Hi Toke,

> On Feb 19, 2018, at 12:10, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
> 
> Pete Heist <petehe...@gmail.com> writes:
> 
>>> On Feb 19, 2018, at 11:36 AM, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>>> 
>>> Pete Heist <petehe...@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 ;)
>>> 
>>> 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

Reply via email to