idnits 2.17.1 draft-gundogan-icnrg-iotqos-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 date (March 28, 2019) is 1850 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.moiseenko-icnrg-flowclass' is defined on line 337, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group C. Gundogan 3 Internet-Draft TC. Schmidt 4 Intended status: Experimental HAW Hamburg 5 Expires: September 29, 2019 M. Waehlisch 6 link-lab & FU Berlin 7 M. Frey 8 F. Shzu-Juraschek 9 Safety IO 10 J. Pfender 11 VUW 12 March 28, 2019 14 Quality of Service for ICN in the IoT 15 draft-gundogan-icnrg-iotqos-00 17 Abstract 19 This document describes manageable resources in ICN IoT deployments 20 and a lightweight traffic classification method for mapping 21 priorities to resources. Management methods are further derived for 22 controlling latency and reliability of traffic flows in constrained 23 environments. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 29, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Manageable Resources in the IoT . . . . . . . . . . . . . . . 3 59 3.1. Link Layer . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Pending Interest Table . . . . . . . . . . . . . . . . . 4 61 3.3. Content Store . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Traffic Flow Classification . . . . . . . . . . . . . . . . . 4 63 5. Priority Handling . . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Link Layer . . . . . . . . . . . . . . . . . . . . . . . 5 65 5.2. Pending Interest Table . . . . . . . . . . . . . . . . . 5 66 5.3. Content Store . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 8. Informative References . . . . . . . . . . . . . . . . . . . 6 70 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 The performance of networked systems is largely determined by the 76 resources available for forwarding messages between components. In 77 addition to link capacities and buffer queues, Information-centric 78 Networks rely on additional resources that shape its overall 79 performance, namely Pending Interest Table space, and caching 80 capacity. 82 Typical IoT deployments add tight resource constraints to this 83 picture [RFC7228]: Nodes have processing and memory limitations, the 84 underlying link layer technologies are lossy and restricted in 85 bandwidth. Particularly in multi-hop networks, such constraints 86 affect the overall performance, create bottlenecks, but may lead to 87 cascading packet loss or energy depletion when PIT resources are 88 independently evicted and forwarding states decorrelate 89 [DECORRELATION]. Overprovisioning to counter performance flaws is 90 infeasible for many IoT scenarios as it inflicts with use cases and 91 increases deployment costs. Quality of Service (QoS) is a method to 92 enhance overall performance by redistributing resources to a subset 93 of messages, and - in the constrained IoT use case - to coordinate 94 operations under resource scarcity. 96 IoT applications follow various use cases, of which different QoS 97 requirements can be derived. While periodic sensor readings often 98 comply with unmanaged performance, industrial control messaging or 99 security alerts require (very) low latency, and safety-critical 100 environmental recording or network management need (highly) reliable 101 network services. Both quality levels can only be assured by 102 appropriate resource reservations. 104 In order to achieve a QoS-aware information-centric IoT deployment, 105 this document describes manageable resources in Section 3, defines a 106 flow classification method in Section 4, and specifies priorities and 107 their mappings in Section 5. 109 2. 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 RFC 2119 [RFC2119]. 114 The use of the term, "silently ignore" is not defined in RFC 2119. 115 However, the term is used in this document and can be similarly 116 construed. 118 This document uses the terminology of [RFC7476], [RFC7927], and 119 [RFC7945] for ICN entities. 121 The following terms are used in the document and defined as follows: 123 Traffic Flow A traffic flow is a sequence of messages (Interest and 124 data) that belong to one specific communication 125 context. Due to in-network caching, ICN flows may be 126 delocalized. A flow may also relate to several 127 requesters in the presence of Interest aggregation. 129 3. Manageable Resources in the IoT 131 The following resources contribute to the overall network performance 132 in Information-Centric IoT Networking and need management for QoS 133 control. 135 3.1. Link Layer 137 The link layer manages access to the media and provides space to 138 buffer packets. Low latency applications require that requests are 139 prioritized compared to regular priority data. Based on the request 140 response pattern of ICN, link layer resources can be preallocated for 141 data packets. 143 3.2. Pending Interest Table 145 The Pending Interest Table (PIT) stores open requests at each hop. 146 PIT resources are allocated when requests are forwarded, and they are 147 released on returning responses. 149 Placement and replacement strategies of PIT entries directly 150 influence the latency and reliability properties of traffic flows and 151 thus should consider prioritization schemes. If the PIT is not 152 saturated new PIT entries can be added. If the PIT is saturated, 153 requests with higher priority should replace requests with lower 154 priority to prevent higher latencies due to retransmissions. 156 3.3. Content Store 158 Content stores (CS) enable transparent in-network caching and thus 159 improve the transport in wireless and lossy environments by reducing 160 hop traversals for content requests [NDN-EXP]. 162 Placement and replacement strategies of data in content stores can 163 affect the latency and reliability properties of traffic flows. The 164 latency can be reduced by placing data closer to the consumers. 165 Reliability can be improved by replicating data in multiple content 166 stores to be resilient to node failures. 168 4. Traffic Flow Classification 170 This document defines a traffic flow classification mechanism that 171 aggregates names into equivalence classes in order to apply resource 172 allocation decisions on messages of particular traffic flows. 174 A traffic class is a name prefix and each device maintains a list of 175 valid classes. The actual distribution of traffic classes is out of 176 scope of this document. The classes for request and response 177 messages are derived by performing a longest prefix match (LPM) with 178 the list of valid traffic classes and the Name TLV of the message. 179 Examples are given in Figure 1. 181 list = 182 ["/org", "/org /Hamburg", "/org /Berlin", "/org /Berlin /sensor" ] 184 LPM("/com" ,list) = "" 185 LPM("/org /Germany" ,list) = "/org" 186 LPM("/org /Hamburg" ,list) = "/org /Hamburg" 187 LPM("/org /Berlin /sensor /temp",list) = "/org /Berlin /sensor" 189 Figure 1: Example traffic flow class matches. 191 The empty traffic class "" is the default class for messages that do 192 not match any valid traffic classes in the class list. 194 5. Priority Handling 196 We define two priority levels to set the priorities for traffic flows 197 in regards to latency and reliability. 199 o Latency: 201 * EXPEDITED 203 * REGULAR 205 o Reliability: 207 * RELIABLE 209 * REGULAR 211 Each list entry of the traffic class list from Section 4 has an 212 associated priority tuple which distinctly specifies priority levels 213 for the resources in Section 3. The tuple is of the following form: 215 priority tuple = < LATENCY_PRIORITY, RELIABILITY_PRIORITY > 217 Figure 2: Schema of the priority tuple. 219 5.1. Link Layer 221 As described above, the link layer provides space to buffer outgoing 222 packets. For the two latency priorities, this space can be allocated 223 into the following two queues: 225 o EXPEDITED_FORWARDING_QUEUE 227 o REGULAR_FORWARDING_QUEUE 229 Packets will be appended to the queue corresponding to their priority 230 level. 232 5.2. Pending Interest Table 234 In unsatured PITs, requests are added as new entries regardless of 235 the priority level. In saturated PITs, EXPEDITED traffic replaces 236 PIT entries of REGULAR traffic. If all entries in a saturated PIT 237 are of a higher priority than the incoming request, then we RECOMMEND 238 to drop the incoming request. If a saturated PIT contains entries of 239 the same priority as the incoming request, we RECOMMEND to drop the 240 incoming request to avoid cancelling active but incomplete ICN 241 operations. 243 5.3. Content Store 245 Nodes MAY implement a caching decision strategy instead of always 246 caching all incoming content objects [ICN-CACHING]. If they do, the 247 caching decision strategy MUST take the content object priority into 248 account, such that lower priority content is not cached if the cache 249 is saturated with higher priority content. 251 In unsaturated content stores, all content objects are passed to the 252 cache decision strategy. 254 In saturated content stores, reliable traffic flows MUST be passed to 255 the cache replacement strategy. Content objects with regular 256 reliability requirements MUST be evicted first to make room for 257 higher reliability content objects. Traffic flows with regular 258 latency and regular reliability requirements MUST be passed to the 259 cache replacement strategy. The cache replacement strategy MUST NOT 260 evict content objects of higher reliability. Expedited traffic flows 261 with regular reliability MUST be passed to the cache replacement 262 strategy. Content objects with regular latency and regular 263 reliability requirements MUST be evicted first, if an open PIT state 264 is available. Otherwise, if no PIT state is available, then the 265 cache replacement strategy MAY replace content objects of expedited 266 or regular latency requirements and with regular reliability 267 requirements. 269 6. Security Considerations 271 TODO 273 7. IANA Considerations 275 TODO 277 8. Informative References 279 [DECORRELATION] 280 Waehlisch, M., Schmidt, TC., and M. Vahlenkamp, 281 "Backscatter from the Data Plane - Threats to Stability 282 and Security in Information-Centric Network 283 Infrastructure", Computer Networks Vol 57, No. 16, pp. 284 3192-3206, November 2013. 286 [I-D.moiseenko-icnrg-flowclass] 287 Moiseenko, I. and D. Oran, "Flow Classification in 288 Information Centric Networking", draft-moiseenko-icnrg- 289 flowclass-03 (work in progress), January 2019. 291 [ICN-CACHING] 292 Chai, W., He, D., Psaras, I., and G. Pavlou, "Cache 'Less 293 for More' in Information-Centric Networks (Extended 294 Version)", Computer Communications 36, 7 (2013) pp. 295 758-770, February 2013, . 297 [NDN-EXP] Gundogan, C., Kietzmann, P., Lenders, M., Petersen, H., 298 Schmidt, TC., and M. Waehlisch, "NDN, CoAP, and MQTT: A 299 Comparative Measurement Study in the IoT", Proc. of 5th 300 ACM Conf. on Information-Centric Networking (ICN-2018) ACM 301 DL, pp. , September 2018, . 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, 305 DOI 10.17487/RFC2119, March 1997, 306 . 308 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 309 Constrained-Node Networks", RFC 7228, 310 DOI 10.17487/RFC7228, May 2014, 311 . 313 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 314 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 315 "Information-Centric Networking: Baseline Scenarios", 316 RFC 7476, DOI 10.17487/RFC7476, March 2015, 317 . 319 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 320 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 321 "Information-Centric Networking (ICN) Research 322 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 323 . 325 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 326 and G. Boggia, "Information-Centric Networking: Evaluation 327 and Security Considerations", RFC 7945, 328 DOI 10.17487/RFC7945, September 2016, 329 . 331 Acknowledgments 333 This work was stimulated by fruitful discussions in the ICNRG 334 research group. We would like to thank all active members for 335 constructive thoughts and feedback. In particular, the authors would 336 like to thank Ilya Moiseenko and Dave Oran for their work provided in 337 [I-D.moiseenko-icnrg-flowclass]. This work was supported in part by 338 the German Federal Ministry of Research and Education within the I3 339 project. 341 Authors' Addresses 343 Cenk Gundogan 344 HAW Hamburg 345 Berliner Tor 7 346 Hamburg D-20099 347 Germany 349 Phone: +4940428758067 350 EMail: cenk.guendogan@haw-hamburg.de 351 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 353 Thomas C. Schmidt 354 HAW Hamburg 355 Berliner Tor 7 356 Hamburg D-20099 357 Germany 359 EMail: t.schmidt@haw-hamburg.de 360 URI: http://inet.haw-hamburg.de/members/schmidt 362 Matthias Waehlisch 363 link-lab & FU Berlin 364 Hoenower Str. 35 365 Berlin D-10318 366 Germany 368 EMail: mw@link-lab.net 369 URI: http://www.inf.fu-berlin.de/~waehl 370 Michael Frey 371 Safety IO 372 Franz-Ehrlich-Strasse 9 373 Berlin D-12489 374 Germany 376 EMail: michael.frey@safetyio.com 378 Felix Shzu-Juraschek 379 Safety IO 380 Franz-Ehrlich-Strasse 9 381 Berlin D-12489 382 Germany 384 EMail: felix.juraschek@safetyio.com 386 Jakob Pfender 387 Victoria University of Wellington 388 Kelburn Parade 389 Wellington NZ-6012 390 New Zealand 392 EMail: jpfender@ecs.vuw.ac.nz 393 URI: https://ecs.victoria.ac.nz/Main/GradJakobPfender