Re: [AVTCORE] [rmcat] Notes on CC-Feedback from the Hackathon

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Mon, 05 November 2018 10:00 UTC

Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED27130F1E for <avt@ietfa.amsl.com>; Mon, 5 Nov 2018 02:00:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.771
X-Spam-Level:
X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=hh/pzK/O; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=BeAuaEuR
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 MMAXNW36NMAJ for <avt@ietfa.amsl.com>; Mon, 5 Nov 2018 02:00:28 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 4CE04130E6C for <avt@ietf.org>; Mon, 5 Nov 2018 02:00:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541412025; x=1544004025; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SA+kai6lActQ4KjNd5r+tUQAM8kDGxHm46xqDZSPYSg=; b=hh/pzK/O7yAEWDZLkYM7PdlmJmyHAVAspNvSKZr86KtepRwbXMps2KfYz8Od2uFw f3itUPBweBKNXIgfet1Qi7IQgzKpl5LLaEE3tVm2tmLm3ov/bI85ac2DOyuRFLJt tZzZT/oZyj573dvGoydhFaGYVGFa+oN/T4AVVY4qE78=;
X-AuditID: c1b4fb25-f3b359e00000414e-8e-5be014b942ef
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 42.89.16718.9B410EB5; Mon, 5 Nov 2018 11:00:25 +0100 (CET)
Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 5 Nov 2018 11:00:24 +0100
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 5 Nov 2018 11:00:24 +0100
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=SLWDHG9rJpR5eQ0SfaUtjXym6OAzciu12asfG7ziIb0=; b=BeAuaEuRxnGMtXjfCfbPcH1C6sHFTe2id62ZFy21LvvvXJOq8y+3F9cEACUruB+Ea0JVJKbm+KKpLLUwi5ABObVg1PApJJ2nkRdb3SXY+VndQ8CQAo4lJuoZw5W1bmY6DshPBFtJxEptwH+YbPkzPn6t3WVwFAdiqbRV/qgaxEM=
Received: from AM4PR07MB3396.eurprd07.prod.outlook.com (10.171.189.157) by AM4PR07MB3347.eurprd07.prod.outlook.com (10.171.189.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.15; Mon, 5 Nov 2018 10:00:23 +0000
Received: from AM4PR07MB3396.eurprd07.prod.outlook.com ([fe80::a99b:80fc:ebf2:9b3f]) by AM4PR07MB3396.eurprd07.prod.outlook.com ([fe80::a99b:80fc:ebf2:9b3f%2]) with mapi id 15.20.1294.032; Mon, 5 Nov 2018 10:00:23 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Jonathan Lennox <jonathan@vidyo.com>, IETF AVTCore WG <avt@ietf.org>, "rmcat@ietf.org" <rmcat@ietf.org>
Thread-Topic: [rmcat] Notes on CC-Feedback from the Hackathon
Thread-Index: AQHUdHlIdmJO8OyjZUmacvcOxX+wU6VA8pyg
Date: Mon, 05 Nov 2018 10:00:23 +0000
Message-ID: <AM4PR07MB33969EA466B0DD5F2F6098B0C2CA0@AM4PR07MB3396.eurprd07.prod.outlook.com>
References: <03492708-99E8-4792-94C9-E8C04D849919@vidyo.com>
In-Reply-To: <03492708-99E8-4792-94C9-E8C04D849919@vidyo.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.176.1.92]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR07MB3347; 6:6VdEdG8FvQXI8t3LHmSAOqxsyylS6cjqrN29MDmsBc+MxHSlVD5I+88Ewm3jp2kF2Eb2Lkj8gbAwijway3KslXpmbq/CZSJSezkTmI9z0zVeZLjtYWNxA13mG+o1ZD6Ky+a6zkhZOUjalWwK5D2n/VIL8YdWsqC4xHdr7mz8HEQWBkZZ2WhAafeowzuh2M3948SyjmDX0+raBCkdnui8joBmWa6w/8uSTToPQJ6mMmL3UBGF7rHD2HMOD05IS7X4+LKm0m09dbDfRVfmzalxQ/Al0rulECd/UdbEU8497KgkNp4WVAK8Zh81552kuYEtW1t3gqsuEHZyU7s/xuBO+5M+X1jaeFVJJ6jcTsyIWb2/Nv996GeBJsp5L1ts8seMOpQbaMQv+lb8LoIy9NcSwjvQJdsIHz/6Whx89JS7RLa6IlGdnDdbFeC/M3xgAo2suRQ9HenfR4zY4EOMPAQNxw==; 5:ec00e+ZM3H/y9eu0MwvDXeihB2NkSINMxnNN4ROVCtPJm4fzqQFNZruB59cXObbTsoGYUCdMTQPlxdQGHsK4ITiY5gFTSVu2C3ISPSoIPO8MCojB4Y14630/nPF0eGDbwrEYG4w7cvJgzRRIZBExeT/8MSYK67gwUSYuFmbnpls=; 7:SKS68ufvxba0CgAhvU8X+7FVjCaWr5nvARmBHuniaY9MbFvNS4iZP2llPv2ytd/SCO/JAKwPTH3XWl5NjxIpLvXT9b3tgMaetqXCTsU583lKlxS0VYuc7zgu9mZGD/0MWnMBGjlmlCQ40bohv7Zl1Q==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 647eb10a-77bc-4eeb-dad7-08d6430580b7
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM4PR07MB3347;
x-ms-traffictypediagnostic: AM4PR07MB3347:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com;
x-microsoft-antispam-prvs: <AM4PR07MB33474D032A1426D968F032F9C2CA0@AM4PR07MB3347.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(20558992708506);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(4983020)(52105095)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM4PR07MB3347; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB3347;
x-forefront-prvs: 08476BC6EF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(366004)(396003)(136003)(13464003)(199004)(189003)(51444003)(68736007)(25786009)(74316002)(55016002)(97736004)(71200400001)(53936002)(8936002)(256004)(6436002)(110136005)(476003)(6116002)(7736002)(86362001)(9686003)(316002)(11346002)(486006)(446003)(66066001)(3846002)(229853002)(6246003)(7696005)(478600001)(305945005)(2906002)(5660300001)(99936001)(33656002)(2501003)(53546011)(105586002)(26005)(186003)(71190400001)(14454004)(6506007)(81156014)(81166006)(76176011)(102836004)(2900100001)(106356001)(99286004)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3347; H:AM4PR07MB3396.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: tAVuHIG0ojJQx1h27NQVLhROlf/EVmMcLrBlHBqoQfDr/aYP6Djs3Qr3SMU+ozzuBQhBS7F1Kr+Zw0CsMlAHulrAnxV1u8K3QjNrYogl6asMlC1SESEZVSwOQ//+Xc0RsQQ9sxnwO5mzQJchREfgFS8AIORpBzypLeZ4wCxVw78ZB/Lr5lcGLW+csqtK690zTJds9S+DxjNMbs+q3+0tONfHWqV7fjkWHOEX2ntCjKf36QBTledVZgdsSqiymw7DMRNXp6dHv8O9StWAsaPX2aU6m6KgvhCnDDPZshUYcWYUPa3TvtafOArb2Lbc+xs5LsDSrsDYZPU2a6EqBRm1SwmKwqtyBYpI4zxusPVxwuA=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_031C_01D474F6.BF2DBE90"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 647eb10a-77bc-4eeb-dad7-08d6430580b7
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2018 10:00:23.1684 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3347
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHfc85OzsuR6d5ezCUXPrF29IKRbz1pYSIBDHKBFt6UtNN2dS0 DymmQtpkoYtcgXlBnJqIWlZo4TRr9sErXlt61EqbmRYlYkg7Owv69nv+/+d9Li8PhUveCjyo DGUuo1LKs6SkiKi92Hsj8IXL0uVjnRrnsPW7BmHY68ZRPKxtbouMwWObmnax2PLPH4RxWKIo IpXJyshnVLKoK6J03fCQMKchr6B9ahgvRh3XK5AjBfQJmDf3ExVIREnoIQRDln4BH/xCsG02 CLksCd2IwaMZL84gaC0O99kGnM+qwaB+1oLxAYtA0zJNcE9IOgIMxh3EsQutgM13JbZSzlZ9 vHLArkdC76cvZAWirBwCi32FnEzQPjBYZRJwLKaToL5vDOOniIDmzW6b7mh92tXYhnOMaE9Y 3Ploa4vT7jC/Wofxu7kAO/6e5NkV1lf2BTwfgT8Ty3bdEybqKhE3P9DTJHyrriZ4IxC2dDqc 53PQ9+qJPWkcwfpgC+INP3j5vQHjp0iBH3Mae4dMWBgpE3CLAR0OVbrTvOwFrRqW4Oss4LDb XIO0SKb/b3C91cPpewh0K89Ive0HDoGpdpXgk/xBw5ahf9xcb8F5joS1kUUhz95QU8na+SRY 3myjx4hqRa5qRn1VkRZyPIhRZaSo1dnKICWT24WsJzXQs+f7HE1unDIimkJSJzFlPS+JQJ6v LlQYkY+1znJn2xjyIJTZSkbqIpaSVlucKi+8yaiyk1V5WYzaiA5ThNRdzIZ2J0roNHkuk8kw OYzqn4tRjh7FKPrhZKu3ckrWftA85uDbuJHhZv6ZPVe+eUlhijdfCLidvF+05r4gEhQZikt7 ZLd8CxNKDHFx51dlDQTuO+/mcVQ/GL/9VB+tHY0ND2l1YH9rzyQUfI1yK02q21s6OxvdYaK3 goVAxrAzd7xMHTGe/h2Ud3uzY6jTgdhr5IMAKaFOlwf74Sq1/C9mI8j5WgMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/9p28kFPzAKKiNfp0Q6FmvdGoO4E>
Subject: Re: [AVTCORE] [rmcat] Notes on CC-Feedback from the Hackathon
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2018 10:00:32 -0000

Hi

I agree that the parsing of the feedback is a bit unorthodox, not necessarily wrong but a bit odd to implement.
The " indicate time *before* the report timestamp" also confused me initially, I thought that it needed to be like this but it is good to state this clearly.

/Ingemar


-----Original Message-----
From: Jonathan Lennox <jonathan@vidyo.com> 
Sent: den 4 november 2018 09:32
To: IETF AVTCore WG <avt@ietf.org>; rmcat@ietf.org
Subject: [rmcat] Notes on CC-Feedback from the Hackathon

Nils Ohlmeier, Sergio Mena (remotely), and I worked on implementing CC-Feedback during the Hackathon.  Sergio and Nils worked on implementing it in libwebrtc, specifically as used in Firefox; I worked on adding it to Vidyo’s proprietary codebase.

We each got as far as sending the feedback messages, but unfortunately Sergio had implemented a slightly older version of the draft (-01 vs. -02, lastSeq vs. lastSeq+1) so we weren’t able to interop.

We also weren’t able to get so far as to actually act on the messages as received, and thus hook up our congestion control algorithms.


What follows are my (somewhat disorganized) notes on the CC-Feedback draft, as an implementor.

Parsing CC-Feedback packets is a bit odd — the way you tell there are no more streams in a feedback packet is that there are only four remaining bytes in the packet, for the report timestamp.  This is unambiguous, but perhaps non-obvious.

It should be made more clear that the arrival time offsets indicate time *before* the report timestamp.

I think that having the report timestamp be “derived from the same wallclock used to generate the NTP timestamp field in RTCP Sender Report (SR) packets” (presumably meaning SR reports from the packet sender?) is unfortunate.  SR NTP timestamps often use the real system wall-clock, i.e. actual NTP time-of-day, which is subject to clock adjustments.  For CC feedback, however, I think we want a clock that’s more stable than that.  I’d suggest that report timestamps from a given sender must always use the same clock, which SHOULD be stable, but otherwise can be unrelated to any other clock on the system.

It’s not also clear what precise semantics "the time instant when the report packet was generated” has.  In particular, this isn’t the time the report packet was *sent*, so it can’t be used for RTT calculations, right?  Additionally, if you need to generate multiple report packets to prevent arrival time offsets from being out of range, at least one of the reports’ report timestamps will *not* be the generation time.

What value should be used for arrival time offsets for packets that arrived after the report timestamp?  (If you have consecutive packets that were reordered by more than the maximum arrival time offset, this might be unavoidable.). I think they should be reported as “not received", because they hadn’t arrived as of the report timestamp, but this should perhaps be clarified.

The sentence "If overlapping reports are sent, the information in the later report updates that in any previous reports for packets included in both reports” should be clarified to include the fact that later feedback messages MUST NOT indicate loss for packets that earlier feedback messages reported on.  This has the consequence that feedback senders can’t just purge all data about received packets once feedback has been sent for them, if it’s possible that sequentially earlier, reordered packets might still arrive later.

There should probably be guidance on what a feedback sender should do if it receives duplicate copies of the same packet.  Should the arrival time be that of the first or last copy?

The document says "RTCP congestion control feedback packets SHOULD include a report block for each SSRC that is being congestion controlled”, but it’s not clear how a receiver can know which sources are being congestion controlled.  Moreover, if you’re in a situation where there could be lots of SSRCs (e.g., media coming from an SFU) it’s not clear to me that you want to include reports for SSRCs that have been inactive for a long time. It’s probably better to say SHOULD be sent for every active source (i.e. source for which you will send a report block in your next SR/RR).

The document says “The sequence number ranges reported on in consecutive reports for an SSRC SHOULD be consecutive and SHOULD NOT overlap (i.e., begin_seq for a report is expected to be one greater, modulo 65535, than end_seq of the previous report for that SSRC).”  Should this be limited in some way?  E.g., if a source’s sequence numbers reset after an outage, how far back should the loss reports go?  I think that we don’t want to be sending reports for thousands of sequence numbers.  Additionally, if you had packet reordering around the time a feedback message was sent, you probably want to go back and report earlier packets that arrived after the feedback message went out, even if this results in a sequence number overlap.

What is the point of having the report timestamp have higher precision than the arrival time offsets?  The report timestamp is measured in 1/65536 of a second, but the arrival time offset is only in 1/1024 of a second.

The rtcp-fb SDP negotiation mechanism supports limiting a feedback message to a specific subset of the payload types.  Should this be allowed for CCFB negotiation?  Why would you want it? What does it mean?

The reference in the SDP syntax is wrong; it should be [RFC4585] , not [RFC4584].