RFC 9064

Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols

📅 published June 2021, from ietf

Title Block 🎀

Okay bestie, first the paperwork. This RFC is RFC 9064, titled Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols 🦋. It was written by D. Oran from Network Systems Research and Design, and it's published in June 2021 as Informational. It comes from the IRTF (Internet Research Task Force) and has ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so there's nothing to chase down there 💅.

Abstract ✨

Okay so this is a position paper, which means it's one author sharing her personal take 💭. The big question is how Quality of Service (QoS) should work in Information-Centric Networking (ICN) protocols like Content-Centric Networking (CCNx) or Named Data Networking (NDN). These protocols run on flow-balanced Interest/Data exchanges and hop-by-hop forwarding state, and that changes everything 🌸.

The author argues that ICN needs a really different QoS approach than TCP/IP, and she suggests some design patterns for classifying traffic and treating it differently, both per flow and in aggregate 🔥. She also says caches count as resources, alongside memory, CPU, and link bandwidth, and that they should be allowed to be shared unfairly on purpose 👑. The methods are meant to live purely at the network layer, giving transport and higher layers the building blocks they need. Quality of Experience (QoE) is explicitly off the table, since that can only be judged at the application layer or above 🙈.

This document is not an IRTF ICNRG product, but it went through a formal Last Call and has the research group's backing for publication as an individual submission 🫶.

Status of This Memo 📜

This isn't an Internet Standards Track spec. It's published just for info 🧚.

It's an IRTF product, and the IRTF shares results from Internet-related research and development. Those results might not be ready for deployment. This RFC is one or more ICNRG members speaking for themselves, and anything the IRSG approves for publication isn't eligible for any level of Internet Standard. Check Section 2 of RFC 7841 if you want the details 🌈.

For current status, errata, or feedback, head to https://www.rfc-editor.org/info/rfc9064 ✨.

Copyright (c) 2021 IETF Trust and the people listed as the document's authors. All rights reserved 🎀.

This document is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info as they stood when this was published. Read those carefully, because they spell out what you can and can't do with this doc 🙈.

Table of Contents 🍓

1.  Introduction
  1.1.  Applicability Assessment by ICNRG Chairs
2.  Requirements Language
3.  Background on Quality of Service in Network Protocols
  3.1.  Basics on How ICN Protocols like NDN and CCNx Work
  3.2.  Congestion Control Basics Relevant to ICN
4.  What Can We Control to Achieve QoS in ICN?
5.  How Does This Relate to QoS in TCP/IP?
6.  Why Is ICN Different?  Can We Do Better?
  6.1.  Equivalence Class Capabilities
  6.2.  Topology Interactions with QoS
  6.3.  Specification of QoS Treatments
  6.4.  ICN Forwarding Semantics Effect on QoS
  6.5.  QoS Interactions with Caching
7.  Strawman Principles for an ICN QoS Architecture
  7.1.  Can Intserv-Like Traffic Control in ICN Provide Richer QoS
        Semantics?
8.  IANA Considerations
9.  Security Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Author's Address

1. Introduction ✨

Okay so TCP/IP has been running the Internet for over 30 years, and in that time it built up a ton of QoS machinery. How well that machinery works depends a lot on the environment 💅. ICN protocols like NDN [NDN] and CCNx [RFC8569] [RFC8609] have about ten years of research behind them but hardly any deployment yet. That's our window 🪟. We could copy the TCP/IP playbook, meaning Intserv [RFC2998] and Diffserv [RFC2474], or we could design something new that fits how ICN actually behaves. The author is team "design something new" 🦋, since ICN works in fundamentally different ways from TCP/IP. Table 1 shows the big differences 👑:

+=============================+====================================+
|            TCP/IP           |            CCNx or NDN             |
+=============================+====================================+
|     Stateless forwarding    |        Stateful forwarding         |
+-----------------------------+------------------------------------+
|        Simple packets       | Object model with optional caching |
+-----------------------------+------------------------------------+
|     Pure datagram model     |       Request-response model       |
+-----------------------------+------------------------------------+
|      Asymmetric routing     |         Symmetric routing          |
+-----------------------------+------------------------------------+
| Independent flow directions |   Flow balance (see note below)    |
+-----------------------------+------------------------------------+
|  Flows grouped by IP prefix |    Flows grouped by name prefix    |
|           and port          |                                    |
+-----------------------------+------------------------------------+
|    End-to-end congestion    |   Hop-by-hop congestion control    |
|           control           |                                    |
+-----------------------------+------------------------------------+

Table 1: Differences between IP and ICN Relevant to QoS Architecture

Heads up 👀: flow balance is an NDN and CCNx property. It means one Interest packet gets back no more than one Data packet. If you want to see why that matters for QoS, check [FLOWBALANCE] 🫶.

The document proposes design patterns for flow classification and differentiated QoS treatment in ICN, covering both individual flows and aggregates 🌸. It also says caches should count as resources, right alongside memory, CPU, and link bandwidth, and be subject to explicitly unfair allocation 💖. The methods are supposed to work purely at the network layer, giving both transport and higher-layer QoS what they need 🔥. It doesn't go into detailed protocol machinery. That job goes to supporting specs like [FLOWCLASS] and [DNC-QOS-ICN] 🧚. And yes, QoE is excluded again, since only the application layer or above can assess and control it 🙈.

A lot of this paper comes from talks the author gave at ICNRG meetings over the past few years. You can find them on the IETF datatracker, for example [Oran2018QoSslides] 🎀.

