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