Re: [Flent-users] DSCP / ToS

[Sebastian Moeller]

Hi Toke,


> On Feb 19, 2018, at 12:10, Toke Høiland-Jørgensen  wrote:
> 
> Pete Heist  writes:
> 
>>> On Feb 19, 2018, at 11:36 AM, Toke Høiland-Jørgensen  wrote:
>>> 
>>> Pete Heist  writes:
>>> 
 I liked the simplicity of RFC 795 (https://tools.ietf.org/html/rfc795) 
 from 1981 :) so, mostly in jest, I’ll propose a new system, call it 
 "Deferential Services", summed up by this:
 
 - Bits 0-2: Anti-precedence: 000 = normal, 111 = least important
 - Bit 3: 0 = normal delay, 1 = high delay ok
 - Bit 4: 0 = normal reliability, 1 = low reliability ok
 - Bit 5: Always 1, identifies deferential services, rarely used for 
 DiffServ in practice, I think
 - Bits 6-7 ECN
 
 Bit 5 will usually be 0 so deferential services won’t be used, and if
 it happens to be 1 for the wrong reason, 000 in bits 0-2 is still best
 effort so it won’t end up that bad in most cases. And with that I wipe
 my hands and slip out the side exit… :)
>>> 
>>> Don't forget RFC3514 compliance ;)
>>> 
>>> https://www.ietf.org/rfc/rfc3514.txt
>> 
>> :)
>> 
>> Humor aside, I do think a system based on voluntary de-prioritization
>> would be better than what we have today. Although, any system which is
>> universally respected also holds the potential for abuse, which is
>> probably why DiffServ ended up like it did in both design and
>> practice.
> 
> Sure, voluntary de-prioritisation would be awesome (people have tried
> with thinks like LEDBAT); but the people designing DiffServ are more in
> the "we must prioritise our (but no one else's) VoIP services" :/

In all fairness I always thought the VoIP application and appliances 
are the few exemplary citizens in dscp-land (which does not mean much); AFAICT 
they mostly tend to use the same small documented set of dscp markings 
(probably driven by the intent to use wifi's wmm categories well?). 
The voluntary de-prioritisation idea is interesting even though the 
devil is in the details.  For example I believe there should to be some (weak) 
guarantee of forward progress even for the back ground traffic (otherwise 
applications would need to monitor the progress themselves and switch markings 
if progress is lacking). It is one thing to say "transfer this when you find 
time" and consciously realizing that this might mean "never"; I doubt people 
consider never to be an acceptable answer ;). (I add that if say on 
LTE-networks BK packets would be free of charge, then even no delivery 
guarantee at all might be acceptable to some users).
But I digress, as far as I can tell CS1 is as close to a "universal" 
background traffic signal if I assume we will ever get (if only ISPs would 
optionally treat CS1 with lower priority at their upstream end for packets 
addressed to their customers we would have 80%? of what is to be gained by 
using a BK signal, assuming all intermediate transports did not actively screw 
up the signal). I believe Dave had data showing one ISP re-mapping almost 30% 
of packets to CS1, so this  "not-screw-up" assumption might be optimistic...

LEDBAT? great idea, sub-optimal congestion detection method ;) (at least wrong 
unless one only uses under-managed queues at the bottleneck link). As is LEDBAT 
(and BBR?) tend to punish those links that use proper AQM, not sure whether 
this could simply be ameliorated by auto-scaling the thresholds used to declare 
an observed latency increase as signal for congestion.

Best Regards
Sebastian


> 
> -Toke
> 
> ___
> Flent-users mailing list
> Flent-users@flent.org
> http://flent.org/mailman/listinfo/flent-users_flent.org


___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] DSCP / ToS

[Toke Høiland-Jørgensen]

Pete Heist  writes:

