Subject: [Coin] Agenda for today

From: Marie-Jose Montpetit <[email-masked]>
Date: Fri, 7 Jun 2019 07:12:15 -0400

Agenda:
- review of the charter towards actualizing it
- Montreal hackaton
- Montreal meeting 
- other topics of interest

nhn
Marie-Jose Montpetit, Ph.D.
[email-masked]
[email-masked]
+1-781-526-2661
@SocialTVMIT

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 7 Jun 2019 13:50:42 +0000

Marie-Jose, all,

As for the charter, some comments:

  1.  Item 1 mentions the term 'network functions' as the scope of research. Is this limitation to 'network function' intended?
  2.  As mentioned in the call, item 2 (use cases) is a method useful not just for requirements analysis (which is solution oriented) but also for scoping of work, i.e., what is in scope of the RG and what is not
  3.  Item 2 states "Identify potential benefits to these networks from in-network functionality" which confuses me a bit in terms of 'these networks' as a focus here. Item 3 does recognize OTOH that we consider placement of compute 'even in end devices'. My main concern goes back to the feedback I received in the past from people who see 'the network' ending at the last link to the end device. If we see a continuum of providing services across devices that include end devices as well as 'in-network resources' then the benefits are not limited to 'the network' only. I suggest simply removing 'to these networks' from the statement
  4.  I understand item 4 having arisen from the interactions with the transport area but I wonder why we do not include 'routing' into the list here, unless we assume 'transport' does include 'routing'. On the other hand, item 3 includes 'new protocol designs' so it seems that the unique point about item 4 is in fact the security and privacy part so maybe rewording item 4 to "research on new privacy and security mechanisms required to enable in-network compute" would be best?

Last question for me to understand the scope: what is a programmable network device? An SDN or P4 switch? Or networked laptop? Or my mobile device? Or all of it? Throughout the charter text, we talk about programmability for 'devices', 'switches' as well as 'networks'. Maybe if we answer the question for 'device', we can provide good answers to the others?

Best,

Dirk

From: Coin <[email-masked]> On Behalf Of Marie-Jose Montpetit
Sent: 07 June 2019 12:12
To: [email-masked]
Subject: [Coin] Agenda for today

Agenda:

nhn
Marie-Jose Montpetit, Ph.D.
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
+1-781-526-2661
@SocialTVMIT

---

From: "Hejianfei (Jeffrey)" <[email-masked]>
Date: Wed, 19 Jun 2019 02:39:34 +0000

Hi Dirk,

Thank you for your comments for the charter. Marie-Jose, Eve and me discussed these in our bi-weekly co-chair meeting, and the response below (with [JEM]) reflects what we three think. Of course, it is how this GROUP feel and think that decides what this group should do…

JEM(Jeffrey, Eve, Marie-Jose)

发件人: Coin [mailto:[email-masked]] 代表 Dirk Trossen
发送时间: 2019年6月7日 21:51
收件人: Marie-Jose Montpetit <[email-masked]>; [email-masked]
主题: Re: [Coin] Agenda for today

Marie-Jose, all,

As for the charter, some comments:
1.       Item 1 mentions the term ‘network functions’ as the scope of research. Is this limitation to ‘network function’ intended?
[JEM] After all, we are talking about “in-network” functions. “Network function” is still ok, only if we don’t limit “ network function” to simply forwarding.
2.       As mentioned in the call, item 2 (use cases) is a method useful not just for requirements analysis (which is solution oriented) but also for scoping of work, i.e., what is in scope of the RG and what is not
[JEM] If we discuss how use cases are related to the scope, we may need to clarify two levels: networks and applications above. We are addressing different sectors of networks, mainly three now: DCN, industrial networks and Edge(with Cloud continuum). And there are different applications related to these three sectors, such as video streaming, immersive AR/VR, autonomous/connected vehicles, industrial IoT.  We need to take care of the relationship between network sectors and applications. One potential and ambitious objective is to explore the common architecture or abstraction for these three, but an even less ambitious reason to address all three in this research group is that these sectors can learn from each other. E.g. the metro network connecting edges has the similarity with DCN connecting servers(e.g how to better convey the distributed computing system), while the experience in in-network control from smart factory may be inspiring for the mission critical services in edge networking in smart city. It is up to the group to decide based on their interest if we address all these three or focus some of them. But to us three, all three are related and interesting.
3.       Item 2 states “Identify potential benefits to these networks from in-network functionality” which confuses me a bit in terms of ‘these networks’ as a focus here. Item 3 does recognize OTOH that we consider placement of compute ‘even in end devices’. My main concern goes back to the feedback I received in the past from people who see ‘the network’ ending at the last link to the end device. If we see a continuum of providing services across devices that include end devices as well as ‘in-network resources’ then the benefits are not limited to ‘the network’ only. I suggest simply removing ‘to these networks’ from the statement
[JEM] Yes, we think “simply removing ‘to these networks’ from the statement” is fine.
4.       I understand item 4 having arisen from the interactions with the transport area but I wonder why we do not include ‘routing’ into the list here, unless we assume ‘transport’ does include ‘routing’. On the other hand, item 3 includes ‘new protocol designs’ so it seems that the unique point about item 4 is in fact the security and privacy part so maybe rewording item 4 to “research on new privacy and security mechanisms required to enable in-network compute” would be best?
[JEM] Yes,  we agree that  probably moving “transport protocol” to item3 can resolve the ambiguousness. Then the item 3 may looks like: “Research on novel architectures, data-plane abstractions and new networking/transport protocols designs to…” The reason behind current text:  networking is layer-2/3, transport is layer-4, so the current item3 is emphasize the layer-2/3 as the data plane in the switches and routers, while transport are at the host side. But Dirk is right, it is confusing to separate “ transport” from “ network”.
Last question for me to understand the scope: what is a programmable network device? An SDN or P4 switch? Or networked laptop? Or my mobile device? Or all of it? Throughout the charter text, we talk about programmability for ‘devices’, ‘switches’ as well as ‘networks’. Maybe if we answer the question for ‘device’, we can provide good answers to the others?
[JEM] A programmable “network device” can be:  a programmable switch, a router with Network Processor Units(NPUs) which is typically also programmable but not as open as a P4 switch, a soft-router/switch with X86 or ARM in the context of NFV, or something made of FPGA, and so on. Logically we differentiate “network device” from “host”(“the network’ ending at the last link to the end device”) , but physically a network node and a host may be implemented in the same real hardware: these mobile phones/laptops can function as “network nodes” besides “hosts”. This is not what we try to emphasize at this stage, but it is possible. That’s why we state “’even’ in the end-user device” in item 3.

Best,

Dirk

From: Coin <[email-masked]<mailto:[email-masked]>> On Behalf Of Marie-Jose Montpetit
Sent: 07 June 2019 12:12
To: [email-masked]<mailto:[email-masked]>
Subject: [Coin] Agenda for today

Agenda:

nhn

---

