Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site wdl1.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!hpda!fortune!wdl1!jbn
From: jbn@wdl1.UUCP
Newsgroups: net.dcom
Subject: Re: Re: Re: Standards for commercial pac
Message-ID: <678@wdl1.UUCP>
Date: Tue, 27-Aug-85 23:29:22 EDT
Article-I.D.: wdl1.678
Posted: Tue Aug 27 23:29:22 1985
Date-Received: Sat, 31-Aug-85 04:59:26 EDT
Sender: kimery@wdl1.UUCP
Organization: Ford Aerospace, Western Development Laboratories
Lines: 59
Nf-ID: #R:cbosgd:-144100:wdl1:11700021:000:3174
Nf-From: wdl1!jbn    Aug 27 19:05:00 1985

Datagram systems have some serious problems.  Here are a few of them.

    1.  In a pure datagram system, with no link-level retransmission, the
	probability of successfully forwarding a packet througn N nodes
	declines exponentially with the number of nodes.  Ham users of
	digipeaters and UNIX users of async links for IP datagrams are
	painfully aware of this phenomenon.  You really do need link-level
	retransmission in any sizable datagram system, unless the medium
	has very low error rates.

    2.  Congestion is a serious problem in datagram systems.  No really good
	general solutions are known.  I've solved some problems associated with
	some of the simpler cases (IP/TCP via Ethernet to slow link gateways)
	but a general solution is still elusive.  There are tough theoretical
	problems here; there may be a way to organize an arbitrarily large
	datagram network, but it hasn't been discovered yet.  Telephony
	has been around long enough that we know how to build very large
	virtual circuit networks.

    3.  Datagram networks tend to break down when fully loaded; this is a
	consequence of (2) above.  There are ways around this, but they
	involve running the system in a derated mode, where keeping all
	links as busy as possible is not attempted.  The ARPANET technology 
	really works only because the ARPANET has substantially more link
	bandwidth than it needs for its traffic volume; this is
	a well known problem.  TELENET started out with ARPANET technology
	but has since gone to virtual circuits internally to get better link 
	utilization.  In any case, the IMP system of the ARPANET is not
	a true datagram system internally, although it exports a datagram
	interface.

    4.  Datagram systems have some serious vulnerabilities.  One bad guy can
	hog the network and clog up the links.  Datagram systems tend to
	rely on hosts being well-behaved.  With virtual circuits, the network
        has a positive throttle over host traffic generation, and can keep
	bad hosts from interfering with other traffic.  In networks with
	no central administrative authority over hosts, this is a serious
	problem in practice.  The ARPANET/MILNET gateways are already
	under serious strain because of this exact problem.  Tight standards
	and anti-bad-guy queuing algorithms in nodes can solve this
	problem; unfortunately the Internet lacks both.

    5.  Accounting is difficult in datagram systems.  What should a phone
	bill for a datagram net look like?  Histograms of traffic by
	time and destination?  Just a total amount?  The network may need
	to recognize clumps of packets for similar destinations and treat
	them as a ``call'' for billing purposes.  

This may sound odd coming from me, as a builder of datagram gateways.  But
datagram systems are useful in the military environment, where the important
thing is to keep going despite serious failures, not achieve maximum
throughput under optimal conditions.  They may be useful for other
purposes, if the problems above are addressed.  But a simple virtual circuit
network (a la Tymnet) behaves better than a simple datagram network (a la
Internet) given the same bandwidth.


				John Nagle