Implementing a user level multimedia transport protocol in Java

Implementing a User Level Multimedia Transport Protocol in Java

L. Apvrille†*‡ , L. Dairaine†, L. Rojas†‡ , P. Sénac†, M. Diaz ‡ † * ‡ ENSICA, Alcatel Space Industries LAAS-CNRS 1, Place Emile Blouin, 26, av J.F. Champollion, 7, avenue du colonel Roche 31056 Toulouse Cedex 5, France BP 1187 31077 Toulouse Cedex 4, France {apvrille, dairaine, rojas, 31037 Toulouse Cedex, [email protected] senac}@ensica.fr France Abstract The paper assesses the potential of Java for developing both portable and efficient communication software. Specifically, this paper presents and compares implementation of a multimedia transport protocol, POC, using the Java and C languages. Performances measurement are applied to the transport of MPEG streams.

1. Introduction The evolution of distributed multimedia applications has stimulated research work on a new generation of Internet protocols. New approaches to end-to-end protocols have been highly debated. For example, Application Level Framing architecture [3], and Partially Ordered and reliable transport Connection [1]. After being specified and validated either by model checking or prototyping, these concepts and mechanisms must be confronted with implementation and performance issues. This implementation and test step can be carried out in any of today's popular languages, such as C, C++ or Java. In the context of network software, platform heterogeneity is a key aspect, and new networking software has a chance to be deployed only if efficient implementations are proposed for a wide range of system architectures. Protocol design and deployment cost can be prohibitive in C or C++, conversely the Java language [6], because it helps develop portable code that interoperates on heterogeneous platforms, offers a clear advantage over the others. Development of networking software in Java will allow deploying this software on any platform where Java is available, without any additional adaptation work. This property is mainly due to Java’s generic virtual machine as a running environment. But C or C++ are low-level system languages able to produce highly optimized code

for target systems. This characteristic is crucial for lowlevel software such as drivers, in-kernel mechanisms, etc. Therefore, experiments have to be carried out to evaluate the exact contribution of Java for designing efficient platform independent multimedia transport protocols. Considering the implementation of multimedia transport protocol in user space, this paper presents and compares the performance offered to a video on demand application by POC, a multimedia transport protocol, implemented both in Java and C. The paper is organized as follows. In section 2, the Java language and its related multimedia and communication support is presented. A comparative study of Java and C are presented with respect to the main mechanisms necessary to build transport protocols. The rest of the paper is dedicated to the comparison of a C and Java implementation of the POC protocol. Section 3 illustrates the main concepts related to the POC protocols. Section 4 presents the implementation of POC, explaining particularities of the C and Java versions. In Section 5, the performance of the two POC implementations are studied under various environmental conditions. Finally, section 6 concludes the paper.

2. Java for Multimedia Communications Java has been designed with multimedia applications in mind. Thus from the start, Java offers support for multithreading, synchronization, sound performing and animations. Recent additional Java modules, e.g. JMF [15], further increase the multimedia orientation of Java. Because multimedia and networking are closely related, JMF also provides protocols for media communication. The Java language offers numerous interesting networking features. First, the Java language offers a good portability between platforms. Java’s portability is particularly important when developing protocols that intend to be used on many platforms, including active network

gateways. Secondly, Java comes with a rich set of networking libraries (the java.net package). Java also ni cludes some additional network standard extensions: object distribution (RMI), Real Time Protocol RTP [11] (in JMF). Other Java technologies just like the Jini [14] connection technology, a high level distributed middleware, contribute to making Java a powerful networkoriented language. C network modules can easily be integrated into operating systems' kernels. But Java does not offer such facilities, which unfortunately restricts Java network applications to the user level. As a consequence, this paper concentrates on Java language performance for transport protocols integrated in usre space. A transport protocol is a end-to-end protocol allowing an application to send or receive data via a specific Application Programming Interface (API). The implementation of such a protocol requires a set of specific computing needs, that is, Buffer Management, Raw Processing, I/O System Calls, and an API. Because protocols need high performance, the use of Java, said to be a slow language, for designing protocols is far from evident [7]. The first Java Virtual Machine strategy was to interpret compiled Java code (the Java bytecode). This procedure being slow, Just-In-Time compilers now transform the bytecode into native code just before its execution. Recent work on this native code optimization has improved Java’s speed [13]. Figure 1 depicts the results obtained in C and in Java over the main identified transport protocol computing needs. Both C and Java implementations were run on a Solaris UltraSparc 10 station. The C code was compiled using the gcc compiler (O3 option) and the Java code was compiled using the standard jdk1.2.2 compiler (O option).

