On Fri, Jul 21, 2017 at 4:27 PM, Lisong Xu <x...@unl.edu> wrote: > > Hi Yuchung, > > This test scenario is only one example to trigger this bug. In general, as > long as cwnd <4, the undo function has this bug.
Yes, personally I agree that this seems like an issue that is general enough to be worth fixing. In the sense that, if cwnd <4, then we may well be very congested. So we don't want to get hit by this bug wherein an undo of a loss recovery can cause cwnd to suddenly jump (from 1, 2, or 3) up to 4. Seems like any of the several CCs that use tcp_reno_undo_cwnd() have this bug. I guess in my mind the only question is whether we want to add a tcp_foo_undo_cwnd() and ca->loss_cwnd to every CC module to handle this issue (i.e. make every CC module handle it the way CUBIC does), or (my preference) just add a tp->loss_cwnd field so we can use shared code in tcp_reno_undo_cwnd() to get this right across all CC modules. neal
