Seventh International Conference on Networking

A transport-layer approach for achieving predictablethroughput for Internet applications
Go Hasegawa, Kana Yamanegi and Masayuki Murata
Graduate School of Information Science and Technology, Osaka University
1-3, Yamadaoka, Suita, Osaka 560-0871, JAPAN
Email: hasegawa@cmc.osaka-u.ac.jp

Abstract—We propose a transport-layer approach to provide
predictable throughput for applications requiring stable bandwidth resource, such as video streaming and VoIP. The proposedmechanism deploys an end-to-end approach: it dynamicallysets the increase degree of the congestion window size of a
TCP connection according to the measurement results of theavailable bandwidth of the network path, which is obtained byinline network measurement technique developed in our researchgroup. In the present paper, we briefly introduce the proposedmechanism and show the performance evaluation results in theexperimental network and in the commercial Internet environment. We exhibit that the proposed mechanism can achieve therequired throughput with high probability without any support
from intermediate network nodes.
Index Terms—TCP, predictable throughput, end-to-end, bandwidth measurement

I. I NTRODUCTION
The Internet users’ demands for network quality has increased due to services becoming progressively diversified
and sophisticated because of the remarkable degree to which
the Internet has grown, which is due in part to access andbackbone network technologies. Applications involving realtime media delivery services, such as VoIP, video streaming
and TV meeting systems, all of which have experienced a dramatic level of development, require large and stable amountsof network resources in order to maintain the Quality ofService (QoS). For example, the quality of real-time streaming
delivery applications is highly dependent on propagation delay
and delay jitter. The available bandwidth on the end-to-end
network path is also an important factor in order to smoothly
provide rich contents, including voice and video.
Most of such video streaming applications use User Datagram Protocol (UDP) as a transport-layer protocol, and theupper-layer application controls the data transmission rateaccording to the network condition [1]. However, these mechanisms have a large cost when modifying the application
program for achieving application-specific QoS requirements,
and the parameter settings are very sensitive to various network
factors. Furthermore, when such applications co-exist in the
network and share the network bottleneck resources, we cannot
estimate the performance of the network or that of the applications, because the control mechanisms of such applications aredesigned and implemented independently, without considering
the effect of interactions with other applications.
Against the above problem, we propose a transport-layer
approach for achieving predictable throughput. By predictablethroughput, we mean the throughput required by an upperlayer application, which can be provided with high probability
when the network congestion level is not extremely high. We
modify the degree of the increase of the congestion window

978-0-7695-3106-9/08 $25.00 © 2008 IEEE
DOI 10.1109/ICN.2008.30

size of a TCP connection in the congestion avoidance phase byusing the information on the available bandwidth of the network path obtained by Inline Measurement TCP (ImTCP) [2],which has been previously proposed by our research group.
The application examples of the proposed mechanism include
TCP-based video or voice delivery services, such as Windows
Media Player [3], RealOne Player [4], and Skype [5]. In [6],we have investigated the fundamental characteristics of the
proposed mechanism through simulation experiments, andconfirmed that the proposed mechanism can achieve a TCP
throughput of 10-20% of the bottleneck link capacity, evenwhen the link is highly congested and there is little residual
bandwidth for the TCP connection.
In this paper, we briefly summarize the proposed mechanismand discuss implementation issues of the proposed mechanism.
Furthermore, we show the performance evaluation results
through the implementation experiments on the experimental networks, and on the commercial Internet environment
between Tokyo and Osaka in Japan. From these results, we
confirm that the proposed mechanism can achieve the required
throughput with high probability in an actual network, asin the simulation results. We also evaluate the importanceof bandwidth measurement for the proposed mechanism toconfirm the effectiveness of the network resource monitoringfor providing higher-level QoS.
II. P ROPOSED MECHANISMS
Figure 1 shows an overview of the proposed mechanism. We
assume that an upper-layer application sends bw (packets/sec)
and t (sec) to the proposed mechanism, which is locatedat transport layer. This means that the application requires
average throughput bw at every interval of t sec in TCP datatransmission, and the proposed mechanism tries to achieve thisdemand. Note that by implementing the proposed mechanism,
we also need to modify the socket interface to pass thevalue of required throughput from the upper-layer application
to TCP. Here, bw is the required throughput and the timeinterval is referred to as the evaluation slot, as shown in
Figure 1. We change the degree of increase of the congestion
window size of a TCP connection to achieve a throughputof bw every t sec. Note that in the slow start phase, we
use a mechanism that is identical to the original TCP Reno,i.e., the proposed mechanism changes the behavior of TCP
only in the congestion avoidance phase. By minimizing thedegree of modification of TCP source code, we expect thatthe original property of the congestion control mechanism
can be preserved. We can also reduce the introduction of
implementation bugs by basing on the existing TCP source
code.
Since the proposed mechanism changes its behavior in unitsof the Round Trip Time (RTT) of the connection, we introduce

