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]