Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:SuggestedFragmentation/Reassemblytext

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

Writing as shepherd for both of the ECN encapsulation drafts (ecn-encap-guidelines, rfc6040update-shim), my intent is to look at both drafts shortly after this IETF meeting week (next week if possible, definitely by end of the month), so there's time to resolve the tension between the two "SHOULD" statements.   After any text changes, I'll want to put my head together with Bob to come up with a summary of how we got here suitable for the shepherd write-up.

Thanks, --David

From: Bob Briscoe <[e-mail]>
Sent: Monday, March 8, 2021 11:02 AM
To: Markku Kojo
Cc: Markku Kojo; [e-mail]; Joe Touch; [e-mail]
Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:SuggestedFragmentation/Reassemblytext


[EXTERNAL EMAIL]
Markku,

Thx. Unfortunately, this draft is coming up in the mtg this afternoon.
I take some of the blame -  only re-posting the draft a couple of hours ago, which presumably reminded you that you were going to think on this.

inline tagged [BB]
On 08/03/2021 13:48, Markku Kojo wrote:
Hi Bob,

this issue and text on it seems acceptable to me.

However, the other issue with the two contradictory SHOULD's - that I now notice I have never replied to - seems not ok, I think.

[BB] The question is whether we have to solve this now.

I have a solution to resolve the contradiction. At the risk of prolonging the progress of this draft, I'll say it now. But if we can't resolve this in the next couple of days, I think we should go ahead with the two contradictory SHOULDs.

For the list, here's the two contradictory paras:

   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.

Possible resolution of the contradiction: the "SHOULD approximately preserve the proportion" is a rough long term average goal while "SHOULD ensure that incoming congestion indication is propagated immediately" is a requirement for after there has been some period (TBD) without any marking.

The big question is where would an implementer set that timescale? It needs to be a "typical RTT in the deployment environment" or some such get-out clause. I guess this is best left to the implementer.



Bob



I'm now occupied for the next few hours, so I'll come back with more detailed reasoning after the tsvwg meeting today.

Cheers,

/Markku

On Mon, 8 Mar 2021, Bob Briscoe wrote:


Markku, chairs, all,

Having reached agreement on the text last Dec, I then went and dropped the ball and
forgot all about this draft,... and ecn-encap-guidelines.

== ECN-ENCAP-GUIDELINES ==

I shall upload a new rev shortly with the following single diff that I noticed
during the meeting last Nov, and said I would do at the next rev:

 4.6.  Reframing and Congestion Markings

    The guidance in this section is worded in terms of framing
    boundaries, but it applies equally whether the protocol data units
-   are frames, cells, packets or fragments.
+   are frames, cells or packets.

== RFC6040UPDATE-SHIM ==

I shall upload a new rev shortly, with the following 3 paras at the end of S.5 on
ECN fragmentation/reassembly:

Para 1 is just moved up from the end but otherwise unchanged.
Para 2 is unchanged.
Para 3 is the text agreed on this list last Dec subject to further checking, with
one exception: I removed the citation of RFC3168 after "equivalent".
    Reason: The citation of RFC6040 at the end is the relevant one, 'cos it
introduced the mechanism for ECT(0) and ECT(1) to be either equivalent or two
severity levels. In this respect it updated RFC3168. So it would not be appropriate
to cite RFC3168, which only said the two were equivalent. If we cited RFC3168 here,
it could be interpreted as if we're saying two RFC give conflicting definitions.

    Section 5.3 of [RFC3168] defines the process that a tunnel egress
    follows to reassemble sets of outer fragments
    [I-D.ietf-intarea-tunnels] into packets.

    During reassembly of outer fragments [I-D.ietf-intarea-tunnels], if
    the ECN fields of the outer headers being reassembled into a single
    packet consist of a mixture of Not-ECT and other ECN codepoints, the
    packet MUST be discarded.

+   If there is mix of ECT(0) and ECT(1) fragments, then the reassembled
+   packet MUST be set to either ECT(0) or ECT(1).  In this case,
+   reassembly SHOULD take into account that the RFC series has so far
+   ensured that ECT(0) and ECT(1) can either be considered equivalent,
+   or they can provide 2 levels of congestion severity, where the
+   ranking of severity from highest to lowest is CE, ECT(1), ECT(0)
+   [RFC6040].

