Subject: [aqm] AQM in every buffer?

From: Dave Taht <[email-masked]>
Date: Fri, 13 Jun 2014 12:39:26 -0700

In the other long thread, gorry said something that didn't quite ring
true with me:

"Our goal should be AQM in every buffer".

Well, that's somewhat desirable but not doable (at least in my world) -

1) The device has sufficient buffering to get at least one packet out.
2) There's a tx ring which puts packets for the device to pick up from
3) In linux now (and some older cisco boxes) there is this thing
called "byte queue limits" which moderates the tx ring to only have
enough data in it to keep the device busy

4) These layers gives the upper portions of the stack time to think
harder about what to put on the tx ring.

*Ideally* an AQM should have a picture of the total buffering in the
system all the way to the wire, but in practice, at higher speeds,
once things are controlled by BQL, it's a trivial amount of extra
buffering.

(this is partially why I get non-plussed by people dissing "drop head", when
 what's on the TX ring is already past the "drop head" point of the AQM layer )

Now, I imagine that at least some hardware switches *could* have a
picture all the way to the wire, but doubt that it's feasible, also.

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

---

From: [email-masked]
Date: Sun, 15 Jun 2014 07:35:34 +0100

Just to clarify, this was someone else's words from the list. They don't
appear in this ID.

I agree with what you have said below.

I personally think in addition that this isn't desirable, because using
AQM implies enforcing a traffic policy (e.g. with respect to flow
bustiness, no of flows and path RTT), and it would be unfortunate if this
policy were embedded in all equipment, it would in some cases constrain
performance when there is no need. The draft motivates that key params
should be externalised.

Gorry

> Dave TÃ¤ht
> NSFW:
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

---

From: [email-masked]
Date: Sun, 15 Jun 2014 07:36:47 +0100

I personally think in addition that trying to manage every buffer isn't
desirable, because using AQM implies enforcing a traffic policy (e.g. with
respect to flow bustiness, no of flows and path RTT), and it would be
unfortunate if this policy were embedded in all equipment, becasue it
would in some cases constrain performance when there is no need. The draft
motivates that key params should be externalised.

Gorry