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