< draft-gundogan-icnrg-iotqos-00.txt   draft-gundogan-icnrg-iotqos-01.txt >
ICN Research Group C. Gundogan ICN Research Group C. Gundogan
Internet-Draft TC. Schmidt Internet-Draft TC. Schmidt
Intended status: Experimental HAW Hamburg Intended status: Experimental HAW Hamburg
Expires: September 29, 2019 M. Waehlisch Expires: January 9, 2020 M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
M. Frey M. Frey
F. Shzu-Juraschek F. Shzu-Juraschek
Safety IO Safety IO
J. Pfender J. Pfender
VUW VUW
March 28, 2019 July 8, 2019
Quality of Service for ICN in the IoT Quality of Service for ICN in the IoT
draft-gundogan-icnrg-iotqos-00 draft-gundogan-icnrg-iotqos-01
Abstract Abstract
This document describes manageable resources in ICN IoT deployments This document describes manageable resources in ICN IoT deployments
and a lightweight traffic classification method for mapping and a lightweight traffic classification method for mapping
priorities to resources. Management methods are further derived for priorities to resources. Management methods are further derived for
controlling latency and reliability of traffic flows in constrained controlling latency and reliability of traffic flows in constrained
environments. environments. This work includes a distributed management of the
heterogeneous resources (i) forwarding capacities, (ii) Pending
Interest Table (PIT) space, and (iii) in-network data storage. By
correlating these common ICN resources, performance measures can be
optimized without sacrificing concurrent traffic demands. Different
from the IP world, QoS in ICN can be benifical for all participants
and manage 'quality instead of unfairness'.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 29, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Manageable Resources in the IoT . . . . . . . . . . . . . . . 3 3. Manageable Resources in the IoT . . . . . . . . . . . . . . . 3
3.1. Link Layer . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Link Layer . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Pending Interest Table . . . . . . . . . . . . . . . . . 4 3.2. Pending Interest Table . . . . . . . . . . . . . . . . . 4
3.3. Content Store . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Content Store . . . . . . . . . . . . . . . . . . . . . . 4
4. Traffic Flow Classification . . . . . . . . . . . . . . . . . 4 4. Traffic Flow Classification . . . . . . . . . . . . . . . . . 4
5. Priority Handling . . . . . . . . . . . . . . . . . . . . . . 5 5. Priority Handling . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Link Layer . . . . . . . . . . . . . . . . . . . . . . . 5 6. Distributed QoS Management . . . . . . . . . . . . . . . . . 5
5.2. Pending Interest Table . . . . . . . . . . . . . . . . . 5 6.1. Locally Isolated Decisions . . . . . . . . . . . . . . . 6
5.3. Content Store . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Local Resource Correlations . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6.3. Distributed Resource Coordination . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Implementation Report and Guidance . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The performance of networked systems is largely determined by the The performance of networked systems is largely determined by the
resources available for forwarding messages between components. In resources available for forwarding messages between components. In
addition to link capacities and buffer queues, Information-centric addition to link capacities and buffer queues, Information-centric
Networks rely on additional resources that shape its overall Networks rely on additional resources that shape its overall
performance, namely Pending Interest Table space, and caching performance, namely Pending Interest Table space, and caching
capacity. capacity.
skipping to change at page 5, line 15 skipping to change at page 5, line 25
The empty traffic class "" is the default class for messages that do The empty traffic class "" is the default class for messages that do
not match any valid traffic classes in the class list. not match any valid traffic classes in the class list.
5. Priority Handling 5. Priority Handling
We define two priority levels to set the priorities for traffic flows We define two priority levels to set the priorities for traffic flows
in regards to latency and reliability. in regards to latency and reliability.
o Latency: o Latency:
* EXPEDITED * PROMPT
* REGULAR * REGULAR
o Reliability: o Reliability:
* RELIABLE * RELIABLE
* REGULAR * REGULAR
Each list entry of the traffic class list from Section 4 has an Each list entry of the traffic class list from Section 4 has an
associated priority tuple which distinctly specifies priority levels associated priority tuple which distinctly specifies priority levels
for the resources in Section 3. The tuple is of the following form: for the resources in Section 3. The tuple is of the following form:
priority tuple = < LATENCY_PRIORITY, RELIABILITY_PRIORITY > priority tuple = < LATENCY_PRIORITY, RELIABILITY_PRIORITY >
Figure 2: Schema of the priority tuple. Figure 2: Schema of the priority tuple.
5.1. Link Layer 6. Distributed QoS Management
As described above, the link layer provides space to buffer outgoing The mechanisms used to achieve QoS management is divided into three
packets. For the two latency priorities, this space can be allocated classes, depending on the level of interdependency exhibited between
into the following two queues: mechanisms on the same device or between devices.
o EXPEDITED_FORWARDING_QUEUE 6.1. Locally Isolated Decisions
o REGULAR_FORWARDING_QUEUE This class includes decisions that have no interaction with other
mechanisms on the local or other devices.
Packets will be appended to the queue corresponding to their priority Prioritized Forwarding:
level. As described above, the link layer provides space to buffer
outgoing packets. For the two latency priorities, this space can
be allocated into the following two queues:
5.2. Pending Interest Table * PROMPT_FORWARDING_QUEUE
In unsatured PITs, requests are added as new entries regardless of * REGULAR_FORWARDING_QUEUE
the priority level. In saturated PITs, EXPEDITED traffic replaces
PIT entries of REGULAR traffic. If all entries in a saturated PIT
are of a higher priority than the incoming request, then we RECOMMEND
to drop the incoming request. If a saturated PIT contains entries of
the same priority as the incoming request, we RECOMMEND to drop the
incoming request to avoid cancelling active but incomplete ICN
operations.
5.3. Content Store Packets will be appended to the queue corresponding to their
priority level.
Nodes MAY implement a caching decision strategy instead of always Caching Decisions:
caching all incoming content objects [ICN-CACHING]. If they do, the The decisions to cache content obey the priority order "reliable"
caching decision strategy MUST take the content object priority into to "regular". In the presence of probabilistic caching
account, such that lower priority content is not cached if the cache strategies, the weights are set accordingly.
is saturated with higher priority content.
In unsaturated content stores, all content objects are passed to the PIT Management:
cache decision strategy. For saturated PITs, the management operates in favor of rapid
packet forwarding, so "prompt" Interests replace "regular"
Interests. Newly arriving Interests that meet a PIT with
saturated entries of equal or higher priority are dropped.
In saturated content stores, reliable traffic flows MUST be passed to 6.2. Local Resource Correlations
the cache replacement strategy. Content objects with regular
reliability requirements MUST be evicted first to make room for
higher reliability content objects. Traffic flows with regular
latency and regular reliability requirements MUST be passed to the
cache replacement strategy. The cache replacement strategy MUST NOT
evict content objects of higher reliability. Expedited traffic flows
with regular reliability MUST be passed to the cache replacement
strategy. Content objects with regular latency and regular
reliability requirements MUST be evicted first, if an open PIT state
is available. Otherwise, if no PIT state is available, then the
cache replacement strategy MAY replace content objects of expedited
or regular latency requirements and with regular reliability
requirements.
6. Security Considerations These are decisions that entail interaction between mechanisms on the
same device (intra-device correlations). This includes the
correlation between the caching decision and cache replacement
strategies.
o If arriving Data meets a valid PIT entry, Data is forwarded
according to priorities. "Reliable" Data is cached with priority.
In the case of exhausted prioritized forwarding queues, "prompt"
traffic is cached with the highest priority, because Interest
retransmissions are likely to occur.
o If arriving Data meets no valid PIT entry, caching follows the
order "prompt" (highest) to "regular" (lowest). For probabilistic
caching, weights are adjusted correspondingly.
6.3. Distributed Resource Coordination
These decisions affect resources across multiple or all devices in
the network (inter-device correlations). These include maintaining
PIT coherence by ensuring that all nodes apply uniform QoS mechanisms
when replacing content of different service classes, as well as
achieving CS diversity by introducing probabilistic caching based on
priority classes. In this document, distributed coordination is
achieved as follows:
PIT Coherence:
Coherence is increased by applying the same PIT eviction strategy
at all nodes. In this case, evict "regular" before "reliable"
before "prompt".
Cache Efficiency:
Efficiency increases with probabilistic caching using the
coordination of equal cache weights. The use of probabilistic
caching reduces the risk of starvation for low priority content,
even if high priority flows dominate the network.
7. Implementation Report and Guidance
The proposed resource management methods have been implemented as an
extension of the NDN/CCNx software stack [CCN-LITE] in its IoT
version on RIOT [RIOT].
Constrained memory and cpu resources limit the use of an elaborate
prioritized buffer queue management. With these constraints, IoT
nodes usually employ forwarding queues that can only hold one to two
packets at once. Despite these challenges, the proposed methods show
visible improvements on forwarding delays.
Experimental evaluations will be added in this section that show the
implications of unmanaged PIT and CS resources for traffic forwarding
in a resource-constrained environment.
8. Security Considerations
TODO TODO
7. IANA Considerations 9. IANA Considerations
TODO TODO
8. Informative References 10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References
[CCN-LITE]
"CCN-lite: A lightweight CCNx and NDN implementation",
<http://ccn-lite.net/>.
[DECORRELATION] [DECORRELATION]
Waehlisch, M., Schmidt, TC., and M. Vahlenkamp, Waehlisch, M., Schmidt, TC., and M. Vahlenkamp,
"Backscatter from the Data Plane - Threats to Stability "Backscatter from the Data Plane - Threats to Stability
and Security in Information-Centric Network and Security in Information-Centric Network
Infrastructure", Computer Networks Vol 57, No. 16, pp. Infrastructure", Computer Networks Vol 57, No. 16, pp.
3192-3206, November 2013. 3192-3206, November 2013.
[I-D.moiseenko-icnrg-flowclass] [I-D.moiseenko-icnrg-flowclass]
Moiseenko, I. and D. Oran, "Flow Classification in Moiseenko, I. and D. Oran, "Flow Classification in
skipping to change at page 7, line 22 skipping to change at page 8, line 44
for More' in Information-Centric Networks (Extended for More' in Information-Centric Networks (Extended
Version)", Computer Communications 36, 7 (2013) pp. Version)", Computer Communications 36, 7 (2013) pp.
758-770, February 2013, <http://dx.doi.org/>. 758-770, February 2013, <http://dx.doi.org/>.
[NDN-EXP] Gundogan, C., Kietzmann, P., Lenders, M., Petersen, H., [NDN-EXP] Gundogan, C., Kietzmann, P., Lenders, M., Petersen, H.,
Schmidt, TC., and M. Waehlisch, "NDN, CoAP, and MQTT: A Schmidt, TC., and M. Waehlisch, "NDN, CoAP, and MQTT: A
Comparative Measurement Study in the IoT", Proc. of 5th Comparative Measurement Study in the IoT", Proc. of 5th
ACM Conf. on Information-Centric Networking (ICN-2018) ACM ACM Conf. on Information-Centric Networking (ICN-2018) ACM
DL, pp. , September 2018, <http://dx.doi.org/>. DL, pp. , September 2018, <http://dx.doi.org/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
Tyson, G., Davies, E., Molinaro, A., and S. Eum, Tyson, G., Davies, E., Molinaro, A., and S. Eum,
"Information-Centric Networking: Baseline Scenarios", "Information-Centric Networking: Baseline Scenarios",
RFC 7476, DOI 10.17487/RFC7476, March 2015, RFC 7476, DOI 10.17487/RFC7476, March 2015,
<https://www.rfc-editor.org/info/rfc7476>. <https://www.rfc-editor.org/info/rfc7476>.
skipping to change at page 8, line 5 skipping to change at page 9, line 23
"Information-Centric Networking (ICN) Research "Information-Centric Networking (ICN) Research
Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
<https://www.rfc-editor.org/info/rfc7927>. <https://www.rfc-editor.org/info/rfc7927>.
[RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S.,
and G. Boggia, "Information-Centric Networking: Evaluation and G. Boggia, "Information-Centric Networking: Evaluation
and Security Considerations", RFC 7945, and Security Considerations", RFC 7945,
DOI 10.17487/RFC7945, September 2016, DOI 10.17487/RFC7945, September 2016,
<https://www.rfc-editor.org/info/rfc7945>. <https://www.rfc-editor.org/info/rfc7945>.
[RIOT] Baccelli, E., Guenes, M., Hahm, O., Schmidt, TC., and M.
Waehlisch, "RIOT OS: Towards an OS for the Internet of
Things", Proc. of the 32nd IEEE INFOCOM IEEE Press, pp.
79-80, April 2013, <http://riot-os.org/>.
Acknowledgments Acknowledgments
This work was stimulated by fruitful discussions in the ICNRG This work was stimulated by fruitful discussions in the ICNRG
research group. We would like to thank all active members for research group. We would like to thank all active members for
constructive thoughts and feedback. In particular, the authors would constructive thoughts and feedback. In particular, the authors would
like to thank Ilya Moiseenko and Dave Oran for their work provided in like to thank Ilya Moiseenko and Dave Oran for their work provided in
[I-D.moiseenko-icnrg-flowclass]. This work was supported in part by [I-D.moiseenko-icnrg-flowclass]. This work was supported in part by
the German Federal Ministry of Research and Education within the I3 the German Federal Ministry of Research and Education within the I3
project. project.
 End of changes. 24 change blocks. 
62 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/