public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: dormando <dormando@rydia.net>
To: Lars Eggert <lars.eggert@nokia.com>
Cc: Rick Jones <rick.jones2@hp.com>,
	Brian Bloniarz <bmb@athenacr.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: 3 packet TCP window limit?
Date: Thu, 6 May 2010 01:51:24 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LNX.2.00.1005060131110.28957@d> (raw)
In-Reply-To: <0C1FD143-5588-4455-B08F-85ADD19E0E02@nokia.com>

> On 2010-5-5, at 23:31, dormando wrote:
> > The RFC clearly states "around 4k",
>
> no, it doesn't. RFC3390 gives a very precise formula for calculating the initial window:
>
> 	min (4*MSS, max (2*MSS, 4380 bytes))
>
> Please see the RFC for why. More reading at http://www.icir.org/floyd/tcp_init_win.html I believe that Linux implements behavior this pretty faithfully.

Sorry, paraphrasing :) Web nerds have been working around this for a long
time now. Google talks about using HTTP chunked encoding responses to send
an initial "frame" of a webpage in under 3 packets. Which immediately
gives the browser something to render and primes the TCP connection for
more web junk.

> I'm surprised to hear that OpenBSD doesn't follow the RFC. Can you share a measurement? Are you sure the box you are measuring is using the default configuration?

Yeah, default config. OBSD was giving me back 4 packets in the first
window, while linux always gives back 3. The Big/IP is based on linux
2.4.21. If that kernel didn't have it wrong, they tuned it.

Already nuked my dumps. If you're curious I'll re-create.

> I don't think the RFC can be misread (it's pretty clear), and the
> formula is also not exactly complicated. My guess would be that some
> vendors have convinced themselves that using a slightly larger value is
> OK, esp. if they can show customers that "their" TCP is "faster" than
> some competitors' TCPs. An arms race between vendors in this space would
> really not be good for anyone - it's clear that at some point, problems
> due to overshoot will occur.

I clearly remember some vendors bragging about doing this. That was a long
time ago? Perhaps they stopped? If it's true they've been doing it for
half a decade or more, and haven't broken anything someone would notice.

The only reason why I set about tuning this is because our latency jumped
while moving traffic from a commercial machine to a linux machine, and I
had to figure out what they changed to do that. I've since turned the
setting *back* to the standard, having confirmed what they did.

Almost tempted to test this against a bunch of websites...

> (We can definitely argue about whether the current RFC-recommended value
> is too low, and Google and others are gathering data in support of
> making a convincing and backed-up argument for increasing the initial
> window to the IETF. Which is exactly the correct way of going about
> this.)

This sounds like fun. We have some diverse traffic, so I'm hoping we can
contribute to that conversation. Still have a lot of reading to catch up
with first :)

  reply	other threads:[~2010-05-06  8:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-05  9:10 3 packet TCP window limit? dormando
2010-05-05 13:26 ` Brian Bloniarz
2010-05-05 20:01   ` dormando
2010-05-05 20:23     ` Rick Jones
2010-05-05 21:31       ` dormando
2010-05-06  6:15         ` Lars Eggert
2010-05-06  8:51           ` dormando [this message]
     [not found]             ` <p2h349f35ee1005061513x1db24de0ld98a40256c481ac2@mail.gmail.com>
     [not found]               ` <q2ud1c2719f1005061613yf90cd7c6r46ee23cc49858e74@mail.gmail.com>
2010-05-06 23:15                 ` Jerry Chu
2010-05-05 20:56     ` Brian Bloniarz
2010-05-05 22:03       ` Stephen Hemminger
2010-05-06  1:37         ` [PATCH iproute2] document initcwnd Brian Bloniarz
2010-05-06  2:33           ` Stephen Hemminger
2010-05-19 15:31           ` Stephen Hemminger

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=alpine.LNX.2.00.1005060131110.28957@d \
    --to=dormando@rydia.net \
    --cc=bmb@athenacr.com \
    --cc=lars.eggert@nokia.com \
    --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