SCTP PERFORMANCE IMPROVEMENT BASED ON ADAPTIVE

RETRANSMISSION TIME-OUT ADJUSTMENT

THESIS

Presented to the Graduate Council

of Texas State University-San Marcos
in Partial Fulfillment
of the Requirements
for the Degree
Master of SCIENCE
by
Sagun Khatri, B.A.
San Marcos, Texas
August 2011

SCTP PERFORMANCE IMPROVEMENT BASED ON ADAPTIVE

RETRANSMISSION TIME-OUT ADJUSTMENT

Committee Members Approved:

Wuxu Peng, Chair

Stan McClellan

Hongchi Shi

Approved:

J. Michael Willoughby
Dean of the Graduate College

FAIR USE AND AHTHORS PERMISSION STATEMENT

Fair Use

This work is protected by the Copyright Laws of the United States (Public Law 94553, section 107). Consistent with fair use as defined in the Copyright Laws, brief
quotations from this material are allowed with proper acknowledgement. Use of this
material for financial gain without the authors express written permission is not
allowed.

Duplication Permission

As the copyright holder of this work I, Sagun Khatri, authorize duplication of this
work, in whole or in part, for educational or scholarly purposes only.

TABLE OF CONTENTS
LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

v
vi

CHAPTER
1. INTRODUCTION
1.1 Background . . . . .
1.2 Motivation . . . . . .
1.3 Objectives . . . . . .
1.4 Layout of the Thesis

.
.
.
.

1
1
2
2
5

.
.
.
.
.
.
.
.
.

6
6
7
9
10
11
13
14
15
16

.
.
.
.
.
.
.
.
.
.

18
18
19
19
23
27
27
28
28
29
30

4. CONCLUSIONS AND FUTURE WORK

BIBLIOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31
33

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

2. BACKGROUND
2.1 Commonalities between SCTP and TCP . . . . . .
2.2 Differences between SCTP and TCP . . . . . . . .
2.3 Retransmission . . . . . . . . . . . . . . . . . . . .
2.4 Jacobsons Algorithm . . . . . . . . . . . . . . . . .
2.5 Performance Deterioration of Jacobsons Algorithm
2.6 Karns Algorithm . . . . . . . . . . . . . . . . . . .
2.7 Fast Retransmission Timeout . . . . . . . . . . . .
2.8 Related Work . . . . . . . . . . . . . . . . . . . . .
2.9 Summary . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.

3. ADAPTIVE RTO MIN (ARM) ALGORITHM

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Research Logistics . . . . . . . . . . . . . . . . . . . . .
3.3 Adaptive RTO MIN (ARM) Algorithm . . . . . . . . .
3.4 Data Gathering for Multiple Payloads . . . . . . . . . .
3.4.1 Performance Evaluation for 50 bytes Payload . .
3.4.2 Performance Evaluation for 500 bytes Payload .
3.4.3 Performance Evaluation for 1000 bytes Payload
3.4.4 Performance Evaluation for 2000 bytes Payload
3.5 Algorithm Comparison Chart . . . . . . . . . . . . . .
3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . .

iv

.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

LIST OF TABLES
Table 3.1 Data in this table are the outcome of the Adaptive RTO algorithm implementation. . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3.2 Data Gathered using the static RTO MIN (SRM) and Adaptive
RTO MIN algorithm (ARM) executed on multiple payload, and
file sizes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 3.3 This chart shows us that when a chunks payload size is relatively small the Adaptive RTO algorithm preforms better than
the static RTO MIN. . . . . . . . . . . . . . . . . . . . . . . . . . .

22

26

29

LIST OF FIGURES
Figure 1.1 In this diagram the X-axis represents number of RTO updates
and the Y-axis represents time in milli seconds. . . . . . . . .
Figure 1.2 In this figure the X-axis represents number of RTO updates,
and the Y-axis represents time in milliseconds. . . . . . . . .
Figure 2.1 The Jacobsons algorithm . . . . . . . . . . . . . . . . . . .
Figure 2.2 In this figure we see how the Jacobsons algorithm currently
behaves in SCTP. . . . . . . . . . . . . . . . . . . . . . . .
Figure 2.3 This is a zoomed-in version of above Figure 2.2. . . . . . . . .
Figure 2.4 Karns Algorithm - the Retransmission Ambiguity Problem . .
Figure 3.1 The SCTP Echo Server running at the Texas State University
Texas State Computer Science Department. . . . . . . . . . .
Figure 3.2 The Adaptive RTO algorithm divides the possible RTT values
into five sectors. . . . . . . . . . . . . . . . . . . . . . . . .
Figure 3.3 Adaptive RTO algorithm. . . . . . . . . . . . . . . . . . . .
Figure 3.4 This graph is generate from the data in the Table 3.1. . . . . .
Figure 3.5 Without the Adaptive RTO MIN algorithm, the static RTO
MIN holds the RTO from falling below 1, 000 milliseconds. . .

vi

. . . .

. . . .
. . . .

4
10

. . . .
. . . .
. . . .

12
12
13

. . . .

20

. . . .
. . . .
. . . .

21
21
23

. . . .

24

CHAPTER 1
INTRODUCTION

1.1

Background

The Stream Control Transmission Protocol (SCTP) is a new IP transport protocol,

