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

From: "Schooler, Eve M" <[email-masked]>
Date: Tue, 11 Aug 2020 00:46:51 +0000

+ 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 <[email-masked]>
Sent: Monday, August 10, 2020 5:59 AM
To: Schooler, Eve M <[email-masked]>
Cc: Colin Perkins <[email-masked]>; Steering Group <[email-masked]>; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Colin Perkins
Sent: Tuesday, June 23, 2020 8:24 AM
To: [email-masked]<mailto:[email-masked]> Steering Group <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 20 Aug 2020 14:07:58 -0400

Thanks a bunch for these substantial thoughts on areas the document 
might address but currently doesn’t. This message definitely qualifies 
for TL;DR, but if it does generate a spirited discussion on the ICNRG 
list I think that would be a good thing (this message cc’s the IRSG 
since Eve’s original message with technical comments on the QoSArch 
document included the larger community, but I encourage further 
follow-up to stay on the ICNRG list).

I have a rather narrow view of what QoS belongs in the network layer 
(L3) as opposed to higher in the stack and I think that colors my 
thoughts on these issues pretty strongly.

In particular, I think there are two themes to this:

1) whether “in network computation” is appropriate to represent in 
the ICN inter-networking protocol (NDN or CCNx). One view is that its 
only real role is to deliver Interests to endpoints (or caches) holding 
the desired named content and returning the corresponding data, 
Alternatively one could consider resources for computational tasks 
beyond to this forwarding/routing function in scope.

2) whether the resources addressable using QoS treatments are just the 
“abstract” resources represented by protocol functions, or more 
directly the underlying resources used by the protocol to achieve those 
functions. For example, PIT capacity, forwarding packet rate, and cache 
capacity would be what were manipulated by requested QoS treatments, 
while things like CPU, DRAM memory, or energy consumption would not.

It would be really interesting to get people’s views on this. My own 
view, clearly represented by the current text of the QoSArch document is 
that for (1) it’s only the role of getting Interest and Data delivered 
that is relevant for ICN network-layer QoS, and for (2) only the 
abstract resources are what gets modeled.

Some more detailed thoughts are embedded.

On 10 Aug 2020, at 20:46, Schooler, Eve M wrote:

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

Well, the document doesn’t reach the goal of being an actual specified 
QoS architecture. I’m just trying to point in a particular direction. 
So, the draft talks about the ability to specify richer QoS treatments 
than can be specified for IP, and to be able to represents tradeoffs as 
well as absolutes (e.g. sacrifice latency in order to get higher 
satisfaction rate). It doesn’t come anywhere close to saying exactly 
what treatments might be included or exactly how they are achieved 
algorithmically.

My goal is that the ICNRG and researchers in general will sink their 
teeth into this and that the QoSArch document, if published, can serve 
as pointing in a productive direction.
>
>   *   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.

