On Tue, Mar 13, 2018 at 3:25 AM, Ilpo Järvinen <ilpo.jarvi...@helsinki.fi> wrote: > Here is a series of fixes to issues that occur when SACK is not > enabled for a TCP connection. These are not fixes to just some > remote corner cases of recovery but many/almost all recoveries > without SACK will be impacted by one (or even more than one) of > them. The sender-side changes (1-4) are not mainly, if any, to > improve performance (throughput) but address correctness > (congestion control responses should not get incorrectly > reverted) and burstiness (that may cause additional problems > later as some of the packets in such bursts may get dropped > needing again to resort to loss recovery that is likely > similarly bursty).
GRO (or similar) adoption a long time ago (not only by linux) had a serious impact on non SACK flow. Should we also disable GRO by default ? (my answer is no, just in case someone wonders) I am sorry, but I am still not convinced by your patches, trying to give a wrong incentive to people keeping their prehistoric stacks, that have serious problems on wifi anyway, and or middle boxes "aggregating/compressing ACKS" The last patch is particularly problematic in my opinion, you have not provided packetdrill tests to prove there was no danger. It seems you leave to us the task of dealing with possible issues, only added a bold changelog. Since the bugs you claim to fix are at least 10 years old, and your fixes are far from being trivial, please wait our packetdrill regression tests being published. This should happen in less than one month I believe, in time for linux-4.17 Note that the publication of the updated packetdrill and test suite is not an easy task, since we accumulated a lot of hacks both in kernel to cope with timer slacks and in packetdrill for various experimental or private features that are not yet in upstream kernels. So we are cleaning all this, and will be happy to help you if you need. Thanks.
