Del Territorio

The TCP fairness of the bandwidth utilization of the Mongoose client has been measured. The different versions of the Mongoose client with different intervals have been examined and the median values compared to those of the standard Second Life client.

Bandwidth utilization against TCP fair rate. The bandwidth against the TCP fair values for different Mongoose traces are shown in figure 7.13. The top two are per second from the four of the traces and the bottom two show the mean, median and percentile value for different traces. The x-axis is the TCP fair rate and the y-axis is the Bandwidth usage in Kbps. In the top two graphs the red points are for 0.01% loss, the green points are for 0.5% loss, the blue points are for 3% loss and the purple points are for 10% loss. The line is fory=x.

(a) The per second TCP fair against bandwidth for the Mongoose client with no interval between transmissions of throttle values is shown in figure 7.13a. A lot of the points of the same colour are grouped together and then there is a group at the end were the TCP fair value has its maximum value. A large number of the points are above the line.

(b) The per second TCP fair against bandwidth for the Mongoose client with a 5 second interval is shown in figure 7.13b. Less of the points are above the line than in the first graph.

In the per connection graphs in figure 7.13d, the red points are the mean bandwidth values, the blue error bars are the median and percentiles and the green line isy=x.

(c) The per connection TCP fair against bandwidth for the Mongoose client with no interval between transmissions of throttle values is shown in figure 7.13c. At low throttle values the bandwidth values are above the TCP fair values.

0

200

400

600

800

1000

1200

1400

1600

0

1

2

3

4

5

6

Loss (%)

SL Throttle 1500Kbps

TCP rate equation

0

200

400

600

800

1000

1200

1400

1600

Bandwidth (Kbps)

Window Tracking zero delay

TCP rate equation

0

200

400

600

800

1000

1200

1400

1600

1800

Window Tracking 5 second delay

TCP rate equation

(d) The per connection TCP fair values against bandwidth values for the Mongoose client with a 5 second interval is shown in figure 7.13d. The low value are closer to the line than in the other graph. The client with a sending interval is able to keep the bandwidth within the TCP fair range.

The TCP fair throttle values calculated by the client is able to produce a sending rate that is TCP fair.

Bandwidth utilization against Loss rate. The bandwidth against loss rate for the Mongoose and Second Life clients is shown in figure 7.14. The Second Life client’s throttle value was set to an initial value of 1,500 Kbps. The points are box plots are of the median, the 25 percentile and the 75 percentile of bandwidth utilization. The green line is the TCP fair equation value.

Bottom The values for the Second Life client are shown in the bottom graph. At very low loss levels the Second Life client is TCP fair. The rate is not TCP fair for loss rates over 0.5% it is not TCP fair.

Middle The middle graph shows the values for the Mongoose client with no calculation interval. This version is closer to the TCP fair line, with the median values not being over the line until 3% loss. The values over the line are closer to the line than the values for the Second Life client.

Top The top graph shows the Mongoose client with a five second calculation interval. The values are closer to the line than the values for the zero interval client. The percentile values are closer to the mean value than in the other too graphs, except at the maximum values. The values for over 3% loss are still over the line, but they are much closer to the line than the interval-less client.

This demonstrates that it is possible to increase the adaptiveness of SL so that it can take advantage of the improved performance available in high bandwidth low congestion environments and automatically adjust to a lower bandwidth utilisation in the presence of congestion. This is achieved, without the need to alter the servers at all.

7.6

Conclusion

The methodology was to perform experiments with real connections connected to the Second Life servers across the Internet and to change the network conditions and record the traffic.

The throttle values calculated by the Second Life client and the Mongoose client were compared with TCP fair and TFRC. The Second Life values were not equal to the TCP fair values, as they make no attempt to be. The Second Life values are also above the TCP fair values in several different circumstances. The Mongoose values are close to the TCP fair values. The Correlation between the throttle value and the loss was calculated for both clients. The Second Life clients had very little correlation in the wrong direction. The Mongoose client had more correlation in the correct direction.

The window tracking system used by Mongoose was compared with TFRC. The median TFRC values are close to the TCP fair values for the average levels of loss. Simulations of window tracking systems and equation based congestion control systems were performed. The window tracking systems converges on the correct values more quickly than the equation based system. Traces of Mongoose traffic, with its window tracking system confirm these results. The window tracking system is therefore appropriate for Mongoose.

The affect of the throttle value on the amount of bandwidth used by the Second Life server was investigated. The Mongoose client with no interval between sending new throttle values to the server had only limited success in controlling the bandwidth utilization. A client with an interval of 5 seconds was tested. The calculated throttle values were compared to TCP fair, the values were a little less close to TCP fair than the zero interval client but still close to TCP fair. The bandwidth utilization are close to the throttle values or they are lower. Different intervals were tested and 5 seconds seems like a reasonable interval.

The TCP fairness of the bandwidth utilization that the Mongoose client results in was tested and found to be in the correct range.

In Summary: The Mongoose client is able to react to loss and calculate a rate that is TCP fair. The Mongoose client is able to control the bandwidth used by the server. The version of Mongoose with no interval is able to calculate a rate correctly but is unable to control the bandwidth used by the server. The Mongoose client with a five second interval in the calculation of the throttle value calculates a throttle value that is TCP fair and is able to control the bandwidth.

Chapter 8

Traffic Management with OpenSim

