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

[Wesley Eddy <[e-mail]>]

On 5/8/2015 11:42 PM, Simon Barber 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
> 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. 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!
> 
> Secondly, there is a recommendation that AQM be implemented both within
> classes of service, and across all classes of service. This does not
> make sense. 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. This destroys the very unfairness that you wanted
> to achieve by implementing the classes in the first place.
> 


Hi Simon, thanks for your comments.

These comments appear to be in response to version -04 of the document,
from around 1 year ago.  The document is currently on version -11, has
past working group last call and IESG evaluation, and is in the RFC
Editor's queue.  I mention this, because it isn't clear to me how
applicable your comments are with regard to the current copy.

The current copy can be found at:
https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/

The current revision does mention the impact to delay-based end-host
algorithms as an area for future research.

While I agree that in a lot of cases it seems like logically a good
idea to have a DiffServ configuration like you mention, I don't think
we have seen data on this yet in the working group.  Looking into this
could be part of that mentioned future work, though not something I'd
want to see hacked into this document today, so late in its publication
process.

-- 
Wes Eddy
MTI Systems