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

[Dave Taht <[e-mail]>]

On Thu, May 21, 2015 at 8:33 AM, Fred Baker (fred) <[e-mail]> wrote:
>
>> On May 18, 2015, at 8:27 AM, Simon Barber <[e-mail]> wrote:

I don't think the authors of the paper under discussion are on the aqm
list, cc'd. lastest version:

http://perso.telecom-paristech.fr/~drossi/paper/rossi14comnet-b.pdf

>>
>> "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.

Heh. The language was less moderate in the first drafts, and I never
got them to put in "and destroying the relative priority between the
CC protocols doesn't matter because aqm reduces overall delays far
below the current ledbat targets". :) The ledbat folk would certainly
like to see delay based cc take over from loss based....

And in all cases, slow start (e.g. web) behaviors relative to the
traffic types has been inadequately documented.

And there are two issues at play here, intertwined. One is reducing
the delays, and the other is reducing the bandwidth share of the lower
priority protocol to a scavenging state. Of these the latter is (now)
more interesting than it used to be.

> 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.

I make a clear distinction between ledbat the single flow cc algo, and
bitorrent the swarming protocol. Originally the ledbat-ers tried for
25ms induced delay, and failed to get there with the underlying OS and
queuing facilities, settling on 100ms. I wouldn't mind seeing newer
things like pacing, spreading, and reduced iws tried for the former,
and that, and coupling for the latter.

>
> 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.

Agree.

Delay gradient TCP just got a writeup in lwn.net btw. haven't read it yet.

I would like it if there were more work into "delay based ccs in a aqm
or fq" environment, building on the tools in the paper referenced
above.

> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67