Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021

["Black, David" <[e-mail]>]

As an individual, I likewise support adoption.  Thanks, --David

From: tsvwg <[e-mail]> On Behalf Of Martin Duke
Sent: Friday, March 19, 2021 10:21 AM
To: Greg White
Cc: [e-mail]
Subject: Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021


[EXTERNAL EMAIL]
As an individual, I support adoption.

On Mon, Mar 15, 2021 at 2:17 PM Greg White <[e-mail]<mailto:[e-mail]>> wrote:
Hi Jonathan,

This is an adoption call, not a call for approval of the text.  In my view, the question is whether the working group members are interested in providing guidance to L4S experimenters to address the issue of compatibility with RFC3168 bottlenecks.

I'll respond to some of your points below in a separate thread so as not to disrupt the adoption call.

-Greg



On 3/15/21, 4:35 AM, "tsvwg on behalf of Jonathan Morton" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

    I do not think this document is ready for adoption in its current form.  Let me explain why, and suggest some ways it could be improved.

    L4S has a fundamental incompatibility with conventional AIMD traffic in the presence of RFC-3168 ECN AQMs, just like DCTCP upon which it was based.  L4S therefore requires mitigations to ensure that the harm caused by this incompatibility is minimised to an acceptable level.  Since the harm is primarily caused to "innocent bystanders" rather than "involved participants" or "interested observers", the acceptable level of harm and risk is especially low, and the mitigations need to be correspondingly robust.

    However, robust mitigations are not what l4s-ops currently describes.  Most of the measures described fall into three categories:

    1: Reliance on detecting an RFC-3168 AQM and disabling the L4S behaviour, using heuristics that have not yet been shown in a reliably working state, even under lab conditions.  It is impossible to state that such a heuristic can be relied upon until such a showing has been made.  A previous attempt at implementing such a heuristic was unsuccessful and is now disabled by default in the reference implementation.  Hence, the reliability of such a heuristic would necessarily be a subject of the experiment, not the primary safeguard.

    2: Requirements placed upon "innocent bystanders" to avoid the harm, mostly by reconfiguring, replacing, or disabling their RFC-3168 AQMs (sometimes in an RFC-ignorant manner).  This is obviously unworkable, since by definition "innocent bystanders" are unaware of the experiment, and even if made aware, are disinterested in doing work to accommodate it.

    3: Recommendation to deploy L4S hosts on networks that have been prepared to receive it.  Which is a step in the right direction.  But this is not accompanied by a corresponding requirement to *contain* L4S traffic to each prepared network.  Without such a requirement, it would be very easy for L4S hosts on different networks, which may individually have been prepared, to communicate over the path between those networks that has *not* been prepared, and upon which the risk of disrupting bystander traffic therefore exists.

    It is perhaps noteworthy that gaps in the second and third classes of mitigation are proposed to be covered by the first class of mitigation.  I also note that there is still an assertion in the text that RFC-3168 AQMs are "rare", which is refuted by recent data.  Finally, in the context of a CDN-ISP pairing for an experimental deployment, the ISP subscribers' LANs and WLANs are technically separate networks that would be difficult to "prepare" for L4S in advance; it would be wise to consider the ramifications of that.

    I also note in passing that a modification of tunnel encapsulation semantics is also proposed.  Given that tunnel implementations are more diverse than RFC-3168 AQM implementations, I also consider this unlikely to be practical, though I haven't studied in detail whether it would be effective if achieved.


    I am currently aware of four theoretical methods of robustly mitigating the risk posed by L4S.  I think that l4s-ops would be considerably improved by proposing that at least one of them be employed as a prerequisite to the L4S experiment actually taking place:

    1: Develop, implement, demonstrate, and open for scrutiny an RFC-3168 detection heuristic that is reliable and prompt enough to serve as a primary safeguard for the experiment.  In my opinion this will be difficult and will take significant time, but is not impossible to achieve.

    2: Deprecate RFC-3168, or amend it to remove drop-equivalent marking of ECT(1) packets, and require the removal of all unmodified ECN AQMs from the Internet.  This is unlikely to get much support given the increasing deployment rates of RFC-3168 AQMs at the present time.  In any case it would take a very long time to eliminate existing RFC-3168 AQM deployments at Internet scale, so I consider this impractical.

    3: Explicitly contain L4S traffic to networks that have been prepared or designated for the experiment.  That could be done by marking all L4S traffic with a designated DSCP at origin, and blocking traffic carrying that DSCP from traversing border gateways into unprepared networks.  This has the effect of making users and administrators of these networks at least "interested observers" and isolating L4S traffic from "innocent bystanders".  Within the designated networks, observing the practical interactions between L4S and conventional traffic would be part of the experiment.

    4: Redesign L4S to shift the risk burden away from "innocent bystanders".  The most obvious way to do so is to implement unambiguous signalling by the network, so that the receiver knows for certain whether it is receiving congestion signals from an RFC-3168 AQM requesting an immediate MD response, or from an AQM of the new type requesting a new type of response.  The risk of performance trouble is then restricted to network nodes that produce the new signals and transport endpoints that understand them - in other words, to the relatively small number of "involved participants" who have the knowledge and incentive to study the problem and find solutions.  The incentives are thus aligned correctly and risks are not "externalised".

    The SCE proposal does exactly that, in a manner that is totally transparent to existing RFC-3168 endpoints and middleboxes.  It becomes practical, for example, to use a Differentiated Services Code Point to differentiate a low-latency service onto a second bearer and provide a single-queue SCE AQM there, while providing a single-queue RFC-3168 AQM (without SCE) on the primary bearer.  Because of the unambiguous signalling, SCE traffic missing the DSCP would still compete on equal terms with conventional traffic, instead of dominating it or being dominated.

    I realise that this last method is not strictly in scope for the l4s-ops draft (and that mentions of SCE tend to raise hackles among L4S proponents), but I include it because it appears to be the most robust mitigation method available.  It also has the advantage of running code being available to try it out immediately.


    I am not hugely optimistic that the l4s-ops draft will incorporate the above advice before the adoption call ends.  But unless and until it does, my position is that it SHOULD NOT be adopted.

     - Jonathan Morton