186

APP

properties of TCP. This means that the degree of the congestion
window size is increased only in the congestion avoidancephase of a TCP connection. This does not modify the TCP
behavior in the slow start phase or when a TCP connection
experiences packet loss(es).
In the proposed mechanism, the sender TCP updates its
congestion window size cwnd in the congestion avoidancephase according to the following equation when it receives an
ACK packet from the receiver TCP:bw [packets/sec] throughput
at every t sec

bw , tTCP

in TCP data transmission
with proposed mechanism

Evaluation slot
CWND
0Throughput
bw
0t

Fig. 1.

Sender host2t

3t

Receiver host

Time

k
(1)
cwnd
where k is the control parameter. From the above equation, we
expect that the congestion window size increases by k packets
in every RTT. The main function of the proposed mechanism isto regulate k dynamically and adaptively, whereas the original
TCP Reno uses a fixed value of k = 1. In the rest of thissubsection, we explain how to change k according to the
network condition and the current throughput of the TCP
connection.
1) Increasing the degree of the congestion window size:
Here, we derive kjbw , which is an ideal value for the degreeof increase of the congestion window size when the j-th
ACK packet is received from the beginning of the i-th control
slot, so that the TCP connection achieves gi of the averagethroughput. For achieving the average throughput gi in the ith control slot, we need to transmit (gi · srtti · s) packets in(s · srtti ) sec. However, since it takes one RTT to receive the
ACK packet corresponding to the transmitted packet, and since
it takes at least one RTT to detect packet loss and retransmit
the lost packet, we intend to transmit (gi · s · srtti ) packets in((s − 2) · srtti ) sec.
We assume that the sender TCP receives the j-th ACK
packet at the nj -th RTT from the beginning of the control
slot, and the congestion window size at that time is cwndnj .
Since the congestion window size increases by k packets every
RTT, we can calculate psnd , the number of packets that would
be transmitted if we use kjbw for k in Equation (1) in the restof the control slot, the length of which is (s − 2 − nj ) · srtti
sec:
cwnd ← cwnd +Overview of the proposed mechanism

a variable e as t = e · rtt, where rtt is the RTT value of the
TCP connection.
In what follows, we first introduce the calculation methodof target throughput in each evaluation slot in Subsection II-A
and propose an algorithm to achieve the required throughput
in Subsection II-B.
A. Calculating target throughput
We split an evaluation slot into multiple sub-slots, called
control slots, to control the TCP behavior in a finer-grained
time period. The length of the control slot is s (RTT), where sis 2 ≤ s ≤ e. We set the throughput value we intend to achieve
in a control slot, which is referred to as the target throughputof the control slot. We change the target throughput in every
control slot and regulate the packet transmission speed in orderto achieve the target throughput. The final goal is to make theaverage throughput in the evaluation slot larger than or equal
to bw, the required throughput.
We use the smoothed RTT (sRTT) value of the TCP
connection to determine the lengths of the evaluation slot andthe control slot. That is, we set the length of the i-th control
slot to s · srtti , where srtti is the sRTT value at the beginningof the i-th control slot. At the end of each control slot, we
calculate the achieved throughput of the TCP connection by
dividing the number of successfully transmitted packets in thecontrol slot by the length of the control slot. We then set thetarget throughput of the i-th control slot, gi (packets/sec), as
follows:
gi = bw + (gi−1 − tputi−1 )g0 = bw
where tputi (packets/sec) is the average throughput of the i-thcontrol slot. This equation means that the target throughput of
the i-th control slot is determined according to the difference
between the target throughput and the achieved throughput inthe (i − 1)-th control slot.
B. Achieving the target throughput by changing the congestion
window size
Although it may seem that one simple method by whichto achieve the target throughput by TCP would be to fix thecongestion window size to the product of the target throughput
and RTT and to keep the window size even when packet losses
occur in the network, such a straightforward method would
introduce several problems in the network congestion that
could not be resolved. In addition, such a method would result
in severe unfairness with respect to co-existing connections
using the original TCP Reno. Therefore, in the proposedmechanism, the degree of modification of the TCP congestion
control mechanism is minimal in order to maintain the original

