Subject: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested Fragmentation/Reassembly text

From: "Black, David" <[email-masked]>
Date: Tue, 8 Oct 2019 19:51:52 +0000

Context: Both draft-ietf-tsvwg-rfc6040update-shim and draft-ietf-tsvwg-ecn-encap-guidelines are currently stalled due to incompatibility between the new fragmentation/reassembly text in draft-ietf-tsvwg-rfc6040update-shim and RFC 3168.  Towards getting both drafts moving again ...

This note suggests text to bring Section 5 of draft-ietf-tsvwg-rfc6040update-shim (ECN Propagation and Fragmentation/Reassembly) into alignment with Section 5.3 of RFC 3168 (Fragmentation).   While the existing Section 5 of the rfc6040update-shim draft may be well-intentioned, that draft is not an appropriate vehicle for changing RFC 3168's reassembly requirements.   If those requirements are to be changed, a separate draft focused on fragmentation and reassembly (overall, not just for tunnels) would be appropriate.

For context, here's the crucial text from Section 5.3 of RFC 3168 that the rfc6040update-shim draft needs to align with:

   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.

Section 5 of draft-ietf-tsvwg-rfc6040update-shim gets off to a good start - the first two paragraphs of that section are fine and should be retained:

   The following requirements update RFC6040<https://tools.ietf.org/html/rfc6040>, which omitted handling of

   the ECN field during fragmentation or reassembly.  These changes

   might alter how many ECN-marked packets are propagated by a tunnel

   that fragments packets, but this would not raise any backward

   compatibility issues:

   If a tunnel ingress fragments a packet, it MUST set the outer ECN

   field of all the fragments to the same value as it would have set if

   it had not fragmented the packet.

**NEW**: Beyond those first two paragraphs, I suggest deleting the rest of Section 5 of the rfc6040update-shim draft and substituting the following paragraph:

   As a tunnel egress reassembles sets of outer fragments

   [I-D.ietf-intarea-tunnels<https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-09#ref-I-D.ietf-intarea-tunnels>] into packets, it MUST comply with

   the reassembly requirements in Section 5.3 of  RFC 3168 in

   order to ensure that indications of congestion are not lost.

It is certainly possible to continue from that text to paraphrase part or all of Section 5.3 of RFC 3168, but I think the above text crisply addresses the problem, and avoids possibilities of subtle divergence.  I do like the "reassembles sets of outer fragments" lead-in text (which I copied from the current rfc6040shim-update draft) because that text makes it clear that reassembly logically precedes decapsulation at the tunnel egress.

Comments?

Thanks, --David
----------------------------------------------------------------
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (774) 350-9323 New    Mobile: +1 (978) 394-7754
[email-masked]<mailto:[email-masked]>
----------------------------------------------------------------

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 9 Oct 2019 01:55:08 +0300

> On 8 Oct, 2019, at 10:51 pm, Black, David <[email-masked]> wrote:
> 
>    [I-D.ietf-intarea-tunnels] into packets, it MUST comply with
> It is certainly possible to continue from that text to paraphrase part or all of Section 5.3 of RFC 3168, but I think the above text crisply addresses the problem, and avoids possibilities of subtle divergence.  I do like the “reassembles sets of outer fragments” lead-in text (which I copied from the current rfc6040shim-update draft) because that text makes it clear that reassembly logically precedes decapsulation at the tunnel egress.
>  
> Comments?

Looks good to me.

The one case this doesn't really cover is what happens when a fragment set has a mixture of ECT(0) and ECT(1) codepoints.  This probably isn't very relevant to current ECN usage, but may become relevant with SCE, in which middleboxes on the tunnel path may introduce such a mixture to formerly "pure" packets.  From my perspective, a likely RFC-3168 compliant implementation of arbitrarily choosing one fragment's ECN codepoint as authoritative (where it doesn't conflict with other rules) is acceptable, but this doesn't currently seem to be mandatory.

With the above language, it should be sufficient to update RFC-3168 to cover this case at an appropriate time, rather than scattering further requirements in many documents.

 - Jonathan Morton

---

From: "Black, David" <[email-masked]>
Date: Wed, 9 Oct 2019 13:33:50 +0000

