[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
- [AVTCORE] Question about the minimum RTCP report … Mario Montagud Climent
- Re: [AVTCORE] Question about the minimum RTCP rep… Magnus Westerlund
- Re: [AVTCORE] Question about the minimum RTCP rep… Mario Montagud Climent