Re: [AVTCORE] Question about the minimum RTCP report interval

[Magnus Westerlund <[e-mail]>]

On 2012-11-05 13:20, Mario Montagud Climent wrote:
> 
> Hi all,
> 
> I would appreciate it very much if you could clarify me a doubt about
> the minimum RTCP reporting interval.
> 
> According to RFC 3550, the RTCP report interval is dynamically computed
> based on the allocated session bandwidth, the average size of all
> (received and sent) RTCP packets, the number of participants in the
> session and their role (senders or receivers), or their proportion, and
> the unicast or multicast nature of the session (Section 6.2 of RFC 3550).
> 
> Nevertheless, it is also specified that this deterministically computed
> RTCP report interval should have a lower bound to avoid having bursts
> (cumpling) of RTCP packets when the number of participants is small and
> the law of large numbers is not helping to smooth out the traffic
> overhead. This would also help to avoid excessive frequent reports
> during transient outages like a network partition. The recommended value
> in RFC 3550 for that fixed RTCP minimum interval is 5 seconds.
> 
> The RFC 3550 also specifies that in some cases (e.g., if the data rate
> is high and the application demands more timely feedback reports) an
> implementation may scale the minimum RTCP interval to a smaller value
> given by 360 divided by the session bandwidth (in kbps). Consequently,
> this yields to an interval smaller than 5 seconds for bandwidths greater
> than 72 kbps. In multicast sessions, only active senders may use that
> reduced minimum interval, whilst in unicast sessions it also may be used
> by receivers. In the above cases, however, the RTCP minimum interval
> must be still taken into account during the membership accounting
> procedure in order to not prematurely time out participants (who can
> indeed be using it) because of inactivity.
> 
> However, RFC 4585 defines an extension to the RTP Audio-Visual Profile
> (AVP) that enables receivers to provide, statistically, more immediate
> feedback messages to the senders and thus allows for short-term
> adaptation and efficient feedback-based repair mechanisms to be
> implemented, while maintaining the bandwidth constraints for RTCP and
> preserving scalability to large groups. In RFC 4585, the RTCP
> transmission interval specified in RFC 3550 is denoted as Regular RTCP
> interval. In addition, RFC 4585 specifies that feedback messages can be
> reported earlier than the next scheduled Regular RTCP transmission time
> if a receiver detects the need to inform about events of interest in the
> media stream (e.g., picture or slice loss) close to their occurrence.
> Otherwise, the Regular RTCP transmission mode is employed, but the
> minimum RTCP report interval of 5 seconds recommended in RFC 3550 is
> dropped.
> 
> So, my questions about this are:
> 
> - When using the Regular RTCP reporting rules (RFC 3550) in multicast
> scenarios, which option should we select for the minimum RTCP reporting
> interval (for a media sender)? Can we use any of the two options for
> selection the minimum thresholds (i.e., 5 sec or 360/bw_session_kbps)?
> 

To my understanding you can use any of them. This is actually a
potential interoperability issue.

> - Likewise, should the sentence "the minimum RTCP report interval of 5
> seconds recommended in RFC 3550 is dropped" from RFC 4585 be applied in
> all cases (i.e. not only when using the early RTCP reporting rules)?

It applies also for regular reporting and instead the trr-int mechanism
is introduced.

I would however strongly recommend that one uses 5 seconds in the
formula when timing out sources to avoid spurious timing out of sources
that uses the 5 seconds if oneself are uses the scaled value.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------