Vietnam National University Hanoi

Faculty of Electronics and Telecommunications

Communication and Data Networks

NETWORK CONGESTION CONTROL LABORATORY
Experiment 1: TCP congestion control
1. INTRODUTION
Network congestion causes waste of network resources and creates many bad effects
reducing QoS (Quality of Service) of the network. It can be controlled if we manage the
operation of the networks components properly. Network congestion can only be avoided if
the amount of data in the network is limited at the rate that the network can carry. This is the
fundamental objective of network congestion control algorithms.
Network congestion control algorithms can be classified into two types: one operates at
the TCP layer of the terminals and the other at the Gateways.
At the TCP layer, congestion control is based on end-to-end flow control using sliding
window. Sliding window mechanism allows TCP to send many segments before stop and wait
for ACK, thus increasing the transfer rate. The change of window size affects directly the
loading data rate. So a reasonable operation of sliding window will help limit network
congestion. However, TCP congestion control algorithms not only manage the window, but
also manage the retransmit timer, which is one of two factors that affect the transmission
operation of TCP. The algorithms differ mainly in the window management part. Many
algorithms have been proposed such as Tahoe, Reno, Vegas, SACK, Veno, etc. Tahoe and
Reno are reactive algorithms, so the throughput often changes periodically. Although Tahoe
does not function well after a loss of segment, but its simplicity and early appearance make it
very popular. Reno is to overcome the weakness of Tahoe, but it only perform well when the
number of lost segment in one data window is not more than one. Vegas is a proactive
algorithm, so it has many strengths such as lower segment loss, stable throughput, less
congestion, etc.. However, the deployment of Vegas is limited not only because of its late
appearance but also because of its poor competition when it cooperates with reactive
algorithms. SACK focuses on solving cases that losing many segments in one data window.
However, SACK need to change at both the transmit side and the receive side, so is more
complex. While the above algorithms are not suitable for wireless communication media, in
which data loss is caused by propagation error and the burst loss rate is quite high, SACK is
still usable. Veno - a combination of Vegas and Reno, can distinguish between data loss
caused by network congestion and that caused by propagation error. It is, therefore, also a
suitable algorithm for wireless media.
At the Gateways, traditional Droptail have many weaknesses, among which the most
important one is to cause Global Synchronization (GS), forcing many TCP to reduce their
throughput synchronously and periodically, thus reducing network efficiency. RED is an
Active Queue Management (AQM) algorithm. It makes the operation of the Gateway more
efficient and helps avoid GS. However, the performance of RED depends on the configured
parameters, and more importantly, on the level of data carried in the network. So the QoS, the
delay in particular, varies with the level of data load. Adaptive RED (ARED) is an
improvement of RED. Apart from its most important strength, which is maintaining delay in a

pre-defined narrow range, ARED also adapts some other parameters automatically, making
configuration simpler.
2. TCP CONGESTION CONTROL
2.1. Theory
2.1.1. Sliding window mechanism
The operation principle of sliding window is illustrated in Figure 1. The operation of
window for a communication process is illustrated in figure 2.
offered window
Usable window
...(n+1) (n+2) (n+3) (n+4) (n+5) (n+6) (n+7) (n+8) (n+9) (n+10) (n+11) ...

Have received
ACK

Have transmitted but havent

received ACK

Can be transmitted
without ACK

Can not be
transmitted
until window
going right

Figure 1: Sliding Window

2.1.2. TCP Tahoe

Apart from using sliding window, Tahoe also uses an additional window called offered
window. If cwnd (congestion window) is the window size allowed by the transmit side and
credit is the window size allowed by the receive side, then the offered window becomes min.
(cwnd,credit).
Tahoe includes 3 main techniques:
1.
SlowStart (SS): is run when TCP starts to transmit data and after recovering from a
segment loss. In this period, cwnd is increased by 1 with each received ACK. So it is
doubled after each Round Trip Time (RTT). This period is stopped when TCP detects a
segment loss.
2.
Congestion Avoidance (CA): In this period, cwnd is increased by 1 after each RTT.
3.
Fast Retransmit: When TCP receives the third Duplicate ACK (dup ACK) of a
segment, Tahoe assumes that the next segment has been lost. So TCP can perform in
the same way as when a segment loss is detected by retransmit TimerOut.
The operation of Tahoe is as follows. At the start of transmission, Tahoe get into
SlowStart with cwnd =1. At the detection of a segment loss, Tahoe retransmits the lost
segment, set thresh= cwnd then restarts SlowStart with cwnd=1. When cwnd=thresh,
Tahoe gets out of SlowStart and gets into Congestion Avoidance period. Figure 3
illustrates the operation of Tahoe at the begining, and the change of cwnd is illustrated in
Figure 4.
Strength: Simple, widely deployed
Weakness: throughput is reduced too much unnecessarily when losing a segment, retransmits
many segments that have been well received at the receiver.
2

Transport Entity A

Transport Entity B

...1000 1001

SN=1001

2400

