# COIN RG Meeting at IETF-108 * Friday, July 31, 2020 @ 14:10am-15:50 UTC Time - on-line meeting Meeting materials: https://datatracker.ietf.org/rg/coinrg/meetings/ Etherpad: https://codimd.ietf.org/notes-ietf-108-coinrg ## Chairs presentation -- 10 minutes * Scribe, administrivia, IPR and agenda bashing (Marie-Jose) * Draft list (Eve) * Milestones (Marie-Jose) - want to begin to address more pointedly, also consider revisions [Note: These notes are a combination of minutes and jabber commentary.] ## Presentations ### Peng Liu - Requirements of Computing in the Network -- 10 mins Draft: https://datatracker.ietf.org/doc/draft-liu-coinrg-requirement/ Last time, the draft categorized the collected requirements into 3 categories: network, computing and management requirements. Since then, added computing resource reservation and OAM, as well as service consistency management.Existing protocols include RSVP/RSVP-TE and PCEP, but they have shortcomings. Therefore proposing a reference methods for distributed resource reservation and centralized resource reservation. [See the slides for good references that inform this work] * Comment (Dirk Kutscher): It seems like the draft is addressing a very specific compute in the network scenario, so it would be worthwhile to spell it out explicity in the draft. It is difficult to discuss the requirements in general. A(Peng Liu); will describe the model in detail in the draft. * Comment (DaveO): One thing I didn't see in the draft was any justification for why this needs to be different from what existing DevOps tools do for deploying application on cloud data centers: they have to deal with placement of computie, allocation of compute resources, allocation of network bandwidth, laying down paths if need be to control latency, ensure fault domain boundaries are considered, etc. A(Peng Liu)If there is any existing DevOps tools do that, it is good to be a reference. I think that we may consider the issue in a wide network, maybe there is any different or worth considering? ### Dirk Kutscher - Directions for Computing in the Network -- 10 mins Draft: https://datatracker.ietf.org/doc/draft-kutscher-coinrg-dir/ Intention of this draft: What does in-network really mean? Some thoughts on computing (e.g., what are interesting units of computation, etc). What could/should COIN look at; suggestions for COINRG? What does "in-network" really mean? There is already a lot of inthe network computing today. Ever increasing. SmartNICs, Web servers, CDNs, cloud platforms, etc. How much research into COIN do they need? One perspective: a joint perspective on networking and computing, not requiring fixed location of data and computation. This draft discusses different types of in-network computing systems, terminology, characterizing COIN, two examples (added a new section on Akka, an actor-based toolkit), research challenges in terms of research fields (added a new research challenge on coordination). Author's view that COIN is... More than just forwarding packets fo nodes that happen to host VMs or processes. Embrace the idea of supporting distributed computing by leveraging networking concepts and mechanisms. Not just building better pipes, but re-designing systems. Suggestion for COIN: catalog the approaches, develop criteria and taxonomy for discussion, identify where possible research is needed. Q(Uma ???): what are the underlay scenarios? what are the striking applications? are you looking at something like active networks? A(Dirk): the draft is describing different approaches. We are more interested in trying to look into distributed computing and see how it could be improved by moving from a pure overlay to a better integrated system with the network. there are other views in this group. Let's be specific on the different approaches, and don't mix them, to develop common concepts? Next steps: chairs to solicit input on the list on adoption of the draft. [14:47:13] I'd answer the question (more directly): how to integrate--ICN as a promising direction [14:47:29] That was precisely the statement I wanted to make: In a so fuzzy environment like in-network compute is so far, a document like the one Dirk presented is a must [14:47:35] I agree with mjm. I think that Dirk's draft is valuable to the group to set a common basis, e.g., regarding the different understandings of COIN. ### Mike McBride - Data Discovery problem statement Draft: https://tools.ietf.org/html/draft-mcbride-data-discovery-problem-statement-00 Decided to create an overall problem statement draft, separate from the original Edge Data Discovery draft. Problem: locating data in a standardized way. Research standardized-based solution where data bases exists throughout the network, where the specfic data objects are located. The location of each data store is likely the first level discovery problem, the details of databases' directory is likely the second level discovery problem. Now three data-discovery-related drafts. Wanted to identify the generic problem in this draft. What's next: if existing protocols will work here. If not, target where a standard protocol might be needed, and if we might need a BoF. Q(Marie-Jose): BoF in IETF or a new RG? a working group on data discovery? A(Mike McBride): Don't know yet. Maybe a working group in IETF. ### Eve Schooler - Edge Data Discovery Draft: https://tools.ietf.org/html/draft-mcbride-edge-data-discovery-overview-04 Anemic references section led to Mike going to investigate related work, which resulted in the Problem statement draft. This is a quick update: did some clarification to the use case section. Both to service function chaining; add a use case "ubiquitous Witness" in dense sensing (e.g cameras). Data are contextually related, so it is able to be processed it collectively. A new, though very modest security section. ### Xavier de Foy - Impact of mobility on discovery in COIN Draft: https://tools.ietf.org/html/draft-defoy-coinrg-mobile-discovery-00 Mobile devices are distributed and dynamic. Challenges on discovery associated with wireless mobility: scalability(keep wireless resource usage low when they change AP); multiple interfaces/networks (determine which network interface or data network to use); service continuity (when a provider or consumer moves to a new location). Starting point for a discussion: consider mobility related requirements among others for data/service discovery in COIN; support centralized and distributed schemes, control plane and data-plane solutions; leverage or extend existing standard solutions to reduce mobile network resource usage for discovery. Q(DaveO) on the jabber link: What is the distinction between in the network and on the network? It would help if you exclude the end point (distributed computing). Q(Marie-Jose): What are the research elements/challenges [that relate to COIN]? A(Xavier): The mobile device use case adds an additional first step to the discovery side, to determine what type of data do you provide to mobile device for it to make decisions (to connect to which AP). Marie-Jose: Does this need a computation? It would be good for each presentation or draft to go back to the COIN charter to re-examine if the problem statement is connected. If there is such an interest in discovering data, independent of computing, maybe it would be worthwhile to create a separate BoF. [15:04:50] Could someone explain to me how these last few presentations are related to the COINRG charter? I thought COINRG was focused on: How programmable network HW that can operate on data is best used in the future Internet. Yet the last few presentations are looking at something completely different. What I think DaveO is saying: it would help if you exclude what the endpoints can do, because that is covered elsewhere, and focus instead on the novel bit around compute in the network and not compute in the traditional places. A(Eve): The relevance to compute-in-the-network is that COIN requires marshalling data from somewhere and figuring out placement of output from the computation somewhere, as well as persistent data. View it as an ancillary problem to COIN. Lars: Our customers lay out pretty carefully what the data pipeline will be at the Edge and in the Core. The idea that data would just float around is kind of weird. Eve: The assumption is that one does NOT come from a containerized world where everything is pre-configured. One counter example is the Ubiquitous Witness use case. For example that a programmable switch may recognize contextually-related data and decide to do a [group] computation on it, which is not pre-configured i/o. [14:50:16] regarding discovery, zmap can scan the entire v4 space for servers listening on a given port in 4.5 minutes :-) [14:51:10] zmap discovers reachable IP addresses, not data [14:51:25] well, the first step of his problem was to discover database servers... [14:52:49] an address does not tell what the box does. but a bigger point is that data can proactively make them noticeable (in a scalable way) [14:54:21] no, it doesn't. but since you need to present some form of authorization to be admitted to see a server's date inventory, you'd need to have a list of credentials anyway that you can then try [14:54:51] data enumeration w/o auth is obviously pretty problematic [14:55:50] in ICN, authenticity is with data, not in addition [14:56:19] it wasn't clear this is meant to only apply to the icn context (at least not to me) [14:56:29] in that case i don't care :-) [14:57:16] then we generalize: data and its authenticity should be bound together [14:57:52] sure. but i was talking about authenticating the entity that wants to enumerate the data [15:02:18] clarification question/comment: we seem to not have a crisp distinction between "in the network" and "on the network". I'm having a bit of difficulty teasing out which is which in this draft, and more generally, does it matter? My intuition is that it does, so not excluding stub endpoints in the absence of some distributed computing elements involved in the communication seems a big expansion of the scope of COINRG Lixia Zhang: Want to answer the in-net or on-net computation question. Fundamentally it seems to me it is a name space question. If computation wants to be in the network, the network has to recognize what that is. If the network only recognizes the network addresses, you cannot see computation. Toerless Eckert: Come up with examples, such as DPI (deep packet inspection), then beat it up what's in and what's out of scope. [15:10:23] I suspect the scope may be a bit wider than the current environment of switching hardware and its limitations, but certainly not a networking-myopic view of the general field of distributed computing [15:12:26] In other words, it may be relevant how you incorporate in-network devices into a general distributed computing framework, but not working to fix/ameliorate the limitations we have in today's distributed computing frameworks, nor reinvent them starting from the limited view of networking people alone. [15:13:55] My own research focus is how to get away from the "inspect traffic as it flies by" bias of current networking folks and really embrace the computation-first architectural view of how to do computing in a topologically and resource-sensitive way. [15:15:05] if one wants to find computed result, that blurs the line with finding data [15:15:26] Another way to say this is "involve smart networking as a capability that people doing distributed computing can use, rather than the reverse". [15:15:42] Dave, agree. the question is how to best orchestrate computation as data flows through networks and pci busses, and through or past cpus, gpus, fpgs, etc. [15:23:27] @lars: how to orchestrate: network has been orchestrating data flows from many places to many other places. What's new needed is to add computation resources into the picture as intermediate stops of data flow -- just a high level thought. [15:24:24] that *just* requires computing components to be on the same namespace with others... [15:26:47] @Lixia and @Lars: there is what is called network slice that is meant to bind together network resources and computing resurces. [15:28:34] @hannu: how is a network slice different from an L2 VPN? [15:30:05] @oran: https://www.gsma.com/futurenetworks/wp-content/uploads/2017/11/GSMA-An-Introduction-to-Network-Slicing.pdf [15:31:37] @Hannu: I know little about slicing so tell me I got it wrong: to me what's needed is integration as "working together", not slicing as co-existing [15:32:59] @hannu - I'll take a look, the last time I conversed with slicing folks (in terms of how to do front-haul and cross-haul to implement a sliced network for a startup I work with) the service delivered looked isomorphic to an L2 VPN to the clients of the slice. [15:33:14] Currently the IETF approach of slicing is more of network management/proviosing type of approach. [15:28:18] Anybody here doing anything with "coded computing"? [15:29:07] @struart - in the sense of FHE? [15:29:49] @steuart: network coding ? [15:36:25] Yes, coded computing is related to network coding, but not the same thing. See https://www.nowpublishers.com/article/Details/CIT-103 [15:37:23] And yes, related to homomorphic encryption. [15:37:48] but only loosely, I think. [15:39:25] @Stuart -- thanks, quite interesting! ### Ike Kunze: Industrial Use cases, Transport issues, Security and privacy -- 10 mins Drafts: https://tools.ietf.org/html/draft-kunze-coin-industrial-use-cases-02 https://tools.ietf.org/html/draft-kunze-coinrg-transport-issues-01 https://tools.ietf.org/html/draft-fink-coin-sec-priv-00 Industrial use cases draft: in-network coordination for data transformation. Strategic placement of network functions (network control, traffic filters, data stream pre-processing or processing, industrial safety). Transport issue draft: a prototype is started, using IPv6 address and segemant routing to find the function and steer the traffic, SCTP as transport protocol(datagram based). SCTP is interesting because we want packets in the network to be self-contained, there are a variety of chunk-types, and packet signing. Security and privacy draft: because of manufacturing context, legacy devices are hard to update and often lack security and privacy mechanism. Looking at manufacturer usage description (MUD) to understand what traffic behavior to anticipate, then apply rules inside the network using p4 switches. Next steps: would like feedback from the group on the drafts. Recommendation: Align the group around common definitions. Often talking about similar things but using different words for them, which makes it difficult to understand each other. [15:40:18] Just to throw a final monkey-wench in…there are three possible approaches to security I can think of here: (a)figure out how to distribute keys to all the possible intermediaries while controlling transitive trust and provenance, (b)depend on FHE, ©provide a shim layer to migrate the things you want the intermediaries to operate on to be outside the encryption envelope. Can anyone think of a fourth (or more) option? [15:44:02] ok, i'll bite: how does aead help? [15:45:49] I confess my total cluelessness: what is AEAD?? [15:46:03] https://en.wikipedia.org/wiki/Authenticated_encryption [15:45:53] trust is less critical if you punt to FHE, and easier to not fall into the complexity hole that MCTLS did if you do the shim approach. [15:47:09] Authenticated Encryption with Associated Data (AEAD) might be an approach to DaveO approach (c) if bundles include some cleartext & some cyphertext. [15:48:39] if you apply aead you need a full mesh of trust, because the computing elements will also need to aead their results [15:49:02] Agree Lars' msg [15:49:03] so it boils down to (a) ### Marie-Jose: Common data layer -- 10 mins What are the elements and hardware, interfaces, defined to allow these decisions and processing to be taken/done both locally and in the cloud, in collaboration. With the network in the middle to allow the communications. data layer functions: filtering, pub/sub, service data function discovery, cache management etc. Match-action functionality that focuses on meta-data, i.e., beyond the packet headers. Use case applicability include vertical agriculture as well as connected vehicles. Next steps: a draft for IETF 109. [15:34:48] Isn’t this just describing an approach that discusses networked computing devices? A(Marie-Jose): yes and no. It also discusses what's inside the networked computing devices, pipelining the functions and decision making. ## Future plans * Start to adopt some drafts, Dirk's and Ike's are the top ones. * Interim meeting in late September for document management, new research topics, yet high priority is scoping and clarification work to do. Host some invited talks, e.g., Noa Zilberman, likely Stanford, Berkeley. Can consider if a Hackathon makes sense. * Security discussion that was on jabber will be taken to the list. * Lixia thinks the fundamental question is how is Trust established in these Edge contexts; where do you put trust? No one is going to pay to get a commercial certificate. * As per the ANRG, don't forget to invite interesting COIN-related security, privacy, trust [as advice from IAB was to better address these topics] * DINRG discussions relevant