►
From YouTube: IETF113-PANRG-20220324-1200
Description
PANRG meeting session at IETF113
2022/03/24 1200
https://datatracker.ietf.org/meeting/113/proceedings/
D
D
D
C
Good
afternoon
announcement,
which
is
not
on
the
slides
when
you
scan
the
qr
code,
use
one
which
is
on
the
screen
and
not
try
to
use
the
paper
one
because
it
didn't
work
for
me,
I'm
not
sure
if
it
still
works,
maybe
it
works.
Actually,
this
is
for
energy,
so
I
hope
everyone
is
in
the
right
room.
C
This
is
not
well,
please
read
it
if
you
have
not
seen
it
before.
It's
irtf
specific
note
well,
which
lists
everything
you
need
to
know,
and
it
also
reminds
you
to
be
polite
and
be
nice
to
other
people
as
much
as
you
can
and
even
better
housekeeping.
So
yes,
I
say:
please
car
scan
qr
code,
which
would
allow
you
to
join
the
microphone
key.
C
When
you
speak
into
the
microphone,
please
say
your
name,
so
we
know
who
you
are
for
people
who
are
not
able
to
join
us
in
person
who
are
remote.
Please
keep
your
audio
and
video
off.
Unless
you
are
speaking
and
then
you
can
join
the
queue.
If
you'd
like
to
ask
question,
and
then
you
can
say
you
probably
should
send
audio,
but
you
may
say
send
video
as
well
so
for
speakers.
C
C
F
You
can,
I
ask
you
to
take
minutes.
G
E
And
also
carsten
will
be
helping
you
out.
C
Beautiful,
thank
you.
Thank
you
very
much
so
agenda.
For
today
we
have
pretty
busy
agenda
time
permitting
section
where
we
have
spencer
has
been
dropped.
Spencer,
just
told
me,
so
listen,
but
I
still
hope
to
hear
from
you
next
time
so,
what's
going
on
in
this
group,
since
last
eight
year
we
published
another
secret
nutrition
brand.
Thank
you
we
have,
and
so
now
we
have
questions.
C
C
E
I
I
see
some
faces
in
here
who
were
in
the
scion
side
meeting
on.
I
guess
that
was
tuesday.
E
E
I
think
it
makes
sense
to
have
a
virtual
interim
between
now
and
philadelphia
to
dig
into
that
question
right,
like
so,
we'd
ask
people
from
scion
and
people
with
interest
in
this
topic
to
get
together
at
that
at
that
virtual
interim
meeting
and
it'll
be
a
bit
more
of
like
a
brainstorming
thing
than
a
and
a
you
know.
Let's
look
at
presentation
sort
of
thing.
E
We
will
follow
up
on
the
list
to
figure
out
the
right
time
to
do
this
and
like
any
suggestions
that
people
might
have
with
respect
to
the
format
of
that.
But
I
think
there
is
an
opportunity
here
to
figure
out
which
bits
of
that
work
belong
in
this
research
group
and
maybe
provide
that
project
with
guidance
for
how
to
engage
with
with
parts
of
that
within
boston
and
the
ietf
as
well.
E
H
C
B
I
Perfect,
I'm
not
sure
yet
I
see
this
light.
F
C
F
You,
okay.
C
C
I
think
I've
done
that.
That's
that's
my
problem.
Okay,
it's
like
what
I'm
doing
wrong.
Try
this
shampoo
slice.
C
No,
I
can,
I
can
be
locked
twice.
I
tried
it's
not
possible.
Okay,
okay,
let's
do
this.
Okay,
oh
yeah,.
K
F
C
K
E
Yes
got
it:
okay,.
I
Yeah,
perfect
yeah,
so
today
I'll
give
you
a
quick
update
on
the
path
property
draft.
I'm
sorry,
my
voice
is
a
bit
it's,
but
I
think
I
should
manage
that
10
15
minutes
yeah.
I
I
will
try
to
keep
the
presentation
short,
so
we
have
some
time
for
feedback,
so
the
biggest
change
we
did
since
the
last
version
is
that
we
replaced
host
with
endpoint,
so
we
removed
the
standalone
definition
of
host
we
had
before
and
we
now
have
a
new
definition
of
an
endpoint
which
is
defined
as
the
first
or
last
node
on
a
path.
I
I
think
one
thing
that's
interesting
to
note
here
is
that
actually
in
the
beginning,
we
had
already
the
term
end
point
in
our
draft.
This
was
when
this
was
not
an
iot
of
irt
graph
by
the
draft
of
freeze,
but
we
decided
to
go
to
use
term
host
because
it
was
not
clearly
defined.
I
But
since
the
the
draft
has
seen
a
lot
of
change
in
the
last
iterations,
we
think
that
now
and
we
can
finally
have
this
definition
of
endpoint,
and
it's
also
clear
and
correct
and
of
course,
naturally
from
this
definition
of
an
end
point.
We
have
the
definition
of
an
end-to-end
path,
property
which
is
simply
a
path
property
defined
on
both
end
points
and
the
virtual
link
between
them,
which
is
very
useful.
I
I
And
then,
from
the
discussions
we
had
previously,
we
felt
it
was
not
clear
enough
why
the
definitions
are
context
dependent.
So
we
added
some
short
text
to
section
2.1
and
what
we
want
to
express
there
is
that
even
a
single
part
where
technology
might
have
different
definitions
right,
they
might
disuse
these
terms
differently,
depending
on
the
context.
I
So
one
example,
I
thought
of,
is
maybe
a
scion
where
we
have
these
path
segments,
so
the
routing
only
works
on
these
path
segments,
but
then
for
actual
data
traffic
data
plane
then
works
on
combined
data
of
segments
that
are
combined
into
paths.
So
there
the
notion
of
a
path
will
be
different
for
one
technology
depending
if
you
look
at
the
routing
side
or
the
data
plane
side.
I
And
then
we
added
a
new
definition,
which
is
a
routing
domain
identifier.
This
was
due
to
a
discussion
in
the
mailing
list
where
this
came
up
and
we
defined
the
routing
domain
as
follows.
So
path,
elements
with
the
same
routing
identifier
are
in
the
same.
Administrative
domain
use
a
common
routing
protocol
and
they
communicate
with
each
other.
Using
this
specific
protocol
and
the
other
classical
example
would
be
the
as
number
and
another
example
could
maybe
be
an
ospf
area.
Identifier.
I
And
then
we
have
a
lot
of
minor
changes,
so
we
added
the
discussion
menu
section
which
contains
a
link
to
the
mailing
list
and
a
link
to
the
github
repository
where
we
have
the
draft
and
where
we
have
issues
where
we
discuss
all
the
changes
and
one
thing
that
we
realized
when
we
updated
the
routing
domain.
Identifier
was
that
the
administrative
domain
property
was
kind
of
recursively
defined,
which
is
a
bit
weird.
So
we
rephrased
this
to
make
it
more
natural.
I
So
that's
already
the
end
of
my
presentation.
I
think
what
I
would
like
to
hear
most
from
you
is
your
thoughts
on
this
new
endpoint
definition
right.
We
already
had
endpoint
before
we
removed
it
in
favor
of
host,
and
now
we
reintroduced
it.
So
there
I
kind
of
have
two
questions:
do
you
think
it's
sufficient?
I
So
does
our
definition
now
cover
all
possible
endpoints
that
you
could
think
of,
or
is
there
something
that
is
not
covered
and
on
the
other
hand,
is
it
necessary?
So
do
we
is
our
definition
too
broad?
Do
we
include
entities
that
would
not
count
as
an
endpoint,
but
they
are
still
defined
as
an
endpoint
in
our
draft.
I
So
what
do
you
think?
How
precise
is
our
definition
and
another
thing
that
we
would
like
to
do
is
to
fairly
soon
finalize
the
main
definitions,
and
one
thing
that
me
and
rhys
thought
when
we
discussed
this,
is
that
once
this
main
definitions
are
clear
are
finalized?
I
Probably
there
will
be
very
little
thing
left
to
do,
because
the
rest
of
the
draft
is
essentially
a
non-exhaustive
list
of
properties,
so
we
could
keep
it
open
for
a
very
long
time,
or
we
could
just
say
this
is
the
state
now
what
we
think
is
useful
and
the
main
definition
will
not
change,
so
we
could
would
ask
for
a
last
call
yeah,
that's
all
it
from
my
side,
I'm
open
for
questions
and
comments
on
on
these
changes.
E
E
E
I
think
that
the
fact
that
we're
having
this
discussion
is
is
the
indication
that
it's
necessary
right
like
if
we
don't
have
a
definition
for
endpoint
people
are
going
to
ask
where
it
is
right.
So,
yes,
I,
like,
I
think,
both
of
the
both
the
conditions
hold.
So
thank
you
very
much,
for
you
know
your
patience,
yours
and
rhys's
patience
with
going
back
and
forth
on
this.
This
is,
you
know,
hard
stuff
to
pin
down.
E
E
C
All
right,
okay,
if
you
know
how
it
is,
I
think
so.
E
So
starting
a
session
ray's
hand
means
yes,
I
believe
path
properties
is
ready
for
last
call
do
not
raise
hand
is
no.
I
think
we
need
to
talk
about
something
before
we
are
ready
to
last
call
this
document.
E
E
G
I
B
L
Yes,
get
you
here,
so
the
rotting
domain
id
just
defined
here.
Well,
you
know
I
you
know.
In
my
my
opinion,
it
might
be
a
little
bit
ambiguous
for
for
something
like,
for
example,
in
the
the
running
product
or
isis.
It
doesn't
use
the
domain
for
some
purpose.
So
I'm
not
sure
if
you
find
this
as
a
generic
generic
term.
I
Yeah,
I
would
like
that
the
things
we
define,
especially,
for
example,
this
routing
domain
identifier,
is
just
kind
of
a
generic
identifier
right.
Definitely,
this
needs
to
be
defined
in
like
in
specific,
when
you
talk
about
one
specific
routing
protocol
like
bgp,
scion
or
whatever.
I
So
this
is
more
like
to
give
an
idea
what
could
be
useful
right
and
we
think
a
way
to
group
nodes
based
on
their
kind
of
ownership
in
a
way
their
administrative
domain
and
that
they
can
communicate
with
other
is
is
useful
and
that's
why
we
added
this.
At
this
part,
property.
L
E
D
E
I'd
actually
go
back
and
ask
corey's
question
now:
real
quick
just
to
get
one
more
bit
of
data,
so
I'm
gonna
ask
for
another
show
of
hands.
As
for
who
has
read
the
path
properties,
draft.
E
Roughly,
as
many
people
have
read
it
as
think,
it's
ready
for
last
call,
so
that's
that's
cool
max
has
joined
the
queue.
B
E
Okay,
good
so
so
of.
C
E
Of
you
please
consider
reading
the
draft,
it's
quite
short-
and
you
know,
speaking
as
an
individual,
very
entertaining
yeah.
E
And
then
I
need
to
go
to
presentation
view.
Okay,
and
I
will
drive
so
just
say
next
slide
find
a
microphone
right
here.
C
E
N
J
N
Right
this
title,
adjusted
to
the
context
of
this
group,
is
about
how
to
use
proxies
and
a
new
way
of
suggesting
how
you
could
maybe
do
it.
Please
next
slide.
N
Okay,
so
the
problem
that
this
is
about
is
that
performance
enhancing
proxies
have
existed
for
a
long
time.
People
hate
them,
they
try
to
help
out
in
tcp
and
in
fact
you
know
because
well
they
sometimes
do
something
useful
right.
They
have
good
intentions
well
intended,
but,
but
you
know
terrible
outcomes
of
ossification
of
playing
tricks
to
tcp
that
they
have
to
do,
and
this
is
why
we
all
hate
them.
N
So
quick
has
started
encrypting
the
header
large
part
of
it,
which
makes
it
impossible
to
introduce
ossification
and
also
makes
it
impossible
to
help
the
transfer
in
the
network,
which
has
the
outcome
that
people
are
now
making
presentations
about.
How
quick
does
not
work
as
well
as
tcp
over
satellite
link?
N
N
So
whenever
you
have
anything,
you
know
in
the
network
that
that
requires
special
attention,
but
you're
actually
happy
to
have
a
proxy
that
is
a
no-go,
and
so
this
is
my
effort
to
retrofit,
and
this
is
probably
where
you
want
to
throw
stuff
at
me.
N
Retrofit
proxies
into
quick
now.
Okay,
first
of
all,
I
claim
that
the
ossification
problem
is
probably
at
least
partially
due
to
the
fact
that
these
proxies
are
transparent
right
by
their
nature.
They
have
to
lie
to
tcp,
they
cheat,
they
do
things
that
are
not
supposed
to
be
happening,
and
that's
why
they
make
assumptions
about
the
header
that
are
not
supposed
supposed
to
be
made
and
that's
how
we
cannot
upgrade
the
protocol
properly
using
a
proxy
that
is
authenticated,
known
signal
tool.
Things
could
be
done
differently
in
principle.
N
Mask
is
a
candidate
for
that
thinking
about
whether
it
would
be
a
good
idea
of
adding
pep
functions
there.
I
guess
some
people
might
think.
Yes,
some
people
might
think
no.
N
There
is
an
obvious
issue
here
that
if
we
start
adding
a
specific
function,
then
we
build
a
reliance
on
that
function
in
the
network
and
not
everybody
may
be
happy
with
the
outcomes
of
that
we
may
reintroduce
ossification.
If
we
don't
do
it
right,
if
we
get
it
right,
maybe
that
could
work.
Here's
another
proposal
next
slide.
N
What
we
suggest
is
to
do
this
differently
using
separation
of
concerns.
The
idea
is
to
use
a
separate
protocol
that
we
call
sidecar
strictly
meant
only
for
pep
functions.
You
would
never
rely
on
it
for
anything.
You
wouldn't
rely
on
this
being
you
know
giving
you
reliability
in
in
the
data
transfer,
for
example,
but
it's
like
an
opt-in
performance
improvement.
N
Okay,
yes
and
the
non-criticality
of
that
thing
is-
is
ensured
by
letting
the
main
protocol
explicitly
opt
in
choose
the
service
via
an
interface
and
that
interface
at
least
the
way
we
think
about
it
is
that
this
interface
would
be
on
a
local
host
only
so
on
the
host.
You
would,
for
instance,
talk
to
a
library
that
supports
that
over
an
api
and
that
library
offers
a
service
and
you
take
it
or
you
don't
for
a
specific
connection
right,
and
you
may
expect
that
this
comes
with
a
certain.
N
A
plan
is
to
minimize
changes
to
the
main
protocols
of
the
main
protocol.
You
couldn't
really
help
quick
much
without
changing
it
at
all,
but
the
idea
is
to
make
it
as
minimal
as
we
possibly
can,
and
if
we
get
this
right
then
ossifying.
The
sidecar
would
mean
that
the
performance
improvement
doesn't
improve
per
se,
but
which
is
bad,
but
nothing
really
severe
happens.
You
will
never
rely
on
that
for
anything
critical.
N
And
the
functionality
of
the
pep,
they
are
the
use
case
of
these
cycle
protocols.
It's
about
providing
a
framework
that
that
helps
with
these
kinds
of
things.
Next
slide:
okay,
so
in
terms
of
functionality,
what
this
protocol
can
do
right
on
the
data
plane?
What
we
can
do
is
we
can
try
to
directly
affect
the
main
protocol
in
some
way.
N
There's
not
so
much
really.
We
can
try
and
manipulate
the
queue.
Just
like
a
router.
Does
you
know
doing
q
management
draining
the
queue
at
a
certain
speed,
something
like
that
we
can
maybe
retransmit
packets,
but
we
would
not
pass
the
header
because
well
it's
mainly
about
quick.
The
idea
is
to
do
this
in
a
way
that
could
work
for
tcp
for
http
for
anything,
but
we
don't
want
to
rely
on
that
on
the
control
plane.
N
So
you
have
a
proxy
that
needs
to
act,
something
now
maybe
a
receiver
that
needs
to
add
something
to
the
proxy,
and
the
idea
is
that
these
acts
will
be
done
using
hashes
over
the
transport
header.
Now
we
don't
even
know
how
big
that
header
is,
but
it
could
be
a
simple
rule
like
saying,
let's
say,
take
20
20
bytes,
starting
from
the
ip
header
from
after
the
ip
header
or
30
bytes.
If
that's
not
good
enough
right,
it's
about
avoiding
that
hashes
collide
and
hoping
that
hashes
are
different
between
different
packets.
N
The
x
could
be
separate
x
and
they
could
be
piggyback,
for
instance,
using
udp
options.
That
seems
like
a
nice
vehicle
to
me,
because
quick,
wouldn't
even
notice,
right
gets
stripped
away
if
nobody
doesn't
want
them
and
well.
I'm
coming
to
two
example:
use
cases
that
illustrate
how
that
thing
could
operate
and
then
then
we'll
see
what
you
think
about
it.
N
N
Okay,
so
the
first
example
is
you're
trying
to
communicate
over.
That
is,
let's
call
it
a
millimeter
wave
link
right.
You
have
a
link
with
fluctuating
capacity
between
what
here
I
call
the
sidecar
proxy
and
the
client.
You
have
a
normal,
quick
data
transfer,
it's
not
interrupted,
I'm
just
showing
a
queue.
So
it's
like
a
router
queue,
it's
a
queue.
It
goes
in
and
you
have
x
going
back,
and
so
we
need
to
add
something
you
know
to
make
it
work
better.
N
You
use
the
hash
to
act
back
to
the
sender,
side,
side,
car
instance,
and
using
these
acts
it
will
be
able
to
get
a
bit
more
data
towards
the
sidecar
proxy,
such
that
you,
if
you
implement
a
different
kind
of
congestion
control,
you
have
data
available,
which
is
what
you
normally
get.
If
you
implement
the
tcp
connection,
splitter
right,
you
would
act
earlier
and
then,
when
capacity
becomes
available,
you
have
the
data
there
and
in
terms
of
the
sending
rate
that
would
just
influence
the
draining
rate
of
the
router.
N
That
is
something
any
device
can
do.
We
can't
prevent
routers
or
any
devices
from
doing
this,
since
this
is
a
congestion
control,
it
would
require
a
control
loop.
So
the
sidecar
in
this
case
would
also
have
to
be
on
the
client
side
to
produce
x
just
to
the
side
car.
So
that's
independent
of
quick,
it's
just
looking
at
the
hashes
and
producing
x
and
the
notification
to
the
quick
entity
would
be
that
a
neck
has
arrived,
increase
your
congestion
window
right.
So
that's,
that's!
That's
the
deal
you
like
it
or
you.
N
This
is
something
different,
just
to
illustrate
that
the
idea
is
to
be
really
flexible
and
do
basically
whatever
perhaps
normally
do
there
is
this
paper
that
some
colleagues
from
trento
university
have
done
a
long
time
ago.
This
was
work
on
tcp.
It's
tricks
playing
playing
tricks
to
tcp.
The
idea
is
that
on
a
wi-fi
network,
any
act
that
a
client
produces
is
really
2x
right.
You
have
a
link
layer,
ack
and
you
have
a
transport
layout
and
then
that
transport
layer
probably
produces
another
link
layer
x.
So
it's
so
much
traffic
just
for
one
ack.
N
Now,
rather
than
having
all
these
acts,
you
could
decide
that
the
client
doesn't
need
to
hack
anything
and
on
the
wi-fi
access
point,
you
can
just
take
a
look
at
the
packets
as
they
arrive.
Remember.
I
forwarded
this
particular
packet
to
the
client
and
wait
for
the
link,
react
that
comes
back
and
when
that
link
layer
comes
back
link
layer
arrives,
I
can
associate
it
with
the
tcp
header
that
I've
just
been
forwarding.
I
can
produce
the
icon
behalf
the
client.
N
Now
really
you
wouldn't
want
to
do
this
for
all
x
right.
You
still
want
to
have
two
packs.
You
still
want
to
have
options,
but
you
could
significantly
reduce
the
number
of
eggs
that
are
necessary,
which
would
save
energy
for
the
device
it
would
avoid
collisions,
and
the
idea
here
is
to
show
how
could
we
play
that
trick
with
with
quick,
for
example,
next,
please
so
here
the
service
will
be.
I
will
treat
your
side
car
wrecks
like
clyde
x.
N
Basically,
I
accept
them,
except
that
I
said
that
we
don't
want
to
do
anything
really
critical
on
this
basis.
So
the
sender
would
keep
the
the
data
in
the
center
for
just
in
case
until
until
the
client
cumulatively
asks
them,
but
other
than
that
you
know
proceed
like
normal.
When
you
get
these
eggs
next,
please,
the
sidecar
notification
will
be
an
ack
has
arrived.
N
It's
a
very
simple
thing
right:
it
does
a
hash
of
the
packet
and
the
x
and
says
okay,
this
packet,
I'm
now
acting
and
as
you
can
see
you
don't
in
this
case,
you
don't
need
to
do
anything
on
the
client
side
in
for
the
sidecar,
but
of
course
the
client
would
have
to
act
less.
So
next,
please,
the
next
one
is
to
saying
that.
N
Well,
the
minimal
changes
to
quick
in
this
case
would
have
to
be
that
you
have
to
signal
to
the
client
that
it
shouldn't
be
acting
as
much
over
quick,
probably
and
if
you
choose
to
service
well
that
and
also
accept
these
sidecar
acts
again
right.
It
may
depend.
I
may
not
at
all
want
that
to
happen
when
I'm
talking
to
my
bank,
but
there
may
be
so
many
things
that
are
run
over
quick,
where
I
really
don't
care
about
anonymity
or
things
like
that
where
maybe
this
is
okay,
it's
just
an
example.
N
Well,
two
very
different
things
that
could
be
done,
but
the
idea
is,
you
could
do
any
pep
function.
Next,
it's
already
the
last
one.
So
what
we
believe
is
that
this
is
a
possible
way
forward
to
solve
that
dilemma,
that
we
now
have
between
end-to-end
encryption,
ossification
and
not
being
able
to
do
any
pep
functions.
N
N
There
are
ways
we
believe
there
are
many
details
here.
You
know
if
you
consider
the
use
cases,
for
example
right.
Let's
take
the
link,
specific
congestion
control
thing
in
case
of
tcp,
because
the
pep
is
invisible
and
transparent.
It
can
just
answer
back
to
the
sender.
There's
no
need
to
even
authenticate.
N
There's
no
need
to
even
find
it
right,
because
it's
on
the
path
and
it
answers
to
the
correct
ip
address
in
this
case
it
would
have
to
be
found
now
and-
and
there
will
be
a
notion
of
trust
right.
So
the
cycle
proxy
in
principle
just
to
give
you
a
hint
of
what
kind
of
you
know,
steps
would
need
to
be
taken.
The
cycle
proxy
in
principle,
you
can
just
send
sidekaix
towards
the
sender.
You
could
start
with
one
see
if
the
device
is
there
answering
that.
N
N
If
a
path
changes
well,
there
can
be
different
side
card
proxies.
They
would
just
all
start
to
act
towards
me.
Then
again,
you
know
if
that,
if
that
is
how
we
operated,
then
we
would
have
a
string
of
we
could
have
a
string
of
multiple
of
these
proxies
answering
without
knowing
about
each
other
right.
So
there
would
have
to
be
some
kind
of
negotiation
phase
to
agree
that
this
is
the
side
car
proxy
I'm
talking
to
so
you
know
there
are
open
things.
N
C
O
Yeah
it'll
be
very
quick,
so
yeah
I
like
the
idea
I
like
the
because
I'd
like
to
ensure
yeah
peps
are
a
way
of
ensuring
that
we
get
the
maximum
utilization
of
the
available
bandwidth.
So
I
like
the
the
concept
of
trying
to
do
both
yeah,
have
the
pep
and
avoid
ossification.
So
it's
good
work.
Yeah
I'd
like
to
see
more
so
thumbs
up.
Okay,.
P
E
E
N
P
Okay,
maybe
I'd
love
to
see
some
ideas
on
on
that
concept
on
the
list
a
little
bit,
maybe
I'll
I'll,
think
about
it,
but
but
you
think
they
would
just
act.
Anybody
who's
sending
regardless.
N
Start
with
a
knack
and
say:
okay,
you
know
I'm
getting
one,
so
it
means
that
there
is
somebody
and
I'm
answering
back.
Maybe
I
could
pick
one
of
them.
You
know
like
there
were
these
things
in
multicast,
where
you
were
able
to
pick
out
of
many
many
possible
receivers
acting
back.
You
said
this
is
the
one
that's
hacking
from
here.
E
Qualities
possible,
there's
like
interest
to
continue.
This
discussion,
like
this
is
seems
like
a
a
potentially
solvable
problem
and
a
good
way
to
get
there
like
discovery
is
hard
anyway.
But,
yes,
I'm
sorry
to
cut
you
off.
E
Maybe
next
meeting
we
could
spend
a
little
bit
more
time
on
this
yeah,
so
marcus,
real,
quick.
Q
All
right
yeah,
I
just
want
to
say
real
quick.
I
think
this
is
great
work,
we're
actually
in
ericsson
working
on
or
we
have
been
working
on
something
very
similar.
We
call
it
lightweight
pep
and
the
multi-domain
congestion
control.
It
has
a
lot
of
these
ideas
in
there,
so
it
would
be
really
nice
to
get
in
touch
and
sort
of
yeah.
Maybe
discuss
this
more
offline.
We
have.
Q
N
M
R
R
And
yeah
exactly
so
I'll,
go
quick
over
the
agenda.
First
I'll
talk
about
the
scenario
that
I'm
presenting
and
exactly
what
is
network
auto
scaling.
Then
I'll
go
over
how
about
how
we
put
the
pieces
together
for
prototyping
and
finally,
some
plots
about
the
results
that
we
got
from
it
next
slide,
please,
okay!
So
if
we
focus
first,
this
is
the
scenario
which
is
built
of
three
different
parts:
the
first
one.
Let's
say
it's
a
branch
where
all
the
users
are
connected.
R
The
second
one
would
be
the
cloud
where
there's
the
application
that
these
users
consume
and
it's
cloud
orchestrator
and
the
third
one
would
be
the
software
defined
network,
which
is
the
part
that
brings
together
the
users
and
the
application
and
provides
some
connectivity.
R
So
if
we
now
look
at
the
situation,
when
an
application
deployed
at
the
cloud
suddenly
receives
an
increase
of
requests,
what
the
cloud
does
is
auto
scale
and
provide
more
resources
to
that
application,
and
it
does
so
in
two
different
ways:
the
first
one
being
horizontal,
auto
scaling,
which
is
deploying
more
replicas
of
that
specific
application.
So
the
load
can
be
balanced
and
managed
more
efficiently
and
the
second
one
is
vertical:
auto
scaling,
which
is
incrementing
the
resources
on
replicas
that
are
already
deployed,
such
as
increasing
the
cpu
or
more
ram.
R
So
if
we
now
take
a
step
back
and
look
at
the
big
picture
again,
there's
okay,
this
situation,
there's
an
increase
of
load.
The
cloud
has
done
something
about
it,
but
there's
the
problem
that
the
network
has
not
been
modified
and
it
might
become
the
bottleneck.
So
that's
when
translating
this
auto-scaling
term
to
the
network
makes
sense,
so
we
define
a
horizontal
network
out
to
scaling
which
is
changing
the
overlay
path
and
vertical
network
of
the
scaling,
which
is
changing
the
characteristics
of
the
underlay
path.
R
So,
let's
like
please,
oh
that's
the
last
one.
That's
the
next
one
yeah!
Thank
you!
So
if
we
go
over
first,
the
horizontal
network
out
to
scaling
case,
as
I
said,
imagine
that
you
have
this
traffic,
that's
usually
routed
through
the
standard
path
and
then
suddenly,
there's
the
increase
of
load
and
then
there's
a
way
that
the
application
is
able
to
tell
the
network
hey,
I'm
out
of
scaling.
I
will
need
more
resources
because
they
are
coming
or
this
channel
that
you
have
is
not
going
to
be
able
to
meet
my
demands.
R
So
then,
here's
where
the
sdn
controller
can
have
a
policy
that
defines
okay.
Now
that
we
think
that
that's
the
case,
you
need
to
be
routed
through
this
other
path
and
in
terms
of
vertical
network,
auto
scaling.
R
It's
a
similar
case
in
the
same
scenario,
there's
a
cloud
out
the
scaling
event,
and
then
the
network
reacts
to
it
by
adapting-
and
in
this
case,
if
there's
only
one
connection
vertical
to
scale
vertical
network,
auto
scaling
would
mean
adding
more
bandwidth.
If
it's
needed
to
end,
then
it's
an
elastic
thing.
It
can
go
back
when
there's
no
more
demand
of
that
bandwidth.
So,
yes,
I
think
a
couple
of
yeah
yeah,
it's
light.
R
You're
gonna
go
with
the
next
one,
so
here's
the
prototyping,
you
can
see
that
both
the
users
and
the
application
have
been
deployed
in
public
cloud
and
what's
interesting
about
here
is
if
you
look
at
the
purple
boxes,
it's
the
way
how
the
application
communicates
its
requirements
to
the
network.
R
So
there's
the
cn1
operator,
which,
let's
call
it
a
plug-in
on
the
kubernetes
orchestrator
that
monitors
the
application
and
what's
happening
on
there
if
there
are
more
replicas
or
if
these
replicas
are
increasing,
so
monitoring
the
cloud
auto
scaling
events
are
happening
and
it
polishes
these
changes
to
the
service
and
external
service
registry,
which
is
then
continuously
pulled
by
the
cn1
reader,
which
takes
into
account
and
says.
Oh
there's,
been
a
change
and
notifies
the
adapter,
which
is
the
piece
that's
in
charge
of
talking
to
the
sd1
controller
and
the
underlay
saying
okay
network.
R
Yeah
yeah,
that's
just
a
quick
plot
about
the
network,
horizontal
network,
auto
scanning
performance,
where
we
switch
the
traffic
over
both
paths
in
a
rate
limited
one
and
on
one
degree
per
second
tunnel,
and,
as
you
can
see
here
at
this
obvious
when
there's
traffic
in
one
path,
there's
nothing
the
other
one
and
we
found
that
the
delay
obtained
was
not
impactful.
So
the
change
of
routing
was
successful
and
just
one
place
and
on
the
case
of
vertical
network,
auto
scaling.
R
If
you
see
the
orange
line,
it's
where
the
cloud
of
the
orchestrator
says:
okay,
there's
a
number
of
labradors
that
is
increasing,
and
if
you
look
at
the
green
line
it
says
it's
the
network,
auto
scaling
at
the
same
time
when
proactively,
meaning
that
okay,
the
cloud
is,
has
had
an
auto
scaling
event.
E
Thank
you
very
much.
We
have
time
for
probably
one
quick
question.
B
M
S
Hello,
my
name
is
rafael,
so
I
here
to
present
the
our
solution-
polka,
that
is
a
polynomial
key
based
architecture
for
sas
routing.
So
next,
please
so
we
are
trying
to
connect
watch
banks
problem
solve
penalties
for
problem
solved
in
pog.
So
we
have
noted
that
any
points
have
little
information
about
the
perhaps
over
which
their
traffic
is
carried
so
and
no
contract
beyond
the
destination
address.
So
next,
please
so
taking
care
about
what
sdn
table
based
solution.
So
we
have
some
next.
S
Yes,
the
s10
table-based
solution
approach
suffered
with
the
pav
setup,
may
involve
several
state
configuration
so
once
we
have,
for
example,
sdn
table
based.
We
are
suffering
with
this
kind
of
out
every
time
we
need
to
keep
states
along
the
path
so
introduce
for
us
a
specific
question:
how
the
sdn
database
solution
offer
pathway
control-
and
you
have
some
problems
about
that,
for
example,
largely
number
of
scale
that
which
means
dealers
for
scalability
limit
capacity
of
tables
directly
and
latest
for
path
configuration.
S
S
So
why
you
should
use
polka
as
a
strict
sauce.
Routing
polka
rotting
simultaneously
meets
some
followed
requirements,
for
example
topology
agnostic,
so
we
don't
need
table
in
the
core
and
we
have
fixed
headers
and
also
we're
implementing
program
switches
for
a
single
path
and
multiplies.
So
it
enables
a
lot
of
a
lot
of
applications
in
that
case,
for
example,
have
expressiveness
reliability
and
efficiency
in
telemetry.
So
next,
please
so
how
power
work.
So
we
have
three
polynomials.
We
have
a
rod
id
which
identify
and
calculate
via
using
crts.
That's
a
chinese
remain
theorem.
S
S
S
S
This
is
kind
of
extern
that
we
offer
us
to
calculate
the
mod
operation
in
a
polynomial
way,
so
the
rainforest
the
red
project
as
a
open
source
full
features
relative
on
which
we
have
network
hardware
for
research
and
education,
so
the
data
plane
that's
supported
now
is
vm2
and
tofino,
and
and
they
did
in
the
pdk,
okay,
so
the
control
plane,
three
routers
use
also
standard,
distribute
protocols
and
state
and
maps
segment
router
index
into
the
node
ids.
So
you
can
get
available
topologies
into
from
a
leak
state
protocols.
S
K
So,
can
you
we're
at
like
seven
minutes
of
five?
Can
you
yeah.
S
The
last
one
so
and
go
ahead,
so
so
you
have
the
the
route
id
and
basically
on
each
switch.
You
calculate
the
mod
operation
by
the
remainder
of
the
division
between
node
id
and
port
id.
Do
the
id
and
the
route
id
and
you
get
the
output
part
as
in
the
final.
So
next
please
go
ahead.
So
in
the
end
you
just,
then,
you
pack
delivered
application
in
a
transferred
manner
for
the
destination.
Removing
the
the
road
id
in
the
package.
E
Next,
yes,
thank
you.
Thank
you
very
much.
Thanks
for
speeding
up
have
a
look
at
the
slides.
We
went
a
little
bit
quickly
through
the
the
last
bits
of
how
that
goes
on
in
each
stage
and.
S
E
Cool,
if
you
have
questions,
please
find
raphael.
Sorry,
we
need
to
go
to
the
next,
which
is
luis,
correct.
No,
oh.
T
S
We
we
are
able
to
encode
a
multiple
path
and
the
same
encoding
rotating
so
once
this
vector
achieves,
for
example,
you
have
some
fail
in
one
path
when
you
go
to
the
another
path,
you
are
railing
code
that
that
switch
needs
to
go
to
that
part,
so
it
so.
You
can
have
multiple
paths
in
the
same
encoder
that
route
id,
which
means
if
this
is
not
independently
one
switch
that
another
switch,
the
result
of
them
because
they
are
calculated
dependently.
So
that's
why
we
can
encode
everything
together
in
the
same
rotate
rotating
in
this
case.
E
A
lot,
I
think
you
are
a
remote,
can
you
go
ahead
and.
U
U
Our
top
packet
is
that
we
think
that
the
bng
working
as
a
giveaway
of
the
enterprise
is
able
to
maintain
a
connection
per
connection,
state
and
trust
relationship
for
each
user,
so,
based
on
this
b3
or
this
png,
we
want
to
make
the
endpoint
trust
the
information
from
the
ingress
p
specific
intermediate
node.
U
Using
this
ingress
pe
can
make
some
decision
for
the
past
to
the
equals
p,
so
it
will
influence
the
path
of
the
current
and
the
inverse
p
contrast
the
station
from
user
for
a
user,
for
example
the
underpoints
in
the
client.
If,
if
the
client
sends
some
suggestion
for
some
information
to
the
ingress
pe,
the
technology
can
trust
them
on
the
next
page.
U
A
initial
magazine
result
is
that,
from
this
english
pe
to
the
kind
current,
for
example,
the
university
need
to
send
some
message
to
the
hand.
It
can,
for
example,
make
her
as
the
nature
for
the
message
by
using
a
private
key,
so
that,
if
you
look
kind
of
receive
it,
it
can
check
it
your
the
public
key
or
the
ingress
pe.
U
If,
if
the
information
is
from
the
client
to
the
ingress
pe,
we
think
that
the
png
can
make
a
signature
instead
of
the
clan
by
using
a
private
cave
belonging
to
this
png
or
the.
If
the
png
between
the
bing
and
the
english
pe
there
is
a
ipsec
tunnel,
it
can
send
the
traffic
of
the
client
into
this
handle
so
that
the
university
can
trust
that
the
building
have
a
check.
That
is
a
valid
user
and
the
information
is
have
been
verified
by
the
png.
E
Thank
you
all
very
much,
so
we
are
still
working
on
the
logistics
of
the
interim
meeting
on
scion
engagement
expect
announcements
to
the
list
shortly,
but
this
will
be
between
now
and
philadelphia
and
I
suspect,
given
sort
of
like
the
engagement
and
all
of
the
really
sort
of
like
interesting
talks
in
the
area
that
we've
had
this
time,
that
we
will
also
have
a
meeting
in
philadelphia.
You
know
a
hybrid
meeting
in
philadelphia
and
it
was
great
to
see
you
all.
E
Thank
you
all
for
all
of
the
talks
in
the
discussion.
It
sounds
like
looking
in
the
chat.
It
looks
like
sort
of
michael's
thing
is
halfway
to
being
designed
a
group
designed
by
people
in
the
chat.
So
we
look
forward
to
some
discussion
of
that
on
the
list
and
to
see
how
that
develops
at
the
next
meeting
as
well.