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

[Bob Briscoe <[e-mail]>]

Gorry,
See [BB2]

On 14/05/2021 13:51, Gorry Fairhurst wrote:
> 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
>

[BB2] Done.


Bob


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