J. W. Burren and S. C. Cooper, Project UNIVERSE: an Experiment in High-Speed Computer Networking. Clarendon, 1989.
Annotation: Datagrams are a disadvantage when LANs are connected together as they contribute additional processing overhead at network bridges ``In a high speed network the CPU power of the bridges is likely to be the limiting factor'' LANs provide broadcast or multicast services naturally. Satellite systems provide much the same facilities as LANs except for the fact that they have a very long transmission delay. Satellite networks are 'one-hop' (the satellite does not provide store and forward facilities) and provide broadcast facilities naturally. Monitoring of networks gathers basic information necessary to diagnose problems, implement controls, accounting or charging of network use and highly loading of the network's resources over time. ``Computer data require some means for ensuring error-free communication accross the network, but do not generally need tight constraints on packet transmission times.'' ``Voice and video data require tight constraints on transit time 'jitter', but can acccept some loss or corruption of the information during transmission.'' Characteristics routes in the Universe network were provided by the nameservers when connections to NVEs were being made so that average jitter delays and the like could be set up for voice protocols, etc. Remote terminal access requires high bit rates in bursts and low transmission delays to be acceptable. Although bulk data transfer does not need a short delay as far as the end user is concerned, long latency in the network can stil make it difficult to provide an appreciable amount of the underlying bandwidth to the user. Network management tools are hard to provide as afterthought and on high speed networks, the components providing these tools have the problem of also having to handle vast quantities of user data. Cacheing can be sometimes be used quite effectively to overcome some of the performance losses due to network delays.
D. R. Cheriton and C. L. Williamson, "VMTP as the Transport Layer for High Performance Distributed Systems," IEEE Communications Magazine, vol. 27, pp. 37-44, June 1989.
Keywords: transport protocol; VMTP
Annotation: The authors point out deficiencies in current transport protocols: performance, naming and functionality TCP on a Cray can sustain 750Mbit/s Performance is not a result of poor data throughput but instead is because current protocols are designed for streaming Streaming requires connection setup and tear down which adds considerable overhead to transaction based request-responce interaction Transaction based systems include distributed file systems, RPC mechanisms and distributed transaction processing systems Current transport protocols are prone to overflow if their windows are greater than the maximum burst size that an intermediate node can handle Naming problems in current transport protocols affect the usability of mobile hosts (such as portables and wireless links) and multi-homed hosts Functionality deficiency is treated as most important by the authors as current protocols do not address the issues of multicast, datagram service, security or priority All the functional deficiencies of current protocols will be required to be corrected in future high speed transport protocols VMTP supports communications between network visible entities via message transactions VMTP message transactions are requests send by a client to one a more servers followed by zero or more responses from the servers Datagram services are covered by VMTP by allowing no responce from a server VMTP also supports a streaming protocol so that it behaves like TCP or TP4 during file transfer, etc VMTP assumes an underlying datagram network and sends it's messages as one or more packets The VMTP packets have a fixed format to simplify processing and have the checksums in trailers at the end The VMTP header is 64 bytes long but the authors justify this by stating that in a high bandwidth environment, the simplified processing is worth the slight waste of bandwidth The VMTP header has room for a small amount of user data such as RPC parameters The data segment of the VMTP message is of variable length (from 0 bytes upwards) VMTP uses selective retransmission and rate based flow control to overcome overflow The authors give some results of using VMTP in the V Distributed System from Stanford
Peter B. Danzig, "Finite Buffers for Fast Multicast," in Proc. 1989 ACM SIGMETRICS and Performance'89: International Conference on Measurement and Modeling of Computer Systems, (Berkeley, California), pp. 108-117, ACM Press, May 1989.
Abstract: When many or all of the recipients of a multicast message respond to the multicast's sender, their responses may overflow the sender's available buffer space. Buffer overflow is a serious, known problem of broadcast-based protocols, and can be troublesome when as few as three or four recipients respond. We develop analytical models that calculate the expected number of buffer overflows that can be used to estimate the number of buffers necessary for an application. The common cure for buffer overflow requires that recipients delay their responses by some random amount of time in order to increase the minimum spacing between response messages, eliminate collisions on the network, and decrease the peak processing demand at the sender. In our table driven algorithm, the sender tries to minimize the multicast's latency, the elapsed time between its initial transmission of the multicast and its reception of the final response, given the number of times (rounds) it is willing to retransmit the multicast. It includes in the multicast the time interval over which it anticipates receiving the response, the round timeout. We demonstrate that the latency of single round multicasts exceeds the latency of multiple round multicasts. We show how recipients minimize the sender's buffer overflows by independently choosing their response times as a function of the round's timeout, sender's buffer size, and the number of other recipients.
Keywords: reliable multicast; LANs
S. Deering, "Host extensions for IP multicasting," Request for Comments (Standard) STD 5, RFC 1112, Internet Engineering Task Force, Aug. 1989. (Obsoletes RFC0988).
Abstract: This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054.
Steve Deering, "IP Multicast Extensions for 4.3BSD UNIX and related systems (Multicast 1.2 Release)," June 1989. release notes.
Keywords: multicast; Unix; Internet; IP; IGMP
A. Forcina, T. DiStefano, and E. Taormina, "A Multicast Broadband Switching Module in a Hybrid ATM Environment," in Conference Record of the International Conference on Communications (ICC), (Boston), pp. 111-0117 (4.3), IEEE, June 1989.
Keywords: multicast; ATM
Annotation: byte parallel; low/high priority traffic
J. S. Meditch and X. Jiang, "An integrated services fast packet/fast circuit switch," in Conference Record of the International Conference on Communications (ICC), (Boston, MA), pp. 104-110, June 1989.
Abstract: A new switching architecture, called the FPC switch, which uses fast packet and fast circuit switching to support integrated voice-data-video, multicasting, and virtual services, is descri-bed. The switch employs autonomous processing units with local memory to store switching information and is built around a modified Banyan network with bit-parallel lines linking its node processors. The system is synchronous and time is slotted
Keywords: Fast packet switching; circuit switching; switching network; ultistage interconnection network; Banyan network; performance evaluation; hybrid switch; bit-parallel; Banyan 2x2 networks
Larry L. Peterson, Nick C. Bucholz, and Richard D. Schlicting, "Preserving and Using Context Information in Interprocess Communication," ACM Transactions on Computer Systems, vol. 7, pp. 217-246, Aug. 1989.
Abstract: When processes in a network communicate, the message they exchange define a partial ordering of externally visible events. While the significance of this partial order in distributed computing is well understood, it has not been made an explicit part of the communication substrate upon which distributed programs are implemented. This paper describes a new interprocess communication mechanism, called Psync, that explicitly encodes this partial ordering with each message. The paper shows how Psync can be efficiently implemented on an unreliable communications network, and it demonstrates how conversations serve as an elegant foundation for ordering messages exchanged in a distributed computation and for recovering from processor failures.
Keywords: multicast; Psync; context graph; happened before; remote procedure calls; RPC