J. King Saud University, Vol. 22, Comp. & Info. Sci., pp. 45-61,Riyadh (1431H.

/2010)

An Extended Review of Techniques for Enhancing TCP Performance

Mohammed A. Alnuem
Dept. of Information System, College of Computer and Information Sciences,
King Saud University
P.O. Box 51178 Riyadh 11543, Saudi Arabia
Email: malnuem@ksu.edu.sa

(Received 01/07/2009; accepted for publication 30/12/2009)

Keywords: TCP, Lossy networks, Error discriminators.

Abstract. Transmission Control Protocol (TCP) is considered one of the most important protocols
in the Internet. An important mechanism in TCP is the congestion control mechanism which
controls TCP sending rate and makes TCP react to congestion signals. Nowadays in heteroge-
neous networks, TCP may work in networks with some links that have lossy nature (wireless
networks for example). TCP treats all packet loss as if they were due to congestion. Consequently,
when used in networks that have lossy links, TCP reduces sending rate aggressively when there are
transmission (non-congestion) errors in an uncongested network. In this paper we present
different solutions to overcome the performance degradation problem TCP faces when working
over lossy links. Many solutions have been proposed but we will concentrate on end-to-end so-
lutions that require no help from the intermediate network.

1. Introduction link so TCP will be unaware of them and hence

it will not reduce its transmission rate as a
Many solutions have been proposed to overcome reaction to those errors. In general, link layer
the problem of TCP bad per- formance over lossy solu- tions are used for wired-wireless networks
links (like wireless networks). Some solutions and they can be located at the base station
were in the transport layer and some solutions which connects the wired network with the
were in lower layers like the link layer. wireless link just before the receiver. They
Balakrishnan in [1] divided the solutions into monitor the packets that pass the base station
two general categories: 1- So- lutions that make from one end to another and keep record (and
TCP unaware of the errors that happen in the sometimes copies) of the packets sent and set a
link so TCP thinks that it works on reliable links retransmission timeout for each packet. When
with no transmission errors, for example Snoop the wireless link drops a packet either a timeout
agents[2]. 2- Approaches to try to make TCP will occur or duplicate acknowledgments will be
aware of the errors caused by the lossy link and received at the base station. The base station then
make TCP avoid using congestion mechanisms resends the lost packet and suppresses the duplicate
for this type of errors. However other authors like acknowledgment at the base station so TCP does
[3] divide these solutions into the fol- lowing more not notice the drop and hence will not need to
specific categories: Link Layer, Split Connection reduce its transmission rate.
and End-To-End solutions. A good feature of this approach is that it
In the link layer solutions the aim is to preserves the end-to-end semantics of TCP since
completely hide the errors that oc- cur in the it does not break the connection (i.e. the
46 Mohammed A. Alnuem: An Extended Review of Techniques…

connection negotiation and maintenance remains (sender and receiver) and do not expect help from
between the sender and the receiver only). the network so they look at the network as a black
However, the problem is that sometimes this box. The main advantage of this approach is
method cannot completely hide errors from the that it does not add overhead to the network.
TCP sender. For example when a mechanism like However, some proposed solutions from this
Snoop resends a dropped packet but the packet category use some sort of indirect feedback from
is dropped again due to high error rates and the network as we will see later.
then the TCP timeout for this packet occurs Mainly the following techniques try to find
before Snoop has a chance to resend it again. ways to recover from drops (con- gestion and
This could happen because of the mismatch transmission) efficiently. Some of these solutions
between the TCP and Snoop retransmission were designed for a wireless environment and
timeout mechanisms (RTO). In principle the some were introduced before introduction of
Snoop RTO should be shorter than the TCP wireless technology. However, since the aim of all
RTO but this is not always true [3, 1]. these solutions is to recover from errors efficiently,
Moreover, sometimes Snoop’s aggressive they can be used for improving TCP performance
retransmission may cause congestion at the base over networks with both congestion and non-
station which may reduce the link utilization. congestion (transmission) errors.
Examples of Link layer solutions are TULIP[4],
Snoop[2] and AIRMAIL[5]. 3. Congestion Drops
In Split Connections protocols the aim is to
divide the problem into two smaller ones. This In the following we will begin with techniques
is done by separating the wired link connection designed to recover from conges-tion drops. Later
from the wireless link connection. This is we will present techniques designed for congestion
usually done at the base station where two and trans- mission drops.
connections are maintained. One standard TCP
connection from the wired host to the base station 3.1 Retransmission Timeout (RTO)
and another wireless connection from the base
station to the mobile host where a new protocol In Retransmission Timeout TCP attaches a
that can handle wireless errors is implemented. timer with each sent packet, and when the timer
The base station plays the role of the interface expires before receiving acknowledgment for that
between the two connections [3][6]. The TCP packet, TCP resends the lost packet and sets the
connection from the sender ends at the base congestion window to the minimum allowed size.
station and then the base station starts a new For more about how RTO is calculated using the
connection with the receiver. RTT see [8, 9].
A good feature of this method is that we do RTO is one of the first methods provided to
not need to do any changes at the sender TCP to recover from errors. However, it is most
because the sender does not need to deal with efficient when the congestion is serious and the
the errors on the wireless link. However, the network needs more time to drain the congested
sender is not now negotiating the connection with nodes. On the other hand, if the drops are caused
the end receiver so the connection between the by transient congestion then it is better to resend
sender and the receiver is broken and the end-to- the lost packet without waiting for a timeout to
end semantics of TCP no longer hold. An example occur. This idea is the base of the fast-
of this category is I-TCP [6] and M-TCP [7]. retransmission mechanism which we will talk
The last category is the end-to-end solutions. about in the next section.
Next we will talk about them in more detail.

2. End-to-End Solutions 3.2 Fast retransmission (TCP-Reno)

In earlier implementations of congestion
In general, most of the end-to-end solutions, control mechanisms, there was an as- sumption
as the name indicates, try to deal with the that errors due to segment damage are rare (less
problem at the end point of the connection than 1% of the sent segments [9]) and so it is
 J. King Saud University, Vol. 22, Comp. & Info. Sci., Riyadh (1431H./2010) 47

