Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!ucbcad!zen!ucla-cs!rutgers!mit-eddie!uw-beaver!cornell!gvax!ken
From: ken@gvax.UUCP
Newsgroups: comp.protocols.misc
Subject: Query: what transport problems do you have?
Message-ID: <925@gvax.cs.cornell.edu>
Date: Thu, 9-Jul-87 08:32:08 EDT
Article-I.D.: gvax.925
Posted: Thu Jul  9 08:32:08 1987
Date-Received: Sat, 11-Jul-87 19:42:17 EDT
Reply-To: ken@gvax.cs.cornell.edu (Ken Birman)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 25

Now that the battle of the ISO and TCP (or was it OSI and Internet?)
people seems to have died down, let me pose a question on a different
issue:  

I feel that we lack adequate protocol support for multicasting at the
transport level -- the protocol layer closest to the hardware.  Dave
Cheriton has proposed that VTMP be widely adopted to address this need.
The general point is that to make the most effective use of the hardware
multicast features we are seeing, one needs a software protocol that is
based on a multicast abstraction.

My question is this: What other transport requirements do people have
that are inadequately addressed by the current generation of transport
protocols?  I think of transport protocols as including things like UDP
XNS, TCP, X.25, etc. (all you OSI buffs: I am sure I got the layer
definition wrong, but no need to correct me; we both know what I mean).
What sort of transport mechanisms or features would be needed to
redress the requirement you face?  I am more interested by the problem
of software abstractions than of ``speed:'' we all want speed, the
problem is that you throw a lot of bandwidth away if the message transport
doesn't understand enough about your class of applications.

For example, what realtime problems do people face?  Do a lot of people need
reliable datagrams?  What sorts of situations have had people really cussing
at TCP and the other ``standards''?