Subject: Speed field in RTSP

From: Eric Fleischman <[email-masked]>
Date: Wed, 26 Mar 1997 15:23:14 -0800

The current RTSP spec permits the play and record methods to have an
optional speed field. The speed field indicates an altered data rate so
that a "speed 2.5" on a play would mean to send 2.5 times the previously
negotiated amount of data within that session.

Speed in the current spec can be a negative number. I believe that this
should never be permitted to occur because a negative number is not
physically possible: the sink never becomes the source. Rather, what
should occur is for the scale field to be permitted to be a negative
number. Please recall that scale field advances the timeline thereby
permitting fast forwards and fast rewinds to occur at a user-specified
rate - a much more appropriate field to indicate "rewinding".

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?

---

From: Sampo Syreeni <[email-masked]>
Date: Fri, 28 Mar 1997 15:04:32 +0200 (EET)

On Wed, 26 Mar 1997, Eric Fleischman wrote:

>physically possible: the sink never becomes the source.

True.

>speed field within the spec.

So am I, and have been from the very beginning.

>I believe that it is a very dangerous
>alternative and leads to many nasty problems.

Especially after it is used in high-latency, big-bucks-per-MBps, multicast 
WAN applications.

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

---

From: Larry Rowe <[email-masked]>
Date: Fri, 28 Mar 1997 11:21:13 -0800

Hi -

I have watched the discussion on the speed/rate issue for some time.  We have 
been developing and using a toolkit, the Berkeley Continuous Media Toolkit, 
for the past four years that has the speed attribute built-in to the logical 
time system and playback abstractions.  The CMT logical time system (LTS) 
abstraction has a speed property that can be positive or negative. We find it 
a very useful construct.  Obviously not all sources can support backward play, 
but who cares, the software just ignores that situation.  That is, the LTS 
runs backwards, but objects that don't have any actions to take when that 
happens just ignore it.  This is probably too detailed for this discussion, 
but I want to *strongly* support Eric's arguments for a speed attribute that 
can be positive and negative.

I'll also weigh in on the bitrate issue.  Clearly, the standard must support 
the use of scalable codecs that might dynamically alter the bitrate being sent 
based on any number of characteristics (e.g., decoding speed of the client, 
channel capacity/jitter, server capacity, etc.).  In addition, it must allow a 
client to select a stream bitrate when it is established.  It might make sense 
to allow the client to request a change in the bitrate or the format when the 
stream is paused.  The issue from my perspective is that we will have a 
heterogeneous network for a long time to come and content providers want to 
produce products that can be played differently on different networks. The 
playback system must accomodate this feature.  I'm not sure it needs to be 
built into the server protocol, but it should be possible to implement these 
features.
	Larry  
-- 
Professor Lawrence A. Rowe               Internet:  [email-masked]
Computer Science Division - EECS         Phone: 510-642-5117
University of California, Berkeley       Fax: 510-642-5615
Berkeley, CA 94720-1776
URL: http://www.bmrc.berkeley.edu/~larry

---

From: Sampo Syreeni <[email-masked]>
Date: Sun, 30 Mar 1997 16:06:52 +0300 (EET DST)

On Fri, 28 Mar 1997, Larry Rowe wrote:

>but who cares, the software just ignores that situation.

I agree that there is real use for the 'scale' parameter. And also
negative ones. But there are synchronization issues that have not been
resolved. How about in your product? But the modification of removing
negative 'bit rates' is a good one also as one hardly needs negative
transmission speeds.

>channel capacity/jitter, server capacity, etc.).

True. But I think that this can be implemented out-of-band (in respect to 
RTSP), that is, through the stream transport mechanism. At least most
varispeed codecs that respond to congestion do it through monitoring acks
and sending information about the changes in the stream itself. And this
is also more stable: congestion, delays and other bottlenecks that might
affect RTSP transmissions do not get in the way when using this approach.

>In addition, it must allow a 
>client to select a stream bitrate when it is established.

That is very reasonable.

>It might make sense 
>stream is paused.

Why? Can you give any examples?

>The issue from my perspective is that we will have a 
>playback system must accomodate this feature.

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.

>I'm not sure it needs to be built into the server protocol,

Indeed.

>but it should be possible to implement these features.

So more discussion is obviously needed.