[icnrg] Spencer Dawkins' Yes on draft-oran-icnrg-qosarch-05: (with COMMENT)

[Spencer Dawkins via Datatracker <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-oran-icnrg-qosarch-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/



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