Subject: [Coin] COIN interim February 10th 15:00 UTC

From: Marie-Jose Montpetit <[email-masked]>
Date: Sun, 16 Jan 2022 07:28:15 -0800

Hello list and welcome to 2022!

There is a lot of activities in the realm of computing in the network as
more an more previously closed network devices are becoming more
programmable. We feel we need to dedicate an interim to how the charter of
the group covers impacts of programmability: forwarding, routing, caching,
in-network computation and packet processing.

We will send the Webex details but please note that the Interim is planned
for February 10th at 15:00 UTC.

The chairs with the support of Colin did some preliminary brainstorming and
agreed that one general objective of this RG is to explore how the
architecture can evolve to encompass a network that’s programmable enough
to provide flexibility and extensibility for various use cases - that seems
to become more numerous each day.

The computation that leverage the programmable network devices, as well as
in-flight computation that consumes data beyond the packet header are both
topics that naturally fall within the group charter. A topic for debate is
where is the dividing line between traditional packet header processing and
COIN fall and what is the most important research towards systems and
protocols. We feel that recent discussions on extensible Internet and
semantic routing are just 2 aspects of this evolution towards the
programmable network.

So mark the date and please suggest ideas for presentation highlighting the
interesting research in the field.

mjm

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

---

From: Dirk Trossen <[email-masked]>
Date: Thu, 20 Jan 2022 08:01:07 +0000

Hi Marie-Jose, all,

I hope you had a good start into 2022 and I wish you all the best moving into this new year!

Great to see the interim happening and thanks for kicking off the discussion on the charter. Let me try to outline a few thoughts defined through my current understanding of COIN, based on ongoing and past activities, with an intention to move forward.

Given the text below, specifically “general objective of this RG is to explore how the architecture can evolve to encompass a network that’s programmable enough to provide flexibility and extensibility for various use cases”, I can see three core parts of the charter:

A.     Formulate the vision and technologies for programmable networks (or ‘network is the computer’).

B.     Formulate distributed computing frameworks and languages to program the PN (or ‘network is the computer’) vision.

C.     Address the applicability of the former two to specific application areas

So far, activities around all three aspects have started (Dirk K’s draft, for instance, addressing items A and B) and some drafts on use cases, transport etc. When wanting to outline how to move forward, the following questions come to my mind:

1.      Do we agree that the first two items A and B are core to COIN albeit being a big story (in terms of activities) to tackle, particularly positioning this against how ‘in-network’ functions have been done so far (the dividing line MJM mentions below) and how it relates to, e.g., emerging edge computing?

2.      When addressing item C, i.e., wanting to tackle specific areas, should the approach be

a.      liaising with the many efforts in the IETF for doing so or

b.      pick a set of applicability areas?

If answering Q2.b positively, it poses additional questions on choice and scope, i.e., why picking specific applicability areas (over others) and if doing so, will we broaden the scope too much beyond working on the already challenging items A and B? Furthermore, do we have the constituency that we’d want to work on those selected applicability areas?

Best,

Dirk

From: Coin [mailto:[email-masked]] On Behalf Of Marie-Jose Montpetit
Sent: 16 January 2022 16:28
To: [email-masked]
Cc: coinrg-chairs <[email-masked]>; Colin Perkins <[email-masked]>
Subject: [Coin] COIN interim February 10th 15:00 UTC

There is a lot of activities in the realm of computing in the network as more an more previously closed network devices are becoming more programmable. We feel we need to dedicate an interim to how the charter of the group covers impacts of programmability: forwarding, routing, caching, in-network computation and packet processing.

We will send the Webex details but please note that the Interim is planned for February 10th at 15:00 UTC.

The chairs with the support of Colin did some preliminary brainstorming and agreed that one general objective of this RG is to explore how the architecture can evolve to encompass a network that’s programmable enough to provide flexibility and extensibility for various use cases - that seems to become more numerous each day.

The computation that leverage the programmable network devices, as well as in-flight computation that consumes data beyond the packet header are both topics that naturally fall within the group charter. A topic for debate is where is the dividing line between traditional packet header processing and COIN fall and what is the most important research towards systems and protocols. We feel that recent discussions on extensible Internet and semantic routing are just 2 aspects of this evolution towards the programmable network.

