[Bug 738319] rtpsession: fix Early Feedback Transmission

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=738319
  GStreamer | gst-plugins-good | 1.4.1

--- Comment #20 from Olivier Crête <olivier.crete at ocrete.ca> 2015-01-22 22:15:51 UTC ---
After over 8 years doing RTP, I think I just understood the meaning of
immediate vs early feedback today, I'll try to explain how I understand it now:

(In reply to comment #10)
> If I'm not mistaken we currently *always* do immediate feedback. AFAIU
> immediate feedback means that it's always allowed to send up to one early RTCP
> packet before the next scheduled one, while in early feedback mode this might
> not be allowed every now and then (rules not 100% clear to me).

The original idea is that we do immediate feedback if the number of session
members is less than "rtcp-immediate-feedback-threshold" (by default 3), but
one could set that to 0 and disable immediate feedback entirely. I now think I
didn't understand it correctly.

I think that from a "endpoint source code" point of view, "early" and
"immediate" feedback are the same. The difference is the aggregate behaviour.
If the group is small enough, then you send feedback packets frequently enough
that everything that happened between two RTCP packets can (statistically) be
reported in the next packet. For example, not many more than 16 RTP packets can
have been lost between two RTCP packet, so the NACK is enough. But if your
group is larger, than you send RTCP packets much less frequently, you cut it
down in half if you go from 2 to 4 members, then you can't individually send
feedback for each event from each endpoint, but as an aggregate you do, so
maybe going from 2 to 4, you switched from immediate to early mode, but the
code in each endpoint is still the same.

> However this is also a bit weird still, as 3.3a) talks about reporting each
> event immediately. Which would not be true with my understanding (you can
> report one event immediately, then you have to wait until the next regular RTCP
> packet).
> I would've expected immediate RTCP mode to mean that it is possible to send
> multiple early packets between the regular RTCP packets, but nothing in the RFC
> seems to support this view.

Sending as many RTCP packets as is needed was also my initial reading. But I
think it's actually not correct. One of the guiding principles of the RTP/RTCP
RFCs is to limit the bandwidth occupied by RTCP to a specific limit. Using the
AVPF profile, when trr-int=0, you send RTCP packets as often as is possible
within the bandwidth limit. So sending a single extra packet would exceed the
limit, which is a big no no. So then it makes sense that sending immediately an
early packet just means that the next packet is sent early, not that you get to
send an extra packet.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.