[Flent-users] DSCP / ToS
peteheist at gmail.com
Mon Feb 19 11:01:40 EET 2018
> On Feb 18, 2018, at 9:03 PM, Sebastian Moeller <moeller0 at gmx.de> wrote:
> Really, I am always confused by this especially since I aways forget whether network order is big or little endian (looked it up again it is big-endian).
Here I got nailed by assuming that ECN being in bits 6 and 7 was based on LSB 0 bit numbering… :)
>> Most OS and application vendors would mark their bulk traffic, and ISPs would be more than happy to honor it. As it stands today I guess most ISPs ignore the DSCP value from customer traffic, and DSCP is probably most useful on home routers and APs, for example, to select the right WMM access category. Right, or wrong?
> Well, as far as I ca tell DSCPs are only ever valid inside a DSCP domain, so in effect one can not trust incoming DSCPs blindly. One RFC I read, but I forgot which, proposed to split the 6 DSCP bits evenly between endpoints and intermediate hops, so that the endpoints could use 3 bits to signal their intent, while the intermediate hops could use the other 3 bits to actually store their transient markings somewhere. Which sounds like a great plan if one is willing to accept that 8 different priority categories are probably enough for getting the most advantage of using different priorities (sort of assuming that it will lead to diminishing returns after that). That view is somewhat backed by WMM just using 4 priority classes, and VLAN tags also just using 3 bits (which some switches evaluate in real-time).
>> And in general, should ISPs de-prioritize traffic marked CS1 (0x10)?
> Realistically they could at least offer their customers one DSCP marking which they will interpret as back ground/bulk. But doing that by default has issues as per RFC DSCPs do not carry intent between DSCP-domains and any intermediary hop might re-map say EF to BK (which is still RFC conform), so this is a bit approximate (unless everybody agrees to a) interpret CS1 as background and b) promises to never ever re-map anything to BK that is from outside the local DSCP-domain, but I digress). Well, that or people agree on the 3bit/3bit split so that each DSCP-domain on ingress would look at the three intent bits and remap the transport bits to whatever it believes to be appropriate (which as intent is conserved, might well be the 3 bit BK equivalent).
> BUT unless and until applications start to offer their users to effortlessly configure DSCP markings all of this is somewhat moot ;)
And they don’t because they’re not consistently treated. What I learned by blowing a good part of a Sunday reading RFCs was mostly summed up later by Toke writing “DiffServ is a mess.” Although we can’t ignore the consequences.
I liked the simplicity of RFC 795 (https://tools.ietf.org/html/rfc795) from 1981 :) so, mostly in jest, I’ll propose a new system, call it "Deferential Services", summed up by this:
- Bits 0-2: Anti-precedence: 000 = normal, 111 = least important
- Bit 3: 0 = normal delay, 1 = high delay ok
- Bit 4: 0 = normal reliability, 1 = low reliability ok
- Bit 5: Always 1, identifies deferential services, rarely used for DiffServ in practice, I think
- Bits 6-7 ECN
Bit 5 will usually be 0 so deferential services won’t be used, and if it happens to be 1 for the wrong reason, 000 in bits 0-2 is still best effort so it won’t end up that bad in most cases. And with that I wipe my hands and slip out the side exit… :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Flent-users