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

Date: Thursday, 9 Nov 2023 -- Session I   
Time: 09:30 - 11:30 CET (Prague) -- 120 mins

Chairs (on-line): 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)  
Delegate (in the room):  
 **Ike Kunze**
[ike.kunze@comsys.rwth-aachen.de](mailto:ike.kunze@comsys.rwth-aachen.de)

Join via Meetecho:   
https://meetings.conf.meetecho.com/ietf118/?session=31732   
Materials:   
https://datatracker.ietf.org/meeting/118/session/coinrg   
Shared Notetaking: https://notes.ietf.org/notes-ietf-118-coinrg   
Chat room: https://zulip.ietf.org/#narrow/stream/coinrg

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

Notetakers: Eve Schooler, Ryo Yanagida, Your name here!

# 1) Chair Update (J/E/M) - 10 mins   {#1-chair-update-jem---10-mins}

*   Notewell
*   Call for Notetakers
*   IRTF Policy reminder
*   Agenda

# 2) Research topics (15 mins each, including 5 mins Q&A)   {#2-research-topics-15-mins-each-including-5-mins-qa}

## 2.1 What is In-Network Computing (INC) in light of and alongside E2E? (Ike Kunze, RWTH Aachen University)   {#21-what-is-in-network-computing-inc-in-light-of-and-alongside-e2e-ike-kunze-rwth-aachen-university}

Colin Perkins: the middle mental model presented seems fuzzier.   
Ike Kunze: Tried to group the statements. Only meant as an inspiration
to think about INC, rather than be definitive.

Ike Kunze: Main questions: What can we make of all the opinions and
views collected? How to make INC work, in light of e2e awareness? What
to do next? Provide input to new discussions. Continue with the
gathering of viewpoints and condense further. Directions draft is in an
ideal position to comprehend the input.

Lixia Zhang: Think this effort to clarify concepts is very important,
otherwise future would be built on unstable ground. What is INC? What
layer? How to understand the Transport layer?  
In the paper is further elaboration of the statement taken from the
abstract (page 2). It states that the function that require the end
knowledge to do right.   
Also, Application level functions do not mean the same thing as INC.

From chat: Lixia Zhang: to share the E2E quote I just mentioned:  
"The function in question can completely and correctly be implemented
only with the knowledge and help of the application standing at the end
points of the communication system. Therefore, providing that questioned
function as a feature of the communication system itself is not possible
(Sometimes an incomplete version of the function provided by the
communication system may be useful as a performance enhancement.)  
We call this line of reasoning against low-level function implementation
the “end-to-end argument.”

From chat: David Oran: there's an even deeper question, which is what
exactly it means to be "in the network" as opposed to be "on the
network"  
From chat: Lixia Zhang: good question. My understanding of the paper: it
means in the network which does not understand nor perform higher layer
functions.

Dirk Kutscher: Agree with Lixia. This needs to be read and interpreted
carefully. Move from high level principles to concrete examples and what
do we actually want to achieve. Collective communications scenario could
be a good candidate (e.g., ClickINC).   
Ike Kunze: Aligns with research problems noted in the slides.

Colin Perkins: Think this is really good and interesting discussion to
have. Critical to work through these issues. You seem to be stating that
we have to conform to the e2e architecture and the internet layered
model. Not sure if those are the right starting assumptions, since we
are building something quite distinct from how the Internet works. Think
about an alternate way to frame the discussion, given that you may end
up with a system that is radically different to the Internet.  
Ike Kunze: It boils down to what scenario you want to use for the
network computing.   
Colin Perkins: Internet-style protocols vs something radically different
than the Internet, e.g., like how ICN is radically different. Models
that fit within a broader Internet. The concepts may not translate
between.

Joerg Ott (TUM): Responding to Colin's point. There was a very good
Network Channel presentation. Message: If it doesn't work in the
Internet, you can fix it in the overlay. A real-world deployment
shouldn't constrain the solution.  
Another point to make: We jump between different levels for INC. Not
sure packet is the right abstraction unit to work with. Has an
implication whether or not a P4 entity can do meaningful work.
Conflating whether we are talking about a switch, router, application,
proxy intermediary - we need to disentangle and make explicit. To
advance further, make these distinctions.

