Quality of Service for ICN in the
IoTHAW HamburgBerliner Tor 7HamburgD-20099Germany+4940428758067cenk.guendogan@haw-hamburg.dehttp://inet.haw-hamburg.de/members/cenk-gundoganHAW HamburgBerliner Tor 7HamburgD-20099Germanyt.schmidt@haw-hamburg.dehttp://inet.haw-hamburg.de/members/schmidtlink-lab & FU
BerlinHoenower Str. 35BerlinD-10318Germanymw@link-lab.nethttp://www.inf.fu-berlin.de/~waehlSafety IOFranz-Ehrlich-Strasse 9BerlinD-12489Germanymichael.frey@safetyio.comSafety IOFranz-Ehrlich-Strasse 9BerlinD-12489Germanyfelix.juraschek@safetyio.comVictoria University of
WellingtonKelburn ParadeWellingtonNZ-6012New Zealandjpfender@ecs.vuw.ac.nzhttps://ecs.victoria.ac.nz/Main/GradJakobPfenderICN Research GroupThis document describes manageable resources in ICN IoT deployments
and a lightweight traffic classification method for mapping priorities
to resources. Management methods are further derived for controlling
latency and reliability of traffic flows in constrained
environments.The performance of networked systems is largely determined by the
resources available for forwarding messages between components. In
addition to link capacities and buffer queues, Information-centric
Networks rely on additional resources that shape its overall performance,
namely Pending Interest Table space, and caching capacity.Typical IoT deployments add tight resource constraints to this
picture : Nodes have processing and memory
limitations, the underlying link layer technologies are lossy and
restricted in bandwidth. Particularly in multi-hop networks, such
constraints affect the overall performance, create bottlenecks, but may
lead to cascading packet loss or energy depletion when PIT resources are
independently evicted and forwarding states decorrelate . Overprovisioning to counter performance flaws
is infeasible for many IoT scenarios as it inflicts with use cases and
increases deployment costs. Quality of Service (QoS) is a method to
enhance overall performance by redistributing resources to a subset of
messages, and - in the constrained IoT use case - to coordinate
operations under resource scarcity.IoT applications follow various use cases, of which different QoS
requirements can be derived. While periodic sensor readings often comply
with unmanaged performance, industrial control messaging or security
alerts require (very) low latency, and safety-critical environmental
recording or network management need (highly) reliable network services.
Both quality levels can only be assured by appropriate resource
reservations.In order to achieve a QoS-aware information-centric IoT deployment,
this document describes manageable resources in , defines a flow classification method in , and specifies priorities and their mappings in
.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 . The use of the term, "silently ignore" is not
defined in RFC 2119. However, the term is used in this document and can
be similarly construed.This document uses the terminology of , , and for ICN entities.The following terms are used in the document and defined as follows:
A traffic flow is a sequence of messages
(Interest and data) that belong to one specific communication
context. Due to in-network caching, ICN flows may be delocalized. A
flow may also relate to several requesters in the presence of
Interest aggregation.The following resources contribute to the overall network performance
in Information-Centric IoT Networking and need management for QoS
control.The link layer manages access to the media and provides space to
buffer packets. Low latency applications require that requests are
prioritized compared to regular priority data. Based on the request
response pattern of ICN, link layer resources can be preallocated for
data packets.The Pending Interest Table (PIT) stores open requests at each hop.
PIT resources are allocated when requests are forwarded, and they are
released on returning responses.Placement and replacement strategies of PIT entries directly
influence the latency and reliability properties of traffic flows and
thus should consider prioritization schemes. If the PIT is not
saturated new PIT entries can be added. If the PIT is saturated,
requests with higher priority should replace requests with lower
priority to prevent higher latencies due to retransmissions.Content stores (CS) enable transparent in-network caching and thus
improve the transport in wireless and lossy environments by reducing
hop traversals for content requests .Placement and replacement strategies of data in content stores can
affect the latency and reliability properties of traffic flows. The
latency can be reduced by placing data closer to the consumers.
Reliability can be improved by replicating data in multiple content
stores to be resilient to node failures.This document defines a traffic flow classification mechanism that
aggregates names into equivalence classes in order to apply resource
allocation decisions on messages of particular traffic flows.A traffic class is a name prefix and each device maintains a list of
valid classes. The actual distribution of traffic classes is out of
scope of this document. The classes for request and response messages
are derived by performing a longest prefix match (LPM) with the list of
valid traffic classes and the Name TLV of the message. Examples are
given in .The empty traffic class "" is the default class for messages that do
not match any valid traffic classes in the class list.We define two priority levels to set the priorities for traffic flows in regards to latency and reliability.
Latency:
EXPEDITEDREGULARReliability:
RELIABLEREGULAREach list entry of the traffic class list from has an associated priority tuple which
distinctly specifies priority levels for the resources in . The tuple is of the following form: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:EXPEDITED_FORWARDING_QUEUEREGULAR_FORWARDING_QUEUE Packets will be appended to the queue corresponding to their
priority level.In unsatured PITs, requests are added as new entries regardless of 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.
Nodes MAY implement a caching decision strategy
instead of always caching all incoming content objects . If they do, the caching decision strategy
MUST take the content object priority into account, such that
lower priority content is not cached if the cache is saturated
with higher priority content.
In unsaturated content stores, all content objects are passed to the cache decision strategy.
In saturated content stores, reliable traffic flows MUST be passed to 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.
TODOTODONDN, CoAP, and MQTT: A Comparative Measurement Study in the
IoTHAW HamburgHAW HamburgFU BerlinFU BerlinHAW HamburgFU BerlinCache 'Less for More' in Information-Centric Networks
(Extended Version)University College LondonUniversity College LondonUniversity College LondonUniversity College LondonBackscatter from the Data Plane - Threats to Stability and
Security in Information-Centric Network InfrastructureFU BerlinHAW HamburgHAW HamburgThis work was stimulated by fruitful discussions in the ICNRG
research group. We would like to thank all active members for
constructive thoughts and feedback. In particular, the authors would
like to thank Ilya Moiseenko and Dave Oran for their work provided in
. This work was supported
in part by the German Federal Ministry of Research and Education within
the I3 project.