Re: [Coin] COINRG minutes - IETF 116

[Eve Schooler <[e-mail]>]

Final minutes attached.
And viewable in the datatracker here:
https://datatracker.ietf.org/doc/minutes-116-coinrg-202303270030/
Thanks all,
J/E/M

On Fri, Apr 14, 2023 at 5:44 PM Eve Schooler <[e-mail]> wrote:

> Hi All,
> Below are draft minutes for the COIN RG meeting at the IETF 116 (can view
> in HedgeDoc at link below).
> All corrections/feedback welcome,
> Many thanks,
> J/E/M
>
> -----
>
> 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 <[e-mail]>
>   Eve Schooler <[e-mail]>
>   Marie-Jose Montpetit <[e-mail]>
>
> 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)
>
> 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)
>
> ## 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)
> 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)
> 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)
> 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)
>
> ## 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)
> 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)
> 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?
>
>
>
> # 5. 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
>