Shady areas of TCP window autotuning?
Marian Ďurkovič
md at bts.sk
Mon Mar 16 09:15:37 UTC 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