應用於終端設備以提供TCP相等性與閘道器上以排程請求回應的公平控制方法

國

立

交

通

大

學

資訊工程學系

博 士

論

文

應用於終端設備以提供 TCP 相等性

與閘道器上以排程請求回應

的公平控制方法

Fairness Controls for

TCP-Equivalence at Endpoint and

Request-Response Scheduling at Gateway

研 究 生：曹世強

指導教授：林盈達 教授

應用於終端設備以提供 TCP 相等性

與閘道器上以排程請求回應

的公平控制方法

Fairness Controls for

TCP-Equivalence at Endpoint and

Request-Response Scheduling at Gateway

研 究 生：曹世強 Student：Shih-Chiang Tsao

指導教授：林盈達 Advisor：Prof. Ying-Dar Lin

國 立 交 通 大 學

資 訊 工 程 學 系

博 士 論 文

A Dissertation Submitted to Department of Computer Science

College of Computer Science National Chiao Tung University

for the Degree of Doctor of Philosophy

in

Computer Science December 2007

Hsinchu, Taiwan, Republic of China

應用於終端設備以提供 TCP 相等性

與閘道器上以排程請求回應

的公平控制方法

學生：曹世強

指導教授：林盈達

國立交通大學資訊工程學系博士班

摘

要

window-averaging rate control (WARC)方法。藉由只考慮固定區間內的 TCP 速

度，使得 WARC 能夠更早的拋棄歷史封包遺失狀態，因而能表現出比過去方法

較好的TCP-equivalence 特性。最後，我們又提出了 minimum-service first request scheduling (MSF-RS)的方法來解決封包排程器無法在使用者端管理下載路徑的 私有公平性問題。MSF-RS 藉由排程上行路徑請求以控制下行路徑回應的方式， 來達到使用者為基礎的權重公平性，也就是無論一類別使用者數量多寡，都能確 保高等級類別使用者獲得較多的頻寬。

大量遺失四種狀態下，顯示出先前速度控制方法無法在 TCP-equivalence 情況下 維持公眾公平性的原因，而分析及模擬結果也顯示 WARC 能藉由更快的加減速 反應，來表現更好的 TCP-equivalence 及達到公眾公平性。最後分析模擬及實驗 結果顯示 MSF-RS 能在使用者閘道器上提供以使用者為基礎的私有權重公平 性，並縮短20~30%的使用者感受延遲時間。 關鍵字- TCP 友善性, 壅塞控制, 請求排程, 接取閘道器, 公平佇列

Fairness Controls for

TCP-Equivalence at Endpoint and

Request-Response Scheduling at Gateway

Student：Shih-Chiang Tsao

Advisors：Dr. Ying-Dar Lin

Department of Computer Science

National Chiao Tung University

Abstract

Flows may compete for bandwidth to transmit packets. Public fairness should be maintained by the flows when they compete for the bandwidth in the Internet, while

private fairness may be required when they do at a private access link which connects

the intranet to the Internet. To maintain the public fairness, rate control schemes different from TCP should use no more bandwidth than TCP. However, these schemes often only use less bandwidth to conservatively maintain the fairness. On the other hand, for maintaining the private fairness, the usual solution is using a packet scheduler to manage bottleneck. Nevertheless, the solution fails to manage the downlink bottleneck at the user-side access gateway, since it cannot schedule the packets queued at the ISP-side gateway, opposite to the user-side one.

This dissertation first investigates eight well-known rate control schemes to reveal why they cannot maintain the public fairness by using just the same bandwidth as TCP, i.e. being TCP-equivalent. Next, this dissertation proposes a window-averaging rate control (WARC) scheme. Considering the TCP rate only over a fixed interval leads WARC to forget the historical packet loss condition more quickly and thus perform better TCP-equivalence than other schemes. Finally, a minimum-service first request scheduling (MSF-RS) scheme is proposed to solve the private fairness problem which packet schedulers fail to manage downlink at the user-side gateway. MSF-RS schedules uplink requests to control downlink responses in order to provide user-based weighted fairness, i.e. ensure high-class users to get more bandwidth even more users belong to the high class.

The simulation results under non-periodic losses, low-multiplexing, two-state losses, and bursty-losses reveal the causes that previous schemes cannot maintain

public fairness with TCP-equivalence. Next, both analysis and simulation demonstrate that WARC does maintain the fairness and perform better TCP-equivalence by exhibiting the faster aggressive and responsive behaviors. Finally, the analysis, simulation and field trial exhibit that MSF-RS provides the user-based private weighted fairness while reducing 20~30% of user-perceived latency at the user-side gateway.

Keywords- TCP-friendly, congestion control, request scheduling, access gateway, fair

Table of Content

1 Introduction...

1.1 Bottlenecks for the Internet Traffic ...1

1.2 Public Fairness Control for TCP-Friendliness ...1

1.3 Private Fairness Control for Weighted Fairness ...2

1.4 Related Work and Potential Problems ...3

1.5 Objective, Methodology and Road Map...5

2 Taxonomy and Evaluation of TCP-friendly Congestion-Control

Schemes...

2.1 Introduction

...

2.2 TCP-Friendliness...9

2.2.1 Steady state and Transient state...9

2.2.2 TCP-friendly Criteria ...10

2.3 Taxonomy in Fairness, Aggressiveness, and Responsiveness ...12

2.3.1 Fairness Strategy ...12

2.3.2 Aggressiveness Strategy...13

2.3.3 Responsiveness Strategy ...14

2.4 Fairness Evaluation...15

2.4.1 TCP-Equivalence: Artificial-losses Testing Scenario with Identical Network Conditions ...15

2.4.2 TCP Equal-share: Low-multiplexing Testing Scenario with the Same Bottleneck...17

