TCP congestion control

Summary

Transmission Control Protocol (TCP) uses a congestion control algorithm that includes various aspects of an additive increase/multiplicative decrease (AIMD) scheme, along with other schemes including slow start and congestion window (CWND), to achieve congestion avoidance. The TCP congestion-avoidance algorithm is the primary basis for congestion control in the Internet. Per the end-to-end principle, congestion control is largely a function of internet hosts, not the network itself. There are several variations and versions of the algorithm implemented in protocol stacks of operating systems of computers that connect to the Internet. To avoid congestive collapse, TCP uses multi-faceted congestion-control strategy. For each connection, TCP maintains a CWND, limiting the total number of unacknowledged packets that may be in transit end-to-end. This is somewhat analogous to TCP's sliding window used for flow control. Additive increase/multiplicative decrease

Official source

https://en.wikipedia.org/wiki/TCP_congestion_control

About this result

This page is automatically generated and may contain information that is not correct, complete, up-to-date, or relevant to your search query. The same applies to every other page on this website. Please make sure to verify the information with EPFL's official sources.

Related publications (60)

Related publications

Related people (6)

Related people

Related units (3)

Related units

Related concepts (7)

Related concepts

Related courses (6)

Related courses

Related lectures (6)

Related lectures

In this work, we address the transport of high quality voice over the Internet with a particular concern for delays. Transport of interactive audio over IP networks often suffers from packet loss and variations in the network delay (jitter). Forward Error Correction (FEC) mitigates the impact of packet loss at the expense of an increase of the end-to-end delay and the bit rate requirement of an audio source. Furthermore, adaptive playout buffer algorithms at the receiver compensate for jitter, but again this may come at the expense of additional delay. As a consequence, existing error control and playout adjustment schemes often have end-to-end delays exceeding 150 ms, which significantly impairs the perceived quality, while it would be more important to keep delay low and accept some small loss. We develop a joint playout buffer and FEC adjustment scheme for Internet Telephony that incorporates the impact of end-to-end delay on perceived audio quality. To this end, we take a utility function approach. We represent the perceived audio quality as a function of both the end-to-end delay and the distortion of the voice signal. We develop a joint rate/error/playout delay control algorithm which optimizes this measure of quality and is TCP-Friendly. It uses a channel model for both loss and delay. We validate our approach by simulation and show that (1) our scheme allows a source to increase its utility by avoiding increasing the playout delay when it is not really necessary and (2) it provides better quality than the adjustment schemes for playout and FEC that were previously published. We use this scheme in the framework of non-elevated services which allow applications to select a service class with reduced end-to-end delay at the expense of a higher loss rate. The tradeoff between delay and loss is not straightforward since audio sources may be forced to compensate the additional losses by more FEC and hence more delay. We show that the use of non-elevated services can lead to quality improvements, but that the choice of service depends on network conditions and on the importance that users attach to delay. Based on this observation, we propose an adaptive service choosing algorithm that allows audio sources to choose in real-time the service providing the highest audio quality. In addition, when used over the standard IP best effort service, an audio source should also control its rate in order to react to network congestion and to share the bandwidth in a fair way. Current congestion control mechanisms are based on packets (i.e., they aim to reduce or increase the number of packets sent per time interval to adjust to the current level of congestion in the network). However, voice is an inelastic traffic where packets are generated at regular intervals but packet size varies with the codec that is used. Therefore, standard congestion control is not directly applicable to this type of traffic. We present three alternative modifications to equation based congestion control protocols and evaluate them through mathematical analysis and network simulation.

EPFL2003

Extending R2P2 with Congestion Control and Request-Level Scheduling

Konstantinos Prasopoulos

Distributed low-latency datacenter applications must meet strict service-level objectives in the order of microseconds. R2P2 is a novel datacenter transport protocol designed for such services. This work extends R2P2 with congestion control and request-level scheduling. It provides a configurable upper bound to in-network queuing using the idleness of the ToR-to-host link as the congestion signal. It also reduces the mean and tail RPC latency by minimizing head-of-line blocking in the network through shortest remaining processing time scheduling. The receiver driven scheduling mechanism is general and can support a variety of scheduling policies. The extension improves the performance of R2P2 under network load by at least 23% and up to two orders of magnitude. Finally, it enables R2P2 to perform similarly to a theoretically near-optimal, clean-slate transport protocol design.

2020

Realisation of an Adaptive Audio Tool

Catherine Boutremans, Arnaud Meylan

Real-time audio over the best effort Internet often suffers from packet loss. At this time, Forward Error Correction (FEC) seems to be an efficient way to attenuate the impact of loss. Nevertheless to ensure efficiency of FEC, the source rate must be continuously controlled to avoid congestion. In this paper, we describe a realisation of adaptive FEC subdued to a TCP-friendly rate control.

2000

EPFL2003