Self-Management of Optical Switching

byWouter Kooij

supervisors:Giovane C. M. Moura,

Aiko Pras,Pieter-Tjerk de Boer

University of TwenteEnschede, The Netherlands

Bachelor assignment, December 6, 2011B.Sc. Telematics

Abstract

The Transmission Control Protocol (TCP) is a protocol that is widely deployedin most IP networks. It is the main protocol on the transport layer on theInternet. Also, it is a stateful protocol.

Optical switching, on the other hand, is a technique that will be employedmore and more in the future. This technique provides the moving of ongoingTCP flows from the IP level to established lightpaths on the optical level. Cur-rently a switch is performed manually. However, in the future, autonomic opticalswitching will be used more often to move ongoing TCP flows on demand.

In this report an analysis is provided of what could happen when movingTCP flows on-the-fly. The impact on several TCP congestion control algorithmsare examined, namely TCP Reno, Vegas, Compound and Cubic.

Contents

1 Introduction 31.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Optical Communications and Optical Switching 72.1 Optical Communications . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 WDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 SONET/SDH . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Optical Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Self-management of Optical Switching . . . . . . . . . . . . . . . 112.3.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 TCP Congestion Control Algorithms of Choice 123.1 Basic Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 TCP Congestion Control Phases . . . . . . . . . . . . . . . . . . 143.3 Congestion Avoidance Algorithms . . . . . . . . . . . . . . . . . 15

3.3.1 TCP Reno . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.2 TCP Vegas . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.3 TCP Compound . . . . . . . . . . . . . . . . . . . . . . . 173.3.4 TCP Cubic . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Simulation and Results 204.1 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3 Simulation results . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3.1 Scenario A and 100 Mbps results . . . . . . . . . . . . . . 224.3.2 Scenario A and 1 Gbps results . . . . . . . . . . . . . . . 234.3.3 Scenario A and 10 Gbps results . . . . . . . . . . . . . . . 254.3.4 Scenario B and 100 Mbps results . . . . . . . . . . . . . . 264.3.5 Scenario B and 1 Gbps results . . . . . . . . . . . . . . . 26

1

4.3.6 Scenario B and 10 Gbps results . . . . . . . . . . . . . . . 274.4 Practical Experiment . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Conclusions and Future Work 305.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Bibliography 33

A Appendix 35A.1 Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

A.1.1 Scenario A . . . . . . . . . . . . . . . . . . . . . . . . . . 35A.1.2 100 Mbps throughput . . . . . . . . . . . . . . . . . . . . 35A.1.3 1 Gbps throughput . . . . . . . . . . . . . . . . . . . . . . 37A.1.4 10 Gbps throughput . . . . . . . . . . . . . . . . . . . . . 38A.1.5 Scenario B . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.1.6 100 Mbps throughput . . . . . . . . . . . . . . . . . . . . 40A.1.7 1 Gbps throughput . . . . . . . . . . . . . . . . . . . . . . 41A.1.8 10 Gbps throughput . . . . . . . . . . . . . . . . . . . . . 43

2

Chapter 1

Introduction

1.1 Problem Description

In current data networks, the use of optical data transferring is becoming moreimportant and widespread. This is because moving data over the optical levelhas some advantages when compared to moving data over the IP level. Theseadvantages are [1] [2]:

1. IP layer 3 router resources and time can be saved. Moving large IP flowsto the optical level allows for bypassing per hop routing decisions at theIP level, which is layer 3 in the OSI model [3]. This makes it possible tooffload the IP network and save more resources for smaller IP flows. Thisis a major advantage, since IP routing is a major bottleneck in the currentInternet .

2. Optical flows provide a better Quality of Service (QoS). An optical dataflow usually has a larger bandwidth than a data flow at the IP level. Alsothe variance in delay (jitter) is negligible in optical data transfer.

To be able to move these IP flows to the optical level, a technique calledoptical switching is used. This basically bypasses the IP routing decisions atlayer 3 and delegates this to the optical level at layer 2, which is the Data LinkLayer in the OSI model [3]. At the layer 2, there is an end-to-end connectionbetween two nodes. This means that packets have a fixed source and destination.This removes the need to look at the destination of individual packets at thismoment, since all packets in one flow have the same direction anyway. Whenpackets have finished traversing the optical path, routers look at the IP headerinformation inside the packet and route this packet accordingly.

There are two ways of performing optical switching. The first method is tohave a network manager manually select flows to be switched. The other way isto have the switching performed automatic, for example based on the flow size.The latter is desired for creating self-management systems, which is becomingmore and more important nowadays.

When performing a switch, an ongoing data flow that is currently beingtransferred is affected. For example when a switch is performed, packets travers-ing the optical path right after a switch might arrive a lot earlier at the receiver

3

than packets that took another route over the IP level. Another problem is thatpackets might get lost at the switch. This can cause trouble at the receiver, i.e.the throughput might decrease at that moment.

Connection-oriented data flows are most affected by this, because these flowsset up a connection that maintains a status of the connection. Switching mightcause the connection to change its status, with all consequences attached to it.In this report, the effect of a switch on an ongoing Transmission Control Pro-tocol (TCP) [4] flow is investigated. TCP is connection-oriented and the mostwidespread protocol used in the Internet [5].

The TCP protocol has mechanisms to deal with packet loss and congestion.These mechanisms consist of a so called congestion control algorithm. Thecongestion control mechanism determines how congestion should be avoidedand dealt with. In this report, several TCP congestion control algorithms andthe effect of a switch on them are examined.

1.2 Research Questions

The main research question addressed in this report looks at the how severalTCP congestion control algorithms deal with and react to a TCP connectionswitch when moving on-the-fly TCP flows. This makes packets use layer 2switching instead of layer 3 routing. This research question should lead to aclassification of the chosen congestion control algorithms to which extent theyprovide resistant against an optical switch.

With this knowledge the performance of a TCP connection in the case ofswitching TCP connection to the optical domain can be better predicted. Tobetter illustrate that, consider the case of a user downloading a 25 GB file.Knowledge about which TCP congestion control algorithm is used could pro-vide insight in whether optical switching would have a positive effect on thethroughput speed and thus the user experience. To answer the main researchquestion a few sub questions are formulated. This section states and explainsthe research questions. The main research question:

- How do different TCP congestion control algorithms react to autonomic opticalswitching?

As mentioned before, switching a TCP connection onto the optical domainmight be paired with packet loss and reordering of packets. The congestioncontrol algorithm will then decide how packet loss is dealt with. To be able toanswer the main research questions, several sub-questions need to be formulated.These questions should provide insight and knowledge to be able to answer themain research question. The sub questions are:

1. What exactly happens to a TCP connection when performing an opticalswitch and why is this happening?To be able to understand how certain congestion control algorithms reactto optical switching, it is important to understand what is actually goingon when switching a TCP connection onto the optical domain.

4

2. What are fundamental differences in how congestion control algorithmsdeal with congestion, packet reordering and packet loss?To understand the behavior of a congestion control mechanism it is neces-sary to know how each congestion control algorithm deals with congestion,packet reordering and packet loss.

3. How is the throughput of an established TCP connection with differentcongestion control algorithms affected after an optical switch and why?Each congestion control mechanism deals in another way with congestionand packet loss. Therefore, throughput of a TCP connection after anoptical switch is most likely to be affected differently for different conges-tion control algorithms. This is a major indication for how resistant acongestion control algorithm is against optical switching.

4. Which TCP congestion control algorithms are most resistant to opticalswitching?Based on the answers of the previous research questions, a classificationof the most resistant TCP congestion control algorithms of the examinedalgorithms can be created.

1.3 Approach

To be able to answer sub questions 1 and 2, a literature study has to be per-formed. RFCs and papers can provide insight in this matter. To answers subquestion 3, a NS-2 (Network Simulator) simulation has to be performed [6].This program allows for the setup of virtual networks and virtual wires in be-tween. Also it is possible to perform the simulation with different congestioncontrol algorithms. NS-2 makes use of the actual code in the Linux kernel foreach congestion control algorithm. The version of NS-2 that is used is 2.33. Theapproach used is depicted in figure 1.1.

Figure 1.1: The approach used.

5

1.4 Related Work

