# Multicast Papers Appeared in 1988

Mustaque Ahamad, Mostafa A. Ammar, Jose M. Bernabeu-Auban, and M. Yousef Khalidi, "Using Multicast Communication to Locate Resources in a LAN-Based Distributed System," in IEEE Conference on Local Computer Networks, (Minneapolis, Minn.), pp. 193-203, IEEE Computer Society, Oct. 1988.

Abstract: In this paper we present a resource (e.g., file, process) located scheme which exploits the multicast communication capability of local area networks. In the scheme, the universe of resource names is partitioned into a relatively small number of groups and each group is assigned a unique address. Nodes storing the locations of resources belonging to a particular group instruct their network interfaces to receive all location messages sent to the group address. To locate a resource, a node first determines the address of the group to which the resource belongs (this can be accomplished via a well-known hash function), and a multicast messages is then sent to the address. The algorithm performance is studied by means of simulation, and approximate closed form solutions are derived for systems operating at heavy and low loads. The scheme's performance is compared with that of broadcast, and it is shown that the proposed scheme performs much better than broadcast alone.

Bharat Bhargava, Enrique Mafla, John Riedl, and Bradely Sauder, "Implementation and Measurements of an Efficient Communication Facility for Distributed Database Systems," Technical Report CSD-TR-783, Department of Computer Science, Purdue University, West Lafayette, IN 47907-2004, June 1988.

Abstract: This research presents our experimentation with several methods of providing efficient communication facilities for distributed database systems. These studies give insight into the delays incurred by applications running on distributed systems. We have implemented, compared, and analyzed five different mechanisms for local interprocess communication (two variations with message queues, named pipes, shared memory, and UDP sockets). The most efficient of these is three times as fast as UDP for 1000 byte messages. We implemented and measured the performance of kernel-level software multicast and hardware multicast. The results show the significant advantage of using these techniques instead of using multiple sends and receives at the user level. Finally, we present the design of a facility that allows the dynamic addition of user-level protocols such as two phase commit, clock synchronization, etc. to an operating system kernel. The facility is based on a simple stack-based language that provides the functionality and security required. This tool makes available to the user the best of two worlds. It provides the efficiency of kernel-resident code with the flexibility and safety of user-level programming. [Ed: To appear in Proc. 5th IEEE Data Engineering Conf.]

G. Chesson and L. Green, "XTP-Protocol Engine VLSI for Real-Time LANs," in Proc. EFOC/LAN 88, (Amsterdam), pp. 435-438, IGI Europe, June 1988.

Abstract: Future needs for low latency internet and transport services for real-time LANs can be met by a lightweight protocol, eXpress Transfer Protocol (XTP). XTP is a connection-oriented protocol providing real-time datagram service, flow, rate, and error control, multiple addressing schemes, and reliable multicast service in an internet environment. XTP is scalable to 1 Gbps with available technology.
Keywords: Transport protocol; real time; LAN; high speed

D. Cheriton, "VMTP: versatile message transaction protocol: Protocol specification," Request for Comments (Experimental) RFC 1045, Internet Engineering Task Force, Feb. 1988.

Abstract: This memo specifies the Versatile Message Transaction Protocol (VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC). The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level. Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required. Examples of such simple clients and servers include PROM network bootload programs, network boot servers, data sensors and simple controllers, to mention but a few examples. This RFC describes a protocol proposed as a standard for the Internet community.

J. Crowcroft and K. Paliwoda, "A multicast transport protocol," in SIGCOMM Symposium on Communications Architectures and Protocols, (Stanford, California), pp. 247-256, ACM, Aug. 1988. also in \em Computer Communication Review 18 (4), Aug. 1988.

Abstract: This paper presents the design of a reliable multicast transport protocol. The aim of the protocol is to provide a service equivalent to a sequence of reliable sequential unicasts between a client and a number of servers, whilst using the broadcast nature of some networks to reduce both the number of packets transmitted and the overall time needed to collect replies. The service interface of the protocol offers several types of service, ranging from the collection of a single reply from any one of a set of servers to the collection of all replies from all known servers. The messages may be of effectively arbitrary size, and the number of servers may be quite large. To support this service over real networks, special flow control mechanisms are used to avoid multiple replies overrunning the client. Reliable delivery is ensured using timeout and a distributed acknowlegement scheme. The protocol is implemented over a network layer which supports multicast destination addressing and packet delivery. The behavior of the protocol over both LANs and LANs interconnected by WAN lines is discussed. We also include some notions for possible future support from network interface hardware.
Keywords: distributed systems; multicast; transport protocol

