[tsvwg] Real time low latency video (SCReAM) and L4S

[Ingemar Johansson S <[e-mail]>]

Hi

I write up one post to address a few of the arguments for/against L4S seen from a SCReAM perspective and from the general point of streaming of low latency video.
I don't expect that the opponents of L4S will become convinced but I hope that it will help others to get some perspective around the matters brought up below. There is a certain risk that this can end up in yet another lengthy thread. I will personally eject from this quite quickly to spare the rest of the audience. 

1) "SCReAM, last I checked, has no code to implement the detection heuristic." (for RFC3168 bottlenecks) : 
SCReAM as well as other rate control algorithms need to have a fall back to delay based congestion control, to at least get a decent behavior for the cases where L4S is not implemented. In addition  a video source has a variable frame size output, not just  because of occasional I frames, P frames also vary in size. This means that realtime low latency applications that strive for a low e2e delay will leave some air for other flows. It is not a given that they will behave like SCReAM but regardless of implementation they all have a rate limited source with a rate that varies a lot over short time scales.
With SCReAM I currently see the problem that it is a bit too reactive to congestion and that it needs some improvement and an RFC3168 detection algorithm is perhaps needed then. But currently, SCReAM is a pretty weak competitor against flows with infinite source bitrates. 
But.. instead of just repeating this argument over and over again. Get the SCReAM BW test application from https://github.com/EricssonResearch/scream and run it with the following additional arguments 
-ect 1 -rand 20 
The code is public, it is just to fire away in test beds.

2) L4S gives very limited gain over CoDel (5ms is only a little more than 1ms). 
I will address this argument as well as the argument that the argument that the congestion control algos chartered in the RMCAT WG already themselves can keep delay low. The simulated test case is SCReAM running with a test trace from NVENC, the video frames are scaled to match the target rate, in the first experiment I assume that the video encoder is very responsive to changes in target bitrate, in the second experiment a bit sluggish behavior is mimicked that makes the video coder react 200ms late, this is a common case in many video encoders (e.g NVIVIA Jetson Nano and Xavier NX and RPI 3). The bottleneck is a 20ms RTT and a bandwidth that varies between 40 and 15Mbps in steps. The max video bitrate is set to 30Mbps.

*SCReAM_no_ECN_v_0.0.png : Shows the performance with no ECN support at all. The video frame delay illustrates the delay the end user will experience, the larger the variations, the larger delay is needed in a dejitterbuffer is needed to avoid a choppy play out.
*SCReAM_ECT0_CoDel_5ms_100ms_v_0.0.png : Shows the performance with  CoDel ECN marking.  Slightly better than no ECN but still up to 150ms frame delay spikes
*SCReAM_ECT1_L4S_v_0.0.png : Now with L4S. The delay is greatly reduced. What is left is the frame delay due to the serialization delay of the larger video frames. The nominal bitrate is slightly lower than the other two cases above in the congested area (when the bottleneck BW is <= 30Mbps), this is a natural tradeoff between latency and throughput.

Now we complicate things a bit for the experiment when the video coder is a bit more sluggish in its behavior. Now it takes 200ms for the video coder to respond to a changed target bitrate.
* SCReAM_no_ECN_v_0.2.png : As expected one can see that the video frame delays increase yet some more.
* SCReAM_ECT0_CoDel_5ms_100ms_v_0.2.png : Roughly the same performance with some tendency towards a higher frame delay.
* SCReAM_ECT1_L4S_v_0.2.png : Video frame delay is still very low, despite this added extra video coding artifact.

To conclude. 
+ L4S improves performance a lot.
+ Congestion controls that only rely on delay and packet loss measurements does not give a very low delay.
  
I hope that this should cast some light on the question whether L4S is useful or not.

/Ingemar
================================
Ingemar Johansson  M.Sc. 
Master Researcher

Ericsson Research
RESEARCHER
GFTL ER NAP NCM Netw Proto & E2E Perf
Labratoriegränd 11
977 53, Luleå, Sweden
Phone [phone]
SMS/MMS [phone]
[e-mail]
www.ericsson.com

 Talk about a dream, try to make it real
                  Bruce Springsteen
=================================