I tried to clarify above that this is intentional. I think allocating 
compute resources via the L3 forwarding protocol would be a mistake and 
a pretty dramatic layer violation (although sometimes layer violations 
are called for and result in important advances, particularly if the 
violated layer boundary was poorly chosen by the architects). If you 
look at some of our current work like CFN 
(https://dl.acm.org/doi/10.1145/3357150.3357395) the resource management 
for placing and allocating compute is a protocol running **on top** of 
the ICN protocols, not inside as QoS-oriented extensions. What it 
*could* do for example (but doesn’t since current protocols don’t 
have the hooks) is use QoS machinery to ensure ongoing computations get 
higher reliability for result delivery than initiating new computations, 
or to rank less important computations to have less stringent latency 
bounds.

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

Given things like Kubernetes, Istio, and friends that place 
computations, there is certainly lots of work to be done to design joint 
optimization of routing, network capacity, and compute placement/load. 
The question for me is what inherent QoS treatments (and associated 
algorithms) in the L3 protocols are needed in order to enable higher 
layer resource management protocols to have the information they need, 
and the knobs to turn, in order to to that. My guess (although I can’t 
prove it) is that the needed capabilities in the L3 ICN protocols are 
quite modest, and are captured by the QoSArch document reasonably well. 
If that’s not the case then I’d really love to hear what might be 
missing or wrong in the overall approach I recommend.

One big open question that I do talk about in the document is whether 
Intserv-like traffic control is useful and if explicit admission control 
is needed. In the IP world, things worked out that supplying traffic 
control and admission control directly to consumer end hosts was a 
colossal no-op/failure, but that using those capabilities internal to 
individual AS’s to do traffic engineering turned out to be quite 
widely employed.

The provisional conclusion I put in the document is that it would not be 
too difficult to add traffic control to the protocols, but that adding 
admission control would be tricky at best and horrendously complicated 
at worst because of the multi-path/multi-destination forwarding model 
and the topological independence of application names.

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

Yes. I recommend that all those schemes operate at a higher layer than 
the L3 forwarding, but do influence the routing protocol in substantial 
ways. So, I would say that when we do work on ICN routing protocols this 
is the place to dig in rather than the data plane forwarding/caching 
primitives. Some prior work has tried to to the whole thing adaptively 
through stochastic forwarding algorithms (e.g. 
https://arxiv.org/abs/1505.05259). I’d need serious convincing that 
this direction has a lot of promise (nor its partner in crime, machine 
learning running in the data plane of switches to adapt forwarding and 
caching). I could easily be wrong here of course…

>   *   Section 6.5: great discussion here of the interplay between 
> network QoS and caching, from both consumers and producers.

Thanks!

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

The dives straight into the core of what it means to have 
“in-network” computing as opposed to “on-network” computing. My 
own view is that if we don’t sort this out with reasonable 
architectural choices we’ll wind up recapitulating the 
less-than-stellar history of service chaining, VNFs, and the like.

In the specific context of ICN, for me some good guideposts are:

- If you  need to transform data, you don’t do it in forwarders since 
the data is hashed and immutable
- If you need to look at payloads, you don’t do it in forwarders since 
the data is encrypted and you don’t have the keys
- If you want to compute in the same hardware box as the box that’s 
doing forwarding, that’s fine, but you are “on-network” rather 
than “in-network” since you are just a consumer/producer co-located 
with the forwarder.

Now, I actually think this is a good division, since most of the things 
people are trying to embed in the packet forwarding path of switches is 
really hard to do if it involves anything other than affecting the 
forwarding (e.g. firewall, DDoS mitigations, etc.). Now it my be that 
certain important optimizations of the computing functions running 
“on-network” can be helped by pushing expensive operations down to 
the switch hardware, just as people have been doing for years with smart 
NICs. That however, is not what I think people are proposing when they 
talk about “in-network” computing.

>
> 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
>
I hope this can generate some good discussion!

After going through these comments and thoughts, I don’t plan on 
making further changes to the current draft, so I’m going to submit it 
after waiting a day or two more for any further feedback on my proposed 
changes from the editorial comments.

Thanks again,

DaveO.

---

From: "Schooler, Eve M" <[email-masked]>
Date: Mon, 24 Aug 2020 16:03:48 +0000

Hi Dave,
Thanks for your articulate and thoughtful responses, especially your explanations of on- versus in-network computation, and of the QoS and layering principles. Your plan to address the more editorial comments (see previous e-mails) in your next version sounds like the right plan.
I look forward to your updated draft,
Eve

From: David R. Oran <[email-masked]>
Sent: Thursday, August 20, 2020 11:08 AM
To: Schooler, Eve M <[email-masked]>
Cc: [email-masked]; [email-masked]; Colin Perkins <[email-masked]>; Steering Group <[email-masked]>
Subject: Re: [icnrg] [irsg] IRSG review request draft-oran-icnrg-qosarch-04

Thanks a bunch for these substantial thoughts on areas the document might address but currently doesn’t. This message definitely qualifies for TL;DR, but if it does generate a spirited discussion on the ICNRG list I think that would be a good thing (this message cc’s the IRSG since Eve’s original message with technical comments on the QoSArch document included the larger community, but I encourage further follow-up to stay on the ICNRG list).

I have a rather narrow view of what QoS belongs in the network layer (L3) as opposed to higher in the stack and I think that colors my thoughts on these issues pretty strongly.

1) whether “in network computation” is appropriate to represent in the ICN inter-networking protocol (NDN or CCNx). One view is that its only real role is to deliver Interests to endpoints (or caches) holding the desired named content and returning the corresponding data, Alternatively one could consider resources for computational tasks beyond to this forwarding/routing function in scope.

2) whether the resources addressable using QoS treatments are just the “abstract” resources represented by protocol functions, or more directly the underlying resources used by the protocol to achieve those functions. For example, PIT capacity, forwarding packet rate, and cache capacity would be what were manipulated by requested QoS treatments, while things like CPU, DRAM memory, or energy consumption would not.

It would be really interesting to get people’s views on this. My own view, clearly represented by the current text of the QoSArch document is that for (1) it’s only the role of getting Interest and Data delivered that is relevant for ICN network-layer QoS, and for (2) only the abstract resources are what gets modeled.

Hi Dave,

Well, the document doesn’t reach the goal of being an actual specified QoS architecture. I’m just trying to point in a particular direction. So, the draft talks about the ability to specify richer QoS treatments than can be specified for IP, and to be able to represents tradeoffs as well as absolutes (e.g. sacrifice latency in order to get higher satisfaction rate). It doesn’t come anywhere close to saying exactly what treatments might be included or exactly how they are achieved algorithmically.

