All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hagen Paul Pfeifer <hagen@jauu.net>
To: David Miller <davem@davemloft.net>
Cc: andi@firstfloor.org, 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 01:15:12 +0200	[thread overview]
Message-ID: <20100526231512.GD2684@nuttenaction> (raw)
In-Reply-To: <20100526.151014.70204145.davem@davemloft.net>

* David Miller | 2010-05-26 15:10:14 [-0700]:

>From: Andi Kleen <andi@firstfloor.org>
>Date: Wed, 26 May 2010 23:27:45 +0200
>
>> As I understand the idea was that the application knows
>> what flows belong to a single peer and wants to have
>> a single cwnd for all of those. Perhaps there would
>> be a way to generalize that to tell it to the kernel.
>> 
>> e.g. have a "peer id"  that is known by applications
>> and the kernel could manage cwnds shared between connections
>> associated with the same peer id?
>> 
>> Just an idea, I admit I haven't thought very deeply
>> about this. Feel free to poke holes into it.
>
>Yes, a CWND "domain" that can include multiple sockets is
>something that might gain some traction.
>
>The "domain" could just simply be the tuple {process,peer-IP}

This discussion - as once a month - is about fairness. But if we define a
domain as a tuple of {process,peer-IP} the fairness is applied only for the
last link before "peer-IP".

But fairness applies to *all* links in between! For example: consider a
dumpbell scenario:


+------+                                   +------+ 
|      |                                   |      |  
|  H1  |                                   |  H3  | 
|      |                                   |      |  
+------+                                   +------+  
  10MB  \   +------+            +------+  / 10MB
         \  |      |   1MB/s    |      | / 
          > |  R1  |------------|  R2  |<    
         /  |      |            |      | \      
  10MB  /   +------+            +------+  \ 10MB 
+------+                                   +------+  
|      |                                   |      |        
|  H2  |                                   |  H4  | 
|      |                                   |      | 
+------+                                   +------+


How can a domain defined as {process,peer-IP} fair to the 1MB bottleneck link?
It is not fair! And it is also not fair to open n simultaneous streams and so
on. This problem is discussed in several RFC's.

.02


Best regards, Hagen


-- 
Hagen Paul Pfeifer <hagen@jauu.net>  ||  http://jauu.net/
Telephone: +49 174 5455209           ||  Key Id: 0x98350C22
Key Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22


  parent reply	other threads:[~2010-05-26 23:15 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
2010-05-26 23:15               ` Hagen Paul Pfeifer [this message]
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=20100526231512.GD2684@nuttenaction \
    --to=hagen@jauu.net \
    --cc=andi@firstfloor.org \
    --cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.