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