Subject: [Coin] Re：Re: Minutes of the interim meeting and some words from thecochairs

From: "JEF" <[email-masked]>
Date: Sat, 5 Mar 2022 09:03:08 +0800

Hi Adrian,

Please see in lines.&nbsp;COIN chairs will meet next week to discuss this. Below are my personal comments and suggestions.

Original

From:"Adrian Farrel"< [email-masked] &gt;;

Date:2022/3/4 0:43

To:"jefhe"< <<[email-masked]&gt;&gt; &gt;;

CC:"coin"< [email-masked] &gt;;

Subject:Re: [Coin] Minutes of the interim meeting and some words from thecochairs

Thanks, Jef, for sharing this, and to you and your co-chairs for putting it together.

This is the guidance we’ve been asking for. So it is most welcome.

First and foremost, the focus in the IRTF is on research, not standardization. As such, it is appropriate to propose a vision for a COIN-based future network infrastructure. However it is equally important to ground the vision in an architecture and in concrete problem formulations. Some of the agreed upon core COIN RG goals are to examine the architectural implications of programmable routing and in-network compute, thus mechanisms to develop more programmable and more flexible packet forwarding could be in scope for COINRG – but only if new routing mechanisms leverage the programmable data plane or routing algorithms are supposed to be run on an in-network computing platform.

I may be wrong, but I think that, with the exception of some very old technologies, all routing algorithms are run on in-network computing platforms. There is no reason to assume that this would change with any approach to Semantic Routing, so that puts all of the routing side of Semantic Routing firmly in scope. Agreed?

[Jeffrey HE] In the context of data plane programmability, such in-network platform here is different from the CPUs in traditional network devices which are used mainly for the control plane. A simple difference is certainly the processing speed. Could we break current routing algorithms into different functions and allocate some of them into a programmable data plane? I have no answer, but this is potential. Is a function of routing algorithm allocated in the data plane still qualified to be called part of the routing? Let’s leave the discussion of naming till we see it.

Simply put, routing is not the sole focus of COIN. 

Well, I would hope not!

I look forward to reading a lot of material that is not related to routing as it is brought to the RG.

In fact, the group has a strong interest in and believes its mission is to go well beyond traditional packet interception -&nbsp; to support computations that go beyond packet header processing, whether to go deeper into packets for contextual info to be included in that computation, or that are part of distributed or federated apps that marshal the inclusion of network-based entities (physical or virtualized) that one wouldn’t normally consider as traditional “routers” (e.g., elements focused on compute, storage).

It is good to know that computations that stop at packet header (for some definition thereof) are not out of scope.

I look forward to reading about mechanisms that go deeper into packets and how they work in the presence of privacy/security-protecting end-to-end encryption.

I think a “router” is defined by the processing components that build routing tables and forward packets. Of course, it is very interesting to compose paths through the network that include nodes that perform routing as well as additional functions whether that be functions that provide services and are composed into chains, or other functions that the payload requires.

One epiphany gleaned from the meeting's discussion was that there is an ongoing tussle between compute in the service of routing and routing in the service of compute; both offer interesting research challenges. 

No reason why this has to be a tussle. But it is good to recognise that the two things exist and both need work, and they need to co-exist.

However, the strong desire in COIN RG is to make a dramatic departure from focusing on classical layer 3 IP address spaces, labelling, and identifiers. 

** This is the statement I most need help with. Is the extent of that strong desire for a dramatic departure such that any work on layer 3 routing and forwarding is not of interest? Maybe this depends on what “classical” means.

[Jeffrey HE] I don’t think that statement excludes Layer 3 as a whole.&nbsp;One example in my mind is the notion of coflow[1], which is a group of flows sharing a collective objective in distributed computing such as mapReduce. When the traffic pattern is multi-point2multi-point, compute-in-the-network has potentials to improve the routing and forwarding by taking the states of member flows at the running time into account.&nbsp;There is a line of research how to optimise a coflow and&nbsp;multi-point2multi-point communications. So I think it is more about if we leverage the data plane programmability in network devices.&nbsp;[1]https://www2.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-184.pdf

And an interesting question raised during the interim was if programmable routing (especially at the application layer) requires that we reconsider/redefine what routing convergence actually means in the presence of COIN-based infrastructure.

Well, of course, routing convergence at the application layer may have a very different meaning from the previous understanding derived from the packet/frame layers, but that is understandable as routing at the application layer also has a different meaning.

