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

[Jonathan Morton <[e-mail]>]

> On 22 Mar, 2021, at 11:40 pm, Holland, Jake <jholland=[e-mail]> wrote:
> 
> Meanwhile, the L4S proponents raised a few well-founded objections to
> SCE with ECT(1) as output, for instance that in a shared queue the
> high fidelity congestion-responsive flows will necessarily be subjected
> to latency spikes driven by classic flow competition.  This was borne
> out in the SCE testing, e.g. in [3]--although it represents a substantial
> overall improved latency profile relative to the classic flow without a
> high-fidelity signal response, you can see the green spikes for the SCE
> latency in the shared queue tests, and how this limits the potential to
> stay within in a tight latency budget, even under favorable conditions.

This is not an insurmountable problem, but one to discuss in another thread at another time.  It refers to a particular prototype qdisc which was deliberately designed to show reasonable coexistence between SCE and conventional traffic in a single queue - which it actually succeeds at.  More sophisticated approaches are possible, in particular FQ, or using Diffserv classification for that rare class of traffic that can't even tolerate 5ms of jitter.

Ultimately, though, SCE is intended not as an "ultra-low-latency at any cost" mechanism, but as a congestion control signal that strikes a better balance between throughput and latency, by eliminating the sawtooth oscillation inherent to AIMD and settling at a cwnd close to the actual BDP.  Any performance achieved beyond that basic standard is gravy - nice to have, but not considered essential.

It's actually strange to me that some people consider this nit a show-stopper while ignoring the horde of angry Japanese Hornets on their own turf.

> There remain some fair questions to ask here, most notably IMO the
> same one you've raised, which I'll phrase as "is it appropriate to
> assign ECT(1) to this when the only known safe deployments would be
> known-path scenarios that could almost equally well use a local DSCP
> assignment for classification?"  I think several others have tried to
> ask roughly the same question, but it has so far been dismissed by
> the authors for the reasons given in Appendix B.4 of l4s-id [5].

I believe those arguments do not apply to the scenario, so are invalid - they are predicated specifically on allowing end-to-end L4S over the global Internet.  But without some significant technical changes to L4S, that is simply not going to happen, and all such technical changes have been rejected outright by L4S draft authors.  Editorial changes, some of which have gone through, do not improve the technical content.

> To me the key conclusion at this stage is that the operational
> considerations draft needs to share fate with the rest of the L4S
> drafts.  This is true regardless of whether L4S ultimately gets
> dropped, gets substantially changed, or achieves consensus and moves
> forward as-is, since as it stands today, the operational considerations
> is a key part of the safety story for avoiding damage to bystanders.
> Given that the other L4S drafts are currently adopted, this means to
> me that the operational considerations also needs to be in the same
> state, IMO.

A reasonable argument, but…

> But IMO, given that there are proponents looking to move forward with some
> form of deployment of the technology in hopes of getting the benefits
> shown in lab, it's important to document the precautions necessary to do
> so safely in deployment, and as far as I can tell, this is currently the
> intended role of the operational considerations draft.  And in that context,
> as RFC 7221 puts it, the pragmatics to consider here are "Initial, not final",
> and "Adoption, not approval", so while it's great that feedback is being
> generated and hopefully considered carefully, it's not (IMO) helpful to put
> off adopting a doc when we have a strong belief that other currently-adopted
> docs can't be deployed safely at scale without considering the advice that's
> in-scope for that doc.

This presupposes that the draft is expected to be refined after adoption, which in turn requires that the author is receptive to constructive feedback.  If I had some assurance that my detailed feedback so far was being taken seriously by this draft's author, I might change my stance.  Since it has simply been dismissed without adequate explanation, objection to adoption is the only voice I have, and I won't apologise for using it.

 - Jonathan Morton