RFC 1633

Integrated Services in the Internet Architecture: an Overview

📅 published June 1994, from ietf

RFC 1633 ✨ Integrated Services in the Internet Architecture: an Overview

okay bestie, this is RFC 1633 🦋 It came out of the Network Working Group in June 1994, and it's written by R. Braden (ISI), D. Clark (MIT), and S. Shenker (Xerox PARC). It's Informational 📚 which means it's here to give the Internet community info. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced or changed by this one 💅

Status of this Memo 📜

This memo is here to give info to the Internet community 🌈 It does not specify an Internet standard of any kind. Distribution of this memo is unlimited, so share it with whoever 🫶

Abstract 💭

This memo talks about a proposed extension to the Internet architecture and protocols to provide integrated services. That means supporting real-time traffic as well as the current non-real-time service of IP ⭐ This extension is needed because there's a growing need for real-time service for a bunch of new apps, like teleconferencing, remote seminars, telescience, and distributed simulation. it's giving future 🔮

This memo is the direct product of recent work by Dave Clark, Scott Shenker, Lixia Zhang, Deborah Estrin, Sugih Jamin, John Wroclawski, Shai Herzog, and Bob Braden, and it indirectly draws upon the work of many others. The whole squad 👑

Table of Contents 🗂️

   1. Introduction ...................................................2
   2. Elements of the Architecture ...................................3
      2.1 Integrated Services Model ..................................3
      2.2 Reference Implementation Framework .........................6
   3. Integrated Services Model ......................................11
      3.1 Quality of Service Requirements ............................12
      3.2 Resource-Sharing Requirements and Service Models ...........16
      3.3 Packet Dropping ............................................18
      3.4 Usage Feedback .............................................19
      3.5 Reservation Model ..........................................19
   4. Traffic Control Mechanisms .....................................20
      4.1 Basic Functions ............................................20
      4.2 Applying the Mechanisms ....................................23
      4.3 An example .................................................24
   5. Reservation Setup Protocol .....................................25

      5.1 RSVP Overview ..............................................25
      5.2 Routing and Reservations ...................................28
   6. Acknowledgments ................................................30
   References ........................................................31
   Security Considerations ...........................................32
   Authors' Addresses ................................................33

1. Introduction 🎀

The IETF meetings that get multicast across the Internet have basically turned into a huge experiment in sending digitized voice and video over a packet-switched network 🎥 Three things made it work: (1) lots of modern workstations now come with built-in multimedia hardware, like audio codecs and video frame-grabbers, and the video gear is now cheap 💸 (2) IP multicasting, which isn't yet common in commercial routers, is being provided by the MBONE, a temporary "multicast backbone" 🧚 and (3) super-sophisticated digital audio and video apps have been developed 🔥

These experiments also showed that something important is still missing 🙈 Real-time apps often don't work well over the Internet because of variable queueing delays and congestion losses. The Internet, as it was originally designed, only offers a very simple quality of service (QoS): point-to-point best-effort data delivery. So before real-time apps like remote video, multimedia conferencing, visualization, and virtual reality can be used widely, the Internet infrastructure must be modified to support real-time QoS, which gives some control over end-to-end packet delays. This extension must be designed for multicasting from the beginning, because simply generalizing from the unicast (point-to-point) case does not work. not me thinking "just generalize it" 💀

Real-time QoS isn't the only thing the next generation of traffic management needs 💅 Network operators want to control how bandwidth on a particular link gets shared among different traffic classes. They want to split traffic into a few administrative classes and give each one a minimum percentage of the link bandwidth when things get overloaded, while letting "unused" bandwidth be available at other times. These classes might represent different user groups or different protocol families, for example. This kind of management facility is commonly called controlled link-sharing. We use the term integrated services (IS) for an Internet service model that includes best-effort service, real-time service, and controlled link sharing ✨

The requirements and mechanisms for integrated services have been the subject of a lot of discussion and research over the past several years (the literature is way too large to list even a representative sample here; see the references in [CSZ92, Floyd92, Jacobson91, JSCZ93, Partridge92, SCZ93, RSVP93a] for a partial list). This work has led to the unified approach to integrated services support described in this memo. We believe it's now time to start the engineering that has to come before integrated services can be deployed in the Internet 🚀

Here's the roadmap 🗺️ Section 2 of this memo introduces the elements of an IS extension of the Internet. Section 3 discusses real-time service models [SCZ93a, SCZ93b]. Section 4 discusses traffic control, the forwarding algorithms to be used in routers [CSZ92]. Section 5 discusses the design of RSVP, a resource setup protocol compatible with the assumptions of our IS model [RSVP93a, RSVP93b] 🦋

2. Elements of the Architecture 🏗️

The fundamental service model of the Internet, as embodied in the best-effort delivery service of IP, has stayed unchanged since the beginning of the Internet research project 20 years ago [CerfKahn74]. We're now proposing to alter that model to encompass integrated service. From an academic viewpoint, changing the service model of the Internet is a major undertaking 😤 However, its impact is softened by the fact that we only want to extend the original architecture. The new components and mechanisms to be added will supplement the basic IP service but not replace it 🫶

Basically, the proposed architectural extension has two elements: (1) an extended service model, which we call the IS model, and (2) a reference implementation framework, which gives us a set of vocabulary and a generic program organization to realize the IS model. It's important to separate the service model, which defines the externally visible behavior, from the discussion of the implementation, which may (and should) change during the life of the service model. However, the two are related 💕 To make the service model credible, it's useful to show an example of how it might be realized.

2.1 Integrated Services Model 🌸

The IS model we're proposing includes two sorts of service targeted at real-time traffic: guaranteed and predictive service. It integrates these services with controlled link-sharing, and it's designed to work well with multicast as well as unicast. We'll get to a summary of the IS model in Section 3, but first we're going to talk through some key assumptions behind the model 🧠

The first assumption is that resources (e.g., bandwidth) must be explicitly managed in order to meet application requirements. This implies that "resource reservation" and "admission control" are key building blocks of the service. An alternative approach, which we reject, is trying to support real-time traffic without any explicit changes to the Internet service model 🙅‍♀️

The essence of real-time service is the need for some service guarantees, and we argue that guarantees can't be achieved without reservations. The term "guarantee" here is meant to be interpreted broadly: they may be absolute or statistical, strict or approximate. However, the user must be able to get a service whose quality is predictable enough that the application can operate acceptably over a duration of time determined by the user. Again, "sufficiently" and "acceptable" are vague terms, bestie 🙈 In general, stricter guarantees cost more in resources that are made unavailable for sharing with others 💸

The following arguments have been raised against resource guarantees in the Internet 🍓

