Re: [tsvwg] feedback and thoughts L4S / SCE

[[e-mail]]

Hi Gorry,

An experiment detecting high but invisible deployments may be useful. If nothing is detected, it might even be better.

I'm not sure, whether an experiment would initially involve more than a single operator and own (or a friendly co-operators) services. L4S is designed for provider access nodes. It will not see a mass-roll out from start, I'd guess.

There needs to be a transport protocol which benefits from L4S without harming flows using competing transport protocols to a level not acceptable. The transport protocol designed to benefit from L4S should also work reasonably well in the absence of L4S, while competing transport streams may be active. 

The discussion about what's fair and what isn't .... ideas to that:
- which are typical operational RTTs, (L4S relevant bottleneck) legacy transport queue-depths, and queue-configurations? The default configuration of a consumer access node queue is between 50 and 200 ms, I'd guess. There may also be a default RED configuration, if RED is configured. Typical RTT distributions - operators and service providers rarely publish on that, but some research work may be available. 
- or the other way around: under which (bandwidth, RTT and flow mix) conditions could an access operate "fair" or say "acceptable" (RTT + L4S configuration + transport mix)?
- does the transport community need to consent on which bottleneck share is fair, unfair or acceptable if flows with RTT feedback loops of different orders of magnitude compete?

I'd prefer to avoid corner case engineering. Workable schemes, not perfect ones.

Regards,

Ruediger


-----Ursprüngliche Nachricht-----
Von: tsvwg <[e-mail]> Im Auftrag von Gorry Fairhurst
Gesendet: Montag, 30. November 2020 20:14
An: Jonathan Morton <[e-mail]>; Sebastian Moeller <[e-mail]>
Cc: [e-mail]
Betreff: Re: [tsvwg] feedback and thoughts L4S / SCE

Here's another plea: If more people that those discussing amongst themselves feel there are other issues with letting this experiment progress, then they probably should let the list know - or directly contact the chairs.

Is there an important case where "RFC-3168 middlebox deployment is high, but invisible" (see below)?

Gorry

On 30/11/2020 15:19, Jonathan Morton wrote:
>> 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

--
G. Fairhurst, School of Engineering