<?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. --> version="1.0" encoding="UTF-8"?>

<!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"
	category="info"
     docName="draft-oran-icnrg-qosarch-06"
     number="9064"
     submissionType="IRTF"
     category="info"
     ipr="trust200902"
     obsoletes=""
     updates=""
	submissionType="IRTF"
     xml:lang="en"
     tocInclude="true"
     tocDepth="4"
     symRefs="true"
     sortRefs="true"
     version="3">
  <!-- xml2rfc v2v3 conversion 2.40.0 -->
  <!-- category values: std, bcp, info, exp, and historic
     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>
    <title abbrev="Thoughts on ICN QoS Architecture">
    Considerations in the development Development of a QoS Architecture for CCNx-like ICN protocols CCNx-Like Information-Centric Networking Protocols
    </title>
    <seriesInfo name="Internet-Draft" value="draft-oran-icnrg-qosarch-06"/> name="RFC" value="9064"/>
    <author fullname="Dave Oran" surname="D. Oran">
      <organization>Network Systems Research and Design</organization>
      <address>
        <postal>
          <street>4 Shady Hill Square</street>
          <city>Cambridge</city>
          <region>MA</region>
          <code>02138</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone/>
        <email>daveoran@orandom.net</email>
        <!-- uri and facsimile elements may also be added -->
        </address>
    </author>

    <date year="2020"/>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc 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 specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

    <!-- Meta-data Declarations -->
    <workgroup>ICNRG</workgroup> year="2021" month="June" />

    <workgroup>Information-Centric Networking</workgroup>

    <keyword>ICN</keyword>
    <keyword>QoS</keyword>
    <keyword>congestion 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>

      <t>This is a position paper. It documents the author's personal views on how Quality of Service (QoS) capabilities ought to be accommodated in ICN Information-Centric Networking (ICN) protocols like CCNx Content-Centric Networking (CCNx) or NDN Named Data Networking (NDN), which employ flow-balanced Interest/Data exchanges and hop-by-hop forwarding state as their fundamental machinery. It argues that such protocols demand a substantially different approach to QoS from that taken in TCP/IP, TCP/IP and proposes specific design patterns to achieve both classification and differentiated QoS treatment on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU CPU, and link bandwidth as a resource resources that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve both transport transport- and higher layer higher-layer QoS objectives. It explicitly excludes any discussion of Quality of Experience (QoE) (QoE), which can only be assessed and controlled at the application layer or above. </t>

      <t>This document is not a product of the IRTF Information-Centric Networking Research Group (ICNRG) but has been through formal last call Last Call and has the support of the participants in the research group for publication as an individual submission.</t>
    </abstract>
</front>

<middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
   <t>The TCP/IP protocol suite used on today's Internet has over 30 years of accumulated research and engineering into the provision of Quality provisioning of Service QoS machinery, employed with varying success in different environments. ICN protocols like Named Data Networking (NDN NDN <xref target="NDN" format="default"/>) format="default"/> and Content-Centric Networking (CCNx CCNx <xref target="RFC8569" format="default"/>,<xref format="default"/> <xref target="RFC8609" format="default"/>) format="default"/> have an accumulated 10 ten years of research and very little deployment. We therefore have the opportunity to either recapitulate the approaches taken with TCP/IP (e.g. (e.g., Intserv <xref target="RFC2998" format="default"/> and Diffserv <xref target="RFC2474" format="default"/>) or design a new architecture and associated mechanisms aligned with the properties of ICN protocols protocols, 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) QoS capabilities ought to be accommodated in ICN protocols like CCNx or NDN. Specifically, these protocols differ in fundamental ways from TCP/IP. The important differences are summarized in the following table:</t> <xref target="IPvsICN" format="default"/>:</t>
      <table anchor="IPvsICN" align="center">
        <name>Differences between IP and ICN relevant Relevant to QoS architecture</name> Architecture</name>
        <thead>
          <tr>
            <th align="center">TCP/IP</th>
            <th align="center">CCNx or NDN</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">Stateless forwarding</td>
            <td align="center">Stateful forwarding</td>
          </tr>
          <tr>
            <td align="center">Simple Packets</td> packets</td>
            <td align="center">Object model with optional caching</td>
          </tr>
          <tr>
            <td align="center">Pure datagram model</td>
            <td align="center">Request-response model</td>
          </tr>
          <tr>
            <td align="center">Asymmetric Routing</td> routing</td>
            <td align="center">Symmetric Routing</td> routing</td>
          </tr>
          <tr>
            <td align="center">Independent flow directions</td>
            <td align="center">Flow balance<sup>*</sup></td> balance (see note below)</td>
          </tr>
          <tr>
            <td align="center">Flows grouped by IP prefix and port</td>
            <td align="center">Flows grouped by name prefix</td>
          </tr>
          <tr>
            <td align="center">End-to-end congestion control</td>
            <td align="center">Hop-by-hop congestion control</td>
          </tr>
        </tbody>
        </table>
        <aside><t><sup>*</sup>Flow Balance
        <aside><t>Note: Flow balance is a property of NDN and CCNx that ensures one Interest packet provokes a response of no more than one data Data packet. Further discussion of the relevance of this to QoS can be found in <xref target="I-D.oran-icnrg-flowbalance"/></t></aside> target="I-D.oran-icnrg-flowbalance"/>.</t></aside>
	<t>This document proposes specific design patterns to achieve both flow classification and differentiated QoS treatment for ICN on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU CPU, and link bandwidth as a resource resources that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve both transport and higher layer higher-layer QoS objectives. It does not propose detailed protocol machinery to achieve these goals; it leaves these to supplementary specifications, such as <xref target="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 Quality of Experience (QoE) QoE, which can only be assessed and controlled at the application 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 datatracker (see, for example example, <xref target="Oran2018QoSslides" format="default"/>).</t>

    <section><name>Applicability Assessment by ICNRG Chairs</name>
      	<t>QoS in ICN is an important topic with a huge design space. ICNRG has been discussing different specific protocol mechanisms as well as conceptual approaches. This document presents architectural considerations for QoS, leveraging ICN properties instead of merely applying IP-QoS mechanisms — mechanisms, without defining a specific architecture or specific protocols protocol mechanisms yet. However, there is consensus in ICNRG that this document, clarifying the author’s author's views, could inspire such work and should hence be published as a position paper.</t>
      </section>
    </section>

<section numbered="true" toc="default">
<name>Requirements Language</name>
    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC2119" format="default">RFC 2119</xref>.</t> target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t>
</section>

