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

[Mario Montagud Climent <[e-mail]>]

Hi Magnus, all,

Thank you for your response! And sorry for our late reply!

See our comments inline.


Magnus Westerlund <[e-mail]> escribió:

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

OK. Thanks for the clarification!

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

We didn?t know about the existence of the trr-int attribute.

As we understand now, the following steps must be followed to compute  
the Regular RTCP Report Interval (T_rtcp):

    - USING RTP/AVP (RFC 3550)

1. T_rtcp_avp_det_1 = (members * avg_rtcp_size * 8)/rtcp_bw_portion

The values of 'members' and 'rtcp_bw_portion' parameters depend on the  
proportion of participants and their role (sender or receivers), as  
specified in RFC 3550, as well as on the value of the RTCP bandwidth  
modifiers (if available), as specified in RFC 3556.

2. Also, a recommended minimal fixed RTCP Report interval, T_rtcp_min,  
must be taken into account. Three options for selecting T_rtcp_min:

2a. T_rtcp_min_a = 2.5 sec (if the participant has not sent any RTCP  
packet yet)

2b. T_rtcp_min_b = 5 sec

2c. T_rtcp_min_c = 360/session_bw(kbps), but only allowed for senders  
in multicast scenarios. This reduced minimal interval, T_rtcp_min_c,  
drops below 5 seconds when the session bandwidth is greater than 72  
kbps.

3. Select the maximum value between (1) and the selected option in (2):

T_rtcp_avp_det_2= max(T_rtcp_avp_det_1, T_rtcp_min)

4. Apply randomization:

T_rtcp_avp_rnd = T_rtcp_avp_det_2*(0.5+rnd())

5. Apply compensation for the reconsideration algorithm:

T_rtcp_avp_final = T_rtcp_avp_rnd/(e - 3/2) = T_rtcp_avp_rnd/1.21828

* Note that most of the variables used for the RTCP period interval  
calculation are estimated at each participant. Therefore, their local  
values may differ at any given point in time.


     - USING RTP/AVPF (RFC 4585)

When using the RTP/AVPF (RFC 4585), the interval between regular RTCP  
reports is only derived from the average RTCP packet size and the RTCP  
bandwidth share available to the RTP/RTCP entity.  Here, the 5-second  
minimum interval between RTCP reports is dropped.  However, an  
OPTIONAL attribute, called trr-int, is defined to specify the minimum  
period interval (in milliseconds) between two Regular (full compound)  
RTCP packets.

Therefore, the RTCP report interval is computed as:

// Please, check if the following formula is correct!!
T_rtcp_real_avpf = (0.5+rnd())(trr-int  + T_rtcp_avp_det_1/1.21828)

The use of the trr-int parameter can minimize an excessive RTCP  
bandwidth consumption, while keeping compatibility with AVP end-points.

If the trr-int is not specified, a default value of 0 is assumed. If  
trr-int == 0, then this variable has no impact on the overall  
operation of the RTCP feedback algorithm, other than the minimum value  
for the report interval is dropped.

If trr-int != 0, this variable does not affect the transmission  
scheduling of Early RTCP packets. Note that providing trr-int as an  
independent variable is meant to minimize Regular RTCP feedback (and  
thus bandwidth consumption) while additionally allowing the use of  
more frequent Early RTCP packets to provide timely feedback. This goal  
could not be achieved by reducing the overall RTCP bandwidth, because  
an RTCP bandwidth reduction would also have an impact over the  
frequency of the Early RTCP feedback messages.

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

To our understanding, if trr-int != 0, then the timeout calculation  
for RTP/AVPF entities MUST be modified to use the larger value between  
trr-int (or the RTCP report interval using RTP/AVPF) and the selected  
option for T_rtcp_min (5 sec, or 360/session_bw) using RTP/AVP, to  
avoid premature timeout of RTP entities.

RFC 4585 species that the trr-int parameter ?SHOULD NOT be larger than  
five seconds? for avoiding accidental timeouts in combined AVP-AVPF  
sessions. RFC 4585 also recommends that in those cases involving  
RTP/AVP entities in which the dynamically calculated T_rtcp is  
sufficiently small (e.g., less than one second), the value of trr-int  
parameter SHOULD be set (close?) to 5 seconds.

Thus, a recommended value of 4 seconds for the trr-int seems a good  
option to allow interworking between RTP/AVPF and RTP/AVP end-points,  
unless they explicitly need this parameter to be lower.



So, if the above consideration are correct, we have some question.

If we want an RTP/AVP and RTP/AVPF compliant scenario:

1) In RTP/AVPF devices, should the trr-int parameter only be applied  
to media receivers? Or contrarily, should this parameter be applied to  
both media receivers and senders? My doubt is because the trr-int is  
also called "Minimal RECEIVER report interval" in the RFC 4585.

2) If the trr-int parameter applies to both senders and receivers,  
which is the recommended value for each case?

3) As the trr-int is specified as an OPTIONAL attribute, could the  
trr-int be set to zero in a compliant RTP/AVPF scenario? For example,  
if we want Sync Clients in an IDMS-enabled session to send frequent  
IDMS reports to the MSAS (this would allow a more fine-grained IDMS  
control), but still adhering to the maximum 5 % RTCP traffic bounds,  
can we set the trr-int parameter to zero in the calculation of the  
RTCP report interval in either Sync Clients or the MSAS?

Sorry for the length of the mail!

Best Regards,

Fernando & Mario


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