Last update at http://inet.nttam.com : Mon May 8 22:16:38 1995

Traffic Measurements in Multimedia Documents Real Time Transfer

Traffic Measurements in Multimedia Documents Real Time Transfer

Last update May 8th, 1995

Vincenzo Biondi biondi@iasi.rm.cnr.it

Carlo Gaibisso gaibisso@iasi.rm.cnr.it

Giorgio Gambosi gambosi@mat.utovrm.it

Maurizio Lancia lancia@iasi.rm.cnr.it

Maurizio Vitale vitale@iasi.rm.cnr.it


Abstract

This paper briefly reports the results of some testing activities performed on the efficiency of MPEG documents transmission in the framework of a prototype of a distributed multimedia DBMS's and in presence of real time playout requirements. Tests have been performed on both local and wide-area (Internet) IP based packet switched networks and with respect to different hardware platforms and MPEG flows. The testing aimed at evaluating the applicability of the TCP and UDP transport protocols in this context. Finally a simple prototype of a videoconferencing tool, based on the MPEG compression scheme, has been implemented and its performances have been compared with those achievable, on the same operating environments, by some widely used videoconferencing tools.


Contents

1 Introduction

2 The Prototype

3 The Testing Scenario

4 TCP Performance

5 UDP Performance

6 An MPEG Based Videoconferencing Tool

7 Conclusions and Future Works

References

Author Information


1 Introduction

This paper reports the results of some testing activities on the transmission of MPEG video documents in the framework of distributed multimedia databases and in presence of real time playout requirements.

Tests have been performed on a prototype of a distributed multimedia DBMS under development at IASI, on both local and wide area IP based packet switched networks (Internet) and with respect to different network loads.

The main goal of the testing is evaluating the applicability of the TCP and UDP transport protocols in order to satisfy real time playout requirements with respect to the transmission of MPEG compressed video streams.

We restricted our attention to MPEG, since it guarantees a better quality in video reproduction and a higher compression rate compared to other video compression schemes, such as JPEG and H.261 [2].

As it may be expected, we did not detect any kind of problem using TCP on local area networks. No substantial delivery delay has been detected and the network bandwidths resulted widely sufficient: the achievable performance, in terms of frame rate, is strictly related to the computing power of the decoder.

On the other side, on wide area networks, performances are greatly influenced by the available bandwidth. Our tests revealed that, for particularly limited bandwidth, the network capacity can be quickly saturated depending on the video streams characteristics.

With respect to the particular application considered the major drawback of TCP is represented by packet retrasmission, which results in a significant delay and overhead in bandwidth occupation, and in a consistent delay jitter in delivering image frames.

Transport protocols which do not guarantee packet delivery, such as UDP and RTP [1], could be the solution. A serious difficulty in this direction is represented by the poor capability of the MPEG decoder in recovering from packet loss situations. Up to now, our tests on UDP have been performed neglecting this aspect, revealing good improvements with respect to TCP performances.

Finally, a simple prototype of a videoconferencing tool has been implemented based on the same approaches tested in the paper and its performances have been compared with those achievable, on the same operating environments, by some widely used videoconferencing tools.



2 The Prototype

As already stated, tests have been conducted by means of a prototype of a distributed multimedia DBMS. Such a prototype is based on a client-server architecture. Multimedia documents (text, audios, still images, videos) are stored in a compressed form on different servers (notice that each workstation can behave as a multimedia information server) and are accessed in a way transparent to client applications. Documents compression is motivated, as usual, by the need of saving disk space ad of limiting the bandwidth requirement in transmissions.

Access to multimedia information is performed by querying a relational database where descriptive, alphanumeric information is linked to each multimedia item. It is to note that both this relational database and the set of multimedia items are fully integrated and transparently distributed.

The database is queried by means of standard relational calculus expressions through a suitable graphic interface. A set of icons provides information on both the type and the content of all documents in the query result. In particular, text and audio documents are identified by generic "text" and "audio" icons, while still images and videos are respectively represented by a miniature of the image itself and of a significative frame in the video (see figure 1).

Figure 1: A Query Result Visualization

Each document can then be retrieved (i.e. transmitted to the client by the storing server) by "pointing-and-clicking" on the corresponding icon, and either locally stored for deferred visualization, or decompressed and displayed in real time.

This is especially relevant for continuous data, such as audio or videostreams. In such cases, data streams are returned to the user with the same modalities of audio- and video-conferencing systems, i.e. (approximately) as soon as new chunks of information are available.

3 The Testing Scenario

Tests have been conducted both on an Ethernet technology based LAN and on a wide area network with 2Mbps and 64Kbps links, and basically consist in trasmitting MPEG compressed video stream from a producer to a consumer through the network. The producer is simply in charge of storing and transmitting the compressed stream, while the consumer decompresses and displays the video as soon as new chunks of information are available. Parameters of interest are the bandwith requirement and the achievable frame rate.

