Re: [AVT] RTCP unicast feedback for measurement applications?
Eve Schooler <schooler@research.att.com> Tue, 04 February 2003 01:01 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26379 for <avt-archive@odin.ietf.org>; Mon, 3 Feb 2003 20:01:45 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1416w306444 for avt-archive@odin.ietf.org; Mon, 3 Feb 2003 20:06:58 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14163J06423; Mon, 3 Feb 2003 20:06:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1414VJ06377 for <avt@optimus.ietf.org>; Mon, 3 Feb 2003 20:04:31 -0500
Received: from mail-green.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26326 for <avt@ietf.org>; Mon, 3 Feb 2003 19:58:47 -0500 (EST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id B32601E056; Mon, 3 Feb 2003 20:02:23 -0500 (EST)
Received: from research.att.com (chopin.attlabs.att.com [135.197.15.62]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id UAA16218; Mon, 3 Feb 2003 20:02:21 -0500 (EST)
Message-ID: <3E3F111D.F28DE55B@research.att.com>
Date: Mon, 03 Feb 2003 17:02:21 -0800
From: Eve Schooler <schooler@research.att.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: riccardo.fiandra@fastweb.it
Cc: Eve Schooler <schooler@research.att.com>, Julian Chesterfield <julian.chesterfield@cl.cam.ac.uk>, Joerg Ott <jo@Informatik.Uni-Bremen.DE>, avt@ietf.org
Subject: Re: [AVT] RTCP unicast feedback for measurement applications?
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Fiandra Riccardo <riccardo.fiandra@fastweb.it> wrote: >I was interested in the "RTCP Extensions for Single-Source Multicast >Sessions with Unicast Feedback" draft. >Actually, I was wondering if it is also targeted to have a very large and >distribuited network measurement framework. >Where multicast receivers (thousands) use RTCP to send report to a >measurement collector about packet loss, jitter, or other. >I see really many advantages on that for e2e measurements, especially in a >scenario where thousands of receivers are always connected to the network >and cannot send multicast (common scenario for an operator, even without >SSM...). > >My questions are: >-Was this a scenario of application when writing the draft? Absolutely, though the primary focus of the draft was to solve the problem posed by the removal/restriction of the backchannel caused by SSM and other uni-directional or asymmetric topologies. Solving the feedback problem for SSM gives us the blueprint for other unicast-based feedback architectures, including ones for network measurement in general. >-In this case, could I use the RTCP channel multicasted to the receivers to >control them? Yes you could. This is certainly what we envision in the RTCP context; use the multicast channel in the source-to-receiver direction, and use the unicast backchannels in the receiver-to-source direction. We also propose to use the multicast channel either: - to reflect receiver feedback (received on the unicast backchannels) back out on the multicast channel to reach all receivers, or - to redistribute to the receivers feedback summaries (receiver feedback collected at the source and aggregated into a single mathematical distribution) back out on the multicast channel. >-Do you see any extension possible also for ptp rtp connections (forward >rtcp reports to another device?) In section 10 of draft-ietf-avt-rtcpssm-02.txt, we use an extension to SDP to indicate the device to which the feedback gets reported. This is done following the proposal for SDP source filters documented in draft-ietf-mmusic-sdp-srcfilter-00.txt. We also just completed a paper that expands upon the ideas in the I-D and that should provide further application scenarios. I'll post it here shortly. Eve -=-=-=-=- Eve M. Schooler Voice: 1-650-330-7913 AT&T Labs - Research FAX: 1-650-463-7037 75 Willow Road E-mail: schooler@research.att.com Menlo Park, CA, USA 94025 http://www.research.att.com/~schooler _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- [AVT] RTCP unicast feedback for measurement appli… Fiandra Riccardo
- Re: [AVT] RTCP unicast feedback for measurement a… Marshall Eubanks
- Re: [AVT] RTCP unicast feedback for measurement a… Eve Schooler
- Re: [AVT] RTCP unicast feedback for measurement a… Eve Schooler