Considerations in the development of a QoS Architecture for CCNx-like ICN protocols
draft-oran-icnrg-qosarch-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | David R. Oran | ||
| Last updated | 2019-08-09 | ||
| Stream | (None) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| IETF conflict review | conflict-review-oran-icnrg-qosarch, conflict-review-oran-icnrg-qosarch, conflict-review-oran-icnrg-qosarch, conflict-review-oran-icnrg-qosarch, conflict-review-oran-icnrg-qosarch, conflict-review-oran-icnrg-qosarch | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-oran-icnrg-qosarch-00
ICNRG D. Oran
Internet-Draft Network Systems Research and Design
Intended status: Informational August 9, 2019
Expires: February 10, 2020
Considerations in the development of a QoS Architecture for CCNx-like
ICN protocols
draft-oran-icnrg-qosarch-00
Abstract
This is a position paper. It documents the author's personal views
on how Quality of Service (QoS) capabilities ought to be accommodated
in ICN protocols like CCNx or NDN which employ flow-balanced
Interest/Data exchanges and hop-by-hop forwarding state as their
fundamental machinery. It argues that such protocols demand a
substantially different approach to QoS from that taken in TCP/IP,
and proposes specific design patterns to achieve both classification
and differentiated QoS treatment on both a flow and aggregate basis.
It also considers the effect of caches as a resource in addition to
memory, CPU and link bandwidth that should be subject to explicitly
un-fair resource allocation. The proposed methods are intended to
operate purely at the network layer, providing the primitives needed
to achieve both transport and higher layer QoS objectives. It
explicitly excludes any discussion of Quality of Experience (QoE)
which can only be assessed and controlled at the application layer or
above.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 10, 2020.
D. Oran Expires February 10, 2020 [Page 1]
Internet-Draft ICN QoS Architecture August 2019
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Some background on the nature and properties of Quality of
Service in network protocols . . . . . . . . . . . . . . . . 4
3.1. Congestion Control basics relevant to ICN . . . . . . . . 5
4. What can we control to achieve QoS in ICN? . . . . . . . . . 6
5. How does this relate to QoS in TCP/IP? . . . . . . . . . . . 7
6. Why is ICN Different? Can we do Better? . . . . . . . . . . . 9
7. A strawman set of principles to guide QoS architecture for
ICN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
The TCP/IP protocol suite used on today's Internet has over 30 years
of accumulated research and engineering into the provision of Quality
of Service machinery, employed with varying success in different
environments. ICN protocols like Named Data Networking (NDN [NDN])
and Content-Centric Networking (CCNx [RFC8569],[RFC8609]) have an
accumulated 10 years of research and very little deployment. We
therefore have the opportunity to either recapitulate the approaches
take with TCP/IP (e.g. IntServ [RFC2998] and Diffserv [RFC2474]) or
design a new architecture and mechanisms aligned with the properties
of ICN protocols which differ substantially from those of TCP/IP.
This position paper advocates the latter approach and comprises the
author's personal views on how Quality of Service (QoS) capabilities
D. Oran Expires February 10, 2020 [Page 2]
Internet-Draft ICN QoS Architecture August 2019
ought to be accommodated in ICN protocols like CCNx or NDN.
Specifically, these protocols differ in fundamental ways from TCP/IP.
These differences are summarized in the following table:
+---------------------------------+---------------------------------+
| TCP/IP | CCNx or NDN |
+---------------------------------+---------------------------------+
| Stateless forwarding | Stateful forwarding |
| Simple Packets | Object model with optional |
| | caching |
| Pure datagram model | Request-response model |
| Asymmetric Routing | Symmetric Routing |
| Independent flow directions | Flow balance |
| Flows grouped by IP prefix and | Flows grouped by name prefix |
| port | |
| End-to-end congestion control | Hop-by-hop congestion control |
+---------------------------------+---------------------------------+
Table 1: Differences between IP and ICN relevant to QoS architecture
This document proposes specific design patterns to achieve both flow
classification and differentiated QoS treatment for ICN on both a
flow and aggregate basis. It also considers the effect of caches as
a resource in addition to memory, CPU and link bandwidth that should
be subject to explicitly un-fair resource allocation. The proposed
methods are intended to operate purely at the network layer,
providing the primitives needed to achieve both transport and higher
layer QoS objectives. It does not propose detailed protocol
machinery to achieve these goals; it leaves these to supplementary
specifications, such as [I-D.moiseenko-icnrg-flowclass]. It
explicitly excludes any discussion of Quality of Experience (QoE)
which can only be assessed and controlled at the application layer or
above.
Much of this document is derived from presentations the author has
given at ICNRG meetings over the last few years that available
through the IETF datatracker (see, for example [Oran2018QoSslides]).
2. Requirements Language
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 [RFC2119].
D. Oran Expires February 10, 2020 [Page 3]
Internet-Draft ICN QoS Architecture August 2019
3. Some background on the nature and properties of Quality of Service
in network protocols
Much of this background material is tutorial, and can be simply
skipped by readers familiar with the long and checkered history of
quality of service in packet networks. Other parts of it are
polemical yet serve to illuminate the author's personal biases and
technical views.
All networking systems provide some degree of "quality of service" in
that they exhibit non-zero utility when offered traffic to carry.
The term therefore is used to describe systems that control the
allocation of various resources in order to achieve _managed
unfairness_. Absent explicit mechanisms to decide what traffic to be
unfair to, most systems try to achieve some form of "fairness" in the
allocation of resources, optimizing the overall utility delivered to
all demand under the constraint of available resources. From this it
should be obvious that you cannot use QoS mechanisms to create or
otherwise increase resource capacity! In fact, all known QoS schemes
have non-zero overhead and hence may (albeit slightly) decrease to
total amount of resources available to carry user traffic.
Further, accumulated experience seems to indicate that QoS is helpful
in a fairly narrow range of network conditions:
o If your resources are lightly loaded, you don't need it, as
neither congestive loss nor substantial queueing delay occurs
o If your resources are heavily oversubscribed, it doesn't save you.
So many users will be unhappy that you are probably not delivering
a viable service
o Failures can rapidly shift your state from the first above to the
second, in which case either:
* your QoS machinery cannot respond quickly enough to maintain
the advertised service quality continuously, or
* resource allocations are sufficiently conservative to result in
substantial wasted capacity under non-failure conditions
Nevertheless, though not universally deployed, QoS is advantageous at
least for some applications and some network environments. Some
examples include:
o applications with steep utility functions [Shenker2006], such as
real-time multimedia
D. Oran Expires February 10, 2020 [Page 4]
Internet-Draft ICN QoS Architecture August 2019
o applications with safety-critical operational constraints, such as
avionics or industrial automation
o dedicated or tightly managed networks whose economics depend on
strict adherence to challenging service level agreements (SLAs)
Another factor in the design and deployment of QoS is the scalability
and scope over which the desired service can be achieved. Here there
are two major considerations, one technical, the other economic/
political:
o Some QoS signaled schemes, such as RSVP [RFC2205] maintain state
in routers for each flow, which scales linearly with the number of
flows. For core routers through which pass millions to billions
of flows, the memory required is infeasible to provide.
o The Internet is comprised of many minimally cooperating autonomous
systems [AS]. There are practically no successful examples of QoS
deployments crossing the AS boundaries of multiple service
providers. This in almost all cases limits the applicability of
QoS capabilities to be intra-domain.
Finally, the relationship between QoS and either accounting or
billing is murky. Some schemes can accurately account for resource
consumption and ascertain to which user to allocate the usage.
Others cannot. While the choice of mechanism may have important
practical economic and political consequences for cost and workable
business models, this document considers none of those things and
discusses QoS in the context of providing managed unfairness only.
Some further background on congestion control for ICN is below.
3.1. Congestion Control basics relevant to ICN
Congestion control is necessary in any packet network that
multiplexes traffic among multiple sources and destinations in order
to:
1. Prevent collapse of utility due to overload, where the total
offered service declines as load increases, perhaps
precipitously, rather than increasing or remaining flat.
2. Avoid starvation of some traffic due to excessive demand by other
traffic.
3. Beyond the basic protections against starvation, achieve
"fairness" among competing traffic. Two common objective
functions are [minmaxfairness] and [proportionalfairness] both of
D. Oran Expires February 10, 2020 [Page 5]
Internet-Draft ICN QoS Architecture August 2019
which have been implemented and deployed successfully on packet
networks for many years.
Before moving on to QoS, it is useful to consider how congestion
control works in NDN or CCNx. Unlike the IP protocol family, which
relies on end-to-end congestion control (e.g. TCP[RFC0793],
DCCP[RFC4340], SCTP[RFC4960], QUIC[I-D.ietf-quic-transport]), CCNx
and NDN employ hop-by-hop congestion control. There is per-Interest/
Data state at every hop of the path and therefore for each
outstanding Interest, bandwidth for data returning on the inverse
path can be allocated. In current designs, this allocation is often
done using Interest counting. By accepting one Interest packet from
a downstream node, implicitly this provides a guarantee (either hard
or soft) that there is sufficient bandwidth on the inverse direction
of the link to send back one Data packet. A number of congestion
control schemes have been developed for ICN that operate in this
fashion, for example [Wang2013], [Mahdian2016], [Song2018],
[Carofiglio2012]. Other schemes, like [Schneider2016] neither count
nor police interests, but instead monitor queues using AQM (active
queue management) to mark returning Data packets that have
experienced congestion.
4. What can we control to achieve QoS in ICN?
QoS is achieved through managed unfairness in the allocation of
resources in network elements, particularly routers doing forwarding
of ICN packets. So, a first order question is what resources need to
be allocated, and how to ascertain which traffic gets what
allocations. In the case of CCNx or NDN the important network
element resources are:
+-----------------------------+-------------------------------------+
| Resource | ICN Usage |
+-----------------------------+-------------------------------------+
| Communication Link capacity | buffering for queued packets |
| Content Store capacity | to hold cached data |
| Forwarder memory | for the Pending Interest Table |
| | (PIT) |
| Compute capacity | for forwarding packets, including |
| | the cost of Forwarding Information |
| | Base (FIB) lookups. |
+-----------------------------+-------------------------------------+
Table 2: ICN-related Network Element Resources
For these resources, any QoS scheme has to specify two things:
D. Oran Expires February 10, 2020 [Page 6]
Internet-Draft ICN QoS Architecture August 2019
1. How do you create _equivalence classes_ (a.k.a. flows) of traffic
to which different QoS treatments are applied?
2. What are the possible treatments and how are those mapped to the
resource allocation algorithms?
Two critical facts of life come into play when designing a QoS
scheme. First, the number of equivalence classes that can be
simultaneously tracked in a network element is bounded by both memory
and processing capacity to do the necessary lookups. One can allow
very fine-grained equivalence classes, but not be able to employ them
globally because of scaling limits of core routers. That means it is
wise to either restrict the range of equivalence classes, or allow
them to be _aggregated_, trading off accuracy in policing traffic
against ability to scale.
The second is how flexible is the set of treatments that are defined.
The ability to encode the treatment requests in the protocol can be
limited (as it is for IP - there are only 6 of the TOS bits available
for Diffserv treatments), but as or more important is whether there
are practical traffic policing, queuing, and pacing algorithms that
can be combined to support a rich set of QoS treatments.
The two considerations above in combination can easily be
substantially more expressive than can be achieved in practice with
the available number of queues on real network interfaces or the
amount of per-packet computation needed to enque or dequeue a packet.
5. How does this relate to QoS in TCP/IP?
TCP/IP has fewer resource types to manage than ICN, and in some cases
the allocation methods are simpler, as shown in the following table:
D. Oran Expires February 10, 2020 [Page 7]
Internet-Draft ICN QoS Architecture August 2019
+-----------------------------+-------------+-----------------------+
| Resource | IP Relevant | TCP/IP Usage |
+-----------------------------+-------------+-----------------------+
| Communication Link capacity | YES | buffering for queued |
| | | packets |
| Content Store capacity | NO | no content store in |
| | | IP |
| Forwarder memory | MAYBE | not needed for |
| | | output-buffered |
| | | designs |
| Compute capacity | YES | for forwarding |
| | | packets, but arguably |
| | | much cheaper than ICN |
+-----------------------------+-------------+-----------------------+
Table 3: IP-related Network Element Resources
For these resources, IP has specified three fundamental things, as
shown in the following table:
+----------------+--------------------------------------------------+
| What | How |
+----------------+--------------------------------------------------+
| *Equivalence | subset+prefix match on IP 5-tuple |
| classes* | {SA,DA,SP,DP,PT} |
| *Diffserv | (very) small number of globally-agreed traffic |
| treatments* | classes |
| *Intserv | per-flow parameterized _Controlled Load_ and |
| treatments* | _Guaranteed_ service classes |
+----------------+--------------------------------------------------+
Table 4: Fundamental protocol elements to achieve QoS for TCP/IP
Equivalence classes for IP can be pairwise, by matching against both
source and destination address+port, pure group using only
destination address+port, or source-specific multicast with source
adress+port and destination multicast address+port.
With Intserv, the signaling protocol RSVP [RFC2205] carries two data
structures, the FLOWSPEC and the TSPEC. The former fulfills the
requirement to identify the equivalence class the QoS being signaled
applies to. The latter comprises the desired QoS treatment along
with a description of the dynamic character of the traffic (e.g.
average bandwidth and delay, peak bandwidth, etc.). Both of these
encounter substantial scaling limits, which has meant that Intserv
has historically been limited to confined topologies, and/or high-
value usages, like traffic engineering.
D. Oran Expires February 10, 2020 [Page 8]
Internet-Draft ICN QoS Architecture August 2019
With Diffserv, the protocol encoding (6 bits in the TOS field of the
IP header) artificially limits the number of classes one can specify.
These are documented in [RFC4594]. Nonetheless, when used with fine-
grained equivalence classes, one still runs into limits on the number
of queues required.
6. Why is ICN Different? Can we do Better?
While one could adopt an approach to QoS mirroring the extensive
experience with TCP/IP, this would, in the author's view, be a
mistake. The implementation and deployment of QoS in IP networks has
been spotty at best. There are of course economic and political
reasons as well as technical reasons for these mixed results, but
there are several architectural choices in ICN that make it a
potentially much better protocol base to enhance with QoS machinery.
This section discusses those difference and their consequences.
First and foremost, hierarchical names are a much richer basis for
specifying equivalence classes than IP 5-tuples. The IP address (or
prefix) can only separate traffic by topology to the granularity of
hosts, and not express actual computational instances nor sets of
data. Ports give some degree of per-instance demultiplexing, but
this tends to be both coarse and ephemeral, while confounding the
demultiplexing function with the assignment of QoS treatments to
particular subsets of the data. Some degree of finer granularity is
possible with IPv6 by exploiting the ability to use up to 64 bits of
address for classifying traffic. In fact, the hICN project
([I-D.muscariello-intarea-hicn]), while adopting the request-response
model of CCNx, uses IPv6 addresses as the available namespace, and
IPv6 packets (plus "fake" TCP headers) as the wire format.
Nonetheless, the flexibility of tokenized, variable length,
hierarchical names allows one to directly associate classes of
traffic for QoS purposes with the structure of an application
namespace. The classification can be as coarse or fine-grained as
desired by the application. While not _always_ the case, there is
typically a straightforward association between how objects are
named, and how they are grouped together for common treatment.
Examples abound; a number can be conveniently found in
[I-D.moiseenko-icnrg-flowclass].
In ICN, QoS is not pre-bound to topology since names are non-
topological, unlike unicast IP addresses. This allows QoS to be
applied to multi-destination and multi-path environments in a
straightforward manner, rather than requiring either multicast with
coarse class-based scheduling or complex signaling like that in RSVP-
TE [RFC3209] that is needed to make point-to-multipoint MPLS work.
D. Oran Expires February 10, 2020 [Page 9]
Internet-Draft ICN QoS Architecture August 2019
Because of IP's stateless forwarding model, complicated by the
ubiquity of asymmetric routes, any flow-based QoS requires state that
is decoupled from the actual arrival of traffic and hence must be
maintained, at least as soft-state, even during quiescent periods.
Intserv, for example, requires flow signaling with state O(#flows).
ICN, even worst case, requires state O(#active interest/data
exchanges), since state can be instantiated on arrival of an
Interest, and removed lazily once the data hase been returned.
Unlike Intserv, Difserv eschews signaling in favor of class-based
configuration of resources and queues in network elements. However,
Diffserv limits traffic treatments to a few bits taken from the ToS
field of IP. No such wire encoding limitations exist for NDN or
CCNx, as the protocol is completely TLV-based, and one (or even more
than one) new field can be easily defined to carry QoS treatment
information.
Therefore, there are greenfield possibilities for more powerful QoS
treatment options in ICN. For example, IP has no way to express a
QoS treatment like "try hard to deliver reliably, even at the expense
of delay or bandwidth". Such a QoS treatment for ICN could invoke
native ICN mechanisms, none of which are present in IP, such as:
o In-network retransmission in response to hop-by-hop errors
returned from upstream forwarders
o Trying multiple paths to multiple content sources either in
parallel or serially
o Higher precedence for short-term caching to recover from
downstream errors
Such mechanisms are typically described in NDN and CCNx as
_forwarding strategies_. However, little or no guidance is given for
what application actions or protocol machinery is used to decide
which forwarding strategy to use for which Interests that arrive at a
forwarder. See [BenAbraham2018] for an investigation of these
issues. Associating forwarding strategies with the equivalence
classes and QoS treatments directly can make them more accessible and
useful to implement and deploy.
IP has three forwarding semantics, with different QoS needs (Unicast,
Anycast, Multicast). ICN has the single forwarding semantic, so any
QoS machinery can be uniformly applied across any request/response
invocation, whether it employs dynamic destination routing, multi-
destination parallel requests, or even localized flooding (e.g.
directly on L2 multicast mechanisms). Additionally, the pull-based
D. Oran Expires February 10, 2020 [Page 10]
Internet-Draft ICN QoS Architecture August 2019
model of ICN avoids a number of thorny multicast QoS problems that IP
has ([Wang2000], [RFC3170], [Tseng2003]).
The Multi-destination/multi-path forwarding model in ICN changes
resource allocation needs in a fairly deep way. IP treats all
endpoints as open-loop packet sources, whereas NDN and CCNx have
strong asymmetry between producers and consumers as packet sources.
IP has no caching in routers, whereas ICN needs ways to allocate
cache resources. Treatments to control caching operation are
unlikely to look much like the treatments used to control link
resources. NDN and CCNx already have useful cache control directives
associated with Data messages. The CCNx controls include
ExpiryTime time after which a cached Content Object is considered
expired and MUST no longer be used to respond to an Interest from
a cache.
Recommended Cache Time time after which the publisher considers the
Content Object to be of low value to cache.
(See [RFC8569] for the formal definitions)
ICN flow classifiers, such as those in
[I-D.moiseenko-icnrg-flowclass] can be used to achieve soft or hard
partitioning of cache resources in the content store of an ICN
forwarder. For example, cached content for a given equivalence class
can be considered _fate shared_ in a cache whereby objects from the
same equivalence class are purged as a group rather than
individually. This can recover cache space more quickly and at lower
overhead than pure per-object replacement. In addition, since the
forwarder remembers the QoS treatment for each pending Interest in
its PIT, the above cache controls can be augmented by policy to
prefer retention of cached content for some equivalence classes as
part of the cache replacement algorithm.
Stateless forwarding and asymmetric routing in IP limits available
state/feedback to manage link resources. In contrast, NDN or CCNx
forwarding allows all link resource allocation to occur as part of
Interest forwarding, potentially simplifying things considerably.
For example, with symmetric routing, producers have no control over
the paths their data packets traverse, and hence any QoS treatments
intended to affect routing paths will have no effect.
D. Oran Expires February 10, 2020 [Page 11]
Internet-Draft ICN QoS Architecture August 2019
7. A strawman set of principles to guide QoS architecture for ICN
Based on the observations made in the earlier sections, this summary
section captures the author's ideas for clear and actionable
architectural principals for how to incorporate QoS machinery into
ICN protocols like NDN and CCNx. Hopefully, they can guide further
work and focus effort on portions of the giant design space for QoS
that have the best tradeoffs in terms of flexibility, simplicity, and
deployability.
*Define equivalence classes using the name hierarchy rather than
creating an independent traffic class definition*. This directly
associates the specification of equivalence classes of traffic with
the structure of the application namespace. It can allow
hierarchical decomposition of equivalence classes in a natural way
because of the way hierarchical ICN names are constructed. Two
practical mechanisms are presented in [I-D.moiseenko-icnrg-flowclass]
with different tradeoffs between security and the ability to
aggregate flows. Either prefix-based (EC3) or explicit name
component based (ECNT) or both could be adopted as the part of the
QoS architecture for defining equivalence classes.
*Put consumers in control of Link and Forwarding resource
allocation*. Do _all_ link buffering and forwarding (both memory and
CPU) resource allocations based on Interest arrivals. This is
attractive because it provides early congestion feedback to
consumers, and allows scheduling the reverse link direction ahead of
time for carrying the matching data. This makes enforcement of QoS
treatments a single-ended rather than a double-ended problem and can
avoid wasting resources on fetching data that will wind up dropped
when it arrives at a bottleneck link.
*Put producers in control of cache resources*. Consumers don't care
if anything is cached, at least not directly. Producers want to
reduce their load and serve consumers with fewest resources. Use the
same equivalence class mechanism for cache resource partitioning and
as a means to fate share cache entries if desired.
*Re-think how to specify traffic treatments - don't just copy
Diffserv*. Some of the Diffserv classes may form a good starting
point, as their mapping onto queuing algorithms for managing link
buffering are well understood. However, Diffserv alone does not
allow one to express latency versus reliability tradeoffs or other
useful QoS treatments. Nor does it permit "TSPEC"-style traffic
descriptions as are allowed in a signaled QoS scheme (despite neither
having nor needing a separate signaling protocol given the state
carried in the ICN data plane by forwarders). Here are some
examples:
D. Oran Expires February 10, 2020 [Page 12]
Internet-Draft ICN QoS Architecture August 2019
o A "burst" treatment, where an initial Interest gives an aggregate
data size to request allocation of link capacity for a large burst
of Interest/Data exchanges. The Interest can be rejected at any
hop if the resources are not available. Such a treatment can also
accomodate Data implosion produced by the discovery procedures of
management protocols like [I-D.irtf-icnrg-ccninfo].
o A "reliable" treatment, which affects preference for allocation of
PIT space for the Interest and Content Store space for the data in
order to improve the robustness of IoT data delivery in
constrained environment, as is described in
[I-D.gundogan-icnrg-iotqos].
o A "search" treatment, which, within the specified Interest
Lifetime, tries many paths either in parallel or serial to
potentially many content sources, to maximize the probability that
the requested item will be found. This is done at the expense of
the extra bandwidth of both forwarding Interests and receiving
multiple responses upstream of an aggregation point. The
treatment can encode a value expressing tradeoffs like breadth-
first versus depth-first search, and bounds on the total resource
expenditure. Such a treatment would be useful for instrumentation
protocols like [I-D.mastorakis-icnrg-icntraceroute].
As an aside, loose latency control can be achieved by bounding
Interest Lifetime as long as it is not also used as an application
mechanism to provide subscriptions or establish path traces for
producer mobility. See [Krol2018] for a discussion of the network
versus application timescale issues in ICN protocols.
8. IANA Considerations
This document does not require any IANA actions
9. Security Considerations
There are a few ways in which QoS for ICN interacts with security and
privacy issues. Since QoS addresses relationships among traffic
rather than the inherent characteristics of traffic, it neither
enhances nor deteriorates the security and privacy properties of the
data being carried, as long as the machinery does not alter or
otherwise compromise the basic security properties of the associated
protocols. The QoS approaches advocated here for ICN can serve to
amplify existing threats to network traffic however:
o An attacker able to manipulate the QoS treatments of traffic can
mount a more focused (and potentially more effective) denial of
service attack by suppressing performance on traffic the attacker
D. Oran Expires February 10, 2020 [Page 13]
Internet-Draft ICN QoS Architecture August 2019
is targeting. Since the architcture here assumes QoS treatments
are manipulable hop-by-hop, any on-path adversary can wreak havoc.
Note however, that in basic ICN, and on-path attacker can do this
and more by dropping, delaying, or mis-routing traffic independent
of any particular QoS machinery in use.
o By explicitly revealing equivalence classes of traffic via either
names or other fields in packets, an attacker has yet one more
handle to use to discover linkability of multiple requests.
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>.
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Semantics", RFC 8569,
DOI 10.17487/RFC8569, July 2019,
<https://www.rfc-editor.org/info/rfc8569>.
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Messages in TLV Format", RFC 8609,
DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>.
10.2. Informative References
[AS] "Autonomous System (Internet)", no date,
<https://en.wikipedia.org/wiki/
Autonomous_system_(Internet)>.
[BenAbraham2018]
Ben Abraham, H., Parwatikar, J., DeHart, J., Dresher, A.,
and P. Crowley, "Decoupling Information and Connectivity
via Information-Centric Transport, in 5th ACM Conference
on Information-Centric Networking (ICN '18), September
21-23, 2018, Boston, MA, USA",
DOI 10.1145/3267955.3267963, September 2018,
<https://conferences.sigcomm.org/acm-icn/2018/proceedings/
icn18-final31.pdf>.
D. Oran Expires February 10, 2020 [Page 14]
Internet-Draft ICN QoS Architecture August 2019
[Carofiglio2012]
Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop-
by-hop and receiver-driven interest control protocol for
content-centric networks, in ICN Workshop at SIGcomm
2012", DOI 10.1145/2377677.2377772, 2102,
<http://conferences.sigcomm.org/sigcomm/2012/paper/icn/
p37.pdf>.
[I-D.gundogan-icnrg-iotqos]
Gundogan, C., Schmidt, T., Waehlisch, M., Frey, M., Shzu-
Juraschek, F., and J. Pfender, "Quality of Service for ICN
in the IoT", draft-gundogan-icnrg-iotqos-01 (work in
progress), July 2019.
[I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-22 (work
in progress), July 2019.
[I-D.irtf-icnrg-ccninfo]
Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering
Content and Network Information in Content-Centric
Networks", draft-irtf-icnrg-ccninfo-02 (work in progress),
July 2019.
[I-D.mastorakis-icnrg-icntraceroute]
Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and
D. Oran, "ICN Traceroute Protocol Specification", draft-
mastorakis-icnrg-icntraceroute-04 (work in progress),
February 2019.
[I-D.moiseenko-icnrg-flowclass]
Moiseenko, I. and D. Oran, "Flow Classification in
Information Centric Networking", draft-moiseenko-icnrg-
flowclass-04 (work in progress), July 2019.
[I-D.muscariello-intarea-hicn]
Muscariello, L., Carofiglio, G., Auge, J., and M.
Papalini, "Hybrid Information-Centric Networking", draft-
muscariello-intarea-hicn-02 (work in progress), June 2019.
D. Oran Expires February 10, 2020 [Page 15]
Internet-Draft ICN QoS Architecture August 2019
[Krol2018]
Krol, M., Habak, K., Oran, D., Kutscher, D., and I.
Psaras, "RICE: Remote Method Invocation in ICN, in
Proceedings of the 5th ACM Conference on Information-
Centric Networking - ICN '18",
DOI 10.1145/3267955.3267956, September 2018,
<https://conferences.sigcomm.org/acm-icn/2018/proceedings/
icn18-final9.pdf>.
[Mahdian2016]
Mahdian, M., Arianfar, S., Gibson, J., and D. Oran,
"MIRCC: Multipath-aware ICN Rate-based Congestion Control,
in Proceedings of the 3rd ACM Conference on Information-
Centric Networking", DOI 10.1145/2984356.2984365, 2016,
<http://conferences2.sigcomm.org/acm-icn/2016/proceedings/
p1-mahdian.pdf>.
[minmaxfairness]
"Max-min Fairness", no date,
<https://en.wikipedia.org/wiki/Max-min_fairness>.
[NDN] "Named Data Networking", various,
<https://named-data.net/project/execsummary/>.
[Oran2018QoSslides]
Oran, D., "Thoughts on Quality of Service for NDN/CCN-
style ICN protocol architectures, presented at ICNRG
Interim Meeting, Cambridge MA", September 2018,
<https://datatracker.ietf.org/meeting/interim-2018-icnrg-
03/materials/slides-interim-2018-icnrg-03-sessa-thoughts-
on-qos-for-ndnccn-style-icn-protocol-architectures>.
[proportionalfairness]
"Proportionally Fair", no date,
<https://en.wikipedia.org/wiki/Proportionally_fair>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>.
D. Oran Expires February 10, 2020 [Page 16]
Internet-Draft ICN QoS Architecture August 2019
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J., and E.
Felstaine, "A Framework for Integrated Services Operation
over Diffserv Networks", RFC 2998, DOI 10.17487/RFC2998,
November 2000, <https://www.rfc-editor.org/info/rfc2998>.
[RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications:
Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170,
September 2001, <https://www.rfc-editor.org/info/rfc3170>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
[Schneider2016]
Schneider, K., Yi, C., Zhang, B., and L. Zhang, "A
Practical Congestion Control Scheme for Named Data
Networking, in Proceedings of the 2016 conference on 3rd
ACM Conference on Information-Centric Networking - ACM-ICN
'16", DOI 10.1145/2984356.2984369, 2016,
<http://conferences2.sigcomm.org/acm-icn/2016/proceedings/
p21-schneider.pdf>.
D. Oran Expires February 10, 2020 [Page 17]
Internet-Draft ICN QoS Architecture August 2019
[Shenker2006]
Shenker, S., "Fundamental Design Issues for the Future
Internet, in IEEE Journal on Selected Areas in
Communications", DOI 10.1109/49.414637, 2006,
<https://dl.acm.org/citation.cfm?id=2316898>.
[Song2018]
Song, J., Lee, M., and T. Kwon, "SMIC: Subflow-level
Multi-path Interest Control for Information Centric
Networking, in 5th ACM Conference on Information-Centric
Networking", DOI 10.1145/3267955.3267971, 2018,
<https://conferences.sigcomm.org/acm-icn/2018/proceedings/
icn18-final62.pdf>.
[Tseng2003]
Tseng, CH., "The performance of QoS-aware IP multicast
routing protocols, in Networks, Vol:42, No:2",
DOI 10.1002/net.10084, September 2003,
<https://onlinelibrary.wiley.com/doi/abs/10.1002/
net.10084>.
[Wang2000]
Wang, B. and J. Hou, "Multicast routing and its QoS
extension: problems, algorithms, and protocols, in IEEE
Network, Vol:14, No:1", DOI 10.1109/65.819168, Jan/Feb
2000, <https://ieeexplore.ieee.org/
document/819168?arnumber=819168>.
[Wang2013]
Wang, Y., Rozhnova, N., Narayanan, A., Oran, D., and I.
Rhee, "An Improved Hop-by-hop Interest Shaper for
Congestion Control in Named Data Networking, in ACM
SIGCOMM Workshop on Information-Centric Networking",
DOI 10.1145/2534169.2491233, 2013,
<http://conferences.sigcomm.org/sigcomm/2013/papers/icn/
p55.pdf>.
Author's Address
Dave Oran
Network Systems Research and Design
4 Shady Hill Square
Cambridge, MA 02138
USA
Email: daveoran@orandom.net
D. Oran Expires February 10, 2020 [Page 18]