So mark the date and please suggest ideas for presentation highlighting the interesting research in the field.

mjm

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 21 Jan 2022 19:20:01 -0000

Hi all,

Dirk’s questions and Nik’s proposal to talk about Flightplan bring up a question for me.

While I find Dirk’s to be good questions, I find them hard to answer without a good definition of “programmable network.” I think we all know what we think that means, but it seems to me that everyone’s opinion is somewhat different. For example, some people see it as restricted to programmable switches for sophisticated forwarding planes. But other people see it as building service functions chains to deliver services using NFV. Still others, of course, see it as leveraging distributed function and capabilities (such as compute in the network). 

Of course, the answer may be “all of these” which is possibly fine, but requires much more attention to be given to the framework and architecture of what you have called “network is the computer”. I don’t at this stage, see any of that vision being brought to COIN and so it is hard to understand how the various pieces of work may fit together within the scope of COIN.

Another way to cut the problem space seems to be, as in Nik’s work, to look not at what is being programmed, but what is doing the programming, where it is located within the network, and what compute resources it uses. 

Anyway, a discussion of Dirk’s points would be helpful.

Best,

Adrian

From: Coin <[email-masked]> On Behalf Of Dirk Trossen
Sent: 20 January 2022 08:01
To: Marie-Jose Montpetit <[email-masked]>; [email-masked]
Cc: coinrg-chairs <[email-masked]>; Colin Perkins <[email-masked]>
Subject: Re: [Coin] COIN interim February 10th 15:00 UTC

Hi Marie-Jose, all,

Best,

Dirk

From: Coin [mailto:[email-masked]] On Behalf Of Marie-Jose Montpetit
Sent: 16 January 2022 16:28
To: [email-masked] <mailto:[email-masked]> 
Cc: coinrg-chairs <[email-masked] <mailto:[email-masked]> >; Colin Perkins <[email-masked] <mailto:[email-masked]> >
Subject: [Coin] COIN interim February 10th 15:00 UTC

mjm

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

---

From: Hesham ElBakoury <[email-masked]>
Date: Fri, 21 Jan 2022 13:02:22 -0800

Dan Pitt who led ONF defines programmable network as a *network whose
behaviors and personality changes can be effected through only software
with no change to the hardware infrastructure*.

What do you think?

Hesham

On Fri, Jan 21, 2022, 11:20 AM Adrian Farrel <[email-masked]> wrote:

