ICN

CHIANTIClient

CHIANTIProxy

WirelessLink

ApplicationServer

Intermittently Connected Link

Access Link

Internet

BS

Internet

User’sApplication

Fig. 1. CHIANTI architecture

RACING: Rate Control for Enhancing Intermittent Networking Performance for Mobile Users

Haruki Izumikawa* Dirk Kutscher Andreas Timm-Giel Carsten Bormann

Universität Bremen, TZI NEC Laboratories Europe Universität Bremen, TZI Universität Bremen, TZI haruki@tzi.org Dirk.Kutscher@nw.neclab.eu atg@tzi.org cabo@tzi.org

Abstract— Internet access for highly mobile users in high-speed

trains or cars, underground walkways and tunnels is often challenged by intermittent connectivity with short and unpredictable connectivity opportunities. In such opportunistic communication scenarios, utilizing these connectivity opportunities to the best potential for the mobile user can be crucial to achieve an acceptable overall perceived service quality. When wireless access networks are shared between mobile and non-mobile TCP users, this objective can be difficult to achieve – especially considering the long-term throughput balance.

In this paper, we analyze the performance issues with current TCP implementations and propose a new rate control mechanism called RACING (Rate Control for Intermittent Networking) for increasing long-term TCP throughput for Intermittent Connectivity Nodes (ICNs) in such challenged networks. In the proposed algorithm, the sending rate is adjusted based on the expected traffic during the outage to, in a sense, compensate the ICN for the disruption. The algorithm also considers the fairness with other flows by gradually changing its algorithm closer to the original TCP according to the compensated amount. Computer simulation results show that RACING reasonably improves the performance of the ICN.

Index Terms—Delay tolerant networking, TCP, TCP friendliness, rate control∗

I. INTRODUCTION With the increasing popularity of wireless Internet services, a

variety of research and development projects aiming at always-connected, seamless communication have been moving forward [1-2]. However, providing complete coverage under all circumstances can be technically difficult to achieve: e.g., it would require to appropriately and densely install base stations (BSs), overcome indoor radio propagation issues with higher-frequency radios of current and emerging next-generation radio technologies, deal with high-speed mobility, etc.

All of this makes the BS installation process more complicated and costly. In addition, even if the BS can be densely installed, proper cell planning or power adjusting can still be non-trivial and costly. Dense BS-settings make the processes more difficult, and raises interference that may lead to capacity degradation.

As an alternative to increasing capital and operating expenditures for enhancing coverage and performance, disruption-tolerant networking appears to be a promising way to enhance user-perceived quality of service for future wireless Internet services. Technologies such as the Delay-Tolerant Networking (DTN) [3-4] as proposed by the IRTF (Internet

∗ ) on leave from KDDI, Tokyo

Research Task Force) have been applied to provide more traditional Internet services such as web access, as described in [5].

Whereas the DTN architecture has historically been associated with application scenarios with longer, potentially scheduled contact opportunities, other research activities have also addressed more short-term disruptions, e.g., the CHIANTI (Challenged Internet Access Network Technology Infrastructure) project [6] in the European 7th Framework Program. CHIANTI has been developing technologies for realizing effective, robust and cost-efficient communication services in challenging environments such as high-speed trains and cars, underground walkways and tunnels.

The CHIANTI architecture maintains compatibility with existing Internet infrastructure and applications by introducing entities with proxy function named CHIANTI client and CHIANTI proxy as shown in Fig. 1. As the wireless system between the intermittent connectivity node (ICN) and BS/AP, any technologies can be applied such as WLAN, mobile WiMAX (mWiMAX) or a cellular system (e.g., HSPA, LTE or IMT-A). The CHIANTI client operates as a proxy server from the view point of application protocols in the ICN. On the other hand, the CHIANTI proxy becomes a proxy server from the application server’s point of view. These entities conceal the disruption of the wireless link from users and applications, such as a web browser/server or an e-mail client/server. During the disruption, data destined to the ICN is buffered at the CHIANTI proxy. When the wireless link becomes available, the CHIANTI proxy starts the transmission of the buffered data to the ICN (see [6] for a detailed description of the CHIANTI architecture). In some cases, this approach could relieve network operators from completely covering the whole area by densely installing BSs.

