[Coin] Feedback on draft-kutscher-coinrg-dir-02

[Xavier de Foy <[e-mail]>]

Hi Dirk, Teemu and Joerg,

Thank you for publishing the draft "Directions for Computing in the
Network". I agree with its content and support its adoption. Here are some
comments on revision -02 of the draft, for your consideration.


1. Introduction

- The numbered list of in-network computing variants is a great way to
introduce the subject, and could even be more explicit (e.g. using
subsections) to structure the text below it. (Even if you prefer not to do
that, you may want to align the order of the detailed paragraphs with the
order of the numbered list).

- Microservices paragraph: consider clarifying where this falls in the list
of variants ("edge computing"?). Maybe "serverless compute services"
platforms such as firecracker may support your point on stateless programs.

- (editorial on the whole document): there are a lot of terms that sound
similar: "in-network computing", "networked computing", "computing in the
network". "in the network", "in-network", "inside the network". In general
the document is already pretty clear, but maybe there is still room to
improve clarity by reducing the number of those terms, and making sure they
are consistent.

2. Terms

- Program: is it important that the program is "requested by a user"? For
example, could a COIN network perform periodic tasks? If we omit this part
of the definition, program and function could both be defined as a set of
instructions that can be executed by a computer, and may differ in scope
only.
- Platform: consider clarifying/expanding "specific host platform" in the
definition.
- Environment: the relationship between environment and platform could be
clarified (if they have a similar meaning, would it be an option to keep
only one term?)

3. Computing in the Network vs Networked Computing vs Packet Processing

- About: "Here, we try to contrast these existing and widely successful
systems (that probably do not require new research) with a more novel ...".
Not disagreeing with that, but "(that probably do not require new
research)" is a bit controversial. For example, those existing systems
could evolve to support some principles from COIN (as one of multiple
approaches to COIN).

3.2. Packet Processing

- This section appears to include flow processing as well, should this be
reflected in the section title?

- Wondering if the recent work discussed at IETF 108 on network tokens,
APN, PLUS/SPUD (which is mentioned in the charter) would have their place
in this section, in the sense that they enable some way to trigger
computation on a flow in the network, using signalling at the network or
transport layer.

By the way, do you think network tokens, APN, PLUS/SPUD should be mentioned
in the introduction, within an existing variant or as a new one?

- nits: s/the VNFs are places/the VNFs are placed/

- sff reference can be update to rfc 8677

3.3.  Computing in the Network

- The paragraph on MEC repeats some of what was said in the introduction,
and does not discuss its relation to COIN, so the purpose of the paragraph
is not clear.

- Consider defining computing in the network as explicitly as possible
(e.g. network/transport layer involvement in using
distributed/multi-domain/decentralized compute/storage, as per the
charter), so that we can objectively determine if an approach is in scope
of COIN. Then maybe there can be room for evolving existing systems towards
COIN, besides the other approach of designing a new COIN system.

- A management plane is used for code placement in non-COIN technologies
described here (MEC, SDN) in opposition to using the control plane in COIN.
Do you think it is an aspect that generally characterizes COIN systems vs.
non-COIN systems?

- Paragraph "Considering computing ... mechanisms directly.": there may be
situations where a managed cloud-like network (e.g. using SDN+NFV) is not
feasible or practical. For example: disaster scenarios, high loss/latency
environments, heterogeneous environments. This may provide a set of base
scenarios justifying developing and using COIN.

4. Examples

- Consider introducing the reason why each example is described. For
example, it seems CFN already implements some COIN concepts, while Akka may
be an example of a candidate technology to integrate with the
network/transport layers.

5. Research Challenges

- With regards to recent presentations in COINRG, some aspects of data
discovery may be relevant to COIN. For example, propagating data discovery
information in a COIN network to enable steering computation requests.
Another question is how the RG should consider the external interfaces: how
will COIN nodes discover data sources which are not COIN nodes? How will
end users discover COIN services?


Thanks again for preparing this draft,
Xavier.