►
From YouTube: IETF104-PANRG-20190328-0900
Description
PANRG meeting session at IETF104
2019/03/28 0900
https://datatracker.ietf.org/meeting/104/proceedings/
B
C
Morning,
please
wake
up
with
your
helmet
yep.
We
it's
a
part
of
our
networking
group
and
you
have
quite
a
busy
agenda,
so
I
think
we
shall
start
right
now
welcome.
This
is
a
known
well
and
Brian
just
pointed
out,
it's
a
wrong
one.
I
will
action
item
to
fix
it
for
Wally,
reule,
sorry,
but
I,
don't
know
what
the
difference
is.
B
The
IR
TF
basically
follows
the
ietf
policies,
but
I
think
there's
a
different
slide
for
the
earth
yeah.
It's
the
same.
Actually
Dave
you're
up
you're,
looking
at
like
which
do
you
use
for
map
okay
na
we'll
have
a
look
at
this,
but
yeah
do
note.
Well,
the
IP
are
actually
in
in
the
IR
TF.
You
don't
necessarily
have
to
disclose
it
if
it
moves
into
the
IETF
that
you
do,
but
you
should
anyway,
so
we'll
fix
this
for
next
time.
D
C
So
agenda
it's
been
published
to
the
website
any
like
comments,
challenges,
complaints,
three
two
one
sold:
oh
yeah,
so
we
have
two
active
group
documents
and
we
have
individual
drafts
which
we
draft,
which
we
discussed
last
meeting
and
going
to
discuss
today
as
well
and
I.
Think
we
have
one
new
individual
draft
and
I
think
that's
it.
So
we
can
start
with
the
first
presentation
which
I
guess
is
Spencer.
E
Good
morning,
everybody
I
feel
really
good
this
morning,
because
the
weight
of
all
my
doubts
went
away
yesterday.
So
life
is
good,
so
I'm
talking
about
the
obstacles
to
deployment
draft
that
we've
had
in
the
research
group
for
a
while.
This
is
update.
What's
what
happened
in
two
zero
one,
and
what
I
really
want
to
do
is
figure
out
well
how
to
use
this
draft
after
we
agree
what
it
you
need
to
do
with
it
next
so
anyway,
Gouri
provided
contributions
on
st
and
st
and
things
like
that.
E
St
plus
I
see
ICMP
source
quench
and
on
ipv6
flow
labels,
and
he
also
performed
it.
A
significant
review
of
the
show
of
zero
draft
Thank
You
Cory
for
that
I
think
I've
addressed
all
of
his
comments
and
that's
what
went
into
r1.
We,
this
included
a
significant
rewrite
of
section
two.
The
summary
of
lessons
learned,
which
is
kind
of
the
point
of
doing
this
draft,
so
want
to
get
that
right.
That's
what
I
want
to
focus
on
during
this
talk,
so
not
at
the
wordsmithing
level.
E
E
So
this
are
usually
when
I've
talked
about
this
draft
in
previous
panel
tree
meetings,
I've
presented
a
summary
of
the
summary
of
lessons
learned.
This
is
the
unsung
rised
version.
This
is
actual
text.
That's
in
the
draft
don't
want
to
like
I,
don't
want
to
wordsmith
this,
but
want
to
give
people
an
opportunity
to
say
that's,
that's
not
right.
If
that
would
be
an
interesting
comment,
and
another
really
interesting
comment
would
be.
That's
not.
E
You
know
that
used
to
be
true,
but
it's
not
anymore
that
that's
you
know,
that's
gonna,
be
something
that's
gonna
be
really
important
for
us
to
push
down
on
then,
if
we're
using
this
material
to
guide
research
and
to
guide
the
IETF
as
they
are
trying
to
engineer
a
path
where
they're
working
so
first
one
I
can
just
put
these
up
and
let
people
look
at
them
or
dreading.
It
should
I
actually
say
something
out
loud,
okay,
so.
B
E
Yes,
I
I
want
to
I
want
to
stop
on
each
slide
and
let
people
say
that's
not
right
or
that
used
to
be
right,
but
it's
not
right
anymore.
That's,
that's
the
that's!
The
review
and
evaluation
I'm
hoping
to
get
as
a
result
of
this
meeting
from
the
research
group,
so
first
one
overcoming
entropy
for
already
employed
devices,
so
the
benefit
of
path.
Awareness
must
be
great
enough
to
overcome
entropy
for
already
deployed
devices.
E
E
Okay,
cool,
okay,
so
nobody
who
died
for
the
microphone
providing
benefits
for
early
adopters
can
be
key
if
everyone
has
to
deploy
a
technology
in
order
for
the
technology
to
provide
benefits
or
even
to
work
at
all.
The
technology
is
unlikely
to
be
adopted
again,
a
couple
of
contributions
that
have
pointed
this
direction.
F
F
B
Is
what
let
me
so
it's
that
the
audio
is
actually
kind
of
crap
up
here
at
the
front.
Let
me
see,
let
me
restate
this
to
see
if
I
heard
you
correctly
and
see
if
I
can
rephrase
that
slightly.
So
this
is
phrased
entirely
in
terms
of
benefits,
so
the
plus
side
of
the
equation
and
you're
talking
about
cost
reduction.
We
did
a
minus
side
of
the
equation
that
should
be
captured
here.
Yeah,
okay,
that's
good
feedback.
B
E
Thank
you,
I
think,
I
think
the
contributions
that
we
kind
of
taken,
that
out
of
so
actually
here's
the
other
part
of
this,
which
is,
if
there's
things
that
are
missing
or
subtleties
that
are
being
totally
stomped
on,
like
the
one
you
just
mentioned.
It
is
helpful
for
us
to
point
to
case
studies.
You
know
that
would
tell
you
about
that.
I've
I
was
mostly
thinking
about
this
in
terms
of
early
adopter
of
things,
you
know,
I
think
the
classic
one
was
was
like
can't
you
know.
What
can
you
do?
E
E
You
know
in
order
for
people
using
this
to
get
benefits
and
things
like
that,
but
most
of
most
of
those
have
not
been
an
about
costs,
so
it
would
be
helpful
with
you
know.
If
you
can
drop
a
note
to
the
mailing
list,
especially
you
just
say
a
country.
You
know
a
technology
that
points
this
direction
for
cost
would
be
whatever
it
is,
and
we
can
follow
up
from
that
said,
fair,
okay,
cool!
Thank
you,
Eric.
H
Eric
Cline:
is
this
the
same
or
different
from
single
uber
benefits?
You
know,
in
other
words,
you
know
where
one
party
can
can
unilaterally
take
some
action
and
get
some
benefit
versus
two
parties
taking
action
both
of
them
in
a
bit
as
opposed
to
all
parties
having
to
take
action,
which
I
mean,
I
think.
E
That
I
think
the
idea
on
this
one
was
basically
does
everybody
along
a
path
have
to
do
something,
so
you
know
so
you
know,
so
you
had
the
thing
where
it's
like.
Well,
if
you,
if
you
were
deploying
a
new
technology
and
some
of
the
boxes
along
a
path
supported
and
some
of
them,
don't
do
you
still
get
benefits?
Does
it
still
work
that
that's
that's,
what
I
thought
we
were
kind
of
pushing
on
in
section
4.2
and
4.3,
so.
E
E
E
You
know
you,
you
could
you
could
do
some
new
cool
mechanism,
but
if
you're
going
to,
if
you're
going
to
catch
up
in
a
couple
of
round-trip
times
anyway,
was
it
worth
doing
and
the
one
the
continuity,
the
section
that
I
contributed
where
my
idea
failed
was
one
of
those,
and
you
know
it's
like
we're,
not
saying
it's
a
bad
idea.
It
was
also
a
bad
idea,
but
we're
not
saying
it
was
a
bad
idea.
E
The
problem
was
that
a
TCP
that
didn't
support
what
we
were
talking
about
could
catch
up
in
two
or
three
round-trips
anyway.
So
if
you
were
talking
about
making
the
TCP
state
machine
more
complex,
but
you're
going
to
catch
up
in
a
couple
round
trips
anyway,
then
it's
really
not
there's
not
really
not
something
that
is
pushing
the
deployment
of
that
technology.
Is
that?
Does
that
make
sense.
I
If
that's
the
only
one
on
the
list
that
really
matters,
then
you
probably
shouldn't
do
it,
but
it
might
be
worth
doing
that.
Providing
your
system
was
really
robust
and
there's
no
side
effects
a
little
benefit,
but
for
some
people
that
might
be
a
huge
benefit.
So
then
you've
got
to
weigh
out
all
the
other
things
and
I
think
that's
the
tricky
bit
of
the
whole
game
gamma.
So
it's
really
good
to
call
out
these
individual
things,
but
sometimes
a
combination
of
them
is
what
matters
so
a
high-level.
E
Thing
that
I
think
I'm
hearing
here
is
that
if
you
look
at
this
whole
section,
that's
very
interesting,
but
when
we
look
at
individual
bullets
in
this
section
there's
you
know
there's,
like
you
know:
well,
some
of
them
may
interact
with
each
other.
Some
of
you
know
some
of
them
may
and
I
think
the
other
thing
that
I'm
kind
of
thinking
as
I'm
standing
here
is
that
there
may
be
some
of
these
that
are
going
to
be
impediments
to
deployment
and
some
things
that
are
gonna
be
just
absolutely
fatal.
E
E
Thank
you,
I
that
we
may
end
up
with
enough
of
these
kind
of
comments
to
justify
adding
a
section
that
kind
of
you
know
an
entire
section.
That
kind
of
explains
the
relationship
between
these
things
that
we've
learned
in
kind
of
you
know
which
ones
seemed
to
dominate,
which
one
seemed
to
interact.
So
yes,
that
one
also.
L
So
I
think
this
one
in
the
first
one
that
Jake
commented
on
I
think
these
are
really
sort
of
variations
of
the
same
thing
right.
It's
that
the
the
parties
that
bear
the
greatest
cost
have
to
get
some
benefit
right
and
that
you
know
whether
that's
operators
or
users
or
an
system
vendors
or
whatever
it
is
but
I.
But
the
thing
that
occurs
to
me:
I've
been
I'm,
trying
to
dig
out
the
the
citation,
but
the
data
trackers
really
slow
is
the
IV.
L
B
L
B
L
E
I
think
I
think
that
take
a
look
take
a
look
at
one
of
the
one
dot,
something
sections
that
actually
call
out
two
or
three
IV
drafts
in
that
space
and
say
you
know
this
is
general
guide
and
it's
not
particularly
path
aware.
Networking
advise
this
advice
and
guidance,
but
a
general
guidance
unless
they
see
if
I've
handled
that
correctly
or
if,
if
there's,
if
there's
still
some
things,
I
need
to
fix
there.
E
E
You
know
what
have
we
learned
not
from
any
particular
contribution,
but
what
have
we
learned
and
so
you'll
see
most
of
them?
Most
of
these
I
would
say
at
least
certainly
many
of
these,
but
most
of
these
come
up
on
multiple
contributions
so
like
this
one's
come
up
on
at
least
three,
so
the
the
this
is
not
obvious
on
the
slides,
but
the
section
numbers
here
are
section
numbers
in
section
section,
4,
subsection
numbers
in
section
4,
which
is
specific
contributions
on
specific
technologies.
So
this
this
has
come
up
at
least
three
times
so
yeah.
E
B
You
let
me
interject
this
chair
here.
Let
me
rephrase
what
Aaron
is
saying
is
as
like.
A
more
direct
piece
of
advice,
maybe
is
have
a
look
at
this
draft
and
consider
what
is
special
about
path,
awareness
and
the
transitions
that
we're
talking
about
here,
as
opposed
to
other
transitions,
and
maybe
call
that
out.
I
think
you
know,
as
somebody
who
watched
this
draft
progress,
the
process
that
we
had
here
was,
you
know,
go
look
at
what
failed
and
then
try
to
pull
commonalities
out
of
what
failed.
B
Transport
focused
just
because
of
who
was
was
contributing
to
it,
so
I
think
that
in
and
of
itself
is
an
interesting
signal
and
one
that
we
shouldn't
just
attenuate
just
because
it
makes
the
document
a
little
bit
less
verbose.
But
I
wouldn't
reiterate
the
point
that
yeah.
We
should
maybe
be
a
lot
more
explicit
about.
What's
special
about
path,
aware
networking
here,
because
a
lot
of.
E
M
M
One
maybe
the
second
point
you
make
where
you
talked
about
it-
requires
the
operator
to
enable
something
end-to-end.
Maybe
you
can
tease
it
out
by
looking
at
those
mechanisms
where
just
one
or
both
ends
systems
need
to
give
something
where
it's
implemented
in
deployable,
which
is
point
two
versus
things
where
the
operator
has
to
actually
enables
something.
End-To-End
like
this
versus
capacitors
for
third
one,
maybe
more,
where
the
mechanism
requires
something
to
work,
end
to
end
that
the
operator
might
not
enable,
in
fact
they
might
filter
it.
Like
extension,
headers,
for
example,
who.
G
M
And
it's
very
difficult,
as
found
said,
to
make
generic
statements
when
there's
so
many
different
approaches.
I
think
that's
the
problem,
whether
teasing
it
out
to
different
categories
of
approaches
might
help
if
you're
thinking
of
building
something
that's
just
those
systems
is
some
points.
If
you
require
operator,
enablement
is
in
place,
yeah.
E
E
Dating
back
to
the
land
of
like
in
serve,
we
have
always
known
at
some
level
that
per
connection
state
and
intermediate
devices
was
going
to
be
a
problem,
so
that
was
what
was
being
captured
here
and
I
really
want
to
get
a
sense
either
here
or
on
the
mailing
list,
or
both
for
their
people.
Think
that
they
can
do
this
now,
where
we
we
couldn't
do
it
before
yeah
I
mean
there
were
a
lot
of
things.
We
try
to
meet
what
we
wanted
to
do
before
that
we
just
couldn't
do
so.
N
Very
much
at
the
edge
of
the
network,
you've
got
a
lot
more
power.
You've
got
devices
that
can
touch
more
of
the
package
and
can
do
things
and
the,
and
we
have
an
existence
group
with
NAT
and
gateways
and
stuff
in
the
core
of
the
network.
It
is
really
really
hard.
Alright,
you
can
see
the
packet,
you
don't
even
see
those
counters
that
you
increment
right.
N
You
sort
of
ping
a
thing
off
somewhere
and
some
things
are
hardware
changes
a
piece
of
brand
that
you
can't
even
get
to
so
her
connection
state
as
something
that's
tripped
us
up
a
few
times.
An
example
is
trying
to
do
in
debt,
because
everything
that
we're
in
trying
to
figure
out
whether
you
see
another
instance
of
this
packet
before
on
a
different
interface,
almost
impossible
to
get
it
between
interfaces.
N
Then
there
are
other
examples
when
we
will
try
to
instrument
the
network
where
we've
had
to
go
to
special
technologies
in
MPLS
in
order
to
find
out
when
a
flow
actually
stopped,
because
the
packets
from
different
flows
or
a
flow
group,
rather
different
flows,
may
go
different
ways
across
the
network.
So
it
ends
up
where
you
are
on
what
speed
you
want
to
do
it
at
I
am.
B
G
B
One
really
interesting
thing
that
we
might
see
with
the
deployment
of
quic
is
when
you
multiplex
a
lot
of
flows
into
a
single
flow.
Each
endpoint
might
be
responsible
for
fewer
Network,
visible
connections
than
it
was
in
the
past.
So
these
numbers
are
all
going
to
keep
changing
but
they're
going
to
keep
changing
in
such
a
way
that
they're
I,
don't
think
there'll
be
any
any
significant
change
to
where
the
boundary
is
between,
where
you
can
and
where
you
can't
it's
gonna
keep
sloshing
back
and
forth.
It
always
has
and
always
will
yeah.
E
And
I
think
actually
ask
you
to
keep
stuff
there,
but
change
hats
for
you
and
Jen
that
that
that
this
is
kind
you
know,
kind
of
what
I've
been
doing
here
has
been
about
he's
been
about
trying
to
identify
principles
and
one
of
the
things
that
you
know
happens
when
you
go
from
section
4
to
section
2.
Is
that
you're
less
subtle
in
question
in
section
2
that
you
were
on
it
when
you
were
talking
about
a
specific
technology?
E
M
M
With
the
two
sessions
you
had
on
quantum
Internet
ey
are
G
one
thing
that
they
they
did
present
there,
which
maybe
think
was
that
to
actually
move
quantum
state
from
A
to
B,
where
you
have
multiple
quantum
repeaters,
you
need
to
do
entanglement
swapping
and
you
need
to
maintain.
You
need
to
have
a
parallel
data
classic
Internet
data
path
between
all
the
quantum
nodes
over
which
other
bits
are
sent,
but
they're
also
having
quantum
node
States
to
do
that
and
an
RSVP
like
protocol.
So
maybe
that's
the
only
way
they
think
they
do
that.
M
M
E
You
know
we
were
trying
to
decide
whether
we
were
going
to
run
everything
over
IP
or
whether
we
were
going
to
have
other
protocols
at
that
layer
that
behaved
different
from
IP
on
the
same
path.
So
I
mean
like
that.
That
goes
a
lot,
but
you
know:
do
people
have
to
slog
through
all
of
that
to
figure
out
what
to
do
now
and
so
I'm?
Finding
that's!
M
E
N
So
the
other
thing
that
needs
to
come
to
come
out
here
is
there's
a
difference
between
per
connection
statement
posed
by
the
control,
plane
and
per
connection
state
imposed
as
a
result
of
a
data
packet
path.
Passing
through.
We
have
existence,
proof
that
providing
you
persuade
the
operator
to
deploy
it.
That
things
like
RSVP
is
a
good
example
of
her
connection
state
that
was
imposed
in
the
control
plane
and
then
just
used,
as
so.
E
E
A
lot
of
the
stuff
that
came
in
this
round
of
updates
was
rent
but
kept
going
to
the
routing
and
forwarding
part
of
the
part
of
the
community
to
see
what
their
experience
has
been
and
I
think
you
know,
I
was
hoping
that
we
were
ready
to
do
that
and
that
that
would
be
a
useful
thing
to
do,
and
I
think
you're
kind
of
telling
me
that
it
is
and
I
appreciate,
I
appreciate
that
very
much.
You.
N
O
O
E
F
G
F
Call
them
out
and
say
these
are
counter
examples
to
this
thing.
Here's
what's
different
about
them,
because
I
think
that's
going
to
be
like
the
advice
to
do.
None
of
these
things
is
going
to
be
really
hard
to
follow
for
the
worst,
like
here's.
The
difference
between
ones
that
worked
and
ones
that
didn't
look
at
him
and
draw
conclusions
is
maybe
more
easily
so.
E
You
should
consider
the
guidance
used
to
figure
out
how
much
of
it
is
applicable
to
you
versus
how
much
of
it
is
applicable
to
other
things
which
are
not
what
you're
trying
to
do
and
that
you
would
of
course
do
the
right
thing,
because
making
good
choices
is
what
we're
all
about.
I
have
a
t-shirt
right.
I
With
myself,
but
agreeing
with
Stuart
I
mean
I
was
thinking
that
in
TS
bwg
we
just
got
an
email
talking
about
and
how
how
you
might
want
to
do
per
flow
accounting
of
things
to
occur,
about
overlord
and
fairness
or
congestion,
class
prevention.
So
because
her
connection
state
is
something
interesting.
That's
not
necessarily
to
do
with
the
forwarding
decision,
so
you
might
want
that,
but
it
doesn't
stop
forwarding
and
that
guess,
that's
somehow
linked
to
what
Stuart
was
saying
about
control
plane
and
how
you
use
it,
etc.
I
So
maybe
we
need
to
capture
that
a
bit,
but
that
was
my.
That
was
a
comment.
My
question
was:
how
does
all
this
fit
in
with
the
path
we're
routing
or
path
we're
forwarding
when
you
have
devices
on
the
path
that
have
state
and
other
ones?
Don't
have
state
I?
Think
that's
that's
something
where
you
might
find
something
radically
different.
When
your
path
aware
networking
says
do
this
and
suddenly
you
end
up
with
a
different
set
of
boxes
on
the
path,
because
some
of
them
are
smart
to
state
yeah.
E
Acting
like
if
I'm
understanding,
you
you're
basically
saying
that,
there's
a
tension
between
canonical
bad
ideas,
and
but
you
got
to
do
it
anyway
in
order
to
make
this
work.
So
how
are
you
going
to
take
for
you
to
make
it
work
yeah?
But
why
is
this
not
going
to
be
another
contribution
in
the
this
of
this
type
of
drift
of
things
that
don't
work?
Well,
what
changed?
What
did
you
do
differently?
You
know,
maybe
maybe
you
put
maybe
per
connection
state
in
a
different
place
in
the
network.
You
know
that's
a
reasonable.
I
Strategy
but
then,
when
you
have
some
pasta,
one
thing
that's
trying
to
pick
two
paths:
you
might
get
some
of
these
boxes
on
one
patterns
of
these
boxes,
not
on
the
other
path.
I
know
your
path,
aware.
Networking,
if
we
think
about
doing
this
is
a
big
solution,
is
there's
another
level
of
issue
here,
because
the
boxes
aren't
all
the
same
that
you
choose.
So
if.
B
Think
this
is
yeah.
This
is
I
mean
this
is
a
really
interesting
conversation,
because
it
actually
is
showing
that
that
you
know
we're
trying
to
decompose
this
problem,
we're
being
analysts
about
it
with
these
two
different
drafts,
but
when
you're
actually
trying
to
think
about
well,
how
could
we
build
something
different
in
this
space?
That's
not
a
fundamentally
analytical
tasks
right,
so
maybe
they're
so
part
of
the
outcome
of
this
discussion
is.
Maybe
we
need
to
think
about
again
how
these
two
overlap
and
what
the
next
steps
are.
But
that's
really
not
this
discussion.
B
I
will
note
that
we
have
one
team
or
minutes
for
this
discussion
and
seven
more
slides
to
get
through
on
questions,
and
they
do
get
much
more
detail
as
we
go
down.
They
get
much
more
path,
aware.
Networking
II,
so
I'd
ask
I'm
gonna
cut
the
lines
with
it
with
the
two
of
you
and
ask
you
to
be
brief
and.
P
Telecom
we
are
running
an
MPLS
backbone
and
network
separation
by
MPLS
is
actually
a
security
feature
to,
and
you
might
want
to
add
that
to
your
list,
that
opening
that
to
outsiders
is
for
us
breaking
our
security
and
path.
Tracing
in
an
MPLS
network
is
probably
possible.
It
requires
some
additional
features,
but
Harpreet
determination
well,
I'm,
not
aware
how
you
would
do
that
without
installing
state
prior
to
the
first
packet
arriving.
N
What
he
said,
but
what
I
came
up
here
to
also
say,
is
that
it
depends
on
whether
you're
talking
about
base
or
an
overlay
so
and
you
can
do
what
your
liking
your
own
overlay,
writing
you
and
deploy
it
and
before
people
say
yeah
well,
overlays
are
bad.
You
realize
that
you're
almost
certainly
running
on
an
overlay
when
you're
running
in
pace,
because
the
transport
network
people
transport
network
in
the
tense,
the
Elector,
you
use
it
they're
running
a
high
rahul
network,
underneath
it's
just
that
you
don't
see
it
cool
so.
E
Just
just
block
is
a
just
kind
of
blowing
through
where
we
are.
Am
I
diving
for
my
last
slide
yet
yeah,
yeah,
yeah,
I,
think
I
think
I
skip
a
couple.
You
know
that
way.
Yeah
this
one
this
one
we
talked
about.
We
talked
about
this
a
lot
I
mean
we
talked
about
this
for
two
hours
in
the
spherical
router
session
last
night,
yeah
yeah
yesterday
afternoon.
E
So
we're
not
going
to
have
that
conversation
again
here
because
it
took
two
hours
the
last
time,
but
just
awareness
of
this
and
like
I,
say
we're
pushing
on
this
and
other
venues
as
well.
So
definitely
having
that
conversation
which
I
owe
the
community
I
will
owe
the
community
minutes
from
that
session.
Also
yesterday,
so
I
will
try
to
point
that
I
will
try
to
remember
to
point
panarchy
to
that
output
and
our
y'all
do
to
have
that
to
consider.
E
This
is
something
that
we've
talked
a
lot
about
in
the
transport
area
over
the
past,
probably
three
or
four
years,
we've
in
certainly
we've
had
a
lot
of
conversations
that
were
guided
by
the
IEP
in
that
space.
Also
so
I
say
just
just
like
I
say
just
awareness
of
both
of
those
and
that
they're
both
you
know
that
they
both
met
her
and
they're,
not
the
same
trust
in
each
direction.
E
Providing
actionable
information-
and
this
was
basically
the
ones
where
I've
told
you
something
about
the
network
path.
There
was
not
on
a
top
that
you're
close
to,
and
it
was
long
enough
ago
to
where
this
is
where
the
situation
could
have
changed
at
the
location
that
I'm
telling
you
about
so
basically,
basically
making
sure
that
we're
not
trying
to
react
to
things.
That
may
not
be
true
anymore
and
that's
been
a
that's,
been
a
couple
of
things
if
that's
come
up
with
different
type
with
different
technologies,.
E
One
of
their
experiences
should
we
capture
to
add
two
lessons
to
add
additional
lessons.
Learned
I
was
a
little
bit
surprised
that
we
were
able
to
put
in
three
new
contribution
sections
in
section
4,
4
St,
for
source
quench
and
for
label
for
labels.
But
what
we
were
learning
from
them
was
different.
E
We
were
adding
lessons
learned
to
buoy
section
2
as
a
result
of
those
new
contributions,
so
they
kind
of
told
me
that
I
wasn't
finished
yet
so
you
know
what
else
do
we
need
to
capture
and
recognizing
that
we
started
out
with
a
really
transport
a
heavy
set
of
contributions,
and
that
we've
been
adding
things
in
the
nth
space
and
that
we
talking
about
reaching
out
to
routing
space
and
I?
Think
one
of
the
things
I
was
getting
from
comments
around
discussion
around
Stewart's
comments
were
that
reaching
out
for
routing,
maybe
next.
E
E
E
B
People
are
getting
to
the
mic
on
that
question,
so
we
keep
talking
about
reaching
out
to
routing.
So
some
of
this
is
a
little
bit
the
chairs
fault
for
not
being
more
forceful
and
trying
to
deconflict
this
with
things
that
were
interesting,
routing
people.
It
took
us
about
three
iterations
to
get
our
conflicts.
Let's
correct!
We've
only.
E
E
So
thank
you
for
that,
and-
and
the
other
thing
is
you
know
now
that
I
know
that
I
don't
have
to
cover
transfer
area
working
groups
all
the
time.
I
have
a
lot
more
flexibility
to
go.
Do
things
like
that
now,
so
this
is
something
that
we
can
do
I
think
better
in
the
future
than
we've
done
in
the
past.
So.
N
There
is
another
driver
that
you
need
to
be
aware
of
who
I'm
sure
people
are
aware
of,
and
that's
Network
slicing,
because
network
slicing
does
require
and
states
in
the
network
to
support
applications
because
they're,
the
extremity
of
latency
property,
for
example,
and
bandwidth,
property
and
isolation.
As
one
thing
second
thing
is
the
there's.
G
M
E
Yeah
I
think
I,
say
I
think
one
of
the
things
I'm
carrying
away
from
this
I
started
peak
about
this
like
this
morning
before
this
session
started
I'm,
really
taking
us
away
from
the
comments
that
have
been
made
that
we
need
to
do
a
better.
We
I
keep
going
back
and
forth
between
we
and
I.
So
Cory
and
I
have
manipulated
most
of
the
text,
that's
in
there,
but
it
is
a
research
group
to
have
so
somewhere
between
I
and
we
need
to
need
to
do
a
better
need
to
add.
E
M
From
reaching
area-
and
things
like
that,
but
I
think
in
general
it's
some
kind
of
guidance.
I
know
we
can't
do
peace
and
P
here,
but,
for
example,
if
you
take
second
routing
which
I
don't
think
it's
mentioned
in
the
document,
maybe
the
path
must
be
determined.
Is
it
good
or
bad?
Cough
yeah,
no
pun
intended.
M
E
The
IAB
does
good
work
that
isn't
ECP's
either
anymore,
so
you
know
that
that's
a
possibility,
not
that
we
would
tell
the
IETF
what
to
do,
because
that
always
ends
badly,
but
that
the
ID
is
G
could
say
that
those
who
could
idea
this
is
a
good
idea
and
we're
going
to
be
kind
of
looking
to
see.
If
people
are
aware
of
it,
we
were
chartering
work
and
when
we're
evaluating
work
so,
like
I,
said
I'm
not
telling
you
I'm
not
telling
you
that
we
can
tell
people
what
to
do.
E
E
Well,
thank
you,
and
it
is
definitely
true.
The
different
I
RTF
research
groups
have
different
styles
of
interacting
with
IETF
working
groups.
You
know,
if
you
think
about,
if
you
think
about
well,
we
what
the
transport
area
gets
out
of
IC
crg
of
what
the
entire
community
gets
out
of
Krypton
form
research
group
there
there
there
are
different
models
that
we
can.
We
can
definitely
be
looking
at
on
how
this
research
group
might
want
to
be
used.
P
Yeah
try
to
figure
out.
Maybe
what
is
the
real
requirement,
because
if
I
hear
that
network
should
be
sliced
and
then
the
argument
is,
we
need
the
path
with
a
shortest
delay
and
that
seems
to
be
the
requirement.
The
shortest
delay.
Don't
understand
the
rest
of
us
slicing.
You
can
have
a
PRF,
of
course,
and
your
own
labels
right,
but
you
don't
need
a
path
in
the
network,
but
then
also
figure
out.
If
this
path
with
the
shortest
delay
is
broken,
would
you
like
to
get
a
backup
path?
G
E
For
follow-on
work,
you
know
faces
yeah
yeah.
This
is
this
is
kind
of
what
they
like
that
research
group
is
chartered
to
do
so.
Definitely
Wendy.
What
do
you
notice?
Don't
tell
me
to
step
down
excellent,
so
my
wait
until
my
last
thing
was
basically
how
long
you
know
how
long
do
we
need
to
continue
to
iterate
on
this
drug?
This
type
of
draught
in
this
research
group
and
yo
and
I
will
defer
to
the
Correa's
chairs
for
thoughts
about
that.
E
N
C
B
Would
say
that
yeah?
So
your
third
point
here,
girl
routing
you
know,
follow
the
path
follow
the
path
into
the
into
the
routing
area
have
like
make
sure
that
people
they
are
aware
of
this
and
see
if
we
can
also
come
up
with.
You
know
various
train
wrecks
from
the
past
to
to
learn
from
and
then
yeah.
We
can
have
this
discussion
again
in
Montreal
I'm,
assuming
well
we'll
try
to
get
on
the
agenda
for
routing
working
group
in
Montreal,
so
it
might
be.
C
B
B
This
is
gonna
expire
in
a
few
weeks.
I
think
we've
had
good
discussion
about
this
document.
Many
of
the
previous
energy
meetings
have
been
on
the
agenda
like
so
at
each
of
these.
Each
time
we've
iterated
on
it,
we've
gotten
good
input.
I've
brought
it
into
the
document.
I
think
that
we're
kind
of
done
with
this
one
and
I
would
like
to
ask
the
the
research
group
sort
of
as
the
editor
of
this
document
my
editor
had
on
what
we
want
to
do
with
it.
B
Do
we
want
to
leave
it
open,
or
do
we
want
to
publish
it
as
an
RTF,
RFC
I
personally
lean
toward
publishing?
This
is
my
RTF
RFC
simply
because
I'd
like
to
have
a
thing
to
point
to
in
other
fora
when
I
they're
like
path
we're
networking?
What
is
that
there's
like
well?
This
is
the
set
of
questions
that
we're
looking
at
so
I'd
like
to
have.
This
is
a
snapshot
in
time
and
maybe
we
could
add
some
some
language
to
it
at
the
front
that
says
you
know.
This
is
not
the
end.
B
E
E
Okay,
okay,
I
have
to
be
retrained
so
expensive,
all
cones
and
I.
Think
that's
brilliant,
though
the
one
suggestion
I
was
going
to
make
and
I
think
that's
on
the
bottom
of
my
slides
last
slide
was:
are
we
going?
Is
it
worth
looking
at
what
we've
learned
and
what
we
think
the
research
questions
are
and
saying?
Are
there
additional
research
questions
that
we
really
need
to
solve
in
order
to
do
the
kinds
of
things
that
are
what
to
do?
E
B
Q
Q
It
is
timely
to
to
frost
this
document
now
and
to
publish
as
an
RFC
I
think,
that's
the
pointer
is
there,
so
we
can
just
party
to
the
current
work
for
the
drugs
that
people
may
be
aware
of
what
is
currently
I
would
say,
discussed
here
in
this
working,
but
I
think
it's
really
too
early
to
declare
for
this
one.
Let
it
let
it
open
more
and
see
more
feedback
from
from
from
the
can
afford.
Okay,.
B
B
F
My
problem
when
I
read
this
draft
is
that
I
ended
up
like
feeling,
okay,
so
what
and
I
wish
there
was
a
just
a
little
bit
of
actionable
suggestion
in
there.
Like
you
know,
energy
is
looking
for
documents
that
address
some
or
all
of
these
questions.
For
example,
I.
Don't
know
if
there's
other
actionable
things
that
could
be
mentioned,
but
that
would
be
a
good
one.
So.
B
R
B
R
B
Yeah
I
think
my
main
reason
for
wanting
to
do
this
is
to
have
something
that
is
archival
to
talk
about
this
in
fora
outside
the
IETF
in
the
RTF.
It's
really
to
answer
the
question
of,
but
I
mean
like
I,
can
just
as
easily
send
a
link
a
data
tracker
link
to
to
the
document
in
in
in
progress
as
I
can
NRF
see.
That's
fine.
G
And
so
I
like
that,
you're
capturing
the
problems
faced
here
and
you
keep
saying
it's
a
snapshot
and
it's
not
credibly
clear
to
me
from
reading
it
that
this
is
not.
This
is
just
a
snapshot
and
the
eg
expect
for
it
to
change
over
time
and
for
this
their
problems
needs
to
evolve.
So
that's
just
a
comment.
That's
not
incredibly
clear
to
me
from
reading
it
and
it
might
be
obvious
that
rubbish.
I
F
You
know
if
it's
gonna
be
a
relatively
short
timeline
like
five
to
ten
years
and
we
think
it'll
be
kind
of
solved
then
yeah,
maybe
just
keeping
a
draft
alive.
Is
that
long.
But
if
it's
gonna
be
more
like
twenty,
then
I
think
the
RFC
might
be
useful
in
an
update
later
if
they
change
or
something
you
know.
B
B
S
K
So
we
did
three
major
changes.
The
first
one
is
we
added
a
section
called
terminology
where
we
describe
all
the
relevant
terms
which
we
use
in
this
document.
I
will
quickly
go
through
of
all
the
definitions
we
made
the
first.
We
have
a
path
element
which
is
either
a
device
or
link
on
which
a
packet
can
be
sent
or
forward
the
door
sent
over.
K
Q
Have
every
one
problem
from
the
first
bullet,
so
if
we
just
define
a
path
limit
as
a
device,
then
we
lost
all
the
visibility
on
the
service
functions
that
are
embedded
in
d-pad
device
except
so
the
path
is
not
all
CEO.
It's
not
all.
Only
the
composed
of
I
would
say
devices,
but
it
is
I
would
say
a
sequence
of
service
functions
that
are
involved
in
that
pad.
Q
So
I
would
like
to
have
something
which
is
more
visible
if,
for
instance,
if
you
are
talking
about
method
passing,
for
instance,
multi-party,
we
did
with
that
with
a
given
service
function,
we
should
I
would
say
we
call
that
convertor
impeded
if
you
disappear
and
this
kind
of
work.
So
we
need
to
have
this
kind
of
visibility
and
the
definition
of
the
path.
So
it
is
to
not
to
be
specific
only
to
hardware
and
under
device
not
themselves
so.
K
I
guess
the
idea
is
to
kind
of
define
a
path
and
then
we
can
still
describe
stuff
that
is
more
on
a
lower
level
or
a
higher
level.
But
and
that's
why
I
think
that's
us
thinking
we
had
that
we
define
it
as
a
network
layer
on
a
device
level.
Then
you
can
still
describe
stuff
within
one
device,
so
different
functions
within
a
device.
If
I
understood
your
comment,
correction.
Q
Generalize,
the
old
definition
of
the
path,
which
is
only
the
consequence
of
the
order,
seconds
of
nodes
to
unordered
seconds
of
service
factions.
The
service
function
may
be
co-located
with
a
given
device
or
may
be
emitted
in
various
ones.
So
we
need
to
zoom
a
little
bit
on
this.
I
would
say
the
device
itself
to
enter
into
this
sequence
of
the
service
functions.
Some
of
the
path
awareness
factions
will
be
provided
by
the
service
functions
and
not
visible
to
I
would
say
to
the
aggregate
device
that
will
host
dispatchers
themselves.
Q
G
N
K
N
J
Was
like
I
think
I
could,
while
ago,
at
some
other
meeting
of
this
book,
I
commented
on
to
my
disappointment,
with
the
lack
of
formalism
in
it's
still
there
even
on
this
slide,
but
you
don't
differentiate.
What
is
the
device
and
what's
the
link,
we
you
allow
past
segments
exists
of
only
of
links
and
no
devices
or
only
of
devices
with
no
links.
You
said
it's
an
ordered
set.
What
is
it
ordered
by?
Is
it
a
total
ordering?
J
J
J
K
K
J
U
Just
to
commit
Jochen
Fubini,
there
is
substantially
overlapping
between
this
work
and
what
has
been
done
in
the
high
ppm.
So
we
have
RFC
keep
that
defines
all
of
these
tops
rings
and
so
on.
Class
C
IP,
some
properties
that
are
very,
very
related
to
what
is
defined
here,
but
there's
the
route
draft
that
is
commonly
a
working
group
in
IP
that
also
defines
the
route
and
and
so
on.
So
in
a
much
more
formal
way,
I'd
suggest
to
see
and
commonalities,
and
perhaps
so.
F
Write
J
:
I
just
want
to
disagree
with
a
couple
of
the
prior
commenters
I'm.
Looking
at
the
draft
and
to
me
it
looks
like
there
is
a
nuance
and
expressive
not
to
say
it
could
not
be
improved,
but
that
some
of
the
comments
presented
previously
have
already
been
addressed
by
the
current
text
of
the
draft
in
mind.
N
So
you
really
need
to
read
I
think
our
hCAT
402,
which
defines
segments
second
routing
architecture,
because
that
I
do
see
a
huge
overlap
here
and
but
people
who
wonder
why
you
might
want
to
specify
device
or
link
what
second
routing
does
is
to
have
the
concept
of
strict
and
loose
routing
and
to
do
loose.
You
go
to
a
device
to
go
strict.
N
You
go
to
a
through
a
link,
so
you
may
specify
I
said
the
leaks
you
want
to
go
through
or
you
may
want
to
specify
a
set
of
devices
or
you
may
want
to
specify
both
depending
on
exactly
what
we're
trying
to
achieve.
But
this
really
does
need
to
align
with
a
piece
of
work
be
going
on
for
five
years
over
in
the
main
I
made
ITF.
Okay,.
B
A
chair
question
for
Stuart:
if
you
could
get
back
up
so
I'm
like
passingly,
aware
of
the
work
in
spray
I
mean
I,
could
I
I
know
what
it
is,
but
I
haven't
looked
too
deeply
into
the
architecture
in
Europe,
and
you
know
somebody
who
spent
some
time
on
that
is
the
architecture
of
that
generalizable,
so
that
we
could
talk
about
path
properties
in
a
way
that
is
not
tied
to
the
the
segment
routing
header
and
how
its
implemented
into
pin
spring
yeah.
That's
a
you.
B
N
That
remember
the
thing
about
spring
is
that
they
can
strut
the
part,
and
then
they
put
the
part
in
the
packet
as
opposed
to
putting
the
path
in
the
control
plane
or
specifying
in
some
other
way,
I'm,
not
sure
whether
it
would
be
directly
applicable.
But
we
certainly
need
to
make
sure
that
we
don't
have
a
clash
of
terminology.
Absolutely.
K
After
the
neutral
flow,
we'd
actually
find
a
property
which
is
a
tuple
which
consists
of
the
name
of
the
property,
for
example,
whether
it's
a
maximum
data
rate
or
a
latency,
the
value
of
this
property
and
the
path
segment
which
is
defined
on
and
the
flow
which
is
defined
on
so
it's
possible
to
define
a
property
only
on
a
path
segment
and
not
on
a
flow.
For
example,
if
we
look
at
the
MTU,
it's
not,
it
doesn't
depend
on
an
actual
packet
being
sent.
K
But
if
you
look
at
the
latency
or
the
queuing
state
of
the
network-
and
we
also
need
to
incorporate
the
flocks
or
the
packet
being
sent-
and
we
can
aggregate
properties
so
essentially,
aggregation
is
simple-
simply
a
function
from
a
set
of
properties
to
a
single
property
examples.
This
could
be
in
a
miracle
aggregation,
sucess,
minimum
or
illogical
aggregation,
which
says,
if
a
set
or
if
this
property
exists
for
any
of
the
path
elements
of
path
segments.
K
Then
it's
valid
for
the
path
itself,
and
then
we
can
sting
wish
between
measures
and
potential
properties
where
a
measured
property
describes.
An
actual
measurement
and
the
potential
property
is
an
estimation
of
of
a
property
value.
At
a
certain
point
at
time,
it's
important
to
note
that
if
you
have
a
potential
property,
you
need
to
have
some
notion
of
certainty.
K
If
it's
in
the
future,
you
might
say
I,
don't
know
what
will
happen
between
now
and
future
if
you
only
infer
its
property
from
another
measure
property,
you
also
need
to
say
that
there's
some
some
error
margin
for
this
potential
property
and
the
second
big
change
was.
We
had
a
three
use
cases.
This
was
due
to
a
comment
which
said
it's
not
clear
why
we
chose
the
path
properties
that
we
described.
So
how
did
we
reach
to
this?
K
Okay
and
then
we
have
our
selection
either
from
the
network
perspective.
My
perspective,
it's
important
that
end
point
selection,
similar
to
outdoor,
which
provides
a
better
than
random
pure
selection,
so
it
there
are
fairness,
also
relevant,
and
then
we
did
some
changes
to
our
path
properties.
For
example,
we
took
some
low-level
property,
such
as
wireless
single
translation
or
a
channel
B
to
say
and
changed
it
to
the
more
generic
current
and
maximum
data
rate,
which
is
also
used
in
the
dynamic
link
exchange
protocol,
and
we
did.
C
So
sorry,
we
ran
out
of
time,
so
I
think
based
on
the
feedback.
I
think
it's
maybe
too
early
to
talk
about
adoption,
because
I
think
you
have
some
action
item
to
address
and
sorry
yeah.
We
don't
have
time
for
questions,
but
I
appreciate
if
people
will
send
their
comments
and
suggestions
to
the
list.
So
sorry,
we
just
thank
you
and
we.
B
A
V
So
yes,
I'm
gonna,
make
it
quick,
hello.
Everyone
pleasure
to
be
here.
My
name
is
Stefan
I'm
presenting
to
you
some
use
cases
that
we
do
have
for
security
on
on,
based
on
upon
energy
work,
which
is
more
or
less
multipath
routing.
Well,
the
anonymized
black
guy.
Here,
oh
that
you
see
over
there
could
have
been
pretty
much
me.
The
last
time
I
was
trying
to
get
an
S
marm
certificate
into
my
mail
client.
So
I
was
desperate,
interesting
in
an
encrypted
email
and,
of
course
asymmetric.
V
Crypto
is
cool
and
we
do
it
in
research
and
we
teach
it
at
the
University,
but
it
still
is
computationally
heavy,
its
computational,
difficult,
cumbersome,
really
expensive,
and
eventually
my
problem
was
settled
with
a
tactical
knockout
in
the
10th
round.
After
an
hour,
the
mail
client
convinced
me
just
to
not
use,
as
my
many
more
so
I
ended
up,
sending
and
sending
an
password-protected
zip
file,
because
I
simply
couldn't
get
it
to
accept
the
s/mime
certificate
so
and
and
I'm
even
a
security
person.
V
So
what
I'm
looking
for
is
usable
security
and
even
lot
more
than
10
years
ago,
we
already
came
up
with
the
idea
to
be
perfect,
CIA
plus
security,
which
means
confidentiality,
integrity,
availability.
Authenticity
is
actually
doable
using
only
symmetric
crypto
that
originated
from
quantum
network
security.
Actually,
we
figured
that
applies
in
any
any
kind
of
network.
There's,
not
least
no
need
for
quantum
here.
So
we're
using
only
point-to-point
shared
secrets.
We
can
do
it
without
certificates,
so
it's
cheap.
V
So
the
idea
is
actually
multipath
routing,
which
means
that
I
am
trying
to
send
my
message
over
a
couple
of
pass,
hoping
that
there
is
at
least
some
sort
of
positive
probability
that
the
adversary
wouldn't
catch
all
the
distal
packets.
So
as
long
as
there
is
at
least
one
of
these
paths
not
being
intercepted
by
the
adversary,
I
have
a
chance
to
say
to
get
my
message
with
arbitrary,
strong
security.
I
don't
need
to
have
any
in
to
initiate
secrets
here.
This
is
what
we
call
a
theory.
A
moving
target.
V
Defense
is
actually
a
matter
of
research
in
game,
theoretic
security
which
kill,
which
is
in
parallel
to
to
the
classical
crypto.
So
after
all,
we
ended
up
with
some
use
cases
or
requirements
for
the
use
case
of
using
partha
we're
rooting
for
perfect
security
without
much
certificates
in
public
key
crypto.
We
need
to
know
a
number
of
passed.
V
We
need
to
know
the
path
elements
in
any
way
they
might
be
defined
now
or
later,
and
we
need
some
sort
of
reliability
of
the
packet
to
stay
on
that
path,
so
we're
actually
counting
on
the
network
to
deliver
the
packet
on
the
way
that
we
chose,
and
that
goes
into
the
draft
as
a
requirements.
We
thought
once
we
go
to
intersections
and
also
we
need
to
rely
on
this
to
be
able
to
work
in
cross
domain.
V
It's
much
done
that
much
deeper
below
that.
We
require
some
device
pairing
to
be
enforced,
by
which
I
mean,
of
course,
I'm.
Sorry
for
the
fuzzy
terminology
here,
devices
just
means
we,
whichever
node
actively
sends
something
to
another
node,
should
do
so
encrypting.
It
should
be
paired
in
the
sense
of
sharing
keys
with
that
further
node
and
refreshing
them,
so
that
would
be
requirement
3.6
and
well.
Actually,
that's
it.
P
E
W
Okay,
so
hello,
my
name
is
Simon
and
my
talk.
I
will
talk
about
how
game
theory
can
help
us
to
reason
about
the
efficiency
of
partner
network
architectures
and
to
eventually
help
us
to
make
them
more
efficient.
So
the
terminology
I
use
here
is
about
source
based
power
selection
and
what
I
mean
by
this
is
basically
a
path
where
networking
architecture
where
a
nice
pea
offers
its
customers
so
the
end
hosts
a
set
of
possible
paths
to
destination
and
the
end
hosts
can
then
choose
for
themselves
which
have
to
use
for
communication.
W
This
is,
in
contrast
to
network
based
path
selection,
where
basically,
one
single
path
is
offered
by
the
network
operator
as
a
result
of
BGP.
So
whenever
we
discussed
these
two
paradigms
and
the
relative
efficiency-
and
we
will
always
encounter
basically
the
following
opinion,
so
in
general
network
operators
like
network
based
path
selection,
because
for
them
it
means
that
they
can
engineer
and
coordinate
and
orchestrate
traffic
very
well.
So
since
they
have
a
lot
of
experience,
a
lot
of
information
about
their
network,
they
can
basically
guarantee
and
overall
efficient
traffic
outcome.
W
So
it's
to
use
this
analogy.
It's
like
by
the
scale
of
a
good
conductor
that
the
music
of
individual
musicians
will
become
a
nice
symphony,
it's
by
the
scale
of
the
network
operator
that
individual
flows
can
be
fit
into
an
overall
efficient
traffic
allocation.
In
contrast
to
that,
source
based
path,
selection
is
viewed
as
something
like
that.
So
network
operators
fear
that
if
an
host
choose
their
own
path
through
the
network,
basically
anarchy
and
chaos
will
break
out.
W
So
without
the
appropriate
information
and
without
coordination
and
those
will
take
by
traffic
allocation
decisions,
they
will
engage
in
mutually
destructive
behavior,
and
so
the
nice
efficient
traffic
allocation
will
give
rise
to
a
much
more
inefficient
traffic
allocation.
And
so
the
question
I'm
interested
in
is
how
justified
is
this
fear
or
put
more
technically?
How
inefficient
is
the
traffic
allocation
that
we
can
expect
the
result
from
selves
and
those
decisions
and
as
kind
of
constructive
follow-up
question,
whether
it
can
reduce
this
inefficiency
by
providing
the
appropriate
information?
W
In
order
to
tackle
these
questions,
we
need
to
have
a
way
to
quantify
the
inefficiency,
the
results
from
selfish
decisions,
and
we
need
to
capture
be
able
to
capture
the
effect
that
information
has
on
this
efficiency,
and
we
can
do
this
by
game.
Theoretic
concept
called
the
price
of
Anarchy,
where
we
need
a
social
cost
function
that
captures
the
social
cost
of
a
traffic
allocation
and
a
way
to
characterize
social
optimist
or
traffic
allocations
which
minimize
the
social
cost
and
Nash
equilibria.
W
So
traffic
allocations
for
no
single
agent
will
unilaterally
deviate
and
change
its
traffic
allocation,
so
these
are
like
stable
states
in
a
network
and
once
we
have
these
three
components,
we
can
derive
this
price
of
energy
for
that
and
we
need
to
have
a
model
of
source
based
off
selection,
which
is
here
presented
for
the
inter-domain
context.
So
you
have
the
autonomous
systems
or
a
SS
in
blue
and
links
interests,
links
alpha
beta
and
gamma.
Every
and
hos
reas
can
accommodate
n
toes,
for
example.
W
W
But
then
we
can
derive
the
social
cost
function,
1
for
n
toast
1
for
network
operators.
The
time
doesn't,
allow
me
to
go
more
into
realities
are
justified,
but
apart
from
that,
we
are
also
interested
in
like
this.
We
can
characterize
the
social
optima,
but
we
are
also
interested
in
the
past
flow
pattern
that
result
from
the
selfish
behavior
of
end
hosts
of
the
Nash
equilibria.
But
of
course,
the
information
that
an
end
host
has
is
very
relevant
for
its
behavior.
W
So
we
need
to
have
a
notion
of
the
information
at
an
end
host
has
and
one
classic
way
to
formalize.
The
information
is
latency.
Only
information
and
host
knows
all
the
posts,
all
the
cost
of
the
paths
to
a
destination.
For
example,
here
the
end
host
Yvonne
has
a
demand
of
one
towards
and
roasty.
It
has
two
available
paths
and
posed.
W
It
knows
the
cost
of
both
of
these
paths
and
in
this
network
it
turns
out
the
cost
of
both
paths
are
equal
and
if
we
have
a
situation
like
that,
the
Antos
will
actually
have
no
reason
to
change
its
traffic
allocation.
So
this
is
what
we
mean
by
an
equilibrium,
but
this
iquilibrium
here
is
dependent
on
the
assumption
of
latency
own
information.
W
So
when
we
have
a
different
information
assumption
and
we
will
get
a
different
equilibrium
and,
for
example,
this
is
a
the
assumption
of
perfect
information
when
an
host
does
not
only
know
the
cost
of
all
the
paths,
but
also
put
the
link
cost
function
so
how
they
link
reacts
to
latency
and
which
is
linear
and
constant
here
and
also
the
background
traffic.
So
the
traffic
not
originating
from
itself,
which
is
one
here
on
both
the
links
and
with
this
knowledge
and
end
hoes,
can
set
up
such
a
selfish
cost
function.
W
It
can
minimize
the
selfish
cost
function
when
at
this
optimal
allocation
is
reached.
An
end
host
will
have
no
reason
to
change
its
traffic
allocation,
because
all
the
other
traffic
and
games
will
mean
a
higher
cost.
So
this
is
also
an
equilibrium,
but
it's
a
it's
a
different
equilibrium
you've
seen
before,
because
the
construction
is
different.
So
what
we
see
here
is
that
we
can
take
in
different
information
assumptions.
W
We
can
compute
different
iquilibrium
from
that
and
from
this
iquilibrium
compute
different
prices,
anarchy,
and
when
it
compared
this
price
of
Anarchy,
we
get
such
a
difference,
a
delta
which
is
which
captures
the
fact
that
information
has,
and
with
this
framework
we
can
it
gained
in
a
number
of
interesting
results.
For
example,
we
consider
the
angles
optimum
and
the
network
operator
ohm
can
be
quite
different
and
we
can
bounce
the
price
of
energy.
W
Above,
given
certain
assumptions
on
the
latency
functions,
we
can
prove
that
additional
inflation
can
be
beneficial
to
network
performance,
but
that
it
can
actually
harmful.
So
it
may
be
bad
to
provide
more
information,
okay,
okay
and
as
the
last
thing,
we
also
see
that
additional
information
becomes
irrelevant
with
the
scale
of
the
network,
so,
for
example,
Internet.
It
might
not
make
such
a
big
difference
where
we
have
the
latency.
Only
information
of
perfect
information
that
we
are
seeing
so
with
this
I'm.
At
the
end
of
my
talk.
B
Don't
have
time
for
questions
but
I'm
the
chair,
so
I
get
to
ask
a
question
so
I'm
gonna
do
two.
So
first
of
all,
this
is
really
interesting
to
give
a
little
bit
more
of
a
formalism
for
I.
Forget
the
numbers
of
the
questions,
but
there's
two
questions
that
stalks
about
like
with
respect
to
interest,
and
you
know
how
you
know:
oh
no,
it
was
purchased
ability
or
it
like,
sir,
exactly
this
is
one
of
the
open
questions
in
the
in
the
draft
that
we're
considering
here.