Multimedia blends two or more media together, such as text, graphics, sound, or movies. The Internet, home to multimedia for quite some time, has been stymied by the transmission requirements of multimedia partnerships. Indeed, audio and video often require several megabytes to work in tandem, thus taking a great deal of time to transmit. For this reason, their availability has been sharply limited for most users.
Multimedia works best as an interactive endeavor, but for the most part, Internet multimedia is not interactive; it’s click and wait. The intertwining of multimedia and the Internet makes sense. People prefer multimedia on their desktops. It’s engaging, entertaining, and makes otherwise complex systems a little easier to use and understand.
Traditionally, much of the information sent over the Internet has a specific destination, such as an email message sent to a specific colleague. A request for a Web page is transmitted to a single host, and the host sends back the requested information to the single recipient. Although computers can handle a substantial number of these requests every second, the information is basically one-to-one: One computer sending the information and only one receiving it. This arrangement seems fine until we wish to send information simultaneously to more than one person. IP multicast supports this type of transmission efficiently by enabling sources to send a single copy of a message to multiple recipients who explicitly want to receive the information [7]. This is far more efficient than requiring the source to send an individual copy of a message to each requester (point-to-point unicast), in which case the number of receivers is limited by the bandwidth available to the sender. It is also more efficient than broadcasting one copy of the message to all nodes (broadcast) on the network, since many nodes may not want the message, and because broadcasts are limited to a single subnet.
IP multicast is an extension to the standard IP network-level protocol. IP multicasting is the transmission of an IP datagram to a host group, a set of 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. The membership of a host group is dynamic; hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group. A host may be a member of more than one group. In addition, at the application level, a single group address may have multiple data streams on different port numbers, on different sockets, in one or more applications. Multiple applications may share a single group address on a host.
An isochronous application must include some time-critical element such as a media stream, that is, a continuous stream of bits with strict time dependencies between those bits. Streamed applications are essentially one-way flows of information such as broadcast or on-demand video and audio services. Isochronous Internet applications have quality of service (QOS) requirements that must be considered on an end-to-end basis [10]. In taking that perspective, end-system and network capabilities are equally important in delivering the QOS support required at the application layer. For media requiring timely guarantees, application designers are primarily concerned with temporal properties such as delay, jitter, bandwidth, synchronization, and reliability properties such as error-free delivery, ordered delivery, and fairness.
Audio quality is highly sensitive to jitter, and the watchability of video is sensitive to available bandwidth. For lip synchronization, audio and video streams need to be synchronized to within 80100ms for skew to be imperceptible [4]. Interpretation of the delivered information is left to human perception; because humans are far more tolerant than computers, lost packets are likely to be perceived merely as a temporary quality reduction. Nevertheless, packet loss is a significant problem for isochronous interactions. For example, since a typical packet size is generally above the threshold for audible loss (~20ms), the loss of a single audio packet can be irritable to the receiver. Resource reservation protocols are an attempt to resolve these difficulties by allocating resources prior to communication.
An object is a programming abstraction that encapsulates data and behavior. Distributed objects are accessed over networks where the location of the object need not be important to its users. Objects with their natural combination of data and behavior and strict separation of interface from implementation, make a neat, useful package for distributing data and processes to end-user applications. In a distributed object environment, application development and management are simplified because clients do not need to know which languages objects are implemented in, what hardware or operating system they run on, and so forth. The fundamental idea behind interoperable objects is to cross existing boundaries between operating systems, address spaces, machines, and languages. A technology that crosses the machine boundary must also locate the server object, establish communication with it, set up the request, and send it off, then wait for results and return them to the application.
Multimedia is composed of varying types such as audio, video, text, control information, and so on. A multitude of formats exists within these types, such as JPEG, MPEG, among others. Take the example of a conference application, where control information, and files need to be transmitted alongside audio and video. The control information such as who has floor control, and files need reliable transport guarantees, whereas the audio and video may be transmitted with a differing QOS. Using an identical protocol stack to cater for all these transport types is not an ideal scenario.
Traditional transport protocols move the media types through the same stack. If a video file is filtered through the same stack as an audio file, the video data will have to adopt the packet size allocated to the audio file. In general, audio runs more efficiently with smaller packet sizes. Isochronous multimedia traffic can tolerate some loss, however, data that misses its expected delivery time is of no use. Therefore, it is more efficient to lose smaller packets than larger packets. However, smaller packets demand increased header processing in routers. Small packet sizes are not optimal for graphical data. A more efficient method would construct optimized protocol stacks for each of the media to adapt to network conditions, for example, mobile networks.
CORBA: Built on an Asynchronous Foundation
The Object Management Group (OMG) is a consortium of hardware, software, and end-user companies formed to create the CORBA architecture [6]. CORBA specifies the architecture of an Object Request Broker (ORB) regulating interoperability between objects and applications. The CORBA specification does not address implementation details and leaves many areas undefined. Unfortunately, this omission has resulted in proprietary technologies used by the various CORBA vendors [1].
It is not our intention to degrade the CORBA standard as we believe it to be the strongest fit for many real-world applications. However, the CORBA model is lacking for the class of systems requiring timely guarantees [2]. It is based fundamentally on a blocked synchronous RPC model [8], rather than an asynchronous Message-Oriented Middleware (MOM) model, which hinders the creation of real-time systems. Most real-time CORBA systems are currently implemented on UDP/IP connectionless protocols, acting as a plumbing approach to the upper layers structured on top of the CORBA protocol.
One may build real-time requests using one-way CORBA operations. However, some CORBA implementations execute subsequent one-way operations in a LIFO fashion [8]. These implementations required yet another sequencing protocol and introduced considerable jitter into the video stream, confirming the notion that applying the CORBA request/reply model is not appropriate for streaming time-dependent data transfer. CORBA calls are not asynchronous in reality. The CORBA specification even permits the ORB to block while sending a one-way call and many of the leading ORB vendors have implemented their one-way calls in a blocked manner [9]. Such behavior is highly undesirable when high-speed video is to be transmitted and displayed.
The RWANDA Protocol
The RWANDA protocol caters to large-scale isochronous wide-area multimedia applications. RWANDA is based on our ideal of an transport protocol for dissemination-oriented communication providing a basic service that supports multicast streams, with incremental extensions and specialization’s to support conversational and request-response communication as part of the same base protocol mechanism.
RWANDA overcomes the blocked synchronous foundation by providing a synchronous foundation; the generic protocol stack limitations by providing a tailored dynamically composed transport protocol; and the unicast limitations by providing a multicast communications model.
Java was chosen as the implementation language primarily due to its platform independence as we are dealing with a heterogeneous environment. Java’s extensive networking facilities, ease of use, and automated garbage collection aid system development. Java also allows the construction of a system without platform-specific extension libraries such as dynamic link libraries that must be in place before communication can occur using CORBA.
The protocol elements (objects) are illustrated in Figure 1. Channels are a multicast medium into which sender applications push objects, and to which receiver applications can subscribe to receive those objects. A channel maps into an IP multicast group or a point-to-point UDP connection. URLs are used for naming channels. These are denoted by URLs such as Videoplayer://227.34.3.63.
Senders push Java objects via one or more channels. To transmit a posting, the push operation is invoked with the appropriate URL and posting. The object is transmitted by IP multicast or unicast depending on if the URL denotes a multicast address. Push communication is in one direction from Sender to Receiver and nonblocking.
Receivers subscribe to channels to receive Java objects such as audio/video postings. Receivers may also explicitly request data from a receiver by issuing the pull operation. However, pull is two-way and blocking, analogous to RPC.
All data to be pushed/pulled via a channel is encapsulated into a posting object. These are serialized Java objects sent through channels. The sender serializes an object by traversing its references to other objects in the object graph recursively to create a complete serialized representation of the graph. At the receiver, the object graph is deserialized and reconstructed enabling user defined objects to be communicated without requiring marshaling code.
Filters extract different media types creating suitable runtime protocol stacks to enable streamlined transport communication to be invoked. Filters are responsible for reassembling the flows at the receiver.
A comparison could be made with the CORBA Event Service which is simply a parameter in a standard CORBA-method invocation, with options available for multicasting and buffering message parameters. The programmer wanting to use this service is still faced with the problem of how to locate events of interest, how to advertise new kinds of events, how to match patterns of events, and how to create and maintain networks of event channels to perform matching. Thus, the CORBA Event Service provides only a small subset of the capabilities needed in an Internet-scale event observation and notification facility.
RWANDA builds upon the iBus framework [5] with an asynchronous foundation suitable for supporting isochronous applications. iBus is a software bus that supports intranet applications such as content delivery systems, groupware, fault-tolerant clientserver systems, and multimedia applications.
Dynamically Composable QOS Stacks
Central to providing an adaptable QOS is the ability to maintain multiple protocol stacks. A protocol stack consists of a linear list of protocol objects and represents a QOS such as reliable delivery, virtual synchrony [2], or encrypted communication. The framework provides the services necessary for supporting new communication protocols and qualities of service. RWANDA consists of a set of Java classes for representing URLs, protocol stacks, the API framework, and posting objects. Dynamically composable protocol stacks overcome the limitations imposed by generic protocol stacks. A dynamically composable protocol stack allows optimization for particular traffic.
Reflection in Java 1.1 refers to the ability of Java classes to reflect “look inside themselves” [3]. The java.lang.Class class has been greatly enhanced in Java 1.1. It includes methods that return the fields, methods, and constructors defined by a class. These items are returned as objects of type Field, Method, and Constructor, respectively. These new classes are part of the new java.lang.reflect package, and they each provide methods to obtain complete information about the field, method, or constructor they represent.
For example, we used the Method object that has methods to query the name, the parameter types, and the return type of the method it represents to allow us to inspect the members of each protocol stack class to inspect whether it supported a relevant protocol profile that was optimal for the current network conditions.
If upon introspection of a particular protocol class at runtime, we found for example, that it contained methods to implement a pricing strategy to be used in conjunction with a resource reservation protocol stack class, then using the invoke() method that allows the represented method to be invoked, and the Constructor class which defines a newInstance() method that creates a new object, we invoked the represented constructor on it. It is through the reflection API that RWANDA achieves the dynamic reconfigurable facilities to cater for varying network conditions.
RWANDA Removes the Server Bottleneck
A request-reply model is where each interested party separately polls the source for updates. This can lead to the sender becoming a bottleneck. The RWANDA protocol overcomes this by the use of channels. Here the receiver is decoupled from the sender. The central abstraction is a set of communication channels into which sender applications push objects, and to which listener applications subscribe to receive/pull those objects. The framework is responsible for transmitting objects over the network to the subscribed listeners. With increasing scale, dissemination actually saves bandwidth because it eliminates the flood of duplicate requests and responses when multiple clients all request the same information. A channel maps into an IP multicast group [7] or into a point-to-point UDP connection. Multicast communication is predominant since it offers higher flexibility, allowing applications to be relocated from one machine to another and to distribute data from one sender to many receivers efficiently also catering for fast and slow receivers. URLs are used for naming channels.
Distinct media formats deserve distinct transportation treatment. RWANDA filters the data depending on the source data stream, for example, audio (microphone), video (camcorder) or text (file transfer) and composes one of a library of protocol stacks suitable for transmission of the media as illustrated in Figure 2.
The result is separate streams from the same application are multicast to the same IP group address, and filters recompose the streams into an integrated application. Protocol stacks can be compiled as late as runtime depending on the need for readaptability. There is a noticeable cost for stack reconfiguration but it is a reasonable overhead if it can be amortized over multiple subsequent data exchanges. Standard recognized objects are audio, video, or text objects. These can be expanded to include more objects and specialized media types within these groups.
RWANDA will provide a reconfigurable plug-and-play network-protocol architecture intended for adaptive applications. The architecture revolves around the notion of a protocol stack contructed from modules that can be stacked and restacked in a variety of ways to meet the communication demands of its applications. RWANDA’s protocols implement basic sliding window protocols, fragmentation and reassembly, flow-control, encryption, and message ordering, among others. Runtime protocol stacks are created according to the QOS string specified in the constructor. To transmit a posting over the network, the void push (iBusURL url, Posting p) operation is used. The URL denotes the channel on which the posting object will be transmitted by IP multicast or unicast, depending on whether the URL denotes a multicast address or not. Push is in one direction from the sender to the listeners, and nonblocking.
Measurement Methodology
In our design, protocol functionality is provided to an application by two interacting components—a protocol library linked into the application and a network I/O module co-located with the network device driver. The library contains the classes that implement the communication protocols. For instance, typical protocol functions such as retransmission, flow control, check-summing, among others, are located in the library. Given the timeout and retransmission mechanisms of reliable transport protocols, the classes typically would be multithreaded. Applications may link to more than one library at a time. For example, an application using TCP will typically link to the TCP, IP, and ARP libraries.
All the measurements are conducted on the Windows95 platform on 200MHz Pentium PCs with 32MB connected to a 10MB/s Ethernet. We used the Sun VM and version 1.1.5 of the JDK. The CORBA ORB used for measurements was VisiBroker for Java 3.2 [12]. We obtained our measurements from a collaboration application.
The primary performance metric for a byte-stream protocol such as UDP is throughput. Throughput was measured between the prototype collaboration applications running on otherwise idle workstations and unloaded networks. We report the performance for several different user-level packet sizes as network efficiency improves with increased packetsize up to the maximum on the link and user packet sizes beyond the link-imposed maximum will require multiple network packet transmissions for each packet. This effect influences overall performance depending on the relative locations of the application, the protocol implementation, the device driver, and the relative costs of switching among these locations. Table 1 shows that RWANDA outperforms the VisiBroker implementation.
We compared the latency characteristics with the CORBA version. The average round-trip time for the exchange with various data sizes is shown in Table 2. As the table indicates, RWANDA shows a significant gain over CORBA.
RWANDA’s Adaptability
One of RWANDA’s main strengths lies in its ability to dynamically create protocol stacks. The power that Java brings to RWANDA is the ability to dynamically invoke objects on remote servers of which the server has no prior knowledge. This is achieved by Java’s pass-by-value mechanism allowing the objects contents to be serialized and transported to the server and invoked within the servers of Java virtual machine. CORBA can only pass by reference. There is a RFP in progress at the moment. To obtain the pass-by-value timings for the CORBA implementation, we had to use smart proxies and convert the objects to strings, serialize and transmit across the ORB where the strings must be converted into object references, and the same procedure repeated for the result.
Figure 3 displays the results from Test 2 which dynamically reconfigures the protocol stacks through reflective methods in an attempt to provide optimal conditions. We compare the basic IP multicast stack (no scheduling) to a FIFO scheduler. In each case, we have six clients, three of them requiring three seconds of processing every t seconds, and the other three requiring six seconds of processing every t seconds. We adjust t to change the targeted CPU utilization. Initial tests have shown that FIFO scheduling performs the best. Basic IP multicast actually outperforms FIFO at lower CPU utilization’s since enough capacity is available. However, performance of the basic IP multicast stack deteriorates as conditions increase. This is an area where we hope to dynamically adapt the protocol stacks to provide for optimal scheduling policies so we achieve the optimal configuration of Figure 4.
Conclusion
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, and synchronization. These needs may not all be directly met by the networks; end-system protocols enrich network services to provide the QOS required by applications. Obviously, fixed end-system protocols are not able to support 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.
The aim of the RWANDA paradigm is to provide configurable 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.
RWANDA is closely modeled on the iBus framework, supporting event-driven applications on top of group communication protocols that implement a QOS 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 the QOS they need. RWANDA recognizes the differing media characteristics and transport requirements within multimedia and provides runtime 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.
To validate our claims about RWANDA, we evaluated the performance of primitive object operations such as object array transfer, remote method calls and data transfer of bytes and integers. We found RWANDA to outperform VisiBroker on all tests. We found the simplicity of buffer management is very important for high-performance network computing.
Figures
Figure 2. Filtering of isochronous media streams.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment