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]