> On 18 May, 2015, at 15:30, Simon Barber <si...@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 _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
