Subject: [icnrg] IRSG ballot closed: <draft-oran-icnrg-qosarch-05.txt> to Informational RFC

From: IESG Secretary <[email-masked]>
Date: Mon, 12 Oct 2020 05:28:12 -0700

The IRSG ballot for <draft-oran-icnrg-qosarch-05.txt> has been closed. The
evaluation for this document can be found at
https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 12 Oct 2020 09:36:30 -0400

> https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/

Thanks for the useful ballot comments on this draft. Here are my 
responses:

#Mallory’s comment:#

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

First, I’m not sure I understand the first sentence, unless Mallory 
was referring to this:

“1.1.  Applicability Assessment by ICNRG Chairs

    QoS in ICN is an important topic with a huge design space.  ICNRG 
has
    been discussing different specific protocol mechanisms as well as
    conceptual approaches.  This document presents architectural
    considerations for QoS, leveraging ICN properties instead of merely
    applying IP-QoS mechanisms - without defining a specific 
architecture
    or specific protocols mechanisms yet.  However, there is consensus 
in
    ICNRG that this document, clarifying the author's views, could
    inspire such work and should hence be published as a position 
paper.”

This was supplied by the ICNRG Chair to position the document relative 
to other ongoing work in ICNRG. I’m not sure it’s my place to rework 
this. As general matter, I’ll defend the draft as being definitive 
where I assessed the principles I proposed to be solid, and 
intentionally open-ended where that is not so. While I certainly hoped 
to be inclusive, I certainly don’t believe this document (or perhaps 
any other at this stage) could confidently claim to “presenting the 
research as a whole”.

On the comment about setting a “low bar”, I respectfully disagree 
with Mallory’s assessment. Perhaps there’s just a mis-communication, 
since I view QoS as a zero-sum game and therefore there’s neither a 
high bar nor a low bar where QoS machinery is concerned. I’d 
definitely be interested in trying to get to the bottom of where Mallory 
thinks the draft falls short in proposing a general direction for QoS 
architecture for ICN protocols.

#Spencer’s comments, with responses embedded:#

	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 :-)

Response: I think it’s appropriate to have a forward reference to the 
discussion later in the document. I’ll put an asterisk in the table 
and the forward pointer below the table, it you think that would help.

	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.

Response: How about I reword this as “Further, accumulated experience 
seems to indicate that QoS is not helpful under most network 
conditions:”

	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"?

Response: Sure, will use your suggested wording.

	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.

Response: well, yes, if you have path-aware signaling the timescales are 
certainly problematic. What I’m getting at here does require a fair 
amount of “reading between the lines”, so the tradeoff is whether to 
go into a long digression about who is in charge of mobility measurement 
and decision making, and where the state needed to do it resides. The 
mental model underlying the assertion in the text is:

- the client machine (consumer in the ICN parlance) has the best idea 
about whether it is likely to move soon  (e.g. history, GPS and 
accelerometers) rather than network elements like mobility managers or 
routers.
- it may have information about *where* it is likely to move if it has a 
modest amount of knowledge of the local network environment.
- It is somewhere between easy and trivial to place a hint about this 
into interest messages it sends.
- ICN routers can use this hint to avoid wasting cache space at routers 
at or closer to the consumer than its current point of attachment, and 
to (depending on how accurate the information is) preferentially cache 
responses for retry after mobility at or close to the topological join 
point (or anchor point if the mobility protocol uses mobility anchors).

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

Response: given the above discussion, perhaps the reasoning behind the 
words is more justifiable? The question is whether we should just leave 
things as they are, or I put in a long “aside” so readers have a 
better idea what I’m getting at. An alternative would be to put in a 
list of references to ICN mobility work that, taken in aggregate, would 
justify the point I’m making, but I don’t like that solution as it 
just sends the reader on an extended tour into ICN mobility designs. 
Advice solicited.

#Mirja comment:#
	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.

Response: as author I don’t care, but I’d ask the (other) ICNRG 
chair whether the ICNRG has a preference. Of course as author I have a 
preference to settle this quickly if we want to change to the ISE 
stream.

[end of ballot comments and responses]

DaveO

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 12 Oct 2020 10:47:20 -0500

Hi, Dave,

You're such a good author :-).

I have a couple of comments below, but I'm fine with your other responses
to me.

Best,

Spencer

On Mon, Oct 12, 2020 at 8:37 AM David R. Oran <[email-masked]> wrote:

> Thanks for the useful ballot comments on this draft. Here are my responses:
> Mallory’s comment:
>
> “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
> First, I’m not sure I understand the first sentence, unless Mallory was
> referring to this:
>
> QoS in ICN is an important topic with a huge design space. ICNRG has
> applying IP-QoS mechanisms - without defining a specific architecture
> or specific protocols mechanisms yet. However, there is consensus in
> inspire such work and should hence be published as a position paper.”
>
> This was supplied by the ICNRG Chair to position the document relative to
> other ongoing work in ICNRG. I’m not sure it’s my place to rework this. As
> general matter, I’ll defend the draft as being definitive where I assessed
> the principles I proposed to be solid, and intentionally open-ended where
> that is not so. While I certainly hoped to be inclusive, I certainly don’t
> believe this document (or perhaps any other at this stage) could
> confidently claim to “presenting the research as a whole”.
>
> On the comment about setting a “low bar”, I respectfully disagree with
> Mallory’s assessment. Perhaps there’s just a mis-communication, since I
> view QoS as a zero-sum game and therefore there’s neither a high bar nor a
> low bar where QoS machinery is concerned. I’d definitely be interested in
> trying to get to the bottom of where Mallory thinks the draft falls short
> in proposing a general direction for QoS architecture for ICN protocols.
> Spencer’s comments, with responses embedded:
>
> 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.
>
> 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.
>
> discussion later in the document. I’ll put an asterisk in the table and the
> forward pointer below the table, it you think that would help.
>
> This text
>
> Further, accumulated experience seems to indicate that QoS is helpful
> 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
>    -
>    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
>    - your QoS machinery cannot respond quickly enough to maintain the
>       advertised service quality continuously, or
>       - resource allocations are sufficiently conservative to result in
>    Nevertheless, though not universally deployed, QoS is advantageous at
> seems to indicate that QoS is not helpful under most network conditions:”
>
> I think this text
>
>    This may
> 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
> 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
> certainly problematic. What I’m getting at here does require a fair amount
> of “reading between the lines”, so the tradeoff is whether to go into a
> long digression about who is in charge of mobility measurement and decision
> making, and where the state needed to do it resides. The mental model
> underlying the assertion in the text is:
>
>    - it may have information about *where* it is likely to move if it has
>    a modest amount of knowledge of the local network environment.
>    -
>    ICN routers can use this hint to avoid wasting cache space at routers
>    at or closer to the consumer than its current point of attachment, and to
>    (depending on how accurate the information is) preferentially cache
>    - 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.
>
> things as they are, or I put in a long “aside” so readers have a better
> idea what I’m getting at. An alternative would be to put in a list of
> references to ICN mobility work that, taken in aggregate, would justify the
> point I’m making, but I don’t like that solution as it just sends the
> reader on an extended tour into ICN mobility designs. Advice solicited.
>
I'm sympathetic here (and more sympathetic given your excellent response).