This report is an extension to [7], where the impact of optical switching on TCPCubic has been researched in 4 scenarios. In this report more congestion controlalgorithms are examined, however only 2 scenarios are used (scenario A and Bin this paper correspond with scenario C-1 and scenario D in [7] respectively.

1.5 Outline

Chapter 2 provides a theoretical background on optical switching. It explainswhat optical switching is, how and where it can be used.

In chapter 3 information about different congestion control algorithms andhow these algorithms work is provided. Also, typical behavior of these algo-rithms is analyzed and based on this, a prediction is made how these algorithmsshould react on an optical switch.

Chapter 4 focuses on the executed simulation. This includes both infor-mation about the setup of the experiment and on results of the experiment.In this part, plots of the simulation results are provided. Also an analysis ofthe obtained results is given here. Next, in chapter 5, conclusions regardingthis work are provided. This includes answers to the research questions andrecommendations. Finally, in chapter 6 information regarding future work isprovided.

6

Chapter 2

Optical Communicationsand Optical Switching

2.1 Optical Communications

2.1.1 Definition

In this chapter more information regarding optical switching is provided. Thisincludes an explanation on how this technique works, its current status, infor-mation regarding self-management and examples.

Optical communications are very different from electronical communications.In electronical communications, electronical pulses are used for transmittingsignals over an electrical wire. On the contrary, optical communications makeuse of light pulses for transmitting signals over an optical fiber. Optical fibershave several advantages over electrical wires, as will be explained later on. Theirmain advantage is the increase in bandwidth.

Light does not travel in a fiber in a way that electricity does in a wire.Light is an electromagnetic wave and optical fiber is a waveguide. This hasseveral consequences. For example, this makes it difficult to do a simple thingas coupling two fibers. Connecting an optical connection with an electronicalconnection is even more difficult.

Optical fibers have been widely deployed to create high-speed links [2]. Thiswas done because optical fibers are suitable as a transmission medium becausethey provide several benifical properties [2] [8], such as:

1. Low attenuation. This means that the signal can traverse large distanceswithout the need to replenish the signal often. The precise attenuationloss of the fiber depends on the wavelength used. Figure 2.1 shows theattenuation of an optical fiber as a function of the wavelength. Comparingthis with a standard CAT-5 UTP cable, which has a loss of 2.5 dB up to23.2 dB per only 100 meter [9], depending on the frequency used, thisdifference is enormous.

2. High bandwidth. An optical fiber has the ability of transferring data at veryhigh speed. To give an example of this potential, the Nippon Telegraphand Telephone Corporation gave a demonstration where they managed to

7

transfer data through a single optical fiber at a speed of 69.1 Tb/s byusing a technique called Wavelength Division Multiplexing (WDM). [10].This technique will be briefly explained later on.

3. No electromagnetic interference. Since the fibers are made of silica, theyare not subject to noise created by other electromagnetic devices.

Figure 2.1: Optical fiber attenuation. [2]

2.1.2 WDM

To share the resources of an optical medium, a technique called multiplexingis used. Multiplexing allows a medium to be shared by multiple signals. Themost used multiplexing techniques in optical networks are Wavelength DivisionMultiplexing (WDM) and Time Division Multiplexing (TDM).An overview of WDM is depicted in figure 2.2. WDM allows for signals ofmultiple frequencies to be used at the same time over a single optical fiber.This means that it can concurrently send multiple TCP flows over a singlefiber. TDM on the other hand creates time slots where each signal has its owntransmission time. The current standards in digital communication, SDH andSONET, make use of these techniques.

2.1.3 SONET/SDH

SONET is a set of standards for data transmission over optical networks. Thesestandards allow for framing and synchronization at the physical layer. SONETis standardized by the American National Standards Institute (ANSI).

SDH is the counterpart of SONET and is standardized by the InternationalTelecommunications Union (ITU). Currently, SDH and SONET support stan-dards with a bandwidth rate of up to 160 Gbps.

The previously mentioned benefits depict optical communication as an idealcommunication medium. This raises the question of why electronical communi-cation is still used. There are a few reasons why electronical communication is

8

Optical Fiber

Wavelength 1

Wavelength 2

Wavelength 3

Wavelength 4

Wavelength 5

Multiplexer DemultiplexerSource 1

Source 2

Source 3

Source 4

Source 5

Source 1

Source 2

Source 3

Source 4

Source 5

Figure 2.2: Wavelength Division Multiplexing (WDM)

still a better solution, especially in short distance and low bandwidth applica-tions:

1. Electronical transmission has a lower material cost. More specifically, thetransmitters and receivers are much cheaper for electronical communica-tion.

2. Electronical communication is capable of carrying electronical signal, whichis how most current equipment is designed to connect with. So electronicalcommunication better fits current devices. This is a reason for choosingelectronical communication in some scenarios, because converting fromelectronical to the optical domain is not worthwhile in all cases, becauseit is expensive.

3. Also, splicing (connecting two fibers or wires together) is more difficult foroptical fibers.

Despite of the cost involved, especially for shorter distances, there is a trendgoing on towards the use of more optical communication, also in shorter linksin the network.Replacing the last few kilometers of a communication network is called Fiberto the x (FTTx) and this amount is increasing massively [11]. An example ofthis is the deployment of glass fiber in many cities in the Netherlands, such asEnschede [12].

2.1.4 Overview

This section described optical communication and its (dis)advantages. It canbe concluded that optical communication is not the ultimate solution for everyscenario, mainly because of the cost of the necesary equipment. However foroften used links it is extremely useful.

The next section will explain a technique called Optical Switching. This isthe act of switching an electronical pulse into an light pulse from the electronicaldomain onto the optical domain. The main advantage of performing opticalswitching on a data flow is to alleviate the burden on routers in the electronicaldomain.

9

2.2 Optical Switching

2.2.1 Definition

In the previous section optical communication and the need for optical switch-ing was explained. This section provides more detailed information on opticalswitching.

As mentioned before, optical switching allows an electronical signal to beconverted into an optical signal. Optical switching creates a connection betweentwo end nodes that are connected with optical fiber. When performing theoptical switch the optical path is activated and packets are routed from theentrance of the path straight to the end of the path. This might go via othernodes, but these nodes in between do not need to do packet lookup or somethingelse. Therefore this can be seen as a virtual circuit like technique.

Performing optical switching is especially beneficial for large flows of data.Because when bundeling data flows into a big flows removes the need for per-forming routing decisions for each flow individually. This has the advantage thatthe big flow receives a better Quality of Service. Also offloading the electronicalnetwork in turn results in a better handling of the smaller flows in the electron-ical network. In chapter 4, the scenarios and the setup for the simulation ofoptical switching is explained in detail.

2.2.2 Status

According to a survey held amongst service providers [13], only a fraction ofthe service providers is using features of Optical Transport Networks (OTNs).However, this surveys shows that in the future this will drastically increase. Forexample, this survey shows that 74% of the respondents plan to deploy electricalODU (Optical Data Unit) switching eventually. And more specific, 71% of thecarriers have deployed or will deploy the so called ODU-2/10 switching in thecore and metro network (a network part covering a metropolitan area) by theend of 2011.

In the Netherlands, SURFnet6 [14] is an example of where optical switchingcould be used. SURFnet provides high speed Internet of up to 10 Gbps to highereducation and research institutions in the Netherlands. SURFnet6 is a networkthat makes use of both optical and electronical links.

There are more examples where optical switching is useful. For example theworld’s largest particle physics laboratory, CERN [15], is producing roughly 15petabytes (15 million gigabytes) of data annually [16]. These large amounts ofdata are distributed to researchers around the world. To do this, CERN hasa so called LHC Computing Grid, which is a computer network that connectsscientific institutions. For this purpose, CERN makes use of private fiber-opticcable links and portions of the public Internet as well. They could for examplemake usage of optical switching technologies very well. This would offload thatpart of the Internet.

Performing optical switching in the above two examples would be for takingadvantage of the main motivation optical switching has to offer: alleviate theburden on routers at the IP level by forwarding the data flows on the opticallevel instead. Also performing this in a self-management fashion could provideeven more resource savings.

10

In this report is being looked at the performance of the TCP protocol afterperforming optical switching. The reason for looking at this protocol is becauseit is the most used protocol on the transport layer [5].

2.3 Self-management of Optical Switching

Optical switching can be performed in two ways: manually or autonomical [1].When performing a switch manually, a network operator or another kind of em-ployee selects a flows and directs this flow to an optical connection beforehand.On the opposite, an autonomic switch is a device that decides autonomouslywhich flows should be moved to the optical level.

It might be argued that it is desirable to perform optical switching as au-tomatically as possible for both economical and efficiency reasons. This meansthat data flows should somehow be selected to be switched onto an opticalnetwork without human interference if possible.

Human interference can still be useful here, but at a higher level. Insteadof directly monitoring a network, a network manager can monitor the self-management system of the network.

2.3.1 Benefits

Here follows a summation of the benefits of using self-management of opticalswitching [1][2]:

1. Self-management is much cheaper. A network operator’s time is saved. Anelectronical device is much cheaper when compared to a network operator’stime.

2. Scalability is much better. An autonomous device can cope much easierwith large amount of flows without degrading in performance in some way.

3. Switching speed is higher. Human management can be slowed down muchwhen when coping with many connections and is much slower than anautonomous device.

4. Having a switch operating autonomously requires no signaling to controlthe switch. Even though this is minimal, it saves bandwidth.

5. An automatic device is less likely to perform a faulty switch. Making anaccidental error is typical human behavior. An automatic device will havea much more consistent and error free behavior, if programmed correctly.

However there are also a disadvantage:

1. Manual switching is much more simple. The whole process is centralizedwhich results in a better control and overview of the network.

So self-management of optical switching contributes to obtain faster, cheaperand automated data networks. [1] Provides more in-depth information aboutthe self-management of optical switching.

11

Chapter 3

TCP Congestion ControlAlgorithms of Choice

3.1 Basic Principles

TCP is a transport layer protocol, which means that it is built on top of anetwork- and physical layer, i.e. IP and an optical connection respectively. Fig-ure 3.1 shows the place of TCP in the OSI protocol stack. This shows the orderin which the protocols and standards are interoperating with each other.

Figure 3.1: TCP, IP and SONET/SDH in the OSI protocol stack.

TCP acts as a end-to-end protocol. However, applications use a client/servermodel for communications. So the communications described in this report willlook as depicted in figure 3.2.

TCP is a connection oriented protocol. This means that status and infor-mation regarding a connection is kept track of. This includes information suchas the phase in which the connection is and the window size (the amount ofpackets that have been sent but not acknowledged).

12

Figure 3.2: Client and server communication over TCP, IP and SONET/SDH.

Figure 3.3: Overview of a TCP segment

A TCP packet has a structure as displayed in figure 3.3. It has a reserved slotsfor flags for such as SYN and ACK. These are used in the setup of a connection,which typically consists of the following steps [4] [17]:

• A client sends a packet to the server with the SYN-flag enabled.

• The server accepts this connection and sends back a packet with bothSYN and ACK enabled.

• Next, the client accepts the server by sending back a packet with theAcknowledgement (ACK) flag enabled.

• At this moment, the connection is established and packets can be ex-changed. The client sends data packets to the server side. As a responseto this, the server sends back packets with the ACK flag enabled and anumber indicating the amount of bytes which have been acknowledged.

Figure 3.4 illustrates this sequence.

13

Figure 3.4: A typical TCP connection setup.

There are a few things to note here:

• The amount of packets that can be sent at a certain moment is limitedby the so called congestion window size [18]. This window size is a locallymaintained variable which dictates the maximum amount of allowed out-standing packet at a certain moment in time. The amount of outstandingpackets is determined by the status of the current TCP connection andalso by the so called congestion control strategy used (more informationon this follows later on).

• Upon receiving an acknowledgement, the client shifts it congestion win-dow forward. After this, the congestion window is not fully used. As aconsequence, new packets can be sent.

• When receiving packets in the wrong order (for example when packetstake different routes), packets are reordered at the receiver.

• When a packet is lost, the receiver does not acknowledge this packet andkeeps on waiting for this packet. The sender is supposed to resend thispacket, but there are no guarantees for this.

3.2 TCP Congestion Control Phases

After reaching certain window size thresholds, the status of the TCP connectionis changed. This has an effect on which congestion control strategy is used. Allthese strategies have the goal to reduce the congestion in the network. Thereare four main congestion control strategies which are used in modern implemen-tations of TCP [18]:

• Slow-start. The TCP connection will start in this phase. In this phasethe congestion window is increased each time an acknowledgement is re-ceived. The window size is increased by the amount of segments acknowl-edged. This keeps on going until no acknowledgement is received or until

14

a certain threshold value is reached. After this, the connection enters thecongestion avoidance phase.

• Congestion avoidance. How the TCP connections will be maintainedin this phase depends on the actual implementation of the congestionavoidance algorithm. There are however commonly used approaches, suchas the additive increase/multiplicative decrease algorithm. More detailson congestion avoidance will follow later on.

• Fast retransmit. This is an enhanced phase for TCP with the goal toreduce the time a sender is waiting before retransmitting a lost segment.Normally, a sender waits for a specified amount of time when a packet islost. However, when three times the same acknowledgement is receivedby a sender, this phase is entered. At this moment the chances are highthat the packet with the next higher sequence number was dropped andtherefore this packet is retransmitted without waiting for its timeout toexpire.

• Fast recovery. This is a variation to the slow start algorithm. It reducesthe throughput reduction gap in the case of receiving three duplicate ac-knowledgements when residing in the congestion avoidance phase. It usesthe fast retransmit followed by the congestion avoidance phase. However,instead of reducing the congestion window to a low initial value, the con-gestion window is reduced to the higher slow-start threshold value. Thisincreases the throughput right after packet loss.

3.3 Congestion Avoidance Algorithms

As explained before, congestion avoidance algorithms are part of the congestioncontrol system. Different implementations of congestion avoidance algorithmsexist. This report investigates the effect of an optical switch on different TCPcongestion avoidance algorithms. The different TCP congestion avoidance algo-rithms that have been selected for this purpose are TCP Reno, TCP Vegas, TCPCompound and TCP Cubic. These first two, Reno and Vegas, are traditionalTCP flavors. Compound and Cubic are designed specifically for high-speed net-works. In the next section follows a more detailed explanation for this selection,as well as an explanation of the operational details.

3.3.1 TCP Reno

Reno[18] is one of the first TCP algorithms created. It has been included in thesimulation because it is used in many operating system as default congestionavoidance algorithm. Especially older versions of Linux which are still in use,have this algorithm implemented as the default congestion control algorithm intheir kernels. Also, newer versions of TCP such as TCP NewReno[19] are basedon this algorithm [20].

Since TCP Reno is one of the earlier congestion mechanism created, its op-erations are more basic when compared to other congestion control algorithms.When a packet is lost, Reno will interpret this as an indication that the net-work is congested. If no packets are lost, Reno increases its window size by

15

one during each Round-trip time (RTT, this is the length of time needed for asignal to be transmitted plus the time it takes for an acknowledgement to bereceived). When packet loss is experienced, the congestion window is halved.This approach of reducing the window size by a large amount after a loss iscalled multiplicative decrease. Also, increasing the window size with a smallfixed amount is called additive increase.

As a consequence, connections with a low RTT will update their congestionwindow more often. This results in connections with a lower RTT acquiringa higher throughput quicker. This holds for most congestion avoidance algo-rithms.

TCP Reno implements the fast retransmit technique explained before. Thismeans that when receiving three duplicate ACKs will be an early indication ofa loss. Before the timeout of a packet sent later on occurs, the packet will beretransmitted. The value of the congestion window will be set to the slow-startthreshold without actually entering the slow-start phase.

Also the fast recovery mechanism is implemented by TCP Reno. This meansthat after a fast retransmit the congestion window is reduced by one packet foreach duplicate ACK. Once the missing data is acknowledged, the congestionwindow will be set to the threshold value from before fast retransmit.

The maximum window size of TCP Reno is calculated as following, as derivedin [21]:

CWNDmax =1.22MSS√p

, (3.1)

where MSS is the maximum segment size and p the packet loss rate.

3.3.2 TCP Vegas

Vegas[22] is also one of the earlier TCP algorithms. Instead of using packet lossas an approach for measuring congestion, this algorithm uses packet delay [23].

To be more precise, Vegas looks at the difference in the expected and actualthroughput rates for adjusting its congestion window. Note that these rates area function of the RTT, which is the delay for sending a packet and receiving ananswer. This equation is as follows:

Diff = (Expected−Actual)BaseRTT, (3.2)

where Expected and Actual are calculated as follows:

Expected = CWND/BaseRTT (3.3)

Actual = CWND/RTT, (3.4)

where BaseRTT is the minimum roundtrip time and RTT the actual round

16

trip time of a packet. Next, the size of the congestion window depends on thefollowing formula:

CWNDV egas =

CWND + 1, if Diff < α

CWND − 1, if Diff > β

CWND, otherwise

(3.5)

Because of this approach, Vegas utilizes the available bandwidth more effi-ciently when compared to Reno [23]. However there are some problems withVegas, such as the ”persistent congestion” problem, as identified in [24].

3.3.3 TCP Compound

TCP Compound[25] is a implementation of TCP created by Microsoft designedfor high-speed networks. It is available on many, mainly windows-based, oper-ating systems. Compound TCP tries to combine a delay-based and a loss-basedapproach. The sending rate is determined by both these components. It alsoaims to increase its sending rate quickly when the network is under utilized. Onthe other hand, when the network is busy, it can reduce throughput quickly.

Like TCP Vegas, TCP Compound also uses delay measuring as an indicationfor congestion. However, it does not try to keep the amount of packets queuedconstant (Vegas tries to do this by reducing the CWND with 1 if Diff > β).

Furthermore, Compound makes use of two congestion windows. It has anadditive increase/multiplicative decrease (AIMD) as well as a delay-based win-dow. The size of the actual sliding window is the sum of both of these windows.

The AIMD windows works in the same way as the AIMD window of Renoworks. The delay-based window aims to make good use of the available band-width. This means that if the delay experienced is small, the delay based win-dow is increased quickly. In the case when queuing is detected, the delay-basedwindow will decrease gradually.

The algorithm aims to keep the sum of the AIMD and the delay-based win-dow constant at a calculated value that is called the bandwidth-delay product.This value is the product of the data link’s capacity (in bits per second) andits end-to-end delay (in seconds). This is equivalent to the maximum amountof data on the network circuit at any given time. This solves the previouslymentioned persistent connection problem that Vegas experiences.

The window for TCP Compound can be calculated as follows:

CWNDCompound = min(cwnd+ dwnd, awnd), (3.6)

where awnd is the advertised window from the receiver. And where cwnd up-dates in the same way as the congestion window of TCP Reno in congestionavoidance phase, which means that it is increased by one MMS every RTT andhalved upon packet loss. However, Compound can send more packets in oneRTT, namely (cwnd + dwnd). Which means that the formula for cwnd is asfollows:

cwnd = cwnd+1

cwnd+ dwnd(3.7)

17

The delay based component in this formula is a bit more advanced and can becalculated as following:

dwnd(t+ 1) =

dwnd(t) + (αwin(t)k − 1)+, if Diff < γ

(dwnd(t)− εdiff)+, if Diff ≥ γ(win(t)(1− β)− cwnd/2)+, if loss is detected,

(3.8)

where diff is calculated in the same way as for TCP Vegas (formula 3.2). Andα, β and k are tunable parameters for changing scalability, smoothness andresponsiveness. (.)+ is defined as max(., 0)

3.3.4 TCP Cubic

TCP Cubic[26] is the default congestion avoidance algorithm in Linux kernelssince version 2.6.19. TCP Cubic is designed and optimized for high speed net-works with high latency. It is a derivate of BIC TCP, but it is less aggressiveand more systematic.

Cubic is different when compared to other TCP congestion avoidance algo-rithms, because it does not increase its window size based on receiving ACKs.Instead, Cubic changes it window according to the last congestion event. Thismeans that the window size is independent of the RTT.

The window size is a cubic function (a polynomial function to the thirddegree) of time since the last moment congestion happened. This function is asfollowing:

CWNDCubic = C(t−K)3 +Wmax (3.9)

Here, C is the scaling factor, t the time since the last window reduction andWmax the window size before the window reduction as caused by a congestionevent. K is obtained as follows:

K = 3√Wmaxβ/C, (3.10)

where β is a constant multiplication factor. Figure 3.5 shows the window sizegrowth of TCP Cubic.The window grows very fast after a window reduction, but as soon as it gets nearWmax its growth is slowed down to almost zero near Wmax. Next, Cubic willprobe for more bandwidth. This will result in a slow window growth initially,followed by a faster growth over time. The slow growth around Wmax improvesthe stability and the fast growth later on improves the network usage and thescalability.

18

Figure 3.5: Window growth function of TCP Cubic

3.4 Overview

TCP Reno is a rather old algorithm, making use of the standard TCP featuressuch as additive increase, multiplicative decrease, fast retransmit, fast recovery.

In contrast to Reno, TCP Vegas takes on a different approach for congestioncontrol. It measures the congestion window size by looking at the delay in thepath between the sender and the receiver.

TCP Compound has a more advanced approach by using two different con-gestion windows (an AIMD and a delay window). By doing this, it combinesboth the approaches used by Vegas and Reno.

TCP Cubic has again a different approach by providing an approach aimedat high speed networks. It aims to have a good stability and a fast windowgrowth, independent of the RTT.

19

Chapter 4

Simulation and Results

4.1 Scenarios

Two scenarios have been created for the simulation. Figure 4.1 shows the topol-ogy of the scenarios used for the optical switching simulation, after which followsan explanation.

Figure 4.1: Optical switching scenario.

This topology consists of three routers (r1, r2 and r3), a sender and a re-ceiver node. The sender and the receiver are connected by two different paths.One path simulates an IP path (which is connected via routers r1, r2 and r3)while the other path is an optical path (connected via r1 and r3). When certainpredetermined throughput values are reached (100 Mbps, 1 Gbps or 10 Gbps)the routing of the TCP flow changes from the IP path onto the optical path.This has consequences only for one direction of the flow (from the sender tothe receiver). The acknowledgement packets (ACKs) are still routed over theoriginal path (from the receiver to the sender). Right after this switch there isa short period of time where normal data packets (not the ACK packets) areflowing through both paths. Once these remaining packets have arrived, thereare only data packets going through the optical path and soon after the simu-lation is finished.

While performing these simulations, throughput information is output byns-2 into tracefiles. These tracefiles have been used to graph throughput infor-mation. This allows for analyzing the maximum throughput and what exactly

20

happens after a switch is performed. The throughput of a TCP flow depends onmultiple factors, such as the application that is used, the size of the TCP buffer,the link capacity and packet loss in the network [27], but here is only looked atthe influence of an on-the-fly switch of a flow when the limiting factor is eitherthe core links or the receiver’s local link capacity. This resulted in creating twoscenarios, which are:

Scenario A. In this scenario, the capacity of the core links (φ1 and φ2 inFigure 4.1) is the limiting factor for the throughput and the capacity of theoptical links is the same as the IP links. (φ1 = φ2 in Figure 4.1)

Scenario B. Scenario B simulates the situation where the local link of thereceiver (ξ in Figure 4.1) is the limiting factor in the throughput.

In both scenarios, the switch was aimed to be performed when the through-put of the flow had reached its maximum throughput. However not all flows ineach scenarios did reach maximum throughput in a reasonable amount of timebecause they were too slow in increasing their window size or they experiencetoo much packet loss. Those flows were switched at a lower speed.

Also, each scenario and throughput combination is performed for three dif-ferent rtts. These different rtts are 10 ms (milliseconds), 100 ms and 1000 ms.These different rtts represents different situations where the sender and receiverare close to each other (10 ms), a situation further away from each other andone very far away from each other (1000 ms). Also note that after the switchthe rtt is assumed to be smaller for each of the above three cases (respectively 6ms, 60 ms, and 600 ms). This is because after the switch the packets can makeuse of the faster optical path and can avoid routing at the IP level.

Table 4.1 summarizes the parameters used in the simulation scenarios. Eachline represents a simulation, which has been ran for each of the different TCPCongestion Control algorithms The Greek symbols correspond with the symbolsin figure 4.1.

Scen. Limiting rate α β φ1 φ2 ξ100 Mbps 1.16 GB 622.08 Mbps 100 Mbps 100 Mbps 622.08 Mbps

A 1 Gbps 1.16 GB 2.488 Gbps 1 Gbps 1 Gbps 2.488 Gbps10 Gbps 1.16 GB 39.813 Gbps 10 Gbps 10 Gbps 39.813 Gbps100 Mbps 1.16 GB 622.08 Mbps 622.08 Mbps 622.08 Mbps 100 Mbps

B 1 Gbps 1.16 GB 2.488 Gbps 2.488 Gbps 2.488 Gbps 1 Gbps10 Gbps 1.16 GB 39.813 Gbps 39.813 Gbps 39.813 Gbps 10 Gbps

Table 4.1: Summary of the parameters for both scenarios for rtt = 10 ms.

4.2 Setup

For the simulations the program ns-2 [6] is used. It is the ’de-facto’ tool employedfor network simulation. The ns-2 enhancement patch ”TCP Linux” [28] hasbeen used to allow for using different TCP congestion control algorithms inthe simulations. TCP Linux makes use of pre supplied code extracted fromthe Linux kernel [29]. Ns-2 version 2.33 has been used, which has the TCP

21

Linux patch built in. Depending on the rtt, the congestion control algorithmand the throughput size, it could take a multiple of ten minutes before reachingmaximum throughput. Which is the moment a switch should be performed.

For each simulation, a logfile has been created with all received and sentTCP packets in that simulation, including details such as arrival time, size andtype of packet. By using a Perl script, the throughput was calculated from thislogfile and converted into plottable data for use with gnuplot. This was doneonce with a granularity of 1.0 second and once with a granularity of 0.1 second.

In the next section the simulation results of both scenario A and B for thedifferent throughput speeds and rtt can be found. A few selected graphs areincluded and analyzed in the text, but a complete list of all the generated graphsis provided in the appendix.

4.3 Simulation results

4.3.1 Scenario A and 100 Mbps results

The results for the NS-2 simulations in the case of a limiting rate of 100 Mbpswith a rtt of 10 and 100ms are not too bad for all the TCP flavors. A summaryof the results for scenario A and 100 Mbps can be found in table 4.2. In thesecases, there is only a small throughput decrease after the switch after which thethroughput only increases for all the flavors. The worst performance in thesetwo scenario is caused by Vegas in the rtt = 100ms scenario. A throughputdecrease for about 3 seconds in which the throughput lowers with about 10Mbps can be seen. After this the throughput only increases linearly. It shouldalso be noted that Vegas is not able to build up a connection with maximumthroughput. Since the maximum window size of Vegas relies on the delay of aconnection, the delay of 100ms apparently prevents Vegas from reaching higherthroughput values.

100Mbps Compound Reno Vegas Cubicrtt = 10ms Indifferent Indifferent Increased Indifferentrtt = 100ms Indifferent Indifferent Small reduc-

tion, then in-creased

Indifferent

rtt = 1000ms Increased Increased Increased Indifferent

Table 4.2: Summary of the results for scenario A with a limiting rate of 100Mbps

In the case of the simulation with rtt = 1000ms, the throughput is unable tobuild up a large enough window to provide 100 Mbps throughput for Compound,Reno and Vegas. Because of the long delay this takes an extremely large amountof time. Also with such a large rtt, a packet loss causes the slowly built upwindow size to be negated by halving it, making it impossible to reach maximumthroughput. Surprisingly, Cubic doesn’t have much trouble with reaching themaximum throughput nor is it affected by the switch. There is even a peak in

22

the throughput at the switch, but this is caused by ACK packets that were sentright before the switch over the normal path and arrived right after the switch.

4.3.2 Scenario A and 1 Gbps results

For the limiting factor φ1 and φ2 = 1 Gbps, all algorithms perform well whenrrt = 10 ms. However, as shown in table 4.3 and figure 4.2, the case of a limitingrate of 1 Gbps might be more interesting.

0

0.2

0.4

0.6

0.8

1

1.2

-50 -40 -30 -20 -10 0 10 20 30

thro

ughput (G

bps)

time(s)

A with rtt=100 ms, throughput=1 Gbps switch at 0

RenoVegas

CompoundCubic

Figure 4.2: Scenario A with an rtt of 100 ms and a limiting rate of 1 Gbps

1Gbps Compound Reno Vegas Cubicrtt = 10ms Indifferent Indifferent Small reduc-

tion for a fewseconds

Indifferent

rtt = 100ms About 60%reduction fora short time

about 75% re-duction on thethroughputfor a while

slowly increas-ing, but wasnot switchedat top speed

Indifferent

rtt = 1000ms Increased,but nowherenear topspeed

Increased, butnowhere neartop speed

Increased, butnowhere neartop speed

Indifferent

Table 4.3: Summary of the results for scenario A with a limiting rate of 1 Gbps

Again here Vegas gives very little throughput reduction for the case of rtt =10ms. Also it wasn’t switched at full throughput, but very close to that. Afterthe reduction it goes also quick to maximum throughput. The other versions

23

have no reduction for this rtt.

The case with rtt = 100ms is getting more problematic. Compound, Renoand Vegas have all three a mentionable throughput reduction. Compound isrestored to maximum throughput rather quick, it takes only about 6 secondsto reach 1Gbps again. After switching Cubic, only a very small reduction inthroughput can be seen.Both Reno and Vegas have a much longer reduction. After the switch thethroughput gets reduced by a mentionable amount and both algorithms startbuilding up the window size again at a faster rate than before the switch (be-cause the rtt on the optical links is lower). However it is still not nearly utilizingthe full amount of bandwidth available. To illustrate this, if a user was down-loading a large file using Reno or Vegas and a switch was applied, the user wouldnotice a change in download speed. Namely if the connection was assigned TCPVegas, it would increase, however it would still not be very fast. If Reno wasused, The download speed would be decreased. Note that the TCP congestioncontrol algorithm to be used is decided by the server.

After the switch a packet loss seems to occur. This causes the congestionwindow to be halved or even worse, this is a characteristic of the multiplicativedecrease phase. Next, both Reno and Vegas show a saw tooth pattern, how-ever they are not reducing to half the throughput. Instead the throughput isonly lowered a little bit. This indicates that there is probably a fast retrans-mission going on. This means that throughput is reduced because packet arebeing received out of order. After the sender has received three packets withthe same ACK number, it assumes that there is an out of order delivery andthat the packet with the duplicate ACK number is missing and is resent. Theother packets send with a higher ACK number are assumed to be received cor-rectly, because otherwise the duplicate ACKs would not be received so fast aftereach other (instead they would time-out). However, after this, the same pat-tern keeps reoccurring. This probably means that the fast retransmit wronglyassumed that all subsequent packets that were sent after the last fast retrans-mission were received correctly. Apparently this was not the case, since the fastretransmissions keep on following each other. So both Reno and Vegas can notdeal really well with the new situation, packets keep on being lost and a patternof multiple fast retransmission is the result.

Compound seems to enter the slow-start phase after the packet loss causedby the switch. Right after the switch, the throughput gets increased at an in-creasingly speed. At about 0.85 Gbps a very small inclination seems to occur inthe throughput speed. After this inclination that throughput increases linearly.This means that the slow-start threshold is reached, making the window resumeits growth in the additive increase pattern. When reaching 1 Gbps throughput,the throughput remains very stable.

This shows that the dual window approach used in TCP Compound worksbetter in this case than a single window as in Reno or Vegas. The quick recoveryis because the delay-based window of Compound was designed to increase veryfast in a lower rtt environment. Also, the more dynamic window size adaption

24

of Cubic makes it more resistant against a switch. This means that users wouldnotice the effect of an optical switch if Reno, Vegas or Compound (in a lesserdegree) is used.

In the case of an rtt of 1000ms, only Cubic reaches full throughput and isnot affected by the switch. The other three algorithms are not nearly able toutilize all available bandwidth, although a very small increase is noticeable afterthe switch. This is due to the shorter delay of the new path.

4.3.3 Scenario A and 10 Gbps results

In this scenario, due to the small window sizes, no maximum throughput isreached in most cases. However, a switch still has the largest impact on TCPReno and Vegas and the least on Compound and Cubic.

In this scenario, the largest impacts in throughput reduction seem to occurfor the case of an rtt of 10 ms. The corresponding graph can be found in figure4.3.

Especially the throughput of Reno is reduced by a substantial amount. Thethroughput for Compound seems to be reduced very little. Again probablybecause the delay is very low and this allows for Compound to increase its win-dow very fast. The delay-bandwidth product is large, so Compound adjuststhe amount of outstanding packets to this amount. Vegas seems to have littletrouble with the switch in this case.

0

2

4

6

8

10

12

-40 -20 0 20 40

thro

ughput (G

bps)

time(s)

A with rtt=10 ms, throughput=10 Gbps switch at 0

RenoVegas

CompoundCubic

Figure 4.3: Scenario A with an rtt of 10 ms and a limiting rate of 10 Gbps

In this graph a similarity with the typical saw tooth pattern of Reno canbe seen. This indicates that Reno is in the additive increase phase and thewindow size being halved after a loss occurs at full throughput. Also the sawtooth becomes steeper after the switch. This is because a smaller rtt allows for

25

quicker building up of the window size.

Vegas seems to be in a pattern of chained fast retransmits, as was also thecase for both Reno and Vegas in Figure 4.2. After the switch, almost no nega-tive effects occur, but Vegas stays in a pattern of fast retransmits. Apparently,Vegas can’t keep up with the sending rate.

On the other hand, Compound has a few packet losses before the switchand a packet loss right after the switch. This packet loss does not have muchimpact because upon this packet loss the fast retransmit state is entered andfull throughput is reached very quickly after this.

The throughput after the packet loss that occurs about 10 seconds beforethe switch and also at the recovery from the packet loss that occurs because ofthe switch show some similarities with the mathematical cubic function that hasbeen explained in section 3. This shows the slowly increasing window size thathappens when Wmax has not been reached yet. Where Wmax is the window sizethat corresponds with a throughput of 10 Gbps on the vertical axis.

Again, this graph shows the superiority of both Cubic and Compound whenreacting to an optical switch. They are both much faster in recovering froma loss and reaching maximum throughput again and also have a lower windowreduction.

4.3.4 Scenario B and 100 Mbps results

In this scenario, the results from a switch with an rtt of 10ms are for each flavorare almost the same. A switch has as good as no impact on the throughput.In this scenario with 100 ms rtt, Reno has the largest throughput reduction,about 23%, but it recovers very quickly. Vegas has a little less reduction, butrecovers over a little longer period. Furthermore both Compound and Cubichave a negligible reduction.For the case of 1000 ms rtt, only Cubic reaches full throughput in reasonabletime.

4.3.5 Scenario B and 1 Gbps results

In the case of 10 ms rtt, each flavor has a very low throughput reduction. WithVegas having the most loss in throughput.

The case of 100 ms rtt is more surprising. This graph is given in figure 4.3.The switching has a positive effect on Reno and Vegas, but they still have alow throughput. Both show a saw tooth pattern after the switch, indicating apattern of fast retransmits. However even after the switch they are very slowat building up a decent window size.

Cubic seems to have a lot more trouble in recovering, it takes about 30 sec-onds to reach 1 Gbps again. Cubic seems to perform actually worse than Renoand Vegas, which is surprising with the previous results in mind, where Cubicperformed very well. However it does increase a lot faster to full throughput

26

0

0.2

0.4

0.6

0.8

1

1.2

-60 -40 -20 0 20 40

thro

ughput (G

bps)

time(s)

B with rtt=100 ms, throughput=1 Gbps switch at 0

RenoVegas

CompoundCubic

Figure 4.4: Scenario B with an rtt of 100ms and a limiting rate of 1 Gbps

which is consistent with the previous behavior of Cubic.

The graph shows a similarity with the positive part of a mathematical cubicfunction. However it is strange that this happens at such a low bandwidth.Apparently Wmax from equation 3.10 has been set a lower threshold of around200 Mbps at maximum, assuming that the first part of the equation is verysmall (t is small because a congestion event just occurred and K is a function ofWmax and constants). After this it shows that the Cubic function is in the maxprobing phase. However the throughput still resembles a saw tooth-pattern,which indicates that it still has many packet losses to deal with. Apparentlythis formula is less efficient than the simple approach used by Reno (which onlyuses the MSS and the packet loss rate for the window size) for this case.

Furthermore, the graph shows a short reduction for Compound, but it re-covers pretty fast and seems to be very stable after about three seconds. So forscenario B with a limiting rate of 1 Gbps it is recommended to perform a switchfor all cases except for Reno and Cubic with an rrt of 100 ms and a limitingrate of 1 Gbps. For all the other combinations for 1 Gbps throughput a switchhas a positive effect.

4.3.6 Scenario B and 10 Gbps results

This case of scenario B with a limiting rate of 10 Gbps and an rtt of 10ms isillustrated in figure 4.5. Note that the simulation for Reno and Compound wasstopped a little earlier than the other two flavors. But the effect of the switchis clear before the end of the simulation. Again in this figure, like in A with alimiting rate of 10 Gbps, not many flavors reaching the top speed. In the caseof 10ms however, both Compound and Cubic reach top speed. Interestingly,Compound recovers again very fast (about 3 seconds), whereas Cubic recoversabout a factor 10 slower. In the case of 100 ms rtt Cubic is the only flavor

27

0

2

4

6

8

10

12

-40 -20 0 20 40

thro

ughput (G

bps)

time(s)

B with rtt=10 ms, throughput=10 Gbps switch at 0

RenoVegas

CompoundCubic

Figure 4.5: Scenario B with an rtt of 100ms and a limiting rate of 10 Gbps.Note that the decreasing line that goes zero is there because the simulation hasended.

is that is reaching the maximum throughput before the switch. Despite this,Compound still recovers faster from the switch even though it wasnt switchednear the maximum throughput. So in scenario B and a limiting rate of 10Gbps, Compound seems to be better than Cubic. This is because Compoundcan increase its window faster because its window size is also based on delay,next to its AIMD window. Cubic on the other hand must rely only on a windowsize that is based on congestion events, which isn’t working that good in caseswhere the throughput is extremely large.

4.4 Practical Experiment

In an attempt to verify the results that were obtained with the ns-2 networksimulator, a practical experiment was set up. Two PCs where connected witheach other using two cat6 UTP cables. Also one PC was supplied with twoGigabit network interface cards, while the other had one Gigabit network inter-face card and one Megabit network card. With this equipment one connectionbetween the PCs would simulate the IP level connection, whereas the otherwould simulate the lightpath. The problem with this experiment was how tomake the PC on the other side recognize that a TCP flow was switched fromone cable and the connected network interface was made onto the other cableand connected network interface and correctly handle it.

Several attempts were made to simulate a lightpath switch with this equip-ment. The following things have been tried: re-route on-the-fly with the linuxroute command, a method called NIC bonding, re-route on-the-fly using IPta-bles and re-route on-the-fly using ebtables.

For both the linux routing command and IPtables, normal traffic re-routingwas possible. However correctly re-routing a flow after switch and handle itaccordingly did not work. The ongoing flows were still routed over the original

28

path. However, after the switch, new TCP flows did get routed over the newpath. So it seems like the new re-routing settings were only applied for newflows, not for ongoing flows. This might be might be a problem in the programitself or in the linux kernel or maybe the settings or commands used were notright. For the attempts at ebtables and NIC bonding, neither normal re-routingor re-routing on-the-fly worked.

29

Chapter 5

Conclusions and FutureWork

5.1 Conclusions

In this report the performance of the throughput of different TCP congestioncontrol algorithms after performing an optical switch was investigated. TCPReno, Vegas, Compound and Cubic have been analyzed. Reno was chosen be-cause it is one of the first TCP algorithms created and it forms the foundationfor many TCP algorithms. Also its still used in many older Linux machines. Ve-gas was chosen because it uses packet delay as a measure for congestion insteadof packet loss as Reno does. Compound was chosen because of its availabilityon many windows-based machines. Also its two window congestion approachmakes it an interesting algorithm. And finally, Cubic was chosen because it isan algorithm designed for high-speed networks.

The analysis was performed by using the ns-2 network simulator. For eachcongestion algorithm, two switching scenarios were simulated. In the first sce-nario, the capacity of the core links are the limiting factors of the throughput.The second scenario simulates the case where the receiver’s local link is thelimiting factor.

The answer to the main research question (”How do different TCP conges-tion control algorithms react to autonomic optical switching?”) was answeredin chapter 4. This answer was obtained by answering sub question 2 (”Whatare fundamental differences in how congestion control algorithms deal with con-gestion, packet reordering and packet loss?”) in chapter 3 by looking at themechanisms of the selected congestion control algorithms. Furthermore subquestion 3 (”How is the throughput of an established TCP connection with dif-ferent congestion control algorithms affected after an optical switch and why?”)was answered in chapter 4 by analyzing the results from the performed simula-tions. Finally, sub question 4 (”Which TCP congestion control algorithms aremost resistant to optical switching?”) will be answered in the remaining part ofthis chapter.

Based on the analysis provided in this report, a few conclusions can be

30

drawn. First, it was shown that Reno and Vegas have a poor performance whenit comes to switching from the electronical domain onto the optical domain.

Also, Compound approaches the performance of Cubic when it comes to op-tical switching and throughput recovery. However there are a few cases whereCompound recovers much better from the switch, such as in Scenario B with100 ms rtt and both 1 Gbps and 10 Gbps throughput.

It might not be surprising that Reno and Vegas perform poor. These twoalgorithms were designed years ago, whereas Compound and Cubic were de-signed much more recent. Also these latter two were specifically designed forhigh-speed networks, which make them able to handle a switch much betterin terms of performance. TCP Compound uses a much more aggressive win-dow size increase approach. Compound recovers throughput much faster aftera switch overall compared with Vegas and Reno. Also it takes much shorter forCompound and Cubic to build up a large enough congestion window to reachmaximum throughput. For Reno and Vegas this was for some scenarios almostor completely impossible.

The results for each scenario and congestion control algorithm differ greatly.However, looking at the overall performance after a switch for each congestioncontrol algorithm, the conclusion can be drawn that Cubic has the best resis-tance against a switch. Compound follows closely and Reno and Vegas stay farbehind. Also, having an TCP congestion control with an aggresively approachis beneficial in recovering from a switch. Because switched flows have their owndedicated light path, fairness is not a problem in this case.

Algorithm ThroughputDelay

rtt = 10ms rtt = 100ms rtt = 1000ms

Reno100Mbps - - ↑∼1Gbps - ⇓ ↑∼10Gbps ⇓ ↑∼ ↑∼

Vegas100Mbps ↑∼ ↓∼ ↑∼1Gbps ↓∼ ∼ ↑∼10Gbps ↑∼ ↑∼ ↑∼

Compound100Mbps - - ↑∼1Gbps - ↓ ↑∼10Gbps - ↑∼ ↑∼

Cubic100Mbps - - -1Gbps - - -10Gbps - - x

Table 5.1: Summary of scenario A. Explanation of the symbols: ”-” meansindifferent (almost no impact), ”⇓” a large reduction in throughput, ”↓” a lesssevere reduction in throughput, ”⇑” a quick and fast increase in throughput,”↑” a slower and smaller increase in throughput, ”∼” not switched at top speedand ”x” means not graphed.

To conclude, optical switching might be used carefully when switching on-going flows because they might take a while to recover. This holds for all of

31

Algorithm ThroughputDelay

rtt = 10ms rtt = 100ms rtt = 1000ms

Reno100Mbps - - ↑∼1Gbps - ⇓ ∼10Gbps ⇓ ∼ ∼

Vegas100Mbps - ↓ ↑∼1Gbps - ↑∼ ∼10Gbps ↑∼ ∼ ∼

Compound100Mbps - - ⇑∼1Gbps - ↓ ∼10Gbps ↓ ⇑∼ ∼

Cubic100Mbps - - -1Gbps - ⇓ ↑10Gbps ⇓ ⇓ x

Table 5.2: Summary of scenario B. Explanation of the symbols: ”-” meansindifferent (almost no impact), ”⇓” a large reduction in throughput, ”↓” a lesssevere reduction in throughput, ”⇑” a quick and fast increase in throughput,”↑” a slower and smaller increase in throughput, ”∼” not switched at top speedand ”x” means not graphed.

the examined congestion control algorithms, but it impacts Reno and Vegas themost. For a summary of the results see 5.1 and 5.2. Based on these results,it is recommended to perform an optical switch in most scenarios, except theone with a ⇓ symbol (Reno in both scenario A and B with 100ms and 1 Gbpsin scenario A, Reno in both scenario A and B with 10ms and 10Gbps, Cubicin scenario B with 1Gbps and 100ms, Cubic in scenario B with 10Gbps and 10and 100ms). The scenarios with a ↓ symbol can be switched with care, sincethere will be a throughput reduction, but the benefits of a light path (betterQoS, relieving the IP level from routing work) should outweigh this. Especiallyif the TCP flow has a long enough duration.

5.2 Future Work

In this report, the impact of an optical switch on the throughput of TCP Cubic,Compound, Reno and Vegas has been analyzed. This was done using the ns-2network simulator. As future work, it would be interesting to verify these re-sults with a real experiment. Performing these test with real network equipmentcould provide a useful comparison with the analysis provided in this report. Thiswould contribute to the realisticity of the results from this report.

32

Bibliography

[1] T. Fioreze, Self-Management of Hybrid Optical and Packet Switching Net-works. PhD thesis, University of Twente, 2010.

[2] M. Maier, Optical Switching Networks. Cambridge University Press, 2008.

[3] International Organization for Standardization, “ISO/IEC 7498-1 secondedition, Open Systems Interconnection - Basic Reference Model: The BasicModel,” 1996.

[4] Information Sciences Institute, University of Southern California, “Trans-mission Control Protocol.” http://www.ietf.org/rfc/rfc793.txt, 1981.

[5] Internet2: Netflow: Weekly Reports, “IP Protocols Distribution.” http:

//netflow.internet2.edu/weekly/20100426/#ip_protos.

[6] ns2, “The Network Simulator NS-2.” http://www.isi.edu/nsnam/ns/.

[7] G. C. Moreira Moura, T. Fioreze, P. T. de Boer, and A. Pras, “Opticalswitching impact on tcp throughput limited by tcp buffers,” in Proceedingsof the 9th IEEE International Workshop on IP Operations and Manage-ment, Venice, Italy (G. Nunzi, C. Scoglio, and X. Li, eds.), vol. 5843 ofLecture Notes in Computer Science, (Heidelberg), pp. 161–166, SpringerVerlag, October 2009.

[8] D. Payne and J. Stern, “Transparent single-mode fiber optical networks,”Lightwave Technology, Journal of, Juli 1986.

[9] E. C. Hannah, “CAT-5 UTP Analysis.” P1394b meeting Media & Inter-connect TechnologyLab, February 1998.

[10] N. Telegraph and T. C. (NTT), “World Record 69-Terabit Capacity forOptical Transmission over a Single Optical Fiber.” http://www.ntt.co.

jp/news2010/1003e/100325a.html/, 2010.

[11] L. Hutcheson, “FTTx: Current Status and the Future,” CommunicationsMagazine, IEEE, July 2008.

[12] http://www.reggefiber.nl/.

[13] Infonetics research, “OTN survey reveals huge shift in carrierplans for optical switching.” http://www.infonetics.com/pr/2011/

Carrier-OTN-Deployment-Strategies-Survey-Highlights.asp.

33

[14] http://www.surfnet.nl/.

[15] http://www.cern.ch/.

[16] CERN, “Worldwide LHC Computing Grid.” http://lcg.web.cern.ch/

LCG/public/.

[17] L. Parziale, Britt, D.T., D. C., J. Forrester, W. Liu, C. Matthews, andN. Rosselot, TCP/IP Tutorial and Technical Overview. IBM, 2006.

[18] M. Allman, V. Paxson, and W. Stevens, “TCP Congestion Control.” RFC2581 (Proposed Standard), Apr. 1999.

[19] S. Floyd and T. Henderson, “The NewReno Modification to TCP’s FastRecovery Algorithm.” RFC 3782, April 2004.

[20] J. F. Kurose and K. W. Ross, Computer Networking: A top-down approachfeaturing the internet. Pearson Addison-Wesley, third ed., 2005.

[21] S. Floyd and K. Fall, “Promoting the Use of End-to-End Congestion Con-trol in the Internet,” IEEE/ACM Transactions on Networking, 1999.

[22] L. S. Brakmo and L. L. Peterson, “TCP Vegas: End to End CongestionAvoidance on a Global Internet,” EEE Journal on selected Areas in com-munications, October 1995.

[23] J. Mo, R. J. La, V. Anantharam, and J. Walrand, “Analysis and comparisonof tcp reno and vegas,” in In proceedings of IEEE Infocom, pp. 1556–1563,1999.

[24] J. W. Richard J. La and V. Anantharam, “Issues in TCPVegas.” http://www.eecs.berkeley.edu/~ananth/1999-2001/Richard/

IssuesInTCPVegas.pdf, 1998. Available online.

[25] Q. Z. Kun Tan, Jingmin Song and M. Sridharan, “A Compound TCPApproach for High-speed and Long Distance Networks,” in In ProceedingsIEEE Infocom, April 2006.

[26] I. Rhee and L. Xu, “CUBIC: A New TCP-Friendly High-Speed TCP Vari-ant,” in In Proceedings of PFLDNet, 2005.

[27] M. Timmer, P. T. de Boer, and A. Pras, “How to identify the speed limitingfactor of a tcp flow,” in Proceedings, 4th IEEE/IFIP Workshop on End-to-End Monitoring Techniques and Services, 2006.

[28] D. X. Wei and P. Cao, “A Linux TCP implementation for NS2.” http:

//netlab.caltech.edu/projects/ns2tcplinux/ns2linux/.

[29] D. X. Wei and P. Cao, “A Linux TCP implementation for NS2 with2.6.16.3 kernel.” http://netlab.caltech.edu/projects/ns2tcplinux/

ns2linux-2.29-linux-2.6.16/index.html.

34

Appendix A

Appendix

A.1 Graphs

All graphs for the possible throughput and rtt combinations can be found herefor both scenarios.

A.1.1 Scenario A

A.1.2 100 Mbps throughput

0

20

40

60

80

100

120

-60 -50 -40 -30 -20 -10 0 10 20 30

thro

ug

hp

ut

(Mb

ps)

time(s)

A with rtt=10 ms, throughput=100 Mbps switch at 0 RenoVegas

CompoundCubic

Figure A.1: Scenario A with an rtt of 10 ms and a throughput of 100Mbps

35

0

20

40

60

80

100

120

-60 -50 -40 -30 -20 -10 0 10 20 30

thro

ug

hp

ut

(Mb

ps)

time(s)

A with rtt=100 ms, throughput=100 Mbps switch at 0 RenoVegas

CompoundCubic

Figure A.2: Scenario A with an rtt of 100 ms and a throughput of 100 Mbps

0

20

40

60

80

100

120

-60 -50 -40 -30 -20 -10 0 10 20 30

thro

ug

hp

ut

(Mb

ps)

time(s)

A with rtt=1000 ms, throughput=100 Mbps switch at 0 RenoVegas

CompoundCubic

Figure A.3: Scenario A with an rtt of 1000 ms and a throughput of 100 Mbps

36

A.1.3 1 Gbps throughput

0

0.2

0.4

0.6

0.8

1

1.2

-50 -40 -30 -20 -10 0 10 20 30

thro

ughput (G

bps)

time(s)

A with rtt=10 ms, throughput=1 Gbps switch at 0

RenoVegas

CompoundCubic

Figure A.4: Scenario A with an rtt of 10 ms and a throughput of 1 Gbps

0

0.2

0.4

0.6

0.8

1

1.2

-50 -40 -30 -20 -10 0 10 20 30

thro

ughput (G

bps)

time(s)

A with rtt=100 ms, throughput=1 Gbps switch at 0

RenoVegas

CompoundCubic

Figure A.5: Scenario A with an rtt of 100 ms and a throughput of 1 Gbps

37

0

0.2

0.4

0.6

0.8

1

1.2

-50 -40 -30 -20 -10 0 10 20 30

thro

ughput (G

bps)

time(s)

A with rtt=1000 ms, throughput=1 Gbps switch at 0

RenoVegas

CompoundCubic

Figure A.6: Scenario A with an rtt of 1000 ms and a throughput of 1 Gbps

A.1.4 10 Gbps throughput

0

2

4

6

8

10

12

-40 -20 0 20 40

thro

ughput (G

bps)

time(s)

A with rtt=10 ms, throughput=10 Gbps switch at 0

RenoVegas

CompoundCubic

Figure A.7: Scenario A with an rtt of 10 ms and a throughput of 10 Gbps

38

0

2

4

6

8

10

12

-40 -20 0 20 40

thro

ughput (G

bps)

time(s)

A with rtt=100 ms, throughput=10 Gbps switch at 0

RenoVegas

CompoundCubic

Figure A.8: Scenario A with an rtt of 100 ms and a throughput of 10 Gbps

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

-40 -20 0 20 40

thro

ughput (G

bps)

time(s)

A with rtt=1000 ms, throughput=10 Gbps switch at 0

RenoVegas

Compound

Figure A.9: Scenario A with an rtt of 1000 ms and a throughput of 10 Gbps

39

A.1.5 Scenario B

A.1.6 100 Mbps throughput

0

20

40

60

80

100

120

-60 -40 -20 0 20 40

thro

ughput (M

bps)

time(s)

B with rtt=10 ms, throughput=100 Mbps switch at 0

Compound overlaps Reno

RenoVegas

CompoundCubic

Figure A.10: Scenario B with an rtt of 10 ms and a throughput of 100 Mbps

0

20

40

60

80

100

120

-60 -40 -20 0 20 40

thro

ughput (M

bps)

time(s)

B with rtt=100 ms, throughput=100 Mbps switch at 0

RenoVegas

CompoundCubic

Figure A.11: Scenario B with an rtt of 100 ms and a throughput of 100 Mbps

40

0

20

40

60

80

100

120

-60 -40 -20 0 20 40

thro

ughput (M

bps)

time(s)

B with rtt=1000 ms, throughput=100 Mbps switch at 0

RenoVegas

CompoundCubic

Figure A.12: Scenario B with an rtt of 1000 ms and a throughput of 100 Mbps

A.1.7 1 Gbps throughput

0

0.2

0.4

0.6

0.8

1

1.2

-60 -40 -20 0 20 40

thro

ughput (G

bps)

time(s)

B with rtt=10 ms, throughput=1 Gbps switch at 0

RenoVegas

CompoundCubic

Figure A.13: Scenario B with an rtt of 10 ms and a throughput of 1 Gbps

41

0

0.2

0.4

0.6

0.8

1

1.2

-60 -40 -20 0 20 40

thro

ughput (G

bps)

time(s)

B with rtt=100 ms, throughput=1 Gbps switch at 0

RenoVegas

CompoundCubic

Figure A.14: Scenario B with an rtt of 100 ms and a throughput of 1 Gbps

0

0.2

0.4

0.6

0.8

1

1.2

-60 -40 -20 0 20 40

thro

ughput (G

bps)

time(s)

B with rtt=1000 ms, throughput=1 Gbps switch at 0

RenoVegas

CompoundCubic

Figure A.15: Scenario B with an rtt of 1000 ms and a throughput of 1 Gbps

42

A.1.8 10 Gbps throughput

0

2

4

6

8

10

12

-40 -20 0 20 40

thro

ughput (G

bps)

time(s)

B with rtt=10 ms, throughput=10 Gbps switch at 0

RenoVegas

CompoundCubic

Figure A.16: Scenario B with an rtt of 10 ms and a throughput of 10 Gbps

0

2

4

6

8

10

12

-40 -20 0 20 40

thro

ughput (G

bps)

time(s)

B with rtt=100 ms, throughput=10 Gbps switch at 0

RenoVegas

CompoundCubic

Figure A.17: Scenario B with an rtt of 100 ms and a throughput of 10 Gbps

43

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.1

-40 -20 0 20 40

thro

ughput (G

bps)

time(s)

B with rtt=1000 ms, throughput=10 Gbps switch at 0

RenoVegas

Compound

Figure A.18: Scenario B with an rtt of 1000 ms and a throughput of 10 Gbps

44