Hi Matt, On Thu, Feb 26, 2026 at 09:12:07AM +0100, Matthieu Baerts wrote: > 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.
Thank you for chiming in; I know that my comments are somewhat provocative. :) > > 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 RFC 8646 has several pointers to RFC 5961 and in section 3.3.5 it says: ... Each of these segments will be mapped onto subflows, as long as subflow sequence numbers are in the allowed windows for those subflows. Note that So, I assume that on sub-flow level we are still supposed to do the standard TCP sequence acceptability checks with respect to the advertised window for the subflow. If so, my concern is that raising rcv_wnd in the RX path means that we may accept sequence numbers that we never advertised in that particular subflow. > > > 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. The issues I see here are: 1. When calculating the usable receive window in TCP, we use 32-bit signed arithmetic. 2. The max. window size with window scaling is around 1GB 3. As said, rcv_wnd is used for acceptability checks. In standard TCP we ensure that rcv_wnd is aligned to the window scaling factor. So, I had assumed to see the "reverse" of the current TX raise window logic in MPTCP: First, calculate the advertised window to put into the outgoing packet and then update rcv_wnd accordingly. > I hope this helps better understanding these modifications, and > hopefully not introducing regressions on the MPTCP side :) Yes, thank you. Regarding regressions, I couldn't agree more. - Simon -- Simon Baatz <[email protected]>
