Skip to main content

Minutes IETF108: coinrg

Meeting Minutes Computing in the Network Research Group (coinrg) RG
Date and time 2020-07-31 14:10
Title Minutes IETF108: coinrg
State Active
Other versions plain text
Last updated 2020-08-18

# COIN RG Meeting at IETF-108
* Friday, July 31, 2020 @ 14:10am-15:50 UTC Time - on-line meeting
Meeting materials:

## Chairs presentation -- 10 minutes
* Scribe, administrivia, IPR and agenda bashing (Marie-Jose)
* Draft list (Eve)
* Milestones (Marie-Jose) - want to begin to address more pointedly, also
consider revisions

[Note: These notes are a combination of minutes and jabber commentary.]

## Presentations

### Peng Liu - Requirements of Computing in the Network -- 10 mins

Last time, the draft categorized the collected requirements into 3 categories:
network, computing and management requirements. Since then, added computing
resource reservation and OAM, as well as service consistency
management.Existing protocols include RSVP/RSVP-TE and PCEP, but they have
shortcomings. Therefore proposing a reference methods for distributed resource
reservation and centralized resource reservation. [See the slides for good
references that inform this work] * Comment (Dirk Kutscher): It seems like the
draft is addressing a very specific compute in the network scenario, so it
would be worthwhile to spell it out explicity in the draft. It is difficult to
discuss the requirements in general. A(Peng Liu); will  describe the model in
detail in the draft. * Comment (DaveO): One thing I didn't see in the draft was
any justification for why this needs to be different from what existing DevOps
tools do for deploying application on cloud data centers: they have to deal
with placement of computie, allocation of compute resources, allocation of
network bandwidth, laying down paths if need be to control latency, ensure
fault domain boundaries are considered, etc. A(Peng Liu)If there is any
existing DevOps tools do that, it is good to be a reference. I think that we
may consider the issue in a wide network, maybe there is any different or worth

### Dirk Kutscher - Directions for Computing in the Network -- 10 mins

Intention of this draft:
What does in-network really mean? Some thoughts on computing (e.g., what are
interesting units of computation, etc). What could/should COIN look at;
suggestions for COINRG?

What does "in-network" really mean? There is already a lot of inthe network
computing today. Ever increasing. SmartNICs, Web servers, CDNs, cloud
platforms, etc. How much research into COIN do they need? One perspective: a
joint perspective on networking and computing, not requiring fixed location of
data and computation. This draft discusses different types of in-network
computing systems, terminology, characterizing COIN, two examples (added a new
section on Akka, an actor-based toolkit), research challenges in terms of
research fields (added a new research challenge on coordination).

Author's view that COIN is...
More than just forwarding packets fo nodes that happen to host VMs or processes.
Embrace the idea of supporting distributed computing by leveraging networking
concepts and mechanisms. Not just building better pipes, but re-designing
systems. Suggestion for COIN: catalog the approaches, develop criteria and
taxonomy for discussion, identify where possible research is needed.

Q(Uma ???): what are the underlay scenarios? what are the striking
applications? are you looking at something like active networks? A(Dirk): the
draft is describing different approaches. We are more interested in trying to
look into distributed computing and see how it could be improved by moving from
a pure overlay to a better integrated system with the network. there are other
views in this group. Let's be specific on the different approaches, and don't
mix them, to develop common concepts? Next steps: chairs to solicit input on
the list on adoption of the draft.

[14:47:13] <Lixia Zhang> I'd answer the question (more directly): how to
integrate--ICN as a promising direction [14:47:29] <Diego Lopez> That was
precisely the statement I wanted to make: In a so fuzzy environment like
in-network compute is so far, a document like the one Dirk presented is a must
[14:47:35] <Ike Kunze> I agree with mjm. I think that Dirk's draft is valuable
to the group to set a common basis, e.g., regarding the different
understandings of COIN.

### Mike McBride - Data Discovery problem statement
Decided to create an overall problem statement draft, separate from the
original Edge Data Discovery draft. Problem: locating data in a standardized
way. Research standardized-based solution where data bases exists throughout
the network, where the specfic data objects are located. The location of each
data store is likely the first level discovery problem, the details of
databases' directory is likely the second level discovery problem. Now three
data-discovery-related drafts. Wanted to identify the generic problem in this
draft. What's next: if existing protocols will work here. If not, target where
a standard protocol might be needed, and if we might need a BoF. Q(Marie-Jose):
BoF in IETF or a new RG? a working group on data discovery? A(Mike McBride):
Don't know yet. Maybe a working group in IETF.

### Eve Schooler - Edge Data Discovery
Anemic references section led to Mike going to investigate related work, which
resulted in the Problem statement draft. This is a quick update: did some
clarification to the use case section. Both to service function chaining; add a
use case "ubiquitous Witness" in dense sensing (e.g cameras). Data are
contextually related, so it is able to be processed it collectively. A new,
though very modest security section.