kjbw(s − nj − 1)(s − nj )2
On the other hand, pneed , i.e., the number of packets thatshould be transmitted in order to obtain gi , is calculated asfollows:
pneed = gi · srtti · s − aj
psnd = (s − nj − 1)cwndnj +where aj is the number of transmitted packets from the
beginning of the control slot to when j-th ACK packet isreceived. Then, we can calculate kjbw by solving the equation
psnd = pneed for kjbw ;kjbw =

2{gi · srtti · s − aj − (s − nj − 1)cwndnj }(s − nj − 1)(s − nj )(2)

In the proposed mechanism, we use the above equation to
update k for Equation (1) when the sender TCP receives a
new ACK packet.
2) Limitation of the increasing degree based on the available bandwidth: By using Equation (2) for determining k, thedegree of increase of the congestion window size becomes toolarge when the current throughput of a TCP connection is far
below the target throughput. Values of k that are too large
would cause bursty packet losses in the network, resulting187

in a performance degradation due to retransmission timeouts.
On the other hand, when the network has sufficient residual
bandwidth, the degree of increase of the congestion window
size in Equation (2) becomes smaller than 1. This results in alower throughput increase than TCP Reno. Therefore, we limit
the maximum and minimum values for k, which are denotedby kmax and kmin , respectively. We simply set kmin = 1
to preserve the basic characteristics of TCP Reno. However,some applications, including transferring sensing observation
data and monitoring log on a system, generate data at aconstant rate and does not require higher throughput than thedesignated one even when the network has enough bandwidth.
For such applications we do not set kmin , meaning that the
proposed mechanism does not achieve more than the required
throughput even if the residual bandwidth is more than therequired throughput.
kmax , on the other hand, should be set such that bursty
packet losses are not invoked, whereas the target throughput
should be obtained. Thus, we decide kmax according to thefollowing considerations. First, when the proposed mechanism
has obtained the target throughput in all of the control slots
in the present evaluation slot, we determine that the available
bandwidth of the network path would be sufficient to obtainthe target throughput of the next control slot. Therefore, we
calculate kmax so as to avoid packet losses by using the information of the available bandwidth of the network path. Here,the information about the available bandwidth of the network
path is estimated by ImTCP [7], which is the mechanism of
inline network measurement. ImTCP measures the available
bandwidth of the network path between sender and receiver
hosts. In TCP data transfer, the sender host transfers a data
packet and the receiver host replies to the data packet with an
ACK packet. ImTCP measures the available bandwidth using
this mechanism, that is, ImTCP adjusts the sending interval ofdata packets according to the measurement algorithm and thencalculates the available bandwidth by observing the change of
ACK arrival intervals. Because ImTCP estimates the available
bandwidth of the network path from data and ACK packets
transmitted by an active TCP connection in an inline fashion,
ImTCP does not inject extra traffic into the network. ImTCP
is described in detail in [7].
Next, when the proposed mechanism has not obtained thetarget throughput in the previous control slot, the proposedmechanism will not obtain the target throughput in the following control slots. We then set kmax so as to obtain alarger throughput than the available bandwidth of the network
path. This means that the proposed mechanism would steal
bandwidth from competing flows in the network in order toachieve the required bandwidth by the upper-layer application.
In summary, the proposed mechanism updates kmax byusing the following equation when the sender TCP receives
a new ACK packet:
A · srtti − cwnd
(∀x{(1 ≤ x < i) ∨ (tputx < gx )}) (3)kmax =min(A+(g
i − tputi−1 ), P ) · srtti − cwnd
(∃x{(1 ≤ x < i) ∧ (tputx < gx )}) (4)where A and P (packets/sec) are the current values for theavailable bandwidth and physical capacity as measured by
ImTCP. In Equation (3), A · srtti indicates the maximum
number of packets that the proposed mechanism can occupy
within the network capacity without occurring packet losses.
In Equation (4), (gi − tputi−1 ) · srtti indicates the number ofpackets required in order to obtain the target throughput when

Applicationdata

parameters (bw, e)

TCP Layer

tcp_input ()cwnd

