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@bts.sk ---- ---- ---- --------------------------------------------------------------------------