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.