From: Dirk Trossen <[email-masked]>
Date: Wed, 19 Jun 2019 07:26:38 +0000

Hi JEM,

Please see inline

From: Hejianfei (Jeffrey) <[email-masked]>
Sent: 19 June 2019 03:40
To: Dirk Trossen <[email-masked]>; Marie-Jose Montpetit <[email-masked]>; [email-masked]
Subject: 答复: [Coin] Agenda for today

Hi Dirk,

发件人: Coin [mailto:[email-masked]] 代表 Dirk Trossen
发送时间: 2019年6月7日 21:51
收件人: Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
主题: Re: [Coin] Agenda for today

Marie-Jose, all,

[DOT] This sounds like ‘scoping’ is part of this, that’s all I thought and wanted to make clear. I do agree on the aspect of bringing communities together in order to inform them of possible similarities in other areas.
[DOT] Great!
[DOT] Great!
[DOT] I would think that a lot about ‘in-network computing’ is that the boundary between the traditional ‘network’ and the ‘host’ is transient at best. I do understand the differentiation at any given point in time but also in order to have such transient network/host view, the aspect of programmability (in the network) extends beyond programmable forwarding actions only. That was mainly my point here.

Best,

Dirk

Agenda:

nhn

---

From: <[email-masked]>
Date: Wed, 19 Jun 2019 08:02:30 -0400

Please see in line below.

From: Coin <[email-masked]> On Behalf Of Hejianfei (Jeffrey)
Sent: Tuesday, June 18, 2019 10:40 PM
To: Dirk Trossen <[email-masked]>; Marie-Jose Montpetit <[email-masked]>; [email-masked]
Subject: [Coin] 答复: Agenda for today

Hi Dirk,

发件人: Coin [mailto:coin-bounces@irtf..org] 代表 Dirk Trossen
发送时间: 2019年6月7日 21:51
收件人: Marie-Jose Montpetit <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
主题: Re: [Coin] Agenda for today

Marie-Jose, all,

[JEM] A programmable “network device” can be:  a programmable switch, a router with Network Processor Units(NPUs) which is typically also programmable but not as open as a P4 switch, a soft-router/switch with X86 or ARM in the context of NFV, or something made of FPGA, and so on. 

[HS] Minor point.  Please see  <https://github.com/hesingh/p4-info> https://github.com/hesingh/p4-info which lists NPU, FPGA, and generic computer as all being programmable using P4.  

Logically we differentiate “network device” from “host”(“the network’ ending at the last link to the end device”) , but physically a network node and a host may be implemented in the same real hardware: these mobile phones/laptops can function as “network nodes” besides “hosts”. This is not what we try to emphasize at this stage, but it is possible. That’s why we state “’even’ in the end-user device” in item 3.

[HS] When an interface on a router acquires an IP/IPv6 address, the interface is a host.  I would elide all mention of host, mobile device, laptop, etc.  Just stick to “computing in network”.  The network may be connecting a laptop, cell phone, router, switch, refrigerator, smart speaker, whatever…

Hemant

---

From: Dirk Trossen <[email-masked]>
Date: Wed, 19 Jun 2019 15:49:04 +0000

Hemant

I was under the impression the RG would target computing in networks (COIN). I didn't see this as limited to essentially programmable routing and forwarding. If indeed the group targets the intersection of computing and communication, as expressed early in the charter, the removal of any mentioning of host is rather questionable to me.

Best

Dirk
________________________________
From: [email-masked] <[email-masked]>
Sent: Wednesday, June 19, 2019 1:02:30 PM
To: 'Hejianfei (Jeffrey)'; Dirk Trossen; 'Marie-Jose Montpetit'; [email-masked]
Subject: RE: [Coin] 答复: Agenda for today

Hi Dirk,

Marie-Jose, all,

[HS] Minor point.  Please see https://github.com/hesingh/p4-info which lists NPU, FPGA, and generic computer as all being programmable using P4.

Hemant

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 19 Jun 2019 11:52:04 -0400

(Chair hat off):
I actually agree with Dirk. I would not want to limit computing to the routing and forwarding. We have discussed meta data processing in the past for example. And host is generic enough.

mjm

> On Jun 19, 2019, at 11:49 AM, Dirk Trossen <[email-masked]> wrote:
> 
> Hemant
> 
> From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> To: 'Hejianfei (Jeffrey)'; Dirk Trossen; 'Marie-Jose Montpetit'; [email-masked] <mailto:[email-masked]>
> From: Coin <[email-masked] <mailto:[email-masked]>> On Behalf Of Hejianfei (Jeffrey)
> To: Dirk Trossen <[email-masked] <mailto:[email-masked]>>; Marie-Jose Montpetit <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> 发件人: Coin [mailto:coin-bounces@irtf..org <mailto:coin-bounces@irtf..org>] 代表 Dirk Trossen
> 发送时间: 2019年6月7日 21:51
> 收件人: Marie-Jose Montpetit <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> [HS] Minor point.  Please see https://github.com/hesingh/p4-info <https://github.com/hesingh/p4-info> which lists NPU, FPGA, and generic computer as all being programmable using P4. 
>

---

From: Jörg Ott <[email-masked]>
Date: Wed, 19 Jun 2019 17:56:35 +0200

+1 on beyond routing and forwarding.
Will take another look if host is sufficient 
but this is too tricky now on a mobile...

Jörg

Sent from my iPhone

> On 19. Jun 2019, at 17:52, Marie-Jose Montpetit <[email-masked]> wrote:
> 
> (Chair hat off):
> -- 
> Coin mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/coin

---

From: <[email-masked]>
Date: Wed, 19 Jun 2019 12:22:57 -0400

Ok, folks,

Adding host is fine then.

Hemant

From: Marie-Jose Montpetit <[email-masked]> 
Sent: Wednesday, June 19, 2019 11:52 AM
To: Dirk Trossen <[email-masked]>
Cc: Hejianfei (Jeffrey) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Coin] 答复: Agenda for today

(Chair hat off):

mjm

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

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

+1-781-526-2661

@SocialTVMIT

On Jun 19, 2019, at 11:49 AM, Dirk Trossen <[email-masked] <mailto:[email-masked]> > wrote:

Hemant

Best

Dirk

  _____  

From:  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> [email-masked]>
Sent: Wednesday, June 19, 2019 1:02:30 PM
To: 'Hejianfei (Jeffrey)'; Dirk Trossen; 'Marie-Jose Montpetit';  <mailto:[email-masked]> [email-masked]
Subject: RE: [Coin] 答复: Agenda for today

From: Coin < <mailto:[email-masked]> [email-masked]> On Behalf Of Hejianfei (Jeffrey)
Sent: Tuesday, June 18, 2019 10:40 PM
To: Dirk Trossen < <mailto:[email-masked]> [email-masked]>; Marie-Jose Montpetit < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Subject: [Coin] 答复: Agenda for today

Hi Dirk,