1.1. Applicability Assessment by ICNRG Chairs 💅

QoS in ICN is a huge topic with a massive design space 🌈. ICNRG has been chatting about specific protocol mechanisms and big-picture concepts. This document is about architecture, and it looks at what ICN's properties offer instead of just copying IP QoS tools. It doesn't define a specific architecture or specific protocol mechanisms yet ✨. Still, ICNRG agrees that this document, which spells out the author's views, could spark that work, so it should be published as a position paper 👑.

2. Requirements Language 💜

Here's the one bit of grammar-police business 📚. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. So capital letters mean the BCP 14 meaning, and lowercase is just normal English 🫶.

3. Background on Quality of Service in Network Protocols 🎀

Okay bestie, this background section is mostly tutorial, so if you already know the long and checkered history of QoS in packet networks, you can skip ahead 🙈 Some parts are kinda polemical, but they also show the author's personal biases and technical views, which is honestly useful to know 💅

All networking systems provide some degree of "quality of service" in that they show nonzero utility when they're handed traffic to carry. Like, a network that never delivers any of the traffic apps inject is totally useless 💀 So the term QoS is more correctly used in a more restricted sense, to describe systems that control the allocation of various resources in order to achieve managed unfairness ✨ Without explicit mechanisms to decide which traffic gets treated unfairly, most systems try to achieve some form of "fairness" in resource allocation, optimizing the overall utility delivered to all traffic under the constraint of available resources. So it should be obvious that you cannot use QoS mechanisms to create or otherwise increase resource capacity! 😭 In fact, all known QoS schemes have nonzero overhead and hence may (albeit slightly) decrease the total resources available to carry user traffic 💔

Further, accumulated experience seems to indicate that QoS is helpful in a fairly narrow range of network conditions:

  • If your resources are lightly loaded, you don't need it, as neither congestive loss nor substantial queuing delay occurs. 🌸
  • If your resources are heavily oversubscribed, it doesn't save you. So many users will be unhappy that you are probably not delivering a viable service. 😩
  • Failures can rapidly shift your state from the first above to the second, in which case either:
    • Your QoS machinery cannot respond quickly enough to maintain the advertised service quality continuously, or
    • Resource allocations are sufficiently conservative to result in substantial wasted capacity under non-failure conditions.

Nevertheless, though not universally deployed, QoS is advantageous at least for some applications and some network environments. Some examples include:

  • Applications with steep utility functions [Shenker2006], such as real-time multimedia 🎥
  • Applications with safety-critical operational constraints, such as avionics or industrial automation ✈️
  • Dedicated or tightly managed networks whose economics depend on strict adherence to challenging service level agreements (SLAs) 👑

Another factor in the design and deployment of QoS is the scalability and scope over which the desired service can be achieved. Here there are two major considerations, one technical, the other economic/political:

  • Some signaled QoS schemes, such as the Resource reSerVation Protocol (RSVP) [RFC2205], maintain state in routers for each flow, which scales linearly with the number of flows. For core routers through which pass millions to billions of flows, the memory required is infeasible to provide. 🧠
  • The Internet is comprised of many minimally cooperating autonomous systems [AS]. There are practically no successful examples of QoS deployments crossing the AS boundaries of multiple service providers. In almost all cases, this limits the applicability of QoS capabilities to be intra-domain. 🌍

This document adopts a narrow definition of QoS as managed unfairness (see note below). However, much of the networking literature uses the term more colloquially, applying it to any mechanism that improves overall performance. One could use a different, broader definition of QoS that encompasses optimizing the allocation of network resources across all offered traffic without considering individual users' traffic. A consequence would be the need to cover whether (and how) ICN might result in better overall performance than IP under constant resource conditions, which is a much broader goal than the one attempted here. The chosen narrower scope comports with the commonly understood meaning of "QoS" in the research community. Under this scope, and under constant resource constraints, the only way to provide traffic discrimination is in fact to sacrifice fairness. Readers assuming the broader context will find a large class of proven techniques to be ignored. This is intentional 🙃 Among these are seamless producer mobility schemes like MAP-Me [Auge2018] and network coding of ICN data as discussed in [NWC-CCN-REQS].

Note: The term managed unfairness used to explain QoS is generally ascribed to Van Jacobson, who in talks in the late 1990s said, "[The problem we are solving is to] Give 'better' service to some at the expense of giving worse service to others. QoS fantasies to the contrary, it's a zero-sum game. In other words, QoS is _managed unfairness_." 🗣️

Finally, the relationship between QoS and either accounting or billing is murky. Some schemes can accurately account for resource consumption and ascertain to which user to allocate the usage. Others cannot. While the choice of mechanism may have important practical economic and political consequences for cost and workable business models, this document considers none of those things and discusses QoS only in the context of providing managed unfairness 💰

For those unfamiliar with ICN protocols, a brief description of how NDN and CCNx operate as a packet network is in Section 3.1. Some further background on congestion control for ICN follows in Section 3.2. 🦋

3.1. Basics on How ICN Protocols like NDN and CCNx Work 🧚

The following summarizes the salient features of the NDN and CCNx ICN protocols relevant to congestion control and QoS. Quite extensive tutorial information may be found in a number of places, including material available from [NDNTutorials]. 📚

In NDN and CCNx, all protocol interactions operate as a two-way handshake. Named content is requested by a consumer via an Interest message that is routed hop-by-hop through a series of forwarders until it reaches a node that stores the requested data. This can be either the producer of the data or a forwarder holding a cached copy of the requested data. The content matching the name in the Interest message is returned to the requester over the inverse of the path traversed by the corresponding Interest. 🔁

