[Flent-users] DSCP / ToS
peteheist at gmail.com
Sun Feb 18 18:47:00 EET 2018
Change of subject...
I realized it’s the two LSBs that carry ECN, not the MSBs. :) 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 <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). 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? And in general, should ISPs de-prioritize traffic marked CS1 (0x10)?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Flent-users