<section anchor="background" numbered="true" toc="default">
<name>Background on Quality of Service in network protocols</name>
<!-- <name>Background on the nature and properties of Quality of Service in network protocols</name> --> Network 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 packet networks. Other parts of it are polemical yet serve to illuminate the author's personal biases and technical views.</t>
    <t>All networking systems provide some degree of "quality of service" in that they exhibit non-zero nonzero utility when offered traffic to carry. In other words, the network is totally useless if it never delivers any of the traffic injected by applications. The term QoS is therefore more correctly applied in a more restricted sense to describe systems that control the allocation of various resources in order to achieve <em>managed unfairness</em>.  Absent explicit mechanisms to decide what which traffic to be unfair to, treat unfairly, most systems try to achieve some form of "fairness" in the allocation of resources, optimizing the overall utility delivered to all offered load traffic under the constraint of available resources. From this this, it should be obvious that you cannot use QoS mechanisms to create or otherwise increase resource capacity! In fact, all known QoS schemes have non-zero nonzero overhead and hence may (albeit slightly) decrease the total resources available to carry user traffic.</t>

    <t>Further, accumulated experience seems to indicate that QoS is helpful in a fairly narrow range of network conditions:</t>
      <ul spacing="normal">
        <li>If your resources are lightly loaded, you don't need it, as neither congestive loss nor substantial queueing queuing delay occurs</li> occurs.</li>
        <li>If your resources are heavily oversubscribed, it doesn't save you. So many users will be unhappy that you are probably not delivering a viable service</li> service.</li>
        <li>
          <t>Failures can rapidly shift your state from the first above to the second, in which case either:
          </t>
          <ul spacing="normal">
            <li>your
            <li>Your QoS machinery cannot respond quickly enough to maintain the advertised service quality continuously, or</li>
            <li>resource
            <li>Resource allocations are sufficiently conservative to result in substantial wasted capacity under non-failure conditions</li> conditions.</li>
          </ul>
        </li>
      </ul>

    <t>Nevertheless, though not universally deployed, QoS is advantageous at least for some applications and some network environments. Some examples include:</t>
      <ul spacing="normal">
        <li>applications
        <li>Applications with steep utility functions <xref target="Shenker2006" format="default"/>, such as real-time multimedia</li>
        <li>applications
        <li>Applications with safety-critical operational constraints, such as avionics or industrial automation</li>
        <li>dedicated
        <li>Dedicated or tightly managed networks whose economics depend on strict adherence to challenging service level agreements (SLAs)</li>
      </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>

      <ul spacing="normal">
        <li>Some signaled QoS schemes, such as RSVP (Resource the Resource reSerVation Protocol) Protocol (RSVP) <xref target="RFC2205" format="default"/>, maintain state in routers for each flow, which scales linearly with the number of flows. For core routers through which pass millions to billions of flows, the memory required is infeasible to provide.</li>
        <li>The Internet is comprised of many minimally cooperating autonomous systems <xref target="AS" format="default"/>. There are practically no successful examples of QoS deployments crossing the AS boundaries of multiple service providers. This in In almost all cases cases, this limits the applicability of QoS capabilities to be intra-domain.</li>
      </ul>

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

    <aside><t><sup>*</sup>This

    <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 1990's said 1990s said, "[The problem we are solving is to] Give ‘better’ 'better' service to some at the expense of giving worse service to others. QoS fantasies to the contrary, it’s it's a zero sum 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 ascertain to which user to allocate the usage. Others cannot. While the choice of mechanism may have important practical economic and political consequences for cost and workable business models, this document considers none of those things and discusses QoS only in the context of providing managed unfairness.</t>

    <t>For those unfamiliar with ICN protocols, a brief description of how NDN and CCNx operate as a packet network is below in <xref target="ICNbasics"/>. Some further background on congestion control for ICN follows in <xref target="CCbasics"/>.</t>

    <section anchor="ICNbasics" numbered="true" toc="default">
    <name>Basics on how How ICN protocols Protocols like NDN and CCNx work</name> Work</name>
    	<t>The following is intended as a brief summary of summarizes the salient features of the NDN and CCnx CCNx ICN protocols relevant to congestion control and QoS. Quite extensive tutorial information may be found in a number of places places, including material available from <xref target="NDNTutorials"/>.</t>

    	<t>In NDN and CCNx, all protocol interactions operate as a two-way handshake. Named content is requested by a <em>consumer</em> via an <em>Interest message</em> which 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>producer</em> of the data, data or a forwarder holding a cached copy of the requested data. The content matching the name in the Interest message is returned to the requester over the <em>inverse</em> of the path traversed by the corresponding Interest.</t>

    	<t>Forwarding in CCNx and NDN is <em>per-packet stateful</em>. Routing information to select next-hops next hop(s) for an Interest is obtained from a <em>Forwarding Information Base (FIB)</em> (FIB)</em>, which is similar in function to the FIB in an IP router, router except that it holds name prefixes rather than IP address prefixes. Conventionally Conventionally, a <em>Longest Name Prefix Match (LNPM)</em> is used for lookup, although other algorithms are possible possible, including controlled flooding and adaptive learning 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> (PIT)</em>, is used to forward the returning Data message to the consumer. Since the PIT constitutes per-packet state state, it is therefore a large consumer of memory resources resources, especially in forwarders carrying high traffic loads over long Round Trip Round-Trip Time (RTT) paths, and hence plays a substantial role as a QoS-controllable 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, optionally storing a copy of any Data messages it has seen in a local data structure known as a <em>Content Store (CS)</em>. Data in the Content Store CS may be returned in response to a matching Interest rather than forwarding the Interest further through the network to the original Producer. Both CCNx and NDN have a variety of ways to configure caching, including mechanisms to avoid both cache pollution and cache poisoning (these are clearly beyond the scope of this brief introduction).</t>
    </section>

    <section anchor="CCbasics" numbered="true" toc="default">
    <name>Congestion Control basics relevant Basics Relevant to ICN</name>

      <t>In any packet network that multiplexes traffic among multiple sources and destinations, congestion control is necessary in order to:</t>
        <ol spacing="normal" type="1">
          <li>Prevent collapse of utility due to overload, where the total offered service declines as load increases, perhaps precipitously, rather than increasing or remaining flat.</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 max-min fairness <xref target="minmaxfairness" format="default"/> and proportional fairness <xref target="proportionalfairness" format="default"/> format="default"/>, both of which have been implemented and deployed successfully on packet networks for many years.</li>
        </ol>
        <t>Before moving on to QoS, it is useful to consider how congestion control works in NDN or CCNx. Unlike the IP protocol family, which relies exclusively on end-to-end congestion control (e.g. TCP<xref (e.g., TCP <xref target="RFC0793" format="default"/>, DCCP<xref DCCP <xref target="RFC4340" format="default"/>, SCTP<xref SCTP <xref target="RFC4960" format="default"/>, QUIC<xref target="I-D.ietf-quic-transport" and QUIC <xref target="RFC9000" format="default"/>), CCNx and NDN can employ hop-by-hop congestion control. There is per-Interest/Data state at every hop of the path path, and therefore outstanding Interests provide information that can be used to optimize resource allocation for data returning on the inverse path, such as bandwidth sharing, prioritization prioritization, and overload control. In current designs, this allocation is often done using Interest counting. By accepting one Interest packet from a downstream node, implicitly this implicitly provides 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 congestion control schemes have been developed for ICN that operate in this fashion, for example example, <xref target="Wang2013" format="default"/>, <xref target="Mahdian2016" format="default"/>, <xref target="Song2018" format="default"/>, and <xref target="Carofiglio2012" format="default"/>. Other schemes, like <xref target="Schneider2016" format="default"/> format="default"/>, neither count nor police Interests, Interests but instead monitor queues using AQM (active queue management) to mark returning Data packets that have experienced congestion. This later class of schemes is similar to those used on IP in the sense that they depend on consumers adequately reducing their rate of Interest injection to avoid Data packet drops due to buffer overflow in forwarders. The former class of schemes is (arguably) more robust against mis-behavior misbehavior by consumers.
</t>
        <t>Given the stochastic nature of round trip times, RTTs, and the ubiquity of wireless links and encapsulation tunnels with variable bandwidth, a simple scheme that admits interests Interests only based on a time-invariant estimate of the returning link bandwidth will perform poorly. However, two characteristics of NDN and CCNx-like protocols can help substantially to improve the accuracy and responsiveness of the bandwidth allocation:
</t>
        <ol spacing="normal" type="1">
          <li>RTT is bounded by the inclusion of an <em>Interest Lifetime</em> in each Interest message, which puts an upper bound on the RTT uncertainty for any given Interest/Data exchange. If Interest lifetimes Lifetimes are kept reasonably short (a few RTTs) RTTs), the allocation of local forwarder resources do not have to deal with an arbitrarily long tail. One could in fact do a deterministic allocation on this basis, but the result would be highly pessimistic. Nevertheless, having a cut-off cutoff does improve the performance of an optimistic allocation scheme.</li>
          <li>Returning Data packets can be
          <li>A congestion marked by an ECN-like marking scheme like that used in Explicit Congestion Notification (ECN) can be used to mark returning Data packets if the inverse link starts experiencing long queue occupancy or other congestion indication. Unlike TCP/IP, where the rate adjustment can only be done end-to-end, this feedback is usable immediately by the downstream ICN forwarder forwarder, and the Interest shaping rate is lowered after a single link RTT. This may allow less pessimistic rate adjustment schemes that are less pessimistic than the Additive Increase, Multiplicative Decrease (AIMD) scheme with .5 multiplier that is commonly used on TCP/IP networks. It also allows the rate adjustments to be spread more accurately among the Interest/Data flows traversing a link sending congestion signals.</li>
        </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> format="default"/>.</t>
      </section>
    </section>
    <section anchor="basics" numbered="true" toc="default">
      <name>What can we control Can We Control to achieve Achieve QoS in ICN?</name>
      <t>QoS is achieved through managed unfairness in the allocation of resources in network elements, particularly in the routers doing forwarding of that forward ICN packets. So, a first order question is what Hence, the first-order questions are the following: Which resources need to be allocated, and how to allocated? How do you ascertain which traffic gets what allocations. those allocations? In the case of CCNx or NDN NDN, the important network element resources are:</t> are given in <xref target="ICNresources" format="default"/>:</t>
      <table anchor="ICNresources" align="center">
        <name>ICN-related
        <name>ICN-Related Network Element Resources</name>
        <thead>
          <tr>
            <th align="center">Resource</th> align="left">Resource</th>
            <th align="left">ICN Usage</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">Communication Link align="left">Communication link capacity</td>
            <td align="left">buffering for queued packets</td>
          </tr>
          <tr>
            <td align="center">Content Store align="left">CS capacity</td>
            <td align="left">to hold cached data</td>
          </tr>
          <tr>
            <td align="center">Forwarder align="left">Forwarder memory</td>
            <td align="left">for the Pending Interest Table (PIT)</td> PIT</td>
          </tr>
          <tr>
            <td align="center">Compute align="left">Compute capacity</td>
            <td align="left">for forwarding packets, including the cost of Forwarding Information Base (FIB) lookups.</td> FIB lookups</td>
          </tr>
        </tbody>
      </table>
      <t>For these resources, any QoS scheme has to specify two things:
</t>
      <ol spacing="normal" type="1">
        <li>How do you create <em>equivalence classes</em> (a.k.a. flows) of traffic to which different QoS treatments are applied?</li>
        <li>What are the possible treatments and how are those mapped to the resource allocation algorithms?</li>
      </ol>
      <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 network element is bounded by both memory and processing capacity to do the necessary lookups. One can allow very fine-grained equivalence classes, classes but not be able to employ them globally because of scaling limits of core routers. That means it is wise to either restrict the range of equivalence classes, classes or allow them to be <em>aggregated</em>, trading off accuracy in policing traffic against ability to scale.</t>
      <t>Second, the flexibility of expressible treatments can be tightly constrained by both protocol encoding and algorithmic limitations. The ability to encode the treatment requests in the protocol can be limited (as -- as it is for IP - where there are only 6 six of the Type of Service (TOS) bits available for Diffserv treatments), but as treatments. However, an equal or more important issue is whether there are practical traffic policing, queuing, and pacing algorithms that can be combined to support a rich set of QoS treatments.</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 needed to enqueue or dequeue a packet.
</t>
    </section>
    <section anchor="ipisdifferent" numbered="true" toc="default">
      <name>How does this relate Does This Relate to QoS in TCP/IP?</name>
      <t>TCP/IP has fewer resource types to manage than ICN, and in some cases cases, the allocation methods are simpler, as shown in the following table:</t> <xref target="TCPIPresources" format="default"/>:</t>
      <table anchor="TCPIPresources" align="center">
        <name>IP-related
        <name>IP-Related Network Element Resources</name>
        <thead>
          <tr>
            <th align="left">Resource</th>
            <th align="center">IP Relevant</th>
            <th align="left">TCP/IP Usage</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">Communication Link link capacity</td>
            <td align="center">YES</td>
            <td align="left">buffering for queued packets</td>
          </tr>
          <tr>
            <td align="left">Content Store align="left">CS capacity</td>
            <td align="center">NO</td>
            <td align="left">no content store CS in IP</td>
          </tr>
          <tr>
            <td align="left">Forwarder memory</td>
            <td align="center">MAYBE</td>
            <td align="left">not needed for output-buffered designs<sup>*</sup> </td> designs (see note below)</td>
          </tr>
          <tr>
            <td align="left">Compute capacity</td>
            <td align="center">YES</td>
            <td align="left">for forwarding packets, but arguably much cheaper than ICN</td>
          </tr>
        </tbody>
      </table>

      <t><sup>*</sup>Output-buffered designs are where

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

      <t>For these resources, IP has specified three fundamental things, as shown in the following table:</t> <xref target="IPQoSspecifiers" format="default"/>:</t>

      <table anchor="IPQoSspecifiers" align="center">
        <name>Fundamental protocol elements Protocol Elements to achieve Achieve QoS for TCP/IP</name>
        <thead>
          <tr>
            <th align="center">What</th>
            <th align="left">How</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">
              <strong>Equivalence classes</strong></td>
              Equivalence classes</td>
            <td align="left">subset+prefix align="left"><t>subset+prefix match on IP 5-tuple {SA,DA,SP,DP,PT}<br/>
            	SA=Source Address<br/>
            	DA=Destination Address<br/>
            	SP=Source Port<br/>
            	DP=Desintation
            	DP=Destination Port<br/>
            	PT=IP Protocol Type</td> Type</t></td>
          </tr>
          <tr>
            <td align="center">
              <strong>Diffserv treatments</strong></td>
              Diffserv treatments</td>
            <td align="left">(very) small number of globally-agreed traffic classes</td>
          </tr>
          <tr>
            <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>
          </tr>
        </tbody>
      </table>
      <t>Equivalence classes for IP can be pairwise, by matching against both source and destination address+port, pure group using only destination address+port, or source-specific multicast with source adress+port address+port and destination multicast address+port.</t>
      <t>With Intserv, the Resource ReSerVation signaling protocol (RSVP) RSVP <xref target="RFC2205" format="default"/> carries two data structures, structures: the Flow Specifier (FLOWSPEC) and the Traffic Specifier (TSPEC). The former fulfills the requirement to identify the equivalence class to which the QoS being signaled applies. The latter comprises the desired QoS treatment along with a description of the dynamic character of the traffic (e.g. (e.g., average bandwidth and delay, peak bandwidth, etc.). Both of these encounter substantial scaling limits, which has meant that Intserv has historically been limited to confined topologies, and/or high-value usages, like traffic engineering.</t>
      <t>With Diffserv, the protocol encoding (6 (six bits in the TOS field of the IP header) artificially limits the number of classes one can specify. These are documented in <xref target="RFC4594" format="default"/>. Nonetheless, when used with fine-grained equivalence classes, one still runs into limits on the number of queues required.</t>
    </section>
    <section anchor="icnisdifferent" numbered="true" toc="default">
      <name>Why is Is ICN Different? Can we do We Do Better?</name>
      <t>While one could adopt an approach to QoS mirroring that mirrors the extensive experience with TCP/IP, this would, in the author's view, be a mistake. The implementation and deployment of QoS in IP networks has been spotty at best. There are are, of course course, economic and political reasons as well as technical reasons for these mixed results, but there are several architectural choices in ICN that make it a potentially much better protocol base to enhance with QoS machinery. This section discusses those differences and their consequences.</t>
      <section anchor="icnflows" numbered="true" toc="default">
        <name>Equivalence class capabilities</name> Class Capabilities</name>
        <t>First and foremost, hierarchical names are a much richer basis for specifying equivalence classes than IP 5-tuples. The IP address (or prefix) can only separate traffic by topology to the granularity of hosts, hosts and not cannot express actual computational instances nor sets of data. Ports give some degree of per-instance demultiplexing, but this tends to be both coarse and ephemeral, while confounding the demultiplexing function with the assignment of QoS treatments to particular subsets of the data. Some degree of finer granularity is possible with IPv6 by exploiting the ability to use up to 64 bits of address for classifying traffic. In fact, the hICN Hybrid Information-Centric Networking (hICN) project <xref target="I-D.muscariello-intarea-hicn" format="default"/>, while adopting the request-response model of CCNx, uses IPv6 addresses as the available namespace, and IPv6 packets (plus "fake" TCP headers) as the wire format.</t>
        <t>Nonetheless, the flexibility of tokenized (i.e. (i.e., strings treated as opaque tokens), variable length, hierarchical names allows one to directly associate classes of traffic for QoS purposes with the structure of an application namespace. The classification can be as coarse or fine-grained as desired by the application. While not <em>always</em> the case, there is typically a straightforward association between how objects are named, named and how they are grouped together for common treatment. Examples abound; a number can be conveniently found in <xref target="I-D.moiseenko-icnrg-flowclass" format="default"/>.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Topology interactions Interactions with QoS</name>
        <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-destination and multi-path multipath environments in a straightforward manner, rather than requiring either multicast with coarse class-based scheduling or complex signaling like that in RSVP-TE RSVP Traffic Engineering (RSVP-TE) <xref target="RFC3209" format="default"/> that is needed to make point-to-multipoint Muti-Protocol Multiprotocol Label Switching (MPLS) work.</t>
        <t>Because of IP's stateless forwarding model, complicated by the ubiquity of asymmetric routes, any flow-based QoS requires state that is decoupled from the actual arrival of traffic and hence must be maintained, at least as soft-state, soft state, even during quiescent periods. Intserv, for example, requires flow signaling with state O(#flows). on the order of O(number of flows). ICN, even worst case, requires state O(#active order of O(number of active Interest/Data exchanges), since state can be instantiated on arrival of an Interest, Interest and removed (perhaps lazily) once the data has been returned.</t>
      </section>
      <section anchor="qostreatments" numbered="true" toc="default">
        <name>Specification of QoS treatments</name> Treatments</name>
        <t>Unlike Intserv, Diffserv eschews signaling in favor of class-based configuration of resources and queues in network elements. However, Diffserv limits traffic treatments to a few bits taken from the ToS TOS field of IP. No such wire encoding limitations exist for NDN or CCNx, as the protocol is completely TLV (Type-Length-Value) based, and one (or even more than one) new field can be easily defined to carry QoS treatment information.</t>
        <t>Therefore, there are greenfield possibilities for more powerful QoS treatment options in ICN. For example, IP has no way to express a QoS treatment like "try hard to deliver reliably, even at the expense of delay or bandwidth". Such a QoS treatment for ICN could invoke native ICN mechanisms, none of which are present in IP, such as: as the following:
        </t>
        <ul spacing="normal">
          <li>In-network retransmission
          <li>Retransmitting in-network in response to hop-by-hop errors returned from upstream forwarders</li>
          <li>Trying multiple paths to multiple content sources either in parallel or serially</li>
          <li>Assign
          <li>Assigning higher precedence for short-term caching to recover from downstream<sup>*</sup> downstream (see note below) errors</li>
          <li>Coordinating cache utilization with forwarding resources</li>
        </ul>
        <aside><t><sup>*</sup><em>Downstream</em>
        <aside><t>Note: <em>Downstream</em> refers to the direction Data messages flow toward the consumer (the issuer of Interests). Conversely, <em>Upstream</em> refers to the direction Interests flow toward the producer of data.</t></aside>
        <t>Such mechanisms are typically described in NDN and CCNx as <em>forwarding strategies</em>. However, there is little or no guidance is given for what which application actions or protocol machinery is used a forwarder should use to decide which select the appropriate forwarding strategy to use for which Interests that arrive at a forwarder. arriving Interest messages. See <xref target="BenAbraham2018" format="default"/> for an investigation of these issues. Associating forwarding strategies with the equivalence classes and QoS treatments directly can make them more accessible and useful to implement and deploy.</t>

        <t>Stateless forwarding and asymmetric routing in IP limits available state/feedback to manage link resources. In contrast, NDN or CCNx forwarding allows all link resource allocation to occur as part of Interest forwarding, potentially simplifying things considerably. In particular, with symmetric routing, producers have no control over the paths their data Data packets traverse, and hence traverse; hence, any QoS treatments intended to influence routing paths from producer to consumer will have no effect.</t>
        <t>One complication in the handling of ICN QoS treatments is not present in IP and hence worth mention. mentioning. CCNx and NDN both perform <em>Interest aggregation</em> (See Section 2.3.2 of (see <xref target="RFC8569" section="2.4.2" sectionFormat="of" format="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 Interest or forward it, and how to keep track of the differing QoS treatments for the two Interests. Exploration of the details surrounding these situations is beyond the scope of this document; further discussion can be found for the general case of flow balance and congestion control in <xref target="I-D.oran-icnrg-flowbalance" format="default"/>, format="default"/> and specifically for QoS treatments in <xref target="I-D.anilj-icnrg-dnc-qos-icn" format="default"/>.</t>
      </section>
      <section numbered="true" toc="default">
        <name>ICN forwarding semantics effect Forwarding Semantics Effect on QoS</name>
        <t>IP has three forwarding semantics, with different QoS needs (Unicast, Anycast, Multicast). ICN has the single forwarding semantic, so any QoS machinery can be uniformly applied across any request/response invocation. This applies whether the forwarder employs dynamic destination routing, multi-destination forwarding with next-hops next hops tried serially, multi-destination with next-hops next hops used in parallel, or even localized flooding (e.g. (e.g., directly on L2 Layer 2 multicast mechanisms). Additionally, the pull-based model of ICN avoids a number of thorny multicast QoS problems that IP has (<xref (see <xref target="Wang2000" format="default"/>, <xref target="RFC3170" format="default"/>, and <xref target="Tseng2003" format="default"/>).</t>
        <t>The Multi-destination/multi-path Multi-destination/multipath forwarding model in ICN changes resource 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 and consumers as packet sources.</t>
      </section>
      <section numbered="true" toc="default">
        <name>QoS interactions Interactions with Caching</name>
        <t>IP has no caching in routers, whereas ICN needs ways to allocate cache resources. Treatments to control caching operation are unlikely to look much like the treatments used to control link resources. NDN and CCNx already have useful cache control directives associated with Data messages. The CCNx controls include: include the following:
        </t>
        <dl newline="false" spacing="normal">
          <dt>ExpiryTime:</dt>
          <dd>time after which a cached Content Object is considered expired and MUST <bcp14>MUST</bcp14> no longer be used to respond to an Interest from a cache.</dd>
          <dt>Recommended Cache Time:</dt>
          <dd>time after which the publisher considers the Content Object to be of low value to cache.</dd>
        </dl>
        <t>See <xref target="RFC8569" format="default"/> for the formal definitions.</t>
        <t>ICN flow classifiers, such as those in <xref target="I-D.moiseenko-icnrg-flowclass" format="default"/> can be used to achieve soft or hard partitioning<sup>*</sup> partitioning (see note below) of cache resources in the content store CS of an ICN forwarder. For example, cached content for a given equivalence class can be considered <em>fate shared</em> in a cache whereby objects from the same equivalence class can be purged as a group rather than individually. This can recover cache space more quickly and at lower overhead than pure per-object replacement when a cache is under extreme pressure and in danger of thrashing. In addition, since the forwarder remembers the QoS treatment for each pending Interest in its PIT, the above cache controls can be augmented by policy to prefer retention of cached content for some equivalence classes as part of the cache replacement algorithm.</t>
        <aside><t><sup>*</sup>With
        <aside><t>Note: With hard partitioning, there are dedicated cache resources for each equivalence class (or enumerated list of equivalence classes). With soft partitioning, resources are at least partly shared among the (sets of) equivalence classes of traffic.</t></aside>
      </section>
    </section>
    <section anchor="principles" numbered="true" toc="default">
      <name>Strawman principles Principles for an ICN QoS architecture</name>
 <!-->   <name>A strawman set of principles to guide QoS architecture for ICN</name> --> Architecture</name>

      <t>Based on the observations made in the earlier sections, this summary section captures the author's ideas for clear and actionable architectural principles for how to incorporate incorporating QoS machinery into ICN protocols like NDN and CCNx. Hopefully, they can guide further work and focus effort on portions of the giant design space for QoS that have the best tradeoffs trade-offs in terms of flexibility, simplicity, and deployability.</t>
      <t><strong>Define equivalence classes using the name hierarchy rather than creating an independent traffic class definition</strong>. This directly associates the specification of equivalence classes of traffic with the structure of the application namespace. It can allow hierarchical decomposition of equivalence classes in a natural way because of the way hierarchical ICN names are constructed. Two practical mechanisms are presented in <xref target="I-D.moiseenko-icnrg-flowclass" format="default"/> with different tradeoffs trade-offs between security and the ability to aggregate flows. Either the prefix-based mechanism (the equivalence class component count (EC3) scheme) or the explicit name component-based mechanism (the equivalence class name component based (ECNT) type (ECNCT) scheme), or both both, could be adopted as the part of the QoS architecture for defining equivalence classes.</t>
      <t><strong> Put consumers in control of Link link and Forwarding forwarding resource allocation</strong>. Do Base all link buffering and forwarding (both memory and CPU) resource allocations based on Interest arrivals. This is attractive because it provides early congestion feedback to consumers, consumers and allows scheduling the reverse link direction ahead of time for carrying the matching data. data in advance. It makes enforcement of QoS treatments a single-ended (i.e. (i.e., at the consumer) rather than a double-ended problem and can avoid wasting resources on fetching data that will wind up be dropped when it arrives at a bottleneck link.</t>
      <t><strong>Allow producers to influence the allocation of cache resources</strong>. Producers want to affect caching decisions in order to: to do the following:
</t>
      <ul spacing="normal">
        <li>Shed load by having Interests served by content stores CSes in forwarders before reaching they reach the producer itself.</li> itself</li>
        <li>Survive transient producer reachability or link outages close to the producer.</li> producer</li>
      </ul>
      <t>
For caching to be effective, individual Data objects in an equivalence class need to have similar treatment; otherwise otherwise, well-known cache thrashing cache-thrashing pathologies due to self-interference emerge. Producers have the most direct control over caching policies through the caching directives in Data messages. It therefore makes sense to put the producer, rather than the consumer or network operator operator, in charge 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><strong>Allow consumers to influence the allocation of cache resources</strong>. Consumers want to affect caching decisions in order to: to do the following:
</t>
      <ul spacing="normal">
        <li>Reduce latency for retrieving data</li>
        <li>Survive transient outages of either a producer or links close to the consumer</li>
      </ul>
      <t>
Consumers can have indirect control over caching by specifying QoS treatments in their Interests. Consider the following potential QoS treatments by consumers that can drive caching policies:
</t>
      <ul spacing="normal">
        <li>A QoS treatment requesting better robustness against transient disconnection can be used by a forwarder close to the consumer (or downstream of an unreliable link) to preferentially cache the corresponding data.</li>
        <li>Conversely
        <li>Conversely, a QoS treatment together with, or in addition to to, a request for short latency, to indicate that new data will be requested soon enough latency indicating that caching the current data being requested would be ineffective and hence to forwarder should only pay attention to the caching preferences of the producer.</li> producer because caching requested data would be ineffective (i.e., new data will be requested shortly).</li>
        <li>A QoS treatment indicating that a mobile consumer will likely to incur a mobility event within an RTT (or a few RTTs). Such a treatment would allow a mobile network operator to preferentially cache the data at a forwarder positioned at a <em>join point</em> or <em>rendezvous point</em> of their topology</li> topology.</li>
      </ul>
      <t><strong>Give network operators the ability to match customer SLAs to cache resource availability</strong>. Network operators, whether closely tied administratively to producer or consumer, or constituting an independent transit administration, provide the storage resources in the ICN forwarders. Therefore, they 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 standpoint emerges from how the mapping of producer-specified equivalence classes map onto cache space availability, including whether cache entries are treated individually, individually or fate-shared. Forwarders also determine how the mapping of consumer-specified QoS treatments map to the precedence used for retaining Data objects in the cache.</t>
      <t>Besides utilizing cache resources to meet the QoS goals of individual producers and consumers, network operators also want to manage their cache resources in order to: to do the following:
</t>
      <ul spacing="normal">
        <li>Ameliorate congestion hotspots by reducing load converging on producers they host on their network.</li> network</li>
        <li>Improve Interest satisfaction rates by utilizing caches as short-term retransmission buffers to recover from transient producer reachability problems, link errors errors, or link outages.</li> outages</li>
        <li>Improve both latency and reliability in environments when consumers are mobile in the operator's topology.</li> topology</li>
      </ul>
      <t><strong>Re-think
      <t><strong>Rethink how to specify traffic treatments - -- don't just copy Diffserv</strong>. Some of the Diffserv classes may form a good starting point, as their mapping mappings onto queuing algorithms for managing link buffering are well understood. However, Diffserv alone does not allow one to express capture more complex QoS treatments, such as:</t>
      <ul spacing="normal">
        <li>Trading off latency versus reliability tradeoffs against reliability</li>
        <li>Trading off resource usage against delivery probability through controlled flooding or other useful QoS treatments. Nor does it permit "Traffic Specification (TSPEC)"-style forwarding mechanisms</li>
        <li>Allocating resources based on rich TSPEC-like traffic descriptions as are allowed that appear in a signaled QoS scheme. Here schemes like Intserv</li>
      </ul>
      <t>Here are some examples:
</t>
      <ul spacing="normal">
        <li>A "burst" treatment, where an initial Interest gives an aggregate data size to request allocation of link capacity for a large burst of Interest/Data exchanges. The Interest can be rejected at any hop if the resources are not available. Such a treatment can also accommodate Data implosion produced by the discovery procedures of management protocols like <xref target="I-D.irtf-icnrg-ccninfo" format="default"/>.</li>
        <li>A "reliable" treatment, which affects preference for allocation of PIT space for the Interest and Content Store CS space for the data Data in order to improve the robustness of IoT data delivery in a constrained environment, as is described in <xref target="I-D.gundogan-icnrg-iotqos" format="default"/>.</li>
        <li>A "search" treatment, which, within the specified Interest Lifetime, tries many paths either in parallel or serial serially to potentially many content sources, to maximize the probability that the requested item will be found. This is done at the expense of the extra bandwidth of both forwarding Interests and receiving multiple responses upstream of an aggregation point. The treatment can encode a value expressing tradeoffs trade-offs like breadth-first versus depth-first search, and bounds on the total resource expenditure. Such a treatment would be useful for instrumentation protocols like <xref target="I-D.irtf-icnrg-icntraceroute" format="default"/>.</li>
      </ul>
      <aside><t>As an aside, loose latency control (on the order of seconds or tens of milliseconds as opposed milliseconds or microseconds) can be achieved by bounding Interest Lifetime as long as this lifetime machinery is not also used as an application mechanism to provide subscriptions or to establish path traces for producer mobility. See <xref target="Krol2018" format="default"/> for a discussion 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 interaction styles)
-->

	<section anchor="Intserv" numbered="true" toc="default">
        <name>Can Intserv-like traffic control Intserv-Like Traffic Control in ICN provide richer Provide Richer QoS semantics?</name>
<!--    <name>What about the richer QoS semantics available with Intserv-like traffic control?</name> --> Semantics?</name>
        <t>Basic QoS treatments such as those summarized above may not be adequate to cover the whole range of application utility functions and deployment environments we expect for ICN. While it is true that one does not necessarily need a separate signaling protocol like RSVP given the state carried in the ICN data plane by forwarders, there are some potentially important capabilities not provided by just simple QoS treatments applied to per- per Interest/Data exchanges. exchanges lack some potentially important capabilities. Intserv'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> Intserv plus RSVP.</t>
        <t>There are three key capabilities missing from Diffserv-like QoS treatments, no matter how sophisticated they may be in describing the desired treatment for a given equivalence class of traffic. Intserv-like QoS provides all of these:
        </t>
        <ol spacing="normal" type="1">
          <li>The ability to <strong>describe traffic flows</strong> in a mathematically meaningful way. This is done through parameters like average rate, peak rate, and maximum burst size. The parameters are encapsulated in a data structure called a "TSPEC" "TSPEC", which can be placed in whatever protocol needs the information (in the case of TCP/IP Intserv, this is RSVP).</li>
          <li>The ability to perform <strong>admission control</strong>, where the element requesting the QoS treatment can know <em>before</em> introducing traffic whether the network elements have agreed to provide the requested traffic treatment. An important side-effect side effect of providing this assurance is that the network elements install state that allows the forwarding and queuing machinery to police and shape the traffic in a way that provides a sufficient degree of <em>isolation</em> from the dynamic behavior of other traffic. Depending on the admission control admission-control mechanism, it may or may not be possible to explicitly release that state when the application no longer needs the QoS treatment.</li>
          <li>The permissable ability to specify the permissible <strong>degree of divergence</strong> in the actual traffic handling from the requested handling. Intserv provided provides two choices here, here: the <em>controlled load</em> service and the <em>guaranteed</em> service. The former allows stochastic deviation equivalent to what one would experience on an unloaded path of a packet network. The latter conforms to the TSPEC deterministically, at the obvious expense of demanding extremely conservative resource allocation.</li>
        </ol>
        <t>Given the limited applicability of these capabilities in today's Internet, the author does not take any position as to whether any of these Intserv-like capabilities are needed for ICN to be succesful. successful. However, a few things seem important to consider. The following paragraphs speculate about the consequences to of incorporating these features into the CCNx or NDN protocol architectures of incorporating these features.</t> architectures.</t>
        <t>Superficially, it would be quite straightforward to accommodate Intserv-equivalent traffic descriptions in CCNx or NDN. One could define a new TLV for the Interest message to carry a TSPEC. A forwarder encountering this, together with a QoS treatment request (e.g. (e.g., as proposed in <xref target="qostreatments" format="default"/>) format="default"/>), could associate the traffic specification with the corresponding equivalence class derived from the name in the Interest. This would allow the forwarder to create state that not only would apply to the returning Data for that Interest when being queued on the downstream interface, interface but also be maintained as soft state across multiple Interest/Data exchanges to drive policing and shaping algorithms at per-flow granularity. The cost in Interest message overhead would be modest, however modest; however, the complications associated with managing different traffic specifications in different Interests for the same equivalence class might be substantial. Of course, all the scalability considerations with maintaining per-flow state also come into play.</t>
        <t>Similarly, it would be equally straightforward to have a way to express the degree of divergence capability that Intserv provides through its controlled 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 heavyweight as it turned out to be is with IP using RSVP. The dynamic multi-path, multipath, multi-destination forwarding model of ICN makes performing admission control particularly tricky. Just to illustrate:
        </t>
        <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>As with point-to-multipoint complexities when using RSVP for MPLS-TE, state has to be installed to multiple producers over multiple paths before an admission control admission-control algorithm can commit the resources and say "yes" to a consumer needing admission control capabilities</li> admission-control capabilities.</li>
          <li>Knowing when to remove admission control admission-control state is difficult in the absence of a heavy-weight heavyweight resource reservation protocol. Soft state timeout may or may not be an adequate answer.</li>
        </ul>

        <t>	Despite the challenges above, it may be possible to craft an admission control admission-control scheme for ICN that achieves the desired QoS goals of applications without the invention and deployment of a complex complex, separate admission control admission-control signaling protocol. There have been designs in earlier network architectures that were capable of performing admission control piggybacked on packet transmission.</t>

        <aside><t>(The

        <aside><t>The earliest example the author is aware of is <xref target="Autonet" format="default"/>).</t></aside> format="default"/>.</t></aside>

        <t>Such a scheme might have the following general shape <strong>(warning: (<strong>warning:</strong> serious hand waving follows!)</strong>: hand-waving follows!):
        </t>
        <ul spacing="normal">
          <li>In addition to a QoS treatment and a traffic specification, an Interest requesting admission for the corresponding equivalence class would so indicate this via a new TLV. It would also need to: to do the following: (a) indicate an expiration time after which any reserved resources can be released, and (b) indicate that caches be bypassed, so that the admission control admission-control request arrives at a bone-fide bona fide producer.</li>
          <!--  (or Repo) -->
          <li>Each forwarder processing the Interest would check for resource availability and if availability. If the resources are not available, or the requested service is not feasible, the forwarder would reject the Interest with an admission control admission-control failure. If resources are available, the forwarder would record the traffic specification as described above and forward the Interest.</li>
          <li>If the Interest successfully arrives at a producer, the producer returns would return the requested Data.</li>
          <li>Each on-path forwarder, on
          <li>Upon receiving the matching Data message, message and if the resources are still available, does the actual allocation, each on-path forwarder would allocate resources and marks would mark the admission control TLV as "provisionally approved". Conversely, if the resource reservation fails, the admission control is would be marked "failed", although the Data is would still be passed downstream.</li>
          <li>Upon the Data message arriving, arrival, the consumer knows would know if admission succeeded or not, and subsequent Interests can could rely on the QoS state being in place until either some failure occurs, or a topology or other forwarding change alters the forwarding path. To deal with this, additional machinery is needed to ensure subsequent Interests for an admitted flow either follow that path or an error is reported. One possibility (also useful in many other contexts), is to employ a <em>Path Steering</em> mechanism, such as the one described in <xref target="Moiseenko2017" format="default"/>.</li>
        </ul>
      </section>
    </section>
    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<!--<?rfc needLines="8" ?>-->
<!-- Possibly a 'Contributors' section ... -->

<section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document does not require any has no IANA actions.</t>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>There are a few ways in which QoS for ICN interacts with security and privacy issues. Since QoS addresses relationships among traffic rather than the inherent characteristics of traffic, it neither enhances nor degrades the security and privacy properties of the data being carried, as long as the machinery does not alter or otherwise compromise the basic security properties of the associated protocols. The QoS approaches advocated here for ICN can serve to amplify existing threats to network traffic however: traffic. However:
</t>
      <ul spacing="normal">
        <li>An attacker able to manipulate the QoS treatments of traffic can mount a more focused (and potentially more effective) denial of service denial-of-service attack by suppressing performance on traffic the attacker is targeting. Since the architecture here assumes QoS treatments are manipulable manipulatable hop-by-hop, any on-path adversary can wreak havoc. Note Note, however, that in basic ICN, an on-path attacker can do this and more by dropping, delaying, or mis-routing misrouting traffic independent of any particular QoS machinery in use.</li>
        <li>By explicitly revealing
        <li>When equivalence classes of traffic are explicitly revealed via either names or other fields in packets, an attacker has yet one more handle to use to discover linkability of multiple requests.</li>
      </ul>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

<back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     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 files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

<displayreference target="I-D.moiseenko-icnrg-flowclass" to="FLOWCLASS"/>
<displayreference target="I-D.muscariello-intarea-hicn" to="HICN"/>
<displayreference target="I-D.irtf-icnrg-ccninfo" to="CCNINFO"/>
<displayreference target="I-D.gundogan-icnrg-iotqos" to="IOTQOS"/>
<displayreference target="I-D.anilj-icnrg-dnc-qos-icn" to="DNC-QOS-ICN"/>
<displayreference target="I-D.oran-icnrg-flowbalance" to="FLOWBALANCE"/>
<displayreference target="I-D.irtf-nwcrg-nwc-ccn-reqs" to="NWC-CCN-REQS"/>
<displayreference target="I-D.irtf-icnrg-icntraceroute" to="ICNTRACEROUTE"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8569.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8609.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2205.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2998.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3170.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4594.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml"/>

<reference anchor="I-D.moiseenko-icnrg-flowclass" target="https://tools.ietf.org/html/draft-moiseenko-icnrg-flowclass-07">
   <front>
      <title>Flow Classification in Information Centric Networking</title>
      <author initials="I." surname="Moiseenko" fullname="Ilya Moiseenko">
         <organization>Apple Computer</organization>
      </author>
      <author initials="D." surname="Oran" fullname="David R. Oran">
         <organization>Network Systems Research and Design</organization>
      </author>
      <date month="January" day="13" year="2021"/>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-moiseenko-icnrg-flowclass-07"/>
</reference>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-moiseenko-icnrg-flowclass-06.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-quic-transport.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-muscariello-intarea-hicn-04.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-icnrg-ccninfo.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-irtf-icnrg-icntraceroute-01.xml"/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-gundogan-icnrg-iotqos-01.xml"/> href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.muscariello-intarea-hicn.xml"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.anilj-icnrg-dnc-qos-icn.xml"/> 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/html/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-Juraschek">
         <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/html/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://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-oran-icnrg-flowbalance-04.xml"/> href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.oran-icnrg-flowbalance.xml"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-irtf-nwcrg-nwc-ccn-reqs-04.xml"/> 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">
          <front>
            <title>MIRCC: Multipath-aware ICN Rate-based Congestion Control</title>
            <seriesInfo name="DOI" value="10.1145/2984356.2984365"/>
            <author surname="Mahdian" initials="M."/>
            <author surname="Arianfar" initials="S."/>
            <author surname="Gibson" initials="J."/>
            <author surname="Oran" initials="D."/>
            <date year="2016" month="September"/>
          </front>
          <refcontent>in ACM-ICN '16: Proceedings of the 3rd ACM Conference on Information-Centric Networking</refcontent>
          <seriesInfo name="DOI" value="10.1145/2984356.2984365"/>
        </reference>

        <reference anchor="Carofiglio2016" target="https://doi.org/10.1016/j.comnet.2016.09.012">
          <front>
            <title>Optimal multipath congestion control and request forwarding in information-centric networks: Protocol design and experimentation</title>
            <seriesInfo name="DOI" value="10.1145/2377677.2377772"/>
            <author surname="Carofiglio" initials="G."/>
            <author surname="Gallo" initials="M."/>
            <author surname="Muscariello" initials="L."/>
            <date year="2016" month="December"/>
          </front>
          <refcontent>in Computer Networks, Vol. 110 No. 9, December 2016</refcontent> 110</refcontent>
          <seriesInfo name="DOI" value="10.1016/j.comnet.2016.09.012"/>
        </reference>

        <reference anchor="Carofiglio2012" target="http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p37.pdf">
          <front>
            <title>Joint hop-by-hop Hop-by-hop and receiver-driven Receiver-Driven Interest control protocol Control Protocol for content-centric networks</title>
            <seriesInfo name="DOI" value="10.1016/j.comnet.2016.09.012"/> Content-Centric Networks</title>
            <author surname="Carofiglio" initials="G."/>
            <author surname="Gallo" initials="M."/>
            <author surname="Muscariello" initials="L."/>
            <date year="2012" month="September"/>
          </front>
          <refcontent>in ACM SIGCOMM Computer Communication Review, September 2012</refcontent> Review</refcontent>
          <seriesInfo name="DOI" value="10.1145/2377677.2377772"/>
        </reference>

        <reference anchor="Wang2013" target="http://conferences.sigcomm.org/sigcomm/2013/papers/icn/p55.pdf"> target="https://conferences.sigcomm.org/sigcomm/2013/papers/icn/p55.pdf">
          <front>
            <title>An Improved improved Hop-by-hop Interest Shaper for Congestion Control in Named Data Networking</title>
            <seriesInfo name="DOI" value="10.1145/2534169.2491233"/>
            <author surname="Wang" initials="Y."/>
            <author surname="Rozhnova" initials="N."/>
            <author surname="Narayanan" initials="A."/>
            <author surname="Oran" initials="D."/>
            <author surname="Rhee" initials="I."/>
            <date year="2013" month="August"/>
          </front>
          <refcontent>in ICN '13: Proceedings of the 3rd ACM SIGCOMM workshop on Information-centric networking, August 2013</refcontent> Computer Communication Review</refcontent>
          <seriesInfo name="DOI" value="10.1145/2534169.2491233"/>
        </reference>

        <reference anchor="Song2018" target="https://conferences.sigcomm.org/acm-icn/2018/proceedings/icn18-final62.pdf">
          <front>
            <title>SMIC: Subflow-level Multi-path Interest Control for Information Centric Networking</title>
            <seriesInfo name="DOI" value="10.1145/3267955.3267971"/>
            <author surname="Song" initials="J."/>
            <author surname="Lee" initials="M."/>
            <author surname="Kwon" initials="T."/>
            <date year="2018" month="September"/>
          </front>
          <refcontent>ICN '18: Proceedings of the 5th ACM Conference on Information-Centric Networking</refcontent>
          <seriesInfo name="DOI" value="10.1145/3267955.3267971"/>
        </reference>

        <reference anchor="Oran2018QoSslides" target="https://datatracker.ietf.org/meeting/interim-2018-icnrg-03/materials/slides-interim-2018-icnrg-03-sessa-thoughts-on-qos-for-ndnccn-style-icn-protocol-architectures">
          <front>
            <title>Thoughts on Quality of Service for NDN/CCN-style ICN protocol architectures</title>
            <author surname="Oran" initials="D." fullname="Dave Oran"/>
            <date year="2018" month="September" day="24"/>
          </front>
          <refcontent>presented at ICNRG Interim Meeting, Cambridge Cambridge, MA</refcontent>
        </reference>

        <reference anchor="NDNTutorials" target="https://named-data.net/publications/tutorials/">
          <front>
            <title>NDN Tutorials</title>
            <author surname="NDN team"/>
            <date>various</date>
          </front>
        </reference>

        <reference anchor="NDN" target="https://named-data.net/project/execsummary/">
          <front>
            <title>Named Data Networking</title> Networking: Executive Summary</title>
            <author surname="NDN team"/>
            <date>various</date>
          </front>
        </reference>

        <reference anchor="minmaxfairness" target="https://en.wikipedia.org/wiki/Max-min_fairness"> target="https://en.wikipedia.org/w/index.php?title=Max-min_fairness&amp;oldid=1028246910">
          <front>
            <title>Max-min Fairness</title>
            <author surname="Wikipedia"/>
            <date>no date</date> fairness</title>
            <author>
               <organization>Wikipedia</organization>
            </author>
            <date year="2021" month="June"/>
          </front>
        </reference>

        <reference anchor="proportionalfairness" target="https://en.wikipedia.org/wiki/Proportionally_fair"> target="https://en.wikipedia.org/w/index.php?title=Proportional-fair_scheduling&amp;oldid=1027073289">
          <front>
            <title>Proportionally Fair</title>
            <author surname="Wikipedia"/>
            <date>no date</date>
            <title>Proportional-fair scheduling</title>
            <author>
               <organization>Wikipedia</organization>
            </author>
            <date year="2021" month="June"/>
          </front>
        </reference>

        <reference anchor="AS" target="https://en.wikipedia.org/wiki/Autonomous_system_(Internet)"> target="https://en.wikipedia.org/w/index.php?title=Autonomous_system_(Internet)&amp;oldid=1025244754">
          <front>
            <title>Autonomous System system (Internet)</title>
            <author surname="Wikipedia"/>
            <date>no date</date>
            <author>
               <organization>Wikipedia</organization>
            </author>
            <date year="2021" month="May"/>
          </front>
        </reference>

        <reference anchor="Shenker2006" target="https://dl.acm.org/citation.cfm?id=2316898"> target="https://dl.acm.org/doi/10.1109/49.414637">
          <front>
            <title>Fundamental Design Issues design issues for the Future future Internet</title>
            <seriesInfo name="DOI" value="10.1109/49.414637"/>
            <author surname="Shenker" initials="S."/>
            <date year="2006" month="September"/>
          </front>
          <refcontent>in IEEE Journal on Selected Areas in Communications, Vol. 13, No. 7</refcontent>
          <seriesInfo name="DOI" value="10.1109/49.414637"/>
        </reference>

        <reference anchor="Wang2000" target="https://ieeexplore.ieee.org/document/819168?arnumber=819168"> target="https://ieeexplore.ieee.org/document/819168">
          <front>
            <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="Hou" initials="J.C."/> initials="J. C."/>
            <date year="2000" month="January"/>
          </front>
          <refcontent>in IEEE Network, Vol:14, Issue:1, Jan/Feb 2000</refcontent> Vol. 14, Issue 1</refcontent>
          <seriesInfo name="DOI" value="10.1109/65.819168"/>
        </reference>

        <reference anchor="Tseng2003" target="https://onlinelibrary.wiley.com/doi/abs/10.1002/net.10084">
          <front>
            <title>The performance of QoS-aware IP multicast routing protocols</title>
            <seriesInfo name="DOI" value="10.1002/net.10084"/>
            <author surname="Tseng" initials="CH.J."/> initials="C.-J."/>
            <author surname="Chen" initials="C.-H."/>
            <date year="2003" month="September"/>
          </front>
          <refcontent>in Networks, Vol:42, No:2</refcontent> Vol. 42</refcontent>
          <seriesInfo name="DOI" value="10.1002/net.10084"/>
        </reference>

        <reference anchor="Krol2018" target="https://conferences.sigcomm.org/acm-icn/2018/proceedings/icn18-final9.pdf">
          <front>
            <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" asciiSurname="Krol" asciiFullname="Michal Krol"/>
            <author surname="Habak" initials="K." fullname="Karim Habak"/>
            <author surname="Oran" initials="D." fullname="David Oran"/>
            <author surname="Kutscher" initials="D." fullname="Dirk Kutscher"/>
            <author surname="Psaras" initials="I." fullname="Ioannis Psaras"/>
            <date year="2018" month="September"/>
          </front>
          <refcontent>in ICN'18: ICN '18: Proceedings of the 5th ACM Conference on Information-Centric Networking September 21-23, 2018, Networking, Boston, MA, USA</refcontent>
          <seriesInfo name="DOI" value="10.1145/3267955.3267956"/>
        </reference>

        <reference anchor="BenAbraham2018" target="https://conferences.sigcomm.org/acm-icn/2018/proceedings/icn18-final31.pdf">
          <front>
            <title>"Decoupling
            <title>Decoupling Information and Connectivity via Information-Centric Transport</title>
            <seriesInfo name="DOI" value="10.1145/3267955.3267963"/>
            <author surname="Ben Abraham" initials="H."/>
            <author surname="Parwatikar" initials="J."/>
            <author surname="DeHart" initials="J."/>
            <author surname="Dresher" initials="A."/>
            <author surname="Crowley" initials="P."/>
            <date year="2018" month="September"/>
          </front>
          <refcontent>in ICN '18: Proceedings of the 5th ACM Conference on Information-Centric Networking September 21-23, 2018, Networking, Boston, MA, USA</refcontent>
          <seriesInfo name="DOI" value="10.1145/3267955.3267963"/>
        </reference>

        <reference anchor="Schneider2016" target="http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p21-schneider.pdf">
          <front>
            <title>"A
            <title>A Practical Congestion Control Scheme for Named Data Networking</title>
            <seriesInfo name="DOI" value="10.1145/2984356.2984369"/>
            <author surname="Schneider" initials="K."/>
            <author surname="Yi" initials="C."/>
            <author surname="Zhang" initials="B."/>
            <author surname="Zhang" initials="L."/>
            <date year="2016" month="September"/>
          </front>
          <refcontent>in ACM-ICN '16: Proceedings of the 3rd ACM Conference on Information-Centric Networking</refcontent>
          <seriesInfo name="DOI" value="10.1145/2984356.2984369"/>
        </reference>

        <reference anchor="Autonet" target="https://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-59.pdf">
          <front>
            <title>Autonet: a High-speed, Self-configuring Local Area Network Using Point-to-point Links</title>
            <seriesInfo name="DOI" value="10.1109/49.105178"/>
            <author surname="Schroeder" initials="M."/>
            <author surname="Birrell" initials="A."/>
            <author surname="Burrows" initials="M."/>
            <author surname="Murray" initials="H."/>
            <author surname="Needham" initials="R."/>
            <author surname="Rodeheffer" initials="T."/>
            <author surname="Satterthwaite" initials="E."/>
            <author surname="Thacker" initials="C."/>
            <date year="1991" month="October"/>
          </front>
          <refcontent>in IEEE Journal on Selected Areas in Communications ( Volume: Communications, Vol. 9, Issue: 8, Oct 1991)</refcontent> No. 8</refcontent>
          <seriesInfo name="DOI" value="10.1109/49.105178"/>
        </reference>

        <reference anchor="Moiseenko2017" target="https://conferences.sigcomm.org/acm-icn/2017/proceedings/icn17-2.pdf">
          <front>
            <title>Path Switching in Content Centric and Named Data Networks</title>
            <seriesInfo name="DOI" value="10.1145/3125719.3125721"/>
            <author surname="Moiseenko" initials="I."/>
            <author surname="Oran" initials="D."/>
            <date year="2017" month="September"/>
          </front>
          <refcontent>in ICN '17: Proceedings of the 4th ACM Conference on Information-Centric Networking</refcontent>
          <seriesInfo name="DOI" value="10.1145/3125719.3125721"/>
        </reference>

        <reference anchor='Auge2018' target='https://ieeexplore.ieee.org/document/8267132'>
	<front>
	<title>MAP-Me: Managing Anchor-Less Producer Mobility in Content-Centric Networks</title>
	<author surname='Augé' initials='J.' fullname='Jordan Augé' asciiFullname="Jordan Auge" asciiSurname="Auge"/>
	<author surname='Carofiglio' initials='G.' fullname='Giovanna Carofiglio'/>
	<author initials='G.' surname='Grassi'/>
	<author initials='L.' surname='Muscariello' fullname='Luca Muscariello'/>
	<author initials='G.' surname='Pau'/>
	<author initials='X.' surname='Zeng'/>
	<date month='June' year='2018'/>
	</front>
	<seriesInfo name='DOI' value='10.1109/TNSM.2018.2796720'/>
	<refcontent>in IEEE Transactions on Network and Service Management (Volume: 15 , Issue: 2 , June 2018)</refcontent> Management, Vol. 15, No. 2</refcontent>
	</reference>

      </references>
    </references>
    <!-- Change Log
v00 2019-07-13  DRO   Initial version
v06	2020-11-20	DRO	  Respond to IRSG Bollot comments from Spencer Dawkins & Mallory Knodel -->
  </back>
</rfc>