TCP and ATM Congestion Control -A simulation study using OPNET

Group:

Desai, Bimal

Chauhan, Anand Kumar

Mukherjee, Gautam

Submitted in Partial Fulfillment for the degree in Master of Science in Computer Science

Summer 2001, Department of Computer Science

Lamar University, Beaumont, TX- 77710

Directed by:

Dr. Lawrence Osborne

Chair, Department of Computer Science

Lamar University, Beaumont, TX -77710

Acknowledgement

We express our heartfelt gratitude to Dr. Lawrence Osborne, Chair, Department of Computer Science at Lamar University, Beaumont TX-77710, without whose priceless encouragement, guidance and support this project would not have been a success. We also sincerely thank the members of the other project group for their consistent and invaluable help.

We express our gratitude to Dr. H. Koh and Dr. Q.N Tran for their guidance and kind suggestions.

We dedicate our endeavor to our parents without whose boundless love and blessings this project would not have been a success.

Group: Desai, Bimal

Chauhan, Anand Kumar

Mukherjee, Gautam

Department of Computer Science, Lamar University

Summer 2001

Abstract

TCP and ATM Congestion Control – A simulation study using OPNET

TCP uses Slow Start algorithm while ATM Available Bit Rate uses the Explicit Rate algorithm for congestion control in a network. We used OPNET to study and compare performances of the two algorithms. The networks under study were designed keeping in mind the actual Wide Area Networks typical of today’s Internet situation. The study of ATM networks was based on two types of switches – Binary and Explicit Rate switches which use EFCI and ERICA congestion control algorithms respectively.

Through simulation of the networks and analysis of the results, we came up with the following primary conclusions about performance of TCP and ATM congestion control algorithms.

• TCP congestion control symbolizes a “best effort “ kind of service and thus cannot be very useful when Quality of Service requirements are stringent. ATM on the other hand provides a reliable and guaranteed Quality of Service.
• Setting up a TCP network is simpler and requires less involvement from an administrator as compared to ATM.
• ATM performs better than TCP in terms of fairness achieved by resources. ATM is also capable of guaranteeing a certain minimum bandwidth to resources, an issue where TCP promises no guarantees whatsoever.
• TCP is best for heterogeneous networks while ATM works best for homogeneous networks.

Study of ERICA, EFCI and EFCI-UPC algorithms led us to the following conclusions.

• ERICA and EFCI –UPC algorithms perform better in terms of cell delay, cell delay variations and queuing delay and also has a greater throughput-load ratio when compared to EFCI algorithm with no Usage Policy Control.

1. Introduction

1.1 Purpose 6

1.2 Overview of Congestion in Networks 6

1.3 Congestion control measures 7

1.4 Overview of TCP Congestion control 9

1.5 ATM ABR Flow control 10

1.6 Sample network 10

1.7 Brief Methodology 11

1.8 Organization of rest of report 13

2. TCP Congestion control theoretical principles

2.1 Introduction to TCP 14

2.2 Definitions 14

2.3 TCP Connection 17

2.4 TCP Congestion control 18

2.5 Algorithms used in TCP congestion control 19

2.6 TCP Flavors 25

2.7 Parameters of TCP 27

2.8 Performance Measures for TCP connection 28

3. Design of TCP Network Model

3.1 TCP Design Approach 34

3.2 TCP Protocol Behavior 35

3.3 TCP Design Basics 36

3.4 Available Statistics 40

4. Results and Analysis of TCP Model

4.1 Congestion window analysis 43

4.2 Comparison of Reno and Tahoe 48

4.3 Performance measures of TCP connections 53

5. ATM ABR Congestion control

5.1 Introduction to ATM 68

5.2 ATM Traffic Management 70

5.3 Importance of ATM 71

5.4 ATM models 72

5.5 ATM Connections 73

5.6 ATM QoS parameters 74

5.7 ATM Traffic descriptors 75

5.8 ATM Service categories 76

5.9 ATM Connection Admission Control 77

5.10 ATM Congestion control 78

6. Basic Design of ATM Model

6.1 ATM Design Basics 88

6.2 ATM Protocol Behavior 90

6.3 ATM Node models 91

6.4 ATM Model attributes 91

6.5 ATM Available statistics 95

6.6 ATM Network components 96

6.7 Destination Address configuration 99

7. Results and Analysis of ATM model

7.1 ATM Global Throughput and load 101

7.2 ABR CTD and CDV 105

7 3 Queuing delay 111

7.4 Queue length 113

7.5 Allowed Cell rate and queue length 114

7.6 Queue length threshold 117

7.7 Conclusion 119

7.8 Further work 121

8. Conclusions

8.1 Conclusion 120

8.2 Future Work 122

Bibliography 123

Appendix A- TCP Network Configuration Steps 125

Appendix B- ATM Network Configuration Steps 144

Chapter 1-Introduction

1.1 Purpose:

The purpose of the project was to study and compare TCP and ATM congestion control algorithms using simulation. We used OPNET- a simulation software by MIL3 for our project. Simulation was performed on separate model networks for TCP/IP and ATM. Performance of the congestion control algorithms used by TCP and ATM was evaluated based on collected data from simulation. Conclusions were drawn about behavior of the two above mentioned congestion control schemes based on analysis of collected statistics.

1.2 Overview of congestion in networks:

Congestion is a phenomenon, which is often encountered, in the networks today. Congestion is likely to occur in an expanding system like the Internet and is often a dynamic phenomenon and happens mainly due to unpredictable events. In the networks, congestion causes excessive delay or loss or both, while the quality of service provided to the end user application is highly affected by such delay and loss. In IP/ATM networks, congestion occurs when the offered load (demand) from the user to the network reaches or exceeds network capabilities (available resources) for providing guaranteed Quality of Service (QoS) over an extended time interval. Such excess demand can occur due to incorrect oversubscribing of resources by network, failures within the network or because of operational failures. In IP/ATM networks, buffers, transmission facilities or processors are prone to congestion. The resource or transmission link where demand exceeds capacity is called a bottleneck [1].

B

Figure 1. Illustration of Congestion Around a Route [1]

Figure 1.1 shows an example of congestion occurring along a path from a server connected to a node D. The nodes in the figure are connected by links and thicker lines indicate a high link capacity. Dots shown next to each link are the rate of bursts of packets/cells delivered across the link. As in Figure 1.1, high-speed links are capable of delivering at a rate of 3 bursts while a thin link can only transmit 1 burst per time interval.

There are two points of congestion in Figure 1.1. The average input to Node C is 6 bursts while the output link can transmit only 3 bursts. Thus, the link between Nodes C and D is congested due to persistent overloading and will eventually result in packets or cells being dropped as storage facilities gradually become full.

Another example of congestion occurs on the low speed link between Node D and the user. The link is capable of transmitting only 1 burst per time interval but has been receiving 3 bursts from the server. Such a mismatch in speed also causes congestion and results in packets or cells being dropped [1].

1.3 Congestion control measures:

The effect of congestion is determined by several application characteristics such as connection node, retransmission policy, acknowledgement policy, responsiveness and higher layer flow control [1]. Network characteristics such as queuing delay, service-scheduling policy, discard strategy, route selection, propagation delay, and processing delay and connection node are also causes of congestion.

The degree of congestion is measured by two major metrics: throughput and delay. Throughput can be defined as the data transmission rate achieved by the end application. Throughput requirements are different for different types of applications. Voice and video are examples of applications with strict throughput requirements. Delay can be defined as the actual time elapsed between the first unsuccessful transmission of a packet and a subsequent successful reception at the receiver [1]. Delay requirements are strict for real time applications. Loss also is a measure of congestion, and tolerance for loss varies among different applications.

Ideal

1 Good

0.8

Throughput

0.4 Poor

0.2

0

Load

0% 50% 100%

Figure 1.2: Throughput vs. Load [1]

Figure 1.2 is a plot of effective throughput versus offered load. As seen from the figure, in an ideal system, throughput increases linearly with increased load. In a good congestion control algorithm, the throughput becomes constant beyond a certain point with increased load while a poor congestion control algorithm gives a congestion collapse when throughput reduces considerably as offered load is increased beyond a certain value.

8 Poor Good Ideal

Delay 6

4

2

0

0% 50% 100%

Offered Load

Figure 1.3: Illustration for effective delay for congestion control schemes [1]

Figure 1.3 plots delay versus offered load. As shown, ideal congestion control schemes exhibit bounded delay for all values of offered load and delay becomes infinite under infinite load conditions. Good congestion control algorithms show increased delay with severe congestion while poor congestion control algorithms exhibit delay that increases rapidly even before the system is fully utilized.

Simultaneous achievement of high throughput and low delay is practically impossible. As a tradeoff, queuing power is evaluated.

1.0

0.8

Power 0.6 Ideal

0.4

0.2 Good

Poor

0% 50% 100%

Offered Load

Figure 1.4: Illustration of queuing power for congestion control schemes [1]

Queuing power = Throughput/delay.

Figure 1.4 is a plot of queuing power versus offered load. Queuing power is a tradeoff between throughput and delay because it compares the ratio between the two instead of comparing absolute values. As seen from Figure 1.4, a good congestion control algorithm shows an optimum queuing power at low utilization levels [1].

1.4 Overview of TCP Congestion control:

There are two mechanisms for controlling congestion: open loop and closed loop. The open loop congestion control operates without any feedback while in the closed loop scheme the sender receives feedback about the congested state. TCP and ATM ABR both use closed loop congestion control mechanisms. TCP works over IP to achieve reliable transmission of packets on an end-to-end basis. The congestion control algorithm used by TCP is known as the Slow Start algorithm and it uses a variable length sliding window flow control protocol. TCP requires acknowledgement for each packet from the receiver and if such an acknowledgement is not received within a time out interval, retransmission occurs based on the assumption that the packet was lost. The sender also assumes a congested situation and slows down the transmission rate as a congestion control measure. The transmission rate is decreased by means of decreasing the window size at the sender [1, 12, 17].

1.5 ATM ABR Flow control:

ATM uses a feedback scheme in which the intermediate nodes send feedback messages to the source about the occurrence of congestion or about the current rate at which it is capable of transmitting. The source then adjusts its transmission rate based on the feedback messages. If sources conform to the rules of ABR, then a minimum cell rate (MCR) is guaranteed by the network with minimal cell loss. Policing ensures that sources do not violate the traffic contract. ABR Flow control has two major modes –EFCI or binary mode and Explicit rate mode. Fairness is an important objective in the closed loop flow control scheme.

In the EFCI mode switches indicate congestion using the EFCI bit in the ATM cell header. Destinations set the Congestion Indication (CI) bit in the Resource Management (RM) cells, which travel backward from destination to source. The source then reduces its transmission rate by a fraction of the currently available cell rate.

In the Explicit rate mode each network element explicitly sets the maximum allowed rate in the RM cells as they loop back to the source. The source then updates its sending rate as indicated in the RM cells. The ABR service operates at high utilization with negligible cell loss. The ABR Flow control scheme can be implemented on per hop basis (Virtual source/destination VS/VD) or on an end-to-end basis (No VS/VD) [1, 2, 5, 8, 12].

1.6 Sample network:

Figure 1.5(a) shows a sample network used in the project to study the TCP Congestion control algorithm. The network consists of servers, workstations and an aggregation of routers/switches representing the Internet Cloud. The network served as a model for simulation. The cloud is an aggregate of IP routers connected by high-speed OC-3 links. The servers support various applications requested by the workstations.

Figure 1.5 (b) shows a similar sample network used as simulation model for studying ATM ABR Flow control. The cloud here consists of ATM cross connection switches and ATM sources that generate ATM cells during every time interval and send them to ATM destinations. The switches in the cloud are interconnected by high-speed links.

1.7 Brief Methodology:

OPNET 7.0B/8.0C was used as the simulation tool. The scope of the project required building a complete network topology because effects of congestion are scaled across the network. A complete network topology was decided upon after careful evaluation of available high performance network test beds available through resources on the Internet even though our study concentrated on evaluating the performance on the Internet cloud [3]. The network model was built up by choosing required node models and link models from the OPNET Object Palette and setting up the applications and profiles supported. A series of simulations were then performed on the models. Each parameter change resulted in a different scenario and results were analyzed and compared in order to understand changes in network behavior.

Figure 1.5(a): Sample TCP network [1]

Figure 1.5(b): Sample ATM network [1]

Two different flavors of TCP (Tahoe and Reno) were used as parameters of the transport layer while simulating the TCP model [1, 12,13, 14, 18]. The effects of buffer size and threshold values on congestion were also used as parameters to study congestion. Statistics were collected on Congestion window size, number of TCP connections, fairness, slow start initial count, link utilization, latency and response time. Network behavior was studied by changing different traffic distributions (exponential, geometric, pareto), page response times and file sizes.

ATM ABR Flow control was studied with respect to throughput/load, cell delay, cell delay variation, queue length and allowed cell rate. The relationship between allowed cell rate and queue length was an important area of study. The EFCI (Binary mode), ERICA (Explicit rate mode) and EFCI mode with Usage Policy Control were implemented on the network model and simulation was performed to compare and contrast the performance of the three schemes.

1.8 Organization of Report:

This report is divided into eight chapters. Chapter 2 describes the TCP congestion control theory and implementation details. Chapter 3 contains a detailed design of the TCP/IP model using OPNET 7.0B. Chapter 4 is concerned with the analysis of simulation results of the TCP model. Chapter 5 describes the theoretical principles of ATM and ABR congestion control schemes. Chapter 6 gives a detailed description of the OPNET simulation models and design strategies used. Chapter 7 describes the results obtained and presents detailed analysis of the ABR Flow control methods based on the results of simulation, the conclusions we have drawn about similarities and differences between TCP and ATM congestion control methods are described in Chapter 8. The last section of the report is a user manual, which will help future researchers in conducting further work in this field.

Chapter 2-TCP Congestion Control Theoretical Principles

2. 1 Introduction to TCP:

TCP is a transport layer protocol that provides reliable transport service to most of the Internet applications including FTP, HTTP, telnet, remote login and email. It supports the transfer of over 90 percent of all traffic on the Internet today [13].

TCP is a transport layer protocol layered between IP and the application layer.

It is a connection-oriented layer protocol, which is responsible for the end-to-end reliable transfer of the data from the source application to destination application over an unreliable network. A Connection setup is required so as to initiate the data transfer.

						User Data

Figure 2.1: General TCP/IP Workflow [13]

The application must open and set up a point-to-point TCP connection before

TCP starts accepting any application data. Each connection has exactly two endpoints (sockets = IP Address / port pair) [13].

2.2 Definitions:

This section provides the definition of several terms that will be used

throughout our project.

Segment: A segment is any TCP/IP data or acknowledgment packet or both.

Sender Maximum Segment Size (SMSS): The size of the largest segment that any sender can transmit at particular instant not including TCP/IP headers and options. The value can be based on the maximum transmission unit of the network.

Receiver Maximum Segment Size (RMSS): The size of the largest segment the receiver is willing to accept. It may be specified in the MSS option or assigned value equal to 536 bytes.

Full-Sized Segment: A segment that contains SMSS bytes of data or the maximum number of data bytes permitted.

Receiver Window (rwnd): It is equal to the most recent advertised receiver window.

Congestion Window (cwnd): A TCP state variable that limits the amount of data a TCP can send. A limit is put on the TCP so that it cannot send data with a sequence number higher than the sum of the highest acknowledged sequence number and minimum of cwnd and rwnd.

Initial Window (IW): It gives the value of the initial size of TCP congestion window the size after the 3-way handshake is completed.

Loss Window (LW): The size of the congestion window when TCP restarts transmission after it remains idle.

Flight Size: The amount of data that has been sent but not yet acknowledged [17].

TCP Segment:

Source Port and Destination Port: The source and the destination ports identify the sending and receiving applications, respectively along with IP addresses it identifies in a process-to-process connection.

Sequence Number: The 32-bit sequence number field identifies the position of the first data byte of this segment in the sender’s byte stream during data transfer.

Acknowledgement number: Acknowledgement number indicates the sequence number of the next data byte that the senders expect to receive if the ACK bit is set. ACK bit is set once the connection is established.

Figure 2.2: TCP Segment [4]

Header Length: Identifies the length of the TCP header in 32-bit words. It enables receiver to know the beginning of the data area because options field is variable length.

Reserved: This field is reserved for future use and is set to 0.

URG: If set, the urgent pointer is valid.

ACK: If set, acknowledgment number is valid.

PSH: Tells the receiving TCP module to pass the data immediately to the application. If not, the receiving TCP module may choose to buffer the segment until enough data accumulates in the buffer.

RST: When set, it tells receiving TCP module to abort the connection if some abnormal condition arises.

SYN: (Synchronize Sequence Number) It requests the setting up for a connection.

FIN: When set, it tells the receiver that the sender does not have any more data to send. The sender on other hand can still receive data until it receives a segment with the FIN bit set.

Window Size: Specifies the number of bytes the sender wants to accept. It controls the dataflow and congestion in TCP networks.

Checksum: Detects errors on TCP segment.

Urgent Pointer: When URG bit is set, the value in urgent pointer field added to that in the sequence number field points to last byte of “urgent data”. It points to last byte because any data in the receiver’s buffer up to last byte may be considered urgent.

Options: It may be used to provide optional functions that are not included by the header.

One of the most important options specified during the connection set up is used by sender to indicate the maximum segment size (MSS) it can accept. Another option specified during connection set up is window scale that allows use of large advertised window size, while the timestamp option is required for high-speed connections where sequence number may wrap around [1,4].

2.3 TCP Connection:

2.3.1 TCP Connection Establishment:

TCP is a connection-oriented protocol, which requires a connection to be set up before any host can send data. TCP establishes the connection using a three-way handshake procedure in the following steps:

1. Host A requests for a connection to host B by setting the SYN bit and registers its initial sequence number as seq_no = x.
2. Host B acknowledges the request by setting the ACK bit and by indicating the next data byte to receive as ack_no = x + 1. Host B now requests to host A by setting the SYN bit and registering its initial sequence number to seq_no = y.
3. Host A now sets its ACK bit and confirms that the next data byte to receive is (ack_no = y + 1) and acknowledges request from B.

Host A Host B

SYN, seq_no = x

SYN, seq_no=y, ACK, ack_no = x + 1

seq_no=x + 1, ACK, ack_no=y+1

Figure 2.3: Three Way Handshake [4]

The TCP segment can be delayed lost and duplicated depending on the diverse network conditions, so the initial sequence number should be different each time a host requests a connection [1,4,13].

2.3.2 TCP Connection Termination:

The data flow at each end must be stopped. Both sender and receiver need to send FIN segment to terminate the connection.

Four steps are involved in closing a connection:

1. X sends a FIN to Y.
2. Y ACKs the FIN to X. At that time Y can still send data.
3. Y sends a FIN to X.
4. X ACKs the FIN segment.

2.4 TCP Congestion Control:

TCP congestion control is a closed-loop congestion control scheme. The feedback information used by TCP to regulate the source rate is implicit. The source uses a time-out to decide whether congestion has occurred in the network. TCP exercises congestion control at the transport layer.

Need of Congestion Control in TCP Networks:

TCP uses a sliding-window protocol for end-to-end flow control. The amount of bytes a receiver can receive is specified in the acknowledgement it sends. The advertised window determines this, and puts a limit on the amount of data that a sender can transmit. In other words TCP sender is not allowed to transmit data exceeding the amount specified in the advertised window. The limitation of the advertised window does not prevent the buffers in the intermediate routers from overflowing. The condition of buffer overflow in intermediate router is termed as congestion. The network layer comprising IP does not provide any mechanism to control congestion, so it is up to the higher level Transport layer to detect congestion and to take appropriate actions [4].

Congestion occurs in a network when data arrives on a link (big pipe) with

a larger bandwidth and is delivered to a link (small pipe) with smaller capacity. Congestion can also occur when multiple input streams arrive at a router or a switch whose output capacity is less than the sum of the inputs. In our case the link connecting the accessrouter2 and Ethernets_switchadv_2 is a bottlenecked link. The traffic from seven links of capacity 10mbps(7 * 10 Mbps) is delivered to a link with smaller capacity

