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

["Black, David" <[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 differentiate   from, 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/ [bobbriscoe.net]<https://urldefense.com/v3/__http:/bobbriscoe.net/__;!!LpKI!zF9Ua67olmvIDP5O29IrV6vgiOMEj1C0P-PTxGHQe0x9Ls1UAXsPrZ1Dh4Z8HSfK$>

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, if all the traffic were marked for the same treatment at these bottlenecks,
Diffserv would make no difference./

Goirry

[BB2] Done.

[David>] That works for me.
Bob




--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/ [bobbriscoe.net]<https://urldefense.com/v3/__http:/bobbriscoe.net/__;!!LpKI!zF9Ua67olmvIDP5O29IrV6vgiOMEj1C0P-PTxGHQe0x9Ls1UAXsPrZ1Dh4Z8HSfK$>