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

[Gorry Fairhurst <[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 Briscoehttp://bobbriscoe.net/

For me this works, thanks.

Gorry