Subject: Fwd: Re: Question about NewReno
To: Kentaro A. Kurahone <email@example.com>
From: Charles M. Hannum <firstname.lastname@example.org>
Date: 01/04/2005 06:44:44
Whoops, must have hit the wrong reply button...
---------- Forwarded Message ----------
Subject: Re: Question about NewReno
Date: Tuesday 04 January 2005 06:40
From: "Charles M. Hannum" <email@example.com>
To: "Kentaro A. Kurahone" <firstname.lastname@example.org>
On Tuesday 04 January 2005 05:13, Kentaro A. Kurahone wrote:
> On Tue, Jan 04, 2005 at 02:08:17AM +0000, Charles M. Hannum wrote:
> > Does anyone have further insight into this?
> The behavior is correct. See RFC2582 for more details, specifically
> section 5, "Avoiding Multiple Fast Retransmits". It basically boils down
> to trying to determine if a dupAck is caused by actual duplicate data, or
> by a packet loss without SACK.
But see the numbered list in section 3.
1. They use max(wnd/2,2mss), not max(min(wnd,cwnd)/2,2mss), as we do. (I'm
not convinced their variant is more correct, but I'm not sure what the origin
of the difference is.)
5. Total acknowledgment case: We seem to be choosing option 2. Our detection
of a "burst" is extremely fishy.
And now see section 5.
1A. This is where the code I initially questioned comes up. Note that this
uses a new variable called "send_high", which is in fact supposed to be set
during a retransmit timeout (or as I say, slow-retransmit). It does not use
the "recover" value. Also note that it says "do nothing" -- this does not
include increasing cwnd and transmitting a packet!
So, I think the so-called "NewReno" code in our source tree is broken.
I'm also a little concerned about something they don't mention anywhere.
When we see further duplicate acks during fast retransmit, we increment cwnd
by one mss (keeping in mind that it was already set to ssthresh+3mss by the
third duplicate ack) and call tcp_output(). This potentially creates a
thundering herd of ssthresh+3mss data, where ssthresh was nominally half the
previous cwnd. This means we could suddenly retransmit more than half our
buffer. I don't think this is desirable.