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]

Date:   Sun, 13 Feb 2022 09:50:27 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     Tian Lan <Tian.Lan@...sigma.com>
Cc:     Tian Lan <tilan7663@...il.com>, 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

On Sun, Feb 13, 2022 at 9:37 AM Tian Lan <Tian.Lan@...sigma.com> wrote:
>
> > 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 ????
>
> Just want to clarify, the intent of this patch is not trying to violate the TCP protocol. The goal is to allow the receiver advertise a much "larger" rcv_wnd once the connection is established. So instead of having the receiver grow the rcv_wnd starting with 64KiB, the receiver could advertise the new rcv_wnd based on a much larger initial window.
>
> Sorry for the confusion, happy to chat more if you have questions or concerns.

To be clear, if the sender respects the initial window in first RTT ,
then first ACK it will receive allows a much bigger window (at least
2x),
 allowing for standard slow start behavior, doubling CWND at each RTT>

linux TCP stack is conservative, and wants a proof of remote peer well
behaving before opening the gates.

The thing is, we have this issue being discussed every 3 months or so,
because some people think the RWIN is never changed or something.

Last time, we asked to not change the stack, and instead suggested
users tune it using eBPF if they really need to bypass TCP standards.

https://lkml.org/lkml/2021/12/22/652


>
> -----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 ????