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/[email protected]/). > > 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.
