[tsvwg] Changes to normative text in ecn-l4s-id as a result of WGLC

[Bob Briscoe <[e-mail]>]

Gorry, Pete, Koen, list,
See [BB2]

On 07/11/2021 21:24, Bob Briscoe wrote:
>> NiT:
>> “ To include additional traffic with L4S, a network element only reads
>>    identifiers such as those itemized above.  It MUST NOT alter these
>>    non-ECN identifiers, so that they survive for any potential use later
>>    on the network path.”
>>
>> - Actually I think this MUST statemen t only applies to the L4S 
>> processing within the device, and I think it doesn’t mean L4S is 
>> unable to work across a policy enforcement point or some other device 
>> that otherwise modifies the other packet headers.
>>
>> .... so is this better as:
>>
>> “ To include additional traffic with L4S, a network element only reads
>>    identifiers such as those itemized above.  The L4S forwarding
>>   MUST NOT alter these
>>    non-ECN identifiers, so that they survive for any potential use later
>>    on the network path.”
>
> [BB] Note that this is not a nit - it is a correction to a normative 
> statement.
> Also, there is no definition of what the extent of an 'L4S forwarding 
> [element]' is. Classification for L4S might be much earlier in the 
> path. How about
>
> "The process of including additional traffic with L4S only involves 
> reading identifiers such as those itemized above. It MUST NOT alter 
> these non-ECN identifiers, so that they survive for any potential use 
> later on the network path."
>
> This is actually rather meaningless, because if a network element 
> wants to alter any of the identifiers, it doesn't have to be part of 
> "the process of including additional traffic with L4S". So the other 
> alternative would be to remove any normative text from this para, and 
> just say "The process ... wouldn't normally be expected to alter these 
> identifiers." But I've left it with the MUST NOT, so as not to 
> radically alter the draft. 

[BB2] I've had offlist pushback from Koen about the latest change to 
deal with your concern here. 
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-19#section-5.4.1.1
He also disagrees with the non-normative alternative I suggested of 
"...wouldn't normally be expected to alter non-L4S identifiers" because 
that's not necessarily true for Diffserv. He proposes that saying 
nothing about altering non-L4S identifiers would be best, and all the 
co-authors now agree with that.

However, Koen has also said that there should be a "MUST NOT" to stop 
anyone thinking they can include additional traffic in the L queue by 
altering the ECN field to ECT(1) based on other non-ECN identifiers.

So for the para at the end of "5.4.1.1.  Inclusion of Additional Traffic 
with L4S" 
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id#section-5.4.1.1
the new proposal for the list to consider is:

CURRENT:

    The process of including additional traffic with L4S only involves
    reading identifiers such as those itemized above.  It MUST NOT alter
    these non-ECN identifiers, so that they survive for any potential use
    later on the network path.

PROPOSED:
    In order to include non-L4S packets in the L queue, a network node
    MUST NOT alter Not-ECT or ECT(0) in the IP-ECN field to an L4S
    identifier. This ensures that these codepoints survive for any
    potential use later on the network path.


> On Sun, 2021-11-07 at 18:47 +0000, Bob Briscoe wrote:
>> On 24/08/2021 21:27, Pete Heist wrote:
>>> l4s-id Section 5.4.1.2:
>>> An operator that excludes traffic carrying the L4S identifier from
>>> L4S treatment MUST NOT treat such traffic as if it carries the ECT(0)
>>> codepoint, which could confuse the sender.
>> It might not directly relate to the section, but in order to comply
>> with this MUST NOT, the operator would also have to make sure that all
>> existing RFC3168 middleboxes are undeployed (see #1 above).
>
> [BB] Ah, I can see the confusion here. We shouldn't have said "An 
> operator ... MUST NOT treat...". We should have said:
>
> "A network node that supports L4S but excludes certain traffic 
> carrying the L4S identifier from L4S treatment MUST NOT treat..."
>
> I've also changed the subject of the other normative requirements in 
> this section from 'operator' to 'network node'.

[BB2] Koen also pushed back on the above change in "5.4.1.2. Exclusion 
of Traffic From L4S Treatment". He pointed out that the approach ought 
to be consistent with the similar but converse position in "2.5.1.1.  
Requirements in Unexpected Cases" in the DualQ draft: 
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled#section-2.5.1.1

The principle here is to deal with queue classification separately from 
AQM classification, but to recommend rather than mandate where possible, 
because operator-specific exclusion of traffic is meant to be for 
flexibility, so we shouldn't prevent flexibility unless important for 
interop.

So, if a network node that supports L4S classifies an ECT(1) packet into 
a Classic queue (due to some other non-ECN identifier), the output from 
the AQM in the Classic queue ought to still be compatible with an L4S 
congestion control.

    A network node that supports L4S but excludes certain L4S packets 
from L4S treatment MUST still apply marking or dropping that is 
compatible with an L4S congestion response. For instance, it could 
either drop such packets with the same likelihood as Classic packets or 
it could ECN-mark them with a likelihood appropriate to L4S traffic 
(e.g. the coupled probability in a DualQ coupled AQM) but aiming for the 
Classic delay target. It MUST NOT ECN-mark such packets with a Classic 
marking probability, which could confuse the sender.


Bob


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