Figure 1. Performance comparison of C and Java over transport protocol computing needs

Figure 1-a depicts the results obtained for the copies of memory blocks (1024 bytes). The memory area was copied 10000 times to another buffer. The C implementation appears to be 2 times faster than the JIT-compiled Java version and 3 times faster than the interpreted Java code. Figure 1-(b) shows a performance comparison between C and Java for computing the same simplified CRC16, and computed over 50 Packets of 1024 bytes.

Performances in C and compiled Java are close but the interpreter remains 3 times slower. Protocols are also composed of system calls, and as the Java’s system calls are bound to the native operating system’s calls, the resulting performances should allow Java transport protocol programming to be efficient enough. Figure 1-(c) presents C versus Java performances obtained after 100000 UDP packets (of 1024 bytes) written over a 1OO base T Ethernet network. Data transfer performances are similar when using a Java compiled code or a interpreted one. The C implementation performs slightly better. As a result, Java performances are not as good as C ones. Buffer management appears to be slower when using the Java language. But other performances appear to be quite close to C ones. This study demonstrates that, by reducing memory transfer, Java should be efficient enough for implementing a user level multimedia transport protocol.

3. POC, a Multimedia Transport Protocol Distributed multimedia applications, and in particular those involving real-time constraints, impose new communication requirements that remain difficult to satisfy by means of traditional transport protocols. In response to this problem, an approach consists in creating new mechanisms to be more compliant with the requirements of distributed multimedia applications [3]. For achieving this goal, it is necessary to tailor the communication system to the application’s needs. A reliable Partial Order Connection (POC) conforms to this approach [1][4]. The POC service [4] supports the notion of QoS, which is characterized by two parameters: the order and the reliability of the Transport Protocol Data Units (TDPUs) over the partial order connection. The first dimension of service S ranges from no order to total order, defining a set of authorized sequences. The second dimension ra nges from no reliability to total reliability defining subsets of application data (embedded in TPDUs) that must be delivered by the service. The specification of such a protocol can be efficiently and compactly obtained with the help of the Time Stream Petri Net (TSPN) model [12], an extension of classical Petri Networks. As a case study, POC’s service has been instantiated for the transport and delivery of MPEG video flow [2]. We have defined a service that offers the best compromise between continuity and reliability. The MPEG video stream structure is organized as a succession of three types of data: (1) Intra frames, (2) Predicted frames and (3) Bi-directional frames. This flow structure allows the definition of partial ordering and reliability relations at frame and block level [9].

Given the MPEG standards [2], the specification of a POC transport service for the transport of MPEG video is realized in two phases. The first step is dedicated to the definition of Transport Service Data Units (TSDUs), and the second one relates to the specification of the POC service with the help of the TSPN formalism. As a result, we obtained a TSPN of 180 places and 12 typed transitions for a classical MPEG video flow. The details of this work are outside the scope of this paper (see [9] [10]).

