ICNRG Anil Jangam, Ed. Internet-Draft Prakash Suthar Intended status: Informational Milan Stolic Expires: September 12, 2019 Cisco Systems March 11, 2019 QoS Treatments in ICN using Disaggregated Name Components draft-anilj-icnrg-dnc-qos-icn-00 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 September 12, 2019. Anil Jangam, et al. Expires September 12, 2019 [Page 1] Internet-Draft Name-based QoS Treatments in ICN March 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. Name based QoS Design . . . . . . . . . . . . . . . . . . . . 5 4.1. QoS Marking in Content Name . . . . . . . . . . . . . . . 5 4.2. QoS Marker Naming Scheme . . . . . . . . . . . . . . . . 6 5. Network Procedures . . . . . . . . . . . . . . . . . . . . . 7 5.1. Consumer Procedure . . . . . . . . . . . . . . . . . . . 7 5.2. Forwarder Procedure . . . . . . . . . . . . . . . . . . . 8 5.2.1. QoS and Multipath Forwarding . . . . . . . . . . . . 9 5.3. Producer Procedure . . . . . . . . . . . . . . . . . . . 9 6. QoS-Aware Forwarder Design . . . . . . . . . . . . . . . . . 10 6.1. Enhanced PIT Design . . . . . . . . . . . . . . . . . . . 10 6.2. Multiple Interest and PIT Scaling . . . . . . . . . . . . 11 6.3. Handling PIT Scaling . . . . . . . . . . . . . . . . . . 12 6.4. Data Delivery at PIT . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Anil Jangam, et al. Expires September 12, 2019 [Page 2] Internet-Draft Name-based QoS Treatments in ICN March 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 September 12, 2019 [Page 3] Internet-Draft Name-based QoS Treatments in ICN March 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 September 12, 2019 [Page 4] Internet-Draft Name-based QoS Treatments in ICN March 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. Name based QoS Design 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). 4.1. QoS Marking 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 marker. As shown in Figure 1, there is a logical separation between the content name and the QoS marker. To support the consumer driven Anil Jangam, et al. Expires September 12, 2019 [Page 5] Internet-Draft Name-based QoS Treatments in ICN March 2019 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. 4.2. QoS Marker Naming 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]. 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. Anil Jangam, et al. Expires September 12, 2019 [Page 6] Internet-Draft Name-based QoS Treatments in ICN March 2019 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. 5. 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. 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 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: Anil Jangam, et al. Expires September 12, 2019 [Page 7] Internet-Draft Name-based QoS Treatments in ICN March 2019 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. 5.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 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. Anil Jangam, et al. Expires September 12, 2019 [Page 8] Internet-Draft Name-based QoS Treatments in ICN March 2019 Conversely, the PIT aggregation logic uses both content name and QoS marker in PIT lookup, which makes it a QoS-aware Interest aggregation. Section 6.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 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 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. Anil Jangam, et al. Expires September 12, 2019 [Page 9] Internet-Draft Name-based QoS Treatments in ICN March 2019 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. 6. 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 5. 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. 6.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. +----+----------------+--------------------+--------------+ | | | | | | # | 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 Anil Jangam, et al. Expires September 12, 2019 [Page 10] Internet-Draft Name-based QoS Treatments in ICN March 2019 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 6.2. 6.2. Multiple Interest and PIT Scaling With two scenarios (d) and (e) in Section 6.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 Anil Jangam, et al. Expires September 12, 2019 [Page 11] Internet-Draft Name-based QoS Treatments in ICN March 2019 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 6.3 6.3. Handling PIT Scaling The PIT scaling issue described in Section 6.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 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. 6.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 Anil Jangam, et al. Expires September 12, 2019 [Page 12] Internet-Draft Name-based QoS Treatments in ICN March 2019 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 6.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. 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 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 transit ICN forwarders; however, it also opens it to various attack scenarios. 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 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 Anil Jangam, et al. Expires September 12, 2019 [Page 13] Internet-Draft Name-based QoS Treatments in ICN March 2019 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. 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. 10. IANA Considerations This draft includes no request to IANA. 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", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Anil Jangam, et al. Expires September 12, 2019 [Page 14] Internet-Draft Name-based QoS Treatments in ICN March 2019 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/". [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". [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", . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", January 2005, . Anil Jangam, et al. Expires September 12, 2019 [Page 15] Internet-Draft Name-based QoS Treatments in ICN March 2019 [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". 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 September 12, 2019 [Page 16]