But I think you are referring to the question raised by Nik in the chat (there is nothing in the minutes about convergence). It’s good that you are opening that question up to include the concept of convergence in application layer routing, but (Nik can correct me) I didn’t read his question as having anything to do with application layer routing per se.

The three cochairs (J/E/M) thought the presentation “Flightplan” from Nik Sultana was a good example of an effective way to contribute to a research group like COIN; bring in concrete research results that offer a solution to a honed research problem. According to the feedback received from RG meetings and the mailing list, this kind of research topic formulation is most beneficial to the audience.

Given the fact that semantic routing has taken a major part of the discussion on the list lately, the chairs would like to request the following. The research on semantic routing that overlaps with COIN needs to be better articulated: (1) to focus the mailing list discussion on those topics that genuinely relate to data plane programmability and in-network compute, (2) to define which (or any) of the current drafts apply to the RG, (3) and to concentrate on the research that advances networking, now that programmability and in-network compute exists at every level in the core-edge continuum.

Given that we have been reliably and repeatedly told that a good proportion of semantic routing fits within the scope of COIN, and absent anywhere else in the IRTF to have these discussions, I think I will continue to discuss the issues and concepts related to semantic routing on the COIN list. The chairs are welcome to tell me on a thread-by-thread basis which pieces are not in scope for COIN, and I will stop talking about those topics. My aim in my emails is to solicit opinions and contributions to the discussion – the IRTF is not just about presenting research papers that have already been published/presented in other venues (although that can be a useful thing, too).

[Jeffrey HE] You’re right, it doesn’t make sense that only published papers are allowed to be presented in COIN. That didn’t happen to COIN either. But as a research group, discussions are expected to be about related research activities. I think you have had described and summarized semantic routing in this list. Among 250+ members in this list, if some of them are interested, these people should have approached to you or joined your mailing list whatever the answer to the scope question is. I would suggest we start from the part that we have already agreed in the scope of COIN, aiming at interesting techinical discussions to the group, that is how the idea of semantic routing may leverage or benefit from the network programmability. If you agree, I would say this is similar to one of your questions in your last slide in the interim:&nbsp;"What programmability (in the network) does Semantic Routing require? What would it drive?” For your other technical questions, the answsers depand on whether the programmabilty in the data plane and future in-network computing&nbsp;platform are included in your research alternatives or not. It would be out of scope of COIN if your research is aiming to extend the current understanding of the routing mechanism/theory in a general way, say without an assumption for a programmable data plane or in-network computing. Anyway, I feel the discussions at the concept levels are usually useful at the beginning, but at this stage I am afraid we need to see more concrete research contents if this group expect to benefit from the discussion. We will understand the concept better if we&nbsp;“see”&nbsp;it.&nbsp;

Best,

Adrian

---

From: "Schooler, Eve M" <[email-masked]>
Date: Wed, 9 Mar 2022 09:29:30 +0000

I include my comments below. Having not discussed my remarks with my co-chairs, please consider this note as being from me (vs from J/E/M).
Best regards,
Eve

From: Coin <[email-masked]> On Behalf Of JEF
Sent: Friday, March 4, 2022 5:03 PM
To: Adrian Farrel <[email-masked]>
Cc: iMac <[email-masked]>; coin <[email-masked]>
Subject: [Coin] Re：Re: Minutes of the interim meeting and some words from thecochairs

Hi Adrian,

Please see in lines. COIN chairs will meet next week to discuss this. Below are my personal comments and suggestions.

Original

From:"Adrian Farrel"< [email-masked]<mailto:[email-masked]> >;

Date:2022/3/4 0:43

To:"jefhe"< <<[email-masked]<mailto:[email-masked]>>> >;

CC:"coin"< [email-masked]<mailto:[email-masked]> >;

Well, I would hope not!

[Eve] The focus is meant to be on computation.

In fact, the group has a strong interest in and believes its mission is to go well beyond traditional packet interception -  to support computations that go beyond packet header processing, whether to go deeper into packets for contextual info to be included in that computation, or that are part of distributed or federated apps that marshal the inclusion of network-based entities (physical or virtualized) that one wouldn’t normally consider as traditional “routers” (e.g., elements focused on compute, storage).

[Eve] The intended meaning of the paragraph above was the opposite of your reading.

