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

[Colin Perkins <[e-mail]>]

The RTP profile for TFRC <draft-ietf-avt-tfrc-profile-03.txt> and the 
work of the DCCP working group might also be of interest.

Colin



On 22 Oct 2004, at 21:38, Stephan Wenger wrote:

> 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:[e-mail]]
> Sent: Thursday, October 21, 2004 7:28 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; 
> [e-mail];
> [e-mail]
> 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


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt