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

Versions: 00 01 02

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


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

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, its 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 September 10, 2020.







Anil Jangam, et al.    Expires September 10, 2020               [Page 1]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


Copyright Notice

   Copyright (c) 2020 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
   4.  A Perspective on QoS in ICN . . . . . . . . . . . . . . . . .   4
     4.1.  Network Resources and QoS Treatments in ICN . . . . . . .   5
     4.2.  Mutation of QoS Marker  . . . . . . . . . . . . . . . . .   6
     4.3.  Nameless Object . . . . . . . . . . . . . . . . . . . . .   7
     4.4.  QoS Marker Inside Content Name  . . . . . . . . . . . . .   7
       4.4.1.  Name-based QoS Encoding Scheme  . . . . . . . . . . .   8
     4.5.  QoS Marker Inside Hop-by-Hop Header . . . . . . . . . . .   8
       4.5.1.  Modified Interest Message . . . . . . . . . . . . . .   9
   5.  Network Procedures  . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Consumer Procedure  . . . . . . . . . . . . . . . . . . .  10
     5.2.  Forwarder Procedure . . . . . . . . . . . . . . . . . . .  11
       5.2.1.  QoS and Multipath Forwarding  . . . . . . . . . . . .  12
     5.3.  Producer Procedure  . . . . . . . . . . . . . . . . . . .  12
   6.  QoS-Aware Forwarder Design  . . . . . . . . . . . . . . . . .  12
     6.1.  Maintaining QoS State in PIT  . . . . . . . . . . . . . .  12
     6.2.  QoS-Aware Interest Aggregation in PIT . . . . . . . . . .  14
     6.3.  Handling of QoS and PIT Aggregation . . . . . . . . . . .  14
     6.4.  Data Delivery at PIT  . . . . . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   8.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     11.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19





Anil Jangam, et al.    Expires September 10, 2020               [Page 2]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


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 has 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 in
   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 is provided in
   Section 4.4.

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

   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, the authors point to the possibility of using
   the QoS aware name prefixes, potentially limiting the third parties
   (e.g. network operators) from defining 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
   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



Anil Jangam, et al.    Expires September 10, 2020               [Page 3]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


   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 the above use cases, the QoS related discussions are mainly
   focused on the forwarding of the Interest requests.  The Data packets
   are forwarded in the 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.

   In [YAOGONG], authors present a scheme for hop-by-hop Interest shaper
   algorithm and demonstrates how by shaping of Interest results the
   returning Data packets are controlled and shaped.  In this algorithm,
   when coupled with the consumer-driven QoS treatment of Interest,
   automatically achieves preferential treatment of returning Data.

4.  A Perspective on QoS in ICN

   In general, QoS marking is used to fine-tune (set and change) certain
   attributes for the traffic belonging to a specific class.  The
   marking helps segregate the traffic that requires special treatment,
   thus helps achieve optimal network performance.  The in-network
   treatment is determined based on how these attributes are set.  Some
   of the possible network treatments are:

   o  Set the precedence of the traffic entering a network e.g.
      selecting specific queue for the real-time (voice and/or video)
      traffic.

   o  Identify traffic for any class-based QoS feature implementation.

   o  Marking of the QoS for packets traversing the network layer
      boundary (e.g. from L3 to L2 and vice versa) as well as the
      Autonomous System (AS) boundaries of different service providers.





Anil Jangam, et al.    Expires September 10, 2020               [Page 4]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


   From the ICN perspective, while the producer decides the
   classification of the data flow packets, 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 the consumer
   can perform the QoS marking in the Interest messages.  The 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.  We may refer to service classes as described in
      [RFC4594] (see section 2.0).

4.1.  Network Resources and QoS Treatments in ICN

   An effective QoS management is achieved through managed unfairness in
   the allocation of resources including the resources on individual
   network elements (e.g. router) and the network links connecting them.
   In [QOSARCH], author lists the resources on a ICN network element.

   +-------------------------+-----------------------------------------+
   | Resource Type           | Use in ICN                              |
   +-------------------------+-----------------------------------------+
   | Link Capacity           | Packet priority queues                  |
   | Content Store Capacity  | Cache the content data chunks           |
   | Forwarder Memory        | Pending Interest Table (PIT) storage    |
   | Compute Capacity        | CPU cycles for FIB, PIT, and CS lookups |
   +-------------------------+-----------------------------------------+


                  Figure 1: ICN Network Element Resources

   Two tradeoffs are discussed, which are important in the modeling of
   QoS treatments.  The first points to the ability to track of the
   number of traffic classes given the memory (to implement packet
   queues) and processing capacity available for various lookups.
   Second points to a trade-off between the flexibility of expressing
   the QoS treatment to the ability of protocol encoding and limitations
   of the implementation of the algorithms.

   In another work [IOTQOS], authors model the QoS treatments as a
   tradeoff between two service attributes - reliability and latency.
   While the proposed treatment model is useful for QoS in ICN network
   in general, the design mainly focuses on meeting the requirements of
   a constrained NDN (Named-data network) IoT (Internet of Things)
   network.



Anil Jangam, et al.    Expires September 10, 2020               [Page 5]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


   Following table list the potential QoS treatments depending on the
   type of network element resource they influence.  It also lists the
   native ICN features used in the realization of the treatment.  Note
   that the table only provides guidance and a particular implementation
   of QoS treatment may utilize one or more native ICN construct.

   +--------------------+----------------------------------------------+
   | QoS Treatment Type | Type of Resource and Influence               |
   +--------------------+----------------------------------------------+
   | Reliable delivery  | ++ CPU - utilization to handle errors        |
   |                    | ++ Queues - for multi-path forwarding        |
   |                    | ++ Cache - utilization for short term        |
   +--------------------+----------------------------------------------+
   | Low Latency        | ++ CPU - utilization to handle errors        |
   | delivery           | ++ Queues - for multi-path forwarding        |
   |                    | ++ Cache - replace cache entries             |
   |                    | ++ PIT - replace low priority PIT entries    |
   |                    |    in saturated PIT                          |
   +--------------------+----------------------------------------------+
   | Mobility event     | ++ Cache - update cache at next forwarder    |
   +--------------------+----------------------------------------------+
   | Bursty data        | ++ Queues - allocation of link capacity      |
   +--------------------+----------------------------------------------+
   | Search data        | ++ Queues - for multi-path forwarding        |
   |                    | ++ CPU - utilization to handle errors        |
   +--------------------+----------------------------------------------+


   Figure 2: QoS Treatment and its Influence on Network Element Resource

   It is important to note that the description of QoS treatment and
   their influence can be quite expressive as compared to flat DSCP
   codes defined in IP QoS design.  In addition, it would be beneficial
   to specify the attributes of influence the treatment is going to have
   on the network resource.  For instance, when specifying 'search' QoS
   treatment, number of forwarding paths to be attempted in parallel can
   be specified.

4.2.  Mutation of QoS Marker

   Changing the QoS marking (a.k.a.  QoS remaking) is a feature often
   used by the network routers.  While QoS remarking is a useful
   feature, it can potentially cause an inconsistent end-to-end QoS
   treatment handling.  From per-hop-behavior (PHB) perspective when QoS
   is remarked, the initial QoS marker added to the packet is lost and
   upstream router has no clue of what treatment the consumer intended
   to receive from the network.




Anil Jangam, et al.    Expires September 10, 2020               [Page 6]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


   While IP network allows for QoS marking and remarking, it suffers
   from this inconsistent end-to-end QoS treatment as it (DiffServ)
   allows only one QoS marker field.  ICN QoS design can improve over
   this QoS inconsistency in following ways.

   One of the mutation schemes provide the space for two QoS markers -
   the first preserves the original QoS marker added by consumer and
   second provides a running marker to be mutated by set by the
   intermediate forwarder in the network.  This provides an opportunity
   to the network router node to meet the QoS as per the consumer's
   expectation rather than the treatment set by the predecessing router
   based on its resource conditions.  In an alternate mechanism, a stack
   of QoS markers can be used where remarked treatment is pushed/popped
   by the node that performs the QoS-based forwarding.

   In both the two-marker based design, the original QoS marker needs to
   be encoded such that it is immutable and is always present in the
   packet, hence it is proposed to encode it into a mandatory hop-by-hop
   header.  Encoding original QoS marker into an optional hop-by-hop
   header may not be a good option.

