[AVTCORE] Notes on RTP CC Feedback from the Hackathon

Jonathan Lennox <jonathan@vidyo.com> Mon, 25 March 2019 11:20 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 31E3912042A for <avt@ietfa.amsl.com>; Mon, 25 Mar 2019 04:20:02 -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=ham 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 F_cCfJ7Ig1Mt for <avt@ietfa.amsl.com>; Mon, 25 Mar 2019 04:20:00 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 3434A1203F0 for <avtcore@ietf.org>; Mon, 25 Mar 2019 04:20:00 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id t5so9601403wri.7 for <avtcore@ietf.org>; Mon, 25 Mar 2019 04:20:00 -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=JU6X5kBX/EEptomwvvF828GFU/QGfjKY8bsJ1CplcKE=; b=GAxUkaxcgXx3XuTBWRBSobESmT/KDi6zLPeQVoLajGNbo9lz6BVxJigsYPFnn3FtKa I9HhZccvYFf11pm2r5DcgAQ/ey0eZSQuPSFW8Uw1/iP7+Cg+CmTNUkqtqB6ilcCZrfgc ZYkXPTS/G0eYOnggQvOAROT2t1wRZRvwg+Pv3YAqs8ZYSOZQOd4FAdQKhm7B7VYnFG71 jAqJ+MAwmD23kLKkhnJXBg23q6pb9PJ+4hglV/AzcctcKmKLWeZJ0HpC4+k7gH4tSQIf Kq+ArflMkZT4dpu3Jvd/389W9nRQaiaKnSlsJFQt0qMAQdU2TufFz5geSZ30TK/QUr3J s0mA==
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=JU6X5kBX/EEptomwvvF828GFU/QGfjKY8bsJ1CplcKE=; b=cHSR1ry/bs2plPr50Betyz76Q5ZEEAu6mNo3pvS1AgFpxpNFNgl28c9OKolC+hCqgK bNEkn+EN6qFj3+u1pOOB43ivdTRSBuGOBFXVkVRxnnrqYINRlxq+FYDvBy1lyZXcqEo9 2DWCQXlqeJWuyEfs334kqrBYvfDIupt6t6epGlyE6L8Rp6/47X65BHdwlMFFUIPzuEEl BG4uNYx+GvXDW9NAFWjlhBhz+0ITj/lPvb2GySqZrYhuQA3w5ArYrkMwFprNszqNESi4 /QF7GBIW0WpfDNU456qchPFysUnnazj8XRPM9k0vNd1p6SRyW1q0HwP2mt77unc9teei 1q/w==
X-Gm-Message-State: APjAAAXvlXw2mEk5bds51w6keqIgESLAJxJbVysU/z3p+kZc7d8GTwH7 O0PpBKXEiLgoxG+lzc7ZAtWyAg==
X-Google-Smtp-Source: APXvYqx+0xOSv0bP8FZOL4RINw7nWEd3wfuzQ72zmqEIEd4V+dkHK112NKA7c6eMMGcbiRKREpw/XA==
X-Received: by 2002:a5d:69c7:: with SMTP id s7mr14722552wrw.71.1553512798476; Mon, 25 Mar 2019 04:19:58 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:a0d6:156:7308:6568? ([2001:67c:370:128:a0d6:156:7308:6568]) by smtp.gmail.com with ESMTPSA id t2sm35497842wra.9.2019.03.25.04.19.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 04:19:57 -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 12.2 \(3445.102.3\))
Message-Id: <91FCCD42-F4DB-45B2-9673-828F327743F8@vidyo.com>
Date: Mon, 25 Mar 2019 12:19:56 +0100
To: "rmcat@ietf.org WG" <rmcat@ietf.org>, avtcore@ietf.org
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/XsOJw9LMyEpVfVM7zDRWm-c4PVI>
X-Mailman-Approved-At: Mon, 25 Mar 2019 06:07:27 -0700
Subject: [AVTCORE] Notes on RTP 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, 25 Mar 2019 11:20:06 -0000

Sergio Mena, Nils Olhmeier, and I got RTP CC Feedback interoperating at the IETF Hackathon this weekend.

Sergio (with help from Nils) got it working in Firefox, driving libwebrtc’s GCC; I had it working in our proprietary codebase with our proprietary congestion control algorithm.  We had media flow between my computer at the Hackathon and Sergio’s in Switzerland, with both sides achieving what seemed to be reasonable bitrates for the network. (We didn’t do careful study of the results in the time we had available, though.)

Some issues we noticed:

* In BUNDLE, it’s not clear whether it should be legitimate to negotiate CCFB on some but not all of a group of bundled media descriptions.  I.e., what should the bundle category of a=rtcp-fb:* ack ccfb be?

* SDP ABNF syntax is fairly arcane, so it wasn’t immediately obvious to everyone that the signaling was indeed supposed to be “a=rtcp-fb:* ack ccfb”.  An example would probably be helpful.

* Offerers will often want to offer a variety of congestion control feedback mechanisms for maximum interoperability, but bad things can happen if you try to use more than one at once.  Thus, answerers should answer with only one option, and if that doesn’t happen (i.e. if an answer contains more than one option) an endpoint should either pick just one it likes best, or complain/fail.

* CCFB, unlike most RTCP messages, isn’t intrinsically bounded in size.  When bandwidths are very asymmetric, you can end up with more feedback reports than will fit in an MTU.  Implementations should make sure to generate multiple feedback packets in this case.

* There should be guidance on how CCFB’s SSRC-and-RTP sequence feedback format can be mapped into a single sequence number space, of the sort that many congestion control algorithms will want as input.

* Congestion algorithms need to understand what to do in response to lost feedback messages.  It’s generally a bad thing to treat them as media packet losses, but it’s also bad to treat them as though the packets were received perfectly.