[AVTCORE] Question about the minimum RTCP report interval

Mario Montagud Climent <mamontor@posgrado.upv.es> Mon, 05 November 2012 12:20 UTC

Return-Path: <mamontor@posgrado.upv.es>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3075821F84EC for <avt@ietfa.amsl.com>; Mon, 5 Nov 2012 04:20:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCOX3dA0dZIv for <avt@ietfa.amsl.com>; Mon, 5 Nov 2012 04:20:05 -0800 (PST)
Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 463D021F84EB for <avt@ietf.org>; Mon, 5 Nov 2012 04:20:04 -0800 (PST)
Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id qA5CK31P021581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <avt@ietf.org>; Mon, 5 Nov 2012 13:20:04 +0100
Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id qA5CK3Rc020214 for <avt@ietf.org>; Mon, 5 Nov 2012 13:20:03 +0100
Received: from localhost (wm2.cc.upv.es [158.42.249.57]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id qA5CK2Bm023043 for <avt@ietf.org>; Mon, 5 Nov 2012 13:20:02 +0100
Received: from gnd2g71-118.wi-fi.upv.es (gnd2g71-118.wi-fi.upv.es [158.42.71.118]) by webmail.upv.es (Horde Framework) with HTTP; Mon, 05 Nov 2012 13:20:02 +0100
Message-ID: <20121105132002.50214lz37taa88he@webmail.upv.es>
Date: Mon, 05 Nov 2012 13:20:02 +0100
From: Mario Montagud Climent <mamontor@posgrado.upv.es>
To: avt@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6)
X-Mailman-Approved-At: Mon, 05 Nov 2012 10:46:09 -0800
Subject: [AVTCORE] Question about the minimum RTCP report interval
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2012 12:20:06 -0000

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