Objective, Methodology and Road Map

The objective of this dissertation is to propose the fairness control schemes respectively to solve the public and private unfair problems which currently existing solutions cannot handle at the end host or at the user-side gateway.

In public fairness, to clarify why the existing schemes cannot always have the same bandwidth as TCP, an investigation for eight well-know schemes is given in the dissertation. These schemes are classified and evaluated according to their underlying policies in three aspects, namely fairness, aggressiveness and responsiveness, as defined in Chapter 2. Next, according to the investigation, a fast-converging window-averaging rate control (WARC) scheme is proposed to have equal bandwidth to TCP more closely than existing schemes [YL00, PHP00, ROY00, JGM03, BB01, PKT99, WDM01]. WARC takes short time to converge its rate toward TCP’s whenever the available bandwidth drastically increases or decreases. Besides, when the available bandwidth keeps stationary, WARC is the first scheme providing the same bandwidth as TCP under any distributions of inter-loss time. Existing schemes provide it only under some specific assumptions, e.g. the packet losses occur periodically or with a fixed probability, but these assumptions may not be realistic in the Internet [ZDP01].

In private fairness, to realize the idea of managing the downlink bandwidth by scheduling uplink requests, the dissertation first investigates the possibility of

Fig. 1.3. A typical topology of connecting the Internet with the access link Internet

applying the class-based fair-queuing discipline, which is widely and maturely used in scheduling packets, to schedule requests. However, we found that simply applying the discipline to schedule requests would encounter three problems. The first two are on the timing of releasing requests and the selection of the next released request, respectively. The last one is about the class-based policy, which may not suit for the user-level differentiation, i.e. may not guarantee high-class users to get more bandwidth than low-class one when more users appear in the high class. Next, based on the above investigation, we propose a minimum-service first request scheduling (MSF-RS) scheme to provide bandwidth sharing and user-based weighted fairness, i.e.

a policy that guarantees the ratio of the bandwidth allocated for each high-class user to that for each low-class user matches the ratio of their weights.

The road map of the dissertation is organized as follows. Chapter 2 presents a taxonomy and evaluation for eight TCP-friendly rate control schemes. Chapter 3 proposes the fast-converging window-averaging rate control scheme for public fairness. Chapter 4 proposes the MSF-RS scheme to manage the downlink at the user-side access gateway for private fairness. The conclusions are given in Chapter 5 and advanced mathematic analyses for TCP-friendly schemes are described in Appendices.

Chapter 2

Taxonomy and Evaluation of

TCP-Friendly Congestion-Control Schemes

2.1 Introduction

Real-time streaming media, such as video/audio conversations and movies online, are now often transmitted over the Internet. Because the available bandwidth in the Internet is dynamic, a congestion control mechanism is needed to prevent the media flow from suffering serious packet losses. A flow carried over TCP generally is subject to such a congestion control mechanism. TCP is the most widely-used transport protocol in the Internet, and embeds an Additive-Increase and Multiplicative-Decrease (AIMD) congestion control mechanism.

The throughput controlled by AIMD in TCP changes dramatically and frequently, which may not satisfy real-time streaming media. Many AIMD-variant and other-style congestion control schemes have been proposed to solve this problem [YL00, PHP00, ROY00, JGM03, BB01, PKT99, WDM01]. Besides being smooth, these schemes have been suggested to be TCP-friendly [BCC98] because their controlled traffic is expected to coexist with TCP traffic in the Internet. “TCP-friendly” is a generic term describing that a scheme aims to use no more bandwidth than TCP. This study discusses in detail the proper behaviors of a TCP-friendly scheme in view of the following three criteria: TCP-compatibility, TCP-equivalence and TCP equal-share.

TCP-compatibility is defined in RFC 2309 [BCC98], which says that a TCP-compatible flow, in the steady state, should use no more bandwidth than a TCP flow under comparable conditions such as packet loss rate and round-trip time (RTT), where RTT means the time required for a packet to travel from the source to the destination and back. However, a TCP-compatible congestion control scheme is not preferred if it always offers far lower throughput than a TCP flow. Hence, a better

congestion control scheme has to not only meet TCP-compatibility, but also pursue TCP-equivalence. A TCP-equivalent flow has the same throughput as a TCP flow if it experiences identical network conditions, which mean the same patterns of packet loss occurrences and RTT changes. Most present schemes tend to provide TCP-equivalence, rather than just TCP-compatibility. However, TCP-equivalence in all network conditions is hard to achieve. Various studies have described schemes that achieve compatibility without always achieving equivalence [YL00, FHP00, ROY00, BBF01, LT03, VB05].