2.5 Evaluation on Aggressiveness and Responsiveness ...19

2.5.1 TCP-Equivalence: Two-states Artificial-losses Testing Scenario with Transient Convergence...19

2.5.2 TCP Equal-share: Bursty-loss Testing Scenario with the Same Bottleneck...21

2.6 Related Work ...23

2.7 Summary ...24

3 A Fast-Converging TCP-Equivalent Window-Averaging Rate

Control Scheme ...

3.1 Introduction ...26

3.2 Window-Averaging Rate Control (WARC)...28

3.2.1 Basic Rate-control Mechanism ...28

3.2.2 Complemental Rate-control Mechanisms ...30

3.2.3 Pseudo Code...33

3.3 Analysis on Fairness...34

3.4 Analyses on Smoothness, Aggressiveness and Responsiveness ...35

3.4.1 Smoothness...36

3.4.2 Aggressiveness ...37

3.4.3 Responsiveness...38

3.4.4 False Positive of the HR procedure...40

3.5 Simulation Results...42

3.5.1 Fairness...42

3.5.2 Smoothness...47

3.5.3 Aggressiveness and Responsiveness...48

3.6 Related Work ...51

3.8 Summary ...53

4 On Applying Fair Queuing Discipline to Schedule Requests at

Access Gateway for Downlink Differential QoS

4.1 Introduction ...54

4.2 Problems on Using Class-based Fair Queuing...56

4.2.1 The Timing for Releasing Requests ...56

4.2.2 The Determination of the Next Request...57

4.2.3 The Class-based Fairness Policy ...57

4.3 A Request Scheduling Scheme for User-side Gateway...58

4.3.1 Minimum-service Order Arbiter (MOA)...59

4.3.2 Window-based Rate Controller (WRC) ...61

4.4 Analysis for Delay and Fairness...62

4.4.1 Short User-perceived Latency...63

4.4.2 Delay Bound...65

4.4.3 Fairness...68

4.5 Simulation Results...69

4.5.1 Topology...70

4.5.2 Weighted Fairness and Bandwidth Sharing...71

4.5.3 User-perceived Latency...72

4.5.4 User-based Weighted Fairness ...73

4.5.5 Adjustment of Outstanding Responses ...74

4.5.6 Effect of U+ on Latency ...75

4.6 Affection of Exceptive Traffic...75

4.7 Field Trial ...78

4.8 Summary ...79

5 Conclusions

Appendix 1 Smoothness Level of TCP-friendly Schemes

Appendix 2 Analysis on WARC

Appendix 3 Unfairness of TFRCP and TEAR

List of Tables

2.1.1 The premises and proper behaviors in three criteria...9

2.1.2 The control parameters used in each scheme...9

2.2 Taxonomy in fairness, aggressiveness, responsiveness strategies ...12

2.3 Comparison on fairness, aggressive and responsive behaviors among schemes ...25

3.1 The control parameters used in each scheme...42

4.1 The utilization of link under oscillating CBR traffic (U+=98%) ...77

4.2 User-perceived latency comparisons ...79

List of Figures

1.1 A typical network topology of the Internet with two types of hosts...1 1.2 A tree is used to organize the related works in the dissertation ...3 1.3 A typical topology of connecting the Internet with the access link ...5 2.1 The throughputs of TCP-friendly schemes normalized with the throughput

of TCP, under the loss link whose inter-loss time has a general exponential distribution. ...16

2.2 n TCP-friendly and n TCP flows compete for the bottleneck link. The

propagation delays among each set of n flows are distributed uniformly with CV[RTT]=0~0.42...17 2.3 The comparison of the slowly convergent behaviors between TCP-friendly

schemes under the two-state loss condition...20 2.4 The slowly aggressive behaviors of TCP-friendly schemes under the

bursty-losses network...22 3.1 The HR procedure would be invoked when RTCP( ) 1N < K R t s( , ). ...31 3.2 The state diagram of the fluid-based timeout procedure in WARC...32 3.3 The pseudo code for the basic and three complemental rate control

mechanisms of WARC...34 3.4 The smoothness effects of WARC, GAIMD, and SIMD, relative to that of

TCP...37 3.5 The aggressiveness indices of WARC, SIMD, GAIMD and IIAD under

different increasing factor m’s and the tradeoff between aggressiveness and smoothness when m=4. ...38 3.6 The responsiveness of WARC under varied decreasing factor m’s. The

initial average window W before bandwidth change is 20. ...39 3.7 The responsiveness of WARC, SIMD, GAIMD and IIAD...40 3.8 The probability of the false-positive invocation of the HR procedure ...42 3.9 The artificial loss-link topology is used to provide the same loss condition

for any two flows running through the link R1-R2...43 3.10 The dumbbell topology used to test the fair sharing between TCP and

3.11 The throughputs of TCP-friendly schemes normalized with that of TCP

under different loss probabilities. ...44

3.12 The throughputs of the TCP-friendly schemes normalized with that of TCP under the artificial-loss links with different CV[T]...45

3.13 The competing results between TCP and five TCP-friendly schemes under the links managed by Drop-Tail are shown. ...46

3.14 The competing results between TCP and five schemes under the links managed by RED are shown...47

3.15 The smoothness of each scheme over different time scales...48

3.16 The topology with oscillating CBR background traffic, used to test TCP-friendly schemes in terms of aggressiveness and responsiveness...49

3.17 The comparison between five TCP-friendly schemes on aggressiveness and responsiveness under the on/off CBR background traffic ...49

3.18 The number of losses encountered by WARC, WARC without HR, and other four schemes between the 600th ~ 620th second are plotted, which are normalized with that by TCP...50