S. Deering, "Host extensions for IP multicasting," RFC 1054, Internet Engineering Task Force, May 1988. (Obsoletes RFC0988).

Abstract: This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. IP multicasting is the transmission of an IP datagram to a "host group", a set hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams. It is proposed as a standard for IP multicasting in the Internet. This specification is a major revision of RFC-988.

Stephen E. Deering, "Multicast routing in internetworks and extended LANs," in SIGCOMM Symposium on Communications Architectures and Protocols, (Stanford, California), pp. 55-64, ACM, Aug. 1988. also in \em Computer Communication Review 18 (4), Aug. 1988 and as Report STAN-CS-88-1214, Department of Computer Science, Stanford, California.

Abstract: Multicasting is used within local-area networks to make distributed applications more robust and more efficient. The growing need to distribute applications across multiple, interconnected networks, and the increasing availability of high-performance, high-capacity switching nodes and networks, lead us to consider providing LAN-style multicasting across an internetwork. In this paper, we propose extensions to two common internetwork routing algorithms - distance vector routing and link-state routing - to support low-delay datagram multicasting. We also suggest modifications to the single-spanning-tree routing algorithm, commonly used by link-layer bridges, to reduce the costs of multicasting in large extended LANs. Finally, we show how different link-layer and network-layer multicast routing algorithms can be combined hierarchically to support multicasting across large, heterogeneous internetworks.
Keywords: multicast; routing; IP; network layer; bridging; LAN

S. Deering, C. Partridge, and D. Waitzman, "Distance vector multicast routing protocol," Request for Comments (Experimental) RFC 1075, Internet Engineering Task Force, Nov. 1988.

Abstract: This RFC describes a distance-vector-style routing protocol for routing multicast datagrams through an internet. It is derived from the Routing Information Protocol (RIP), and implements multicasting as described in RFC-1054. This is an experimental protocol, and its implementation is not recommended at this time.

H. Garcia-Molina, B. Kogan, and N. Lynch, "Reliable Broadcast in Networks with Nonprogrammable Servers," in International Conference on Distributed Computing Systems, pp. 428-438, June 1988.

Abstract: The problem of implementing reliable broadcast in ARPA-like computer networks is studied. The environment is characterized by the absence of any multicast facility on the communications subnetwork level. Thus, broadcast protocol has to be implemented directly on hosts. A reliable broadcast protocol is presented and evaluated by several important performance criteria.
Keywords: reliable broadcast; multicast; transport protocol

Larry Hughes, "LAN gateway design for multicast communication," in IEEE Conference on Local Computer Networks, (Minneapolis, Minnesota), pp. 82-91, IEEE, Oct. 1988.

Abstract: Low cost local area networks and the growing interest in distributed systems have resulted in the development of applications which require one-to-many or multicast communications. Many of the issues relating to intranetwork multicast communications are fairly well understood - as illustrated by the increasing number of applications that use multicast communication. However, internetwork multicast communication can lead to problems not normally encountered in an intranetwork multicast communication such as where remote identifiers are maintained, identifying the intended gateways, and minimizing the number of transmissions. In this paper we consider these and other problems associated with two different types of multicast gateway implementations. We then present a hybrid multicast gateway that is designed to overcome a number of the limitations imposed by internetwork multicast communication.
Keywords: multicast; gateway

B. Leiner, "Critical issues in high bandwidth networking," RFC 1077, Internet Engineering Task Force, Nov. 1988.

Annotation: RPC is not suitable as a general communications programming paradigm as it forces the programmer to avoid certain common programming constructs (such as fully generalised pointers and global variables). It is not always clear who is the client and who is the server in programs, especially those used under OSes such as UNIX which allow pipes of commands to be set up. RPC is an inherently two party interaction and so does not easily allow for the use of multicast. When a server crashes whilst processing an RPC call, the client is sometimes left hanging forever or times out. In the first case the extra fault tolerence that a distributed system can afford us is not used and in the second case the RPC call will generate an exception which a local procedure call never would thus voiding the programming transparency once more. Nonidempotent operations performed via RPC are dangerous as it is impossible to make a general exactly once execution'' RPC operation. If a client crashes, the server becomes an orphan which can be difficult to dispose of and can leave locks on resources if killed. In RPC there is a lack of parallelism as when the server is active, the client is idle. With RPC it is impossible to stream data between the processes so that if, for example, a server can start to work with a few parameters, it is forced to wait until it has gotten all of them. Non-transparent communications systems may be better in many circumstances than transparent ones such as RPC.