My goal is that the ICNRG and researchers in general will sink their teeth into this and that the QoSArch document, if published, can serve as pointing in a productive direction.

I tried to clarify above that this is intentional. I think allocating compute resources via the L3 forwarding protocol would be a mistake and a pretty dramatic layer violation (although sometimes layer violations are called for and result in important advances, particularly if the violated layer boundary was poorly chosen by the architects). If you look at some of our current work like CFN (https://dl.acm.org/doi/10.1145/3357150.3357395) the resource management for placing and allocating compute is a protocol running on top of the ICN protocols, not inside as QoS-oriented extensions. What it could do for example (but doesn’t since current protocols don’t have the hooks) is use QoS machinery to ensure ongoing computations get higher reliability for result delivery than initiating new computations, or to rank less important computations to have less stringent latency bounds.

Given things like Kubernetes, Istio, and friends that place computations, there is certainly lots of work to be done to design joint optimization of routing, network capacity, and compute placement/load. The question for me is what inherent QoS treatments (and associated algorithms) in the L3 protocols are needed in order to enable higher layer resource management protocols to have the information they need, and the knobs to turn, in order to to that. My guess (although I can’t prove it) is that the needed capabilities in the L3 ICN protocols are quite modest, and are captured by the QoSArch document reasonably well. If that’s not the case then I’d really love to hear what might be missing or wrong in the overall approach I recommend.

One big open question that I do talk about in the document is whether Intserv-like traffic control is useful and if explicit admission control is needed. In the IP world, things worked out that supplying traffic control and admission control directly to consumer end hosts was a colossal no-op/failure, but that using those capabilities internal to individual AS’s to do traffic engineering turned out to be quite widely employed.

The provisional conclusion I put in the document is that it would not be too difficult to add traffic control to the protocols, but that adding admission control would be tricky at best and horrendously complicated at worst because of the multi-path/multi-destination forwarding model and the topological independence of application names.

Yes. I recommend that all those schemes operate at a higher layer than the L3 forwarding, but do influence the routing protocol in substantial ways. So, I would say that when we do work on ICN routing protocols this is the place to dig in rather than the data plane forwarding/caching primitives. Some prior work has tried to to the whole thing adaptively through stochastic forwarding algorithms (e.g. https://arxiv.org/abs/1505.05259). I’d need serious convincing that this direction has a lot of promise (nor its partner in crime, machine learning running in the data plane of switches to adapt forwarding and caching). I could easily be wrong here of course…

Thanks!

The dives straight into the core of what it means to have “in-network” computing as opposed to “on-network” computing. My own view is that if we don’t sort this out with reasonable architectural choices we’ll wind up recapitulating the less-than-stellar history of service chaining, VNFs, and the like.

  *   If you need to transform data, you don’t do it in forwarders since the data is hashed and immutable
  *   If you need to look at payloads, you don’t do it in forwarders since the data is encrypted and you don’t have the keys
  *   If you want to compute in the same hardware box as the box that’s doing forwarding, that’s fine, but you are “on-network” rather than “in-network” since you are just a consumer/producer co-located with the forwarder.

Now, I actually think this is a good division, since most of the things people are trying to embed in the packet forwarding path of switches is really hard to do if it involves anything other than affecting the forwarding (e.g. firewall, DDoS mitigations, etc.). Now it my be that certain important optimizations of the computing functions running “on-network” can be helped by pushing expensive operations down to the switch hardware, just as people have been doing for years with smart NICs. That however, is not what I think people are proposing when they talk about “in-network” computing.

Best regards,
Eve

After going through these comments and thoughts, I don’t plan on making further changes to the current draft, so I’m going to submit it after waiting a day or two more for any further feedback on my proposed changes from the editorial comments.

Thanks again,

DaveO.

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 24 Aug 2020 14:25:06 -0400

Many thanks!
I’ll go ahead and get the draft update submitted!

On 24 Aug 2020, at 12:03, Schooler, Eve M wrote:

> Hi Dave,
> Thanks for your articulate and thoughtful responses, especially your 
> explanations of on- versus in-network computation, and of the QoS and 
> layering principles. Your plan to address the more editorial comments 
> (see previous e-mails) in your next version sounds like the right 
> plan.
> Cc: [email-masked]; [email-masked]; Colin Perkins 
> <[email-masked]>; Steering Group <[email-masked]>
> might address but currently doesn’t. This message definitely 
> qualifies for TL;DR, but if it does generate a spirited discussion on 
> the ICNRG list I think that would be a good thing (this message cc’s 
> the IRSG since Eve’s original message with technical comments on the 
> QoSArch document included the larger community, but I encourage 
> further follow-up to stay on the ICNRG list).
>
> only real role is to deliver Interests to endpoints (or caches) 
> holding the desired named content and returning the corresponding 
> data, Alternatively one could consider resources for computational 
> tasks beyond to this forwarding/routing function in scope.
>
> directly the underlying resources used by the protocol to achieve 
> those functions. For example, PIT capacity, forwarding packet rate, 
> and cache capacity would be what were manipulated by requested QoS 
> treatments, while things like CPU, DRAM memory, or energy consumption 
> would not.
>
> view, clearly represented by the current text of the QoSArch document 
> is that for (1) it’s only the role of getting Interest and Data 
> delivered that is relevant for ICN network-layer QoS, and for (2) only 
> the abstract resources are what gets modeled.
>
> Well, the document doesn’t reach the goal of being an actual 
> specified QoS architecture. I’m just trying to point in a particular 
> direction. So, the draft talks about the ability to specify richer QoS 
> treatments than can be specified for IP, and to be able to represents 
> tradeoffs as well as absolutes (e.g. sacrifice latency in order to get 
> higher satisfaction rate). It doesn’t come anywhere close to saying 
> exactly what treatments might be included or exactly how they are 
> achieved algorithmically.
>
> * section 4, Table 2: when you identify the kinds of resources ICN 
> requires, there is mention of resources for Compute capacity for 
> compute resources via the L3 forwarding protocol would be a mistake 
> and a pretty dramatic layer violation (although sometimes layer 
> violations are called for and result in important advances, 
> particularly if the violated layer boundary was poorly chosen by the 
> architects). If you look at some of our current work like CFN 
> (https://dl.acm.org/doi/10.1145/3357150.3357395) the resource 
> management for placing and allocating compute is a protocol running on 
> top of the ICN protocols, not inside as QoS-oriented extensions. What 
> it could do for example (but doesn’t since current protocols don’t 
> have the hooks) is use QoS machinery to ensure ongoing computations 
> get higher reliability for result delivery than initiating new 
> computations, or to rank less important computations to have less 
> stringent latency bounds.
>
> * section 5: this discusses TCP/IP equivalence classes and Intserv and 
> Diffserv, but made me wonder if there is a similar discussion that 
> computations, there is certainly lots of work to be done to design 
> joint optimization of routing, network capacity, and compute 
> placement/load. The question for me is what inherent QoS treatments 
> (and associated algorithms) in the L3 protocols are needed in order to 
> enable higher layer resource management protocols to have the 
> information they need, and the knobs to turn, in order to to that. My 
> guess (although I can’t prove it) is that the needed capabilities in 
> the L3 ICN protocols are quite modest, and are captured by the QoSArch 
> document reasonably well. If that’s not the case then I’d really 
> love to hear what might be missing or wrong in the overall approach I 
> recommend.
>
> Intserv-like traffic control is useful and if explicit admission 
> control is needed. In the IP world, things worked out that supplying 
> traffic control and admission control directly to consumer end hosts 
> was a colossal no-op/failure, but that using those capabilities 
> internal to individual AS’s to do traffic engineering turned out to 
> be quite widely employed.
>
> The provisional conclusion I put in the document is that it would not 
> be too difficult to add traffic control to the protocols, but that 
> adding admission control would be tricky at best and horrendously 
> complicated at worst because of the multi-path/multi-destination 
> forwarding model and the topological independence of application 
> names.
>
> the L3 forwarding, but do influence the routing protocol in 
> substantial ways. So, I would say that when we do work on ICN routing 
> protocols this is the place to dig in rather than the data plane 
> forwarding/caching primitives. Some prior work has tried to to the 
> whole thing adaptively through stochastic forwarding algorithms (e.g. 
> * Section 6.5: great discussion here of the interplay between network 
> QoS and caching, from both consumers and producers.
>
> Thanks!
>
> “in-network” computing as opposed to “on-network” computing. 
> My own view is that if we don’t sort this out with reasonable 
>   *   If you need to look at payloads, you don’t do it in forwarders 
> since the data is encrypted and you don’t have the keys
>   *   If you want to compute in the same hardware box as the box 
> that’s doing forwarding, that’s fine, but you are “on-network” 
> rather than “in-network” since you are just a consumer/producer 
> co-located with the forwarder.
>
> Now, I actually think this is a good division, since most of the 
> things people are trying to embed in the packet forwarding path of 
> switches is really hard to do if it involves anything other than 
> affecting the forwarding (e.g. firewall, DDoS mitigations, etc.). Now 
> it my be that certain important optimizations of the computing 
> functions running “on-network” can be helped by pushing expensive 
> operations down to the switch hardware, just as people have been doing 
> for years with smart NICs. That however, is not what I think people 
> are proposing when they talk about “in-network” computing.
>
> making further changes to the current draft, so I’m going to submit 
> it after waiting a day or two more for any further feedback on my 
> proposed changes from the editorial comments.
>
> Thanks again,
>
> DaveO.

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

DaveO