[tsvwg] ECN encapsulation draft - next steps

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

The most recent chapter in this story of this draft (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/) is that a couple of months ago I attempted to resolve the remaining open issue on reframing based on  citation of RFC 7141 material on that topic (https://mailarchive.ietf.org/arch/msg/tsvwg/VlZsZYptYjqX4tHVHdoF5LLPcec/).  A lengthy discussion ensued ;-).

In reviewing that discussion, I have to agree that Markku Kojo was basically correct about the situation in his first response (https://mailarchive.ietf.org/arch/msg/tsvwg/-EGCISelAlZ3CDO79iOn42tT3No/):

I believe that the best solution to allow ECN encap draft to move forward
is that the draft does not say anything on the topic except points to a
new draft (the one that has been envisioned to handle the IP
fragmentation problem and would include also the handling of not aligned
packet/frame boundaries) and we initiate such new draft before ECN encap
draft gets published.

We have a draft from another WG (trill) at the RFC Editor that is stuck waiting for this draft to arrive (https://datatracker.ietf.org/doc/draft-ietf-trill-ecn-support/, https://www.rfc-editor.org/cluster_info.php?cid=C350).  That trill draft also has a reference to the ecn-l4s-id draft, but the ecn-l4s-id reference is informative, hence does not block RFC publication, whereas the reference to the ECN encapsulation draft is normative and is blocking RFC publication.

In the hope of not adding another year to that trill draft's sojourn at the RFC Editor, I propose doing something along the lines of Markku's suggestion to express no position on the open issue, and pursue the issue in a separate draft or drafts in the following fashion:


  *   Replace the last two paragraphs of Section 4.6 (https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-16#section-4.6) with a paragraph on each of the congestion marking for reframing approaches (preserve number of congestion-marked bytes, propagate congestion marks), each with suitable citations of references, e.g., RFC 7141 and RFC 3168.
  *   Include no material on how to select one of the approaches, or even matters to consider in making a selection.   The latter (omit matters to consider in making a selection) may seem harsh, but it's based on an observation that we don't even have rough consensus on how the various congestion control protocols interact with specific reframing congestion marking behavior.
  *   Invite the proponents of each approach to submit individual drafts on how congestion marking for reframing ought to work and why.  Informative references to these drafts as works in progress could then be added as part of IETF Last Call on the ECN encapsulation draft. To that end, I will be happy to record this plan/intent to add such references in the shepherd write-up for the ECN encapsulation draft, which should result in checks for such drafts at IETF Last Call and/or during IESG Evaluation.

I suspect that nobody (including myself) is going to regard this plan as ideal, but I do think the time has come to settle for something that is possible rather than continue to strive for perfection in the hope of moving this draft (and the related rfc6040update-shim draft) out of this WG and on its way to IETF Last Call and the RFC Editor.

Thoughts? Comments?

Thanks, --David (as WG co-chair and draft shepherd)

David L. Black, Sr. Distinguished Engineer, Technology & Standards
Infrastructure Solutions Group, Dell Technologies
mobile [phone] [e-mail]<mailto:[e-mail]>