►
From YouTube: IETF-COINRG-20220210-1500
Description
COINRG meeting session at IETF
2022/02/10 1500
https://datatracker.ietf.org/meeting//proceedings/
A
B
B
A
A
A
We
are
gathered
here
today
so
good
morning,
good
afternoon
good
evening,
I'm
eve
schuler
that
was
jeffrey,
mauricio
zay's
online
as
well,
and
we're
we're
having
an
interim
in
preparation
for
the
itf
irtf
113,
and
we
are
specifically
here
today
to
have
a
discussion
around
what
topics
we
feel
are
essential
to
the
working
group
and
are
in
topic
versus
in
scope
out
of
scope
and
hope
to
have
a
healthy
discussion.
In
fact,
to
have
hopefully
a
continuation
of
the
discussion.
A
A
Although
they
are
synergistic,
the
goals
of
the
irtf
are
really
to
conduct
research
and
that
it's
not
a
place
where
we
are
standardizing
efforts.
We
are
really
conducting
the
research.
We
are
offering
a
haven
for
the
discussion
around
the
research.
It
may
or
may
not
lead
to
standardization
efforts,
but
it's
quite
a
separate
kind
of
activity.
A
Next,
today,
we
are
going
to
begin
our
agenda
by
really
we
welcoming
adrian
to
come
and
present
the
semantic
routing
work
for
which
he
and
his
co-authors
have
written
quite
a
body
of
work.
And
so
we
look
forward
to
that.
The
coin
research
group
so
so
dirk
is
going
to
help
us
by
proposing
some
thoughts
forward.
A
What's
in,
what's
in
scope
and
what's
out
of
scope
in
the
working
group-
and
we
are
delighted
to
have
stefano
silsano
here
to
talk
about
extensible,
in-band
processing
as
well
as
nick
sultana,
to
present
work
on
flight
plan,
which
was
part
of
nsdi
this
past
year.
And
then
we
will
conclude
with
a
couple
of
students
that
ruiz
jose
has
invited
in
to
talk
about
their
work,
and
we
will
conclude
we
are
going
to
try
to
keep
to
a
tight
schedule.
A
Well,
you
made
it
here,
so
you
figured
out
the
meat
echo
link
so
welcome.
The
blue
sheets
will
be
automatically
created
and
there's
an
icon
up
at
the
top
for
helping
to
contribute
to
to
the
minutes.
There's
also
a
chat
feature
and
the
mailing
list,
if
you
aren't
already
on
it,
here's
the
pointer
to
it
and
the
meeting
materials
now
they've
been
loaded
successfully
into
the
tool
can
also
be
found
in
the
data
tracker.
A
A
F
So
yeah
introducing
semantic
routing
to
you
all
finding
out
which
bits
sit
comfortably
inside
coin,
not
having
a
rehash
of
what's
in
the
ids
and
the
papers
and
the
email
threads,
and
not
debating
the
value
or
lack
of
value
of
semantic
routing
as
a
thing,
but
trying
to
open
up
what
research
we
can
do
within
coin.
So
next
slide.
F
F
F
F
So
we
need
to
pick
away
at
that
a
bit
for
semantic
routing.
This
is
chiefly
about
for
programming,
forwarding
tables
so
using
the
sdn
architecture
to
to
push
forwarding
tables
into
the
devices,
and
that
assumes
that
routine
is
is
run
centrally,
although
it
could
be
distributed
and
and
hybrid,
and
that
could
start
to
nibble
into
computing.
The
network
with
network
programming,
so
just
to
stress
that
the
sdn
network
programming
approach
is
one
way
of
doing
semantic
routing.
F
F
F
The
question
will
be-
and
we
probably
come
to
this
at
the
end-
is
coin
interested
in
these
aspects
of
sdn
and
programming.
They
don't
seem
radical
or
new.
That's
the
kind
of
thing
that
openflow
was
invented
for,
but
the
routing,
algorithms
and
related
issues
are
new,
so
maybe
they're
in
scope
for
coin
next
slide.
F
So
yeah
computing,
the
network,
which
is
you
know,
a
big
piece
of
what
coin
is
about.
Obviously,
there's
no
draft
on
this
or
no
discussion
document
on
this
at
the
moment,
but
there
is
some
material
in
the
coin
list
for
background
reading,
and
this
is
quite
an
open
thing,
so
this
could
be
about
building
forwarding
tables
using
algorithms
that
are
installed
onto
the
network
nodes.
F
And
then
those
algorithms
on
the
network
nodes,
they
could
be
built
into
the
devices
and
that's
essentially
what
happens
today
for
routing
algorithms,
if
you,
if
you're
running
an
igp,
there
is
a
routing
algorithm
and
it's
built
firmly
into
your
device
or
they
could
be
installed
into
the
devices
using
network
programming.
So
you
could
be
pushing
little
or
even
large
programs
down
into
the
devices
to
get
the
devices
to
act
either
generally
to
build
the
tables
or
per
packet.
F
F
So
again
the
cost
question
we're
going
to
have
to
come
to
is
how
interested
in
coin
is
this
and
I'm
assuming
that
static
algorithms,
as
used
today,
are
not
so
interesting
for
coin,
but
that
algorithms,
that
are
installed
by
programming
and
sort
of
mini
compute
on
the
devices
that
could
be
of
interest,
and
then
we
have
to
consider
what
programmability
in
the
network
does
semantic
routing
require
and
what
would
it
drive
so
next
slide?
Please.
F
Just
so
that
we
can,
we
can
pull
them
out
and
flag
them.
Question
was:
is
this
an
engineering
problem
or
a
research
problem?
Those
of
us
who've
been
writing
about.
This
are
not
looking
for
a
solution,
we're
looking
to
to
to
evaluate
and
research
around
potential
solutions
and
to
look
at
abstractions,
and
there
seems
to
be
a
lot
of
research
projects
and
papers
out
there
haven't
we
always
done
semantic
routing.
F
F
F
Absolutely
we
we're
not
talking
about
doing
that,
but
we
are
trying
to
understand
what
needs
to
be
standardized.
Do
algorithms
need
to
be
uniform
across
the
network
and
so
on?
And
then
what
is
the
network?
That
coin
enables
and
where
does
semantic
routing
fit
with
that?
I
think
that
needs
broad
discussion
in
research
group
and
I
don't
believe
I'm
qualified
to
to
talk
about
that
yeah.
Thank
you.
Where
is
the
community?
F
F
F
F
There's
a
list
here
of
pieces
that
maybe
we
can
bring
to
coin
and
we
need
the
view
of
the
community
and
the
chairs
and
of
colin
about
which
of
these
we're
okay
to
bring
to
coin,
because
we
don't
want
to
waste
people's
time
and
which
of
these
we
should
take
somewhere
else
and
if
so,
where
and
I'm
not
gonna
read
through
all
these.
But
maybe
we
leave
that
up
as
we
move
into
any
discussion.
If
there's
time
for
that
chairs,.
A
G
Just
fiddling
with
my
with
my
microphone
here,
yeah
I
mean
we
have
been
discussing
this
question
a
bit
further
and
and,
as
drawing
pointed
out,
that
john
has
alluded
to
this
on
the
mail,
so
the
the
slides
don't
have
numbers.
Unfortunately,
so
I
can't
refer
easily
to
one
back,
but
I
was
essentially
curious
that
most
of
the
points
on
the
slides
was
pretty,
but
it
was
pretty
specific
about
forwarding
decisions,
whereas
I'm
still
struggling
to
see
what
the
bigger
picture
for
the
routing
part
and
that
could
get
instantiated.
F
You
then
put
that,
together
with
the
fact
that
you
are
trying
to
make
these
decisions
on
microflows
or
even
per
packet
basis
based
on
information
carried
in
the
packets,
and
you
are
setting
yourself
up
for
some
very
confused
forwarding,
loops
or
drop
packets.
Unless
you
have
the
coordinated
view
of
the
routing
algorithms.
G
Effectively,
you
would
have
a
routing
algorithm
that
would
have
set
more
attributes
to
enter
into
the
tables
to
make
forwarding
decisions
and
possibly
dynamic
ones
or
but
otherwise.
This
is
a
very
generic
description
of
how
routing
works,
not
that
I
would
know
much
about
routing
besides
the
basics,
but.
A
A
C
Okay,
thank
you.
Can
we
actually
hear
me
because
what
okay,
okay,
thanks
adrian,
so
would
it
be
correct
to
say
that
so
what
you
call
semantic
routing
here
is
an
attempt
to
do
something
like
what,
for
example,
service
function,
chaining
is
doing
or
nfv
management
and
control
I
mentioned
orchestration
is
doing,
but
this
time
on
the
ip
layer.
Is
that
what
you
have
in
mind.
F
H
C
C
A
H
H
What
are
the
implications
for
routing
and
and
basically,
how
is
semantic
routing,
a
good
use
case
for
that,
and
not
because
I
think
there
was
an
awful
lot
of
traffic
on
on
routing
last
week
on
the
list
and
there's
I'm
sure
I've
read
dirk's
slides.
So
I
I
actually
know
a
little
bit
what
he's
gonna
talk
about
and
I
think
there's
also
an
incredible
amount
of
cool
work
that
can
be
done
within
the
coin
or
umbrella.
H
And
so
routing
is
one
aspect,
there's
others
and
if
you
want
to
take
the
lead
and
looking
at
how
packet
data
plane,
programmability,
impacts
routing
and
you
can
get
people
to
join
your
movement.
I
think
it's
for
it's
fantastic,
but
I
would
have
a
tendency
to
as
a
generalist
to
say.
Okay,
so
we
have
packet
level,
programmability
data,
plane
programmability.
H
E
E
I
in
particular,
I'm
trying
to
understand
why
some
of
the
work
that
we
also
currently
doing
fits
in
and
trying
to
understand
how
this
goes,
and
this
triggered
the
email
that
I
sent
to
the
list,
and
I
wanted
just
to
summarize
from
those
things
and
just
as
a
discussion
of
where
we
could
go
as
a
research
group.
So
this
I
said
just
you,
you
can
read
some
of
this
in
relation
to
some
animation,
but
it's
not
intended
to
really
trying
to
help
us,
or
at
least
present
from
my
side.
E
How
I
see
where
coin
is,
what
coin
does
for
people
to
disagree,
push
back
or
agree
with,
hopefully,
hopefully,
all
I'm
saying
is
going
to
be
nonsense.
So
next
slide.
Please
says
that
this
is
a
an
individual
understanding
of
the
scope
of
intention
of
coin.
The
way
I've
understood
it,
I've
been
involved
in
coin-
I
don't
know,
probably
should
go
back
to
three
years
or
so
certainly
before
I
started
huawei
and
trying
to
look
at
it
at
coin
as
a
community
effort
through
the
taking
input
from
charter.
E
E
But
again,
honestly,
it's
an
individual
understand.
You
may
very
well
disagree,
and
I
expect
you
to
just
maybe
also
agree.
Ask
questions
to
the
community
on
this
understanding.
Do
I
get
it
right
are?
Are
the
questions,
maybe
the
right
ones,
possibly
the
wrong
ones?
Maybe
there
are
no
good
answers?
Maybe
they
aren't
even
good
questions
to
start,
but
I
don't
know
the
goal
is:
is
that
we
discuss
how
to
possibly
get
a
better
understanding
how
we
could
go
forward,
and
I
paraphrase
dave's
email
I
left.
E
I
know
he
talked
about
routing
there,
but
I
think
we
can
paraphrase
that
with
anything
in
mind,
we
have
ample
basis
for
a
lot
of
pieces
that
we
discuss
in
coin,
to
work
on
from
mourinho's
perspective,
and
the
question
is
really:
what
brings
the
coinage
to
the
party?
That's
kind
of
inspired
a
little
bit
to
look
at
this
from
my
side.
E
It's
not
hard
to
make
this
clear,
there's
no
target
towards
specific
outcomes.
Like
rechartering,
I
took
the
charter
as
an
input
because
that's
what
people
encounter
when
they
type
coin
irtf
into
a
search
engine?
It's
not
the
intention
to
suggest
interpret
what
we've
agreed
and
written
down
so
far.
Please
next
slide,
please
so
observations.
So
I
tried
to
tease
out
core
aspects
core
concepts.
How
I
understood
this.
You
know
words
that
have
been
flying
around
descriptions
for
concerts
that
be
flying
around
computer
network.
E
We
hear
that
a
lot
and
and
and
the
recent
discussion
was
that
john
chimed
in
you
know
that
was
the
terminology
has
been
used.
You
can
also
find
in
the
charter.
You
can
find
a
number
of
documents,
so
it
seems
to
be
something
that
people
care
about
which
I
guess
you
know-
comes
from
the
name.
Probably
it's
not
active.
Networking
pointed
this
out
before
in
a
different
context
that
john
responded
there
and
and
and
seems
to
be.
E
You
know
I
seem
to
agree
to
this
broker
mobility
of
the
data
plane,
as
you
just
see
right
rightly
pointed
out
that
results
from
the
computer
in
the
network
vision.
So
can
we
do
something
with
data
plane?
That's
just
more
than
a
relatively
static
table,
lookup
and
then
again
we
see
this
in
a
number
of
pieces
that
be
presented
not
only
through
the
work
on
sdn
p4.
E
Also,
a
number
of
the
use
cases
we
captured
in
the
use
case
draft
you
know
really
make
use
of
that.
You
can
see
it
comes
out
of
those
examples,
cloud
edge,
continuing
that's
being
used
as
a
as
a
word.
I
think
the
charter,
but
also
you
know
in
other
pieces
specifically
to
move
beyond
just
packet
and
deception
and
do
move
towards
computation.
So
that's
kind
of
the
way
this
is
presented
there
orchestration.
E
I
think,
we've
seen
there
are
aspects
of
this
in
the
use
case
draft
it
does
talk
about
orchestration,
need
to
orchestrate
the
research
usage
within
the
computer
network.
So
how
does
this
all
come
about?
It's
all
nice
to
have
programmability
in
a
switch,
but
how
is
it
placed
at
the
right
switch?
How
is
the
conjunction
of
computations
in
several
places
in
the
network
properly
being
well
orchestrated?
E
That
seems
to
be
of
great
interest
decentralization.
I
find
this
personally
quite
interesting
like
with
this
quite
a
bit
there.
We
have
would
count
probably
to
use
cases
that
are
quite
heavily,
and
that
is
quite
happy
that
are
quite
heavily
centered
around
decentralization,
so
they
move
beyond
just
the
data
center,
not
because
necessarily
it's
it's.
We
talk
about
compute
in
the
network,
but
also
the
fact
that
the
participating
end
nodes
that
are
not
technically
in
the
network
are
also
becoming
much
stronger.
E
Part
of
the
story,
then
there's
a
computer
with
a
network
and
the
only
outside
element
is
the
data
center.
So
there's
a
very
strong
element
of
that.
I
may
have
missed
something.
These
are
the
bits
again
bits
and
pieces
that
I
teased
out
also
didn't
want
to
overcrowd,
possibly
miss
something
likely
and
probably
quite
interesting,
to
hear
from
folks
about
very,
very
strong
and
important
aspect
that
may
be
missing
on,
but
at
that
discussion
next
time.
Please,
then
other
observation
I
wanted
to
do
is
on
the
intended
methods.
E
I
know
this
is
the
iotf
a
lot
of
discussion
around
this.
The
iotf
and
you
know,
there's
not
the
ietf,
but
there
are
hints
obviously
in
our
own
work,
but
also
in
the
charter
as
to
already
what
the
intended
methods
are.
Charter
talks
about
use,
case,
driven
requirements,
analysis
and-
and
we
progress
that,
it's
probably
I
don't
know
if
it's
the,
but
probably
one
of
the
most
collaborative
pieces
of
work
in
coin,
that's
being
through
the
draft,
I
think
we
are
now
at
six
or
seven
quarters
identify
benefits.
E
You
know
that
that
that
coin
may
bring,
but
also
even
describing
what
an
experience
of
computer
network
may
look
like.
I
think
that's
very
useful
for
people.
They
want
to
understand
things.
So
that's
a
method,
and
it's
quite
common
to
do
that.
I
mean
it's.
It's
not
only
coin,
as
an
rg
is
doing
this
other
rgs
have
done
the
same
thing.
Of
course
it
may
come
from
outside
or
from
within
the
coin.
E
H
E
People
to
this
research
on
new
users,
languages,
abstraction
market-
that's
explicitly
mentioned-
I
think,
that's
where
we
see
a
lot
of
the
presentations
that
are
being
done
so
in
order
to
attract
the
wider
community
to
bring
their
work
to
coin
once
they
either
realize
it
is.
Coin
might
be
a
right
place
or
somebody
in
the
coin
community
may
think
these
people
should
present.
Here
right,
I
mean
we've
seen
both
ways:
people
coming
to
coin
people
being
pulled
into
coin,
and
I
think
that's
a
good
thing
right
also
mentioned.
E
There
was
a
bit
of
a
discussion.
This
is
the
iatf
and
we
shouldn't
do
certain
things.
The
charter
gives
us
an
idea
that
we
should
pay
close
attention
to
work
in
other
rgs,
that's
quite
natural,
it
seems
so
see,
what's
happening
elsewhere,
not
just
in
the
community
but
also
in
other
groups.
Specifically,
I
definitely
I
see
energy.
I
forgot,
as
I
mentioned.
Definitely
ic
energy
was
mentioned
in
the
charter
and
we
can
see
in
overlap
also
of
constituents
here.
E
People
who
are
active
in
both
of
these
communities
for
good
reason,
but
also
the
interaction
with
the
ietf
is
being
mentioned
so
avoid
proposals
in
particular.
There's
an
aspect
mentioned
to
that
would
increase
the
friction
between
privacy
and
invoking
competing
and
also
before
the
discussion
with
hvac.
We
mentioned
aspects
on
security
that
would
need
deep
consideration.
E
So
these
are
the
intended
methods
are
probably
not
surprising,
but
I
wanted
to
put
them
up
here
what's
the
discussion,
but
I
also
wanted
to
clarify
that
the
vehicle
for
capturing
the
discussions
are
very
varied.
There
are
internet
drafts,
people
have
been
putting
together
myself,
I
joined
two
different
internet
drafts
and
I
say
joined.
I
didn't
create
them,
but
we
also
bring
in
papers.
People
send
their
githubs
around.
It
doesn't
really
quite
matter.
E
E
Now
you
see
it
all,
which
is
fine,
the
light
blue
pieces,
you
can
probably
see
and
recognize
quite
easily,
both
in
pieces
of
work,
but
also
in
discussions
on
the
main
list
and
even
better
in
the
charter
I
put
the
I.
I
posted
these
scope
numbers
in
the
charter
as
I
perceive
them.
On
the
left
hand
side.
This
is
what
the
scope
one
two
three
four
means.
If
you
look
at
the
bullet
items
in
the
charter,
they're
reflected
there.
So
it
starts
from
the
bottom
on
vision
and
technologies
from
copied
in
the
network.
E
That's
a
very,
very
clear
thrust
of
of
work.
Personally,
I
would
like
to
see
more
there,
but
we
have
a
lot
of
technology
presentations.
On
the
other
hand,
there's
a
lot
happening
there
as
well
distributed
computing
frameworks
and
languages
that
build
on
top
of
this
division,
as
well
as
the
abstractions
that
are
being
created
through
this
visions
division.
I
know
we
have
a
threat
which
has
gone
a
little
bit
dormant.
E
I
think
on
the
descriptive
competing
framework,
dirks
and
york's
work,
but
I
also
know
there
has
been
related
work.
That's
happening.
I
recall
a
paper
that
dirk
submitted
in
the
acm
itn
conference
that
I
see
directly
related
to
the
distributed
convening
frameworks
that
could
be
used
there.
So
there's
a
lot
happening
there.
It's
obviously
banging
the
scope,
it
seems
to
be
and
and
then
I
introduced-
and
I
noticed
it's
a
terminology-
you
can
push
back
on,
but
they
are
listed
in
and
I
just
stuck
a
name
on
it.
E
I
called
applicability
area.
It
may
not
be
a
very
good
name
or
hack.
The
the
areas
are,
the
the
blue
ones.
Light
blue
ones
are
already
listed
in
the
charter
and
we
have
ongoing
and
transparent.
We
have
ongoing
activity,
ike,
klaus
and
myself.
We
are
co-authoring
a
draft
on
transport
issues
that
are
looking
looking
at
issues
that
arise
at
the
transport
level
through
programmability
in
the
network.
E
That
was
the
call
that
ike
recently
had
on
the
list
for
cool
contributors,
people
to
join
us
in
this
effort-
and
I
think
the
next
presentation
that's
being
announced-
is
one
of
the
ones
that
we
actually
try
to
pull
into
the
coin
group
to
help
us
in
this
era.
Privacy
is
another
area,
that's
been
mentioned.
It's
been
some
work
going
on
data
discovery
was
an
item.
I
know
I
put
it
now
in
dark
blue.
It
was
an
item,
but
I
I
also
think
it
has
gone
dormant.
E
Some
time
ago
there
were
also
internet
crafts
on
this,
where
he
summarized
the
discussions
routing.
You
can
see
that
as
I
within
the
terminology,
I'm
using
as
a
applicability
area
again
the
same
question:
how
is
future
routing
and
whether
it's
semantic
routing
or
routing?
I
left
the
semantic
out
here.
E
How
is
that
impacted
by
the
capabilities
that
the
items
below
give
you
the
capability
of
computer
in
the
network
and
but
also
computing
framework
in
languages?
That
would
allow
you
to
write
routing
as
an
app
in
a
way
right,
and
maybe
there
are
other
applicability
areas
right
outside
that
I
may
have
missed,
so
that
was
kind
of
the
one
that
I
used
on
on
the
mailing
list
and
if
you
go
to
the
very
last
slide
that
led
me,
then
to
a
number
of
questions.
E
I
just
wanted
to
throw
out
and
that's
the
question:
where
do
we,
and
I
said
why
do
we
want
to
see
progress?
I
have
my
own
viewer.
I
would
like
to
see
more
brokers,
but
I
want
to
push
this
or
put
this
to
the
community
vision.
Well,
the
positioning
and
the
delineation,
I
think,
is
very,
very
important
in
particular
towards
edge
computing.
We
had
quite
a
bit
of
discussion,
particularly
in
the
use
cases,
and
the
courses
may
remember
a
bit
of
that
on.
E
You
know
where
is
really
the
borderline
between
edge
computing
and
competing
in
the
network?
Well,
if
we
assume
that
maybe
putting
an
application
level
server
through
nfv
somewhere
in
the
network
is,
is
that
really
the
same
thing?
Is
that
for
computer
networking
or
standard
computing
right?
So
so
I
think
that's
what
work
on
vision
could
really
help
us,
because
this
is
also
a
question
that
I
receive
very
often
I
invited
a
few
people
to
join
coin,
and
this
is
very
often
one
of
the
first
questions.
E
You're
getting
is
calling
about
edge
computing
right
technologies.
What
is
possible
enablement
of
this
vision
and
the
architecture
of
coin?
We
have
quite
a
lot
on
that.
I
think
that's
good,
because
that's,
I
think,
is
the
easiest
area
to
invite
outside
research
into
the
coin
group.
So
I
I
think,
that's
probably
quite
easy
to
say.
That's
probably
something
that
also
others
may
feel
quite
strongly
in
keeping
as
a
progress
right
and
applicability
is
something,
but
not
only
because
it's
in
the
in
the
charter.
E
But
it's
something
that's
always
very,
very
useful,
because
it
allows
us
to
describe
the
impact
on
existing
or
discovering
new
areas.
Transport
was
included
because
we
wanted
to
know
how
transport
would
be
impacted
by
the
ability
to
start
fiddling
around
with
stuff
in
the
middle
of
the
network
right
and
it
seems
to
be
quite
obvious,
and
privacy
was
another
one,
and
now
we're
talking
about
routing.
E
How
could
routing
be
impacted
by
the
fact
that
you
could
do
more
intelligent
decisions
in
the
network,
so
applicability
is
something
that's
very
intriguing
because
it
it's,
it
can
be
very,
very
powerful.
If
you
will
the
question.
I
asked
on
the
on
the
on
the
list,
and
I
think
this
goes
towards
back
to
looking
back
to
dave's
email.
E
E
You
know
to
ask
almost
immediately
as
to
what
are
the
key
questions
from
a
coin
perspective
that
looking
at
this
applicability
area
may
pose
and
would
be
really
really
interesting
right,
but
then
also
how
to
connect-
and
this
is
something
with
that
we
discussed-
and
this
was
something
that
came
discussion
with
ike.
How
do
we
connect
to
other
efforts?
A
A
I
I
So
we
we
say
that
the
the
the
layer
3
functionalities
is
rather
ossified,
so
we
are
trying
to
collect
requirements.
We
want
to
collect
requirements
from
a
few
use
cases
and
then
define
this
eip
mechanism
as
a
an
extension
approach
and,
of
course,
trying
to
overcome
these
ossification
barriers,
and
we
will
base
our
work
on
open
source
prototypes.
Also,
we
want
to
to
make
design
ideas
and
then
to
turn
them
into
into
into
prototypes
to
support
this
this
process.
I
I
So
I
stress
that
I
don't
think
that
this
pardon
me
can
be
applied
in
the
wool
internet
from
tomorrow.
So
I
think
that
which
we
can
focus
a
solution
that
work
in
limited
domains,
so
there
are
other
examples
in
in
in
itf,
in
a
protocol
of
mechanisms
that
have
been
defined
for
for
limited
or
controlled
domains.
This
is
also
also
called
so.
I
think
that
this
new
mechanism,
this
eip,
will
work
in
in
limited
domains
of
controller
domains.
I
So,
let's
start
with
the
one
one
use
case,
for
example
contractual
networking,
because
I've
been
discussing
that
this
in
previous
side
meetings
in
in
atf,
so
this
is
a
from
this
discussion
in
itf
side
meetings
that
started
this
idea
of
on
on
eip.
So
what
is
the
contract?
This
is
my
view.
It's
a
complex
and
distributed
service
offered
by
a
network,
and
this
complex
and
distributed
service
is
composed
by
several
service
components
and
features
like
forwarding
metering,
filtering
accounting.
I
So
a
service
will
include
all
these
all
these
aspects,
and
in
order
to
support
these
these
features,
we
may
need
to
add
and
modify
information
in
the
packet
on
the
fly
talking
about
contractor
networking.
I
think
that
we
have
to
face
is
a
phase
in
which
we
can
negotiate
a
contract,
and
this
is
the
control
plane
and
a
phase
in
which
a
contract
this
service
is
enforced.
I
The
packets
are
processing
according
to
the
negotiation
negotiated
contract,
and
I
will
just
want
to
stress
that
with
irp
eip,
we
want
to
focus
on
data
plane,
so
the
enforcement,
the
monitoring
phase,
the
the
data
plane.
So
we
are
not
focused
on
on
control
plane
on
the
contract
definition
on
the
signaling
about
this,
so
we
just
focus
on
data
plane
mechanism,
how
we,
what
we
write,
what
we
read
in
in
data
packets
to
support
our
our
services.
I
So
I
just
repeat
some
somehow:
the
processing
forwarding
on
packet
based
on
eip
is
based
on
the
combination
of
different
information.
We
have
some
information
that
can
be
inserted
by
the
source,
node
or
also
the
edge
node,
if
we
consider
that
packets
can
be
encapsulated
by
edge
nodes
into
new
packets.
So
in
this
case
the
edge
node
can
play
the
role
of
the
source
and
can
start
writing
this
eip
information
in
the
packet.
I
Then
the
following
nodes
in
the
in
the
in
the
path
can
dynamically
insert
the
information
in
the
packets
and,
of
course,
so
we
can
base
the
the
the
processing
on
the
packets
or
on
regular
layer,
the
current
existing
layer,
three
information,
the
routing
information,
the
combination
of
all
information
determines
what
we
write
on
the
packet,
but
also
where
we
send.
We
send
the
packet.
So
we
we
can
achieve
with
this
information
that
is
inserted
in
the
packet,
a
network-wide,
dynamic
and
stateful
packet
packet
processing.
I
So
if
you
want
to
go
into
a
little
bit
more
details,
if
you
want
to
define
aip,
I
think
we
can
to
to
answer
to
question
what
we
put
inside
this
new
ip
header.
Let's
see-
and
this
will
be
based
on
the
the
services
that
we
want
to
define
the
use
case-
that
we
will
support
using
this
eip
information
and
where
to
write
this
information
inside
the
ipv6
packet
headers.
I
I
But
what
I
can
already
envisage
is
that
some
requirements
will
be
common
to
different
use
cases,
and
so
that
will
be
the
added
value
of
having
this
eip
with
respect
of
the
other
existing
extension
mechanism
in
in
pvcs
that
we
can
put
together
different
use
cases
and
make
some
common
information
that
we
had
in
the
packets.
For
example,
time
stamping
can
be
official,
which
is
common
to
different
use
case
authentication
so
with
hmac.
I
I
So
the
second
question
is
where
we
carry
the
information
and
okay.
Here
we
have
the
the
ipv6
header
and
its
extension
extension
headers.
We
have
several
possibilities,
so
we
have
hop
by
up
options,
so
we
can
define
the
erp
as
a
a
hop
by
up
option
or
a
destination
option.
Then
inside
this,
of
course,
I
repeat,
we
will
have
tlbs
subtle
and
v's
specific
for
the
different
use
cases
and
some
that
are
common
to
more
than
one
use
case.
I
Also,
we
have
the
segment
rooting
header,
so
this
is
another
opportunity,
because
segment,
rooting
header
is
also
extensible.
It
has
the
notion
of
tlbs,
so
we
can
carry
an
eap
tlv
and
this
in
turn
can
have
sub
b's
and
we
can
carry
it
also
inside
the
the
segment
through
header.
So
I
think
that
currently
these
are
different
alternatives.
Of
course.
I
In
the
end,
maybe
we
will
select
one
for
the
time
being.
We
have
started
some
initial
brainstorming,
so
I
have
an
initial
document
in
which
I
propose
some
format
for
these
options
or
for
these
tlbs
and
make
some
example
of
some
tlvs,
like
the
hmac
or
like
the
timestamping,
that
I
think
that
can
be
general
for
for
different
use
cases.
I
So
I
will
continue
with
a
couple
of
other
use
cases
in
addition
to
contractual
networking
just
to
give
the
idea
and
to
try
to
gather
feedback
and
other
ideas.
So
the
dominic's
networking
has
been
standardized
in
these
rfcs
and
the
the
the
rfc
of
deterministic
networking
explained
that
there
are
no
limitations
in
the
current
ip
data
plane
to
support
the
diminished
networking.
I
So
they
say
that
okay,
we
have
done
an
ip
based
implementation
with
this
limitation,
if
we
can
add
the
explicit
information
in
it
packets.
This
can
simplify
the
implementation
of
deterministic
networking
in
ap,
routers
and
us
and
provide
additional
features.
So,
for
example,
eip
is
very
well
suited
to
to
this
purpose.
We
can
use
eip
to
support
the
needs
of
deterministic
networking.
I
Another
example
is
slicing,
there's
a
lot
of
discussion
on
going
in
in
the
these
working
group
of
ietf,
and
there
is
a
framework
that
describe
is
described
in
in
a
draft
and
we
need
at
least
an
identifier
in
the
packet.
There
are
many
proposals
what
we
say
that
in
ip
of
course,
we
can
support
azerite's
identifier,
but
we
can
also
support
the
requirements
and
future
features
that
are
a
little
bit
more
complex.
I
Okay,
you
have
another
couple
of
technical
comments
for
for
the
further
discussion,
wire
speed
processing.
Of
course,
we
we,
we
target
wire,
speed
processing.
We
know
that
it's
a
problem,
but,
of
course
we
we
think
that
we,
we
will
require
hardware
support
to
achieve
a
high
speed
processing
of
this
information,
and
these
will
need
to
be
taken
in
into
account.
So
we
we,
if
we
want
to
to
to
design
solution
that
will
be
implemented
by
hardware.
I
I
I
So
in
a
linear
domain
is
there
are
already
established
mechanism
to
to
have
a
trust
of
the
information
which
is
changed
by,
for
example,
a
router
and
needs
to
be
read
by
another
another
router,
okay,
so
just
in
general,
I
think
that
our
security
concerns
are
rather
aligned
with
those
of
a
service,
6
network
programming
model
and
where
they
have
been
addressed
adequately,
and
there
are
already
standards
for
servc.
So
I
think
that
we
can
work
this
security
concern.
I
Deployability,
I've
already
mentioned
that
we
work
in
limited
domain
and,
of
course
we
will,
when
we
will
go
into
definition
of
specific
services,
we
will
also
clarify
the
requirements
for
the
nodes
that
are
running
in
these
limited
domains.
So
in
some
cases
we
will
be
able
to
provide
a
service
only
if
all
routers
are
upgraded
with
a
new
feature,
but
in
many
other
case
we
can
support
services.
I
This
is
based
on
ebpf
http,
so
it
is,
it
is
efficient
and
the
prototype
relies
on
a
framework
that
I've
been
working
on
in
with
my
research
group,
a
framework
for
a
bpf
programming.
So
this
is
why
I
think
we
can
achieve
a
very
quick
prototype.
We
target
to
have
a
prototype
in
one
month
from
from
now,
because
we
rely
on
an
existing
programming
framework
for
for
a
bpf
in
the
future.
We
could
also
work
on
a
p4
prototype
question.
I
Is
anyone
interested
in
in
such
in
such
a
work-
and
here
are
just
two
words
about
this
framework
for
ebpf
programming-
that
we
are
using?
It's
it's
a
framework
which
is
described
in
this
submitted
paper.
Here
you
find
the
the
the
link
to
the
to
the
paper,
and
here
you
find
the
the
technical
documentation
of
the
system
that
it's,
of
course
it's
an
open
source
solution.
I
The
idea
is
that
we
can
write
scripts
in
a
language
similar
to
python,
to
implement
packet
processing
operator
operation
inside
a
node.
So
in
order
to
program
the
processing
of
the
packets
in
a
node,
we
have
ebpf
components
and
we
are
able
to
compose
these
with
an
high-level
language
like
like
python,
then
everything
is
is
compiled
and
then
it's
executed
at
ebpf
level
at
a
very,
very
in
a
very
efficient
efficient
way.
I
So
we
have
this
prototype
and
we
can
have
a
basic
prototype
in
in
a
single
node
in
which
we
have,
let's
say
a
kind
of
development
environment
for
eip
and
in
this
development
environment.
We
have
a
system
under
test
in
which
we
put
our
functions.
So
the
the
the
function
that
reads
and
write
the
eip,
packets,
the
dip
headers
and
we
can
test
them
with
with
the
traffic
traffic
generator.
I
I
I
I
I
A
Thank
you
so
much
for,
inter
very
interesting
talk,
and
it's
very
interesting
that
you
have
a
test
bed,
that's
up
and
running.
So
thank
you
for
that.
Thank
you
for
sharing
and
I
would
encourage
folks
to
look
into
the
slides
to
track
down
the
the
pointer
to
joining
the
conversation
and
the
test.
Back
I
mean
I'm.
H
I
thank
you
for
the
presentation
I'm
a
little
bit
confused,
though
about
what
do
you
want
to
achieve
within
this
group.
We
are
not
going
to
give
you
use
cases,
you
know
we're
doing
research
on
data
plane,
programmability,
and
I
would
recommend
that
you
look
at
the
existing
use
cases
and
maybe
tell
us
how
your
solution
matches
and
not
the
other
way
around.
H
H
I
Yes,
thank
you.
Thank
you
yeah.
If,
of
course,
I've
been
a
little
bit
quicker,
but
that,
in
the
call
for
a
feedback
that
was
written,
of
course,
operator
vendors
and
academia.
So
of
course
here
maybe
I'm
talking
also
to
academia
to
to
researcher,
and
the
point
is
that
I,
like
that
researchers
also
join
this.
I
This
effort
absolutely,
and
I
think
that
the
use
case
can
also
come
from
from
researchers
and
so
for,
for
example,
I
mean
in
the
previous
presentation
we
saw
adrian
that
mentioned
that
okay,
we
may
need
to
add
the
information
in
a
packet
for
the
need
of
of
semantic
routine,
for
example.
This,
for
me,
is,
is
a
use
case
that
maybe
can
can
be
turned
into
some
extension
to
to
the
framework
that
I'm
trying
to
to
to
set
up.
So
this
is,
I
think,
it's
stefano.
H
I
I
I
think
that
if
this
community
has
some
interest
in
in
doing
some
scenarios
in
which
notes
are
actively
reading
and
writing
information
in
packets,
I'm
providing
a
tool
and
also
a
framework,
and
so
also
people
that
have
these
scenarios
in
mind.
May
I
think
I
mean
we
could
join
the
work
if
there
are
other
people
that
think
that
a
node
may
need
to
read
and
write
information
in
in
pocket
on
the
fly.
A
I
E
Yeah
yeah,
I
I'm
kind
of
given
that,
but
I'm
really
quite
keen
on
you
know,
maybe
we
can
get
something
out
there.
You
know
for
the
use
case,
work
that
we're
doing.
No.
No,
no,
no
colin
made
me
avoid
the
word
craft,
but
it
happens
to
be
a
draft.
I'm
sorry,
colin
I'd
be
really
quite
interested.
I
mean
formulating
what
you
said
before:
I'm
I'm
confused
by
the
by
the
direction
you
suggested
and
saying.
E
If
the
community
is
interested
in
doing
something
where
you
do
something
on
the
line
on
the
wire,
I
have
the
tool
to
do
it.
That's
good.
I
mean
this
is
good
in
the
sense
that
eve
just
said,
maybe
that
we
could
do
some
research
than
that.
That's
that's,
okay,
but
I
would
also
like
to
post
the
question
the
other
way
around
to
you.
I
would
argue
going
in
my
mind
for
the
use
cases
we
currently
have
in
the
use
case
document.
E
If
we
actually,
why
can't
could
you
bring
a
very,
very
strong
use
case
into
the
coin
community
in
the
form
of
that
document?
Where
you
said
yeah,
you
know
if
you
have
that
ability
for
injecting
these
type
of
extensible
information,
and
you
can
do
something
concrete,
not
just
generic,
it
can
be
information,
and
you
can
act
on
it
that
that
that's
a
bit
strange
right
about
a
use
case
where
I'd
say
this
is
a
use
case
for
forwarding
node
for
forwarding
nodes
on
the
path
doing
something
with
information,
etc.
E
E
That
sounds
like
eip
right.
So
that's
the
part
that
I'm
missing
not
the
other
way
around
that
we
go
through
our
use
cases
that
we
already
have.
I
think,
six
or
seven
of
them
said.
Oh
yeah
ap
could
be
a
solution.
I
I
would.
I
would
really
put
the
demand
on
you
to
say:
come
up
with
something
really
cool,
very
specific
as
a
use
case,
as
as
they
are
on
the
use
case
documents
and
put,
and
then
you
know,
send
us
an
email
on
a
mature.
E
I
Yeah,
I
I
I
accept
this
this
suggestion.
I
think
that
is
exactly
what
I'm
going
to
do
in
the
next
in
the
next
weeks
that
that
defining,
which
is
the
best
the
best
use
case
and
and
and
start
to
work
on
on
that.
So
I
I
it's
a
good
point
and
I
I
will
surely
follow,
follow
up
and
I
think
that
in
over
in
a
couple
of
months
I
will
have
the
test
bed,
but
also
I
will
identify
the
nice
use
cases
and
but
I'm
also
asking
for
suggestions.
I
A
J
Wonderful,
okay!
Thank
you,
everyone
for
a
very
interesting
session.
It's
a
pleasure
to
be
here.
I
I
recently
joined
illinois
tech,
but
the
the
work
I'm
describing
was
mostly
done
when
I
was
a
postdoc
at
upenn,
so
so
speaking,
of
which
I'd
like
to
start
by
acknowledging
the
wonderful
people
I
worked
with
there,
both
at
upenn
and
also
at
pertinent
labs,
who
was
an
industrial
collaborator
in
this
this
project.
J
So
the
the
scope
of
this
work
is
mostly
targeted
at
data
center
networks,
but
there
are
various
ideas
that
can
be
transferred
over
to
other
types
of
networks.
So
I
mentioned
this
because
the
kind
of
topologies
that
you're
gonna
see
are
going
to
be
most
easily
kind
of
fit
within
a
data
center
context,
but
I'd
be
happy
to
kind
of
discuss
further
how
the
ideas
can
transfer
over.
J
There
was
a
very
interesting
you
know
couple
of
points
made
throughout
today
and
also
on
the
mailing
list
about
research
versus
engineering
and
one
of
the
things
kind
of
I
struggle
with
a
bit
sometimes
in
academic
research.
Is
you
know
how
to
get
enough
leverage
technically
to
do
interesting,
work
right
and
and
come
come
up
with
new
ideas
and
prototype
them,
and
something
that
I
found
helpful
over
the
last
deck
over
the
last
few
years?
J
J
So
for
those
of
you
who
are
not
familiar
with
p4
I'll
just
add
some
context,
it
is
a.
It
is
a
fairly
limited
domain,
specific
language.
It
does
not
support
loops,
but
it's
being
domain
specific.
It
supports
abstractions
that
you
typically
encounter
or
needs
when
programming
the
network,
such
as
table
lookups.
J
But
currently
the
paradigm
is
it
kind
of
follows,
a
one-to-one
pattern
where
you
write
a
program
and
then
you
flash
it
onto
one
data
plane
device
now
this
is
you
know
it's
fairly
simple
and
it
kind
of
carries
over
from
how
we
traditionally
program
microprocessors
microcontrollers,
but
it
feels
that
there
is
a
bit
of
a
mismatch
with
the
overarching
vision
right
because
we
are
this
is
this
is
two.
This
is
to
to
kind
of
coarse
grain
right
at
the
granularity
of
devices,
so
I
I'm
expanding
a
bit
more
on
this.
J
This
mismatch
here.
So
there's
a
certain
exclusivity.
When
you
pick
a
particular
device
that
you
want
to
program,
you
also
have
to
reason
about
the
dedication
of
those
of
the
targets
resources
being
dedicated
to
your
program.
Your
program
must
fit
or
somehow
be
shoehorned
into
that
target,
and
also
we're
kind
of
meant
to
be
programming
the
network
right,
but
it
takes
too
much
of
a
piecemeal
approach
using
this
paradigm
to
to
to
end
up
doing
the
programming
of
the
network.
J
In
order
to
meet
your
your
objectives
and
the
you
know
talking
about
engineering
versus
research,
one
of
the
pragmatic
choices
that
we
made
here
was
to
you
to
continue
to
preserve
the
use
of
existing
vendor
tool,
chains,
languages
and
hardware,
simply
because
we
wanted
the
research
to
be
more
realistic
right.
So
this
kind
of
resonates
with
points
made
earlier
and
on
the
mailing
list
that
we
don't
expect
the
world
to
change
to
suit
our
idea.
J
J
J
But
the
idea
is
to
isolate
bits
of
the
logic
and
then
have
them
offloaded
to
other,
maybe
different
network
hardware
or
hardware
that
is
connected
to
the
network
right.
It
might
be
a
cpu
being
offloaded
to
by
a
switch
or
a
smart
nic
or
another
switch,
and
you
know
you
know
so.
The
idea
is
then
to
transform
the
program
in
order
to
do
this
hand
over
and
also
hand
over
back,
but
we
start
to
see
that
you
know
we
gradually
appreciate
that.
J
Oh
hang
on
what
happens
if
part
of
the
program
fails
and
part
of
the
switch
right
when
you
need
to
do
some
monitoring
right,
so
we
end
up
with
a
distributed
system.
So
this
makes
the
program
pro
the
problem
more
challenging,
ie,
interesting
and
I'll
talk
about
how
we
deal
with
that.
Another
thing
I
wanted
to
bring
across
is
that
the
granularity
of
the
the
handover
should
not
be
prescribed
by
us
right,
so
that
should
be
something
that
can
depend
on
what
hardware
is
going
to
be
available
at
wherever
this
is
deployed.
J
J
You
know
a
tremendous
amount
of
manual
effort
to
just
kind
of
place
and
split
programs,
and
you
know
speaking
of
manual
efforts.
It's
a
manual
effort
would
be
a
killer
for
for
this
right.
So
we
do
need
automated
support
because,
as
you
can
appreciate,
you
know,
if
you
change
a
program,
there's
always
a
risk
of
introducing
bugs
plus
the
program
would
need
to
be
changed
if
your
topology
changes.
J
So,
as
I
already
mentioned
kind
of
we,
we
need
to
split
the
program
and
the
way
the
split
is
guided
is
based
on
the
resources
that
different
parts
of
the
program
use,
because
those
resources
ultimately
need
to
be
satisfied
by
the
hardware
target
right,
no
use,
mapping
part
of
a
program
on
a
piece
of
hardware
that
doesn't
have
the
right
amount
of
memory
or
the
right
type
of
memory,
or
that
cannot
operate
at
a
certain
rate
right.
So
we
need
to
do
kind
of
a
resource-based
program
analysis
for
suitability.
J
We
need
to
be
able
to
reason
about
heterogeneity,
so
this
is
the
different
types
of
resources,
a
different
platforms
make
available,
and
we
also
need
to
take
account
of
the
user's
resource
and
performance
objectives.
So
this
is.
This
is
a
particularly
interesting
part
of
the
talk
I
won't
get
into
much
during
today's
presentation,
but
I'd
be
very
happy
to
go.
Go
into
in
more
detail
since
we're
talking
about
different
data
plans.
J
We
need
to
talk
about
placement
right,
so
I
think
derek
mentioned
this
in
his
presentation
earlier,
since
we
have
a
mix
of
data
planes,
you
know
we
don't
have
shared
fate.
We
need
to
talk
about
handover,
we
need
to
talk
about
synchronization,
we
need
to
detect
and
mitigate
and
handle
faults
and
there's
also
a
bunch
of
other.
You
know
other
issues
right
so
there's
we
don't
want
to
make
language
or
hardware
changes,
and
I
have
a
shopping
list
of
various
other
issues,
including
multi-programming
right.
J
If
you're
running
one
program
in
the
network,
you're
gonna
want
to
run
several.
How
do
you
accommodate
that?
And
so
flight
plan
is
a
is
a
system
that
tries
to
accommodate
all
of
this
and
we
have
a
research
prototype
and
it's
available
online
together
with
a
bunch
of
documentation
and
scripts
to
facilitate
reproducibility.
J
I
was
also
very
interested
in
adrian's
talk
earlier
because
there
is
a
rooting
component
to
flight,
but
I
don't
know
to
what
extent
it
overlaps
or
complements
semantic
routing,
but
in
order
to
do
what
flightland
does
you
have
to
kind
of
hijack
routing
right
in
order
to
progress
a
computation
through
a
set
of
devices
that
are
available
in
the
network?
I'll
say
more
about
this
later,
and
the
the
high
level
idea
of
how
flightplan
works
is
that
you
have
a
dataplane
program.
J
It
is
logically
split
into
bits
that
are
physically
mapped
to
specific
devices
and
then
there's
a
linking
process
that
allows
these
bits
of
programs
to
find
each
other
on
the
network.
You
can
see.
I
have
some
duplication
here,
because
it
also
has
an
inbuilt
notion
of
in
data
plane,
failover
right,
so
that
you
can
pre-program
its
reaction
in
case
bits
of
it
become
unavailable
at
runtime.
J
The
actual
workflow
is
a
bit
more
sophisticated
and
I'm
going
to
focus
in
the
time
I
have
I'm
going
to
focus
on
a
couple
of
aspects
that
I
think
are
salient
so.
First
of
all,
I
want
to
point
out.
You
know
this.
You
can
see
this
as
being
a
junction.
All
arrows
kind
of
up
to
this
point
are
pointing
into
the
planner,
and
so
this
is
one
of
the
the
kind
of
intellectual
ideas
that
we're
using
in
this
work
of
reducing
different
types
of
information
to
a
common,
rule-based
representation
in
order
to
make
allocations.
J
Another
thing
kind
of
a
pragmatic
aspect
I
wanted
to
mention
earlier-
is
you
know
this
kind
of
boundary
here
so
here
we're
representing
the
vendor
tool
chains
to
talk
to
different
hardware
right,
that's
typically
closed
and
we're
okay
with
that
right,
so
so
we're
working
with
p4
here,
which,
as
I
mentioned,
can
work
with
a
variety
of
different
hardware,
and
we
wanted
to
try
to
you
know,
walk
the
line
between
research.
That's
you
know
is
a
bit
more,
maybe
feasible
than
you
know.
That
then,
would
otherwise
be.
J
J
Id
hardware
features
I'm
going
to
give
you
an
example
of
how
we
have
shared
programs,
and
this
is
a
p4
snippet
and
I've
highlighted
two
types
of
phrases.
The
orange
phrase
is
an
annotation
that
we
added,
and
this
is
not
added
to
p4.
This
is
picked
up
by
a
preprocessor
that
we
wrote
that
will
create
a
topology
of
of
the
program
and
we'll
create
you
know
segments.
So
so
here
we
have
a
flag
segment
called
compress
here:
a
segment
called
fccm
code.
Anything
between
two
segments
is
considered.
J
J
J
That
might
only
be
supported
on
some
types
of
hardware
targets
and
that
is
used
by
the
reasoning
engine
to
reas
to
decide
where
to
place
them
and
what
type
of
hardware
to
to
place
it
on,
and
this
is
done,
then
digested
into
rules
and
the
programmer
never
sees
these
rules
so
the
programmer,
who
knows
before
only
works
with
mp4
and
and
this
this
dimension
is
abstracted
entirely
for
the
programmer.
So
this
is
basically
saying
if
you
want
to
execute
a
segment
called
compress,
then
to
make
sure
that
these
three
resources
are
available.
J
J
The
other
thing
we're
abstracting
is
hardware
features,
so
we're
using
a
similar
mechanism
here.
So
what
I'm
showing
you
here
is
that
we're
capturing
a
profile
of
running
a
particular
function
on
a
cpu
compared
to
running
it
on
an
fpga,
and
there
are
certain
parameters,
such
as
the
rate
and
the
package
size.
These
vary
and
what
this
is
showing.
You
is
kind
of
the
the
side
effect
of
running
this
function
on
this
platform.
If
it
were
to
be
successful,
then
the
profile
the
response
would
change
in
in
some
specified
way.
J
J
J
I
know
packet
load
and
also
in
terms
of
memory
on
the
devices
or
you
can
trade
it
up
and
there's
a
bit
level
analysis
of
that
in
the
paper.
So
to
I'm
going
to
start
concluding,
I'm
just
going
to
mention
evaluation.
There
are
various
aspects
of
this
that
were
evaluated.
One
of
my
favorite
aspects
is
running
multiple
programs
that
are
split
in
different
ways
and
running
on
multiple
runtimes
within
the
same
network,
because
we
wanted
to
test
this
idea
of
you
know.
J
If
you
have
a,
if
you
have
multiple
people
using
the
network,
then
typically,
they
might,
you
know,
have
their
preferences
about
how
they
want
to
what
they
want
to
run
and
how
to
go
to
split
it.
So
this
is
an
example.
We
did
in
simulation.
Other
evaluation
results
were
done
on
physical
hardware
and
the
basically,
this
is
showing
we
have
kind
of
a
little
topology
here
with
different
runtimes
and
different
splits.
J
So
one
of
the
things
that
is
very
low
effort
is
you
could
try
our
demo,
which
takes
virtually
every
single
figure,
for
example.
This
is
the
one
I
just
showed
you
and
makes
the
experiment
interactive,
and
you
can
play
it
and
you
know
so.
This
is
showing
you
packets
being
fired,
and
this
is
a
reduced
experiment
right,
so
we
simplified
it
a
bit
to
reduce
clutter
and
what
you're
seeing
here
is.
J
H
J
J
So,
as
I
mentioned,
so
that's
that
kind
of
the
a
very
kind
of
quick
tour
of
flight
plan.
As
I
mentioned,
I
started
at
at
illinois
tech
a
couple
of
months
ago,
I'm
very
interested
in
continuing
to
work
in
this
general
direction,
which
also
brought
me
to
to
coin-
and
you
know
I'm
just
putting
this
out
to
to
in
case
you
want
to
reach
out
about
you,
know,
collaboration
and
discuss
programmability.
I'm
very
keen
on
that.
J
One
recent
things
I've
been
I've
been
working
on
is
extending
what
I
talked
about
that
interfaces
in
network
programming
with
the
network
to
include
application
level
concerns
right.
So
ultimately
we
wanted
to
serve
applications
right.
Otherwise,
what's
the
point
in
having
a
network-
and
I
want
I've-
got
a
paper
and
a
prototype
on
how
to
extract
some
features
or
applications
and
have
the
network
program
and
the
planning
using
flight
plan
to
kind
of
interpose
and
and
help
facilitate
those.
The
realization
of
those
features
right.
J
J
H
H
We
we
can
take
this
offline,
but
I
think
that
could
be
maybe
something
you
could
present
at
the
next
meeting
next
month.
What
are
your
thoughts
about
this,
because
that
would
be
linking
flight
plan
into
work?
That's
already
existing
in
this
research
group.
I
just
saw
that
dirk
joined
the
queue
so
go
ahead.
Dirk.
C
C
How
can
we
bridge
this
say
dichotomy
between
like
networking
devices,
network
elements
and
say
servers
and
so
yeah?
Of
course,
one
approach
has
always
been
okay:
let's
use
data
plane
probability,
so
p4
probability
and
people
have
developed,
say
individual
point
solutions
in
this
direction
and
I
think
your
work
is
a
really
nice
say
next
step
forward
towards
say
it's
a
slightly
more
more
powerful
and
more
networked
approach
to
like
this,
this
topic.
C
So
when
one
question
though,
so
what
do
you
think?
What
would
be
the
kind
of
programs
that
you
would
primarily
program
in
this,
like
virtual
for
women
layer?
Would
this
be
something
more
like
you
know
like
forwarding
enhancements
so
like
more
like
networking
functions,
or
do
we
also
envision
some
like
more
application
logic.
J
Thank
you
for
the
question
and
and
by
the
way
our
past
has
crossed
in
cambridge
many
years
ago.
So
I
just
want
to
say
hello.
It's
it's
very
nice
to
be
in
touch
again.
So
so
the
answer
to
your
question
is:
we've
looked
at
all
three,
so
let
me
give
you
an
example.
So
this
is
a
an
evaluation
I
didn't
get
to
cover
in
the
talk,
but
this
is
an
opportunity
to
to
cover
it
a
bit
more.
So
this
is
a
testbed
evaluation.
J
J
Now
what
we
we're
using
flight
plan
for
here
is
to
improve
the
functioning
of
the
network,
but
also
kind
of
keep
an
eye
on
how
applications
are
responding
to
this
right,
but
applications
as
we
all
know,
they
sit
on
top
of
a
stack
that
can
quesi
autonomously
take
actions
right
so
so
hyper.
For
example,
this
is
funneling
over
a
tcp,
and
you
know
it
is
sensitive
to
to
the
congestion
in
the
network,
and
so
what?
J
What
I'm
going
to
show
you
here
is
kind
of
a
progression,
an
evaluation
of
an
experiment
where
we're
measuring
power
throughputs
and
success
and
latency
of
the
key
value
lookup
and
set
okay.
So
this
is
the
the
base
state,
and
what
we
can
see
is
that
the
latency
is
it's
going
to
show
up
as
being
high,
because
you
know
it's
being
contented
by
by
so
what,
as
this
progresses,
is
we're
going
to
activate
functions
right,
so
this
is
going
to
be.
J
This
is
a
distributed
program
in
in
flight
plan
and
and
I
think
it
will
cover
the
point
behind
points
you
raise
right
in
relation
to
to
forwarding,
but
also
in
relation
to
applications.
So
what
happens?
Is
we
add
header
compression
right?
So
so
this
is
transparent
to
reduce
the
contention
that
ip
that
iperf
has
and
what
we
notice
is
that
latency
drops
right.
So
more
more
mphd
queries
get
through
both
sets
and
gets.
Next
thing
we
do.
J
It's
not
just
forwarding
right.
It's
also
doing
this
in
network
computing.
That
is
rather
intensive.
We
see
that
tcp
is
a
bit
happier.
Therefore,
iperf
is
a
bit
happier.
We
see
that.
However,
you
know
this.
This
is
I'm
casey's,
oblivious
to
that.
So
the
last
thing
we
added
was
a
key
value
cache
in
the
network.
So
this
is
talking
more
towards
the
end
of
your
question,
which
was
about
applications,
so
we
have
more
power.
J
Tcp
doesn't
care
because
this
this
this
is
working
over
edp,
but
what
we
see
is
that
you
know
successful
gets
improves
so
so
part
of
the
application's
experience
has
improved.
Sets
still
needs
to
go
through
the
lossy
link.
We
put
this
cache
before
the
lost
link,
so
you
know
it's
a
bit
of
a
nuanced
answer:
it's
not
yes
or
no!
It's
a
bit
of
both
because
it
depends
on
whether
you're
focusing
more
on
read.
J
Workloads
and
latency
again
so
so
the
biggest
note
results
we
see
here
is
that
latency
can
drop,
because
suddenly
the
cache
is
much
closer
right.
So
if
we
have
a
cache
hit,
then
we
get
to
reply
very
quickly.
Otherwise,
if
it's
a
miss,
then
it
still
needs
to
go
back
to
the
server
right.
So
sorry,
this
was
a
slightly
more
lengthy,
but
hopefully
more
information,
rich
and
stereo.
To
to
to
your
question
right
about
what.
A
Any
other
questions.
Yes,
thank
you
so
much.
I
really
appreciated
the
discussion
here
about
routing
in
the
service
of
compute,
because
you
know,
as
you
could
hear
from
the
previous
discussion
in
the
mailing
list.
There's
you
know
often
this
contrast
with
compute
in
the
service
of
routing,
and
I
think
we
need
a
little
bit
of
both,
but
it
was
refreshing
to
see
to
hear
this
contrasting
narrative
and
framework,
and
so
thank
you
for
coming
in
and
sharing
this.
J
So
you
know
it's
not
a
full
kind
of
routing
protocol,
but
it
gives
it
some
some
some
metrics
to
keep
an
eye
on
and
some
ability
to
actuate
some
some
changes-
and
you
know
you
know
it's
it's.
I
think
there's
a
lot
of
space
here
to
to
try
to
optimize
across
time
scales
right.
So
one
of
the
challenges
we
often
face
in
routing
is
that
the
time
scale
of
forwarding
is
at
one
level,
but
the
time
scale
of
routing
is
a
at
a
much
lower
level.
J
H
I
will
let
you
present,
but
I
will
introduce
your
talk
great,
so
this
experiment
that
I
did
with
about
15
students
at
parisud
and
nicoleta
will
present,
which
is
great
and
what
we
did
is
a
class,
a
project
class
on
computing
in
the
network,
and
we
essentially
started
with
a
lot
of
com.
You
know,
I
would
say
complex
ideas,
but
the
project
itself.
H
It
was,
we
didn't
have
hardware,
we
couldn't
do
p4
we
tried,
we
tried
to
use
the
p4
pi,
which
is
pi,
but
we
didn't
have
pi
either.
So
in
order
to
get
the
brains
going,
we
started
thinking
okay
and
eve.
It's
going
to
be
computation
and
the
service
of
applications.
In
that
case,
it
was,
let's
think,
let's
take
an
application
that
is
running
right
now
and
let's
break
it
down.
So
let's
do
the
life
of
a
packet,
what
happens
to
packets
when
they
cross
the
application?
H
What
would
change
in
the
application
or
in
the
life
of
that
packet?
Would
that
packet
be
sent
somewhere
else?
Would
that
packet
meet
likely-minded
other
packets?
Would
new
services,
be,
you
know,
included
or
excluded
and
nikoletta
and
team?
They
took
the
smart
city,
and
this
is
their
presentation:
smart
lights.
Once
you
have
networking
and
processing
being
together
in
a
smart
city,
so
nikoletta
you
can
actually
talk
for
just
a
few
minutes.
D
H
K
L
K
All
right
perfect,
so
I
will
just
try
to
speak
around
this
because
we
only
have
a
few
minutes.
So
thank
you
so
much
for
the
limitation.
My
name
is
randarisa,
and-
and
we
did
this
project
with
our
professor-
so
basically
it
was
just
a
proposal
to
solve
the
traffic
problems
and
really
big
cities,
since
this
is
a
time
management
problem
and
and
also
an
environmental
one.
K
D
Yes,
so
the
thinking
of
the
computational
program,
we
will
use
the
information
collected
to
design
training
test,
the
machine
learning
algorithm
and
we
expect
to
find
different
patterns
among
the
variables
and
identify
the
relationship
between
them
to
produce
a
program
that
will
optimize
the
flow
of
traffic.
Through
the
waiting
time
of
its
channel.
We
will
train
and
program
to
identify
accidents
and
other
exceptional
cases
to
plan
and
create
alternative
paths
in
order
to
keep
the
traffic
flow
mostly
uninterrupted
and
clear.
F
D
To
check
that
our
program
is
functioning
reliably
in
real
life,
we
will
use
ai
cups,
which
are
actually
the
smart
cameras
we
used
before
to
gather
information
data
in
the
initial
study,
and
this
camera
should
provide
real-time
information,
which
is
our
full
computing
part
that
will
first
be
sent
and
stored
in
the
local
servers,
which
is
the
edge
computing
part
of
our
project
and
then
to
the
main
servers
of
the
city,
which
is
our
cloud
computing
part.
These
are
the
three
main
parts
of
our
project.
D
K
So
yeah
that
was
in
general,
that
was
what
we
made
dora
explained
it
perfectly.
I
think
so.
We
wanted
to
break
down
the
system
and
then
put
it
back
again
to
understand
how
a
city
works
and
how
to
optimize
traffic.
So
we
have
the
fog
computing
part
to
understand
the
little
parts
of
the
city
and
then
the
edge
computing,
and
then
the
cloud
computing
to
put
it
together.
H
Guys
so
the
point-
the
point
here
is:
thank
you
very
much
for
being
available
and
for
doing
the
work,
and
I
think
this
this
is
actually
the
wrap
up,
but
I
would
say
you
know
we
are
a
community
and
I
think
maybe
the
best
way
of
expanding
the
community
is
teach
them.
So
thank
you
very
much
to
you
and
actually,
to
the
whole,
the
whole
class,
which
was
very
patient
with
me.
I
think
we're
wrapping
up,
I
think
so
the
whole.
H
I
think
there's
a
lot
of
questions
that
are
on
the
on
the
the
the
chat,
and
so
I
guess
there
will
be
more
discussions
going
on.
We
are
meeting
in
about
a
month
and
a
week
which
will
be
two
weeks
two
years
after
the
first
meeting
was
cancelled,
so
it
will
be
hybrid.
I
think
most
of
us,
the
chairs
will
be
online,
but
we
welcome
ideas
for
presentations.
H
H
I
think
our
charter
is
wide
enough
to
be
an
umbrella
for
the
research
that
has
been
going
on,
and
I
think
we
like
the
fact
that
our
community
has
greatly
expanded
and
phillip
the
idea
that
the
thing
is
that
this
is
all
this
is
all
our
architecture
right
now
we
didn't
have
the
time
nor
the
money
to
do
anything
else,
but
there's
cool
stuff
there.
If
you
want
to
talk
to
them
anyway,
so
wrapping
up,
let's
meet
you
guys
again
in
about
a
month
and
a
month
and
a
week.
H
Thank
you
for
all
the
presenters.
Thank
you
to
everybody
who
participated,
contributed
been
on
the
chat
been
here.
Thank
you
to
the
discussions
that
happened
before
on
the
list.
I
think
heated
discussions
are
always
necessary
to
to
bring
things
forward,
so
I'm
a
big
fan
of
that
and
again
would
jeff
or
eve
want
to
add
something
else.