Re: [lwip-devel] TCP ack timing

[K.J. Mansley]

On Fri, 2004-04-30 at 11:15, Mountifield, Tony wrote:

> Is this correct and/or expected behaviour? Or is there a tweak
> required to efficiently support continuous unidirectional data flows?
> My knowledge of the deeper esoterica of TCP algorithms is fairly limited.

Sounds like there's something strange going on, but it's almost
correct.  TCP delays acknowledging data in order to avoid sending
packets that only contain ACKs and no payload.  As you're sending data
in one direction only, it never gets a packet to send it with (and this
is why sending data in the reverse direction solved the problem). 
However, there are supposed to be limits on the delay in the absence of
traffic:
 - if its been 200ms since the acknowledgement was requested, send the
ACK anyway;
 - if the amount of unacknowledged data is >2*TCP_MSS, send the ACK
anyway.

To do this relies on the TCP timers being called appropriately.  As this
is an embedded system, are you sure this is the case?  Can anyone
provide a (link to a) document/previous post that describes what is
required?  As you get ACKS sent after 0.2s (200ms) it sounds like it is
working.

This suggests that the second limit is not being obeyed.  Having had a
look at the code, lwIP uses a slightly different algorithm: it sends the
ACK if *two ACKs* have been requested, not if *two MSS of data need
ACKing*.  This could result in the behaviour you're seeing if you have a
large TCP_MSS (similar to the receive window), and send a single segment
that closes the receive window entirely.  Then you can't send a second
segment, and so it waits for the 200ms limit to be hit.

This is possibly a bug, but I think you might see similar problems even
if lwIP did the standard 2*TCP_MSS check, as you'd still never reach
2*TCP_MSS if TCP_MSS is > TCP_WND/2.

Could you verify if this is the case?  If not, I'll give it some more
thought.  

Thanks

Kieran

PS. Anyone want to proof read my PhD chapter on acknowledgements and TCP
timers? ;)