predicting network traffic for collaborative virtual environments

Computer Networks and ISDN Systems 30 (1998) 1677–1685

Predicting network traffic for collaborative virtual environments

Chris Greenhalgh a,Ł, Steve Benford a, Adrian Bullock a, Nico Kuijpers b, Kurt Donkers b

a Department of Computer Science, The University of Nottingham, University Park, Nottingham NG7 2RD, UKb TNO Physics and Electronics Laboratory, 2509 JG The Hague, Netherlands

Abstract

We introduce a method for predicting the network traffic that will be generated by collaborative virtual environmentapplications with varying numbers of participants. Statistical analysis of event logs from user trials results in a userbehaviour model. Controlled traffic measurements combined with an analysis of the application architecture and networktopology results in a system behaviour model. These two models are combined to produce a network traffic model. Wedescribe the application of this method to a business game application that has been developed as part of the COVENproject. Finally, we make some general observations concerning the network traffic generated by CVEs including its burstynature and the potential use of techniques such as multicasting and statistical multiplexing to reduce network load. 1998Elsevier Science B.V. All rights reserved.

Keywords: Collaborative virtual environments; Service provisioning; Network traffic modelling and ISDN networks

1. Introduction

The technology of Collaborative Virtual Environ-ments (CVEs), distributed multi-user virtual realitysystems that support co-operative work, is currentlyemerging from the research domain into the com-mercial environment. There are many potential ap-plications of CVEs including virtual meeting rooms,shared information visualisations, battle and emer-gency simulations, group decision support and vari-ous forms of art and entertainment. This technologyhas now matured to the point where commercialproducts are available and early public services arebeing deployed on the Internet [1].

As CVEs become more widely deployed, so ser-vice and network providers will be faced with the

Ł Corresponding author. Tel.: C44-115-9514221; Fax: C44-115-9514254; E-mail: [email protected].

problem of service provisioning. This involves un-derstanding the resources that are required to supporta given CVE application. Given this knowledge,service providers can ensure that the necessary re-sources are available to support a CVE application,or alternatively, can constrain the application to op-erate within the limitations of available resources(e.g., by limiting the number of participants). A coreproblem with service provisioning is determining thebandwidth requirements of different CVE applica-tions as used by varying numbers of participants.Specifically, it is important to understand both thevolume of network traffic that will produced andalso its general characteristics (i.e., is it bursty andhow does it vary over different phases of an activ-ity?).

Predicting the network traffic that will be gener-ated by CVEs is a difficult problem. CVEs are an in-herently complex class of application. Multiple users

0169-7552/98/$ – see front matter 1998 Elsevier Science B.V. All rights reserved.PII: S 0 1 6 9 - 7 5 5 2 ( 9 8 ) 0 0 2 0 9 - 8

1678 C. Greenhalgh et al. / Computer Networks and ISDN Systems 30 (1998) 1677–1685

share a computer generated virtual world. Each usercan freely navigate their viewpoint within this world;is directly represented to others through a processof embodiment; can communicate with others usingvarious media, including audio, text, graphics andvideo; and can directly manipulate objects within theworld. Consequently, CVEs involve a variety of traf-fic types from dynamic movement updates, throughcontinuous audio and video to potentially large state-transfers as users join new worlds. Furthermore,network traffic is likely to be highly dependent onpatterns of user behaviour (i.e., on how often theymove, speak, manipulate objects and so forth andthe extent to which these activities are performed ingroups or as individuals).

This paper describes some early experiments thathave explored the network traffic requirements ofCVEs. Although the details are concerned with aspecific CVE application and platform, the papermakes two broader contributions to the problem ofservice provisioning for CVEs. First, it demonstratesa general method for constructing traffic predictionmodels based on data captured from trials. Second, itmakes (with caution) some broad qualitative obser-vations concerning the nature of network traffic forCVEs in general and the techniques that are availableto reduce bandwidth requirements.

2. Method

