[lwip-users] ACK transmission in tcp_recved()

[tbutler]

Hi all,

In looking at a trace, I see that TCP sends an ACK for every incoming
segment, never piggy-backing the acknowledgment despite the existence of 2
way traffic. I see that this is due to the function tcp_recved(),
specifically its logic which sends an immediate ACK if one is pending and
the newly updated rcv_win is above a threshold. The comment indicates that
this is an attempt to refrain from sending an ACK for each window update.
However, it appears that the only way an ACK WILL NOT be sent is if the
application reads data significantly slower than the incoming segment
arrival rate such that a call to tcv_recved() finds rcv_wnd under the
threshold, even after being updated. As this is not the case in my
application, every incoming segment results in an outgoing ACK-only
segment.

It seems to me that the logic should take into account the amount of
accumulated window updates pending communication to the peer, in order to
strike a balance between minimizing ACKs and not stalling the peer. If I
understand the spirit of the comment, the idea would be to send an ACK only
when the amount by which the window has opened since the last ACK reaches
some threshold (MSS, fraction of window, etc.). That is, the amount of
unadvertised window has grown "significantly" since we last sent an ACK.

To test this, I added a new receive variable, rcv_wnd_owed, which is
incremented in tcv_recved() and reset to zero each time an ACK is sent. I
changed the threshold comparison in tcp_rcved() to use this variable
instead of rcv_wnd, thereby using the unadvertised window as the threshold
criterion.This works well for me, but maybe I've only solved my scenario:
slow GSM link with bidirectional traffic. From the mail list archives, it
appears that this was added for the scenario of unidirectional reception
over Ethernet, but I think my change would be applicable, apart from
possible tuning of the threshold.

I'd welcome comments, as I may have misunderstood the intent of this logic.
Should my changes be of interest, I'll post a patch.

Tim Butler