Re: [tsvwg] Update to Position Statement on ECT(1)

["C. M. Heard" <[e-mail]>]

On Thu, May 28, 2020 at 1:21 AM "Holland, Jake" wrote:

> On 5/28/20, 12:57 AM, "Sebastian Moeller" wrote:
> > I have a question regarding tunneling, that IMHO is left unanswered
> > so far. Why is the rule for ECN and tunneling not simply: copy the
> > inner to outer on encapsulation and the outer to inner on
> > decapsulation. Period.
>
> Please see RFC 6040.  Section 7 gives the design principles,
> and Section 4 describes the current standard rules.  The Intro
> also reviews some of the other considerations that went into it.
>

Consider applying Sebastian's suggestion to ECT(0) and ECT(1) only.

Only the combination marked (**) below would be changed from RFC 6040:

            +---------+------------------------------------------------+
            |Arriving |            Arriving Outer Header               |
            |   Inner +---------+------------+------------+------------+
            |  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
            +---------+---------+------------+------------+------------+
            | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
            |  ECT(0) |  ECT(0) | ECT(0)     | ECT(1) (++)|     CE     |
            |  ECT(1) |  ECT(1) | ECT(0) (**)| ECT(1)     |     CE     |
            |    CE   |      CE |     CE     |     CE(!!!)|     CE     |
            +---------+---------+------------+------------+------------+


That combination was marked with (!) in RFC 6040 because no existing
standard relied upon it.

[I]t seems the consensus at the time landed on a copy of outer
> to inner for ECT(1) overwriting ECT(0) on decapsulation, but not
> for ECT(0) overwriting ECT(1) (which I think is the only change I'd
> want in order to enable the 2-signal proposal, to the extent it
> seems possibly worth doing).  To me it's an understandable decision,
> especially considering RFC 6660, which seems essentially "SCE but
> only applicable inside DSCP", and would prefer not to lose that pre-
> congestion signal if something weird happens while it's tunneled.
>

But RFC 6660 actually relies only on the combination (++) which would be
unchanged.

In a later message, Gorry Fairhurst admonished:

> Please relate ECN tunnel discussions to the relevant work items. Is this
> related to draft-ietf-tsvwg-rfc6040update-shim or the
> draft-ietf-tsvwg-ecn-encap-guidelines or to draft-ietf-intarea-tunnels?
>

The discussion strayed a bit but the topic of this thread is the
ECT(1)->ECT(0) alternative for safely accomplishing the goals of L4S. This
message concerns a minimal change to RFC 6040 needed to make ECT(1)->ECT(0)
work.

AFAICT that change would break no existing standard. Also AFAICT the only
effect on draft-ietf-intarea-tunnels would be a need to refer to a 6040bis
instead of RFC 6040. In draft-ietf-tsvwg-ecn-encap-guidelines the change
would necessitate an update to the rules in Section 4.4, Decapsulation
Guidelines, specifically rules 1 and 4, and in addition numerous references
to 6040 would need to be changed. I have not reviewed all 41 occurrences,
but a spot check indicates that some of the text surrounding those
references would need updating as well. The effect on
draft-ietf-tsvwg-rfc6040update-shim, to the extent that it was not rolled
into a 6040bis, would be to update the discussion of fragment reassembly,
probably to recommend preserving the pre-reassembly and post-reassembly
fractions of packets with ECT(0), ECT(1), and CE and to update the
discussion of ECN handling in the various protocols under IETF change
control.

There are lot of other changes to ongoing work items needed to make the
ECT(1)->ECT(0) alternative work, most notably (AFAICT) a reworking of
AccECN. That does not mean all of the existing work goes down the drain,
but the changes are not trivial.

And as Bob Briscoe has vocally noted, the adoption tail would grow very
long (though as he also notes, the future is longer than the present or
past),

Chairs: if all this is considered off-topic for the TSVWG list, given the
decision to move forward with the L4S work, just say the word, and I'll
happily comply. But, as David Black said in the "dispute" thread, "I am
confident that TSVWG *does not* currently have rough consensus that the L4S
experiment is safe to perform on the Internet." So there may be some value
in further exploration of the ECT(1)->ECT(0) alternative. If that needs to
go elsewhere, so be it.

Thanks & regards,

Mike Heard