IEICE TRANS. COMMUN., VOL.E89–B, NO.10 OCTOBER 2006

2850

PAPER

Mutual Complementarity between Diﬀusion-Type Flow Control
and TCP
Chisa TAKANO†,††a) , Kaori MURANAKA† , Members, Keita SUGIYAMA†† , Student Member,and Masaki AIDA†† , Member

SUMMARY
In current IP-based networks, the application of windowbased end-to-end flow control, including TCP, to ensure reliable flows is
an essential factor. However, since such a flow control is provided by theend hosts, end-to-end control cannot be applied to decision-making in atime-scale shorter than the round-trip delay. We have previously proposeda diﬀusion-type flow control mechanism to realize the extremely time sensitive flow control that is required for high-speed networks. In this mechanism, each network node manages its own traﬃc only on the basis of thelocal information directly available to it, by using predetermined rules. The
implementation of decision-making at each node can lead to optimal performance for the whole network. Our previous studies showed that themechanism works well, by itself, in high-speed networks. However, to apply this mechanism to actual networks, it needs to be able to coexist withother existing protocols. In this paper, we investigate the performance ofdiﬀusion-type flow control coexisting with TCP. We show that diﬀusiontype flow control can coexist with TCP and the two can be complementary.
Then, we show that a combination of both controls achieves higher network
performance than TCP alone in high-speed networks.
key words: flow control, autonomous decentralized control, diﬀusion equation, high-speed networks

1.

Introduction

The rapid spread of the Internet will necessitate the construction of higher-speed backbone networks in the near future. In a high-speed network, it is impossible to implement
time-sensitive control based on collecting global information about the whole network because the state of a nodevaries rapidly with time, and is dependent on its processing speed, even if the propagation delay is identical withthat in low-speed networks. We have previously proposed adiﬀusion-type flow control (DFC) mechanism as a solution
for the severely time-sensitive flow control that is requiredfor high-speed networks [1]–[3].
The diﬀerent control mechanisms in networks can beclassified from the point of view of their particular timescale of control operations. Figure 1 shows the mutual relationship of diﬀerent types of control according to such aclassification. They form a layered structure with respect totime-scale. For example, routing and call admission control fall into the long and medium time-scales, respectively.
Manuscript received January 23, 2006.
Manuscript revised April 12, 2006.
†
The authors are with Traﬃc Engineering Division, NTT Advanced Technology Corporation (NTT-AT), Musashino-shi, 1800006 Japan.
††
The authors are with the Graduate School of System Design,
Tokyo Metropolitan University, Hino-shi, 191-0065 Japan.
a) E-mail: chisa.takano@ntt-at.co.jp
DOI: 10.1093/ietcom/e89–b.10.2850

Fig. 1 Classification of various control mechanisms with respect to theireﬀective time-scales.

Individual control mechanisms work well for their appropriate time-scales and they cooperate with each other. An
end-to-end control such as TCP acts on the time-scale of theround-trip delay time (RTT). In high-speed networks, since
a lot of packets are in transit on links, the delay in applying control greatly aﬀects the network performance. However, since end hosts provide the flow control, TCP cannot
be applied to decision-making in a time-scale shorter thanthe RTT. The target of DFC is a time-scale shorter than the
RTT.
To overcome the ineﬃciency of TCP in high-speed networks, eXplicit Control Protocol (XCP) has been proposed[4]. This protocol is a generalization of Explicit Congestion Notification (ECN). By notifying information about arouter to an end host, XCP can stabilize TCP performance.
However, XCP is an end-to-node control and the notification of router information to an end host experiences delay
proportional to the RTT. Therefore, TCP assisted by XCP,
cannot be applied to decision-making in a time-scale verymuch shorter than the RTT.
Most research into flow control mechanisms mainly focuses on optimization problems [5]–[9]. These studies do
not address the requirement of time-sensitivity in network
control. The principles adopted for time-sensitive control
are inevitably those of autonomous decentralized systems[10]. DFC is a solution for the extremely time-sensitive flow
control required for high-speed networks, and is designed sothat can satisfy the following requirements:• It must be possible to collect the information required
for the control method.
• The control should take eﬀect immediately.
In DFC, by using predetermined rules, each node in a net-

c 2006 The Institute of Electronics, Information and Communication Engineers
Copyright TAKANO et al.: MUTUAL COMPLEMENTARITY BETWEEN DIFFUSION-TYPE FLOW CONTROL AND TCP

2851

