Shady areas of TCP window autotuning?

Mon Mar 16 13:05:18 UTC 2009

Briefly?  They're correct - the rx advertised window has nothing to do  
with congestion control and everything to do with flow control.

The problem you've described *is* a problem, but not because of its  
effects on congestion control -- the problem it causes is one we call  
a lack of agility:  it takes longer for control signals to take effect  
if you're doing things like fast-forwarding a YouTube movie that's  
being delivered over TCP.

If you want patches for Linux that properly decrease the window size,  
I can send you them out-of-band.

But in general, TCP's proper behavior is to try to fill up the  
bottleneck buffer.  This isn't a huge problem *in general*, but can be  
fairly annoying on, e.g., cable modems with oversized buffers, which  
are fairly common.  But that's pretty fundamental with the way TCP is  
designed.  Otherwise, you WILL sacrifice throughput at other times.

   -Dave

On Mar 16, 2009, at 5:15 AM, Marian Ďurkovič wrote:

> 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    ----
> ----                                                                  ----
> --------------------------------------------------------------------------
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20090316/258ea5b6/attachment.sig>