assumed that most of the segment loss is because this step of the algorithm that may affect TCP
of congestion [10][9]. As a result, when there is a performance.
high packet damage rate or when the congestion The problem is that during the start up
loss rate exceeds 1%, the TCP performance will phase of TCP connection (slow start), the
suffer badly. Ac- cording to Jacobson [11] TCP sending rate grows exponentially until the
will lose between 50% and 75% of its throughput congestion window reaches the ssthresh. So,
when the error rate reaches 1%. giving ssthresh a high value will inject the
This shows how congestion control network with high number of segments in a short
mechanisms are intolerant to high error rates. period of time.
This behaviour can be explained if we return to However, the network may be unable to handle
the combined slow start congestion avoidance that amount of data at once and, hence, some
algorithm explained in Stevens [10] and packets may be dropped due to congestion.
Allman[12]. In this algorithm Stevens [10] Moreover, due to this congestion, more than one
explained how TCP should react to congestion segment may be dropped from the same window
as follows: If there is a duplicate [13] and this will create problems to the TCP
acknowledgment then TCP should set the slow fast retransmission mechanism proposed by
start threshold ssthresh to half of current window Jacobson [11].
size (the window size when the error happened) The fast retransmission algorithm [11] can
and then enters the slow start mode when a handle only one drop per window and hence if
timeout occurs. This way all drops will be more than one segment is dropped from the
recovered by entering slow-start, however, TCP same window, only one will be resent by fast
performance will decrease sharply. retransmission and TCP will recover from the
For this reason, Jacobson [11] suggests that other losses by using a retransmission timeout
TCP can use the knowledge brought by (RTO) which will initiate the slow start
duplicate acknowledgment to resend the lost algorithm which will reduce the congestion
packet (a fast retrans- mission) and then there is window size to its initial value (usually one
no need to enter slow start because the segment) and TCP performance will suffer badly
duplicate acknowledgments indicate that these [13].
packet have left the network and there is more To understand why the fast retransmission
space for new packets to be injected into the algorithm cannot recover from multiple drops,
network [12] so no need to reduce the cwnd to Stevens [10] indicated that the fast
one segment by entering slow start. Instead, TCP retransmission algorithm is terminated whenever
enters con- gestion avoidance by reducing the a new acknowledgment is received. This new
congestion window to the half of the current acknowledg- ment is assumed to acknowledge all
window size. packets sent after the lost segment up to the
Another reason for not using slow start is window size. However, if multiple segments were
given by Stevens [10]. He noted that because we dropped, this acknowledgment will acknowledge
know that there is still data flowing in the only the segments that have been received
connection because of the duplicate correctly up to the second drop. Hence, fast
acknowledgments we received, we do not want to transmission will be terminated before resending
cut this flow by entering slow start [10]. all lost segments and TCP will enter a series of
retransmission timeouts causing the performance
3.3 Fast retransmission phase (TCP- to degrade.
NewReno) As a solution, Heo [13], suggested a change
When Stevens [10], in the RFC 2001, explained in the fast retransmission al- gorithm so it will
the slow start algorithm, he indi- cated that the not exit until it receives an acknowledgment for
first step in the algorithm is to initialize the slow all dropped segments. This is done by ignoring
start threshold variable ssthresh to a high value the new acknowledgments that acknowledge only
(65535 bytes). Also Allman [12], in RFC 2581, part of the sent segments and repeating fast
indicated that ssthresh could be set to an arbitrary retransmission until the sender receives an
high value. However, Heo [13] noted a problem in acknowledgment for all sent segments. This way,
48 Mohammed A. Alnuem: An Extended Review of Techniques…

there is no need to wait for the retransmission will solve the problem we described before when
timeout (RTO) to force resending the rest of the more than one packet is dropped from the same
lost segments. Floyd et al. [14] call the window [16].
intermediate acknowledgments the partial Also using selective acknowledgment will
acknowledgments. allow TCP to resend all lost pack- ets without
A new variation of TCP was proposed the need to do unnecessary retransmission of
based on these modifications and called TCP- packets already re- ceived [17]. Using selective
NewReno [14]. Also, Floyd et al. [14] has acknowledgment does not require the overhead
introduced two options of NewReno regarding of extra traffic since it is sent over normal
when to reset the retransmission timeout: the first acknowledgments [16][17].
option is called slow-but-steady NewReno and However, a disadvantage of the
the second is called impatient NewReno. In the implementation explained in [16] is that it
former the timeout clock is initialized after each requires the use of a retransmission queue to save
partial acknowledgment. This way TCP will stay unacknowledged segments. Also it requires the
in fast recovery mode as much as possible but as TCP sender to keep a record of the received
the name indicates, the resending rate will be as acknowledgments. This may requires more
low as one packet per round trip time (RTT). memory usage and perhaps more processing
However, in the impatient NewReno TCP will power for sorting and comparing sequence
reset the RTO only after the first partial numbers for segments in the queue especially
acknowledgment so if there are too many packets when TCP uses a large sending window (congestion
dropped from the same window then RTO will window). Moreover, SACK is helpless when
eventually expire before receiving a new ac- retransmission timeout occurs; all segments in the
knowledgment and, hence, TCP will enter slow retransmission queue will be resent even if they
start [14] and resend all dropped packets and cut have been sent before [16]. Last but not least,
the congestion window at the same time. applying selective acknowledgment requires
changes to both sender and receiver sides which
3.4 Selective acknowledgment (TCP- may be hard in real networks.
Sack) On the other hand, accumulative
The original idea of using selective acknowledgments which used in most TCP
acknowledgments (SACK) was proposed ini- tially variations is simple and allows easy management
by Braden and Jacobson in [15]. However, of incoming packets with no need for extra
detailed implementation and improvements to the memory or processing as in the case of selective
idea were proposed later by Mathis et al. in [16]. acknowledgment. For example it is easy, in
Selective acknowledgment is a change to the standard TCP, to discover receipt of duplicate
way the TCP receiver reacts to receiving new copies of a packet by simply comparing the
packets. Usually when the TCP receiver receives packet sequence number with the last ac-
a new packet it sends an acknowledgment to the knowledged packet number [8]. This way TCP
sender that carries the received packet sequence does not need to keep a record of the received
number which indicates to the sender that all packets and only needs to save the last in-order
previous packets up to this one have been received received packet sequence number. Another
successfully at the sender because of that it is advantage of the standard approach is that if
called cumulative acknowledgment [8]. This way an acknowledgment is dropped then it is enough
new acknowledgments will be sent only if the to receive another acknowledg- ment with higher
packets are received in order, otherwise the sequence number since it acknowledges all packets
acknowledgment will be sent for the last in-order with lower sequence numbers.
packet received (duplicate acknowledgment).
However using selective acknowledgments, the 4. Congestion and Transmission Drops
receiver will send an acknowl- edgment for each
packet no matter in what order it has arrived. In this section we will present techniques
This way the sender will have a clear idea of what designed to improve TCP performance for
packets have been received successfully and this congestion and transmission drops.
 J. King Saud University, Vol. 22, Comp. & Info. Sci., Riyadh (1431H./2010) 49

4.1 Congestion predictors timing mechanisms has given higher RTT

In this type of solution, TCP uses techniques estimations. This makes TCP take up to three
such as delays on the links (round trip time) like times longer to recover from losses [20]. A new
the CARD [18] technique (CARD stands for mechanism has been introduced based on using
Congestion Avoidance using Round Trip Delay) a time stamp for each packet and computing
or the connection throughput in the case of the the round trip time by comparing the packet’s
Tri-s scheme [19] and the Vegas scheme [20] to time stamp with its acknowledgment time stamp.
predict if there will be congestion and then This way a more accurate retransmission timeout
control the inflation and the deflation of the can be computed.
congestion window based on this prediction. If the Retransmission of lost packets: TCP-Vegas
predictor does not see congestion happening in introduces a new retransmission mechanism by
the near future then it suggests increasing the changing the way TCP responds to duplicate
congestion window. On the other hand, if the acknowledgments. TCP needs to receive three
predictor notices that congestion is coming then duplicate acknowledgments before it retransmits
it suggests that TCP decrease the congestion the lost packet. However when Vegas receives the
window. As we can see, unlike TCP, drops are not first duplicate acknowledgment for a segment it
used here to control the growth of the congestion compares the time stamp with the current time.
window. If the difference is more than the computed
In theory, the perfect predictor will eliminate timeout then it triggers retransmission without
congestion errors since it will detect and avoid waiting for more duplicate acknowledgments to
congestion before it happens. So, if an error come [20]. As we can see this will add overhead
happens then it can be considered to be caused to the system to record a time stamp for each
by the link failure (like wireless errors) rather segment and save it until it receives an
than by congestion. We will see later how acknowledgment. However, the authors indicated
congestion predictors can be used to build error that the overhead of using TCP-Vegas will not
discriminators. Following, brief explanations of exceed 5% more than older implementations [20].
some congestion predictors. The other area in which TCP-Vegas provides
changes is in congestion avoid- ance: TCP-Vegas
4.2 TCP-Vegas has made dramatic changes to the congestion
TCP-Vegas [20, 21] is a modification to the avoidance mech- anism used in TCP by making
congestion control mechanism in standard TCP TCP to increase/decrease the sending rate, not
[9, 11]. It aims to reduce the congestion losses based on packet drops as in TCP, but based on
and to increase TCP throughput by predicting prediction of available link bandwidth.
the available capacity on the link and trying not Vegas estimates an expected throughput and
to exceed it. an actual throughput for the connection. The
According to the Vegas authors in [20], Vegas expected throughput is computed using the
has increased the throughput of TCP up to 70% current window size and the minimum RTT seen
more than older implementations of TCP (TCP- so far. The actual throughput is computed using
Tahoe & TCP-Reno). Also Vegas has reduced the current window size and last RTT reading.
losses in the link up to 50% [20]. Then Vegas compares the expected
We will give here an extended explanation of throughput and the actual throughput and
TCP-Vegas because of its im- portance and since updates the sender window according to the
some other solutions are based on Vegas as we comparison results as following: If the actual
will see later. throughput is less than the expected one then
TCP-Vegas introduces changes to TCP in four TCP is unable to utilize the link because there
areas as follows: is congestion and hence it should decreases the
Timeout computation: The authors of Vegas window size [20]. On the other hand, if the actual
have noticed from experiments over the Internet throughput becomes closer to the expected
that the timing mechanism used in previous throughput then it is safe to increase the window
implementations of TCP is not accurate and that size. The increase and decrease in the window
computing round trip time (RTT) using current size is linear unlike TCP which uses Jacobson’s
50 Mohammed A. Alnuem: An Extended Review of Techniques…