If any of this isn't acceptable, I'll have to post another rev, but I think it's
what was agreed.

Cheers



Bob


On 14/12/2020 15:44, Markku Kojo wrote:
      Hi Bob, all,

      apologies for the delay, now catching up again.

      yes, handling mix of ECT(0)/ECT(1) like in the new proposed text below
      seems reasonable choice (for now).

      I'll come back shortly with the issue in the other thread. It seems
      less clear, actually seems quite difficult to handle correctly for all
      foreseen cases.

      /Markku

      On Thu, 3 Dec 2020, Bob Briscoe wrote:

            Markku, all,

            I am also only now catching up with the list...

            On 17/11/2019 08:46, Markku Kojo wrote:
                  Hi Dave, Joe, All,

                  Catching up ...

                  I agree with the modified new text as well as
            treatment of an ECT(0)/ECT(1)
                  mix as "any".


            [BB] Thanks. For the list, the current text that Markku is
            agreeing with is here:
            https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-11#section-5

            Regarding reassembly of a mix of ECT(0)/ECT(1). I agree
            with David that the current text
            should handle this case that 3168 doesn't address.
            And I agree with Joe that an interim way of handling it is
            needed, not just punting until
            later.

            I see that all of Jonathan, David and you Markku are happy
            with reassembling a mix of
            ECT(0) and ECT(1) to result in either ECT(0) or ECT(1).
            (for now). I think we can go one
            better than that, still without precluding a more specific
            RFC later. Here's proposed
            text:

            After the following para:

               During reassembly of outer fragments
            [I-D.ietf-intarea-tunnels], if
               the ECN fields of the outer headers being reassembled
            into a single
               packet consist of a mixture of Not-ECT and other ECN
            codepoints, the
               packet MUST be discarded.

            Add:

                  If there is mix of ECT(0) and ECT(1) fragments, then
            the reassembled packet
                  MUST be set to either ECT(0) or ECT(1). In this case,
            reassembly SHOULD take
                  into account that the RFC series has so far ensured
            that ECT(0) and ECT(1)
                  can either be considered equivalent [RFC3168], or
            they can provide 2 levels
                  of congestion severity, where the ranking of severity
            from highest to lowest
                  is CE, ECT(1), ECT(0) [RFC6040].


            Rationale: This avoids constraining future RFCs, but at
            least lays out all the
            interoperabilityrequirements we already have for handling
            this mixture. Then if an
            implementer wants to just default to choosing one, it hints
            that they should choose
            ECT(1).



                  I also want to repeat my comment that

                   draft-ietf-tsvwg-ecn-encap-guidelines-13

                  added similar new text that alters RFC 3168, and it
            should be modified
                  accordingly.


            [BB] I'll start another thread for this, rather than make
            this thread too unweildy.



            Bob



                  Thanks,

                  /Markku

                  PS. I missed Bob's response to my comment at the
            time, but will reply it
                  separately at some point.


                  On Wed, 9 Oct 2019, David Black wrote:

                        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

                              -----Original Message-----
                              From: Joe Touch <[e-mail]><mailto:[e-mail]>
                              Sent: Wednesday, October 9, 2019 10:29 AM
                              To: Black, David
                              Cc: Jonathan Morton; [e-mail]<mailto:[e-mail]>
                              Subject: Re: [tsvwg]
                              draft-ietf-tsvwg-rfc6040update-shim:
            Suggested
                              Fragmentation/Reassembly text


                              [EXTERNAL EMAIL]

                              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
                                    <[e-mail]><mailto:[e-mail]> wrote:

                                          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
                                          <[e-mail]><mailto:[e-mail]>
                                          Sent: Tuesday, October 8,
                                          2019 6:55 PM
                                          To: Black, David
                                          Cc: [e-mail]<mailto:[e-mail]>
                                          Subject: Re: [tsvwg]

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


                                          [EXTERNAL EMAIL]

                                                On 8 Oct, 2019,
                                                at 10:51 pm,
                                                Black, David
                                                <[e-mail]><mailto:[e-mail]>
                                                wrote:

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


                                          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





            --
            ________________________________________________________________
            Bob Briscoe
            http://bobbriscoe.net/
                           PRIVILEGED AND CONFIDENTIAL



--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/




--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/