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

[Mountifield, Tony]

Has anyone (e.g. Kieran) evaluated these patches from Sam?

They appear to work fine for me, and I'm wondering whether they will make it 
into CVS sometime or not.

Cheers
Tony

> -----Original Message-----
> From: Sam Jansen [mailto:address@hidden
> Sent: 27 July 2004 02:34
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] Recent tcp_rexmit() changes
> 
> 
> K.J. Mansley wrote:
> > 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.
> 
> After a retransmit timeout, the sender should be in slow start. lwIP 
> seems to miss this fundamental point. RFC 2001 states that
> 
> "Therefore, after retransmitting the dropped segment the TCP 
> sender uses 
> the slow start algorithm to increase the window from 1 full-sized 
> segment to the new value of ssthresh, at which point congestion 
> avoidance again takes over."
> 
> It is because of this lack in functionality that lwIP behaves poorly 
> when there is enough loss that fast retransmit cannot cope 
> and a timeout 
> occurs.
> 
>  > 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.
> 
> I see why you might be concerned, the behaviour I found 
> before the fast 
> retransmit fix showed such happening. However this will not happen if 
> lwIP enters slow start correctly. I have implemented this 
> behaviour and 
> now lwIP behaves well enough during loss.
> 
> Changes I made:
> * Added a tcp_rexmit_rto function that is a clone of the old 
> tcp_rexmit 
> function
> * Made sure this function was called AFTER cwnd is set to 1 mss in 
> tcp_slowtmr
> * Uncommented the old code which allowed acks to ack data in 
> the unsent 
> queue
> * Made a small modification to tcp_output which checks the sequence 
> number of the packet just sent. This was needed because a packet sent 
> with a fast retransmit would end up on the end of the unacked queue, 
> even though it should be at the start of the queue.
> 
> Attached is a diff. I made it against the stable version, but 
> it looks 
> like it applies fine to HEAD.
> 
> > 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?
> 
> I'm not certain SACK is all it is thought to be. Research in 
> this area 
> by myself as well as recent analysis points out that SACK 
> almost never 
> makes a difference. However, there are other strategies you 
> can employ 
> to improve throughput.
> 
> Consider this: FreeBSD does not implement SACK (though I have 
> heard it 
> is making its way into -CURRENT) and OpenBSD does. However, FreeBSD 
> vastly outperforms OpenBSD, even in lossy situations. I've 
> also measured 
> Linux (2.4.20 at the time) to get no real difference in 
> throughput with 
> or without SACK in laboratory tests.
> 
> The most interesting research I have seen that improves 
> throughput under 
> loss is the (somewhat) recent Westwood congestion control 
> algorithm that 
> is a part of Linux since 2.4.26 (and 2.6.something). I've found its 
> quite an improvement on its own, though with the help of SACK 
> it's even 
> better.
> 
> See:
> http://www-ictserv.poliba.it/mascolo/tcp%20westwood/homeW.htm
> and
> http://www-ictserv.poliba.it/mascolo/tcp%20westwood/Tech_Rep_0
7_03_S.pdf
for information on Westwood.

Failing that, perusing the sources of FreeBSD shows all sorts of tricks 
they use to improve performance at little cost.

-- 
Sam Jansen                                           address@hidden
Wand Network Research Group             http://www.wand.net.nz/~stj2


***********************************************************************************
This email, its content and any attachments is PRIVATE AND
CONFIDENTIAL to TANDBERG Television. If received in error please
notify the sender and destroy the original message and attachments.

www.tandbergtv.com
***********************************************************************************