Date:	Wed, 11 Mar 2009 10:11:10 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	David Miller <davem@...emloft.net>
CC:	md@....sk, johnwheffner@...il.com, netdev@...r.kernel.org
Subject: Re: TCP rx window autotuning harmful at LAN context

David Miller a écrit :
> 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.
> 

I am interested to know how use AQM in practice.

Isnt it a matter of :

Using RED on linux hosts, with 'ecn' flag to mark packets instead
 of droping them if possible.

Using ECN enabled clients and servers. (Assuming most trafic is TCP)
Last time I checked, windows XP doesnt have ECN support. Am I wrong ?

Then in the Marian case, it has many senders that might send data to
one target. Active Queue Management wont triger at sender level,
so we need ECN capable routers that are able to use ECN to mark packets,
because only these routers will notice a queue congestion ?

Or maybe my focus on ECN is not relevant, since it may be marginal and
only save some percent of bandwidth ?

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



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

Powered by blists - more mailing lists