4.3.  Nameless Object

   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 is for further study to find an encoding
   scheme to put the QoS marker in a nameless content object.

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

4.4.  QoS Marker Inside Content Name

   In this scheme, the consumer encode the QoS markers by appending them
   as a non-routable suffix to the content name.  The idea and
   distinction of routable vs non-routable component are that in general
   QoS marking is the consumer-initiated activity and content publishing
   is the producer's task.  The routing protocol only advertises the
   name or the prefixes (without any QoS marker suffix in it as producer
   never publishes the QoS markers) to eventually update the FIB
   entries.

   It is important to note the distinction between the content name and
   the QoS marker as the content and content name are published by the
   content producer whereas QoS marker suffix is appended to the content
   name by the consumer before requesting the content.  Figure 3 shows a



Anil Jangam, et al.    Expires September 10, 2020               [Page 7]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


   conceptual design of the QoS marker encoding into content name.  Note
   that discovery of content name by the consumer is out of the scope of
   this draft.

   +------------+------------+------------+-------------+-------------+
   |   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 3: Disaggregate Content and QoS Name Components

   As QoS marker is appended as non-routable suffix to the content name,
   the content name matching algorithm at the PIT, CS are extended to
   ignore QoS markers.  The suffix-based design of QoS markers does not
   affect FIB's prefix-based matching, as the FIB table contains the
   only name prefix advertised by the routing protocol.  The QoS marker,
   however, will be used to implement the QoS-aware forwarding strategy
   for both Interest and Data packets.  All name components are
   potentially routable, in the sense that if they (or their prefix) are
   in a FIB they will be matched.

   In this approach, however the name-based encoding of QoS marker (in
   both Interest and Data packet) makes it immutable as it is inside the
   authentication signature and routers along a path cannot change it.

4.4.1.  Name-based QoS Encoding Scheme

   Figure 3 shows a reference model for name component-based QoS marker
   scheme.  The number of QoS name components required depends 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 the QoS marker is the subject of further study.  Following are the
   potential mechanisms that can be used for encoding of QoS marking
   into the content name:

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

4.5.  QoS Marker Inside Hop-by-Hop Header

   In this design, the QoS marker is encoded in a mandatory hop-by-hop
   header.  The mandatory header ensures that QoS marker is available to
   each forwarding node in the network Interest packet path and allows
   it to save the QoS state in PIT and remark the QoS marker when



Anil Jangam, et al.    Expires September 10, 2020               [Page 8]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


   required.  We propose to add a new QoS marker TLV in the CCNx
   Interest message as shown in Figure 6.

   While we have proposed two QoS markers (see Section 4.2), we are
   showing encoding for single QoS marker only.  We will evolve the two-
   marker scheme and provide an update based on the community feedback.

                     1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +---------------+---------------+---------------+---------------+
     |         MessageType           |         MessageLength         |
     +---------------+---------------+---------------+---------------+
     | Name TLV                                                      |
     +---------------+---------------+---------------+---------------+
     / Mandatory QoS Marker TLV                                      /
     +---------------------------------------------------------------+


                         Figure 4: QoS Marker TLV

    +--------------+-----------+--------------------------------------+
    |    Abbrev    |    Name   |             Description              |
    +--------------+-----------+--------------------------------------+
    | T_QOS_MARKER | QoSMarker | representation of the QoS Marker TLV |
    +--------------+-----------+--------------------------------------+

                          Table 1: QoS Marker TLV

   The bit-wise structure of the QoS Marker TLV is shown in Figure 5.
   We propose to use this TLV to encode the QoS treatment identifiers
   listed in Section 4.1.

                     1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +---------------+---------------+---------------+---------------+
     |           T_QOS_MARKER        |             1 byte            |
     +---------------+---------------+---------------+---------------+
     /8 bit QoS field|                                               /
     +---------------+---------------+---------------+---------------+


                Figure 5: Binary Encoding of QoS Marker TLV

4.5.1.  Modified Interest Message

   Figure 6 shows the Interest message structure with addition of the
   QoS Marker TLV.




