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

From: Spencer Dawkins via Datatracker <[email-masked]>
Date: Wed, 16 Sep 2020 17:52:31 -0700

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.

---

From: "Dirk Kutscher" <[email-masked]>
Date: Thu, 17 Sep 2020 10:44:00 +0200

Thanks a lot for looking into this, Spencer!

> understand the term used on page 3.

Fair comment. It's a  well-understood term for ICN folks, but we could 
consider addressing a broader audience here. There is also 
https://datatracker.ietf.org/doc/rfc8793/ (Terminology) that mentions 
flow balance in the big-picture-overview -- that could be referenced as 
well if a revision was to be done.

> seems backwards to me, because the list of bullets that follows 

IMO, this is just trying level expectations and debunk some QoS myths 
that might aggravate the understanding of the document.

>    least for some applications and some network environments.

	* applications with steep utility functions [Shenker2006], such as
       real-time multimedia

    *  applications with safety-critical operational constraints, such 
as
       avionics or industrial automation

    *  dedicated or tightly managed networks whose economics depend on
       strict adherence to challenging service level agreements (SLAs)

I was thinking that this illustrates it quite nicely. Do you think that 
more is needed?

> with ECT(1) experimentation as per 
> https://tools.ietf.org/html/rfc8311. Perhaps

Probably nice to have in case a revision is done.

> seems like deleting it would be just as clear and accurate.

So, here I agree that, in a non-ICN context, the original text could 
raise some eye brows. However in this context, I don't see a need for 
change, because of the different nature of ICNs (conceptually less need 
for path-awareness) and light-weight mobility management approaches that 
ICNs enables.

Thanks,
Dirk

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 17 Sep 2020 08:40:21 -0500

Hi, Dirk,

I'm fine with most of these replies. On one of my comments, I wasn't clear
enough (please see below).

Best,

Spencer

On Thu, Sep 17, 2020 at 3:44 AM Dirk Kutscher <[email-masked]> wrote:

> IMO, this is just trying level expectations and debunk some QoS myths that
> might aggravate the understanding of the document.
>
>    -
>    applications with safety-critical operational constraints, such as
>    -
>    dedicated or tightly managed networks whose economics depend on
I agree that the examples are good. What I SHOULD have said in my comment
was that the leading sentence says "QoS is helpful in a fairly
narrow range" but the examples are for cases where it is not helpful :-)

I should have suggested "QoS is only helpful in a fairly narrow range" -
adding "only". Then the examples make sense - "not helpful in this case, or
this one, or this one".

Best,

Spencer

> So, here I agree that, in a non-ICN context, the original text could raise
> some eye brows. However in this context, I don't see a need for change,
> because of the different nature of ICNs (conceptually less need for
> path-awareness) and light-weight mobility management approaches that ICNs
> enables.
>
> Thanks,
> Dirk
>

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 17 Sep 2020 09:45:35 -0400

Thanks Spencer - adding “only” in that sentence helps a lot. I’ll 
note it for the next revision before sending to RFCed.

On 17 Sep 2020, at 9:40, Spencer Dawkins at IETF wrote:

>> I'm not an ICN guy, but I can translate all of the terms on both 
>> sides of
>> Table
>> 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
>> seems backwards to me, because the list of bullets that follows 
>> describe
>> where
>> QoS is NOT helpful:
>>
>> that
>> is approximately correct today, but TSVWG is certainly trying to 
>> change
>> that
>> 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
>> raise

> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 17 Sep 2020 17:56:48 -0500

Hi, Dave,

On Thu, Sep 17, 2020 at 8:45 AM David R. Oran <[email-masked]> wrote:

> Thanks Spencer - adding “only” in that sentence helps a lot. I’ll note it
> for the next revision before sending to RFCed.
>
Thank you, and I'm sorry it took two shots to provide a clear suggestion!

Best,

Spencer

>> change, because of the different nature of ICNs (conceptually less need for