Re: [tsvwg] ECT(1) Flag Day Plausibility

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

Hi Mike,

From: "C. M. Heard" <[e-mail]>
> Date: Sun,2021-05-09 at 4:27 PM
...
> Why not instead try to clean up tunnel behavior so that the transitions ECT(1) -> ECT(0) and ECT(0) -> ECT(1)  within the network make it through tunnels? If we go for a flag day, wouldn't this be more profitable?
...
> On Fri, Mar 26, 2021 at 10:15 AM Martin Duke wrote:
>>Bob has identified all of the problems with using DSCP for L4S. Among them is running L4S through a tunnel.
>>
>> Another axis of discussion was changing the L4S signal to be ECT(1)->ECT(0) and preserving the CE signal (thread: [1]), which comprehensively solves the coexistence issues. But this fell down, partially because of the (needless) RFC6040 tunnel decap behavior, which will revert any outer-header changes. There are some other problems, of course, they don't affect bystanders and I don't see them as likely to be fatal.


That also would be a reasonable approach to me.  I was including
this idea under "SCE-like", in that the change of codepoint in a
packet stream is interpreted as a high-fidelity congestion signal
as output from the network.

But I think Bob and others had some reasonable objections that
not only is the classifier unreliable under that proposal, but
also the unreliability increases with higher adoption, and we
can expect some related performance problems down this path that
would be avoided with the current l4s-id approach, assuming a
way can be found to roll it out safely.

I think we've seen a fair amount of discussion on SCE in general,
and I was assuming we can expect a sort of "reversed SCE" to have
roughly similar characteristics (with some unproven possibility
that there are some further improvements possible).

But we haven't seen much explicit discussion on sticking with
the current l4s-id while making the world ready to handle it
safely as a harm-avoidance strategy.

The threads referenced at the top of the prior message (and
maybe a few others earlier?) had a few people who seemed to be
saying something about the concept, but had some conflicting
views.  People seemed to be taking the position that it was
either trivial or essentially impossible and I don't think
either is true.

I think it would require a challenging but doable flag day.  I
think it would result in a slightly improved performance in the
end, relative to using ECT(1)->ECT(0) as a congestion signal.

And although 2 years ago I would have rated it almost certainly
more trouble than it's worth, the lack of motion on this
discussion (and even more so on the implementations) has me
reconsidering that position.

I hope that helps to clarify the intent behind the proposal.

Best regards,
Jake

(To the tunnel point: I agree 6040 would also need fixing with a
standards document that changes behaviors if we did something SCE-
like, but if I understand correctly enough (not assured! grain
of salt here) it could be done safely in parallel without blocking
on a flag day, and traffic over tunnels mostly just wouldn't get the
latency benefits until they get the upgrade, since they'd be stuck
with basically classic behavior.  Not sure that captures all the
nuances, but I thought I'd try to dodge that rathole in this thread
and leave it as a side issue.  For the sake of staying focused on
a flag day safety discussion, I was aiming to keep the effects here
summarized as "worse performance", some of which comes from the
tunnels having a long tail upgrade cycle that keeps their traffic's
behavior classic, and some of which comes from other effects.)