Re: [AVT] draft-ietf-avt-rtcp-bw-05.txt question

Aaron Colwell <acolwell@real.com> Thu, 03 July 2003 21:45 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08143 for <avt-archive@odin.ietf.org>; Thu, 3 Jul 2003 17:45:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBt1-0003q3-W1 for avt-archive@odin.ietf.org; Thu, 03 Jul 2003 17:45:04 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Lj35Y014744 for avt-archive@odin.ietf.org; Thu, 3 Jul 2003 17:45:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBsz-0003ph-Qf; Thu, 03 Jul 2003 17:45:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YBsR-0003os-6z for avt@optimus.ietf.org; Thu, 03 Jul 2003 17:44:27 -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 RAA08104 for <avt@ietf.org>; Thu, 3 Jul 2003 17:44:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YBsO-0004OE-00 for avt@ietf.org; Thu, 03 Jul 2003 17:44:24 -0400
Received: from flawless.real.com ([207.188.7.222]) by ietf-mx with esmtp (Exim 4.12) id 19YBsO-0004Nt-00 for avt@ietf.org; Thu, 03 Jul 2003 17:44:24 -0400
Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by flawless.real.com with esmtp; Thu, 03 Jul 2003 14:43:48 -0700
Date: Thu, 03 Jul 2003 14:50:15 -0700
From: Aaron Colwell <acolwell@real.com>
To: Stephen Casner <casner@acm.org>
cc: avt@ietf.org
Subject: Re: [AVT] draft-ietf-avt-rtcp-bw-05.txt question
In-Reply-To: <20030703141746.M66738-100000@ash.packetdesign.com>
Message-ID: <Pine.LNX.4.51.0307031432190.21916@raven.dev.prognet.com>
References: <20030703141746.M66738-100000@ash.packetdesign.com>
Mime-Version: 1.0
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

Steve,

This proposal would work fine if only b=RS is present. This would just
mean that the client would not send receiver reports.

In the case where b=RR is specified that would mean that no sender reports
or BYE packets could be sent. Is that allowed? In the A/V case the client
would not be able to sync the streams because it would never get their
CNAME. I suppose that is the server's fault for not specifying a value
for the sender reports. I guess this brings up another question. Does it
make sense for the RS value to be 0?

Perhaps we could modify your proposal to say, "If only b=RS is specified
and it's value is greater than 5% of the stream bitrate, then RR value is
0. If you need a b=RR line that is greater than 5% of the stream bitrate,
then you MUST supply a b=RS line." We could say that or we could just
make the rule that if you are allocating more than 5% of the stream
bitrate to RTCP, you MUST specify both the b=RR and b=RS lines.

Aaron



On Thu, 3 Jul 2003, Stephen Casner wrote:

> Aaron,
>
> > What is the expected behavior if only a b=RR line is specified and it's
> > value is greater than 5% of the stream bandwidth. The draft says that if
> > only one parameter is specified then the value of the other is determined
> > by subracting the value of the specified parameter from 5% of the stream
> > bitrate. In the case I have mentioned this would cause a negative
> > bandwidth to be calculated. That is obviously not valid. Could someone
> > please clarify what should happen in this case.
>
> I propose to simply say that the unspecified parameter is zero in that
> case.
>                                                         -- 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