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]
Message-Id: <0C1FD143-5588-4455-B08F-85ADD19E0E02@nokia.com>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