Dear Jim,
RTP is considered an application layer protocol, not a transport layer
protocol. RTCP feedback message are application layer feedback.
Schemes like yours have been proposed before. Their problem is that
they do
not work.
The standard solution for your problem (without additional signaling
support) would be to mimic TCP congestion control mechanisms. Google
for
"TCP Westwood", and you will find a dozen papers or so. Standard RCTP
receiver reports are perfectly fine for this purpose. However, even
if you
were using a high enough report frequency, you could not avoid losses,
because only the losses would tell you to reduce your bandwidth. TCP
will
always claim as much bandwidth as it can get, and only stop asking for
it
when it senses excessive losses.
In the 3GPP environment, the AVP (and AVPF) can be augmented with a
"jitter
buffer fullness" indication, which reports the status of the receiver
(jitter) buffer -- which, in turn, could be used to calculate your
target
bandwidth, doing a bit of straightforward math. This may work over the
point-to-point wireless link to the mobile terminal, assuming an
overprovisioned core network. It will not work on a LAN, or a
best-effort
WAN.
With respect to your proposal: As long as your LAN has (statistically)
a
lower bandwidth then the typical TCP sender's sending capability, your
media
transport will be messed up from time to time, no matter what. Unless
you
use exotic stuff such as negotiated quality (Intserv, Diffserv) or
DCCP.
Writing this after 22 hours of no-sleep,
Stephan
-----Original Message-----
From: Jim Kleck [mailto:jimk at 8x8.com]
Sent: Thursday, October 21, 2004 7:28 PM
To: avt at ietf.org
Cc: jo at tzi.org; stewe at stewe.org; sato652 at oki.com;
burmeister at panasonic.de;
rey at panasonic.de
Subject: [AVT] bandwidth feedback in
draft-ietf-avt-rtcp-feedback-11.txt
(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