RFC 3662
A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services
RFC 3662: A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services 🎀 (part 1 of 4)
okay bestie, let's get into it 💅 this one is by R. Bless (Univ. of Karlsruhe), K. Nichols (Consultant), and K. Wehrle (Univ. of Tuebingen/ICSI). It's Informational, dated December 2003, and the header doesn't list anything it obsoletes or updates 🦋
Status of this Memo ✨
This memo gives information to the Internet community. It is not a standard of any kind. Distribution is unlimited.
Copyright Notice 🌸
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract 💜
okay so this doc proposes a differentiated services per-domain behavior (PDB) whose traffic is allowed to get "starved" 🥺 (starvation isn't strictly required though). Normally on the Internet, "best-effort" or "normal" traffic going hungry for ages is a sign something is broken 😭 but here it's kind of the whole point. The PDB's traffic gets a "lower" priority than normal best-effort traffic, so it's called "Lower Effort" (LE) 🧚
the big perk is that a network operator can strictly limit how much LE traffic affects best-effort traffic or any other Internet traffic 🙌 the doc has some example uses, but it does NOT restrict LE to any particular kind of traffic. it's giving flexibility 💖
1. Description of the Lower Effort PDB ✨
this doc proposes a differentiated services per-domain behavior [RFC3086] called "Lower Effort" (LE). it's meant for traffic of sufficiently low value, where "value" can mean whatever makes sense to the network operator 💅 basically, all other traffic gets to eat first when it comes to network link bandwidth, and LE gets the leftovers 🍓
"low value" can mean low priority in time, and that doesn't automatically mean it's unimportant 👀 think of it like background priority for processes in an operating system. it's the network version of that. LE traffic may or may not get memory (buffer) resources allocated to it, and that's totally optional 🫶
some networks carry traffic where delivery is optional. those packets should only use network resources when no other traffic is around 🙈 or the effect of that traffic on everything else is strictly capped. this is different from "best-effort" (BE) traffic, because the network makes no promise to deliver LE packets at all. BE traffic gets an implied "good faith" promise of at least some available resources 🥹 this doc proposes the LE PDB [RFC3086] for handling that "optional" traffic inside a differentiated services domain.
there's no built-in reason to limit LE to one application or type of traffic. it's just another tool for admins running engineered networks 🛠️✨
Note: where a term isn't otherwise defined, it means what it means 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 LE packets may get delayed or dropped when other traffic is around. ✨ this is the caveat: the lowercase "should" here is just plain English and doesn't carry a requirement level. Using the LE PDB can help a network operator move certain kinds of traffic or users to off-peak times 🌙 Or both, or in addition: packets can be marked for LE when the goal is to protect all other traffic from competing with the LE aggregate, without totally banning LE traffic from the network 🫧
here's the important bit: an LE PDB should not be used for a customer's "normal internet" traffic 🙅♀️ and packets should not be "downgraded" to LE as a substitute for dropping packets that should just be dropped as unauthorized. nope nope nope 💀 The LE PDB is expected to fit networks that have some unused capacity at some times of day ⏰
this PDB lets networks protect themselves from selected types of traffic, instead of giving a chosen traffic aggregate preferential treatment 👑 It may also soak up all the unused resources from other PDBs 🦋
3. Technical Specification 💅
3.1. Classification and Traffic Conditioning 🎀
there are no required traffic profiles controlling the rate and bursts of packets, beyond the limits set by the ingress link 🙌 LE doesn't need edge techniques to limit its aggregate, because its PHB is set up so packets in the aggregate get dropped inside the network if no forwarding resources are free. ✨
the differentiated services architecture [RFC2475] lets packets be marked upstream of the DS domain or at the domain's edge 🌸 When packets show up already marked with the DSCP used by the LE PDB, the DS domain boundary shouldn't need to police that marking 🫶 Further (MF) classification for those packets would only be needed if there was some reason to mark them with a different DSCP.
If there's no agreement on a DSCP marking with the upstream domain, the boundary must include a classifier 🔥 that picks out the right LE target group of packets from everything that arrives, 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] can be used as the PHB for the LE traffic aggregate 💖 This doc doesn't specify the exact DSCP to use inside a domain. Instead, it specifies the properties the PHB needs to have, based on the DSCP that selects it. 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 set up so its packets get forwarded onto the node's output link when the link would otherwise be idle 😌 Conceptually, that's what a weighted round-robin scheduler with a weight of zero does 🦋
operators might choose to give the LE aggregate a very small link share and still get the goals they want ✨ If the output link scheduler allows it, a small fixed rate can be assigned to the PHB, but beyond that configured rate, packets should only be forwarded when the link would otherwise be idle 🙈 One example of this is a CBQ [CBQ] scheduler with a small share and borrowing permitted 🎀 A PHB that lets LE packets send more than the configured rate while packets from other traffic aggregates are waiting for the link is not recommended 🚫
now, if a CS PHB is used, this setup will violate the "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474], since CS1 gets less timely forwarding than CS0 😬 But the operator's goal of providing an LE PDB is reason enough to break that SHOULD, and the doc says so openly 🫶 If an AF PHB is used, it must be configured and given a DSCP so it doesn't 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 the PDB definition doesn't produce any absolute or statistical attributes ✨ A particular operator can configure the DS domain so a statistical metric gets associated with it 📊 When the DS domain is known to be heavily congested with traffic from other PDBs, an operator should expect to see no (or very few) LE packets leave the domain 🌧️ When there's no other traffic around, the share of LE traffic that makes it across the domain is limited only by the network's capacity relative to the incoming LE aggregate ☀️
5. Parameters 💜
None required. 🫧
6. Assumptions 🧚
A properly functioning network. 💅
7. Example uses 🌈
- Multimedia applications [this example edited from Yoram Bernet]:
okay, so a lot of network managers want to protect their networks from certain applications, especially multimedia apps that usually run over non-adaptive protocols like UDP 😤
most of the QoS focus is on getting attributes better than Best Effort 🙌 Those approaches let managers control how much multimedia traffic gets that improved performance, with the excess pushed down to Best Effort 📉 But that excess can wreak havoc on network resources even at Best Effort, because it doesn't adapt and it can be huge in volume and duration 💀 It can seize resources and wreck the performance of more important applications in the Best Effort aggregate that use adaptive protocols (like TCP) 😭 So managers often just refuse to let multimedia apps be deployed in resource-constrained parts of their network 🙈
the LE PDB lets a manager allow multimedia apps to be deployed without losing control of network resources 🫶 A limited amount of multimedia traffic may (or may not) be assigned to PDBs with better-than-Best-Effort attributes 💖 Excess multimedia traffic can be kept from wreaking havoc by forcing it into the LE PDB 🦋
- For Netnews and other "bulk mail" of the Internet. 📰
- For "downgraded" traffic from some other PDB, when that doesn't 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. It may be used by design, though, e.g., when multicast is used with a value-added DS-service and the Neglected Reservation Subtree problem [NRS] shows up 🌸
- For content distribution, peer-to-peer file sharing traffic, and the like. 🍓
- For traffic caused by world-wide web search engines while they gather information from web servers. 🕸️
8. Experiences 🎀
The authors are soliciting 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 ✨
okay so the OG name for this PDB was "bulk handling" 📦. It was loosely based on the US Postal Service's super low priority mail, the stuff sent at a reduced rate 💌. It basically means cheaper delivery where things aren't handled with the same care or arrive on the same timeline as first-class postage. Eventually it got renamed to "lower effort" 🎀 because the authors and other DiffServ WG members felt the name should be more generic, so it doesn't seem like it's only for one kind of traffic (aka bulk data) 💅
The idea of something "lower than Best Effort" got raised in the Diffserv WG, most notably by Roland Bless and Klaus Wehrle in their Internet Drafts [LBE] and [LE], and by Yoram Bernet for enterprise multimedia apps 🎬. One of its first uses was re-marking packets within multicast groups [NRS] 🦋. So earlier chats were all about creating a brand new PHB 🤔. BUT the original authors (Brian Carpenter and Kathleen Nichols) don't think a new PHB is required 🙅♀️, and this doc was written to specifically explain how to get less than Best Effort without one ✨.
11. Acknowledgments 🫶
Yoram Bernet wrote a whole lot of the "Examples" section and gave other super helpful comments while editing ✍️. Other Diffserv WG members suggested the LE PDB is needed for Napster traffic, especially at universities 🎓. Huge thanks to Milena Neumann for her extensive work running the simulations described in Appendix A 👑.
Appendix A. Experiences from a Simulation Model 🧪
The point of this appendix is to show that a Lower Effort PDB with the behavior described in this document can be realized with different implementations and PHBs 🌈. Overall, each variant shows the desired behavior, but there are minor differences in certain traffic load situations. This comparison could make picking a realization variant pretty 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 traffic sources (S1-S3) 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, and 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 flowsIn 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 packets to be marked 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, which creates 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 at 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 📊
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), you 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.
+-------------------------+--------+-----------------------------------+
| | | 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 bandwidthResults of situation II are shown in Figure 3. In case C1), LE traffic gets exactly the 10% residual bandwidth that isn't 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
Okay, situation III is where things get spicy 🔥😭 The results are in Figure 4! Because the A1-A5 flows overload the link, packets get dropped in every single case. Bulk flows B1 and B2 basically hit their near-max throughput in case B) 🚀. As you'd expect, in case C1) every packet from B1 and B2 gets dropped 💀, and in C2) and C4) the bulk data stays capped at the configured 10% share 🎀. The WRED one in C3) is lowkey not as precise as the WFQ variants, and it lets more BE traffic slip 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%
Situation IV is giving 🌸 Here, 33% (that's 400 kbit/s) isn't used by the Ax flows, and the results are in Figure 5. In case B), where bulk flows B1 and B2 use the BE PDB, the Ax packets get dropped 😩. But in C1)-C4), the Ax flows are protected from B1 and B2. So when the Bx flows use the LE PDB, they only get that residual 400 kbit/s and not a drop more 🧚. The Ax packets aren't 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%
The big takeaway 👑 is that every scenario shows "normal" BE traffic can be protected from LE PDB traffic, and it works effectively. Either nothing gets through when there's no residual bandwidth left (the LE traffic is starved 💀), or LE traffic can only eat resources up to a configurable limit 💅.
The results also prove that mass data transfer can seriously hurt "normal" BE traffic when the LE PDB isn't used. We're talking 14.9% packet loss in situations I and II (e.g., that's the vibe), and even 10.2% in situation IV 😭.
So yeah, all the presented ways of realizing the LE PDB hit the goal of protecting BE traffic, but they show small differences in the details 🦋. A network operator gets to pick the realization method that fits the behaviour they want (showing this is the second designation of this appendix, after proving LE's efficacy 💖). For example, if operators want to starve LE traffic completely during congestion, they could choose PQ. That makes LE traffic completely starved, so not a single packet gets through at full load or overload 🧊.
On the other hand, if network operators want to let some small amount of throughput through the LE PDB, one of the other variants is a better choice 🌈.
Referring to this, the WFQ implementation was slightly more robust with PQ, but it had problems with synchronized TCP flows 🙃. WRED's behaviour is highly dependent on the actual traffic characteristics, and its packet loss rates are often higher than the other implementations, while fairness between TCP connections is better 🍓. The combined WFQ with RED solution showed the overall best behaviour 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.orgKlaus 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 ✨
Okay so this part is the legal stuff, and I'm keeping the wording exactly as written so nobody can say I changed the rules 💅
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. Honestly, the people keeping these documents tidy deserve all the flowers 🫶
📦 where this page comes from
- ietf: rfc3662 2003-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms