On Wed, Mar 25, 2026 at 12:58 AM Simon Baatz <[email protected]> wrote: > > Hi Wesley, > > On Tue, Mar 24, 2026 at 02:52:58PM -0600, Wesley Atwell wrote: > > Hi, > > > > This v3 addresses the follow-up review on v2. > > > > Eric pointed out that 1/3 does not need the added packetdrill comment > > and that 2/3 compared signed free_space against an unsigned > > granularity. > > > > This revision drops the extra in-file comment from 1/3 and keeps > > the scaled-window granularity in int space in 2/3 so the comparison > > stays type-safe. The overall approach and reproducer remain unchanged > > from v2. > > > > Simon was right that the original 3/3 only showed the explicit > > rcv_ssthresh-limited ALIGN-up behavior. For v2, 3/3 was replaced with > > an OOO-memory-based reproducer that first grows rcv_ssthresh with > > in-order data and then drives raw backed free_space below > > rcv_ssthresh without advancing rcv_nxt. In the instrumented > > old-behavior run that shaped this test, the critical ACK reached > > free_space=86190, rcv_ssthresh=86286, and still advertised 87040 > > (85 << 10). With 2/3 applied, the same ACK stays at 84. > > > > That follow-up also clarified why the broader 2/3 change is required. > > A narrower variant that preserved the old rcv_ssthresh-limited ALIGN-up > > behavior was not sufficient: earlier ACKs still stored 85 in tp->rcv_wnd, > > and tcp_select_window() later preserved that extra unit because shrinking > > was disallowed. Keeping tp->rcv_wnd representable across the scaled > > no-shrink path is what lets later ACKs settle at the correct > > wire-visible edge. > > So, you are saying that 84 defines the "correct > wire-visible edge"? That's a strong claim. > > The test in 3/3 adds OOO packets until the window calculated from > free_space is 84. But why stop there? If I added further OOO > packets until the calculated window drops to 83, I can claim, by the > same reasoning, that 83 is the correct value and the initial 84 is > wrong. > > In other words, this is a very synthetic scenario that can be steered > to arbitrary values. As stated in v1, I would really like to see a > packetdrill (or real-world scenario) where the old behavior actually > hurts (after all, this series claims that the current behavior needs > to be fixed). >
This series seems to be a social engineering experiment. Could we have the prompts that were fed to an AI agent ? I really do not see the point. RWIN is by essence advisory, and TCP cannot accept arbitrary bloated (small skb->len / skb->truesize ratio) anyway.
