RFC 4883

Benchmarking Terminology for Resource Reservation Capable Routers

📅 published July 2007, from ietf

RFC 4883: Benchmarking Terminology for Resource Reservation Capable Routers 🎀

Okay bestie, this one is from July 2007, and it's an Informational RFC, so it gives info to the Internet community and does not set an Internet standard 💅. The authors are G. Feher, K. Nemeth, and A. Korn from BUTE, plus I. Cselenyi from TeliaSonera. It's Request for Comments: 4883 in the Network Working Group ✨. The title block doesn't say it obsoletes or updates anything, so there's no drama there 🫶.

Status of This Memo 📌

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice ©️

Abstract 🦋

The main goal of this doc is to define terminology for benchmarking resource reservation signaling on Integrated Services (IntServ) IP routers. These terms can be used in other documents that define benchmarking methodologies for routers that support resource reservation, or reporting formats for the benchmarking measurements. It's giving building blocks for other specs 🧱

Table of Contents 🗂️

   1. Introduction ....................................................2
   2. Existing Definitions ............................................3
   3. Definition of Terms .............................................4
      3.1. Traffic Flow Types .........................................4
           3.1.1. Data Flow ...........................................4
           3.1.2. Distinguished Data Flow .............................4
           3.1.3. Best-Effort Data Flow ...............................5
      3.2. Resource Reservation Protocol Basics .......................5
           3.2.1. QoS Session .........................................5
           3.2.2. Resource Reservation Protocol .......................6
           3.2.3. Resource Reservation Capable Router .................7
           3.2.4. Reservation State ...................................7
           3.2.5. Resource Reservation Protocol Orientation ...........8
      3.3. Router Load Factors ........................................9
           3.3.1. Best-Effort Traffic Load Factor .....................9
           3.3.2. Distinguished Traffic Load Factor ..................10
           3.3.3. Session Load Factor ................................11
           3.3.4. Signaling Intensity Load Factor ....................11
           3.3.5. Signaling Burst Load Factor ........................12
      3.4. Performance Metrics .......................................13
           3.4.1. Signaling Message Handling Time ....................13
           3.4.2. Distinguished Traffic Delay ........................14
           3.4.3. Best-effort Traffic Delay ..........................15
           3.4.4. Signaling Message Deficit ..........................15
           3.4.5. Session Maintenance Capacity .......................16
      3.5. Router Load Conditions and Scalability Limit ..............17
           3.5.1. Loss-Free Condition ................................17
           3.5.2. Lossy Condition ....................................18
           3.5.3. QoS Compliant Condition ............................19
           3.5.4. Not QoS Compliant Condition ........................20
           3.5.5. Scalability Limit ..................................20
   4. Security Considerations ........................................21
   5. Acknowledgements ...............................................21
   6. References .....................................................21
      6.1. Normative References ......................................21
      6.2. Informative References ....................................21

1. Introduction 🌸

Signaling-based resource reservation using the IntServ paradigm [4] is a big part of the different Quality of Service (QoS) provisioning approaches 💖. So if network operators are planning to deploy signaling-based resource reservation, they may want to look at the scalability limits of reservation capable routers, and how signaling affects their data forwarding performance 👀.

The way to measure those scalability constraints objectively is to run tests on routers that can do IntServ-based resource reservation 🧪. This document defines terminology for a specific set of tests that vendors or network operators can run to measure and report the signaling performance of routers that support resource reservation protocols. The results give comparable data across different products, which helps with buying decisions before purchase 🛍️. The measurements also give input for dimensioning a network where resources are provisioned dynamically by signaling. And the tests can characterize how resource reservation signaling affects the forwarding performance of the routers, which is very main character energy 👑.

This benchmarking terminology is based on what the authors learned from examining and experimenting with different resource reservation protocols. The big one is the IETF standard Resource ReSerVation Protocol (RSVP) [5]. There's also Next Steps in Signaling (NSIS) [6][7][8][9], plus a bunch of experimental ones: YESSIR (Yet Another Sender Session Internet Reservation) [10], ST2+ [11], Session Description Protocol (SDP) [12], Boomerang [13], and Ticket [14] 🧚. The IETF NSIS working group also analyzed some of these protocols [15]. Right now the authors only know about resource reservation capable router products that interpret RSVP, but this document defines terms that are valid in general and aren't restricted to any of the protocols above 🌈.

To avoid any confusion, this terminology only considers signaling protocols that provide IntServ resource reservation 🙅‍♀️. For example, techniques in the DiffServ toolbox are mostly out of scope, so don't come for them here 💅.

