Re: [tsvwg] Review comments on a careful read of the L4S ID (#10. DSCPs)

[Bob Briscoe <[e-mail]>]

See [BB]

On 06/05/2021 07:52, Gorry Fairhurst wrote:
>
> =================================================================
> *10. Please avoid making a claim that the IETF is NOT making a 
> statement about usability of DSCPs in this document.*
>
> This text grates:
[BB] I've added some context around this quote:
> “ Latency is becoming the critical performance factor for many (most?)
>    applications on the public Internet
> [...]
>    The Diffserv architecture provides Expedited Forwarding [RFC3246], so
>    that low latency traffic can jump the queue of other traffic.
>    However, on access links dedicated to individual sites (homes, small
> enterprises or mobile devices), often all traffic at any one time
> will be latency-sensitive.Then, given nothing to differentiate
> from, Diffserv makes no difference. Instead, we need to remove the
>    causes of any unnecessary delay.“
>
> ⁃To me this is not balanced. It seems to suggest that setting a DSCP 
> is useless. I don’t believe that is the consensus of tsvwg, although 
> at some additional pain we can debate the merits of setting DSCPs for 
> a traffic - such as the implications in enterprise networks; the 
> implications on UP in access points, etc. I’m not against this 
> discussion, but needing this to progress the draft seems unfortunate 
> to me. “Then, given nothing to differentiatefrom, Diffserv makes no 
> difference.” is gratuitous and should be removed.The paragraph 
> continues with “Instead, we need to remove the causes of any 
> unnecessary delay.” which can be combined into the previous sentence 
> as: “ … will be latency-sensitive, making it imperative to remove the 
> underlying causes of delay.”Nothing is lost here because the crucial 
> comparison with Diffserv is picked up two paragraphs later: “Unlike 
> Diffserv, which gives low latency to some traffic at the expense of 
> others, AQM controls latency for _all_ traffic in a clas
>
> =================================================================

[BB] I appreciate that you are trying to avoid upsetting anyone in the 
IETF who might take exception to criticism of Diffserv. However, I have 
tried to make it clear below that this is about limits to its 
applicability, not criticism of the whole idea.

This whole section is about the limits of other pre-existing low latency 
technologies. So it has something to irritate everyone - inherently. It 
is unfortunately necessary because, when I'm asked to review drafts from 
other areas of the IETF, I often have to ask the authors to say why they 
are proposing another way to do something that can already be done 
(which is the opposite of what a standards body ought to be encouraging 
- unless there's a new problem).

Second attempt...
[...]
    The Diffserv architecture provides Expedited Forwarding [RFC3246], so
    that low latency traffic can jump the queue of other traffic.

Then the following PROPOSED replacement text:

    If growth in high-throughput latency-sensitive applications continues,
    periods with solely latency-sensitive traffic will become increasingly
    common on links where traffic aggregation is low. For instance, on the
    access links dedicated to individual sites (homes, small enterprises
    or mobile devices). These links also tend to become the path bottleneck
    under load.  During these periods, given nothing to differentiate from,
    Diffserv would make no difference, at these bottlenecks. Instead, it
    becomes imperative to remove the underlying causes of any unnecessary
    delay.

Reasoning: Instead of relying on the reader connecting two concepts 
across paragraphs, this spells out the problem. This para's role was to 
explain the problem first. Before the subsequent para with the solution 
(AQMs reduce delay for all traffic).

But to soften the offending sentence, I've conditioned it  on "During 
these periods" and "at these bottlenecks".

The problem may seem obvious or gratuitous to experts in traffic 
control. However, to many networks engineers who are not traffic 
experts, Diffserv is something you take off a pick-list - "if you need 
low latency, you stick a low latency DSCP on the packets".





Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/