> While I find Dirk’s to be good questions, I find them hard to answer
> without a good definition of “programmable network.” I think we all know
> what we think that means, but it seems to me that everyone’s opinion is
> somewhat different. For example, some people see it as restricted to
> programmable switches for sophisticated forwarding planes. But other people
> see it as building service functions chains to deliver services using NFV.
> Still others, of course, see it as leveraging distributed function and
> capabilities (such as compute in the network).
>
>
> Of course, the answer may be “all of these” which is possibly fine, but
> requires much more attention to be given to the framework and architecture
> of what you have called “network is the computer”. I don’t at this stage,
> see any of that vision being brought to COIN and so it is hard to
> understand how the various pieces of work may fit together within the scope
> of COIN.
>
>
>
> Another way to cut the problem space seems to be, as in Nik’s work, to
> look not at what is being programmed, but what is doing the programming,
> where it is located within the network, and what compute resources it uses.
>
>
>
> *From:* Coin <[email-masked]> *On Behalf Of *Dirk Trossen
> *Sent:* 20 January 2022 08:01
> *To:* Marie-Jose Montpetit <[email-masked]>; [email-masked]
> *Cc:* coinrg-chairs <[email-masked]>; Colin Perkins <
> [email-masked]>
> *Subject:* Re: [Coin] COIN interim February 10th 15:00 UTC
>
>
>
> Hi Marie-Jose, all,
>
>
>
> Great to see the interim happening and thanks for kicking off the
> discussion on the charter. Let me try to outline a few thoughts defined
> through my current understanding of COIN, based on ongoing and past
> activities, with an intention to move forward.
>
>
>
> Given the text below, specifically “general objective of this RG is to
> explore how the architecture can evolve to encompass a network that’s
> programmable enough to provide flexibility and extensibility for various
> use cases”, I can see three core parts of the charter:
>
>    1. Formulate the vision and technologies for programmable networks (or
>    ‘network is the computer’).
>    2. Formulate distributed computing frameworks and languages to program
>    the PN (or ‘network is the computer’) vision.
>    3. Address the applicability of the former two to specific application
>    areas
>
>
>
> So far, activities around all three aspects have started (Dirk K’s draft,
> for instance, addressing items A and B) and some drafts on use cases,
> transport etc. When wanting to outline how to move forward, the following
> questions come to my mind:
>
>    1. Do we agree that the first two items A and B are core to COIN
>    albeit being a big story (in terms of activities) to tackle, particularly
>    positioning this against how ‘in-network’ functions have been done so far
>    (the dividing line MJM mentions below) and how it relates to, e.g.,
>    emerging edge computing?
>       1. liaising with the many efforts in the IETF for doing so or
>       2. pick a set of applicability areas?
>
>
>
> If answering Q2.b positively, it poses additional questions on choice and
> scope, i.e., why picking specific applicability areas (over others) and if
> doing so, will we broaden the scope too much beyond working on the already
> challenging items A and B? Furthermore, do we have the constituency that
> we’d want to work on those selected applicability areas?
>
>
>
> Best,
>
>
>
> Dirk
>
>
>
> *From:* Coin [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Marie-Jose Montpetit
> *Sent:* 16 January 2022 16:28
> *To:* [email-masked]
> *Cc:* coinrg-chairs <[email-masked]>; Colin Perkins <
> [email-masked]>
> *Subject:* [Coin] COIN interim February 10th 15:00 UTC
>
>
>
> The chairs with the support of Colin did some preliminary brainstorming
> and agreed that one general objective of this RG is to explore how the
> --
> Coin mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/coin
>

---

From: Haoyu Song <[email-masked]>
Date: Fri, 21 Jan 2022 21:09:06 +0000

In a sense, the different aspects of the “programmable network” are actually in the same vein.
They all depend on  more and more flexible and powerful data plane chip and devices. First you allow customized forwarding functions, then support to include more extern functions (i.e., use SFC for NFV), and finally incorporate partial application logic and computation in the chip (i.e., in network computing). Now the chip technology can easily support the first one and eventually may be able to comfortably support the last one as well although currently it’s still in the early research stage.

Best,
Haoyu
From: Coin <[email-masked]> On Behalf Of Adrian Farrel
Sent: Friday, January 21, 2022 11:20 AM
To: 'Dirk Trossen' <dirk.trossen=[email-masked]>; 'Marie-Jose Montpetit' <[email-masked]>; [email-masked]
Cc: 'coinrg-chairs' <[email-masked]>; 'Colin Perkins' <[email-masked]>
Subject: Re: [Coin] COIN interim February 10th 15:00 UTC

Hi all,

Best,
Adrian

From: Coin <[email-masked]<mailto:[email-masked]>> On Behalf Of Dirk Trossen
Sent: 20 January 2022 08:01
To: Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: coinrg-chairs <[email-masked]<mailto:[email-masked]>>; Colin Perkins <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Coin] COIN interim February 10th 15:00 UTC

Hi Marie-Jose, all,

  1.  Formulate the vision and technologies for programmable networks (or ‘network is the computer’).
  2.  Formulate distributed computing frameworks and languages to program the PN (or ‘network is the computer’) vision.
  3.  Address the applicability of the former two to specific application areas

  1.  Do we agree that the first two items A and B are core to COIN albeit being a big story (in terms of activities) to tackle, particularly positioning this against how ‘in-network’ functions have been done so far (the dividing line MJM mentions below) and how it relates to, e.g., emerging edge computing?
  2.  When addressing item C, i.e., wanting to tackle specific areas, should the approach be
     *   liaising with the many efforts in the IETF for doing so or
     *   pick a set of applicability areas?

Best,

Dirk

From: Coin [mailto:[email-masked]] On Behalf Of Marie-Jose Montpetit
Sent: 16 January 2022 16:28
To: [email-masked]<mailto:[email-masked]>
Cc: coinrg-chairs <[email-masked]<mailto:[email-masked]>>; Colin Perkins <[email-masked]<mailto:[email-masked]>>
Subject: [Coin] COIN interim February 10th 15:00 UTC

mjm

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 21 Jan 2022 21:29:52 -0000

