Re: [tsvwg] Comments on L4Sops [was Adoption call for draft-white-tsvwg-l4sops ...]

[Jonathan Morton <[e-mail]>]

> On 16 Mar, 2021, at 1:41 am, Greg White <[e-mail]> wrote:
> 
> I think you've misinterpreted the intent of the draft a bit.  Maybe there is an opportunity for further clarification in the draft itself, but fwiw I'll try to explain it better here.  

Actually, thank you for confirming that I understood the intent of your draft quite accurately.  The problem is that your intent does not match what is actually required, and was called for by the WG Chairs about a year ago.  That is precisely why I do not think this draft should be adopted in its current form - because it misses the whole qualitative point.  That is different from a disagreement on some detail point, which could be considered quantitative.

> Accurate real-time, in-band detection of RFC3168 by an L4S congestion controller is what you are referring to in your first item labeled 1.  If such an algorithm were generally agreed to be simple and reliable, then it could be argued that there wouldn't need to be an L4Sops draft. The detection algorithm that was studied earlier was found to suffer false positives at low data rates or high RTTs (though the referenced 'fallback' paper does discuss another approach for in-band detection that warrants looking into).  While the draft intends to include in-band detection as a potential option, it recognizes that it isn't the only solution.  I think there is confidence that out-of band tests can be reliably performed that determine whether RFC3168 bottlenecks exist, and this information can be used to make decisions about deployment and use of L4S.

I agree that offline active probes of the network are capable of yielding useful information, but that is not sufficient to reduce the risks of harm that I am concerned about to an acceptable level.

Path characteristics can change more rapidly than you are probably willing to run active probes, particularly in terms of which node along a given path acts as the bottleneck.  Congestion at peering and other shared nodes tends to follow a diurnal and weekly pattern, which I'm sure you're familiar with, and can also feature disruption events due to equipment faults, newsworthy real-world events, etc.  This could easily shift the bottleneck dynamically from the last-mile link to the backhaul or the peering, and back again.  You cannot tell from a single probe at a single time whether *all* those potential bottlenecks are L4S-safe.

You may remember that one test we presented for SCE, at the Chairs' request, was a simulation of changing the bottleneck from one type of AQM to another and back again.  The results, as I recall, were quite satisfying.  I'm not sure that we included a switch from an AQM to a dumb FIFO, but the results in that case are also benign and easy to predict for SCE.  Have similar tests been run for L4S, with similarly satisfying results?

> Further, I don't agree that network operators are always "innocent bystanders" in your taxonomy.  Some might be, but others are definitely not.  I think it is totally appropriate to provide guidance to network operators that want to participate in L4S but have RFC3168 deployed in their networks.   

In other words, you intend l4s-ops to be a guide on how to prepare an "involved participant" or "interested observer" network to carry L4S traffic, under the assumption that the experimental traffic will not accidentally leak out of that network into an "innocent bystander" network.  But as I pointed out, there is no mechanism mentioned for reliably preventing such leaks from occurring, and there are reasonably obvious cases that could provoke that eventuality.

What the WG at large is *specifically* concerned about, however, is the potential harm to "innocent bystanders".  That is the central point of Issue #16, though I don't think the words "innocent bystander" are actually mentioned in it.  By definition, an innocent bystander cannot be expected to take extraordinary action to avoid the risk of harm to himself or his own interests - which means that the recommendations laid out in l4s-ops, as presently written, do not protect him.

I do recognise that some of my suggestions are potentially out of scope for l4s-ops, or completely impractical to actually implement, or both.  In particular the last method requires a rewrite of the *other* L4S documents, or else throwing them away and starting from scratch.  But I think you could reasonably consider the third method - that of containment - as a method of conducting the experiment safely and discovering whether the fourth method is, in fact, necessary.

>> 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.

Based on your response so far, I think the above paragraph was quite perceptive.

 - Jonathan Morton