Forwarding in CCNx and NDN is per-packet stateful. Routing information to select next hop(s) for an Interest is obtained from a Forwarding Information Base (FIB), which is similar in function to the FIB in an IP router except that it holds name prefixes rather than IP address prefixes. Conventionally, a Longest Name Prefix Match (LNPM) is used for lookup, although other algorithms are possible, including controlled flooding and adaptive learning based on prior history. 🔍

Each Interest message leaves a trail of "breadcrumbs" as state in each forwarder. This state, held in a data structure known as a Pending Interest Table (PIT), is used to forward the returning Data message to the consumer. Since the PIT constitutes per-packet state, it is therefore a large consumer of memory resources, especially in forwarders carrying high traffic loads over long Round-Trip Time (RTT) paths, and hence plays a substantial role as a QoS-controllable resource in ICN forwarders. 🍞✨

In addition to its role in forwarding Interest messages and returning the corresponding Data messages, an ICN forwarder can also operate as a cache, optionally storing a copy of any Data messages it has seen in a local data structure known as a Content Store (CS). Data in the CS may be returned in response to a matching Interest rather than forwarding the Interest further through the network to the original Producer. Both CCNx and NDN have a variety of ways to configure caching, including mechanisms to avoid both cache pollution and cache poisoning (these are clearly beyond the scope of this brief introduction). 🧊

3.2. Congestion Control Basics Relevant to ICN ✨

Okay bestie, first things first. In any packet network that mixes traffic from lots of sources and destinations, congestion control is necessary so that it can:

  1. Stop utility from collapsing under overload. The total service you get drops as load goes up (maybe precipitously) instead of growing or staying flat. 📉💀
  2. Stop some traffic from starving because other traffic is demanding too much. 🙅
  3. Go beyond basic anti-starvation protection and achieve "fairness" among competing traffic. Two popular objective functions are max-min fairness [minmaxfairness] and proportional fairness [proportionalfairness]. Both have been implemented and deployed successfully on packet networks for many years. 🎀

Before we get to QoS, let's look at how congestion control works in NDN or CCNx. The IP protocol family relies exclusively on end-to-end congestion control (e.g., TCP [RFC0793], DCCP [RFC4340], SCTP [RFC4960], and QUIC [RFC9000]). CCNx and NDN, though, can employ hop-by-hop congestion control. There is per-Interest/Data state at every hop of the path, so outstanding Interests give information that can be used to optimize resource allocation for data returning on the inverse path. That covers things like bandwidth sharing, prioritization, and overload control. In current designs, this allocation is often done using Interest counting. By accepting one Interest packet from a downstream node, you implicitly get a guarantee (either hard or soft) that there is enough bandwidth on the inverse direction of the link to send back one Data packet. 🔁

A bunch of congestion control schemes for ICN work this way, for example [Wang2013], [Mahdian2016], [Song2018], and [Carofiglio2012]. Other schemes, like [Schneider2016], neither count nor police Interests. Instead, they monitor queues using AQM (active queue management) to mark returning Data packets that have experienced congestion. This later class is similar to IP in the sense that it depends on consumers adequately reducing their rate of Interest injection to avoid Data packet drops due to buffer overflow in forwarders. The former class is (arguably) more robust against misbehavior by consumers. 🛡️

Given the stochastic nature of RTTs and the ubiquity of wireless links and encapsulation tunnels with variable bandwidth, a simple scheme that admits Interests only based on a time-invariant estimate of the returning link bandwidth will perform poorly. 😬 However, two characteristics of NDN and CCNx-like protocols can help substantially to improve the accuracy and responsiveness of bandwidth allocation:

  1. RTT is bounded by the inclusion of an Interest Lifetime in each Interest message. That puts an upper bound on the RTT uncertainty for any given Interest/Data exchange. If Interest Lifetimes are kept reasonably short (a few RTTs), the allocation of local forwarder resources doesn't have to deal with an arbitrarily long tail. You could in fact do a deterministic allocation on this basis, but the result would be highly pessimistic. Nevertheless, having a cutoff does improve the performance of an optimistic allocation scheme. ⏱️
  2. A congestion marking scheme like the one used in Explicit Congestion Notification (ECN) can mark returning Data packets if the inverse link starts experiencing long queue occupancy or other congestion indication. Unlike TCP/IP, where rate adjustment can only be done end-to-end, this feedback is usable immediately by the downstream ICN forwarder, and the Interest shaping rate is lowered after a single link RTT. This may allow rate adjustment schemes that are less pessimistic than the Additive Increase, Multiplicative Decrease (AIMD) scheme with .5 multiplier that is commonly used on TCP/IP networks. It also allows the rate adjustments to be spread more accurately among the Interest/Data flows traversing a link that sends congestion signals. 🌸

A useful discussion of these properties, and of how they demonstrate the advantages of ICN approaches to congestion control, can be found in [Carofiglio2016]. 📚

4. What Can We Control to Achieve QoS in ICN? 🎯

