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: <20090311.014103.163410266.davem@davemloft.net>
Date:	Wed, 11 Mar 2009 01:41:03 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	md@....sk
Cc:	johnwheffner@...il.com, netdev@...r.kernel.org
Subject: Re: TCP rx window autotuning harmful at LAN context

From: Marian Ďurkovič <md@....sk>
Date: Wed, 11 Mar 2009 09:29:20 +0100

> For the last time:

Thankfully...

> setting TCP window to BDP is well-known and generally accepted
> practice. Autotuning does NOT respect it, and for 100 Mpbs
> connections at LAN context it might set the rx window somewhere
> between 100*BDP and 300*BDP. Since the BDP formula obviously applies
> also in reverse direction, i.e.

It's the congestion control algorithm on the sender making this
happen, not window autosizing.  The window autosizing is only
providing for flow control.  It's the congestion control algorithm
that is deciding to send more and more into a path where only
latency (and not bandwidth) is increasing with larger congestion
window values.

John has tried to explain this to you, and now I have also made an
effort.  So please stop ignoring what the real issue is here.

You also could use Active Queue Management.  But I doubt you would
bother even testing such a thing to let us know how well that works in
your situation.  You've already decided how you are willing to handle
this issue, so it's a fait accompli.

It's seems to be not even a matter for discussion for you, so that's
why this thread will likely go nowhere if it's entirely up to you.

> delay=window/bandwith
> 
> setting insanely huge window results in insanely increased LAN latencies
> (upto buffer limits). Is this really something noone cares about ?! 

Let me clue you in about something you may not be aware of.

If you don't auto-tune and let the RX socket buffer increase up
to a few megabytes, you cannot fully utilize the link on real
trans-continental connections people are using over the internet
today.

So your suggestion would be a huge step backwards.

This is why you keep being told that what you're asking us to do
is not appropriate.

You can't even talk 100Mbit between New York and San Francisco
without appropriately sized large RX buffers, and RX autotuning
is the only way to achieve that now.

Similarly for west coast US to anywhere in the Asia Pacific region.

So the world is much bigger than your little university where you've
decided to oversubscribe your network, and there are many other issues
to consider besides your specific localized problem.