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

From: Mario Montagud Climent <[email-masked]>
Date: Mon, 05 Nov 2012 13:20:02 +0100

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)?

- 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)?

Thank you very much in advance.

Best Regards,

Mario Montagud

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Nov 2012 14:28:33 +0100

On 2012-11-05 13:20, Mario Montagud Climent wrote:
> 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.
> 
> 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.
> 
> 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.
> 
> 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.

> 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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------