QoS is achieved through managed unfairness in the allocation of resources in network elements, particularly in the routers that forward ICN packets. So the first-order questions are: Which resources need to be allocated? And how do you figure out which traffic gets those allocations? In the case of CCNx or NDN, the important network element resources are given in Table 2:

 +=============================+===================================+
 | Resource                    | ICN Usage                         |
 +=============================+===================================+
 | Communication link capacity | buffering for queued packets      |
 +-----------------------------+-----------------------------------+
 | CS capacity                 | to hold cached data               |
 +-----------------------------+-----------------------------------+
 | Forwarder memory            | for the PIT                       |
 +-----------------------------+-----------------------------------+
 | Compute capacity            | for forwarding packets, including |
 |                             | the cost of FIB lookups           |
 +-----------------------------+-----------------------------------+

            Table 2: ICN-Related Network Element Resources

For these resources, any QoS scheme has to specify two things:

  1. How do you create equivalence classes (a.k.a. flows) of traffic to which different QoS treatments are applied?
  2. What are the possible treatments, and how are those mapped to the resource allocation algorithms?

Two critical facts of life come into play when designing a QoS scheme. First, the number of equivalence classes that can be simultaneously tracked in a network element is bounded by both memory and by the processing capacity needed to do the necessary lookups. You can allow very fine-grained equivalence classes but not be able to employ them globally because of scaling limits of core routers. That means it is wise to either restrict the range of equivalence classes or allow them to be aggregated, trading off accuracy in policing traffic against the ability to scale. 🧠

Second, the flexibility of expressible treatments can be tightly constrained by both protocol encoding and algorithmic limitations. The ability to encode the treatment requests in the protocol can be limited (as it is for IP, where there are only six of the Type of Service (TOS) bits available for Diffserv treatments). However, an equal or more important issue is whether there are practical traffic policing, queuing, and pacing algorithms that can be combined to support a rich set of QoS treatments. 💅

The two considerations above, in combination, can easily be substantially more expressive than what can be achieved in practice with the available number of queues on real network interfaces or the amount of per-packet computation needed to enqueue or dequeue a packet. 😭

5. How Does This Relate to QoS in TCP/IP? 🦋

TCP/IP has fewer resource types to manage than ICN, and in some cases the allocation methods are simpler, as shown in Table 3:

  +===============+=============+================================+
  | Resource      | IP Relevant | TCP/IP Usage                   |
  +===============+=============+================================+
  | Communication |     YES     | buffering for queued packets   |
  | link capacity |             |                                |
  +---------------+-------------+--------------------------------+
  | CS capacity   |      NO     | no CS in IP                    |
  +---------------+-------------+--------------------------------+
  | Forwarder     |    MAYBE    | not needed for output-buffered |
  | memory        |             | designs (see note below)       |
  +---------------+-------------+--------------------------------+
  | Compute       |     YES     | for forwarding packets, but    |
  | capacity      |             | arguably much cheaper than ICN |
  +---------------+-------------+--------------------------------+

           Table 3: IP-Related Network Element Resources

   |  Note: In an output-buffered design, all packet buffering
   |  resources are associated with the output interfaces, and
   |  neither the receiver interface nor the internal forwarding
   |  buffers can be over-subscribed.  Output-buffered switches or
   |  routers are common but not universal, as they generally require
   |  an internal speedup factor where forwarding capacity is greater
   |  than the sum of the input capacity of the interfaces.

For these resources, IP has specified three fundamental things, as shown in Table 4:

+=============+====================================================+
|     What    | How                                                |
+=============+====================================================+
| Equivalence | subset+prefix match on IP 5-tuple {SA,DA,SP,DP,PT} |
|   classes   | SA=Source Address                                  |
|             | DA=Destination Address                             |
|             | SP=Source Port                                     |
|             | DP=Destination Port                                |
|             | PT=IP Protocol Type                                |
+-------------+----------------------------------------------------+
|   Diffserv  | (very) small number of globally-agreed traffic     |
|  treatments | classes                                            |
+-------------+----------------------------------------------------+
|   Intserv   | per-flow parameterized *Controlled Load* and       |
|  treatments | *Guaranteed* service classes                       |
+-------------+----------------------------------------------------+

  Table 4: Fundamental Protocol Elements to Achieve QoS for TCP/IP

Equivalence classes for IP can be pairwise, by matching against both source and destination address+port. They can also be pure group, using only destination address+port, or source-specific multicast, with source address+port and destination multicast address+port. 🔍

With Intserv, RSVP [RFC2205] carries two data structures: the Flow Specifier (FLOWSPEC) and the Traffic Specifier (TSPEC). The former fulfills the requirement to identify the equivalence class to which the QoS being signaled applies. The latter comprises the desired QoS treatment along with a description of the dynamic character of the traffic (e.g., average bandwidth and delay, peak bandwidth, etc.). Both of these encounter substantial scaling limits, which has meant that Intserv has historically been limited to confined topologies and/or high-value usages, like traffic engineering. 🚧

With Diffserv, the protocol encoding (six bits in the TOS field of the IP header) artificially limits the number of classes one can specify. These are documented in [RFC4594]. Nonetheless, when used with fine-grained equivalence classes, one still runs into limits on the number of queues required. 🌈

6. Why Is ICN Different? Can We Do Better? ✨

Okay so, bestie, here's where it gets SPICY 🌶️. Could we just copy the whole TCP/IP QoS playbook and call it a day? The author's view is that this would be a mistake 🙅‍♀️. IP QoS has been spotty at best in deployment, and yeah, there are economic and political reasons for that, not just technical ones 💅. But ICN has a few architectural choices that make it a way better base to add QoS machinery to 🦋. This section walks through those differences and what they mean. Let's gooo 🚀

6.1. Equivalence Class Capabilities

