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

From: "jefhe"<[email-masked]>
Date: Thu, 3 Mar 2022 21:48:41 +0800

Hi group,
Attached is the minutes of the interim meeting and below are some words from COIN cochairs.
Some overarching messaging that came out of the COIN RG interim and the ongoing e-mail discussions.
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.
Simply put, routing is not the sole focus of COIN. 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). 
 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. 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. 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.
 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.
Best,
J/E/M

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Mar 2022 16:43:46 -0000

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.

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?

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

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.

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

Best,

Adrian

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 3 Mar 2022 19:31:52 +0100

Thanks Jeff

let me add some more specific questions over Adrians statements.
and make a few comments.

inline...

> On Thu, Mar 03, 2022 at 09:48:41PM +0800, jefhe wrote:
> Hi group,
> 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.

Is there actually a definition from COIN that would allow me to look at a network
and decide whether it is COIN based or not ?

> 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

Does COIN have any definition for "programmable routing" ?

Example: Do X.25 or OpenFlow switches fall under programmable routing
(e.g.: because they allow for forwarding entries to be to "programmed" ?)
If not, why not.

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

Whats COINs definition of a "NOT-in-network computing platform" ? Aka: I always
though a centralized SDN controller, PCE or AC (admission controller) are NOT
"in network computing platforms", but SDN fans where viciously contesting me
on that statement. A colleague made the argument somewhat more acceptable to
me by giving the example how any of these PCE/SDN/AC compute systems would
often run on a so-called "route-processor" of routers.

Aka: I have a very hard time guessing whats "non-in-the-network".

> > Simply put, routing is not the sole focus of COIN. In fact, the group has a strong interest in and believes its mission is to go well beyond traditional packet interception -  to support computat…

We had i think on INTAREA a nice conversation where Jeff Tentsura chimed in
with restating a well-known dilemma: The faster you want the processing to
be (at best cost/energy-consumption), the less you can do. It would be nice
to have a continuum in which you can pick an arbitrary amount of compute
you'd want to do, but in practice we know that we have for different markets
only few different architectrual options each, such as NPU/FPU for fast-path
(100Gbps++) processing, highly intelligent linecard (Smart-NIC <= 100Gbps)
and then CPU processing. 

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

"Dramatic" ? ;-))

Let me answer to the latter part of your letter separately

Cheers
    Toerless

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