3.19 The normalized throughputs of TCP-friendly schemes under an oscillating CBR traffic...50

4.1 A typical network topology that an enterprise accesses the Internet through ISP...54

4.2 The internal architecture of MSF-RS...59

4.3 Two procedures in MOA: request selector and request receiver...61

4.4 Procedure of window-based service-rate controller (WRC)...62

4.5 The ratio on Ta of a MSF-RS gateway to an ordinary gateway ...65

4.6 The downlink can be conceptually divided into multiple sub-links. ...65

4.7 The difference of the service between Class i and Class j...69

4.8 Simulation topology for three classes with service ratio 4:2:1...70

4.9 The average throughput of three classes over the four phases...71

4.10 The average throughput of three classes over the four phases under DRR ...72

4.11 User-perceived latency comparison by decomposing time factors: queuing time and transmission time ...73 4.12 The difference on the bandwidth allocated for the high-class host between

the host-based and class-based weighted fairness. ...74 4.13 The size of W+ is fixed in the period with insufficient traffic (the 500th

~1000th seconds) ...74 4.14 The user-perceived latency, queuing time, and the number of packets

queued in ISP-side router under different U+...75 4.15 Two potential integrated architectures for handling the network when the

uplink is a bottleneck. The diamond C represents a request classifier...76 4.16 Fast-responsive W+ and full utilization of access link under oscillate CBR

traffic...77 4.17 The test bed for field trial in the Internet ...78 A1.1 The smooth level on the throughput of each scheme, relative to that of

TCP, under different levels of variant-losses condition ...83 A2.1 The increase curves of WARC, GAIMD, and TCP ...85 A3.2 The decreasing of the CWNDs and the mean CWNDs of a TCP flow when

Chapter 1

Introduction

1.1 Bottlenecks for the Internet Traffic

The Internet traffic may encounter bottleneck at any one link. Fig. 1.1 shows a common network topology to classify the positions of bottleneck links. The first position is the link between any two edge routers (ERs) within the Internet while the second position is the access link between an Intranet and the Internet. The link in the first position is shared for public and thus has traffic coming from numerous hosts. These hosts would compete for the bottleneck with uncertain hosts. For example, Host S1 will not know whether its packets for D1 are competing for the link between ISP1 and ISP2 with packets from S2 or other hosts. However, the link in the second position is only used by a group of users and has traffic for specific hosts. For example, the traffic passing through the link of G and EG would be associated with H1 ~ Hn only. Different from S1 and S2 which compete for the bandwidth of a public link, these hosts are competed for that of a private link, which is rented and managed by them.

1.2 Public Fairness Control for TCP-Friendliness

Fig. 1.1. Bottlenecks may be the links in the Internet or between the Internet and an intranet.

EDU2 ISP2 ISP₁ EDU1 ER ER ER ER S₂ S2 S1 S₁ Internet D₂ D2 D₁ D1 ER ER EG EG G G H1 H1 H_n Hn Intranet Public Fairness Private Fairness EDU2 ISP2 ISP₁ EDU1 ER ER ER ER S₂ S2 S1 S₁ Internet D₂ D2 D₁ D1 ER ER EG EG G G H1 H1 H_n Hn Intranet Public Fairness Private Fairness

no central mechanism in the Internet to keep the public fairness, i.e. to tell a host about how much bandwidth it should use in transmitting packets to avoid from starving other flows. In fact, the current public fairness of the Internet depends on using the same end-to-end rate control mechanism among all hosts. That is, the rates of most Internet traffic are controlled by the additive-increase/multiple-decrease (AIMD) embedded in TCP. AIMD increases the transmission rate per round-trip time (RTT) to detect and use the available bandwidth and then decreases the rate to avoid from the congestion when packet losses occur.

Unfortunately, the behavior of rate controlled by AIMD cannot satisfy the real-time streaming traffic, because such traffic prefers a smooth rate but the rate controlled by AIMD changes abruptly and largely. Therefore, new rate control mechanisms are required and their controlled traffic may coexist with that of AIMD in the Internet. In order to keep the public fairness of the Internet, the concept “TCP-compatibility”, i.e. TCP-friendliness, is suggested in RFC 2309 [BCC98]. The concept asks these rate control mechanisms to use no more bandwidth than TCP under the same network conditions such as loss ratio and RTT.

1.3 Private Fairness Control for Weighted

Fairness

Compared to the public bandwidth in the Internet, the bandwidth on the access link is private. If the owner of the access link has multiple hosts commonly sharing the access link, then the owner may allocate the bandwidth for each host by his or her preference policies, which is called private fairness in this dissertation. Class-based weighted fairness [FJ95, PG93] is one of the policies widely used for allocating private bandwidth. By the policy, traffic running through the access link will be classified into multiple classes and each class is assigned a weight. Then, the ratio of bandwidth of any two classes would match the ratio of their weights. The class with a large weight, i.e. the high class, can get more bandwidth than that with small weight. Besides, if the high class is idle, i.e. has no traffic for transmission, its bandwidth will be proportionally allocated for other non-idle classes.

To carry out the class-based weighted fairness policy, deploying a classifier and a scheduler at the gateway is necessary. As shown in Fig. 1.1, the access link has two gateways, the user-side gateway G and the ISP-side gateway EG. G is more preferable

by user than EG to deploy these mechanisms, because the gateway G is owned by the user renting the link and is easy to manage, while EG is owned by ISP. Moreover, if a classifier is deployed at EG, it cannot classify packets by their IP addresses because the source address of all uplink packets may be identical at EG, as well as the destination address of all downlink packets may be. For hosts in the intranet, commonly sharing a public IP address for connecting the Internet is often seen because of security concern and the short of IPv4 addresses.

1.4 Related

Work

and

Potential

