Re: [tsvwg] Gorry Fairhurst Individual thoughts on choosing whether/how to advance ECN work.

[Sebastian Moeller <[e-mail]>]

Hi Bob,

Tl, dr: L4S offers some quantitative improvements over the status quo, but nothing qualitative novel. 



> On May 24, 2020, at 01:53, Bob Briscoe <[e-mail]> wrote:
> 
> Sebastian,
> 
> On 23/05/2020 16:33, Sebastian Moeller wrote:
>> Bob,
>> 
>> 
>> 
>>> On May 23, 2020, at 17:07, Bob Briscoe <[e-mail]>
>>>  wrote:
>>> [...]
>>> 
>>> Another explanation is that L4S enables new interactive applications that are currently infeasible over the WAN.
>>> 
>> 	[SM] I have asked this before, but I am happy if I get a response this time: Which novel applications are possible now that the queuing delay has been reduced from ~10ms (fq_codel/cake, measured under real life traffic conditions on life internet access links) to ~1ms (L4S. dual queue coupled AQM under laboratory conditions)? This is the state of the art you compare against, not multiple 100s milliseconds of latency-under-load.
> 
> As explained in the email you are responding to, tail latency is important for real-time.

	[SM] This is not wrong, but the fact of the matter is, that the three services I already listed, google stadia, nvidia gforce now, shadow cloud gaming, all are real-time sensitive applications that are DEPLOYED und OPERATE in today's internet. So even the status quo is good enough for real-time coordination between actions and resulting control flow changes to be convincing enough for people to spend money on. That is a bg part of your potential market, that clearly is OKAY today indicating that improving tail latency is not an urgent issue for internet-scale real-time applications.



> The 10ms you report for FQ_CoDel is roughly its 90th percentile queue latency, which is an irrelevant metric for real-time (if the stream was being rendered after the 90%ile delay, 10% of the packets would arrive too late to be rendered). 

	[SM] This is not wrong, assuming your total latency is below one frame period and you are rendering at >= 100 Hz (for the 10ms limit). Soft real-time applications like games already deal with such delay variations though (to over-come both information transfer and CPU/GPU-cycle limitations), so improving your PDV slightly is not going to bring qualitative changes, no matter how hard we might wish.


> 
> In http://bobbriscoe.net/presents/2004ietf/202005L4S-brief.pdf (slide 4) I've used the 99.9th percentile delay for the rendering deadline, which reduces the fraction of packets that cannot be used to 0.1%.

	[SM] Your assumptions for that plot are a bit simplistic, but let's work with those. A) I claim that L4S is in reality not going to work reliably in the green circles (which you made from extrapolating a lab measurement, not from real-world measurements). B) CDN/data centers tend to be closer to the red radii not the green ones, so the internet already "solved" that issue for you, and e.g. 5G proponents advertize moving data center nodes even into the base stations, so I see no tendency currently to re-centralize data centers, do you?


> In the experiment reported in slide 3 you'll see the P99.9 latencies are 32ms for FQ_CoDel and 4.5ms for L4S.
> On slide 4 this is translated into reach in fibre, taking the generally accepted 50ms max delay for 'responsive feel' and subtracting application and OS delays.

	[SM] The point is that 500km radius is already plenty sufficient, unless you are trying to sell L4S exclusively to operators of big data centers, so that they can re-centralize their sites.

> 
> 
> See the link I put in the email you are responding to for the list, repeated here:
>     http://bobbriscoe.net/presents/2004ietf/202005L4S-brief.pdf
> To be clear, I'm not advocating these. I'm merely justifying my assertion about applications that are not currently possible. Personally, I'm not excited by gadgetry and social distancing. 

	[SM] Again, which of these a) make sense over the internet and b) do not work already today? As far as I can see the intersection of that set is rather empty.
Let's face it, L4S offers nothing qualitative novel, it is (assuming it works) an quantitative improvement, and hence might make a few things work a bit better, but the claim for novel applications really is wishful thinking.

> 
> Of course, we can't predict what other new applications will be developed once this amount of tail latency is removed over the wide area.

	[SM] Well, I can offer a prediction: no novel applications will grow out of this.

> Also, please bear in mind that I cannot generally pass on information about product plans.

	[SM] Fair enough, but a product plan, does not make a successful new application, nor does it demonstrate that the application absolutely requires L4S like network feedback.

