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

From: "Marc Eshel/Almaden/IBM" <[email-masked]>
Date: 5 Mar 97 22:08:31

Hi,
Maybe we can require the offset to be on PAUSE and PLAY so you can have a
'state less'
server, but if you want to implement a server that doesn't tell a client after
a PAUSE that the
resources are gone and he can not continue to play because he paused and the
resources
were used for another stream, or if you really want to be ready on the server
by pre-fetching
the stream so when the play comes you can respond faster you need the offset on
the PAUSE too.

Marc.

---

From: Eric Fleischman <[email-masked]>
Date: Thu, 6 Mar 1997 13:27:37 -0800

Anup,

I wish to apologize to you and to this list. I am in the process of
"cleaning house" in preparation for a 9 day vacation. This conversation
which we are having is extremely interesting to me. I deeply regret that
I must shortly go "off line" and I want to be sure that you know that
this is entirely unintentional and is not reflective of the quality of
your much-appreciated comments. I also hope that you wouldn't be too
upset once I try to again rejoin you all on the 17th or 18th of March.

Had I not been in my current hurried state, I would have proposed that
we form a conference call among interested parties. It seems to me that
we need to spend a bit more time building "foundations" and the purpose
of that conference call would be to establish some tentative
foundational "straw men".

Specifically, I would like us to agree on a common set of terms in line
with the thread originally started by Intel. This will help us correctly
interpret the words which are being written/said.

Once that is done I would like to see us "open our respective kimonos"
about how we envision a RTSP session to progress. Our goal here is
two-fold: RTSP needs to be adequately general to support real-life
variability and a broad range of requirements but adequately specific so
that interoperability may be attained. 

These various RTSP session scenarios would suggest a state machine. I am
a firm believer that the defining of such a state machine is an
essential exercise since the whole spec hangs upon its foundation. This
would be particularly helpful for the current spec since it has many
methods in section 9 which I do not envision ever using and I am
confused about what parameters are available for any given method (i.e.,
what do "?" and "o" mean in Tables 4 and 5 of section 11?) and how those
parameters are to be used. I also note the obvious disagreement (as
evidenced by the embedded comments) between the authors and fear that
this may have produced hidden inconsistencies or situations where two
people interpret the same text in contradictory ways without knowing it.
I also have the significant fear that I have misunderstood some very
fundamental intentions of the spec.

However, if I were to "open my kimono" as to how I view an RTSP
"on-demand" session as progressing (i.e., a "live" session would behave
differently) I would say the following:
1.	User finds out about the session through some out-of-scope
vehicle and issues a GET command to retrieve all of the necessary
session information. The GET command would return a so-called "header
value" (i.e., the header field of the multimedia file (e.g., AVI,
QuickTime, RMFF, ASF, etc.) which has stored the multimedia experience.
This so-called "header value" contains all of the information necessary
to interpret the data fields within that file including the codec
information, the various encoding strategies, information about what
security and error correction has been used, "marker" information for
"indexing", etc.) and associates a dynamic RTP payload type for RTP data
for that session (or indicates what other data comm approach will be
used including streaming the data over UDP, TCP, or HTTP). Note that
this tells the client everything they need to know to be able to control
the session.
2.	The client then says "Play" with an offset into the timeline and
the playing begins (this includes the possibility of doing a
fast-forward (i.e., using the speed parameter for play) or jumping
directly to a synch-point indicated by a marker and start playing from
there).
3.	At some point the client can say "pause" and the playing will
stop.
4.	The client can then say Play with an offset to resume playing
(or fast-forward, fast-reverse, or jump directly to a synch-point
indicated by a marker and start playing from there (again Play with an
offset)). 
5.	At any point the client can say "Close" (or "BYE" - I don't know
why we need two methods to say what appears to me to be the same thing)
and the session is ended. 

This alternative suggests a state machine with the following states:
1.	Data is being streamed
2.	Data is not being streamed
This approach does not permit a session to exist which has not been
fully specified to both the client and the server - incomplete session
definitions are entirely verboten. The approach does not distinguish the
rate at which the timeline is being presented to the client. It does not
need to do so because the client is providing the intelligence to drive
the experience within the constraints established by the content
creator. This is particularly important when we stream 3D modeling data
(e.g., VRML) as media types within the experience since that media type
would introduce intolerable numbers of additional new states for a
"server-state"-driven approach such as what Anup seems to be suggesting.
This simple state machine is all that is needed to ensure that the
client and server are "in synch" with what the user is telling them to
do.

This view reflects my firm belief that "simpler is better". Please let
me know if you see any "holes" with these claims.

	-----Original Message-----
	From:	Anup Rao [SMTP:[email-masked]]
	Sent:	Thursday, March 06, 1997 12:10 PM
	To:	Eric Fleischman
	Cc:	'Sampo Syreeni'; 'Jeff Smith'; 'Henning Schulzrinne';
[email-masked]'
	Subject:	Re: Pause, Fast-Forward, Fast-rewind in RTSP

	Eric Fleischman wrote:
	> 
	> 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.

	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).

	> 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.

	> >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.
	> 
	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)
	> 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.

	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: Adrien de Croy <[email-masked]>
Date: Fri, 07 Mar 1997 13:44:35 +1200

Hi all, sorry if I seem to be sticking my oar in. 

Couple of points - RAM is cheap, but bandwidth is not.  You can (pretty
much) always buy more RAM, but you don't always have access to more bandwidth.

I can't see why storing the current client position (for a session) at the
cost of a couple of bytes of RAM should be deprecated in favour of having to
re-establish socket resources, and retransmit what should really be
redundant data.

Here's my vote for a PAUSE command which pauses rather than stops.

Cheers

Adrien

At 12:09 6/03/97 -0800, Anup Rao wrote:
>Eric Fleischman wrote:
>> 
>> 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:-
>> >b) maintenance of "SETUP" information ie. transport ports etc.
>> >Note that we do not have the notion of "STOP", rather a "CLOSE" which
>> I am not actually intending to argue against either a or b since I view
>> both as being necessary.
>> 
>
>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
>Option2 : There are 3 states: ready, sending, not sending. There is a
>PAUSE message. On receipt of a SETUP message, the server follows orders
>message, it is honored only if transport is set(ie. in state ready).
>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
>> 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.
>> 
>
>
>> 
>> >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
>> 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
>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.
>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
>> 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.
>
>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
>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
>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
-------------------------------------------------------------------------------
Adrien de Croy - [email-masked].  Qbik Software Limited, Auckland, New Zealand
                 See our pages and learn about WinGate at http://www.qbik.com/
-------------------------------------------------------------------------------