We begin by outlining our general approach. Ouraim is to construct a predictive model of networktraffic for a given CVE application that takes ac-count of the number of simultaneous participants,the pattern of their activity and the behaviour of theapplication itself. Our approach is to conduct exten-sive trials with the application in order to capture andthen analyse two kinds of data. The first kind of datais detailed event logs which record and time-stampevery action of every participant, where the set ofpossible actions is determined by the particular ap-plication (typical examples are movement, speakingand manipulating objects). The second kind is mea-surements of network traffic on different networklinks, captured using the tcpdump utility.

This data is then analysed according to threesteps:

(1) User behaviour model – statistical analysis of theevent logs results in a user behaviour model thatdescribes typical patterns of user activity withthis application. This model summarises the av-erage frequencies of actions; the extent to whichpatterns of activity vary according to participantand phase of the application; and the extent towhich actions are correlated among users. Cor-relation is concerned with whether participantstend to perform specific actions at the same time,whether they avoid overlaps or whether they areacting independently.

(2) Application behaviour model – this step involvesdeveloping an application behaviour model thatidentifies the traffic that will appear on a spe-cific network link when a given application eventoccurs. There are two aspects to this model.First, through a process of controlled traffic mea-surements, we determine the size of the mes-sages that are sent between different applica-tion components whenever a given action oc-curs. Secondly, by considering how the logicalcommunication architecture of the applicationmaps down onto the underlying physical net-work topology we consider how these messagesbecome concentrated on different network links.For example, an application that uses a unicastbased peer-to-peer communication architecture(i.e., where each participant’s process sends aseparate update message to each of its peers)but is running over a star network topology, willsend several update messages across a single linktowards the central hub for a given action. Com-bining these two aspects allows us to predict thenetwork traffic that should appear on a given linkfor a specified sequence of actions. The applica-tion behaviour model is validated by comparingthe traffic that is predicted for an example sessionwith the traffic that was actually observed.

(3) Network traffic model – this step combines steps1 and 2 to create a model of network traffic thatpredicts the traffic that might be generated by thisparticular application. We are particularly inter-ested in the mean and peak levels of traffic thatmight be expected on a given link. The mean traf-fic on a link is predicted from the average frequen-cies of events (from the user model). The peaktraffic is given by the worst case situation, where

C. Greenhalgh et al. / Computer Networks and ISDN Systems 30 (1998) 1677–1685 1679

users act as much as is possible (e.g., continuallymoving and speaking). The resulting model indi-cates how these mean and peak predictions varyaccording to the number of participants.

To date, we have applied this approach in twoseparate series of trials:ž Trials with the MASSIVE-1 system [2] as part

of the BT funded Inhabiting the Web project.Over twenty virtual meetings were held acrossthe UK’s SuperJANET network. These involvedup to ten participants from six different sites (fiveuniversities and BT Laboratories). The results ofthese trials are reported in [3,4].ž Trials with a ‘business game’ application devel-

oped at TNO [7] using the dVS system from Divi-sion Ltd [5] as part of the COVEN project (Euro-pean Union ACTS programme). Over twenty vir-tual meetings were held between four participantsat four different sites in the UK and the Nether-lands. The remainder of this paper describes theresults of these trials.Having described our general approach to net-

work traffic prediction for CVEs, the following sec-tions describe the results of the COVEN trials, be-ginning with an overview of the COVEN businessgame and the organisation of the trials.

3. An overview of the COVEN project trials

The COVEN project is funded under the EUACTS programme and is concerned with the devel-opment, demonstration and evaluation of a scaleableCVE platform. One aspect of COVEN has involvedconducting network trials with the business gameapplication. These trials have involved over twentyvirtual meetings between four partners’ sites (Not-tingham University, UCL and Division in the UK andTNO in the Netherlands) running over a dedicatedISDN network.

The business game application has been writtenby researchers at TNO using Division’s dVS plat-form (version 4). Audio communication is providedby UCL’s RAT tool [6] that runs alongside dVS.The application consists of two main scenarios: abusiness game, involving the co-operative use ofthree spreadsheets, and a virtual conference roomwith graphics presentation facilities and shared text