Wes Hardaker (ISI): Hard to think about greenfield deployments. The
Internet is a network of networks. It started with networks that weren't
necessarily always doing the right thing. Think about solving a smaller
network, before scaling up.

## 2.2 ClickINC: In-network Computing as a Service in Heterogeneous, Programmable Data-center Networks   {#22-clickinc-in-network-computing-as-a-service-in-heterogeneous-programmable-data-center-networks}

(Haoyu Song, FutureWei)  
https://dl.acm.org/doi/10.1145/3603269.3604835

Dirk Kutscher: The WG has had a creative tension between distributed
computing concepts and leveraging a programmable data plane. How to make
productive use of these facilities? The "one big device abstraction" is
an interesting way to deal with it. One question: what's the failure
model if something goes wrong?  
Haoyu Song: A good question. Future work now. Always assume a regular
topology and consider failure model. There's a common base forwarding
program so therefore we can decouple the forwarding with the function
itself, the last step is how we merge the INC functions with the base
forwarding functions, so the program developer doesn't need to worry
about how to forward.

Lixia Zhang (UCLA): I think it is interesting treating the whole network
as the super device so you can perform optimization. Related question:
Does this pertain to privately owned networks - so no security
considerations?  
Haoyu Song: Data center owned by a single owner. Can use network or
server resources to simultaneously support different applications.  
Lixia Zhang: The assumptions should be stated in big(ger) fonts to help
people understand the scope of the work.

## 2.3 P4Pir: In-Network Analysis for Smart IoT Gateways   {#23-p4pir-in-network-analysis-for-smart-iot-gateways}

(Mingyuan Zang, Technical University of Denmark),   
https://eng.ox.ac.uk/media/11759/zang22p4pir.pdf

See QR code for open-source code.

Dirk Kutscher: In the taxonomy of things, this seems to be an in-network
function. What is the assumption of the traffic you are analyzing and
encrypting.  
Mingyuan Zang: due to power consumption, all the data is in plain text.
Parse more info that we want.

Houda Chihi (Tunisia Telecom): Have you evaluated the energy consumption
in your scenario?  
Mingyuan Zang: We didn't directly test the energy consumption, however,
we use CPU and Temp to approximate the power consumption metric.

From the chat: Lixia Zhang: The P4Pir talk started with consideration on
"IoT Security" (slide-4), but I didn't see clearly where this security
consideration is addressed in the work. Hope someone can help clarify.

# 3) RG Drafts updates (10 mins each, including Q&A)   {#3-rg-drafts-updates-10-mins-each-including-qa}

## 3.1 Use Case Analysis for Computing in the Network   {#31-use-case-analysis-for-computing-in-the-network}

(Jungha Hong, ETRI-Electronics and Telecommunications Research
Institute)  
https://datatracker.ietf.org/doc/draft-irtf-coinrg-use-case-analysis/

Joerg Ott: Looking at the 16 Research Challenges, they appear to be
fairly generic and applicable to every distributed system one could
construct. Is it useful to broaden the scope to this degree? Would make
it difficult to finish a representative document. How to know when you
are finished? Vagueness may be an indicator that the scope is too broad.
How much scope should there actually be to get to completion?  
From the chat: Lixia Zhang: I'd second Joerg's comments.  
Jungha Hong: Will try to be more specific in the next round.

Roland Bless: Regarding reliability, that comes back to e2e argument.  
If you have more functionality in the network, the more things might
break. What about isolation? Things become more fragile due to side
effects of entity failures. How to achieve necessary isolation?  
Jungha Hong: We will consider.

Haoyu Song: Thank you for providing the list, but they seem less
structured. The scope is too broad now. Better to have classification of
the different use cases, to have fixed set of scenarios, each with
unique challenges.  
Jungha Hong: We do have a Categorization of Research Challenges table.
And will consider narrowing the scope.

