Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols
RFC 9064
Not Ready
Yes
No Objection
Recuse
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
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
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
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
I'm the author