Subject: [Coin] Charter discussion

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Nov 2021 14:07:03 -0000

Hi COIN chairs,

Thanks for taking the decision to give the time to the presenters, but a
shame that your space for chartering discussions got squeezed off the
bottom.

In preparation for an interim discussing scope and charter, I'd like to push
again for some feedback on our work on semantic routing and the challenges
to the packet routing system
(https://github.com/danielkinguk/sarah/tree/main/RISE). If this is clearly
out of scope (see DaveO's email) and unlikely to come into scope, then
clearly it would be good to know that sooner. If it might come into scope at
a recharter, then perhaps you can give us some time at the interim to bring
it up and explain what we are looking at. And, obviously (?), if you think
it is already in scope, then I encourage everyone to comment on the list.

Thanks,
Adrian

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 11 Nov 2021 09:13:28 -0500

I believe we will find out that some elements are in scope and some not. We
need to find the right research community.

Marie-José Montpetit, Ph.D.
[email-masked]

From: Adrian Farrel <[email-masked]> <[email-masked]>
Reply: [email-masked] <[email-masked]> <[email-masked]>
Date: November 11, 2021 at 9:07:37 AM
To: [email-masked] <[email-masked]> <[email-masked]>
Cc: [email-masked] <[email-masked]> <[email-masked]>
Subject:  Charter discussion

Hi COIN chairs,

In preparation for an interim discussing scope and charter, I'd like to
push
again for some feedback on our work on semantic routing and the challenges
to the packet routing system
(https://github.com/danielkinguk/sarah/tree/main/RISE). If this is clearly
out of scope (see DaveO's email) and unlikely to come into scope, then
clearly it would be good to know that sooner. If it might come into scope
at
a recharter, then perhaps you can give us some time at the interim to bring
it up and explain what we are looking at. And, obviously (?), if you think
it is already in scope, then I encourage everyone to comment on the list.

Thanks,
Adrian

---

From: "Dirk Kutscher" <[email-masked]>
Date: Fri, 12 Nov 2021 14:40:32 +0100

Hi,

my view:

there are routing aspects in some of the "networking approach"-focused 
RGs, such as ICNRG and COINRG. For example in ICNRG, topics such as Name 
Link-State Routing or Hyperbolic Routing are of interest (or studying 
systems where discovery, path establishment can be done without routing 
protocols). For COINRG, routing to additional resources (compute, 
storage etc.) could be of interest (in the end, similar mechanism as for 
ICN might apply) and should be fine to discuss there.

I don't think this requires any explicit re-chartering.

Best regards,
Dirk

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

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 12 Nov 2021 09:23:38 -0500

On 12 Nov 2021, at 8:40, Dirk Kutscher wrote:

> Hi,
>
> my view:
>
> there are routing aspects in some of the "networking approach"-focused RGs, such as ICNRG and COINRG. For example in ICNRG, topics such as Name Link-State Routing or Hyperbolic Routing are of interest (or studying systems where discovery, path establishment can be done without routing protocols). For COINRG, routing to additional resources (compute, storage etc.) could be of interest (in the end, similar mechanism as for ICN might apply) and should be fine to discuss there.
>
This message is demonstrably random and a bit stream-of-conciousness, but I wanted to get it out there for folks in raw form to see what might resonate:

Dirk’s is a perfectly reasonable interpretation and one that is in line with a lot of the current work coming into COINRG. It’s fine if that’s what we decide to focus on.

A somewhat negative interpretation of that focus however might be that it emphasizes only networking functions that have always belonged on networking devices but which now can be done by software on programmable switches rather than in hardware or hard-to-modify/innovate firmware.

I think more important is how networking devices could do computing functions that today can only be done on hosts. This is for me where the architectural/research big win might be.

Or, put more succinctly, we have a danger of just doing “programming networking devices in software for enhanced networking functions”. Or, even more snarky “COINRG worries about how to beat P4 into submission”.

A tricky but probably highly interesting hybrid is programmable NICs, which could be viewed either simply as accelerators/offload devices that are “part of” the host, or as independent networking devices with their own policy/security/management/application environment.

My personal interest is in trying to reduce and someday break the hard partitioning between what’s considered a networking device and what’s considered a host, by figuring out how to interconnect and do distributed programming for heterogeneous devices that have CPUs, GPUs, TPUs, and switching ASICs.

The end game might be that pure networking engineers disappear the same way telephony engineers disappeared with the advent of the general-purpose networking protocols that could provide communication services for any application. People just learn to program distributed applications directly on these heterogeneous compute platforms and the networking pieces just align with the way the application behaves. Interconnect gets back to being super-dumb pipes that connect these complexes together with the topology emergent through the behavior of the distributed programs.

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Fri, 12 Nov 2021 09:30:53 -0500

P4 is another language.

Programming dataplanes (and control planes and distributed systems) is the
goal.

So now we will have tel-heads -> net-heads -> prog-heads?

And all in our lifetime!

mjm

From: David R. Oran <[email-masked]> <[email-masked]>
Reply: David R. Oran <[email-masked]> <[email-masked]>
Date: November 12, 2021 at 9:24:03 AM
To: Dirk Kutscher <[email-masked]> <[email-masked]>
Cc: Marie-Jose Montpetit <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]> <[email-masked]>
Subject:  Re: [Coin] Charter discussion

RGs, such as ICNRG and COINRG. For example in ICNRG, topics such as Name
Link-State Routing or Hyperbolic Routing are of interest (or studying
systems where discovery, path establishment can be done without routing
protocols). For COINRG, routing to additional resources (compute, storage
etc.) could be of interest (in the end, similar mechanism as for ICN might
apply) and should be fine to discuss there.
This message is demonstrably random and a bit stream-of-conciousness, but I
wanted to get it out there for folks in raw form to see what might
resonate:

Dirk’s is a perfectly reasonable interpretation and one that is in line
with a lot of the current work coming into COINRG. It’s fine if that’s what
we decide to focus on.

A somewhat negative interpretation of that focus however might be that it
emphasizes only networking functions that have always belonged on
networking devices but which now can be done by software on programmable
switches rather than in hardware or hard-to-modify/innovate firmware.

I think more important is how networking devices could do computing
functions that today can only be done on hosts. This is for me where the
architectural/research big win might be.

Or, put more succinctly, we have a danger of just doing “programming
networking devices in software for enhanced networking functions”. Or, even
more snarky “COINRG worries about how to beat P4 into submission”.

A tricky but probably highly interesting hybrid is programmable NICs, which
could be viewed either simply as accelerators/offload devices that are
“part of” the host, or as independent networking devices with their own
policy/security/management/application environment.

My personal interest is in trying to reduce and someday break the hard
partitioning between what’s considered a networking device and what’s
considered a host, by figuring out how to interconnect and do distributed
programming for heterogeneous devices that have CPUs, GPUs, TPUs, and
switching ASICs.

The end game might be that pure networking engineers disappear the same way
telephony engineers disappeared with the advent of the general-purpose
networking protocols that could provide communication services for any
application. People just learn to program distributed applications directly
on these heterogeneous compute platforms and the networking pieces just
align with the way the application behaves. Interconnect gets back to being
super-dumb pipes that connect these complexes together with the topology
emergent through the behavior of the distributed programs.

---

From: Lixia Zhang <[email-masked]>
Date: Fri, 12 Nov 2021 08:03:48 -0800

> On Nov 12, 2021, at 6:30 AM, Marie-Jose Montpetit <[email-masked]> wrote:
> 
> P4 is another language.
> 
> Programming dataplanes (and control planes and distributed systems) is the goal.
> 

Agree.  Progress is accelerating :-)

But it seems to me that the word "net" in "net-heads" could benefit from a bit further classification

1/ communications need networking.

2/ so telecom also built networks, and "tel-heads" in the old days referred to as "bell-shaped heads", the view that communication is about building a network that sets up circuits.

3/ really dont mean to put word in your mouth: I assume the "net" in net-heads means IP networking (as opposed to telecom networks) that we have today?

If I dare to say this in public (please do not shoot me! close friends have heard it from me for years:) -- by paraphrasing the old saying, and clarifying what kind net one is talking about: the "net-heads" in the above should be called "IP-shaped heads", thinking in terms of shooting packets to destination addresses. 

4/ the "N" in ICN is also about networking, information-centric networking.

Now back to where this exchange started: yes all kinds of networks need routing (telecom had routing too, they just did in different ways), so COIN needs routing support, whether that is in/out the charter is a separable question. I would just like to remind ourselves that that routing works on some identifier space, so we need to first clarify what that identifier space identifiers.

IP address identifies locations (more precisely: network attachment points).
ICN names identifies information--a name can name anything, so the information can be about anything (sensor data, compute function, Netflix movie, or a node's MIB or its attachment points...).

As I read from draft-king-irtf-semantic-routing-survey, "semantic routing" aims to change the semantics of IP addresses.
But I am afraid that the definition of IP addresses cannot be *feasibly* redefined in fundamental ways --- just look at "IP multicast address" as an example: that's no longer the address as defined by RFC791, and that redefinition implied profound changes to the deployed IP base, hence its 30 years of (losing?) battle in deployment.

"The farther back you can look, the farther forward you are likely to see."--Winston Churchill 

just my 2 cents, Lixia

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 12 Nov 2021 16:18:23 -0000

Hi Lixia,

Picking on one point.

Please look at draft-farrel-irtf-introduction-to-semantic-routing for our
latest thoughts on what we mean by semantic routing.

Making changes to the semantics of IP addresses is *one* possible approach
to placing semantics in packets to enable routing. But it is not our
objective. I know there are a number of proposals to do this (including WGs
that work on it extensively), but we are not supporting or promoting these
approaches.

Our objective is to look at the consequences for packet routing systems if
they use the different approaches to semantic routing. How does backward
compatibility work? What happens to scalability and stability? What about
security and privacy?

Thanks,
Adrian

PS "Routing" is, of course, a concept used widely at multiple layers.
Sometimes it means slightly different things, but the general concept is the
same. We, however, are considering "packet routing" at layer 3.

-----Original Message-----
From: Coin <[email-masked]> On Behalf Of Lixia Zhang
Sent: 12 November 2021 16:04
To: Marie-Jose Montpetit <[email-masked]>
Cc: [email-masked]
Subject: Re: [Coin] Charter discussion

goal.

But it seems to me that the word "net" in "net-heads" could benefit from a
bit further classification

2/ so telecom also built networks, and "tel-heads" in the old days referred
to as "bell-shaped heads", the view that communication is about building a
network that sets up circuits.

3/ really dont mean to put word in your mouth: I assume the "net" in
net-heads means IP networking (as opposed to telecom networks) that we have
today?

If I dare to say this in public (please do not shoot me! close friends have
heard it from me for years:) -- by paraphrasing the old saying, and
clarifying what kind net one is talking about: the "net-heads" in the above
should be called "IP-shaped heads", thinking in terms of shooting packets to
destination addresses. 

Now back to where this exchange started: yes all kinds of networks need
routing (telecom had routing too, they just did in different ways), so COIN
needs routing support, whether that is in/out the charter is a separable
question. I would just like to remind ourselves that that routing works on
some identifier space, so we need to first clarify what that identifier
space identifiers.

IP address identifies locations (more precisely: network attachment points).
ICN names identifies information--a name can name anything, so the
information can be about anything (sensor data, compute function, Netflix
movie, or a node's MIB or its attachment points...).

As I read from draft-king-irtf-semantic-routing-survey, "semantic routing"
aims to change the semantics of IP addresses.
But I am afraid that the definition of IP addresses cannot be *feasibly*
redefined in fundamental ways --- just look at "IP multicast address" as an
example: that's no longer the address as defined by RFC791, and that
redefinition implied profound changes to the deployed IP base, hence its 30
years of (losing?) battle in deployment.

"The farther back you can look, the farther forward you are likely to
see."--Winston Churchill 

just my 2 cents, Lixia

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 12 Nov 2021 11:56:24 -0800

> The end game might be that pure networking engineers disappear the same way telephony engineers disappeared with the advent of the general-purpose networking protocols that could provide communicat…

And good idea and a valid goal.

Dino

---

From: Cedric Westphal <[email-masked]>
Date: Fri, 12 Nov 2021 20:20:48 +0000

Fully agree is a worthy goal and fascinating research problem.

That said, if that the goal of THIS RG, does its scope include looking into other protocols that are not aligned with this goal? Say if your protocol is a routing protocol for end hosts rather than to connect compute/storage/network in a unified manner?

C. 

-----Original Message-----
From: Coin <[email-masked]> On Behalf Of Dino Farinacci
Sent: Friday, November 12, 2021 11:56 AM
To: David R. Oran <[email-masked]>
Cc: Adrian Farrel <[email-masked]>; Marie-Jose Montpetit <[email-masked]>; [email-masked]; Dirk Kutscher <[email-masked]>; [email-masked]
Subject: Re: [Coin] Charter discussion

Dino

-- 
Coin mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcoin&amp;data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb15f4ad2954d4013e9dc08d9a6168752%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637723437982153141%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=N%2F81I6YCA8FVENEmXYMRXPWWXiue2tI3ChnAPbs%2FJ98%3D&amp;reserved=0

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 12 Nov 2021 17:34:24 -0500

On 12 Nov 2021, at 15:20, Cedric Westphal wrote:

> That said, if that the goal of THIS RG, does its scope include looking into other protocols that are not aligned with this goal?
Sure, depending on what insights they may bring from a research perspective to computing in the network.

> Say if your protocol is a routing protocol for end hosts rather than to connect compute/storage/network in a unified manner?
I personally would see that as out of scope but others might feel differently. I believe we have ample places to work on routing protocols from a research perspective. What would COINRG bring to the party?

---

From: [email-masked]
Date: Sat, 13 Nov 2021 10:11:37 +0100 (CET)

On Fri, 12 Nov 2021, David R. Oran wrote:

> how to interconnect and do distributed programming for heterogeneous 
> devices that have CPUs, GPUs, TPUs, and switching ASICs.

So by pointing out NICs together with above list, what you are saying is 
that the networking realm was already implementing Patterson's world of 
domain-specific architectures, avant la lettre.

Linking this to the routing topic which triggered this thread: random or 
not, I like this view because from a flow perspective it helps to frame 
routing as a restrictor function that prevents information to be 
processed in most of the cases. We have other, nice restrictors, like 
the LRU cache of packet hashes (McCauley's deforestation paper), or 
CCN's pending interest table construct. That is, restrictors are 
essential to make progress in a computation, and this is our ultimate 
metric.

Once there will be a CoinOS or other framework to manage the 
programmable bits and pieces, this will also be a restrictor function. 
Which is good news for investors (and this RG) as managed scarcity is 
what can create google-sized money engines.

Best, c

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Sat, 13 Nov 2021 07:30:43 -0500

The “CoinOS" concept is very interesting and is what I was trying to start
a discussion on with the MODA presentation.

From: [email-masked] <[email-masked]>
<[email-masked]>
Reply: [email-masked] <[email-masked]>
<[email-masked]>
Date: November 13, 2021 at 4:11:43 AM
To: David R. Oran <[email-masked]> <[email-masked]>
Cc: Dirk Kutscher <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]> <[email-masked]>, Marie-Jose
Montpetit <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]> <[email-masked]>
Subject:  Re: [Coin] Charter discussion

Best, c

>>
> This message is demonstrably random and a bit stream-of-conciousness, but
I wanted to get it out there for folks in raw form to see what might
>
> A tricky but probably highly interesting hybrid is programmable NICs,
which could be viewed either simply as accelerators/offload devices that
are “part of” the host, or as independent networking devices with their own
policy/security/management/application environment.
>
> The end game might be that pure networking engineers disappear the same
way telephony engineers disappeared with the advent of the general-purpose

---

From: "David R. Oran" <[email-masked]>
Date: Sat, 13 Nov 2021 07:36:04 -0500

> a discussion on with the MODA presentation.
another interesting view is the Hotnets Paper from the UIUC folks 
proposing service mesh interconnection via sidecars to applications as 
the “new network layer”.

[Leveraging Service Meshes as a New Network 
Layer](https://dl.acm.org/doi/10.1145/3484266.3487379)

> Marie-Jose
> storage
>>>> Thanks for taking the decision to give the time to the presenters, 
>>>> but
> a
>>>> a recharter, then perhaps you can give us some time at the interim 
>>>> to
> bring
>>>> it up and explain what we are looking at. And, obviously (?), if 
>>>> you
> think

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Sat, 13 Nov 2021 07:38:33 -0500

Yes I saw it and they are my list of people to invite to the next COIN.

From: David R. Oran <[email-masked]> <[email-masked]>
Reply: David R. Oran <[email-masked]> <[email-masked]>
Date: November 13, 2021 at 7:36:23 AM
To: Marie-Jose Montpetit <[email-masked]> <[email-masked]>
Cc: [email-masked] <[email-masked]>
<[email-masked]>, [email-masked]
<[email-masked]> <[email-masked]>, [email-masked]
<[email-masked]> <[email-masked]>, Dirk Kutscher
<[email-masked]> <[email-masked]>, [email-masked] <[email-masked]>
<[email-masked]>
Subject:  Re: [Coin] Charter discussion

another interesting view is the Hotnets Paper from the UIUC folks proposing
service mesh interconnection via sidecars to applications as the “new
network layer”.

Leveraging Service Meshes as a New Network Layer
<https://dl.acm.org/doi/10.1145/3484266.3487379>

Best, c

Hi,

my view:

Best regards,
Dirk

I believe we will find out that some elements are in scope and some

not. We

From: Adrian Farrel <[email-masked]> <[email-masked]>
Reply: [email-masked] <[email-masked]> <[email-masked]>
Date: November 11, 2021 at 9:07:37 AM
To: [email-masked] <[email-masked]> <

[email-masked]>

Hi COIN chairs,

Thanks for taking the decision to give the time to the presenters, but

a

In preparation for an interim discussing scope and charter, I'd like to
push
again for some feedback on our work on semantic routing and the

challenges

to the packet routing system
(https://github.com/danielkinguk/sarah/tree/main/RISE). If this is

clearly

out of scope (see DaveO's email) and unlikely to come into scope, then
clearly it would be good to know that sooner. If it might come into

scope

at
a recharter, then perhaps you can give us some time at the interim to

bring

it up and explain what we are looking at. And, obviously (?), if you

think

it is already in scope, then I encourage everyone to comment on the

list.

Thanks,
Adrian

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 13 Nov 2021 13:51:30 +0000

ah, overlays revisited...again:)

On Sat, Nov 13, 2021 at 12:36 PM David R. Oran <[email-masked]> wrote:
> another interesting view is the Hotnets Paper from the UIUC folks proposing service mesh interconnection via sidecars to applications as the “new network layer”.
>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Sat, 13 Nov 2021 08:59:08 -0500

Hmm overlay not really or not by default?

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

> On Nov 13, 2021, at 8:51 AM, Jon Crowcroft <[email-masked]> wrote:
>

---

From: Hesham ElBakoury <[email-masked]>
Date: Sat, 13 Nov 2021 14:14:46 -0800

My understanding from the paper presentation and Professor Brighten is that
today, service meshes do not use in-network computing.  They are deployed
entirely within host containers and use standard TCP/IP to provide
connectivity between containers. But it may be a good idea to have
discussion with him and coauthors of the paper about how in-network
computing can benefit the architecture proposed in the paper.

Thanks
Hesham

On Sat, Nov 13, 2021, 4:38 AM Marie-Jose Montpetit <[email-masked]>
wrote:

> proposing service mesh interconnection via sidecars to applications as the
> “new network layer”.
>

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 13 Nov 2021 15:27:23 -0800

Service meshes are massively deployed today and are nothing else than a TLS encrypted host based overlay, implementation details, whether it is a sidecar or a some other way to implement proxy and its control plane don’t change this basic functionality.

Cheers,
Jeff

> On Nov 13, 2021, at 14:15, Hesham ElBakoury <[email-masked]> wrote:
> 
> 
> My understanding from the paper presentation and Professor Brighten is that today, service meshes do not use in-network computing.  They are deployed entirely within host containers and use standard TCP/IP to provide connectivity between containers. But it may be a good idea to have discussion with him and coauthors of the paper about how in-network computing can benefit the architecture proposed in the paper.
> 
> Thanks
> Hesham
> 
>> On Sat, Nov 13, 2021, 4:38 AM Marie-Jose Montpetit <[email-masked]> wrote:
>> From: David R. Oran <[email-masked]>
>> Reply: David R. Oran <[email-masked]>
>> Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Dirk Kutscher <[email-masked]>, [email-masked] <[email-masked]>

---

From: "Bernier, Daniel" <[email-masked]>
Date: Sun, 14 Nov 2021 17:56:22 +0000

Actually it all depends on implementation. Currently, most meshes happen a the TLS layer because initial use was within kubernetes and micro-services architecture.

You now have variation of meshes that can work at lower layers (Network Service Mesh) with various dataplane encapsulation techniques. Nothing prevents implementing the mesh sidecar mechanism in hardware acceleration via P4 or others and it is also possible to do proxyless meshes through gRPC.

It is actually becoming quite interesting when thinking of application oriented networking, edge computing or slicing when you realize that the mesh control plane has visibility at higher layers and can influence at more than bits in a encapsulation header or NLRI attributes.

Daniel Bernier

Sent from my Bell Samsung device over Canada's largest network.

-------- Original message --------
From: Jeff Tantsura <[email-masked]>
Date: 2021-11-13 6:27 p.m. (GMT-05:00)
To: Hesham ElBakoury <[email-masked]>
Cc: Marie-Jose Montpetit <[email-masked]>, "David R. Oran" <[email-masked]>, Dirk Kutscher <[email-masked]>, [email-masked], [email-masked], Adrian Farrel <[email-masked]>, [email-masked]
Subject: [EXT]Re: [Coin] Charter discussion

Cheers,
Jeff

Thanks
Hesham

On Sat, Nov 13, 2021, 4:38 AM Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>> wrote:
Yes I saw it and they are my list of people to invite to the next COIN.

Marie-José Montpetit, Ph.D.
[email-masked]<mailto:[email-masked]>

From: David R. Oran <[email-masked]><mailto:[email-masked]>
Reply: David R. Oran <[email-masked]><mailto:[email-masked]>
Date: November 13, 2021 at 7:36:23 AM
To: Marie-Jose Montpetit <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Dirk Kutscher <[email-masked]><mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject:  Re: [Coin] Charter discussion

Leveraging Service Meshes as a New Network Layer<https://dl.acm.org/doi/10.1145/3484266.3487379>

Marie-José Montpetit, Ph.D.
[email-masked]<mailto:[email-masked]>

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
<[email-masked]<mailto:[email-masked]>>
Reply: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
<[email-masked]<mailto:[email-masked]>>
Date: November 13, 2021 at 4:11:43 AM
To: David R. Oran <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Cc: Dirk Kutscher <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>,
[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>, Marie-Jose
Montpetit <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>,
[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>,
[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Coin] Charter discussion

Best, c

Hi,

my view:

Best regards,
Dirk

not. We

Marie-José Montpetit, Ph.D.
[email-masked]<mailto:[email-masked]>

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Reply: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Date: November 11, 2021 at 9:07:37 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> <

[email-masked]<mailto:[email-masked]>>

Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Charter discussion

Hi COIN chairs,

a

challenges

clearly

scope

at

bring

think

list.

Thanks,
Adrian

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

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

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

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

---

From: "Milheiro Mendes, Paulo Jorge" <[email-masked]>
Date: Mon, 15 Nov 2021 10:09:21 +0100

Hi David and all,

 From the current charter it seems that COIN aims to have a broad view on
embedded computing functions into the network, encompassing novel
architectures, data-plane abstractions and new network protocol designs...
From the current working items, the group seems to be tackling
programabillity, security, privacy, scheduling, data discovery, as well as
looking at transport issues. This seems to me already a significant diverse
set of problems, more looking at the data plane. Focusing only at
the charter, the first question is: should the COINRG focus on the data
plane to start with or embrace a larger charter encompassing a lot of
different challenges from control to management?

In what concerns routing, this is already a transversal topic. As mentioned
before, routing depends on the identifier space. So, we have several
routing challenges to begin pursuit in IETF in relation to the host
identifier space... In ICNRG we have some routing efforts related to the
data identification space. From this point of view we could also tackle the
routing challenge in COINRG related to a new identification space focused
on computing functions.

However, IMO the question around "semantic routing" is, can we have a
programmable way to look at routing, tackling different identification
spaces into account? For instance, should a routing problem take into
account a set of network functions that need to be executed and a set of
data objects needed for that execution? If this is the way to go, maybe the
topic of semantic routing should have a transversal approach within IRTF,
located in a different RG.

IMO, semantic routing aims to use a more programmable decision model, able
to exploit any information available on the packet head (data
identification, network function identification, host identification, ToS,
etc) and on the visited hosts (service semantics, contextual information).
IMO semantic routing does not have to be related to changing the semantics
of IP addresses. Although this is already being done: e.g. with hICN, for
instance.

As for the addressing issue itself, the drafts presented to Intarea aim
to describe well-recognized scenarios that showcase possibly different
addressing requirements, as mentioned here with the different
identification space, but that does not mean that we need to change the IP
addressing model. Maybe we need a more flexible routing to handle different
identification spaces. And if this is the case, again, this routing
challenge is transversal to several IRTF groups.

Cheers,
Paulo

*****************************

Dr. habil. Paulo Mendes

Expert Communication Network Architectures and Design
Central Research and Technology, XRC
*Airbus*

On Fri, Nov 12, 2021 at 11:35 PM David R. Oran <[email-masked]> wrote:

> > That said, if that the goal of THIS RG, does its scope include looking
> into other protocols that are not aligned with this goal?
> > Say if your protocol is a routing protocol for end hosts rather than to
> connect compute/storage/network in a unified manner?
> I personally would see that as out of scope but others might feel
> differently. I believe we have ample places to work on routing protocols
> from a research perspective. What would COINRG bring to the party?
>
> >
> > C.
> >
> > Cc: Adrian Farrel <[email-masked]>; Marie-Jose Montpetit <
> [email-masked]>; [email-masked]; Dirk Kutscher <
> [email-masked]>; [email-masked]
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

---

From: Hesham ElBakoury <[email-masked]>
Date: Mon, 15 Nov 2021 07:31:54 -0800

Hi Paulo,

You said below:

"If this is the way to go, maybe the topic of semantic routing should 
have a transversal approach within IRTF, located in a different RG."

Do you mean a new RG or another RG such as ICNRG ?

Thanks

Hesham

On 11/15/2021 1:09 AM, Milheiro Mendes, Paulo Jorge wrote:
> Hi David and all,
>
>  From the current charter it seems that COIN aims to have a broad view 
> on embedded computing functions into the network, encompassing novel 
> architectures, data-plane abstractions and new network protocol 
> designs... From the current working items, the group seems to be 
> tackling programabillity, security, privacy, scheduling, data 
> discovery, as well as looking at transport issues. This seems to me 
> already a significant diverse set of problems, more looking at the 
> data plane. Focusing only at the charter, the first question is: 
> should the COINRG focus on the data plane to start with or embrace a 
> larger charter encompassing a lot of different challenges from control 
> to management?
>
> In what concerns routing, this is already a transversal topic. As 
> mentioned before, routing depends on the identifier space. So, we have 
> several routing challenges to begin pursuit in IETF in relation to the 
> host identifier space... In ICNRG we have some routing efforts related 
> to the data identification space. From this point of view we could 
> also tackle the routing challenge in COINRG related to a new 
> identification space focused on computing functions.
>
> account a set of network functions that need to be executed and a set 
> of data objects needed for that execution? If this is the way to go, 
> maybe the topic of semantic routing should have a transversal approach 
> within IRTF, located in a different RG.
>
> IMO, semantic routing aims to use a more programmable decision model, 
> able to exploit any information available on the packet head (data 
> identification, network function identification, host identification, 
> ToS, etc) and on the visited hosts (service semantics, contextual 
> information). IMO semantic routing does not have to be related to 
> changing the semantics of IP addresses. Although this is already being 
> done: e.g. with hICN, for instance.
>
> As for the addressing issue itself, the drafts presented to Intarea 
> aim to describe well-recognized scenarios that showcase possibly 
> different addressing requirements, as mentioned here with the 
> different identification space, but that does not mean that we need to 
> change the IP addressing model. Maybe we need a more flexible routing 
> to handle different identification spaces. And if this is the case, 
> again, this routing challenge is transversal to several IRTF groups.
>
> Cheers,
> Paulo
>
>     > That said, if that the goal of THIS RG, does its scope include
>     looking into other protocols that are not aligned with this goal?
>     > Say if your protocol is a routing protocol for end hosts rather
>     than to connect compute/storage/network in a unified manner?
>     differently. I believe we have ample places to work on routing
>     protocols from a research perspective. What would COINRG bring to
>     the party?
>
>     >
>     > C.
>     >
>     > Cc: Adrian Farrel <[email-masked]>; Marie-Jose Montpetit
>     <[email-masked]>; [email-masked]; Dirk Kutscher
>     <[email-masked]>; [email-masked]
>     >> The end game might be that pure networking engineers disappear
>     the same way telephony engineers disappeared with the advent of
>     the general-purpose networking protocols that could provide
>     communication services for any application. People just learn to
>     program distributed applications directly on these heterogeneous
>     compute platforms and the networking pieces just align with the
>     way the application behaves. Interconnect gets back to being
>     super-dumb pipes that connect these complexes together with the
>     topology emergent through the behavior of the distributed programs.
>     >
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcoin&amp;data=04%7C01%7Ccedric.westphal%40futurewei.com%7Cb15f4ad2954d4013e9dc08d9a6168752%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637723437982153141%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=N%2F81I6YCA8FVENEmXYMRXPWWXiue2tI3ChnAPbs%2FJ98%3D&amp;reserved=0>
>     >
>     > --
>     > Coin mailing list
>     > [email-masked]
> The information in this e-mail is confidential. The contents may not 
> be disclosed or used by anyone other than the addressee. Access to 
> this e-mail by anyone else is unauthorised.
> Airbus cannot accept any responsibility for the accuracy or 
> completeness of this e-mail as it has been sent over public networks. 
> If you have any concerns over the content of this message or its 
> Accuracy or Integrity, please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated 
> virus scanning software but you should take whatever measures you deem 
> to be appropriate to ensure that this message and any attachments are 
> virus free.
>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 14 Nov 2021 10:16:06 -0800

In the LISP deployments I am involved with we put a containerized LISP xTR co-located with the app. The app only knows about 240.0.0.0/4 addresses (EIDs) and the xTRs use locators that are assigned to the container. It’s kinda all automated where all addresses are allocated dynamically and then the binding happens in the mapping system. 

I call the deployments “routing-as-an-application”. It provides all of service meshes, VPNs, and traffic steering with no new components but minor configuration. 

Dino

> On Nov 14, 2021, at 9:56 AM, Bernier, Daniel <daniel.bernier=[email-masked]> wrote:
> 
>

---

From: Sharon Barkai <[email-masked]>
Date: Sun, 14 Nov 2021 11:28:39 -0800

> It is actually becoming quite interesting when thinking of application oriented networking, edge computing or slicing when you realize that the mesh control plane has visibility at higher layers an…

Or, Network oriented Applications, where multi-vendor interoperability is of value.  We presented two such use-cases in the LISP (Layer3.5) WG in Cyber Security and Vehicle Mobility. The commonalities where:

1. Data production is intense and after initial aggregation further propagation is needed based on: change, anomaly, exception… Reduction processing is multi-vendor in nature, vehicle, mobility, network, infrastructure, security .. providers

2. Data production is much higher than consumption, its therefore unlike CDNs in a sense that network functions are not generic and consumption is by push not pull, there are multiple derivative propagations to justify data upload costs  

3. In-network edge indirection for in-network processing is needed since DNS or generic load-balancing is less applicable because of latency over mobile, mass market cache coherency, or dependency of compute context on the data generated: street sampling/traffic sampling

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

> On Nov 14, 2021, at 09:56, Bernier, Daniel <daniel.bernier=[email-masked]> wrote:
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 15 Nov 2021 19:41:48 +0000

Adrian, all

I’m responding to Adrian's original message, but I have read the other messages in the thread and the proposed charter for the semantic routing work.

The proposed semantic routing work is about making more flexible packet routing and forwarding decisions based on either using information in the packet headers in addition to the IP address, or by modifying the addresses or interpreting them differently. This work is described as semantic routing, but must necessarily also consider the impact on the packet forwarding path, the in-network processing and state needs, and various deployment considerations. The proposal for a charter recognises much of this.

The feedback I gave ahead of the meeting was that some aspects of the semantic routing work fell into the scope of COINRG, and some parts overlapped with other IRTF groups. It seemed that there was no need for a new group, since IRTF had existing venues that covered key aspects of the proposed work. Parts of the work also seemed to be outside the scope of IRTF or better suited to other venues.

Having discussed with a number of people, with a range of views on the issue, attended the side meeting, and read the email discussion, I remain of that opinion. 

The proposed semantic routing work overlaps strongly with the scope of COINRG, and somewhat with several other IRTF groups. Not all of the work is in scope, but should the proponents want to discuss their ideas in IRTF, there are venues for it.

Accordingly, it does not seem appropriate to charter a semantic routing group.

This is not to say that the semantic routing work is uninteresting or unimportant. The proposal is one example of how the network might evolve, and it’s important to understand the implications of such changes. But the underlying problem is broader. The challenge for the network today is not whether it’s possible to add support for any particular new routing or forwarding proposal, but is rather how the architecture can evolve to encompass a network that’s programmable enough to support the range of proposals we’re seeing for enhanced routing, forwarding, caching, packet processing, and in-network computation. Understanding that broader problem is, to my mind, one of the key goals of COINRG. 

Colin

> On 11 Nov 2021, at 14:07, Adrian Farrel <[email-masked]> wrote:
> 
> Hi COIN chairs,
> 

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 22 Nov 2021 13:10:48 -0000

Colin,

Thanks for taking the time to give us guidance on this.

You’ve captured the essence of the work we’ve been talking about (as described at https://github.com/danielkinguk/sarah/ and in our drafts).

Obviously, we have some work to do to work out what bits belong in COIN, which pieces go in which other research groups, and which items are currently homeless. We’ll spend some time with the COIN chairs to try to make a start on this.

I think, as you note, we need to facilitate discussion of the many different proposals that pop up for enabling semantic routing, and we need to examine them against a common understanding of what makes routing work and stable.

We’ll start on this and work with the COIN community to advance the work.

Best,

Adrian

From: Colin Perkins <[email-masked]> 
Sent: 15 November 2021 19:42
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Coin] Charter discussion

Adrian, all

Colin

On 11 Nov 2021, at 14:07, Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Hi COIN chairs,

Thanks,
Adrian

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

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