Proposal: a PLAY or STREAM method for http/1.1

I am new to this group, coming from a background of storage and
communication subsystems for video servers + familiarity with
networking. I've gone through the HTTP/1.0 and preliminary 1.1
proposals + the relevant http-wg email exchanges, and also looked in
Simon Spero's preliminary NG draft of March '95. Finally, I am aware
of the proposal made by David Levine in May '95 for a transfer-rate
parameter and the discussion that followed.

In this note, I propose to add a "PLAY" (or "STREAM") method to
http/1.1 in support of data-streaming applications.  My proposal is
stated briefly, followed by FAQ (by me, so far...) which expose my
rationale. I am looking forward to comments on the proposal,
alternatives, as well as suggestions for appropriate attributes.

-----------------------------------

PROPOSAL:  add a "PLAY" (or "STREAM") METHOD to HTTP/1.1

The semantics of GET are "provide the requested entity in its entirety
as soon as possible". Various qualifiers may influence the content,
but the basic semantics remain unchanged.

The semantics of PLAY are "provide the requested material at the
suitable rate for playback, starting as soon as possible".  

Similarly to GET, PLAY could have various qualifiers. For example, one
could request the highest data-rate option that the server (and
perhaps the network) is capable of guaranteeing at that time. Also,
client-buffer-size may be provided in order to help the server manage
its resources in a flexible manner without causing glitches (and
determine whether it can provide the guarantees).

Based on the knowledge of the true request semantics, the server can
allocate its resources much more intelligently than otherwise, sign an
appropriate contract with the network (a constant-bit-rate ATM virtual
circuit, for example), and the system as a whole can provide the best
possible service with minimum disturbance to other
activity. (Alternatively, the server may refuse service if sufficient
resources cannot be committed or negotiate down to GET.)  As the
fraction of network traffic that has this "stream" nature increases,
the ability to recognize a request's true semantics and to service it
properly will become extremely important. In contrast, an inability to
convey the "stream" semantics would result in an unusual situation
whereby lower communication layers provide richer semantics than
higher ones can exploit. This would be unfortunate.

One important case in which PLAY better represents the request
semantics is an audio or video file that the user wishes to view
rather than to "download". Explicit support for such requests would
facilitate the penetration of WWW in general and http in particular
into domains that are still (conveniently?) viewed by some as best
served by closed, proprietary systems.

-----------------------

Initial Q&A regarding a "PLAY" or "STREAM" method in http/1.1

Q0. Is PLAY meaningful on the internet?

Usefulness in the very near future will vary dramatically by
location. However, including PLAY in http now would pose a challenge
and set a goal for infrastructure implementers, and would help in
shaping the priorities. Also, it may find use in "closed" subnetworks,
helping http gain broader acceptance and facilitating integration of
"bulk" and "streaming" infrastructures.

Q1. Should PLAY be in http or part of html?  

Since both download (GET) and PLAY requests are sensible for the same
file, the only place is http. (The file may contain playback directives.)

Q2. Can PLAY be closely approximated by a sequence of GET(byte range)?

NO! The server would not possess the right criteria for accepting or
rejecting the request. Even if it did, it would not be able to offer
guarantees for the entire movie, since each GET would be considered in
isolation. Finally, even if things did work (aided by sufficient
client buffering), the traffic pattern presented to the network would
differ dramatically from that with PLAY (bursty instead of nearly-fixed
bandwidth), creating unnecessary problems there.

Q3. Is PLAY the same as GET(transfer rate)?

The two are conceptually different, since PLAY states what is
required, and GET(rate) specifies how it should be done. Confusing the
two is not a good idea, since problems may show up and flexibility is
reduced.

Consider, for example, the case of a variable-rate stream. PLAY would
enable a "smart" server to supply the entire stream correctly in
response to a single request. A sequence of GET(byte-range, rate)
requests (with the client parsing the data and issuing the requests)
could perhaps imitate this. However, the server would again be unable
to reserve resources (its own, network, etc.) for the duration of the
entire stream based on the semantics of GET.

Q4. Would a session extension do the trick?

This comes closer if the session setup reserves bandwidth. The server,
however, is still unaware of the commitments (e.g., storage bandwidth)
that it has implicitly made, and service interruptions may result.


Q5. Should PLAY be a separate method or some new descriptor of GET?

The semantical difference between PLAY and GET is at least as large
and fundamental as between GET and HEAD, ==> method.

Q6. Should PLAY also be provided in the reverse direction?

I think this is not necessary, as I don't envision "playing" data to a
server. (The server can always request if it wishes, using PLAY).

Q7. Would PLAY  be used in practice? 

Since the difference between "download" and "play" is very intuitive
to any user and application writer, I expect it to be used frequently
(infrastructure permitting).


---------------------

Yitzhak Birk
EE Dept, Technion - Israel Inst. of Technology  birk@ee.technion.ac.il
Presently at HP Labs, Palo Alto.  (birk@bodega.stanford.edu, birk@hpl.hp.com)

Received on Wednesday, 23 August 1995 19:39:44 UTC