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

[Simon Barber <[e-mail]>]

Hi John,

Where would be the best place to see if it would be possible to get 
agreement on a global low priority DSCP?

In the latest draft:

https://tools.ietf.org/html/draft-ietf-aqm-recommendation-11

Top of page 16, line 3 it says "AQM should be applied across the classes 
or flows as well as within each class or flow"

It does also say "AQM mechanisms need to allow combination with other 
mechanisms, such as scheduling, to allow implementation of policies for 
providing fairness between different flows."

But I'm still not happy with the statement that AQM should be applied 
'across the classes'.

Simon


On 5/9/2015 6:58 PM, John Leslie wrote:
> Simon Barber <[e-mail]> wrote:
>> I have a couple of concerns with the recommendations of this document as
>> they stand. Firstly - implementing AQM widely will reduce or even
>> possibly completely remove the ability to use delay based congestion
>> control in order to provide a low priority or background service.
>     I agree that if AQM succeeds in reducing delay, that will reduce
> the delay variation that "low priority" services depend upon.
>
>     However, that strikes me a a problem that delay-based congestion-
> control services will have to deal with regardless of AQM.
>
>     Wouldn't we be better off to figure out how AQMs could signal what
> these delay-based services actually care about?
>
>> I think there should be a recommendation that if you are implementing
>> AQM then you should also implement a low priority service using DSCP,
>> e.g. CS1.
>     I don't follow how that could help in practice, except for the case
> where the AQM is implemented _very_ near the sender. (DSCP gets lost
> pretty quickly at Autonomous System boundaries.)
>
>> This will enable these low priority applications to continue to
>> work in an environment where AQM is increasingly deployed. Unlike
>> DSCPs that give higher priority access to the network, a background
>> or low priority DSCP is not going to be gamed to get better service!
>     (I wish I believed we could get agreement to do this!)
>
>> Secondly, there is a recommendation that AQM be implemented both within
>> classes of service, and across all classes of service.
>     I'm not finding this in the document: "Quality of Service" is found
> in Section 2.1; but that's not "class of service". "Traffic class" is
> found in Sections 2.1 and 4.4, neither of which mentions "across all
> classes."
>
>     ???
>
>> This does not make sense.
>     Agreed.
>
>> If you are implementing AQM across multiple classes of service, then you
>> are making marks or drops while ignoring what class the data belongs to.
>     Alas, that doesn't make sense either. :^(
>
>> This destroys the very unfairness that you wanted to achieve by
>> implementing the classes in the first place.
>     That's a funny way to phrase it...
>
> --
> John Leslie <[e-mail]>