Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #1

From: Bob Briscoe <[email-masked]>
Date: Fri, 12 Jul 2013 02:28:34 +0100

Fred,

To save mail header processing, I've ammortised most of my replies. 
Sorry I'm very late.

#1 Operational deployments SHOULD implement AQM
Agree

#2 Signaling to the endpoints of a session
Agree
(and see my note to Dave Taht just now wherein I said we should give 
examples of good and bad approaches. Good: drop at a tight delay cap; 
Bad 100% drop)

#3 Active Queue Management algorithms deployed SHOULD NOT require 
operational tuning
Agree
(and see same note to Dave Taht wherein I said time as a queue 
threshold is not sufficient to get a tick in the auto-tuning box - 
responsiveness of the algo also needs to depend on how bad the queue 
is getting)

#4 AQM deployed SHOULD be effective on all common Internet traffic
Disagree (see next posting: summary: SHOULD allow congestion controls 
to remain as effective as they are with other generally accepted AQMs 
or with tail drop)

#5 TCP and SCTP congestion control algorithms SHOULD maximize ...
Don't disagree, but it's out of scope, as Michael said. The other 
recommendations already say what the AQM side needs to do to try to 
keep at the knee - this recommendation is aimed at transport 
protocols, so it should be cut - not in scope.

#6 Need for further research
Agree

Bob

At 15:00 24/04/2013, Fred Baker (fred) wrote:
>Do we generally agree with the recommendation of 
>http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.1?
>
>
>_______________________________________________
>aqm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Dave Taht <[email-masked]>
Date: Thu, 11 Jul 2013 18:49:59 -0700

Since this is a rollup email, this is a rollup in response.

On Thu, Jul 11, 2013 at 6:28 PM, Bob Briscoe <[email-masked]> wrote:
> Fred,
>
> To save mail header processing, I've ammortised most of my replies. Sorry
> I'm very late.
>

Agree

> #2 Signaling to the endpoints of a session

Agree.

> examples of good and bad approaches. Good: drop at a tight delay cap; Bad
> 100% drop)

Codel stops dropping at the target delay (5ms). Aside from possible
quantization error in the timestamping it's impossible to get to 100%
drop.

I enjoyed your examples of existing approaches and where they went
wrong. I could certainly add more, notably from our efforts in
extending SFQ to higher bandwidths and the SFQ + ARED effort that
preceded fq_codel.

> #3 Active Queue Management algorithms deployed SHOULD NOT require

Agree, but I'd capitalize the REQUIRE bit, in that everything in this
world can benefit from a little tuning here and there...

as one major example, which is in conflict with your byte-congest
draft, using a smaller quantum than the default helps on asymmetric
links in fq_codel (and pie uses a probalistic drop mechanism also
based on packet size). The smaller quantum thing has been well proven
to work on multiple shapers/schedulers going back to wondershaper.

> (and see same note to Dave Taht wherein I said time as a queue threshold is
> not sufficient to get a tick in the auto-tuning box - responsiveness of the
> algo also needs to depend on how bad the queue is getting)

The sqrt->linear drop approach is tcp friendly and currently works
well on a wide range of RTTs. It certainly seems like a worthwhile
research effort to measure and act on the slope of the curve, both up
and down, in a codel variant, in order to get better results faster.

And the results of the hybrid fq_codel are interesting in that
perspective as flows do affect one another, particularly in steady
state. Right now a drop in one queue can be followed quickly by a drop
in another queue (at steady state), and that could be randomized
somewhat or fed into a feedback mechanism also.

I do show this behavior on the rrul vs web traffic benchmark on the
slidesets I've been showing. Note that steady state is something of a
rarity outside of benchmarks.

another thought is to periodically perturb the flow list. sigh. more research.

> Disagree (see next posting: summary: SHOULD allow congestion controls to
> remain as effective as they are with other generally accepted AQMs or with
> tail drop)
>
> recommendations already say what the AQM side needs to do to try to keep at
> the knee - this recommendation is aimed at transport protocols, so it should
> be cut - not in scope.
>

4,5,6 agree. 6, agree strongly, but who will fund it?

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 12 Jul 2013 18:28:42 +0100

Dave,

>to work on multiple shapers/schedulers going back to wondershaper.

Pls elucidate or cite. INsufficient detail to understand. I thought I 
knew what a quantum was in a scheduler, but in these sentences I'm 
wondering whether you're talking about something else.

>and down, in a codel variant, in order to get better results faster.

I've transferred this response over to the separate thread 
specifically about this (rec #2), as I think my points have been missed.

Bob