Thanks Haoyu,

I both agree and disagree with you 😊

One of the purposes of a programmable forwarding plane is to offload “intelligence” from the data plane components. That is, to enable them to be dumb forwarding engines. I would argue that OpenFlow and then P4 achieved this admirably such that all a forwarder has to do is match certain packet fields against a look-up table (where that table is programmed by the southbound protocol). On the other hand, you are right to say that the dumb forwarding engine is also made more powerful by this process.

Now, we could also leverage these approaches to place function in computation engines in the forwarding plane. That may be programmable virtual functions, etc. etc.

Maybe my question can be looked at as: is COIN seeking to do all of this, or is the focus on increasing the functionality in the network devices (rather than encouraging them to be dumb forwarders albeit with detailed matching)?

Would love to hear more opinions.

Cheers,

Adrian

From: Haoyu Song <[email-masked]> 
Sent: 21 January 2022 21:09
To: [email-masked]; 'Dirk Trossen' <dirk.trossen=[email-masked]>; 'Marie-Jose Montpetit' <[email-masked]>; [email-masked]
Cc: 'coinrg-chairs' <[email-masked]>; 'Colin Perkins' <[email-masked]>
Subject: RE: [Coin] COIN interim February 10th 15:00 UTC

Best,

Haoyu   

Hi all,

Best,

Adrian

From: Coin <[email-masked] <mailto:[email-masked]> > On Behalf Of Dirk Trossen
Sent: 20 January 2022 08:01
To: Marie-Jose Montpetit <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Cc: coinrg-chairs <[email-masked] <mailto:[email-masked]> >; Colin Perkins <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Coin] COIN interim February 10th 15:00 UTC

Hi Marie-Jose, all,

Best,

Dirk

mjm

---

From: Haoyu Song <[email-masked]>
Date: Fri, 21 Jan 2022 22:56:35 +0000

Hi Adrian,

I would argue that the programmability makes the data plane smart rather than dumb. Thanks to the data plane programmability, instead of being limited by a fix set of pre-defined functions offered by vendors (that’s pretty dumb, right?), now you can support many custom forwarding protocols/functions as you like. Should we call it dumb or smart? (we’ve see the trend of “smart” NIC built with programmable chips or DPU)
If we try to keep the data plane dumb, as the conventional wisdom does, perhaps the data plane programmability is not needed at all. Fixed hardware is faster and simpler and of course dumber 😊

The simple match action table abstraction used by P4 is actually very powerful for flexible forwarding programming. But it seems insufficient for computing in network. Perhaps we should look beyond P4.

Best,
Haoyu

From: Adrian Farrel <[email-masked]>
Sent: Friday, January 21, 2022 1:30 PM
To: Haoyu Song <[email-masked]>; 'Dirk Trossen' <dirk.trossen=[email-masked]>; 'Marie-Jose Montpetit' <[email-masked]>; [email-masked]
Cc: 'coinrg-chairs' <[email-masked]>; 'Colin Perkins' <[email-masked]>
Subject: RE: [Coin] COIN interim February 10th 15:00 UTC

Thanks Haoyu,

Cheers,
Adrian

From: Haoyu Song <[email-masked]<mailto:[email-masked]>>
Sent: 21 January 2022 21:09
To: [email-masked]<mailto:[email-masked]>; 'Dirk Trossen' <dirk.trossen=[email-masked]<mailto:dirk.trossen=[email-masked]>>; 'Marie-Jose Montpetit' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: 'coinrg-chairs' <[email-masked]<mailto:[email-masked]>>; 'Colin Perkins' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Coin] COIN interim February 10th 15:00 UTC

Best,
Haoyu
From: Coin <[email-masked]<mailto:[email-masked]>> On Behalf Of Adrian Farrel
Sent: Friday, January 21, 2022 11:20 AM
To: 'Dirk Trossen' <dirk.trossen=[email-masked]<mailto:dirk.trossen=[email-masked]>>; 'Marie-Jose Montpetit' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: 'coinrg-chairs' <[email-masked]<mailto:[email-masked]>>; 'Colin Perkins' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Coin] COIN interim February 10th 15:00 UTC

Hi all,

Best,
Adrian

Hi Marie-Jose, all,

Best,

Dirk

mjm