发件人: Coin [ <mailto:coin-bounces@irtf..org> mailto:coin-bounces@irtf..org] 代表 Dirk Trossen
发送时间: 2019年6月7日 21:51
收件人: Marie-Jose Montpetit < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
主题: Re: [Coin] Agenda for today

Marie-Jose, all,

Hemant

---

From: "Dirk Kutscher" <[email-masked]>
Date: Thu, 20 Jun 2019 12:10:22 +0200

Hi,

More generally, “computing in the network” has the potential to open 
new perspectives on the relationship of “hosts”, “network” as 
well as on layers, i.e., required services and functional 
modularization.

I don’t think it’s helpful if we constrain ourselves to 1990s 
textbook categories (such as “L3”, “L4”). These categories were 
not god-given anyway — they just helped in designing systems at a time 
and explaining them…

IMO, one of the COIN objectives should be to propose/define new 
categories for functional composition that help to us to describe the 
relevant COIN scenarios.

Just as an example, if we consider a set of distributed data sources and 
processing/aggregation functions a COIN use case, what would be the 
“L4” protocol? What would be the “end-to-end” service?

An example at the other end of the spectrum could be a set of 
programmable network nodes that get programmed by some SDN controller to 
achieve a certain packet forwarding behaviour (for example, multicast 
distribution).

What abstraction could be useful to describe these two use cases in one 
framework? (And is there any value in trying to find them?) IMO these 
are good challenges for COIN.

And, in that context, SDN frameworks, control protocols (such as 
OpenFlow), programming languages (such as P4) are IMO just tools that 
could be useful in one or the other scenario — just like execution 
environments are tools — they should not define the concepts and 
decomposition categories we talk about here.

Summarizing, I agree to DirkT that COIN should go beyond programmable 
routing and forwarding, and when doing that, we have to rethink 
traditional definitions of hosts, networks etc.

Cheers,
Dirk

On 19 Jun 2019, at 17:52, Marie-Jose Montpetit wrote:

> (Chair hat off):
> I actually agree with Dirk. I would not want to limit computing to the 
> routing and forwarding. We have discussed meta data processing in the 
> past for example. And host is generic enough.
>
> mjm
>> I was under the impression the RG would target computing in networks 
>> (COIN). I didn't see this as limited to essentially programmable 
>> routing and forwarding. If indeed the group targets the intersection 
>> of computing and communication, as expressed early in the charter, 
>> the removal of any mentioning of host is rather questionable to me.
>>
>> Best
>>
>> Dirk
>> To: Dirk Trossen <[email-masked] 
>> <mailto:[email-masked]>>; Marie-Jose Montpetit 
>> <[email-masked] <mailto:[email-masked]>>; [email-masked] 
>> <mailto:[email-masked]>
>> Thank you for your comments for the charter. Marie-Jose, Eve and me 
>> discussed these in our bi-weekly co-chair meeting, and the response 
>> below (with [JEM]) reflects what we three think. Of course, it is how 
>> this GROUP feel and think that decides what this group should do…
>>
>> 发件人: Coin [mailto:coin-bounces@irtf..org 
>> <mailto:coin-bounces@irtf..org>] 代表 Dirk Trossen
>> 发送时间: 2019年6月7日 21:51
>> 收件人: Marie-Jose Montpetit <[email-masked] 
>> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> 1.      Item 1 mentions the term ‘network functions’ as the scope 
>> of research. Is this limitation to ‘network function’ intended?
>> [JEM] After all, we are talking about “in-network” functions. 
>> “Network function” is still ok, only if we don’t limit “ 
>> network function” to simply forwarding.
>> 2.      As mentioned in the call, item 2 (use cases) is a method 
>> useful not just for requirements analysis (which is solution 
>> oriented) but also for scoping of work, i.e., what is in scope of the 
>> RG and what is not
>> [JEM] If we discuss how use cases are related to the scope, we may 
>> need to clarify two levels: networks and applications above. We are 
>> addressing different sectors of networks, mainly three now: DCN, 
>> industrial networks and Edge(with Cloud continuum). And there are 
>> different applications related to these three sectors, such as video 
>> streaming, immersive AR/VR, autonomous/connected vehicles, industrial 
>> IoT.  We need to take care of the relationship between network 
>> sectors and applications. One potential and ambitious objective is to 
>> explore the common architecture or abstraction for these three, but 
>> an even less ambitious reason to address all three in this research 
>> group is that these sectors can learn from each other. E.g. the metro 
>> network connecting edges has the similarity with DCN connecting 
>> servers(e.g how to better convey the distributed computing system), 
>> while the experience in in-network control from smart factory may be 
>> inspiring for the mission critical services in edge networking in 
>> smart city. It is up to the group to decide based on their interest 
>> if we address all these three or focus some of them. But to us three, 
>> all three are related and interesting.
>> 3.      Item 2 states “Identify potential benefits to these 
>> networks from in-network functionality” which confuses me a bit in 
>> terms of ‘these networks’ as a focus here. Item 3 does recognize 
>> OTOH that we consider placement of compute ‘even in end devices’. 
>> My main concern goes back to the feedback I received in the past from 
>> people who see ‘the network’ ending at the last link to the end 
>> device. If we see a continuum of providing services across devices 
>> that include end devices as well as ‘in-network resources’ then 
>> the benefits are not limited to ‘the network’ only. I suggest 
>> simply removing ‘to these networks’ from the statement
>> 4.      I understand item 4 having arisen from the interactions with 
>> the transport area but I wonder why we do not include ‘routing’ 
>> into the list here, unless we assume ‘transport’ does include 
>> ‘routing’. On the other hand, item 3 includes ‘new protocol 
>> designs’ so it seems that the unique point about item 4 is in fact 
>> the security and privacy part so maybe rewording item 4 to 
>> “research on new privacy and security mechanisms required to enable 
>> in-network compute” would be best?
>> [JEM] Yes,  we agree that  probably moving “transport protocol” 
>> to item3 can resolve the ambiguousness. Then the item 3 may looks 
>> like: “Research on novel architectures, data-plane abstractions and 
>> new networking/transport protocols designs to…” The reason behind 
>> current text:  networking is layer-2/3, transport is layer-4, so the 
>> current item3 is emphasize the layer-2/3 as the data plane in the 
>> switches and routers, while transport are at the host side. But Dirk 
>> is right, it is confusing to separate “ transport” from “ 
>> network”.
>> Last question for me to understand the scope: what is a programmable 
>> network device? An SDN or P4 switch? Or networked laptop? Or my 
>> mobile device? Or all of it? Throughout the charter text, we talk 
>> about programmability for ‘devices’, ‘switches’ as well as 
>> ‘networks’. Maybe if we answer the question for ‘device’, we 
>> can provide good answers to the others?
>> [JEM] A programmable “network device” can be:  a programmable 
>> switch, a router with Network Processor Units(NPUs) which is 
>> typically also programmable but not as open as a P4 switch, a 
>> soft-router/switch with X86 or ARM in the context of NFV, or 
>> something made of FPGA, and so on.
>>
>> [HS] Minor point.  Please see https://github.com/hesingh/p4-info 
>> <https://github.com/hesingh/p4-info> which lists NPU, FPGA, and 
>> generic computer as all being programmable using P4.
>>
>> Logically we differentiate “network device” from 
>> “host”(“the network’ ending at the last link to the end 
>> device”) , but physically a network node and a host may be 
>> implemented in the same real hardware: these mobile phones/laptops 
>> can function as “network nodes” besides “hosts”. This is not 
>> what we try to emphasize at this stage, but it is possible. That’s 
>> why we state “’even’ in the end-user device” in item 3.
>>
>> [HS] When an interface on a router acquires an IP/IPv6 address, the 
>> interface is a host.  I would elide all mention of host, mobile 
>> device, laptop, etc.  Just stick to “computing in network”.  The 
>> network may be connecting a laptop, cell phone, router, switch, 
>> refrigerator, smart speaker, whatever…
>>
>> Hemant

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 20 Jun 2019 15:17:31 +0000