surfaces. With the business game, users manipulate3-D widgets to control different parameters of a fi-nancial simulation and a central column representingnet profit rises and falls accordingly. The users’ taskis to co-operatively manipulate the simulation in or-der to obtain the maximum possible profit. With themeeting room, users can exchange text messages viaa series of private virtual screens and can display aseries of slides on a virtual projector. Throughout theapplication, users are represented by humanoid em-bodiments, can freely move about, can grasp objectsand can speak over an open real-time audio channel.

Fig. 1 shows four screenshots from the businessgame scenario. The top two images show three otherusers who are exchanging text messages near tothe spreadsheet. Note that all images are from ourown first party perspective. Bottom left we see auser referring to the virtual projector screen in themeeting room and bottom right we see the results ofsuccessfully manipulating the simulation, visualisedby a tall profit column which has appeared in thecentre of the room.

The infrastructure for the trials consisted of Sili-con Graphics workstations (typically an Impact classmachine) which were connected using ISDN. Thenetwork topology took the form of a star, with UCLat the hub and with two bonded basic rate ISDNchannels providing the link to each of the outlyingnodes. Over twenty virtual meetings were held overthis network between December 1996 and July 1997.The shortest meeting lasted for 30 minutes and thelongest for 150 minutes.

4. Network traffic modelling

We now briefly discuss the results of the trialsaccording to the three steps defined above: userbehaviour model, application behaviour model andnetwork traffic model. The following discussion isbased on event logs and traffic measurements fromfive of the twenty meetings.

4.1. User behaviour model

With the COVEN business game participants canengage in three main classes of activity: speaking,moving and manipulation of the spreadsheet.


Fig. 1. Scenes from the business game application.

4.1.1. SpeakingNetwork audio is provided in all of these trials

by the RAT audio tool. By analysis of the networktraffic logs from UCL (the hub) it is possible todetermine when participants are sending network au-dio data. RAT (like most network audio tools) usessilence suppression so that it does not send datawhen there is no significant sound being receivedby the microphone. Therefore the presence of audiopackets indicates that speaking or some other suf-ficiently loud sound is present. For the purposes ofthis analysis it is the generation of network audiodata that is being considered, rather than ‘speaking’as it might be assessed by a human expert. For the 5trials under consideration the average fraction of thetime for which any given participant was generatingnetwork audio traffic was 5.2%, i.e. informally wemight say that participants spoke on average 5.2% ofthe time. Note that this is per-participant; in a typical

meeting with 4 participants each one is speakingapproximately 5% of the time. This measure is veryvariable between participants. Ranging from a mini-mum average of 1.3% for the least active speaker upto an average of 10.7% for the most active speaker.

Intuitively, one might expect a negative correla-tion between speaking for different participants ina single session, i.e. that participants would ‘taketurns’ to speak. Our analyses indicates that over-lapping speech occurs somewhat less often thanrandom, i.e. participants do appear to be avoidingspeaking over one another to a certain extent. How-ever, it is not appropriate to assume at most onespeaker at a time for a session – overlapping speechis not an exceptional event.

4.1.2. MovementThe dVS4 version of the business platform in-

cludes general event logging facilities that, with


careful analysis, allow movements of individual par-ticipants within the virtual world to be identified.The trials all involve desktop-only use, with par-ticipants navigating using explicit actions with themouse in order to change their viewpoint within thevirtual world. The average fraction of time for whichan average participant was moving was 15.6%, i.e.informally we might say that each participant wasmoving on average 15.6% of the time.

For movement, the correlation of the observeddata is higher than chance, indicating that movementmay be co-ordinated at some level. For example,there may be stages of the meeting in which co-ordi-nated movement or realignment may be required. Inturn, these may result in bursts in network traffic.

4.1.3. ManipulationIn the business game participants interact with the

application by direct manipulation of 3D graphicalwidgets using the mouse. The basic event loggingincludes details of the corresponding changes in vir-tual entities but does not allow the cause of thesechanges to be determined. Careful use of additionalinformation from the business application logs al-lows the majority of user interactions to be identifiedand analysed. Application logs are only available fora subset of the trials under consideration (approxi-mately 100 minutes), and it is this subset which isconsidered here.

For the available data, the fraction of time whichan average participant spent actively interacting withthe application was 6.8%. As with audio and move-ment data there remains significant variation aroundthis average which might be attributed to individualvariations and to different stages of the meeting.