AIMD [9] mechanism (Additive increase continuous estimation of the bandwidth and
multiplicative decrease) to update the congestion update the window size according to that
window. estimation [24]. This way TCP will send in a
The Vegas algorithm is expected to prevent rate that will occupy the available bandwidth
congestion from occurring and, hence, reduce only and hence any error could be considered
congestion drops dramatically. safely as a transmission error. Westwood
Slow Start: In Vegas, the congestion estimates the available bandwidth by monitoring
predictor, explained above, is added to the slow incoming acknowledgments and assumes this rate
start mechanism. Another modification Vegas re- flects available link capacity in the forward
makes to slow start is that the update of window path [24].
size during slow start is not done every RTT; Also TCP-Westwood [24] suggested that TCP
instead it takes two RTTs before increasing the does not need to halve the window size when
window size. This is done to give the algorithm errors happen, like TCP-Reno. TCP-Reno halves
chance to measure the actual throughput the window size whenever there is an error and
between updating window size [20]. hopes this action will solve the congestion and,
Hengartner et al. in [22] have reviewed each of at the same time, it increases the congestion
the modifications Vegas did to TCP. Their results window linearly to utilize the available bandwidth
show that the new retransmission technique has without more investigation of the link status. In
improved the performance noticeably because it contrast, after each drop TCP-Westwood [24] uses
was able to avoid timeouts during multiple the estimated bandwidth-delay product to set the
packet drops from the same window. It does sender window according to the current
this by performing retransmis- sion when its congestion level [25].
new timeout mechanism expires even before The authors of TCP-Westwood [24] reported
receiving duplicate acknowledgments. big improvements in TCP per- formance,
However, the results in [22] showed that TCP- especially over networks suffering from
Vegas suffers from performance degradation when transmission errors like Wired- Wireless networks
it coexists with versions of TCP that use the [24]. This improvement has been confirmed by
AIMD mecha- nism like TCP-Reno. This is Grieco & Mas-colo in [26]. Also the experimental
because the AIMD mechanism is more aggressive results reported in both [24] and in [26] showed that
in grabbing the link bandwidth because it keeps TCP-Westwood has maintained fair sharing of
increasing the window size until an error occurs the bandwidth and it does not lead to starvation
while Vegas tries to prevent causing drops and of TCP-Reno connections.
hence it keeps smaller window size. This indicates However Biaz et al.[27] did experiments on
that the congestion predictor in Vegas some- times TCP-Westwood when coexisting with non-TCP
has a negative impact on the performance [22]. traffic on the reverse link and their results
Also, we will see later how the authors in [23] indicate that TCP- Westwood could not estimate
have confirmed this fact (i.e. Vegas predictor the link capacity correctly when a non-TCP traffic
poor perfor- mance) when we talk about using exists in the reverse path. This result can be
the Vegas congestion predictor in an error explained since bandwidth estima- tion in TCP-
discriminator. Westwood is based on taking the average rate of
received acknowl- edgments and, since the added
4.3 TCP-westwood traffic in the reverse path could add additional
Mascolo et al. in [24] proposed a modification delay to the received acknowledgments, TCP-
to the congestion avoidance al- gorithm used in Westwood will underestimate the available
TCP-Reno, which uses duplicate acknowledgment bandwidth.
and timeout as an indicator for congestion and
to update the sender window [9]. However, 4.4 Error discriminators
duplicate acknowledgments do not give indication All methods that try to understand the cause
of the type of the error (con- gestion or of the error and to act differently to each type of
transmission error). For this reason Mascolo et al. error based on that understanding are called error
[24] suggested that the TCP sender should do discriminators.
 J. King Saud University, Vol. 22, Comp. & Info. Sci., Riyadh (1431H./2010) 51

Some error discriminators deal with the The mechanism works as follows: The sender
network as a black box and do not need any marks each outgoing packet with one of the marks
feedback from the network in order to (in/out) in a consistent pattern, for example by
discriminate errors. Other types of error marking four packets with (in) and the fifth
discriminators use help from intermediate packet (out) and so on. When congestion occurs
networks in order to under- stand the cause of the at intermediate nodes there should be a biased
error. queue-management mechanism that drops only
In the following, we will talk about both the packets marked with the (out) mark. This
types and we will start with error discriminators way, the receiver receives the packets with a
that depend upon the network to help consistent pattern of drops, because only
distinguishing errors. As far as we know this is packets marked with (out) are dropped, so the
the first attempt to classify error discriminators. receiver recognizes that the errors are congestion
errors.
4.5 Network dependent error On the other hand, if a wireless error occurs,
Discriminators Network dependent error then the drops will be random among all packets
discriminators are actually based at the end- (in-marked and out-marked) and, hence, the
point of the connection but use help from the receiver can recognize that these random errors
intermediate nodes. However, although they are are wireless errors [27].
not totally end-to-end we mention them here for If the receiver diagnoses a wireless error it
two reasons, first all network dependent error marks the acknowledgments with an explicit loss
discriminators explained in this section use notification (ELN). When the TCP sender
already popular active queuing mechanism receives a duplicate acknowledgment, because of
techniques like the use of explicit conges- tion error, it checks if the acknowledgment contains
notification through RED [28] (Random early ELN and, if so, TCP considers the loss to be
dropping) queues. Second reason, is that we wireless loss; otherwise it considers it to be a
want to complete the picture about the error congestion error [27]. In case of congestion error
discrimination techniques. TCP cut the congestion window, otherwise it
The advantage of this approach is that both only resend the packet and does not cut the
end hosts can have detailed information about congestion window.
the cause of drops and the network status. So, as we can see applying this mechanism
However, if we want to apply this approach in requires mainly four changes to TCP
a large network we may need a wide-scale change sender/receiver and the network: First adding
to the network components (i.e. mainly we need an error discriminator at the sender (which is
to change the routers if we want notification for called Casablanca) and acting according to the
congestion drops and we need changes in the ELN signals it receives. Second, the receiver
wireless base stations if we want wireless drop should be able to deduce when a random or
notification). non-random drop occurs and to send ELN if a
Following I will explain briefly some network random error occurs . Third, an active queuing
dependent error discriminators. mechanism should be implemented in the
bottleneck, which will drop only packets marked
4.6 TCP-casablanca with the (out) mark. Finally the packet format
The key idea TCP-Casablanca introduces should be altered to add in/out marking and
[27] is as follows: Congestion errors and ELN. The reset of the protocol is based on the
transmission errors usually happen randomly NewReno [14] version of TCP.
and this is basically why it is difficult to The authors indicated that the Casablanca
differentiate between them. However, if we can discriminator has achieved high accuracy in
”de-randomize” [27] the congestion errors by discriminating between congestion and
making congestion errors take a non-random transmission errors and, using it in TCP, gave
form then it will be easy to discriminate the non- significant (above 100%) improvement in TCP
random congestion errors from the random perfor- mance [27]. Accuracy is a crucial
wireless errors[27]. component in this error discriminator since it
52 Mohammed A. Alnuem: An Extended Review of Techniques…