Several architectures have been considered for the consumers with different computing capabilities, ranging from 486 DX2/66, to more powerful machines such as SparcStation10 and DEC 3000/AXP, as illustrated in table 1.

Table 1: Different Considered Architectures

At the same time two different MPEG compressed video streams, with respect to the image size, the total number of frames and the particular pattern following which I, B and P-frames appears in the encoding sequence, are considered. The main characteristics of the streams are reported in tables 2 and 3.

Table 2: Characteristics of the Considered MPEG Streams

Table 3: Number and Average Size of I, P and B Frames in the Considered MPEG Streams

Values of reference for the best frame rate achievable by the consumer and the corresponding bandwidth requirement are obtained by locally (on the consumers themselves) storing, decompressing and visualizing both the considered video streams (see table 4).

Finally tests have been performed by several monitoring and simulating systems (Etherpeek, OpenView, SunNet, OpNet) and with respect to the MPEG decoder developped at the University of California at Berkeley. Obviously the decoder has been modified in order to get input data from the network interface.

Table 4: Best Achievable and Ideal Bandwidth Requiremets

4 TCP Performance

Tests have been firstly performed under limited traffic load by considering a single MPEG transmission on the network.

The reproduction frame rate achievable on the LAN, reported in table 5 for 4Kbytes sockets, are comparable with the reference values of table 4, while the bandwith occupation is increased by the overhead introduced by the protocol (i.e. packet headers and flow control mechanisms).

Due to the flow control implemented by TCP the bit rate emission of the producer is regulated by the consumer capacity in processing incoming data. Consequently, the average bandwidth occupation is dependent from the consumer computing power.

On wide area networks, as it may be expected, 2Mbps links provide approximatively the same performances, in terms of frame rate and bandwidth requirement, than those achievable on a LAN (see table 6). On the other hand, with respect to 64Kbps links, the frame rate and bandwidth requirement values are remarkably different from the reference values reported in table 4 (see table 7).

Table 5: TCP Performance on LAN

Table 6: TCP Performance on 2 Mbits Geographic Links

Table 7: TCP Performance on 64 Kbits Geographic Links

Different traffic loads on the LAN have been considered by simulating the connection to the network of several producers and consumers and investigating the maximum and the average values and the standard deviation of the access delay to the phisical medium (MAC protocol level). Such values are indicative of the network level of congestion and of the delay jitter. More in details we evaluated the effect of the multiple transmission of the flow generated by a single "Flower" MPEG stream when decoded by a DEC 3000/AXP. This choice is significative since leads to the maximum load of the network in terms of bandwidth requirement.

The results of the simulation are reported in table 8.

Table 8: Access Delay to the Physical Medium

A comparative analysis of such results and of the corresponding access delay distribution functions reveals that the bound we considered as tolerable in this context, i.e. the 90% of the Ethernet frames entering the network with a delay lower than 15 ms, is exceeded for about 7-8 simultaneous trasmissions.

Summarizing, on LAN's TCP presents good performances under medium traffic conditions. The only bottleneck can be the efficiency achievable in the decoding activity.

On the other side, on wide area networks, our tests showed that:

5 UDP Performance

Since the UDP datagram service does not implement any control mechanism on the information flow, not introducing any restriction on the emission bit rate of the producer, results in a quickly saturation of the reception buffer and consequently in a high degree of packet loss.

This observation has been taken into account by forcing the emission bit rate of each producer to be approximatively bounded by the ideal bandwidth requirements reported in table 4, compatibly with the overall available bandwidth.

Obviously the packet acquisition process running on the consumer has been provided with a suitably dimensioned buffer.

The testing activity resulted in the following observations:

Table 9: UDP Performance on LAN

Table 10: UDP Performance on 2 Mbits Geographic Links

Table 11: UDP Performance on 64 Kbits Geographic Links

Closing this section it is worth noting that with respect to the the particular testing scenario, and to the particular class of applications we considered, UDP revealed itself as a quite safe transport protocol. In fact limiting the producer bit rate emission results in a tolerable, from the MPEG decoder point of view, level of packet loss.

Figure 2: TCP traffic bandwith (bps)

Figure 3: UDP traffic bandwith (bps)

6 An MPEG Based Videoconferencing Tool

Experimental results [2] concerning some widely used videoconferencing tools, like IVS [4], NV [5] and ShowMe [6], show that a narrow bandwidth is the major restriction to videoconferencing on WAN's.

This consideration together with the results we obtained with respect to the transmissions of MPEG documents in presence of the same bandwidth restrictions, introduce the opportunity of evaluating the impact of such a coding method in the implementation of videoconferencing sessions.

With this aim we implement a simple prototype of a videoconferencing tool based on the MPEG compression scheme. The real matter at this regard has been if the bottleneck introduced by the poor efficiency of the MPEG coder (2-3 frames per second) could be balanced by the higher achievable compression rate.

