Re: [tsvwg] L4S vs SCE

[Markku Kojo <[e-mail]>]

On Wed, 20 Nov 2019, Kyle Rose wrote:

> On Wed, Nov 20, 2019 at 6:04 PM Ingemar Johansson S
> <ingemar.s.johansson=[e-mail]> wrote:
>       >       How do you expect an industry/commercial roll-out of L4S
>       > technology to behave, if the L4S experiment should terminated without
>       > adoption as a standard track RFC? Are they supposed to phase-out using
>       > ECT(1) as well, or is it understood that deployed L4S instances continue using
>       > L4S methods?
>
>       [IJ] The premise would be that L4S is declared a failure. I doubt that anybody has
>       a good enough crystal ball to predict what happens. First it is necessary to come
>       to the conclusion that L4S is a failure and I would argue that we are not yet
>       there and I don't currently see that coming. Before that possible event I don't
>       see it meaningful to speculate.
> 
> 
> I'm going to have to go ahead and disagree with you strongly here. Given the potential
> consequences of cleaning up after a failed experiment without a plan worked out beforehand,
> this blithe approach is simply not acceptable.
> 
> In lots of cases, experiments are easy to terminate in an obvious way: for example, in one
> typical case, a code point can simply be abandoned, or (even better) a pollutable experimental
> code point returned to the available pool after some time. If that were the case here, it
> would not be difficult to enumerate a sequence of steps required to do so. It doesn't appear
> that's the case, however, so all the more reason to make sure we address this as part of the
> experiment setup.
> 
> A launch escape system of the necessary complexity should be a requirement of any experimental
> deployment. In this case, that might circumscribe the scope of the experiment itself.
>

I do not intend to speak out for either proposal but to raise my concern 
about future of new AQMs and related CCs that would really solve the 
problems that still seem to remain unsolved, particularly the problem of 
load transients such as flow startup. There have been a number of 
alternative proposals for ECN earlier and I expect there will be more in 
the future. I find it extremely important to allow such evolution.

That said, we have IETF-wide consensus documented in BCP 124 (RFC 4774) 
exactly for this case, i.e., the issues and requirements for a safe 
coexistence when defining alternate semantics for the ECN field. Sally, 
once again, has been very careful when considering the issues and the 
document is in most part very relevant. I would expect very thorough 
consideration for any deviation from the requirements in this document 
(along what is discussed in RFC 2914 and RFC 5033).

RFC 4774 also proposes a reasonable way forward for coexistence that is 
not necessarily ideal for widespread deployment in the global Internet 
but that's not what I find us discussing here. The question is about 
allowing controlled experiments in the Internet when using alternative ECN 
codepoint semantics for EXP purpose only. We very well know DSCP is known 
to have problems (bleaching, remarking, etc) but I don't think it would 
have that significant impact on EXPERIMENTING, because we have tools 
available to determine whether such problems are present in the 
end-to-end paths that are experimented with.

Thanks,

/Markku