►
From YouTube: IETF110-COINRG-20210312-1600
Description
COINRG meeting session at IETF110
2021/03/12 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
Fearless
leader
lisa
zang,
but
I
am
not
seeing
her
on
the
participant
list,
so
I
think
I
will
welcome
you
myself.
Welcome
everyone
to
the
coin
rg
session.
Welcome
to
our
speakers.
Welcome
to
those
of
you
who
regularly
attend
and
welcome
to
our
new
attendees,
I'm
eve
schuler,
and
I
have
two
co-chairs
jeffrey
and
marie
jose,
and
we
sometimes
refer
to
ourselves
as
jem
you're
at
the
ietf
110
and
we're
virtually
in
prague.
A
The
documentation
and
materials
for
this
session
can
be
found
online
through
the
data
tracker.
Remember
that
all
of
these
sessions
are
being
recorded
and
please
ensure
that
your
video
is
off,
keep
yourself
muted
and
we
will
monitor
the
chat
cues
for
you.
The
chat,
as
well
as
the
queue
for
speaking.
A
In
case
you
have
not
attended
the
ietf
and
irtf
before
and
in
fact,
coinrg
is
part
of
the
irtf.
There
are
intellectual
property
rights,
disclosure
rules
that
are
crisply
described
in
many
documents
and
by
participating
in
the
ayatura
irtf.
You
agree
to
many
of
these
processes
and
policies.
Implicitly
by
joining
the
session.
A
B
Hello,
everyone,
I'm
I'm
sorry,
I
I'm
sorry.
I
had
connectivity
issues
so.
A
Get
through
this
and
then
I
will
advance
for
you
and
then
when
we
get
to
the
presentations,
then
I'll
switch
over
and
I'll.
A
And
you
can
continue
additionally,
the
privacy
and
code
of
conduct.
There
are
high
standards
documented
in
these
places,
and
the
goals
of
the
irtf
are
slightly
different
than
the
ietf
they're
to
conduct
research.
A
It's
not
neces,
it's
not
about
standards
development,
although
there
is
certainly
precedent
for
groups
in
the
irtf
to
mature
into
groups
into
the
ietf.
But
that
is
not
our
intent.
It
is
really
to
be
a
forum
and
community
for
research.
D
Yes,
and
actually,
I
would
like
to
to
point
on
the
last
slide.
I
know
we're
going
to
have
a
number
of
presentations
today
by
new
people
and
the
group,
and
I
think
it's
very
important
to
highlight
what
is
related
to
a
research
community
in
your
presentations
and
we're
not
a
working
group
and
we're
not
going
to
produce
any
standards.
D
So
we
can
go
to
the
next
slide.
You
did
you're
sharing.
If
you
want
me
well,
let's,
let's
wait.
I
will.
D
So
our
goal
essentially
because
we're
a
research
group
we
would
like
to
create
a
dynamic
community
for
computing
in
the
network
and
on
the
network,
because
I
think
we've
we've
made
progress
in
both
directions
and
to
share
and
define
the
research
that
will
help
to
use
computing
to
improve
performance
in
networks
and
applications
and
eventually
to
users.
D
So
it's
not
about
again
it's
not
about
creating
standards
to
implement
in
industry.
It's
about
to
create
that
research
community
that
eventually
will
evolve
most
likely
into
industry
projects
and
technology
transfers.
D
So
the
scope,
obviously,
is
the
evolution
of
of
these
systems.
The
architectures
you're
going
to
see
a
lot
of
that
today,
the
protocols
that
are
being
used
and
how
they
can
also
evolve
within
the
research
community
and
real
world
use
cases,
application
and
obviously
a
lot
of
work
and
progress.
D
D
So
today's
presentations,
we
continued
the
trend
that
we
started
at
the
last
ietf
a
little
bit,
but
mostly
at
the
at
the
interim,
which
is
having
invited
papers
that
are
relevant
to
the
evolution
of
coin.
So
today
we
have
all
these
papers
and
they
cover
architectures
computing
and
distributed
systems.
D
I
would
say:
data
set
more
than
databases,
storage
and
edge
devices.
Obviously,
the
whole
move
to
distributed
information
systems
across
the
network
deployment
aspects
and
also
we're
going
to
have
a
short
draft
update.
There's
a
lot
of
research
going
on.
We
have
a
few
drafts
that
have
expired
and
that
will
need
some
attention
from
the
authors,
but
we're
going
to
talk
about
that
after
the
presentations.
D
So
a
short
summary
of
the
research,
the
slides
are
available.
So
that's
why
there's
links
to
the
papers
there?
So
if
you
you're
going
to
have
the
obviously
the
slides
in
the
data
tracker,
but
you
can
also
get
the
papers
so
we're
going
to
have
a
first,
a
presentation.
D
The
flow
lens
which
was
presented
at
ndss
we're
going
to
have
a
review
of
some
of
the
work
from
theo
at
stanford
and
he
also
works
with
robert
soulet
at
yale,
who
is
one
of
the,
I
would
say,
leading
researchers
in
computing
in
the
network,
we're
going
to
have
presentation
from
georgia,
tech
on
distributed
data
storage,
another
presentation
from
toronto
on
session
consistency
and
the
project
from
ericsson
on
connected
intelligent
machines.
D
That
actually
requires
a
lot
of
processing
and
then
we're
going
to
have
an
update
on
the
coin.
The
network
computing
for
app
centric
microservices
from
their
crossing
and
to
presentation
from
heman
singh.
You
may
probably
not
have
seen
his
name
a
lot.
He
was
very,
very
active
when
we
did
the
hackathon
and
he's
a
leading
researcher
in
in
p4.
D
So
he's
going
to
present
that
I
say:
there's
a
typo
but
that's
fine,
and
then
we
hope
to
have
time
for
discussions
and
and
see
a
little
bit.
You
know
what
how
we
can
evolve
a
few
things,
and
then
we
are
going
to
go
through
some
conclusions
and
future
plans
and
especially
the
the
goals
for
the
next
meetings
and
the
interim.
D
So
this
is
it
I
I
don't
want
to
take
more
time.
We
want
to
go
directly
into
the
presentations
and
should
and.
A
A
A
And
I
would
like
to
tell
people
that
I
am
taking
notes
which,
if
you
go
to
the
top
of
the
meet
echo
screen,
is
the
is
the
button
that
has
the
pencil
over
the
paper
and
that
takes
you
right
to
cody
md
and
please
it's
a
group
sharing
note-taking
tool
so
by
all
means,
if
you
have
some
comments,
you
want
to
make
we'll
be
monitoring
the
the
chat
as
well,
but
feel
free
to
add
your
notes
into
the
meeting
notes.
A
D
D
E
Yeah
sure
so
I
would
actually
propose
that,
so
let
me
try.
A
And
if
that
doesn't
work,
I'm
happy
to
share
again,
I
it's
just
hard
to
note,
take
and
share
screen.
At
the
same
time,.
E
So
it
says
that
I'm
in
this
sort
of
key.
E
E
Can
you
see
my
slides
now?
Yes,.
E
D
E
Okay,
so
thank
you
so
much
for
having
me
presenting
my
work
here
at
the
coin
rg.
So
my
work
is
joint
work
with
moonsanch,
which
would
reach
france
and
andre
madera
from
ineski
to
superior
technique
university
of
lisbon,
and
also
salvatore
signorelo
from
lazy,
faculdad,
cnc
university
of
lisbon
as
well,
and
so
today,
I'm
going
to
talk
a
little
bit
about
our
system
called
flow
lens
that
used
programmable
switches
to
enable
a
range
of
machine
learning
based
security
applications
in
the
network.
E
E
Speed
can
be
fully
programmable
in
the
p4
language
and
have
also
been
the
recent
focus
of
different
hardware
manufacturers,
and
so
they
actually
bring
new
opportunities
in
the
realm
of
network
security
and,
as
a
matter
of
fact,
these
switches
have
also
been
used
by
different
authors
to
propose
new
security
applications
in
the
network,
such
as
the
obfuscation
of
network
topologies,
the
filtering
of
spoof
type
traffic
mitigation
of
ddos
attacks,
or
also
to
forward
network
cover
channels
and
by
using
programmable
switching
devices.
E
But,
however,
as
you
can
see,
they
are
actually
fine
tunes
for
a
very
specific
application
domains
and
unfortunately,
they
ignore
some
other
important
applications
that
depend
on
machine
learning
and
so
within
these
applications
we
can
think
of
the
detection
of
botnet
traffic,
the
fingerprinting
of
websites
that
is
identifying
a
website
that
is,
the
that
is
being
browsed
by
given
clients
over
unencrypted
circuits,
also
to
perform
the
analysis
of
the
behavior
of
different
iot
devices
like
smart
home
devices,
and
also
to
detect
cover
channels.
E
So
one
thing
that
all
these
applications
have
in
common
is
that
they
rely
on
some
kind
of
statistical
traffic
analysis
that
analyzes
and
extracts
features
from
the
distributions
of
packet,
lengths
or
inter-arrival
times
of
such
network
flows
and
then
use
a
machine
learning
based
classifier
to
distinguish
between
different
classes
of
traffic.
Let's
say
malicious
traffic
from
benign
traffic
within
an
organization
and,
as
you
can
see
as
well,
so
this
is
some
sort
of
a
generic
approach
to
detect
multiple
attacks.
E
However,
collecting
these
packet
distributions
in
programmable
switches
is
actually
a
hard
task.
So
in
the
one
hand
we
know
that
the
stateful
memory
that
is
available
in
this
kind
of
devices
is
very
limited
and
typically
just
allows
for
keeping
track
of
a
few
hundreds
of
megabytes
of
sram,
and
this
just
has
no
memory
for
starting
many
flows
that
can
cross
these
switches.
Concurrently.
E
Not
all
that
we
know
also
that
packets
must
be
processed
at
line
speed
within
these
devices,
which
typically
means
processing
packets
within
the
switches
under
a
few
times
of
nanoseconds,
and
we
can
only
use
a
limited
number
of
operations
to
do
this,
also
using
a
reduced
and
often
domain
specific
instruction
set,
and
so
this
actually
raises
the
question
that
it
really
doesn't
seem
feasible
to
obtain
these
packet
distributions
in
programmable
switches
at
scale
to
enable
these
machine
learning
based
applications.
E
So
we
know
that
there
are
being
proposed
different
solutions
for
collecting
these
packet
distributions,
also
with
the
aid
of
programmable
switches.
So,
for
instance,
star
flow
proposes
this
kind
of
packets,
duplication
approach
back
to
a
monitoring
server.
And
while
this
approach
is
generic,
it
incurs
in
a
large
bandwidth
costs
by
sending
these
packet
properties
back
to
this
monitoring
server.
And
we
also
have
other
approaches
such
as
networking,
which
can
actually
perform
some
kind
of
computation
on
the
packet
distributions
of
flows
within
the
programmable
switch
itself.
But
can.
E
A
Audio
of
our
speaker,
joko,
are
you
hearing
us?
Did
you
type
in
the
chat
window.
A
A
A
Sometimes,
when
you
use
the
arrow
key
all
the
way
at
the
bottom
of
the
screen,
the
far
right
there's
two
arrows
and
they
it
suggests
to
reconnect
the
audio.
Sometimes
that
will
help
if
you
could
try
that,
but
I'm
suspecting
he
can't
hear
us.
So
I'm
going
to
type
in
that
as
well.
Okay,.
D
D
F
A
D
And
I
re,
I
remind
everyone
that
you
have
15
minutes
so,
but
I'm
I'm
dealing
with
the
diogo
right
now.
Okay,
go
ahead.
F
Okay,
so
I'm
going
to
tell
you
why
networks
should
and
from
and
can
provide
more
expressive
routing-
and
this
is
a
little
bit
controversial
because
it
touches
on
the
end-to-end
end-to-end
principle,
but
I
I
think
you'll
you'll
enjoy
it.
So
I
worked
in
this
together
with
with
ali
fazoloman
masood,
mashref
antonio
cartaniga,
nate,
foster
and
and
robert
soy.
F
This
was
done
at
when
I
was
interning
at
barefoot
networks
and
at
university,
but
now
I'm
at
at
stanford
university.
F
So
we
see
a
fundamental
mismatch
between
the
application
requirements
and
the
api
provided
by
the
network,
so
how
do
applications
actually
communicate?
Let's
look
at
some
modes
of
communication
in
a
microservice
environment
services.
Don't
send
requests
to
the
physical
hosts,
but
to
a
service
by
id,
with
a
locate
with
load.
Balancer
applications
don't
contact
a
specific
server
with
the
server
with
the
lowest
load
and
in
publish
subscribe
systems
like
apache
kafka
or
activemq.
F
They'll
applications
send
messages
to
topics
and
the
middleware
or
the
software
broker
messages
forwards,
the
messages
to
their
destinations,
so
these
systems
provide
more
expressive
routing
than
just
ip
forwarding,
but
they're
slow
compared
to
network
devices.
They
introduce
significant
latency
and
can't
handle
the
same
throughputs.
F
Let's
see
an
example,
let's
say
we
have
a
publisher
that
sends
messages
with
different
attributes
or
fields,
for
example,
a
message
with
a
topic
r
that
has
received
70
likes
so
far,
then
there
are
services
like
analytics
services
which
want
to
receive
some
of
these
messages.
One
is
only
interested
in
art
another
only
in
sports.
One
would
like
art
with
more
than
50
likes.
F
F
F
F
F
So
what
do
packet
subscriptions?
Look
like
a
packet
subscription
lets
an
application,
decide
how
the
network
should
process
a
packet
based
on
its
content
in
its
simplest
form,
a
subscription
identifies
a
packet
and
executes
an
action,
for
example.
If
the
top
topic
of
the
message
is
art
for
it
to
host,
one
subscriptions
can
also
be
more
complex.
F
This
is
a
powerful
abstraction
because
it
decouples
the
the
locations
from
addresses
from
the
content
of
the
messages.
But
how
do
we
make
this
practical?
It's
not
so
straightforward
to
get
this
working
at
the
switch
local
level.
How
do
we
run
these
rules?
We
need
to
compile
them
somehow
and
execute
them
efficiently
at
line
rate
and
then
from
the
global
perspective,
how
do
we
route
with
rules
on
the
network?
Which
switches
should
store
the
rules?
F
I'll
show
you
how
we
tackle
both
of
these
challenges?
Let's
start
looking
at
the
single
switch
as
inputs,
we
have
a
application
specification
which
indicates
the
type
of
packets
will
be
processing
and
we
have
subscriptions
from
the
hosts
the
apple
application
specification,
which
doesn't
change,
often
is
compiled
once
to
generate
a
pipeline
of
tables
on
the
switch.
F
F
F
F
This
tree-like
structure
essentially
encodes
the
logic
of
matching
a
packet.
You
can
think
of
it
as
a
as
a
finite
state
machine.
You
traverse
the
tree
from
top
to
bottom,
starting
at
the
root
node
and
each
node
predicates
on
a
field
in
the
packet.
If
the
predicate
is
true,
you
take
the
true,
solid
line,
otherwise
the
dot,
the
dotted
line,
if
it's
false
and
finally,
you
arrive
at
the
leaf
node
at
the
bottom.
This
indicates
the
action
to
be
taken,
but
how
do
we
execute
this?
This
data
structure
on
the
switch?
F
F
Essentially,
these
tables
encode
a
finite
state
machine
each
table
matches
on
one
of
the
predicates
and
updates
a
state
variable
that
corresponds
to
our
location.
In
the
tree.
This
state
is
passed
from
table
to
table
and
at
the
last
table,
depending
on
the
current
state,
it
executes
the
appropriate
action
like
forward
to
a
host
or
drop
the
packet.
F
F
Well,
all
the
switches
going
up,
the
topology
must
store
this
rule
and
for
each
for
each
of
these
switches
we
calculate
the
shortest
path
and
forward
the
packet
down
the
appropriate
link.
But
how
about
the
other
side
of
the
network?
How
about
going
up
the
topology
from
from
a
sender
on
the
other
side?
Do
we
need
to
store
all
the
rules?
F
Alternatively,
we
can
use
a
memory
reduction
scheme
if
we
want
to
store
less
rules
instead
of
matching
on
the
topic
r
going
up
the
topology,
we
forward
all
the
packets
that
right
from
below
upwards
until
the
core
switch,
then
the
core
switch
forwards,
the
packets
down,
so
the
core
switch
needs
to
store
all
the
rules,
so
the
this
uses
less
memory
than
the
other
scheme,
but
it
comes
at
the
expense
of
sending
more
traffic
because
all
packets
have
to
go
all
the
way
up
to
the
top
of
the
topology
before
they
can
start
going
down.
F
This
reduces
the
number
of
rules
and
also
saves
bandwidth
in
our
evaluation.
I'll
show
you
how
the
schemes
I
showed
you
here
compare
so
we've
built
a
prototype
of
packet
subscriptions
and
we
use
it
to
answer
several
questions.
Our
first
question
is:
are
packet
subscriptions
useful
to
applications?
F
Does
it
provide
the
interface
that
they
need
to
answer
this?
We
implemented
several
applications.
We
use
packet
subscriptions
to
filter
the
nasdaq
itch
feed
and
we
routed
video
streams
for
cisco's
hybrid
icn
system
and
we
use
it
to
detect
network
events
and
streams
of
in-band
network
telemetry,
int
data,
the
market
filtering
and
the
network.
Telemetry
applications
did
not
require
any
changes
to
use
packet
subscriptions.
We
could
use
the
the
header
packet
header
formats
from
the
original
protocols,
and
this
demonstrates
that
packet
subscriptions
provides
the
right
interface
for
these
applications.
F
F
We
connected
a
server
to
a
tofino,
programmable
switch
and
on
the
server
we
ran
a
feed
publisher
which
sends
market
events
to
the
switch
which
sends
it
back
to
the
server
which
has
a
subscriber
running
on
it.
The
subscribers
co-located
on
the
server
with
a
publisher
for
accurate,
timestamp,
stamping
and
the
subscriber,
is
only
interested
in
events
for
the
google
stock.
F
F
When
the
switch
filters,
the
messages,
the
tail
is
a
lot
smaller.
As
you
can
see
the
on
the
the
green
line,
the
99th
percentile
is
below
50
microseconds,
and
this
is
because
the
buffers
don't
build
up
at
the
subscriber
with
when,
when
the
subscriber
is
performing
the
filtering
it
can
cannot
keep
up
with
the
the
line
rate.
The
switch,
however,
can
perform
filtering
at
line
rate
and
send
exactly
the
packets
the
subscriber
wants.
Thus,
the
subscriber
does
not
waste
any
time
filtering
out
the
superfluous
messages.
F
F
F
We
found
that
overall,
the
compiler
uses
memory
efficiently
with
1600
filters.
We
can
filter
the
prices
of
a
few
hundred
stock
symbols,
which
is
a
realistic
workload,
and
this
generates
18
million
table
entries,
which
fits
well
within
the
memory
constraints
of
the
switch
notice
that
here
in
the
traffic
reduction
scheme,
that
all
the
switches
use
the
same
amount
of
memory,
and-
and
this
is
because,
as
I
mentioned
before,
every
switch
in
the
network
needs
to
store
every
rule
to
send
the
packet
the
most
direct
path
with
the
memory
reduction
scheme.
F
On
the
other
hand,
most
switches
use
very
little
memory.
That's
because
they
only
need
to
store
subscriptions.
Are
the
rules
for
the
hosts
that
are
immediately
below
them
in
their
topology?
The
core
switch,
on
the
other
hand,
needs
to
store
all
of
these
rules.
As
you
can
see
this.
The
curve
here
for
the
course
switch
is
the
same
as
what
we
saw
for
the
traffic
reduction
scheme.
So
there's
the
the
difference.
There's
no
difference
in
memory
reduction
between
the
two
schemes,
at
least
for
the
for
the
core
switch.
F
D
Yeah
we
can
maybe
take.
We
have
two
people
in
the
queue.
First
is
alexander
clem.
So
alexander,
please
ask
your
question.
C
Yes,
hello,
a
very
interesting
presentation.
Thank
you
very
much.
I
my
question
is
what
you
can
actually
filter
on.
Basically,
does
it
require
you
to
expect
payload
or
how
do
you
deal
with
encrypted
traffic?
Can
you
comment
on
that.
F
Yeah,
that's
a
that's
an
excellent
question,
so
our
compiler,
you
can
specify
to
our
compiler
the
packet
header
format
using
p4
and
so
any
any
any
header
format.
That's
parsable
by
p4
is
supported
by
our
our
compiler,
essentially,
and
so
of
course,
there
are
some
limitations,
so
how
deep
you
can
look
into
the
payload
and
what
types
of
header
formats.
F
So
we
since
p4
supports
fixed
fixed
length,
fixed
width,
headers,
that's
for
now
that
we're
limited
to
that,
and
I
think
you
mentioned
something
about
encryption.
F
That's
something
we're
also
of,
of
course,
lots
of
messages
that
travel
through
the
network
are
encrypted
and
that's
some
unless
the
switch
can
decrypt
packets
right
now.
Packet
subscriptions
needs
to
look
at
the
packets
in
plain
text,
and
we
we've
been
thinking
about
some
homomorphic
encryption
schemes
which
will
allow
the
the
the
switch
to
perform
perform
forwarding
on
the
on
these
packets
without
knowing
the
actual
content.
But
that's
that's.
G
Yeah
thanks
very
nice
presentation.
I
think
it's
a
good
example
of
say
how
the
network
could
you
know
assist
in
achieving
you
know
computation
or
data
subscription
like
applications.
G
So
I'm
a
bit
familiar
with
the
general
body
of
this
pub
sub
work,
and
so
I
also
wanted
to
ask
the
security
question,
but
you,
you
already
mentioned
a
potential
way
there.
What
about
other
things
like
congestion
control,
for
example,.
F
That's
a
that's
a
good
question,
so
I
I'd
argue
that
congestion
control
is
orthogonal
to
to
what
packet
subscriptions
does.
I
think
that
you
could
add
congestion,
control
to
packets
descriptions
and
another.
Another
issue
related
to
to
congestion
control
is
reliability
and
again
that's
something.
That's
that's
difficult
to
handle
in
publish
subscribe
systems,
especially
because,
unlike
models
like
tcp,
which
are
have
one
sender
or
one
receiver
in
public
subscribe
systems,
there
can
be,
it
can
be
one-to-many
or
many-to-many
model.
So
you
you
don't
it's.
F
F
So
I
think
congestion
control
could
be,
should
be
handled
another
another
layer
than
than
packet
subscriptions.
G
D
I
know
there's
a
question
from
dave
oren
and
I
see
now
that
somebody
else
would
join
the
queue
but
for
sake
of
time
tianji
I
maybe
you
can
be
very
fast
and
theo.
You
may
want
to
look
at
the
question
from
davor
and
respond
offline.
It's
about
fragmentation,
so
tianji
a
quick
question
and
then
we
move
on.
D
I
We're
taking
too
much
time
sure
sorry
about
that.
It's
just
like
informational,
very
interesting
topic,
but
just
for
the
example
you
are
using
here
with
nasdaq
example,
you
may
reference
a
paper
by
asking
greg
from
as
easy
about
some
fast,
the
the
the
slowness
aggregate
transactions.
So
in
your
case,
you
are
doing
some
round
trip
between
the
server
your
switch
and
then
subscribers.
So
it's
my
it
might
cause
some
problem
with
the
things
so
the
other
paper
about
how
to
do
this
type
of
things.
So
you
may
reconsider
your
example.
I
Okay
sure
yeah,
it's
like
a
three
year
back
yeah
from
sac.
Okay,.
B
Please
put
the
paper
in
the
stack
diogo,
I
hope
you're
back,
but
before
you
go
teo.
Thank
you
for
an
excellent
presentation.
B
A
D
Thank
you.
Thank
you.
Thank
you,
teo
and
I'm
sure
there's
going
to
be
follow
up
and
yogo
is
starting
to
to
share,
and
hopefully
the
sound
will
be
there
so
diogo
you
don't
have
to
restart
from
the
beginning.
You
can
go
to
where
you
were
when
the
sound
went
off,
and
I
remind
you
that
you,
you
have
15
minutes,
you
have
way
too
many
slides.
D
Work:
okay,
so,
okay.
E
E
Thank
you.
So
we
propose
for
lens,
which
is
this
flow
classification
system
for
generic
machine
learning,
based
security
tasks
and
one
contribution
is
this
compact
representation
of
the
packet
distributions
within
the
switch
the
flow
marker
accumulator,
which
is
a
way
that
we
actually
implemented
this
kind
of
a
collection
within
the
switching
hardware.
And
then
we
built
an
automatic
profiler
that
can
tailor
the
size
and
the
accuracy
of
these
flow
markers
respectively
to
the
application
itself,
and
we
also
evaluated
our
system
resorting
to
three
different,
security-based
tasks.
E
So,
in
a
nutshell,
our
full-length
system
is
comprised
of
a
profiler
server
which
can
be
used
to
given
a
training
data
set
provided
by
the
client.
Tell
us
which
are
the
better
parameters
for
achieving
that
balance
between
the
size
and
the
accuracy
of
the
flow
marker.
These
parameters
will
be
loaded
into
a
p4
program
within
the
switch
that
will
be
responsible
for
actually
compressing
the
packet
distributions
and
sometimes
periodically
these
packet.
These
flow
markers
will
be
collected
to
the
control
plane
of
the
switch
which
will
be
actually
performing.
E
The
classification
of
these
flows,
so
flow
lens
can
be
used,
distributed
fashion
across
the
network
to
scale
the
number
of
measured
flows,
ensure
network
visibility
and
can
also
be
used
in
different
switches
to
support
multiple
machine
learning-based
applications
across
the
network.
So
to
produce
these
packet
distributions
efficiently.
What
we
did
was
to
quantize
the
packet
distribution,
and
so
in
some
sense
you
can
see
that
if
this
is
a
row
packet
size,
distribution
of
a
given
flow,
we
can
compress
it.
E
Let's
say
by
a
factor
of
16,
and
then
we
can
further
apply
a
pre-processing
step
based
on
supervised
learning.
That
will
tell
us
which
of
these
particular
bins
of
the
distribution
are
most
useful
for
performing
classification,
and
so
in
this
case
we
can
see
that
this
is
the
top
10
bin
that
will
be
still
useful
for
representing
the
actual
raw
packet
size,
distribution
and
still
achieve
a
high
classification
accuracy,
and
so,
for
instance,
this
allowed
us
to
achieve
up
to
150
times
size
reduction
in
the
size
of
these
slow
markers.
E
So,
just
for
the
implementation
of
full
marker,
I
would
like
to
say
that
we
started
by
implementing
our
design
on
a
software
simulator,
and
then
we
had
to
adapt
our
program
in
the
physical
switching
hardware,
where
we
actually
focused
the
tofino
switching
asic.
So
I'm
going
to
skip
some
of
the
problems
that
we
did
have
in
implementing
these
on
the
on
the
switch
itself.
E
But
I
would
like
to
let
you
know
that
the
typical
architecture
for
one
of
these
programmable
switching
devices
is
actually
these
sequence
of
match
action
tables
that
can
match
some
packet
fields
and
trigger
an
action
that
will
change
some
packet,
headers
or
metadata.
E
All
these
is
programmed
in
p4,
and
there
are
a
few
drawbacks
on
these
feed
forward
pipeline
that
we
had
to
overcome
to
actually
build
our
quantization
and
rotation
approaches
for
generating
flow
markers.
E
So
I'm
skipping
some
of
the
details
of
this
implementation
that
basically
showed
that
we
actually
had
to
come
up
with
a
representation
that
was
simple
enough
to
be
run
in
these
in
these
tasks
and
that
we
actually
used
the
control
plane
to
assist
in
this
rotation
procedure.
E
So,
in
a
nutshell,
I'm
going
to
show
you
how
what
what
happens
in
full
length
when
a
new
flow
actually
reaches
the
switch
so
suppose
that
we
have
this
flow
id
that
the
switch
has
not
seen
previously
and
the
packet
size
of
that
particular
packet
of
the
flow
is
512..
E
Since
this
packet
has
not
been
yet
seen
in
the
in
the
switch,
we
will
ask
for
the
control
plane
to
install
a
rule
that
will
index
this
flow
in
the
flow
table.
That
is
in
some
of
the
stages
of
the
switch.
So
the
flow
will
be
indexed,
for
instance
in
here
in
stage
four,
and
we
also
use
the
control
plane
to
set
a
flow
offset
in
the
register
grid,
which
is
the
amount,
the
local,
the
local,
in
memory.
Where
we'll
keep
track
of
these
flow
markers.
E
So
in
stage
one
we
will
quantize
the
the
distribution,
and
so
we
will
obtain
a
bin
index
of
this
quantization
from
this
packet
size
that
responds
to
16.
in
stage
two,
we
will
perform
the
truncation
process
and
consult
the
table
that
was
set
previously
in
the
control
plane,
and
in
this
case
the
transition
flag
is
set
to
one,
which
means
that
we
should
keep
this
packet
size
and
the
bin
offset
is
one
which
means
that
it
is
the
second
packet
or
the
second
beam
that
we
should
take
into
account.
E
So
in
stage
3.
Nothing
will
happen
because
the
flow
does
not
match
in
this
whole
table,
but
it
will
match
in
flow
table
2
in
stage
4..
Once
this
happens,
we
can
compute
the
cell
offset.
That
should
be
updated
in
the
register
cell.
E
That
corresponds
to
the
full
marker
of
this
flow,
and
so
we
do
this
by
summing
the
flow
offset
with
the
bin
offset
that
was
computed
previously
and
finally,
in
stage
five,
we
just
increment
the
position
for
this
particular
full
marker,
and
this
allows
us
to
count
the
to
generate
these
flow
markers
at
line
speed.
E
So
since
there
is
this
large
configuration
space
of
quantization
and
rotation
parameters,
we
actually
leverage
bayesian
optimization
to
build
an
automatic
profiler
that
could
build
these
flow
markers
with
three
different
criteria:
either
choose
the
smaller
flow
marker
for
given
target
accuracy
to
select
the
best
accuracy
given
a
size
constraint
for
the
flow
marker,
or
else
to
find
a
compromise
between
the
two.
And
by
doing
this
we
actually
save
many
hours
of
testing
what
would
be
sub-optimal
configurations
of
the
parameterization
of
quantization
and
truncation
to
evaluate
our
system.
E
We
try
to
evaluate
its
scalability
on
three
different
generic
machine
learning
based
security
tasks,
including
cover
channel
detection,
website,
fingerprinting
and
botnet
detection.
We
evaluated
the
performance
of
our
profiler
and
we
also
evaluated
the
resource
consumption
that
flowlands
used
in
the
switch
both
on
cpu
usage
and
also
on
the
asic
usage.
E
So
these
correspond
broadly
to
the
cases
that
we
studied
in
our
paper,
which
I
will
not
briefly
cover
for
interest
of
time,
but
we
can
check
it
in
our
paper
as
well.
E
So,
for
instance,
for
the
use
case
of
cover
channels,
we
are
able
to
scale
the
number
of
measured
flows
simultaneously
in
the
switch
by
150
times,
while
losing
only
a
few
percent
accuracy
loss
in
the
in
the
the
performance
of
the
task
itself
and,
for
instance,
we
could
scale
the
number
of
flows
measured
in
the
switch
by
over
30
times,
both
for
website
fingerprinting
and
botnet
detection,
while
losing
also
just
two
percent
accuracy
or,
for
instance,
two
percent
precision
in
the
performance
of
the
classifier
in
the
interest
of
time
again
I'll
just
cover
briefly,
our
results
for
cover
channel
detection.
E
So
one
thing
that
we
can
see
here
is
that,
for
instance,
depending
on
the
quantization
level,
we'll
be
using
less
and
less
memory
for
keeping
the
raw
packet
size
distribution,
which
also
allows
us
for
keeping
track
of
many
additional
flows.
So,
for
instance,
here
we
can
see
that
with
full
information,
we
will
require
3
000
bytes
to
keep
a
packet
size
distribution
for
just
a
given
flow,
and
this
will
allow
us
to
perform
this
cover.
E
We
are
still
able
to
detect
the
same
kind
of
covered
channels
with
92
percent
accuracy
and
using
just
the
representation
of
this
packet
size
distribution
that
only
takes
20
bikes
and
so
effectively.
We
are
having
an
increase
of
150
times
in
the
number
of
measured
flows.
E
We've
also
seen
that
the
full
length
profiler
is
able
to
find
a
good
quantization
and
rotation
parameters.
So
I'm
also
just
trying
to
show
you
here
that,
despite
other
configurations
that
may
achieve
a
higher
accuracy
in
the
task,
so,
for
instance,
using
a
quantization
level
of
two
without
any
truncation
would
give
us
96
accuracy.
E
But
if
you
use
our
profiler
to
choose
a
sensible
trade-off
between
the
size
and
accuracy,
we
can
actually
achieve
a
configuration
which
uses
a
quantization
level
of
4
and
a
truncation
level
of
10
features
that
still
achieves
94
accuracy,
so
just
2
percent
less
than
the
these
optimum
accuracy
ones.
E
We've
also
seen
that
full
length
imposes
only
a
small
overhead
on
the
switch,
so,
for
instance,
when
using
cpu
we've
seen
that
for
instantiating
our
botnet
detection
model,
which
was
actually
our
largest
model,
we
just
use
140
megabytes
out
of
a
total
32
gigabytes
of
ram.
We
just
required
5.6
megabytes
of
storage
and
we
just
wasted
around
200
microseconds
per
prediction.
E
However,
we
can
see
that
this
allows
full
length
to
support
the
flow
classification
in
the
control
plane
itself
and
as
for
the
asic
usage,
we
can
also
see
that
we
do
not
use
tcam
at
all
in
the
switch,
because
we
just
really
require
the
use
of
some
sram
to
keep
these
flow
markers
as
they
are
being
processed
and
computed
as
new
packets
are
flowing
through
the
switch,
and
we
also
do
not
use
many
computational
resources
of
the
asic,
which
also
means
that
full
lens
can
support
the
concurrent
execution
of
other
forwarding
behaviors.
E
E
So
I
invite
you
to
check
our
codes
and
before
closing
my
presentation,
I
would
like
you
to
keep
in
mind
these
three
big
takeaways,
which
is
that
flow
lens
is
the
first
traffic
analysis
system
for
these
generic
machine
learning,
based
security
applications
and
programmable
switches
that
is
able
to
collect
these
compressed
packet
distributions,
while
ensuring
both
classification,
accuracy
and
the
small
memory
footprint
of
these
full
markers,
and
it
is
also
able
to
classify
the
flows
directly
on
the
switch,
disregarding
any
additional
infrastructure
which
enables
us
to
save
communication.
Computing
storage
costs.
E
So
thank
you
I'll
be
available
for
answering
any
questions,
and
I
have
also
an
additional
slide
that
I
hope
that
can
spark
some
discussion
relating
to
some
other
killer,
apps
that
you
can
think
of
for
flow
lens
and
some
other
general
questions
of
whether
you
actually
deployed
p4
code
into
fino
and
what
difficulties
did
you
face?
Actually,
thank
you.
D
Actually,
I
don't
see
any
questions,
so
I
will
ask
people
to
move
their
questions
to
to
the
list.
Thank
you
very
much
yoga
and
thank.
D
Them
too,
so,
thank
you
so
very
much
for
for
living
with
that.
The
next
presentation
is,
if
I
had
my
my
things
well
done.
D
Okay,
I
have
too
many
too
many
things,
so
the
next
presentation
is
from
the
university
of
toronto.
Syed
syed.
Are
you
there.
D
No
actually,
the
next
one
is
har,
sorry
say
ed.
I
I've
skipped
over
her.
I
know
her
is
there
because
I
saw
him
in
this
in
the
in
in
the
chat.
So
please
harsh
it
it's
your
please.
H
Dick
okay,
hello,
y'all,
thanks
for
the
opportunity
to
present,
I
am
a
phd
student
at
georgia,
tech
and
I'd
be
presenting
our
work
on
data
management
over
geo,
distributed
edge,
computing
infrastructure.
This.
H
Umaki
show
ramachandran
so
at
the
edge
we
now
have
these
novel
applications,
which
are
springing
up
like
collaborative
driving
assistance,
distributed
camera
networks,
autonomous
drone,
swarms,
etc,
which
pose
new
stringent
requirements
on
the
infrastructure.
Some
of
those
requirements
are
enumerated
here,
like
they
have
geo-distributed
clients.
They
require
low,
latency
access
to
compute
services,
they
generate
data
at
a
very
high
rate
and
they
are
characterized
by
continuous
mobility
of
clients.
H
These
are
typically
good
use
cases
for
edge,
so
our
vision
of
edge
computing
is
the
following:
where
we
have
a
continuum
of
resources
ranging
from
very
proximal
resources,
neck
close
to
cell
towers,
all
the
way
to
central
offices
and
the
cloud,
and
these
resources
could
be
owned
by
the
same
or
multiple
providers.
H
So
the
applications
that
we
discussed
before
require
managing
data
because,
as
we
just
saw
they
they
discussed,
they
generate
a
lot
of
data
that
needs
to
be
handled.
So
what
are
they?
What
are
some
examples
of
data
so
for,
for
instance,
information
that
is
generated
by
one
application
could
be
used
by
others,
which
is
like
the
use
case
that
nokia
streaming
as
a
service
was
promulgating.
H
Another
use
case
is
time
series
wherein
data
can
be
stored
in
a
data
data
platform
which
can
be
retrieved
later
for
historical
queries
or,
for
you
know,
analytics.
Another
form
of
storing
data
is
to
store
the
state
of
processing
workflow,
which
is
done
in
stream.
Processing
platforms
like
flink.
H
In
addition
to
data,
which
is
you
know,
persistent.
We
also
deal
with
communication
between
entities.
For
instance,
drone
storms
need
to
communicate
with
each
other
to
coordinate
for
a
given
task.
That
also
holds
true
for
collaborative
driving,
where
multiple
cars
need
to
fuse
their
sensor
data
to
get
a
more
extended
view
of
the
world
for
better
obstacle
detection.
H
So
what
are
the
typical
solutions
which
are
which
have
been
used
in,
say
the
cloud
computing
space
for
data
management?
So,
if
you
think
about
key
value
stores,
which
is
suits
the
first
set
of
use
cases,
cassandra
timescale
db
and
influx
db
have
been
typical
platforms
which
have
been
used
for
maintaining
data
for
these
for
applications
for
real-time
messaging,
between
application
components,
developers
have
traditionally
relied
on
pub
sub
systems
like
pulsar
kafka
or
mqtt.
H
However,
at
the
edge
there
are
some
requirements
which
are
kind
of
novel
as
compared
to
data
center
data
management
platforms,
and
that
is,
we
need
to
provide
low,
latency
and
high
throughput
access
to
data.
The
the
the
platform.
The
data
platform
should
be
agile
in
such
and
adapt
to
workload
dynamism,
for
example,
client
mobility,
and
it
should
also
expose
well-known
semantics
to
clients,
so
that
you
know
application
development
is,
is
a
better
experience
for
developers.
H
So
if
we
just
use
the
cloud-based
platforms
on
the
edge,
there
are
a
number
of
problems
that
arise.
So
the
first
problem
stems
from
the
fact
that
the
topology
of
edge
is
highly
heterogeneous.
Systems
like
cassandra
or
pulsar,
use,
typically
use
a
hash
function
for
partitioning
data
among
various
nodes.
So
this
diagram
shows
the
way
cassandra
works,
wherein
it
takes
the
key
of
the
key
value
pair
that
it
needs
to
store
it
hashes,
the
key
and
based
on
the
hash
value.
It
assigns
it
to
multiple
nodes.
H
That
is
the
primary
and
the
secondary
replica.
But
this
process,
as
you
can
see,
is,
is
agnostic
to
the
topology
and
therefore
can
perform
very
poorly
in
a
geo
distributed
edge,
setting
the
second
problem
with
edge
that
the
challenge
with
edge
is
that
the
geo
distribution
is
very
dense
as
compared
to
multi
data
center
deployments
that
we
typically
see,
for
you
know,
databases
and,
and
therefore
granularity
at
the
level
of
racks
is
not
sufficient,
because
we
would
need
to
also
attribute
location
or
some
kind
of
network
proximity
information
into
our
data
data
distribution
policy.
H
And
finally,
there
is
no
support
for
monitoring,
client
mobility,
and
thus
these
solutions-
they
don't
even
they
don't
have
any
mechanisms
to
handle
workload,
dynamism
that
are
peculiar
to
edge
computing.
H
So,
in
our
area
of
research
we
try
to
build
edge
friendly
data
management
solutions
and
which
tackle
the
for
the
above
challenges,
and
in
this
talk
I
will
be
briefly
going
over
two
systems
that
we
have
implemented,
which
are
catered
to
different
classes
of
data
management
and
how
we
incorporated
edge
friendly
mechanisms
into
them.
In
both
cases,
we
assume
that
the
data
management
platform
is
deployed
on
multiple
edge
sites
such
that
there
is
one
platform
which
is
running
on
top
of
a
continuum
of
edge
resources.
H
This
platform
provides
a
user
interface
that
is
similar
to
typical
key
value
stores,
wherein
you
can
have
keys
and
values,
and
in
addition,
the
developer
can
specify
the
location
of
the
data
item
and
the
timestamp
of
a
data
of
that
data
items.
This
is
a
spatial
temporal
extension
to
typical
time
series,
databases
and
the
assumption
of
this
work
is
that
we
are
dealing
with
situation.
Awareness,
applications
like
autonomous
cars
or
sorry
autonomous
drone,
swarms
or
navigation
assistance,
wherein
low
latency
data
is
required
by
clients
which
are
in
proximity
to
the
data
item.
H
That
is,
we
cannot,
we
don't
guarantee
low
latency
to
an
arbitrary
data
item,
but
only
to
those
which
are
close
to
the
clients
and
we
implemented
data
fork
by
extending
apache
cassandra.
H
So
before
we
dive
into
the
design
choices,
let's
quickly
go
over
the
sources
of
latency
in
zero
distributed
key
value
stores.
The
first
source
of
latency
is
the
selection
of
replicas.
So,
as
we
just
discussed,
cassandra
uses
a
hash
function
which,
in
this
case,
is
consistent,
hashing
to
determine
the
location
of
replicas
for
a
given
data
item,
so
that
is
not
aware
of
the
network
topology
and
therefore
it
can
be
highly
suboptimal
in
terms
of
latency.
H
In
addition
to
that,
these
databases,
in
order
to
provide
consistency,
they
perform
replication
in
a
synchronous
manner
and
since
even
the
all
the
replicas
are
not
close
to
the
client.
It
results
in
higher
latency
to
perform
reads
and
writes
so
these
two
sources
of
latency
drive
us
to
make
the
design
decisions
for
data
form.
The
first
is
that
we
incorporate
location
based
data
partitioning
the
idea.
The
objective
of
this
design
choice
is
to
keep
data
close
to
the
potential
users.
H
H
This
the
we
modify
the
hash
function,
which
has
been
used
by
cassandra
to
convert
a
data
item
to
the
partition
key,
which
is
used
to
figure
out
which
replicas
to
select
for
that
data
item.
H
You
know
hash
ring
mechanism
in
cassandra,
given
that
now
the
output
of
the
hash
function
is
location,
sensitive,
and
this
allows
us
to
place
data
items
closer
to
the
location
that
that
data
item
corresponds
to
so,
in
addition
to
location
based
partitioning
the
other,
we
address
the
other
source
of
latency,
which
is
synchronous,
replication
for
high
consistency.
H
So,
to
do
this,
we
utilize
spatial
temporal
locality
in
queries,
so
going
back
to
our
assumption.
A
smart
car
is
interested
in
recent
events
in
its
vicinity
and
we
provide
consistent
access
to
spatial
temporally
relevant
items.
That
is,
we
ensure
that
the
read
and
write
quorums
overlap.
H
So,
given
that
we
have
now
the
luxury
to
maintain
two
types
of
replicas,
we
maintain
strongly
consistent
replicas
in
vicinity
of
of
the
data
item,
so
that
we
can
provide
low
latency
access
to
clients
for
whom
that
data
item
is
relevant
and
we
also
maintain
remote
replicas,
which
are
eventually
consistent
and
for
our
data
items
which
are,
and
we
can
provide
fault
tolerance
from
correlated
failures,
because
it
is
more
likely
in
an
edge
setting
for
sites
to
fail
in
a
geographically
correlated
fashion.
H
So
having
a
remote
replica
helps
in
that
case,
although
it's
not
strongly
consistent
with
the
in
vicinity,
replicas.
H
So
we
show
that
such
optimizations
provide
such
locality.
Optimizations
provide
significant
improvements
in
reads
and
write
latencies,
so
we
experiment
with
a
data
store
infrastructure
where
we
have
four
data
store
nodes
which
are
local
in
atlanta,
and
there
is
a
variable
number
of
remote
data
stored
nodes
which
are
which
are
spread
across
the
us,
and
the
emulation
has
been
performed
using
container
net,
which
is
similar
to
millionaire,
but
that
uses
docker.
H
The
query
is
a
range
query
that
selects
all
vehicles
within
a
five
kilometer
radius
that
we
detected
ten
minutes
ago,
and
we
see
that,
as
you
increase
the
scale
of
the
data
store
by
adding
more
remote
nodes,
the
access
latencies
increase,
and
that
is
because
cassandra
for
cassandra-
and
that
is
because
cassandra
does
not
is
not
aware
of
the
network
topology
and
therefore
it
places
replicas
in
an
agnostic
fashion
which
results
in
high
data
access
latencies.
H
However,
since
data
fog
is
completely
aware
of
the
location
of
nodes,
it
is
able
to
consistently
maintain
the
access
latencies
at
the
same
level.
As
you
know,
a
very
small
scale,
cluster.
H
H
So
e-pulsar
is
a
geo-distributed
public
subscribe
system
and
it
follows
a
similar
interface
to
kafka
and
pulsar,
which
are
also
commonly
known
by
subsystems
wherein
producer
clients,
publish
the
topics.
Consumers
consume
from
topics
and
brokers
are
system
entities
that
host
those
topics
and
e-pulsar
allows
developers
to
specify
per
topic.
Latency
constraints,
that
is
the
end-to-end
public
subscribe
latency,
should
be
below
a
developer
specified
threshold.
H
So
what
are
the
sources
of
latency
in
typical,
published,
subscribe
systems
so
as
before,
since
pulsar
also
relies
on
consistent
hashing
for
distributing
topics
to
brokers,
it
does
not
take
into
account
network
topology
and
that
results
in
high
client
to
broker
latency,
that
is
the
latency
between
the
producer
and
broker,
as
well
as
between
consumer
and
broker,
is
unpredictable
and
can
be
high
because
of
the
heterogeneous
nature
of
the
edge.
H
So,
in
order
to
solve
this,
we
make
two
main
contributions.
We
first
incorporate
network
coordinates,
which
is
a
well-known
decentralized
p2p
protocol
for
a
scalable
inter
node
latency
estimation
to
estimate
client
broker
latencies
without
much
overhead,
and
secondly,
we
incorporate
the
network
coordinates
into
the
broker
selection
algorithm
so
that
we
can
minimize
the
worst
case,
end-to-end
latency.
H
In
addition
to
that,
this
placement,
or
this
selection
of
brokers,
is
adaptive
and
it
can
adapt
to
continuous
client
mobility.
We
implemented
e-pulsar
by
extending
apache
pulsar,
so
first
for
scalable
client
broker
latency
estimation.
We
run
a
network
coordinate
agent
which
is
running
the
well-known
vivaldi
protocol
on
all
system
entities,
which
is
the
producers,
consumers
and
the
brokers
as
the
implementation
we
use
surf
network
coordinate
agent
as
as
the
building
block
for
this
for
this
entity.
H
So
these
network
coordinate
agents
they
interact
with
each
other
and
then
they
converge
on
a
network
coordinate
in
a
high
dimensional
space
such
that
the
distance
between
two
network
coordinates
gives
you
the
latency
between
those
two
nodes.
So
it
is
a
very
scalable
way
of
estimating
inter
node
latencies.
H
So
then,
once
each
system
entity
knows
its
network
code
in
it,
the
clients
report
their
current
code
in
it
to
the
to
the
serving
broker
and
broker
aggregates
these
monitoring
pieces
of
information
from
all
clients,
and
then
they
send
it
to
the
control
plane
where
we
use
this,
for
you
know
initiating
topic
migration
if
necessary.
H
So
the
worst
case,
probably
subscribe,
latency
can
be
visualized
as
the
maximum
distance
between
the
network
coordinate
of
any
producer
to
the
current
broker
to
the
farthest
consumer
from
the
broker.
So
this
distance
gives
you
gives
us
an
estimate
of
the
worst
case.
Public
subscribe
latency,
which
is
used
by
the
control
plane
to
decide
if
it
is
greater
than
the
threshold
or
not,
and
if
it
is
a
topic
migration
is
triggered
and
the
new
broker
for
that
topic
is
determined
by
a
latency
aware,
broker
selection
algorithm.
H
So
for
that
we
we
use
the
an
aggregate
of
the
producers
network
coordinates
which
is,
namely
the
centroid.
In
our
case,
we
use
the
centroid
of
producer
coordinates
and
the
centroid
of
consumer
coordinates
to
estimate
the
worst
case,
latency
that
can
be
experienced
that
can
be
provided
by
a
candidate
broker
and
we
select
the
one
that
meets
the
latency
constraint.
H
So
we
show
our
evaluation
I'll
be
quick
with
this.
So
this
is
a
uav
swarm
scenario
where
there
are
multiple
drones,
which
are
talking
to
each
other.
Talking
to
the
leader
and
the
leader
to
the
follower.
By
using
the
pub
sub
interface,
we
evaluate
this
in
a
city
scale,
infrastructure
with
multiple
sites
and
on
the
bottom,
you
can
see
a
time
series
of
communication
latency
for
each
drone
swarm.
H
So
in
conclusion,
we
design
est
friendly
data
management
solutions
that
that
solve
challenges
post
by
the
edge
on
contemporary
data
management
platforms,
and
we
show
how
these
two
work
for
key
value
stores
and
pub
sub
systems
and
following
are
the
references
if
you
would
like
to
check
them
out,
and
that's
all
for
this
talk
thanks
for
listening,
I
can
take
any
questions
that
you
may
have.
K
K
Replica
and
the
other
is
synchronization
replicas
with
consistency,
so
I
think
that
both
can
be
potentially
improved
by
innovation
inside
the
network.
But
what
is
the
major
one
in
between
this
from
end
to
end?
Point
of
view
so
which
which
length
is,
is
a
major
major,
latency,
synchronization
or
select
the
replica
make
that
a
decision.
H
Yes,
so
so
the
the
major
source
of
latency
is
the
synchronous
replication,
but
that
is
tied
to
the
selection
of
the
replicas,
because
it
depends
on
where
the
replicas
are
located.
So
we
need
to
to
to
so,
if
you,
if
you
don't,
do
the
the
selective
replication
in
that
case,
you
pay
the
penalty
of
going
to
the
farthest
replica
and
that
also
imposes
high
latency
on
the
overall
access.
G
Please,
hey
hashid
thanks
for
the
presentation,
so
in
general
I
think
you
are.
You
are
under
a
good
track,
so
I
think
there
is
good
potential
in
you
know
finding
out
how
this
relevant
application
layer
systems
and
their
interactions
can
be
better
supported
by
the
network.
G
G
H
On
that,
yes,
I
totally
appreciate
your
question,
so
that
is
one
reason
why
we
move
from
a
geographical
location
based
approach
to
a
more
you
know:
network
coordinate,
oriented
approach
because
by
using
network
coordinates,
it
is
agnostic
of
location
and
it
gives
you
proximity
in
terms
of
round
trip
time.
H
We
don't
consider
hops,
because
we
don't
assume
that
as
edge
provider,
you
would
know
about
the
internals
of
a
network
of
the
network
say
you
are
an
edge
provider
like
micro
edge,
which
is
deployed
on
pairing
sites,
so
we
just
care
about
end-to-end,
rtp
and
based
on
that,
we
can
make
these
placement
decisions
yeah,
yeah,
okay.
D
Any
other
question:
okay,
so
then
I
thank
you
very
very
much
for
this
presentation
and
then
now
we're
back
to
the
next
presentation.
So
please
say
it.
E
Okay,
so
the
topic
of
my
talk
today
is
hierarchical
data
storage
and
processing
on
the
edge
of
the
network.
This
was
a
collaborative
work
with
at
university
of
toronto.
This
was
my
phd
work,
I'm
with
some
folks
at
at
research.
E
E
However,
current
networks
are
not
able
to
support
next
generation
applications
that
require
low
latency,
such
as
ar
vr
applications,
wearable
devices
and
safety,
critical
applications
or
applications
that
produce
large
volumes
of
data
that
can
overwhelm
the
network,
such
as
video
analysis
and
ao
iot
devices,
and
they
also
don't
support
other
applications
that
have
other
requirements,
such
as
specific
privacy
requirements
or
exact
location,
detection
or
scalability.
E
E
We
assume
that
edge
computing
networks
are
composed
of
a
collection
of
hierarchical
data
centers,
as
you
can
see,
in
the
figure
and
with
edge
computing.
Additional
services
could
be
provided
to
applications
such
as
the
location,
authentication,
services,
mobility
management
and
so
on,
so
to
emulate
the
success
of
web
applications
on
the
cloud.
We
should
understand
why
these
applications
have
worked
so
well
in
the
cloud
and
what
we
see
is
generally
that
many
web
applications
are
partitioned
into
independent
state
handlers
and
each
request
is
processed
by
a
different
handler.
E
Now,
in
this
model,
requests
don't
necessarily
go
to
the
same
server,
but
what
enables
this
model
to
scale
is
a
short,
a
shared
storage
layer
where
all
handlers
can
share
states.
E
Now,
as
I
said,
our
idea
is
to
apply
the
same
principle
by
enforcing
a
clear
separation
between
computation
and
state
for
applications,
and
we
propose
cloud
path
that
is
a
new
model
for
deploying
and
executing
third-party
applications
on
the
edge
of
the
network
in
cloud
path.
Application
developers
organize
their
applications
as
a
collection
of
stateless
handlers
and
cloudpath,
deploys
and
executes
those
functions
on
demand
over
the
hierarchy
of
data,
centers
replication,
replicating
application
and
code
data.
E
So
each
cloud
path,
node
that
is
deployed
on
a
separate
data
center,
contains
the
following
modules:
a
path
execute
that
executes
functions
in
an
isolated
environment
path,
deploy
that
deploys
the
applications
on
demand
path.
Writing
that
routes,
requests
to
running
functions,
a
path
store,
the
common
storage
layer
responsible
for
moving
application
data
in
code
and
finally,
path
monitor,
which
is
the
common,
a
common
monitoring
platform
now
to
show
how
cloud
path
works.
E
We
present
an
example,
a
concern
application
that
controls
a
swarm
of
drones
over
a
city
that
includes
three
functions:
the
drone's
carrier,
camera
and
the
application
includes
an
object,
avoidance
function
and
a
function
that
records
flights
info
and
a
function
that
receives
sensory
data
and
makes
decisions
about
the
flight
path.
So
the
application
developer
may
require
the
object.
E
Avoidance
functionality
to
be
close
to
the
drones
because
of
the
lower
latency
and
bandwidth,
and
when
a
new
request
comes
onto
the
function,
it
goes
on
to
the
edge
cloud
path,
copies
the
application
code
and
executes
the
application
on
that
on
that
node.
It
also
runs
the
code
on
its
parents
all
the
way
to
the
cloud.
E
Similarly,
the
developer
may
want
f2
to
run
on
the
cores
where
data
from
different
drones
can
be
aggregated
and
f1
to
stay
on
the
cloud
because
of
the
infrequent
latency
insensitive
nature
of
the
requests
on
each
node.
Multiple
functions
from
different
applications
can
run
on
the
same
time,
but
the
code
and
data
application
is
is
only
on
demand.
E
So
if
we
can
have
another
application
app
too,
that
runs
on
the
cloud
and
can
be
replicated
on
core
two
on
demand.
If
a
request
comes
in,
of
course,
you
so
compared
to
running
an
application
on
the
cloud.
There's
a
significant
improvement,
as
one
might
expect
in
terms
of
request
response
time
when
running
an
application
closer
to
the
user.
In
our
you
know,
in
our
experiments
we
deploy
a
face,
detection
application
using
cloud
path,
and
the
results
show
that
it
has
a
big
effect
on
resource
and
code
placement.
E
What
a
big
effect
resource
and
code
placement
can
have
on
query
response
time
and
potentially
throughput.
However,
one
thing
that
we
haven't
really
so
I
made
this
slide
for
this
talk.
We,
what
something
that
we
can
significantly
improve
on
is
is
is
routing
overhead
in
cloud
path.
We
use
information
in
an
http
header,
so
it's
layer,
7
routing,
grout,
requests
related
execution
points.
However,
you
know
this
can
be
significantly
improved
now.
Our
second
line
of
code
of
work
is
is
pathstore.
E
E
E
Now
a
path
store
is
composed
of
a
hierarchy
of
independent
object
stores
and
in
our
implementation
each
node
runs.
The
cassandra
ring
a
full
cassandra
rain,
which
means
that
we
can
have
horizontal
scaling
within
a
data
center.
Essentially,
e
passer
is
responsible
for
replicating
data
between
these
different
object
stores
through
background
processes.
E
Now
it
supports
eventual
consistency.
However,
our
extension,
which
I
will
talk
next
about
called
session,
store,
supports
session
consistency.
Read
your
own
rights
monotonic
reads
and
writes
for
users
and
devices
that
use
this
service
so
in
path
store.
Then
the
node
at
the
root
of
the
hierarchy
contains
all
persistent
data
and
all
other
nodes
act
as
temporal
partial
replicas
data
is
replicated
on
demand.
E
We
use
a
sql-based
interface
and
in
our
implementation
we
use
cassandra
as
as
for
each
ring,
and
we
have
roll
level
replication
now
as
an
example
suppose
that
we
have
an
application
that
has
a
table
called
marbles
where
the
color
of
the
marble
is
a
primary
key.
Now
assume
that
some
data
already
exists
in
the
cloud
node.
If
an
user
executes
the
query
selector
for
marbles,
where
color
equals
blue
on
h3,
because
h3
does
not
have
the
data,
the
query
is
executed
on
the
parent
node
as
core
2
also
does
not
have
the
data.
E
E
A
similar
process
is
repeated
when
h1
does
select
all
from
table
marbles
and
data
is
replicated
on
core
one.
Then
then
this
is
received
on
h1.
E
However,
when
h2
executes
a
sub
query
selects
all
four
marbles
where
color
equals
green,
rather
than
going
all
the
way
to
the
cloud
data
is
obtained
from
core
one.
E
In
the
case
of
writes
when
an
object
is
written
locally,
it's
very
periodically
pushed
all
the
way
to
the
cloud.
So,
as
I
said,
the
cloud
contains.
E
So
the
results
in
the
red
marble
for
the
red
marble
automatically
is
replicated
on
co1
and
h1.
E
Now
edges
and
intermediate
nodes
in
path
store,
as
I
said,
act
as
cache
when
data
exists
on
them
right,
reads
and
writes
fast
in
this
specific
experiment.
We
examine
how
long
it
takes
to
answer
a
query
on
the
edge
or
core
and
cloud
nodes
when
data
is
cached
on
local
paths
or
nodes,
which
is
the
orange
bars
and
compare
it
to
when
data
does
not
exist
on
local
nodes
and
has
to
be
fight.
E
The
cloud
which
is
the
blue
bars
and
we
also
compare
it
to
a
scenario
where
data
has
to
be
refreshed
from
the
cloud
node
without
any
paths
or
it's
just
just
one
single
database
on
single
cassandra
database.
So
you
can
see
the
benefits
for
reoccurring,
queries.
E
Now
our
next
work
is
on
providing
stronger
consistency,
guarantees
for
the
edge
data,
storage,
layer,
edge
users
and
devices
are
commonly
mobile
and
can
move
between
data
centers.
This
means
that
their
data
has
to
move
with
them
in
a
consistent
manner
for
many
applications.
E
In
this
figure
we
have
two
scenarios
where
the
session
consistency
for
a
mobile
user
is
broken.
For
example,
a
client
writes
a
value
on
a
server
on
edge.
One
then
moves
to
h2
but
reads
an
old
value.
So
what
we
want
to
provide
in
this
line
of
work
is
video
and
writes
and
monotonic
return
rights.
E
Again,
we
have
row
level
replication
so
as
an
example,
a
user
on
h1
executes
two
queries
and
then
moves
to
h3
so
select
offer
models
and
insert
screen
marble
into
the
marbles
table.
Then
it
moves
to
page
three
one
approach:
the
pajama
approach
is
to
move
all
application
in
data,
including
the
stamps
table
to
h3.
E
All
our
alternative
is
only
to
move
data
related
to
the
session,
which
is
some
rules
on
the
marvels
table
right
three,
so
all
of
the
data
is
fetched
from
h1
directly,
but
it's
only
the
data
that
the
session
has
accessed
now.
If
there's
some
data
already
existing
on
h3,
we
only
need
to
move
the
newer
data,
so
delta
list
optimization
only
moves
newer
data
around.
E
We
also
have
an
optimization
for
when
a
user
moves
to
neighboring
node
and
that's
in
that
case
only
data
that
was
read
or
written
on
h1
and
has
not
been
updated
on
core
one,
which
is
the
parent,
is
sent
to
h2,
as
the
other
data
can
be,
can
be
queried
from
core
one.
So
if
the
application
needs
the
blue,
the
blue
marble
rather.
C
E
E
So
each
session
in
sessions
or
is
identified
by
token,
which
we
call
an
s
token
it's
encrypted
and
signed
to
prevent
forging
or
misrepresentation
and
what
constitutes
as
a
session.
We
leave
that
to
the
application
developer
to
keep
track
of
data
related
to
a
session
command.
Cache
is
added
to
each
path
so
replica
that
stores
all
the
statements
that
were
executed
on
behalf
of
the
session.
E
E
E
Also
even
for
eventual
consistency.
Path
store
needs,
synchronized,
clocks
between
data
centers.
This
is
again
a
service
that
I
think
that
the
network
can
provide
so
that
we
are
sure
that
the
the
clocks
are
synchronized.
E
We
can
assume
that
there's
a
gps
clock
on
each
data
center,
but
even
if
there
was
not,
there
was
nothing
there.
I
think
that
the
network
can
provide
this
service
and
I
also
think
that
we
can
move
entirely
or
create
a
service,
a
locking
service
for
data
consistency.
And
then,
if
there
is
such
a
service
inside
the
network
itself,
then
better
guarantees
can
be
provided
by
a
data
source.
C
D
Always
happens
anyway.
Edgar
are
you
still
there.
D
I
L
L
It's
more
about,
I
would
say,
research,
questions
for
us
for
the
future
and
how
we
have
a
vision
so
where
how
the
things
are
going
to
be
transforming
the
way
how
the
network
is
today
and
what
it
should
be
addressed
in
the
future.
L
This
is
part
of
some
work
that
was
done
in
a
crowdsource
crowdsourcing
way
in
ericsson,
research.
By
pretty
much
all
the
research
areas
we
have
and
where
everyone
with
their
knowledge
and
their
let's
say,
skills
in
in
their
area
and
expertise
they
have
they
contribute
and
then
provide
this
kind
of
info
information
and
input,
and
then
what
I
want
to
show
you
is
how
we
believe
that
these
intelligent
machines
are
going
to
evolve
and
how
the
network
it
will
evolve
with
it
so
to
to
put
it
a
bit
on
context.
L
One
one
of
the
things
we
were
kind
of
we
were
considering
is:
what
are
the
things
that
are
driving
these
changes
and,
of
course
we
have
the
weakest
connectivity
of
the
main
main
thing
where,
if,
when
everything
gets
connected,
then
it
gets
the
power
to
get
exposed
to
everywhere
everywhere
else,
then
we
have
iot
and
all
the
devices
that
are
being
interacting
with
each
other
and
with
humans,
and
then,
when
we
add
on
top
of
that
ai
and
then
all
the
capabilities
that
ai
are
bringing-
and
I'm
not
only
talking
about
machine
learning,
but
also
the
trying
to
almost
mimic
human
behavior
and
even
further
than
that.
L
So
I
mean
not
only
becoming
machines
with
human
capabilities
for
even
capabilities
that
goes
beyond
what
the
humans
have.
L
Then
we
have
the
the
cloud
and
age
that
are
coming
then
also
the
truth-worthiness
and
how
we
can
start
to
trust,
not
only
data
but
also
processes
and
machines,
and
then
we
have
the
robotization
the
new
ways
of
interaction
with
machines,
so
how
the
humans
are
able
to
communicate
with
with
other
machines
and
then
finally,
we
have
the
new
computing
paradigms:
alternative
materials
and
on
energy
technologies,
so
that
are
becoming
more
and
more
common
in
in
our
everyday
lives,
and
they
are
starting
to
pair
me,
these
10
forces
and
together
they
are
kind
of
leading
or
creating
this
kind
of
path
which
we
call
the
technology
journeys.
L
Then,
to
put
it
a
little
bit
on
context
to
coin
and
and
what
we
do
in
coin,
rg,
the
the
network
should
match
or
will
match
this
evolution
of
the
machines.
So
the
machines,
as
we
know
them
today,
a
refrigerator,
a
toaster
or
very
simple
machines,
even
our
cars,
it.
It
will
evolve
to
something
much
more
complex
and
with
highly
it
becomes
more
autonomous
and
it
will
become
also
more
generic.
L
So
our
device
will
stop
being
a
specialized
thing,
but
it
will
actually
start
to
do
more
things
that
it
was
designed
to
do
as
a
initial.
In
initial-
let's
say
a
purpose
then
also
this
will
mean
that
that
we
will
have
all
this
customization
going
around
because
at
the
same
time
that
the
things
are
generic,
they
are
also
have
to
address.
So
many
new
use
cases
adapt
to
what
is
happening,
that
this
kind
of
need
for
customization
is
something
that
will
be
there,
but
still
we
require
this
interoperability.
L
L
Additionally
to
that,
then
we
have
this
empowering
the
devices
by
the
network
by
discoveries
exposure
trolls
of
organization,
things
that
we
know
that
the
network
could
already
do,
but
even
beyond
that
to
when
everything
becomes
intelligent.
So
then
there
will
be
this
need
for
mediation
and
arbitration
of
these
kind
of
agents
that
are
running
in
the
machines,
intelligent
agents,
then.
Finally,
we
could
even
question
if
the
network
is
really
relevant
in
the
future,
when
you
have
all
these
ai
talking
to
each
other
and
then
they
might
even
think
like.
L
Why
should
I
use
the
network
services?
Maybe
I
can
just
create
my
own
network
services
since
I'm
so
intelligent,
so
I
mean
we
could
think
to
that
extreme.
But
I
think
it's
it's
the
task
of
the
network
to
keep
the
relevance
and
the
improvise,
the
the
incentive
so
that
all
this
intelligent
build
on
top
of
what
the
network
can
produce
and
not
bypass
it.
L
So
this
in
in
a
nutshell,
is
actually
maybe
the
summary
of
what
you're
gonna
hear,
but
I
thought
it
was
more
interesting
to
maybe
put
it
here
in
the
beginning
and
then
go
actually
to
the
journey,
so
the
journey
I'm
to
talk
is
called
connected,
intelligent
machines-
and
this
is
a
one
of
the
examples
of
what
we
think
genetics
and
it
will
be
happening
for
six
years
or
the
road
to
6e.
L
So
we
are
talking
about
way
in
the
in
the
to
the
future,
and
then
we
can
start
with
basically
two
aspects:
one
is
how
the
machines
are
going
to
evolve,
so
the
machines
we
think
they
will
evolve
from
what
we
have
today,
which
are
machines
that
can
have
multiple
sensors,
has
multiple
different
type
of
special
ways
to
to
collect
data,
but
at
the
same
time
they
are
quite
specialized
in
one
domain,
so
they
are
not
very
generic
they.
L
L
Where
you
put
it,
then
what
we
think
is
that
those
kind
of
robots
and
those
kind
of
machines
will
evolve
to
something
where
the
environment,
depending
on
the
environment
and
the
sensing
of
the
environment,
the
machines
can
adapt
and
can
take
intent
instead
of
code
for
pro
provide
results.
So
today
the
machines
they
require
to
be
coded
so
that
they
actually
do
what
what
you
want
them
to
do.
L
So
one
machine
can
maybe
take
over
or
understand
what
other
machine
can
do
and
then
use
it
for
the
purpose
that
that
machine
has
the
objective,
then
we
can
take
it
still
further,
and
I
think
I
have
been
talking
about
mainly
machines
that
are
with
an
intelligence
that
is
centralized
is
in
one
place,
but
then
imagine
that
those
centralization
then
disappear,
and
then
you
cannot
actually
call
one
machine
that
that
is
in
one
place,
but
it's
actually
distributed
in
multiple
places
and
then
that's
what
we
call
this
decentralized
intelligence,
where
multiple
machines
may
actually
work
together,
maybe
in
a
swarm
way,
and
they
could
resolve
problems
that
otherwise
they
couldn't
solve
by
themselves.
L
Then
the
next
generation
could
be
something
where
the
machines
can
actually
rewrite
their
own
code.
They
could
even
come
to
do
their
own
training
and
then
even
do
their
own
life
cycle
management
of
software
and
decide
what
components
they
need
to
accomplish
the
tasks
that
they
have
been
asked.
L
Also,
these
machines
could
even
change
their
own
architecture
and
actually
in
there
have
been
some
studies
and
some
work
where
machines
are
designed
in
other
machines.
So
all
this
is
part
of
the
journey
and
finally,
we
could
say
about
that:
the
machines
become
more
general,
so
they
move
from
the
domain.
Specific,
let's
say
feel
to
something
where
they
can
actually
handle
problems
that
on
and
they
could
handle
things
or
situations
that
are
in
multiple
domains,
and
then
these
multiple
domains
could
become
something
almost
in
the
human
level.
L
So
we
could
say
that
those
machines,
maybe
in
the
future,
could
even
pass
an
iq
test
that
they
keep
a
small
kid
of
less
than
10
years
would
pass
so
then,
more
more
or
less.
In
that
level,
we
expect
that
the
machines
could
could
reach,
maybe
by
2030,
so
that
is
kind
of
the
the
the
scope
of
this
journey.
L
Then
the
network
should
need
to
match
this
evolution
of
these
machines,
so
we
will
have
the
data
services
that
the
machine
would
require
to
to
to
need
for
their
specialized
functions
and
then
that's
what
we
have
today
pretty
much.
L
We
have
all
these
data
oriented
ai
that
is
been
feeding,
mainly
algorithms,
and
then
we
have
all
this
evolution
where
we
go
to
discover
the
cyber
war
and
navigation,
how
the
network
can
provide
apis
or
can
provide
different
services
that
allows
you
to
find
what
exactly
are
the
needs
that
that
that
the
machine
needs
to
fulfill
and
also
we
have
these
network
services,
which
are
more
specific
for
machines
instead
of
of
humans,
because,
if
we
think
about,
if
we
think
about
that
today,
the
today's
situation,
the
networks
are
trying
to
fulfill,
mainly
the
humans
human
needs.
L
Then
what
I
was
talking
about
the
incentive
is
that
the
network
should
actually
try
to
predict
what
are
the
things
that
the
machines
will
need.
L
That
needs
to
be,
for
example,
avoid,
or
it
could
be
also
that
we
need
to
do
some
arbitration
or
some
kind
of
mediation
between
all
these
kind
of
different
systems
that
might
have
even
conflicting
goals.
Sometimes
then,
in
between
there
will
be
a
a
bunch
of
things
that
that
feels
off
also
to
to
this
journey.
I
will
take
them
in
the
next
slide,
but
basically
they
are
about
interoperability.
L
Then
the
a
lot
of
what
I
have
been
talking
with
decentralization
has
to
do
also
with
system
of
systems
where
machines
will
basically
get
together
and
we
expect
that
they
will
self-organize
and
then
we'll
create
these
autonomous
systems
where
they
can
achieve
goals
that
otherwise
they
couldn't
achieve
them
if
they
would
be
alone
and
then.
L
Then,
of
course,
you
can
ask
me
how
this
all
gets
together
and
then
that's
what
I
will
attempt
to
to
explain
in
this
slide.
So,
basically,
if
we
take
from
each
of
the
different
what
we
call
stepping
stones
from
all
of
these
subjourneys,
so
then
we
can
put
them
in
in
this
way.
So
for
the
first
generation
of
machines,
then
we
need
this
still.
There
will
be
a
lot
of
this
human
machine
assistance.
This
collaboration,
then
we
need
to
do
this
governance
across
the
the
the
machine
life
cycle.
L
So
still,
we
need
to
take
care
of
those
things
in
the
beginning,
but
then
towards
we
go
to
the
the
more
evolved
machines,
so
new
things
are
are
needed
like,
for
example,
semantic-driven
communication
in
the
in
the
interoperability
part,
so
how
we
actually
make
the
machines
can
understand
each
other,
especially
when
they
are
learning
from
other
machines
and
and
then
how
they
can
expose
their
capabilities
so
that
the
other
machines
can
actually
utilize
them.
L
And
then
we
also
can
see
these
kind
of
dynamic
ways
of
interacting
so
how
a
machine
decides
to
interact
with
other
and
then
in
in
one
way,
create
this
kind
of
system
of
systems,
and
then
finally,
we
also
have
to
take
care
of
that.
Whatever
thing
the
machine
does,
it
can
be
explained,
and
it
should
be
a
way
that
we
can
actually
debug
and
understand
how
a
decision
or
how
something
that
the
machine
is
is
doing.
It
can
be
traced
to
to
certain
certain
things.
L
This
environment
and
intend-driven
machines
are
quite
actually
quite
related.
Also
to
this
machine
learning
from
other
machines
and
then
there
we
also
the
thing
that
is
bringing
forward
is,
for
example,
this
intent
and
natural
language
and
natural
human
natural
way
of
expressing
interactions.
L
Then,
when
we
are
talking
about
decentralization,
then
we
have
this,
for
example,
conditional
autonomy
where
sometimes
the
humans
are
not
in
full
control,
but
it
might
be
that
the
machine
take
control,
total
control
in
certain
situations,
for
example
a
car
that
is
in
a
highway.
It
might
be
in
this
conditional
autonomy.
L
D
I
think
we
have
edgar.
Can
you
please
conclude.
L
Okay,
then
we
have
these
two
lightest
ones
which
are
basically
about
the
regenerating
machines
and
then
these
cognitive
systems
and
then
there's
some
interesting
part-
is,
for
example,
how
the
machines
are
becoming
so
societally
aware
and
how
they
also
are
kind
of
become
some
kind
of
legal
entity
and
then
how
the
network
could
should
support
that
when
these
things
happen,
we
have,
for
example,
have
the
right
logs.
They
have
the
right
tools
to
handle
that
kind
of
evolution.
L
Then
what
I
wanted
to
say
is
how
this
kind
of
matched
together
with
the
network
and
the
communication
is
that
we
actually
extend
this
kind
of
stacks,
where
we
are
in
the
network
in
the
communication
part
to
go
further
to
what
we
call
agent
interactions
so
how
these
devices
will
talk
to
each
other,
and
then
there
are
different
levels
in
the
stack
that
will
be
actually
extended
towards
the
actual
model,
where
we
only
end
in
an
application
level.
Of
course
we
can
take
it
also
in
that
in
that
level.
L
But
then
there
will
be
some
functions
and
like
cycle
life,
cycle
management,
orchestration
and
policy
handling
that
need
to
be
taken
in
consideration
for
that
kind
of
intelligence
that
the
device
has
and
then
on
top
of
that,
just
you
will
have
the
application
so
actually
it
this
is.
This
stack
is
not
that
is
on
top
of
the
applications,
but
maybe
something
in
between
still
the
application
layer.
L
Well,
that's
all
my
last
slide.
My
last
slide,
so
please,
if
you
have
any
questions,
I'm
happy.
D
To
move
the
questions
to
the
chat
for
people
who
had,
I
would
say,
draft
overviews
will
have
time
for
dirks
and
dirk.
You
can
make
it
kind
of
fast
and
hey
mount.
Maybe
you
will
just
have
time
just
to
show
one
slide
and
just
summarize
really
fast
what
you
wanted
to
tell
us
and,
like
I
said,
I
think
you
have
to
maybe
reconfigure
your
drafts
to
make
sure
that
they
they
they're
looking
at
research
and
not
ietf
so
dirk.
J
J
Yeah
good,
just
maybe
I
was
the
only
one
noticing
that,
but
him
and
slides
are
actually
not
actually
not
referenced
in
the
agenda.
It's
three
times
the
same
slide
hours.
Let's
listen
there.
H
J
The
ad
time
for
our
slide,
but
it's
maybe
overdoing
it
a
bit
so
just
very
quickly
through
the
challenges
we
started
also
looking
at
ongoing
efforts
in
relevant
technology
areas.
That's
probably
what
you
meant
about
not
looking
towards
the
itf,
where
I
felt
to
an
extent,
that's
the
new
section,
six
that
we
did,
but
it
may
be
quite
interesting
to
add
that
if
that's
not
wanted,
you
can
drop
it
again.
J
What
we
did
is
the
the
bigger
changes
we
moved
the
use
cases
into
the
use
case,
draft
that
you
co-edited
as
well.
I
want
you
to
say
that's
just
a
stat
that
has
the
references
in
there.
So
it's
shorter
the
requirements
I've
come
to
that
they
have
been
linked
clearer
to
the
technologies.
J
In
section
five
for
section
five,
it
has
a
mixture
of
both
standardization
efforts,
but
also
research
papers,
and-
and
we
want
to
expand
that,
if,
if
possible-
and
then
the
section
six,
as
I
said
is,
is
new
requirements
are
put
into
eight
different
ones.
Now
they
have
been
slightly
changed
compared
to
before,
because
before
they
were
more
oriented
towards
the
use
cases
which
have
been
moved
off.
So
now
they
are
a
little
bit
more
related
to
the
technology
area,
so
there's
a
slightly
different
one.
J
I
won't
be
reading
through
them,
so
don't
be
worried
about
that.
So
their
grouping
changed
because
of
that.
So
it's
more
technology-oriented,
not
use
case
oriented
and
we're
also
discussing
of
how
to
get
some
of
those
requirements
straight
into
some
of
the
the
use
case.
Discussions
and
I
said
that
that's
the
the
mapping
of
requirements
of
standardization
efforts
that
was
done.
J
It's
a
very
initial
list,
not
claiming
to
be
exhaustive
and-
and
maybe
in
order
to
accommodate
your
comment
before
I'm
very
happy
to
extend
that
and
then
and
scrap
the
standardization
only
and
actually
put
that
into
a
large
referent
list.
The
point
was
that
we
we
have
something
that
maps
from
requirements
onto
links
extending
that
to
research
links
is
obviously
quite
easily
possible,
so
that
would
extend
them
beyond
the
standardization.
J
So
that's
something
we
could
do
for
the
next
revision,
but
that
was
the
idea
there
to
look
in
the
grouping
of
the
requirements
on
the
ones.
I
said
the
the
future
plans
are
to
fill
in
the
missing
subsection.
We
still
haven't
tackled
the
dynamic
contracts
in
particular,
there
is
a
lot
going
on
in
various
efforts,
both
in
research
and
in
platforms.
As
you
know,
we
also
would
like
to
more
clearly.
J
I
know
that
I
already
said
that
last
time,
but
I
didn't
really
get
to
it
to
do
to
link
this
to
other
coin
drafts.
We've
done
it
with
the
use
case.
Draft
we're
also
getting
slowly.
I
think
there
there
are.
There
is
some
linkage
now
with
the
transport
draft
that
I
work
with
icon,
so
I
think
we're
getting
there,
but
there
are
other
things
that
can
be
done
in
section
five
update
section.
J
Five
is
more
relevant
efforts
and
I
said
I'm
happy
to
scratch
the
the
sdo
focus
only
and
then
obviously
we
there
are
already
research
efforts
in
there
in
all
standards.
This
is
not
only
sdo.
If
anything,
probably
I
wanted
to
add
more
sdo
efforts
in
order
to
highlight
what
it
actually
is,
that
standards
haven't
done
so
far.
Yet
right,
that's
the
idea
same
the
update,
as
in
section
six
that
I
mentioned
before,
which
is
that
that
lists
are
the
mapping
of
requirements
onto
ongoing
efforts.
J
D
Yeah,
actually,
this
is
something
that
we
will
not
have
time
to
discuss,
but
you
were
going
to
be
discussed
as
becoming
an
arty
draft,
because
this
is
well
advanced.
I
will
push
that
discussion
to
the
list,
but
yes,
I
think
this
is
a
draft
that
should
be
adopted
as
a
research
group
draft.
So
thank
you
very
much
to
having
been
really
fast,
hey,
mom,
sorry
to
have
pushed
you
at
the
end
here.
D
Maybe
you
can
just
do
it
first,
a
a
short
presentation
of
what
you
know
you've
been
doing
and
then
just
you
know
summarizing
your
two
drafts
into
one.
If
possible,
I
hope
you're
still,
there
is
heymon.
Still
there
a
month
is
not
there.
Oh
then
it's
great
so
we'll
be
able
to
finish
on
time.
D
Maybe
then
I
can
share
my
slide.
My
screen.
D
A
D
While
you're
sharing,
obviously
we
want
to
have
a
an
interim,
sometimes
in
may,
to
review
the
milestones,
we're
lucky
that
we
are
in
a
very
active
and
dynamic
field
where
there
is
a
lot
of
activity,
and
so
the
milestones
are
evolving.
I
think
as
fast
as
we
can
and
and
the
also
we
will
meet,
probably
not
in
san
francisco,
but
at
least
virtually
can
you
go
back
to
future
plans.
C
D
So
we
would
like
maybe
to
have
a
theme
today
you
saw
there
was
a
a
lot
of
presentations
that
were
not
clearly
related.
They
were
all
currently
related
to
coin,
but
maybe
we
want
to
have
a
theme.
So
if
somebody
has
ideas,
please
send
it
to
us.
You
can
go
next
eve,
so
we
had
actually
one
draft
presented
today
and
we
will
like
to
push
it
to
rg
document.
We
always
have.
D
We
already
have
one,
which
is
the
use
case
and
obviously
hemant
could
not
stay
as
long
as
maybe
he
wanted,
but
those
will
be
presented.
We
can
present
them
at
a
later
meeting
next
slide
eve.
D
So
these
are
the
other
drafts,
and
actually
I
would
like
the
authors
of
expired
draft
to
advise
us
on
future
intent.
Actually,
we
would
like
the
authors
to
advise
us,
especially
the
ones
that
were
like
the
directions,
which
was
very
interesting-
the
security
one
which
was
very
interesting,
and
then
there
was
a
number
of
discovery
drafts
that
also,
I
think,
could
come
back
into
play.
D
So
it's
not
for
now,
but
for
all
of
these
authors
you
know
who
you
are
so
please
advise
us
on
what
you
want
to
do
next
slide
and
that's
the
milestones.
We
have
a
ton
of
milestones
that
none
of
them
is
20
21
and
I
think
we've
achieved
a
lot
of
them.
I
don't
want
to
discuss
that
again,
but
this
is
what
we
would
like
the
interim
to
be
doing.
D
So
we
will
probably
not
have
a
lot
of
presentations,
maybe
one
and
then
keep
all
the
time
or
one
or
two
and
keep
all
the
time
to
discuss
that
and
that's
it
now
we're
because
we
are
yeah
because
hemant
didn't
show
up
so
yeah
we're
actually
20
minutes
over
time.
But
that's
fine.
Thank
you.
So
very
much
everyone
to
have
spent
the
last
two
hours
with
us
again.
D
I
think
we're
very
lucky
we're
in
a
very,
very
dynamic
field,
there's
an
awful
lot
of
research
happening
and
we're
very
happy
to
offer
a
home
for
that
research
to
be
disseminated,
and
also
to
have
a
home
for
that
research
to
be
further
defined
and
to
find
new
ways
of
of
connecting
computers
and
networks.
Thank
you.
So
much.
D
A
Okay,
well,
I
will
capture
the
the
notes
in
the
in
the
chat.