> On 21 Mar, 2019, at 1:29 am, Bob Briscoe <i...@bobbriscoe.net> wrote: > >> But more importantly, the L4S usage couples the minimized latency use >> case to any possibility of getting a high fidelity explicit congestion >> signal, so the "maximize throughput" use case can't ever get it.
> Eh? There's definitely a misunderstanding or a difference in terminology > between us here. The whole point of using a congestion controller like DCTCP > is so that flow rate can scale indefinitely with capacity. Van Jacobson > actually noted that the original TCP was unscalable in a footnote to the tech > report version of the SIGCOMM paper. > > The high fidelity congestion signal of what we call scalable congestion > controllers (like DCTCP) is inversely proportional to the window. So as > window scales up, the congestion signal scales down, so that their product > remains constant. That means the number of ECN marks per RTT is > scale-invariant. So the control signal remains just as tight at any scale. If you'll indulge me for a moment, I'd like to lay out a compromise scenario where a lot of L4S' stated goals are still met. There is no dualQ. There is an AQM at the bottleneck link, of unspecified type, which implements SCE. Assume that it produces CE marks like a conventional AQM, and also produces SCE marks like an L4S AQM produces CE. A sender implements DCTCP-SCE, which is essentially Paced NewReno modified to subtract half of all acked data that was SCE-marked from its cwnd. (This is equivalent to the DCTCP algorithm with g=1 and an arbitrarily small measurement window, but acting on SCE instead of CE.) Any SCE mark also kicks it out of slow-start. The means by which SCE information gets back to the sender is left vague for now; it's an orthogonal problem with several viable solutions. What is missing from this scenario, from L4S' point of view? And why have I been able to describe it so succinctly? - Jonathan Morton _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