[Jeffrey HE] I don’t think that statement excludes Layer 3 as a whole. One example in my mind is the notion of coflow[1], which is a group of flows sharing a collective objective in distributed computing such as mapReduce. When the traffic pattern is multi-point2multi-point, compute-in-the-network has potentials to improve the routing and forwarding by taking the states of member flows at the running time into account. There is a line of research how to optimise a coflow and multi-point2multi-point communications. So I think it is more about if we leverage the data plane programmability in network devices. [1]https://www2.eec<https://www2.eec/>s.berkeley.edu/Pub<http://s.berkeley.edu/Pub>s/TechRpts/2012/EECS-2012-184.pdf

Given that we have been reliably and repeatedly told that a good proportion of semantic routing fits within the scope of COIN,

[Eve] I beg to differ. The feedback has been that only some of it may fit.

and absent anywhere else in the IRTF to have these discussions, I think I will continue to discuss the issues and concepts related to semantic routing on the COIN list.

[Eve] Because there is nowhere else to have these discussions does not make it appropriate to post everything semantic routing related here. Please re-read the 3 recommendations in the paragraph above.

The chairs are welcome to tell me on a thread-by-thread basis which pieces are not in scope for COIN, and I will stop talking about those topics.

[Eve] And I will respectfully request that you make an equal effort before posting to ask yourself if the subject is on topic.

My aim in my emails is to solicit opinions and contributions to the discussion – the IRTF is not just about presenting research papers that have already been published/presented in other venues (although that can be a useful thing, too).

[Jeffrey HE] You’re right, it doesn’t make sense that only published papers are allowed to be presented in COIN. That didn’t happen to COIN either. But as a research group, discussions are expected to be about related research activities. I think you have had described and summarized semantic routing in this list. Among 250+ members in this list, if some of them are interested, these people should have approached to you or joined your mailing list whatever the answer to the scope question is. I would suggest we start from the part that we have already agreed in the scope of COIN, aiming at interesting techinical discussions to the group, that is how the idea of semantic routing may leverage or benefit from the network programmability. If you agree, I would say this is similar to one of your questions in your last slide in the interim: "What programmability (in the network) does Semantic Routing require? What would it drive?” For your other technical questions, the answsers depand on whether the programmabilty in the data plane and future in-network computing platform are included in your research alternatives or not. It would be out of scope of COIN if your research is aiming to extend the current understanding of the routing mechanism/theory in a general way, say without an assumption for a programmable data plane or in-network computing.

[Eve] I agree with Jeffrey’s comments: asking how does semantic routing research overlap with/drive/influence/advance programmability in the data plane and in-network computing. And that general routing is out of scope.

Anyway, I feel the discussions at the concept levels are usually useful at the beginning, but at this stage I am afraid we need to see more concrete research contents if this group expect to benefit from the discussion. We will understand the concept better if we “see” it.

[Eve] Agreed.

Best,

Adrian

---

From: Sharon Barkai <[email-masked]>
Date: Wed, 9 Mar 2022 15:38:13 +0200

Here is an example of a big cloud computation problem,
turned into a simple application routing problem:

- A very big table of Vehicle.Location (Ms) 
- Needs to be joined with Event.Location (100Ks)
- In order to generate vehicle push notifications
- Both tables keep changing by the second
- Join compute time is much longer than that

The programmable routing solution:

- The join column e.g. “location" is an IP multicast channel for notifications
- Both events and subscriptions are designated to addressable “locations"
- The logical meaning of the channel is a shared system convention
- It leverages standard routing to designate events to addresses 
- It leverages MLD and signal-free multicast RFCs to subscribe

The question is - does COIN facilitate such research use-cases,
based on what terminology and open contribution framework?

This a simple example with multiple possible solutions.
There are many more like that with increased complexity.
So COIN may or may not be the right place for these.

> On Mar 9, 2022, at 11:29, Schooler, Eve M <[email-masked]> wrote:
> 
> From: Coin <[email-masked] <mailto:[email-masked]>> On Behalf Of JEF
> To: Adrian Farrel <[email-masked] <mailto:[email-masked]>>
> Cc: iMac <[email-masked] <mailto:[email-masked]>>; coin <[email-masked] <mailto:[email-masked]>>
> From:"Adrian Farrel"< [email-masked] <mailto:[email-masked]> >;
> 
> Date:2022/3/4 0:43
> 
> To:"jefhe"< <<[email-masked] <mailto:[email-masked]>>> >;
> 
> CC:"coin"< [email-masked] <mailto:[email-masked]> >;
> 
> [Jeffrey HE] I don’t think that statement excludes Layer 3 as a whole. One example in my mind is the notion of coflow[1], which is a group of flows sharing a collective objective in distributed computing such as mapReduce. When the traffic pattern is multi-point2multi-point, compute-in-the-network has potentials to improve the routing and forwarding by taking the states of member flows at the running time into account. There is a line of research how to optimise a coflow and multi-point2multi-point communications. So I think it is more about if we leverage the data plane programmability in network devices. [1]https://www2.eec <https://www2.eec/>s.berkeley.edu/Pub <http://s.berkeley.edu/Pub>s/TechRpts/2012/EECS-2012-184.pdf
> 
> -- 
> Coin mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/coin <https://www.irtf.org/mailman/listinfo/coin>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 9 Mar 2022 18:40:54 +0100

