| | 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 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 2: Situation I - Best Effort traffic uses 100% of the
available bandwidth
Results of situation II are shown in Figure 3. In case C1), LE
traffic gets exactly the 10% residual bandwidth that is not used by
the Ax flows. Cases C2) and C4) show similar results compared to
C1), whereas case C3) also drops packets from flows A1-A5 due to
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 | 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 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 3: Situation II - Best Effort traffic uses 90% of the
available bandwidth
Results of simulations for situation III are depicted in Figure 4.
Due to overload caused by flows A1-A5, 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.
+-------------------------+--------+-----------------------------------+
| | | 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 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 4: 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 Figure 5. 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.
+-------------------------+--------+-----------------------------------+
| | | 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 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 5: 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 no residual bandwidth is left (LE
traffic is starved), or traffic of the LE PDB can only consume
resources up to a configurable limit.
Furthermore, the results substantiate that mass data transfer can
adversely affect "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.
Thus, while all presented variants of realizing the LE PDB meet the
desired behavior of protecting BE traffic, they also show small
differences in detail. A network operator has the opportunity to
choose a realization method to fit the desired behavior (showing this
is - after the proof of LE’s efficacy - the second designation of
this appendix). For instance, if operators want to starve LE traffic
completely in times of congestion, they could choose PQ. This causes
LE traffic to be completely starved and not a single packet would get
through in case of full load or overload.
On the other hand, for network operators who want to permit some
small amount of throughput in the LE PDB, one of the other variants
would be a better choice.
Referring to this, the WFQ implementation showed a slightly more
robust behavior with PQ, but had problems with synchronized TCP
flows. WRED behavior is highly dependent on the actual traffic
characteristics and packet loss rates are often higher compared to
other implementations, while the fairness between TCP connections is
better. The combined solution of WFQ with RED showed the overall
best behavior, when an operator’s intent is to keep a small but
noticeable throughput in the LE PDB.
Normative References
[RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules for
their Specification", RFC 3086, April 2001.
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
Informative References
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[CBQ] Floyd, S. 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] Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop
Behavior", Work in Progress, September 1999.
[LE] Bless, R. and K. Wehrle, "A Limited Effort Per-Hop
Behavior", Work in Progress, February 2001.
[SimKIDS] Wehrle, K., Reber, J. and 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), Phoenix (AZ), USA,
pp. 115-122, January 2001.
[NRS] Bless, R. and K. Wehrle, "Group Communication in
Differentiated Services Networks", in Proceedings of IEEE
International Workshop on "Internet QoS", Brisbane,
Australia, IEEE Press, pp. 618-625, May 2001.
Authors’ Addresses
Roland Bless
Institute of Telematics, Universitaet Karlsruhe (TH)
Zirkel 2
76128 Karlsruhe
Germany
EMail: bless@tm.uka.de
URI: http://www.tm.uka.de/~bless/
Kathleen Nichols
325M Sharon Park Drive #214
Menlo Park, CA 94025
EMail: knichols@ieee.org
Klaus Wehrle
University of Tuebingen, Computer Networks and Internet
Morgenstelle 10c, 72076 Tuebingen, Germany &
International Computer Science Institute (ICSI)
1947 Center Street, Berkeley, CA, 94704, USA
EMail: Klaus.Wehrle@uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/~wehrle/
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.