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 <swm...@swm.pp.se> 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: swm...@swm.pp.se
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