existing at an equivalent level with User Datagram Protocol (UDP) and Transmission Control Protocol (TCP), which provides transport layer functions to many Internet applications. SCTP has been approved by the IETF as a Proposed Standard
[Ong and Yoakum, 2002].
Like TCP, SCTP provides a reliable transport service, ensuring that data is
transported across the network without error and in sequence. Like TCP, SCTP
is session-oriented mechanism, meaning that a relationship is created between the
endpoints of an SCTP association prior to data being transmitted, and this relationship is maintained until all data transmission has been successfully completed
[Ong and Yoakum, 2002]. The word association is used in SCTP instead of connection to avoid the connotation that a connection involves communication between only two IP addresses. An association refers to a communication between
two systems, which may involve more than two IP addresses due to multihoming
[Stevens et al., 2004].
Unlike TCP, SCTP provides a number of functions that are critical for telephony
signaling transport, and at the same time can potentially benefit other applications
1

2
needing transport with additional performance and reliability [Ong and Yoakum, 2002].

1.2

Motivation

In recent years there have been a significant number of changes with regard to network
infrastructure. In the 1980s the Round Trip Time (RTT) for a packet to travel from
one side of the Continental US, for example, from New York City to the other side,
for example, Los Angeles California, used to take around 200 milliseconds. Currently
a packet traveling from New York City to Los Angeles could easily travel in less than
60 milliseconds. The decrease in time taken for a packet to travel a distance shows
us that there is a major improvement in the network infrastructure. With the help
of new technologies, such as fiber cables, and better satellite communication, faster
data transfer between two endpoints is going to be an ongoing trend.
Even though the network infrastructure has improved significantly over the years,
some of the network algorithms have not been fine tuned to take advantage of the
infrastructure improvement. Some of the network algorithms designed in the late
1980s are still being used Jacobsons algorithm is a good example at this trend.
Jacobsons algorithm calculates the Retransmission Time-Out (RTO) for each Round
Trip Time (RTT) [Stevens et al., 2004]. The algorithm was designed with the network
infrastructure of the late 1980s, where bandwidth was not as abundant.

1.3

Objectives

This work focuses on improving the file transfer time for the Stream Control Transmission Protocol (SCTP). SCTP borrows many features from TCP, but there are some

3
3000

2500

RTO

Waste

Time (milliseconds)

2000

1500

RTO MIN

1000

Waste

Waste

500

RTT
0

10

15

20

25

30

35

40

44

Number of RTO and RTT Updates

Figure 1.1: In this diagram the X-axis represents number of RTO updates and the Y-axis
represents time in milli seconds.

areas where the SCTP needs fine tuning in order to take advantage of its unique features, such as multi-homing. One particular area where the SCTP needs improvement
is the implementation of the Retransmission Time-Out Minimum (RTO MIN).
The Retransmission Time-Out Minimum (RTO MIN) constant in SCTP is set
very high (i.e., 1000 milliseconds) as seen in Figure 1.1 and Figure 1.2. Jacobsons
algorithm does not respond to any sporadic changes in the RTT value mainly due to
the RTO MIN, as seen in Figure 1.2. The result is waste of valuable system resources,
that could have been used for transmitting few more packets of data.
The subject matter of this thesis is not only to improve upon the time taken
to transfer a file form one node to the other, but also to make sure that the new
algorithm does not have any side effects, like bandwidth congestion. To accomplish

4
1100

RTO MIN
1000

RTO
900

800

Waste

Time (milliseconds)

700

600

500

400

300

200

100

RTT
1

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

Number of RTO and RTT Updates

Figure 1.2: In this figure the X-axis represents number of RTO updates, and the Y-axis
represents time in milliseconds.

this we proposed to fine tune the RTO MIN to make SCTP aware of a packet loss in
a significantly shorter amount of time. Thus, the retransmission will be expedited.
With static RTO MIN (SRM), Jacobsons algorithm is idle majority of the time,
as seen in Figure 1.2. In this thesis we propose a new algorithm called Adaptive RTO
MIN (ARM) algorithm, which dynamically lowers the lower bound of the RTO, thus
forcing Jacobsons algorithm to engage in the RTOs calculation.
The retransmission timer is a key feature of a reliable link or transport layer
protocol. It can greatly influence peer-to-peer performance. A too optimistic retransmission often expires prematurely. Such an event is called spurious timeout
[Ludwig and Sklower, 2000]. Thus, the ARM algorithm should avoid spurious timeouts. However, fine tuning the RTO MIN should not make the RTO too optimistic.

5
Otherwise, there is a risk of high bandwidth consumption because of spurious retransmissions. Detecting packet loss faster, should result in a faster file transfer as
compared to the existing algorithm.

1.4

Layout of the Thesis

Chapter 1: Introduction to SCTP. Describes the fundamental differences between

SCTP, TCP, and UDP.
Chapter 2: Provide a detailed background information on SCTP and research that
is related to this thesis.
Chapter 3: Detailed description on the Adaptive RTO MIN algorithm.
Chapter 4: Conclusion and Future Work.

CHAPTER 2
BACKGROUND

2.1

Commonalities between SCTP and TCP

SCTP shares many features of TCP. For example:

