[Flent-users] DSCP / ToS
moeller0 at gmx.de
Sun Feb 18 22:03:23 EET 2018
> On Feb 18, 2018, at 17:47, Pete Heist <peteheist at gmail.com> wrote:
> Change of subject...
> I realized it’s the two LSBs that carry ECN, not the MSBs. :)
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).
> I sometimes mistakenly passed in 46 (0x2E) for CS5 to irtt’s —dscp flag, for example, But it's really 184 (0xb8) that should go into the DS (ToS) field. Flent has it correct, and thankfully IRTT is doing today what Flent thinks it’s doing. But what I’m thinking for IRTT’s future is:
> 1) Add a new —tos parameter (possibly with a —ds synonym) that just sets the value passed in, hex or dec. It will not allow text. Basically what —dscp is today.
> 2) Change —dscp to left shift whatever value is passed in by two bits, if it’s hex or dec. If it’s text, use the same table Flent has now, except add “voice-admit” (0xb0, from RFC 5865), which is the only additional value at https://www.tucny.com/Home/dscp-tos, otherwise they all agree. The two LSBs (ECN bits) will always be 0 in this case. Flent could additionally add the "voice-admit” value (0xb0), but it’s probably not that critical. :)
> This would break —dscp’s current behavior, so I would increment the version number when I do it, and save it for v1.0 in case there are other breaking changes.
> So just some DSCP general discussion...
> It occurs to me that maybe the differentiated services spec should have defined official ways to _de-prioritize_ traffic (I think CS1 is sometimes used for this, but unofficially).
Yes, I agree (not that this matters much ;) ), but using CS1 seems to be just as "common" as can be hoped for for any DSCP mark.
> 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 ;)
More information about the Flent-users