RE: RTP over QUIC experiments

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Tue, 16 November 2021 08:25 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 8B1173A00C0; Tue, 16 Nov 2021 00:25:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level:
X-Spam-Status: No, score=-2.802 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, 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 1mw7Oea1hlaE; Tue, 16 Nov 2021 00:25:02 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130052.outbound.protection.outlook.com [40.107.13.52]) (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 DCA023A00C1; Tue, 16 Nov 2021 00:25:01 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eNAhcC8hvGH4q9AQJR104C0WmbLaGAf1ZY+lokKPCHSHzkcTkgVR7yb2aMP8dA1frRnRxt8K+df6RdoigKxLQ0NYxZl/4nevFY02Px6B1BpnQgClG7qjaZ0q04W8Jqtysq1UYOVzMGMBCh7zRHsSdGpkYJPPJL8SoSwYLOtsvX7ykV1ZRRHan4GOrrG2yB0pNx4/dwpuTAjUsRE++EMoUDRXWRQU5WlmllS5Z6vfP3kJCQkJ2oxhEMXECKfnjlKn4/E07IE/A4izdk/1TntB3+wTr6npaab9Kq27s+Se7H4BQ9Do6vqzD7x4SMVdUpqbaOlvE9j0aMUx0InXDnhuHQ==
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=z2gTGSUA6EBpcPcWoi5zq7bxgo8D4a7pTNru/EW+97s=; b=ieKaILkh2ejo5BTjOdrmk9fTe1Iig+26oaaKCDmJQwDZhDNmNWe66m2JOoAQeXlgXf9G+9ULmQcFR3y38k3E0emEqu4RpFIyjMyF7L9Il4O9VpQ5o6bw/WqY20l0zrkS3JY6WqgSgKFBsplU5aYoRu99ogDj23iIr+mSYIb7mEMhPsWj0U5hUQ0k141PBCU2rt6yFiS0KmsqF5PwuvnDR1XPpaQi2YUcGme3rLCMMmxo49e8KM6it9QWuFbvLfrGouFHF+FJsiGJj8ZOGkeimm3PlN+wV84nschT2SZjxFBQbzyTYNJL1dSZKnsPg3re81NZGhQSXt2w1C6ouw+VUw==
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=z2gTGSUA6EBpcPcWoi5zq7bxgo8D4a7pTNru/EW+97s=; b=VrIaq5nJfYwyOqOYf3ehOUOyNqmQHG8C2uGxb5/I8FOYly6q5Ei0JtS6Af2LHUOUzB5k4suWfKLRl+r6Z1JmruB0MCSbTEiD34MV5xGOeo2HfruxzzMXZcJ8axuasZgXw5x4kibeFz+VUn01ZRRxSDnFZ5uF5DqRDVe2xc7ngw8=
Received: from AM8PR07MB8137.eurprd07.prod.outlook.com (2603:10a6:20b:36c::18) by AM8PR07MB8124.eurprd07.prod.outlook.com (2603:10a6:20b:36f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.14; Tue, 16 Nov 2021 08:24:56 +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 08:24:56 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Joerg Ott <ott@in.tum.de>, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>, "avt@ietf.org" <avt@ietf.org>, IETF QUIC WG <quic@ietf.org>
CC: "mathis.engelbart@gmail.com" <mathis.engelbart@gmail.com>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: RE: RTP over QUIC experiments
Thread-Topic: RTP over QUIC experiments
Thread-Index: AdfX2qCtpQbe7xxBQleaYoCld3uW9gCg3ZoAABivfTA=
Date: Tue, 16 Nov 2021 08:24:56 +0000
Message-ID: <AM8PR07MB81379B96B9FCB356DDDB3985C2999@AM8PR07MB8137.eurprd07.prod.outlook.com>
References: <AM8PR07MB8137AD430709AC54E6EA361CC2959@AM8PR07MB8137.eurprd07.prod.outlook.com> <87375eb3-09b3-d2c4-2e5f-2697745954a3@in.tum.de>
In-Reply-To: <87375eb3-09b3-d2c4-2e5f-2697745954a3@in.tum.de>
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: df25c787-c977-46a5-6b94-08d9a8da92c3
x-ms-traffictypediagnostic: AM8PR07MB8124:
x-microsoft-antispam-prvs: <AM8PR07MB8124C7013C26D62EB8346021C2999@AM8PR07MB8124.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: X7ftjVWFVFX8UYcbwirfBU6Lb/kRyykEtN7y9qNvoRIx/eEWAIMZ6QNFudXeYoW2INXMGHniAwxDlPuT1LsdVUAyW4/HYmeyKpXaguRbvZBIdsFZPH8x5TNqYsH0Nh9dMxihCeIm4Uwr+16a1HF2cF/14wRdblby2kovN3KK+favdNeQ6n3GZSI4gYuYyUTZthXv9/81Bx7In3nreJxKqezxjsaYLXj0LN0VKhKWwz+jdCNbwNZ7dR7g7BtcmfXHme8xpy2Zc9sShZF021jK1H/gVfAgNVz826l/bK8CLG71eVHS01PbyHXcWq957fkYDRNilfPdRF4VRIhoQhY9o36/IO4cSo8tzwkkgoxYIWHTuqMI+Ut/0C6G23dB57TVbZohsYYgL1DCo06Bs8cJOmUjcPb5/eTqehtOeA76lLl9v03Gb3U99ihd7rSRZiGavg0uB0Z6LO23tXiiQP4yz+Uv/etGV2DpSOqz7+bw1UuGp0uj3OYbFAZl264mCDhw19/A7gYXwQcBYN7y0ly2HAzzjokslcGEe+mEpGqZl2iZZGvD0jkmT+VK5XsR9ncT5IF1ZE8ekYaUoJHNvyp4MlKnQqsuiGOR7KhoArrV60BJ3WJ1W7PNXdLSrNvnqFcc/CwjAj5TnNk1gwX/hLxLBy6EvvaDFIKs/7X6oudTIGHofYQGCUm/DgLMVQl9scH8ffvz+p54mxSir4dQ59V6JR6XxSkPKq/pnqTX7qoeqiOwByH/4PnLJv5BPkbNrPQvJ1aeurYaLTyBKs7C/gk0qk/OeS7fvexhcYI9CyZJlWkCo3p6g2ZifgJTJuVme8ghgbmdzTUmUIzx04G1Qx9pGw==
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)(316002)(7696005)(107886003)(8676002)(4326008)(82960400001)(6506007)(66446008)(52536014)(54906003)(8936002)(110136005)(99936003)(9686003)(53546011)(26005)(3480700007)(33656002)(38100700002)(966005)(76116006)(66556008)(86362001)(64756008)(38070700005)(66476007)(2906002)(55016002)(66574015)(83380400001)(508600001)(186003)(66946007)(71200400001)(5660300002)(122000001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SUhFYzVuc0tvY0MwWUFpbU1KOXEvU0ptdHgzMWhUZ2ZjM2pCYUIwb3VjN1Y1?= =?utf-8?B?cnBvWXNFNHVOMTdzVTN1RGtlZ3d3MERyd2JibXNvZnN3QWJmYlR0cFFYcitN?= =?utf-8?B?NDQvTVVtM1VvREZuNnUvVFVsSG9tOVlFMjBiZFhGc25nSjh0OUN2cHIzeDla?= =?utf-8?B?WFhHWnUvVEN6QlhES1JHYk1kaUQvNjJaQlpDRmlTWHpsT0owbmJrRXRHR3Zn?= =?utf-8?B?YTZBZUE1dEMxRnhTdTJLdGdod08zMGszMlplZjI2TDFZenUveS9OSk1BWjFy?= =?utf-8?B?eDJtRXB6MWtSekV6RHo2R3FPd0dzVWNKYSs5WTFwV05YWkpqRCtlbHNwK1Mx?= =?utf-8?B?ZzAyOVd3ckxJZlFPQjhOWlQxOXZSZWdwbE4wdm9KczVNZ2RXM3VlY0JPdDJ2?= =?utf-8?B?TE04NmNMQkVvQ2duSWp2MTBNOWRYQXI0Zzl2MW1sbURCa0VWdkR0em04Mzhs?= =?utf-8?B?bTNHeUNFMFVrUTN4czBWNjJDSFBkSkZ4bzJoRzJQSUNRRCs3LzhVTFpMdmkx?= =?utf-8?B?RW1SVkRIR2ZCOWp0dzN3M3JvVlRtZEhlUnIrRkE5QmNxT0JSeWw3N1RidWY5?= =?utf-8?B?bTRvZ1VCQmpIdHhSSHhaQkZBWk8yWnZPYlFUZWdJU2ZQT3pXdFJjWFdXK21L?= =?utf-8?B?WW4yOHN3Rjl1NmxlK1Bxc1FGTDJXU1NIdVBVMnZETnh5RG1WZUxzR1JlV3ZD?= =?utf-8?B?aE8yeXZBU0llWkc5dmRWSjB1eWFFdkx1bkw0U3BFSXI2SjZFTHlsMWlpeXAr?= =?utf-8?B?VVp4OWx4RkZmTkJMOGhZdmZERUpSdm5NRE9jbzN3ejdQdlhrYmtoWFU1ekdB?= =?utf-8?B?ekc2MEJpek5sWlRPRGNOZElFQmt1NHlCWjlrd2o4c1FwOEMzamgrMk9QNDRh?= =?utf-8?B?NkIzNDZLY2N0OFc0VVRFbjJnWXJuK1o3NDg1d2NyWkZsT1VSTmxrRkl5UWhM?= =?utf-8?B?TXNBaG1UMFA3aUNnaytRTFZlSXlCUURzUS9iQ2EyTmphVkJUZ0dpcy9mQi9G?= =?utf-8?B?RHRCWEJsZmViM2dmd3ZpNjJxMlEzQnk5dS9OemZlcjk2aUViUUZJNEtVS2pE?= =?utf-8?B?SFlxL2prQWp3S1FtSStGR0RXcUZ3TlV0RjZQN3I5SHh0N3NRWUVOc2lOdlQ1?= =?utf-8?B?TWVSZFc4bDBWQ0RORk9mYnpFaTcyNG5aeS91V21MVi9lbjRUWTBBWTE2RGpK?= =?utf-8?B?Z3JacWdOTXM4WlFKbEJ5cVJ2WWNZeVlSOHlQK3ZmQ1dUV2tQdjc3d2xWVHJ1?= =?utf-8?B?VlJjMlg3M2ZNMUVtbC9aVXc4TFppZjd1SE9wOFk0ZFMwS2h4ZFFVYnRrWXJo?= =?utf-8?B?akgwTUxPc0Q0K0lTQ0wwZXp2RFZoWk5HNEJNMkdjUHpENldIcHM3YjZzRVB2?= =?utf-8?B?MUtxV0RkT25Od01jUUNSL05xK1RDcGRhdEliUE0ydEtUWTEvSmtNWHJta2tu?= =?utf-8?B?SnBOYWNYL292SFlDMHRhYnpEaWtWYmlNMjg0V1orazc3SzdFUlF2Z0xZUDd6?= =?utf-8?B?TDZVMUUweFY3NXJkZmJnVUtEVDdSL0dicUJoalRQbFkxWkR0UW5EQjliSmxZ?= =?utf-8?B?TC9xVmxBaU80c29BRk82WkxBKzhRNUhxZ2E2a0M5VERTRkQwa2djY3pNOVJB?= =?utf-8?B?emxobGNSdHhrRC96SnE5eWRlLzVmemE1UkVveko2TnNYS0loVW4zclE2YWxP?= =?utf-8?B?L3A0Qno5QWdrb3BsYmMrL1QyU1Q3WHhVekJSdDJYYjVrOTF6QWpKSC9OL28z?= =?utf-8?B?NEhUU0gxUmlQTDN3TnJqUG0xcGJGc1BmMS94TldvVVFpM0E0L3BMWHh0N21E?= =?utf-8?B?UUlkSnNTdzJUYmpPMmRnSlp1dGtrL0cvaVhxNG41M0Jhc05XMGM4cFFIUkpS?= =?utf-8?B?U3VBeG5MQWZLcnl6OXhqNFJsM3pubExYa1BsMG1MVGRzcEdFcjZrR2tiQmRs?= =?utf-8?B?Y2s1Y2V4SVBHTjgyYWo0UUQrdC9wOTUvU1RJYVFmRjZWdFU3eDFDamwvTzJ4?= =?utf-8?B?QVRHT3hZN0wwMEpoMkI0akQ3ZUJqelc0OVlyRWhCR0lTckNac1NDZjdkc2FS?= =?utf-8?B?Uk9UMFFOMERqalBZNGVlM3REb3JyMzVtSWRkc1FwVkJJV0ZiMzI2NVBHYXRK?= =?utf-8?B?Z0ZmN3BvbmpRbzBSOFJYU3o1Mk1pUVVKc0ZnRGlYem1qenBGaW5OaFZxekQ4?= =?utf-8?B?RzFKREkyeGt6WGVKajl5SUJZd2U4U0ZOUkpiOVBvdGFBYXRuWmtFdjArT1ZQ?= =?utf-8?B?SnBGWklCdGdyNmFXd2ZCNGJ2Ly9EOHFDdURRaFgvemdwVW8xTWc3MnNPcEJY?= =?utf-8?B?UWUwWXVpUjh2M1hrbGZaczVhSTdybFZxMHQ1WlE5c094N05RUGtBdz09?=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05ED_01D7DACB.D125A340"
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: df25c787-c977-46a5-6b94-08d9a8da92c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2021 08:24:56.7805 (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: mHFmYqNeFOEXZDRGTx1YQFF8g6XH6NNJDBQz0MCBU5LfKq7/GwoprxmbywDI4OMTxq7ax4vuVuyjlTQUg5CvgZX2KpY526rwL+D+lQhNE4imao3SuVdxn9bcGeLasq0u
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8124
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/W8K-1OghByNpvRF9HeDqSrMErqU>
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 08:25:08 -0000

Hi Jörg

Please see inline

/Ingemar

> -----Original Message-----
> From: Joerg Ott <ott@in.tum.de>
> Sent: den 15 november 2021 21:19
> To: Ingemar Johansson S
> <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>rg>; avt@ietf.org; IETF
> QUIC WG <quic@ietf.org>
> Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>om>;
> mathis.engelbart@gmail.com
> Subject: Re: RTP over QUIC experiments
> 
> Hi Ingmar,
> 
> On 12.11.21 17:28, Ingemar Johansson S 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 from
> > https://protect2.fireeye.com/v1/url?k=08572266-57cc1b66-085762fd-86fc6
> > 812c361-628ef39f33771783&q=1&e=e4b293a8-5f25-4c05-9d2e-
> f15862439753&u=
> >
> https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream%2Ftree%2Fm
> aster%2
> > Fgstscream
> > <https://protect2.fireeye.com/v1/url?k=6c2bb408-33b08d08-6c2bf493-
> 86fc6812c361-ff87cf79fe3fb90c&q=1&e=e4b293a8-5f25-4c05-9d2e-
> f15862439753&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscre
> am%2Ftree%2Fmaster%2Fgstscream>  ?
> 
> Well, we use your C++ version (forked a bit ago), not the plugin you refer to.
> This experiment has already been ongoing for some time.
> 
> > Observations/Comments:
> >
> > + SCReAM + Reno : Strange that the throughput dropped like that but
> > perhaps an unlucky outcome of two cascaded congestion controls.
> 
> Nested control loops may not play out that well, and this seems just
> one artifact of this.
> 
> > + 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.
> 
> It is but it attends to the specific needs of real-time media, which
> cannot really be said for New Reno and many others.


[IJ] Yes, one definitely need some kind of a low latency network congestion control, I guess today the lowest hanging fruit is BBRv1 or v2

> 
> > 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.
> 
> We would have tried BBR(v2) if that was available with quic-go; on our
> list, but there is only so much you can do at time :-)
[IJ] OK, understand the problem 😊

> 
> > 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.
> 
> Right, we are currently exploring the basic combinations with lots of
> tracing and try to understand who impacts whom and what and try to
> disentangle implication specifics from protocol aspects.  So take this
> as a first step of a more comprehensive evaluation of where we are.
[IJ] OK
> 
> A next step is understanding how you make the two work together so that
> you can preserve the fact that QUIC congestion controls everything it
> sends; this will then go more into a bit of integration and API
> discussion.
> 
> > 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 are all in for leaking (well: sharing) useful information, and one of
> the main questions we tried to address is how much RTCP signaling for CC
> you would need; well, and it seems we can do already pretty well with
> what QUIC has built in.
> 
> This helps using RTP with one of its congestion control algorithms on
> top, but we hope it could also help understand what you'll need to do
> an RTP++ (or: MOQ) on top of QUIC without all the legacy baggage (if
> that turns out to be useful).
[IJ] OK, sounds good, 

> 
> > + 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.
> 
> This is an interesting data point I'd love to learn more about.  Not
> surprised that scheduling would turn out to be one of the harder nuts to
> crack.
[IJ] I believe one can find some evidence of the problem in the SCReAM code. The stream prioritization is implemented as a WRR scheduler and works so-so (https://github.com/EricssonResearch/scream/blob/master/code/ScreamTx.cpp#L1682).. Still more code is needed to ensure the given priority (https://github.com/EricssonResearch/scream/blob/master/code/ScreamTx.cpp#L1651), the latter code is run every 1s when the link is congested. Without this extra adjustment I had the problem that the rear camera in our 5G toy car dropped down to real low bitrates. It is possible that one could do this smarter.

> 
> > + 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
> 
> That could work.  Still an area of experimentation (min_rtt may have its
> own issues but that would remain to be seen).  QUIC rx timestamps may
> help us further. So far, we mostly investigated different ways of
> interpolating; tried different alternatives.
> 
> Best,
> Jörg