Problems

Fig. 1.2 shows a tree to organize the related work of this dissertation. The dissertation focuses on the issues about bandwidth fairness and divides them into the public and private fairness. Public fairness is promoted in [FF99, BCC98], which asks the Internet traffic to be transmitted by a TCP-compatible rate control scheme. Meanwhile, in order to understand what the TCP-compatible rate is, the throughput models of TCP [PFT98, AAB05] are proposed and the network conditions in the Internet [ZDP01] are investigated. Next, to implement public fairness, many TCP-compatible rate control schemes are proposed [YL00, PHP00, ROY00, JGM03, BB01, PKT99, WDM01]. These schemes intend to control the flow to have a smoother rate while using the same bandwidth as TCP. However, several literatures reveal that these schemes may have lower bandwidth under some testing cases [BBF01, LT03, VB05]. Although such schemes still confirms to “TCP-compatibility”, they are not favorable to carry the streaming traffic because they provide less bandwidth than TCP.

Different from the public fairness which promotes each flow to use no more bandwidth than a TCP flow, the private fairness allows the differential allocations on bandwidth among the competitory flows. Class-based weighted fairness [FJ95, PG93] is such a goal and often pursued by the private fairness controls, such as WFQ [PG93], DRR [SV96], SCFQ [GOL94] and SFQ [GVC96]. Although all these schemes achieve the goal, they provide different degrees of packet latency and short-term fairness with different per-packet processing complexity. For example, DRR [SV96] is an scheduling algorithm which has O(1) complexity but a little worse degree on latency and short-term fairness. Thus, pre-order DRR is proposed in our previous work [TL01] to shorten the packet latency in DRR while retaining the O(1) complexity.

Unfortunately, all these packet-level scheduling schemes cannot allocate the downlink bandwidth at the user-side gateway. As shown in Fig. 1.3, when the downlink is the bottleneck, the inbound packets will queue at the ISP edge gateway. Thus, scheduling packets at the user-side gateway is useless since packets have passed through the bottleneck. For this problem, an idea is scheduling uplink requests to control the returned downlink responses since the Internet traffic most follows the request/response model. Request scheduling was used in several studies to provide differential Web QoS for different-classes users [CKD02]. These studies provided QoS services by designing request scheduling at a single Web server [PBB98, BBK00, CP99] or a web-side gateway, i.e. a gateway ahead close to a group of Web servers [CCC02, CC01, LGC01]. No published studies discussed how to design request

Fig. 1.2. A tree is used to organize the related work in the dissertation Bandwidth Fairness Private Fairness - Weighted Fairness [PG93] - Class-based [FJ95] Packet Scheduling -WFQ [PG93] -WRR/ DRR [SV96] -SCFQ [GOL94] -SFQ [GVC96] Pre-order DRR [TL01] Public Fairness - TCP-friendliness [FF99, BCC98] - TCP-equation [PFT98, AAB05] - Internet Conditions [ZDP01] Algorithms - GAIMD [YL00] - TFRC [FHP00] - TEAR [ROY00] - SQRT, IIAD [BB01] - SIMD [JGM03] WARC Evaluation - Survey [WDM01] - Dynamic Cond. [BBF01] - TFRC’s analysis [VB05] Taxonomy & Evaluation

Request Scheduling - Web server [PBB98, BBK00, CP99] - Server Farms [CCC02, CC01, LGC01] Minimum-service first request scheduling Bandwidth Fairness Private Fairness - Weighted Fairness [PG93] - Class-based [FJ95] Private Fairness - Weighted Fairness [PG93] - Class-based [FJ95] Packet Scheduling -WFQ [PG93] -WRR/ DRR [SV96] -SCFQ [GOL94] -SFQ [GVC96] Pre-order DRR [TL01] Public Fairness - TCP-friendliness [FF99, BCC98] - TCP-equation [PFT98, AAB05] - Internet Conditions [ZDP01] Algorithms - GAIMD [YL00] - TFRC [FHP00] - TEAR [ROY00] - SQRT, IIAD [BB01] - SIMD [JGM03] WARC Evaluation - Survey [WDM01] - Dynamic Cond. [BBF01] - TFRC’s analysis [VB05] Taxonomy & Evaluation

Request Scheduling - Web server [PBB98, BBK00, CP99] - Server Farms [CCC02, CC01, LGC01] Minimum-service first request scheduling

scheduling at the access gateway. The key difference between the previous works and this work is that the target Web servers in the former are specific and their status can be detected or controlled. The resources each request will cost could be measured in advance to assist in the scheduling mechanism. However, the servers in the latter are infinite, distributed over the Internet, and cannot be managed. It is impossible to measure the costing resources for all requests in advance.

1.5 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 G EG W1 W₂ EG EG W3 user-side access gateway H1 Hn Req. Rsp. queuing packets Internet G EG W1 W₂ EG EG W3 user-side access gateway H1 Hn Req. Rsp. queuing packets ISP-side edge gateway Internet G EG W1 W₂ EG EG W3 user-side access gateway H1 Hn Req. Rsp. queuing packets Internet G EG W1 W₂ EG EG W3 user-side access gateway H1 Hn Req. Rsp. queuing packets Internet G EG W1 W₂ EG EG W3 user-side access gateway H1 Hn Req. Rsp. queuing packets ISP-side edge gateway

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).

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

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 _bottleneck Same

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

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 decrease the throughput. In the variable-history policy, loss statistics of a large value may have a longer duration to affect the throughput than that of a small value. For example, CWND in GAIMD controls the throughput, and can be regarded as a weighted average over all historical values on inter-loss time, where the values obtained earlier have smaller weights [ABB05]. Therefore, early but large values still affect the throughput, even when their weights are small. However, schemes with fixed history only consider the latest n loss statistics when computing the new throughput. A loss statistic, regardless of its value, is eliminated from the computation if it is not among the latest n values. Fixed-history schemes include TFRC, TEAR and TFRCP.