### Xavier de Foy - Impact of mobility on discovery in COIN
Mobile devices are distributed and dynamic. Challenges on discovery associated
with wireless mobility: scalability(keep wireless resource usage low when they
change AP); multiple interfaces/networks (determine which network interface or
data network to use); service continuity (when a provider or consumer moves to
a new location). Starting point for a discussion: consider mobility related
requirements among others for data/service discovery in COIN; support
centralized and distributed schemes, control plane and data-plane solutions;
leverage or extend existing standard solutions to reduce mobile network
resource usage for discovery.

Q(DaveO) on the jabber link: What is the distinction between in the network and
on the network? It would help if you exclude the end point (distributed

Q(Marie-Jose): What are the research elements/challenges [that relate to COIN]?
A(Xavier): The mobile device use case adds an additional first step to the
discovery side, to determine what type of data do you provide to mobile device
for it to make decisions (to connect to which AP). Marie-Jose: Does this need a
computation? It would be good for each presentation or draft to go back to the
COIN charter to re-examine if the problem statement is connected. If there is
such an interest in discovering data, independent of computing, maybe it would
be worthwhile to create a separate BoF.

[15:04:50] <Lars Eggert> Could someone explain to me how these last few
presentations are related to the COINRG charter? I thought COINRG was focused
on: How programmable network HW that can operate on data is best used in the
future Internet. Yet the last few presentations are looking at something
completely different. What I think DaveO is saying: it would help if you
exclude what the endpoints can do, because that is covered elsewhere, and focus
instead on the novel bit around compute in the network and not compute in the
traditional places. A(Eve): The relevance to compute-in-the-network is that
COIN requires marshalling data from somewhere and figuring out placement of
output from the computation somewhere, as well as persistent data. View it as
an ancillary problem to COIN. Lars: Our customers lay out pretty carefully what
the data pipeline will be at the Edge and in the Core. The idea that data would
just float around is kind of weird. Eve: The assumption is that one does NOT
come from a containerized world where everything is pre-configured. One counter
example is the Ubiquitous Witness use case. For example that a programmable
switch may recognize contextually-related data and decide to do a [group]
computation on it, which is not pre-configured i/o.

[14:50:16] <Lars Eggert> regarding discovery, zmap can scan the entire v4 space
for servers listening on a given port in 4.5 minutes :-) [14:51:10] <Lixia
Zhang> zmap discovers reachable IP addresses, not data [14:51:25] <Lars Eggert>
well, the first step of his problem was to discover database servers...
[14:52:49] <Lixia Zhang> an address does not tell what the box does. but a
bigger point is that data can proactively make them noticeable (in a scalable
way) [14:54:21] <Lars Eggert> no, it doesn't. but since you need to present
some form of authorization to be admitted to see a server's date inventory,
you'd need to have a list of credentials anyway that you can then try
[14:54:51] <Lars Eggert> data enumeration w/o auth is obviously pretty
problematic [14:55:50] <Lixia Zhang> in ICN, authenticity is with data, not in
addition [14:56:19] <Lars Eggert> it wasn't clear this is meant to only apply
to the icn context (at least not to me) [14:56:29] <Lars Eggert> in that case i
don't care :-) [14:57:16] <Lixia Zhang> then we generalize: data and its
authenticity should be bound together [14:57:52] <Lars Eggert> sure. but i was
talking about authenticating the entity that wants to enumerate the data

[15:02:18] <DaveO> clarification question/comment: we seem to not have a crisp
distinction between "in the network" and "on the network". I'm having a bit of
difficulty teasing out which is which in this draft, and more generally, does
it matter? My intuition is that it does, so not excluding stub endpoints in the
absence of some distributed computing elements involved in the communication
seems a big expansion of the scope of COINRG Lixia Zhang: Want to answer the
in-net or on-net computation question. Fundamentally it seems to me it is a
name space question. If computation wants to be in the network, the network has
to recognize what that is. If the network only recognizes the network
addresses, you cannot see  computation. Toerless Eckert: Come up with examples,
such as DPI (deep packet inspection), then beat it up what's in and what's out
of scope.

[15:10:23]<DaveO> I suspect the scope may be a bit wider than the current
environment of switching hardware and its limitations, but certainly not a
networking-myopic view of the general field of distributed computing [15:12:26]
<DaveO> In other words, it may be relevant how you incorporate in-network
devices into a general distributed computing framework, but not working to
fix/ameliorate the limitations we have in today's distributed computing
frameworks, nor reinvent them starting from the limited view of networking
people alone. [15:13:55] <DaveO> My own research focus is how to get away from
the "inspect traffic as it flies by" bias of current networking folks and
really embrace the computation-first architectural view of how to do computing
in a topologically and resource-sensitive way. [15:15:05] <Lixia Zhang> if one
wants to find computed result, that blurs the line  with finding data
[15:15:26] <DaveO> Another way to say this is "involve smart networking as a
capability that people doing distributed computing can use, rather than the
reverse". [15:15:42] <Lars Eggert> Dave, agree. the question is how to best
orchestrate computation as data flows through networks and pci busses, and
through or past cpus, gpus, fpgs, etc. [15:23:27] <Lixia Zhang> @lars: how to
orchestrate: network has been orchestrating data flows from  many places to
many other places. What's new  needed is to add computation resources into the
picture as intermediate stops of data flow -- just a high level thought.
[15:24:24] <Lixia Zhang> that *just* requires computing components to be on the
same namespace with others...

