netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Rick Jones <rick.jones2@hp.com>
Cc: andi@firstfloor.org, David Miller <davem@davemloft.net>,
	therbert@google.com, shemminger@vyatta.com,
	netdev@vger.kernel.org, ycheng@google.com
Subject: Re: [PATCH] tcp: Socket option to set congestion window
Date: Thu, 27 May 2010 09:57:18 +0200	[thread overview]
Message-ID: <20100527075717.GA6800@basil.fritz.box> (raw)
In-Reply-To: <4BFDA0B6.8030701@hp.com>

> Then all the app does is say "I'am in peer id foo" right?  Is that really 
> that much different from making the setsockopt() call for a different cwnd 
> value? Particularly if say the limit were not a global sysctl, but based on 
> the existing per-route value (perhaps expanded to have a min, max and 
> default?)

The worst case with peer id would be app using an own peer id
for each connection. So each connection would have an own cwnd,
just like today. So the worst case is the same as today.

If it shares connections between peer ids the real effective cwnd
of all those connections would be also never be "worse" (that is
larger) than it could be on single connection. 

So this limits the cwnds effectively with peer ids, although it also 
gives a nice way to reuse an already existing cwnd for a new
connection (this does not make things worse because in theory
the app could have reused the same connection too) 

So overall peer ids don't allow to enlarge cwnds over today.

If the cwnd is fully application controlled all these limits
are not there and a bittorrent client could just always set 
it to 1 million.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

  reply	other threads:[~2010-05-27  7:57 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
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 [this message]
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=20100527075717.GA6800@basil.fritz.box \
    --to=andi@firstfloor.org \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.com \
    --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).