"Bandwidth will be infinite." The incredibly large carrying capacity of an optical fiber leads some to conclude that in the future bandwidth will be so abundant, ubiquitous, and cheap that there will be no communication delays other than the speed of light, and therefore there will be no need to reserve resources. However, we believe this will be impossible in the short term and unlikely in the medium term. While raw bandwidth may seem inexpensive, bandwidth provided as a network service is not likely to become so cheap that wasting it becomes the most cost-effective design principle. Even if low-cost bandwidth does eventually become commonly available, we don't accept that it will be available "everywhere" in the Internet. Unless we provide for dealing with congested links, real-time services will simply be precluded in those cases. We find that restriction unacceptable 😭
"Simple priority is sufficient." It's true that simply giving higher priority to real-time traffic would lead to adequate real-time service at some times and under some conditions. But priority is an implementation mechanism, not a service model. If we define the service by means of a specific mechanism, we may not get the exact features we want. With simple priority, the issue is that as soon as there are too many real-time streams competing for the higher priority, every stream gets degraded. Restricting our service to this single failure mode is unacceptable. In some cases, users will demand that some streams succeed while some new requests get a "busy signal" 📞
"Applications can adapt." The development of adaptive real-time applications, such as Jacobson's audio program VAT, does not remove the need to bound packet delivery time. Human needs for interaction and intelligibility limit how much adaptation to network delays is possible. We've seen in real experiments that, while VAT can adapt to network delays of many seconds, users find that interaction is impossible in those cases 🥲

okay so this is where it gets spicy 🌶️✨ we conclude that there is an inescapable requirement for routers to reserve resources, so they can give special QoS to specific user packet streams (aka "flows") 💖 and ngl that's a big deal, because it means routers need flow-specific state, which is a seriously fundamental change to the Internet model 😭. The Internet has always been founded on the idea that all flow-related state lives in the end systems [Clark88] 🌸, and designing TCP/IP around that idea is a huge part of why it's so robust 👑. In section 5 we get into how the flow state added to routers for resource reservation can be made "soft", so we keep that robustness 🦋.

there's a real-world side effect of resource reservation in routers 👀. Since some users are getting privileged service, reservations need enforcement of policy and administrative controls 💅. That leads to two kinds of authentication: authenticating users who make reservation requests, and authenticating packets that use the reserved resources 🔐. These issues aren't unique to "IS" though, because commercialization and commercial security are pushing the rest of the Internet toward the same requirements 💼. We won't dig into policy or security any further in this memo, but they will need attention 🙈.

we also make another fundamental assumption: it's desirable to use the Internet as a common infrastructure for both non-real-time and real-time communication 🌈. Someone could build a whole new parallel infrastructure for real-time services and leave the Internet alone, but we reject that 🙅‍♀️. It would lose the big advantages of statistical sharing between real-time and non-real-time traffic, and it would be way more complex to build and administer than one shared infrastructure.

on top of that common infrastructure, we adopt a unified protocol stack model, using a single internet-layer protocol for both real-time and non-real-time service 🧚. So we propose using the existing internet-layer protocol (e.g., IP or CLNP) for real-time data. Another approach would be to add a brand-new real-time protocol in the internet layer [ST2-90], which is valid, but our unified stack gives us economy of mechanism and lets us fold controlled link-sharing in easily ✨. It also handles partial coverage, meaning IS-capable Internet systems can interoperate with systems that haven't been extended, without the complexity of tunneling 🫶.

we take the view that there should be a single service model for the Internet 👑. If different parts of the Internet had different service models, it would be really hard to see how any end-to-end service quality statements could be made 😵. But a single service model doesn't necessarily mean a single implementation for packet scheduling or admission control 🔥. Specific mechanisms that satisfy our service model have been developed, and other mechanisms could satisfy it too. The reference implementation framework, introduced below, is meant to let us discuss implementation issues without mandating a single design 💖.

based on all of this, we believe an IS extension that includes additional flow state in routers and an explicit setup mechanism is necessary to provide the needed service 💅. A partial solution short of this point would not be a wise investment 🙅‍♀️. We believe these extensions preserve the essential robustness and efficiency of the Internet architecture, and they allow efficient management of network resources. Those goals will stay important even if bandwidth becomes very inexpensive 💸.

2.2 Reference Implementation Framework ✨

we propose a reference implementation framework to realize the IS model 🧩. It has four components: the packet scheduler, the admission control routine, the classifier, and the reservation setup protocol. We'll go over these briefly below, and more fully in Sections 4 and 5.

in the ensuing discussion, we define the "flow" abstraction as a distinguishable stream of related datagrams that results from a single user activity and requires the same QoS 🦋. For example, a flow might be one transport connection or one video stream between a given host pair. It's the finest granularity of packet stream the IS can distinguish. A flow is simplex, meaning it has a single source but N destinations. So an N-way teleconference will generally need N flows, one originating at each site 📞.

in today's Internet, IP forwarding is completely egalitarian 🥹. All packets get the same quality of service, and they're typically forwarded using a strict FIFO queueing discipline. For integrated services, a router must implement an appropriate QoS for each flow, in accordance with the service model. The router function that creates different qualities of service is called "traffic control" 🎀. Traffic control is implemented by three components: the packet scheduler, the classifier, and admission control.

Packet Scheduler 🕰️

the packet scheduler manages the forwarding of different packet streams using a set of queues and perhaps other mechanisms like timers. It must be implemented at the point where packets are queued. That's the output driver level of a typical operating system, and it corresponds to the link layer protocol. The details of the scheduling algorithm may be specific to the particular output medium. For example, the output driver will need to invoke the appropriate link-layer controls when interfacing to a network technology that has an internal bandwidth allocation mechanism.

an experimental packet scheduler has been built that implements the IS model described in Section 3 and [SCZ93]. It's known as the CSZ scheduler, and we'll talk more about it in Section 4 🧪. We note that the CSZ scheme is not mandatory to accomplish our service model. In fact, for parts of the network that are known always to be underloaded, FIFO will deliver satisfactory service 😌.

there's another component that could be considered part of the packet scheduler or kept separate: the estimator [Jacobson91] 🔍. It measures properties of the outgoing traffic stream to develop statistics that control packet scheduling and admission control. This memo will consider the estimator to be a part of the packet scheduler.

Classifier 🗂️

for the purpose of traffic control (and accounting), each incoming packet must be mapped into some class. All packets in the same class get the same treatment from the packet scheduler, and this mapping is performed by the classifier. The choice of a class may be based upon the contents of the existing packet header(s) and/or some additional classification number added to each packet.

a class might correspond to a broad category of flows, e.g., all video flows or all flows attributable to a particular organization. On the other hand, a class might hold only a single flow. A class is an abstraction that may be local to a particular router, so the same packet may be classified differently by different routers along the path 🛤️. For example, backbone routers may choose to map many flows into a few aggregated classes, while routers nearer the periphery, where there is much less aggregation, may use a separate class for each flow.

Admission Control 🚪

admission control implements the decision algorithm that a router or host uses to determine whether a new flow can be granted the requested QoS without impacting earlier guarantees. It is invoked at each node to make a local accept/reject decision, at the time a host requests a real-time service along some path through the Internet. The admission control algorithm must be consistent with the service model, and it is logically part of traffic control. There are still open research issues in admission control, but a first cut exists [JCSZ92] 🧠.

admission control is sometimes confused with policing or enforcement. Policing is a packet-by-packet function at the "edge" of the network that ensures a host does not violate its promised traffic characteristics 👀. We consider policing to be one of the functions of the packet scheduler.

