►
From YouTube: IETF103-PANRG-20181107-1350
Description
PANRG meeting session at IETF103
2018/11/07 1350
https://datatracker.ietf.org/meeting/103/proceedings/
A
B
C
Okay,
let's
start
it
go
talk
to
now.
This
is
our
network
and
research
group,
I,
hope
you're
in
the
right
room
anyway,
please
stay
I'm,
Jen
and
Brian
could
not
be
straight
with
us,
so
I'm
gonna
run
this
show
alone.
So
before
we
actually
started
okay.
This
is
not
well,
which
you
probably
have
seen
many
times
this
week
already
and
before
we
can
actually
start
I
need
two
volunteers.
I
need
the
minutes,
taker
and
jabber
scribe.
Please.
C
C
Thank
you
very
much.
Okay,
the
hardest
part
is
done
for
me,
so
no
agenda.
For
today
we
have
three
presentations
if
any
last-minute
agenda
Bashan
anyone
brilliant
ideas
to
discuss
No,
okay.
So
what
actually
will
happening
in
the
group?
Just
to
remind
you,
since
last
IETF
I
seen
Brian
posted,
updated
version
of
his
open
questions.
Draft
no
actually
I,
don't
see.
Any
major
changes
has
been
done.
C
I
think
the
document
is
a
pretty
good
shape,
but
I
think
we
can
discuss
it
next
time
when
Brian
will
be
back
so
Spencer
document
about
what
we
should
not
be
doing
or
what
we
have
down
and
shouldn't
be
doing.
Any
more
has
been
adopted,
well
done
and
we
have
another
individual
draft
from
the
Reza
which
she
is
going
to
present
right.
Wisco
is
your
Co,
sir.
So
please
let
me
change
the
slides.
D
D
So
a
path
property
is
a
characteristic
of
a
path
between
two
endpoints
and
what
we
do
in
this
draft
is
we
list
useful
and
relevant
path
properties,
and
then
we
classify
them
into
three
categories
and
the
classification
is
mainly
based
on
the
speciality.
So
how
close
to
the
endpoints
does
this
path?
Property
show
itself
and
temporalities
the
usefulness
of
such
a
measurement
over
time?
D
So
domain
properties
are
properties
that
relate
to
characteristic
within
the
administrative
domain
of
the
endpoint,
so
they
are
usually
within
the
first
few
hopes
of
a
path.
For
example,
the
home
Wi-Fi
network
or
Wi-Fi,
combined
with
the
Internet,
is
read
link
to
the
provider
or
the
cellular
network
in
case
of
a
seller
connection,
and
these
properties
are
strongly
influenced
by
an
endpoint.
D
D
Examples
of
these
properties
are
the
access
technology
of
an
endpoint
and
the
monetary
costs
now
for
the
backbone
properties
temporarily
device,
it's
similar
to
domain
properties.
So
these
are
rather
static.
They
usually
don't
change
over
the
lifetime
for
connection.
If
you
have
certain
device,
for
example,
net
or
a
firewall,
it
will
not
match
to
disappear
within
a
connection,
but
platform
properties
are
not
within
the
administrative
domain
of
an
endpoint,
so
we
have
less
influence
on
it.
D
E
D
F
So
we
do
not
like
we
probably
generate
some
samples
of
those
properties
and
then
at
various
points
in
time
at
which
we
think
it
would
be
useful
to
know
them.
We
can
like
have
a
median
or
the
minimum
of
this
metric
of
this
property,
or
maybe
also
we
can
only
approximate
it.
We
just
have
to
live
with
that.
We
can
know
the
actual
like
ground,
true
for
this
property,
but
we
have
a
reasonable
estimate
that
would
help
us
and
they
are
usually
union
bi-directional
I'm,
going
to
show
examples
on
the
next
slide.
F
Do
you
have
a
general
question
today?
Concept
yeah.
G
Rick
Taylor,
just
a
very
good
question
about,
is
your
intention.
So
I've
done
a
fair
amount
of
work
in
the
many
working
group
about
not
measuring,
but
actually
going
down
to
the
layers
below
going
down
to
that
layer,
1,
layer,
2
and
actually
letting
the
the
link
the
per
link
technology
tell
the
higher
layers.
This
is
what's
actually
happening.
F
But
we
can
also
have
measurements
in
the
physical
layer,
for
example,
it's
going
to
be
on
the
next
slide.
Okay,
so
I'm
within
the
dense,
usually
within
the
scope
of
a
connection.
We
have
a
round-trip
time
and
a
round-trip
time
variation,
for
example,
and
that
is
obviously
useful.
So
then
we
can
also
have
an
available
bandwidth
and
to
end
in
the
both
on
the
upstream
and
in
the
downstream
direction.
F
So
here
that's
an
obvious
example
of
in
asymmetric
or
bi-directional
and
which
way
it
what
the
best
word
for
that
is
property,
and
this
available
the
entrance.
What
we
I
would
expect
it
to
change
very
frequently,
and
it's
also
sort
of
hard
to
know
what
the
exact
value
of
that
is.
But
we
can
probably
approximate
it
by
looking
at
this
report
of,
let's
say
a
big
connection
that
like
transfers,
a
lot
of
data
and
it
maxes
out,
for
example,
the
congestion
window,
and
then
we
can
sort
of
approximate
what
may
not
prevent
words.
F
E
If
you
want
to
talk
about
these
things
in
any
sense
of
the
way,
I
mean
we've
done
quite
a
bit
of
work
in
AI
ppm
and
in
BMW
G
on
sort
of
defining
metrics,
but
in
sound
a
lot
of
these
things
are
related
to
that
or
or
even
identical,
but
it's
sort
of
I
I
can
argue
with
almost
anything
that
you've
presented,
but
because
I
can't
really
get
to
what
your
definition
of
it
is.
It's
kind
of
not
productive.
To
have
that
discussion
right.
F
F
Okay,
so
the
yeah,
the
first
step,
was
to
just
list
what
we
have
and
to
see
if
that's
like
something
or
if
we
are
like
missing
something
or
like
what
the
generals
causes
of
properties,
because
we
wanted
to
see
like
what
properties
are
actually
useful
and
so
on.
And
now
probably
one
of
the
next
steps
would
be
to
define
it
more
formally.
E
F
E
F
A
So
Cory,
Fairhurst
and
I
don't
often
say
that
the
IETF
but
I,
sometimes
I,
used
to
work
with
modems
and
I'm
designing
going
modern
waveform.
Nearly
everything
on
that
slide
can
be
traded
one
for
another.
On
the
next
time,
I
send
a
packet
and
modulation
rate.
I
can
just
change
and
if
you
see
level
I
can
change
your
cue
level.
Retransmits
I
can
change
our
TT.
A
I
can
change
by
changing
interleaving
depth
and
I
then
get
packet
loss
changes
can
just
so
first
comment
is
all
of
these
parameters
are
useful
for
knowing
what
happened
last
time.
I
may
tell
you
nothing
about
what
happens
next
time
you
try
and
transmit,
because
it's
different
trade-off.
So
this
is
something
to
think
about.
Yeah
second
thing
is
and
I
chair
a
group
that
just
cure
I
some
multiple
cues.
A
A
A
G
Rick
Taylor
again
I'm
just
following
on
from
the
previous
comments,
which
I
think
were
both
valuable
I
think
this
is
valuable
work
I'm,
not
trying
to
shoot
this
down
at
all.
But
going
back
to
my
point
about
a
lot
of
these
per
link
properties.
Wireless,
going
to
the
signal,
strength,
modulation
rate,
the
channel
utilization,
the
the
lower
links
are
doing
clever,
stuff,
they're,
doing
predictive
stuff.
We
are,
and
eight
years
working
on
dynamic
link
exchange
protocol,
which
is,
in
the
main,
a
working
group.
That's
done
as
an
RFC
that
will
give
layer
three
information.
G
It
cares
about
in
their
three
terms,
as
in
data
rates.
Layton
sees
things
like
that,
so
you
don't
have
to
try
and
decode
what
the
link
layer
is
doing
with
its
frequency
allocation
with
its
CDMA
TDMA
II
and
all
that
kind
of
stuff,
because
it's
not
just
802
11
Wireless
links,
SATCOM
mesh
radio
systems,
they're
very
clever,
I,
really.
G
You
go
and
look
at
not
only
dilemma,
but
also
the
microwave
transit
link.
Guys
have
done
some
very
good
stuff
in
C.
Camp
they've
worked
with
the
industry
about
what
data
can
we
get
that
is
useful,
and
how
do
we
get
that
in
it
in
a
in
a
maintainable
way
that
talks
about
not
what
happened
just
now,
but
what
we
are
going
to
be
doing
for
the
next
n
milliseconds
in
seconds?
So
you
know
it's
trying
to
tie
into
their
processing
to
so
that
we
can
make
predictive
things
at
the
higher
layers
so
value.
F
F
G
F
K
You
know
Adrian
Farrell
I
want
to
apologize,
I
have
read,
you
ever
hoped,
I
think
it's
there's
good
stuff
here
in
the
shopping
list.
Sense
you
you
are
collecting,
but
the
shopping
list
and
that's
fine
and
as
RIT
says,
we
have
some
work
in
how
you
collect
the
information.
You
may
be
missing
work
in
the
ITF
and
how
you
aggregate
that
information
end
to
end.
You
know
we
can
get
piece
by
piece,
but
what
is
then
like
last
says,
definitions.
What
is
a
path?
I
Mia
cumin
I
also
want
to
echo
echo
one
point
last
part
up,
and
that
is
that
for
network
metrics
we
have
a
lot
of
work
in
I
ppm
and
what
they
usually
do,
at
least
is
the
upper
three
metrics
are
well
defined
and
well
describe
them.
What
they
usually
do
is
they
have
a
definition
for
on
a
packet
basis,
basically
for
packet
loss
either
the
packet
is
lost
or
not
right,
but
there
are
self
definitions
for
like
a
set
of
packets.
I
G
Just
to
follow
on
Rick
Taylor,
again
just
to
follow
on
from
that
the
Delap
RFC
81-75
for
whoever's.
Taking
minutes
that
we
have
extensions
in
progress
to
allow
you
to
get
/,
qø,
SQ,
metrics
dynamically,
from
the
radio
or
from
from
the
link
layer.
So
they
can
say
I'm
running
different
I
mean
configures,
a
different
key
you're,
getting
different
metrics
per
qos
or
it'll.
Do
it
on
ethertype
as
well
I'll.
F
Be
sure
to
take
a
look
at
that
right
if
there
is
not
more
specific
questions
on
this
particular
slide
on
it,
then
I
have
some
questions
myself,
which
are
partially
already
being
discussed,
so
anything
were
missing.
Well,
more
formalization
is
what
I
hear
and
then
perhaps
this
yeah
there's
more
things
to
look
at
and
then
the
categorization
yeah.
This
is
our
first
proposal
of
a
categorization
into
domain
properties
back
on
properties
and
dynamic
properties,
or
maybe
you
have
I
to
net
ideas.
That
would
be
very
welcome
and
then
another.
F
So
the
initial
Panaji
question
was
how
a
property
is
defined
and
represented.
So
so
far
we
have
mostly
talked
about.
Let's
say
we
would
have
an
overview
of
what
properties
you
might
be
looking
at.
We
have
to
clarify
the
definition
more
formally
and
then
also
representation
is
interesting,
so
some
of
them
obviously
say
numeric
and
like
we
might
defined
units,
but
it's
not
very
interesting,
but
then
something
that
I
have
thought
about
is
how
do
we
represent?
For
example,
the
excess
technology
is
like.
F
There
is
a
Wi-Fi,
there
is
a
cellular,
but
is
this
just
a
string
space?
It
basically
says
I
said
and
then,
or
is
there
like
some
enumeration
that
we
won,
because
we
have
I
think
I
remember
we
have
looked
at
this
in
taps
and
we
haven't
found
a
registry
that
makes
sense
of
like
two
different
access
technologies
that
we
would
want
here.
So
any
idea
on
that
and
then
also
how
do
we
represent
the
tails,
for
example,
a
specific
type
of
device
on
the
path?
For
example,
you
carry
a
great
net.
F
Do
we
get
the
address
of
this
device
or
there's
some
like
interesting
question
on
how
these
things
can
be
represented?
And
then
finally,
the
working
problem
asked
for
this
document,
and
so
we
wanted
to
be
brave
and
ask
whether
the
working
group
would
be
interested
to
adopt
this
draft
at
this
stage
already.
A
F
Motivation
well,
for
me,
it's
mostly
about
I,
have
a
man.
Endpoint
I,
have
multiple
paths:
I
want
a
good
performance
for
my
application,
perhaps,
and
so
that
is
why
I
want
to
choose
between
those
different
house,
but
it
doesn't
have
to
be
only
performance.
But
yes,
we
didn't
make
that
clear
in
the
presentation,
so
I
think
also.
That
should
be
a
more
clear
in
the
draft.
F
A
Like
to
suggest
that
people
like
AI
ppm,
have
very
different
motivations,
they
often
want
to
know,
did
my
path
work.
Is
it
actually
within
the
SLA
I
specified
from
the
data
I?
Have
you
actually?
What
you
just
said
appear
to
have
a
crystal
ball
and
be
able
to
predict
ahead?
How
that
paths
going
to
work
next
time,
or
maybe
even
in
a
routing
case,
you're
talking
about
how
it
will
work
in
the
next
30
seconds,
so
I
can
now
make
a
routing
decision
to
do
something.
A
So
there
is
an
element
of
predicting
the
future
here
and
if
I
go
back
to
the
more
dem
slide.
Well,
that's
a
big
call
you're
asking
what
the
interference
and
the
propagation
properties
will
be
in
the
future.
So
that's
not
what
you
learn
from
the
data
you
have
collected
in
the
past.
That's
a
different
set
of
data,
especially
when
we
go
to
places
where
I've
got
shared
spectrum
and
once
of
Wi-Fi
might
be
impacted
by
the
forms
of
another
waveform.
A
So
this
is
this
is
this
is
an
area
where
we
should
also
have
some
little
bit
of
clarity.
Kind
of
like?
Are
you
going
to
use
it
for
justify
what
happened
and
understanding
the
data
I
saw
a
conformance,
etc,
or
are
you
using
it
for
the
future
and
how
far
in
the
future,
do
you
want
to
use
it?
I,
don't
I'm,
not
asking
you
for
the
answers.
I'm
just
saying
these
are
the
sort
of
things
that
we
should
decide.
If
you
want
to
answer.
That's
ok.
F
A
F
C
J
H
Good
morning,
I
I
heard
that
I
was
invoked
so
yeah
to
answer
Gauri's
point
I
think
that
there
is
indeed
a
an
element
of
predicting
the
future
here.
Right
like
there
is
a
something
along
the
path,
so
either
that
the
sender
so
that
the
transport
protocol
stack
itself
or
something
in
between
the
transport
protocol
stack
and
the
rest
of
the
network
has
information
from
the
past
that
it
uses
to
make
a
likely
estimate
of
the
future
right
like
so.
In
this
document
we
don't
talk
about
the.
H
Mechanisms
by
which
that
would
happen,
but
we
assume
that
those
mechanisms
exist
now
predicting
the
future
to
100%
accuracy
is
impossible,
but
is
there
a
way
that
we
can
predict
it
to
90
something
percent
that
would
actually
give
a
cinder
enough
information
to
make
a
choice.
So
that's
what
this
that's!
What
I
did
the
way
that
I
see
this
framework?
It's
you
know.
Yes,
it
predicts
the
future,
but
it
doesn't
predict
the
future
great.
L
All
right,
Giovani
say
the
end
lab
Sena
Tia
Delft,
so
it
just
I,
don't
go
back
to
the
point
of
definition
of
what
is
a
path
but
might
be
useful
for
you
in
the
future
or
whatever
you
updated
draft
to
think
of
what
is
not
a
path.
So
maybe
they'd
be
interesting
to
log
into
the
definition
of
secret
circles,
waiting
like
what
they
did
an
ATM
and
they
have
a
clear
path.
L
M
Spencer
Dawkins,
so
I
couple
things
I
just
wanted
to
say
real
quickly.
One
is
you
know,
because
we
did
get
as
far
as
the
slide
with
adoption.
Adoption
adoption
in
a
research
group
is
adoption
for
the
research
group
to
work
on
it
and
different
research
groups
have
a
huge
amount
of
flexibility
on
when
they
do
that.
What
we
did
with
the
what
not
to
do
draft
was
basically
I
did
two
revisions.
I
think
are
somewhat.
M
Ugly
I've
made
it
to
revisions
and
I've
asked
for
help.
So
just
this
perspective,
I
think
the
other
thing
to
mention
on
this
is
that's
helpful.
To
think
about,
this
is
going
to
help
us
have
a
shared
understanding
if
we
ever
stop
talking
about
what
not
to
do
and
start
talking
about
what
to
do
that,
we'll
be
able
to
understand
each
other
when
we
have
when
we
had
that
conversation.
So
it's
differently
very
useful
for
us
to
have
this
with
that
goal
in
mind,
among
probably
others,.
E
Lots
of
great
so
so
Corey
made
a
lot
of
points
that
I
was
going
to
make
something
to
repeat
them,
but
but
they
were
all
excellent
one
thing
going
great
briefly
back
to
the
formalism
right.
So
if
you
don't
know
what
your
units
are,
that's
a
pretty
good
sign
that
your
formalism
isn't
there,
because
that
should
just
fall
out
of
the
math
right.
If
it
doesn't,
then
that
tells.
F
E
But
that
was
just
a
slight
question,
so
it
would
also
be
useful
since,
since
it
is
partially
about
predicting
the
future
right,
so
we-
the
original
charter
for
the
alto
working
group
over
in
the
ITF
that
was
I,
was
area
director
for
that,
so
that
they
had
a
very
minimal
goal
that
we
work
very
hard
to
phrase,
and
it's
basically
to
do
anything.
That's
better
than
random.
In
terms
of
you
know,
if
also
specifically,
try
to
give
peer-to-peer
clients
a
set
of
peers
that
they
could
start
pulling.
E
F
N
Meteor
finishes:
I
just
wanted
to
add
that
one
of
the
most
important
things
in
mind,
source
attributes
which
I
use
for
e,
are
their
statistical
properties
because
in
the
end
we
are
trying
to
predict
or
infer
the
future
from
the
past
and
essentially
many
of
the
tree
bridges,
it's
sort
of
stochastic
process.
We
measure
them
and
they
are
starting
to
diverge
and
to
have
a
variety
in
their
situation.
F
C
M
So
hi
everybody,
I'm,
Spencer
and
I'm
here
to
talk
to
you
about
what
not
to
do
I
wanted
to
call
it
everybody's
interested
the
draft
prefix,
they
name
prefix,
changing
because
the
work
the
research
group
adopted
it
and
there's
also
actually
a
name
change
as
well.
A
couple
things
that
this
is
not
a
huge
change
from
when
I
had
this
slide
up
previously.
M
But
the
idea
is
basically
we're
not
trying
to
capture
every
idea,
but
we're
trying
to
capture
every
lesson
that
we
need
to
learn
to
keep
in
mind
when
we
get
to
what
to
do
for
Panther
we're
networking.
This
is
now
a
RG
graph,
so
you
all
own
it
make
good
choices
and
please
send
comments
to
on
the
draft
contents
to
the
mailing
list.
M
This
is
what
the
new
summary
of
the
summary
of
lessons
learned
looks
like
these.
The
ones
in
red
are
ones
that
we
picked
up
in
the
last
round
of
comments.
One
was
providing
benefits
for
early
adopters
is
key.
This
is
something
we've
learned
on
protocol
design
in
general,
but
it
certainly
applies
in
path.
Aware.
Networking.
One
comment
that
we
got
from
Joe
touch
was
followed
the
money
which
is
very
close
to
this
topic.
M
Here
we
got
a
lot
clearer
statement
about
routers
that
don't
process
and
band
help
IHOP
signals
and
hardware
and
that
being
a
bit
being
a
problem
for
a
variety
of
reasons.
We
got
that
because
we
added
in
sis
we
got
these
it
needs
to
because
we
added
incest.
So
we
still,
you
know
so
adding
a
couple.
More
was
still
a
good
thing
to
do
a
couple,
more
contributions
about
things,
we've
tried
and
the
third
one
got
more
complex.
We
had
I
want
to
say
that
that.
M
Middle
boxes
needed
to
be
able
to
trust
in
systems
in
order
to
use
signals.
It
turns
out
that
what
we
added
in
sis
it
made
it
obvious
that
the
relationship
had
to
be
in
both
directions.
You
know
that,
in
order
for
you
to
to
do
in
order
for
you
to
not
have
an
obstacle
about
with
trust
that
you
had
to
overcome,
so
these
are
the
things
that
are
new
and
they
in
the
o0
research
grant
draft
version.
I'm
going
to
put
those
are
further
people.
Is
it
possible
that
there
are
questions
from
the
audience.
A
H
A
M
C
M
So
it
may
be
right
in
the
draft
in
the
summary,
but
when
I
summarized
the
summary
here
to
share
with
the
research
group,
I
might
have
done
violence
to
it.
I
think,
though,
I
think
what
the
point
of
this
is
that
the
processing
path
is
not
the
same.
If
you
put
options
on
things,
whether
that's
in
hardware
or
some
mystical
smoke
does
doesn't
matter,
but
but
basically
this
can
slow
down.
This
can
slow
down
a
path
enough
to
where
operators
are
elected,
to
use
the
mechanism.
A
M
You
look
at
the
draft
there's
one
that
says
it
has
been
an
obstacle
to
deployment
in
the
past
that
somebody
was
trying
to
do
something
that
required
the
operator
or
the
middle
box
to
believe
what
the
end
system
was
doing
next
contribution
down.
There
was
there
was
this.
Is
the
past
we're
having
the
in
system
trusting
the
operator
was
the
obstacle
deployment?
M
A
J
A
O
No,
that
wasn't
the
point.
I
was
gonna,
make
him
a
middleboxes
known
systems,
do
not
trust
each
other
they
may
be
able
to.
You
may
be
able
to
gain
trust
over
time
by
demonstrating
their.
What
you
are
sure
the
information
you
are
sharing
is
correct.
Anchor
have
to
trust
is,
is
is
very
much
not
the
right.
Fraser.
M
Again,
this
is
translating
the
Spencer
and
I
probably
shouldn't,
but
it's.
This
is
not
to
say
that
this
is
not
to
say
that
anything
that
we
do
going
forward
has
to
have
trust
in
both
directions.
It's
it
is
to
say
that
in
the
past
this
has
been
a
problem
in
both
directions.
It
has
been
a
bit
of
problem
in
each
of
two
directions,
and
so
what
are
we
going
to
do
about
that?
When
we
get
to
what
to
do
about
path
or
networking?
We
head
back
to
the
mic
on.
M
M
So
this
is
kind
of
the
high
order
bits
on
what
I've
done
since
the
last
time,
which
is
I
added
a
pointer
to
the
IBI
tech
workshop
report
on
a
protocol
design
and
adoption.
That's
not
specific,
to
path
aware
networking,
nor
are
the
other
two
IAB
RFC's
that
are
in
that
are
abandoned
as
informational
references
but
they're
worth
reading.
This
one
is,
as
we
started,
to
move
into
the
fall
of
the
money,
part
of
the
conversation
and
incentives,
and
things
like
that.
The
ICAT
workshop
was
kind
of
focus.
M
Some
of
the
topics
we're
talking
about
economic
incentives
as
well,
not
just
technical
incentives
or
performance
incentives,
or
something
like
that.
I
added
the
contribution
from
incest
and
worked
on
things
a
little
bit
more
yeah
yeah
I'm,
not
just
adding
at
the
bottom
I'm
kind
of
trying
to
synthesize
and
rearrange
things
and
stuff
like
that,
and,
as
we
said,
we
had
a
contribution
from
from
Roland
and
from
Martin
on
incest.
So
that's
that's!
M
What's
new
in
this
version
of
the
draft
compared
to
the
information,
the
individual
versions
of
the
draft
that
came
previously
I
said:
please
send
direction
the
corrections,
and
somebody
did
so
just
because
this
is
they
were
a
research
group
draft.
Now
you
won't
need
to
know
what
I'm
doing
in
your
name
and
Wes
said
embarrassingly.
M
The
BGP
specs
for
specs
was
not
the
same
as
RC
people.
Specs
same
term
is
used
for
different
things.
Unfortunately,
so
I
met
with
Ron
Monica
serendipitously
on
Monday,
and
he
said
what
he
meant
basically
in
the
original
text
was
that
the
concepts
were
reused,
not
that
not
that
the
mechanism
was
reviewed,
renew
reuse.
So
some
of
the
flow
specs
I
had
the
same
names
to
represent
the
same
kind
of
things,
but
it's
not
a
reuse
at
the
flow
spec
mechanism.
M
So
I
can
fix
that,
and
I
am
in
blue
is
what
I'm
planning
to
do
and
let
something
stops
me
would
it
make
any
sense,
make
sense
to
say
anything
about
xcp,
EPC,
interconnects,
so
high
order
bit
is
what
other
contributions
would
provide
lessons
that
we
don't
already
have
in
section
2.
Those
are
the
additional
contributions
that
women
should
be
soliciting
and
I'm,
not
sure
I've
managed
to
hunt
down
I
had
I.
Think
one
of
these
one
other
of
these
sections
was
a
volunteer
and
everybody
else
was
caught
by
me
from
running.
M
You
know
chasing
them
to
do
the
contribution,
so
I'm,
not
I'm,
not
shy
about
chasing
contributions.
I
just
say
need
to
know
kind
of
where
the
what
the
research
group
thinks
about
what
else
matters
and
the
so
the
EO.
So
the
question
is
what
lessons
would
these
contributions
provide,
whether
it's
one
of
the
set
of
three
or
whether
it's
some
other
contribution,
so
I'm
kind
of
sitting
on
that
comment
right
now,
Adrian
are
you
for
me.
K
M
I
So
I
think
the
lesson
of
those
three
protocols
is
more
or
less
a
lesson
of
ecn,
which
was
if
the
deployment
story
and
the
incentives,
if
then
plot
deployments
are,
is
too
complicated
and
the
incentives
are
not
clear
and
there's
no
incremental
way
forward.
Then
it
it's
hard
that
might
be
covered
present,
another
section,
but
maybe
not
that
explicitly.
I
don't
know,
but
it
would
make
more
sense
to
write
something
about
the
base
protocol
here,
which
is
ECM
yeah.
M
I
think
that
I
think
that
I
think
that
what
I'm
hearing
you
say
sounds
probably
most
like
the
ANSYS
contribution
that
we
just
got
so
so
maybe
we
would
you
know,
as
I
said,
this
is
what
the
editor
position
is
busily
doing
is
saying.
Will
we
learn
enough
about
adding
formatting
a
contribution
to
change?
What's
in
the
lessons
learned
summary
so
so.
I
I
M
M
E
The
operators
would
bet
were
benefiting
by
making
this
information
available,
that
that
would
hint
to
the
clients
where
to
connect
to
and
the
clients
were
probably
going
to
benefit,
because
you
know
they
got
unto
the
bigger
pass
right
away
with
more
capacity
on
them
and
we
still
couldn't
deploy
us
and
then
they
could
work
a
Center
food
that
actually
were
there.
Otherwise
we
wouldn't
have
chartered
it,
but
it's
a
it
died
for,
for
many
other
reasons,
and
also
also
now
is,
is
very
different.
E
I
M
I
think
you
know
maybe
a
second
order
passed
through
the
stuff.
Is
this
dressed
or
it's
maturing,
and
it's
not
gonna
on
my
slides
because
I
just
thought
of
it,
but
I
think
you
know
one
of
the
next
things
that
we
can
do
is
to
say
if
these
have
been
obstacles,
the
deployment
for
some
networker,
where
path
where
networking
mechanisms
have
they
ever
been
overcome,
and
what
what
did
they
look
like?
You
know
so
I
think
that
I
think
it's
a
very
fair
observation
to
make
yeah.
M
So
this
one
here,
yeah
so
basically
I
got
I,
got
text
that
kind
of
the
text.
The
text
that
I
got
from
Eric
Northman
well,
my
mark
was-
was
accurate
at
the
time
where
was
basically
talking
about
HTTP
stayed
and
assuming
that
everything
was
running
over
TCP
and
stuff
like
this
is
like
10
years
ago
right,
that's,
not
a
meaningful
explanation
in
2018
as
far
as
Spencer
is
concerned,
what
it,
basically,
what
we're
thinking
about
now
is
not
HTTP
stayed
and
file
descriptors
and
things
like
that.
M
It's
talking
about
transport
connections
in
general,
which,
as
long
as
the
only
transfers,
only
that's
the
only
thing
we
were
doing,
was
query
response
over
UDP
plus
TCP.
The
only
thing
that
mattered
was
TCP,
but
that's
not
where
we
are
now
so
I'm,
just
basically
up
leveling
that
that
at
that
point
in
the
in
the
draft,
if
that
makes
sense,
mundo
are
you
thinking?
Okay
should
should.
Should
we
wait
for
you
to
think
or
you
could
bring
me
back
if
you
need
to
go?
M
Thank
you
that
was
a
that
was
a
that
was
there
was
a
hard
that
was
think
hard
thinking.
I
could
see
three
rows
of
two
rows
back
this
one.
So
there
was
his
text
in
there
about
the
in
the
shrimp.
Six
section
and
I
want
to
be
very
clear
that
this
text,
as
part
of
that
section,
was
something
I
wrote
and
not
something
that
Eric
Norberg,
but
basically
saying
you
know.
M
The
observation
was
that
she
ship
six
got
a
lot
of
operator
resistance
because
you
had
untrusted
in
systems
that
were
going
to
be
making
decisions
to
swing
traffic
around
from
one
set
of
paths
to
another.
I
happened
to
be
at
the
Nanog
session
when
Jeff,
Houston
and
Dave
Meyer
were
doing
their
pitch
to
the
operator
community
about
Jim
six
and
they
were
like.
M
Are
you
nuts,
but
what
they
were
coming
from,
especially
at
that
time
was
the
level
of
security
in
widely
deployed,
desktop
operating
systems
and
basically,
how
you
know
how
easy
it
was
to
roll
up
a
forty
thousand.
You
know
bought
botnet,
where
you
could
say:
I'm,
gonna
move
all
the
traffic
that
I'm
doing
on
this
network
path
through
this
is
P
and
they
don't
care
about
the
path
that
they
care
about.
M
The
IASB
through
this
is
B
I'm,
going
to
roll
it
all
over
to
that
one
and
it's
all
running
it
more
or
less
full
speed,
and
that
will
be
never.
You
know.
We've
come
as
quite
a
surprise
to
the
second
operator
who
thinks
he
is
engineer,
is
networks
well
enough,
except
with
everybody
at
the
world,
shows
up
at
full
speed,
so
that
was
that
was
the
concern.
Okay,
so
I'm,
not
in
the
mind
of
Spencer
I'm,
not
sure
how
that
is
different
from
SCTP
or
impede
TCP,
but
yeah.
My
thing
was
no
one.
M
Nobody
cares,
but
that
makes
a
larger
point,
which
is
one
gopher
to
this
raft
is
to
use
it
to
spot
proposals
that
might
trip
over
known
obstacles
and
lessons
learned,
but
the
truth
is
always
appropriate.
If
that's
true,
my
suggestion
is
to
remove
this
text
that
I
wrote
from
the
draft
from
this
draft
and
that
will
figure
out
what
to
do
with
it.
M
As
we
start
saying,
you
know,
as
we
start
as
we
start
saying:
we've
we've
we've
we've
got
research
group
general
agreement
that
this
stuff
will
be
problematic,
not
that
you
can't
do
it,
but
then
it
would
be
problematic
and
then
to
start
those
conversations
rather
than
try
to
have
those
conversations
in
this
research
group
about
those
protocols
in
the
IT
in
the
IETF.
Does
that
make
sense.
E
E
You
might
ask
yourself:
why
am
I
paying
for
that
other
link
when
it's
consistently
worse,
and
that
was
a
big
discussion
right
and-
and
it
seems
like
for
this
particular
effort
in
this
group
right
that'll
be
a
much
more
interesting
discussion,
because
you
potentially
like
Teresa
and
her
colleague
had
a
lot
of
things.
You
have
multipath
T's.
If
he
didn't
even
capture,
it
was
purely
based
on
TCP
level,
information
like
packet
losses
and
round
trips,
and
already
the
operators
were
freaking
out
so
yeah.
E
M
And
that
may
be
actually
be
the
point,
which
was
that
the
operators
could
tell
you
we're
doing
gem
six.
It
seems
like
they
can't
quite
so
easily
tell
about
it.
You
know
about
some
other
things,
but
but
anyway,
so,
like
I
said
I'm,
not
multiple
TCP
is
one
of
the
working
groups
that
Martin
had
when
I
was
at
the
Area
Director
with
Martin
and
now
Maria
has
now
that
I'm,
the
area
director
with
Maria
so
I
have
trusted
them
and
don't
really
know
very
much
about
the
details.
F
Had
a
quibble,
what
Lustrous
said
I
find
it
really
interesting
to
know
about
why
MPT
City,
but
what
kind
of
resistance
MPT
City
met
and
why
it's
still
I
guess
was
more
successful
and
I.
Don't
know
and
I'm
wondering
what
kind
of
draft
would
that
be
to
put
this
lesson
in?
Is
it
as
a
draft
like
what
to
do?
Instead
of
what
do
you
know,
I.
M
Mean
people
have
been
trying
to
give
me
what
to
do
information
since
I
started
the
what
not
to
do
draft
so
I
know,
I,
know
that
there's
interest
the
research
group
to
do
that
and
I
think
I
think
that
will
be
a
good
thing.
One
of
the
things
one
of
the
other
points
now
that's
worth
maybe
saying
out
loud
when
we
started
Penn
orgy
and
when
I
asked
about
this
draft,
and
they
said
that
sounds
like
a
fine
idea.
M
M
Basically
to
you
know
to
use
one
of
the
examples
you
know
most
of
the
stuff
has
got
our
see,
numbers
like
below
five
thousand
and
we're
not
seeing
a
deployed
and
we're
thinking
that
that's
not
a
good
sign
that
it's
moving
forward,
so
you
know
so
we're
writing
it
up.
Those
are
the
ones
that
were
using
for
lessons
at
some
point
coming
forward.
You
know
in
time
they're
gonna
gets
definitely
worth
looking
around
more
recent
stuff
and
I
actually
have
a
point
in
there.
I
think
it's
all
later
slide.
M
We
talk
about
anyway,
but
anyway,
so
my
point
was
I'm
gonna
go
ahead
and
remove
this
text
just
because
I
think
it's
starting
to
get
to
other
drafts
that
the
research
group
might
have,
and
one
of
them
is
the
oh
just
an
analysis
saying
this
is
what
we
see
now.
This
is
what
we
learned
for
previous,
don't
methyl
or
networking
techniques
we're
trying
to
understand
how
these
lessons
apply
or
don't
apply
in
this
case
and
try
to
you
know
it's
like
I
say
we're,
not
the
police
of
the
internet.
M
M
So
just
talk
about
where
I
think
the
goalposts
are
on
things
I'd
like
for
this
device,
Spencer
the
editor
of
a
research
group
draft
which
is
not
Spencer's,
Draft
anymore.
I'd
like
for
this
to
be
a
document,
that's
useful
advice
from
Panaji
to
the
ITF,
the
ITF
developed,
the
protocols
that
were
described
in
this
document
so
far
there
were
not
implemented
or
were
implemented
and
not
deployed.
M
There's
no
reason
to
think
that
the
ITF
will
not
learn
these
lessons
again
because
some
of
these
coming
some
of
these
are
you
know
if
you
look
at
if
you
look
at,
if
you
look
at
section
two,
which
is
a
summary
of
lessons
learned,
it
says
here's
the
lesson
and
then
here's
the
individual
contribution
that
that
came
from
so
let
them
have
three
or
four
lessons.
You
know
like
this.
This
isn't
young.
This
is
always
going
to
be
a
problem
when
you
try
to
do
it,
you
know
this
is
you
know,
thinking
happy
thoughts.
M
The
next
time
is
not
going
to
be
the
win,
so
you
know
so
now.
What
are
you
going
to
do
so?
I
think
that
it's
fair
to
say
that
the
IETF
is
capable
of
learning,
but
the
the
ITF
is
capable
of
repeating
the
same
mistakes.
If
no
one
points
you
know,
if
no
one
says
we've
looked
at
this-
and
this
is
the
way
it
looks
to
us.
I
would
like
to
this
document
to
be
useful
advice
to
pay
energy
itself.
M
So
Brian
has
the
open
questions
draft
to
guide
penalty
research.
This
document
may
identify
other
open
questions
to
guide,
pen
or
key,
which
I
have
not
looked
at
at
all.
I
mean
I
Fred
Reines
draft,
but
I
haven't
thought
about
at
all.
What
held
what
we've
learned
so
far
maps
on
to
the
open
questions
you
know
are
there?
Have
we
learned
if
we
have?
M
F
Reason:
okay,
I
just
opened
the
questions
draft
to
look
at
it
again
and
two
point:
three
is
a
selecting
pass,
I
think
not
sure
who
exactly
it
was
facing
a
craft,
but
I
think
that
goes
back
to
what
we
were
discussing
earlier
and
they've
have
properties
draft,
which
is
actually
part
of
probably
a
different
graph
or
okay
point
is
we
want
to
do
path?
Selection?
On
the
end
point
it?
It
has
limitations,
as
we
saw
so
I.
Think
learning
from
our
mistakes
is
also
useful
input
to
answer
question
2.3
in
the
questions
draft
great.
M
M
Okay,
cool
and
that's
the
end.
Okay
cool,
so
you
know
question
which
we've
kind
of
talked
about
so
far.
Are
there
other
lessons
that
we
need
to
document?
What
are
their
contributions?
Do
we
need
which
ones
from
who
we
just
took
comics
on
there,
because
it
was
on
the
list,
but
I,
say
I'm
still
interested
and
still
happy
to
chase
people
if
we
think
we're
gonna
learn
something
that
we
haven't
already
learned
in
section
2
and
are
there
we
haven't?
M
Looked
at
all
I
have
not
looked
at
all
at
lessons
from
outside
the
ITF
and
I
know
that
there's
a
lot
more
protocol
work
that
happens
at
the
research
level
they
had
the
outside.
The
idea
of
them
there
is
in
you
know,
are
the
things
that
we
could
learn
from
outside
the
guidance
that
would
be
helpful.
You
know
I
I,
don't
know,
I
haven't
looked,
but
some
of
you
all
might
know
something
about
research.
That
was
a
joke.
M
So
thinking
about
what's
next,
what
seem
to
his
fiddle
to
me?
We
could
reasonably
look
at
the
current
path
where
proposals,
if
we
think
this
draft
is
stable
enough
after
we
move
things
around,
maybe
after
maybe
after
0
1
of
this
draft
to
we
can
point
people
to
this
at
the
ITF
and
if
there's
anything
going
on
in
another
research
group
as
well,
because
we
know
we're
trying
to
say
well,
the
current
proposals
can't
counter
the
same
obstacles.
Why
or
why
not
I
think
it's
good
to
do
that
at
some
point.
I,
don't
know!
M
We
could
compare
the
reason
we
compare
this
graph
to
the
PRG
questions,
which
is
kind
of
doing
that
scan
saying.
Are
there
things
that
we
have
identified
as
problems
that
we
that
we
haven't
told
anybody
that
they
need
to
be
thinking
about?
How
do
it
how
to
get
how
to
work
around,
and
we
could
reasonably
finish
this
draft
and
publish
it?
M
A
So
very
fast,
the
last
one
I
can
see
reasons
why
we
might
publish
it
for
another
audience,
and
but
we
have
to
be
clear
in
the
message
we
present
and
people
keep
coming
to
me
saying
we
need
to
bring
more
of
this
stuff.
That's
done
outside
of
the
IETF
to
here,
and
people
don't
always
understand
the
culture
and
the
things
we've
tried
here
when
they
bring
a
new
piece
of
work
here,
so
it
would
be
kind
of
useful
just
to
have
a
document
that
was
totally
informational.
We
said
these
are
the
stories
about
what
happened.
A
I
think
that'd
be
a
great
thing
to
point
people
to,
but
if
we
do,
then
we
must
make
it
clear
that
some
of
these
experience
in
the
ITF
with
good
experiments
to
do,
even
though
the
outcome
was
pretty
disastrous
in
consequences.
So
we
need
to
make
sure
that
message
is
very
clearly
conveyed,
because
otherwise
we
we
stop
people
being
interesting,
come
here.
Yeah.
M
I,
it's
worth
me
saying
something
as
transfer
area
director
for
just
nanoseconds,
so
there
was
a
hunter
or
sea
talk
on
Sunday
night
about
loops
and
doesn't
matter
what
that
is.
But
we
talked
about.
We
like
nine
people
from
the
Transport
Directorate,
ended
up
at
their
side
meeting
and
we
had
one
of
the
most
positive
conversations.
I
can
remember
having
an
a
with
anybody
trying
to
bring
transport
work
into
the
IETF,
but
we
you
know
I
was
pointing
to
them
towards
this
draft
in
its
current
form,
as
possibly
useful
advice
to
them.
F
Again,
if
I
remember
correctly
in
Montreal
at
the
last
Panaji,
it
was
pointed
out
that
this
group,
right
now
and
like
who's
speaking,
is
very
transport
focused
and
we
would
like
more
routing
people
here.
Does
society
I
haven't
gotten
the
opportunity
to
go
to
the
spring
working
group,
for
example,
and
invite
them
to
come
because
so
I'm
wondering
if
there's
routing
people
in
the
room,
and
maybe
they
have
more
protocols
more
lessons.
M
M
And
and
that's
that's
an
important
observation.
The
first
time
we
met
I
think
it
is
true
that
either
the
first
time
we
met
her.
The
second
time
we
met.
This
is
both
alia.
Alia
is
correctly
me
to
both,
but
both
of
the
first
two
times
we
met
that
we
conflicted
with
what
was
a
routing
area
or
something
yeah.
Okay.
So
basically
it's
like
you
know
we're
routing
guys.
Please
come
unless
you're
a
nurse
is
routing.
H
C
M
No
I
think
I
think
you
already
have
when
we
were
doing
the
you
and
Brian
already
have
when
we
were
doing
the
conflict
review
thing
either
after
102
or
before
103
I
think
you
all
changed
the
conflict
list
for
this
to
include
at
least
from
routing
stuff,
and
this
was
Consulting
without
Faro,
who
is
still
sitting
a
peon
and
stuff
like
that.
So
it's
gotten
better
and
I.
Think
that's
why,
which
Risa
says
something?
M
M
I
think
you
I
think
every
time
that
we've
made
an
editing
pass
over
this
we've
tried
to
make
it
less
your.
You
know
this.
Your
proposal
is
bad
and
you
should
feel
bad
and
more
in
more.
You
know
trying
to
tell
you
it's
like
and
having
having
the
people
who
made
the
mistakes
right.
The
contributions
you
know,
I
think
it's
like
you
know,
always
remember
the
first
contribution
that
went
in
here,
Spencer
Road
about
Spencer's
path.
You
know
so
it's
like,
but
I,
think
you
know.
The
other
thing
you're
saying
is
really
important.
M
P
Marco
related
to
the
old
stories,
the
I
just
wanted
to
point
out
that
there
is
an
old
craft
that
parties
are
all
active,
Sally,
Floyd
and
I
in
EDA
in
transport
area
working
group.
More
than
ten
years
back,
it's
titled
transport
layer,
considerations
for
explicit
cross
layered,
not
a
indications,
so
it
may
have
some
usable
stuff
for
these
crafts
and
maybe
more
for
your
previous
one.
So
maybe
good
idea
to
take
a
look
at
I,
don't
know
if
it's
very
could.
M
C
B
B
C
Q
Also,
we
have
run
some
experiments
based
on
least
my
method
and
a
fine,
and
we
find
that
we
can
get
a
big
chance
to
find
a
better
pass
paste,
the
home
tense
of
clouded
routers
and
such
approach.
Currently
they
become
much
much
more
approach,
a
practical,
because
it
is
easy
to
to
build
a
pair
of
us
via
the
loader
in
the
different
geography
sites
in
a
cloud,
and
it
is
intensive
and
easy
to
provisioning
and
some
some
how
the
provider
even
provided
the
instance
with
enhanced
the
network
performance
for
sale.
Q
Q
Q
Now
this
is
the
result
of
patent
laws
in
the
experiment.
We
can
see.
Some
paths
have
high
and
straighten
all
the
time.
Q
And
we
also
figure
out
some
problems
in
the
will,
a
paste
cloud
and
network
and,
let's
say
some
tendency,
sensitive
application
like
video
conference.
Okay
me
as
their
delay
needs
to
be
shorter
than
like
200,
milliseconds
or
300
milliseconds,
for
example,
and
in
the
meanwhile
the
end-to-end
RTD
is
almost
enriched
data
limit.
So
the
traditional
end-to-end,
the
packet
recovery
mechanism,
is
not
good
enough
to
me
to
the
request
so
better
record
here,
overpass,
therefore,
the
internet
is
the
wanted.
Q
Actually
there
are
some
companies
are
doing
this
in
the
market
and
also
we
have
some
potential
message
to
fix
this,
like
the
no
code
which
has
the
mission
over
the
crowded
router
and
the
FEC
over
single
or
multi
pass
segments.
So
why
do
we
need
a?
But
now
because
the
currently
the
cloud
in
a
always
allows
the
better
has
to
be
a
creditor,
and
it's
enacted
a
test
on
the
the
cloud
allows,
the
virtual
load
and
in
the
Colorado,
naturally
breaks
passed
to
a
multiple
paths.
Q
Q
Currently
over
the
the
cloud
router,
the
the
overlay
know
that
could
provide
a
congest,
much
more
congestion.
Information
to
the
sender
and
a
sender
could
decide
if
decreased
any
rate
is
necessary
and
how
much
to
decrease,
but
the
potential
by
circuit,
just
as
I
said
that
if
and
now
the
Endora
could
provide
a
richer
congestion
information
to
the
sender.
G
I
had
a
Rick
Taylor,
just
a
clarifying
question
I,
and
is
it
maybe
me
being
stupid,
probably
is
what
is
the
difference
between
a
cloud
Internet
and
a
complex
transit
network
I,
don't
understand
what
what
is
the
difference
that
what
I
do?
Can
you
describe
a
cloud
Internet
to
me
from
just
a
complex
backbone
Internet,
you
know
connected
Network
Oh.
Q
Q
R
How'd
networks
are
in
I
mean
it's
a
private
network
right,
except
people
can
connect
in
and
use
and
they
can
connecting
privately
or
they
can
connected
via
VPNs
or
whatever
to
get
to
there
by
private
cloud.
Then
inside
the
cloud
provider
they
have
their
own
connectivity
to
go
between
different
geographical
regions.
Lee's
talking
about
is,
if
you
want
to
buy,
that
you
get
private
transit
through
sorry,
but
these
cloud
providers
in
general
are
not
internet.
R
R
S
O
O
There
an
assumption
that
you
are
using
the
clouds
to
do
complex
processing
on
the
packets
using
some
of
the
compute
infrastructure,
that
is
in
the
clouds,
or
are
you
just
using
them
as
a
routing
over
Lake
and
just
essentially
running
a
software
route,
sir,
in
a
cloud
based
mode,
I
mean
I,
think
it's
just
using
it
as
a
routing
mode.
Nobody.
G
Q
Q
Q
We
want
to
attack
the
opportunity
to
do
the
loops.
Motorized
provides
a
chignon
path.
Segment.
I'll
refer
to
this
picture
below
the
end-to-end
a
path
we
have.
Multiple
overlay
did
the
past
segment
between
overlay
loads
away,
and
we
can
try
to
solve
the
problems
mentioned
before,
like
the
slow
recovery
over
long
haul
and
the
inaccuracy
in
sending
rate
decreased
at
the
sender,
and
also
this
solution
has
some
other
issues
should
be
a
gesture
like
as
an
impairment,
temporary
outage
of
the
word,
hope
and
remedy
the
capacity
of
the
ovens
for
your
notes.
C
K
Adrian
Farrell
I'm
that
previous
slide
I
I
want
to
pick
again
at
the
definition
of
the
word
path,
because
when
we
have
a
path
segments
in
the
network
layer,
this
is
a
different
path.
Type
than
a
part
in
the
transport
layer
and
I
would
have
thought
that
if
you
want
to
talk
about
transport
paths,
the
path
segments
needs
to
pop
up
into
the
transport
layer,
I
may
be
being
really
pedantic,
but
so
what
your
your
picture
is.
Fine.
The
labels
on
your
picture
upset
me.
K
T
Q
And
so
the
elements
of
solution
we
think
there
are
three
are
key
elements
to
address
their
problems:
local
recovery,
congestion
control,
interaction
and
the
traffic
is
reading.
We
come
by
for
the
local,
which
has
local
recovery.
We
can
do
the
work
on
Twitter
based
on
the
entire
tunnel,
which
aggregates
the
fellows
together,
and
we
can
do
the
nos
detection,
which
has
mission
and
RTD
measurement
between
the
events
between
the
notes
and
also
the
ring
during
the
local
recovery.
Q
We
need
to
pay
attention
on
how
to
limited
limited
ly,
which
has
a
mission
attempts
and
how
to
control
the
fe
Fe
C
replication
intensity
for
the
congestion
sure
in
interaction.
We
definitely
don't
want
to
get
a
competing
between
the
local
reach
at
the
mission
and
the
e3
continuous
chain
we
may,
but
we
can
Twitter.
We
can.
We
may
expose
some
appreciate
here
to
see
congestion.
Can
you
signal
from
the
loops
to
the
it
we
transport
and
then
we
have?
We
made
spotter
ecn
too.
E
Q
E
Gave
you
way
more
of
my
opinion
than
you
probably
wanted
to
hear
during
the
site
meeting?
So
so
all
I'm,
gonna
repeat
it
at
the
foot
for
this
particular
group
right
you're,
giving
the
same
presentation
you
gave
at
a
site
meeting
which
is
I
think
way
too
broad
I
think
the
the
keep
it
is
this
signaling,
or
at
least
sort
of
the
conversation
of
this
thing
with
the
transport
that
that
might
be
the
path
away,
a
bit
that
you
might
want
to
get
feedback
on
here.
G
Sorry,
Rick
Taylor
again
I'm
just
trying
to
work
out
what's
going
on
here
and
I'm
a
bit
slower
than
everyone
else
in
the
room.
I
think
so.
This
is
as
I
understand
it.
You're
trying
to
say
I,
don't
quite
get
what
loops
is
it's
it's
a
signaling
protocol
between
your
tunnels
so
that,
although
your
packets
are
living
within
a
tunnel
its
to
signal
the
information
by
the
fact
that
it's
actually
an
overlay
on
top
of
a
much
more
complex
underway
or
are
my
miles
off.
N
T
So
I
think
what
he's
trying
to
do
is
describe
the
whole
thing,
but
the
whole
thing
includes
components
that
somebody
has
to
do
it
and
we
part
of
what
this
is
trying
to
do.
So
somebody
has
to
buy
those
loud
routers
or
pay
for
them
and
set
up
paths,
and
maybe
you
measure
them
put
a
controller
somewhere
who
has
a
global
overview
over
the
health
of
everything
that
is
already
happening
and
if
you
can
go
to
the
previous
slide.
Thank
you.
T
So
the
question
is
simply:
is
there
something
that
can
be
run
between
oh
and
one
and
one
true,
and
between
oh
and
went
over
three
and
between
the
ingress
and
egress
that
might
be
used
to
improve
what
we
have
a
trance
forty
thing
so
or
lutely
I?
Think
whatever
you
you
think
about
it,
but
not
a
network
thing,
but
a
thing
that
actually
looks
at
packets
and
makes
sure
they
they
get
there.
So
if
something
is
lost,
you
recover
them,
and
this
is
what
loops
is
about.
So
it's
not
trying
to
solve
the
the
problem.
T
How
do
I
get
the
best
path,
I
need,
and
so
on
somebody's
already
solved
it.
It's
just
not
now
that
I
have
those
a
path.
How
do
I
get
local
transport?
The
lower
blue
things
running,
and
the
other
question
of
course,
is
how
to
avoid
that
fighting
against
the
upper
layer,
transport,
but
exactly
the
inverse.
How
do
I
get
these
two
transports
to
live
forever
in
Hamlet.
R
O
M
Spencer
Arkansas
I'll
just
be
real,
quick
and
say
you
know,
focusing
on
the
asking
the
group
and
everybody
to
focus
on
the
path
parts
of
this,
because
we
can
reconstruct
transported
on
a
single
path
all
by
itself,
but
especially
the
thing
that
you
had
on
that.
The
other
slide
that
you
could
showing
that's,
got
the
most
via
past
flooding
and
traffic
splitting
in
traffic,
recombining
and
stuff,
like
that
at
the
bottom
and
they're,
probably
starting
to
get
into
the
number
two
things
like
that.
M
The
way
you
say
this
is
be
thinking
you
know,
whatever
whatever
anybody
else
is,
you
know,
can
help
you
with
definitely
the
path
that
we're
networking
research
group
has
got
to
be
thinking
about
those
kinds
of
things,
because
nobody,
because
nobody
else
is
thinking
about
them.
So
thank
you
for
bringing
the
work
here.
Q
Think
there
are
some
work
items
behind
it
relevant
to
this
research
group
like
the
traffic
is
reading
and
a
multipass
utilization.
So
we
want
to
attract
your
feedbacks
and
we
we
also
have
a
live.
What
has
better
running
in
the
internet?
So
if
you
are
you
sitting
it
please
come
to
me.
Thank
you.
Thank.