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

[Bob Briscoe <[e-mail]>]

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

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


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.

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. Also, please bear in mind that I cannot generally pass on 
information about product plans.


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 
<https://riteproject.files.wordpress.com/2015/10/uld4all-demo_mmsys.pdf>“, 
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.

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:
* cloud-rendered interactive control (like this: 
https://riteproject.eu/dctth/#1511dispatchwg )
* remote presence,
* interactive real-time remote control or supervisory monitoring of 
cameras, drones, machinery (oil rigs, power plants, machine shops, 
cranes, ), medical procedures, using (high res.) video to monitor what 
is being controlled.
* interactive light-field experiences


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

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.



Bob

> 	Thanks in advance for the list of relevant new use-cases.





>
> Best Regards
> 	Sebastian

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/