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 
separate:

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 
this.

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.