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

[Dario Rossi <[e-mail]>]

Hi Dave,  all,

message lost on my inbox  -- no mean to get down to 0-latency in this 
queue :/

I just react on a point

 > I would say that any technology that automatically reduces mean 
latency reduces the need to manage mean latency.
sure, reducing latency (e.g.LEDBAT) is better than increasing it (e.g. 
TCP) until too late (i.e. drop).

except, if you leave in New Zealand and try to make a voip call 
everywhere in the world except New Zealand (or Australia) then those 
extra 100ms of queuing on top of your propagation delay hurts your QoE 
--  not that I care (or call) much New Zealand

hence you will need something (eg. fqcodel if you listen to Dave ;) that 
will make your voip call smooth, but that as side effect reinstates 
fairness among flows, hence increase the aggressiveness of  transfers 
that wants to be background --- if a flow wants to be low priority, why 
not dropping him first?

  the main point in the paper Dave points to is I believe " you cannot 
solve the problem without at least 1 bit of explicit coordination": the 
paper tells that concept with (lot of) simulation and (couple of) 
prototype experiments. we've also extented our control-theoretic 
analysis  that just phrases the same concept more elegantly (under 
journal submission, but can share if of interest)

best,
D.


On 05/21/2015 06:31 PM, Dave Taht wrote:
> 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
>>
>
>

-- 

  Oo    Professor
   >    Telecom ParisTech
  ~     Ecole Polytechnique

mail:  [e-mail]
phone: [phone]
fax:   [phone]
web:   http://www.enst.fr/~drossi