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

[Markku Kojo <[e-mail]>]

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. 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]>
>                               Sent: Wednesday, October 9, 2019 10:29 AM
>                               To: Black, David
>                               Cc: Jonathan Morton; [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]> 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]>
>                                           Sent: Tuesday, October 8,
>                                           2019 6:55 PM
>                                           To: Black, David
>                                           Cc: [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]>
>                                                 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/
> 
>