Adaptive Multimedia Protocol Stacks

Fixed end-system protocols are unable to support the wide range of applications requirements on top of current networks without adding overhead in the form of unnecessary functionality for multiple combinations of application requirements and networks. The RWANDA (Real-time Wide Area Network Dissemination Architecture) paradigm dynamically configures multimedia protocol stacks to support a wide range of application requirements and to increase performance. 

Recent developments in data communications are dominated by advances in high-speed networking and distributed multimedia applications. Multimedia applications increase the set of requirements in terms of throughput, end-to-end delay, delay jitter, synchronisation. These needs may not all be directly met by the networks; end system protocols enrich network services to provide the quality of service (QoS) required by applications. Obviously, fixed end-system protocols are not able to support the the wide range of application requirements on top of current networks (ranging from modems up to gigabit networks) without adding overhead in form of unnecessary functionality for multiple combinations of application requirements and networks. 

There are several factors that explore alternatives to traditional monolithic structures. The most obvious of these are ease of prototyping, debugging, and maintenance. Two more interesting factors are: 

• The co-existence of multiple protocols that provide materially differing services, and the clear advantages of easy addition and extensibility by separating their implementations into self-contained units.

• The ability to exploit appliation-specific knowledge for improving the performance of a particular communication protocol such as in our case with Multimedia.

Application needs have driven the creation of numerous protocols. The need for an efficient transport for distributed systems was a factor in the development of request/response protocols in lieu of existing byte-stream protocols such as TCP [2]. Experience with specialised protocols shows that they achieve remarkably low latencies. However these protocols do not always the highest throughput [3]. In systems that need to support both throughput-intensive and latency-critical applications, it is realistic to expect bth types of protocols to co-exist. 

We expect the trend towards multiple protocols to continue in the future due to at least three factors. 

• Emerging communication modes such as graphics and video, and access patterns such as request-response, bulk transfer, and real-time, will require transport services which may have differing characteristics. Further, the needs of integration require that these transports co-exist on one system.

• Future uses of workstation clusters as message passing multicomputers will undoubtedly influence protocol design: efficient implementations of this and other programming paradigms will drive the development of new transport protocols.

• As newer networks with different speed and error characteristics are deployed, protocol requirements will change. For example higher speed, low error links may favour forward error correction and rate-based flow control over more traditional protocols [7]. If different network links exist at a single site, multiple protocols may need to co-exist.

In addition to using special purpose protocols for different application areas, further performance advantages may be gained by exploiting application-specific knowledge to fine tune a particular instance of a protocol. Watson and Mamrak have observed conflicts between application-level and transport-level abstractions that lead to performance compromise [1]. One solution to this is to ‘partially evaluate’ a general purpose protocol with respect to a particular application. In this approach based on application requirements, a specialised variant of a standard protocol is used rather than the standard protocol. A different application would use a slightly different variant of the same protocol. The notion of specialising a transport protocol to the needs of a particular application has been the motivation behind may recent system designs. 

The Aim of the RWANDA paradigm is to improve this situation by configuring end-system protocols to cater for the differing media within multimedia. Configuration serves to support a wide range of application requirements and to increase protocol performance by decreasing protocol complexity. 
 

Application Requirements  

The traditional relation between service user and service provider is a simple contract. Service using applications specify their requirements by a target value or target range [4] for QoS parameters. Service providers offer QoS in a best-effort manner such as OSI TP4 or in a guaranteed manner such as ST-II, or reject the service request. Multiple renegotiations might be performed to find a satisfying and supported QoS. 

From our point of view, this fixed negotitation scheme is not appropriate for complex multimedia requirements. Generally, applications have only a very limited knowledge on available resources, network services, and end system load, and they may change drastically [5]. Furthermore, applications want to attain more than one (possibly contradicting) objective such as high performance and low costs. New QoS definitions in [6] and [7] introduce some flexibility for the service provider. 

Design Overview  

