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

[Bob Briscoe <[e-mail]>]

David,

I admit to curling up into a little ball and trying to ignore this 
controversy when it arose.
Let me try to sort this out now, for both ecn-encap-guidelines and 
rfc6040update-shim.

Back in Sep '19 (quoted at the end) you asked me not to use 
rfc64040update-shim to update RFC3168's fragmentation behaviour, even if 
it's the "right thing" to do, given I was saying that there were 
problems with the RFC3168 approach.

Background: Neither RFC3168 nor RFC6040 covered fragmentation & 
reassembly during encap and decap. So Joe Touch suggested 
rfc6040update-shim should fix that omission. Seems reasonable enough. 
However, it doesn't seem right to fix an omission by the stop-gap of:
1. requiring the approach in RFC3168 that we know is potentially 
problematic.
2. then planning to correct what we write, by updating it in a later RFC.

Let's call that approach (A). I don't like that at all. What if step #2 
never happens?
Fortunately, that's not the only way out of this. I can think of three 
other ways:

    B) The compromise text I've drafted below, which states the high
    level intent of a good mechanism as a SHOULD, and gives an example
    of how to do it. Then also allows the RFC3168 mechanism as a "MAY".
    C) Say nothing about fragmentation and reassembly in
    rfc64040update-shim or ecn-encap-guidelines. Then use a later RFC to
    update them both (stds track and BCP) with a considered 'correct'
    approach. ecn-encap-guidelines would still say include what it has
    always said about re-framing (which is a similar but different subject).
    D) Convince ourselves that fragmentation and reassembly during encap
    and decap is allowed to be different from fragmentation and
    reassembly without encapsulation.


Last night, I took approach (B), but with too little time left to 
discuss it on the list. I scrubbed the offending paras from 
rfc6040update-shim and replaced them with those below (also at 
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-10#section-5 
).

Thinking about it further since last night, I'm now inclining towards 
approach (C).


    5. ECN Propagation and Fragmentation/Reassembly


    The following requirements updateRFC6040  <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.

    During reassembly of outer fragments [I-D.ietf-intarea-tunnels  <https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-10#ref-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.

    As a tunnel egress reassembles sets of outer fragments
    [I-D.ietf-intarea-tunnels  <https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-10#ref-I-D.ietf-intarea-tunnels>] into packets, as long as no fragment
    carries the Not-ECT codepoint, it SHOULD propagate CE markings such
    that the proportion of reassembled packets output with CE markings is
    broadly the same as the proportion of fragments arriving with CE
    markings.

    The above statement describes the approximate desired outcome, not
    the specific mechanism.  A simple to achieve this outcome would be to
    leave a CE-mark on a reassembled packet if the head fragment is CE-
    marked, irrespective of the markings on the other fragments.
    Nonetheless, "SHOULD" is used in the above requirement to allow
    similar perhaps more efficient approaches that result in
    approximately the same outcome.

    InRFC 3168  <https://tools.ietf.org/html/rfc3168>  the approach to propagating CE markings during fragment
    reassembly required that a reassembled packet has to be be CE-marked
    if any of its fragments is CE-marked.  This "logical OR" approach to
    CE marking during reassembly was intended to ensure that no
    individual CE marking is ever lost.  However, an unintended
    consequence is that the proportion of packets with CE markings
    increases.  For instance, with the logical OR approach, once a
    sequence of packets each consisting of 2 fragments, has been
    reassembled, the fraction of packets that are CE-marked roughly
    doubles (because the number of marks remains roughly the same, but
    the number of packets halves).

    This specification does not rule out the logical OR approach ofRFC  <https://tools.ietf.org/html/rfc3168>
    3168  <https://tools.ietf.org/html/rfc3168>.  So a tunnel egress MAY CE-mark a reassembled packet if any of
    the fragments are CE-marked (and none are Not-ECT).  However, this
    approach could result in reduced link utilization, or bias against
    flows that are fragmented relative to those that are not.


Regards


Bob

On 15/09/2019 22:07, Black, David wrote:
> 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]>
>
> ----------------------------------------------------------------
>

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