Subject: Re: Some discussion of NewReno implementation issues
To: None <firstname.lastname@example.org>
From: Charles M. Hannum <email@example.com>
Date: 01/27/2005 04:10:20
On Thursday 27 January 2005 00:29, Charles M. Hannum wrote:
> 3) RFC 3782 suggests keeping track of whether we're in fast recovery in a
> separate variable, noting that out-of-order acks can reset "dupacks". I
> note that out-of-order acks are also likely to prevent getting into fast
> recovery in the first place; the possibility of getting out-of-order acks
> *after* entering fast recovery is not particularly high unless our window
> is fairly large, and in that case we're best off using SACK anyway.
> Keeping extra state here seems to have minimal benefit, and creates
> additional risk that we will not clean up the state machine properly in
> some case.
Note that I changed this. There are two benefits to keeping the state
1) It ensures that we reset cwnd correctly on exiting fast recovery. There
were some cases (mainly out-of-order acks) that would cause us to do not do
2) It combined easily with keeping track of how many partial acks we've
received, so that we only reset the RTO timer once per fast recovery. This
avoids a pathological behavior where we could wait for one RTO per segment
after entering fast recovery in NewReno.
After Kentaro updates his SACK patch for the latest changes, I will be testing
that and will hopefully commit it later this week.