(1 * 10 Mbps).

Packet loss is indicated in two manners:

1. Occurring of timeout
2. Receipt of duplicate ACKs.

Modern implementation of congestion control in TCP contains four intertwined algorithms:

Slow Start

Congestion Avoidance

Fast Retransmit

Fast Recovery

Slow Start and Congestion Avoidance are independent algorithms with different objectives. But whenever congestion occurs, TCP must slow down its transmission rate of packets into the network, and then invoke slow start. Thus they are implemented together.

Both these algorithm requires maintenance of two variables:

Slow Start Threshold

Congestion Window [4,14].

2.5 Algorithms Used in TCP Congestion Control:

2.5.1 Slow Start Algorithm and Congestion Avoidance

The basic idea underlying the congestion control in TCP is to allow each sender to transmit just the pertinent amount of data to keep the network resources utilized and at the same time to be sure that the network is not overloaded. If a sender sends too many packets, the network will experience congestion. On the contrary, if senders are conservative enough to send packets, the network will be underutilized.

“ The maximum amount of bytes that a TCP sender can transmit without congesting the network is specified by a window called the congestion window”. The basic principle for congestion avoidance is that maximum amount of data transmitted by sender should not exceed the minimum of the advertised window and congestion window.

In order to dynamically regulate the size of the congestion window according to the state of the network, TCP uses a congestion control algorithm known as slow start algorithm. Slow start algorithm is designed to dynamically maximize throughput and prevent congestion collapse. TCP congestion algorithm can be divided into three phases:

Client Server

S(0) ACK(0) S(0)

S(1)

S(2) ACK(1) S(1)

ACK (2) S(2)

S(3)

S(4) ACK(3) S(3)

S(5) ACK(4) S(4)

S(6)

Time Out

S(5)

ACK (5) S(5)

Figure 2.4: TCP Dynamic Congestion Window Control [1]

S(1) ….. S(N) = TCP Segment 1 …. N

ACK(1)….ACK(N) = Acknowledgment of 1….N

FIRST PHASE:

In the first phase, the congestion window is set equal to one maximum-size segment (One MSS). Sender sends the packet S(0) and waits for an acknowledgement. S(0) is delivered to the destination server and receipt is acknowledge with the ACK(0) packet. On receiving the acknowledgement, sender then increases the congestion window size to two, sends packets S (1) and S (2) and again waits for the acknowledgement. On receiving the acknowledgement the congestion window size is increased to four. Sender can now transmit four packets. In other words, every time the sender receives an acknowledgement from the receiver before a time-out, the sender doubles the size of congestion window, so the congestion window size grows exponentially during this phase.

SECOND PHASE:

The congestion window size does not always increase exponentially. At the point when the congestion window reaches its threshold specified by congestion threshold, congestion avoidance phase takes place. It indicates that the bottlenecked resource is running close to utilization. The sender now reduce the rate of increase and increases the congestion window size linearly (one segment each round trip time) rather than exponentially. Thus, increase in cwnd should be at most one segment each round-trip time during congestion avoidance phase whereas, slow start phase increments cwnd by number of ACKs received.

THIRD PHASE:

The exponential and linear increase of congestion window is not without end. When the TCP network detects that IP network causes loss of the segment and sender does not receive an acknowledgement from receiver within the time out period, then sender retransmits the packet. Now the congestion threshold is first set to one-half of the minimum of the congestion window and the advertised windows. The algorithm now restarts using slow start technique. TCP detects congestion if an acknowledgement is not received before the expiration of the timeout period. Congestion is also detected on receiving a duplicate ACK. In this case congestion threshold is decreased to one–half the window size.

12 Time-out Time-out

Slow Start Congestion

10 Phase Avoidance

9

8

6 Slow Start Slow Start

4

2

0 5 10 15 20 25

Figure 2.5: TCP Slow Start Congestion Window Size Behavior [1]

Figure 2.5 shows the congestion window size as the time progresses. In the first phase, the slow start increases the congestion window size exponentially until it reaches the about one-half the threshold value set at 10 i.e. about 7. Then under the second phase the window increases linearly until the time-out occurs at about 11 seconds, indicating that network is congested. Now the threshold is set to 10 and the window size is set to 1 segment [1,4,14].

2.5.2 Fast Retransmit:

As we will see in Section 4.1 in actual practice implementation of these congestion control algorithms results in the TCP timeouts leading to long periods of time during which the connection goes dead waiting for a timer to expire. Because of this, a new mechanism, called fast retransmit, was added to TCP. Fast retransmit uses a heuristic approach that sometimes triggers the retransmission of a dropped packet sooner than the regular timeout mechanism. The fast retransmit mechanism does not replace regular timeouts but enhances that facility.

In a Fast Retransmit algorithm, every time a data packet arrives at the receiving side, the receiver responds with an acknowledgement, even if packet with that sequence number has already been acknowledged. So, when a packet arrives out of order, i.e., TCP cannot yet acknowledge the data it contains because earlier data has not yet arrived, TCP resends the same acknowledgement it sent last time. This second transmission of the same acknowledgement is called a duplicate ACK. When the sending side sees a duplicate ACK, it figures out that the other side must have received a packet. In other words the traffic is still flowing through the network. So the sender interprets that the original/earlier packet must have been received out of order by the receiver or might have been lost.

Since it is also possible that the earlier packet has only been delayed rather than lost, the sender waits until it sees some number of duplicate ACKs, and then retransmits the missing packet. TCP therefore sometimes generate an immediate acknowledgement (a duplicate ACK) when an out-of-order segment is received. This duplicate ACK should not be delayed because its purpose is to make the opposite end realize that the segment was received out of order.

However, a lost segment or simply a reordering of segments may generate duplicate ACKs. Therefore, the generation of duplicate ACK cannot be always interpreted as an arrival of unordered data. So TCP waits for a small number of duplicate ACKs to be received. If there is only a reordering of the segments, there can be only one or two duplicate ACKs before the reordered segment is processed. However, if three or more duplicate ACKs are received in a row the segment has been lost. TCP then retransmits the missing segment without waiting for the retransmission timer to expire. In practice, TCP waits until it has seen three duplicate ACKs before retransmitting the packet.

segment 1

ack 1

segment 2

segment 3 ack 2

segment 4

segment 5 ack 2

segment 6 ack 2

ack 2

retransmits

segment 3

ack6

Figure 2.6: TCP Dynamic Congestion Control with Fast Retransmit [24]

Figure 2.6 illustrates how duplicate ACKs lead to a fast retransmit. In this example, the destination receives packets 1 and 2, but packet 3 is lost in the network. Thus, the destination will send a duplicate ACK for packet 2 when packet 4 arrives, again when packet 5 arrives, and so on. When the sender sees the third duplicate ACK for packet 2---the one sent because the receiver had received packet 6---it retransmits packet 3. Note that when the retransmitted copy of packet 3 arrives at the destination, it then sends a cumulative ACK to the source for everything up to and including packet 6 [14].

2.5.3 Fast Recovery:

After transmission of the missing segment by the Fast Retransmit algorithm, instead of implementing slow start for continuing the transmission of segments, congestion avoidance is performed. This improvement to congestion control algorithm allows high throughput under moderate congestion, especially for large windows.

It is not advisable to perform slow start in such situation because receipt of the duplicate ACKs reveals that there is still data flowing between the two ends. This is because receiver can only generate the duplicate ACK when another segment is received and is in the receiver’s buffer. So, even if the packet has been lost TCP cannot reduce the flow abruptly by going into slow start since data is still flowing through the network.

Fast Retransmit Algorithm is implemented together with Fast Recovery in the manner that:

1. On receiving the third duplicate ACK, ssthresh is set to one-half the current cwnd but it should not be less than 2 segments. The missing segment is retransmitted and cwnd is set to ssthresh plus 3 times the segment size, which increases the congestion window by number of segments received at the other end.
2. The congestion window should be constantly incremented each time the duplicate ACK arrives to make room for additional segment that has left the network.

The packet is transmitted only if allowed by the new value of cwnd.

3. The ACK which is the acknowledgement caused by the retransmission arrives after one round-trip time after the retransmission. This acknowledgement should acknowledge all the intermediate segments sent between the lost packet and receipt of the first duplicate ACK.

The Fast Recovery algorithm was implemented for the first time in Reno release, followed by the Fast Retransmit algorithm that appeared in the Tahoe release [14].

2.6 TCP Flavors:

2.6.1 Tahoe TCP:

Since nobody knows what is tomorrow’s network will be, modern implementation of TCP contains a number of algorithms to control network congestion and to maintain a good user throughput. Before the implementation of Tahoe TCP, earlier implementations followed a go-back-n model using cumulative positive acknowledgement and requiring a retransmit timer expiration to re-send data lost during transport. But with expanding networks these implementations did little to minimize the congestion problem.

TCP Tahoe added a number of new algorithms to the older implementations. The new algorithms include slow-start, Congestion Avoidance and Fast Retransmit. The modifications of Fast-retransmit algorithm in Tahoe led to subsequent modifications of Tahoe implementation to form the new versions. With Fast Retransmit, after receiving certain number of duplicate ACKs for same TCP segment, the sender infers that the data segment has been lost and retransmits the packet without waiting for a retransmission timer to expire. This leads to higher utilization of channel and connection throughput [14,18].

2.6.2 Reno TCP:

The Reno TCP implementation retains the enhancements incorporated into Tahoe, but modifies the Fast Retransmit algorithm to include Fast Recovery.

The new implementation is better than Tahoe because it prevents the link or resource from going empty after Fast Retransmit, thereby avoiding the need for slow start after loss of a single packet. A TCP sender enters Fast Recovery when it reaches the threshold for duplicate ACKs usually three. When the network detects the loss of a packet, and the sender receives three duplicate ACKs, the sender retransmits one packet and reduces its congestion window by one half.

The implementation of the new Reno can be defined as follows:

1. After the lost of a packet, when the third duplicate ACK is received by the TCP sender, the threshold for the congestion window size is set to:

