RFC 2211

RFC 2211: Specification of the Controlled-Load Network Element Service 🎀

Okay so this one came from J. Wroclawski at MIT LCS, filed under the Network Working Group as a Standards Track doc, dated September 1997 💖 The header doesn't list any RFCs it obsoletes or updates, so it's standing on its own. ✨

Status of This Memo 🌸

This is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💅

Abstract 🦋

This memo spells out the network element behavior needed to deliver Controlled-Load service on the Internet. Controlled-load service gives a client's data flow a quality of service that closely matches what that same flow would get from an unloaded network element. The difference is that it uses capacity (admission) control to make sure the flow still gets this service even when the network element is overloaded 👑

1. Introduction ✨

This document defines the requirements for network elements that support the Controlled-Load service. It's one of a series of documents that specify the network element behavior needed to support various qualities of service in IP internetworks 🧚 These services are useful both on the global Internet and on private IP networks.

This document is based on the service specification template given in [1]. For definitions and more info about specifying qualities of service within the IP protocol family, go check that document 🍓

2. End-to-End Behavior 🔥

The end-to-end behavior that an application gets from a chain of network elements providing controlled-load service tightly matches the behavior that applications get from best-effort service under unloaded conditions on that same chain. As long as the network is working correctly, these applications can assume that:

