Re: [tsvwg] ECN encapsulation draft - proposed resolution

[Bob Briscoe <[e-mail]>]

David, Thx for bringing this one up. See [BB] inline,

On 22/05/2021 01:02, Black, David wrote:
>
> On another topic, I believe that I have good news to pass along on the 
> ECN encapsulation drafts.
>
> The current situation is that the 6040update-shim draft is ready for 
> RFC publication to be requested, but there's an open issue in the 
> ecn-encap draft on the contents of this paragraph in Section 4.6 
> (Reframing and Congestion Markings), 
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-15#section-4.6 
> <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-15#section-4.6>:
>
> 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.
>
> Digging further, this area appears to be dealt with in greater length 
> and detail by RFC 7141 (Byte and Packet Congestion Notification) 
> Section 2.4 (Recommendation on Handling Congestion Indications When 
> Splitting or Merging Packets), 
> https://datatracker.ietf.org/doc/html/rfc7141#section-2.4 
> <https://datatracker.ietf.org/doc/html/rfc7141#section-2.4>. The short 
> summary is that the quoted sentence is generally correct with RFC 7141 
> containing a more comprehensive discussion including an exception.  As 
> RFC 7141 is a BCP, I suggest treating it as authoritative on this 
> matter for now, leaving redesign in this area to a possible future 
> draft (as we did in the 6040update-shim draft wrt RFC 3168 fragment 
> reassembly requirements).
>
> To carry this out, here's an initial ecn-encap draft text change 
> suggestion (begins with last two sentences in second paragraph of 
> Section 4.6):
>
> OLD
>
>       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.
>
> NEW
>
>     Where framing boundaries do not necessarily align
>
> with packet boundaries, the provisions of Section 2.4 of RFC 7141
>
> apply to propagation of ECN markings from layer-2 frame headers
>
> when they are stripped off and IP PDUs with different boundaries are
>
>     reassembled for forwarding. Those provisions include: "The general
>     rule to follow is that the number of octets in packets with
>     congestion indications SHOULD be equivalent before and after merging
>     or splitting." See RFC 7141 for the complete provisions and related
>     discussion, including an exception to that general rule.
>
> In addition to adhering to the provisions of RFC 7141 Section 2.4,
>
> the mechanism for congestion indication propagation SHOULD ensure
>
> that any incoming congestion indication is propagated immediately,
>
> and not held awaiting possible arrival of further congestion
>
> indications sufficient to indicate congestion for all of the octets
>
> of an outgoing IP PDU.
>
> END
>

[BB] OK, this is indeed progress.

> RFC 7141 (a BCP) would be added as a normative reference.
>

[BB] I'll write that up now. And post a revised draft.


Bob


> Comments?
>
> Thanks, --David (as draft shepherd)
>
> *David L. Black, *Sr. Distinguished Engineer, Technology & Standards
>
> Infrastructure Solutions Group,*Dell Technologies*
>
> mobile [phone] [e-mail] <mailto:[e-mail]>
>

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