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

[Gorry Fairhurst <[e-mail]>]

On 14/05/2021 12:53, Bob Briscoe wrote:
> 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 Briscoehttp://bobbriscoe.net/

To me this helps a lot, but I'd prefer to avoid /given nothing to 
differentiate from/ and explain, is this better?:

/During these periods, given nothing to differentiate from,
    Diffserv would make no difference, at these bottlenecks./

During these periods, ifall the traffic were marked for the same 
treatment at these bottlenecks,
Diffserv would make no difference./

Goirry