Re: [tsvwg] Moving the ECN Encapsulation drafts forward ...

[Sebastian Moeller <[e-mail]>]

Hi David,

> On Jul 6, 2022, at 19:13, Black, David <David.Black=[e-mail]> wrote:
> 
> Writing as a WG chair …
>  
> We (WG chairs) are getting reminded about moving the ECN encapsulation draft (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/) onward, as it (along with the L4S drafts) is holding up another draft at the RFC Editor (https://www.rfc-editor.org/cluster_info.php?cid=C350).  With the L4S drafts now in the capable hands of our AD (and approaching completion of AD review), we need some compromise text for congestion indication propagation across resegmentation of layer-2 frames into IP packets (PDUs).  That is the only outstanding issue.
>  
> The text involved is in a couple of paragraphs in section 4.6.  The latest -16 version of the draft contains text that was my attempt to use RFC 7141 (Byte and Packet Congestion Notification) to settle this issue.  That did not work – the lack of WG rough consensus for that approach is clear from the resulting WG discussion.
>  
> So, we need to go back to the -15 text and try to make progress from there – the relevant -15 text (in Section 4.6) is:
>  
>    Where framing boundaries do not necessarily align
>    with packet boundaries, the following guidance will be needed.  It
>    explains how to propagate ECN markings from layer-2 frame headers
>    when they are stripped off and IP PDUs with different boundaries are
>    reassembled for forwarding.
>  
>    Congestion indications SHOULD be propagated on the basis that an
>    encapsulator or decapsulator SHOULD approximately preserve the
>    proportion of PDUs with congestion indications arriving and leaving.
>  
>    The mechanism for propagating congestion indications SHOULD ensure
>    that any incoming congestion indication is propagated immediately,
>    not held awaiting the possibility of further congestion indications
>    to be sufficient to indicate congestion on an outgoing PDU.
>   
> The simplest thing to do would be to delete the middle paragraph ("Congestion indications SHOULD be propagated …") and adjust the first paragraph accordingly, as I believe the WG has rough consensus that the last paragraph (on promptness of propagating congestion indications) is a "good thing" to do.
>  
> Beyond that, mentioning the two approaches that have been discussed without offering guidance could help implementers figure out "where to dig", so here's an initial attempt at replacement text:
>  
>    Where framing boundaries do not necessarily align
>    with packet boundaries, ECN markings SHOULD be propagated
>    from layer-2 frame headers to IP packets that may have different
>    boundaries as a consequence of payload segmentation and
>    reassembly for IP forwarding.
>  
>   Two possible implementation approaches to propagating congestion
>    indications are packet counting (e.g., proportion of IP PDUs sent with
>   congestion indications approximately matches the proportion of layer-2
>    frames received with congestion indications) and byte counting (e.g.,
>    number of payload bytes in IP PDUs that have congestion indications
>    is approximately equivalent to the number of bytes in layer-2 frames
>    received with congestion indications).
>  
>    The mechanism for propagating congestion indications SHOULD ensure
>    that any incoming congestion indication is propagated immediately,
>    not held awaiting the possibility of further congestion indications
>    to be sufficient to indicate congestion on an outgoing PDU.
>  
> Attempting to bound the discussion in the hope of getting to a conclusion:
> 	• Please do not debate packet-counting vs. byte-counting, even if you're absolutely certain that one of the two is the only thing that could possibly be the "right thing to do" – based on past experience, that debate appears to be intractable.
> 	• It's fine to take the position that neither implementation approach can readily be aligned with the SHOULD recommendation for prompt congestion indication propagation … BUT … it is incumbent on anyone who takes  that position to propose alternate text (which could be just that the paragraph on possible implementation approaches ought not to be included).


	[SM] Here is my go at it: 

"If framing boundaries do not align with contained IP packet boundaries all (ECT([0|1))* packets that are wholly or partly contained within the marked frame SHOULD be marked. However, if efficient processing requires only marking IP packets beginning inside a frame that is acceptable as well."


*) Assuming that flows that did not negotiate ECN will simply ignore any CE marks thet receive , the "all (ECT([0|1))" condition might be superfluous and could be dropped.


I accept that tunneling and encapsulations are important and that on core internet links processing cost needs to be minimized. Respectfully, if an entity wants tunneling AND "veridical" ECN signals it should simply avoid the situation by either not marking at the level of non aligned encapsulations or simply make sure one outer packet corresponds to one inner packet. This approach is both simple, predictable, and requires very little state keeping of the "de-framing" nodes. 
I also accept that this solution is probably "wrong" from both the packet-counting and byte-counting perspectives (as well as from other perspectives)...

Regards
	Sebastian




>  
> My goal is to get this resolved at the Philadelphia TSVWG meeting at the latest, preferably beforehand.
>  
> Thanks, --David
>  
> David L. Black, Sr. Distinguished Engineer, Technology & Standards
> Infrastructure Solutions Group, Dell Technologies
> mobile [phone] [e-mail]