uses an aggressive action toward non congestion received an ECN in the near past. If ECN is
drops by not cutting the congestion window size received before the error happened, then this is a
for these drops and keeps it as big as it was strong indication that this error is caused by
before the drop. congestion. This is based on the understanding
that, in ECN-capable connections, ECN should
4.7 TCP-ifrane always happen before congestion drops. So, if the
TCP-Ifrane [27] is a sender based version of ECN preceded the drop then TCP considers this
TCP-Casablanca [27]. In TCP- Ifrane changes drop to be conges- tion drop and acts by reducing
are made at the sender only and not the the senders window size in order to resolve the
receiver. When the sender sends a packet it congestion.
records whether this packet is marked as out or However, if the drop happens while not
in. If the sender receives a duplicate preceded by ECN, its then considered as a wireless
acknowledgment indicating that a packet is lost, error and TCP does not reduce the senders
it looks at its record and sees if that packet was window size [31]. How- ever, we still need to
marked out or in when it was sent. If the packet retransmit the lost packet. The authors in [30]
was marked out the error is considered to be argue that this approach will improve TCP
congestion error otherwise it is considered as performance over networks with transmission
wireless error [27]. TCP-Ifrane was found to give errors like wireless networks specially those suffers
higher throughput than TCP-Casablanca; this is from high error rates.
because it has less congestion accuracy and hence However, Biaz in [31] studied the possibility
it slows down less than TCP-Casablanca [27]. of using ECN to distinguish between error
However, the effect of TCP-Ifrane’s accuracy was types. He argues that this approach is not an
not studied by the authors in [27]. accurate method to differentiate between
congestion and transmission errors and showed
4.8 Explicit congestion notifications that transmission errors can be random so that the
Explicit congestion notification [29] was first probability that ECN will precede a congestion
introduced to help TCP avoid con- gestion by error is approximately the same as the
allowing intermediate nodes to set a congestion probability that ECN will precede a transmission
notification bit in the IP header whenever error[31].
congestion is expected. The TCP sender will So the authors in[31] proposed that instead of
respond to this notification by reducing its using ECN directly to infer the type of the error;
transmission rate. An Active Queue Man- TCP should also look at the state of the sender.
agement (AQM) mechanism (e.g. RED [28]) is If the sender was in congestion avoidance phase
placed at the congested nodes and becomes then the drop is probably a transmission drop.
responsible for marking packets when congestion However, if the sender was in slow start phase
is expected ( in case of RED the packets will be then the drop is considered congestion drop. The
marked when the queue reaches a particular new protocol is called TCP-Eaglet [31] and it
threshold). showed improvement over standard TCP
Using ECN requires changes in both the TCP performance.
sender and receiver. Also it requires the use of
AQM at the congested nodes. However, using 4.9 TCP-jersey
ECN does not require changing the TCP Xu et al. [32] has suggested using the
congestion mechanisms since TCP responds to estimated bandwidth instead of errors to tell
ECN in the same way as it responds to a packet TCP when to decrease sender window size,
drop. which is an idea similar to Westwood [24] but
Dawkins et al. in [30] has proposed the use with a different implementation. The available
of ECN to improve TCP per- formance over bandwidth is estimated based on the rate of
wireless links by modifying the way TCP responds arrival acknowledgments. High acknowledgment
to ECN. Biaz [31] explains the technique as arrival rate means packets can get to the other
follows: If a drop is detected by receiving duplicate end fast and hence high network capacity.
acknowledgments, then we look if we have Moreover, in this approach the nodes in the
 J. King Saud University, Vol. 22, Comp. & Info. Sci., Riyadh (1431H./2010) 53

middle should be able to mark packets when was predicting congestion then the drop is
congestion is expected in order to notify the considered to be congestion loss. However if the
sender [32]. So this method is a combination of predictor was suggesting increasing the sending
TCP-Westwood and ECN error discrimina- tor rate, because it does not predict any congestion
[30] except that it differs in some implementation in the near future, then the drop is considered to
details in both cases. be caused by link error [23] .
However, like TCP-Westwood, TCP-Jersey Also we must notice that as [23] indicated,
may suffer from performance degradation when designing an accurate error pre- dictor is
coexisting with non-TCP traffic on the reverse important since mistakes of distinguishing
link because it cannot estimate the link capacity transmission errors from congestion errors could
correctly since the added traffic in the re- verse cause unnecessary congestion which is usually
path can delay the acknowledgments, so it will avoidable by using normal congestion control
underestimate the available bandwidth. algorithms [23]. For example, if a congestion error
However, improvement has been done to TCP- is mistaken to be a transmission error then
Jersey to overcome this prob- lem. The improved TCP will not decrease the window size and this
version is called TCP-New Jersey [32] and it uses will make the current congestion much worse.
acknowl- edgment timestamps [33] instead of Experiments were performed by Biaz and
acknowledgment arrival rate to calculate Vaidya [23] on three different error discriminators
estimated bandwidth which solves the problem of based on congestion predictors: the CARD [18],
delayed acknowledgments be- cause each Tri-s [19] and Vegas [20]. Unfortunately the
acknowledgment has a time stamp which allows results obtained by Biaz and Vaidya experiments
the sender to cal- culate the forward path delay. in [23] show that these congestion predictors are
The authors indicated that simulation results of no better than a random loss predictor. From
TCP-New Jersey gave good results and show these results, Biaz came to the conclusion that
improvement in TCP performance particularly these three con- gestion predictors are not
with reverse paths that suffers from congestion suitable as an accurate error discriminator.
and lossy links [32]. The reason which leads to the failure of
these methods to make a good error
4.10 Network independent error discriminator is that they assume that if one TCP
discriminators increases its congestion window then the network
This kind of solution implicitly infers the delay will increase. So they assume that one
cause of packet drop without the need of explicit connection can affect the whole network. Using
notification from the network about the cause of this assumption, if TCP is able to gain high
the drop. In this kind, the solution is based at throughput then this is an indication that the
the end hosts (or one of them). The advantage of network is not congested. On the other hand, if
using this approach is to keep the changes to a TCP is able to gain only small part of the
minimum (to the end hosts) and there is no need expected network throughput then this means
to make changes to the network components, that a congestion exists.
which may require wide scale changes. However, However, in [34] the authors showed that
an obvious limitation to this approach is that the when TCP increases its sending rate the RTT
end hosts will not have detailed information could go either way (i.e. increase/decrease). They
about the status of the congestion or the showed that the correlation between a single
transmission drops and can only guess the connection sending rate and the RTT is weak
situation using implicit signs from the network [34]. This is because usually a single connection
(like packet delay for example). forms a small part of the network aggregate
Some of these solutions are based on using traffic.
congestion predictors like Ve- gas [20] or CARD However, the authors in [34] also emphasized
[18] or Tri-s [19]. In this approach the on the sensitivity of the net- work delay to the
discriminator works by taking input from the total load, which makes the measured RTT a
congestion predictor about the congestion status good indication of congestion events and hence
when a drop occurs. If the congestion predictor RTT can be used to build an effective error
54 Mohammed A. Alnuem: An Extended Review of Techniques…

discriminator. connection in order to predict the optimum

