[Flent-users] DSCP / ToS

Toke Høiland-Jørgensen toke at toke.dk
Mon Feb 19 12:22:10 EET 2018


Pete Heist <peteheist at gmail.com> writes:

>> On Feb 18, 2018, at 7:48 PM, Pete Heist <peteheist at gmail.com> wrote:
>> 
>>>> 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.
>>> 
>>> Well, that means Flent would need to deal with this case and detect
>>> which version of irtt is available; which IMO goes into the 'too much
>>> effort' category ;)
>> 
>> I hear you. :)
>
> So my latest idea is to not break the current behavior, and rather:
>
> 1) Add the text values as described before.
>
> 2) Return an error if a value is passed in with either of the two LSBs set to 1. That will save people in many cases who make the same mistake I did of passing in the DSCP value rather than the whole DS field.
>
> 3) If ever people really need to set what is currently the ECN bits, add a new flag at that time, but they really shouldn’t be doing that.
>
> Flent should be fine since it doesn’t pass in values with the ECN bits
> set.

Yup, this sounds like an excellent plan!

> Incidentally, I found that yes, Go lets you set whatever you want in
> the DS/ToS field, but somewhere along the Internet route from the
> office to my house, all the bits except the ECN bits are set to 0, so
> something, somewhere is washing the field in this direction only. So
> apparently, “DS field washing" happens sometimes as well…

Yeah, there's a reason DiffServ failed as an end-to-end measure. This
kind of shenanigans is happens way too often. For some networks I guess
it's necessary; if, e.g., you are doing strict priority on DiffServ
fields you kinda need to make sure someone doesn't DOS you by flooding
you network with EF traffic; and just clearing the fields is easier than
doing proper admission control... :)

-Toke




More information about the Flent-users mailing list