# COIN RG Meeting at IETF 116   {#coin-rg-meeting-at-ietf-116}

Date: Monday, 27 March, 2023 -- Session I  
Time: 9:30am - 11:30am UTC (Tokyo) -- 120 mins

Chairs: J/E/M  
 Jianfei (Jeffrey) He [jefhe@foxmail.com](mailto:jefhe@foxmail.com)  
 Eve Schooler [eve.schooler@gmail.com](mailto:eve.schooler@gmail.com)  
 Marie-Jose Montpetit
[marie@mjmontpetit.com](mailto:marie@mjmontpetit.com)

Join via Meetecho:
https://meetecho.ietf.org/conference/?group=coinrg&short=coinrg&item=1  
Materials: https://datatracker.ietf.org/meeting/116/session/coinrg  
Shared Notetaking: https://notes.ietf.org/notes-ietf-116-coinrg  
Chat room: https://zulip.ietf.org/#narrow/stream/coinrg

Available post session:  
Recording: http://www.meetecho.com/ietf116/recordings#COINRG

Notetakers: Eve Schooler, Jianfei (Jeffrey) He

# 1. Chair Updates (J/E/M) (15 mins)   {#1-chair-updates-jem-15-mins}

Encourage authors of expired docs to consider renewing and progressing
docs for maturation and possibly for working group adoption.

Had hoped to lead a discussion on end-to-end research in the context of
COIN, but Ike Kunze unfortunately is out sick so can't participant in
this meeting. Therefore this topic will be addressed in the mailing list
or a future meeting.

# 2. New Drafts (10 mins each)   {#2-new-drafts-10-mins-each}

## 1) An Evolution of Cooperating Layered Architecture for SDN (CLAS) for Compute and Data Awareness (Luis M. Contreras, Telefónica)   {#1-an-evolution-of-cooperating-layered-architecture-for-sdn-clas-for-compute-and-data-awareness-luis-m-contreras-telefónica}

https://datatracker.ietf.org/doc/draft-contreras-coinrg-clas-evolution/ 

CLAS idea was adopted in SDN RG, then moved into ISE (independent stream
editor) after RG closure, eventually being released as RFC 8597.

New drivers pushing toward CLAS evolution:  
interworking of virtualized and physical service functions, as well as
network operations are introducing AI and ML at the basis of closed loop
automation.

Potential research directions:

*   Identify use cases that can help to better define hte architecture
    capabilities.
*   Investigate how to fit with the legacy architecture
*   Inter-domain APIs between same/different strata
*   Explore intent-based APIs/approaches for learning plane
*   Data models (ontologies) for the exchange and aggregation of data
    across planes

Marie-Jose Montpetit: When you say that a next step is to set the scope
of the draft to align with COINRG, yet in slide with the architecture
showing SDN, it appears very traditional. Where do you see COIN fitting
in, as it is not clear where/how compute actually functions?   
Luis: Telefonica sees orchestration and service functions requiring
connectivity and integration to support e2e delivery.  
Marie-Jose Montpetit: would be helpful to show how the compute plane
actually works or drives the stratum and their interactions. And to show
how the scope is clearer.  
Dave Oran: Based on the architectural drawing, the implication is that
there is a hierarchical relationship between the connectivity and the
compute, but driven by connectivity. Is that merely an artifact of the
drawing? Instead, they should be at the same level.  
Luis: Yes.  
Marie-Jose: Great to see that traditional operators are taking notice of
COIN related concerns.

## 2) A Generic COIN framework in controlled environments (Kehan Yao, China Mobile)   {#2-a-generic-coin-framework-in-controlled-environments-kehan-yao-china-mobile}

Draft:
https://datatracker.ietf.org/doc/draft-yao-coinrg-generic-framework/

View COIN as a means of offloading application-specific function to
network elements, to speed up applications.  
How to make the app development easier.  
Increase generality and promote standardization of COIN.

