Unreliable Datagrams

[Kevin D. Kissell]

Anyone who's done much in the way of networking in the last few
years accepts the utility of an "unreliable" datagram service, but I
think it's a bit excessive to assert that datagrams SHOULD be unreliable.
Putting responsibility for reliability at (or near) the top of the
protocol hierarchy was (or is) in vogue in most networking circles,
but it's not at all the kind of thing that is inherently sound or
unsound.  It's just one more design decision to be made on the basis
of the problem being solved and the tools available.

Unreliable datagram-based systems make sense where:
	1) Communications bandwidth is cheap
	2) The transmission system has a low error rate
	3) The ultimate clients have more computational cycles to spare than
	   the intermediate network nodes

If (1) is not satisfied, virtual circuit services make for more efficent
use of available bandwidth.  This is relevant chiefly if one is building a
system that works in sessions consisting of multiple messages.

If (2) is not satisfied, particularly in a multi-hop environment, the
aggregate throughput of a network can be seriously impaired by detecting,
reporting, and retransmitting errors across, say, 12 hops rather than
handling the recovery across the one link where the error occured.

I mention (3) simply because someone recently submitted the notion that
an unreliable datagram system ensures that the burden of reliability
"is spread out where there is (sic) lots of resources -- at the endpoints".
In my own experience, there are a surprising number of cases where a
microprocessor-based network node can more easily afford the overhead than 
a VAX 750 groaning under 16+ users.

Datagrams are a handy tool, and an appropriate one for UN*X IPC.  I do not
think that lack of reliability should be regarded as a virtue, however.

		Kevin D. Kissell
		Fairchild Research Center
		Advanced Processor Development
		uucp: {ihnp4 decvax}!decwrl!\
		                             >flairvax!kissell
		    {ucbvax sdcrdcf}!hplabs!/