On Fri, 22 Jul 1994, Daniel W. Connolly wrote:
> But if we're going to try to boil the web down to one protocol,
> let's get it right:
>
> * cut out the TCP connection set-up time by using a UDP
> based protocol like prospero/ARDP.
I'll be dealing with this on www-speed shortly with the grand http
futures compare-and-contrast report, but since this ties in nicely, I'll
just through in a few quick comments, especially since I already posted
a report on how TCP and HTTP get in each other's way.
Abandoning TCP completely is almost always a bad idea. There are
exceptions to this rule; however unless the traffic pattern is almost
always to a different host, and the typical message size fits in a single
packet, you'ld better have a bloody good excuse :-)
One of the problems with going from TCP to an application specific
transport protocol is that you lose all the work that has gone into
making TCP work, and work well.
Any responsible wide-area transport protocol must implement slow-start,
or the network will soon enter congestion collapse (see Nagle's RFC on
what used to happen before slow start existed). Any new transport layer
will need to deal with recieve windows, retransmissions, time outs, round
trip time estimation, and message re-assembly. You can't even just use
UDP - if you want to do path MTU discovery, you need to twiddle the Don't
Fragment bit in the IP header.
By the time you've finished, what you've ended up with is your own
private implementation of TCP..
In the report I have shortish section on how changing the transport layer
can help, and what the costs are. The best solution along this dimension
of the solution space is probably to use Bob Braden's T/TCP, which is a
backwards compatible change to TCP which solves some of the problems with
TIME_WAIT, slow start, and the three-way handshake.
The real problem isn't with TCP, it's with HTTP. TCP is like planet
earth; abuse her and rape her resources, and she'll wreak vengance upon
you unto the fourth generation; Treat her with love and respect, and
she'll grant you a bountiful harvest for ever. [Overblow similies 'R' Us]
> * put authentication and compression in the transport
> layer (ARDP).
See above; unless you have real reasons for putting this in the transport
layer, you're almost always better off on the internet layering these
services above transport.
> * Allow for replicated servers and objects.
> * Separate object names from network locations
These two are part of a broader problem; name resolution and resource
discovery. I've done some work on this with the centroid architecture I
developed for whois++ and which has been adopted by SOLO; I hope to do
more with the next draft of SID (Simple Internet Directory). Although I have
great hope there will be a URN proposal within my lifetime, that hope is
predicated on my giving up smoking :-/ The Web as a whole may be better
off using one existing international standards, and using either the
name format defined in RFC 1487, or user friendly names (RFC 1484).
I will be adding support for SOLO into MDMA to make it easier to
experiment with names versus locations. SOLO is not a viable long-term
solution for Name->URL lookup, but it's real easy to code for, and
Paul-Andre has already added SOLO support to libwww, so client support is
easy.
SID is designed to be a general purpose Directory lookup service (this
one *is* layered on top of UDP, because it meets the 'single-packet'
criteria). It's based on a modified form of LDAP (Lightweight Directory
Access Protocol), but using a Whois++/SOLO style centroid architecture,
with all requests and responses tuned for the common case, and using the
Packet encoding rules. The end result gives a protocol that packages the
power of X.500 and the flexibility of Whois++ into a packet format with
less than half the overhead of DNS, and with a much cuter acronym
Simon