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

["David R. Oran" <[e-mail]>]

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.

#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