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

[Simon Barber <[e-mail]>]

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.

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