tcp_output ()proposedmechanism
available ImTCP
bandwidth

IP LayerFig. 2.

Outline of implementation architecture

the network has insufficient available bandwidth.
III. I MPLEMENTATION
Figure 2 shows the architecture of the proposed mechanism
implemented in Linux 2.6.16.21 kernel system. When new
data is generated at the application, the data is passed to
the TCP layer through the socket interface [8]. The data ispassed to the IP layer after TCP protocol processing by the
tcp_output() function and the resulting IP packets are
injected into the network. On the other hand, an ACK packet
that arrives at the IP layer of the sender host is passed to the
tcp_input() function for TCP protocol processing. The
congestion window size of a TCP connection is updated whenan ACK packet is passed to the tcp_input() function.
Therefore, the control program for congestion window sizefor the proposed mechanism should be implemented in the
tcp_input() function. Linux 2.6.16 kernel system unifies
the interfaces for congestion control mechanisms, and enables
to implement congestion control algorithm as a module. In thispaper, we implement the proposed mechanism as a module inLinux 2.6.16.21 kernel system.
The tcp_input() function calls the cong_avoid()function and updates the congestion window size when an
ACK packet arrives. The module for the proposed mechanism determines the congestion window size according to
its algorithm described in Section 2, and splits time into
evaluation/control slot in the cong_avoid() function. On
the other hand, ImTCP, which we utilize to obtain the available bandwidth of the network path, calculates the available
bandwidth in the tcp_input() function [9]. The proposedmechanism inquires ImTCP for the available bandwidth in the
cong_avoid() function, and changes the degree of increaseof the congestion window size based on the value.
Figure 3 shows the flow chart of the cong_avoid() function of the proposed mechanism. First, the cong_avoid()function compares the congestion window size (cwnd) andthe slow start threshold (ssthresh). When cwnd is smaller
than ssthresh, the congestion window size is updated by
the slow start algorithm as TCP Reno. On the other hand,when cwnd is larger than ssthresh, the congestion window
size is determined based on the algorithm of the proposedmechanism. In the congestion avoidance phase, the proposedmechanism checks the passed time from the beginning of
the present evaluation/control slots and judges the end of theslots. When the passed time is longer than the length of theevaluation/control slots, the proposed mechanism calculates
the average throughput in the slot and initializes the variables
for the next slots. Next, the increase degree of the congestion
window size is the determined on consideration of kmax ,188

TABLE I
PC SPECIFICATIONS OF THE EXPERIMENTAL NETWORK ENVIRONMENT

cong_avoid ()cwnd > ssthresh ?
yesCPUMemoryKernelset evaluation/control slot

slow startcalculate kbw

nonokbw < kmax ?
yes
k=1

k=kbw

cwnd

k=kmax← cwnd + k/cwnd
finishFig. 3.

traffic generator1
Pentium 4 1.7GHz
2048 MBLinux 2.6.16.21

receiver1
Xeon 2.80GHz
2048 MBLinux 2.6.16.21

kbw < 1 || kmax < 1 ?

Congestion window size [packets]

yes

sender1
Pentium 4 1.90GHz
1024 MBLinux 2.6.16.21

Flow chart of the cong_avoid() function

cwnd
length of control slot

400

32

300
200

16

100

8
4
2

0
0

10

20

30
40
Time [sec]5060(a) Changes in window size and control slot
lengthsender1

100

100 Mbps
Ethernet
30 msec

Throughput [Mbps]

PC Router
Buffer: 100packet

500
Length of slot [RTT]no100 Mbps
Ethernetreceiver1

bw= 20Mbps
av-throughput

80
60
40
20
0
0

traffic_generator1
Proposed mechanism
TCP Reno

Fig. 4.

10

20

30
40
Time [sec]5060(b) Changes in throughput
Fig. 5.
Changes in cwnd, control slot length and throughput in theexperimental network

Experimental network environment

