INTERACCIÓN CON LAS MUJERES

The future work is to evaluate this modified server under different network conditions.

B.5

Conclusion

A traffic management system using a modified client and server has been designed to be TCP fair. This system uses a modified channel system which protects the avatar traffic from the other traffic. This system uses the USDL implementation of DCCP to provide the congestion control system, with a modified congestion control system that gives more information to the server. The channel throttles are set depending on the amount of bandwidth to use to provide differential QoS to the different types of packets.

The design is to create C# bindings for the USDL library to integrate it into the OpenSim server. The client is modified to use the USDL library. The USDL library has been evaluated to determine that is able to handle sufficient traffic to be used for this propose.

A modified server where the throttle values are calculated at the server end of the connection would be able to adapt more quickly and would have less problems with a misbehaving client. A system has been designed that uses an implementation of DCCP to provide the throttle values. This designed system has been implemented and is able to function. The DCCP implementation has been tested and is able to handle the required amount of bandwidth.

Appendix C

User Level DCCP

The Internet provides an unreliable service for transferring packets of data. When the number of packets sent onto the network exceeds its ability to transport those packets the network becomes congested and packets can be lost. The introduction of reliability at the transport layer meant that when the network was most congested the amount of load on the network would increase until very little or no traffic across the network. In 1986 Jain [85] described a system to detect congestion on a network and prevent congestion collapse, with this system when a packet is transmitted a timer is started, if the packet has not acknowledged within an amount of time the packet is considered to have been lost, this is taken to indicate that network is congested. A variable called the window size (WS) limits the number of packets that are in flight in the network at anyone time. When a packet is lost the WS is reduced to one. For every N successful packet transmissions the WS is increased by one, up to the window specified by the other direction. This paper however advocates the use of a congestion control system where the window size is reduced to one when a packet is lost, because when packet loss occurs the number of network and router queues are all full and will take some time to empty. In 1988 Jacobson described a congestion control system designed to reach a steady state of packet send, for networks without changing conditions. To get to this state the connection starts in the slow start phase were the window starts at one packet and increases by one for each acknowledgement received. When packets are lost a variable SSTHRESH is set to half the congestion window and the congestion window is set to one packet. The connection then enters slow-start, until the congestion window is greater-than or equal to SSTHRESH, the connection then enter the congestion avoidance stage. In the congestion avoidance stage the window size is increased by one over the window size for each acknowledgement received.

TCP provides reliable data transfer and has congestion control implemented on top of it. This provides the service required by a large number of the applications that the Internet is used for and by providing congestion control it prevents congestion collapse on the Internet. TCP provides reliable in order and byte stream oriented data delivery, it is good for applications that require to transfer large amounts of data without time constraints. As it provides in order delivery if data is lost it must be re-sent before any data after it is available to the application. For applications where latency is important, and reliability is not essential UDP [156] has been commonly used. UDP does not provide reliability or congestion control, so packets that are lost are not retransmitted and data is delivered to the application out-of-order and with gaps, as it arrives. This allows the applications to meet their timing constraints however it doesn’t prevent congestion on the network. To avoid congestion such applications employ a number of techniques. Some systems limit their traffic to set level or attempt to reduce the amount of traffic that is to be sent over the network so that there is no need for congestion control. They may alternatively use a congestion control system at a level above the transport level.

Congestion control at the application level could be implemented using a system unique to the application, for media streaming there is an existing protocol, RTP in conjunction with RTSP, that provides sufficient feedback for the application to implement its own congestion control system. RTP provides payload type identification, sequence numbers, time-stamping and delivery monitoring. There is also a proposal to include TFRC in RTP [66].

An alternative to implementing congestion control at the application level is to implement congestion control at the transport layer. DCCP [99] is a relatively new protocol that provides congestion control without requiring that data transfer is reliable or in the correct order. In [55] the problem statement for DCCP is described. As well as providing congestion control DCCP is intended to work with network address translators (NAT) and firewalls, this is possible as it is a connection oriented protocol. There are a number of implementations though currently only the Linux kernel space version is complete. Creating user space libraries is less complicated than creating and editing

kernel space modules as crashes are less of a problem and there are more tools available. DCCP is designed to allow for a number of different congestion control mechanisms. To aid in the development and evaluation of new congestion control mechanisms it was decided to create an implementation of DCCP in user space. This implementation will allow DCCP to be used on operating systems that currently lack support for DCCP. It has so far been used on both Linux and FreeBSD without DCCP support installed and Linux DCCP with DCCP support.

The structure of the rest of this chapter will have the following structure:

Section C.1: DCCP will be described.

Section C.2: User space implementations are described.

Section C.3: The library is described.

Section C.4: The processes that happen in the library are described.

Section C.5: The evaluation of the library is described.

C.1

Datagram Congestion Control Protocol (DCCP)

