idnits 2.17.1 draft-anilj-icnrg-dnc-qos-icn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2019) is 1870 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG Anil Jangam, Ed. 3 Internet-Draft Prakash Suthar 4 Intended status: Informational Milan Stolic 5 Expires: September 12, 2019 Cisco Systems 6 March 11, 2019 8 QoS Treatments in ICN using Disaggregated Name Components 9 draft-anilj-icnrg-dnc-qos-icn-00 11 Abstract 13 Mechanisms for specifying and implementing end-to-end Quality of 14 service (QoS) treatments in Information-Centric Networks (ICN) has 15 not been explored so far. There has been some work towards 16 implementing QoS in ICN; however, the discussions are mainly centered 17 around strategies used in efficient forwarding of Interest packets. 18 Moreover, as ICN has been tested mainly as an IP overlay, it's QoS is 19 still governed by the IP QoS framework and there is a need for 20 implementing QoS in ICN natively. This document describes mechanisms 21 to classify and provide associated "name-based" extensions to 22 identify QoS within the framework of ICN's core design principles. 23 The name-based design provides a mechanism to carry QoS information 24 and implement the treatments as ICN packets travel across different 25 routers in the ICN network. Detailed discussion is provided for QoS 26 specific procedures in each of the ICN network elements i.e. 27 consumer, producer and forwarder. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 12, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 65 3. Prior Work and Motivation . . . . . . . . . . . . . . . . . . 3 66 3.1. Prioritization of Interest Packets . . . . . . . . . . . 3 67 3.2. Flow Classification in ICN . . . . . . . . . . . . . . . 4 68 4. Name based QoS Design . . . . . . . . . . . . . . . . . . . . 5 69 4.1. QoS Marking in Content Name . . . . . . . . . . . . . . . 5 70 4.2. QoS Marker Naming Scheme . . . . . . . . . . . . . . . . 6 71 5. Network Procedures . . . . . . . . . . . . . . . . . . . . . 7 72 5.1. Consumer Procedure . . . . . . . . . . . . . . . . . . . 7 73 5.2. Forwarder Procedure . . . . . . . . . . . . . . . . . . . 8 74 5.2.1. QoS and Multipath Forwarding . . . . . . . . . . . . 9 75 5.3. Producer Procedure . . . . . . . . . . . . . . . . . . . 9 76 6. QoS-Aware Forwarder Design . . . . . . . . . . . . . . . . . 10 77 6.1. Enhanced PIT Design . . . . . . . . . . . . . . . . . . . 10 78 6.2. Multiple Interest and PIT Scaling . . . . . . . . . . . . 11 79 6.3. Handling PIT Scaling . . . . . . . . . . . . . . . . . . 12 80 6.4. Data Delivery at PIT . . . . . . . . . . . . . . . . . . 12 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 87 11.2. Informative References . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 Information Centric Networking (ICN) is rapidly emerging as an 93 alternative networking mechanism for the TCP/IP based host-centric 94 networking paradigm. Use cases of video conferencing [MPVCICN] and 95 real-time streaming [NDNRTC] signify the value of ICN architecture 96 and have been studied in detail. Also, a number of studies on 97 routing of Interest and flow classification [ICNFLOW] have been 98 published; however, relatively less work has been done on end-to-end 99 quality of service (QoS) architecture for ICN. QoS is important to 100 deliver preferential service to a variety of traffic flows resulting 101 into better user experience. Evaluation and study of prior work done 102 in this area is provided in Section 3. The current QoS 103 implementation is based on either Layer-3 TOS or DiffServ, which is 104 applicable only for ICN as an overlay. The QoS mechanisms described 105 in this draft are applicable to the native ICN architecture. A 106 detailed discussion related to the design of name-based QoS encoding, 107 which is in line with ICN's fundamental design principles. 109 2. Conventions and Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 This document uses the terminology of [CCNXSEMANTICS] and 116 [CCNXMESSAGES] for CCNx entities. 118 3. Prior Work and Motivation 120 3.1. Prioritization of Interest Packets 122 Among the work related to the quality of service (QoS) requirements 123 in ICN network, larger emphasis is given to an optimized and 124 efficient routing of Interest packets towards its content. 126 M.F. Al-Naday et.al. in [NADAY] argues that information awareness of 127 ICN network would help build scalable QoS model. In the context of 128 CCN/NDN network design, authors points to the possibility of using 129 the QoS aware name prefixes, with potentially limiting the third 130 parties (e.g. network operators) from defining an alternative QoS 131 enforcement mechanisms. Moreover, the QoS solution is developed 132 around the PURSUIT architecture, which may not be applicable to CCN/ 133 NDN. 135 Weibo Chu et.al. in [WEIBO] present a QoS model for ICN network based 136 on the popularity ranking of the content and its placement/location 137 in the network. They present a classification of the content into 138 three categories - locally cached, remotely cached, and uncached 139 contents, hence the network delay is modeled as a function of the 140 distance of the content from the requester. Essentially, the QoS 141 problem is seen in the perspective of faster routing of Interest 142 request towards its content. 144 In [XINGWEI] authors present a QoS mechanism, which is applicable to 145 the routing of Interest requests in ICN network. The basis of the 146 proposal is to decide the suitability of the forwarding link to make 147 the process more energy efficient. They use the same Data forwarding 148 algorithm specified in the original NDN design [JACOBSON]. 150 In [CHRISTOS] Christos et.al. argue about a need for a differentiated 151 routing and forwarding mechanisms based on not only the name of the 152 content but also specifying the nature of the traffic. They further 153 emphasize that this differentiation is better handled at the network 154 level rather than leaving it for the upper layer. 156 In all above use cases, the QoS related discussions are mainly 157 focused on the forwarding of the Interest requests. It assumes that 158 Data packets are forwarded in downstream direction according to the 159 pending Interest table (PIT). There is little or no discussions 160 provided about how preferential treatment can be implemented and 161 enforced in the Data packet path. 163 3.2. Flow Classification in ICN 165 Flow classification [ICNFLOW] describe the methods for classification 166 of data flows in ICN. The method called equivalence class component 167 count (EC3), uses a predefined number of name components of the 168 content name forming an equivalence class. While approach has the 169 flexibility in re-grouping of components in aggregating the flows, it 170 suffers from an inconsistent interpretation due to implicit binding 171 of the equivalence class into the content namespace. In the second 172 method called equivalence class name component type (ECNCT), the flow 173 classification information is directly embedded in the hierarchical 174 content name. This paves the way to achieve implicit aggregation of 175 data flows analogous to the prefix-based aggregation of content names 176 in FIB table. At the forwarder level, a flow table is implemented to 177 store the equivalence classes and is used to perform the flow 178 classification decisions. 180 While both the schemes provide data flow classification in ICN, they 181 are not sufficient for implementing a preferential service treatment 182 in the network. Table 1 provide a summary of important differences 183 between the flow classification and QoS treament implementation. 185 +---+-------------------------------+-------------------------------+ 186 | # | Flow Classifier | QoS Marker | 187 +---+-------------------------------+-------------------------------+ 188 | 1 | Identify the type of data | Identify the QoS treatment | 189 | | flow | | 190 | 2 | Set by the producer | Set by the consumer | 191 | 3 | Immutable for the lifetime of | Can be modified in the | 192 | | Interest | network | 193 | 4 | Part of the routable content | Non-routable part of the | 194 | | name | content name | 195 +---+-------------------------------+-------------------------------+ 197 Table 1: Difference between Flow Class and QoS Marker 199 By design, the data flow classification described in ECNCT is set by 200 the producer at the time of registration of the content name and 201 hence it is immutable for the life time of the content. Also, flow 202 classification is encoded as part of routable name and therefore it 203 has direct effect on both, PIT and FIB matching. Since flow 204 classification mechanisms are initiated or triggered at the producer, 205 they lack to convey consumer's or application's context in deciding 206 the traffic treatment in the network for individual data flows. 208 4. Name based QoS Design 210 Producer decides the classification of the data flow packets; 211 however, it is consumer's prerogative what QoS treatment is actually 212 provided to them by the network. Consumer application itself or the 213 network on behalf of consumer, can perform the QoS marking in the 214 Interest messages. Following factors govern the type of QoS markers 215 we may require. 217 o Consumer's subscription: The type of service user subscribes with 218 the service provider e.g. subscription with high-speed data plan 219 vs. low-speed data plan. 221 o Service type: The type of service or the application consumer is 222 running. As a reference, we may refer to service classes as 223 described in [RFC4594] (see section 2.0). 225 4.1. QoS Marking in Content Name 227 Supporting the ICN design principles, the QoS marking is encoded in 228 the content name field. Prior to their consumption, as both content 229 and the content name are published by the content producer, it is 230 important to make distinction between the content name and the QoS 231 marker. As shown in Figure 1, there is a logical separation between 232 the content name and the QoS marker. To support the consumer driven 233 ICN design, QoS marker is encoded as non-routable part of the content 234 name and hence is editable. To support the content matching 235 algorithm at PIT and prefix matching algorithm at FIB, QoS marker is 236 added at the end of the content name. 238 +------------+------------+------------+-------------+-------------+ 239 | Content | Content | Content | QoS | QoS | 240 | Name comp-1| Name comp-2| Name comp-3| Name comp-1 | Name comp-2 | 241 | | | | | | 242 +------------+------------+------------+-------------+-------------+ 243 |<---------Routable name comp--------->|<--Non-routable name comp->| 245 Figure 1: Disaggregate Content and QoS Name Components 247 The non-routable name component design of QoS marker allows consumer 248 to add the QoS marking to the Interest message. The reasoning behind 249 making it non-routable is that it does not affect the forwarder's 250 name or prefix matching process directly; however, it can influence 251 FIB's selection of forwarding faces the Interest packet is forwarded 252 to. This allows for an implementation of QoS-aware forwarding 253 strategy for both Interest and Data packets. 255 4.2. QoS Marker Naming Scheme 257 Figure 1 shows a reference model for name component-based QoS marker 258 scheme. The number of QoS name components required shall depend on 259 the type of QoS encoding uses as well as the total number of markers 260 required. QoS marker design can either be hierarchical or based on a 261 flat naming scheme. The exact requirements and design specification 262 of QoS marker is subject of further study. 264 While exact specification of QoS marking are being studied, following 265 are the potential mechanisms that can used for encoding of QoS 266 marking into content name: 268 o Using the path parameters addition to HTTP URI [RFC3986] (see 269 section 3.3). We provide a summary of path parameter below from 270 [RFC3986]. 272 The path component contains data organized in hierarchical form 273 serves to identify a resource within the scope of the URI's scheme 274 and its naming authority. A path consists of a sequence of path 275 segments separated by a slash ("/") character, which indicate 276 hierarchy. A path parameter, part of a path segment that occurs 277 after its name, control the representations of resource. A 278 reserved characters often allowed in a path segment to delimit 279 scheme-specific or dereference-handler-specific subcomponents. 281 For example, the semicolon (";") and equals ("=") reserved 282 characters are often used to delimit parameters and parameter 283 values applicable to that segment. 285 The semicolon ';' delimits the parameters i.e. anything in a path 286 segment that comes after a ';' is treated as a new parameter. The 287 '=' separate parameter names from their values i.e. anything that 288 is specified after '=' sign is treated as parameter value. A 289 parameter may have multiple values separated by a ',' symbol. Few 290 examples of path parameter are shown below. 292 * /content/name;param=val1 - Content name with single path param 293 with single value 295 * /content/name;param1=val1;param2=val1 - Content name with two 296 path params 298 * /content/name;param1=val1,val2 - Content name with single path 299 param with two value 301 o Using the 'application payload name segments' approach defined in 302 CCNX [CCNXMESSAGES] (see section-3.6.1.1). 304 The exact form and structure of QoS marking are being developed and 305 more details shall be provided in next revision. 307 5. Network Procedures 309 An important takeaway of implementing QoS is effective management of 310 network resources such as, link capacity, bandwidth, and memory. ICN 311 follows a pull-based or a receiver driven design, which directly 312 influences the load on to the network. Network based policy 313 configuration decides how the Interest and Data traffic is carried 314 optimally, and producers, depending on where the content is, responds 315 to the requests from the consumers. With introduction of QoS marking 316 in the Interest packet, important changes in the behavior of each of 317 these network elements are discussed. 319 5.1. Consumer Procedure 321 Consumer sends out the Interest packet into the network adding the 322 QoS marker as per its service subscription and/or quality 323 requirements. Consumer does QoS marking and adds it as non-routable 324 name component, as shown in Figure 1. 326 Consumer, the initiator of the Interest is the most appropriate 327 network entity to perform the QoS marking for the following reasons: 329 o ICN fundamentally is a pull-based, consumer driven design and 330 consumer directly influences the resource allocation in the 331 network in terms of timing and rate of Interest traffic. 333 o Consumer is aware of the context of the application initiating the 334 Interest. For instance, an application starting a simple video 335 download compared to initiating a video conferencing. 337 o Consumer at least partially in control of the traffic paths in 338 both directions [MIRCC]. 340 As an alternative to consumer adding the QoS marker in the Interest, 341 the network (i.e. forwarder) can be allowed to amend the content name 342 with the QoS marker. It should be possible since QoS marker is 343 encoded as a non-routable component of the content name. The network 344 shall add the QoS marker based on the information such as, user's 345 service or subscription authorization. In this context, an immediate 346 forwarder (a.k.a. default gateway) would be the appropriate network 347 node to perform this marking. 349 Following aspects need more discussion: 351 o Should network be allowed to add QoS marker in non-routable 352 component of content name or should it add as a separate field of 353 the Interest packets. 355 o Once QoS marker is added and Interest is admitted into the network 356 should network be allowed to modify the QoS marker. 358 o Since QoS markings are explicit, should the QoS marker be aware of 359 consumer's subscription and make the relationship between the two 360 explicit. 362 5.2. Forwarder Procedure 364 ICN forwarder, in addition to preserving the Interest state into PIT 365 table (mapping between content name and the interface it receives the 366 Interest on), now also preserves the state of QoS marker against the 367 interface. In a representative domain, the PIT structure is enhanced 368 by adding a new column to save the state of QoS marker. This forms a 369 3-tuple information set comprising content name, interface, and QoS 370 marker. Unlike PIT, there is no change in the structure of FIB 371 table; however, forwarder forwards to the upstream ICN router both 372 content name and QoS marker, as they are received from its 373 predecessor. 375 With enhanced QoS-aware content name design, forwarder performs the 376 content store (CS) lookup only using routable name component. 378 Conversely, the PIT aggregation logic uses both content name and QoS 379 marker in PIT lookup, which makes it a QoS-aware Interest 380 aggregation. Section 6.1 provide more details about new PIT design 381 and related procedures. 383 While there are no changes in the FIB table, the conventional name 384 prefix based multipath forwarding path selection of forwarder can use 385 the QoS marker to make the QoS-aware forwarding decision. For 386 example, QoS marking can be used to select a low latency interface 387 over a high latency interface or it can be used to select a high 388 bandwidth path over a low bandwidth path or vice versa. 390 The following aspects of QoS-aware forwarder design need more 391 attention: 393 o How mapping is done between QoS marking and the forwarding queue 394 after the forwarding interface is selected. 396 o From the perspective of per-hop-behavior (PHB), it is important to 397 understand if remarking of QoS is allowed and if one marker is 398 sufficient for it. One possibility is to preserve the original 399 QoS marker added by consumer and have a running marker set by the 400 intermediate forwarder in the network. 402 o In the context of QoS remarking by the network, it may also become 403 important to let consumer know, what network is doing with their 404 QoS marking. From the network behavior perspective, following are 405 the possibilities: 407 * QoS marking is preserved and obeyed in subsequent hop 409 * QoS marking is preserved but not obeyed 411 * QoS marking is remarked and obeyed 413 5.2.1. QoS and Multipath Forwarding 415 QoS marking in the Interest packet does not change the multipath 416 forwarding capability of ICN forwarders. In Section 6.2, more 417 details are provided about specific QoS behavior related to multipath 418 forwarding. 420 5.3. Producer Procedure 422 Producer is aware of the disaggregation between routable name and the 423 non-routable QoS marker. It looks up the content in content store 424 (CS) only using routable name component. An intermediate router acts 425 in a similar manner. 427 Depending on the what kind of QoS marking is done in the Interest 428 packet, producer can have following response behaviors: 430 o Producer may respond in a different manner with the Data packet to 431 the consumer. 433 o One such aspect of QoS aware response could be to provide the 434 consumer information about how much distance (e.g. number of hops) 435 Interest has travelled into the network before it is satisfied. 437 o QoS-aware response does not change the original requested content. 439 6. QoS-Aware Forwarder Design 441 Towards supporting end-to-end QoS and handling of Interest and Data 442 traffic throughout the network, important network procedures are 443 discussed in Section 5. There are some important design changes in 444 the way PIT maintains the pending Interests and the way forwarding 445 decisions are made. This section discuss in detail each of the 446 changes. 448 6.1. Enhanced PIT Design 450 The new PIT design has added a new column to maintain the QoS marker 451 received in the Interest packet. The enhancement in the PIT table 452 and its behavior are applicable only specific to its Interest 453 aggregation feature of multiple Interest packet received for the same 454 content. 456 +----+----------------+--------------------+--------------+ 457 | | | | | 458 | # | Interface Id | Content Name | QoS Marker | 459 +---------------------------------------------------------+ 460 | 1 | face-1 | /youtube/med/vid-1 | /qos-level-1 | 461 +---------------------------------------------------------+ 462 | 2 | face-2 | /youtube/med/vid-1 | /qos-level-2 | 463 +---------------------------------------------------------+ 464 | 3 | face-1 | /youtube/med/vid-1 | /qos-level-3 | 465 +----+----------------+--------------------+--------------+ 467 Figure 2: Enhanced PIT Design with QoS Marker 469 The scenarios emerging from the new QoS marking and new PIT design 470 are discussed here. Three PIT entries are shown in Figure 2 to 471 explain the new PIT design and its behavior. Notice that in the 472 modified PIT design, content name always takes the higher precedence 473 over the QoS marker in deciding the Interest aggregation. Having 474 said this, following scenarios of Interest arrival at forwarder are 475 possible: 477 a. Two or more Interests with different content name, but with 478 different QoS markers are received on two different interfaces. 480 b. Two or more Interests with different content name, but with same 481 QoS markers are received on two different interfaces. 483 c. Two or more Interests with same content name and with same QoS 484 markers are received on two different interfaces. 486 d. Two or more Interests with same content name, but with different 487 QoS markers are received on two different interfaces. 489 e. Two or more Interests with same content name, but with different 490 QoS markers are received on the same interface. 492 Scenarios (a) and (b), since both Interests are received with 493 different content name, no PIT aggregation is required and Interest 494 are forwarded if content is not found in CS. In case (c), since both 495 content name and QoS marker are same, Interest is aggregated in PIT 496 and second Interest is not forwarded. 498 In scenarios (d) and (e), since Interests are received with same 499 content name, the PIT aggregation decision is made based on the QoS 500 marker. These two scenarios lead to a potential PIT scaling issue, 501 which is discussed in Section 6.2. 503 6.2. Multiple Interest and PIT Scaling 505 With two scenarios (d) and (e) in Section 6.1 forwarder forwards both 506 the Interests to upstream router creating two PIT entries as shown in 507 Figure 2 i.e. entries #1 and #3. This behavior violates the 508 conventional PIT behavior; however, is essential to support the 509 different QoS treatment. 511 In order to support QoS-aware forwarding, the conventional PIT 512 aggregation needs to be loosened up proportional to the number of QoS 513 markers; in other words, the QoS treatments. Without this, upstream 514 forwarder would not get an opportunity to obey each of the QoS 515 treatments. The theoretical upper bound on the PIT scaling for given 516 content will be equal to number of QoS markers. 518 The impact on the PIT scaling depends on and can be mitigated by the 519 following mechanisms: 521 o By keeping the number of QoS markers limited 522 o By keeping the QoS marker unique and avoiding the hierarchy or 523 order among them. 525 o In real-time case, the PIT may not hit the upper bound all the 526 times i.e. not all QoS markers are utilized all the times on the 527 same content name. 529 o Using an optimization in multiple Interest handling, as discussed 530 in Section 6.3 532 6.3. Handling PIT Scaling 534 The PIT scaling issue described in Section 6.2 can be handled with an 535 optimization discussed here. 537 The forwarder can avoid forwarding the second/duplicate Interest if 538 it receives it with a lower QoS marking than the one already pending 539 in PIT. Thus, achieving the Interest aggregation based on the higher 540 QoS marker for given content name. Conversely if the received 541 Interest is with a higher QoS marking, then forwarder forwards the 542 Interest and updates the pending PIT entry with higher QoS marking. 543 Also, note that forwarder updates the PIT entry irrespective of the 544 interface the higher QoS marked Interest is received on. 546 Notice that forwarding of Interest with higher QoS marker in spite of 547 having an already pending with a lower QoS marker, is a breach of 548 Interest aggregation at PIT in conventional terms; however, it is 549 necessary to give an opportunity for upstream routers to provide 550 appropriate QoS treatment to the higher priority Interest and the 551 resulting Data traffic flow. 553 These are the scenarios, which provide for a QoS-aware PIT design, 554 Interest aggregation and forwarding in ICN router. 556 6.4. Data Delivery at PIT 558 With QoS-aware Interest aggregation at PIT, more than one Interest 559 are flowing in the network for the same content. With a higher 560 probability of a priority treatment to the higher QoS marked Interest 561 at each hop and with the possibility of multipath forwarding, it is 562 highly likely that the Interest with higher QoS marking shall be 563 satisfied faster than the Interest with lower QoS marking. 565 The Data packet arrival may satisfy all the PIT entries for the given 566 content name irrespective of the QoS markers in Data packet. This is 567 possible mainly because the content itself in Data packet does not 568 change by different QoS marker in the Interest. Depending on whether 569 forwarder implements a PIT scaling optimization, two scenarios of 570 Data forwarding are possible: 572 o Data packet to the downstream interface is forwarded with its 573 original QoS marking recorded by the PIT. 575 o Data packet to the downstream interface is forwarded with the 576 higher QoS marking recorded by the PIT by virtue of PIT 577 optimization. 579 With the PIT optimization described in Section 6.3, it is possible to 580 satisfy a pending Interest with lower QoS marking with arrival of a 581 Data packet having higher QoS marker. As a result, a user with lower 582 QoS subscription may experience a better response time from the 583 network. Note that this is a legitimate behavior, as ICN is 584 fundamentally designed to optimize the network round-trip time 585 providing better user experience. 587 7. Security Considerations 589 ICN being name-based networking opens up new security and privacy 590 considerations which have to be studied in the context of name-based 591 QoS framework. 593 Depending on where the QoS marker is encoded in the Interest, certain 594 security attack scenarios against QoS treatment are possible. If the 595 QoS marker located inside the security envelope, it can be read, but 596 not changed. Conversely, if the QoS marker is placed outside of the 597 security envelope, it can be added as hop-by-hop message header and, 598 therefore, can be modified by the transit ICN forwarders; however, it 599 also opens it to various attack scenarios. 601 Consumer procedure discussed in Section 5.1 and forwarder procedure 602 discussed in Section 5.2 shall decide the security requirements 603 related to implementing QoS treatments in ICN. 605 8. Summary 607 This draft provides an architecture to implement end-to-end QoS 608 treatments in ICN network using a name-based disaggregation of 609 routable content name and non-routable, mutable QoS markers. The 610 independence between content name and QoS marking makes their 611 evolution easier and yet bounded to content name keeping with ICN 612 principles. 614 A new PIT design and a potential impact on PIT scaling is presented. 615 An optimization to deal with the PIT scaling problem is discussed 616 where a number of pending Interests requests in PIT for same content 617 to be normalized around the highest QoS marking. 619 Security requirements are dependent on whether QoS marker is encoded 620 inside security envelop or outside of it. Consumer and forwarder 621 procedure requirements shall also govern the security features. 623 A detailed analysis and evaluation shall be performed, through 624 prototype using [VICN] and/or simulation [NDNSIM], of the impact on 625 PIT aggregation and effect of optimization. The details on design of 626 a naming scheme for QoS marking in content name needs to be worked 627 on. It is also necessary to test and measure the effectiveness of 628 the QoS framework by deploying it using a multimedia streaming 629 application. 631 9. Acknowledgements 633 We thank all contributors, reviewers and the chairs for their 634 valuable time in providing the comments and feedback, which has 635 helped to improve this draft. 637 10. IANA Considerations 639 This draft includes no request to IANA. 641 11. References 643 11.1. Normative References 645 [CCNXMESSAGES] 646 "Marc Mosko et.al., CCNx Messages in TLV Format, ICNRG 647 Internet-Draft 2019", . 650 [CCNXSEMANTICS] 651 "Marc Mosko et.al., CCNx Semantics, ICNRG Internet-Draft 652 2018", . 655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 656 Requirement Levels", BCP 14, RFC 2119, 657 DOI 10.17487/RFC2119, March 1997, 658 . 660 11.2. Informative References 662 [CHRISTOS] 663 "Christos Tsilopoulos et.al., Supporting Diverse Traffic 664 Types in Information Centric Networks, Proceedings of the 665 ACM SIGCOMM Workshop on Information-centric Networking, 666 Pages 13-19, ICN 2011", 667 . 669 [ICNFLOW] "Moiseenko et.al., Flow Classification in Information 670 Centric Networking, ICNRG Internet-Draft, February 2017, 671 https://datatracker.ietf.org/doc/ 672 draft-moiseenko-icnrg-flowclass/". 674 [JACOBSON] 675 Jacobson, Van et.al, "Networking Named Content, 5th 676 International Conference on Emerging Networking 677 Experiments and Technologies, CoNEXT '09, pp. 1-12, 2009". 679 [MIRCC] "Milad Mahdian et.al., MIRCC: Multipath-aware ICN Rate- 680 based Congestion Control, Proceedings of the 3rd ACM 681 Conference on Information-Centric Networking Pages 1-10, 682 ICN 2016", . 684 [MPVCICN] Jangam, A., Ravindran, R., Chakraborti, A., Wan, X., and 685 G. Wang, "Realtime multi-party video conferencing service 686 over information centric network", IEEE International 687 Conference on Multimedia and Expo Workshops (ICMEW) Turin, 688 Italy, pp. 1-6, June 2015, 689 . 691 [NADAY] "M. F. Al-Naday et.al., Quality of service in an 692 information-centric network, 2014 IEEE Global 693 Communications Conference GLOCOM.2014, pp. 1861-1866, Dec 694 2014". 696 [NDNRTC] Gusev, P., Wang, Z., Burke, J., Zhang, L., Yoneda, T., 697 Ohnishi, R., and E. Muramoto, "Real-time Streaming Data 698 Delivery over Named Data Networking,", IEICE Transactions 699 on Communications vol. E99.B, pp. 974-991, May 2016, 700 . 702 [NDNSIM] "ndnSIM: NS-3 based Named Data Networking (NDN) 703 simulator", . 705 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 706 Resource Identifier (URI): Generic Syntax", January 2005, 707 . 709 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 710 Guidelines for DiffServ Service Classes", August 2006, 711 . 713 [VICN] "Mauro Sardara et.al., Virtualized ICN (vICN): towards a 714 unified network virtualization framework for ICN 715 experimentation, ICN'17 Proceedings of the 4th ACM 716 Conference on Information-Centric Networking Pages 717 109-115", . 719 [WEIBO] "Weibo Chu et.al., Network delay guarantee for 720 differentiated services in content-centric networking, 721 Journal of Computer Communications Volume 76, Pages 54-66, 722 February 2016". 724 [XINGWEI] "Xingwei Wang et.al., Energy-efficient ICN routing 725 mechanism with QoS support, Journal of Computer 726 Communications Volume 131, Pages 38-51, 2018". 728 Authors' Addresses 730 Anil Jangam (editor) 731 Cisco Systems 732 San Jose, California 95134 733 USA 735 Email: anjangam@cisco.com 737 Prakash Suthar 738 Cisco Systems 739 Rosemont, Illinois 56018 740 USA 742 Email: psuthar@cisco.com 744 Milan Stolic 745 Cisco Systems 746 Rosemont, Illinois 56018 747 USA 749 Email: mistolic@cisco.com