[tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

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

This email concerns draft-ietf-tsvwg-ecn-encap-guidelines and draft-ietf-tsvwg-rfc6040update-shim, which are being handled together for WG Last Call and RFC publication, and is posted in my role as shepherd and responsible WG chair for these drafts.



The current situation is that both drafts are stuck due to a problem with the fragementation text added to the rfc6040update-shim draft.   Section 5 on ECN Propagation and Fragmentation/Reassembly was added to that draft in response to a WGLC comment, and it appears to have gone too far in the direction of trying to do the proverbial "right thing".



The core of the problem is in these two paragraphs in Section 5 of that draft (https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-09#section-5):



   As a tunnel egress reassembles sets of outer fragments

   [I-D.ietf-intarea-tunnels] into packets, it SHOULD propagate CE

   markings on the basis that a congestion indication on a packet

   applies to all the octets in the packet.  On average, a tunnel egress

   SHOULD approximately preserve the number of CE-marked and ECT(1)-

   marked octets arriving and leaving (counting the size of inner

   headers, but not encapsulating headers that are being stripped).

   This process proceeds irrespective of the addresses on the inner

   headers.


   Even if only enough incoming CE-marked octets have arrived for part

   of the departing packet, the next departing packet SHOULD be

   immediately CE-marked.  This ensures that CE-markings are propagated

   immediately, rather than held back waiting for more incoming CE-

   marked octets.  Once there are no outstanding CE-marked octets, if

   only enough incoming ECT(1)-marked octets have arrived for part of

   the departing packet, the next departing packet SHOULD be immediately

   marked ECT(1).

Much as that may be the proverbial "right thing" to do, particularly with the benefit of 20/20 hindsight, that text is inconsistent with the following text from Section 5.3 of RFC 3168 (https://tools.ietf.org/html/rfc3168#section-5.3), as Markku Kojo has pointed out:


   ECN-capable packets MAY have the DF (Don't Fragment) bit set.

   Reassembly of a fragmented packet MUST NOT lose indications of

   congestion.  In other words, if any fragment of an IP packet to be

   reassembled has the CE codepoint set, then one of two actions MUST be

   taken:



      * Set the CE codepoint on the reassembled packet.  However, this

        MUST NOT occur if any of the other fragments contributing to

        this reassembly carries the Not-ECT codepoint.



      * The packet is dropped, instead of being reassembled, for any

        other reason.



   If both actions are applicable, either MAY be chosen.  Reassembly of

   a fragmented packet MUST NOT change the ECN codepoint when all of the

   fragments carry the same codepoint.

The 6040update-shim draft is intended to update RFC 6040, and a number of the tunnel protocol drafts, but it is not intended to update RFC 3168, and hence the above new text (albeit well-intentioned) is a showstopper.   Changing ECN fragmentation behavior should be done in a separate draft.

Bob (as draft editor) - do you want to propose some new text to the list, possibly after private email discussion with Marco and me to figure out what it needs to say?

Thanks, --David
----------------------------------------------------------------
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
[phone] New    Mobile: [phone]
[e-mail]<mailto:[e-mail]>
----------------------------------------------------------------