[15:26:47] <Hannu Flinck> @Lixia and @Lars: there is what is called network
slice that is meant to bind together network resources and computing resurces.
[15:28:34] <DaveO> @hannu: how is a network slice different from an L2 VPN?
[15:30:05] <Hannu Flinck> @oran:
[15:31:37] <Lixia Zhang> @Hannu: I know little about slicing so tell me I got
it wrong: to me what's needed is integration as "working together", not slicing
as co-existing [15:32:59] <DaveO> @hannu - I'll take a look, the last time I
conversed with slicing folks (in terms of how to do front-haul and cross-haul
to implement a sliced network for a startup I work with) the service delivered
looked isomorphic to an L2 VPN to the clients of the slice. [15:33:14] <Hannu
Flinck> Currently the IETF approach of slicing is more of network
management/proviosing type of approach.

[15:28:18] <Stuart Card> Anybody here doing anything with "coded computing"?
[15:29:07] <DaveO> @struart - in the sense of FHE?
[15:29:49] <Toerless Eckert> @steuart: network coding ?
[15:36:25] <Stuart Card> Yes, coded computing is related to network coding, but
not the same thing. See
[15:37:23] <Stuart Card> And yes, related to homomorphic encryption. [15:37:48]
<Stuart Card> but only loosely, I think. [15:39:25] <Dirk Kutscher> @Stuart --
thanks, quite interesting!

    ### Ike Kunze: Industrial Use cases, Transport issues, Security and privacy
    -- 10 mins

Industrial use cases draft: in-network coordination for data transformation.
Strategic placement of network functions (network control, traffic filters,
data stream pre-processing or processing, industrial safety). Transport issue
draft: a prototype is started, using IPv6 address and segemant routing to find
the function and steer the traffic, SCTP as transport protocol(datagram based).
SCTP is interesting because we want packets in the network to be
self-contained, there are a variety of chunk-types, and packet signing.
Security and privacy draft: because of manufacturing context, legacy devices
are hard to update and often lack security and privacy mechanism. Looking at
manufacturer usage description (MUD) to understand what traffic behavior to
anticipate, then apply rules inside the network using p4 switches. Next steps:
would like feedback from the group on the drafts. Recommendation: Align the
group around common definitions. Often talking about similar things but using
different words for them, which makes it difficult to understand each other.

[15:40:18] <DaveO> Just to throw a final monkey-wench in…there are three
possible approaches to security I can think of here: (a)figure out how to
distribute keys to all the possible intermediaries while controlling transitive
trust and provenance, (b)depend on FHE, ©provide a shim layer to migrate the
things you want the intermediaries to operate on to be outside the encryption
envelope. Can anyone think of a fourth (or more) option? [15:44:02] <Lars
Eggert> ok, i'll bite: how does aead help? [15:45:49] <Diego Lopez> I confess
my total cluelessness: what is AEAD?? [15:46:03] <Lars Eggert> [15:45:53] <DaveO> trust
is less critical if you punt to FHE, and easier to not fall into the complexity
hole that MCTLS did if you do the shim approach. [15:47:09] <Stuart Card>
Authenticated Encryption with Associated Data (AEAD) might be an approach to
DaveO approach (c) if bundles include some cleartext &amp; some cyphertext.
[15:48:39] <Lars Eggert> if you apply aead you need a full mesh of trust,
because the computing elements will also need to aead their results [15:49:02]
<Lixia Zhang> Agree Lars' msg [15:49:03] <Lars Eggert> so it boils down to (a)

### Marie-Jose: Common data layer -- 10 mins
What are the elements and hardware, interfaces, defined to allow these
decisions and processing to be taken/done both locally and in the cloud, in
collaboration. With the network in the middle to allow the communications. data
layer functions: filtering, pub/sub, service data function discovery, cache
management etc. Match-action functionality that focuses on meta-data, i.e.,
beyond the packet headers. Use case applicability include vertical agriculture
as well as connected vehicles. Next steps: a draft for IETF 109.

[15:34:48] <Joerg Ott> Isn’t this just describing an approach that discusses
networked computing devices? A(Marie-Jose): yes and no. It also discusses
what's inside the networked computing devices, pipelining the functions and
decision making.

## Future plans
* Start to adopt some drafts, Dirk's and Ike's are the top ones.
* Interim meeting in late September for document management, new research
topics, yet high priority is scoping and clarification work to do. Host some
invited talks, e.g., Noa Zilberman, likely Stanford, Berkeley. Can consider if
a Hackathon makes sense. * Security discussion that was on jabber will be taken
to the list.
    * Lixia thinks the fundamental question is how is Trust established in
    these Edge contexts; where do you put trust? No one is going to pay to get
    a commercial certificate. * As per the ANRG, don't forget to invite
    interesting COIN-related security, privacy, trust [as advice from IAB was
    to better address these topics] * DINRG discussions relevant