Re: [tsvwg] Review comments on a careful read of the L4S ID (24. Including other L packets)

["Black, David" <[e-mail]>]

On 14/05/2021 15:47, Bob Briscoe wrote:
Gorry, David,
On 06/05/2021 07:52, Gorry Fairhurst wrote:
=================================================================
24. Requirements in 5.4.1.
“Such
   non-ECN-based packet types MUST be safe to mix with L4S traffic
   without harming the low latency service, where 'safe' is explained in
   Section 5.4.1.1.1 below.”

⁃            It is not clear what the MUST relates to, I think this needs to be more like (you’d still need to explain harm): “Non-L4S packets that are mixed with L4S traffic MUST NOT harm the low latency service, where 'safe' is explained in Section 5.4.1.1.1 below. and… Consider use of “SHOULD” here, as the consequences of not following it are stated, but not the current “MUST”.

[BB] Actually, I now realize that this has been written as a requirement on the operator, not the implementation. See below for fix.



“Therefore, a network element that
   implements L4S in a shared queue MAY classify additional packets into
   the L queue if they carry certain non-ECN identifiers.”
⁃           This later sentence appears to be a requirement on the same thing, but isn’t the same
⁃            “MAY classify additional packets” -> “MAY classify additional ‘safe’ packets” would provide consistency.
=================================================================

[BB] To resolve the problems with both the above normative sentences, I have deleted them both. And introduced the bullet list of different types of identifier with these words instead: "Examples of relevant non-ECN identifiers are:"

Then I've added the following normative sentence just after the bullet list:

   In summary, a network element that implements L4S in a shared queue

   MAY classify additional types of packets into the L queue based on

   identifiers other than the ECN field, but the types SHOULD be 'safe'

   to mix with L4S traffic, where 'safe' is explained in

   Section 5.4.1.1.1.

Please confirm if this resolves the problems here.




--

________________________________________________________________

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

For me this works, thanks.

Gorry

[David>] +1