Hi,

I wholeheartedly support the two Dirk’s and Marie-Jose’s positions. The COIN concept should make us consider new ways of thinking about how we structure and abstract data forwarding and data processing mechanisms, including the current layering approaches, and the endpoint concepts and its corollary on end-to-end requirements.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]<mailto:[email-masked]>
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 20/06/2019, 12:11, "Coin on behalf of Dirk Kutscher" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi,

More generally, “computing in the network” has the potential to open new perspectives on the relationship of “hosts”, “network” as well as on layers, i.e., required services and functional modularization.

I don’t think it’s helpful if we constrain ourselves to 1990s textbook categories (such as “L3”, “L4”). These categories were not god-given anyway — they just helped in designing systems at a time and explaining them…

IMO, one of the COIN objectives should be to propose/define new categories for functional composition that help to us to describe the relevant COIN scenarios.

Just as an example, if we consider a set of distributed data sources and processing/aggregation functions a COIN use case, what would be the “L4” protocol? What would be the “end-to-end” service?

An example at the other end of the spectrum could be a set of programmable network nodes that get programmed by some SDN controller to achieve a certain packet forwarding behaviour (for example, multicast distribution).

What abstraction could be useful to describe these two use cases in one framework? (And is there any value in trying to find them?) IMO these are good challenges for COIN.

And, in that context, SDN frameworks, control protocols (such as OpenFlow), programming languages (such as P4) are IMO just tools that could be useful in one or the other scenario — just like execution environments are tools — they should not define the concepts and decomposition categories we talk about here.

Summarizing, I agree to DirkT that COIN should go beyond programmable routing and forwarding, and when doing that, we have to rethink traditional definitions of hosts, networks etc.

Cheers,
Dirk

mjm

On Jun 19, 2019, at 11:49 AM, Dirk Trossen <[email-masked]<mailto:[email-masked]>> wrote:

Hemant
I was under the impression the RG would target computing in networks (COIN). I didn't see this as limited to essentially programmable routing and forwarding. If indeed the group targets the intersection of computing and communication, as expressed early in the charter, the removal of any mentioning of host is rather questionable to me.
Best
Dirk
________________________________
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 19, 2019 1:02:30 PM
To: 'Hejianfei (Jeffrey)'; Dirk Trossen; 'Marie-Jose Montpetit'; [email-masked]<mailto:[email-masked]>
Subject: RE: [Coin] 答复: Agenda for today

From: Coin <[email-masked]<mailto:[email-masked]>> On Behalf Of Hejianfei (Jeffrey)
Sent: Tuesday, June 18, 2019 10:40 PM
To: Dirk Trossen <[email-masked]<mailto:[email-masked]>>; Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [Coin] 答复: Agenda for today

Hi Dirk,

Marie-Jose, all,

Hemant

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: [email-masked]
Date: Thu, 20 Jun 2019 08:23:10 -0700 (PDT)

Hi Dirk,

agreeing on many points, and yes to finding an abstraction. Here is a suggestion (which could help to sharpen the charter?) that focuses onthe control locus instead of hosts, interfaces or tools:

There is "computing in the network" IFF these conditions hold:
- function execution is triggered from within the net (control inside the net)
- there is choice as of which function to execute (late binding)
- function results are accessible inside the net, can act as triggers (chaining).

With this definition, plain forwarding is out but also one of your cases where the SDN controller merely configures a multicast tree.

best, cft

On Thu, 20 Jun 2019, Dirk Kutscher wrote:

> 
> Hi,
> 
> More generally, “computing in the network” has the potential to open new perspectives on the relationship of “hosts”, “network” as
> well as on layers, i.e., required services and functional modularization.
> 
> I don’t think it’s helpful if we constrain ourselves to 1990s textbook categories (such as “L3”, “L4”). These categories were not
> god-given anyway — they just helped in designing systems at a time and explaining them…
> 
> Just as an example, if we consider a set of distributed data sources and processing/aggregation functions a COIN use case, what
> would be the “L4” protocol? What would be the “end-to-end” service?
> 
> An example at the other end of the spectrum could be a set of programmable network nodes that get programmed by some SDN controller
> to achieve a certain packet forwarding behaviour (for example, multicast distribution).
> 
> And, in that context, SDN frameworks, control protocols (such as OpenFlow), programming languages (such as P4) are IMO just tools
> that could be useful in one or the other scenario — just like execution environments are tools — they should not define the concepts
> and decomposition categories we talk about here.
> 
> Summarizing, I agree to DirkT that COIN should go beyond programmable routing and forwarding, and when doing that, we have to
> rethink traditional definitions of hosts, networks etc.
> 
> Cheers,
> Dirk
> 
> 
> 
> 
> 
> 
>       (Chair hat off):I actually agree with Dirk. I would not want to limit computing to the routing and forwarding. We have
>       discussed meta data processing in the past for example. And host is generic enough.
> 
> mjm
> I was under the impression the RG would target computing in networks (COIN). I didn't see this as limited to essentially
> programmable routing and forwarding. If indeed the group targets the intersection of computing and communication, as
> expressed early in the charter, the removal of any mentioning of host is rather questionable to me.
> 
> Best
> 
> Dirk
> 
> ____________________________________________________________________________________________________________________________________
> Thank you for your comments for the charter. Marie-Jose, Eve and me discussed these in our bi-weekly co-chair meeting,
> and the response below (with [JEM]) reflects what we three think. Of course, it is how this GROUP feel and think that
> decides what this group should do…
>
> 
> 
> 2.      As mentioned in the call, item 2 (use cases) is a method useful not just for requirements analysis (which is
> solution oriented) but also for scoping of work, i.e., what is in scope of the RG and what is not
> [JEM] If we discuss how use cases are related to the scope, we may need to clarify two levels: networks and applications
> above. We are addressing different sectors of networks, mainly three now: DCN, industrial networks and Edge(with Cloud
> continuum). And there are different applications related to these three sectors, such as video streaming, immersive
> AR/VR, autonomous/connected vehicles, industrial IoT.  We need to take care of the relationship between network sectors
> and applications. One potential and ambitious objective is to explore the common architecture or abstraction for these
> three, but an even less ambitious reason to address all three in this research group is that these sectors can learn
> from each other. E.g. the metro network connecting edges has the similarity with DCN connecting servers(e.g how to
> better convey the distributed computing system), while the experience in in-network control from smart factory may be
> inspiring for the mission critical services in edge networking in smart city. It is up to the group to decide based on
> their interest if we address all these three or focus some of them. But to us three, all three are related and
> interesting.
> 3.      Item 2 states “Identify potential benefits to these networks from in-network functionality” which confuses me a
> bit in terms of ‘these networks’ as a focus here. Item 3 does recognize OTOH that we consider placement of compute ‘even
> in end devices’. My main concern goes back to the feedback I received in the past from people who see ‘the network’
> ending at the last link to the end device. If we see a continuum of providing services across devices that include end
> devices as well as ‘in-network resources’ then the benefits are not limited to ‘the network’ only. I suggest simply
> removing ‘to these networks’ from the statement
> 4.      I understand item 4 having arisen from the interactions with the transport area but I wonder why we do not
> include ‘routing’ into the list here, unless we assume ‘transport’ does include ‘routing’. On the other hand, item 3
> includes ‘new protocol designs’ so it seems that the unique point about item 4 is in fact the security and privacy part
> so maybe rewording item 4 to “research on new privacy and security mechanisms required to enable in-network compute”
> would be best?
> [JEM] Yes,  we agree that  probably moving “transport protocol” to item3 can resolve the ambiguousness. Then the item 3
> may looks like: “Research on novel architectures, data-plane abstractions and new networking/transport protocols designs
> to…” The reason behind current text:  networking is layer-2/3, transport is layer-4, so the current item3 is emphasize
> the layer-2/3 as the data plane in the switches and routers, while transport are at the host side. But Dirk is right, it
> is confusing to separate “ transport” from “ network”.
> Last question for me to understand the scope: what is a programmable network device? An SDN or P4 switch? Or networked
> laptop? Or my mobile device? Or all of it? Throughout the charter text, we talk about programmability for ‘devices’,
> ‘switches’ as well as ‘networks’. Maybe if we answer the question for ‘device’, we can provide good answers to the
> others?
> [JEM] A programmable “network device” can be:  a programmable switch, a router with Network Processor Units(NPUs) which
> is typically also programmable but not as open as a P4 switch, a soft-router/switch with X86 or ARM in the context of
> NFV, or something made of FPGA, and so on. 
>
> 
> 
> Logically we differentiate “network device” from “host”(“the network’ ending at the last link to the end device”) , but
> physically a network node and a host may be implemented in the same real hardware: these mobile phones/laptops can
> function as “network nodes” besides “hosts”. This is not what we try to emphasize at this stage, but it is possible.
> That’s why we state “’even’ in the end-user device” in item 3.
>
> 
> 
> [HS] When an interface on a router acquires an IP/IPv6 address, the interface is a host.  I would elide all mention of
> host, mobile device, laptop, etc.  Just stick to “computing in network”.  The network may be connecting a laptop, cell
> phone, router, switch, refrigerator, smart speaker, whatever…
>
> 
> 
> Hemant 
> 
>
>       --
>       Coin mailing list
>       [email-masked]

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 20 Jun 2019 13:27:48 -0400

On 20 Jun 2019, at 11:23, [email-masked] wrote:

> Hi Dirk,
>
> agreeing on many points, and yes to finding an abstraction. Here is a 
> suggestion (which could help to sharpen the charter?) that focuses 
> onthe control locus instead of hosts, interfaces or tools:
>
I’m not entirely sure I agree with this. The unstated implication (or 
at least the implication I derive) is that there is an administrative 
separation between the entire that operates and runs application on 
hosts, and the entity that operates and the network and decides what 
computations run and where. Therefore if one does not start from this 
mental model:

- It does not seem fundamental to me from where the function execution 
is triggered.
	
	- As an example from a different era and somewhat different problem 
domain, consider Packetcable Multimedia, which is a QoS resource 
management protocol for CMTSs based on COPS. In this case an application 
running on a host sends PCMM function calls to a execution box 
“inside” the network, which in turn uses COPS to install QoS state 
in the CMTS. Which part of this is “inside the network”? If you say 
it’s just the two ends of COPS, then the function of installing QoS 
state is executed “inside” and the “trigger” is also inside, as 
the function that derives the COPS stuff from the PCMM calls, is under 
control of the cable operator and hence “inside” the network. If, on 
the other hand you start with the PCMM request as the “trigger”, the 
function execution is invoked from a host “outside” the network.

	- Conversely, RICE (or for that matter NFN) method invocation could 
arrive at an ICN forwarder which has an associated internal module 
capable of executing the function and returning results. In this case 
the “trigger” is the original call, possibly from a host 
“outside” the network being forwarded through ICN routers, and the 
“execution” is just another piece of method/function code on the 
router/forwarder and therefore “inside” the network.

- Late versus early binding also seems somewhat orthogonal. One can do 
late binding (as my second example above shows), or quite possibly early 
binding by setting up a full computation graph statically at the first 
invocation. In fact, you might even do it at compile time if you have a 
network with stable and predictable topological and resource structure, 
as one might for example in a toroidal mesh of TPUs in a Google data 
center that are all resources “inside” the data center network and 
not the application hosts executing the ML application.

- I imagine that chaining (at least the simple forms like SFC or NFV) 
can’t cross administrative boundaries easily and hence might be 
constrained to be entirely “inside” the network, but why start from 
this limitation?

For me, the more important characteristics of “in network” computing 
are things like:

- computations are done on devices placed topologically at interior 
nodes of the network graph, as opposed only at the edges of the graph.

- The security perimeter is around the computation instance, not a 
topological boundary of the connectivity graph, hence one can keep an 
entire distributed computation inside one security perimeter and not 
have to either leak data or share keys with third parties.

- Any state kept and/or mutated by the computation is considered 
application state, not state related to the operation of the basic 
forwarding and topology maintenance function of the network devices.

> With this definition, plain forwarding is out but also one of your 
> cases where the SDN controller merely configures a multicast tree.
>
I think my definitions are somewhat orthogonal to these concerns…

What do people think? which general way of thinking about in-network 
computing resonates better?

DaveO.