• A very high percentage of transmitted packets will be successfully delivered by the network to the receiving end-nodes. (The percentage of packets that aren't successfully delivered must closely approximate the basic packet error rate of the transmission medium.)
• The transit delay experienced by a very high percentage of the delivered packets will not greatly exceed the minimum transmit delay experienced by any successfully delivered packet. (This minimum transit delay includes speed-of-light delay plus the fixed processing time in routers and other communications devices along the path.)

To make sure these conditions are met, clients requesting controlled-load service give the intermediate network elements an estimate of the data traffic they'll generate. That estimate is the TSpec 💅 In return, the service makes sure that network element resources adequate to process traffic inside this descriptive envelope will be available to the client. If the client's traffic generation properties fall outside the region described by the TSpec parameters, the QoS the client gets may show signs of overload, including lots of delayed or dropped packets. The service definition doesn't require the precise characteristics of that overload behavior to match what a best-effort data flow would get on the same path under overloaded conditions 🙈

NOTE: In this memo, the term "unloaded" is used in the sense of "not heavily loaded or congested" rather than in the sense of "no other network traffic whatsoever".

3. Motivation 💜

Controlled-load service is meant to support a broad class of applications that were built for today's Internet but are really sensitive to overloaded conditions. The big names in this class are the "adaptive real-time applications" that a bunch of vendors and researchers are offering. These apps have been shown to work well on unloaded nets, but they fall apart fast under overloaded conditions. A service that mimics unloaded nets serves these apps really well 😭

Controlled-load service is intentionally minimal. The specification has no optional functions or capabilities, and it offers only a single function. System and application designers can assume that all implementations will be identical in this respect ✨

Internally, controlled-load service fits a wide range of implementation techniques, including evolving scheduling and admission control algorithms that let implementations be super efficient with network resources. It's just as friendly to extremely simple implementations in situations where maxing out network resource utilization isn't the only concern 🌈

4. Network Element Data Handling Requirements 🎀

Each network element that accepts a request for controlled-load service must make sure that adequate bandwidth and packet processing resources are available to handle the requested level of traffic, as given by the requestor's TSpec. This must be accomplished through active admission control. All resources important to the operation of the network element must be considered when admitting a request. Common examples include link bandwidth, router or switch port buffer space, and the computational capacity of the packet forwarding engine 💅

Controlled-load service doesn't accept or use specific target values for control parameters like delay or loss. Instead, accepting a controlled-load request means the network element commits to giving the requestor service that's closely equivalent to what uncontrolled (best-effort) traffic gets under lightly loaded conditions 🦋

"Closely equivalent to unloaded best-effort service" is necessarily fuzzy. It's easiest to pin this quality of service down by describing the events that are expected to not happen with any frequency. A flow getting controlled-load service at a network element can expect to experience:

• Little or no average packet queueing delay over all timescales significantly larger than the "burst time". The burst time is the time required for the flow's maximum size data burst to be transmitted at the flow's requested transmission rate, where the burst size and rate are given by the flow's TSpec, as described below.
• Little or no congestion loss over all timescales significantly larger than the "burst time" defined above. In this context, congestion loss includes packet losses due to a shortage of any required processing resource, such as buffer space or link bandwidth. Occasional congestion losses may happen, but any substantial sustained loss means the admission control algorithm has failed 💀

The basic effect of this language is to set an expectation on the duration of a disruption in delivery service. Shorter events are seen as statistical effects that can happen in normal operation. Longer events point to a failure to allocate adequate capacity to the controlled-load flow 😤

A network element can use statistical approaches to decide whether it has adequate capacity to accept a service request. For example, a network element processing a bunch of flows whose long-term characteristics are predicted from measuring past behavior may be able to overallocate its resources to some extent without lowering the level of service delivered to the flows 🧠

A network element can use any appropriate scheduling means to make sure admitted flows get appropriate service 🔥

NOTE: The flexibility implied by the above paragraph exists within definite limits. Readers should observe that the specification's requirement that the delay and loss behavior described above imposes concrete requirements on implementations.

Honestly the most important requirement here is that the implementation has to make bandwidth greater than the Tspec token rate available to the flow in certain situations. That requirement for extra bandwidth can be derived from the fluid model of traffic scheduling (e.g. [7]). If a flow gets exactly its promised token rate at all times, queueing caused by an over-rate burst arriving at the network element may never clear, and the traffic queueing delay keeps permanently increasing. This happens if the flow keeps generating traffic at exactly the token rate after emitting the burst 😭

To control the long-term effects of traffic bursts, a Controlled Load implementation has several options. At minimum, there must be a mechanism to "borrow" the bandwidth needed to clear bursts from the network. There are a bunch of ways to build such a mechanism, ranging from explicit borrowing schemes inside the traffic scheduler to implicit schemes based on statistical multiplexing and measurement-based admission control. The specification doesn't prefer any method over any other, but it does require that some such mechanism exists 👑

Similarly, the requirement for low congestion loss for in-Tspec traffic means buffer management needs some flexibility. Because controlled-load service doesn't reshape traffic to its token-bucket parameters at every node, traffic flowing through the network gets distorted as it crosses queueing points. This distortion is especially likely during traffic bursts, which is exactly when buffering is used the most. In these situations, rigidly restricting the buffering capacity to a size equal to the flow's TSpec burst size may lead to congestion loss. An implementation should be ready to make extra buffering available to bursting flows. Again, this can be done in a number of ways. One obvious choice is statistical multiplexing of a shared buffer pool 🍓

Links are not permitted to fragment packets that receive the controlled-load service. Packets larger than the MTU of the link must be treated as nonconformant to the TSpec. This implies they'll be forwarded according to the rules described in the Policing section below 🙈

Implementations of controlled-load service are not required to provide any control of short-term packet delay jitter beyond what's described above. However, using packet scheduling algorithms that provide additional jitter control is not prohibited by this specification 🦋

Packet losses due to non-congestion-related causes, such as link errors, are not bounded by this service 💅

5. Invocation Information ✨

okay so, to invoke the controlled-load service, you just hand the network element your flow's desired traffic parameters, the TSpec 💅. If the element has the room to forward the flow's packets the way we described above, the new flow gets accepted 🎀. Want to change the TSpec on a flow that's already running? That counts as a brand-new invocation, so admission control has to run again for that flow 👀. And if the new TSpec is strictly smaller than the old one (using the ordering rules below), it should never get denied service 🫶.

The controlled-load service describes a flow's traffic parameters with the TOKEN_BUCKET_TSPEC from Reference [5] 🧚. The TSpec is a token bucket specification plus a peak rate (p), a minimum policed unit (m), and a maximum packet size (M) 🌸.

The token bucket specification has a bucket rate r and a bucket depth b. Both r and b must be positive 💖. The rate r is measured in bytes of IP datagrams per second, and it can range from 1 byte per second all the way up to 40 terabytes per second 🌈. Network elements MUST return an error for any request with a value outside that range 🚫. They also MUST return an error for any request with a value inside the range that the element just can't support 😭. Real talk, only the first few digits of r actually matter, so floating point representations accurate to at least 0.1% are encouraged ✨.

The bucket depth b is measured in bytes and can range from 1 byte up to 250 gigabytes 🍓. Same deal here: Network elements MUST return an error for values outside that range, and MUST return an error for values inside the range that the element can't support 🙈. Only the first few digits of b matter in practice, so floating point representations accurate to at least 0.1% are encouraged 💜.

The allowed range is intentionally huge so future network technologies have room to grow 🚀. Any single network element isn't expected to support the whole range though, so don't panic if your hardware doesn't 🫠.

The peak rate p is measured in bytes of IP datagrams per second, with the same range and suggested representation as the bucket rate 🌊. It exists in this version mostly so the TSpec stays compatible with other QoS control services and the shared TOKEN_BUCKET_TSPEC parameter 🦋. Some admission control and buffer allocation algorithms might find it useful, but a Controlled-Load service that follows this version can always ignore it 🙌. The service module at a network element can always assume the peak data rate arriving there is the line rate of the incoming interface, and the service's evaluation criteria don't require the element to look at the peak rate at all 💅. More explicit use of the peak-rate parameter might show up in a future version ⭐.

The minimum policed unit m is an integer measured in bytes 🎀. Every IP datagram smaller than m gets counted against the token bucket as if it were exactly m bytes big 📦. The maximum packet size M is the biggest packet that still conforms to the traffic specification, also measured in bytes 🧁. Network elements MUST reject a service request if the requested maximum packet size is larger than the MTU of the link 🚨. Both m and M must be positive, and m must be less than or equal to M 💕.

The preferred concrete representation of the TSpec is three single-precision IEEE floating point numbers, followed by two 32-bit integers in network byte order 🤓. The order goes: the rate (r), the bucket size (b), the peak rate (p), the minimum policed unit (m), and the maximum packet size (M) 📋. For r and b, only bit patterns representing valid non-negative floating point numbers are allowed. Negative numbers (including "negative zero"), infinities, and NAN's are not allowed 🙅‍♀️. For p, only bit patterns representing valid non-negative floating point numbers or positive infinity are allowed. Positive infinity is represented with an exponent of all ones (255) and a sign bit and mantissa of all zeroes ♾️. Negative numbers (including "negative zero"), negative infinity, and NAN's are not allowed for p either 😤.

NOTE: An implementation using general-purpose hardware or software IEEE floating-point support may want to check that incoming parameters meet this requirement before using them in floating-point math. That way it can dodge unexpected exceptions or traps 🛡️.

The controlled-load service is assigned service_name 5 🏷️.

The TOKEN_BUCKET_TSPEC parameter used by the Controlled-Load service is general parameter number 127, as listed in [5] 🔢.

---

6. Exported Information

The controlled-load service has no required characterization parameters, so nothing is mandatory here 🤷‍♀️. Individual implementations can export whatever implementation-specific measurement and monitoring info they want 📊✨.

---

7. Policing

okay this section is the bouncer 🚪💅. The controlled-load service is given to a flow on the condition that the flow's traffic actually conforms to a TSpec given at flow setup time. This section explains what conformance means, when a controlled-load flow's traffic might not conform, and what the network element does about it 🕵️‍♀️.

Controlled-load service modules give QoS control to traffic that conforms to the TSpec from setup time 🎀. The token bucket parameters mean the traffic has to follow this rule: over any time period, the amount of data sent does not exceed rT+b, where r and b are the token bucket parameters and T is the length of the time period ⏱️. For this accounting, links must count packets smaller than the minimum policing unit m as being of size m 📏. Packets that show up at an element and break the rT+b bound are considered nonconformant 🙅‍♀️.

Packets bigger than the outgoing link MTU are also considered nonconformant 🚫. This isn't expected to happen very often, since flow setup mechanisms are expected to tell the sending application the right path MTU 🗺️.

When nonconformant packets show up for one or more controlled-load flows, each network element must make sure locally that these requirements are met:

1. The network element MUST keep providing the contracted quality of service to those controlled-load flows that aren't experiencing excess traffic 💖.
2. The network element SHOULD keep excess controlled-load traffic from unfairly hurting the handling of arriving best-effort traffic. There's more on this in Section 9 of this document (Guidelines for Implementors) 🫶.
3. Consistent with points 1 and 2, the network element MUST attempt to forward the excess traffic on a best-effort basis if there are enough resources available 🌈.

Network elements must not assume that arriving nonconformant traffic for a specific controlled-load flow is unusual, or a sign of an error 🙅‍♀️. In some situations (especially routers acting as the "split points" of a multicast distribution tree supporting a shared reservation), big numbers of packets will fail the conformance test as a matter of normal operation 🌳.

Network elements must not assume that data sources or upstream elements have "policed" controlled-load flows by limiting their traffic to conform to the flow's TSpec 🙈. Each network element providing controlled-load service MUST independently make sure the requirements above are met when nonconformant traffic arrives for one or more controlled-load flows 🛡️.

Network elements can use any suitable implementation mechanism to meet those requirements 🧰. Examples include token-bucket policing filters and per-flow scheduling algorithms ✨. However, it's not enough to just dump all controlled-load flows into the same shared resource pool. Non-conformant flows have to be kept from starving conformant flows of the processing resources they need 😤.

Section 11 of this note has more discussion on this issue 📚.

Beyond requirements 2 and 3 above, the controlled-load service doesn't define the QoS behavior for flows with nonconformant arriving traffic 🤷‍♀️. It's allowed either to degrade the service for all of the flow's packets equally, or to sort the packets into a conformant set and a nonconformant set and give the two sets different levels of service 🎭. Section 9 of this note discusses this further 💅.

When resources are available, network elements in the interior of the network SHOULD be ready to handle packet bursts somewhat bigger than the actual TSpec 💥. This comes from the traffic distortion effect described in Section 4. As covered there, it can be met with explicit mechanisms or with statistical multiplexing of shared buffering resources 🧠.

When handling this kind of traffic, it's okay to delay a packet a bit if that delay lets it pass the policing function. (Basically, reshape the traffic 🌀.) But the overall requirement for limiting how long any traffic distortion lasts has to be considered too ⏳. The challenge is coming up with a workable reshaping function 🧩.

Intuitively, one plausible approach is to allow a delay of (roughly) up to the maximum queueing delay that completely conforming packets experience, before declaring that a packet has failed the policing function 🤔. Whether this approach has merit, and how the spec should word it, still needs further study 📖✨.

8. Ordering and Merging ✨

Okay so TSpecs can actually be lined up and ranked 👑, but only sometimes. TSpec A is a substitute for ("as good or better than" or "greater than or equal to") TSpec B if and only if:

1. the token bucket rate r for TSpec A is greater than or equal to that of TSpec B,
2. the token bucket depth b for TSpec A is greater than or equal to that of TSpec B,
3. the peak rate p for TSpec A is greater than or equal to that of TSpec B,
4. the minimum policed unit m for TSpec A is less than or equal to that of TSpec B,
5. the maximum packet size M of TSpec A is greater than or equal to that of TSpec B.

Heads up 🙈: not every pair of TSpecs can be ordered against each other. If two TSpecs differ but not all five of the points above are true, then the TSpecs are unordered.

A merged TSpec is the TSpec the RSVP protocol uses when it merges a set of TSpecs into a "merged" reservation. TSpec merging is described further in [4] and [3]. The TSpec merge operation covers two requirements:

• The "merged" TSpec parameters are used as the traffic flow's TSpec at the local node.
• The merged parameters are passed upstream to traffic source(s) to describe characteristics of the actually installed reservation along the data path.

For the controlled-load service, a merged TSpec may be calculated over a set of TSpecs by taking:

1. the largest token bucket rate r;
2. the largest token bucket size b;
3. the largest peak rate p;
4. the smallest minimal policed unit m;
5. the smallest maximum packet size M;

across all members of the set.

A Least Common TSpec is a TSpec that's adequate to describe the traffic from any one of a number of traffic flows. It can be useful when creating a shared reservation for a bunch of flows using SNMP or another management protocol. This is different from the merged TSpec above because the computed parameters are not passed upstream to the sources of traffic. 🦋

For the controlled-load service, the Least Common TSpec may be calculated over a set of TSpecs by taking:

1. the largest token bucket rate r;
2. the largest token bucket size b;
3. the largest peak rate p;
4. the smallest minimal policed unit m;
5. the largest maximum packet size M;

across all members of the set.

The sum of n controlled-load service TSpecs is used when computing the TSpec for a shared reservation of n flows. It's computed by taking:

• The sum across all TSpecs of the token bucket rate parameter r.
• The sum across all TSpecs of the token bucket size parameter b.
• The sum across all TSpecs of the peak rate parameter p.
• The minimum across all TSpecs of the minimum policed unit parameter m.
• The maximum across all TSpecs of the maximum packet size parameter M.

The minimum of two TSpecs depends on whether they can be ordered using the "greater than or equal to" rule above. If one TSpec is less than the other, the smaller one is the minimum. For unordered TSpecs, a different rule kicks in 💅. The minimum of two unordered TSpecs is found by comparing the respective values in the two TSpecs and choosing:

1. the smaller token bucket rate r;
2. the larger token bucket size b;
3. the smaller peak rate p;
4. the smaller minimum policed unit m;
5. the smaller maximum packet size M;

---

9. Guidelines for Implementors 🎀

REQUIREMENTS PLACED ON ADMISSION CONTROL ALGORITHM: The whole point of this service spec is that network elements deliver a level of service closely approximating best-effort service under unloaded conditions. Just like best-effort under those conditions, it is not required that every single packet must be successfully delivered with zero queueing delay 🌸. Network elements providing controlled-load service are permitted to oversubscribe the available resources to some extent. In other words, the bandwidth and buffer requirements you get by summing the TSpec token buckets of all controlled-load flows may exceed the maximum capabilities of the network element. However, this oversubscription may only be done in cases where the element is quite sure that actual utilization is less than the sum of the token buckets would suggest, so that the implementor's performance goals will be met. This information may come from measurement of the aggregate traffic flow, specific knowledge of application traffic statistics, or other means. The most conservative approach, rejecting new flows whenever adding their traffic would cause the strict sum of the token buckets to exceed the capacity of the network element (including consideration of resources needed to maintain the delay and loss characteristics specified by the service), may be appropriate in other circumstances. 🧚

Specific issues related to this subject are discussed in the "Evaluation Criteria" and "Examples of Implementation" sections below.

INTERACTION WITH BEST-EFFORT TRAFFIC: Implementors of this service need to clearly understand that in certain circumstances (routers acting as the "split points" of a multicast distribution tree supporting a shared reservation), large numbers of a flow's packets may fail the TSpec conformance test as a matter of normal operation. According to the requirements of Section 7, these packets should be forwarded on a best-effort basis if resources permit.

If the network element's best-effort queueing algorithm doesn't distinguish between these packets and elastic best-effort traffic such as TCP flows, THE EXCESS CONTROLLED-LOAD PACKETS WILL "BACK OFF" THE ELASTIC TRAFFIC AND DOMINATE THE BEST-EFFORT BANDWIDTH USAGE 😭. The integrated services framework doesn't currently address this issue. However, several possible solutions to the problem are known [RED, xFQ]. Network elements supporting the controlled-load service should implement some mechanism in their best-effort queueing path to discriminate between classes of best-effort traffic and provide elastic traffic with protection from inelastic best-effort flows.

Two basic approaches are available to meet this requirement. The network element can maintain separate resource allocations for different classes of best-effort traffic, so that no one class will excessively dominate the loaded best-effort mix. Alternatively, an element can process excess controlled-load traffic at somewhat lower priority than elastic best-effort traffic, so as to completely avoid the back-off effect discussed above.

If most or all controlled-load traffic comes from non-rate-adaptive real-time applications, the use of priority mechanisms might be desirable. If most controlled-load traffic comes from rate-adaptive realtime or elastic applications trying to establish a bounded minimum level of service, the use of separate resource classes might be preferable. However, this is not a firm guideline. In practice, the network element designer's choice of mechanism will depend heavily on both the goals of the design and the implementation techniques appropriate for the designer's platform. This version of the service specification does not specify one or the other behavior, and leaves the choice to the implementor. 👑

FORWARDING BEHAVIOR IN PRESENCE OF NONCONFORMANT TRAFFIC: As indicated in Section 7, the controlled-load service does not define the QoS behavior delivered to flows with non-conformant arriving traffic. It is permissible either to degrade the service delivered to all of the flow's packets equally, or to sort the flow's packets into a conformant set and a nonconformant set and deliver different levels of service to the two sets.

In the first case, expected queueing delay and packet loss probability will rise for all packets in the flow, but packet delivery reordering will, in general, stay at low levels. This behavior is preferable for applications or transport protocols that are sensitive to excessive packet reordering. A possible example is an unmodified TCP connection, which would see reordering as lost packets, triggering duplicate acks and hence excessive retransmissions. 💀

In the second case, some subset of the flow's packets will be delivered with low loss and delay, while some other subset will be delivered with higher loss and potentially higher delay. The delayed packets will appear to the receiver to have been reordered in the network, while the non-delayed packets will, on average, arrive in a more timely fashion than if all packets were treated equally. This might be preferable for applications that are highly time-sensitive, such as interactive conferencing tools. 🫶

10. Evaluation Criteria 📊

okay so the big rule for controlled-load service is that, no matter what's going on, it has to give accepted data flows service that's basically the same as what that exact flow would get from best-effort service on an unloaded network 💅✨

This gives us a super simple two-step plan 🧪

Step one is to compare best-effort and controlled-load traffic when the network is underloaded:

• Measure the packet loss rate and delay characteristics of a test flow using best-effort service, with no load on the network element.
• Compare those measurements with measurements of the same flow receiving controlled-load service, with no load on the network element.

Closer measurements mean a higher evaluation rating ⭐. A substantial difference in delay characteristics, like the smoothing you'd see in an implementation that scheduled the controlled-load flow with a fixed, constant-bitrate algorithm, SHOULD result in a somewhat lower rating 🙈

Step two is to watch how the controlled-load flow changes as the load goes up 📈

• Increase the background traffic load on the network element, while still measuring the loss and delay characteristics of the controlled-load flow. Characteristics that stay essentially constant as the element is driven into overload mean a high evaluation rating 🦋 Minor changes in the delay distribution mean a somewhat lower rating. Significant increases in delay or loss mean a poor rating 💀

This simple model isn't enough to fully evaluate controlled-load service, though, because three extra variables affect the score 🎀

1. The short-term burstiness of the traffic stream used for the tests above.
2. The degree of long-term change in the controlled-load traffic, as long as it stays within the bounds of its TSpec. (Changes here have a huge effect on certain admission control algorithms 👑)
3. The ratio of controlled-load traffic to other traffic at the network element (either best-effort or other controlled services).

The third variable SHOULD be evaluated specifically, using this procedure:

• With no controlled-load flows in place, overload the network element with best-effort traffic (you'll know it's working when there's substantial packet loss and queueing delay).
• Send requests for controlled-load service with TSpecs that have increasingly large rate and burst parameters. If a request is accepted, verify that traffic matching the TSpec is actually handled with characteristics that closely approximate the unloaded measurements you took above 🔥
• Repeat these experiments to find the range of traffic parameter values (rate, burst size) that the network element successfully handles. Each parameter's useful range MUST be determined for several settings of the other parameter, so you can map out a two-dimensional "region" of successfully handled TSpecs 🗺️ When you compare this with network elements that offer similar capabilities, the region shows how well each element can provide controlled-load service under high load. A larger region means a higher evaluation rating 👑

---

11. Examples of Implementation 🛠️

okay so one possible implementation is a queueing mechanism with two priority levels: a high-priority one for controlled-load traffic and a lower-priority one for best-effort traffic 🍓 An admission control algorithm limits how much traffic gets placed into the high-priority queue. That algorithm MAY be based either on the specified characteristics of the high-priority flows (using the information in the TSpecs), or on the measured characteristics of the existing high-priority flows plus the TSpec of the new request 🧚

Another option is built on the existing capabilities of network elements that support "traffic classes" through mechanisms such as weighted fair queueing or class-based queueing [6]. Here, it's enough to map the data flows accepted for controlled-load service into an existing traffic class with enough capacity to avoid overload. This requirement is enforced by an admission control algorithm that looks at the characteristics of the traffic class, the characteristics of the traffic already admitted to the class, and the TSpec of the new flow asking for service 💖 Again, the admission control algorithm MAY be based either on the TSpec-specified or the measured characteristics of the existing traffic.

A specific version of that approach is to use a scheduler that implements weighted fair queueing or a similar load-management scheme, giving each individual controlled-load flow its own scheduling queue with a correctly chosen weight 🫶 In this case, the traffic scheduler also acts as the policing function, making sure that nonconformant traffic arriving for one controlled-load flow doesn't affect other controlled-load flows or best-effort traffic. This removes a whole mechanism, but the trade-off is that this approach doesn't get any performance or resource-usage gains from statistically aggregating several flows into a single queueing class 🙃

Admission control algorithms based on specified characteristics are likely to be appropriate when the high-priority class has only a few flows, or when the flows' traffic characteristics look highly variable 🥺 In those situations, the measured behavior of the aggregate controlled-load traffic may not predict future traffic well, so a measurement-based admission control algorithm could produce incorrect results. On the flip side, when the past behavior of the aggregate controlled-load traffic is a good predictor of future behavior, a measurement-based algorithm MAY admit more traffic into the controlled-load service class with no degradation in performance 🤩 An implementation MAY choose to switch between these two approaches depending on the nature of the traffic stream at a given time 🔄

There are lots of ways to keep excess (nonconformant) controlled-load traffic isolated from other best-effort traffic 🧼 A low-priority queue for nonconformant controlled-load traffic is simple, but other approaches may provide better service or fit more neatly into existing architectures ✨ Variants of fair queueing or weighted fair queueing MAY be used to give different best-effort traffic classes a percentage of the available resources. One approach is to give each controlled-load flow a 1/N "fair share" percentage of the available best-effort bandwidth for its excess traffic. Another is to provide a single WFQ resource class for all excess controlled-load traffic 💅 Finally, alternate mechanisms such as RED [xxx] MAY be used to provide the same overall function 🌈

---

12. Examples of Use 🌸

controlled-load service MAY be used by any application that can make use of best-effort service, but it's best suited to applications that can usefully describe their traffic requirements 📝 Applications that transport "continuous media" data, like digitized audio or video, are an important example of this group 🎧🎥

Here's the thing though: controlled-load service isn't isochronous and doesn't give any explicit information about transmission delay 🙅‍♀️ So applications with end-to-end timing requirements, including the continuous-media apps mentioned above, bring their own application-specific timing recovery mechanism. It's similar to (or the same as) what they'd need when using best-effort service anyway. A protocol that helps applications with this is the IETF Real-Time Transport Protocol [2] 🧚‍♀️

Load-sensitive applications have two strategies 🎀 They can ask for controlled-load service every time they run, or they can keep an eye on their own performance and only request controlled-load service when best-effort service isn't cutting it. The first option gives higher assurance that the quality delivered to the user won't change over the lifetime of an application session 🔒 The second option is more flexible and saves money in environments where service levels above best-effort come with a charge 💸

---

13. Security Considerations 🔐

okay bestie, this part is serious 😭 A network element implementing this service is intentionally and explicitly expected to give preferential treatment to selected packet traffic. This memo doesn't describe how traffic gets marked for that preferential treatment. Instead, controlled-load service can be invoked through a bunch of mechanisms, including RSVP, SNMP network management software, or proprietary control software. Whatever mechanism is used to invoke controlled-load service MUST provide security sufficient to guard against undesired or unauthorized traffic using that preferential treatment capability 🚨 A correct implementation of controlled-load service is not susceptible to a denial-of-service attack based on maliciously requesting a very small resource allocation for the attacked flow 🙌 That's because the service specification requires traffic beyond the requested level to be carried on a best-effort basis, rather than being dropped. This requirement is discussed further in Section 7 of this memo 📖

Giving preferential service to some flows means giving less service to others 🫠 So it's possible to launch a denial-of-service attack by maliciously reconfiguring the controlled-load "admission control algorithm" to allow overallocation of available bandwidth or other forwarding resources, which starves the non-controlled-load flows 😤 Generally, this isn't likely to make the network more vulnerable to attack, because lots of other router or host reconfigurations can cause denial of service too 🤷‍♀️ It's reasonable to assume that whatever protects against those other reconfiguration attacks will also be enough to protect against this one 🛡️

---

Appendix 1: Use of the Controlled-Load service with RSVP 🧾

okay last bit! 🎉 Using controlled-load service together with the RSVP resource reservation setup protocol is specified in reference [4]. That document gives the format of the RSVP FLOWSPEC, SENDER_TSPEC, and ADSPEC objects needed to support applications that want controlled-load service, and it explains how RSVP processes those objects 💖 The RSVP protocol itself is specified in Reference [3] ✨

References ✨

okay bestie, this is the bibliography bit, the list of all the docs this one leans on 📚 every single citation stays exactly as written, no cap 💅

[1] Shenker, S., and J. Wroclawski. "Network Element Service Specification Template", RFC 2216, September 1997.

[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson. "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.

[3] Braden, R., Ed., et. al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.

[4] Wroclawski, J., "The use of RSVP with IETF Integrated Services", RFC 2210, September 1997.

[5] Shenker, S., and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.

[6] S. Floyd, and V. Jacobson. "Link-sharing and Resource Management Models for Packet Networks," IEEE/ACM Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995.

[7] A. K. J. Parekh. "A Generalized Processor Sharing Approach to Flow Control in Integrated Service Networks". MIT Laboratory for Information and Decision Systems, Report LIDS-TH-2089, February 1992

Author's Address 🎀

this is where the author lives, the official contact details, so you know who to ping about this doc 🦋

John Wroclawski
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA  02139

Phone: 617-253-7885
Fax:   617-253-2673 (FAX)
EMail: jtw@lcs.mit.edu

---

and that's the whole RFC, bestie 🌈👑 you made it through all five parts 🫶💖