Subject: Re: Speed field in RTSP

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

At 04:06 PM 3/30/97 +0300, Sampo Syreeni wrote:
>I think the issue has been whether to allow for changing the bit rates
>after the resources have already been reserved, that is, the routes have
>been established for the data flow. And this is certainly something that
>should not be encouraged. This is a bit different from what you described
>above as the above problem of responding to network load and end point
>latencies mainly calls for (temporary) throttleback. What the bit rate
>parameter would do, however, is, it would allow for artificially raising
>the data rate in the middle of transmission. This isn't good from neither
>the routing nor the good-netizen point of view.

Isn't this what TCP slow start does on a regular basis?

Let's say that you have a stream that takes far less than the available
bandwidth, and you would like to buffer up a large portion of the stream
while the network is clear, so that you can scale back later when the
network is congested.

There are other uses for this, but rather than getting into those, please
explain why non-RSVP routers care what the data rate is.  Also please
explain why variable bitrates are not good from a "good-netizen" point of
view.  The reason why I ask is because we've taken heat before as "non net
friendly" for *not* responding to network conditions, and now you are
alarmed by the mechanism which would allow for that.

Thanks
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: Sampo Syreeni <[email-masked]>
Date: Tue, 1 Apr 1997 18:22:59 +0300 (EET DST)

>Isn't this what TCP slow start does on a regular basis?

TCP doesn't use resource reservations (as there is currently no
infrastructure for using them anyway). So this is a bit different. And TCP
streams are best effort unlike the isochronous streams we're talking about
here. The slow start mechanism prevents TCP streams from causing
burstiness in the traffic and is hardly something that could be used with
isochronous streams such as audio or video.

>while the network is clear, so that you can scale back later when the

Possibly. But I think this should be handled through the transport, not
the control protocol. If the transport is a realtime one, then it seems
weird that someone would like to do buffering. Also, at the rates that
one speaks about when using audio and video, it's hardly useful to fill
up buffers beforehand. And if the transport isn't a realtime one, say,
it's TCP, then there is no real need for chaging the parameters - one
can use TCP's flow control mechanisms to take as much data as one can at 
any one time. So I don't believe RTSP should include features to control
realtime modification of the parameters.

>explain why non-RSVP routers care what the data rate is.

Not much. But they care about the stability of the data flow and that is
bound to shatter if one can rapidly change the data rates of such large
bandwidth streams as video and audio.

And what about the RSVP ones? One is bound to have them, sooner or later.

>Also please explain why variable bitrates are not good from a
>"good-netizen" point of view.

They encourage resource hogging.

>The reason why I ask is because we've taken heat before as "non net

Netizen-like behaviour calls for variable rates, but variable only
downwards. This can be handled through transport throttleback/congestion
control mechanisms. What the proposed bit-rate parameter does, however, is
a bit different. It allows one to increase one's reservations in real time
(leads to routing problems), it allows the reservations to change in
steps rather than continuously (leading to burstiness) and it encourages
resource hogging.

By the way, building congestion control with positive feedback isn't
generally a very good idea. If you rely on RTSP to control the data flows
when network conditions change, the best effort, possibly high-latency 
nature of the control link is bound to cause problems.

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

---

From: Alagu Periyannan <[email-masked]>
Date: Tue, 1 Apr 1997 12:52:12 -0800

Hi all,

I am a newcomer to this group and hope to participate
more in the RTSP discussion.

It seems to me that "speed=2.0" may be a nifty feature in
some cases where you want to buffer ahead.

But when you are buffering ahead you also want to say
"speed=2.0 for_range=0-10; speed=1.0 for_range=10-".
This would mean, I want to buffer the first 10 seconds
at twice the speed and after that start receiving at
normal speed.

In the above example on the server side, "speed" and
"for_range" are just parameters that are passed by
the RTSP subsystem transparently to the stream data
transport subsystem. There can be many such parameters.
These parameters are dependant on the stream data
transport protocol. Maybe we should have a flexible way
in which RTSP can carry such parameters.

Actually, why not use the "Transport" header for this?
Currently there are definitions of parameters for RTP,
like ttl=127, port=1234. We could easily add speed and other
arbitrary parameters to it.

Implementations that do not support a particular
parameter must have a way of stating it.

---------------------------------------------------
Alagu Periyannan                   [email-masked]

Interactive Multimedia Group
Apple Computer, Inc.

---

From: Sampo Syreeni <[email-masked]>
Date: Thu, 3 Apr 1997 13:43:30 +0300 (EET DST)

>some cases where you want to buffer ahead.

Did you mean bit-rate=2.0?

>"speed=2.0 for_range=0-10; speed=1.0 for_range=10-".

Hmm. Means a bit more complexity and more states in the server side...
However, as the cue lists are already used...

But as we've discussed before, there is some concern over the whole
bit-rate parameter...

>arbitrary parameters to it.

Indeed. Or do it by pure flow control.

---

From: Alagu Periyannan <[email-masked]>
Date: Thu, 3 Apr 1997 09:35:46 -0800

>Did you mean bit-rate=2.0?

I meant send it out at twice the speed over the network.

The timestamps on every sample may still correspond to
normal playback rate. The playback rate gets determined
by the "scale".