First things first, hierarchical names are a MUCH richer way to define equivalence classes than IP 5-tuples 💖. An IP address (or prefix) can only separate traffic by topology, down to the level of hosts. It can't express actual computational instances or sets of data 🙈. Ports give you a little per-instance demultiplexing, but that's coarse and ephemeral, and it mixes up the demux job with assigning QoS treatments to subsets of the data 😭. IPv6 can get somewhat finer, since you can use up to 64 bits of address to classify traffic 🌸. Then there's the Hybrid Information-Centric Networking (hICN) project [HICN]. It adopts the request-response model of CCNx, but it uses IPv6 addresses as its namespace and IPv6 packets (plus "fake" TCP headers) as the wire format 🧚.

Now here's the glow-up 🌈: the flexibility of tokenized (i.e., strings treated as opaque tokens), variable length, hierarchical names lets you directly tie classes of traffic for QoS purposes to the structure of an application namespace ✨. The classification can be as coarse or as fine-grained as the application wants 👑. It's not always the case, but there's usually a straightforward link between how objects are named and how they get grouped for common treatment 💜. There are loads of examples; you can find a bunch in [FLOWCLASS] 🎀.

6.2. Topology Interactions with QoS

In ICN, QoS isn't pre-bound to network topology, because names are non-topological, unlike unicast IP addresses 🦋. That means QoS can be applied to multi-destination and multipath environments in a straightforward way 🔥. Compare that to needing either multicast with coarse class-based scheduling, or complex signaling like RSVP Traffic Engineering (RSVP-TE) [RFC3209], which is what it takes to make point-to-multipoint Multiprotocol Label Switching (MPLS) work 😵‍💫.

Because IP forwarding is stateless, and asymmetric routes are everywhere, any flow-based QoS ends up needing state that's decoupled from when traffic actually arrives 💀. That state has to be kept around, at least as soft state, even during quiet periods 🌙. Intserv, for example, needs flow signaling on the order of O(number of flows) 📈. ICN, even in the worst case, only needs O(number of active Interest/Data exchanges) 🫶. Why? Because state can be created when an Interest arrives and removed (maybe lazily) once the data has come back 💅.

6.3. Specification of QoS Treatments

Intserv goes the signaling route, but Diffserv skips signaling in favor of class-based configuration of resources and queues in network elements 🌸. The catch is that Diffserv only gets a few bits to work with, taken from the TOS field of IP 😬. NDN and CCNx don't have that wire encoding limit, because the protocol is completely TLV (Type-Length-Value) based 🎀. So one (or even more than one) new field can be defined easily to carry QoS treatment info 🧁.

That opens up greenfield possibilities for way more powerful QoS treatment options in ICN ✨. For example, IP has no way to ask for something like "try hard to deliver reliably, even at the expense of delay or bandwidth" 🙃. An ICN QoS treatment like that could invoke native ICN mechanisms, none of which exist in IP, such as the following 🦋:

  • Retransmitting in-network in response to hop-by-hop errors returned from upstream forwarders 🔁
  • Trying multiple paths to multiple content sources, either in parallel or serially 🛤️
  • Assigning higher precedence for short-term caching to recover from downstream (see note below) errors 💾
  • Coordinating cache utilization with forwarding resources 🤝
Note: Downstream refers to the direction Data messages flow toward the consumer (the issuer of Interests). Conversely, Upstream refers to the direction Interests flow toward the producer of data. 📝

Such mechanisms are typically described in NDN and CCNx as forwarding strategies 🧠. But honestly? There's little or no guidance on which application actions or protocol machinery a forwarder should use to pick the right forwarding strategy for arriving Interest messages 😭. See [BenAbraham2018] for an investigation of these issues 📚. Tying forwarding strategies directly to equivalence classes and QoS treatments can make them more accessible and useful to implement and deploy 💖.

Stateless forwarding and asymmetric routing in IP limit the state and feedback available to manage link resources 🙁. NDN or CCNx forwarding, on the other hand, lets all link resource allocation happen as part of Interest forwarding, which could simplify things a LOT ✨. In particular, with symmetric routing, producers have no control over the paths their Data packets take, so any QoS treatments meant to influence routing paths from producer to consumer will have no effect 🚫.

There's one complication for ICN QoS treatments that IP doesn't have, so it's worth mentioning 👀. CCNx and NDN both do Interest aggregation (see Section 2.4.2 of [RFC8569]) 🫧. Say an Interest arrives that matches an existing PIT entry, but with a different QoS treatment from an Interest that was already forwarded. Deciding whether to aggregate it or forward it gets tricky, and so does tracking the differing QoS treatments for the two Interests 😵. Digging into the details of these situations is beyond the scope of this document 🙅‍♀️. For the general case of flow balance and congestion control, check out [FLOWBALANCE]. For QoS treatments specifically, see [DNC-QOS-ICN] 📖💜.

6.4. ICN Forwarding Semantics Effect on QoS

IP has three forwarding semantics, each with different QoS needs: Unicast, Anycast, and Multicast 🌐. ICN has a single forwarding semantic, so any QoS machinery can be applied uniformly across any request/response invocation 💅. That holds whether the forwarder uses dynamic destination routing, multi-destination forwarding with next hops tried serially, multi-destination forwarding with next hops used in parallel, or even localized flooding (e.g., directly on Layer 2 multicast mechanisms) 🤯. Plus, ICN's pull-based model dodges a bunch of thorny multicast QoS problems that IP has (see [Wang2000], [RFC3170], and [Tseng2003]) 🙌.

