[Flent-users] DSCP / ToS
moeller0 at gmx.de
Mon Feb 19 13:32:49 EET 2018
> On Feb 19, 2018, at 12:10, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> Pete Heist <peteheist at gmail.com> writes:
>>> On Feb 19, 2018, at 11:36 AM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>>> Pete Heist <peteheist at gmail.com> 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 ;)
>> 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
> 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.
> Flent-users mailing list
> Flent-users at flent.org
More information about the Flent-users