Subject: Some discussion of NewReno implementation issues
To: None <>
From: Charles M. Hannum <>
List: tech-net
Date: 01/27/2005 00:29:24
There are a few things I should point out WRT to the way I've implemented 

1) It is the "Less Careful" version as specified in RFC 2582.  The throughput 
of the "Careful" version is almost strictly worse, AFAICT, so I really don't 
seen any point.

2) It uses the separate "send_high" and "recover" variables as per RFC 2582.  
RFC 3782 specifies a single variable; unfortunately, this massively 
complicates the logic for when to update snd_high to track snd_una.  It also 
prevents fast retransmitting the first packet after the completing ack of a 
previous fast retransmit, and thus reduces performance in that case.  I note 
that the change to a single state variable and its implications were not 
discussed *anywhere* in RFC 3782.

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.

Really, NewReno is very poorly specified.  RFC 2582 includes many variants, 
and RFC 3782 adds several new ones while only removing one.  It is nearly 
impossible to say that any variant is strictly better or worse than any 
other.  RFC 3782 also does not discuss the impact of overloading "recover," 
even though there clearly *is* an impact.

As such, given that the performance appears to have been brought back in line 
with Reno, I am not inclined to touch it again unless I see hard numbers to 
demonstrate that another variant is better.