>> More generally, “computing in the network” has the potential to 
>> open new perspectives on the relationship of “hosts”, 
>> “network” as
>> textbook categories (such as “L3”, “L4”). These categories 
>> were not
>> categories for functional composition that help to us to describe
>> the relevant COIN scenarios.
>>
>> Just as an example, if we consider a set of distributed data sources 
>> and processing/aggregation functions a COIN use case, what
>> programmable network nodes that get programmed by some SDN controller
>> What abstraction could be useful to describe these two use cases in 
>> one framework? (And is there any value in trying to find them?)
>> IMO these are good challenges for COIN.
>>
>> OpenFlow), programming languages (such as P4) are IMO just tools
>> that could be useful in one or the other scenario — just like 
>> execution environments are tools — they should not define the 
>> concepts
>> routing and forwarding, and when doing that, we have to
>>       (Chair hat off):I actually agree with Dirk. I would not want to 
>> limit computing to the routing and forwarding. We have
>> (COIN). I didn't see this as limited to essentially
>> programmable routing and forwarding. If indeed the group targets the 
>> intersection of computing and communication, as
>> Subject: RE: [Coin] 答复: Agenda for today Please see in line 
>> below.
>>
>>
>>
>> To: Dirk Trossen <[email-masked]>; Marie-Jose 
>> Montpetit <[email-masked]>; [email-masked]
>> discussed these in our bi-weekly co-chair meeting,
>> and the response below (with [JEM]) reflects what we three think. Of 
>> course, it is how this GROUP feel and think that
>> 1.      Item 1 mentions the term ‘network functions’ as the 
>> scope of research. Is this limitation to ‘network function’
>> intended?
>> 2.      As mentioned in the call, item 2 (use cases) is a 
>> method useful not just for requirements analysis (which is
>> need to clarify two levels: networks and applications
>> above. We are addressing different sectors of networks, mainly three 
>> now: DCN, industrial networks and Edge(with Cloud
>> continuum). And there are different applications related to these 
>> three sectors, such as video streaming, immersive
>> AR/VR, autonomous/connected vehicles, industrial IoT.  We need to 
>> take care of the relationship between network sectors
>> and applications. One potential and ambitious objective is to explore 
>> the common architecture or abstraction for these
>> three, but an even less ambitious reason to address all three in this 
>> research group is that these sectors can learn
>> from each other. E.g. the metro network connecting edges has the 
>> similarity with DCN connecting servers(e.g how to
>> better convey the distributed computing system), while the experience 
>> in in-network control from smart factory may be
>> smart city. It is up to the group to decide based on
>> their interest if we address all these three or focus some of them. 
>> But to us three, all three are related and
>> interesting.
>> networks from in-network functionality” which confuses me a
>> bit in terms of ‘these networks’ as a focus here. Item 3 does 
>> recognize OTOH that we consider placement of compute ‘even
>> in end devices’. My main concern goes back to the feedback I 
>> received in the past from people who see ‘the network’
>> ending at the last link to the end device. If we see a continuum of 
>> providing services across devices that include end
>> devices as well as ‘in-network resources’ then the benefits are 
>> not limited to ‘the network’ only. I suggest simply
>> 4.      I understand item 4 having arisen from the interactions 
>> with the transport area but I wonder why we do not
>> include ‘routing’ into the list here, unless we assume 
>> ‘transport’ does include ‘routing’. On the other hand, item 3
>> includes ‘new protocol designs’ so it seems that the unique point 
>> about item 4 is in fact the security and privacy part
>> so maybe rewording item 4 to “research on new privacy and security 
>> mechanisms required to enable in-network compute”
>> would be best?
>> to item3 can resolve the ambiguousness. Then the item 3
>> may looks like: “Research on novel architectures, data-plane 
>> abstractions and new networking/transport protocols designs
>> to…” The reason behind current text:  networking is layer-2/3, 
>> transport is layer-4, so the current item3 is emphasize
>> the layer-2/3 as the data plane in the switches and routers, while 
>> transport are at the host side. But Dirk is right, it
>> network device? An SDN or P4 switch? Or networked
>> laptop? Or my mobile device? Or all of it? Throughout the charter 
>> text, we talk about programmability for ‘devices’,
>> ‘switches’ as well as ‘networks’. Maybe if we answer the 
>> question for ‘device’, we can provide good answers to the
>> others?
>> switch, a router with Network Processor Units(NPUs) which
>> is typically also programmable but not as open as a P4 switch, a 
>> soft-router/switch with X86 or ARM in the context of
>> [HS] Minor point.  Please 
>> see https://github.com/hesingh/p4-info which lists NPU, FPGA, and 
>> generic computer as all
>> device”) , but
>> physically a network node and a host may be implemented in the same 
>> real hardware: these mobile phones/laptops can
>> function as “network nodes” besides “hosts”. This is not what 
>> we try to emphasize at this stage, but it is possible.
>> interface is a host.  I would elide all mention of
>> host, mobile device, laptop, etc.  Just stick to “computing in 
>> network”.  The network may be connecting a laptop, cell
>> -

---

From: <[email-masked]>
Date: Thu, 20 Jun 2019 13:43:34 -0400

+1.

I am new to COIN.  Soon as I heard what its acronym stands for, I only thought of computing anywhere in the flight path of a packet, not the packet’s sender and receiver.  An example is virus detection in the network before virus-infected packets reach a host.  Anyway, I defer to others until I am done reading all the docs produced by the COIN WG. 

Hemant  

From: Coin <[email-masked]> On Behalf Of David R. Oran
Sent: Thursday, June 20, 2019 1:28 PM
To: [email-masked]
Cc: Dirk Trossen <[email-masked]>; Hejianfei <[email-masked]>; Marie-Jose Montpetit <[email-masked]>; [email-masked]; [email-masked]; Dirk Kutscher <[email-masked]>
Subject: Re: [Coin] 答复: Agenda for today

On 20 Jun 2019, at 11:23,  <mailto:[email-masked]> [email-masked] wrote:

Hi Dirk,

I’m not entirely sure I agree with this. The unstated implication (or at least the implication I derive) is that there is an administrative separation between the entire that operates and runs application on hosts, and the entity that operates and the network and decides what computations run and where. Therefore if one does not start from this mental model:

*	It does not seem fundamental to me from where the function execution is triggered. 

*	As an example from a different era and somewhat different problem domain, consider Packetcable Multimedia, which is a QoS resource management protocol for CMTSs based on COPS. In this case an application running on a host sends PCMM function calls to a execution box “inside” the network, which in turn uses COPS to install QoS state in the CMTS. Which part of this is “inside the network”? If you say it’s just the two ends of COPS, then the function of installing QoS state is executed “inside” and the “trigger” is also inside, as the function that derives the COPS stuff from the PCMM calls, is under control of the cable operator and hence “inside” the network. If, on the other hand you start with the PCMM request as the “trigger”, the function execution is invoked from a host “outside” the network.
*	Conversely, RICE (or for that matter NFN) method invocation could arrive at an ICN forwarder which has an associated internal module capable of executing the function and returning results. In this case the “trigger” is the original call, possibly from a host “outside” the network being forwarded through ICN routers, and the “execution” is just another piece of method/function code on the router/forwarder and therefore “inside” the network. 