2. Existing Definitions 📚

RFC 1242 "Benchmarking Terminology for Network Interconnection Devices" [1] and RFC 2285 "Benchmarking Terminology for LAN Switching Devices" [3] both have discussions and definitions for a bunch of terms that matter for benchmarking the signaling performance of reservation-capable routers. You should check them out before using this document 🤓.

This document also defines terminology in a way that matches the terms used by the Next Steps in Signaling working group in [6][7][8] ✨.

For clarity and continuity, this document uses the template for definitions set out in Section 2 of RFC 1242 💁‍♀️.

The definitions are indexed and grouped into sections so they're easy to find 🗃️.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2] 🔑.

3. Definition of Terms 🎀

3.1. Traffic Flow Types 🦋

This group of definitions describes the traffic flow types that resource reservation capable routers forward 🚦.

3.1.1. Data Flow

Definition: A data flow is a stream of data packets from one sender to one or more receivers, where each packet has a flow identifier that's unique to the flow 🌊.

Discussion: The flow identifier can be any subset of the packet header fields that uniquely tells the flow apart from others 🔍. For example, the 5-tuple "source address; source port; destination address; destination port; protocol number" is commonly used for this (where port numbers apply). It's also possible to use the Flow Label field of IPv6 packets 🧠. For more on flow identification, see [6] 💜.

3.1.2. Distinguished Data Flow

Definition: Distinguished data flows are flows that resource reservation capable routers intentionally treat better or worse than best-effort data flows, according to a QoS agreement defined for the distinguished flow 🏆.

Discussion: Routers classify the packets of distinguished data flows and identify the data flow each packet belongs to 🗂️.

The most common use of a distinguished data flow is to get higher-priority treatment than best-effort data flows (see the next definition) 🚀. In these cases, a distinguished data flow is sometimes called a "premium data flow" 💎. Still, in theory it's possible to require worse treatment than that of best-effort flows 🙃.

3.1.3. Best-Effort Data Flow

Definition: Best-effort data flows are flows that resource reservation capable routers don't treat in any special way, so their packets are served (forwarded) in some default way 🫧.

Discussion: "Best-effort" means the router makes its best effort to forward the data packet quickly and safely, but doesn't guarantee anything (for example, delay or loss probability) 🤷‍♀️. This is the most common type of traffic on today's Internet 🌐.

Packets in best-effort data flows don't need to be classified by the routers. That means the routers don't have to find a related reservation session to figure out what treatment the packet is entitled to 🙌.

3.2. Resource Reservation Protocol Basics 🛠️

This group of definitions applies to signaling-based resource reservation protocols implemented by IP router devices. 💜

3.2.1. QoS Session 💖

Definition: okay so a QoS session is an application layer concept that's shared between a bunch of network nodes 🧚. It's about a specific group of data flows, and the info attached to it has two jobs: identifying which flows are in the group, and spelling out the special QoS treatment they need. ✨

Discussion: A QoS session is an end-to-end thing, bestie 🫶. Whenever the end-nodes decide they want special QoS treatment for their communication, they set up a QoS session. They (or their proxies) make a QoS agreement with the network, listing their data flows and the QoS treatment those flows need. It's giving contract, honestly 💅.

A single QoS session can span multiple network domains that have different resource provisioning architectures, and that's fine. In this document though, we're only looking at the case where the session is realized over an IntServ architecture. It's assumed that sessions get set up using signaling messages from a resource reservation protocol 📨.

QoS sessions must have unique identifiers, because it has to be possible to tell which QoS session a given signaling message is about 🔥. So each signaling message should include the identifier of its corresponding session. For example, in RSVP, the "session specification" identifies the QoS session and points to the data flow, the "flowspec" describes the QoS treatment you want, and the "filter spec" picks out which packets in the data flow actually get that QoS 🎀.

QoS sessions can be unicast or multicast, depending on how many participants there are. In a multicast group you can have several traffic sources and destinations. The QoS agreement doesn't have to be identical for every branch of the multicast tree forwarding the group's data flow. Instead, a dedicated network resource in a router can be shared among many traffic sources from the same multicast group (see the multicast reservation styles in RSVP, iykyk) 🌸.

