Re: [lwip-users] Recent tcp_rexmit() changes

[K.J. Mansley]

On Sun, 2004-07-25 at 20:46, Karl Jeacle wrote:

> The timeout would be OK, and as expected, if it happened just once, but a
> timeout is taking place at each RTT... the sender is stalled for 500ms at
> a time instead of one RTT at a time. I hope I am making some sense!

Yes, I can see your problem.  You'll end up with retransmitted segments
(sent every 500ms) interleaving with new segments (when an ACK for a
retransmitted one is received), and a lot of timeouts will be necessary
to recover.  I think, although can't be sure, that this is the intended
behaviour.  Complex cases such as this are rarely used when illustrating
protocols though, so if anyone knows otherwise, or has a few minutes to
see how a Linux or BSD stack behaves in this scenario, I'd be very
interested to hear from them.

> > Perhaps we could alter the behaviour so that when there is a sudden
> > cut-off in ACKs (which suggests many segments lost), rather than a large
> > number of duplicate acks (which suggests a single segment lost), we
> > resume from the seqno of the first retransmitted packet?  It's a bit
> 
> Assuming, I am correct about the above, I would suggest two versions of
> tcp_rexmit() - one for fast retransmit (to solve Sam's original problem)
> where just a single segment is placed on the unsent queue, and one for
> all other cases, where the previous lwIP behaviour is maintained.

That is a possibility, and although I don't like dumping the whole
unacked queue on the unsent queue just in case it's necessary, it would
solve your problem.  My only worry is that it might result (if we're not
careful) in a large number of segments being put on the network as a
result of a loss, which is completely the opposite of what the sender
should be doing.

> Finally, thanks for info re:SACK etc. My senders and receivers are both
> lwIP, so SACK support would solve problems and definitely be beneficial.

I think this is the best way to proceed, and I believe it's designed to
solve almost exactly this problem.  I don't think it will involve too
much work, so may have a look later today.  Perhaps if I do get
something coded up you'd be willing to test/debug it for us?

Thanks

Kieran