Re: [PATCH RFC net-next v2 0/5] tcp: RFC 7323-compliant window retraction handling

[Matthieu Baerts <matttbe@kernel.org>]

Hi Simon,

On 26/02/2026 01:49, Simon Baatz via B4 Relay wrote:
> this series implements the receiver-side requirements for TCP window
> retraction as specified in RFC 7323 and adds packetdrill tests to
> cover the new behavior.

Thank you for looking at that.

> It addresses a regression with somewhat complex causes; see my message
> "Re: [regression] [PATCH net-next 7/8] tcp: stronger sk_rcvbuf checks"
> (https://lkml.kernel.org/netdev/aXaHEk_eRJyhYfyM@gandalf.schnuecks.de/).
> 
> Please see the first patch for background and implementation details.
> 
> This is an RFC because a few open questions remain:

(...)

> - MPTCP seems to modify tp->rcv_wnd of subflows. And the modifications
>   look odd:
> 
>   1. It is updated in the RX path. Since we never advertised that
>      value, we shouldn't need to update rcv_mwnd_seq.

FYI, with MPTCP the received windows are shared between subflows. This
might be surprising, but maintaining per-subflow receive windows could
end up stalling some subflows while others would not use up their
window. For more details, please check this section of the RFC:

  https://datatracker.ietf.org/doc/html/rfc8684#sec_rwin

>   2. In the TX path, there is:
>   
>      tp->rcv_wnd = min_t(u64, win, U32_MAX);
> 
>      To me, that looks very wrong and that code might need to be fixed
>      first.
The capping is explained because the MPTCP-level ack seq is on 64-bit,
while the TCP level receive window is on 32-bit.

I hope this helps better understanding these modifications, and
hopefully not introducing regressions on the MPTCP side :)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.