ssthresh = min (awin, cwnd + ndup)

where, ssthresh = threshold value cwnd = congestion window

awin = advertised window ndup = no of duplicate segments

2. The lost segment is retransmitted and cwnd is set to ssthresh plus 3*MSS. By doing so the congestion window is increased by 3 segments that have left the network and which receiver has buffered.
3. The cwnd is increased by one for each additional duplicate ACK received. This makes room for an additional segment that has left the network.
4. After entering the Fast Recovery and retransmitting a single packet, the sender

effectively waits till half the windows of dup ACKs have been received, and sends a new packet for each dup ACK received. On receiving the ACK for new data called “recovery ACK”, sender exits the Fast Recovery by setting ndup to 0.

Unlike Tahoe implementation, the limitation of Reno’s Fast Recovery algorithm is that it holds good for only a single packet drop. In other words Reno sender can transmit at the most one dropped packet per round-trip time, but suffers from performance problems when multiple packets are dropped [14,18].

2.6.3 New-Reno TCP:

To improve upon the performance of Reno for multiple packet drops and to remove the limitations of the Reno TCP, a newer version New-Reno TCP was implemented by a small change to the Reno algorithm at the sender.

In Reno, partial ACKs take TCP out of Fast Recovery and decrease the size of the usable window to that of the congestion window. Instead in New-Reno, partial ACKs do not take TCP out of Fast Recovery and they are treated as an indication that the packet immediately following the acknowledged packet has been lost and should be retransmitted. Thus, in case of multiple packet loss from a single window, New-Reno can recover without a retransmission timeout, retransmitting one lost packet per round-trip time until all of the loss packets have been retransmitted. In other words New-Reno remains in Fast Recovery until all of the data outstanding when Fast Recovery was initiated has been acknowledged [14,16,18].

2.7 Parameters of TCP:

All the nodes (workstation, LANs, server and routers) which supports TCP as one of its contained protocol provides an attribute called “TCP Parameters” in order to configure various parameters. It also allows us to implement different flavors of TCP.

2.7.1 Maximum Segment Size:

It is the largest amount of data that will be transmitted as one TCP segment. The utilization of the network and performance are the two important factors for choosing a pertinent MSS value. Choosing smaller values of MSS results in poor network utilization, while choosing larger value of MSS degrades the performance by creating many IP datagrams which cannot be acknowledged or retransmitted independently.

Normally it should be set to the maximum size “MAC” layer can handle, minus the size of TCP and IP headers. OPNET can set this attribute to “Auto-Assigned”. Thus it is optimally configured for Data Link layer over which TCP is operating [1, 4, 13].

2.7.2 Maximum ACK Delay:

Normally, TCP does not send an acknowledgement (ACK) immediately on receiving the data. Instead, it waits for data transmitted in the same direction as the ACK, so the ACK can be sent along with the data. This is called piggybacking [13].

It influences the end-to-end delay because if the TCP process receives the data only, the connection process waits for the timer to expire before sending an ACK. This parameter when set to high values results in higher response time. On the other hand if this is set to low value then it may result in too many dataless acknowledgments, which increases in the load on the network [4, 13].

2.7.3 Delayed ACK Mechanism:

There are two ways to control the delayed “dataless” acknowledgements

(i) Clock Based: Here the data less acknowledgement are generated at the expiration of maximum acknowledgment delay timer.

(ii) Segment/Clock Based: Here dataless acknowledgements are generated on receiving every other TCP segment or maximum delay timer expiration, whichever is achieved first [4,13].

2.8 Performance Measures for TCP Connection:

2.8.1 Throughput:

Throughput is one of the important measures of TCP connection performance. Throughput is defined as rate at which it transmits data from the sender to the receiver.

The value of the throughput depends on the congestion window. If the connection transmits n bytes every RTT seconds than the throughput or transmission rate for a connection is given by n/RTT bytes per second.

For example if the transmitting capacity of the link is R and number of connections traversing the link is K then ideally the window size in TCP connections traversing this link should be such that each connection achieves a throughput of R/K. This ideal throughput is valid if the TCP connection is transmitting large amounts of data and that none of these TCP connection traverses any other congested link.

Considering the above discussions if there are N number of links in an end to end connection and the transmission rate of the nth link in that connection is given by Rn and

Number of connections supported by nth link is Kn then ideally the transmission rate (throughput) for this connection is Rn/Kn on the nth link. However, the end-to-end transmission rate for this connection is actually:

r= min ({R1/K1/……, RN/KN)

Switch3

Work Station1

Switch4

Switch1

RN/KN R2/K3 R2/k2

R1/k1

Switch2

Server Side Cloud of Switch Client Side

Figure 2.7: Utilization and Throughput for various links

On the other hand if one of more of the intervening connections is bottlenecked at some other link, that is, on some other end-to-end path, then it cannot use their bandwidth share, Rn/Kn. Under this condition r would be higher than min {R1/K1, R2/K2…. RN/KN).

This effect of congestion on the throughput for a given connection will be explored in the Section 4.3.2. We experimented with 3 LANs and 4 Workstations injecting data into Ethernet Switch through seven links of 10BaseT capacity. In turn this outputs the data into one link of only 10BaseT capacity. Our results in Section 4.3.2 show that utilization achieved was higher by some links and poor in some others [21].

2.8.2 Fairness:

Assumptions:

1. Let two TCP connections share a single link with transmission rate R.
2. Suppose the value of MSS and RTT for the two connections is same so that the throughput achieved by both is equal.
3. The TCP connections operate in congestion avoidance mode rather than slow start mode.

R

Equal Bandwidth Share

Full

Bandwidth

Link 2

Utilization D

B

C A

Link1 Utilization R

2.8 Utilization realized by Link1 and Link2 [21]

If both the connections are to share the link bandwidth equally then the throughput should have value around “equal bandwidth share” line. Ideally the sum of the throughputs should equal R. It is not desirable for the one link to have transmission rate at R while the other has a transmission rate of 0. So the throughput achieved by bottleneck links should fall near the intersection of the “equal bandwidth share” line and “full bandwidth utilization” line.

As shown in Figure 2.8, suppose the throughput realized by link 1 and link 2 is given by point A at a certain time. As the amount of link bandwidth jointly consumed by two links is less than R, no loss occurs and hence both the connection will increase their window size by 1 per RTT, as we assumed it operated in congestion avoidance mode. Thus the joint throughput of both the connection proceeds along a 45-degree line starting from point A. When the link bandwidth consumed jointly by the two links becomes greater than R, packet will drop. Suppose the packet loss occurs at point B. Links 1 and 2 then decrease their congestion window by a certain factor when the throughput realized by both links is given by point C. As the combined bandwidth used is less than R at point C, the two links again tries to increase their throughput along 45-degree line. Again loss occurs and the two links decrease their throughput. Ideally this will continue and the utilization achieved by both links should proceed along a 45-degree line [21].

However after simulating TCP Reno network and collecting throughput statistics on various links, our results shows that the throughput achieved by both the links does not proceed along a 45-degree line. Further results and analyses will be given in Section 4.3.1.

2.8.3 Slow Start Initial count:

All TCP implementations use slow start in one of three different ways:

1. When a new connection is started (initial window).
2. To restart a transmission after a long idle period called application

limited phase. (restart window)

3. To restart after a retransmit timeout (loss window)

i) Advantages of Larger Initial Windows:

1. When the slow start count is kept to one segment, the receiver that generates delayed ACKs has to wait for a timeout to occur before generating an ACK. On the other hand, by keeping the slow start initial count to two segments, the receiver will generate an ACK after the second data segment arrives, usually 0.02 seconds later.
2. Increase in slow start initial count reduces the transmission time for connections transmitting a small amount of data. For transfer less than 4k bytes, the larger initial window reduces the data transfer time to as small as single RTT.
3. For connections, which can to use large congestion windows, this modification eliminates up to three RTTs and a delayed ACK timeout during the initial slow-start phase. This would particularly benefit high-bandwidth large-propagation delay TCP connections.

We simulated TCP Reno network by increasing the value of a slow start count to 4 and compared it to Reno network with slow start count 1, keeping all the other parameters the same. As the HTTP Object size was set to 1000(i.e. small) our results in Section 4.3.5 showed that there was considerable decrease in the object response time of HTTP traffic.

ii) Disadvantages of Larger Initial Windows for Individual Connection:

Sometimes it is better to start with an initial window of one segment in high-congestion environment. It has been observed that TCP starting with an initial window of one segment has few or no drops while a connection starting with an initial window of four segments might experience unusual retransmits due to the inability of the routers to handle small bursts, resulting in unnecessary retransmit timeouts. For a large-window connection that can recover without a retransmit timeout, this could result in needlessly early transition from slow start to the congestion-avoidance phase.

The chances of these premature segment drops are much less in uncongested networks with sufficient buffering or in moderately congested networks where the congested router uses active queue management. Although an increase in initial window size results in premature segment drop, the performance of TCP can be improved upon in two ways:

1 If the connection recovers from the segment drop without a retransmit timeout.

2 The congestion window maintained by TCP connection is kept small either by either the network congestion or by the advertised window.

Certain TCP connections will receive better performance with the higher initial window even if the burstiness of initial window results in premature segment drops.

iii) Disadvantages of Larger Initial Windows for the Network:

There are three main effects of increasing the slow start count on network performance.

1. There are chances of many segments on congested links being duplicate segments, which are received by the receiver. (However it was observed that might result in large number of packet drops but would not result in transmission of a large number of duplicate segments.
2. There are many segments on the congested link that would be dropped later in the network before reaching their final destination. (It was observed that the number of segments dropped later in the network before reaching the final destination was the same as that observed by keeping the initial slow start count to 1)

The increase in slow start count affects other traffic in the network by increasing the general packet drop rate in the network. This is because routers with drop tail queue management have difficulties with bursty traffic in times of congestion

We simulated TCP Reno network with slow start count set to 4 and compared it with the other TCP Reno network with slow start count set to 1. All other parameters in both the scenario were configured to be same. Our results in Section 4.3.5 shows that there was increase in the queuing and hence the scenario with slow start count set to 4 resulted in the considerable packet drops.

iv) Level of Burstiness for TCP traffic:

A larger value of slow start count does not significantly affect burstiness of TCP traffic.

This is because infact the nature of Internet traffic is bursty itself [17,20].

2.8.4 Receiver Buffer and Receive Buffer Usage Threshold:

Besides the Maximum ACK Delay and Delayed ACK Mechanism, application delay also depends on these parameters. The value of Receive Buffer and Buffer Usage Threshold affects the TCP connection’s window size. The size of the receive buffer is specified in bytes. The default and normal size of the receive buffer is kept to 8760 bytes. The decrease in buffer size results in larger queuing and hence in larger packet drops and increases the chance of congestion in the network. For a novice it is easy to believe that providing a large buffer can decrease congestion in the network. However the increased value of the buffer size only delays congestion. Also, when congestion gets in, it will last much longer and will be more severe.

Receive Buffer usage threshold determines when data should be transferred from the TCP’s receive window to the application, thereby increasing the size of receive window. At the same time, if the buffer threshold value is kept higher, it results in higher application response time. The amount of space available in receive window is the advertised window. The amount of data transmitted at particular instant in a network is highly dependent on advertised window. This is because it is the maximum amount of data that a sender can transmit. As the receive buffer fills, the size of the advertised window keeps decreasing and hence puts a limit on amount of data a sender can transmit. A higher threshold value will keep data in the receive buffer for a longer time and hence increase the delay. In short, a higher value of threshold increases the application response time. A low value allows data from the receive buffer to be transferred to the application more often and hence the advertised window is always close to the full size window. This increases the chances of congestion and hence packet drop [4,14].

Chapter 3 –Design of TCP Network Model

3.1 TCP Design Approach:

The primary approach to the performance analysis of the TCP model was to build a network topology suitable for such study. The network was based on study of high performance network test beds. The TCP network that we designed and implemented is a heterogeneous network consisting of wide variety of network components, which are typical of the Internet today.

Fig 3.1: TCP Network

The network is capable of handling a broad spectrum of application needs like ftp, remote login, database etc. Users of the network have different needs in terms of the data traffic and type of data the users request from the server. The users of the network have different profiles, and each profile consists of a particular set of applications in a specific proportion. For example a particular user might need applications like http (heavy browsing), e-mail (light), ftp (medium load); at the same time another user might need different applications or same applications in a different proportion. All these issues have been taken care of and implemented in the network we have designed. The network traffic pattern is also an important criterion while performing any network or protocol analysis, because the performance or behavioral response of a network or a protocol changes when the traffic packet distribution, attributes of distribution or protocol implementation varies. We have varied these attributes for network analysis, and analyzed the results in different cases.

3.2 TCP Protocol Behavior:

The TCP model suite of OPNET model library provides following features:

Reliability	The model provides retransmission timers that trigger acknowledgments and retransmissions as and when required.
Flow Control	Window size is dynamically controlled per availability of buffering resources at receiving nodes.
Resequencing	The models supports reordering of data segments arriving out of order.
Connection Setup and Termination	TCP model uses three-way handshake protocol for connection setup and termination.
Algorithms	The TCP model of OPNET supports implementation of following algorithms Slow Start for Congestion Control Nagle’s for Silly Window Syndrome Avoidance Karn’s for avoiding retransmission ambiguity Fast Retransmit and Fast Recovery Window Scaling Selective Acknowledgment Increased Initial Window Option
Persistence Time-out	Timer enabling sending node to send one byte segments to receiving node with a very small window size to poll a remote socket.

3.3 TCP Design Basics:

The network components of the TCP model are made up of the following basic

components:

• Servers-These accept and respond to http, ftp or other requests from client

workstations.

• Workstations-These send and accept http, ftp or other requests to and from

servers.

• Routers-A collection of these makes up the Internet cloud and primarily route

packets to destinations.

• Switch-This has the same function of switching packets to destinations.
• LAN-An aggregation of several workstations which also interact with the servers

in terms of http, ftp or other requests.

• Links-These represent the cables or transmission medium for data traffic.

OPNET provides a choice of vendors to choose the above components .The following sequence of steps were carried out after the initial network topology was constructed.

1. Define applications supported by the network and profiles of users.
2. Set supported applications and profile in each node model.
3. Verify link consistency of the network.
4. If link consistency is verified, go to step 5, or replace links and perform step 3 again.
5. Configure simulation options and run simulation.
6. View results and compare against expected results.
7. If results conform to expected outcome, record and analyze results or change network configurations and perform steps 1-7.

TCP Node and Link Models Used in TCP Network:

Server Model (ethernet_server_adv)	The ethernet_server_adv model provided by OPNET represents a server node supporting server applications running over TCP/IP and UDP/IP. It supports one 10Mbps, 100Mbps and 1Gbps Ethernet connection. FCFS algorithm is used to route the packets. The protocols supported by this model are: RIP, UDP, IP, TCP, Ethernet, Fast Ethernet, and Gigabit Ethernet Interconnections.
Workstation (ethernet_wkstn_adv)	The ethernet_wkstn_adv model provided by OPNET represents a workstation with applications running over TCP/IP and UDP/IP. Like Ethernet server this model supports one 10Mbps, 100Mbps and 1Gbps Ethernet connection. The protocols supported by this model are UDP, IP, Ethernet, Fast Ethernet, Gigabit Ethernet, RIP, TCP, and OSPF.
LAN (10BaseT_LAN & 100BaseT_LAN)	It represents Ethernet LAN in a switched topology. This model supports applications like FTP, Email, Database, Rlogin, HTTP, etc. It has a default switching speed of 50,000pkts/sec, and number of workstations equal to 10 and 100.
Ethernet Switch (ethernet16_switch_adv) Router (CS_12016_16s_a10_fe8_ge3_s124_adv)	This is a switch model that supports upto 16 Ethernet interfaces. This model supports Spanning Tree Bridge Protocol and Ethernet. CS_12016_16s_a10_fe8_ge3_s124_adv represents CISCO 12000 series router. The RIP and OSPF protocol may be used to automatically and dynamically create the routing tables and select routes in an adaptive manner. It supports IP forwarding rate of 60,000,000 packets/sec. The “store and forward” switching methodology is used by router. The protocols supported by this model are Ethernet, Token Ring, (IP) Internet Protocol, (RIP) Routing Information Protocol, (UDP) User Datagram Protocol, (OSPF) Open Shortest Path First Protocol, (BGP) Border Gateway Protocol, (IGRP) Interior Gateway Routing Protocol, (EIGRP), and Enhanced Interior Gateway Routing Protocol.
Access Router (CS_7000_6s_e6_f_fe2_fr4_s14_tr4_adv)	(CS_7000_6s_e6_f_fe2_fr4_s14_tr4_adv) represents CISCO 7000 series router, which has the specific configuration of an IP-based router gateway protocol. It has an IP forwarding rate of 150,000 packets/second. Like 12000 series router this router model implements “store and forward” type of switching methodology. The protocols supported by this router are Ethernet, Token Ring, IP, RIP, UDP, OSPF and Frame Relay.
Links (10BaseT and 100BaseT)	The 10BaseT and 100BaseT link are link models that are capable of transmitting at 10Mbps and 100Mbps datarate. These link models can connect Station 4. Switch Hub (except Hub to Hub) 5. LAN nodes Bridge Switch
OC3 link	This model connects two nodes running IP. It can transmit at a rate of about 148.61 Mbps

3.4 Available Statistics:

On simulating the network to analyze the performance of TCP protocol several statistics can be collected. These statistics can be collected on the base of per-TCP connection, per-node or global.

3.4.1 TCP Characteristics:

Node (and global based) statistics are helpful in studying all processes running in a node (and network) collectively. It also helps to know total flow of traffic traveling through the TCP layer.

Figure 3.2: Statistics available for study of TCP Performance

3.4.2 TCP Connection Characteristics:

This group of statistics particularly helps to study the establishment and termination of TCP connections. They are particularly useful for studying low-level TCP performance metrics. “Congestion window” maintained at each connection process can also be known.

Figure 3.3: Statistics Available for Study of TCP Connection

3.4.3 Link Statistics:

This group of statistics particularly helps in studying the behavior of the links and various performance measures such as queuing delay and throughput [13].

Figure 3.4: Available Link Statistics

Chapter 4- Results and Analysis of TCP Model

4. 1 Congestion Window Analysis:

4.1.1 Congestion Window in Tahoe TCP:

TCP’s congestion window controls the number of packets a TCP flow can have in the network at any time. In other words it puts a limit on amount of data TCP sender can transmit without receiving acknowledgement from the receiver. Tahoe uses Slow Start, Congestion Avoidance and Fast Retransmit Algorithms for congestion control.

Figure 4.1: Congestion Window in TCP Tahoe

As shown in the Figure 4.1, the congestion window grows exponentially from its initial window size as it goes on receiving acknowledgements. Ideally the window size should increase exponentially up to its threshold (65536 bytes), but at certain point (22000) time-out occurs and the sender does not receive an acknowledgement from the receiver. The network identifies this as a packet loss in the network, the intermediate router is fully utilized and it starts discarding packets, so there is no more increase in the size of the congestion window.

As seen in our Figure 4.1, congestion window increases exponentially from 7500 bytes to about 22000 bytes. TCP is in slow start phase from about 2.5 to 3.2 seconds and the congestion window remains flat from 3.2 to 5.5. Then, TCP decreases the congestion window size. The reason for congestion window remaining flat is explained later.

Now the congestion window size is set to 22000 bytes and congestion threshold is set to almost half the previous congestion window size equal to 15000 bytes. TCP, knowing that there is a packet loss, restarts the slow-start algorithm as seen at 6 sec in Figure 4.1. It increases the window size exponentially as it receives the acknowledgement. But this time it does not increase the window exponentially until congestion appears. Instead, it grows exponentially till the value reaches congestion threshold (15000 at 6.5 seconds). Once it has reached congestion threshold, it increases the congestion window size linearly. TCP is now in the second phase (congestion avoidance phase from 6.5 seconds to 7.8 seconds) and increases the window size linearly. Again the congestion window remains flat from 7.8 seconds to 13.8 seconds and then the congestion window decreases to one segment.