Issues: Okay this part is kind of messy 😭. Even though QoS sessions are considered unique, resource reservation capable routers might aggregate them and allocate network resources to the aggregated sessions all at once. The aggregation can be based on similar data flow attributes (like similar destination addresses), or it can combine arbitrary sessions too. Reservation aggregation really lightens the signaling workload of a resource reservation capable router, but it also means the aggregated QoS sessions need to be administered, and it might lead to violating the quality guarantees that refer to individual data flows inside an aggregation [16] 💀.

3.2.2. Resource Reservation Protocol 🦋

Definition: Resource reservation protocols define the signaling messages and the message processing rules used to control resource allocation in IntServ architectures ✨.

Discussion: The signaling messages of a resource reservation protocol are the ones carrying the info about QoS sessions 💜. That info includes a session identifier, the actual QoS parameters, and possibly flow descriptors.

The message processing rules of the signaling protocols make sure the signaling messages reach all the network nodes concerned 🫶. Some resource reservation protocols (like RSVP and NSIS QoS NSLP [8]) only care about that part. They carry the QoS-related info to all the right nodes without actually knowing what it says. This approach is lowkey genius, because you can change the way QoS parameters are described, and different kinds of provisioning can be done without changing the protocol itself 🌈.

3.2.3. Resource Reservation Capable Router 👑

Definition: A router is resource reservation capable (meaning it supports resource reservation) if it can interpret signaling messages from a resource reservation protocol. Based on those messages, it can adjust how it manages its flow classifiers and network resources so they match what the signaling messages say 🍓.

Discussion: These routers catch the signaling messages and then change their reservation states and/or reserved network resources based on what the messages contain. That's how the flows get treated the way their specified QoS requirements indicate. Main character energy 😭🔥.

3.2.4. Reservation State 🧚

Definition: A reservation state is the set of entries in a router's memory that hold all the relevant info about a given QoS session registered with that router 📚.

Discussion: States are needed because IntServ-related resource reservation protocols make routers keep track of QoS session and data-flow metadata 🎀. The reservation state includes the QoS treatment parameters, the description of how and where to forward incoming signaling messages, refresh timing info, and so on.

Routers can be sorted into two classes based on how they store reservation states 💅.

Hard-state resource reservation protocols (like ST2 [11]) require routers to store reservation states permanently. These states get set up by a setup signaling primitive and stick around until the router is explicitly told that the QoS session is canceled 🧊.

Then there are soft-state resource reservation capable routers. These have no permanent reservation states, and every state has to be regularly refreshed by refresh signaling messages 🌊. If no refresh message shows up for a certain period, the router stops maintaining that QoS session. It assumes the end-points don't want to keep the session up anymore, or that the communication lines broke somewhere along the data path. This makes soft-state routers way more robust than hard-state ones, because no failure can leave resources stuck in the routers forever 🙌. (Note that soft-state protocols can still have an explicit teardown message for quicker resource release 🌸.)

Issues: Depending on where the refresh messages start, soft-state resource reservation protocols fall into two groups 🦋. In the first group, the end-points (or their proxies) are responsible for starting the refresh messages. Those messages travel along the data flow's path and refresh the reservation states in each router the flow touches. In the second group, the routers and end-points each keep their own refresh schedule and signal those refreshes to their neighboring routers 💜.

3.2.5. Resource Reservation Protocol Orientation 🌈

Definition: The orientation of a resource reservation protocol tells you which end of the protocol communication starts the allocation of network resources 🎯. So a protocol can be sender-oriented or receiver-oriented, depending on where the data flow source (sender) and destination (receiver) sit compared to the reservation initiator.

Discussion: In sender-oriented protocols (sometimes called sender-initiated protocols), the resource reservation goes in the same direction(s) as the data flow(s) ➡️. In receiver-oriented protocols, the signaling messages that reserve resources get forwarded backward along the data flow's path ⬅️. Because the Internet's routing is asymmetric, in this second case the path of the desired data flow should be known before the reservation initiator can send the resource allocation messages 🧭. For example, in RSVP, the PATH message travels from the data flow sources toward the destinations, and it marks the data flow's path first, so the resource allocation messages know where to travel backward 🦋.

This definition only considers protocols that reserve resources for one data flow between the end-nodes. The reservation orientation of protocols that reserve more than one data flow isn't defined here 🙈.

Issues: Where the reservation initiator sits really affects the basics of resource reservation protocols, so it's a super important thing to characterize 💖. Most importantly, in multicast QoS sessions, sender-oriented protocols make the traffic sources keep a list of receivers and send their allocation messages according to each receiver's different requirements. Receiver-oriented protocols let the receivers manage their own resource allocation requests in multicast QoS sessions, which takes a lot of the work off the sources 🫶.

3.3. Router Load Factors 🍓

When a router is under "load", it means there are tasks its CPU(s) have to deal with, and/or its memory holds data it has to keep track of, and/or its interface buffers are being used to some extent, and so on 💻. The tricky part is that we can't assume we can monitor the full internal state of a router during a benchmark. So we have to treat the router as a black box 🖤.

We need to look at router "load" in a way that makes it measurable and controllable 📏. Instead of digging into a router's internal processes, we'll focus on the external processes that create "load". Those are observable, measurable, and controllable, which is exactly what we need 🔍.

In this section we introduce several ways of creating "load" on a router, and from here on we'll call these "load factors" 🧚. Each load factor is defined so it affects the router's performance in a different way (or by different means). Each one uses different components of a resource reservation capable router, and keeps them as separate as possible 🎀.

During a benchmark, the performance of the device under test has to be measured under different controlled load conditions, meaning with different values of these load factors 💅✨.

3.3.1. Best-Effort Traffic Load Factor 🎀

Definition: Okay so the best-effort traffic load factor is the number and length of equal-sized best-effort data packets that zip through the router in one second 🦋

Discussion: Forwarding best-effort packets means the router has to grab the routing info and move the packet between network interfaces, and that takes processing power 💅 This load factor puts pressure on the router's CPU(s) and buffers.

For benchmarking, we define a traffic flow as a stream of equal-sized packets with even interpacket delay. You can also specify traffic with varying packet sizes as a superposition of multiple best-effort traffic flows, as they're defined here ✨

Issues: The same amount of data split into differently sized packets puts different amounts of load on the router, so that has to be considered during benchmarking measurements. The measurement unit reflects this too 🙈

Measurement unit: This load factor has a composite unit of [packets per second (pps); bytes]. For example, [5 pps; 100 bytes] means five pieces of one-hundred-byte packets per second 📦

3.3.2. Distinguished Traffic Load Factor 💜

Definition: The distinguished traffic load factor is the number and length of the distinguished data packets that traverse the router in a second 🌸

Discussion: Just like best-effort data, forwarding distinguished packets requires getting the routing info and transferring the packet between network interfaces. The difference is that these packets also have to be classified, and that needs extra processing capacity 🧠

For benchmarking, we define a traffic flow as a stream of equal-sized packets with even interpacket delay. You can specify traffic with varying packet sizes as a superposition of multiple distinguished traffic flows, as they're defined here 💖

Issues: Just as in the best-effort case, the same amount of data segmented into differently sized packets causes different amounts of load on the router. That has to be considered during the benchmarking measurements, and the measurement unit reflects this as well 🫶

Measurement unit: This load factor has a composite unit of [packets per second (pps); bytes]. For example, [5 pps; 100 bytes] means five pieces of one-hundred-byte packets per second 🍓

3.3.3. Session Load Factor 🧚

Definition: The session load factor is the number of QoS sessions the router is keeping track of 👑

Discussion: Resource reservation capable routers maintain reservation states to keep track of QoS sessions. The more reservation states are registered with the router, the more complex the traffic classification gets, and the longer it takes to look up the matching reservation state. It's giving a lot of work 😭

Signaling messages that control those reservation states also have to be identified before the router does anything else, and that classification is extra work too 💅

With soft-state resource reservation protocols, the session load also affects reservation state maintenance. For example, supervising the timers that watchdog reservation state refreshes can add more load on the router ⏲️

This load factor utilizes the CPU(s), the main memory, and the session management logic (e.g., content addressable memory), if any, of the resource reservation capable router 🔥

Measurement unit: This load component is measured by the number of QoS sessions that impact the router 🎀

3.3.4. Signaling Intensity Load Factor ⭐

Definition: The signaling intensity load factor is the number of signaling messages presented at the input interfaces of the router during one second 📨

Discussion: Processing signaling messages takes processor power, which raises the load on the router's control plane 🧁

In routers where the control plane and the data plane aren't totally independent (e.g., certain tasks are served by the same processor, or the architecture shares memory buffers, transfer buses, or other resources), the signaling load can also affect the router's packet forwarding performance 🌈

Naturally, just like everywhere else in this document, the term "signaling messages" refers only to the resource reservation protocol related primitives 🦋

Issues: Most resource reservation protocols have several protocol primitives, each realized by a different signaling message type. Each of these message types may need a different amount of processing power from the router, so this has to be considered during the benchmarking measurements 🙈

Measurement unit: The unit of this factor is signaling messages/second 💜