A may send 1400 octets

2401...

SN=1201

...1000 1001

B is prepared to receive 1400 octets,

beginning with 1001

SN=1401
...1000 1001

1601

2400 2401...

A shrinks its transmit window with each

transmission
...1000 1001

2001

...1600 1601

2400 2401...

2001

SN=1601

2401...

AN=1601
W=1000

SN=1801

2601...

SN=2001

...1600 1601

2600 2601...

B acknowledges 3 segments (600 octets) but is only

prepared to receive 200 additional octets beyond the
origin budget (i.e, B will accept octetts 1601 through 2600)

...1600 1601

A adjusts its window with each credit

2001

26002601...

SN=2201
...1600 1601

2600 2601...

SN=2401

A exhausts its credit

...2600 2601

...2600 2601

AN=2601,W=1400

4000 4001...

A receives new credit

Figure 2: Example of Window operation

3

4000 4001...

B acknowledges 5 segments (1000 octets)

and restores the original amount of credit

Figure 3: SlowStart, then CA

Figure 4: cwnd of the example in Figure 4

2.1.3. TCP Reno

Reno only improves fast Retransmit of Tahoe to fast Recovery. When TCP receives third
dup ACK, it retransmits the lost segment and wait for ACK of this segment (new ACK) then
restart CA with cwnd reduced by . However, when waiting for this new ACK, Reno can
transmit new segments if it meets some conditions. If the segment loss is detected by
retransmit TimerOut, it takes similar action as Tahoe does.
Strength: get more throughput than Tahoe
Weakness: Only have good performance when the number of lost segments in the same data
window is no more than 1. When there is more than 1, cwnd is reduced many times
making its performance no better than Tahoe, or Reno must wait for retransmit TimerOut
then takes similar action as Tahoe, making the performance worse than Tahoe.
TCP NewReno
NewReno improves fast recovery of Reno to achieve better performance in the case that
many segments in the same data window are lost. It only gets out of fast recovery when all
segments that have been transmitted before starting fast recovery have corresponding ACKs.
This will avoid reducing cwnd many times. NewReno achieves its objective quite well.
However in some cases, especially when too many segments in the same data window are
lost, NewReno cant find good solution and must wait for retransmi TimerOut then restarts
SlowStart. The performance in these cases is often worse than Tahoe.
Although in some situations Reno and NewReno perform worse than Tahoe, but the
probability of these cases in wired-network is low, so in general, Reno and NewReno have
better performance than Tahoe.
The common weakness of reactive algorithms: must lose segments to determine allowed
throughput, throughput changes periodically (in case that network condition is stable),
cant distinguish segment loss caused by congestion and caused by transmission error.
2.1.4. TCP Vegas
Vegas is a proactive algorithm, it allows estimation of congestion before happening, so
can control its operation to avoid congestion. Vegas uses 3 main techniques to increase
throughput and decrease loss:
1. New retransmit mechanism: uses time with better resolution and faster retransmit
decision.
2. CA: compare actual throughput and expected throughput to have suitable action:
increase cwnd by 1, decrease by 1 or maintain it in next RTT.
3. SS: cwnd is doubled in one RTT and maintain in next RTT to compare throughputs
for decision of exiting SS or not.
Strength: less loss, stable throughput, less congestion, high average throughput
Weakness: Poor competition for throughput when cooperating with reactive algorithms, and
when cooperating with other Vegas later connections often get better throughput.

2.2. Experiments
The purpose of these experiments is to illustrate the operation and some characteristics of
above algorithms. These experiments are run in NS2. Please refer to
http://www/isi.edu/nsnam/ns for detailed installation instruction. The sources are in type
file.tcl. To run an experiment, in shell type ns file.tcl. The results are plotted in xgraph.
Please zoom in to get better detail view. You can also get the result data in file*.tr for
analyzing by your softwares. Please refer to NSmanual to get the structure of fileAll.tr and
see the finish procedure in file.tcl to get the structure of other file*.tr.
A simple network topology in Figure 5 is used to study the operation of the algorithms.
TCP always have data to transmit. Queue on the G-SINK link is a DropTail type. When SINK
receives a segment, it frees segment and makes corresponding cumulative ACK immediately.
10Mbps, 10ms
TCP

1Mbps, 100ms

SINK

Figure 5: Network topology

2.2.1. Tahoe (Tahoe.tcl)

1. Set the maximum size of transmit window to 47, queue size to 20. Run the simulation,
you will get result which is similar to Figure 6. How are the techniques of Tahoe
shown in this result? Does Tahoe show any of its characteristics in this result?
2. Change those two parameters (at least one smaller and one bigger value), do you
observe any significant difference?
3. Increase the simulation time to a large value and observe the change of cwnd. What do
you observe? How does it agree with the theory?
2.2.2. Reno (Reno.tcl v NewReno.tcl)
2.2.3. Vegas (TCPVegas.tcl)
2.3. Discussion and conclusion

Figure 6: Data transfer process of Tahoe