Anil Jangam, et al.    Expires September 10, 2020               [Page 9]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


                       1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+---------------+---------------+
       |         MessageType           |         MessageLength         |
       +---------------+---------------+---------------+---------------+
       | Name TLV                                                      |
       +---------------------------------------------------------------+
       / Mandatory QoS Marker TLV                                      /
       +---------------+---------------+---------------+---------------+
       / Optional KeyIdRestriction TLV                                 /
       +---------------------------------------------------------------+
       / Optional ContentObjectHashRestriction TLV                     /
       +---------------------------------------------------------------+


          Figure 6: Modified Interest Message with QoS Marker TLV

5.  Network Procedures

   Along with the traffic treatment, network policy configuration
   decides how the Interest and Data traffic is carried optimally.  In
   this section, we discuss how various ICN network nodes behave to
   support the QoS in the handling of Interest and Data traffic.
   Important changes in the behavior of each of the ICN network elements
   are discussed.

5.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 performs the QoS marking and adds it as non-
   routable name component, as shown in Figure 3.

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

   o  ICN 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].





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


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


   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 the QoS marker is
   encoded as a non-routable component of the content name.  The network
   adds the QoS marker based on the information such as user's service
   or subscription authorization.

5.2.  Forwarder Procedure

   In addition to preserving the Interest state (i.e. the mapping
   between content name and the interface) in the PIT, forwarder also
   preserves and maps the QoS marker information to the interface it
   receives the Interest on.  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 by ignoring the QoS markers in the name.
   The Interest aggregation at the PIT uses both content name and QoS
   marker during the PIT lookup, which makes it a QoS-aware Interest
   aggregation.  Section 6.1 provide more details about the QoS state in
   the PIT and related procedures.

   While there are no changes in the FIB table, the conventional name
   prefix based multipath forwarding path selection can use the QoS
   marker to make the QoS-aware forwarding decision.  In other words,
   the QoS markers can be used to implement the forwarding strategies.
   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.
   However, note that how forwarder maintains or knows about current
   operation state of forwarding interface is beyond the scope of this
   design.

   The process of mapping the QoS marker and the forwarding queue is not
   very different than other packet-switched forwarding mechanisms.  The
   significance of QoS treatment design is that it allows the
   implementation of a queuing algorithm that can accomplish the
   intended QoS treatment.

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

   o  QoS marking is preserved and obeyed by the router in the current
      hop



Anil Jangam, et al.    Expires September 10, 2020              [Page 11]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


   o  QoS marking is preserved but not obeyed

   o  QoS marking is remarked and obeyed

5.2.1.  QoS and Multipath Forwarding

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

5.3.  Producer Procedure

   The producer is aware of the disaggregation between routable name and
   the non-routable QoS marker.  It looks up the content in the content
   store (CS) only using a 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, the producer can have the following response behaviors:

   o  The QoS aware response to provide information to the consumer
      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.

6.  QoS-Aware Forwarder Design

   Towards supporting end-to-end QoS and handling of Interest and Data
   traffic in the network, there are some important design changes in
   the way PIT maintains the pending Interests and the way forwarding
   decisions are made.  This section discusses in detail each of the
   changes.

6.1.  Maintaining QoS State in PIT

   To support the QoS treatment processing we leverage the Interest
   state mechanism provided by the PIT.  When an Interest arrives on an
   interface and is aggregated in the PIT, its QoS attribute is
   preserved and mapped to the interface.  The specifics of the
   implementation are beyond the scope of this draft but a generic,
   conceptual model is provided here.  As shown in Figure 7, the
   interface data structure is enhanced to maintain the QoS marker
   received in the Interest.






