Quality of Service Support of Distributed Interactive Virtual ... - CiteSeerX

Quality of Service Support of Distributed Interactive Virtual Environment Applications in IP Networks Hong Yu*$ , Quanyou Zhou$ , Dimitrios Makrakis $ , Nicolas D. Georganas&, Emil Petriu@ $

Broadband Wireless and Internetworking Research Laboratory & Multimedia Commutations Research Laboratory @ Sensing and Modeling Research Laboratory School of Information Technology and Engineering University of Ottawa 161 Louis Pasteur St., Ottawa, ON, K1N 6N5, CANADA E-mails: {hyu, dimitris, qzhou, georgana, petriu}@site.uottawa.ca

•

Abstract— This paper reports on the performance of Distributed Interactive Virtual Environment (DIVE) applications, deployed through Internet. Our goal is to understand the behaviour of a DIVE application, its interaction with competing traffic streams, as well as its network resource requirements for a satisfactory performance. As DIVE is becoming the building block of new applications and services, impacting several established or new and growing sectors of our economy (e.g. electronic commerce, tele-training, transportation, health), it is important that we understand the resource requirements of these applications, as well as the “stress” they will impose on the network. Index Terms—QoS, DiffServ, DIVE, Internet

I. INTRODUCTION Distributed Interactive Virtual Environments (DIVE) [1, 2] are shared virtual worlds that could radically alter the way people work, play, learn, consume and collaborate. In DIVE applications, a simulated world runs not on one computer system, but on several, connected over a network (e.g. Internet). People who use those computers are able to interact in real time, sharing the same virtual world. Each of the machines participating in the simulation of the virtual word is called a “host”. On each host there is a number of “entities” (things in the virtual environment) that communicate their changing state by sending “update messages”. The specific entity that corresponds to a participant’s virtual body is called “avatar”. Avatars are either included within the virtual world during initialization or dynamically created at a later time. The following are some of the key features of DIVE applications:

*

Ms. Hong Yu is presently a Software Designer with the Software Department of “Research In Motion” (RIM), Waterloo, Ontario.

They are sensitive to packet delays. Any action issued by any participant in the DIVE (transported through packets) must reach the other participants within 100 ms. • They should be capable of scaling to large number of participants. The number of participants should be unlimited to allow everybody to enter the virtual world. • Messages are transported through short packets (few tens of bytes) and frequently. This characteristic differs from other multimedia application data like audio and video. • They demonstrate high level of dynamicity in group structure and topology. Participants should be able to join and leave the session dynamically. While DIVE applications will be used in services related to commerce, health, training, transportation and business, there is no adequate understanding on how they behave in modern networks. In [3], we presented the first (to the best of our knowledge) research results dealing with sensitivity analysis of DIVE applications in Ethernet and ATM networks, and modeling of DIVE traffic. The work was conducted under a CANARIE funded research project. For completeness, some of our results, reported in [3] will be included in this work. This paper, expands the work reported in [3], by testing a VR application in a Differentiated Services (Diffserv) network. Our objective is to assess the ability of DiffServ to support these delay, packet loss and performance sensitive applications, understand the effect “main-stream applications”, such as video, ftp etc., have on DIVE, when they co-exist in the same network, as well as “fine tune” the network’s parameters and architecture, in order to provide acceptable performance levels to DIVE applications. We conducted our study through experimentation. A DIVE based application of tele-training nature was used, which was developed by researchers of the Multimedia Communications Research Laboratory (MCRLab) of the University of Ottawa. Its function is to enable instructors and technical support to train and guide remote users through Internet, on maters related to Newbridge’s ATM

switches. The development of the application was done under a Newbridge funded project. The remaining of the paper is organized as follows: In section 2, the teletraffic model of the VR application is presented. In section 3, we describe the network set up of our research. In section 4, the performance testing results are presented. Conclusions are given in section 5. II. TELE- TRAFFIC MODEL OF DIVE We collected data of the DIVE application, running between three systems. We monitored the traffic, produced from one user, sent to the other. We ran experiments for Ethernet and ATM networks. The results reported correspond to Ethernet; however, ATM results were similar.

Packet size (bytes)

250 200 150 100 50 0 0

5

10

15

20

We found that the traffic is very thin; roughly 4 to 5 Kbps. Figure 1 shows the behaviour of packet size vs. packet arrival time. A periodic rather than asynchronous behaviour can be observed in the generation of packets. The packet size has almost always the same value of 92 bytes, with a few exceptions of packets having 64, 82, 130, 180, or 232 bytes. In order to verify the periodicity in the generation of packets, figure 2 shows a plot of the packet inter-arrival time, and figure 3 displays the resulting histogram for the same variable. It can be observed that there is a bimodal behaviour for the packet inter-arrival time. The sizes of interarrival times tend to accumulate around two different values, which correspond to approximately 10 ms and 280 ms. To express this behaviour, we proposed a bursty (ON/OFF) model for the generation of packets. In this model, the shorter packet inter-arrival times correspond to the distance between packets within the same burst, while the longer packet interarrival times correspond to the distance between packets that belong to different bursts. Bursts and burst size are generated according to distributions, developed according to the collected data. Figures 4 and 5 display the empirical and approximated (model) distributions for the probability density function (pdf) of interarrival times and probability mass function (pmf) of burst size. It is clear that the developed models closely resemble the statistics of the collected data.