> The original L4S teams from Alcatel-Lucent and Simula demonstrated a number of these applications at the Multimedia System 2016 conference: “Ultra-Low Delay for All: Live Experience, Live Analysis“, Proc. ACM Multimedia Systems; Demo Session (May 2016).
> Particularly cloud-rendered panoramic camera control and cloud-rendered VR goggles, were run at the conference over DCTCP and L4S with emulated wide-area round trip delay. 

	[SM] People use shadow cloud gaming with oculus rift headsets to do cloud-rendered VR already today... L4S (if it works) might make shadow's job a bit easier, but that is simply nothing novel. As noted before shadow is not alone in that respect.


> 
> Over today's state of the art AQMs, the delay is too inconsistent to rely on doing any of the following real-time interactive applications over wide area distances, or rendered remotely (e.g. in the cloud), rather than just confined to a LAN or metropolitan area:

	[SM] A claim that either hinges on your definition of "wide area distances" or is simply already refuted by reality. As expected, as all you are offering is a quantitative improvement in one metric, queueing latency, while the proposed applications are limited by total latency and total latency variation.


> * cloud-rendered interactive control (like this: https://riteproject.eu/dctth/#1511dispatchwg )

	[SM] Shadow, stadia, gforce now, do this right now without any AQM on the consumer side/return channel, so clearly something is wrong with your analysis?

> * remote presence,

	[SM] Video conferencing already works today; interestingly this tends to work better with a competent home network set-up with airtime fairness on the wifi side and a properly debloated access link (the wifi tends to be the bigger issue for many users though, L4S is not going to help there, is it)?

> * interactive real-time remote control or supervisory monitoring of cameras, drones, machinery (oil rigs,

	[SM] This is asinine, but I will bite, these off-shore oil-rigs most likely are connected via satellite internet, and geostationary satellites at that, the variable queueing delay is just going to be drop in the latency bucket (~270ms one-way propagation delay); and good luck doing anything interactive over such a delay.


> power plants, machine shops, cranes, ), medical procedures, using (high res.) video to monitor what is being controlled. 

	[SM] Whoever thinks about routing important medical procedures information required to make that procedure successful over the open internet, needs to be separated from his/her medical license. Anything that is not important for the process, like a comented upon video feed can easily tolerate delays.


> * interactive light-field experiences

	[SM] Just like "cloud-rendered panoramic camera control" that seems to be something playing to L4S perceived strength, but that has currently zero market share behind it. Sort of like an on-line version of the laser-disc.


> 
> 
>> 	Note, how for this question, I accept your claim of 1ms queueing delay even though testing indicates that this does not hold under all traffic patterns one is prone to encounter on a real internet access link (e.g. congestion on the reverse path). But really which application can not tolerate this additional 9ms of delay, yet is still a viable idea to deploy over the open internet? I note that real time control applications/reaction-time bound game services like google stadia and nvidia gforce now, are already deployed in today's internet, there really is nothing novel left as far as I can see
> 
> [BB] The novelty isn't the ability to demonstrate a "concept application" in a marketing video;

	[SM] But that is all that you offer ATM; I asked explicitly to get some real world killer apps for L4S and all I got was generalities.

> it's large numbers of real people actually being able to use it over the wide area for extended periods, without getting stressed, sick, or exhausted. And with just their regular Internet, rather than having to set up special network arrangements, or a special reserved session.

	[SM] As before, because you keep ignoring the elephant in the room, like Google Stadia, NVidia GeForce Now, and shadow cloud gaming. This ship has sailed without L4S, all you can offer is incremental improvements.

> 
> In the case of industrial or professional applications, quite often it's the ability for expertise to be deployed to a far-flung or inaccessible site instantly that would be the novel aspect, without experts or supervisors having to already sit on-call close by the site.

	[SM] Bob, either the behavior can be conserved in a video, which can be easily and reliably transported over the best-effort internet to the remote expert to scrutinize, or we are back to the critically stupid and dangerous idea of running important real-time control loops with real life consequences over the best-effort internet (games are fine, the failure mode, you loose a round, is benign, as compared you blowing out the well-head of an oil-rig in the gulf of mexico, I assume you agree).


As before, my assessment of L4S boils down to "too little, too late". Too little improvement over the status quo (at too high side-effects/costs) almost a decade later than originally envisioned.


Best Regards
	Sebastian

> 
> 
> 
> Bob
> 
>> 	Thanks in advance for the list of relevant new use-cases.
> 
> 
> 
> 
> 
>> 
>> Best Regards
>> 	Sebastian
>> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/