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

On Thu, 24 Aug 1995, Bob Wyman wrote:

> 
> This business of "items... which are retained" is a very important point.
> That is, HTTP is typically used to transfer contained objects around the
> network. Objects which have size, creation dates, etc. In fact, it isn't
> only clients that retain these objects but also a variety of proxies, caches
> , HTTP accelerators, etc. PLAY requires a completely different beast to be
> supported.
> 


> I would suggest that the cache problem alone would be enough to want to put
> streams on a different port or channel than that which is used for the kinds
> of objects that HTTP transfers today.  There are other good arguments as
> well...
> 
> 
> As mentioned before, HTTP performance can be improved and is being improved
> without introducing PLAY. It would seem that the "performance improvement"
> you are discussing would only really be provided to users of streaming
> applications.
> 
> 
> The tremendous amount of
> discussion concerning building state into HTTP (for shopping bags, etc.)
> would probably be nothing compared to what would result once PLAY shows up
> in HTTP.
> 

- Whether we like it or not, the different beasts do and will share the 
network. There (e.g., ATM forum), the issue of coexistance of traffic of
different types is being addressed. Among other features, ATM supports 
bandwidth reservation. 

- The beasts (items) themselves aren't different. In the case of PLAY as 
proposed, the requested item is also a wrapped object of known size. 
However, something is known about the requested delivery manner which may 
have important ramifications to the scheduling of server resources and 
use/reservation of network resources. 


- The claim that HTTP performance problems can be solved without PLAY is 
only partly correct: since the optimal (in an informal sense) 
allocation and scheduling of the server and of network resources 
depend on the performance measures, you should be able to do better 
if you knew what those measures were for each request. (E.g., latency 
until last byte vs. until first byte vs. first byte + rate).

- I am aware of the complexities of caches and proxies. However, taking 
the "half-full glass" approach, any use that is made of the knowledge of 
the true semantics of a request will be better than nothing. Also, caching 
considerations are not different than the usual, since these are the same 
objects that you are GETting today. I am only proposing to supply a 
useful hint.

My suggestion is to start with something, mandating only implementation 
stubs that implement GET in response to PLAY, and let things evolve. This 
does not preclude the eventual development of a replacement protocol.

-----------------
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 16:56:16 UTC