From: Jonathan Morton <chromatix99@gmail.com>
To: Simon Barber <simon@superduper.net>
Cc: "Klatsky, Carl" <carl_klatsky@cable.comcast.com>,
cake@lists.bufferbloat.net, "Eggert, Lars" <lars@netapp.com>,
cerowrt-devel@lists.bufferbloat.net,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems
Date: Mon, 18 May 2015 18:03:45 +0300 [thread overview]
Message-ID: <73098C19-53F3-4638-BA7A-D335BF2D26A1@gmail.com> (raw)
In-Reply-To: <14d67011de0.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net>
> On 18 May, 2015, at 15:30, Simon Barber <simon@superduper.net> wrote:
>
> implementing AQM without implementing a low priority traffic class (such as DSCP 8 - CS1) will prevent solutions like LEDBAT from working
I note that the LEDBAT RFC itself points out this fact, and also that an AQM which successfully “defeats” LEDBAT in fact achieves LEDBAT’s goal (it’s in the name: Low Extra Delay), just in a different way.
There’s a *different* reason for having a “background” traffic class, which is that certain applications use multiple flows, and thus tend to outcompete conventional single-flow applications. Some of these multiple-flow applications currently use LEDBAT to mitigate this effect, but in an FQ environment (not with pure AQM!) this particular effect of LEDBAT is frustrated and even reversed.
That is the main reason why cake includes Diffserv support. It allows multiple-flow LEDBAT applications to altruistically move themselves out of the way; it also allows applications which are latency-sensitive to request an appropriate boost over heavy best-effort traffic. The trick is arrange such boosts so that requesting them doesn’t give an overwhelming advantage to bulk applications; this is necessary to avoid abuse of the Diffserv facility.
I think Cake does achieve that, but some day I’d like some data confirming it. A test I happened to run yesterday (involving 50 uploads and 1 download, with available bandwidth heavily in the download’s favour) does confirm that the Diffserv mechanism does its job properly when asked to, but that doesn’t address the abuse angle.
NB: the abuse angle is separate from the attack angle. It’s always possible to flood the system in order to degrade service; that’a an attack. Abuse, by contrast, is gaming the system to gain an unfair advantage. The latter is what cake’s traffic classes are intended to prevent, by limiting the advantage that misrepresenting traffic classes can obtain. If abuse is inherently discouraged by the system, then it becomes possible to *trust* DSCPs to some extent, making them more useful in practice.
For some reason, I haven’t actually subscribed to IETF AQM yet. Perhaps I should catch up.
- Jonathan Morton
next prev parent reply other threads:[~2015-05-18 15:04 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-14 19:13 [Cerowrt-devel] " Dave Taht
2015-05-15 2:48 ` Greg White
2015-05-15 4:44 ` Aaron Wood
2015-05-15 8:18 ` [Cerowrt-devel] [Bloat] " Eggert, Lars
2015-05-15 8:55 ` Sebastian Moeller
2015-05-15 11:10 ` [Cerowrt-devel] [Cake] " Alan Jenkins
2015-05-15 11:27 ` [Cerowrt-devel] " Bill Ver Steeg (versteb)
2015-05-15 12:19 ` Jonathan Morton
2015-05-15 12:44 ` Eggert, Lars
2015-05-15 13:09 ` Bill Ver Steeg (versteb)
2015-05-15 13:35 ` Jim Gettys
2015-05-15 14:36 ` Simon Barber
2015-05-18 3:30 ` dpreed
2015-05-18 5:06 ` Simon Barber
2015-05-18 9:06 ` Bill Ver Steeg (versteb)
2015-05-18 11:42 ` Eggert, Lars
2015-05-18 11:57 ` luca.muscariello
2015-05-18 12:30 ` Simon Barber
2015-05-18 15:03 ` Jonathan Morton [this message]
2015-05-18 15:09 ` dpreed
2015-05-18 15:32 ` Simon Barber
2015-05-18 17:21 ` [Cerowrt-devel] [Cake] " Dave Taht
2015-05-18 15:40 ` [Cerowrt-devel] " Jonathan Morton
2015-05-18 17:03 ` Sebastian Moeller
2015-05-18 17:17 ` Jonathan Morton
2015-05-18 18:14 ` Sebastian Moeller
2015-05-18 18:37 ` Dave Taht
2015-05-19 16:25 ` [Cerowrt-devel] [Cake] " Sebastian Moeller
2015-05-15 16:59 ` [Cerowrt-devel] " Dave Taht
2015-05-15 17:47 ` [Cerowrt-devel] " Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=73098C19-53F3-4638-BA7A-D335BF2D26A1@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cake@lists.bufferbloat.net \
--cc=carl_klatsky@cable.comcast.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=lars@netapp.com \
--cc=simon@superduper.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox