[AVTCORE] Notes on CC-Feedback from the Hackathon

Jonathan Lennox <jonathan@vidyo.com> Sun, 04 November 2018 08:32 UTC

Return-Path: <jonathan@vidyo.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 41950127133 for <avt@ietfa.amsl.com>; Sun, 4 Nov 2018 01:32:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo.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 luVN1ym3sGlS for <avt@ietfa.amsl.com>; Sun, 4 Nov 2018 01:32:12 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7806130DD5 for <avt@ietf.org>; Sun, 4 Nov 2018 01:32:12 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id f8-v6so2833626pgq.5 for <avt@ietf.org>; Sun, 04 Nov 2018 01:32:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=uXE622bMxpp23XVcG8cYr+mASd4gAgCzzuIkU8It+mQ=; b=foTxk08Ra3aoBvHA/aJPDBJJhfhwC1GwI+OZib2m37uELW41P8jxvbiD56IwLA0OAE 3GuJx6+1+AxouXGCfjVW6F2wS1mt1Q8CiiuE9wGXsFdVehW5TfBBwb+a1nvTMcl/7sLk ouya9a2YPCi0Jv6fILFF/WCBOohV167Xg3BdaMovHY8XJBmip60cvCyc3Pyuf+LPd8af JnuPQi4dzSeeG19e62hmH4YqkrzFUWOu6mNjEi3y5wNbZ0DMXmbRqBbSj8q61oSF/jkJ 5X29ouOUYqIMQ0Bm6h1xZ5tEnCvKpkb+xDVNzpQpzn5dnUpVh/mNNyJM0R/BR0uSIxMN Pe3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=uXE622bMxpp23XVcG8cYr+mASd4gAgCzzuIkU8It+mQ=; b=FEdiW0wviqFRsVPeu0CJkBNkPMGebjU3v1cNAoo7kgjKFdC5sphTAiWpuWJZX1cLQN pl+C96JiYHrzlvXr9HoSmPTy+8amPNXEz7f7G2Gy7NtvgemNiaIbentLeVFlBZ2tJq2U NLkOnS3Qtv1yYcEmB2s2WSU6PUw1LKZ0cqXdZvzSpjTcqX2sEmo+EuXIv4uTqQba3Cp3 8qfKys389kcVN8/R6SuT7qUTu50Pyj9DdEnA8aUM6qhvBAH02Ds0qp7NR1swg5H4h3ga 5pXCFd9IHSju3Lmz15ziv+1WPs7g474uNnCRkVdC3zIml6967tUXbFW1a/rHsYgKoIYH e7Pw==
X-Gm-Message-State: AGRZ1gIMyqqxQ1mwsKAOpqdY+ii47Gcq+z5lYTnIsEL2opC9skWSSrTk 63U0ONOSkLqsaneRBT1vEoieZhEPAB4=
X-Google-Smtp-Source: AJdET5eAOJCd8gWFRsvTXgfEg2O+IUNZ9A71SIRjcwMWwKz1Ic5YF9UqmGln+XCwxBOyOPiMoH0IkQ==
X-Received: by 2002:a65:40c5:: with SMTP id u5mr15972975pgp.46.1541320331937; Sun, 04 Nov 2018 01:32:11 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:9e0:45c9:3074:f505? ([2001:67c:370:128:9e0:45c9:3074:f505]) by smtp.gmail.com with ESMTPSA id 74-v6sm57690380pfx.182.2018.11.04.01.32.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 01:32:11 -0700 (PDT)
From: Jonathan Lennox <jonathan@vidyo.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <03492708-99E8-4792-94C9-E8C04D849919@vidyo.com>
Date: Sun, 4 Nov 2018 15:32:08 +0700
To: IETF AVTCore WG <avt@ietf.org>, rmcat@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/MdxCH_NlOuamWw47ms1Vo59p9ps>
Subject: [AVTCORE] 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: Sun, 04 Nov 2018 08:32:15 -0000

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].