Performance Analysis and Trac Behavior of the Xphone. Videoconferencing Application System on an Ethernet. B. K. Ryu and H. E.

Transcription

1 Performance Analysis and Trac Behavior of the Xphone Videoconferencing Application System on an Ethernet B. K. Ryu and H. E. Meadows Department of Electrical Engineering and Center for Telecommunications Research Columbia University New York, NY 127 Abstract As a case study, we present the results of performance and trac behavior analyses of the Xphone system. Our major ndings are: 1) Eects of the total network load on the performance of Xphone are generally signicant. The video frame rate is adversely aected by the high variability of the concurrent network activities. Audio/video frames occasionally experience delays of more than 1{2 seconds. However, average end-to-end delay is relatively small despite high concurrent network load. Video frame drops due to audio/video synchronization appear to occur independently of the concurrent network activities. 2) Our analysis indicates that TCP appears to be inecient for this application under the current implementation. 3) The packet size distribution of the system is strictly bimodal. 4) The trac generated by the system shows fractal behavior, with the same fractal dimension regardless of the concurrent network activities. Keywords { Multimedia communication systems, Performance analysis, Ethernet trac analysis, Fractal. 1 Introduction While LANs are prevalent nowadays and thus have great potential to expedite the deployment of a variety of multimedia applications, the bandwidth sharing property of typical LANs such as Ethernet and Token Ring has made the design and deployment of multimedia applications dicult [2]. Most LAN topologies are based on sharing the bandwidth fairly and hence do not provide guaranteed quality of service for realtime multimedia applications in general. Since some past studies on LAN trac analysis have reported that LAN trac shows high variability [1], [4], [7], [11], the bandwidth-sharing property may result in prevalent delay uncertainty or packet loss, which may be a serious limitation for the successful design of LAN-based interactive multimedia applications. The Xphone system was developed to test the feasibility of LAN-based interactive multimedia applications under the generally prohibitive environment aforementioned. Part of its performance has been analyzed in [3] based on a measurement of an actual session with very short time duration (a few minutes only). Such a time period, however, may not be suf- cient to analyze fully the performance and to understand its trac behavior, which may be severely aected by concurrent network activities. It is the intention of this paper to analyze the network aspects of Xphone under the current network environment (about 3 workstations connected via a 1 Mbits/sec Ethernet) and design algorithms [3] based on long-time measurements of a few actual sessions. To this end, we specically set up the following objectives: Investigating the eects of concurrent network activities on the performance parameters of Xphone such as video frame rate, delay jitter, and video frame drop. Examining the suitability of TCP for LAN-based multimedia applications. Analyzing trac behavior of Xphone under the bandwidth-sharing environment. The fact that little data has been published on the trac behavior of LAN-based multimedia applications in real networks has also motivated this study.

2 Osage Hopi Measuring Host video & audio ack about 1 meters separate TCP connections ack video & audio 1 Mbps Ethernet Figure 1: Conguration of the Xphone System 2 Network Environment, Measurements, and Operational Algorithms Figure 1 shows a simplied conguration of the currently implemented Xphone system. It consists of two hosts (Sun SPARCstation 2), Osage and Hopi, which serve the Xphone system in the 1 Mbits/sec Image Laboratory Ethernet. The trac measurements are made using a raw Ethernet packet capture program (tcpdump) [5] running on a Sun SPARCstation 1. In a promiscuous mode, tcpdump identies every healthy packet on the network, extracts its header information, timestamps it, and stores the resulting information in the disk. Sun's network interface tap (NIT) device driver provided the mechanism to monitor all Ethernet packets indiscriminately 1. We note that much consideration has been made to minimize a few limitations of tcpdump and measuring host such as timestamp accuracy and processing capability. Two measurements, called I and II, have been taken for the study of the Xphone trac under various network activities. I and II represent cases in which the network is lightly and heavily loaded, respectively. Articial load was generated during measurement II using a simple client-server application in order to increase total network load. A summary of both measurements is given in Table 1. Measurement I II Start 18:37:26 1:2:54 Stop 19:11:24 1:51:3 Duration 33m58s 3m36s Throughput (pkts=sec) Utilization 1.92 % % Throughput of Hopi (pkts=sec) Variance of Hopi (pkts=sec) Table 1: Summary of Measurements I and II Basically, Xphone works in the following way: Once a session is set up, a CCD color video cam- 1 However, NIT is unable to capture packets sent from the measuring host era on top of each host (Osage and Hopi) produces video frames at the rate of 3 frames/sec. Then, Xphone captures the most recent frame, compresses it using JPEG, and sends the resulting packet down to TCP/IP. Since a video frame generates 5 { 7 KBytes, TCP segments it into several smaller packets so that the maximum size of an Ethernet packet (1518 Bytes) can be met. Upon the successful, lossless transmission of the whole frame by TCP, the system goes back to the rst step and repeats the same procedure. A simplied ow diagram for this operation is shown in Fig. 2. Audio frames are transmitted in a somewhat dierent way since they have implicitly more stringent delay requirement than video frames 2. The system currently employs a silence detection mechanism in order to minimize overall end-to-end delay of audio frames. The reader is referred to [3] for more technical detail of its implementation. Start Xphone Capture Frame Compression (JPEG) Segmentation (TCP) Transmission Sending Host Ethernet Playback Audio/Video Synchronization Decompression Desegmentation (TCP) Reception Receiving Host Frame Drop Figure 2: A simplied ow diagram of acquisition/playback of video frames Upon the receipt of each video frame, Xphone determines whether the video frame is played back or dropped depending on the synchronization with respect to the audio frame. As the system assumes \best-eort" delivery of information, there is no bounded end-to-end delay. Therefore, the decision whether a video frame is to be dropped is not made upon the end-to-end delay but upon the relative discrepancy with the audio information. As shown later, the decision of dropping frames at the highest level based on TCP may not be the best choice under the \best-eort" delivery environment. An alternative is to use an unreliable protocol such as User Datagram Protocol (UDP), which is currently an active ongoing research [3]. 2 Note that video frames are synchronized with respect to audio frames, requiring that no audio frames be lost or dropped.

3 3 Network Load and Performance As expected, the Xphone trac at the highly loaded network (II) shows much higher variability than at the lightly loaded network (I) in terms of throughput (Fig. 3 and Table 1). Such a phenomenon can be easily explained by the ow control of TCP and the bandwidth-sharing property of Ethernet. Packets/sec Measurement I Total Network Traffic Xphone Traffic from Osage Packets/sec Measurement II Total Network Load Xphone Traffic from Hopi Figure 3: Network Load and Xphone Trac (Throughput) (a) audio and video frames mean = 268 msec std. dev. = 83 msec of measurement (c) audio frames only mean = 197 msec std. dev. = 48 msec of measurement (b) video frames only, excluding ones dropped mean = 34 msec std.dev. = 78 msec of measurement (d) video frames dropped mean = 289 msec std. dev. = 6 msec of measurement Figure 4: Jitter (Measurement II) While real-time multimedia applications are somewhat tolerant of loss of information, they are generally stringent about end-to-end delay. However, there is no bounded end-to-end delay for the Xphone system as it operates under a \best-eort" environment (Fig. 4). As a result, audio/video frames occasionally experience delays of more than 1-2 seconds. Nevertheless, we note that the average end-to-end delay of audio/video frames is relatively small (under 3-35 msec). By the silence detection algorithm [3], the delay of most audio frames is kept under 25 msec (Fig. 4(c)). One interesting observation from Fig. 4 is that the delay of video frames played back (Fig. 4(b)) is generally higher than that of dropped video frames (Fig. 4(d)). Since video frames are dropped due to their relative time discrepancy with audio information, the dropped frames do not necessarily have a higher delay than the playback frames. However, such a phenomenon may imply further possible reduction of the end-to-end delay of video frames by improving the algorithms related to audio/video synchronization 3. Fig. 5 shows that the performance of Xphone degrades as the network activities increase. Figures 5 (a) and (b) imply that frame rate and end-to-end delay are severely aected by the concurrent network activities. One of the major reasons for such results is that as the network becomes busier, it takes more time for TCP to transmit a whole video frame, which is segmented into smaller packets based on the current algorithms. We also note that occasional larger-than-the-average delays, called delay outliers, are caused by TCP retransmissions (Fig. 5 (c)). Since a high retransmission rate is a consequence of high total network throughput, it appears that the retransmission of TCP is the main cause of the delay outliers and the decreased frame rate (Fig. 5 (c,d)). Fig. 6 indicates that on the average, the playback frame rate is reduced by about 3% compared to 8 frames/sec under normal network activity. Such a low frame rate is a direct result of high network activity and the currently implemented operational algorithms described in Section 2. Surprisingly, the frame drop rate is 25% as much as the playback frame rate, (Fig. 6(b)), strongly implying that lossless transport of video frames may be ineective and even adverse to the performance as retransmissions result in delay outliers. Another interesting result is that the frame drop rate is found to be uncorrelated with both total network load and retransmission rate. The estimated correlation coecients for both cases turn out to be very close to zero. That is, video frame drops occurring due to audio/video synchronization are not 3 In doing so, audio/video synchronization accuracy may be sacriced as a trade-o.

4 signicantly aected by the concurrent network load. 1 8 (msec) (a) Throughput vs. Average Frame (correlation coefficient =.15) Frames/sec (b) Throughput vs. Frame Rate (correlation coefficient = -.24) aected by total network load and is relatively high compared to the actual playback frame rate. ) Lossless transmission at a transport layer may have to be replaced by unreliable transmission (such as UDP) of dropped video frames is generally smaller than that of playback video frames. ) Currently implemented audio/video synchronization algorithm may have to be further optimized Throughput (packets/sec) retransmissions/sec (c) vs. Retransmission Rate (correlation coefficient =.8) average frame delay (msec) retransmissions/sec Throughput (packets/sec) (d) Throughput vs. Retransmission (correlation coefficient =.8) Throughput (packets/sec) Figure 5: Eects of Network Activity on the Xphone Performance (Measurement II) Frames/sec (a) Frame Rate (playback frames only) mean = 5.6 std.dev. = 1.6 Frames/sec (b) Frame Drop Rate mean = std.dev. = Packet Size Distribution Information about packet size distribution is important for the design and tuning of communications protocol and buer management algorithms. Figures 7 (a) and (b) clearly show that regardless of the network activity the packet size distribution is strictly bimodal. While the rst peak, occurred at 64 bytes, was made mostly by ack packets, the second peak at 1518 bytes was made purely by data (audio and video) packets. Such bimodal distribution is explained in two ways. First, ack packets do not contain any information in their data eld. They carry only the acknowledgement sequence numbers in the header eld, resulting in the smallest-size packets of Ethernet (64 bytes). The other peak comes from one of the generic characteristics of TCP protocol which attempts to maximize the network utilization once a connection is established. As the size of a typical video frame after JPEG compression ranges from 5 to 7 KBytes, TCP attempts to segment it into n r where n 2 f1; 2; 3; : : :g and r < 146 bytes. 5.% (a) Host: Hopi, Measurement: I 5.% (b) Host: Hopi, Measurement: II % % Figure 6: Comparison of Frame Rate and Frame Drop Rate (Measurement II) 3.% 2.% 64 3.% 2.% Based on the above results, we summarize some remarks for further optimization of the performance: 1. Frame rate is vulnerable to concurrent network load. ) A robust and reliable source bit-rate control technique may have to be implemented. 2. Despite occasional delay outliers, average end-toend delay is relatively small. 3. outliers are mainly caused by retransmissions of TCP. Further, frame drop rate is not 1.%.% packet size (byte) 1.%.% packet size (byte) Figure 7: Histogram of Packet Size 4 Note that the current system requires lossless transmission of audio information for the purpose of audio/video synchronization. For UDP-like protocols to be employed, at least the synchronization algorithms must be revised.

