Pre-Congestion Notification Encoding Comparison

DiffServ mechanisms have been developed to support Quality of Service (QoS). However, the level of assurance that can be provided with DiffServ without substantial over-provisioning is limited. Pre-Congestion Notification (PCN) investigates the use of per-flow admission control to provide the required service guarantees for the admitted traffic. While admission control will protect the QoS under\ud normal operating conditions, an additional flow termination mechanism is necessary in the times of heavy congestion (e.g. caused by route changes due to link or node failure).\ud Encoding and their transport are required to carry the congestion and pre-congestion information from the congestion and pre-congestion points to the decision points. This document provides a survey of\ud several encoding methods, using comparisons amongst them as a way to explain their strengths and weaknesses.\u

Implementation of the Network Control Protocol using ECN Bits (eNCP)

Many studies have shown that the transmission con- trol protocol (TCP) which is the major transport protocol in the Internet today is finding it increasingly difficult to cope with the growth of communication network capacities and applications. TCP???s inability to properly utilize network links is one of the problems. Besides, TCP takes a long time to achieve fairness between flows. Many of the new modification of TCP inherit these main problems of TCP. Clean-slate protocols such as the explicit Congestion control Protocol (XCP) which get congestion feedback from routers can fully utilize the links and reduce queueing delays in the path of the flows. But XCP, in addition to having many router computation overheads also takes many rounds to allocate fair shares to flows. To solve the drawbacks of XCP and TCP, we have previously presented a network control protocol (NCP). NCP allocates fair share to flows in one round resulting in increased average file completion time (AFCT) as short flows are not blocked by big file transfer flows. Although smaller than that of XCP, NCP uses a 32 bit additional header in every packet to carry a congestion feedback from the routers in the path of every flow to each source of the flow. Apart from the inconvenience of modifying the TCP/IP packet formats, the additional header may accumulate to cause some increase in AFCT. In this paper we present an efficient implementation scheme (algorithm) of the Network Congestion Control (NCP) protocol using Explicit Congestion Notification (ECN) bits (eNCP). Using this implementation scheme, NCP does not need any additional packet header, avoiding the per packet overhead. In addition to the convenience of not having to change the TCP/IP packet header format, numerical results show that a significant amount of data overhead can be saved using eNCP. Not having to add a layer can also make NCP easily deployable and backward compatible.unpublishednot peer reviewe

Is Explicit Congestion Notification usable with UDP?

We present initial measurements to determine if ECN is usable with UDP traffic in the public Internet. This is interesting because ECN is part of current IETF proposals for congestion control of UDPbased interactive multimedia, and due to the increasing use of UDP as a substrate on which new transport protocols can be deployed. Using measurements from the author’s homes, their workplace, and cloud servers in each of the nine EC2 regions worldwide, we test reachability of 2500 servers from the public NTP server pool, using ECT(0) and not-ECT marked UDP packets. We show that an average of 98.97% of the NTP servers that are reachable using not-ECT marked packets are also reachable using ECT(0) marked UDP packets, and that ~98% of network hops pass ECT(0) marked packets without clearing the ECT bits. We compare reachability of the same hosts using ECN with TCP, finding that 82.0% of those reachable with TCP can successfully negotiate and use ECN. Our findings suggest that ECN is broadly usable with UDP traffic, and that support for use of ECN with TCP has increased

Comparative Study Of Congestion Control Techniques In High Speed Networks

Congestion in network occurs due to exceed in aggregate demand as compared to the accessible capacity of the resources. Network congestion will increase as network speed increases and new effective congestion control methods are needed, especially to handle bursty traffic of todays very high speed networks. Since late 90s numerous schemes i.e. [1]...[10] etc. have been proposed. This paper concentrates on comparative study of the different congestion control schemes based on some key performance metrics. An effort has been made to judge the performance of Maximum Entropy (ME) based solution for a steady state GE/GE/1/N censored queues with partial buffer sharing scheme against these key performance metrics.Comment: 10 pages IEEE format, International Journal of Computer Science and Information Security, IJCSIS November 2009, ISSN 1947 5500, http://sites.google.com/site/ijcsis

Pre-Congestion Notification (PCN) Architecture

This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain.\u

Multimedia congestion control: circuit breakers for unicast RTP sessions

The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows. This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms

Transport congestion events detection (TCED): towards decorrelating congestion detection from TCP

TCP (Transmission Control Protocol) uses a loss-based algorithm to estimate whether the network is congested or not. The main difficulty for this algorithm is to distinguish spurious from real network congestion events. Other research studies have proposed to enhance the reliability of this congestion estimation by modifying the internal TCP algorithm. In this paper, we propose an original congestion event algorithm implemented independently of the TCP source code. Basically, we propose a modular architecture to implement a congestion event detection algorithm to cope with the increasing complexity of the TCP code and we use it to understand why some spurious congestion events might not be detected in some complex cases. We show that our proposal is able to increase the reliability of TCP NewReno congestion detection algorithm that might help to the design of detection criterion independent of the TCP code. We find out that solutions based only on RTT (Round-Trip Time) estimation are not accurate enough to cover all existing cases. Furthermore, we evaluate our algorithm with and without network reordering where other inaccuracies, not previously identified, occur