kmin and kjbw , which is calculated according to Equation (2).
Finally, cwnd is updated by Equation (1).
IV. E XPERIMENTAL R ESULTS
A. Performance evaluations using an experimental network
We first evaluate the proposed mechanism in an experimental network. Figure 4 shows the experimental network
environment. This network environment consists of a PC
router in which Dummynet [10] is installed, an endhost thatgenerates cross traffic (traffic generator1), an endhost thatuses the proposed mechanism (sender1), and an endhost thatreceives packets from each endhost (receiver1). All endhosts
and the PC router are connected by a 100-Mbps Ethernet
networks. We configured the Dummynet setting so that theminimum RTT between the sender1 and the receiver1 becomes
30 msec. Table I shows the specifications of the endhosts ofthe experimental network environment.
In this experiment, we set e = 32 for the length ofevaluation slot, and s, the length of control slot, is initialized
to 16. The cross traffic is generated by traffic generator1, andsends the packets to receiver1. We set the size of TCP socket
buffer on traffic generator1 to limit the maximum throughput
of each TCP Reno connection to approximately 4 Mbps, andthe amount of the cross traffic is changed by the number of
the TCP Reno connections. The value of HZ at the sender host(sender) is set to 20,000.
1) Changes in congestion window size and throughput:
In this section, we evaluate the behavior of the proposedmechanism against the changes in the amount of cross traffic.
In this experiment, we use one connection using the proposedmechanism, and set bw to 20 (Mbps), which is equal to 20%

189

of the bottleneck link capacity. To change the congestion
level of the network, we change the number of TCP Reno
connections between traffic generator1 and receiver1 to 5, 25
and 40 in every 20 seconds. Figure 5(a) shows the changes
in the congestion window size and the length of control slot,
and Figure 5(b) shows the changes in the average throughput
in each evaluation slot.
The results for 0-20 seconds shown in Figures 5(a) and5(b) show that when five TCP Reno connections co-exist witha TCP connection of the proposed mechanism, the proposedmechanism can obtain the required throughput by keeping
the same behavior as the normal TCP connection (k = 1
in Equation (1)). In this period, the available bandwidth issufficiently large to obtain the required throughput, because
there are only five connections, each of whose maximum
throughput is limited to 4 Mbps, in the network that have 100
Mbps capacity. Thus, the proposed mechanism sets k = kmin(=1).
The results for 20-40 seconds, in which case there are
25 TCP Reno connections, we observe that the proposedmechanism has a faster increase in the congestion window
size than that in 0-20 seconds. This is because it is impossible
to obtain the required throughput with the identical behavior
to TCP Reno, due to the increase of the amount of competing
traffic. Consequently, the proposed mechanism changes thedegree of increase of the congestion window size in orderto achieve the required throughput.
Furthermore, the results after 40 seconds with competing
40 TCP Reno connections show that the congestion window
size of the proposed mechanism increases faster than thatof previous cases, and that the length of control slot, s, ischanged to a smaller value. This result indicates that the pro-

100

Internet
17 msec

Probability [%]80

optical network
service

100 Mbps
Ethernet

60

100 Mbps
Ethernet

40

20

sender2

bw: 10Mbps
bw: 20Mbps

traffic_generator2

0
0

5

10

15

20

25

30

35

40

45

50

OSAKA, JAPAN

Number of co-existing TCP Reno connections

Fig. 6.

receiver2

TOKYO, JAPANProposed mechanism
TCP Reno

Ratio of evaluation slot required throughput achieved
Fig. 8.

1

Cumulative distribution

0.8

Experimental system with the Internet environment

TABLE IIPC SPECIFICATIONS OF THE I NTERNET ENVIRONMENT

0.6

0.4

0.2

CPU
MemoryKernel(10, 30)(10, 50)(20, 30)(20, 50)

sender2
Pentium 4 3.40GHz
1024 MBLinux 2.6.16.21

traffic generator2
Xeon 3.60GHz
2048 MBLinux 2.6.17

receiver2
Xeon 2.66GHz
1024 MBLinux 2.4.21

035

Fig. 7.

30

25

20
15
Throughput [Mbps]

10

5

0

Cumulative distribution function of throughput

