[Coin] COINRG minutes - IETF 116

Eve Schooler <eve.schooler@gmail.com> Sat, 15 April 2023 00:45 UTC

Return-Path: <eve.schooler@gmail.com>
X-Original-To: coin@ietfa.amsl.com
Delivered-To: coin@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782FBC151540 for <coin@ietfa.amsl.com>; Fri, 14 Apr 2023 17:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0oYl2PTUQ3E for <coin@ietfa.amsl.com>; Fri, 14 Apr 2023 17:44:59 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F126FC14CE5F for <coin@irtf.org>; Fri, 14 Apr 2023 17:44:58 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id h8so4795815ljf.3 for <coin@irtf.org>; Fri, 14 Apr 2023 17:44:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681519495; x=1684111495; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=tyEZULZQ1XAwbPgOBNj3um0y0f1LMZSbn+039ZJkI0g=; b=EC0IIvbPpo93Rlb9BX85MUmdjePJ1uHb6YkReHd6JWMbGdu0Rdpc/AKDba3YQ8S8sE y9UUf3qwAAC2TkIukoS9Oxp2Q5bOfdVnDYcOYEN1UXlK/nP1aBRaC9mafuz58Hb7aKUq nR/MRhjw9GghGk01Ou3m0XLG1Ge34qqakl1jKH/o6UwEfr8UpOLEn6CixP2WxYYVf3q6 o4bmjBJLxJB8XkJ7MZgWbHn+7lv78yZFiPmpo8e+ZANWx/BVCNhtJqO3SHy3CeV4c1O/ fsGG6NA5vtbmHrNlqa9pwvNeWyyMN1B30jgHjQpxBXmhR5cGuuAv79N2Yk8FHqjgRgbD 6qNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681519495; x=1684111495; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=tyEZULZQ1XAwbPgOBNj3um0y0f1LMZSbn+039ZJkI0g=; b=iKX3XUPEG8EZI/F8wtKjXp3vZzSE56pjIsclS7cXvoQnEc2LXQsgaLxt0OUFvSMJtz T0Gxzv8oWpYh9WdfAfk8Keny/VLi3sG8KaL/G4+JA56+5URkKIVNY0zqR8d3/J1l5NB3 VfN1Akk8VLnPXTl36eyqXSm2UBmY/UfZAktKEwq005lp8hGuxcpPApR3NWAGbDiSDk4m oGuFdXdHIkhIkQB8NyK216u2YbB/dUhLlX1445BUH5bBGymc4bcUtiAxr16p1SCW9JTt LlsQ7SOSkSI/eUSJmDEVH/B+Jx/kjLbLuJhwTmP9zLDjlX0GWHlw3IEf6KPQAqSumd4P xYaw==
X-Gm-Message-State: AAQBX9edi/6HZ3gL5OJGcV/cxrWHPjO+kJ91Mf+3zClqdSFhH7ENFArK ephyCY3V7YhfV8a3s+JqyYghAiBe64cai9IT+Sw60co76Q==
X-Google-Smtp-Source: AKy350Z2Dd2pdbbmwqVvQV7ZJlbDFHe2EQW03XqpPDg8EpWUNTPWrv0KN6DJDSc//WbQoYtRIpe0x6xovQFhb3qh7WY=
X-Received: by 2002:a05:651c:545:b0:2a7:ad00:67ca with SMTP id q5-20020a05651c054500b002a7ad0067camr3354932ljp.1.1681519494642; Fri, 14 Apr 2023 17:44:54 -0700 (PDT)
MIME-Version: 1.0
From: Eve Schooler <eve.schooler@gmail.com>
Date: Fri, 14 Apr 2023 17:44:43 -0700
Message-ID: <CADbu6ZrmO6HU+HxV-KK4zTsQskC6i+VjbmTVT=fODrMuMgLYPQ@mail.gmail.com>
To: coin@irtf.org
Cc: coinrg-chairs <coinrg-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000293ee205f955447d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/GDr5X_HD5Azs_IoZNFRNyZ6wZ8s>
Subject: [Coin] COINRG minutes - IETF 116
X-BeenThere: coin@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "COIN: Computing in the Network" <coin.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/coin>, <mailto:coin-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/coin/>
List-Post: <mailto:coin@irtf.org>
List-Help: <mailto:coin-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/coin>, <mailto:coin-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Apr 2023 00:45:02 -0000

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 <jefhe@foxmail.com>
  Eve Schooler <eve.schooler@gmail.com>
  Marie-Jose Montpetit <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)

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