5 5 Fractal Behavior A new approach for modeling packet trac is to employ self-similarity (fractal structure), a structural similarity across all or at least a wide range of time scales [6]. In short, fractal trac behavior is characterized as a power-law decay whereas currently proposed packet trac models such as Poisson, Hyperexponential, Autoregressive model, and Markov-modulated Poisson process (MMPP) are characterized by an exponential decay. Because of signicant discrepancy between the two types of decays, trac showing fractal behavior is generally characterized by exponentialdecaying models only with diculty and ineciency. One of the several features displaying self-similar behavior is that the variance of sample means decreases more slowly than the reciprocal of the sample size, that is, Var[X (m) ] 1 m? as m! 1; (1) where < 1 < 1 and < < 1. Here X (m) = (X (m) k ; k = 1; 2; 3; : : :) denotes an aggregated time series (sample mean) obtained by X (m) k = 1 m (X (k?1)m+1 + X (k?1)m X km ) (2) where X = (X k ; k = 1; 2; 3; : : :) denotes the number of packets per time unit. Parameter is obtained by plotting log(var[x (m) )] against log(m) (variance-time plot) and by determining the slope of the simple least squares line tted to the resulting points in the plot, ignoring small m. For other features of self-similar packet trac, readers are referred to [6] and references therein. Another tool for determining whether a given packet trac manifests fractal behavior is to make use of the index of dispersion for counts (IDC). Let N(T ) and I(T ) denote the number of arrivals of a point process and the IDC during the time interval T, respectively. Then I(T ) is dened as: I(T ) def = Var[N(T )] E[N(T )] : (3) In particular, fractal point processes have I(T ) 2 T D as T! 1 where < 2 < 1 and < D < 1 [9]. D is known as the fractal dimension of the original point process and obtained by using the same method as for. From (1) - (3), it is easy to see that D = 1?. Figure 8 manifests the fractal behavior of the Xphone trac for both measurements. In Fig. 8(a), X was chosen to be the number of Xphone packets arriving during a 1 msec time unit. Clearly, straight lines appear for both cases as m increases in the variancetime plot 5. Similarly, after the dead time of about.5 second, I(T ) also shows straight line variation over a few orders of time scales on a log-log plot. We see that D and satisfy the relation D = 1?. It is interesting to note that the fractal dimension D is the same (or at least very close) for both measurements, regardless of the degree of overall network activity. We took a few more measurements under various network activities to discern whether such a phenomenon is typical, and observed the same D (and therefore the same ) with only a small change in the shape of I(T ) for every measurement. Therefore it appears that the Xphone trac behavior is generically unique under the current implementation and thus provides a useful method for characterizing the Xphone trac using simple fractal point processes available [8], [9], [1]. Var[X(m)] slope = -1 Host: Hopi m (a) slope = -.19 Measurement I Measurement II slope = -.2 I(t) Host: Hopi, Measurements I and II slope = time window size (b) Measurement I Measurement II Figure 8: Manifestation of Fractal Behavior using (a) Variance-time Plot ( =.19 (I),.2 (II)) and (b) IDC (D = :82 for both I and II) 6 Conclusions and Related Work In this study, we have found some interesting and potentially important results about the Xphone system which may aect the future design of LAN-based multimedia applications. As generally believed and expected, the eects of the total network load on the performance of Xphone are found to be signicant. Suggestions made earlier to mitigate such eects are being considered for the next stage of the Xphone system. 5 The deviation of variance-time plot and I(T ) of measurement I from straight lines at the end occurs due to the nite length of the data. Generally, fractal behavior is observed based on data obtained over a very wide range of time scale. slope = 1

6 Another important nding is that the Xphone traf- c shows fractal behavior, with the same fractal dimension irrespective of concurrent network activities. Further work will be concentrated on which factors of the network and design algorithms drive such behavior and on analyzing the trac in more detail with the aid of fractal point processes. Acknowledgements The rst author would like to thank Prof. S. F. Chang for his overall supervision and valuable suggestions. The rst author is also greatly indebted to Dr. S. Lowen for his review and numerous discussions on fractal processes. Special thanks to A. Eleftheriadis and S. Pejhan who have shown great interest in this work and cleared many questions on the Xphone system. This work would never have been possible without their generous help. [9] S. B. Lowen and M. C. Teich. Estimating the dimension of a fractal point process. accepted for Proc. SPIE (Chaos in Biology and Medicine), 236, [1] S. B. Lowen and M. C. Teich. Fractal renewal processes generate 1/f noise. Physical Review E, 47(2):992{11, February [11] J. F. Shoch and J. A. Hupp. Measured performance of an Ethernet local network. Commun. ACM, 23(12):711{721, December 198. References [1] B. G. Barnett and E. T. Saulnier. High level traf- c analysis of a LAN segment. In IEEE Proc. 17th Conference on Local Computer Networks, pages 188{197, [2] B. Cole. The technology framework. IEEE Spectrum, pages 32{39, March [3] Alexandros Eleftheriadis, Sassan Pejhan, and Dimitris Anastassiou. Algorithms and performance evaluation of the xphone multimedia communication system. In Proc. ACM Multimedia '93 Conference, August [4] R. Gusella. A measurement study of diskless workstation trac on an Ethernet. IEEE Trans. on Comm., 38(9):1557{1568, September 199. [5] Van Jacobson et al. Tcpdump, June manual. [6] W. E. Leland et al. On the self-similar nature of Ethernet trac. In Proc. ACM SIGCOMM '93, pages 183{193, [7] W. E. Leland and D. V. Wilson. High timeresolution measurement and analysis of LAN traf- c: Implications for LAN interconnection. In Proc. IEEE INFOCOM '91, pages 136{1366, April [8] S. B. Lowen and M. C. Teich. Doubly stochastic Poisson point process driven by fractal shot noise. Physical Review A, 43(8):4192{4215, April 1991.