Marie-Jose: Standardization is not our role as a research group. Suggest
to look at work that has gone on since the early papers cited in the
presentation. Am aware of the proposal to the ITU to standardize
COIN-related.   
Kehan: Presenting the work here to promote share ideas.  
Dirk Kutcher: Raises some interesting ideas. Are these considerations
based on research or prototyping experience, or just an architectural
thinking at the moment?   
Kehan: Based on actual research. I didn't mention all the coauthors,
some of them published papers in major conferences. There are references
in the draft.  
Dirk Kutscher: Interesting work on distributed computing, such as
decomposition framework. Do think that this is an interesting topic for
COIN. Your title of the document is "controlled enviroments". Would the
requirements change if focusing on general technical requirements for
distributed computing versus in controlled environments?  
Kehan: Controlled enviroments are initial, easy for deployment. The
framework may extend.  
Colin Perkins: With IRTF chair hat on, would echo Marie Jose's comments.
However as an individual, do think there is interesting work here.
Appreciate how to systematize things. Can you say more on how do you
compare your operations to others (e.g., in-net compute languages such
as P4)? Why do you chose these primitives compared to others choices,
e.g. defined by P4?   
Kehan: These primitives should be common, standardized (maybe not here),
implemented by different network vendors. These are summarized from the
research.  
Colin: Going forward, focus on the research challenges. How from a
research point of view, this approach compares and is better than others
in COIN.  
Jianfei He: Would seem there is a contradiction between
application-specific and those widely used by many applications. An
ambitious objective. How to justify the primitives that are both
necessary and sufficient for future applications. Think it is
interesting research if you can justify it more deeply.  
Colin: would like to see those discussions happening in this research
group.  
Jianfei: At this stage, need more solid research to justify further and
to foster debate.  
Dirk Kutscher: this work in principle is important research topic. It's
important to learn from running code, real experimentation, lessons
learned from really developing the technologies. Hard otherwise to
assess the merit of the drafts and proposals just by looking at slides
and informational material. If you can move the group in this direction
that would be great.  
Marie-Jose: Related to this framework: Work done by Noa Zilberman for
example and those in p4.org, federated learning. Have had discussions
here that we want to expand the primitives beyond just those that focus
on data in packet headers, and want to move toward inference on
meta-data beyond headers. Thus, want to move beyond the current
primitives and add to the richness of the field.

## 3) Research problems around the security in COIN (Pascal Urien, Telecom Paris)   {#3-research-problems-around-the-security-in-coin-pascal-urien-telecom-paris}

Draft: https://datatracker.ietf.org/doc/draft-urien-coin-sec/

Colin: What's your considerations in an internet scale instead of a
single domain?  
A: for a single domain, multi tenant inferdace is required. In my
research, physical entity, logical entity for multiple participants can
work together. Mutli tenant means multiple source of trust.  
Dave Oran: What is the relevance of Security to COIN?  
Erik Nordmark: it may be that the difference is about who has physical
control over the boxes. In distributed systems, may happen
automatically. Here, it may be that one has to be more explicit.  
Jainfei He: Interesting research problem with security in COIN beyond
key management.  
Pascal: Must be distributed and collaborative here, which differentiates
it from typical security. Complicated by multi-tenancy.  
Marie-jose: In the next version, would be interesting to address the
issues raised here, e.g., differences with standard key management
systems, discovery in multi-tenant and multi-trust domain, etc.

## 4) Data-driven Coordination of Network Devices in Computing in the Network (Zongpeng Du, China Mobile)   {#4-data-driven-coordination-of-network-devices-in-computing-in-the-network-zongpeng-du-china-mobile}

Draft:
https://datatracker.ietf.org/doc/draft-du-coinrg-coordination-on-data-plane-00

In contrast to SRv6, strict network programming, consider the case where
a function MAY take place in a node.  
Thus considered a Loose network programming paradigm.  
And a coordination mechanism proposed as needed (e.g., HBH extension
header of IPv6 encapsulation): a bitmask to indicate the functions/tasks
needed to be done in the network.  
DDoS might be an example of such an application for this functionality.

Colin: invoking an in-net function for a loose spec of where to do it is
reasonable. Have seen on a number of proposals in the past. Since this
is a research group, can you compare with other approaches? Would be
interesting to see the research results.  
Zongpeng: Early idea, so open to ideas.  
Marie-Jose: Where do you feel is the most promising research? How is it
different from the SoTA and going beyond it? E.g., distributed container
architecture - how this is the same and different from current research.