3.3.5. Signaling Burst Load Factor 💥

Definition: The signaling burst load factor is the number of signaling messages that arrive at one input port of the router back-to-back ([1]), causing persistent load on the signaling message handler 🔁

Discussion: This definition focuses on one input port only and doesn't consider traffic arriving at the other input ports. So a set of messages arriving at different ports, even if their timing would form a burst at a single port, is not considered a burst. The reason is that a black-box test can't guarantee that this would have the same effect on the router as a burst (incoming at the same interface) does 🤷‍♀️

This definition conforms to the burst definition given in [3] ✅

Issues: Most resource reservation protocols have several protocol primitives realized by different signaling message types. Bursts built from different messages may affect the router differently, so the content of the burst has to be considered during measurements 🎀

Also, the first one of multiple idempotent signaling messages that each accomplish exactly the same end will probably not take the same amount of time to process as the subsequent ones. Benchmarking methodology will have to consider the intended effect of the signaling messages, as well as the state of the router when they arrive 🧐

Measurement unit: This load factor is characterized by the number of messages in the burst 🌸

3.4. Performance Metrics 📊

This group of definitions is a collection of measurable quantities that describe the performance impact the different load components have on the router 💅

During a benchmark, the values of these metrics will have to be measured under different load conditions 🫶

3.4.1. Signaling Message Handling Time ⏱️

Definition: The signaling message handling time (or, in short, signal handling time) is the latency ([1], for store-and-forward devices) of a signaling message passing through the router 🚦

Discussion: The router interprets signaling messages, acts on their content, and usually forwards them in an unmodified or modified form. So the message handling time is usually longer than the forwarding time of data packets of the same size 💅

There might be signaling message primitives that are drained or generated by the router, like certain refresh messages. In that case, the signal handling time isn't necessarily measurable, so it isn't defined for those messages 🙈

For signaling messages that carry information about multicast flows, the router might issue multiple signaling messages after processing them. In this case, by definition, the signal handling time is the latency between the incoming signaling message and the last outgoing signaling message related to the received one 🌊

The signal handling time is an important characteristic because it directly affects the setup time of a QoS session 🔥

Issues: The signal handling time may depend on the type of the signaling message. For example, it usually takes less time for the router to remove a reservation state than to set one up. This has to be considered during the benchmarking process 🧠

As noted above, the first one of multiple idempotent signaling messages that each accomplish exactly the same end will probably not take the same amount of time to process as the subsequent ones. Benchmarking methodology will have to consider the intended effect of the signaling messages, as well as the state of the router when they arrive 🎀

Measurement unit: The dimension of the signaling message handling time is the second. Report it with a resolution sufficient to tell different events/DUTs apart (e.g., milliseconds). Reported results MUST clearly indicate the time unit used ⏰

3.4.2. Distinguished Traffic Delay 🦋

Definition: Distinguished traffic delay is the latency ([1], for store-and-forward devices) of a distinguished data packet passing through the tested router device ✨

Discussion: Distinguished traffic packets must be classified first so the network resources dedicated to the flow can be assigned. The classification time gets added to the usual forwarding time (including queuing) that a router would spend on the packet without any resource reservation capability. This classification procedure might be quite time-consuming in routers with vast amounts of reservation states 🌀

Some routers share processing power between the control plane and the data plane. That means processing signaling messages may affect the data forwarding performance of the router. In this case, the distinguished traffic delay metric also shows how much the two planes influence each other 💜

Issues: Queuing of incoming data packets in routers can bias this metric, so the measurement procedures have to account for that effect 🫠

Measurement unit: The dimension of the distinguished traffic delay is the second. Report it with a resolution sufficient to tell different events/DUTs apart (e.g., millisecond units). Reported results MUST clearly indicate the time unit used 💖

3.4.3. Best-effort Traffic Delay ⏱️

Definition: okay so best-effort traffic delay is basically the latency of a best-effort data packet zipping through the router being tested 🚀

Discussion: this one's giving "are the planes fighting?" 👀 If the router's processing power is shared between the control and data planes, then handling signaling messages can totally mess with how fast data gets forwarded. So this metric is a vibe check on how much the two planes influence each other 💅

Issues: queuing of incoming data packets in routers can bias this metric too, so measurement procedures have to account for that 🙈

Measurement unit: the dimension is the second 🕐, reported with enough resolution to tell different events/DUTs apart (e.g., millisecond units). Reported results MUST clearly indicate the time unit used 🫶

3.4.4. Signaling Message Deficit 📉

