Probabilistic Congestion Control for Non-Adaptable FlowsJörg Widmer, Martin Mauve, Jan Peter Damm (NOSSDAV’02)

Presented by Ankur Upadhyaya for CPSC 538A

Presentation Outline

PART 1: Non-Adaptable Flows

PART 2: Probabilistic Congestion Control

PART 3: Performance Evaluation

PART 4: Related and Future Work

PART 5: Discussion

PART 1: Non-Adaptable Flows

What is a non-adaptable flow?

A non-adaptable flow is defined as a data flow whose sending rate is strictly a function of the needs of the underlying application and so, cannot adjust its sending rate to control congestion.

A non-adaptable flow only operates in one of two states: it is either on, meaning that it is transmitting at a rate determined by the application or it is off, meaning that it is not transmitting any data.

Examples of Non-Adaptable Flows

In network games, the data rate is determined by the requirement that player actions must be transmitted instantaneously.

For audio or video transmissions, the data rate may be determined by a certain minimum quality requirement.

Why can’t we use existing congestion control mechanisms for such flows?

Existing congestion control mechanisms (e.g. TCP, TFRC, etc.) are based on rate adaptation. This is unacceptable for a non-adaptable flow.

For this reason, applications using non-adaptable flows often just use UDP and ignore congestion control altogether. This is also unacceptable.

Probabilistic congestion control (PCC) addresses the problem of congestion control for non-adaptable flows.

PART 2: Probabilistic Congestion Control

The Basic Idea (1)

Probabilistic congestion control (PCC) is an end-to-end congestion control mechanism for unicast non-adaptable flows.

Rather than adapting the rate of a flow, PCC turns them on and off in a way that ensures that the aggregate of a large number of such flows is TCP-friendly.

The Basic Idea (2)

PCC works by computing the probability p that the flow should be on, such that the expected average rate of the flow is TCP friendly.

The probability p is used to perform a random experiment that determines the state of the flow.

By the law of large numbers, the aggregate of a large number of flows with TCP friendly expected average rates will be TCP friendly – even though individual flows within this aggregate may be operating at an application determined rate that is not TCP friendly.

The Basic Idea (3)

By repeatedly computing p based on the current network conditions and performing the random experiment to turn flows on or off, responsiveness to changing network conditions is achieved.

Prerequisites for use of PCC (1)

Network conditions must be relatively independent of the state of a single PCC flow. As we are interested in applying the law of large numbers to achieve a desired aggregate effect, each individual flow should have a negligible impact on congestion.

The average rate of a PCC (rNA) flow can be estimated. This can be done in a number of ways, including using samples of past data rate or application level knowledge.

Prerequisites for use of PCC (2)

The average rate of a TCP flow under comparable conditions (rTCP) can be estimated. We will simply use the model for TCP-friendly rate used by TFRC.

PCC flows start up independently of each other.

Architecture

The following block diagram shows the architecture of PCC:

Basic Operation (1)

The receiver sends control packets labeled with a flow state (on or off) and a timestamp to the sender.

The sender uses the flow state on these packets to determine its state. If in the on state, the sender transmits data to the receiver at a rate determined by the application.

The data packets sent by the sender contain sequence numbers to allow detection of lost packets.

Basic Operation (2)

More importantly, the data packets contain (1) the timestamp of the most recently received control packet and (2) the time between the reception of that control packet and the transmission of the current data packet.

Using this extra information on the data packets, the receiver can compute estimates of the RTT, tRTT, and the loss event rate (as defined in TFRC), l.

Basic Operation (3)

Using a model such as the one below, the receiver can compute the TCP-friendly rate rTCP (note that s is the packet size).

Basic Operation (4)

Using an estimate of the average rate of the non-adaptable flow, rNA, the probability that the flow should remain in the on state can be computed using the equation below.

Based on a random experiment characterized by p, we either keep the flow running or suspend it.

Basic Operation (5)

The parameter T can be interpreted as (1) the time for which a flow is suspended before we repeat our random experiment or (2), the longest time a flow can remain on before we repeat the random experiment.

T is application specific. It should be large enough to accommodate a meaningful operation for the application (e.g. transmit a news clip).

Basic Operation (6)

As a side note, the control packets also serve as a backup mechanism in the case of heavy congestion. If the sender stops receiving them, it will stop transmitting.

Also note that wherever possible, functionality has been placed on the receiver instead of the sender. This is to facilitate future extension of PCC to multicast congestion control.

Continuous Evaluation

Network conditions must still be monitored when the flow in the on state.

If we notice a degradation in network conditions, we must resume our random experiments with an appropriately revised p value.

Loss-Rate Monitoring (1)

With loss-rate monitoring, a PCC flow uses probe packets to continuously monitor the loss rate.

By correlating the loss rate with its own on and off times, a PCC flow can determine its individual impact on network conditions.

Clearly, a large variation in loss rates between on and off times indicates a large impact.)

Loss-Rate Monitoring (2)

If the PCC flow has a large impact on the network conditions, the prerequisite level of statistical multiplexing is not being achieved and the flow should be turned off.

Fixed On-Time

Some applications have a strict requirement on the duration of their on-time T, but are flexible as to when they take this on-time.

Fixed On-Time allows a PCC flow stay on, uninterrupted, for a time of T, but requires it to stay off afterwards for a sufficiently long period of time to ensure TCP-friendliness.

Clearly, T must still be small enough to ensure responsiveness to changes in network conditions.

Probe While Off (1)

A suspended PCC flow must wait for its off-time, T , to pass before resuming, even if network conditions improve before this.

This can degrade PCC’s performance for large T.

Probe While Off addresses this problem by sending probe packets onto the network at a very low data rate (rOFF). These are used to compute rTCP.

Probe While Off (2)

Note that the expression for the expected data rate of a PCC flow must be changed to p * T * rNA + (1-p) * T * rOFF to account for these probe packets.

If rTCP improves beyond a certain threshold, a suspended flow can resume immediately.

Without the use of a proper threshold on rTCP this technique may produce frequent changes between on and off states that are distracting to an end-user.

Probe Before On (1)

Immediately turning on a flow during initialization makes no attempt to explore available bandwidth.

Also, if the flow is turned off right after initialization, the application will only appear to work for a brief moment.

Probe Before On addresses this problem by sending probe packets at an increasing rate before deciding whether or not to turn on a flow.

Probe Before On (2)

In this way, the flow will only be turned on after a random experiment based on reliable parameter estimates has been made.

Drawbacks of this technique include the bandwidth consumed by the probe packets and the delay of the initial startup of a flow.

PART 3: Performance Evaluation

Simulation Setup

A standard dumbbell topology, common in the evaluation of congestion control protocols was used.

Intra-Protocol Friendliness

Responsiveness

Varying Off Times

PART 4: Related and Future Work

Related Work

A considerable amount of work has been done on rate adaptive congestion control schemes (e.g. TCP and TCP friendly schemes such as PGMCC, TEAR, TFRC, FLID-DL).

Other than PCC, no work has been done on congestion control for non-adaptable flows.

Future Work

Complementing existing rate adaptive congestion control mechanisms with PCC.

Applying to other service models the idea of probabilistically controlling individual flows to achieve certain aggregate characteristics.

PCC for multicast transmissions.

Future Work

Finding methods more accurate methods of estimating fair TCP rate when loss event rate measured at sending rate considerably different from TCP friendly rate.

PART 5: Discussion