Multi-Path TCP: A Joint Congestion Control and Routing Scheme to Exploit Path Diversity in the Internet

(1)

Multi-Path TCP: A Joint Congestion Control and

Routing Scheme to Exploit Path Diversity in the Internet

K. Seena NaiK

(Ph.D.)

Department of CSE S K University, Anantapur Email: [email protected]

Dr. G. A. Ramachandra

Department of CSE S K University, Anantapur

M. V. Bramhananda Reddy

Department of CSE Gitam University

Email: [email protected]

Abstract – We consider the problem of congestion-aware multi-path routing in the Internet. Currently, Internet routing protocols select only a single path between a source and a destination. However, due to many policy routing decisions, single-path routing may limit the achievable throughput. In this paper, we envision a scenario where multi-path routing is enabled in the Internet to take advantage of path diversity. Using minimal congestion feedback signals from the routers, we present a class of algorithms that can be implemented at the sources to stably and optimally split the flow between each source-destination pair. We then show that the connection level throughput region of such multi-path routing/congestion control algorithms can be larger than that of a single-path congestion control scheme.

Keywords – Congestion Control, Multi-Path Routing, Throughput, Overlay Networks.

I. INTRODUCTION

In Recent years, there has been a great deal of interest in the congestion control in the Internet. Kelly proposed a framework in which congestion control can be viewed as a mechanism for fair resource allocation in a network of elastic users, such as the Internet. This framework, and more generally, differential equation models of congestion control, can be used to study the stability of congestion control and active queue management (AQM) schemes using control-theoretic methods.

In most prior models, it has been assumed that each user is assigned a single path between its source and destination. The user then reacts to congestion on its path. However, congestion may be caused indirectly due to inefficiencies in the routing protocol itself. For example, BGP is primarily a policy-bsed protocol and, depending upon the policy, can sometimes choose a low bandwidth path for a source, even when an alternate nigh bandwidth is available.

We consider networks where multiple paths are available to each user between its source and destination, and the user can direct its flow along these paths using source routing. The amount of flow on each path is determined by the user in response to congestion indications from the routers on the path. Currently, source routing is not supported in routers in the Internet. However, two scenarios exist in which this might become possible.

The first is when we overlay the network with routers that allow source routing. Fig.1.1, which shows a network of ISPs connected to each other by means of peering points. In this network of ISP clouds, depending on the

policy employed by the ISPs, a connection from ISP2 to ISP4 may be routed via peering point P4 even though more bandwidth may be available on a different path, say via ISP5, through peering points P1 and P3.

Fig.1. The figure shows a network of ISPs connected via peering points, denoted by P1 through P4.

This presents an opportunity for overlay networking to improve the service provided to the end users in the following manner: suppose that one installs overlay routers at the peering points and allows source routing at these overlay routers. Further, if the provider of the overlay routing service buys a bandwidth from the ISPs, then one create a logical network as shown in fig.2. This would allow us to provide a service where data transfer can simultaneously take place over multiple routes in the overlay network. It is not necessary to always place the overlay routers at the peering points. Any set of overlay routers which allow source routing would provide some path diversity which can only improve network performance.

Fig.2. A logical network formed from the network in fig 1.1 by overlaying routers and using virtual links through the ISP cloud. In this example, two sources S1 and S2 are

(2)

case looks very similar to the overlay case. We refer to a data transfer between two nodes as a flow. By “node”, we mean a source or destination for network traffic. Each flow may use multiple paths to transfer data. Obviously many flows can exist between a node-pair, but it is not necessary that all of them share the same path-set.

1.2 Problem statement:

In recent years, there has been a great deal of interest in congestion control in the Internet. In most prior models, it has been assumed that each user is assigned a single path between its source and destination. Congestion may be caused indirectly due to inefficiencies in the routing protocol itself.

1.3 Objective

 A joint congestion control and routing schema to exploit path diversity in the internet

 multi-path routing is enabled in the Internet to take advantage of path diversity.

1.4 Scope

The scope of our project is it is mainly useful at the internet for increasing the throughput region between two systems in the n/w.

1.5 Limitations

To take the advantage of path diversity source routing must and should supported by the internet.

1.6 Applications

 Used in internet for controlling the congestion.  Used in internet for increasing the throughput.

This paper has mainly four sections.

Section 1: To control the congestion in the internet. Section 2: Multi path routing.

Section 3: Calculate Time for single path and multi path routing.

Section 4: Result and Conclusion.

Section 1: To control the congestion in the internet

II. STANDARD TCP CONGESTION CONTROL

ALGORITHMS