However, because of the intermittent connectivity for the wireless access link of the ICN, the TCP performance of the ICN tends to be much lower compared to a normal node (NN) that can keep its connection on, especially from the long-term point of view. At each connectivity phase, the ICN TCP throughput will suffer from reduced sending rates, due to slow

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2009 proceedings.978-1-4244-4148-8/09/$25.00 ©2009

start and congestion avoidance. This is not surprising from a TCP perspective, but it would be desirable to improve the ICN’s performance for a better user experience in these scenarios.

In this paper, we focus on a TCP rate control mechanism called RACING (Rate Control for Intermittent Networking) that gives preference to the ICN TCP connections (without jeopardizing TCP fairness in general). RACING improves the performance of the ICN by reasonably raising the sending rate for ICN connections. We assume a CHIANTI-like architecture in which the connection is split at the proxy server such as the CHIANTI proxy positioned in the network, and also assume to install RACING in place of the existing TCP rate control algorithm implemented in the TCP stack for connections to the ICN. One objective of this approach is to avoid any further modifications to the network infrastructure such as routers, BSs and application servers.

The remainder of this paper is organized as follows. In section II, we analyze the current problem more deeply, while section III presents the design concept of RACING as well as the concrete algorithm. In section IV, we evaluate RACING using a network simulator before providing discussion in section V. We conclude the paper in section VI.

II. PROBLEM STATEMENT TCP is the transport protocol most widely used worldwide,

which also holds for mobile usage scenarios. According to a CHIANTI study [7] that analyzed real world logging data collected on wireless LAN hotspots on trains, more than 90% of the traffic were transported by TCP. TCP’s rate control inherently tries to equally share the path among other flows –which is commonly called TCP fairness [8-9].

Yet, it is not appropriate to apply the current rate control algorithm to the ICN in challenged environments, as illustrated by Fig. 2. In Fig. 2 (a), there are two mobile nodes – one (ICN) in a moving car on the highway and another (NN) in a parked car in the rest area. In the rest area, the user can connect to the Internet via the installed BS that supports WLAN, mWiMAX or high speed cellular system. Figure 2 (b) shows the expected

throughput that the two nodes obtain. Indeed, while the ICN passes through the coverage (from t1 to t2 in Fig. 2), the wireless link capacity can be fairly shared between the two nodes. However, the NN can occupy the wireless link while the ICN is out of coverage. From a long-term-perspective, it can therefore not be assumed that any fairness is achieved.

To improve the user experience in challenging environments, the performance of the ICN should be improved in a way as depicted in Fig. 2 (c), and the unfairness should be mitigated with a long-term perspective1.

III. RACING: REASONABLE RATE CONTROL FOR CHALLENGED NETWORK

RACING (Rate Control for Intermittent Networking) is an unprecedented rate control scheme for challenged networks that is intended to accommodate the intermittently connected user by allowing him to take a larger share of the bandwidth on a utilized link or path, compared to what he would be able to achieve with established TCP rate control schemes.

This based on a different notion of “fairness” compared to what global Internet congestion control schemes normally try to achieve. The fairness is traditionally defined as a “fair share per link” [8], i.e., each flow has the right to use a resource; the capacity of a bottleneck link that is equally divided among all flows. For RACING, we try to consider the disconnection history of mobile nodes in order to determine an appropriate rate increase for corresponding flows on a utilized path. The objective is to treat TCP flows of challenged users preferentially – without causing too drastic performance degradation for NN.

In general, TCP’s Additive Increase Multiplicative Decrease (AIMD) congestion control algorithm (congestion avoidance phase) is based on calculating the congestion window as follows [11]:

⎩⎨⎧

−+

=