Both TCP and SCTP are developed to achieve the highest possible throughput
in various network scenarios. Thus, they will try to make use of all available
bandwidth in the network to transmit data as fast as possible to remote users.
This is known as thick stream. An example of thick stream would be a file transfer from one node to the other. When very few packets are sent without the need
to make use of the available bandwidth, and those packets are small compared
to the available payload. This is known as thin stream [Pedersen, 2006].
SCTP and TCP adjusts the sending rate to avoid overwhelming both the receiver and the network. Limiting the sending rate to avoid overwhelming a
receiver is called flow control. Limiting the sending rate to avoid overwhelming
the network is called congestion control [Matthews, 2005].
SCTP and TCP maintains another limit called the congestion window. The congestion window typically starts at the 1 Maximum Segment Size (MSS) and then
increases with each segment that is successfully acknowledged [Matthews, 2005].

7
In SCTP and TCP the congestion window grows multiplicatively with each acknowledgement. This phase of multiplicative growth is called slow start. However, this multiplicative growth does not continue forever, there is a adaptively
determined threshold [Matthews, 2005].
In SCTP data can be transmitted in one or more streams within a single association and subjected to common congestion and flow control. These mechanisms
are based on TCP. This means that SCTP is using slow start and congestion
avoidance in its procedures. During slow-start the initial congestion window is
set to 2 Maximum Transmission Unit (MTU). During congestion avoidance,
the congestion window is increased by 1 MTU per RTT.

2.2

Differences between SCTP and TCP

SCTP differs from TCP in fundamental ways, which is why there is a need to optimize
algorithms to better suit SCTP, rather than just copy and paste the code from TCP.
Following are some key differences between the two protocols:
Unlike TCP, SCTP is message-oriented. It provides sequence delivery of individual records. Like User Datagram Protocol (UDP), the length of a record written
by the sender is passed to the receiving application [Stevens et al., 2004].
SCTP can provide multiple streams between connection endpoints, each with
its own reliable sequenced delivery of messages. A lost message in one of these
streams does not block delivery of messages in any other streams. This approach
is in contrast to TCP, where a loss at any point in the single stream of bytes

8
blocks delivery of all future data on the connection until the loss is repaired
[Stevens et al., 2004].
SCTP also provides a multihoming feature, which allows a single SCTP endpoint to support multiple IP addresses. This feature can provide increased
robustness against network failure. An endpoint can have multiple redundant
network connections, where each of these networks has a different connection
to the Internet. SCTP can work around a failure of one network or path across
the Internet by switching to another address already associated with the SCTP
association. The word association is used in SCTP instead of connection to
avoid the connotation that a connection involves communication between only
two IP addresses [Stevens et al., 2004].
In SCTP a message from the application layer is transmitted in a data chunk
which has its own unique Transmission Sequence Number (TSN). Several chunks
for different types may get bundled into one packet as long as the total size of a
packet does not exceed the MTU of the network path. If a message does not fit
into a single packet according to the MTU, it is fragmented into multiple data
chunks where each fits into a packet [Stewart et al., 2000].
SCTP uses SACK to acknowledge the receipt of data chunks. In the absence of
loss, a SACK is sent back for every second packet received or within 200 milli
seconds of the arrival of any unacknowledged data chunks.

9
2.3

Retransmission

When a SCTP sender transmits a chunk, it also sets a timer called a retransmission
timer. When an acknowledgment arrives, the timer is cancelled. If the timer expires
before an acknowledgment arrives, the chunk will be retransmitted.
SCTP does not always wait for a retransmission timer to expire before retransmitting data. SCTP will also interpret a series of duplicate acknowledgments as an
early sign of packet losses [Matthews, 2005]. Fast retransmission occurs when four
Selective Acknowledgements (SACKs) is received, and this is discussed in details in
later sections.
The RTT between a client and a server can change rapidly with time as network conditions change. For optimal performance a timeout and retransmission
algorithm should be used that takes into account the actual RTTs characteristics
along with changes in the RTT over time. Much work has been focused on this
area, mostly relating to TCP, but the same ideas apply to any network application
[Allman and Paxson, 1999, Coene and Pastor-Balbas, 2006].
The retransmission time-out (RTO) value is the time that elapses after a packet
was sent until the sender considers it lost and retransmits it, this event is called a
timeout. The RTO is a prediction of the upper limit of the round trip time (RTT), i.e.,
the time that elapses after a packet left the sender until the sender receives a positive
acknowledgment (ACK) for that packet. The time that remains until the timeout for
a packet occurs is maintained by the retransmission timer state (REXMT). Thus, the
RTO is the REXMTs initial value [Ludwig and Sklower, 2000].

10

delta
srtt
rttvar
RT O

measuredRT T srtt
srtt + g delta
rttvar + h(|delta| rttvar)
srtt + 4 rttvar

Figure 2.1: The Jacobsons algorithm

The retransmission timer is the key feature of a reliable link or transport layer
protocol. It can greatly influence peer-to-peer performance. A too optimistic retransmission timer often expires prematurely. Such an event is called spurious timeout. It
causes unnecessary traffic, so called spurious retransmissions, that reduce a connections effective throughput. On the other hand, a retransmission timer that is too
conservative may cause long idle time before the lost packet is retransmitted. This
can also degrade performance [Ludwig and Sklower, 2000].

2.4

Jacobsons Algorithm