work manages its local traﬃc flow on the basis of only the
local information directly available to it. In addition, theimplementation of decision-making at each node can leadto optimal performance for the whole network. That is, thestate of the whole network is controlled indirectly throughthe autonomous action of each node.
Decentralized flow control by end hosts, including
TCP, is widely used in current networks, and there has
been a lot of research in this area [8], [9], [11]. However,since end-to-end or end-to-node control cannot be applied
to decision-making on a time-scale shorter than the roundtrip delay, it is not capable of supporting decision-making
on a very short time-scale. In low-speed networks, a control
delay of the order of the RTT has a negligible eﬀect on the
network performance. However, in high-speed networks,
the control delay greatly aﬀects the network performance.
This is because, although the RTT is itself unchanged, it becomes larger relative to the unit of time determined by thenode’s processing speed. This means that nodes in highspeed networks experience a larger RTT relative to the processing speed, and this causes an increase in the sensitivity
to control delay. To achieve rapid control in a time-scale
shorter than the RTT, it is preferable to apply control by thenodes rather than by the end hosts (see Fig. 2).
Let us consider the situation where the RTT is 100 ms
when a network is congested. The upper graph in Fig. 2
shows the relationship between the speed of the network andthe number of packets influenced by the control delay, when
flow control by end hosts is applied. If the network speed is10 Mbps, the number of packets influenced by control delay
from an end host is only a few hundred. However, if the
network speed is 100 Gbps, the number of packets is several
million. Even though the RTT is unchanged, the increase in
the network speed has a severe influence on network performance. If we apply node-by-node control (the lower graphin Fig. 2), the control delay is reduced typically by a factorof 2000 compared to end host control.
We have evaluated the performance of DFC in a highspeed network environment [1]–[3]. In particular, DFC foran end-to-end flow has been evaluated in [3]. Since the previous studies have not introduced window flow control such
as TCP as a means of end-to-end flow control, we shouldverify the compatibility and complementarity of DFC withTCP.
In this paper, we investigate the performance of DFC
coexisting with TCP. We show that DFC can coexist with
TCP and the two can complement each other. In addition, we show that the coexistence of both controls achieves
higher network performance than TCP alone in high-speed
networks. The remainder of this paper is organized as follows. In Sect. 2, we describe the framework of DFC. In
Sect. 3, we describe some requirements of DFC which arenecessary to ensure that DFC works appropriately in actual networks. In Secs. 4–6, we evaluate the performanceof TCP with DFC in various situations: network speed, network size, and diﬀerent TCP implementations. The comparisons were made using the ns2 simulator. Finally, Sect. 7

Fig. 2 Relationship between the number of packets influenced by control
delay and the speed of the network. The upper graph illustrates control
by end hosts and the lower one illustrates node-by-node control. (A trial
calculation was made with an average distance between nodes of 10 km,
average number of hops = 5, and a link utilization of 0.5.)

provides the conclusions to this paper.
2.

Diﬀusion-Type Flow Control

2.1 Concept
In the case of Internet-based networks, to guarantee the endto-end quality of service (QoS) of a flow, a QoS-sensitive
flow uses a static route (e.g., RSVP). Thus, we assume thata target flow has a static route. In addition, we assume allrouters in the network can employ per-flow queuing for all
the target flows† . DFC provides a framework in which theimplementation of the decision-making of each node leads
to high performance for the whole network. The principleof our flow control model can be explained through the following analogy [3].
When we heat a point on a cold iron bar, the temperature distribution follows a normal distribution and heatspreads through the whole bar by diﬀusion (Fig. 3). In thisprocess, the action in a minute segment of the iron bar is†
The assumption of per-flow queuing is not mandatory in theframework of DFC, but it is convenient to use it to simplify the
explanation of the framework. In actual fact, it is hard to implement per-flow queuing in high-speed networks Fundamentally,
DFC only requires “per-input port” queueing.

IEICE TRANS. COMMUN., VOL.E89–B, NO.10 OCTOBER 2006

2852

Fig. 3

Example of thermal diﬀusion phenomenon.

Fig. 4

Node interactions in our flow control model.

