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

Yitzhak Birk <birk@bodega.stanford.edu> wrote on Thu, 24 Aug 1995:
  > 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.
ATM is only one medium that supports the Internet.  Please don't base
your proposal on an assumption that it will ride on ATM.  However, as
Harald Alvestrand pointed out, the RSVP working group is working on
resource reservation (but only in the context of multicast, I think).

Also, even if you reserve bandwidth, a receiver may still want to send
flow control information to the sender.  Imagine a VCR-like control on
playback.  The user wants to stop/pause/rewind/play.  You can't do that
if content keeps flowing down the pipe uncontrolled.  HTTP is ill-suited
for sending the control messages.
  > 
  > [Example about mineral water distribution deleted.  This must be
    California. :-) ]

I, and others, support the concept of a protocol that allows large
objects to be played out in real time.  We just disagree with you that
support for it must be part of HTTP.  You think it should.  We don't.
  > 
  > 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.
Okay, maybe "real-time" is a poor term to use, because the data are already
recorded, and their playback rate can be controlled.  So there are two
classes of object:
1) those that have no time-dependency, for which anytime delivery is okay.
2) those that have a time-dependency in their presentation
I assert that HTTP is well suited for the former and not for the latter
(nor should be).  I will agree with you that there is a similarity, in
that in each case you want to receive the entire object.
  > 
  > - 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.
I don't think anyone has said the semantics of the requests should be
hidden from the system.  They (we) have said this kind of request lies
outside HTTP.
  > 
  > - 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. 

All right thinking people (:-) care about performance, quality of service,
and other motherhood issues for the Internet.  We differ on whether HTTP
is the new univeral protocol.

I say it isn't.  I think something like PLAY is a good idea, but outside
HTTP.  I don't think you can arrange a playout protocol without
feedback from the receiver to the sender to control the data rate.
HTTP does not lend itself to such two-way traffic.

Dave Kristol

Received on Friday, 25 August 1995 07:01:53 UTC