►
From YouTube: PANRG Interim Meeting, 2020-06-03
Description
PANRG Interim Meeting, 2020-06-03
A
B
B
B
B
B
B
F
B
B
F
F
G
B
B
B
B
A
B
Issues
lights;
alright,
yes,
so
this
is
not
well
I
do
hope.
It's
the
right
one,
because
it's
the
same
one
Brian
present
at
last
time.
I
hope
you've
seen
that
before.
If
don't
please
check
it
out,
you
know
where
to
find
the
slides
right,
just
in
the
case,
they're
holding
signs
agenda
so
I
need
all
I
need
to
click
record
right.
I
guess
this
is
supposed
to
be
recorded.
A
B
Okay,
sir
its
virtue
interim-
please
please
excuse
me
I've,
never
done
that
before.
So
let
me
remind
you
some
special
things
about
Kevin's
virtual
meeting
I
was
told
that
you
having
difficulty
joining
the
audio
by
computer,
try
:
option
from
your
phone.
It's
recommended
to
have
your
video
off
unless
you
have
a
funny
hiatus
function.
A
B
You
speaking,
please
mute
your
microphone.
It
does
help.
The
decks
chat
is
only
to
join
the
Mike
Pihl.
Everything
else
should
go
to
the
jabber
room,
to
add
yourself
to
the
queue
press,
plus
cool
and
Brad
will
kindly
ID
you
to
argue
to
the
queue
and,
if
you
change
your
mind
and
do
not
want
to
talk
anymore,
please
put
a
minus
Q
in
the
chat.
A
B
B
C
B
F
B
F
F
B
J
B
Radio,
don't
be
surprised
that
you
do
not
see
a
pioneer
session
scheduled
during
virtual
idea,
and
we
have
three
doc
active
research
group
documents
we
are
going
to
discuss
today
and
the
number
of
encryption
presentations,
sir.
The
first
on
agenda
is
Brian,
but
I
do
like
me
to
open
the
browser
you
like
to
present
yourself.
Let.
F
H
B
F
E
F
You,
sir,
so
yeah.
So
this
is
the
ritual
discussion
of
current
open
questions
in
path
or
networking
draft
our
TFP
energy
question
zero.
Four,
where
I
asked
the
research
group
whether
or
not
we
should
present
this
and
then
I
get
either
the
answer.
Yes,
in
which
case
we
will
our
present
publish
this,
and
what
is
there?
I'll
even
get
the
answer.
Yes,
in
which
case
we
will
somehow
fail
to
publish
it
or
I
get
the
answer.
F
No,
in
which
case
we
will
can
keep
it
open
and
make
a
few
minor
changes
to
it
until
we
have
the
next.
One
of
these
meetings
were
asked
to
publish
it,
and
then
we
will
say
yes,
so
that
seems
to
be
the
ritual
that
we're
following
Jen.
If
you
could
scroll
down
to
the
the
diffs
in
the
in
the
table
of
contents,
there
are
no
actual
dips
in
the
table
of
contents.
Just
page
number
changes
I
just
wanted
to
bring
this
up
to
show
sort
of
what
we
think
the
questions
are.
F
So
there
are
eight
questions
we
think
are
open
having
to
do
with
vocabulary,
path,
properties,
how
you
distribute
them
supporting
path,
selection
and
so
on
and
so
forth.
After
the
last
time,
we
discussed
this
in
Singapore
I
got
some
feedback,
I
believe
from
Teresa,
but
I,
don't
remember
who
about
making
sure
that
the
language
and
vocabulary
of
path
properties
actually
covered?
The
types
of
things
were
thinking
about
in
that
vocabulary,
which
we'll
talk
about
a
little
bit
later.
So
if
you
can
scroll
down
to
the
diffs
and
2.1,
I
guess
it's
probably
better.
F
F
F
F
I
would
actually
ask
whether
we
can
go
ahead
and
say
we
have
research
group
consensus
out
on
the
list,
obviously
to
publish
this
as
a
snapshot
right
like
so
the
the
zero
three
revision
of
this
changed
open
questions
in
path,
aware,
networking
to
current
open
questions
and
path
where
networking
putting
a
time
stamp
on
it,
which
was
2019
since
the
questions
haven't
changed
since
then,
I
think
that's
reasonable
to
keep
that
timestamp
and
say:
okay,
we're
gonna,
take
the
snapshot
at
this
point
in
time,
and
then
maybe
you
know,
do
you
know
once
we've
done
a
little
bit
more
work
in
the
space
as
a
research
group
to
go
do
a
retrospective.
C
This
is
Spencer
and
I
would
I
would
just
say,
I
think
this
is
a
good
enough
list
of
research
questions
for
us
to
publish
to
help
guide
the
working
group
and
to
be
able
to
explain
to
people
who
might
not
be
participating.
It's
a
research
group
to
explain
to
people
who
might
not
be
participating
in
the
research
group.
Now
what
the
research
questions
are
so
I
think
I
would
I
I
think
you
could
be
through
I.
K
L
Haibach
I'm
scoring
here
and
I
wonder
whether
we
have
to
think
a
little
bit
about
defaults
of
what
we
think
is
normal
when
we
don't
have
a
signal
and
question
of
untangling
it,
but
it
seems
that
as
I
look
at
paths,
there's
always
some
assumption
about
what
you
think
is
a
normal
path
that
is
influencing
the
way
you're
using
it
or
your
design
above
it.
So
do
we
need
to
say
anything
about
this,
or
is
it
partly
implicit
in
answering
each
of
the
questions
as
we
go
through
I
would.
F
Personal
opinion
I
would
think
that
that's
a
detail
of
each
of
the
questions
and
it's
implicit
in
each
of
the
questions
that
you
need
to
have
reasonable
default,
because
it's
one
of
those
things
that
you
know.
We
don't
talk
a
lot
in
this
document
about
implement
ability,
because
we
think
that
implementable,
'ti
is
actually
one
of
those
things
that
needs
to
be.
You
know
kind
of
solved
on
its
own,
so
I
would
like.
F
L
F
Welcome,
although
I
noticed
that,
like
this
documents,
gonna
expire
relatively
soon,
so
actually
I,
might
that
point
about
implement
ability?
I'm,
add
a
sentence
about,
of
course,
if
it's
not
implementable,
it
won't
deploy
but
and
implementation
requires
sensible
defaults.
So
it
might
actually
add
a
sentence
based
on
that
comment,
whether
that's
before
or
after
we
send
it
to
a
research
group.
Last
call
I'll,
probably
wrap
the
document
just
to
make
sure
it
doesn't.
M
B
N
B
N
N
N
Sequence
of
logical
note:
for
example,
a
set
of
routers
contained
in
the
signal.
Yes,
it
can
be
specified
up
to
the
physical
or
link
layer,
technology
used
or
just
in
kind
of
logical
sense,
saying.
Well.
This
is
just
a
power
from
a
source
to
a
destination
kind
of,
in
the
way
that
current
internet
works
right,
you
have
a
source
destination
and
you
don't
know
anything
or
you
know
that
can
be
guarantees
for
anything
between
them.
N
I
N
N
N
We
reworked
a
use
case
section
so
here
we
mostly
did
structural
changes
and
textual
changes
for
the
past
election
with
its
own
small
textual
changes.
Then
we
remove
the
performance,
monitoring
and
enhancement
use
case,
since
it
seems
that
this
use
case
was
going
too
much
in
direction
of
internet
measurements,
actual
part
measurements
which
is
not.
Would
you
want
to
show
that
our
properties
are
useful
for
in
this?
In
this
draft
recovery
of
pad
properties?
O
N
N
We
decided
to
define
it
as
a
standalone
power
property,
which
is
the
definition
as
follows.
Oh
I
know
it's
transparent
with
respect
to
a
protocol
if
it
does
modify
this
protocol
and
your
pets
headers,
its
processing
is
independent
of
any
protocol
headers,
for
example,
an
IP
router,
typically.
N
To
transport
protocol
right,
while
and
network
I
will
select
translation
device,
looks
at
transport
protocol
headers
and
actively
modifies
them.
Another
examples
may
be
kind
of
a
firewall
which
doesn't
modify
the
transport
headers
or
contents,
but
it
still
looks
at
the
transport
tailor
Center
the
header
sent
them
to
decide
whether
to
block
or
not.
F
N
Which
simply
states
that
two
of
our
paths
are
symmetric
if
the
path
and
its
reverse
path
and
context
of
and
bi-directional
communication
consist
of
the
same
path,
elements
for
the
universe,
order
and
that's
next
slide
and
then
another
discussion
points
for
point
during
the
last
meeting
was
about
security
related
properties,
for
example,
confidentiality
or
integrity
and
I.
We
thought
about
this
and
we
think
we
decided
not
to
define.
N
N
The
reason
we're
not
sure
if
it's
a
good
idea
to
add
additional
properties
properties
right
now
is
that
it's
quite
difficult
to
characterize
its
properties.
You
need
to
consider
a
threat
model,
otherwise
they
don't
really
make
sense.
So
you
need
to
look
at
the
environment
entities
and
which
protocols
are
used.
What
is
ways
actually
use
case?
N
N
Establish
that
a
a
secure,
Channel
and
I
try
to
illustrate
this
with
these
two
pull
up
points,
so
you
say
that
half
properties
describe
what
function.
Work
applies
to
the
packets,
while
these
security
related
properties
describe
what
function
the
communicating
parties
applied
to
packets.
Well,
it
might
be
the
case
that
not
on
the
endpoints,
but
also
off
elements
that
they
are
communicating.
This
is
not
the
typical
case,
so
I
think
it's
enough.
It's.
N
N
F
L
N
Yes,
so
symmetric
paths
only
means
that
two
parts
which
are
still
independent
the
forward
and
the
backward
paths
that
they
automatic
in
the
terms
of
which
entities
they
traverses,
so
the
properties
could
be
completely
different.
This
is
just
to
talk
about
this
scenario
right.
It's
not.
We
don't
make
any
assumptions
that
is
paths,
food
or
or
must
be
symmetric
on
automatic
I.
L
Don't
know
whether
I
like
symmetric
puppets
yet
or
what
I
want
to
call
just
symmetric,
rooted
path
or
or
something
which
kind
of
clarifies
that
there's
no
symmetry
in
the
other
parameters.
Actually.
N
L
L
L
F
To
pick
on
slide,
five
I
was
actually
going
to
talk
about
the
so
first
of
all,
everything
Gauri
said:
I
was
going
to
mention
that,
on
the
symmetry
of
the
path
on
the
other
side,
there's
sort
of
transparency
I,
would
you
know
in
a
former
life.
I
did
a
whole
lot
of
work
on
stuff
that
we
called
path
transparency
and
we
defined
it
kind
of
like
this,
but
in
thinking
about
it,
I
would
have
made
it
a
little
bit
more
gray
than
that's
right.
F
E
F
Nodes
will
actually
pull
those
two
parts
out
right
like
so,
there
would
be
a
you
could
have
transparency
in
the
sense
of
it
might
actually
look
at
the
headers
without
changing
them,
which
will
have
certain
implications
for
the
types
of
protocols
you
can
use
on
that
path
and
then
there's
one
where
it
actually
will
try
to
change
the
headers,
in
which
case
it
has
other
implications
right.
So
I
would
think
that,
at
the
very
least,
transparency
would
be
sort
of
like
a
3
Way
as
opposed
to
a
boolean
hum.
F
N
F
For
example,
right
like
so
that
you
know
an
IP
level,
router
could
actually
look
at
the
IP
address,
but
it's
not
gonna
if
the
IP
address
changes
within
the
net
blocks.
If
that
router
is
gonna
put
down
that
that
that
path,
it's
actually
not
going
to
change
or
any
like.
So
it's
you
know
you
can
change
the
IP
address
and
if
it's
a
router
with
the
default
route,
it's
still
gonna
put
it
out
the
other
port,
whereas
if
it's
an
IP
address,
but
not
it's
also
rewriting,
which
you
no
changes.
F
The
semantics
of
those
address
spaces,
so
yeah
I
think
this
is.
This
is
a
again.
This
is
pretty
much
exactly
when
we
started
thinking
about
path,
transparency.
This
is
pretty
much
exactly
what
what
how
we
defined
it
as
well,
but
I
would
make
it
a
little
bit
more
nuanced.
Here,
thanks
Spencer
ease
next.
F
C
D
C
C
So
the
question
about
what
is
pet?
We're
networking
anyway,
I
got
this
call
more
than
a
couple
of
times,
especially
at
last
call
I've
seen
that
comment
on
other
paradox:
I
added
something
that
might
not
be
completely
wrong
in
euro-6
section
I
have
no
reason
to
believe
that
most
of
the
research
group
even
noticed
it,
and
the
draft
was
adopted
by
the
research
group.
So
that's
probably
not
good.
So,
let's
talk
about
what
path
aware.
Networking
actually
has
next
slide
please.
C
So
next
slide,
please
everyone,
please
step
away
from
the
mute
button.
Now
we'll
talk
about
this
in
a
minute.
I've
next
slide,
please.
So
the
questions
draft
has
some
description
of
path
or
the
path
we're
in
a
networking
architecture
that
talks
about
two
important
properties
and
what
that
is
and
there's
more
in
the
introduction.
But
you
kind
of
get
the
idea
you
can
like
I
say
you.
Could
you
could
check
that
out
on
the
for
revision
of
the
questions?
Draft
next
slide?
C
C
My
point
is
that
I'm
not
sure
we
have
a
canonical
definition
of
PAM.
Now
it
could
be
the
one
in
penalty
questions,
although
that
seemed
a
bit
more
about
architecture
than
pan
itself.
I
had
the
question
of
whether
we
needed
a
canonical
definition,
and
we
could
talk
about
that
on
the
penalty.
He
barely
lists.
If
we
need
what
it
would
be,
but
just
get
a
feedback
from
in
person
whether
this
is
helpful
or
not,
and
also
where
to
put
it
yeah.
C
What
not
to
do
is
a
horrible
place
for
it.
So
I'd
love
to
be
deferring
to
a
draft
that
is
not
bad
ideas
and
no
that's.
Alright.
I
would
like
to
defer
to
a
draft
that
is
not
about
ideas
that
didn't
receive
deployment.
The
path
properties
could
work
and
then
point
to
that,
but
maybe
there's
a
better
place,
but
we
can
talk
next
slide.
Please
so
I
thought,
let's
yeah
yeah,
that
that
one
absolutely.
F
K
Okay,
so
I
think
yes,
we
should
have
like
a
definition.
I
think
the
question
stressed
is
a
good
place
for
that's.
Why
I
linked
to
it
in
the
past
properties
draft,
but
it
should
probably
be
a
little
bit
expanded,
or
there
was
also
in
in
one
of
the
reviews
that
we
got
from
Matt
on
the
path
properties
draft
he
asked.
K
If
maybe
we
should
have
like
an
entire
architecture
draft
about
the
architectural
assumptions
that
we
made
in
the
properties
draft,
and
then
we
dialed
back
the
the
assumptions
a
little
bit,
but
still
there's
some
kind
of
like
architectural
understanding.
I,
don't
think
it's
enough
for
an
entire
draft,
so
I
think
it
might
go
in
the
questions.
Draft
I,
don't
think
it
goes
in
the
property's
draft.
C
F
Okay,
so
that's
me
then
follow
me.
Let
me
let
me
think
about
that
for
a
second
Tom
I
am
unmuted,
it's
new.
If
you
go
back
to
your
last
slide,
go
back
one
yeah.
Do
we
need
a
canonical
definition?
My
personal
take
on
this
is
no.
F
We
can
actually
make
the
canonical
definition
be
the
entire
text
of
the
questions
draft
right
like
so.
These
are
the
types
of
things
we
are
interested
in,
but
I
explicitly
don't
want
to
prejudice
any
sort
of
like
you
know
it
has
to
fit
into
this
particular
projection
of
this
particular
right
right.
We
have
architecture
in
order
to
be
in
order
to
fit
here
right.
F
I
understand
why,
like
reviewers,
would
be
confused
about
this
right
because
it's
like
this
is
amorphous,
and
it's
purposely
amorphous
I
think
the
idea
of
a
like
an
architecture
draft
makes
sense
only
to
the
extent
that
it
gives
people
who
really
really
want
to
have
an
architecture
draft
something
to
chew
on
I
think
it
should.
If
that
drafts
normative
language
is
longer
than
its
boilerplate,
then
that's
a
failure.
F
Whether
that
should
be
like
a
section
of
questions
just
to
avoid
having
to
take
another
graph
through
the
process
or
cuz
I
mean
lurk
layer,
it's
literally
like
a
paragraph
or
whether
it
should
be
in
you
know
its
own
one.
Paragraph
draft
I,
don't
really
have
an
opinion,
but
in
general
I
would
say
that,
like
that,
the
need
for
a
canonical
definition
or
the
need
for
a
a
prescriptive
architecture
for
towpath,
aware
networks
at
this
point
primarily
just
is
there
to
give
people
an
unsatisfying
answer
to
a
question
they
feel
like.
F
C
C
C
One
thing
that
we
could
do
is
have
the
two
of
us
chat
and
come
up
with
something
maybe
merged
out
of
what
I
had
which
what
I
had
I
should
have
said.
This
was
kind
of
taken
from
some
of
the
text
in
the
Charter,
so
for
you
and
me
to
come
up
with
a
proposal
put
it
in
the
questions.
Draft
and
I
can
and
I
can
point
to
the
questions
draft.
In
my
draft
that.
F
Seems
that
seems
perfectly
reasonable.
One
thing
I
wanted
to
say
that
I
forgot
before
I
started
on
my
my
thing.
There
is
basically
I,
don't
see
so
you're
pointing
out
that
we
have
three
definitions
that
differ
from
each
other
very
slightly
in
in
sort
of
their
wording
and
people
who
really
want
a
language
lawyer.
It
could
actually
see
that
that
that
implies
a
difference
in
scope.
I,
don't
I,
think
those
I
think
all
three
of
those
are
perfectly
perfectly
compatible
with
each
other
and
I.
F
Don't
think
that
there's
a
scope
problem,
but
that's,
maybe
because
I
purposefully
want
to
keep
this
amorphous
for
the
time
being
so
I
think
the
overlap
of
all
three
is
fine.
I
think
yeah,
it's
like
if
we
just
sit
down
and
try
to
be
awake
at
the
same
time,
for
like
a
couple
of
minutes,
maybe
bring
threes
in
zero
and
do
that
as
well,
which
makes
the
awakeness
slightly
like
two
times
difficult,
but
yeah
we
can.
We
can
deal
with
it,
I'm
good
at
I'm,
good
at
minus
nine.
It's.
C
Other
thing
I
wanted
to
mention
because
so
I
used
the
word
canonical.
Probably
in
advisedly,
that's
what
you
that's
what
you
would
want,
but
you're
supposed
to
say
that
when
I'm
wrong,
but
you
know
this
being
a
research
group-
things
that
don't
fit
the
canonical
definition
can
still
be
interesting
to
a
research
group.
K
C
F
L
That
could
be
and
that
I
have
something
to
say,
because
when
we
put
these
documents
in
TS
vwg
in
the
IETF,
there
are
always
people
come
and
try
and
beat
me
up
saying
that
transport,
sound
and
and
I
think
you
think
it's
important
to
have
some
text
that
kind
of
a
path.
Is
it
the
core
of
all
this
stuff
and
Spencers
texts
looked
okay
but
I
think
we
need
to
agree
on
some
words:
I
hate
it
text
word
the
or
D
before
something.
L
F
C
Was
empty
if
you
want
to
do
the
next
slide,
please
and
then
the
one
after
that,
so
I
think
we
know
what
to
do
with
that
question
about
the
generally.
What's
going
on
whole
definition,
so
that's
good!
Thank
you
all
for
your
help
with
that,
on
behalf
of
all
of
the
authors
and
charter
editors
and
could
I
get
two
more
slides
back.
You
can
skip
the
next
one.
K
C
Okay
yeah
this
one
here,
I've
mentioned
this
at
106,
but
the
the
goals
for
this
informational
draft
were
to
inform
research
in
this
research
group,
which
is
fine
that
it's
still
a
draft
in
the
research
group.
Research
outside
this
research
group
and
engineering
outside
this
research
group-
and
it
seems
to
me
that
we
need
to
publish
in
order
to
inform
activity
outside
the
research
group
that
that
that.
C
This
morning,
I'm
B
this
morning,
I'm
being
recruited
to
help
with
a
nether
buff
that
is
in
this
space
at
the
IETF
and
I
would
love
to
be
able
to
provide
information
to
engineering.
That's
happening
outside
this
research
research
group,
which
is
one
of
the
things
stable
things
I,
think
we
can
do
with
this
draft.
So
questions
are
we
finished
yet
and
if
not,
what
else
do
we
need
to
do?
F
F
C
C
B
F
Observe
we're
doing
pretty
good
on
time
right
now,
so
I
would
actually
say
that
if
we
end
up
at
the
end
of
this
with
any
time
available,
we
should
just
make
that
call
with
those
of
us
who
are
gonna
bang
out.
The
next
version
of
this
just
be
like
at
the
end
of
this
inner
meeting,
and
we
should
just
anyone
who
wants
to
be
part
of
that
discussion
should
just
stay
we're
already
all
here
in
a
wake
to
some
extent.
F
C
So
you
had
me
going
now:
nobody
said
I
was
awake
right,
but
some
the
other
thing
that
I
was
asking
to
talk
about,
and
this
is
not
something-
that's
gotten
a
lot
of
work
mailing
list
attention
yet
so
thank
you
all
for
putting
this
on
the
agenda,
but
whether
there
were
design
goals
for
path,
aware,
networking
which,
knowing
what
we're
generally
trying
to
do,
would
probably
help
that
idea.
Also
next
slide,
please.
C
So
if
so,
but
my
thing
is
basically
if
somebody
proposes
migrate
path
or
networking
approach,
how
do
we
know
it's
a
good
approach
that
maybe
we
should
have
design
goals
there?
We
have
the
idea
of
a
beautiful
baby
contest
where
you
line
up
all
the
beautiful
babies
and
see
which
one
is
the
most
beautiful
baby,
and
if
you
don't
agree
on
the
definition
of
beautiful
before
the
babies
arrive,
you
have
to
tell
people
that
their
babies
are
ugly.
C
That
seems
wrong
to
me
and
I
next
slide.
Please
so
question:
do
we
already
have
design
goals
for
panarchy?
We
learned
a
lot
and
what
not
to
do
in
section
2
and
section
3
number
one.
We
did
not
have
very
many
filters
for
adding
contributions
to
section
5
I
believe
the
only
filter
we
used
was
that
we
were
just.
We
were
including
protocols
that
had
gone
through
ITF
standardization,
at
least
part
of
the
way,
and
some
of
those
contributions
dated
back
to
the
1970s.
Some
of
the
goals
have
been
dumped,
the
entire.
C
So
if
people
wanted
to
jump
in
the
queue
for
that
in
a
minute
or
if
you
wanna
jump,
the
queue
now
afford
it,
a
discussion
about
that
in
a
minute
that
could
be
great,
and
it
seems
to
me
that
this
Magritte
on
design
goals
would
help
us
provide
a
document
on
what
to
do.
We've
been
asked
for
that
repeatedly
and
and.
C
Maybe
we
could
write
that
next
slide.
Please
I
wanted
to
talk
about
this
for
a
second,
because
this
was
a
little
bit
the
model
that
I
was
thinking
about
and
I
I
was
not
the
person
that
suggested
this,
but
someone
smarter
than
I
did.
Did
the
research
routing
group
came
up
with
a
design
goals
for
scalable
internet
routing
and
published
it
as
an
RFC,
which
was
they?
Can
he
tried
to
a
prioritized
list
of
design
goals
for
the
target
architecture?
They
started
with
19th
Steve
1958.
So
this
is
the
internet
architectural
principles.
C
C
Questions
is
something
like
that:
a
good
model.
It
seems
to
me
that
what
we're
trying
agreeing
or
what
we're
trying
to
accomplish
would
help
us.
We
won't
all
have
the
same
goals
and
no
other
goals,
and
this
is
different
from
rrg.
There's
only
one
internet
to
do
internet
routing
on,
but
there
could
be
lots
of
different
kinds
of
pans,
so
this
may
be
more
of
a
list
a
what
a
intersection
list
than
a
No.
C
B
F
So
I
am
actually
just
in
the
interest
of
fairness,
going
to
keep
my
position
in
the
queue
before
Theresa
this
time.
So
like
that
sound
of
the
skirling
in
the
background
is
those
of
us
who
didn't
see
your
slides
her
reading
62
27
as
fast
as
we
possibly
can,
and.
F
F
In
the
questions,
draft
right,
I
would
think
the
design
goals
for
a
path
aware
network
is
basically
you
need
to
solve
two
point,
two
and
two
point
three,
so
discovery,
distribution
and
trustworthiness
of
properties
and
way
to
do
path,
selection,
the
interfaces
for
path,
awareness
or
something
that
you
need
to
actually
deploy
it
like.
You
actually
need
to
be
able
to
write
programs
that
use
it
great
and
then
the
rest
of
them
are
kind
of
like
higher
order
order,
sort
of
requirements
to
get
it
deployed.
F
So
I
think
that
if
you
basically
take
question
2,
2
and
2
3
and
tear
them
apart,
that
turns
into
the
beginning
of
the
design
goals
for
for
path.
Aware
networking-
and
that
might
you
know
we
might
actually
want
to
have
that
as
a
support
document,
because
I
don't
want
to
stuff
design
goals
into
a
questions.
Draft
right.
F
Let
me
keep
talking
because
I
think
you're
gonna
disagree
with
the
next
thing,
I'm
gonna
say
so
I'm,
actually
looking
at
62,
27
and
to
some
extent
the
reasons
that
people
care
about
path
or
networking
are
some
of
the
design
goals
for
the
new
routing
architecture
as
well.
Right
like
so
the
one
of
the
paths
where
architectures
that
actually
seen
some
implementation
and
pilot
deployment
is
Scion
and
one
of
the
big
goals
of
Scion
is
routing
scalability
right,
like
so
actually
fixing
the
problem
of
needing
gigantic
piles
of
of.
F
Tkm
all
over
the
network
by
actually
pushing
that
to
the
edge
scalable
support
for
traffic
engineering,
so
endpoint
traffic
engineering
is
essentially
QLS
right
like
so
so.
The
difference
between
traffic
engineering
and
QoS
is
who's.
Making
the
decision-
and
that
is
a
also
like
a
a
a
Kegel
skills-
were
for
multihoming.
That's
also
a
Kegel
like
I
mean
we
could
almost
it.
F
You
know
how
much
of
the
design
goals
from
the
routing
area
from
when
was
62
27.
This
was
2011
a
decade
ago.
Basically,
design
calls
at
least
all
have
for
pan
RG
or
for
path.
We're
networking,
because
they're
the
same
problems
that
we
have
with
the
current
internet,
so
I
think
we
have
to
like.
We
don't.
F
Sort
of
implementation,
I'm
not
sure
about
deployment,
is
the
decoupling
location,
identification
with
Lisp
right
the
rest
of
it.
The
extent
to
the
extent
that
those
problems
are
solved.
Those
problems
are
solved
like
so
skeletal
support.
Permeability
is
all
the
architectures
outside
of
the
IETF
and
outside
of
the
Internet.
F
The
internet
protocol
stack,
so
I
would
use
62
27
a
little
bit,
as
you
know,
maybe
a
pattern
in
terms
if
it's
got
the
same
boilerplate
on
it
in
the
same
general
document
structure.
But
what
I
look
at
when
I
see
these
11
points
is
an
attempt
to
boil
the
ocean
and
we're
trying
to
do
the
same
thing
in
panner,
G
right.
It's
like.
Let's
change
this
space
of
architectures
that
we
can
deploy
in
the
Internet.
F
C
Let
me
let
me
wave
for
a
minute
and
I'm
not
going
to
disagree
with
you
much.
The
first
thing
I
was
going
to
say
was
here
you're
looking
at
the
you
were
looking
at
the
questions
and
the
questions,
draft
and
I
would
suggest
sprinkling
stuff
out
of
what
we
learned
in
section
2
and
section
3
out
of
what
not
to
do,
because,
because
there
there
are
vo
there
is
we
we
were
doing
work
there.
That
was
going
to
drive
the
things
that
we
still
need
to
do,
and
we
think
matter,
and
things
like
that.
C
C
C
F
F
We
know
what
not
to
do,
but
what
to
do
is
is
still
up
in
the
air,
but
I
think
that
actually
sort
of
like
sitting
down
and
trying
to
trying
to
tease
that
out
is
also
one
of
those
things
that
I
really
wish
that
we
could
actually
get
on
airplanes
and
get
in
a
room.
Because
that's
one
of
those
things
that,
like
an
actual
physical
whiteboard,
would
be
super
useful
for
you're.
F
Getting
loopy
so,
let's
Teresa
so.
K
K
C
C
This
is
not
the
same
as
the
pan
or
the
pan
problem
domain
is
not
constrained.
The
way
the
routing
research
group
don't
problem
domain
was
constrained,
yeah
I
mean
the
the
other
thing
was.
The
idea
is
that
this
is
at
least
theoretically
going
to
drive,
work
and
the
IETF
very
soon,
and
this
may
not
be,
as
this
may
not
be
as
under
the
gun,
as
the
routing
table
explosion
was.
G
G
C
G
C
F
C
C
C
M
M
M
What
are
the
benefits
to
the
applications
that
use
it
and
so
I
think
that
would
be
more
helpful
to
people
who
are
working
on
this
than
a
especially
an
ordered
list,
but
even
a
collected
list
of
goals
that
are
sometimes
don't
even
fit
well
into
the
same
puzzle
because
they're,
somewhat
orthogonal
or
we're
trying
to
approach
different
aspects
of
the
reason
you
want.
Pathaway
yeah.
C
F
F
L
L
L
It's
only
a
little
bit
about
path
away
and
networking,
because
at
the
moment
we're
not
quite
there
and
you'll
figure
that
out
as
we
go
through,
because
maybe
the
solution
is
Hathaway
networking
for
many
of
the
problems
we
have
I'm
gonna,
be
talking
about
paths
of
a
high
bandwidth.
Delay
product
particularly
pass
worthy
return
or
reverse
path
is
asymmetric,
so
it
is
different
to
the
forward
path.
L
I'm
missing
this
answer
sheet
analysis
and
part
of
a
set
of
data
we've
collected
using
a
testbed
looking
at
quick
with
quickly
chromium
and
some
performance
of
TCP
using
reno
right
next,
like
okay
and
basic
message,
is
forward.
Paths
are
not
the
same
as
return
paths
for
many
people
return.
Parson
are
all
the
same,
so
we're
going
to
focus
on
the
return
path
for
the
moment.
L
Different
types
of
return
path
have
different
properties.
Some
of
them
are
bit
congested.
In
other
words,
they
have
capacity
limits
or
some
form
of
contention
ratio
which
limits
the
capacity
by
time
of
day
or
other
users,
or
they
are
limited
by
the
packet
rate.
They
can
support.
Many
of
the
technologies
we
have
out
there
in
the
real
world
are
asymmetric
because
return
packets
actually
consume
a
lot
more
resource
than
forward
packets.
So
it's
important
to
look
at
this
stuff
next
slide
in
Spencer's
vein.
Let's
go
back
into
history
and
find
out
what
happened.
L
One
originally
used
three
percent
of
the
capacity
in
the
reverse
direction,
simply
for
carrying
acts,
and
everybody
agreed
that
was
far
too
much
so
TCP
acts
every
other
segment
always
recommended
to
work
every
other
segment
overhead
about
one
and
a
half
percent
of
the
traffic
devoted
to
Ike's.
Actually,
that's
too
much
for
many
deployed
in
futures
and
if
you
actually
do
analysis
of
network
traffic
you'll
find
that
stretch,
acts
are
common
with
one
like
every
three
or
one
like
every
four
packets.
L
Tcp
is
just
a
statement
if
they
can't
stay
to
the
art
alone
comes
quick,
quick
uses,
1200
byte
packets
and
you
can
see
immediately
in
comparison.
Quick
takes
a
lot
more
capacity
roughly
twice
as
much
as
TCP
and
quick
speed
specified
to
use
knack
for
every
two
oculus
two
packets,
or
it
confused
about
three
percent
of
the
return
capacity
and
much
more
than
one,
which
is
the
target
for
many
operators
could
be
due
to
the
fact
that
quick
uses
12
read
byte
packets.
So
what
I'm
saving
you
is
1500
bytes?
L
L
We
had
a
scenario
to
look
at
and
because
the
utah
sap
mailing
list
is
all
about
satellites.
We
use
the
quickforce
at
architecture
and
we
looked
at
a
number
of
scenarios
and
10
megabit
forward
with
a
2
megabit
return,
which
the
1
to
5
capacity,
asymmetry,
10
megabit
forward
with
a
point
1
return,
which
is
a
1
to
100
capacity,
err,
symmetry,
and
we
also
looked
at
15
megabits,
with
10
mega
return
and
50
megabits
with
0.5
megabit
return.
These
numbers
are
not
actually
that
uncommon.
L
Dsl
has
an
asymmetry
of
about
1
to
8
and
I.
Think
many
people
who
use
cable
modems,
perhaps
one
in
20
1
in
40
capacity,
is
cemetary.
This
sort
of
asymmetry
is
very
common,
both
in
the
satellite
world
and
outside
your
satellite
world.
An
act
thinning
is
a
commonly
deployed
method
used
in
all
of
these,
but
also
in
Wi-Fi
drivers.
Standard
Wi-Fi
drivers
that
you
see
for
Wi-Fi
chipsets
implement
a
form
of
active
inning.
So
next
slide.
Please.
L
Let's
have
a
look
at
how
this
generation
of
acts
in
TCP
is
affected
by
these
a
simmer
three
scenarios
that
are
just
proposed
so
looking
at
the
performance
of
TCP
with
a
10
megabit
forwards,
routes,
link
and
a
2,
megabit
reverse
direction
path,
and
you
can
fill
that
path
with
10
megabits
per
second
of
traffic
and
attacks.
You
can
shoot
percent
on
the
return
path
and
transmitting
just
acts
which
is
okay.
L
If
the
asymmetry
grows
for
1/5
just
say
a
100
which
the
10.1
scenario,
then
you
see
pedes
forward,
data
rate
becomes
limited
completely
by
the
amount
of
acts
that
can
be
returned
across
the
path
and
or
10
to
3
megabits
per
second,
with
a
1
to
1
and
wanted
to
default
for
TCP.
It
got
down
to
6
megabits,
it's
limited
by
this.
You
can
see.
This
is
the
motivation
for
active
thinning.
L
The
red
boxes
display
places
that
are
limited
by
the
return
rate
of
the
of
the
traffic
on
the
path,
the
amount,
the
capacity
consumed,
and
some
of
these
numbers
are
basis
for
concern,
and
the
packets
she's
carrying
acts
can
consume
quite
a
lot
of
capacity,
and
nowadays
we
tend
to
worry
about
capacity
in
the
return
direction.
Perhaps
more
than
we
used
to
people
are
doing
more
uploads
since
they're
working
at
home,
many
people
are
doing
like
we
are
they're
using
video
I
said
it.
L
Video
on
my
return
path
and
fitting
that
into
the
capacity
pool
is
creating
real
pressure
on
this
infrastructure,
as
currently
designed
is
not
helping
this
at
all
one
side,
yeah,
basically
too
much
at
traffic
and
is
not
helping
the
transport
protocol
pretty
squeezing
out
all
the
traffic
on
the
return
link-
and
this
is
a
real
problem.
Go
to
the
next
slide.
I'll
show
you
what
the
effect
is
on
the
traffic.
L
So
then
real
data,
real
real
test
in
chromium-
and
you
can
see
here
a
set
of
lines
that
show
the
packet
rate
on
the
vertical
axis
against
time
on
the
horizontal
axis.
I
will
look
first
at
the
blue
line,
which
is
chromium
using
the
a
pressure
one
to
two
I
can
see
that
it
grows
its
rate
exponentially
up
to
about
five
seconds
and
then
it
transmits
stable
e
filling
the
forward
capacity
of
the
link.
This
is
for
an
eight
point.
Five
one
point:
five
link,
so
eight
point:
five
megabits
forward.
L
If
you
keep
the
akrasia
wanted
to
as
specified
in
quick,
and
then
you
reduce
the
returned
capacity,
200
kilobits,
so
you
have
a
a
pasty
which
is
no
constraint
one
to
100
and
the
rate
they
significantly
reduce
ten
to
five
megabits.
In
this
case-
and
this
is
bbr
data,
if
you
know
bbr
you'll
recognize
the
they
rather
stable
response.
You'll
also
see
that
the
red
line
slopes
slightly
upwards
for
some
bizarre
reason,
which
maybe
you
could
explore
in
icc
and
ask
them
why?
Because
it
doesn't
seem
right,
but
it
is
the
way
bv
art
works.
L
What
happens
if
you
change
the
up
ratio?
If
you
change
the
arc
ratio,
quick
changes,
the
behavior
back
to
the
original,
the
black
line
is
almost
christened
with
the
blue
line.
The
path
is
completely
filled
by
the
return
path
or
this
traffic.
It's
so
stable
situation.
It
works.
Okay
and
the
default
lured
in
chromium
is
actually
to
do.
This
change
dynamically.
Moving
from
the
up
ratio
to
after
100
packets
down
to
the
up
ratio
of
10,
but
that's
not
what
the
idea
of
quick
working
groups
currently
picked
up
on
them.
Next
slide,
please!
L
This
is
the
result
with
Reno.
Maybe
you
thought
that
chromium
was
using
BB
R,
and
that
was
the
reason
why
it
worked
well.
It
certainly
worked
smoother
with
chromium,
but
even
if
we
just
look
at
Reno-
and
we
look
in
this
case
at
the
return
path,
you
can
see
that
the
axe
follow
more
or
less
you
would
expect.
L
Tcp
has
a
certain
number
of
acts
per
second,
quick
with
not
ratio
or
wanted
to
has
a
similar
number
of
acts
per
second,
which
is
what
you'd
expect.
However,
the
acts
are
bigger,
so
they
still
consume
what
capacity.
If
you
thin
TCP
acts
they
reduce,
and
if
you
use
not
ratio
one
to
ten,
then
you
get
a
performance
where
the
ratio
is
reduced,
of
course,
so
this
is
really
showing
what
you
would
expect
while
I'm
doing
this.
But
let's
look
at
some
other
type
of
data.
Next
slide
shows
the
results
for
book
downloads.
L
This
is
book
download
of
100
megabytes
of
data,
and
you
can
see
the
download
here
for
a
50
megabit
path
source
it
it's
using
a
higher
speed
forward
link
and
we
get
28
bits
per
second
cited
424.
Maybe
we
would
get
more
if
we
tuned
to
the
floor
control
more
here.
You
move
to
higher
asymmetry.
In
the
50.5
case,
you
can
see
that
the
capacity
is
being
limited.
The
forward
rate
has
reduced
and
therefore
the
time
to
complete
has
increased
an
overall
throughput
becomes
18
megabits,
rather
than
twenty
eight
megabits
the
same
message.
L
What's
on
the
path,
so
we
had
path
awareness
and
we
discovered
that
there
was
something
on
the
path
with
a
certain
rate
or
a
certain
capacity
limit.
We
could
adjust
our
transport
in
response
and
respond
to
that
I
mean
that's
a
good
thing
to
do,
and
that's
the
thing
that
we'd
love
to
see
emerge
from
path
awareness.
L
You
know
you
you
find
out
what's
on
your
path
and
you
adjust
to
it
unfortunately,
luxury
where
you
you
don't
have
at
the
moment
and
people
using
their
laptops
using
whatever
network
infrastructure
they
have,
and
they
don't
really
know
how
that's
operating
or
what
the
constraints
are.
So
the
transports
can't
think
this
out.
L
When
they
want
to
reduce
for
other
reasons,
there
are
other
reasons
why
you
might
want
to
change
the
ID
puttan,
and
these
are
purely
transport-
really
not
path
related,
for
instance,
to
use
the
interoperate
on
your
device,
your
server
device
or
because
you've
got
another
congestion
controller.
That's
you
know
doesn't
need
an
ACK
frequently.
Maybe
only
is
one
in
every
100
packets.
So
there
are
good
reasons
why
you
might
want
to
choose
very
big
at
ratios,
but
I
think
these
are
all
defined
by
the
transport
operations.
L
B
L
Act,
Rafi
is
still
a
lot
because
is
using
1/2
to
like
ratio.
What
happens
when
this
traffic
is
injected
on
the
paths
that
we've
been
speaking
about,
link
can't
see
inside
a
quick
packet?
It's
not
aware
of
the
contents,
because
it's
encrypted,
so
a
queue
builds
in
the
Rooter.
The
routes
becomes
congested
and
we
end
up
with
a
delay
under.
L
It
is
what
we
thrive
it,
and
so,
if
we
looked
at
the
delay,
we
see
the
delay
creeping
up
as
well,
and
the
solution
to
this
could
be
deploy
some
form
of
a
queuing
user
short
EQ
to
control
the
delay,
simply
resulting
higher
act
lost
and
due
to
reach
a
queuing
we'd.
Also,
some
non
act
frames
which
probably
will
have
some
impact
on
the
transport
in
this
case
wait.
But
it's
the
best
aru
can
do.
L
Perhaps
some
sort
of
fair
queuing
might
help
within
the
device
to
stop
you
deleting
packets
from
other
flows
that
really
disrupt
a
different
floor
causing
collateral
damage,
but
that
also
will
have
implications
for
queuing
is
not
without
its
own
costs
so
and
I'm
motivating
that
choosing
the
right
default
would
save
a
lot
of
mess.
If
you
don't
know
how
to
set
that
default,
because
you
don't
have
a
signal
from
the
path,
then
you
have
to
choose
a
number,
and
you
have
to
choose
that
number
wisely.
L
I'm
happy
to
take
questions
on
this.
We
have
a
number
of
slides
that
are
related
to
this
I'm.
Similar
topics.
I
would
be
talking
about
these
on
the
each
of
sub
mailing
list.
So
if
you
want
to
talk
a
lot
about
it,
please
and
join
that
mailing
list.
I'll
take
questions
now
and
be
happy
to
try
to
answer
them.
F
A
B
D
Quick
because
this
is
actually
a
follow-up
to
earlier
data
where
I
just
wanted
to
add
in
the
error
rate
measurements
next
base,
please
so
you
know,
the
problem
statement
is
similar
to
what
Corey
was
talking
about
for
different
reasons.
You
know
the
TCP
tears
for
protocols
don't
perform
well
over
high
latency
links,
particularly
with
the
BRIC
groups,
respect
to
error
recovery.
We
generally
have
always
used
TCP
spoofing
can't
do
that
with
any
encrypted
transport,
particularly.
E
D
Next
page,
so
we
set
out
to
try
to
measure
how
bad
the
performance
was.
This
is
with
Google,
quick,
because
that's
what's
a
bit,
you
know
what
we
see
in
our
network.
This
is
really
our
test
drive.
You
could
come
back
and
read
this
if
you
want
to
next
page
so
this
is,
there
was
so
test
setups,
one
where
we
went
through
an
equipment
to
test
a
path
with
pip
and
one
where
we
just
let
it
go
directly
through
and
our
quit
was
not
involved
to
compare.
D
So
basically,
this
gives
us
both
spoofed
in
non
spoof
TCP
as
part
of
the
comparison,
but
the
delay
it
added
in
both
cases
was
the
same.
Next
page
we
did
some
different
testing
variants.
You
know
two
versions
of
HDPE
and
one
gigabit
connection.
We
did
three
file
sizes
I'm
only
going
to
talk
about
one
of
them,
because
the
answers
were
essentially
consistent,
so
one
gigabyte
files
and
then
we
tried
three
different
packet
loss
rates.
We
actually
tried.
Four,
we
tried
10%
loss.
That
was
so
bad.
D
D
So
here
are
the
results.
You
know
with
no
packet
loss.
Spoofing
could
go
really
fast
on
our
250
mega
link,
HP
2.0
was
limited
by
by
by
the
chromium,
I
think,
and
so
originally
you
must.
This
is
what
my
last
presentation
was
about.
You
know
comparing
comparatively
quick,
which
is
you
can't
do
a
spoof
on
the
speed
is
slower
because
of
you
guys,
daily
and
then
latency,
but
a
particular
interest
for
right
now.
D
Why,
once
we
say
again,
as
you
know,
when
we
tried
to
pick
a
loss
rates,
you
can
see
that
that
the
packet
lost,
of
course,
as
expected,
reduces
the
throughput
for
all
three,
the
Pech
one
kind
of
compensates,
which
is
what
it's
designed
to
do
without
pepto.
It
starts
dropping
down
significantly
and,
of
course,
the
reason
being
that,
when
you
drop
something
you've
got
to
recover
it
with
this
and
then
delay.
D
D
D
F
So
you
know
in
the
quick
working
group
is
the
quick
working
group
is
doing
all
of
their
testing
based
on
sort
of
the
right
set
of
tables
here
right,
so
you
know
they
see:
hey,
there's
no
PAP,
because
we
don't
have
one
we're
not
going
to
implement
one.
We
do
better
than
TCP
with
no
PAP
on
this
ridiculous
link,
whereas
yeah
so
it'd
be
interesting.
I,
don't
know,
it'd
be
interesting
to
maybe
get
this
get
these
numbers
in
front
of
the
quick
working
group.
F
D
D
From
our
perspective,
of
course,
we
only
sell
satellite
network,
so
we
we
want
quick
to
be
what
we
want:
click
to
be
on
par
with
a
pepped
TCP,
that's
we're
coming
from,
and
so
basically
we
know
we
can
tap
quick.
So
we
want
to
improve
quick
to
get
up
to
these
numbers
and
the
key
part
being
of
course,
how
do
we
recover
from
errors?
But
I
agree
with
you
that
on
the
right
side,
I
mean
even
with
this
delay,
quic
is
still
outperforming
TCP.
What
you
don't
have
a.
L
D
That's
a
good
point
and
we
actually
are
in
the
process
of
staging
up
an
internet.
You
know
an
IETF
version
of
quick
with
an
h2o
server
and
getting
ready
to
redo
all
these
tests,
as
well
as
some
more
tests
related
to
smaller
interactive
traffic,
which
is
related
to
them.
The
next
topic
I
want
to
talk
about
which
classification
coming
up
in
a
couple
presentations,
but
yes,
we're
definitely
continuously
testing
this.
F
C
D
C
C
C
C
P
So
this
Toki,
you
thing
picked
and
the
one
that
was
addressed
just
now.
It
is
just
date
on
the
thing
we
had
experience
on
what
is
a
satellite
past
and
what
is
the
problem
we
have
is
quicken
in
this
case.
Oh
I
think,
and
you
can
go
to
the
next
slide.
The
next
slide
is
actual
exact,
the
same
one
than
the
one
and
plenty
in
previous
IETF
meeting.
The
point
here
is
saying
that
the
satellite
is
very
strange
network,
but
it's
just
one
part
of
the
very
strange
racing.
If
you
would
next
slide.
P
Basically,
when
you
we
have
included
using
satellite
satellite
axises,
we
have.
If
we
look
at,
we
have
first
the
internet
on
the
left,
which
is
a
very
high
data
rate
and
low
latency
and
low
losses.
Then
on
the
satellite
is
P
networks.
We
have
a
high
data
rate,
but
then
now
we
have
more
congestion
losses.
P
The
satellite
access
network
on
its
own
shows
very
variable
at
a
rate,
no
losses
unless
you
are
on
very
heavy
heavy
rain
in
India
and
some
freaking
specific
frequencies
and
but
threatened
C
is
high
here
and
then
on
the
local
area
network.
We
have
an
average
data
rate,
but
now
we
also
have
losses
that
can
occur
on
my
Wi-Fi
link.
P
So
if
you
go
to
the
next
slide,
when
we
have
an
end-to-end
fourth,
the
third
path
that
were
mentioned
in
the
vocabulary
document
are
very
important
because
we
have
here,
four
sub
passes
with
very
different
characteristics,
but
our
reality
with
quake
is
that
I
will
end
to
end
and
is
variable
data
rate
hydrants
and
congestion
and
Wi-Fi
losses
for
Thor,
for
these
kind
of
things
very
complexed
for
earth
to
fee
how
we
can
actually
have
relevant
end-to-end
protocols
when
local
breakout
is
not
possible.
P
P
So
I
think
you
can
go
to
the
next
slide
or
even
I.
Don't
have
lots
of
time.
I
met
very
wordy,
slides
because
I'm
wasn't
sure
my
audio
or
anything
was
working
so
and
if
you
can
go
to
this-
or
these
are
the
basically
the
scenarios
that
we
are
considering
in
the
draft
for
fan
colonization
or
for
our
tests
between
Aberdeen
us
and
ourselves.
So
basically,
what
I
will
show
here
is
some
results.
P
One
is
end
to
end
without
split,
so
it
will
be
green,
so
we
have
been
using
pick
a
quick
servers
or
H
2,
h2o
servers
and
then
on
the
plant
side.
We
have
pick
a
quick
or
curl,
and
we
compare
that
with
different
flavors
of
pet
cell,
which
is
an
open
source,
CP
proxy,
and
so
we
have
I
prefer
ease
and
type
of
clients
and
we
have
losses
between
the
Petzl
and
the
client.
P
We
have
different
configuration
of
pet
to
see
the
problem
we
have
been
experiencing
and
to
see
to
what
extent
we
can
tune
the
pet
though
I
will
not
have
time
to
go
through
all
the
results.
But
if
you
go
to
the
next
slide,
basically
this
is
the
case
where
we
have
same
case
and
Gauri
showed
earlier
when
we
have
50
Meg,
download
and
10
megabits
upload
what
we
got.
P
What
we
can
see
here
on
so
I
already
have
this
kind
of
representation,
and
we
have
the
received
right
on
the
first
fear,
and
second
figure
is
a
received
data,
so
we
can
see
that.
Are
we
not
goes
through
the
different
specifics
of
all
the
path
I'm
available?
If
you
want
to
discuss
about
these
results
afterwards,
I
have
more
comedy
days
on
understand
the
results,
but
what
we
can
see
is
when
we
change
the
buffer
sizes
on
the
rtcp
boxes.
P
We
can
reach
very
high
GDP,
otherwise,
even
default
tcp
is
not
always
a
bought
for
the
high
GDP
of
the
network
and
if
TCP
proxies,
let
us
have
some
Chiefs
for
the
transmission
time
of
different
file
sizes.
So
what
we
have
done,
if
you
go
to
the
next
slide,
is
looking
what
happens
when
we
take
a
pic
of
a
server
and
a
bigger
click,
client
or
taken
h2
whole
favor
and
pick
up
a
client
and
vice
versa.
The
idea
was
to
see
first,
what
is
the
impact
of
the?
P
What
are
the
performances
of
when
you
choose
one,
quite
one,
quick
with
several
valve
version
and
another
quick
client,
because
sometimes
when
we
see
evaluations
of
performances,
we
have
the
same
flavor
of
different
implementations.
So
we
wanted
to
see
how
this
impacts
our
end-to-end
performances
in
these
use
cases.
P
What
well?
One
of
the
first
thing
we
can
see
on
the
figure
on
the
left
with
Pico,
quick
client
is
that
we
don't
have
any
results
for
the
hundred
megabytes
when
we
have
h2
whole
server
and
pickle
client,
and
basically,
we
had
a
problem.
We
just
take
default
parameters
of
the
different
implementations
and
we
had
too
many
other
transmissions
of
one
packet.
So
we
had
a
disconnect.
So
here
we
can
see
that
the
fact
that
Pico,
quick
server
manages
the
maximum
act
delay
and
actually
a
component
of
the
power
of
the
peacock.
P
Another
thing
when
we
compare
the
different
quick,
always
does
better
than
h2
hole
servers
and
that's
because
it's
using
PPR,
and
so
we
tried
to
see
what
happens
when
we
choose
Reno
in
Pico
quick,
and
we
still
had
lots
of
much
better
performances.
So
the
thing
is
the
Havel.
If
you
even
within
the
details,
we
could
see
that
at
least
some
transport
parameters
are
different,
such
as
congestion,
initial
condition
window,
but
not
very
different
and
the
English
or
a
TT.
P
If
you
go
to
the
next
slide,
here's
another
opposition
or
what,
when
we
see
what
happens
better
and
basically
we
see
the
amount
of
that
I
received
with
Pico
quickly
and
Oracle
client.
What
we
can
see
here
is
that
Pico
quick.
If
you
only
want
to
actually
meet
the
same
performances
and
the
one
we
have
when
we
have
a
TCP
proxy.
The
good
thing
is,
if
you
have
pick
a
quick
client,
Antigo,
quick
favor,
and
you
can
actually
reach
the
performances
of
the
tcp,
pipette
and
splitted
approach
of
satellite
networks.
P
P
If
you
go
to
the
next
slide,
that
means
thing
means
why'd.
We
go
quick
meets
objectives.
Basically,
it's
because
it
doesn't
follow.
The
standard
here
are
a
list
of
the
different
permit
relation.
You
can
see
that
one
of
the
main
difference
is
in
the
congestion
control
that
is
different
between
Pico,
quick
service
and
h2o
servers,
and
so
we
are
actually
working
on
to
see
what
are
the
relevant
parameters
and
what
parameters
are
again
changers
but
to
go
back
to
what
Gauri
presented
earlier.
P
If
you
go
to
the
slide
15mm
another
thing
that
people
quit
does
not
as
default
today
and
is
the
acknowledgement
strategy
where,
basically,
if
you
look
at
what
we
show
here
is
the
amount
of
data
that
is
sent
by
the
quick
client
or
the
kuroh
client.
What
we
can
see
is
that
quick,
peek
aqua
client
tends
to
actually
increase
is
very
quickly
the
amount
of
data
that
is
sent
in
the
acknowledgement.
So
there
is
some
strange
ACK
coalescing
algorithm
in
Pico,
quick.
P
Basically,
the
acknowledgement
ratio
is
not
constant
through
how
the
whole
communication
this
kind
of
things
I'm
not
really
sure
now,
but
this
is
to
show
that
there
are
very
important
interactions
between
what
could
happen
between
a
server
and
what
collab
and
client,
and
the
next
slide
is
my
last
slide
on
what
we
are
going
to
do
next.
So,
as
I
said,
we
are
working
on
to
see
what
other
show
relevant
parameters
for
the
satellite
use
cases
and
we
are
going
to
implement
the
zero
attitude
rafts
that
we
have.
P
We
want
to
see
if
the
iPhone
thing
that
I
implemented
in
bigger,
quick
that
are
relevant
for
everyone
and
that
should
be
included
in
the
standard
and
not
only
for
our
specific
satellite
use
case
and
I
think
that
the
act
of
management
as
Gauri
showed
is
very
one
of
the
way
to
do
that.
Another
thing
we
have
is.
P
Basically,
the
all
that
is
ready
to
the
flow
control.
One
other
thing
I
didn't
mention
here
is
what
very
matters
to
us
and
I.
Think
to
the
past
aware
network
with
a
group
is
the
management
of
sub
passes
with
very
different
characteristics,
and
when
we
have
losses,
this
impacts
a
lot.
So
in
quick,
we
are
working
at
the
moment
on
adding
coding
in
quick,
efficient,
quick
or
quick
proxies,
or
all
the
approach
that
we
can
have
to
be
adapted
to
that.
Okay,
and
so
we
are
at
the
moment,
have
two
implementations.
P
We
are
working
on
making
something
quite
flexible
and
making
every
available
21
to
have
some
sort
of
fabric
with
which
you
could
try
easily
any
quick
implementation
over
different
use
cases.
So
we
want
to
make
all
the
coal
we
have
Pune.
We
have
been
using
available.
Sorry
if
I
was
quick
but
I.
Don't
have
didn't,
have
much
time
and
I'm
here.
If
you
have
any
question.
A
C
But
but
but
my
my
think
was
just
to
be
very
very
brief,
and
so
thank
you
guys
for
bringing
this
information.
You
know,
although
all
people
are
bringing
satellite
information
in
to
panarchy,
which
is
very
important
and
I,
think
that's
where
the
love
of
the
satellite
stuff
belongs
right
now,
but
thank
you
thank
you
for
doing
that.
I
know
you're,
not
everybody's,
getting
a
lot
of
feedback,
but
you
can
hear
our
brains
chugging
out
here.
If
you
get
close.
Thank
you.
I
C
I
I
P
O
B
B
O
Yeah,
that's
the
one,
so
I
just
want
to
point
out
a
couple
of
things
that
first
broadly
speaking,
it's
not
that
because
not
following
in
the
spec
spec
requires
a
minimum
of
80.
Bytes
doesn't
doesn't
limit
how
large
you
can
send
them.
H2O
right
now
matches
whatever
the
client
uses
for
the
max
packet
size.
So
if
you
use
an
h2
a
server
and
a
curve
line
that
uses
1350
bytes,
for
example,
then
a
server
will
use
the
in
20
bytes
because
it
might
be
fixing
it
at
a
high
value
there.
O
This
is
just
an
example
of
some
difference
in
implementations
that
you
are
likely
to
see
going
forward.
The
question
I
would
encourage
you
to
consider
is
whether
these?
What
the
cost
of
doing
these
things
is
I
mean
you
can
choose
the
maximum
packet
size.
That's
9000!
Bytes!
If
you
want,
the
problem
is
going
to
be,
it
won't
work.
O
Well,
you
don't
have
a
9000
valentĂn,
so
a
lot
of
the
implementations
are
making
choices
that
allow
them
to
work
for
most
of
the
paths
on
the
Internet
and
I
would
encourage
you
to
think
about
how
to
make
endpoints
work.
Well,
given
that
they
also
have
to
work
on
other
paths
that
are
not
satellite,
the
same
holds
true
for
the
condition
controller
as
well.
O
The
point
here
is
to
try
and
understand
whether
I
would
suggest
that
you
might
want
to
look
at
what
the
congestion
controls
are
actually
doing,
then
consider
how
they
would
work
on
the
public
Internet
as
well,
and
this
is
just
a
broad
comment.
All
of
these
evaluations
are
wonderful
to
see
how
these
I'm
happy
to
talk
about
the
h2
implementation.
It's
moving
rapidly.
O
Just
even
a
month
ago
would
be
quite
different,
so
I
would
encourage
you
to
to
keep
looking
at
the
performance
and
also
keep
publishing
the
date
that
you
took
the
cord
or
the
commit
number
that
you
the
commit
hash
that
you
used
for
these
servers.
A
final
comment
in
general:
we
don't
expect
right
now.
The
quick
end
points
don't
really
have
any
way
to
communicate
to
the
network,
any
things
and
the
record
doesn't
have
a
way
to
coming.
O
It
is
the
quick
end
points
at
their
satellite
networks
in,
in
all
of
these
cases,
I
think
it's
useful
and
valuable
to
look
at
how
endpoint
behavior
can
be
changed
so
that
it
works
well
for
starters
networks
and
for
other
networks,
I
mean
whatever
changes.
If
we
simply
treat
the
endpoints
to
work
really
well
for
satellite
networks,
that's
not
going
to
be
that's
not
going
to
be
very
useful
because,
as
the
deployment
I
can't
simply
kill
my
server
to
use
measures
that
are
great
for
satellite
networks,
because
I
don't
know
when
my
traffic
is.
D
Say
I
agree
with
what
your
honor
said
at
the
end,
there
I
mean
I've,
always
viewed
it
as
the
defaults
can't
be
friendly
and
satellite.
What
you
need
is
to
be
able
to
figure
it
out
automatically.
You
can't
require
the
end-users
to
figure
it
out
to
do
it
at
week.
So
that's
the
key
thing
is:
we
need
to
have
mechanisms
to
dynamically,
determine
that's
that.
That's
the
situation.
P
If
I
may,
thank
you
for
the
comment,
I
just
wanted
to
say
that
I
understand
the
cost
of
deploying
these
things.
For
the
general
use
case,
you
just
don't
have
the
I
don't
have
the
data
for
that
I
can
share
the
lid
I
have
and
thank
you
for
or
if
I
know,
that,
reading
the
perfect
idea
that
we
were
can
be
costly
on
data
centers.
P
We
are
truly
also
working
on
adapting
endpoints,
seeing
what
we
can
do
on
the
endpoints.
That's
one
of
the
things
we
will
investigate
and
for
you
comment
on
the
commits
version
of
the
code.
We
will
do
that
in
the
future
and
also
try
to
make
our
code
everything
we
do
to
occur
straight.
Our
tests.
Everything
is
open-source,
but
we
just
don't
have
made
it
perfect.
Yet
so
I
want
to
make
that
Taurus
that
anyone
can
you
true
actually
also
with
different
comets,
and
thank
you
very
much
for
your
time.
C
D
Okay,
put
this
together
to
sort
of
get
some
new
discussion
going
on
another
problem
that
we
care
about
a
lot
which
is
classifications
next
page,
please
so
I'm,
not
gonna
read
the
Wikipedia
thing,
but
basically
you
know,
classification
largely
depends
on
transport,
headers
and
application
headers.
It
has
traditionally
done
so,
and
you
know
port
numbers
being
the
primary
things
next
page
for
network
operators.
You
know,
traffic
classification
is
very
important
for
meeting
customer
service
expectations.
Chris.
My
experience
is
satellite,
but
I
believe
this
to
be
true,
elsewhere,
concise
in
the
symmetric
castes.
D
D
Mile,
because
network,
where
your
user
is
connected,
is
usually
the
one
that
needs
to
classification
the
most,
because
it's
the
end
last
hop,
and
it
probably
is
it
probably-
is
the
constraining
Network
besides
prioritizing
over
the
interactive
traffic
over
background,
for
example,
their
device
such
as
a
satellite
terminal
ax.
He
may
have
multiple
paths.
So
that's
another
thing.
You
know,
for
example,
if
there
is
a
LTE
path
and
a
signle
path,
you
want
to
be
able
to
classify
and
decide
which
types
us
in
which
path,
because
this
second
path
is
in
the
terminal.
D
D
Obviously,
for
a
subscription
encryption
is
making
this
hard
to
do.
That's
a
good
thing,
we're
not
objecting
to
that
all
we.
You
know
we,
there
techniques
like
the
packet
inspection,
DNS,
correlation,
S&I,
etc,
still
classify
traffic
when
we
can't
see
the
headers,
but
unfortunately
anything
we
can
do
to
classify
an
attacker
can
do.
For
other
reasons.
D
So
the
questions
I'm
trying
to
get
discussion
going
on
is,
can
the
end
users
device
signal
the
network.
This
is
not
the
first
time
this
questions
come
up.
It's
come
up
for
many
reasons
so
that
we
can
get
classification
information
to
that
first
file,
device
that
it
can
use
to
get
across
the
first
network,
but
in
such
a
way
that
then,
that
information
doesn't
propagate
farther
than
that
and
leak
or
minimize.
This
is
about
privacy,
information
that
it
gives
out.
D
You
know:
TSE
peas
are
a
natural
option,
but
I
think
this
is
even
in
the
in
Spencer's
document.
You
know,
there's
the
age-old
problem
of
how
do
you
trust
the
source,
although
I
think
the
world's
changing,
and
maybe
that
question
could
be
re-examined
when
the
users
talking
about
its
own
traffic
and
you
were
like
yeah
I've,
been
playing
around
with
what
haven't
had
time
to
write
the
raffia.
D
D
All
it
has
x-ray
in
it
is
lets
me
see
that
the
NCP's
or
whatever
enough
information
they
classify
a
lot
the
work
you
have
to
go
into
making
that
happen
right,
but
that's
kind
of
the
idea.
Next
page,
so
you
know
I
I
wanted
to
get
some
discussion
going
on
it.
We
we
really
care
about
this
problem.
We
you
know
and-
and
we
think
it's
gonna
come
more
and
more
important,
especially
when
quickstarts
really
getting
out
there,
and
you
know
the
key
question,
but
not
the
only
one
is.
D
L
I
mean,
but
thanks
John,
no
I
haven't
really
read
that
one
through
before
that.
This
is
an
interesting
proposal
and
please
read
my
draft
in
TS
vwg
on
encryption
and
comment.
I
would
love
to
join
you
in
exploring
this
I
think
this
is
an
interesting
problem
that
where
we
can
make
some
real
inroads,
your.
D
Document
was
actually
the
one
of
the
ones.
I
was
thinking
of
this
time,
because
actually
definitely
already
come
up
before
I
was
you
know
in
terms
I
was
trying
to
tie
it
in
here
it's
like
well.
Can
we
make
the
path
aware
of
the
classification
it's
kind
of
in
question
right
without
you
know
just
enough
to
make
use
of
it?
That's
a
part
of
the
network
where
it's
needed
and
then
drop.
It
wins
for
the
rest
of
the
network,
where
you
don't
need
it
do.
D
C
F
D
J
So
that
in
the
privacy
has
been
sin,
the
pair
of
you
group,
we
are
there's
a
particular
draft
floating
around
that
looks
at
traffic
analysis
and
website
fingerprinting
in
general,
which
is
sort
of
this
classification
problem
that
you
speak
of
and
surveys,
basically
the
relevant
research
that
we
could
find
talking
about
how
easy
or
it
or
not.
It
is
to
do
this
in
practice.
Most
of
it
is
focused
on
things
like
Torah
flows
like
tour,
just
because
that's
where
privacy
nominee
is
most
important,
but
of
course
the
the
techniques
also
apply
elsewhere.
Q
Q
F
Myself
in
the
in
the
queue
as
well
one
to
kind
of
point
you
in
the
direction
of
of
of
peer
as
well
I
think
there's
also
just
I,
don't
I'm
not
as
active
in
this
space
as
I
was
saying
about
ten
years
ago,
but
I
know
that
there
was,
if
you
look
at
the
at
least
the
marketing
in
security
traffic
analysis
right,
like
so
so.
F
Enterprise
systems
for
doing
outbound,
a
sort
of
exclusion
analysis
as
well
as
intrusion
analysis,
a
lot
of
that
marketing
in
the
past
five
years
is
gone
in
the
direction
away
from
the
direction
of
signature
based
traffic
analysis.
Like
basically
saying
this
is
a
good
packet
versus
this
is
a
bad
packer.
There's
a
good
flow
versus
a
bad
flow
based
on
on
matching
like
known
malware
characteristics
and
has
moved
toward
I
mean
all
that
in
the
marketing
is
called
AI
right
like
so.
F
F
Understanding
that
you
know
the
efficiency
of
a
network
is
bounded
by
how
much
bandwidth
you
use
for
a
given
information
exchange
and
how
much
latency
you're
willing
to
tolerate.
So
your
traffic's
gonna
push
you
very
as
close
as
it
can
possibly
to
the
the
bottom
of
the
bandwidth
and
latency
consumption
windows,
and
that
basically
means
that
the
traffic
is
going
to
have
certain
characteristics,
just
the
inter
arrival
times
so
I
think
there's
a
lot
of
people
who
don't
show
up
here
who
are
in
that
security
space.
F
Some
of
them
are
hiding
behind
marketing,
which
is
his
marketing,
and
some
of
them
might
actually
have
a
traffic
classification.
That
would
be
more
than
good
enough
for
the
type
of
first
mile
signaling
that
would
be
here
so
I,
don't
know
how
to
get
them
to
engage
here
or
how
to
get
them
to
engage
with
with
sort
of
like
you
know.
How
can
we
use
these
technologies
to
make
transport
work
without
having
to
look
at
the
payload,
but
I
think
there's
definitely
work
that
can
be
used
in
this
pace.
D
F
F
J
Yeah
just
to
follow
up
on
that
point,
I
I
do
think
you're
gonna
see
more
pushes
in
that
direction
in
the
future
particular
actually
making
use
of
the
padding
mechanisms
that
were
built
into
cos
1.3
and
into
quick
and
even
a
ch3
3,
an
HB
2.
So
I
can't
comment
on
like
how
painful
it's
going
to
make
life
for
people,
but
it
was
likely
gonna
happen.
O
Quickly,
I
was
going
to
second
what
Chris
said.
There's
a
lot
of
moment
in
that
direction
in
general
and
I.
Think
a
lot
of
these
classifiers
that
we're
talking
about
also
still
use
things
that
are
exposed
right
now,
such
as
sni,
to
make
a
lot
of
conclusions
about
the
traffic
that
they
seen
and
a
lot
of
the
engender
and
the
community
is
towards
hiding
that
information
as
well
so
going
forward,
while
the
classification
might
be
effective.
Now.
The
hope
is
that
it's
not
as
effective
going
into
the
future.
O
B
E
Thank
you
is
it
pom
from
China
move
out
and
I'm
glad
to
introduce
my
work
out
avian
and
some
considerations
out
pen,
and
they
are
legal
same
in
the
name,
and
we
have
some
connections
of
difference.
That's
why
I
want
to
have
the
press
and
explanation
about
it.
I
hope
it
will
give
some
help
or
be
available
to
our
group.
So
I
will
introduce
these
two
aspects.
Next,
space.
E
Okay,
first
part,
is
about
even
pn6
the
motivations
of
a
being
six
that
new
applications
put
forward.
Haggar
comments
of
network
and
the
network
operators
need
to
be
able
to
provide
fine
and
granularity
and
even
application
level
as
a
grantee
to
achieve
better
quality
of
expert
experience
for
the
users,
for
example,
5
g
and
the
verticals
generates
more
and
more
applications
with
diverse
network
requirements
and
revenue
producing
apps
such
as
online
gaming
live
video
streaming
and
much
more
demanding
requirements.
E
E
That
might
be
enabled
by
differentiate
service
providers
and
what
even
want
is
to
add
application
knowledge
to
the
network
layer
which
can
enable
finer
granularity
requirements
of
applications
to
be
specified
to
the
network
operator
and
as
the
ipv6
is
being
widely
deployed
and
the
program
program
ability
provided
by
them
can
be
augmented
by
convene
app
info
next
slide,
please
so
the
challenges
of
traditional
differentiated
service
we
provide
versioning.
We
don't
we
didn't
do
that,
because
we
ipv4
protocol
packets
are
not
able
to
carry
enough
information
for
indicating
applications
and
expressing
their
service
requirements.
E
The
network
device
meaning
rely
on
the
5
turbo
of
the
package
of
BI
tools
used
for
sale
matching
of
traffic
are
not
the
direct
application
information
that
not
babble
enough
for
new
and
deep
packet
inspection
introduced,
Quebec
sore
backs
and
security
issues
what's
more
and
about
the
Sdn
based
solution.
The
controlling
loop
is
too
long
to
be
suitable
for
faster
service
provisioning
for
critical
applications,
and
there
are
need,
be
too
many
interface
involved
in
the
loop
next
size.
E
Please,
according
to
those
problems,
how
18
can
help
you
can
6
aim
to
satisfy
the
application
awareness
comments
demanded
by
new
service
and
provide
differentiated
service
treatment
and
5
current
traffic
of
operations,
the
use
ipv6
or
as
a
v6
Network
program
ability
to
convince
app
info
in
the
data
plan
allowing
the
final
grant
requirements
from
apps
to
be
specified
to
the
network.
So
it
can
convince
the
application
information,
such
as
application
identification
and
as
our
service
requirements.
E
The
also
allows
network
to
quickly
adapt
the
perform
performance
necessary
actions
for
the
guarantee
is
by
and
as
a
v6
pass.
So
next
ice.
Please
and
the
key
element
of
epic
avionics
are
application
info,
conveying
app
info
and
network
abilities
matching
and
network
performance
merriment,
and
it
should
be
note
in
the
end
the
one
that
the
application
info
conveying
shouldn't
be
enforced
by,
but
provide
an
open
option
for
to
decide
whether
to
input
this
app
info
into
its
data
stream.
E
If
it
opens
element,
two
can
be
realized
according
to
the
info
so,
and
a
pretty
great
network
service
can
be
tracked
and
for
the
enemy
theory.
According
to
the
merriment,
can
update
the
match
between
the
app
and
the
corresponding
network
service
for
better
vigor
and
penalty
Azeri
and
complains
sighs.
E
Please
do
we
also
have
a
framework
of
a
pian
takes
the
cake
components
includes
service,
aware
app
and
app
aware
edge
device,
everweb
process
headed
and
the
me
mid
point
and
end
point
so
for
the
service
app
is
a
host
opens
an
application
factory
state
information
of
the
service
where
app
and
the
generates
packet,
which
carries
application
characteristic
information
in
the
caps
oscillation.
But
it
is
not
mandatory
to
base
service
where
and
and
app
aware
at
device
its
its
network
device
receives
pack.
E
The
we're
at
device
at
the
information
in
the
encapsulation
on
behalf
of
the
application,
the
packet
carrying
the
information
where
piston
to
the
abwehr
process,
hadn't
and
app
information,
will
be
used
to
determine
the
path
between
the
head
and
and
endpoint
for
boarding.
The
packet
for
the
app
aware
process
had
and
received
packets
and
obtains
information
and
the
set
of
passed
tunnels
or,
as
the
policy
exists
between
the
head
and
and
on
the
point.
E
E
Finally,
the
process
of
the
specific
service
path
will
and
at
any
point
the
service
requirements.
Information
can
be
removed
at
any
point
together
with
the
author
encapsulation,
or
go
to
go
to
be
convened
with
packet
in
all
this
week.
The
network
is
aware
of
service
requirements
expressed
by
applications.
E
So
there
are
some
advantages
of
using
ipv6
support.
Appian
6
includes
and
first
is
IP
reach
ability.
Then
it
is
much
easier
to
achieve
since
both
app
and
network
based
on
ipv6,
and
it
can
carry
very
rich,
very
rich
information
revelant
to
applications.
If
the
application
information
not
recognized
the
packet
will
be
forward
based
on
pure
ipv6,
it
is
also
little
dependency
because
there
are
only
based
on
forwarding
land
of
a
device
and
it
can
quick
response
enterprise.
Please.
E
Some
use
case
that
can
benefit
from
the
application
around
these
introduced
by
IBM
6,
including
as
a
guarantee
not
vocalising
deterministic
networking
service
from
function
to
network
moment
and
that
computing,
and
what
I
would
say
is
that
equity
is
the
nutrient
that
might
influence
the
network.
It
may
be
difficult
to
update
also
of
the
operators
device,
but
may
be
more
easily
to
change
the
edge
device,
so
it
may
also
benefit
pad
next,
please
it's
about
security
considerations,
because
we
exposed
some
informations
about
network,
so
great.
E
E
I've
read
the
draft
I'll
pan
and
have
some
considerations
of
and
Ian
and
but
I'm
not
sure
if
all
of
them
are
right.
So
if
it
is
mistaken,
please
point
out
seeing
the
same
things
of
some
is
to
provide
a
better
network
and
application
service.
They
want
the
interaction
between
network
and
the
user
on
the
point
of
application,
but
the
difference
is
that
Penn
wants
the
endpoints
or
application
to
get
pass
information
and
to
select
path
and
it
works
in
there
for
layer.
E
E
E
Trends
about
network
today's
network
is
best
ever
so
cast.
Customer
won't
expect
expect
too
much
of
it
most
case.
They
can
tolerate
its
reliability
or
instability,
but
that
work
will
be
better
than
before.
Consider
a
fabergé
of
mobile
network
and
gave
a
low
latency
high
bandwidth
and
multi-access
connection.
F
G
E
Are
also
some
existing
service
data,
it
was
similar
with
Penn,
for
example,
when
you
want
download
something.
Users
come
to
different
servers,
different
Network
points
or
different
operators,
the
wooden
playing
games
user
and
we
can
to
different
network
points
by
themselves
or
automatic
service.
Wage
will
choose
different
paths
by
application
itself
and
those
are
not
in
the
same.
In
the
same
we
open,
but
some
of
the
goals
I've
seen.
E
So
the
key
problem
I
think
about
the
business
and
technology.
The
existing
draft
mentions
that
it
caused
a
problem
of
who
operates
a
network
endpoint
app
or
operator.
I
worked
in
turnover
and
also
have
some
discussion
with
my
colleagues
and
there
might
be
the
chance
of
coalition
that
provider
can
rent
and
networks
operation
right
from
operator
motivations,
maybe
that
there
are
a
few
typical
applications
which
count
from
for
most
traffic.
Maybe
care
about
as
I
evaporator
can
really
have
some
benefits
from
selling
the
controlling
right.
F
E
Devising
operators
Network
and
some
new
argument
about
new
business,
the
which
has
also
been
mentioned
in
the
existing
draft
for
the
technology
draft.
What
not
to
do
really
gives
analysis
and
I
think
that
I
need
a
common
explosion
of
multiple
technologies
by
the
new
trend
of
the
network.
So
for
my
presentation
thanks
the
questions.
F
F
C
F
So
West's
question
is
essentially
what
sort
of
application
ID
zu
transmitting.
F
F
E
F
I
think
it
was
like
on
slide.
Could
he
could
go
back?
A
few
slides
I
forget
this
flight
number.
There
was
a.
There
was
a
picture
that
did
keep
going
yeah
this
one,
so
the
appian
six
framework
right
like
so
there's
an
information
from
the
app
where
edge
that
gets
put
into
the
app
aware
process
head
end
and
end
point.
So
there
that's
there's
some
application
ID.
F
Is
the
point
is
from
from
wes?
Is
that
like,
if
you're
actually
saying
well,
this
is
web
traffic?
Or
this
is
you
know,
traffic
of
a
particular
your
app
right,
like
so
a
particular
app
on
the
phone?
Then
that
has
a
certain
set
of
privacy
characteristics
that
are
our
I
think
quantitatively,
worse
than
the
privacy
characteristics
of
seeing
what
the
network
requirements
are
like.
So
in
terms
of
like
what
the
bandwidth
is
or
what
the
transmission
sort
of
like,
what
the
shape
of
the
in
you're
trying
to
pack
it
in
the
network
is
Colin.
F
Olsson
makes
the
point.
Many
applications
send
different
types
of
traffic.
So
if
you
have
a
application
ID
that
is
assuming
that
the
application
is
for
a
given
path
in
a
given
time
frame
going
to
have
heterogeneous
traffic
behavior.
That
might
not
be
enough
to
actually
to
actually
classify
to
pack
the
bins
I.