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", . [CCNXSEMANTICS] "Marc Mosko et.al., CCNx Semantics, ICNRG Internet-Draft 2018", . 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, . 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", . [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", . [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, . [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, . [NDNSIM] "ndnSIM: NS-3 based Named Data Networking (NDN) simulator", . [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, . [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", . [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", . 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]