doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc3662.txt b/doc/rfc/rfc3662.txt
new file mode 100644
index 0000000..032b8bd
--- /dev/null
+++ b/doc/rfc/rfc3662.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                           R. Bless
+Request for Comments: 3662                            Univ. of Karlsruhe
+Category: Informational                                       K. Nichols
+                                                              Consultant
+                                                               K. Wehrle
+                                                 Univ. of Tuebingen/ICSI
+                                                           December 2003
+
+
+  A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  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, where prolonged starvation indicates network problems.  In
+   this sense, the proposed 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 permits a network
+   operator 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 is intended for traffic of
+   sufficiently low value (where "value" may be interpreted in any
+   useful way by the network operator), in which all other traffic takes
+   precedence over LE 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 viewpoint, it can be
+
+
+
+
+
+Bless, et al.                Informational                      [Page 1]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+   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" (BE) traffic since the network makes no commitment to deliver
+   LE packets.  In contrast, BE traffic receives an implied "good faith"
+   commitment of at least some available network resources.  This
+   document proposes a Lower Effort Differentiated Services per-domain
+   behavior (LE PDB) [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 as 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 other traffic is
+   present.  Use of the LE PDB 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 when 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 should packets be "downgraded" to the LE PDB
+   for use as a substitute for dropping packets that ought to simply be
+   dropped as unauthorized.  The LE PDB is expected to be applicable to
+   networks that have some unused capacity at some times of day.
+
+   This is a PDB that allows networks to protect themselves 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, et al.                Informational                      [Page 2]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+3.  Technical Specification
+
+3.1.  Classification and Traffic Conditioning
+
+   There are no required traffic profiles governing the 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 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 for the packets to be marked with a
+   different DSCP.
+
+   If there is not an agreement on a DSCP marking with the upstream
+   domain for a DS domain 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 that 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, this is 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 permitted.  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.
+
+
+
+
+Bless, et al.                Informational                      [Page 3]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+   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
+   an 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 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
+
+   o  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 seize network resources, thereby compromising the
+      performance of other, more important applications that are
+
+
+
+Bless, et al.                Informational                      [Page 4]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+      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.
+
+   o  For Netnews and other "bulk mail" of the Internet.
+
+   o  For "downgraded" traffic from some other PDB when this does not
+      violate the operational objectives of the other PDB or the overall
+      network.  As noted in section 2, LE should not be used for the
+      general case of downgraded traffic, but may be used by design,
+      e.g., when multicast is used with a value-added DS-service and
+      consequently the Neglected Reservation Subtree problem [NRS]
+      arises.
+
+   o  For content distribution, peer-to-peer file sharing traffic, and
+      the like.
+
+   o  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
+   Working Group members believe that the name should be more generic in
+   order to not imply constraints on the PDB's use to a particular type
+
+
+
+Bless, et al.                Informational                      [Page 5]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+   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 [NRS].
+   Therefore, previous discussions centered on the creation of a new
+   PHB.  However, the original authors (Brian Carpenter and Kathleen
+   Nichols) believe this is not required and this document was written
+   to specifically explain how to get less than Best Effort without a
+   new PHB.
+
+11.  Acknowledgments
+
+   Yoram Bernet contributed significant amounts of text for the
+   "Examples" section of this document and provided 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, et al.                Informational                      [Page 6]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+Appendix A.  Experiences from a Simulation Model
+
+   The intention of this appendix is to show that a Lower Effort PDB
+   with a behavior as described in this document can be realized with
+   different implementations and PHBs respectively.  Overall, each of
+   these variants show the desired behavior but also show minor
+   differences in certain traffic load situations.  This comparison
+   could make the choice of a realization variant interesting for a
+   network operator.
+
+A.1.  Simulation Environment
+
+   The small DiffServ domain shown in Figure 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 five aggregated TCP
+   flows (A1-A5) to the receivers R1-R5 respectively.  Each aggregated
+   flow Ax consists of 20 TCP connections, where each aggregate
+   experiences a different round trip time between 10ms and 250ms.
+   There are two sources of bulk traffic.  B1 consists of 100 TCP
+   connections sending as much data as possible to R6 and B2 is a single
+   UDP flow also sending as much as possible to R7.
+
+                      ...................
+                    .                     .                R1
+                  .                        .              /
+                .                           .            /-R2
+               .                             .          /
+     S1==**=>[BR1]                          [BR4]==**==>---R3
+             . \\                           // .        \
+            .   \\                         //   .        \-R4
+            .    **                       **     .        \
+            .     \\                     //      .         R5
+            .      \\                   //       .
+   S2=++=>[BR2]-++-[IR1]==**==++==::==[IR2]      .
+   (Bulk)   .      //                    \\      .
+            .     //                      ::     .
+            .    ::                        \\    .
+             .  //                          ++  .
+              .//                            \\.
+    S3==::==>[BR3]                           [BR5]==++==>R6
+    (UDP)       .                           . ||
+                 .                         .  ||
+                   .                      .   ::
+                     ....................     ||
+                                              VV
+                                              R7
+
+            Figure 1: A DiffServ domain with different flows
+
+
+
+Bless, et al.                Informational                      [Page 7]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+   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:
+
+         1) PHB with Priority Queueing (PQ)
+         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 with 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 with 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Bless, et al.                Informational                      [Page 8]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+   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
+
+   QoS parameters listed in the following tables are averaged over the
+   first 160s of the transmission.  Results of situation I are shown in
+   Figure 2.  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 precisely as
+   with WFQ.  C4) shows slightly higher packet losses for Ax flows due
+   to the active queue management.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bless, et al.                Informational                      [Page 9]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
++-------------------------+--------+-----------------------------------+
+|                         |        |   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 |
++----------------+--------+--------+------+------+------+------+-------+
+
+      Figure 2: Situation I - Best Effort traffic uses 100% of the
+                          available bandwidth
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bless, et al.                Informational                     [Page 10]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+Bless, et al.                Informational                     [Page 11]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+   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%
+
+
+
+
+
+
+
+
+
+Bless, et al.                Informational                     [Page 12]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+   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.
+
+
+
+
+Bless, et al.                Informational                     [Page 13]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bless, et al.                Informational                     [Page 14]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+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.
+
+
+
+
+
+
+
+
+
+Bless, et al.                Informational                     [Page 15]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+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/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bless, et al.                Informational                     [Page 16]
+
+RFC 3662                    Lower Effort PDB               December 2003
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bless, et al.                Informational                     [Page 17]
+