Packet Loss Control Using TOKENS At The NETWORK EDGE
A B S T R A C T (See below for source code)
Presently the Internet accommodates simultaneous audio, video, and data traffic. This requires the Internet to guarantee the packet loss which at its turn depends very much on congestion control. A series of protocols have been introduced to supplement the insufficient TCP (Transmission Control Protocol) mechanism controlling the network congestion.
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 principle, which restricts token resources consumed by an end-user and provides the fair best effort service with O(1) complexity.
As Self-Verifying CSFQ and Re-feedback, it experiences a heavy load by policing inter-domain traffic for lack of trust. 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 output and input traffic at the inter-domain link with O(1) complexity.
STLCC produces a congestion index, pushes the packet loss to the network edge and improves the network performance. Finally, the simple version of STLCC is introduced. This version is deployable in the Internet without any IP (Internet Protocol) protocols modifications and preserves also the packet datagram.
Brief Information of Project
Modern IP network services provide for the simultaneous digital transmission of voice, video, 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 therefore, the cornerstone of packet switching networks. It should prevent congestion collapse, provide fairness to competing flows and optimize transport performance indexes such as throughput, delay and loss. The literature abounds in papers on this subject; there are papers on high-level models of the flow of packets through the network, and on specific network architecture .
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 at congestion links. This model is called the Terminal Dependent Congestion Control case.
Core-Stateless Fair Queuing (CSFQ) set up an open- loop control system at the network layer, which 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 the 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 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 flows, but unfortunately it is not what end-users and operators really want. Token-Based Congestion Control (TBCC) 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.
In this paper a new and better mechanism for congestion control with application to Packet Loss in networks with P2P traffic is proposed. In this new method the edge and the core routers will write a measure of the quality of service guaranteed by the router by writing a digital number in the Option Field of the datagram of the packet. This is called a token. The token is read by the path routers and interpreted as its value will give a measure of the congestion especially at the edge routers. Based on the token number the edge router at the source, thus reducing the congestion on the path. In Token-Limited Congestion Control (TLCC), the inter-domain router restricts the total output token rate to peer domains. When the output token rate exceeds the threshold, TLCC will decreases the Token-Level of output packets, and then the output token rate will decrease.
Stable Token Limit Congestion Control (STLCC):
STLCC is able to shape output and input traffic at the inter-domain link with O(1) complexity. STLCC produces a congestion index, pushes the packet loss to the network edge and improves the network performance. To solve the oscillation problem, the Stable Token-Limited Congestion Control (STLCC) is introduced. It integrates the algorithms of TLCC and XCP altogether. In STLCC, the output rate of the sender is controlled according to the algorithm of XCP, so there is almost no packet lost at the congested link.
At the same time, the edge router allocates all the access token resource to the incoming flows equally. When congestion happens, the incoming token rate increases at the core router, and then the congestion level of the congested link will also increase. Thus STLCC can measure the congestion level analytically, allocate network resources according to the access link, and further keep the congestion control system stable.
In this paper a new and better mechanism for congestion control with application to Packet Loss in networks with P2P traffic is proposed. In this new method the edge and the core routers will write a measure of the quality of service guaranteed by the router by writing a digital number in the Option Field of the datagram of the packet. This is called a token. The token is read by the path routers and interpreted as its value will give a measure of the congestion especially at the edge routers. Based on the token number the edge router at the source, thus reducing the congestion on the path.
A core router is a router designed to operate in the Internet Backbone or core. To fulfill this role, a router must be able to support multiple telecommunications interfaces of the highest speed in use in the core Internet and must be able to forward IP packets at full speed on all of them. It must also support the routing protocols being used in the core. A core router is distinct from an edge routers.
Edge routers sit at the edge of a backbone network and connect to core routers. The token is read by the path routers and interpreted as its value will give a measure of the congestion especially at the edge routers. Based on the token number the edge router at the source, thus reducing the congestion on the path.
The Scope of the Work
At the beginning a series of protocols like TCP,CSFQ are used to controlling the network congestion. But these are become helpless when the P2P flows started to dominate the traffic of the internet.
To solve this congestion problem we are using the STLCC protocol. It is combination of XCP and TLCC. This is deployable in the internet without any IP protocol modification.
The scope of the product
1. Description of data to be entered into the system:
The sender can send the text file through peer. It is divided into packets. The receiver receives those packets based on token number.
2. Description of operation of each screen:
The sender sends or receiver receives the data through its Edge routers with help of the Core router.
3. Description of work flow:
In this first the user sends their data through the peer. At this data is divided into different number of packet. Each packet has token number. After that it is passed to Edge router with the help of the Core router. At receiver side the other user who wants the data receive the data.
4. Who can enter the data to the system:
On the sender can send the data to the system.
5. Description of Output:
Only the receiver receives the data. The data is collected in the form of packets. These packets are arranged in the order based on the token number.
Minimum Hardware Requirements
The below links contains table of contents, documentation and source code of Packet Loss Control Using Tokens At The Network Edge.