In the following sections we will present window size that gives maximum throughput
briefly some error discriminators based on with minimum delay. The authors in [18] call it
congestion predictors and show how they work. maximum Power where the power is the ratio
of throughput and delay : P ower = (T
4.11 Error discriminator based on vegas hroughput/Delay) [18]. The aim is to have
congestion predictor maximum Power.
Based on the Vegas predictor [20] described Unlike TCP, this approach does not use
earlier, Biaz and Vaidya [23] pro- posed an error errors to update the window size which is
discriminator that computes the difference approach similar to TCP-Vegas [21]. However
between expected throughput (link capacity) and Jain[18] did not provide a complete TCP solution
the actual throughput in order to predict con- like TCP-Vegas, instead, it gives a mechanism
gestion and use this difference to define a new that can be used to replace Jacobson’s [9]
variable fVegas. The difference is computed as congestion avoidance mechanism in TCP.
follows: D = expected throughput - actual The CARD [18] measures the change of the
throughput If D > 0 this means that TCP increase/decrease rate in the connection
throughput is less than what it should be to throughput and delay. When the network is fully
utilize the link and this indicates that congestion utilized then any small increase in the throughput
exists in the connection path and hence any drop will result in a big increase in the observed delay.
is considered to be a congestion drop. On the This gives a good indication that the network is
other hand if D ≤ 0 this means that TCP congested. However, when the network capacity is
throughput is actually able to utilize the link underutilized then the increase in the throughput
capacity and hence there is no congestion and will result in a small (or none) increase in the
any error is considered to be a transmission network delay.
error. Using this approach will add no overhead on
The simulation results in [23] show that the Vegas the network since it requires no feedback from
based error discriminator has achieved low to the network [18]. This approach assumes there is
medium performance in terms of accuracy in a single con- nection that can utilize the whole
defining error types. As we said before, this is network capacity and hence increase/decrease the
due to the assumption that the network will network delay [18]. As we said before this
respond noticeably to the changes in a single assumption is not always valid in real networks.
connection window. This is not always true Biaz et al. [23] designed an error
since, in large networks, a single connection discriminator based on the CARD [18]
forms a small fraction of the whole traffic [23] congestion predictor. The discriminator uses the
and this will affect the error discriminator assumption used in CARD that if the network is
ability to discover congestion errors. not congested then the rate of change in the
This also applies to the next two error delay will be zero. However, when the network
discriminators based on CARD [18] starts building queues with the increase in the
and Tri-s [19] congestion predictors. TCP window size then the delay will change
rapidly. The discriminator monitors the delay and
4.12 Error discriminator based on card the window size changes; if both are increasing
delay-based congestion then the drop is considered to be congestion drop
Predictor Congestion Avoidance Round trip otherwise the drops is considered transmission
Delay (CARD) [18] is an approach to up- date drop.
the TCP sender window size without the need to The results presented in [23] indicate that the
have any feedback from the network. It is called error discriminator based on the CARD predictor
[18] a black-box approach since it deals with the is poor in discriminating between error types
net- work as a black box and does not require [23]. Again this because of the assumption used
any explicit feedback from the net- work. It in CARD that a single TCP window size will
works by analyzing the relation between the affect the network delay.
round-trip delay and the throughput of the
 J. King Saud University, Vol. 22, Comp. & Info. Sci., Riyadh (1431H./2010) 55

reduce the rate at which the congestion window

4.13 Error discriminator based on tri-s increases during the congestive state. So instead of
throughput-based congestion predictor increasing the congestion window every RTT, the
The Tri-s [19] congestion predictor proposed window is increased every other RTT if the
an approach to predict conges- tions in the link system is in the congestive state [35].
based on the throughput rather than errors. Its The authors in [35] reported noticeable
difference than CARD [18] approach is that Tri-s improvement (up to 80%) for TCP- Veno over
monitors only the changes in the connection TCP-Reno in different scenarios. However, TCP-
throughput. Also this approach tries to find the Veno suffers from the bad performance of Vegas
optimal window size only at the beginning of predictor mentioned before which may lead to
the connection and fix it through the rest of the classify errors wrongly.
connection period. Only when a major change in An important feature of TCP-Veno is that it cuts
the connection happens, like when a new the congestion window even for transmission errors
connection starts or an old connection by a fixed factor of 4/5 [35] which may reduce the
terminates, the optimal window size is effect of poor discrimination ability. We could not
recalculated. Small changes during the connection find any other error discriminator that uses a
are dealt with by buffering in the network instead special action in case of transmission errors.
of changing the sender window size [19].
An error discriminator based on this idea has 4.15 Receiver based error discriminators
been proposed in [23]. This is based on the Most of the previous solutions are based in
assumption that if the network is free of the sender side of the connection. Following we
congestion then the con- nection throughput will will describe some solutions which are designed to
increase rapidly and hence any drop will be be in the receiver side of the connection.
considered to be a transmission drop. However, In [36] the authors proposed a receiver based
if there is congestion in the network the TCP error discriminator that uses a heuristic method
throughput will decrease and any error will be to discriminate between transmission and
considered to be a conges- tion drop. The results congestion losses. In this method the authors
presented in [23] show a poor discrimination level assume that the lossy link will be always the
and this is for the same reasons mentioned before bottle- neck of the connection, for example a low
for the Vegas and CARD based error bandwidth last hop in a wired-wireless network.
discriminator. Hence, in the case of congestion all packets will
be queued in the bot- tleneck in the wireless base
4.14 TCP-veno station. So, when the base station sends the
TCP-Veno [35] applies changes to the Vegas packets they will travel back-to-back on the
[20] congestion predictors in order to differentiate wireless link. As a result, the TCP receiver can
between congestive states [35] and non congestive compute the inter arrival time of the packets
states [35] of the connection. If a packet drop and use it to determine the cause of the drop.
occurs during a congestive state then it is For example, if we have packets 1,2 and 3,
considered a congestion drop otherwise it is then in normal cases there will be T time
considered transmission drop. between consecutive packets. However, if one
TCP-Veno estimates the number of packets packet is dropped, say packet 2, then the time
buffered in the network and if this number between packet 1 and 3 will be at least 2T. From
exceeds a predefined threshold (3 in this case) that the receiver can know that a drop in the
then the system enters congestive state [35]. It wireless links has occurred.
uses Vegas [20] congestion predictors to estimate However, if packet 2 was dropped before the
buffered packets and, instead of updating the base station because of conges- tion, then packets
congestion window based on this information like 1 and 3 will probably be queued in the base
Vegas, it uses it to differentiate between errors station because the wireless link is the
and uses TCP AIMD to update the congestion bottleneck, the time between packet 1 and 3 will
window. be less than 2T and hence the receiver can
The other change TCP-Veno proposes is to recognize that this error is due to congestion error
56 Mohammed A. Alnuem: An Extended Review of Techniques…

[36]. drops and seems to keep the congestion window

