Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)

[Jonathan Morton <[e-mail]>]

On 3 Dec, 2020, at 11:36 pm, Sebastian Moeller <[e-mail]> wrote:

> …team L4S (not team FQ whoever that is) keeps claiming that FQ will make L4S' re-definition of the CE response "safe".; but in the light of tunneling that claim simply is not true. Also not really a reason to go off on an unprovoked rant about FQ and layer violations.

Just to put this completely to bed:

- If you remove FQ from the equation, and just have single-queue RFC-3168 AQMs, then L4S' problems get worse, not better.  Every instance, rather than only a limited subset of instances, of L4S sharing an AQM bottleneck with conventional traffic would be doing so in a shared queue, and we know perfectly well where that story ends (see Issue #16).  Therefore, FQ is not the cause of the problem, but a partial workaround; it works well when applicable, but there are scenarios where it does not apply, whence the behaviour is merely as if FQ were not present.

- If you remove AQMs from the equation entirely, then the coexistence problem goes away, but also L4S shows no benefits over the status quo, because it relies on an AQM to inform it of the bottleneck queue status.  Both L4S and conventional traffic would experience a lot of queue delay.

- If you remove L4S from the equation, then the problems associated with it go away completely.  Conventional traffic coexists with other conventional traffic just fine, whether in a shared queue or with FQ.  Therefore, L4S is the cause of the problem, because it is the single element that you can remove (while changing nothing else) to solve the problem.

In causal analysis, this is a no-brainer.  L4S, not FQ, is the problem.

With that high-level insight, it is then straightforward to drill deeper into the system and find the design element within L4S that is the *root* cause of the coexistence problems.  Everything leads back to the design decision to change the meaning of CE, slavishly following the (bad) example of DCTCP.  All subsequent design of L4S has been driven by the need to mitigate the consequences of that basic choice, and ultimately it has not worked - fundamentally because existing networks (as opposed to those specially prepared for L4S) see only the behaviour inherited from DCTCP.

In SCE, we made a different choice.  We chose from the outset to keep CE with its existing meaning, and even to use the existing ECE/CWR feedback mechanism for it.  For the high-fidelity signal we followed the suggestion in RFC-3168 of using the spare ECN codepoint, which seemed very natural, and we then had to decide on a feedback mechanism for it.  All of our subsequent work on SCE has been driven from the natural consequences of these early decisions, and some WG feedback on what behaviours are more or less desirable.  But it has resulted in a scheme that is inherently compatible with existing networks and existing traffic, unlike L4S.


Wes wrote:

> I wish this thread was making progress in any way, but I don't see it, and it's become a bit heated again.

I, and probably Sebastian too, feel some need to robustly counter disinformation when we see it.  That is unfortunately something we have to do rather a lot when L4S comes up.  Today's discussion about FQ is emblematic.

I agree with Wes in wishing that more people would get involved in this topic.  They should look at the test data that Pete, Jake and I have organised, maybe try to replicate our findings, and come to an informed opinion as to whether L4S (as a current WG item) remains worthwhile and/or can be salvaged somehow, or not.  They could also try some mathematical analysis to see what the theoretically predicted behaviour would be, and whether our tests reproduce that accurately.  Third-party validation (or repudiation) would be welcomed.

In connection with that, I would point to the lack of progress in addressing Issue #16 by technical means, in more than a year since it was first raised.  The heuristic bottleneck type detector was a valiant effort, but was not successful.  No better alternative has been put forward - except for changing the signalling mechanism, at least two versions of which the L4S team has flatly rejected.  I think we must consider the signalling mechanism to be a defining feature of L4S at this point, such that they share fates.

May I ask the Chairs whether a WGLC would be capable of de-adopting L4S from the WG agenda?  If so, then I might just remove my objection to having another WGLC for L4S.  At present, it seems like one of the most promising avenues for making concrete progress towards a worthwhile experiment in high-fidelity congestion control.

 - Jonathan Morton