very simple: heat flows from the hotter side towards thecooler side. The rate of heat flow is proportional to thetemperature gradient. There is no direct communication
between two distant segments of the iron bar. Althougheach segment acts autonomously, based on its local information, the temperature distribution of the whole iron bar exhibits orderly behavior. In DFC, each node controls its local
packet flow. The packet rate includes the quantity that is proportional to the diﬀerence between the number of packets inthe node and that in an adjacent node. Thus, the distribution of the total number of packets in a node in the network
becomes uniform over time. In this control mechanism, thestate of the whole network is controlled indirectly throughthe autonomous action of each node.
2.2 Main Principle of Diﬀusion-Type Flow Control Mechanism
In DFC, each node controls its local packet flow autonomously. Figure 4 shows the interactions between nodes(routers) in our flow control method, using a network modelwith a simple 1-dimensional configuration. All nodes have
two incoming and two outgoing links, for a one-way packet
stream and for feedback information, that is, node i (i =1, 2, . . . ) transfers packets to node i+1, and node i+1 sends
feedback information to node i. For simplicity, we assume
that packets have a fixed length in bits.
All nodes are capable of receiving feedback information from adjacent downstream nodes, and sending it to adjacent upstream nodes. Each node i can receive feedback
information sent from the downstream node i + 1 and cansend feedback information about itself to the upstream nodei − 1.
When node i receives feedback information fromdownstream node i + 1, it determines the transmission rate
for packets to the downstream node i + 1 using the received
feedback information, and it adjusts its transmission rate towards the downstream node i + 1 accordingly. The framework for node behavior and flow control may be summarized as follows:• Each node i autonomously determines the transmission
rate Ji on the basis of only the local information directly available to it, that is, the feedback information

obtained from the downstream node i + 1 and its own
feedback information.
• The rule for determining the transmission rate is thesame for all nodes.
• Each node i adjusts its transmission rate towards thedownstream node i + 1 to Ji .
(If there are no packets in node i, the packet transmission rate is 0.)• Each node i autonomously creates feedback information according to a predefined rule and sends it to the
upstream node i − 1. Feedback information is createdperiodically with a fixed interval τi for each link.
• The rule for creating the feedback information is thesame for all nodes.
• Packets and feedback information both experience thesame propagation delay.
As mentioned above, the framework of our flow control
model involves both autonomous decision-making by eachnode and interaction between adjacent nodes. There is nocentralized control mechanism in the network.
Next, we explain the details of DFC. The transmission
rate Ji (α, t) of node i at time t is determined by
Ji (α, t) = max(0, min(Li (t), J˜i (α, t))), andJ˜i (α, t) = α ri (t − di ) − Di (ni+1 (t − di ) − ni (t)),

(1)
(2)

where Li (t) denotes the value of the available bandwidth ofthe link from node i to node i+1 for target flow at time t, ni (t)denotes the number of packets in node i at time t, ri (t − di )is the target transmission rate specified by the downstream
node i + 1 as feedback information, and di denotes the propagation delay between nodes i and i + 1. The determinationof Li (t) is explained in the next subsection.
In addition, ri (t − di ) and ni+1 (t − di ) are reported fromthe downstream node i + 1 as feedback information withpropagation delay di . Parameter α (≥ 1), which is a constant, is the flow intensity multiplier. When α = 1, the firstterm on the right-hand side of (2) becomes ri (t − di ). Thisparameter setting influences the balance between input andoutput traﬃc at a node. Our previous study [3] showed thatα = 1 exhibits appropriate performance. Parameter Di ischosen to be inversely proportional to the propagation delay[2] as follows:
Di = D1∝ (di )−1 ,di(3)where D (> 0), which is a positive constant, is the diﬀusion
coeﬃcient.
The feedback information Fi (t) created at regular fixedintervals of periodicity τi by node i consists of the two quantities shown in (4):Fi (t) = (ri−1 (t), ni (t)).

(4)

Node i reports this to the upstream node i − 1 with a periodof τi = di−1 . Here, the target transmission rate is determinedasTAKANO et al.: MUTUAL COMPLEMENTARITY BETWEEN DIFFUSION-TYPE FLOW CONTROL AND TCP

2853

ri−1 (t) = Ji (1, t).

(5)Moreover, the packet flow Ji (t) in node i is adjusted whenever feedback information arrives from the downstream
node i + 1 (with a periodicity of τi+1 = di ).
To allow an intuitive understanding, we will briefly explain the physical meaning of DFC. Let us replace i with x
and apply a continuous approximation. Then the propagation delay becomes di → 0 for all i and the packet flow (2)may be expressed as
˜ x, t) = α r(x, t) − D ∂n(x, t) ,
J(α,
∂x

(6)

and the temporal evolution of the packet density n(x, t) may
be represented by a diﬀusion-type equation,∂n(x, t)∂r(x, t)∂ n(x, t)
= −α
+D
,
∂t
∂x
∂x2

j
j
follows: Li (t) → Li (t), J˜i (α, t) → J˜i (α, t), etc., where thesemean the quantities for flow j. Let the bandwidth of the linkfrom node i to i + 1 be Bi . Then, Lij (t) ( j = 1, 2, . . . , Mi )must satisfyMi˜ x, t)∂n(x, t)∂ J(α,=−.
∂t∂x

where Mi denotes the number of flows at node i.
In DFC, the ideal transmission rate is J˜ij (α, t), andJij (α, t) is restricted by its available bandwidth. In particular, if there are a lot of flows, the ideal transmission rate
J˜ij (α, t) is frequentlyMiAs explained in Sect. 2.1, our method aims to perform flow
control using the analogy of diﬀusion. We can therefore
expect excess packets in a congested node to become distributed over the whole network and normal network conditions to be restored after some time.
In addition to the above framework, we consider theboundary condition of the rule for determining the transmission rate in the DFC.
Here we consider the situation where nodes and/or end
hosts in other networks do not support the DFC mechanism.
We call the nodes and/or end hosts that are connected directly to the ingress node in our network external nodes. We
assume that the external nodes only have a traﬃc shaping
function, which can adjust the transmission rate to the requested rate reported by the downstream node.
That is, an external node 0 cannot calculate the transmission rate J0 (α, t) using (2), but can adjust its transmission
rate to r0 (t − d0 ), which was reported by node 1.
We consider a rule for determining r0 (t) as a boundary
condition. Node 1 can calculate J0 (α, t) if we assume thatthe number of packets stored in the other networks’ node isi = 0. The target rate r0 (t), reported by node 1, is created as
J˜0 (α, t) with the above assumption. That is,
r0 (t) := J˜0 (α, t + d0 ) = α J1 (1, t) − D0 n1 (t).

(9)

This quantity can be calculated just from information known
to node 1.
2.3 Determination of Available Bandwidth
Since the link bandwidth is shared by multiple flows, weneed to adjust the available bandwidth, Li (t), appropriately
among the flows. In this subsection, we take multiple flows
into account. So, we have generalized some quantities as

J˜ij (α, t) > Bi ,

(11)

j=1

(7)

(8)

(10)

j=1

2

using the continuous equation

Lij (t) ≤ Bi ,and the probability of each flow getting its ideal transmission rate J˜ij (α, t) is low. This prevents the smooth equalization of the packet density. So, we take into consideration
two conditions: the relative value of the ideal transmission
rate of each flow, and the following equation.
Mi

Jij (α, t) ≤ Bi .

(12)

j=1

Then, the simplest way to determine Lii (t) is to assume
that the bandwidth Bi is shared between flows according toa flow weight J˜ij (α, t) [12], that is,J˜j (α, t)Lij (t) = Bi  M i j.
i˜
j=1 Ji (α, t)(13)This rule means that a flow with larger J˜ij (α, t) can have alarger transmission rate and can transmit a larger volume of
traﬃc to the downstream node. Thus, the transmission rates
of other flows are regulated to be smaller.
Hereafter, we focus on models having two flows, a target flow and a background flow, and investigate the extent towhich DFC and TCP complement each other in operation.
The performance of DFC for multiple flows was describedin our previous study [12].
3.

Requirements of Characteristics of TCP Coexistence with DFC

If DFC is to be installed in actual networks, it must work
well with UDP and TCP. Our previous studies showed that
DFC itself exhibits improved performance. These results
imply that DFC should works well in combination withsome kinds of protocols, including UDP, that have no flow
control. Since TCP includes its own flow control, we need toverify the compatibility and complementarity of DFC withrespect to TCP. We extend the simulation tool ns2 [13] capability with the function of DFC to investigate the performance of DFC when coexisting with TCP.

IEICE TRANS. COMMUN., VOL.E89–B, NO.10 OCTOBER 2006

2854

In general, it is diﬃcult to for two diﬀerent flow control mechanisms to coexist in the same network, especially ifthey act in the same time-scale. For example, both TCP and
ATM ABR include end-to-end flow control mechanisms,
which act in the time-scale of the RTT. Since they makedecisions in the same time-scale, but not in a manner whichis cooperative, it is hard to obtain synergy between them.
One of important features of DFC, which can help
overcome this problem and to achieve complementarity between DFC and TCP, is that they act in diﬀerent time-scales.
DFC is a node-by-node control and acts in a time-scale
shorter than the RTT. The diﬀerence of the time-scales islarger for high-speed and large-scale networks. Even though
it is more diﬃcult to control higher-speed and larger-scale
networks using TCP, we expect a coexistence of DFC with
TCP to give dependable performance in this situation.
To verify the performance of the coexistence of DFC
and TCP, we evaluate their complementarity from the following three points of view:• Performance characteristics in high-speed networks.
• Performance characteristics in large-scale networks.
• Performance characteristics with diﬀerent TCP implementations.
4.

Complementarity of DFC and TCP with Respect to
Network Speed

4.1 Simulation Model
Figure 5 shows our network model with 30 nodes, which isused in the simulations. Although this 1-dimensional model
looks simple, it represents a part of a network and describes
a path of the target end-to-end flow extracted from the wholenetwork. The propagation delay of each link between nodes
is 0.1 ms, and the buﬀer capacity at each node is 1800 packets. The reason why the capacity of buﬀer is fixed in our

Fig. 5scenario 1
scenario 2
scenario 3
scenario 4
scenario 5
scenario 6

model is as follows. In actual network design, it is natural
to choose a larger capacity of buﬀer for a larger link bandwidth. However, the appropriate capacity with respect topacket loss and delay depends on the RTT of each flow.
Since we cannot predict the RTT of incoming flows to arouter in advance at the router design stage, the appropriate
capacity cannot be designed in advance. So, it is preferable
that the appropriate performance should be obtained by using as small a capacity of buﬀer as possible. One aim of oursimulation models is to show that DFC exhibits appropriate
performance even when the buﬀer capacity is small.
The target flow is between node 1 and node 30, while
the background traﬃc flows between node 15 and node 30.
The target flow and the background flow start at simulation
time t = 0 s and t = 0.1 s, respectively.
We investigated the network performance with respect
to network speed in the cases of TCP flow control without
DFC and TCP coexisting with DFC by the use of six simulation scenarios. The background flow was controlled by
the same method as the target flow, that is, TCP without
DFC or TCP with DFC. Unlike TCP with DFC, TCP without DFC does not use per-flow queuing but uses FIFO. The
network parameters and flow control parameters for eachsimulation scenario are summarized in Table 1. The maximum TCP window size was chosen to be suﬃciently larger
than the bandwidth-delay product. The source traﬃc modelis greedy, that is, input traﬃc to the network is the same as
the quantity allowed by the flow control. For simplicity, thepacket size was a fixed length of 1500 bytes. In addition, we
chose α = 1.0 in DFC. The implementation of TCP usedin the results reported in this section was TCP Tahoe. The
buﬀer capacity of the nodes and the distances between thenodes were the same in all scenarios. The link bandwidth
was altered, becoming progressively greater in the diﬀerent scenarios. The window size was also increased to caterfor this larger bandwidth. That is, scenario 1 represented a
network with the smallest link bandwidth, while scenario 6

Simulation model.

Table 1 Simulation conditions.
network parameters
flow control parameterslink bandwidth link delay
buﬀer capacity
diﬀusion coeﬃcientmax. window size
(Mbps)(msec)(packets)
370
0.1
1800
0.1
5,000
1,230
0.1
1800
0.1
5,000
3,700
0.1
1800
0.1
5,000
12,3000.1
1800
0.1
10,00037,0000.1
1800
0.1
20,000123,000
0.1
1800
0.1
100,000

TAKANO et al.: MUTUAL COMPLEMENTARITY BETWEEN DIFFUSION-TYPE FLOW CONTROL AND TCP

2855

Fig. 6

Simulation scenario 1.

Fig. 7

Simulation scenario 2.

Fig. 8Simulation scenario 3.

Fig. 9Simulation scenario 4.

Fig. 10

Simulation scenario 5.

Fig. 11

Simulation scenario 6.

represented a network with the largest link bandwidth.
4.2 Simulation Results
Figures 6–11 show the simulation results obtained from scenarios 1–6, respectively. The horizontal axes denote the simulation time and the vertical axes denote the eﬃciency of the
networks. Here, the eﬃciency of the network represents thenormalized value of the total number of packets that are intransit on links, that is, a ratio of the total number of packets
that are in transit on links to the maximum number of packets that can be in transit on links. The total number of packets means the number of packets being transported by the
network at a particular instant. The left-hand graph of eachfigure shows the result obtained using TCP without DFC,
and the right-hand graph shows the result obtained using
TCP with DFC. The simulation time was 3 s for scenarios
1–5, and 1.5 s for scenario 6. After the time when the background traﬃc started (after 0.1 s), the available bandwidth
for the target flow was reduced to a half. If the eﬃciency of
networks reaches 0.5 after 0.1 s, the target flow is sharing
the link bandwidth fairly, with high utilization.
In Figs. 6–10 the eﬃciency of TCP without DFC is low
and unstable. This is because the background traﬃc enter-ing at node 15 causes packet losses and with the result thatTCP reduces its window size. On the other hand, the eﬃciency of TCP with DFC remains high and stable. This isbecause DFC acts to prevent packet loss. Through the diffusion eﬀect of DFC, the number of packets stored at nodes
becomes uniform over time. These results show that when
TCP is used in conjunction with DFC it is possible to maintain high and stable network eﬃciency, even if background
traﬃc changes. In Fig. 11, both TCP without and TCP with
DFC exhibit low and unstable eﬃciency. At this link speed,
the capacity of the buﬀers is too small to prevent packet loss
even when DFC is applied. Thus, packet losses can occur
not only in the case of TCP without DFC but also when
TCP is used with DFC, if the buﬀer size is not adequate forthe link speed.
Next, to investigate the diﬀerence between TCP without DFC and TCP with DFC, we show the temporal evolution of the number of packets stored in each node. Figures 12 and 13 show the results obtained from TCP wthout
and with DFC (both are scenario 4). The horizontal axes denote node ID (1–29) and the vertical axes denote the numberof packet stored at the node. The five diﬀerent graphs foreach case represent diﬀerent instants during the simulation,

IEICE TRANS. COMMUN., VOL.E89–B, NO.10 OCTOBER 2006

2856

Fig. 12

Temporal evolution of distribution of packets stored in each node (TCP without DFC).

Fig. 13

Temporal evolution of distribution of packets stored in each node (TCP with DFC).

the time being shown on each graph.
In the case of Fig. 12, after the time when the background traﬃc started (after 0.1 s), all the stored packets wereat node 15, resulting in packet loss. The number of stored
packet at node 15 reached the buﬀer size of 1800 and packet
loss occured. After that, the TCP window size was reduced
and the number of stored packet decreased. In the case of
Fig. 13, TCP with DFC prevents the stored packets frombuilding up at a particular node. This eﬀect is due to theoperation of DFC. Since packet loss was avoided, the TCP
window size did not reduce and high network eﬃciency wasachieved, as shown as Figs. 6–10. Through the introductionof DFC, each node acts cooperatively to avoid packet loss
even though the decision-making of each node is based only
on the local information.
5.

Complementarity of DFC and TCP with Respect to
the Number of Hops

Table 2 Simulation conditions 2.
numberwindowotherof nodescapacity
parameters
scenario 4S
16
10,000same as scenario 4
scenario 4L
60
20,000same as scenario 4

TCP without DFC TCP with DFC
Fig. 14

Simulation scenario 4S.

Fig. 15

Simulation scenario 4L.

5.1 Simulation ModelIn this section, we investigate the performance characteristics of TCP with DFC with respect to the network size. We
take scenario 4 in Sect. 4 as a reference model, and add newmodels which have 16 nodes and 60 nodes. We call themscenarios 4S and 4L, respectively. The background traﬃcis entered at node 8 in scenario 4S and node 30 in scenario
4L. In scenario 4L, the maximum TCP window size waschanged from scenario 4 because it should be chosen to be
suﬃciently larger than the bandwidth-delay product. Other
simulation conditions were the same as for scenario 4 (Table 2).
5.2 Simulation Results
Figures 14 and 15 show the results obtained from scenarios 4S and 4L, respectively. The horizontal axes denote thesimulation time and the vertical axes denote the eﬃciency ofthe network. The left-hand graph of each figure shows theresult obtained using TCP without DFC, and the right-handgraph shows the result obtained using TCP with DFC. By

comparing these figures with Fig. 9, the performance of TCP
without DFC can be seen to be degraded as the network size
increases. In other words, a larger RTT degrades the performance of TCP. On the other hand, TCP with DFC exhibitshigh and stable network eﬃciency for all cases. These results show that DFC can be eﬀective irrespective of network
size.

TAKANO et al.: MUTUAL COMPLEMENTARITY BETWEEN DIFFUSION-TYPE FLOW CONTROL AND TCP

2857

6.

Complementarity of DFC and TCP with Respect toDiﬀerences in TCPs Implementation

6.1 Simulation Model
In previous sections, our evaluation results were obtainedusing TCP Tahoe. Other popular implementations of TCP
are Reno, NewReno, and Vegas. The main diﬀerence ofReno and NewReno with respect to Tahoe is in the behavior
of TCP window size after the detection of packet loss.
In the evaluation of TCP with DFC it is possible to
avoid packet losses if each node has appropriate buﬀer size
(but the size is still smaller than that required for TCP without DFC). Thus, we may expect that replacing Tahoe with
Reno or NewReno in TCP with DFC will cause no essential change in the results described in the previous sections.
However, Vegas is rather diﬀerent from other implementations. In this section, we evaluate the performance characteristics of TCP with DFC with respect to diﬀerences in TCP
implementation.
As in Sect. 5, we take scenario 4 in Sect. 4 as areference model, and add new models using TCP Reno,
NewReno, and Vegas. We call them scenarios 4R, 4N, and4 V, respectively. Other simulation conditions are same asin scenario 4 (see Table 3). TCP window control in Vegas is
triggered by the detection of a variation in RTT, variations
while in the other implementations (Reno and NewReno)
window control is triggered by detection of packet losses.
Thus, Vegas can act in a smaller time-scale than the others.
That is, Vegas has a smaller control delay than the other implementations. To further investigate the behavior of TCP
Vegas without and with DFC, we introduce a new modelin addition to the above models. This model has a smaller
buﬀer size (400 packets), but the other conditions are thesame as for scenario 4 V. We call it scenario 4 V’ (Table 4).

obtained from TCP without DFC, and the right-hand graphshows the result obtained from TCP with DFC. By comparing these figure with Fig. 9, we can see that the performanceof TCP without DFC for Reno or NewReno is improved
compared with than that for Tahoe. However, the improved
performance is still inferior to TCP with DFC. TCP with
DFC exhibits high and stable eﬃciency of the network for
all three of the TCP implementations compared here, that is
Tahoe, Reno, and NewReno.
Figure 18 shows the results obtained from scenario 4 V.
This result is completely diﬀerent from the previous results.
Strong oscillations appears in the behavior of the eﬃciencyof the network. Since high frequency oscillations in the behavior of the eﬃciency of the network do not contribute tothroughput (the eﬃciency of the network averaged over alonger time-scale), the throughput tends to decrease and toconverge slowly. The results for TCP without and TCP with
DFC are almost the same, and this similarity means the origin of the behavior is a feature of TCP Vegas. The additionof DFC does not influence the behavior of the eﬃciency oft he network in this case.
In the evaluation of scenario 4 V, there was no packet
loss. This is because Vegas has a smaller control delay thanFig. 16

Simulation scenario 4R.

Fig. 17

Simulation scenario 4N.

Fig. 18

Simulation scenario 4 V.

6.2 Simulation Results
Figures 16 and 17 show the results obtained from scenarios
4R and 4N, respectively. The horizontal axes denote simulation time and the vertical axes denote the eﬃciency of the
network. The left-hand graph in each figure shows the result
Table 3 Simulation conditions 3.
implementation
buﬀer
other
of TCP
capacity
parameters
scenario 4R
Renosame as scenario 4 same as scenario 4
scenario 4N
Newrenosame as scenario 4 same as scenario 4
scenario 4 V
Vegas
same as scenario 4 same as scenario 4

Table 4 Simulation conditions 4.
implementation
buﬀer
other
of TCP
capacity
parameters
scenario 4 V
Vegas
same as scenario 4 same as scenario 4
scenario 4 V’
Vegas
400
same as scenario 4

IEICE TRANS. COMMUN., VOL.E89–B, NO.10 OCTOBER 2006

2858

Acknowledgments
This research was partially supported by the Grant-in-Aid
for Scientific Research (S) No. 18100001 (2006–2010) fromthe Japan Society for the Promotion of Science.
References
Fig. 19

Simulation scenario 4 V’.

other implementations. To further clarify the diﬀerence between TCP without and TCP with DFC, we evaluate scenario 4 V’, in which a smaller buﬀer size is used. Figure 19
shows the results obtained from scenario 4 V’. In the caseof TCP without DFC, there is packet loss and the eﬃciencyof the network is degraded remarkably. In the case of TCP
with DFC, the eﬃciency obtained is same as in scenario 4 V.
Consequently, we may conclude that introducing DFC
makes it possible to stabilize TCP performance for all TCP
implementations: Tahoe, Reno, NewReno, and Vegas.
7.

Conclusions

To overcome the diﬃculty in controlling high-speed networks, we have proposed DFC, where each node manages
its local traﬃc flow on the basis of only the local information
directly available to it, by using predetermined rules.
One of the important issues in the application of DFC
is the verification of the applicability of DFC to conventional networks. DFC needs to work well in conventional
networks. This paper investigates the issue of the complementarity of DFC and TCP. This is the central issue for DFC
applicability. We extended the capabilities of the simulation
tool ns2, by adding the function of DFC, and investigatedthe performance of TCP without DFC and TCP with DFC.
We found that the eﬃciency of the network is low and unstable in the case of TCP without DFC, while in case of TCP
with DFC the eﬃciency of the network becomes stable andhigh, even for high speed networks.
In addition, we compared the behavior of the distribution of packets among the individual nodes for TCP without
DFC and for TCP with DFC, in order to demonstrate the performance of DFC. The simulation results showed that packet
loss occurs at congestion nodes for TCP without DFC, while
TCP with DFC avoids packet losses.
Moreover, we investigated the performances of TCP
with DFC with respect to diﬀerent network sizes and different TCP implementations. These results tell us that introducing DFC enables to stabilize TCP performance in various situations.
These results indicate that the desirable characteristics of DFC, including the cooperative behavior of nodes
to avoid packet loss and the ability to recover rapidly fromcongestion, are also eﬀective for a TCP controlled flow.

[1] C. Takano and M. Aida, “Stability and adaptability of autonomous decentralized flow control in high-speed networks,” IEICE Trans. Commun., vol.E86-B, no.10, pp.2882–2890, Oct. 2003.
[2] C. Takano, M. Aida, and S. Kuribayashi, “Autonomous decentralized
flow control in high-speed networks with inhomogeneous configurations,” IEICE Trans. Commun., vol.E87-B, no.6, pp.1551–1560, June
2004.
[3] C. Takano and M. Aida, “Diﬀusion-type autonomous decentralized
flow control for end-to-end flow in high-speed networks,” IEICE
Trans. Commun., vol.E88-B, no.4, pp.1559–1567, April 2005.
[4] D. Katabi, M. Handley, and C. Rohrs, “Congestion control for highbandwidth-delay product networks,” Proc. ACM SIGCOMM 2002,
pp.89–102, Aug. 2002.
[5] Y. Bartal, J. Byers, and D. Raz, “Global optimization using local information with applications to flow control,” Proc. 38th Ann. IEEE
Symp. on Foundations of Computer Science, pp.303–312, Oct. 1997.
[6] S.H. Low and D.E. Lapsley, “Optimization flow control-I: Basic algorithm and convergence,” IEEE/ACM Trans. Netw., vol.7, no.6,
pp.861–874, 1999.
[7] K. Kar, S. Sarkar, and L. Tassiulas, “A simple rate control algorithm for maximizing total user utility,” Proc. IEEE INFOCOM 2001,
pp.133–141, 2001.
[8] J. Mo and J. Walrand, “Fair end-to-end window based congestion control,” IEEE/ACM Trans. Netw., vol.8, no.5, pp.556–567, Oct. 1999.
[9] S. Kunniyur and R. Srikant, “A decentralized adaptive ECN marking
algorithm,” Proc. IEEE GLOBECOM’00, pp.1719–1723, 2000.
[10] M. Aida and K. Horikawa, “Stability analysis for global performanceof flow control in high-speed networks based on statistical physics,”
IEICE Trans. Commun., vol.E82-B, no.12, pp.2095–2106, Dec. 1999.
[11] R. Johari and D. Tan, “End-to-end congestion control for the Internet:
Delays and stability,” IEEE/ACM Trans. Netw., vol.9, no.6, pp.818–
832, Dec. 2001.
[12] M. Aida, C. Takano, and A. Miura, “Diﬀusion-type flow control
scheme for multiple flows,” 19th International Teletraﬃc Congress(ITC19), pp.133–142, 2005.
[13] The Network Simulator — ns-2. http://www.isi.edu/nsnam/ns/

Chisa Takano
received the B.E. in Telecommunications Engineering from Osaka University, Japan, in 2000. In 2000 she joined Traffic Research Center, NTT Advanced Technology Corporation (NTT-AT). She has been engaged in research and development of computer
networks. She received the Young Researchers’Award of IEICE in 2003.

TAKANO et al.: MUTUAL COMPLEMENTARITY BETWEEN DIFFUSION-TYPE FLOW CONTROL AND TCP

2859

Kaori Muranaka
received the B.S. in Mathematics from Tsuda College, Tokyo, Japan, in
1999. In 1999 she joined Traﬃc ResearchCenter, NTT Advanced Technology Corporation (NTT-AT). She has been engaged in research on traﬃc issues in computer communication networks.

Keita Sugiyama
received his B.E. in Information Systems Engineering from Tokyo Institute of Technology, Japan, in 2006. Now, he
is a graduate student of the Graduate School of
System Design, Tokyo Metropolitan University.

Masaki Aida
received his B.Sc. and M.Sc.
in Theoretical Physics from St. Paul’s University, Tokyo, Japan, in 1987 and 1989, and received the Ph.D. in Telecommunications Engineering from the University of Tokyo, Japan, in
1999. He joined NTT Laboratories in 1989. He
was also a manager at Traﬃc Research Center,
NTT Advanced Technology Corporation (NTTAT) from 1998 to 2001. His current interests include traﬃc issues in communication systems. He is currently an Associate Professor at
the Graduate School of System Design, Tokyo Metropolitan University.
Dr. Aida received the Young Researchers’ Award of IEICE in 1996. He isa member of the IEEE and the Operations Research Society of Japan.