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) <[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
--
Oo Professor
> Telecom ParisTech
~ Ecole Polytechnique
mail: [email protected]
phone: +33.1.4581.7563
fax: +33.1.4581.7158
web: http://www.enst.fr/~drossi
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
