[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
- [AVT] bandwidth feedback in draft-ietf-avt-rtcp-f… Jim Kleck
- [AVT] bandwidth feedback in draft-ietf-avt-rtcp-f… Jim Kleck
- RE: [AVT] bandwidth feedback in draft-ietf-avt-rt… Stephan Wenger
- Re: [AVT] bandwidth feedback in draft-ietf-avt-rt… Colin Perkins