4. POC implementation in Java The architecture of the protocol is essentially based on three functional modules: (1) Synchronization, (2) Error Recovery and (3) Congestion Control [8] [10]. The Synchronization module determines how objects can be consistently delivered to the application, the Error Recovery module checks for losses packets and retransmits them if necessary, and Finally, the Congestion Control module monitors losses and determines the quantity of TPDUs that must be dropped consistently with the observed network QoS, while respecting the prenegotiated transport service. The implementation runs in user space and relies on “POSIX threads 1c” API provided by Solaris 2.5.1. POC is built over UDP/IP with the help of TLI (Transport Layer Interface). Java implementation of the POC protocol relies on the second version of the Java language and can therefore run only on Java 2 platforms. The Software architecture is illustrated in Figure 2. The sender entity During the connection establishment phase, a user specifies his required QoS. Then, the sending entity performs the following tasks during data transfer: (1) user

data packetization, (2) packet (re)transmission, and (3) acknowledgments reception and synchronization. These tasks are respectively achieved by three threads: the main thread, the transmission thread and the retransmission thread. The receiver entity As for the sending entity, the user application first provides the required QoS. The receiver entity performs (1) packets reception and generation of acknowledgments, and (2) control of delivery. The delivery entity is controlled by the receiver application which asks for packets. This task is performed by the main thread. On the other hand, the receiving thread performs the packet reception and acknowledgment generation. Both sender and receiver sides use two developed packages: pocspn and pocnet. The first refers to the TSPN management; the second concerns the protocol communication management. The pocspn package is surrounded by a dotted line in Figure 2. The remaining modules refer to the pocnet package. The pocspn package The pocspn package manages the TSPN. For all packets processed, the TSPN is consulted in order to take the best decision according to TSPN specification. The package has been implemented with extensibility and reusability in mind, but has not been fully optimized. A simple interface allows the user to easily define the TSPN that specifies the needed QoS for the transport of a given multimedia stream. Once the TSPN engine has been initialized, a set of methods helps the user to decide what to do with any event such as reception or sending of packet. For exa mple, on the receiver side, each packet received from the

Figure 2. Software Architecture of POC Java

network is announced to the TSPN engine. Then, the TSPN engine decides what the user has to do with the packet, i.e., memorize it, trash it, or present it to the application. In this later case, a number of packets previously memorized into the TSPN engine can be delivered to application. The protocol mechanisms can be easily extended (e.g., providing services that help the congestion and flow control process to decide which TPDU can be sent in regard to the reliability and order specification) by adding methods to the pocspn classes. Moreover, the addition of a new dimension such time in the decision process can be implemented by adding new classes to the TSPN core.

protocol for multimedia applications. Both packages appear to be highly reusable and easy-to-use. Performance study of these developments will be achieved in the next part of the paper.

5. Performance Study In comparing the respective performances of the POC C and Java implementations, the goal of these performance measures is to highlight the benefits and limits of a Java approach for a POC service in terms of blocking times, viewing quality, and error recovery.

5.1.

Evaluation platform

The pocnet package The pocnet package contains the five threads implementation (i.e., three threads of the sending part and two threads of the receiving entity). The pocspn package is used through a simple API. Pocnet package could easily work with other packages whose API would be similar. This leads us to assert that we have developed a generic protocol package. For example, TCP/IP programming would be possible with our pocnet package by adding a tcpip package instead of the pocspn package. As a consequence, the receiver side uses only five pocspn’s methods. Each time the receiving thread gets a packet from the network, the thread simply specifies the packet to the pocspn module by using the pktReceived method; this thread then checks for packets to be deleted from the buffer (isPktToDelete and getNextPktToDelete). This thread also unlocks the main thread if there are packets to deliver (isPktToDeliver). The main thread delivers the data obtained from the pocspn package to the application using the getNextPktToDeliver method. Furthermore, centralizing all protocol data (packets and feedback from the network) in one class (POCData.class), facilitates adding additional functionalities to the protocol, for example a congestion control mechanism. Therefore, new functionalities must be m iplemented in a new class that uses a reference to all protocol data (the protocol’s POCData object). The POC API The POC API is designed to be similar to UDP’s API. Thus, we have defined the POCSocket class and the POCPacket class. Once a POCSocket is created, the user can invoke the send and receive methods on the socket respectively to send or receive a POCPacket. A POCPacket is used to transmit or receive user data to the POC layer. The TSPN, port numbers, host identities and buffer pools size are given in arguments when instantiating the POCSocket. As a result of this implementation, we have programmed two independent packages that both constitute a

