[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

ICNRG                                                   Anil Jangam, Ed.
Internet-Draft                                            Prakash Suthar
Intended status: Informational                              Milan Stolic
Expires: March 14, 2020                                    Cisco Systems
                                                      September 11, 2019


       QoS Treatments in ICN using Disaggregated Name Components
                    draft-anilj-icnrg-dnc-qos-icn-01

Abstract

   Mechanisms for specifying and implementing end-to-end Quality of
   service (QoS) treatments in Information-Centric Networks (ICN) has
   not been explored so far.  There has been some work towards
   implementing QoS in ICN; however, the discussions are mainly centered
   around strategies used in efficient forwarding of Interest packets.
   Moreover, as ICN has been tested mainly as an IP overlay, it's QoS is
   still governed by the IP QoS framework and there is a need for
   implementing QoS in ICN natively.  This document describes mechanisms
   to classify and provide associated "name-based" extensions to
   identify QoS within the framework of ICN's core design principles.
   The name-based design provides a mechanism to carry QoS information
   and implement the treatments as ICN packets travel across different
   routers in the ICN network.  Detailed discussion is provided for QoS
   specific procedures in each of the ICN network elements i.e.
   consumer, producer and forwarder.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 14, 2020.







Anil Jangam, et al.      Expires March 14, 2020                 [Page 1]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  Prior Work and Motivation . . . . . . . . . . . . . . . . . .   3
     3.1.  Prioritization of Interest Packets  . . . . . . . . . . .   3
     3.2.  Flow Classification in ICN  . . . . . . . . . . . . . . .   4
   4.  QoS Marker Encoding Choices . . . . . . . . . . . . . . . . .   5
   5.  Name based QoS Marking  . . . . . . . . . . . . . . . . . . .   6
     5.1.  QoS Marker in Content Name  . . . . . . . . . . . . . . .   6
     5.2.  Name-based QoS Marker Scheme  . . . . . . . . . . . . . .   7
   6.  Network Procedures  . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Consumer Procedure  . . . . . . . . . . . . . . . . . . .   9
     6.2.  Forwarder Procedure . . . . . . . . . . . . . . . . . . .   9
       6.2.1.  QoS and Multipath Forwarding  . . . . . . . . . . . .  11
     6.3.  Producer Procedure  . . . . . . . . . . . . . . . . . . .  11
   7.  QoS-Aware Forwarder Design  . . . . . . . . . . . . . . . . .  11
     7.1.  Enhanced PIT Design . . . . . . . . . . . . . . . . . . .  11
     7.2.  Multiple Interest and PIT Scaling . . . . . . . . . . . .  13
     7.3.  Handling PIT Scaling  . . . . . . . . . . . . . . . . . .  13
     7.4.  Data Delivery at PIT  . . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     12.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18







Anil Jangam, et al.      Expires March 14, 2020                 [Page 2]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


1.  Introduction

   Information Centric Networking (ICN) is rapidly emerging as an
   alternative networking mechanism for the TCP/IP based host-centric
   networking paradigm.  Use cases of video conferencing [MPVCICN] and
   real-time streaming [NDNRTC] signify the value of ICN architecture
   and have been studied in detail.  Also, a number of studies on
   routing of Interest and flow classification [ICNFLOW] have been
   published; however, relatively less work has been done on end-to-end
   quality of service (QoS) architecture for ICN.  QoS is important to
   deliver preferential service to a variety of traffic flows resulting
   into better user experience.  Evaluation and study of prior work done
   in this area is provided in Section 3.  The current QoS
   implementation is based on either Layer-3 TOS or DiffServ, which is
   applicable only for ICN as an overlay.  The QoS mechanisms described
   in this draft are applicable to the native ICN architecture.  A
   detailed discussion related to the design of name-based QoS encoding,
   which is in line with ICN's fundamental design principles.

2.  Conventions and Terminology

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

   This document uses the terminology of [CCNXSEMANTICS] and
   [CCNXMESSAGES] for CCNx entities.

3.  Prior Work and Motivation

3.1.  Prioritization of Interest Packets

   Among the work related to the quality of service (QoS) requirements
   in ICN network, larger emphasis is given to an optimized and
   efficient routing of Interest packets towards its content.

   M.F.  Al-Naday et.al. in [NADAY] argues that information awareness of
   ICN network would help build scalable QoS model.  In the context of
   CCN/NDN network design, authors points to the possibility of using
   the QoS aware name prefixes, with potentially limiting the third
   parties (e.g. network operators) from defining an alternative QoS
   enforcement mechanisms.  Moreover, the QoS solution is developed
   around the PURSUIT architecture, which may not be applicable to CCN/
   NDN.

   Weibo Chu et.al. in [WEIBO] present a QoS model for ICN network based
   on the popularity ranking of the content and its placement/location
   in the network.  They present a classification of the content into



Anil Jangam, et al.      Expires March 14, 2020                 [Page 3]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


   three categories - locally cached, remotely cached, and uncached
   contents, hence the network delay is modeled as a function of the
   distance of the content from the requester.  Essentially, the QoS
   problem is seen in the perspective of faster routing of Interest
   request towards its content.

   In [XINGWEI] authors present a QoS mechanism, which is applicable to
   the routing of Interest requests in ICN network.  The basis of the
   proposal is to decide the suitability of the forwarding link to make
   the process more energy efficient.  They use the same Data forwarding
   algorithm specified in the original NDN design [JACOBSON].

   In [CHRISTOS] Christos et.al. argue about a need for a differentiated
   routing and forwarding mechanisms based on not only the name of the
   content but also specifying the nature of the traffic.  They further
   emphasize that this differentiation is better handled at the network
   level rather than leaving it for the upper layer.

   In all above use cases, the QoS related discussions are mainly
   focused on the forwarding of the Interest requests.  It assumes that
   Data packets are forwarded in downstream direction according to the
   pending Interest table (PIT).  There is little or no discussions
   provided about how preferential treatment can be implemented and
   enforced in the Data packet path.

3.2.  Flow Classification in ICN

   Flow classification [ICNFLOW] describe the methods for classification
   of data flows in ICN.  The method called equivalence class component
   count (EC3), uses a predefined number of name components of the
   content name forming an equivalence class.  While approach has the
   flexibility in re-grouping of components in aggregating the flows, it
   suffers from an inconsistent interpretation due to implicit binding
   of the equivalence class into the content namespace.  In the second
   method called equivalence class name component type (ECNCT), the flow
   classification information is directly embedded in the hierarchical
   content name.  This paves the way to achieve implicit aggregation of
   data flows analogous to the prefix-based aggregation of content names
   in FIB table.  At the forwarder level, a flow table is implemented to
   store the equivalence classes and is used to perform the flow
   classification decisions.

   While both the schemes provide data flow classification in ICN, they
   are not sufficient for implementing a preferential service treatment
   in the network.  Table 1 provide a summary of important differences
   between the flow classification and QoS treament implementation.





Anil Jangam, et al.      Expires March 14, 2020                 [Page 4]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


   +---+-------------------------------+-------------------------------+
   | # | Flow Classifier               | QoS Marker                    |
   +---+-------------------------------+-------------------------------+
   | 1 | Identify the type of data     | Identify the QoS treatment    |
   |   | flow                          |                               |
   | 2 | Set by the producer           | Set by the consumer           |
   | 3 | Immutable for the lifetime of | Can be modified in the        |
   |   | Interest                      | network                       |
   | 4 | Part of the routable content  | Non-routable part of the      |
   |   | name                          | content name                  |
   +---+-------------------------------+-------------------------------+

           Table 1: Difference between Flow Class and QoS Marker

   By design, the data flow classification described in ECNCT is set by
   the producer at the time of registration of the content name and
   hence it is immutable for the life time of the content.  Also, flow
   classification is encoded as part of routable name and therefore it
   has direct effect on both, PIT and FIB matching.  Since flow
   classification mechanisms are initiated or triggered at the producer,
   they lack to convey consumer's or application's context in deciding
   the traffic treatment in the network for individual data flows.

4.  QoS Marker Encoding Choices

   In ICN protocols like CCNx, the ability to mutate the protocol
   metadata is directly controlled by whether it is placed inside the
   security envelop or outside.  Likewise, for the encoding of the
   protocol metadata, such as QoS marker, two design choices are
   possible.

   o  In first choice, encoding of QoS marker inside content name (in
      both Interest and content object) makes it immutable as it is
      inside an authentication signature and routers along a path cannot
      change it.

   o  In the second choice, we define a mandatory hop-by-hop header to
      be able to change the QoS marker over time.

   While QoS mutability can be a useful feature, it can potentially
   suffer from an inconsistent end-to-end QoS treatment handling as each
   router can potentially change the QoS marking based on per hop
   traffic conditions.  On the other hand, the optional content name
   field in the content object makes it a nameless object.  As an
   example, the nameless content objects are used inside a Manifest.
   So, one could put a QoS marking in an Interest name (to be used
   inside manifest), but it would not be used in the content object.  It




Anil Jangam, et al.      Expires March 14, 2020                 [Page 5]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


   is for further study to find an encoding scheme to put QoS marker in
   content name of a nameless content object.

   From routing and forwarding perspective, all name components are
   routable, in the sense that if they are in a FIB they will be
   matched.  In case of name-based QoS marking, we can assume that
   router publishes only the name prefixes, exclusive of QoS markers.
   That said, globally routable FIBs would likely only have general name
   components.

   In summary, we have following options to design the QoS marking
   scheme based on.

   o  Define a mandatory hop-by-hop header to be able to change the QoS
      over time i.e. hop-by-hop.

   o  Encode QoS marker as a distinguished field inside a content
      object, but not part of the content name.

   o  Find a way to make it work with nameless objects to be able to put
      it inside a name.

   In rest of the document, we discuss the design name-based encoding of
   QoS marker.

5.  Name based QoS Marking

   Producer decides the classification of the data flow packets;
   however, it is consumer's prerogative what QoS treatment is actually
   provided to them by the network.  Consumer application itself or the
   network on behalf of consumer, can perform the QoS marking in the
   Interest messages.  Following factors govern the type of QoS markers
   we may require.

   o  Consumer's subscription: The type of service user subscribes with
      the service provider e.g. subscription with high-speed data plan
      vs. low-speed data plan.

   o  Service type: The type of service or the application consumer is
      running.  As a reference, we may refer to service classes as
      described in [RFC4594] (see section 2.0).

5.1.  QoS Marker in Content Name

   Supporting the ICN design principles, the QoS marking is encoded in
   the content name field.  Prior to their consumption, as both content
   and the content name are published by the content producer, it is
   important to make distinction between the content name and the QoS



Anil Jangam, et al.      Expires March 14, 2020                 [Page 6]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


   marker.  As shown in Figure 1, there is a logical separation between
   the content name and the QoS marker.  To support the consumer driven
   ICN design, QoS marker is encoded as non-routable part of the content
   name and hence is editable.  To support the content matching
   algorithm at PIT and prefix matching algorithm at FIB, QoS marker is
   added at the end of the content name.

   +------------+------------+------------+-------------+-------------+
   |   Content  |   Content  |   Content  |     QoS     |     QoS     |
   | Name comp-1| Name comp-2| Name comp-3| Name comp-1 | Name comp-2 |
   |            |            |            |             |             |
   +------------+------------+------------+-------------+-------------+
   |<---------Routable name comp--------->|<--Non-routable name comp->|


          Figure 1: Disaggregate Content and QoS Name Components

   The non-routable name component design of QoS marker allows consumer
   to add the QoS marking to the Interest message.  The reasoning behind
   making it non-routable is that it does not affect the forwarder's
   name or prefix matching process directly; however, it can influence
   FIB's selection of forwarding faces the Interest packet is forwarded
   to.  This allows for an implementation of QoS-aware forwarding
   strategy for both Interest and Data packets.

   Finally, the idea of routable vs non-routable is that in general we
   believe that as QoS marker is the consumer-initiated activity and
   content producer (a.k.a. publisher) would publish and the routing
   protocol would advertise only the general name segments (i.e.
   content-name without any QoS marker in it) and thus be updated in a
   FIB entry.

5.2.  Name-based QoS Marker Scheme

   Figure 1 shows a reference model for name component-based QoS marker
   scheme.  The number of QoS name components required shall depend on
   the type of QoS encoding uses as well as the total number of markers
   required.  QoS marker design can either be hierarchical or based on a
   flat naming scheme.  The exact requirements and design specification
   of QoS marker is subject of further study.

   While exact specification of QoS marking are being studied, following
   are the potential mechanisms that can used for encoding of QoS
   marking into content name:

   o  Using the path parameters addition to HTTP URI [RFC3986] (see
      section 3.3).  We provide a summary of path parameter below from
      [RFC3986].



Anil Jangam, et al.      Expires March 14, 2020                 [Page 7]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


      The path component contains data organized in hierarchical form
      serves to identify a resource within the scope of the URI's scheme
      and its naming authority.  A path consists of a sequence of path
      segments separated by a slash ("/") character, which indicate
      hierarchy.  A path parameter, part of a path segment that occurs
      after its name, control the representations of resource.  A
      reserved characters often allowed in a path segment to delimit
      scheme-specific or dereference-handler-specific subcomponents.
      For example, the semicolon (";") and equals ("=") reserved
      characters are often used to delimit parameters and parameter
      values applicable to that segment.

      The semicolon ';' delimits the parameters i.e. anything in a path
      segment that comes after a ';' is treated as a new parameter.  The
      '=' separate parameter names from their values i.e. anything that
      is specified after '=' sign is treated as parameter value.  A
      parameter may have multiple values separated by a ',' symbol.  Few
      examples of path parameter are shown below.

      *  /content/name;param=val1 - Content name with single path param
         with single value

      *  /content/name;param1=val1;param2=val1 - Content name with two
         path params

      *  /content/name;param1=val1,val2 - Content name with single path
         param with two value

   o  Using the 'application payload name segments' approach defined in
      CCNX [CCNXMESSAGES] (see section-3.6.1.1).

   The exact form and structure of QoS marking are being developed and
   more details shall be provided in next revision.

6.  Network Procedures

   An important takeaway of implementing QoS is effective management of
   network resources such as, link capacity, bandwidth, and memory.  ICN
   follows a pull-based or a receiver driven design, which directly
   influences the load on to the network.  Network based policy
   configuration decides how the Interest and Data traffic is carried
   optimally, and producers, depending on where the content is, responds
   to the requests from the consumers.  With introduction of QoS marking
   in the Interest packet, important changes in the behavior of each of
   these network elements are discussed.






Anil Jangam, et al.      Expires March 14, 2020                 [Page 8]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


6.1.  Consumer Procedure

   Consumer sends out the Interest packet into the network adding the
   QoS marker as per its service subscription and/or quality
   requirements.  Consumer does QoS marking and adds it as non-routable
   name component, as shown in Figure 1.

   Consumer, the initiator of the Interest is the most appropriate
   network entity to perform the QoS marking for the following reasons:

   o  ICN fundamentally is a pull-based, consumer driven design and
      consumer directly influences the resource allocation in the
      network in terms of timing and rate of Interest traffic.

   o  Consumer is aware of the context of the application initiating the
      Interest.  For instance, an application starting a simple video
      download compared to initiating a video conferencing.

   o  Consumer at least partially in control of the traffic paths in
      both directions [MIRCC].

   As an alternative to consumer adding the QoS marker in the Interest,
   the network (i.e. forwarder) can be allowed to amend the content name
   with the QoS marker.  It should be possible since QoS marker is
   encoded as a non-routable component of the content name.  The network
   shall add the QoS marker based on the information such as, user's
   service or subscription authorization.  In this context, an immediate
   forwarder (a.k.a. default gateway) would be the appropriate network
   node to perform this marking.

   Following aspects need more discussion:

   o  Should network be allowed to add QoS marker in non-routable
      component of content name or should it add as a separate field of
      the Interest packets.

   o  Once QoS marker is added and Interest is admitted into the network
      should network be allowed to modify the QoS marker.

   o  Since QoS markings are explicit, should the QoS marker be aware of
      consumer's subscription and make the relationship between the two
      explicit.

6.2.  Forwarder Procedure

   ICN forwarder, in addition to preserving the Interest state into PIT
   table (mapping between content name and the interface it receives the
   Interest on), now also preserves the state of QoS marker against the



Anil Jangam, et al.      Expires March 14, 2020                 [Page 9]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


   interface.  In a representative domain, the PIT structure is enhanced
   by adding a new column to save the state of QoS marker.  This forms a
   3-tuple information set comprising content name, interface, and QoS
   marker.  Unlike PIT, there is no change in the structure of FIB
   table; however, forwarder forwards to the upstream ICN router both
   content name and QoS marker, as they are received from its
   predecessor.

   With enhanced QoS-aware content name design, forwarder performs the
   content store (CS) lookup only using routable name component.  It is
   possible that a forwarder implementation may choose to understand
   name components types and do special things based on it.  Conversely,
   the PIT aggregation logic uses both content name and QoS marker in
   PIT lookup, which makes it a QoS-aware Interest aggregation.
   Section 7.1 provide more details about new PIT design and related
   procedures.

   While there are no changes in the FIB table, the conventional name
   prefix based multipath forwarding path selection of forwarder can use
   the QoS marker to make the QoS-aware forwarding decision.  For
   example, QoS marking can be used to select a low latency interface
   over a high latency interface or it can be used to select a high
   bandwidth path over a low bandwidth path or vice versa.

   The following aspects of QoS-aware forwarder design need more
   attention:

   o  How mapping is done between QoS marking and the forwarding queue
      after the forwarding interface is selected.

   o  From the perspective of per-hop-behavior (PHB), it is important to
      understand if remarking of QoS is allowed and if one marker is
      sufficient for it.  One possibility is to preserve the original
      QoS marker added by consumer and have a running marker set by the
      intermediate forwarder in the network.

   o  In the context of QoS remarking by the network, it may also become
      important to let consumer know, what network is doing with their
      QoS marking.  From the network behavior perspective, following are
      the possibilities:

      *  QoS marking is preserved and obeyed in subsequent hop

      *  QoS marking is preserved but not obeyed

      *  QoS marking is remarked and obeyed





Anil Jangam, et al.      Expires March 14, 2020                [Page 10]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


6.2.1.  QoS and Multipath Forwarding

   QoS marking in the Interest packet does not change the multipath
   forwarding capability of ICN forwarders.  In Section 7.2, more
   details are provided about specific QoS behavior related to multipath
   forwarding.

6.3.  Producer Procedure

   Producer is aware of the disaggregation between routable name and the
   non-routable QoS marker.  It looks up the content in content store
   (CS) only using routable name component.  An intermediate router acts
   in a similar manner.

   Depending on the what kind of QoS marking is done in the Interest
   packet, producer can have following response behaviors:

   o  Producer may respond in a different manner with the Data packet to
      the consumer.

   o  One such aspect of QoS aware response could be to provide the
      consumer information about how much distance (e.g. number of hops)
      Interest has travelled into the network before it is satisfied.

   o  QoS-aware response does not change the original requested content.

7.  QoS-Aware Forwarder Design

   Towards supporting end-to-end QoS and handling of Interest and Data
   traffic throughout the network, important network procedures are
   discussed in Section 6.  There are some important design changes in
   the way PIT maintains the pending Interests and the way forwarding
   decisions are made.  This section discuss in detail each of the
   changes.

7.1.  Enhanced PIT Design

   The new PIT design has added a new column to maintain the QoS marker
   received in the Interest packet.  The enhancement in the PIT table
   and its behavior are applicable only specific to its Interest
   aggregation feature of multiple Interest packet received for the same
   content.









Anil Jangam, et al.      Expires March 14, 2020                [Page 11]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


        +----+----------------+--------------------+--------------+
        |    |                |                    |              |
        | #  | Interface Id   | Content Name       | QoS Marker   |
        +---------------------------------------------------------+
        | 1  | face-1         | /youtube/med/vid-1 | /qos-level-1 |
        +---------------------------------------------------------+
        | 2  | face-2         | /youtube/med/vid-1 | /qos-level-2 |
        +---------------------------------------------------------+
        | 3  | face-1         | /youtube/med/vid-1 | /qos-level-3 |
        +----+----------------+--------------------+--------------+


               Figure 2: Enhanced PIT Design with QoS Marker

   The scenarios emerging from the new QoS marking and new PIT design
   are discussed here.  Three PIT entries are shown in Figure 2 to
   explain the new PIT design and its behavior.  Notice that in the
   modified PIT design, content name always takes the higher precedence
   over the QoS marker in deciding the Interest aggregation.  Having
   said this, following scenarios of Interest arrival at forwarder are
   possible:

   a.  Two or more Interests with different content name, but with
       different QoS markers are received on two different interfaces.

   b.  Two or more Interests with different content name, but with same
       QoS markers are received on two different interfaces.

   c.  Two or more Interests with same content name and with same QoS
       markers are received on two different interfaces.

   d.  Two or more Interests with same content name, but with different
       QoS markers are received on two different interfaces.

   e.  Two or more Interests with same content name, but with different
       QoS markers are received on the same interface.

   Scenarios (a) and (b), since both Interests are received with
   different content name, no PIT aggregation is required and Interest
   are forwarded if content is not found in CS.  In case (c), since both
   content name and QoS marker are same, Interest is aggregated in PIT
   and second Interest is not forwarded.

   In scenarios (d) and (e), since Interests are received with same
   content name, the PIT aggregation decision is made based on the QoS
   marker.  These two scenarios lead to a potential PIT scaling issue,
   which is discussed in Section 7.2.




Anil Jangam, et al.      Expires March 14, 2020                [Page 12]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


7.2.  Multiple Interest and PIT Scaling

   With two scenarios (d) and (e) in Section 7.1 forwarder forwards both
   the Interests to upstream router creating two PIT entries as shown in
   Figure 2 i.e. entries #1 and #3.  This behavior violates the
   conventional PIT behavior; however, is essential to support the
   different QoS treatment.

   In order to support QoS-aware forwarding, the conventional PIT
   aggregation needs to be loosened up proportional to the number of QoS
   markers; in other words, the QoS treatments.  Without this, upstream
   forwarder would not get an opportunity to obey each of the QoS
   treatments.  The theoretical upper bound on the PIT scaling for given
   content will be equal to number of QoS markers.

   The impact on the PIT scaling depends on and can be mitigated by the
   following mechanisms:

   o  By keeping the number of QoS markers limited

   o  By keeping the QoS marker unique and avoiding the hierarchy or
      order among them.

   o  In real-time case, the PIT may not hit the upper bound all the
      times i.e. not all QoS markers are utilized all the times on the
      same content name.

   o  Using an optimization in multiple Interest handling, as discussed
      in Section 7.3

7.3.  Handling PIT Scaling

   The PIT scaling issue described in Section 7.2 can be handled with an
   optimization discussed here.

   The forwarder can avoid forwarding the second/duplicate Interest if
   it receives it with a lower QoS marking than the one already pending
   in PIT.  Thus, achieving the Interest aggregation based on the higher
   QoS marker for given content name.  Conversely if the received
   Interest is with a higher QoS marking, then forwarder forwards the
   Interest and updates the pending PIT entry with higher QoS marking.
   Also, note that forwarder updates the PIT entry irrespective of the
   interface the higher QoS marked Interest is received on.

   Notice that forwarding of Interest with higher QoS marker in spite of
   having an already pending with a lower QoS marker, is a breach of
   Interest aggregation at PIT in conventional terms; however, it is
   necessary to give an opportunity for upstream routers to provide



Anil Jangam, et al.      Expires March 14, 2020                [Page 13]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


   appropriate QoS treatment to the higher priority Interest and the
   resulting Data traffic flow.

   These are the scenarios, which provide for a QoS-aware PIT design,
   Interest aggregation and forwarding in ICN router.

7.4.  Data Delivery at PIT

   With QoS-aware Interest aggregation at PIT, more than one Interest
   are flowing in the network for the same content.  With a higher
   probability of a priority treatment to the higher QoS marked Interest
   at each hop and with the possibility of multipath forwarding, it is
   highly likely that the Interest with higher QoS marking shall be
   satisfied faster than the Interest with lower QoS marking.

   The Data packet arrival may satisfy all the PIT entries for the given
   content name irrespective of the QoS markers in Data packet.  This is
   possible mainly because the content itself in Data packet does not
   change by different QoS marker in the Interest.  Depending on whether
   forwarder implements a PIT scaling optimization, two scenarios of
   Data forwarding are possible:

   o  Data packet to the downstream interface is forwarded with its
      original QoS marking recorded by the PIT.

   o  Data packet to the downstream interface is forwarded with the
      higher QoS marking recorded by the PIT by virtue of PIT
      optimization.

   With the PIT optimization described in Section 7.3, it is possible to
   satisfy a pending Interest with lower QoS marking with arrival of a
   Data packet having higher QoS marker.  As a result, a user with lower
   QoS subscription may experience a better response time from the
   network.  Note that this is a legitimate behavior, as ICN is
   fundamentally designed to optimize the network round-trip time
   providing better user experience.

8.  Security Considerations

   ICN being name-based networking opens up new security and privacy
   considerations which have to be studied in the context of name-based
   QoS framework.

   Depending on where the QoS marker is encoded in the Interest, certain
   security attack scenarios against QoS treatment are possible.  If the
   QoS marker located inside the security envelope, it can be read, but
   not changed.  Conversely, if the QoS marker is placed outside of the
   security envelope, it can be added as hop-by-hop message header and,



Anil Jangam, et al.      Expires March 14, 2020                [Page 14]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


   therefore, can be modified by the transit ICN forwarders; however, it
   also opens it to various attack scenarios.

   Consumer procedure discussed in Section 6.1 and forwarder procedure
   discussed in Section 6.2 shall decide the security requirements
   related to implementing QoS treatments in ICN.

9.  Summary

   This draft provides an architecture to implement end-to-end QoS
   treatments in ICN network using a name-based disaggregation of
   routable content name and non-routable, mutable QoS markers.  The
   independence between content name and QoS marking makes their
   evolution easier and yet bounded to content name keeping with ICN
   principles.

   A new PIT design and a potential impact on PIT scaling is presented.
   An optimization to deal with the PIT scaling problem is discussed
   where a number of pending Interests requests in PIT for same content
   to be normalized around the highest QoS marking.

   Security requirements are dependent on whether QoS marker is encoded
   inside security envelop or outside of it.  Consumer and forwarder
   procedure requirements shall also govern the security features.

   A detailed analysis and evaluation shall be performed, through
   prototype using [VICN] and/or simulation [NDNSIM], of the impact on
   PIT aggregation and effect of optimization.  The details on design of
   a naming scheme for QoS marking in content name needs to be worked
   on.  It is also necessary to test and measure the effectiveness of
   the QoS framework by deploying it using a multimedia streaming
   application.

10.  Acknowledgements

   We thank all contributors, reviewers and the chairs for their
   valuable time in providing the comments and feedback, which has
   helped to improve this draft.  We would like to thank Mark Mosco who
   provided a useful feedback on proposed name-based encoding scheme and
   nameless content objects.

11.  IANA Considerations

   This draft includes no request to IANA.







Anil Jangam, et al.      Expires March 14, 2020                [Page 15]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


12.  References

12.1.  Normative References

   [CCNXMESSAGES]
              "Marc Mosko et.al., CCNx Messages in TLV Format, ICNRG
              Internet-Draft 2019", <https://tools.ietf.org/html/
              draft-irtf-icnrg-ccnxmessages-09#section-3.6.1.1>.

   [CCNXSEMANTICS]
              "Marc Mosko et.al., CCNx Semantics, ICNRG Internet-Draft
              2018", <https://datatracker.ietf.org/doc/
              draft-irtf-icnrg-ccnxsemantics/>.

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

12.2.  Informative References

   [CHRISTOS]
              "Christos Tsilopoulos et.al., Supporting Diverse Traffic
              Types in Information Centric Networks, Proceedings of the
              ACM SIGCOMM Workshop on Information-centric Networking,
              Pages 13-19, ICN 2011",
              <https://dl.acm.org/citation.cfm?id=2018588>.

   [ICNFLOW]  "Moiseenko et.al., Flow Classification in Information
              Centric Networking, ICNRG Internet-Draft, February 2017,
              https://datatracker.ietf.org/doc/
              draft-moiseenko-icnrg-flowclass/".

   [JACOBSON]
              Jacobson, Van et.al, "Networking Named Content, 5th
              International Conference on Emerging Networking
              Experiments and Technologies, CoNEXT '09, pp. 1-12, 2009".

   [MIRCC]    "Milad Mahdian et.al., MIRCC: Multipath-aware ICN Rate-
              based Congestion Control, Proceedings of the 3rd ACM
              Conference on Information-Centric Networking Pages 1-10,
              ICN 2016", <https://dl.acm.org/citation.cfm?id=2984365>.









Anil Jangam, et al.      Expires March 14, 2020                [Page 16]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


   [MPVCICN]  Jangam, A., Ravindran, R., Chakraborti, A., Wan, X., and
              G. Wang, "Realtime multi-party video conferencing service
              over information centric network", IEEE International
              Conference on Multimedia and Expo Workshops (ICMEW) Turin,
              Italy, pp. 1-6, June 2015,
              <https://ieeexplore.ieee.org/document/7169810>.

   [NADAY]    "M. F. Al-Naday et.al., Quality of service in an
              information-centric network, 2014 IEEE Global
              Communications Conference GLOCOM.2014, pp. 1861-1866, Dec
              2014".

   [NDNRTC]   Gusev, P., Wang, Z., Burke, J., Zhang, L., Yoneda, T.,
              Ohnishi, R., and E. Muramoto, "Real-time Streaming Data
              Delivery over Named Data Networking,", IEICE Transactions
              on Communications vol. E99.B, pp. 974-991, May 2016,
              <https://doi.org/10.1587/transcom.2015AMI0002>.

   [NDNSIM]   "ndnSIM: NS-3 based Named Data Networking (NDN)
              simulator", <http://ndnsim.net/2.2/>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", January 2005,
              <https://tools.ietf.org/html/rfc3986#section-3.3>.

   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", August 2006,
              <https://tools.ietf.org/html/rfc4594#section-2>.

   [VICN]     "Mauro Sardara et.al., Virtualized ICN (vICN): towards a
              unified network virtualization framework for ICN
              experimentation, ICN'17 Proceedings of the 4th ACM
              Conference on Information-Centric Networking Pages
              109-115", <https://wiki.fd.io/view/Vicn>.

   [WEIBO]    "Weibo Chu et.al., Network delay guarantee for
              differentiated services in content-centric networking,
              Journal of Computer Communications Volume 76, Pages 54-66,
              February 2016".

   [XINGWEI]  "Xingwei Wang et.al., Energy-efficient ICN routing
              mechanism with QoS support, Journal of Computer
              Communications Volume 131, Pages 38-51, 2018".








Anil Jangam, et al.      Expires March 14, 2020                [Page 17]


Internet-Draft      Name-based QoS Treatments in ICN      September 2019


Authors' Addresses

   Anil Jangam (editor)
   Cisco Systems
   San Jose, California  95134
   USA

   Email: anjangam@cisco.com


   Prakash Suthar
   Cisco Systems
   Rosemont, Illinois  56018
   USA

   Email: psuthar@cisco.com


   Milan Stolic
   Cisco Systems
   Rosemont, Illinois  56018
   USA

   Email: mistolic@cisco.com



























Anil Jangam, et al.      Expires March 14, 2020                [Page 18]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/