Diego Lopez: Probably here, something to consider, e.g., load balancing,
how to explore a convergence of techniques. You have load balancing in
the cloud and load balancing in the network, and so how to make them
consistent or make them align. Perhaps the challenge is a matter of
alignment.  
Jungha Hong: We will address more specifically next time.

## 3.2 Directions for Computing in the Network   {#32-directions-for-computing-in-the-network}

(Dirk Kutscher, The Hong Kong University of Science and Technology)  
https://datatracker.ietf.org/doc/draft-kutscher-coinrg-dir/02/

Ike Kunze: Like this angle. One question in light of the use case
analysis draft and Ike's earlier presentation, how we might join these
efforts together?  
Dirk Kutscher: Let's find a time to understand related areas. Now would
be a good time to reconcile these docs.

Alex Clemm: There are a lot of things we could do, one thing missing is
WHY. What are the problems we want to solve with this that we cannot
solve without these solutions. Extract some of those problems.  
Dirk Kutscher: In the examples we could do a better job.

David Lou: Tried to address as well in a new transport for collective
communication side-meeting happening at 3pm today.  
Dirk Kutscher: I am aware of the side-meeting

Jeffrey He: Comment: Collective communication is more generic than
machine translation. Aggregation is just one of the functions. Question:
you will propose a particular direction for COIN. But the name of your
draft is Directions. Is this a specific direction proposal or more
general?  
Dirk Kutscher: Original intent was to set a scope for the group. Intent
is to narrow down. We are not nearly finished, but it could characterize
the problems and make an understasndable description of the research
problems.

Lixia Zhang: Have not read the draft yet, but enjoyed the presentation.
Will now read it and try to get some comments in.

# 4) Individual Drafts (5 mins each)   {#4-individual-drafts-5-mins-each}

## 4.1 The Requirements of a Unified Transport Protocol for In-Network Computing   {#41-the-requirements-of-a-unified-transport-protocol-for-in-network-computing}

(Haoyu Song, FutureWei)  
(https://datatracker.ietf.org/doc/html/draft-song-inc-transport-protocol-req-00)

Dirk Kutscher: One concern with collective communication, the idea of
having the network helping you, doesn't work in the presence of
connection-oriented vs data-oriented. Would you agree?  
Haoyu Song: Yes.  
Dirk Kutscher: Do you think packet is a good abstraction unit? What is
the level or layer that the transport protocol should operate at?  
Haoyu Song: Above routing/inter-networking layer, below application
layer.  
Dirk Kutscher: Let's take this offline

Colin Perkins: We don't or shouldn't have the model of a
connection-oriented transport for INC. Urge you to think more broadly.  
Haoyu Song: May not be a connection-oriented protocol to achieve.

Ike Kunze: There was a draft a few years back on the INC transport
issues.  
Haoyu Song: Aware of the drafts, let's talk.  
Ike Kunze: A few papers exist as well and I will share pointers.

## 4.2 An Evolution of Cooperating Layered Architecture for SDN (CLAS) for Compute and Data Awareness   {#42-an-evolution-of-cooperating-layered-architecture-for-sdn-clas-for-compute-and-data-awareness}

(Carlos J. Bernardos, University Carlos III of Madrid)   
https://datatracker.ietf.org/doc/draft-contreras-coinrg-clas-evolution/

Please take questions/comments to the ML.

From the chat: Lixia Zhang: I feel a little lost: is this effort (CLAS)
about research, or standardization?

# 5) Other Topics (5 mins)   {#5-other-topics-5-mins}

## 5.1 AI4ME – Delivering the future of interactive and personalised media at scale   {#51-ai4me--delivering-the-future-of-interactive-and-personalised-media-at-scale}

(Rajiv Ramdhany, BBC / Daniel King, Lancaster)  
https://ai4me.surrey.ac.uk/

Going forward will submit an I-D.  
Tomorrow in CATS WG will talk about traffic steering. Compute
optimization, placement, and network optimization.

# 6) RG Wrapup   {#6-rg-wrapup}

Thank you to all presenters, participants, and especially Ike Kunze who
hosted the session in the room! See you at IETF 119.

Total: 120 minutes