idnits 2.17.1 draft-oran-icnrg-qosarch-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 == Line 472 has weird spacing: '...iryTime time ...' == Line 476 has weird spacing: '...he Time time ...' -- The document date (August 9, 2019) is 1720 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-22 == Outdated reference: A later version (-15) exists of draft-irtf-icnrg-ccninfo-02 == Outdated reference: A later version (-06) exists of draft-mastorakis-icnrg-icntraceroute-04 == Outdated reference: A later version (-07) exists of draft-moiseenko-icnrg-flowclass-04 == Outdated reference: A later version (-04) exists of draft-muscariello-intarea-hicn-02 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG D. Oran 3 Internet-Draft Network Systems Research and Design 4 Intended status: Informational August 9, 2019 5 Expires: February 10, 2020 7 Considerations in the development of a QoS Architecture for CCNx-like 8 ICN protocols 9 draft-oran-icnrg-qosarch-00 11 Abstract 13 This is a position paper. It documents the author's personal views 14 on how Quality of Service (QoS) capabilities ought to be accommodated 15 in ICN protocols like CCNx or NDN which employ flow-balanced 16 Interest/Data exchanges and hop-by-hop forwarding state as their 17 fundamental machinery. It argues that such protocols demand a 18 substantially different approach to QoS from that taken in TCP/IP, 19 and proposes specific design patterns to achieve both classification 20 and differentiated QoS treatment on both a flow and aggregate basis. 21 It also considers the effect of caches as a resource in addition to 22 memory, CPU and link bandwidth that should be subject to explicitly 23 un-fair resource allocation. The proposed methods are intended to 24 operate purely at the network layer, providing the primitives needed 25 to achieve both transport and higher layer QoS objectives. It 26 explicitly excludes any discussion of Quality of Experience (QoE) 27 which can only be assessed and controlled at the application layer or 28 above. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on February 10, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 66 3. Some background on the nature and properties of Quality of 67 Service in network protocols . . . . . . . . . . . . . . . . 4 68 3.1. Congestion Control basics relevant to ICN . . . . . . . . 5 69 4. What can we control to achieve QoS in ICN? . . . . . . . . . 6 70 5. How does this relate to QoS in TCP/IP? . . . . . . . . . . . 7 71 6. Why is ICN Different? Can we do Better? . . . . . . . . . . . 9 72 7. A strawman set of principles to guide QoS architecture for 73 ICN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 78 10.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 81 1. Introduction 83 The TCP/IP protocol suite used on today's Internet has over 30 years 84 of accumulated research and engineering into the provision of Quality 85 of Service machinery, employed with varying success in different 86 environments. ICN protocols like Named Data Networking (NDN [NDN]) 87 and Content-Centric Networking (CCNx [RFC8569],[RFC8609]) have an 88 accumulated 10 years of research and very little deployment. We 89 therefore have the opportunity to either recapitulate the approaches 90 take with TCP/IP (e.g. IntServ [RFC2998] and Diffserv [RFC2474]) or 91 design a new architecture and mechanisms aligned with the properties 92 of ICN protocols which differ substantially from those of TCP/IP. 93 This position paper advocates the latter approach and comprises the 94 author's personal views on how Quality of Service (QoS) capabilities 95 ought to be accommodated in ICN protocols like CCNx or NDN. 96 Specifically, these protocols differ in fundamental ways from TCP/IP. 97 These differences are summarized in the following table: 99 +---------------------------------+---------------------------------+ 100 | TCP/IP | CCNx or NDN | 101 +---------------------------------+---------------------------------+ 102 | Stateless forwarding | Stateful forwarding | 103 | Simple Packets | Object model with optional | 104 | | caching | 105 | Pure datagram model | Request-response model | 106 | Asymmetric Routing | Symmetric Routing | 107 | Independent flow directions | Flow balance | 108 | Flows grouped by IP prefix and | Flows grouped by name prefix | 109 | port | | 110 | End-to-end congestion control | Hop-by-hop congestion control | 111 +---------------------------------+---------------------------------+ 113 Table 1: Differences between IP and ICN relevant to QoS architecture 115 This document proposes specific design patterns to achieve both flow 116 classification and differentiated QoS treatment for ICN on both a 117 flow and aggregate basis. It also considers the effect of caches as 118 a resource in addition to memory, CPU and link bandwidth that should 119 be subject to explicitly un-fair resource allocation. The proposed 120 methods are intended to operate purely at the network layer, 121 providing the primitives needed to achieve both transport and higher 122 layer QoS objectives. It does not propose detailed protocol 123 machinery to achieve these goals; it leaves these to supplementary 124 specifications, such as [I-D.moiseenko-icnrg-flowclass]. It 125 explicitly excludes any discussion of Quality of Experience (QoE) 126 which can only be assessed and controlled at the application layer or 127 above. 129 Much of this document is derived from presentations the author has 130 given at ICNRG meetings over the last few years that available 131 through the IETF datatracker (see, for example [Oran2018QoSslides]). 133 2. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 3. Some background on the nature and properties of Quality of Service 140 in network protocols 142 Much of this background material is tutorial, and can be simply 143 skipped by readers familiar with the long and checkered history of 144 quality of service in packet networks. Other parts of it are 145 polemical yet serve to illuminate the author's personal biases and 146 technical views. 148 All networking systems provide some degree of "quality of service" in 149 that they exhibit non-zero utility when offered traffic to carry. 150 The term therefore is used to describe systems that control the 151 allocation of various resources in order to achieve _managed 152 unfairness_. Absent explicit mechanisms to decide what traffic to be 153 unfair to, most systems try to achieve some form of "fairness" in the 154 allocation of resources, optimizing the overall utility delivered to 155 all demand under the constraint of available resources. From this it 156 should be obvious that you cannot use QoS mechanisms to create or 157 otherwise increase resource capacity! In fact, all known QoS schemes 158 have non-zero overhead and hence may (albeit slightly) decrease to 159 total amount of resources available to carry user traffic. 161 Further, accumulated experience seems to indicate that QoS is helpful 162 in a fairly narrow range of network conditions: 164 o If your resources are lightly loaded, you don't need it, as 165 neither congestive loss nor substantial queueing delay occurs 167 o If your resources are heavily oversubscribed, it doesn't save you. 168 So many users will be unhappy that you are probably not delivering 169 a viable service 171 o Failures can rapidly shift your state from the first above to the 172 second, in which case either: 174 * your QoS machinery cannot respond quickly enough to maintain 175 the advertised service quality continuously, or 177 * resource allocations are sufficiently conservative to result in 178 substantial wasted capacity under non-failure conditions 180 Nevertheless, though not universally deployed, QoS is advantageous at 181 least for some applications and some network environments. Some 182 examples include: 184 o applications with steep utility functions [Shenker2006], such as 185 real-time multimedia 187 o applications with safety-critical operational constraints, such as 188 avionics or industrial automation 190 o dedicated or tightly managed networks whose economics depend on 191 strict adherence to challenging service level agreements (SLAs) 193 Another factor in the design and deployment of QoS is the scalability 194 and scope over which the desired service can be achieved. Here there 195 are two major considerations, one technical, the other economic/ 196 political: 198 o Some QoS signaled schemes, such as RSVP [RFC2205] maintain state 199 in routers for each flow, which scales linearly with the number of 200 flows. For core routers through which pass millions to billions 201 of flows, the memory required is infeasible to provide. 203 o The Internet is comprised of many minimally cooperating autonomous 204 systems [AS]. There are practically no successful examples of QoS 205 deployments crossing the AS boundaries of multiple service 206 providers. This in almost all cases limits the applicability of 207 QoS capabilities to be intra-domain. 209 Finally, the relationship between QoS and either accounting or 210 billing is murky. Some schemes can accurately account for resource 211 consumption and ascertain to which user to allocate the usage. 212 Others cannot. While the choice of mechanism may have important 213 practical economic and political consequences for cost and workable 214 business models, this document considers none of those things and 215 discusses QoS in the context of providing managed unfairness only. 217 Some further background on congestion control for ICN is below. 219 3.1. Congestion Control basics relevant to ICN 221 Congestion control is necessary in any packet network that 222 multiplexes traffic among multiple sources and destinations in order 223 to: 225 1. Prevent collapse of utility due to overload, where the total 226 offered service declines as load increases, perhaps 227 precipitously, rather than increasing or remaining flat. 229 2. Avoid starvation of some traffic due to excessive demand by other 230 traffic. 232 3. Beyond the basic protections against starvation, achieve 233 "fairness" among competing traffic. Two common objective 234 functions are [minmaxfairness] and [proportionalfairness] both of 235 which have been implemented and deployed successfully on packet 236 networks for many years. 238 Before moving on to QoS, it is useful to consider how congestion 239 control works in NDN or CCNx. Unlike the IP protocol family, which 240 relies on end-to-end congestion control (e.g. TCP[RFC0793], 241 DCCP[RFC4340], SCTP[RFC4960], QUIC[I-D.ietf-quic-transport]), CCNx 242 and NDN employ hop-by-hop congestion control. There is per-Interest/ 243 Data state at every hop of the path and therefore for each 244 outstanding Interest, bandwidth for data returning on the inverse 245 path can be allocated. In current designs, this allocation is often 246 done using Interest counting. By accepting one Interest packet from 247 a downstream node, implicitly this provides a guarantee (either hard 248 or soft) that there is sufficient bandwidth on the inverse direction 249 of the link to send back one Data packet. A number of congestion 250 control schemes have been developed for ICN that operate in this 251 fashion, for example [Wang2013], [Mahdian2016], [Song2018], 252 [Carofiglio2012]. Other schemes, like [Schneider2016] neither count 253 nor police interests, but instead monitor queues using AQM (active 254 queue management) to mark returning Data packets that have 255 experienced congestion. 257 4. What can we control to achieve QoS in ICN? 259 QoS is achieved through managed unfairness in the allocation of 260 resources in network elements, particularly routers doing forwarding 261 of ICN packets. So, a first order question is what resources need to 262 be allocated, and how to ascertain which traffic gets what 263 allocations. In the case of CCNx or NDN the important network 264 element resources are: 266 +-----------------------------+-------------------------------------+ 267 | Resource | ICN Usage | 268 +-----------------------------+-------------------------------------+ 269 | Communication Link capacity | buffering for queued packets | 270 | Content Store capacity | to hold cached data | 271 | Forwarder memory | for the Pending Interest Table | 272 | | (PIT) | 273 | Compute capacity | for forwarding packets, including | 274 | | the cost of Forwarding Information | 275 | | Base (FIB) lookups. | 276 +-----------------------------+-------------------------------------+ 278 Table 2: ICN-related Network Element Resources 280 For these resources, any QoS scheme has to specify two things: 282 1. How do you create _equivalence classes_ (a.k.a. flows) of traffic 283 to which different QoS treatments are applied? 285 2. What are the possible treatments and how are those mapped to the 286 resource allocation algorithms? 288 Two critical facts of life come into play when designing a QoS 289 scheme. First, the number of equivalence classes that can be 290 simultaneously tracked in a network element is bounded by both memory 291 and processing capacity to do the necessary lookups. One can allow 292 very fine-grained equivalence classes, but not be able to employ them 293 globally because of scaling limits of core routers. That means it is 294 wise to either restrict the range of equivalence classes, or allow 295 them to be _aggregated_, trading off accuracy in policing traffic 296 against ability to scale. 298 The second is how flexible is the set of treatments that are defined. 299 The ability to encode the treatment requests in the protocol can be 300 limited (as it is for IP - there are only 6 of the TOS bits available 301 for Diffserv treatments), but as or more important is whether there 302 are practical traffic policing, queuing, and pacing algorithms that 303 can be combined to support a rich set of QoS treatments. 305 The two considerations above in combination can easily be 306 substantially more expressive than can be achieved in practice with 307 the available number of queues on real network interfaces or the 308 amount of per-packet computation needed to enque or dequeue a packet. 310 5. How does this relate to QoS in TCP/IP? 312 TCP/IP has fewer resource types to manage than ICN, and in some cases 313 the allocation methods are simpler, as shown in the following table: 315 +-----------------------------+-------------+-----------------------+ 316 | Resource | IP Relevant | TCP/IP Usage | 317 +-----------------------------+-------------+-----------------------+ 318 | Communication Link capacity | YES | buffering for queued | 319 | | | packets | 320 | Content Store capacity | NO | no content store in | 321 | | | IP | 322 | Forwarder memory | MAYBE | not needed for | 323 | | | output-buffered | 324 | | | designs | 325 | Compute capacity | YES | for forwarding | 326 | | | packets, but arguably | 327 | | | much cheaper than ICN | 328 +-----------------------------+-------------+-----------------------+ 330 Table 3: IP-related Network Element Resources 332 For these resources, IP has specified three fundamental things, as 333 shown in the following table: 335 +----------------+--------------------------------------------------+ 336 | What | How | 337 +----------------+--------------------------------------------------+ 338 | *Equivalence | subset+prefix match on IP 5-tuple | 339 | classes* | {SA,DA,SP,DP,PT} | 340 | *Diffserv | (very) small number of globally-agreed traffic | 341 | treatments* | classes | 342 | *Intserv | per-flow parameterized _Controlled Load_ and | 343 | treatments* | _Guaranteed_ service classes | 344 +----------------+--------------------------------------------------+ 346 Table 4: Fundamental protocol elements to achieve QoS for TCP/IP 348 Equivalence classes for IP can be pairwise, by matching against both 349 source and destination address+port, pure group using only 350 destination address+port, or source-specific multicast with source 351 adress+port and destination multicast address+port. 353 With Intserv, the signaling protocol RSVP [RFC2205] carries two data 354 structures, the FLOWSPEC and the TSPEC. The former fulfills the 355 requirement to identify the equivalence class the QoS being signaled 356 applies to. The latter comprises the desired QoS treatment along 357 with a description of the dynamic character of the traffic (e.g. 358 average bandwidth and delay, peak bandwidth, etc.). Both of these 359 encounter substantial scaling limits, which has meant that Intserv 360 has historically been limited to confined topologies, and/or high- 361 value usages, like traffic engineering. 363 With Diffserv, the protocol encoding (6 bits in the TOS field of the 364 IP header) artificially limits the number of classes one can specify. 365 These are documented in [RFC4594]. Nonetheless, when used with fine- 366 grained equivalence classes, one still runs into limits on the number 367 of queues required. 369 6. Why is ICN Different? Can we do Better? 371 While one could adopt an approach to QoS mirroring the extensive 372 experience with TCP/IP, this would, in the author's view, be a 373 mistake. The implementation and deployment of QoS in IP networks has 374 been spotty at best. There are of course economic and political 375 reasons as well as technical reasons for these mixed results, but 376 there are several architectural choices in ICN that make it a 377 potentially much better protocol base to enhance with QoS machinery. 378 This section discusses those difference and their consequences. 380 First and foremost, hierarchical names are a much richer basis for 381 specifying equivalence classes than IP 5-tuples. The IP address (or 382 prefix) can only separate traffic by topology to the granularity of 383 hosts, and not express actual computational instances nor sets of 384 data. Ports give some degree of per-instance demultiplexing, but 385 this tends to be both coarse and ephemeral, while confounding the 386 demultiplexing function with the assignment of QoS treatments to 387 particular subsets of the data. Some degree of finer granularity is 388 possible with IPv6 by exploiting the ability to use up to 64 bits of 389 address for classifying traffic. In fact, the hICN project 390 ([I-D.muscariello-intarea-hicn]), while adopting the request-response 391 model of CCNx, uses IPv6 addresses as the available namespace, and 392 IPv6 packets (plus "fake" TCP headers) as the wire format. 394 Nonetheless, the flexibility of tokenized, variable length, 395 hierarchical names allows one to directly associate classes of 396 traffic for QoS purposes with the structure of an application 397 namespace. The classification can be as coarse or fine-grained as 398 desired by the application. While not _always_ the case, there is 399 typically a straightforward association between how objects are 400 named, and how they are grouped together for common treatment. 401 Examples abound; a number can be conveniently found in 402 [I-D.moiseenko-icnrg-flowclass]. 404 In ICN, QoS is not pre-bound to topology since names are non- 405 topological, unlike unicast IP addresses. This allows QoS to be 406 applied to multi-destination and multi-path environments in a 407 straightforward manner, rather than requiring either multicast with 408 coarse class-based scheduling or complex signaling like that in RSVP- 409 TE [RFC3209] that is needed to make point-to-multipoint MPLS work. 411 Because of IP's stateless forwarding model, complicated by the 412 ubiquity of asymmetric routes, any flow-based QoS requires state that 413 is decoupled from the actual arrival of traffic and hence must be 414 maintained, at least as soft-state, even during quiescent periods. 415 Intserv, for example, requires flow signaling with state O(#flows). 416 ICN, even worst case, requires state O(#active interest/data 417 exchanges), since state can be instantiated on arrival of an 418 Interest, and removed lazily once the data hase been returned. 420 Unlike Intserv, Difserv eschews signaling in favor of class-based 421 configuration of resources and queues in network elements. However, 422 Diffserv limits traffic treatments to a few bits taken from the ToS 423 field of IP. No such wire encoding limitations exist for NDN or 424 CCNx, as the protocol is completely TLV-based, and one (or even more 425 than one) new field can be easily defined to carry QoS treatment 426 information. 428 Therefore, there are greenfield possibilities for more powerful QoS 429 treatment options in ICN. For example, IP has no way to express a 430 QoS treatment like "try hard to deliver reliably, even at the expense 431 of delay or bandwidth". Such a QoS treatment for ICN could invoke 432 native ICN mechanisms, none of which are present in IP, such as: 434 o In-network retransmission in response to hop-by-hop errors 435 returned from upstream forwarders 437 o Trying multiple paths to multiple content sources either in 438 parallel or serially 440 o Higher precedence for short-term caching to recover from 441 downstream errors 443 Such mechanisms are typically described in NDN and CCNx as 444 _forwarding strategies_. However, little or no guidance is given for 445 what application actions or protocol machinery is used to decide 446 which forwarding strategy to use for which Interests that arrive at a 447 forwarder. See [BenAbraham2018] for an investigation of these 448 issues. Associating forwarding strategies with the equivalence 449 classes and QoS treatments directly can make them more accessible and 450 useful to implement and deploy. 452 IP has three forwarding semantics, with different QoS needs (Unicast, 453 Anycast, Multicast). ICN has the single forwarding semantic, so any 454 QoS machinery can be uniformly applied across any request/response 455 invocation, whether it employs dynamic destination routing, multi- 456 destination parallel requests, or even localized flooding (e.g. 457 directly on L2 multicast mechanisms). Additionally, the pull-based 458 model of ICN avoids a number of thorny multicast QoS problems that IP 459 has ([Wang2000], [RFC3170], [Tseng2003]). 461 The Multi-destination/multi-path forwarding model in ICN changes 462 resource allocation needs in a fairly deep way. IP treats all 463 endpoints as open-loop packet sources, whereas NDN and CCNx have 464 strong asymmetry between producers and consumers as packet sources. 466 IP has no caching in routers, whereas ICN needs ways to allocate 467 cache resources. Treatments to control caching operation are 468 unlikely to look much like the treatments used to control link 469 resources. NDN and CCNx already have useful cache control directives 470 associated with Data messages. The CCNx controls include 472 ExpiryTime time after which a cached Content Object is considered 473 expired and MUST no longer be used to respond to an Interest from 474 a cache. 476 Recommended Cache Time time after which the publisher considers the 477 Content Object to be of low value to cache. 479 (See [RFC8569] for the formal definitions) 481 ICN flow classifiers, such as those in 482 [I-D.moiseenko-icnrg-flowclass] can be used to achieve soft or hard 483 partitioning of cache resources in the content store of an ICN 484 forwarder. For example, cached content for a given equivalence class 485 can be considered _fate shared_ in a cache whereby objects from the 486 same equivalence class are purged as a group rather than 487 individually. This can recover cache space more quickly and at lower 488 overhead than pure per-object replacement. In addition, since the 489 forwarder remembers the QoS treatment for each pending Interest in 490 its PIT, the above cache controls can be augmented by policy to 491 prefer retention of cached content for some equivalence classes as 492 part of the cache replacement algorithm. 494 Stateless forwarding and asymmetric routing in IP limits available 495 state/feedback to manage link resources. In contrast, NDN or CCNx 496 forwarding allows all link resource allocation to occur as part of 497 Interest forwarding, potentially simplifying things considerably. 498 For example, with symmetric routing, producers have no control over 499 the paths their data packets traverse, and hence any QoS treatments 500 intended to affect routing paths will have no effect. 502 7. A strawman set of principles to guide QoS architecture for ICN 504 Based on the observations made in the earlier sections, this summary 505 section captures the author's ideas for clear and actionable 506 architectural principals for how to incorporate QoS machinery into 507 ICN protocols like NDN and CCNx. Hopefully, they can guide further 508 work and focus effort on portions of the giant design space for QoS 509 that have the best tradeoffs in terms of flexibility, simplicity, and 510 deployability. 512 *Define equivalence classes using the name hierarchy rather than 513 creating an independent traffic class definition*. This directly 514 associates the specification of equivalence classes of traffic with 515 the structure of the application namespace. It can allow 516 hierarchical decomposition of equivalence classes in a natural way 517 because of the way hierarchical ICN names are constructed. Two 518 practical mechanisms are presented in [I-D.moiseenko-icnrg-flowclass] 519 with different tradeoffs between security and the ability to 520 aggregate flows. Either prefix-based (EC3) or explicit name 521 component based (ECNT) or both could be adopted as the part of the 522 QoS architecture for defining equivalence classes. 524 *Put consumers in control of Link and Forwarding resource 525 allocation*. Do _all_ link buffering and forwarding (both memory and 526 CPU) resource allocations based on Interest arrivals. This is 527 attractive because it provides early congestion feedback to 528 consumers, and allows scheduling the reverse link direction ahead of 529 time for carrying the matching data. This makes enforcement of QoS 530 treatments a single-ended rather than a double-ended problem and can 531 avoid wasting resources on fetching data that will wind up dropped 532 when it arrives at a bottleneck link. 534 *Put producers in control of cache resources*. Consumers don't care 535 if anything is cached, at least not directly. Producers want to 536 reduce their load and serve consumers with fewest resources. Use the 537 same equivalence class mechanism for cache resource partitioning and 538 as a means to fate share cache entries if desired. 540 *Re-think how to specify traffic treatments - don't just copy 541 Diffserv*. Some of the Diffserv classes may form a good starting 542 point, as their mapping onto queuing algorithms for managing link 543 buffering are well understood. However, Diffserv alone does not 544 allow one to express latency versus reliability tradeoffs or other 545 useful QoS treatments. Nor does it permit "TSPEC"-style traffic 546 descriptions as are allowed in a signaled QoS scheme (despite neither 547 having nor needing a separate signaling protocol given the state 548 carried in the ICN data plane by forwarders). Here are some 549 examples: 551 o A "burst" treatment, where an initial Interest gives an aggregate 552 data size to request allocation of link capacity for a large burst 553 of Interest/Data exchanges. The Interest can be rejected at any 554 hop if the resources are not available. Such a treatment can also 555 accomodate Data implosion produced by the discovery procedures of 556 management protocols like [I-D.irtf-icnrg-ccninfo]. 558 o A "reliable" treatment, which affects preference for allocation of 559 PIT space for the Interest and Content Store space for the data in 560 order to improve the robustness of IoT data delivery in 561 constrained environment, as is described in 562 [I-D.gundogan-icnrg-iotqos]. 564 o A "search" treatment, which, within the specified Interest 565 Lifetime, tries many paths either in parallel or serial to 566 potentially many content sources, to maximize the probability that 567 the requested item will be found. This is done at the expense of 568 the extra bandwidth of both forwarding Interests and receiving 569 multiple responses upstream of an aggregation point. The 570 treatment can encode a value expressing tradeoffs like breadth- 571 first versus depth-first search, and bounds on the total resource 572 expenditure. Such a treatment would be useful for instrumentation 573 protocols like [I-D.mastorakis-icnrg-icntraceroute]. 575 As an aside, loose latency control can be achieved by bounding 576 Interest Lifetime as long as it is not also used as an application 577 mechanism to provide subscriptions or establish path traces for 578 producer mobility. See [Krol2018] for a discussion of the network 579 versus application timescale issues in ICN protocols. 581 8. IANA Considerations 583 This document does not require any IANA actions 585 9. Security Considerations 587 There are a few ways in which QoS for ICN interacts with security and 588 privacy issues. Since QoS addresses relationships among traffic 589 rather than the inherent characteristics of traffic, it neither 590 enhances nor deteriorates the security and privacy properties of the 591 data being carried, as long as the machinery does not alter or 592 otherwise compromise the basic security properties of the associated 593 protocols. The QoS approaches advocated here for ICN can serve to 594 amplify existing threats to network traffic however: 596 o An attacker able to manipulate the QoS treatments of traffic can 597 mount a more focused (and potentially more effective) denial of 598 service attack by suppressing performance on traffic the attacker 599 is targeting. Since the architcture here assumes QoS treatments 600 are manipulable hop-by-hop, any on-path adversary can wreak havoc. 601 Note however, that in basic ICN, and on-path attacker can do this 602 and more by dropping, delaying, or mis-routing traffic independent 603 of any particular QoS machinery in use. 605 o By explicitly revealing equivalence classes of traffic via either 606 names or other fields in packets, an attacker has yet one more 607 handle to use to discover linkability of multiple requests. 609 10. References 611 10.1. Normative References 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, 615 DOI 10.17487/RFC2119, March 1997, 616 . 618 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 619 Networking (CCNx) Semantics", RFC 8569, 620 DOI 10.17487/RFC8569, July 2019, 621 . 623 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 624 Networking (CCNx) Messages in TLV Format", RFC 8609, 625 DOI 10.17487/RFC8609, July 2019, 626 . 628 10.2. Informative References 630 [AS] "Autonomous System (Internet)", no date, 631 . 634 [BenAbraham2018] 635 Ben Abraham, H., Parwatikar, J., DeHart, J., Dresher, A., 636 and P. Crowley, "Decoupling Information and Connectivity 637 via Information-Centric Transport, in 5th ACM Conference 638 on Information-Centric Networking (ICN '18), September 639 21-23, 2018, Boston, MA, USA", 640 DOI 10.1145/3267955.3267963, September 2018, 641 . 644 [Carofiglio2012] 645 Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop- 646 by-hop and receiver-driven interest control protocol for 647 content-centric networks, in ICN Workshop at SIGcomm 648 2012", DOI 10.1145/2377677.2377772, 2102, 649 . 652 [I-D.gundogan-icnrg-iotqos] 653 Gundogan, C., Schmidt, T., Waehlisch, M., Frey, M., Shzu- 654 Juraschek, F., and J. Pfender, "Quality of Service for ICN 655 in the IoT", draft-gundogan-icnrg-iotqos-01 (work in 656 progress), July 2019. 658 [I-D.ietf-quic-transport] 659 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 660 and Secure Transport", draft-ietf-quic-transport-22 (work 661 in progress), July 2019. 663 [I-D.irtf-icnrg-ccninfo] 664 Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering 665 Content and Network Information in Content-Centric 666 Networks", draft-irtf-icnrg-ccninfo-02 (work in progress), 667 July 2019. 669 [I-D.mastorakis-icnrg-icntraceroute] 670 Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and 671 D. Oran, "ICN Traceroute Protocol Specification", draft- 672 mastorakis-icnrg-icntraceroute-04 (work in progress), 673 February 2019. 675 [I-D.moiseenko-icnrg-flowclass] 676 Moiseenko, I. and D. Oran, "Flow Classification in 677 Information Centric Networking", draft-moiseenko-icnrg- 678 flowclass-04 (work in progress), July 2019. 680 [I-D.muscariello-intarea-hicn] 681 Muscariello, L., Carofiglio, G., Auge, J., and M. 682 Papalini, "Hybrid Information-Centric Networking", draft- 683 muscariello-intarea-hicn-02 (work in progress), June 2019. 685 [Krol2018] 686 Krol, M., Habak, K., Oran, D., Kutscher, D., and I. 687 Psaras, "RICE: Remote Method Invocation in ICN, in 688 Proceedings of the 5th ACM Conference on Information- 689 Centric Networking - ICN '18", 690 DOI 10.1145/3267955.3267956, September 2018, 691 . 694 [Mahdian2016] 695 Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, 696 "MIRCC: Multipath-aware ICN Rate-based Congestion Control, 697 in Proceedings of the 3rd ACM Conference on Information- 698 Centric Networking", DOI 10.1145/2984356.2984365, 2016, 699 . 702 [minmaxfairness] 703 "Max-min Fairness", no date, 704 . 706 [NDN] "Named Data Networking", various, 707 . 709 [Oran2018QoSslides] 710 Oran, D., "Thoughts on Quality of Service for NDN/CCN- 711 style ICN protocol architectures, presented at ICNRG 712 Interim Meeting, Cambridge MA", September 2018, 713 . 717 [proportionalfairness] 718 "Proportionally Fair", no date, 719 . 721 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 722 RFC 793, DOI 10.17487/RFC0793, September 1981, 723 . 725 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 726 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 727 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 728 September 1997, . 730 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 731 "Definition of the Differentiated Services Field (DS 732 Field) in the IPv4 and IPv6 Headers", RFC 2474, 733 DOI 10.17487/RFC2474, December 1998, 734 . 736 [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., 737 Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. 738 Felstaine, "A Framework for Integrated Services Operation 739 over Diffserv Networks", RFC 2998, DOI 10.17487/RFC2998, 740 November 2000, . 742 [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: 743 Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, 744 September 2001, . 746 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 747 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 748 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 749 . 751 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 752 Congestion Control Protocol (DCCP)", RFC 4340, 753 DOI 10.17487/RFC4340, March 2006, 754 . 756 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 757 Guidelines for DiffServ Service Classes", RFC 4594, 758 DOI 10.17487/RFC4594, August 2006, 759 . 761 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 762 RFC 4960, DOI 10.17487/RFC4960, September 2007, 763 . 765 [Schneider2016] 766 Schneider, K., Yi, C., Zhang, B., and L. Zhang, "A 767 Practical Congestion Control Scheme for Named Data 768 Networking, in Proceedings of the 2016 conference on 3rd 769 ACM Conference on Information-Centric Networking - ACM-ICN 770 '16", DOI 10.1145/2984356.2984369, 2016, 771 . 774 [Shenker2006] 775 Shenker, S., "Fundamental Design Issues for the Future 776 Internet, in IEEE Journal on Selected Areas in 777 Communications", DOI 10.1109/49.414637, 2006, 778 . 780 [Song2018] 781 Song, J., Lee, M., and T. Kwon, "SMIC: Subflow-level 782 Multi-path Interest Control for Information Centric 783 Networking, in 5th ACM Conference on Information-Centric 784 Networking", DOI 10.1145/3267955.3267971, 2018, 785 . 788 [Tseng2003] 789 Tseng, CH., "The performance of QoS-aware IP multicast 790 routing protocols, in Networks, Vol:42, No:2", 791 DOI 10.1002/net.10084, September 2003, 792 . 795 [Wang2000] 796 Wang, B. and J. Hou, "Multicast routing and its QoS 797 extension: problems, algorithms, and protocols, in IEEE 798 Network, Vol:14, No:1", DOI 10.1109/65.819168, Jan/Feb 799 2000, . 802 [Wang2013] 803 Wang, Y., Rozhnova, N., Narayanan, A., Oran, D., and I. 804 Rhee, "An Improved Hop-by-hop Interest Shaper for 805 Congestion Control in Named Data Networking, in ACM 806 SIGCOMM Workshop on Information-Centric Networking", 807 DOI 10.1145/2534169.2491233, 2013, 808 . 811 Author's Address 813 Dave Oran 814 Network Systems Research and Design 815 4 Shady Hill Square 816 Cambridge, MA 02138 817 USA 819 Email: daveoran@orandom.net