RFC 3754
IP Multicast in Differentiated Services (DS) Networks
RFC 3754: IP Multicast in Differentiated Services (DS) Networks 🎀
Okay bestie, this one is RFC 3754, titled IP Multicast in Differentiated Services (DS) Networks 💖. The authors are R. Bless from Univ. of Karlsruhe and K. Wehrle from Univ. of Tuebingen. It's dated April 2004 and its category is Informational 🦋, so it's here to inform rather than set a standard. It doesn't list any documents it obsoletes or updates.
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 (2004). All Rights Reserved.
Abstract 🧚
This doc is about the problems you run into when you use IP Multicast in Differentiated Services (DS) networks, and it builds on what RFC 2475 ("An Architecture of Differentiated Services") already talked about. It also suggests possible fixes for those problems, describes a potential implementation model, and shares simulation results 📊✨.
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Management of Differentiated Services. . . . . . . . . . 2
2. Problems of IP Multicast in DS Domains . . . . . . . . . . . . 3
2.1. Neglected Reservation Subtree Problem (NRS Problem). . . 4
2.2. Heterogeneous Multicast Groups . . . . . . . . . . . . . 12
2.3. Dynamics of Any-Source Multicast . . . . . . . . . . . . 13
3. Solutions for Enabling IP-Multicast in Differentiated
Services Networks. . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Solution for the NRS Problem . . . . . . . . . . . . . . 13
3.2. Solution for Supporting Heterogeneous Multicast Groups . 15
3.3. Solution for Any-Source Multicast. . . . . . . . . . . . 16
4. Scalability Considerations . . . . . . . . . . . . . . . . . . 16
5. Deployment Considerations. . . . . . . . . . . . . . . . . . . 17
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
7. Implementation Model Example . . . . . . . . . . . . . . . . . 18
8. Proof of the Neglected Reservation Subtree Problem . . . . . . 19
8.1. Implementation of the Proposed Solution. . . . . . . . . 20
8.2. Test Environment and Execution . . . . . . . . . . . . . 21
9. Simulative Study of the NRS Problem and Limited Effort PHB . . 23
9.1. Simulation Scenario. . . . . . . . . . . . . . . . . . . 24
9.2. Simulation Results for Different Router Types. . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 31
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 341. Introduction 💅
This doc is about the problems you hit when you use IP Multicast in Differentiated Services (DS) networks, and it builds on RFC 2475 ("An Architecture of Differentiated Services"). It also suggests fixes, describes a potential implementation model, and presents simulation results 🔥.
The "Differentiated Services" (DiffServ or DS) approach [1, 2, 3] sets up certain building blocks and mechanisms so you can get services that are qualitatively better than the usual best-effort delivery in an IP network 🌈. In the DiffServ Architecture [2], scalability comes from not piling complexity and per-flow state onto core nodes, and from pushing the unavoidable complexity out to the network edges 🧠. So individual flows that belong to the same service get aggregated, which means interior nodes don't need complex classification or per-flow state management 🫶.
But here's the tea ☕: the reduced complexity in DS nodes makes it harder to use those "better" services together with IP Multicast (point-to-multipoint or multipoint-to-multipoint communication) 😭. Section 2 covers the problems that come from this. Basic DS forwarding mechanisms also work with IP Multicast, but some things related to provisioning multicast resources have to be considered. It's important to build IP Multicast functionality into the architecture from the beginning, and to provide simple solutions for those problems that won't wipe out the advantages we already gained ✨.
1.1. Management of Differentiated Services 🎀
At least for Per-Domain Behaviors and services based on the EF PHB, admission control and resource reservation are required [14, 15]. Installing and updating traffic profiles in boundary nodes is necessary. Most network administrators cannot do this manually, even for long term service level agreements (SLAs) 😩. On top of that, offering services on demand requires some kind of signaling and automatic admission control procedures.
However, no standardized resource management architecture for DiffServ domains exists 🙈. The rest of this document assumes that at least some logical resource management entity is available to perform resource-based admission control and allotment functions. This entity may also be realized in a distributed fashion, e.g., within the routers themselves. Detailed aspects of how resource management is realized within a DiffServ domain, plus the interactions between resource management and routers or end-systems (e.g., signaling for resources), are out of scope for this document 🚫.
Protocols for signaling a reservation request to a Differentiated Services Domain are required. For end-system signaling to DS domains, RSVP [4] may be used with new DS specific reservation objects [5]. RSVP supports multicast scenarios and is already supported by many systems 🦋. However, using RSVP in a DiffServ multicast context may lead to problems that are also described in the next section. The NSIS Working Group is currently defining new signaling protocols that may behave differently, but the WG is more focused on unicast flows than on multicast flows 👀.
2. Problems of IP Multicast in DS Domains 🔥
Potential problems and the complexity of providing multicast with Differentiated Services are covered in a separate section of [2], but both aspects need a closer look. The simplicity of the DiffServ Architecture and its DS node types is necessary to reach high scalability, but it also causes fundamental problems when you use IP Multicast in DS domains 💀. The subsections below describe these problems, and section 3 proposes a generic solution. This solution is as scalable as IP Multicast and needs no resource separation, because it uses different codepoint values for unicast and multicast traffic 🧚.
Because Differentiated Services are unidirectional by definition, point-to-multipoint communication is also treated as unidirectional. In traditional IP Multicast, any node can send packets spontaneously and asynchronously to a multicast group identified by its multicast group address. In other words, traditional IP Multicast offers a multipoint-to-multipoint service, also called Any-Source Multicast. The implications of this feature are discussed in section 2.3 🌸.
Unless stated otherwise, we assume at least a unidirectional point-to-multipoint scenario, where the sender generates packets that get a "better" Per-Hop-Behavior than the traditional default PHB. That gives a better quality of service than default best-effort. To make this happen, a traffic profile matching the traffic conditioning specification has to be installed in the sender's first DS-capable boundary node. It also must be assured that the matching resources are available on the path from the sender to all the receivers, which may mean adapting traffic profiles at the involved domain boundaries 📋. On top of that, on-demand resource reservations may be receiver-initiated 🙌.
2.1. Neglected Reservation Subtree Problem (NRS Problem) 😱
Usually, resources for Differentiated Services must be reserved before they're used. But in a multicast scenario, group membership is often very dynamic, which limits how useful sender-initiated resource reservation in advance can be. Sadly, when new members join a multicast group using Differentiated Services, they can hurt other existing traffic if resources weren't explicitly reserved before use 💔. A practical proof of this problem is given in section 8.
IP Multicast packet replication usually happens when the packet is handled by the forwarding core (cf. Fig. 1), meaning when it's forwarded and replicated according to the multicast forwarding table. So a DiffServ capable node would also copy the content of the DS field [1] into the IP packet header of every replica. As a result, replicated packets get exactly the same DS codepoint (DSCP) as the original packet, so they get the same forwarding treatment as the incoming packets of this multicast group 🍓. Fig. 1 shows this too, where each egress interface has functions for (BA-) classification, traffic conditioning (TC), and queueing ✨.
Interface A IP Forwarding Interface B
+-----------+ +--------------+ +-----------+
MC-flow | | | replication | | egress |
---->| ingress |---->|------+-------|----->|(class.,TC,|---->
| | | | | | queueing) |
+-----------+ | | | +-----------+
| | |
| | | Interface C
| | | +-----------+
| | | | egress |
| +-------|----->|(class.,TC,|---->
| | | queueing) |
+--------------+ +-----------+
Figure 1: Multicast packet replication in a DS nodeNormally, the replicating node can't check whether a matching resource reservation exists for a particular flow of replicated packets on an output link (its corresponding interface). That's because flow-specific information (e.g., traffic profiles) usually isn't available in every boundary and interior node 🕵️♀️.
When a new receiver joins an IP Multicast group, a multicast routing protocol (e.g., DVMRP [6], PIM-DM [7] or PIM-SM [8]) grafts a new branch onto the existing multicast tree to connect the new receiver 🌳. Because of this tree expansion, plus missing per-flow classification and policing mechanisms, the new receiver ends up implicitly using the better service, thanks to the "better" copied DSCP. Bestie, that's the whole NRS problem in one sentence 💅🫶
If the extra resources that the new part of the multicast tree consumes aren't counted by the domain's resource management (see section 1.1), then the quality of service that other receivers with correct reservations are getting will suffer, or even be violated outright. ✨ This bad side effect of an unaccounted reservation, which we'll call the Neglected Reservation Subtree Problem (NRS Problem) from here on, must be avoided under all circumstances 🚫. Strong admission control at the domain boundary won't stop it either, because the new flow that eats up the resources starts inside the domain 🙈.
There are two main flavours of the NRS Problem 💅. They behave differently depending on where the branching point is. To compare them, let's look at a simple example of how bandwidth gets split up, shown in Fig. 2. The specific PHB types and their bandwidth shares don't matter here, but their relative priority does 🎀.
40% 40% 20%
+--------------------+---------------------+------------+
|Expedited Forwarding| Assured Forwarding | Best-Effort|
+--------------------+---------------------+------------+
---------------------------------------------------------->
output link bandwidthFigure 2: An example bandwidth share of different behavior aggregates
The bandwidth of the output link in question is split among three kinds of service (three behavior aggregates): Expedited Forwarding, Assured Forwarding, and the classic Best-Effort service 🌈. For this example, we're assuming routers do strict priority queueing, where EF gets the highest scheduling priority, AF the middle, and Best-Effort the lowest 👑. A strict non-preemptive priority scheduler is one way to implement EF, though it's not mandatory. It's described in section 5.1.1 of RFC 3247 [15] 🦋. If Weighted Fair Queueing (WFQ) were used instead, the effects would basically still happen, just with minor differences 💜. In the scenarios below, you'll see that PHBs with equal or lower priority (compared to the multicast flow's PHB) get hit by the NRS Problem 😭.
The NRS Problem shows up in two different cases:
- Case 1: If the branching point of the new subtree (at first just a branch) and the previous multicast tree is an (egress) boundary node, as in Fig. 3, the extra multicast flow pushes up the total resources used by that behavior aggregate on the affected output link 📈. That total will be more than the amount originally reserved. So the policing component in the egress boundary node starts dropping packets until the traffic aggregate matches the traffic contract 🚨. But while it's dropping, the router can't tell which flow is responsible (it has no flow classification functionality), so it discards packets at random, whether they belong to a well-behaved flow or not 💀. The result? Flows with properly reserved resources lose their service guarantee entirely 😱.
Sender
+---+
| S | DS domains
+---+ / \
.||............... / \ ................
. || .<- ->. .
. || . . .
. +---+ +--+ +--+ *) +--+ +--+ +--+ +------+
. |FHN|===|IN|=====|BN|###########|BN|####|IN|######|BN|####|Recv.B|
. +---+ +--+ +--+\\ +--+ +--+ +--+ +------+
. \\ \ . \\ . \ .
. +--+ +--+ . \\ . \ .
. |IN|-----|IN| . \\ . +--+ .
. +--+ +--+ . \\ ..........|BN|..
. || \ . +------+ +--+
. || \ . |Recv.A|
.+--+ +--+. +------+
|BN|........|BN|
+--+ +--+
||
S: Sender
Recv.x: Receiver x
FHN: First-Hop Node
BN: Boundary Node
IN: Interior Node
===: Multicast branch with reserved bandwidth
###: Multicast branch without reservation
*) Bandwidth of EF aggregated on the output link is higher than
actual reservation, EF aggregate will be limited in bandwidth
without considering the responsible flow.
Figure 3: The NRS Problem (case 1) occurs when Receiver
B joinsHere's the scenario in Fig. 3 🎬. Receiver A is already hooked up to the egress boundary node (BN) of the first domain. Resources are properly reserved along the path to receiver A, and they're being used by correspondingly marked packets ✅. Then receiver B joins the same group as receiver A. Packets get replicated and sent down the new branch towards the second domain, using the same PHB as receiver A 🍓. If that PHB is EF, the new branch might use up the resources allotted to EF, which hurts the other EF users getting their packets over the link marked with the *) 😤. The BN normally makes sure that outgoing traffic aggregates heading to the next domain follow the agreed traffic conditioning specification 📜. So the egress BN will drop packets of the PHB type that the multicast flow uses 🗑️.
PHBs with lower or higher priority aren't hurt in this case 🙌. Here's an example in Fig. 4 that shows it for two PHBs.
+------------------+---------------------+--------------+------+
| Expedited Forw. | Expedited Forw. | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| EF with and without reservation share | 40 % | 20% |
| 40% of reserved EF aggregate. | | |
| -> EF packets with reservation and | | |
| without reservation will be | | |
| discarded! | | |
+------------------+---------------------+--------------+------+
(a) Excess flow has EF codepoint
+------------------+---------------------+--------------+------+
| Expedited Forw. | Assured Forwarding | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| | AF with & without reservation share| 20 % |
| | 40% of reserved EF aggregate. | |
| 40% | -> EF packets with reservation and | |
| | without reservation will be | |
| | discarded! | |
+------------------+---------------------+--------------+------+
(b) Excess flow has AF codepoint
Figure 4: Resulting share of bandwidth in a egress
boundary node with a neglected reservation of
(a) an Expedited Forwarding flow or (b) an
Assured Forwarding flow.Fig. 4 shows the resulting bandwidth split when the extra multicast branch causing the NRS Problem uses (a) Expedited Forwarding or (b) Assured Forwarding 🧁. Say the additional traffic takes another 30% of the link bandwidth. In Fig. 4 (a), the resulting EF aggregate (70% of the outgoing link bandwidth) gets throttled back down to its originally reserved 40% 📉. That means the amount of dropped EF bandwidth equals the amount of excess bandwidth 🫠. So the original EF aggregate, which had 40% of the link reserved, takes packet losses too 💔. Other services, like AF or Best-Effort, are not disadvantaged 🙅♀️.
Fig. 4 (b) shows the same thing for AF. The only difference is that now AF alone takes the discards, since the other services still get their guarantees 🛡️. Either way, packet losses are kept within the misbehaving service class by the traffic meter and policing mechanisms in the boundary nodes 🚧. Also, this problem (case 1) only happens in egress boundary nodes, because those are responsible for making sure traffic leaving the Differentiated Services domain isn't more than the following ingress boundary node will accept 🛂. So these SLA violations get caught and handled right at the egress BN 🫶.
- Case 2: The NRS Problem can also happen if the branching point between the previous multicast tree and the new subtree is in an interior node (as shown in Fig. 5) 🌸. In Fig. 5, receivers A and B have already joined the multicast group and reserved resources accordingly ✔️. The interior node in the second domain starts replicating multicast packets as soon as receiver C joins 🪄. Because that router has no metering or policing functions, it can't spot any excess traffic and just forwards the new multicast flow 🤷♀️. If that flow belongs to a higher priority service, like Expedited Forwarding, the aggregate's bandwidth on the new branch goes above its reservation and takes bandwidth from lower priority services 😩.
Sender
+---+
| S | DS domains
+---+ / \
.||............... / \ ................
. || .<- ->. .
. || . . .
. +---+ +--+ +--+ +--+ +--+ +--+ +------+
. |FHN|===|IN|=====|BN|===========|BN|====|IN|======|BN|===|Recv.B|
. +---+ +--+ +--+\\ +--+ +--+ +--+ +------+
. \\ \ . \\ . # .
. +--+ +--+ . \\ . # *) .
. |IN|-----|IN| . \\ . +--+ .
. +--+ +--+ . \\ ..........|BN|..
. || \ . +------+ +--+
. || \ . |Recv.A| #
.+--+ +--+. +------+ #
|BN|........|BN| +------+
+--+ +--+ |Recv.C|
|| +------+
FHN: First-Hop Node, BN: Boundary Node, Recv.x: Receiver x
S: Sender, IN: Interior Node
===: Multicast branch with reserved bandwidth
###: Multicast branch without reservation
*) Bandwidth of EF aggregated on the output link is higher than
actual reservation, EF aggregate will be limited in bandwidth
without considering the responsible flowOkay, so the extra EF traffic that has no reservation just hitches a ride with the aggregate that does have one, and bestie, that's actually good news for EF 🫶 As long as the total doesn't go above the output link bandwidth, EF gets zero packet losses. Its higher priority means it grabs as much bandwidth as it needs and as is available 💅 Here's how that plays out for everyone else, in Fig. 6:
+------------------+---------------------+--------------+------+
| Expedited Forw. | Expedited Forw. | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| 40% | 30% | 30% | 0% |
+------------------+---------------------+--------------+------+
EF with reservation and the excess flow use together 70%
of the link bandwidth because EF, with or without reservation,
has the highest priority.
(a) Excess flow has EF codepoint
+------------------+---------------------+--------------+------+
| Expedited Forw. | Assured Forw. | Assured Forw.| BE |
| | | | |
| with reservation | excess flow | with reserv. | |
| | without reservation | | |
+------------------+---------------------+--------------+------+
| 40% | 60% | 0% |
| | (10% loss) | |
+------------------+---------------------+--------------+------+
AF with reservation and the excess flow use together 60%
of the link bandwidth because EF has the highest priority
(-> 40%). 10% of AF packets will be lost.
(b) Excess flow has AF codepoint
Figure 6: Resulting share of bandwidth in an interior
node with a neglected reservation of (a) an
Expedited Forwarding flow or (b) an Assured
Forwarding flowThe result of case 2 is that EF has no restrictions at all 🦋 But look at Fig. 6 (a), because other services get absolutely wrecked by this use of non-reserved resources 💀 Their bandwidth just gets eaten by the new extra flow. Here the additional 30% EF traffic pushes out the AF traffic, which then pushes out the best-effort traffic. The end result is 10% packet losses for the AF aggregate and a complete loss of best-effort traffic 😭
Fig. 6 (b) shows this can also happen with lower priority services like AF 🌸 When a reservation for a lower priority service flow gets neglected, the services below it (even lower priority ones) can lose quality too. In this example that means best-effort. The service whose aggregate causes the NRS problem can get hit too, since 10% of the AF aggregate is discarded. On top of the case 2 problems we just covered, case 1 will show up at the DS boundary node of the next DS domain that does traffic metering and policing for that service aggregate ✨
Directly applying RSVP to Differentiated Services would also cause the NRS Problem for a little while, which is so annoying 🙈 A receiver has to join the IP multicast group to get the sender's PATH messages before it can send a resource reservation request (RESV message). So the join itself, on the link that carries PATH messages, can trigger the NRS Problem unless it's handled specially. One example of a special handling is marking all PATH messages with codepoint 0 and dropping or re-marking all other data packets of the multicast flow.
2.2. Heterogeneous Multicast Groups
Heterogeneous multicast groups have one or more receivers who want a different service or quality of service than the sender provides, or than other receiver subsets are currently using 🌈 A super important thing Differentiated Services should support is that participants who only want best-effort quality can still join a group communication that otherwise uses a better service class 💖 The next step up is supporting concurrent use of more than two different service classes within one group. And it gets even more complicated when you don't just need different service classes, but also different values for quality parameters inside a certain service class 😵💫
Another problem is supporting heterogeneous groups with different service classes in a consistent way. Some services aren't comparable to each other, so one service can't be swapped out for another. Both services then have to be provided over the same link within that group 🎀
Here's the tricky part. Any new receiver that wants the different service can be grafted onto any point of the current multicast delivery tree. That means even interior nodes might have to replicate packets using the different service 👑 At first glance this seems to contradict the simplicity of interior nodes, since they don't even have a profile available but would now need to convert the service or quality for individual receivers. So to make this work, interior nodes have to change the codepoint value during packet replication 🧚
2.3. Dynamics of Any-Source Multicast
Basically, within an IP multicast group, any participant can act as a sender. Honestly, it can even be a host that isn't receiving packets from this multicast group at all 🙌 This is a big feature that should also work when the group uses a specific service other than best-effort. But Differentiated Services is, conceptually, unidirectional, so it's kind of a one-way street 🛣️ For every multicast tree implied by a sender, resources must be reserved separately if simultaneous sending should be possible with a better service. This is true even when shared multicast delivery trees are used, like with PIM-SM or Core Based Trees. If a multicast tree allows more than one participant to send at the same time and not enough resources are reserved for a service within it, the NRS problem happens again 😭
The same logic applies to half-duplex reservations, where several senders would share the reserved resources. The network can't guarantee that exactly one sender is transmitting to the group at any given time, so it doesn't work. That's why the corresponding RSVP reservation styles "Wildcard Filter" and "Shared-Explicit Filter" [4] cannot be supported within Differentiated Services 🚫 Integrated Services can handle the half-duplex nature of the traffic, though, because every router can check each packet against the installed reservation state. Iconic for them 💅
3. Solutions for Enabling IP-Multicast in Differentiated Services Networks
Okay, so the problems in the last section mostly come from how simple the Differentiated Services architecture is 🍓 Any solution has to avoid adding extra complexity, or else it would weaken the scalability that makes DiffServ so good. This document suggests a straightforward solution for most of the problems ✨
3.1. Solution for the NRS Problem ✨
okay so the solution is basically three steps, and I'll go into way more detail later 🫶
- a new receiver joins a multicast group that's already using a DiffServ service. multicast routing protocols connect the new branch to the (possibly already existing) multicast delivery tree like they normally do 🌸
- to stop unauthorized resource use, branching nodes re-mark all the extra packets heading down the new branch. at first the new receiver gets every packet of the group without quality of service 💅 the management entity of the correspondent DiffServ domain might get told about the tree getting bigger
- if a pre-issued reservation exists for the new branch, or somebody (receiver, sender or a third party) makes one, the management entity tells the branching router to set the matching codepoint for the service that was asked for ✨
usage of resources that weren't reserved has to be prevented, bestie, no exceptions 🙅♀️ so picture this: a new receiver joins a DS multicast group, and that means grafting a new branch onto a multicast delivery tree that already exists. the node where the two trees meet converts the codepoint (and therefore the Per-Hop Behavior) to one for a PHB that's similar to the default PHB, so the new branch gets a best-effort-like service 🍓 honestly this PHB can even be worse than the default PHB's best-effort. see RFC 3662 [16] for a matching Lower Effort Per-Domain Behavior 🦋
why do we even do this? it's to avoid unfairness inside the best-effort aggregate. the incoming multicast traffic uses a lot more resources, and if the rate of re-marked packets going into the outgoing aggregate isn't reduced, those packets will probably knock out other flows' packets in that aggregate when resources are scarce 😭
so the re-marked packets from this group should get dropped more aggressively than the other packets in that outgoing aggregate. you can do this with an appropriately configured PHB (and a related DSCP) for those packets. to tell this PHB apart from the default one, it's called the Limited Effort (LE) PHB throughout this document (it can be realized by an appropriately configured AF PHB [9] or Class Selector Compliant PHB [1]) 💜 dropping packets more aggressively at the re-marking node by itself isn't enough, though. the outgoing behavior aggregate (BA) might have room to send every re-marked packet without discarding any other packets in the same BA, but resources in the next node could be short for that particular BA. those "excess" packets have to be identifiable at this node, periodt 💀
re-marking is only needed at branching nodes. every other node in the multicast tree (the ones with outdegree 1) just replicates packets as usual 🧚 and since a branching node can also be an interior node of a domain, re-marking conceptually needs per-flow classification. yes, that sounds like it clashes with the DiffServ idea of a core that avoids per-flow state, but IP multicast flows are different from unicast flows. traditional IP multicast forwarding and multicast routing already have to install state per multicast group for every outgoing link anyway. so re-marking in interior nodes scales to the same extent as IP multicast (cf. section 4) 🌈
re-marking with standard DiffServ mechanisms [10] for every new branch needs a default traffic profile to be activated. that profile does the re-marking with a combination of an MF-classifier and a marker on an outgoing link that makes up a new branch. the classifier sends all the replicated packets to a marker that sets the new codepoint. there's an alternative implementation described in section 7 if you want it 💖
the better service only gets provided if a reservation request was processed and approved by the resource management function. so an admission control test has to be done before resources are actually used by the new branch. if the admission test passes, the resource management tells the re-marking node to stop re-marking and use the original codepoint again (conceptually, by removing the profile) ✨
so in summary, only receivers that reserved the resources in the new branch ahead of time, with help from resource management, get a better service inside a DiffServ multicast group. everyone else gets a quality that could be even lower than best-effort 😭🫠
3.2. Solution for Supporting Heterogeneous Multicast Groups 🌸
quick scope check: in this document we're only looking at providing different service classes, not different quality parameters within one service class 💅
the concept from section 3.1 is a limited solution to the heterogeneity problem, lowkey. receivers can get a Limited Effort service without a reservation, so a multicast group can have at least two different service classes at once. that means any receiver can join the multicast session without getting any quality of service at all 🦋 this is useful if a receiver just wants to check whether the group's content is interesting enough before asking for a better service that has to be paid for (kind of like snooping into a group without a prior reservation 👀)
or a receiver might not be able to get the better quality of service (for example, because it's mobile and using a wireless link with limited capacity). but it might be happy with the reduced quality instead of getting no content at all 🫶
also, applying the RSVP concept of listening for PATH messages before sending any RESV message is feasible again. without the proposed solution, this would have caused the NRS Problem 😭
theoretically, the approach in section 7 also supports more than two services within one multicast group, because the extra field in the multicast routing table can store any DSCP value. but this only works if PHBs can be ordered, so that the "best" PHB among the different required PHBs downstream gets forwarded on a specific link. honestly that's mainly a management issue and it's out of scope for this document 🧚
more advanced concepts could also support conditional re-marking based on the group address and DSCP value. this is useful if the group uses different PHBs (for example, for flows to different transport protocol ports) and the re-marking should also depend on the DSCP value of an incoming packet 🌈
3.3. Solution for Any-Source Multicast 💜
every participant would have to start an explicit reservation to make sure they can send to the group with a better service quality, no matter whether other senders in the group are already using the same service class at the same time. that would need a separate reservation for each sender-rooted multicast tree 😩
BUT, in the specific case of best-effort service (the default PHB), participants can still send packets to the group anytime without any extra mechanisms 🎀 the reason is that the first DS-capable boundary node marks those packets with the DSCP of the default PHB, because there's no traffic profile for that particular sender. so the first DS-capable boundary nodes should always classify multicast packets based on both the sender's address and the multicast group address 💖
4. Scalability Considerations 🦋
the proposed solution doesn't add complexity to the DS architecture or to a DS node, and it doesn't change the scalability properties of DiffServ either 🫶 with current IP multicast routing protocols, a multicast router has to manage and hold state information for every multicast flow passing through it. the suggested solution scales to the same extent as IP multicast itself, because the proposed re-marking can happen per branch of a multicast flow. this re-marking is logically tied to an addition to the multicast routing state that's needed anyway ✨ so re-marking packets for multicast flows in interior nodes isn't treated as a scalability problem, and it isn't in contradiction with the DiffServ approach itself 💅
it's important to tell the multicast case apart from the existing, justifiable scalability concerns about re-marking packets of unicast flows inside interior routers 👀 also, the router doesn't decide when to change a re-marking policy. a management entity does that, on a time scale that's different from the time scale of packet forwarding 🌸
5. Deployment Considerations 🧚
the solution proposed in section 3.1 can be deployed on most router platforms available today. architectures that do routing and forwarding in software could be updated with a new software release 💜
that said, there may be some specialized hardware platforms that can't deploy the solution from section 7 yet. this could happen when a multicast packet gets duplicated directly on the backplane of the router, so all the outgoing interfaces read the packet in parallel 😵💫 then the codepoint can't be changed for a subset of those outgoing interfaces, and the NRS problem can not be solved directly at the branching point 🫠
in this case there are several alternative solutions:
- as mentioned in section 3.1, if traffic conditioning mechanisms can be applied to outgoing packets at the individual output interfaces, a combination of classifier and marker may be used for each branch 🎀
- the codepoint change for subtrees without properly allocated resources could happen in the following downstream router. there, for every incoming packet of the considered multicast group, the codepoint would be changed to the value the previous router should have set. if a LAN (for example, a high-speed switching LAN) is attached to the considered outgoing interface, then on every router connected to the LAN, packets of the considered group should be changed on the incoming interface using standard DiffServ mechanisms 🌈
future releases of router architectures may support changing the codepoint directly in the replication process, as proposed in section 7 ⭐
6. Security Considerations 🔐
Okay bestie, so basically the security considerations in [1] apply. 💅 The proposed solution does not imply new security aspects. ✨ If a join of arbitrary end-systems to a multicast group is not desired (thereby receiving a lower than best-effort quality), the application usually has to exclude these participants. 🫶 This can be accomplished by using authentication, authorization, or ciphering techniques at the application level, just like in traditional IP multicast scenarios.
Moreover, it is important to consider the security of the corresponding management mechanisms, because they are used to activate re-marking of multicast flows. 🚨 On one hand, functions for instructing the router to mark or re-mark packets of multicast flows are super attractive targets for theft of service attacks 💀. On the other hand, their security depends on the router management mechanisms that are used to realize this functionality. Router management should generally be protected against unauthorized use, which prevents those attacks as well 🔒.
7. Implementation Model Example 🧚
One possibility of implementing the proposed solution from section 3.1 is described in the following. 🍓 It has to be emphasized that other realizations are also possible, and this description should not be understood as a restriction on potential implementations. The benefit of the following implementation is that it does not require any additional classification of multicast groups within an aggregate. ✨ It serves as a proof of concept that no additional complexity is necessary to implement the proposed general solution described in section 3. It's giving clean design 👑.
Because every multicast flow has to be considered by the multicast routing process (in this context, this notion signifies the multicast forwarding part and not the multicast route calculation and maintenance part, cf. Fig. 1), adding an extra byte in each multicast routing table entry containing the DS field, and thus its DS codepoint value per output link (resp. virtual interface, see Fig. 8), results in nearly no additional cost 🤯. Packets will be replicated by the multicast forwarding process, so this is also the right place for setting the correct DSCP values of the replicated packets. Their DSCP values are not copied from the incoming original packet. Instead, they come from the additional DS field in the multicast routing table entry for the corresponding output link (only the DSCP value must be copied, while the two remaining bits are ignored and are present for simplification reasons only). This field initially contains the codepoint of the LE PHB if incoming packets for this specific group do not carry the codepoint of the default PHB.
When a packet arrives with the default PHB, the outgoing replicates should also get the same codepoint, so that current common multicast groups using the default PHB keep their behavior 🌈. A router configuration message changes the DSCP values in the multicast routing table and may also carry the new DSCP value that should be set in the replicated packets. It should be noted that although re-marking may also be performed by interior nodes, the forwarding performance will not be decreased, because the decision of when and what to re-mark is made by the management (control plane) 🧠✨.
Multicast Other List
Destination Fields of
Address virtual Inter- DS
interfaces face ID Field
+--------------------------------+ +-------------------+
| X | .... | *-------------------->| C | (DSCP,CU) |
|--------------------------------| +-------------------+
| Y | .... | *-----------+ | D | (DSCP,CU) |
|--------------------------------| | +-------------------+
| ... | .... | ... | |
. . . . | +-------------------+
. ... . .... . ... . +-------->| B | (DSCP,CU) |
+--------------------------------+ +-------------------+
| ... | .... | ... | | D | (DSCP,CU) |
+--------------------------------+ +-------------------+
| ... | ... |
. . .
. . .
Figure 8: Multicast routing table with additional
fields for DSCP values8. Proof of the Neglected Reservation Subtree Problem 🧪
In the following, it is shown that the NRS problem actually exists and occurs in reality 😭. So the problem and its solution were investigated using a standard Linux Kernel (v2.4.18) and the Linux-based implementation KIDS [11].
Furthermore, the proposed solution for the NRS problem has been implemented by enhancing the multicast routing table, as well as the multicast routing behavior in the Linux kernel 🔥. In the following section, the modifications are briefly described.
Additional measurements with the simulation model simulatedKIDS [12] will be presented in section 9. 📊 They show the effects of the NRS problem in more detail, and also the behavior of the BAs using or not using the Limited Effort PHB for re-marking.
8.1. Implementation of the Proposed Solution 🛠️
As described in section 3.1, the proposed solution for avoiding the NRS Problem is an extension of each routing table entry in every multicast router by one byte. In the Linux OS, the multicast routing table is implemented by the Multicast Forwarding Cache (MFC). The MFC is a hash table consisting of an mfc-cache-entry for each combination of the following three parameters: sender's IP address, multicast group address, and incoming interface.
The routing information in an mfc-cache-entry is kept in an array of TTLs for each virtual interface. When the TTL is zero, a packet matching this mfc-cache-entry will not be forwarded on this virtual interface. Otherwise, if the TTL is less than the packet's TTL, the latter will be forwarded on the interface with a decreased TTL.
In order to set an appropriate codepoint if bandwidth is allocated on an outgoing link, we added a second array of bytes, similar to the TTL array, for specifying the codepoint that should be used on a particular virtual interface. The first six bits of the byte contain the DSCP that should be used, and the seventh bit indicates whether the original codepoint in the packet has to be changed to the specified one (=0) or has to be left unchanged (=1). The default entry of the codepoint byte is zero, so initially all packets will be re-marked to the default DSCP 🎀.
Furthermore, we modified the multicast forwarding code to consider this information while replicating multicast packets. To change an mfc-cache-entry, we implemented a daemon for exchanging the control information with a management entity (e.g., a bandwidth broker). Currently, the daemon uses a proprietary protocol, but migration to the COPS protocol (RFC 2748) is planned 🦋.
8.2. Test Environment and Execution 🧪
Okay bestie, time for the receipts 🧾✨ Figure 8.1 is the testbed. It's a smaller version of the network from Figure 5, so it's not the full setup, but it still proves the point. It has two DS-capable nodes, an ingress boundary node and an egress boundary node. Interior nodes aren't needed because leaving them out doesn't change the proof at all 💅
Sender
+---+ FHN: First Hop Node
| S | BN: Boundary Node
+---+
+#
+#
+#
+---+ +--+ +------+
|FHN|++++++++++++|BN|+++++++++++| host |
| |############| |***********| B |
+---+ +--+## +------+
+# #
+# #
+# #
+------+ +------+
|host A| |host C|
+------+ +------+
+++ EF flow (group1) with reservation
### EF flow (group2) with reservation
*** EF flow (group2) without reservation
Figure 8.1: Evaluation of NRS-Problem described in
Figure 3So this is the whole point: we wanted to prove case 1 of the NRS problem from section 2.1 🫶 The lab had two Personal Computers (Pentium III at 450 Mhz, 128 MB Ram, 3 network cards Intel eepro100) acting as DiffServ nodes, plus one sender and three receiver systems (also PCs) 🖥️ KIDS was installed on the routers, and mrouted (Multicast Routing Daemon) handled multicast routing. Everything was wired up with separate 10BaseT Ethernet segments in full-duplex mode.
Now, the performance question, because nobody wants bottleneck drama 🙄 [11] tested the software routers, and even a PC at 200Mhz handled up to 10Mbps DS traffic on each link with no problem. So the results you're about to see are not because the software routers were slow. They're the actual NRS effect 💯
The sender generated two shaped UDP flows, each at 500kbps with 1.000 byte constant-size packets 📦 One went to multicast group 1 (233.1.1.1) and the other to group 2 (233.2.2.2). In both measurements, receiver A had a reservation along the path to the sender for each flow, receiver B had reserved for flow 1, and receiver C had reserved for flow 2 🌸 That meant the ingress boundary node got two static profiles, each with 500kbps EF bandwidth and a token bucket size of 10.000 bytes.
On the egress boundary node, there was one profile for the output link to host B and one for the output link to host C 🎀 Each one permits up to 500kbps Expedited Forwarding, but only the total EF traffic on the outgoing link counts. That's the detail that makes this whole thing spicy 🌶️
In measurement 1, hosts A and B joined group 1, and A, B, and C joined group 2. Those joins used a reservation for the group toward the sender. The only join without an admitted reservation was host B joining group 2 😳 Per section 2.1, that's exactly what triggers the NRS problem (case 1). The metering and policing in the egress boundary node squeezed the EF aggregate down to the reserved 500kbps, and that squeeze doesn't care whether individual flows were reserved or not.
+--------+--------+--------+
| Host A | Host B | Host C |
+---------+--------+--------+--------+
| Group 1 | 500kbps| 250kbps| 500kbps|
+---------+--------+--------+--------+
| Group 2 | 500kbps| 250kbps| |
+---------+--------+--------+--------+
Figure 8.2: Results of measurement 1 (without the
proposed solution): Average bandwidth of
each flow.
--> Flows of group 1 and 2 on the link to
host B share the reserved aggregate of
group 1.Here's the tea ☕ Figure 8.2 shows the results. Hosts A and C got their flows with zero interference, living their best lives 🦋 But host B only got half the reserved bandwidth for group 1, so half of those packets were discarded 😭 Receiver B ended up with the full amount for groups 1 and 2 combined, which is exactly the reserved 500kbps. Flow 2 got Expedited Forwarding even though nobody reserved any bandwidth for it, and it also broke group 1's guarantee on that link. Not it 💀
For measurement 2, the solution from section 3.1 was installed in the boundary node 🔧 Now, while duplicating packets, the node checks whether the codepoint has to be changed to Best-Effort (or Limited Effort), or whether the packet can just be duplicated as is. In this run, it changed the codepoint for group 2 on the link to host B to Best-Effort 🙌
+--------+--------+--------+
| Host A | Host B | Host C |
+---------+--------+--------+--------+
| Group 1 | 500kbps| 500kbps| 500kbps|
+---------+--------+--------+--------+
| Group 2 | 500kbps| 500kbps| |
+---------+--------+--------+--------+
Figure 8.3: Results of measurement 1 (with the
proposed solution): Average bandwidth of
each flow.
--> Flow of group 1 on the link to host B
gets the reserved bandwidth of group 1.
The flow of group 2 has been re-marked to
Best-Effort.And the glow-up is real ✨ Figure 8.3 shows that each host got its flows at the reserved bandwidth with no packet loss at all 🎉 The group 2 packets were re-marked in the boundary node, so they were treated as best-effort traffic. They got the same bandwidth as the Expedited Forwarding flow, and since there wasn't much other traffic on the link, nothing had to be dropped 🌈
So yeah, the measurements confirm that the Neglected Reservation Subtree problem is to be taken seriously, and that the presented solution does fix it 👑
9. Simulative Study of the NRS Problem and Limited Effort PHB 🌸
This section is all about the simulation results 📊 It shows that the proposed solution works correctly, and what happens when the responsible flow gets re-marked to Limited Effort. We already proved the NRS problem in section 8 and in [13], so this part focuses on the benefit for regular Best Effort traffic when Limited Effort is used for re-marking instead of Best Effort. Spoiler: the results strongly motivate using Limited Effort 💜
9.1. Simulation Scenario 🧪
Here's the setup 📝 In this scenario, the boundary nodes had a link speed of 10 Mpbs, and the Interior Routers had a link speed of 12 Mbps. On the boundary nodes, a 5 Mbps aggregate was reserved for EF.
When Limited Effort was used, LE got 10% of the capacity (0.5Mpbs) from the original BE aggregate, and BE got the other 90% (4.5Mbps) of that original BE aggregate capacity 🍓 The bandwidth between LE and BE is shared using WFQ scheduling.
The topology looks like this, where Sx is a sender, BRx is a boundary node, IRx is an interior node, and Dx is a destination/receiver 🗺️
+--+ +--+ +---+ +--+
|S1| |S0| /=|BR5|=====|D0|
+--+ +--+ // +---+ +--+
\\ || //
\\ || //
+--+ \+---+ +---+ +---+ +---+ +--+
|S2|===|BR1|=====|IR1|=====|IR2|======|BR3|=====|D1|
+--+ +---+ /+---+ +---+ +---+ +--+
// \\ +--+
// \\ /=|D2|
+--+ +---+ // \\ // +--+
|S3|===|BR2|=/ +---+/
+--+ +---+ /=|BR4|=\
|| +--+ // +---+ \\ +--+
+--+ |D4|=/ \=|D3|
|S4| +--+ +--+
+--+
Figure 9.1: Simulation TopologyNext up is the flow table 💅 It shows the flows in the simulation runs. For example, EF0 is sent from sender S0 to destination D0 at 4 Mbps using an EF reservation ✨ The presented cases (I to IV) use different amounts of BE traffic, so we can see what Limited Effort does in each one. The intention behind each of the four cases is explained right after the table.
+----+--------+-------+----------+-----------+-----------+---------+
|Flow| Source | Dest. | Case I | Case II | Case III | Case IV |
+----+--------+-------+----------+-----------+-----------+---------+
| EF0| S0 | D0 | 4 Mbps | 4 Mbps | 4 Mbps | 4 Mbps |
+----+--------+-------+----------+-----------+-----------+---------+
| EF1| S1 | D1 | 2 Mbps | 2 Mbps | 2 Mbps | 2 Mbps |
+----+--------+-------+----------+-----------+-----------+---------+
| EF2| S2 | D2 | 5 Mbps | 5 Mbps | 5 Mbps | 5 Mbps |
+----+--------+-------+----------+-----------+-----------+---------+
| BE0| S3 | D3 | 1 Mbps | 2.25 Mbps | 0.75 Mbps |3.75 Mbps|
+----+--------+-------+----------+-----------+-----------+---------+
| BE1| S4 | D4 | 4 Mbps | 2.25 Mbps | 0.75 Mbps |3.75 Mbps|
+----+--------+-------+----------+-----------+-----------+---------+
Table 9.1: Direction, amount and Codepoint of flows in the four
simulation cases (case I to IV)A few rules for the sim 🤓 All the EF sources sent constant-rate traffic with constant packet sizes over UDP. The BE sources also sent constant-rate traffic, but BE0 used UDP and BE1 used TCP as its transport protocol.
Now the four cases 🎭 Each one has its own vibe:
- Case I: The BE sources sent exactly 5 Mbps together, so there's no congestion in the BE queue.
- Case II: BE is sending less than 5 Mbps, so there's room in the BE queue for re-marked traffic. BE0 and BE1 together send 4.5 Mbps, which is exactly BE's share when LE is in use. So when multicast packets get re-marked to LE because of the NRS problem, LE should get 0.5 Mbps and BE should get 4.5 Mbps, which is still enough for BE0 and BE1. LE should not act greedy and should not take resources from BE 🫶
- Case III: BE is very low. BE0 and BE1 only use 1.5 Mbps together. So when LE is used, it should be able to use the unused bandwidth from BE 🌊
- Case IV: BE0 and BE1 send 7.5 Mbps together, so the BE queue is congested. In this case, LE should get 0.5 Mbps, not more and not less ⚖️
In every scenario, the loss rate and throughput of the flows and aggregates under consideration were measured 📈
9.2. Simulation Results for Different Router Types 🌈
9.2.1. Interior Node ✨
okay so when the branching point of a new multicast subtree lands in an interior node, the NRS problem can totally pop off, like we talked about in section 2.1 (Case 2) 💅
for these next four subsections, D3 joins the multicast group of sender S0 and doesn't make any reservation or resource allocation 🫶 so a new branch just gets added to the existing multicast tree 🌳 the branching point from D3's join is IR2, and on the link to BR3 there's no bandwidth allocated for the new flow (EF0) 😭
the next four subsections show the metered throughput of flows on the link between IR2 and BR3 across four different cases 📊 column two is the situation before the new receiver joins, column three is after the join without the proposed solution, and column four is what happens when we use the proposed solution from section 3.1 and the responsible flow gets re-marked to LE 🦋
9.2.1.1. Case I:
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.007 Mbps | LE0: 0.504 Mbps |
|achieved| EF1: 2.001 Mbps | EF1: 2.003 Mbps | EF1: 2.000 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 5.009 Mbps | EF2: 5.000 Mbps |
|put | BE0: 1.000 Mbps | BE0: 0.601 Mbps | BE0: 1.000 Mbps |
| | BE1: 4.000 Mbps | BE1: 0.399 Mbps | BE1: 3.499 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.003 Mbps | EF: 11.019 Mbps | EF: 7.000 Mbps |
|through-| BE: 5.000 Mbps | BE: 1.000 Mbps | BE: 4.499 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 87.4 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 34.8 % | BE0: 0 % |
| | BE1: 0 % | BE1: 59.1 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE09.2.1.2. Case II:
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.003 Mbps | LE0: 0.500 Mbps |
|achieved| EF1: 2.000 Mbps | EF1: 2.001 Mbps | EF1: 2.001 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 5.005 Mbps | EF2: 5.002 Mbps |
|put | BE0: 2.248 Mbps | BE0: 0.941 Mbps | BE0: 2.253 Mbps |
| | BE1: 2.252 Mbps | BE1: 0.069 Mbps | BE1: 2.247 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.002 Mbps | EF: 11.009 Mbps | EF: 7.003 Mbps. |
|through-| BE: 4.500 Mbps | BE: 1.010 Mbps | BE: 4.500 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 87.4 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 58.0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 57.1 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE09.2.1.3. Case III:
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 3.998 Mbps | LE0: 3.502 Mbps |
|achieved| EF1: 2.000 Mbps | EF1: 2.001 Mbps | EF1: 2.001 Mbps |
|through-| EF2: 5.000 Mbps | EF2: 5.002 Mbps | EF2: 5.003 Mbps |
|put | BE0: 0.749 Mbps | BE0: 0.572 Mbps | BE0: 0.748 Mbps |
| | BE1: 0.749 Mbps | BE1: 0.429 Mbps | BE1: 0.748 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.000 Mbps | EF: 11.001 Mbps | EF: 7.004 Mbps |
|through-| BE: 1.498 Mbps | BE: 1.001 Mbps | BE: 1.496 Mbps |
|put | LE: --- | LE: --- | LE: 3.502 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 12.5 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 19.7 % | BE0: 0 % |
| | BE1: 0 % | BE1: 32.6 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE09.2.1.4. Case IV:
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 4.001 Mbps | LE0: 0.500 Mbps |
|achieved| EF1: 2.018 Mbps | EF1: 2.000 Mbps | EF1: 2.003 Mbps |
|through-| EF2: 5.005 Mbps | EF2: 5.001 Mbps | EF2: 5.007 Mbps |
|put | BE0: 2.825 Mbps | BE0: 1.000 Mbps | BE0: 3.425 Mbps |
| | BE1: 2.232 Mbps | BE1: --- | BE1: 1.074 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 7.023 Mbps | EF: 11.002 Mbps | EF: 7.010 Mbps |
|through-| BE: 5.057 Mbps | BE: 1.000 Mbps | BE: 4.499 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: 0 % | LE0: 75.0 % |
|packet | EF1: 0 % | EF1: 0 % | EF1: 0 % |
|loss | EF2: 0 % | EF2: 0 % | EF2: 0 % |
|rate | BE0: 23.9 % | BE0: 73.3 % | BE0: 0 % |
| | BE1: 41.5 % | BE1: --- | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF0 is re-marked to LE and signed as LE0NOTE: BE1 has undefined throughput and loss in situation "after join (no re-marking)", because TCP is going into retransmission back-off timer phase and closes the connection after 512 seconds. 😭💀
9.2.2. Boundary Node 🌸
when the branching point of a new multicast subtree is in a boundary node, the NRS problem can happen too, like in section 2.1 (Case 1) 🧚
same deal for the next four subsections 💖 D3 joins the multicast group of sender S1 with no reservation or resource allocation, so a new branch gets added to the existing tree 🌿 this time the branching point is BR3, and on the link to BR4 there's no bandwidth allocated for the new flow (EF1) 🙈
we're tracking the metered throughput on the link between BR3 and BR4 across four cases 📈 column two is before the new receiver joins, column three is after the join without the proposed solution, and column four is the proposed solution from section 3.1 with the responsible flow re-marked to LE 🎀
9.2.2.1. Case I:
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.489 Mbps | LE1: 0.504 Mbps |
|through-| EF2: 5.002 Mbps | EF2: 3.512 Mbps | EF2: 5.002 Mbps |
|put | BE0: 1.000 Mbps | BE0: 1.000 Mbps | BE0: 1.004 Mbps |
| | BE1: 4.000 Mbps | BE1: 4.002 Mbps | BE1: 3.493 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.002 Mbps | EF: 5.001 Mbps | EF: 5.002 Mbps |
|through-| BE: 5.000 Mbps | BE: 5.002 Mbps | BE: 4.497 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 25.6 % | LE1: 73.4 % |
|loss | EF2: 0 % | EF2: 29.7 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE19.2.2.2. Case II:
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.520 Mbps | LE1: 0.504 Mbps |
|through-| EF2: 5.003 Mbps | EF2: 3.482 Mbps | EF2: 5.002 Mbps |
|put | BE0: 2.249 Mbps | BE0: 2.249 Mbps | BE0: 2.245 Mbps |
| | BE1: 2.252 Mbps | BE1: 2.252 Mbps | BE1: 2.252 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.003 Mbps | EF: 5.002 Mbps | EF: 5.002 Mbps |
|through-| BE: 4.501 Mbps | BE: 4.501 Mbps | BE: 4.497 Mbps |
|put | LE: --- | LE: --- | LE: 0.504 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 24.0 % | LE1: 74.8 % |
|loss | EF2: 0 % | EF2: 30.4 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+
(*) EF1 is re-marked to LE and signed as LE19.2.2.3. Case III: 🌈
okay so Case III is where things get spicy 🌶️ and the table is literally giving rainbow 🌈 Read the columns left to right: before the join, after the join with no re-marking, and after the join with EF1 re-marked to LE. The bottom two rows are the BA throughput and the packet loss rate, so you can compare them at a glance 💅
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.084 Mbps | LE1: 2.000 Mbps |
|through-| EF2: 5.001 Mbps | EF2: 3.919 Mbps | EF2: 5.000 Mbps |
|put | BE0: 0.749 Mbps | BE0: 0.752 Mbps | BE0: 0.750 Mbps |
| | BE1: 0.749 Mbps | BE1: 0.748 Mbps | BE1: 0.750 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.001 Mbps | EF: 5.003 Mbps | EF: 5.000 Mbps |
|through-| BE: 1.498 Mbps | BE: 1.500 Mbps | BE: 1.500 Mbps |
|put | LE: --- | LE: --- | LE: 2.000 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 45.7 % | LE1: 0 % |
|loss | EF2: 0 % | EF2: 21.7 % | EF2: 0 % |
|rate | BE0: 0 % | BE0: 0 % | BE0: 0 % |
| | BE1: 0 % | BE1: 0 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+(*) EF1 is re-marked to LE and signed as LE1
9.2.2.4. Case IV: 💜
Last one, bestie 😭 Case IV has the same three-column setup, but the numbers are way messier. Look at what happens to EF1 and BE0/BE1 once the join goes through, and then check how the re-marked version shakes things up. It's a lot, but you've got this 🫶
+--------+-----------------+-----------------+------------------+
| | before join | after join |after join, |
| | | (no re-marking) |(re-marking to LE)|
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|achieved| EF1: --- | EF1: 1.201 Mbps | LE1: 0.500 Mbps |
|through-| EF2: 5.048 Mbps | EF2: 3.803 Mbps | EF2: 5.004 Mbps |
|put | BE0: 2.638 Mbps | BE0: 2.535 Mbps | BE0: 3.473 Mbps |
| | BE1: 2.379 Mbps | BE1: 2.536 Mbps | BE1: 1.031 Mbps |
+--------+-----------------+-----------------+------------------+
|BA | EF: 5.048 Mbps | EF: 5.004 Mbps | EF: 5.004 Mbps |
|through-| BE: 5.017 Mbps | BE: 5.071 Mbps | BE: 4.504 Mbps |
|put | LE: --- | LE: --- | LE: 0.500 Mbps |
+--------+-----------------+-----------------+------------------+
| | EF0: --- | EF0: --- | EF0: --- |
|packet | EF1: --- | EF1: 40.0 % | LE1: 68.6 % |
|loss | EF2: 0 % | EF2: 23.0 % | EF2: 0 % |
|rate | BE0: 30.3 % | BE0: 32.1 % | BE0: 0 % |
| | BE1: 33.3 % | BE1: 32.7 % | BE1: 0 % |
+--------+-----------------+-----------------+------------------+(*) EF1 is re-marked to LE and signed as LE1
10. Acknowledgements ✨
The authors wish to thank Mark Handley and Bill Fenner for their valuable comments on this document. Special thanks go to Milena Neumann for her extensive efforts in performing the simulations. We would also like to thank the KIDS simulation team [12]. Big love to everyone who helped make this happen 💖
11. References 📚
11.1. Normative References
- [1] 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.
- [2] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
11.2. Informative References
- [3] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
- [4] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1", RFC 2205, September 1997.
- [5] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
- [6] Waitzman, D., Partridge, C. and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
- [7] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, L., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
- [8] Adams, A., Nicholas, J. and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM) Protocol Specification (Revised)", Work in Progress.
- [9] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group" RFC 2597, June 1999.
- [10] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal Management Model for DiffServ Routers", RFC 3290, May 2002.
- [11] R. Bless, K. Wehrle. Evaluation of Differentiated Services using an Implementation under Linux, Proceedings of the Intern. Workshop on Quality of Service (IWQOS'99), London, 1999.
- [12] K. Wehrle, J. Reber, V. Kahmann. A simulation suite for Internet nodes with the ability to integrate arbitrary Quality of Service behavior, Proceedings of Communication Networks And Distributed Systems Modeling And Simulation Conference (CNDS 2001), Phoenix (AZ), January 2001.
- [13] R. Bless, K. Wehrle. Group Communication in Differentiated Services Networks, Internet QoS for the Global Computing 2001 (IQ 2001), IEEE International Symposium on Cluster Computing and the Grid, May 2001, Brisbane, Australia, IEEE Press.
- [14] Davie, B., Charny, A., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
- [15] Charny, A., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C. and K.K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002.
- [16] Bless, R., Nichols, K. and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
12. Authors' Addresses 📮
Comments and questions related to this document can be addressed to one of the authors listed below. 🦋
Roland Bless
Institute of Telematics
Universitaet Karlsruhe (TH)
Zirkel 2
76128 Karlsruhe, Germany
Phone: +49 721 608 6413
EMail: bless@tm.uka.de
URI: http://www.tm.uka.de/~bless
Klaus Wehrle
University of Tuebingen
WSI - Computer Networks and Internet /
Protocol Engineering & Distributed Systems
Morgenstelle 10c
72076 Tuebingen, Germany
EMail: Klaus.Wehrle@uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/~wehrle/13. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 🔐
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society.
📦 where this page comes from
- ietf: rfc3754 2004-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms