Vincenzo Biondi email@example.com
Carlo Gaibisso firstname.lastname@example.org
Giorgio Gambosi email@example.com
Maurizio Lancia firstname.lastname@example.org
Maurizio Vitale email@example.com
2 The Prototype
3 The Testing Scenario
4 TCP Performance
5 UDP Performance
6 An MPEG Based Videoconferencing Tool
7 Conclusions and Future Works
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 .
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 , 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.
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).
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.
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.
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.
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.
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).
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.
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:
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:
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.
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.
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  and RTP, to the transmission of MPEG streams and to compare its performances with the ones provided by TCP, UDP.
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: firstname.lastname@example.org
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: email@example.com
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.
- Viale Manzoni 30
- I 00185 Roma - Italy
Phone: +39-6-7716443 - Fax: +39-6-7716461 - E-mail: firstname.lastname@example.org
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: email@example.com