[e2e] Packet re-ordering & NewReno
revans at emea.att.com
Fri May 27 06:10:39 PDT 2005
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.
<-- 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'
<-- 1-ack ( to packet 6 )
<-- 2-ack ( to packet 2 ) , according to newreno this is a partial ack
.. transmit new data if permitted by the cwnd
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 ?
Home Office +44-(0)1422 342472
Home Office: +44-(0)1904 672669
Mobile Number - 07740 056695
More information about the end2end-interest