Packet arrival time (sec)

Figure 1. Packet size vs. packet arrival time

0.30

Packet interarrival time (sec)

0.25

0.5 0.45 0.4 0.35 0.3 0.25 0.2 0.15 0.1 0.05 0

0.20

Empirical pdf

0.15

Approximated pdf

0.10 0.05 0.00 0

0.2

0.4

0.6

0.8

1

Burst interarrival time (sec)

0

2000

4000

6000

Figure 4. Empirical and approximated burst-interarrivaltime pdf.

8000

Packet number

Figure 2. Packet interarrival time vs. packet number

0.60 0.50

2500

Empirical pmf

0.40

2000

Approximated pmf

0.30

1500

0.20 0.10

1000

0.00

500

0

5

10

15

Burst size (packets)

0 0

0.1

0.2

0.3

0.4

Packet interarrival time (sec)

Figure 3. Packet interarrival time histogram

Figure 5. Empirical and approximated burst-size pmf A general conclusion that can be drawn from our modeling, both for the Ethernet (and the ATM case), is that the source has an ON/OFF behaviour. However, the distribution of the time that the source remains in the ON state does not appear

to have long-tailed characteristics. The same applies for the OFF state. This observation leads us to the conclusion that aggregation of the traffic produced by such sources should not have short-range dependence characteristics. This is in contrast to the models describing other types of traffic (e.g. ftp, r-login, www, etc.), which are governed by long-tailed distributions [4] and, when aggregated, they produce longrange dependence, as explained in [5]. This also suggests that this type of traffic will be “friendlier” to the network and the competing applications. The produced model has been used in this work. III. EXPERIMENTAL TEST BED SET UP Figure 6 displays the network topology, used in our experimental study. It consists of a video server, a client, three Ethernet segments, a traffic sink and two InterWatch 95000 (IW95000) network analysis/traffic generation tools, manufactured by GN-Nettest. The DIVE1 (sending) host, video server host and the background traffic generator are located on a Fast Ethernet LAN segment where the Edge router input interface is connected as well. The output interface of the Edge router and the input interface of the Core Router are connected by a second Fast Ethernet LAN segment. The DIVE2 (receiving) host, video client host and the sink that is used to receive the background traffic are connected to the third (10 Mbps) Ethernet LAN segment. DIVE1 and DIVE2 are NT based machines. The video server, client and two routers are PCs running under Linux. One of the IW95000 units is used to generate udp packets as background traffic, the second is used to monitor the network traffic. In order to obtain time -related statistics for the VR traffic, tcpdump was used.

Figure 6. Test bed topology In our testbed, we have implemented Expedited Forwarding (EF) Per Hop Behaviour (PHBs) (RFC2598) and Assured Forwarding (AF) PHB (RFC2597). We have developed Priority First In First Out (PFIFO), and Class Based Queuing (CBQ) queue management schemes. In [6], a similar testbed has been used to evaluate the performance and behaviour of MPEG-2 video in a DiffServ network. The interested reader can find more information regarding DiffServ and queue management disciplines in that work.

IV. PERFORMED TESTS AND RESULTS ANALYSIS A comprehensive set of experiments has been contacted and detailed statistical information has been collected and processed. Due to limited space, we can only report in this paper a small part of our results. More information will be given during the presentation. In this paper, we present results concerning the packet loss rate of the DIVE application, as well as their forwarding delay distribution, when background traffic and / or video co-exist in the network. Bursty background traffic is produced and applied at the input of the Edge router, by the traffic generator of one of the IW95000 units. The traffic is applied in the form of a burst (ON) period, followed by an idle (OFF) period. ON and OFF periods succeed each other. MPEG-2 compressed video is used as another traffic source. The observed average video transmission rate is close to 4 Mbps, while the observed maximum and minimum rates are 4.8 Mbps and 3.3 Mbps. We present results for the following configurations: i) Best effort network. ii) DiffServ network, with the DIVE application and video placed at EF, background traffic placed at best effort class (EF1-PFIFO). iii) DiffServ network, with the EF class split in two different subclasses (EF2-PFIFO). PFIFO discipline is used, with DIVE placed in the higher priority and video in the lower priority EF queue. iv) DiffServ with CBQ discipline applied, with DIVE and video assigned to EF class and placed in the same queue (EF1-CBQ). The resource allocation for this class is 4 Mbps. No borrowing among classes is allowed. v) DiffServ with CBQ discipline applied, with DIVE and video allocated EF class but placed in different queues (EF2-CBQ). The queue for DIVE is 5 packets, whereas the queue for video is 30. The resource allocation to DIVE is 7 Kbps, whereas the resource allocation to video is 4 Mbps. No borrowing is allowed. We have also evaluated DIVE in the presence of ftp traffic, and when is assigned to the AF classes. However, space limitations do not allow us reporting these results in this paper. Figures 7 and 8 display the percentage of packet losses experienced by the DIVE traffic stream at the core router, for different values of background traffic. Since the packet losses experienced by DIVE applications should be very low it is evident, that a best effort network is not capable of supporting such applications. On the contrary, DiffServ configurations are performing quite well. The higher detail offered by figure 5, allows us to make a comparison between the various DiffServ schemes. It is evident that EF1-PFIFO provides the worst performance. At 50% loading, it gives a packet loss rate at 10-5 ; at 90% loading, it becomes 4.5x10-5 . When different queues are provided within the EF discipline, no losses were encountered. The presence of bursty video, mixed with DIVE traffic, could be a threat for DIVE applications. Video produces considerably “heavier” traffic as compared to DIVE. During burst periods, it can take all EF resources, forcing DIVE packets to be dropped, thus impairing the packet loss sensitive DIVE application. In order to solve this problem, we considered separation of the two types of traffic within EF (EF2-PFIFO). As can be seen, the performance improves. The packet loss performance is again very good for both CBQ configurations.

