►
From YouTube: CNCF SIG Network 2020-05-07
Description
CNCF SIG Network 2020-05-07
B
A
B
B
B
A
B
A
B
C
Awesome
well,
this
is
my
first
sig
meeting.
So
thank
you
for
having
me
and
thank
you
for
giving
the
opportunity
to
present
on
what
I've
been
working
on.
I
have
a
slide
deck
and
if
we
have
questions,
I
am
happy
to
answer
questions
afterwards,
but
also
during
the
talk
feel
free
to
stop
me.
If
anything
comes
to
mind.
So
let
me
if
I
can
switch
to
screen,
share,
look
at
that
and
then
let's
try.
C
Oh
good,
awesome
awesome.
So,
as
I
mentioned,
you
know
it's
my
first
time
presenting,
but
I'm
actually
working
on
a
proposal
for
the
upcoming
kubecon,
so
this
is
sort
of
a
good,
forcing
function
to
to
get
ready
for
that
if,
if
it
happens
but
anyway,
the
this
topic
is
something
I've
been
working
on
in
my
spare
time
and
it's
out
of
the
interest
and
necessity
for
my
startup
that
I'm
working
on
and
it
turned
out
to
that
it
could
be
useful
for
the
community.
C
So
a
bit
about
me,
I'm
a
product
manager.
I
worked
at
companies
like
google
nest
for
a
bunch
of
years.
It's
startups
and
and
everything
in
between
the
company
I'm
working
on
is
an
iot
startup
we
haven't
launched
yet,
and
my
background
is
in
iot
and
protocols
and
things
of
that
sort-
and
you
can
find
me
afterwards
on
twitter.
My
her
handle
is
bare,
bear
kicks
kind
of
a
boring,
lame
name
but
funny
story,
and
it's
in
and
of
itself.
B
C
It
was
a
a
long
time
ago,
I
think,
like
eight
years
ago
and
were
coming
up
with
twitter
handles
and
I
kept
on
doing
combinations,
there's
a
very
popular
twitter
generator
at
the
time
and
it
kept
on
coming
up
with
very
berry,
which
is
a
you
know,
immune
deficiency
or
vitamin
deficiency
disease
and
my
co-worker
it
was
in
the
morning
was
eating
cereal
and
he
was
eating
berry
berry,
kicks
cereal
and
and
yeah.
It
was
a
group
vote
and
that's
how
I
got
I'm
very,
very
kicks
yeah.
C
But
anyway
I
mentioned
that
I'm
working
on
an
iot
platform
and
if
you're
not
really
familiar
with
the
space,
an
iot
platform.
You
know
the
fundamentals
is
trying
to
have
a
tea,
a
thing
that
has
internet-
and
you
know,
do
something
interesting
and
and
talk
to
the
cloud
and
that
cloud
infrastructure
is
doing
a
lot.
C
On
behalf
of
that
thing,
it's
doing
the
communication
between
the
device
and
the
cloud
and
the
cloud
device
or
or
device
messaging
security
firmware
updates
a
whole
bunch
of
other
stuff,
but
for
the
context
of
networking,
and
we
really
care
about
this.
This
device
messaging
component
and
part
of
that
is
related
to
iot
protocols
and
so
iot
protocols.
Your
networking
protocols,
if
you're,
not
you're,
not
into
the
space.
C
But
many
of
them
are
either
cloud
friendly,
so
they
they
talk
to
some
backend
or
have
some
way
to
do
it
or
cloud
native
in
the
context
of
they
have
definitions
of
how
to
talk
to
the
cloud
and
and
in
part
because
they're
oftentimes
ip
based.
So
it's
it's
really
natural
to
integrate
that
with
the
cloud
backend-
and
you
know
this.
This
kind
of
brings
me
to
what
I'm
working
on
you
know
as
a
platform.
We
want
to
support
many
protocols
over
time.
C
We
want
to
do
it
in
a
way
that
scales,
so
we
don't
have
to
you,
know
hack
different
implementations
and
fake
ip,
or
do
some
protocol
marshalling
so
to
give
you
sort
of
how
we're
thinking
about
this
problem
and
how
we're
coming
into
the
cloud
native
space
and
why
I
call
it
the
ecosystem
is
we're
looking
at
is
sort
of
an
iterative
approach,
so
this
very
first
architecture,
we've
built.
It
looks
something
like
this
right.
You
have
the
device
again
on
the
left.
C
It's
talking
over
the
internet
to
the
cloud
that
it's
using
one
of
these
protocols.
It's
co-op,
it's
an
ietf
standard.
It's
a
udp-based
protocol
and
the
interesting
part
is
really
our
gateway,
and
that
speaks
co-op
on
the
other
end
and
within
the
the
cluster
it's
forwarding
basically
ip
packets
around
that's
very
simplistic.
It's
really
not
cloud
native
at
all.
C
Different
applications
talk
to
each
other
and
ideally
in
the
native
protocol
that
the
device
spoke
and
there's
some
benefits
there,
of
having
native
iot
protocols
from
device
to
the
far
edge
or
to
the
back
end.
But
that's
not
so
important
for
this
context,
and
then
you
know
the
last
part
is
adding
incrementally
more
capabilities,
for
example
like
like
serverless,
and
this
is
just
a
frame
how
I've
been
thinking
about
the
space
and
how
we've
been
building
to
it
and
kind
of
how
we
got
to
this.
C
This
survey
that
we've
been
we've
been
working
on.
It's
not
an
all-nothing
binary
switch
of
becoming
cloud
native,
but
it's
looking
at
the
landscape
of
what
we
can
leverage
to
build
a
new
type
of
iot
platform
cool
and,
if
you're
curious
about
any
of
these
details,
I'm
happy
to
chat
more
about
it
later.
C
So
at
the
time
I
raised
an
issue
on
envoy
to
try
to
poke
at
this
problem.
This
is
really
early
thinking
and
this
content
is
actually
in
the
survey
as
well,
because
udp
was
just
being
turned
on
in
alpha
on
envoy
and
within
the
project.
There
were
tcp
protocols
that
were
also
supported,
but
by
and
large
http
was
where
a
lot
of
the
effort
and
capabilities
were
there,
and-
and
I
mean
that
makes
sense
and
most
of
the
customers
who
use
envoy
are
doing
some
sort
of
http
traffic
and
proxying.
C
C
You
know,
for
example,
in
gaming
or
telephony,
and
so
the
question
I
raised
was
what
would
it
take
or
how
would
we
enable
people
to
implement
their
own
protocols,
their
own
l7,
like
protocols
on
top
of
envoy,
that
weren't
http
http,
and
you
know
what
would
that
be
like?
Does
it
require
just
best
practices?
Is
it
modifying
some
of
the
accessibility?
C
This
is
before
wasm
proxy
was
available
available.
Is
it
a
spec
or
what
would
it
take
and
that
began
the
rabbit
hole
of
understanding
this
difference
between
l7
and
http,
as
as
one
category
and
kind
of
the
bulk
of
the
work?
That's
already
been
done
and
everything
else,
and
so
I
came
away
with
that
on
looking
at
envoy
and
talking
to
matt
from
the
from
the
project
that,
broadly
speaking,
cloud,
the
cloud
native
landscape
is
really
optimized
for
http
and
that
just
makes
sense
right.
C
The
majority
of
the
workloads
that
the
cloud
serve
are
http
traffic
web
apis
and
things
like
that
nature
and
as
a
result,
though,
the
projects
in
that
landscape
have
a
lot
of
assumptions
around
the
the
traffic
being
http
based
and
potentially
areas
where
it's
harder
to
implement
non-hp
based
protocols-
and
you
know
the
as
I
started
thinking
about
myspace
and
iot.
I
found
other
people
who
are
looking
to
this
exact
same
problem.
C
So
I
mentioned
gaming
earlier
gaming
protocol
gaming
systems
use,
you
know,
alternative
protocols
for
games,
synchronization
for
game
chat
and
communication,
and
they're
also
trying
to
figure
out
how
they
could
build
gaming
platforms
on
top
of
cloud
and
even
kubernetes
so
project
agonis
is
one
project
from
google.
It's
open
source.
They
also
have
a
hosted
version,
and
it's
for
the
game.
C
Servers
themselves
and
mark
over
at
google
was
looking
to
build
a
sync
server
on
top
of
a
gonis
looking
into
envoy,
and
we
both
bumped
into
each
other
of
trying
to
run
a
udp-based
protocol
and
there's
really
no
good
solution
today.
So
they
have
a
sample
in
their
github
repo
and
they
they're
not
they're,
not
trying
to
solve
right
now.
C
Another
use
case
is
telephony
and
real-time
communication
and
specifically
webrtc
comes
up
a
bunch.
Pion
is
actually
a
set
of
services,
libraries,
open
source,
a
project
for
webrtc
and
all
the
other
lower
bits
that
you
need.
That's
actually
really
cool
project
and
go
and
and
sean
who's
the
lead
over.
C
B
C
C
Functionality
now
and
you
know,
scale
up
scale
down
and
the
very
specific
algorithms
that
game
developers
have
developed
over
time
of
scaling
and
routing
and
matchmaking,
and
you
know
leveraging
that
on
top
of
kubernetes,
it's
a
really
cool
project.
What
and
that's
just
you
know,
service
serving
right
when
it
comes
to
the
in-app
services,
so
one
in
particular
is
game.
State
synchronization!
C
C
So
you
build
a
gamesync
server
and
those
are
pretty
complicated
to
develop
and
as
an
industry
they
have
a
couple
de
facto
protocols
to
synchronize
the
state
of
the
virtual
world,
they're
largely
based
off
udp.
There's
no
single
one,
but
they
effectively
do
similar
things
serialize
the
data
synchronize
it
through
some
sort
of
synchronization
system
and
enable
game
developers
to
just
pull
in
an
api
to
or
library
to
to
do
that.
C
C
Yeah
yeah,
so
it's
effectively
re-implementing
all
the
webrtc
functions
and
protocols
that
are
needed
to
to
implement
a
client,
a
server
and
even
abstractions.
On
top,
so
the
the
the
most
complete
implementation
of
webrtc
comes
from
from
chromium,
and
so
there's
basically
a
rewrite
from
go,
but
the
some
of
the
harder
parts
were
the
protocols
that
webrtc
uses
because
webrtc
and
it's
a
collection
of
specs.
C
It
uses
a
collection
of
protocols
some
for
the
video
streaming,
some
for
the
data
channels,
which
is
the
you
can
send
you
know,
say,
text
data
or
other
type
of
data.
On
top
of
that
that
pipe
it's
based
off
of
udp,
it's
based
off
of
tcp,
it's
based
off
of
sctp.
So
it's
a
pretty
complicated
suite
of
protocols
and
you
know
pion
has
implemented
those.
C
As
you
know,
standard
go,
go
libraries,
interesting,
okay,
yeah,
yeah,
and
you
know
it
when
it
comes
to
the
sort
of
routing
and
load,
balancing
and
connections.
Webrtc
has
similar
problems
and
challenges
that
gaming
has,
which
is
similar
and
to
some
iot
use
cases.
So,
for
example,
when
you're
roaming,
the
behavior
of
network
traffic,
say
on
your
cell
phone
or
your
connected
scooter
running
around
the
bay
area
to
a
player
on
a
mobile
phone
to
a
a
device
that
might
be
hopping
between
different
base
stations.
C
You
know
those
kind
of
networking
challenges
are
solved
at
the
protocol
layer
and
are
very
interesting
and
useful,
but
also
need
to
be
integrated
into
your
network
management
layer.
So,
for
example,
if
you
want
to
do
congestion,
control
right
congestion
control
for
that
game,
server,
I
would
imagine,
is
finally
different
than
congestion
control
for
the
the
webrtc.
And
what
I
know
more
about
is
the
congestion
control
for
an
iot
device
that
might
be
on
a
cellular
link
or
a
satellite
link
or
an
ethernet
link.
C
And
so
this
is
kind
of
really
just
background
for
this
document.
I've
been
working
on
and
somehow
the
screenshot
got
downraized
and
at
least
in
my
view,
and
that's
the
link
for
anyone
to
go
check
it
out.
What
I
effectively
did
was
starting
out
with
my
own
iot
use
case
and
looking
at
that
progression
from
simple
ingress
of
data
from
the
iot
device
to
the
to
the
cluster
over
that
iot
protocol.
C
What
are
the
pieces
of
kubernetes
that
exist
today
that
deal
with
protocols
and
deals
with
non-http
traffic
what's
possible
today?
What's
what's
in
a
cap
or
something
else
and
then
going
through
okay?
Well
now,
if
I
want
to
stand
up
a
proxy
like
envoy,
what
parts
of
envoy
assume
http
has
already
implemented,
capabilities
of
http
and
and
so
on,
so
the
stock
is
this
ongoing
survey
that
I've
been
developing
and
it's
it's
actually
going
quite
well.
I
put
you
know
a
week
of
worth
of
effort
to
understand.
C
Each
project
is
a
better
degree
of
detail,
but,
more
importantly,
I
was
able
to
convince
some
of
the
project
leads
and
implementers
from
each
one
to
comment
in
and
validate
what.
I'm
saying
and
add
more
context
and
debate
and
discuss
how
well
each
one
is
solving
for
so
it
took
about
a
week
just
to
kind
of
cover
the
basics
of
tribunities
and
envoy
and
service
meshes.
Then
a
lot
of
good
feedback
came
from
other
folks
around.
Oh,
you
should
look
at
other
aspects
like,
for
example,
cloud
events.
C
C
It's
still
flagged
as
draft,
but
it's
probably
a
little
bit
more
then
draft
at
this
point-
and
this
is
the
reason
why
I
wanted
to
share
with
this
group
and
just
if
someone
doesn't
have
time
to
read
this
or
hasn't
read
it
just
yet.
I
just
want
to
give
you
a
quick
example
of
what
kind
of
analysis
I'm
doing
and
others
are
helping
me
do
and
sort
of
how
I'm
presenting
it.
So
both
the
description
and
the
takeaway.
So
this
is
the
smi
spec.
C
You
know
it's
a
defining
standard
interface,
I'm
not
gonna,
be
the
whole
thing.
The
current
focus
is
hd.
The
goal
is
to
support
more
protocols,
and
so,
for
example,
there's
this
traffic
specs
and
you
can
add
new
traffic
specs
via
crds,
so
the
takeaway
for
smi
is
that
it
should
be
able
to
support
alternative
protocols,
as
it
does
already
define,
http
and
tcp
and
provides
a
traffic
spec
as
a
corollary,
there's
some
other
parts
that
don't
have
a
way
to
extend
in
a
protocol-agnostic
way.
C
So
my
ass
for
the
group
is,
if
you're
watching
it
now
live
or
if
you're
watching
it
later.
Please
take
a
look
at
the
doc.
I
would
love
comments,
feedback,
any
additional
takeaways
that
I
may
not
have
hit
on,
or
we
haven't
hit
on
yet
potentially
new
areas
to
investigate
to
really
build
out
this
as
a
true
landscape
survey
to
help
everyone
who's
working
on
these
projects
and
I'd
say
specifically
for
for
the
sig
and
why
I
asked
to
present
is
you
know?
C
C
What's
the
best
way
to
help,
you
know
enable
this
to
be
useful
and
engage
with
with
the
sick,
I'm
also
very
new
to
to
working
with
cncf
projects
and
if
there's
any
other
sigs
that
I
should
be
presenting
to
or
sharing
this
information
that
might
have
interest
or
insights.
That's
that's
really.
You
know.
How
can
I
make
this
better
and
more
helpful,
yeah
and
quick
summary
I'm
working
on
quantitative,
iot
infrastructure,
largely
I'm
noticing
that
cloud
is
optimized
for
hp.
C
Sometimes,
alternative
protocols
are
hard
to
implement
and
there's
a
lot
of
different
use
cases
from
other
folks
beyond
iot
that
might
be
interested
in
this,
and
my
goal
is
to
really
make
it
possible
or
at
least
easier
to
support
new
protocols.
Oh
and
these
slides
are
available
if
you're
interested
and
thank
you
and
questions.
B
B
A
couple
a
couple:
random
thoughts
like
like
actually
the
the
example
with
respect
to
smi
supporting
additional
traffic.
It's
a
timely
discussion
as
there's
kind
of
an
active
there's,
an
active
discussion
happening
on
support
for
udp
and
yeah.
The
more
service
meshes
that
participate
there,
the
more
each
of
them
bring
a
little
bit
of
a
diverse
use
case
for
additional
protocol
support.
As
an
example.
B
Speaking
of
that,
maybe
I'll
I'll
poke
it
at
ed
for
a
moment
and
say
ed
of
with
your
nsm
hat
on,
do
well,
I
get
well
here
I'm
going
to
maybe
try
to
ask
two
questions
at
once,
and
that's
that
jonathan
of
of
some
of
the
protocols
that
you
look
at
have
any
of
those
been
multicast
use
cases.
Things
like
you
know
trying
to
get
the
right.
D
D
Yeah,
I
I
think
I
think
I
think,
basically,
what
lee
is
trying
to
sort
of
set
up
as
a
softball
pitch.
For
me,
which
is
appreciated,
is
that
you
know
effectively
when
you,
when
you
talk
about
this
stuff.
If
you
have
things
that
want
to
think
like
live
life
at
l7
and
think
of
l7
right,
then
by
all
means
you
should
absolutely
be
going
and
figuring
out
how
to
get
additional
stuff
into
envoy
and
that
kind
of
stuff.
D
I
mean,
if
you
ever
really
really
want
to
to
get
a
room
laughing,
go
to
a
nog
meeting
and
suggest
you
know
the
implementation
of
multi-service
provider
multicast
they
will.
They
will
either
be
you
senseless
or
laugh
you
off
the
stage,
maybe
both,
and
so
you
know,
if
you
have
things
and
or
if
you
have
things
that
are
more
easily
solvable
down
at
that
layer
than
they
may
be
at
l7.
D
C
Yeah,
I
am
yeah
thanks
for
for
the
the
context
the
nsm
was
actually
pretty
new
to
me.
I
just
learned
about
it
last
week,
so
I'm
excited
to
dig
in
further
awesome
and
I
I
think
that
to
lee's
earlier
question.
Yes,
there's
definitely
protocols
that
are
multicast.
You
know
both
on
the
rtc
side,
as
well
as
in
the
iot
side,
and
in
my
experience
in
working
at,
for
example,
a
nest
we
used,
ipv6
multicast
heavily,
but
only
on
the
local
network,
and
that's
largely
because
you
can't
really
go.
D
It's
just
it's
not
going
to
work,
but
if
you're
operating
on
the
scale
of
an
application
that
has
workloads
in
different
places
that,
if
you
were
to
put
them
all
into
a
single
data
center
multicast
would
be
reasonable.
Then
you
can
make
multicast
reasonable
for
a
network
service
that
is
servicing
those
workloads
wherever
they
may
be.
Does
that
make
sense?
Yes,
yes,
it
does,
and
so
like
that,
opens
up
some
interesting
doors
in
terms
of
how
you
might
want
to
handle.
D
That
stuff
be
honest,
I
mean
that
that's
that's
interesting
possibility
because
you're,
not
the
only
people
who
abuse
multicast
locally,
not
at
all,
I
would
go
so
far
as
abused.
Well,
I
mean,
and
the
other
thing
is
you
can
do.
I
don't
know
if
you're
familiar
with
beer,
not
the
beverage,
okay,
yeah
beverage.
No
so
like
this
is
an
attempt
by
some
of
the
to
make
multicast
more
scalable,
not
scalable.
E
D
The
internet
providers
are
ever
gonna,
get
on
board,
but
more
scalable
than
things
like
pim,
for
example,
and
some
of
its
relatives,
which
scale
very
poorly.
I
actually
I
have
scars.
I
cut
my
teeth
very
early
in
my
career,
trying
to
do
large
scale,
testing
of
multicast-
and
oh
my
god
so,
but
yeah
so
anyway,
like
we
would
love
to
chat
with
you
if
you
go
ahead
and
feel
free
to.
Thank
me
I'm
on
the
cnc
slack.
C
D
Absolutely
and
like
I
said,
we're
we're
we're
very
much
a
compliment
to
traditional
application
service
match
like
if
you
need
to
understand
higher
liars,
we're
not
going
to
do
that
for
you.
Lots
of
people
do
that
really
really
intelligently
at
this
point.
But
if
your
problem
can
be
sold
at
lower
layers,
then
man
we
got.
C
We
got
solutions
for
you,
yeah,
and
I
I
my
gut
is
especially
just
kind
of
thinking
about
different
implementations
of
these
l7
protocols
is
shelby
a
percentage
of
protocols
that
have
to
live
in
both
worlds
right.
There
there
will
be
have
to
be
something
around,
for
example,
operators
how
they
think
about
their
their
their.
You
know
tcp
udp
traffic
and
leverage
some
of
the
some
of
the
service
mesh
stuff
at
that
layer,
as
well
as
implement
the
high
level
protocol.
D
And
like
one
of
the
things
we've
actually
looked
at
in
our
service
mesh,
we
had
to
talk
at
an
smc
about
it
is
taking
a
traditional
application
service
mesh
and
running
on
top
of
a
network
service
so
that
you
can
get
the
particular
kind
of
behavior
that
you
need
for
your
workloads
over
that.
So,
for
example,
if
you're
deploying
into
a
cluster
that
has
already
got
a
service
mesh
for
the
cluster
and
it's
not
a
service
mesh,
that's
going
to
support
the
magical
things
that
you
want.
You
would
have
a
network.
D
All
of
those
needs
you
can
make
it
work
for
very
common
denominator
needs
and
the
kubernetes
community's
done
that
very
well.
But
if
you've
got
niche
needs
the
probability
that
you're
going
to
convince
your
run
time
to
meet
your
niche
needs
without
adversely
impacting
other
people
lower,
and
even
if
it
won't
adversely
impact
them.
There's
a
lot
of
discussion
and
work
and
blah
blah.
C
Blah
make
it
happen.
Yeah
I
mean
you
know,
pre-orchestration
and
containers.
The
majority
of
architectures
for
iot
were
literally
separate
domains
and
separate
teams
right.
You
have
your
device
front-end
suite
of
services
that
handle
device,
communication
and
device
management
talks
over
some
sort
of
you
know
to
second
effectively
cluster,
but
you
know
set
of
services
managed
by
a
different
team,
so
that
makes
tons
of
sense
when
you
wanna
combine
them,
but
also
let
the
people
who
focus
on
that
part
of
the
problem
space
have
their
own.
D
One
of
the
things
that's
actually
super
interesting
that
we're
figuring
out
is.
It
turns
out
that
one
of
the
major
advantages
we
have
is
actually
has
to
do
with
administrative
domains,
not
connectivity,
domains
in
that,
if
you
think
about
the
world
as
a
single
administrative
domain,
possibly
so
divided
on
a
hierarchy
tree
that
works
great
if
you're
in
a
single
organization,
but
the
minute
you're,
not
where
you've
got
two
hierarchy:
trees
in
the
administrative
control,
that's
where
almost
everything
breaks
down
and
we're
actually
designing
for
that
scenario.
C
D
C
Yes-
and
you
know
just
another
use
case-
to
throw
out
there
when
it
comes
to
carrier
integrations,
I
I
through
a
slide
about
that
a
lot
of
times.
If
you
have
a
deep
partnership
with
a
carrier,
they
might
actually
deploy
an
application
in
your
in
your
environment
that
talks
directly
to
their
network
and
that
has
special
requirements,
very
complicated
network
routing
logic
and
yeah.
So.
D
B
Today,
I
import
was
doing
what
ed
was
saying
which
is
sort
of
poking
at
head
poking
at
kind
of
my
point
of
my
area,
an
area
of
interest
for
me
around
multicast,
given
that
matt
is
here
as
well
and
just
in
context
of
let
me
ask
an
ignorant
question
kind
of
in
context
of
iot
and
embedded
devices,
matt,
the
mobile
library,
the
sort
of
the
envoys
mobile
library
or
the
mobile
edition
of
envoy.
If
I
could
characterize
it
like
that,
is
there
a
is
jonathan?
F
Probably
not
just
because
most
of
the
iot
devices
are
running
on
microprocessors
and
operating
systems
and
constrained
environments
that
they
can't
it
can't
run
on
boy
now
over
time.
You
know
for
smart
devices
that
are
running
linux
and
are
running
application,
processors
and,
like
mcus,
that
actually
I
am
and
can
run
envoy.
I
think
it's
possible
for
a
lot
of
iot
devices.
F
You
know
that
are
deployed
today.
It's
not
it's
not
really
an
option
like
most
of
those
devices.
They
don't
they
don't
have
heaps
right.
I
mean
it's
like
they're
they're,
very
constrained,
so
they
can't
use
http
2.
They
can't
use
grpc
like
they're,
typically
using
very
basic
text.
Protocols
like
or
you
know,
maybe
basic
binary
ones
or
something
like
what
or
you
know,
different
messaging
protocols,
but
it
tends
to
be
really
simple
environments
so,
like
possibly
in
the
future.
I
think.
C
Yeah
and
it's
sort
of
interesting,
because
there's
this
you
know
mobile
devices
and
envoy
mobile-
is
very
specific
right,
but
there's
these
cases
of
where
there
is
a
capable
device,
and
so
in
industrial
context
they
usually
have
an
industrial
controller.
That's
running
linux,
it's
probably
running
java,
so
it's
got
heaps
of
ram
or
in
more
recent
non-industrial
use
cases
I'll
explain
this
so
a
major
retailer.
C
They
have
refrigerators
all
along
their
in
their
facility
and
they
have
iot
sensors
on
them,
so
measure
the
temperature
to
make
sure
it's
still
operating
correctly
and
they
have
a
mini
cluster
on-prem.
It's
like
a
single
rack
type
of
thing
and
that
also
connects
to
the
radio
technology.
So
they
can
sense
all
the
devices
and
collect
that
data
locally
and
then
push
it
off
back
to
their
their
main
hosted
solution.
So
that's
also
like
an
iot
gateway,
but
it's
actually
capable
of
running.
You
know
full-fledged.
C
You
know
kubernetes
envoy,
so
the
interesting.
Where
would
that
line
live?
Will
it
well
the
use
cases
that
make
sense
to
have
a
gateway
like
device?
Will
they
actually
just
be
running
a
more
traditional
envoy,
kubernetes
deployment
or
will
actually
be
even
more
constrained
because
of
deployability
cost
whatever,
but
but
surely
the
end-to-end
ip
there's
a
lot
of
value
in
in
having
it
at?
C
And
and
just
kind
of
like
to
bring
to
bring
it
home,
the
device
drives
the
requirements
to
the
cloud.
That's
that's
sort
of
one
of
the
things
I've
learned
in
my
career.
So
if
an
iot
device
has
a
very
constrained
requirements
of
what
you
can
communicate,
how
it
can
communicate
well,
you
can't
really
change
the
constraints
of
you
know
a
scooter
driving
around
the
city,
but
you
can
you
know,
for
example,
you
know
implement
protocols
on
the
cloud
side
to
match
to
the
to
the
device
side
requirements.
B
Yeah
interesting
yeah-
I
guess
I
had
it.
Hadn't
occurred
to
me
until
just
a
moment
ago
that
I've
been
speaking
with
a
well
with
a
very
large
manufacturer
of
well,
it's
used
with
the
parking
meters
and
a
bunch
of
other
style
iot
devices
or
the
various
styles
of
those
types
of
meters
for
airports,
parking
lots
and
the
like,
and
and
much
of
our
conversation
was
about
their
potential
use
of
a
service
mesh.
B
C
The
the
other
interesting
bit
about
specifically
iot
is
that
there's
not
necessarily
one
type
of
network
network
transport
right,
probably
in
the
sensor
use
case.
They
have
some
sort
of
local
sensor
communication,
some
wireless
protocol,
and
it
connects
eventually
to
some
point
to
some
aggregator
and
that
aggregator
might
translate
that
protocol
into
an
ip
based
protocol
or
it
might
be
an
iep
based
protocol
already.
D
One
one
other
one,
other
quick
thing:
you
mentioned
non-ip
networks
and
and
that
sort
of
got
me.
You
know
that
that
raised
my
my
ears
again
because
there's
a
thing:
we
don't
talk
about
network
service
mission
very
much,
because
most
people
only
care
about
ip,
but
we
are
actually
payload
agnostic
in
the
sense
that
if
you
have
any
kind
of
a
payload
that
can
be
broken
up
into
frames
of
any
sort-
and
you
have
something
that
you
are
willing
to
stick
it
on
to
for
transport.
D
D
But
there
are
a
small
number
of
pathological
use
cases
where
it
actually
is
the
thing
you
need
now
and
one
of
the
reasons
we
kept
that
agnostic
was
specifically
because,
even
though
we
don't
know
enough
about
iot
to
actually
know
what
to
do.
We
did
know
that
iot
had
a
bunch
of
what
we
call
exotic
network
protocols
where
there
and-
and
so,
if
you,
what
you're
doing,
is
just
streaming
a
serial
line
where
you
don't
have
framing
that,
I
probably
can't
help
you
with
right.
C
In
spades
yeah,
some
of
the
extremely
low
bandwidth
protocols
like
you
might
start
seeing
in
low
earth
satellite
communication.
Those
are
not
ip
based
because
they
don't
have
a
bandwidth
for
an
ip,
even
a
compressed
ip
header,
but
they
are
trying
to
map
the
protocol
to
create
a
framing
protocol
on
top
of
it.
So
once
it
actually
gets
to
a
collector
or
an
aggregator,
it
can
do
that
translation
pretty
fast
yeah.
By
framing
what
all
I.
D
Mean
by
framing
literally
is
it
doesn't
even
have
a
friction
header,
it's
just.
I
can't
stream
it.
I
can't
stream
it.
I
can't
do
this
for
an
infinitely
potentially
infinitely
long
thing
I
have
to.
I
could
only
do
this
for
something
that
is
going
to
have
a
defined
length.
Yeah,
that's
really
what
I
mean
by
framing.
It
doesn't
even
have.
C
A
header
for
all
I
care
right,
then
that's
more
aligned
with
some
of
these,
these
more
exotic
protocols
and
that
are
not
ipv-based.
They're
they're
dealing
with
the
again
may
or
may
not
solve
your
problem,
but
we
at
least
tried
to
leave
space
for
it,
yeah,
no,
that
that
that
opens
up
space
for
sure.
B
Wow
all
right,
good,
so
yeah
anyway
I'll
share
the
meeting
minute
some
here
briefly,
both
to
yeah
so
net
next
up
was
a
so
sorry
geez,
I'm
a
bit
all
over
the
place.
Thank
you,
jonathan
we'll
go
ahead
and
maybe
do
a
couple
of
things.
You'd
ask
like
hey
sort
of
anybody
have
any
feedback.
Any
questions
we've
had
some
good
discussion.
B
B
Interested
yeah-
and
I
guess
maybe
I
would
say
you
know
in
lieu
of
anyone
else
suggesting
something
else
is
maybe
jonathan
to
do
what
you
can
to
to
stick
around.
You
might
find
opportunity
to
advance
part
of
that
effort
in
context
of
this.
This
thing
right
now,
are
you
having
trouble
getting
people
to
respond
or
or
different
representatives
of
those
projects
to
to
review
the
doc
or
to.
C
Actually,
not
it's
been
surprisingly
amazing,
just
like
post
in
the
appropriate
slack
group
or
or
maybe
on
on
twitter,
if
they're
not
active
there,
and
they
just
pop
right
in
add
some
comments.
Some
some
project,
maintainers
of
competing
projects,
are
having
little
discussions,
which
is
also
fun
but
yeah.
It's
I've
been
getting
really
good
engagement
so
far,
nice.
Okay,
I
mean
that
one
of
the
questions
you
know
are
there
other
cigs?
It
sounds
like
you
know.
Immediately.
B
Okay,
the
other
topic
that
we
had
for
today
was
well
actually
before
we
get
to
that.
Just
with
nikolai
here
I'll
say
kudos
on
your
recent
switch
of
role
so
and
timely
in
terms
of
it
being
a
topic
that
we
will
be
discussing
further.
I
bring
this
up
to
say
congrats
on
the
role
change,
also
to
hint
toward
the
notion
that
we're
working
on
schedules
now
for
trying
to
assign
a
slot
for
review
of
kuma
presentation
of
kuma
and
review.
B
B
B
F
B
For
my
part,
I
don't
think
that
that
will
happen
based
on
a
number
of
things
and
in
part,
the
response
from
the
group
there
there's
another
specification.
That's
been
worked
on
by
a
few
different
groups
and
it's
part
of
what
I'm
hoping
this
service
smash
performance
working
group
can
focus
on
in
advance,
maybe
legitimize
and
it's
a
service
mesh
performance
specification.
B
B
There
are
a
couple
of
there's
there's
some
older
initiatives
that
have
yet
to
be
completed.
Things
like
really
a
vendor-neutral
study
of
performance
service,
mesh
performance
data,
plane
and
control
plane
under
a
variety
of
configurations
and
to
be
done
using
the
cncf
labs,
and
there
was
an
approval
to
use
the
use
that
lab
some
time
ago.
B
There's
been
some
recent
interest
in
completing
that
research
and
that's
in
part
why
the
university
of
texas
and
the
university
of
chicago
are
university
of
texas,
austin
rather
and
chicago
there's
some
post-docs
and
some
pre-docs
involved
in
some
research
here.
Some
of
their
research
is
fairly
hardware,
centric
and
others
of
their
research
is
just
it.
One
of
them
is,
has
just
gotten
done
doing
performance
benchmarking
on
search
engines
funded
under
a
google
initiative
anyway,
lots
of
folks
coming
together
from
different
projects.
B
B
I
actually
consider
that
it's
kind
of
an
interesting
thing
that
we're
we
live
in
a
distributed
world
today
or
there
are
more
and
more
workloads
being
designed
in
that
way,
and
yet,
at
least
of
things
that
I've
seen-
and
maybe
I'm
ignorant
here-
and
that
is
not
a
lot
around.
It
distributed
performance
testing,
and
so
that's
one.
That's
sort
of
the
the
point
of
that
particular
gsoc
project
is
to
help
enable
nighthawk
to
be
to
run
many
instances
of
nighthawk.
B
Lastly,
the
another
thing
to
potentially
just
be
discussed
within
that
working
group
is
the
notion
that,
as
the
that
service
match
performance
specification
comes
forth,
that
each
of
the
service
mesh
projects
that
I've
spoken
to
save
for
kuma,
actually
nikolai
when
I'd
spoken
with
boy.
I
forget
yeah
marco
a
couple
couple
of
times
now
he
didn't
necessarily
and
it's
okay,
it's
fine,
I'm
just
giving
context
since
you're
here.
B
B
B
So
not
it
not
really
about
white
papering
things
here,
but
rather
some
some
of
the
artifacts
to
be
produced.
You
know
it
may
include
publication
of
a
benchmark,
a
one-time
analysis,
potentially
publication
of
something
of
a
specification
for
uniformly
capturing
and
measuring
those
environments,
potentially
an
easy
gauge
and
easy.
You
know
zero
to
100
number
that
you
would
use
to
identify.
B
The
performance
of
you,
like,
I
said,
the
kind
of
performance
of
the
mesh
in
context
of
the
value
it's
provided,
yeah
and
again
so
so
yeah.
So
we
figured
the
reason
I
was
bringing
this
forth
right
now
is
because
both
gsoc
and
community
bridge
are
landing
in
terms
of
the
selection
of
some
of
their
projects,
and
some
of
those
projects
are
very
relevant.
E
B
In
this
case,
the
the
spec
is
it
can
that
the
spec
allows
for
that.
But
what
the
spec
also
captures
is
what
the
control
plane
is.
Maybe
what
functionality
is
enabled
in
the
control
plane?
So
I
think,
like,
as
you
were,
to
run
two
tests
and
contrast
them.
If
the
only
thing,
the
only
variable
that
has
changed
between
those
environment
configurations
is
your
data
plane.
In
that
sense,
it
could
be
a
comparison
between
proxies
but
the,
but
doesn't
necessarily
need
to
be.
B
B
I
think,
like
I've
seen
it
any
number
of
times,
people
will
take
a
gasp
at
just
how
much
overhead
they're,
seeing
from
a
mesh,
not
realizing
that
all
of
the
value
that
they're
getting
out
of
it,
that
if
they
were
getting
logging
or
tracing
or
observability
or
mtls,
or
you
know,
traffic,
routing
and
things
if
they
were
getting
all
those
things
from
a
variety
of
different
implementations
and
tools.
In
the
past.
They
couldn't
really
simply
measure
the
overhead
of
all
of
that.
The
value
that
that
infrastructure
was
providing.
D
For
you
know
normal
networking
kinds
of
stuff
where
people
look
at
it
and
say
yeah.
If
I
run
bvp,
it's
going
to
burn
two
core
and
what
they
don't
realize
is
that
the
kernel
is
burning
five
core
to
do
the
same
amount
of
work
with
less
throughput,
because
the
kernels
of
your
use
of
resources
is
invisible.
D
Oh,
but
the
vvps
resources
are
highly
visible
to
them
and
so
being
able
to
figure
out
a
way
to
capture
some
of
that
for
comparison,
because
it
may
also
turn
out
to
be
the
case
that
in
many
cases
they're
like.
Oh,
the
service
message
is
costing
me
x,
but
it's
costing
them
half
x.
You
know,
basically
it's
costing
them
2x
to
do
it
the
way
they're
doing
it
now,
and
so
it's
actually
a
net
gain
independent
of
the
independent
additional
value.