Fuzzy Controller based TCP-Vegas Enhancement for Congestion Control

In this research work, an efficient fuzzy based TCP
congestion controller is developed to avoid network
collapse. The algorithm dynamically estimates the available
network bandwidth at any time and adapts the sending rate
at the TCP sender according to the changes in traffic load.
The proposed mechanism efficiently utilizes available
capacity of the network as it adapts the sending rate
dynamically. The results indicate that the proposed
controller real network is more effective than TCP Vegas
real network.

During the past few years, several changes have been
made to the Transmission Control Protocol (TCP) [1], and
different mechanisms have been implemented to avoid
congestion problem [2]. The most popular mechanisms
include TCP Tahoe [3], Reno , New-Reno [12], Sack [6] and
Vegas [4,5,7,8,10]. However, most of the existing
mechanisms adapt the sending rate at the sender without
considering the network load. Briefly, when detecting
congestion, some mechanisms adjust the congestion window
size to one segment and go back to slow start phase. Other
mechanisms adjust the congestion window to slow-start
threshold and go back to congestion avoidance phase. This
behavior decreases the network throughput especially at high
traffic load because the protocol does not use the available
network capacity.
This paper presents a new fuzzy controller to enhance the
TCP-Vegas for congestion control. The intended controller
changes the sanding rate at the sender dynamically based on
the network load. It detects the load by using the Round Trip
Time (RTT) and then adjusts the congestion window size
that in turn adjusts the sending rate. The achievement of the
intended TCP-Vegas fuzzy controller is evaluated by using
the well-known Network Simulator NS-2.
The remainder is regular as follows, Section 2 describes
the behavior of the TCP Vegas while section 3 presents the
problems of TCP Vegas. Section 4 describes the intended
Fuzzy based TCP congestion controls while section 5
presents performance evaluation. Finally, the paper
conclusions.
II. TCP Vegas
TCP Vegas is prefectly different from TCP Tahoe, Reno and
their modifications. It uses packet delay, rather than packet
loss, as a signal to detect congestion at an incipient stage
and then determine the sending packet rate at the sender . In
other words, TCP Vegas develops the congestion avoidance
and fast retransmission phases of TCP Reno to linearly
increase or decrease the window size at the sender
conformity to the observed Round Trip Time (RTT) of the
packets that it has already sent. Commonly, Vegas works by
observation the difference between the expected and the
actual flow rates and adjusts the congestion window. It first
sets Base RTT to the smallest measured RTT, and calculates
the expected flow rate according to
(1)
Where, cwnd is the current window size.
In addition, it calculates the actual flow rate as follows.
(2)
Where, RTT is computed by the difference between the time
at which the ACK comes back and the sending time of the
packet.
Then, it computes the difference between the expected and
the actual flow rates as follows.
(3)

2
Finally, it updates the cwnd continuously to:
Where, α and β are two thresholds more than zero [10] .
In TCP Vegas, the difference is used to adapt the window
size. TCP Vegas defines two threshold
values . When Diff < ,
Vegas increases the window size linearly during the next
RTT. If Diff > reduced then Vegas decreases the window
size linearly during the next RTT. Otherwise, it leaves the
window size unchanged. This means that, if the observed
RTT becomes large, the network is encounter congestion,
causing TCP Vegas to reduce its window size. In addition, if
the observed RTT becomes small, the network is not
encounter congestion causing TCP Vegas to increase its
window size.
III. Problem statement
TCP Vegas has some problems that have critical impacts on
its performance ,When route of a connection changes, the
RTT increases and Vegas misreads it as the outcome of the
network congestion and accordingly decreases its own
sending rate to one segment in some mechanisms and to the
threshold value in other mechanisms . This behavior
inefficiently utilizes the available capacity of the network.
In case of no congestion, it leads to a considerable decrease
of network throughput since the number of packets to be
transmitted is less than the available capacity of the
network.
When a flow reaches to the network later than other flows
and faces with congested queues, it wrongly assesses the
measured RTT as its initial Base RTT. This means that
while other flows decrease their sending rates due to
running congestion, this flow does not sense the congestion
and inequitable increases its sending rate .
To overcome these problems, a new design is required to
adjust the sending rate at the sender according to the
available bandwidth of the network at any time.
IV. Intended Design
In this section, a new congestion control design is developed
to enhance the TCP Vegas. The main idea of the intended
design is to employ fuzzy logic capabilities to dynamically
adapt the congestion window (cwnd) that in turn adjust the
sending rate. To do this, the controller changes the window
size based on five distance values between the Diff value
and the two thresholds instead of changing the window size
according to the comparison between the Diff with the two
fixed thresholds only. That is, if the distance between the
Diff value and thresholds is very low, low, medium,
high or very high, the controller changes the window size
very low, low, high or very high, respectively.
Generally, designing fuzzy controller requires awareness of
the effect of the membership functions on the efficiency of
the controller. In other words, the challenging tasks
associated with fuzzy controller are to choose appropriate
membership functions, shape of membership functions i.e.
triangular, Gaussian etc., inference mechanism, minimum
rule base and the most convenient fuzzifier and defuzzifier .
Research results have shown that singleton fuzzifier,
triangular and trapezoid input membership functions, center
average defuzzifier and product inference engine works best
for the fuzzy controller [9,11,13,14].