Re: [Coin] 答复: Agenda for today

["Diego R. Lopez" <[e-mail]>]

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: [e-mail]<mailto:[e-mail]>
Tel:         [phone]
Mobile:  [phone]
----------------------------------

On 20/06/2019, 12:11, "Coin on behalf of Dirk Kutscher" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> 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





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
Marie-Jose Montpetit, Ph.D.
[e-mail]<mailto:[e-mail]>
[e-mail]<mailto:[e-mail]>
[phone]
@SocialTVMIT




On Jun 19, 2019, at 11:49 AM, Dirk Trossen <[e-mail]<mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, June 19, 2019 1:02:30 PM
To: 'Hejianfei (Jeffrey)'; Dirk Trossen; 'Marie-Jose Montpetit'; [e-mail]<mailto:[e-mail]>
Subject: RE: [Coin] 答复: Agenda for today

Please see in line below.

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

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:coin-bounces@irtf..org] 代表 Dirk Trossen
发送时间: 2019年6月7日 21:51
收件人: Marie-Jose Montpetit <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
主题: 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.

[HS] Minor point.  Please see 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


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

________________________________

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