As with movement, the observed data for morethan one simultaneously interacting participant ishigher than chance, indicating that interaction maybe co-ordinated at some level. This confirms what weexpect from the nature of the task – the participantscollaborate around the spreadsheet to achieve a jointgoal. Consequently there is a distinct phase of themeeting in which interaction is concentrated.

To summarise, the average character of user ac-tivity in the trials considered is: speaking, 5.2% ofthe time; moving, 15.6% of the time; and interactingwith the application, 6.8% of the time. Speaking isnegatively correlated, but movement and interaction

are positively correlated. It should also be notedthat there is a large intrinsic variability in all of theabove measurements, with probable components ofindividual variation and also strong task dependence.As such, these measures must be used with cautionwhen considering network requirements.

4.2. Application behaviour model

There are two aspects to the application behaviourmodel: determining the volume of data that is sentfor each application event and identifying how thisis concentrated onto different links of the physicalnetwork topology. Addressing the first aspect hasinvolved controlled traffic measurements. The detailsof these are beyond to the scope of this paper, but tosummarise the key figures:ž audio – each participant generates 180 bits/s of

RTCP data plus 40800 bits/s of audio data (as-suming DVI encoding with 40 ms period) whenthey are speaking.ž movement – each participant generates 31040

bits/s of updates while they are moving; this isduplicated for every other participant in the world.ž manipulation – each participant generates 27100

bits/s of updates while they are interacting with avirtual object; the server generates an additional17400 bits/s for the same duration; this is dupli-cated for every other participant in the world.There is also some additional server and applica-

tion traffic and there may be other protocol overheads(e.g. addition acknowledgement packets).

Addressing the second aspect requires an under-standing of how the logical communication archi-tecture of the application relates to the physicalnetwork topology. The dVS platform that deals withthe movement and manipulation actions is based ona peer-to-peer unicast architecture. This means thateach movement or manipulation update that is gen-erated by a participant is transmitted as a separatemessage to each other participant. However, the starnetwork topology means that each of these messagespasses over the same network link from the partici-pant to the central hub before being routed outwardsto the other participants. Audio, on the other hand, ishandled by the RAT application via a central audioreflector running at the hub. This means that eachaudio message is sent just once from the participant


Fig. 2. How application messages concentrate on network links.

to the hub before being routed onwards. In summary,the traffic from each outlying node towards the hubconsists of three messages for every movement, threemessages for every manipulation and one messagefor every segment of speech. The reverse traffic fromthe hub outwards consists of the movement, manip-ulation and speech messages from each of the otherthree participants. This is summarised in Fig. 2.

At this point it should be possible to predict thenetwork traffic that would be generated by a givensequence of events. This can be validated by re-running recorded event logs though the applicationbehaviour model and comparing the predicted trafficagainst that actually measured. An example of thisis shown in Fig. 3. This figure is concerned with thenetwork traffic that was transmitted from the node atNottingham to the central hub at UCL throughout a

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

0 200 400 600 800 1000 1200

Ban

dwid

th (

bits

/sec

ond)

Time (seconds)

Actual and predicted traffic from Nottingham, with breakdown of prediction

actualpredicted

audiomovement

manipulationjoin

Fig. 3. Validation of the application behaviour model.

seventeen minute period during one of the trials. Thegraph shows a close correspondence between thepredicted traffic from our system behaviour model(upper dashed line) and that measured by tcpdump(upper solid line). It also shows the contributionsof different traffic types to our prediction (i.e., au-dio traffic, movement traffic, manipulation traffic andserver traffic). After an initial burst of server trafficcaused by entering the world, the graph shows in-termittent movement from about time 130. Betweentime 300 and 850 the participants are playing thespreadsheet game and so there is a burst of manipu-lation traffic.

4.3. Network traffic model

So far, we have demonstrated how network band-width usage is tied directly to user activity by cor-rectly predicting the observed network usage basedsolely on high-level network- and platform-indepen-dent knowledge of user activity (moving, manipula-tion, speaking). Using the same understanding of theplatform as the example above, a statistical model ofuser behaviour gives rise to a linked statistical modelof network bandwidth requirements.

