[rmcat] Notes on CC-Feedback from the Hackathon

[Jonathan Lennox <[e-mail]>]

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