RE: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt

"Jose Rey" <rey@panasonic.de> Mon, 16 June 2003 16:53 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 MAA20733 for <avt-archive@odin.ietf.org>; Mon, 16 Jun 2003 12:53:22 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GGqt117976 for avt-archive@odin.ietf.org; Mon, 16 Jun 2003 12:52:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBX2a26453; Mon, 16 Jun 2003 07:33:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GBWtm26442 for <avt@optimus.ietf.org>; Mon, 16 Jun 2003 07:32:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08396 for <avt@ietf.org>; Mon, 16 Jun 2003 07:32:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RsC7-0001Pp-00 for avt@ietf.org; Mon, 16 Jun 2003 07:30:39 -0400
Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 19RsC6-0001Pm-00 for avt@ietf.org; Mon, 16 Jun 2003 07:30:38 -0400
thread-index: AcMz+ud4Ao0fmbOeQ1OgH4tdX/0aLw==
Received: from atrgreyj ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Jun 2003 13:32:01 +0200
From: Jose Rey <rey@panasonic.de>
To: Stephen Casner <casner@acm.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Cc: IETF AVT WG <avt@ietf.org>
Content-Class: urn:content-classes:message
Subject: RE: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt
Priority: normal
Date: Mon, 16 Jun 2003 13:32:00 +0200
Message-ID: <NGBBJIBNJOKHDHFKEOMHMEECEPAA.rey@panasonic.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <20030615233831.P61774-100000@oak.packetdesign.com>
X-OriginalArrivalTime: 16 Jun 2003 11:32:01.0465 (UTC) FILETIME=[E7768290:01C333FA]
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

Hi,

> -----Original Message-----
> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Stephen
> Casner
> Sent: Monday, June 16, 2003 8:47 AM
> To: Magnus Westerlund; Jose Rey
> Cc: IETF AVT WG
> Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt
>
>
> Some more thoughts on this:
>
> To simplify the unicast streaming application, we could specify that
> when RTCP bw is specified with RS and RR those values are used
> separately for senders and non-senders without any consideration of
> treating senders and receivers together when the number of senders is
> greater than RS/(RS+RR).

I think this is the best and easiest solution. In 3GPP unicast streaming it is
the server that sets the RS and RR values, that means the server should consider
well how much bandwidth it is needed for own reporting and for the sender's.
There's no case where the algorithm must adapt, the scenario is rather static.

>
> However, that would not be good for conversational applications
> (unicast or multicast) because the classification as sender changes
> over time.  At times when both ends have sent within two intervals,
> they would be using the RS bw only and ignoring the RR bw.  To get
> around this we could set RS to be the total, and RR zero, but then if
> one was sending and the other just listening for a long time, the
> listener would get nothing.  For these applications, you need the
> smooth transision that the existing algorithm was intended to
> provide.
>
I see. I was referring more to the streaming unicast scenario. I guess my
characterization was not accure enough.

cheers,

Jose

>                                                         -- Steve
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt