Managing a Queue to a Soft Delay Target

TL;DR

This paper introduces a method to incorporate a soft delay target into active queue management algorithms like PIE and PI2, aiming to improve their adaptability to network dynamics.

Contribution

It adapts the core concept of Curvy RED to more dynamic AQMs, addressing the limitations of fixed delay targets in existing algorithms.

Findings

Enhanced delay management in AQMs with soft delay targets

Improved adaptability to network dynamics

Potential for more stable queue behavior

Abstract

This memo proposes to transplant the core idea of Curvy RED, the softened delay target, into AQMs that are better designed to deal with dynamics, such as PIE or PI2, but that suffer from the weakness of a fixed delay target.

Equations

$$p^{\prime}(t)=p^{\prime}(t-T)+\alpha\big{(}q(t)-Q_{0}\big{)}+\beta\big{(}q(t)-q(t-T)\big{)},$$

$$Q(p^{\prime })=Q_0+Q_1{p}^{\prime }(t-T),$$

$$Q(p)=Q_0+Q_1\sqrt{p(t-T)}.$$

Full text

CCS Concepts

•Networks $\to$ Cross-layer protocols; Network algorithms; Network dynamics;

Keywords

Data Communication, Networks, Internet, Control, Congestion Control, Quality of Service, Performance, Latency, Responsiveness, Dynamics, Algorithm, Standards, Active Queue Management, AQM, Signalling, Sojourn time, Queue delay, Service time, wait time, Expectation, Estimation, Explicit Congestion Notificiation, ECN

1 Introduction

All the well-known modern AQMs aim for a constant target queueing delay, e.g. CoDel [NJ12] including fq-CoDel, PIE [PPP*+*13], PI2 [DSBTB16], DualPI2 [DSBEBT17], and a recent variant of DCTCP’s AQM [BCCW16, BCC*+*16]. In the technical report “Insights from Curvy RED” [Bri15] it was proved that the level of loss needed to induce TCP-based load to keep to a fixed delay target has to rise to unacceptably high levels during periods of increased load.

The report makes the point that the time taken to repair losses is itself a source of delay, particularly for short flows. Therefore, it is perverse to hold down queuing delay at the expense of very high loss levels.

[Bri15] proposes an adaptation of the RED algorithm [FJ93] called Curvy RED that uses a convex function of queuing delay as a target. This softens (increases) the delay target as load intensifies.

However RED, and by extension Curvy RED, provides no control over queue dynamics, whereas control theoretic AQMs do. This means that during dynamic load excursions, RED and Curvy RED have little control over how much delay overshoots (or undershoots) while trying to bring it back to the target. This allows delay to vary uncontrollably above the target. This is a significant problem because many applications are sensitive to maximum, not average, delay.

This memo proposes to transplant the core idea of Curvy RED, the softened delay target, into AQMs that are better designed to deal with dynamics, such as PIE or PI2, but that suffer from the weakness of a fixed delay target.

It should be emphasized that this combination is only useful when loss is used as the signalling mechanism. By extension that means this combination would also be used with classic ECN [RFB01], which requires any ECN behaviour to be equivalent to loss behaviour. However, this combination would be unnecessary for use with L4S ECN [DSBET17], which is not constrained to be equivalent to loss.

2 Curvy PI2

A Proportional Integral (PI) controller alters the congestion signalling probability dependent on both the distance from the target delay (the error) and the rate of change of the queuing delay. Therefore, it is able to rapidly control load excursions before they cause too much variation in load. Specifically, it uses an control equation of the form:

[TABLE]

where $p^{\prime}(t)$ is the drop probability at time $t$, $q(t)$ is the queuing delay at time $t$, $\alpha$ and $\beta$ are the gain constants, $T$ is the sampling period and $Q_{0}$ is the (constant) target delay.

It would be straightforward to make the target delay a function $Q()$ of the current drop probability $p(t-T)$ rather than a constant, for instance, picking a reasonable formula fairly arbitrarily, one might use:

[TABLE]

where $Q_{0}$ and $Q_{1}$ are the min and max values of the soft delay target (at $p^{\prime}=0$ and $p^{\prime}=1$).

The PI2 controller squares the resulting value of $p^{\prime}(t)$ to determine the drop probability $p=(p^{\prime})^{2}$ (see [DSBTB16] for why). Therefore Equation 2 is equivalent to:

[TABLE]

Equations 1 and 2 are illustrated in Figure 1

In practice, rather than using the arbitrary formula in Equation 1, it will be possible to determine the optimum compromise between queueing delay and loss from human factors experiments that record the mean opinion score of a 2-D matrix of these two impairments for the popular application that is most sensitive to both, e.g. voice, or perhaps virtual reality (although MOS data is more readily available for voice). Then it should be possible to fit an approximate curve to the contour of optimum pairs that will be amenable to implementation as the soft delay target function.

It might seem of concern that the loss probability depends on a delay target function, which in turn depends on the loss probability, which seems like a circular dependency. However, the target function depends on the loss probability that was output in the previous sampling period (and the second dependency will be much weaker than the first anyway).

It might seem contrary to the goal of a PI controller to allow high load to increase delay. However, there is nothing sacred about the constant delay goal that was first proposed by Hollot et al in 2001 [HMTG01a], before designing a solution in the same year [HMTG01b]. A controller can aim for any target that meets human needs, it does not have to be a constant.

3 Variants

By extension, a delay target that itself depends on the level of loss could be used in other, non-control-theoretic AQMs such as CoDel. As before, the intent would be to soften the delay target under high load, so as not to drive loss to extreme levels in pursuit of low queuing delay, given repairing loss itself introduces delay.

In the case of Codel, the variable called target would need to depend on the variable drop_next_, which determines the interval between drops.

Document history

[TABLE]