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''?