Sharon:

Given Colins ask to the folks like Adrian focussing on semantic addressing to
first go to coin, i think any such problems should maybe start using COIN at
least as a dispatch, and either the discussion about a specific topic

a) fits coin and might result in adopted work
b) does not fit coin but subsides
c) does not fit coin, does not subside and should then be moved
   to another forum in IETF/IRTF or at least be given a mailing list.

That is at least what i have seen as logical processes in the past.

But logistics aside (boooring ;-)

The generic problem you describe has been around forever but indeed will need
different optimizations based on its specific parameters. When subscription patterns
do for example map well with the network topology (vehicles subscribe to interest
channels specific to their vicinity and network topology is vicinity based), then
a lot of optimizations can be done.

I observed similar application requirements from the 90th on, first with
hundreds of thousands of financial instrument event channels (stock tickers),
and brokers as subscribers. That problem had much lower subscriber counts,
but no locality matching. First solutions did use multicast, but then when
software compute/networking (DC servers) became cheap enough vs. the required
bandwidth it was moved up the stack because it allowed the application developers
to not depend on "network operators" to ask "vendors" about forwarding plane
functions that their applications required, because that multi-party development
loop made the agility of solution development compete with continental drift.

This is why why i think programmable slices (where the actual
forwarding is programmable by the application owner) are a mandatory requirement
to make progress in leveraging high-speed programmable forwarding planes in
shared networks: The wide-area network operators will not be able to drive
requirements on behalf of such specialized application owners. Those application
owners have to be able to program what they want themselves.

ICN btw. did and does promise to solve these type of content stream distribution
model fairly well. In fact i would claim it did develop out of use cases like
the one i described because multicast itself didn't get to the point of
standardizing the required reliability, mostly because of IETF's bureaucracy
around the RMT WG, which is a whole other annoying IETF story...

Cheers
    Toerless

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

-- 
---
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Wed, 9 Mar 2022 19:32:13 +0000

> On 9 Mar 2022, at 17:40, Toerless Eckert <[email-masked]> wrote:
> 
> 
> Sharon:
> 
> Given Colins ask to the folks like Adrian focussing on semantic addressing to first go to coin, i think any such problems should maybe start using COIN at least as a dispatch, and either the discussion about a specific topic

No – that is not correct.

What I said to Adrian was that some parts of the semantic routing work fall into the scope of COINRG, some parts overlap with other IRTF groups, and some parts are outside the scope of IRTF or are better suited to other venues. 

COINRG is not a DISPATCH-style group. Work that does not relate to computation in the network research is out of scope and should be discussed elsewhere.

>   to another forum in IETF/IRTF or at least be given a mailing list.

If the work does not fit within the COINRG charter, it should not be raised here. 

Colin

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

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 9 Mar 2022 20:42:07 +0100

> What I said to Adrian was that some parts of the semantic routing work fall into the scope of COINRG, some parts overlap with other IRTF groups, and some parts are outside the scope of IRTF or are…

Ah, thanks for reminding me. I forgot that you wanted to make any useful discusion
around the work we propose even more impossible by asking to go shopping around a variety
of existing and non-existing RGs for any individual detail that may not fit a
particular groups charter.

> If the work does not fit within the COINRG charter, it should not be raised here. 

The COIN charter is so broadly written that everything the COIN chairs want to claim
to be in charter they can, and likewise anything they don't, they can equally do.

Everything a network forwarding plane does is compute of how to process packets for example.

Cheers
    Toerless

---

From: Colin Perkins <[email-masked]>
Date: Wed, 9 Mar 2022 20:13:54 +0000

Toerless,

The COINRG, like every other IRTF group, has a charter that defines what is, and is not, in scope. The charter was agreed with the IAB when the group was formed, and has been reviewed since. One of the roles of the research group chairs is to interpret that charter, and ensure the group remains on topic.

If you believe the chairs are interpreting that charter incorrectly, you may appeal to me, as IRTF Chair. If you disagree with my decisions, you may appeal to the IAB.

