Skip to main content

Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols
RFC 9064

Revision differences

Document history

Date Rev. By Action
2021-06-30
06 (System)
Received changes through RFC Editor sync (created alias RFC 9064, changed title to 'Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric …
Received changes through RFC Editor sync (created alias RFC 9064, changed title to 'Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols', changed abstract to 'This is a position paper. It documents the author's personal views on how Quality of Service (QoS) capabilities ought to be accommodated in Information-Centric Networking (ICN) protocols like Content-Centric Networking (CCNx) or Named Data Networking (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 in addition to memory, CPU, and link bandwidth as resources that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve 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.

This document is not a product of the IRTF Information-Centric Networking Research Group (ICNRG) but has been through formal Last Call and has the support of the participants in the research group for publication as an individual submission.', changed pages to 23, changed standardization level to Informational, changed state to RFC, added RFC published event at 2021-06-30, changed IRTF state to Published RFC)
2021-06-30
06 (System) RFC published
2021-06-23
06 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9064">AUTH48-DONE</a> from AUTH48
2021-06-22
06 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9064">AUTH48</a>
2021-05-24
06 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-04-16
06 (System) IANA Action state changed to No IANA Actions from In Progress
2021-04-15
06 (System) RFC Editor state changed to EDIT
2021-04-15
06 (System) IANA Action state changed to In Progress
2021-04-15
06 Colin Perkins IRTF state changed to Sent to the RFC Editor from Waiting for IRTF Chair
2021-04-15
06 Colin Perkins Sent request for publication to the RFC Editor
2021-03-12
06 David Oran Tag IESG Review Completed set.
2021-03-12
06 David Oran IRTF state changed to Waiting for IRTF Chair from Sent to the RFC Editor
2021-03-09
06 David Oran IRTF state changed to Sent to the RFC Editor from In IESG Review
2021-01-15
06 Colin Perkins Magnus Westerlund will do a conflict review for the IESG
2021-01-15
06 Colin Perkins IRTF state changed to In IESG Review from Waiting for IRTF Chair
2020-12-22
06 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed
2020-12-22
06 Amanda Baber
(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has reviewed draft-oran-icnrg-qosarch-06 and has the following comments:

We understand that this document doesn't require any registry …
(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has reviewed draft-oran-icnrg-qosarch-06 and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist
2020-12-21
06 Colin Perkins IETF conflict review initiated - see <a href="/doc/conflict-review-oran-icnrg-qosarch/">conflict-review-oran-icnrg-qosarch</a>
2020-11-22
06 David Oran
Confirm with Mallory & Spencer that their comments on the IRSG ballot were adequately addressed by this version, and if so, it should be ready …
Confirm with Mallory & Spencer that their comments on the IRSG ballot were adequately addressed by this version, and if so, it should be ready for IESG conflict review and on to RFCed for publication.
2020-11-22
06 David Oran IRTF state changed to Waiting for IRTF Chair from Waiting for Document Shepherd
2020-11-19
06 (System) Revised ID Needed tag cleared
2020-11-19
06 David Oran New version available: draft-oran-icnrg-qosarch-06.txt
2020-11-19
06 (System) New version approved
2020-11-19
06 (System) Request for posting confirmation emailed to previous authors: David Oran <daveoran@orandom.net>
2020-11-19
06 David Oran Uploaded new revision
2020-10-12
05 David Oran Changed document external resources from:

[]

to:

github_repo https://github.com/daveoran/draft-oran-icnrg-qosarch
2020-10-12
05 Colin Perkins Revised draft needed to address IRSG ballot comments from Spencer and Mallory.
2020-10-12
05 Colin Perkins Tag Revised I-D Needed set.
2020-10-12
05 Colin Perkins IRTF state changed to Waiting for Document Shepherd from In IRSG Poll
2020-10-12
05 Colin Perkins Closed "IRSG Approve" ballot
2020-09-24
05 Mallory Knodel
[Ballot comment]
The draft includes a lot of meta narrative about the discussion of the draft and unresolved issues in the IRSG without simply resolving …
[Ballot comment]
The draft includes a lot of meta narrative about the discussion of the draft and unresolved issues in the IRSG without simply resolving those issues and presenting the research as a whole. Furthermore the "managed unfairness" framing sets a low bar when QoS should be primarily about defining the high bar. While it might be worth mapping the floor, I suggest it's real value for the IRTF would be achieved in conjunction with finding the ceiling.
2020-09-24
05 Mallory Knodel [Ballot Position Update] New position, Not Ready, has been recorded for Mallory Knodel
2020-09-16
05 Spencer Dawkins
[Ballot comment]
Thanks for writing this. I'm fine with it being published on the IRTF stream as a way of provoking thought.

I have some …
[Ballot comment]
Thanks for writing this. I'm fine with it being published on the IRTF stream as a way of provoking thought.

I have some nit-ish comments, but please do the right thing, whatever that is.

I'm not an ICN guy, but I can translate all of the terms on both sides of Table 1, except for "flow balance". The term isn't mentioned anywhere else, except with a reference to I-D.oran-icnrg-flowbalance,  which has a very clear definition in its abstract.

  This captures the idea that there is a one-to-one
  correspondence between requests for data, carried in Interest
  messages, and the responses with the requested data object, carried
  in Data messages. 

Would it make sense to include some or all of that definition earlier in the document, or just including a pointer to the discussion draft near where the term first appears? The current pointer to the discussion draft happens 14 pages into this draft, which doesn't seem helpful if a reader doesn't understand the term used on page 3.

If everyone else knows what that means, please carry on :-)

This text

  Further, accumulated experience seems to indicate that QoS is helpful
  in a fairly narrow range of network conditions:

seems backwards to me, because the list of bullets that follows describe where QoS is NOT helpful:

  *  If your resources are lightly loaded, you don't need it, as
      neither congestive loss nor substantial queueing delay occurs

  *  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

  *  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.

I think this text

      This may
      allow less pessimistic rate adjustment schemes than the Additive
      Increase, Multiplicative Decrease (AIMD) with .5 multiplier that
      is used on TCP/IP networks. 

is approximately correct today, but TSVWG is certainly trying to change that with ECT(1) experimentation as per https://tools.ietf.org/html/rfc8311. Perhaps "that is commonly used on TCP/IP networks"?

I'm a bit uncomfortable with "likely to incur a mobility event within an RTT (or a few RTTs)", because really short-horizon distributed decisions seem to be problematic in a lot of path aware networking proposals.

  *  A QoS treatment indicating a mobile consumer likely to incur a
      mobility event within an RTT (or a few RTTs).  Such a treatment
      would allow a mobile network operator to preferentially cache the
      data at a forwarder positioned at a _join point_ or _rendezvous
      point_ of their topology.

How badly do you need the text following "likely to incur a mobility event"? It seems like deleting it would be just as clear and accurate.
2020-09-16
05 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2020-09-16
05 Eve Schooler [Ballot Position Update] New position, Yes, has been recorded for Eve Schooler
2020-09-16
05 Dirk Kutscher [Ballot Position Update] New position, Yes, has been recorded for Dirk Kutscher
2020-09-11
05 Mirja Kühlewind
[Ballot comment]
The document states that is does only reflect the author's personal views and is not a product of the IRTF Information-Centric  Networking Research …
[Ballot comment]
The document states that is does only reflect the author's personal views and is not a product of the IRTF Information-Centric  Networking Research Group (ICNRG), as such it seems to me that the document would be the perfect candidate for publication on the ISE stream.
2020-09-11
05 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2020-09-11
05 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Not Ready
2020-09-10
05 Mirja Kühlewind
[Ballot comment]
I would like to quickly discuss if this document is seen as appropriate for publication on the IRTF stream. The document states that …
[Ballot comment]
I would like to quickly discuss if this document is seen as appropriate for publication on the IRTF stream. The document states that is does only reflect the author's personal views and is not a product of the IRTF Information-Centric  Networking Research Group (ICNRG), as such it seems to me that the document would be the perfect candidate for publication on the ISE stream.
2020-09-10
05 Mirja Kühlewind [Ballot Position Update] New position, Not Ready, has been recorded for Mirja Kühlewind
2020-09-08
05 David Oran [Ballot comment]
I'm the author
2020-09-08
05 David Oran [Ballot Position Update] New position, Recuse, has been recorded for David Oran
2020-09-06
05 Colin Perkins IRTF state changed to In IRSG Poll from Waiting for Document Shepherd
2020-09-06
05 Colin Perkins Created IRSG Ballot
2020-09-06
05 Colin Perkins
1) Summary
This document is a position paper that describes how Quality of Service (QoS) capabilities ought to be accommodated
in ICN protocols like CCNx …
1) Summary
This document is a position paper that describes 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.

2) Review and Consensus
QoS in ICN is an important topic with a huge design space. ICNRG has
been discussing different specific protocol mechanisms as well as
conceptual approaches. This document presents architectural
considerations for QoS, leveraging ICN properties instead of merely
applying IP-QoS mechanisms - without defining a specific architecture
or specific protocols mechanisms yet. However, there is consensus in
ICNRG that this document, clarifying the author's views, could
inspire such work and should hence be published as a position paper.

The draft was reviewed for the IRSG by Eve Schooler.
2020-08-24
05 (System) Revised ID Needed tag cleared
2020-08-24
05 David Oran New version available: draft-oran-icnrg-qosarch-05.txt
2020-08-24
05 (System) New version approved
2020-08-24
05 (System) Request for posting confirmation emailed to previous authors: David Oran <daveoran@orandom.net>
2020-08-24
05 David Oran Uploaded new revision
2020-08-10
04 Colin Perkins Eve Schooler review 2020-08-10; revised I-D needed
2020-08-10
04 Colin Perkins Tag Revised I-D Needed set.
2020-08-10
04 Colin Perkins IRTF state changed to Waiting for Document Shepherd from Awaiting IRSG Reviews
2020-08-10
04 Colin Perkins Intended Status changed to Informational from None
2020-06-23
04 Colin Perkins Sent for IRSG review 2020-06-23
2020-06-23
04 Colin Perkins IRTF state changed to Awaiting IRSG Reviews from Waiting for IRTF Chair
2020-06-23
04 Colin Perkins Changed consensus to No from Unknown
2020-04-08
04 Dirk Kutscher IRTF state changed to Waiting for IRTF Chair from Waiting for Document Shepherd
2020-04-08
04 Dirk Kutscher
1) Summary
This document is a position paper that describes how Quality of Service (QoS) capabilities ought to be accommodated
in ICN protocols like CCNx …
1) Summary
This document is a position paper that describes 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.