Although a TCP-equivalent scheme consumes TCP-equivalent bandwidth when working by itself, it may not coexist well with TCP in the Internet. A TCP-equivalent scheme merely ensures the same throughput between TCP and TCP-equivalent flows when both experience identical conditions, but not that when both compete for the same bottleneck, which is exactly the real situation in the Internet. Competing for the same bottleneck does not imply experiencing identical network conditions [VB05].

Therefore, this study defines a new criterion, namely TCP equal-share. This criterion is more realistic than TCP-equivalence, because the most important concern is whether flows with different controls can co-exist and equally share bandwidth in the same bottleneck while coexistence is not in the picture of TCP-equivalence. Moreover, TCP equal-share is also more challenging than TCP-equivalence because a TCP equivalent flow may not be TCP equal-share, but vice versa is true.

This study has three objectives. The first objective is to be the guide for selecting from existing TCP-friendly schemes, based on the proposed taxonomy and evaluation.

The second objective is to indicate the potential fault cases and causes of the eight schemes evaluated, thus helping designers to realize what needs to be enhanced. The third objective is to recommend policies for designing an ideal scheme to meet all TCP-friendly criteria. Unlike the survey of Widmer et al. [WDM01] which compares the functionality of various schemes, this study tests the selected schemes for the TCP-friendly criteria. Contrary to Bansal et al. [BBF01] who compare the transient behaviors of various schemes, this study additionally investigates these schemes under the steady state to reveal that they may use bandwidth unequal to TCP even in this case. Besides, this study investigates the bandwidth sharing between TCP and TCP-friendly flows (inter-fairness), differing from Tsaoussidis et al. [TZ05] who study the bandwidth sharing among a group of homogeneous flows (intra-fairness).

For TCP-friendly schemes, Table 2.1.1 summarizes the proper behaviors for the

three TCP-friendly criteria in three aspects, namely fairness, aggressiveness and responsiveness, as explained further in Chapter 2.2. Also, Table 2.1.2 shows the eight typical TCP-friendly schemes selected for this study. In Chapter 2.3, the behaviors of these schemes are classified according to their key operational characteristics to realize how they meet the three criteria. In Chapter 2.4 and 2.5, the evaluation results verify whether these schemes meet the criteria, and also reveal some further issues.

Next, related work is discussed in Chapter 2.6. Finally, we make recommendations about the preferred schemes and policies, based on the observed results, in Chapter 2.7.

Notably, although TFRCP is simply the predecessor of TFRC, it is selected in this study due to its simplicity, which may be preferred by the programmers of real-time applications. Moreover, Bansal et al. [BBF01] defined a TCP-equivalent scheme differently from this study, as a scheme with the same AIMD as TCP, but without packet loss recovery or fast retransmission.

2.2 TCP-friendliness

2.2.1 Steady state and Transient state

TABLE 2.1.1.THE PREMISES AND PROPER BEHAVIORS IN THREE CRITERIA Proper behaviors of a scheme Steady state Transient state Criterion Network

premise

Fairness Aggressiveness Responsiveness TCP-compatibility Comparable

conditions Less bw Don’t care As fast as TCP TCP-equivalence Identical

conditions TCP equal-share Same

bottleneck

Equal bw As fast as TCP

TABLE 2.1.2.THE CONTROL PARAMETERS USED IN EACH SCHEME

SCHEME FULL NAME PARAMETERS REF.

GAIMD General additive inc./multiplicative-dec. α=0.2, β=0.125 [YL00]

IIAD Inverse-inc./additive-dec. α=1.0, β=0.67, k=1, l=0 [BB01]

SQRT Square-root inc./dec. α=1.0, β=0.67, k=0.5, l=0.5 [BB01]

SIMD Square-inc./multiplicative-dec. β=0.0625, k=-0.5, l=1 [JGM03]

AIAD/H Additive inc./dec. with history β=0.25, k=0, l=0 [JGM03]

TFRCP TCP-friendly rate control protocol Interval=5 seconds [PKT99]

TFRC TCP-friendly rate control The number of samples=8 [FHP00]

TEAR TCP-emulation at receiver The number of samples=8 [ROY00]

