TOWARDS NEW TRANSPORT SERVICES TO SUPPORT DISTRIBUTED MULTIMEDIA APPLICATIONS Gordon Blair, Geoff Coulson, Francisco García, David Hutchison and Doug Shepherd Computing Department Lancaster University Lancaster LA1 4YR, UK E.mail:
[email protected] ABSTRACT
This paper describes the contribution of Lancaster University to the definition of new transport services for supporting distributed multimedia applications. The paper first reports on a set of requirements that we have identified from a comprehensive applications survey. It goes on to describe the design and implementation of an experimental multimedia support infrastructure which attempts to meet these requirements. This infrastructure consists of a distributed systems platform built on top of a continuous media transport service and protocol. It includes a new set of services, called orchestration services, which are designed to assist with the synchronisation requirements of multimedia applications. 1. REQUIREMENTS FOR COMMUNICATIONS PROTOCOL SUPPORT Lancaster University is involved in two related projects which together are working towards the design and implementation of a communications and distributed systems support architecture for multimedia applications. The Multimedia Network Interface (MNI) project has built a distributed multimedia workstation system which enables the development of experimental communications protocols and a distributed systems platform [Ball 90], [Blair 90], [Scott 91]. The ESPRIT OSI 95 project aims to specify a new transport service and protocol to meet the needs of new applications in the high speed multiservice network environment. Part of this project has concentrated on surveying possible distributed multimedia application domains to determine requirements for OSI protocols. This complements the work of some other partners who are considering the impact of new communications techniques, particularly ATM/B-ISDN. The overall strategy is illustrated in Figure 1. Multimedia applications ( data, image, audio, video); Open Distributed Processing
7 6 5 4 3 2 1 High speed networks Broadband ISDN, FDDI, etc.
Requirements Analysis
Specification and Design
High Performance Transport Protocols
Network Services
Figure 1: OSI 95 Overview
In proceedings of 4th IEEE COMSOC International Workshop on Multimedia Communications: Multimedia '92, April 1-4th 1992.
1.1 State of the art in applications In total, the OSI 95 survey of applications covered over 100 projects including European projects funded by ESPRIT, RACE, DELTA and AIM, as well as other projects in Europe and the United States. Many new areas of application are made possible with the emergence of multimedia, including office automation, service industry applications, retail applications, domestic applications, science and engineering and cultural activities. The topic of Computer Supported Cooperative Work (CSCW) is also highlighted as an important development with implications for distributed multimedia technology. The overall balance of projects is shown in Figure 2 [Williams,92]. Documentation Systems Office Requirements Education Finance Medical Publishing Travel Real-Estate Domestic Science and Engineering Cultural Multimedia CSCW
Figure 2: Areas of Application for Distributed Multimedia Computing 1.2 Characteristics required of a new transport protocol From the OSI 95 survey, it is possible to identify a number of important issues which will have an impact on future work in transport services and protocols. The major requirements arising from these issues are detailed below:General •ּsupport for a variety of services - It is important for the communications infrastructure to support a number of styles of service. The following are seen as particularly important for multimedia: efficient transactions (i.e. remote procedure calls) and high throughput streams. In multimedia systems, transactions are often used for control data whereas streams are used for continuous media (CM) traffic. •ּprofile selection - The concept of selecting a profile through the protocol stack is likely to be important in multimedia. Given the varying demands on a protocol stack by multimedia traffic, it is important to be able to select the appropriate path through the stack to provide a given service. •ּend to end argument - In multimedia, it is not sufficient to guarantee the transmission of information between two endpoints. It is also important that the operating system can provide appropriate response. Hence, QoS issues such as throughput, latency and real-time responsiveness are end to end concerns as well as concerns of the communications infrastructure. This makes the relationship between the operating system and the communications infrastructure particularly important in distributed multimedia systems. Quality of Service (QoS) •ּQoS parameterisation - QoS is one of the most important issues in multimedia. The requirements of different media types vary greatly (e.g. voice and video). Similarly, a particular media type can be transmitted with a variety of characteristics (e.g. monochrome or full colour image). It is therefore important to support a notion of QoS whereby the precise characteristics of a transmission can be established. Again, this applies to both transactions and streams. Important QoS parameters for transactions
are the semantics of the transaction (at most once, at least once, etc) and the style of synchronisation (synchronous or asynchronous). Important QoS parameters for streams include throughput, error rates, latency and jitter. •ּQoS negotiation and re-negotiation - It is important that QoS parameters can be negotiated, i.e. it should be possible to interactively determine the QoS depending on the current state of the network, the volume of traffic, etc. Similarly, because of the dynamic nature of communications systems, it is also important to support renegotiation of the parameters, e.g. to reduce latency as more bandwidth becomes available. •ּreal-time responsiveness - The real-time responsiveness of the communications system is particularly important for multimedia. i.e. the timeliness of delivery. This can actually be considered as a QoS issue but is worth highlighting in its own right. Responsiveness is important for transactions as real-time control environments demand guarantees of the temporal behaviour of control messages. This is also likely to be an important feature for control in multimedia environments. Similarly, timeliness is an important issue for stream services as media types such as audio and video require that the temporal structure of the information should be retained. Orchestration •ּmultimedia synchronisation - There is a well known need in multimedia to support continuous synchronisation across a number of streams, e.g. lip-sync between audio and video. In order to achieve this level of synchronisation, it is necessary to have a management entity monitoring the performance of underlying protocols and responding to exceptions or changes in the network. This introduces the notion of an orchestrator which oversees a number of stream connections. Note that orchestration requires the ability to respond to exceptions such as the temporary loss of synchronisation. This strengthens the argument above to support dynamic renegotiation of QoS parameters. Groups and multicast support • groups and multicast support - The applications study highlights the importance of multicast services for multimedia. For example, many CSCW applications require sophisticated patterns of connectivity between different sites. Note that multicast is important for both transactions and streams. All of these points will have a significant impact on the OSI seven layer model, in general, and on the transport service and protocol in particular. The issues presented above will be used in the next phase of OSI 95 to help identify precise requirements for a transport service and protocol called TPX that will support the new environment. The work described in section 2 below is feeding useful practical information into the OSI 95 project. It is intended that TPX will be introduced into discussions on the ISO New Work Item on Enhanced Transport Mechanisms. It should be stressed that the experimental transport protocol at Lancaster is being used as a vehicle to test our ideas, particularly on QoS provision and orchestration, and is distinct from TPX itself. 1.3 Other studies/proposals A number of other projects have examined the requirements imposed by multimedia on transport services, most notably an ANSI X3S3 report [ANSI,91]. We believe that the list presented above subsumes all the issues raised in the ANSI report. Within the EC RACE programme, project R.1071 [RACE,91] categorises the applications into a number of service domains. More recently, ANSI X3S3.3 has produced proposals for a new High Speed Transport Service (HSTS) and Protocol (HSTP), and these will be further studied in OSI 95. A preliminary assessment indicates that these proposals may complement the proposal for orchestration services contained in this paper.
2. EXPERIMENTAL DISTRIBUTED MULTIMEDIA ARCHITECTURE It is the intention of the Lancaster research to derive generalized QoS parameters for multimedia applications. These parameters will not only take into account the requirements outlined in the previous section, but we also intend to use them to adjust the functionality of the communications subsystem and hence support varying application requirements. We picture communications subsystems of the future to be composed of vertical and horizontal subdivisions in a protocol matrix. QoS parameters will then be employed to select a vertical path through the matrix that provides the necessary functionality to support a particular application, ie. a functional profile. The idea would be to cater for the whole of the applications end-to-end requirements throughout the whole of the protocol stack. This should be done in such a way that duplication of functionality through the various protocol layers will be avoided. To summarize, what we propose is a QoS-driven communications subsystem. The architecture of the experimental distributed multimedia system is shown in Figure 3. Distributed multimedia applications view an object-based distributed application platform, known as the base services platform [Coulson,91]. The platform isolates applications from the complexities of multimedia devices and continuous media communications by providing high level run-time services which applications can dynamically bind to and access. The platform runs over an experimental distributed infrastructure consisting of multimedia workstations and a real-time high-speed network emulator. The multimedia workstations are, in fact, standard UNIX or PC machines augmented with a transputer based multimedia network interface (MNI) unit which attaches to standard workstations and provides the hardware support for the entire software infrastructure [Scott,91]. DISTRIBUTED MULTIMEDIA APPLICATIONS
Application Platform
DISTRIBUTED SYSTEM SUPPORT ORCHESTRATION SERVICES
Transport Sub-system
RATE-BASED FLOW CONTROL PROTOCOLS MULTISERVICE NETWORKS
Figure 3: Lancaster multimedia architecture The purpose of the orchestration services is to provide synchronisation support for continuous media applications. Support is provided for continuous synchronisation as mentioned above, and also for the real-time association of actions with events such as the presentation of a particular frame in a video play-out. We apply the term event-based synchronisation to these sorts of situation. The orchestration services are visible in the application platform, but much of the mechanism of orchestration is carried out in close association with the rate-based transport protocol. The various components in this architecture are described in the following sub-sections. 2.1 Distributed system support The Lancaster base services platform [Coulson,91] forms the application programmers interface to the transport and orchestration mechanisms to be described. It uses the facilities of the object-based ANSA architecture [ANSA,89] to implement a set of generic base objects which encapsulate the services provided by the lower layers, and consist principally of three types of object: devices, streams and synchronisation managers. These are seen by the higher layers as object-oriented services with abstract data type interfaces, but they encapsulate the control and transmission of continuous media. In addition, to enable multi-party communication, interfaces may be grouped either to allow the multicasting of continuous media data, or to allow invocation of a number of interfaces at one time [ANSA,90]. We now
describe the platform object types in more detail. Devices Devices are an abstraction of physical devices, pieces of stored continuous media, or software processes. Video windows are also modelled as device objects. Devices may be either sinks, sources or transformers of continuous media data. Examples of transformers are processes which perform compression or data format conversion. Devices present the following pair of interfaces:•
a generic control or Chain interface. A piece of continuous media may be visualised as a chain comprising a sequence of links, each of which represents an atomic unit particular to the media type in question (for example a frame of video).
•
a device dependent interface. The device dependent interface contains operations specific to the device. For example, cameras have operations such as pan and tilt.
The Chain interface is common to all continuous media devices. It contains operations to selectively set up the device to produce or consume continuous media data, and to actually switch the information flow on and off. Sequences of stored media do not have a device dependent interface for control, only a Chain interface and hence are often referred to simply as Chains. A virtual pointer moves through the Chain as it is played or recorded, and this pointer may be located and moved using additional operations available in the Chain interface. Using the Chain interface, clients of a device may create an endpoint interface on the device. This interface abstracts over all aspects of a device which are concerned with the transport of continuous media data (essentially it presents a pair of operations, get_link and put_link through which links can be read or written). Streams Streams are services which are used to connect devices together via their endpoint interfaces. They are abstractions of continuous media transmissions which map down on to an underlying transport protocol. The Stream interface contains operations which allow the client of a Stream service to connect and disconnect endpoint interfaces. Streams support M:N connections, i.e. they allow M sources to be connected to N sinks. This is modelled by allowing endpoint interfaces to be grouped together. Endpoint interfaces may be dynamically added to or removed from these groups. Synchronisation Managers Synchronisation managers offer a service to which all application synchronisation requirements may be delegated. Requirements for event-driven synchronisation are expressed as an interpreted script which specifies actions to be taken on the basis of events generated by base service objects such as devices or streams. Continuous synchronisation is specified according to parameters such as the packet ratio between the related streams, the tightness of synchronisation required, and permissible actions to take to regain lost synchronisation (such as packet discard, increased throughput etc.). The synchronisation manager makes use the orchestrator services described below to implement continuous synchronisation. 2.2 Orchestration services Orchestration is introduced into the architecture to provide support for the multimedia synchronisation requirement identified in section 1.2. Focussing on the continuous synchronisation problem, the following functionality must be provided by the infrastructure to ensure that media flowing in separate but related connections can be correctly co-ordinated in time [Campbell,92]:i) the ability to start related continuous media data flows precisely together. If the relationship is not correctly initiated, there is no possibility of maintaining a correct temporal relationship. ii) the ability to start and stop the flow of continuous media information on sets of related connections together in real-time. iii) the ability to create related connections with compatible QoS. This is so that the connections will maintain a compatible temporal transmission rate in the required ratio.
iv) the ability to monitor the on-going temporal relationship between related connections, and to regulate the connections to perform fine grained corrections if synchronisation is being lost. It is almost inevitable that related connections will eventually drift out of synchronisation due to such factors as the potentially long duration of continuous media connections in typical applications, the inevitable discrepancies between remote clock rates, and temporary 'glitches' occuring in individual connections. Sync. Manager OSI ULA
HLO
HLO
Key: HLOHigh level Orchestrator
LLO
LLO
LLO Low level
OSI 1-4
Orchestrator
ULA OSI Upper
protocol stacks Single node
Layer Architecture
Single node
Figure 4: Three level orchestration architecture Our orchestration design is illustrated in Figure 4. The synchronisation manager provides the view of orchestration seen by users of the base services platform. The view presented is of an abstract data type service interface which contains orchestration related named operations. Applications pass Stream interfaces to these operations and the synchronisation manager arranges to have the required continuous synchronisation performed by the lower layers according to a policy which is also specified by the application. Policies include constraints on how 'strict' the continuous synchronisation should be and actions to take on failure.
1
2 Interval
3
Regulate.indication
Regulate.request
Regulate.indication
Regulate.request
Regulate.request
Regulate.indication
High Level Orchestrator
Low Level Orchestrator 4 5 6 7 8 9 10 Interval
11
12
Interval
TIME LINE
Figure 5: Interaction between HLO and LLO
Regulate.request
Below the platform level, the remaining two orchestration components are responsible for realising the behaviour and policy required by the synchronisation manager. At this level, the orchestration process is realised as high level orchestrator (HLO) objects which monitor and regulate multiple transport connections via a low level orchestrator (LLO) interface in a continuous feedback loop. For each orchestrated group of connections, there is a single HLO instance, and a separate LLO instance runs on all source and sink nodes of all the orchestrated connections. The HLO and the multiple LLO instances interact with each other via Orchestrator PDUs, on out of band connections (actually the HLO only interacts with a single LLO per connection). These out of band connections must have guaranteed bandwidth to support the necessary real-time communication of orchestration primitives.
Figure 5 illustrates the interaction between the HLO and an LLO instance. The HLO supplies the LLO with rate targets for each orchestrated connection over specified intervals. These targets ensure that each orchestrated connection runs at the required rate, relative to a reference clock, for the required synchronisation relationship between the orchestrated connections to be maintained. The LLO attempts to meet the required rate target over each interval for each connection, and reports back at the end of the interval on its actual success or failure. Then, on the basis of these reports, the HLO sets new targets for the next interval which compensate for any relative variation in speed among the orchestrated connections. The LLO operates on a best effort principle; it is the responsibility of the HLO to take appropriate action (e.g. set new targets or re-negotiate the connection QoS) if the LLO consistently fails to meet targets. The LLO orchestration interface consists of two sets of primitives. The first set operates over a grouping of transport connections and provide the ability to atomically prime, start and stop the flow of data in these connections both atomically and instantaneously. The prime primitive is worthy of special mention. This is used to pre-fill the receivers' buffers so that a subsequent start can take effect immediately (with minimal latency). The second set of primitives operate on single transport connections in an orchestrated grouping. They enable the controlling HLO to set and monitor the above mentioned flow rate targets. Primitives are also provided to report back to the HLO agent on the actual performance achieved at the end of each interval. Further details of the design and implementation of the orchestration system are provided in [Campbell,92]. 2.3 Transport protocol design and implementation Traditional transport protocols such as OSI TP4 and TCP were designed to work over an older generation of communications infrastructures which did not provide high-speed and multiservice capabilities. These protocols tend to be complex in both design and implementation and thus limited in their throughput capabilities [Clark,90], [Zhang,86]. Although it has been demonstrated that it is possible to produce efficient implementations which are able to handle high throughputs [Zitterbart,91], such protocols still lack the support for many of the requirements of emerging distributed multimedia applications. More recently, new protocols have been developed to handle high throughputs and exploit the resilience of the underlying high-speed networks, but again these do not meet the demands of distributed multimedia applications. Due to these factors, it is now becoming widely recognised that new, standardised transport protocols will be required in the new environment [Hehmann,91], [Jain,90a], [Netravali,90], [Wolfinger,91]. We therefore decided to design and implement an experimental transport service and protocol specifically for the support of continuous media. Although the transport service is new, we have made every effort to use existing standardised conventions and terminology wherever possible. The service offers connection-oriented services on the basis that the best way to support continuous media is by enforcing QoS guarantees not only end-to-end, but on a hop-by-hop basis (for example traversing across an internet). The service offers peer-to-peer, peer-tomultipeer, and multipeer-to-peer connection-oriented options. Connection Establishment and Release Connection establishment is a fully confirmed service similar in nature to that employed in the OSI reference model. Full option negotiation of QoS is performed on connection, and in keeping with the requirements for CM connections, the negotiated QoS represents the required characteristics of the media in one direction only, from source to sink (see Table 1).
Primitives T-Connect.request T-Connect.indication T-Connect.response T-Connect.confirm T-Disconnect.request T-Disconnect.indication
Parameters initiator-address, src-address, dest-address, protocol, class-of-service, QoS-tolerance-levels, CID " " " initiator-address, CID initiator-address, CID, reason
Table 1: Connection establishment and release primitives and their associated parameters. Notification of QoS Degradation If the class of service selected from the transport protocol for a particular connection incorporates the error indication facility, a primitive is required to convey to the transport user any errors or QoS degradations which may have occurred. This primitive is generated by the transport entity monitoring the connection over a suitable sample period. The primitive and its parameters are set out in Table 2. The primitive will identify the connection, provide the negotiated QoS tolerance levels, the sample period, the measured performance of the negotiated QoS tolerance levels within that sample period, and an error number to identify which of the tolerance levels have suffered degradation. Primitive T-QoS.indication
Parameters initiator-address, src-address, dest-address, initial-QoS-tolerance-levels, sample-period, CID, current-QoS-tolerance-levels, error-number
Table 2: Primitive issued by transport service to notify transport user of degradation of negotiated QoS. QoS Re-negotiation For QoS re-negotiation, a fully confirmed service with full option negotiation similar to that used for connection establishment is employed. The primitive is detailed in Table 3. The time sequence diagram in figure 5 above is also applicable to the T-Renegotiate service. Primitives T-Renegotiate.request T-Renegotiate.indication T-Renegotiate.response T-Renegotiate.confirm
Parameters initiator-address, src-address, dest-address, new-QoS-tolerance-levels, CID " " "
Table 3: Primitives employed for the re-negotiation of QoS. The primitives may be initiated by a transport protocol user, or by the transport protocol itself. The transport protocol may need to tear down a connection and open a new one in order to supply the required QoS. Thus it should be capable of sustaining state so that it can resynchronise once the new connection is established. If for some reason a modified service cannot be provided, the service request will be rejected with a T-Disconnect.request, and the transport user will receive a T-Disconnect.indication. However, in this latter case, the existing connection is not torn down; the T-Disconnect.indication simply indicates that the new service level requested can not be supported. Note that the T-Renegotiate service allows the QoS of a connection to be modified but not its protocol type or class of service. Data Transfer The transfer of information is flow controlled by sending timed bursts at regular rates on the basis of burst rates negotiated between the sender and receiver. This ratebased scheme has been used in a number of other transport protocols in recent years [Cheriton,86], [Chesson,89], [Clark,87]. It is believed that most errors in transmission over the high-speed multiservice networks will be caused by congestion [Jain,90b]. Applying rate-
control instead of widow-based flow control as used in OSI TP4 / TCP on an end-to-end basis, provides a mechanism which controls the admission of data onto the network. If congestion occurs, this mechanism may be adjusted to deal with it (i.e. the rate of admission may be slowed down). Other interesting features of such protocols are that flow control and error control can be handled independently, and flow of data is not impeded by the error control mechanisms used. The state synchronisation point and the error recovery block becomes the burst, which is also made use of in the orchestration mechanism. Broadband networks of the future will support access control schemes: this makes rate-control transport protocols natural candidates to be employed over such networks for the handling of end-to-end issues. 3. SUMMARY This paper outlines the design of a continuous media (CM) transport service and an associated orchestration service which permits real-time co-ordination between distinct transport connections. Our transport service has simplex connections with flexible QoS configuration, including re-negotiation. Details of related work in the field of CM transport protocols may be found in [Wolfinger,91] and [Hehmann,91]. Our work is notable for the close integration of CM transport concerns with those of the distributed application platform that we consider an essential part of future systems building. An orchestration architecture is described that consists of three components: a high level orchestrator which makes HLO services available from our object-based application platform, HLO agents which control and monitor orchestrated connections, and low level orchestrators which sample and regulate the flow of CM information over intervals as directed by the HLO agent. The orchestration system is architecturally separate from the transport sub-system although the two components must be intimately related in implementation. The context of our work is that it forms part of the ESPRIT OSI 95 project. Part of the aim of this project is to develop new transport services suited to the new environment of high-speed multiservice networks and distributed multimedia applications. The ESPRIT OSI 95 project is not the only international attempt to introduce a new high-speed transport protocol: in particular, ANSI X3S3.3 has recently issued draft descriptions of a new high speed transport service (HSTS) and protocol (HSTP), which are to be studied further within OSI 95. 4. ACKNOWLEDGEMENTS This paper describes the results of work carried out within two distributed multimedia projects at Lancaster University: the Multimedia Network Interface (MNI) project is supported jointly by the UK Science and Engineering Research Council and by British Telecom Laboratories; and the OSI 95 project is a collaborative ESPRIT project funded by the European Commission. 5. REFERENCES [ANSA,89] Advanced Networked Systems Architecture, "ANSA Reference Manual, Release 01.00", Architecture Projects Management Ltd., Poseidon House, Castle Park, Cambridge CB3 0RD, UK, March 1989. [ANSA,90] Advanced Networked Systems Architecture, "A Model for Interface Groups", Architecture Projects Management Ltd., Poseidon House, Castle Park, Cambridge CB3 0RD, UK, 1990. [ANSI,91] High Speed Transport Protocol (HSTP) Specification, American National Standards Institute, X3S3.3/91-264, September 1991. [Ball 90] F. Ball, D. Hutchison, A. Scott and D. Shepherd, "A Multimedia Network Interface", Proceedings of the 3rd IEEE COMSOC International Multimedia Workshop (Multimedia’90), Bordeaux, France, Nov 1990. [Blair 90] G.S. Blair, G. Coulson, P. Dark and N. Williams, "Engineering Support for Multimedia Applications in Open Distributed Processing", Proceedings of the 3rd IEEE COMSOC International Multimedia Workshop (Multimedia’90), Bordeaux, France, Nov 1990. [Campbell,92] Campbell, A., Coulson G., Garcia F., and D. Hutchison, "A Continuous Media Transport and Orchestration Service", Internal Report, Lancaster University, December 1991. [Cheriton 86], D. R. Cheriton, "VMTP: A Transport Protocol for the Next Generation of Communication Systems", SIGCOMM'86, ACM, 1986, pp. 406-415.
[Chesson 88], G. Chesson, "XTP/PE Overview", Proceedings 13th Conference on Local Computer Networks, Minneapolis, Minnesota, 1988, pp. 292-296. [Clark 87], D. D. Clark, M. L. Lambert and L. Zhang, "NETBLT:A High Throughput Transport Protocol", Computer Communication Review, Vol. 17 (5), 1987, pp. 353-359. [Clark 90], D. D. Clark and D. L. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", Computer Communications Review, Vol. 20 (4), 1990, pp. 200-208. [Coulson,91] Coulson, G., G.S. Blair, N. Davies, and N. Williams. "Extensions to ANSA for Multimedia Computing", Internal Report ref. MPG-90-11, and submitted for publication, Lancaster University. June 1991. [Hehmann 91], D. Hehmann, R. G. Herrtwich, W. Schulz, T. Schutt and R. Steinmetz, "Implementing HeiTs: Architecture and Implementation Strategy of the Heidelberg High-Speed Transport System", Second International Workshop on Network and Operating Systems Support for Digital Audio and Video, Heidelberg, Germany, 1991. [Jain 90a], N. Jain, M. Schwartz and T. R. Bashkov, "Transport Protocol Processing at GBPS Rates.", Computer Communications Review, Vol. 20 (4), 1990, pp. 188-199. [Jain 90b], R. Jain, "Congestion Control in Computer Networks: Issues and Trends", IEEE Network Magazine, Vol. 1990, pp. 24-30. [Netravali 90], A. N. Netravali, W. D. Roome and K. Sabnani, "Design and Implementation of a HighSpeed Transport Protocol", IEEE Transactions on Communications, Vol. 38 (11), 1990. RACE 91], RACE Project R1071: IBC Application Analysis, Research and Development in Advanced Communications Technologies in Europe, Commission of the European Communities, 200 Rue de la Loi, B-1049 Brussels, Belgium, 1991. [Scott 91] A. Scott, F. Ball, D. Hutchison and P. Lougher, "Communications Support for Multimedia Workstations", Proceedings of 3rd IEE Conference on Telecommunications (ICT'91), Edinburgh, Scotland, March 1991. [Williams 92], N. Williams and G.S. Blair, "A Distributed Multimedia Applications Study", To appear in Computer Communications, 1992. [Wolfinger 91], B. Wolfinger and M. Moran, "A Continuous Media Data Transport Service and Protocol for Real-Time Communication in High Speed Networks", Second International Workshop on Network and Operating Systems Support for Digital Audio and Video, Heidelberg, Germany, 1991. [Zhang 86], L. Zhang, "Why TCP Timers Don't Work Well", ACM SIGCOMM '86 SYMPOSIUM, Communication Architectures and Protocols, Stowe, Vermont, 1986, pp. 397-405. [Zitterbart 91], M. Zitterbart, "High-Speed Transport Components", IEEE Network Magazine, 1991, pp. 5463.
