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

[Simon Barber <[e-mail]>]

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.
>