Re: [icnrg] [irsg] IRSG review request draft-oran-icnrg-qosarch-04

["Schooler, Eve M" <[e-mail]>]

+ ICNRG (meant to cc originally, but I seem only to have cc’d the chairs)

Hi Dave,

I think the document is sound technically, at least in terms of what it discusses from the ICN perspective.

However, one aspect about QoS that seems less clear from the document (but that you hint at in various places, yet never seem to really sink your teeth into fully) is how does one specify QoS treatments, when the QoS spans multiple kinds of resources, not only the network but also storage/caches, compute resources, and energy (e.g., availability/excess clean energy):

  *   section 4, Table 2: when you identify the kinds of  resources ICN requires, there is mention of resources for Compute capacity for forwarding functions, but not for in-network computation.
  *   section 5: this discusses TCP/IP equivalence classes and Intserv and Diffserv, but made me wonder if there is a similar discussion that could be had about QoS from the standpoint of computation engines, e.g., Kubernetes or other orchestrated workload/offload frameworks.
  *   Section 6.3: Interesting tradeoff questions are raised between reliability vs latency vs bandwidth. Tradeoff algorithms would seem to need joint-optimization expertise, and so we will likely need the kind of work that folks like Edmund Yeh (Northeastern) and Andrea Goldsmith (Stanford) are doing on joint-optimization of caching and routing for heterogeneous wireless networks (and they’ve recently augmented their research focus to include joint optimization for caching-routing-and-compute).
  *   Section 6.5: great discussion here of the interplay between network QoS and caching, from both consumers and producers.
  *   Section 7 and 7.1: the principles list does include caching as something needing further specification, but I wonder if 7.1 could do more to comment on the impact of computational resources for in-network compute (vs forwarding functions).


My thoughts on this topic are not fully formed, but I thank you for getting me to wonder aloud if this is the right document in which to raise these issues or if a broader QoS technical discussion and proposed guidelines should appear somewhere else. The reason why ICN has been an interesting place for this discussion is because of the close partnership with caching; my intuition is that if we can get QoS to comprehend not only network QoS but caching QoS, then it might help us to specify QoS and QoS tradeoffs among other a range of resources.

Best regards,
Eve


From: David R. Oran <[e-mail]>
Sent: Monday, August 10, 2020 5:59 AM
To: Schooler, Eve M <[e-mail]>
Cc: Colin Perkins <[e-mail]>; Steering Group <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [irsg] IRSG review request draft-oran-icnrg-qosarch-04


Thanks a ton. These are great editorial suggestions. I’l get to them in the next few days and generate an updated draft to look at.

Did you have any technical comments though?

On 10 Aug 2020, at 4:22, Schooler, Eve M wrote:

Hi Colin, Dave, ICNRG, IRSG,

Below is my review for draft-oran-icnrg-qosarch-04.

In summary, the I-D is very well written. As instructed, my review is not a technical review.

My comments instead target clarity for non-experts and consistency in terminology, context, and references.

Best regards,

Eve



-----



Abstract:

  *   The abstract states, “This document is not a product of the IRTF ICNRG….”. Yet the draft would seem to be a byproduct of the ongoing I-Ds and discussions of the WG, and has been through last call there?  Why not simply state, “This document has the support of the participants in the ICN RG for publication as an individual submission, has the support of the participants in the RG, and has been through last call.”  [Note: Section 1.1, Applicability Assessment – states the status in this manner.]
  *   For clearer parsing, either parenthesize or put commas around the phrase “in addition to memory, CPU and link bandwidth”.



Section 3,  Background:

  *   Page 4: “…they exhibit non-zero utility when offered traffic to carry”. This phrase is meant to clarifying what QoS means, but the wording is a bit obtuse.
  *   Page 4: “…optimizing the overall utility delivered to all demand under  the constraint of available resources.” Seems like “demand” is an extra word or perhaps “demand” is meant to read “demands”? Either way the sentence was hard to parse.



Section 3.1,  Congestion Control basics relevant to ICN:

