Subject: Re: Speed field in RTSP

From: Rob Lanphier <[email-masked]>
Date: Sun, 30 Mar 1997 09:51:11 -0800

At 03:23 PM 3/26/97 -0800, Eric Fleischman wrote:
>Overlooking this problem, I am concerned by the very existence of the
>speed field within the spec. I believe that it is a very dangerous
>alternative and leads to many nasty problems. For example, Network
>Managers are very concerned that network traffic be somehow prioritized
>in tune to the company's internal priorities. Controls to achieve this
>are few and inexact at best, so what frequently happens is that Network
>Managers try to set aside a certain percentage of capacity for
>multimedia events including "broadcasts" such as the MBONE. Hence the
>existence of "channels" and SDP-like registration services. Should users
>be given the ability to willy-nilly exceed these prescheduled bandwidth
>allocations, the Network Manager's job quickly becomes untenable. Having
>seen this situation enacted multiple times, the normal next result is a
>directive coming from management banning that technology within the
>corporation until such a time as it may function in a "well behaved"
>fashion. Why then are we permitting a Bad-Network-Citizen-feature like
>speed within this spec? Let's rather eliminate it altogether since its
>downsides are so severe. Any Pushback?

Yes, quite a bit, actually :)  Like I said in my response to Sampo, I think
that this is the method by which we can do crude flow control, among other
things.  Flow control is a characteristic of a "good network citizen".

Truth told, I can't think of a good reason to use this field in MBONE
situations in the near future.  The more likely scenario is a
point-to-point unicast of a stream.  In that scenario, it is not
unmanageable at all.  Network managers who wish to control bandwidth of
RTSP streams will have to do so through the use of proxies, and those
proxies can just as easily strip the "Speed" field as they can limit the
size of the stream.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Mar 1997 15:29:02 -0500

There seem to be several cases that need to be distinguished:

1) Unicast data delivery over TCP: the client can buffer as much as it
wants. Getting the data across as fast as possible is probably good if
bandwidth is available - can't save up those bits. However, this does
not require a Speed field, since TCP window control will take care of
pacing the sender.

2) Multicast data delivery using UDP: sending data faster is probably
not a great idea, in general. Otherwise, see next item, witht the added
difficulty of multicast congestion/flow control.

3) Unicast UDP: Assuming we have a mechanism like that presented by S.
Jacobs at the RTMWorkshop at INRIA last fall or another TCP-emulating
congestion control, this will look like TCP to the network (minus the
retransmissions, possibly). If you are going to buffer lots of data, you
might as well get (some) reliability, however. Again, a good network
citizen, but not requiring RTSP Speed indication.

If we use the 'equivalent TCP bandwidth function' proposed by Floyd et
al., we can indeed make use of a rate indication (either Speed or
Bandwidth) within RTSP to deliver data faster or at a better quality,
respectively.

Having out-of-band rate control like RTSP Speed for deeply-buffered
receivers is a bit dangerous, however. Imagine that the receiver notices
that its buffer is getting full and that it needs to slow down the
receiver to Speed: 1. In most cases, the request will get there fast,
but in some cases, packet loss or processing delays at proxies or end
systems will delay processing of the request, while the bits keep
flowing at the high rate, overflowing the receiver buffer. Flow control
using rate indication can be tricky...

Thus, I see at best a very limited use for the Speed parameter.

Henning

---

From: Sampo Syreeni <[email-masked]>
Date: Tue, 1 Apr 1997 18:28:20 +0300 (EET DST)

>things.  Flow control is a characteristic of a "good network citizen".

It is also something best handled by the transport protocol.

>The more likely scenario is a
>unmanageable at all.

RTSP should support both multicast and unicast traffic. And probably
transparently as well.

>Network managers who wish to control bandwidth of

Yep, but as RTSP and the actual streams are separate entities, it makes
life hard for firewall and proxy writers.

Sampo Syreeni (Decoy/dAWN), student, <[email-masked]>