Re: [tsvwg] links to Canary methods for roll-out of new transport features

[Jonathan Morton <[e-mail]>]

> On 27 Aug, 2021, at 11:52 pm, Martin Duke <[e-mail]> wrote:
> 
> Hi Jake,
> 
> I don't think I was clear enough.
> 
> The assumption in my proposal is that in a large deployment these things will average out. So there is no intent to create additional connections solely to detect self-harm. As large deployments will likely have multiple connections to each endpoint and even larger pools of connections through important bottlenecks, I assert that if a provider
> 
> (1) establishes a Not-ECT and ECT(0) baseline;
> (2) Randomly turns on ECT(1) for 1/3 (?) of flows; and 
> (3) Both Not-ECT and ECT(0) meet some standard of non-degradation/non-starvation in the aggregate.
> 
> then that is strong evidence that the hypothesis that the problematic 3168 queueing is not operating on the internet.

I believe that would be a false assumption, and consequently a false assertion.

That type of testing is only capable of detecting a problem in a conventional flow that just happens to run simultaneously with an L4S flow.  It is not reasonable to assume that will routinely occur.  This is a general problem with using canary testing to detect externalised problems.

And this is a problem that is theoretically *expected* to occur…

> As for including both Not-ECT and ECT(0) in the baseline, I seem to recall someone making separate claims about the impact of L4S on each; if that's inaccurate, I have no objection to collapsing the control into one or the other.

For at least one type of expected bad interaction, Not-ECT and RFC-3168 ECN traffic will probably be affected equally.  I explain why in my detailed comments document.  Note that merely carrying ECT(1) is not relevant for this case, but the alternative congestion response associated with an L4S transport.

> Meanwhile, I am not crystal-clear as to whether the proponents intend to deploy L4S endpoints with Prague, something else that meets the Prague requirements, or nothing at all.

TCP Prague within a modified Linux kernel seems to be the only known L4S endpoint implementation at present.

 - Jonathan Morton