in addition to ensuring that QoS guarantees are met, admission control will be concerned with enforcing administrative policies on resource reservations 📋. Some policies will demand authentication of those requesting reservations. Finally, admission control will play an important role in accounting and administrative reporting 🧾.

the fourth and final component of our implementation framework is a reservation setup protocol 🏁. It's necessary to create and maintain flow-specific state in the endpoint hosts and in the routers along the path of a flow. Section discusses a reservation setup protocol called RSVP (for "ReSerVation Protocol") [RSVP93a, RSVP93b] 💜. It may not be possible to insist that there be only one reservation protocol in the Internet, but we will argue that multiple choices for reservation protocols will cause confusion 😬. We believe multiple protocols should exist only if they support different modes of reservation.

the setup requirements for the link-sharing portion of the service model are far less clear than those for resource reservations 🤷‍♀️. We expect much of this can be done through network management interfaces, and so it need not be part of the overall architecture. We may also need RSVP to play a role in providing the required state.

to state its resource requirements, an application must specify the desired QoS using a list of parameters called a "flowspec" [Partridge92] 📝. The flowspec is carried by the reservation setup protocol, passed to admission control to test for acceptability, and ultimately used to parametrize the packet scheduling mechanism ⚙️.

Figure shows how these components might fit into an IP router that has been extended to provide integrated services 🗺️. The router has two broad functional divisions: the forwarding path below the double horizontal line, and the background code above the line. bestie, the diagram is coming up next 🧚

okay so the forwarding path of a router runs for EVERY. SINGLE. PACKET 😭 which means it has to be highly optimized 🔥 like, in most commercial routers it literally gets a hardware assist 💅. The forwarding path is split into three sections: input driver, internet forwarder, and output driver 🎀. The internet forwarder reads the internetworking protocol header that matches the protocol suite, e.g., the IP header for TCP/IP, or the CLNP header for OSI 🧚. For each packet, it runs a suite-dependent classifier and then passes the packet and its class to the right output driver 🦋. A classifier has to be both general AND efficient ✨, so a common mechanism should be used for both resource classification and route lookup 💜.