Definition: signaling message deficit is one minus the ratio of the actual and the expected number of signaling messages leaving a resource reservation capable router 🧮

Discussion: this gives the same value as the ratio of the lost messages (the ones not forwarded or not generated) to the expected messages. The above calculation must be used because the number of lost messages cannot be measured directly, bestie 🙃

Some signaling messages are ones that reservation capable routers are required to forward as soon as their processing is finished. But due to lack of resources or other reasons, the forwarding or even the processing of these messages might not happen 😭

Certain other kinds of signaling messages have to be generated by the router even when there's no corresponding incoming message. An overloaded router might not have the resources needed to generate one of those 💀

So to characterize these situations, we introduce the signaling message deficit metric. It expresses the ratio of the signaling messages that actually left the router to the ones that were expected to leave. We subtract that ratio from one to get a loss-type metric instead of a "message survival metric" ✨

Since the most frequent reason for signaling message deficit is high router load, this metric is perfect for sounding out the scalability limits of resource reservation capable routers 👑

During the measurements, you have to be able to tell whether a signaling message is still sitting in the router's queues or has already been dropped 👀. So we define a signaling message as lost if no forwarded signaling message is emitted within a reasonably long time period. This period is defined along with the benchmarking methodology 🎀

Measurement unit: this measure has no unit. It's expressed as a real number between zero and one, including the limits 🔢

3.4.5. Session Maintenance Capacity 🦋

Definition: the session maintenance capacity metric is only used for soft-state resource reservation protocols. It's the ratio of the number of QoS sessions actually being maintained to the number of QoS sessions that should have been maintained 💜

Discussion: for soft-state protocols, maintaining a QoS session means refreshing the reservation states associated with it 🔄

When a soft-state resource reservation capable router is overloaded, it might not be able to refresh all the registered reservation states, because it doesn't have time to run the state refresh task. So sooner or later, some QoS sessions get lost even when the endpoints still need them maintained 😩

The session maintenance capacity sounds out the maximal number of QoS sessions that the router is capable of maintaining 🌸

Issues: the actual process of session maintenance depends on the protocol and the implementation, and so does the method for checking whether a session is maintained 🧩

In soft-state resource reservation protocols, the network nodes are responsible for generating the refresh messages. So a router that fails to maintain a QoS session may not emit refresh signaling messages either. This has direct consequences for the signaling message deficit metric 🚨

Measurement unit: this measure has no unit. It's expressed as a real number between zero and one (including the limits) 🔢

3.5. Router Load Conditions and Scalability Limit 🌈

Depending mainly, but not exclusively, on the overall load of a router, it can be in exactly one of four conditions at a time: loss-free and QoS compliant; lossy and QoS compliant; loss-free but not QoS compliant; and neither loss-free nor QoS compliant. These conditions are defined below, along with the scalability limit 💅

3.5.1. Loss-Free Condition 🫧

Definition: a router is in loss-free condition (or loss-free state) if and only if it's able to perform its tasks correctly and in a timely fashion 🧚

Discussion: all existing routers have finite buffer memory and finite processing power. If a router is in loss-free state, its buffers still have enough free space to accommodate the next incoming packet when it arrives. The router also has enough processing power to cope with all its tasks, so every required operation is carried out within the time the protocol specification allows. If that time isn't specified by the protocol, then it's carried out in "reasonable time" (which is then defined in the benchmarks) ⏰

Similar considerations apply to any other resources a router may have. In loss-free states, the utilization of those resources still lets the router carry out its tasks according to the applicable protocol specifications and in "reasonable time" 🌷

Note that loss-free states, as defined above, are not related to the reservation states of resource reservation protocols. The word "state" is used to mean "condition" 🙂

Also, it doesn't matter what internal reason causes a router to fail to perform according to protocol specifications or in "reasonable time." If it's not high load but, for example, an implementation error that makes the device perform inadequately, it still can't be said to be in a loss-free state 🐛. The same goes for random early dropping of packets to prevent congestion. In a black-box measurement, it's impossible to tell whether a packet was dropped as part of a congestion control mechanism or because the router couldn't forward it. So if packet loss is observed (except as noted below), the router is by definition in lossy state (lossy condition) 🫠

If a distinguished data flow exceeds its allotted bandwidth, it is acceptable for routers to drop excess packets. So a router that is QoS Compliant (see below) is also loss-free, provided that it only drops packets from distinguished data flows 🎀

If a device is not in a loss-free state, it's in a lossy condition/state 💀

