rfc9064.original   rfc9064.txt 
ICNRG D. Oran Internet Research Task Force (IRTF) D. Oran
Internet-Draft Network Systems Research and Design Request for Comments: 9064 Network Systems Research and Design
Intended status: Informational 19 November 2020 Category: Informational June 2021
Expires: 23 May 2021 ISSN: 2070-1721
Considerations in the development of a QoS Architecture for CCNx-like Considerations in the Development of a QoS Architecture for CCNx-Like
ICN protocols Information-Centric Networking Protocols
draft-oran-icnrg-qosarch-06
Abstract Abstract
This is a position paper. It documents the author's personal views This is a position paper. It documents the author's personal views
on how Quality of Service (QoS) capabilities ought to be accommodated on how Quality of Service (QoS) capabilities ought to be accommodated
in ICN protocols like CCNx or NDN which employ flow-balanced in Information-Centric Networking (ICN) protocols like Content-
Interest/Data exchanges and hop-by-hop forwarding state as their Centric Networking (CCNx) or Named Data Networking (NDN), which
fundamental machinery. It argues that such protocols demand a employ flow-balanced Interest/Data exchanges and hop-by-hop
substantially different approach to QoS from that taken in TCP/IP, forwarding state as their fundamental machinery. It argues that such
and proposes specific design patterns to achieve both classification protocols demand a substantially different approach to QoS from that
and differentiated QoS treatment on both a flow and aggregate basis. taken in TCP/IP and proposes specific design patterns to achieve both
It also considers the effect of caches in addition to memory, CPU and classification and differentiated QoS treatment on both a flow and
link bandwidth as a resource that should be subject to explicitly aggregate basis. It also considers the effect of caches in addition
unfair resource allocation. The proposed methods are intended to to memory, CPU, and link bandwidth as resources that should be
operate purely at the network layer, providing the primitives needed subject to explicitly unfair resource allocation. The proposed
to achieve both transport and higher layer QoS objectives. It methods are intended to operate purely at the network layer,
explicitly excludes any discussion of Quality of Experience (QoE) providing the primitives needed to achieve transport- and higher-
which can only be assessed and controlled at the application layer or layer QoS objectives. It explicitly excludes any discussion of
above. Quality of Experience (QoE), which can only be assessed and
controlled at the application layer or above.
This document is not a product of the IRTF Information-Centric This document is not a product of the IRTF Information-Centric
Networking Research Group (ICNRG) but has been through formal last Networking Research Group (ICNRG) but has been through formal Last
call and has the support of the participants in the research group Call and has the support of the participants in the research group
for publication as an individual submission. for publication as an individual submission.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Research Task Force
Task Force (IETF). Note that other groups may also distribute (IRTF). The IRTF publishes the results of Internet-related research
working documents as Internet-Drafts. The list of current Internet- and development activities. These results might not be suitable for
Drafts is at https://datatracker.ietf.org/drafts/current/. deployment. This RFC represents the individual opinion(s) of one or
more members of the Information-Centric Networking Research Group of
the Internet Research Task Force (IRTF). Documents approved for
publication by the IRSG are not a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9064.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Applicability Assessment by ICNRG Chairs . . . . . . . . 4 1.1. Applicability Assessment by ICNRG Chairs
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language
3. Background on Quality of Service in network protocols . . . . 4 3. Background on Quality of Service in Network Protocols
3.1. Basics on how ICN protocols like NDN and CCNx work . . . 7 3.1. Basics on How ICN Protocols like NDN and CCNx Work
3.2. Congestion Control basics relevant to ICN . . . . . . . . 8 3.2. Congestion Control Basics Relevant to ICN
4. What can we control to achieve QoS in ICN? . . . . . . . . . 10 4. What Can We Control to Achieve QoS in ICN?
5. How does this relate to QoS in TCP/IP? . . . . . . . . . . . 11 5. How Does This Relate to QoS in TCP/IP?
6. Why is ICN Different? Can we do Better? . . . . . . . . . . 13 6. Why Is ICN Different? Can We Do Better?
6.1. Equivalence class capabilities . . . . . . . . . . . . . 13 6.1. Equivalence Class Capabilities
6.2. Topology interactions with QoS . . . . . . . . . . . . . 13 6.2. Topology Interactions with QoS
6.3. Specification of QoS treatments . . . . . . . . . . . . . 14 6.3. Specification of QoS Treatments
6.4. ICN forwarding semantics effect on QoS . . . . . . . . . 15 6.4. ICN Forwarding Semantics Effect on QoS
6.5. QoS interactions with Caching . . . . . . . . . . . . . . 16 6.5. QoS Interactions with Caching
7. Strawman principles for an ICN QoS architecture . . . . . . . 16 7. Strawman Principles for an ICN QoS Architecture
7.1. Can Intserv-like traffic control in ICN provide richer QoS 7.1. Can Intserv-Like Traffic Control in ICN Provide Richer QoS
semantics? . . . . . . . . . . . . . . . . . . . . . . . 20 Semantics?
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References
10.2. Informative References . . . . . . . . . . . . . . . . . 23 10.2. Informative References
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address
1. Introduction 1. Introduction
The TCP/IP protocol suite used on today's Internet has over 30 years The TCP/IP protocol suite used on today's Internet has over 30 years
of accumulated research and engineering into the provision of Quality of accumulated research and engineering into the provisioning of QoS
of Service machinery, employed with varying success in different machinery, employed with varying success in different environments.
environments. ICN protocols like Named Data Networking (NDN [NDN]) ICN protocols like NDN [NDN] and CCNx [RFC8569] [RFC8609] have an
and Content-Centric Networking (CCNx [RFC8569],[RFC8609]) have an accumulated ten years of research and very little deployment. We
accumulated 10 years of research and very little deployment. We
therefore have the opportunity to either recapitulate the approaches therefore have the opportunity to either recapitulate the approaches
taken with TCP/IP (e.g. Intserv [RFC2998] and Diffserv [RFC2474]) or taken with TCP/IP (e.g., Intserv [RFC2998] and Diffserv [RFC2474]) or
design a new architecture and associated mechanisms aligned with the design a new architecture and associated mechanisms aligned with the
properties of ICN protocols which differ substantially from those of properties of ICN protocols, which differ substantially from those of
TCP/IP. This position paper advocates the latter approach and TCP/IP. This position paper advocates the latter approach and
comprises the author's personal views on how Quality of Service (QoS) comprises the author's personal views on how QoS capabilities ought
capabilities ought to be accommodated in ICN protocols like CCNx or to be accommodated in ICN protocols like CCNx or NDN. Specifically,
NDN. Specifically, these protocols differ in fundamental ways from these protocols differ in fundamental ways from TCP/IP. The
TCP/IP. The important differences are summarized in the following important differences are summarized in Table 1:
table:
+=============================+====================================+ +=============================+====================================+
| TCP/IP | CCNx or NDN | | TCP/IP | CCNx or NDN |
+=============================+====================================+ +=============================+====================================+
| Stateless forwarding | Stateful forwarding | | Stateless forwarding | Stateful forwarding |
+-----------------------------+------------------------------------+ +-----------------------------+------------------------------------+
| Simple Packets | Object model with optional caching | | Simple packets | Object model with optional caching |
+-----------------------------+------------------------------------+ +-----------------------------+------------------------------------+
| Pure datagram model | Request-response model | | Pure datagram model | Request-response model |
+-----------------------------+------------------------------------+ +-----------------------------+------------------------------------+
| Asymmetric Routing | Symmetric Routing | | Asymmetric routing | Symmetric routing |
+-----------------------------+------------------------------------+ +-----------------------------+------------------------------------+
| Independent flow directions | Flow balance^(*) | | Independent flow directions | Flow balance (see note below) |
+-----------------------------+------------------------------------+ +-----------------------------+------------------------------------+
| Flows grouped by IP prefix | Flows grouped by name prefix | | Flows grouped by IP prefix | Flows grouped by name prefix |
| and port | | | and port | |
+-----------------------------+------------------------------------+ +-----------------------------+------------------------------------+
| End-to-end congestion | Hop-by-hop congestion control | | End-to-end congestion | Hop-by-hop congestion control |
| control | | | control | |
+-----------------------------+------------------------------------+ +-----------------------------+------------------------------------+
Table 1: Differences between IP and ICN relevant to QoS architecture Table 1: Differences between IP and ICN Relevant to QoS Architecture
| ^(*)Flow Balance is a property of NDN and CCNx that ensures one | Note: Flow balance is a property of NDN and CCNx that ensures
| Interest packet provokes a response of no more than one data | one Interest packet provokes a response of no more than one
| packet. Further discussion of the relevance of this to QoS can | Data packet. Further discussion of the relevance of this to
| be found in [I-D.oran-icnrg-flowbalance] | QoS can be found in [FLOWBALANCE].
This document proposes specific design patterns to achieve both flow This document proposes specific design patterns to achieve both flow
classification and differentiated QoS treatment for ICN on both a classification and differentiated QoS treatment for ICN on both a
flow and aggregate basis. It also considers the effect of caches in flow and aggregate basis. It also considers the effect of caches in
addition to memory, CPU and link bandwidth as a resource that should addition to memory, CPU, and link bandwidth as resources that should
be subject to explicitly unfair resource allocation. The proposed be subject to explicitly unfair resource allocation. The proposed
methods are intended to operate purely at the network layer, methods are intended to operate purely at the network layer,
providing the primitives needed to achieve both transport and higher providing the primitives needed to achieve both transport and higher-
layer QoS objectives. It does not propose detailed protocol layer QoS objectives. It does not propose detailed protocol
machinery to achieve these goals; it leaves these to supplementary machinery to achieve these goals; it leaves these to supplementary
specifications, such as [I-D.moiseenko-icnrg-flowclass] and specifications, such as [FLOWCLASS] and [DNC-QOS-ICN]. It explicitly
[I-D.anilj-icnrg-dnc-qos-icn]. It explicitly excludes any discussion excludes any discussion of QoE, which can only be assessed and
of Quality of Experience (QoE) which can only be assessed and
controlled at the application layer or above. controlled at the application layer or above.
Much of this document is derived from presentations the author has Much of this document is derived from presentations the author has
given at ICNRG meetings over the last few years that are available given at ICNRG meetings over the last few years that are available
through the IETF datatracker (see, for example [Oran2018QoSslides]). through the IETF datatracker (see, for example, [Oran2018QoSslides]).
1.1. Applicability Assessment by ICNRG Chairs 1.1. Applicability Assessment by ICNRG Chairs
QoS in ICN is an important topic with a huge design space. ICNRG has QoS in ICN is an important topic with a huge design space. ICNRG has
been discussing different specific protocol mechanisms as well as been discussing different specific protocol mechanisms as well as
conceptual approaches. This document presents architectural conceptual approaches. This document presents architectural
considerations for QoS, leveraging ICN properties instead of merely considerations for QoS, leveraging ICN properties instead of merely
applying IP-QoS mechanisms - without defining a specific architecture applying IP-QoS mechanisms, without defining a specific architecture
or specific protocols mechanisms yet. However, there is consensus in or specific protocol mechanisms yet. However, there is consensus in
ICNRG that this document, clarifying the author's views, could ICNRG that this document, clarifying the author's views, could
inspire such work and should hence be published as a position paper. inspire such work and should hence be published as a position paper.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "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.
3. Background on Quality of Service in network protocols 3. Background on Quality of Service in Network Protocols
Much of this background material is tutorial and can be simply Much of this background material is tutorial and can be simply
skipped by readers familiar with the long and checkered history of skipped by readers familiar with the long and checkered history of
quality of service in packet networks. Other parts of it are quality of service in packet networks. Other parts of it are
polemical yet serve to illuminate the author's personal biases and polemical yet serve to illuminate the author's personal biases and
technical views. technical views.
All networking systems provide some degree of "quality of service" in All networking systems provide some degree of "quality of service" in
that they exhibit non-zero utility when offered traffic to carry. In that they exhibit nonzero utility when offered traffic to carry. In
other words, the network is totally useless if it never delivers any other words, the network is totally useless if it never delivers any
of the traffic injected by applications. The term QoS is therefore of the traffic injected by applications. The term QoS is therefore
more correctly applied in a more restricted sense to describe systems more correctly applied in a more restricted sense to describe systems
that control the allocation of various resources in order to achieve that control the allocation of various resources in order to achieve
_managed unfairness_. Absent explicit mechanisms to decide what _managed unfairness_. Absent explicit mechanisms to decide which
traffic to be unfair to, most systems try to achieve some form of traffic to treat unfairly, most systems try to achieve some form of
"fairness" in the allocation of resources, optimizing the overall "fairness" in the allocation of resources, optimizing the overall
utility delivered to all offered load under the constraint of utility delivered to all traffic under the constraint of available
available resources. From this it should be obvious that you cannot resources. From this, it should be obvious that you cannot use QoS
use QoS mechanisms to create or otherwise increase resource capacity! mechanisms to create or otherwise increase resource capacity! In
In fact, all known QoS schemes have non-zero overhead and hence may fact, all known QoS schemes have nonzero overhead and hence may
(albeit slightly) decrease the total resources available to carry (albeit slightly) decrease the total resources available to carry
user traffic. user traffic.
Further, accumulated experience seems to indicate that QoS is helpful Further, accumulated experience seems to indicate that QoS is helpful
in a fairly narrow range of network conditions: in a fairly narrow range of network conditions:
* If your resources are lightly loaded, you don't need it, as * If your resources are lightly loaded, you don't need it, as
neither congestive loss nor substantial queueing delay occurs neither congestive loss nor substantial queuing delay occurs.
* If your resources are heavily oversubscribed, it doesn't save you. * If your resources are heavily oversubscribed, it doesn't save you.
So many users will be unhappy that you are probably not delivering So many users will be unhappy that you are probably not delivering
a viable service a viable service.
* Failures can rapidly shift your state from the first above to the * Failures can rapidly shift your state from the first above to the
second, in which case either: second, in which case either:
- your QoS machinery cannot respond quickly enough to maintain - Your QoS machinery cannot respond quickly enough to maintain
the advertised service quality continuously, or the advertised service quality continuously, or
- resource allocations are sufficiently conservative to result in - Resource allocations are sufficiently conservative to result in
substantial wasted capacity under non-failure conditions substantial wasted capacity under non-failure conditions.
Nevertheless, though not universally deployed, QoS is advantageous at Nevertheless, though not universally deployed, QoS is advantageous at
least for some applications and some network environments. Some least for some applications and some network environments. Some
examples include: examples include:
* applications with steep utility functions [Shenker2006], such as * Applications with steep utility functions [Shenker2006], such as
real-time multimedia real-time multimedia
* applications with safety-critical operational constraints, such as * Applications with safety-critical operational constraints, such as
avionics or industrial automation avionics or industrial automation
* dedicated or tightly managed networks whose economics depend on * Dedicated or tightly managed networks whose economics depend on
strict adherence to challenging service level agreements (SLAs) strict adherence to challenging service level agreements (SLAs)
Another factor in the design and deployment of QoS is the scalability Another factor in the design and deployment of QoS is the scalability
and scope over which the desired service can be achieved. Here there and scope over which the desired service can be achieved. Here there
are two major considerations, one technical, the other economic/ are two major considerations, one technical, the other economic/
political: political:
* Some signaled QoS schemes, such as RSVP (Resource reSerVation * Some signaled QoS schemes, such as the Resource reSerVation
Protocol) [RFC2205], maintain state in routers for each flow, Protocol (RSVP) [RFC2205], maintain state in routers for each
which scales linearly with the number of flows. For core routers flow, which scales linearly with the number of flows. For core
through which pass millions to billions of flows, the memory routers through which pass millions to billions of flows, the
required is infeasible to provide. memory required is infeasible to provide.
* The Internet is comprised of many minimally cooperating autonomous * The Internet is comprised of many minimally cooperating autonomous
systems [AS]. There are practically no successful examples of QoS systems [AS]. There are practically no successful examples of QoS
deployments crossing the AS boundaries of multiple service deployments crossing the AS boundaries of multiple service
providers. This in almost all cases limits the applicability of providers. In almost all cases, this limits the applicability of
QoS capabilities to be intra-domain. QoS capabilities to be intra-domain.
This document adopts a narrow definition of QoS as _managed This document adopts a narrow definition of QoS as _managed
unfairness_^(*). However, much of the networking literature uses the unfairness_ (see note below). However, much of the networking
term more colloquially as applying to any mechanism that improves literature uses the term more colloquially, applying it to any
overall performance. One could use a different, broader definition mechanism that improves overall performance. One could use a
of QoS that encompasses optimizing the allocation of network different, broader definition of QoS that encompasses optimizing the
resources across all offered traffic without considering individual allocation of network resources across all offered traffic without
users' traffic. A consequence would be the need to cover whether considering individual users' traffic. A consequence would be the
(and how) ICN might result in better overall performance than IP need to cover whether (and how) ICN might result in better overall
under constant resource conditions, which is a much broader goal than performance than IP under constant resource conditions, which is a
that attempted here. The chosen narrower scope comports with the much broader goal than that attempted here. The chosen narrower
commonly understood meaning of "QoS" in the research community. scope comports with the commonly understood meaning of "QoS" in the
Under this scope, and under constant resource constraints, the only research community. Under this scope, and under constant resource
way to provide traffic discrimination is in fact to sacrifice constraints, the only way to provide traffic discrimination is in
fairness. Readers assuming the broader context will find a large fact to sacrifice fairness. Readers assuming the broader context
class of proven techniques to be ignored. This is intentional. will find a large class of proven techniques to be ignored. This is
Among these are seamless producer mobility schemes like MAPME intentional. Among these are seamless producer mobility schemes like
[Auge2018], and network coding of ICN data as discussed in MAP-Me [Auge2018] and network coding of ICN data as discussed in
[I-D.irtf-nwcrg-nwc-ccn-reqs]. [NWC-CCN-REQS].
| ^(*)This term to explain QoS is generally ascribed to Van | Note: The term _managed unfairness_ used to explain QoS is
| Jacobson, who in talks in the late 1990's said "[The problem we | generally ascribed to Van Jacobson, who in talks in the late
| are solving is to] Give 'better' service to some at the expense | 1990s said, "[The problem we are solving is to] Give 'better'
| of giving worse service to others. QoS fantasies to the | service to some at the expense of giving worse service to
| contrary, it's a zero sum game. In other words, QoS is | others. QoS fantasies to the contrary, it's a zero-sum game.
| _managed unfairness_." | In other words, QoS is _managed unfairness_."
Finally, the relationship between QoS and either accounting or Finally, the relationship between QoS and either accounting or
billing is murky. Some schemes can accurately account for resource billing is murky. Some schemes can accurately account for resource
consumption and ascertain to which user to allocate the usage. consumption and ascertain to which user to allocate the usage.
Others cannot. While the choice of mechanism may have important Others cannot. While the choice of mechanism may have important
practical economic and political consequences for cost and workable practical economic and political consequences for cost and workable
business models, this document considers none of those things and business models, this document considers none of those things and
discusses QoS only in the context of providing managed unfairness. discusses QoS only in the context of providing managed unfairness.
For those unfamiliar with ICN protocols, a brief description of how For those unfamiliar with ICN protocols, a brief description of how
NDN and CCNx operate as a packet network is below in Section 3.1. NDN and CCNx operate as a packet network is in Section 3.1. Some
Some further background on congestion control for ICN follows in further background on congestion control for ICN follows in
Section 3.2. Section 3.2.
3.1. Basics on how ICN protocols like NDN and CCNx work 3.1. Basics on How ICN Protocols like NDN and CCNx Work
The following is intended as a brief summary of the salient features The following summarizes the salient features of the NDN and CCNx ICN
of the NDN and CCnx ICN protocols relevant to congestion control and protocols relevant to congestion control and QoS. Quite extensive
QoS. Quite extensive tutorial information may be found in a number tutorial information may be found in a number of places, including
of places including material available from [NDNTutorials]. material available from [NDNTutorials].
In NDN and CCNx, all protocol interactions operate as a two-way In NDN and CCNx, all protocol interactions operate as a two-way
handshake. Named content is requested by a _consumer_ via an handshake. Named content is requested by a _consumer_ via an
_Interest message_ which is routed hop-by-hop through a series of _Interest message_ that is routed hop-by-hop through a series of
_forwarders_ until it reaches a node that stores the requested data. _forwarders_ until it reaches a node that stores the requested data.
This can be either the _producer_ of the data, or a forwarder holding 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 a cached copy of the requested data. The content matching the name
in the Interest is returned to the requester over the _inverse_ of in the Interest message is returned to the requester over the
the path traversed by the corresponding Interest. _inverse_ of the path traversed by the corresponding Interest.
Forwarding in CCNx and NDN is _per-packet stateful_. Routing Forwarding in CCNx and NDN is _per-packet stateful_. Routing
information to select next-hops for an Interest is obtained from a information to select next hop(s) for an Interest is obtained from a
_Forwarding Information Base (FIB)_ which is similar in function to _Forwarding Information Base (FIB)_, which is similar in function to
the FIB in an IP router, except that it holds name prefixes rather the FIB in an IP router except that it holds name prefixes rather
than IP address prefixes. Conventionally a _Longest Name Prefix than IP address prefixes. Conventionally, a _Longest Name Prefix
Match (LNPM)_ is used for lookup, although other algorithms are Match (LNPM)_ is used for lookup, although other algorithms are
possible including controlled flooding and adaptive learning based on possible, including controlled flooding and adaptive learning based
prior history. on prior history.
Each Interest message leaves a trail of "breadcrumbs" as state in Each Interest message leaves a trail of "breadcrumbs" as state in
each forwarder. This state, held in a data structure known as a each forwarder. This state, held in a data structure known as a
_Pending Interest Table (PIT)_ is used to forward the returning Data _Pending Interest Table (PIT)_, is used to forward the returning Data
message to the consumer. Since the PIT constitutes per-packet state message to the consumer. Since the PIT constitutes per-packet state,
it is therefore a large consumer of memory resources especially in it is therefore a large consumer of memory resources, especially in
forwarders carrying high traffic loads over long Round Trip Time forwarders carrying high traffic loads over long Round-Trip Time
(RTT) paths, and hence plays a substantial role as a QoS-controllable (RTT) paths, and hence plays a substantial role as a QoS-controllable
resource in ICN forwarders. resource in ICN forwarders.
In addition to its role in forwarding Interest messages and returning In addition to its role in forwarding Interest messages and returning
the corresponding Data messages, an ICN forwarder can also operate as the corresponding Data messages, an ICN forwarder can also operate as
a cache, optionally storing a copy of any Data messages it has seen 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 in a local data structure known as a _Content Store (CS)_. Data in
the Content Store may be returned in response to a matching Interest the CS may be returned in response to a matching Interest rather than
rather than forwarding the Interest further through the network to forwarding the Interest further through the network to the original
the original Producer. Both CCNx and NDN have a variety of ways to Producer. Both CCNx and NDN have a variety of ways to configure
configure caching, including mechanisms to avoid both cache pollution caching, including mechanisms to avoid both cache pollution and cache
and cache poisoning (these are clearly beyond the scope of this brief poisoning (these are clearly beyond the scope of this brief
introduction). introduction).
3.2. Congestion Control basics relevant to ICN 3.2. Congestion Control Basics Relevant to ICN
In any packet network that multiplexes traffic among multiple sources In any packet network that multiplexes traffic among multiple sources
and destinations, congestion control is necessary in order to: and destinations, congestion control is necessary in order to:
1. Prevent collapse of utility due to overload, where the total 1. Prevent collapse of utility due to overload, where the total
offered service declines as load increases, perhaps offered service declines as load increases, perhaps
precipitously, rather than increasing or remaining flat. precipitously, rather than increasing or remaining flat.
2. Avoid starvation of some traffic due to excessive demand by other 2. Avoid starvation of some traffic due to excessive demand by other
traffic. traffic.
3. Beyond the basic protections against starvation, achieve 3. Beyond the basic protections against starvation, achieve
"fairness" among competing traffic. Two common objective "fairness" among competing traffic. Two common objective
functions are [minmaxfairness] and [proportionalfairness] both of functions are max-min fairness [minmaxfairness] and proportional
which have been implemented and deployed successfully on packet fairness [proportionalfairness], both of which have been
networks for many years. implemented and deployed successfully on packet networks for many
years.
Before moving on to QoS, it is useful to consider how congestion Before moving on to QoS, it is useful to consider how congestion
control works in NDN or CCNx. Unlike the IP protocol family, which control works in NDN or CCNx. Unlike the IP protocol family, which
relies exclusively on end-to-end congestion control (e.g. relies exclusively on end-to-end congestion control (e.g., TCP
TCP[RFC0793], DCCP[RFC4340], SCTP[RFC4960], [RFC0793], DCCP [RFC4340], SCTP [RFC4960], and QUIC [RFC9000]), CCNx
QUIC[I-D.ietf-quic-transport]), CCNx and NDN can employ hop-by-hop and NDN can employ hop-by-hop congestion control. There is per-
congestion control. There is per-Interest/Data state at every hop of Interest/Data state at every hop of the path, and therefore
the path and therefore outstanding Interests provide information that outstanding Interests provide information that can be used to
can be used to optimize resource allocation for data returning on the optimize resource allocation for data returning on the inverse path,
inverse path, such as bandwidth sharing, prioritization and overload such as bandwidth sharing, prioritization, and overload control. In
control. In current designs, this allocation is often done using current designs, this allocation is often done using Interest
Interest counting. By accepting one Interest packet from a counting. By accepting one Interest packet from a downstream node,
downstream node, implicitly this provides a guarantee (either hard or this implicitly provides a guarantee (either hard or soft) that there
soft) that there is sufficient bandwidth on the inverse direction of is sufficient bandwidth on the inverse direction of the link to send
the link to send back one Data packet. A number of congestion back one Data packet. A number of congestion control schemes have
control schemes have been developed for ICN that operate in this been developed for ICN that operate in this fashion, for example,
fashion, for example [Wang2013], [Mahdian2016], [Song2018], [Wang2013], [Mahdian2016], [Song2018], and [Carofiglio2012]. Other
[Carofiglio2012]. Other schemes, like [Schneider2016] neither count schemes, like [Schneider2016], neither count nor police Interests but
nor police Interests, but instead monitor queues using AQM (active instead monitor queues using AQM (active queue management) to mark
queue management) to mark returning Data packets that have returning Data packets that have experienced congestion. This later
experienced congestion. This later class of schemes is similar to class of schemes is similar to those used on IP in the sense that
those used on IP in the sense that they depend on consumers they depend on consumers adequately reducing their rate of Interest
adequately reducing their rate of Interest injection to avoid Data injection to avoid Data packet drops due to buffer overflow in
packet drops due to buffer overflow in forwarders. The former class forwarders. The former class of schemes is (arguably) more robust
of schemes is (arguably) more robust against mis-behavior by against misbehavior by consumers.
consumers.
Given the stochastic nature of round trip times, and the ubiquity of Given the stochastic nature of RTTs, and the ubiquity of wireless
wireless links and encapsulation tunnels with variable bandwidth, a links and encapsulation tunnels with variable bandwidth, a simple
simple scheme that admits interests only based on a time-invariant scheme that admits Interests only based on a time-invariant estimate
estimate of the returning link bandwidth will perform poorly. of the returning link bandwidth will perform poorly. However, two
However, two characteristics of NDN and CCNx-like protocols can help characteristics of NDN and CCNx-like protocols can help substantially
substantially to improve the accuracy and responsiveness of the to improve the accuracy and responsiveness of the bandwidth
bandwidth allocation: allocation:
1. RTT is bounded by the inclusion of an _Interest Lifetime_ in each 1. RTT is bounded by the inclusion of an _Interest Lifetime_ in each
Interest message, which puts an upper bound on the RTT Interest message, which puts an upper bound on the RTT
uncertainty for any given Interest/Data exchange. If Interest uncertainty for any given Interest/Data exchange. If Interest
lifetimes are kept reasonably short (a few RTTs) the allocation Lifetimes are kept reasonably short (a few RTTs), the allocation
of local forwarder resources do not have to deal with an of local forwarder resources do not have to deal with an
arbitrarily long tail. One could in fact do a deterministic arbitrarily long tail. One could in fact do a deterministic
allocation on this basis, but the result would be highly allocation on this basis, but the result would be highly
pessimistic. Nevertheless, having a cut-off does improve the pessimistic. Nevertheless, having a cutoff does improve the
performance of an optimistic allocation scheme. performance of an optimistic allocation scheme.
2. Returning Data packets can be congestion marked by an ECN-like 2. A congestion marking scheme like that used in Explicit Congestion
marking scheme if the inverse link starts experiencing long queue Notification (ECN) can be used to mark returning Data packets if
occupancy or other congestion indication. Unlike TCP/IP, where the inverse link starts experiencing long queue occupancy or
the rate adjustment can only be done end-to-end, this feedback is other congestion indication. Unlike TCP/IP, where the rate
usable immediately by the downstream ICN forwarder and the adjustment can only be done end-to-end, this feedback is usable
Interest shaping rate lowered after a single link RTT. This may immediately by the downstream ICN forwarder, and the Interest
allow less pessimistic rate adjustment schemes than the Additive shaping rate is lowered after a single link RTT. This may allow
Increase, Multiplicative Decrease (AIMD) with .5 multiplier that rate adjustment schemes that are less pessimistic than the
is commonly used on TCP/IP networks. It also allows the rate Additive Increase, Multiplicative Decrease (AIMD) scheme with .5
adjustments to be spread more accurately among the Interest/Data multiplier that is commonly used on TCP/IP networks. It also
flows traversing a link sending congestion signals. allows the rate adjustments to be spread more accurately among
the Interest/Data flows traversing a link sending congestion
signals.
A useful discussion of these properties and how they demonstrate the A useful discussion of these properties and how they demonstrate the
advantages of ICN approaches to congestion control can be found in advantages of ICN approaches to congestion control can be found in
[Carofiglio2016] [Carofiglio2016].
4. What can we control to achieve QoS in ICN? 4. What Can We Control to Achieve QoS in ICN?
QoS is achieved through managed unfairness in the allocation of QoS is achieved through managed unfairness in the allocation of
resources in network elements, particularly in the routers doing resources in network elements, particularly in the routers that
forwarding of ICN packets. So, a first order question is what forward ICN packets. Hence, the first-order questions are the
resources need to be allocated, and how to ascertain which traffic following: Which resources need to be allocated? How do you
gets what allocations. In the case of CCNx or NDN the important ascertain which traffic gets those allocations? In the case of CCNx
network element resources are: or NDN, the important network element resources are given in Table 2:
+===============+===============================================+ +=============================+===================================+
| Resource | ICN Usage | | Resource | ICN Usage |
+===============+===============================================+ +=============================+===================================+
| Communication | buffering for queued packets | | Communication link capacity | buffering for queued packets |
| Link capacity | | +-----------------------------+-----------------------------------+
+---------------+-----------------------------------------------+ | CS capacity | to hold cached data |
| Content Store | to hold cached data | +-----------------------------+-----------------------------------+
| capacity | | | Forwarder memory | for the PIT |
+---------------+-----------------------------------------------+ +-----------------------------+-----------------------------------+
| Forwarder | for the Pending Interest Table (PIT) | | Compute capacity | for forwarding packets, including |
| memory | | | | the cost of FIB lookups |
+---------------+-----------------------------------------------+ +-----------------------------+-----------------------------------+
| Compute | for forwarding packets, including the cost of |
| capacity | Forwarding Information Base (FIB) lookups. |
+---------------+-----------------------------------------------+
Table 2: ICN-related Network Element Resources Table 2: ICN-Related Network Element Resources
For these resources, any QoS scheme has to specify two things: For these resources, any QoS scheme has to specify two things:
1. How do you create _equivalence classes_ (a.k.a. flows) of traffic 1. How do you create _equivalence classes_ (a.k.a. flows) of traffic
to which different QoS treatments are applied? to which different QoS treatments are applied?
2. What are the possible treatments and how are those mapped to the 2. What are the possible treatments and how are those mapped to the
resource allocation algorithms? resource allocation algorithms?
Two critical facts of life come into play when designing a QoS Two critical facts of life come into play when designing a QoS
scheme. First, the number of equivalence classes that can be scheme. First, the number of equivalence classes that can be
simultaneously tracked in a network element is bounded by both memory simultaneously tracked in a network element is bounded by both memory
and processing capacity to do the necessary lookups. One can allow and processing capacity to do the necessary lookups. One can allow
very fine-grained equivalence classes, but not be able to employ them very fine-grained equivalence classes but not be able to employ them
globally because of scaling limits of core routers. That means it is globally because of scaling limits of core routers. That means it is
wise to either restrict the range of equivalence classes, or allow wise to either restrict the range of equivalence classes or allow
them to be _aggregated_, trading off accuracy in policing traffic them to be _aggregated_, trading off accuracy in policing traffic
against ability to scale. against ability to scale.
Second, the flexibility of expressible treatments can be tightly Second, the flexibility of expressible treatments can be tightly
constrained by both protocol encoding and algorithmic limitations. constrained by both protocol encoding and algorithmic limitations.
The ability to encode the treatment requests in the protocol can be The ability to encode the treatment requests in the protocol can be
limited (as it is for IP - there are only 6 of the Type of Service limited -- as it is for IP where there are only six of the Type of
(TOS) bits available for Diffserv treatments), but as or more Service (TOS) bits available for Diffserv treatments. However, an
important is whether there are practical traffic policing, queuing, equal or more important issue is whether there are practical traffic
and pacing algorithms that can be combined to support a rich set of policing, queuing, and pacing algorithms that can be combined to
QoS treatments. support a rich set of QoS treatments.
The two considerations above in combination can easily be The two considerations above in combination can easily be
substantially more expressive than what can be achieved in practice substantially more expressive than what can be achieved in practice
with the available number of queues on real network interfaces or the with the available number of queues on real network interfaces or the
amount of per-packet computation needed to enqueue or dequeue a amount of per-packet computation needed to enqueue or dequeue a
packet. packet.
5. How does this relate to QoS in TCP/IP? 5. How Does This Relate to QoS in TCP/IP?
TCP/IP has fewer resource types to manage than ICN, and in some cases TCP/IP has fewer resource types to manage than ICN, and in some
the allocation methods are simpler, as shown in the following table: cases, the allocation methods are simpler, as shown in Table 3:
+===============+=============+================================+ +===============+=============+================================+
| Resource | IP Relevant | TCP/IP Usage | | Resource | IP Relevant | TCP/IP Usage |
+===============+=============+================================+ +===============+=============+================================+
| Communication | YES | buffering for queued packets | | Communication | YES | buffering for queued packets |
| Link capacity | | | | link capacity | | |
+---------------+-------------+--------------------------------+ +---------------+-------------+--------------------------------+
| Content Store | NO | no content store in IP | | CS capacity | NO | no CS in IP |
| capacity | | |
+---------------+-------------+--------------------------------+ +---------------+-------------+--------------------------------+
| Forwarder | MAYBE | not needed for output-buffered | | Forwarder | MAYBE | not needed for output-buffered |
| memory | | designs^(*) | | memory | | designs (see note below) |
+---------------+-------------+--------------------------------+ +---------------+-------------+--------------------------------+
| Compute | YES | for forwarding packets, but | | Compute | YES | for forwarding packets, but |
| capacity | | arguably much cheaper than ICN | | capacity | | arguably much cheaper than ICN |
+---------------+-------------+--------------------------------+ +---------------+-------------+--------------------------------+
Table 3: IP-related Network Element Resources Table 3: IP-Related Network Element Resources
^(*)Output-buffered designs are where all packet buffering resources | Note: In an output-buffered design, all packet buffering
are associated with the output interfaces and there are no receiver | resources are associated with the output interfaces, and
interface or internal forwarding buffers that can be over-subscribed. | neither the receiver interface nor the internal forwarding
Output-buffered switchs or routers are common but not universal, as | buffers can be over-subscribed. Output-buffered switches or
they generally require an internal speed-up factor where forwarding | routers are common but not universal, as they generally require
capacity is greater than the sum of the input capacity of the | an internal speedup factor where forwarding capacity is greater
interfaces. | than the sum of the input capacity of the interfaces.
For these resources, IP has specified three fundamental things, as For these resources, IP has specified three fundamental things, as
shown in the following table: shown in Table 4:
+==============+====================================================+ +=============+====================================================+
| What | How | | What | How |
+==============+====================================================+ +=============+====================================================+
| *Equivalence | subset+prefix match on IP | | Equivalence | subset+prefix match on IP 5-tuple {SA,DA,SP,DP,PT} |
| classes* | 5-tuple {SA,DA,SP,DP,PT} | | classes | SA=Source Address |
| | SA=Source Address | | | DA=Destination Address |
| | DA=Destination Address | | | SP=Source Port |
| | SP=Source Port | | | DP=Destination Port |
| | DP=Desintation Port | | | PT=IP Protocol Type |
| | PT=IP Protocol Type | +-------------+----------------------------------------------------+
+--------------+----------------------------------------------------+ | Diffserv | (very) small number of globally-agreed traffic |
| *Diffserv | (very) small number of | | treatments | classes |
| treatments* | globally-agreed traffic | +-------------+----------------------------------------------------+
| | classes | | Intserv | per-flow parameterized _Controlled Load_ and |
+--------------+----------------------------------------------------+ | treatments | _Guaranteed_ service classes |
| *Intserv | per-flow parameterized | +-------------+----------------------------------------------------+
| treatments* | _Controlled Load_ and |
| | _Guaranteed_ service |
| | classes |
+--------------+----------------------------------------------------+
Table 4: Fundamental protocol elements to achieve QoS for TCP/IP Table 4: Fundamental Protocol Elements to Achieve QoS for TCP/IP
Equivalence classes for IP can be pairwise, by matching against both Equivalence classes for IP can be pairwise, by matching against both
source and destination address+port, pure group using only source and destination address+port, pure group using only
destination address+port, or source-specific multicast with source destination address+port, or source-specific multicast with source
adress+port and destination multicast address+port. address+port and destination multicast address+port.
With Intserv, the Resource ReSerVation signaling protocol (RSVP) With Intserv, RSVP [RFC2205] carries two data structures: the Flow
[RFC2205] carries two data structures, the Flow Specifier (FLOWSPEC) Specifier (FLOWSPEC) and the Traffic Specifier (TSPEC). The former
and the Traffic Specifier (TSPEC). The former fulfills the fulfills the requirement to identify the equivalence class to which
requirement to identify the equivalence class to which the QoS being the QoS being signaled applies. The latter comprises the desired QoS
signaled applies. The latter comprises the desired QoS treatment treatment along with a description of the dynamic character of the
along with a description of the dynamic character of the traffic traffic (e.g., average bandwidth and delay, peak bandwidth, etc.).
(e.g. average bandwidth and delay, peak bandwidth, etc.). Both of Both of these encounter substantial scaling limits, which has meant
these encounter substantial scaling limits, which has meant that that Intserv has historically been limited to confined topologies,
Intserv has historically been limited to confined topologies, and/or and/or high-value usages, like traffic engineering.
high-value usages, like traffic engineering.
With Diffserv, the protocol encoding (6 bits in the TOS field of the With Diffserv, the protocol encoding (six bits in the TOS field of
IP header) artificially limits the number of classes one can specify. the IP header) artificially limits the number of classes one can
These are documented in [RFC4594]. Nonetheless, when used with fine- specify. These are documented in [RFC4594]. Nonetheless, when used
grained equivalence classes, one still runs into limits on the number with fine-grained equivalence classes, one still runs into limits on
of queues required. the number of queues required.
6. Why is ICN Different? Can we do Better? 6. Why Is ICN Different? Can We Do Better?
While one could adopt an approach to QoS mirroring the extensive While one could adopt an approach to QoS that mirrors the extensive
experience with TCP/IP, this would, in the author's view, be a experience with TCP/IP, this would, in the author's view, be a
mistake. The implementation and deployment of QoS in IP networks has mistake. The implementation and deployment of QoS in IP networks has
been spotty at best. There are of course economic and political been spotty at best. There are, of course, economic and political
reasons as well as technical reasons for these mixed results, but reasons as well as technical reasons for these mixed results, but
there are several architectural choices in ICN that make it a there are several architectural choices in ICN that make it a
potentially much better protocol base to enhance with QoS machinery. potentially much better protocol base to enhance with QoS machinery.
This section discusses those differences and their consequences. This section discusses those differences and their consequences.
6.1. Equivalence class capabilities 6.1. Equivalence Class Capabilities
First and foremost, hierarchical names are a much richer basis for First and foremost, hierarchical names are a much richer basis for
specifying equivalence classes than IP 5-tuples. The IP address (or specifying equivalence classes than IP 5-tuples. The IP address (or
prefix) can only separate traffic by topology to the granularity of prefix) can only separate traffic by topology to the granularity of
hosts, and not express actual computational instances nor sets of hosts and cannot express actual computational instances nor sets of
data. Ports give some degree of per-instance demultiplexing, but data. Ports give some degree of per-instance demultiplexing, but
this tends to be both coarse and ephemeral, while confounding the this tends to be both coarse and ephemeral, while confounding the
demultiplexing function with the assignment of QoS treatments to demultiplexing function with the assignment of QoS treatments to
particular subsets of the data. Some degree of finer granularity is particular subsets of the data. Some degree of finer granularity is
possible with IPv6 by exploiting the ability to use up to 64 bits of possible with IPv6 by exploiting the ability to use up to 64 bits of
address for classifying traffic. In fact, the hICN project address for classifying traffic. In fact, the Hybrid Information-
[I-D.muscariello-intarea-hicn], while adopting the request-response Centric Networking (hICN) project [HICN], while adopting the request-
model of CCNx, uses IPv6 addresses as the available namespace, and response model of CCNx, uses IPv6 addresses as the available
IPv6 packets (plus "fake" TCP headers) as the wire format. namespace, and IPv6 packets (plus "fake" TCP headers) as the wire
format.
Nonetheless, the flexibility of tokenized (i.e. strings treated as Nonetheless, the flexibility of tokenized (i.e., strings treated as
opaque tokens), variable length, hierarchical names allows one to opaque tokens), variable length, hierarchical names allows one to
directly associate classes of traffic for QoS purposes with the directly associate classes of traffic for QoS purposes with the
structure of an application namespace. The classification can be as structure of an application namespace. The classification can be as
coarse or fine-grained as desired by the application. While not coarse or fine-grained as desired by the application. While not
_always_ the case, there is typically a straightforward association _always_ the case, there is typically a straightforward association
between how objects are named, and how they are grouped together for between how objects are named and how they are grouped together for
common treatment. Examples abound; a number can be conveniently common treatment. Examples abound; a number can be conveniently
found in [I-D.moiseenko-icnrg-flowclass]. found in [FLOWCLASS].
6.2. Topology interactions with QoS 6.2. Topology Interactions with QoS
In ICN, QoS is not pre-bound to network topology since names are non- In ICN, QoS is not pre-bound to network topology since names are non-
topological, unlike unicast IP addresses. This allows QoS to be topological, unlike unicast IP addresses. This allows QoS to be
applied to multi-destination and multi-path environments in a applied to multi-destination and multipath environments in a
straightforward manner, rather than requiring either multicast with straightforward manner, rather than requiring either multicast with
coarse class-based scheduling or complex signaling like that in RSVP- coarse class-based scheduling or complex signaling like that in RSVP
TE [RFC3209] that is needed to make point-to-multipoint Muti-Protocol Traffic Engineering (RSVP-TE) [RFC3209] that is needed to make point-
Label Switching (MPLS) work. to-multipoint Multiprotocol Label Switching (MPLS) work.
Because of IP's stateless forwarding model, complicated by the Because of IP's stateless forwarding model, complicated by the
ubiquity of asymmetric routes, any flow-based QoS requires state that ubiquity of asymmetric routes, any flow-based QoS requires state that
is decoupled from the actual arrival of traffic and hence must be is decoupled from the actual arrival of traffic and hence must be
maintained, at least as soft-state, even during quiescent periods. maintained, at least as soft state, even during quiescent periods.
Intserv, for example, requires flow signaling with state O(#flows). Intserv, for example, requires flow signaling on the order of
ICN, even worst case, requires state O(#active Interest/Data O(number of flows). ICN, even worst case, requires order of O(number
exchanges), since state can be instantiated on arrival of an of active Interest/Data exchanges), since state can be instantiated
Interest, and removed (perhaps lazily) once the data has been on arrival of an Interest and removed (perhaps lazily) once the data
returned. has been returned.
6.3. Specification of QoS treatments 6.3. Specification of QoS Treatments
Unlike Intserv, Diffserv eschews signaling in favor of class-based Unlike Intserv, Diffserv eschews signaling in favor of class-based
configuration of resources and queues in network elements. However, configuration of resources and queues in network elements. However,
Diffserv limits traffic treatments to a few bits taken from the ToS Diffserv limits traffic treatments to a few bits taken from the TOS
field of IP. No such wire encoding limitations exist for NDN or field of IP. No such wire encoding limitations exist for NDN or
CCNx, as the protocol is completely TLV (Type-Length-Value) based, CCNx, as the protocol is completely TLV (Type-Length-Value) based,
and one (or even more than one) new field can be easily defined to and one (or even more than one) new field can be easily defined to
carry QoS treatment information. carry QoS treatment information.
Therefore, there are greenfield possibilities for more powerful QoS Therefore, there are greenfield possibilities for more powerful QoS
treatment options in ICN. For example, IP has no way to express a treatment options in ICN. For example, IP has no way to express a
QoS treatment like "try hard to deliver reliably, even at the expense QoS treatment like "try hard to deliver reliably, even at the expense
of delay or bandwidth". Such a QoS treatment for ICN could invoke of delay or bandwidth". Such a QoS treatment for ICN could invoke
native ICN mechanisms, none of which are present in IP, such as: native ICN mechanisms, none of which are present in IP, such as the
following:
* In-network retransmission in response to hop-by-hop errors * Retransmitting in-network in response to hop-by-hop errors
returned from upstream forwarders returned from upstream forwarders
* Trying multiple paths to multiple content sources either in * Trying multiple paths to multiple content sources either in
parallel or serially parallel or serially
* Assign higher precedence for short-term caching to recover from * Assigning higher precedence for short-term caching to recover from
downstream^(*) errors downstream (see note below) errors
* Coordinating cache utilization with forwarding resources * Coordinating cache utilization with forwarding resources
| ^(*)_Downstream_ refers to the direction Data messages flow | Note: _Downstream_ refers to the direction Data messages flow
| toward the consumer (the issuer of Interests). Conversely, | toward the consumer (the issuer of Interests). Conversely,
| _Upstream_ refers to the direction Interests flow toward the | _Upstream_ refers to the direction Interests flow toward the
| producer of data. | producer of data.
Such mechanisms are typically described in NDN and CCNx as Such mechanisms are typically described in NDN and CCNx as
_forwarding strategies_. However, little or no guidance is given for _forwarding strategies_. However, there is little or no guidance for
what application actions or protocol machinery is used to decide which application actions or protocol machinery a forwarder should
which forwarding strategy to use for which Interests that arrive at a use to select the appropriate forwarding strategy for arriving
forwarder. See [BenAbraham2018] for an investigation of these Interest messages. See [BenAbraham2018] for an investigation of
issues. Associating forwarding strategies with the equivalence these issues. Associating forwarding strategies with the equivalence
classes and QoS treatments directly can make them more accessible and classes and QoS treatments directly can make them more accessible and
useful to implement and deploy. useful to implement and deploy.
Stateless forwarding and asymmetric routing in IP limits available Stateless forwarding and asymmetric routing in IP limits available
state/feedback to manage link resources. In contrast, NDN or CCNx state/feedback to manage link resources. In contrast, NDN or CCNx
forwarding allows all link resource allocation to occur as part of forwarding allows all link resource allocation to occur as part of
Interest forwarding, potentially simplifying things considerably. In Interest forwarding, potentially simplifying things considerably. In
particular, with symmetric routing, producers have no control over particular, with symmetric routing, producers have no control over
the paths their data packets traverse, and hence any QoS treatments the paths their Data packets traverse; hence, any QoS treatments
intended to influence routing paths from producer to consumer will intended to influence routing paths from producer to consumer will
have no effect. have no effect.
One complication in the handling of ICN QoS treatments is not present One complication in the handling of ICN QoS treatments is not present
in IP and hence worth mention. CCNx and NDN both perform _Interest in IP and hence worth mentioning. CCNx and NDN both perform
aggregation_ (See Section 2.3.2 of [RFC8569]). If an Interest _Interest aggregation_ (see Section 2.4.2 of [RFC8569]). If an
arrives matching an existing PIT entry, but with a different QoS Interest arrives matching an existing PIT entry, but with a different
treatment from an Interest already forwarded, it can be tricky to QoS treatment from an Interest already forwarded, it can be tricky to
decide whether to aggregate the interest or forward it, and how to decide whether to aggregate the Interest or forward it, and how to
keep track of the differing QoS treatments for the two Interests. keep track of the differing QoS treatments for the two Interests.
Exploration of the details surrounding these situations is beyond the Exploration of the details surrounding these situations is beyond the
scope of this document; further discussion can be found for the scope of this document; further discussion can be found for the
general case of flow balance and congestion control in general case of flow balance and congestion control in [FLOWBALANCE]
[I-D.oran-icnrg-flowbalance], and specifically for QoS treatments in and specifically for QoS treatments in [DNC-QOS-ICN].
[I-D.anilj-icnrg-dnc-qos-icn].
6.4. ICN forwarding semantics effect on QoS 6.4. ICN Forwarding Semantics Effect on QoS
IP has three forwarding semantics, with different QoS needs (Unicast, IP has three forwarding semantics, with different QoS needs (Unicast,
Anycast, Multicast). ICN has the single forwarding semantic, so any Anycast, Multicast). ICN has the single forwarding semantic, so any
QoS machinery can be uniformly applied across any request/response QoS machinery can be uniformly applied across any request/response
invocation. This applies whether the forwarder employs dynamic invocation. This applies whether the forwarder employs dynamic
destination routing, multi-destination forwarding with next-hops destination routing, multi-destination forwarding with next hops
tried serially, multi-destination with next-hops used in parallel, or tried serially, multi-destination with next hops used in parallel, or
even localized flooding (e.g. directly on L2 multicast mechanisms). even localized flooding (e.g., directly on Layer 2 multicast
Additionally, the pull-based model of ICN avoids a number of thorny mechanisms). Additionally, the pull-based model of ICN avoids a
multicast QoS problems that IP has ([Wang2000], [RFC3170], number of thorny multicast QoS problems that IP has (see [Wang2000],
[Tseng2003]). [RFC3170], and [Tseng2003]).
The Multi-destination/multi-path forwarding model in ICN changes The Multi-destination/multipath forwarding model in ICN changes
resource allocation needs in a fairly deep way. IP treats all resource allocation needs in a fairly deep way. IP treats all
endpoints as open-loop packet sources, whereas NDN and CCNx have endpoints as open-loop packet sources, whereas NDN and CCNx have
strong asymmetry between producers and consumers as packet sources. strong asymmetry between producers and consumers as packet sources.
6.5. QoS interactions with Caching 6.5. QoS Interactions with Caching
IP has no caching in routers, whereas ICN needs ways to allocate IP has no caching in routers, whereas ICN needs ways to allocate
cache resources. Treatments to control caching operation are cache resources. Treatments to control caching operation are
unlikely to look much like the treatments used to control link unlikely to look much like the treatments used to control link
resources. NDN and CCNx already have useful cache control directives resources. NDN and CCNx already have useful cache control directives
associated with Data messages. The CCNx controls include: associated with Data messages. The CCNx controls include the
following:
ExpiryTime: time after which a cached Content Object is considered ExpiryTime: time after which a cached Content Object is considered
expired and MUST no longer be used to respond to an Interest from expired and MUST no longer be used to respond to an Interest from
a cache. a cache.
Recommended Cache Time: time after which the publisher considers the Recommended Cache Time: time after which the publisher considers the
Content Object to be of low value to cache. Content Object to be of low value to cache.
See [RFC8569] for the formal definitions. See [RFC8569] for the formal definitions.
ICN flow classifiers, such as those in ICN flow classifiers, such as those in [FLOWCLASS] can be used to
[I-D.moiseenko-icnrg-flowclass] can be used to achieve soft or hard achieve soft or hard partitioning (see note below) of cache resources
partitioning^(*) of cache resources in the content store of an ICN in the CS of an ICN forwarder. For example, cached content for a
forwarder. For example, cached content for a given equivalence class given equivalence class can be considered _fate shared_ in a cache
can be considered _fate shared_ in a cache whereby objects from the whereby objects from the same equivalence class can be purged as a
same equivalence class can be purged as a group rather than group rather than individually. This can recover cache space more
individually. This can recover cache space more quickly and at lower quickly and at lower overhead than pure per-object replacement when a
overhead than pure per-object replacement when a cache is under cache is under extreme pressure and in danger of thrashing. In
extreme pressure and in danger of thrashing. In addition, since the addition, since the forwarder remembers the QoS treatment for each
forwarder remembers the QoS treatment for each pending Interest in pending Interest in its PIT, the above cache controls can be
its PIT, the above cache controls can be augmented by policy to augmented by policy to prefer retention of cached content for some
prefer retention of cached content for some equivalence classes as equivalence classes as part of the cache replacement algorithm.
part of the cache replacement algorithm.
| ^(*)With hard partitioning, there are dedicated cache resources | Note: With hard partitioning, there are dedicated cache
| for each equivalence class (or enumerated list of equivalence | resources for each equivalence class (or enumerated list of
| classes). With soft partitioning, resources are at least | equivalence classes). With soft partitioning, resources are at
| partly shared among the (sets of) equivalence classes of | least partly shared among the (sets of) equivalence classes of
| traffic. | traffic.
7. Strawman principles for an ICN QoS architecture 7. Strawman Principles for an ICN QoS Architecture
Based on the observations made in the earlier sections, this summary Based on the observations made in the earlier sections, this summary
section captures the author's ideas for clear and actionable section captures the author's ideas for clear and actionable
architectural principles for how to incorporate QoS machinery into architectural principles for incorporating QoS machinery into ICN
ICN protocols like NDN and CCNx. Hopefully, they can guide further protocols like NDN and CCNx. Hopefully, they can guide further work
work and focus effort on portions of the giant design space for QoS and focus effort on portions of the giant design space for QoS that
that have the best tradeoffs in terms of flexibility, simplicity, and have the best trade-offs in terms of flexibility, simplicity, and
deployability. deployability.
*Define equivalence classes using the name hierarchy rather than *Define equivalence classes using the name hierarchy rather than
creating an independent traffic class definition*. This directly creating an independent traffic class definition*. This directly
associates the specification of equivalence classes of traffic with associates the specification of equivalence classes of traffic with
the structure of the application namespace. It can allow the structure of the application namespace. It can allow
hierarchical decomposition of equivalence classes in a natural way hierarchical decomposition of equivalence classes in a natural way
because of the way hierarchical ICN names are constructed. Two because of the way hierarchical ICN names are constructed. Two
practical mechanisms are presented in [I-D.moiseenko-icnrg-flowclass] practical mechanisms are presented in [FLOWCLASS] with different
with different tradeoffs between security and the ability to trade-offs between security and the ability to aggregate flows.
aggregate flows. Either prefix-based (EC3) or explicit name Either the prefix-based mechanism (the equivalence class component
component based (ECNT) or both could be adopted as the part of the count (EC3) scheme) or the explicit name component-based mechanism
QoS architecture for defining equivalence classes. (the equivalence class name component type (ECNCT) scheme), or both,
could be adopted as the part of the QoS architecture for defining
equivalence classes.
*Put consumers in control of Link and Forwarding resource *Put consumers in control of link and forwarding resource
allocation*. Do all link buffering and forwarding (both memory and allocation*. Base all link buffering and forwarding (both memory and
CPU) resource allocations based on Interest arrivals. This is CPU) resource allocations on Interest arrivals. This is attractive
attractive because it provides early congestion feedback to because it provides early congestion feedback to consumers and allows
consumers, and allows scheduling the reverse link direction ahead of scheduling the reverse link direction for carrying the matching data
time for carrying the matching data. It makes enforcement of QoS in advance. It makes enforcement of QoS treatments a single-ended
treatments a single-ended (i.e. at the consumer) rather than a (i.e., at the consumer) rather than a double-ended problem and can
double-ended problem and can avoid wasting resources on fetching data avoid wasting resources on fetching data that will be dropped when it
that will wind up dropped when it arrives at a bottleneck link. arrives at a bottleneck link.
*Allow producers to influence the allocation of cache resources*. *Allow producers to influence the allocation of cache resources*.
Producers want to affect caching decisions in order to: Producers want to affect caching decisions in order to do the
following:
* Shed load by having Interests served by content stores in * Shed load by having Interests served by CSes in forwarders before
forwarders before reaching the producer itself. they reach the producer itself
* Survive transient producer reachability or link outages close to * Survive transient producer reachability or link outages close to
the producer. the producer
For caching to be effective, individual Data objects in an For caching to be effective, individual Data objects in an
equivalence class need to have similar treatment; otherwise well- equivalence class need to have similar treatment; otherwise, well-
known cache thrashing pathologies due to self-interference emerge. known cache-thrashing pathologies due to self-interference emerge.
Producers have the most direct control over caching policies through Producers have the most direct control over caching policies through
the caching directives in Data messages. It therefore makes sense to the caching directives in Data messages. It therefore makes sense to
put the producer, rather than the consumer or network operator in put the producer, rather than the consumer or network operator, in
charge of specifying these equivalence classes. charge of specifying these equivalence classes.
See [I-D.moiseenko-icnrg-flowclass] for specific mechanisms to See [FLOWCLASS] for specific mechanisms to achieve this.
achieve this.
*Allow consumers to influence the allocation of cache resources*. *Allow consumers to influence the allocation of cache resources*.
Consumers want to affect caching decisions in order to: Consumers want to affect caching decisions in order to do the
following:
* Reduce latency for retrieving data * Reduce latency for retrieving data
* Survive transient outages of either a producer or links close to * Survive transient outages of either a producer or links close to
the consumer the consumer
Consumers can have indirect control over caching by specifying QoS Consumers can have indirect control over caching by specifying QoS
treatments in their Interests. Consider the following potential QoS treatments in their Interests. Consider the following potential QoS
treatments by consumers that can drive caching policies: treatments by consumers that can drive caching policies:
* A QoS treatment requesting better robustness against transient * A QoS treatment requesting better robustness against transient
disconnection can be used by a forwarder close to the consumer (or disconnection can be used by a forwarder close to the consumer (or
downstream of an unreliable link) to preferentially cache the downstream of an unreliable link) to preferentially cache the
skipping to change at page 18, line 16 skipping to change at line 786
Consumers can have indirect control over caching by specifying QoS Consumers can have indirect control over caching by specifying QoS
treatments in their Interests. Consider the following potential QoS treatments in their Interests. Consider the following potential QoS
treatments by consumers that can drive caching policies: treatments by consumers that can drive caching policies:
* A QoS treatment requesting better robustness against transient * A QoS treatment requesting better robustness against transient
disconnection can be used by a forwarder close to the consumer (or disconnection can be used by a forwarder close to the consumer (or
downstream of an unreliable link) to preferentially cache the downstream of an unreliable link) to preferentially cache the
corresponding data. corresponding data.
* Conversely a QoS treatment together with, or in addition to a * Conversely, a QoS treatment together with, or in addition to, a
request for short latency, to indicate that new data will be request for short latency indicating that the forwarder should
requested soon enough that caching the current data being only pay attention to the caching preferences of the producer
requested would be ineffective and hence to only pay attention to because caching requested data would be ineffective (i.e., new
the caching preferences of the producer. data will be requested shortly).
* A QoS treatment indicating a mobile consumer likely to incur a * A QoS treatment indicating that a mobile consumer will likely
mobility event within an RTT (or a few RTTs). Such a treatment incur a mobility event within an RTT (or a few RTTs). Such a
would allow a mobile network operator to preferentially cache the treatment would allow a mobile network operator to preferentially
data at a forwarder positioned at a _join point_ or _rendezvous cache the data at a forwarder positioned at a _join point_ or
point_ of their topology _rendezvous point_ of their topology.
*Give network operators the ability to match customer SLAs to cache *Give network operators the ability to match customer SLAs to cache
resource availability*. Network operators, whether closely tied resource availability*. Network operators, whether closely tied
administratively to producer or consumer, or constituting an administratively to producer or consumer, or constituting an
independent transit administration, provide the storage resources in independent transit administration, provide the storage resources in
the ICN forwarders. Therefore, they are the ultimate arbiters of how the ICN forwarders. Therefore, they are the ultimate arbiters of how
the cache resources are managed. In addition to any local policies the cache resources are managed. In addition to any local policies
they may enforce, the cache behavior from the QoS standpoint emerges they may enforce, the cache behavior from the QoS standpoint emerges
from how the producer-specified equivalence classes map onto cache from the mapping of producer-specified equivalence classes onto cache
space availability, including whether cache entries are treated space availability, including whether cache entries are treated
individually, or fate-shared. Forwarders also determine how the individually or fate-shared. Forwarders also determine the mapping
consumer-specified QoS treatments map to the precedence used for of consumer-specified QoS treatments to the precedence used for
retaining Data objects in the cache. retaining Data objects in the cache.
Besides utilizing cache resources to meet the QoS goals of individual Besides utilizing cache resources to meet the QoS goals of individual
producers and consumers, network operators also want to manage their producers and consumers, network operators also want to manage their
cache resources in order to: cache resources in order to do the following:
* Ameliorate congestion hotspots by reducing load converging on * Ameliorate congestion hotspots by reducing load converging on
producers they host on their network. producers they host on their network
* Improve Interest satisfaction rates by utilizing caches as short- * Improve Interest satisfaction rates by utilizing caches as short-
term retransmission buffers to recover from transient producer term retransmission buffers to recover from transient producer
reachability problems, link errors or link outages. reachability problems, link errors, or link outages
* Improve both latency and reliability in environments when * Improve both latency and reliability in environments when
consumers are mobile in the operator's topology. consumers are mobile in the operator's topology
*Re-think how to specify traffic treatments - don't just copy *Rethink how to specify traffic treatments -- don't just copy
Diffserv*. Some of the Diffserv classes may form a good starting Diffserv*. Some of the Diffserv classes may form a good starting
point, as their mapping onto queuing algorithms for managing link point, as their mappings onto queuing algorithms for managing link
buffering are well understood. However, Diffserv alone does not buffering are well understood. However, Diffserv alone does not
allow one to express latency versus reliability tradeoffs or other capture more complex QoS treatments, such as:
useful QoS treatments. Nor does it permit "Traffic Specification
(TSPEC)"-style traffic descriptions as are allowed in a signaled QoS * Trading off latency against reliability
scheme. Here are some examples:
* Trading off resource usage against delivery probability through
controlled flooding or other forwarding mechanisms
* Allocating resources based on rich TSPEC-like traffic descriptions
that appear in signaled QoS schemes like Intserv
Here are some examples:
* A "burst" treatment, where an initial Interest gives an aggregate * A "burst" treatment, where an initial Interest gives an aggregate
data size to request allocation of link capacity for a large burst data size to request allocation of link capacity for a large burst
of Interest/Data exchanges. The Interest can be rejected at any of Interest/Data exchanges. The Interest can be rejected at any
hop if the resources are not available. Such a treatment can also hop if the resources are not available. Such a treatment can also
accommodate Data implosion produced by the discovery procedures of accommodate Data implosion produced by the discovery procedures of
management protocols like [I-D.irtf-icnrg-ccninfo]. management protocols like [CCNINFO].
* A "reliable" treatment, which affects preference for allocation of * A "reliable" treatment, which affects preference for allocation of
PIT space for the Interest and Content Store space for the data in PIT space for the Interest and CS space for the Data in order to
order to improve the robustness of IoT data delivery in improve the robustness of IoT data delivery in a constrained
constrained environment, as is described in environment, as is described in [IOTQOS].
[I-D.gundogan-icnrg-iotqos].
* A "search" treatment, which, within the specified Interest * A "search" treatment, which, within the specified Interest
Lifetime, tries many paths either in parallel or serial to Lifetime, tries many paths either in parallel or serially to
potentially many content sources, to maximize the probability that potentially many content sources, to maximize the probability that
the requested item will be found. This is done at the expense of the requested item will be found. This is done at the expense of
the extra bandwidth of both forwarding Interests and receiving the extra bandwidth of both forwarding Interests and receiving
multiple responses upstream of an aggregation point. The multiple responses upstream of an aggregation point. The
treatment can encode a value expressing tradeoffs like breadth- treatment can encode a value expressing trade-offs like breadth-
first versus depth-first search, and bounds on the total resource first versus depth-first search, and bounds on the total resource
expenditure. Such a treatment would be useful for instrumentation expenditure. Such a treatment would be useful for instrumentation
protocols like [I-D.irtf-icnrg-icntraceroute]. protocols like [ICNTRACEROUTE].
| As an aside, loose latency control (on the order of seconds or | As an aside, loose latency control (on the order of seconds or
| tens of milliseconds as opposed milliseconds or microseconds) | tens of milliseconds as opposed milliseconds or microseconds)
| can be achieved by bounding Interest Lifetime as long as this | can be achieved by bounding Interest Lifetime as long as this
| lifetime machinery is not also used as an application mechanism | lifetime machinery is not also used as an application mechanism
| to provide subscriptions or to establish path traces for | to provide subscriptions or to establish path traces for
| producer mobility. See [Krol2018] for a discussion of the | producer mobility. See [Krol2018] for a discussion of the
| network versus application timescale issues in ICN protocols. | network versus application timescale issues in ICN protocols.
7.1. Can Intserv-like traffic control in ICN provide richer QoS 7.1. Can Intserv-Like Traffic Control in ICN Provide Richer QoS
semantics? Semantics?
Basic QoS treatments such as those summarized above may not be Basic QoS treatments such as those summarized above may not be
adequate to cover the whole range of application utility functions adequate to cover the whole range of application utility functions
and deployment environments we expect for ICN. While it is true that and deployment environments we expect for ICN. While it is true that
one does not necessarily need a separate signaling protocol like RSVP one does not necessarily need a separate signaling protocol like RSVP
given the state carried in the ICN data plane by forwarders, there given the state carried in the ICN data plane by forwarders, simple
are some potentially important capabilities not provided by just QoS treatments applied per Interest/Data exchanges lack some
simple QoS treatments applied to per- Interest/Data exchanges. potentially important capabilities. Intserv's richer QoS
Intserv's richer QoS capabilities may be of value, especially if they capabilities may be of value, especially if they can be provided in
can be provided in ICN at lower complexity and protocol overhead than ICN at lower complexity and protocol overhead than Intserv plus RSVP.
Intserv+RSVP.
There are three key capabilities missing from Diffserv-like QoS There are three key capabilities missing from Diffserv-like QoS
treatments, no matter how sophisticated they may be in describing the treatments, no matter how sophisticated they may be in describing the
desired treatment for a given equivalence class of traffic. Intserv- desired treatment for a given equivalence class of traffic. Intserv-
like QoS provides all of these: like QoS provides all of these:
1. The ability to *describe traffic flows* in a mathematically 1. The ability to *describe traffic flows* in a mathematically
meaningful way. This is done through parameters like average meaningful way. This is done through parameters like average
rate, peak rate, and maximum burst size. The parameters are rate, peak rate, and maximum burst size. The parameters are
encapsulated in a data structure called a "TSPEC" which can be encapsulated in a data structure called a "TSPEC", which can be
placed in whatever protocol needs the information (in the case of placed in whatever protocol needs the information (in the case of
TCP/IP Intserv, this is RSVP). TCP/IP Intserv, this is RSVP).
2. The ability to perform *admission control*, where the element 2. The ability to perform *admission control*, where the element
requesting the QoS treatment can know _before_ introducing requesting the QoS treatment can know _before_ introducing
traffic whether the network elements have agreed to provide the traffic whether the network elements have agreed to provide the
requested traffic treatment. An important side-effect of requested traffic treatment. An important side effect of
providing this assurance is that the network elements install providing this assurance is that the network elements install
state that allows the forwarding and queuing machinery to police state that allows the forwarding and queuing machinery to police
and shape the traffic in a way that provides a sufficient degree and shape the traffic in a way that provides a sufficient degree
of _isolation_ from the dynamic behavior of other traffic. of _isolation_ from the dynamic behavior of other traffic.
Depending on the admission control mechanism, it may or may not Depending on the admission-control mechanism, it may or may not
be possible to explicitly release that state when the application be possible to explicitly release that state when the application
no longer needs the QoS treatment. no longer needs the QoS treatment.
3. The permissable *degree of divergence* in the actual traffic 3. The ability to specify the permissible *degree of divergence* in
handling from the requested handling. Intserv provided two the actual traffic handling from the requested handling. Intserv
choices here, the _controlled load_ service and the _guaranteed_ provides two choices here: the _controlled load_ service and the
service. The former allows stochastic deviation equivalent to _guaranteed_ service. The former allows stochastic deviation
what one would experience on an unloaded path of a packet equivalent to what one would experience on an unloaded path of a
network. The latter conforms to the TSPEC deterministically, at packet network. The latter conforms to the TSPEC
the obvious expense of demanding extremely conservative resource deterministically, at the obvious expense of demanding extremely
allocation. conservative resource allocation.
Given the limited applicability of these capabilities in today's Given the limited applicability of these capabilities in today's
Internet, the author does not take any position as to whether any of Internet, the author does not take any position as to whether any of
these Intserv-like capabilities are needed for ICN to be succesful. these Intserv-like capabilities are needed for ICN to be successful.
However, a few things seem important to consider. The following However, a few things seem important to consider. The following
paragraphs speculate about the consequences to the CCNx or NDN paragraphs speculate about the consequences of incorporating these
protocol architectures of incorporating these features. features into the CCNx or NDN protocol architectures.
Superficially, it would be quite straightforward to accommodate Superficially, it would be quite straightforward to accommodate
Intserv-equivalent traffic descriptions in CCNx or NDN. One could Intserv-equivalent traffic descriptions in CCNx or NDN. One could
define a new TLV for the Interest message to carry a TSPEC. A define a new TLV for the Interest message to carry a TSPEC. A
forwarder encountering this, together with a QoS treatment request forwarder encountering this, together with a QoS treatment request
(e.g. as proposed in Section 6.3) could associate the traffic (e.g., as proposed in Section 6.3), could associate the traffic
specification with the corresponding equivalence class derived from specification with the corresponding equivalence class derived from
the name in the Interest. This would allow the forwarder to create the name in the Interest. This would allow the forwarder to create
state that not only would apply to the returning Data for that state that not only would apply to the returning Data for that
Interest when being queued on the downstream interface, but be Interest when being queued on the downstream interface but also be
maintained as soft state across multiple Interest/Data exchanges to maintained as soft state across multiple Interest/Data exchanges to
drive policing and shaping algorithms at per-flow granularity. The drive policing and shaping algorithms at per-flow granularity. The
cost in Interest message overhead would be modest, however the cost in Interest message overhead would be modest; however, the
complications associated with managing different traffic complications associated with managing different traffic
specifications in different Interests for the same equivalence class specifications in different Interests for the same equivalence class
might be substantial. Of course, all the scalability considerations might be substantial. Of course, all the scalability considerations
with maintaining per-flow state also come into play. with maintaining per-flow state also come into play.
Similarly, it would be equally straightforward to have a way to Similarly, it would be equally straightforward to have a way to
express the degree of divergence capability that Intserv provides express the degree of divergence capability that Intserv provides
through its controlled load and guaranteed service definitions. This through its controlled load and guaranteed service definitions. This
could either be packaged with the traffic specification or encoded could either be packaged with the traffic specification or encoded
separately. separately.
In contrast to the above, performing admission control for ICN flows In contrast to the above, performing admission control for ICN flows
is likely to be just as heavy-weight as it turned out to be with IP is likely to be just as heavyweight as it is with IP using RSVP. The
using RSVP. The dynamic multi-path, multi-destination forwarding dynamic multipath, multi-destination forwarding model of ICN makes
model of ICN makes performing admission control particularly tricky. performing admission control particularly tricky. Just to
Just to illustrate: illustrate:
* Forwarding next-hop selection is not confined to single paths (or * Forwarding next-hop selection is not confined to single paths (or
a few ECMP equivalent paths) as it is with IP, making it difficult a few ECMP equivalent paths) as it is with IP, making it difficult
to know where to install state in advance of the arrival of an to know where to install state in advance of the arrival of an
Interest to forward. Interest to forward.
* As with point-to-multipoint complexities when using RSVP for MPLS- * As with point-to-multipoint complexities when using RSVP for MPLS-
TE, state has to be installed to multiple producers over multiple TE, state has to be installed to multiple producers over multiple
paths before an admission control algorithm can commit the paths before an admission-control algorithm can commit the
resources and say "yes" to a consumer needing admission control resources and say "yes" to a consumer needing admission-control
capabilities capabilities.
* Knowing when to remove admission control state is difficult in the * Knowing when to remove admission-control state is difficult in the
absence of a heavy-weight resource reservation protocol. Soft absence of a heavyweight resource reservation protocol. Soft
state timeout may or may not be an adequate answer. state timeout may or may not be an adequate answer.
Despite the challenges above, it may be possible to craft an Despite the challenges above, it may be possible to craft an
admission control scheme for ICN that achieves the desired QoS goals admission-control scheme for ICN that achieves the desired QoS goals
of applications without the invention and deployment of a complex of applications without the invention and deployment of a complex,
separate admission control signaling protocol. There have been separate admission-control signaling protocol. There have been
designs in earlier network architectures that were capable of designs in earlier network architectures that were capable of
performing admission control piggybacked on packet transmission. performing admission control piggybacked on packet transmission.
| (The earliest example the author is aware of is [Autonet]). | The earliest example the author is aware of is [Autonet].
Such a scheme might have the following general shape *(warning: Such a scheme might have the following general shape (*warning:*
serious hand waving follows!)*: serious hand-waving follows!):
* In addition to a QoS treatment and a traffic specification, an * In addition to a QoS treatment and a traffic specification, an
Interest requesting admission for the corresponding equivalence Interest requesting admission for the corresponding equivalence
class would so indicate via a new TLV. It would also need to: (a) class would indicate this via a new TLV. It would also need to do
indicate an expiration time after which any reserved resources can the following: (a) indicate an expiration time after which any
be released, and (b) indicate that caches be bypassed, so that the reserved resources can be released, and (b) indicate that caches
admission control request arrives at a bone-fide producer. be bypassed, so that the admission-control request arrives at a
bona fide producer.
* Each forwarder processing the Interest would check for resource * Each forwarder processing the Interest would check for resource
availability and if not available, or the requested service not availability. If the resources are not available, or the
feasible, reject the Interest with an admission control failure. requested service is not feasible, the forwarder would reject the
If resources are available, the forwarder would record the traffic Interest with an admission-control failure. If resources are
specification as described above and forward the Interest. 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 * If the Interest successfully arrives at a producer, the producer
returns the requested Data. would return the requested Data.
* Each on-path forwarder, on receiving the matching Data message, if * Upon receiving the matching Data message and if the resources are
the resources are still available, does the actual allocation, and still available, each on-path forwarder would allocate resources
marks the admission control TLV as "provisionally approved". and would mark the admission control TLV as "provisionally
Conversely, if the resource reservation fails, the admission approved". Conversely, if the resource reservation fails, the
control is marked "failed", although the Data is still passed admission control would be marked "failed", although the Data
downstream. would still be passed downstream.
* Upon the Data message arriving, the consumer knows if admission * Upon the Data message arrival, the consumer would know if
succeeded or not, and subsequent Interests can rely on the QoS admission succeeded or not, and subsequent Interests could rely on
state being in place until either some failure occurs, or a the QoS state being in place until either some failure occurs, or
topology or other forwarding change alters the forwarding path. a topology or other forwarding change alters the forwarding path.
To deal with this, additional machinery is needed to ensure To deal with this, additional machinery is needed to ensure
subsequent Interests for an admitted flow either follow that path subsequent Interests for an admitted flow either follow that path
or an error is reported. One possibility (also useful in many or an error is reported. One possibility (also useful in many
other contexts), is to employ a _Path Steering_ mechanism, such as other contexts), is to employ a _Path Steering_ mechanism, such as
the one described in [Moiseenko2017]. the one described in [Moiseenko2017].
8. IANA Considerations 8. IANA Considerations
This document does not require any IANA actions. This document has no IANA actions.
9. Security Considerations 9. Security Considerations
There are a few ways in which QoS for ICN interacts with security and There are a few ways in which QoS for ICN interacts with security and
privacy issues. Since QoS addresses relationships among traffic privacy issues. Since QoS addresses relationships among traffic
rather than the inherent characteristics of traffic, it neither rather than the inherent characteristics of traffic, it neither
enhances nor degrades the security and privacy properties of the data enhances nor degrades the security and privacy properties of the data
being carried, as long as the machinery does not alter or otherwise being carried, as long as the machinery does not alter or otherwise
compromise the basic security properties of the associated protocols. compromise the basic security properties of the associated protocols.
The QoS approaches advocated here for ICN can serve to amplify The QoS approaches advocated here for ICN can serve to amplify
existing threats to network traffic however: existing threats to network traffic. However:
* An attacker able to manipulate the QoS treatments of traffic can * An attacker able to manipulate the QoS treatments of traffic can
mount a more focused (and potentially more effective) denial of mount a more focused (and potentially more effective) denial-of-
service attack by suppressing performance on traffic the attacker service attack by suppressing performance on traffic the attacker
is targeting. Since the architecture here assumes QoS treatments is targeting. Since the architecture here assumes QoS treatments
are manipulable hop-by-hop, any on-path adversary can wreak havoc. are manipulatable hop-by-hop, any on-path adversary can wreak
Note however, that in basic ICN, an on-path attacker can do this havoc. Note, however, that in basic ICN, an on-path attacker can
and more by dropping, delaying, or mis-routing traffic independent do this and more by dropping, delaying, or misrouting traffic
of any particular QoS machinery in use. independent of any particular QoS machinery in use.
* By explicitly revealing equivalence classes of traffic via either * When equivalence classes of traffic are explicitly revealed via
names or other fields in packets, an attacker has yet one more either names or other fields in packets, an attacker has yet one
handle to use to discover linkability of multiple requests. more handle to use to discover linkability of multiple requests.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <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 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Semantics", RFC 8569, Networking (CCNx) Semantics", RFC 8569,
DOI 10.17487/RFC8569, July 2019, DOI 10.17487/RFC8569, July 2019,
<https://www.rfc-editor.org/info/rfc8569>. <https://www.rfc-editor.org/info/rfc8569>.
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Messages in TLV Format", RFC 8609, Networking (CCNx) Messages in TLV Format", RFC 8609,
DOI 10.17487/RFC8609, July 2019, DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>. <https://www.rfc-editor.org/info/rfc8609>.
10.2. Informative References 10.2. Informative References
[AS] "Autonomous System (Internet)", no date, [AS] Wikipedia, "Autonomous system (Internet)", May 2021,
<https://en.wikipedia.org/wiki/ <https://en.wikipedia.org/w/index.php?title=Autonomous_sys
Autonomous_system_(Internet)>. tem_(Internet)&oldid=1025244754>.
[Auge2018] Augé, J., Carofiglio, G., Grassi, G., Muscariello, L., [Auge2018] Augé, J., Carofiglio, G., Grassi, G., Muscariello, L.,
Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less
Producer Mobility in Content-Centric Networks", in IEEE Producer Mobility in Content-Centric Networks", in IEEE
Transactions on Network and Service Management (Volume: 15 Transactions on Network and Service Management, Vol. 15,
, Issue: 2 , June 2018), DOI 10.1109/TNSM.2018.2796720, No. 2, DOI 10.1109/TNSM.2018.2796720, June 2018,
June 2018, <https://ieeexplore.ieee.org/document/8267132>. <https://ieeexplore.ieee.org/document/8267132>.
[Autonet] Schroeder, M., Birrell, A., Burrows, M., Murray, H., [Autonet] Schroeder, M., Birrell, A., Burrows, M., Murray, H.,
Needham, R., Rodeheffer, T., Satterthwaite, E., and C. Needham, R., Rodeheffer, T., Satterthwaite, E., and C.
Thacker, "Autonet: a High-speed, Self-configuring Local Thacker, "Autonet: a High-speed, Self-configuring Local
Area Network Using Point-to-point Links", in IEEE Journal Area Network Using Point-to-point Links", in IEEE Journal
on Selected Areas in Communications ( Volume: 9, Issue: 8, on Selected Areas in Communications, Vol. 9, No. 8,
Oct 1991), DOI 10.1109/49.105178, October 1991, DOI 10.1109/49.105178, October 1991,
<https://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR- <https://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-
59.pdf>. 59.pdf>.
[BenAbraham2018] [BenAbraham2018]
Ben Abraham, H., Parwatikar, J., DeHart, J., Dresher, A., Ben Abraham, H., Parwatikar, J., DeHart, J., Dresher, A.,
and P. Crowley, ""Decoupling Information and Connectivity and P. Crowley, "Decoupling Information and Connectivity
via Information-Centric Transport", in ICN '18: via Information-Centric Transport", in ICN '18:
Proceedings of the 5th ACM Conference on Information- Proceedings of the 5th ACM Conference on Information-
Centric Networking September 21-23, 2018, Boston, MA, USA, Centric Networking, Boston, MA, USA,
DOI 10.1145/3267955.3267963, September 2018, DOI 10.1145/3267955.3267963, September 2018,
<https://conferences.sigcomm.org/acm-icn/2018/proceedings/ <https://conferences.sigcomm.org/acm-icn/2018/proceedings/
icn18-final31.pdf>. icn18-final31.pdf>.
[Carofiglio2012] [Carofiglio2012]
Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop- Carofiglio, G., Gallo, M., and L. Muscariello, "Joint Hop-
by-hop and receiver-driven Interest control protocol for by-hop and Receiver-Driven Interest Control Protocol for
content-centric networks", in ACM SIGCOMM Computer Content-Centric Networks", in ACM SIGCOMM Computer
Communication Review, September 2012, Communication Review, DOI 10.1145/2377677.2377772,
DOI 10.1016/j.comnet.2016.09.012, September 2012, September 2012,
<http://conferences.sigcomm.org/sigcomm/2012/paper/icn/ <http://conferences.sigcomm.org/sigcomm/2012/paper/icn/
p37.pdf>. p37.pdf>.
[Carofiglio2016] [Carofiglio2016]
Carofiglio, G., Gallo, M., and L. Muscariello, "Optimal Carofiglio, G., Gallo, M., and L. Muscariello, "Optimal
multipath congestion control and request forwarding in multipath congestion control and request forwarding in
information-centric networks: Protocol design and information-centric networks: Protocol design and
experimentation", in Computer Networks, Vol. 110 No. 9, experimentation", in Computer Networks, Vol. 110,
December 2016, DOI 10.1145/2377677.2377772, December 2016, DOI 10.1016/j.comnet.2016.09.012, December 2016,
<https://doi.org/10.1016/j.comnet.2016.09.012>. <https://doi.org/10.1016/j.comnet.2016.09.012>.
[I-D.anilj-icnrg-dnc-qos-icn] [CCNINFO] Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering
Jangam, A., suthar, P., and M. Stolic, "QoS Treatments in
ICN using Disaggregated Name Components", Work in
Progress, Internet-Draft, draft-anilj-icnrg-dnc-qos-icn-
02, 9 March 2020, <https://tools.ietf.org/html/draft-
anilj-icnrg-dnc-qos-icn-02>.
[I-D.gundogan-icnrg-iotqos]
Gundogan, C., Schmidt, T., Waehlisch, M., Frey, M., Shzu-
Juraschek, F., and J. Pfender, "Quality of Service for ICN
in the IoT", Work in Progress, Internet-Draft, draft-
gundogan-icnrg-iotqos-01, 8 July 2019,
<https://tools.ietf.org/html/draft-gundogan-icnrg-iotqos-
01>.
[I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-32, 20 October 2020,
<https://tools.ietf.org/html/draft-ietf-quic-transport-
32>.
[I-D.irtf-icnrg-ccninfo]
Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering
Content and Network Information in Content-Centric Content and Network Information in Content-Centric
Networks", Work in Progress, Internet-Draft, draft-irtf- Networks", Work in Progress, Internet-Draft, draft-irtf-
icnrg-ccninfo-05, 21 September 2020, icnrg-ccninfo-06, 9 March 2021,
<https://tools.ietf.org/html/draft-irtf-icnrg-ccninfo-05>. <https://tools.ietf.org/html/draft-irtf-icnrg-ccninfo-06>.
[I-D.irtf-icnrg-icntraceroute] [DNC-QOS-ICN]
Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and Jangam, A., Ed., Suthar, P., and M. Stolic, "QoS
D. Oran, "ICN Traceroute Protocol Specification", Work in Treatments in ICN using Disaggregated Name Components",
Progress, Internet-Draft, draft-irtf-icnrg-icntraceroute- Work in Progress, Internet-Draft, draft-anilj-icnrg-dnc-
01, 10 October 2020, <https://tools.ietf.org/html/draft- qos-icn-02, 9 March 2020, <https://tools.ietf.org/html/
irtf-icnrg-icntraceroute-01>. draft-anilj-icnrg-dnc-qos-icn-02>.
[I-D.irtf-nwcrg-nwc-ccn-reqs] [FLOWBALANCE]
Matsuzono, K., Asaeda, H., and C. Westphal, "Network Oran, D., "Maintaining CCNx or NDN flow balance with
Coding for Content-Centric Networking / Named Data highly variable data object sizes", Work in Progress,
Networking: Considerations and Challenges", Work in Internet-Draft, draft-oran-icnrg-flowbalance-05, 14
Progress, Internet-Draft, draft-irtf-nwcrg-nwc-ccn-reqs- February 2021, <https://tools.ietf.org/html/draft-oran-
04, 2 September 2020, <https://tools.ietf.org/html/draft- icnrg-flowbalance-05>.
irtf-nwcrg-nwc-ccn-reqs-04>.
[I-D.moiseenko-icnrg-flowclass] [FLOWCLASS]
Moiseenko, I. and D. Oran, "Flow Classification in Moiseenko, I. and D. Oran, "Flow Classification in
Information Centric Networking", Work in Progress, Information Centric Networking", Work in Progress,
Internet-Draft, draft-moiseenko-icnrg-flowclass-06, 12 Internet-Draft, draft-moiseenko-icnrg-flowclass-07, 13
July 2020, <https://tools.ietf.org/html/draft-moiseenko- January 2021, <https://tools.ietf.org/html/draft-
icnrg-flowclass-06>. moiseenko-icnrg-flowclass-07>.
[I-D.muscariello-intarea-hicn] [HICN] Muscariello, L., Carofiglio, G., Augé, J., Papalini, M.,
Muscariello, L., Carofiglio, G., Auge, J., Papalini, M.,
and M. Sardara, "Hybrid Information-Centric Networking", and M. Sardara, "Hybrid Information-Centric Networking",
Work in Progress, Internet-Draft, draft-muscariello- Work in Progress, Internet-Draft, draft-muscariello-
intarea-hicn-04, 20 May 2020, intarea-hicn-04, 20 May 2020,
<https://tools.ietf.org/html/draft-muscariello-intarea- <https://tools.ietf.org/html/draft-muscariello-intarea-
hicn-04>. hicn-04>.
[I-D.oran-icnrg-flowbalance] [ICNTRACEROUTE]
Oran, D., "Maintaining CCNx or NDN flow balance with Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and
highly variable data object sizes", Work in Progress, D. R. Oran, "ICN Traceroute Protocol Specification", Work
Internet-Draft, draft-oran-icnrg-flowbalance-04, 24 August in Progress, Internet-Draft, draft-irtf-icnrg-
2020, <https://tools.ietf.org/html/draft-oran-icnrg- icntraceroute-02, 11 April 2021,
flowbalance-04>. <https://tools.ietf.org/html/draft-irtf-icnrg-
icntraceroute-02>.
[IOTQOS] Gundogan, C., Schmidt, T. C., Waehlisch, M., Frey, M.,
Shzu-Juraschek, F., and J. Pfender, "Quality of Service
for ICN in the IoT", Work in Progress, Internet-Draft,
draft-gundogan-icnrg-iotqos-01, 8 July 2019,
<https://tools.ietf.org/html/draft-gundogan-icnrg-iotqos-
01>.
[Krol2018] Król, M., Habak, K., Oran, D., Kutscher, D., and I. [Krol2018] Król, M., Habak, K., Oran, D., Kutscher, D., and I.
Psaras, "RICE: Remote Method Invocation in ICN", in Psaras, "RICE: Remote Method Invocation in ICN", in ICN
ICN'18: Proceedings of the 5th ACM Conference on '18: Proceedings of the 5th ACM Conference on Information-
Information-Centric Networking September 21-23, 2018, Centric Networking, Boston, MA, USA,
Boston, MA, USA, DOI 10.1145/3267955.3267956, September DOI 10.1145/3267955.3267956, September 2018,
2018, <https://conferences.sigcomm.org/acm- <https://conferences.sigcomm.org/acm-icn/2018/proceedings/
icn/2018/proceedings/icn18-final9.pdf>. icn18-final9.pdf>.
[Mahdian2016] [Mahdian2016]
Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, Mahdian, M., Arianfar, S., Gibson, J., and D. Oran,
"MIRCC: Multipath-aware ICN Rate-based Congestion "MIRCC: Multipath-aware ICN Rate-based Congestion
Control", in Proceedings of the 3rd ACM Conference on Control", in ACM-ICN '16: Proceedings of the 3rd ACM
Information-Centric Networking, Conference on Information-Centric Networking,
DOI 10.1145/2984356.2984365, September 2016, DOI 10.1145/2984356.2984365, September 2016,
<http://conferences2.sigcomm.org/acm-icn/2016/proceedings/ <http://conferences2.sigcomm.org/acm-icn/2016/proceedings/
p1-mahdian.pdf>. p1-mahdian.pdf>.
[minmaxfairness] [minmaxfairness]
"Max-min Fairness", no date, Wikipedia, "Max-min fairness", June 2021,
<https://en.wikipedia.org/wiki/Max-min_fairness>. <https://en.wikipedia.org/w/index.php?title=Max-
min_fairness&oldid=1028246910>.
[Moiseenko2017] [Moiseenko2017]
Moiseenko, I. and D. Oran, "Path Switching in Content Moiseenko, I. and D. Oran, "Path Switching in Content
Centric and Named Data Networks", in ICN '17: Proceedings Centric and Named Data Networks", in ICN '17: Proceedings
of the 4th ACM Conference on Information-Centric of the 4th ACM Conference on Information-Centric
Networking, DOI 10.1145/3125719.3125721, September 2017, Networking, DOI 10.1145/3125719.3125721, September 2017,
<https://conferences.sigcomm.org/acm-icn/2017/proceedings/ <https://conferences.sigcomm.org/acm-icn/2017/proceedings/
icn17-2.pdf>. icn17-2.pdf>.
[NDN] "Named Data Networking", various, [NDN] "Named Data Networking: Executive Summary",
<https://named-data.net/project/execsummary/>. <https://named-data.net/project/execsummary/>.
[NDNTutorials] [NDNTutorials]
"NDN Tutorials", various, "NDN Tutorials",
<https://named-data.net/publications/tutorials/>. <https://named-data.net/publications/tutorials/>.
[NWC-CCN-REQS]
Matsuzono, K., Asaeda, H., and C. Westphal, "Network
Coding for Content-Centric Networking / Named Data
Networking: Considerations and Challenges", Work in
Progress, Internet-Draft, draft-irtf-nwcrg-nwc-ccn-reqs-
05, 22 January 2021, <https://tools.ietf.org/html/draft-
irtf-nwcrg-nwc-ccn-reqs-05>.
[Oran2018QoSslides] [Oran2018QoSslides]
Oran, D., "Thoughts on Quality of Service for NDN/CCN- Oran, D., "Thoughts on Quality of Service for NDN/CCN-
style ICN protocol architectures", presented at ICNRG style ICN protocol architectures", presented at ICNRG
Interim Meeting, Cambridge MA, 24 September 2018, Interim Meeting, Cambridge, MA, 24 September 2018,
<https://datatracker.ietf.org/meeting/interim-2018-icnrg- <https://datatracker.ietf.org/meeting/interim-2018-icnrg-
03/materials/slides-interim-2018-icnrg-03-sessa-thoughts- 03/materials/slides-interim-2018-icnrg-03-sessa-thoughts-
on-qos-for-ndnccn-style-icn-protocol-architectures>. on-qos-for-ndnccn-style-icn-protocol-architectures>.
[proportionalfairness] [proportionalfairness]
"Proportionally Fair", no date, Wikipedia, "Proportional-fair scheduling", June 2021,
<https://en.wikipedia.org/wiki/Proportionally_fair>. <https://en.wikipedia.org/w/index.php?title=Proportional-
fair_scheduling&oldid=1027073289>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
skipping to change at page 28, line 28 skipping to change at line 1267
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006, DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>. <https://www.rfc-editor.org/info/rfc4594>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[Schneider2016] [Schneider2016]
Schneider, K., Yi, C., Zhang, B., and L. Zhang, ""A Schneider, K., Yi, C., Zhang, B., and L. Zhang, "A
Practical Congestion Control Scheme for Named Data Practical Congestion Control Scheme for Named Data
Networking", in ACM-ICN '16: Proceedings of the 3rd ACM Networking", in ACM-ICN '16: Proceedings of the 3rd ACM
Conference on Information-Centric Networking, Conference on Information-Centric Networking,
DOI 10.1145/2984356.2984369, September 2016, DOI 10.1145/2984356.2984369, September 2016,
<http://conferences2.sigcomm.org/acm-icn/2016/proceedings/ <http://conferences2.sigcomm.org/acm-icn/2016/proceedings/
p21-schneider.pdf>. p21-schneider.pdf>.
[Shenker2006] [Shenker2006]
Shenker, S., "Fundamental Design Issues for the Future Shenker, S., "Fundamental design issues for the future
Internet", in IEEE Journal on Selected Areas in Internet", in IEEE Journal on Selected Areas in
Communications, Vol. 13, No. 7, DOI 10.1109/49.414637, Communications, Vol. 13, No. 7, DOI 10.1109/49.414637,
September 2006, September 2006,
<https://dl.acm.org/citation.cfm?id=2316898>. <https://dl.acm.org/doi/10.1109/49.414637>.
[Song2018] Song, J., Lee, M., and T. Kwon, "SMIC: Subflow-level [Song2018] Song, J., Lee, M., and T. Kwon, "SMIC: Subflow-level
Multi-path Interest Control for Information Centric Multi-path Interest Control for Information Centric
Networking", ICN '18: Proceedings of the 5th ACM Networking", ICN '18: Proceedings of the 5th ACM
Conference on Information-Centric Networking, Conference on Information-Centric Networking,
DOI 10.1145/3267955.3267971, September 2018, DOI 10.1145/3267955.3267971, September 2018,
<https://conferences.sigcomm.org/acm-icn/2018/proceedings/ <https://conferences.sigcomm.org/acm-icn/2018/proceedings/
icn18-final62.pdf>. icn18-final62.pdf>.
[Tseng2003] [Tseng2003]
Tseng, CH.J., "The performance of QoS-aware IP multicast Tseng, C.-J. and C.-H. Chen, "The performance of QoS-aware
routing protocols", in Networks, Vol:42, No:2, IP multicast routing protocols", in Networks, Vol. 42,
DOI 10.1002/net.10084, September 2003, DOI 10.1002/net.10084, September 2003,
<https://onlinelibrary.wiley.com/doi/abs/10.1002/ <https://onlinelibrary.wiley.com/doi/abs/10.1002/
net.10084>. net.10084>.
[Wang2000] Wang, B. and J.C. Hou, "Multicast routing and its QoS [Wang2000] Wang, B. and J. C. Hou, "Multicast routing and its QoS
extension: problems, algorithms, and protocols", in IEEE extension: problems, algorithms, and protocols", in IEEE
Network, Vol:14, Issue:1, Jan/Feb 2000, Network, Vol. 14, Issue 1, DOI 10.1109/65.819168, January
DOI 10.1109/65.819168, January 2000, 2000, <https://ieeexplore.ieee.org/document/819168>.
<https://ieeexplore.ieee.org/
document/819168?arnumber=819168>.
[Wang2013] Wang, Y., Rozhnova, N., Narayanan, A., Oran, D., and I. [Wang2013] Wang, Y., Rozhnova, N., Narayanan, A., Oran, D., and I.
Rhee, "An Improved Hop-by-hop Interest Shaper for Rhee, "An improved Hop-by-hop Interest Shaper for
Congestion Control in Named Data Networking", in ICN '13: Congestion Control in Named Data Networking", in ACM
Proceedings of the 3rd ACM SIGCOMM workshop on SIGCOMM Computer Communication Review,
Information-centric networking, August 2013,
DOI 10.1145/2534169.2491233, August 2013, DOI 10.1145/2534169.2491233, August 2013,
<http://conferences.sigcomm.org/sigcomm/2013/papers/icn/ <https://conferences.sigcomm.org/sigcomm/2013/papers/icn/
p55.pdf>. p55.pdf>.
Author's Address Author's Address
Dave Oran Dave Oran
Network Systems Research and Design Network Systems Research and Design
4 Shady Hill Square 4 Shady Hill Square
Cambridge, MA 02138 Cambridge, MA 02138
United States of America United States of America
 End of changes. 196 change blocks. 
591 lines changed or deleted 597 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/