RFC 1363

A Proposed Flow Specification 🦋✨

Okay bestie, let's do the paperwork first 📋💅 so you know exactly what we're looking at:

• Network Working Group, Request for Comments: 1363 🎀
• Author: C. Partridge, BBN 💖
• Date: September 1992 🍓
• Status: this memo provides information for the Internet community, and it does not specify an Internet standard 📚
• Obsoletes and updates: this header doesn't list anything it obsoletes or updates 🙈

---

Status of this Memo 📚

This memo is here to give information to the Internet community 🌸 It does not specify an Internet standard. Distribution of this memo is unlimited, so share away 🌈

Abstract 💌

Okay, so a flow spec (or "flow spec" for short 💅) is a data structure that internetwork hosts use to request special services from the internetwork, often guarantees about how the internetwork will handle some of the hosts' traffic 🔥. In the future, hosts are expected to have to request these services on behalf of distributed applications, like multimedia conferencing 📹.

The flow spec defined in this memo is meant for information and possible experimentation, i.e., experimental use by consenting routers and applications only 🧪. (Consent is everything, babes 🫶.) This RFC is a product of the Internet Research Task Force (IRTF) 🔬.

Introduction 🌷

The Internet research community is currently studying how to support a new suite of distributed applications over internetworks 🕸️. These include multimedia conferencing, data fusion, visualization, and virtual reality 🥽. What they have in common is that they need the distributed system (the collection of hosts that support the applications, plus the internetwork they're attached to) to be able to provide guarantees about the quality of communication between applications 🎯. For example, a video conference may need a certain minimum bandwidth so that the video images get delivered in a timely way to all recipients 📞.

One way for the distributed system to provide guarantees is for hosts to negotiate with the internetwork for the rights to use a certain part of its resources 🤝. (An alternative is for the internetwork to infer the hosts' needs from information embedded in the data traffic each host injects into the network 🕵️. Right now, it's not clear how to make that scheme work except for a rather limited set of traffic classes 🤷‍♀️.)

There are lots of ways to run a negotiation 🧩. It can be done in-band or out-of-band. It can be done way in advance of sending data (possibly days in advance), as the first part of a connection setup, or concurrently with sending. Like, a host starts sending data and starts a negotiation to try to make sure it'll be allowed to keep going 😳. As far as is possible, this memo stays neutral 🤍 about which variety of negotiation is used.

The purpose of this memo is to define a data structure, called a flow specification or flow spec, that can be used as part of the negotiation to describe the type of service the hosts need from the internetwork 📝. This memo defines the format of the fields of the data structure and how they're interpreted 🧾. It also briefly describes what purpose the different fields fill, and discusses why this set of fields is thought to be both necessary and sufficient 🧠.

It's important to note that the goal of this flow spec is to be able to describe any flow requirement, both for guaranteed flows and for applications that simply want to give hints to the internetwork about their requirements 💡. That's a whole vibe 👑.

Format of the Flow Spec 📐

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Version          |    Maximum Transmission Unit  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Token Bucket Rate        |        Token Bucket Size      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Maximum Transmission Rate    |     Minimum Delay Noticed     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Maximum Delay Variation   |        Loss Sensitivity       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Burst Loss Sensitivity    |          Loss Interval        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Quality of Guarantee       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Discussion of the Flow Spec 🗣️

The flow spec indicates service requirements for a single direction 👉. Multidirectional flows will need to request services in both directions, using two flow specs 🔁.

To characterize a unidirectional flow, the flow spec needs to do four things, bestie 4️⃣.

First, it needs to characterize how the flow's traffic will be injected into the internetwork 💉. If the internetwork doesn't know what to expect (is it a gigabit-per-second flow or a three kilobit-per-second flow?!), then it's hard for the internetwork to make guarantees 🥴. (Note the word "difficult" rather than "impossible" 👀. It may be possible to statistically manage traffic, or to over-engineer the network so well that it can accept almost all flows without setup. But this problem looks way harder than asking the sender to approximate its behavior so the network can plan 🗓️.) In this flow spec, injected traffic is characterized as having a sustainable rate (the token bucket rate), a peak rate (the maximum transmission rate), and an approximate burst size (the token bucket size) 🪣. A more precise definition of each of these fields is given below 🔍. The characterization is based, in part, on the work done in [1] 📚.

Second, the flow spec needs to characterize sensitivity to delay ⏱️. Some applications are more sensitive than others 🫣. At the same time, the internetwork will likely have a choice of routes with various delays available from the source to the destination 🛣️. For example, both routes using satellites (which have very long delays) and routes using terrestrial lines (which will have shorter delays) may be available 🛰️. So the sending host needs to indicate the flow's sensitivity to delay. However, this field is only advisory 📢. It only tells the network when to stop trying to reduce the delay. It does not specify a maximum acceptable delay 🙅‍♀️.

There are two problems with letting applications specify the maximum acceptable delay 🙃.

First, observe that an application would probably be happy with a maximum delay of 100 ms between the US and Japan, but very unhappy with a delay of 100 ms within the same city 🌏🏙️. This observation suggests that the maximum delay is actually variable, and is a function of the delay that is considered achievable. But the achievable delay is largely determined by the geographic distance between the two peers, and this sort of geographical information is usually not available from a network 🗺️. Worse yet, the advent of mobile hosts makes such information increasingly hard to provide 📱. So there is reason to believe that applications may have difficulty choosing a rational maximum delay 🤯.

Second, maximum delays are an attempt to quantify what performance is acceptable to users, and an application usually does not know what performance will be acceptable to its user 🤷‍♀️. For example, a common justification for specifying a maximum acceptable delay is that human users find it difficult to talk to each other over a link with more than about 100 ms of delay 📞. Certainly such delays can make the conversation less pleasant, but it is still possible to converse when delays are several seconds long. And given a choice between no connection and a long delay, many users will pick the delay 🫠. (The phone call may involve an important matter that must be resolved 💼.)

As part of specifying a flow's delay sensitivity, the flow spec must also characterize how sensitive the flow is to the distortion of its data stream 🌀.

Packets injected into a network according to some pattern will not normally come out of the network still conforming to that pattern 🌪️. Instead, the pattern will have been distorted by queueing effects in the network. Since there is reason to believe that it may make network design easier to continue to allow networks to slightly distort traffic patterns, it is expected that applications which are sensitive to distortion will require their hosts to use some amount of buffering to reshape the flow back into its original form 🧱. It seems reasonable to assume that buffer space is not infinite, and that a receiving system will wish to limit the amount of buffering that a single flow can use 🚧.

The amount of buffer space required for removing distortion at the receiving system is determined by the variation in end-to-end transmission delays for data sent over the flow 📏. If the transmission delay is a mean delay, D, plus or minus a variance, V, the receiving system needs buffer space equivalent to 2 * V * the transmission rate 🧮. To see why this is so, consider two packets, A and B, sent T time units apart, which must be delivered to the receiving application T time units apart ⏳. In the worst case, A arrives after a delay of D-V time units (the minimum delay), and B arrives after a delay of D+V time units (the maximum delay) 🐢🐇. The receiver cannot deliver B until it arrives, which is T + 2 * V time units after A. To ensure that A is delivered T time units before B, A must be buffered for 2 * V time units 🫙. The delay variance field is the value of 2 * V, and it allows the receiver to indicate how much buffering it is willing to provide 💕.

A third function of the flow spec is to signal sensitivity to loss of data 🚨. Some applications are more sensitive to the loss of their data than other applications 💔. Some real-time applications are both sensitive to loss and unable to wait for retransmissions of data ⏰. For these particularly sensitive applications, hosts may implement forward error correction on a flow to try to absolutely minimize loss 🛡️. The loss fields allow hosts to request loss properties appropriate for the application's requirements 🎯.

Finally, it is expected that the internetwork may be able to provide a range of service guarantees 🎁. At the best, the internetwork may be asked to guarantee (with tight probability bounds) the quality of service it will provide 👑. Or the internetwork may simply be asked to ensure that packets sent over the flow take a terrestrial path 🌍. The quality of guarantee field indicates what type of service guarantee the application desires 💯.

Definition of Individual Fields 🔬

General Format of Fields 🧩

With a few exceptions, fields of the flow spec are expressed using a common 16-bit format ⚡. This format has two forms. The first form is shown below 👇.

            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |0|  Exponent   |     Value     |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In this format, the first bit is 0, followed by 7 bits of an exponent (E), and an 8-bit value (V) 🔢. This format encodes a number of the form V * (2**E) 🧪. This representation was chosen to allow easy representation of a wide range of values, while avoiding over-precise representations 💎.

okay so sometimes a system doesn't want to ask for a precise number, it just wants to say "hey, I'm sensitive to this" 🫶 like a virtual terminal app (Telnet is the classic example) that totally cares about delay but isn't even worth asking the network for some exact delay value. So for these cases, instead of a number, the field in the flow spec looks like this 🎀

               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |1|   Well-defined Constant     |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first bit is one, and it's followed by a 15-bit constant ✨ The values of the constants for each field are defined below. If you need more values, they can be requested from the Internet Assigned Numbers Authority (IANA) 🌸

Version Field 🦋

This is a 16-bit integer in Internet byte order, and it's the version number of the flow specification. The version defined in this document is 1. IANA is responsible for assigning future version numbers for any proposed revisions of this flow specification 💅

This field does not use the general field format.

Maximum Transmission Unit (MTU) 🍓

This is a 16-bit integer in Internet byte order, and it's the maximum number of bytes in the largest possible packet to be transmitted over this flow 📦

This field does not use the general field format.

The MTU has two jobs, bestie 👑

It's a convenient unit for expressing loss properties. Using the default MTU of the internetwork is inappropriate, because the internetwork can have a very large MTU (like the 64Kbytes of IP). But applications and hosts can be sensitive to losses of way less than an MTU's worth of data. A voice app, for example, would be sensitive to losing several consecutive small packets 🎙️

The MTU also limits how long a flow can transmit, uninterrupted, on a shared media ⏱️

And the loss rates of links that suffer bit errors can vary dramatically based on the MTU size 📉

Token Bucket Rate 🪣

The token bucket rate is one of three fields that define how traffic gets injected into the internetwork by the sending application. (The other two are the token bucket size and the maximum transmission rate.) 💖

The token rate is the speed at which tokens (credits) get dropped into an imaginary token bucket. Every flow gets its own bucket 🪣 To send a packet over the flow, a host MUST remove a number of credits equal to the size of the packet from the bucket. If there aren't enough credits, the host MUST wait until enough credits build up in the bucket 😭

Okay, this part is lowkey important: the fact that the rate is written as a token bucket rate does NOT mean hosts MUST implement token buckets. Any traffic management scheme that gives equivalent behavior is permitted ✨

The field is in the general field format and counts the number of byte credits (basically, the right to send a byte) per second that get deposited into the bucket. The value MUST be a number, not a well-known constant 🔢

Zero is slightly special 🙈 It means the application isn't asking for any bandwidth guarantees. If this field is zero, then the Token Bucket Size MUST also be zero, and the type of guarantee requested MAY be no higher than predicted service.

Token Bucket Size 🧺

The token bucket size controls the maximum amount of data the flow can send at the peak rate. More formally: if the token bucket size is B and the token bucket rate is R, then over any arbitrarily chosen interval T in the life of the flow, the amount of data the flow sends cannot have exceeded B + (R * T) bytes 🧮

The bucket fills at the token bucket rate. The bucket size limits how many credits the flow may store, and when the bucket is full, new credits get thrown away 🗑️

The field is in the general field format and tells you the size of the bucket in bytes. The value MUST be a number.

Note that the bucket size MUST be greater than or equal to the MTU size 💅

Zero is a legal value for this field, and it means no credits get saved 🫠

Maximum Transmission Rate 🚀

The maximum transmission rate limits how fast packets can be sent back to back from the host. Here's the problem: if the token bucket is full, the flow can send a whole series of back-to-back packets equal to the size of the token bucket. If the token bucket is big, that back-to-back run can go on long enough to seriously block multiplexing 😤

So to limit this, the maximum transmission rate bounds how fast successive packets can be put on the network 🚧

You can think of this control as a form of leaky bucket 🪣💧 When a packet is sent, a number of credits equal to the packet's size gets placed into an empty bucket, which drains credits at the maximum transmission rate. No more packets MAY be sent until the bucket has emptied again.

The maximum transmission rate is the rate at which the bucket gets emptied. The field is in the general field format and indicates the size of the bucket in bytes. The value MUST be a number and MUST be greater than or equal to the token bucket rate 🎀

Also, the MTU size can team up with the maximum transmission rate to bound how long one packet can block other transmissions. The MTU caps the maximum time an individual packet may take, and the Maximum Transmission Rate limits how often packets may be placed on the network 🧚

Minimum Delay Noticed 🌈

This field tells the internetwork that the host and application are effectively insensitive to improvements in end-to-end delay below this value. The network is encouraged to push the delay down to this value, but it doesn't need to try to improve the delay any further 🙌

The field is in the general field format.

If it's expressed as a number, it's the number of microseconds of delay below which the host and application don't care about improvements. Human users only care about delays in the millisecond range, but some applications are computer to computer, and computers now have clock times measured in a handful of nanoseconds. For those computers, microseconds are a real, appreciable amount of time, so this field measures in microseconds even though that might seem tiny 🤓

If it's expressed as a well-known constant (first bit set), two field values are accepted:

   0 - the application is not sensitive to delay

   1 - the application is moderately delay sensitive
       e.g., avoid satellite links where possible).

