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

Note: This ballot was opened for revision 05 and is now closed.

Ballot question: "Is this draft ready for publication in the IRTF stream?"

Mallory Knodel Not Ready

Comment (2020-09-24 for -05)
No email
send info
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.

Dirk Kutscher Yes

Eve Schooler Yes

Spencer Dawkins Yes

Comment (2020-09-16 for -05)
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.

Mirja K├╝hlewind (was Not Ready) No Objection

Comment (2020-09-11 for -05)
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.

David Oran Recuse

Comment (2020-09-08 for -05)
No email
send info
I'm the author