The results we obtained on 64Kbps geographical links have been encouraging. A very interesting frame rate (2-3 frames per second) has been achieved with respect to those observed for IVS, NV and ShowMe (up to 2 frames per second), especially considering the corresponding limited bandwidth requirement (see figure 4). In fact improvements in terms of the achievable frame rate are still possible, depending on the availability of more efficient MPEG coders.

Figure 4: Bandwidth Requirement for the MPEG Based Videoconferencing Tool (bps)

7 Conclusion and Future Works

As anticipated in the introduction, MPEG real time transmission on a LAN resulted in high frame rates (both using TCP and UDP), with no substantially delivery delay. In the case of wide area connections, 2Mbps links provide enough bandwidth to guarantee efficient delivery, while, for the limited bandwidth offered by a 64Kbps links, UDP outperform TCP if a limited amount of lost packets is guaranteed.

At this regard it is worth noting that with respect to the particular testing scenario, and to the particular class of applications we considered, UDP revealed itself as a quite safe transport protocol. In fact limiting the emission bit rate results in a tolerable, from the MPEG decoder point of view, level of packet loss.

Anyway, it's our opinion that by accepting higher amounts of lost packets, UDP could achieve even better performances. It is our aim, in the next few months, to face this problem, perhaps by filtering the information processed by the MPEG decoder.

Concluding, in this paper we show under what conditions TCP could be a reasonable solution to real time playout requirements, testing at the same time the applicability of different transmission protocols, such as UDP.

For what concerns activities planned for the near future, it is our intention to apply protocols specifically introduced for real time transmission of multimedia broadcasting, such as ST II [3] and RTP, to the transmission of MPEG streams and to compare its performances with the ones provided by TCP, UDP.


References

[1]
H. Shulzrinne and S. Casner, "RTP: A Transport Protocol for Real-Time Applications", INTERNET DRAFT, 1993.

[2]
C. Gaibisso, G. Gambosi, M. Lancia and M. Vitale, "Multimedia Conferencing on Packet Switched Networks: Testing and Evaluation", Computer Networks for Research in Europe, Vol. 26, Suppl. 2 double issue, pagg. S139-S146, (1994).

[3]
ST-II Network Working Group, "Experimental Internet Stream Protocol", RFC 1190, 1990.

[4]
T. Turletti, "H.261 Software Codec for Videoconferencing over the Internet", research report n. 1834, INRIA, January 1993.

[5]
R. Fredericks, "NV Network Video Tool", available for anonymous FTP from ftp.park.xerox.com, 1993.

[6]
Sun, "ShowMe Documentation for ShowMe Video", SunSolutions, 1993.

Author Information


Vincenzo Biondi received a degree in Computer Engineering from University of Rome "La Sapienza" (Italy) in 1994. His research interest in distributed multimedia applications.
IASI-CNR - Viale Manzoni 30 - I 00185 Roma - Italy
Phone: +39-6-7716454 - Fax: +39-6-7716461 - E-mail: biondi@iasi.rm.cnr.it

Carlo Gaibisso received a degree in Computer Science from Pisa University (Italy) in 1986 and joined IASI-CNR in 1989. His research interest are in theoretical computer science and in distributed multimedia applications.
IASI-CNR - Viale Manzoni 30 - I 00185 Roma - Italy
Phone: +39-6-7716424 - Fax: +39-6-7716461 - E-mail: gaibisso@iasi.rm.cnr.it

Giorgio Gambosi is a Full Professor at the Department of Mathematics, University of Rome II "Tor Vergata". His research interest are in theoretical computer science and in distributed systems.
Dipartimento di Matematica - Universita' di Roma "Tor Vergata" - Via della Ricerca Scientifica - I 00133 Roma - Italy
Phone: +39-6-72594724 - Fax: +39-6-72594699 - E-mail: gambosi@mat.utovrm.it

Maurizio Lancia received a degree in Computer Engineering from University of Rome "La Sapienza" (Italy) in 1981 and joined IASI-CNR in 1983. His research interest are in distributed multimedia applications, in network management, in operating system performance evaluation and in distributed computing environments. IASI-CNR - Viale Manzoni 30 - I 00185 Roma - Italy
Phone: +39-6-7716443 - Fax: +39-6-7716461 - E-mail: lancia@iasi.rm.cnr.it

Maurizio Vitale received a degree in Telecommunications Engineering from University of Rome "La Sapienza" (Italy) in 1994. His research interest in distributed multimedia applications and in network management.
IASI-CNR - Viale Manzoni 30 - I 00185 Roma - Italy
Phone: +39-6-7716454 - Fax: +39-6-7716461 - E-mail: vitale@iasi.rm.cnr.it


Return to the Table of Contents