This section describes our design at a high level. In our design, protocol functionality is provided to an application by two interacting components – a protocol library that is linked into the application and a network I/O module that is co-located with the network device driver. Figure 1 shows the overall view of our design and the interaction between the components. 
 
 

The library contains the code that implements the communication protocol. For instance, typical protocol functions such as retransmission, flow control, checksumming etc., are located in the library. Given the timeout and retransmission mechanisms of reliable transport protocols, the library is multithreaded. Applications may link to more than one protocol library at a time. For example, an application using TCP will typically link to the TCP, IP and ARP libraries. 
 

Performance  

All the measurements are conducted on the Windows 95 platform on 200MHz Pentium PC’s with 32mb connected to a 10 Mb/sec Ethernet. We used the Sun VM and version 1.1.5 of the JDK. In our first test, we hope to prove that RWANDA provides a transport system which outperforms CORBA when it comes to passing objects to remote servers. As CORBA has no pass-by-value mechanism, the object must be wrapped, serialised and transmitted. The CORBA ORB that we used for measurements was VisiBroker for Java 3.2 [8]. 

Distributed multimedia applications require high bandwidth of data – which is typically transferred in large arrays of byte, integer or double. We measure the performance of data transfer for the byte array and integer array categories. For the measurements, we used two methods that take an int array and a byte array. The buffer size for Sun’s JIT was 1024. RWANDA utilises Java’s built Serialisation API for the larger Video datagrams, however we achieved greater performance by cloning the smaller audio datagrams and sending them over the wire. 
 

 

 

 
Figure 2 and Figure 3 show the results of byte array and int array transfers respectively. For Byte array transfer, VisiBroker peaked at 3.4 MB/Sec. RWANDA showed very high data transfer rate, finally saturating at 5.3 MB/Sec. For Int array transfer, the data transfer rate of VisiBroker was not varying, especially for small byte array size. This means that the operations were CPU bound and the cost of byte reordering and data copy was expensive. 

RWANDA is closely modelled on the iBus framework [9], supporting event-driven applications on top of group communication protocols which implement a quality-of-service framework allowing programmers to compose protocol stacks for unreliable communication, reliable multicast, message encryption, and so forth. This provides a framework where applications need only pay for quality of services they need. RWANDA recognises the differing media characteristics and transport requirements within multimedia and provides run-time composable protocol stacks. This delays the necessity for defining protocols until the latest possible stage allowing adaptability to network conditions. Channels allow for large scale decoupling of clients and servers – a necessary feature for large scale systems - also allowing heterogeneous receivers with differing capabilities to receive information. 
 

References  

[1] Watson R. and Mamrak, S. Gaining Efficiency in Transport Services by Appropriate Design and Implementation Choices, ACM Transactions on 
Computer Systems, vol. 5, pp. 97-120, May 1987. 

[2] Clark, D., Lambert, M., Zhang, L., NETBLT: A bulk data transfer protocol, RFC 998, Mar 1997 

 [3] Tobe, Y., Chou, S., QoS Control for Continuous Media Communications, pg 471-81, INET’92, Apr 1992 

 [4] Jung, J., Seret, D., Translation of QoS parameters into ATM performance parameters in B-ISDN, Proc IEEE INFOCOMM’93, pg 748-55, Mar 1993 

[5] Ferrari, D., Client Requirements For Real-Time Communication Services, IEEE Communications, 65-72, Nov 1990 

 [6] Campbell, A., Coulson, G, Gracia, F., Integrated Quality Of Service For Multimedia Communications, Proc. IEEE INFOCOMM’93, pg 732-39, Mar 1993 

 [7] Danthine, A., Bonaventure, O., From Best-Effort to Enhanced QoS, RACE 2060, CEC Deliverable No R2060/Ulg/CIO/DS/P/004/bl, Jul 1993 

 [8] VisiBroker 3.2 for Java. Visigenic Corporation. Http//www.visigenic.com, 1998 

 [9] Maffeis, Silvano. iBus - The Java Intranet Software Bus, http://www.olsen.ch/~maffeis/, 1997. 

Task