"De Schepper, Koen (Koen)" <[email protected]> writes:
> Reporting the self inflicted delay on greedy flows might be a good > measurement to additionally report in the test suites, so its impact > on greedy interactive applications can be estimated. Some sort of greedy real-time media or equivalent is definitely missing from my suite of tests. However, that is partly due to the lack of a good tool to do it with; preferably one that actually matches real deployed applications (webrtc for instance), and that doesn't require either synchronised clocks, packet dumps, or inspecting the router queues while running. On the page I linked to there are packet dumps available from my tests, btw, in case anyone does want to go extract some of these figures from them... > I expect also that the advantage of FQ in general will becomes less > relevant if the queue of all flows in the network are very small and > even most of the time empty. This is what you see already when a low > latency configured AQM is combined with FQ. The lower the latency in > the queues the less the impact of FQ. FQ might still have an advantage > in case of dynamics where a queue build up cannot be avoided. Well, I haven't yet seen an AQM that can keep the queue "very small and even most of the time empty" in the presence of (e.g.) the RRUL test. Especially not during the period where the flows start up (or, roughly equivalent, if the bandwidth changes very rapidly). FQ helps a lot here, especially for the transients. -Toke _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