>> On Feb 19, 2018, at 11:36 AM, Toke Høiland-Jørgensen  wrote:
>> 
>> Pete Heist  writes:
>> 
>>> I liked the simplicity of RFC 795 (https://tools.ietf.org/html/rfc795) from 
>>> 1981 :) so, mostly in jest, I’ll propose a new system, call it "Deferential 
>>> Services", summed up by this:
>>> 
>>> - Bits 0-2: Anti-precedence: 000 = normal, 111 = least important
>>> - Bit 3: 0 = normal delay, 1 = high delay ok
>>> - Bit 4: 0 = normal reliability, 1 = low reliability ok
>>> - Bit 5: Always 1, identifies deferential services, rarely used for 
>>> DiffServ in practice, I think
>>> - Bits 6-7 ECN
>>> 
>>> Bit 5 will usually be 0 so deferential services won’t be used, and if
>>> it happens to be 1 for the wrong reason, 000 in bits 0-2 is still best
>>> effort so it won’t end up that bad in most cases. And with that I wipe
>>> my hands and slip out the side exit… :)
>> 
>> Don't forget RFC3514 compliance ;)
>> 
>> https://www.ietf.org/rfc/rfc3514.txt
>
> :)
>
> Humor aside, I do think a system based on voluntary de-prioritization
> would be better than what we have today. Although, any system which is
> universally respected also holds the potential for abuse, which is
> probably why DiffServ ended up like it did in both design and
> practice.

Sure, voluntary de-prioritisation would be awesome (people have tried
with thinks like LEDBAT); but the people designing DiffServ are more in
the "we must prioritise our (but no one else's) VoIP services" :/

-Toke

___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] DSCP / ToS

[Pete Heist]

> On Feb 19, 2018, at 11:36 AM, Toke Høiland-Jørgensen  wrote:
> 
> Pete Heist  writes:
> 
>> I liked the simplicity of RFC 795 (https://tools.ietf.org/html/rfc795) from 
>> 1981 :) so, mostly in jest, I’ll propose a new system, call it "Deferential 
>> Services", summed up by this:
>> 
>> - Bits 0-2: Anti-precedence: 000 = normal, 111 = least important
>> - Bit 3: 0 = normal delay, 1 = high delay ok
>> - Bit 4: 0 = normal reliability, 1 = low reliability ok
>> - Bit 5: Always 1, identifies deferential services, rarely used for DiffServ 
>> in practice, I think
>> - Bits 6-7 ECN
>> 
>> Bit 5 will usually be 0 so deferential services won’t be used, and if
>> it happens to be 1 for the wrong reason, 000 in bits 0-2 is still best
>> effort so it won’t end up that bad in most cases. And with that I wipe
>> my hands and slip out the side exit… :)
> 
> Don't forget RFC3514 compliance ;)
> 
> https://www.ietf.org/rfc/rfc3514.txt

:)

Humor aside, I do think a system based on voluntary de-prioritization would be 
better than what we have today. Although, any system which is universally 
respected also holds the potential for abuse, which is probably why DiffServ 
ended up like it did in both design and practice.
___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] DSCP / ToS

[Toke Høiland-Jørgensen]

Sebastian Moeller  writes:

> Hi Toke,
>
>
>> On Feb 19, 2018, at 11:22, Toke Høiland-Jørgensen  wrote:
>> 
>> Pete Heist  writes:
>> 
 On Feb 18, 2018, at 7:48 PM, Pete Heist  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... :)
>
> Well, it might be even easier for an ISP to completely ignore the
> tos/dscp fileds and simply use VLAN tags for priretisation, which a)
> can be interpreted by L2-Hardware (at least that is my understanding)
> and b) require active configuration so they are orthogonal to whateber
> gunk upstream passed in the DSCP fields (CS7?).

Yeah, I'm pretty sure some networks do that. Or something equivalent
using SDN. But using VLANs basically means you're now running your whole
network on layer 2; which means you'll need to handle routing at layer 2
as well. If you're not using SDN that basically means spanning tree or
something proprietary...

-Toke

___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] DSCP / ToS

[Toke Høiland-Jørgensen]

Pete Heist  writes:

>> On Feb 18, 2018, at 9:03 PM, Sebastian Moeller  wrote:
>> 
>>  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).
>
> Here I got nailed by assuming that ECN being in bits 6 and 7 was based on LSB 
> 0 bit numbering… :)
>
>>> 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 ;)
>
> And they don’t because they’re not consistently treated. What I learned by 
> blowing a good part of a Sunday reading RFCs was mostly summed up later by 
> Toke writing “DiffServ is a mess.” Although we can’t ignore the consequences.
>
> I liked the simplicity of RFC 795 (https://tools.ietf.org/html/rfc795) from 
> 1981 :) so, mostly in jest, I’ll propose a new system, call it "Deferential 
> Services", summed up by this:
>
> - Bits 0-2: Anti-precedence: 000 = normal, 111 = least important
> - Bit 3: 0 = normal delay, 1 = high delay ok
> - Bit 4: 0 = normal reliability, 1 = low reliability ok
> - Bit 5: Always 1, identifies deferential services, rarely used for DiffServ 
> in practice, I think
> - Bits 6-7 ECN
>
> Bit 5 will usually be 0 so deferential services won’t be used, and if
> it happens to be 1 for the wrong reason, 000 in bits 0-2 is still best
> effort so it won’t end up that bad in most cases. And with that I wipe
> my hands and slip out the side exit… :)

