Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
Computer Science Technical Report Archive
/
USC Computer Science Technical Reports, no. 752 (2002)
(USC DC Other)
USC Computer Science Technical Reports, no. 752 (2002)
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
1
Fair Stateless Aggregate Marking Techniques for
Differentiated Services Networks
Abhimanyu Das, Debojyoti Dutta, Ahmed Helmy
Abstract—In heterogeneous networks such as today’s Inter-
net, the differentiated services architecture for providing scal-
able service differentiation, has proved to be a practical and
easily deployable method for providing Quality-of-Services. In
this paper, we focus on the issue of packet marking in diff-
serv networks. We specifically look at developing fair aggre-
gate markers which do not need to maintain per-flow state.
We propose two new probabilistic marking strategies to enable
fair token distribution among individual flows of an aggregate.
The first marker, Probabilistic Aggregate Marker (PAM), uses
the Token Bucket burst size to probabilistically mark incom-
ing packets and ensure proportional fair marking among the
flows. The second marker, Stateless Aggregate Fair Marker
(SAFM) approximates fair queuing techniques to isolate flows
while marking packets of the aggregate, and distributes to-
kens evenly among the flows without maintaining per-flow
state. Our simulation results show that the two fair marking
strategies show considerable improvement over standard token
bucket techniques while marking flow aggregates.
Keywords— Diffserv, Fairness, Aggregate Traffic Mark-
ing, Internet, Congestion Control
I. INTRODUCTION
The Differentiated Service architecture (diffserv) [1] [2]
addresses the issue of providing QoS within IP by clas-
sifying and aggregating flows into different classes, and,
providing service differentiation among the traffic aggre-
gates. Thus, statistical QoS guarantees can be provided to
applications. The diffserv approach does not suffer from
the scalability problems of IntServ [3] because it uses fine
grained, per-flow marking at the network edges to classify
flows into the various classes, and then using coarser per-
class service differentiation at the network core.
The per-flow marking at leaf nodes, however, need to
be supplemented by remarking of the packets at the net-
work edge before entering the next domain. Edge aggre-
gate diffserv markers (re-)mark all packets leaving a net-
work domain to enter a neighboring domain, based on the
service level agreements (SLA) between the two domains,
which can be modeled as a token bucket for each diffserv
class. Since the service level agreement applies to aggre-
gate traffic leaving the domain, traffic marking needs to
The authors are with University of Southern California, Los An-
geles, USA. E-mail: adas@usc.edu, ddutta@isi.edu and
helmy@usc.edu
be performed after the individual flows within the domain
have been aggregated at the edge. Using a simple token
bucket marker at the edge, however, leaves no scope to
distinguish between flows within an aggregate. In particu-
lar, there is no way to prevent excessive token allocation to
misbehaving, non-responsive flows while marking down
traffic belonging to other well-behaved sources in the do-
main as they try to cross into the next diffserv domain. An
important goal for diffserv markers should therefore be to
ensure fairness in token allocation to individual flows dur-
ing packet marking, and, at the same time, be scalable as
the number of flows increases.
One way to ensure fair marking of packets amongst the
flows in the aggregate is to segregate individual flows in-
side the marker and maintain per-flow state and fairly dis-
tribute the tokens among the flows. This clearly adds a
lot of complexity to the marker, and, hence, does not scale
with increase in the number of flows at an edge. The con-
stantly varying number of flows and varying rules used to
classify individual flows makes it difficult for edge mark-
ers to maintain per-flow state and perform per-flow classi-
fication and management in. Clearly such techniques will
not scale with increasing edge traffic.
We therefore turn to techniques that do not look at indi-
vidual flows. We assume that each flow is either a TCP or
a UDP connection. Hence we mark the aggregates of these
flows while maintaining very little at the edge routers. We
propose two alternate methods of edge aggregate marking
that attempt to allocate tokens to the aggregate of flows
entering the edge marker without maintaining state for the
individual flows while ensuring some degree of fairness
and isolation of the misbehaving flows. We draw paral-
lels between diffserv packet marking and queue scheduling
to formulate our methods. Specifically, we borrow ideas
from efficient and fair packet scheduling algorithms like
RED [4] and CSFQ [5] that try to protect well behaved
flows from misbehaving flows, to enhance fairness in the
simple Token Bucket marker. We show through extensive
simulations that our methods achieve fairness in token al-
location between flows without maintaining per-flow state.
In addition, both the methods are probabilistic in nature,
which also has the effect of decreasing bursts of down-
graded packets belonging to a single flow, thus making the
2
marked flows more TCP-friendly [6].
The rest of this document is outlined as follows. Sec-
tion II provides motivation for our work. Section III
presents related work on markers. A brief background on
traffic marking is given in Section IV and our first scheme,
PAM, is describes in Section V. Section VI details our sec-
ond scheme, SAFM. Our simulation results are discussed
in Section VII. Section VIII outlines future work and Sec-
tion IX concludes.
II. MOTIVATION
We aim to solve the issue of fairness among individ-
ual flows while re-marking and policing packets in an ag-
gregate packet marker for differentiated services network.
Our architectural modification changes the aggregate traf-
fic marker at the edge of a domain (say at the outgoing end
of an ISP).
In the follwoing paragraphs, we present some sample
scenarios illustrating why we need to consider fair aggre-
gate packet marking at the outgoing edge (egress) of a do-
main, in spite of (possibly per-flow) packet marking at the
ingress to the domain.
Consider the case of an ISP which connects with a back-
bone network at its egress and provides network access
points to individual customers or corporates. The ISP has
a service level agreement with the backbone network for
the various diff-serv classes, and also has individual ser-
vice commitments to its customers. Packet marking is al-
ready performed per customer-flow at the ingress to the
ISP, where any traffic of a particular flow exceeding its
quota for that class is marked into the next lower class. So
it could be possible that the total number of packets present
in the ISP domain for a given class, exceeds the allocated
capacity of that class provisioned in the ISP, because of this
trickle-down effect. So at the egress of the ISP, we need
to ensure that the aggregate number of packets per class
conforms to the service level agreements between the two
domains across the edge. This is where aggregate packet
remarking comes in. So we have to drop/re-mark packets
of various classes whose quota are exceeded, before they
enter the next domain.
In the case of a network domain which has service level
agreements only with other diffserv domains (no individ-
ual customers), the ingress marker at each of the domain’s
nodes which are adjoining any neighboring domain ensure
service level agreements for all entering flows from the
neighboring domain. Now assume that the domain is rout-
ing all its incoming packets to another adjoining domain.
Because of the ingress re-marking and the completely in-
dependent service level agreement with this egress do-
main, there needs to be some egress packet marking before
packets enter the outgoing domain. This can be done by an
aggregate packet marker at the egress node of the domain,
which ensures conformance of diffserv classes among the
aggregated flows to the levels negotiated with the egress
domain in the service level agreement.
The above egress aggregate marking should be fair to
the various ingress flows (or ingress aggregates entering
from various domains) which are all intermingled when
they enter the traffic marker, without maintaining any per-
flow state. With conventional approaches, this fairness re-
quirement usually leads to complex marker schemes that
lack scalability. Assume we have a token-bucket specifi-
cation for a class quota. Hence, the problem statement is
to distribute the tokens fairly among the incoming pack-
ets of the various flows, while preventing misbehaving
flows from misappropriating tokens away from conform-
ing flows. A simple token-bucket like marking strategy
would not be fair to bursty and short term flows. Other
diffserv markers like single-rate three color markers [7]
and two-rate three color markers [8] are either per-flow
based or they need per-flow state information. In the next
sections, we propose two fair aggregate marking schemes
without maintaining per-flow state. The salient feature
of our markers is that they are derived from well-known
packet queueing strategies (RED [4]and CSFQ [5]), and
hence are readily deployable. In fact, we view the prob-
lem of fair token distribution among packets aggregated
from various flows according to a token bucket specifica-
tion, as being equivalent to fair packet scheduling of in-
coming packets at a node with a limited queue size.
III. RELATED WORK
Packet marking is a well visited topic. Most markers ei-
ther do very sophisticated per-flow marking or apply very
simple techniques on per-flow aggregates. Current aggre-
gate traffic markers mark individual packets of an aggre-
gate using simple token-bucket like schemes without look-
ing at fair token distribution among individual flows; a re-
quirement we believe to be essential to maintain fairness in
QoS based on differentiated services. For example, previ-
ous work on markers [7] [8] provides good per-flow mark-
ing but does not consider fair token distribution between
individual flows of the aggregate incoming traffic.
Maintaining individual, per-flow marker state can, of
course solve our fair aggregate marking problem. How-
ever, this scheme may not be scalable and might not even
be feasible when the number of flows entering a marker
is varying and dynamic. In [6] the authors aim to give
preferential treatment to short-lived TCP flows in an ag-
gregate and perform a max-min fairness on the remain-
ing TCP flows, but they assume that their marker has state
3
about all the component TCP flows in the aggregate, which
might not be practical or scalable. Yeom and Reddy [9]
also looks at fair aggregate marking issues, but it calculates
the flow throughput information using a TCP throughput
model which requires Round Trip Time and PacketSize in-
formation for each flow, and it does not work for non-TCP
flows, which is a common with many of today’s applica-
tions requiring QoS guarantees. In [10], the authors look
specifically at the issue of sharing excess network band-
width among traffic aggregates. However, they do not in-
vestigate the problem of fairly marking individual flows
within an aggregate, which is the problem we address in
this study.
There have been some work in aggregate marking. They
typically rely of metering the average rates and comparing
them against a token bucket traffic specification. A so-
phisticated marker in this class is that of Fang. et. al. [11]
which does probabilistic marking on the average rates. But
they do not explore issues in fair token allocation amongts
different TCP flows. Our work presents aggregate mark-
ers that outperform all the current aggregate traffic mark-
ers, and at the same time, improves the fairness amongst
flows in the aggregate by using simple techniques bor-
rowed from queue scheduling. We are not aware of any
previous work that aims to solve the problem of fair token
distribution among individual flows of an aggregate at a
marker, without maintaining per-flow state within the dif-
ferentiates services framework.
IV. TRAFFIC MARKING
Traffic marking is an essential component of the diff-
serv architecture. It is a step where individual packets are
labeled with a codepoint or simply a identifier. This iden-
tifier is synonymous to a priority. The first module of a
marker looks at the packets going through a link or a node
and compares it with a given traffic profile (a token bucket
characterization for example). This step is known as me-
tering. Metering can signal whether the packets conform
to the traffic profile (they are in-profile) or whether they
violate the profile (out-of-profile). In-profile packets are
marked with an identifier that indicates a higher priority.
If packets are out of profile, it is marked with a lower pri-
ority.
Marking can be done with respect to a single flow or
an aggregate of flows. Per flow marking can be very ef-
fective and reasonable QoS guarantees can be obtained.
Unfortunately, this strategy requires us to maintain a large
amount of state and might not be scalable. The other strat-
egy is to mark packet aggregates. Consider an aggregate
to be a set of flows within a domain entering a particu-
lar traffic marker. Now, we can treat all the packets with
this aggregate of flows to be a single unit and apply a me-
ter to determine whether the aggregate is in-profile or not.
All the packets of the same aggregate get marked with the
same code point (DSCP). Obviously this strategy involves
the maintenance of less state information. On the other
hand, markers based on per-flow marking will tend to be
be more accurate and provide more fine-grained QoS guar-
antees. Much work has been done in this area of aggregate
marking. See [6] and [9] for more details on marking TCP
flow aggregates.
In this section, we address several issues and strategies
for packet marking. We also introduce two novel marking
schemes in this and the subsequent section.
A. Where do we mark?
An issue that has yet to be resolved in the diffserv com-
munity is to find the best place where to install the traf-
fic markers. One argument is to have the markers at the
leaf router and have the them mark on a per-flow basis.
That way, a marker could specify different traffic profiles
for marking every diffserv flow, and avoid more coarse
grained marking of flows in aggregates, when they merge
later in the network. Others claim that we need to address
marking at the edge router between two domains - since it
is more trustworthy and easily administered. However this
approach also has a few problems:
The markers at the edges are aggregate markers. An ag-
gregate marker, in general, does not distinguish between
individual flows in the aggregate. So it would perform very
coarse grained marking based on an aggregate traffic pro-
file.
Even if markers are able to distinguish among flows, it
would not be scalable to maintain marking state and pro-
files for each individual flow at the marker.
A flow needs to be defined. Currently, such definitions
are not very clear.
An aggregate marker will find it difficult to adapt to the
traffic dynamics of individual flows.
Aggregate markers are not very fair. We would ideally
like to have fair marking; i.e., misbehaving flows should
have more of their packets remarked to a lower priority.
B. Our Strategy
One possible in marking is to have two levels of mark-
ing: first on a per-flow basis (maybe at the application) and
later remarking on an aggregate basis, which is more scal-
able than the current marking schemes. We realize that it
will be more beneficial if the applications themselves do
their packet marking. They have a better handle on their
QoS requirements anyway. Unfortunately, it may not be
4
practical to require all applications to negotiate with band-
width brokers for QoS guarantees. We propose to put the
fair marking at transport agents operating at the transport
layer.
The major shortcoming of this approach is that the trans-
port agents need to be trusted to fairly mark their packets,
according to the traffic profile it was allocated. That is not
possible always. Hence, we cannot just have marking at
the end hosts. To this effect we have devised a combina-
tion of marking strategies. The traffic is marked by the
transport agents which negotiates with a bandwidth bro-
ker. Then there is another round of fair and efficient traffic
remarking at the edge router. This remarking would use an
aggregate marker.
In the next section and the section that follows, we dis-
cuss how the traffic re-marking is done on an aggregate
basis. Note that this paper does not try solve the prob-
lem of application level traffic marking. Hence, we use the
terms marking and re-marking interchangeably throughout
the rest of the paper.
V. AGGREGATE TRAFFIC MARKING
min max
P
P
th th
min
max
size of tocken bucket
remark
probability
Fig. 1. Probability density function used for remarking at the
edge router. The x-axis represents the size of the token
bucket or maximum burst. The y-axis represents the proba-
bility to downgrade a packet
The diffserv community has tried to promote traffic
marking at the edge router with the hope that the edges are
lightly loaded compared to the core. Hence the aggregate
markers that have been designed try to do this expensive
flow detection to ensure fairness. Much work has been
done in this regard. Unfortunately, flow detection is itself
not an easy problem. On top of that it has high overheads,
and hence, has deployment problems.
We have designed a new Probabilistic Aggregate
Marker (PAM). Our approach has been to use probabilis-
tic marking similar to RED (Random Early Detection) [4].
We assume a token bucket traffic descriptor for the aggre-
gate. Intuitively, the idea is as follows. The aggregate traf-
fic will try to consume traffic at a certain rate. Suppose
the token bucket contents fall below a certain threshold
, all packets are to be marked with a lower priority.
If the bucket size varies between
and
, we
remark the packet with a lower priority based on a proba-
bility function that depends on the instantaneous size of the
token bucket. If the token bucket size exceeds
, we
do not remark the packet. The probability density func-
tion is depicted in Fig 1. More formally, our probability
function of remark can be written as follows.
"!
#%$’&)(+*-,
.0/13254.0/7698
:<;>=@?BA
4 :DCFEG?FAIH
$KJL *-,NM O
! $’&)( *-, #PQ#%$KJR *-,
S ! T%$KJR*-,
(1)
where
is the instantaneous size of the token bucket. For
every packet, we calculate the token bucket size to get the
probability of remarking.
The rationale behind using a probabilistic, RED-like,
approach is that we want to apply aggregate marking and
yet maintain equitable marking among the flows of the ag-
gregate, without trying to explicitly identifying individual
flows. The identification process can be expensive. Also
we can argue that like RED, this marking scheme will en-
sure a more proportional marking.
In our probabilistic marking, however, we propose that
every packet is marked to a lower class with a certain prob-
ability (based on the current token bucket size) once the
token bucket starts getting depleted. Hence, the flow that
pumps more traffic into the edge will, on the average, have
a greater number of packets that are remarked into a lower
service class. We believe that this scheme is indeed fair-
since it remarks packets of a flow proportionally to the
number of packets being sent by the flow. This simple
probabilistic approach naturally leads to a RED-like ap-
proach.
Our claim is that this marker is fair with respect to
packet marking among the different flows of the aggregate.
We test our claim using simulation and present the results
in Section VII. One major advantage of this approach is
that it is very simple and does not keep per-flow state.
VI. STATELESS AGGREGATE FAIR MARKER
In the stateless aggregate fair marker SAFM, we propose
an alternate strategy of aggregate marking, which uses a
fair-queuing like max-min fairness criteria [12]. Recall
that our main problem is to distribute tokens fairly among
the individual packets in the aggregate, assuming we have
a token-bucket specification for every diffserv class. The
idea here is to apply approximate fair queuing to each
class, while distributing the tokens among the packets of
5
each class, but without maintaining any per flow queue or
state. We therefore use the core stateless fair queuing con-
cept presented in [5] to maintain the rate information of a
flow in the packet header itself, and use this to calculate a
token allocate probability, on a per-packet basis in the edge
marker. The queue, output link speed and drop probability
in [5] are replaced by the token bucket, token-bucket rate
and (1 - token allocation probability). In token allocation,
packets with tokens are allowed through unchanged, while
packets with no tokens are either dropped or remarked to
a lower priority.
The rate information in each packet header is calculated
and filled by the ingress node when the flow enters the do-
main. Since each ingress node is responsible for maintain-
ing the rate of only the flow that enters through it, there
is no scalability issue involved in the per-flow rate cal-
culation that is needed. At the egress, the edge marker
needs to calculate the fair rate, , allocated to the flows,
and then calculates the token allocation probability (mark-
ing probability) of a packet as
, where is the
rate of the corresponding flow. So the expected token al-
location rate to a packet belonging to a flow of rate , is
then
, which corresponds to the max-min fair-
ness of fair-queuing. The aggregate token allocation rate
will then be . As in [5], the fair-rate
, is calculated by an iterative method based on the av-
erage aggregate arrival rate of packets , estimate of the
aggregate token allocation rate of packets
, and the to-
ken bucket rate .
The aggregate arrival rate and token allocation rate are
exponentially averaged at the egress marker. Note that
these rates do not need any per-flow measurements. The it-
erative algorithm to calculate the fair-share rate , is based
on the assumption that the estimate of the aggregate to-
ken allocation rate is a monotonically increasing, concave,
piecewise linear function of . In any time interval of size
, if the arrival rate is greater than the token bucket rate
, the fair rate , is the unique solution to
.
Approximating
by a linear function, with
slope , we get "!#
$%’&)(+*
-,
. If the arrival rate
is less than the token bucket rate , the fair rate is set
to the largest rate seen on any incoming packet in the time
interval of size k. In this way, we get an approximate fair
queuing strategy with which we get fair probabilities of
token allocation for every incoming packet, without main-
taining any per-flow state.
This scheme will ensure that tokens are allocated among
the various flows fairly, based on their incoming arrival
rates, almost as if it were a bit-by-bit round robin strat-
egy with individual queues per flow. The rate estimation
of a flow and its corresponding entry into the packet head-
ers of the flow can be done just once at the first trusted
router of the ISP before any individual flows are aggre-
gated, using simple metering. The rate does not need to be
re-calculated at every hop inside the ISP network, since we
are concerned with parameterizing and ensuring fairness
of token allocations only based on the flow rates when the
enter the ISP network, and not when they enter the edge
router.
VII. RESULTS
s1
s2
s3
s4
d1
d2
d3
e1 e2 c
(core)
Fig. 2. Simulation scenario: A simple core with two edges. The
. C inject traffic of different classes into the network while
the / C s are the sinks.
In this section we evaluate the two markers presented in
this paper. The markers PAM and SAFM aim to achieve
different levels of fairness. We investigate the validity of
our claims in the previous sections using packet level net-
work simulation. First, we study scenarios with few flows
to gain insight into the marking schemes and then we give
results for many flows to compare our aggregate markers
against Token bucket based marker.
A. Experimental Setup
We simulated the design of our markers with the ns-
2 [13] network simulator
1
.
The topology used in our experiments is depicted in Fig-
ure 2. The source nodes are 0 and the destination or sink
nodes are 1 . The source nodes are connected to the edge
node 23 which inject traffic into the network core, 4 . The
core is connected to the edge 562 which is further connected
to the sink nodes 1 s. The source node 07 is used to gener-
ate background traffic in form of many TCP flows carrying
bulk traffic. This background traffic is marked with a sep-
arate DSCP (e.g., 58 ) and is absorbed at 19 .
: We used the Nortel’s diff-serv patch for ns-2. To implement the two
markers, we have added our modules to the dsPolicy.cc and dsPolicy.h.
Besides this, we have added a new field to the IP packet header for
storing the DSCP.
6
TCP Flow 1 TCP Flow 2 Misbehaving UDP Flow
unmarked pkts marked pkts unmarked pkts marked pkts mb/s unmarked pkts marked pkts
172 3172 224 3475 1 2173 2853
67 1261 76 1267 2 2423 7215
0 0 318 2082 2 2244 7639
Fig. 3. Detailed Token Bucket results with 2 TCP flows and 1 misbehaving UDP flow. For the UDP flow, we give the rate, the
number of packets not remarked and the number of packets that have been remarked(downgraded) by our marker. For the TCP
flows, we present only the number of packets not remarked and remarked respectively
UDP Flow 1 UDP Flow 2 UDP Flow 3
mb/s unmarked pkts marked pkts mb/s unmarked pkts marked pkts mb/s unmarked pkts marked pkts
1 5 968 6 5594 1017 0 0 0
1 13 748 4 805 2869 2 387 1593
1 5 968 6 362 5594 2 1017 1688
Fig. 4. Detailed Token Bucket results with 3 UDP flows. For the flows, we give the rate, the number of packets not remarked and
the number of packets that have been remarked by our marker.
B. Validating the marking process
First we evaluate the PAM marker. The quantitative
measure used to evaluate the quality of guarantees to as-
sured services is that all the flows should receive at least
the bandwidth assured to them by the network, in the
presence of non-responsive assured-service or best-effort
flows. We also show the proportion of packets remarked
for each flow by an aggregate marker and see whether
we remark large misbehaving flows more than conformant
flows. Also we aim to show that in the case where the net-
work bandwidth is oversubscribed, we do get a gradation
of quality-of-service in terms of throughput achieved, into
as many categories as there are classes supported by the,
AS Byte field. That is, we should get better service dif-
ferentiation among the traffic without increasing the state
space at each router linearly in proportion to the number
of service-classes. To simulate this, we would have As-
sured flow sources marked with different service-classes,
and oversubscribe the assured guarantees in comparison to
the total network bandwidth. We would then see if we get
a finer granularity of service differentiation in terms of the
throughput achieved by each source.
Our results in Figure 5 compares our PAM aggregate
marker with standard Token Bucket marker (referred to
TB from now on). We use the scenario in Figure 2 and
we do aggregate marking at the entry to the network core,
instead of per-flow marking at the leaf nodes. We aggre-
gate two TCP flows and a misbehaving UDP flow at the
network edge, 2 , and mark them using our probabilistic
marking strategy (PAM). The network bottleneck for as-
sured forwarding packets is 2000kbps. We vary the rate of
the misbehaving flow from 800kbps to 2300 kbps, and see
the proportion of traffic remarked to a lower category for
each flow. Ideally the number of packets remarked for each
flow should be proportional to its share of the bandwidth
utilization at the marker node. (or equivalently, percent-
age of packets remarked for each flow should be constant).
In a normal aggregate marker the number of packets re-
marked for each flow is not as proportionate as the PAM
marker. We can see clearly from Fig. 5 that the PAM mark-
ing strategy is fairer (proportionately) since it marks near
equal percentage of traffic from all flows, even in the pres-
ence of a misbehaving flow.
1 1.5 2
Bandwidth of misbehaving flow (Flow 3) in Mbps
0
1
2
3
4
5
%age of packets remarked
Flow 1 with PAM
Flow 2 with PAM
Flow 3 with PAM
Flow 1 w/o PAM
Flow 2 w/o PAM
Flow 3 w/o PAM
Fig. 5. Comparing our PAM with normal aggregate marker
Now let us investigate in more detail the performance
of the PAM marker. Consider the table in Figure 6. This
experiment had 2 TCP flows multiplexed with 1 misbehav-
ing UDP flow injected into the core. We used a commit-
ted information rate (CIR) of 500kb/s and a burst size of
100kbits. We changed the sending rate of the UDP flow
and ran the simulation for 40 seconds in virtual time. Let
us compare these results with those obtained by using a
TB marker on the aggregate (see Figure 3). As we increase
7
TCP Flow 1 TCP Flow 2 Misbehaving UDP Flow
unmarked pkts marked pkts unmarked pkts marked pkts mb/s unmarked pkts marked pkts
1591 2094 1522 2167 1 2021 2993
236 935 378 1456 2 2011 7607
0 0 542 2088 2 2083 7088
Fig. 6. Detailed PAM results with 2 TCP flows and 1 misbehaving UDP flow. For the UDP flow, we give the rate, the number of
packets not remarked and the number of packets that have been remarked by our marker. For the TCP flows, we present only
the number of packets not remarked and remarked respectively
UDP Flow 1 UDP Flow 2 UDP Flow 3
mb/s unmarked pkts marked pkts mb/s unmarked pkts marked pkts mb/s unmarked pkts marked pkts
1 203 714 6 1083 4269 0 0 0
1 245 695 4 695 2883 2 387 1593
1 179 886 6 813 5441 2 353 1957
Fig. 7. Detailed PAM results with 3 UDP flows. For the flows, we give the rate, the number of packets not remarked and the
number of packets that have been remarked by our marker.
the sending rate, we see that the PAM remarks and down-
grades packets proportionately i.e. the misbehaving flow
gets penalized more. In other words, with PAM the ratio
$ % ! ! ! & $ % !
! & is the same for all flows. In the to-
ken bucket case, we see that the misbehaving UDP flow
squeezes the elastic TCP connections.
In the next experiment, we consider only UDP flows
carrying CBR traffic. On comparing Figures 4 and 7, we
again see a similar result. With PAM, the number of re-
marked packets is proportional to the total number of pack-
ets carried by the flow. This result illustrates that PAM is
indeed a fair proportional marker.
In the preceding subsection, we showed how PAM is a
proportional marker. Sometimes we need a marker which
marks flow of an aggregate with max-min fairness(cite).
For example, even in a PAM marker, a very large misbe-
having flow would take away some fraction of tokens from
other conforming flows, and consequently affect marking
of all other flows in an aggregate. SAFM is an aggregate
marker that approximates max-min fairness principles i.e.
tokens are allocated to individual flows in order of increas-
ing demands. No flow receives more tokens than needed,
and flows with unsatisfied demands split the remaining re-
sources. As we see in the following results, SAFM is one
such aggregate stateless marker which simulates the core
stateless fair queuing techniques [5] to nearly achieve max-
min fairness.
Just like the preceding subsection, we conducted two
sets of simulations. First we try the similar simulation
experiment with aggregates consisting of TCP flows and
a single misbehaving UDP flow with rates varying from
1mbps to 2Mbps . In this case too, we see in Figure 9 that
all the TCP and UDP flows get approximately the same
share of tokens from the marker, in spite of the large mis-
behaving UDP flow (which would have misappropriated
most of the tokens from the TCP flows in the case of a
token bucket marker, as seen in the token bucket marker
results in Figure 4).
Thus we see, that the SAFM marker effectively segre-
gates flows from each other, and does not let misbehav-
ing flows take away tokens from other well-behaved flows.
When the token bucket is oversubscribed, the number of
tokens allocated to all flows is nearly the same irrespective
of their packet rates, following max-min fairness rules.
The next set consists of UDP flows being marked by
the same aggregate marker (see Figure 8). The flows have
varying transmission rates, and we observe the number
of packets of each flow which are not remarked (i.e. the
number of packets of each flow which are allocated tokens
from the token bucket). We use background TCP traffic
in the topology to prevent flow synchronization. Since the
SAFM algorithm requires the flow rate information in each
packet, we use a rate-estimator at the source of the flows
to insert the flow rate into each outgoing packet’s header.
We change the individual flow rates to different values and
run the simulations for 40 seconds each. We use a token
bucket CIR of 5Mbps and a CBS value of 10 Kb. The rates
of all the flows varied from 1Mbps to 6MBps, so only a
small fraction of packets in the aggregates receive tokens.
We see that in each case, the number of tokens allocated to
each flow is nearly the same, in spite of widely varying in-
dividual flows rates. Thus the tokens are distributed fairly
among each flow, from a single aggregate token bucket
just as if the flows were separated and marked individu-
ally using fair-queuing principles. Comparing with the to-
ken bucket marker results (see Figure 4), where the larger
flows gather most of the tokens, we see that the SAFM
marker effectively isolates flows among the aggregates. It
8
also evenly distributes tokens among the individual flows,
without maintaining any per-flow state or queue.
C. End-to-end Performance
In the previous subsection we have seen that both PAM
and SAFM mark packets from an aggregate in a more
fair manner compared to the token bucket marker (TB)
and the superior Time Sliding Window 2 Color Marker
(TSW2CM). Now we compare the end-to-end perfor-
mance of PAM and SAFM.
0 50 100 150 200 250 300
Number of bulk TCP flows
0
5
10
15
20
Per-flow throughput (pkts/s)
Token Bucket
PAM
SAFM
TSW2CM
Fig. 10. Comparison of markers when Only bulk TCP flows
are used between
.
and /
initially marked with the same
codepoint
0 50 100 150 200 250 300
Number of bulk TCP flows
0
5
10
15
20
Per-flow throughput (pkts/s)
Token Bucket
PAM
SAFM
TSW2CM
Fig. 11. Comparison of markers when both bulk as well as
short lived TCP flows are used between
.
and /
initially
marked with the same codepoint. In this graph, we plot the
bandwidth of the long lived flows
In all the experiments in this subsection, we tool the
topology as depicted by Figure 2. The CIR was 1Mb/s, the
TB burst size was 500Kb/s and there was no separate back-
ground traffic as in the previous set of experiments. All the
links except the one between 4" 2 and 25 had a bandwidth
of 10Mb/s while the bottleneck had 5Mb/s. The delays in
all the links were 5ms. We have used TCP Reno for all
TCP agents and the short lived flows were generated by
0 50 100 150 200 250 300
Number of bulk TCP flows
10
15
20
25
30
35
40
45
50
55
60
Per-flow throughput (pkts/s)
Token Bucket
PAM
SAFM
TSW2CM
Fig. 12. Comparison of markers when both bulk as well as
short lived TCP flows are used between
.
and /
initially
marked with the same codepoint. In this graph, we plot the
bandwidth of each short lived flows
the HTTP 1.0 model in ns-2. The parameters for the RIO
queues were the default ones in ns-2. We have got better
results by tweaking the RIO parameters but we have not
presented those results here.
First, we tested our markers with long lived bulk TCP
flows from 03 to 1 . The results are shown in Figure 10.
We see that PAM is marginally better than TB. PAM tries
to space out the out packets probabilistically. Hence, un-
der heavy aggregation out packets would be spaced equally
from all flows. When dropping took place in the congested
router, the probability of two packets from the same flow
getting dropped would become lower. We also notice that
SAFM is around 10% better than TB. It is interesting to
note that both PAM as well as SAFM have a lesser standard
deviation compared to TB, which shows that our markers
lead to a more fair bandwidth allocation. The clear winner
is SAFM which has a much lesser standard deviation for
the per-flow bandwidth. This is expected as we use a max-
min fairness criteria to distribute the token at the marker.
Note that the results of the TSW2CM are worse than all
other markers. One possible reason is that rate estimation
of the marker is smoothed and it cant account for the bursty
TCP traffic.
In the next experiment, we took several bulk TCP flows
along with several short lived TCP flows marked with the
same DSCP. Again, the average per-flow throughput was
similar with PAM and SAFM yielding less standard devi-
ation. Hence, Figure 11 is very similar to Figure 10. We
must note that the SAFM results have very low standard
deviation (almost half of that of the TB marker). Again,
this is expected out of a marker that uses max-min fair-
ness to distribute tokens. The PAM marker has a slightly
smaller average throughput than TB. Again TSW2CM per-
forms badly. Clearly SAFM is the winner due to its higher
9
TCP Flow 1 TCP Flow 2 Misbehaving UDP Flow
unmarked pkts marked pkts unmarked pkts marked pkts mb/s unmarked pkts marked pkts
797 2691 831 2755 1 918 4084
740 882 748 835 2 1042 8254
0 0 1169 1631 2 1376 8835
Fig. 8. Detailed SAFM results with 2 TCP flows and 1 misbehaving UDP flow. For the UDP flow, we give the rate, the number of
packets not remarked and the number of packets that have been remarked by our marker. For the TCP flows, we present only
the number of packets not remarked and remarked respectively
UDP Flow 1 UDP Flow 2 UDP Flow 3
mb/s unmarked pkts marked pkts mb/s unmarked pkts marked pkts mb/s unmarked pkts marked pkts
1 673 587 6 632 4385 0 0 0
1 497 620 4 413 2952 2 456 1571
1 480 813 6 426 5669 2 456 1922
Fig. 9. Detailed SFAM results with 3 UDP flows. For the flows, we give the rate, the number of packets not remarked and the
number of packets that have been remarked by our marker.
0 50 100 150 200 250 300
Number of bulk TCP flows
0
5
10
15
20
Per-flow throughput (pkts/s)
Token Bucket
PAM
SAFM
TSW2CM
Fig. 13. Comparison of markers when bulk TCP flows are used
between
.
and /
and a single misbehaving UDP flow with
a rate of 1Mb/s between
. and /
, initially marked with the
same codepoint
throughput as well lower standard deviation. If we con-
sider the bandwidth received by the short flows in Fig-
ure 12, we will see that SAFM outperforms all the other
markers here too. The deviation of SAFM is around 50%
lower than other markers. This clearly demonstrates that
SAFM has better fairness.
In the next set of experiments, we had the same setting
as the previous experiments. There were a variable number
of bulk TCP flows. Besides, there was a single misbehav-
ing UDP flow carrying CBR traffic whose bandwidth was
varied as 1, 2 and 3 Mb/s. The results are depicted in Fig-
ures 13, 14 and 15 respectively. Let us consider Figure 13.
Compared to the numerous TCP flows, this single UDP
flows try to introduce traffic at 1Mb/s. In a normal TB
marker, this would lead to a burst of packets being down-
graded as this single UDP flow competes with several TCP
flows. The downgraded TCP flows would be punished
0 50 100 150 200 250 300
Number of bulk TCP flows
0
5
10
15
20
Per-flow throughput (pkts/s)
Token Bucket
PAM
SAFM
TSW2CM
Fig. 14. Comparison of markers when bulk TCP flows are used
between
.
and /
and a single misbehaving UDP flow with
a rate of 2Mb/s between
. and /
, initially marked with the
same codepoint
severely leading more drops and reduced throughput. Our
aggregate markers alleviate this problem by ensuring that
the token distribution is more fair than TB (see the pre-
vious subsection). For example, PAM tried to randomly
distribute the out profile tokens randomly amongst flows.
SAFM tried to provide the same number of tokens to each
flow. As a result, we see that the average bandwidth re-
ceived by each bulk TCP flows is higher than TB. The per-
formance of SAFM is much better than that of PAM due
to a more even distribution of in and out packets between
the flows. The better TCP performance is clearly due to an
evenly distributed out-profile packets compared to bursty
out-profile packets in the case of the TB marker in pres-
ence of misbehaving UDP flows.
The performance improvement continues as the band-
width of the misbehaving flow is increased. This demon-
strates the efficacy of our marking schemes. We should
10
0 50 100 150 200 250 300
Number of bulk TCP flows
0
5
10
15
Per-flow throughput (pkts/s)
Token Bucket
PAM
SAFM
TSW2CM
Fig. 15. Comparison of markers when bulk TCP flows are used
between
.
and /
and a single misbehaving UDP flow with
a rate of 3Mb/s between
. and /
, initially marked with the
same codepoint
note that no special tuning of queue parameters were re-
quired to get performance improvement. In fact, we have
obtained better performance when we tuned the parame-
ters of the PAM marker as well as the RIO queues.
Thus, these experiments demonstrate that SAFM does a
very good job of isolating misbehaving flows. We conjec-
ture that techniques such as SAFM will give us the upper
bound in aggregate marking. PAM is a much less sophisti-
cated marker and has less dramatic gains. But it does very
well for short lived flows and the overheads are very small.
It is easy to see that the two markers provide a different set
of benefits. One needs to look at the design requirements
and match it with the performance tradeoffs when deciding
the best marker.
We must note that both our markers are very easily de-
ployable as they do not need any per flow state main-
tenance. Such simple schemes are promising because
their performance is very close to that of many sophisti-
cated per-flow marking schemes discussed in the literature.
We should understand that it is very difficult to surpass
the benefits of these well designed sophisticated per-flow
markers because they can do a much better job of protect-
ing TCP flows from misbehaving flows.
VIII. FUTURE WORK
Each of the the traffic markers introduced needs more
work. We need to explore the design space in more detail.
That will ensure it can deployed in a variety of scenarios.
For example, we have tested our markers with long lived
flows only in the presence of short lived flows. We must
fine tune our design for scenarios with a mixture of short
and long lived flows. We are currently adapting our tech-
niques to segregate the UDP flows early enough so that
we can give better fairness guarantees to short lived TCP
flows.
For PAM, We have used instantaneous token bucket
sizes for the probability calculations. One algorithm to
investigate is to use smooth bucket sizes. By this we im-
ply the use of exponential weighted moving average. This
EWMA will make the marker more stable and less prone
to transient jitter. Then we plan to incorporate marking
schemes based on concepts of PI controllers and equation
based marking schemes.
For SAFM, we have not yet looked at the idea of
weighted fair queuing while distributing tokens among the
flows. Allowing for different weights to individual flows
of the aggregate is the next logical step after approximat-
ing fair queuing. Another issue we have to look at is that
the rate estimation being performed at the source leaf node
might be incorrect by the time the flow reaches the marker,
and this could present some inaccuracies to the fair queu-
ing approximation algorithm.
One direction from this work is to generalize this ag-
gregate marking framework to provide application specific
service differentiation. For example, we are investigat-
ing how our techniques can be applied to protect short
term TCP flows by building a multilevel marker. This can
help improve the performance of web traffic. Finally, we
want to explore how our markers can be used to implement
good, fair pricing schemes apart from designing better ar-
chitecture for ensuring QoS.
IX. CONCLUSION
In this paper, we have proposed two aggregate markers
that ensure fairness amongst different flows in the aggre-
gate without maintaining per-flow state. This makes our
approach unique. Probabilistic Aggregate Marking (PAM)
ensures fairness in a proportional fashion and remarks, or
downgrades the DSCP (code point) in packets with a trans-
fer function that looks similar to the transfer functions of
RED. Also this ensures that misbehaving flows get penal-
ized proportional to their respective sending rates. We
also presented a more sophisticated marker called State-
less Aggregate Fair Marker (SAFM). This marker is based
on the dynamic sending rate and fair queueing using max-
min fairness criteria and maintains the instant flow state in
the packet itself. The marker calculates the fair rate from
the packet information and all flows are marked in a way
that approximatesmax-min fairness.
The above markers are scalable and readily deployable.
Our hope is that markers like PAM and SAFM will enable
architectures based on application level marking along
with probabilistic aggregate marking. Such architectures
promise much more deployable and scalable solution to
the problem of traffic marking in the differentiated services
11
framework.
REFERENCES
[1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and
W. Weiss, “An architecture for differentiated services,” RFC
2475, 1998.
[2] K. Nichols, V . Jacobson, and L. Zhang, “A twobit differentiated
services architecture for the internet,” RFC 2638, 1999.
[3] Lixia Zhang, Steve Deering, Deborah Estrin, Scott Shenker, and
Daniel Zappala, “Rsvp: A new resource reservation protocol,”
IEEE Network Magazine, September 1993.
[4] S. Floyd and V . Jacobson, “Random early detection gateways for
congestion avoidance.,” IEEE/ACM Transactions on Networking,
V .1 N.4, 1993.
[5] Ion Stoica, Scott Shenker, and Hui Zhang, “Core-stateless fair
queueing: Achieving approximately fair bandwidth allocations in
high speed networks,” Sigcomm, 1998.
[6] A.Feroz, A. Rao, and S. Kalyanaraman, “A tcp-friendly traffic
marker for ip differentiated services,” Proc. of the IEEE/IFIP
Eighth International Workshop on Quality of Service - IWQoS,
2000.
[7] J. Heinanen and R. Guerin, “A single rate three color marker,”
RFC 2697, 1999.
[8] J. Heinanen and R. Guerin, “A two rate three color marker,” RFC
2698, 1999.
[9] Ikjun Yeom and A. L. Narasimha Reddy, “Adaptive marking for
aggregated flows,” Globecomm, 2001.
[10] H. Su and Mohammed Atiquzzaman, “Itswtcm: A new aggregate
marker to improve fairness in difserv,” Globecomm, 2001.
[11] W. Fang, N. Seddigh, and B. Nandy, “A time sliding window
three colour marker (tswtcm,” 2000.
[12] A. Demers, S. Keshav, and S.J. Shenker, “Analysis and simulation
of a fair queueing algorithm,” Sigcomm, 1989.
[13] UCB/LBNL/VINT, “The NS2 network simulator, available at
http://www.isi.edu/nsnam/ns/.,” .
Abstract (if available)
Linked assets
Computer Science Technical Report Archive
Conceptually similar
PDF
USC Computer Science Technical Reports, no. 763 (2002)
PDF
USC Computer Science Technical Reports, no. 831 (2004)
PDF
USC Computer Science Technical Reports, no. 877 (2006)
PDF
USC Computer Science Technical Reports, no. 753 (2002)
PDF
USC Computer Science Technical Reports, no. 779 (2002)
PDF
USC Computer Science Technical Reports, no. 757 (2002)
PDF
USC Computer Science Technical Reports, no. 814 (2004)
PDF
USC Computer Science Technical Reports, no. 812 (2003)
PDF
USC Computer Science Technical Reports, no. 804 (2003)
PDF
USC Computer Science Technical Reports, no. 884 (2006)
PDF
USC Computer Science Technical Reports, no. 765 (2002)
PDF
USC Computer Science Technical Reports, no. 780 (2002)
PDF
USC Computer Science Technical Reports, no. 803 (2003)
PDF
USC Computer Science Technical Reports, no. 758 (2002)
PDF
USC Computer Science Technical Reports, no. 770 (2002)
PDF
USC Computer Science Technical Reports, no. 764 (2002)
PDF
USC Computer Science Technical Reports, no. 789 (2003)
PDF
USC Computer Science Technical Reports, no. 727 (2000)
PDF
USC Computer Science Technical Reports, no. 781 (2002)
PDF
USC Computer Science Technical Reports, no. 673 (1998)
Description
Abhimanyu Das, Debojyoti Dutta, Ahmed Helmy. "Fair stateless aggregate marking techniques for DifferentiatedServices networks." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 752 (2002).
Asset Metadata
Creator
Das, Abhimanyu
(author),
Dutta, Debojyoti
(author),
Helmy, Ahmed
(author)
Core Title
USC Computer Science Technical Reports, no. 752 (2002)
Alternative Title
Fair stateless aggregate marking techniques for DifferentiatedServices networks (
title
)
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Tag
OAI-PMH Harvest
Format
11 pages
(extent),
technical reports
(aat)
Language
English
Unique identifier
UC16269175
Identifier
02-752 Fair Stateless Aggregate Marking Techniques for DifferentiatedServices Networks (filename)
Legacy Identifier
usc-cstr-02-752
Format
11 pages (extent),technical reports (aat)
Rights
Department of Computer Science (University of Southern California) and the author(s).
Internet Media Type
application/pdf
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/
Source
20180426-rozan-cstechreports-shoaf
(batch),
Computer Science Technical Report Archive
(collection),
University of Southern California. Department of Computer Science. Technical Reports
(series)
Access Conditions
The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Repository Email
csdept@usc.edu
Inherited Values
Title
Computer Science Technical Report Archive
Coverage Temporal
1991/2017
Repository Email
csdept@usc.edu
Repository Name
USC Viterbi School of Engineering Department of Computer Science
Repository Location
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Publisher
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
(publisher)
Copyright
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/