We want to calculate the RTO to use for every packet that we send. To calculate this,
we measure the RTT: the actual round-trip time for a packet. Every time we measure
an RTT, we update two statistical estimators: srtt is the smoothed RTT estimator and
rttvar is the smoothed mean deviation estimator. The latter is a good approximation
of the standard deviation, but easier to compute since it does not involve a square
root. Given these two estimators, the RTO is assigned as srtt plus four times rttvar
[Jacobson and Karels, 1988] provides all the details to these calculations, which we
can summarize in Figure 2.1:
In Figure 2.1 delta is the difference between the measured RTT and the current

11
smoothed RTT estimator (srtt), g is the gain applied to the RTT estimator and equals
1
,
8

and h is the gain applied to the mean deviation estimator and equals 41 .
Another point made in [Jacobson and Karels, 1988] is that when the retransmis-

sion timer expires, an exponential backoff must be used for the next RTO. For example, if our first RTO is 2 seconds and the reply is not received in this time, then the
next RTO is 4 seconds. If there is still no reply, the next RTO is 8 seconds, and then
16, and so on [Stevens et al., 2004].

2.5

Performance Deterioration of Jacobsons Algorithm

A retransmission timer that is too conservative may cause long idle time before the lost
packet is retransmitted. This can degrade performance [Ludwig and Sklower, 2000].
In SCTP, RTO MIN is a constant that keeps the RTO from falling below 1, 000
milliseconds. During the research, there was a strong reverberation through the static
RTO MIN causing Jacobsons algorithm performance deterioration.
RTO MINs very liberal value of 1, 000 milliseconds keeps the Jacobsons algorithm
from playing a proactive role in RTO calculation, as seen in Figure 2.2 and Figure 2.3.
In many circumstances (due to modern broadband networks) the RTT is well below
1, 000 milliseconds. Thus, most of the time Jacobsons algorithm is never used for
the RTO calculation, which causes long idle time before realizing a packet has been
lost. In other words, SCTP has to wait for almost a whole second, before realizing a
packet has been lost. This approximately 1, 000 millisecond loss in the long run will
turns out to be very costly in terms of transmission time.

12

4500

4000

3500

Time (milliseconds)

3000

2500

2000

1500

RTO

1000

500

RTT

0
180

250

300

350

400

450

500

550

Number of RTO and RTT Updates

Figure 2.2: In this figure we see how the Jacobsons algorithm currently behaves in SCTP.

4500

4000

3500

Time (milliseconds)

3000

2500

2000

1500

RTO

1000

500

RTT
40

50

60

70

80

90

100

110

120

Number of RTO and RTT Updates

Figure 2.3: This is a zoomed-in version of above Figure 2.2.

130

140

13
client

RTO

server
request

client

server
request

client

server
request

lost
request

reply
lost

reply
request

request
reply

reply
reply

(a) lost request

(b) lost reply

(c) RTO too short

Figure 2.4: Karns Algorithm - the Retransmission Ambiguity Problem

2.6

Karns Algorithm

Another point made in [Jacobson and Karels, 1988] is that when the retransmission
timer expires, an exponential backoff must be used for the next RTO. For example,
if our first RTO is 2 seconds and the reply is not received in this time, then the next
RTO is 4 seconds. If there is still no reply, the next RTO is 8 seconds, and then 16,
and so on.
Jacobsons algorithm is used to calculate the RTO each time an RTT is measured,
and how to increase the RTO for retransmission. However, a problem arises for
ACK of retransmitted packets. This is called the retransmission ambiguity problem.
Figure 2.4 shows the following three possible scenarios when the retransmission timer
expires.
(a) The request is lost.
(b) The reply is lost.

14
(c) The RTO is too small.

When the client receives a reply to a request that was retransmitted, it cannot
tell to which request the reply corresponds. In the example (refer to Figure 2.4) the
reply corresponds to the original request, while in the two other examples, the reply
corresponds to the retransmitted request.
Karns algorithm [Karn and Partridge, 1991] handles this scenario with the following rules that apply whenever a reply is received for a request that was retransmitted.

If an RTT was measured, do not use it to update the estimators since it is not
known to which request the reply corresponds.
Since this reply arrived before the retransmission time expired, reuse this RTO
for the next packet. Only when a reply is received to a request that was not
retransmitted will RTT estimators be updated and RTO recalculated.

2.7

Fast Retransmission Timeout

In SCTP, fast retransmission is triggered by four SACKs. Whenever the sender

receives a SACK that reports missing data chunks, it will wait for three further SACKs
reporting the same data chunks as missing before doing the fast retransmission. By
waiting for four consecutive SACKs, SCTP tries to eliminate spurious retransmissions
caused by packets that are received out of order [Pedersen, 2006].

15
2.8

Related Work

A lot of research has been done to improve late retransmission. This section focuses
on what others have done in order to improve the late retransmission.
Early Fast Retransmit (EFR) is an optional mechanism in FreeBSD, which is
active whenever the congestion window is larger than the number of unacknowledged
packets and there are packets to be sent. It starts a timer that closely follows the
RTT and RTTVAR for every packet sent, and when the timer goes off and the stream
is still not using the entire congestion window, it retransmits all packets that could
have been acknowledged [Pedersen et al., 2006].
Much research has been done in the quest to improve Jacobsons algorithm, but so
far there has not been a definite answer. Ekstrom and Ludwig [Ekstrom and Ludwig, 2004]
indicate that the RTO algorithm defined in RFC2988 [Paxson and Allman, 2000],
used in both TCP and SCTP, responds inappropriately to certain fluctuation in RTT.
This causes the characteristics spike in RTO when there is a sudden movement in
RTT, as seen in Figure 2.2. The reason behind the spike is that the RTTVAR computation does not distinguish between positive and negative variations. Their proposed
algorithm alleviates the sudden fluctuation for a wide range of cases, and the findings
in [Pedersen et al., 2006] concurs with their algorithm. However, their solution on
average is higher than that proposed in RFC2988 [Paxson and Allman, 2000], which
is not a optimal solution [Petlund et al., 2009].
The Early Retransmit (ER) algorithm [Allman et al., 2010] suggests that a
mechanism should be in place to recover lost segments when there are few unac-

16
knowledged packets to trigger Fast Retransmit. The Early Retransmit algorithm
reduces waiting time in four situations [Petlund et al., 2009]:

The congestion window is still initially small.

It is small because of heavy loss.
Flow control limits the send window size.
The application has no data to send.

The RTO MIN is an important factor in calculating the RTO itself. Some applications may want to lower the RTO MIN to less than 1, 000 milliseconds, which will
allow the sender to reach the maximum number of retransmission threshold faster in
the case of network failures. However, Allman and Paxson [Allman and Paxson, 1999]
warn that lowering the RTO MIN may have negative impact on network behavior.
Where as, some applications might want to eliminate using the binary exponential back-off concept in the RTO calculation in order to speed up failure detection.
The RFC4166 suggests not to eliminate the binary exponential back-off altogether,
because when network congestion does occur, not backing off the timer may worsen
the congestion situation [Coene and Pastor-Balbas, 2006].

2.9

Summary

Even though there has been a tremendous amount of research in this area, there is
still a great deal of fine tuning to be done in terms of enhancing the retransmission
timeout algorithms. In the next chapter we are going to give a detailed description

17
of the algorithm we call Adaptive RTO MIN (ARM) algorithm, which exploits the
variations in RTT and dynamic range of RTO. This algorithm improves performance
of SCTP by implementing a dynamically variable minimum value for RTO. Previously,
the minimum value of RTO (RTO MIN) has been statically defined.

CHAPTER 3
ADAPTIVE RTO MIN (ARM) ALGORITHM

3.1

Introduction

The idea behind the Adaptive RTO algorithm comes from observing the Jacobsons
algorithm secluded role in calculating the RTO with the lower bound set by the static
RTO MIN (SRM). With the SRM, Jacobsons algorithm is idle the majority of the
time. The Adaptive RTO MIN (ARM) algorithm dynamically lowers the lower bound
of the RTO, thus forcing Jacobsons algorithm to engage in the RTOs calculation.
RFC-2960 defines RTO MIN as a constant, with a value of one second, which
is 1, 000 milliseconds [Stewart et al., 2000]. The primary purpose of the RTO MIN
is to act as a lower bound for the RTO, i.e. RTOs value can not fall below that
threshold. The RTO MIN constant makes the RTO very unresponsive to RTTs
sporadic behavior. For example even if the RTT is at 700 milliseconds the RTO will
not make any adjustments accordingly, as seen in Figure 2.2.
The only way Jacobsons Algorithm can play a proactive role in the RTO calculation is if the RTT value is in the vicinity of 800 to 900 milliseconds. In our research,
we found that waiting 1000 milliseconds for the retransmission timer to expire is a
waste of time, since as mentioned before the RTT for the Continental US is about 60
milliseconds. If there are some spurious RTTs once in a while, then why not catch
it early and retransmit it for faster file transfer?
18

19
Modern bandwidth is big enough for us to afford to do such retransmissions, and
as the results from the data collection shows that doing so will not be retransmitting
any more than the current algorithm. In some occasions the Adaptive RTO algorithm
can save retransmission from happening and wasting resources.

3.2

Research Logistics

For this research we setup three computers, as seen in Figure 3.1. Two computers
running an SCTP echo client program residing in an external network, and the third
computer running an SCTP echo server program, which resides in the Texas State
UniversitySan Marcos Computer Science Department. All three of them were running Linux CentOS 5.4, kernel version 2.6.18, with the default SCTP module provided
by the kernel.
The physical distance between the computers was less than 50 miles. The RTT
between the two client computers and the server was typically around 30 milliseconds.
To measure the time taken, the Adaptive RTO MIN (ARM) algorithm and the
static RTO MIN (SRM), we transmitted the same file from two client computers,
where one is running the ARM algorithm and the other SRM. In addition, the client
computers were transmitting the file in 10 streams, with the data being mirrored in
all 10 streams, as diagramed in Figure 3.1.

3.3

Adaptive RTO MIN (ARM) Algorithm

The ARM algorithm calculates RTO MIN based on the current value of RTT. Dynamically lowering the RTO MIN forces Jacobsons algorithm to play a proactive role

20

External
Network

University
Network

10 Streams

SCTP Echo
Server

SCTP Echo
Client 1

10 Streams

Router

Router

Internet
SCTP Echo
Client 2
RTT 28 to 32 ms