2.4 Fairness Evaluation

We use ns-2 simulation [NS06] and examine the fairness of eight different schemes to determine whether they meet the TCP-equivalence and TCP equal-share criteria. The source codes of TEAR, TFRCP, SIMD, and AIAD are not included in the package of ns-2 simulation, but instead are published individually on the Web sites of their authors. Also, this study like [FHP00, JGM03, BB01] uses SACK [MMF96] as the TCP version and assumes no delayed acknowledgments. For the simulation, we use packets that were 1,000 bytes long and a maximum window size of 200 packets.

2.4.1 TCP-equivalence: Artificial-losses testing scenario with identical network conditions

A link with artificial packet losses was used to test for TCP-equivalence. The link discards the passing packets with a specific mathematical model. Such a link guarantees that any two passing flows experience identical loss conditions, thus satisfying the premise in TCP-equivalence, making this link suitable for the test of TCP-equivalence. Sufficient bandwidth was allocated for this link to prevent the packets from being dropped due to overflow.

The selected schemes were tested to determine whether they are robust enough to have the same throughput as TCP under varied artificial links, which have different means or Coefficient-of-Variations (CVs) of inter-loss time. The two statistics were varied because both affect the TCP throughput [AAB05]. A general exponential random variable allows its coefficient-of-variation to be changed while fixing its mean, or vice versa, so it is employed to drop packets at the link. The time between two packet losses thus forms a general exponential distribution, which is also used in [VB05] to investigate the conservativeness of TFRC. Only the testing result under links with different coefficient-of-variations is shown herein. The result with different means has already been obtained [JGM03, BB01].

The artificial link plotted as the link R1-R2 in Fig. 2.1(a), drops one packet every T seconds. T denotes a general exponential distributed random variable where E[T] is fixed at 5 and CV[T] uniformly increases from 0 to 1. The results in Fig. 2.1 were averaged from five runs of 5200 seconds each, where the data within the first 200 seconds were discarded, and the mean coefficient-of-variation of the simulation results between the five runs was 0.025. Because this coefficient-of-variation is small,

it is ignored in plot to improve the clarity of the figure.

Observation 1: Non-periodic losses should be considered in adopting WB/RB fairness policies.

Figures 2.1(b)(c) reveal that none of the WB/RB schemes meet TCP-equivalence under non-periodic packet loss (CV[T]>0). When CV[T]=1, GAIMD and TFRC only have 80% throughput of TCP while TEAR, IIAD, SQRT, and AIAD/H have 60% on average, because all schemes, except SIMD, were proposed based only on the periodic-loss assumption, i.e. the packet losses occur periodically. The unfairness under CV[T]=1 should be handled by these schemes because the inter-loss time in the Internet may approximate an i.i.d. exponential distribution equivalent to the link with

CV[T]=1, according to the observation in [ZDP01].

Notably, the TFRCP and SIMD flows exhibit a different trend from other flows in Fig. 2.1(b)(c). The difference of TFRCP is due to the convex TCP throughput equation and the fixed rate-adjusting period [VB05], while that of SIMD occurs because its specific relationship between parameters is based on the packet loss model with CV T  [JGM03]. Figures 2.1(b) also plots the curve of SIMD variant, [ ] 1 SIMD/Period, with this design based on CV[T]=0. Unfortunately, SIMD/Period violates the TCP-compatibility criterion under non-periodic conditions.

Fig. 2.1. The throughputs of TCP-friendly schemes normalized with the throughput of TCP, under the loss link whose inter-loss time has a general exponential distribution. For clarity, results are separately shown in (b) and (c).

S R1 R2 D 100Mbps 20ms 100Mbps 20ms 100Mbps 30 ms Discarding packets by math model

(a) The artificial-loss topology used in Chapter 2.4.A and 2.5.A

2.4.2 TCP equal-share: Low-multiplexing testing scenario with the same bottleneck

A dumbbell topology provides the premise of TCP equal-share, i.e. “competing for the same bottleneck,” and thus is used to verify the TCP equal-share of a scheme in the steady state. As shown in Fig. 2.2(a), n TCP-friendly flows compete with n TCP flows for a single bottlenecked link. All flows have backlogged data for the whole testing period. This study particularly investigates a low-multiplexing scenario [F00], where n is small and Drop-Tail is deployed to manage the bottleneck link, because previous results [YL00, FHP00, ROY00, BBF01, LT03] imply that a TCP-equivalent flow may violate TCP equal-share under such a scenario. Drop-Tail is a queuing management algorithm which discards new arrival packets when its managed queue is full.

To indicate the cause of the violation, the scenario used in [YL00, FHP00, ROY00, BBF01, LT03] was slightly modified at two points. First, instead of using a fixed capacity, e.g. 15 or 60 Mbps, the link had 2n Mbps. Such a link can provide on average 1Mbps of bandwidth for each flow, avoiding the influence of the TCP timeout-handling mechanism, as expected from previous studies [YL00, FHP00, ROY00, BBF01, LT03]. Second, although multiple rounds were tested for the same n,

SQRT TFRCP, TFRC, TEAR

(b) n = 8

(a) Dumbbell topology

SIMD

(c) Comparison on loss ratio Fig. 2.2. n TCP-friendly and n TCP flows compete for the bottleneck link. The propagation delays among each set of n flows are distributed uniformly with CV[RTT]=0~0.42.