Don't forget RFC3514 compliance ;)

https://www.ietf.org/rfc/rfc3514.txt

-Toke

___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] DSCP / ToS

[Sebastian Moeller]

Hi Toke,


> On Feb 19, 2018, at 11:22, Toke Høiland-Jørgensen  wrote:
> 
> Pete Heist  writes:
> 
>>> On Feb 18, 2018, at 7:48 PM, Pete Heist  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... :)

Well, it might be even easier for an ISP to completely ignore the tos/dscp 
fileds and simply use VLAN tags for priretisation, which a) can be interpreted 
by L2-Hardware (at least that is my understanding) and b) require active 
configuration so they are orthogonal to whateber gunk upstream passed in the 
DSCP fields (CS7?).
But you aptly described it as a "mess" ;)

Best Regards
Sebastian



> 
> -Toke


___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] DSCP / ToS

[Toke Høiland-Jørgensen]

Pete Heist  writes:

>> On Feb 18, 2018, at 7:48 PM, Pete Heist  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

___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] DSCP / ToS

[Pete Heist]

> On Feb 18, 2018, at 7:48 PM, Pete Heist  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.

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…


___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] DSCP / ToS

[Pete Heist]

> On Feb 18, 2018, at 9:03 PM, Sebastian Moeller  wrote:
> 
>   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).

Here I got nailed by assuming that ECN being in bits 6 and 7 was based on LSB 0 
bit numbering… :)

>> 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 ;)

And they don’t because they’re not consistently treated. What I learned by 
blowing a good part of a Sunday reading RFCs was mostly summed up later by Toke 
writing “DiffServ is a mess.” Although we can’t ignore the consequences.

I liked the simplicity of RFC 795 (https://tools.ietf.org/html/rfc795) from 
1981 :) so, mostly in jest, I’ll propose a new system, call it "Deferential 
Services", summed up by this:

- Bits 0-2: Anti-precedence: 000 = normal, 111 = least important
- Bit 3: 0 = normal delay, 1 = high delay ok
- Bit 4: 0 = normal reliability, 1 = low reliability ok
- Bit 5: Always 1, identifies deferential services, rarely used for DiffServ in 
practice, I think
- Bits 6-7 ECN

Bit 5 will usually be 0 so deferential services won’t be used, and if it 
happens to be 1 for the wrong reason, 000 in bits 0-2 is still best effort so 
it won’t end up that bad in most cases. And with that I wipe my hands and slip 
out the side exit… :)

___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] DSCP / ToS

[Sebastian Moeller]

Hi Pete,


> On Feb 18, 2018, at 17:47, Pete Heist  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 ;)

Best Regards
Sebastian


___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] DSCP / ToS

[Sebastian Moeller]

Hi Toke, hi Pete,


> On Feb 18, 2018, at 19:09, Toke Høiland-Jørgensen  wrote:
> 
> Pete Heist  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
>> , 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 ;)
> 
> -Toke


___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] DSCP / ToS

[Pete Heist]

> On Feb 18, 2018, at 7:09 PM, Toke Høiland-Jørgensen  wrote:
> 
> Pete Heist  writes:
> 
>> 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,
> 
> 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 only don’t love the idea of —tos accepting a DSCP text value when the field 
isn’t called the ToS field anymore. I know people look for tos because that’s 
what they’ve been used to all these years, but I rather like getting rid of old 
stuff when possible. I’d feel more comfortable with —ds, as it’s the DS field 
now. I’ll still think about it…

>> 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. :)


___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] DSCP / ToS

[Toke Høiland-Jørgensen]

Pete Heist  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
> , 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.

> 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 ;)

-Toke

___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] DSCP / ToS

[Pete Heist]

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 , 
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)?

___
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org