There are four standard congestion control algorithms that are now in common use. Each of the algorithms noted within that document was actually designed long before the standard was published. Their usefulness has passed the test of time. The four algorithms, Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery are described below.

a. Slow Start

Slow Start, a requirement for TCP software implementations is a mechanism used by the sender to control the transmission rate, otherwise known as sender-based flow control. This is accomplished through the return rate of acknowledgements from the receiver. In other words, the rate of acknowledgements returned by the receiver determines the rate at which the sender can transmit data.

When a TCP connection first begins, the Slow Start algorithm initializes a congestion window to one segment, which is the maximum segment size (MSS) initialized by

the receiver during the connection establishment phase. When acknowledgements are returned by the receiver, the congestion window increases by one segment for each acknowledgement returned. Thus, the sender can transmit the minimum of the congestion window and the advertised window of the receiver, which is simply called the

transmission.

Slow Start is actually not very slow when the network is not congested and network response time is good. For example, the first successful transmission and acknowledgement of a TCP segment increases the window to two segments. After successful transmission of these two segments and acknowledgements completes, the window is increased to four segments. Then eight segments, then sixteen segments and so on, doubling from there on out up to the maximum window size advertised by the receiver or until congestion finally does occur. At some point the congestion window may become too large for the network or network conditions may change such that packets may be dropped. Packets lost will trigger a timeout at the sender. When this happens, the sender goes into congestion avoidance mode.

Slow start algorithm:

We define a new variable called ssthresh, the Slow-Start threshold, which is initialized to the maximum window size.

1. Initial value of cwnd , cwnd <= 2* SMSS 2. SSthresh = size of the advertised window 3. Each time we receive a new ACK, (i) if (cwnd < SSthresh)

cwnd+=1; Else

cwnd+=1/cwnd ;

4. If time out occurs or cwnd > SSthresh

The sender goes into congestion avoidance mode.

Slow Start is actually not very slow when the network is not congested and network response time is good. For example, the first successful transmission and acknowledgement of a TCP segment increases the window to two segments. After successful transmission of these two segments and acknowledgements completes, the window is increased to four segments. Then eight segments, then sixteen segments and so on, doubling from there on out up to the maximum window size advertised by the receiver or until congestion finally does occur. At some point the congestion window may become too large for the network or network conditions may change such that packets may be dropped. Packets lost will trigger a timeout at the sender. When this happens, the sender goes into congestion avoidance mode.

b. Congestion Avoidance

During the initial data transfer phase of a TCP connection the Slow Start algorithm is used. However, there may be a point during Slow Start that the network is forced to drop one or more packets due to overload or

(3)

