> • SCE will only work if the bottleneck link implements fq. Some > bottleneck network gear will not be able to implement fq or will not > implement it due to its undesirable side effects (see section 6 of RFC 8290).
> SCE leverages a paragraph in a draft that describes a first guess about how a > congestion controller might work. We have an update in the works that should enable RTT-fair convergence with single-queue AQMs, whether they support SCE or not. To do this using the simplest reasonable adjustments to existing congestion control algorithms, the setpoint is no longer fixed at 50% but varies with the cwnd of each flow. And yes, we have worked out what those adjustments should look like in practice, but we haven't yet had time to run tests, or describe them in a nicely formatted I-D. This update should also allow a very DCTCP-like congestion control algorithm to work correctly with SCE, as long as it acts conventionally with CE marks and only has the reduced response to SCE marks. That's something that DCTCP itself currently does not do. > • SCE’s usage of ECT(1) potentially allows an automatic fallback to > traditional Cubic behavior if the bottleneck link is a single-queue > classic-ECN AQM (do any of these exist?), whereas L4S will need to detect > such a condition via RTT measurement From my standpoint, the major objection to L4S is that it is not incrementally deployable, because DCTCP starves conventional TCPs unless run through an isolated queue. This is something we quickly realised when L4S was first announced. It is simply not practical to require all middleboxes on the path to support L4S before L4S endpoints can safely be deployed, except in the isolated and very controlled environments where DCTCP was "proved". > I find it extremely disappointing that some people on this list are taking > such a negative attitude to the major development in their own field that > they seem not to have noticed since it first hit the limelight in 2015. It is not at all true that we were unaware of L4S. Rather, we quite reasonably believed it would never get traction in the IETF or in the Internet at large unless that problem was robustly solved - and we thought the obvious solution *was* to use ECT(1) as SCE does, and to fix Diffserv (so that it becomes e2e usable to some degree) or implement FQ if isolating low-latency-assured traffic is so important. Incidentally, during that time we were implementing a good FQ system that is now in Linux and in commercial products. Granted, it isn't designed for the sort of high-capacity links where FQ is traditionally considered impractical. > L4S has defined a congestion feedback mechanism so that these congestion > signals can get back to the sender. SCE offers that “we’ll propose something > later”. It should be straightforward to adjust AccECN so that it primarily carries SCE information instead of unnecessarily detailed CE information. That's one obvious solution, which we hoped those already familiar with L4S would recognise without explicit prompting. We have outlines of other feedback methods, still awaiting conversion to the proper document format, including one that doesn't require a new TCP option (I understand there are objections to such things, centred around paranoid firewalls) and which existing middleboxes and endpoints will transparently ignore (like the rest of SCE). It uses the NS bit which was also freed up by the obsoleting of Nonce Sum. The I-D presently available defines the SCE codepoint and very little else. This is due to separation of concerns. Other I-Ds will define feedback mechanisms, detailed modifications to congestion control algorithms, and recommendations as to what AQMs should do. Perhaps if we get a chance to work, instead of responding to manufactured outrage that we dare to propose something different, these extra documents might surface in time for discussion. - Jonathan Morton _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
