[112731] in North American Network Operators' Group
Re: Shady areas of TCP window autotuning?
daemon@ATHENA.MIT.EDU (David Andersen)
Mon Mar 16 09:05:41 2009
From: David Andersen <dga@cs.cmu.edu>
To: =?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?= <md@bts.sk>
In-Reply-To: <20090316091537.GA25118@bts.sk>
Date: Mon, 16 Mar 2009 09:05:18 -0400
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-27--944003053
Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Briefly? They're correct - the rx advertised window has nothing to do =20=
with congestion control and everything to do with flow control.
The problem you've described *is* a problem, but not because of its =20
effects on congestion control -- the problem it causes is one we call =20=
a lack of agility: it takes longer for control signals to take effect =20=
if you're doing things like fast-forwarding a YouTube movie that's =20
being delivered over TCP.
If you want patches for Linux that properly decrease the window size, =20=
I can send you them out-of-band.
But in general, TCP's proper behavior is to try to fill up the =20
bottleneck buffer. This isn't a huge problem *in general*, but can be =20=
fairly annoying on, e.g., cable modems with oversized buffers, which =20
are fairly common. But that's pretty fundamental with the way TCP is =20=
designed. Otherwise, you WILL sacrifice throughput at other times.
-Dave
On Mar 16, 2009, at 5:15 AM, Marian =C4=8Eurkovi=C4=8D wrote:
> Hi all,
>
> TCP window autotuning is part of several OSs today. However, the =20
> actual
> implementations behind this buzzword differ significantly and might =20=
> impose
> negative side-effects to our networks - which I'd like to discuss =20
> here.
> There seem to be two basic approaches which differ in the main =20
> principle:
>
> #1: autotuning tries to set rx window to a sensible value for a =20
> 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 =20=
> paths,
> their behaviour on low-RTT paths is very different - mainly because =20=
> the
> fact, that #2 suffers from "spiraling death" syndrome. I.e. when RTT
> increases due to queueing at the bottleneck point, autotuning reacts =20=
> by
> increasing the advertised window, which again increases RTT...
> So the net effect of #2 is, that after very short TCP connection =20
> lifetime
> it might advertise extermely huge RX window compared to BDP of the =20
> 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 =20=
> 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 =20
> of #2,
> who claim that receiver is not supposed to anyhow assist in congestion
> control. Instead, they advise everyone to use advanced queue =20
> 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 =20=
> to
> someone else, not mentioning the fact, that absolutely trusting the =20=
> sender
> to perform everything right and removing all safety-belts at the =20
> receiver
> could be very dangerous.
>
> What do people here think about this topic?
>
>
> Thanks & kind regards,
>
> M.
>
> =
--------------------------------------------------------------------------=
> ---- =
----
> ---- Marian =C4=8Eurkovi=C4=8D network =20
> manager ----
> ---- =
----
> ---- Slovak Technical University Tel: +421 2 571 041 =20
> 81 ----
> ---- Computer Centre, N=C3=A1m. Slobody 17 Fax: +421 2 524 94 =20=
> 351 ----
> ---- 812 43 Bratislava, Slovak Republic E-mail/sip: =20
> md@bts.sk ----
> ---- =
----
> =
--------------------------------------------------------------------------=
>
>
--Apple-Mail-27--944003053
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkm+To4ACgkQLZyskygNjpx12gCdF99h8y8tzDvX4NA4kLT8Kfu3
R+YAoIaHT+3HsMgXANSITgoqPgUiqoOe
=fKef
-----END PGP SIGNATURE-----
--Apple-Mail-27--944003053--