posed mechanism controls its congestion window size with asmaller length of the control slot to obtain required throughput
because sufficient throughput cannot be achieved by merely
changing the degree of increase of the congestion window
size. As a result, the proposed mechanism can obtain therequired throughput even when there are 40 competing TCP
Reno connections. Thus, we have confirmed that the proposedmechanism can effectively obtain the required throughput bychanging the degree of increase of the congestion window size
and the length of the control slot according to the network
congestion level in the experimental network environment.
2) Probabilities of obtaining required throughput: We next
show the relationship between the performance of the proposed mechanism and the number of co-existing TCP Reno
connections in more detail. We set bw = 10, 20 (Mbps),
and use one connection for the proposed mechanism in the
network. Figure 6 shows the ratio of the number of evaluation
slots in which the proposed mechanism obtains the required
throughput to the total number of evaluation slots.
Figure 6 indicates that the proposed mechanism can obtain
the required throughput with high probability even when theconnections co-exist in the network. This result is quite similar
to the simulation result described in Subsection 3.1. However,
the ratio in which the proposed mechanism can achieve therequired throughput decreases when bw is 20 Mbps and thenumber of TCP Reno connection is 25. In this case, theproposed mechanism cannot set the length of control slot to its
appropriate value according to the congestion level, because
the length of control slot drastically changes by doubled
or halved, as described in Subsection 2.2.3. Thus, the ratio
in which the proposed mechanism can achieve the required
throughput decreases due to the frequent changes in the lengthof control slot. Against this problem, we plan to improve thecontrol algorithm of the length of control slot as a future work.
We next show the cumulative distribution function of theaverage throughput in each evaluation slot (Figure 7), when
we set bw to 10 and 20 Mbps and the number of the TCP
Reno connections to 30 and 50. We observe from Figure 7
that when the number of co-existing TCP Reno connections
is 30, approximately 80 % of the evaluation slots can achieve

190

more than the required throughput, and the rest of them canachieve the throughput close to the required throughput. On
the other hand, the ratio becomes degraded when there are
50 competing TCP Reno connections. However, most of theevaluation slots which cannot achieve the required throughput
can achieve the throughput close to the required throughput.
B. Experiments in an actual Internet environment
We finally confirm the performance of the proposed mechanism in the commercial Internet environment. Figure 8 shows
the network environment, which consists of two local area
networks in Osaka, Japan and Tokyo, Japan, which are connected to the Internet. The network environment consists ofan endhost that generates cross traffic (traffic generator2), an
endhost that uses the proposed mechanism (sender2), and an
endhost that receives packets from both endhosts (receiver2)
across the Internet. The path of the commercial Internet
network between Osaka and Tokyo passes 100-Mbps opticalfiber services, and the local area networks in Osaka and Tokyois constructed by a 100-Mbps Ethernet networks. Table IIshows the specifications of the endhosts of the experimental
system. Through preliminary investigations, we confirmed thefollowing characteristics regarding the network between Osakaand Tokyo:• Seventeen hops exist in the network path from Osaka toTokyo.
• The minimum value of RTTs is 17 msec.
• The upper limit of the bandwidth between Osaka andTokyo is 70 Mbps.
In this experiment, we set e = 32 for the length ofevaluation slot, and s, the length of control slot, is initialized
to 16. The cross traffic is generated by traffic generator2, andsends the packets to receiver2. We set the size of TCP socket
buffer on traffic generator2 to limit the maximum throughput
of each TCP Reno connection to approximately 3 Mbps, andthe amount of the cross traffic is changed by the number of the
TCP Reno connections. On the other hand, the size of TCP
socket buffer on sender2 and receiver2 is enough large.
We first evaluate the behavior of the proposed mechanism
against the change in the amount of cross traffic. In this experiment, we use one connection for the proposed mechanism, andset bw to 14 (Mbps), which is equal to 20% of the bottleneck

Congestion window size [packets]

1

300
cwnd
length of control slot

100

8
4
2

0
0

10

20

30

40
50
Time [sec]60

70

Cumulative distribution

16

Length of slot [RTT]

0.8

32

200

0.6

0.4

0.2

(7, 30)(7, 50)(14, 30)(14, 50)

80
0
35

30

25

20

15

10

5

0

Throughput [Mbps](a) Changes in window size and control slot
lengthFig. 10.

CDF of throughput in the Internet experimentThroughput [Mbps]

80bw= 14Mbps
av-throughput

70

the measurement accuracy of the available bandwidth of the
network path operated by ImTCP becomes slightly degradedin the actual Internet environment. However, most of theevaluation slots which cannot achieve the required throughput
can achieve the throughput close to the required throughput.
Thus, we conclude that the proposed mechanism works welleven in the actual Internet environment.

60
50
40
30
20
10
0
0

10

20

30

40
50
Time [sec]

60

70

80

