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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 6 May 2010 08:15:03 +0200
From:	Lars Eggert <lars.eggert@...ia.com>
To:	dormando <dormando@...ia.net>
Cc:	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?

Hi,

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.

> but these other OS's/products have an
> extra kilobyte snuck in? Could this be on purpose via rfc
> interpretation, or an off by one on the initcwnd estimator? :)

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?

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.

(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.)

Lars
Download attachment "smime.p7s" of type "application/pkcs7-signature" (2490 bytes)