Scheffenegger, Richard <r...@netapp.com> wrote: > >... At the least when you are using TCP, a drop will cause head-of-line > blocking on the receiver, for at least 1 RTT;
Yes. This is a trade-off: many folks believe that a good AQM has enough benefits for typical TCP flows to overcome that. (YMMV) > Agreed, there are ways to mitigate this (FEC-encoded transports). Indeed. And this is happening. I haven't heard of it happening in TCP itself; but I wouldn't be surprised to hear of implementations which advertise themselves as TCP doing this... FEC does _not_ have to be particularly expensive in bandwidth (though the implementations we hear about mosty are...). > But the "OR" is exactly the correct description here: FEC has inherent > overhead thus reduced bandwidth, and loss-recovery suffers from > head-of-line blocking, Yes. (though there are possible mitigations)... > thus higher latency (to the application, where it actually matters). It depends upon the application, at least partly. The bulk of TCP transport today, we believe, is trying to optimize for quick transport of medium-sized files. We already see "optimizations" which send whole files before looking for feedback. These optimizations seem to be working pretty well... > FQ-Codel runs with high bandwidth, but the drops induce latency in the > end-hosts nevertheless... Yes. But this isn't causing folks to demand their outgoing routers disable FQ-CoDel, etc... > Thus FQ-Codel with ECN would still be more effective than without ECN. Absolutely! And that is where we want to go! -- John Leslie <j...@jlc.net> _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
