29-09-2016, 11:51 AM
1456759323-10IJIRTfinalproject.pdf (Size: 469.46 KB / Downloads: 6)
Abstract: The Internet accommodates simultaneous
audio, video and data traffic. It requires the Internet
to guarantee the packet loss which at its turn depends
very much on congestion controls. A series of
protocols have been introduced to supplement the
insufficient TCP mechanism controlling the network
congestion's. CSFQ was designed as an open-loop
controller to provide the fair best effort service for
supervising the per-flow bandwidth consumption and
has become helpless when the P2P flows started to
dominate the traffic of the Internet. Token-Based
Congestion Control (TBCC) is based on a closed-loop
congestion control principles, which restricts token
resources consumed by an end-user and provides the
fair best effort service with O(1) complexity. As Self
Verifying Re-feedback and CSFQ, it experiences a
heavy load by policing inter-domain traffic for lack of
trusts. In this paper, Stable Token-Limited
Congestion Control (STLCC) is introduced as new
protocols which appends inter-domain congestion
control to TBCC and make the congestion control
system to be stable. STLCC is able to shape input and
output traffic at the inter-domain link with O(1)
complexity. STLCC produce a congestion index is
pushes the packet loss to the network edge and
improves the network performance. At last, the
simple version of STLCC is introduced. This version
is deployable in the Internet without any IP protocols
modifications and preserves also the packet
datagram.
INTRODUCTION
Modern IP network services provide for the
simultaneous digital transmission of video, voice
and data. These services require congestion control
protocols and algorithms which can solve the
packet loss parameter can be kept under control.
Congestion control is the cornerstones of packet
switching networks. It should prevent congestion
collapse it provide fairness to competing flows and
optimize transport performance indexes such as
throughput, loss and delay. The literature abounds
in papers on this subject; there are papers on highlevel
models of the flow of packets through the network, and on specific network architectures.
Despite this vast literature, congestion control in
telecommunication networks struggles with two
major problems that are not completely solved. The
first one is the time-varying delay between the
control point and the traffic sources. The second
one is related to the possibility that the traffic
sources do not follow the feedback signal. This
latter may happen because some sources are silent
as they have nothing to transmit. Originally
designed for a cooperative environment. It is still
mainly dependent on the TCP congestion control
algorithm at terminals, supplemented with load
shedding [1] at congestion links. This model is
called the Terminal Dependent Congestion Control
case. Core-Stateless Fair Queuing (CSFQ) [3] set
up an open- loop control system at the network
layer, it inserts the label of the flow arrival rate
onto the packet header at edge routers and drops
the packet at core routers based on the rate label if
congestion happens. CSFQ is first to achieve
approximate fair bandwidth allocation among flows
with O (1) complexity at core routers.
According to Cache Logic report, P2P traffic was
60% of all the Internet traffic in 2004, of which
Bit-Torrent [4] was responsible for about 30% of
the above, although the report generated quite a lot
of discussions around the real numbers. In
networks with P2P traffic, CSFQ can provide
fairness to competing flow, but unfortunately it is
not what end-users and operators really want.
Token-Based Congestion Control (TBCC) [5]
restricts the total token resource consumed by an
end-user. So, no matter how many connections the
end-user has set up, it cannot obtain extra
bandwidth resources when TBCC is used.
II. RELATED WORKS
The basic idea behind RED queue management is
to detect incipient congestion early and to convey
congestion notification to the end-hosts, allowing
them to reduce their transmission rates before
queues in the network overflow and packets are
dropped.
Flow Random Early Drop (FRED) is a modified
version of RED, which uses per-active-flow
accounting to make different dropping decisions
for connections with different bandwidth usages.
FRED only keeps track of flows that have packets
in the buffer, thus the cost of FRED is proportional
to the buffer size and independent of the total flow
numbers. FRED can achieve the benefits of perflow
queuing and round-robin scheduling. Some
other interesting features of FRED include:
(1) Penalizing non-adaptive flows by imposing a
maximum number of buffered packets, and
surpassing their share to average perflow buffer
usage;
(2) Protecting fragile flows by deterministically
accepting flows from low bandwidth connections;
(3) Providing fair sharing for large numbers of
flows by using “two-packet buffer” when buffer is
used up;
(4) Fixing several imperfections of RED by
calculate average queue length at both packet
arrival and departure (which also causes more
overhead).
CSFQ was designed as an open-loop controller to
provide the fair best effort service. CSFQ (Core
Stateless fair Queuing) is a Queuing Technique
used to achieve fair bandwidth allocation using
differential packet dropping. The CSFQ
architecture differentiates between edge and core
nodes. The edge nodes performs per flow
management, core nodes do not perform per flow
management and therefore can be efficiently
implemented at high speeds.
CONCULSION
The architecture of Token-Based Congestion
Control (TBCC), which provides fair bandwidth
allocation to end-users in the same domain will be
introduced. It evaluates two congestion control
algorithms CSFQ and TBCC. In this STLCC is
presented and the simulation is designed to
demonstrate its validity. It presents the Unified
Congestion Control Model which is the abstract
model of STLCC, CSFQ and Re-feedback. Finally,
conclusions will be given. To inter-connect two
TBCC domains, then the interdomain router is
added to the TBCC system. To support the SKA
arrangements, the inter-domain router should limit
its output token rate to the rate of the other domains
and police the incoming token rate from peer
domains.