Subject: Some discussion of NewReno implementation issues
To: None <email@example.com>
From: Charles M. Hannum <firstname.lastname@example.org>
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.