timer expiring or the reception of duplicate acknowledgements can implicitly signal the sender that a network congestion situation is occurring. The sender immediately sets its transmission window to one half of the current window size (the minimum of the congestion window and the receiver's advertised window size), but to at least two segments. If congestion was indicated by a timeout, the congestion window is reset to one segment, which automatically puts the sender into Slow Start mode. If congestion was indicated by duplicate acknowledgements, the Fast Retransmit and Fast Recovery algorithms are invoked (see below).

As data is received during Congestion Avoidance, the congestion window is increased. However, Slow Start is only used up to the halfway point where congestion originally occurred. This halfway point was recorded earlier as the new transmission window. After this halfway point, the congestion window is increased by one segment for all segments in the transmission window that are acknowledged. This mechanism will force the sender to more slowly grow its transmission rate, as it will approach the point where congestion had previously been detected.

Congestion Avoidance algorithm:

This algorithm is used to slow the transmission rate of the sender.

1. If congestion situation occurs or time out occurs SSthresh = Max ( CWND/2 , 2*SMSS ) CWND = 1;

2. Then sender put into slow start mode

3. Each time we receive a new acknowledgment if (cwnd < Ssthresh )

cwnd+=1;

Else cwnd+=1/cwnd;

c. Fast Retransmit

When a duplicate acknowledgement is received, the sender does not know if it is because a TCP segment was lost or simply that a segment was delayed and received out of order at the receiver. If the receiver can re-order segments, it should not be long before the receiver sends the latest expected acknowledgement. Typically no more than one or two duplicate acknowledgements should be received when simple out of order conditions exist.

If however more than two duplicate acknowledgements are received by the sender, it is a strong indication that at least one segment has been lost. The TCP sender will assume enough time has lapsed for all segments to be properly re-ordered by the fact that the receiver had enough time to send three duplicate acknowledgements. When three or more duplicate acknowledgements are received, the sender does not even wait for a retransmission timer to expire before retransmitting the segment (as indicated by the position of the duplicate acknowledgements in the byte stream). This process is called the Fast Immediately following Fast Retransmit is the Fast Recovery algorithm.

d. Fast Recovery

Since the Fast Retransmit algorithm is used when duplicate acknowledgements are being received, the TCP

sender has implicit knowledge that there is data still flowing to the receiver. Why? The reason is because duplicate acknowledgements can only be generated when a segment is received. This is a strong indication that serious network congestion may not exist and that the lost segment was a rare event. So instead of reducing the flow of data abruptly by going all the way into Slow Start, the sender only enters Congestion Avoidance mode. Rather than start at a window of one segment as in Slow Start mode, the sender resumes transmission with a larger window, incrementing as if in Congestion Avoidance mode.

Fast Retransmit & Fast recovery:

A TCP receiver should send an immediate duplicate ACK when an out-of-order segments arrives. The purpose of this ACK is to inform the sender that a segment was received out-of-order and which sequence number is excepted.

Duplicate ACK causes due to 1. In case of dropping segments 2. time-out

3. replication

Fast retransmit algorithm occurs when 3 or more duplicate packets occurs.

After receiving 3 duplicate ack, TCP performs a retransmission for missing segments, without waiting for retransmission timer to expire

1. When 3 duplicate ACK is received Ssthresh <= Max ( cwnd/2 , 2 segments ) for each duplicate ACK , cwnd+=1; Each time we receive a new ack cwnd = Ssthresh + 3 smss

The retransmission due to incoming duplicate ACK’s called Fast Retransmission.

Fast recovery algorithm occurs when duplicate ack are received.

In this, the TCP sender enters into congestion avoidance mode instead of slow start algorithm.

Section 2: Multipath routing:

It is desirable to allow packets with the same source and destination to take more than one possible path. This facility can be used to ease congestion and overcome node failures. To operate such a scheme consistently nodes must maintain routing tables specifying what goes where. The mechanisms for this differ with datagram and virtual circuit transport.

Datagram Routing Tables

(4)

numbered, its datagram routing table is shown. The weights in the table represent the probability of the link being chosen for the destination specified. A random number will decide where the packet actually goes. The wieghts represent ratios of some metric of path length.

III. SHORTEST AND BEST PATHS

A path is the route taken by a data packet traveling between two network nodes. A network is typically highly complex so the correct path will not be obvious. Routing algorithms must overcome this complexity and make useful path choices. The notion of a shortest path is necessary when evaluating routing choices.

Distance Metrics

An obvious metric of path length is number of hops. In the above example ABC is shorter than ABEF. Many other metrics are commonly used, the ones chosen will greatly affect how optimal paths are found. The numbers on the links, on the netwok shown above, represent physical distance, it can be seen that ABEF is shorter than ABC. Other common metrics include mean queueing and transmission times, bandwidth, cost and average traffic. The labels (fig 2.1) could be the result of a function of some or all of these metrics.

Fig.3. network with path length

Section 3: Calculate Time for single path and multi

path routing.

1)Start

on arrival of packet p from router 2)e.currentRTT=cur_time-p.timestamp;

3)if(e.currentRTT< e.baseRTT)

3.1) e.baseRTT=e.currentRTT;

for each flow f listed in p

4) temp=min(e.currentRTT, f.egress_rate); 5) if(f.ingress_rate<baseRTT)

5.1) f.ingress_rate=f.ingress_rate+temp; 6) else

6.1) f.ingress_rate=f.ingress_rate-temp; 7) Stop.

ALGORITHM

Section 4: Result and conclusion.

Throughput value

GRAPHS

Throughput value comparison in single-path and multi-path routing

IV. CONCLUSION

In this project, we have studied congestion control algorithms for networks where multi-path routing is possible.

We show that the connection-level throughput region of such multi-path routing can be large than that of a single-path routing scheme.

REFERENCES

[1] M. Hwang, et al., “Challenges in e-Government and Security of

Information.” in Information & Security, vol.15, no.1, 2004.

[2] M . Wimmer & B. Bredow, “A Holistic Approach for Providing

Security Solutions in e-government.” IEEE Computer Society,

2002.

[3] M. Whitman and H. Mattord, , Readings and Cases in the

Management of Information Security, Thomson, 2006.

[4] Security e-Government Strategy Framework Policy and

Guidelines, retrieved from: http://www.govtalk.gov.uk/

documents/securityv4.pdf

[5] C. Kalloniatis et al., Security Requirements Engineering for

(5)

AUTHOR’S PROFILE

K. Seena Naik (Ph.D.)

Department of CSE

S K University, Anantapur Email: [email protected]

Dr G.A Ramachandra

Department of CSE

S K University, Anantapur

M. V. Bramhananda Reddy

Department of CSE

Gitam University