The functional architecture of the evaluation platform is based on four subsystems: sender, receiver, transport protocol (POC/UDP/IP), and network. An MPEG video sequence is transmitted between the sender and the receiver. The packetization scheme of the MPEG stream is as described in section 3. The experiments were done over 4 platforms, SUN Solaris 2.6, Linux 2.2.9, Windows 95 and Windows NT 4 Server. On all platforms, the newest stable Java platform was used. For example, on the Solaris platform, the 1.2.2 Java version was used. All Java environments support a Just-In-Time compiler. HotSpot module was not used. The C sender runs on an Ultra Sparc 1 and the Java one on a Ultra Sparc 10. The C receiver runs on a Ultra Sparc 2. The Java receivers were experimented on a Ultra Sparc 10 (Solaris), on a PC Pentium III 500 MHz (Linux), on a PC Pentium 133 MHz (Windows 95), on a PC Pentium III 500 MHz (Windows 98) and a PC Pentium II 266 MHz (Windows NT 4/sp4). The network used is the best-effort Internet. The tests have been made in the context of a Metropolitan Area Network situated in Toulouse, France. Both the C and Java servers were placed at LAAS/CNRS, whereas clients were placed at ENSICA approximately 10 kilometers and 5 hops away. The network was always heavily loaded i.e. more than 5% of packets were lost. The C sender/receiver and the Java sender/receiver worked at the same time, exchanging the same MPEG stream, but running on different workstations. The experimental results obtained concerns two main aspects: (1) the blocking times and (2) the impact on the viewing quality.

5.2.

Blocking times

In this paragraph, we compare the difference between service continuity with POC C and POC Java. Blocking times are usually generated by both recovery of lost information and the need to observe order constraints. Indeed, in a totally ordered and totally reliable

(a)

s

RTT UDP in “C”

Time (s) (a)

RTT UDP in Java

ms

Time (s) (b)

Figure 3. Losses, inter-packet times and RTTs Solaris POC C service vs Linux Java POC

service (such as TCP), each TPDU loss or unordered reception can potentially generate blocking times, conversely a connectionless service such as UDP does not entail such blocking states, at the expense of reliability. We compared blocking times on the two POC implementation using the same MPEG stream. Figure 3 shows that blocking times occur about at the same time in Java and C, and also last as long. A blocking time can be observed each time the inter-packet time is greater than the RTT. Each other inter-packet time corresponds to a jitter inherent to every network service. Therefore, we can notice for both POC C and POC Java about 7 blocking times. In both cases, about 130 packets were lost (6.5%). So the results shows that there were few blocking times in comparison to the number of lost packets. Therefore the two POC implementations can offer a good service continuity (few blocking times) and at the same time good error recovery. Table 1 shows the average inter-packet time, as perceived by the application, for POC C on the Solaris platform compared to POC Java on the five experimental platforms. Therefore, the column “POC C” gives the average inter-packet time for POC C on the Solaris platform while the Java implementation was running on the corresponding line platform. Note that on every platforms, the mean POC Java inter-packet time is higher than the C mean inter-packet time, but still remains very close, demonstrating that POC Java doesn’t generate more significant blocking times than the C implementation.

POC Java (Various platforms) Solaris 2.6 : 0.0314 Windows 95: 0.0308 Windows 98: 0.0308 Windows NT: 0.0308 Linux: 0.0319

POC C (Solaris 2 .6) 0.0309 0.0304 0.0302 0.0314 0.0309

Table 1. Mean Inter-packet times

