- From: <touch@isi.edu>
- Date: Wed, 19 Feb 1997 09:42:25 -0800
- To: touch@isi.edu, luigi@labinfo.iet.unipi.it
- Cc: ses@tipper.oit.unc.edu, masinter@parc.xerox.com, http-wg@cuckoo.hpl.hp.com
> From luigi@labinfo.iet.unipi.it Tue Feb 18 23:09:27 1997 > > > > > > 1) try alternate protocol, and use it if it works. Cache result > > > > Increases the connection latency. Bad in general. Besides, > > > > > > Adds an extra RTT to first connection to host > > > > Only if "fails" is by NACK. Otherwise, it adds > > a timeout, which is usually in the 2-3*RTT range, _at best_. > > It should normally fail by NACK (with the equivalent of ICMP port > unreachable), so that's not much of an issue. Since the result of > the probe is cached, this is not more costly than a DNS lookup. > Besides, you can probe in parallel all (are they 2, 3, 4 ? not > certainly a dozen) the known protocols and continue the transaction > using the preferred one among those available. ICMP port unreachable is a "MAY", not a "MUST". It also can increase the load on the server, especially when you probe in parallel. There is only one known protocol for which any of this works, as pointed out earlier - TCP. Using non IP reliable full-duplex connection transports requires redoing the rest of the URL anyway (to change the interpretation of the host address and port, which is IPv4-specific), so using a new protocol ID (http-tp4:) is necessary anyway. Supporting HTTP over non full-duplex, connection-oriented protocols requires other modificiations - i.e., serial numbers to associate responses with requests, at least. What is the advantage to a transparent selection of transport protocol, given these constraints?? Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/
Received on Wednesday, 19 February 1997 09:49:46 UTC