Anil Jangam, et al.    Expires September 10, 2020              [Page 12]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


           +----------------+------------------+--------------+
           | Content Name   |    Interface Id  | QoS Marker   |
           +----------------+------------------+--------------+
           | /yt/vid1/ch1 -------> face1                      |
           |                         |                        |
           |                         +------------> /qosmrk1  |
           | /yt/vid2/ch1 -------> face2                      |
           |                         |                        |
           |                         +------------> /qosmrk1  |
           +----------------+------------------+--------------+


               Figure 7: Enhanced PIT Design with QoS Marker

   A special QoS handling is required in forwarder for couple of
   scenarios when more than one Interests are received with same content
   name but with different QoS markers.  The new aspects are discussed
   in Section 6.2.

   a.  Interests with same content name with different QoS markers are
       received on the same interface.  In this representation, Interest
       #1 is having a lower priority than Interest #2, which is a higher
       QoS priority Interest.

           +--------------------------------------------------+
           | Int# | Content name  | Face Id  | QoS Marker     |
           +------+---------------+----------+----------------+
           | Int1 | /yt/vid1/ch1  | face1    | qosmrk1        |
           | Int1 | /yt/vid1/ch1  | face1    | qosmrk2        |
           +--------------------------------------------------+


    Figure 8: Duplicate Interest on Same Face with Different QoS Marker

   b.  Interests with same content name with different QoS markers are
       received on different interfaces.  In this representation,
       Interest #1 is having a lower priority than Interest #2, which is
       a higher QoS priority Interest.

           +--------------------------------------------------+
           | Int# | Content name  | Face Id  | QoS Marker     |
           +--------------------------------------------------+
           | Int1 | /yt/vid1/ch1  | face1    | qosmrk1        |
           | Int2 | /yt/vid1/ch1  | face2    | qosmrk2        |
           +--------------------------------------------------+


    Figure 9: Duplicate Interest on two Faces with Different QoS Marker



Anil Jangam, et al.    Expires September 10, 2020              [Page 13]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


6.2.  QoS-Aware Interest Aggregation in PIT

   In scenarios shown in Figure 8 and Figure 9, since Interests are
   received with same content name, the PIT aggregation decision has to
   be done based on the QoS marker.  In both cases, if forwarder decides
   to forward both the Interests to the upstream router, it is going to
   violate the conventional PIT aggregation behavior.

   In order to support QoS-aware forwarding, the conventional PIT
   aggregation needs to be loosened up proportional to the number of QoS
   markers without which the forwarder would not get an opportunity to
   enforce all the QoS treatments.  As a result, the theoretical upper
   bound on the number of Interests with the same content name will be
   bound to the number of QoS markers.  However, in a practical case, it
   can safely be assumed that not all QoS markers are utilized all the
   time using the same content name.  Section 6.3 discusses an
   optimization in QoS-aware Interest aggregation handling.

   The impact on the PIT aggregation can be mitigated by the following
   methods:

   o  By keeping the number of QoS markers limited

   o  By having a hierarchy or an order among the QoS markers.

6.3.  Handling of QoS and PIT Aggregation

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

   The resulting state of the PIT after handling the Interest scenarios
   depicted in Figure 8 and Figure 9 are shown in Figure 10 and
   Figure 11 respectively.











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


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


           +--------------------------------------------------+
           | Content Name   |    Interface Id  | QoS Marker   |
           +--------------------------------------------------+
           | /yt/vid1/ch1 +------> face1                      |
           |                         +                        |
           |                         +------------> /qosmrk2  |
           |                         +------------> /qosmrk1  |
           +--------------------------------------------------+


       Figure 10: PIT Status after Handling Duplicate Interest with
                 different QoS Received on Same Interface

           +--------------------------------------------------+
           | Content Name   |    Interface Id  | QoS Marker   |
           +--------------------------------------------------+
           | /yt/vid1/ch1 +------> face1                      |
           |                         +------------> /qosmrk1  |
           |                       face2                      |
           |                         +------------> /qosmrk2  |
           +--------------------------------------------------+


       Figure 11: PIT Status after Handling Duplicate Interest with
              different QoS Received on Different Interfaces

   In an another case where the duplicate Interest is received but with
   lower priority than the pending one, the second interest with lower
   QoS marker will not be forwarded.

   It is important to note that forwarding of Interest with higher QoS
   marker while having a pending Interest with a lower QoS marker is a
   breach of conventional Interest aggregation in the PIT; however, it
   provides an opportunity to the router to enforce the higher priority
   QoS treatment to the Interest as well as the resulting Data traffic.

6.4.  Data Delivery at PIT

   Assuming the router has forwarded more than one Interest in the
   network for the same content, there is no certainty which of the
   Interests (i.e. one with higher QoS priority or with lower QoS
   priority) would be satisfied first.  This depends on various network
   conditions as well as the distance of the content cache having the
   requested content.  In this case, it is very likely that arrival of
   Data packet for either Interest is going to satisfy all pending
   Interest marked with different QoS marking.