This chapter looks at traffic management for OpenSim a toolkit for creating virtual worlds that are compatible with Second Life servers. As OpenSim servers are freely available and open source this facilitates investigation of both the client and server side aspects of traffic management for virtual worlds. This in turn allows the constraint that only changes to the client are investigated, to be relaxed. It is reasonable to relax this constraint as it is possible for Linden Labs to implement modifications to Second Life’s [115] server and there is increasing use of OpenSim. Using OpenSim [132] we were able to run, measure, modify and evaluate a virtual world server. In doing so it was possible to both investigate how a client and server can co-operate together to ensure TCP [160] fair [146] behaviour as well as exploring how network bandwidth should be distributed between different traffic types within the application.

Original contributions in this chapter include: a study of OpenSim network traffic, the design and evaluation of TCP fair congestion control for OpenSim and server side traffic control which both adapts to requests from the client for aggregate bandwidth and distributes that bandwidth between traffic types. Real-time measurements are used to determine network conditions and these measurements are used as parameters to traffic management algorithms. The client measures packet loss and RTT to determine a TCP fair rate which is requested from the server. The server side system combines two level token buckets with proportional fair queuing to regulate data transmissions.

The OpenSim server uses the same network protocol as Second Life and provides a virtual environment that is similar to that provided by Second Life. Although OpenSim uses the same protocol as Second Life the bandwidth requirements and traffic mix may differ substantially. This chapter opens with a measurement study of OpenSim traffic, this looks at the bandwidth required for a range of common activities, bandwidth requirements for different OpenSim “islands” and packet size distributions. The OpenSim server can be managed and administered by institutions like other types of server. There are also facilities for modifying the server, new modules providing additional functionality may be developed and added. From a development stand point OpenSim has the advantage that it is open-source so can be modified, as can the Second Life client (SLC) [112].

The Mongoose client was created to control the bandwidth usage of the Second Life server. Here its interaction with the OpenSim server is evaluated. In the light of this evaluation modifications to the OpenSim server are proposed, implemented and evaluated. This chapter is organised into the following sections:

Section 8.1: The design priorities of an OpenSim traffic management system.

Section 8.2: A measurement study of the traffic from OpenSim.

Section 8.3: The examination of OpenSim traffic and throttle system.

Section 8.4: A description of OpenSim and the design and implementation of the modified OpenSim throttle system.

Section 8.5: The measurements of the bandwidth and throttle values with the modified OpenSim server.

Section 8.6: A comparison of the two client versions and the two server versions.

8.1

Traffic management system

There are a number of metrics that measure the quality of service that a connection receives from the network. The throughput is the amount of data transferred per unit time. The rate of packet loss is also important, it will affect the throughput. Network delay is also important as it affects the responsiveness of the system.

Environments such as Virtual Worlds have similar timeliness requirements to 3D games123_{. In addition when the} world has to remain consistent the input often has to be sent and response received before the user input has an effect on the environment. As a result there are limits on the level delay and variation in the delay that can be tolerated by the user. In MUVEs such as Second Life [115] the user can move around in an environment even when only some of the information, necessary to render the environment, has been transferred to the client.

In Second Life and OpenSim traffic is separated into different channels each channel has its own queue, and there is a scheduling system which controls when the packets in each queue are sent. These scheduling algorithms attempt to achieve the desired weighting between the different queue, without having a large detrimental effect on the performance of the system. A fair queueing system attempts to maximise the minimum bandwidth that each of the flows, or channels, is able to achieve. If the packet size is taken into account then flows with small packets get an equal opportunity to transmitter data.

A system to control OpenSim’s traffic should react to network conditions by changing the rate at which packets are transmitted. It should be TCP fair. The existing system involves the client determining the rate at which the server is to send data and sending this information to the server, which then caps its data transfer rate. The client side is the same system that Second Life uses, the server is different. In previous chapters modifications to the client were proposed which involved modifying the client to detect loss and measure the round trip time and uses these values to calculating a TCP fair sending rate, which is then requested as a cap.

The current channel system separates different types of data into channels, each channel receives a separate bandwidth allocation. However, the channels are not arranged by the Quality of Service requirements of the traffic. Modifying the client and the server makes it possible to change the channel system so that QoS requirements are better met.

There are three main types of data, avatar control traffic, data which defines the shape of objects and data which defines the surfaces of objects. In addition there is data which defines the land, trees and wind. If a user’s avatar does not respond to input promptly the interactivity and immersiveness of the system will be reduced. The bandwidth necessary for avatar traffic is low, a few kilobits per second for each avatar. Thus avatar traffic has a low bandwidth requirement and high requirement for timeliness. This suggests that it should be prioritised. Prim traffic defines the shape or structure of objects. This traffic has a higher bandwidth requirement than avatar traffic, but is not as critical for interactivity. Texture traffic, consists of images which are used to provide realistic surfaces for objects. Textures have a higher bandwidth requirement, but a lower priority than prim traffic.

In the current channel structure the Task channel contains the information about avatars and information about Prims. Images are dealt with by a separate Texture channel. There is a Resend channel, which contains all of the re-sent packets, this results in Texture, Land, Asset and Task packets getting mixed together. The different types of packet then cannot be given different amounts of bandwidth when it comes to resending them. An improved channel system would separate the Avatar and Prim traffic:

1. Asset: Containing the contents of the Asset channel. 2. Avatar: Containing all of the avatar traffic.

3. Task: Containing the remainder of the Task channel. 4. Layer: Containing the Wind, Land and Cloud channels. 5. Texture: Containing the contents of the Texture channel.

With the re-sent packets belonging to the same channel as the original sending of the packets. With the avatar traffic having a separate channel it will be possible to guarantee it bandwidth. A channel system implementation based upon this design and compatible with the current SL protocol is described in sub section 8.4.1.