This model predicts the mean and peak levels oftraffic that might be expected on a given link for agiven number of participants. In general the meantraffic will be generated by average levels of useractivity as identified in the user behaviour model. Incontrast, peak traffic will be generated by maximumpossible user activity, such as when users are contin-ually speaking and moving (the application does notallow simultaneous movement and manipulation).

These two observations allow us to determine thetraffic that will be generated by each participant.To do this we combine the frequencies of action(average or continuous) with the sizes of individualevent messages (from Section 4.2). The final stepis to consider how the traffic that will be generatedby N participants will be concentrated onto differentlinks of the star network topology. Fig. 2 showshow this works for four participants, both for traffictowards and away from the central hub. This can begeneralised to N participants.

Fig. 4 summarises how predicted traffic varieswith number of participants according to this model.The figure plots four curves (on a log–log scale). The


1000

10000

100000

1e+06

1e+07

1e+08

1 10 100 1000

Ban

dwid

th o

n lin

k (b

its/s

)

Number of participants

Average and peak link bandwidth for varying numbers of participants

peak outpeak in

average outaverage in

2B ISDN

Fig. 4. Peak and mean bandwidths predicted for varying numbersof participants.

topmost curve represents the predicted peak trafficflowing out from the hub and the next line downthe peak traffic flowing into the hub. The lower pairof lines predict the mean traffic from and towardsthe hub. Also shown on the graph is the bandwidthprovided by two bonded ISDN channels as used inthe trials.

The graph suggests that if mean traffic were thesole consideration, then we might allow for up to tenor eleven simultaneous participants using the busi-ness game application over ISDN. However, levels ofactivity which suddenly exceeded the average wouldproduce sudden peaks in traffic, causing congestionand degraded performance. In the worst case, thatof continual activity, ISDN could only support twosimultaneous users, the limitation being the peaktraffic away from the hub.

4.4. Broader observations

Based on this analysis of network traffic for theCOVEN business application, we can (with caution)make some observations concerning the general net-work traffic characteristics of CVEs.

First, predicted and observed network traffic isvery bursty (i.e., there may be very large peaksin relation to the mean). Where bandwidth is thelimiting factor then it is inappropriate to design tothe average anticipated volume of traffic.

Second, the user model and hence predicted traf-fic exhibits a strong dependence on both the individ-ual participant and the nature of the task. Speaking

is negatively correlated (i.e., people tend to avoidoverlapping speech). However, multiple simultane-ous speaking is not an exceptional event. In otherwords, one couldn’t provision a CVE on the assump-tion of a single speaker at a time. In contrast, bothmovement and manipulations are positively corre-lated (i.e., they are typically performed in groups).

Third, for peer-to-peer unicast CVEs running overa dedicated non-mesh network topology, then thepeak incoming traffic from each participant’s node toa central hub becomes the first limiting factor as thenumber of participants increases. The use of multi-casting reduces this by removing duplicate inboundmessages which are being sent from one peer tothe hub before being routed to the other peers. Thenext limiting factor will be peaks in outgoing trafficfrom the hub to individual participants. Statisticalmultiplexing may reduce the effective peaks (e.g.,for speech) but validating this will require a moredetailed understanding of how users’ activities arecorrelated. In order to further reduce traffic, clientswill need to delegate key functions to central servers(e.g., compression, spatialising audio, etc.). How-ever, this will increase CPU load at these servers.

Finally, high-bandwidth individual links (e.g., us-ing ATM) can in theory support hundreds or eventhousands of participants in terms of peak traffic.However, other issues are likely to become bot-tlenecks long before this (e.g., local and centralprocessing load and core network bandwidth).

5. Summary

As CVEs emerge from the research domain to-wards commercial deployment, so the issue of ser-vice provisioning will become increasingly impor-tant. This paper has outlined a method for predictingthe network traffic that will be generated by differentCVE applications with different numbers of users.This method involves capturing event log and traf-fic measurement data from user trials. This data isanalysed in three stages. First, statistical analysis ofevent logs results in a model of user behaviour whichidentifies the average frequency of occurrence ofdifferent events (e.g., moving, speaking and manipu-lating) as well as their degree of correlation. Second,we establish a model of application behaviour which


