I. Introduction

It has been common to play the real-time media data over the Internet, such as having video/audio conversations or watching a movie online. Since the available bandwidth in the Internet is dynamic, a congestion control mechanism is necessary to avoid the media flow suffering serious packet losses. In general, if a flow is carried over Transmission Control Protocol (TCP), it will have 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.

Nevertheless, the throughput controlled by AIMD is changed dramatically and frequently, which may not satisfy for the continuous real-time media data. For this problem, many AIMD-variant or other-style congestion control schemes are proposed [1-6]. These new schemes are suggested being TCP-friendly [7] because they are expected to coexist with TCP traffic in the Internet. The definition of “TCP-friendly” usually refers[1] to “TCP-compatible” in RFC 2309 [7], which said a TCP-compatible flow, in the steady state, should use no more bandwidth than a TCP flow under the compatible conditions such as loss ratio and Round-Trip Time (RTT).

However, users will not favor a TCP-compatible congestion control scheme if it always offers far lower throughput than a TCP flow. Therefore, a better congestion control scheme not only has to meet the TCP-compatibility, but also has to pursue the TCP-equivalence[2]. A TCP-equivalent flow has the same throughput as a TCP flow if perceiving the identical network conditions. In fact, most present schemes intend to provide TCP-equivalence, rather than TCP-compatibility. However, achieving TCP-equivalence in all network conditions is difficult. The situations that schemes achieve compatibility, but not always equivalence, could be found in [1-3]. D. Bansal and H. Balak. et al. compared TCP with General AIMD (GAIMD) [1] and TFRC [2] in their throughputs under extremely oscillatory conditions, and reported a TCP-friendly flow, due to its slow response, may get lower throughput than a TCP flow in the long run [8]. The bad TCP-equivalence in GAIMD was also addressed in [9]. Later, Vojnovic and Boudec analyzed TFRC to reveal the unfairness between TFRC and TCP, and further reported TFRC may be fair or unfair with TCP depending on the variation of inter-loss (event)[3] packets. Moreover, different network conditions may be perceived by TCP and TCP-friendly flows even when both flows competes the same bottleneck [10]. An additional criterion, TCP fair-share, is thus defined in this work for discussion. The criterion is more realistic than TCP-equivalence because we care about how fair they can co-exist while coexistence is not in the picture of TCP-equivalence. It also is more challenging because a TCP fair-share flow shall be TCP-equivalent too, but vice versa may not be true.

This work has three purposes. The first is to be the guide for selecting a TCP-friendly scheme, according to the taxonomy and evaluation. The second is to reveal the selected schemes about their potential fault cases and causes, helping designers realizing what needs to be enhanced. The third is to suggest the strategies for designing an ideal scheme to meet all TCP-friendly criteria.

For TCP-friendly schemes, Table I-A summarizes the proper behaviors stated in the three TCP-friendly criteria in three aspects: fairness, aggressiveness, and responsiveness, explained further in Section II. Also, eight classical TCP-friendly schemes are selected, as shown in Table I-B. We classify their behaviors to infer whether they meet the three criteria in Section III. In Section IV and V, the evaluation results verify the inference and also reveal some further issues. Finally, we recommend the schemes and the strategies based on the observed results.

Table I-A. The Premises and Proper Behaviors in Three Criteria Criterion Premise Proper behaviors of a scheme Steady state Transient state Fairness Aggressiveness Responsiveness TCP-compatibility Identical network conditions Less bw Don’t care As fast as TCP TCP-equivalence Equal bw As fast as TCP TCP fair-share Identical bottleneck

Table I-B. The Control Parameters used in Each Scheme Scheme Parameters GAIMD α=0.2, β=0.125 IIAD α=1.0, β=0.67, k=1, l=0 SQRT α=1.0, β=0.67, k=0.5, l=0.5 SIMD β=0.0625, k=-0.5, l=1 AIAD/H β=0.25, k=0, l=0 TFRCP Interval=5 seconds TFRC The number of samples=8 TEAR The number of samples=8