Packet pair estimation

2.2.2.1 Bottleneck capacity

In [1], Van Jacobson suggested that the bottleneck capacity of a network path could be estimated by measuring the time spacing between two packets arriving at the receiver2if they where sent back-to-back by the sender. Figure 2.3 illustrates 2_{Jacobson actually measured the spacing between the acknowledgement packets arriving at} the sender side, assuming that it was the same as at the receiver side.

2.3. Application level congestion control

{

{

Figure 2.3. The probe gap model

the idea behind the technique, where the path is represented by a funnel where the vertical dimension represents the bandwidth and the horizontal dimension represents time. The colored areas show the position of the packets along the path. At the left, two packets are sent with a small input spacing δ < s/Cb on a high capacity link, where s is the size of the first (rightmost) packet and Cb is the bottleneck link capacity. It is assumed that this spacing is maintained when the two packets arrive at the bottleneck link in the middle, where the packets are spread out in time. The resulting gap between the packets is then δ = s/Cb.

By using the measured output gap δ and the known packet size, the receiver is

now able to estimate the bottleneck capacity as ˆCb= s/δ. This model is often referred to as the Probe Gap Model (PGM).

Unfortunately, the estimator is unbiased only if there is no cross traffic interfering with the two probe packets anywhere on the path. Otherwise, cross traffic packets may either increase or decrease the gap depending on whether they interfere before or after the bottleneck link respectively. This was later addressed by Paxson [20], who proposed to identify modes in the probability density function (PDF) of the output gap distribution and stated that the largest mode is with a high probability the output gap from the bottleneck link.

2.2.2.2 Available bandwidth

The probe gap model can also be extended in order to estimate the available bandwidth on the bottleneck link. This involves estimating the bandwidth usage of the cross traffic. As the estimation of available bandwidth using packet pairs is a central topic in paper B, the detailed description is given in the related work section of that paper (section 3.2.2).

2.3

Application level congestion control

Historically, congestion control has been a transport level mechanism, reflected by its location in the OSI model. The primary objective has been to avoid congestion in the network, and to ensure fairness among flows. Belonging to the transport level, congestion control functionality has traditionally been implemented in the operating system, with a relatively simple interface to the applications. For

multimedia applications however, a closer coupling between the application and the congestion controller is necessary, and the congestion control mechanism has therefore moved up the protocol stack. In this process of optimizing the application quality, properties such as fairness and network stability have a tendency to receive less attention.

When individual applications implement their own congestion control, they may work well in isolated environments where all flows are of the same type. However, if flows with different congestion control algorithms compete for the same bandwidth resources, they may interfere with each other’s regulation schemes. This may cause instability with high oscillations in the sending rates, and it may cause unfairness with some flows claiming more than their fair share of bandwidth.

To avoid these issues, different applications can use the same transport-level rate control (TRC), thereby ensuring that the underlying control algorithm is the

same for all flows. Over the open internet, TFRCis an example of a protocol

intended for such use, carefully designed in order to operate together with TCP. However, as pointed out in section 2.2,TFRCis not well suited for layered video, as the sudden increase in application sending rate causes jitter, packet loss and oscillating behavior.

In general, as long as theTRCis not targeting a specific application, there is also need for an application-level rate control (ARC). AnARChas a closer tie to the application, and ensures that rate adaption is done on the premises of the

application, and not only the network. The goal of theARCis to optimize the

QoE, which does not necessarily translate into optimizingQoS. For instance, a

high average bandwidth is not always beneficial from aQoEperspective, if the

cost is high variations in quality.

The tie to the application may vary in strength. TheARCcan be an integrated part of the application, it can be designed as a standalone protocol serving one specific application, or it may be a standalone protocol designed for a range of applications. En example of the latter is described in paper D, where the

proposed ARC is designed for applications using layered VBR video (i.e. it is

codec-independent).

Further, theARCmay be designed to work together with aTRC, or alterna-

tively, all the necessary “transport level mechanisms” can be incorporated into

theARC. However, as argued above, it is recommended to have a commonTRC

for a range of applications. Consequently, a split between the TRC and ARC

is reasonable. Figure 2.4 illustrates the protocol stack where the application,

ARCandTRCare shown as three separate protocols. This organization is the

basis for the research presented in papers C and D. Clean interfaces between the protocols facilitates modularity (e.g ability to replace the TRCwithout re-

designing/rewriting the application). Note that integrating the ARC with the

application is possible while still gaining from having a separateTRC.

There are two key elements needed in order to achieve application level congestion control:

2.3. Application level congestion control

• First of all, the application needs to be elastic, being able to adjust the

video quality. This must be done on-the-fly, making it possible to adapt the application data rate according to the varying network conditions. For inelastic applications, network level congestion control as described in section 2.1 is the alternative.

• Second, a decision-engine implementing a control method which takes

decisions about how, how much and when the video quality should be adjusted. These decisions are typically based on feedback from the peer

and/or the underlyingTRC, and the intention is to optimize performance

with respect to some video quality metric. When using a non-reliable

transport protocol, theARCmay also apply error handling techniques such

as retransmission or forward error correction (FEC).

Figure 2.4. ARC is located between

theTRC and the application

Contributions of this thesis within the area of application level congestion control are made with respect to the last item, and will be discussed in 3.3. The described solutions rely on a video codec being able to adapt the sending rate. More specifically, layered video is assumed. For this reason, rate adaptive

video in general, and SVC in specific,

are briefly described in the following sections.