The multi-destination/multipath forwarding model in ICN changes resource allocation needs in a pretty deep way 🌊. IP treats every endpoint as an open-loop packet source. NDN and CCNx, though, have a strong asymmetry between producers and consumers as packet sources 🦋.

6.5. QoS Interactions with Caching

IP has no caching in routers, but ICN needs ways to allocate cache resources 💾. Treatments that control caching operation are unlikely to look much like treatments used to control link resources 🎀. Good news: NDN and CCNx already have useful cache control directives associated with Data messages ✨. The CCNx controls include the following 📋:

ExpiryTime: time after which a cached Content Object is considered expired and MUST no longer be used to respond to an Interest from a cache. ⏰

Recommended Cache Time: time after which the publisher considers the Content Object to be of low value to cache. 🗑️

For the formal definitions, see [RFC8569] 📜.

ICN flow classifiers, like the ones in [FLOWCLASS], can be used to achieve soft or hard partitioning (see note below) of cache resources in the CS of an ICN forwarder 🧩. For example, cached content for a given equivalence class can be fate shared in a cache, meaning objects from the same equivalence class get purged as a group instead of one at a time 🫂. This can recover cache space faster and with less overhead than pure per-object replacement when a cache is under extreme pressure and in danger of thrashing 🔥. Also, since the forwarder remembers the QoS treatment for each pending Interest in its PIT, those cache controls can be augmented by policy to prefer keeping cached content for some equivalence classes as part of the cache replacement algorithm 👑.

Note: With hard partitioning, there are dedicated cache resources for each equivalence class (or enumerated list of equivalence classes). With soft partitioning, resources are at least partly shared among the (sets of) equivalence classes of traffic. 🍓

7. Strawman Principles for an ICN QoS Architecture ✨

okay so after all the digging in the earlier sections 🧐 this part is where the author finally drops their ideas for architecture principles 💅 they're called strawman principles, which basically means "here's a starting pile of ideas, let's see what sticks" 🍓 the goal is clear, actionable guidance so future work can focus on the parts of the HUGE QoS design space with the best trade-offs between flexibility, simplicity, and deployability 🦋

Define equivalence classes using the name hierarchy rather than creating an independent traffic class definition. This one is so clean 😭 it ties the way traffic gets grouped directly to the structure of the application namespace. Hierarchical ICN names are built in layers, so the equivalence classes can be broken down hierarchically in a super natural way 🌈 [FLOWCLASS] has two practical mechanisms with different trade-offs between security and how well flows can be aggregated. You could adopt the prefix-based one (the equivalence class component count (EC3) scheme), the explicit name component-based one (the equivalence class name component type (ECNCT) scheme), or both, as part of the QoS architecture for defining equivalence classes 🎀

Put consumers in control of link and forwarding resource allocation. Base all link buffering and forwarding resource allocations (memory and CPU both) on Interest arrivals 🔥 this is so attractive because consumers get early congestion feedback, and the reverse link direction can be scheduled ahead of time to carry the matching Data 🚀 enforcing QoS treatments becomes a single-ended problem (handled at the consumer) instead of a double-ended one 💜 and it helps avoid wasting resources on fetching Data that's just going to get dropped at a bottleneck link 🙈

Allow producers to influence the allocation of cache resources. Producers want to shape caching decisions for two main reasons 💖

  • Shed load by having Interests served by CSes in forwarders before they reach the producer itself
  • Survive transient producer reachability or link outages close to the producer

For caching to actually work, individual Data objects in an equivalence class need to get similar treatment 🧚 otherwise well-known cache-thrashing pathologies caused by self-interference show up, and nobody wants that 💀 producers have the most direct control over caching policy through the caching directives in their Data messages, so it makes sense for the producer, not the consumer or the network operator, to be in charge of specifying these equivalence classes 👑

See [FLOWCLASS] for the specific mechanisms that make this happen ✨

Allow consumers to influence the allocation of cache resources. Consumers want to affect caching decisions for these reasons 🫶

  • Reduce latency for retrieving data
  • Survive transient outages of either a producer or links close to the consumer

Consumers can have indirect control over caching by specifying QoS treatments in their Interests 💅 here are some potential consumer QoS treatments that could drive caching policies:

  • A QoS treatment asking for better robustness against transient disconnection can be used by a forwarder close to the consumer (or downstream of an unreliable link) to preferentially cache the matching data 🛡️
  • Conversely, a QoS treatment paired with, or added to, a request for short latency tells the forwarder to only pay attention to the producer's caching preferences 🙃 caching the requested data would be ineffective here, because new data will be requested shortly, so it's giving "why bother" 🤷‍♀️
  • A QoS treatment indicating that a mobile consumer will likely incur a mobility event within an RTT (or a few RTTs) 🦋 this would let a mobile network operator preferentially cache the data at a forwarder sitting at a join point or rendezvous point of their topology 🗺️

Give network operators the ability to match customer SLAs to cache resource availability. Network operators, whether they're closely tied administratively to the producer or consumer or are an independent transit administration, provide the storage in the ICN forwarders 🏗️ that makes them the ultimate arbiters of how cache resources get managed 👑 on top of any local policies they enforce, the cache behavior from a QoS standpoint comes from mapping producer-specified equivalence classes onto available cache space, including whether cache entries get treated individually or fate-shared 🌸 forwarders also decide how consumer-specified QoS treatments map to the precedence used for keeping Data objects in the cache 💜

