Draft: datatracker.ietf.org/doc/draft-barkai-lisp-nexagon
Motivation to move AI to the edge: a service level agreement (SLA) often requires sub-sec low latency, heavy load due to large volume of data, regulation.
Examined two production networks: (1) mobility networks of cars in Auto use case (2) cyber case study
Virtual routing methods: IP over UDP, LISP Overlay(topological constraints, this is key for Ai case to reduce the data), signal-free multicast(useful edge reduction to support many channels)
Q(Marie-Jose): how do you want this work to evolve in this group?
A: start from specific use cases, then generalize to a family of problems
Draft: https://datatracker.ietf.org/doc/draft-kutscher-coinrg-dir/
Updates: currently working with app developers on new use cases beyond DC and MEC
ToDo list: terminology clarification; extent of packet processing; discovery; who is the user ; result provenance, mobility;
Applying Internet principles to distributed computing AND employing distributed computing principles for system design
Exploring domain specific solutions, but not point solutions, rather specilaized implementation under coin principles.
Authors’ view: supporting distributed computing by leveraging networking concepts, instead of building better pipes; enhancing TCP with new headers is not promising, security model should be kept in mind;
Future additions: more use cases; taxonomy; not architecture or solution;
Q(Eve): use cases?
A: different class of use cases;
Q(Ike):
A: useful split among drafts
Comment(Phil Eardley): not taxo, but also requirement
A: more about collecting ideas, not mandate the requirements;
Mare-Jose: the common elements;
Draft: datatracker.ietf.org/doc/draft-mcbride-edge-data-discovery-overview
The problem: data are scattered with the compute; how to locate data in an open standardized way;
What is data: statistics, location, health etc; bag of bits; meta-data;
Data discovery is fundamental to COIN: all the input\ function\ output are related to data, and the place of data is important;
Request RG adoption for the first draft of three re data discovery;
Q(Marie-jose): is there other research on this?
A: We are targeting data discovery in more dynamic autonomous situations in contrast to orchestrated containers with pre-configured and/or static data locations
Q(Lars Eggets): a more general comment. Wasting too much time to discuss whether to adopt a RG document. More interesting is what kind of research this group wants to discuss; similarly, it doesn’t matter whether it is in the charter if people want to discuss it! We should focus on more on the technical content and it would be more beneficial and lead to more Q&A.
A(Marie-Jose): Although we are dominated by drafts this meeting, we will target more research presentations in the interim meeting.
Q(Dirk Trossen): I wonder about the RG relevance (not RG adoption); data is relevant to compute, but how about the “in network” part: how the “network” can help in this problem.
Draft: tools.ietf.org/html/draft-kunze-coin-industrial-use-cases-02
open up for other use cases beyond intrustrial one.
Change the structure of the content;
use this document to collect the use cases in this central place, then point to other documents for the details;
use similar structure to describe different use cases: motivation, definition and requirements, realization and research questions;
taxonomy to classify the use cases and find common building blocks;
welcome contributions with additional use cases;
Q(Dirk Trossen): Besides the use cases, taxonomy is also important and requires more contribution; emphasize not only the “computing” but also the “in network” part. Researchers from UCL may contribute on the use case.
Marie-Jose: more than happy to help to integrate my draft into this document.
Draft: tools.ietf.org/html/draft-asai-tsvwg-transport-review-00
New layering architecture for distributed computing.
The network is getting smarter with QoS, middlebox, new distributed computing paradigms (pub/sub, edge computing, in network computing).
Idea: separate transport layer into two sublayers: data path (stateless or per path states) and data flow (per flow states).
Simple case for stateful per packet in network computing: the waypoint have policy to route the packet so is stateful, the in network computing nodes don’t have state, just apply a program to packets.
Stack: data flow is end to end without in network computing nodes, data path have them as hops.
More complex case: per flow in network computing; computing(such as aggregation) on packets from different flows; must be awre of flows; implement data flow protocols
Q(Dirk Kustcher): if computing happens on the payload, what is the security model for data flow ?
A: security function is in the data flow layer
Q(??): if there is computing at the middle of data flow layer, what is the expectation from end to end application layer? not only security, but also the correctness issue?
A: application layer should take care of the service level integrity and functionality
Q(??) the application should at least be aware of the waypoint etc?
A: Yes. This draft focuses on the data plane. The control plane should have to manage waypoint and service. The application layer should control these.
Q(Uma Chunduri): Are there any use cases not processing the payload?
A: no such use case in mind specifically. Maybe encryption. We are thiking, when collecting data from IOT devices, the data needs to be aggregated.
Draft: tools.ietf.org/html/draft-kunze-coinrg-transport-issues
Updates: addressing part, linked to service routing discussing in appcentres draft, amended research questions; flow granularity, added short-term messages, error control to messages while congestion control to endpoint relation; new section on collective communication including short lived multipoint communication; transport features, covering reliability and congestion control.
Future plan: link to other drafts in coin such as use case draft; ask for adoption as rg draft;
Drafts: datatracker.ietf.org/doc/draft-sarathchandra-coin-appcentres
Plan to move use case section to new use cases draft.
Add a few new sub sections; references to 3GPP and edge computing in 5G, service routing critical in L2 enviroment; contraint-based forwarding decisions; extend the contraints more than load/latency, coordinating matching operation in routers for service scheduling;
Collective communication: 1:N/N:1/N:M, short lived, spontaneous formation;
Future plan: move use cases to updated use case draft, complete section 5, clearly link to other coin drafts; ask for RG adoption.
Draft: datatracker.ietf.org/doc/draft-fink-coin-sec-priv
Updates:
In-network vulnerability patches as protection mechanism: define fine grain rules and patches easy to distribute by automatic software updates.
Current research: in network policy enforcement; enhancing incident investigation by efficient network monitoring.
Piccolo: “in network compute for 5G services”, a new project; keen to collaberate with coin group.
Initial direction: joint optimization between network, compute, storage in a reliable and scalable way. Network will provide in network computing in a transparent way like today’s processing packet in a transparent way.
Use cases and services: vision processing, future cars, smart streetlights; and network as a platform.
Vision processing: cameras capture video and video processing is in carriers’ platform for automatic detection;
Automotive use case: do correlation and analysis at the edge more efficiently and faster than in the cloud.