The output driver implements the packet scheduler 💖. (Layerists will notice that the output driver now has two distinct sections: the packet scheduler, which is mostly independent of the detailed mechanics of the interface, and the actual I/O driver, which only cares about the grittiness of the hardware. The estimator lives somewhere in between. We're only noting this fact, without suggesting that it be elevated to a principle. 🙈)

       _____________________________________________________________
      |         ____________     ____________     ___________       |
      |        |            |   | Reservation|   |           |      |
      |        |   Routing  |   |    Setup   |   | Management|      |
      |        |    Agent   |   |    Agent   |   |  Agent    |      |
      |        |______._____|   |______._____|   |_____._____|      |
      |               .                .    |          .            |
      |               .                .   _V________  .            |
      |               .                .  | Admission| .            |
      |               .                .  |  Control | .            |
      |               V                .  |__________| .            |
      |           [Routing ]           V               V            |
      |           [Database]     [Traffic Control Database]         |
      |=============================================================|
      |        |                  |     _______                     |
      |        |   __________     |    |_|_|_|_| => o               |
      |        |  |          |    |      Packet     |     _____     |
      |     ====> |Classifier| =====>   Scheduler   |===>|_|_|_| ===>
      |        |  |__________|    |     _______     |               |
      |        |                  |    |_|_|_|_| => o               |
      | Input  |   Internet       |                                 |
      | Driver |   Forwarder      |     O u t p u t   D r i v e r   |
      |________|__________________|_________________________________|

            Figure 1: Implementation Reference Model for Routers

The background code is simply loaded into router memory and run by a general-purpose CPU 🧠. These background routines build the data structures that control the forwarding path 🛠️. The routing agent implements a particular routing protocol and builds a routing database 🗺️. The reservation setup agent implements the protocol used to set up resource reservations; see Section . If admission control gives the "OK" for a new request, the right changes get made to the classifier and packet scheduler database so the desired QoS actually happens ✅. Finally, every router supports an agent for network management 👑. This agent must be able to modify the classifier and packet scheduler databases to set up controlled link-sharing and to set admission control policies. Iconic behavior 💅.

The host setup is generally similar to the router one, with the addition of applications 📱. Instead of being forwarded, host data starts and ends in an application 🌸. An application that needs a real-time QoS for a flow has to somehow invoke a local reservation setup agent 🫶. The best way to interface with applications is still to be determined 🤔. For example, there might be an explicit API for network resource setup, or the setup might be invoked implicitly as part of the operating system scheduling function ⭐. The IP output routine of a host may need no classifier, since the class assignment for a packet can be specified in the local I/O control structure that corresponds to the flow 🍓.

In routers, integrated service will require changes to both the forwarding path and the background functions 🔥. The forwarding path, which may depend on hardware acceleration for performance, will be the harder and more costly one to change 😤. So it's vital to pick a set of traffic control mechanisms that is general and adaptable to a wide variety of policy requirements and future circumstances, and that can be implemented efficiently 💖🌈.

3. Integrated Services Model ✨

A service model is embedded within the network service interface that applications invoke to define the set of services they can request 🎀. Both the underlying network technology and the overlying suite of applications will keep evolving, but the need for compatibility means this service interface has to stay relatively stable (or, more properly, extensible; we do expect to add new services in the future, but it's going to be hard to change existing services 🙈). Because of its lasting impact, the service model should not be designed around any specific network artifact, and should instead be based on fundamental service requirements 💅.

We now briefly describe a proposal for a core set of services for the Internet 🌐. This proposed core service model is described more fully in [SCZ93a, SCZ93b]. The core service model addresses the services that relate most directly to the time-of-delivery of packets ⏰. We leave the remaining services (such as routing, security, or stream synchronization) for other standardization venues 🧚. A service model consists of a set of service commitments: in response to a service request, the network commits to deliver some service 🤝. These service commitments can be sorted by the entity they're made to. They can be made to individual flows or to collective entities (classes of flows) 🦋. The commitments made to individual flows are meant to provide reasonable application performance, so they're driven by the ergonomic requirements of applications, and they relate to the quality of service delivered to a single flow 💖. The commitments made to collective entities are driven by resource-sharing, or economic, requirements, and they relate to the aggregate resources made available to the various entities 💜.

In this section we start by looking at the service requirements of individual flows and proposing a matching set of services ✨. Then we discuss the service requirements and services for resource sharing 🫧. Finally, we wrap up with some remarks about packet dropping 🌸.

3.1 Quality of Service Requirements 💖

The core service model is concerned almost exclusively with the time-of-delivery of packets 🕰️. So per-packet delay is the central quantity the network makes quality of service commitments about. We make an even more restrictive assumption: the only quantity we make quantitative service commitments about is bounds on the maximum and minimum delays 📏.

The degree to which application performance depends on low delay varies WIDELY, and we can make a few qualitative distinctions between applications based on how dependent they are 🔍. One class of applications needs the data in each packet by a certain time, and if the data hasn't arrived by then, it's basically worthless. We call these real-time applications ⏳. Another class of applications will always wait for data to arrive. We call these "elastic" applications 🫠. We now consider the delay requirements of these two classes separately 💅.

3.1.1 Real-Time Applications 🎀

An important class of these real-time applications, which are the only real-time applications we explicitly consider in the arguments that follow, are "playback" applications 🎶. In a playback application, the source takes some signal, packetizes it, and then transmits the packets over the network 📦. The network inevitably introduces some variation in the delay of the delivered packets 😵‍💫. The receiver depacketizes the data and then tries to faithfully play back the signal. It does this by buffering the incoming data and then replaying the signal at some fixed offset delay from the original departure time. The term "playback point" refers to the point in time that is offset from the original departure time by this fixed delay 🕒. Any data that arrives before its associated playback point can be used to reconstruct the signal. Data arriving after the playback point is essentially useless for reconstructing the real-time signal 🙅‍♀️.

In order to choose a reasonable value for the offset delay, an application needs some "a priori" characterization of the maximum delay its packets will experience 🧐. This "a priori" characterization could either be provided by the network in a quantitative service commitment to a delay bound, or come from observing the delays experienced by previously arrived packets. The application needs to know what delays to expect, but that expectation doesn't have to stay constant for the entire duration of the flow 📉.

The performance of a playback application is measured along two dimensions: latency and fidelity 📊. Some playback applications, especially ones that involve interaction between the two ends of a connection (like a phone call), are pretty sensitive to latency 📞. Other playback applications, like transmitting a movie or lecture, aren't 🍿. Similarly, applications show a wide range of sensitivity to loss of fidelity 🎧. We'll consider two somewhat artificially dichotomous classes: intolerant applications, which require absolutely faithful playback, and tolerant applications, which can handle some loss of fidelity 💅. We expect the vast bulk of audio and video applications to be tolerant, but we also suspect there will be other applications, such as circuit emulation, that are intolerant 🫶💜.

Okay bestie, so delay messes with playback in two ways 🫶 First, the offset delay (your best guess about how late future packets will be) sets the app's latency. Second, any single packet that shows up later than the offset delay ruins the fidelity 😭 The app then has two options: change the offset delay to play the late packet (distortion), or just toss it (an incomplete signal). Which one is better depends on the app, but the big takeaway is that late packets always lower fidelity 💀

Intolerant apps have to use a fixed offset delay, because even a tiny wobble in the offset adds distortion ✨ For a given spread of packet delays, that fixed offset has to be bigger than the absolute maximum delay, so no packet is ever late 🙈 An intolerant app can only pick that number right if it gets a perfectly reliable upper bound on the max delay of each packet. A service that gives a perfectly reliable upper bound on delay is called "guaranteed service", and it's the model we're suggesting for intolerant playback apps 👑

Tolerant apps are chill though 🦋 They don't need the offset to be bigger than the absolute maximum delay, since they can handle a few late packets. Even better, instead of one fixed offset, they can lower their latency by changing the offset based on the packet delays they actually saw recently. We call apps that do this "adaptive" playback apps 🌸

For tolerant apps, we propose "predictive service", which gives a fairly reliable bound, but not a perfectly reliable one 💅 Unlike the guaranteed bound, this one isn't built on worst-case assumptions about what other flows are doing. It can be computed with properly conservative predictions about other flows instead. If the network gets it wrong and the bound gets broken, the app's performance might take a hit, but users are fine with those interruptions in exchange for the lower cost ✨ Also, since so many tolerant apps are adaptive, we add "minimax" service to predictive service too. Its goal is to minimize the ex post maximum delay. It isn't trying to make every packet fast 🏃‍♀️ It's trying to pull in the tail of the delay distribution 🎀

Honestly, if everything else were equal, an app would never do worse with absolutely reliable bounds than with fairly reliable ones 🤔 So why even offer predictive service? It's all about efficiency 🧠 When you loosen the requirement from perfectly reliable to fairly reliable bounds, the network can sustain a higher level of utilization, so predictive service presumably costs less than guaranteed service 💜 The whole predictive class is based on a hunch: the performance penalty will be small for tolerant apps, but the overall efficiency gain will be huge 🌈

To give a delay bound, the network has to know the nature of the traffic coming from the source, and there has to be an admission control algorithm that makes sure a requested flow can actually fit ✨ Traffic characterization and admission control are a must for these real-time delay bound services. This is a core part of our overall architecture 👑 Up to now we've assumed an app's data generation is just an intrinsic property the network doesn't affect. But lots of audio and video apps can change their coding scheme, which changes the data they generate depending on what service the network offers 🎬 That creates a tradeoff between fidelity (of the coding scheme itself, not of the playback) and the flow's bandwidth needs 💖 These "rate-adaptive" playback apps can adjust to current network conditions not just by resetting their playback point, but also by changing the traffic pattern itself 🫧 For rate-adaptive apps, the traffic characterizations used in a service commitment aren't set in stone. So we can extend the service model so the network notifies rate-adaptive apps to change their traffic characterization, either implicitly through packet drops or explicitly through control packets 🦋

3.1.2 Elastic Applications

Real-time apps don't wait for late data to arrive, but elastic applications always wait for data 🫶 That doesn't mean they don't care about delay. Honestly, significantly increasing the delay of a packet will often hurt the app's performance 😭 The real point is that elastic apps usually use data the moment it arrives instead of buffering it for later, and they'll always choose to wait for incoming data rather than go on without it ⏳ Since arriving data gets used right away, these apps don't need any a priori characterization of the service to work 💅 Generally speaking, for a given spread of packet delays, an elastic app's perceived performance depends more on the average delay than on the tail of the distribution 🌸

There are a few categories of elastic apps: interactive burst (Telnet, X, NFS), interactive bulk transfer (FTP), and asynchronous bulk transfer (electronic mail, FAX) 📬 Their delay needs range from pretty demanding for interactive burst apps to pretty laid-back for asynchronous bulk transfer, with interactive bulk transfer sitting in the middle 🍓

The service model that fits elastic apps is "as-soon-as-possible", or ASAP service 🏃‍♀️ (For compatibility with historical usage, we'll say best-effort service when we mean ASAP service.) We also suggest offering several classes of best-effort service so they reflect how sensitive different elastic apps are to delay ✨ That way interactive burst apps get lower delays than interactive bulk apps, and interactive bulk apps get lower delays than asynchronous bulk apps 👑 Unlike the real-time models, apps using this service aren't subject to admission control 🙌

The taxonomy of apps into tolerant playback, intolerant playback, and elastic isn't exact or complete 🙈 It was only used to steer the development of the core service model. The core service model should be judged by how well it meets the needs of the whole spectrum of apps, not by whether the underlying taxonomy is valid 🧚 Also, not every real-time app is a playback app. For example, you could imagine a visualization app that just displays the image in each packet as soon as it shows up 🖼️ Non-playback apps can still use either the guaranteed or predictive real-time model, even though those services aren't specifically tailored to them 🎀 And playback apps can't be neatly sorted into tolerant or intolerant either. They fall along a continuum, so offering both guaranteed and predictive service lets apps make their own tradeoff between fidelity, latency, and cost 💜 Even with these obvious flaws in the taxonomy, we expect it to describe the service requirements of current and future apps well enough that the core service model can meet everyone's needs 🌈

Okay so the last section was about quality of service commitments, and those dictate how the network has to split its resources among individual flows 🎀 That split is usually negotiated flow by flow, as each flow asks to be admitted to the network. It doesn't cover any of the policy issues that come up when you look at collections of flows 🫣 To deal with those collective policy issues, we now talk about resource-sharing service commitments. Remember that for individual QoS commitments, we only cared about delay. Here, the quantity we care about most in resource-sharing is aggregate bandwidth on individual links 💖 This component of the service model is called "link-sharing", and it answers the question of how to share a link's aggregate bandwidth among various collective entities according to some set of specified shares 🦋 There are a few examples people usually use to explain why link-sharing among collective entities is needed 🔥

Multi-entity link-sharing. A link might be bought and used together by several organizations, government agencies, or things like that 🏛️ They may want to make sure that under overload, the link is shared in a controlled way, maybe in proportion to each entity's capital investment 💅 At the same time, they might want any one of the entities to be able to use all the idle bandwidth whenever the link is underloaded 🌸

Multi-protocol link-sharing 🌈 okay so picture a multi-protocol Internet. Sometimes you want to stop one protocol family (DECnet, IP, IPX, OSI, SNA, etc.) from hogging the whole link and shoving everyone else out 💀. This matters because different families can detect and react to congestion in different ways, and some of those ways are more "aggressive" than others. So one protocol might back off way faster than another under congestion and end up with zero bandwidth 😭. Explicit control in the router may be required to fix that. Again, you'd probably expect this control to only kick in when things are overloaded, while an idle link can still be used in any proportion 🦋.

Multi-service sharing 💖 within a protocol family like IP, an administrator might want to cap how much bandwidth each service class gets. For example, they might want to limit real-time traffic to some fraction of the link so it doesn't preempt elastic traffic such as FTP 🎀.

In general terms, the link-sharing service model is to share the aggregate bandwidth according to some specified shares. We can extend this into a hierarchical version 🌸. Picture a link split between a bunch of organizations, each of which divides its slice among protocols, and each protocol divides its slice among services. The sharing is defined by a tree, with shares assigned to each leaf node 🌳.

Now the idealized fluid model of instantaneous link-sharing with proportional sharing of excess is the fluid processor sharing model (introduced in [DKS89], further explored in [Parekh92], and generalized to the hierarchical case) 🧪. At every instant, the available bandwidth is shared between the active entities (i.e., those having packets in the queue) in proportion to their assigned shares of the resource. This fluid model has the desired policy behavior, but it's of course an unrealistic idealization 😌. So we propose the actual service model should approximate, as closely as possible, the bandwidth shares produced by this ideal fluid model. It's not necessary to require that the exact order of packet departures match the fluid model, because we presume all detailed per-packet delay requirements of individual flows are handled through quality of service commitments. Plus, satisfaction with the link-sharing service probably won't depend very sensitively on small deviations from the scheduling implied by the fluid link-sharing model ✨.

We already noticed that admission control was necessary to make sure real-time service commitments could be met. Similarly, admission control will again be necessary to make sure link-sharing commitments can be met 💅. For each entity, admission control must keep the cumulative guaranteed and predictive traffic from exceeding the assigned link-share.

3.3 Packet Dropping 🍓

So far we've implicitly assumed that all packets within a flow were equally important. But in lots of audio and video streams, some packets are way more valuable than others 🎧. So we propose augmenting the service model with a "preemptable" packet service, where some of the packets within a flow could be marked as preemptable. When the network is in danger of missing some of its quantitative service commitments, it could exercise a packet's "preemptability option" and discard that packet. Not merely delay it, though, because that would cause out-of-order problems 🙈. By discarding these preemptable packets, a router can reduce the delays of the packets that weren't preempted.

Furthermore, one can define a class of packets that is not subject to admission control 👑. In the scenario above, where preemptable packets are dropped only when quantitative service commitments are in danger of being violated, the expectation is that preemptable packets will almost always be delivered. So they must be included in the traffic description used in admission control. However, we can extend preemptability to the extreme case of "expendable" packets (the term expendable connotes an extreme degree of preemptability) 💀, where the expectation is that many of these expendable packets may not be delivered. One can then exclude expendable packets from the traffic description used in admission control. In other words, the packets aren't considered part of the flow from the perspective of admission control, since there's no commitment that they'll be delivered 🦋.

3.4 Usage Feedback 💸

Another important issue in the service is the model for usage feedback, also known as "accounting," which exists to prevent abuse of network resources 🔍. The link-sharing service described earlier can be used to provide administratively-imposed limits on usage. However, a more free-market model of network access will require back-pressure on users for the network resources they reserve. This is a highly contentious issue, and we are not prepared to say more about it at this time 🙃.

3.5 Reservation Model 📋

The "reservation model" describes how an application negotiates for a QoS level 🤝. The simplest model is that the application asks for a particular QoS, and the network either grants it or refuses. Often the situation is more complex. Many applications can get acceptable service from a range of QoS levels, or more generally, from anywhere within some region of the multi-dimensional space of a flowspec 🌈.

For example, rather than simply refusing the request, the network might grant a lower resource level and inform the application of what QoS was actually granted 🫶. A more complex example is the "two-pass" reservation model. In this scheme, an "offered" flowspec is propagated along the multicast distribution tree from each sender Si to all receivers Rj. Each router along the path records these values and perhaps adjusts them to reflect available capacity. The receivers get these offers, generate corresponding "requested" flowspecs, and propagate them back along the same routes to the senders. At each node, a local reconciliation has to happen between the offered and the requested flowspec to create a reservation, and an appropriately modified requested flowspec is passed on 🧩. This two-pass scheme allows extensive properties like allowed delay to be distributed across hops in the path [Tenet90, ST2-90]. Further work is needed to define the amount of generality, with a corresponding level of complexity, that is required in the reservation model 🤔.

4. Traffic Control Mechanisms 🚦

We first survey very briefly the possible traffic control mechanisms. Then in Section 4.2 we apply a subset of these mechanisms to support the various services that we have proposed ✨.

4.1 Basic Functions 🧠

In the packet forwarding path, there's actually a very limited set of actions that a router can take 🙃. Given a particular packet, a router must select a route for it. In addition, the router can either forward it or drop it, and the router may reorder it with respect to other packets waiting to depart. The router can also hold the packet, even though the link is idle. These are the building blocks we have to fashion the desired behavior from 🧱.

4.1.1 Packet Scheduling 📅

The basic function of packet scheduling is to reorder the output queue 🔀. There are many papers written on possible ways to manage the output queue, and on the resulting behavior. Perhaps the simplest approach is a priority scheme, where packets are ordered by priority and the highest-priority packets always leave first. This gives some packets absolute preference over others. If there are enough higher-priority packets, the lower-priority class can be completely prevented from being sent 😭.

An alternative scheduling scheme is round-robin or some variant, which gives different classes of packets access to a share of the link. A variant called Weighted Fair Queueing, or WFQ, has been demonstrated to allocate the total bandwidth of a link into specified shares 🎀.

There are more complex schemes for queue management, most of which involve observing the service objectives of individual packets, such as delivery deadline, and ordering packets based on these criteria 🧐.

4.1.2 Packet Dropping 🪂

The controlled dropping of packets is just as important as their scheduling 💅.

Most obviously, a router must drop packets when its buffers are all full. This fact, however, doesn't determine which packet should be dropped. Dropping the arriving packet, while simple, may cause undesired behavior 😬.

In the context of today's Internet, with TCP operating over best-effort IP service, dropping a packet is taken by TCP as a signal of congestion and causes it to reduce its load on the network. So picking a packet to drop is the same as picking a source to throttle 🫠. Without going into any particular algorithm, this simple relation suggests that some specific dropping controls should be implemented in routers to improve congestion control 🌸.

In the context of real-time services, dropping more directly relates to achieving the desired quality of service ⏱️. If a queue builds up, dropping one packet reduces the delay of all the packets behind it in the queue. The loss of one can contribute to the success of many 💖. The problem for the implementor is to determine when the service objective (the delay bound) is in danger of being violated. You can't look at queue length as an indication of how long packets have sat in a queue 🙅‍♀️. If there's a priority scheme in place, lower-priority packets can be pre-empted indefinitely, so even a short queue may have very old packets in it. While actual time stamps could be used to measure holding time, the complexity may be unacceptable 🥲.

Some simple dropping schemes, such as combining all the buffers into a single global pool and dropping the arriving packet if the pool is full, can defeat the service objective of a WFQ scheduling scheme. Thus, dropping and scheduling must be coordinated 🔥.

4.1.3 Packet Classification 🏷️

The above discussion of scheduling and dropping presumed that the packet had already been classified into some flow or sequence of packets that should be treated in a specified way. A preliminary step to this sort of processing is the classification itself 🧚. Today, a router looks at the destination address and selects a route. The destination address is not sufficient to select the class of service a packet must receive, though. More information is needed 👀✨.

One option would be to ditch the IP datagram model and go with a virtual circuit model 🦋. A circuit gets set up with specific service attributes, and each packet just carries a circuit identifier. That's how ATM does it, and it's also the approach of protocols like ST-II [ST2-90]. A less IP-hostile option is to let the classifier peek at more fields in the packet, like the source address, the protocol number, and the port fields 👀. So video streams could be spotted by a particular well-known port in the UDP header, or a specific flow could be recognized by looking at both the source and destination port numbers. You could even go deeper and check a field in the application layer to pick out a subset of a hierarchically-encoded video stream 🎀.

The classifier's problems are complexity and processing overhead 💀. Current experience suggests that careful implementation of efficient algorithms can lead to efficient classification of IP packets 🔥. This matters a lot, because it means we can add QoS support to existing applications, like Telnet, that are built on today's IP headers ✨.

One way to cut the overhead of classification would be a "flow-id" field in the Internet-layer packet header 🧚. This flow-id would be a handle that could be cached and used to short-cut classification of the packet. There are lots of variations on this idea, and engineering is needed to pick the best design 💜.

4.1.4. Admission Control 🚦

As we said in the intro, real-time service depends on setting up state in the router and making commitments to certain classes of packets. To keep those commitments, resources have to be explicitly requested, so the request can be refused if the resources aren't available. Deciding whether resources are available is called admission control 🙅‍♀️.

Admission control requires that the router understand the demands currently being made on its assets. The traditional approach is to remember the service parameters of past requests, then make a computation based on the worst-case bounds on each service. A more recent proposal, which is likely to give better link utilization, is to program the router to measure the actual usage by existing packet flows and use that measured information as a basis for admitting new flows [JCSZ92] 📊. This approach carries a higher risk of overload 😬, but it may prove much more effective at using bandwidth 💸.

Note that while the need for admission control is part of the global service model, the details of the algorithm run in each router are a local matter. So vendors can compete by developing and marketing better admission control algorithms, which lead to higher link loadings with fewer service overloads 🏆.

4.2. Applying the Mechanisms 🛠️

The various tools described above can be combined to support the services discussed in section 3 💖.

Guaranteed delay bounds: A theoretical result by Parekh [Parekh92] shows that if the router implements a WFQ scheduling discipline, and if the nature of the traffic source can be characterized (e.g. if it fits within some bound such as a token bucket), then there will be an absolute upper bound on the network delay of the traffic in question. This simple and very powerful result applies not just to one switch, but to general networks of routers. The result is constructive: Parekh displays a source behavior which leads to the bound, and then shows that this behavior is the worst possible. That means the bound he computes is the best there can be, under these assumptions 🙌.
Link sharing: The same WFQ scheme can provide controlled link sharing. The service objective here isn't to bound delay, but to limit overload shares on a link, while allowing any mix of traffic to proceed if there's spare capacity. This use of WFQ is available in commercial routers today, and it's used to segregate traffic into classes based on things like protocol type or application. For example, you can allocate separate shares to TCP, IPX and SNA, and you can make sure network control traffic gets a guaranteed share of the link 🔐.
Predictive real-time service: This service is actually more subtle than guaranteed service 🧐. Its objective is to give a delay bound that's as low as possible on one hand, and stable enough that the receiver can estimate it on the other. The WFQ mechanism leads to a guaranteed bound, but not necessarily a low one. In fact, mixing traffic into one queue, rather than separating it as in WFQ, leads to lower bounds, so long as the mixed traffic is generally similar (e.g., mixing traffic from multiple video coders makes sense, mixing video and FTP does not) 🎬.

This suggests we need a two-tier mechanism 💅: the first tier separates traffic which has different service objectives, and the second tier schedules traffic within each first-tier class in order to meet its service objective.

4.3. An example: The CSZ scheme 🌈

As a proof of concept, a code package has been implemented which realizes the services discussed above 🧪. It uses a number of the basic tools, combined in a way specific to the service needs. We describe in general terms how it works, to suggest how services can be realized. We stress that there are other ways of building a router to meet the same service needs, and there are in fact other implementations being used today.

At the top level, the CSZ code uses WFQ as an isolation mechanism to separate guaranteed flows from each other, as well as from the rest of the traffic. Guaranteed service gets the highest priority when and only when it needs access to meet its deadline ⏰. WFQ provides a separate guarantee for each and every guaranteed flow.

Predictive service and best effort service are separated by priority. Within the predictive service class, a further priority is used to provide sub-classes with different delay bounds. Inside each predictive sub-class, simple FIFO queueing is used to mix the traffic, which seems to produce good overall delay behavior 🍓. This works because the top-tier algorithm has already separated out the best effort traffic, such as FTP.

Within the best-effort class, WFQ is used to provide link sharing. Since there may be a requirement for nested shares, this WFQ code can be used recursively 🪆. So there are two different uses of WFQ in this code: one to segregate the guaranteed classes, and one to segregate the link shares. They're similar, but they differ in detail.

Within each link share of the best effort class, priority is used to let more time-sensitive elastic traffic go ahead of other elastic traffic, e.g., to allow interactive traffic to precede asynchronous bulk transfers 🏃‍♀️.

The CSZ code uses both WFQ and priority in an alternating manner to build a mechanism that supports a range of rather sophisticated service offerings 🧠. This discussion is very brief, and it doesn't touch on a number of significant issues, such as how the CSZ code fits real-time traffic into the link sharing objectives. But the basic building blocks are very simple, and very powerful 💪. In particular, while priority has been proposed as a key to real-time services, WFQ may be the more general and powerful of the two schemes 👑. It, rather than priority, supports guaranteed service and link sharing.

5. Reservation Setup Protocol 📮

There are a number of requirements to be met by the design of a reservation setup protocol 📝. It should be fundamentally designed for a multicast environment, and it must accommodate heterogeneous service needs. It must give flexible control over the manner in which reservations can be shared along branches of the multicast delivery trees. It should be designed around the elementary action of adding one sender and/or receiver to an existing set, or deleting one. It must be robust and scale well to large multicast groups. Finally, it must provide for advance reservation of resources, and for the preemption that this implies. The reservation setup protocol RSVP has been designed to meet these requirements [RSVP93a, RSVP93b]. This section gives an overview of the design of RSVP.

5.1. RSVP Overview 🌊

Figure 2 below shows multi-source, multi-destination data delivery for a particular shared, distributed application 🫧. The arrows indicate data flow from senders S1 and S2 to receivers R1, R2, and R3, and the cloud represents the distribution mesh created by the multicast routing protocol. Multicast distribution replicates each data packet from a sender Si, so it can be delivered to every receiver Rj. We treat unicast delivery from S1 to R1 as a special case, and we call this multicast distribution mesh a session. A session is defined by the common IP (multicast) destination address of the receiver(s) 📍.

                 Senders                              Receivers
                             _____________________
                            (                     ) ===> R1
                    S1 ===> (    Multicast        )
                            (                     ) ===> R2
                            (    distribution     )
                    S2 ===> (                     )
                            (                     ) ===> R3
                            (_____________________)

                   Figure 2: Multicast Distribution Session

5.1.1. Flowspecs and Filter Specs 🔍

In general, an RSVP reservation request specifies the amount of resources to be reserved for all, or some subset of, the packets in a particular session 🎟️. The resource quantity is specified by a flowspec, while the packet subset to receive those resources is specified by a filter spec. Assuming admission control succeeds, the flowspec will be used to parametrize a resource class in the packet scheduler, and the filter spec will be instantiated in the packet classifier to map the appropriate packets into this class. The subset of the classifier state that selects a particular class is referred to in RSVP documentation as a (packet) "filter" 🧩.

The RSVP protocol mechanisms provide a very general facility for creating and maintaining distributed reservation state across the mesh of multicast delivery paths 🕸️. These mechanisms treat flowspecs and filter specs as mostly opaque binary data, handing them to the local traffic control machinery for interpretation. Of course, the service model presented to an application must specify how to encode flowspecs and filter specs 🫶.

5.1.2 Reservation Styles ✨

okay so RSVP has several different reservation "styles" 💅 and these decide how the resource needs of multiple receivers get combined in the routers. The styles let the reserved resources meet application requirements way more efficiently 🦋 Right now there are three: "wildcard", "fixed-filter", and "dynamic-filter" 🌸

A wildcard reservation uses a filter spec that isn't source-specific, so all packets headed for the associated destination (session) can share one common pool of reserved resources 🫧 That means a single resource allocation can cover all the distribution paths for the group. The wildcard style is giving audio conference energy 🎙️ where at most a small number of sources are active at once and can share the allocation 💜

The other two styles use filter specs that pick out particular sources. A receiver might want to receive from a fixed set of sources, or it might want the network to switch between different sources by changing its filter spec(s) dynamically ⭐ A fixed-filter reservation can't be changed during its lifetime without re-invoking admission control 🙈 Dynamic-filter reservations do let a receiver change its choice of sources over time without additional admission control. However, this requires that sufficient resources be allocated to handle the worst case, when all downstream receivers take input from different sources 😭 The worst case is literally the main character of this section lol.

5.1.3 Receiver Initiation 🎀

okay big design question: should senders or receivers be responsible for starting reservations? 🤔 A sender knows the qualities of the traffic stream it can send, while a receiver knows what it wants to (or can) receive. The most obvious move is to let the sender kick it off. But ngl that scales poorly for large, dynamic multicast delivery trees and for heterogeneous receivers 💀

Both of those scaling problems get solved by making the receiver responsible for initiating the reservation ✨ Receiver initiation handles heterogeneous receivers easily. Each receiver just asks for a reservation that fits itself, and any differences among reservations from different receivers get "merged" inside the network by RSVP 🧚 It's also consistent with IP multicast, where a multicast group gets created implicitly when receivers join it 🌈

Receiver-initiated reservation is the natural choice for multicast sessions. For unicast sessions, though, the case for receiver initiation may look weaker, since the sender might be the logical session initiator 🤷 However, we expect that every realtime application will have its own higher-level signalling and control protocol, and that protocol can be used to signal the receiver to initiate a reservation (and perhaps indicate the flowspec to be used) 🎀 For simplicity and economy, a setup protocol should support only one direction of initiation, and receiver initiation appears to us to be the clear winner 🏆

RSVP uses receiver-initiation of reservations [RSVP93b]. A receiver is assumed to learn the senders' offered flowspecs by a higher-level mechanism ("out of band"). It then generates its own desired flowspec and propagates it towards the senders, making reservations in each router along the way 🦋

5.1.4 Soft State 🧊

There are two different possible styles for reservation setup protocols: the "hard state" (HS) approach (also called "connection-oriented"), and the "soft state" (SS) approach (also called "connectionless") 💜 In both approaches, multicast distribution is performed using flow-specific state in each router along the path. Under the HS approach, this state is created and deleted in a fully deterministic manner through cooperation among the routers. Once a host requests a session, the "network" takes responsibility for creating and later destroying the necessary state. ST-II is an example of the HS approach [ST2-90].

Since management of HS session state is completely deterministic, the HS setup protocol must be reliable, with acknowledgments and retransmissions 📬 In order to clean up state deterministically after a failure, there must be some mechanism to detect failures, i.e., an "up/down" protocol 🚨 The router upstream (towards the source) from a failure takes responsibility for rebuilding the necessary state on the router(s) along an alternate route 🛤️

RSVP takes the SS approach, which treats reservation state as cached information that gets installed and periodically refreshed by the end hosts. Unused state gets timed out by the routers. If the route changes, the refresh messages automatically install the necessary state along the new route 🪄 The SS approach was chosen to get the simplicity and robustness that connectionless protocols like IP have shown [Clark88] 💖

5.2 Routing and Reservations 🗺️

There's a fundamental interaction between resource reservation setup and routing, since reservation requires installing flow state along the route of data packets 👀 If and when a route changes, there must be some mechanism to set up a reservation along the new route.

Some have suggested that reservation setup necessarily requires route setup, i.e., imposing a virtual-circuit internet layer. But our goal is to simply extend the Internet architecture, not replace it 🫶 The fundamental connectionless internet layer [Clark88] has been super successful, and we want to keep it as an architectural foundation. We propose instead to modify the pure datagram forwarding mechanism of the present Internet somewhat to accommodate "IS" 🔧

There are four routing issues faced by a reservation setup protocol such as RSVP 📋

Find a route that supports resource reservation. This is simply "type-of-service" routing, a facility that is already available in some modern routing protocols.
Find a route that has sufficient unreserved capacity for a new flow. Early experiments on the ARPANET showed that it is difficult to do load-dependent dynamic routing on a packet-by-packet basis without instability problems. However, instability should not be a problem if load-dependent routing is performed only at reservation setup time.

Two different approaches might be taken to finding a route with enough capacity. One could modify the routing protocol(s) and interface them to the traffic control mechanism, so the route computation can consider the average recent load. Alternatively, the routing protocol could be (re-)designed to provide multiple alternative routes, and reservation setup could be attempted along each in turn.

Adapt to a route failure When some node or link fails, adaptive routing finds an alternate path. The periodic refresh messages of RSVP will automatically request a reservation along the new path. Of course, this reservation may fail because there is insufficient available capacity on the new path. This is a problem of provisioning and network engineering, which cannot be solved by the routing or setup protocols.

There is a problem of timeliness in establishing reservation state on the new path. The end-to-end robustness mechanism of refreshes is limited in frequency by overhead, which may cause a gap in realtime service when an old route breaks and a new one is chosen. It should be possible to engineer RSVP to supplement the global refresh mechanism with a local repair mechanism, using hints about route changes from the routing mechanism.

Adapt to a route change (without failure) Route changes may occur even without failure in the affected path. Although RSVP could use the same repair techniques as those described in (3), this case raises a problem with the robustness of the QoS guarantees. If admission control fails on the new route, the user will see service degradation unnecessarily and capriciously, since the original route is still functional.

To avoid this problem, a mechanism called "route pinning" has been suggested. This would modify the routing protocol implementation and the interface to the classifier, so that routes associated with resource reservations would be "pinned". The routing protocol would not change a pinned route if it was still viable.

It may eventually be possible to fold together the routing and reservation setup problems, but we do not yet understand enough to do that. Furthermore, the reservation protocol needs to coexist with a number of different routing protocols in use in the Internet. Therefore, RSVP is currently designed to work with any current-generation routing protocol without modification. This is a short-term compromise, which may result in an occasional failure to create the best, or even any, real-time session, or an occasional service degradation due to a route change. We expect that future generations of routing protocols will remove this compromise by including hooks and mechanisms that, in conjunction with RSVP, will solve the problems (1) through (4) just listed. They will support route pinning, notification of RSVP to trigger local repair, and selection of routes with "IS" support and adequate capacity 🌟

The last routing-related issue is provided by mobile hosts 📱 Our conjecture is that mobility is not essentially different from other route changes, so the mechanism suggested in (3) and (4) will suffice. More study and experimentation is needed to prove or disprove this conjecture 🧪

6. Acknowledgments 🫶

Many Internet researchers have contributed to the work described in this memo. We want to especially acknowledge, Steve Casner, Steve Deering, Deborah Estrin, Sally Floyd, Shai Herzog, Van Jacobson, Sugih Jamin, Craig Partridge, John Wroclawski, and Lixia Zhang. This approach to Internet integrated services was initially discussed and organized in the End-to-End Research Group of the Internet Research Task Force, and we are so grateful to everyone in that group for their interesting (and sometimes heated) discussions 🔥

References 📚

[CerfKahn74] Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Trans on Comm., Vol. Com-22, No. 5, May 1974.

[Clark88] Clark, D., "The Design Philosophy of the DARPA Internet Protocols", ACM SIGCOMM '88, August 1988.

[CSZ92] Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanisms", Proc. SIGCOMM '92, Baltimore, MD, August 1992.

[DKS89] Demers, A., Keshav, S., and S. Shenker. "Analysis and Simulation of a Fair Queueing Algorithm", Journal of Internetworking: Research and Experience, 1, pp. 3-26, 1990. Also in Proc. ACM SIGCOMM '89, pp 3-12.

[SCZ93a] Shenker, S., Clark, D., and L. Zhang, "A Scheduling Service Model and a Scheduling Architecture for an Integrated Services Packet Network", submitted to ACM/IEEE Trans. on Networking.

[SCZ93b] Shenker, S., Clark, D., and L. Zhang, "A Service Model for the Integrated Services Internet", Work in Progress, October 1993.

[Floyd92] Floyd, S., "Issues in Flexible Resource Management for Datagram Networks", Proceedings of the 3rd Workshop on Very High Speed Networks, March 1992.

[Jacobson91] Jacobson, V., "Private Communication", 1991.

[JCSZ92] Jamin, S., Shenker, S., Zhang, L., and D. Clark, "An Admission Control Algorithm for Predictive Real-Time Service", Extended abstract, in Proc. Third International Workshop on Network and Operating System Support for Digital Audio and Video, San Diego, CA, Nov. 1992, pp. 73-91.

[Parekh92] Parekh, A., "A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks", Technical Report LIDS-TR-2089, Laboratory for Information and Decision Systems, Massachusetts Institute of Technology, 1992.

[Partridge92] Partridge, C., "A Proposed Flow Specification", RFC 1363, BBN, July 1992.

[RSVP93a] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. Zappala, "RSVP: A New Resource ReSerVation Protocol", Accepted for publication in IEEE Network, 1993.

[RSVP93b] Zhang, L., Braden, R., Estrin, D., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", Work in Progress, 1993.

[ST2-90] Topolcic, C., "Experimental Internet Stream Protocol: Version 2 (ST-II)", RFC 1190, BBN, October 1990.

[Tenet90] Ferrari, D., and D. Verma, "A Scheme for Real-Time Channel Establishment in Wide-Area Networks", IEEE JSAC, Vol. 8, No. 3, pp 368-379, April 1990.

Security Considerations 🔥

Okay, this part is serious bestie 💀. As noted in Section 2.1, being able to reserve resources means we need authentication, both for the users asking for resource guarantees and for the packets that claim the right to use those guarantees 🔐. These authentication issues are not otherwise addressed in this memo, so they're left for further study 🧐.

Authors' Addresses 🎀

Bob Braden
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292

Phone: (310) 822-1511
EMail: Braden@ISI.EDU


David Clark
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139-1986

Phone: (617) 253-6003
EMail: ddc@LCS.MIT.EDU


Scott Shenker
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304

Phone: (415) 812-4840
EMail: Shenker@PARC.XEROX.COM

That's the whole RFC, bestie 🌈✨ we did it 😭🫶

📦 where this page comes from

ietf: rfc1633 1994-06
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms