Summary: Has a Not Ready position. Has enough positions to pass.
Ballot question: "Is this draft ready for publication in the IRTF stream?"
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.
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.
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.
I'm the author