As shown in Table 2.1.1, the term “steady-state” is used in the description of the three criteria. A steady-state network originally means that a network with a negligible change over an arbitrarily long period. By this definition, the Internet would not be in the steady-state condition unless the term “arbitrarily long” is removed from the definition. The measured result in [ZDP01] reveals that the packet loss condition experienced by an Internet flow may consist of multiple minute-scale steady-state regions, and the time interval between any two consecutive losses may be mutually independent and have the same probability distribution, i.e. be independently and identically distributed (i.i.d.), within a region. Thus, a TCP-friendly scheme should use the same bandwidth as TCP in a steady-state region, while being aggressive enough to capture the available bandwidth and being responsive enough to protect itself from congestion, as the packet loss condition changes across regions (the transient state). Notably, a packet loss (event) in this study denotes an event causing a TCP flow halving its congestion window. Such an event may imply that multiple consequent packets are discarded. For convenience, this study, like other studies [YL00, FHP00, ROY00, BBF01, LT03, VB05], ignores the term “event”.

2.2.2 TCP-friendly Criteria

This study uses the following three criteria to describe the proper behaviors of a TCP-friendly scheme. Vojnovic et al. presented a criterion, named “conservative”

[VB05]. However, this criterion is suitable only for evaluating schemes that use TCP throughput formula, and therefore is not considered herein.

1) TCP-compatibility: The basic criterion, introduced in RFC 2309 [BCC98], is defined as, “A TCP-compatible flow is responsive to congestion notification, and uses no more bandwidth in the steady state than a conformant TCP flow running under comparable conditions (e.g. packet loss rate, RTT).” As shown in Table I-A, this criterion forbids a scheme from providing a flow with more bandwidth than TCP, in order to protect TCP flows from starvation. Based on this definition, a TCP-compatible flow should decrease the throughput at least as fast as TCP when the packet loss condition becomes severe, i.e. responsive but not necessarily aggressive.

Otherwise, the compatibility criterion would be violated during the long convergence time of the flow.

2) TCP-equivalence: This study defines the criterion as, “If given identical network conditions, then a TCP-equivalent flow uses the same bandwidth as a TCP flow when the network condition is either in the steady or transient state.” This

criterion, unlike “TCP-compatibility”, requires the same bandwidth, not just “no more” bandwidth than TCP. Therefore, a TCP-equivalent scheme is more desirable for transmitting media traffic, because it provides more bandwidth than a TCP-compatible scheme. Moreover, to meet the criterion in the transient state, a TCP-equivalent scheme must consider aggressiveness besides responsiveness. That is, if more bandwidth becomes available, then a TCP-equivalent scheme should increase the throughput of its controlled flow as fast as TCP. Finally, TCP-equivalence requires

“identical network conditions”, rather than “comparable conditions”, to ensure the same patterns of packet loss occurrences and RTT changes. The requirement is necessary for testing a scheme whether to have the same throughput as TCP, because TCP has different throughputs under the same mean but different variances of loss rate or RTT [AAB05].

A TCP-equivalent scheme may work well in routers which use well-designed Active Queuing Management (AQM) algorithms to manage their bottleneck links, because such routers may offer the needed premise, namely “given identical network conditions” to TCP and TCP-equivalent flows. However, if this premise is not supported, then a TCP-equivalent flow may have more throughput than a TCP flow when the TCP-equivalent flow experiences fewer packet losses from the routers. To support the premise, these AQMs apply equal packet loss rate on flows of the same throughput, with the loss rate being directly proportional to the throughput. Since TCP and TCP-equivalent flows adjust the throughput based on their loss rates regulated by the AQM, they finally would have the same throughput and loss rate. Readers interested to this issue may refer to Gwyn et al. [CLB04].

3) TCP equal-share: This study defines the criterion as, “A TCP equal-share flow uses the same bandwidth as a TCP flow if both flows compete for the same bottleneck.” This criterion should hold regardless of whether the network conditions experienced by the two flows are identical. This criterion differs from TCP-equivalence in its premise, “competing for the same bottleneck”, which implies

“competing for the shared bandwidth resources”, but it is not necessary for TCP-equivalence.

TCP equal-share is more realistic than TCP-equivalence. A new scheme is safe to deploy if it provides the same bandwidth as TCP when competing for the same bottleneck, not just when it has identical network conditions. However, achieving TCP equal-share is more challenging than achieving TCP-equivalence, because

competing for the same bottleneck does not imply experiencing identical network conditions [ZDP01]. Therefore, a TCP-equivalent flow may not be TCP equal-share if it experiences different network conditions from a TCP flow. However, a TCP equal-share flow should have the same bandwidth as a TCP flow, regardless of network conditions, implying that it is also TCP-equivalent.

2.3 Taxonomy in Fairness, Aggressiveness, and Responsiveness

The section investigates the fairness, aggressiveness and responsiveness policies taken by the selected schemes, as summarized in Table 2.2.

2.3.1 Fairness Strategy