> The one case this doesn't really cover is what happens when a fragment set
> has a mixture of ECT(0) and ECT(1) codepoints.  This probably isn't very
> relevant to current ECN usage, but may become relevant with SCE, in which
> middleboxes on the tunnel path may introduce such a mixture to formerly
> "pure" packets.  From my perspective, a likely RFC-3168 compliant
> implementation of arbitrarily choosing one fragment's ECN codepoint as
> authoritative (where it doesn't conflict with other rules) is acceptable, but
> this doesn't currently seem to be mandatory.
> 
> With the above language, it should be sufficient to update RFC-3168 to cover
> this case at an appropriate time, rather than scattering further requirements
> in many documents.

I would concur that using a separate draft to cover that case at the appropriate time would be the better course of action.

Thanks, --David

> -----Original Message-----
> From: Jonathan Morton <[email-masked]>
> Sent: Tuesday, October 8, 2019 6:55 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested
> Fragmentation/Reassembly text
> 
> 
> [EXTERNAL EMAIL]
> 
> > **NEW**: Beyond those first two paragraphs, I suggest deleting the rest
> of Section 5 of the rfc6040update-shim draft and substituting the following
> paragraph:
> >
> > It is certainly possible to continue from that text to paraphrase part or all of
> Section 5.3 of RFC 3168, but I think the above text crisply addresses the
> problem, and avoids possibilities of subtle divergence.  I do like the
> “reassembles sets of outer fragments” lead-in text (which I copied from the
> current rfc6040shim-update draft) because that text makes it clear that
> reassembly logically precedes decapsulation at the tunnel egress.
> >
> > Comments?
> 
> Looks good to me.
> 
> The one case this doesn't really cover is what happens when a fragment set
> has a mixture of ECT(0) and ECT(1) codepoints.  This probably isn't very
> relevant to current ECN usage, but may become relevant with SCE, in which
> middleboxes on the tunnel path may introduce such a mixture to formerly
> "pure" packets.  From my perspective, a likely RFC-3168 compliant
> implementation of arbitrarily choosing one fragment's ECN codepoint as
> authoritative (where it doesn't conflict with other rules) is acceptable, but
> this doesn't currently seem to be mandatory.
> 
> With the above language, it should be sufficient to update RFC-3168 to cover
> this case at an appropriate time, rather than scattering further requirements
> in many documents.
> 
>  - Jonathan Morton

---

From: Joe Touch <[email-masked]>
Date: Wed, 9 Oct 2019 07:29:13 -0700

Hi, all,

I disagree with the suggestion below.

Pushing this “under the rug” for an indeterminate later date only serves to undermine the importance of this issue.

At a MINIMUM, there needs to be direct guidance in place until a “better” solution can be developed. For now, that would mean one of the following:
- use the max of the frag code point values
- use the min of the frag code point values
- use “any” of the frag code point values
- pick some other way (first, the one in the initial fragment i.e., offset 0), etc.

One of these needs to be *included at this time*.

If a clean up doc needs to be issued, it can override individual “scattered” recommendations later.

Joe

> On Oct 9, 2019, at 6:33 AM, Black, David <[email-masked]> wrote:
>

---

From: "Black, David" <[email-masked]>
Date: Wed, 9 Oct 2019 14:59:41 +0000

At this juncture, for an ECT(0)/ECT(1) mix across a set of fragments being reassembled, I would suggest using "any" (i.e., either is ok) at this juncture to avoid constraining what we may do in the future; in particular, this allows use of the value in the first or last fragment, both of which are likely to be convenient approaches for some implementations.

Thanks, --David

> From: Joe Touch <[email-masked]>
> Sent: Wednesday, October 9, 2019 10:29 AM
> To: Black, David
> Cc: Jonathan Morton; [email-masked]
> At a MINIMUM, there needs to be direct guidance in place until a “better”
> solution can be developed. For now, that would mean one of the following:
> > I would concur that using a separate draft to cover that case at the
> appropriate time would be the better course of action.
> >
> > Thanks, --David
> >

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 9 Oct 2019 18:26:05 +0300

> On 9 Oct, 2019, at 5:59 pm, Black, David <[email-masked]> wrote:
> 

Makes sense to me.

 - Jonathan Morton