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

[Dave Taht <[e-mail]>]

On Mon, May 18, 2015 at 8:27 AM, Simon Barber <[e-mail]> 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

That paper was continually extended and revised. (I have had very
little to do with it since the first release.)

http://perso.telecom-paristech.fr/~drossi/paper/rossi14comnet-b.pdf

While it is pretty good... my fav part of that paper is table 3 where
the authors ignore the 7 second delay on the link but otherwise
showing the optimal ratio between real tcp and utp in their testbed.

LEDBAT was probably my first concern and area of research before
entering this project full time. I *knew* we were going to break
ledbat, but the two questions were:

how badly? (ans: pretty badly)
and did it matter? (not that much, compared to saving seconds overall
in induced delay)

> it's conclusion states:
>
> "Shortly, our investigation confirms the negative interference: while AQM
> fixes the bufferbloat, it destroys the relative priority among Cc
> protocols."

Yep.

I do wish the paper was updated to account for 4 concepts

0) never got around to trying ns2/ns3 fq_codel or the sqm_scripts against it
1) utp has a lower IW. With the move to IW10 in linux tcp iw10 tcp
knocks utp more out of the way (note that a ton of torrent clients
still use tcp and thus they are getting an "advantage" now by using
iw10 that they shouldn't be). Anyway, most web traffic knocks utp out
of the way handily
2) ledbat when first proposed had a 25ms target for induced delay. I
would not mind that tried again.
3) coupled congestion control (one app, many flows)

> Apparently a significant chunk of bittorrent traffic and Windows updates use
> these techniques to deprioritise their traffic.

So, torrent and ledbat are different things. torrent has LOTS of flows
(worst case 6 active/torrent, (50 or more connected, and switching one
into an active state every 15 seconds)).

ledbat is just a cc algorithm that torrent and some other heavy apps use.

> Widespread adoption of AQM
> will remove their ability to avoid impacting the network at peak times.

No. A single ledbat flow will behave like a single tcp flow.
Widespread adoption of AQM will make it easier for many flows to share
the network with low latency.
I don't see any impact from continued use of ledbat for applications
like updates, backups, etc.

My own recomendation is merely to try torrent today with your aqm or
fq system of choice and see what happens. I did, and stopped worrying
about ledbat.

> Use
> of DSCP could be one way to mitigate this problem with AQM, and this merits
> further study.

while we have long recommended CS1 be set on torrent, it turns out
that a lot of gear actually prioritizes that over BE, still. It helps
on the outbound where you can still control your dscp settings.
Many torrent users have reported just setting their stuff to max
outbound and rate limiting inbound, and observing no real effects on
their link.


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



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

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