Re: [tsvwg] ECN encapsulation draft - proposed resolution

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

As draft shepherd and a WG chair, I believe that these drafts resolve the last of the open issues from WG Last Call.

In the next week or two, I will prepare the shepherd writeups and submit these drafts to our AD for further review towards IETF Last Call and publication as RFCs.

Thanks, --David

From: Bob Briscoe <[e-mail]>
Sent: Tuesday, May 25, 2021 10:35 AM
To: Black, David; [e-mail]
Cc: Donald Eastlake; John Kaippallimalil
Subject: Re: [tsvwg] ECN encapsulation draft - proposed resolution


[EXTERNAL EMAIL]
David, tsvwg list,

As promised yesterday, we just posted a new rev of ecn-encap-guidelines-16, with text based on your (David's) suggestions below. To add the references and to avoid some repetition, I twiddled the order round, but otherwise kept the text intact.

I also took the opportunity to post a new rev of rfc6040update-shim, 'cos I noticed Geneve has been published as an RFC. There were also a couple of words edited in my local copy as agreed on the list a few months ago.

https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines__;!!LpKI!0Dqxl-PL3yDRdgn8NyJqA_qluMSR5rs68SLBpIu5U8NjdWiozUI4l69r9TYj-2b3$>
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim__;!!LpKI!0Dqxl-PL3yDRdgn8NyJqA_qluMSR5rs68SLBpIu5U8NjdWiozUI4l69r9b6OmvWT$>

Cheers



Bob
On 24/05/2021 13:50, Bob Briscoe wrote:
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 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-15*section-4.6__;Iw!!LpKI!0Dqxl-PL3yDRdgn8NyJqA_qluMSR5rs68SLBpIu5U8NjdWiozUI4l69r9XO0Iqus$>:

   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 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7141*section-2.4__;Iw!!LpKI!0Dqxl-PL3yDRdgn8NyJqA_qluMSR5rs68SLBpIu5U8NjdWiozUI4l69r9T2hOroi$>.  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/ [bobbriscoe.net]<https://urldefense.com/v3/__http:/bobbriscoe.net/__;!!LpKI!0Dqxl-PL3yDRdgn8NyJqA_qluMSR5rs68SLBpIu5U8NjdWiozUI4l69r9SPBhicu$>



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/ [bobbriscoe.net]<https://urldefense.com/v3/__http:/bobbriscoe.net/__;!!LpKI!0Dqxl-PL3yDRdgn8NyJqA_qluMSR5rs68SLBpIu5U8NjdWiozUI4l69r9SPBhicu$>