2) Review and Consensus
QoS in ICN is an important topic with a huge design space. ICNRG has
been discussing different specific protocol mechanisms as well as
conceptual approaches. This document presents architectural
considerations for QoS, leveraging ICN properties instead of merely
applying IP-QoS mechanisms - without defining a specific architecture
or specific protocols mechanisms yet. However, there is consensus in
ICNRG that this document, clarifying the author's views, could
inspire such work and should hence be published as a position paper.
2020-04-08
04 Dirk Kutscher Notification list changed to Dirk Kutscher <ietf@dkutscher.net>
2020-04-08
04 Dirk Kutscher Document shepherd changed to Dirk Kutscher
2020-04-08
04 Dirk Kutscher agreed to publish without adoption as a position paper (Informational RFC)
2020-04-08
04 Dirk Kutscher IRTF state changed to Waiting for Document Shepherd
2020-04-08
04 Dirk Kutscher Notification list changed to none
2020-04-08
04 Dirk Kutscher Changed group to Information-Centric Networking (ICNRG)
2020-04-08
04 Dirk Kutscher Changed stream to IRTF
2020-02-28
04 David Oran New version available: draft-oran-icnrg-qosarch-04.txt
2020-02-28
04 (System) New version approved
2020-02-28
04 (System) Request for posting confirmation emailed to previous authors: David Oran <daveoran@orandom.net>
2020-02-28
04 David Oran Uploaded new revision
2019-12-03
03 David Oran New version available: draft-oran-icnrg-qosarch-03.txt
2019-12-03
03 (System) New version approved
2019-12-03
03 (System) Request for posting confirmation emailed to previous authors: David Oran <daveoran@orandom.net>
2019-12-03
03 David Oran Uploaded new revision
2019-10-12
02 David Oran New version available: draft-oran-icnrg-qosarch-02.txt
2019-10-12
02 (System) New version approved
2019-10-12
02 (System) Request for posting confirmation emailed to previous authors: David Oran <daveoran@orandom.net>
2019-10-12
02 David Oran Uploaded new revision
2019-08-27
01 David Oran New version available: draft-oran-icnrg-qosarch-01.txt
2019-08-27
01 (System) New version approved
2019-08-27
01 (System) Request for posting confirmation emailed to previous authors: David Oran <daveoran@orandom.net>
2019-08-27
01 David Oran Uploaded new revision
2019-08-09
00 David Oran New version available: draft-oran-icnrg-qosarch-00.txt
2019-08-09
00 (System) New version approved
2019-08-09
00 David Oran Request for posting confirmation emailed  to submitter and authors: David Oran <daveoran@orandom.net>
2019-08-09
00 David Oran Uploaded new revision