Beyond using cache resources to meet individual producer and consumer QoS goals, network operators also want to manage their caches to do the following:

  • Ameliorate congestion hotspots by reducing load converging on producers they host on their network
  • Improve Interest satisfaction rates by using caches as short-term retransmission buffers to recover from transient producer reachability problems, link errors, or link outages
  • Improve both latency and reliability in environments where consumers are mobile in the operator's topology 🌈

Rethink how to specify traffic treatments -- don't just copy Diffserv. Some of the Diffserv classes could be a good starting point, since their mappings onto queuing algorithms for managing link buffering are well understood 🧠 but Diffserv alone doesn't capture more complex QoS treatments, like:

  • Trading off latency against reliability
  • Trading off resource usage against delivery probability through controlled flooding or other forwarding mechanisms
  • Allocating resources based on rich TSPEC-like traffic descriptions of the kind that show up in signaled QoS schemes like Intserv

Here are some examples 🎀

  • A "burst" treatment, where an initial Interest gives an aggregate data size to request allocation of link capacity for a large burst of Interest/Data exchanges 💥 the Interest can be rejected at any hop if the resources aren't available 🙅‍♀️ this treatment can also handle Data implosion produced by the discovery procedures of management protocols like [CCNINFO] 🌊
  • A "reliable" treatment, which affects the preference for allocating PIT space for the Interest and CS space for the Data, to improve the robustness of IoT data delivery in a constrained environment, as described in [IOTQOS] 🔋
  • A "search" treatment, which, within the specified Interest Lifetime, tries many paths either in parallel or serially to potentially many content sources 🔍 this maximizes the chance the requested item gets found, but it costs extra bandwidth for forwarding Interests and for receiving multiple responses upstream of an aggregation point 😵‍💫 the treatment can encode a value expressing trade-offs like breadth-first versus depth-first search, plus bounds on the total resource expenditure 🧭 this would be useful for instrumentation protocols like [ICNTRACEROUTE] 🛰️
As an aside, loose latency control (on the order of seconds or tens of milliseconds as opposed milliseconds or microseconds) can be achieved by bounding Interest Lifetime, as long as this lifetime machinery is not also used as an application mechanism to provide subscriptions or to establish path traces for producer mobility 🙈 see [Krol2018] for a discussion of the network versus application timescale issues in ICN protocols 📚

7.1. Can Intserv-Like Traffic Control in ICN Provide Richer QoS Semantics? 🎀

Okay bestie, so basic QoS treatments like the ones we just covered might not be enough for the whole range of application utility functions and deployment environments we expect for ICN 🥺. Yes, you don't need a separate signaling protocol like RSVP, since forwarders already carry state in the ICN data plane 💅. But simple QoS treatments applied per Interest/Data exchange are missing some potentially important stuff ✨. Intserv's richer QoS capabilities could be really valuable, especially if ICN can provide them with less complexity and protocol overhead than Intserv plus RSVP 🦋.

