rfc9064.original.xml   rfc9064.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
category="info" docName="draft-oran-icnrg-qosarch-06" docName="draft-oran-icnrg-qosarch-06"
ipr="trust200902" number="9064"
obsoletes="" submissionType="IRTF"
updates="" category="info"
submissionType="IRTF" ipr="trust200902"
xml:lang="en" obsoletes=""
tocInclude="true" updates=""
tocDepth="4" xml:lang="en"
symRefs="true" tocInclude="true"
sortRefs="true" tocDepth="4"
version="3"> symRefs="true"
<!-- xml2rfc v2v3 conversion 2.40.0 --> sortRefs="true"
<!-- category values: std, bcp, info, exp, and historic version="3">
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front> <front>
<title abbrev="Thoughts on ICN QoS Architecture"> <title abbrev="Thoughts on ICN QoS Architecture">
Considerations in the development of a QoS Architecture for CCNx-like ICN pr otocols Considerations in the Development of a QoS Architecture for CCNx-Like Inform ation-Centric Networking Protocols
</title> </title>
<seriesInfo name="Internet-Draft" value="draft-oran-icnrg-qosarch-06"/> <seriesInfo name="RFC" value="9064"/>
<author fullname="Dave Oran" surname="D. Oran"> <author fullname="Dave Oran" surname="D. Oran">
<organization>Network Systems Research and Design</organization> <organization>Network Systems Research and Design</organization>
<address> <address>
<postal> <postal>
<street>4 Shady Hill Square</street> <street>4 Shady Hill Square</street>
<city>Cambridge</city> <city>Cambridge</city>
<region>MA</region> <region>MA</region>
<code>02138</code> <code>02138</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone/>
<email>daveoran@orandom.net</email> <email>daveoran@orandom.net</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date year="2020"/> <date year="2021" month="June" />
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations --> <workgroup>Information-Centric Networking</workgroup>
<workgroup>ICNRG</workgroup>
<keyword>ICN</keyword> <keyword>ICN</keyword>
<keyword>QoS</keyword> <keyword>QoS</keyword>
<keyword>congestion control</keyword> <keyword>congestion control</keyword>
<keyword>admission control</keyword> <keyword>admission control</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>This is a position paper. It documents the author's personal views on h ow Quality of Service (QoS) capabilities ought to be accommodated in ICN protoco ls like CCNx or NDN which employ flow-balanced Interest/Data exchanges and hop-b y-hop forwarding state as their fundamental machinery. It argues that such proto cols demand a substantially different approach to QoS from that taken in TCP/IP, and proposes specific design patterns to achieve both classification and differ entiated QoS treatment on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU and link bandwidth as a resource th at should be subject to explicitly unfair resource allocation. The proposed meth ods are intended to operate purely at the network layer, providing the primitive s needed to achieve both transport and higher layer QoS objectives. It explicitl y excludes any discussion of Quality of Experience (QoE) which can only be asses sed and controlled at the application layer or above. </t>
<t>This document is not a product of the IRTF Information-Centric Networki <t>This is a position paper. It documents the author's personal views on h
ng Research Group (ICNRG) but has been through formal last call and has the supp ow Quality of Service (QoS) capabilities ought to be accommodated in Information
ort of the participants in the research group for publication as an individual s -Centric Networking (ICN) protocols like Content-Centric Networking (CCNx) or Na
ubmission.</t> med Data Networking (NDN), which employ flow-balanced Interest/Data exchanges an
d hop-by-hop forwarding state as their fundamental machinery. It argues that suc
h protocols demand a substantially different approach to QoS from that taken in
TCP/IP and proposes specific design patterns to achieve both classification and
differentiated QoS treatment on both a flow and aggregate basis. It also conside
rs the effect of caches in addition to memory, CPU, and link bandwidth as resour
ces that should be subject to explicitly unfair resource allocation. The propose
d methods are intended to operate purely at the network layer, providing the pri
mitives needed to achieve transport- and higher-layer QoS objectives. It explici
tly excludes any discussion of Quality of Experience (QoE), which can only be as
sessed and controlled at the application layer or above. </t>
<t>This document is not a product of the IRTF Information-Centric Networki
ng Research Group (ICNRG) but has been through formal Last Call and has the supp
ort of the participants in the research group for publication as an individual s
ubmission.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>The TCP/IP protocol suite used on today's Internet has over 30 years of ac cumulated research and engineering into the provision of Quality of Service mach inery, employed with varying success in different environments. ICN protocols li ke Named Data Networking (NDN <xref target="NDN" format="default"/>) and Content -Centric Networking (CCNx <xref target="RFC8569" format="default"/>,<xref target ="RFC8609" format="default"/>) have an accumulated 10 years of research and very little deployment. We therefore have the opportunity to either recapitulate the approaches taken with TCP/IP (e.g. Intserv <xref target="RFC2998" format="defau lt"/> and Diffserv <xref target="RFC2474" format="default"/>) or design a new ar chitecture and associated mechanisms aligned with the properties of ICN protocol s which differ substantially from those of TCP/IP. This position paper advocates the latter approach and comprises the author's personal views on how Quality of Service (QoS) capabilities ought to be accommodated in ICN protocols like CCNx or NDN. Specifically, these protocols differ in fundamental ways from TCP/IP. Th e important differences are summarized in the following table:</t> <t>The TCP/IP protocol suite used on today's Internet has over 30 years of ac cumulated research and engineering into the provisioning of QoS machinery, emplo yed with varying success in different environments. ICN protocols like NDN <xref target="NDN" format="default"/> and CCNx <xref target="RFC8569" format="default "/> <xref target="RFC8609" format="default"/> have an accumulated ten years of r esearch and very little deployment. We therefore have the opportunity to either recapitulate the approaches taken with TCP/IP (e.g., Intserv <xref target="RFC29 98" format="default"/> and Diffserv <xref target="RFC2474" format="default"/>) o r design a new architecture and associated mechanisms aligned with the propertie s of ICN protocols, which differ substantially from those of TCP/IP. This positi on paper advocates the latter approach and comprises the author's personal views on how QoS capabilities ought to be accommodated in ICN protocols like CCNx or NDN. Specifically, these protocols differ in fundamental ways from TCP/IP. The i mportant differences are summarized in <xref target="IPvsICN" format="default"/> :</t>
<table anchor="IPvsICN" align="center"> <table anchor="IPvsICN" align="center">
<name>Differences between IP and ICN relevant to QoS architecture</name> <name>Differences between IP and ICN Relevant to QoS Architecture</name>
<thead> <thead>
<tr> <tr>
<th align="center">TCP/IP</th> <th align="center">TCP/IP</th>
<th align="center">CCNx or NDN</th> <th align="center">CCNx or NDN</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">Stateless forwarding</td> <td align="center">Stateless forwarding</td>
<td align="center">Stateful forwarding</td> <td align="center">Stateful forwarding</td>
</tr> </tr>
<tr> <tr>
<td align="center">Simple Packets</td> <td align="center">Simple packets</td>
<td align="center">Object model with optional caching</td> <td align="center">Object model with optional caching</td>
</tr> </tr>
<tr> <tr>
<td align="center">Pure datagram model</td> <td align="center">Pure datagram model</td>
<td align="center">Request-response model</td> <td align="center">Request-response model</td>
</tr> </tr>
<tr> <tr>
<td align="center">Asymmetric Routing</td> <td align="center">Asymmetric routing</td>
<td align="center">Symmetric Routing</td> <td align="center">Symmetric routing</td>
</tr> </tr>
<tr> <tr>
<td align="center">Independent flow directions</td> <td align="center">Independent flow directions</td>
<td align="center">Flow balance<sup>*</sup></td> <td align="center">Flow balance (see note below)</td>
</tr> </tr>
<tr> <tr>
<td align="center">Flows grouped by IP prefix and port</td> <td align="center">Flows grouped by IP prefix and port</td>
<td align="center">Flows grouped by name prefix</td> <td align="center">Flows grouped by name prefix</td>
</tr> </tr>
<tr> <tr>
<td align="center">End-to-end congestion control</td> <td align="center">End-to-end congestion control</td>
<td align="center">Hop-by-hop congestion control</td> <td align="center">Hop-by-hop congestion control</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<aside><t><sup>*</sup>Flow Balance is a property of NDN and CCNx that en <aside><t>Note: Flow balance is a property of NDN and CCNx that ensures
sures one Interest packet provokes a response of no more than one data packet. F one Interest packet provokes a response of no more than one Data packet. Further
urther discussion of the relevance of this to QoS can be found in <xref target=" discussion of the relevance of this to QoS can be found in <xref target="I-D.or
I-D.oran-icnrg-flowbalance"/></t></aside> an-icnrg-flowbalance"/>.</t></aside>
<t>This document proposes specific design patterns to achieve both flow c
<t>This document proposes specific design patterns to achieve both flow c lassification and differentiated QoS treatment for ICN on both a flow and aggreg
lassification and differentiated QoS treatment for ICN on both a flow and aggreg ate basis. It also considers the effect of caches in addition to memory, CPU, an
ate basis. It also considers the effect of caches in addition to memory, CPU and d link bandwidth as resources that should be subject to explicitly unfair resour
link bandwidth as a resource that should be subject to explicitly unfair resour ce allocation. The proposed methods are intended to operate purely at the networ
ce allocation. The proposed methods are intended to operate purely at the networ k layer, providing the primitives needed to achieve both transport and higher-la
k layer, providing the primitives needed to achieve both transport and higher la yer QoS objectives. It does not propose detailed protocol machinery to achieve t
yer QoS objectives. It does not propose detailed protocol machinery to achieve t hese goals; it leaves these to supplementary specifications, such as <xref targe
hese goals; it leaves these to supplementary specifications, such as <xref targe t="I-D.moiseenko-icnrg-flowclass" format="default"/> and <xref target="I-D.anilj
t="I-D.moiseenko-icnrg-flowclass" format="default"/> and <xref target="I-D.anilj -icnrg-dnc-qos-icn" format="default"/>. It explicitly excludes any discussion of
-icnrg-dnc-qos-icn" format="default"/>. It explicitly excludes any discussion of QoE, which can only be assessed and controlled at the application layer or abov
Quality of Experience (QoE) which can only be assessed and controlled at the ap e.</t>
plication layer or above.</t>
<t>Much of this document is derived from presentations the author has given at ICNRG meetings over the last few years that are available through the IETF da tatracker (see, for example <xref target="Oran2018QoSslides" format="default"/>) .</t> <t>Much of this document is derived from presentations the author has given at ICNRG meetings over the last few years that are available through the IETF da tatracker (see, for example, <xref target="Oran2018QoSslides" format="default"/> ).</t>
<section><name>Applicability Assessment by ICNRG Chairs</name> <section><name>Applicability Assessment by ICNRG Chairs</name>
<t>QoS in ICN is an important topic with a huge design space. ICNRG has b een discussing different specific protocol mechanisms as well as conceptual appr oaches. This document presents architectural considerations for QoS, leveraging ICN properties instead of merely applying IP-QoS mechanisms — without defining a specific architecture or specific protocols mechanisms yet. However, there is c onsensus in ICNRG that this document, clarifying the author’s views, could inspi re such work and should hence be published as a position paper.</t> <t>QoS in ICN is an important topic with a huge design space. ICNRG has b een discussing different specific protocol mechanisms as well as conceptual appr oaches. This document presents architectural considerations for QoS, leveraging ICN properties instead of merely applying IP-QoS mechanisms, without defining a specific architecture or specific protocol mechanisms yet. However, there is con sensus in ICNRG that this document, clarifying the author's views, could inspire such work and should hence be published as a position paper.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
document are to be interpreted as described in <xref target="RFC2119" fo NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
rmat="default">RFC 2119</xref>.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.</t>
</section> </section>
<section anchor="background" numbered="true" toc="default"> <section anchor="background" numbered="true" toc="default">
<name>Background on Quality of Service in network protocols</name> <name>Background on Quality of Service in Network Protocols</name>
<!-- <name>Background on the nature and properties of Quality of Service in netw
ork protocols</name> -->
<t>Much of this background material is tutorial and can be simply skipped by readers familiar with the long and checkered history of quality of service in p acket networks. Other parts of it are polemical yet serve to illuminate the auth or's personal biases and technical views.</t> <t>Much of this background material is tutorial and can be simply skipped by readers familiar with the long and checkered history of quality of service in p acket networks. Other parts of it are polemical yet serve to illuminate the auth or's personal biases and technical views.</t>
<t>All networking systems provide some degree of "quality of service" in tha
<t>All networking systems provide some degree of "quality of service" in tha t they exhibit nonzero utility when offered traffic to carry. In other words, th
t they exhibit non-zero utility when offered traffic to carry. In other words, t e network is totally useless if it never delivers any of the traffic injected by
he network is totally useless if it never delivers any of the traffic injected b applications. The term QoS is therefore more correctly applied in a more restri
y applications. The term QoS is therefore more correctly applied in a more restr cted sense to describe systems that control the allocation of various resources
icted sense to describe systems that control the allocation of various resources in order to achieve <em>managed unfairness</em>. Absent explicit mechanisms to
in order to achieve <em>managed unfairness</em>. Absent explicit mechanisms to decide which traffic to treat unfairly, most systems try to achieve some form of
decide what traffic to be unfair to, most systems try to achieve some form of " "fairness" in the allocation of resources, optimizing the overall utility deliv
fairness" in the allocation of resources, optimizing the overall utility deliver ered to all traffic under the constraint of available resources. From this, it s
ed to all offered load under the constraint of available resources. From this it hould be obvious that you cannot use QoS mechanisms to create or otherwise incre
should be obvious that you cannot use QoS mechanisms to create or otherwise inc ase resource capacity! In fact, all known QoS schemes have nonzero overhead and
rease resource capacity! In fact, all known QoS schemes have non-zero overhead a hence may (albeit slightly) decrease the total resources available to carry user
nd hence may (albeit slightly) decrease the total resources available to carry u traffic.</t>
ser traffic.</t>
<t>Further, accumulated experience seems to indicate that QoS is helpful in a fairly narrow range of network conditions:</t> <t>Further, accumulated experience seems to indicate that QoS is helpful in a fairly narrow range of network conditions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If your resources are lightly loaded, you don't need it, as neither <li>If your resources are lightly loaded, you don't need it, as neither
congestive loss nor substantial queueing delay occurs</li> congestive loss nor substantial queuing delay occurs.</li>
<li>If your resources are heavily oversubscribed, it doesn't save you. S <li>If your resources are heavily oversubscribed, it doesn't save you. S
o many users will be unhappy that you are probably not delivering a viable servi o many users will be unhappy that you are probably not delivering a viable servi
ce</li> ce.</li>
<li> <li>
<t>Failures can rapidly shift your state from the first above to the s econd, in which case either: <t>Failures can rapidly shift your state from the first above to the s econd, in which case either:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>your QoS machinery cannot respond quickly enough to maintain the <li>Your QoS machinery cannot respond quickly enough to maintain the
advertised service quality continuously, or</li> advertised service quality continuously, or</li>
<li>resource allocations are sufficiently conservative to result in <li>Resource allocations are sufficiently conservative to result in
substantial wasted capacity under non-failure conditions</li> substantial wasted capacity under non-failure conditions.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>Nevertheless, though not universally deployed, QoS is advantageous at lea st for some applications and some network environments. Some examples include:</ t> <t>Nevertheless, though not universally deployed, QoS is advantageous at lea st for some applications and some network environments. Some examples include:</ t>
<ul spacing="normal"> <ul spacing="normal">
<li>applications with steep utility functions <xref target="Shenker2006" <li>Applications with steep utility functions <xref target="Shenker2006"
format="default"/>, such as real-time multimedia</li> format="default"/>, such as real-time multimedia</li>
<li>applications with safety-critical operational constraints, such as a <li>Applications with safety-critical operational constraints, such as a
vionics or industrial automation</li> vionics or industrial automation</li>
<li>dedicated or tightly managed networks whose economics depend on stri <li>Dedicated or tightly managed networks whose economics depend on stri
ct adherence to challenging service level agreements (SLAs)</li> ct adherence to challenging service level agreements (SLAs)</li>
</ul> </ul>
<t>Another factor in the design and deployment of QoS is the scalability and scope over which the desired service can be achieved. Here there are two major considerations, one technical, the other economic/political:</t> <t>Another factor in the design and deployment of QoS is the scalability and scope over which the desired service can be achieved. Here there are two major considerations, one technical, the other economic/political:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Some signaled QoS schemes, such as RSVP (Resource reSerVation Protoc <li>Some signaled QoS schemes, such as the Resource reSerVation Protocol
ol) <xref target="RFC2205" format="default"/>, maintain state in routers for eac (RSVP) <xref target="RFC2205" format="default"/>, maintain state in routers for
h flow, which scales linearly with the number of flows. For core routers through each flow, which scales linearly with the number of flows. For core routers thr
which pass millions to billions of flows, the memory required is infeasible to ough which pass millions to billions of flows, the memory required is infeasible
provide.</li> to provide.</li>
<li>The Internet is comprised of many minimally cooperating autonomous s <li>The Internet is comprised of many minimally cooperating autonomous s
ystems <xref target="AS" format="default"/>. There are practically no successful ystems <xref target="AS" format="default"/>. There are practically no successful
examples of QoS deployments crossing the AS boundaries of multiple service prov examples of QoS deployments crossing the AS boundaries of multiple service prov
iders. This in almost all cases limits the applicability of QoS capabilities to iders. In almost all cases, this limits the applicability of QoS capabilities to
be intra-domain.</li> be intra-domain.</li>
</ul> </ul>
<t>This document adopts a narrow definition of QoS as <em>managed unfairness </em><sup>*</sup>. However, much of the networking literature uses the term more colloquially as applying to any mechanism that improves overall performance. On e could use a different, broader definition of QoS that encompasses optimizing t he allocation of network resources across all offered traffic without considerin g individual users’ traffic. A consequence would be the need to cover whether (a nd how) ICN might result in better overall performance than IP under constant re source conditions, which is a much broader goal than that attempted here. The ch osen narrower scope comports with the commonly understood meaning of “QoS” in th e research community. Under this scope, and under constant resource constraints, the only way to provide traffic discrimination is in fact to sacrifice fairness . Readers assuming the broader context will find a large class of proven techniq ues to be ignored. This is intentional. Among these are seamless producer mobili ty schemes like <xref target='Auge2018'>MAPME</xref>, and network coding of ICN data as discussed in <xref target='I-D.irtf-nwcrg-nwc-ccn-reqs'/>.</t> <t>This document adopts a narrow definition of QoS as <em>managed unfairness </em> (see note below). However, much of the networking literature uses the term more colloquially, applying it to any mechanism that improves overall performan ce. One could use a different, broader definition of QoS that encompasses optimi zing the allocation of network resources across all offered traffic without cons idering individual users' traffic. A consequence would be the need to cover whet her (and how) ICN might result in better overall performance than IP under const ant resource conditions, which is a much broader goal than that attempted here. The chosen narrower scope comports with the commonly understood meaning of "QoS" in the research community. Under this scope, and under constant resource constr aints, the only way to provide traffic discrimination is in fact to sacrifice fa irness. Readers assuming the broader context will find a large class of proven t echniques to be ignored. This is intentional. Among these are seamless producer mobility schemes like <xref target='Auge2018'>MAP-Me</xref> and network coding o f ICN data as discussed in <xref target='I-D.irtf-nwcrg-nwc-ccn-reqs'/>.</t>
<aside><t><sup>*</sup>This term to explain QoS is generally ascribed to Van Jacobson, who in talks in the late 1990's said "[The problem we are solving is t o] Give ‘better’ service to some at the expense of giving worse service to other s. QoS fantasies to the contrary, it’s a zero sum game. In other words, QoS is < em>managed unfairness</em>."</t></aside> <aside><t>Note: The term <em>managed unfairness</em> used to explain QoS is generally ascribed to Van Jacobson, who in talks in the late 1990s said, "[The p roblem we are solving is to] Give 'better' service to some at the expense of giv ing worse service to others. QoS fantasies to the contrary, it's a zero-sum game . In other words, QoS is <em>managed unfairness</em>."</t></aside>
<t>Finally, the relationship between QoS and either accounting or billing is murky. Some schemes can accurately account for resource consumption and ascerta in to which user to allocate the usage. Others cannot. While the choice of mecha nism may have important practical economic and political consequences for cost a nd workable business models, this document considers none of those things and di scusses QoS only in the context of providing managed unfairness.</t> <t>Finally, the relationship between QoS and either accounting or billing is murky. Some schemes can accurately account for resource consumption and ascerta in to which user to allocate the usage. Others cannot. While the choice of mecha nism may have important practical economic and political consequences for cost a nd workable business models, this document considers none of those things and di scusses QoS only in the context of providing managed unfairness.</t>
<t>For those unfamiliar with ICN protocols, a brief description of how NDN a nd CCNx operate as a packet network is below in <xref target="ICNbasics"/>. Some further background on congestion control for ICN follows in <xref target="CCbas ics"/>.</t> <t>For those unfamiliar with ICN protocols, a brief description of how NDN a nd CCNx operate as a packet network is in <xref target="ICNbasics"/>. Some furth er background on congestion control for ICN follows in <xref target="CCbasics"/> .</t>
<section anchor="ICNbasics" numbered="true" toc="default"> <section anchor="ICNbasics" numbered="true" toc="default">
<name>Basics on how ICN protocols like NDN and CCNx work</name> <name>Basics on How ICN Protocols like NDN and CCNx Work</name>
<t>The following is intended as a brief summary of the salient features o <t>The following summarizes the salient features of the NDN and CCNx ICN
f the NDN and CCnx ICN protocols relevant to congestion control and QoS. Quite e protocols relevant to congestion control and QoS. Quite extensive tutorial infor
xtensive tutorial information may be found in a number of places including mater mation may be found in a number of places, including material available from <xr
ial available from <xref target="NDNTutorials"/>.</t> ef target="NDNTutorials"/>.</t>
<t>In NDN and CCNx, all protocol interactions operate as a two-way handsh ake. Named content is requested by a <em>consumer</em> via an <em>Interest messa ge</em> which is routed hop-by-hop through a series of <em>forwarders</em> until it reaches a node that stores the requested data. This can be either the <em>pr oducer</em> of the data, or a forwarder holding a cached copy of the requested d ata. The content matching the name in the Interest is returned to the requester over the <em>inverse</em> of the path traversed by the corresponding Interest.</ t> <t>In NDN and CCNx, all protocol interactions operate as a two-way handsh ake. Named content is requested by a <em>consumer</em> via an <em>Interest messa ge</em> that is routed hop-by-hop through a series of <em>forwarders</em> until it reaches a node that stores the requested data. This can be either the <em>pro ducer</em> of the data or a forwarder holding a cached copy of the requested dat a. The content matching the name in the Interest message is returned to the requ ester over the <em>inverse</em> of the path traversed by the corresponding Inter est.</t>
<t>Forwarding in CCNx and NDN is <em>per-packet stateful</em>. Routing in formation to select next-hops for an Interest is obtained from a <em>Forwarding Information Base (FIB)</em> which is similar in function to the FIB in an IP rou ter, except that it holds name prefixes rather than IP address prefixes. Convent ionally a <em>Longest Name Prefix Match (LNPM)</em> is used for lookup, although other algorithms are possible including controlled flooding and adaptive learni ng based on prior history.</t> <t>Forwarding in CCNx and NDN is <em>per-packet stateful</em>. Routing in formation to select next hop(s) for an Interest is obtained from a <em>Forwardin g Information Base (FIB)</em>, which is similar in function to the FIB in an IP router except that it holds name prefixes rather than IP address prefixes. Conve ntionally, a <em>Longest Name Prefix Match (LNPM)</em> is used for lookup, altho ugh other algorithms are possible, including controlled flooding and adaptive le arning based on prior history.</t>
<t>Each Interest message leaves a trail of "breadcrumbs" as state in each forwarder. This state, held in a data structure known as a <em>Pending Interest Table (PIT)</em> is used to forward the returning Data message to the consumer. Since the PIT constitutes per-packet state it is therefore a large consumer of memory resources especially in forwarders carrying high traffic loads over long Round Trip Time (RTT) paths, and hence plays a substantial role as a QoS-contro llable resource in ICN forwarders.</t> <t>Each Interest message leaves a trail of "breadcrumbs" as state in each forwarder. This state, held in a data structure known as a <em>Pending Interest Table (PIT)</em>, is used to forward the returning Data message to the consumer . Since the PIT constitutes per-packet state, it is therefore a large consumer o f memory resources, especially in forwarders carrying high traffic loads over lo ng Round-Trip Time (RTT) paths, and hence plays a substantial role as a QoS-cont rollable resource in ICN forwarders.</t>
<t>In addition to its role in forwarding Interest messages and returning the corresponding Data messages, an ICN forwarder can also operate as a cache, o ptionally storing a copy of any Data messages it has seen in a local data struct ure known as a <em>Content Store (CS)</em>. Data in the Content Store may be ret urned in response to a matching Interest rather than forwarding the Interest fur ther through the network to the original Producer. Both CCNx and NDN have a vari ety of ways to configure caching, including mechanisms to avoid both cache pollu tion and cache poisoning (these are clearly beyond the scope of this brief intro duction).</t> <t>In addition to its role in forwarding Interest messages and returning the corresponding Data messages, an ICN forwarder can also operate as a cache, o ptionally storing a copy of any Data messages it has seen in a local data struct ure known as a <em>Content Store (CS)</em>. Data in the CS may be returned in re sponse to a matching Interest rather than forwarding the Interest further throug h the network to the original Producer. Both CCNx and NDN have a variety of ways to configure caching, including mechanisms to avoid both cache pollution and ca che poisoning (these are clearly beyond the scope of this brief introduction).</ t>
</section> </section>
<section anchor="CCbasics" numbered="true" toc="default"> <section anchor="CCbasics" numbered="true" toc="default">
<name>Congestion Control basics relevant to ICN</name> <name>Congestion Control Basics Relevant to ICN</name>
<t>In any packet network that multiplexes traffic among multiple sources a nd destinations, congestion control is necessary in order to:</t> <t>In any packet network that multiplexes traffic among multiple sources a nd destinations, congestion control is necessary in order to:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Prevent collapse of utility due to overload, where the total offer ed service declines as load increases, perhaps precipitously, rather than increa sing or remaining flat.</li> <li>Prevent collapse of utility due to overload, where the total offer ed service declines as load increases, perhaps precipitously, rather than increa sing or remaining flat.</li>
<li>Avoid starvation of some traffic due to excessive demand by other traffic.</li> <li>Avoid starvation of some traffic due to excessive demand by other traffic.</li>
<li>Beyond the basic protections against starvation, achieve "fairness " among competing traffic. Two common objective functions are <xref target="minm axfairness" format="default"/> and <xref target="proportionalfairness" format="d efault"/> both of which have been implemented and deployed successfully on packe t networks for many years.</li> <li>Beyond the basic protections against starvation, achieve "fairness " among competing traffic. Two common objective functions are max-min fairness < xref target="minmaxfairness" format="default"/> and proportional fairness <xref target="proportionalfairness" format="default"/>, both of which have been implem ented and deployed successfully on packet networks for many years.</li>
</ol> </ol>
<t>Before moving on to QoS, it is useful to consider how congestion cont rol works in NDN or CCNx. Unlike the IP protocol family, which relies exclusivel y on end-to-end congestion control (e.g. TCP<xref target="RFC0793" format="defau lt"/>, DCCP<xref target="RFC4340" format="default"/>, SCTP<xref target="RFC4960" format="default"/>, QUIC<xref target="I-D.ietf-quic-transport" format="default" />), CCNx and NDN can employ hop-by-hop congestion control. There is per-Interes t/Data state at every hop of the path and therefore outstanding Interests provid e information that can be used to optimize resource allocation for data returnin g on the inverse path, such as bandwidth sharing, prioritization and overload co ntrol. In current designs, this allocation is often done using Interest counting . By accepting one Interest packet from a downstream node, implicitly this provi des a guarantee (either hard or soft) that there is sufficient bandwidth on the inverse direction of the link to send back one Data packet. A number of congesti on control schemes have been developed for ICN that operate in this fashion, for example <xref target="Wang2013" format="default"/>, <xref target="Mahdian2016" format="default"/>, <xref target="Song2018" format="default"/>, <xref target="Ca rofiglio2012" format="default"/>. Other schemes, like <xref target="Schneider201 6" format="default"/> neither count nor police Interests, but instead monitor qu eues using AQM (active queue management) to mark returning Data packets that hav e experienced congestion. This later class of schemes is similar to those used o n IP in the sense that they depend on consumers adequately reducing their rate o f Interest injection to avoid Data packet drops due to buffer overflow in forwar ders. The former class of schemes is (arguably) more robust against mis-behavior by consumers. <t>Before moving on to QoS, it is useful to consider how congestion cont rol works in NDN or CCNx. Unlike the IP protocol family, which relies exclusivel y on end-to-end congestion control (e.g., TCP <xref target="RFC0793" format="def ault"/>, DCCP <xref target="RFC4340" format="default"/>, SCTP <xref target="RFC4 960" format="default"/>, and QUIC <xref target="RFC9000" format="default"/>), CC Nx and NDN can employ hop-by-hop congestion control. There is per-Interest/Data state at every hop of the path, and therefore outstanding Interests provide info rmation that can be used to optimize resource allocation for data returning on t he inverse path, such as bandwidth sharing, prioritization, and overload control . In current designs, this allocation is often done using Interest counting. By accepting one Interest packet from a downstream node, this implicitly provides a guarantee (either hard or soft) that there is sufficient bandwidth on the inver se direction of the link to send back one Data packet. A number of congestion co ntrol schemes have been developed for ICN that operate in this fashion, for exam ple, <xref target="Wang2013" format="default"/>, <xref target="Mahdian2016" form at="default"/>, <xref target="Song2018" format="default"/>, and <xref target="Ca rofiglio2012" format="default"/>. Other schemes, like <xref target="Schneider201 6" format="default"/>, neither count nor police Interests but instead monitor qu eues using AQM (active queue management) to mark returning Data packets that hav e experienced congestion. This later class of schemes is similar to those used o n IP in the sense that they depend on consumers adequately reducing their rate o f Interest injection to avoid Data packet drops due to buffer overflow in forwar ders. The former class of schemes is (arguably) more robust against misbehavior by consumers.
</t> </t>
<t>Given the stochastic nature of round trip times, and the ubiquity of wireless links and encapsulation tunnels with variable bandwidth, a simple schem e that admits interests only based on a time-invariant estimate of the returning link bandwidth will perform poorly. However, two characteristics of NDN and CCN x-like protocols can help substantially to improve the accuracy and responsivene ss of the bandwidth allocation: <t>Given the stochastic nature of RTTs, and the ubiquity of wireless lin ks and encapsulation tunnels with variable bandwidth, a simple scheme that admit s Interests only based on a time-invariant estimate of the returning link bandwi dth will perform poorly. However, two characteristics of NDN and CCNx-like proto cols can help substantially to improve the accuracy and responsiveness of the ba ndwidth allocation:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>RTT is bounded by the inclusion of an <em>Interest Lifetime</em> i <li>RTT is bounded by the inclusion of an <em>Interest Lifetime</em> i
n each Interest message, which puts an upper bound on the RTT uncertainty for an n each Interest message, which puts an upper bound on the RTT uncertainty for an
y given Interest/Data exchange. If Interest lifetimes are kept reasonably short y given Interest/Data exchange. If Interest Lifetimes are kept reasonably short
(a few RTTs) the allocation of local forwarder resources do not have to deal wit (a few RTTs), the allocation of local forwarder resources do not have to deal wi
h an arbitrarily long tail. One could in fact do a deterministic allocation on t th an arbitrarily long tail. One could in fact do a deterministic allocation on
his basis, but the result would be highly pessimistic. Nevertheless, having a cu this basis, but the result would be highly pessimistic. Nevertheless, having a c
t-off does improve the performance of an optimistic allocation scheme.</li> utoff does improve the performance of an optimistic allocation scheme.</li>
<li>Returning Data packets can be congestion marked by an ECN-like mar <li>A congestion marking scheme like that used in Explicit Congestion
king scheme if the inverse link starts experiencing long queue occupancy or othe Notification (ECN) can be used to mark returning Data packets if the inverse lin
r congestion indication. Unlike TCP/IP, where the rate adjustment can only be do k starts experiencing long queue occupancy or other congestion indication. Unlik
ne end-to-end, this feedback is usable immediately by the downstream ICN forward e TCP/IP, where the rate adjustment can only be done end-to-end, this feedback i
er and the Interest shaping rate lowered after a single link RTT. This may allow s usable immediately by the downstream ICN forwarder, and the Interest shaping r
less pessimistic rate adjustment schemes than the Additive Increase, Multiplica ate is lowered after a single link RTT. This may allow rate adjustment schemes t
tive Decrease (AIMD) with .5 multiplier that is commonly used on TCP/IP networks hat are less pessimistic than the Additive Increase, Multiplicative Decrease (AI
. It also allows the rate adjustments to be spread more accurately among the Int MD) scheme with .5 multiplier that is commonly used on TCP/IP networks. It also
erest/Data flows traversing a link sending congestion signals.</li> allows the rate adjustments to be spread more accurately among the Interest/Data
flows traversing a link sending congestion signals.</li>
</ol> </ol>
<t>A useful discussion of these properties and how they demonstrate the advantages of ICN approaches to congestion control can be found in <xref target= "Carofiglio2016" format="default"/></t> <t>A useful discussion of these properties and how they demonstrate the advantages of ICN approaches to congestion control can be found in <xref target= "Carofiglio2016" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="basics" numbered="true" toc="default"> <section anchor="basics" numbered="true" toc="default">
<name>What can we control to achieve QoS in ICN?</name> <name>What Can We Control to Achieve QoS in ICN?</name>
<t>QoS is achieved through managed unfairness in the allocation of resourc <t>QoS is achieved through managed unfairness in the allocation of resourc
es in network elements, particularly in the routers doing forwarding of ICN pack es in network elements, particularly in the routers that forward ICN packets. He
ets. So, a first order question is what resources need to be allocated, and how nce, the first-order questions are the following: Which resources need to be all
to ascertain which traffic gets what allocations. In the case of CCNx or NDN the ocated? How do you ascertain which traffic gets those allocations? In the case o
important network element resources are:</t> f CCNx or NDN, the important network element resources are given in <xref target
="ICNresources" format="default"/>:</t>
<table anchor="ICNresources" align="center"> <table anchor="ICNresources" align="center">
<name>ICN-related Network Element Resources</name> <name>ICN-Related Network Element Resources</name>
<thead> <thead>
<tr> <tr>
<th align="center">Resource</th> <th align="left">Resource</th>
<th align="left">ICN Usage</th> <th align="left">ICN Usage</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">Communication Link capacity</td> <td align="left">Communication link capacity</td>
<td align="left">buffering for queued packets</td> <td align="left">buffering for queued packets</td>
</tr> </tr>
<tr> <tr>
<td align="center">Content Store capacity</td> <td align="left">CS capacity</td>
<td align="left">to hold cached data</td> <td align="left">to hold cached data</td>
</tr> </tr>
<tr> <tr>
<td align="center">Forwarder memory</td> <td align="left">Forwarder memory</td>
<td align="left">for the Pending Interest Table (PIT)</td> <td align="left">for the PIT</td>
</tr> </tr>
<tr> <tr>
<td align="center">Compute capacity</td> <td align="left">Compute capacity</td>
<td align="left">for forwarding packets, including the cost of Forwa <td align="left">for forwarding packets, including the cost of FIB l
rding Information Base (FIB) lookups.</td> ookups</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>For these resources, any QoS scheme has to specify two things: <t>For these resources, any QoS scheme has to specify two things:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>How do you create <em>equivalence classes</em> (a.k.a. flows) of tra ffic to which different QoS treatments are applied?</li> <li>How do you create <em>equivalence classes</em> (a.k.a. flows) of tra ffic to which different QoS treatments are applied?</li>
<li>What are the possible treatments and how are those mapped to the res ource allocation algorithms?</li> <li>What are the possible treatments and how are those mapped to the res ource allocation algorithms?</li>
</ol> </ol>
<t>Two critical facts of life come into play when designing a QoS scheme. <t>Two critical facts of life come into play when designing a QoS scheme.
First, the number of equivalence classes that can be simultaneously tracked in a First, the number of equivalence classes that can be simultaneously tracked in a
network element is bounded by both memory and processing capacity to do the nec network element is bounded by both memory and processing capacity to do the nec
essary lookups. One can allow very fine-grained equivalence classes, but not be essary lookups. One can allow very fine-grained equivalence classes but not be a
able to employ them globally because of scaling limits of core routers. That mea ble to employ them globally because of scaling limits of core routers. That mean
ns it is wise to either restrict the range of equivalence classes, or allow them s it is wise to either restrict the range of equivalence classes or allow them t
to be <em>aggregated</em>, trading off accuracy in policing traffic against abi o be <em>aggregated</em>, trading off accuracy in policing traffic against abili
lity to scale.</t> ty to scale.</t>
<t>Second, the flexibility of expressible treatments can be tightly constr <t>Second, the flexibility of expressible treatments can be tightly constr
ained by both protocol encoding and algorithmic limitations. The ability to enco ained by both protocol encoding and algorithmic limitations. The ability to enco
de the treatment requests in the protocol can be limited (as it is for IP - ther de the treatment requests in the protocol can be limited -- as it is for IP wher
e are only 6 of the Type of Service (TOS) bits available for Diffserv treatments e there are only six of the Type of Service (TOS) bits available for Diffserv tr
), but as or more important is whether there are practical traffic policing, que eatments. However, an equal or more important issue is whether there are practic
uing, and pacing algorithms that can be combined to support a rich set of QoS tr al traffic policing, queuing, and pacing algorithms that can be combined to supp
eatments.</t> ort a rich set of QoS treatments.</t>
<t>The two considerations above in combination can easily be substantially more expressive than what can be achieved in practice with the available number of queues on real network interfaces or the amount of per-packet computation ne eded to enqueue or dequeue a packet. <t>The two considerations above in combination can easily be substantially more expressive than what can be achieved in practice with the available number of queues on real network interfaces or the amount of per-packet computation ne eded to enqueue or dequeue a packet.
</t> </t>
</section> </section>
<section anchor="ipisdifferent" numbered="true" toc="default"> <section anchor="ipisdifferent" numbered="true" toc="default">
<name>How does this relate to QoS in TCP/IP?</name> <name>How Does This Relate to QoS in TCP/IP?</name>
<t>TCP/IP has fewer resource types to manage than ICN, and in some cases t <t>TCP/IP has fewer resource types to manage than ICN, and in some cases,
he allocation methods are simpler, as shown in the following table:</t> the allocation methods are simpler, as shown in <xref target="TCPIPresources" fo
rmat="default"/>:</t>
<table anchor="TCPIPresources" align="center"> <table anchor="TCPIPresources" align="center">
<name>IP-related Network Element Resources</name> <name>IP-Related Network Element Resources</name>
<thead> <thead>
<tr> <tr>
<th align="left">Resource</th> <th align="left">Resource</th>
<th align="center">IP Relevant</th> <th align="center">IP Relevant</th>
<th align="left">TCP/IP Usage</th> <th align="left">TCP/IP Usage</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Communication Link capacity</td> <td align="left">Communication link capacity</td>
<td align="center">YES</td> <td align="center">YES</td>
<td align="left">buffering for queued packets</td> <td align="left">buffering for queued packets</td>
</tr> </tr>
<tr> <tr>
<td align="left">Content Store capacity</td> <td align="left">CS capacity</td>
<td align="center">NO</td> <td align="center">NO</td>
<td align="left">no content store in IP</td> <td align="left">no CS in IP</td>
</tr> </tr>
<tr> <tr>
<td align="left">Forwarder memory</td> <td align="left">Forwarder memory</td>
<td align="center">MAYBE</td> <td align="center">MAYBE</td>
<td align="left">not needed for output-buffered designs<sup>*</sup> </td> <td align="left">not needed for output-buffered designs (see note be low)</td>
</tr> </tr>
<tr> <tr>
<td align="left">Compute capacity</td> <td align="left">Compute capacity</td>
<td align="center">YES</td> <td align="center">YES</td>
<td align="left">for forwarding packets, but arguably much cheaper t han ICN</td> <td align="left">for forwarding packets, but arguably much cheaper t han ICN</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t><sup>*</sup>Output-buffered designs are where all packet buffering reso <aside><t>Note: In an output-buffered design, all packet buffering resourc
urces are associated with the output interfaces and there are no receiver interf es are associated with the output interfaces, and neither the receiver interface
ace or internal forwarding buffers that can be over-subscribed. Output-buffered nor the internal forwarding buffers can be over-subscribed. Output-buffered swi
switchs or routers are common but not universal, as they generally require an in tches or routers are common but not universal, as they generally require an inte
ternal speed-up factor where forwarding capacity is greater than the sum of the rnal speedup factor where forwarding capacity is greater than the sum of the inp
input capacity of the interfaces.</t> ut capacity of the interfaces.</t></aside>
<t>For these resources, IP has specified three fundamental things, as show
n in <xref target="IPQoSspecifiers" format="default"/>:</t>
<t>For these resources, IP has specified three fundamental things, as show n in the following table:</t>
<table anchor="IPQoSspecifiers" align="center"> <table anchor="IPQoSspecifiers" align="center">
<name>Fundamental protocol elements to achieve QoS for TCP/IP</name> <name>Fundamental Protocol Elements to Achieve QoS for TCP/IP</name>
<thead> <thead>
<tr> <tr>
<th align="center">What</th> <th align="center">What</th>
<th align="left">How</th> <th align="left">How</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center"> <td align="center">
<strong>Equivalence classes</strong></td> Equivalence classes</td>
<td align="left">subset+prefix match on IP 5-tuple {SA,DA,SP,DP,PT}< <td align="left"><t>subset+prefix match on IP 5-tuple {SA,DA,SP,DP,P
br/> T}<br/>
SA=Source Address<br/> SA=Source Address<br/>
DA=Destination Address<br/> DA=Destination Address<br/>
SP=Source Port<br/> SP=Source Port<br/>
DP=Desintation Port<br/> DP=Destination Port<br/>
PT=IP Protocol Type</td> PT=IP Protocol Type</t></td>
</tr> </tr>
<tr> <tr>
<td align="center"> <td align="center">
<strong>Diffserv treatments</strong></td> Diffserv treatments</td>
<td align="left">(very) small number of globally-agreed traffic clas ses</td> <td align="left">(very) small number of globally-agreed traffic clas ses</td>
</tr> </tr>
<tr> <tr>
<td align="center"> <td align="center">
<strong>Intserv treatments</strong></td> Intserv treatments</td>
<td align="left">per-flow parameterized <em>Controlled Load</em> and <em>Guaranteed</em> service classes</td> <td align="left">per-flow parameterized <em>Controlled Load</em> and <em>Guaranteed</em> service classes</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Equivalence classes for IP can be pairwise, by matching against both so <t>Equivalence classes for IP can be pairwise, by matching against both so
urce and destination address+port, pure group using only destination address+por urce and destination address+port, pure group using only destination address+por
t, or source-specific multicast with source adress+port and destination multicas t, or source-specific multicast with source address+port and destination multica
t address+port.</t> st address+port.</t>
<t>With Intserv, the Resource ReSerVation signaling protocol (RSVP) <xref <t>With Intserv, RSVP <xref target="RFC2205" format="default"/> carries tw
target="RFC2205" format="default"/> carries two data structures, the Flow Specif o data structures: the Flow Specifier (FLOWSPEC) and the Traffic Specifier (TSPE
ier (FLOWSPEC) and the Traffic Specifier (TSPEC). The former fulfills the requir C). The former fulfills the requirement to identify the equivalence class to whi
ement to identify the equivalence class to which the QoS being signaled applies. ch the QoS being signaled applies. The latter comprises the desired QoS treatmen
The latter comprises the desired QoS treatment along with a description of the t along with a description of the dynamic character of the traffic (e.g., averag
dynamic character of the traffic (e.g. average bandwidth and delay, peak bandwid e bandwidth and delay, peak bandwidth, etc.). Both of these encounter substantia
th, etc.). Both of these encounter substantial scaling limits, which has meant t l scaling limits, which has meant that Intserv has historically been limited to
hat Intserv has historically been limited to confined topologies, and/or high-va confined topologies, and/or high-value usages, like traffic engineering.</t>
lue usages, like traffic engineering.</t> <t>With Diffserv, the protocol encoding (six bits in the TOS field of the
<t>With Diffserv, the protocol encoding (6 bits in the TOS field of the IP IP header) artificially limits the number of classes one can specify. These are
header) artificially limits the number of classes one can specify. These are do documented in <xref target="RFC4594" format="default"/>. Nonetheless, when used
cumented in <xref target="RFC4594" format="default"/>. Nonetheless, when used wi with fine-grained equivalence classes, one still runs into limits on the number
th fine-grained equivalence classes, one still runs into limits on the number of of queues required.</t>
queues required.</t>
</section> </section>
<section anchor="icnisdifferent" numbered="true" toc="default"> <section anchor="icnisdifferent" numbered="true" toc="default">
<name>Why is ICN Different? Can we do Better?</name> <name>Why Is ICN Different? Can We Do Better?</name>
<t>While one could adopt an approach to QoS mirroring the extensive experi <t>While one could adopt an approach to QoS that mirrors the extensive exp
ence with TCP/IP, this would, in the author's view, be a mistake. The implementa erience with TCP/IP, this would, in the author's view, be a mistake. The impleme
tion and deployment of QoS in IP networks has been spotty at best. There are of ntation and deployment of QoS in IP networks has been spotty at best. There are,
course economic and political reasons as well as technical reasons for these mix of course, economic and political reasons as well as technical reasons for thes
ed results, but there are several architectural choices in ICN that make it a po e mixed results, but there are several architectural choices in ICN that make it
tentially much better protocol base to enhance with QoS machinery. This section a potentially much better protocol base to enhance with QoS machinery. This sec
discusses those differences and their consequences.</t> tion discusses those differences and their consequences.</t>
<section anchor="icnflows" numbered="true" toc="default"> <section anchor="icnflows" numbered="true" toc="default">
<name>Equivalence class capabilities</name> <name>Equivalence Class Capabilities</name>
<t>First and foremost, hierarchical names are a much richer basis for sp <t>First and foremost, hierarchical names are a much richer basis for sp
ecifying equivalence classes than IP 5-tuples. The IP address (or prefix) can on ecifying equivalence classes than IP 5-tuples. The IP address (or prefix) can on
ly separate traffic by topology to the granularity of hosts, and not express act ly separate traffic by topology to the granularity of hosts and cannot express a
ual computational instances nor sets of data. Ports give some degree of per-inst ctual computational instances nor sets of data. Ports give some degree of per-in
ance demultiplexing, but this tends to be both coarse and ephemeral, while confo stance demultiplexing, but this tends to be both coarse and ephemeral, while con
unding the demultiplexing function with the assignment of QoS treatments to part founding the demultiplexing function with the assignment of QoS treatments to pa
icular subsets of the data. Some degree of finer granularity is possible with IP rticular subsets of the data. Some degree of finer granularity is possible with
v6 by exploiting the ability to use up to 64 bits of address for classifying tra IPv6 by exploiting the ability to use up to 64 bits of address for classifying t
ffic. In fact, the hICN project <xref target="I-D.muscariello-intarea-hicn" form raffic. In fact, the Hybrid Information-Centric Networking (hICN) project <xref
at="default"/>, while adopting the request-response model of CCNx, uses IPv6 add target="I-D.muscariello-intarea-hicn" format="default"/>, while adopting the req
resses as the available namespace, and IPv6 packets (plus "fake" TCP headers) as uest-response model of CCNx, uses IPv6 addresses as the available namespace, and
the wire format.</t> IPv6 packets (plus "fake" TCP headers) as the wire format.</t>
<t>Nonetheless, the flexibility of tokenized (i.e. strings treated as op <t>Nonetheless, the flexibility of tokenized (i.e., strings treated as o
aque tokens), variable length, hierarchical names allows one to directly associa paque tokens), variable length, hierarchical names allows one to directly associ
te classes of traffic for QoS purposes with the structure of an application name ate classes of traffic for QoS purposes with the structure of an application nam
space. The classification can be as coarse or fine-grained as desired by the app espace. The classification can be as coarse or fine-grained as desired by the ap
lication. While not <em>always</em> the case, there is typically a straightforwa plication. While not <em>always</em> the case, there is typically a straightforw
rd association between how objects are named, and how they are grouped together ard association between how objects are named and how they are grouped together
for common treatment. Examples abound; a number can be conveniently found in <xr for common treatment. Examples abound; a number can be conveniently found in <xr
ef target="I-D.moiseenko-icnrg-flowclass" format="default"/>.</t> ef target="I-D.moiseenko-icnrg-flowclass" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Topology interactions with QoS</name> <name>Topology Interactions with QoS</name>
<t>In ICN, QoS is not pre-bound to network topology since names are non- <t>In ICN, QoS is not pre-bound to network topology since names are non-
topological, unlike unicast IP addresses. This allows QoS to be applied to multi topological, unlike unicast IP addresses. This allows QoS to be applied to multi
-destination and multi-path environments in a straightforward manner, rather tha -destination and multipath environments in a straightforward manner, rather than
n requiring either multicast with coarse class-based scheduling or complex signa requiring either multicast with coarse class-based scheduling or complex signal
ling like that in RSVP-TE <xref target="RFC3209" format="default"/> that is need ing like that in RSVP Traffic Engineering (RSVP-TE) <xref target="RFC3209" forma
ed to make point-to-multipoint Muti-Protocol Label Switching (MPLS) work.</t> t="default"/> that is needed to make point-to-multipoint Multiprotocol Label Swi
<t>Because of IP's stateless forwarding model, complicated by the ubiqui tching (MPLS) work.</t>
ty of asymmetric routes, any flow-based QoS requires state that is decoupled fro <t>Because of IP's stateless forwarding model, complicated by the ubiqui
m the actual arrival of traffic and hence must be maintained, at least as soft-s ty of asymmetric routes, any flow-based QoS requires state that is decoupled fro
tate, even during quiescent periods. Intserv, for example, requires flow signali m the actual arrival of traffic and hence must be maintained, at least as soft s
ng with state O(#flows). ICN, even worst case, requires state O(#active Interest tate, even during quiescent periods. Intserv, for example, requires flow signali
/Data exchanges), since state can be instantiated on arrival of an Interest, and ng on the order of O(number of flows). ICN, even worst case, requires order of O
removed (perhaps lazily) once the data has been returned.</t> (number of active Interest/Data exchanges), since state can be instantiated on a
rrival of an Interest and removed (perhaps lazily) once the data has been return
ed.</t>
</section> </section>
<section anchor="qostreatments" numbered="true" toc="default"> <section anchor="qostreatments" numbered="true" toc="default">
<name>Specification of QoS treatments</name> <name>Specification of QoS Treatments</name>
<t>Unlike Intserv, Diffserv eschews signaling in favor of class-based co <t>Unlike Intserv, Diffserv eschews signaling in favor of class-based co
nfiguration of resources and queues in network elements. However, Diffserv limit nfiguration of resources and queues in network elements. However, Diffserv limit
s traffic treatments to a few bits taken from the ToS field of IP. No such wire s traffic treatments to a few bits taken from the TOS field of IP. No such wire
encoding limitations exist for NDN or CCNx, as the protocol is completely TLV (T encoding limitations exist for NDN or CCNx, as the protocol is completely TLV (T
ype-Length-Value) based, and one (or even more than one) new field can be easily ype-Length-Value) based, and one (or even more than one) new field can be easily
defined to carry QoS treatment information.</t> defined to carry QoS treatment information.</t>
<t>Therefore, there are greenfield possibilities for more powerful QoS t <t>Therefore, there are greenfield possibilities for more powerful QoS t
reatment options in ICN. For example, IP has no way to express a QoS treatment l reatment options in ICN. For example, IP has no way to express a QoS treatment l
ike "try hard to deliver reliably, even at the expense of delay or bandwidth". S ike "try hard to deliver reliably, even at the expense of delay or bandwidth". S
uch a QoS treatment for ICN could invoke native ICN mechanisms, none of which ar uch a QoS treatment for ICN could invoke native ICN mechanisms, none of which ar
e present in IP, such as: e present in IP, such as the following:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>In-network retransmission in response to hop-by-hop errors returne d from upstream forwarders</li> <li>Retransmitting in-network in response to hop-by-hop errors returne d from upstream forwarders</li>
<li>Trying multiple paths to multiple content sources either in parall el or serially</li> <li>Trying multiple paths to multiple content sources either in parall el or serially</li>
<li>Assign higher precedence for short-term caching to recover from do wnstream<sup>*</sup> errors</li> <li>Assigning higher precedence for short-term caching to recover from downstream (see note below) errors</li>
<li>Coordinating cache utilization with forwarding resources</li> <li>Coordinating cache utilization with forwarding resources</li>
</ul> </ul>
<aside><t><sup>*</sup><em>Downstream</em> refers to the direction Data m <aside><t>Note: <em>Downstream</em> refers to the direction Data message
essages flow toward the consumer (the issuer of Interests). Conversely, <em>Upst s flow toward the consumer (the issuer of Interests). Conversely, <em>Upstream</
ream</em> refers to the direction Interests flow toward the producer of data.</t em> refers to the direction Interests flow toward the producer of data.</t></asi
></aside> de>
<t>Such mechanisms are typically described in NDN and CCNx as <em>forwar
<t>Such mechanisms are typically described in NDN and CCNx as <em>forwar ding strategies</em>. However, there is little or no guidance for which applicat
ding strategies</em>. However, little or no guidance is given for what applicati ion actions or protocol machinery a forwarder should use to select the appropria
on actions or protocol machinery is used to decide which forwarding strategy to te forwarding strategy for arriving Interest messages. See <xref target="BenAbra
use for which Interests that arrive at a forwarder. See <xref target="BenAbraham ham2018" format="default"/> for an investigation of these issues. Associating fo
2018" format="default"/> for an investigation of these issues. Associating forwa rwarding strategies with the equivalence classes and QoS treatments directly can
rding strategies with the equivalence classes and QoS treatments directly can ma make them more accessible and useful to implement and deploy.</t>
ke them more accessible and useful to implement and deploy.</t>
<t>Stateless forwarding and asymmetric routing in IP limits available st
ate/feedback to manage link resources. In contrast, NDN or CCNx forwarding allow
s all link resource allocation to occur as part of Interest forwarding, potentia
lly simplifying things considerably. In particular, with symmetric routing, prod
ucers have no control over the paths their data packets traverse, and hence any
QoS treatments intended to influence routing paths from producer to consumer wil
l have no effect.</t>
<t>One complication in the handling of ICN QoS treatments is not present <t>Stateless forwarding and asymmetric routing in IP limits available st
in IP and hence worth mention. CCNx and NDN both perform <em>Interest aggregati ate/feedback to manage link resources. In contrast, NDN or CCNx forwarding allow
on</em> (See Section 2.3.2 of <xref target="RFC8569" format="default"/>). If an s all link resource allocation to occur as part of Interest forwarding, potentia
Interest arrives matching an existing PIT entry, but with a different QoS treatm lly simplifying things considerably. In particular, with symmetric routing, prod
ent from an Interest already forwarded, it can be tricky to decide whether to ag ucers have no control over the paths their Data packets traverse; hence, any QoS
gregate the interest or forward it, and how to keep track of the differing QoS t treatments intended to influence routing paths from producer to consumer will h
reatments for the two Interests. Exploration of the details surrounding these si ave no effect.</t>
tuations is beyond the scope of this document; further discussion can be found f <t>One complication in the handling of ICN QoS treatments is not present
or the general case of flow balance and congestion control in <xref target="I-D. in IP and hence worth mentioning. CCNx and NDN both perform <em>Interest aggreg
oran-icnrg-flowbalance" format="default"/>, and specifically for QoS treatments ation</em> (see <xref target="RFC8569" section="2.4.2" sectionFormat="of" format
in <xref target="I-D.anilj-icnrg-dnc-qos-icn" format="default"/>.</t> ="default"/>). If an Interest arrives matching an existing PIT entry, but with a
different QoS treatment from an Interest already forwarded, it can be tricky to
decide whether to aggregate the Interest or forward it, and how to keep track o
f the differing QoS treatments for the two Interests. Exploration of the details
surrounding these situations is beyond the scope of this document; further disc
ussion can be found for the general case of flow balance and congestion control
in <xref target="I-D.oran-icnrg-flowbalance" format="default"/> and specifically
for QoS treatments in <xref target="I-D.anilj-icnrg-dnc-qos-icn" format="defaul
t"/>.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>ICN forwarding semantics effect on QoS</name> <name>ICN Forwarding Semantics Effect on QoS</name>
<t>IP has three forwarding semantics, with different QoS needs (Unicast, <t>IP has three forwarding semantics, with different QoS needs (Unicast,
Anycast, Multicast). ICN has the single forwarding semantic, so any QoS machine Anycast, Multicast). ICN has the single forwarding semantic, so any QoS machine
ry can be uniformly applied across any request/response invocation. This applies ry can be uniformly applied across any request/response invocation. This applies
whether the forwarder employs dynamic destination routing, multi-destination fo whether the forwarder employs dynamic destination routing, multi-destination fo
rwarding with next-hops tried serially, multi-destination with next-hops used in rwarding with next hops tried serially, multi-destination with next hops used in
parallel, or even localized flooding (e.g. directly on L2 multicast mechanisms) parallel, or even localized flooding (e.g., directly on Layer 2 multicast mecha
. Additionally, the pull-based model of ICN avoids a number of thorny multicast nisms). Additionally, the pull-based model of ICN avoids a number of thorny mult
QoS problems that IP has (<xref target="Wang2000" format="default"/>, <xref targ icast QoS problems that IP has (see <xref target="Wang2000" format="default"/>,
et="RFC3170" format="default"/>, <xref target="Tseng2003" format="default"/>).</ <xref target="RFC3170" format="default"/>, and <xref target="Tseng2003" format="
t> default"/>).</t>
<t>The Multi-destination/multi-path forwarding model in ICN changes reso <t>The Multi-destination/multipath forwarding model in ICN changes resou
urce allocation needs in a fairly deep way. IP treats all endpoints as open-loop rce allocation needs in a fairly deep way. IP treats all endpoints as open-loop
packet sources, whereas NDN and CCNx have strong asymmetry between producers an packet sources, whereas NDN and CCNx have strong asymmetry between producers and
d consumers as packet sources.</t> consumers as packet sources.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>QoS interactions with Caching</name> <name>QoS Interactions with Caching</name>
<t>IP has no caching in routers, whereas ICN needs ways to allocate cach <t>IP has no caching in routers, whereas ICN needs ways to allocate cach
e resources. Treatments to control caching operation are unlikely to look much l e resources. Treatments to control caching operation are unlikely to look much l
ike the treatments used to control link resources. NDN and CCNx already have use ike the treatments used to control link resources. NDN and CCNx already have use
ful cache control directives associated with Data messages. The CCNx controls in ful cache control directives associated with Data messages. The CCNx controls in
clude: clude the following:
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>ExpiryTime:</dt> <dt>ExpiryTime:</dt>
<dd>time after which a cached Content Object is considered expired and MUST no longer be used to respond to an Interest from a cache.</dd> <dd>time after which a cached Content Object is considered expired and <bcp14>MUST</bcp14> no longer be used to respond to an Interest from a cache.</ dd>
<dt>Recommended Cache Time:</dt> <dt>Recommended Cache Time:</dt>
<dd>time after which the publisher considers the Content Object to be of low value to cache.</dd> <dd>time after which the publisher considers the Content Object to be of low value to cache.</dd>
</dl> </dl>
<t>See <xref target="RFC8569" format="default"/> for the formal definiti ons.</t> <t>See <xref target="RFC8569" format="default"/> for the formal definiti ons.</t>
<t>ICN flow classifiers, such as those in <xref target="I-D.moiseenko-ic <t>ICN flow classifiers, such as those in <xref target="I-D.moiseenko-ic
nrg-flowclass" format="default"/> can be used to achieve soft or hard partitioni nrg-flowclass" format="default"/> can be used to achieve soft or hard partitioni
ng<sup>*</sup> of cache resources in the content store of an ICN forwarder. For ng (see note below) of cache resources in the CS of an ICN forwarder. For exampl
example, cached content for a given equivalence class can be considered <em>fate e, cached content for a given equivalence class can be considered <em>fate share
shared</em> in a cache whereby objects from the same equivalence class can be p d</em> in a cache whereby objects from the same equivalence class can be purged
urged as a group rather than individually. This can recover cache space more qui as a group rather than individually. This can recover cache space more quickly a
ckly and at lower overhead than pure per-object replacement when a cache is unde nd at lower overhead than pure per-object replacement when a cache is under extr
r extreme pressure and in danger of thrashing. In addition, since the forwarder eme pressure and in danger of thrashing. In addition, since the forwarder rememb
remembers the QoS treatment for each pending Interest in its PIT, the above cach ers the QoS treatment for each pending Interest in its PIT, the above cache cont
e controls can be augmented by policy to prefer retention of cached content for rols can be augmented by policy to prefer retention of cached content for some e
some equivalence classes as part of the cache replacement algorithm.</t> quivalence classes as part of the cache replacement algorithm.</t>
<aside><t><sup>*</sup>With hard partitioning, there are dedicated cache <aside><t>Note: With hard partitioning, there are dedicated cache resour
resources for each equivalence class (or enumerated list of equivalence classes) ces for each equivalence class (or enumerated list of equivalence classes). With
. With soft partitioning, resources are at least partly shared among the (sets o soft partitioning, resources are at least partly shared among the (sets of) equ
f) equivalence classes of traffic.</t></aside> ivalence classes of traffic.</t></aside>
</section> </section>
</section> </section>
<section anchor="principles" numbered="true" toc="default"> <section anchor="principles" numbered="true" toc="default">
<name>Strawman principles for an ICN QoS architecture</name> <name>Strawman Principles for an ICN QoS Architecture</name>
<!--> <name>A strawman set of principles to guide QoS architecture for ICN</n
ame> --> <t>Based on the observations made in the earlier sections, this summary se
<t>Based on the observations made in the earlier sections, this summary se ction captures the author's ideas for clear and actionable architectural princip
ction captures the author's ideas for clear and actionable architectural princip les for incorporating QoS machinery into ICN protocols like NDN and CCNx. Hopefu
les for how to incorporate QoS machinery into ICN protocols like NDN and CCNx. H lly, they can guide further work and focus effort on portions of the giant desig
opefully, they can guide further work and focus effort on portions of the giant n space for QoS that have the best trade-offs in terms of flexibility, simplicit
design space for QoS that have the best tradeoffs in terms of flexibility, simpl y, and deployability.</t>
icity, and deployability.</t> <t><strong>Define equivalence classes using the name hierarchy rather than
<t><strong>Define equivalence classes using the name hierarchy rather than creating an independent traffic class definition</strong>. This directly associ
creating an independent traffic class definition</strong>. This directly associ ates the specification of equivalence classes of traffic with the structure of t
ates the specification of equivalence classes of traffic with the structure of t he application namespace. It can allow hierarchical decomposition of equivalence
he application namespace. It can allow hierarchical decomposition of equivalence classes in a natural way because of the way hierarchical ICN names are construc
classes in a natural way because of the way hierarchical ICN names are construc ted. Two practical mechanisms are presented in <xref target="I-D.moiseenko-icnrg
ted. Two practical mechanisms are presented in <xref target="I-D.moiseenko-icnrg -flowclass" format="default"/> with different trade-offs between security and th
-flowclass" format="default"/> with different tradeoffs between security and the e ability to aggregate flows. Either the prefix-based mechanism (the equivalence
ability to aggregate flows. Either prefix-based (EC3) or explicit name componen class component count (EC3) scheme) or the explicit name component-based mechan
t based (ECNT) or both could be adopted as the part of the QoS architecture for ism (the equivalence class name component type (ECNCT) scheme), or both, could b
defining equivalence classes.</t> e adopted as the part of the QoS architecture for defining equivalence classes.<
<t><strong> Put consumers in control of Link and Forwarding resource alloc /t>
ation</strong>. Do all link buffering and forwarding (both memory and CPU) resou <t><strong> Put consumers in control of link and forwarding resource alloc
rce allocations based on Interest arrivals. This is attractive because it provid ation</strong>. Base all link buffering and forwarding (both memory and CPU) res
es early congestion feedback to consumers, and allows scheduling the reverse lin ource allocations on Interest arrivals. This is attractive because it provides e
k direction ahead of time for carrying the matching data. It makes enforcement o arly congestion feedback to consumers and allows scheduling the reverse link dir
f QoS treatments a single-ended (i.e. at the consumer) rather than a double-ende ection for carrying the matching data in advance. It makes enforcement of QoS tr
d problem and can avoid wasting resources on fetching data that will wind up dro eatments a single-ended (i.e., at the consumer) rather than a double-ended probl
pped when it arrives at a bottleneck link.</t> em and can avoid wasting resources on fetching data that will be dropped when it
<t><strong>Allow producers to influence the allocation of cache resources< arrives at a bottleneck link.</t>
/strong>. Producers want to affect caching decisions in order to: <t><strong>Allow producers to influence the allocation of cache resources<
/strong>. Producers want to affect caching decisions in order to do the followin
g:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Shed load by having Interests served by content stores in forwarders <li>Shed load by having Interests served by CSes in forwarders before th
before reaching the producer itself.</li> ey reach the producer itself</li>
<li>Survive transient producer reachability or link outages close to the <li>Survive transient producer reachability or link outages close to the
producer.</li> producer</li>
</ul> </ul>
<t> <t>
For caching to be effective, individual Data objects in an equivalence class nee d to have similar treatment; otherwise well-known cache thrashing pathologies du e to self-interference emerge. Producers have the most direct control over cachi ng policies through the caching directives in Data messages. It therefore makes sense to put the producer, rather than the consumer or network operator in charg e of specifying these equivalence classes.</t> For caching to be effective, individual Data objects in an equivalence class nee d to have similar treatment; otherwise, well-known cache-thrashing pathologies d ue to self-interference emerge. Producers have the most direct control over cach ing policies through the caching directives in Data messages. It therefore makes sense to put the producer, rather than the consumer or network operator, in cha rge of specifying these equivalence classes.</t>
<t>See <xref target="I-D.moiseenko-icnrg-flowclass" format="default"/> for specific mechanisms to achieve this.</t> <t>See <xref target="I-D.moiseenko-icnrg-flowclass" format="default"/> for specific mechanisms to achieve this.</t>
<t><strong>Allow consumers to influence the allocation of cache resources< /strong>. Consumers want to affect caching decisions in order to: <t><strong>Allow consumers to influence the allocation of cache resources< /strong>. Consumers want to affect caching decisions in order to do the followin g:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Reduce latency for retrieving data</li> <li>Reduce latency for retrieving data</li>
<li>Survive transient outages of either a producer or links close to the consumer</li> <li>Survive transient outages of either a producer or links close to the consumer</li>
</ul> </ul>
<t> <t>
Consumers can have indirect control over caching by specifying QoS treatments in their Interests. Consider the following potential QoS treatments by consumers t hat can drive caching policies: Consumers can have indirect control over caching by specifying QoS treatments in their Interests. Consider the following potential QoS treatments by consumers t hat can drive caching policies:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>A QoS treatment requesting better robustness against transient disco nnection can be used by a forwarder close to the consumer (or downstream of an u nreliable link) to preferentially cache the corresponding data.</li> <li>A QoS treatment requesting better robustness against transient disco nnection can be used by a forwarder close to the consumer (or downstream of an u nreliable link) to preferentially cache the corresponding data.</li>
<li>Conversely a QoS treatment together with, or in addition to a reques <li>Conversely, a QoS treatment together with, or in addition to, a requ
t for short latency, to indicate that new data will be requested soon enough tha est for short latency indicating that the forwarder should only pay attention to
t caching the current data being requested would be ineffective and hence to onl the caching preferences of the producer because caching requested data would be
y pay attention to the caching preferences of the producer.</li> ineffective (i.e., new data will be requested shortly).</li>
<li>A QoS treatment indicating a mobile consumer likely to incur a mobil <li>A QoS treatment indicating that a mobile consumer will likely incur
ity event within an RTT (or a few RTTs). Such a treatment would allow a mobile n a mobility event within an RTT (or a few RTTs). Such a treatment would allow a m
etwork operator to preferentially cache the data at a forwarder positioned at a obile network operator to preferentially cache the data at a forwarder positione
<em>join point</em> or <em>rendezvous point</em> of their topology</li> d at a <em>join point</em> or <em>rendezvous point</em> of their topology.</li>
</ul> </ul>
<t><strong>Give network operators the ability to match customer SLAs to ca <t><strong>Give network operators the ability to match customer SLAs to ca
che resource availability</strong>. Network operators, whether closely tied admi che resource availability</strong>. Network operators, whether closely tied admi
nistratively to producer or consumer, or constituting an independent transit adm nistratively to producer or consumer, or constituting an independent transit adm
inistration, provide the storage resources in the ICN forwarders. Therefore, the inistration, provide the storage resources in the ICN forwarders. Therefore, the
y are the ultimate arbiters of how the cache resources are managed. In addition y are the ultimate arbiters of how the cache resources are managed. In addition
to any local policies they may enforce, the cache behavior from the QoS standpoi to any local policies they may enforce, the cache behavior from the QoS standpoi
nt emerges from how the producer-specified equivalence classes map onto cache sp nt emerges from the mapping of producer-specified equivalence classes onto cache
ace availability, including whether cache entries are treated individually, or f space availability, including whether cache entries are treated individually or
ate-shared. Forwarders also determine how the consumer-specified QoS treatments fate-shared. Forwarders also determine the mapping of consumer-specified QoS tr
map to the precedence used for retaining Data objects in the cache.</t> eatments to the precedence used for retaining Data objects in the cache.</t>
<t>Besides utilizing cache resources to meet the QoS goals of individual p <t>Besides utilizing cache resources to meet the QoS goals of individual p
roducers and consumers, network operators also want to manage their cache resour roducers and consumers, network operators also want to manage their cache resour
ces in order to: ces in order to do the following:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Ameliorate congestion hotspots by reducing load converging on produc <li>Ameliorate congestion hotspots by reducing load converging on produc
ers they host on their network.</li> ers they host on their network</li>
<li>Improve Interest satisfaction rates by utilizing caches as short-ter <li>Improve Interest satisfaction rates by utilizing caches as short-ter
m retransmission buffers to recover from transient producer reachability problem m retransmission buffers to recover from transient producer reachability problem
s, link errors or link outages.</li> s, link errors, or link outages</li>
<li>Improve both latency and reliability in environments when consumers <li>Improve both latency and reliability in environments when consumers
are mobile in the operator's topology.</li> are mobile in the operator's topology</li>
</ul> </ul>
<t><strong>Re-think how to specify traffic treatments - don't just copy Di <t><strong>Rethink how to specify traffic treatments -- don't just copy Di
ffserv</strong>. Some of the Diffserv classes may form a good starting point, as ffserv</strong>. Some of the Diffserv classes may form a good starting point, as
their mapping onto queuing algorithms for managing link buffering are well unde their mappings onto queuing algorithms for managing link buffering are well und
rstood. However, Diffserv alone does not allow one to express latency versus rel erstood. However, Diffserv alone does not capture more complex QoS treatments, s
iability tradeoffs or other useful QoS treatments. Nor does it permit "Traffic S uch as:</t>
pecification (TSPEC)"-style traffic descriptions as are allowed in a signaled Qo <ul spacing="normal">
S scheme. Here are some examples: <li>Trading off latency against reliability</li>
<li>Trading off resource usage against delivery probability through cont
rolled flooding or other forwarding mechanisms</li>
<li>Allocating resources based on rich TSPEC-like traffic descriptions t
hat appear in signaled QoS schemes like Intserv</li>
</ul>
<t>Here are some examples:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>A "burst" treatment, where an initial Interest gives an aggregate da ta size to request allocation of link capacity for a large burst of Interest/Dat a exchanges. The Interest can be rejected at any hop if the resources are not av ailable. Such a treatment can also accommodate Data implosion produced by the di scovery procedures of management protocols like <xref target="I-D.irtf-icnrg-ccn info" format="default"/>.</li> <li>A "burst" treatment, where an initial Interest gives an aggregate da ta size to request allocation of link capacity for a large burst of Interest/Dat a exchanges. The Interest can be rejected at any hop if the resources are not av ailable. Such a treatment can also accommodate Data implosion produced by the di scovery procedures of management protocols like <xref target="I-D.irtf-icnrg-ccn info" format="default"/>.</li>
<li>A "reliable" treatment, which affects preference for allocation of P <li>A "reliable" treatment, which affects preference for allocation of P
IT space for the Interest and Content Store space for the data in order to impro IT space for the Interest and CS space for the Data in order to improve the robu
ve the robustness of IoT data delivery in constrained environment, as is describ stness of IoT data delivery in a constrained environment, as is described in <xr
ed in <xref target="I-D.gundogan-icnrg-iotqos" format="default"/>.</li> ef target="I-D.gundogan-icnrg-iotqos" format="default"/>.</li>
<li>A "search" treatment, which, within the specified Interest Lifetime, <li>A "search" treatment, which, within the specified Interest Lifetime,
tries many paths either in parallel or serial to potentially many content sourc tries many paths either in parallel or serially to potentially many content sou
es, to maximize the probability that the requested item will be found. This is d rces, to maximize the probability that the requested item will be found. This is
one at the expense of the extra bandwidth of both forwarding Interests and recei done at the expense of the extra bandwidth of both forwarding Interests and rec
ving multiple responses upstream of an aggregation point. The treatment can enco eiving multiple responses upstream of an aggregation point. The treatment can en
de a value expressing tradeoffs like breadth-first versus depth-first search, an code a value expressing trade-offs like breadth-first versus depth-first search,
d bounds on the total resource expenditure. Such a treatment would be useful for and bounds on the total resource expenditure. Such a treatment would be useful
instrumentation protocols like <xref target="I-D.irtf-icnrg-icntraceroute" form for instrumentation protocols like <xref target="I-D.irtf-icnrg-icntraceroute" f
at="default"/>.</li> ormat="default"/>.</li>
</ul> </ul>
<aside><t>As an aside, loose latency control (on the order of seconds or t ens of milliseconds as opposed milliseconds or microseconds) can be achieved by bounding Interest Lifetime as long as this lifetime machinery is not also used a s an application mechanism to provide subscriptions or to establish path traces for producer mobility. See <xref target="Krol2018" format="default"/> for a disc ussion of the network versus application timescale issues in ICN protocols.</t>< /aside> <aside><t>As an aside, loose latency control (on the order of seconds or t ens of milliseconds as opposed milliseconds or microseconds) can be achieved by bounding Interest Lifetime as long as this lifetime machinery is not also used a s an application mechanism to provide subscriptions or to establish path traces for producer mobility. See <xref target="Krol2018" format="default"/> for a disc ussion of the network versus application timescale issues in ICN protocols.</t>< /aside>
<!--
can we tighten this up to really manage latency-sensitive traffic? Can we play
with this hop-by-hop?
Consider anticipatory allocation for reverse traffic (e.g. phone-home interactio
n styles)
<section anchor="Intserv" numbered="true" toc="default"> <section anchor="Intserv" numbered="true" toc="default">
<name>Can Intserv-like traffic control in ICN provide richer QoS semanti <name>Can Intserv-Like Traffic Control in ICN Provide Richer QoS Semanti
cs?</name> cs?</name>
<!-- <name>What about the richer QoS semantics available with Intserv-like tr <t>Basic QoS treatments such as those summarized above may not be adequa
affic control?</name> --> te to cover the whole range of application utility functions and deployment envi
<t>Basic QoS treatments such as those summarized above may not be adequa ronments we expect for ICN. While it is true that one does not necessarily need
te to cover the whole range of application utility functions and deployment envi a separate signaling protocol like RSVP given the state carried in the ICN data
ronments we expect for ICN. While it is true that one does not necessarily need plane by forwarders, simple QoS treatments applied per Interest/Data exchanges l
a separate signaling protocol like RSVP given the state carried in the ICN data ack some potentially important capabilities. Intserv's richer QoS capabilities m
plane by forwarders, there are some potentially important capabilities not provi ay be of value, especially if they can be provided in ICN at lower complexity an
ded by just simple QoS treatments applied to per- Interest/Data exchanges. Intse d protocol overhead than Intserv plus RSVP.</t>
rv's richer QoS capabilities may be of value, especially if they can be provided
in ICN at lower complexity and protocol overhead than Intserv+RSVP.</t>
<t>There are three key capabilities missing from Diffserv-like QoS treat ments, no matter how sophisticated they may be in describing the desired treatme nt for a given equivalence class of traffic. Intserv-like QoS provides all of th ese: <t>There are three key capabilities missing from Diffserv-like QoS treat ments, no matter how sophisticated they may be in describing the desired treatme nt for a given equivalence class of traffic. Intserv-like QoS provides all of th ese:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>The ability to <strong>describe traffic flows</strong> in a mathem <li>The ability to <strong>describe traffic flows</strong> in a mathem
atically meaningful way. This is done through parameters like average rate, peak atically meaningful way. This is done through parameters like average rate, peak
rate, and maximum burst size. The parameters are encapsulated in a data structu rate, and maximum burst size. The parameters are encapsulated in a data structu
re called a "TSPEC" which can be placed in whatever protocol needs the informati re called a "TSPEC", which can be placed in whatever protocol needs the informat
on (in the case of TCP/IP Intserv, this is RSVP).</li> ion (in the case of TCP/IP Intserv, this is RSVP).</li>
<li>The ability to perform <strong>admission control</strong>, where t <li>The ability to perform <strong>admission control</strong>, where t
he element requesting the QoS treatment can know <em>before</em> introducing tra he element requesting the QoS treatment can know <em>before</em> introducing tra
ffic whether the network elements have agreed to provide the requested traffic t ffic whether the network elements have agreed to provide the requested traffic t
reatment. An important side-effect of providing this assurance is that the netwo reatment. An important side effect of providing this assurance is that the netwo
rk elements install state that allows the forwarding and queuing machinery to po rk elements install state that allows the forwarding and queuing machinery to po
lice and shape the traffic in a way that provides a sufficient degree of <em>iso lice and shape the traffic in a way that provides a sufficient degree of <em>iso
lation</em> from the dynamic behavior of other traffic. Depending on the admissi lation</em> from the dynamic behavior of other traffic. Depending on the admissi
on control mechanism, it may or may not be possible to explicitly release that s on-control mechanism, it may or may not be possible to explicitly release that s
tate when the application no longer needs the QoS treatment.</li> tate when the application no longer needs the QoS treatment.</li>
<li>The permissable <strong>degree of divergence</strong> in the actua <li>The ability to specify the permissible <strong>degree of divergenc
l traffic handling from the requested handling. Intserv provided two choices her e</strong> in the actual traffic handling from the requested handling. Intserv p
e, the <em>controlled load</em> service and the <em>guaranteed</em> service. The rovides two choices here: the <em>controlled load</em> service and the <em>guara
former allows stochastic deviation equivalent to what one would experience on a nteed</em> service. The former allows stochastic deviation equivalent to what on
n unloaded path of a packet network. The latter conforms to the TSPEC determinis e would experience on an unloaded path of a packet network. The latter conforms
tically, at the obvious expense of demanding extremely conservative resource all to the TSPEC deterministically, at the obvious expense of demanding extremely co
ocation.</li> nservative resource allocation.</li>
</ol> </ol>
<t>Given the limited applicability of these capabilities in today's Inte <t>Given the limited applicability of these capabilities in today's Inte
rnet, the author does not take any position as to whether any of these Intserv-l rnet, the author does not take any position as to whether any of these Intserv-l
ike capabilities are needed for ICN to be succesful. However, a few things seem ike capabilities are needed for ICN to be successful. However, a few things seem
important to consider. The following paragraphs speculate about the consequences important to consider. The following paragraphs speculate about the consequence
to the CCNx or NDN protocol architectures of incorporating these features.</t> s of incorporating these features into the CCNx or NDN protocol architectures.</
<t>Superficially, it would be quite straightforward to accommodate Intse t>
rv-equivalent traffic descriptions in CCNx or NDN. One could define a new TLV fo <t>Superficially, it would be quite straightforward to accommodate Intse
r the Interest message to carry a TSPEC. A forwarder encountering this, together rv-equivalent traffic descriptions in CCNx or NDN. One could define a new TLV fo
with a QoS treatment request (e.g. as proposed in <xref target="qostreatments" r the Interest message to carry a TSPEC. A forwarder encountering this, together
format="default"/>) could associate the traffic specification with the correspon with a QoS treatment request (e.g., as proposed in <xref target="qostreatments"
ding equivalence class derived from the name in the Interest. This would allow t format="default"/>), could associate the traffic specification with the corresp
he forwarder to create state that not only would apply to the returning Data for onding equivalence class derived from the name in the Interest. This would allow
that Interest when being queued on the downstream interface, but be maintained the forwarder to create state that not only would apply to the returning Data f
as soft state across multiple Interest/Data exchanges to drive policing and shap or that Interest when being queued on the downstream interface but also be maint
ing algorithms at per-flow granularity. The cost in Interest message overhead wo ained as soft state across multiple Interest/Data exchanges to drive policing an
uld be modest, however the complications associated with managing different traf d shaping algorithms at per-flow granularity. The cost in Interest message overh
fic specifications in different Interests for the same equivalence class might b ead would be modest; however, the complications associated with managing differe
e substantial. Of course, all the scalability considerations with maintaining pe nt traffic specifications in different Interests for the same equivalence class
r-flow state also come into play.</t> might be substantial. Of course, all the scalability considerations with maintai
ning per-flow state also come into play.</t>
<t>Similarly, it would be equally straightforward to have a way to expre ss the degree of divergence capability that Intserv provides through its control led load and guaranteed service definitions. This could either be packaged with the traffic specification or encoded separately.</t> <t>Similarly, it would be equally straightforward to have a way to expre ss the degree of divergence capability that Intserv provides through its control led load and guaranteed service definitions. This could either be packaged with the traffic specification or encoded separately.</t>
<t>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 using RSVP. The dynamic multi-path, multi-destination forwarding model of ICN makes performi ng admission control particularly tricky. Just to illustrate: <t>In contrast to the above, performing admission control for ICN flows is likely to be just as heavyweight as it is with IP using RSVP. The dynamic mul tipath, multi-destination forwarding model of ICN makes performing admission con trol particularly tricky. Just to illustrate:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Forwarding next-hop selection is not confined to single paths (or 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 Interest to forward.</li> <li>Forwarding next-hop selection is not confined to single paths (or 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 Interest to forward.</li>
<li>As with point-to-multipoint complexities when using RSVP for MPLS- <li>As with point-to-multipoint complexities when using RSVP for MPLS-
TE, state has to be installed to multiple producers over multiple paths before a TE, state has to be installed to multiple producers over multiple paths before a
n admission control algorithm can commit the resources and say "yes" to a consum n admission-control algorithm can commit the resources and say "yes" to a consum
er needing admission control capabilities</li> er needing admission-control capabilities.</li>
<li>Knowing when to remove admission control state is difficult in the <li>Knowing when to remove admission-control state is difficult in the
absence of a heavy-weight resource reservation protocol. Soft state timeout may absence of a heavyweight resource reservation protocol. Soft state timeout may
or may not be an adequate answer.</li> or may not be an adequate answer.</li>
</ul> </ul>
<t> Despite the challenges above, it may be possible to craft an admi ssion control scheme for ICN that achieves the desired QoS goals of applications without the invention and deployment of a complex separate admission control si gnaling protocol. There have been designs in earlier network architectures that were capable of performing admission control piggybacked on packet transmission. </t> <t> Despite the challenges above, it may be possible to craft an admi ssion-control scheme for ICN that achieves the desired QoS goals of applications without the invention and deployment of a complex, separate admission-control s ignaling protocol. There have been designs in earlier network architectures that were capable of performing admission control piggybacked on packet transmission .</t>
<aside><t>(The earliest example the author is aware of is <xref target=" Autonet" format="default"/>).</t></aside> <aside><t>The earliest example the author is aware of is <xref target="A utonet" format="default"/>.</t></aside>
<t>Such a scheme might have the following general shape <strong>(warning : serious hand waving follows!)</strong>: <t>Such a scheme might have the following general shape (<strong>warning :</strong> serious hand-waving follows!):
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>In addition to a QoS treatment and a traffic specification, an Int <li>In addition to a QoS treatment and a traffic specification, an Int
erest requesting admission for the corresponding equivalence class would so indi erest requesting admission for the corresponding equivalence class would indicat
cate via a new TLV. It would also need to: (a) indicate an expiration time after e this via a new TLV. It would also need to do the following: (a) indicate an ex
which any reserved resources can be released, and (b) indicate that caches be b piration time after which any reserved resources can be released, and (b) indica
ypassed, so that the admission control request arrives at a bone-fide producer.< te that caches be bypassed, so that the admission-control request arrives at a b
/li> ona fide producer.</li>
<!-- (or Repo) --> <li>Each forwarder processing the Interest would check for resource av
<li>Each forwarder processing the Interest would check for resource av ailability. If the resources are not available, or the requested service is not
ailability and if not available, or the requested service not feasible, reject t feasible, the forwarder would reject the Interest with an admission-control fail
he Interest with an admission control failure. If resources are available, the f ure. If resources are available, the forwarder would record the traffic specific
orwarder would record the traffic specification as described above and forward t ation as described above and forward the Interest.</li>
he Interest.</li> <li>If the Interest successfully arrives at a producer, the producer w
<li>If the Interest successfully arrives at a producer, the producer r ould return the requested Data.</li>
eturns the requested Data.</li> <li>Upon receiving the matching Data message and if the resources are
<li>Each on-path forwarder, on receiving the matching Data message, if still available, each on-path forwarder would allocate resources and would mark
the resources are still available, does the actual allocation, and marks the ad the admission control TLV as "provisionally approved". Conversely, if the resour
mission control TLV as "provisionally approved". Conversely, if the resource res ce reservation fails, the admission control would be marked "failed", although t
ervation fails, the admission control is marked "failed", although the Data is s he Data would still be passed downstream.</li>
till passed downstream.</li> <li>Upon the Data message arrival, the consumer would know if admissio
<li>Upon the Data message arriving, the consumer knows if admission su n succeeded or not, and subsequent Interests could rely on the QoS state being i
cceeded or not, and subsequent Interests can rely on the QoS state being in plac n place until either some failure occurs, or a topology or other forwarding chan
e until either some failure occurs, or a topology or other forwarding change alt ge alters the forwarding path. To deal with this, additional machinery is needed
ers the forwarding path. To deal with this, additional machinery is needed to en to ensure subsequent Interests for an admitted flow either follow that path or
sure subsequent Interests for an admitted flow either follow that path or an err an error is reported. One possibility (also useful in many other contexts), is t
or is reported. One possibility (also useful in many other contexts), is to empl o employ a <em>Path Steering</em> mechanism, such as the one described in <xref
oy a <em>Path Steering</em> mechanism, such as the one described in <xref target target="Moiseenko2017" format="default"/>.</li>
="Moiseenko2017" format="default"/>.</li>
</ul> </ul>
</section> </section>
</section> </section>
<!-- This PI places the pagebreak correctly (before the section title) in th
e text output. -->
<!--<?rfc needLines="8" ?>-->
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document does not require any IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>There are a few ways in which QoS for ICN interacts with security and p rivacy issues. Since QoS addresses relationships among traffic rather than the i nherent characteristics of traffic, it neither enhances nor degrades the securit y and privacy properties of the data being carried, as long as the machinery doe s not alter or otherwise compromise the basic security properties of the associa ted protocols. The QoS approaches advocated here for ICN can serve to amplify ex isting threats to network traffic however: <t>There are a few ways in which QoS for ICN interacts with security and p rivacy issues. Since QoS addresses relationships among traffic rather than the i nherent characteristics of traffic, it neither enhances nor degrades the securit y and privacy properties of the data being carried, as long as the machinery doe s not alter or otherwise compromise the basic security properties of the associa ted protocols. The QoS approaches advocated here for ICN can serve to amplify ex isting threats to network traffic. However:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>An attacker able to manipulate the QoS treatments of traffic can mou <li>An attacker able to manipulate the QoS treatments of traffic can mou
nt a more focused (and potentially more effective) denial of service attack by s nt a more focused (and potentially more effective) denial-of-service attack by s
uppressing performance on traffic the attacker is targeting. Since the architect uppressing performance on traffic the attacker is targeting. Since the architect
ure here assumes QoS treatments are manipulable hop-by-hop, any on-path adversar ure here assumes QoS treatments are manipulatable hop-by-hop, any on-path advers
y can wreak havoc. Note however, that in basic ICN, an on-path attacker can do t ary can wreak havoc. Note, however, that in basic ICN, an on-path attacker can d
his and more by dropping, delaying, or mis-routing traffic independent of any pa o this and more by dropping, delaying, or misrouting traffic independent of any
rticular QoS machinery in use.</li> particular QoS machinery in use.</li>
<li>By explicitly revealing equivalence classes of traffic via either na <li>When equivalence classes of traffic are explicitly revealed via eith
mes or other fields in packets, an attacker has yet one more handle to use to di er names or other fields in packets, an attacker has yet one more handle to use
scover linkability of multiple requests.</li> to discover linkability of multiple requests.</li>
</ul> </ul>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie <displayreference target="I-D.moiseenko-icnrg-flowclass" to="FLOWCLASS"/>
s: <displayreference target="I-D.muscariello-intarea-hicn" to="HICN"/>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here <displayreference target="I-D.irtf-icnrg-ccninfo" to="CCNINFO"/>
(as shown) <displayreference target="I-D.gundogan-icnrg-iotqos" to="IOTQOS"/>
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm <displayreference target="I-D.anilj-icnrg-dnc-qos-icn" to="DNC-QOS-ICN"/>
l"?> here <displayreference target="I-D.oran-icnrg-flowbalance" to="FLOWBALANCE"/>
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis. <displayreference target="I-D.irtf-nwcrg-nwc-ccn-reqs" to="NWC-CCN-REQS"/>
xml") <displayreference target="I-D.irtf-icnrg-icntraceroute" to="ICNTRACEROUTE"/>
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included fi
les in the same
directory as the including file. You can also define the XML_LIBRARY enviro
nment variable
with a value containing a set of directories to search. These can be eithe
r in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.2119.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8569.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8569.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8609.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8609.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8174.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.0793.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.0793.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.2205.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.2205.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.2474.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.2474.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.2998.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.2998.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.3170.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.3170.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.3209.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.3209.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4340.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4340.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4594.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4594.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4960.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4960.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
rence.I-D.draft-moiseenko-icnrg-flowclass-06.xml"/> <reference anchor="I-D.moiseenko-icnrg-flowclass" target="https://tools.ietf.org
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe /html/draft-moiseenko-icnrg-flowclass-07">
rence.I-D.ietf-quic-transport.xml"/> <front>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe <title>Flow Classification in Information Centric Networking</title>
rence.I-D.draft-muscariello-intarea-hicn-04.xml"/> <author initials="I." surname="Moiseenko" fullname="Ilya Moiseenko">
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe <organization>Apple Computer</organization>
rence.I-D.irtf-icnrg-ccninfo.xml"/> </author>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe <author initials="D." surname="Oran" fullname="David R. Oran">
rence.I-D.draft-irtf-icnrg-icntraceroute-01.xml"/> <organization>Network Systems Research and Design</organization>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe </author>
rence.I-D.draft-gundogan-icnrg-iotqos-01.xml"/> <date month="January" day="13" year="2021"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe </front>
rence.I-D.anilj-icnrg-dnc-qos-icn.xml"/> <seriesInfo name="Internet-Draft" value="draft-moiseenko-icnrg-flowclass-07"/
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe >
rence.I-D.draft-oran-icnrg-flowbalance-04.xml"/> </reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
rence.I-D.draft-irtf-nwcrg-nwc-ccn-reqs-04.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.9000.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.muscariello-intarea-hicn.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.irtf-icnrg-ccninfo.xml"/>
<reference anchor="I-D.irtf-icnrg-icntraceroute" target="https://tools.ietf.org/
html/draft-irtf-icnrg-icntraceroute-02">
<front>
<title>ICN Traceroute Protocol Specification</title>
<author initials="S." surname="Mastorakis" fullname="Spyridon Mastorakis">
<organization>University of Nebraska, Omaha</organization>
</author>
<author initials="J." surname="Gibson" fullname="Jim Gibson">
<organization>Cisco Systems</organization>
</author>
<author initials="I." surname="Moiseenko" fullname="Ilya Moiseenko">
<organization>Apple Inc</organization>
</author>
<author initials="R." surname="Droms" fullname="Ralph Droms">
<organization>Google Inc.</organization>
</author>
<author initials="D. R." surname="Oran" fullname="David R. Oran">
<organization>Network Systems Research and Design</organization>
</author>
<date month="April" day="11" year="2021"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-icntraceroute-02"/>
</reference>
<reference anchor="I-D.gundogan-icnrg-iotqos" target="https://tools.ietf.org/htm
l/draft-gundogan-icnrg-iotqos-01">
<front>
<title>Quality of Service for ICN in the IoT</title>
<author initials="C." surname="Gundogan" fullname="Cenk Gundogan">
<organization>HAW Hamburg</organization>
</author>
<author initials="T. C." surname="Schmidt" fullname="Thomas C. Schmidt">
<organization>HAW Hamburg</organization>
</author>
<author initials="M." surname="Waehlisch" fullname="Matthias Waehlisch">
<organization>link-lab &amp; FU Berlin</organization>
</author>
<author initials="M." surname="Frey" fullname="Michael Frey">
<organization>Safety IO</organization>
</author>
<author initials="F." surname="Shzu-Juraschek" fullname="Felix Shzu-Jurasc
hek">
<organization>Safety IO</organization>
</author>
<author initials="J." surname="Pfender" fullname="Jakob Pfender">
<organization>Victoria University of Wellington</organization>
</author>
<date month="July" day="8" year="2019"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-gundogan-icnrg-iotqos-01"/>
</reference>
<reference anchor="I-D.anilj-icnrg-dnc-qos-icn" target="https://tools.ietf.org/h
tml/draft-anilj-icnrg-dnc-qos-icn-02">
<front>
<title>QoS Treatments in ICN using Disaggregated Name Components</title>
<author fullname="Anil Jangam" role="editor">
<organization>Cisco Systems</organization>
</author>
<author fullname="Prakash Suthar">
<organization>Cisco Systems</organization>
</author>
<author fullname="Milan Stolic">
<organization>Cisco Systems</organization>
</author>
<date month="March" day="9" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-anilj-icnrg-dnc-qos-icn-02"/>
</reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.oran-icnrg-flowbalance.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.irtf-nwcrg-nwc-ccn-reqs.xml"/>
<reference anchor="Mahdian2016" target="http://conferences2.sigcomm.org/ acm-icn/2016/proceedings/p1-mahdian.pdf"> <reference anchor="Mahdian2016" target="http://conferences2.sigcomm.org/ acm-icn/2016/proceedings/p1-mahdian.pdf">
<front> <front>
<title>MIRCC: Multipath-aware ICN Rate-based Congestion Control</tit le> <title>MIRCC: Multipath-aware ICN Rate-based Congestion Control</tit le>
<seriesInfo name="DOI" value="10.1145/2984356.2984365"/>
<author surname="Mahdian" initials="M."/> <author surname="Mahdian" initials="M."/>
<author surname="Arianfar" initials="S."/> <author surname="Arianfar" initials="S."/>
<author surname="Gibson" initials="J."/> <author surname="Gibson" initials="J."/>
<author surname="Oran" initials="D."/> <author surname="Oran" initials="D."/>
<date year="2016" month="September"/> <date year="2016" month="September"/>
</front> </front>
<refcontent>in Proceedings of the 3rd ACM Conference on Information-Ce <refcontent>in ACM-ICN '16: Proceedings of the 3rd ACM Conference on I
ntric Networking</refcontent> nformation-Centric Networking</refcontent>
<seriesInfo name="DOI" value="10.1145/2984356.2984365"/>
</reference> </reference>
<reference anchor="Carofiglio2016" target="https://doi.org/10.1016/j.com net.2016.09.012"> <reference anchor="Carofiglio2016" target="https://doi.org/10.1016/j.com net.2016.09.012">
<front> <front>
<title>Optimal multipath congestion control and request forwarding i n information-centric networks: Protocol design and experimentation</title> <title>Optimal multipath congestion control and request forwarding i n information-centric networks: Protocol design and experimentation</title>
<seriesInfo name="DOI" value="10.1145/2377677.2377772"/>
<author surname="Carofiglio" initials="G."/> <author surname="Carofiglio" initials="G."/>
<author surname="Gallo" initials="M."/> <author surname="Gallo" initials="M."/>
<author surname="Muscariello" initials="L."/> <author surname="Muscariello" initials="L."/>
<date year="2016" month="December"/> <date year="2016" month="December"/>
</front> </front>
<refcontent>in Computer Networks, Vol. 110 No. 9, December 2016</refco <refcontent>in Computer Networks, Vol. 110</refcontent>
ntent> <seriesInfo name="DOI" value="10.1016/j.comnet.2016.09.012"/>
</reference> </reference>
<reference anchor="Carofiglio2012" target="http://conferences.sigcomm.or g/sigcomm/2012/paper/icn/p37.pdf"> <reference anchor="Carofiglio2012" target="http://conferences.sigcomm.or g/sigcomm/2012/paper/icn/p37.pdf">
<front> <front>
<title>Joint hop-by-hop and receiver-driven Interest control protoco <title>Joint Hop-by-hop and Receiver-Driven Interest Control Protoco
l for content-centric networks</title> l for Content-Centric Networks</title>
<seriesInfo name="DOI" value="10.1016/j.comnet.2016.09.012"/>
<author surname="Carofiglio" initials="G."/> <author surname="Carofiglio" initials="G."/>
<author surname="Gallo" initials="M."/> <author surname="Gallo" initials="M."/>
<author surname="Muscariello" initials="L."/> <author surname="Muscariello" initials="L."/>
<date year="2012" month="September"/> <date year="2012" month="September"/>
</front> </front>
<refcontent>in ACM SIGCOMM Computer Communication Review, September 20 <refcontent>in ACM SIGCOMM Computer Communication Review</refcontent>
12</refcontent> <seriesInfo name="DOI" value="10.1145/2377677.2377772"/>
</reference> </reference>
<reference anchor="Wang2013" target="http://conferences.sigcomm.org/sigc omm/2013/papers/icn/p55.pdf"> <reference anchor="Wang2013" target="https://conferences.sigcomm.org/sig comm/2013/papers/icn/p55.pdf">
<front> <front>
<title>An Improved Hop-by-hop Interest Shaper for Congestion Control <title>An improved Hop-by-hop Interest Shaper for Congestion Control
in Named Data Networking</title> in Named Data Networking</title>
<seriesInfo name="DOI" value="10.1145/2534169.2491233"/>
<author surname="Wang" initials="Y."/> <author surname="Wang" initials="Y."/>
<author surname="Rozhnova" initials="N."/> <author surname="Rozhnova" initials="N."/>
<author surname="Narayanan" initials="A."/> <author surname="Narayanan" initials="A."/>
<author surname="Oran" initials="D."/> <author surname="Oran" initials="D."/>
<author surname="Rhee" initials="I."/> <author surname="Rhee" initials="I."/>
<date year="2013" month="August"/> <date year="2013" month="August"/>
</front> </front>
<refcontent>in ICN '13: Proceedings of the 3rd ACM SIGCOMM workshop on <refcontent>in ACM SIGCOMM Computer Communication Review</refcontent>
Information-centric networking, August 2013</refcontent> <seriesInfo name="DOI" value="10.1145/2534169.2491233"/>
</reference> </reference>
<reference anchor="Song2018" target="https://conferences.sigcomm.org/acm -icn/2018/proceedings/icn18-final62.pdf"> <reference anchor="Song2018" target="https://conferences.sigcomm.org/acm -icn/2018/proceedings/icn18-final62.pdf">
<front> <front>
<title>SMIC: Subflow-level Multi-path Interest Control for Informati on Centric Networking</title> <title>SMIC: Subflow-level Multi-path Interest Control for Informati on Centric Networking</title>
<seriesInfo name="DOI" value="10.1145/3267955.3267971"/>
<author surname="Song" initials="J."/> <author surname="Song" initials="J."/>
<author surname="Lee" initials="M."/> <author surname="Lee" initials="M."/>
<author surname="Kwon" initials="T."/> <author surname="Kwon" initials="T."/>
<date year="2018" month="September"/> <date year="2018" month="September"/>
</front> </front>
<refcontent>ICN '18: Proceedings of the 5th ACM Conference on Informat ion-Centric Networking</refcontent> <refcontent>ICN '18: Proceedings of the 5th ACM Conference on Informat ion-Centric Networking</refcontent>
<seriesInfo name="DOI" value="10.1145/3267955.3267971"/>
</reference> </reference>
<reference anchor="Oran2018QoSslides" target="https://datatracker.ietf.o rg/meeting/interim-2018-icnrg-03/materials/slides-interim-2018-icnrg-03-sessa-th oughts-on-qos-for-ndnccn-style-icn-protocol-architectures"> <reference anchor="Oran2018QoSslides" target="https://datatracker.ietf.o rg/meeting/interim-2018-icnrg-03/materials/slides-interim-2018-icnrg-03-sessa-th oughts-on-qos-for-ndnccn-style-icn-protocol-architectures">
<front> <front>
<title>Thoughts on Quality of Service for NDN/CCN-style ICN protocol architectures</title> <title>Thoughts on Quality of Service for NDN/CCN-style ICN protocol architectures</title>
<author surname="Oran" initials="D." fullname="Dave Oran"/> <author surname="Oran" initials="D." fullname="Dave Oran"/>
<date year="2018" month="September" day="24"/> <date year="2018" month="September" day="24"/>
</front> </front>
<refcontent>presented at ICNRG Interim Meeting, Cambridge MA</refconte nt> <refcontent>presented at ICNRG Interim Meeting, Cambridge, MA</refcont ent>
</reference> </reference>
<reference anchor="NDNTutorials" target="https://named-data.net/publicat ions/tutorials/"> <reference anchor="NDNTutorials" target="https://named-data.net/publicat ions/tutorials/">
<front> <front>
<title>NDN Tutorials</title> <title>NDN Tutorials</title>
<author surname="NDN team"/> <author surname="NDN team"/>
<date>various</date>
</front> </front>
</reference> </reference>
<reference anchor="NDN" target="https://named-data.net/project/execsumma ry/"> <reference anchor="NDN" target="https://named-data.net/project/execsumma ry/">
<front> <front>
<title>Named Data Networking</title> <title>Named Data Networking: Executive Summary</title>
<author surname="NDN team"/> <author surname="NDN team"/>
<date>various</date>
</front> </front>
</reference> </reference>
<reference anchor="minmaxfairness" target="https://en.wikipedia.org/wiki /Max-min_fairness"> <reference anchor="minmaxfairness" target="https://en.wikipedia.org/w/in dex.php?title=Max-min_fairness&amp;oldid=1028246910">
<front> <front>
<title>Max-min Fairness</title> <title>Max-min fairness</title>
<author surname="Wikipedia"/> <author>
<date>no date</date> <organization>Wikipedia</organization>
</author>
<date year="2021" month="June"/>
</front> </front>
</reference> </reference>
<reference anchor="proportionalfairness" target="https://en.wikipedia.or g/wiki/Proportionally_fair"> <reference anchor="proportionalfairness" target="https://en.wikipedia.or g/w/index.php?title=Proportional-fair_scheduling&amp;oldid=1027073289">
<front> <front>
<title>Proportionally Fair</title> <title>Proportional-fair scheduling</title>
<author surname="Wikipedia"/> <author>
<date>no date</date> <organization>Wikipedia</organization>
</author>
<date year="2021" month="June"/>
</front> </front>
</reference> </reference>
<reference anchor="AS" target="https://en.wikipedia.org/wiki/Autonomous_ system_(Internet)"> <reference anchor="AS" target="https://en.wikipedia.org/w/index.php?titl e=Autonomous_system_(Internet)&amp;oldid=1025244754">
<front> <front>
<title>Autonomous System (Internet)</title> <title>Autonomous system (Internet)</title>
<author surname="Wikipedia"/> <author>
<date>no date</date> <organization>Wikipedia</organization>
</author>
<date year="2021" month="May"/>
</front> </front>
</reference> </reference>
<reference anchor="Shenker2006" target="https://dl.acm.org/citation.cfm? id=2316898"> <reference anchor="Shenker2006" target="https://dl.acm.org/doi/10.1109/4 9.414637">
<front> <front>
<title>Fundamental Design Issues for the Future Internet</title> <title>Fundamental design issues for the future Internet</title>
<seriesInfo name="DOI" value="10.1109/49.414637"/>
<author surname="Shenker" initials="S."/> <author surname="Shenker" initials="S."/>
<date year="2006" month="September"/> <date year="2006" month="September"/>
</front> </front>
<refcontent>in IEEE Journal on Selected Areas in Communications, Vol. 13, No. 7</refcontent> <refcontent>in IEEE Journal on Selected Areas in Communications, Vol. 13, No. 7</refcontent>
<seriesInfo name="DOI" value="10.1109/49.414637"/>
</reference> </reference>
<reference anchor="Wang2000" target="https://ieeexplore.ieee.org/documen t/819168?arnumber=819168"> <reference anchor="Wang2000" target="https://ieeexplore.ieee.org/documen t/819168">
<front> <front>
<title>Multicast routing and its QoS extension: problems, algorithms , and protocols</title> <title>Multicast routing and its QoS extension: problems, algorithms , and protocols</title>
<seriesInfo name="DOI" value="10.1109/65.819168"/>
<author surname="Wang" initials="B."/> <author surname="Wang" initials="B."/>
<author surname="Hou" initials="J.C."/> <author surname="Hou" initials="J. C."/>
<date year="2000" month="January"/> <date year="2000" month="January"/>
</front> </front>
<refcontent>in IEEE Network, Vol:14, Issue:1, Jan/Feb 2000</refcontent <refcontent>in IEEE Network, Vol. 14, Issue 1</refcontent>
> <seriesInfo name="DOI" value="10.1109/65.819168"/>
</reference> </reference>
<reference anchor="Tseng2003" target="https://onlinelibrary.wiley.com/do i/abs/10.1002/net.10084"> <reference anchor="Tseng2003" target="https://onlinelibrary.wiley.com/do i/abs/10.1002/net.10084">
<front> <front>
<title>The performance of QoS-aware IP multicast routing protocols</ title> <title>The performance of QoS-aware IP multicast routing protocols</ title>
<seriesInfo name="DOI" value="10.1002/net.10084"/> <author surname="Tseng" initials="C.-J."/>
<author surname="Tseng" initials="CH.J."/> <author surname="Chen" initials="C.-H."/>
<date year="2003" month="September"/> <date year="2003" month="September"/>
</front> </front>
<refcontent>in Networks, Vol:42, No:2</refcontent> <refcontent>in Networks, Vol. 42</refcontent>
<seriesInfo name="DOI" value="10.1002/net.10084"/>
</reference> </reference>
<reference anchor="Krol2018" target="https://conferences.sigcomm.org/acm -icn/2018/proceedings/icn18-final9.pdf"> <reference anchor="Krol2018" target="https://conferences.sigcomm.org/acm -icn/2018/proceedings/icn18-final9.pdf">
<front> <front>
<title>RICE: Remote Method Invocation in ICN</title> <title>RICE: Remote Method Invocation in ICN</title>
<seriesInfo name="DOI" value="10.1145/3267955.3267956"/>
<author surname="Król" initials="M." fullname="Michał Król" asciiSur name="Krol" asciiFullname="Michal Krol"/> <author surname="Król" initials="M." fullname="Michał Król" asciiSur name="Krol" asciiFullname="Michal Krol"/>
<author surname="Habak" initials="K." fullname="Karim Habak"/> <author surname="Habak" initials="K." fullname="Karim Habak"/>
<author surname="Oran" initials="D." fullname="David Oran"/> <author surname="Oran" initials="D." fullname="David Oran"/>
<author surname="Kutscher" initials="D." fullname="Dirk Kutscher"/> <author surname="Kutscher" initials="D." fullname="Dirk Kutscher"/>
<author surname="Psaras" initials="I." fullname="Ioannis Psaras"/> <author surname="Psaras" initials="I." fullname="Ioannis Psaras"/>
<date year="2018" month="September"/> <date year="2018" month="September"/>
</front> </front>
<refcontent>in ICN'18: Proceedings of the 5th ACM Conference on Inform <refcontent>in ICN '18: Proceedings of the 5th ACM Conference on Infor
ation-Centric Networking September 21-23, 2018, Boston, MA, USA</refcontent> mation-Centric Networking, Boston, MA, USA</refcontent>
<seriesInfo name="DOI" value="10.1145/3267955.3267956"/>
</reference> </reference>
<reference anchor="BenAbraham2018" target="https://conferences.sigcomm.o rg/acm-icn/2018/proceedings/icn18-final31.pdf"> <reference anchor="BenAbraham2018" target="https://conferences.sigcomm.o rg/acm-icn/2018/proceedings/icn18-final31.pdf">
<front> <front>
<title>"Decoupling Information and Connectivity via Information-Cent <title>Decoupling Information and Connectivity via Information-Centr
ric Transport</title> ic Transport</title>
<seriesInfo name="DOI" value="10.1145/3267955.3267963"/>
<author surname="Ben Abraham" initials="H."/> <author surname="Ben Abraham" initials="H."/>
<author surname="Parwatikar" initials="J."/> <author surname="Parwatikar" initials="J."/>
<author surname="DeHart" initials="J."/> <author surname="DeHart" initials="J."/>
<author surname="Dresher" initials="A."/> <author surname="Dresher" initials="A."/>
<author surname="Crowley" initials="P."/> <author surname="Crowley" initials="P."/>
<date year="2018" month="September"/> <date year="2018" month="September"/>
</front> </front>
<refcontent>in ICN '18: Proceedings of the 5th ACM Conference on Infor <refcontent>in ICN '18: Proceedings of the 5th ACM Conference on Infor
mation-Centric Networking September 21-23, 2018, Boston, MA, USA</refcontent> mation-Centric Networking, Boston, MA, USA</refcontent>
<seriesInfo name="DOI" value="10.1145/3267955.3267963"/>
</reference> </reference>
<reference anchor="Schneider2016" target="http://conferences2.sigcomm.or g/acm-icn/2016/proceedings/p21-schneider.pdf"> <reference anchor="Schneider2016" target="http://conferences2.sigcomm.or g/acm-icn/2016/proceedings/p21-schneider.pdf">
<front> <front>
<title>"A Practical Congestion Control Scheme for Named Data Network <title>A Practical Congestion Control Scheme for Named Data Networki
ing</title> ng</title>
<seriesInfo name="DOI" value="10.1145/2984356.2984369"/>
<author surname="Schneider" initials="K."/> <author surname="Schneider" initials="K."/>
<author surname="Yi" initials="C."/> <author surname="Yi" initials="C."/>
<author surname="Zhang" initials="B."/> <author surname="Zhang" initials="B."/>
<author surname="Zhang" initials="L."/> <author surname="Zhang" initials="L."/>
<date year="2016" month="September"/> <date year="2016" month="September"/>
</front> </front>
<refcontent>in ACM-ICN '16: Proceedings of the 3rd ACM Conference on I nformation-Centric Networking</refcontent> <refcontent>in ACM-ICN '16: Proceedings of the 3rd ACM Conference on I nformation-Centric Networking</refcontent>
<seriesInfo name="DOI" value="10.1145/2984356.2984369"/>
</reference> </reference>
<reference anchor="Autonet" target="https://www.hpl.hp.com/techreports/C ompaq-DEC/SRC-RR-59.pdf"> <reference anchor="Autonet" target="https://www.hpl.hp.com/techreports/C ompaq-DEC/SRC-RR-59.pdf">
<front> <front>
<title>Autonet: a High-speed, Self-configuring Local Area Network Us ing Point-to-point Links</title> <title>Autonet: a High-speed, Self-configuring Local Area Network Us ing Point-to-point Links</title>
<seriesInfo name="DOI" value="10.1109/49.105178"/>
<author surname="Schroeder" initials="M."/> <author surname="Schroeder" initials="M."/>
<author surname="Birrell" initials="A."/> <author surname="Birrell" initials="A."/>
<author surname="Burrows" initials="M."/> <author surname="Burrows" initials="M."/>
<author surname="Murray" initials="H."/> <author surname="Murray" initials="H."/>
<author surname="Needham" initials="R."/> <author surname="Needham" initials="R."/>
<author surname="Rodeheffer" initials="T."/> <author surname="Rodeheffer" initials="T."/>
<author surname="Satterthwaite" initials="E."/> <author surname="Satterthwaite" initials="E."/>
<author surname="Thacker" initials="C."/> <author surname="Thacker" initials="C."/>
<date year="1991" month="October"/> <date year="1991" month="October"/>
</front> </front>
<refcontent>in IEEE Journal on Selected Areas in Communications ( Volu <refcontent>in IEEE Journal on Selected Areas in Communications, Vol.
me: 9, Issue: 8, Oct 1991)</refcontent> 9, No. 8</refcontent>
<seriesInfo name="DOI" value="10.1109/49.105178"/>
</reference> </reference>
<reference anchor="Moiseenko2017" target="https://conferences.sigcomm.or g/acm-icn/2017/proceedings/icn17-2.pdf"> <reference anchor="Moiseenko2017" target="https://conferences.sigcomm.or g/acm-icn/2017/proceedings/icn17-2.pdf">
<front> <front>
<title>Path Switching in Content Centric and Named Data Networks</ti tle> <title>Path Switching in Content Centric and Named Data Networks</ti tle>
<seriesInfo name="DOI" value="10.1145/3125719.3125721"/>
<author surname="Moiseenko" initials="I."/> <author surname="Moiseenko" initials="I."/>
<author surname="Oran" initials="D."/> <author surname="Oran" initials="D."/>
<date year="2017" month="September"/> <date year="2017" month="September"/>
</front> </front>
<refcontent>in ICN '17: Proceedings of the 4th ACM Conference on Infor mation-Centric Networking</refcontent> <refcontent>in ICN '17: Proceedings of the 4th ACM Conference on Infor mation-Centric Networking</refcontent>
<seriesInfo name="DOI" value="10.1145/3125719.3125721"/>
</reference> </reference>
<reference anchor='Auge2018' target='https://ieeexplore.ieee.org/documen t/8267132'> <reference anchor='Auge2018' target='https://ieeexplore.ieee.org/documen t/8267132'>
<front> <front>
<title>MAP-Me: Managing Anchor-Less Producer Mobi <title>MAP-Me: Managing Anchor-Less Producer Mobility in Content-Centric
lity in Content-Centric Networks</title> Networks</title>
<author surname='Augé' initials='J.' fullname='Jo <author surname='Augé' initials='J.' fullname='Jordan Augé' asciiFullname
rdan Augé' asciiFullname="Jordan Auge" asciiSurname="Auge"/> ="Jordan Auge" asciiSurname="Auge"/>
<author surname='Carofiglio' initials='G.' fullna <author surname='Carofiglio' initials='G.' fullname='Giovanna Carofiglio'
me='Giovanna Carofiglio'/> />
<author initials='G.' surname='Grassi'/> <author initials='G.' surname='Grassi'/>
<author initials='L.' surname='Muscariello' fulln <author initials='L.' surname='Muscariello' fullname='Luca Muscariello'/>
ame='Luca Muscariello'/> <author initials='G.' surname='Pau'/>
<author initials='G.' surname='Pau'/> <author initials='X.' surname='Zeng'/>
<author initials='X.' surname='Zeng'/> <date month='June' year='2018'/>
<date month='June' year='2018'/> </front>
</front> <seriesInfo name='DOI' value='10.1109/TNSM.2018.2796720'/>
<seriesInfo name='DOI' value='10.1109/TNSM.2018.2796720'/ <refcontent>in IEEE Transactions on Network and Service Management, Vol.
> 15, No. 2</refcontent>
<refcontent>in IEEE Transactions on Network and Service M </reference>
anagement (Volume: 15 , Issue: 2 , June 2018)</refcontent>
</reference>
</references> </references>
</references> </references>
<!-- Change Log
v00 2019-07-13 DRO Initial version
v06 2020-11-20 DRO Respond to IRSG Bollot comments from Spencer Da
wkins & Mallory Knodel -->
</back> </back>
</rfc> </rfc>
 End of changes. 147 change blocks. 
678 lines changed or deleted 723 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/