Colin

> On 9 Mar 2022, at 19:42, Toerless Eckert <[email-masked]> wrote:
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 9 Mar 2022 21:56:54 +0100

Colin,

I think everybody understands that process can be used positively to help or
negatively  to hinder specific activities. It is left up to every IETF participant 
to form their opinions as to whether or how this is happening in any instance.

I explicitly did not make any complaints about how the COIN chairs are running
the RG, i was just observing that the charter is quite inclusive and
maybe more so than what a single RG can grasp. But that is not a bad problem to
deal with, and i certainly understand that the COIN chairs are trying to find
some good interpretations about what is and what is not in scope (as Jeff did
i think speaking for all chairs in his summary).

Of course i am also yealous, because i think routing would also be a great topic
to deserve an RG with such an inclusive charter as "compute", but seemingly i am
in a minority there. Which is still baffling to me given how routing is really
one of the roots of this whole organization. 

I did make very specific observations about how i think programmability aspects
are closely tied to protocol/addressing design and how that makes it hard
and/or not very productive IMHO to try to find a strict separation between the
two. I welcome any technical thoughts you have about that technical contention.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Wed, 9 Mar 2022 23:34:41 +0000

Toerless,

> On 9 Mar 2022, at 20:56, Toerless Eckert <[email-masked]> wrote:
> 
> Colin,
> 

The IRSG reviewed the proposal for a semantic routing research group, and concluded that it did not meet the bar for chartering as a new IRTF group.

You are, of course, entitled to disagree with that decision. You have made it very clear, with repeated postings to this list and others, over a period of several months, that you do disagree. Your opinion is well noted – further repeating it here will achieve nothing other than disrupting the operation of this group.

> two. I welcome any technical thoughts you have about that technical contention.

How to develop more flexible, more general purpose, programming models for the data plane, to avoid some limitations of current approaches, is a goal of the group. 

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

---

From: Sharon Barkai <[email-masked]>
Date: Thu, 10 Mar 2022 21:17:52 +0200

Thanks Toerless, good observations.

The well mapping is not just of “location“ subscription-replication to network topology, solve big Joins, theres also:

o network addressing supporting privacy while publishing-subscribing to states
o dns-less seamless context switching while physically moving between states of interest 
o high availability and dynamic allocation of addressable states per car activity/facilities
o addressable stat-mux coalescing low latency low bw access queues to metroE queues
o etc. 

But unless somebody writes and COIN adopts some agreed terminology and reference architecture for Compute Overlay in (routed) Network its really hard to discuss research or generalize these topics. Iv seen a few proposals fly by the list by Luigi and others. Maybe if one of these gets a green light the discussion can move forward. Perhaps its premature but the interest seems real.

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

> On Mar 9, 2022, at 19:41, Toerless Eckert <[email-masked]> wrote:
> 
> When subscription patterns

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 10 Mar 2022 14:36:01 -0500

You are free to propose that terminology.

Marie-José Montpetit, Ing. Ph.D.

> On Mar 10, 2022, at 2:18 PM, Sharon Barkai <[email-masked]> wrote:
> 
>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 11 Mar 2022 05:31:08 +0100

Thanks, Sharon

Terminology and reference architecture would be good goals to work towards, but 
how would we validate what is proposed in such work ? I think for that it would
be very helpful to start from some significant enough, but not "ocean boiling"
set of well described use-case scenarios

It sounds to me as if the aspects you mention could apply all to edge-mobility
such as car-2-curb. Would that be a good set of use-case/scenarios ?

Setting context with some tutorial writeup of such use-cases and a survey of
existing/proposed mechanisms for the aspects you mention might be a good starting
point to establish a common base to work from towards those goals you mention.
And a survey/tutorial from a broader set of authors might also be a much easier
way to get a community working on the problem started.

Of course i am specifically interested in the subset of the work areas you mention
that do impact not only the compute overlay, but also the routing underlay. And
that impact goes IMHO both ways.

For example, if application developers including those working on such
"compute overlays" would better understand what could be done with the new
evolving stateless multicast technologies such as BIER, then it might help
to better solve such application challenges. But alas, we are also somewhat
slow so far to produce good material to educate about such new opportunities
in the routing underlay (its on my bucket list though). 

On the other hand, working in the routig underlay, i am of course even more
interested in what challenges such overlays face that have not yet good
solutions from the routing underlay. But which maybe could have better
solutions if we worked on more/better semantic routing solutions ;-)

Cheers
    Toerless

-- 
---
[email-masked]