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.
Abstract: This memo presents the results of a working group on High Bandwidth Networking. This RFC is for your information and you are encouraged to comment on the issues presented. Use of Gigabit scale networks include supercomputer imaging, Miltary C2 and sensor data distribution from space. A Gigabit Network (GN) must support these services: - Currently Provided Packet Services - Multi-Media Mail - Multi-Media Conferencing - Computer Generated Real Time Graphics - High-Speed Transaction Processing - Wide Area Distributed Database/Knowledge Base Management Systems For a stream or synchronous service a reservation system is used to set up and guarantee a constant and steady amount of bandwidth between any two subscribers. For Gigabit Backbones (GB), LAN speeds should be able to change irrespective of GB speeds and vice versa. Directory services such as those found in CCITT X.500/ISO DIS 9594 need to be provided. Usage policy is expressed by a tariff which is upheld by accounting. Routing policies are enforced by traffic controls. Trusted and secure communications on GNs is provided by authentication, integrity, confidentiality, access control, and nonrepudiation. Speeds of trunks in the next generation networks is rising faster than the speeds of the switching elements. New designs of switch are required to handle expensive but large bandwidths without the switch becoming the bottleneck. Hierarchically designed networks may be the key to managability in the next generation networks. Reliablity is needed in future networks and is achieved through the use of fault-tolerant switches, distributed control with self-correcting algorithms and the protection of network control traffic. Architecture of future networks must be divorced from the underlying transmission technology. There is a heirarchy of progressively more effective network management techniques: 1) Reactive Problem Management 2) Reactive Resource Management 3) Proactive Problem Management 4) Proactive Resource Management To prevent information overflow on human operators, the system with have to provide increasing amounts of filtering. thresholding and altering mechanisms. Expert systems capable of early fault detection, diagnosis and problem resolution will become mandatory for GNs. High level entities should have a name or logical address that identifies them independently of location. Multicast should be provided as a user level service as in RFC1054 for IP. The GN will alsmost certainly be made up from point to point fibre links that will not provide broadcast or multicast for free. Open group multicast means that any host can multicast to the group; closed group multicast means that only hosts which are members of the group may multicast to the group. Closed group multicasting is adequate for applications such as conferencing but open group multicasting is required for more client-server applications such as file and database servers. TCP places the checksum in the packet header, forcing the packet to be formed and read fully before transmission can begin. ISO TP4 is worse than TCP in that the checksum is in a variable location in the header and thus hardware implementation is made very difficult. Special purpose transport protocols can be designed for applications with more stringent requirements than generic transport protocols (such as TCP and ISO TP4) can provide. Current special purpose transport protocols include: o UDP (user datagram protocol) o RDP (reliable datagram protocol) o LDP (loader/debugger protocol) o NETBLT (high-speed block transfer protocol) o NVP (network voice protocol) o PVP (packet video protocol) New generic transport protocols such as VMTP hope to offer a wide range of service options that help remove the need to resort to special purpose protocols. New transport protocols should not be over optimised for current networks and yet must not ignore the fundamental deficiencies of current protocols. Forward Error Correction (FEC) is useful when the bandwidth/delay ratio of the physical medium is high (ie photonic transcontinental or transatlantic links). Operating systems must be refined to the level of performance required of them for use with a gigabit/sec network. Decentralised approaches to network management should be emphasised over centralised systems. Compromising the security of one part of a GN should not compromise the security of the entire network. With changes future bandwidth and computing costs and performance ratios, the trade off between user data and network control data flows needs to be re-explored. Resource requests made by an application to the network system must be in real terms desipte the fact that most operating systems attempt to present a 'virtual world' to the application level code. A protocol implementation can adapt to changes in that [lower level] service by tuning its internal mechanisms (time-outs, retransmission strategies, etc.)''. To minimise the effects of failures in future networks, the system must reconfigure itself to adapt to the new network state when a failure occurs. Small messages (that fit into one RTD such as those generated by most applications today) will require open-loop controls on flow and congestion. Large messages (those taking longer than one RTD such as voice or video streams) will require explicit resource commitment. The speed of light and queuing delays are the most critical sources of delay faces future gigabit/sec networks. Depending upon the actual (physical) size of the network, the application layer programs can expect to experience delays which differe by several orders of magnitude. The current Internet is more or less unmanagable and is having problems with network administrators using one logical subnet address to cover widely geographically dispersed LANs connected with fibre or satelite links. Routing can be based on policy (such as access rights) instead of simply minimising some 'cost' such as delay. Connectionless protocols make imposing a policy difficult and increase processing overhead, especially at gateways, as no state is kept and policy decisions must be made for every packet. Variables which can be taken into account in policy based routing include: o Classes of users (ie large, small, commerical, governmental, academic, etc), o) Classes of Service (what quality is required), o) Time varying (on or off peak transmission), o) Volume (discount and surcharges), o) Access charges (per port or bandwidth of the ports in use), o) Distance (circuit miles, as the crow flies, number of hops). A list of 'current' (as of November 1988) research efforts in the USA is given.
A. S. Tanenbaum and R. van Renesse, "A Critique of the Remote Procedure Call Paradigm," in EUTECO '88 Proceedings, Particpants Edition, (Amsterdam, Netherlands), pp. 775-783, North-Holland, 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.