As we saw, the congestion window remained flat from 3.2 to 5.5 seconds and again from 7.8 seconds to 13.8 seconds. These are two possible reasons for this result:

First:

The applications and profiles in the network have been configured in such a way that traffic is generated after every specific interval of time.

Application Limited Phase:

TCP’s congestion window gives idea regarding the number of packets sender should send knowing the current state of the network. Congestion window is set using an Additive –Increase, Multiplicative –Decrease (AIMD) mechanism that probes for the available bandwidth, dynamically adapting to the changing network conditions [15,19].

This mechanism shows ideal behavior when sender continually has data to send i.e. for bulk-data transfer. Under this condition the sender is limited to transmitting data by the congestion window. This period is termed Network-limited period. During this period, sender is transmitting data equal to the full window.

However, the above mechanism does not give same performance for idle periods between bursts such as web page replies. Also, when TCP is used for applications like telnet, the data sender often has little or no data to send. The sending rate is determined by rate at which the user generates data. A period when the sender transmits less data than is allowed by the congestion or receiver window is called application limited period. Times when there are no traffic in a node is called an Application Limited phase. A long period during which the sender is application limited leads to invalidation of the congestion window. An invalid congestion window results when the congestion window increases (as in the slow start or congestion avoidance phase) during application-limited phases, when the previous value of the congestion window is not fully utilized [15].

As seen in Figure 4.1,an invalid congestion window is obtained at 22000 bytes, from 3.2 to 5.5 and 7. 8 to 13.8.

When the TCP sender is application limited from 3.2 to 5.5 seconds, the currently available capacity represented by the congestion window may gradually become less accurate over time. In other words, the capacity that had once been used by the network-limited connection might now be used by other traffic.

Hence, after application-limited phase, the restart is implemented using the slow start behavior. Much research work has been done to improving the restart of these idle TCP connections. Current implementations either enforce slow start after remaining idle or donot reduce their congestion window, instead using the prior congestion window size and increasing the window size there on. However the former conservative approach, leads to low effective throughput and the latter approach sends a large burst of back-to-back packets, overflowing the buffers and leading to subsequent packet loss [15].

Second:

The congestion window remains flat because there are no ACKs arriving because several packets were lost. The implementation of TCP timeouts led to long periods of time during when connection remained dead waiting for a timer to expire. In fact, no new packets are sent during this time. A timeout eventually occurred when the congestion window was halved.

4.1. 2 Congestion Window in TCP Reno:

The Reno flavor of TCP uses all the four algorithms for congestion control. They are, Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery.

Figure 4.2: Congestion Window in TCP Reno

As shown in Figure 4.2 the congestion window increases exponentially starting with initial window size as it receives ACKs in a manner similar to TCP Tahoe. Buffer size was set to 5760 bytes during this simulation. Ideally this congestion window size should increase to 5760; however when the sender does not receive the ACKs from the receiver, the network sees that it is congested and prevents the congestion window from growing further. As shown in Figure 4.2 the network gets congested when the congestion window size is equal to 4300 at 12 seconds. Congestion window is in slow start phase from 10.7 to 12 seconds.

4.1.3 Comparison of Congestion Window With Tahoe:

As far as congestion window is concerned, the Reno’s implementation is different from Tahoe’s because Reno uses Fast Recovery algorithm along with Fast Retransmit Algorithm. Accordingly, as shown in Figure 4.2, when the network does not receive ACK at 4300, it waits for three duplicate ACKs to get from the receiver so as to confirm that the ACK was not received due to out of order data segments, rather than packet loss. When it receives three acknowledgements, the sender considers it a packet loss, but the arrivals of ACKs from the destination reveals that there is still a data transfer between the source and the destination. So instead of decreasing the congestion window size to one segment as we see at 13.2 seconds, it decreases the window size to half the previous congestion window (when loss occurred) and then increases the size of the window linearly up to 3700 bytes at 13.5 seconds. Hence the congestion window is in congestion avoidance from 13.2 to 13.5 seconds.

When the congestion window size reaches 3700 bytes it again enters the application-limited period (time when there is no traffic at particular node or network). Reno remains in the application limited phase from 14 to 15 seconds. At about 15 seconds Reno restarts this idle connection from the current congestion window size threshold and then increases it linearly [15].

4.2 Comparison of TCP Reno and TCP Tahoe:

4.2.1 FTP and HTTP Response Time:

Simulations were carried out on two different flavors of TCP. All the parameters were configured to be identical in both the scenarios to understand the implementation of TCP Reno and TCP Tahoe.

Figure 4.3: HTTP Object Response Time in TCP Tahoe and Reno

Figure 4.4: HTTP Page Response Time in TCP Tahoe and Reno

Figure 4.5: FTP Download Response Time in TCP Tahoe and Reno

As seen from Figures 4.3, 4.4 and 4.5 the response time for HTTP and FTP traffic is almost the same for both Tahoe and Reno.

Studies shows that ideally the download and upload response time should be less and much more better in TCP Reno than in Tahoe. This is because, when the receiver receives unordered segments, TCP Reno implements Fast Recovery algorithm as compared to TCP Tahoe that allows the congestion window to start from a threshold value equal to half of the previous congestion window instead of from slow start from initial segment size of 1.

However, as we see from the above figures, not much considerable difference is observed in the HTTP and FTP response time in TCP Reno and Tahoe implementation.

One possible interpretation is that, there may be fewer unordered segments received by the receiver from the sender. Instead there were more packet drops. So there may be fewer chances of congestion window size being initialized to size equal to the threshold value and fewer chances of fast recovery in Reno.

4.2.2 Queuing Delay:

Simulations were performed on TCP Reno and Tahoe to compare the performance of these two regarding queuing. All the parameters were configured identical in both the scenarios and Pareto distribution was chosen.

Pareto was chosen to study the effect of the bursty traffic that represents current Internet traffic. Bursts in the traffic lead to buffering of the packets at the intermediate routers. Buffering leads to queuing of the packets at these routers and queuing in turn leads to delay in the transmission of the packets, which is one of the reasons for congestion in the network. The congestion causes packet drops in the network and this packet drop increase with any increase in queuing and hence the queuing delay.

As we see in Figure 4.6, queuing delay starts at about 3.5 seconds in both Tahoe and Reno, increases gradually, achieves its maximum value at about 6 seconds and then decreases gradually. Figure 4.6 shows that the queuing delay in TCP Reno, observed at 6 sec is as low as 0.0032 seconds as compared to TCP Tahoe queuing delay of 0.0062 seconds (almost double to that of Reno).

Figure 4.6: Queuing Delay in TCP Tahoe and Reno

Thus, there is a larger buffering and queues in the TCP Tahoe as compared to Reno due to congestion that causes additional delays called queuing delay.

4.2.3 IP PACKET DROP:

The packet drop in the network is directly proportional to increased queuing due to congestion. As we saw earlier there is larger queuing in TCP Tahoe than in TCP Reno, so the queue overflows. The routers start discarding packets because of queue overflowing, called congestion; these packet drops increase with the increased queuing.

Figure 4.7: Comparison of IP Packet Drop in TCP Tahoe and Reno

There is a larger queuing delay in TCP Tahoe and as packet drop is directly proportional to increased queuing, the packet drop should be higher in TCP Tahoe than Reno.

Our simulation result proves the above fact. As shown in Figure 4.7 the packet drop is more in TCP Tahoe than TCP Reno. If we consider the period from 3 to 9 seconds, the minimum and maximum values of the packet drop in TCP Tahoe are 90 packets/second (at 4.7 seconds) and 3000 packets/second (at 8.3 seconds) respectively. On the other hand the packet drop in TCP Reno is 500 packets/second (at 4 seconds) and 1200 packets/second (at about 7 seconds) respectively. Thus the packet drop in TCP Tahoe is as almost double as compared to that of Reno.

4.2.4 Comparison of TCP Tahoe and TCP Reno:

Performance Metrics	TCP Tahoe Implementation	TCP Reno Implementation
Congestion Window	No Fast Recovery	Fast Recovery
Response Time	Almost same	Almost Same
Queuing Delay	0.0063 seconds	0.0032 seconds
Packet Drop	3000 packets/second	1200 packets/second

Thus TCP Reno gives almost same response time at the cost of larger queuing delay and hence more packet drops compared to TCP Tahoe. We can conclude that implementation of congestion control is better in Reno than in Tahoe.

4.3 Performance Measures of TCP Connections:

4.3.1 Fairness:

Simulation was carried out on Reno implementation of TCP for about 18 seconds to study issue of fairness in TCP congestion control.

Consider the bottlenecked link 10baseT having transmission capacity of 10Mbps which connects access_router2 to ethernet_switch_adv2. This link connecting ethernet_switch_adv2 to 3 LANs and 4 other workstations is shared by 614 other sources. Thus, 614 sources are sharing the bottlenecked 10baseT link. Ideally each source should transmit at their fair share of 0.0162Mbps(10Mbps/614). However, Figure 4.8 shows the link connecting ethernet_switch_adv2 <-> lan8 transmits at more than 8.75Mbps. It means each source connected to that link is transmitting at rate 0.029Mbps, which is higher than its fair share of 0.0162 while the link connecting ethernet_switch_adv2<-> workstation2 transmit at about 0 Mbps much below its fair share of 0.016 Mbps.

Figure 4.8: Comparison of Utilization Achieved by various Links

The table below shows the comparative utilization obtained by 7 links transmitting data to one bottlenecked link.

Link considered	Utilization (Approximately)
ethernet_switch_adv2 <-> lan8	87.5
ethernet_switch_adv2 <-> lan10	25
ethernet_switch_adv2 <-> lan9	47.5
ethernet_switch_adv2 <-> wkstn1	Almost 0
ethernet_switch_adv2 <-> wkstn2	Almost 0
ethernet_switch_adv2 <-> wkstn3	1.43
ethernet_switch_adv2 <-> wkstn4	1.43 Mbps

