RE: RTP over QUIC experiments

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Tue, 16 November 2021 07:14 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0FB3A0948; Mon, 15 Nov 2021 23:14:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 wp-1-amUwLJQ; Mon, 15 Nov 2021 23:14:01 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60054.outbound.protection.outlook.com [40.107.6.54]) (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 BE3B33A0947; Mon, 15 Nov 2021 23:14:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h6g4oDXWdeF3OdigNrmLbDswjQNYCpXnaogmNXFZKbKl+ztLjGlgB/1A0caFW/DKGxMXigbQnrDCzgos9y7Gc6DJKEO+OODCPfHLoC5IaLRwodOpbhH5NdLKaR7t1jKaolpkbo4vI78FDCxvouWZngMcec82C4qekUliFJOQooDMFiuOH185xMerNpv1pjDjIEaghnvgENpdYLcE7JCkm/0FeNhNwqhnofBC985I3ZRkYYOjJ9DySnSmCv+igYYeFQ3aUdGNnWa744dtdalc/Q19Fpa8yqEl1vqp79E97GxvQ1Oh4ygLms/0GLlyaMCYGEyt+evcad1kVLD29gFEJQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=H+Yjh9qhSFd6K28K/Ru6gdAUuNBRPZq6uaY2Xxo9XR4=; b=MpRC9YCCL/Ixu0keGTK0ysoKmOReOWu+Cq+FAWn2ySqUu4zDmckSJK9Ji/2cnNOYCD+zRtZgi1VllfKBL1fU2AC2W5alZsB0ymumwNWd99yUnxHI5SlJe+PDxdJRV7uO8IPXHuHkp73X+O0UWN//TlBseoF4mZLfjdFfg1S7cfC20g5lJ857f5fKO9QinwjZ73h4iQ1fXfKxH5nfY2ueakr0yJRmLSBoGh0bDD53HfVHP8jUJUADUPSpt03y7MCKRnq383niMiJHmQIa1TQeBXsYoOdHeM4CZ+soYXLyhXy4DVP7k9vpQ9SdIN5sA0mqqzlLHiuI4BDRXTNea3z+fg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H+Yjh9qhSFd6K28K/Ru6gdAUuNBRPZq6uaY2Xxo9XR4=; b=qg6E1HVIwIlZvmXTrB+8/m+VwTaE7WowUP5/98+itaXMM1hn/dl6LRT5Ebf9TBb6HaETOt9z5iH2zOFVZk/FBVpz604euhn+S8QqKcIMbm8h0pwu/CtIeUsn+KGE4ZiM6Y5onBd2vEGptDaRYQ6ItjC880hx/I9jTgeYb3iihsk=
Received: from AM8PR07MB8137.eurprd07.prod.outlook.com (2603:10a6:20b:36c::18) by AM8PR07MB8148.eurprd07.prod.outlook.com (2603:10a6:20b:323::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.9; Tue, 16 Nov 2021 07:13:53 +0000
Received: from AM8PR07MB8137.eurprd07.prod.outlook.com ([fe80::b9f4:e4f0:b07c:49dd]) by AM8PR07MB8137.eurprd07.prod.outlook.com ([fe80::b9f4:e4f0:b07c:49dd%9]) with mapi id 15.20.4713.019; Tue, 16 Nov 2021 07:13:53 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Vidhi Goel <vidhi_goel@apple.com>, Joerg Ott <ott@in.tum.de>
CC: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, "mathis.engelbart@gmail.com" <mathis.engelbart@gmail.com>, IETF QUIC WG <quic@ietf.org>, "avt@ietf.org" <avt@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: RE: RTP over QUIC experiments
Thread-Topic: RTP over QUIC experiments
Thread-Index: AdfX2qCtpQbe7xxBQleaYoCld3uW9gARIgSAAJBC5AAABoFaAAAPvwzg
Date: Tue, 16 Nov 2021 07:13:53 +0000
Message-ID: <AM8PR07MB81379868B1FFA4BB31CA85B3C2999@AM8PR07MB8137.eurprd07.prod.outlook.com>
References: <AM8PR07MB8137AD430709AC54E6EA361CC2959@AM8PR07MB8137.eurprd07.prod.outlook.com> <236C1AB5-D0F5-4453-A4F3-DEAB5D7113CB@apple.com> <2c965999-21f8-9a62-e008-47094a47430f@in.tum.de> <8CB16CED-5C42-4320-9CEE-B2FE8A78899D@apple.com>
In-Reply-To: <8CB16CED-5C42-4320-9CEE-B2FE8A78899D@apple.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c01ec54e-3ce9-41e0-0489-08d9a8d0a5c2
x-ms-traffictypediagnostic: AM8PR07MB8148:
x-microsoft-antispam-prvs: <AM8PR07MB8148A5B0473550159CFFD1DEC2999@AM8PR07MB8148.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:2582;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: X2fM5Dm1GoEQ6mA1sIOrnZMHsmwHyNEK5j15iuc69DxtbVtpU4+OH73RnQlzI1ZbHO+DqcVtO4n6urj14v62qXRaJgkm2B2EneTp9rwEgPqvrbiGLBQ+E5qrdtG8W5zf/8L9iJbfijvls4kpp7SNZGtcrve9HHoE792MvB8CKkwF7QhPAYnSbyA2Tlni2hlQyE8SDmUvp14/vvPlDDF8YXJC0MnqCHlR6IKdH2IOjMH/sGbhu2gjYk5fuQqHFuIbZOC7fB1nQcI89ucpWSekHDhj/b6iuc6DMIr3cewkZo3mZaHyoOCvoO3KhaDcwTvsq9RB4/LprE5igTvQ8JvkeF/odzSLcZfH1W7dtlpP72jh5qixgycHMEo9JvcuIS9Ic/kw2hVvT/Ic35jREPazTM908ZI/WSnyukUGkaHDxO42it8GthuN9beVbB7ETop8MLi0B5bHVNn4//ZA2R5zN+sMqpr6hrJCXa/gR8NQM3LZB5gPZWDVDCf/U8MHhlVIYi8yROololy0b7bHnv1E3J3QxH/atWz56qjs528QJtA2h/ir/2yrrOxC5gqFGOdH/1M+O2PK54+hJCboftdLXdPioMgvNJQNpHh+GYhr6blw0szw9Gox3bBvhMSsM27YSK3akpf0zs3ljKw9KLnzY7nc4TOpupPI3J2wkokWhs01ScOrfbHg1Iwy4sMI/KDXKnh8hacgtl71oevLBwJ3+ZoMOFTLrontNmr6vLowY5LU6TyvhJP0GkW0mmQ15V+dPdKo+qX1E9csxV6SOl6qHTEiEZYSfQUgwvHEKxgs+GX/RYLvCs+irdeHfijc0vJ6Vocq1TBhwDe9FELt4IWA5A==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8137.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(3480700007)(107886003)(53546011)(52536014)(38100700002)(4326008)(38070700005)(66946007)(33656002)(8676002)(122000001)(86362001)(26005)(66446008)(66574015)(66476007)(966005)(316002)(76116006)(64756008)(66556008)(8936002)(54906003)(5660300002)(110136005)(186003)(166002)(7696005)(99936003)(82960400001)(6506007)(83380400001)(71200400001)(55016002)(2906002)(508600001)(9686003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SkhTSGVjQzVIZ2tVTUpoMnExMUxpZlhFYjR1aTVZUGxhSkU2bHNySnZZeGF6?= =?utf-8?B?emlsOU5XUDVFTEZxQm56TGI5UXJCRTZNb1hRTk5scDlXL0tONjZtYlRjZ3VY?= =?utf-8?B?U2dQM3FpMnlPR3d6MVJqZFBUd0dmU2dReWNQbFVsVVZ6Slg5cjRwSlczcUV4?= =?utf-8?B?QjF4dTBHM3dqRVJqYk5VVlZGRHRzY3ZTcmZ2bjhFOStPYWVZbGtwV3BWTlFJ?= =?utf-8?B?RTJ3Rk1FRWg2S0RPTDA2WlJEb0hiOURyZEpXd2xMVm01L05kZ0d5eUdvWXA3?= =?utf-8?B?bmdpaHArYUNSYnF4b3hUVG5HVE5CWkFQRmtHU3B4YnJWQzgwaU5iYUwyMjVU?= =?utf-8?B?SlJJUWVBYk5VV254L0F1SWNKWU40Z3U5VEY3VHRCem9DaU5rVEJIMzFLUTlt?= =?utf-8?B?aEJkcWJGb0lwalE2OXBSN2pMallvYmxBWnJlcHM1TEw0SmNXcTdVQUp0allY?= =?utf-8?B?ZGRwVHc1SFhpb1Vacm8vY2FHTVI3dW9SYktWSHlYQ1BRdGZRNkEwSWdDUWJR?= =?utf-8?B?aDd0dlBGbU9peHppOW84Z1N4cngwYkZYa3hoeUZ5YVViL2c3Z3ViNjF2SjJ0?= =?utf-8?B?bjAzWUMyS1RzNkhyRVRDOU9DS1BFUmgza09GYjg4KzRiaTdtcU1YdHNrK0Fs?= =?utf-8?B?N2NKWVIxUjg0M3M2VTFDb0NRbHBkRmkxZ1RnQktiUm81TVVmeHdOQmdDcHVm?= =?utf-8?B?eEtIUTB3blpsdFN1SjNGemhvVVNNYXVDaHdWeHpoMnp3UnNKZnJOL3ZKUWly?= =?utf-8?B?NEo4dWszUTduWFo0Q09JQlA0QXJpM2tGemhndEZVSDJaR2JIMWx4SDhYTmZu?= =?utf-8?B?N3Z5amNCWUlsZU0rdE9RckxUQ1FPUlh6OVRNYi9XUXNlRm50dWIyV2d4Q2lq?= =?utf-8?B?UW93ZU5EaUVyakhPbXhVdVc0M3BHblRnM0YyNHFBZ3NuQVk3RGFXT2IzWDBi?= =?utf-8?B?RUl3MFlYTXVxQTZ6UUtJTmhrbVBselFrNk5UZDN5dkcwSkRQRWJSZjB1RXVW?= =?utf-8?B?RFJCU1JGQW9uWHh6NWdKS1IybU5wN1NOVmFJNkp4RFhYalhOMmNXN0xkTzJv?= =?utf-8?B?UXdBTnFDdTI5OFVoYzgxdG5CeU50Z25kTVZ2Y1VhQjY2T21aZTJ3TUFnSHRM?= =?utf-8?B?Y0ZhaGY0MWlyYkhZL3lWNjNOVFh5OWNZUFRrSkhHL2RQeSs1QjlOcmVWNFNR?= =?utf-8?B?aitoSWgrUFVnNUxHeitXS25oUUZxTURCWEY0TDZJN3dsejc0VzFZMG5mR3BZ?= =?utf-8?B?b002aVVIT3NpaFQzUUgyTUxvNFJFNjd3aTQxUzFsQjdyK0I5ejNSenBWMFBh?= =?utf-8?B?bVFzMXRtSzBIaEhXWlpaVzR4cXFUUWtkRjYzTElHcXhnL1lEUjdSelZmdlE2?= =?utf-8?B?MnFsSG5zeFU2SGV3Q0xDYldCYUdXSTN2Sll1eTRSdFJscmNpdjZsaUpiK1A4?= =?utf-8?B?aTY2eTZKRm1WZmFWR29pYzlrVkh1U2dmR3M4djZiQUNWQ2w2MzVibEl5ZEds?= =?utf-8?B?dWZaUmhheFp3aytCcGtDb1ZwR3JvNUpUempiZG85cnQ3bTE5d3FOZ25GL0JK?= =?utf-8?B?dktCNGJ1WnQ2elBwd2NCOTBaazlFakJPbE9UKzhOTXNlOVpCblR6Z040TnIr?= =?utf-8?B?RUpCSXpuQVRMYmk0aXlKblJvSTRZY2dTa2JESERuZHFvdkRnZlZoeTlpSDh2?= =?utf-8?B?ejNtbGJXR3pVWVdtU0Vvb0QrcUhwNkRNNDBlbU9SVWFnWCtCM3A4aHhoVEl6?= =?utf-8?B?d3R6Znl3V3VtcnVJK083YlA1VFBieEJaRXJLeFZKbm9Cd0V4ZnFHNThubUpa?= =?utf-8?B?dVd4U0wxaDBzeTNDeStKbEdyRG92MTZsdFBxOEcrZnhkNkVseFdNaGVVTlR6?= =?utf-8?B?Um1HcnZtSmxlcWZubU1FeUNOSmFNZmdNRzJJMi9UZENNWk5CSkhNN21kRU9o?= =?utf-8?B?RWM0SzlLYTFNaC9VUGdOa09YbVVDSzRBcm1pTnhkaWJOeUZ6Z0pLcmZheWtl?= =?utf-8?B?WHNFcXdkQVlhVEI0a3MrNWJ4WnNzTGQzUVh2SGpWK1gzdGxSZ0YxWjhtQmh2?= =?utf-8?B?c3pieGM5M0w4SlM5NC9uL21RdmE0SFIwVUdkZUNyZXpQdHY0dHVEZUY3WTZt?= =?utf-8?B?NDNyRXYvUzEwaGxkdjQ1S2NwcER1dlNWUGN2TmZGZ0NiMDlZUjZtUnFCL1RC?= =?utf-8?B?cU03QklzWWxFSDhPQ0tnVC90VzcrNC9ReXZIWlJBaDdSb0RFNTBVTFpjbDhx?= =?utf-8?B?SlpVcGRxbWd6L2hQMWFFZ2ZjQTBPR1BObE1jLzNLQ1RzUDNoalJGQVZVVkp1?= =?utf-8?B?YW9HaXVFQ3YzeEc3djVrNXBnQUdzZi9wZnJJaWREZ2s5Q1llajFIZz09?=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05A5_01D7DAC1.E3FE34F0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8137.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c01ec54e-3ce9-41e0-0489-08d9a8d0a5c2
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2021 07:13:53.5483 (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: CevrPrRrzcTfqtQGzsUTjHI4KoUs4BRm4J4noNW5wFmF6Ks6W+1iiprt+cp4gmBcU6BP/K7T0I0m0r2ejViswypu2XK/qte4B3mBHJlNDPVA2ZvISD9G2hSy1poX1Cu2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8148
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/YnV_ugCsPKTNZy2qF8rlFME6SFI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Nov 2021 07:14:06 -0000

Hi Vidhi

You are right 😊

Receive time stamps is of course better, the benefit is that one don’t need to worry about possible reverse path congestion, the drawback is that clock drift needs to be addressed.

 

/Ingemar

 

 

From: Vidhi Goel <vidhi_goel@apple.com> 
Sent: den 16 november 2021 00:41
To: Joerg Ott <ott@in.tum.de>
Cc: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>rg>; Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>rg>; mathis.engelbart@gmail.com; Ingemar Johansson S <ingemar.s.johansson@ericsson.com>om>; IETF QUIC WG <quic@ietf.org>rg>; avt@ietf.org
Subject: Re: RTP over QUIC experiments

 

+ Page 18 : Inferring the receive timestamp. What is suspect is that you will essentially halve the estimated queue delay (I assume here that the reverse path is uncongested). One alternative could be to compute
receive-ts = send-ts + latest_rtt + min_rtt
where min_rtt is the min RTT over a given time interval

You are right that halving latest_rtt / 2 may not be accurate if the reverse path is not congested, but there is no guarantee for that. So, a more accurate way to compute receive-ts is to use One way timestamps which can be added to QUIC as new Frames.


As long as the metric is taken for what it actually is, a rough
approximation, we can probably work with a number of ways to measure.
More to experiment.

 

I forgot to mention earlier, but the equation for recieve-ts should be (assuming queuing is only in one direction)

 

receive-ts = send-ts + min_rtt/2 + (latest_rtt - min_rtt)

 

Right?

 

Thanks,

Vidhi





On Nov 15, 2021, at 12:34 PM, Joerg Ott <ott@in.tum.de <mailto:ott@in.tum.de> > wrote:

 

Hi,




What I am trying to understand is, what is the motivation behind running real time congestion control like SCReAM over QUIC congestion control? The results (as Ingemar also mentioned) are not encouraging.


we should clarify that this wasn't a design choice but rather part of
systematically looking at the four combinations you get and then see
what happens to each one of them (we didn't expect this one to fare
particularly well but we were initially a bit surprised how poorly it
performed).




If we want to use a single QUIC connection for media (audio/video using RTP) and other reliable streams, then would it be better to not use QUIC CC for media streams and only use it for reliable streams? Obviously this will violate the current spec which applies congestion control on connection level. But maybe this use case can be specialized.


This would indeed be one option in the (more desirable?) design space:
the question is if you should allow libraries out there without
congestion control just because something claims it's real-time media
and does its own.

Somebody may have mentioned the circuit breaker last week in some
context (too many slots, sorry).

Indeed, one idea could be having a QUIC "enforce" a limit that it
considers acceptable for the current connection and provide the
RTP CC with the necessary parameters to come to a meaningful rate
itself; as long as the offered load from the RTP CC fits the
enveloped computed by QUIC CC, the DATAGRAMs could just flow;
above that rate, queuing or dropping (or local ECN-style signals)
could follow.

It remains to be seen if shared congestion control between real-time
flows, other datagrams, and regular QUIC streams can be done in a
sensible manner, with acceptable complexity and little brittleness.
And if there is a strong use case for such.  This was quite a bit
discussed in the MOQ side meeting.




+ Split of network congestion control and media rate control : QUIC already today has the congestion control on the connection level, it is then up to the individual streams to deliver media, subject to the individual stream priorities. SCReAM is quite similar in that respect, one difference is perhaps the implementation of the media rate control. I think that with QUIC one should do a full split and do the network congestion control on the QUIC connection level. The congestion control would then be some low latency version, perhaps BBRv2? or something similar, I am not sure that the network congestion control in SCReAM is the idea choice here as it is quite a lot tailored for RTP media. 

The impact of cascading two congestion controllers (with different input and output parameters) has not been studied extensively yet. And is a real time CC like SCReAM by itself not enough to control the congestion in the network? In other words, does it need another congestion controller to make sure that the real time data doesn’t cause more congestion in the network?


Right.  The main question is: should a QUIC connection trust the
arbitrary datagram source or should it check.  Given that all sources
(datagrams and otherwise) would often be part of the same application,
there is probably not much point in trying to cheat on itself.  Maybe
some sanity checks would make sense, paired with mild adjustments of
the share given to the reliable streams as the codec source traffic
won't be able to follow exactly a given target data rate.




My SCReAM experience is that one need to leak some of the congestion signals from the connection level congestion control up to the stream rate control, to make the whole thing responsive enough. In the SCReAM code one can see that the exotic variable queueDelayTrend as well as ECN marks and loss events are used for this purpose. I believe that something like that is needed for an RTP (or whatever low latency) media over QUIC. I believe that it is necessary to leak congestion information from the connection level up to the stream level, especially to be able to exploit L4S fully, even though it is a bit of a protocol layer violation.

We absolutely should allow sharing of network events, like RTT, ECN, packet loss from QUIC to RTP. Not sure how it is protocol layer violation.


Yes.




+ Page 18 : Inferring the receive timestamp. What is suspect is that you will essentially halve the estimated queue delay (I assume here that the reverse path is uncongested). One alternative could be to compute
receive-ts = send-ts + latest_rtt + min_rtt
where min_rtt is the min RTT over a given time interval

You are right that halving latest_rtt / 2 may not be accurate if the reverse path is not congested, but there is no guarantee for that. So, a more accurate way to compute receive-ts is to use One way timestamps which can be added to QUIC as new Frames.


As long as the metric is taken for what it actually is, a rough
approximation, we can probably work with a number of ways to measure.
More to experiment.

Best,
Jörg




On Nov 12, 2021, at 8:28 AM, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org <mailto:ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>  <mailto:ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>> wrote:

Hi Jörg, Mathis + others
It was nice to learn about your activity to try and use SCReAM as example algorithm to integrate with QUIC. Pages 14-25 in
https://datatracker.ietf.org/meeting/112/materials/slides-112-avtcore-ietf-112-avtcore-03 <https://datatracker.ietf.org/meeting/112/materials/slides-112-avtcore-ietf-112-avtcore-03>
Did you use the new gsteamer plugin fromhttps://github.com/EricssonResearch/scream/tree/master/gstscream <https://github.com/EricssonResearch/scream/tree/master/gstscream <https://protect2.fireeye.com/v1/url?k=4c40e89e-13dbd19b-4c40a805-86d2114eab2f-5bc01f3ec9be70a9&q=1&e=fac4681d-c4fd-439d-89fa-e885e47e4764&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream%2Ftree%2Fmaster%2Fgstscream> >  ?
Observations/Comments:
+ SCReAM + Reno : Strange that the throughput dropped like that but perhaps an unlucky outcome of two cascaded congestion controls.
+ Split of network congestion control and media rate control : QUIC already today has the congestion control on the connection level, it is then up to the individual streams to deliver media, subject to the individual stream priorities. SCReAM is quite similar in that respect, one difference is perhaps the implementation of the media rate control.
I think that with QUIC one should do a full split and do the network congestion control on the QUIC connection level. The congestion control would then be some low latency version, perhaps BBRv2? or something similar, I am not sure that the network congestion control in SCReAM is the idea choice here as it is quite a lot tailored for RTP media.
The media rate control is done on the stream level and is then subject to stream priority. This should give a more clean split of functionality.
My SCReAM experience is that one need to leak some of the congestion signals from the connection level congestion control up to the stream rate control, to make the whole thing responsive enough. In the SCReAM code one can see that the exotic variable queueDelayTrend as well as ECN marks and loss events are used for this purpose. I believe that something like that is needed for an RTP (or whatever low latency) media over QUIC. I believe that it is necessary to leak congestion information from the connection level up to the stream level, especially to be able to exploit L4S fully, even though it is a bit of a protocol layer violation.
+ Stream prioritization : … is a problematic area, especially if one stream is low latency video and another stream is a large chunk of data for e.g. a large web page. With a simple round robin scheduler, the stream with the large chunk of data will easily win because it is quite likely to always have data to transmit. So some WRR is needed. I have even had problems with the algorithm in SCReAM that prioritizes between two cameras/video coders, this because the two cameras see different views and thus provide differing information content/compression need.
+ Page 18 : Inferring the receive timestamp. What is suspect is that you will essentially halve the estimated queue delay (I assume here that the reverse path is uncongested). One alternative could be to compute
receive-ts = send-ts + latest_rtt + min_rtt
where min_rtt is the min RTT over a given time interval
Regards
/Ingemar