*	Late versus early binding also seems somewhat orthogonal. One can do late binding (as my second example above shows), or quite possibly early binding by setting up a full computation graph statically at the first invocation. In fact, you might even do it at compile time if you have a network with stable and predictable topological and resource structure, as one might for example in a toroidal mesh of TPUs in a Google data center that are all resources “inside” the data center network and not the application hosts executing the ML application.
*	I imagine that chaining (at least the simple forms like SFC or NFV) can’t cross administrative boundaries easily and hence might be constrained to be entirely “inside” the network, but why start from this limitation?

For me, the more important characteristics of “in network” computing are things like:

*	computations are done on devices placed topologically at interior nodes of the network graph, as opposed only at the edges of the graph.
*	The security perimeter is around the computation instance, not a topological boundary of the connectivity graph, hence one can keep an entire distributed computation inside one security perimeter and not have to either leak data or share keys with third parties.
*	Any state kept and/or mutated by the computation is considered application state, not state related to the operation of the basic forwarding and topology maintenance function of the network devices.

What do people think? which general way of thinking about in-network computing resonates better?

DaveO.

best, cft

Hi,

IMO, one of the COIN objectives should be to propose/define new categories for functional composition that help to us to describe
the relevant COIN scenarios.

What abstraction could be useful to describe these two use cases in one framework? (And is there any value in trying to find them?)
IMO these are good challenges for COIN.

Cheers,
Dirk

mjm

Hemant

Best

Dirk

____________________________________________________________________________________________________________________________________
From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> >
Sent: Wednesday, June 19, 2019 1:02:30 PM
To: 'Hejianfei (Jeffrey)'; Dirk Trossen; 'Marie-Jose Montpetit'; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Coin] 答复: Agenda for today Please see in line below.

From: Coin <[email-masked] <mailto:[email-masked]> > On Behalf Of Hejianfei (Jeffrey)
Sent: Tuesday, June 18, 2019 10:40 PM
To: Dirk Trossen <[email-masked] <mailto:[email-masked]> >; Marie-Jose Montpetit <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: [Coin] 答复: Agenda for today

Hi Dirk,

Marie-Jose, all,

1.      Item 1 mentions the term ‘network functions’ as the scope of research. Is this limitation to ‘network function’
[JEM] After all, we are talking about “in-network” functions. “Network function” is still ok, only if we don’t limit “

[HS] Minor point.  Please see  <https://github.com/hesingh/p4-info> https://github.com/hesingh/p4-info which lists NPU, FPGA, and generic computer as all
being programmable using P4.

Hemant

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

-

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

---

From: [email-masked]
Date: Thu, 20 Jun 2019 14:02:37 -0700 (PDT)

Hi Dave, thanks for your answer and the debate

Re your three characteristics of COIN:
1 functions execute on "inside" nodes
2 (virtual?) secure execution spaces
3 separation of app state vs netops state

I like the two latter abstractions, it's about virtualization really. 
However, I think that these are potential COIN services or methods (like 
RPC), but not defining COIN. In fact, we have items 2 and 3 today with 
the standard layering, just that they do not have incarnations "inside 
the net". So your characterization rests on that item 1, which is back 
to the host or netdevice discussion that I wanted to get rid of. My 
view: I think we have seen the MIDCOM discussion and because the ICMP 
echo function is answered from within the net does not make it COIN, 
even if you wrap in a security perimeter.

Regarding the comment on 'trigger' and your two cases of COPS and RPC 
(good to discuss with examples): Granted, often the very initial trigger 
is from meat space, some human pushing a button, and then a call is made 
into the net. This is not my point. Instead, once that trigger is pulled 
and the event lands inside the net, in-network functions (unknown at 
spec-time) take over control, the control locus moves into the net: The 
triggered function can decide how to react on that event (choice), can 
consult other functions --which can also be outside the net, I should 
note-- and resume (chaining). If control remains outside the net or is 
locked down at COIN spec time - what would be new? I would be happy if 
you see better ways to express this, without reference to 'trigger'.

I'm not familiar with COPS but from what I get from your description is 
that there is no choice, only hardwired (network) functionality, in the 
same way that L2 switches have an IP address, it seems to be classic 
"over-the-net" communication even if it has side effect on net state. 
RPC is a mechanism that can be used over the net as well as from within, 
so it is not characteristic of COIN.

"Late binding": probably "after-spec-time" would have been better in 
order to express that potentially arbitrary code can be thrown at a 
COIN-enabled net. Your compile case and early binding makes sense, COIN 
doesn't have to be "interpreted".

One way to identify new ideas is to probe for their abuse potential, 
which is why I went for the in-net control characteristics: COIN is on 
the right track if it will be faced with in-network RPC storms that can 
only be broken by unplugging all attached devices, or prevented through 
a special COIN resource mgmt framework or compilation guarantees.

> computing resonates better?

Perhaps there are even more ways of thinking COIN than "interior node" 
vs "in-net control"?

thanks, cft

On Thu, 20 Jun 2019, David R. Oran wrote:

>       agreeing on many points, and yes to finding an abstraction. Here is
>       a suggestion (which could help to sharpen the charter?) that
>       focuses onthe control locus instead of hosts, interfaces or tools:
>
> I’m not entirely sure I agree with this. The unstated implication (or at least
> the implication I derive) is that there is an administrative separation between
> the entire that operates and runs application on hosts, and the entity that
> operates and the network and decides what computations run and where. Therefore
> if one does not start from this mental model:
>
>  * 
>
>     It does not seem fundamental to me from where the function execution is
>     triggered.
>
>      +  As an example from a different era and somewhat different problem
>         management protocol for CMTSs based on COPS. In this case an
>         application running on a host sends PCMM function calls to a execution
>         box “inside” the network, which in turn uses COPS to install QoS state
>         state is executed “inside” and the “trigger” is also inside, as the
>         function that derives the COPS stuff from the PCMM calls, is under
>      +  Conversely, RICE (or for that matter NFN) method invocation could
>         the “trigger” is the original call, possibly from a host “outside” the
>         network being forwarded through ICN routers, and the “execution” is
>         just another piece of method/function code on the router/forwarder and
>         therefore “inside” the network.
>  * 
>
>     Late versus early binding also seems somewhat orthogonal. One can do late
>     binding (as my second example above shows), or quite possibly early binding
>     by setting up a full computation graph statically at the first invocation.
>     In fact, you might even do it at compile time if you have a network with
>     stable and predictable topological and resource structure, as one might for
>     example in a toroidal mesh of TPUs in a Google data center that are all
>     resources “inside” the data center network and not the application hosts
>     executing the ML application.
>
>  * 
>
>     I imagine that chaining (at least the simple forms like SFC or NFV) can’t
>     cross administrative boundaries easily and hence might be constrained to be
>     entirely “inside” the network, but why start from this limitation?
> 
>  * 
>     computations are done on devices placed topologically at interior nodes of
>     the network graph, as opposed only at the edges of the graph.
>
>  * 
>
>     The security perimeter is around the computation instance, not a
>     entire distributed computation inside one security perimeter and not have
>     to either leak data or share keys with third parties.
>
>  * 
>
>     Any state kept and/or mutated by the computation is considered application
>     state, not state related to the operation of the basic forwarding and
>     topology maintenance function of the network devices.
>
>             More generally, “computing in the network” has the
>             potential to open new perspectives on the relationship
>             of “hosts”, “network” as
>             I don’t think it’s helpful if we constrain ourselves to
>             1990s textbook categories (such as “L3”, “L4”). These
>             categories were not
>             IMO, one of the COIN objectives should be to
>             propose/define new categories for functional
>             composition that help to us to describe
>             Just as an example, if we consider a set of distributed
>             data sources and processing/aggregation functions a
>             COIN use case, what
>             An example at the other end of the spectrum could be a
>             set of programmable network nodes that get programmed
>             by some SDN controller
>             What abstraction could be useful to describe these two
>             use cases in one framework? (And is there any value in
>             trying to find them?)
>             And, in that context, SDN frameworks, control protocols
>             (such as OpenFlow), programming languages (such as P4)
>             are IMO just tools
>             that could be useful in one or the other scenario —
>             just like execution environments are tools — they
>             should not define the concepts
>             Summarizing, I agree to DirkT that COIN should go
>             beyond programmable routing and forwarding, and when
>             doing that, we have to
>             (Chair hat off):I actually agree with Dirk. I would not
>             want to limit computing to the routing and forwarding.
>             We have
>             I was under the impression the RG would target
>             computing in networks (COIN). I didn't see this as
>             limited to essentially
>             programmable routing and forwarding. If indeed the
>             group targets the intersection of computing and
>             communication, as
>             expressed early in the charter, the removal of any
>             mentioning of host is rather questionable to me.
>
>             Best
>
>             Dirk
> 
> ______________________________________________________________________________
>             ______________________________________________________
>             To: Dirk Trossen <[email-masked]>;
>             Marie-Jose Montpetit
>             <[email-masked]>; [email-masked]
>             Thank you for your comments for the charter.
>             Marie-Jose, Eve and me discussed these in our bi-weekly
>             co-chair meeting,
>             and the response below (with [JEM]) reflects what we
>             three think. Of course, it is how this GROUP feel and
>             think that
>             1.      Item 1 mentions the term ‘network functions’ as
>             the scope of research. Is this limitation to ‘network
>             function’
>             intended?
>             [JEM] After all, we are talking about “in-network”
>             functions. “Network function” is still ok, only if we
>             don’t limit “
>             2.      As mentioned in the call, item 2 (use cases) is
>             a method useful not just for requirements analysis
>             (which is
>             solution oriented) but also for scoping of work, i.e.,
>             what is in scope of the RG and what is not
>             [JEM] If we discuss how use cases are related to the
>             scope, we may need to clarify two levels: networks and
>             applications
>             above. We are addressing different sectors of networks,
>             mainly three now: DCN, industrial networks and
>             Edge(with Cloud
>             continuum). And there are different applications
>             related to these three sectors, such as video
>             streaming, immersive
>             AR/VR, autonomous/connected vehicles, industrial IoT.
>             We need to take care of the relationship between
>             network sectors
>             and applications. One potential and ambitious objective
>             is to explore the common architecture or abstraction
>             for these
>             three, but an even less ambitious reason to address all
>             three in this research group is that these sectors can
>             learn
>             from each other. E.g. the metro network connecting
>             edges has the similarity with DCN connecting
>             servers(e.g how to
>             better convey the distributed computing system), while
>             the experience in in-network control from smart factory
>             may be
>             inspiring for the mission critical services in edge
>             networking in smart city. It is up to the group to
>             decide based on
>             their interest if we address all these three or focus
>             some of them. But to us three, all three are related
>             and
>             interesting.
>             3.      Item 2 states “Identify potential benefits to
>             these networks from in-network functionality” which
>             confuses me a
>             bit in terms of ‘these networks’ as a focus here. Item
>             3 does recognize OTOH that we consider placement of
>             compute ‘even
>             in end devices’. My main concern goes back to the
>             feedback I received in the past from people who see
>             ‘the network’
>             ending at the last link to the end device. If we see a
>             continuum of providing services across devices that
>             include end
>             devices as well as ‘in-network resources’ then the
>             benefits are not limited to ‘the network’ only. I
>             suggest simply
>             4.      I understand item 4 having arisen from the
>             interactions with the transport area but I wonder why
>             we do not
>             includes ‘new protocol designs’ so it seems that the
>             unique point about item 4 is in fact the security and
>             privacy part
>             so maybe rewording item 4 to “research on new privacy
>             and security mechanisms required to enable in-network
>             compute”
>             would be best?
>             [JEM] Yes,  we agree that  probably moving “transport
>             protocol” to item3 can resolve the ambiguousness. Then
>             the item 3
>             may looks like: “Research on novel architectures,
>             data-plane abstractions and new networking/transport
>             protocols designs
>             to…” The reason behind current text:  networking is
>             layer-2/3, transport is layer-4, so the current item3
>             is emphasize
>             the layer-2/3 as the data plane in the switches and
>             routers, while transport are at the host side. But Dirk
>             is right, it
>             Last question for me to understand the scope: what is a
>             programmable network device? An SDN or P4 switch? Or
>             networked
>             laptop? Or my mobile device? Or all of it? Throughout
>             the charter text, we talk about programmability for
>             ‘devices’,
>             ‘switches’ as well as ‘networks’. Maybe if we answer
>             the question for ‘device’, we can provide good answers
>             to the
>             others?
>             [JEM] A programmable “network device” can be:  a
>             programmable switch, a router with Network Processor
>             Units(NPUs) which
>             is typically also programmable but not as open as a P4
>             switch, a soft-router/switch with X86 or ARM in the
>             context of
>             see https://github.com/hesingh/p4-info which lists NPU,
>             FPGA, and generic computer as all
>             physically a network node and a host may be implemented
>             in the same real hardware: these mobile phones/laptops
>             can
>             function as “network nodes” besides “hosts”. This is
>             not what we try to emphasize at this stage, but it is
>             possible.
>             [HS] When an interface on a router acquires an IP/IPv6
>             address, the interface is a host.  I would elide all
>             mention of
>             host, mobile device, laptop, etc.  Just stick to
>             “computing in network”.  The network may be connecting
>             a laptop, cell

---

From: <[email-masked]>
Date: Thu, 20 Jun 2019 17:07:07 -0400

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Thursday, June 20, 2019 5:03 PM
To: David R. Oran <[email-masked]>
Cc: Dirk Trossen <[email-masked]>; Hejianfei <[email-masked]>; Marie-Jose Montpetit <[email-masked]>; [email-masked]; [email-masked]; Dirk Kutscher <[email-masked]>
Subject: Re: [Coin] 答复: Agenda for today

> I'm not familiar with COPS but from what I get from your description is that there is no choice, 

COPS is covered in a RFC: https://tools.ietf.org/html/rfc2748

Hemant