IIAD GAIMD 0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 CV[RTT]=0 AVG(CV[RTT]>0.25) Lo ss ( TFC C ) / Lo ss (TC P ) SIMD GAIMD AIAD/H IIAD SQRT TFRCP TFRC TEAR R₁ S₁ S_n R₂ Drop-Tail n TCP-friendly senders 2n Mbps 10ms S’₁ S’_n n TCP senders D₁ D_n D’₁ D’_n 100 Mbps 20ms on average 100 Mbps 20ms on average R₁ S₁ S_n R₂ Drop-Tail n TCP-friendly senders 2n Mbps 10ms S’₁ S’_n n TCP senders D₁ D_n D’₁ D’_n 100 Mbps 20ms on average 100 Mbps 20ms on average

the RTT-heterogeneity of n TCP flows and of n studied flows were enlarged equally over different rounds. The RTT-heterogeneity of n flows represents the coefficient-of-variation of the RTTs of these flows, denoted as CV[RTT]. The mean end-to-end propagation delay was set to 50ms for all rounds. The queue size was 1.5 times the bandwidth-delay product.

Observation 2: RB fairness policy wins and RTT-heterogeneity matters for TCP equal-share.

Figure 2.2(b) indicates that the tested schemes do not always ensure TCP equal-share under the scenario, because they are based on the premise of TCP-equivalence, i.e. “any two flows experiencing identical network conditions,” but not that of TCP equal-share. Thus, these schemes cannot have the same throughput as TCP when the premise of TCP-equivalence is false, i.e. they do encounter different numbers of packet losses.

To show that the premise of TCP-equivalence is false under the scenario, Fig. 2.2(c) plots the normalized packet loss rate experienced by the TCP-friendly flows with the shortest RTT, compared with that of TCP flows. The loss rates of shortest-RTT flows are shown because their differences are the most significant among all flows. Three RB schemes, namely TFRCP, TFRC and TEAR, clearly suffer a higher loss rate than TCP at CV[RTT]=0, but an equal rate at CV[RTT]>0.25, which explains their bandwidth sharing with TCP in Fig. 2.2(b). Similarly, the other five schemes suffer a lower loss rate than TCP, so they occupy much more bandwidth than TCP.

Figure 2.2(b) also reveals that the RTT-heterogeneity of the competing flows significantly affects the fairness between TCP and TCP-friendly flows. GAIMD and SIMD occupy more bandwidth on average than TCP flows (1.5~4 times), particularly when CV[RTT]=0 (>10 times), where the number of competing flows is small (n=8, total is 16). The seriously unfair situation at CV[RTT]=0 also exists even when the total number of competitory flows is 64.

The unfair situation in the five WB schemes results from their exercising the packet acknowledgement mechanism. These schemes, like TCP, delay the transmission of the next data packet if the transmitter does not receive an ACK packet because the queue of a router in the transmission path has overflowed. By the delay, they encounter fewer packet losses and thus have higher throughput than the three RB

schemes. Moreover, because the overflow is alleviated by TCP significantly reducing its CWND, these five schemes, which slowly reduce their CWNDs, may monopolize the link until the queue is overflowing again. Thus, they have higher average throughput than TCP.

Although neither the WB and RB fairness policies can ensure TCP equal-share, the RB flows would experience similar packet loss rate to TCP flows, and can meet TCP equal-share in most cases, i.e. under CV[RTT]>0.05. By contrast, the WB flows may severely starve TCP flows. Therefore, the RB fairness policy should have a better chance than WB of meeting the TCP equal-share. Notably, these TCP-friendly schemes were also tested under a topology with multiple bottlenecks, but the results reveal that their TCP equal-share is unrelated to the number of bottlenecks, when this number increases from 1 to 10.

2.5 Evaluation on Aggressiveness and

Responsiveness

This section evaluates the selected schemes on their aggressive and responsive behaviors to verify whether they meet the TCP-equivalence and TCP equal-share criteria.

2.5.1 TCP-equivalence: Two-state artificial-losses testing scenario with transient convergence

The objective of the testing is to observe whether the throughput of the schemes converge as fast as TCP. An artificial-loss link was used, as in 2.4.A, because it satisfies the premise of TCP-equivalence. However, a two-state packet loss model was adopted in the link to simulate large changes in the loss conditions. A packet was dropped every 5 seconds during the 100th~800th seconds, and every 1 second at other times. The result after 100 seconds exhibits aggressive behavior, and that after 800 seconds exhibits responsive behavior. The RTT of the testing flow was about 140ms.

Observation 3: Throughput-inversed aggressive, defined below, and non-historical responsive policies are inadequate.

700 seconds to increase their throughput to the new steady throughput. Such a long time is unacceptable, particularly since the other six schemes reach steady throughput within 100 seconds. Surprisingly, although AIAD/H has a linearly increasing curve between two packet losses as mentioned earlier, it has a slower convergence than IIAD. Under this scenario, the reason that both schemes seriously violate TCP-equivalence is their slowly increasing behaviors across over multiple losses, instead of between two losses. Both schemes shorten the increasing step inversely with their throughput per loss. Herein such an unfavorable slow aggressive behavior is called a throughput-inversed aggressiveness policy.

Figure 2.3(c) and the right part of Fig. 2.3(b) verify that the non-historical

responsiveness policy does not satisfy the TCP-equivalence criterion. The policy

TFRCP SIMD TEAR SQRT GAIMD TFRC TCP IIAD SIMD GAIMD TFRCP TCP SQRT TFRC TEAR (b) AIAD/H _IIAD AIAD/H TFRCP IIAD (a) (c)

Fig. 2.3. The comparison of the slowly convergent behaviors between TCP-friendly schemes under the two-state loss condition

TCP

