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

[David Lang <[e-mail]>]

On Mon, 18 May 2015, Simon Barber wrote:

> Thank you Mikeal, these are useful observations about the choice of exact 
> DSCP value and various potential impacts. I agree that ultimately without 
> operator agreement non of this matters. I do think that an important step 
> towards garnering that operator agreement is to have the concerns clearly 
> elucidated in this group's recommendations.
>
> I found a study of the interaction between low priority background 
> techniques, including LEDBAT and AQM.
>
> http://www.enst.fr/~drossi/paper/rossi12conext.pdf
>
> it's conclusion states:
>
> "Shortly, our investigation confirms the negative interference: while AQM 
> fixes the bufferbloat, it destroys the relative priority among Cc protocols."
>
> Apparently a significant chunk of bittorrent traffic and Windows updates use 
> these techniques to deprioritise their traffic. Widespread adoption of AQM 
> will remove their ability to avoid impacting the network at peak times. Use 
> of DSCP could be one way to mitigate this problem with AQM, and this merits 
> further study.

Does it matter? If such traffic doesn't interfere significantly with what the 
user is trying to do in the forground, it shouldn't matter that it's not being 
deprioritized as much.

The big problem before was that such traffic would cause the buffers to build up 
and slow everything down. With AQM in place, that concern basically disappears 
and the only resulting problem would be that you are maxing out the available 
bandwidth unless you deprioritize such traffic.

But if I'm sitting waiting for Windows to download an update, that's now 
forground traffic that is preventing me from doing anything else. I don't want 
it to be deprioritized behind other people in the house doing other things. I 
want it to get it's fair share of bandwidth.

The vast majority of the time, users are going to have enough bandwidth to be 
able to share it with such update mechansims. Those of us stuck on low bandwidth 
links (I'm currently unable to upgrade beyond 3Mb on my DSL line), are going to 
have to accept that when we have multiple things going on, they are going to 
impact each other because the sum of the bandwidth each wants is higher than the 
available bandwidth.

David Lang

> Simon
>
> Sent with AquaMail for Android
> http://www.aqua-mail.com
>
>
> On May 13, 2015 1:47:33 AM Mikael Abrahamsson <[e-mail]> wrote:
>
>> On Tue, 12 May 2015, Simon Barber wrote:
>> 
>> > Hi John,
>> >
>> > Where would be the best place to see if it would be possible to get 
>> agreement
>> > on a global low priority DSCP?
>> 
>> Currently the general assumption among ISPs is that DSCP should be zeroed
>> between ISPs unless there is a commercial agreement saying that it
>> shouldn't. This is generally accepted (there are NANOG mailing list
>> threads on several occasions in the past 5-10 years where this was the
>> outcome).
>> 
>> The problem is quite complex if you actually want things to act on this
>> DSCP value, as there are devices with default behaviour is 4 queue 802.1p,
>> with 1 and 2 (which will match AF1x and AF2x) will have lower priority
>> than 0 and 3 (BE and AF3x), and people doing DSCP based forwarding,
>> usually does things the other way around.
>> 
>> It might be possible to get the last DSCP bits to map into this, because
>> for DSCP-ignorant quipment, this would still be standard BE to something
>> only looking at CSx (precedence), but that would be lower than 000000. So
>> DSCP 000110 (high drop BE) might work, because it's incremental. Possibly
>> DSCP 000010 (low drop BE) might be able to get some agreement because it
>> doesn't really cause any problems in the existing networks (most likely)
>> and it could be enabled incrementally.
>> 
>> I would suggest bringing this kind of proposal to operator organizations
>> and the IETF. It needs to get sold to the ISPs mostly, because in this
>> aspect the IETF decision will mostly be empty hand-waving unless the
>> operators do something.
>> 
>> --
>> Mikael Abrahamsson    email: [e-mail]
>> 
>> _______________________________________________
>> aqm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/aqm
>
>
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>