public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ed W <lists@wildgooses.com>
To: Hagen Paul Pfeifer <hagen@jauu.net>
Cc: Rick Jones <rick.jones2@hp.com>,
	David Miller <davem@davemloft.net>,
	davidsen@tmr.com, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org
Subject: Re: Raise initial congestion window size / speedup slow start?
Date: Wed, 14 Jul 2010 23:05:31 +0100	[thread overview]
Message-ID: <4C3E34AB.2060405@wildgooses.com> (raw)
In-Reply-To: <20100714203919.GD6682@nuttenaction>

On 14/07/2010 21:39, Hagen Paul Pfeifer wrote:
> * Rick Jones | 2010-07-14 13:17:24 [-0700]:
>
>    
>> There is an effort under way, lead by some folks at Google and
>> including some others, to get the RFC's enhanced in support of the
>> concept of larger initial congestion windows.  Some of the discussion
>> may be in the "tcpm" mailing list (assuming I've not gotten my
>> mailing lists confused).  There may be some previous discussion of
>> that work in the netdev archives as well.
>>      
> tcpm is the right mailing list but there is currently no effort to develop
> this topic. Why? Because is not a standardization issue, rather it is a
> technical issue. You cannot rise the initial CWND and expect a fair behavior.
> This was discussed several times and is documented in several documents and
> RFCs.
>    

I'm sure you have covered this to the point you are fed up, but my 
searches turn up only a smattering of posts covering this - could you 
summarise why "you cannot raise the initial cwnd and expect a fair 
behaviour"?

Initial cwnd was changed (increased) in the past (rfc3390) and the RFC 
claims that studies then suggested that the benefits were all positive. 
Some reasonably smart people have suggested that it might be time to 
review the status quo again so it doesn't seem completely obvious that 
the current number is optimal?

> RFC 5681 Section 3.1. Google employees should start with Section 3. This topic
> pop's of every two months in netdev and until now I _never_ read a
> consolidated contribution.
>    

Sorry, what do you mean by a "consolidated contribution"?

That RFC is a subtle read - it appears to give more specific guidance on 
what to do in certain situations, but I'm not sure I see that it 
improves slow start convergence speed for my situation (large RTT)?  
Would you mind highlighting the new bits for those of us a bit newer to 
the subject?

> Partial local issues can already be "fixed" via route specific ip options -
> see initcwnd.
>    

Oh, excellent.  This seems like exactly what I'm after.  (Thanks Stephen 
Hemminger!)

Many thanks

Ed W

  parent reply	other threads:[~2010-07-14 22:05 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-14 10:43 Raise initial congestion window size / speedup slow start? Ed W
2010-07-14 11:58 ` Alan Cox
2010-07-14 15:21 ` Bill Davidsen
2010-07-14 18:15   ` David Miller
2010-07-14 18:48     ` Ed W
2010-07-14 19:10       ` Stephen Hemminger
2010-07-14 21:47         ` Mitchell Erblich
2010-07-14 20:17       ` Rick Jones
2010-07-14 20:39         ` Hagen Paul Pfeifer
2010-07-14 21:55           ` David Miller
2010-07-14 22:13             ` Hagen Paul Pfeifer
2010-07-14 22:19               ` Rick Jones
2010-07-14 22:40                 ` Hagen Paul Pfeifer
2010-07-14 22:52               ` Ed W
2010-07-14 23:01                 ` Hagen Paul Pfeifer
2010-07-14 23:05                   ` Ed W
2010-07-15  3:49               ` Bill Fink
2010-07-15  5:29                 ` H.K. Jerry Chu
2010-07-15 19:51                   ` Rick Jones
2010-07-15 20:48                     ` Stephen Hemminger
2010-07-16  0:23                       ` H.K. Jerry Chu
2010-07-16  9:03                 ` Hagen Paul Pfeifer
2010-07-15 10:33               ` Alan Cox
2010-07-14 22:05           ` Ed W [this message]
2010-07-14 22:36             ` Hagen Paul Pfeifer
2010-07-14 23:01               ` Ed W
2010-07-15  4:12           ` Tom Herbert
2010-07-15  7:48             ` Ed W
2010-07-15 17:36               ` Jerry Chu
2010-07-15  5:09           ` H.K. Jerry Chu
2010-07-15  2:52     ` Bill Fink
2010-07-15  4:51     ` H.K. Jerry Chu
2010-07-16 17:01       ` Patrick McManus
2010-07-16 17:41         ` Ed W
2010-07-17  1:23           ` H.K. Jerry Chu
2010-07-17  0:36         ` H.K. Jerry Chu
2010-07-19 17:08           ` Rick Jones
2010-07-19 22:51             ` H.K. Jerry Chu
2010-07-19 23:42               ` Hagen Paul Pfeifer
2010-07-15 23:14     ` Bill Davidsen
2010-07-14 18:32   ` Ed W
2010-07-15 15:10     ` Bill Davidsen
2010-07-16  2:58 ` Henrique de Moraes Holschuh

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=4C3E34AB.2060405@wildgooses.com \
    --to=lists@wildgooses.com \
    --cc=davem@davemloft.net \
    --cc=davidsen@tmr.com \
    --cc=hagen@jauu.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.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