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

Jim Kleck <jimk@8x8.com> Thu, 21 October 2004 16:50 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 MAA22189 for <avt-archive@ietf.org>; Thu, 21 Oct 2004 12:50:11 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgLM-00082v-Cy for avt-archive@ietf.org; Thu, 21 Oct 2004 13:03:19 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKg3r-0008Vq-Ke; Thu, 21 Oct 2004 12:45:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKfo5-0001eD-C1 for avt@megatron.ietf.org; Thu, 21 Oct 2004 12:28:54 -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 MAA19869 for <avt@ietf.org>; Thu, 21 Oct 2004 12:28:50 -0400 (EDT)
Received: from mail.8x8.com ([192.84.19.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKg0j-0007SX-IA for avt@ietf.org; Thu, 21 Oct 2004 12:41:58 -0400
Received: from [127.0.0.1] (mail [192.84.19.130]) by mail.8x8.com (Postfix) with ESMTP id 75B521E1AF; Thu, 21 Oct 2004 09:28:20 -0700 (PDT)
Message-ID: <4177E3A4.8070303@8x8.com>
Date: Thu, 21 Oct 2004 09:28:20 -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: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit
Cc: burmeister@panasonic.de, stewe@stewe.org, jo@tzi.org, rey@panasonic.de, sato652@oki.com
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: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit

(resent to CC the draft authoers)

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