Re: [PATCH mptcp-next 2/3] mptcp: sched: do not penalise when receive-window-limited

Hi Matt,

On Wed, 2026-07-29 at 13:49 +0200, Matthieu Baerts wrote:
> Hi Shardul,
> 
> On 26/07/2026 07:55, Shardul Bankar wrote:
> > 
> > +/* Only penalise when the connection is not receive-window-
> > limited: all the
> > + * data the application has queued fits within the current send
> > window
> > + * (write_seq <= wnd_end). If it has queued past the window edge,
> > the peer's
> > + * receive window (not our congestion window) is the bottleneck:
> > the fast
> > + * path is capped by that shared window too and cannot use
> > capacity freed from
> > + * the slow path, so penalising would only shed the slow path's
> > throughput.
> > + *
> > + * write_seq (application demand) and wnd_end (peer-advertised
> > window) are both
> > + * standing values and neither is derived from cwnd, so unlike the
> > instantaneous
> > + * window headroom this is not biased by the scheduler sampling
> > just after an
> > + * ACK opened the window, nor circular when the window is what
> > suppresses cwnd.
> 
> (a bit too long, some text can probably be moved to the commit
> message
> if not there already → but also, I guess this commit will be squashed
> in
> the previous one at the end)
> 

Yes. I kept it separate for now so the guard can be tested on its own,
and I will squash it into 1/4 for the merge-ready version.

> > + */
> > +static bool mptcp_penalise_send_window_ok(const struct mptcp_sock
> > *msk)
> > +{
> > +       return msk->write_seq <= mptcp_wnd_end(msk);
> 
> It looks like you are doing something similar to tcp_snd_wnd_test(),
> no?
> 
> I guess you should at least use after64/before64. Here we don't have
> the
> skb, that might change later if the MPTCP scheduler API is modified,
> but
> that can be an optimisation for later.
> 
> You could name the helper mptcp_snd_wnd_test(), and mention it is
> inspired by the TCP version, but without checking the packet len (for
> the moment).
> 

Yes, renamed to mptcp_snd_wnd_test(), and it uses after64() now.

> Other than that, this Sashiko's comment is interesting:
> 
> > Does this heuristic correctly identify receive-window bottlenecks
> > without
> > unintentionally disabling the penalty for congestion-limited bulk
> > transfers?
> > Because write_seq is limited by the socket send buffer (sk_sndbuf)
> > rather
> > than the congestion window, an application performing a bulk
> > transfer with a
> > large send buffer can easily queue data past the peer's advertised
> > receive
> > window.
> > If the connection is heavily congestion-limited, the fast path is
> > saturated
> > and the slow path should still be penalized to reduce head-of-line
> > blocking.
> > However, since write_seq > mptcp_wnd_end(msk) in this scenario, it
> > seems
> > this check will incorrectly assume the connection is receive-window
> > limited
> > and skip the penalty.
> 
> By chance, did you already validate this case?
> 

Yes, with a send buffer larger than the receive window. The guard
suppresses the penalty there, correctly: the receiver is genuinely at a
zero window, so it is receive-window-limited rather than congestion-
limited, and it is no slower than baseline.

Thanks,
Shardul