Re: [tsvwg] [Ecn-sane] Comments on L4S drafts

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

Hi Dave + all

Please see inline [IJ]

/Ingemar

> -----Original Message-----
> From: Dave Taht <[e-mail]>
> Sent: den 15 juni 2019 19:54
> To: Holland, Jake <[e-mail]>
> Cc: Ingemar Johansson S <[e-mail]>; Bob Briscoe
> <[e-mail]>; [e-mail]
> Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts
> 
> On Sat, Jun 15, 2019 at 10:44 AM Dave Taht <[e-mail]> wrote:
> >
> > On Fri, Jun 14, 2019 at 11:28 AM Holland, Jake <[e-mail]>
> wrote:
> > >
> > > Hi Ingemar,
> > > (bcc: ecn-sane, to keep them apprised on the discussion).
> > >
> > > Thanks for chiming in on this.  A few comments inline:
> > >
> > > On 2019-06-08, 12:46, "Ingemar Johansson S"
> <[e-mail]> wrote:
> >
> > > > I see many applications that can benefit greatly from L4S, besides
> > > > AR/VR,
> 
> I over reacted to the second part of this sentence. AR/VR - assuming it's over a
> reliable short RTT isochronous transport, can benefit from  L4S-style techniques.
> 
> > > > there is also an increased interest in the deployment of remote
> > > > control capabilities for vehicles such as cars, trucks and drones,
> > > > all of which require low latency video streaming.
> 
> but not this.
> 
> > This is a poor example of a use case for l4s. The link rates in these
> > cases are *wildly variable*.
> >
> > - in the case of a realtime command and control video stream on cars,
> > trucks, drones, uav or rockets, you *want* packet loss, you want the
> > most current frame or fragments thereof as closely tied to actual
> > event as possible. You want to drop from the head, not the tail of the
> > queue, when the rate changes, so the most current data is available to
> > the operator.
[IJ] Yes, of course. That is the whole intention with the congestion control algorithms devised within the charter of the RMCAT WG, SCReAM (RFC8298) is one of them. But simply head dropping is not good enough for video as this would distort the video.

> >
> > See any launch video from spacex for this.
> >
> > You also want backpressure or preferably an out of band signal to the
> > encoder (if you have one) so it drops the encoding resolution down to
> > the data rate ASAP, if you exceed the capacity, while holding the
> > video frame rate steady.
[IJ] Yes, also in the scope of RMCAT. The main challenge here is that run of the mill video coders like omxh264enc (available in the NVIDIA Jetson Nano) take some 300-500ms to reduce the rate. For that reason SCReAM has an RTP buffer on the sender side that can swallow RTP packets temporarly if the encoder output rate is higher than the target rate. The whole RTP queue is discarded if the delay becomes too high, with omxh264enc one can enforce a new IDR frame at the same time. This gives a very short glitch in the video. With that said.. video encoders behave differently, some are better than others.

> >
> > And you want to be running well below the presently observed capacity
> > of the link at all times, because it's precisely when things are going
> > south that you want the most data, especially if you are also
> > multiplexing control traffic over the same link.
[IJ] In the best of worlds you'd want to run exactly at or below the observed capacity but it is not always possible and perhaps not always needed, larger drops in link capacity can be solved with the RTP queue discard + new IDR outlined below. L4S can reduced network jitter which is welcome as network jitter leads to larger e2e delay as dejitterbuffers need to use a larger headroom to avoid choppy playout of the video. The link below tries to illustrate this a bit more 
https://github.com/EricssonResearch/scream#ecn-explicit-congestion-notification
  

> >
> > --
> >
> > Dave Täht
> > CTO, TekLibre, LLC
> > https://protect2.fireeye.com/url?k=f7d03840-ab0430e9-f7d078db-865b3b1e
> > 120b-b0476ab97f0a5e2a&q=1&u=http%3A%2F%2Fwww.teklibre.com%2F
> > Tel: [phone]
> 
> 
> 
> --
> 
> Dave Täht
> CTO, TekLibre, LLC
> https://protect2.fireeye.com/url?k=8920c762-d5f4cfcb-892087f9-
> 865b3b1e120b-
> 71c0ea6118599683&q=1&u=http%3A%2F%2Fwww.teklibre.com%2F
> Tel: [phone]