brings IIAD and AIAD/H longer convergence time than the other schemes. Figure 2.3(c) reveals that the fixed-history policy usually takes a shorter time to converge than the variable-history policy. TFRC, TFRCP, and TEAR take 20 seconds to converge, which is half the time of GAIMD and SIMD. However, the results also reveal that SQRT, which has a variable-history policy, also has a short convergence time. Further analysis indicates that the control parameters used in SQRT have the advantage of a short convergent time.

2.5.2 TCP equal-share: Bursty-loss testing scenario with the same bottleneck

To test whether a scheme in the transient state meets the TCP equal-share criterion, a two-state constant-bit rate (CBR) arrival traffic with obviously different rates between on and off periods was applied to the dumbbell bottleneck scenario used in Chapter 2.4.B. The oscillating CBR traffic emulates the arrival of a group of TCP flows, significantly changing the packet loss condition of the bottleneck, and thus providing the required transient-state scenarios. Such traffic in [BBF01] is used to observe how a GAIMD, TFRC, IIAD, or SQRT flow competes with a bursty arrival of TCP traffic.

Whereas Bansal et al. [BBF01] showed the statistical behavior for the selected

schemes, this study reveals their micro behavior in one on/off period. Additionally, this study tested four schemes, SIMD, AIAD/H, TFRCP, and TEAR, which were not tested in [BBF01], are included here. The bottleneck in the test was a 15Mbps link managed with Drop-Tail, where the rate of the two-state CBR traffic oscillated between two values, 14Mbps and 9Mbps, to vary the bandwidth available for the TCP-friendly flow to 1Mbps and 6Mbps, respectively. The propagation delay of flows was 60ms, and the queue size was set to 1.5 times the bandwidth-delay product [BBF01].

Observation 4: Historical/super-linearly aggressive and fixed-history responsive policies are satisfactory.

Figure 2.4(a) indicates that historical/super-linear aggressiveness is the preferred policy, because it enables SIMD to use the available bandwidth as quickly as TCP, i.e., to meet the TCP equal-share criterion, and to have a smooth rate after the convergence. By contrast, as shown in Fig. 2.4(b), the non-historical/super-linear policy of TFRCP is not recommended, because a non-historical policy does not change the increasing step to a small value after the convergence, thus causing large oscillations in TFRCP.

Notably, care should be taken when using the history. AIAD/H also uses a historical aggressiveness policy, but takes too short a history to allow a stable increase during the testing time. TFRCP and AIAD/H are not recommended because of their instability. The historical/super-linear aggressiveness policy has the fastest rate of increase, and provides both smoothness and aggressiveness, making it most likely to meet the TCP-equivalence and TCP equal-share.

Figure 2.4(c) indicates that the fixed-history responsiveness policy meets TCP equal-share in terms of responsiveness by encountering fewer packet losses than other policies. Although all schemes reduce their throughput within about 15 seconds, Fig. 2.4(c) shows that the fixed-history schemes, such as TFRC and TEAR, encounter fewer losses during convergence than variable-history schemes, such as SIMD and GAIMD. Therefore, the fixed-history responsiveness policy appears to have the best chance of meeting the three criteria, because it considers bounded statistics and thus may reach convergence with fewer packet losses or shorter time than other policies, particularly when the loss statistics change significantly.

1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8

SQRT GAIMD SIMD TFRC TEAR

N or m al iz ed lo ss r at e

Fig. 2.4. (a) and (b) The slowly aggressive behaviors of TCP-friendly schemes under the bursty-losses network. The (b) has longer timescale than (a) to show that TFRCP and AIAD/H have different behaviors in each on/off period. (c) The number of loss events encountered by TCP-friendly schemes, normalized to that by TCP, under the low-available bandwidth case.

(c) (a) (b) TCP SIMD TEAR IIAD GAIMD TFRCP AIAD/H TFRC SQRT

2.6 Related Work

Many AIMD variants have been proposed for different purposes. This study evaluates variants that aim to have a throughput smoother than but equivalent on average to TCP’s. Therefore, this study does not evaluate some schemes, e.g. AIMD-FC [LT03] and [NK04], that stress fast convergence in high-speed links. Additionally, this study focuses on the inter-fairness, i.e. whether a scheme shares the same bandwidth with TCP. Intra-fairness, i.e. the fairness among the flows controlled by the same scheme, is discussed in [TZ05,G04]. Moreover, the schemes selected herein detect congestions only by packet losses as TCP Reno and SACK [MMF96] do. Actually, the RTT variation can be used for the detection, as in TCP Vegas [BP95], which also provides a smooth rate. However, RTT-based scheme may share bandwidth unfairly in the Internet where most traffic is still controlled by loss-based versions of TCP. C. Zheng and V. Tsaoussidis [ZT06] recently proposed a scheme using both packet losses and RTTs, which may be the solution to the unfairness problem.

Although the topologies discussed have appeared in the literature, e.g. [BB01,VB05], this study revises the simulation scenarios and compares additional

schemes to reveal undiscovered phenomena. For example, this study uses a common

topology – dumbbell – to investigate the TCP equal-share of the schemes, but changes the RTT-heterogeneity to display the difference between WB and RB schemes. Tsaoussidis et al. considered the RTT-heterogeneity in [TZ05] but for the intra-fairness of GAIMD flows. Moreover, this study like [BB01] uses the oscillating CBR traffic, but includes four extra schemes to show three interesting results, i.e. SIMD has the fastest aggressiveness, AIAD/H and TFRCP are the most unstable, and TEAR has the slowest aggressiveness. Additionally, this study used the general exponential distribution, as used by Vojnovic et al. [VB05] who show that TFRC may have a lower throughput than TCP under non-periodic losses due to its design. However, this study reveals that schemes other than TFRC have the same unfairness phenomenon, although they control the throughput with methods different from TFRC.

