From: David Miller <davem@davemloft.net>
To: shemminger@vyatta.com
Cc: therbert@google.com, netdev@vger.kernel.org, ycheng@google.com
Subject: Re: [PATCH] tcp: Socket option to set congestion window
Date: Tue, 25 May 2010 22:52:36 -0700 (PDT) [thread overview]
Message-ID: <20100525.225236.226781050.davem@davemloft.net> (raw)
In-Reply-To: <20100525220858.1071f238@nehalam>
From: Stephen Hemminger <shemminger@vyatta.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.
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.
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.
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.
next prev parent reply other threads:[~2010-05-26 5:52 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-26 5:01 [PATCH] tcp: Socket option to set congestion window Tom Herbert
2010-05-26 5:08 ` Stephen Hemminger
2010-05-26 5:52 ` David Miller [this message]
2010-05-26 7:06 ` Tom Herbert
2010-05-26 7:33 ` David Miller
2010-05-26 17:33 ` Andi Kleen
2010-05-26 17:41 ` Denys Fedorysychenko
2010-05-26 21:08 ` David Miller
2010-05-26 21:27 ` Andi Kleen
2010-05-26 22:10 ` David Miller
2010-05-26 22:29 ` Rick Jones
2010-05-27 7:57 ` Andi Kleen
2010-05-26 23:15 ` Hagen Paul Pfeifer
2010-05-27 3:04 ` David Miller
2010-05-27 7:08 ` Hagen Paul Pfeifer
2010-05-27 7:28 ` David Miller
2010-05-27 7:46 ` Hagen Paul Pfeifer
2010-05-27 16:14 ` Tom Herbert
2010-05-27 18:56 ` Andi Kleen
2010-05-27 19:19 ` Hagen Paul Pfeifer
2010-05-27 8:00 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100525.225236.226781050.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
--cc=therbert@google.com \
--cc=ycheng@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).