Figure 3.1: The SCTP Echo Server running at the Texas State UniversityTexas State
Computer Science Department.
in calculating RTO.
The RTO Adaptive Algorithm calculates the RTO MIN value based on the current
RTT with the principle of exponential decay. This is diagramed in Figure 3.2 and
Figure 3.3.
There are two reasons for choosing the multiplicative values in the Adaptive RTO
MIN algorithm:

Multiplication of 2, 1.75, 1.50, 1.25, 1.125, is easier and efficient to calculate

using a right bit shift and an addition operation, rather than a floating point
calculations.
When the RTT is in the lower range, from 1 to 50 milliseconds, it is safe to
double the RTO MIN value, because the RTO MIN will at most have an upper
bound of 100 milliseconds. Whereas, doubling the RTT MIN value while the

21

2.25

2
1.8
1.6

RTO MIN Ration

1.4
1.2
1
0.8
0.6
0.4
0.2
0

50

100

150

200

250

300

350

400

450

500

550

600

650

700

750

800

RTT Value

Figure 3.2: The Adaptive RTO algorithm divides the possible RTT values into five sectors.

1
2
3
4
5
6
7
8
9
10

i f ( r t t <= 5 0 )
rto min
e l s e i f ( r t t <=
rto min
e l s e i f ( r t t <=
rto min
e l s e i f ( r t t <=
rto min
else
rto min

= rtt
100)
= rtt
200)
= rtt
400)
= rtt

2
1.75
1.5
1.25

= r t t 1.125

Figure 3.3: Adaptive RTO algorithm.

22
Table 3.1: Data in this table are the outcome of the Adaptive RTO algorithm implementation.

RTO MIN and RTO After the Adaptive RTO Algorithm

Round Trip Time Retransmission Time-Out Retransmission Time-Out Minimum
29
85
58
33
78
66
28
66
56
32
64
64
62
108
108
106
159
159
184
286
276
215
401
268
40
356
80
40
320
80
36
291
72
44
252
88
60
211
105
60
175
105
70
152
122
81
150
141
85
148
148
89
155
155
90
157
157
93
162
162

RTT is in the range of 201 to 400 milliseconds, is not wise because the RTO
MINs upper bound will be almost the same as static RTO MIN. Thus, using
an exponential decay principle in the Adaptive RTO MIN algorithm made the
most sense.
Figure 3.4 shows the resulting performance of the ARM algorithm. Note that
because of the ARM algorithm the RTO, which is calculated by Jacobsons algorithm,
is not over estimating as was the case with the static RTO MIN of 1, 000 milliseconds.
By lowering the RTO MIN value and allowing it to update dynamically based

23
450

400

350

Time (milliseconds)

300

250

RTO
200

150

RTO MIN
100

RTT
50

10

12

14

16

18

20

22

Number of RTO, RTT, and RTO MIN Updates

Figure 3.4: This graph is generate from the data in the Table 3.1.
on current RTT values, Jacobsons algorithm becomes more proactive in the RTO
calculation, but with enough room for the RTT to fluctuate and not over-congest the
network bandwidth.
As shown in Figure 3.4, the ARM algorithm gives enough room for the RTO to
make correct decision, but at the same time it does not let the RTO MIN fall too far
below. In a sense the RTO MIN is acting like a net for the RTO. Before, the RTO
constantly hovered at 1, 000 milliseconds even if the RTT was around 30 milliseconds.

3.4

Data Gathering for Multiple Payloads

To verify the performance of Adaptive RTO algorithm a wealth of data were gathered, using the network configuration of Figure 3.1, using multiple payload sizes, and
multiple file sizes. The payload size ranged from 50 bytes 2000 bytes, and the file

24
1100

RTO

1000

RTO MIN
900

800

Time (milliseconds)

700

600

500

400

300

200

RTT

100

10

12

14

16

18

20

22

Number of RTO, RTT, and RTO MIN Updates

Figure 3.5: Without the Adaptive RTO MIN algorithm, the static RTO MIN holds the
RTO from falling below 1, 000 milliseconds.

sizes ranged from 32 kilobytes 2048 kilobytes (2 megabytes). The interpretation

of this data shows that the ARM algorithm preforms better with smaller payloads.
As seen in Table 3.2, the data shows that the Adaptive RTO algorithm behaves
approximately the same when the congestion level in the network is the comparatively
same, i.e. there is no excessive misfiring of retransmission. The conventional thought
is that lowering the RTO MIN might have undesirable side effect, like network congestion [Allman and Paxson, 1999, Coene and Pastor-Balbas, 2006]. The Adaptive
RTO algorithm and static RTO MIN behaves approximately the same while operating in the non-congested mode. However, the Adaptive RTO algorithm still out
performs the static RTO MIN in terms of Total Transmission time, RTX due to Fast
RTX, albeit in small fractions.

25
The advantage comes when using small packets as in thin stream, or control
streams. During the data collection phase the Adaptive RTO algorithm transfer rate
improved by 5%, while still retaining the same retransmission rate as the static RTO
MIN (SRM). Table 3.2 shows the findings using multiple payload, and file sizes.
In Table 3.2, each sub-tables represents different payload and file sizes. Furthermore, the sub-tables have been divided into two different columns that represents
data collected with and without congestion. Each rows of the sub-tables are defined
below:

Number of Fast RTX, represents the total number of chunks retransmitted due
to fast retransmission.
Number of RTX Time-Out, represents the total number chunks retransmitted
due to time out.
Number of RTX PMTU, represents the total number of chunks retransmitted
due to the chunks size being greater than the maximum transmission unit.
Transmission Time in seconds, represents the total time taken to transmit a
file.

In order to collect the data a text file was transferred from the two client computers
to the echo server, as seen in Figure 3.1. The file size is represented by each sub-tables
in Table 3.2. The network congestion was emulated by uploading a very large file in
the background from one of the client computer.

26

Table 3.2: Data Gathered using the static RTO MIN (SRM) and Adaptive RTO MIN
algorithm (ARM) executed on multiple payload, and file sizes.

Transferring 32 Kb file with 50 bytes payload

Without Congestion With Congestion
SRM
ARM
SRM
ARM
Number of Fast RTX
164
177
1862
2005
Number of RTX Time-Out
5
0
55
342
Number of RTX PMTU
0
0
0
0
Transmission Time (seconds) 1673
1667
5716
5498
Transferring 512 Kb File with 500 bytes payload
Without Congestion With Congestion
SRM
ARM
SRM
ARM
Number of Fast RTX
656
159
3009
2350
Number of RTX Time-Out
34
7
88
383
Number of RTX PMTU
0
0
0
0
Transmission Time (seconds) 2756
2724
9013
8581
Transferring 1024 Kb file with 1000 bytes payload
Without Congestion With Congestion
SRM
ARM
SRM
ARM
Number of Fast RTX
311
181
2223
2118
Number of RTX Time-Out
6
9
97
343
Number of RTX PMTU
0
0
0
0
Transmission Time (seconds) 2728
2721
9542
9334
Transferring 2048 Kb file with 2000 bytes payload
Without Congestion With Congestion
SRM
ARM
SRM
ARM
Number of Fast RTX
362
290
2735
2572
Number of RTX Time-Out
14
9
64
393
Number of RTX PMTU
0
0
0
0
Transmission Time (seconds) 2742
2723
9224
9237

27
The data in the Table 3.2 show the performance improvement achieved by implementing the ARM algorithm over the standard SRM, which will be discussed in
detail in the following sections.

3.4.1

Performance Evaluation for 50 bytes Payload

The data from the Table 3.2 suggest that the ARM algorithm preforms better with
small the payload size.
When the payload size is 50 bytes, and there is no network congestion the ARM
algorithm transfers a file in approximately the same time the SRM does. The retransmission rate due to both fast retransmission and time-out is approximately the
same.
Whereas, the ARM algorithm out performs the SRM when there is a network
congestion, by transferring a file 4% faster. As expected, the number of chunks retransmitted due to time-out increases for the ARM algorithm. But, the number of
chunks retransmitted due to time-out is very minuscule in comparison to the total
number of chunks actually transmitted. In comparison to the SRM, the ARM algorithm retransmitted 0.3% more chunks in total, which as stated earlier is well within
network bandwidths capacity.

3.4.2

Performance Evaluation for 500 bytes Payload

When the payload size is 500 bytes, and there is no network congestion the ARM
algorithm transfers a file in approximately the same time the SRM does. The retransmission rate due to both fast retransmission and time-out is approximately the

28
same as well.
The ARM algorithm preform better than the SRM when there is network congestion. The ARM algorithm transferred a file 5% faster as compared to SRM. The
total number of retransmission caused by the ARM algorithm was in fact 0.1% less
than the SRM.
With the 500 bytes payload, the ARM algorithm seems to be more efficient than
with 50 bytes payload, because it transferred a file in 5% less time, with 0.1% less
retransmission.

3.4.3

Performance Evaluation for 1000 bytes Payload

With the payload size of 1, 000 bytes, and with no network congestion the ARM
algorithm transmits a file in approximately the same time as the SRM, and the
retransmission rate is the same for both.
The ARM algorithm preforms better than the SRM when there is network congestion. The ARM algorithm transferred a file 2.23% faster as compared to the SRM.
The total number retransmission caused by the ARM algorithm was approximately
the same as the SRM.

3.4.4

Performance Evaluation for 2000 bytes Payload

As the payload size increases the ARM algorithm and SRM preforms the same regardless of with or without network congestion. The total number of chunks retransmitted
is approximately the same, and the time taken to transmit a file is same as well.

29
Table 3.3: This chart shows us that when a chunks payload size is relatively small the
Adaptive RTO algorithm preforms better than the static RTO MIN.

Comparison Chart
Payload Size (bytes) Without Congestion
2, 000

1, 000

500

50

3.5

With Congestion

+2.2%
+5.03%
+4%

Algorithm Comparison Chart

Table 3.2 presents us with the data for different file and payload sizes, with ARM algorithm and without. Detailed interpretation of the data was provided in the previous
sections.
Table 3.3 is a comparison chart which neatly conveys the messages, provided in
the previous sections. The chart represents how the ARM algorithm compares to the
SRM, in respect to file transfer time. The convention used in the chart is as follows:
+ represents a time gain caused by the ARM algorithm, and the represents the
ARM algorithms performance is approximately the same as the SRM.
With the help of Table 3.3 it is easy to visualize the conditions that favors ARM
algorithm. The data suggest that the ARM algorithm is always better than the SRM
when the payload is relatively small, thin stream, and the ARM algorithm performs
approximately the same as SRM, when the payload size increases in the vicinity of
2, 000 bytes.

