[e2e] Unexpected small reduction in cwnd during iperf test

[Toby Rodwell]

Can anyone think in what circumstances a TCP instance might reduce cwnd
by a small amount, without there being any change in ssthresh?  I
detected this with a script that periodically (every 0.25 seconds)
collects TCP stats.  The TCP transfer in question was an iperf test
running between a measurement point in a New York PoP and
another in Budapest.  netstat (run before and after the test) confirms
that there was no packet loss, but there were two re-transmitted
segments, which presumably was the event which initially set ssthresh as
4740, and I assume was caused by reordering/dup ACKs.

Time (s)	
15.50 	 cwnd:5931	 ssthresh:4740	 	
15.75 	 cwnd:5931	 ssthresh:4740	 	
16.00 	 cwnd:5931	 ssthresh:4740
...
23.75 	 cwnd:5931	 ssthresh:4740	 	
24.00 	 cwnd:5926	 ssthresh:4740 <==GLITCH?	
24.25 	 cwnd:5927	 ssthresh:4740	 	
24.50 	 cwnd:5928	 ssthresh:4740	 	
24.75 	 cwnd:5929	 ssthresh:4740	 	
25.00 	 cwnd:5930	 ssthresh:4740	 	
25.25 	 cwnd:5931	 ssthresh:4740	 	
25.50 	 cwnd:5931	 ssthresh:4740	 	

The hosts are both Linux kernel's 2.6.13, using BIC congestion control.

regards
Toby

-- 
______________________________________________________________________

Toby Rodwell
Network Engineer

DANTE - www.dante.net

Tel: +44 (0)1223 371 300
Fax: +44 (0)1223 371 371
Email: toby.rodwell at dante.org.uk
PGP Key ID: 0xB864694E

City House, 126-130 Hills Road
Cambridge CB2 1PQ
UK
_____________________________________________________________________