[AVT] bandwidth feedback in draft-ietf-avt-rtcp-feedback-11.txt

Jim Kleck <jimk@8x8.com> Thu, 14 October 2004 22:12 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12821 for <avt-archive@ietf.org>; Thu, 14 Oct 2004 18:12:35 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIE18-0007S1-Ed for avt-archive@ietf.org; Thu, 14 Oct 2004 18:24:15 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDm4-0003PM-NL; Thu, 14 Oct 2004 18:08:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDaB-0006ga-6I for avt@megatron.ietf.org; Thu, 14 Oct 2004 17:56:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11068 for <avt@ietf.org>; Thu, 14 Oct 2004 17:56:20 -0400 (EDT)
Received: from mail.8x8.com ([192.84.19.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDlM-000787-Sz for avt@ietf.org; Thu, 14 Oct 2004 18:08:00 -0400
Received: from [127.0.0.1] (mail [192.84.19.130]) by mail.8x8.com (Postfix) with ESMTP id EAD0F1E1A2; Thu, 14 Oct 2004 14:55:46 -0700 (PDT)
Message-ID: <416EF5E2.7030104@8x8.com>
Date: Thu, 14 Oct 2004 14:55:46 -0700
From: Jim Kleck <jimk@8x8.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: avt@ietf.org
Subject: [AVT] bandwidth feedback in draft-ietf-avt-rtcp-feedback-11.txt
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: 7bit
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit

Hi all,


We have a SIP video conferencing application which operates over
broadband. Typically our videophone is on a local network behind a
router connected to a DSL or cable modem.

When another device on the local network asynchronously starts using
bandwidth, e.g. by doing an FTP, we experience either increasing latency
as transmitted packets are buffered along the path and/or we experience
dropped packets.

Both of these conditions are detectable by using RTCP Sender Reports
and Receiver Reports, but the question is: how far should our
application reduce its transmit bandwidth? RTCP reports indicate
number of lost packets or increasing latency, but due to the varying
transmit bandwidth of the video (i.e. small bandwidth during periods
of little motion, larger bandwidth during periods of large motion),
this does not easily translate into how far to reduce the transmit
bandwidth.

The far end's receiver does, however, have the means to easily
calculate both the sender's transmit bandwidth for a particular period
(by comparing the two most recently received RTCP Sender Reports) and
the actual received bandwidth for that comparable period (by comparing
the time and the received byte count at the reception of those two
RTCP Sender Reports). Note that the receive bandwidth alone is not
sufficient because of the varying video bandwidth.

So given these transmit and receive bandwidths, the difference is the
amount by which the sender has overfilled the pipe. This difference is
not exact because RTP/RTCP packets can get out of sequence, so the
difference is only meaningful if it exceeds some threshold.

Now all that is needed is a way for the receiver to communicate this
difference back to the sender. This could certainly be done using an
Application Layer Feedback Message but it is the receiver's RTP layer
which processes the RTCP Sender Reports and Receiver Reports and which
can calculate the bandwidth difference. This puts the feedback more
in the Transport Layer area. However, the sender (i.e. the endpoint
that receives the feedback) must pass the information up to the
application, so maybe it belongs in the Application Layer area after
all. But this kind of feedback seems of general use to me, possibly
useful for many types of payload. It should thus be standardized and
not left up the the applications nor put into the Payload Specific area.

So, I propose a new transport layer feedback message with a single FCI
field containing an unsigned 32 bit value. This FCI field would contain
the bandwidth difference detected by the receiver. Upon receiving this
feedback, the sender can then reduce its maximum transmit bandwidth by
the difference.





Thank you for your time,

Jim Kleck
8x8, Inc

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