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

[Harald Alvestrand <[e-mail]>]

On 3/25/19 12:19 PM, Jonathan Lennox wrote:
> 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?

I thought it was obvious that it should be TRANSPORT, but I see that no
other rtcp-fb value uses that form; instead they are mostly
IDENTICAL-PER-PT, which collapses to IDENTICAL due to the requirement to
use * as the PT.

Definition of IDENTICAL from draft-ietf-mmusic-sdp-mux-attributes:

   The attributes and their associated values (if any) in the IDENTICAL
   category MUST be repeated across all the media descriptions under
   multiplexing.

I suggest that IDENTICAL is the simplest thing, so that's what we should
specify.



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


-- 
Surveillance is pervasive. Go Dark.