Furthermore, the curves depicted on Figure 4. show that the distribution of inter packet arrival durations is very close for the two implementatio ns (Figure 4-(a)). On the windows NT platform Figure 4-(b), we can notice that inter-packet durations are distributed according to regular slots. This could be due either to the clock granularity of the Windows platform or to the inaccurate Java clock system call. Other Windows (NT, 95 and 98) results were close to other platforms. It should be also noticed that the mean inter-packet time for POC Java is closer to POC C on the Windows platforms than on the UNIX platforms. This similarity could also be due to the inaccurate Java clock system call on the Windows pla tforms. As shown at the beginning of the paper, the Java language induces a delay overhead compared to C implementation in raw processing task (see Figure 2.b), but gives good results in memory management and I/O calls (Figure 2.a and 2.c). These observations lead us to study the Java overhead significance in the context of packet processing. Moreover, the Java overhead weight is also compared to memorization induced by the reliability and order management of the POC protocol. We experimented in measuring the POC layer processing time

(a) – Linux platform (POC Java)

(b) – Windows NT platform (POC Java)

Figure 4. Distribution frequency of inter-packet time

truncated because two I-slices were lost before. But POC Java has already been able to recover one of those slices. Moreover, other lost packets have been already recovered by POC, which explains that there is more degradation in the man’s face when using UDP than when using POC. The error with UDP increases in the next pictures whereas during pictures P6 and P7 POC is still able to recover lost packets. Most packets are recovered in picture P9 for POC Java whereas the P9 picture with UDP is of poor quality: many blocks and the lower part of the pictures are still missing. The picture quality is the same for UDP and POC at picture P11 as a new I slice has been received. POC

in measuring the POC layer processing time with C and Java implementations. The processing time has been evaluated in measuring for each processed packet, the end-to-end delay at network and POC level, then computing their difference. To ensure a comparable measurement between C and Java implementation, we have used the same Petri Net (i.e., the MPEG transmission scheme) on a LAN with the same errors emulation. It appeared that the difference of processing time in POC layer is not significant. The mean POC processing delay of packets that have not been buffered (no associated loss) in POC layer is less than 1ms for each of the implementations. When taking into account error recovering time, the global mean of packet delay in POC layer is around 10ms. In this last case, the mean time difference between C and Java over 2000 packets is 1.3ms, POC C being faster.

P5

P8

P11

P9

Impact on viewing quality

The video transfer was tested successively with UDP, POC C and POC Java. The experiment used an MPEG video sequence characterized by a prediction scheme with M=4, N=12 and 15 slices per picture. The size of each TDSU corresponds to the size of one picture slice. Considering pictures of 15 slices and a 25 frames per second rate, the inter TDSU period for emission is roughly 2 ms. Figure 5 shows two resulting sequences using UDP and POC Java. The POC Java MPEG stream was played on a MPEG decoder able to use limited disordered packets. This decoder is based on an extension of mpeg2play [5]. On the first picture (P5), the lower part is

UDP

5.3.

P5 200

P8 240

320

P9 360

P11 400

440

480 t (ms)

Figure 5. Error recovery at final presentation level

Figure 6. shows packets that were lost and packets that could be delivered to the application after loss detection and retransmission. Note that all I slices were retrieved on time with the POC Java implementation. This is due to their temporal validity, which is higher than for B slices for example. Only a third of the B slices were recovered on time. Most of the P slices were also recov-

ered. Therefore, recovering efficiently I slices and P slices increase the video viewing quality: POC can offer a good service continuity and at the same time a good error recovery. 70 60 50 40 30 20 10 0

[4]

[5] Lost Delivered

Header

I Slice

P Slice

[6]

B Slice

Figure 6. Lost and delivered packets (Java POC)

ceedings ACM SIGCOMM, September 1990, Philadelphia. Diaz M., A. Lozes, C. Chassot, P. Amer, “Partial order connections : a new concept for high speed and multimedia services and protocols”, Annals of Telecommunications, 49, n° 5-6, 1994, pp. 270-281. Eckart S., mpeg2play version 1.1b, MPEG Software Simulation Group; ftp.netcom.com/pub/cfogg/mpeg2, July 13, 1994 Gosling J., McGilton H., “The Java Language Environment: a White Paper”, Sun Microsystems Inc., 1995. http://java.sun.com/whitePaper/java-

