netdev - RE: [PATCH] tcp: allow the initial receive window to be greater than 64KiB

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: <9bd37d176e29457885588b36cfcee292@exmbdft6.ad.twosigma.com>
Date:   Sun, 13 Feb 2022 04:43:53 +0000
From:   Tian Lan <Tian.Lan@...sigma.com>
To:     Eric Dumazet <edumazet@...gle.com>, Tian Lan <tilan7663@...il.com>
CC:     netdev <netdev@...r.kernel.org>,
        Andrew Chester <Andrew.Chester@...sigma.com>
Subject: RE: [PATCH] tcp: allow the initial receive window to be greater than
 64KiB

Hey Eric,

Thanks for the comment. I agree with you that this change will not make receiver advertise a larger rwnd in the 3WHS. But I think it can help on the rwnd scaling after the first RTT (the receiver would advertise new rwnd based on a much larger rcv_ssthresh).

From our benchmark testing (mostly for data < 4MiB), it seems like that the sender was mostly waiting on the receiver to scale up the receive window. For network with high latency, this is very costly even we try to set a large initial cwnd to take advantage of full rwnd window advertised initially. I'm happy to discuss other alternatives if you think there are better options to scale up rwnd much more aggressively.

-Best
Tian

-----Original Message-----
From: Eric Dumazet <edumazet@...gle.com> 
Sent: Saturday, February 12, 2022 11:23 PM
To: Tian Lan <tilan7663@...il.com>
Cc: netdev <netdev@...r.kernel.org>; Andrew Chester <Andrew.Chester@...sigma.com>; Tian Lan <Tian.Lan@...sigma.com>
Subject: Re: [PATCH] tcp: allow the initial receive window to be greater than 64KiB

On Sat, Feb 12, 2022 at 8:06 PM Tian Lan <tilan7663@...il.com> wrote:
>
> From: Tian Lan <Tian.Lan@...sigma.com>
>
> Commit 13d3b1ebe287 ("bpf: Support for setting initial receive 
> window") introduced a BPF_SOCK_OPS option which allows setting a 
> larger value for the initial advertised receive window up to the 
> receive buffer space for both active and passive TCP connections.
>
> However, the commit a337531b942b ("tcp: up initial rmem to 128KB and 
> SYN rwin to around 64KB") would limit the initial receive window to be 
> at most 64KiB which partially negates the change made previously.
>
> With this patch, the initial receive window will be set to the 
> min(64KiB, space) if there is no init_rcv_wnd provided. Else set the 
> initial receive window to be the min(init_rcv_wnd * mss, space).

I do not see how pretending to have a large rcvwin is going to help for passive connections, given the WIN in SYN and SYNACK packet is not scaled.

So this patch I think is misleading. Get over it, TCP has not been designed to announce more than 64KB in the 3WHS.

The only way a sender could use your bigger window would be to violate TCP specs and send more than 64KB in the first RTT, assuming the receiver has in fact a RWIN bigger than 64K ????