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

[Spencer Dawkins at IETF <[e-mail]>]

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 <[e-mail]> wrote:

> On 12 Oct 2020, at 8:28, IESG Secretary wrote:
>
> 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/
>
> 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.
>
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
> 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
>