►
From YouTube: IETF101-PANRG-20180320-1330
Description
PANRG meeting session at IETF101
2018/03/20 1330
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
C
C
D
C
A
A
A
So
I
think
yeah,
which
does
not
fit
very
well
on
the
screen.
It's
updated
version
actually
do
not
know.
What's
the
difference,
but
anyway
yeah,
please
read
it
or
check
it
out
the
ATO
website.
We
have
an
agenda
yeah,
it's
actually
up-to-date
of
gender
and
gender,
great,
quite
busy
agenda
actually,
and
we
have
two
documents
on
the
which
we'll
be
discussing
today.
It's
kind
of
twice
more
than
the
head/neck
had
last
time
such
a
bit
progress
and
okay,
so
and
now
I
think
we
can
start
with
the
first
presentation,
then
I
own
zero.
A
B
So
yeah
so
yeah
just
come
to
the
mic
and
give
the
real
quick
version
of
your
heart.
Roc
talking.
Okay,.
E
So,
basically
we're
trying
to
get
going
discussion
on
the
idea
of
encrypted
protocols
like
quick
running
over
satellite,
where
you
can't
do
things
like
pep
anymore
to
accelerate
the
things.
So
you
need
solutions
that
can
give
you
the
high
performance
required
in
the
path
that
has
non-trivial
latency
like
a
geosynchronous
satellite,
we're
getting
ready
to
stand
up
a
mailing
list
to
get
the
discussion
going.
E
A
B
F
And
so
my
research
is
focused
on
the
scenario
when
we
are
at
an
end
device
and
have
multiple
paths
available,
for
example,
over
Wi-Fi,
our
over
cellular
and
usually
devices
just
use
Wi-Fi
as
a
default
thanks,
but
actually
Wi-Fi
is
not
always
the
best
option.
This
has
already
been
shown
in
several
studies
so
which
of
the
available
paths.
Do
we
actually
pick
from
the
add
device?
F
If
we
just
use
the
vanilla,
bsd
socket
API,
then,
basically
assume
we
have
a
bunch
of
connections
that
we
see
here
on
the
left
and
then
there's
the
two
paths
shown
on
the
right
at
the
end
device.
The
socket
API
cannot
distinguish
between
different
kinds
of
connection
I'm
going
to
come
to
what
exactly
that
means
in
a
minute.
So
it
does
not
have
additional
information
on
the
TCP
connections,
for
example,
and
then
also
it
has
no
information
about
the
paths
like
about
their
performance.
So
usually
what
happens?
F
Is
it
just
uses
a
default
path
that
is
based
on
some
system
policy?
What
I
mentioned
before
just
Wi-Fi
is
used
so
socket
intents,
is
additional
information
on
the
connections,
so
the
application
that
opens
several
connections
tells
it
tells
us
what,
at
once,
with
the
connection
what
it
knows
about
it
when
it
assumes
about
its
own
traffic
or
what
it
prefers.
This
is
not
quality
of
service.
This
is
just
some
hints
on
what
what
should
be
optimized,
for
so,
let's
say:
should
we
optimize
for
low
latency
or
rather
for
high
bandwidth
for
the
connections?
F
So
we
have
a
draft
geared
towards
the
tabs
working
group.
If
you're
interested
in
the
details
so
socket
intents
can,
for
example,
be
the
category
of
traffic.
So
is
this
going
to
be
just
a
query?
Is
this
going
to
be
about
transform
or
stream,
then
there's
the
size
of
the
content
to
be
received
so
think
about
like
an
OS
update?
Is
it
going
to
be
a
hundred
megabyte
that
we're
downloading?
F
This
is
information
that
could
be
useful
for
path,
selection,
right
and
then
also
what
bitrate
is
the
application
planning
to
send
round
about
which
we
could
know
for
some
video
streaming
applications,
the
timeliness
or
the
cost
preferences
that
the
application
specifies
on
its
connections.
It
can
also
specify
this
properties
per
message,
for
example,
but
I'm
going
to
focus
on
the
connection
for
simplicity.
So
now
assume
there
is
connection
1
and
the
application
has
that
has
told
us
that
it's
going
to
be
a
query
and
it's
only
going
to
be
tank
robot
so
now.
F
The
other
part
that
we
need
is
we
need
some
information
about
the
available
paths.
So,
in
our
prototype
we
have
some
property
estimates,
for
example
the
median
round-trip
time,
the
maximum
bitrate
or
the
Wi-Fi
utilization,
and
this
is
actually
the
part
that
I'm
going
to
be
focusing
on
in
this
talk.
So
f1
is
LTE.
It
has
a
high
quantity,
it
has
also
high
bandwidth.
F2
is
Wi-Fi,
it
has
a
low
RTT,
but
also
a
low
bandwidth,
and
now
our
path
selection
policy,
in
the
socket
intents
prototype-
can,
for
example,
just
be
ok.
F
F
It
will
be
much
shorter,
so
well,
I'll
just
use
Wi-Fi
right
and
then
the
second
connection
is
going
to
be
a
bike
transfer
and
it's
going
to
be
500
kilobyte
that
is
expected
and
specified
by
the
application
as
a
socket
intent
and
now
the
path
selection
policy,
if
it
wants
to
still
prefer
the
faff
of
the
shorter
completion
time
without
regarding
the
cost
preferences.
Of
course,
it
also
depends
on
the
system
policy
and
on
what
the
application
specifies.
But
let's
assume
we
still
use
the
same
power
selection
policy.
F
Then
over
LTE,
this
transfer
is
going
to
be
completed
sooner
so
it
would
use
LTE
or
maybe,
if
MP
TCP
is
available,
it
could
also
combine
both
paths
and
just
use
MP
TCP.
So
our
prototype
framework
is
yeah
works
the
following
way:
we
have
an
application,
it
specifies
the
intense
say
for
a
connection
and
then
the
socket
intent
library
that
sits
on
top
of
the
vanilla,
socket
API.
It
asks
the
multi
access
manager,
which
is
a
standalone
application,
a
daemon,
the
drones
and
lots
the
policy
as
a
module.
F
It
asks
which
path
should
be
used
for
this
new
connection,
and
now
the
multi
access
manager
makes
its
decision.
It
has
information
available
on
the
paths
and
it
gets
the
socket
intense
from
the
that
were
originally
specified
by
the
application,
and
now
it
says
ok
for
this
particular
communication.
Please
use
path,
1
and
use
local
address
a
and
now,
in
the
socket
intents
library,
we
can
bind
a
new
connection
to
address
a
and
then
connect,
and
so
now
we
are
using
the
path
that
has
been
specified
by
the
multi
access
manager
for
details.
F
F
We
focus
on
prefixes
because
with
ipv6
privacy,
extensions,
our
actual
address
might
change
over
time,
but
then
we
still
have
the
information
for
the
same
prefix
available.
Even
if
our
address
changes
and
so
yeah
the
multi
access
manager
is
a
demon
at
runs
and
it
collects
information
on
the
current
traffic
and
also
keeps
some
state
on
the
past
traffic
that
it
has
observed,
and
so
in
my
earlier
example,
I
simplified
it
as
a
path
RTT
of
100,
milliseconds
and
10
milliseconds,
but
actually
per
prefix.
F
The
RTT
might
be
different
and
I'm
going
to
go
into
detail
about
the
RTT
on
the
next
slide.
So
also
we
can
have
debate
the
bitrate
and
utilization
and
potentially
many
other
properties.
So
the
path
bitrate
is
calculated
per
interface
and
we
just
read
interface
counters
every
every
100
milliseconds
or
we
can
also
do
it
more
often
and
then
calculate
the
current
bitrate,
just
using
a
simple
formula
shown
so
over
time.
We
observe
that
so
suppose
there
is
a
large
transfer.
F
We
observe
some
maximum
bitrate
at
some
point
and
we
estimated
this
is
around
about
the
maximum
bitrate
that
we
are
currently
getting
for
transfer
over
this
interface.
So
this
assumes
that
the
bottleneck
on
a
path
is
within
the
first
few
hops,
because,
as
I
said
there
are,
we
assume
there
are
two
paths
available.
Of
course,
after
the
first
few
hops,
there
can
be
many
more
pass
through
the
actual
internet,
but
our
focus
is
the
access
network,
and
so
for
each
of
these
paths
we
know
per
interface
what
we
observed
roundabout
as
a
bit
rate.
F
F
So
this
is
our
abstraction
for
paths,
and
these
are
this
is
the
RTT
we
get
so
then
also
radio
properties
for
Wi-Fi
are
possible
to
get
on
linux.
So
we
can
get
to
receive
signal
strengths,
empty
modulation,
bit
rates
and
also
for
the
utilization.
There
is
the
QBs
as
information
element
in
beacon
frames
and
also
probe
response
frames,
and
we
can.
We
can
observe
that
from
our
multi
access
manager
and
then
know
about
what
percent
of
the
airtime
did.
F
So
currently
we
are
using
our
prototype
to
show
that
page
no
time
for
web
browsing
can
actually
be
reduced
with
this
approach,
so
web
browsing
is
basically
fetching
several
objects
over
several
either
TCP
connections,
or
it
could
also,
of
course,
be
like
quick
streams
and
as
a
series
of
objects
that
we
download
and
through
a
hack,
we
know
the
file
size
of
the
of
the
objects,
and
then
we
schedule
the
objects
on
the
different
interfaces.
So
what
I
showed
earlier?
F
The
large
objects
go
over
one
half
deep,
smaller
objects
go
over
a
different
path,
and
then
we
ask
can
we
actually
find
a
good
link,
selection
or
path
selection
policy?
In
this
case
that
helps
us
reduce
page
load
time
and
then
also
we
are
looking
for
more
path,
selection
properties,
policies,
I
meant
so
there's
one
policy
that
I
showed,
which
optimizes
for
Pedro
time
or
for
an
object
load.
F
Time
is
one
example,
but
then
they
can
also
be
policies
that
optimize
for
cost
or
maybe
for
energy
consumption
and
so
on,
and
then
also
we
want
to
find
out
more
about
the
path.
So
the
variation
of
the
SR
to
T's
can
be
interesting
over
time,
but
also
within
the
SRT
T's
that
we
get
from
the
color
because
say:
if
there's
ten
TCP
connections
on
the
same
prefix,
then
we
get
ten
as
RT
T's
and
we
calculate
the
mean
the
median,
but
we
can,
of
course
also.
F
We
also
do
calculate
the
variance
of
these
ten
TCP
connections
that
exist
in
parallel
and
also
we
can
observe
packet
loss
and
we
can
also
get
more
information
from
the
network.
Maybe
perhaps-
but
this
is
not,
except
for
QB
SS.
This
is
not
implemented
yet,
but
we
are
still
exploring
ideas.
So,
as
a
summary
socket
intends,
is
application
provided
hints
on
a
connection
or
on
a
message,
and
so
in
our
prototype
we
know
what
to
optimize
for
and
then
the
path
properties
are
gathered
locally,
just
on
the
end
device.
F
So
right
now
the
only
signaling
that
is
going
on
is
that
we
get
cubillas
as
frames
and
we
observe
their
QB
SS
medium
utilization
and
also
the
median
ass
outta
T
maximum
bitrate.
And
then
we
do
have
selection
with
an
automatic
access
manager
within
the
policy
and
as
I
said,
if
you're
interested
in
the
details,
you
can
look
at
our
draft
or
our
code
and
now
I'm,
looking
forward
to
questions
or
comments.
G
F
G
For
a
long
time,
for
example,
suppose
you
keep
law
as
Dean
Software,
Defined,
Networking
and
one
pass
you
would
allow
for
280
a
second
pass.
You
wouldn't
allow
for
80,
for
example,
and
essentially
there's
a
policy
issue.
That's
inside
networking
permission
and
you
plan
to
calexis
information
eventually
in
your
implementation,
or
maybe
that's
really,
probably
you
initially
designed
in
part
of
your
API
yeah.
F
We
don't
do
this
yet,
but
there's
a
lot
of
room
for
like
collecting
more
information
on
the
pass,
such
as
which
protocols
are
supported,
for
example,
would
be
also
every
need
interesting
question
right.
So
are
there
any
middle
boxes
on
that
one
path
or
on
the
other
path,
and
is
there
anything
blocked
and
so,
but
for
protocol
selection?
We
are
limited
by
the
socket
API
right.
G
Basically,
for
example,
isn't
even
told
can
become
your
complex,
okay
and
the
second
quest
will
be
following
I,
think
API
to
modifying
and
mostly
questions
about
your
intention
to
handle
the
past
property
collection
and,
for
example,
the
available
bandwidth
essentially
to
computer
finish
in
time
and
can
depend
on
the
dynamics
and,
for
example,
depends
on
the
TCP
and
his
view.
Reno,
which
is
bigger.
They
have
all.
Essentially
you
to
the
functions
and
the
band
is
sharing
depend
very
complexed
on
a
band.
G
The
sharing
is
that
we
need
to
solve
global
transition
from,
and
you
think
that
we
eventually
in
scope
or
essential
assumption,
would
it
be
okay
and
your
number
one?
Is
you
probably
can't
proximate
unit,
for
example
a
street
if
you're
flowe
small
you
not,
you
were
not
a
mobile
market,
your
product
approximate
by
a
SME,
some
cattle,
also
a
la
where
you
from
your
hand
or
something
dynamics
as
an
okay
water.
If
I
start
it's
a
very
large
flow
and
the
overall
bandwidth
allocation
whole
net
will
be
change
and
how
Britain
do
that?
F
G
G
H
Lee
Howard.
Thank
you.
This
is
really
interesting.
Good
work
question,
so
I
loved
when
you,
when
you
were
showing
the
round-trip
times
based
on
prefix
and,
of
course,
I,
always
love,
seeing
examples
in
ipv6
as
well
as
ipv4,
because,
of
course
they're
different
prefixes,
and
we
know
there
are
different
latencies
on
those
paths.
How
does
this
interact
with
happy
eyeballs?
Well,.
F
F
I
J
Hi
hi
Ben
Schneider,
and
you
see
quick
question
it.
It
seems
that
most
of
the
time,
the
connection
initiator
would
not
know
the
intent
that
the
application
has,
because
it
probably
is
dependent
on
what
the
contacted
server
wants
to
transmit.
It
seems
like
you,
probably
want
to
explore
something
in
the
direction
of
how
to
get
the
intent
over
from
the
other
side.
The
connection,
establishment
or
I
mean
vice
versa.
F
J
F
F
L
M
Think
I
need
it,
but
there
were
enough
to
get
to
the
room,
so
I'm
gonna
present
service,
aware
networking
using
SR
from
an
operator
viewpoint,
so
there
may
not
be
going
down
to
the
pits,
as
that,
my
curious
speaker,
but
there
you're
gonna,
go
see
our
challenges
and
where
we're
thinking
about
going
toward
using
that
map
and
that
model
for
a
Torres,
so
our
telco
challenge
is
I'm
going
to
go
really
fast.
The
problem
statement
is
what
happens
and
what
what's
the
view
from
our
site
is?
Well,
you
know
it.
Internet
is
growing.
M
So
it's
not
big
news.
Our
networks
is
really
static
and
some
of
our
network
devices
and
our
networks
still
don't
support
this
an
NP
so
that
you
are
much
our
network
is
all
we
have
long
migration
cycle.
So
that's
a
big
known
fact
from
every
telco.
We
have
hardware
becoming
obsolete
quicker.
So
if
there
was
a
big
TQM
issue
in
2014
that
blast
that
affected
a
lot
of
our
of
our
US
carriers
and
that's
the
basic
approach
of
well,
the
internet
is
growing.
The
second
thing
is
our
network,
we're
managing
complexity.
M
We
added
in
the
past
four
years
as
these
three
providers
got
joined
into
Bell,
so
it's
get
is
getting
even
bigger,
as
we
were
so
we're,
adding
different
level
of
networks.
We
have
and
we
have
as
a
network
no
end
to
a
traffic
engineering
you
so
ever
since
we
have
pockets
of
networks
connecting
them
together
doesn't
mean
we
have
an
end-to-end
view,
and
then
we
don't
have
any
end-to-end
OEM
for
troubleshooting,
so
that
becomes
integrated
becomes
an
operational
challenge
and
we
use
the
complain
to
the
complexity
of
being
able
to
offer
services
quicker.
M
So
our
first
response
was
well
liked.
Almost
every
telco
is,
let's
do
network
virtualization
and
transform
so
that
that's
an
easy
way
to
do,
but
transformed
our
network
to
to
integrate
the
core
with
our
network.
Our
DC's
to
leverage
virtualization
include
leverage
our
existing
MPLS
data
plane
because
we're
actually
good
at
MPLS
insight,
Val,
so
I
move
towards
a
vision
of
pure
ipv6
or
sr
v6
as
it
as
it
progresses
and
simplify
the
control
plane
so
flatten
our
network,
so
that
we
use
MPLS
everywhere
and
a
single
flat,
our
topology.
M
M
We
have
the
trouble
of
a
if
you
try
to
do
and
we're
transform
that
into
a
CEO
into
a
DC,
all
the
cost
of
changing
that
if
it
were
not
read
necessarily
the
revenue
generation
is
kind
of
a
challenge:
removing
old
boxes
to
get
enough
power.
It's
still
like
removing
a
DMS
for
us
takes
about
a
year.
We
have
192.
So
if
you
think
about
that
might
take
a
long
time
before
were
able
to
convert
all
of
that
plus
virtualizing.
Well,
it
seems
easy,
but
it's
not
that
easy
VNS
are
not
always
putting
nice.
M
Everybody
will
agree
with
that.
Virtualizing
core
functions
into
and
from
structure
like
OpenStack
is
again
not
that
trivial,
but
that
those
things
are
happening
and
it
takes
a
slow
painful
time
and
by
the
main
reason
is
by
the
time
we
finally
get
it
right.
They
an
industry
will
have
evolved
and
we
have
been
completely
obsolete
it
as
a
tour
as
well.
So
we
need
to
move
faster.
The
ends,
though
we
need
a
bigger
book,
so
the
trick
is
pushing
it
forward
even
further.
M
So
if
we
make
our
network
looks
like
it
looked
like
a
big
like
a
big
network
policy
or
I
mean
good
at
pushing
segments
or
thing
even
further,
so
that
the
network
is
really
flattened
as
much
as
we
can.
So,
let's
push
it
even
more,
as
we
can
push
SR
to
the
house
and
DNS
and
all
those
things
so
make
a
leapfrog
approach
to
this,
then
we
can
start
leveraging
mechanism
we're
building
with
SR,
which
are
srte
under
Man
X
of
our
article
technologies
in
the
end
we're
getting
we're
pushing
the
limits.
M
So
closer
to
the
edge,
then
we're
Greek
getting
closer
to
the
application.
Our
level
is
being
able
to
offer
a
network
service
which
is
bound
or
is
able
to
support
the
application
so,
but
why?
Why
do
I
make
this
statement?
Is
we
want
to
make
our
network
stateless
as
much?
We
remove
states
from
the
underlying
network
and
push
it
to
the
edges.
It
removes
a
bunch
of
encapsulation
decapsulation
middle
boxes,
which
we
would
like
to
remove
and
in
the
end,
will
probably
be
removed
because
virtualization
technologies
are
evolving
as
well.
M
We
want
to
distribute
function,
processing
getting
virtualizing
a
physical
box
at
dress,
100
Gig
of
line
right
through
put
into
a
virtual
functions
if
somebody's
able
to
do
it
really
easily
without
any
problems.
I
would
like
him
to
talk
to
me
because
that's
not
a
new
trivial
problem
and
at
the
same
time,
we
figure
out
that
if
you
push
this
to
the
edges,
we're
doing
smaller
functions
really
close
to
the
end
user
is
really
easier.
Abstracting
complexity
is
for
us.
A
service
chain
is
not
a
service
change.
M
The
network
policy
services
are
part
of
our
network.
Traffic
engineering
mechanism.
Are
part
of
what
we
will
do
with
that
reputation?
What
we
do
with
low
latency
links
versus
standard
links,
so
a
chain
is
not
just
one
firewall
connecting
to
our
application
at
the
end-to-end
view
and
that's
what
we
call
it
for
us
as
a
network
policy
being
able
to
apply
functions
where
they
need
to
be
closer
to
the
application
where
it
makes
much
more
sense.
M
So
for
us
never
policies,
our
service
functions,
T,
behaviors
and
I
put
it
as
it's
SR
v6
and
functions
I'm
going
to
talk
about
it
later.
So
for
us
idea
of
path,
awareness's
in
a
presentation,
I
did
not
under
P
for
submit
I
talked
to
it
about
being
able
to
do
the
network
as
an
ASIC
so
doing
parsing
at
the
edges.
As
much
as
we
can
to
make
classification
on
that
primitive,
you
have
trying
network
policies
which
is
anywhere
in
the
network.
You
can
distribute
the
processing
where
it
makes
sense
and
based
on
application
requirements.
M
So
we
don't
expect
we
need
to
have
a
better
way
of
communicating
the
application
or
the
pre-application
needs,
so
they
can
build
those
policies
for
us.
It
becomes
programming
at
all
layers
programming
the
set
functions
that
the
word
of
the
function
should
be
and/or
use,
srte
to
be
able
to
create
that
end-to-end
Network
function,
which
is
the
net
network
and
to
add
policy.
The
demo
we
did
was
with
SRB
sick,
but
could
be
done
as
well
for
us,
our
Abdullah's.
M
So
one
way
to
expect
this
network
behaviors
is
we
don't
necessarily
need
special
functions
to
do
something
so
the
example
I'm
bruising
right
now
is
one
of
the
concepts
we
have
with
sr
v6
and
then
yes
RHS.
We
can
encode
a
lot
of
function
into
this,
so
we
can
say,
for
example,
instead
of
meta
data
or
a
firewall
supposed
to
be,
can
you
use
sit
segments
and
say
here's
a
function
and
the
argument
is
the
policy
should
be
using.
So
there
was
mechanism
we
can
use
to
simplify
another
messaging.
M
We
send
it
to
the
network,
but
the
trick
is
always
well
it's
cool.
You
can
do
a
lot
of
those
things,
but
how
we
can
program
those,
so
we
implement
SR
on
the
host
SR,
the
house.
Again,
you
have
a
bit
bit
more
flexibility
on
what
you
can
do,
so
we
have
a
lot
of
implementations
right
now.
We've
done
SRH
in
linux,
kernel
with
RS
RPLS,
NSO,
v,
6
and
EBP,
and
for
those
who
knew
we
did
the
current
limitation
of
SR
v6
and
p4.
M
So
we
can
implement
that
in
both
Isaac
and
FPGA,
which
really
is
interesting
to
us,
and
but
there
still
need
to
do
some
work.
So,
for
example,
it's
cool
I
have
a
data
plane,
it
works
with
SR
MPLS
and
SR
v6.
Well,
I'll
open
stack,
doesn't
understand
anything
of
this.
He
sees
a
EE
so
that
the
construct
to
make
it
work
in
an
orchestration
platform
is
not
the
same.
We
also
need
n2n
orchestration.
So
right
now
everything
we
do
in
Arcis,
tration,
like
we
are
involved
in
on
that
as
well,
is
based
on
other
primitives.
M
To
do
then
doing
network
policies
based
on
SR.
So
we
need
to
include
that
into
our
and
to
our
entire
equation.
So
now
we
know
how
to
program
SR
to
the
house.
Now
we
now
ought
to
do
a
to
build
a
network
policy
inside
the
network,
but
what's
missing
well,
we
have
challenges
on
the
path
awareness
right
now,
when
our
big
focus
we
have
is
we're
getting
good
at
explaining
a
path
to
somebody.
M
We
can
tell
using
pce
with
the
old
time
we'll
use
bgp
activities
with
the
providers
or
PT
committees
between
providers
talk
to
each
other.
We
can
send
an
information
to
private
to
pvd's
but
trouble
as
that's
good.
So
we
know
how
to
tell
somebody
what
to
do
we
don't.
We
have
not
really
that
much
awareness
of
receiving.
You
ask
the
question,
so
somebody
telling
us
what
they
need
and
right
now
that
becomes
swivel-chair
emails
or
big
web
portal
with
a
bunch
of
templates
telling
us
what
what
should
be
done.
M
So
the
question
is-
and
the
second
point
I'm
talking
about
this-
there's
actually
work
done
in
tip
the
telecom
end
for
project
four
dollars
for
those
who
are
aware
where
they
were
talking
about
out
to
exchange
information
between
content
providers
and
service
providers.
So,
instead
of
having
to
build
a
bunch
of
cash
engines
everywhere
and
oversubscribed
network,
can
we
leverage
some
mechanisms?
In
that
case
it
did
out
the
use
Alto
as
a
mechanism
to
be
able
to
exchange
information,
so
what
your
provider
needs?
M
What
is
the
ISPs
able
to
give
and
based
on
that,
you
build
a
path
that
could
be
done.
That
was
interesting
work,
but
now,
how
can
we
yeah
ask
for
a
policy
and
that's
I
think
you
can
remove
the
the
sub-bullets
or
the
first
point,
but
right
now,
what
we
need
is
a
simpler
way
of
to
express
those
network
paths.
M
We
request:
how
can
an
application
owner
or,
if
you
think
about
this,
if
we're
pushing
really
closer
to
the
application,
how
can
an
administrator
of
our
an
application
developer
make
a
network
request
of
based
on
his
application
requirements
so
that
isn't
just
it?
Doesn't
it
end
up
being
an
indeed
to
understand
our
MPLS
VPN
works,
our
SRT
here
works
and
that
the
trouble
is
right
now
so
then
we
have
a
gap
between
what
an
application
developer,
pure
application
developer,
does
versus
what
the
network
is
able
to
given.
M
So
there
has
been
proposed
IDs
and
that
that
frame,
for
example,
it
was
one
about
using
sign
of
a
DNS
proxy
and
I've
put
the
reference
to
the
paper
there,
but
I
think
that
for
us
as
a
challenge
right
now,
if
you
want
to
move
forward
into
our
level,
is
we
know
how
to
program
the
network?
We
know
where
we're
going
with
a
single
simplified
data
plane
the
trick
is
we
need
to
find
ways
to
make
it
simpler
for
our
external
partners,
external
users,
even
customers
are
applications
to
ask
the
request
to
our
network.
B
Hi
Brian
Trammell
for
these
perks
is
not
the
chair
of
ban
PRT.
So
go
back
yeah!
Well,
no,
not
not
that
far,
so
the
data
plane
is
pretty
clear
right
like
so.
This
is
all
essentially
done
work.
It's
standardized
the
point
that
you
can
buy
boxes
that
do
it
and
the
big
question
that
I
had
and
sort
of
what
you
know.
B
M
M
B
Sorry,
that's
a
that's
a
terminology,
question
right!
So
sorry,
so
when
I
say
control,
plane,
I
need
something
different,
so
I'll
use
different
words,
a
way
to
specify
so
a
way
to
act.
So
in
the
questions
document
for
for
a
energy
this
is
we
refer
to
this
is
how
do
you
get
the
path
properties
down
to
the
edge
great
you.
M
Think
this
down
to
the
edge
for
us.
Yes,
all
right,
we're
able
to
do
sr
did
have
been
to
the
closest
to
the
edge
as
we
can
writing
a
path
property
there.
It's
quite
easy,
my
challenge:
we
can
do
it
different
ways.
You
can
do
it
with
management
plane,
let
be
signaling,
it
would
be
j'tia
there's
other
ways.
My
trouble
is:
how
can
I
know
what
the
application
wants,
or
they
our
customer
wants
to
create
that
policy
right
now
will
presume
or
there
will
be
exchanges
with
emails
discussions,
afraid.
M
In
a
room
deciding
of
trying
on
a
board
where
I
think
we
need
to
evolve
is
how
can
that
be?
Can
I
we're
trying
to
automate
everything
so
great
and
I
ought
to
make
that
that
your
is
the
other
way
around
I
can
program
a
path
if
I
have
a
unified
data
plane
I
have,
but
my
trouble
is
I
won't
get
a
way
around.
How
can
I
can
somebody
talk
to
me
in
a
way
that
is
not
it's
not
China.
Sorry,
there's
change
people
in
there,
but
in
the
room,
but
it's
not
Chinese
to
everybody.
N
M
It's
always
to
me
so
to
me,
I
to
be
service.
Aware,
is
I,
have
a
service
I.
Can
it
be
a
service
over
an
effort
policy,
but
then
it
doesn't
mean
that
my
network
policies
applied
to
the
application.
What
it
needs
so
I
can
build
a
bunch
of
services.
Nobody
wants
them
because
I
don't
know
what
they
want.
So
I
want
the
other
way
around.
So
I
need
both
ways
and
right
now
it's
one-way
signaling.
So
I
am
free.
There's.
K
B
B
K
A
D
O
That
better,
so
what
we're
trying
to
do
here
is
this
is
a
method
for
applications
to
signal
the
network.
I
think
it's
kind
of
kind
of
came
up
in
the
last
presentation
and
I
think
this
has
been
a
general
idea
that
people
want
it
and
there's
kind
of
a
long
list
of
laundry
items.
We
want
this
to
be
extensible
expressible
have
an
application
signal.
The
types
of
service
at
once,
but
also
be
able
to
do
this,
such
that
a
service
wants
a
specific
or
an
application,
wants
a
specific
type
of
service.
O
Then
it
should
be
granted
that
service
and
maybe
somebody
else,
shouldn't
be
able
to
kind
of
steal
that
service
or
use
that
same
parameter.
So
this
shows
a
long
list
of
laundry
items
efficient
dynamic.
We
would
like
to
reduce
the
amount
of
dpi
in
the
network
in
order
to
do
stuff
like
this
and
also
not
to
enclose
the
internals
of
the
network,
so
in
some
sense
these
requests
for
service
should
be
somewhat
extracted
and
work
with
any
transport
protocol.
So
today
we
know
about
diffserv.
O
This
is
a
wonderful
mechanism,
kind
of
limited
in
terms
of
how
much
information
it
can
express
and
also
the
controls
it's
hard
to
control
applications
from
just
arbitrarily
setting
it.
Dpi
has
been
used,
that's
been
yet
being
a
little
obsolete
it
because
of
TLS,
so
it's
become
harder
and
harder
for
networks.
You
look
inside
the
pack
to
figure
out
if
it's
cat,
video
or
not,
maybe
what
have
you
spotted
plus
for
some
good
efforts
done
previously
these
right,
the
idea
was
to
do
sort
of
signaling
over
UDP.
O
So
some
of
the
ideas
here
actually
borrowed
those
initiatives.
There
are
a
number
of
ad
hoc
mechanisms.
One
of
the
interesting
ones
was
a
proposal
in
TCP
to
add
a
TCP
option
to
do
some
quality
of
service
and
then
applications
could
set
this
and
network
with
somehow
interpret
TCP
options
and
there's
a
couple
of
other
in
band
signaling,
the
one
that
I
have.
There
is
a
little
more
generic
over
usage
of
extension.
O
O
It
gives
you
admission
to
the
network,
so
it
says
you're
allowed
to
enter
the
network
and
it
gives
you
kind
of
the
services
that
will
be
applied
to
the
packet,
so
the
idea
is,
every
packet
gets
a
ticket
and
when
the
packet
enters
and
network
and
I
get
to
get
to
the
meaning
of
entering
network
in
a
minute
we
enter
as
a
network.
The
services
are
apply
on
the
application.
Admissible
of
the
packet
is
checked.
So
when
you
have
tickets,
you
need
ticket
agents.
O
Ticket
agents
are
going
to
be
nodes
in
the
network
that
provide
tickets
to
the
application.
So
basically
the
idea
is
the
application
sends
a
request
to
a
ticket
agent
and
the
request
will
be
somewhat
expressible.
So
this
kind
of
a
one-time
thing,
so
maybe
a
little
more
extracted
and
just
like
ban
what
bandwidth
or
priority
you
may
have
other
interesting
characteristics.
For
instance,
you
may
describe
video
characteristics
in
terms
of
frame
per
second
or
bit
right,
so
the
ticket
agent
once
it
gets
this,
then
it
can
decide
whether
or
not
to
issue
a
ticket.
O
O
In
what
case
we
have
some
so
the
provisions
for
that,
but
once
the
ticket
is
accept
that,
then
the
ticket
itself
indicate
to
the
network,
the
services
that
should
be
provided,
and
the
network
then
can
convert
that
into
the
network
mechanisms
to
implement
the
services.
For
instance,
you
may
go
into
network
slices
could
be
encapsulated
for
segment.
Routing
us
to
stuff
previously
nfe
what
happened
so
one
important
aspect
of
realm
to
tickets
is
that
they
need
to
be
roundtrip
so
when
the
application
sets
the
ticket
and
the
forward
it
forward
path.
O
So
it's
sending
packets
into
the
network,
that's
fairly
simple,
so
the
application
just
sets
the
ticket
it's
sent
into
the
network.
However,
in
most
applications,
packets
will
come
back
for
that
that
particular
flow
and
the
intent
is
that
the
application
you
want
services
in
both
directions.
So
the
question
is
how
to
do
that
and
the
answer
is
we
will
reflect
the
tickets
at
the
pier
and
have
them
come
back
so
there's
basically
two
of
variants
of
the
same
second
one
is
ticket
sent
in
the
forward
direction,
which
means
apply.
O
O
So
tickets,
like
any
other
tickets,
they
need
to
be
secured,
so
there
non-transferable.
So
if
a
network
issues
a
ticket
for
a
particular
flow,
for
instance,
and
an
application
wants
only
that
flow-
should
be
able
to
use
that
ticket.
So
there
will
be
some
security
and
signing
of
tickets
for
individual
flows,
for
instance,
they
have
an
expiration
time,
so
I
should
mention
that
tickets
are
essentially
stateless.
O
So
when
the
athlete,
when
the
network
is
presented
with
a
ticket,
it
validates
the
ticket
kind
of
as
a
standalone
thing,
does
not
necessarily
create
state
a
priori
to
process
the
tickets
and
the
other
important
aspect
is
the
tickets
are
non-interoperable
by
anyone
outside
the
network.
So
one
thing
we
we
can
consider
is
that
the
tickets
themselves
may
contain
information
that
could
be
exploited.
O
I
mean
the
very
fact
that
we're
saying
this
is
video
at
certain
rate,
that
in
itself
may
be
sensitive
information
and
the
other
reason
why
we
don't
want
kind
of
tickets
to
be
interpreted
there.
There's
no
concept
here
of
having
global
parameters
for
the
network,
so
the
local
network
may
have
may
implement
a
service
parameter
that
did
not
necessarily
have
to
have
global
meaning
that
could
have
meaning
to
itself
so
no
concept
here
of
the
global
ticket
system.
So
this
is
a
picture
of
what
the
ticket
flow
might
look
like.
O
So
on
the
Left
we
have
the
host
first
thing:
the
host
does
say
it's
creating
a
connection
request,
a
ticket
and
in
that
request,
as
I
mentioned,
it
describes
this
types
of
services
at
once.
Ticket
agent
replies-
and
this
is
a
ticket.
It's
kind
of
pipes
that
have
bits
that
the
host
world
attaching
to
packets
and
I'll
get
to
the
mechanism
for
attaching
in
a
second.
So
the
application
then
attaches
the
tickets
to
its
packets
for
the
flow
each
packet
contains
two
ticket
packets
go
into
the
network
and
a
maybe
first
hop.
O
Router
then
interprets
that
ticket
reads
a
ticket
and
then
puts
the
packet
into
whatever
network
services
are
required.
Then
the
package
reverses
the
providers.
Network
in
this
case
leaves
the
internet
so
once
it
leaves
the
Internet,
the
ticket
is
still
attached
to
the
packet.
We
actually
flow
through
the
internet
through
the
remote
provider
network
to
the
remote
peer
now
during
that
part
of
the
path
the
ticket
is
actually
not
interpreted,
so
it
just
carried
with
a
packet
at
the
peer
host
ticket
is
then
reflected
on
packets
to
being
sent
back.
O
So
if
this
is
a
request
for
video,
then
the
actual
video
stream
coming
back
will
have
the
ticket
attached
and
that's
probably
where
the
parameters
are
most
interesting.
So
again,
the
reflected
ticket
is
not
interesting
to
the
local
provider
of
the
pure
coast,
nor
the
Internet.
Once
it
comes
into
the
local
network
through
another
device
that
device
will
again
interpret,
they
were
now
interpret
the
reflected
ticket
and
assign
the
service
parameters
within
the
local
network
again
in
the
downstream
path
packet
then
goes
to
the
host
post
receives
it.
O
Host
can
also
look
at
the
reflected
ticket
to
make
sure
that
it
actually
is
valid
and
one
that
it
had
sent
in
a
packet.
So
that's
kind
of
the
complete
lifecycle
of
one
packet
here
is
kind
of
an
example
of
what
a
video
chat
might
look
like,
so
the
application
in
this
case
a
video
application-
may
issue
a
fast
ticket
request.
In
this
case.
O
It's
a
video
chat,
30
frames
per
second
with
a
minimal
delay
1080p,
so
maybe
high
quality,
interactive
video
fast
decides
whether
or
not
it
can
service
that
and
will
send
back
the
ticket
to
the
application,
and
then
it
kind
of
goes
through
the
path
that
I
described.
So
the
application
attaches
the
ticket
it
goes
through.
The
network,
the
ticket
is
mapped
into
services,
goes
through
the
internet
and
reflected
and
what
happened.
The.
P
O
So,
actually,
that's
the
next
flight
yeah,
so
yes,
tickets
can
be
used
by
directionally,
and
in
this
sense
it's
can
each
use
them.
However,
the
uses
are
independent,
so
the
ticket
really
applies
to
the
network
that
they
are
issued
in.
So
in
this
model,
you
can
think
of
the
network
as
kind
of
a
dumbbell,
so
there's
provider
network,
internet
provider,
network
tickets
are
applicable
and
the
providers
networks
we're
assuming
that
tickets
are
not
of
interest
to
the
core
network
that
packets
are
mostly
just
forwarded.
So
in
this
case
each
side
can
do
the
same
thing.
O
They
would
end
up
having
two
tickets
per
packet,
one,
maybe
the
local
ticket,
which
would
not
be
reflected
one,
would
be
the
reflected
ticket
and
the
way
to
way
to
tell
this.
So
when
packet
comes
into
the
network,
you
do
need
to
determine
if
the
ticket
is
for
you,
then
it's
a
matter
of
looking
at
the
addresses.
If
the
destination
address
is
local
and
it's
a
reflective
ticket,
that
means
that
that's
a
ticket
for
the
local
local
network.
O
So
some
specifics
of
tickets,
we
plan
to
encode
these
and
ipv6
destination
options.
Technically
speaking,
these
kind
of
by
definition
should
be
hop-by-hop
options,
but
I
think
the
legacy
of
hop-by-hop
options
and
kind
of
the
some
of
the
requirements
there's
a
greater,
much
greater
likelihood,
they'll
be
dropped
and
that
might
be
unsolvable.
O
Q
Q
R
B
J
O
J
O
J
O
J
O
You
get
tickets
from
your
local
network,
yeah,
okay,
so
I
wish
to
do
something
more
elaborate.
Then
you
could
do
that,
but
then
your
application
has
to
be
contacting
more
than
one
ticket
agent
right.
I
don't
have
to
contact
other
networks,
so
so
the
other
alternative
here
is:
if
you
want
to
schedule
a
whole
path,
then
you
can
do
that
from
from
the
ticket
itself.
P
O
O
O
S
S
O
S
O
S
O
O
O
Okay,
so
it's
a
world
code
ticket
and
hop
hopper
destination
options.
I
guess
that's
to
be
done,
though
they
have
a
specific
network
encoding.
They
need
some
sort
of
encryption
because
they're
likely
we
want
to
avoid
having
them
exposed
to
the
outside
network
and
they
do
need
an
expiration
time.
So
again
they
are
aren't
stateful,
so
we're
not
looking
at
TCP
flow
State,
for
instance,
to
track
tickets,
so
the
option
format.
This
is
your
typical
option.
O
There
are
like
said
that
some
tickets
are
don't
reflect
it
so
are
not
reflected.
There's
also
an
option
to
say
you
can't
reflect
it
and
a
ticket
might
look
something
like
this.
So
there's
an
expiration
time
verification
data.
So,
if
we're
doing
HVAC,
we
would
need
some
data
there
and
then
the
important
part
is
what
is
the
information
that
indicates
the
service,
and
this
is
where
it
becomes
interesting,
because
we
obviously
want
to
keep
this
as
small
as
possible,
but
also
fairly
rich,
so
different
ways.
You
could
do
that
you
could
have.
O
You
could
have
tlvs
if
you
wanted
to
would
that
be
kind
of
expensive,
but
we
could
also
put
this
into
some
sort
of
index
into
some
number
of
common
profiles.
You
could
have
a
number
of
flags.
The
question
in
how
big
tickets
are
I
would
hope
that
we
can
get
these
down
to
about
16
bytes,
maybe
less.
That
would
kind
of
be
my
goals
so.
O
There
is
an
obviously
pretty
rich
control
plane
here.
The
applications
speak
to
a
ticket
agent.
This
is
most
likely
through
some
sort
of
library
arranged
by
the
OS
and
the
ticket
request
at
least
contain
the
source
and
destination
of
the
communication,
possibly
the
ports
and
then,
as
I
said,
has
a
some
level
of
desired
services,
and
this
is
expressed
in
some
really
rich
format.
Rest
XML,
what-have-you
tickets
reply
should
be
pretty
simple.
O
It
needs
to
be
the
expiration
time
so
that
the
location
knows
when
to
stop
using
the
ticket
and
then
the
actual
ticket
itself
and
our
ticket
itself
and
the
application
takes
and
arranges
to
have
attached
inside
the
option
for
TCP.
That's
actually
a
pretty
simple
thing:
it's
just
a
simple
socket
call
saying
here:
it's
a
destination
option
or
hop-by-hop
option.
Please
add
this
to
all
the
packets
I
should
mention
that
the
idea
of
tickets
is
once
you
use
it.
O
So
implementation
wise.
There
is
some
work
to
be
done,
so
the
OS
we
need
to
enable
some
setting
of
tickets
for
applications.
This
is
mostly
done
in
sockets
API.
So
it's
not
too
much
of
an
issue.
There
may
be
some
priority
or
permissions
things
that
we
need
to
kind
of
allow,
but
we
do
need
the
library
that
allows
applications
to
talk
to
the
ticket
manager.
Applications
themselves
presumably
would
use
this
library,
and
the
API
would
also
allow
it
to
be
easy
to
attach
the
tickets
server
reflection.
O
If
we
do
that
on
TCP,
it's
actually
pretty
simple,
because
we
can
do
this
completely
within
the
stack.
The
pure
application
doesn't
even
have
to
know
that
it's
reflecting
tickets,
so
that's
kind
of
nice,
can
election
less
protocols
like
quick,
quick
servers.
We
actually
use
the
API
to
reflect
tickets
network
support,
so
tickets
can
be
the
network
process.
Is
one
thing:
that's
probably
pretty
clear.
Is
we
if
we're
doing
encryption,
we
can't
decrypt
on
every
ticket,
so
we
could
establish
a
cache
so
the
first
time
a
ticket
comes
in,
establish
a
cache
entry.
O
O
So
there
are
some
different
types
of
drops.
We
may
see
destination,
reachable
on
the
forward
path
and
we're
getting
replies,
but
the
tickets
not
being
reflected.
That
may
mean
that
reflections
not
enabled
so
that's
half
the
path
might
be
working
and
we
can
actually
kind
of
maybe
create
soft
states,
at
least
on
the
forward
path
for
the
reverse
path
you
would
create,
maybe
hopefully
use
that
stall
soft
state.
If
you
get
a
symmetric
path,
if
packets
are
dropped
in
both
directions,
that's
a
little
little
less
pleasant.
Obviously
we
can't
have
communication
stops.
O
So
in
this
case
we
need
to
back
off
from
using
extension
headers.
In
that
case,
it's
less
likely.
We
could
use
the
tickets.
Maybe
we
can.
You
have
to
back
off
to
some
sort
of
stateful
stateful
mapping
kind
of
unpleasant,
but
hope
is
that
over
time
the
number
of
hosts
or
networks
dropping
extension,
headers
goes
down.
Also,
I
think
it's
obvious
that
if
your
local
network
is
supporting
tickets,
then
presumably
they're
supporting
extension
headers,
at
least
your
local
network
shouldn't
be
dropping
them
and
neither
should
be
the
peer
for
peer
is
actually
doing
reflection.
O
O
T
Alan
Chadwick
I
had
a
question
about
what
is
there
any
way
that
you
imagine
either
having
the
network
attached,
something
to
say
that
actually
I
obeyed
the
ticket
or
follow
the
policy
that
stick?
It
implies
or,
conversely,
some
way
for
the
ticket
agent
to
come
back
later
and
say
hey
by
the
way.
So
it's
been
a
change
in
the
network,
actually
that
tickets
no
longer
valid
to
expire
it
early.
So.
O
That's
that's
an
interesting
idea.
We
haven't
really
specified
a
lot
of
the
characteristics
of
tickets
in
terms
of
does
a
ticket
actually
guarantee
you
something
or
is
it?
Is
it
best
effort
and
I
think
that
for
the
mechanism,
what
I
think
the
implication
there
is?
It's
probably
true
that
you
could
do
that.
O
In
that
case
it
makes
the
API
to
the
application
and
a
little
more
interesting,
possibly
because
now
you
have
to
actually
receive
messages,
asynchronous
messages,
I,
don't
see
any
reason
why
you
couldn't
you
couldn't
do
that
also
brings
up
the
question:
how
do
you
dynamic
with
this
process
be,
if
and
networks,
constantly
changing
or
the
application?
That's
changing?
Do
you
want
to
be
able
to
change
tickets?
Every
five
seconds,
I
mean
it's
all
possible
and
obviously
the
more
interaction
you
have
with
a
network
trying
to
fine-tune
this.
O
T
R
G
Yeah
we
should
yeah
and
a
very
clear
freaking
question.
So
looking
at
your
like
servers
or
doctor
state,
essentially
I,
guess
that
your
impacts
or
profile
impacts
only
the
services
not
for
exam,
imagine
condition
I
always
imagined.
Would
it
be
like
a
matching
condition
of
a
packet
and
then
type
of
service
piece
I
mean
are
somehow
for
the
server
or
for
the
doctor
State,
you
don't
keep
track
on
matching
conditions.
G
So
if
you
don't,
what
do
you
prevent
from
other
people
overheard
about
the
ticket
and
we
you
essentially
how
to
prevent,
for
example,
Bundy
in
picking
packets
and
a
ticket
someone
else
overheard
about
it?
I
can
also
use
it.
But
if
you
do
a
bonding
between
the
matching
and
a
ticket
and
the
services,
then
why
do
we
even
need
a
ticket?
Just
because
a
server
already
do
classification,
you
the
open
flows,
and
then
why
do
we
even
have
tickets?
That
well
because.
O
That
would
be
stateful,
so,
for
instance,
if
I
wanted
to
do
if
I
wanted
to
attach
a
ticket
to
a
particular
for
trouble,
because
it's
a
particular
connection
right,
then
the
ticket
itself
could
indicate
the
for
couple
to
match
it
against.
So,
in
some
sense
the
ticket
becomes
signed
based
on
the
for
trouble.
So
the
thing
I'm
trying
to
avoid
here
is
to
create
a
whole
bunch
of
state
in
the
network
for
every
flow,
and
this
is
this
is
really
one
of
my
one
of
the
things
we're
trying
to
avoid.
O
G
O
Think
of
it
this
way.
So
if
we
want
to
say
this
tickets
only
valid
for
this
for
travel
sure,
then
we
just
take
a
hash
of
that
for
couple
and
whenever
the
packet
comes
down
and
hash
over
the
addresses
imports,
if
it
matches,
then
we
know
the
tickets
ballot
after
some
sort
of
decryption.
So
again,
all
of
that
could
be
encoded
fairly
simple
in
a
map
cat
or
in
a
cache.
So
we
don't
have
to
go
through
the
full
check
process
each
time
sure
so.
B
N
Video
for
telecom
first,
a
note
I,
would
not
be
optimistic
about
getting
support
for
long
header
chains
anyway.
For
for
any
for
any
reason,
okay,
then
I
wonder
it
looks
to
me
I'm
an
intern
or
made
inter
domain
routing.
Guy
looks
to
me,
like
you,
are
essentially
taking
care
of
stuff
that
happens
in
the
originators
domain.
N
O
Actually,
that
does
bring
up
a
good
good
principle
here.
My
preference
is
the
only
entity
the
application
talks
to
is
the
local
network,
because
in
some
sense
that's
the
only
entity
it
trusts
and
only
only
because
it
has
to
trust
and
what
I
really
want
is
I.
Don't
want
any
information
about
the
path
other
than
I
know
that
that
network
is
in
the
path.
That's
really
the
only
thing
the
application
should
have
to
know.
So
the
fact
that
this
packet
is
traversing,
some
other
providers
from
the
applications
point
of
view,
since
that's
not
local.
O
That
should
not
be
relevant.
So
in
that
case
yes,
you're
correct.
If,
if
there
is
to
be
more
negotiation
of
this
path,
then
that
would
have
to
be
something
that's
initiated
by
the
provider
to
the
next
network,
to
the
Nesmith
next
network,
but
I,
guess
that
that
makes
the
difference
very
noticeable.
This
is
only
because
of
the
the
application
talking
in
network
now.
If
this
is
the
case
that
the
provider
is
able
to
do
that,
then
the
ticket
that's
attached
may
be.
O
The
ticket
is
known
to
outside
providers,
but
the
application
doesn't
know
that
the
application,
all
as
it
sees,
is
a
ticket
just
an
app
a
extreme
of
bets
has
no
idea
what
that
means
to
it.
The
network
can
actually
assign
more
semantics
to
it
if
it
wish
I
think
that's
going
to
get
into
some
complexities.
But
if
you
wanted
to
do
this
kind
of
inter
domain
ticketing,
then
yeah
I
don't
want
the
application
have
to
negotiate
with
five
domains
just
to
get
its
packet
sent.
That's
that
would
be
kind
of
crazy
Heather.
P
Daniel
con
Gilmore
ACLU,
so
I'm
trying
to
understand
the
implications
of
this
type
of
scheme
in
a
scenario
where
the
network
may
be
adversarial
to
the
users
interests.
For
example,
the
network
provider
may
not
want
to
deliver
voice
traffic
to
the
user
because
they
want
to
sell
the
user
their
voice
traffic,
which
comes
at
a
premium.
So
do
you
have
any
plans
for
how
this
scheme
could
be
used
in
a
way
that.
O
I
would
I
would
view
it.
This
way
like
I,
said
see.
The
the
user
in
a
sense
has
to
trust
the
network.
I
mean
they're,
getting
servers
from
the
network
that
adversarial
to
the
users
I'm,
not
sure
how
much
we
can
do.
If
the
user
says
I
want
service
a
and
the
network
doesn't
provide,
it,
then
to
call
them,
and
then
this
did
come
up
as
having
lunch
before
we
do,
need
a
way
to
verification
to
verify
the
service
they're
actually
giving.
O
So
you
do
need
that
feedback,
and
presumably
you
can't
trust
the
network
to
say:
oh
yeah
you're
getting
that
service,
so
the
application
would
have
to
decide
if
it's
getting
the
service
that
paid
for
in
that
Sarah,
but
I'm
not
sure
what
else
you
could
do.
So.
Yes,
this
could
be
misused
by
a
network.
That's
adversarial
to
excuse,
there's
no
doubt
I'm,
not
sure.
That's
a
good
starting
point
for
architecture
that
makes.
R
R
R
R
O
Thing
I
didn't
mentioned
mentioned:
it
would
be
nice
if
the
application
didn't
have
to
request
every
individual
ticket
say
say:
the
application
is
creating
thousands
of
flows
or
aggregating
millions
of
flows
if
he
could
become
kind
of
costly.
If
every
time
you
needed
a
new
ticket,
you
had
to
arrest
the
the
network
agent.
Also,
the
tickets
may
expire
at
a
higher
rate.
O
So
one
of
the
things
we
are
considering
is:
is
there
a
way
to
allow
the
application
the
power
to
generate
some
number
tickets
kind
of
autonomous
way,
so
these
tickets
would
still
have
the
same
properties
and
the
network
would
know
that
the
application
generated
these
tickets,
but
the
application
within
some
small
space
could
generate
a
block
of
tickets
and
we
see
the
same
thing
in
Iowa.
If
you
were
at
that
conversation
yesterday
with
hidden
aggregation.
O
So
we
want
the
network
to
to
have
secure
identifiers
stones
in
some
sense,
but
allow
applications
to
actually
create
those
on
a
small
scale.
So
then,
instead
of
having
to
creating
each
individual
ticket
and
give
it
to
the
application,
what
if
the
network
could
just
say?
Ok,
you
can
print
your
own
ticket
book,
it
booklet,
you
can
print
thousand
tickets
and
here's
how
to
do
it
and
I
will
honor
those
thousand
tickets.
But
beyond
that,
I
can't
do
that
and
somebody
else
tries
to
spoof.
You
I
would
detect
that.
R
B
Quick
I
already
answered
this
clarifying
question:
how
big
are
these
tickets.
P
Know
if
you're
familiar
with
the
DL
EQ
work
that
was
discussed
at
CFR
G,
a
discrete
log
quality
work,
that's
being
used
for
privacy
pass.
Are
you
aware
of
this
work?
No,
not
so!
If
you're
thinking
more
about
what
types
of
ticket
issuance
you
might
be
interested
in,
where
a
network
provider
wants
to
sort
of
bind
itself
to
the
mast
and
be
a
good
citizen
and
prove
that
it's
not
doing
certain
kinds
of
things
that
users
might
not
like,
you
might
want
to
look
into
tissue
ticket
issuance.
P
That's
a
blinded
form
of
ticket
assurance
so
that
the
network,
if
it
limits
that
what
the
network
provider
can,
do
and
provides
the
user
with
more
autonomy.
So,
if
you're
interested
in
looking
at
how
to
do
more,
equitable
ticket
distribution,
take
a
look
at
the
DL
EQ
work.
That's
coming
out
of
CFR,
see
right
now,
I
say
so.
You
basically.
L
Chris
we're
just
commenting
on
D
kgs
coming
it's
possible
to
verify
these
particular
tickets
in
batch
is
so
that
may
be
help
well
performance
if
you
do
want
to
go
down
that
route.
So
if
you
are
interested,
we
should
talk
more
about
that.
S
U
Hi
I'm
Tony
Paula
from
Apple
and
I'm,
just
giving
a
very
quick
pitch,
just
a
5-minute
little
pitch
here
for
some
work.
That's
going
on
in
taps,
which
is
tomorrow
morning,
so
I
think
there's
actually
talked
a
little
bit
about
last
time
at
energy,
discussing
post,
socket,
API
stuff,
but
I
want
to
present
the
work
that
we're
currently
doing
for
path.
U
Awareness
in
API
for
transports,
so
here
are
just
three
thoughts
that
we're
trying
to
incorporate
into
our
our
API
models
as
we're
trying
to
look
at
how
to
give
more
path
and
transport
flexibility,
we
want
to
make
sure
that
API
is
allow
applications
to
expect
multiple
paths
as
the
default,
and
so
it's
interesting
to
think
about
how
ApS
can
be
designed
to
not
just
think
of
a
single
connection.
As
one
thing,
one
set
of
IP
addresses
on
one
path:
we're
also
trying
to
consider
how
applications
and
protocols
can
handle
path,
changes
gracefully.
U
U
So
these
are
questions
they're
all
trying
to
consider
if
you
have
thoughts
on
these,
please
come
tomorrow
and
try
to
incorporate
them
and
give
us
feedback
on
the
way
work.
So
specifically,
we
actually
have
three
new
drafts
in
the
taps.
Working
group,
please
do
read
them,
there's
one
top
level,
one
which
is
a
architecture
draft
time
out.
We
know,
what's
our
general
approach,
what
are
we
trying
to
abstract
away
here
to
make
it
more
flexible
around
paths
to
make
it
more
flexible
around
protocols?
U
There
is
a
document
that
covers
the
API,
what
we're
describing
as
the
abstract
non
language,
specific
API
for
how
we
can
have
applications
interact
with
this
model
and
then
we're
also
working
on
a
implementation
guide
document
that
talks
about
how
you
actually
translate
these
concepts
and
how
do
you
get
into
the
nitty-gritty
of
taking
those
concepts
and
putting
them
into
the
protocols
and
specifically
for
path
awareness?
What
does
that
translate
to
4mp
TCP
and
others?
U
A
couple
highlights
I
want
to
point
to
in
the
architecture
and
the
API,
we
have
concept
of
path,
selection,
properties
I'm.
So,
rather
than
allowing
the
app
to
be
involved
in
every
single
path
change,
the
application
can
specify
the
properties
that
it
wants
the
system
to
take
on
its
behalf
around
path
selection.
What
paths
are
preferred
which
ones
are
allowed
which
ones
are
prohibited?
We
believe
this
is
a
pretty
clean
way
to
allow
multi
path,
there's
steps
during
connection
establishment
of
candidate
path,
gathering
and
racing.
U
There's
also
the
notion
of
reading
writing
using
messages,
rather
than
just
having
byte
streams,
even
when
you're
going
over
protocols
that
may
use
a
byte
stream
like
TCP.
Hopefully
this
can
help
the
underlying
levels
schedule
better
if
they
have
notions,
of
which
types
of
data
have
different
levels
of
priority,
different
levels
of
urgency,
dependence
between
each
other
such
that.
U
If
we're
using
multiple
paths,
we
can
take
advantage
of
them
of
the
paths
well,
and
we
also
have
the
notion
of
path
properties
changing
and
allowing
the
application
to
some
degree
be
able
to
react
to
path
changes
so
anyway.
The
next
steps
we're
going
to
be
talking
about
this
all
tomorrow
at
taps.
If
you're
interested
this
type
of
work,
how
api's
can
allow
our
protocols
and
our
devices
to
become
more
path
aware?
Please
join
us
if
there
are
concepts
that
you
think
do
need
to
be
exposed
to
promote
path.
U
L
U
W
B
U
Q
X
X
So
I'm,
here
talking
about
roads,
not
taken
from
the
first
panarchy
meeting
we
had
at
ATF
99
Oliver
did
a
present
a
great
presentation
on
our
experiences.
It's
called
a
decade
of
path
awareness.
We
learned
two
things
from
that
presentation:
we
have
a
lot
of
experience
with
path
awareness
over
the
last
decade
and
we
have
very
little
experience
with
getting
path
weariness
deployed.
So
what
we
decided
in
the
room.
There
was
two
things
again.
X
First,
this
stuff
is
mostly
research,
so
proposing
research
group
done
and
the
second
is:
we
need
to
write
down
what
we've
learned
and
Spencer.
Finally,
yes
cool,
so
this
was
submitted
yesterday
morning.
It's
only
a
start.
The
thing
I
want
to
call
attention
to
on
this
slide
is
that
this
is
providing
the
rules
of
engagement.
We
don't
need
to
describe
every
idea,
but
we
need
to
learn
every
lesson.
Please
contribute
subsections
for
your
own
experience
and
please
send
in
have
full
requests
to
do
that.
Url
is
there?
X
The
requested
format
for
contributions
is
in
section
3
of
the
draft.
Please
send
comments
about
stuff
that
you
see
in
the
draft
revisions
with
draft
mailing
lists.
I
described
my
own
learning,
experience
triggers
for
transport
or
Treat
rant
just
to
get
things
started.
There
is
no
shame
in
describing
your
own
learning
experience
now.
It
would
be
real
clear
about
that.
X
The
stuff
with
the
stuff
was
research,
even
if
we
were
trying
to
engineer
another
way,
hit
away,
yeah,
sorry
area.
So
what
my
contribution
looked
like,
which
is
section
4.2
of
this
draft,
is
a
short
description
of
2002
era.
Tcp
timer
behavior
problems,
a
lot
of
which
had
to
do
with
TCP
s.
That
would
back
off
for
a
long
time.
You
know
exponential
back-off.
X
First,
you
know
to
give
you
an
example
of
what
I'm
thinking
about
here.
Is
that
you
can't
add
complexity.
If
you
don't
take
complexity
away,
we
had
we
had
problems
with
basically
saying
that
you
know
if
you
were
worried
about
congestion,
for
instance,
that
in
congestion
you
can
lose
triggers,
you
can
lose
you,
you
can
lose
the
signal
that
you
are
hoping
to
find
out
about
to
speed
up
and
slow
down.
X
It
turns
out
that
that's
really
awkward,
so
it
turns
out
the
TCPS
leave
all
the
mechanisms
in
there
that
they
would
use
to
recover
if
they
didn't
get
a
trigger
which
they
don't
get
today
anyway.
So,
basically,
all
we
could
do
is
add
complexity.
We
couldn't
take
complexity
away.
A
related
part
of
that
was
that
we
were
I
mean
con.
This
is
2002
right.
Everything
was
in
authenticated
way,
I'm,
not
sure
we're
deprecated,
plaintext
passwords,
yet
so,
basically,
basically
say
I'm
making
something
up
a
little
bit
here.
X
There
was
a
previous
thing
called
ultimate
triggers
and
if
I
remember
it
correctly-
and
some
of
you
all
may
know
better,
because
I
wasn't
involved
with
it,
that
was
more
of
a
I
want
to
be
passing.
I
want
to
be
passing
triggers
up
and
down
the
network
path,
because
things
go
up
and
down
in
the
net
we
go,
and
then
it
work
too
and
that
basically
we
said
you
know
this
stuff
is
all
little
authenticated.
The
best
we
can
do
is
trust
the
next
hop
device,
and
even
that
we
said
well,
you
know
fine.
X
X
Third
thing
was:
if
you
need
support
in
the
network,
operators
will
want
to
bill
for
that
and
what
we
were
providing
was
not
a
big
enough
benefit
to
where
they
could
sell
this
as
a
service,
distinct
from
other
things
that
they
were
selling
the
way
this.
The
way
this
falls
into
the
draft
is
that
this
got
stuck
in
is
section
4.2
in
section
2,
which
is
a
summary
section.
I
tried
to
do
a
less
detailed
version
of
these
lessons.
X
My
suggestion
is
to
look
through
the
section
to
and
if
you
learned
things
that
aren't
there,
please
consider
contributing
a
section
describing
your
own
learning
experience,
based
on
the
conversations
that
we
had
at
Oliver's
presentation
at
ITF,
99
I,
stuck
I
I
stuck
a
thing
in
there
from
intserv
I
stuck
a
thing
in
there
for
gem
6.
It
was
becoming
increasingly
obvious
that
I
wish
I
started.
Writing
the
section
on
QuickStart
two
years
ago,
because.
X
The
other
reason
I
said
our
transport
area
director
is
that
I
think
Miri
and
I
would
appreciate
an
awful
lot
if
people
were
capturing
this
stuff,
because
a
lot
of
it
tends
to
end
up
coming
back
into
the
transport
area
and
we
end
up
learning
the
same
lessons
over
and
over
again.
So
the
transport
area,
directors
I,
am
I.
Speaking
for
you
correctly
Miriah.
You
would
agree
with
that.
This
is
gonna
help
us
yeah,
oh
she's,
naughty
she's
like
it's.
It's
money
is
it's
it's
Tuesday
afternoon
and
so
I'll
stop
there,
and
so.
B
B
Who
has
a
lesson
that
they
would
like
to
write
down
and
help
Spencer
fill
this
document
out,
one
gory
tireless
to
okay,
the
rest
of
you
may
be
able
to
speak
at
other
mics,
but
not
this
Mike,
okay,
so
a
few
so
get
in
touch
with
Spencer.
Please
and
we'll
try
and
get
this
trend
move
this
forward
for
a01
for
Montreal.
So.
X
So,
like
I
said,
if
you
are,
if
you,
if
you
are
a
person
who
can
in
contribute
text
on
ship
six
on
and
serve
or
on
QuickStart,
that
would
be
fabulous.
Two
of
those
sections
are
already
in
there
in
blank,
and
it
says
your
name
goes
here
provide
text,
but
that,
that's
all
you
know,
that's
only
a
beginning,
honestly,
I'm
kind
of
considering
that
this
is
going
to
continue
this.
This
is
going
to
be
a
living
document
for
a
while,
because
we're
you
know
we
continue
to.
X
We
continue
to
learn
as
well
as
continue
to
document
the
things
that
we've
learned
several
times
and
I
forgot
to
raise
my
hand
when
Brian
asked
for
a
show
of
hands,
because
I
was
laughing
so
hard.
I
didn't
need
to
do
that,
so
my
hand
went
up
too.
So
that's
like
I
said:
that's
why
I'm
section
442
yeah.
V
So
I
mean
this
looks
as
if
life
is
easy,
I
mean
I
would
revert
the
whole
thing
in
terms
of
saying
we
can
make
pigs
fly.
We
actually
have
a
pretty
good
track
record
of
doing
that.
As
long
as,
basically,
some
people
thought
that
there
was
business
behind
it
right
and
sometimes
they
actually
was,
and
we
have
flying
pics
a
network,
so
simplicity
and
you
know
saying
architecture
aren't
really
the
best
or
necessary
requirements
to
sell
things
in
the
idea.
The
support
and
the
network
operators
want
a
bill
for
that.
V
V
There
are
so
many
of
these
markets,
and
you
know,
starting
with
your
whole
network,
starting
with
a
lot
of
the
enterprises
where
you
know,
the
margins
of
acceptance
are
completely
different
and
even
when
you
look
at
service
providers
and
I've
got
my
experience
with
IP
multicast,
where
we
still
haven't
gotten
what
we
wanted
to
do
in
89,
which
was
get
multicast
to
home
users,
because,
yes,
the
business
people
didn't
figure
out
how
to
you
know,
monetize
it,
whereas
it's
being
used
everywhere
for
IPTV
for
their
internal
use.
Section
4.5,.
K
U
D
X
T
V
X
With
what
you're
saying
and
the
thing
I
think
I
would
say
also
is
that
what
you're
describing
if
it
got
deployed
it
worked
we're
not
those
are
not
the
people
that
frighten
us,
it's
the
ones
that
we
spend
a
lot
of
time,
doing
something
we
spent
years
on
Jim
6
and
you
know
it
wasn't
deploy.
What
could
we
learn
from
that?
You
know
that's
section
4.3,
if
someone
if
someone
I
would
like
to
take
a
swing
at
that.
Well,
you
know
this.
X
Y
Spenser's
Gauri,
yes,
I,
think
this
document
would
be
really
useful
for
me
to
show
people
when
they
come
up
with
new
proposals,
because
a
lot
of
people
spend
a
lot
of
time
wasted
here
by
going
through
things,
we've
already
done
and
not
understanding
that
they
have
to
talk
about
those
first
to
kind
of
clear
the
ground.
So
this
is
really
good.
It
might
be
difficult
to
remember
the
things
that
completely
went
wrong,
but
we
should.
We
should
encourage
people
to
think
about
those
as
well.
A
lot
of
buffs
are
endless,
so.
X
And
and
I
think
it
is
fair
to
say
that
one
of
the
things
I'm
expecting
to
do
was
editor
on
this
draft
is
some
structural
maintenance
kind
of
things
saying
you
know
what
was
this?
What
was
this
rejected
by
service
providers
rejected
by
operators?
Was
this
trying
to
violate
the
fundamental
laws
of
physics?
You
know
I
mean
they're
like
there's
different,
there's
different
categories
of
things
that
we've
learned
I
think
like
I,
said
I,
think
I.
Think
all
three
of
these
learnings
from
trig
train
might
go
in
three
different
sections,
so.
R
Q
Fact
you
know:
twenty
years
ago
the
tcp
over
satellite
working
group
was
created
largely
to
inform
satellite
industry
of
what
not
to
do
to
try
to
solve
their
problems
and
RFC.
38:19
was
a
really
good
summary
of
that,
and
I
think
that
you
know
the
it's
that's
so
such
a
small
number
compared
to
the
current
RFC
state
that
I
wouldn't
be
surprised.
Q
X
X
B
Check
check
I,
I'm,
Brian,
Trammell
I'm
speaking
now
as
an
individual
on
these
are
sort
of
some
of
my
thoughts
on
ways
forward
so
I
mean
we
all
we've
had
a
bunch
of
presentations
where
we
were
talking
about
path.
Awareness
I
wanted
to
put
my
definition
of
this
up
here.
It's
sort
of
the
science
fiction
for
a
future
IR
TF
sort
of
way
of
looking
at
this
and
I.
B
A
way
of
building
together
networks
of
the
stock
protocols
is
path
aware,
if
the
network
explicitly
exposes
information
about
the
pass
to
the
end
points
and
allows
end
points
to
have
control
over
the
pass
over
which
their
traffic
will
be
set.
This
is
the
best
definition
I
could
come
up
with.
There
are
many
other
definitions,
all
of
which
I
think
capture
some
part
of
this,
where
we're
talking
about
getting
information
out
of
the
network
so
that
you
can
do
things
so
that
you
can.
B
You
know
schedule
which
packets
are
going
to
get
sent,
where
that's
why
this
research
group
has
a
large
overlap
in
the
transport
area
and
information
about
sort
of
like
path
control,
which
is
why
we're
hearing
about
segment
routing
so
on
and
so
forth.
The
kerning
and
architecture.
If
such
a
thing
exists,
is
not
path
aware,
but
there
are
a
lot
of
IETF
technologies
that
we
could
use
to
build
one.
It's
one
of
the
reasons
that
proposes,
as
proposed
working
group,
is
to
have
a
place
to
sort
of
work
out
work
this
out.
B
Why
do
we
want
to
do
this?
A
big
sort
of
driver
for
trains
for
people
as
hey
we're,
we're
doing
a
lot
of
work
on
multipath
transport
protocols.
These
only
work
in
situations
where
you're
multiplicative,
where
you
have
a
different
or
even,
why
all
the
different
characteristics
on
your
access
interfaces.
It
would
be
neat
if
we
could
generalize
this
beyond
just
these
these
cases.
It
would
be
great
if
singly
connected
multi-home
devices
could
maybe
get
some
of
the
control
that
you
get,
and
some
of
the
benefits
that
you
get
over.
B
These
multipath
transfer
protocols
we'd
like
to
look
at
alternate
architectures
for
for
routing
and
the
trustworthiness
of
routing
information,
we'd
like
to
look
at
ways
that
the
endpoints
can
cooperate
with
these
things,
and
we
like
to
experiment
with
cooperative
signaling
for
path
properties
in
pass
selection.
What
have
we
done
so
far?
We've
had
three
meetings.
We
have
this
vision
of
endpoint
participation
in
network
paths.
We
have
a
set
of
open
research
questions
which
I
brought
into
the
Singapore
meeting.
B
We
had
some
good
discussion
on
those
and
there's
a
new
version
of
these
will
go
over
in
a
second.
We
have
a
venue
for
discussion
of
topics
related
to
endpoint
control
of
path.
Selection,
that's
what
most
of
today
was
about.
We
had
many
interesting
proposed
talks
to
come
in
and
say:
okay.
Well,
these
things
are
all
kind
of
related.
Let's
get
together
in
a
room
and
talk
about
them,
and
we
have
some
interest
in
questions
and
discussions.
B
But
if
you
look
at
sort
of
it,
you
know
if
you
can
call
the
output
of
a
research
group
or
the
traffic
on
the
mailing
list,
not
a
lot
of
energy
in
terms
of
answering
them
so
far
and
and
I'd
like
to
kind
of
ask
questions
about,
you
know
how
can
we
do
better?
So
these
are
the
open
research
questions.
This
was
what
we
started
with
before
Singapore
we
refined
it
in
Singapore.
How
do
we
define
and
represent
the
properties
of
paths?
B
One
of
the
things
that's
happened
in
the
meantime
is
some
of
this
work
is
is
possibly
going
into
the
taps
working
group
in
the
IETF.
How
do
we
get
access
to
trustworthy
information
about
path
properties
right
now?
The
endpoints
measure
it
themselves,
I
mean
like
so.
Basically,
everything
in
the
talk
and
intense
work
is
based
on
on
getting
data
that
the
kernel
is
already
measuring.
Can
we
do
better
than
that?
How
do
we
give
endpoints
control
over
path
selected
for
given
traffic
traffic
in
a
way
the
network
compras?
B
Well,
you
can
do
it
with
segment
routing
if
you
magically
fix
the
inter-domain
problem
that
would
be
I'm
missing
a
unicorn
up
here
on
the
top
left
on.
Maybe
Tom
can
help
me
out
and
then
what
are
the
interfaces
for
this
stuff
looks
like
and
it
looks
like
tabs
might
be,
taking
this
on
as
well,
because
the
the
protocol
stack
selection
and
pass
selection
problems
are,
are
sort
of
pulled
into
this
emerging
taps
architecture.
B
Looking
down
the
the
path
of
the
science-fiction
road,
once
you
have
you
pick
it
as
path
awareness,
you
don't
necessarily
want
the
applications
to
do
all
the
heavy,
lifting
or
figure
out
what
figuring
out
what
goes
on,
which
path
you'd
like
to
design
transport
protocols.
That
can
do
this.
We
had
to
talk
about
this
in
in
Singapore.
B
There
is
this
one
actually
came
from
Singapore
howdy
when
we
talk
about
urban
I
talk
about
path
or
an
is
coming
from
sort
of,
like
my
research
background,
I
think
very
much
of
end
point
network
endpoint
and
it's
the
endpoints.
The
endpoints
are
running
the
applications,
but
it
turns
out
that
actually
a
lot
of
these
topics
come
up
in
managing
networks
that
you're
building
out
of
tunnels
and
overlays
and
there's
you
know
an
opportunity,
I
think
for
interchange.
How
does
that?
How
does
this
vocabulary?
B
B
If
you
start
giving
the
endpoints
control
over
where
their
traffic
goes.
Now
you
have
a
control
loop
at
the
ends
and
the
control
loop
in
the
middle.
You
don't
necessarily
want
to
sort
of
cross
drive
what
the
endpoints
are
saying
and
what
EGP
is
telling
the
network
where
the
where
the
traffic
should
go.
So
that's
that's
open
and
researchy,
and
then
there's
the
the
architectural
question
of
that
I
think
is
going
to
show
up
again
and
again
and
again
in
I
I
thought
it
was
gonna,
be
called
draft.
B
Dawkins
energy
don't
do
this,
but
what
not
to
do
is
also
good.
Is
that
okay?
Well,
we
built
the
thing
and
there
were
no
incentives
for
anybody
to
play
it.
So
nothing
happened.
I
think,
there's
a
continuum
here
and
when
we
started
this
research
group
we
thought
we
were
dr..
I
felt
we
were
talking
about
this
well
network
support
for
path,
properties,
endpoint
determinants
or
inter
domain
routing,
whose
guys
and
unicorns
for
all
where
we
started
is
here.
B
What's
a
path
rate
and
one
of
the
one
of
the
the
interesting
things
about
like
looking
at
the
presentations
we've
had
over
the
past
the
past
three
meetings
is:
there's
a
there's,
a
continuum
here
and
there's
actually
a
lot
of
stuff,
a
lot
of
which
is
already
there
right,
like
so
any
transport
protocol
or
or
transport
overlay.
That's
doing
in
transport
measurement
of
what's
going
on
on
a
single
path
and
might
remember
it
is
inherently
path
aware
so
Saucon
intents
is
a
little
farther
down
that
path.
B
Mm-Hmm,
the
but
but
most
sort
of
tcp,
like
working
TCP
implementations
now
all
tend
to
remember
what
works.
What
doesn't
what
the
RTT
was?
Can
it
you
know
we
should
it
do
something
with
initial
window
on
and
so
on
and
so
forth?
There's
the
PVD
work,
which
gives
you
local
link
path,
properties
explicitly.
That
also
exists,
and
that's
also
a
little
bit
further
along
in
this
continuum.
Multi-Point
multipath
transport
protocols
exist
application
access
to
path,
properties
were
not
quite
there
yet,
but
I
mean
you,
I
mean
well
application
access
to
file
properties.
B
W
B
Exactly
great,
it's
a
little
hand
waving
and
then
local
network
path
control.
Well,
you
can
do
that
with
segment
routing
in
a
situation
where
you
already
have
information
about
what
each
segment
means,
but
I
mean,
like
all
of
these
things
are
sort
of
there
and
they're
all
sort
of
along
this
continuum
and
I
think
that.
B
We
can
have
a
very
productive
research
group
if
we
focus
on
sort
of
over
here
and
moving
up
here.
I,
don't
think
we
need
to
really
go
all
the
way
down
into
the
into
the
bright
shiny,
unicorn
science
fiction
future,
but
we
should
keep
it
in
mind.
So
that's
just
my
sort
of
thought
so
from
that.
What
next
everybody
who
raised
their
hands
because
they
want
to
keep
speaking
at
the
mic,
should
talk
to
Spencer.
Please
contribute
to
to
draft
talk
in
spanner
to
you.
B
What
not
to
do
when
we're
looking
at
the
space
and
of
technologies
and
questions
to
tackle
I.
Think
another
session
or
two
like
this,
which
is
really
just
sort
of
solicited.
Talks
hey
come,
and
you
know
if
you
have
something
that
looks
like
it
fits
in
this
space-
hey,
let's,
let's
all
talk
about
it
together
and
and
and
discuss
I
think
that
could
be
useful
with
respect
to
moving
forward
as
a
research
group.
If
what
we're
going
to
do
is
is
write
documents
you
know,
maybe
we
can
do
that.
B
We
also
don't
have
to.
How
should
we
increase
energy
in
the
research
group?
Should
we
focus
on
a
few
questions?
Should
we
look
at
one
into
this
continuum?
Are
there
other
questions
to
consider
and
what
I
would
say
again
as
individual
is?
If
people
have
found
the
questions
doc
useful.
Is
that
something
that
we
should
adopt
and
publish
as
the
research
group
so
with
that
I'm
going
to
sit
down
as
an
individual
and
open
the
line
to
comments
and
discussion?
So
this
is
really
about
and
then
it's
at
some
point.
B
Alison
will
jump
up
and
do
the
IR
TF
chair
thing,
I
presume.
Z
That's
okay
up
so
I'm
Alison,
Mankin
I'm,
the
IRT
F
chair.
We
chartered
this
as
a
proposed
research
group
and
it's
having
its
third
meeting.
So
it's
now
time
to
decide,
shall
we
make
it
a
full
research
group
and
I
would
like
to
get
the
sense
of
the
room
that
there's
commitment
and
interest
to
keep
working
along
the
lines
that
we're
here
and
then
you
know,
then
I
think
you
can
devise
what
the
plan
is.
Z
But
you
know
reminder
to
everybody
that
then
I
want
to
make
sure
that
these
are
good
uses
of
people's
time
and
that
we
get
good
results
out
of
these
research
groups
that
could
lend
themselves
towards
you
know
more.
You
know
more
enlightenment
or
you
know
potentially
engineering
protocols
as
well.
So
so
can
we
I
think
we'll
just
do
a
hum?
Could
you
you
hum
now
if
you
believe
that
this
research
group
should
transition
from
propose
to
full
status.
Z
Okay,
now,
let's
have
a
hum
of
those
who
believe
that
it
and
if
you're
at
the
mic-
yes,
you
probably
should
cover
like
you-
did
Thank
You,
trellis
and
now
another
hum.
This
is
for
those
who
think
that
it
should
not
transition,
and
that
basically
means
it
really
doesn't
get
to
keep
meeting
formally
anymore.
X
Mr.
Dawkins
speaking
as
transfer
area
direct
one
of
the
to
air
transfer
area
directors,
just
the
outgoing
one,
my
take
from
my
place-
is
that
this
work
will
happen,
and
the
only
question
is
whether
it
happens
in
the
IE
RTF,
where
it
belongs,
or
if
it
continues
to
happen
for
another
20
years
in
the
internet
engineering
task
force
where
Allison
was
the
sponsoring
ad
for
trig
Tran.
V
Told
us
Eckhart
yeah
so
to
two
points
is
one
about.
You
know
what
what
is
the
scope
of
the
research
right,
I
think
everybody
loves
to
be
technologies,
and
just
you
know,
do
research
on
these
wonderful
technology
aspects
in
here,
but
quite
frankly
and
I.
Think
Spencer
is
draft,
is
eluding
a
little
bit
to
it.
I
think
there
two
other
really
important
things
to
understand.
V
One
is
business
and
the
other
is
politics,
and
you
know
if
I
look
at
the
history
of
what
we've
tried
to
achieve
here
and,
let's
say,
for
example,
privacy
as
one
of
the
important
you
know,
policies
I
think
it
would
be
good
if
people
would
be
willing
to
stand
up,
and
actually
summarize
also,
you
know
business
aspects
and
policy
aspects
in
a
way
that
that
we
know
what's
either
feasible
in
the
idea
for
what
we
need
to
make
become
feasible
in
the
idea.
In
that
respect.
So.
B
I'm
standing
up
here
as
author
of
the
questions
draft,
this
is
kind
of
what
I
was
trying
to
capture
these
last
two
questions
here.
If
there
are
other
aspects
of
those
questions
that
we
should
address,
please
send
a
line
to
the
list
or
a
PR
on
the
on
the
draft
and.
V
In
the
other
part,
with
respect
to
your
last
slide,
so
I'm
not
that
much
motivated
to
constrain
the
work
only
to
let's
say
data
model,
one
sucking
path
or
five
sucking
path,
but
really
something
to
do
to
get
better
path.
Yeah,
yeah,
I
I
do
applaud
all
the
people
who
do,
and
you
know
to
the
extent
that
I
can
contribute
help
with
that.
But
it's
kind
of
just
a
boring
place
to
stop
right.
Yep
yep,
understand
well.
H
K
H
B
N
Go
for
Deutsche
Telekom,
once
in
a
while
I
go
as
an
observer
to
research
groups
and
I'm,
going
to
drop
out
and
I'm
not
going
to
do
research
when
I'm
looking
at
what
you
were
talking
about.
I
suspect,
I
suspect
that
the
term
path
where
actually
is
misleading,
okay
and
well.
Okay,
once
in
a
while
using
MS
law,
misleading
terminology,
actually
miss
misleads
yourself
kind
of
your
slide
was
saying
yes,
the
question
that
you
were
asking
was
well
okay.
N
N
Probably
very
irrelevant
to
most
of
the
applications
but
kind
of
starting
starting
with
that
kind
of
question
and
terminology
I
think
I
think
the
chances
of
getting
results
that
actually
can
turn
over
into
something
that
is
useful
in
business
and
in
engineering
I
think
would
get
better
people,
people
who
are
who
are
who
are
told.
Well,
okay,
we
are
looking
into
the
paths
and
make
the
applications
network
aware.
N
X
Thanks
Spencer
Dawkins
this
week
or
today,
as
a
IR
s,
G
member,
so
I
you're
kind
of
like
what
are
the
next
steps
and
I'm
thinking.
Next
steps
kinds
of
things
might
be
to
encourage
people
to
especially
people
from
the
IETF
to
take
a
look
at
I
guess:
it's
RFC
74
74
18,
which
is
basically
you
know
the
here's.
If
you're
an
IETF
person,
here's
what
here's
what's
different
in
the
IRT
F
and
here
are
the
advantages
of
being
in
the
IRT
F.
X
Here
are
the
tools
that
you
have
in
the
IRT,
app
that
you
don't
have
in
the
IETF,
because
the
is
G
is
supposed
to
keep
you
from
using
them.
I
can
say
that
I
wrote
that
document,
but
the
the
so
you
know,
for
example,
building
community.
You
know
building
you
know
increasing
the
connection
with
this
community
with
people
outside
the
current
research.
Is
you
know?
That's
a
thing
you
know
so
I
don't
know
if
there
are,
is
the
a
is
a
right
place
for
this
research
group
to
meet?
X
That's
not
co-located
with
an
IETF,
but
but
you
can
do
that
if
there
is
so
like
I,
said
I'd
like
you
to
encourage
people
to
kind
of
think
think
big
about
that.
If
Allison,
if
you
and
Alison
and
Jenna,
decided
that
this
was
to
this
point,
suggesting
that
the
IAB
sponsor
a
workshop
to
also
bring
in
other
people
that
might
not
be
at
at
a
research
conference,
that's
also
a
tool
that
you've
got
so
I
would
encourage
people
in
here
to
think
big
and
not
think
about
how
to
do
a
tree
Tran.
V
Told
us
so
yeah
I
mean
from
what
really
ER
said.
I
think
it
would
be
good
to
have
you
know
for
for
all
the
drafts,
some
kind
of
self
classification
where
they
think
they
fit
into
the
spectrum
right.
In
terms
of
you
know,
this
is
a
cool
idea
which
we
haven't
even
figured
out.
Really
kind
of
you
know,
base
research
type
of
thing
in
one
of
the
other
aspects
and
maybe
on
the
other
side
of
the
spectrum,
where
you
know
a
lot
of
us
coming
from
development
side
and
being
frustrated
with
okay.
V
We
think
this
is
a
cool
technology.
They
will
work,
it
should
be
in
the
IDF,
but
yep
business
or
politics
don't
work
out
yet
so
how
far
can
we
still
drive
it?
Can
we
you
know?
I,
have
you
know
the
research
aspects
of
what's
on
the
business
side?
What's
on
the
politics
side
in
the
research
group,
help
us
to
drive
it
over
to
the
idea,
and
that's
just
you
know,
to
our
ends
of
the
spectrum.
I
can
imagine,
but
the
clearer
we,
you
know,
try
to
self
classify
the
work.
We're
doing
here.
AA
Matt
Mathis
there's
a
lot
of
really
cool
ideas
in
this
space.
There
are
a
lot
of
really
simple,
straightforward,
valuable
ideas
that
had
never
been
deployed
for
a
bunch
of
a
bunch
of
reasons
outside
is
a
simple
example.
Is
we
don't
really
have
a
scavenger
service?
This
is
a
one
bit
surface
on
top
of
other
services,
I
can't
say
this
application
is
running
in
the
background
you
can
finish
whatever.
AA
That's
not
the
same
as
actually
doing
the
research,
so
that
means
people
presenting
the
research
talking
about
it,
exploring
ideas
and
then
saying:
okay,
what's
the
barrier
that
this
idea
is
likely
to
hit
and
helping
people
try
to
overcome
those
barriers,
I'm
very
skeptical,
of
big
changes
because
of
the
scale
of
the
Internet,
not
because
of
the
ossification
of
the
Internet,
although
that
may
be
an
issue,
but
that's
just
a
sheer
scale.
Point.
AA
AA
The
last
six
of
which
have
been
at
Google
and
one
of
the
things
that
you
realize
at
Google
is
the
Internet
is
the
proverbial
elephant
and
a
roomful
of
lineman,
and
it's
different
everywhere
and
no
matter
how?
Well
you
think
you
know
you
you're
part
of
the
Internet
somebody
else's
Internet
is
entirely
different
than
yours.
A
A
Okay,
please
come
if
you
do
not
think
it
should
bad
up
there.
Okay,
air
conditioner
still
does
not
like
your
brand,
but
I
still
isn't
clear.
Okay,
thank
you
and
wait
before
you
leave.
Please
raise
your
hand
and
freeze.
If
you
have
not
signed
the
blue
sheet.
Okay,
cool
I
will
come
to
you
in
a
second,
because
I
do
not
want
people
sitting
on
the
floor
next
time.
I
want
to
have
a
bigger
room
for
this.
Thank
you
very
much
in
CA,
Monroe.