Performance Comparison of TCP Rubic and TCP Westwood Protocols
VerifiedAdded on 2019/09/13
|5
|2300
|322
Project
AI Summary
This project investigates the performance of two Transmission Control Protocol (TCP) variants, TCP Rubic and TCP Westwood, through network simulation across various network scenarios: normal, Lossy, and LFN. The study employs a dumbbell network topology to simulate file transfers and analyzes the congestion window (CWND) behavior of each protocol. Key aspects of TCP congestion control, including slow-start, congestion avoidance, and the Additive Increase/Multiplicative Decrease (AIMD) scheme, are examined. The project also provides an overview of different TCP congestion control algorithms like TCP CUBIC and TCP Westwood. The simulation results, presented in graphs and tables, compare the average goodput achieved by each TCP variant under different network conditions, offering insights into their effectiveness in mitigating congestion. The analysis aims to determine the best means of congestion control for different network types, highlighting the strengths and weaknesses of each protocol. The project uses the results to demonstrate the application of congestion control techniques.
Abstract—this paper studied and compared the performance of transport protocols namely TCP (Rubic) and TCP (Westwood) by
means of network simulation.
Keywords—tcp, congestion avoidance
I. INTRODUCTION
Transmission Control Protocol (TCP) uses a network
congestion-avoidance algorithm that includes various
aspects of an additive increase/multiplicative decrease
(AIMD) scheme, with other schemes such as slow-start to
achieve congestion avoidance. The TCP congestion-
avoidance algorithm is the primary basis for congestion
control in the Internet. [1][2][3][4][5]
There are two classic TCP variants, TCP Tahoe and TCP
Reno. The two algorithms were named after the 4.3BSD
operating system. The “Tahoe” algorithm first appeared in
4.3BSD-Tahoe that was developed to support the CCI
Power 6/32 “Tahoe” minicomputer, and was available to
non-AT&T licensees as part of the “4.3BSD Networking
Release 1.” Enhancements were implemented to 4.3BSD-
Reno and released as “Networking Release 2” and later
“4.4BSD-Lite”. [1] Tahoe and Reno are similar where both
consider retransmission timeout (RTO) and duplicate ACKs
as packet loss events. The main difference is in how they
react to duplicate acknowledgement:
Tahoe: If three duplicate ACKs are received, it performs
a fast retransmit, sets the slow start threshold to half of the
current congestion window, reduces the congestion window
to 1 MSS, and resets to slow-start state.[10]
Reno: If three duplicate ACKs are received, it also
performs a fast retransmit but skip the slow-start phase by
setting the threshold value equivalent to the new congestion
window, then go into the Fast Recovery state.[10]
In both Tahoe and Reno, if an ACK times out (RTO
timeout), slow start is used, and both algorithms reduce
congestion window to 1 MSS.
In Fast Recovery state, TCP retransmits the missing packet,
then waits for an acknowledgment of the entire transmit
window before returning to congestion avoidance. If there is
no acknowledgment, TCP Reno experiences a timeout and
enters the slow-start state.
II. TCP CONGESTION CONTROL OVER VIEW
A. Operation
TCP uses a congestion control strategy to avoid
congestive collapse. It maintains a congestion window for
each connection so it controls the total number of
unacknowledged packets in end-to-end transit. This is
similar to TCP's sliding window used for flow control.
There is mechanism called slow start that TCP uses to
increase the congestion window after a connection is
initialized and after a timeout. [6] It starts with a window
double the maximum segment size (MSS). Even though the
initial rate is low, it increase rapidly: Congestion window
increases by 1 MSS for every packet acknowledged, that
means the congestion window doubles for every round-trip
time (RTT).[6] the slow start algorithm enters a new state if
the congestion window exceeds the ssthresh threshold that is
congestion avoidance. As a result of having large initial
ssthresh in some implementations (e.g., Linux), the first
slow start usually ends after a loss. Nevertheless, ssthresh is
updated at the end of each slow start and will affect
subsequent slow starts caused by timeouts. [6]
In congestion avoidance state, the congestion window is
increased additively by one MSS every RTT, as long as
non-duplicate ACKs are received. In case of packet loss, the
possibility of duplicate ACKs being received is very high
(duplicate ACKs could be prompted as result of a lot of
packet reordering on the stream). [10][6]
B. Congestion window
In (TCP), the congestion window is “one of the factors
that determines the number of bytes that can be outstanding
at any time”. [3] The congestion window is maintained by
the sender, where the TCP window size is maintained by the
receiver. The congestion window main objective is to control
the link between the sender and the receiver and stop it from
getting overloaded with too much traffic. It is measured by
approximating how much congestion there is between tow
ends (sender & receiver) and the value maintained
independently at each host. [3]
When a connection is set up, the congestion window
value is set to a small multiple of the (MSS) allowed on that
connection. Additional alteration in the congestion window
is applied by an Additive Increase/Multiplicative Decrease
approach (AIMD).
So, if all segments are received and the
acknowledgments reach the sender on time, there will be
some constant added to the window size. The window will
keep increasing exponentially until a timeout occurs or the
receiver reaches its limit (a threshold value "ssthresh"). After
this the congestion window increases linearly at the rate of
1/(congestion window) packets on each new
acknowledgement received. On timeout:
1. Congestion window is reset to 1 MSS
2. "ssthresh" is set to half the congestion window
size before packet loss started
3. "slow start" is initiated.
means of network simulation.
Keywords—tcp, congestion avoidance
I. INTRODUCTION
Transmission Control Protocol (TCP) uses a network
congestion-avoidance algorithm that includes various
aspects of an additive increase/multiplicative decrease
(AIMD) scheme, with other schemes such as slow-start to
achieve congestion avoidance. The TCP congestion-
avoidance algorithm is the primary basis for congestion
control in the Internet. [1][2][3][4][5]
There are two classic TCP variants, TCP Tahoe and TCP
Reno. The two algorithms were named after the 4.3BSD
operating system. The “Tahoe” algorithm first appeared in
4.3BSD-Tahoe that was developed to support the CCI
Power 6/32 “Tahoe” minicomputer, and was available to
non-AT&T licensees as part of the “4.3BSD Networking
Release 1.” Enhancements were implemented to 4.3BSD-
Reno and released as “Networking Release 2” and later
“4.4BSD-Lite”. [1] Tahoe and Reno are similar where both
consider retransmission timeout (RTO) and duplicate ACKs
as packet loss events. The main difference is in how they
react to duplicate acknowledgement:
Tahoe: If three duplicate ACKs are received, it performs
a fast retransmit, sets the slow start threshold to half of the
current congestion window, reduces the congestion window
to 1 MSS, and resets to slow-start state.[10]
Reno: If three duplicate ACKs are received, it also
performs a fast retransmit but skip the slow-start phase by
setting the threshold value equivalent to the new congestion
window, then go into the Fast Recovery state.[10]
In both Tahoe and Reno, if an ACK times out (RTO
timeout), slow start is used, and both algorithms reduce
congestion window to 1 MSS.
In Fast Recovery state, TCP retransmits the missing packet,
then waits for an acknowledgment of the entire transmit
window before returning to congestion avoidance. If there is
no acknowledgment, TCP Reno experiences a timeout and
enters the slow-start state.
II. TCP CONGESTION CONTROL OVER VIEW
A. Operation
TCP uses a congestion control strategy to avoid
congestive collapse. It maintains a congestion window for
each connection so it controls the total number of
unacknowledged packets in end-to-end transit. This is
similar to TCP's sliding window used for flow control.
There is mechanism called slow start that TCP uses to
increase the congestion window after a connection is
initialized and after a timeout. [6] It starts with a window
double the maximum segment size (MSS). Even though the
initial rate is low, it increase rapidly: Congestion window
increases by 1 MSS for every packet acknowledged, that
means the congestion window doubles for every round-trip
time (RTT).[6] the slow start algorithm enters a new state if
the congestion window exceeds the ssthresh threshold that is
congestion avoidance. As a result of having large initial
ssthresh in some implementations (e.g., Linux), the first
slow start usually ends after a loss. Nevertheless, ssthresh is
updated at the end of each slow start and will affect
subsequent slow starts caused by timeouts. [6]
In congestion avoidance state, the congestion window is
increased additively by one MSS every RTT, as long as
non-duplicate ACKs are received. In case of packet loss, the
possibility of duplicate ACKs being received is very high
(duplicate ACKs could be prompted as result of a lot of
packet reordering on the stream). [10][6]
B. Congestion window
In (TCP), the congestion window is “one of the factors
that determines the number of bytes that can be outstanding
at any time”. [3] The congestion window is maintained by
the sender, where the TCP window size is maintained by the
receiver. The congestion window main objective is to control
the link between the sender and the receiver and stop it from
getting overloaded with too much traffic. It is measured by
approximating how much congestion there is between tow
ends (sender & receiver) and the value maintained
independently at each host. [3]
When a connection is set up, the congestion window
value is set to a small multiple of the (MSS) allowed on that
connection. Additional alteration in the congestion window
is applied by an Additive Increase/Multiplicative Decrease
approach (AIMD).
So, if all segments are received and the
acknowledgments reach the sender on time, there will be
some constant added to the window size. The window will
keep increasing exponentially until a timeout occurs or the
receiver reaches its limit (a threshold value "ssthresh"). After
this the congestion window increases linearly at the rate of
1/(congestion window) packets on each new
acknowledgement received. On timeout:
1. Congestion window is reset to 1 MSS
2. "ssthresh" is set to half the congestion window
size before packet loss started
3. "slow start" is initiated.
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
As part of TCP tuning, the system administrator could
modify the maximum window size limit, or the constant
added during additive increase. [3][4][5]
C. Slow start
Slow-start is part of the congestion control strategy used by
TCP. Slow-start is used in conjunction with other
algorithms to avoid sending more data than the network is
capable of transmitting, that is, to avoid causing network
congestion. [3]
Slow-start begins initially with a congestion window Size
(cwnd) of 1, 2 or 10. [7] the value of Congestion window
increases by 1 MSS for every packet acknowledged, that
means the congestion window doubles for every round-trip
time (RTT) ("although it is not exactly exponential because
the receiver may delay its ACKs, typically sending one
ACK for every two segments that it receives"[8]). The
transmission rate will be increased with slow-start algorithm
until either a loss is detected, or the receiver's advertised
window (rwnd) is the limiting factor, or the slow start
threshold (ssthresh) is reached. If a loss event occurs, TCP
assumes that it is due to network congestion and takes steps
to decrease the load on the network. Depending on the used
TCP congestion avoidance algorithm, these measurements
varies. Once ssthresh is reached, TCP changes from slow-
start algorithm to the linear growth (congestion avoidance)
algorithm. At this point, the window is increased by 1
segment for each RTT.
Although the strategy is referred to as "Slow-Start", its
congestion window growth is quite aggressive, more
aggressive than the congestion avoidance phase. [9] Before
slow-start was introduced in TCP, the initial pre-congestion
avoidance phase was even faster.
The behavior upon packet loss depends on the TCP
congestion avoidance algorithm that is used.
III. TCP CUBIC
TCP CUBIC is also known as window-based
congestion control. In TCP CUBIC, protocols are applied
using window sizes w. The number of packets in the
network are limited to w, and the source rate is equal to w
multiplied by the message size divided by round trip time
(RTT), in bits per second (bps). In case w is too small, the
link capacities will underutilization, and in case it is too
large, congestion occurs. CUBIC does depend on the size of
the last congestion event at the time instead of ACKs for
window size increases. In this manner, congestion is
mitigated over time, with continual improvement. It is the
default protocol used for congestion control in Linux
kernels 2.6-3.1
IV. TCP WESTWOOD
TCP Westwood used for congestion control for both
wired and wireless networks. A sender-side modification of
TCP Reno, it modifies the basic congestion window
algorithm in order to decrease end-to-end congestion, with
the greatest improvement visible in wireless networks. TCP
Westwood monitors the sender’s bandwidth nonstop and
ACK return rates then adjusts for congestion accordingly. It
does not inspect or intercept packets at proxy notes. “Faster
recovery” method, in which picking a slow start threshold
consistent with wireless networking capabilities, and taking
into account packet loss as a feature of wireless networks,
instead of viewing it as network congestion. TCP Westwood
is very effective in mixed wired/wireless networks, with
throughput improvements of 550% possible when applied.
[11]
V. SIMULATION
Simulations were completed over three different network
scenarios, normal, Lossy, and LFN, for each TCP variant.
The congestion window size (CWND) were then recorded
across each network. Results were plotted in the respective
graphs. The congestion windows over time indicate the
amount of congestion that occurred, allowing for
documentation of the best means of congestion control for
each network type. It was assumed that the simulations
would depict normal network traffic for each of the three
different network scenarios.
A. Setup
The simulation program simulates file transfer using
TCP over a network with a bottleneck link. To complete
this simulation, the scenario implemented consisted of a
simple network of N clients talking to N servers through
a single backbone link. This topology, referred to as a
dumbbell network, is illustrated below. The application
used here is a simple TCP Bulksender that keeps
sending bytes up until the total bytes in the file have
been sent.
Network topology:
backbone line is between node 0 and node 1
clients are on the left side (even node numbers)
servers are on the right side (odd node
numbers)
Figure 1: Dumbbell network
n2 ---+ +--- n3
| |
n0 -- n1
| |
n4 ---+ +--- n5
modify the maximum window size limit, or the constant
added during additive increase. [3][4][5]
C. Slow start
Slow-start is part of the congestion control strategy used by
TCP. Slow-start is used in conjunction with other
algorithms to avoid sending more data than the network is
capable of transmitting, that is, to avoid causing network
congestion. [3]
Slow-start begins initially with a congestion window Size
(cwnd) of 1, 2 or 10. [7] the value of Congestion window
increases by 1 MSS for every packet acknowledged, that
means the congestion window doubles for every round-trip
time (RTT) ("although it is not exactly exponential because
the receiver may delay its ACKs, typically sending one
ACK for every two segments that it receives"[8]). The
transmission rate will be increased with slow-start algorithm
until either a loss is detected, or the receiver's advertised
window (rwnd) is the limiting factor, or the slow start
threshold (ssthresh) is reached. If a loss event occurs, TCP
assumes that it is due to network congestion and takes steps
to decrease the load on the network. Depending on the used
TCP congestion avoidance algorithm, these measurements
varies. Once ssthresh is reached, TCP changes from slow-
start algorithm to the linear growth (congestion avoidance)
algorithm. At this point, the window is increased by 1
segment for each RTT.
Although the strategy is referred to as "Slow-Start", its
congestion window growth is quite aggressive, more
aggressive than the congestion avoidance phase. [9] Before
slow-start was introduced in TCP, the initial pre-congestion
avoidance phase was even faster.
The behavior upon packet loss depends on the TCP
congestion avoidance algorithm that is used.
III. TCP CUBIC
TCP CUBIC is also known as window-based
congestion control. In TCP CUBIC, protocols are applied
using window sizes w. The number of packets in the
network are limited to w, and the source rate is equal to w
multiplied by the message size divided by round trip time
(RTT), in bits per second (bps). In case w is too small, the
link capacities will underutilization, and in case it is too
large, congestion occurs. CUBIC does depend on the size of
the last congestion event at the time instead of ACKs for
window size increases. In this manner, congestion is
mitigated over time, with continual improvement. It is the
default protocol used for congestion control in Linux
kernels 2.6-3.1
IV. TCP WESTWOOD
TCP Westwood used for congestion control for both
wired and wireless networks. A sender-side modification of
TCP Reno, it modifies the basic congestion window
algorithm in order to decrease end-to-end congestion, with
the greatest improvement visible in wireless networks. TCP
Westwood monitors the sender’s bandwidth nonstop and
ACK return rates then adjusts for congestion accordingly. It
does not inspect or intercept packets at proxy notes. “Faster
recovery” method, in which picking a slow start threshold
consistent with wireless networking capabilities, and taking
into account packet loss as a feature of wireless networks,
instead of viewing it as network congestion. TCP Westwood
is very effective in mixed wired/wireless networks, with
throughput improvements of 550% possible when applied.
[11]
V. SIMULATION
Simulations were completed over three different network
scenarios, normal, Lossy, and LFN, for each TCP variant.
The congestion window size (CWND) were then recorded
across each network. Results were plotted in the respective
graphs. The congestion windows over time indicate the
amount of congestion that occurred, allowing for
documentation of the best means of congestion control for
each network type. It was assumed that the simulations
would depict normal network traffic for each of the three
different network scenarios.
A. Setup
The simulation program simulates file transfer using
TCP over a network with a bottleneck link. To complete
this simulation, the scenario implemented consisted of a
simple network of N clients talking to N servers through
a single backbone link. This topology, referred to as a
dumbbell network, is illustrated below. The application
used here is a simple TCP Bulksender that keeps
sending bytes up until the total bytes in the file have
been sent.
Network topology:
backbone line is between node 0 and node 1
clients are on the left side (even node numbers)
servers are on the right side (odd node
numbers)
Figure 1: Dumbbell network
n2 ---+ +--- n3
| |
n0 -- n1
| |
n4 ---+ +--- n5
B. Graphs of the normal network
0.17640613.4327 26.5848 39.7413 52.6118 65.7683 78.6389 92.0304
0
10000
20000
30000
40000
50000
60000
70000
80000
90000
CWND vs time graph
TCP (Tahoe) on normal line
0.17640613.346 25.711237.839450.204762.337374.469986.8352
0
20000
40000
60000
80000
100000
CWND vs time graph
TCP (Reno) on normal line
0.17640614.1681 27.2336 40.0728 53.1383 65.9819 79.0474 91.891
0
10000
20000
30000
40000
50000
60000
70000
80000
90000
CWND vs time graph
TCP (Westwood) on normal line
0.0681835 5.8504 24.5457 37.8183 58.8115 71.713 84.8926
0
20000
40000
60000
80000
100000
120000
140000
CWND vs time graph
TCP (Cubic) on normal line
C. LFN network graphs
0.860323 19.405 35.0034 47.0929 57.724 73.0527 84.9466 96.1936
0
5000
10000
15000
20000
25000
CWND vs time graph
TCP (Tahoe) on LFN line
1.0625417.967532.869644.552556.698469.442582.6231 90.679
0
5000
10000
15000
20000
25000
30000
35000
40000
CWND vs time graph
TCP (Reno) on LFN line
1.9354914.557826.980739.499151.565963.366874.948286.6377
0
20000
40000
60000
80000
100000
120000
CWND vs time graph
TCP (Westwood) on LFN line
0.42606627.5301 48.0554 57.773 72.1646 82.6972 86.2156
0
20000
40000
60000
80000
100000
120000
140000
CWND vs time graph
TCP (Cubic) on LFN line
D. Lossy network graphs
0.17640613.4327 26.5848 39.7413 52.6118 65.7683 78.6389 92.0304
0
10000
20000
30000
40000
50000
60000
70000
80000
90000
CWND vs time graph
TCP (Tahoe) on normal line
0.17640613.346 25.711237.839450.204762.337374.469986.8352
0
20000
40000
60000
80000
100000
CWND vs time graph
TCP (Reno) on normal line
0.17640614.1681 27.2336 40.0728 53.1383 65.9819 79.0474 91.891
0
10000
20000
30000
40000
50000
60000
70000
80000
90000
CWND vs time graph
TCP (Westwood) on normal line
0.0681835 5.8504 24.5457 37.8183 58.8115 71.713 84.8926
0
20000
40000
60000
80000
100000
120000
140000
CWND vs time graph
TCP (Cubic) on normal line
C. LFN network graphs
0.860323 19.405 35.0034 47.0929 57.724 73.0527 84.9466 96.1936
0
5000
10000
15000
20000
25000
CWND vs time graph
TCP (Tahoe) on LFN line
1.0625417.967532.869644.552556.698469.442582.6231 90.679
0
5000
10000
15000
20000
25000
30000
35000
40000
CWND vs time graph
TCP (Reno) on LFN line
1.9354914.557826.980739.499151.565963.366874.948286.6377
0
20000
40000
60000
80000
100000
120000
CWND vs time graph
TCP (Westwood) on LFN line
0.42606627.5301 48.0554 57.773 72.1646 82.6972 86.2156
0
20000
40000
60000
80000
100000
120000
140000
CWND vs time graph
TCP (Cubic) on LFN line
D. Lossy network graphs
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.
Trusted by 1+ million students worldwide
0 17.289727.085441.1518 51.005 66.165477.396589.6011
0
500
1000
1500
2000
2500
3000
3500
4000
4500
CWND vs time graph
TCP (Tahoe) on Lossy line
0 5.5391422.534937.941447.701862.7462 73.733 86.3098
0
2000
4000
6000
8000
10000
12000
14000
CWND vs time graph
TCP (Reno) on Lossy line
0 13.929922.164433.7974 44.638 71.404678.634389.3612
0
2000
4000
6000
8000
10000
12000
14000
16000
CWND vs time graph
TCP (Westwood) on Lossy line
0 1.403242.7745715.022124.7548 45.859 66.510185.3162
0
2000
4000
6000
8000
10000
12000
14000
16000
CWND vs time graph
TCP (Cubic) on Lossy line
VI. SIMULATION ANALYSIS
A. Discussion
The simulation program simulates file transfer using
TCP over a network with a bottleneck link. To complete
this simulation, the scenario implemented consisted of a
simple network of N clients talking to N servers through
a single backbone link. This topology, referred to as a
dumbbell network, is illustrated below. The application
used here is a simple TCP Bulksender that keeps
sending bytes up until the total bytes in the file sent.
Network topology:
backbone line is between node 0 and node 1
clients are on the left side (even node numbers)
servers are on the right side (odd node
numbers)
Figure 1: Dumbbell network
n2 ---+ +--- n3
| |
n0 -- n1
| |
n4 ---+ +--- n5
Followings are the various parameter settings of each
network scenario.
Table 1: Parameter settings implemented
NETWORK BANDWIDTH
(BPS)
DELAY
(MS)
LOSS
(%)
FLOW
NORMAL 1000000000 1 0.0001 1
LFN 100000000 100 0.001 1
LOSSY 1000000 10 0.1 1
B. TCP goodput observations
Following table shows the TCP Average Goodput in bit per
second observed for each network scenario.
Table 2: TCP Average Goodput
TCP variant Normal
(1G)
LFN
(100M)
Lossy (1M)
Tahoe 1795921.34 352985.56 34954.28
Reno 1783263.71 408387.08 35315.54
Westwood 1762997.85 1625111.16 57906.41
Cubic 1463860.53 1168204.84 61756.22
Based on these results, it is possible to see the
different applications for each of the identified styles and
view how each is able to work to mitigate congestion
concerns.
REFERENCES
[1] Van Jacobson, Michael J. Karels. Congestion Avoidance and Control
(1988). Proceedings of the Sigcomm '88 Symposium, vol.18(4):
pp.314–329. Stanford, CA. August 1988. This paper originated many
of the congestion avoidance algorithms used in TCP/IP.
[2] RFC 2001 – TCP Slow Start, Congestion Avoidance, Fast Retransmit,
and Fast Recovery Algorithms
[3] RFC 5681 – TCP Congestion Control
[4] RFC 3390 – TCP Increasing TCP's Initial Window
[5] TCP Congestion Avoidance Explained via a Sequence DiagramM.
Young, The Technical Writer’s Handbook. Mill Valley, CA:
University Science, 1989.
[6] JACOBSON, VAN; KARELS, MICHAEL (1988). "CONGESTION
AVOIDANCE AND CONTROL" (PDF). ACM SIGCOMM
COMPUTER COMMUNICATION REVIEW 25 (1): 157–187.
[7] Corbet, Jonathan. "Increasing the TCP initial congestion window".
LWN. Retrieved 10 October 2012.
0
500
1000
1500
2000
2500
3000
3500
4000
4500
CWND vs time graph
TCP (Tahoe) on Lossy line
0 5.5391422.534937.941447.701862.7462 73.733 86.3098
0
2000
4000
6000
8000
10000
12000
14000
CWND vs time graph
TCP (Reno) on Lossy line
0 13.929922.164433.7974 44.638 71.404678.634389.3612
0
2000
4000
6000
8000
10000
12000
14000
16000
CWND vs time graph
TCP (Westwood) on Lossy line
0 1.403242.7745715.022124.7548 45.859 66.510185.3162
0
2000
4000
6000
8000
10000
12000
14000
16000
CWND vs time graph
TCP (Cubic) on Lossy line
VI. SIMULATION ANALYSIS
A. Discussion
The simulation program simulates file transfer using
TCP over a network with a bottleneck link. To complete
this simulation, the scenario implemented consisted of a
simple network of N clients talking to N servers through
a single backbone link. This topology, referred to as a
dumbbell network, is illustrated below. The application
used here is a simple TCP Bulksender that keeps
sending bytes up until the total bytes in the file sent.
Network topology:
backbone line is between node 0 and node 1
clients are on the left side (even node numbers)
servers are on the right side (odd node
numbers)
Figure 1: Dumbbell network
n2 ---+ +--- n3
| |
n0 -- n1
| |
n4 ---+ +--- n5
Followings are the various parameter settings of each
network scenario.
Table 1: Parameter settings implemented
NETWORK BANDWIDTH
(BPS)
DELAY
(MS)
LOSS
(%)
FLOW
NORMAL 1000000000 1 0.0001 1
LFN 100000000 100 0.001 1
LOSSY 1000000 10 0.1 1
B. TCP goodput observations
Following table shows the TCP Average Goodput in bit per
second observed for each network scenario.
Table 2: TCP Average Goodput
TCP variant Normal
(1G)
LFN
(100M)
Lossy (1M)
Tahoe 1795921.34 352985.56 34954.28
Reno 1783263.71 408387.08 35315.54
Westwood 1762997.85 1625111.16 57906.41
Cubic 1463860.53 1168204.84 61756.22
Based on these results, it is possible to see the
different applications for each of the identified styles and
view how each is able to work to mitigate congestion
concerns.
REFERENCES
[1] Van Jacobson, Michael J. Karels. Congestion Avoidance and Control
(1988). Proceedings of the Sigcomm '88 Symposium, vol.18(4):
pp.314–329. Stanford, CA. August 1988. This paper originated many
of the congestion avoidance algorithms used in TCP/IP.
[2] RFC 2001 – TCP Slow Start, Congestion Avoidance, Fast Retransmit,
and Fast Recovery Algorithms
[3] RFC 5681 – TCP Congestion Control
[4] RFC 3390 – TCP Increasing TCP's Initial Window
[5] TCP Congestion Avoidance Explained via a Sequence DiagramM.
Young, The Technical Writer’s Handbook. Mill Valley, CA:
University Science, 1989.
[6] JACOBSON, VAN; KARELS, MICHAEL (1988). "CONGESTION
AVOIDANCE AND CONTROL" (PDF). ACM SIGCOMM
COMPUTER COMMUNICATION REVIEW 25 (1): 157–187.
[7] Corbet, Jonathan. "Increasing the TCP initial congestion window".
LWN. Retrieved 10 October 2012.
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
[8] "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast
Recovery Algorithms". January 1997.
[9] Jacobson, Van; Karels, MJ (1988). "Congestion avoidance and
control" (PDF). ACM SIGCOMM Computer Communication Review
18 (4): 314–329.
[10] Kurose & Ross 2008, p. 284.
[11] S. Ha, I. Rhee, & L. Xu, "CUBIC: A New TCP-Friendly High-Speed
TCP Variant", PDF copy of journal article
Recovery Algorithms". January 1997.
[9] Jacobson, Van; Karels, MJ (1988). "Congestion avoidance and
control" (PDF). ACM SIGCOMM Computer Communication Review
18 (4): 314–329.
[10] Kurose & Ross 2008, p. 284.
[11] S. Ha, I. Rhee, & L. Xu, "CUBIC: A New TCP-Friendly High-Speed
TCP Variant", PDF copy of journal article
1 out of 5
Your All-in-One AI-Powered Toolkit for Academic Success.
+13062052269
info@desklib.com
Available 24*7 on WhatsApp / Email
![[object Object]](/_next/static/media/star-bottom.7253800d.svg)
Unlock your academic potential
Copyright © 2020–2025 A2Z Services. All Rights Reserved. Developed and managed by ZUCOL.