I'am investigated TCP's behaviour, especially the slow start phase after
link layer connectivity has been interrupted for one second. Although
link interuption lasts only 1 second, it takes about 7 additional
seconds until TCP communications continues at full speed. It is not
the exponential backoff strategy of TCP that causes this communication pause.
I'm not sure if this behaviour, discribed in detail below, is
due to a defency of the Linux TCP implementation, or if it is according to
the specification of TCP. Hopefully a TCP guru can help ....
Scenario:
- sender and receiver running Linux 2.1.124
- no background traffic, no congestion
- receiver located close to basestation, thus no transmision errors
on wireless link
- ftp transfer from sender --> receiver
- 3 ms RTT
- GBN retransmission, no SACKs
- wireless link interrupted for 1.0 secs
sender WaveLan Basestation receiver
| | | |
-------------------- -------------------------
10 Mbit/s 2 Mbit/s wireless Link
Figures representing packet sequence traces (x-axis: time [sec],
y-axis: seqnr [bytes]) can be found at
http://www.ibr.cs.tu-bs.de/~fieger/tcp_delay/tcp_delay.html
Additional, tcpdump output of packettraces at the sender/receive can
be found at this web page.
The sender transmitts packets of a flow control window up to
seq. 16062953 and stops transmission due to exhausted send credit.
The channel is interrupted between t=96.3 sec and t=97.3 sec. (Note:
The timescale of the x-axis differs form the timescale of the trace
appendend at the end of this file). Data ackets (seq-nr. 16047025
to seq-nr. 16062953) and ack-packets (from receiver to sender)
achnowledging seq 16032545 are lost due to the interrupted channel.
During t=96.3 and t=98.0 we see the exponential backoff behaviour of TCP.
Up to this point in time everything happens as aspected. From t=98.0
up to t=104 the sender retransmitts every 0.5 secs a single packet.
Between consecutive retransmission of packets 0.5 secs. pass. This is
due to the delayed ack strategy of the receiver that receives only a single
data packet and thus sends the ack after the ack delay has expired.
What I'am wondering about is:
Why does the sender transmitt between t=98 and t=104 retransmitt only
a single packet every 0.5 secs. What I would expect is a slow start phase
with increasing congestion control window:
At t=98 a single packet is retransmitted and at 98.5 the ack received.
Due to the received ack the cwnd is incremented, thus at t=98.5 TWO data
packets should be send. Between 98.5 and 99 acks for both data packets should
arrive. Thus cwnd should be set to 4 and at t=99 FOUR data packets be
transmitted to the receiver... (and so on)
However the figure and the packet traces clearly depict, that ever 0.5 secs
only a SINGLE packet is retransmitted and no increase of the congestion
control window takes place.
Within the Linux 2.1.124 I identified the code, that prevents the adaption
of the congestion control window (CWND) if the received ack is a ack
that belongs to an retransmitted packets.
IS THIS BEHAVIOUR ACCORDING TO THE TCP SPECIFICATION AND WHAT IS THE REASON
FOR NOT ADAPTING THE CONGESTION WINDOW WHEN ACKS BELONGING TO RETRANSMITTED
PACKETS ARRIVE AT THE SENDER ????
Thanks
Andreas
=====================================================================
Andreas Fieger fieger@ibr.cs.tu-bs.de Tel.: +49 531 391 3250
Department of Computer Science, TU Braunschweig, Bueltenweg 74/75,
D-38106 Braunschweig, Germany
=====================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/