Page 6:

  *   For clarity, re-jigger the very first sentence. Put the phrase “congestion control is necessary in order to” at the end of the sentence, all in one piece (rather than having it cut in half with another phrase). The sentence would become, “In any packet network…, congestion control is necessary in order to:”
  *   The bottom paragraph describes the behavior of congestion control in ICN. However the description assumes that the reader already understands the basic Interest-Data behaviors in ICN.  As a result, I think the document would benefit from an additional paragraph or section about how ICN operates at its most basic level, so that the nuances of the subsequent phrases in this paragraph – such as “per-Interest/Data state” and “outstanding Interests” and “accepting one Interest packet from a downstream node” –  can be fully understood.

Page 7:

  *   “two characteristics of NDN and CCNx-like protocols” are mentioned, but then items 1 and 2 listed are not really stated as characteristics. Call out the characteristics more clearly (e.g., reword the opening sentences or boldify the key phrases). As written, it is not clear if the characteristics are RTT is bounded (or alternatively Bounded Interest lifetime), and Data packets traverse inverse links (or alternatively Data packets can be congestion marked or…).
  *   Item 1: “the allocations do not have to deal with an arbitrarily long tail”. Allocations of what? resources in general? Note that allocations are discussed more in the next section, but at this point in the document, more context is needed. Similarly, “the result would be highly pessimistic” could also use some additional detail, i.e., spell out briefly what you mean by pessimistic/conservative, e.g., resulting in an allocation that likely consumes more resources than are needed.



Section 5, How does this relate to QoS in TCP/IP?

  *   Page 9, table 3: the Forwarder memory entry lists its IP relevance as MAYBE and the TCP/IP usage is listed as “not needed for output-buffered designs”. It would be helpful to give more detail about this comment, in the text or in the table.
  *   Page 10, table 4: the first entry of the table lists equivalence classes and the IP 5-tuple. It would be helpful if the acronyms given for the parts of the 5-tuple in the table are somehow referenced in the text explaining equivalence classes.
  *   Page 10, last paragraph: “…one still runs into limits on the number of queues required.” This phrase begs the question, “queues for what?”, something along the lines of “…queues required to achieve the requested QoS classes”.
  *

Section 6.1, Equivalence class capabilities:

  *   Page 11: What is meant by “tokenized…names”?