The above table obtained from simulation results clearly shows that the link connecting ethernet_switch_adv2<->lan8 uses share of the other links and transmits at much higher rate than its fair share. On the other hands the link connecting ethernet_switch_adv2 <-> workstation0 achieves throughput as low as 0 (much below their fair share). This is because the connections in link connecting ethernet_switch_adv2 and workstation might be congested at some other point along the end-to-end connection [4].

4.3.2 Link Utilization and Throughput:

Throughput is the data transfer rate actually achieved by the application. Useful throughput is the packets actually sequentially delivered to the end application without errors or loss.

Figure 4.9: Comparison of Throughput Achieved by various links

In our simulation we considered the link connecting Ethernet_switch_adv2 and LAN8 having the transmission capacity of 10 Mbps. The number of connections through this link is 4000 at 9 seconds. Ideally all the 4000 connections should have throughput of 0.0025Mbps(10Mbps/4000). However as we see, the throughput obtained for each connection of the link connecting ethernet_switch_adv2 <-> lan8 was 0.002Mbps(8Mbps/4000)

This is because, as discussed in Section 2.8.1, the throughput achieved by a connection is the minimum of the throughput achieved by all the connection across the end-to-end connection. So the connection on the link connecting ethernet_switch_adv2 and LAN8 achieves poor throughput because some other link along which the connection is being traversed might be congested and would not be able to transmit more that 0.002Mbps.

4.3.3 Effect of Increasing File Size and Decreasing the Buffer Size:

We simulated two different scenarios for Reno implementation. The object size (for HTTP application) and file size (for FTP applications) for the first one was configured respectively as 1000bytes and 50000 bytes. The object and file size for the other scenario was configured as 5000 bytes and 75000 bytes respectively. Also we decreased the buffer size for the second scenario from 8760 to 5760 bytes and increased the interarrival time from pareto (1.3,1.5) to pareto (1.5,1.7). The effect of increased file size and decreased buffer size on various performance measures was studied.

i) Queuing Delay:

As defined earlier, queuing delay is the amount of delay achieved by the packet while remaining in the queue due to buffering.

Figure 4.10:

Queuing Delay Increase due to File Size Increase and Buffer Size Decrease

For the same Reno implementation, increasing the file size and inter-request time and decreasing the buffer size resulted in considerable increase in the queuing delay.

As seen in Figure 4.10, at 7 seconds normal implementation resulted in queuing delay of 0.0030 seconds while the increased file size and decreased buffer size resulted in queuing delay of 0.0055 seconds. Segmentation of the packets due to increased file size causes additional delay in transmission. This in turn causes into increased queuing at the router because router uses store and forward mechanism for transmitting packets. This in turn, results in congestion of the link and network, which causes increased packet drops.

ii) IP Traffic Dropped:

As discussed earlier, the increase in the file size and decrease in the buffer size

results in considerable increase in queuing and hence considerable increase in packets dropped.

Figure 4.11:

Packet Drop Increase due to File Size increase and Buffer Size decrease

As seen in Figure 4.11 there is a considerable drop in the traffic due to an increase in file size and a decrease in buffer size. One possible reason is that the router uses store and forward technique for forwarding the packets, but because of lowered buffer size, packets cannot be stored at the router and hence get dropped.

This is supported by our simulation results shown in Figure 4.11. As shown, if we consider the period from 3 to 9 seconds, packet drop with normal Reno implementation is 1200 packets/sec at about 4 seconds and minimum of about 500 packets/sec at about 7 seconds. The packet drop observed when the file size was increased and buffer size was decreased was as high as 3300 packets/sec at about 6.5 seconds and as low as 100 packets/second at about 8.5 seconds. Thus, the average packet drop was higher in the scenario with increased file size and decreased buffer size.

iii) HTTP Response Time:

Figure 4.12:

Effect of Increasing File Size & Decreasing Buffer Size on Response time

The above statistics were collected when the object size in the HTTP application was increased from 1000 bytes to 5000 bytes. As we see there is a considerable increase in the object response time of HTTP application. This is due to the increased object size. Due to increase in the object size from 1000 bytes to 5000 bytes, the object takes much longer to download when requested, which results in increase of the response time. This results into slower performance of the applications.

This is supported by our simulation results. As seen in Figure 4.12 the response time at 9 seconds for normal Reno implementation was about 0.53 seconds and the response time observed when object size was increased was about 0.90 seconds.

The statistic shown below was collected when the inter-request time for the page was increased from pareto (1.3,1.5) to pareto (1.5,1.7). Both statistics were collected on Reno implementation.

4.13: Effect of Increasing the Inter-Request time on Http Page Response

An increase in inter-request time results in an increase in the number of pages per second requested by all the clients. As number of pages requested per time increases, the page response time increases. This is supported by our simulation results.

As shown above, results collected by us gave response time for normal Reno implementation to about 0.95 at 7 seconds, while increased inter-request time increased the response time to about 1.20 to 1.75 as seen at 7 seconds.

Figure 4.14: Effect of Increasing File size on FTP Download response

The statistic shown in Figure 4.15 was collected when the file size of the FTP object was increased from 50000 to 75000 and the buffer size was decreased. As the file size increases the time taken to download increases. Hence the FTP downloads time increases. This was supported by our results. As we see, the download response time for FTP traffic at 7 seconds was about 1 second at 7 seconds while it is about 1.25 at 7 seconds and there is a considerable increase later as well.

Figure 4.15:

Effect of Increasing File Size on FTP Download Response Time

iv) Comparison of Increased File Size and Decreased Buffer Size

:

Performance Metrics	TCP Reno Normal Implementation	TCP Reno Implementation With Increased File Size And Decreased Buffer Size.
Queuing delay	0.0030 sec	0.0055 sec
IP Packet Drop	1200 packets (max)	3300 packets (max)
HTTP Object Response	0.53 sec	0.90 sec
HTTP Page Response	0.95 sec	1.30 sec
FTP Download Response	1.0 sec	1.25 sec

Thus increased file size and decreased buffer size resulted into increased queuing delay, larger packet drop and higher HTTP and FTP response time. So it is not advisable to either increase the file size or to decrease the buffer size.

4.3.4 Increased Buffer Size:

As we have seen, the decrease in buffer size resulted in increased congestions and hence increased packet drop. It seems to claim that this increased congestion and packet drop can be solved by allocating larger buffer. So we increased the size of the buffer to 658330. Ideally, the increase in buffer size tempts us to think that increased space for storing the packets may lead to decrease in the congestion. However this solution merely delays congestion and instead results in increased queuing. Thus, queuing delay is greater when the buffer size is increased. Also, when congestion takes place, it will last much longer and will be more severe. This in turn results in increased packet drop rate. This fact is supported by the graph collected from the simulation.

i) Queuing Delay:

Figure 4.16:

Queuing Delay for Buffer Size Decrease and Buffer Size Increase

The above statistic (Figure 4.18) was collected by simulating Reno implementation of TCP network. It shows the comparison of the increasing queuing delay for normal Reno implementation, decreased buffer size and increased buffer size. It can be seen that queuing delay increases by decreasing the buffer size from 8760 bytes to 6750 bytes. Moreover, as we said earlier, it would be easy to claim that this queuing delay will decrease by providing a large buffer. However, as discussed earlier and as seen in the above graph, the queuing delay increases with increasing the buffer size. As we see, the queuing delay at 7 seconds for Normal implementation is 0.0030 seconds, for buffer size decrease is 0.0055 seconds and 0.0062 seconds when the buffer size is increased.

ii) IP Packet Drop:

As seen from the above graph when buffer size is increased from normal, there is considerable increase in the packet drop. For the period from 3 to 9 seconds the maximum packet drop is 1200packets at 4 seconds for normal implementation, increases to 3300 packets at 7 seconds by decreasing the buffer size and increases further more to about 3800 packets at 3.5 seconds when the buffer size is increased.

Figure 4.17: IP Packet Drop for Buffer size Increase and Buffer Size Decrease

iii) Comparison of Increased Buffer Size:

Performance Measure	Normal Reno	Decrease Buffer Size	Increase Buffer Size
Queuing Delay	0.0030 sec	0.0055 sec	0.0006 sec
IP Packet Drop	1200 packets	3300 packets	3800 packets

Thus, results obtained from these statistics show that increasing the buffer size causes increase in the queuing delay and hence increased packet drops.

4.3.5 Slow Start Initial Count:

The statistic shown below was collected when the slow start initial count for TCP was increased from 1 to 4. Simulation was performed on Reno implementation of TCP networks.

i) HTTP Object Response Time

Figure 4.18: Effect of Slow Start Initial Count on HTTP Response Time

As seen in Figure 4.18, the object response time decreases considerably when the value of slow start initial count is increased to 4 segments. The object response time is about 0.3 seconds at 9 seconds when the slow start initial count is set to 4. While the object response time is 0.5 seconds at 9 seconds when the slow start initial count is set to 1.

Moreover as we see in Figure 4.18, the response time continues to increase even after 9 seconds in the scenario with slow start count set to 4. This is because when the slow start count is set to 1, the receiver has to wait for a timeout to occur before generating an ACK. By keeping the slow start initial count to 4, the receiver will generate an ACK after 4 data segments will arrive. This will eliminate the unnecessary wait (particularly for small objects) for the receiver to send an ACK.

When the simulation was carried out, the object size was kept to 1000 bytes only. This is one reason for the decrease in the response time with an increase in the initial count. Thus, we could conclude that increase in slow start count reduces the transmission time for connections transmitting small size data or small amounts of data. For transfer of less than about 4kbytes, the slow start initial count set at 4 will reduce the transmission time.

ii) IP Packet Drop:

The graph below shows the statistic for Reno implementation that was collected to study the effect of increasing the slow start initial count from 1 to 4.

As shown in Figure 4.19, an increase in the slow start initial count resulted in considerable increase in packet drop. The drop rate in the Reno version of TCP with slow start count at one is quite uniform as compared to drop rate in Reno version with slow start count at four. The maximum drop is achieved by keeping slow start count at one was 1200packets/seconds, while that achieved by keeping slow start count at 4 was as high as 9200packets/seconds.

