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

Dave Taht <> Sat, 15 June 2019 17:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABC1A120052 for <>; Sat, 15 Jun 2019 10:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9WXmgQZN_3gp for <>; Sat, 15 Jun 2019 10:44:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87F251200B9 for <>; Sat, 15 Jun 2019 10:44:49 -0700 (PDT)
Received: by with SMTP id e5so12793332iok.4 for <>; Sat, 15 Jun 2019 10:44:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tieJVsJhWgYQZiPWeamVXPn5Ey8Q+9PBWIGMAnKWZUA=; b=jfQhS94B6L1yaC1SQkGejCE8HQKN/WhGn1O8UcFi2bgt1v+8GG7Mo4VGIhwuymiI0i 0wGUFeCRy5H+nf7gxKQQYEAMfgxEswS+T5ZcE26GHBuQcpYk8GCZeZbM6nziKjWOt1YY HZcK8RanNJHhe3iTw9Nan9MmsGmBrDb4SPocodsRad5g5aXjz6zeHPVazaRCQyPOY4lP +16FGMsoZP/CMDAJwILPlssEFlahmxQxKXtO0wAH3LpIjB5nTDmG9bshcHLrFf+uMgAN W7VrlUiszHLZAsPsR2ewicjJRz+M4bYK/3lZ6YH/69SgGp1aMHAAL9WAbAnpwGwlT6wb wryw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tieJVsJhWgYQZiPWeamVXPn5Ey8Q+9PBWIGMAnKWZUA=; b=dm/2TfSLL2kNaQY0A2NZAM4XiHzHOtU0mBMz2HRZ9cTreJFWwGdWHQnrGI5MBinpd5 t0mQ/ZvbBsq5v3LnRdWH29GI0M2u7BZDcOiuAwKJekV7AYD8Fhq0ZgLLjpeJUo0fjHvw cKiK7AcJm9HVOfMfbPcxcU09ZcONvLKezFM0UcWg8iLoiKB5U059qSESuN2qKuutyP4S NElS76vIAszhdOmz8iK+hBnNmIHojTKUoiVna1LVmf5UlxJTw2EPiNA4WZv4Py0Sx2Kg iTavNgUd7iHT/e0OQlHctlal2MR7WA1vY3St6DxODkfaTCt8XVpyoZrEw3sx55qCYJLM ky2Q==
X-Gm-Message-State: APjAAAUS9JDB187nlCgHPWnEko8RdvQuKSf9kTzYeuSDXoUKiTfRXu55 lBYkK8lFCGBd9rv1/3GjNyBHxJSqnpi3aWWkA6s=
X-Google-Smtp-Source: APXvYqzu+TqsVsZQf732SCqAIFKLhHjly9Qbv2VOgMZ6HybNHxl9Xh1m8qJEc5Tvu58C0wH9LcI+QqDTuN4bjW+frNs=
X-Received: by 2002:a02:c7c9:: with SMTP id s9mr72117870jao.82.1560620687960; Sat, 15 Jun 2019 10:44:47 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Dave Taht <>
Date: Sat, 15 Jun 2019 10:44:35 -0700
Message-ID: <>
To: "Holland, Jake" <>
Cc: Ingemar Johansson S <>, Bob Briscoe <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 15 Jun 2019 17:44:54 -0000

On Fri, Jun 14, 2019 at 11:28 AM Holland, Jake <> 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" <> 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
Tel: 1-831-205-9740