On Thu, May 21, 2015 at 8:33 AM, Fred Baker (fred) <[email protected]> wrote: > >> On May 18, 2015, at 8:27 AM, Simon Barber <[email protected]> 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 > [email protected] > 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 _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