designing a protocol for carrying streaming traffic. E. Kohler et al. [KHF06] discussed these factors in depth, and proposed the Datagram Congestion Control Protocol (DCCP). DCCP allows free selection of a congestion control scheme, and therefore is the most realistic means for practical use of schemes addressed in this study. The protocol currently only includes two schemes, namely TCP-like and TFRC. We strongly encourage the addition of other schemes to the protocol.

2.7 Summary

For a TCP-friendly congestion control scheme, meeting TCP-compatibility only protects TCP flows from starvation and network from congestion, but cannot guarantee that the media flow obtains equal throughput to TCP. A good scheme should use the same throughput as TCP in the steady state, but as aggressive and responsive as TCP in the transient state. To examine whether the present TCP-friendly schemes meet the TCP-equivalence and TCP equal-share criteria, we classify the behaviors of eight typical schemes in terms of fairness, aggressiveness, and responsiveness. Additionally, we test the conformance these schemes to the criteria under four scenarios, namely non-periodic losses, low-multiplexing, two-state losses, and bursty-losses.

Table 2.3 summarizes the evaluation result for the eight selected schemes for fairness, aggressiveness and responsiveness. A comparison of the results in this table with the taxonomy results shown in Table II demonstrates that a TCP friendly scheme may have desirable TCP-equivalence and TCP equal-share in a general network condition, if it takes the rate-based fairness, historical/super-linear aggressiveness and fixed history responsiveness policies. The evaluation results of the three recommended policies are shaded in Table 2.3, which are obviously more satisfactory than that of other policies.

Unfortunately, no scheme simultaneously takes the three recommended policies for meeting the three criteria. However, if protecting TCP flows from starvation, i.e. meeting TCP-compatibility, is the major concern, then TFRC is recommended. TFRC uses the rate-based fairness and fixed-history responsiveness policies, and therefore has better behaviors under most scenarios than others on average, as shown in the row TFRC of Table 2.3. However, if fast aggressiveness is the most important property,

SIMD is recommended, since it takes the shortest time to converge and then maintains a stable throughput, due to its historical/super-linear aggressiveness policy. Nevertheless, SIMD violates TCP-compatibility under low-multiplexing bottleneck, because of its window-based fairness policy. Moreover, SIMD spends longer time or encounters more packet losses before reducing its throughput to the available bandwidth because of its variable-historical responsiveness policy.

As a result of this study, we also observed the following: (1) a scheme should consider non-periodic loss models when taking any one of the fairness policies; (2) the RTT-heterogeneity between competitory flows influences the TCP equal-share of a scheme when the bottleneck is managed by the Drop-Tail algorithm, and (3) the throughput-inversed aggressiveness and non-historical responsiveness policies should not be taken, since they cannot adapt to the change of packet loss conditions.

Table 2.3. COMPARISON ON FAIRNESS,AGGRESSIVE AND RESPONSIVE

BEHAVIORS AMONG SCHEMES

Behavior Fairness Aggressiveness Responsiveness Criterion _(TCP-comp)TCP-eq + TCP eq-share _(TCP-comp)TCP-eq _eq-shareTCP _(TCP-comp) TCP-eq _eq-share TCP

Low-multiplexing Scenario periodic Non-

Losses Homogeneous RTTs Heterogeneous RTTs Two-state Losses Bursty Losses Two-state Losses Bursty Losses

GAIMD Δ(O) X X Δ (O) Δ Δ (Δ) Δ

IIAD X(O) Δ X X (O) X X (X) X

SQRT X(O) Δ X O (O) Δ O (O) O

SIMD Δ(O) X X O (O) O Δ (Δ) X

AIAD/H X(O) Δ X X (O) X X (X) X

TFRCP X(X) Δ O Δ (O) X O (O) O

TFRC Δ(O) Δ O Δ (O) Δ O (O) O

TEAR X(O) Δ O X (O) X O (O) O

O: satisfactory Δ: Acceptable X: Unacceptable

TCP-eq: TCP-equivalence TCP-comp: TCP-compatibility TCP eq-share: TCP equal-share

Chapter 3

A Fast-Converging TCP-Equivalent

Window-Averaging Rate Control Scheme

3.1 Introduction

TCP is a widely-used transport protocol in the Internet. Its rate control mechanism, Additive-Increase and Multiple-Decrease (AIMD), frequently and dramatically adjusts the rate to detect the available bandwidth for transmitting packets and to avoid the packets from the sequential losses. However, TCP may be unsuitable to carry the streaming data because of its oscillatory rate. The playback of streaming data will be paused, if the sending rate of TCP is lower than the encoding rate of the streaming while no streaming data is buffered at the receiver. Although allocating a large buffer may alleviate the oscillatory rate, it prolongs the start-up latency for on-demand media traffic [GTC06] and causes an intolerable delay for interactive applications, e.g. video conference. Besides, the oscillatory rate of TCP increases the difficulty for media servers to decide which encoding rate should be taken to deliver the media for a stable user-perceived quality.

For the oscillatory-rate problem, many rate control schemes were proposed [YL00, PHP00, ROY00, JGM03, BB01, PKT99] to transmit streaming data at a smooth rate. 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. A TCP-compatible scheme uses no more throughput than TCP, under the same conditions such as packet loss rate and round trip time (RTT). Based on the suggestion, a scheme using the same throughput as TCP is the most favorable for carrying media data because it conforms to TCP-compatibility with the highest throughput. Such a scheme is called as a TCP-equivalent scheme in this work.

TCP-equivalence is more preferred than TCP-compatibility, since the latter protects only TCP flows from starvation, but the former further ensures the fairness between TCP and the TCP-equivalent flows. In fact, current schemes are proposed for