Subject: [AVTCORE] Notes on RTP CC Feedback from the Hackathon

From: Jonathan Lennox <[email-masked]>
Date: Mon, 25 Mar 2019 12:19:56 +0100

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.