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

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

On Thu, May 21, 2020 at 5:51 AM Holland, Jake wrote:
> > From: Bob Briscoe <[e-mail]>
> > Date: Tuesday, May 19, 2020 at 4:18 PM
> ...
> > There are a hundred or so companies that have said they are planning
> > to deploy L4S, many with products imminent, but hanging on this IETF
> > decision. Under this proposal, they will then be expected to wait a
> > few years (probably more like a decade) until these tunnels are
> > designed, specified, implemented and deployed. Until then, L4S just
> > doesn't work at all over 60-70% of the Internet.
> >
> > This isn't going to happen. This is fantasy. Can you not see how
> > this will look? Actually, how it does look? It looks like you are
> > trying to give the IETF a reputation for shooting itself in both
> > feet, then laying land mines and blowing off both legs.
>
> This sounds to me like “whoops, we have made a terrible mistake by
> defining the tunnel semantics in such a way that only one wire signal
> (CE) can be transported [...]"

While I broadly agree with Jake's points, I don't think this last part
is quite right. Some of the trimmed text provided what I understand to
be the principal objection to the ECT1->0 proposal:

> > The guess is that 60-70% of Internet paths involve some form of
> > layering, tunnelling, overlay, etc. At the moment, L4S just works
> > with any of the whole history of ECN tunnels: RFC3168, RFC4301 and
> > RFC6040.
> >
> > This ECT1->0 proposal would make L4S not work at all with /any/
> > existing tunnels or layerings. Instead, it proposes to obsolete and
> > reverse RFC6040 (standards track) {1} and force L4S to /depend/ on
> > deployment of this new tunnel behaviour before L4S will work at all
> > (even tho it doesn't currently depend on RFC6040).
> > [...]
> > {1} Not to mention reversing other standards track RFCs, like
> > RFC6660.

RFC 6040 adopted the rule that ECT(1) overrides ECT(1) at tunnel egress
because ECT(1) was used at the threshold mark in the pre-congestion
notification work leading up to RFC 6660. So indeed there is standards
track work that would have to be deprecated in order for the ECT1->0
proposal to move forward. The choice of ECT(1) rather than ECT(0) as
the PCN threshold mark (and the resulting tunnel egress behavior in
RFC 6040) was a natural choice at the time and is perfectly compatible
with SCE (without the bits reversed). It was in hindsight a suboptimal
choice, but that was not in any was the fault of the L4S community.

With that said ...

> If there is a "fantasy" here, it's this notion that we'll quickly just
> breeze through a transition period before classic ECN is phased out,
> and so the interoperability problems don't need a serious and
> long-term solution, unless I'm misunderstanding the meaning of the
> "transition" you've referred to with remarks like these:
>
> (Sample "transition" remark 1):
>   > So please be correct and precise and say that a CE response is
>   > needed for the possibility of encountering a single-queue RFC3168
>   > AQM /during transition/.
>   >
>   > Beyond transition, a fixed 'back-stop'  response in addition to
>   > 1/p signalling would be completely redundant.
>
> (Sample "transition" remark 2):
>   > [BB] Again, see above - the second signal is purely for
>   > transition, so no need to try to convince yourself that it's
>   > also a useful backstop in its own right. Extent-based congestion
>   > signalling inherently contains its own backstop.

These remarks echo the theme I've heard in the comments from many of
the L4S advocates who spoke at the interim meeting on 2020 April 27
and seem to me to rest on a firm belief that L4S signalling offers
such a dramatic over classic RFC 3168 that it will sweep the latter
aside. I'm not convinced that this is in fact true, but if it is ...

> Perhaps the right choice is to deprecate classic ECN in shared queues
> and have the flag day.  Put that to a consensus call, and if it's
> really such a small footprint of people who would be affected, maybe
> it will fly.

+1

I see that the consensus call is to proceed with ECT(1) as an input and
develop L4S. I hope that classic AQM detection really can be made to
work as lot better than I now believe.

Mike Heard