Date: Tuesday, 8 Nov, 2022 -- Session I
Time: 9:30am - 11:30am UTC (London) -- 120 mins
Chairs: J/E/M
Jianfei (Jeffrey) He jefhe@foxmail.com
Eve Schooler
eve.m.schooler@intel.com
Marie-Jose Montpetit
marie@mjmontpetit.com
Join via Meetecho:
https://meetings.conf.meetecho.com/interim/?short=5203a6a0-2a4b-4983-b351-791cb6c4d8f0
Materials: https://datatracker.ietf.org/meeting/ietf-115/session/coinrg
Shared Notetaking: https://notes.ietf.org/notes-ietf-115-coinrg
Chat room: https://zulip.ietf.org/#narrow/stream/coinrg
Recording: https://www.youtube.com/watch?v=5c1tmfOAWZY
Note takers: Eve Schooler, Ryo Yanagida, your name here!
THANK YOU to Cedric Westphal for serving as our delegate in the room.
Note well, agenda, outstanding+new drafts.
Paper: https://arxiv.org/pdf/2205.08243.pdf
Joint work across many institutions. In-network ML - HotNets 2019.
Supported 4 ML models originally, now 12 ML. Currently the focus is on
automating in-network ML. A range of HW targets supported: ASICS, with
WIP on FPGA and NVIDIA HW.
Challenges
In-net classification is feasible: line rate, commodity switches,
coexists w net ft'y, scalable/hybrid deployment.
Use cases demonstrated: anomaly detection, IoT gateways, HFT, looking
for ideas?
Q Ike Kunze: re resource consumption tradeoffs. What kind of resources
constraints are the limiting factors? Sequential number of steps
executed or other constraints for features or ???
A: Several types of constraints. Most common is state consumption. E.g.,
tree depth, number of trees. Memory is another constraints: decision
tables if too many trees. Can support more than 60 features, but if
stored in ascii only 30, because the parser has constraints on header
fields. In general, there are more constraints. Most switches do not
support floating point numbers and other multiplication/division
operations. Our solution does not use those operations.
Q Hongyi Huang: In S. Korea there is a similar project. How can you
handle the training data/same picture? (feature?)
A: Not packet level but flow level data. The packet will go through
different routing pass. There is some work that uses algorithms for
image classification.
Paper:
https://www.comsys.rwth-aachen.de/fileadmin/papers/2022/2022-kunze-coin-transport.pdf
Comes out of the Transport issues draft.
What's the interplay between transport issues, e2e principle, and
in-network compute?
New version of presentation given at recent workshop last week.
Evolution of the network: from dumb to smart networks. TCP assumes
packets are unchanged when sent across the network: breaks transport
layer assumptions.
What does it take to have a COIN-enabled transport that still respects
the e2e princple (as stated in the Saltzer ACM TOCS paper from 1984)?
Also a HotNets'21 paper by Stephens et al.
Two aspects of focus: the location of computation and what kind of
computations can be performed?
Location can be considered strict (only net devices) to lax (subset of
edge/cloud computing) --> generalized to COIN elements.
Location in relation to the endpoints might be on- vs off-path.
What kind of functionality can be provided by the COIN elements? Took a
functional view.
e2e-function-internal vs e2e-function-external (functionality not part
of the original functional).
Can the latter be e2e compliant? The latter deemed not COIN.
Thus, e2e-function-internal computation on on- or off-path COIN
elements.
How/where to place functionality?
Considerations for Transport: fn'ty trad'ly implemented in endpoints
only, directly impacted by emerging COIN capabilities, several aspects
to consider (collective comm, flow granularity, but today focus on the
addressing part).
Transport addressing:
Implicit integration of a function in-the-network has the issues that it
is hard to maintain, only supports on-path notion.
Explicit steering associateds an explicit tag as the address, but it is
unclear how to actually impl this addressing.
Instance selection raises many issues: multiple possible locations, how
to select them and how to specificy constraints or locators?
Affinity might be needed, but how to realize that (setup during
orchestrations or route based on service id?).
The way ahead must consider transport addressing concerns like source
routing, service fn chaining, ICN.
Overall, many possible solutions to these open questions.
Main takeaway: COIN can be aligned with e2e principles, but need to be
careful about the questions we raise.
What was discussed at the workshop: what should be our goal, in
practice.
Have one global e2e-compliant transport protocol for everything
COIN-related? or speciliazed transport protocols (perhaps with core
features, with standardized interaction)? Or abandon e2e principle?
In the chat from Dirk Kutscher:
For function selection in ICN COIN networks, you could use path
steering:
https://datatracker.ietf.org/doc/draft-oran-icnrg-pathsteering/
Q Dirk Kutscher: you may be making your life unnecessarily hard. So much
of what you implement depends on what you want to "do". Hard to have an
effective COIN protocol without knowing that. The principles with
certain goals, may not be the same goals as COIN goals. We may need to
constrain ourselves by the proposed principles. May be premature to
think about a grand unifying protocols. We need to experiment further.
A: Goals were not really to lobby for one protocol, but rather to think
about how to align aspects and to give guidance for first larger
deployments or solutions, so that then could come back to the
considerations to evaluate if they make sense. The two papers referenced
provide good solutions for specific usages, as examples of customized
solutions.
Q: if you have a mental model of a computation in the middle of an e2e
flow. Not sure this is the best mental model. Data flow systems, where
some bits are modified, with discrete steps of computations, meaning the
whole connection metaphor may not be helpful.
A: agreed.
From chat, David Oran:
What i don't get is why even think of this as a transport protocol?
Isn't this just how you design a multi-party distributed computation
where some of the parties are topologically positioned on switches and
servers "inside" the network?
I also tend to agree with Dirk that a better match than some kind of
"wire with bumps in it" with the transport emulating a wire is a data
flow graph where each place that computes is a terminal or non-terminal
node on the graph.
Q Roland Bless:
Robustness is an attractive attribute of e2e model. Could be
interdependencies or side effects that could be avoided. Protection of
innovation: the argument is that it is hard to change the network. When
we have fn'ty in place that allows that, it is no longer an obstacle (as
compared to when e2e principle was written). Another observation: when
you talked about addressing, it complicates things if you req apps to
have knowledge about the network. The network tries to figure out what
to do to support the app. Alternatively, the app may know when/where to
locate the functions. App developers say please do not do that, because
complicates application writing.
A: Thanks for the interesting thoughts. Re Robustness/Interactions of
functions. If want some kind of reliability, how would we handle 2-3
functions, but the packet gets lost in after some but not all of the
functions? If we consider ICN aspects, might reduce complexity.
Q Andy Reid: Very interesting paper. Connection between the transparency
of e2e and addressing is a central issue. Similar to paper presented at
last IETF. Would be keen to develop further. Started from a different
starting point, but came to similar conclusions.
Q Lars Eggert: Two points correlating to the 2 parts of the slides.
Early stages of putting fns on FPGAs.
Think you have something there about e2e principles.
From practical view, want to put something expensive somewhere cheaper
so want to do the minimal thing to make my current app faster. Therefore
don't want to have to use new protocols, specifically for Internet. More
customized, more difficult. Encourage folks to focus on the low hanging
fruit for now. For IETF, the things we can deploy soon are much more
interesting (to Lars).
From chat, Dirk K.: I thought this is about research?
From the chat, Ryo Yanagida:
I agree, I feel that chasing 'easily deployable' limits the
possibilities.
Personally, I find it interesting to work on filling in the gaps and
trying to bring the clean-ideal architecture/design/mechanism into a
real-world in more deployable way. But, that is only possible because
there are those ambitious research on clean-slate novel approaches out
there.
Q Erik Nordmark: really like thinking about the implications and
framing. One thing that ties into robustness but not presented here is
state in the network. Might be useful to add to the list of things to
consider. You also raised an interesting issue: a common transport
protocol. We already have an example, in-band or in-line OAM. Can mesh
things in interesting ways. Have that at one end. ICN at the other end.
A: Large spectrum of solutions from minor tweaks to brand new solutions
Likely will need more practical experience. Robustness addressed some in
the drafet, but perhaps not State addressed directly but was in the back
of our minds.
Paper: to be published in the upcoming ICBC2022
See also IIC white paper and draft listed in the slides.
Permissionless distributed concensus systems have evolved from DHTs to
Distributed consensus (DCSs) to Distributed ledgers (DLTs), consensus
oriented on distributed content.
Key mechanism used is randomized atomic broadcast (over a set of
receivers). Built as a peer to peer system on top of IP networsk, using
UDP, TCP and QUIC. Identified communication pattern in multiple places:
pick a peer from a list of DLT peers.
Many challenges for users and provider networks: pool maintenance,
resilience and reliability, match capabilities, unicast replication, IP
address privacy
Investigations/Observations
Can the network help with these issues? YES
Draft: https://datatracker.ietf.org/doc/draft-urien-coinrg-iose/
An architecture for an Internet of Secure Elements, where Secure is
measured by evaluation assurance level (EAL) that goes up to EAL6+.
Note that 9 billion secure elements were shipped in 2021.
Why connect secure elements to the Internet? On-line trusted
cryptographic resources for internet users, identified by URIs. Many
issues such as: add'l processor (server) is req'd w net interface and
TCP/IP conn'ty. Global platform support ofr on-demand apps. Protocol to
access secure leement resources. Secure element naming. Attestation for
on-demand apps.
IOSE draft creates cryptographic resources URIs and identifies IOSE
server components.
Open Resources available on GitHub
Q Eve Schooler: Help us connect the dots to COIN.
A: Security mechanisms/capabilities in the network, you need a safe
place to store a key and compute cryptographic processes. Today, you put
your secure module in the cloud for example. But at a user level, you
have no trust insurance about that nor do you have open features today.
Relationships to COIN is that when you need some way to deploy a secure
processor in the Internet (to perform authentications, signatures), then
this could apply. With some open stuff - it is not so simple to get open
stuff today. Nor provable stuff. Higher levels are certified by a
national security agency usually managed by governements. These are your
roots of trust. Many manufacturers of that and standards related to
these components (and many of them exist, order of billions). Not so
easy; very difficult to demo SW and recover keys that are stored. A way
to have procedures hosted in the Internet with an improved level of
security and trust for the user.
[Note Emmanuel Baccelli to take additional question to the e-mail
list]
Possible Interim in January: queue up discussion on
retrospective/directions, reflections after 3 years.
See the 5G NetApp Lab proposal solicitation from [e-mail Oct 25)]
Have a look at the Hotnets'22 technical program that is h appening next
week
Total: 120 minutes