Related definitions:

Lossy Condition
QoS Compliant Condition
Not QoS Compliant Condition
Scalability Limit

3.5.2. Lossy Condition 🌧️

Definition: a router is in a lossy condition (or lossy state) if it can't perform its duties adequately for some reason. That means it doesn't meet protocol specifications (except QoS guarantees, which are treated separately), or, if time-related specifications are missing, it doesn't complete some operations in "reasonable time" (which is then defined in the benchmarks) 😵‍💫

Discussion: a router may be in a lossy state for several reasons, including but not necessarily limited to the following 👇

a) Buffer memory has run out, so either an incoming or a buffered packet has to be dropped 🥲
b) The router doesn't have enough processing power to cope with all its duties. Some required operations get skipped, aborted, or suffer unacceptable delays 🐌
c) Some other finite internal resource is exhausted 🫙
d) The router runs a defective (non-conforming) protocol implementation 🤒
e) Hardware malfunction 🔧
f) A congestion control mechanism is active 🚦

Loss can mean the loss of data packets as well as signaling message deficit ✨

A router that doesn't lose data packets and doesn't experience signaling message deficit, but still fails to meet required QoS parameters, is in the loss-free but not the QoS compliant state 🫤

If a device is not in a lossy state, it's in a loss-free condition/state 🌈

Related definitions:

Loss-Free Condition (especially the discussion of congestion control mechanisms that cause packet loss)
Scalability Limit
Signaling Message Deficit
QoS Compliant Condition
Not QoS Compliant Condition

3.5.3. QoS Compliant Condition 💖

Definition: a router is in the QoS compliant state if and only if all distinguished data flows get the QoS treatment they're entitled to 👑

Discussion: defining which specific QoS guarantees must be upheld is beyond the scope of this document, because every reservation model may specify a different set of such parameters 🙈

Loss, delay, jitter, etc. of best-effort data flows are irrelevant when considering whether a router is in the QoS compliant state 🧃

Related definitions:

Loss-Free Condition
Lossy Condition
Not QoS Compliant Condition
Scalability Limit

3.5.4. Not QoS Compliant Condition 🚫

Definition: a router is in the not QoS compliant state if and only if it is not in the QoS compliant condition 🙅‍♀️

Related definitions:

Loss-Free Condition
Lossy Condition
QoS Compliant Condition
Scalability Limit

3.5.5. Scalability Limit 🦋

Definition:

The scalability limits of a router are the boundary load conditions where the router is still in the loss-free and QoS compliant state, but the smallest amount of additional load would drive it to a state that is either QoS compliant but not loss-free, or not QoS compliant but loss-free, or neither loss-free nor QoS compliant. 💖

Discussion:

Okay so an unloaded router that operates correctly is totally in a loss-free and QoS compliant state ✨ As load goes up, the router's resources get more and more utilized, and at some point it slides into a state that is either not QoS compliant, or not loss-free, or neither one 😭 Note that this point can be literally impossible to reach in some cases. For example, if the bandwidth of the physical medium stops the traffic load from going any higher, you just can't get there 💀

A particular load condition can be identified by the values of the load factors (as defined in 3.3 Router Load Factors) that affect the router. These values can be written as a 7-tuple of numbers. There are only five load factors, but the traffic load factors have composite units, so each of them needs two numbers to express it 🧚 You can think of these tuples as vectors that point to a state. That state is either both loss-free and QoS compliant, or not loss-free (but QoS compliant), or not QoS compliant (but loss-free), or neither loss-free nor QoS compliant. The scalability limit of the router is the boundary between the set of vectors for the loss-free and QoS compliant states and all the other states. Finding these boundary points is one of the main goals of benchmarking 👑

Benchmarks may try to identify the boundaries of the loss-free condition and the QoS compliant condition separately, in the (seven-dimensional) space defined by the load vectors 🌈

Related definitions:

Lossy Condition
Loss-Free Condition
QoS Compliant Condition
Non QoS Compliant Condition

4. Security Considerations 🔒

Okay, this one's short and sweet 🫶 This document only provides terminology. It doesn't describe a protocol, an implementation, or a procedure, so there are no security considerations associated with it. Not a single one, bestie 💅

5. Acknowledgements 🌸

We would like to thank Telia Research AB, Sweden and the High Speed Networks Laboratory at the Department of Telecommunication and Media Informatics of the Budapest University of Technology and Economics, Hungary, for their support in the research and development work that contributed to the creation of this document 💜 The authors really appreciate it.

