Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!FTP.COM!jbvb
From: jbvb@FTP.COM (James B. Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Reliable Datagram ??? Protocols
Message-ID: <9010221418.AA03839@ftp.com>
Date: 22 Oct 90 14:18:35 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jbvb@ftp.com
Organization: The Internet
Lines: 80


    apple.com!erekose@apple.com  (Erik Scheelke):
    >     Does anyone know of a reliable connectionless datagram protocol that
    >     runs on top of UDP?  Is so, is there a library out there I can get?
    
    postel@VENERA.ISI.EDU writes:
    >Hi.
    >
    >"Reliable Datagram" is an oxymoron.
    
    Very funny.  Really.  I would guess, however, that Erik is referring to a
    connectionless protocol that preserves message boundaries and guarantees
    delivery but not necessarily sequencing or non-duplication.  I'm sure such
    beasts exist somewhere.

What Jon said was the very, very condensed summary of an issue that he has
no doubt seen hashed over far too many times.  Even though I've been over
it twice as many times on the phone to customers as I've seen it discussed
here, I'll try my hand at laying it out in long form.

"Datagrams" are defined as single messages.  Sometimes you send one and you
don't expect an answer.  Sometimes you kind of hope for a reply, but the
transaction you are attempting isn't worth the overhead of setting up a
connection; if you don't get an answer, the request may have been lost, the
server may be down, or the reply may have been lost.  You don't care, there
are many servers, and your timeout handler has just sent a duplicate query
to another of them...

"Connectionless" means that there is no state at either the source or the
destination of the message.  Thus, a connectionless protocol cannot
guarantee delivery.  If the sender keeps enough state and includes enough
information in each message to guarantee delivery (e.g. some sort of
unique ID, and a timeout if the guaranteed response doesn't arrive), you
only need to add a little state to the receiver to allow sequencing and
non-duplication.  If the application must keep track because the
transport doesn't, it still looks like a connection to me...

So, every time this came up in the past, the next stage was to ask the
person looking for a "reliable connectionless protocol" or somesuch what
was really needed.  The most frequent goal has been some sort of transport
for a little machine, or a new one for which there is no networking
software yet.  The searcher doesn't want to implement all of TCP, and sees
"datagrams" as being easier, particularly on a single Ethernet.  Another
common goal has been to get very high throughput by avoiding the "excessive
overhead" of TCP, but Van Jacobsen's research has more or less laid that
one to rest.  A third one has been "preservation of message boundaries".

There are a number of 'reliable' alternatives to TCP, including NETBLT
(optimized for block transfers over lossy links), ISO TP, RDP and others.
Those I'm familiar with offer built-in functionality for preserving message
boundaries, along with varying approaches to connection establishment and
acknowlegement.  However, it does not appear that they provide enough extra
functionality, or require enough less effort to develop that they (except
for ISO TP) will ever become very widespread.

Frequently, having been made aware of the alternatives, the searcher reads
the specs and decides that he won't save anything.  Sometimes the next stage
is a complaint about excessive complexity containing the assertion "I never
see *any* packet loss between my Frobozz boxes on my FooNeT".  Whereupon
a large number of people jump down the complainer's throat, mostly network
maintainers suffering the slings and arrows of trying to make protocols
designed for 'little' nets run on 'big, bad' nets...

In summary, if you need reliability in an "internet" protocol, those "in
tune with the Tao of the Internet" assert that you need a connection, flow
control and an end-to-end data integrity check.  If all of your
transactions are guaranteed to fit in one packet, you can replace the
connection state with server idempotency.  If not, message boundaries are
best not tied to packet boundaries, lest you fall afoul of differing
MTUs and fragmentation (see RFC 1001/1002 Netbios over TCP for an example
of a header/length-based scheme).  If you leave the integrity check out,
that's your and your customers' risk, but leaving the flow control out
could get hosts ostracized by offended backbone router operators...

"Those who do not understand TCP are doomed to re-invent it..."

(??? who said that ???)

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901