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

[Dave Taht <[e-mail]>]

On Tue, May 12, 2015 at 9:17 PM, Simon Barber <[e-mail]> wrote:
> 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.

I am glad you are able to put time in, you have been a long way away.

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

There are many ways to do lower priority streams if fq is present.

Simplest:

1) Send
3 packets back to back, timestamped. First packet arrives in an empty
queue, gets sent out immediately, 2nd and third packet are affected by the
total number of flows extant.  (fq_codel) (or in SFQ all are affected by
total number of flows)

keep that to 1/2 OWD (or less) plus fuzz/smoothing and you have a solution
for how much additional load you are willing to add to the network.

2) for coupled congestion control on say 6 flows from one app do the
same sort of bunching and measure,
then drop off when one or more of the flows experiences excessive delay.

In both cases the timestamps would be received differently and in
order via pure aqm or drop tail most of the time.

It is relatively easy to get "low priority" in other words in a fq'd
system. It is harder to get to an optimal bandwidth while still
staying low priority and somewhat hard to figure out if you are being
fq'd in the first place.


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

see dart.

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67