This is because the number of duplicate segments on the congested link increases which results in large numbers of packet drops. TCP starts with an initial widow of one segment as seen in Figure 4.19 and has few or no drops; the connection starting with an initial window of four segments results in more packet drops because the routers cannot handle small bursts which causes unnecessary retransmit timeouts.

Figure 4.19: Effect of Slow Start Initial count on IP Packet Drop

(iii) Effect of increase in Slow Start Initial Count on Response time and Packet Drop:

Performance Measures	Slow Start Count = 1	Slow Start Count = 4
Response Time	Less for small object size	More for small object size
IP Packet Drop	1200 packets (max)	9200 packets (max)

Thus, it can be said that increasing the TCP slow start initial count to 4 results in a better object response time for small objects at the cost of increased packet drops.

Chapter 5-ATM and ABR congestion control

5.1 Introduction to ATM:

Asynchronous Transfer Mode (ATM) is a method of multiplexing and switching that supports a variety of services. ATM is a connection oriented packet switching method that provides Quality of Service (QoS) guarantees. ATM was developed in the mid 1980s to combine the advantages of packet switching and Time Division Multiplexing (TDM) and incorporates features of both the methods. In ATM all information is converted into short fixed length packets called cells along with abbreviated headers .ATM is packet based and thus can easily handle services that generate bursty traffic and have variable bit rates. The short fixed size of cells result in reduced delay and increased speed [4,8].

Figure 5.1 shows the working of an ATM Multiplexer. Information flow originating from different users are converted into cells and sent to an ATM Multiplexer where they are arranged into queues. A scheduling algorithm then determines the order in which the cells will be transmitted from these queues. The scheduling algorithm takes into consideration the different qualities of service requirements of each information flow. The name asynchronous evolved from the fact that in ATM transmission of cells is not synchronized to any frame structure as happens with TDM systems.

MUX

Voice

Data Packets

Images

Figure 5.1: ATM Multiplexer [1]

ATM is a connection-oriented method requiring a connection-setup prior to the transfer of cells. Such a connection setup requires the source to provide a traffic descriptor which sets out rules for the way cells are generated, e.g. peak cell rate in cells/second, sustainable (average) cell rate in cells/second and maximum length of a burst of cells. The source specifies a set of QoS parameters that the connection will have to provide e.g. cell delay, cell loss and cell delay variation. The connection-setup defines a path through the network that conform to these requirements. A connection admission control protocol is implemented at every multiplexer along the path and this path is known as a Virtual Channel Connection (VCC). A series of local identifiers at the input port to each switch between source and destination are defined during connection setup and these identifiers establish a VCC.

Figure 5.2 describes the tables associated with input ports of an ATM switch. Cells from a voice stream arrive with identifier 32 at input port 5.At the same port cells from a video stream also arrive wit identifier 25. The table look up for entry 32 indicates that the cell must be transferred to output port 1 and the identifier must be changed to 67. Similarly, cells with identifier 25 are switched to output port N with identifier 75. The identifiers are local to each port and same identifier can be used for a different VCC.

25 N 75

32 1 67

32 3 39

61 2 67

Voice 67

1

	Video 25			Voice 67
		Voice 32

5

		Data 39
Data 32	Video 61

Video 75

6

N

Figure 5.2: ATM Switching [1]

ATM uses some of the concepts of SONET, thus allowing flows having a common path across the network to be grouped together. This aggregation is called a virtual path.

Figure 5.3 explains the concept of a virtual path. Five VCCs in an ATM network is shown in Figure 1.3 where VCC s A, B and C enter through switch 1 and share the same path to switch 2 and are therefore aggregated together to form a virtual path connection (VPC) connecting switch 1 to switch 2.This VPC passes to through an ATM cross connection switch. Virtual Path Identifier (VPI) 3 is assigned to that VPC that contains VCCs A, B, C between switch 1 and cross connect switch. The cross connect switch switches all the cells with VP 3 to the link going to switch 2 and changes its VP to 5. At switch 2, the cells are unbundled, cells from VCC A goes to an output port and cells from VCCs B and C go to switch 3. VCC s D, E entering at switch 1 also has VP 2 between switch 1 and the cross connect switch and VP 1 between the cross connect switch and switch 4 [4,8].

ATM

Switch

2

ATM

DCC

ATM

Switch

1

VP 3 VP 5 A

A

ATM

Switch

3

B

C B

D C

E

VP 2

ATM

Switch

4

VP 1 D

E

Figure 5.3: ATM Virtual Paths [1]

5.2 ATM Traffic Management:

Traffic management is concerned with Quality of Service (QoS) guarantees to packet flows and incorporates methods to manage packet flow and control load in a network. It is also concerned with priority and scheduling mechanisms at switches and routers to differentiate between services provided to different traffic classes. Traffic Management also may involve policing and shaping of traffic flows into the network.

A path covered by a packet in a network can be seen as a sequence of multiplexers and transmission links (Figure 5.4). The dashed arrows indicate packets from other flows that contend for the same resources .The performance of a packet across a network is a summation of the performance experienced by the packet at all intermediate N nodes . Total end-to-end delay for a packet is the sum of the delays experienced at each multiplexer. Jitter is the variation of packet delay and is measured by the difference of maximum and minimum amount of delay experienced by a packet. Cell Loss occurs when a packet reaches a switch where there are no buffers free and may also happen due to burstiness of packet arrival pattern, reduced transmission rate out of a multiplexer and faults in equipments. To meet QoS objectives, ATM implements methods to manage the way in which cells are placed in queues and also to control transmission bit rates of the sources [4,8].

1 2 N-1 N

Figure 5.4: End-to-End QoS of a cell along a path of N hops [1]

5.3 Importance of ATM:

ATM was developed primarily to handle a steady flow of traffic as well as bursty traffic and also to support different types of applications like data, voice, video etc. This makes ATM suitable for an Integrated Services Network. The single transfer mode of ATM makes the network infrastructure management simple and also provides extensive bandwidth capabilities. ATM can operate over LANs and global backbone networks and is not limited by speed or distance. ATM differs from traditional TCP/IP networks in providing QoS guarantees to connections [1,4,8].

5.4 ATM Models:

The BISDN reference model consists of three planes: user plane, control plane and management plane. The user plane deals with the transfer of data, flow control and error recovery. The control plane is associated with the signaling required to set up, manage and release connections, while the management plane carries out management of network resources.

The user plane consists of three layers: ATM Adaptation Layer (AAL), ATM layer and the physical layer. AAL provides support to the different applications and converts higher layer Service Data Units (SDUs) into 48 byte blocks to be carried by ATM cells. The AAL on receiver side is responsible for reassembling and delivery of information in conformance with the requirements of a given application. Figure 1.5 shows the user plane layers of ATM .The AAL resides in terminal equipment and interacts on an end-to-end basis. The ATM layer deals with the transfer of cells across the network and adds 5 bytes of header to the 48-byte block received from AAL. The Physical layer is concerned with the details of the transmission of the bits over a specific medium and also converts ATM cells into a format appropriate for delivery across the medium [1,4,8].

AAL

ATM

PHY

AAL

ATM

PHY

User Information User Information

ATM

PHY

ATM

PHY

Figure 5.5: User Plane Layers [1]

5.5 ATM Connections:

ATM can provide different QoS to different connections and this requires that a service contract be negotiated between the user and the network at the time when the connection is set up. The user describes its traffic pattern and the required QoS at the time a connection is requested. If the network accepts its request, a contract is set up that ensures the QoS as long as the user abides by its traffic description. To ensure QoS guarantees, ATM uses policing mechanisms to monitor user compliance with the service contract and then discards cells that do not follow rules. ATM supports both point-to-point (unidirectional or bi-directional) and point-to-multipoint connections (unidirectional). Classified on the basis of duration, ATM connections can be permanent virtual connections (PVCs) and switched virtual connections (SVCs). PVCs are the permanent leased lines and are usually set up manually by the operator, SVC s are set up and released on demand by the users. The source user interacts with the network through a user-network- interface (UNI) .As shown in Figure 5.6 the connection request travels across the network and reaches destination UNI. Within the network, switches share information across the network-network interface (NNI). The source and destination end systems and all switches in the network are responsible for meeting the QoS guarantees [1,4,8].

Computer

Private UNI

Public UNI

Public

UNI

Computer

Figure 5.6: ATM Network Interfaces [1]

5.6 ATM QoS Parameters:

Primary objective of ATM is to provide QoS guarantees while transferring cells across the network. There are a total of six QoS parameters specified for ATM and they are indicators of the performance of the network [1,4,8].

5.6.1 Cell Error Ratio (CER): CER is the ratio of the number of cells that are delivered with one or more bit errors during a transmission to the total number of cells. CER depends on the underlying physical medium. CER calculation does not take into account blocks of cells that are severely defective.

5.6.2 Cell Misinsertion Rate (CMR): CMR is the average number of cells per second that is transferred mistakenly to a destination. CMR depends on the rate at which undetected header errors result in misdelivered cells and calculation of CMR also does not consider blocks of cells that are severely errored.

5.6.3 Severely-errored Cell Block Ratio (SECBR): A severely-errored cell block event occurs when more than M cells are lost, in error or are misdelivered in a received block of N cells. SECBR is the ratio of severely errored cellblocks to total number of transmitted cellblocks in a connection. It depends on the properties of the underlying physical medium and buffer overflows.

The three QoS parameters above are not negotiated during the connection set up process but the following three parameters are negotiated during that process.

5.6.4 Cell Loss Ratio (CLR): The CLR for a connection is defined as the ratio of the number of cells lost to the total number of transmitted cells. CLR value is negotiated between user and network during call set up process and is usually in the range of 10^-1 to 10^-15. The degree to which CLR can be negotiated depends on the sophistication of the buffer allocation strategies of the network.

5.6.5 Cell Transfer Delay (CTD): CTD is defined as the time that elapses between the instant the cell enters the network at the source UNI to the instant it comes out at the destination. This includes propagation delay, processing delay and queuing delays at switches. CTD is expressed as a probability density function as in figure 5.7. Maximum CTD is defined as D_max for which the fraction 1-a of cells have CTD less than D_max where a is small. Queue scheduling algorithms in ATM control the CTD experienced by cells.

Probability

Density