# 3. Internet-Drafts (10 mins each)   {#3-internet-drafts-10-mins-each}

## 1) Use case analysis (Ike Kunze, RWTH Aachen University)   {#1-use-case-analysis-ike-kunze-rwth-aachen-university}

Draft: https://datatracker.ietf.org/doc/draft-irtf-coinrg-use-cases/

Ike and Dirk have done an incredible job. Great team effort.  
Started this at the beginning of the research group. COIN an enabler of
certain applications. Goal is to drive use-case driven requirements and
how to make them into a decent structure and a common way of presenting
them. Many current apps are suffering from Cloud or thin-client
architectures. Defined capabilities to put in the network. Does raise
some issues of security. Distributed AI, dealing with an incredible
amount of data.

Invite the group to look at the use case draft, as the authors believe
it is ready for RGLC.

## 2) Terminology (Ike Kunze, RWTH Aachen University)   {#2-terminology-ike-kunze-rwth-aachen-university}

Draft:
https://datatracker.ietf.org/doc/draft-irtf-coinrg-coin-terminology/

Had to align on a taxonomy to complete the use cases draft.  
Still encouraging the draft-kutscher-coinrg-dir-02 to be renewed, as it
is presently expired. Would be good to align on terminology.

Questions for the RG and will put to the list:

*   Who can take over managing the doc?
*   Goal for this doc? Living collection of terminology?
*   Scope of this terminology?
*   Changes? Additions? Probably need a whole section on Security and
    other topics.

Note PNDs (Programmable network devices) might be interface cards and
switches, but could go beyond that, using P4 and other languages.

Go beyond the notion of a single provider to multiple providers. Note:
not just processing/computing but also communication. Would also like to
go beyond the monolithic program, and to be able to orchestrate and
federate.   
Goal: Is COIN making the life of a packet and the life of an application
better?

## 3) Use Case Analysis for COIN (Ike Kunze, RWTH Aachen University)   {#3-use-case-analysis-for-coin-ike-kunze-rwth-aachen-university}

Draft:
https://datatracker.ietf.org/doc/draft-irtf-coinrg-use-case-analysis/

Another draft percolating on Use Case Analysis for In-Network Computing.

Purpose: to go beyond descriptions and analyze opportunities, research
questions, and requirements to identify commonalities. Provide general
research directions for COIN.  
Have identified a range of applicability areas: transport, App design,
Data processing, Routing and forwarding, (Industrial) control. Also see
distributed computing frameworks and languages relevant to COIN (beyond
P4). Enabling Technologies for COIN, e.g., from Nvidia, Intel, etc.

Questions for the RG:

*   Who can take over managing the doc? Note, Ike to graduate soon.
*   Who is interested in contributing / doing the analyses?

# 4. RG topics and directions (30 mins)   {#4-rg-topics-and-directions-30-mins}

Recommendations:

*   Graduate Use case draft to RGLC
*   Terminology needs to evolve
*   Analysis is something that needs to be done

Dirk Kutcher: COIN Directions draft.  
One general question: how many docs and of which nature do we want to
push to the RFC editor? In general, good to have high quality output.
For the COIN directions draft we actually are not sure. One purpose is
to steer conversation in the group. Another purpose might be to have
longer relevance. Personal preference is to focus on experimental specs
mostly, and if other important/mature enough architecture or analysis
work then consider publishing as well. Avoid publishing too much
information.

Marie-Jose: would be great to be able to have a foundational draft to
point people to who are just getting into the COIN arena.

Colin: Agree it is good to think about the set of docs this group should
produce and be strategic about what those docs are. The focus as a RG
isn't necessarily on drafts but on understanding. Drafts is one way to
get understanding to organize thoughts. Research papers and collections
of papers and organizing material is also useful. Then can be able to
point people to the research.

Marie-Jose: Have the use cases draft as a meta draft on SoTA.

Colin: Useful to have the material, but encourage the group to be
creative about achieving the goals better.

Eve: Have been wanting for some time to hold an interim where we do a
retrospective of COIN: assess where we've been, where we're going as a
RG, catalog the SoTA (to help those in search of getting oriented and to
identify what are the known gaps/opportunities), and be deliberate to
address the question of how to organize material in this area to best
serve the research community.

Total: 120 minutes