netdev - Re: TCP rx window autotuning harmful at LAN context

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1e41a3230903091101u536a3b3bv7f0dd9da6891781e@mail.gmail.com>
Date:	Mon, 9 Mar 2009 11:01:52 -0700
From:	John Heffner <johnwheffner@...il.com>
To:	Marian Ďurkovič <md@....sk>
Cc:	netdev@...r.kernel.org
Subject: Re: TCP rx window autotuning harmful at LAN context

On Mon, Mar 9, 2009 at 4:25 AM, Marian Ďurkovič <md@....sk> wrote:
>   As rx window autotuning is enabled in all recent kernels and with 1 GB
> of RAM the maximum tcp_rmem becomes 4 MB, this problem is spreading rapidly
> and we believe it needs urgent attention. As demontrated above, such huge
> rx window (which is at least 100*BDP of the example above) does not deliver
> any performance gain but instead it seriously harms other hosts and/or
> applications. It should also be noted, that host with autotuning enabled
> steals an unfair share of the total available bandwidth, which might look
> like a "better" performing TCP stack at first sight - however such behaviour
> is not appropriate (RFC2914, section 3.2).

It's well known that "standard" TCP fills all available drop-tail
buffers, and that this behavior is not desirable.

The situation you describe is exactly what congestion control (the
topic of RFC2914) should fix.  It is not the role of receive window
(flow control).  It is really the sender's job to detect and react to
this, not the receiver's.  (We have had this discussion before on
netdev.)  There are a number of delay-based congestion control
algorithms that have been implemented and are available in Linux, but
all have proved problematic in many cases, and has not been suitable
to enable widely.  This is still an active research topic.

Another option in LANs is to enable AQM.  In Linux, you can configure
the bottleneck interface qdisc to be any of a number of RED-like early
droppers.  Most commercial routers also offer the ability to configure
AQM on interfaces, though most do not enable by default.

  -John
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html