The fairness policy of a scheme describes how the scheme adjusts a flow to have equivalent throughput to a TCP flow in the long term under the steady state. As shown in Table 2.2, the selected schemes use two fairness policies, window-based (WB) and rate-based (RB).

The WB fairness policy controls the throughput by adjusting the congestion window (CWND). CWND represents the number of packets that can be freely sent without waiting for their acknowledgements, and is updated by a set of control

TABLE 2.2.TAXONOMY IN

FAIRNESS,AGGRESSIVENESS,RESPONSIVENESS STRATEGIES

Policy Fairness Aggressiveness Responsiveness

Aspect throughput adjusting step of each inc.

curve type life cycle of loss statistics GAIMD Window-based Non-historical Linear Variable-history

IIAD Window-based Historical Sub-linear Non-historical SQRT Window-based Historical Sub-linear Variable-history SIMD Window-based Historical Super-linear Variable-history

AIAD/H Window-based Historical Linear Non-historical

TFRCP Rate-based Non-historical Super-linear Fixed-history

TFRC Rate-based Historical Linear Fixed-history

TEAR Rate-based Historical Linear Fixed-history

parameters, see Table 2.1.2. A specific relationship exists between the parameters, giving a scheme equal throughput to the TCP. Applying this policy requires the developments of control parameters and their specific relationship. For instance, GAIMD uses two parameters, α and β, to control its CWND, increasing CWND by α for every RTT and decreasing CWND by β if a packet loss occurs. A specific relationship α=3β/(2-β) exists between α and β for achieving the same throughput as TCP. Five of the selected schemes, GAIMD, SQRT, IIAD, SIMD and AIAD/H, apply the WB policy.

The RB fairness policy directly adjusts the throughput by finely controlling the time between sending two packets and thus has a smoother rate than the WB policy.

The RB policy continues to estimate the potential throughput of a TCP flow during its lifetime and repeatedly adjusts the sending rate according to this estimated TCP throughput, enabling a flow to have equal throughput to TCP. Applying this policy requires the developments of scheme for estimating the TCP throughput and determining when to adjust the sending rate. The RB policy is applied in three schemes, TFRCP, TFRC and TEAR.

2.3.2 Aggressiveness Strategy

The aggressiveness policy of a scheme describes how the scheme increases the throughput of a flow before encountering the next packet loss. As shown in Table 2.2, the non-historical policy is taken by GAIMD and TFRCP. The step of increase is independent of the history of packet losses, and is thus fixed during the whole life of the flow. Unfortunately, this behavior brings the tradeoff between aggressiveness and smoothness. For instance, when GAIMD employs a small step for smoothness, a slow rate of increase may prohibit GAIMD from achieving either TCP-equivalence or TCP equal-share when the loss condition changes dramatically. Conversely, TFRCP doubles its rate if it does not encounter any loss during a fixed time interval, which makes it super-linear, i.e. fast and aggressive, but possibly causes large oscillation, i.e.

poor smoothness.

By contrast, the historical policy has a variable step. For example, to achieve smoothness, SIMD initially takes a smaller increasing step than TCP after encountering a packet loss. SIMD then enlarges the step according to the historical maximum CWND, to increase the aggressiveness before encountering the next loss.

The historical policy also enables AIAD/H to dynamically determine a step for

linearly increasing the throughput. AIAD/H seems to be more adaptive than GAIMD.

Three of the schemes with the historical policy, namely SQRT, IIAD and SIMD, have non-linearly increasing curves between packet losses, because they change their steps per RTT, instead of per loss. SQRT and IIAD have sub-linearly increasing curves, because they shorten the step inversely with increasing CWND and CWND, respectively. By contrast, SIMD has a super-linear behavior and thus has the fastest increasing rate because the step in SIMD is enlarged with the time escaped from the latest loss.

2.3.3 Responsiveness Strategy

The responsiveness policy of a scheme describes how the scheme decreases the throughput of a flow when the packet loss condition becomes severe. The key difference among the policies is the life cycle of the loss statistics used in adjusting the new throughput. The loss statistics include the number of inter-loss packets (the received packets between two losses), the inter-loss time, or the loss rate measured in an interval. There are three policies, namely non-historical, fixed-history and variable-history, as shown in Table 2.2.

The non-historical policy ignores the historical packet loss statistics in decreasing throughput, and thus decreases the throughput at a constant speed, thus producing a tradeoff between responsiveness and smoothness. For example, to ensure smoothness, IIAD and AIAD/H employ a small decreasing speed, leading to a long convergence time and the violation of all three criteria, particularly when a significant change of loss condition occurs.

The other two policies consider the historical packet loss statistics in order to

The other two policies consider the historical packet loss statistics in order to