[tsvwg] On safety

[Sebastian Moeller <[e-mail]>]

Dear list,


In the L4S presentation in tsvwg, I claimed that L4S has not demonstrated that it is safe for deployment over the wider internet.
Resulting in Mirja asking what I consider safe.
Now, that is harder to answer than what I consider unsafe ans unsound, so I will answer that question instead.


Currently, L4S design and/or implementation have a few systematic bias issues that I consider unsafe:

A) dominance of the shallow ECT(1) queue over the non-ECT(1) queue. As recently posted by Pete heist, if e.. CUBIC competes directly with TCP Prague, L4S will give a significant bias towards Prague, not stochastically one or the other, but always Prague. That bias ranges from "acceptable" to much less so, but the biggest issue is that this is a systematic reliable and robust bias in spite of draft text that implies equitable sharing between the classes. 

B) Increased RTT dependence: in spite of the requirements to eliminate RTT bias, team L4S's best approach at doing so still ends up with a design, that shows significantly stronger RTT-dependence of a flows throughput under competition with flows of shorter RTT, than either a FIFO queue, an FQ aqm or an approximate fq AQM. Sure, it is possible that this can be overcome by a better CC algorithm, but again it might not be possible. In which case who in their right mind is going to use TCP Prague/L4S in the first place, if I need to first figure out the RTT before deciding which CC to use?


C) odd design methods: It became clear from the discussion that Koen and Bob essentially consider the protocol/CC part of L4S somebody else's problem. In accordance with Lars I think that is the wrong approach. Essentially L4S proposes a new communication channel between AQM and end points, and communication needs to be understood as the interplay of sender (the AQM), signal (the marking) and receiver (the protocol operated by the end-points). Assuming one can design a robust, reliable, and effective communication by ignoring one of the components seems rather optimistic. This is only an abstract safety consideration, because it does not directly imply safety deficits, but it seems diagnostic to the frame of mind in which L4S has been characterized and tested by its proponents, piecewise instead of integrally.





It is also clear that the current combination of existing L4S implementations (dualPI2 plus TCP Prague) will basically just built a fast priority lane for short distances, like Eye-Balls to (nearby) CDN. In itself that is IMHO not necessarily an unworthy goal, but is NOT what the L4S drafts imply L4S to be.

None of these issues, require a mass deployment of network nodes or end points or even an RFC. The real experiment about safety and functionality over the existing internet IMHO needs to be performed before the "let's deploy this" and see how the components evolve an improve by active use "experiment" that seems to be planned.

Best Regards
	Sebastian