Section 6.2, Topology interactions with QoS:

  *   Page 11, O(#flows) vs O(#active Interst/Data exchanges): What is the relative gain or improvement?
  *   Page 11, last sentence, typo: “hase” --> “has”



Section 6.3, Specification of QoS treatments:

  *   Page 12, first sentence, typo: “Difserv” --> “Diffserv”
  *   Page 12, bulleted list, 3rd bullet: “downstream errors”, clarify what is meant by upstream vs downstream when dealing with Interest vs Data packets?
  *   Page 12, the paragraph beginning “Stateless forwarding…”: Not clear how the example given follows from the point made at the top of the paragraph.



Section 6.4, ICN forwarding semantics effect on QoS:

  *   Page 13: is the reference to “multi-destination parallel requests” the same or different from “the multi-destination/multi-path forwarding model in ICN”? If the same, then use the same terminology. If different, clarify that this is yet another kind of forwarding semantics.
  *   Not sure what the second paragraph implies. How does open-loop packet sources vs asymmetries between producers and consumers relate back to resource allocation needs?



Section 6.5, QoS Interactions with Caching:

  *   Page 13: Clarify what is meant by “soft or hard partitioning of cache resources”.



Section 7, A strawman set of principles to guide QoS architecture for ICN:

  *   Page 15,  “Survive transient outage of either the producer or links close to the producer”: this phrase appears in a couple places on this page. This doesn’t really cover the case where a producer is mobile. Perhaps reword to capture this case, with something along the lines of, “Survive transient producer reachability or link outages….”
  *   Page 16: another example is given of “link errors or outages”, which could be amended to cover producer reachability as well.
  *   Page 16: Consider being more specific re “when consumers move in” --> “when consumers are mobile in”?
  *   Page 17: Define more specifically what’s meant by “loose latency control”



Section 7.1: What about the richer QoS semantics available with INTServ-like traffic control?

  *   Page 18, top of page, end of bullet number 2: Can you give an example where “it may or may not be possible to explicitly release that state”? Are you saying that the release of the state needs to be signaled explicitly and it is not typically?
  *   Page 19, bulleted list at bottom of page, 1st bullet: Cannot tell if points (a) and (b) are meant as behaviors the packet can optionally request (vs the packet is always required to request).   Also this is the first mention of a “Repo”, which could benefit by brief definition, if not here then earlier in section 3, along with the suggested additional description of the basic operation of ICN.



Section 10, References:

  *   Stylistically, most of the references that aren’t RFCs or I-Ds have placed the trailing double quote (that would normally appear at the end of the title of the paper referenced) in the wrong place!
  *   Be consistent in the citations. Many papers are referenced from the ACM ICN conference and SIGCOMM ICN workshop before it became a conference. Make sure to be consistent in how you cite these; some include months, others not, one has multiple dates [BenAbraham2018]. Same holds for how Vol. and No. are cited (a couple use Vol# and No#).
  *   Some references are listed with “no date” as they are web pages, e.g., Wikipedia entries. The IEEE for example will accept a web link, and  I’ve sometimes seen a date provided as “[accessed 09-Aug-2020]” (for instance the Wayback Machine could find a web page from that date or thereabouts if it were a relatively public page).
  *   [Auge2018] is a reference where one of the authors has an accent in the last name, and the text version of the I-D has not converted it properly.



Nits:

  *   Acronyms that could use spelling out the first time used: AIMD, TOS, RSVP, TLV, TSPEC
  *   Consistent reference to: INTServ/IntServ/Intserv
  *   Some of the section headers could be shortened (3, 7, 7.1) without loss of intent







From: irsg <[e-mail]<mailto:[e-mail]>> On Behalf Of Colin Perkins
Sent: Tuesday, June 23, 2020 8:24 AM
To: [e-mail]<mailto:[e-mail]> Steering Group <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [irsg] IRSG review request draft-oran-icnrg-qosarch-04



IRSG members,

The ICNRG Research Group has requested that draft-oran-icnrg-qosarch-04<https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/> be considered for publication as an IRTF RFC. To progress this draft, we now need at least one IRSG member to volunteer to provide a detailed review of the draft, as follows:


The purpose of the IRSG review is to ensure consistent editorial and technical quality for IRTF publications. IRSG review is not a deep technical review. (This should take place within the RG.) At least one IRSG member other than the chair of the RG bringing the work forth must review the document and the RG’s editorial process.

IRSG reviewers should look for clear, cogent, and consistent writing. An important aspect of the review is to gain a critical reading from reviewers who are not subject matter experts and, in the process, assure the document will be accessible to those beyond the authoring research group. Also, reviewers should assess whether sufficient editorial and technical review has been conducted and the requirements for publication described in RFC 5743  have been met. Finally, reviewers should check that appropriate citations to related research literature have been made.

Reviews should be written to be public. Review comments should be sent to the IRSG and RG mailing lists and entered into the tracker. All IRSG review comments must be addressed. However, the RG need not accept every comment. It is the responsibility of the shepherd to understand the comments and ensure that the RG considers them including adequate dialog between the reviewer and the author and/or RG. Reviews and their resolution should be entered into the tracker by the document shepherd.

The IRSG review often results in the document being revised. Once the reviewer(s), authors, and shepherd have converged on review comments, the shepherd starts the IRSG Poll on whether the document should be published.



Please respond to this message if you’re able to perform such a review, and indicate the approximate time-frame by which you’ll be able to complete it. The document shepherd write-up is available at  https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/shepherdwriteup/<https://datatracker.ietf.org/doc/draft-irtf-icnrg-icn-lte-4g/shepherdwriteup/>

Thanks!
Colin


DaveO