whitepaper-1.html [7]

6. Concluding Remarks

Krupczak B., Calvert K.L., Ammar M., “Implementing Protocols in Java: The Price of Portability”, In proceedings INFOCOM, March-April 1998, San Francisco, USA Rojas L., Dairaine L., Senac P., M. Diaz, “Error Recovery Mechanisms Based on Retransmissions for Video Coded with Motion Compensation Techniques”, IEEE Packet Video Workshop (PV99), New York, U.S.A, April 1999. Rojas-Cardenas L., Dairaine L., Senac P., Diaz M., “An adaptive transport service for multimedia streams”, IEEE Multimedia Systems, Florence Italy, Jun 1999. Rojas-Cardenas L., Senac P., Dairaine L., Diaz M., “Temporal Partial Order and Partial Reliability Service for Distributed Multimedia Applications”, 5th International conference on Multimedia Modelling (MMM'98), Lausanne, Switzerland, Octobre 1998. Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., " RTP: A Transport Protocol for Real-Time Applications ", RFC 1889, January 1996. Senac P., Diaz M., de Saqui-Sannes P., Leger A., “Modeling Logical and Temporal Synchronization in Hypermedia Systems”, IEEE JSAC , special issue on multimedia synchronization, vol. 14, nº 1, page 84-103, Jan. 1996. Sun Microsystems Inc., HotSpot: “The Java HotSpot virtual machine architecture”, http://java.sun.com/products/hotspot/whitepaper.html Sun Microsystems Inc., Jini: “The JINI connection overview”, http://java.sun.com/jini/overview Sun Microsystems Inc., JMF: “The JMF API”, http://java.sun.com/products/javamedia/jmf/index.html

In this paper, we argue that Java infrastructure performances are able to provide an efficient support for endto-end protocol implementation. To demonstrate this assertion, we compared Java and C performances for designing a real multimedia transport protocol, that is a Partial Order Protocol. Measurements demonstrate that, although C performs better than Java, Java performances are still acceptable for giving efficient support to the targeted video on demand applications. Indeed, implementation of this protocol has been tested over several platforms. The performances of those implementations have been confronted to C implementation running on an Solaris environment. We implemented a test platform with an MPEG video server system. The obtained results demonstrate that both performances were similar. Therefore, we conclude that implementing a transport protocol at user-level is almost as efficient with Java than with C. Future work will be dedicated to add additional modules to the Java POC implementation, which according to its object structure can be easily extended. Thus, we aim to combine our implementation with the Java Multimedia Framework to offer additional functionalities. We also aim to improve our POC Java implementation with congestion control mechanisms and with time related resource management techniques. We plan also to evaluate the POC approach with other network links (e.g., satellite links) and with other media (H.263, HTML, … ).

[8]

7. References

8. Acknowledgments

[1]

Authors would like to thank M. Pierre de SaquiSannes (ENSICA, France) and M. Paul Ame r (Univ. of Delaware, USA) for their help in the writing of the paper.

[2]

[3]

Amer P.D., C. Chassot, T. Connolly, M. Diaz, P. Conrad, “Partial Order Transport Service for Multimedia and Other Applications ”, IEEE Transactions on Networking, Vol 2, N°5, Oct 1994, 440-456 CCITT, “CCITT Recommendation MPEG-1, Coded Representation of Picture”, Audio and Multimedia/Hypermedia Information, ISO/IEC 111172 Geneva Switzerland, 1993 Clark D.D. and Tenenhouse D.L., “Architectural considerations for a new generation of protocols”, In proceedings ACM SIGCOMM, September 1990, Philadel-

View publication stats

[9]

[10]

[11]

[12]

[13] [14] [15]