V. CONCLUSION In the present work, we investigated the behaviour of a DIVE application in best effort and differentiated services networks with different queuing discipline strategies. From the results, it is quite evident that best effort is not able to support such packet loss and delay sensitive applications. On the other hand, Diffserv is capable of doing so. Our results indicate that there is benefit if we do not only forward traffic to EF class, but we also keep it separate from other “main stream”, “heavier” and more bursty applications such as video. Also, use of CBQ rather than PFIFO provides lowed forwarding delays. Thus, CBQ should be used to support connections between DIVE users that are located far from each other geographically.

Packet Loss Rate

Packet Loss Rate (%)

0.12 0.1 0.08 0.06 0.04 0.02 0 0

10

[4] Paxson V., Floyd S., “Wide Area Traffic: The Failure of Poisson Modeling”, IEEE/ACM Transactions on Networking, Vol. 3, No. 3 (June), pp 226-244, 1995. [5] Willinger, W. Taqqu, M. S., Sherman, R., Wilson, D. V., “Self-Similarity Through High-Variability: Statistical Analysis of Ethernet LAN Traffic at the Source Level”, IEEE/ACM Transactions on Networking, Vol. 5, No. 1 (Feb.), pp 71-86, 1997 [6] H. Yu, D. Makrakis, L. Orozco-Barbosa, “Experimental Evaluation of MPE-2 Video over Differentiated Services IP Networks”, in Proceedings of Pacific Rim 2001 Conference, Victoria, Aug. 2001.

30

40

50

60

70

80

90

100

Best Effort

EF1-PFIFO

EF1-CBQ

EF2-CBQ

EF2-PFIFO

Figure 7. Loss rate of DIVE packets versus background traffic loading Packet Loss Rate

0.02 0.018 0.016 0.014 0.012 0.01 0.008 0.006 0.004 0.002 0 0

10

20

30

40

50

60

70

80

90

100

Background Traffic (%)

References:

Best Effort

EF1-PFIFO

EF1-CBQ

EF2-CBQ

EF2-PFIFO

Figure 8. Loss rate of DIVE packets versus background traffic loading Forwarding Delay Distribution Fraction of Forwarded Packets

[1] S. Benford, A. Bullock, C. Greenhalgh, R. Ingram and D. Snowdon, “Collaborative Virtual Environments: User Interaction and Populated Information Terrain”, in Proceedings of Imagina'95, Monte Carlo, February 1995. [2] Q. Wang, M. Green and C. Shaw, “EM - an environment manager for building networked virtual environments”, in Proceedings of the Virtual Reality Annual International Symposium. VRAIS'95, pages 11-18. IEEE Computer, IEEE Functional Specification, Draft prETS300652, ETSI Secretariat, July 1995. [3] J. R. Gallardo, L. Qin, M. Hafid, D. Makrakis and A. Hafid, “DIVE-Based Applications over IPv6-Capable Networks: Teletraffic Studies and Performance Analysis” in proceedings of the 7th International Conference on Advances in Communications and Control (COMCON7), Athens, Greece, July 1999.

20

Background Traffic (%)

Packet Loss Rate (%)

As mentioned earlier, DIVE applications are highly sensitive to end-to-end delay as well. Should a packet be delivered 100 msec after generation, it is considered outdated. In figure 9 we have plotted the fraction of DIVE that go over a certain value of forwarding delay. It is quite evident that best effort is performing very pad, while the DiffServ configurations are performing well. The fraction of packets experiencing forwarding delay higher than 10 msec. is very small in all cases. In addition to this, we see a superiority of CBQ over PFIFO. Since lower per router forwarding delays allow to go over longer distances (larger number of routers), then CBQ should be used to accommodate DIVE users located at far away dis tances.

0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 10ms

20ms

40ms

60ms

80ms

100ms

Time (ms)

Best-effort

EF1-PFIFO

EF1-CBQ

EF2-CBQ

EF2-PFIFO

Figure 9. Fraction of forwarded packets whose forwarding delay exceeds certain size.