Date:	Wed, 26 May 2010 00:06:35 -0700
From:	Tom Herbert <therbert@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	shemminger@...tta.com, netdev@...r.kernel.org, ycheng@...gle.com
Subject: Re: [PATCH] tcp: Socket option to set congestion window

On Tue, May 25, 2010 at 10:52 PM, David Miller <davem@...emloft.net> wrote:
>
> From: Stephen Hemminger <shemminger@...tta.com>
> Date: Tue, 25 May 2010 22:08:58 -0700
>
> > The IETF TCP maintainers already think Linux TCP allows unsafe
> > operation, this will just allow more possible misuse and prove
> > their argument.  Until/unless this behavior was approved by
> > a wider set of research, I don't think it should be accepted at
> > this time.
>
> Yes, and two other points I'd like to add.
>
> 1) Stop pretending a network path characteristic can be made into
>   an application level one, else I'll stop reading your patches.
>
>   You can try to use smoke and mirrors to make your justification by
>   saying that an application can circumvent things right now by
>   openning up multiple connections.  But guess what?  If that act
>   overflows a network queue, we'll pull the CWND back on all of those
>   connections while their CWNDs are still small and therefore way
>   before things get out of hand.
>
It's really not that simple.  In the application with multiple
connections, congestion may only affect some number of connections, so
more of the aggregate window may be preserved.  This is an unfairness
issue between 1 and N connection scenarios which is a real problem.

>
>   Whereas if you set the initial window high, the CWND is wildly out
>   of control before we are even started.
>
>   And even after your patch the "abuse" ability is still there.  So
>   since your patch doesn't prevent the "abuse", you really don't care
>   about CWND abuse.  Instead, you simply want to pimp your feature.
>
> 2) The very last application I'd want to use something like this is a
>   damn web browser.
>

Right, this should be fixed in the server not at the browsers.
Unfortunately, web browsers seem to have lost any self control in
limiting the number of simultaneous connections that can be opened (we
managed to get IE8 to open over 100 of them).  So the cat's way out of
the bag.  Server's can rein this problem in by only allowing fewer
connections, but at the cost of losing latency is not much incentive!

>   Maybe a program, which is extremely sophisticated, like a database
>   or caching manager, that runs privileged and somehow has complete
>   and constantly updated knowledge of the network topology from end
>   to end.  And iff, and only iff, we only would let privileged
>   applications make the setting.
>
> Right now we only allow to do this via a route setting, exactly because:
>
> 1) It is a network path characteristic, full stop.
>
Thanks to NAT, the concept of a network path or even host specific
path is a weakened concept.  On the Internet this may be a path
characteristic per client, which unfortunately has no visibility in
the kernel other than per connection state.  When a single IP address
may have thousands of hosts behind it, caching TCP parameters for that
IP address is implicitly doing a huge aggregation-- probably dicey...

>
> 2) Only humans can really know what the exact end to end path
>   characteristics are on a per-route basis, and given that whether it
>   is safe to increase the initial CWND as a result.

In all but the most trivial networks, I do not believes humans are
capable of making an intelligent decision about this.  Don't get me
wrong, it's great that it can be set in the route, but there's nothing
at all that prevents naive abuse (2009 study showed that 15%
connections of connections on the Internet violate icw standards
anyway).  We have proposed in iETF to raise the initial congestion
window, but dynamic mechanisms that algorithmically determine safe
values are still of interest and may be safer which is what this patch
would allow.

Thanks for your comments!
--
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