What I was chafing at, was "within an RTT (or a few RTTs)". I'm not smart
about ICNs, but to transport guys, this sounds like a classic recipe for
churning when you have unstable network paths (think someone standing
precisely on the handoff boundary between two cell towers and switching
hands once or twice per minute - that's the worst scenario, but damping
matters, in transport.

Would it matter in ICN, or are the timescales already longer than TCP/QUIC
RTTs?

Best,

Spencer

> Mirja comment:
>
> 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
> Response: as author I don’t care, but I’d ask the (other) ICNRG chair
> whether the ICNRG has a preference. Of course as author I have a preference
> to settle this quickly if we want to change to the ISE stream.
>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 28 Oct 2020 00:00:59 +0000

Spencer, Dave – thanks.

Mallory – I believe there are a couple of questions for clarification of your review below.

Cheers,
Colin

> On 12 Oct 2020, at 16:47, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Dave, 
> 
> I have a couple of comments below, but I'm fine with your other responses to me. 
> 
> Best,
> 
> Spencer
> 
> On Mon, Oct 12, 2020 at 8:37 AM David R. Oran <[email-masked] <mailto:[email-masked]>> wrote:
> https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/ <https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/>
> First, I’m not sure I understand the first sentence, unless Mallory was referring to this:
> 
> This was supplied by the ICNRG Chair to position the document relative to other ongoing work in ICNRG. I’m not sure it’s my place to rework this. As general matter, I’ll defend the draft as being definitive where I assessed the principles I proposed to be solid, and intentionally open-ended where that is not so. While I certainly hoped to be inclusive, I certainly don’t believe this document (or perhaps any other at this stage) could confidently claim to “presenting the research as a whole”.
> 
> On the comment about setting a “low bar”, I respectfully disagree with Mallory’s assessment. Perhaps there’s just a mis-communication, since I view QoS as a zero-sum game and therefore there’s neither a high bar nor a low bar where QoS machinery is concerned. I’d definitely be interested in trying to get to the bottom of where Mallory thinks the draft falls short in proposing a general direction for QoS architecture for ICN protocols.
> 
> Response: I think it’s appropriate to have a forward reference to the discussion later in the document. I’ll put an asterisk in the table and the forward pointer below the table, it you think that would help.
> 
> This text
> 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
> Response: How about I reword this as “Further, accumulated experience seems to indicate that QoS is not helpful under most network conditions:”
> 
> I think this text
> 
>    This may
> experimentation as per https://tools.ietf.org/html/rfc8311 <https://tools.ietf.org/html/rfc8311>. Perhaps "that is commonly
> Response: well, yes, if you have path-aware signaling the timescales are certainly problematic. What I’m getting at here does require a fair amount of “reading between the lines”, so the tradeoff is whether to go into a long digression about who is in charge of mobility measurement and decision making, and where the state needed to do it resides. The mental model underlying the assertion in the text is:
> 
> the client machine (consumer in the ICN parlance) has the best idea about whether it is likely to move soon (e.g. history, GPS and accelerometers) rather than network elements like mobility managers or routers.
> it may have information about where it is likely to move if it has a modest amount of knowledge of the local network environment.
> It is somewhere between easy and trivial to place a hint about this into interest messages it sends.
> ICN routers can use this hint to avoid wasting cache space at routers at or closer to the consumer than its current point of attachment, and to (depending on how accurate the information is) preferentially cache responses for retry after mobility at or close to the topological join point (or anchor point if the mobility protocol uses mobility anchors).
> 
> 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"?
> Response: given the above discussion, perhaps the reasoning behind the words is more justifiable? The question is whether we should just leave things as they are, or I put in a long “aside” so readers have a better idea what I’m getting at. An alternative would be to put in a list of references to ICN mobility work that, taken in aggregate, would justify the point I’m making, but I don’t like that solution as it just sends the reader on an extended tour into ICN mobility designs. Advice solicited.
> 
> What I was chafing at, was "within an RTT (or a few RTTs)". I'm not smart about ICNs, but to transport guys, this sounds like a classic recipe for churning when you have unstable network paths (think someone standing precisely on the handoff boundary between two cell towers and switching hands once or twice per minute - that's the worst scenario, but damping matters, in transport. 
> 
> Would it matter in ICN, or are the timescales already longer than TCP/QUIC RTTs?
> 
> Best,
> 
> Spencer
> Mirja comment:
> 
> Response: as author I don’t care, but I’d ask the (other) ICNRG chair whether the ICNRG has a preference. Of course as author I have a preference to settle this quickly if we want to change to the ISE stream.
> 

-- 
Colin Perkins
https://csperkins.org/