6. References 📚

6.1. Normative References

[1] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[3] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.

6.2. Informative References

[4] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.

[5] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.

[6] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.

[7] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signaling Transport", Work in Progress, April 2007.

[8] Manner, J., Ed., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service Signaling", Work in Progress, June 2007.

[9] Ash, J., Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC Template", Work in Progress, March 2007.

[10] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation Mechanism for the Internet", Computer Communication Review, on-line version, volume 29, number 2, April 1999

[11] Delgrossi, L. and L. Berger, "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 1995.

[12] P. White, J. Crowcroft, "A Case for Dynamic Sender-Initiated Reservation in the Internet", Journal on High Speed Networks, Special Issue on QoS Routing and Signaling, Vol. 7 No. 2, 1998

[13] J. Bergkvist, D. Ahlard, T. Engborg, K. Nemeth, G. Feher, I. Cselenyi, M. Maliosz, "Boomerang : A Simple Protocol for Resource Reservation in IP Networks", Vancouver, IEEE Real-Time Technology and Applications Symposium, June 1999

[14] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight Resource Reservation for Unicast IP Traffic", International WS on QoS'98, IWQoS'98, May 18-20, 1998

[15] Manner, J. and X. Fu, "Analysis of Existing Quality-of-Service Signaling Protocols", RFC 4094, May 2005.

[16] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.

Authors' Addresses 🧑‍💻

Gabor Feher Budapest University of Technology and Economics Department of Telecommunications and Media Informatics Magyar Tudosok krt. 2, H-1117, Budapest, Hungary

Phone: +36 1 463-1538 EMail: Gabor.Feher@tmit.bme.hu

Krisztian Nemeth Budapest University of Technology and Economics Department of Telecommunications and Media Informatics Magyar Tudosok krt. 2, H-1117, Budapest, Hungary

Phone: +36 1 463-1565 EMail: Krisztian.Nemeth@tmit.bme.hu

Andras Korn Budapest University of Technology and Economics Department of Telecommunication and Media Informatics Magyar Tudosok krt. 2, H-1117, Budapest, Hungary

Phone: +36 1 463-2664 EMail: Andras.Korn@tmit.bme.hu

Istvan Cselenyi TeliaSonera International Carrier Vaci ut 22-24, H-1132 Budapest, Hungary

Phone: +36 1 412-2705 EMail: Istvan.Cselenyi@teliasonera.com

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧠

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🎀

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from

ietf: rfc4883 2007-07
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms

RFC 4883

RFC 4883: Benchmarking Terminology for Resource Reservation Capable Routers 🎀

Status of This Memo 📌

Copyright Notice ©️

Abstract 🦋

Table of Contents 🗂️

1. Introduction 🌸

2. Existing Definitions 📚

3. Definition of Terms 🎀

3.1. Traffic Flow Types 🦋

3.1.1. Data Flow

3.1.2. Distinguished Data Flow

3.1.3. Best-Effort Data Flow

3.2. Resource Reservation Protocol Basics 🛠️

3.2.1. QoS Session 💖

3.2.2. Resource Reservation Protocol 🦋

3.2.3. Resource Reservation Capable Router 👑

3.2.4. Reservation State 🧚

3.2.5. Resource Reservation Protocol Orientation 🌈

3.3. Router Load Factors 🍓

3.3.1. Best-Effort Traffic Load Factor 🎀

3.3.2. Distinguished Traffic Load Factor 💜

3.3.3. Session Load Factor 🧚

3.3.4. Signaling Intensity Load Factor ⭐

3.3.5. Signaling Burst Load Factor 💥

3.4. Performance Metrics 📊

3.4.1. Signaling Message Handling Time ⏱️

3.4.2. Distinguished Traffic Delay 🦋

3.4.3. Best-effort Traffic Delay ⏱️

3.4.4. Signaling Message Deficit 📉

3.4.5. Session Maintenance Capacity 🦋

3.5. Router Load Conditions and Scalability Limit 🌈

3.5.1. Loss-Free Condition 🫧

3.5.2. Lossy Condition 🌧️

3.5.3. QoS Compliant Condition 💖

3.5.4. Not QoS Compliant Condition 🚫

3.5.5. Scalability Limit 🦋

4. Security Considerations 🔒

5. Acknowledgements 🌸

6. References 📚

6.1. Normative References

6.2. Informative References

Authors' Addresses 🧑‍💻

Full Copyright Statement ©

Intellectual Property 🧠

Acknowledgement 🎀