RFC 3086
Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification
Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification 🎀
Okay bestie, so this is RFC 3086 🦋 It's an Informational doc from April 2001, which means it's sharing knowledge rather than setting an official standard, and it's from the Network Working Group. The authors are K. Nichols from Packet Design and B. Carpenter from IBM. Nothing is listed as obsoleted or updated in this title block. Iconic start, honestly ✨
Status of This Memo 📜
Quick legal vibe check: this memo gives info to the Internet community. It is not an Internet standard of any kind, and it can be distributed freely 💅
Copyright Notice ⚖️
Copyright (C) The Internet Society (2001). All Rights Reserved. 🔒
Abstract ✨
Okay so Differentiated Services (diffserv) gives you Quality of Service inside a single network domain 🌈 Edge rules bundle packets into traffic aggregates, then each aggregate gets tagged with a codepoint in the IP header so it gets a specific forwarding path treatment. The diffserv WG already defined the general architecture and focused on the per-hop forwarding behaviors (PHBs) that routers need. They also talked about the edge stuff, like classifiers that pick out traffic and traffic conditioners (think policing and shaping) that tune it according to the rules. If the QoS goals change short-term, you only need to tweak the edge configuration. Interior nodes don't necessarily have to be reconfigured 🧚
The next step is figuring out how PHBs, classifiers, and traffic conditioners can team up to build traffic aggregates whose packets get specific forwarding characteristics as they cross a DS domain. The WG chose the term per-domain behavior (PDB) for the treatment a particular set of packets gets while crossing a DS domain. A PDB is described by specific metrics that measure the treatment packets with a particular DSCP (or set of DSCPs) receive across the domain 💖 A PDB specifies a forwarding path treatment for a traffic aggregate. Because the edge and PHB configuration choices shape its final attributes, a PDB is exactly where the forwarding path and the control plane interact, which is so iconic. The measurable parameters of a PDB should be suitable for use in Service Level Specifications at the network edge 📊
This document defines and discusses Per-Domain Behaviors in detail. It lays out the format and required content for contributions to the Diffserv WG on PDBs, plus the procedure that applies when individual PDB specifications advance as WG products. The format is specified to speed up WG review of PDB submissions 🫶
Table of Contents 📚
1. Introduction ................................................ 2
2. Definitions ................................................. 4
3. The Value of Defining Edge-to-Edge Behavior ................. 5
4. Understanding PDBs .......................................... 7
5. Format for Specification of Diffserv Per-Domain Behaviors ...13
6. On PDB Attributes ...........................................16
7. A Reference Per-Domain Behavior .............................19
8. Guidelines for Advancing PDB Specifications .................21
9. Security Considerations .....................................22
10. Acknowledgements ............................................22
References ..................................................22
Authors' Addresses ..........................................23
Full Copyright Statement ....................................241 Introduction 🌸
Differentiated Services is giving modular, incrementally deployable, and scalable IP Quality of Service, and it barely adds any complexity per node [RFC2475]. From the end user's point of view, QoS should be supported end-to-end between any pair of hosts 🫶 Honestly though, that goal isn't attainable right now. It will need interdomain QoS support, and there are still a lot of untaken steps on the road to get there 😭 One big essential step is the evolution of business models for interdomain QoS, and that will develop outside the IETF. The Diffserv WG's goal is to provide the solid technical foundation that lets those business models grow 💅 The first major step is supporting edge-to-edge or intradomain QoS between the ingress and egress of one network. That's a DS Domain in RFC 2474 terms 🎀 The plan is that this edge-to-edge QoS should be composable, in a purely technical sense, into quantifiable QoS across a DS Region made of multiple DS domains ✨
The Diffserv WG has finished phase one of standardizing the forwarding path behaviors that every network node needs, the per-hop forwarding behaviors or PHBs 🦋 The PHBs defined in RFCs 2474, 2597 and 2598 are a rich toolbox for handling packets differently in individual boxes 🧰 The general architectural model for diffserv is documented in RFC 2475. An informal router model [MODEL] describes traffic conditioning and other forwarding behaviors. But technical issues still remain when we try to go "beyond the box" to intradomain QoS models 👀
The ultimate goal is scalable end-to-end QoS across the Internet, and that requires us to identify and quantify the behavior of a group of packets that stays preserved when those packets get aggregated with other packets while they traverse the Internet 🌈 The step of specifying forwarding path attributes on a per-domain basis, for packets distinguished only by the mark in the DS field of each packet, is critical for the evolution of Diffserv QoS. It should also give the technical input that helps build business models 💜 This document defines and specifies the term "Per-Domain Behavior" or PDB to describe QoS attributes across a DS domain ✨
Diffserv classification and traffic conditioning get applied to packets arriving at the boundary of a DS domain. They impose restrictions on how the resulting traffic aggregates get composed inside the domain, as distinguished by the DSCP marking 🎀 The classifiers and traffic conditioners are set to reflect the policy and traffic goals of that domain, and they may be specified in a TCA (Traffic Conditioning Agreement) 📜 Once packets have crossed the DS boundary, following diffserv principles makes it possible to group packets solely by the behavior they receive at each hop, as selected by the DSCP. This approach has well-known scaling advantages, both in the forwarding path and in the control plane 🦋 But here's the less-talked-about part: those scaling properties only happen if the per-hop behavior definition gives rise to a particular kind of invariance under aggregation 🙈 The per-hop behavior has to be equivalent at every node in the domain, while the set of packets marked for that PHB may be different at every node. So PHBs should be defined such that their characteristics don't depend on the traffic volume of the associated BA on a router's ingress link, nor on a particular path through the DS domain that the packets take 🌸 Specifically, different streams of traffic that belong to the same traffic aggregate merge and split as they traverse the network. If the properties of a PDB using a particular PHB hold no matter how the temporal characteristics of the marked traffic aggregate change as it crosses the domain, then that PDB scales 💖 (Clearly this assumes that numerical parameters, like the bandwidth allocated to a particular PDB, may be different at different points in the network, and may be adjusted dynamically as traffic volume varies.) If there are limits to where the properties hold, that becomes a limit on the size or topology of a DS domain that can use that PDB 😬 Single-link DS domains might exist, but what we really need for scalable end-to-end quality of service are PDBs that are invariant with network size, or that have simple relationships with network size and whose properties can be recovered by reapplying rules. That means forming another diffserv boundary or edge to re-enforce the rules for the traffic aggregate 🧩
There's a clear distinction between a Per-Domain Behavior defined inside a DS domain and a service that might be specified in a Service Level Agreement 💅 The PDB definition is a technical building block. It couples classifiers, traffic conditioners, specific PHBs, and particular configurations with a resulting set of specific observable attributes, which can be characterized in a variety of ways 🧚 These definitions are meant to be useful tools for configuring DS domains. But the PDBs a provider uses aren't expected to be visible to customers, any more than the specific PHBs in the provider's network would be 🙈 Network providers are expected to pick their own measures to make customer-visible in contracts. Those measures may be stated quite differently from the technical attributes in a PDB definition, though the configuration of a PDB might be taken from a Service Level Specification (SLS) 📊 Similarly, specific PDBs are intended as tools that ISPs can use to build differentiated services offerings. Each ISP may choose different sets of tools, or even develop its own, in order to hit particular externally observable metrics 🌈 Still, the measurable parameters of a PDB are expected to be among the parameters cited directly or indirectly in the Service Level Specification component of a corresponding SLA ✨
This document defines Differentiated Services Per-Domain Behaviors and specifies the format that must be used for submissions of particular PDBs to the Diffserv WG 🎀
2 Definitions 💅
okay bestie, these definitions are stated in RFCs 2474 and 2475, and they get repeated here so you don't have to go digging 🎀
- Behavior Aggregate: a collection of packets with the same codepoint crossing a link in a particular direction. 🦋
- Differentiated Services Domain: a contiguous portion of the Internet over which a consistent set of differentiated services policies are administered in a coordinated fashion. A differentiated services domain can represent different administrative domains or autonomous systems, different trust regions, different network technologies (e.g., cell/frame), hosts and routers, etc. Also DS domain. 🌸
- Differentiated Services Boundary: the edge of a DS domain, where classifiers and traffic conditioners are likely to be deployed. A differentiated services boundary can be further sub-divided into ingress and egress nodes, where the ingress/egress nodes are the downstream/upstream nodes of a boundary link in a given traffic direction. A differentiated services boundary typically is found at the ingress to the first-hop differentiated services-compliant router (or network node) that a host's packets traverse, or at the egress of the last-hop differentiated services-compliant router or network node that packets traverse before arriving at a host. This is sometimes referred to as the boundary at a leaf router. A differentiated services boundary may be co-located with a host, subject to local policy. Also DS boundary. 🧚
To these we add:
- Traffic Aggregate: a collection of packets with a codepoint that maps to the same PHB, usually in a DS domain or some subset of a DS domain. A traffic aggregate marked for the foo PHB is referred to as the "foo traffic aggregate" or "foo aggregate" interchangeably. This generalizes the concept of Behavior Aggregate from a link to a network. 💖
- Per-Domain Behavior: the expected treatment that an identifiable or target group of packets will receive from "edge-to-edge" of a DS domain. (Also PDB.) A particular PHB (or, if applicable, list of PHBs) and traffic conditioning requirements are associated with each PDB. ✨
- A Service Level Specification (SLS) is a set of parameters and their values which together define the service offered to a traffic stream by a DS domain. It is expected to include specific values or bounds for PDB parameters. 👑
3 The Value of Defining Edge-to-Edge Behavior 🌈
okay so, as defined in section 2, a PDB describes the edge-to-edge behavior across a DS domain's "cloud." Specifying the transit expectations of packets matching a target for a particular diffserv behavior across a DS domain will both assist in the deployment of single-domain QoS and will help enable the composition of end-to-end, cross-domain services. Networks of DS domains can be connected to create end-to-end services by building on the PDB characteristics without regard to the particular PHBs used. This level of abstraction makes it easier to compose cross-domain services, as well as making it possible to hide details of a network's internals while exposing information sufficient to enable QoS. It's giving clean architecture 🫶
Today's Internet is composed of multiple independently administered domains or Autonomous Systems (ASs), represented by the "clouds" in figure 1. To deploy ubiquitous end-to-end quality of service in the Internet, business models must evolve that include issues of charging and reporting that are not in scope for the IETF. In the meantime, there are many possible uses of quality of service within an AS, and the IETF can address the technical issues in creating an intradomain QoS within a Differentiated Services framework. In fact, this approach is quite amenable to incremental deployment strategies. 🎀
Where DS domains are independently administered, the evolution of the necessary business agreements and future signaling arrangements will take some time, so early deployments will be within a single administrative domain. Putting aside the business issues, the same technical issues that arise in interconnecting DS domains with homogeneous administration will arise in interconnecting the autonomous systems (ASs) of the Internet. 💅
----------------------------------------
| AS2 |
| |
------- | ------------ ------------ |
| AS1 |------|-----X | | | |
------- | | | Y | | -------
| | | /| X----|--------| AS3 |
| | | / | | | -------
| | | / ------------ |
| | Y | |
| | | \ ------------ |
------- | | | \ | | |
| AS4 |------|-----X | \| | |
------- | | | Y X----|------
| | | | | |
| ------------ ------------ |
| |
| |
----------------------------------------
Figure 1: Interconnection of ASs and DS DomainsA single AS (e.g., AS2 in figure 1) may be composed of subnetworks and, as the definition allows, these can be separate DS domains. An AS might have multiple DS domains for a number of reasons, most notably to follow topological and/or technological boundaries and to separate the allocation of resources. If we confine ourselves to the DS boundaries between these "interior" DS domains, we avoid the non-technical problems of setting up a service and can address the issues of creating characterizable PDBs. ✨
The incentive structure for differentiated services is based on upstream domains ensuring their traffic conforms to the Traffic Conditioning Agreements (TCAs) with downstream domains, and downstream domains enforcing that TCA, so metrics associated with PDBs can be sensibly computed. The letters "X" and "Y" in figure 1 represent the DS boundary routers containing traffic conditioners that ensure and enforce conformance (e.g., shapers and policers). Although policers and shapers are expected at the DS boundaries of ASs (the "X" boxes), they might appear anywhere, or nowhere, inside the AS. Specifically, the boxes at the DS boundaries internal to the AS (the "Y" boxes) may or may not condition traffic. Technical guidelines for the placement and configuration of DS boundaries should derive from the attributes of a particular PDB under aggregation and multiple hops. 🦋
This definition of PDB continues the separation of forwarding path and control plane described in RFC 2474. The forwarding path characteristics are addressed by considering how the behavior at every hop of a packet's path is affected by the merging and branching of traffic aggregates through multiple hops. Per-hop behaviors in nodes are configured infrequently, representing a change in network infrastructure. More frequent quality-of-service changes come from employing control plane functions in the configuration of the DS boundaries. A PDB provides a link between the DS domain level, at which control is exercised to form traffic aggregates with quality-of-service goals across the domain, and the per-hop and per-link treatments packets receive that result in meeting those quality-of-service goals. 👑
4 Understanding PDBs 🧚
4.1 Defining PDBs
RFCs 2474 and 2475 define a Differentiated Services Behavior Aggregate as "a collection of packets with the same DS codepoint crossing a link in a particular direction," and further state that packets with the same DSCP get the same per-hop forwarding treatment (or PHB) everywhere inside a single DS domain. Note that even if multiple DSCPs map to the same PHB, this must hold for each DSCP individually. In section 2 of this document, we introduced a more general definition of a traffic aggregate in the diffserv sense, so that we might easily refer to the packets which are mapped to the same PHB everywhere within a DS domain. Section 2 also presented a short definition of PDBs, which we expand upon in this section: 🌸
Per-Domain Behavior: the expected treatment that an identifiable or target group of packets will receive from "edge to edge" of a DS domain. A particular PHB (or, if applicable, list of PHBs) and traffic conditioning requirements are associated with each PDB.
Each PDB has measurable, quantifiable attributes that can be used to describe what happens to its packets as they enter and cross the DS domain. These derive from the characteristics of the traffic aggregate that results from application of classification and traffic conditioning during the entry of packets into the DS domain, and the forwarding treatment (PHB) the packets get inside the domain, but they can also depend on the entering traffic loads and the domain's topology. PDB attributes may be absolute or statistical, and they may be parameterized by network properties. For example, a loss attribute might be expressed as "no more than 0.1% of packets will be dropped when measured over any time period larger than T", and a delay attribute might be expressed as "50% of delivered packets will see less than a delay of d milliseconds, 30% will see a delay less than 2d ms, 20% will see a delay of less than 3d ms." A wide range of metrics is possible. In general they will be expressed as bounds or percentiles rather than as absolute values. 🍓
A PDB is applied to a target group of packets arriving at the edge of the DS domain. The target group is distinguished from all arriving packets by use of packet classifiers [RFC2475] (where the classifier may be "null"). The action of the PDB on the target group has two parts. The first part is the use of traffic conditioning to create a traffic aggregate. During traffic conditioning, conformant packets are marked with a DSCP for the PHB associated with the PDB (see figure 2). The second part is the treatment experienced by packets from the same traffic aggregate transiting the interior of a DS domain, between and inside of DS domain boundaries. The following subsections further discuss these two effects on the target group that arrives at the DS domain boundary. 💜
----------- ------------ -------------------- foo
arriving _|classifiers|_|target group|_|traffic conditioning|_ traffic
packets | | |of packets | |& marking (for foo) | aggregate
----------- ------------ --------------------Figure 2: Relationship of the traffic aggregate associated with a PDB to arriving packets 🌈
4.1.1 Crossing the DS edge: the effects of traffic conditioning on the target group ✨
okay so this effect gets measured by how the traffic aggregate coming out compares to the target group going in 👀 and that relationship can depend on two things: the traffic pattern that shows up, and how the traffic conditioners are set up 🎀 For example, say the EF PHB [RFC2598] and a strict policer of rate R are attached to the foo PDB. Then the first step in characterizing the foo PDB is writing down the relationship between the arriving target packets and the departing foo traffic aggregate 💅 In this case, "the rate of the emerging foo traffic aggregate is less than or equal to the smaller of R and the arrival rate of the target group of packets", and you can add other temporal stuff about the packets (like burst) if you want 🦋 So yeah, there's a "loss rate" on the arriving target group that happens when too much traffic shows up, or traffic with the wrong timing shows up 😭 This loss rate should be entirely preventable (or controllable) if the upstream sender follows the traffic conditioning that goes with the PDB spec 🫶
The "who is in control" question is what keeps this part of PDB performance separate from the part about getting through the domain 🧚 The domain operator fully controls the second part, and the first part exists to make sure the entering traffic aggregate matches the traffic profile the operator set up for the network 👑 Also, the effects of traffic conditioning on the target group can usually be described more simply than the effects of crossing the DS domain on the traffic aggregate's traffic profile 🌸
A PDB may also apply traffic conditioning at DS domain egress 🍓 The effect of that conditioning on the overall PDB attributes would be handled the same way as the ingress characteristics. (The authors may develop more text on this in the future, but it does not materially affect the ideas presented in this document.) 💜
4.1.2 Crossing the DS domain: transit effects 🌈
The second part of PDB performance is the set of metrics that describe how a packet of the PDB's traffic aggregate transits between any two edges of the DS domain boundary shown in figure 3 🦋 Heads up: the DS domain boundary runs right through the DS boundary routers, because the traffic aggregate usually gets formed in the boundary router before the packets are queued and scheduled for output 👀 (In most cases, this distinction is expected to be important. 🙈)
DSCPs should not change in the interior of a DS domain, since no traffic conditioning is being applied there 💖 If you do need to reapply the kind of traffic conditioning that could result in remarking, there should be a DS domain boundary at that point. Though an "interior" boundary like that can have "lighter weight" rules in its TCA ✨ So when you measure attributes between the locations shown in figure 3, the DSCP on the egress side can be assumed to have held throughout the domain 🫶
-------------
| |
-----X |
| |
| DS |
| domain X----
| |
-----X |
| |
-------------
Figure 3: Range of applicability of attributes of a traffic
aggregate associated with a PDB (is between the
points marked "X")Okay, a DS domain can be as small as a single node, but more complex topologies are expected to be the norm 🌸 So the PDB definition must still hold when its traffic aggregate gets split and merged on the interior links of a DS domain 💅 Packet flow in a network is not part of the PDB definition. Instead, the application of traffic conditioning as packets enter the DS domain, plus the consistent PHB through the DS domain, must be enough 🧚 A PDB's definition does not have to hold for arbitrary network topologies, but the limits on where a specific PDB applies must be clearly specified 🎀
In general, a PDB operates between N ingress points and M egress points at the DS domain boundary 🍓 Even in the degenerate case where N=M=1, PDB attributes are more complex than PHB attributes, because the concatenation of the behavior of intermediate nodes affects the former 😭 A complex case, with N and M both greater than one, involves splits and merges in the traffic path and is non-trivial to analyze 🙈 Analytic, simulation, and experimental work will all be necessary to understand even the simplest PDBs 🔥
4.2 Constructing PDBs 🏗️
A DS domain is configured to meet the network operator's traffic engineering goals for the domain, independently of the performance goals for any particular flow of a traffic aggregate 👑 Once the interior routers are configured for the number of distinct traffic aggregates the network will handle, each PDB's allocation at the edge comes from meeting the desired performance goals for that PDB's traffic aggregate, subject to that configuration of packet schedulers and bandwidth capacity 💖 The configuration of traffic conditioners at the edge may be altered by provisioning or admission control. But the decision about which PDB to use, and how to apply classification and traffic conditioning, comes from matching performance to goals 🦋
For example, consider the DS domain of figure 3 ✨ A PDB with an explicit bound on loss must apply traffic conditioning at the boundary, to ensure that on the average no more packets are admitted than can emerge 🫶 Queueing internal to the network may result in a difference between input and output traffic over some timescales, but the averaging timescale should not exceed what might be expected for reasonably sized buffering inside the network 🌈 So if bursts are allowed to arrive into the interior of the network, there must be enough capacity to make sure losses don't exceed the bound 😭 Explicit bounds on loss levels can be especially hard, because the exact way packets merge inside the network affects the burstiness of the PDB's traffic aggregate, and therefore the loss 💀
PHBs give explicit expressions of the treatment a traffic aggregate can expect at each hop 🧚 For a PDB, this behavior must apply to merging and diverging traffic aggregates. So characterizing a PDB requires understanding what happens to a PHB under aggregation 🎀 In other words, PHBs applied recursively must result in a known behavior 👑 As an example, since maximum burst sizes grow with the number of microflows or traffic aggregate streams merged, a PDB specification must address this 🍓 A clear advantage of constructing behaviors that aggregate is how easily PDBs can be concatenated, so the associated traffic aggregate has known attributes that span interior DS domains and, eventually, farther 💜 For example, in figure 1, assume we have configured the foo PDB on the interior DS domains of AS2. Then the traffic aggregates associated with the foo PDB in each interior DS domain of AS2 can be merged at the shaded interior boundary routers 🌸 If the same (or fewer) traffic conditioners as those applied at the entrance to AS2 are applied at these interior boundaries, the attributes of the foo PDB should continue to be used to quantify the expected behavior ✨ Explicit expressions of what happens to the behavior under aggregation, possibly parameterized by node in-degrees or network diameters, are necessary to decide what to do at the internal aggregation points 🔥 One approach might be to completely reapply the traffic conditioning at these points. Another might employ some limited rate-based remarking only 🦋
Multiple PDBs may use the same PHB. The specification of a PDB can contain a list of PHBs and their required configuration, all of which would result in the same PDB 🫶 In operation, a single domain is expected to use a single PHB to implement a particular PDB, though different domains may select different PHBs 🌈 Recall that in the diffserv definition [RFC2474], a single PHB might be selected within a domain by a list of DSCPs 💅 Multiple PDBs might use the same PHB, in which case the transit performance of their traffic aggregates will, of necessity, be the same 😭 Yet the particular characteristics that the PDB designer wants to claim as attributes may vary, so two PDBs that use the same PHB might not be specified with the same list of attributes 🙈
The specification of the transit expectations of PDBs across domains both helps with deploying QoS within a DS domain and makes it possible to compose end-to-end, cross-domain services 👑 It does this by hiding the details of a domain's internals while still exposing the characteristics necessary for QoS 💖 bestie this is so iconic 🥹✨
4.3 PDBs using PHB Groups 🧚
okay so there are a bunch of ways to build PDBs out of PHB groups, and it's giving buffet 🍓 A single PHB member of a PHB group might be used to build one PDB all by itself. For example, a PDB could be defined using just one of the Class Selector Compliant PHBs [RFC2474] ✨ The traffic conditioning for that PDB and the required configuration of that particular PHB would be defined so there's no dependence or relationship with how the other PHBs in the group are used, or even whether they're used in that DS domain at all 🙈 In this case, the reasonable move is to specify this PDB alone in a document that clearly calls out the conditions and configuration of the Class Selector PHB it needs. Very clean, very iconic 💅
A single PDB can also be built from more than one PHB from the same PHB group. For example, the traffic conditioner described in RFC 2698 might be used to mark a particular entering traffic aggregate for one of the three AF1x PHBs [RFC2597], while the transit performance of the resulting PDB is specified statistically across all the packets marked with one of those PHBs 🦋
A set of related PDBs might be defined using a PHB group too. In this case, the related PDBs should be defined in the same document. This makes sense when the traffic conditioners that create the traffic aggregates for each PDB have some relationships and interdependencies, so the aggregates should be described and characterised together 🫶 The transit attributes will depend on the PHB associated with each PDB and won't be the same for every PHB in the group, though there may be some parameterised interrelationship between the attributes of these PDBs. Here, each PDB should have a clearly separate description of its transit attributes, delineated in its own subsection within the document. For example, the traffic conditioner described in RFC 2698 might be used to mark arriving packets for three different AF1x PHBs, each treated as a separate traffic aggregate in terms of transit properties. Then a single document could define and quantify the relationship between the arriving packets and the emerging traffic aggregates as they relate to one another 💜 The transit characteristics of packets in each separate AF1x traffic aggregate should be described separately within that document.
Another way a PHB group might be used to create one PDB per PHB is with decoupled traffic conditioners but some relationship between the PHBs of the group. For example, a set of PDBs might be defined using Class Selector Compliant PHBs [RFC2474] in such a way that the traffic conditioners creating the traffic aggregates are not related, but the transit performance of each traffic aggregate has some parametric relationship to the others 🌈 If it makes sense to specify them in the same document, then the author(s) should do so.
4.4 Forwarding path vs. control plane 🎀
okay this one is so important, bestie 😭 A PDB's associated PHB, classifiers, and traffic conditioners are all in the packet forwarding path and operate at line rates. PHBs, classifiers, and traffic conditioners get configured in response to control plane activity, which happens across a whole range of time scales. But even at the shortest time scale, control plane actions are not expected to happen per-packet ✨ Classifiers and traffic conditioners at the DS domain boundary are used to enforce who gets to use the PDB and how the PDB should behave over time. Reconfiguration of PHBs might happen monthly, quarterly, or only when the network is upgraded. Classifiers and traffic conditioners might be reconfigured at a few regular intervals during the day, or they might change in response to signalling decisions thousands of times a day 🍓
Much of the control plane work is still evolving and sits outside the charter of the Diffserv WG. We note that this is quite appropriate, since the manner in which the configuration is done, and the time scale at which it is done, should not affect the PDB attributes 💅 It's giving separation of concerns, and I am obsessed.
5 Format for Specification of Diffserv Per-Domain Behaviors 👑
PDBs arise from a particular relationship between edge and interior, which may be parameterised. The quantifiable characteristics of a PDB must be independent of whether the network edge is configured statically or dynamically 🦋 The particular configuration of traffic conditioners at the DS domain edge is critical to how a PDB performs, but the act(s) of configuring the edge is a control plane action that can be separated from the specification of the PDB.
The following sections must be present in any specification of a Differentiated Services PDB. Of necessity, their length and content will vary greatly 🧚
5.1 Applicability Statement 🌸
All PDB specs must have an applicability statement that outlines the intended use of this PDB and the limits to its use.
5.2 Technical specification 💖
This section specifies the rules or guidelines to create this PDB, each distinguished with "may", "must" and "should." The technical specification must list the classification and traffic conditioning required (if any) and the PHB (or PHBs) to be used, with any additional requirements on their configuration beyond what is contained in RFCs. Classification can reflect the results of an admission control process. Traffic conditioning may include marking, traffic shaping, and policing. A Service Provisioning Policy might be used to describe the technical specification of a particular PDB 🫶
5.3 Attributes ✨
A PDB's attributes tell how it behaves under ideal conditions if configured in a specified manner, where the specification may be parameterised. These might include drop rate, throughput, and delay bounds measured over some time period. They may be bounds, statistical bounds, or percentiles, e.g., "90% of all packets measured over intervals of at least 5 minutes will cross the DS domain in less than 5 milliseconds". A wide variety of characteristics may be used, but they must be explicit, quantifiable, and defensible. Where particular statistics are used, the document must be precise about how they are to be measured and about how the characteristics were derived 🔥
Advice to a network operator would be to use these as guidelines in creating a service specification rather than using them directly. For example, a "loss-free" PDB would probably not be sold as such, but rather as a service with a very small packet loss probability 💅
5.4 Parameters 🌈
The definition and characteristics of a PDB may be parameterised by network-specific features. For example: maximum number of hops, minimum bandwidth, total number of entry/exit points of the PDB to/from the diffserv network, maximum transit delay of network elements, minimum buffer size available for the PDB at a network node, etc. 🍓
5.5 Assumptions 🙈
In most cases, PDBs will be specified assuming lossless links, no link failures, and relatively stable routing. This is reasonable, since otherwise it would be very difficult to quantify behaviour, and this is the operating condition most operators strive for. However, these assumptions must be clearly stated. Since PDBs with specific bandwidth parameters require that bandwidth to be available, the assumptions to be stated may include standby capacity. Some PDBs may be specifically targeted for cases where these assumptions do not hold, e.g., for high loss rate links, and such targeting must also be made explicit. If additional restrictions, especially specific traffic engineering measures, are required, these must be stated 💜
Further, if any assumptions are made about the allocation of resources within a diffserv network in the creation of the PDB, these must be made explicit.
5.6 Example Uses 🦋
A PDB specification must give example uses to motivate understanding of the ways a diffserv network could make use of the PDB, although these are not expected to be detailed. For example: "A bulk handling PDB may be used for all packets which should not take any resources from the network unless they would otherwise go unused. This might be useful for Netnews traffic or for traffic rejected from some other PDB by traffic policers." 🧚
5.7 Environmental Concerns (media, topology, etc.) 🌸
Note that it is not necessary for a provider to expose which PDB (if a commonly defined one) is being used, nor is it necessary for a provider to specify a service by the PDB's attributes. For example, a service provider might use a PDB with a "no queueing loss" characteristic in order to specify a "very low loss" service 💖
This section is there to inject realism into the characteristics described above. Detail the assumptions made there and what constraints that puts on topology, type of physical media, or allocation 🔥
5.8 Security Considerations for each PDB 🔒
This section should include any security considerations that are specific to the PDB. Is it subject to any unusual theft-of-service or denial-of-service attacks? Are any unusual security precautions needed? 😭
It is not necessary to repeat the general security discussions in [RFC2474] and [RFC2475], but a reference should be included. Also refer to any special security considerations for the PHB or PHBs used 🫶
6. On PDB Attributes 🎀
okay so remember how section 4 said measurable, quantifiable attributes can describe what happens to packets using a PDB as they cross the domain? 💅 Those attributes are the whole vibe here. When a PDB spec is building block for interdomain QoS, it needs to answer one big question: under what conditions can we join this domain's output to another one under the same traffic conditioning and expectations? 🫶 There are a bunch of ways traffic could get distributed, but making PDBs that are quantifiable, realizable, AND concatenable into multi-domain services cuts down the realistic scenarios a lot. So a PDB's attributes need a clear statement of the conditions they hold under. Non-negotiable for multi-domain services ✨
There's a clear correlation between how strict the traffic conditioning is and how good the PDB's attributes are. As we said earlier, numerical bounds are likely to be statistical or expressed as a percentile. Strict bounds need very precise mathematical analysis 🤓, while statistical ones can kinda lean on experiment. Section 7 gives an example of a PDB without strict traffic conditioning, and there's concurrent work on a PDB with strict traffic conditioning and attributes that's also in front of the WG [VW] 👀. This section just gives some general considerations for characterizing PDB attributes. Let's go 🦋
There are two ways to characterize PDBs with respect to time. 🕰️ First, there are properties over "long" time periods, or average behaviors. A PDB spec should report these as the rates or throughput seen over some specified time period. Then there are properties of "short" time behavior, which are usually expressed as the allowable burstiness in a traffic aggregate. Short-time behavior matters for understanding buffering requirements (and the loss characteristics that come with them) and for metering and conditioning at DS boundaries 🔥. For short-time behavior we mainly care about two things: 1) how many back-to-back packets of the PDB's traffic aggregate we'll see at any point (this would be metered as a burst) and 2) how large a burst of packets from this PDB's traffic aggregate can show up in a queue at once (this is what gives queue overflow and loss 💀). And if other PDBs are using the same PHB within the domain, that has to be taken into account too 🌸
6.1. Considerations in specifying long-term or average PDB attributes
okay so to characterize the average or long-term behavior for the foo PDB, we have to explore a bunch of questions 🧐. For instance: can the DS domain handle the average foo traffic flow? Is that answer topology dependent, or are there specific assumptions on routing that must hold for the foo PDB to keep its "adequately provisioned" capability? Like, if the topology of D changes suddenly, will the foo PDB's attributes change? Will its loss rate dramatically increase? 😭
Let's say domain D in figure 4 is an ISP ringing the U.S. with links of bandwidth B and with N tails to various metropolitan areas 🗺️. Inside D, if the link between the node connected to A and the node connected to Z goes down, then all the foo traffic aggregate between those two nodes has to transit the entire ring. Would the bounded behavior of the foo PDB change? Well, if this outage makes some node on the ring have a larger arrival rate to one of its links than that link's capacity for foo's traffic aggregate, the loss rate would obviously change dramatically 🙈. In this case, topological assumptions were made about the path of traffic from A to Z, and those assumptions affected the characteristics of the foo PDB. If those topological assumptions stop holding, the loss rate of packets in the foo traffic aggregate transiting the domain could change. For example, a characteristic like "loss rate no greater than 1% over any interval larger than 10 minutes" could just... not be true anymore 😱. A PDB spec should spell out the assumptions made about preserving the attributes. No cap, this is the part people skip and then regret 🥲
____X________X_________X___________ /
/ \ L |
A<---->X X<----->| E
| | |
| D | \
Z<---->X |
| |
\___________________________________/
X X
Figure 4: ISP and DS domain D connected in a ring and
connected to DS domain E6.2. Considerations in specifying short-term or bursty PDB attributes
Next up, the short-time behavior of the traffic aggregate for a PDB 💖. Specifically, we need to figure out whether letting the maximum bursts add up the same way the average rates do will lead to properties that aggregate. Or, under what conditions will it lead to properties that aggregate? In our example, if domain D lets each of the uplinks burst p packets into the foo traffic aggregate, those bursts could accumulate as they transit the ring 📈. Packets headed for link L can come from both directions of the ring, so back-to-back packets from foo's traffic aggregate can arrive at the same time 😮.
Now, if the bandwidth of link L is the same as the links of the ring, this probably isn't a buffering problem 🙌. If two input links can send packets to queue for L, at worst two packets can arrive simultaneously for L. And if the bandwidth of link L equals or exceeds twice B, the packets won't accumulate ✨. Further, if p is limited to one, and the bandwidth of L exceeds the rate of arrival (over the longer term) of foo packets (which is required for bounding the loss), then the queue of foo packets for link L will empty before new packets arrive 🧹. But if the bandwidth of L is equal to B, one foo packet has to queue while the other one is transmitted. This would result in N x p back-to-back packets of this traffic aggregate arriving over L during the same time scale as the bursts of p that were permitted on the uplinks. Thus, configuring the PDB so that link L can handle the sum of the rates ingressing to the foo PDB doesn't guarantee that L can handle the sum of the N bursts into the foo PDB. Plot twist, bestie 🫣
If the bandwidth of L is less than B, then the link must buffer Nxpx(B-L)/B foo packets to avoid loss 📦. And if the PDB is getting less than the full bandwidth L, that number gets even bigger. For probabilistic bounds, a smaller buffer might do, as long as the probability of exceeding it can be bounded 🤞.
More generally, for router indegree of d, bursts of foo packets might arrive on each input 🌈. Then, in the absence of any additional traffic conditioning, it's possible that dxpx(# of uplinks) back-to-back foo packets get sent across link L to domain E. So DS domain E has to permit these much larger bursts into the foo PDB than domain D permits on the N uplinks 😳. Or else the foo traffic aggregate has to be made to conform to the TCA for entering E (for example, by shaping) 💅
So what conditions should be imposed on a PDB and on the associated PHB so PDBs can be concatenated, like across the interior DS domains of figure 1? 🤔 Traffic conditioning for constructing a PDB with certain attributes across a DS domain should apply independently of where the packets came from. With reference to the example we've been exploring, the TCA for the PDB's traffic aggregate entering link L into domain E should not depend on the number of uplinks into domain D. Independence = iconic behavior 👑
6.3. Remarks
This section is motivational food for thought for PDB specifiers 🍓. It is by no means an exhaustive catalog of possible PDB attributes or of the kind of analysis that must be done. We expect this to be an interesting and evolutionary part of the work of understanding and deploying differentiated services on the Internet 🧚. There's a lot of potential for really cool research work. However, when a PDB spec is submitted to the Diffserv WG, the PDB also has to pass the test of being useful and relevant through deployment experience, which is described in section 8 🎯.
7. A Reference Per-Domain Behavior ✨
The intent of this section is to define, as a reference, a Best Effort PDB: a PDB that has very little in the way of rules or expectations 🫶.
7.1. Best Effort PDB
7.1.1. Applicability
A Best Effort (BE) PDB is for sending "normal internet traffic" across a diffserv network 🌐. Like, the whole point of this PDB is to keep, to a reasonable extent, the pre-diffserv delivery expectations for packets in a diffserv network that don't need any special differentiation. Although the PDB itself doesn't include bounds on availability, latency, and packet loss, that doesn't stop Service Providers from engineering their networks so they end up with commercially viable bounds on services that use the BE PDB 💼. This would be analogous to the Service Level Guarantees provided in today's single-service Internet, which is giving very "classic internet" vibes 🦋
In the present single-service commercial Internet, Service Level Guarantees for availability, latency, and packet delivery can be found on ISP web sites [WCG, PSI, UU] 🌸. For example, a typical North American round-trip latency bound is 85 milliseconds, and each service provider's site info specifies the method of measurement for the bounds and the terms attached to them contractually 📝.
7.1.2. TCS and PHB configurations
There are no restrictions governing the rate and bursts of packets beyond the limits imposed by the ingress link 🙌. The network edge makes sure packets using the PDB are marked for the Default PHB (as defined in [RFC2474]), but no other traffic conditioning is required. Interior network nodes apply the Default PHB to these packets. Simple, clean, no drama 💅
7.1.3. Attributes of this PDB
"As much as possible as soon as possible" 🏃♀️💨
Packets of this PDB won't be completely starved. When resources are available (i.e., not required by packets from any other traffic aggregate), network elements should be configured to let packets of this PDB consume them 🥰.
Network operators may bound the delay and loss rate for services built from this PDB, given knowledge about their network, but those attributes aren't part of the definition 🧠.
7.1.4. Parameters
None. Zero vibes to manage here ✨
7.1.5. Assumptions
A properly functioning network, i.e., packets may be delivered from any ingress to any egress 🌈.
7.1.6. Example uses
- For the normal Internet traffic connection of an organization 🏢
- For the "non-critical" Internet traffic of an organization 🍵
- For standard domestic consumer connections 🏠
7.1.7. Environmental Concerns
There are no environmental concerns specific to this PDB 🌿
7.1.8. Security Considerations for BE PDB
There are no specific security exposures for this PDB. Just check the general security considerations in [RFC2474] and [RFC2475] 🔐. Bestie, don't skip those 🫶
8. Guidelines for writing PDB specifications 💅
Okay bestie, this is the checklist for writing a PDB spec, and it's kinda a big deal. 🎀
G1. Follow the format in this document, write a draft, and submit it as an Internet Draft. The document should have "diffserv" as some part of the name. Put your deployment experience in an appendix to the draft or in a separate document. It should include measured results from a network of non-trivial size carrying realistic traffic, and/or convincing simulation results (simulating a range of modern traffic patterns and network topologies, as applicable). Bring the document to the attention of the diffserv WG mailing list, if it's active. 📬✨
G2. Initial discussion should focus mainly on whether the PDB is actually worth having, though comments and questions about the claimed attributes are fair game. This matches the Differentiated Services goal of putting relevance ahead of academic interest when specifying PDBs. Academically interesting PDBs are encouraged, but they'd be a better fit for technical publications and conferences than for IETF submission. (An "academically interesting" PDB might become a PDB of interest for deployment over time. 🧠💜)
The rest of the steps depend on whether there's an active diffserv working group. Here's how it goes in each case. 👀
Active Diffserv Working Group path:
G3. Once consensus is reached that a version of the draft is a useful PDB and that the characteristics "appear" to be correct (i.e., not egregiously wrong), that version goes to a review panel the WG co-chairs set up to audit and report on the characteristics. The panel gets a deadline for the review. The co-chairs set the exact timing case-by-case to reflect how complex the task is and other constraints (IETF meetings, major holidays), but it's expected to be in the 4-8 week range. During that time, the panel may correspond with the authors directly (cc'ing the WG co-chairs) to get clarifications. This process should end with a revised draft and/or a report to the WG from the panel that either endorses or disputes the claimed characteristics. 🔍🌸
G4. If the panel endorses the draft, it goes to WG last call. If it isn't endorsed, the author(s) can send an itemized response to the panel's report and ask for a WG Last Call. 🙏
G5. If it passes Last Call, it goes to the ADs for publication as a WG Informational RFC in our "PDB series." 🎉👑
If no active Diffserv Working Group exists:
G3. After discussion on the relevant mailing lists, the authors should revise the Internet Draft and contact the IESG for "Expert Review" as defined in section 2 of RFC 2434 [RFC2434]. 📝
G4. After the review, the IESG may recommend publication of the Draft as an RFC, request revisions, or decline to publish it as an Informational RFC in the "PDB series." 🦋
9. Security Considerations 🔐
Okay, this part is seriously important, so please don't skip it. ⚠️ The general security considerations of [RFC2474] and [RFC2475] apply to all PDBs. Individual PDB definitions may require additional security considerations. Every PDB author needs to think about these, because a PDB that ignores security can break things for everyone else on the network. 🙈💀
10. Acknowledgements 🫶
The ideas in this document were heavily shaped by the Diffserv WG, and especially by discussions with Van Jacobson, Dave Clark, Lixia Zhang, Geoff Huston, Scott Bradner, Randy Bush, Frank Kastenholz, Aaron Falk, and a whole bunch of other people who deserve credit for their useful input. They shouldn't be blamed for how we mangled it, though! 😭✨ Grenville Armitage coined "per domain behavior (PDB)," though some people have suggested similar terms before that. Dan Grossman, Bob Enger, Jung-Bong Suk, and John Dullaert reviewed the document and commented to improve its form. Bestie squad. 💜
References 📚
[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",
December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999.
[RFC2698] Heinanen, J. and R. Geurin, "A Two Rate Three Color
Marker", RFC 2698, June 1999.
[MODEL] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An
Informal Management Model for Diffserv Routers", Work in
Progress.
[MIB] Baker, F., Chan, K. and A. Smith, "Management Information
Base for the Differentiated Services Architecture", Work in
Progress.
[VW] Jacobson, V., Nichols, K. and K. Poduri, "The 'Virtual
Wire' Per-Domain Behavior", Work in Progress.
[WCG] Worldcom, "Internet Service Level Guarantee",
http://www.worldcom.com/terms/service_level_guarantee/
t_sla_terms.phtml
[PSI] PSINet, "Service Level Agreements",
http://www.psinet.com/sla/
[UU] UUNET USA Web site, "Service Level Agreements",
http://www.us.uu.net/support/sla/
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for IANA
Considerations", BCP 26, RFC 2434, October 1998.Authors' Addresses 🧚
Kathleen Nichols
Packet Design, LLC
2465 Latham Street, Third Floor
Mountain View, CA 94040
USA
EMail: nichols@packetdesign.com
Brian Carpenter
IBM
c/o iCAIR
Suite 150
1890 Maple Avenue
Evanston, IL 60201
USA
EMail: brian@icair.orgFull Copyright Statement ⚖️
Legal stuff, so I've kept it word-for-word so nothing gets lost. 🙏
Copyright (C) The Internet Society (2001). 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 assigns.
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. Thank you, Internet Society, for keeping the lights on! ✨💖
📦 where this page comes from
- ietf: rfc3086 2001-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms