[e2e] Packet re-ordering & NewReno

[Evans, Roy]

I am trying to close off a problem I was working on last month , which TCP stack has it wrong. rtfm of course , but thus far I cannot find the manual to read.

I think I am seeing chronic reduction of a senders congestion window as an apparent consequence of using newreno


Box A  ftps to box B
In the network I am looking at, round trip time ~ 250ms .  Box A is in UK , Box B on pacific rim.
Box A puts 128KB in flight ,  window scale is x8 , 128KB is the default tcp transmit buffer for the interface on box A.
No packet loss between A&B of any significance
A implements NewReno fast retransmit

Something re-orders packets between A&B , lets say  1,3,4,5,6,2,7,8,9..endofwindow  within the 128K in-flight .    I am suspecting the 'something' was within box A's IP stack , but was unable to capture this in any trace & of course operating system levels have been changed.   In principle, it could be network  because I do mess around with DSCP bits in the network with a view to doing sensible things in congestion , traffic in an individual flow could get into different Qs & cisco is quite capable of re-ordering packets c/o its Q scheduling.

For simplicity of explanation,  lets say B acknowledges every packet  rather than one in every two.

At A:

<--  1-ack  ( to packet 1 )
<--  1-ack  ( to packet 3 ) first duplicate ack
<--  1-ack  ( to packet 4 ) 2nd duplicate ack
<--  1-ack  ( to packet 5 ) 3rd duplicate ack
A enters fast retransmit
recover = 'endofwindow'

-->  2-retransmit
<--  1-ack ( to packet 6 )
<--  2-ack ( to packet 2 ) , according to newreno this is a partial ack
-->  3-retransmit
<--  7-ack
-->  8-retransmit

.. transmit new data if permitted by the cwnd
..
<--  endofwindow-ack


A exits new-reno , with its congestion window reduced accordingly.   I cannot fault this per newreno documentation , but in an ideal world I'd have hoped that A would have exited fast-retransmit earlier , on the receipt of 2-ack (?).

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 ?


Roy Evans 
AT&T 
Home Office  +44-(0)1422 342472
Home Office: +44-(0)1904 672669 
Mobile Number - 07740 056695