[5262] in www-talk@info.cern.ch
Re: Virtual Circuit protocols => universal access
daemon@ATHENA.MIT.EDU (Simon E Spero)
Mon Aug 22 20:54:16 1994
Date: Tue, 23 Aug 1994 02:51:49 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: ses@tipper.oit.unc.edu
From: Simon E Spero <ses@tipper.oit.unc.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
"Daniel W. Connolly" <connolly@hal.com> writes:
>What about a reliable, connectionless protocol, like ARDP? (Well, it's
>not really any more or less connectionless than TCP, but there is no
>connection establishment overhead in ARDP).
ARDP v5 ([1], pp 36-41) is not suitable for use as a transport protocol for
an http like protocol for several reasons.
1. No window control. ARDP does not support receiver window management.
The receiver has no way to prevent buffer over-runs.
2. No congestion control. ASRP does not use congestion control
mechanisms such as Van Jacobson slow start. This is a real
show-stopper; if a network becomes congested, and reliable
transport protocols without slow-start are used, the network
will experience congestion collapse. [2]
3. Vulnerable to packet duplication. ARDP does not provide any
support for detecting earlier incarnations of a connection using
a given connection id. This leads to a whole host of problems-
many of these are outlined in [3].
4. ARDP does not support path MTU discovery. ARDP instead uses a
fixed maximum size for datagram- for bulk transfer this either
leads to datagram fragmentation or an excess number of packets.
5. ARDP does not estimate re-transmission delays. This leads to
large throughput loss in the event of a dropped packet.
ARDP was not designed for use as a data transfer protocol - it was developed
for use in a distributed directory service; in this application class, the
expected transaction profile consists of a single packet request, followed by
a single packet response.
>Yes, but those queries are not conducted over the same connection, nor
>should they be, except in the case of inlined images. Short connections
>is one of the major wins of gopher/HTTP typical usage over FTP typical usage.
>No server resources are consumed while the client user browses.
This is incorrect. See [4] and [3] for information. A TCP connection continues
to use resources for around four minutes after the connection has been closed.
The typical transaction pattern observed on a sample of one million
sunsite transactions shows that around two thirds of all user sessions
involve access to more than one non-gif object, where a session is
defined as a sequence of HTTP accesses from a single host with an
inter-query gap of not more than 4 minutes.
Simon
References:
[1] The Prospero Protocol/version 5/ Neuman, B. C. AND Augart, S. S. /
Information Sciences Institute, University of Southern California/
12 June 1993
ftp://prospero.isi.edu/pub/prospero/doc/prospero-protocol.PS.Z
[2] Congestion Control in IP/TCP Internetworks/ Nagle, J/
Ford Aerospace and Communications Corporation/
RFC 896/ 6 January 1984
http://sunsite.unc.edu/pub/docs/rfc/rfc896.txt
[3] Transmission Control Protocol/ Postel, J. / Information Sciences
Institute, University of Southern California/
September 1981/ RFC 793
http://sunsite.unc.edu/pub/docs/rfc/rfc793.txt
[4] HTTP Performance problems/ Spero, S. / University of North Carolina
at Chapel Hill / July 16th 1994
http://elanor.oit.unc.edu/http-prob.html
