Pete Heist <petehe...@gmail.com> writes:
>> On Feb 18, 2018, at 7:48 PM, Pete Heist <petehe...@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
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... :)
Flent-users mailing list