netdev - Re: [PATCH] Add sysctl to set the advertised TCP 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] [day] [month] [year] [list]

Message-ID: <65634d660912091005w127699f7w176cded946a53acc@mail.gmail.com>
Date:	Wed, 9 Dec 2009 10:05:26 -0800
From:	Tom Herbert <therbert@...gle.com>
To:	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH] Add sysctl to set the advertised TCP initial receive 
	window.

On Wed, Dec 9, 2009 at 5:26 AM, Andi Kleen <andi@...stfloor.org> wrote:
> chavey@...gle.com writes:
>
>> Add a sysctl, tcp_init_rcv_wnd, to set the TCP initial receive window
>> size advertised by passive and active TCP connections.
>> The current Linux TCP implementation limits the advertised TCP initial
>> receive window to the one proscribed by slow start. For short leave
>> TCP connections used for transaction type of traffic (i.e. http
>> requests), bounding the advertised TCP initial receive window results
>> in increased latency to complete the transaction. There exists
>> environments where strict adherence to using the TCP initial receive
>> window used by slow start is un-necessary.
>
> That's not the Internet?
>
>> The tcp_init_rcv_wnd sysctl allows increasing the TCP initial receive
>> window for all TCP connections or on a per TCP connection, allowing
>> for some of the TCP connection to advertise larger TCP receive window
>> than the ones bounded by slow start.
>
> Traditionally it was very discouraged to expose such settings to users.
> There's the danger that lots of people will essentially turn off cwnd
> without knowing what they're doing to "make downloads go faster", causing
> problems in the public network.
>

The dangers to the Internet are not exposed on the receiver side but
more on the sender side and its correct adherence to slow start.  A
large majority of clients on the Internet are currently advertising
initial receive windows much higher than 3*MSS (in many cases 64K or
higher), so the impetus is on server side to do the right thing.

Support for setting initial congestion window is already supported in
the stack, but, as has been pointed out this list, it's pretty useless
without the ability to set a larger initial receive window.  If we can
use larger initial congestion windows on private networks that we know
to be essentially uncongested, this can result in reduced
transactional latency by one or more RTTs.  The performance benefits
should be fairly obvious, but we can provide numbers if necessary.

Thanks,
Tom

> -Andi
>
> --
> ak@...ux.intel.com -- Speaking for myself only.
> --
> 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
>
--
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