[e2e] Packet re-ordering & NewReno

[Henderson, Thomas R]

> -----Original Message-----
> From: Evans, Roy [mailto:revans at emea.att.com] 
> Sent: Friday, May 27, 2005 6:11 AM
> To: end2end-interest at postel.org
> Subject: [e2e] Packet re-ordering & NewReno
> 
<snip>
> 
> Anyhow, its what happens next that I am getting excited 
> about, ok perhaps confused by.
> 
> There is a bunch of retransmitted data in flight in the 
> network , followed by new & retransmitted data.
> 
> The retransmitted data hits B , B responds with 
> endofwindow-ack again.   To me, this seems a reasonable response
> 
> So , I end up with a stream of endofwindow-acks flowing back to A
> 
> ..which triggers a fast / newreno response  & its reduction 
> of ssthresh & cwnd
> 
> another round-trip time later , new-reno exits , with a bunch 
> of retransmitted data in flight in the network , triggering 
> duplicate acks , triggering a third fast/newreno response.
> 
> 
> Any thoughts on what the protocol error is ?

It looks like this implementation is supporting the so-called "Less
Careful" variant of NewReno (see Section 5 of RFC 2582).  Such a variant
is more aggressive in recovering from the loss of the (endofwindow+1)
new packet transmission without taking a timeout, at the cost of more
unnecessary fast retransmits in other scenarios (which, in this
reordering case, is clearly suboptimal).

Both RFCs 2582 and its update, 3782, recommend the Careful variant,
although the Less Careful variant is dropped altogether (and only the
Careful variant specified) in 3782.  See Section 11 of RFC 3782.

Tom