Internet Engineering Task Force R. Bless (Editor)
U. of Karlsruhe
B. Carpenter
Differentiated Services Working Group IBM
Internet Draft K. Nichols
Expires in December, 2002 Packet Design
K. Wehrle
U. of Karlsruhe
draft-bcnw-diffserv-pdb-le-00 June, 2002
A Lower Effort Per-Domain Behavior for Differentiated Services
<draft-bless-diffserv-pdb-le-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This document is a product of the Diffserv working group. Comments
on this draft should be directed to the Diffserv mailing list
<diffserv@ietf.org>. The list of current Internet-Drafts can be
accessed at www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
www.ietf.org/shadow.html. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document proposes a differentiated services per-domain behavior
(PDB) whose traffic may be "starved" (although starvation is not
strictly required) in a properly functioning network. This is in
contrast to the Internet's "best-effort" or "normal Internet traffic"
model. In this sense this PDB's traffic is forwarded with a "lower"
priority than the normal "best-effort" Internet traffic, thus the PDB
is called "Lower Effort" (LE). Use of this PDB allows to strictly
limit the effect of its traffic on "best-effort"/"normal" or all other
Internet traffic. This document gives some example uses, but does not
propose constraining the PDB's use to any particular type of traffic.
1. Description of the Lower Effort PDB
This document proposes a differentiated services per-domain behavior
[RFC3086] called "Lower Effort" (LE) which makes it possible to admit
traffic of sufficiently low value (where "value" may be interpreted
Bless (Ed.) Expires: December, 2002 [Page 1 ]
INTERNET DRAFT June, 2002
in any useful way by the network operator) that any other traffic
should take precedence over this traffic in consumption of network
link bandwidth. One possible interpretation of "low value" traffic
is its low priority in time, which does not necessarily imply that
it is generally of minor importance. From this point of view it
can be considered as a network equivalent to a background priority
for processes in an operating system. There may or may not be memory
(buffer) resources allocated for this type of traffic.
Some networks carry traffic for which delivery is considered optional;
that is, packets of this type of traffic ought to consume network
resources only when no other traffic is present. Alternatively,
the effect of this type of traffic on all other network traffic
is strictly limited. This is distinct from "best-effort" traffic
since the network makes no commitment to delivering these packets
while, in the best-effort case, an implied "good faith" commitment
that there are at least some network resources available is assumed.
This document proposes a Lower Effort Differentiated Services
per-domain behavior [RFC3086] for handling this "optional" traffic
in a differentiated services domain.
There is no intrinsic reason to limit the applicability of the LE PDB
to any particular application or type of traffic. It is intended as an
additional tool for administrators in engineering networks.
Note: where not otherwise defined, terminology used in this document
is defined in [RFC2474].
2. Applicability
A Lower Effort (LE) PDB is for sending extremely non-critical traffic
across a DS domain or DS region. There should be an expectation
that packets of the LE PDB may be delayed or dropped when any other
traffic is present. Its use might assist a network operator in
moving certain kinds of traffic or users to off-peak times.
Alternatively, or in addition, packets can be designated for the LE PDB
where the goal is to protect all other packet traffic from competition
with the LE aggregate while not completely banning LE traffic from
the network. An LE PDB should not be used for a customer's "normal
internet" traffic nor for "downgraded" packets that ought simply to be
dropped as unauthorized. The LE PDB is expected to have applicability
in networks that have at least some unused capacity at some times
of day.
This is a PDB that allows for protecting networks from selected types
of traffic rather than giving a selected traffic aggregate
preferential treatment. Moreover, it may also exploit all unused
resources from other PDBs.
Bless (Ed.) Expires: December, 2002 [Page 2 ]
INTERNET DRAFT June, 2002
3. Technical Specification
3.1 Classification and Traffic Conditioning
There are no required traffic profiles governing rate and bursts
of packets beyond the limits imposed by the ingress link. It is
not necessary to limit the LE aggregate using edge techniques since
its PHB is to be configured such that packets of the aggregate
will be dropped in the network if no forwarding resources are available.
The Differentiated Services Architecture [RFC2475] allows packets
to be marked upstream of the DS domain or at the DS domain's edge.
When packets arrive pre-marked with the DSCP used by the LE PDB,
it should not be necessary for the DS domain boundary to police
that marking; further (MF) classification for such packets would
only be required if there was some reason to suspect the packets
should be marked with some other DSCP.
If there is not an agreement on DSCP marking with the upstream domain,
when a DS domain is using the LE PDB, the boundary must include
a classifier that selects the appropriate LE target group of packets
out of all arriving packets and steers them to a marker which sets
the appropriate DSCP. No other traffic conditioning is required.
3.2 PHB configuration
Either a Class Selector (CS) PHB [RFC2474], an Experimental/Local
Use (EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597]
may be used as the PHB for the LE traffic aggregate. This document
does not specify the exact DSCP to use inside a domain, but instead
specifies the necessary properties of the PHB selected by the DSCP.
If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested.
The PHB used by the LE aggregate inside a DS domain should be configured
so that its packets are forwarded onto the node output link when
the link would otherwise be idle; conceptually, the behavior of
a weighted round-robin scheduler with a weight of zero. An operator
might choose to configure a very small link share for the LE aggregate
and still achieve the desired goals. That is, if the output link
scheduler permits, a small fixed rate might be assigned to the
PHB, but the behavior beyond that configured rate should be that
packets are forwarded only when the link would otherwise be idle.
This behavior could be obtained, for example, by using a CBQ [CBQ]
scheduler with a small share and with borrowing permited. A PHB
that allows packets of the LE aggregate to send more than the configured
rate when packets of other traffic aggregates are waiting for the
link is not recommended.
If a CS PHB is used, note that this configuration will violate the
"SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will
have a less timely forwarding than CS0. An operator's goal of providing
a LE PDB is sufficient cause for violating the SHOULD. If an AF PHB is
used, it must be configured and a DSCP assigned such that it does not
Bless (Ed.) Expires: December, 2002 [Page 3 ]
INTERNET DRAFT June, 2002
violate the "MUST" of paragraph three of section 2 of RFC 2597 [RFC2597]
which provides for a "minimum amount of forwarding resources".
4. Attributes
The ingress and egress flow of the LE aggregate can be measured but
there are no absolute or statistical attributes that arise from the PDB
definition. A particular network operator may configure the DS domain
in such a way that a statistical metric can be associated with
that DS domain. When the DS domain is known to be heavily congested
with traffic of other PDBs, a network operator should expect to
see no (or very few) packets of the LE PDB egress from the domain.
When there is no other traffic present, the proportion of the LE
aggregate that successfully crosses the domain should be limited
only by the capacity of the network relative to the ingress LE
traffic aggregate.
5. Parameters
None required.
6. Assumptions
A properly functioning network.
7. Example uses
7.1 Multimedia applications [this example edited from Yoram Bernet]:
Many network managers want to protect their networks from certain
applications, in particular, from multimedia applications that
typically use such non-adaptive protocols as UDP.
Most of the focus in quality-of-service is on achieving attributes
that are better than Best Effort. These approaches can provide
network managers with the ability to control the amount of multimedia
traffic that is given this improved performance with excess relegated
to Best Effort. This excess traffic can wreak havoc with network
resources even when it is relegated to Best Effort because it is
non-adaptive and because it can be significant in volume and duration.
These characteristics permit it to sieze network resources, thereby
compromising the performance of other, more important applications
that are included in the Best Effort traffic aggregate but that
use adaptive protocols (e.g., TCP). As a result, network managers
often simply refuse to allow multimedia applications to be deployed
in resource constrained parts of their network.
The LE PDB enables a network manager to allow the deployment of
multimedia applications without losing control of network resources.
A limited amount of multimedia traffic may (or may not) be assigned
to PDBs with attributes that are better than Best Effort. Excess
multimedia traffic can be prevented from wreaking havoc with network
resources by forcing it to the LE PDB.
Bless (Ed.) Expires: December, 2002 [Page 4 ]
INTERNET DRAFT June, 2002
7.2 For Netnews and other "bulk mail" of the Internet.
7.3 For "downgraded" traffic from some other PDB.
7.4 For content distribution, Napster traffic, and the like.
7.5 For traffic caused by world-wide web search engines while they
gather information from web servers.
8. Experiences
The authors solicit further experiences for this section. Results
from simulations are presented and discussed in Appendix A.
9. Security Considerations for LE PDB
There are no specific security exposures for this PDB. See the general
security considerations in [RFC2474] and [RFC2475].
10. History of the LE PDB
The previous name of this PDB, "bulk handling", was loosely based on
the United States' Postal Service term for very low priority mail,
sent at a reduced rate: it denotes a lower-cost delivery where the
items are not handled with the same care or delivered with the same
timeliness as items with first-class postage. Finally, the name was
changed to "lower effort", because the authors and other DiffServ WG
members believe that the name should be more generic in order to not
imply constraints on the PDB's use to a particular type of traffic
(namely that of bulk data).
The notion of having something "lower than Best Effort" was raised in
the Diffserv Working Group, most notably by Roland Bless and Klaus
Wehrle in their Internet Drafts [LBE] and [LE] and by Yoram Bernet for
enterprise multimedia applications. One of its first applications was
to re-mark packets within multicast groups. Therefore, previous
discussions centered on the creation of a new PHB which the original
authors (Brian Carpenter and Kathleen Nichols) believe is not
required. This document was specifically written to explain how to get
less than Best Effort without a new PHB.
11. Acknowledgments
Yoram Bernet contributed significant text for the "Examples" section
of this document and other useful comments that helped in editing.
Other Diffserv WG members suggested that the LE PDB is needed for
Napster traffic, particularly at universities. Special thanks go to
Milena Neumann for her extensive efforts in performing the simulations
that are described in Appendix A.
Bless (Ed.) Expires: December, 2002 [Page 5 ]
INTERNET DRAFT June, 2002
12. References
[RFC3086] "Definition of Differentiated Services Per-Domain Behaviors
and Rules for their Specification", K. Nichols, B. Carpenter,
www.ietf.org/rfc/rfc3086.txt
[RFC2474] RFC 2474, "Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers", K. Nichols, S. Blake,
F. Baker, D. Black, www.ietf.org/rfc/rfc2474.txt
[RFC2475] RFC 2475, "An Architecture for Differentiated Services",
S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang,W. Weiss,
www.ietf.org/rfc/rfc2475.txt
[RFC2597] RFC 2597, "Assured Forwarding PHB Group", F. Baker, J.
Heinanen, W. Weiss, J. Wroclawski, www.ietf.org/rfc/rfc2597.txt
[CBQ] S. Floyd and V. Jacobson, Link-sharing and Resource Management
Models for Packet Networks, IEEE/ACM Transactions on Networking,
Vol. 3 No. 4, pp. 365-386, August 1995
[LBE] R. Bless and K. Wehrle, "A Lower Than Best-Effort Per-Hop
Behavior", draft-bless-diffserv-lbe-phb-00.txt, 1999, (work in
progress).
[LE] R. Bless and K. Wehrle, "A Limited Effort Per-Hop Behavior",
draft-bless-diffserv-le-phb-00.txt, 2001, (work in progress).
[SimKIDS] K. Wehrle, J. Reber, V. Kahmann: "A simulation suite for
Internet nodes with the ability to integrate arbitrary Quality of
Service behavior", in Proceedings of Communication Networks And
Distributed Systems Modeling And Simulation Conference (CNDS 2001)
ISBN 1-56555-223-7, pp. 115-122, Phoenix (AZ), USA, Jan. 7-11,
2001.
Authors' Addresses
Brian Carpenter Kathleen Nichols
IBM Research Packet Design
Zuerich Research Laboratory 2465 Latham Street
8803 Rueschlikon Mountain View, CA 94040
Switzerland USA
email: brian@hursley.ibm.com email: nichols@packetdesign.com
Roland Bless Klaus Wehrle
Institute of Telematics Institute of Telematics
Universitaet Karlsruhe (TH) Universitaet Karlsruhe (TH)
Zirkel 2 Zirkel 2
76128 Karlsruhe 76128 Karlsruhe
Germany Germany
email: bless@tm.uka.de email: wehrle@tm.uka.de
Bless (Ed.) Expires: December, 2002 [Page 6 ]
INTERNET DRAFT June, 2002
Appendix A: Experiences from a Simulation Model
A.1 Simulation Environment
The small DiffServ domain shown in figure A.1 was used to simulate the
LE PDB. There are three main sources of traffic (S1-S3) depicted on the
left side of the figure. Source S1 sends 5 aggregated TCP flows (A1-A5)
to the receivers R1-R5 respectively, which have different round trip
times. Each aggregated flow Ax comprises 20 TCP connections. There are
two sources B1 and B2 transferring bulk data through the domain using
100 TCP connections respectively a UDP flow.
...................
. . R1
. . /
. . /-R2
. . /
S1==**=>[BR1] [BR4]==**==>---R3
. \\ // . \
. \\ // . \-R4
. ** ** . \
. \\ // . R5
. \\ // .
S2=++=>[BR2]-++-[IR1]==**==++==::==[IR2] .
(Bulk) . // \\ .
. // :: .
. :: \\ .
. // ++ .
.// \\.
S3==::==>[BR3] [BR5]==++==>R6
(UDP) . . ||
. . ||
. . ::
.................... ||
VV
R7
Flows Protocol Source Destination RTT [ms]
----------------------------------------------------------------------
** : A1,A2,A3,A4,A5 TCP S1 R1,R2,R3,R4,R5 10,25,75,125,250
++ : B1 TCP (bulk) S2 R6 10
:: : B2 UDP (bulk) S3 R7 -
----------------------------------------------------------------------
Figure A.1: A DiffServ domain with different flows
In order to show the benefit of using the LE PDB instead of the
normal Best Effort (BE) PDB [RFC3086], different scenarios are used:
A) B1 and B2 are not present, i.e. the "normal" situation without
bulk data present. A1-A5 use the BE PDB.
B) B1 and B2 use the BE PDB for their traffic, too.
C) B1 and B2 use LE PDB for their traffic
with different PHB implementations:
Bless (Ed.) Expires: December, 2002 [Page 7 ]
INTERNET DRAFT June, 2002
1) PHB with Priority Queueing
2) PHB with Weighted Fair Queueing (WFQ)
3) PHB with Weighted RED (WRED)
4) PHB with WFQ and RED
C1) represents the case where there are no allocated resources for the
LE PDB, i.e. LE traffic is only forwarded if there are unused
resources. In scenarios C2)-C4) a bandwidth share of 10% has been
allocated for the LE PDB. RED parameters were set to w_q=0.1 and
max_p=0.2. In scenario C2) two tail drop queues were used for BE and
LE and WFQ scheduling was set up with a weight of 9:1 for the ratio of
BE:LE. In scenario C3) a total queue length of 200000 bytes was used
and the following thresholds: min_th_BE=19000, max_th_BE=63333,
min_th_LE=2346, max_th=7037. WRED allows to mark packets with BE or LE
within the same microflow (e.g., letting applications pre-mark packets
according to their importance) without causing a reordering of packets
within the microflow. In scenario C4) each queue had a length of 50000
bytes and the same thresholds of min_th=18000 and max_th=48000
bytes. WFQ parameters were the same as in C2).
The link bandwidth between IR1 and IR2 is limited to 1200 kbit/s, thus
creating the bottleneck in the network for the following situations.
In all situations the 20 TCP connections within each aggregated flow
Ax (flowing from S1 to Rx) used the Best Effort PDB. Sender S2
transmitted bulk flow B1 (consisting of 100 TCP connections to R6)
with an aggregated rate of 550 kbit/s, whereas the UDP sender S3
transmitted with a rate of 50 kbit/s.
The following four different situations with varying traffic load
for the Ax flows (at application level) were simulated.
Situation | I | II | III | IV |
----------------------------+------+------+------+------|
Sender Rate S1 [kbit/s] | 1200 | 1080 | 1800 | 800 |
Sender Rate S2 [kbit/s] | 550 | 550 | 550 | 550 |
Sender Rate S3 [kbit/s] | 50 | 50 | 50 | 50 |
Bandwidth IR1 -> IR2 | 1200 | 1200 | 1200 | 1200 |
Best Effort Load (S1) | 100% | 90% | 150% | 67% |
Total load for link IR1->IR2| 150% | 140% | 200% | 117% |
In situation I, there are no unused resources left for the B1 and B2
flows. In situation II, there is a residual bandwidth of 10% of the
bottleneck link between IR1 and IR2. In situation III the traffic load
of A1-A5 is 50% higher than the bottleneck link capacity. In situation
IV, A1-A5 consume only 2/3 of the bottleneck link capacity. B1 and B2
require together 50% of the bottleneck link capacity.
The simulations were performed with the freely available discrete
event simulation tool OMNeT++ and a suitable set of QoS mechanisms
[SimKIDS]. Results from the different simulation scenarios are
discussed in the next section.
A.2 Simulation Results
Bless (Ed.) Expires: December, 2002 [Page 8 ]
INTERNET DRAFT June, 2002
QoS parameters listed in the following tables are averaged over the
first 160s of the transmission. Results of situation I are shown in
Table A.1. When the BE PDB is used for transmission of bulk flows B1
and B2 in case B), one can see that flows A1-A5 throttle their sending
rate to allow transmission of bulk flows B1 and B2. In case C1) not a
single packet is transmitted to the receiver, because all packets get
dropped within IR1, thereby protecting Ax flows from Bx flows. In case
C2) B1 and B2 consume all resources up to the configured limit of 10%
of the link bandwidth, but not more. C3) also limits the share of B1
and B2 flows, but not as precise as with WFQ. C4) shows slightly
higher packet losses for Ax flows due to the active queue management.
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 240 | 71 | 240 | 214 | 225 | 219 |
| | A2 | 240 | 137 | 240 | 216 | 223 | 218 |
| | A3 | 240 | 209 | 240 | 224 | 220 | 217 |
| Throughput | A4 | 239 | 182 | 239 | 222 | 215 | 215 |
| [kbit/s] | A5 | 238 | 70 | 238 | 202 | 201 | 208 |
| | B1 | - | 491 | 0 | 82 | 85 | 84 |
| | B2 | - | 40 | 0 | 39 | 31 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1197 | 669 | 1197 | 1078 | 1084 | 1078 |
| [kbit/s] | bulk | - | 531 | 0 | 122 | 116 | 122 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 0 | 19.3 | 0 | 6.3 | 5.7 | 8.6 |
| | A2 | 0 | 17.5 | 0 | 6.0 | 5.9 | 8.9 |
| | A3 | 0 | 10.2 | 0 | 3.2 | 6.2 | 9.1 |
| Paket Loss | A4 | 0 | 12.5 | 0 | 4.5 | 6.6 | 9.3 |
| [%] | A5 | 0 | 22.0 | 0 | 6.0 | 5.9 | 9.0 |
| | B1 | - | 10.5 | 100 | 33.6 | 38.4 | 33.0 |
| | B2 | - | 19.6 | 100 | 19.9 | 37.7 | 22.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 14.9 | 0 | 5.2 | 6.1 | 9.0 |
| Loss Rate [%] | bulk | 0 | 11.4 | 100 | 29.5 | 38.2 | 29.7 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 21.9 | 12.6 | 21.9 | 19.6 | 20.3 | 20.3 |
+----------------+--------+--------+------+------+------+------+-------+
Table A.1: Situation I - Best Effort traffic uses 100% of the available
bandwidth
Results of situation II are shown in Table A.2: In case C1) LE traffic
gets exactly the 10% residual bandwidth that are not use by the Ax
flows. Cases C2) and C4) show similar results compared to C1), whereas
case C3) also drops unnecessarily packets from flows A1-A5 due to
active queue management.
Bless (Ed.) Expires: December, 2002 [Page 9 ]
INTERNET DRAFT June, 2002
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 216 | 193 | 216 | 216 | 211 | 216 |
| | A2 | 216 | 171 | 216 | 216 | 211 | 216 |
| | A3 | 216 | 86 | 216 | 216 | 210 | 216 |
| Throughput | A4 | 215 | 121 | 215 | 215 | 211 | 215 |
| [kbit/s] | A5 | 215 | 101 | 215 | 215 | 210 | 215 |
| | B1 | - | 488 | 83 | 83 | 114 | 84 |
| | B2 | - | 39 | 39 | 39 | 33 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1078 | 672 | 1077 | 1077 | 1053 | 1077 |
| [kbit/s] | bulk | - | 528 | 122 | 122 | 147 | 122 |
+----------------+--------+--------+------+------+------+----+-+-------+
| | A1 | 0 | 9.4 | 0 | 0 | 1.8 | 0 |
| | A2 | 0 | 14.6 | 0 | 0 | 2.0 | 0 |
| | A3 | 0 | 22.4 | 0 | 0 | 2.1 | 0 |
| Paket Loss | A4 | 0 | 15.5 | 0 | 0 | 1.8 | 0 |
| [%] | A5 | 0 | 17.4 | 0 | 0 | 1.9 | 0 |
| | B1 | - | 11.0 | 32.4 | 32.9 | 35.7 | 33.1 |
| | B2 | - | 21.1 | 20.3 | 20.7 | 34.0 | 22.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 14.9 | 0 | 0 | 1.9 | 0 |
| Loss Rate [%] | bulk | - | 12.0 | 28.7 | 29.1 | 35.3 | 29.8 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 19.8 | 12.8 | 19.8 | 19.8 | 19.5 | 19.8 |
+----------------+--------+--------+------+------+------+------+-------+
Table A.2: Situation II - Best Effort traffic uses 90% of the available
bandwidth
Results of simulations for situation III are depicted in Table A.3.
Due to overload caused by flows A1-A5, their packets get dropped in
all cases. Bulk flows B1 and B2 nearly get their maximum throughput in
case B). As one would expect, in case C1) all packets from B1 and B2
are dropped, in cases C2) and C4) resource consumption of bulk data is
limited to the configured share of 10%. Again the WRED implementation
in C3) is not as accurate as the WFQ variants and lets more BE traffic
pass through IR1.
Bless (Ed.) Expires: December, 2002 [Page 10 ]
INTERNET DRAFT June, 2002
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 303 | 136 | 241 | 298 | 244 | 276 |
| | A2 | 316 | 234 | 286 | 299 | 240 | 219 |
| | A3 | 251 | 140 | 287 | 259 | 236 | 225 |
| Throughput | A4 | 168 | 84 | 252 | 123 | 209 | 219 |
| [kbit/s] | A5 | 159 | 82 | 132 | 101 | 166 | 141 |
| | B1 | - | 483 | 0 | 83 | 73 | 83 |
| | B2 | - | 41 | 0 | 38 | 31 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1199 | 676 | 1199 | 1079 | 1096 | 1079 |
| [kbit/s] | bulk | - | 524 | 0 | 121 | 104 | 121 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 9.6 | 17.6 | 12.1 | 9.3 | 8.6 | 12.8 |
| | A2 | 8.5 | 13.6 | 8.4 | 9.8 | 8.1 | 14.5 |
| | A3 | 8.8 | 18.7 | 7.7 | 11.6 | 7.8 | 13.6 |
| Paket Loss | A4 | 14.9 | 22.3 | 11.2 | 18.9 | 8.2 | 12.4 |
| [%] | A5 | 12.8 | 19.0 | 15.6 | 19.7 | 8.3 | 14.3 |
| | B1 | - | 11.9 | 100 | 32.1 | 39.5 | 33.0 |
| | B2 | - | 17.3 | 100 | 22.5 | 37.7 | 22.8 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 10.4 | 17.3 | 10.3 | 12.2 | 8.2 | 13.4 |
| Loss Rate [%] | bulk | - | 12.4 | 100 | 29.1 | 39.0 | 29.9 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 22.0 | 12.6 | 22.0 | 20.2 | 20.6 | 20.3 |
+----------------+--------+--------+------+------+------+------+-------+
Table A.3: Situation III - Best Effort traffic load is 150%
In situation IV, 33% or 400 kbit/s are not used by Ax flows and the
results are listed in Table A.4. In case B) where bulk data flows B1
and B2 use the BE PDB, packets of Ax flows are dropped, whereas in
cases C1)-C4) flows Ax are protected from bulk flows B1 and
B2. Therefore, by using the LE PDB for Bx flows, the latter get only
the residual bandwidth of 400 kbit/s but not more. Packets of Ax flows
are not affected by Bx traffic in these cases.
Bless (Ed.) Expires: December, 2002 [Page 11 ]
INTERNET DRAFT June, 2002
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 160 | 140 | 160 | 160 | 160 | 160 |
| | A2 | 160 | 124 | 160 | 160 | 160 | 160 |
| | A3 | 160 | 112 | 160 | 160 | 160 | 160 |
| Throughput | A4 | 160 | 137 | 160 | 160 | 159 | 160 |
| [kbit/s] | A5 | 159 | 135 | 159 | 159 | 159 | 159 |
| | B1 | - | 509 | 361 | 362 | 364 | 362 |
| | B2 | - | 43 | 40 | 39 | 38 | 40 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 798 | 648 | 798 | 798 | 797 | 798 |
| [kbit/s] | bulk | - | 551 | 401 | 401 | 402 | 401 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 0 | 9.2 | 0 | 0 | 0 | 0 |
| | A2 | 0 | 12.2 | 0 | 0 | 0 | 0 |
| | A3 | 0 | 14.0 | 0 | 0 | 0 | 0 |
| Paket Loss | A4 | 0 | 9.3 | 0 | 0 | 0 | 0 |
| [%] | A5 | 0 | 6.6 | 0 | 0 | 0 | 0 |
| | B1 | - | 7.3 | 21.2 | 21.8 | 25.0 | 21.3 |
| | B2 | - | 14.3 | 19.4 | 20.7 | 24.5 | 20.7 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 10.2 | 0 | 0 | 0 | 0 |
| Loss Rate [%] | bulk | - | 8.0 | 21.0 | 21.7 | 25.0 | 21.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 14.8 | 12.1 | 14.8 | 14.8 | 14.7 | 14.7 |
+----------------+--------+--------+------+------+------+------+-------+
Table A.4: Situation IV - Best Effort traffic load is 67%
In summary, all the different scenarios show that the "normal" BE
traffic can be protected from traffic in the LE PDB effectively.
Either no packets get through if there is no residual bandwidth left
(LE traffic is starved), or, traffic of the LE PDB can only consume
resources up to a configurable limit.
Mass data transfer affects adversely the "normal" BE traffic (e.g.,
14.9% packet loss in situations I and II, even 10.2% in situation IV)
in situations without using the LE PDB.
As one would expect, the implementation using PQ protects the "normal"
BE traffic very well, but shows problems with TCP connections which
fail after some timeouts. This is because the traffic is completely
starved and not a single packet gets through in case of overload.
The WFQ implementation showed robust behavior, but problems with
synchronized TCP flows. The WRED implementation has the advantage of
maintaining packet order when packets of a single micro-flow are
Bless (Ed.) Expires: December, 2002 [Page 12 ]
INTERNET DRAFT June, 2002
marked as LE and BE intermittently. But the effects depend on the
actual traffic characteristics and packet loss rates are often higher
compared to other locations, whereas the fairness between TCP
connections is better. Therefore, the combined solution of WFQ with
RED showed the overall best behavior. However, the configured minimum
rate for WFQ would often be lower than in the presented
configurations, but prevents TCP connections from breakdown due to
starvation.