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

[Jonathan Morton <[e-mail]>]

> On 6 Jul, 2022, at 8:13 pm, Black, David <David.Black=[e-mail]> wrote:
> 
> 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).

My position is that preserving the "proportion" of any particular quantity is a fool's errand.  It is more useful and robust to attempt to preserve the absolute number of congestion signals applied, within the limits of feasibility, and in particular it is easier to implement that approach in a way that propagates such signals "immediately".  I believe I've given sufficient reasoning for that previously.

In terms of alternative 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.

   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.
   Mechanisms which satisfy this property include:

   - Every IP PDU which is reassembled, in whole or in part, from an L2
     frame which is marked with a congestion signal, should have that
     signal propagated to it.

   - Every IP PDU whose ECN field falls within an L2 frame which is
     marked with a congestion signal, should have that signal
     propagated to it.

   - Every L2 frame which is marked with a congestion signal, should
     propagate that signal to one IP PDU which is reassembled, in whole
     or in part, from it.  If multiple IP PDUs meet this description,
     the choice may be made arbitrarily but should be consistent.

   - Every L2 frame which is marked with a congestion signal, should
     propagate that signal to one IP PDU which is decapsulated from
     the same L2 link, as soon as is feasible.

   The number of L2 frames may be generally higher (eg. ATM), similar to,
   or lower than (eg. 802.11 aggregation) the number of IP PDUs, and this
   distinction may influence the choice of mechanism.  The above list is
   not exhaustive.

Each of the four mechanisms described above has immediately obvious implementation techniques, and it is relatively unlikely that an implementer choosing one of them would inadvertently get it wrong.  I believe they are also sufficiently analogous to RFC-3168 to admit to similar robustness analyses.

 - Jonathan Morton