Re: Proposal: a PLAY or STREAM method for http/1.1

Dave and Bob,

Thanks for your remarks. Following is my reply, in which I have tried to 
argue strictly from the perspective of HTTP and its current mainstream use.

Dave Kristol <dmk@allegra.att.com> wrote:

>IMO, this kind of method is outside HTTP.  I think it is best handled by
>(conceptually, at least) an outboard application...
>HTTP is not all things to all people, and I think one of the things it
>is not is a real-time transport protocol.  It seems to me much better
>to segregate such sophisticated real-time processing elsewhere.
-------------

Bob Wyman <bobwyman@medio.com> wrote:

>I agree with this (Dave's) position at this time.

>I suggest that while Yitzhak Birk may have established a requirement for a
>connection which provides the semantics he defines as being needed by 
>"PLAY", what he hasn't done is establish the requirement that HTTP be the 
>protocol which provides the required semantics. Yitzhak's only attempt at
>rationalizing that HTTP should be the mechanism for supporting PLAY is his
>FAQ item in which he argues between HTTP and HTML. There are other
>alternatives... TCP/IP supports many ports -- we don't have to pump
>*everything* through port 80...
>...
>Play is not the only protocol type which is not well served by HTTP today.
>...
>The growing popularity of HTTP is certainly compelling, however, just
>because it does what it does doesn't mean it should be made to do everything
>else. It would be more reasonable to define a family of protocols that
>interwork well within the context of a single, reasonably easy to construct,
>multi-protocol client.
------------------------------------------

Clearly, it is always possible to define another protocol and use it
to get things done. I nonetheless still argue that the semantics of
PLAY should be "native" within HTTP, for reasons that have to do with
the way in which HTTP is commonly used and its own performance:


- HTTP is commonly used for viewing items, some of which are retained
by the client.

For items that only have spatial dimensions, the GET semantics are
appropriate both for viewing and for retention. Various optimizations
for these items are aimed at overcoming the artificial temporal
dimension introduced by the fact that fetching is not instantaneous.

For items that do have a built-in temporal dimension, such as video or
audio clips, GET semantics are still appropriate when the desire is
strictly to fetch and retain, but PLAY semantics are the right ones for
viewing (with or without subsequent retention).

Since viewing very often precedes retention (the decision whether to
save may even depend on the result of the viewing) and an increasing
fraction of material has a temporal dimension, PLAY semantics are as
natural as GET for the current mainstream use of HTTP. The fact that
such items tend to be voluminous raises the importance of recognizing
the true semantics of requests for them.


- In examining the discussions of HTTP and the proposed extensions,
performance is clearly of great concern to the HTTP
community. Concerns include the self-induced problems (e.g., due to an
excessive number of handshakes) as well as suboptimal use of shared
resources (multiple connections for the same document, speculative
prefetching, etc.).  As is often the case, it is somewhat difficult to
provide good solutions without knowing the requirements. Both server
performance and network performance can be improved significantly if
the semantics of a request are known. (This applies to both types of
concerns.)

- I share the reluctance to turn HTTP into a "real-time" protocol, and
do not suggest to do so. 

Unlike interactive applications such as games or video conferencing, however,
streaming applications can strike a comfortable balance between delay
in the beginning of a presentation, buffer size, bandwidth and
glitches. Therefore, HTTP need only convey the requested semantics and
perhaps a few simple attributes. The rest is left to the
implementations of the client, server and network. A simple server
might treat PLAY as GET. A more sophisticated one might blast an
initial amount of data to fill the client buffer and then try to
stream data such that the buffer would not become empty or
overflow. Network type and condition would also influence the
service. All this could be handled through optional extensions with
simple defaults once the semantics are there, and does not impose any
mandatory complexities. Yet, it does enable one to do better, offering
a challenge and an opportunity. All this in the context of current
mainstream use of HTTP.


In summary, I argue that the PLAY semantics for streaming (as opposed
to truly interactive conferencing) do fall well within the natural
scope of HTTP, even for its current mainstream use, and believe that
their inclusion in HTTP would facilitate substantial and meaningful
performance improvements. In the absence of PLAY, I suspect that people 
will simply continue using GET rather than develop a new protocol for 
a subset of "HTTP-like" requests, and overcoming the resulting 
performance problems will be more difficult. 

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

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 Thursday, 24 August 1995 13:05:11 UTC