There are three key capabilities that Diffserv-like QoS treatments are missing, no matter how sophisticated they get at describing the desired treatment for an equivalence class of traffic 😭. Intserv-like QoS gives you all three:

  1. The ability to describe traffic flows in a mathematically meaningful way 📐. This is done with parameters like average rate, peak rate, and maximum burst size. The parameters get packed into a data structure called a "TSPEC", which can go in whatever protocol needs the info (for TCP/IP Intserv, that's RSVP) 🧚.
  2. The ability to do admission control, where the element asking for the QoS treatment can know _before_ it introduces traffic whether the network elements have agreed to give it the requested treatment 🫶. A big side effect of that assurance is that the network elements install state that lets the forwarding and queuing machinery police and shape the traffic, giving it a solid degree of _isolation_ from the dynamic behavior of other traffic. Depending on the admission-control mechanism, it may or may not be possible to explicitly release that state when the application no longer needs the QoS treatment 🤷.
  3. The ability to specify the permissible degree of divergence between the actual traffic handling and the requested handling 🌈. Intserv offers two choices here: the _controlled load_ service and the _guaranteed_ service. The first allows stochastic deviation, equivalent to what you'd experience on an unloaded path of a packet network. The second conforms to the TSPEC deterministically, at the obvious expense of demanding extremely conservative resource allocation 💸.

Given the limited applicability of these capabilities in today's Internet, the author doesn't take a position on whether any of these Intserv-like capabilities are needed for ICN to be successful 🤷‍♀️. Still, a few things seem important to consider. The following paragraphs speculate about the consequences of putting these features into the CCNx or NDN protocol architectures 🔮.

Superficially, it'd be pretty straightforward to accommodate Intserv-equivalent traffic descriptions in CCNx or NDN 💖. You could define a new TLV for the Interest message to carry a TSPEC. A forwarder that sees this, together with a QoS treatment request (e.g., as proposed in Section 6.3), could associate the traffic specification with the corresponding equivalence class derived from the name in the Interest. That lets the forwarder create state that doesn't just apply to the returning Data for that Interest while it's queued on the downstream interface, but is also kept as soft state across multiple Interest/Data exchanges to drive policing and shaping algorithms at per-flow granularity 🌸. The cost in Interest message overhead would be modest. However, the complications of managing different traffic specifications in different Interests for the same equivalence class might be substantial 😵. And of course, all the scalability considerations that come with maintaining per-flow state come into play too 📈.

Similarly, it would be equally straightforward to have a way to express the degree of divergence that Intserv provides through its controlled load and guaranteed service definitions 🎯. This could be packaged with the traffic specification or encoded separately.

Versus all that, performing admission control for ICN flows is likely to be just as heavyweight as it is with IP using RSVP 🏋️. ICN's dynamic multipath, multi-destination forwarding model makes admission control particularly tricky 🙃. Just to illustrate:

  • Forwarding next-hop selection isn't confined to single paths (or a few ECMP-equivalent paths) like it is with IP, which makes it hard to know where to install state before an Interest arrives to be forwarded 🤔.
  • As with point-to-multipoint complexities when using RSVP for MPLS-TE, state has to be installed to multiple producers over multiple paths before an admission-control algorithm can commit the resources and say "yes" to a consumer that needs admission-control capabilities 🙈.
  • Knowing when to remove admission-control state is hard without a heavyweight resource reservation protocol. Soft state timeout may or may not be an adequate answer 💀.

Despite these challenges, it may be possible to craft an admission-control scheme for ICN that achieves applications' desired QoS goals without inventing and deploying a complex, separate admission-control signaling protocol 🧚‍♀️. There have been designs in earlier network architectures that could do admission control piggybacked on packet transmission.

The earliest example the author is aware of is [Autonet]. 📜

Such a scheme might have the following general shape (warning: serious hand-waving follows!) 🙈:

  • In addition to a QoS treatment and a traffic specification, an Interest requesting admission for the corresponding equivalence class would indicate this via a new TLV. It would also need to do the following: (a) indicate an expiration time after which any reserved resources can be released, and (b) indicate that caches be bypassed, so that the admission-control request arrives at a bona fide producer 🎟️.
  • Each forwarder processing the Interest would check for resource availability. If the resources aren't available, or the requested service isn't feasible, the forwarder would reject the Interest with an admission-control failure. If resources are available, the forwarder would record the traffic specification as described above and forward the Interest 📬.
  • If the Interest successfully arrives at a producer, the producer would return the requested Data 🎁.
  • Upon receiving the matching Data message, and if the resources are still available, each on-path forwarder would allocate resources and would mark the admission control TLV as "provisionally approved". Conversely, if the resource reservation fails, the admission control would be marked "failed", although the Data would still be passed downstream 🚦.
  • Upon the Data message's arrival, the consumer would know whether admission succeeded or not, and subsequent Interests could rely on the QoS state being in place until either some failure occurs or a topology or other forwarding change alters the forwarding path. To deal with this, additional machinery is needed to ensure subsequent Interests for an admitted flow either follow that path or an error is reported. One possibility (also useful in many other contexts) is to employ a _Path Steering_ mechanism, such as the one described in [Moiseenko2017] 🛤️.

8. IANA Considerations 📋

This document has no IANA actions. 🙌

9. Security Considerations 🔐

Okay, this section is serious, so listen up 🚨. There are a few ways QoS for ICN interacts with security and privacy issues. Since QoS addresses relationships among traffic rather than the inherent characteristics of traffic, it neither enhances nor degrades the security and privacy properties of the data being carried, as long as the machinery doesn't alter or otherwise compromise the basic security properties of the associated protocols. The QoS approaches advocated here for ICN can serve to amplify existing threats to network traffic. However:

  • An attacker able to manipulate the QoS treatments of traffic can mount a more focused (and potentially more effective) denial-of-service attack by suppressing performance on the traffic the attacker is targeting. Since the architecture here assumes QoS treatments are manipulable hop-by-hop, any on-path adversary can wreak havoc. Note, however, that in basic ICN, an on-path attacker can do this and more by dropping, delaying, or misrouting traffic, independent of any particular QoS machinery in use. 💀
  • When equivalence classes of traffic are explicitly revealed via either names or other fields in packets, an attacker has yet one more handle to discover the linkability of multiple requests 🕵️.

10. References 📚

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, https://www.rfc-editor.org/info/rfc8569.

[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, https://www.rfc-editor.org/info/rfc8609.

10.2. Informative References

[AS] Wikipedia, "Autonomous system (Internet)", May 2021, https://en.wikipedia.org/w/index.php?title=Autonomous_system_(Internet)&oldid=1025244754.

[Auge2018] Augé, J., Carofiglio, G., Grassi, G., Muscariello, L., Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less Producer Mobility in Content-Centric Networks", in IEEE Transactions on Network and Service Management, Vol. 15, No. 2, DOI 10.1109/TNSM.2018.2796720, June 2018, https://ieeexplore.ieee.org/document/8267132.

[Autonet] Schroeder, M., Birrell, A., Burrows, M., Murray, H., Needham, R., Rodeheffer, T., Satterthwaite, E., and C. Thacker, "Autonet: a High-speed, Self-configuring Local Area Network Using Point-to-point Links", in IEEE Journal on Selected Areas in Communications, Vol. 9, No. 8, DOI 10.1109/49.105178, October 1991, https://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-59.pdf.

[BenAbraham2018] Ben Abraham, H., Parwatikar, J., DeHart, J., Dresher, A., and P. Crowley, "Decoupling Information and Connectivity via Information-Centric Transport", in ICN '18: Proceedings of the 5th ACM Conference on Information-Centric Networking, Boston, MA, USA, DOI 10.1145/3267955.3267963, September 2018, https://conferences.sigcomm.org/acm-icn/2018/proceedings/icn18-final31.pdf. 🦋

Author's Address ✨

Dave Oran Network Systems Research and Design 4 Shady Hill Square Cambridge, MA 02138 United States of America

Email: daveoran@orandom.net 💜

📦 where this page comes from