Subject: Re: [Coin] Charter discussion

From: Marie-Jose Montpetit <[email-masked]>
Date: Sun, 14 Nov 2021 13:24:19 -0500

Forward of Dino’s answer.

From: Dino Farinacci <[email-masked]> <[email-masked]>
Reply: Dino Farinacci <[email-masked]> <[email-masked]>
Date: November 14, 2021 at 1:16:09 PM
To: Bernier, Daniel <daniel.bernier=[email-masked]>
<daniel.bernier=[email-masked]>
Cc: Jeff Tantsura <[email-masked]> <[email-masked]>, Hesham
ElBakoury <[email-masked]> <[email-masked]>, Marie-Jose
Montpetit <[email-masked]> <[email-masked]>, David R. Oran
<[email-masked]> <[email-masked]>, [email-masked]
<[email-masked]> <[email-masked]>, [email-masked]
<[email-masked]> <[email-masked]>, Dirk Kutscher <[email-masked]>
<[email-masked]>, Adrian Farrel <[email-masked]>
<[email-masked]>, [email-masked] <[email-masked]>
<[email-masked]>
Subject:  Re: [Coin] Charter discussion

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:

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

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:

> Yes I saw it and they are my list of people to invite to the next COIN.
>
> Marie-José Montpetit, Ph.D.
> [email-masked]
>
>
>
> 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
>
> On 13 Nov 2021, at 7:30, Marie-Jose Montpetit wrote:
>
> The “CoinOS" concept is very interesting and is what I was trying to start
> 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-José Montpetit, Ph.D.
> [email-masked]
>
> 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
>
> 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
>
> On Fri, 12 Nov 2021, David R. Oran wrote:
>
> 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.
>
> I don't think this requires any explicit re-chartering.
>
> Best regards,
> Dirk
>
> On 11 Nov 2021, at 15:13, Marie-Jose Montpetit wrote:
>
> 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,
>
> 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
>
> --
> Coin mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/coin
>
> --
> Coin mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/coin
>
> --
> Coin mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/coin
>
> --
> Coin mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/coin
>
-- 
Coin mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/coin

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

---

From: Hesham ElBakoury <[email-masked]>
Date: Sun, 14 Nov 2021 19:49:12 -0800

How we define in-network computing when we have a network of 
micro-services that happen to run on one or more servers. Virtual 
switches and physical switches in the underlying physical infrastructure 
can be involved in the communications between these micro-services. I 
think a function executed by the physical switch is an instance of 
in-network computing. What if the function is executed by a virtual 
switch running on a server, is this also considered a case of in-network 
computing ?

Thanks

Hesham

On 11/14/2021 10:24 AM, Marie-Jose Montpetit wrote:
> From: Dino Farinacci <[email-masked]> <mailto:[email-masked]>
> Reply: Dino Farinacci <[email-masked]> <mailto:[email-masked]>
> <mailto:daniel.bernier=[email-masked]>
> Cc: Jeff Tantsura <[email-masked]> 
> <mailto:[email-masked]>, Hesham ElBakoury 
> <[email-masked]> <mailto:[email-masked]>, Marie-Jose 
> Montpetit <[email-masked]> <mailto:[email-masked]>, 
> David R. Oran <[email-masked]> <mailto:[email-masked]>, 
> [email-masked] <[email-masked]> 
> <mailto:[email-masked]>, [email-masked] <[email-masked]> 
> <mailto:[email-masked]>, Dirk Kutscher <[email-masked]> 
> <mailto:[email-masked]>, Adrian Farrel <[email-masked]> 
> <mailto:[email-masked]>, [email-masked] 
> <[email-masked]> <mailto:[email-masked]>
>> 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 <http://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:
>>>
>>> 
>>> 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
>>>
>>> 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]
>>> 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
>>>
>>>> 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]>
>>>>     <mailto:[email-masked]>
>>>>     Reply: David R. Oran <[email-masked]>
>>>>     <mailto:[email-masked]>
>>>>     To: Marie-Jose Montpetit <[email-masked]>
>>>>     <mailto:[email-masked]>
>>>>     <mailto:[email-masked]>, [email-masked]
>>>>     <[email-masked]> <mailto:[email-masked]>,
>>>>     [email-masked] <[email-masked]>
>>>>     <mailto:[email-masked]>, Dirk Kutscher
>>>>     <[email-masked]> <mailto:[email-masked]>, [email-masked]
>>>>     <[email-masked]> <mailto:[email-masked]>
>>>>>     another interesting view is the Hotnets Paper from the UIUC
>>>>>     folks proposing service mesh interconnection via sidecars to
>>>>>     applications as the “new network layer”.
>>>>>
>>>>>         [email-masked] <[email-masked]>
>>>>>         <[email-masked]>, Marie-Jose
>>>>>         with a lot of the current work coming into COINRG. It’s
>>>>>         fine if that’s what
>>>>>         we decide to focus on.
>>>>>
>>>>>         networking devices in software for enhanced networking
>>>>>         functions”. Or, even
>>>>>         are “part of” the host, or as independent networking
>>>>>         devices with their own
>>>>>         application. People just learn to program distributed
>>>>>         applications directly
>>>>>         align with the way the application behaves. Interconnect
>>>>>         gets back to being
>>>>>                     Reply: [email-masked]
>>>>>                     <[email-masked]> <[email-masked]>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 15 Nov 2021 09:45:18 -0800

> How we define in-network computing when we have a network of micro-services that happen to run on one or more servers. Virtual switches and physical switches in the underlying physical infrastructure can be involved in the communications between these micro-services. I think a function executed by the physical switch is an instance of in-network computing. What if the function is executed by a virtual switch running on a server, is this also considered a case of in-network computing ?

Here is a one-slide high-level description. You can do anything you want with the packet at each encapsuulation hop. The reference to "ELP" below stand for "Explicit Locator Path" which means the EID maps to a RLOC-path of (left-RTR -> right-RTR -> ETR).

That is, the compute is done on each overlay edge (and not in the underlay network, the gray cloud below).

Dino