Hi Wesley,
Thanks for considering my comments, and apologies for being so late in
the process - I've only recently been able to put time into this area,
and I understand it may be too late in the process to hack things in. I
replied to John with where I'm concerned with the current -11 text.
Re: background / low priority streams. There are other ways to achieve a
'lower priority', such as changing the AIMD parameters. Does not help if
FQ is involved though. My concern is that implementing AQM removes a
capability from the network, so doing so without providing a mechanism
to support low priority is a negative for certain applications (backups,
updates - and the impact these have on other applications). Would be
good for this to be at least common knowledge. Is there any other
document this could go in?
Simon
On 5/12/2015 5:11 PM, Wesley Eddy wrote:
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.
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
