[tsvwg] ECN encapsulation draft - proposed resolution

["Black, David" <[e-mail]>]

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:

   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.  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

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

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]>