The problem with this method is that it open.
requires the wireless link to be the bottleneck
(the one with least bandwidth) [36]. Also, as we 4.16 Fast recovery plus
noticed from the example above, this method Fast recovery plus [39] has introduced a
works only if the wireless link is the last hop in modification to TCP fast retransmission [11] and
the path and directly before the TCP receiver and fast recovery [12] algorithms so it can
also if a non-stop stream of data is being sent discriminate between congestion and transmission
(bulk data)[36]. However, the simulation results in errors. The idea is simple; the TCP sender
[36] showed that by using this method TCP could maintains a counter of how many times the fast
discriminate between wireless and congestion retransmission-fast recovery module is called by
errors, in most cases, as good as a perfect error duplicate acknowledgments before receiving a new
discriminator i.e. with accuracy around 100% of acknowledgment. The authors in [39] assumes that
discriminating both types of errors. transmission errors will occur in small numbers
A similar approach has been proposed in per window of data compared to congestion
WTCP (Wireless Transmission Control Protocol) errors. So the counting of the number of fast
[37] but without the constraint that the base retransmission-fast recovery events can give an
station should be the bottleneck. This is achieved indication of the error type. If this number
by computing an average inter arrival time at the exceeds a preset threshold then the error is
receiver (AvgT). When a drop occurs instead of considered to be a congestion error otherwise it
comparing with T we compare with average is considered a transmission error. The author in
AvgT. If current inter arrival time is within a [39] did not explain how to choose the error
predefined threshold from AvgT then the error is threshold in order to decide the error type and we
considered a transmission error otherwise it is assume it is a fixed one that will be chosen
considered a congestion error. A promising result based on the system experimental results.
has been reported in [37] after using this The results shown in [39] presents a good
approach. improvement in TCP throughput when Fast
Another receiver based error discriminator is Recovery plus is used. However, like previous
proposed in [38] and called TCP-Real. TCP- error discriminators, this method does not
Real uses the rate of receiving data at the consider an action in case of transmission errors.
receiver to detect congestion. It computes an
expected receiving rate and an actual receiving 4.17 Spike error discriminator
rate based on the congestion window size and The authors in [40] did a series of
minimum RTT and current RTT. If the actual experiments on UDP performance in the
receiving rate is less than the expected then the Internet and they noticed that most congestion
receiver signals the sender to increase its drops occur during specific pe- riods related to
congestion window and if the expected rate is less noticeable increase in the packet trip time from
than the actual the receiver signals the sender to the sender to receiver. They call these periods
reduce its congestion window (we can notice the spike-train periods [40] since spikes appear in the
similarity with TCP-Vegas [20] which uses same packet trip time graphs when congestions occur.
concept but at the sender). These spikes were found highly correlated with
Because this method uses the receiver to congestion events and hence congestion drops
calculate the congestion window size it solves the [40].
problem when the return path is slower that the The authors in [41] used this idea to design
forward path by considering the available an error discriminator which uses spike-train
bandwidth on the forward path only [38]. periods [40]. They define two states, the spike-
Experi- mental results in [38] shows that TCP- state and, non spike-state. In the spike state the
Real improves TCP performance when compared connection is considered in congestion state and
to TCP-Reno and TCP-Tahoe specially with the any drop that occurs during this period is
increase in the error rate. However, TCP-Real considered a congestion drop. During the non
does not define a clear action for transmission spike-state any drop is considered a transmission
 J. King Saud University, Vol. 22, Comp. & Info. Sci., Riyadh (1431H./2010) 57

drop [41]. The system enters the spike-state if the bottleneck bandwidth.
packet trip time exceeded a threshold called We explained several protocols in this paper, in
Bspikestart and ends when the packet trip all of these protocols the main aim was to improve
time becomes below Bspikend [41]. These TCP performance when congestion and
thresholds are computed dynamically according transmission errors coexist. However, we can
to current relative one way trip time (ROTT) categorize these solutions into two categories
reading as follows: depending on how they solve the problem. The
first category tries to distinguish between
Bspikestart = ROT Tmin + α(ROT Tmax− ROT Tmin ) congestion and transmission errors and apply
(1) different actions for each case. All error
discriminators like TCP-Casablanca [27] come
Bspikend=ROT Tmin + β(ROT Tmax− ROT Tmin ) under this category. We will call them two actions
solutions because in concept they can apply
(2)
different actions at each case (i.e. congestion or
Spike uses ROTT instead of round trip time transmission drops).
(RTT) because it was designed for UDP On the other hand other solutions apply one
applications where there is no acknowledgment so action which can only detects and response to
the authors used the relative one way trip time congestion and will do nothing if there are no
and since the sender and receiver clock may vary congestion drops (and only there are
the term relative is used. transmission errors). These kind of solutions
The Spike [41] error discriminator performed usually ap- ply techniques which by nature
well under different scenarios where congestion respond to congestion only. For example, TCP-
and transmission errors were present. It was able Vegas [20] which uses expected and actual
to achieve high link utilization. However, its throughput to set the congestion window or
accuracy of distinguishing between error types was TCP-Westwood [24] which uses Bandwidth-Delay
moderate (around 50%) and this has led to product to set the congestion window size which
increased congestion in several cases [41]. will be affected mainly by the change in the avail-
able bandwidth due to the congestion in the
5. Conclusions and Recommendations network. These solutions do not differentiate
between error types but only respond to
Our aim in this paper is to give an overview congestion ( by increasing sending rate if there is
of the efforts to improve TCP performance in no congestion and decrease the sending rate if
presence of errors (congestion and transmission). there is congestion) so we call them the one
Some of the main end-to-end solutions are action solutions.
presented here and more related solutions can However, in both one action and two actions
be found in [42–47]. Table 1 shows some of tha solutions the TCP reaction to transmission errors
main features of the presented protocols (the is simply not to cut the congestion window and
meaning of the letters in ’Required changes’ filed to keep the sending rate as it was before the error.
in table 1 is as follows: s:sender, r:reciever, Moreover, in the two action solutions when the
n:network, pf:packet format. Also ED in the protocol discovers transmission errors it
filed ’Protocol/Technique’ means Error implicitly implies that it should increase the
Discriminator). congestion window (not just do nothing).
Also to show the effect of adding an error These assumptions give rise to a question
discriminator on TCP performance, in Fig. 1 we about whether the transmission action in current
present the performance comparison of TCP error discriminators is enough or not. Authors like
before and after adding an error discriminator [27] indicated that the current transmission action
named TWA [48] (Transmission Window Action) used in error discriminators is a bad one. This is
in a semi-log scale. This gives an example of the because it is simplistic and it ignores two facts:
noticeable effect of adding an error discriminator first it is very hard to have an end-to-end error
on TCP performance. In figure 1 the Goodput is discriminator with very high accuracy. Second,
normalized by each flow fair share of the even with accurate error discriminators
58 Mohammed A. Alnuem: An Extended Review of Techniques…

Table 1. comparison of some features in protocols presented in this paper

Protocol/Technique Action-congestion Action- Required
transmission changes
Vegas Additive Decrease Not available s+ r
Westwood BWE * MinRTT (pipe size) Not available s
Casablanca Multiplicative decrease Not available s + r + n + pf
I-frane Multiplicative decrease Not available s, n, pf
ECN Multiplicative decrease Not available s, n, pf
Jeresy Delay-Bandwidth + ECN Not available s, n, pf
ED based on Vegas Multiplicative decrease Not available s
ED based on CARD Multiplicative decrease Not available s
ED based on Tri-s Multiplicative decrease Not available s
Veno Multiplicative decrease Cut by factor (4/5) s
Biaz (receiver) Multiplicative decrease Not available r
WTCP Based on receiver estimation of congestion level Not available r
TCP-Real Based on expected and actual receiving rate Not available r
Spike Multiplicative decrease Not availabl s

Fig. 1. TCP and TWA semi-log scale normalized goodput.

mismatches between error types can occur. There should be an extended study of the
Because of that some studies like [41, 27, 45] effects of the lack of action in case of
indicated that error discriminators usually transmission errors on current error
increase the congestion loss rate noticeably. discriminators and on the network.
Moreover, even the one action solutions can As we said before, some studies noticed
be affected by the lack of ap- propriate increase in the congestion level in the network
transmission action. This could happen when the when using some error discriminators which we
technique used to discover congestion in the believe related to the lack of action in the case
network fails to do so and hence no action is taken of transmission errors. We recommend that
in case of congestion. current error discriminators should use a set of
actions in the case of transmission errors where
 J. King Saud University, Vol. 22, Comp. & Info. Sci., Riyadh (1431H./2010) 59

these actions should provide the following: in any error discriminator will create a balance
between the need to improve TCP performance
ƒ These actions should be able to achieve the and the need to prevent congestion in the
aim of any error discriminator which is to network.
improve TCP performance when congestion In this work we wanted to shed the light on the
and transmission errors coexist. need of such actions. In other works like [49] we
ƒ These actions should be able to prevent explain our vision of how these actions should be
increasing the congestion in the network designed to achieve the two aims mentioned
which may occur because of the first aim. above.