Maximum Delay Variation 🌀

If a receiving application needs data delivered in the same pattern the data was transmitted, the receiving host may need to briefly buffer data as it arrives so the receiver can restore the old transmission pattern 🧠 (An easy example: an app sends voice samples that are generated and played at regular intervals. Queueing effects in the network can distort those regular intervals, so the receiver may have to restore the regular spacing 🎶)

The amount of buffer space the receiving host is willing to provide determines how much variation in delay is permitted for individual packets within a given flow. The maximum delay variation field lets you tell the network how much variation is permitted. (Implementors SHOULD note that the restrictions on the maximum transmission rate may cause data traffic patterns to be distorted before they're placed on the network, and that this distortion MUST be accounted for when determining the receiver buffer size 👀)

The field is in the general field format and MUST be a number. It's the difference, in microseconds, between the maximum and minimum possible delay that a packet will experience. (There's some debate about whether microsecond units are too big. At a terabit per second, one microsecond is a megabit. Presumably, if a host is willing to receive data at terabit speeds, it's also willing to provide megabits of buffer space 🤯)

A value of 0, meaning the receiving host won't buffer out delays, is acceptable, but the receiving host MUST still have enough buffer space to receive a maximum transmission unit sized packet from the sending host. Note that a value of 0 is expected to make it unlikely that a flow can be established 😬

Loss Sensitivity 🫧

This field shows how sensitive the flow's traffic is to losses. Loss sensitivity can be expressed in one of two ways: either as a number of losses of MTU-sized packets in an interval, or as a value that just indicates a level of sensitivity 💜

The field is in the general field format.

If the value is a number, then it's the number of MTU-sized packets that MAY be lost out of the number of MTU-sized packets listed in the Loss Interval field 📊

If the value is a well-known constant, then one of two values is permitted:

   0 - the flow is insensitive to loss

   1 - the flow is sensitive to loss (where possible
       choose the path with the lowest loss rate).

Burst Loss Sensitivity 💥

This field states how sensitive the flow is to losses of consecutive packets. It enumerates the maximum number of consecutive MTU-sized packets that MAY be lost 🎯

The field is in the general field format.

If the value is a number, then it's the number of consecutive MTU-sized packets that MAY be lost.

If the value is a well-known constant, then the value 0 means the flow is insensitive to burst loss.

Note that it's totally fine to set the loss sensitivity field to just indicate sensitivity to loss, and then set a numerical limit on how many consecutive packets can be lost 🫶

Loss Interval ⏳

This field sets the period over which the maximum number of losses per interval gets measured. In other words, for any arbitrarily chosen interval of this length, the number of losses may not exceed the number in the Loss Sensitivity field 🧐

The field is in the general field format.

If the Loss Sensitivity field is a number, then this field MUST also be a number, and MUST indicate the number of MTU-sized packets that make up a loss interval 🔢

If the Loss Sensitivity field is not a number (it's a well-known constant instead), then this field MUST use the well-known constant of 0 (first bit set, all other bits 0). That indicates that no loss interval is defined 🙃

Quality of Guarantee 🏆

It's expected that the internetwork will likely have to offer more than one type of guarantee ✨

There are two unrelated issues related to guarantees 👀

First, the internetwork may not be able to make a firm guarantee at all 😭. Picture a path where the last hop is an Ethernet. Some of the IETF conferencing experiments showed an Ethernet can often give acceptable performance, but the internetwork can't promise it won't saturate at some point during a flow's lifetime. So we need a way to tell apart flows that can't tolerate even a small chance of failure (those must be guaranteed at every hop on the path 💅) and flows that are fine with little islands of uncertainty 🦋.

Second, there's some early work (see [2]) suggesting that some apps can adapt to modest variations in internetwork performance, and that network designers can use that flexibility to get better network utilization ✨. In this model, the internetwork is allowed to drift slightly from the promised flow parameters during busy periods. This class of service is called predicted service, to tell it apart from guaranteed service 🌸.

The difference between predicted service and a guarantee that can't be perfectly kept (like the Ethernet example) is that the imperfect guarantee makes no statistical promises about how it might misbehave 💀. In the worst case, the imperfect guarantee just won't work at all, whereas predicted service gives slightly degraded service 😌. Also, predicted service assumes the routers and links in a path all cooperate (to some degree), while an imperfect guarantee says some routers or links won't cooperate at all 🙈.

The field is a 16-bit field in Internet byte order. There are six legal values:

   0 - no guarantee is required (the host is simply expressing
       desired performance for the flow)

   100 (hex) - an imperfect guarantee is requested.

   200 (hex) - predicted service is requested and if unavailable,
               then no flow should be established.

   201 (hex) - predicted service is requested but an imperfect
               guarantee is acceptable.

   300 (hex) - guaranteed service is requested and if a firm
               guarantee cannot be given, then no flow should be
               established.

   301 (hex) - guaranteed service is request and but an imperfect
               guarantee is acceptable.

It is expected that asking for predicted service, or permitting an imperfect guarantee, will substantially increase the chance that a flow request gets accepted 🎀.

---

Possible Limitations in the Proposed Flow Spec

There are at least three places where the flow spec is arguably imperfect, based on what we currently know about flow reservation 🧐. And since this is a first attempt at a flow spec, readers should expect changes as we learn more 📚.

First, the loss model isn't perfect. Just saying an app is sensitive to loss and to burst loss is a pretty crude way to show sensitivity 🙃. Explicitly listing loss requirements within a cycle is also imperfect. The key problem with explicit values is that not all packets sent over a flow will be a full MTU in size. Put another way, the current flow spec expects an MTU-sized packet to be the unit of error recovery. If flows send packets in a range of sizes, the loss bounds may not be very useful. Letting a flow request a set of loss models (one per packet size) is so painful to think about that I've limited the flow to one loss profile 😩. Further study of loss models is clearly needed 🔬.

Second, the minimum delay sensitivity field only lets a flow say there's one point on a performance sensitivity curve below which it's no longer interested in better performance. A single point might not be enough to fully express a flow's sensitivity 🤔. For example, take a flow supporting part of a two-way voice conversation. Humans will notice delay improvements down to a few 10s of milliseconds. But the key point of sensitivity is the delay where normal conversation starts getting awkward (about 100 milliseconds) 😬. With only one sensitivity point, the flow designer has to either ask for the best possible delay (e.g., a few 10's of ms) to squeeze maximum performance out of the network, or state a sensitivity of about 95 ms and accept that the internetwork won't try to improve delay below that value, even if it could (and even though the user would notice the improvement) 💔. My expectation is that a simple point is easier to deal with than trying to enumerate two (or three or four) points on the sensitivity curve 💅.

Third, the models for service guarantees are still evolving, and it's by no means clear that the service choices provided are the correct set 🌈.

How an Internetwork is Expected to Handle a Flow Spec

There are at least two parts to how an internetwork is expected to handle a flow spec 🗺️. The first part is how the flow spec gets interpreted so the internetwork can find a route that matches the flow's requirements. The second part is how the network replies to the host's request.

The precise mechanism for setting up a flow, given a flow spec, is a big topic and out of scope for this memo 🙅‍♀️. The point of the next few paragraphs is just to sketch an argument that this flow spec is sufficient for the requirements of the setup mechanisms known to the author.

The key problem in setting up a flow is figuring out whether one or more routes from the source to the destination(s) might be able to support the requested quality of service 🛣️. Once you have a route (or a set of candidate routes), you can take whatever actions are appropriate to confirm the route is actually viable and to make the flow's data follow that route ✨.

There are a number of ways to find a route. You could build one on the fly by establishing the flow hop-by-hop (as ST-II does), or you could consult a route server that provides a set of candidate source routes derived from a routing database 🗂️. Whatever system is used, though, some basic information about the flow needs to be given to the routing system. That information is:

• How much bandwidth the flow may require. There's no point routing a flow that expects to send at over 10 megabits per second via a T1 (1.5 megabit per second) link 📉.
• How delay sensitive the application is. You don't want to route a delay-sensitive application over a satellite link, unless the satellite link is the only possible route from here to there 🛰️.
• How much error can be tolerated. Can we send this flow over our microwave channel on a rainy day, or is a more reliable link required? ⛈️
• How firm the guarantees need to be. Can we put an Ethernet in as one of the hops? 🤷
• How much delay variation is tolerated. Again, can an Ethernet be included in the path? Does the routing system need to worry if adding this flow will cause a few routers to run at close to capacity? (A side note: we assume the routers are running priority queueing systems, so running a router close to capacity doesn't mean all flows get long and variable delays. Rather, running close to capacity means high priority flows will be unaffected, and low priority flows will get hit with a lot of delay and variation 💁‍♀️.)

The flow spec provides all of this information, so it seems plausible to assume it provides enough information to make routing decisions at setup time 💖.

The flow spec was designed with the expectation that the network would give a yes or no reply to a request for a guaranteed flow 🙆.

Some researchers have suggested that the negotiation to set up a flow might be an extended one, where the requesting host first asks for the best possible flow it could desire, then haggles with the network until they agree on a flow with properties the network can actually provide and the application still finds useful 🤝. This idea bugs me for at least two reasons. First, it means setting up a flow becomes a potentially long process. Second, the general problem of finding all possible routes with a given set of properties is a version of the traveling salesman problem, and I don't want to embed traveling salesman algorithms into a network's routing system 🚫🧳.

The model used in designing this flow spec was that a system asks for the minimum level of service it deems acceptable, and the network tries to find a route that meets that level of service. If the network can't achieve the desired level of service, it refuses the flow. Otherwise, it accepts the flow 👍.

The Flow Spec as a Return Value

This memo doesn't specify the data structures the network uses to accept or reject a flow 🙈. However, the flow spec has been designed so it can be used to return the type of service being guaranteed 🎁.

If the request is accepted, the minimum delay field could be set to the guaranteed or predicted delay, and the quality of guarantee field could be set to no guarantee (0), imperfect guarantee (100 hex), predicted service (200 hex), or guaranteed service (300 hex) ✅.

If the request is rejected, the flow spec could be modified to indicate what type of flow the network believes it could accept (e.g., the traffic shape or delay characteristics could be adjusted, or the type of guarantee lowered). Note that this returned flow spec would likely be a hint, not a promised offer of service 🫠.

Why Type of Service is not Good Enough

Okay so the flow spec in this memo is basically a set of parameters that describe what a flow looks like and what it needs 💅 Sometimes people bring up Type of Service (TOS) instead, which is what IP already uses 🎀

A TOS value is an integer (or bit pattern) whose values have been predefined to stand for requested qualities of service. So a TOS of 47 might ask for service for a flow using up to 1 gigabit per second of bandwidth with a minimum delay sensitivity of 100 milliseconds 🦋

TOS schemes work great if the qualities of service people can ask for are both enumerable and reasonably small. Unfortunately, that doesn't seem to be true for future internetworks 😭 The range of possible bandwidth requests alone is huge. Add several gradations of delay requirements, plus widely different sensitivities to errors, and the set of TOS values you'd need gets extremely large. (At least one person has suggested to the author that perhaps a TOS field combined with a bandwidth parameter might be appropriate. In other words, a two parameter model. That's a tempting idea but my gut feeling is that it is not quite sufficient so I'm proposing a more complete parametric model.) 🧚

Another reason to prefer parametric service is optimization. A key issue in flow setup is trying to design the routing system so it manages flows as well as possible 🔥 You can optimize on a number of criteria, and a really good example of an optimization problem is this question, expressed by Isidro Castineyra of BBN:

"Given a request to establish a flow, how can the internetwork accept that request in such a way as to maximize the chance that the internetwork will also be able to accept the next flow request?"

The optimization goal here is call-completion, which means maximizing the chance that requests to establish flows will succeed. You could also try to maximize revenue instead (if you're charging for flows) 👑

The internetwork is presumably in a better position to optimize if it has more information about the flow's expected behavior. For example, if a TOS system only says that a flow is delay sensitive, the routing system has to seek out the most direct route for the flow. But if the routing system is told that the flow is sensitive only to delays over 100 milliseconds, there may be a bunch of routes other than the most direct one that can satisfy that delay. That leaves the most direct route free for a later flow that needs a far lower delay 🌈

In fairness, a danger of a parametric model is that it is very easy to end up with too many parameters. The yearn to optimize can be overdone 🙈 The goal of this flow spec is to list just enough parameters that essential needs can be expressed, and the internetwork has some information it can use to manage the flows. Features that would simply be nice or useful to have (but not essential) are left out to keep the parameter space small ✨

An Implication of the Flow Spec

It's important to notice that some fields in the flow spec are based on information from the sender (like rate information), and some are based on information from the receiver (like delay variation). There are also fields that the sender and receiver may need to negotiate in advance 🫶 For example, the acceptable loss rate may depend on whether the sender and receiver both support the same type of forward error correction. The delay sensitivity for a voice connection may depend, in part, on whether both sender and receiver support echo cancelling.

So the implication is that the internetwork must let the sender and receiver communicate before a flow is set up, because a flow spec can only be defined once both sender and receiver have had their say. In other words, a reserved flow should not be the only form of communication. There must be some mechanism to perform a short exchange of messages in preparation for setting up a flow 💅

(Another aside: it has been suggested that perhaps the solution to this problem is to have the sender establish a flow with an incomplete flow spec, and when the receiver gets the flow spec, have the receiver send the completed flow spec back along the flow, so the internetwork can "revise" the flow spec according to the receiver's desires. I have two problems with this approach. First, it is entirely possible that the receiver's information may lead the internetwork to conclude that the flow established by the sender is no good. For example, the receiver may indicate it has a smaller tolerance for delay variation than expected and force the flow to be rerouted over a completely different path. Second, if we try to avoid having the receiver's information cause the flow to fail, then we have to over-allocate the flow's resources during the preliminary setup. But over allocating the resources requested may lead us to choose better quality paths than we need for this flow. In other words, our attempts to optimize use of the network will fail.) 😭

Advance Reservations and Flow Duration

The main purpose of a flow specification is to give the internetwork information so it can properly manage the proposed flow's traffic alongside everything else on the network 🎀 One question is whether the flow should tell the network when it's expected to start and how long it's expected to last.

Announcing when a flow will start is mostly of interest for advance reservations. (If the flow isn't being reserved substantially in advance, presenting the flow spec to the internetwork can be taken as an implicit request for a flow, now.) It's the author's view that advance reservation is a separate problem from describing the properties of a flow 🦋 Advance reservations will need some mechanism to keep information in the network about flows that aren't active right now but are expected to start at some point in the future. The author anticipates this will need some sort of distributed database, so that information about advance reservations isn't accidentally lost if parts of the internetwork crash. In other words, advance reservations come with a lot of extra baggage that's probably better kept out of the average flow spec 🧳

Deciding whether a flow spec should include how long the flow is expected to run is a harder call 🤔 Clearly, if the internetwork is going to support advance reservations, its elements will need to predict their traffic load so that advance reservations aren't compromised by new flow requests. However, there's a school of thought that says estimating future load from the current behavior of existing flows is more accurate than anything the flows declared in their flow specs. For this reason, the author has left a duration field out of the flow spec 🌸

Examples

To show how the flow spec values might be used, this section presents three example flow specs ✨

Telnet

For the first example, let's use the flow spec to request service for an existing application: Telnet 🖥️ Telnet is a virtual terminal protocol, and you can think of it as stringing a virtual wire across the network between the user's terminal and a remote host.

Telnet has been a super successful application without needing to reserve bandwidth, because the amount of data sent over any Telnet connection tends to be quite small 💖 However, Telnet users are often really sensitive to delay, since delay can affect how long it takes to echo characters. This suggests a Telnet connection might benefit from asking the internetwork to avoid long delay paths. It could do so using the following flow spec (for both directions):

Version=1
MTU=80 [40 bytes of overhead + 40 bytes user data]
Token Bucket Rate=0/0/0 [don't want a guarantee]
Token Bucket Size=0/0/0
Maximum Transmission Rate=0/0/0
Maximum Delay Noticed=1/1 [constant = delay sensitive]
Maximum Delay Variation=0/0/0 [not a concern]
Loss Sensitivity=1/0 [don't worry about loss]
Burst Loss Sensitivity=1/0
Loss Interval=1/0
Quality of Guarantee=1/0 [just asking]

It's worth noting that Telnet's flow spec is likely to be the same for all instantiations of a Telnet connection 🧚 As a result, there may be some optimizations possible (such as just tagging Telnet packets as being subject to the well-known Telnet flow spec).

A Voice Flow

Now let's think about transmitting voice over the Internet 🎤 Currently, good quality voice can be delivered at rates of 32Kbit/s or 16Kbit/s. Assuming the rate is 32Kbit/s and voice samples are 16 bit samples packaged into UDP datagrams (for a data rate of about 60 Kbyte/s), a flow spec might be:

Version=1
MTU=30 [2 byte sample in UDP datagram]
Token Bucket Rate=0/10/59 [60.4 Kbytes/s]
Token Bucket Size=0/0/30 [save enough to send immediately
                          after pauses]
Maximum Transmission Rate=0/10/59 [peak same as mean]
Maximum Delay Noticed=0/10/100 [100 ms]
Maximum Delay Variation=0/10/10 [keep variation low]
Loss Sensitivity=1/1 [loss sensitive]
Burst Loss Sensitivity=0/0/5 [keep bursts small]
Loss Interval=1/0
Quality of Guarantee=1/201 [predicted service and I'll accept
                            worse]

A Variable Bit-Rate Video Flow

Variable bit-rate video transmissions change the rate at which they send data depending on how much of the video image has changed between frames 📺 In this example, we look at a one-way broadcast of a picture. If we assume 30 frames a second, that a full frame is about 1 megabit of data, and that on average about 10% of the frame changes (but in the worst case the entire frame changes), the flow spec might be:

Version=1
MTU=4096 [big so we can put lots of bits in each packet]
Token Bucket Rate=0/20/1 [8 Mbits/s]
Token Bucket Size=0/17/2 [2 Mbits/s]
Maximum Transmission Rate=0/20/30 [30 Mbits/s]
Maximum Delay Noticed=1/1 [somewhat delay sensitive]
Maximum Delay Variation=0/10/1 [no more than one second of
                                buffering]
Loss Sensitivity=0/0/1 [worst case, one loss per frame]
Burst Loss Sensitivity=0/0/1 [no burst errors please]
Loss Interval=0/0/33 [one frame in MTU sized packets]
Quality of Guarantee=1/300 [guaranteed service only]

The token bucket is sized to hold two frames of data, and the bucket rate will fill the bucket every 250 ms 🍓 The expectation is that full scene changes will be rare, and that a fast rate with a large bucket size should handle even a series of scene changes.

Disclaimer

In all cases, these examples are simply there to sketch how the flow spec is used. The author makes no claims that the actual values used are the correct ones for a particular application 🙏

Security Considerations 🔒

Okay bestie, the security section is giving plot twist 😭. Security considerations definitely exist 🚨. Like, if people get charged for guaranteed flows, then some mechanism has to exist to make sure a flow request (flow spec included) is authenticated 🫣. Craig's take is that all of this stuff belongs in the design of a negotiation protocol, and not in the design of the flow spec data structure 💅. Mood, honestly 🎀.

Acknowledgements 🫶

Craig wants to give a massive shoutout to Steve Deering, Scott Shenker, and Lixia Zhang of XEROX PARC for helping write this RFC 💖. A big chunk of this flow spec was sketched out in two long meetings with them at PARC ✨. Other people who gave super helpful advice and comments include Isidro Castineyra, Deborah Estrin, and the members of the End-to-End Research Group chaired by Bob Braden 🌸. Any ideas that turn out to be misbegotten are totally on the author 💀. This work was funded under DARPA Contract No. MDA903-91-D-0019 🦋. The views expressed in this document are not necessarily those of the Defense Advanced Research Projects Agency, so don't blame DARPA for the vibes 🙈.

References 📚

1. Parekh, A., "A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks", MIT Laboratory for Information and Decision Systems, Report No. LIDS-TH-2089.
2. Clark, D., Shenker, S., and L. Zhang, "Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanism", Proceedings of ACM SIGCOMM '92, August 1992.

Author's Address 💌

Craig Partridge 🧚 BBN 824 Kipling St Palo Alto, CA 94301

Phone: 415-325-4541

EMail: craig@aland.bbn.com 💜

---

That's the whole RFC, bestie! 🌈👑