netdev - Re: [PATCH 1/1] TCP: increase default initial receive window.

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:	Mon, 20 Dec 2010 10:26:20 -0800
From:	Rick Jones <rick.jones2@...com>
To:	Stephen Hemminger <shemminger@...tta.com>
CC:	Nandita Dukkipati <nanditad@...gle.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	therbert@...gle.com, chavey@...gle.com, ycheng@...gle.com
Subject: Re: [PATCH 1/1] TCP: increase default initial receive window.

> Agree this is a good idea, but some further notes:
>   * The control of receive window is a local function not covered by
>     RFC.
>   * Linux manipulates receive window automatically, unlike some other
>     implementations.
> 
> But any change to TCP risks breaking other broken implementations
> and users need a good way to recover. 

Always good to be careful, but break in what way?  Many stacks have been 
advertising an initial receive window of well above 10 segments going back 
literally decades.

HP-UX systems have been advertising a default/initial recieve window of 32768 
bytes since the mid 1990s, Solaris systems have been advertising a default 
receive window of 49152 for ages.  I cannot speak to Windows' default advertised 
window.  While that sound a bit like "But MOM! All my friends are doing it." it 
does seem to suggest that advertising an initial receive window of 10 segments 
is unlikely to uncover anything new.

rick jones
--
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