►
From YouTube: IETF106-PANRG-20191122-1220
Description
PANRG meeting session at IETF106
2019/11/22 1220
https://datatracker.ietf.org/meeting/106/proceedings/
C
D
E
D
D
D
D
We
have
two
active
documents
which
we
are
going
to
discuss
and
we
have
one
document
individual
draft
which
were
also
going
to
discuss
today
and
we
have
two
guests
talks
and
I
think
we're
good
to
go.
But
when
you
go
to
the
microphone,
please
state
your
name,
affiliation
and
other
information.
You
think
might
be
interesting
for
a
minute
to
take
care,
and
so
the
first
presenter
is
Brian.
Let
me.
E
E
This
is
open
questions
in
path,
aware
networking
which
the
basically
the
feedback
we
got
at
the
last
meeting
was
to
change
the
title
to
current
open
questions
and
panarin
or
this
is
you
Erin
I,
don't
know
it
looked
confused
about
this?
The
idea
was,
you
know.
If
we're
gonna
snapshot
this,
then
we
should
probably
make
it
clear
that
this
is
something
that
is.
You
know,
as
of
the
point
in
time
as
in
publication,
so
we
changed
some
of
the
frontmatter.
We
changed
the
title.
E
We
kept
it
from
expiring
and
those
were
the
three
things
that
happened
when
we
have
submitted
that
draft.
Just
for
a
review.
There
are
some
open
questions.
I
am
NOT
going
to
sit
up
here
and
read
this
I
think
that
everybody
who
is
interested
in
this
draft
has
already
read
these
multiple
times.
It
turns
out
when
I
wanted
to
make
my
slides
for
this
presentation.
E
All
I
had
to
do
was
copy
my
slides
from
Montreal
and
when
I
say
Montreal
I
mean
102,
not
105,
so
this
document
has
now
been
stable
for
about
18
17
months.
I
did
change
sort
of
the
annotations
over
here
so
how
our
path
properties
defined
represented.
Since
the
last
time
we
talked
about
this
graph.
There
is
now
a
individual
draft
that
that
talks
about
that
sort
of
okay,
so
more
defined
than
represented,
but
you
know
there's
a
semantic
layer
and
then
a
presentation
layer.
C
E
H
E
I
was
just
in
a
in
another
working
group
where
the
word
recent
was
spin,
bitted
and
like
it's
like.
We
shouldn't
talk
about
reason
because
there's
going
to
be
perpetual,
it's
like
so
I
think
that
we
can
leave
current
in
there
and
the
current
means
perpetual.
So
that
way,
I
don't
have
to
push
another
get
tagged.
E
There
was
one
minor
change
to
this
list
of
questions
from
some
discussion
that
we
had
some
time
between
two
Montreal's
ago
and
now
about
the
transition
right
like
so
we're
talking
about
in
this
eighth
question.
So
this
is
the
thing
that's
in
in
italic,
your
is
the
new
text.
This
incentive
alignment
is
not
just
about.
You
know
the
greenfield
creation
of
these
kind
of
networks.
It's
they
transition
right
like
so.
I
On
mark,
so
we
have
this
reliable
and
available
Wireless
boss
earlier
this
week,
and
it's
part
of
this
discussion
leading
up
to
that
we
asked
o,
is
pen
RG
doing
something
and
I
went
I
looked
at
this
staff
to
find
out
about
whether
you
have
discussed
this
sort
of
time
aspect
of
the
properties
so
particularly
Wireless.
We
have
some
path
properties
that
might
very
extremely
quickly
over
some
particular
wireless
link,
as
opposed
to
the
unturned
properties
of
the
whole
path.
Right
and
I,
don't
see
any
mention
about
in
the
draft.
E
E
E
K
E
So
you
actually
do.
We
did
actually
start
the
discussion
about
the
temporal
the
temporal
characteristics,
these
properties,
the
I,
think
the
question
should
capture
that
because
they
don't
write
like
so
when
you
started
trying
to
answer
the
question.
This
other
question
came
up
very
quickly
and
you
kept
answering
it,
but
the
questions
draft
should
point
out
that
this
is
a
thing,
so
I
see
Erik
typing
furiously
over
there
and
I
hope
that
that's
he's
sending
a
PR
on
the
draft,
but
yeah
I
think
I.
Think.
E
Yes,
we're
gonna
talk
about
a
little
bit
more
in
your
in
your
thing,
but
it
doesn't
need
to
be
in
this
draft,
which
means
these
meta
questions
on
the
question.
Draft
are
overtaken
by
events.
We
discussed
a
bit
hasn't
changed
much
we're
gonna
change
that
April
I
would
propose
his
editor,
publish
on
the
IR
TF
stream.
I
would
actually
say
proposed
as
editor
to
publish
on
the
IR
TF
stream.
After
some
discussion
on
the
mailing
list
after
a
zero
for
Rev
that
has
Eric's
text
in
it.
K
L
Just
to
double
check
this
I'm,
like
I'm,
super
happy
to
to
give
you
an
RC
number
for
that.
But,
given
the
word
crudeness
in
there-
and
it
actually
has
some
meaning,
does
it
actually
make
sense
to
publish
it
as
an
RC
or
is
it
just
like
something
we
need
to
know
about
in
this
group
and
then
work
on
the
questions
so.
E
E
My
thinking
on
this
has
changed
over
time
and
where
I
am
right
now
is
publishing
this
as
an
RFC
has
the
advantage
of
giving
people
who
are
working
on
on
technologies
and
techniques
and
and
stuff
in
this
space
who
are
not
in
this
room,
something
that
they
can
wave
around
and
say.
This
is
important
and
I
think
that's
a
service
to
the
community.
G
Erin
+
wonder
what
you
just
said
also
referring
to
my
last
comment,
given
the
fact
that
the
answers
are
coming
rather
slowly,
I
suspect
that
these
questions
will
be
around
for
a
while.
In
fact,
this
would
be
great
input
for,
say,
an
activity.
That's
looking
at
a
vision
of
the
network
for
2030
to
have
some
real
research
questions
to
chew.
On
that
would
okay.
E
So
that's
that's
tuned,
for
we
should
probably
probably
publish,
but
let's
not
have
that
discussion
right
now,
because
there's
going
to
be
text
coming
like
texts
and
it's
coming
in
to
talk
about
the
temporal
aspects
of
things
so
like
on
the
current
versus
not
I
mean
like
we
can.
We
can.
We
can
multicast
the
the
title
a
bit
if
we
want
to,
but
I
think
we
should
probably
do
that
on
the
list.
Yeah
we
already
already
spin
bit
at
the
agenda,
so
we
have
to
multicast
the
title
other
questions.
E
K
Hi
I'm,
Theresa
and
I'm
here
for
an
update
of
deep
F
properties,
draft
which
I
prepared
together
with
Cyril
before
this
meeting,
so
we
got
a
bunch
of
feedback
in
at
last
Montreal,
which
was
105,
and
we
got
an
extensive
review
on
the
list
by
med,
for
which
we're
really
grateful
so
I,
just
the
first
thing.
I
just
wanted
to
remind
people
of
the
scope
of
this
particular
draft.
So
there
was
a
question
on
like.
K
Is
there
some
architectural
reference
of
this
of
this
draft
and
we
think
it
would
be
really
interesting
to
have
something
like
more
fleshed
out
more
concrete,
but
the
architectural
reference
that
we
see
and
that
we
now
link
to
in
the
error
that
we
reference
now
in
the
abstract
or
in
the
introduction,
is
basically
what
the
questions
questions
draft
says.
What
a
path
aware
network
is.
So
the
path
of
a
network
exposes
information
about
the
forwarding
paths
and
services
associated
with
these
paths,
to
costs
or
to
other
entities
and
in
the
path
properties
draft.
K
We
want
to
talk
about
this
information
like
what.
How
can
we
define
this
kind
of
information
either
the
host
or
the
other
entities
would
want
to
know,
and
how
do
we
express
them
and
four
so
yeah?
To
answer
this
question?
We
need
a
common
terminology,
because
if
people
from
different
areas
say
path,
they
sometimes
mean
like
very
different
things.
So
we
had
a
look
at
a
bunch
of
different
definitions
and
now
we're
trying
to
find
a
common
language
for
this
research
group
to
talk
about
paths.
So
we
still
have
nodes
and
nodes
process.
K
K
For
example,
if
you
want
to
talk
about
a
path-
and
you
do
not
care
about
like
each
individual
device,
that
is
on
the
path-
or
maybe
you
just
don't
know-
or
maybe
it
it
changes,
and
so
a
node
can
also
be
this
kind
of
more
abstract
thing
or
a
more
concrete
thing,
and
we
still
have
one
special
case
of
a
node,
because
we
talk
about
hosts
so
much.
We
decided
that
we
would
keep
the
definition
of
hosts,
but
it
our
other
definitions,
do
not
depend
on
it.
K
But
we
talk
about
hosts
a
lot
in
like
other
parts
of
the
draft,
so
that
definition
is
now
aligned
with
our
SLC
11:22
and
then
there's
links
which
basically
allow
one
node
to
send
a
packet
to
another
node
or
even
to
multiple
other
nodes.
Our
links
are
unidirectional.
So
if
you
want
to
model
bi-directional
communication,
just
use
two
links
between,
for
example,
the
same
nodes
which
basically
allowed
to
send
packets
in
opposite
directions.
K
And
now,
if
you
can
sort
of
align
those
or
if
you
have
multiple
of
those
nodes,
one
after
the
other,
each
of
nodes
and
links
one
after
the
other,
they
are
path
elements.
If
you
can
transmit
a
packet
over
these
path
elements,
then
this
is
enough
for
them
to
form
a
path.
So
you
can
have
a
path
that
includes
note,
link,
node
link
and
then
there
can
be
three
nodes,
for
example,
for
the
for
the
service
function,
chaining
use
case.
K
We
need
this,
so
it
depends
on
kind
of
your
granularity
and
then
the
de
path
is
defined
as
the
sequence
of
path
elements
from
one
node
to
another,
node
doesn't
have
to
be.
A
host
can,
of
course,
be
like
both
hosts,
but
they
can
also
be
overlay
nodes,
for
example,
and
we
didn't
want
to
have
like
a
clear
distinction
between
what
is
a
host.
What
is
a
router?
What
as
an
overlay
node,
because
then
we
might
unnecessarily
constrain
our
definitions.
K
So
now
we
just
have
like
one
node,
another
node,
and
that
can
be
a
packet
sent
from
one
node
to
the
other
node
across
those
path,
elements
and
then
sub
path
is
just
a
subsequence
of
this
path
doesn't
have
to
start
and
end
with
a
node
anymore.
So
we
can
just
talk
about
maybe
three
nodes
or
three
links
or
something
like
that
and
then
the
packet.
So
a
data
flow
is
packets.
K
That
can,
for
example,
be
sent
from
one
node
to
another
over
a
given
path,
but
we
didn't
want
to
constrain
our
definition
to
imply
that
all
the
path
elements
have
to
stay
the
same,
because
maybe
you
send
you
sent
multiple
packets
and
somewhere
on
your
path.
Maybe
it
just
tastes
like
a
load,
balancer
and
then
packets
take
one
way,
the
other
way
and
so
on.
Maybe
you
want
to
still
collectively
refer
to
those
packets
because
they
are
between
the
same
nodes
right
and
so
we
basically
have
a
flow.
K
That
is
just
a
collection
of
packets,
and
we
want
to
talk
about
these
packets
sort
of
as
a
collection
and
like
a
path
property
to
them,
and
then
the
property
definition
essentially
stayed
the
same,
but
like
components
that
it
refers
to
change.
So
we
think
now
a
path
property
should
should
work
as
a
definition,
and
we
give
a
number
of
examples
for
path
property
so
note
that
we
remove
the
classification
into
domain
properties,
backbone
properties
and
what
was
the
other
dynamic
properties.
K
But
now
we
basically
have
a
list
of
of
examples
of
path
properties
which
might
be
interesting
to
know
for
the
host,
such
as
what
access
technology
do
we
have?
Is
this
a
Wi-Fi
link?
Cellular
link
is
like
Ethernet,
and
does
it
cost
money
to
transmit
packets
across
a
network
across
a
link
then
did
administrative
domain
is
a
new
property
which
we
basically
we
basically
more
of
this.
K
This
aspect
that
maybe
you
care
like
who
owns
path,
element
on
your
path
or
sequence
of
path
elements,
and
that
is
the
administrative
domain
property
which
can,
for
example,
just
be
it
belongs
to
an
autonomous
system.
It
belongs
to
a
certain
service
providers
network,
or
it
might
also
be
like
more
fine-grained.
K
So
those
definitions
we
aligned
with
basically
with
existing
RFC's,
such
as
wit,
entire
di
VPN
working
group,
because
we
we
do
not
intend
to
like
redefine
properties
that
are
already
well
defined
somewhere
else
right.
So
we
have
this
list
of
examples
of
map
properties
and,
of
course,
this
is
not
an
exhaustive
list,
but
just
a
few
examples.
So
we
wanted
to
motivate
our
examples,
and
that
is
why
we
have
the
use
cases
section
in
there.
Actually,
this
section
is
not
new.
K
It
was
part
of
the
introduction
before,
but
now
we
explicitly
made
it
its
own
section
and
those
are
three
use
cases
that
we
came
up
with
also
with
the
help
of
our
reviewer
and
yeah.
Basically,
those
are
examples
why
a
host
or
another
entity
might
want
to
know
about
the
past
properties
that
we
have
in
our
draft
and
with
this
I'm,
going
back
to
like
the
bigger
picture.
K
So
after
the
scope
of
this
draft
and
the
context
so-
and
we
have
asked
for
adoption
on
the
list
already-
there
was
not
a
lot
of
feedback
at
the
time
so
now
I
just
would
like
to
to
ask
again
so
do
it.
Does
the
research
group
think
that
these
terms
and
like
this
draft
serves
or
may
serve
as
a
basis
for
us
as
a
research
group
to
come
up
with
a
common
terminology?
So
we
can
talk
about
a
path
properties
in
the
context
of
the
research
group
and
maybe
later
on,
for
people
reading
a
strap.
M
M
M
Have
you
know
things?
I
can
help
me
do
MPT,
CP
or
like
things
that
can
act
as
proxies
or
nodes
that
enable
path
selection
and
in
potentially
even
when
we
talk
about
measurement
nodes
that
participate
with
the
client
in
path
measurement.
So
they
are
know.
So
essentially,
there
are
transparent
nodes
and
there
are
nodes
that
you
can
use
for
measurement
or
selection
that
are
enabling
some
future
techniques,
and
so
maybe
just
having
a
definition.
Kosovo.
M
K
N
K
They
will
automatically
be
generated
or
available
I,
just
I'm,
coming
up
with
a
with
definitions
of
how
to
talk
about
those
properties.
If
there
are
like
devices
that
can
come
up
with
them
right
or
if
there
are
devices
that
sort
of
can
can
process
them,
but
how
we
would
exactly
measure
them
how
we
would
communicate
those
properties
from,
for
example,
a
puff
element
to
the
end
point.
That
is
another
answer
to
another
research
question
that
might
be
another
research
group
draft
or
something
else.
So
this
is
just
about
the
terminology,
so
I
do
not.
N
So
the
next
question
is
that
it
seems
that
you
may
want
to
design
a
representation
format
and
cap
and
for
those
paths
and
their
properties
I
have
actually.
These
looks
very
similar
to
what
is
done
in
auto,
auto
defines
a
feature,
a
service
that
is
called
path
vector,
and
that
may
be
useful
to
your
work,
because
between
two
endpoints
you,
you
make
a
break
you
you
make
a
breakdown
on
what
happens
between
two
end
points,
and
that
can
be.
This
is
kind
of
this.
This
would
support
what
you
would
like
to
have
as
information.
N
K
Read
a
number
of
different
like
drafts
that
relate
to
different
definitions
of
a
path.
Your
sounds
more
like
the
transport
perspective,
so
we
we
have
on
our
github
repo,
where
this
draft
is
being
developed.
We
have
a
wiki
where
we
also
list
like
some
working
groups
and
some
RFC's
that
are
related.
We
have
Alto
in
there
I
believe,
but
I'm
gonna
go
back
and
check
the
specific
like
path
vector
that
you
mentioned,
and
then
we
can
talk
about
more
okay.
E
Actually
I
wanted
to
I
want
to
come
up
here
and
say:
yes,
I
think
this
is
a
good
start.
I
think
we
should
continue
this
discussion
in
the
research
group.
This
is
what
we're
here
for
I
have
a
couple
of
things
that
I
would
change,
but
I
don't
want
to
make.
Those
discussion
goes
from
here,
because
I
don't
want
to
I,
don't
want
to.
Let's
see
we've
already,
you
spend
it
and
multicast
I
don't
want
to
put
it
in
the
DNS.
The
Tommies
thing
like
I
think
he
just
like.
Did
that
and
then
ran
out?
E
Didn't
he
so
Tommy's
idea
is
intriguing,
but
terrifying.
I
would
not
want
to
see
us
try
to
go
down
the
the
path
of
node
properties
or
node
classification
in
the
path
properties.
Document
I
think
there
is
some
room
for
talking
about
the
types
or
classes
of
functions
that
a
node
might
like.
So
I
like
the
idea
of
like
saying
this
is
a
transparent,
and
this
is
an
in
transparent,
and
this
is
a
you
know,
layer,
X-
and
this
is
an
endpoint
right
like
so
that
beyond
that,
I
don't
think
we
want
to.
E
K
E
K
E
But
as
an
individual
contributor,
I
just
say
that
I
will
be
I'll,
be
sort
of
aggressively
pushing
toward
trying
to
generalize
the
things
in
this
document,
as
opposed
to
make
them
like
specific
to
a
particular
thing.
I
also
think
that,
like
so
there's
a
there's
definite
overlap
here
with
Aalto,
with
respect
to
like
the
path
vector,
I,
think
there's
a
very
clear
line
between
the
responsibilities
of
Alto
in
terms
of
building
representations
of
these
things
and
the
energies
should
work
on
abstract
vocabulary.
E
K
E
O
You're
being
it
a
statement
on
the
same
topics
on
policy
on
Thomas
comment,
I
find
it
very
interesting
to
have
this
property
of
a
layer,
X
transparency.
You
can
formulate
it
mathematically.
You
can
aggregate
it
on
path,
on
path,
aggregations
on
aggregations
of
on
subpaths,
to
formulate
that
you
have
a
transparency
on
a
specific
layer,
which
means
that
you
have
an
kind
of
end-to-end
connectivity
for
this
specific.
O
K
So
it
could
you
could
you
like,
provide
a
reference
or
something
to
that
to
the
list,
because
I
would
like
to
see
like
how
do
you
express
that
mathematically?
Because
we
did
have
something
like
that
and
I
think
previous
versions
of
our
definitions,
and
then
we
were
like
yeah.
It's
kind
of
hard
to
express.
So
I
would
just
like
to
take
a
look
at
like
how
you
mathematically,
Express
those
become
ok.
O
K
What
I
could
imagine
is
you
have
to
talk
about
trust
in
some
way,
but
this
is
really
complicated,
I'm,
not
sure,
like
I,
don't
think
you
can
capture
how
much
you
trust
a
certain
half
element
as
a
property
yeah,
but
otherwise
what
do
you
want
encrypted?
Your
transfer
like?
Is
it
like?
Oh
traffic
is
encrypted
between
this
and
that
other,
but
still
you
have
to
you,
have
to
qualify
it.
It's
not
like
encryption
is
not
the
same
as
encryption
right.
Yes,.
O
O
K
K
P
T's
does
begin
as
an
individual
first
really
thank
you
for
doing
this
work
because
we've
seen
it
maturing
a
lot
and
I
think
it's
read
definitely
in
the
state
where
we
should
adopt
it
and
work
together
on
it.
Honorable,
as
a
working
group
or
as
a
research
group,
sorry
tommy's
comment
also
made
me
think
made
me
stand
up
for
more
deities
I,
think
it's
very
good,
starting
with
a
generic
description
of
the
past,
like
just
being
a
set
of
node
or
a
sequence
of
notes.
P
Besides
that
the
idea
of
whether
the
note
is
transparent
or
isn't
transparent,
so
whether
it's
actually
breaking
the
end-to-end
principle
or
whether
it
isn't
breaking
that
end-to-end
principle,
it's
an
important
property
I'm,
not
sure
whether
we
need
this
in
the
basic
definition
or
that's
one
of
the
first
properties
of
a
note.
One
wants
to
be
fine.
K
P
K
L
L
Adoption
can
work
on
that,
but
the
actual
reason
I
came
here
was
that
about
the
use
cases,
you've
added
so
I
think
it's
a
very
good
approach
to
look
at
the
use
cases
and
figure
out
like
based
on
the
use
cases,
what
we
need
and
what
we
want,
but
right
now,
I
find
the
use
case
is
rather
a
little
bit
confusing,
because
so
example,
you
talk
about
performance,
monitoring
and
like
performance.
Monitoring,
for
me,
is
something
very
like
I
want
to
know.
Does
my
does
work?
That's
my
network
work
right
now,
right
and
I.
L
Don't
think
that's
what
you're
looking
at
that's
actually
kind
of
what
you're,
explaining
very
lengthy
in
the
next
section,
talking
about
examples
that
it's
not
about
dislike
current
state
but
more
about
general
properties
right
and
that's
also
everything
that's
related
to
measurements.
Always
the
question
is:
what's
your
measurement
timeframe
right?
This
is
something
you've
been
measuring
over
the
last
second
or
do
you
take
the
average
over
the
last
week
right?
L
K
Yeah
so
I
definitely
open
to
contributions
to
this.
To
this
use
case
a
section
because,
yes
I
agree,
it
needs
more
work,
performance,
monitoring,
I.
Think
as
the
definitions
work
right
now,
we
can
have
both.
We
can
have
like
the
very
short
term
because,
like
the
property
would
be
defined
on
may
be
a
single
packet
and
one-way
delay
of
a
single
packet,
and
then
you
can
aggregate,
and
then
you
can
aggregate
over
the
last
10
seconds
last
hour
week.
K
L
K
L
K
So
this
can
be
protocol
features,
but
it
can
also
be
like
application
level
modifications
to
what
you're
sending
as
a
horse.
So
I
wanted
to
keep
it
much
annual,
but
traffic
configuration
was
trusted
to
her.
Mine
came
up
with
like
at
one
point
and
of
course
we
can
change
it
or
maybe
split
those
news
cases
and
make
them
more.
I
L
Q
F
Andrew
McGregor,
firstly,
I
could
have
a
lot
to
say
about
this,
but
I'll
just
restrict
myself
a
bit.
Firstly
representing
representing
different
modes
of
a
path
as
separate
paths
is
a
really
bad
idea,
because
what
you
want
to
do
is
represent
where
the
shared
resources
are,
and
if
you,
if
you
say
ok
at
this
point,
you
could
route
it
through
that
tunnel
or
not.
Then
what
about
the
fording
resources
on
the
on
path,
nodes
that
are
in
the
unfolded
version
of
the
path?
How
do
you
represent
that
you're
sharing
buffers
between
the
two
versions?
Right?
F
D
B
E
C
E
B
H
The
question
was
mostly
just
give
me
time
to
take
the
picture
so
I'm
Spencer
Dawkins
I'm,
talking
about
the
what
not
to
do
draft,
which
was
something
maybe
I,
can
give
just
this
much
background
for
people
who
haven't
read
it
for
from
the
beginning
of
the
research
group
work.
One
of
the
things
we
said
was
that
we
keep
you
know,
we've
had
a
lot
of
had
to
wear
networking
mechanisms
that
didn't
get
deployed
and
they
keep
not
getting
deployed
for
many
of
the
same
reasons,
so
we
should
write
those
down.
H
H
We've
been
talking
about
this
draft
as
a
research
group
draft
and
as
an
individual
draft,
for
you
know
what
what
will
be
in
Vancouver
two
years,
they've
been
presented
at
every
parent
recession,
since
ITF,
400
and
I
want
to
say
that
every
revision
has
been
an
improvement,
and
that
has
been
because
people
have
worked
on
it
and
contributed
to
it.
Thank
you
for
those
people.
H
We
can
continue
to
improve
this
draft
in
the
future
or
it
might
be
time
for
this
bird
to
leave
the
nest
and
the
reason
I
think
that
is
the
last
two
major
revisions
have
been
mostly
summarizing.
The
draft
the
goals
for
this
informational
draft
are
to
inform
research
in
this
research
group.
Research
outside
this
research
group
and
engineering
outside
this
research
group,
and
that's
the
third
one,
is
the
one
I
want
to
call
the
most
attention
to.
H
If
you
look
at,
if
you
look
at
the
dip
from
zero,
three
you'll
see
a
lot
of
changes
in
section
two,
but
that's
those
are
mostly
formatting
changes.
I
was
mostly
adding
anchors
to
allow
cross
refs
from
other
parts
of
the
document,
so
you
see
a
lot
of
deaths,
but
not
very
much
change
text.
There's
a
new
section
called
section
three:
this
was
the
so
this
is
summarizing
the
discussion
we
had
at
IETF
105,
and
so
that
summarized
summary
is
on
the
next
slide.
H
The
answer
very
much
I,
don't
think
well,
I
should
have
asked
was
do
we
understand
this
lesson
enough
well
enough
for
people
who
think
about
this
lesson
to
assess
risk?
If
the
answer
is
yes,
we're
talking
about
engineering,
if
we're
talking
about
no,
it's
still,
research
I
think
that's
the
question
we
actually
talked
about
at
ITF
105.
So
the
good
news
is
that
the
research
group
ignored
Spencer's
question
and
talked
that's
always
the
right
thing
to
do
of
the
the
lessons
that
are
summarized
in
the
draft.
There
are
two
of
them
that
I
don't
think.
H
Based
on
the
discussion
we
had
at
IETF
105,
we
unders.
We
understand
these
well
well
enough
for
people
to
assess
risk.
One
of
them
is
endpoints.
Trusting
in
intermediate
devices.
One
is
intermediate
devices
trusting
endpoints
and
for
these
two
lessons
Spencer
thinks
we
need
to
revisit
the
internet
threat
model
and
note
that
the
IAB
has
an
active
discussion
on
this
on
the
Model
T
mailing
list.
And
if
you
click
on
that
in
the
slides
you
get
the
mailing
list.
H
K
No
I
think
you
asked
the
right
question
o5,
but
this
question
is
kind
of
related
and
more
specific.
So
if
you
define
risk
as
just
like
the
Trust's
sort
of,
but
we
had
a
lot
of
things
about
that
deployment,
is
it
gonna
get
deployed
and
so
on
and
I
think
I.
Think
asking
the
broader
question
is
absolutely
fine
about
a
sweat
model.
Yes,
this
is
really
interesting
and
we
should
follow
it.
I'm
not
sure
like
what
we
can
contribute
to
it.
K
H
E
Hi
Brian
Cromwell
speaking
as
an
individual,
as
the
editor
of
the
questions
talk
I'll
plan
out
that
your
two
questions
there
question
number
two
and
question
number
three
and
the
questions
talk
but
expanded.
So
the
questions
arc
was
basically
looking
at.
You
know
this
endpoint
trusting
the
intermediate
device.
How
can
you
get
trustworthy
path,
properties
to
you
and
intermediate
Rises,
trusting
endpoints?
These
are
sort
of
a
superclass
questions.
E
The
this
into
the
room.
There
was
that
a
lot
of
this
stuff
needs
to
be
moved
into
the
IETF
sooner
rather
than
later.
I,
don't
know
if
that
means
that
there's
gonna
be
traps
that
turn
into
a
ball
or
what?
But
since
a
lot
of
this
is
going
to
update
the
internet
threat
model,
which
is
the
security
considerations
like
guidelines
for
writing,
security
considerations
is
that
the
RFC
that
they
need
to
update
or
obsolete
in
order
to
do
that,
the
wider
questions
about
this
end
point
intermediate
device,
trust
and
intervene
device.
E
Endpoint
trust
should
be
addressed
as
part
of
that
effort.
Having
spent
five
years
of
effort
on
that
question,
I
am
it's
Friday
and
I'm
not
gonna,
go
down
a
rabbit
hole
of
cynicism,
but
I
mean
there's
work
to
do
there
and
explicitly
reason
that
I
wanted
to
frame
the
questions
in
the
questions
draft
much
more
in
a
much
tighter
scope
with
respect
to
like
these
properties
was
to
see
if
there
was
a
way
to
frame
that
question
in
order
to
make
progress
on
it,
and
maybe
I
should
take.
E
E
R
R
Think
this
we
should
distinguish
from
revisiting
the
internet
for
its
model,
that
the
standards
community
uses
to
frame
their
standards
and
doing
research
which
thinks
about
some
of
the
threats
related
to
this
and
I.
Think
there's
nothing
stopping
is
doing
research
about
perfo,
where
networking
and
how
its
effects
end
points
and
so
on.
Provided
this
group
is
not
trying
to
directly
drive
water.
N
R
H
Is
this
is
the
retrospective
on
engineering
draft
that
I'm
talking
about
here?
It's
so
if
I
understood
what
your
we
are
saying
there
is
that
we
should
do.
We
can
do
research
in
that
space,
but
not
necessarily
as
part
of
the
retrospective
draft.
Do
you
see
what
I'm
you
see?
What
I'm
saying
did
we
oh
we're
talking
we're
talking
about
moving
forward,
and
that
won't
happen
in
the?
What
not
to
do
draft
I
think
right.
R
Right
I
mean
this:
this
group
has
produced
a
graph
that
says
we
believe
these
things
are
problematic,
yeah
and
that
that
will
be
published
and
sure
yeah
I.
Don't
think
this
group
should
be
trying
to
influence
what
the
standards
process
is
doing
and
how
this
the
IETF
community
defines
its
threat
model.
S
H
So
my
proposed
stick:
next
steps
were
basically
to
do
a
largely
editorial
revision
to
fix
up
the
phrasing
around
the
question.
I
should
have
asked
at
105
and
do
a
research
group
last
call
on
0
5,
resolve
issues
raised
during
class
call
and
request
publication
as
an
IRT,
have
stream
informational
draft
and
then
begin
informing
proposals
inside
and
outside
the
research
group
and.
H
E
My
perception
watching
this
document
evolve
over
time
is
that
the
velocity
is
going
down.
Right
is
your
like
in
terms
of
like
changes
to
it
and
like
things
that
we're
adding
to
it.
It's
like
there
was
sort
of
this
explosion
of
effort,
and
now
it's
sort
of
is
there
anything
that
could
be
gained
by
keeping
it
open.
It
looks
to
me
like
it's
slowing
down.
Is
that
your
perception
as
well?
Well
so
so.
H
It
makes
a
difference
what's
moving
in
as
well
as
how
fast
what-what
was
moving,
was
the
contributions
and
that's
what
you're
remembering
where
it's
like.
Oh
the
first
few
times
I
did
this
it's
like.
Well,
we
at
you
know
we
added
we
added
material
on
we
had
we
at
you
know
we
added
material
on
diffserv
or
you
know,
whatever
you
know
whatever
it
was.
So
the
sections
of
the
contributions
which
are
in
section
5
now
I
think
because
those
section
numbers
keep
changing,
but
the
contributions
that
are
there.
H
We
kept
adding
those
what
has
been
changing
and
I.
Don't
know
that
the
I
don't
know
that
the
word
came
out
of
the
changes
have
been
and
quite
trailing
off.
But
what
it's
been
changing
has
been
that
we've
been
more
adding
more
and
more
text
that
were
summarizing
the
contributions
and
the
lessons
learned
from
those
contributions
we
haven't
edited.
E
H
It
really
turns
out
to
be
critical
to
attend
the
Pecha
Kucha
talks,
because
we
keep
using
words
from
last
night
like
yeah,
we're
spin
bidding
this
or
we're
going
down
the
rabbit
hole,
or
you
know
things
like
that
that
we're
discussed
there
that's
turned
out
to
be
a
really
key
part
of
the
ITF
week.
If.
S
T
Just
before
the
Pecha
Kucha
didn't
make
them
the
best
set
of
slides,
but
mostly
stuffing
is
actually
okay
and
I.
Think
I
think
we're
ready
to
talk
about
this.
Aren't
we,
the
title
is
MTU
is
hard:
getting
packets,
bigger,
bigger
packets,
don't
simply
get
there,
I
mean
Bert
right,
we
start
with
an
application,
it
sends
some
data
and
we
have
a
notion
of
how
big
a
piece
of
data
we
concerned
in
TCP.
T
That's
MSS,
it
reads:
Mike's
Datagram
lots
of
different
words
are
used
here
and
then
the
transport
has
some
notion
of
Kohan,
which
you
can
send
and
the
network
layers
got
a
notion
of
how
bigger
packet
is
and
in
fact
it's
got
more
than
one
notion,
because
it's
got
a
size
of
actually
the
subnet
it's
using
and
the
size
it
thinks
he's
using
and
the
interface
size.
There's
lots
of
things
going
on
here.
It's
not
just
as
easy
as
sending
a
big
packet
down
a
pipe
and
it
comes
out
on
the
on
the
network.
T
Are
you
going
to
interpret
at
some
point?
Bob,
oh
okay,
but
the
solution
to
this
is
great.
We
did
it
years
and
years
ago
and
we
take
big
piece
we
MIT
and
smaller
in
the
network,
and
they
come
out
big
at
the
end,
because
you
reassemble
them
read:
RFC
791,
you
figure
out
how
it
all
works,
and
then
we
discovered
and
in
1987.
So
this
is
kind
of
relatively
recently.
T
Fragmentation
was
a
harmful
thing
to
do,
because
when
you
brick
pack
it
up
into
lots
of
pieces,
they
don't
all
arrive
in
the
same
order
and
what
happens
if
one
of
them
doesn't
get
there
and
what
I
don't
see
if
you
get
bits
of
ones
that
you
didn't
actually
send
and
yeah,
it's
not
possible
to
kind
of
do
this.
So
what
we
want
to
do
is
get
the
network
to
tell
you
how
big
a
packet
to
send
isn't
that
was
signal
if.
U
T
And
there's
some
helpful
boxes
that
don't
leave
the
RFC's
and
tries
to
put
packets
together
or
try
and
do
other
helpful
things
for
you,
so
I'm
pregnant
subproblems
right
save
the
day.
Let's
not
really
do
fragments,
let's
just
tell
them
that
work.
If
you
can't
send
a
big
packet,
send
a
signal
back
for
your
path
and
will
will
tell
you
how
big
of
packet
to
send
it's
all
very
great
and
good.
It
was
done
in
1919
1191.
The
transport
simply
gets
a
signal
from
the
path
saying:
here's
how
big
a
packet
you
should
send.
U
T
S
T
As
you
think
and
yeah-
and
it
was
subtly
tricky
to
implant
in
TCP
as
well
because
of
the
MSS
thing
and
what
TCP
decided
to
do
was
simply
decide
at
the
beginning:
hey
how
big
a
packet
can
you
send
and
the
boxes
in
the
middle
on
the
path
read
the
MSS
value
and
they
change
it
to
reduce
it
to
the
correct
size
it
should
have
been
sent
to
because
obviously
they're
not
better
than
the
endpoint.
So
what
the
endpoint
learns
is
I
can
only
use
this
size
across
the
network
path.
T
It's
called
MSS
clamping
widely
deployed
great
technology.
It's
what
makes
the
network
work
with
TCP.
So
that's
really
good.
It's
not
an
IETF
way
of
doing
it,
but
it's
the
way
it
works
currently
and
sadly,
this
is
where
we
got
to,
but
there's
more
and
oh
yeah
and
some
people
think
fragmentation
is
still
harmful
after
we've
done
all
this
and
we
have
to
think
about
it
because
ipv6
hopefully
has
fragmentation,
but.
T
T
If
ICMP
was
harmful,
then
maybe
the
transport
shouldn't
really
rely
upon
ICMP.
So
back
in
a
while
ago,
we
invented
P.
If
we
take
what
we
got
yeah
yeah
yeah
right
right,
that's
fine,
yeah,
missing
one
slide!
There
didn't
show
the
slider.
Is
we
invented
something
else,
but
we'll
come
back
to
that
if
ICMP
was
was
harmful
and
it
was
harmful
in
various
ways.
One
way
was
we
do
see
some
ICMP
messages
that
contain
just
the
wrong
information.
These
horrible
people,
building
Reuters
actually
might
to
get
some
cord
wrong.
I.
T
Think
some
learner,
little-endian
versus
big-endian,
are
the
number
you
get
back
he's
kind
of
just
swapped
yo.
So
you
get
kind
of
like
a
bit
of
wrong
advice.
That's
just
awkward!
That's
not
really!
The
big
problem
with
the
signal.
Big
problem
with
the
signal
is
when
these
handing
network
layer
people
designed
path,
MTU
discovery.
T
They
thought
this
was
a
great
signal
and
they
didn't
know
how
to
check
whether
it
was
a
signal
from
somebody
who
actually
saw
your
packets
on
your
path
or
whether
it
is
somewhat
helpful
somewhere
else
in
the
exact
he
was
just
telling
you
to
use
a
certain
packet
size
other
time
that
wasn't
really
a
big
issue.
No,
we
call
it
like
a
dosa
Tyco.
T
T
You
have
to
have
a
way
to,
and
so
you
can
find
out
he's
got
an
encapsulated
packet.
Maybe
we
should
have
always
checked
that
and
checked.
It
actually
match
the
floor.
We
were
trying
to
send
at
the
transport,
so
we
can
do
it
that's
great,
and
if
we
have
it,
then
maybe
the
ICMP
message
are
a
little
bit
useful.
Maybe
they're
hints
useful
advice
from
the
network
about
what
to
do.
T
Maybe
the
transport
layer
can
use
this
to
check
to
see
whether
the
network
path
actually
supports
it,
and
if
it
does
hey,
that's
a
great
idea.
We
get
to
the
right
value
very
quickly
and
if
the
transport
layer
finds
it
doesn't
work,
then
it
doesn't
say
the
ICMP
message
must
have
been
right
and
I'm
wrong.
It
simply
says
that
size
doesn't
work.
I
would
choose
a
different
size,
so
we
can
go
quite
a
long
way
with
this.
T
This
is
quite
a
good
way
of
doing
things
and
and
it's
the
way
that
PLP
and
tud
now
saves
the
day,
PLP
path,
packetization
layer
path,
MTU
discovery
puts
the
problem
at
the
transport
layer
and
it
takes
signals
in
from
these
probes.
Decide
what
to
do
HP
and
implemented
in
SCTP?
It's
it's
in
the
quick
spec
and
there's
a
spec
with
the
iesg
on
how
to
do
it
was
done.
It
was
a
other
ways
of
doing
this.
T
This
is
now
a
general
method
and
I
think
the
working
transport
TS
vwg
at
the
bottom
is
going
to
be
published
next
year
prediction.
I
don't
know
when
things
really
get
published,
but
this
is
a
mechanism,
that's
kind
of
robust
and
works.
Well,
it
tastes
pass
signals
and
does
useful
things
with
them,
and
you
can
use
ICMP
messages
optionally
to
help
you
find
about
the
path.
Maybe
you
can
use
other
signals
and
maybe
extension
headers
yeah.
We
can
go
on
an
extension,
headers
model
and
extension
headers.
T
Something
proposing
ipv6,
don't
work
across
all
paths,
pretty
start
actually
a
problem.
You
can
get
path,
information,
there's
just
hints
just
useful
stuff.
So
if
it
works
in
some
place
and
tells
you
something
useful
that
you
can
use
it
so
there's
an
interesting
thing.
Maybe
past
signals
don't
have
to
be
accurate,
they
just
have
to
be
good
advice
or
there
you
can
probe
and
check
they
work.
T
Are
we
going
forward
there?
We
go
so
next
thing.
How
much
of
this
is
real
in
future?
Well,
the
first
thing
is:
how
big
a
packet
can
we
actually
send
and
don't
really
know,
operators
being
deploying
rooters
and
switches.
I
support,
big
packets
in
many
parts
of
the
internet,
many
people
at
home
can't
send
big
packets.
What's
the
real
state
of
play,
which
parts
the
Internet
do
what
I
mean?
T
We
don't
actually
know
if
you
know
just
come
and
tell
me
and
I
don't
have
to
this
talk
again,
if
not
I'm,
going
to
try
and
start
measuring
this.
The
other
thing
is
how
about
extension
headers.
We
know
they
don't
reliably
work.
We've
got
lots
of
evidence
that
some
people
drop
them.
What
about
those
people
who
forward
them?
Where
can
they
be
forwarded?
How
much
can
we
use
them
for
something
useful?
T
This
is
why
Bob's
here,
because
Bob
and
I
have
a
nice
draft
that
says,
let's
use
a
hop
by
hop
extension
header,
to
figure
out
the
MTU
of
the
path.
If
we
get
it,
we
have
a
hint.
We
have
a
great
piece
of
information.
If
we
don't
well,
it
doesn't
matter,
we
will
carry
on
doing
the
PLP
and
tud
algorithm
and
find
a
way
ourselves.
So
this
is
good
I'm.
Promoting
a
couple
of
tools,
we're
using
path.
T
Spider
is
a
measurement
tool
for
testing
lots
of
different
hosts,
different
paths
through
the
network
and
gathering
some
big
mapping
of
what
is
actually
done.
That's
quite
useful
in
this,
and
we
want
that
data.
We
also
have
another
tool
called
path
trace
which
takes
a
particular
path
or
tries
to
figure
out
where
on
the
path,
something
happens
that
changes
the
packets
or
the
forwarding
behavior.
If
we
use
these
tools
together,
we
can
map
the
entire
of
the
Internet
and
figure
out
whether
everybody's
house
will
support
all
these
mechanisms,
and
we
can't
do
that.
T
We'll
have
to
do
a
smaller
measurement
campaign,
alas,
but
we'll
try
and
make
it
a
big
one
and
try
and
give
some
real
data
I
like
the
idea
of
doing
measurements
now,
and
we
did
some
measurements
already
and
yannick.
Do
you
want
to
and
say
which
one
was
your
probe?
My
probe
was
the
one
in
Aberdeen
yeah.
U
T
This
is
why
you
need
two
types
of
tool
wanted
to
figure
out.
What's
going
along
the
path
from
want
to
just
do
the
mapping
exercise
we're
going
to
work
with
some
people
and
figure
out
why
these
answers
are
here?
So
do
not
take
this
as
a
measurement
of
what
the
internet
supports.
Take
it
as
an
indication
that
we
can
do
good
work
in
this
space
and
it's
not
hopeless.
There
are
places
where
you
can
even
use
hop
by
hop
options
to
find
out
useful
stuff
could
be
cool,
and
this
is
a
some
reason
tip.
T
We
want
to
deploy
more
probes
and
you're.
Not.
There
was
only
like
three
columns
here
and
talk
to
us
if
you
like
these
measurements,
talk
to
us,
if
you
want
to
measure
paths,
we're
talking
just
about
sending
bigger
packets
once
we
have
the
probes,
we
can
test
other
things
that
happen
on
paths,
and
we
are
really
passionate
about
trying
to
measure
these
other
things.
But
you
do
have
to
have
some
prerequisites
to
join
our
measurement
activity
either.
T
Give
us
good
data,
which
is
always
welcome
or
offered
to
host
a
probe,
but
have
a
big
MTU
support,
so
we
can
probe
for
the
empty
you.
Another
ipv6
support
a
preferably
ipv6
extension
header
support.
So
we
can
actually
measure
extension,
headers
and
summary
and
doing
MTU
is
hard.
Actually
it's
not
hard
just
to
find
it
is
taking
a
long
long
time
to
get
here.
The
IETF
has
made
lots
of
bad
decisions
on
the
pathway.
We
believe
we're
now
making
the
right
decisions.
T
Unfortunately,
the
other
people
probably
thought
that
too,
but
yeah
I
think
we
are
it's
not
a
network
problem
unless
you're
talking
about
tunnels,
in
which
case
everything
is
completely
different.
Sorry,
it
is
a
transport
problem.
Unless
you're
talking
about
tunnels
are
the
only
thing
you
can.
Trust
is
your
own
probes
sent
by
your
own
endpoint
to
test
your
path,
but
you
can
get
lots
of
helpful
hints
from
other
devices
on
the
path
to
help.
You
know
how
to
build
those
probes
and
I.
Think
that's
where
we're
at
right.
U
R
T
E
T
T
We
have
a
picture,
I
did
or
did
we
I
think
we
took
the
picture
ID
to
the
slide
deck
to
slave
on
slide
eight
place,
it's
a
it's,
a
small
box
that
runs
Linux
and
looks
like
a
home
router
to
run
it
as
we
currently
have
it.
We
could
run
it
as
a
VM,
because
we
know
that
some
people
want
to
run
it
as
a
VM,
but
there
are
different
ways
of
measuring.
We
might
use
different
poles
for
different
things.
Okay,
thank
you.
Tell
us.
T
T
So
I've
got
to
take
you
for
a
little
bit
of
view
from
TCP
if
you're,
less
interested
in
TCP
or
just
in
multimedia
or
even
quick
or
something
then
there's
a
little
bit
of
stuff
later.
But
let's
learn
about
TCP
and
TCP
connections
have
a
use
for
two
parts
of
the
path
they
use
data
in
the
forward
part
of
the
path
on
other
control
signaling
and
they
receive
acts
in
the
return
part
of
the
path,
and
we
use
these
acts
to
control
the
speed
at
which
the
TCP
sender
works.
T
So
they
help
with
the
congestion
control
and
the
basic
rule
is
a
TCP
receiver
sends
an
ACK
for
every
two
MSS
of
data.
Read
two
packets,
that's
more
normal
except
not
quite
always.
We
send
it
at
every
segment
to
increase
the
Seawind
at
the
beginning
in
some
more
or
less
randomly
hard
to
express
way,
but
actually
works
quite
well
for
just
a
little
while,
and
we
also
use
them
whenever
there's
a
loss
and
to
make
sure
the
loss
information
gets
through.
And
then
you
have
an
asymmetric
path.
T
One
path
goes
in
one
way
or
another
path
comes
in
another
way.
They
might
actually
just
be
on
the
same
cable
as
the
two
directions
are
different
and
the
amount
of
acts
you
get
back
can
constrain
the
amount
of
data.
You
send
simple
reason
for
this
could
be
you
have
much
lower
bitrate
on
one
direction
and
higher
bitrate
on
the
other
direction.
T
The
high
bitrate
link
can't
be
used
because
it
fills
up
the
return
link
with
Ickes
and
TCP
doesn't
really
know
how
to
deal
with
this
there's
there's
bits
of
pieces,
but
most
people
have
deployed
boxes
on
the
path,
which
is
why
it's
interesting
here
that
help
you
and
the
first
is
an
easy
box.
You
simply
compress
the
data,
because
acts
are
quite
compressible.
Usually
you
can
press
them
away
using
heavy
to
compression
rock.
Does
this
works
well
used
widely
in
cellular
environments,
helps
a
lot
with
this
asymmetry
problem.
T
You
could
deploy
ax
thinning,
RSC,
34.9
again
a
little
bit
of
history
and
talks
about
act,
thinning
as
a
way
of
filtering
the
acts
that
are
necessary,
acts
accumulative.
You
can
get
rid
of
all
the
ones
you
don't
need
if
you're
smart
in
the
network
and
you
understand
which
which
which
acts
are
more
valuable
than
which,
whether
the
AK
is
cumulative
or
reordered
or
whatever
you
could
just
filter
them.
You
could
imagine.
T
Some
boxes
are
smarter
than
other
boxes,
and
some
boxes
are
really
smart
because
they
use
these
methods
called
compacting
compounding
and
expanding,
which
means
that
they
regenerate
the
act
clocking
in
some
way.
So
actually,
when
they
remove
the
acts,
they
kind
of
put
them
back
again,
which
all
seen
great
stuff
and
maybe
doesn't
fit
today.
T
Security
model
but
they've
seen
as
good
stuff
at
the
time
and
he's
still
widely
done
for
TCP,
there's
a
mere
more
stray
sitting
at
the
bottom,
which
is
really
cool
if
you're
doing
measurements,
which
is
the
acts
first
scheduling
scheme
which
says
that
acts
are
tiny
bits
of
data,
so
why
don't
put
them
at
the
front
of
the
queue?
So
if
you
have
accent
data,
then
just
shove
all
the
acts
to
the
front,
and
if
you
think
that's
amusing,
then
have
a
look
at
it.
T
If
you
don't
understand
the
issues
with
that,
then
think
it's
a
problem
but
they're
widely
deployed
these
methods
and
they
sit
on
the
path
they
deal
primarily
with
differences
in
capacity
capacity
is
a
big
issue,
always
was,
and
isn't
actually
the
biggest
issue.
The
biggest
issue
is,
when
you
have
a
radio
link,
if
you
have
a
radio
link
of
any
type
which
kind
of
you
know,
it's
just
many
types
of
links
we
actually
find
in
the
internet
that
it's
not
actually
the
volume
of
debt.
That's
the
problem.
T
The
problem
is
that
when
you
transmit
a
packet,
you
incur
a
certain
amount
of
resource
in
actually
sending
it
over
the
radio
link,
supporting
use,
different
technologies
or
different
configurations
on
the
return
link
to
the
uplink.
Every
AK
you
send
consumes
radio
resource,
it
may
be.
The
total
cost
of
a
sending
an
IKE
is
the
same
as
sending
a
data
packet,
so
you
could
spend
two
data
packets.
You
send
one
act
packet,
two
data
packets,
one
act
packet.
T
This
is
kind
of
disproportionate
using
one
third
of
your
radio
resource
for
sending
acts
not
good,
actually
much
worse
than
this,
because
the
radio
link
in
the
return,
Direction
is
often
contention
based
or
demand
assignment,
might
see
a
completely
different
technology,
completely
Radio
characteristics.
It
costs
more
to
send
accident
just
to
send
data.
T
Often
really
TCP
doesn't
know
about
all
this
mean,
and
so
people
deployed
act,
thinning
and
other
methods
to
solve
this
and
they
reduced
the
a
crate
rather
than
the
arc
volume
in
this
case,
and
it
really
has
a
big
effect
on
your
system
design.
That
doesn't
mean
your
network
runs
faster
or
slower
because
of
this,
what
it
affects
is
the
bottom-line
cost
for
the
person
providing
the
network.
So
if
you're
the
radio
operator,
the
ISP,
you
have
a
cost
and
this
reduces
your
cost,
which
probably
reduces
subscription
costs
for
the
service.
T
So
there
is
a
round
effect.
It
does
affect
the
user.
Okay,
all
the
background
done,
and
this
is
what
TCP
does
here's?
Do
you
lay
back
after
slow
start?
If
you
want
to
pretty
slide
of
it,
you
start
sending
lots
of
acts
thing
you
send
less
acts
and
it
works.
This
is
real
plot
and
next
slide,
and
what
about
quick,
aha,
quick
and
we
should
think
about
quick
because
quick,
let's
take
a
different
security
model.
T
If
you
were
smart,
you
would
realize
that
all
this
great
stuff,
that's
in
keeping
the
internet
afloat
for
years,
no
longer
works.
Well,
okay,
so
we
have
the
same
path,
but
the
path
is
different
because
we
use
quicken,
we
encrypt
the
acts
and
the
data
packets
was
quick.
Trying
to
do
it
tries
to
send,
according
to
the
current
spec
and
Ike,
every
two
packets
it
mimics
TCP.
So
actually
it's
just
in
how
did
the
same
problem
as
TCP
and
he's
got
an
act.
T
Delay
interval
it's
slightly
better
because
and
if
you've
got
a
they
lost,
then
he
only
acts
for
a
little
bit
of
time
and
then
it
realizes
you
don't
have
to
send
acts
continuously.
I
didn't
need
to
use
delay.
That's
after
saw
start,
because
that
was
a
TCP
thing,
but
the
basic
thing
is:
you
can't
use
any
of
these
performance
enhancing
devices
on
your
path,
even
though
they
might
have
been
really
simple
radio
layer
stuff.
They
still
don't
work
with
this.
So
what
is
TC?
T
What
does
it
look
like
when
you
use
quick
and
real
measurements
from
various
quick
stacks
sure
they
implement
the
spec
yeah
they're,
implementing
the
ITF
spec?
That's
great,
so
they
do
I
carry
two
packets
and
how
much
volume
updates
they
sent.
Oh,
it's
actually
worse
in
the
measurements
we've
done.
This
is
a
10
megabyte
down
Lord.
Yes,
it
is
Aksum
bytes
for
those
people
who
saw
his
presentation.
I
forgot
to
the
vertical
column
for
the
total
aggregate
of
traffic,
quick
sent
twice
as
many
bytes
as
TCP.
T
So
it's
the
protocol
itself
needs
less
Cemetery,
in
other
words,
the
ACT
traffic,
more
impacts,
quick
than
it
did
for
TCP.
Paths
that
are
asymmetric
will
have
bigger
problems
why
packets
are
smaller.
The
blue
part
is
the
easy
bit
and
TCP
packets
tend
to
be
a
little
bit
bigger
than
quick
packets.
Previous
talk
applies,
let's
do
this
stuff
and
get
the
packets
bigger,
because
the
overhead
is
significant.
T
The
red
part
on
the
Linux
stack
is
the
actual
access,
just
simple
TCP
segments
and
we
got
too
quick
and
we
find
the
combination
of
IP
and
transport
is
about
the
same
okay.
You
can
wiggle
in.
You
can
tell
me
that
the
crypto
stuff
Inc
quick,
could
have
been
done
in
TCP,
but
actually
it's
not
very
important
that,
in
terms
of
total
performance,
the
quick
acts
are
not
as
compact
as
the
TCP
acts.
T
Maybe
we
just
change
the
acting
policy
and
we
have
to
thinning
in
TCP.
So
we
can
do
this
in
quickly
and
said
one
lakh,
every
ten
segments
and
yeah
could
do
it.
People
have
talked
about
it.
Maybe
people
talk
about
it
more
in
the
IETF.
Maybe
we
can
fix
this.
Maybe
we
just
change
the
protocol
to
understand
the
path
this
is
with,
and
this
is
no
over
a
satellite
link
where
we
have
asymmetric
capacity,
also
asymmetric
radio
considerations
and
liking.
Every
two
packets
looks
like
this.
T
If
we
changed
like
every
10
packets,
lo
and
behold,
the
chord
we
have
seen
actually
being
people
using
just
works,
oh
well,
this
may
be
a
few
things
to
consider,
but
really-
and
we
can
change
the
behavior
to
it
with
this.
So
conclusion,
if
we
knew
the
past
capacity,
resources
had
a
symmetry,
we
could
know
what
to
do.
Is
it
a
great
signal
from
the
network?
No
I
tried
to
argue.
T
Actually
this
is
a
transport
problem,
so
a
cement
asymmetry
in
the
network,
I
think
is
not
a
great
thing
to
signal
because
you
don't
really
most
the
time
nor
what
path
you're
using
if
you're,
on
the
look
radio
link
yourself,
if
you
attach
it
to
a
Wi-Fi
or
direct
it
to
a
cellular
device.
Maybe
you
can
say
something
about
your
local
link.
T
So
this
one
isn't
a
greater
talk
here,
because
really
after
looking
at
it
all
we
find
out
is
not
a
lot.
The
path
can
help
with.
We
have
to
live
with
the
fact
that
path
is
asymmetric,
so
we
need
tools
to
know
how
asymmetric
it
is,
so
we
can
debug
it
because
one
of
the
things
I
need
to
know
are
somebody
using
this
network
is
whether
these
paths
are
symmetric.
H
H
H
I
think
that's
what
can
cause
this
as
well
as
the
radio
link
well
I'm,
talking
about
the
remembering
problems
that
adapt
yes
and
then
the
plane
flew
over
the
mountain
yeah
and
so
remembering
might
make
things
better
or
you
might
be
remembering
old
information
and
have
to
recover
from
that.
So
I
think
I
think
that,
like
I,
say,
I
think
this
is
terrific
and
I
think
this
is
terrifically
important.
This
is
directly
relevant
to
a
project
proposal
that
I
saw
in
an
IETF
working
group
within
the
past
three
days
and
surprise.
H
T
And
and
just
to
fill
up
what
Spencer
said:
if
we,
if
we
have
boxes
on
the
path,
we
might
have
various
things
chained
together
on
the
path
we
saw
that
earlier
that
it'd
be
nice
to
have
right,
good
tools
to
know
what
was
happening
here.
So
we
can
debug
this
stuff
at
a
higher
level.
You
know
you
can't
just
believe
things
happen
magically
at
the
higher
level.
You
need
to
have
tools
in
the
network
to
understand.
What's
going
on,
to
make
this
stuff
evolve
at
the
higher
level,
then
question
please
thank.
V
You
Tim
Costello
from
BT,
yes,
very
good
presentation
and
nice
results
in
there.
I
work
also
on
5g
standards
set
up
coming
from
their
issue
on
traffic,
steering
so
eighty
triple
s
we
call
it
over
there
and
which
uses
the
multipath
protocols
in
here.
So
your
path
can
change
mid
midst,
mid
anything
really
over
wireless
satellite
or
residual
band.
Have
you
got
consideration
of
that
in
here?
That
I
could
then
go
and
look
at
no.
T
T
V
F
Andrew
but
Gregor,
firstly,
I
think
the
common
thing
there
is
with
you
know,
memory
and
in
transports
and
so
forth.
Is
the
layers
below
transport
need
to
supply
signal
at
a
rate
that
is
tolerable
for
transport,
to
learn
what
is
going
on
and
transport
needs
to
be
mindful
of
its
own
learning
rate
and
so
effectively.
T
I
mean
the
interesting
things
there
might
be
under.
Aren't
ya,
yeah
I
know
I'm,
just
making
sure
people
know
the
first
thing
Andrew
is:
could
we
just
have
a
hot
signal
we
used
to
have
those
in
the
olden
days?
It
doesn't
necessarily
have
to
say
hey,
my
pop
asymmetry
has
changed,
and
it's
no
like
this
just
something's
changed
underneath
that
I
can
believe.
I
know
it
came
on
path.
Therefore,
I
can
trust
it
and
I.
T
W
Eric
Kinnear
just
to
note
about
the
something
has
changed
signal.
We
don't
do
anything
like
that
on
a
path
right
now,
but
at
least
within
a
client
device.
When
something
changes,
we
take
a
signal
and
we
say
hey.
We
should
probably
look
at
some
of
the
things
that
we're
currently
estimating
about
the
transport
that
we
have
and
not
necessarily
toss
everything
away,
but
but
be
much
more
aggressive
about
updating
to
the
fact
that
we
may
have
a
significantly
different
situation
than
we
did
a
second
ago.
That's
the
first
hop
signal,
an.
H
Dawkins,
okay,
you
know
kind
of
going
back
to
the
what
not
to
do
draft.
You
know
work
or
deep
in
the
territory
of
things
that
have
been
impediments
to
oh
man
of
the
past,
and
the
assertion
during
my
presentation
was
that
we
understood
the
issues
well
enough
to
do
engineering
so
for
people
to
be
thinking
about
about
that.
H
X
Necklace
cream
chunk
nice
I
have
two
small
questions
comments
at
first.
Are
we
sure
it's
because
of
a
symmetry
or
large
ITT?
To
what
extent
the
entity
has
an
impact
on
that?
Do
we
we
could?
We
can
do
measurements
together
if
you
want
I,
mean
I,
think
it's
or
even
to
experiment
the
same
characteristics
with
a
high
tea
tea,
but
no
asymmetry.
We
have
links
to
do
so.
Okay,
we
should
do
that,
and
so
there.
T
W
X
Thank
you
for
this
useful
information
and
also
on
you
mentioned
I'm.
A
second
point:
was
it
really
key
to
your
first
comment
on
what
you
do
at
the
client
level
at
the
moment,
and
there
are
things
that
are
done
in
specific
client
implementations
in
quick
and
that
are
not
clearly
exchanged
between
the
client
and
the
server
at
least.
X
Is
that
in
the
standard
today-
and
we
have
a
draft
in
quick
to
actually
exchange
information
between
clients
and
servers
that
the
XP
machines
you
have
on
the
path
on
one
path,
on
one
way
that
you
can
actually
use
and
measure
asymmetry
and
exchange
information
publicly
between
Canton's
not
publicly,
because
it's
still
within
the
quick
secure
the
years.
It's.
T
Y
T
T
Yeah
yeah
yeah
feedback
is
something
that
we
have
to
get
right
and
yeah
yeah.
Okay,
so
I
mean
that's
fun
and
I'm
so
pleased
that
people
started
asking
questions
here
and
I
think
that
there
are
follow-on
things.
We
could
work
on
so
happy
to
talk
about
that.
Using
the
research
group
mailing
list,
yeah.