Subject: RE: Pause, Fast-Forward, Fast-rewind in RTSP

From: Eric Fleischman <[email-masked]>
Date: Thu, 6 Mar 1997 10:54:40 -0800

Anup Rao wrote:
>I do not understand how the PAUSE message has an effect on scalability.
>Indeed, it is not necessary from a user point-of-view. There seem to be
>two issues here:-
>a) maintenance of current position at the server
>b) maintenance of "SETUP" information ie. transport ports etc.
>Note that we do not have the notion of "STOP", rather a "CLOSE" which
>results in release of resources.
>Are you arguing against a) or b) or both ?

I am not actually intending to argue against either a or b since I view 
both as being necessary.

Rather, I am working from a different algorithm altogether, as I explained 
in my original posting. My algorithm is to explicitly minimize the work a 
server has to perform so that the server can better perform its task of 
actually streaming data. The more complexity we put into the server, the 
move overhead the server must give to manage that complexity and the less 
time it has for its primary task of streaming data (unless, of course, you 
have a multiprocessing system with an "extra" CPU to offload such overhead 
to).

This means that the server needs to be more focussed (dumber, if you 
prefer). The client maintains the state, the server responds to the 
client's commands. The commands thus need parameters to "clue in" the 
server as to what the client exactly intends since it is the human end user 
(i.e., the client) which controls what happens within the constraints 
originally designed into the experience by the content creator.

I am sorry that I introduced a new term (i.e., STOP) into the discussion. 
This was a mistake on my part. Please overlook this failing.

>There are two ways that the concepts of FF and FRewind may be thought of
:

>a) Simply deliver the data as-is, but faster than its natural  rate
>based on the speed parameter. As Henning mentioned, this is specified.
>Admittedly, this is useful only if bandwidth permits and should be used
>with care, but it should not be entirely ruled out.

I have real problems with this alternative. I believe that streaming data 
must maintain a constant data rate. That rate must not fluctuate up and 
down. Take, for example, the possibility of the data being streamed into a 
H.323 conference which happens to also be "broadcasted" over the MBONE 
through the use of H.LooselyCoupled. SDR will tell the address and port of 
the MBONE broadcast and should indicate the bandwidth needed to support it. 
Network Managers would have "reserved" (so to speak) that bandwidth to 
permit individuals within their corporation to receive the session, perhaps 
by filtering out other less desirable bandwidth-consuming alternatives so 
that other work can also proceed. However, should the data rate of the 
streamed content fluctuate all over the map, the net result will be a total 
breakdown of the system. As a former corporate data communications 
architect, I can well imagine what the future policy for those types of 
sessions will be within that (receiving) corporation.

What I am saying is that if this streamed content is to "play well with 
others" and be genuinely useful in integrating with conferencing apps, and 
if it should not give network managers major heart attacks, then it must 
conform to a maximum bit rate above which it never goes. Your (a) 
alternative then has substantial needless complexity since you compute what 
"fast" means for each given session instance for channels which are 
session-specific. A much simpler algorithm is to do as we suggest and to 
maintain a constant data rate, accelerating only the timeline when "fast" 
is occurring.

Regards,

--Eric

---

From: Anup Rao <[email-masked]>
Date: Thu, 06 Mar 1997 12:09:52 -0800

> I am not actually intending to argue against either a or b since I view

Option1 : No PAUSE message.
In this case the setup information would have be included in the
PLAY.(because, if you "CLOSE", you have to setup the information  again
i.e send SETUP.) For each PLAY, the server would need to check if the
transport was set earlier or changed. Also, (as agreed above), we have
chosen that it(the server) maintains current position. This gives us
binary state ie. either sending or not sending. Also, lets assume the
PLAY message always contains the Range. Proxies/firewalls need to read
both PLAY and SETUP messages.

Option2 : There are 3 states: ready, sending, not sending. There is a
PAUSE message. On receipt of a SETUP message, the server follows orders
and does not check if transport is set earlier or not. On a PLAY
message, it is honored only if transport is set(ie. in state ready).
Proxies/firewalls need to read the SETUP message. 

I am a great supporter of the dumb server:-) idea. Forgive my
persistence, but I do not understand how Option1 would result in a
dumber server than Option2. Note that I am not arguing too strongly in
favor of either, but I think Option2 is cleaner and has a precise
indication of allocation and release of  resources. It seems to me that
the alternative have roughly the same complexit, whether we create a
state or not. (On thing that needs clarification though ie. at minimum
transport should be set before sending PLAY).

> sessions will be within that (receiving) corporation.
As I said earlier, it should be used carefully when appropriate. One may
configure to not choose other high-bandwidth alternatives, and similarly
also not allow this alternative. I am not saying that we should have
this ability so that everyone can wreak havoc. Also, it is a resource
issue - the server may not be able to do it - and it should just refuse.
All I am saying is that it is useful in *some* cases eg. remote
editing/previewing of streams where the video-type fastforward based on
subsampling is not possible. For example a presentation consisting of
only images and text ticker, changing at 2 second intervals(hence
time-related), that the editor wants to remotely preview at twice the
rate. Clearly sending every other image is pointless here. 

> Your (a)

I'm afraid I dont understand this fully. (due to our terminology again,
I think). What the channel or URL means with respect to different
streams/substreams is upto the session description. Yes, if the session
description describes 2 streams, you have to calculate what fast means
for both of them. However, as I've said above, in general the
alternative a)  is not the way to do things in a lot of the cases,
particulary video. For simplicity in these cases, a server may just
refuse.

On a similar note :- What may be  of some concern(I just thought), there
is no indication in the protocol messages of the bandwidth that the
stream will occupy(other than the Accpet header that is not
authoritative. )Rather, this is in the session description. This may
complicate implementation of an intermediary - it will necessarily have
to know the session description. (For eg., a packet filter may want to
know what the data transfer rate will be). Comments welcome.

-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : [email-masked]         Phone : (415) 937 3129       
-----------------------------------------------------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Mar 1997 15:30:10 -0500

Would it make sense to have a two-parameter Speed header: the network
speedup and the logical (time-line) speedup? That way, we cover both
cases and the server can decide what it can/wants to do. I may well have
"I want twice the video frame rate, but don't care if you send me twice
the data rate or if you drop half the frames". Something like Speed:
2/*. Or Speed: 2/2.

---

From: Sampo Syreeni <[email-masked]>
Date: Fri, 7 Mar 1997 23:35:20 +0200 (EET)

On Thu, 6 Mar 1997, Eric Fleischman wrote:

> down.

I agree. It is very important in the face of multicasting connections
that the data rate is constant. It is hard enough to do QoS and resource
reservation without fluctuating data rates.

> maintain a constant data rate, accelerating only the timeline when "fast" 

Do you think this fits in with the concept of a 'focussed' server?

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