netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Heffner <jheffner@psc.edu>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Mark Lord <lkml@rtr.ca>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: 2.6.17: networking bug??
Date: Tue, 13 Jun 2006 14:28:03 -0400	[thread overview]
Message-ID: <448F03B3.5040501@psc.edu> (raw)
In-Reply-To: <Pine.LNX.4.64.0606131048550.5498@g5.osdl.org>

Linus Torvalds wrote:
> 
> On Tue, 13 Jun 2006, John Heffner wrote:
>> The best thing you can do is try to find this broken box and inform its owner
>> that it needs to be fixed.  (If you can find out what it is, I'd be interested
>> to know.)  In the meantime, disabling window scaling will work around the
>> problem for you.
> 
> Well, arguably, we shouldn't necessarily have defaults that use window 
> scaling, or we should have ways to recognize automatically when it 
> doesn't work (which may not be possible).
> 
> It's not like there aren't broken boxes out there, and it might be better 
> to make the default buffer sizes just be low enough that window scaling 
> simply isn't an issue.
> 
> I suspect that the people who really want/need window scaling know about 
> it, and could be assumed to know enough to raise their limits, no?
> 
> 		Linus

Unfortunately, there's really no way to detect this, at least not until 
it's too late.  You can't un-negotiate window scale after the connection 
is initiated.

64k buffers, the largest you can use without window scaling, are 
adequate for most home users on DSL or cable modems (good to about 10 
Mbps across the US, not quite that over trans-oceanic links). 
Unfortunately, that's about a factor of ten too small for that average 
university user, and a factor of 100-1000 too small for high end use. 
Check out the figure at 
<http://people.internet2.edu/~ghb/pmwiki/pmwiki.php/BridgingTheGap/BtGWizGap>, 
which has some data points.  (The bottom line is the best "normal" users 
can get with system default buffers, the top line is what high-end users 
have gotten with tuned systems over the wide area.  Note that this gap 
is increasing at an exponential rate.)

In the last couple years, we've added code that can automatically size 
the buffers as appropriate for each connection, but it's completely 
crippled unless you use a window scale.  Personally, I think it's not a 
question of *whether* we have to start using a window scale by default, 
but *when*.  I don't know that we want to let a small number of 
unambiguously broken middleboxes kill our forward progress.

Though I haven't gotten my hands on it, I believe Windows will soon have 
this capability, too.  I'm sure Windows is big enough that whenever they 
turn this on, it will flush out all these boxes pretty quickly.  We 
could wait for them to do it first, that that's not my favored approach.

BTW, as one data point, I've been personally running with a large window 
scale for about 5 years, and only seen a small handful of problems, most 
of which were corrected fairly quickly after I sent email to the admin 
of the box in question.  No "big" sites have been an issue.

Thanks,
   -John

  parent reply	other threads:[~2006-06-13 18:28 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <448EC6F3.3060002@rtr.ca>
     [not found] ` <448ECB09.3010308@rtr.ca>
2006-06-13 15:00   ` 2.6.17: networking bug?? Mark Lord
2006-06-13 15:28     ` Mark Lord
2006-06-13 16:58       ` Mark Lord
2006-06-13 17:22         ` Mark Lord
2006-06-13 17:39           ` John Heffner
2006-06-13 17:50             ` Linus Torvalds
2006-06-13 18:26               ` Mark Lord
2006-06-13 19:08                 ` Mark Lord
2006-06-13 21:26                   ` David Miller
2006-06-13 21:49                     ` Mark Lord
2006-06-13 22:12                       ` Rick Jones
2006-06-13 22:23                       ` David Miller
2006-06-13 22:40                         ` Rick Jones
2006-06-13 23:01                           ` David Miller
2006-06-14  1:25                           ` John Heffner
2006-06-13 23:22                       ` Matt Mackall
2006-06-19  7:07                       ` Helge Hafting
2006-06-14  5:18                     ` Andi Kleen
2006-06-14  8:09                   ` Daniel Drake
2006-06-13 18:28               ` John Heffner [this message]
2006-06-13 20:45                 ` Barry K. Nathan
2006-06-13 22:09                 ` Chase Venters
2006-06-13 22:23                   ` David Miller
2006-07-02 17:39             ` Jan Knutar

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=448F03B3.5040501@psc.edu \
    --to=jheffner@psc.edu \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@rtr.ca \
    --cc=netdev@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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).