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

On Thu, 24 Aug 1995, Dave Kristol wrote:

> I don't believe you can negotiate all the flow parameters in advance,
> because the state of the network changes, and the changes affect the
> streaming.  Thus it's likely there will be two-way communication
> between client and server to adjust the data rate.  HTTP is ill-suited
> for such communication.
> 

I believe ATM supports bandwidth reservation and should be able to 
guarantee it.

> People here at Bell Labs have done some work on real-time delivery over
> the Internet.  (See <http://www.research.att.com/~hpk/nemesis.html>.)
> They use a separate connection in an outboard application, which was
> the basis for my earlier description.
> 
> I see that superficially the PLAY method fits into the HTTP paradigm,
> but I think the details make the fit a poor one.  Adding a bunch of new
> headers, and possibly client-directed flow control, means you're a good
> way toward a very different protocol.  So make it a different protocol!
> 

To best illustrate why I think it may be useful to 
include PLAY in HTTP (not to the exclusion of subsequent better and 
separate solutions), let me use a simple example.

Suppose a mineral-water distribution company receives one order for 
100K bottles and one hundred 2K-bottle orders. My claim is that 
the company would really appreciate being told that the 100K bottles are 
needed at the rate of 2K per day and not ASAP for a big bash, and that the 
client can store up to 5K. The extent to which the company is actually 
able to take advantage of this knowledge would depend on many factors, but I 
think it is pretty clear that one should provide the information. Also, 
it is clear that trickling the bottles of the large order at exactly 2K 
per day, or 2K/24 per hour, is not required, and loose scheduling is 
possible.


In summary, I have tried to make several points:

- Within the simple, common use of HTTP, there are sufficiently important 
cases in which large amounts of data are requested, the semantics of the 
request differ dramatically from the usual "everything ASAP", yet are 
also very different from "real time" with the associated strictness and 
difficulty of implementation.

- Hiding the semantics of these requests from the "system" affects 
performance, since the scheduling and resource-allocation decisions 
throughout the system may be based on the wrong performance measures for 
those requests.

- The issue can be addressed in various ways, levels of quality and 
difficulty. Doing something is better than nothing, and it is not an "all 
or none" situation.

Having said all this, I hope to have shed light on an issue that is 
relevant to HTTP since it influences its performance as perceived 
by its users as well as its "good citizenship" on the network.  As such, 
the HTTP community should be interested in having something done about 
it.  I hope to have convinced people of this, regardless of who should do 
this and whether it should be included in the HTTP protocol itself.
Related to the question of whether or not this should be done within 
HTTP, it is perhaps time to better define the scope of HTTP, for example 
by stating explicitly the (assumed) semantics of HTTP requests. 


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 18:00:11 UTC