[Cerowrt-devel] Cerowrt-devel Digest, Vol 44, Issue 24
chromatix99 at gmail.com
Mon Jul 20 03:51:58 EDT 2015
> On 20 Jul, 2015, at 10:17, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> On Sun, 19 Jul 2015, Jonathan Morton wrote:
>> In the current version, a bandwidth threshold is used instead. If the traffic in the class remains below the threshold, then they get the (non strict) priority requested. If it strays above, the priority is demoted below other classes instead. In the absence of competing traffic, any class can use the full available bandwidth, but there's always room for other classes to start up.
> I had an idea of using DSCP 000xx0 and have a BE+, BE and BE-. BE+ would be scheduled to send packets twice as often as BE, and BE- would be 1/10th of (BE+ BE).
> I keep getting pushback from the DSCP authors that he BE- idea wouldn't be a problem (and they agree that it makes sense for a scavenger class), but that my idea of BE+ should be something else, for instance AFxy. I don't believe anything that isn't 000xxx will ever get widely deployed for Internet use, and there should be no strict priority but just a slight preference for scheduling packets with the BE+ code point, exactly to make DDOS less of an impact.
> What is your opinion on this concept?
I could add support for, say, DSCP 000110 mapping to the Background class with one line of code in Cake; that would give it the same treatment as CS1 currently gets. The legacy TOS codepoints 000001 and 000100 (Low Delay and High Reliability) already map to the Video class; I’ve deliberately left 000010 (High Throughput) in the Best Effort class.
In effect, that would give very similar behaviour to what you suggest. Assuming the link is saturated with all three classes of traffic, three-quarters of the bandwidth would be dedicated to the Video class, three-quarters of the remainder would be Best Effort, and just one-sixteenth would be Background.
Additionally, there is already *some* traffic routinely using CS6 (eg. NTP) and EF codepoints, which I think are relatively well-established as “low throughput, low latency” indicators. Those both go in the Voice class in Cake, which is thresholded at one-quarter of the link. If all four classes are saturating the link, that would just reduce the Video class’s share to one-half instead of three-quarters, leaving the remaining two classes alone.
More generally, using unconditional strict priority for anything is a Very Bad Idea - as noted, it’s just too easy to abuse.
- Jonathan Morton
More information about the Cerowrt-devel