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

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Sun, 16 June 2019 12:19 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615B512014A for <tsvwg@ietfa.amsl.com>; Sun, 16 Jun 2019 05:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa86qXOufZSa for <tsvwg@ietfa.amsl.com>; Sun, 16 Jun 2019 05:19:03 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30048.outbound.protection.outlook.com [40.107.3.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FCC12003E for <tsvwg@ietf.org>; Sun, 16 Jun 2019 05:19:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KI+VEJ/B4WSqLQgzq9WBeDM8urzoDUrGgCy1mmFTvEQ=; b=mfMz7c5/+poARp0MoP5LpIvzEG87Itq3KZ9EYyVdotchNqeoC3HCyp/BiEUZF4DBX0G65YtSfiGSVs04vsn8teEK2IZn1E8Jh/1pv0PtGyvm54wuq2P8qsYi6lL5zPiI0t7k24SaPVncgcqU/8jnXQFxKpiH9eC2XZeOic2DqSY=
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.167.142) by HE1PR07MB4252.eurprd07.prod.outlook.com (20.176.166.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.5; Sun, 16 Jun 2019 12:18:59 +0000
Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::802b:5182:975c:99da]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::802b:5182:975c:99da%3]) with mapi id 15.20.1987.010; Sun, 16 Jun 2019 12:18:59 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Dave Taht <dave.taht@gmail.com>, "Holland, Jake" <jholland@akamai.com>
CC: Bob Briscoe <ietf@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: [Ecn-sane] [tsvwg] Comments on L4S drafts
Thread-Index: AdUeK8SLhgyjMeS8RyC1czIhZ3l0vwEok9eAADT6vYAAAFfrgAAlzweg
Date: Sun, 16 Jun 2019 12:18:59 +0000
Message-ID: <HE1PR07MB4425FFE38922C2B9DDF4E165C2E80@HE1PR07MB4425.eurprd07.prod.outlook.com>
References: <HE1PR07MB4425603844DED8D36AC21B67C2110@HE1PR07MB4425.eurprd07.prod.outlook.com> <8967E7D6-F8FB-4926-87B7-7B0F1F4CEBDF@akamai.com> <CAA93jw5vrtHS1yev8AZjesLBOetp7aWKkrbXOUHemC1MNy3TvQ@mail.gmail.com> <CAA93jw5YFtyEK-VMG-CRu4RrzRmBGQCk69P4QcUQGgncRf+Y5A@mail.gmail.com>
In-Reply-To: <CAA93jw5YFtyEK-VMG-CRu4RrzRmBGQCk69P4QcUQGgncRf+Y5A@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com;
x-originating-ip: [83.226.2.151]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 90a3749c-6786-4c2c-32aa-08d6f254cfc4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB4252;
x-ms-traffictypediagnostic: HE1PR07MB4252:
x-microsoft-antispam-prvs: <HE1PR07MB4252E1750A3C40DB50AB1764C2E80@HE1PR07MB4252.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:1265;
x-forefront-prvs: 0070A8666B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(136003)(396003)(39860400002)(189003)(199004)(13464003)(14444005)(8936002)(256004)(68736007)(54906003)(110136005)(2906002)(476003)(486006)(7696005)(76176011)(9686003)(186003)(26005)(316002)(99286004)(53546011)(6506007)(102836004)(52536014)(305945005)(7736002)(966005)(11346002)(446003)(478600001)(14454004)(5660300002)(86362001)(71190400001)(6246003)(25786009)(53936002)(107886003)(66066001)(66574012)(76116006)(229853002)(64756008)(74316002)(81156014)(81166006)(66556008)(6436002)(66616009)(66476007)(55016002)(6306002)(3846002)(6116002)(73956011)(33656002)(8676002)(66446008)(4326008)(66946007)(99936001)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4252; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: LtXdHs2Ss6FIbYk3bujUccOfMRCvw82HOuNDudePNGAF7/EFK+sVySMVb3Ip9eaO2dLiS2Gumb/X9nxvaIjdfCe/87JNggBsCGLdfBrSPHXrlqu6rS+PXS/OrjY9KlaazBuPYSx3RSq3jiEnzEurpH+lj2NvmheXELCjorvfJ8zgQ48oupRSHa81NxfvoRC/Udf1GgwrS4eYIHz6oU0ZXcwwKEfn50XvTvJOCCJS9cW+kqc8vmSR5jb2wbLgHHQ/ufMI2ZLozsXMic/u5E2yw6XmFNDzitG7XSdCn3PKUv81oEW8GbAQEQXEQ85cHIe2zMwZzrIL/0PLUvlFmJv1lXfh1EMayrOipFpKXOBr8ToQ2BVLVPzKh+hjlMpHhc7qmfJkImHzPjy7R9Rs3IzozHEXQCjlx4kUnYU2F9iW80c=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0821_01D5244E.6F48D1F0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 90a3749c-6786-4c2c-32aa-08d6f254cfc4
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2019 12:18:59.3411 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ingemar.s.johansson@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4252
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/rjgdB9vF-YwR_dRSnd_yCXcCzG4>
Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Jun 2019 12:19:08 -0000

Hi Dave + all

Please see inline [IJ]

/Ingemar

> -----Original Message-----
> From: Dave Taht <dave.taht@gmail.com>
> Sent: den 15 juni 2019 19:54
> To: Holland, Jake <jholland@akamai.com>
> Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>om>; Bob Briscoe
> <ietf@bobbriscoe.net>et>; tsvwg@ietf.org
> Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts
> 
> On Sat, Jun 15, 2019 at 10:44 AM Dave Taht <dave.taht@gmail.com> wrote:
> >
> > On Fri, Jun 14, 2019 at 11:28 AM Holland, Jake <jholland@akamai.com>
> 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"
> <ingemar.s.johansson@ericsson.com> 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: 1-831-205-9740
> 
> 
> 
> --
> 
> 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: 1-831-205-9740