[e2e] Unexpected small reduction in cwnd during iperf test

[Salman Abdul Baset]

I can think of two possible scenarios:

2.6.13 implements RFC 2861 which suggests that cwnd should be reduced
if application packet rate is reduced. But that does not seem to be the
case in your scenario.

You may want to check the TCP send and receive buffer sizes. It may so
happen that the receiver ran out of buffer space because packets were
reordered and so the sender had to reduce its window.

The possible reason for retransmission without packet loss is timeout. You
may want to check its value. You may also want to do indirect packet
counting at sender and receiver using tcpdump and wc.

Regards,
Salman

>
> Message: 6
> Date: Tue, 08 Aug 2006 19:32:19 +0100
> From: Toby Rodwell <toby.rodwell at dante.org.uk>
> Subject: [e2e] Unexpected small reduction in cwnd during iperf test
> To: end2end-interest at postel.org
> Message-ID: <44D8D8B3.9060109 at dante.org.uk>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
> _____________________________________________________________________
>
>
>
>
> ------------------------------
>
> _______________________________________________
> end2end-interest mailing list
> end2end-interest at postel.org
> http://mailman.postel.org/mailman/listinfo/end2end-interest
>
>
> End of end2end-interest Digest, Vol 30, Issue 12
> ************************************************
>