We hope that having these addition actions

References

1. Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshan, and Randy H.Katz. A comparison of mechanisms for
improving tcp performance over wirelesslinks. In Conference proceedings on Applications, technologies, architectures, and
protocols for computer communications, Palo Alto, California, United States, 1996. ACM Press. pages 256-269.
2. H. Balakrishnan, S. Seshan, Amir E., and R. H. Katz. Improving TCP/IP perfor- mance over wireless networks. In
Proceedings 1st ACM international conference on Mobile Computing and Networking (Mobicom), 1995.
3. H. Elaarag. Improving TCP performance over mobile networks. ACM Computing Surveys (CSUR), 34(3):357–374, 2002.
4. C. Parsa and J. J. Garcia-Luna-Aceves. Improving tcp performance over wireless networks at the link layer. Mobile
Networks and Applications, 5(1):57–71, 2000.
5. E. Ayanoglu, S. Paul, T. F. LaPorta, K. K. Sabnani, and R. D. Gitlin. Airmail: a link-layer protocol for wireless
networks. Wireless Networks, Kluwer Academic Publishers, 1(1):47–60, 1995.
6. A. V. Bakre and B. R. Badrinath. Implementation and performance evaluation of indirect TCP. IEEE Transactions on
Computers, 46(3):260–278, 1997.
7. K. Brown and S. Singh. M-TCP: TCP for mobile cellular networks. ACM SIG- COMM Computer Communication
Review, 27(5):19–43, 1997.
8. J. Postel. Transmission control protocol. RFC 793, 1981.
9. V. Jacobson. Congestion avoidance and control. In Symposium proceedings on Communications architectures and
protocols, pages 314–329, Stanford, California, United States, 1988. ACM Press.
10. W. Stevens. TCP slow start, congestion avoidance, fast retransmit, and fast re- covery algorithms. RFC 2001, 1997.
11. Van Jacobson. Modified TCP congestion avoidance algorithm. email sent to end2end-interest mailing list, 1990.
12. M. Allman, V. Paxson, and W. Stevens. Tcp congestion control. RFC 2581, 1999.
13. J. C. Hoe. Improving the start-up behavior of a congestion control scheme for tcp.
In Conference proceedings on Applications, technologies, architectures, and proto- cols for computer communications, pages
270–280, Palo Alto, California, United States, 1996. ACM Press.
14. S. Floyd and T. Henderson. The NewReno modification to TCP’s fast recovery algorithm. RFC 2582, 1999.
15. V. Jacobson and R. T. Braden. TCP extensions for long-delay paths. RFC 1072,1988.
16. M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. Tcp selective acknowledgement options. RFC 2018, 1996.
17. K. Fall and S. Floyd. Simulation-based comparisons of Tahoe, Reno and SACK TCP. ACM SIGCOMM Computer
Communication Review, 26(3):5–21, 1996.
18. R. Jain. A delay-based approach for congestion avoidance in interconnected hetero- geneous computer networks. ACM
SIGCOMM Computer Communication Review,
19(5):56–71, 1989.
19. Z. Wang and J. Crowcroft. A new congestion control scheme: slow start and search
(tri-s). ACM SIGCOMM Computer Communication Review, 21(1):32–43, 1991.
20. L. S. Brakmo, S. W. O’Malley, and L. L. Peterson. TCP Vegas: new techniques for congestion detection and avoidance.
In Proceedings of the conference on com- munications architectures, protocols and applications, pages 24–35, London, United
Kingdom, 1994. ACM Press.
21. L. S. Brakmo and L. L. Peterson. Tcp vegas: end to end congestion avoidance on a global internet. IEEE Journal on
Selected Areas in Communications, 13(8):1465–1480, 1995.
22. U. Hengartner, J. Bolliger, and T. Gross. Tcp vegas revisited. In Proceedings of Nineteenth Annual Joint Conference of
the IEEE Computer and Communications Societies, INFOCOM 2000, volume 3, pages 1546–1555, 2000.
23. S. Biaz and N. Vaidya. Distinguishing congestion losses from wireless transmission losses: a negative result. In
Proceedings of the Seventh International Conference on Computer Communications and Networks, pages 722–731, 1998.
24. S. Mascolo, C. Casetti, M. Gerla, M. Y. Sanadidi, and R. Wang. TCP westwood: Bandwidth estimation for enhanced
transport over wireless links. In Proceedings of the 7th annual international conference on Mobile computing and
networking, pages 287–297, Rome, Italy, 2001. ACM Press.
60 Mohammed A. Alnuem: An Extended Review of Techniques…

25. M. Gerla, G. Pau, M. Y. Sanadidi, R. Wang, S. Mascolo, C. Casetti, and S. Lee.

