Subject: [Coin] Draft COIN minutes - IETF 109

From: "Schooler, Eve M" <[email-masked]>
Date: Fri, 11 Dec 2020 09:34:54 +0000

Hi All,
Thanks for the many interesting presentations, the probing questions, and of course the discussion/debate during the IETF 109.
Please have a look at the draft minutes; attached, below, or on-line in CodiMD<https://codimd.ietf.org/notes-ietf-109-coinrg>.
All comments/edits welcome (but due before end of day today!).
A big THANK YOU to co-chair Jianfei He (aka Jeffrey) for capturing the minutes.

Best regards,
J/E/M

-----
# COIN RG Meeting at IETF-109
* When: Thursday, Nov 19, 2020 @ 12:00am-14:00 UTC+6 Time - on-line meeting
* Meeting materials: https://datatracker.ietf.org/rg/coinrg/meetings/
* Etherpad: https://codimd.ietf.org/notes-ietf-109-coinrg
* Note taker: Jeffrey He

## Chairs presentation -- 10 minutes
* Administrivia, IPR and scope (Marie-Jose) -- clarification of scope
* Agenda bashing, Internet drafts, Milestones (Jeffrey) -- two drafts were adopted as RG documents, announced on mailing list

## Presentations

### Sharon Barkai - IETF-LISP Virtual Routing for AI at the Edge -- 10 mins
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

### Dirk Kutscher - Directions for Computing in the Network -- 15 mins
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;

### Eve Schooler - Data Discovery and discussion -- 10 mins
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.

### Ike Kunze - Current Work on the Use Cases -- 15 mins
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.

### H. Asai - Separation of Data Path and Data Flow Sublayers in the Transport Layer -- 10 mins
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.

### D. Trossen - Transport Protocol Issues of In-Network Computing Systems -- 10 mins
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;

### D. Trossen - In-Network Computing for App-Centric Micro-Services -- 10 mins
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.

### Ina Fink - Enhancing Security and Privacy with In-Network Computing -- 10 mins
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.

### Philip Eardley - Piccolo Celtic Project -- 10 mins
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.

## Future plans
* Interim meeting in early Feb, with a focus on Research (vs I-Ds) and Scope

---

From: <[email-masked]>
Date: Fri, 11 Dec 2020 10:27:46 -0500

Thanks for sharing the meeting minutes.

Regarding disparate data discovery, why not tie data discovery to node
discovery?  A network interface acquires an IP address using DHCP/DHCPv6 or
IPv6 SLACC.  With a statically assigned IP address one is out of luck.
DHCP/DHCPv5/SLAAC (IPv6 ND RA) include support for options.  An option can
carry what type of data and data format is used by a node whose interface
acquired a layer-3 address.  The option can use a TLV format. 

Best wishes,

Hemant

From: Coin <[email-masked]> On Behalf Of Schooler, Eve M
Sent: Friday, December 11, 2020 4:35 AM
To: [email-masked]
Cc: coinrg-chairs <[email-masked]>
Subject: [Coin] Draft COIN minutes - IETF 109

Hi All, 

Thanks for the many interesting presentations, the probing questions, and of
course the discussion/debate during the IETF 109.

Please have a look at the draft minutes; attached, below, or on-line in
CodiMD <https://codimd.ietf.org/notes-ietf-109-coinrg> .

A big THANK YOU to co-chair Jianfei He (aka Jeffrey) for capturing the
minutes.

Best regards,

J/E/M

-----

* Note taker: Jeffrey He

* Agenda bashing, Internet drafts, Milestones (Jeffrey) -- two drafts were
adopted as RG documents, announced on mailing list

## Presentations

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)

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;

Q(Eve): use cases? 

Q(Ike):

The problem: data are scattered with the compute; how to locate data in an
open standardized way;

Data discovery is fundamental to COIN: all the input\ function\ output are
related to data, and the place of data is important;

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.

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; 

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.

### H. Asai - Separation of Data Path and Data Flow Sublayers in the
Transport Layer -- 10 mins 

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 ? 

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

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.

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.

### D. Trossen - Transport Protocol Issues of In-Network Computing Systems
-- 10 mins

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;

### D. Trossen - In-Network Computing for App-Centric Micro-Services -- 10
mins

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; 

Future plan: move use cases to updated use case draft, complete section 5,
clearly link to other coin drafts; ask for RG adoption.

### Ina Fink - Enhancing Security and Privacy with In-Network Computing --
10 mins

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. 

## Future plans