(could we agree to reduce the Cc list on this thread?) Jonathan Morton <chromati...@gmail.com> wrote: >... > What fq_codel does is identify latency-sensitive flows by the fact that > they are not taking up their fair share of the bandwidth. Packets > belonging to these flows are typically delivered *immediately* and > *without loss*.
This is a nice feature; and I certainly don't mean to badmouth fq_codel. But it's guessing... And it depends on those flows being able to know "their fair share" milliseconds in advance: which can fail on short notce. Better would be to identify latency-sensitive flows by a specific signal, and continue to deliver a "fair share" of packets "immediately" and marked to show the congestion. Consider voice traffic. Voice can be intelligible at rather low data rates; but sounds much better at higher data rates. For conferencing uses, low delay is pretty critical. Sudden reductions in data rate are annoying, but unexpected silence while you wait for delayed packets are much worse; and losing track of how much delay there actually is can be fatal. Low-latency is "nice" for all traffic; but I claim it's critical for voice. (Of course, it's "critical" for some other things, too...) +++++++++++++++++ Ideally, each packet would carry an indication of a latency target, beyond which it's less useful and congestion needs to be indicated. I have been very disappointed that we designed IPv6 without leaving space for this. ++++++++++++++++ (Actually, we _did_ originally design for this: TTL was indended to be decremented every second, whether or not forwarded. Alas, this was grossly inadequate resolution; so this usage was abandoned.) -- John Leslie <j...@jlc.net> _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
