LIRA: An Approach for Service Differentiation in the Internet
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
LIRA: An Approach for Service Differentiation in the Internet
Ion Stoica, Hui Zhang
Carnegie Mellon University
Pittsburgh, PA 15213
e-mail: fistoica,hzhangg@cs.cmu.edu
Abstract 1 Introduction
As the Internet evolves into a global commercial infras-
In this paper, we study the Assured Service model pro- tructure, there is a growing need to support more enhanced
posed by Clark and Wroclawski [3, 4]. While existing services than the traditional best-effort service. To address
schemes use service profiles that are defined in terms of ab- this issue, several new QoS models (guaranteed, controlled
solute bandwidth, it is difficult, if not impossible, to design load, committed rate) have been proposed [26, 31]. Collec-
provisioning algorithms that achieve simultaneously good tively, they are called Integrated Services or Intserv models.
service quality and high resource utilization for such ser- Recently, there are new efforts in the IETF to develop a new
vices with large spatial granularities. class of service models called Differential Services or Diff-
serv models [2, 3, 4, 17, 22, 29].
We propose an Assured Service model, called LIRA (Lo- While these schemes differ in details, they are very sim-
cation Independent Resource Accounting), in which ser- ilar at the architectural level. Usually a scheme consists
vice profiles are defined in units of resource tokens, rather of the following components: (a) a service profile between
than absolute bandwidth. The number of resource tokens each customer (user) and the Internet Service Provider (ISP)
charged for each in-profile packet is a dynamic function of that defines the commitment of the ISP to the user, (b)
the path it traverses and the congestion level. Defining ser- ingress nodes at the ISP edge which police the aggregate
vice profile in terms of resource tokens allows more dynamic traffic from each user to make sure that no user exceeds its
and flexible network control algorithms that can simultane- service profile, (c) network nodes inside the ISP core which
ously achieve high utilization and ensure high probability implement a variety of packet forwarding, buffer manage-
delivery of in-profile packets. We present an integrated set ment, and scheduling behaviors in order to control packet
of algorithms that implement the model. Specifically, we queueing delay, loss, and/or throughput, and (d) a set of bits
leverage the existing routing infrastructure to distribute the in the header of each packet used to trigger mechanism for
path costs to all edge nodes. Since the path cost reflects the differential processing inside the network. Usually, there
congestion level along the path, we use this cost to design are two types of bits. The first type specifies the differential
dynamic routing and load balancing algorithms. To avoid processing behavior requested by the user, such as drop or
packet re-ordering within a flow, we devise a lightweight delay preference. These bits are not modified by the routers.
mechanism that binds a flow to a route so that all packets The second type of bits can be changed by routers and en-
from the flow will traverse the same route. To reduce route codes the dynamic information. An example is the bit that
oscillation, we probabilistically bind a flow to one of the encodes whether the packet is in or out of the service profile.
multiple routes. Simulation results are presented to demon- The key difference between Intserv and Diffserv is that
strate the effectiveness of the approach. while Intserv provides end-to-end QoS service on a per flow
basis, Diffserv is intended to provide service differentia-
tion among the traffic aggregates to different users over a
long timescale. Such difference at the service level has im-
This research was sponsored by DARPA under contract numbers portant implications on the complexity of the network-level
N66001-96-C-8528 and N00174-96-K-0002, and by a NSF Career Award mechanisms required to implement these services. In par-
under grant number NCR-9624979. Additional support was provided by ticular, to provide Intserv, each router needs to support a
Intel Corp., MCI, and Sun Microsystems. Views and conclusions con-
flow level signaling protocol such as RSVP [32], maintain
tained in this document are those of the authors and should no be inter-
preted as representing the official policies, either expressed or implied, of per flow state, and perform scheduling and manage buffers
DARPA, NSF, Intel, MCI, Sun, or the U.S. government. on a per flow basis. Since there can be a large number of
1flows in the Internet, it is an open question whether Intserv However, as the spatial granularity becomes larger than
can be implemented in a scalable fashion. Diffserv, on the one destination, it is more difficult to support a service with
other hand, pushes the complexity to the network edge, and a fixed bandwidth profile. In this situation, there is a fun-
requires very simple priority scheduling/dropping mecha- damental conflict between maximizing resource utilization
nisms inside the core. An important property of the Diffserv and achieving a high service assurance. Since the network
schemes considered in this paper is that each router treats does not know in advance where the packets will go, in or-
identically all packets which have the same bits set. That der to provide high service assurance, it needs to provision
is, routers only distinguish a small number of aggregated enough resources to all possible destinations. This will re-
classes of packets, where a class represents all packets with sult in a severe resource under-utilization.
the same marking. In this paper, we show that by defining service profiles in
Existing Diffserv schemes are based on the concept of terms of the amount of resource tokens rather than the ab-
service profile. From the service’s point of view, there are solute bandwidth, we can design dynamic and flexible net-
three aspects that a Diffserv model needs to specify [3, 4]: work control algorithms that can achieve high resource uti-
semantics of the service profile: what exactly is pro-
lization, while at the same time delivering in-profile packets
with high probability. The key aspect of the model is that
vided to the customer (user)? the service differentiation is based on resource tokens rather
spatial granularity of the service: is the service pro- than the exact amount of bits per second. The amount of re-
file applied to traffic destined to a single destination, source tokens charged for each bit is a dynamic function of
a group of destinations, all nodes of an ISP, or every- the path and the congestion level. This avoids the worst-
where in the Internet? case provisioning dilemma faced by existing solutions. In
addition, as we will discuss in Section 4, our scheme can
level of assurance: how likely is an in-profile packet to also be used to implement differential services with service
be delivered to the destination? profiles defined in terms of absolute bandwidth.
The rest of the paper is organized as follows. In Section 2
Two examples of differential service models are the As- describes our model based on resource tokens and proposes
sured Service proposed by Clark and Wroclawski [3, 4] and a set of mechanisms to implement the model. Section 3
the Premium Service proposed by Jacobson et. al [22]. The presents simulation experiments to demonstrate the effec-
Premium Service provides the equivalent of a dedicated link
tiveness of our solution. Section 4 justifies the new service
of fixed bandwidth between two edge nodes. The main ad-
model and discusses possible ways for our scheme to imple-
vantage of the Premium Service over the current Intserv ment other differential service models. Finally, in Section 5
models such as guaranteed or controlled load is its imple- we present the related work, and in Section 6 we summarize
mentation simplicity – it does not require per flow manage- our contributions.
ment at core routers.
The Assured Service supports coarse spatial granularity, 2 LIRA: Service Differentiation based on Re-
i.e., service profiles are applied to traffic defined to more source Right Tokens
than one destination. It is important to notice that in addi-
tion to the implementation simplicity, the Assured Service In this section, we present our differential service model,
also provides a service semantic that is richer than those called LIRA (Location Independent Resource Accounting),
provided by the existing Intserv models. For example, while with service profiles defined in terms of resource tokens
Intserv and Premium services are better suited for steady rather than absolute amounts of bandwidth.
and long-lived traffic, the Assured Service provides better We consider the following simple two bits encoding
support for traffic aggregates that consist of many short- scheme. The first bit, called the preferred bit, is set by the
lived bursty flows with different destinations (such as WEB application or user and indicates the dropping preference of
traffic). the packet. The second bit, called marking bit, is set by the
We believe that a service model with a coarse spatial ingress routers of an ISP and indicates whether the packet
granularity embodies some of the fundamental motivations is in- or out-of profile. More precisely, when a preferred
behind the design of the Assured Service. The coarse spa- packet arrives at an ingress node, the node marks it if the
tial granularity leads to a smaller number of service pro- user has not exceeded its profile; otherwise the packet is
files, which in turn improves the scalability by reducing the left unmarked1. The reason to use two bits instead of one is
amount of state needed at the edge of the network. In addi- that in an Internet environment with multiple ISPs, even if
tion, service profiles with coarser spatial granularities also a packet may be out-of profile in some ISPs on the earlier
mean higher traffic aggregation for each profile, which al- portion of its path, it may still be in-profile in a subsequent
lows users to achieve a higher degree of statistical multi- 1 In the paper, we will use the terminology of marked or unmarked pack-
plexing gain. ets to refer to packets in or out-of the service profile, respectively.
2ISP. Having a dropping bit that is unchanged by upstream dropped, or treated as best effort. Informally, our goal at
ISPs on the path will allow downstream ISPs to make the the user level is to ensure that users with “similar” com-
correct decision. Core routers implement a simple behavior munication patterns receive service (in terms of aggregate
of priority dropping. Whenever there is a congestion, a core marked traffic) in proportion to their token rates.
router always drops unmarked packets first. The crux of the problem then is the computation and dis-
In this paper, we focus on mechanisms for implementing tribution of the per marked bit cost for each path. In this
LIRA in a single ISP. We assume the following model for section, we first present the algorithm to compute the cost
the interaction of multiple ISPs: if ISP A is using the service of each marked bit for a single link, and next present an
of ISP B, then ISP B will treat ISP A just like a regular user. algorithm that computes and distributes the per-path cost
In particular, the traffic from all ISP A’s users will be treated of one marked bit by leveraging existing routing protocols.
as a single traffic aggregate. We then argue that this dynamic cost information is also
useful for multi-path routing and load balancing purposes.
2.1 LIRA Service Model
To avoid route oscillation and packet reordering within one
With LIRA, each user i is assigned a service profile that application-level flow, we introduce two techniques. First,
is characterized by a resource token bucket (ri ; bi), where a lightweight scheme is devised to ensure that all packets
ri represents the resource token rate, and bi represents the from the same application-level flow always travel the same
depth of the bucket. Unlike traditional token buckets where path. The scheme is lightweight in the sense that no per
each preferred bit entering the network consumes exactly flow state is needed in any core routers. Second, rather than
one token, with resource token buckets the number of to- using a simple greedy algorithm that always selects the path
kens needed to admit a preferred bit is a dynamic function with the current lowest cost, we use a probabilistic scheme
of the path it traverses. to enhance system stability.
Although there are many functions that can be used, we
consider a simple case in which each link i is associated a 2.2 Link Cost Computation
cost, denoted ci (t), which represents the amount of resource A natural goal in designing the link cost function in LIRA
tokens charged for sending a marked bit along the link at is to avoid marked packets being dropped. Since in the
P
time t. The cost of sending a marked packet is computed
as i2P L ci(t), where L is the packet length and P is
worst case all users can compete for the same link at the
same time, a sufficient condition is to have a cost func-
the set of links traversed by the packet. While we focus on tion that exceeds the number of tokens in the system when
unicast communications in this paper, we note that the cost the link utilization approaches unity. Without bounding the
function is also naturally applicable to the case of multicast. number of tokens in the system, this suggests a cost function
As we will show in Section 3, charging a user for every that goes to infinity when the link utilization approaches
link it uses and using the cost in routing decisions help to unity. Among many possible cost functions that exhibit this
increase the network throughput. In fact, it has been shown property, we choose the following one:
c(t) = 1 ,au(t) ;
in [19] that using a similar cost function2 for performing
the shortest path routing gives the best overall results when (1)
compared with other dynamic routing algorithms.
It is important to note that the costs used in this paper are where a is the fixed cost of using the link3 when it is idle,
not monetary in nature. Instead they are reflecting the level and u(t) represents the link utilization at time t. In partic-
of congestion and the resource usage along links/paths. This ular, u(t) = R(t)=C , were R(t) is the traffic throughput at
is different from pricing which represents the amount of time t, and C represents the link capacity. Recall that c(t)
payment made by an individual user. Though costs can pro- is measured in tokens/bit and represents how much a user is
vide valuable input to pricing policies, in general, there is charged for sending a marked bit along that link at time t.
no necessary direct connection between cost and price. In an ideal system, where costs are instantaneously dis-
Figure 1 illustrates the algorithm performed by ingress tributed and the rate of the incoming traffic varies slowly,
nodes. When a preferred packet arrives at an ingress node, a cost function as defined by Eq. (1) guarantees that no
the node computes its cost based on the packet length and marked packets are dropped inside the core. However, in
the path it traverses. If the user has enough resource to- a real system, computing and distributing the cost informa-
kens in its bucket to cover this cost, the packet is marked, tion incur overhead, so they are usually done periodically.
admitted in the network, and the corresponding number of In addition, there is always the issue of propagation delay.
resource tokens is subtracted from the bucket account. Oth- Because of these, the cost information used in admitting
erwise, depending on the policy, the packet can be either packets at ingress nodes may be obsolete. This may cause
2 It can be shown that when all links have the same capacity our cost 3 In practice, the network administrator can make use of a to encour-
is within a constant factor from the cost of shortest-dist(P, 1) algorithm age/discourage the use of the link. Simply by changing the fixed cost a, a
proposed in [19]. link will cost proportionally more or less at the same utilization.
3r
l c5 dst
Ingress Node Alg.
c4
c3
upon packet arrival :
c2 bit_cost = c1 + c2 + c3 + c4 + c5;
c1 packet_cost = packet_length * bit_cost;
if (preferred(packet) && l > packet_cost)
mark(packet);
l −= packet_cost;
r = resource token rate
l = current bucket level
ci = per bit cost of link i
Figure 1. When a preferred packet arrives, the node computes the packet’s cost, and the packet is
marked if there are sufficient resource tokens.
packet dropping, and lead to oscillations. Though oscilla- 2.3 Path Cost Computation and Distribution
tions are inherent to any system in which the propagation
In LIRA, the cost of a marked bit over a path is the sum
of the feed-back information is non-zero, the sensitivity of
of the costs of a marked bit over each link on the path. Once
our cost function when the link utilization approaches unity
the cost for each link is computed, it is easy to compute and
makes things worse. In this regime, an incrementally small
distribute the path cost by leveraging existing routing proto-
traffic change may result in an arbitrary large cost change.
cols. For link state algorithms, the cost of each marked bit
In fact one may note that Eq. (1) is similar to the equa-
can be included as part of the link state. For distance vector
tion describing the delay behavior in queueing systems [18],
algorithms, we can pass and compute the partial path cost
which is known to lead to system instability when used as a
in the same way the distance of a partial path is computed
congestion indication in a heavily loaded system.
with respect to the routing metric.
To address these issues, we use the following iterative
b
formula to compute the link cost: 2.4 Multipath Routing and Load Balancing
c(ti ) = a + c(ti,1 ) R(ti; ti,1) :
C (2) Since our algorithm defines a dynamic cost function that
b
reflects the congestion level of each link, it is natural to use
where R(t0 ; t00) denotes the average bit rate of the marked this cost function for the purpose of multi-path routing. In
traffic during the time interval [t0; t00). It is easy to see that if this paper, we compute the k shortest paths for each des-
the marked traffic rate is constant and equal to R, the above tination or egress node using unit link metric. While the
iteration converges to the cost given by Eq. (1). The main obvious solution is to send packets along the path with the
advantage of using Eq. (2) over Eq. (1) is that it is more minimum cost (in the sense of LIRA, see Section 2.1) among
robust against large variations in the link utilization. In par- the k paths, this may introduce two problems: (a) packet re-
ticular, when the link utilization approaches unity the cost ordering within one application-level flow, which may neg-
increases by at most a every iteration. In addition, unlike atively affect end-to-end congestion control algorithms, and
b
Eq. (1), Eq. (2) is well defined even when the link is con- (b) route oscillation, which may lead to system instability.
gested, i.e., R(ti,1; ti ) = C . We introduce two techniques to address these problems.
Unfortunately, computing the cost by using Eq. (2) is not First, we present a lightweight mechanism that binds a flow
as accurate as by using Eq. (1). The link may become and to a route so that all packets from the flow will traverse the
remain congested for a long time before the cost increases same route. Second, to reduce route oscillation, for each
large enough to reduce the arrival rate of marked bits. This new flow, an ingress node probabilistically binds it to one of
may result in the loss of marked packets, which we try to the multiple routes. By carefully selecting the probability,
avoid. To address this problem we use only a fraction of the we can achieve both stability and load-balancing.
link capacity, C = C , for the marked traffic, the remain-
ing being used to absorb the unexpected variations due to
2.4.1 Forwarding Algorithm For Multiple Path Rout-
inaccuracies in the cost estimation4. In this paper we chose
ing
between 0.85 and 0.9.
4 is similar to the pressure factor used in some ABR congestion con- As discussed earlier, we will maintain multiple routes for
trol schemes for estimating the fair share [14, 25]. each destination. However, we would like to ensure that all
4ROUTING TABLE
FORWARDING TABLE FORWARDING TABLE
dst cost label label dst next hop label dst next hop
id5 7 id2 id3 id5 id3 id5 id5 id3
8 id2 id4 id5 id5 id5 id5
. . . id4 id5 id5 id4 . . .
. . . . . .
. . . . . . . . .
. . .
. . .
FORWARDING TABLE
label dst next hop
id2 id3 id5 id5 id2
id2 id4 id5 id5 id2
. . .
. . .
. . .
id3
3
1
id1 id2 id5
3
3 2
id4
label = id2 id3 id5
label = id2 label = id3 id5 label = id3 label = id5
Figure 2. Example of route binding via packet labeling.
packets belonging to the same flow are forwarded along the Besides the destination and the route cost, each entry in
same path. the routing table also contains the label associated with that
The basic idea is to associate with each path a label com- path.
puted as the XOR over the identifiers of all routers along the
path, and then associate this label with each packet of a flow
< dst; < cost(1) ; l(1) >; : : : < cost(k) ; l(k)) >> (4)
that goes along that path. Here we use the IP address as the Similarly, the forwarding table should contain an entry for
identifier. More precisely, a path P = (id0 ; id1; : : :; idn), each path:
where id0 is the source and idn is the destination, is en-
coded at the source (id0 ) by l0 = id1 id2 : : : idn . < l(1) ; dst; next hop(1) > : : : < l(k) ; dst; next hop(k) > (5)
Similarly, the path from id1 to idn is encoded at id1 by
l1 = id2 : : : idn . A packet that travels along path P In Figure 2 we give a simple example to illustrate this
mechanism. Assume that nodes id1 and id5 are edge nodes,
is labeled with l0 as it is leaving id0 , and with l1 as it is
and there are two possible paths from id1 to id5 of costs
leaving d1 . By using XOR we can iteratively re-compute
7, and 8, respectively. Now, assume a packet destined to
the label based on the packet’s current label and the node
identifier. As an example, consider a packet that is assigned
id5 arrives at id1 . First the ingress node id1 searches the
label l0 at node id0. When the packet arrives at node id1 ,
classifier table (not shown in the Figure), that maintains a
list of all flows, to see whether this is the first packet of a
the new label corresponding to the remaining of the path,
(id1; : : :; idn), is computed as follows:
flow. If it is, the router uses the information in the routing
table to probabilistically bind the flow to a path to id5. At
l1 = id1 l0 = (3) the same time it labels the packet with the encoding of the
id1 (id1 id2 : : : idn ) = id2 : : : idn: selected route. In our example, assume the path of cost 7,
i.e., (id1 ; id2; id3; id5), is selected. If the arriving packet
It is easy to see that this scheme guarantees that the packet is not the first packet of the flow, the router automatically
will be forwarded exactly along the path P . Here, we im- labels the packet with the encoding of the path to which the
plicitly assume that all alternate paths between two end- flow is bound. This can be simply achieved by keeping a
nodes have unique labels. Although theoretically there is copy of the label in the classifier table. Once the packet is
a non-zero probability that two labels may collide, we be- labeled, the router checks the forwarding table for the next
lieve that for practical purposes it can be neglected. hop by matching the packet’s label and its destination. In
Next we give some details of how this mechanism can our case, this operation gives us id2 as the next hop. When
be implemented by simply extending the information main- the packet arrives at node id2 the router first computes a
tained by each router in the routing and forwarding tables. new label based on the current packet label and the router
5identifier: label = id2 label. The new label is then used d0
to lookup the forwarding table.
r0 r1
It is important to note that the above algorithm assumes
per flow state only at ingress nodes. Inside the core, there
is no per flow state. Moreover, the labels can speed-up the
table lookup if used as hash keys. d1
2.4.2 Path Selection Figure 3. Topology to illustrate the label and
cost aggregation.
While the above forwarding algorithm ensures that all pack-
ets belonging to the same flow traverse the same path, there
not keep state for the individual routes to d0, and d1 re-
is still the issue of how to select a path for a new flow. The
biggest concern with any dynamic routing protocol based
spectively, we need to aggregate the cost to these two des-
on congestion information is its stability. Frequent route
tinations. In doing this, a natural goal would be to main-
changes may lead to oscillations.
tain the total charges the same as in a reference system
that keeps per route state. Let R(r1 ; di) denote the aver-
To address this problem, we associate a probability with
age traffic rate from r1 to di, i = 1; 2. Then, in the refer-
each route and use it in binding a new flow to that route.
The goal in computing this probability is to equalize the
ence system that maintains per route state, the total charge
per time unit for the aggregate traffic from r1 to d0 and d1
costs along the alternate routes, if possible. For this we use
is: cost(r1 ; d0)R(r1; d0) + cost(r1 ; d1)R(r1 ; d1). In a sys-
a greedy algorithm. Every time the route costs are updated
we split the set of routes in two equal sets, where all the
tem that does not maintain per route state, the charge for
the same traffic is cost(r1 ; d0; d1)(R(r1 ; d0) + R(r1; d1)),
routes in one set have costs larger than the routes in the
where cost(r1 ; d0; d1) denotes the per bit aggregate cost.
second set. If there is an odd number of routes, we leave
the median out. Then, we decrease the probability of ev-
This yields
cost(r1 ; d0; d1) = Rcost (r1 ; d0)R(r1 ; d0)
ery route in the first set, the one which contains the higher
cost routes, and increase the probability of each route in the + (6)
second set by a small constant . It can be shown that in a (r1; d0) + R(r1; d1)
steady-state system, this algorithm converges to the optimal cost(r1 ; d1)R(r1 ; d1) :
solution within . R(r1; d0) + R(r1; d1)
2.5 Algorithm Scalability Thus, any packet that arrives at r0 and has either destination
d0 or d1 is charged with cost(r0 ; r1)+ cost(r1 ; d0; d1). Ob-
As described so far, our scheme requires to maintain k viously, route aggregation increases the inaccuracies in cost
entries for each destination in both the forwarding table estimation. However, this may be alleviated by the fact that
used by the forwarding engine and the routing table used the route aggregation usually exhibits high localities.
by the routing protocol, where k is the maximum number Another problem with address aggregation is that a label
of alternate paths. While this factor may not be significant can no longer be used to encode the entire path to the desti-
if k is small, a more serious issue that potentially limits nation. Instead, it is used to encode the common portion of
the scalability of the algorithm is that in the vanilla form the paths to the destinations in the aggregate set. This means
it requires to maintain an entry for each destination, where that a packet should be relabeled at every router that per-
in reality, to achieve scalability, routers really maintain the forms aggregation involving the packet’s destination. The
longest-prefix of a group of destinations that share the same most serious concern with this scheme is that it requires to
route [11]. Since our algorithm works in the context of one maintain per flow state and perform packet classification at
ISP, we can maintain an entry for each egress node instead a core router (r1 in our example). Fortunately, this scalabil-
of each destination. We believe this is sufficient as the num- ity problem is alleviated by the fact that we need to keep per
ber of egress nodes in an ISP is usually not large. flow state only for the flows whose destination addresses are
However, assume that the number of egress nodes in aggregated at the current router. Finally, we note that this
an ISP is very large so that significant address aggrega- problem is not specific to our scheme; any scheme that (i)
tion is needed. Then we need to also perform cost ag- allows multiple path routing, (ii) performs load balancing,
gregation. To illustrate the problem consider the exam- and (iii) avoids packet reordering has to address it.
ple in Figure 3. Assume the addresses of d0 and d1 are
aggregated at an intermediate router r1. Now the ques- 3 Simulation Experiments
tion is how much to charge a packet that enters at the In this section we evaluate our model by simulation. We
ingress node r0 and has the destination d0. Since we do conduct four experiments: three involving simple topolo-
6Throughput (Mbps)
Throughput (Mbps)
4.38 4.40
11
00
3.88 00
11
00
11
00
11
3.13 11
00
S2 S3
00 3.05 3.06
11 00
11
2.83 11
00 00
11
2.78
00 11
11 00 1100 00 11
11 00 2.45
00
11
00 11
11 00 00
11 00
11 00
11
link 2 link 3 00
11 00
11
00
11 00
11
00
11 00 11
11 00
00 11
11 00
00 11
11 00 00
11 00
11
00 11
11 00 00
11
00
11
00
11 00
11 00
11 00 11
11 00 11
00
00
11
00
11
00 11
11 00
11 00
11 00
11
00
11 00
11
00
00 11
11 00
11 00 11
11 00 00
11
link 4 00 00
11 00
11
00
11 00
11 00
11 00
11
00
11
00
11 00 11
11 00
00
11 00 11
11
00
11 00 11
00
00 11
111111111
000000000 00
S1
link 1 link 5 link 6
D1 00
11 00
11 00
11 00 11
11 00
11
S1 S2 S3 S1 S2 S3 S1 S2 S3
(a) BASE STATIC STATIC
1best-effort
0 1in-profile 1
0 0out-of profile 1in-profile 1
0 0out-of profile
0
1 0
1 0
1 0
1 0
1
(b) (c)
Figure 4. (a) Topology used in the first experiment. Each link has 10 Mbps capacity. S 1, S 2, and S 3
send all their traffic to D1. (b) The throughputs of the three users under BASE and STATIC schemes.
(c) The throughputs under STATIC when the token rate of S 2 is twice the rate of S 1/S 2.
gies which help to gain a better understanding of the be- routing protocol uses the number of hops as the dis-
havior of our algorithms, and one more realistic example tance metric and it is implemented by either DV or
with a larger topology and more complex traffic patterns. SPF. This scheme does not implement service differ-
The first experiment shows that if all users share the same entiation, i.e., both marked and unmarked packets are
congested path, then each user receives service in propor- identically treated.
tion to its resource token rate. This is the same result one
would expect from using a weighted fair queueing sched- STATIC – this scheme implements the same static
uler on every link, with the weights set to the users’ token routing as BASE. In addition, it implements LIRA by
rate. In the second experiment, we show that by using dy- computing the link cost as described in Section 2.2,
namic routing and load balancing, we are able to achieve and marking packets at each ingress node according to
the same result – that is, each user to receive service in pro- the algorithm shown in Figure 1.
portion to its token rate – in a more general configuration
where simply using weighted fair queueing scheduler on ev-
DYNAMIC-k – this scheme adds dynamic routing and
load balancing to STATIC. The routing protocol uses a
ery link is not sufficient. In the third experiment, we show
modified versions of DV/SPF to find the first k short-
how load balancing can significantly increase the overall re-
source utilization. Finally, the fourth experiment shows how est paths. Note that DYNAMIC-1 is equivalent to
the behaviors observed in the previous experiments scale to STATIC.
a larger topology.
Each router implements a FIFO scheduling discipline
3.1 Experiment Design with a shared buffer and a drop-tail management scheme.
We have implemented a packet level simulator which When the buffer occupancy exceeds a predefined threshold,
supports both Distance Vector (DV) and Shortest Path First newly arrived unmarked packets are dropped. Thus, the en-
(SPF) routing algorithms. To support load balancing we ex- tire buffer space from the threshold up to its total size is
tended these algorithms to compute the k-th shortest paths. reserved to the in-profile traffic5. Unless otherwise speci-
The time interval between two route updates is uniformly fied, throughout all our experiments we use a buffer size of
distributed between 0:5 and 1:5 of the average value. As 256 KB and a threshold of 64 KB.
shown in [10] this choice avoids the route-update self- The two main performance indices that we use in com-
synchronization. In SPF, when a node receives a routing paring the above schemes are the user in-profile and user
message, it first updates its routing table and then forwards overall throughputs. The user in-profile throughput repre-
the message to all its neighbors, excepting the sender. The 5 We note that this scheme is a simplified version of the RIO buffer
routing messages are assumed to have high priority, so they management scheme proposed by Clark and Wroclawski [4]. In addition,
are never lost. In the followings we compare the following RIO implements a Random Early Detection (RED) [9] dropping policy,
schemes: instead of drop-tail, for both in- and out-of profile traffic. RED provide an
efficient detection mechanism for the adaptive flows, such as TCP, allowing
BASE – this scheme models today’s best-effort Inter-
them to gracefully degrade their performances when congestion occurs.
However, since in this study we are not concerned with the behavior of
net, and it is used as a baseline in our comparison. The individual flows, for simplicity we chose to not implement RED.
78.74 8.74
11best-effort
00
Throughput (Mbps)
00
11
11
00 00in-profile
11
00
11 00
11
00
11
00
11 00out-of profile
11
S4 00
11 00
11
00
11
00
11
00
11
00
11
00
11
00
11 5.22
00
11 4.89 4.90 4.96
00
11 11
00
00
11 000
111 000 11
111 00
00
11 000 11
111 00
000
111 00
11
S3 00
11
00
11 000 11
111 00
000 11
111
00
11 00
000 11
111 00
link 2 link 3 D3 3.52 3.32 3.32 3.35 11
00 000
111 00
11
000
111
000 11
111 00
11
00
11 000
111 00
000 11
111 00
3.25 3.21
00 1100 00
11 00
11
00 11
11 00 11 00
11 000
111
000 11
111 00 00
11
00 11
11 00
00 11
11 00
11
00 1100 000
111
000
111
000 11
111 00
000 11
111
00
11 00
00
11
S2 D2 00
11
00 1100 1100 1100 111 000
111
000 11
00
link 1 11
00
11 00
11 00
11
00 11
00
11
00 000
111 000 11
111
00
11 00
00
11
00 11
11 00 11 00
11 000
111
000 11
111 00 00
11
00 11
11 00
00 11
11 00
11
00 1100 000
111
000
111
000 11
111 00
000 11
111
00
11 00
00
11
00
11
00 1100 1100 1100 000
111
000 11
111 00
11 000 11
00
S1 D1 00
11
00
11 00
11 000
111 111
00
11
00
11
00 11
11 00 11
00
11
00 11
00
11
00
00
11 111 000 11
111
000 11
00 00
00
11
00
11 00 11
11 00 1100 111 000
111
000 11
00
000 11
111 00
(a) 11
00 1100 1100 1100 000 11
111 00
000 11
111 00
000 11
111 00 00
11
S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4
BASE STATIC DYNAMIC-2
(b)
Figure 5. (a) Topology used in the second experiment. S 1, S 2, S 3, and S 4 send all their traffic to D1,
D2, and D3, respectively. (b) The throughputs of all users under BASE, STATIC, and DYNAMIC-2.
sents the rate of the user aggregate in-profile traffic deliv- at time t = 50 sec.
ered to its destinations. The overall throughput represents
the user’s entire traffic — i.e., including both the in- and 3.2 Local Fairness and Service Differentiation
out-of profile traffic — delivered to its destinations. In ad- This experiment shows that if all users send their traffic
dition, we use user dropping rate of the in-profile traffic to along the same congested path, they get service in propor-
characterize the level of service assurance. tion to their token rate, as long as there is enough demand.
Recent studies have shown that the traffic in real net- Consider the topology in Figure 4(a), where users S 1, S 2,
works exhibits the self-similar property [5, 23, 24, 30] — and S 3 send traffic to D1. Figure 4(b) shows the user over-
that is, the traffic is bursty over widely different time scales. all throughputs over the entire simulation under BASE. As
To generate self-similar traffic we use the technique origi- it can be seen, S 1 gets significantly more than the other
nally proposed in [30], where it was shown that the super- two. In fact, if the traffic from all sources were continuously
position of many ON-OFF flows with ON and OFF periods backlogged, we expect that S 1 to get half of the congested
drawn from a heavy tail distribution, and which have fixed links 5 and 6, while S 2 and S 3 to split the other half. This
rates during the ON period results in self-similar traffic. In is because even though each user sends at an average rate
particular, in [30] it is shown that the aggregation of several higher than 10 Mbs, the queues are not continuously back-
hundred of ON-OFF flows is a reasonable approximation of logged. This is due to the bursty nature of the traffic and
the real end-to-end traffic observed in a LAN. due to the limited buffer space at each router.
In all our experiments, we generate the traffic by draw- Next, we run the same simulation for the STATIC
ing the length of the ON and OFF periods from a Pareto scheme. To each user we assign the same token rate, and
distribution with the power factor of 1:2. During the ON to each link we associate the same fixed cost. Figure 4(b)
period a source sends packets with sizes between 100 bytes shows the user overall and in-profile throughputs. Com-
and 1000 bytes. The time to send a packet of minimum pared to BASE, the overall throughputs are more evenly
size during the ON period is assumed to be the time unit in distributed. However, the user S 1 still gets slightly better
computing the length of the ON and OFF intervals. service, i.e., its in-profile throughput is 3.12 Mbps, while
Due to the high overhead incurred by a packet-level sim- the in-profile throughput of S 2/S 3 is 2.75 Mbps. To see
ulator, such as ours, we limit the link capacities to 10 Mbps why, recall from Eq. (1) that link cost accurately reflects the
and the simulation time to 200 sec. We set the average inter- level of congestion on that link. Consequently, in this case
val between routing updates to 5 sec for the small topologies links 5 and 6 will have the highest cost, followed by link
used in the first three experiments, and to 3 sec for the large 4, and then the other three links. Thus, S 2 and S 3 have to
topology used in the last experiment. In all experiments, “pay” more than S 1 per marked bit. Since all users have the
the traffic starts at time t = 20 sec. The choice of this time same token rates, this translates into lower overall through-
is such that to guarantee that the routing algorithm finds at puts for S 2 and S 3, respectively.
least one path between any two nodes by time t. In order to To illustrate the relationship between the user’s token
eliminate the transient behavior, we start our measurements rate and its performance, we double the token rate of S 2.
8Mean Throughput (Mbps)
Mean Throughput (Mbps)
1
0
0best-effort
1
9.14 1
0
0best-effort
1
S3 7.86 7.98 0
1
0in-profile
1 0
1
0in-profile
1
S2 7.03 7.20
6.95 1
0
0out-of profile
1 1
0
0out-of profile
1
S4 11
00
00
11
111 11
000 000
111 00
11
link 1 000 00
111 00
11 000 11
111 00
S1 000
111
000
111 00
11 000
111 00
11
000
111 00
11 000 11
111 00
00
11
000 11
111 00 000
111
000
111 00
11
link 2 000 11
111 00
00
11 000 11
111 00
link 4 000
111
000 11
111 00 000
111 00
11
S5 000
111 00
11 000 11
111 00
000 11
111 00 000 11
111 00
00
11
S7 000
111 00
11 000
111
000 11
111 00
000
111 00
11 000
111 00
11
000 11
111 00
00
11 000 11
111 00
link 3 000
111
000
111 00
11 000
111 00
11
111 11
000 00 111 11
000 00
S6
STATIC
STATIC
BASE
BASE
DYNAMIC-2
DYNAMIC-2
S8
(a)
(b) (c)
Figure 6. (a) Topology used in the third experiment. Mean throughputs when (b) load is balanced,
and (c) when it is unbalanced, i.e, S3 and S4 are inactive.
Figure 4(c) shows the overall and in-profile throughputs of son for this difference is because when competing with S 4,
each user. In terms of in-profile traffic user S 2 gets roughly the other users have to pay, besides link 3, for link 2 as well.
twice the throughout of S 3 (i.e., 4.27 Mbps vs. 2.18 Mbps). Thus, by taking advantage of the alternate routes, our
Finally, we note that there was no marked packets scheme is able to achieve fairness in a more general setting.
dropped in any of the above simulations. For comparison At the same time it is worth noting that the overall through-
more than 60 % of the out-of profile traffic was dropped. put also increases by almost 7 %. However, in this case,
this is mainly due to the bursty nature of S 4’s traffic which
3.3 User Fairness and Load Balancing
cannot use the entire capacity of link 3 when it is the only
In this section we show how dynamic routing and load one to use it, rather than load balancing.
balancing help to improve user level fairness and achieve
better resource utilization. Consider the topology in Fig- 3.4 Load Distribution and Load Balancing
ure 5 where users S 1, S 2, S 3 and S 4 send traffic to users This experiment shows how the load distribution affects
D1, D2 and D3. Again the fixed costs of all links are equal, the effectiveness of our load balancing scheme. For this
and all users are assigned the same token rate. purpose, consider the topology in Figure 6(a). In the first
Figure 5(b) shows the overall and in-profile through- simulation we generate flows that have the source and the
puts of S 1, S 2, S 3 and S 4 under BASE, STATIC and destination uniformly distributed among users. Figure 6(b)
DYNAMIC-2, respectively. When BASE and STATIC are shows the means of the overall throughputs under BASE,
used, each user sends always along the shortest paths. This STATIC, and DYNAMIC-2, respectively 6 . Due to the uni-
results in S 1, S 2 and S 3 sharing link 1, while S 4 using formity of the traffic pattern, in this case BASE performs
alone link 3. As a consequence S 4 receives significantly very well. Under STATIC we get slightly larger overall
better service than the other three users. Since it imple- throughput, mainly due to our congestion control scheme,
ments the same routing algorithm, STATIC does not im- which admits a marked packet only if there is a high prob-
prove the overall throughputs. However, compared with ability to be delivered. However, under DYNAMIC-2 the
BASE, STATIC guarantees that in-profile packets are deliv- performances degrades. This is because there are times
ered with very high probability (again, in this experiment, when our probabilistic routing algorithm selects longer
no marked packets were dropped). On the other hand, when routes, which leads to inefficient resource utilization.
DYNAMIC-2 is used each user receives almost the same Next, we consider an unbalanced load by making users
service. This is because, now users S 1, S 2 and S 3 can S 3 and S 4 inactive. Figure 6(c) shows throughput means
use both routes to send their traffic, which allow them to under BASE, STATIC, and DYNAMIC-2, respectively. As
compete with user S 4 for link 3. User S 4 still maintains a it can be noticed, using DYNAMIC-2 increases the mean by
slightly advantage, but now the difference between its over- 30 %. This is because under BASE and STATIC schemes
all throughput and the overall throughputs of the other users 6 We have also computed standard deviations for each case: the largest
is less than 7%. In the case of the in-profile traffic this dif- standard deviation was 0.342 for the overall throughput under STATIC
ference is about 5%. As in the previous experiment the rea- scheme, and 0.4 for the in-profile throughput under DYNAMIC-2.
9S3
S4 S5 S7
S6 S8 S9
N11
S10
N3 N4
N2
S2
S15
S19 N5
N1 N10 N9 S18
(b)
S1
S14 S16 S17
N8 N7 N6
S13 S12 S11
(a)
(c)
Figure 7. Topology similar to the T3 topology of the NSFNET backbone network containing the IBM
NSS nodes.
the entire traffic between S 1, S 2 and S 5, S 6 is routed other hand, the dynamic routing and load balancing are not
through links 3 and 4 only. On the other hand, DYNAMIC- effective in this case, since they tend to generate longer
2 takes advantage on the alternate route through links 1 and routes which leads to inefficient resource utilization. This is
2. illustrated by the decrease of the overall and the in-profile
Finally, in another simulation not shown here we con- throughputs under DYNAMIC-2 and DYNAMIC-3, respec-
sidered the scenario in which S 5, S 6, S 7, and S 8 send tively.
their entire traffic to S 3 and S 4, respectively. In this case In the second scenario we assume unbalanced load.
DYNAMIC-2 outperforms almost two times STATIC and More precisely, we consider 11 users (covered by the
BASE both in terms of in-profile and overall throughputs. shaded area in Figure 7(b)) which are nine times more active
This is again because BASE and STATIC use exclusively than the other, i.e., they send/receive nine times more traffic
links 3 and 2, while DYNAMIC-2 uses the other two links than the others.7 Unlike the previous scenario, in terms of
as well. overall throughputs DYNAMIC-2 outperforms STATIC by
almost 8 %, and BASE by almost 20 % (see Figure 8(b)).
3.5 Large Scale Example This is because DYNAMIC-2 is able to use some of the
In this section we consider a larger topology that closely idle links from the un-shaded partition. However, as shown
resembles the T3 topology of the NSFNET backbone con- by the results for DYNAMIC-3, as the number of alternate
taining the IBM NSS nodes (see Figure 7). The major dif- paths increases both the overall and in-profile throughputs
ference is that in order to limit the simulation time we as- start to decrease.
sume 10 Mbps links, instead of 45 Mbps. We consider the In the last scenario we consider the partition of the net-
following three scenarios. work shown in Figure 7(c). For simplicity, we assume
In the first scenario we assume that load is uniformly that only users in the same partition communicate between
distributed, i.e., any two users communicate with the same them. This scenario models a virtual private network (VPN)
probability. Figure 8(a) shows the results for each scheme, setting, where each partition corresponds to a VPN. Again,
results which are consistent with the ones obtained in the DYNAMIC-2 performs the best8 , since it is able to make
previous experiment. Due to the congestion control which 7 This might model the real situation where the east coast is more active
reduces the number of dropped packets in the network, between 9 and 12 a.m. EST, than the west coast.
STATIC achieves higher throughput than BASE. On the 8 The mean of the user overall throughput under DYNAMIC-2 is 15 %
108.10
Mean Throughput (Mbps)
Mean Throughput (Mbps)
Mean Throughput (Mbps)
7.87 7.83 7.79
7.67
7.20 7.43 1
0
0best-effort
1
11 11
00 00
11 11
00
00 00 00
11
00 11
00
6.50
11
00
11 00 11
11 00
00
11 11 00 11
11 00
00
11
6.31 6.09 0
1
0in-profile
1
00 11
11 00
00
11 00
11
00
11
00
11
00
11 00
11
00
11 00
11 5.47
1
0
00
11 00
11 00 11
00 11
11 00 5.32
00
11
00
11
11 00 11
00 11
00
00
11 00
11 00
11 00
11 11
00 00 11
11 00
00
11
0out-of profile
1
00
11 00
11 00
11 00 11
00 11
11 00 00
11 00
11 00
11
00
11 00
11
00
11 00
11 00 11
00 11
11 00
00
11 00
11 00
11
00 11
00
00
11 00
11 00
11 00
11
00 11
00 00 11
11 00
11
00 11
11 00
00
11 00
11
00
11
00 11
11
00
11 00
11 00
11 00
11
00
11
00
11
00
11 00
11
00
11
00
11 00
11 00
11 00
11 00
11 00
11 00 11
11 00
00
11
00 11
11 00
00
11 00
11 00 11
00 11
11 00
00
11 00
11 00 11
11 00
00
11
00
11 00
11 00
11 00
11 00
11 00
11 11 00
11
00 11
00 00
11
00 11
11 00
11 00
11 00
11 00
11 00 11
11 00 11
00
00 00
11 00
11 00
11
00
11
00
11 00
11
00 11
00 11
11 00 00
11 00
11
00 11
11 00
11
00
11
00
11
00
11 00
11 00
11 00
11 00
11 00
11 00
11 00 00
11
00
11 00
11 00
11 00
11 00 11
00
11 00 11
00 11 00
00
11 11 11 11
00 00 00 11 00 11
11 00
STATIC
STATIC
STATIC
BASE
BASE
BASE
DYNAMIC-2
DYNAMIC-3
DYNAMIC-2
DYNAMIC-3
DYNAMIC-2
DYNAMIC-3
(a) (b) (c)
Figure 8. The throughputs when the load is balanced (Figure 7(a)), (b) unbalanced ((Figure 7(b)), and
(c) when the network is virtually partitions (Figure 7(c)).
use of some links between partitions that otherwise would in the last scenario the percentage decreases from 0.129 %
remain idle. for STATIC, to 0.101 % for DYNAMIC-2, and to 0.054 %
Finally, we note that across all simulations presented in for DYNAMIC-3.
this section the dropping rate for the marked packets was
4 Discussion
never larger than 0.3 %. At the same time the dropping rate
for the unmarked packets was over 40 %. In this paper, we have studied a differential service
model, called LIRA, in which the service profile is specified
3.6 Summary of Results in terms of resource tokens instead of absolute bandwidth.
Although the experiments in this section are far from be- Since the exact bandwidth of marked bits that a customer
ing exhaustive, we believe that they give a reasonable image can receive from such a service is not known a priori, a nat-
of how our scheme performs. First, our scheme is effec- ural question to ask is why such a service model is interest-
tive in providing service differentiations at the user level. ing.
Specifically, the first two experiments show that users with There are several reasons. First, we believe that the apri-
similar communication patterns get service in proportion to ori specification of an absolute amount of bandwidth in the
their token rates. Second, at least for the topologies and the service profile, though desirable, is not essential. In par-
traffic model considered in these experiments, our scheme ticular, we believe that the essential aspects that distinguish
ensures that marked packets are delivered to the destination Diffserv from Intserv are the followings: (a) the service pro-
with high probability. file is used for traffic aggregate much coarser than per flow
Consistent with other studies [19], these experiments traffic, and (b) the service profile is defined over a timescale
show that performing dynamic routing and load balancing larger than the duration of individual flows, i.e. service pro-
make little sense when the load is already balanced. In file is rather static. Notice that the degree of traffic aggre-
fact, doing dynamic routing and load balancing can actually gation directly relates to the spatial granularity of the ser-
hurt, since, as noted above, this will generate longer routes vice profile. On the one hand, if each service profile is
which may result in inefficient resource utilization. How- defined for only one destination, we have the smallest de-
ever, when the load is unbalanced, using DYNAMIC-k can gree of traffic aggregation. If there are N possible egress
significantly increase the utilization and achieve a higher nodes for a user, N independent service profiles need to be
degree of fairness. defined. Network provisioning is relatively easy as the en-
Finally, we note that the in-profile dropping rate de- tire traffic matrix between all egress and ingress nodes is
creases as the the number of alternate paths increases. For known. However, if a user has a rather dynamic distribu-
example in the last experiment in the first two scenarios the tion of egress nodes for its traffic, i.e., the amount of traffic
dropping rate is no larger than 0.3 % under STATIC and 0 destined to each egress node varies significantly, and the
under DYNAMIC-2 and DYNAMIC-3, respectively, while number of possible egress nodes is large, such a scheme
will significantly reduce the chance of statistical sharing.
larger than under STATIC, and 18 % larger than under BASE. On the other hand, if each service profile is defined for all
11egress nodes, we have the largest degree of traffic aggrega- a fixed token rate. Both the user and the ISP can perform
tion. Only one service profile is needed for each user re- this measurement. In fact, this suggests two possible sce-
gardless the number of possible egress nodes. In addition to narios in which LIRA can be used to provide a differential
a smaller number of service profiles, such a service model service with an expected capacity defined in terms of ab-
also allows all the traffic from the same user, regardless of solute bandwidth. In the first scenario, the service is not
its destinations, to statistically share the same service pro- transparent. Initially, the ISP will provide the user with the
file. The flip side is that it makes it difficult to provision following relationship
network resources. Since the traffic matrix is not known
apriori, the best-case scenario is when the network traffic is expected capacity = f (token rate; traffic mix) (7)
evenly distributed, and the worst-case scenario is when all
traffic goes to the same egress router. based on its own prior measurement. The user will measure
Therefore, it is very difficult, if not impossible, to design the expected capacity and then make adjustments by asking
service profiles that (1) are static, (2) support coarse spatial for an increase or a decrease in its resource token rate. In
granularity, (3) are defined in terms of absolute bandwidth, the second scenario, the service is transparent. Both the
and at the same time achieve (4) high service assurance and initial setting and the subsequent adjustments of the service
(5) high resource utilization. Since we feel that (1), (2), (4) profile in terms of number of token rate will be made by the
and (5) are the most important for differential services, we ISP only.
decide to give up (3). Therefore, one way of thinking about our scheme is that
Fundamentally, we want a service profile that is static it provides a flexible and efficient framework for imple-
and egress node/path independent. However, to achieve menting a variety of Assured Services. In addition, the
high utilization, we need to explicitly address the fact that dynamic link cost information and the statistics of the re-
congestion is a local and dynamic phenomenon. Our so- source token bucket history provide good feedback both for
lution is to have two levels of differentiation: (a) the user individual applications to perform runtime adaptation, and
or service-profile level differentiation, which is based on for the user or the ISP to do proper accounting and provi-
resource token arrival rate. This is static and path inde- sioning.
pendent; (b) the packet level differentiation, which is a
simple priority between marked and unmarked packets and 5 Related Work
weighted fair share among marked packets. By dynamically Our work is highly influenced by Clark and Wro-
setting the cost of each marked bit as a function of the con- clawski’s Assured Service proposal [3, 4]. The key differ-
gestion level of the path it traverses, we set up the linkage ence is that we define service profiles in units of resource
between the static/path-independent and the dynamic/path- tokens rather than absolute bandwidth. In addition, we pro-
dependent components of the service model. pose a resource accounting scheme and an integrated set of
A second reason for which our service model may be ac- algorithms to implement our service model.
ceptable is that users may care more about the differential Another related proposal is the User-Share Differentia-
aspect of the service than the guaranteed bandwidth. For tion (USD) [29] scheme, which does not assume absolute
example, if user A pays twice as much as user B, user A bandwidth profiles either. In fact, with USD, a user is as-
would expect to have roughly twice as much traffic deliv- signed a share rather than a token-bucket-based service pro-
ered as user B during congestion if they share same con- file. For each congested link in the network traversed by the
gested links, which is exactly what we accomplish in LIRA. user’s traffic, the user shares the bandwidth with other users
A third reason for which a fixed-resource-token-rate- in proportion to its share. The service provided is equiva-
variable-bandwidth service profile may be acceptable is lent to one in which each link in a network implements a
that the user traffic is usually bursty over multiple time- weighted fair queueing scheduler where the weight is the
scales[5, 23, 30]. Thus, there is a fundamental mismatch user’s share. With USD, there is little correlation between
between an absolute bandwidth profile and the bursty na- the share of a user and the aggregate throughput it will re-
ture of the traffic9. ceive. For example, two users that are assigned the same
We do recognize the fact that it is desirable for both the share can see drastically different aggregate throughputs.
user and the ISP to understand the relationship between the A user that has traffic for many destinations (thus traverse
user’s resource token rate and its expected capacity. This many different paths) can potentially receive much higher
can be achieved by measuring the rate of marked bits given aggregate throughput than a user that has traffic for only a
few destinations.
9 Some recent measurements show that the aggregate traffic over Inter-
There is a huge body of related work that addresses the
net backbone links are not very bursty. We note that this is not inconsistent
with the observations that the aggregate traffic from a campus to the Inter- resource allocation problem both for single and multiple re-
net exhibits long range dependency. sources. However, to the best of our knowledge, none of
12the existing proposals address the problem of allocating re- bandwidth allocation between competing streams with elas-
sources for traffic aggregate that has a large spatial gran- tic traffic. In particular, they propose a mathematical model
ularity. In general, they are limited in scope to allocating to analyze the stability and fairness of a class of rate con-
resources along individual paths only. In addition, these trolled algorithms. In this model each user chose the charge
schemes usually require each user to maintain per resource per unit of time that it is willing to pay for a route. In turn
state, or/and each resource to maintain per user state. In the the network computes the user rates according to a propor-
following, we discuss several of the more relevant schemes. tionate criterion. However, they only consider the model
Waldspurger and Weihl have proposed a framework for where resources are allocated on the basis of per virtual cir-
resource management based on lottery tickets [27, 28]. cuit.
Each client is associated a certain number of tickets which To increase resource utilization, in this paper we propose
encapsulate its resource rights. The number of tickets a user performing dynamic routing and load balancing among the
receives is similar to the user’s income rate in LIRA. This best k shortest paths between source and destination. In
framework was shown to provide flexible management for this context, one of the first dynamic routing algorithms,
various single resources, such as disk, memory and CPU. which uses the link delay as metric, was the ARPANET
However, they do not give any algorithm(s) to coordinate shortest path first [21]. Unfortunately, the sensitivity of
tickets allocation among multiple resources. this metric when the link utilization approaches unity re-
Ferguson et al. proposed a flow control economy to al- sulted to relative poor performances. Various routing algo-
locate network resources such as links and buffers among rithms based on congestion control information were pro-
competing virtual circuits (VCs) [7, 8]. In this model, each posed elsewhere [12, 13]. The unique aspect of our algo-
VC is endowed certain funds for buying resources. The rithm is that it combines dynamic routing, congestion con-
VC’s goal is to buy a minimum capacity on all links along trol and load balancing together. Also we alleviate the prob-
its path, and use the extra money to minimize the average lem of system stability which plagued many of the previous
end-to-end delay. The resource prices are set so that the dynamic routing algorithms by defining a more robust cost
supply and the demand are balanced. It has been shown function and probabilistically binding a flow to a route. We
that such economy converges and the resulted allocations also note that our link cost is similar to the one used in [19].
are pareto-optimal. In particular, it can be shown that when all links have the
MacKie-Mason and Varian have proposed a model, same capacity, our link cost is within a constant factor of
called “smart markets”, in which each packet carries a bid the cost of shortest-dist(P, 1) algorithm presented in [19].
that represents how much the user is willing to pay for It is worth noting that shortest-dist(P, 1) performed the best
it [20]. At each congested link along a path a cutoff price among all the algorithms studied in [19].
is computed and only packets that have a higher bid are for-
warded; the other packets are buffered. At the service level 6 Summary
it is unclear how the priorities of individual packets trans- We study models and algorithms that support Assured
late into expected network throughput. In addition, in order Service with service profiles defined over large spatial gran-
to achieve high level of service assurance, a user needs to ularities. We propose a service model in which the service-
know the smallest bid along the path. No mechanisms are profile is defined in units of resource tokens rather than the
given to propagate this information to the users. absolute bandwidth, and an accounting scheme that dynam-
Awerbuch et al. [1] have proposed an on-line reserva- ically determines the number of resource tokens charged for
tion algorithm to maximize the throughput in a network each in-profile packet. We present a set of algorithms that
where the duration of each reservation is known in ad- efficiently implement the service model. In particular, we
vance. The algorithm guarantees that the throughput is introduce three techniques: (a) distributing path costs to all
within O(log nT ) factor of the throughput achieved by an edge nodes by leveraging existing routing infrastructure; (b)
optimal off-line algorithm, where n is the number of nodes binding a flow to a route (route-pinning) without maintain-
and T is the maximum duration of a reservation. In the ing per flow state; (c) multi-path routing and probabilistic
scheme, each link is associated with a cost that is a expo- binding of flows to paths to achieve load balancing. Simu-
nential function of its current utilization. Also, each con- lation results are presented to demonstrate the effectiveness
nection is associated with a profit which is received only of the approach. To the best of our knowledge, this is the
if the request is granted. The goal of the algorithm is then first complete scheme that explicitly addresses the issue of
to maximize the overall profit. While this algorithm differs large spatial granularities.
significantly form ours both in assumptions and goals, we While these techniques are developed in the context of
note that the mechanisms used to implement LIRA can also supporting Assured Service, they may be useful in other
be used to implement this scheme. contexts. For example, by combining the route-pinning
Kelly et. al [15, 16] have considered the problem of technique with the SCED+ algorithm proposed in [6], guar-
13You can also read
