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

["Holland, Jake" <[e-mail]>]

Hi Bob,

Again, I'm trimming down to the summary in hopes of getting
better clarity, but for reference the full message I'm replying
to is here:
https://mailarchive.ietf.org/arch/msg/tsvwg/h6DPXNbPR9kXXzsZTuD9x7_Bs88/

I just wanted to respond to a few points.

> From: Bob Briscoe <[e-mail]>
> Date: Wednesday, May 20, 2020 at 11:59 AM
...
> In summary,
> * There is only one unlikely condition (no.1) for spurious 
> retransmissions as a result of ECT1->0.
> * Whereas ECT0->CE only causes spurious retransmissions if all 5 
> unlikely or extremely unlikely conditions occur together.

I roughly agree with the analysis you gave; I do think you'd get
more spurious retransmissions in the case of multiple loaded
dualqs in series using the 2-signal scheme that Martin and I were
discussing than using the scheme in l4s-id.  (And thanks for
the references and the deeper dive, and the engagement with this
discussion.)

But the thing to compare is the overall consequences between the
2 schemes, of which reordering is one part.  (Not the direct
comparison of the reordering differences in a vacuum.)

The 2-signal scheme under discussion provides one major benefit,
namely that it would not redefine the meaning of a ECT(1)->CE
transition, and thus would not need the flag day I argued the
current L4S spec would need in my other recent message here:
https://mailarchive.ietf.org/arch/msg/tsvwg/THuFmguARLFQHWXG_VOyt0Wj5R8/

> Having engaged with this argument, I do want to emphasize that the 
> tunnel argument causes ECT1->0 not to work at all over 60-70% of the 
> Internet for many years.

I also agree the tunnel problem is a bigger downside of the proposed
2-signal scheme than the reordering issues.

You convinced me tunnels are a significant and serious issue, which
is in large part the driver on this discussion, and why I framed it
as possibly coming down to a choice between the 1/p signal and the
1/sqrt(p) signal, if we can't have both safely out of a tunnel.

However, organizing a flag day in order to enable an experiment that's
incompatible with a standard as widely implemented as RFC 3168 is a
heavy lift, and that proposal might not achieve the kind of consensus
that would be necessary to move that forward.

If no solution can be found that makes L4S's use of CE compatible with
RFC 3168 queues sharing with classic traffic, and no flag day can be
organized to responsibly deprecate the existing meaning of the
ECT(1)->CE transition, then the question becomes how to do something
worthwhile.  Even if that means starting with the 30-40% of the
internet that *can* be addressed in the near term without breaking
the one signal (CE) that can currently be passed through a tunnel
egress (with an eventual path forward over time if it proves useful).

This is the context where I thought our examination of the reordering
consequences made sense, in terms of thinking through the tradeoffs for
a proposal that does not redefine CE.

I'm not sure whether you're saying it's not worth doing anything at all
if the L4S 1/p redefinition of CE can't be deployed, but if you are I'd
tend to disagree.  A 1/p congestion signal seems worthwhile to try to
make happen and to use in the places where it can be used, even if those
are limited at first.  I just don't see it as clear-cut that the CE
semantic redefinition is going to be able to move forward, given the
poor interaction with existing implementations and the fundamentally
fragile heuristics in the proposed classic queue detection solution
(not to mention the poor behavior under testing that the SCE team and
your own collaborators have observed).

As I think Gorry put it, we're faced with a shortage of bits here, so
we might have to take a choice that's not as globally optimal as it
could be if we could change deployed systems whenever we wanted.  A
flag day is one path forward if there's a sufficiently broad consensus,
but I'm not convinced it'll be doable.

And I'd tend to be against it today, since I think we should keep
expanding on the deployment of the existing queues.  But I'm not
opposed to a standards track spec that says to treat ECT(1) as NECT
instead of as ECT(0), I think that's a fine idea that could open up
the possibility of using ECT(1) the way you want within a decade or so,
as support rolls out for avoiding the ambiguous signaling.  So it's
another reasonable path forward that might make L4S-style signaling
possible to set up for success down the road.

But again, it doesn't solve the near term problem of companies that
would like to get something rolling out sooner, but have so far been
working with a signal that's an incompatible use of an existing signal.

So to me it still seems worth considering a 2-signal approach first,
since it works right away for 30-40% of paths, doesn't break regular
AQM and CE (which, I must emphasize again, is already widely available
and finally in use at endpoints, and does most of the latency job
compared with drop-tail, which is the proper point of comparison for
the internet paths that are suffering from queuing delay today), and
could move forward with a longer term incremental improvement from
there.

Short of a magical bitless packet classifier, I'm not sure what other
options can help achieve anything that improves the congestion
signaling fidelity at internet scope in the near term.

Best regards,
Jake