►
From YouTube: IETF105-LOOPS-20190722-1000
Description
LOOPS meeting session at IETF105
2019/07/22 1000
https://datatracker.ietf.org/meeting/105/proceedings/
B
If
we
can
work
our
way
down
to
one
boss
in
the
room
at
the
time
at
a
time,
it
will
probably
be
helpful
to
the
area.
Directors.
I
am
Spencer
Dawkins,
and
this
is
Oh
waitron.
We
are
your
Pepe,
both
chairs
for
the
gluts
pop,
if
you're
in
the
loops
pop
you're
in
the
right
place
and
if
you're
needing
to
be
somewhere
else,
we'll
miss
you.
B
B
So
good
excellent,
so
we
will
go
with
this
agenda.
Please
remember
that
this
stuff
is
not
working
group
forming,
which
is
means
that
we're
thinking
I
wanted
to
do
a
little
scope
scoping
for
our
discussions,
we're
not
replacing
the
internet
quick
or
TCP.
We
are
talking
about
optimizations
where
things
work,
but
don't
always
work.
B
We
are
not
changing
the
indian
transport
protocol
payload
and
our
goal
for
this
off
is
that
we
agree
on
what
happens
so
there's
a
lot
of
things
we
could
talk
about
for
two
hours,
but
I
would
like
to
direct
your
attention
to
helping
us
find
out
what
needs
to
happen.
Next,
our
face
to
face
time
is
precious.
B
This
is
not
a
work
group
forming
both
because
for
my
other
reasons,
the
proponents
were
meeting
for
the
last
day
and
a
half
and
they
learn
well.
They
were
learning
a
lot
from
each
other.
What
I
think
this
means
is
that
people
are
different.
People
are
working
in
the
same
space,
but
since
there's
no
IETF
activity,
yet
they're
not
doing
things
the
same
way,
and
there
wouldn't
be
you
know
anything
they
produced
would
not
be
produced
providing
the
same
services.
B
B
B
C
A
Can
send
it
to
you
afterwards,
but
to
summarize
its
one-third
transport
one-third
Internet,
one
tenth
on
the
application
to
people
on
operations,
five
people
on
measurement
to
one
and
a
half
and
security.
Perhaps
a
third
of
the
room
has
read
the
problems,
opportunities
draft
and
we
have
sort
of
1012
people
who
are
actually
working
on
products
in
this
area
or
systems
in
this
area.
B
Fabulous
thank
you
so
I'd
like
to
just
put
the
questions
to
guide
us
between
now
and
ITF
world.
Six
up
we're
going
to
loop
back
to
this
slide
at
the
end
of
at
the
end
of
our
discussion
time.
But
this
is
these
are
questions
that
I'm
going
to
be
asking
or
hums,
and
my
client,
if
you're
humming,
no
to
help
help
us
understand
why
not
and
so
I
say,
you'll
see
the
slide
again,
but
I
wanted
you
to
have
it
in
your
mind.
Since
we
started
the
discussion.
E
E
E
More
interestingly,
if
you,
if
Peck
loss,
is
not
a
problem
for
you,
you're,
probably
also
in
the
wrong
room,
because
all
we
are
going
to
do
for
the
rest
of
the
morning
is
looking
at
optimizing
things.
So
we
have
less
packet
loss
and
I've
also
mentioned
that
one
form
of
pick
loss
for
instances
tail
loss.
Michael
has
provided
this
nice
demonstration
of
tail
loss,
and
so
there's
always
a
little
bit
of
latency
consideration
behind
that.
E
But
what
we
are
primarily
try
to
do
here
is
reduce
packet
loss
and
the
the
approach
is
to
do
the
simplest
thing
that
could
possibly
work,
which
is.
We
have
a
network
path
between
two
hosts
that
are
oblivious
to
what's
going
on
here,
and
we
have
two
nodes
in
the
network
that
cooperate
both
are
on
paths.
They
cooperate
in
reducing
the
loss
and
it's
about
compensating
for
losses
that
happen
in
the
path
between
the
two
nodes.
So
I
think
it's
hard
to
do
something
that's
even
simpler
than
that.
E
So
that
is
what
we're
trying
to
do
here
and,
of
course
there
are
things
like
retransmissions
and
FEC
and
and
things
we
can't
could
do
or
could
not
do
and
that's
possibly
something
that
a
working
group
could
let
to
find
out
what
exactly
you
want
to
do.
But
right
now,
let's
try
to
understand
the
problem.
E
So
the
point
is
to
recover
packets
locally.
So
locally
has
two
meanings.
It
means
close
together
low
latency,
but
it
also
means
with
no
impact
on
the
rest
of
the
network,
and
that,
of
course
requires
a
little
bit
of
thinking
how
you
really
can
make
sure
that
there
is
no
impact
on
the
rest
of
the
network,
but
the
main
thing
is
doing
it
locally
allows
us
to
do
it
with
low
latency.
That's
one
of
the
objectives.
The
second
thing
is,
we
want
to
do
it
in
the
network,
so
host
participation
is
not
required.
E
That
doesn't
mean
that
there
shouldn't
be
activities
with
host
participation.
That's
fine,
but
it's
not
what
what's
on
the
agenda
today.
So
we
want
to
do
this
in
the
network
and
something
because
we
we
don't
want
the
whole
to
participate.
We
don't
want
to
touch
the
hosts
packets,
so
traditionally
peps
have
been
very
intrusive
and
and
have
looked
into
packets
and
actually
changed
packets,
and
this
is
not
the
objective.
The
objective
is
that
the
packet
that
comes
out
of
loops
is
the
same
one
that
came
in
it's
just
more
likely
to
actually
really
emerge.
E
Then
it
would
be
without
loops,
and
this,
of
course
means
it
works
with
any
kind
of
IP
packets.
So
encryption
is
not
a
problem
for
for
what
we
are
trying
to
do.
So
don't
look
and
don't
touch
so
with
these
three
framing
things,
copying
things
it's
pretty
clear
that
any
solution
would
have
retransmission
forward
error,
correction
or
both
and
right
now
we
are
looking
at
the
solution
that
actually
can
do
both
and,
of
course,
for
retransmission.
E
So
if
the
terms
reverse
information
and
forward
information,
I
come
up,
these
are
things
that
need
to
be
done,
and
these
are
the
things
that
actually
we
want
to
send
it
as
here,
so
we
can
interoperate.
The
same
thing
is
true
for
forward
error
correction,
since
that
may
not
be
as
familiar
to
people,
it
means
adding
redundancy
to
the
packets.
So
if
you
lose
one
out
of
a
group
of
packets,
you
can
recover
independent
of
which
of
the
packets.
Your
us.
E
This
has
some
latency
advantages
and
it
gets
really
good
when
you
do
a
dynamic
selection
and
adaptation
algorithm
for
the
parameters
of
the
fact
things
like
block
size.
If
you
have
a
block
size
and
fake
rate,
how
much
redundancy
do
you
actually
add?
It
helps
to
dynamically
adapt
there
and
to
be
able
to
adapt.
You
need
measurement
and
we
will
see
a
few
other
places
where
measurement
is
useful
and
finally,
it
turns
out.
There
are
some
some
hybrid
approaches
where
you
react
to
a
neck
by
adding
FEC.
So
this
is
not
not
out
of
scope.
E
What
we
don't
really
want
to
spend
a
lot
of
time
on
is
things
like
protocol
setup
negotiation
and
so
on,
we're
assuming
this
that
this
happens
in
an
environment
where
we
have
some
controller
thing
that
does
these
things
for
us
and
we
are
hand
waving
there.
This
is
not
meant
to
be
part
of
the
effort,
but
of
course
we
need
to
understand
what
information
needs
to
be
in
that
setup,
so
maybe
in
the
end
there
will
be
a
yang
model
or
something
like
that.
E
Ok,
the
other
part.
As
I
said,
we
don't
want
to
influence
what's
outside
there
and
and
the
most
important
thing
is.
We
don't
want
to
blow
it
up,
and
this
means
we
have
to
be
careful
about
concealing
packet
losses,
because
if
you
completely
conceal
all
packet
losses,
then
of
course
the
end
hosts
will
ramp
up
and-
and
you
get
into
all
kinds
of
problems,
because
you
will
increase
congestion.
So
a
necessary
component
here
is
congestion,
feedback
to
the
end,
hosts
and
yeah.
E
E
The
permanent
disincentive
everybody
is
waiting
for
easy
end.
Actually,
some
informal
measurements
make
me
very
optimistic
about
ecn
about
the
percentage
of
traffic.
That
already
is
easy
and
caliber,
but
that's
maybe
not
for
this
of
to
discuss
and
the
other
observation
is.
We
assume
the
transfer
protocols
on
the
hosts
will
improve
over
time
and
we
want
to
play
the
puck
a
little
bit
to
what,
where
they
will
be
yet
not
where
they
are
now.
E
So
we
are
assuming
more
easy
and
we
are
assuming
more
time-dependent
loss
detection
stuff
like
in
rec,
instead
of
packet,
number
dependent
loss,
detection
and
so
on.
So
there
are
a
number
of
improvements
that
may
may
shape
the
optimal
solution
of
things
for
loops,
but
since
we
are
not
picking
anything
today,
that's
just
something
to
keep
in
mind
yeah.
E
E
What's
not
in
scope,
but
what
maybe
at
some
point
some
people
want
to
do
is
adding
multipath
to
the
picture.
Well,
traditionally,
I
would
propose
adding
multicast
mobility
and
security.
That's
always
the
three
things
that
make
things
interesting,
but
multipath
is
joint.
That
list,
and
also
we
are
not
we
into
diagnosing
that
path
segment.
We
have
ways
of
diagnosing
paths,
also
IOM
and
so
on.
This
is
not
really
what
what
we
are
trying
to
do
here.
E
Mtu
handling
is
not
something
we
will
be
the
first
to
solve,
I
mean
it
has
been
tried
before,
and
we
know
that
there
are
a
number
of
solutions
that
are
not
always
very
satisfying,
but
we
will
just
live
in
that.
Thank
you
and
finally,
since
this
needs
tunneling,
we
probably
want
to
use
some
tunnel
encapsulation.
E
E
E
E
H
H
E
H
E
That's
something
lot
of
things
we
have
to
look
at
and
there
is
a
number
of
things
you
can
do
relatively
safely
and
there
are
a
number
of
things
that
may
be
a
little
bit
aggressive
and
then
we
are
right
there
in
congestion
control
and
where
we
have
a
number
of
algorithms
and
mechanisms
to
choose
from
and
there
will
be
BCPs
and
and
everything
I
think
this
needs
to
be
examined.
I
just
want
to
point
out.
We.
G
B
Want
to
do
that
might
come
back
to
say
real
quickly
here,
one
of
the
things,
one
of
the
questions
that
it's
on
our
list
of
questions
is
how
much
you
know
how
much
of
this
is:
what's
research
and
what's
engineering,
so
we
you
know
we
are
kind
of
headed
towards
that
question
in
the
first
couple
that
have
come
up
and
I
wanted
to.
Thank
you
all
for
helping
us
to
understand
that
that
one
of
the
questions
so
tender
than
it
is
most
you
all
david.
I
Black
as
a
transparent
group
chair
or
one
of
the
chairs,
want
to
quick
get
up
to
do
two
quick
plugs
from
labor
at
first
for
all.
Bob
Brisco
who
just
sat
down
has
written
a
couple
of
drafts
that
are
that
are
mostly
done
in
the
working
group
headed
for
IETF
last
call
soon
of
important
interests
of
this
group
is
that
they
explain
a
bit
about
how
to
handle
EC
and
a
tunnel
a
tunnel
ich
egress
and
particular
bob
has
written
some
text
on
fragmentation
that
might
also
in
might
also
apply
to
FEC.
I
If
you
don't
look
at
it,
look
at
at
the
details
to
closes
on
cars
looking
that
at
those
drafts
one
of
them
has
Easton
and
cap
my
name.
The
other
has
RFC
6040
updates
shim
in
the
name.
We
apologize
for
the
not
exactly
intuitive
draft
names
and
then
having
mentioned
tunnels,
there's
a
long-suffering
draft
in
antic
area
on
tunnels.
Please
read
that
and
don't
reinvent
it.
I
Yeah
there's
there's:
there's
2tsp
WG
drafts
one
sec
and
cap,
the
name
one
has
RFC
6040
updates
shim
in
the
name.
Oh
and
there's
an
indie
area
draft
on
tunnels
and
of
the
3d
interior
draft
is
probably
the
most
important
because
it
reflects
a
bunch
of
things
learned
learned
along
to
over
a
long
time.
The
hard
way
about
tunnels,
Thank
You,.
J
Ted
lemon
so
to
me
so
I'm
a
little
frustrated
by
what
Carsten
just
said,
because
to
me
the
most
interesting
problem
that
that
needs
to
be
solved
in
this
space
is
the
is
the
problem
of
the
edge
device,
the
leaf
device
talking
to
the
border,
router
between
and
I
a
constrained
network
and
a
bigger
network?
And
so
if
that
problem
is
out
of
scope,
then
I
actually
have
no
interest
in
this
work.
That's
not
to
say
that
I!
Don't
don't
think
it's
a
good
idea!
J
K
Sniffing
Vega
one
thing:
one
thing
that
came
to
my
mind
is
I
think
this.
This
problem
that
was
described
here
is
at
least
for
many
more
tricky
links
solved
in
proprietary
ways
by
basically,
everyone
and
I
think
it's
also
quite
common
that
the
that
said,
when
you
have
a
satellite
link
that
your
satellite
uplink
and
your
satellite
downlink
and
the
boxes
attached
to
it
where
something
like
this
has
to
happen,
are
from
the
same
vendor,
and
they
do
them
and
a
specific
thing.
Why
is
that
not
sufficient
anymore?
Are
we?
B
L
You
so
I'm
going
to
present
a
use
case,
so
hopefully
some
of
the
questions
can
be
answered
when
we
have
a
very
specific
use
case.
So
here
here
is
the
usage
scenario.
We
are
trying
to
introduce
thinking
about
intercontinental
when
past,
for
example,
from
Paris
to
Beijing,
either
over
NPSL
over
Internet,
but
here
we're
trying
to
focusing
on
over
the
public
Internet.
So
we
find
out
as
the
default
path
does
not
always
keep
the
latency
we
required
or
the
best
latency.
So
what
we
are
trying
to
do
is
look
at
the
small
square.
L
Here
we
create
the
workload
from
multiple
clouds
in
different
geographer
sites
to
build
a
better
web
pass
via
the
overlay
nodes,
those
square
boxes.
Actually,
the
overlay
notes
record
crowd
the
Internet
network
science
or
something
so
we
have
put
this
virtual
nodes
or
cloud
routers
globally.
Then
we
have
experiments
based
on
37
cloud
routers.
Then
we
find
out
wisdom.
We
have
71
percent
chance
of
finding
a
better
path
in
terms
of
latency.
So
what's
next
we
find
out.
Even
we
have
a
selected
path,
gives
a
better
latency.
The
loss
still
exists.
L
Then
there
are
some
pretty
well-known
negative
impacts
of
packet
loss
in
Longhorn
Network,
the
Longhorn
Network.
Here
we
refers
to
the
long
pipeline,
at
least
like
tens
of
hundreds
of
milliseconds,
so
there
are
at
a
loss
problem
for
short
flow
which
possibly
caused
by
the
timeout,
possibly
a
few
seconds
at
the
sender,
or
it
may
take
an
additional
Artie
T
for
T
spirit
transmission
in
so
the
long
flow
completion
time
is
is
expected
in
this
case
and
for
large
flows.
L
The
throughput
is
the
large
flow
I
mean
the
cares
most,
so
there
are
chances
that
the
TCP
sender
actually
reduce
its
sending
rate,
even
when
the
loss
is
not
caused
by
a
persistent
congestion.
So
in
summary,
the
packet
loss
negative
impact
most
because
of
the
internal
transmission.
It
takes
time,
especially
in
long-haul
network,
so
too
have
some
further
study
on
the
packet
loss
pattern.
We
we
have
this
picture
sorry
syllabus
little
bit
more,
but
for
those
is
in
Chinese,
but
you
can
guess
there.
There
are
locations,
I
mean
they
are
Shanghai
by
Eugene
I.
L
Valley
and
like
San,
Paulo
or
somewhere,
so
each
pair
of
them
there's
the
small
square
here
actually
captures
the
loss
rate,
so
it
can
be
easily
identified
that
the
loss
over
past
segments
has
very
different
characteristics,
some
Dom
them
the
loss
is,
is
persistently
high
and
some
some
of
them
the
loss,
almost
can
be
ignored
in
some
random.
The
laws
vary
over
time,
for
example,
higher
getting
higher
over
the
peak
peak
hours
yeah.
L
So
in
our
usage
scenario,
there
are
at
least
two
opportunities
to
new
opportunities
we
have
now
with
where
we
find
out
that
can
solve
the
packet
loss
problem.
The
first
one
is
in
this
cloud
internet
we
have
overlay
nodes,
they
partition
the
whole
heads
into
shorter
segments,
naturally,
and
we
can
enable
the
per
segment
operation,
for
example,
quicker
recovery
from
loss
comparing
to
entry,
and
also
we
can
do
the
adaptive
recovery.
So
the
adaptive
here
means
for
each
of
the
segments.
L
L
Providing
the
complex
features
like
detection
recovery
measurement
is
a
marking,
others
things
so
here
this
pay,
trying
to
show
a
little
bit
how
the
segment
based
merriment
can
help
us
help
determine
the
cause
of
a
packet
loss.
Look
at
the
picture
here.
The
left-hand
side,
actually
I,
think
is
from
where
Frankfurt
or
Shanghai
on
the
right
side
from
Frankfurt
to
Shanghai
and
the
left
side
is
from
Shanghai
to
u.s.
West.
So
the
blue
is
the
loss
rate.
L
The
red
is
the
RTT,
so
we
can
see
there
is
a
strong
correlation
in
these
two
cases
so
that
somehow
in
ties-
if
it
has
such
pattern
the
high
correlation
pattern,
then
there
is
a
loss.
Then
we
check
that
at
that
time
the
delay
is
high.
Then
we
it's
highly
possible
that
losses
caused
by
a
congestion.
Otherwise,
it's
possible
that
caused
by
a
non-contrast
reason,
so
why
we
care
about
this.
Remember
the
slides
that
are
shown
by
Caston.
Somehow
we
want
the
feedback,
the
congestion
information
to
the
sender.
L
So
that's
how
the
segment
based
information
helped
us
I
believe
in
the
solution.
Sketch
presentation
may
have
made
touch
more
on
this.
So
to
summarize,
I
have
introduced.
That
is
a
particular
scenario
in
the
overlay
nodes.
Allow
us
to
improve
the
loss,
the
packet
loss
over
some
specific
channel
based
path
segments
in
we
are
requiring
mechanism
to
be
defined
to
achieve
the
local
recovery
and,
at
the
same
time,
minimizing
the
undesired
side
effects
we
I
kind
of
think
the
loops
buys
too
should
buy
to
existing
overlay
tonneau
insulation.
A
D
Gouri
first
and
cartwright
question:
so
we
we
have
these
effects
going
on
at
multiple
layers,
so
I
write
I,
put
my
operator
hat
on
I'm,
doing
stuff
that
late
to
mail,
maybe
layer,
three,
then
I'm
doing
routine
control
to
try
eliminate
these
things.
I've
got
transport
protocols
running
over
the
top.
I
see
real
dangers
that
we
have
too
many
layers
trying
to
cross
optimize
the
same
things
over
slightly
different
time
scales.
Is
this
something
that
you're
considering.
L
Okay,
for
this
one
I
am,
it's
highly
depends
on
their
deployment
because
for
this
one
we
are
thinking
there
are
some
underling
nodes
and
it's
not
under
control
of
the
operator,
who
provides
all
the
small
square
boxes.
So
this
is
an
overlay
note
managed
by
somebody
else.
So
that's
why
we
have
layering
so
naturally,.
D
L
You
I'm
trying
to
say:
actually
there
are
some
underlying
optimization
that
that's
the
I
mean
operators
are
trying
news
right,
guys,
I
I
think
it's
possible,
but
that
part
is
not
the
I
mean
they're.
The
provider
with
this
layer
will
be
worried
about
and
from
some
of
the
experiments
will
show.
Actually
the
latency
I
mean
they,
the
unrecorded
underlay.
Actually,
the
underlay
latency
given
by
them
is
not
satisfied.
So
that's
why
they're,
the
middle
layer
operator
I,
want
to
do
something
by
themselves.
C
Aaron
Falk
Akamai,
thank
you
for
your
presentation
was
very
clear.
I
thought
it
was
very
helpful.
Could
you
go
to
the
slide
that
shows
the
delay
and
loss
rate
and
I
think
this
is
a
the
point
that
Corey
was
making,
which
is
at
every
layer
that
you
are
implementing
loss
recovery?
You
are
converting
loss
into
delay
because
each
layer
is
doing
some
sort
of
loss,
detection
and
then
recovery
to
ensure
successful
transmission.
So
that's
happening
at
the
link
layer
that
could
be
happening
between
routers
you're,
doing
it
between
your
cloud
routers.
C
So
what
that's
going
to
do
is
that's
going
to
mask
some
of
the
signal.
So
if
you
are
using
an
indication
of
delay
to
say
correlated
with
loss
to
say
that
this
is
congestion
related
loss,
you
may
be
may
be
incorrect
in
that,
because
what's
happening
is
that
a
layer
underneath
you
is
converting
that
loss
that
it's
detected
into
delay.
L
So
what
we
are
trying
to
do
is
at
least
we
need
to
do
no
harm,
so
this
is
just
an
example
to
show
in
case
there
is
a
strong
correlation.
What's
possibly
we
can
do,
but
if
I
mean,
if
people
really
have
worries
about
this,
we
can
just
do
the
local
recovery
and
then
let
the
sender
as
they
usually
do,
I
mean
if
one
they
want
to
decrease
the
sending
rate.
So
just
as
a
conventional
TCP
sender,
but
at
least
we
are
to
doing
no
harm
this.
L
L
N
N
So
you
break
it
into
smaller
segments
the
advantages
of
localization,
but
then
the
obvious
problem
becomes
what,
if
I
have
lost
it,
each
segment
and
they'll
have
additive
delay,
which
is
making
the
problem
even
worse.
Oh
it's
just
some
of
the
things
I'm
sure
you're
thinking
about
these
things,
yeah.
L
So
so
that's
why
I
mean
during
the
solution.
Considerations
I
think
we
want
to
make
the
recovery
mechanism
more
adaptive,
so
some
sources
for
certain
segments.
Maybe
we
don't
want
to
enable
it
at
all
for
some
of
them,
maybe
retransmission.
Okay,
now
for
some
of
them,
if
you
see
with
different
redundancy,
might
be
applicable.
So
that's
yeah,
but
we
don't
have
very,
very
specific
solution
right
now,
but
because
this
is
known
working
group
forming
both.
So
that's
what
I'm
thinking
Spencer.
B
B
As
individual
contributor,
so
one
of
the
things
I
wanted
to
be
sure
and
say,
was
again
I'm
glad
that
Aaron
stood
up
and
started
talking
Aaron
and
I
co-chaired
the
pilk
working
group,
which
produced
the
advice
for
subjects
sub
network
protocol
designers
a
long
time
ago,
and
one
of
the
things
that's
in
there
or
is
about
being
aware
of
reach.
You
know
retransmissions.
We
did
that
so
long
ago
that
people
are
still
running
IPO
for
x.25.
You
know.
B
In
the
end,
people
were
still
saying
that
they
want
to
say
your
hops
that
were
completely
reliable,
completely
reliable,
so
those
kinds
of
things
so
we've
had
the
ITF
has
done
work
that
required
a
you
know
that
that
tried
to
help
people
be
aware
of
that
problem
and
I.
Think
what
we're
saying
now
is
that
that
problem
is
at
more
than
one
layer
down.
You
know
it's
more
than
one
layer
for
the
two
layers
that
could
be
arguing
and
so
I.
B
O
O
Innately
Andrew
McGregor,
if
you
hide
or
smear
out
in
time
the
correlation
between
congestive
loss
and
the
delay
you're
doing
harm
end
of
story
because
it
reduces
the
ability
of
the
congestion
control
to
see
what's
going
on.
If,
on
the
other
hand,
you
have
some
level
of
non
congestive
loss,
then
papering
over.
That
is
purely
a
good
thing.
The
question
is:
can
you
tell
the
difference
and
that's
the
that's
the
key
problem
in
all
of
this
yeah
and
the
reason
works
layer
too.
O
By
the
way-
and
you
know,
there's
probably
more
than
four
instances
of
an
algorithm
that
does
exactly
this
for
per
person
in
this
room
running-
is
that
you
know
that
it's
not
congested
was
right.
Wi-Fi
you
dropped
up.
You
know
you
have
an
error
rate,
that's
rather
high
for
an
indifferent
internet
going.
You
dropped
a
packet
because
of
that
we'll
find
just
paper
over
it
right,
whereas
you
know,
if
you
don't
know
on
a
long-haul
path,
whether
it
was
congested
or
not,
you
should
probably
leave
it
in
the
string.
So.
E
Now
let
me
answer
the
other
question,
which
is
essentially,
we
have
survived
the
last
30
years.
Why
are
we
doing
this?
Now?
There
are
a
number
of
things
coming
together
and
the
cloudy
stuff
that
you
talked
about
is
maybe
one
aspect
of
it,
but
I
think
the
important
observation
is
this
is
not
supposed
to
reply.
We've
replaced
the
existing
Internet.
E
This
is
a
particular
performance,
optimization
that
you
can
employ
at
specific
places
in
the
network
that
have
the
characteristics
to
make
this
useful
and
having
a
sizable
part
of
non
congestive
loss
probably
is
a
precondition
to
to
make
this
really
worthwhile.
So
there
is
an
assumption.
There
is
a
controller
somewhere
that
is
looking
at
the
network
and
has
already
has
some
measurement
data,
and
that
helps
you
decide
where
to
put
a
loop
segment
and-
and
we
are
not
to
put
one-
and
the
third
observation-
is
the
the
blue
segments
work
best
when
they
are
shot.
E
So
this
is
not
supposed
to
be
an
edge-to-edge
thing.
This
is
supposed
to
be
in
the
network
deeply.
In
the
network
and
the
final
observation,
when
you
think
about
this
problem,
try
to
strike
from
your
minds
that
a
retransmission
scheme
has
to
do
resequencing,
so
most
people
who
want
to
do
that
something
in
this
space
don't
want
to
do
resequencing
many
link
layer
solutions
today
have
to
do
resequencing,
because
the
link
layers
are
you
find
to
be
sequence.
A
Okay,
Thank
You
Joan
and
Yuen
long
you're
next,
so
that's
one
more
presentation
on
use
cases
for
this
problem
and
then
we're
going
to
talk
a
little
bit
about
solution
sketches
just
in
a
matter
of
time,
keeping
we're
running
a
little
late.
But
I
think
this
discussion
is
very
useful
and
important
to
understand
the
problems.
But
at
some
point
we're
going
to
you
know,
draw
a
hard
line
and
ensure
that
we
get
off
questions
answered
as
well.
So.
P
Q
So
anyway,
so
I'm
going
to
show
you
a
couple
pictures
about
satellite
use
case.
So
basically,
you
know
today,
it's
TCP.
We
put
a
pep
in
there
over
satellite
to
optimize
one
of
the
things
that
optimizes
is
recovery
from
loss
over
the
satellite
link,
a
particular
thing
that
makes
it
a
little
different
than
what
was
talked
about
earlier
is
you're
still
going
to
be
latency
there
even
with
a
loose
based
solution.
But
the
key
thing
we're
looking
at,
though,
is
with
the
move
towards
things
like
quick.
Q
We
can't
do
split
TCP
anymore,
so
we
need
some
kind
of
underlay.
As
was
pointed
out,
you
know
we
actually
have
proprietary
solutions
now.
So
one
of
the
questions
a
couple,
why
are
we
looking
potentially
a
sterilised
one?
Well,
one
is
maybe
we
can
leverage
open
source
solutions,
especially
with
respect
to
solutions
that
include
more
advanced
FEC.
The
other
thing
is
for
my
future
thing,
which
is
out
of
scope.
I,
think
Ted
brought
it
up,
even
though
right
now
we're
not
looking
and
going
to
the
end
host.
You
need
this.
Q
This
part
in
the
middle
to
get
there,
because
I
would
like
to
optimize
recovery
over
that
Wi-Fi
link
at
my
remote
site.
Also,
so
you
know
in
the
longer
term,
I
want
to
build
on
this
solution
to
get
to
the
point
where
I
can
actually
recover,
because
that's
another
thing
that
pept
does
for
me
is:
it
gives
me
the
local
recovery
at
each
of
the
three
spaces,
so
that's
kind
of
where
we're
looking
at
it.
You
know
terms
of
why
we're
interested
in
this
from
the
satellite.
F
To
create
the
problem
here
actually
again
with
the
chair:
we're
actually
having
two
drops
that
actually
want
to
put
fvc
inside
quick
to
deal
with
losses
without
having
another
layer.
So
how
do
you
go
well?
How
are
you
going
to
deal
with
essentially
two
layers
of
FEC,
one
below,
which
is
what
you
want
to
do
in
loops
and
the
one
that
we
already
have
inside
quick?
Why
do
we
need
to
loose
well.
Q
I
I'm
actually
very
interested
in
that
solution,
also
because
I
actually,
because
it
can
learn
something
about
the
network
and
be
very
specific
to
the
transport
protocol.
This
is
more
generic,
but
also
you
know,
hopefully
I
would
say.
I
would
set
this
up
to
be
intelligent
enough.
That
I
wouldn't
use
this
one
if
I
didn't
need
it.
Q
If,
if
it
was
there
or
maybe
I
use
this
one,
you
know
quick
still
going
to
have
a
learning
curve
to
figure
out
that
I'm
going
satellite-linked,
so
I
think
they
could
play
together,
but
they
are
actually
there's
two
different
approaches
and
I'm
actually
interested
in
both
solutions
towards
us.
The
FEC
inside
quick
is
very
interesting
to
me.
You.
F
Know
I
think
what
I
hear
is
that
there
seems
to
be
a
gathering
of
a
ton
of
different
pieces
of
information
that
come
from
a
ton
of
different
groups
and
research
groups
and
I.
Don't
know.
One
task
that
you
guys
want
to
to
take
is
actually
to
see
what
exists
and
what
has
been
done
and
what
can
actually
be
used
here
next
slide
set.
Ok!
Well,
thank
you,
but
what
I'm
saying
is
that,
yes,
there
is
going
to
be
FEC
inside
quick
and
I
hope
that
who
do
not
work
against
one
another
yeah.
Q
Q
F
F
We
have
these
people
coming
yet
another
add-on
to
quit.
That
will
the
last
two
hours
of
sleep,
I
added.
So
yes,
it's
inside
the
research
group
right
now,
but
it
is
not
to
be
a
research
paper.
The
strategy
is
the
minute
that
these
guys
issue
version
one
or
whatever
the
stable
version
they
have.
We
are
coming
in
the
in
the
working
group.
Thank
you.
Okay,.
E
Yeah
cuz
I
I
just
wanted
to
say
again:
we
want
to
play
the
part
to
where
the
entrant
protocol
will
be.
So,
of
course,
yes,
we
are
considering
if
you
see
that
is
being
done
end
to
end
so
that's
useful
stuff
going
on
and
what
loops
can
do
is
provide
FEC
in
places
in
specific
places
in
the
network
where
it's
needed
and
not
having
the
overhead
in
other
places.
So
this
is
100%
complimentary
and,
yes,
the
fun
part
will
be
getting
the
to
dynamic
adaptation.
Algorithms
work
together
correctly.
E
Well,
I,
don't
have
the
research
for
that
yet,
but
again,
there's
a
difference
between
a
protocol
and
a
mechanism,
and
we
can
standardize
things
at
different
times.
So
when
we
understand
good
mechanisms
to
do
this
optimally,
we
should
send
analyzed
those
and
we
should
define
a
protocol
within
which
we
can
do
these
mechanisms.
B
Actually,
I
should
probably
mention
that
we're
kind
of
getting
towards
the
discussions
that
we
would
have
at
a
chartering
time
for
a
working
group
which
it's
now
is
not
be
honest
out
the
conversation
we're
having
here,
but
then
it
is
stuff
that
we
have
to
think
about
and
probably
stuff
that
has
to
appear
in
the
Charter,
but
it's
just
not
necessary
for
us
to
know
what
to
do
next
after
noon.
Today,.
R
Lars
Eiger
chairing
the
quick
working
group,
so
we
don't
have
fact
on
the
agenda
at
the
moment
on
the
agenda
on
the
Charter
at
the
moment,
and
while
there
is
significant
interest
in
having
some
sort
of
effect
in
quickly
at
the
moment,
it's
it's
if
they're
all
individual
proposals
right
and
and
there's
no
working
group
consensus
on
what
to
do
with
this
I
will
know
that
that
fact
was
actually
part
of
Google
quick
at
some
point.
It
was
removed
at
least
one
particular
way
of
doing
effect
and
quick
because
it
didn't
deliver
on
the
promise.
C
I
so
I
think
that
you
know
I
came
here
to
try
to
get
a
better
understanding
of
what
the
problem
is
that
that
the
blue,
who
have
used
cases,
feel
they
need
to
solve
I.
Think
that
will
inform
some
IETF
activity.
Maybe
it
happens
in
a
new
working
group,
maybe
happens
an
existing
working
group
and
also
to
learn
about
some
existing
proposed
solutions
to
try
to
understand
what
the
solution
space
is.
You
know
what's
changed
and
what
are
people
doing
so?
I
think
that
the
network
coding
is
an
important
piece
of
that.
C
Quick
is
a
piece
of
that.
The
the
overlay
stuff
is
a
piece
of
that.
So
I
don't
see.
You
know
this
is
an
informational
bar,
so
we're
just
we're
not
making
decisions
about.
What's
gonna
happen,
we're
trying
to
understand
the
problem,
space
and
so
I.
Don't
think
we
need
to
have
the
argument
about
where
the
work
is
going
to
happen.
We
get
to
do
that
in
a
we're
going
to
performing
Bach.
S
Morning,
everyone,
this
is
John
from
China
Telecom
and,
like
I
like
to
present
a
petition
scenario
that
loops
could
be
applicable,
as
its
mentioned
in
the
draft
I
will
talk
about
a
zombie
six
and
base
that
Enterprise
one
connection
his
kiss
for
loops
after
say,
I
will
take
a
brief
introduction
about
the
background.
China
is
the
largest
public
Internet
backbone
network
in
China,
a
melon
provides
Robin
Internet
and
a
cloud
access
was
for
public
users
and
enterprise
users.
S
Their
entire
network
devices
are
ipv6
enabled
and
we
plan
to
support
SRV,
Six
Sigma
routing
of
ipv6
to
provide
the
path
selection.
To
me,
services
array,
however,
when
we
deploy
some
services
of
the
internet,
for
example,
enterprise
usually
require
network
connection
between
the
branch
offices
or
between
branch
offices
and
cloud
data
center
over
Geographic
distances.
S
The
problem
we
encounter
is
that
the
traffic
over
the
Internet
a
subject
to
lose
during
the
best
effort
networks.
So
there
is
a
urgent
need
to
do
network
optimization
to
provide
high
quality
internet
for
specific
service
that
needed
the
reliability
of
data
transform
the
following
in
the
use
case.
As
the
picture
shows,
there
are
two
branches
of
the
enterprise
which
access
the
internet
through
visa
Vee
for
one
connection
and
recipe
connects
to
a
cloud-based
pub
which
further
directs
the
traffic
to
the
PC
for
cloud
access.
S
You
know
we
see
PSO
and
they
favor
two
node
in
the
network,
so
it
can
be
enable
with
some
whining
I
did
services
to
be
provided
from
providers
work.
So
we
can
see.
There
are
three
typical
services
deployed,
the
yellow
one,
the
yellow
line
represent
one
connection
and
the
green
I
represent
the
cloud
axis
and
the
red
line
represent
the
DZ
interconnection.
S
So
this
is
the
will
be
of
opportunity
for
loops,
which
can
be
enabled
for
the
segments
of
the
scible
paths
to
solve
packet
loss
and
provide
the
better
for
path.
Selection.
With
with
this
deployment,
we
can
provide
her
County
internet
connection
in
terms
of
loss
rate.
So
do
you
think
it
is
so
applicable
use
case
for
loops
that
we
also
should
focus
on
and
I
think
it
can
be
applied
to
the
enterprise
one
connections,
an
area
apart
from
that
s,
our
v6
provider
provide
the
path
selection.
S
A
T
Do
my
best
to
be
yeah
double
time
here,
alright,
quick
overview
of
how
loops
could
work
I
got
the
impression
from
the
discussion
already
that
some
people
tend
to
have
a
specific
image
in
the
mind
of
how
a
loop
system
is
gonna
work
like
it's
definitely
going
to
affect,
or
it's
definitely
gonna
do
resequencing
and
I.
Think
none
of
these
things
are.
None
of
these
things
are
decided
yet.
So
this
is
just
an
overview
of
the
possibilities
that
that
we
have.
T
T
T
T
They
will
need
to
be
some
measurement
that
will
need
to
be
some
congestion,
detection
and
we'll
need
to
think
about
how
congestion
is
signal
towards
the
end
hosts
if
it
was,
if
it
was
detected,
can
be
done
by
dropping
a
packet
which
is
against
the
whole
purpose
of
loops,
but
you
could
drop.
You
know
a
better
packet
in
the
last
packet
could
be
done
using
ecn,
which
is
preferable.
T
Some
concrete
ideas
on
how
these
things
cooperate
are
coming
now,
but
it's
just
a
straw,
man,
the
two
modes
here
that
I'm
going
to
present
to
you.
The
first
is
tunnel
mode
which
is
I
guess
closer
to
what
most
of
the
things
are,
that
you've
seen
so
far
step.
One
of
the
steps
that
you
that
you've
seen
is
encapsulation.
You
would,
on
the
ingress
side
encapsulated
in
something
we
don't
specify
how
yet
you
know
there
are.
The
document
has
caches
of
gooey
and
of
genève
and
how
it
could
be
possibly
done.
T
But
the
point
is,
you
would
encapsulate
and
add
some
information
that
is
necessary
such
that
we
can
reflect,
for
instance,
sequence
numbers
we
can
use,
you
know
proper
X,
so
you
need
obviously
right.
You
need
to
identify
packets.
You
need
the
sequence
number
we
identified
also
some
other
information,
Tunnel
type,
an
actus
arable
flag,
I
get
to
what
that
is
about
quickly
next
slide
and
whatever
might
may
be
needed
by
a
key.
So,
regarding
exact,
desirable
flag,
there
are
two
blocks
that
are
currently
being
envisioned
for
the
feedback.
T
This
box
would
be
just
sent
in
some
way
right.
It
could
be
interspersed,
it
could
be
repeated,
they
could
be
piggybacked
on
packets,
but
the
point
is
that
there
are
two
information
blocks
that
are
transmitted
from
the
receiving
from
the
ink
from
the
egress
back
to
the
ingress.
One
is
an
optional
bottle.
Both
are
optional,
they
don't
always
have
to
be
included
in
every
a
key.
T
One
would
contain
the
PSM,
this
sequence
number
and
an
absolute
reception
time
such
that
we
get
the
delay
signal
that
could
then
be
used
for
as
a
congestion
indicator
and
the
other
one
building
would
contain
an
occupied
map.
That's
based
on
the
packet
sequence
number
and
a
delta
indicating
the
end
of
the
the
last
psn
of
the
bitmap.
T
So
that's
the
feedback
and
then
getting
the
feedback.
The
ingress
would
do
something
right.
It
gets
max
or
it
gets
it.
So
it
learns
about
missing,
missing
sequence,
numbers
from
from
this
occupied
map
or
about
catenaccio,
make
a
decision.
That's
somehow
related
to
the
congestion
estimate
that
it's
taking
possibly
use
this
young.
You
know
if
that,
if
that
works
to
somehow
influence
the
decision
calculate
late,
severe
variation
from
the
timestamps
in
feedback
blocks
and
well,
and
then
it
would
either
retransmit
or
sent
factory
pair
packets
depending
on
how
design
goes
the
egress
on
forwarding
it.
T
T
If
we
can
do
that,
something
that
I
find
personally
interesting
about
this
as
people
were
saying,
you
know
this
is
what
introduced
delay
and
it
would
you
know
if
you
can't
you
know
in
the
worst
case
you
know,
you'll
have
to
you,
have
to
inform
the
aunt
systems
about
a
lot
loss
here.
I
see
that
as
an
opportunity
to
make
use
of
ezn
signaling.
You
have
an
systems
today
that
uses
yen
and
basically
no
equipment
inside
the
network
that
makes
use
of
ezn.
So
here
there
will
be
some
equipment
I.
Could
you
know?
T
T
So
that's
a
summary
slide
of
the
information
exchanged
in
tunnel
mode
on
forwarding
the
packet
sequence,
number
tunnel
type,
actually
terrible
flag.
That
would
inform
you
that
occasionally
you
want
to
have
this
timestamp
included
anything
that's
needed
perfect
and
for
backward,
these
two
blocks,
one
that
contains
the
timestamp,
the
other
one
that
has
this
occupied
map
now,
just
to
show
that
this
whole
thing
could
be
done
in
a
much
less
intrusive
way
as
well
and
a
very
different
way
we
get
to
this
transparent
mode.
T
That's
in
the
appendix
that's
a
bit
more
radical,
and
the
point
here
is
to
to
have
the
least
intrusive
possible
thing.
The
goal
is
to
never
delay
anything
and
to
not
even
tunnel
just
I'm.
Just
just
discussing
retransmission,
you
could
do
the
same
with
FAQ.
You
could
have
all
kinds
of
variations
in
between
the
spectrum
yeah,
but
in
the
simplest
case
you
know
you
would,
on
the
on
the
English
side
just
forward
and
keep
a
copy
of
the
packets
with
the
hash
of
a
packet
so
I
you
could
identify
it.
T
So
it's
just
taking
a
copy
but
forwarding
not
adding
any
header
or
anything.
The
hash
calculation
made
it
many
to
include
data
beyond
IP,
but
this
is
not
relying
on
a
specific
protocol.
Anything
it's
just
taking
the
bytes
and
the
egress
would
answer
in
this
idea
here:
bodek
it
couldn't
neck
right
because
we
don't
have
consecutively
growing
sequence
numbers
we
just
have
hashes
and
the
AK
format
could
be
similar
to
the
tunnel
mode.
T
Now
the
ingress
upon
seeing
that
there's
an
RTO
for
one
of
the
hashes
that
it
has
it
could
make
it
make
a
decision
to
retransmit
packets.
That
could
also
be
that
should
be
done
based
on
a
congestion
estimate
as
before
the
cost
of
a
hash
coalition.
In
this
whole
thing
is
kinda
low,
because
what
that
would
mean
is
you
mister
retransmit
opportunity?
T
If
you,
if
you
have
a
hash
collision,
you
just
can't
store
it
in
your
cache,
so
you've
reduced
the
probability
of
being
able
to
reach
and
submit
something
at
the
egress
we'll
just
forward
so
that
that's
you
know
in
that
particular
case.
That's
all
they
would
be
doing
there
wouldn't
be
any
reordering,
I
think
sending
things
on
without
resequencing
I
mean
yes,
you
have
modern
TCPS
that
can
handle
that.
Well,
you
have
rack.
T
You
have
experienced
loss
detection
mechanisms,
but
I
think
it's
important
to
keep
in
mind
that
for
TCP
s
that
don't
have
that
or
any
mechanisms
that
don't
have
that
you
know
the
worst
thing
that
would
happen
is
that
you
don't
have
the
benefit
of
the
region's
mission
right.
It's
not
going
to
be
any
worse.
If
you
just
forward
you
just
don't
have
any
benefit
in
in
the
worst
case,
then
they're
all
done
would
be
you
udp-based
transports
all
kinds
of
transports.
T
That
might
you
know
not
have
a
big
problem
with
the
reordering
anyway,
so
there
may
not
always
be
a
need
to
delay
packets
sequencing.
To
summarize
this
on
forwarding,
you
wouldn't
add
anything
extra
on
back
or
backward,
you
would
have
roughly
the
same
thing
as
before
this
blocks,
one
and
two
they
would
have
to
look
slightly
different
block.
One
will
be
limited
in
some
way,
because
this
act
is
Arabic
flag
doesn't
exist.
We
don't
have
any
forward
information
right,
yeah
and
then
everything
is
about
hashes.
So
black
two
can't
really
have
this
occupied
map.
T
You
know
we
could.
Maybe
you
have
a
bloom
filter
or
something
like
that.
Some
interesting
way
of
encoding
X
and
that's
that
so
the
point
is:
there's
a
spectrum
of
possibilities
here,
we're
not
trying
to
nail
it
down
to
one
specific
mechanism
just
yet.
Rather
the
idea
could
be
that
we
could
have
a
framework
that
would
allow
to
implement
several
mechanisms.
T
In
all
cases
it
could
be
pretty
beneficial
when
the
RTT
on
the
segment
is
much
shorter
than
the
end-to-end
rgt.
That's
already
well,
I
think
these
things
have
been
said.
You
know,
while
this
next
use
that
fact
and
well
I
believe
in
the
benefit
of
reducing
Talos
yeah
clarifying
question
I,
don't
I,
don't
think
that
I
mean
we're
getting
close
to
this
lot
of
longer
discussions
anyways,
oh
yeah,.
B
S
E
E
Well,
it's
for
any
traffic,
and
the
message
is
that
we
can
work
with
encrypted
traffic
and
loops
does
not
peak
beyond
layer.
Three.
Well,
maybe
the
part
numbers,
but
not
beyond
that.
So
that
doesn't
mean
that
an
implementer
couldn't
apply
some
secret
sauce.
They
still
have
from
the
pet
days
and
do
wonderful
things
by
digging
forward
and
combine
them
with
groups,
but
we're
not
going
to
standardize
those.
So
the
solution
we
are
discussing
here
is
based
on.
Don't
look,
don't
touch?
E
E
Third
question:
how
do
we
transport
the
measurement
related
information
or
actually
any
reverse
informations,
so
any
measurement
related
information
that
is
going
in
the
forward
direction
probably
would
be
put
into
the
encapsulation
as
a
form
of
an
extension
together
with
the
sequence
number.
So
if
you
would
need
to
send
a
timestamp
for
some
reason,
we
would
put
it
there
we're
not
currently
advocating
for
that,
and
the
the
reverse
direction
could
be
done.
The
same
way
we
do
with
the
AK
information.
E
So
again
that
depends
a
bit
on
the
encapsulation.
If
you
have
a
bi-directional
tunnel,
you
might
be
able
to
piggyback
it.
If
your
tunnel
is
Julie
directional,
you
have
to
send
several
packets
for
the
X
anyway,
and
you
can
include
measurement
information
there
and
you
do
the
fullscreen
thing
again.
Code
screen
holds
mean
fullscreen.
I
Carsten,
yes,
David
David,
black,
real,
quick,
real,
quick
note
on
your
second
FAQ,
which
says
this
is
an
l-3
only
mechanism.
I
assume,
that's
that
that's
intended
to
scope
for
whatever
whatever
comes
out
of
here.
Is
that
correct?
Yes,
okay,
one
could
point
out
and
I
apologize
not
doing
this
during
during
the
second
presentation
and
the
satellite
presentation.
I
If
you
look
at
what
a
satellite
pepper
does
it
does
two
things
one
is
it
does
some
things
here
to
to
deal
with
losses
as
soon
as
you
can
figure
out
the
size
that
something
has
not
bounced
off
the
satellite?
The
other
thing
that
it
does
is
it
MUX
with
the
transport
protocol
to
grow
the
window?
Historically,
this
was
needed
because
endpoints
just
didn't
have
enough
buffers
to
fill
the
pipe
up
with
satellite
and
back
the
former.
It
would
be
within
scope
for
loops.
E
Okay,
the
question
that
comes
up
loops
has
some
cost.
Even
transparent
load
has
some
cost
because
you
have
to
send
forward
and
back
the
ancillary
information.
How
do
you
know
that
this
cost
is
actually
worth
it?
And
again
we
assume
we
have
some
some
Network
intelligence,
some
controller
thing
that
understands
what's
going
on
in
the
network.
We
may
want
to
put
something
in
loops
that
might
actually
enable
the
protocol
to
dynamically
be
switched
on
and
switched
off
to
make
this
quicker.
E
If
the
assumption
is
something
is
providing
the
information
and
providing
the
monitoring
that
allows
making
that
call,
yeah
and
I
think
the
the
final
question
has
been
answered,
but
just
to
repeat,
we
need
congestion
relay.
We
don't
want
to
lose
information
in
this
tunnel,
so
we
need
to
do
a
dropping
for
non
easy
and
capable
transports
and
yeah
we
can
do
this
by
by
dropping.
We
can
probably
more
usefully
do
this
by
simply
not
doing
retransmissions
when
we
know
those
would
be
dropped
for
organization
feedback
anyway.
E
Okay,
so
let's
talk
about
related
work
for
a
moment.
Cori
has
a
better
idea,
I'm
looking
forward
to
him
telling
me
after
the
meeting.
So
of
course,
as
we
said,
many
of
us
have
worked
on
systems.
That
did
something
like
that.
Some
people
have
first
sent
mail
about
interesting
papers
about
this.
We
know
that
link
layers
are
doing
that
for
us
all
the
time,
and
if
we
look
closely
at
these
link
layers,
these
are
often
tunnels.
E
R
Does
a
custard
so
I'll
note
that
there's
a
lot
of
related
work,
as
you
say
in
the
ITF,
but
but
the
the
most
sort
of
common
thing
that
was
brought
up
today
are
pets
and
those
we
don't
have
any
idea,
because
the
vendors
of
those
boxes
have
had
no
interest
in
an
IGF
standard
ever
right,
so
I
you
know,
has
that
changed
it
so
bill.
Those
vendors
participate
here
or
your
are.
We
are
we
standardizing
something
that
then
we'll
never
get
actually
shipped
well?
I
can
so.
R
From
the
vendors
that
traditionally,
this
is
very
close
to
a
pet
box,
but
we
don't
standardize
those
here.
We
never
have
not
for
lack
of
trying
simple,
because
the
vendors
weren't
interested
has
that
changed
at
other
vendors
that
traditionally
have
shipped
these
boxes
for
customers.
Do
they
want
common
standards
in
this
space?
Now.
B
Things
that
is
relevant
here
is
that
that's
a
really
good
question
for
a
working
group
charter
time,
but
I
don't
know
if
we're
going
to
be
able
to
figure
out
the
answer
between
now
and
twelve
o'clock.
That
would
guide
us
on
what
we
do
after
twelve
o'clock.
So
I
would
encourage
everybody
to
not
have
a
food
fight
about
business
models
and
things
like
that.
But
it
is
an
important
question
for
us
to
talk
about
at
charter
time.
I.
U
Mean
my
answer
would
be
that
time
is
playing
for
more
and
more
software
based
networks
were
much
larger.
Variety
of
you
know.
Vendors
are
coming
into
play,
so
the
opportunities
I
think
are
something
that
we
can
try
to
leap
onto
right
now.
I,
don't
think
that
traditional
hardware,
vendors
might
be
the
first
ones
to
pick
up
after
the
experience
was
correctly
recited,
but
that's
not
the
market
anymore
alone.
Today,.
C
All
right,
Aaron,
Falk
I,
want
to
respond
to
largest
point
I.
Think
that
I
think
that
what
we've
heard
here
is
expression
today
of
operators
who
see
this
as
a
problem
that
they
want
to
have
solved.
The
fact
that
a
set
of
vendors
doesn't
want
to
solve
their
problem,
for
them
is
irrelevant
right.
Somebody
they
want
somebody
step
forward
and
solve
it.
They're
asking
you:
if
you
have
to
do
it,
if
the
ITF
doesn't
do
it,
then
they'll
find
some
other
solution.
That's
what
is
what
the
pet
benders
did.
V
That
might
be
more
discussion
or
question.
No,
no.
We
speak
about
pets,
but
this
discussion
is
also
relevant
for
all
the
software
define
one
equivalents
that
are
in
the
market
today
that
are
not
interoperable.
So
if
we
want
to
standardize
something,
we
may
want
them
to
be
to
work
together,
but
there
are
already
lots
of
solutions
that
do
this
kind
of
things
and
also
something
that
I
think
is
missing.
W
L
X
Neither
of
those
need
be
the
case
if
you
think
of
path
segments
as
essentially
being
transfer
functions
and
different
path,
segments
having
different
statistical
characteristics.
They
are
different
transfer
functions,
and
so
the
end-to-end
transport
protocol
is
presented
with
a
composition
of
functions
that
it
may
not
be
well
able
to
handle,
and
so
the
different
transport
protocols
with
which
we
are
familiar
makes
certain
assumptions
about
those
statistical
distributions
and
congestion
versus
non
congestion
losses
and
so
on.
X
E
N
Tom
Harper,
so
thinking
about
the
use
cases,
this
actually
looks
a
lot
more
like
a
piece
of
QoS
to
me,
so
we're
basically
offering
a
well.
It
does
in
the
sense
we're
offering
a
path
with
more
reliability
or
lower
latency,
or
something
like
that.
So
if
you
view
it
as
that,
it
sounds
to
me
like
this
could
be
considered
one
type
of
QoS
for
a
path
and
then
something
like
the
pan
or
G,
or
some
of
the
other
efforts
to
make
qos
aware
networking
might
be
applicable.
N
E
N
One
comment:
I
know
you
want
to
keep
this
completely
independent
and
all
layer
three,
but
the
second.
You
have
any
sort
of
multi
path
where
you
have
you
can
take
possibly
two
segments,
you're
gonna
have
to
make
sure
that
you
do
that
per
flow
at
the
transport
layer.
So
it's
it's
inevitable.
You're
gonna
have
to
look
beyond
layer
three
or
use
the
flow
label
or
an
ipv6,
or
something
like
that.
I.
Y
Y
The
approaches
that
we're
looking
at
energy
are
entirely
different
in
that
the
energy
we're
looking
at
taking
the
this
information,
whatever
measurement
information
you
get
from
the
path
that
goes
into
the
deeps
ingress
point
we're
actually
taking
it
and
taking
it
all
the
way
to
the
endpoint
right
like
so,
we
have
a
completely
different
name.
We
want
to
modify
the
endpoint
so
that
it
can
do
paths
where
sort
of
stuff.
That
being
said,
there's
a
big
question
going
on
in
panner
G
as
to
what
is
an
endpoint.
Is
a
tunnel
ingress
midpoint?
Y
C
E
You,
okay,
now
to
my
presentation,
have
really
sad
yet
I
wanted
to
quickly
point
to
four
pieces
of
work
inside
the
aisle
I
eat,
EF
and
actually,
in
one
case
inside
the
IRT
F
that
are
interesting
in
this
context.
One
of
course,
there's
lots
of
work
on
measurements
and
we
want
to
stand
on
the
shoulders
of
those
people
and
not
on
their
feet.
E
So
let's
talk
about
these
four
things
quickly,
I
am
or
Institute
OAM
is
used
to
collect
information
within
the
package.
Why
the
package
traverses
a
path
between
two
points
in
the
network.
So
it's
about
hop,
hop,
hop,
hop
information.
It
might
return
the
measurement
to
a
third
party
using
postcards
and
yeah.
My
observation
would
be
loops
is
really
about
an
ingress
and
egress
pair
and
not
about
lots
of
hops.
E
So
at
some
point
we
won't
may
want
to
mix
that
in
some
form,
so
rubies
may
be
able
to
make
use
of
information
that
I
ôm
provides.
But
right
now
this
seems
to
be
a
little
bit
different.
I
also
uses
the
generic
information
model
approach,
which
is
not
new
in
the
IP
PM
community,
so
we
can
certainly
learn
something
from
there.
So
we
can
map
our
protocol
to
multiple
formats
and
speaking
about
formats,
the
data
formats
that
the
IP
PM
people
have
developed,
and
maybe
some
measurement
methods
are,
of
course,
things
that
may
be
applicable.
E
This
is
a
little
bit
different
because
it's
about
fragments
within
a
packet-
it's
not
about
packets
and
and
a
number
of
parameters,
constrain
the
situation
a
lot
so
that
actually
may
be
more
attractable
than
it
would
have
been
in
the
global,
Internet
and
yeah,
of
course,
again.
The
congestion
control
issues,
the
the
interesting
one
and
the
question
about
the
control
loops
working
against
each
other.
So
this
is
work.
That's
going
on
and
I
would
expect.
Other
pieces
of
work
will
be
going
on
in
the
ITF
at
some
point
when
it's
really
needed.
E
The
sliding
window,
fec
I,
think,
is
interesting,
which
has
has
left
the
network
according
research
group
and
is
now
in
TS
vwg
draft,
and
that's
certainly
something
that
will
go
into
a
good
loop's
solution.
And
finally,
there
is
the
channel
congestion
feedback
framework
well
yeah.
This
is
one
one
more
of
those
TS
WG
drafts,
they've,
like
mentioned
a
few
more
ones
that
we
may
want
to
use.
There
is
an
IP
fix
mapping
in
there.
We
may
want
to
use
that
as
a
source
of
information
elements
that
need
to
be
part
of
loops.
E
C
I,
just
I
just
want
to
challenge
your
framing
of
this
question,
because
it
seems
to
me
that
you
know
we're
motivating
this
by
several
operators
who
say
they
have
a
problem.
You
know
I
think
would
be.
They
haven't
said
that
the
host
participation
is
impossible
from
their
point
of
view
that
it
is
that
it
is
a
it's
a
requirement
that
the
host
cannot
participate,
I'd
be
interested
in
knowing
whether
that's
actually
the
case
or
not.
Yeah.
E
Maybe
I
should
have
been
more
specific
because
in
the
slide
that
John
showed
you
have
this
leaps
loops
thing
in
one
of
the
end
hosts.
But
the
interesting
thing
about
this
loose
thing
is
in
an
actual
implementation.
This
would
be
in
the
VPN
layer.
It
would
not
influence
the
transport
layer
in
the
host,
so
you're.
C
U
D
U
D
B
If
I
could
just
do
it
your
interrupt
here,
it
would
have
been
reasonable
for
us
to
say
at
the
beginning
of
Carson's
presentation
that
this
is
Carson's
view,
and
these
are
the
things
that
the
we
could
talk
about
a
chart.
You
know
and
probably
really
a
charter
time,
so
it's
not
necessary
for
us
to
to
figure
out
what
all
the
linkages
are
really,
but
to
figure
out
where
we
need
to
be
with.
You
know
with
observations
like
Erin's,
so
thank
you
yeah.
Thank
you
that
thank
you
so.
B
U
U
U
B
E
E
E
U
As
you,
yes,
you
just
brought
the
example
right.
If
you,
basically
simply
do
it
sure
implementation
questions
decide
just
you
know
as
part
of
the
network
layer
in
the
host
stack
then
you're
having
exactly
the
same
architectural
model,
you're
just
also
able
to
include
the
first
last
hops.
Yes
in
the
solution,
so
I
don't
think
we
should
go
beyond
that,
but
that
option
certainly
shouldn't
be
excluded.
So
I
think
we
are
actually.
B
Z
B
H
But
Briscoe
again,
I
just
wanna
I
said
I
might
come
back
to
this
and
I'm
coming
back
to
it.
I've
not
heard
an
answer
to
the
question:
I,
don't
get
why
you
want
to
do
something
on
an
overlay,
that's
relatively
easy
on
a
link
and
the
link.
If
the
link
knows
it's
bad,
it
do
it
because
they
want
to
sell
their
technology.
So
why
try
and
fix
something
that
someone
else
has
got
the
motivation
to
fix
anyway,
and
they
can
do
it
really
easily,
and
it's
really
difficult
to
do
just
slightly
above
that
layer.
G
H
You
talking
equipment,
build
a
person
or
operator
person,
yes
both,
but
what
I
was
saying
is
that
those
that
develop
technology
have
a
standard
idea
at
they
are
chiefly
or
whatever
link
technology.
They.
They
have
a
perfectly
good
motivation
to
do:
link
layer
retransmission
if
it's
going
to
make
their
link
better.
D
C
Application
user
and
the
link
designer
may
have
very
different
ideas
of
how
that
link
is
going
to
be
used
and
if,
if
the
link
is
better
than
they
need,
nobody
complains,
except
maybe
about
price.
The
only
goes
worse
than
they
need.
Then
you
then
some
other
party
has
to
try
to
improve
the
data
throughput
right
and
that's
what
we're
talking
about.
Now
right,
the
in
going
the
assumption
here
is
that
the
link
is
not
good
enough
right.
Otherwise,
you
don't
deploy
this
at
all.
E
Danny,
the
other
case
that
you
talked
about
is
we
are
that
the
person
who
wants
to
make
the
optimization
sees
a
path
that
person
doesn't
have
access
to
all
the
individual
links.
Okay
has
the
part,
and
it
once
said
they
want
to
optimize
the
usage
of
their
path,
but
I
actually
wanted
to
give
another
example.
E
E
H
I
was
just
thinking,
Aaron
had
said.
No
I
was
thinking
that
they
big
change.
That
you're
proposing
needs
to
be
split
into
two
parts:
the
other
I
power
on
the
sequence
not
preserving
pop
and
and
and
once
the
link
people
know
they
don't
have
to
keep
the
thing
from
sequence
preserved.
Then
they've
got
a
different
way
of
fixing
their
links.
You
know.
Currently
they
do
it
to
a
certain
level
and
then
they
think
I
can't
wait
any
longer
to
get
this
retransmission,
because
I've
got
to
keep
everything
in
order.
H
H
N
So
to
me
it
seems
like
the
biggest
now
use
case,
of
something
like
loops
would
be
a
long
path.
Delay
say
over
the
Internet
where
one
of
those
segments
within
that
is
low
delay,
but
possibly
high
loss
and
to
me
it
sounds
like
that
would
be
a
mobile
network
satellites
interesting.
But
that
seems
like
that
already
has
a
long
delay,
so
I'm
wondering
or
guests
asking.
Are
there
applications
in
mobile
world
where
we
do
have
that
situation
like
at
the
last
hop
or
Radio
Network?
N
B
Spencer
Dawkins
speaking
as
an
individual
contributor
I
like
Tom's
question
and
I,
would
offer
as
a
semi
friendly
amendment
what
if
there
are
two
what
if
there
are
two
network
segments
like
that
and
and
that
that
you
know
it
seems
to
me
that
we
can't
really
guarantee
that
there
would.
There
would
only
be
one
and
so
to
the
extent
that
there
is
more
than
one
I
think
that
changes
the
way.
We
look
at
the
problem.
Well,.
U
Totally
sacred
I
missed
the
beginning,
so
I'm
not
quite
sure.
If
the
scope
was
more
about,
you
know
dealing
with
congestion,
loss
on
on
congestion
loss
right.
What
I
would
say
is
that
traditionally
you
know
the
non
congestion
loss
is
something
that
you
know
subnets
try
to
get
rid
of,
but
you
know
if
we
look
through
the
industry
that
hasn't
always
been
very
successful,
so
I
think
one
of
the
questions
would
really
be.
U
You
know
how
awaiting
the
scope
of
you
know:
congestion
laws,
local
solving
and
non
congestion
loss,
local,
solving,
right
and
I
think
it
would
really
be
nice
to
have
something:
that's
more
generically
applicable
to
all
type
of
subnets.
If
you
have
a
shocking
subnet
where
it
doesn't,
you
know
the
provided
mechanisms
of
that
layer
to
submit
are
not
good
enough
to
deal
with
the
loss.
It
has
the
non
congestion.
B
A
B
A
B
B
C
Hi
Aaron
Falk
again,
let
me
try
not
to
kill
you
what
I
think
I
heard,
because
this
was
exactly
my
mind
in
thinking
that
this
question,
which
is
we
have
identified
a
bunch
of
problems,
I,
don't
think
we've
identified
how
they
group
together
to
become
the
problem.
There's
a
bunch
of
there's
work,
that's
going
on!
C
There's
a
lot
of
history
here,
there's
stuff
that
is
kind
of
outside
the
scope
of
the
IETF,
and
it's
that
there's
mechanisms
that
are
happening
way
down
in
the
staff
and
in
the
applications
and
I
have
not
come
away
from
this
discussion
with
a
clear
idea
of
the
thing.
The
thing
that's
unaddressed
that
there
needs
to
be
work
on.
So
that's
that's
what
I
heard
I.
U
Was
trying
some
70%
policy,
modulation
I
understand
the
problem,
so
I
think
it
very
much
depends
on
a
lot
of
the
scope
details
right
so
I
haven't
heard.
You
know
just
vague
sub
sensation
of
trying
to
differentiate
between
different
traffic
right.
Obviously,
congestion,
control
expectations
of
this
adhesive
e
are
different
from
TCP
right.
Would
we
be
willing
to
do
that
and
the
whole
discussion
of
why
the
heck
would
we
want
to
exclude
the
last
thing?
So
understanding
comes
a
little
bit
through
the
refinement
of
the
scope
and
I
hope
that
we
can
solve
this.
Y
Burn
caramel,
no
hats
at
this
point
the
so
I
hunt,
yes,
because
actually
I
think
we've
understood
this
problem
for
the
past
quarter
century
and
we've
had
the
problem
for
the
baryon
supporters.
Entry
and
we've
come
up
with
a
bunch
of
bad
solutions
for
it
right.
So
the
the
the
thing
that
I'd
like
to
see
a
refinement
of
is
one
a
little
bit
of
the
refinement
of
the
scope,
but
to
a
little
bit
more
of
the
fun.
None
of
us,
not
the
scope
of
the
problem,
but
also
scope
of
the
solution.
Y
Great,
like
so
a
little
bit
more
discussion
about
which
exact
subset
of
the
we
do
not
have
complete
clairvoyance
for
every
past
segment
of
transport
problem.
Do
we
want
to
solve
here
and
then
a
little
bit
more
of
the
the
reducing
down
the
solution
space
to
something
tractable
I
think
this.
This
ball
was
a
very
good
sort
of
start
to
that
and
I'd
like
to
see
you
continue
but
yeah.
That's
why
I
hummed,
yes
and
still
came
up
with
a
mic
line
and.
B
E
Can
answer
engineering
to
the
previous
thing
because
there
was
some
comments
on
the
microphone
that
made
it
an
important
distinction
between
the
program
and
the
scope
of
the
problem.
I
think
60%
of
the
room
answered
the
question:
do
we
understand
the
problem
in
40%
and
such
I
don't
understand
the
scope
of
the
problem
and
can.
B
We
so
so,
if
I
was
going
to
do
a
friendly
amendment
to
the
question,
that's
on
the
screen,
I
think
I
would
be
suggesting
something
like
is
there.
Engineering
are
people
ready?
Are
there
things
that
we
talked
about
today
that
were
ready
to
do
engineering
that
don't
need
additional
research
and
I
was
thinking
in
before
the
buff
that
if
we
had
enough
people
show
up
saying
I'm
working
on
this
now
that
that
was
at
least
some
people
have
thought
that,
but
the
microphone
lines.
AA
AB
AB
Mean
you
know,
I
mean
to
expand
a
bit.
I.
Think
there's
enough
of
this,
which
is
engineering
that
there
is
a
useful
IETF
work.
We
can
do.
There
are
bits,
I
think
we
don't
know,
don't
necessarily
know
how
to
solve.
I
think
we
don't
necessarily
need
to
know
how
to
solve
them
all
to
do
an
initial
version
of
this
yeah.
It
wouldn't
be
the
first
time
the
ITF
has
chartered
a
group,
but
we
don't
have
all
of
the
answers.
At
the
beginning.
K
So
stiffening
up
I
come
back
to
that
question
which
I
had
originally
I
read
here.
Is
this
engineering
or
is
research
required
blah
blah
blah
I
would
say
absolutely
there
is
research
required,
maybe
not
technically
research
but
I
think
I
think
base
insufficient
input
on
whether
there
is
actually
a
demand
for
such
a
standard
for
standardized
solution
that
I
do
not
see
personally.
B
C
C
How
important
is
that?
How
useful
is
it
how
what
what
set
of
problems
it
solves?
Having
said
that,
you
know
I'm
not
opposed
to
seeing
somebody
go
and
build
something
like
that
and
try
it
out.
I,
don't
know
if
I
would
recommend
that
it
be
used
on
the
internet
or
what
problems
it's
going
to
be
useful
for,
but
so
to
me
this
is
even
with
that
statement.
It's
not
obvious
to
me.
C
It's
it's
in
the
the
gray
area
between
the
IRT
F
work
in
ITF
work
I
wouldn't
actually
be
opposed
to
it
in
either
place
I'd
kind
of
like
to
see
the
thinking
of
how
this
could
work
move
forward.
I
would
also
like
to
see
it
not
interfere
with
some
of
the
other
ideas
for
improving
things.
Like
effect
and
quick
and
the
panel
G
stuff
so
I,
you
know
I
say:
if
people
won't
work
on
this,
they
should
be
able
to
work
on
it.
I
wouldn't
stand
in
the
way.
I,
don't
think.
AC
Was
hurt,
occurred,
I,
say
I
guess,
with
my
IAB,
had
half
kill
turd,
because
I
have
questions
I'm,
not
a
statement
or
iam,
so
I
the
whole
point
of
the
IRT
F
and
I'm
very
glad
that
there's
people
here
that
are
working
on
that
part
of
the
area.
If
it's
not
me,
the
whole
point
of
the
RTF
is
to
eventually
transition
work
into
the
IETF
for
Standardization
and
I.
Think
that
this
this
whole
baath
shows
that
there
is
no
an
effort
or
desire
to
to
transition
to
something
that
might
actually
work.
AC
I
do
think
that
the
proponents
and
the
research
side
need
to
get
together
and
seems
like
there's
sort
of
a
split
between
groups,
and
they
really
need
to
sit
in
a
room
and
say:
okay,
what
elements
are
ready
for
transition
and
what
it's
still
in
research
and
if
solutions
exist.
Great
now
is
the
time
to
to
push
those
forward
into
standards,
so
they
can
actually
be
deployed
and
and
put
into
interoperability.
AC
The
one
concern
I
have
is
whether
the
research
community
in
particular
agrees
that
there
aren't
issues
that
are
hiding
where,
even
though
the
engineering
side
may
say,
we
think
we
have
a
Ellucian,
the
research
cited
say.
No,
you
know
we
haven't
actually
figured
out
like
the
whole
house
congestion
getting
away,
and
how
are
we
going
to
make
sure
that
we're
not
actually
building
adding
that
the
engineering
solution
doesn't
add
to
the
problem?
That's
just
my
thoughts.
B
O
Andrew
Berg,
Riga
I
think
the
answers
to
the
first
two
questions
very
strongly
depend
on
what
the
scope
turns
out
to
be,
because
there
are
things
in
here
where
I'm
sitting
there
is
research
required
in
the
potential
scope
of
this,
and
there
are
other
things
which
you're
like
yeah
sure
we
can
do
that.
That's
fine.
G
D
Control
it
yeah
I'm
I'm,
still
not
very
sure
about
how
all
this
interacts
between
different
layers.
So
there's
this
transport
questions
and
there's
ops,
questions
and
I
guess
this
routine
questions
here
and
I'd
like
to
see
which
ones
of
laws
actually
have
concerns
and
by
whom,
because
the
the
use
case
we
saw
was
simple,
but
our
people
signed
up
against
those
two
use
cases
or
do
they
have
more,
and
so
so
I
see
questions
here
and
I
think
these
are
research
questions
that
we
don't
see
data
now
with
the
answers.
D
E
What
we
also
need
to
do
is
understand
how
to
correctly
use
that
protocol
all
the
mechanisms,
so
TCP
was
standardized
in
1983
or
something
and
76
how
you
look
at
it
and
we
are
starting
to
understand
the
mechanisms
now
and
I
think
we
can
go
ahead
and
do
a
mechanism.
The
mechanism
work
do
protocol
work.
Excuse
me
on
loops
now
and
fully
understanding
that
we
will
have
five
years
or
so
looking
at
all
the
research
questions
that
finally
go
into
DBC
piece
on
how
to
best
one.
E
E
B
If
I
could
do
an
ad
interrupt,
everybody
stay
at
the
microphones
that
still
at
the
microphones
Magnus
asked
if
I
could
do
a
hum.
If
people
believe
that
standardization
in
this
space
is
required
is
required
or
if,
if
it's
not,
and
if
you
think
that
it's
not
a
few
hum
does
not
feel
you
know,
feel
free
to
hop
up
to
the
mic
lines,
we've
got
about
men
and
I
have
to
go,
but
we'd
be
interested
in
hearing
could
I
ask
for
hum
of
people
who
think
that
standardization
in
this
space
is
required?
Can
we
clarify.
B
AB
A
AC
A
U
Doing
it,
so
let
me
bring
up
an
important
point
right,
so
nobody
talked
about
I,
think
analyzing.
What's
already
out
there
in
the
market,
there
are
a
lot
of
proprietary
solutions
to
do
these
things.
They
may
cover
a
lot
of
IPR,
but
they
may
also
set
a
good
amount
of
references
of
you
know
what
we
could
achieve
and
you
know
showing
what
we
want
to
achieve
compared
to
to
that
stuff.
So
it's
ugly
work
to
try
to
do
that
analysis,
but
I
think
it
would
be
very
helpful.
Thank.
AD
Okay,
we
have
some
15
hands,
that's
good
great,
so
my
conclusions
here
is
that
the
scoping
etcetera
in
small
discussion.
We
have
the
loops
but
loops
mailing
lists
to
do
things.
So
please,
if
you're
not
already
subscribed,
go
there
and
let's
have
some
discussions
about
scope,
etc
and
what's
what's
available
or
not,
and
let's
be
done?
Okay,
thank
you.
Everyone.