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

[Dave Taht <[e-mail]>]

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

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.

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.

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.

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: [phone]