netdev - Re: 3 packet TCP window limit?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Thu, 6 May 2010 16:15:52 -0700
From:	Jerry Chu <hkchu@...gle.com>
To:	dormando <dormando@...ia.net>
Cc:	Lars Eggert <lars.eggert@...ia.com>,
	Rick Jones <rick.jones2@...com>,
	Brian Bloniarz <bmb@...enacr.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: 3 packet TCP window limit?

From: dormando <dormando@...ia.net>
>
> Date: Thu, May 6, 2010 at 1:51 AM
> Subject: Re: 3 packet TCP window limit?
> To: Lars Eggert <lars.eggert@...ia.com>
> Cc: Rick Jones <rick.jones2@...com>, Brian Bloniarz
> <bmb@...enacr.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>
>
>
> > 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 :)

Yes please do.  Our presentation at Anaheim IETF can be found at
http://www.ietf.org/proceedings/10mar/slides/tcpm-4.pdf, with a paper describing
the details of our experiments at
http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf.

We've gotten a lot of feedback from IETF and are planning to collect
more data to
justify the proposal. But at this point we really need help from
others as the scope of
the work is certainly not a one-company job. Help can be in the form of more
experiments/tests and/or simulations to study the effect of a larger
initcwnd. Please
contact me directly or send your data to IETF's TCPM WG list
(http://www.ietf.org/mail-archive/web/tcpm/current/maillist.html).

Thanks,

Jerry
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html