Shady areas of TCP window autotuning?

Marian Ďurkovič md at bts.sk
Mon Mar 16 04:15:37 CDT 2009


Hi all,

   TCP window autotuning is part of several OSs today. However, the actual
implementations behind this buzzword differ significantly and might impose
negative side-effects to our networks - which I'd like to discuss here.
There seem to be two basic approaches which differ in the main principle: 

#1: autotuning tries to set rx window to a sensible value for a given RTT 
#2: autotuning just ensures, that rx window is always bigger than 
    congestion window of the sender, i.e. it never limits the flow

While both approaches succeed to achieve high throughput on high-RTT paths,
their behaviour on low-RTT paths is very different - mainly because the
fact, that #2 suffers from "spiraling death" syndrome. I.e. when RTT 
increases due to queueing at the bottleneck point, autotuning reacts by
increasing the advertised window, which again increases RTT...
So the net effect of #2 is, that after very short TCP connection lifetime
it might advertise extermely huge RX window compared to BDP of the path: 

RTT when idle    Max advertised window #1     Max advertised window #2
----------------------------------------------------------------------
< 1 msec          66560 byte                  3 Mbyte
3 msec            66560 byte                  3 Mbyte
12 msec          243200 byte                  3 Mbyte
24 msec          482048 byte                  3 Mbyte

(The above data were taken from the same host connected by 100 Mpbs ethernet
to the network while running two OSs with different approaches and
transferring 1 GByte of data)

It's obvious, that #2 has significant impact on the network. Since
it advertises really huge window, it will fill up all buffers at the
bottleneck point, it might increase latency to >100 msec levels even
at LAN context and prevent classic TCP implementations with fixed
window size from getting a fair share of bandwidth.

This however doesn't seem to be of any concern for TCP maintainers of #2,
who claim that receiver is not supposed to anyhow assist in congestion
control. Instead, they advise everyone to use advanced queue management,
RED or other congestion-control mechanisms at the sender and at every
network device to avoid this behaviour.

My personal opinion is that this looks more like passing the problem to
someone else, not mentioning the fact, that absolutely trusting the sender
to perform everything right and removing all safety-belts at the receiver
could be very dangerous.

What do people here think about this topic?  


    Thanks & kind regards,

            M.

--------------------------------------------------------------------------
----                                                                  ----
----   Marian Ďurkovič                       network  manager         ----
----                                                                  ----
----   Slovak Technical University           Tel: +421 2 571 041 81   ----
----   Computer Centre, Nám. Slobody 17      Fax: +421 2 524 94 351   ----
----   812 43 Bratislava, Slovak Republic    E-mail/sip: md at bts.sk    ----
----                                                                  ----
--------------------------------------------------------------------------




More information about the NANOG mailing list