losspacket detect if ),1(ack new receive if ,*/

2

βα

cwndMSScwndcwnd

cwnd

(1) where cwnd and MSS are the congestion window size in bytes and maximum segment size, respectively. α and β are the increase and decrease parameters, respectively. In case of TCP Reno, these parameters are set as follows: α=1, β=0.5

The proposed algorithm described in the following is inspired by the algorithm of high-speed TCP [10] that improves the performance of the high-bandwidth long-distance connections by modifying two parameters, α and β, that are respectively determined as functions of cwnd, i.e., the bigger cwnd grows, the bigger the value for α and the smaller the value for β gets. While RACING also adopts the AIMD algorithm for controlling the sending rate, RACING takes other functions to determine α and β. We derive those values dynamically to provide better throughput for challenged users where it is needed without being too aggressive in other cases.

1 Note that a very simple model was used for illustration purposes here; the lower figure in Fig. 2 does not represent any real measurements.

ICN

NN

ICN

CoverageBS

0 t1 t2

NN

Thro

ughp

ut

Elapsed time 0 t1 t2

C

C/2

Rest Area

NN

Thro

ughp

ut

Elapsed time 0 t1 t2

C

C/2

ICN

(a)

(b)

(c) Fig. 2. Current rate control problem and preferable control for ICNs

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2009 proceedings.978-1-4244-4148-8/09/$25.00 ©2009

A. Compensation metrics In this subsection, we discuss the fundamental approach for

finding suitable values for α and β for increasing the sending rate where needed. Here, the core question is: how much advantage should be given to the ICN during its connectivity phases compared to the NN? Intuitively, the ICN should be compensated for the disruption, i.e., the metrics should be related to the experienced disruptions so far.

One interesting metric to look at is queue length at the proxy server, as one might assume a correlation between the duration of disconnections and the amount of data that the proxy server could buffer from the application server. This would be the case if the capacity of all underlying links such as core, access and wireless links was the same. However, the capacity and the achievable throughput of the core network is usually much faster compared to the access network.

For example, after a HTTP request message reaches the application server, the queue length would quickly increase even if the wireless link was available. For instance, given the capacity of the core network is 1 Gbit/s and the bandwidth of access (or wireless) link is 10 Mbit/s in Fig. 1, the data can be buffered at the proxy server at speeds up to 990 Mbit/s and the queue length can rapidly grow even when the ICN is connected. For this reason, we consider queue length alone to be inappropriate as a metric.

Next, let us consider the disruption duration as the metric. This metric seems to be adequate, but in general, it is probably also not useful alone – without considering the bandwidth demand of ICNs.

Instead, it would be better to consider the intended throughput, i.e., the amount of data that could have been transmitted to the ICN without disruption – to derive useful parameters for compensation.

Therefore, in this paper, we use the expected traffic (amount of data) during the disruption as the metric for RACING. In other words, the greater the amount is, the higher rate the ICN could obtain to some extent. Let Trafrc denote the compensable traffic. Then, when the ICN is reconnected to the proxy server, Trafrc is determined and can be given by

aveoutagerc GoodputDurationTraf *= (2)

where Durationoutage and Goodputave are the disruption duration and average goodput just before this disruption. In this paper, the Goodputave is calculated by an exponential moving average method in the proxy server. After the reconnection, the segment size is subtracted from Trafrc at every successful transmission.

B. Short term fairness among existing flows It is important to find a reasonable balance between ICN and

NN uses. Obviously it would not be acceptable if the preferred treatment of ICN users caused disruption to NN users.

For example, in Fig. 2, if the ICN parks in the rest area and enjoys a sustained-higher rate, the NN could seriously suffer in low throughput. RACING clearly has to address this issue. In

this paper, RACING controls the sending rate according to the value of Trafrc. The smaller the Trafrc is, the more equally the resource can be shared with NNs. Because Trafrc decrease at every successful transmission as stated above, the short term fairness among other flows can be gradually improved after each successful transmission.

C. Proposed algorithm for RACING While RACING adopts the original TCP slow start algorithm,

it relies on a modified congestion avoidance algorithm – reflecting the above mentioned considerations. RACING therefore defines the parameters α and β as follows:

⎩⎨⎧ >=

otherwise ),(

)( if ,

rc

highrchigh

TrafA

IncTrafAIncα

(3)

⎩⎨⎧ <=

otherwise ),(

)( if ,

rc

highrchigh

TrafB

DecTrafBDecβ

(4)

where Inchigh and Dechigh are the maximum values for growing the cwnd but also and the highest factor for reducing the cwnd after a congestion event, respectively. Functions A and B of variance Trafrc are given by

)10/)1010(log

)(

+−

=

threshInc

rc

rc

Data(Traf

TrafAhigh

(5)

highthreshrchigh

rc

DecDataTrafDecTrafB

++−=

)1.0)/(*9.0log()5.0()(

(6)

where Datathresh is a threshold. Even if Trafrc exceeds the threshold, the sending rate does not increase anymore. As described above, at every successful transmission, the segment size is subtracted from Trafrc, and the values of the parameters α and β are also updated.

Figure 3 shows the variations of α and β to Trafrc given Inchigh=2, Dechigh=0.125 and Datathresh =10 Mbytes. As shown in Fig. 3, when Trafrc becomes zero even if there are still buffered packets destined to the ICN at the proxy server, the RACING rate controlling becomes totally TCP Reno-equivalent.

0 2000 4000 6000 8000 10000 12000

Remaining amount of the compensable data Traf rc KB

AlfaBeta

2.0

1.5

1.0

0.1250.25

0.5

0

2.0

1.5

1.0

0.1250.25

0.5

0Dechigh

Inchigh

αβ

αan

d β

KbytesDatathresh

Fig. 3. Variations of α and β against the remaining amount of the

compensable data. (Inchigh=2, Dechigh=0.125 and Datathresh=10 Mbytes)

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2009 proceedings.978-1-4244-4148-8/09/$25.00 ©2009

D. Enhanced TCP-friendliness Unfortunately, according to our first experimental results,

the aggressive RACING algorithm introduced above is likely to significantly affect existing flows, which may lead to unacceptable quality degradation of real-time services running on NNs. Therefore, we are adjusting the RACING algorithm to give preference to other flows, based on the following scheme:

According to the TCP Friendly Rate Control (TFRC) scheme [12] – one of the major congestion control mechanisms for real-time services – one feedback message for congestion control is transmitted from receiver host to sender host per Round Trip Time (RTT). After receiving such a feedback message, the sender host updates its local rate control parameters such as exponential moving average (EMA) of the RTT estimation. Because the smoothing factor of the EMA is recommended to be 0.1 [12], the latest value has 86%-weight for most recent 20 samples. In RACING, we therefore use a Reno-equivalent algorithm for 20 RTTs after entering the congestion avoidance phase in order to let existing flows gracefully lower their sending rates. Only after 20 RTTs, RACING switches to the more aggressive algorithm as described in the previous section. Although we know that the RTTs of the ICN flows may be different compared to the other flows, we use ICN’s RTT to count the RTT-round in this paper.

It should be noted that the RTTs for the ICN flows may differ from other flows’ RTTs – i.e., this scheme is not completely accurate, but is still provides a reasonable approximation.

IV. PERFORMANCE EVALUATION We have implemented the proposed RACING algorithm for

the ns-3 (ns-3.3) network simulator [13] and have evaluated the performance. Table I shows the parameters used in this evaluation.

A. Simulation Scenario Figure 4 shows the network topology for the simulation

scenario where two wireless nodes download files from file servers via a WLAN AP and two routers. We assume that one node is the NN and the other one is the ICN. We also assume that the file server 1 is the proxy server (e.g., a CHIANTI-proxy) that already buffers data for the ICN.

At 0.1s after starting the simulation, the NN starts downloading a 45 Mbytes file from file server 2. At the same time, the ICN starts downloading a 17.5 Mbytes file from file server 1. After the ICN has received 2.5 Mbytes of data, the

File Server1

File Server2

Router Router

Access Point

ICN

NN Fig. 4. Network topology

Fig. 5. Congestion window size and Slow start threshold in Reno scenario

Fig. 6. Enlarged figure of Fig. 5. (from 150s to 380s)

Fig. 7. Congestion window size and Slow start threshold in RACING scenario

Reno-equivalent

Reno-equivalent

Compensation process

Fig. 8. Enlarged figure of Fig. 7. (from 150s to 380s)

TABLE I: SIMULATION PARAMETERS

Parameters Value Remarks

Wired link BW [Mbit/s] 10 Wired link delay [ms] 5

Router buffer size [Kbytes] 32 Segment size [Bytes] 1412 TCP segment size TCP Sack option enable Inchigh 2 Highest increase factor Dechigh 0.125 Highest decrease factor Datathresh [Mbytes] 10 Threshold File size for ICN [Mbytes] 17.5 The file size the ICN downloads File size for NN [Mbytes] 45 The file size the NN downloads

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2009 proceedings.978-1-4244-4148-8/09/$25.00 ©2009

wireless link becomes unavailable to the ICN (phase 1). At 150.0s, the wireless link becomes available again. Then,

the ICN is reconnected to the file server 2 and resumes the download until the ICN completes the download (phase 2).

We are comparing the performance of RACING with the existing algorithm (TCP Reno) in two different scenarios. In the first scenario (Reno scenario), both servers use TCP Reno as the congestion control algorithm. In the second scenario (RACING scenario), file server 2 (accessed by the NN) adopts TCP Reno, while file server 1 (accessed by the ICN) uses RACING.

B. Simulation Results Figures from 5 to 8 show the cwnd and slow start threshold in

both scenarios. Figures 6 and 8 are the enlarged figures of Figs. 5 and 7, respectively, to observe the fluctuations in detail.

As shown in Figs. 5 and 6, the moving of cwnd for both nodes are more or less the same in both phases in the Reno scenario. In the RACING scenario, the moving of cwnd for the ICN is very different from the one for the NN in the phase 2 while the both moving are close enough in the phase 1. Let us observe the result of the RACING scenario in more detail.

In the phase 1, file server 1 is using the Reno-equivalent algorithm because this was the first communication with the ICN, and Trafrc was zero. The phase 1 ends at 32.6s and the

average goodput of the ICN is 744.0 Kbit/s. At 150.0s, when the ICN is reconnected to the server, the

server calculates Trafrc using (2) and obtains Trafrc =10.9 Mbytes. At 152.6s, the first congestion avoidance occurs for the ICN in the phase 2. At this time, the average RTT is 245.3 ms. Therefore, file server 1 uses the Reno-equivalent algorithm again until 157.5s (= 152.6 + 20 RTT). After that, the rate is controlled according to (1) – (6). Here, at first, since Trafrc is greater than Trafthresh, Inchigh and Dechigh are used for obtaining α and β, respectively. As the transmitted traffic increases, i.e., as Trafrc decreases, the sending rate gradually decreased as well based on Fig. 3 as shown in Figs. 7 and 8.

Finally at 254.4s, the compensation is completed, i.e., 10.9 Mbytes of traffic were transmitted, and the rate control algorithm became Reno-equivalent again.

Figures from 9 to 12 show the goodput in both scenarios. As shown in Fig. 12, after the compensation, the network resource can be fairly shared between both nodes in the RACING scenario. Table II shows the specific goodput values. In the table, “end of compensation” indicates the time when the Trafrc traffic has been successfully transmitted; i.e., 254.4s in this simulation.

From the table, we can also see that the ICN can obtain the higher sending rate and thus make up for the disruption in addition to sharing the resource equally with the NN after the

Fig. 11. Goodput in RACING scenario

Fig. 12. Enlarged figure of Fig. 10. (from 150s to 380s)

Fig. 9. Goodput in Reno scenario

Fig. 10. Enlarged figure of Fig. 9. (from 150s to 380s)

TABLE II: SIMULATION RESULTS

Scenario Nodes Average goodput at phase 2 [Kbit/s]

Average goodput (150s-end of compensation)

[Kbit/s]

Average goodput (end of compensation-last)

[Kbit/s]

Download time of ICN at phase 2 [s]

Reno NN (Reno) 673.7 n/a n/a n/a ICN (Reno) 545.7 n/a n/a 219.9

RACING NN (Reno) 457.0 351.9 650.3 n/a ICN (RACING) 743.8 836.4 574.6 161.3

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2009 proceedings.978-1-4244-4148-8/09/$25.00 ©2009

compensation. Figure 13 shows the fluctuation of the Trafrc. Until Trafrc

reaches 10 Mbytes (= Datathresh), the values of α and β are set to 2 and 0.125, respectively, except for the first 20 RTT period. After the variance falls below 10 Mbytes, α and β are calculated based on the (5) and (6).

V. DISCUSSION In this section, we briefly discuss the influence of some

parameters introduced in Sec. III. From (1) and [14], the elapsed time Trnd of single congestion

avoidance round is obtained by calculating:

RTTwTrnd **αβ= (7)

where w is cwnd when a packet loss occurs. We can also calculate the amount of transmitted packets Txrnd in a single congestion avoidance round as follows:

2

2)2( wTxrnd α

ββ −= (8)

Therefore, from (7) and (8), the estimated traffic rate R can be calculated as follows:

pRTTR

*2)2(1

ββα −= (9)

where p is the ratio of the packet losses. In the simulation, we adopted values of 2 and 0.125 for the highest increase and decrease parameters, respectively, so the sending rate of a RACING flow compared to a TCP Reno flow is at most 10 times higher. Figure 14 shows the proportion of the traffic rate of RACING to TCP Reno. Since the traffic rate can be controlled based on Trafrc, if there is more than one ICN with different Trafrc, the transmission opportunity can be reasonably allocated to ICNs according to the value of respective Trafrc. Note that service providers using RACING can adjust the maximum transmission ratio to the existing protocol by changing the parameters Inchigh and Dechigh according to their policies. Furthermore, if they want to restrict the compensable traffic, it can be realized to set the maximum value of Trafrc by Datathresh.

VI. CONCLUSION In this paper, we propose a novel perspective on resource

sharing in challenging network environments. The RACING rate control algorithm allows determining the sending rate based on the expected throughput during disruption times.

While we focus on the downlink direction from the proxy server to the ICN in this paper, the role of the proxy server and the ICN should be swapped for the uplink direction from the ICN to the proxy server, i.e., the rate control can be easily realized in the uplink direction if the ICN adopts RACING as its congestion control algorithm. Furthermore, if an application server installs RACING, the proxy server is not needed any more.

This paper has just presented the results of the simple topology in the simulation, which allowed us to provide the initial evaluation of RACING. As future work, we plan to evaluate RACING with multi-terminal environments and observe whether RACING would have the danger of congestion collapse especially in environments with heavy congestion. In addition, we will implement and run RACING in real-world environments and asses the performance increase as well as the effect on NN flows in different scenarios.

REFERENCES [1] E. Gustafsson and A. Jonsson, “Always Best Connected,” IEEE Wireless

Communications, Vol. 10, No. 1, Feb. 2003. [2] H. Izumikawa, et al., “User-centric Seamless Handover Scheme for

Real-time Applications in Heterogeneous Networks,” IEICE Trans. Commun., vol.E92-B, No. 3, Mar. 2009.

[3] K. Fall, “A Delay-Tolerant Network Architecture for Challenged Internets,” in Proc. of ACM SIGCOMM 2003, Aug. 2003.

[4] V. Cerf, et al., “Delay-Tolerant Networking Architecture,” IETF, RFC 4838, Apr. 2007.

[5] J. Ott and D. Kutscher, “Applying DTN to Mobile Internet Access: An Experiment with HTTP,” Tech. Repo. TR-TZI-050701, University of Bremen, Jul. 2005.

[6] “CHIANTI project,” http://www.chianti-ict.org/ [7] N. Seifert, “Operational and User Requirements,” CHIANTI D1.2, Jun.

2008. [8] T. R. Henderson, et al., “On improving the fairness of TCP congestion

avoidance,” in Proc. of IEEE GLOBECOM 98, Nov. 1998. [9] E. Altman, et al., “Fairness in MIMD congestion control algorithms,” in

Proc. of IEEE INFOCOM 2005, Mar. 2005. [10] S. Floyd, “HighSpeed TCP for Large Congestion Window,” IETF, RFC

3649, Dec. 2003. [11] K. Hyogon, et al., “Reducing TCP response time in face of wireless uplik

losses,” IEEE VTC 2001, Oct. 2001. [12] M. Handley, et al., “TCP Friendly Rate Control (TFRC): Protocol

Specification,” IETF RFC 3448, Jan. 2003. [13] The ns-3 network simulator, http://www.nsnam.org/ [14] S. Floyd and K. Fall, “Promoting the Use of End-to-End Congestion

Control in the Internet,” IEEE/ACM Trans. on Networking, Aug. 1999.

0

0.5

1

1.5

2

2.5

3

3.5

0 2000 4000 6000 8000 10000 12000

Remaining amount of the compensable data Traf rc Kbytes

Prop

ortio

n of

the

traff

ic ra

te o

f RA

CIN

Gto

TCP

Ren

o

Fig. 14. Proportion of the traffic rate of RACING to TCP Reno

0

2000

4000

6000

8000

10000

12000

150 200 250 300 350

Elapsed time s

Rem

aini

ng a

mou

nt o

f the

com

pens

able

dat

a Tra

f rc K

byte

s

Fig. 13. Fluctuation of the variance Trafrc

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2009 proceedings.978-1-4244-4148-8/09/$25.00 ©2009