TCP westwood: Enhanced congestion control for large leaky pipes. In NASA Workshop, 25 June 2001.
26. L. Grieco and S. Mascolo. Performance evaluation and comparison of Westwood+, New Reno, and Vegas TCP congestion
control. ACM SIGCOMM Computer Com- munication Review, 34(2):25–38, 2004.
27. S. Biaz and N. Vaidya. De-randomizing congestion losses to improve TCP per- formance over wired-wireless
networks. IEEE/ACM Transaction in Networking,
13(3):596–608, 2005.
28. S. Floyd and V. Jacobson. Random early detection gateways for congestion avoid- ance. IEEE/ACM Transaction on
Networking, 1(4):397–413, 1993.
29. S. Floyd. Tcp and explicit congestion notification. ACM Computer Communication
Review, 24(5):10–23, 1994.
30. S. Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann, J. Touch, H. Kruse, S. Ostermann, K. Scott, and
J. Semke. Ongoing TCP research related to satellites. RFC 2760, 2000.
31. S. Biaz and X. Wang. Can ECN be used to differentiate congestion losses from wireless losses? Technical Report
CSSE04-04, Auburn University, 2004.
32. K. Xu, Y. Tian, and N. Ansari. Improving TCP performance in integrated wire- less communications networks.
Computer Networks: The International Journal of Computer and Telecommunications Networking, 2005.
33. V. Jacobson, R. Braden, and D. Borman. Tcp extensions for high performance.
RFC 1323, 1992.
34. S. Biaz and N. Vaidya. Is the round-trip time correlated with the number of packets in flight ? In Proceedings of the 3rd
ACM SIGCOMM conference on Internet measurement, IMC03, 2003.
35. Fu Cheng Peng and S. C. Liew. TCP Veno: TCP enhancement for transmission over wireless access networks. IEEE
Journal on Selected Areas in Communications,
21(2):216–228, 2003.
36. S. Biaz and N. Vaidya. Discriminating congestion losses from wireless losses using inter-arrival times at the receiver. In
Proceedings of Application-Specific Systems and Software Engineering and Technology Conference, pages 10–17, 1999.
37. P. Sinha, T. Nandagopal, N. Venkitaraman, R. Sivakumar, and V. Bharghavan.
WTCP: a reliable transport protocol for wireless wide-area networks. Wireless
Networks, 8(2/3):301–316, 2002.
38. C. Zhang and V. Tsaoussidis. TCP-real: improving real-time capabilities of tcp over heterogeneous networks. In
Proceedings of the 11th international workshop on Network and operating systems support for digital audio and video, pages
189–198, Port Jefferson, New York, United States, 2001. ACM Press.
39. X. Li, J. Wu, S. Cheng, and J. Ma. Performance enhancement of transmission control protocol (TCP) for wireless
network applications. United States Patent
6757248, 2004.
40. Y. Tobe, Y. Tamura, A. Molano, S. Ghosh, and H. Tokuda. Achieving moderate fairness for udp flows by path-status
classification. In Proceedings of the 25th Annual IEEE Conference on Local Computer Networks, pages 252–261, 2000.
41. S. Cen, P. Cosman, and G. Voelker. End-to-end differentiation of congestion and wireless losses. IEEE/ACM Transactions
on Networking, 11(5):703–717, 2003.
42. S. Biaz, M. Mehta, S. West, and N. Vaidya. TCP over wireless networks using mul- tiple acknowledgments. Technical
report, Texas A & M University, 1997. Report No. : 97-001.
43. K. Tae-eun, L. Songwu, and V. Bharghavan. Improving congestion control per- formance through loss differentiation.
In Proceedings of the Eight International Conference on computer Communications and Networks, pages 412–418, 1999.
44. N. K. G. Samaraweera. Non-congestion packet loss detection for TCP error re- covery using wireless links. IEE
Proceedings in Communications, 146(4):222–230,
1999.
45. S. Biaz and N. Vaidya. Differentiated services: A new direction for distinguishing congestion losses from wireless losses.
Technical report, University of Auburn,
2003. Report No. : CSSE03-02.
46. S. Wang and H. Kung. Use of TCP decoupling in improving tcp performance over wireless networks. Wireless Networks,
7(3):221–236, 2001.
47. C. Lim. An adaptive End-to-End loss differentiation scheme for TCP over wired/wireless networks.
IJCSNS,International Journal of Computer Science and Network Security, 7(3):72, 2007.
48. Mohammed A. Alnuem. Improving TCP Performance over Heterogeneous Net- works. PhD thesis, University of
Bradford, 2009.
49. M. Alnuem, J. Mellor, and R. Fretwell. Tcp multiple drop action for transmission errors. In PGnet2008 The 9th Annual
Postgraduate Symposium on the Convergence of Telecommunications, Networking and Broadcasting, 2008.
 ‫)‪J. King Saud University, Vol. 22, Comp. & Info. Sci., Riyadh (1431H./2010‬‬ ‫‪61‬‬

‫ﻣﺮاﺟﻌﺔ ﻣﻮﺳﻌﺔ ﻟﺘﻘﻨﻴﺎت ﺗﺤﺴﻴﻦ ﺑﺮوﺗﻮﻛﻮل ال‪TCP‬‬

‫ﻣﺤﻤﺪ ﻋﺒﺪاﷲ اﻟﻨﻌﻴﻢ‬

‫ﻗﺴﻢ ﻋﻠﻮم اﳊﺎﺳﺐ‪ ،‬ﻛﻠﻴﺔ ﻋﻠﻮم اﳊﺎﺳﺐ واﳌﻌﻠﻮﻣﺎت‬
‫ﺟﺎﻣﻌﺔ اﳌﻠﻚ ﺳﻌﻮد‪ ،‬ص‪.‬ب‪ ،٥١١٧٨ :‬اﻟﺮﻳﺎض ‪ ،١١٥٤٣‬اﳌﻤﻠﻜﺔ اﻟﻌﺮﺑﻴﺔ اﻟﺴﻌﻮدﻳﺔ‬
‫‪malnuem@ksu.edu.a‬‬

‫)ﻗﺪم ﻟﻠﻨﺸﺮ ﰲ ‪٢٠٠٩/٧/١‬م؛ وﻗﺒﻞ ﻟﻠﻨﺸﺮ ﰲ ‪٢٠٠٩/١٢/٣٠‬م(‬

‫ﻣﻠﺨﺺ اﻟﺒﺤﺚ‪ .‬ﻳﻌﺪ ﺑﺮﺗﻮﻛﻮل اﻟﺘﺤﻜﻢ ﺑﺎﻹرﺳﺎل )‪ (TCP‬واﺣﺪا ﻣﻦ أﻫﻢ ﺑﺮوﺗﻮﻛﻮﻻت اﻹﺗﺼﺎل ﰲ اﻟﺸﺒﻜﺔ اﻟﻌﺎﳌﻴﺔ )اﻹﻧﱰﻧﺖ(‪.‬‬
‫ﺣﻴﺚ ﳛﺘﻮي ﻋﻠﻰ ﻋﺪة آﻟﻴﺎت داﺧﻠﻴﺔ وﻣﻦ أﻫﻢ ﻫﺬﻩ اﻵﻟﻴﺎت آﻟﻴﺔ اﻟﺘﺤﻜﻢ ﺑﺎﻹزدﺣﺎم واﻟﱵ ﺗﺴﺎﻫﻢ ﰲ ﻣﻨﻊ ﺣﺪوث ازدﺣﺎﻣﺎت ﻏﲑ‬
‫ﻣﺮﻏﻮب ﺎ وذﻟﻚ ﻋﻦ ﻃﺮﻳﻖ ﺗﻐﻴﲑ ﺳﺮﻋﺔ اﻻرﺳﺎل ﺑﻨﺎء ﻋﻠﻰ ﺣﺎﻟﺔ اﻻزدﺣﺎم ﰲ اﻟﺸﺒﻜﺔ‪ .‬وﻣﻊ اﻟﺘﻄﻮر اﻟﻜﺒﲑ ﰲ اﻟﺸﺒﻜﺎت ﻫﺬﻩ اﻷﻳﺎم‬
‫ﻓﻘﺪ أﺻﺒﺢ ﻣﻦ اﻟﻄﺒﻴﻌﻲ أن ﻳﻌﻤﻞ ال )‪ (TCP‬داﺧﻞ ﺷﺒﻜﺎت ﺗﺘﻤﻴﺰ ﺑﻜﺜﺮة ﺿﻴﺎع ﺣﺰم اﻟﺒﻴﺎﻧﺎت أﺛﻨﺎء اﻹرﺳﺎل )ﻣﺜﻞ اﻟﺸﺒﻜﺎت‬
‫اﻟﻼﺳﻠﻜﻴﺔ( ‪ .‬اﳌﺸﻜﻠﺔ ﲢﺪث ﺣﲔ ﳜﻠﻂ ال ) ‪ (TCP‬ﺑﲔ اﻷﺧﻄﺎء ﰲ ﰲ ﺣﺎﻟﺔ اﻹرﺳﺎل واﻷﺧﻄﺎء ﺑﺴﺒﺐ اﻟﺰﺣﺎم ﳑﺎ ﻳﱰﺗﺐ ﻋﻠﻴﻪ‬
‫ﺗﺒﺎﻃﺆ ﻏﲑ ﻣﱪر ﰲ ﺳﺮﻋﺔ اﻹرﺳﺎل‪.‬‬
‫ﰲ ﻫﺬﻩ اﻟﻮرﻗﺔ أﻗﻮم ﺑﻌﺮض أﻫﻢ اﳊﻠﻮل ﳌﺸﻜﻠﺔ ﺗﺒﺎﻃﺆ أداء ﺑﺮوﺗﻮﻛﻮل ال )‪ (TCP‬ﻋﻨﺪﻣﺎ ﻳﺴﺘﺨﺪم ﻋﻠﻰ اﻟﺸﺒﻜﺎت ذات ﻣﻌﺪل‬
‫اﻷﺧﻄﺎء اﻟﻌﺎﱄ‪ .‬ﺧﻼل اﻟﻔﱰة اﻟﺴﺎﺑﻘﺔ ﰎ اﻗﱰاح اﻟﻜﺜﲑ ﻣﻦ اﳊﻠﻮل ﳍﺬﻩ اﳌﺸﻜﻠﺔ وﺳﻨﺮﻛﺰ ﰲ ﻫﺬﻩ اﻟﻮرﻗﺔ ﻋﻠﻰ اﳊﻠﻮل اﻟﱵ ﺗﻌﺎﰿ‬
‫اﳌﺸﻜﻠﺔ ﻋﻦ ﻃﺮﻳﻖ أﻃﺮاف اﻻﺗﺼﺎل دون اﳊﺎﺟﺔ ﻹﺣﺪاث ﺗﻐﻴﲑ ﰲ ﺑﺮاﻣﺞ اﻟﺸﺒﻜﺔ‪.‬‬