Anil Jangam, et al.    Expires September 10, 2020              [Page 15]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


   The PIT behavior of Data handling does not change with the addition
   of the QoS marker mainly because the content in the Data packet does
   not change with the QoS marker.  Depending on the implementation of
   the PIT aggregation, two Data forwarding scenarios are possible.  In
   both cases, it also determines how the data packet is queued on the
   downstream interface.

   o  If the Interest are aggregated as shown in Figure 10, Data packet
      to the downstream interface is forwarded with the higher QoS
      marking recorded at the interface in the PIT.

   o  If the Interest are aggregated as shown in Figure 11, Data packet
      to the downstream interface is forwarded with its original QoS
      marking recorded at the interface in the PIT.

   With the QoS handling in the PIT described in Section 6.3, it is
   possible to satisfy a pending Interest with a lower QoS marking with
   the arrival of a Data packet having higher QoS marker.  As a result,
   a user with lower QoS subscription may experience an improved latency
   from the network.  Note that this is a legitimate behavior as it is
   ICN's one of the design goals i.e. to optimize the network round-trip
   time providing better user experience.

7.  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 is 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, therefore, can be modified by the ICN router nodes in the
   transit.

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

8.  Summary

   This draft provides an architecture to implement end-to-end QoS
   treatments in the ICN network using a name-based non-routable QoS
   marker suffix.  Mechanics for mutation of the QoS marker is discussed
   along with schemes to preserve the original QoS marker added by the




Anil Jangam, et al.    Expires September 10, 2020              [Page 16]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


   consumer.  The independence between content name and QoS marking
   makes their evolution easier.

   An enhancement to the PIT to store the per-interface QoS state is
   presented.  An optimization to deal with the QoS-aware Interest
   aggregation is discussed where a number of pending Interests requests
   in the PIT for the same content to be normalized around the highest
   QoS marking.

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

   A detailed analysis and evaluation is required, either through a
   prototype using [VICN] or a simulation using [NDNSIM], to assess the
   effect of QoS-aware PIT aggregation.  The details on the design of a
   naming scheme for QoS marking in the content name is required.  It is
   also necessary to test and measure the effectiveness of the QoS
   framework by deploying it using a multimedia streaming application.

9.  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 Marc Mosko who
   provided useful feedback on proposed name-based encoding scheme and
   nameless content objects.

10.  IANA Considerations

   TBD

11.  References

11.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/>.





Anil Jangam, et al.    Expires September 10, 2020              [Page 17]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


   [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>.

11.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/".

   [IOTQOS]   "Cenk et.al., Quality of Service for ICN in the IoT, ICNRG
              Internet-Draft, July 2019,
              https://datatracker.ietf.org/doc/html/
              draft-gundogan-icnrg-iotqos-01".

   [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>.

   [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".






Anil Jangam, et al.    Expires September 10, 2020              [Page 18]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


   [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/>.

   [QOSARCH]  "Dave Oran, Considerations in the development of a QoS
              Architecture for CCNx-like ICN protocols, ICNRG Internet-
              Draft, February 2020, https://datatracker.ietf.org/doc/
              draft-oran-icnrg-qosarch/".

   [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".

   [YAOGONG]  "Wang, Yaogong et.al., An Improved Hop-by-Hop Interest
              Shaper for Congestion Control in Named Data Networking,
              ACM SIGCOMM Computer Communication Review, August 2013",
              <https://dl.acm.org/citation.cfm?id=2491233>.

Authors' Addresses

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

   Email: anjangam@cisco.com





Anil Jangam, et al.    Expires September 10, 2020              [Page 19]


Internet-Draft      Name-based QoS Treatments in ICN          March 2020


   Prakash Suthar
   Cisco Systems
   Rosemont, Illinois  60018
   USA

   Email: psuthar@cisco.com


   Milan Stolic
   Cisco Systems
   Rosemont, Illinois  60018
   USA

   Email: mistolic@cisco.com





































Anil Jangam, et al.    Expires September 10, 2020              [Page 20]


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