identifies the messages that are generated by a givensequence of events and also the way in which theybecome concentrated on different links of a givenunderlying network topology. Third, we combine thefirst two models to produce a model of networktraffic that predicts the mean and peak volumes oftraffic on a given network link that would be gener-ated by different numbers of participants using theapplication.

We have described the application of this methodto a CVE application that has been developed as partof the COVEN project (EU ACTS programme). Thisapplication has been used in an extended series oftrials between four partners over a dedicated ISDNnetwork.

Finally, we have made a number of more generalobservations concerning the nature of the networktraffic that will be generated by CVEs. A key ob-servation concerns the burstiness of the traffic. Ingeneral, network providers must carefully considerthe relationship between likely mean and peak levelsof traffic. Beyond this, we have considered the roleof techniques such as multicasting, statistical multi-plexing and the use of client-server architectures tofurther reduce network traffic as well as the poten-tial of high-bandwidth technologies such as ATM tosupport very many participants using a CVE.

Acknowledgements

We gratefully acknowledge the EU’s ACTS Pro-gramme for supporting the COVEN project.

References

[1] B. Damer, Demonstration and guided tours of virtual worldson the Internet, CHI ’97 (demonstrations), Atlanta, US, 1997.

[2] C. Greenhalgh, S. Benford, MASSIVE: a virtual reality sys-tem for tele-conferencing, ACM Trans. on Computer HumanInteraction, 1995.

[3] C.M. Greenhalgh, Analysing movement and world transi-tions in virtual reality tele-conferencing, Proc. ECSCW ’97,Lancaster, UK, September 1997.

[4] C.M. Greenhalgh, A.N. Bullock, J.G. Tromp, S.D. Benford,Evaluating the network and usability characteristics of virtualreality conferencing, Br. Telecom Technol. J. (BTTJ), Spec.Issue on Shared Spaces, 15(4) (1997).

[5] C. Grimsdale, dVS-distributed virtual environment system,

Proc. Computer Graphics ’91, London.[6] V. Hardman, A. Sasse, M. Handley, A. Watson, Reliable audio

for use over the Internet, Proc. Inet ’95, June 1995, Honolulu,Hawaii.

[7] N. Kuipers, H. Jacobs, Teleconferencing and collaboration invirtual environments, HPCN Europe ’97, April 1997, Vienna,Austria.

Chris Greenhalgh (B.A., Ph.D.) isa lecturer in computer science atthe University of Nottingham. He isthe creator of the MASSIVE-1 andMASSIVE-2 multi-user distributedvirtual reality systems. His interestsinclude distributed systems, CSCWand large scale collaborative virtualenvironments.

Steve Benford (B.Sc., Ph.D.) is aprofessor in computer science at theUniversity of Nottingham. His inter-ests include CSCW, HCI and dis-tributed systems and their integrationin collaborative virtual environments.

Adrian Bullock (B.Sc.) is a researchassociate in computer science at theUniversity of Nottingham. His inter-ests include security and access con-trol and he has extensive experienceof networked virtual reality trials us-ing a variety of systems.

Nico Kuijpers is a member of the sci-entific staff in the Command and Con-trol and Simulation Division at TNO-FEL. He is project leader for sev-eral collaborative projects in the areasof collaborative virtual environmentsand distributed simulation, both na-tionally with partners in Dutch indus-try and academia, and internationallywithin European research programs.He holds an M.Sc. in computer sci-ence from Eindhoven University of

Technology and a Master of Technological Design in softwaretechnology, also from Eindhoven University of Technology.


Kurt Donkers is a member of thescientific staff in the Command andControl and Simulation Division atTNO-FEL. He is software architectfor several collaborative projects inthe areas of collaborative virtual en-vironments, simulation and visuali-sation, both nationally with partnersin Dutch industry and academia, andinternationally within European re-search programs. He holds an M.Sc.in computer science from Delft Uni-versity of Technology.

predicting network traffic for collaborative virtual environments

Documents