30
3.6

Summary

The data gathering and analysis in this chapter have proven the Adaptive RTO MIN
(ARM) algorithm as a viable replacement to the current static RTO MIN implementation. The ARM algorithm can transmit a file from one endpoint to the other in
5% less time than the static RTO MIN, without unnecessary retransmission, and in
some case the ARM algorithm has even mitigated the amount of retransmission as
compared to the static RTO MIN.

CHAPTER 4
CONCLUSIONS AND FUTURE WORK

In this thesis we have shown what others have done in regard to enhancing SCTPs
retransmission time-out performance, and how their approaches are different from
ours. We have also shown how the Adaptive RTO algorithm helps improve the SCTPs
performance in contrast to the existing implementation.
Significant amount of data were gathered in order to show that we have improved
the file transfer rate in SCTP by about 5%, in the scenario where the Adaptive RTO
algorithm is implemented. We have been vigilant in making sure the Adaptive RTO
algorithm does not unnecessarily clog networks bandwidth, and that the current implementation of RTO MIN can be safely replaced with the Adaptive RTO algorithm.
Furthermore, we have done extensive testing of the Adaptive RTO algorithm in respect to multiple scenarios. For example, the data were gathered when the network
was operating on a non-congested environment, as well as when the network was operating under heavy congestion environment. We have also shown that the Adaptive
RTO algorithm does not clog networks bandwidth under any conditions.
This is an evolutionary research. This thesis does not solve all the problems but
sets up additional studies and hypothesis. If the time had permitted I would have
done the following, in my opinion, the next cycle in this evolution:
Come up with a design and implement a congestion detection via Adaptive
31

32
RTO algorithm, and make use of the SCTPs unique feature, multihoming, to
switch between IP address. Currently this feature is not fully implemented in
the SCTP, the application layer needs to handle the logic to select IP addresses.
The Adaptive RTO algorithm will help detect the networks congestion and help
make better decision to switch between multiple IP addresses.
Come up with a design and implement better path selection algorithm via Adaptive RTO algorithm. The Adaptive RTO algorithm would detect a better path
for transferring data from one node to the other.

BIBLIOGRAPHY
[Allman et al., 2010] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and
Hurtig, P. (2010). Early retransmit for tcp and stream control transmission protocol
(sctp).
[Allman and Paxson, 1999] Allman, M. and Paxson, V. (1999). On estimating endto-end network path properties. SIGCOMM.
[Coene and Pastor-Balbas, 2006] Coene, L. and Pastor-Balbas, J. (2006). Telephony
signaling transport over stream control transmission protocol (sctp) applicability
statement.
[Ekstrom and Ludwig, 2004] Ekstrom, H. and Ludwig, R. (2004). The peak-hopper:
A new end-to-end retransmission timer for reliable unicast transport. INFOCOM.
[Jacobson and Karels, 1988] Jacobson, V. and Karels, M. J. (1988).

Congestion

avoidance and control. ACM Computer Communications Review.

[Karn and Partridge, 1991] Karn, P. and Partridge, C. (1991). Improving round-trip
time estimates in reliable transport protocols. ACM Transactions on Computer
Systems, 9(4):364373.
[Ludwig and Sklower, 2000] Ludwig, R. and Sklower, K. (2000). The eifel retransmission timer. ACM Computer Communications Review.

33

34
[Matthews, 2005] Matthews, J. (2005). Computer Networking Internet Protocols In
Action. Wiley, Hoboken, NJ, 1st edition.
[Ong and Yoakum, 2002] Ong, L. and Yoakum, J. (2002). An introduction to the
stream control transmission protocol (sctp).
[Paxson and Allman, 2000] Paxson, V. and Allman, M. (2000). Computer tcps retransmission timer, rfc 2988 (proposed standard).
[Pedersen, 2006] Pedersen, J. (2006). Evaluation of sctp retransmission delays. Masters thesis, University of Oslo Department of Informatics.
[Pedersen et al., 2006] Pedersen, J., Griwodz, C., and Halvorsen, P. (2006). Considerations of sctp retransmission delays for thin streams. LCN.
[Petlund et al., 2009] Petlund, A., Beskow, P., Pedersen, J., Paaby, E. S., Griwodz,
C., and Halvorsen, P. (2009). Improving sctp retransmission delays for timedependent thin streams. Multimedia Tools and Applications, 45:3360.
[Stevens et al., 2004] Stevens, W. R., Fenner, B., and Rudoff, A. M. (2004). UNIX
Network Programming The Socket Networking API Volume 1. Addison-Wesley,
Boston, MA, 3rd edition.
[Stewart et al., 2000] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and Paxson, V. (2000). Stream
control transmission protocol.

VITA
Sagun Khatri was born in Kathmandu, Nepal, on December 27, 1981, the son of
Sridhar and Sarita Khatri. After completing his work at Galaxy Public High School
in Kathmandu, Nepal, he entered Luther CollegeDecorah, Iowa. In the Fall of 2006,
he received the degree of Bachelor of Arts from Luther CollegeDecorah, Iowa. In
Fall 2008, he entered the Graduate College of Texas State University-San Marcos.

Permanent Address: 12800 Harrisglenn Drive Apt# 1534

Austin, Texas 78753

This thesis was typed by Sagun Khatri.