Re: Draft Minutes of HTTP Working Group, 33rd IETF Meeting, Stockholm

As I was reading though this extensive wish list for what an http replacement
would look like, I nodded a lot; one place where I shook my head vigorously,
however, is the line "Copies of data must be avoided".  

I would argue that a better notion would be to make a protocol capable
of handling data replication in a smart way.   	Working with a number
of international programs has made me see the usefulness of replicated
data; the ability to connect to a server that is reasonably local can
be a tremendous win, especially in situations where a connection to
the Internet is over a very slow link.  While the URN to URL resolution
proposals provide a useful model for long-term work, some very simple
solutions could work for mirrorinng non-interactive pages even in the
short term.  A Mirrors: header, for example, could provide a simple list
of alternate URLS where the same data could be found (much like the lists
some ftp servers provide when user limits have been reached); the client
could then analyze the list and choose mirrors which are closer.  While
it may be difficult to determine what is "close" and what is "distant"
in network terms, there are some rules which could be built into the
clients.  (Actually, a clever server could do the same thing with 
redirects--read the client's network and domain from its headers and
issue a redirect to a closer mirror).  

Moving this sort of negotiation even lower in the protocol (so that it
occurs before other header negotiation) might be a bigger win yet,
although you might also want to go through the full negotiation to
be sure that the mirror contained the correct flavor of content (if
it were available in various char sets, for example).

Anyway, the basic point I want to stress is that avoiding data
duplication may be a win in some circumstances, but using data
duplication wisely can help you get a lot closer to some of your other
goals pretty quickly.
				Regards,
					Ted Hardie
					NASA NAIC


> 
> I was about to make a comment about why UDP for basic HTTP was inappropriate,
> but Jeff Mogul beat me to it, and as usual has said it better than I could
> have.  The congestion collapse of the Internet happened just when we were
> building X11.  The moral imperative to protect the Internet from
> disaster is emblazoned on the scars some of have from getting up in the middle
> of the night to get code across the country, when the network didn't work.
> 
> DCE RPC has several other problems, the most important of which
> is that it isn't available universally, and very difficult to make it so
> quickly, independent of other attributes that are needed, some of which are
> below.
> 
> Here are some requirements for technology used to build a new protocol:
> 	* ubiquitous: anything we depend on has to either be available 
> 	universally, or available and easy to port. 
> 	* needs to support non-blocking or streaming (often called "batching")
> 	of requests; if there is no error from a request and the request has
> 	no return value, the system shouldn't generate network
> 	traffic.  Round trips are the death of performance on a world
> 	wide network, with round trip times often measured in hundreds
> 	of milliseconds (or more).
> 	* needs to support streaming and interleaving of return values;
> 	entities need to be able to be multiplexed on the return connection
> 	from the server so we can do appropriate prioritization and
> 	prefetching of objects.
> 	* bit efficient: the web should be more usable over high latency and
> 	low bandwidth links. Too much bandwidth is going into protocol
> 	and metadata transport in current HTTP.  Think dialup modems,
> 	or use over cellular modems, and you immediately get round trips
> 	from 150 milliseconds to ~1 second before you start transiting
> 	a global network.
> 	* fast, at least for the server; think of servers connected
> 	to truly high speed networks, which may be delivering many
> 	video streams, or millions of requests/hour, for example. 
> 	Think of the load generated by a television AD for a neat
> 	product on a web server 5 years from now, 
> 	when that advertisment is made during the World Cup (world wide 
> 	interest, outside of U.S.)  or Super Bowl (U.S. only). 
> 	Everyone may turn around at the next commercial break and hit 
> 	the same server.
> 	Copies of data must be avoided.   
> 	Cycles and bandwidth on clients are much less dear, 
> 	but may be much slower systems, so speed on the client side 
> 	can't be ignored either.
> 	* doesn't suffer from error 33: basing work on top of someone
> 	else's research work while it is still research is a good way to
> 	cause a project (research or not) to never be completed.
> 	* reliable, dependable, and problems can get resolved quickly so
> 	forward progress can be made.
> 	* the usual comments about size, memory consumption, etc.
> 
> Not all of these requirements have to necessarily be fulfilled by the
> transport protocol itself, but the transport system certainly affects
> what you can do with what is built on top.
> 
> My suspicion is that rolling one from scratch down to TCP is the likely
> best choice, but I feel we need to understand if any system out there
> might in fact be useful.  I'd be VERY happy to be proved wrong.
> I've rolled more protocol stubs by hand than I care to think of for 
> two different systems both in widespread use, and I certainly do not love doing 
> so.
> 
> So I intend to spend some time looking around at what is out there that
> may fulfill the requirements. (ILU from Xerox, and others that 
> may be suggested to me).  Butler Lampson also pointed out to me that the 
> exercise of looking around at existing systems will likely pay off in good 
> ideas worth stealing, even if the RPC system itself isn't appropriate to this 
> application. (If you can't steal good code, at least steal good ideas; a good 
> motto, me thinks).
> 					- Jim Gettys
> 					  W3C
>

Received on Thursday, 10 August 1995 12:12:47 UTC