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)