DCCP is a transport level protocol that provides congestion control, without reliability. In [55] the problem statement for DCCP is described. As well as providing congestion control DCCP is intended to work with network address translators (NAT) and firewalls, this is possible as it is a connection oriented protocol. [99] is the RFC that describes DCCP.

RTP also includes sufficient feedback about packet loss that an application could use it to control its packet transmission rate. RTP, on its own, does not include a mechanism for sending feedback to the sending end of the connection. DCCP’s purpose is to provide congestion control to applications so that they do not need to implement their own congestion control system. If the features provided by RTP are required there is a specification for RTP over DCCP [151].

RTP [172], in conjunction with RTSP [173], can provide information to the application about the state of the network. This information can be used for the application to implement its own congestion control system. RTP provides payload type identification, sequence numbers, time-stamping and delivery monitoring. This allows an application to react in the way that best suites their needs rather than rely on a congestion control system that does not meet the needs of the application. The application will however need to implement its own congestion control system, or use a library. DCCP provides congestion control to the application with very little effort from the application. RTP was originally intended for use in situations where it would not have to deal with congestion. It was therefore not designed to include congestion control systems. DCCP was designed to provide congestion control. The design of DCCP keeps the monitoring of packet loss and reacting to congestion out of the application and in the implementation of the protocol. The features that DCCP has to support congestion control were not designed for any specific type of congestion control, instead they were designed to be capable of supporting different types of congestion control. This allows new congestion control systems to be created for DCCP and used by applications without large or any changes to the application.

In [100] DCCP is described as well as the reasons for its creation. Currently applications that require packets to be delivered within certain time constraints or not at all have used UDP [156] as it allows packets to be delivered out-of- order and not at all, however it does not provide any type of congestion control so applications either implement their own or have no congestion control mechanism. Applications in userspace can also use an application level protocol such as RTP [172] to provide the necessary infrastructure to allow congestion control, possible with TCP friendly rate control [66]. The purpose of DCCP is to provide congestion control to applications that would otherwise use UDP, allowing them to get feedback about packet delivery without having to implement acknowledgement or congestion control systems. The requirements of different applications on a congestion control system are different, for this reason DCCP was designed so that new congestion control systems can be added to it.

DCCP includes support for Explicit Congestion Notification (ECN) [163] which allows routers to mark packets instead of dropping them to indicate that it is congested. The sender must then be informed that a marked packet was received. As packets are marked instead of being dropped the congestion control system should react as if marked packets had been dropped. In TCP [160] [45] the use of ECN must be negotiated before it is used, as ECN was created after TCP, so support cannot be assumed to exist. DCCP however was created after ECN, so the default is to assume

that both ends of a connection can inform the other end when marked packets arrive. Implementations of DCCP can however indicate that they are unable to access the ECN bits of packets.

Currently DCCP has two congestion control systems. The default is TCP-like congestion control [57] that provides a congestion control system similar to the one used by TCP as is described in [4]. This allows applications to receive as much bandwidth as possible, whilst having similar behaviour to TCP’s congestion control. It also has many of the other properties of TCP, in that it favour’s bandwidth over other quality of service parameters. It does not provide reliability and ordering so the application gets the packet as it arrives rather than having to wait for any more packets to arrive. This congestion control system is not intended to affect delay or jitter. It is intended to reduce loss due to congestion, whilst maximising available bandwidth so by design it does not minimise the variation in the available bandwidth, rather it rapidly changes the amount of available bandwidth.

DCCP includes service numbers that indicate the type of application level traffic is carried, if this is used correctly this will allow priority to be given to certain types of traffic without the need to perform traffic classification [13].

Currently DCCP has two congestion control systems. The default is TCP like congestion control [57] that provides a congestion control system similar to the one used by TCP, which is described in [4]. This allows applications to receive as much bandwidth as possible, whilst having similar behaviour to TCP’s congestion control.

The other congestion control system is TCP-Friendly Rate Control (TFRC) for DCCP [58], which provides a smoother rate of packet transmissions whilst remaining TCP friendly, at the expense of not achieving the maximum possible speed. TFRC is described in [72].

The Linux implementation is intended to be integrated with a congestion manager [8], there also a plan to integrate the library with a congestion manager.

DCCP is able to deal with the amounts of bandwidth that MUVEs, in general use and Second Life in particular, use. It is designed to be able to support new congestion control systems so it will be possible to add a congestion control system that meets the particular needs of MUVEs. Its similarity to UDP will mean that it will take less alteration to change the existing systems to use UDP. With a user space implementation it will easier to develop a new congestion control system that has the desired properties works correctly. With a user space implementation it will be possible to more closely integrate the implementation with client and server, this will allow the interface to be changed to allow information to be exchanged between the application and the protocol implementation. It will also allow DCCP to be used on systems that do not currently support DCCP.