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

[Bob Briscoe <[e-mail]>]

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/