[Flent-users] DSCP / ToS
moeller0 at gmx.de
Sun Feb 18 21:40:24 EET 2018
Hi Toke, hi Pete,
> On Feb 18, 2018, at 19:09, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> Pete Heist <peteheist at gmail.com> writes:
>> 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. :)
> Is it really useful to have two different ones? Adding --tos as an alias
> for --dscp (and maybe deprecating the latter) would be sufficient,
> wouldn't it? If you support the textual representations most people will
> probably use those anyway, I figure. DiffServ is a mess in any case, so
> spending too much effort trying to support is "nicely" is probably not
> worth it.
I guess the potential issue is that setting all 8 bits might interfere with ECN (assuming that the ECH handling is not performed after IRTT let go of the packet), so for ECN-cohabitation masking the two ECN bits seems required while for full backward compatibility at least on of the ECN bits needs to be settable?
On the other hand, I would guess that ECN is more important than exposing all 7+1 TOS bits...
>> 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 ;)
More information about the Flent-users