Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt

["Fred Baker (fred)" <[e-mail]>]

> On May 18, 2015, at 8:27 AM, Simon Barber <[e-mail]> wrote:
> 
> "Shortly, our investigation confirms the negative interference: while AQM fixes the bufferbloat, it destroys the relative priority among Cc protocols."

I think I would phrase that a little differently.

The concept of rearranging traffic in a queue - prioritizing it, deprioritizing it, making it proceed at some rate, and so on - depends on the system in question making choices. It can only make choices when it has multiple things to choose among. Even if a queue consistently has only two waiting elements, it has the opportunity to make choices. However, it also has less need to - if the objective was to reduce jitter (which is why we prioritize voice-on-IP), a shallow queue already has that effect.

In addition, we are talking about stochastic systems, the kind that Kleinrock studied and wrote about. AQM, LEDBAT, CalTech FAST, and so on each moderate the behavior of a data stream so that the inter-arrival intervals approximate mean observed departure intervals, and manage the arrival rate of traffic such that the math tells us that the queues will be less full. A side-effect of doing so, in the Internet, is that queues occasionally completely empty.

I would say that any technology that automatically reduces mean latency reduces the need to manage mean latency. LEDBAT, Delay-based TCP/SCTP congestion control technologies like CalTech FAST, and various AQM technologies all have that property.