Re: [tsvwg] feedback and thoughts L4S / SCE

[Jonathan Morton <[e-mail]>]

> On 30 Nov, 2020, at 11:51 am, Sebastian Moeller <[e-mail]> wrote:
> 
>> That leaves us with the long discussion RFC3168 AQMs. Here the discussion
>> leaves me thinking that we are talking about a very limited actual
>> deployment in other words too much ado about very little.
> 
> 	[SM] citation needed? The challenge is that we have no reliable numbers, one way or the other. Your assessment, says more about your leaning towards L4S than about the deployed reality in the internet. 
> 
>> In addition, I get
>> the impression that these limited deployments are seen as monoliths that
>> cannot be modified and updated,
> 
> 	[SM] So I wonder in what kind of blessed reality you seem to be living? In my experience updates for most consumer-grade networked equipment are pretty rare and often stop way before the useful live of such devices, assuming all of these can/will be updated in time is simply unrealistic. Any proposal that relies on that has the onus of convincing the reviewers why this time around this will be a successful approach. 

Bearing in mind that this is the Internet *Engineering* Task Force, when lacking reliable data the instinct should be to try and obtain it and to make pessimistic assumptions meanwhile, rather than to make optimistic assumptions.

For L4S, the appropriately pessimistic assumptions should, until clearly shown otherwise, be that RFC-3168 middlebox deployment is high but invisible, and that eliminating the majority of this deployment (in favour of L4S-aware middleboxes) would take several years.  The burden of proof is on L4S proponents to show otherwise, given the safety risks already demonstrated of deploying L4S into an RFC-3168 network.

At present the data clearly shows a non-zero active deployment rate of both RFC-3168 endpoints and RFC-3168 middleboxes.  Passive deployment (ie. not enabled by default) of RFC-3168 endpoints is much higher, constituting the overwhelming majority of current desktop and mobile operating systems.  Additionally, L4S clients communicating with existing RFC-3168 servers will generate RFC-3168 traffic from the server to the client, due to details of AccECN negotiation on the three-way handshake.  That much is (or should be) completely uncontroversial.

It is further believed that many RFC-3168 middlebox deployments are presently not easy to observe in traffic statistics, either because they are not always (or not often) bottlenecked at that point, or because the endpoints did not negotiate RFC-3168 capability for the observed traffic.

The former case (not deployed at the bottleneck) may result in AQM activity later, when the bottleneck shifts to the link where it is deployed, perhaps due to ISP-side upgrades or changing the location of wifi devices - or when the observed traffic moves to a closer endpoint in the network, such as a local CDN.  This last suggests that L4S traffic might see more AQM activity due to deployment on an advantageously-positioned CDN, than the existing vantage points from which data has so far been collected.  NB: even if the ISP network has been made L4S-aware prior to the CDN deployment, the end-user's network might not have been, and this is generally outside the ISP's control.

The latter case (non-negotiation of ECN) could still result in AQM activity that would only be observable as packet loss, and thus is difficult to distinguish from a dumb FIFO without deeper analysis.  That is the major source of uncertainty in the data.  This could become more visible if active (rather than passive) deployment of RFC-3168 endpoints increases, which would most likely be from changing the default setting in major operating systems.  Presently the default in both Windows and Linux is passive only.

I will remind readers that although TCP Prague responds appropriately with Multiplicative Decrease upon packet loss, that does not help it when encountering an RFC-3168 AQM that it shares with conventional AIMD traffic, even if the latter is Not-ECT.  This is because the RFC-3168 AQM will mark the L4S traffic at the same rate as it drops Not-ECT traffic and marks RFC-3168 traffic.  This therefore forces TCP Prague to rely on secondary protections such as FQ to avoid starving conventional traffic, but FQ is typically defeated by tunnel encapsulations.

All of the above will be repeated as open issues at any L4S WGLC, unless and until it is clearly shown to be false.  That, I think, should give the L4S team pause when calling for WGLC.

 - Jonathan Morton