(b) Changes in throughput
Fig. 9. Changes in cwnd, control slot length and throughput in the Internet
experimentlink capacity. To change the congestion level of the network,
we change the number of TCP Reno connections between
traffic generator2 and receiver2 to 0, 5, 25, and 40 in every
20 seconds. Figure 9(a) shows the changes in the congestion
window size and the length of control slot, and Figure 9(b)shows the changes in the average throughput in each evaluation
slot.
The results for 0-20 seconds in Figure 9, when there is only
one connection for the proposed mechanism, we can find thatthe upper limit of the throughput between Osaka and Tokyo
is 70 Mbps because the proposed mechanism can obtain at
most apploximately 70 Mbps. In addition, the results after 20
seconds in Figure 9 is almost equivalent to the results on theexperimental network shown in Subsection 4.2.1. That is, theresults for 20-40 seconds show that the proposed mechanism
can obtain more than the required throughput by keeping
the same behavior as the normal TCP connection, and theresults for 40-60 seconds show that it can achieve the required
throughput by having a faster increase in the congestion
window size, The results after 60 seconds, we observe thatthe length of control slot is changed to a smaller value, andthe proposed mechanism can achieve the required throughput.
Thus, we have confirmed that the proposed mechanism caneffectively obtain the required throughput by changing thedegree of increase of the congestion window size and thelength of the control slot according to the network congestion
level in the commercial Internet environment.
We next evaluate the average throughput in each evaluation
slot, when we set bw to 7 and 14 Mbps and the number of
the TCP Reno connections to 30 and 50. Figure 10 shows the
cumulative distribution function of the average throughput ineach evaluation slot. From Figure 10, we can observe that theratio of achieving the required throughput is slightly smaller
than that in the experimental network in Figure 7. One ofthe possible reason is that there are short-lived connections,
including web-traffic, in the Internet environment, those traffic
has highly bursty nature. Since the proposed mechanism isbased on TCP, it can not adapt to shorter-term changes of
the network condition than its RTT. Another reason is that191

V. C ONCLUSION
In this paper, we focused on upper-layer applications requiring constant throughput, and proposed the TCP congestion
control mechanism for achieving the required throughput witha high probability. The proposed mechanism is modified
the degree of increase of the congestion window size of a
TCP connection in the congestion avoidance phase, by using
the information on the available bandwidth of the network
path. We implemented the proposed mechanism on Linux
2.6.16.21 kernel system, and confirmed from implementation
evaluation that the proposed mechanism works well in theactual networks.
In future studies, we will evaluate the performance of the
proposed mechanism in other actual network environments.
In addition, we would like to confirm the applicability of the
proposed mechanism to actual upper-layer applications, suchas a real-time video streaming.
R EFERENCES[1] M. Handley, S. Floyd, J. Padhye, and J. Widmer, “TCP friendly rate
control (TFRC): Protocol specification,” RFC 3448, Jan. 2003.
[2] C. L. T. Man, G. Hasegawa, and M. Murata, “ImTCP: Tcp with an
inline measurement mechanism for available bandwidth,” Computer
Communications Journal special issue of Monitoring and Measurementsof IP Networks, vol. 29, pp. 1614–1626, June 2006.
[3] Microsoft Corporation, “Microsoft Windows Media - Your Digital Entertainment Resource,” available from http://www.microsoft.com/windows/
windowsmedia/.
[4] RealNetworks Corporation, “Rhapsody & RealPlayer,” available fromhttp://www.real.com/.
[5] Skype Technologies Corporation, “Skype -The whole world can talk forfree.” available from http://www.skype.com/.
[6] K. Yamanegi, G. Hasegawa, and M. Murata, “Congestion control mechanism of TCP for achieving predicatable throughput,” in Proceedings of
ATNAC 2006, Dec. 2006, pp. 117–121.
[7] C. L. T. Man, G. Hasegawa, and M. Murata, “A simultaneous inline
measurement mechanism for capacity and available bandwidth of end-toend network path,” IEICE Transactions on Communications, vol. E89-B,
pp. 2469–2479, Sept. 2006.
[8] G. R. Wright and W. R. Stevens, TCP/IP Illustrated, Volume 2: The
Implementation. Addison-Wesley, 1995.
[9] T. Tsugawa, G. Hasegawa, and M. Murata, “Implementation and evaluation of an inline network measurement algorithm and its application to
TCP-based service,” in Proceedings of NOMS 2006 E2EMON Workshop
2006, Apr. 2006.
[10] L. Rizzo, “IP DUMMYNET,” available from http://info.iet.unipi.it/∼luigi/ip dummynet/.