►
From YouTube: IETF108-LOOPS-20200731-1100
Description
LOOPS meeting session at IETF108
2020/07/31 1100
https://datatracker.ietf.org/meeting/108/proceedings/
A
A
I
see
it
so
I
guess
we're
going
to
start
off
with
the
chair
bit,
which
is
actually,
if
you
can
go
to
the
the
next
slide.
I
guess
is
a
do.
We
have
the
the
agenda
should
be
in
here
somewhere
right,
okay.
Well,
I
can
just
sort
of
do
this
from
let's
go
back.
Let's
start
with
the
note.
Well,
no,
well
very
short,
you
will
be
recorded,
be
nice
be
professional.
A
This
is
an
ietf
meeting.
The
ipr
guidelines
apply.
This
is
friday,
so
you
should
have
seen
this
notewell
at
least
once
the
there's
a
couple
of
links
here,
you
should
have
a
look
at
so
the
repo
for
all
of
this
material.
Is
there
on
github,
loops,
wgitf108
and
notes
we'll
be
taking
in
kodi
md
note
ietf108
loops,
which
is
the
link
that
you
get
to.
If
you
click
on
the
etherpad
link
from
the
data
tracker,
could
I
bug
people
for
note
takers.
A
That's
a
much
better
way
to
put
it.
Who
would
like
to
is
ask
you
a
lot
yeah
who
would
like
to
who
would
like
to
serve
the
community,
I'm
going
to
start
picking
random
names.
I
recognize
from
the
attendees
list.
A
Excellent,
so
go
into
the
code
emd.
So
it's
this
link
here
from
the
can
we
get.
Can
we
get
somebody
else
to
help
you
out.
A
A
So
there's
a
few
people
on
the
attendees
list
that
I
pick
on
quite
often
for
this
don't
want
to
do
that
again,
I'm
looking
at
you
tommy.
A
I
can
do
backup
backup,
perfect,
okay,
perfect.
Thank
you
very
much.
Okay.
We
have
no
takers
next
slide,
so
the
carson
can
you
hit
the
arrow.
A
We've
done
the
concise
note.
Well,
this
is
the
actual
note.
Well,
please
have
a
look
at
this
in
the
slides.
If
you
haven't
seen
it
anything
that
you
say
in
this
meeting
is
a
contribution
to
the
ietf
and
you
should
understand
what
that
means
next
slide.
So
here's
our
agenda.
We
got
10
minutes
for
spencer
and
I
to
sit
up
here
in
babylon,
which
means
we
have
six
minutes
left.
I
think
we've
got
this
tool
fiddling
the
scribe
kidnapping,
oh
jabber
scribes
I
can.
A
I
can
keep
an
eye
on
the
chat
room,
but
I'd
like
somebody
else
to
be
able
to
like
I'm
sharing
this,
so
I
won't
be
able
to
do
that.
Full.
B
A
Cool
and
then
we
move
on
to
agenda
bashing.
Would
anyone
like
to
bash
this
already
well
bashed
into
our
time
slot
agenda.
A
A
Seeing
no
one
in
the
queue
and
hearing
no
agenda
bashes,
we
will
start
five
minutes
early
and
hand
it
over
to
karsten
what
is
loops.
D
Okay,
I
switch
on
my
camera,
so
you
see
me
once
until
my
laptop
has
overheated.
So
this
is
the
the
second
buff
we
are
having
on
loops.
We
had
one
at
iatf
105,
so
I'm
going
to
run
through
this
relatively
quickly
and
focus
on
what
has
changed
since
105.
But
of
course
I
need
to
do
the
whole
thing
for
so
so
everybody
knows
what
we
are
talking
about.
D
So
basically,
this
is
loops
on
on
one
slide,
where
we
see
that
we
might
have
an
end
to
path
and
between
two
hosts
and
we
might
have
a
segment
in
the
middle
of
that
path
that
that
somehow
is
is
not
so
good.
That's
losing
packets
and
the
idea
is
to
to
apply
some
remedy
in
the
network
for
this,
so
we
have
an
ingress
and
an
egress
node,
and
these
run
some
something
that
looks
a
little
bit
like
a
transport
protocol
that
isn't
one
for
recovering
those
packets.
So
it
can
do
reconstruction.
D
Various
ways
of
doing
this
are
possible,
but
the
point
is
the
packet
loss
is
recovered
within
this
short
segment,
so
this
can
be
done
faster
than
the
hosts
can
do
it
among
themselves.
In
the
end
trend,
and
of
course,
the
end-to-end
principle
applies-
that
the
host
will
continue
to
need
to
do
this,
and
that
also
means
that
loops
doesn't
need
to
be
perfect,
so
yeah.
The
the
first
point
is
we
want
to
recover
packets
locally.
D
B
Problem:
okay!
So
so
I
just
uploaded,
I
just
uploaded
new
slides
about
an
hour
before
the
session.
So
that's
what
you're
producing
that's!
What
you're
presenting
right.
D
Karsten
yeah
ma
martin
says
it's
broken
brian
says
it
seems
to
match.
D
Yeah,
but
there
hasn't
hasn't
changed
much.
So
even
if
people
are
looking
at
the
old
slides,
they
should
still
see
that
so
martin
says
meet.
Echo
is
broken,
not
sure
I
can
do
much
about
that.
Okay,
okay!
So
a
third
item:
don't
look,
don't
touch
so
this
works
with
any
kind
of
iv
packets
in
particular
with
encrypted
ones,
and
we
are
not
trying
to
help
the
end-to-end
protocol
except
by
not
losing
their
packets.
D
So
an
end
host
sends
some
data,
the
the
loops
segment,
transmits
that
we
need
some
form
of
x
or
other
reverse
information
feedback,
and
maybe
there
will
be
a
retransmission.
Maybe
there
will
be
forward
error
correction
and
in
the
end
the
data
is
reconstructed
and
sent
on
to
the
end
host.
D
So
this
is
a
pretty
big
area.
We
could
do
lots
of
things
here
and
in
the
initial
meetings
we
had,
we
we
were
going
through
these
lots
of
things
and
people
were
starting
to
get
scared
because
it
sounded
like
we
wanted
to
reinvent
the
internet
or
something
that
of
course,
was
not
the
point.
This
is
a
patch
a
fix.
D
You
apply
to
something
that
doesn't
work
right
at
the
moment,
so
many
things
could
be
included
in
loops
and
we
we
are
trying
to
follow
a
minimum,
viable
protocol
approach
here
and
make
sure
we
have
a
protocol
soon
that
we
have
the
energy
to
develop,
that
we
have
the
agreement
that
we
want
to
that.
D
We
are
able
to
deploy
this
and
that
provides
enough
benefit
already,
but
it's
not
boiling
the
whole
ocean
and
we
might
build
a
few
more
dikes
and
add
a
little
bit
more
of
our
ocean
later
so
recovering
is
done
using
retransmission
reconstruction.
I
probably
don't
have
to
say
much
about
this.
I
left
this
slide
in
from
105
because
we
struck
a
few
things
from
the
list
for
the
minimum
value
protocol.
D
So
we
are
not
talking
about
dynamic
block
sizes
and
rates
or
forward
error,
correction
or
combined
forward
error,
correction
and
retransmission.
We
can
add
that
later
and
also
we
are
keeping
most
of
the
setup
out
of
the
protocol.
So
this
is
a
controller
model.
D
Note
yeah-
and
we
want
to
do
this
in
a
way
that
doesn't
blow
up
the
internet,
so
we
know
that
if
we
are
concealing
losses,
we
are
removing
an
important
condition
signal
and
end
hosts
would
ramp
up
indefinitely
to
higher
rates
and
and
increase
the
congestion.
D
Yeah,
so
at
the
same
time,
we
see
that
the
host
transfer
protocols
are
getting
better
in
certain
ways
and-
and
we
may
want
to
design
loops
in
such
a
way
that
it
can
take
that
it
actually
works
well
with
these
improvements,
but
they
are
not
the
prerequisite
for
the
protocol
to
to
work
okay.
So
the
three
things
are
recovery
measurement.
Of
course
we
need
to
know
the
rtt.
D
We
may
want
to
know
the
the
delay
variation
as
well,
so
we
can
set
the
recovery
parameters
and
we
are
leaving
out
the
ambitious
goal
of
identifying
non-congestion
losses
from
the
minimum
viable
protocol.
So
the
congestion
feedback
is
now
entirely
focused
on
ecm
you're,
not
working
with
non-econ
traffic.
D
So
loops
is,
of
course,
interacting
with
the
the
engine
protocol
transporter,
which
is
also
trying
to
make
sure
that
all
packets
make
it,
and
we
are
not
meddling
with
that.
We
are
also
not
assuming
the
end-to-end
protocol
knows
that
loops
is
in
place
and
in
particular
the
end-to-end
protocol
remains
the
one
that
controls
the
sending
rate.
D
So
we
have
to
make
sure
that
the
the
congestion
control
feedback,
the
entrant
particle
gets
with
loops,
looks
very
similar
to
the
one
that
it
would
get
without
loops.
D
On
the
other
hand,
loops
is
not
a
classical
transport
protocol,
so
some
losses
are
okay
and
also
implementations
might
be
able
to
interact
much
more
tightly
with
the
path
segment
being
optimized.
So
if
they
know
this
is
actually
just
a
satellite
segment,
they
might
be
able
to
do
more
than
than
other
loops
implementations,
but
that's
not
part
of
the
project.
D
So
the
the
typical
intuition
for
a
transport
protocol
doesn't
really
work
very
well
for
loops.
First
of
all,
the
the
environment
is
controlled.
Somebody
set
up
this
loop
segment,
so
they
must
have
had
a
reason
for
that.
D
These
are
not
random.
End
hosts
that
are
interacting
over
random
internet
paths.
We
don't
need
full
reliability
and,
since
loops
actually
is
aggregating,
it's
usually
aggregating.
Multiple
entrant
flows
in
a
tunnel
it
might
have
much
more
packets
in
flight
than
the
typical
transport
protocol
would
over
a
segment
that
actually
has
losses.
D
D
The
pointers
are
in
the
charter,
so
maybe
the
most
important
thing
is
to
look
at
the
chart
and
we
had
a
mailing
list
in
case
you
haven't
followed
that
okay,
so
that
was
a
very
quick
run
through
loops,
and
now
I
want
to
focus
on
what
happened
from
ietf
105
to
itf
108.,
so
the
105
both
was
one
that
was
labeled
as
non-working
group.
D
For
me,
even
though
some
questions
asked
at
the
end,
probably
would
have
been
better
for
working
performing
wolf
anyway,
so
there
we
kind
of
opened
the
the
design
space
and
and
looked
for
for
feedback,
and
we
got
this
feedback.
Thank
you
very
much.
I
got
a
lot
of
more
feedback
in
in
the
year
since
so
for
108.
D
For
this
working
performing
group,
we
we
made
a
few
decisions.
We
briefly
considered
leaving
out
fec,
but
we
think
we
need
to
exercise
the
parts
of
the
protocol
that
switch
between
fec
and
retransmission.
D
As
I
said,
we
are
not
trying
to
detect
non-congestion
losses
as
such
and
we
are
focusing
on
the
drop
to
mark
approach,
which
means
we
require
end-to-end
ecn
and
we
see
e-mark
the
recovered
packets.
D
D
So
initially
we
wanted
to
to
improve
throughput
and
latency,
and
we
saw
that
improving
throughput
actually
is
way
more
complicated.
So
we
are
focusing
on
latency
now
on
faster
recovery,
and
that
means
the
the
flows
that
we
are
interested
in
are
really
the
the
ants,
the
short
flows
and
the
transactional
loads,
where
we
have
small
bursts
of
traffic
gamers
or
something
like
that
and
then
go
back
to
idle
and
the
the
reason
why
we
want
to
do
this
is
we
we
don't
want
to
have
congestion
control
loops,
fighting
against
each
other?
D
So
we
just
leave
the
congestion
signals
in
place
and
let
the
end-to-end
congestion
control
do
its
thing,
even
though
we
might
get
better
congestion
control,
but
yeah
that
needs
maybe
needs
more
work
so
yeah,
maybe
the
the
most
important
consideration
here
is
tailors,
tailors
both
for
for
ants
and
for
for
transactional
nodes
and
of
course
there
are
other
people
working
on
tail
loss
from
the
entrance
side
and
and
that's
great,
but
we
can
attack
the
problem
from
both
sides
so
in
in
a
very
short
way.
D
This
is
our
problem
statement.
Packets
get
lost
and
it
can
take
a
long
time
to
recover
them
end
to
end
now.
This
is
a
very
broad
problem
statement
and
and
quick
and
tailors
detection
and
so
on
we'll
address
this
problem.
So
we
are.
We
are
narrowing
this
a
little
bit
to
an
opportunity
which,
in
this
case
is
we
know
how
to
improve
this
using
local
recovery,
retransmission
or
reconstruction
without
host
corporation
independent
transfer
protocols,
and
we
are
also
narrowing
the
opportunity
to
easy
and
capital
traffic.
D
So
the
narrowing
of
the
opportunity,
of
course
also
means
that
the
environments
that
benefit
nero
so
we
can
only
benefit
applications
that
have
ecn
enabled
at
the
end
hosts
and
that
benefit
from
improved
latency,
and
we
looked
at
a
number
of
applications.
We
will
go
to
use
cases
shortly
and
yeah
smartphones
might
already
be
easy
and
enabled
in
the
enterprise.
We
know
that
in
many
cases,
ecm
needs
switching
on
and
and
the
drop
to
mark
approach
actually
is
an
incentive.
D
So
if
you
don't
care
about
loops
but
do
care
about
ecn,
maybe
you
should
just
keep
in
mind.
Loops
is
intended
also
as
an
incentive
to
switch
on
ecm
and
yeah
bleaching
of
vcn
by
networks
is
a
problem
and
we
cannot
do
anything.
D
D
We
cannot
do
anything
about
networks
that
reach
ecn,
but
what
we
actually
can
do
is
work
around
a
network
that
is
reaching
ecn
by
running
a
loops
segment
around
it,
converting
the
drops
to
marks
and
run
ecn
in
the
next
next,
the
adjacent
parts
of
the
network
outside
the
loop
segment
yeah.
The
question
that
is
often
asked
the
frequently
asked
question
is:
why
don't
you
just
simply
fix
your
network?
D
It
turns
out
that
the
use
cases
that
people
have
in
mind
for
this
involve
heterogeneous
or
hybrid
environments.
So
you
you
have
traffic
that
is
crossing
into
operator
boundaries
or
traffic
that
is
going
through
legacy
areas
in
in
your
network,
where
you
know
the
forklift
lift
upgrade,
will
take
another
three
years
so
so
right
now,
it's
just
not
possible
to
do
something
so
think
about
the
patch,
not
in
the
computer
sense,
but
in
the
physical
sense.
D
D
D
Somehow
yeah
so
more
discussion
in
in
the
jabba
about
l4s.
Definitely
this
is
something
we
we
have
been
following
with
great
interest,
and
we
also
would
follow
sce
with
great
interest
if
that
can
ever
happen.
But
right
now
we
are
focusing
on
on
things
that
that
actually
are
working.
D
D
Okay,
so
what
are
these
heterogeneous
scenarios
and
we
came
up
with
two
abstract
scenarios
that
actually
can
be
combined.
D
D
So
the
the
little
squares
here
are
not
the
end
hosts,
I
should
have
said,
but
our
routers-
that
that
then
branch
out
into
the
the
networks
on
which
the
the
over
which
the
and
hosts
then
communicate.
D
So
why
do
we
want
to
standardize
this
now?
Actually,
I
have
been
wanting
to
standardize
this
approximately
since
2008,
so
I'm
happy
that
that
more
people
want
to
do
this
now.
We
actually
think
this
is
low
hanging
fruit
and
the
the
interesting
development
that
helps
is
that
we
now
have
overlay
nodes.
We
can
get
deployed
all
over
the
network
either
in
operator
data
centers
or
even
in
cloud
provider-
data
centers
that
can
provide
the
compute
and
the
space
to
make
this
happen.
D
So
I
think
that
is
one
of
the
reasons
why
this
hasn't
been
done
earlier.
It
was
harder
to
find
these
overlay
nodes,
but
it's
it's
also.
Just
we
just
happened
to
have
found
applications
in
in
various
parts
of
the
world.
D
Again,
it's
probably
not
saw
interest
in
the
middle
of
of
the
us
or
in
the
corn
network
in
germany,
or
something
like
that,
but
there
there
are
applications
where,
where
operators
see
use-
and
actually
there
are
lots
of
of
riverbeds
and
and
other
applications,
other
companies
around
that
provide
application
controllers
or
whatever
they
are
called,
and
these
often
come
from
a
background
of
intrusive
peps,
so
they
will
have
to
change.
But
it's
not
like
these
solutions
don't
exist.
D
We
we
just
don't
see
them
in
in
the
standard
internet
protocol
place,
because
these
boxes
are
usually
usually
bought
in
pairs,
and
they
are
also
often
not
done
right.
So
my
personal
record
for
a
round
trip
time
was
in
a
train
in
belgium,
where
I
measured
measured
a
round
trip
time
of
264
seconds.
Through
such
a
solution,
I
had
to
modify
ping
to
even
be
able
to
measure
that
yeah.
D
So
not
everything
that's
out
there
is
is
great
and
it
would
be
good
to
have
a
standardized
solution
that
points
the
way
a
little
bit.
So
why
standardize
that
all
the?
The
reason
is
that
the
ingress
and
the
egress
often
are
different.
D
They
might
be
run
by
different
operators
who
want
to
make
different
choices
in
in
equipment,
but
they
also
might
be
in
different
ends
of
the
network,
so
you
might
have
might
have
an
arm-based
cpe
and
the
operator
data
center
at
a
virtual
pub
and-
and
you
might
want
to
buy
different
solutions
for
these
environments
so
having
a
standard
is,
is
actually
useful.
D
So
with
that,
maybe
we
can
have
a
quick
peek
at
the
use
cases.
So
we
we
have
talked
about
use
cases
a
lot
in
in
105
and
in
in
various
site
meetings
and
the
the.
D
We're
not
trying
to
to
list
all
potential
use
cases
here,
but
focus
on
sums
that
actual
operators
have
today
and
again
it's
not
about
changing
the
internet.
It's
about
changing
those
parts
of
the
internet
that
actually
need
this
change
or
can
benefit
from
this
change.
D
C
This
leader,
I'm
going
to
talk
about
this
use
case,
called
the
overlay
path
via
cloud.
Actually,
this
was
presented
before
during
itf-105,
but
here
we're
trying
to
refine
it
into
the
terminology
used
by
their
previous
scenario.
Those
square
boxes
here.
So
basically,
this
this
use
case
is
a
combination
of
the
two
scenarios
covered
by
custom.
Just
now,
if
you
look
at
the
small
blue
squares,
a1,
a2
and
a3,
basically,
there
were
clothes
created
by
us
and
they
are
located
in
a
different
cloud
or
possibly
same
cloud.
But
here
for
illustration
purpose.
C
We
use
different
cloud
so
and
the
big,
the
the
bigger
blue
square,
a
actually
is
is,
is
also
our
cloud,
so
the
a2
is
located
is
created
from
our
own
cloud
and
possibly
there
are
other
clouds
which
is
green
and
red.
We
create
workloads
there.
C
So
if
you
look
at
the
left
hand
side
the
small
picture,
we
have
the
overlay
nodes
all
around
the
world
there
are,
there
are
more
than
100,
some
are
from
our
own
cloud
and
some
are
created
from
other
clouds.
So,
with
all
this
overlay
nodes,
we
can
possibly
select
a
better
path
in
terms
of
the
lower
latency.
So,
for
example,
we
find
out
the
the
default
path
from
jakarta,
indonesia
to
shenzhen.
China
actually
sometimes
gives
a
quite
high,
quite
high
rtt
time,
for
example
like
a
few
hundred
milliseconds.
C
So
we
try
to
use
a
two
segment
based
path
to
instead
of
the
default
pass.
That
is
from
jakarta
to
hong
kong
and
hong
kong
to
shenzhen
and
with
this
lower
latency
up
two
segment
lower
latency
pass,
then
we
find
we
we
can
achieve
better
latency,
but
we
find
out
the
loss
is
still
there
from
shenzhen
to
hong
kong,
although
the
distance
is
is
pretty
short,
but
because
it's
an
international
gateway
there,
it's
across
the
region,
so
the
loss
can
be.
The
loss.
C
Is
there
from
time
to
time
so
we're
trying
to
enable
the
loops
over
this
particular
segment
and
to
achieve
the
faster
loss
packet
loss
recovery.
So
I
just
want
to
point
out
loops,
actually
does
not
address
any
problem
of
the
past
selection
or
the
the
or
partition
the
past
two
segments
here.
We
loops
only
helps
here
to
recover
the
packet
over
put
over
specific
segments
in
a
faster
way.
So
that's
what
I'm
trying
to
say
thank.
F
F
Thank
you,
okay.
Thank
you.
This
is
john
from
china
telecom.
Many
thanks
for
this
opportunity
to
speak
out
of
use
case
to
you,
and
this
use
case
is
mainly
focuses
on
the
sd1
based
branch
office.
Interconnect
as
we
all
know,
more
and
more
enterprise
customers
choose
to
deploy
as
divine
services
due
to
its
flexibility
and
a
lower
cost.
However,
in
most
cases,
sd1
is
overlaid
network
service
built
upon
the
internet,
which
is
best
effort
network.
F
F
So
the
branch
office
cpe
connects
to
the
selected
pub
in
beijing
for
service
access,
and
then
it
will
direct
the
traffic
to
another
pub
in
nanjing,
which
is
close
to
the
branch
of
a
set
too.
We
can
say
that
there
would
be
three
segments
overlay
passed
in
between
of
branch
offices
cpe,
and
there
are
cpe
a
cp
1
2
pop
1
pop
1
to
pop
2
and
pop
2
to
cp
2
and
each
segment.
F
You
should
use
network
overlays
by
means
of
tenants.
Besides
from
our
current
deployed
deployment,
status,
cp
to
pub
segment
is
based
on
the
internet.
Access
network,
which
is
usually
tens
of
kilometers
and
pop
to
another.
Pub,
can
be
hundreds
of
kilometers
away
through
internet
backbone,
so
pack
and
loss
could
happen
on
any
of
them
generally,
so
we
can
enable
loops
on
the
cpe
and
the
pops
puppies
used
to
deploy,
overlaid,
nodes
and
loops
function
can
be
enabled
on
demand.
A
I'm
seeing
a
little
bit
of
discussion
on
this
use
case
some
questions
in
jabber.
Do
we
want
to
bring
those
forward
well,
jian
wang's
still
here.
Do
we
want
to
go
on
to
marcus
first.
A
A
We'll
carry
them
to
next
good
marcus
you're
up.
G
Micro
speaking,
so
we
from
dodge
telecom
see
loops
potentially
to
improve
multipass.
So
in
the
context
of
the
minimum
viable
protocol
carson
already
mentioned,
that
does
not
mean
that
we
extend
loops
with
multi-path
capabilities.
G
It
just
means
that
an
existing
multi-path
environment,
an
existing
multi-part
protocol,
can
leverage
loops,
so
no
integration
here,
at
least
not
in
the
beginning,
maybe
later
on,
if
the
charter
becomes
extended
by
multi-path.
So
let's
see
so.
I've
sketched
here
two
use
cases
on
the
top.
I
see
that
loops
can
be
used
on
individual
paths
between
a
multi-pass
communication.
G
G
G
So
here
we
apply
a
loops
connection
through
a
multi-path
protocol.
G
G
Yeah
packet
losses
caused
by
such
such
a
mismatch,
so
that
is,
that
is
the
idea
here.
Mainly
we
see
loops
to
improve
multi-path
protocols
which
transmit
data
non-reliable,
so
we
don't
see
it,
for
example,
for
multiples
tcp,
but
exemplary.
Here
I
mentioned
in
the
slide
for
multi-pass
dccp
or
even
in
future,
for
multi-path
quick
if
it
makes
use
of
the
data
chrome
extension.
D
Okay,
thank
you,
marcus.
I
I
think
that
we're
having
some
some
interesting
discussion
in
in
the
jabber
all
these
use
cases,
of
course,
involve
more
than
than
two
network
components
and
the
these
other
network
components
obviously
do
something
useful
as
well.
D
It's
pretty
hard
to
construct
a
use
case
where
you
only
see
the
loop
segment,
because
then
it's
kind
of
trivial,
so
the
the
use
case
use
cases
we
have
seen
actually
show
yeah
complicated
scenarios,
but
that
doesn't
mean
that
loops
needs
to
handle
all
aspects
of
that
scenario.
Loops
only
handles
the
packet
recovery
part,
so
things
like
like
path,
selection,
routing
and
so
on
help
with
achieving
the
overall
goal
of
each
of
the
use
cases.
A
So
we
we
put
this
here
to
like,
basically
whether
we
you
know
whether
this
is
a
you
know
like
in
a
54
34
situation.
This
would
be
a
hum.
I
think
that
there's
probably
enough
traffic
in
the
back
channel
on
jabber
to
show
that
we
don't
yet
have
like
the
the
entropy
does
everyone
understand
the
problem
that
has
been
presented
is
in
detail
not
yet
so,
let's
actually,
let's
take
some
of
the
discussion
in
jabber
and
bring
it
out
into
the
room.
H
Hi
does
this
work?
It
does
excellent.
So
we
talk
about
using
ecn
end
to
end
what's
loose
position
on
using
paths
that
have
ecn
on
in
the
underlay.
D
Is
so
for
a.
I
D
We
might
further
simplify
the
the
scenarios
by
requiring
ecn
in
the
underlay,
but
we
found
that
that
we
actually
don't
need
that,
because
we
can
convert
the
the
drops
that
are
happening
there
into
marks
at
the
egress.
H
So
but
carson,
if
you
had
ecn
in
the
underlay,
then
you
would
want
to
react
differently
to
drops
at
the
marks
and
because
cues
that
are
dropping
when
they're
using
aqm
might
be
dropping
because
they're
trying
to
shed
load
and
yet
you
it
seems
that
loops
translates
these
intentionally
introduced,
drops
into
marks
and
therefore
doesn't
cause
them
to
be
seen.
At
the
end
points.
D
Yet
so
I
think
converting
these
drops
to
marks
is
inocus
and
if,
if
there's
actually
something
bad
going
on
in
the
loop
segment-
and
I
probably
should
have
had
that
on
one
side,
you
would
use
a
circuit
breaker
to
to
make
sure
that
you
are
not
completely
swamping
that
segment.
So
that's
actually
an
important
part
of
the
overall
picture,
and-
and
I
don't
know
why
this
is
not
on
the
slides.
I'm
sorry
about
that.
A
Okay,
thank
you.
Next,
you
have
colin.
E
Hi,
can
you
hear
me?
Yes,
you
can
yes
good
good,
so
I
just
wanted
to
clarify
my
understanding
of
the
scope
and
see
if
it
matches
that
of
the
the
people
proposing
the
work.
So
what
what
I
thought
was
happening
with
loops
was
that
it
was
essentially
a
fancy
tunnel.
It
was
a
tunneling
protocol
that
could
recover
packet
losses
and
turn
them
into
ecn
marks.
D
D
I
Martin,
that
play
is
amazing.
Okay,
so
I
was
a
little
con
confused
by
some
of
the
presentations
here.
I
think,
if
you've
answered
colin
correctly
when
you
have,
but
if
I
understood
the
answer-
sorry
fancy
tunnel.
If
your
route
selection
causes
you
to
go
down
that
tunnel
and
that
tunnel
has
loops,
then
you
get
all
of
the
reported
benefits.
Slash
drawbacks
of
what's
going
on.
Is
that
right?
Yes,
excellent!
That's
a
whole
lot
clearer!
I
D
Loops
needs
to
work
in
cases
that
as
a
packet
assignment
malfunctions,
so
the
ingress
will
actually
have
to
look
at
the
ect
bits
to
find
out
whether
it
actually
can
do
repair
or
not.
D
So
there
is
a
little
bit
of
traffic
sorting
going
on
in
the
ingress,
because
we
don't
know
how
to
signal
transaction
to
to
non-ecg
traffic.
Yet.
I
Okay,
so
that's
that's
just
a
choice
about
how
you
manage
the
signaling,
and
so
you
basically
opt
out
of
doing
anything
for
those
people
who
don't
do
ect
right.
Okay,
fine,
doesn't
this
add
a
massive
amount
of
reordering?
D
So
that
that's
maybe
one
of
the
the
differences
between
that
net
and
and
loops
that
net
was
brought
up
in
in
the
jabber.
That
net
has
to
make
sure
the
whole
thing
looks
like
an
ethernet
after
it
has
done
its
work
and
well
that's
a
very,
very
brief
way
of
saying
it,
but
so
it
has
to
actually
handle
the
reordering
that
it
introduces
and
that
there
for
also
has
a
resequencing
function.
D
I
forget
how
that
is
called
at
the
moment,
the
o
in
in
the
pre-off
name.
So
all
the
packets
are
delivered
to
the
application
in
the
same
order.
A
loops
implementation
has
everything
to
do
that
if
it
wants.
D
I
So
so
I
guess
the
question
then
becomes
if
the
application
in
question
is
not
tolerant
of
that
degree
of
reordering
and
and
for
instance,
if
you
decided
to
to
re-transmit
a
packet
that
is
a
little
too
late,
how
much
and
and
that
displaces
other
packets
causing
latency,
certainly
repair
would
would
cause
latency,
but
if
it
displaces
packets
causing
latency.
How
is
this
necessarily
a
good
thing
in
all
cases,.
D
Well,
first
of
all,
you
would
not
run
loops
in
such
a
way
that
the
displacement
effect
becomes
serious,
because
we
are
talking
about
the
small
two-digit
percentage
percentages.
Here
we
are
not
talking
about
creating
three
times
the
traffic
or
something
like
that,
and
the
second
observation
is
yes,
so
so
anything
you
can
do
to
packets
has
a
few
people
who
who
heavily
benefit
from
that
and
others
who
might
see
a
slight
impairment
of
their
traffic.
There
is
no
way
to
ever
touch
a
package
without
having
the
possibility
of
of
some
apparent.
A
Okay,
thanks
next
and
I'll
go
ahead
and
close
the
queue
after
this
janna.
J
You
hear
me,
I
think
you
can
okay
jenna
yengar,
so
I
want
to
follow
on
to
what
martin
just
does
and
broaden
the
question
a
bit,
because
that's
important
to
ask:
how
do
you
so
there's
no
application
classification
going
on
here
or
if
there
is
it's
not
in
scope
for
loops
right?
J
D
K
J
So
I
think
this
is
where
I'm
getting
stuck,
I'm
trying
to
understand
the
context
in
which
loops
gets
deployed,
and
it's
it's
failing
me,
so
it
it's
so
this
is
this
to
me
sounds
very
much
like
what
already
happens
around
problematic
links.
Wi-Fi
is
a
good
example
of
that,
where
we
do
local
re-transmits
at
the
link
level
and
satellite
networks
again,
you
might
want
to
do
that,
but
that's
sort
of
around
one
ip
hop.
J
Typically,
that's
how
we
think
about
that
and
the
reason
it
works
in
those
situations
is
because
you
know
that
the
path
has
particularly
poor
loss
characteristics
and
doing
some
sort
of
local
recovery
around.
That
particular
link
is
helpful,
but
turning
it
to
the
ip
level
means
that
I
can
do
it
across
the
internet.
J
I
can
do
it
from
my
house
to
the
google
data
center
or
to
wherever
I
want
to
do
it
and
that's
where
it
starts
to
become
much
more
problematic
for
me,
because
the
it
starts
to
work
on
aggregates
of
traffic
without
and
at
that
point
I'm
trying
to
figure
out
how
does
loops
selectively
apply
this
only
to
the
traffic
that
cares
about?
Having
that
sort
of
free
transmission,
I
mean
the
extreme
case.
J
I
can
imagine
a
loop
send
point
at
my
computer
here
and,
at
the
other
end
as
well,
and
there
being
basically
a
reliable
tunnel
between
the
two
endpoints
again
without
the
context.
It's
not
clear
to
me
exactly
where
and
how
the
loops
gets
used.
Now
I
saw
the
use
cases,
but
again
the
use
cases
didn't
help
me
understand
the
context,
meaning
what
is
the
technology
around
loops?
That
is
helping
loops,
do
its
work
effectively.
D
So
the
you
made
the
observation
that
we're
doing
this
in
link
layer,
adaptation
protocols
all
the
time,
so
wi-fi
uses
free
transmission
and
also
resequencing,
one
might
say-
and
the
question
really
that
that
comes
up
very
quickly
is,
if
that
makes
sense
for
wine.
One
hop.
Why
does
that
make
sense?
D
And
so
so
loops
is
kind
of
the
generalization
to
to
the
answer
to
this
question.
Of
course
it
makes
sense
in
certain
situations
in
in
certain
cases,
so
you
can
do
a
lot
of
things
to
actually
make
the
the
loops
mechanism
be
be
really
optimal
and
selecting
the
right
application,
traffic
and
so
on,
but
simply
switching
on
loops
for
for
a
particular
segment
on
which
traffic
is
flowing
should
have
some
some
positive
latency
effect
for
that
traffic.
J
D
D
So
I
think
you
are
overestimating
the
amount
of
intelligence
that
actually
is
in
in
linked
layer
protocols
about
re-transmissions
these
times.
D
J
Fundamental
and
important
characteristic:
yes,
when
you're
going
across
ip
hops,
you
have
significantly
congestion
as
a
a
big
signal
as
a
big
reason
for
loss
that
can
happen
at
across
ip
hops
and
if
you
try
to
put
loops
because
you
start
to
see
congestion,
I'm
not
quite
sure
what
happens,
and
this
is
again
why
I
mean
link
level.
Retransmission
is
a
property
of
the
link.
It
is
exposed
up
to
ip
ip
doesn't
see
those
losses
at
all.
J
It
might
see
some
reordering,
but
typically
link
level
protocols
have
buffers
to
manage
the
reordering.
Are
we
talking
about
doing
buffering
here
to
manage
the
reordering?
No,
we
are
not
we're
talking
about
simply
retransmitting
which
which
again
may
not
actually
help
you
at
all.
But
it's
not
clear
to
me.
J
J
So
the
only
thing
I'll
leave
with
is
that
it
is
important,
very
important
to
consider
that
any
recovery
that
loops
does
has
to
be
seen
in
the
context
of
end-to-end
recovery.
That
is
happening
at
the
sender,
so
if
the
sender
is
doing
fec,
the
sender
is
doing,
loss
recovery
will
loops
know
that
does
loops
interfere
with
that
does
loops
help
that,
under
what
conditions
does
it
help
under
what
conditions
does
it
hurt?
Those
are
questions
that
are
still
open.
In
my
mind,.
D
D
Will
it
improve
that?
Well
if
there
are
losses-
and
there
is
still
a
budget
to
to
fix
them
by
repair-
yes,
it
will
repair
them
and
it
will
happen
within
the
segment.
So
it
will
be
faster
if
it's
retransmission,
then
it
would
be
end
to-
and
I
forgot
the
third
question.
J
A
I'll
take
this
I'll.
Take
that
as
a
question
for
his
input
to
the
the
chartering,
because
we
are
currently
about
six
minutes
over
on
this
part
each
hour.
Did
you
have
a
a
point
on
the
on
this
discussion?
Or
did
you
have
an
additional
question
because
we
closed
after
jonna.
C
I
tried
to
be
quick,
so
I
want
to
add
something
to
customs
comments
as
well
to
to
answer
why
this,
why
this
loops?
I
mean
what
in
under
what
circumstances
loops
would
be
required.
For
example,
the
the
the
underlaid
infrastructure
operator
actually
is
a
different
one
from
the
overlay
network
operator.
So
in
that
case
the
overlay
operator
doesn't
really
know
what
happens
only.
C
There
is
another
case
that,
even
for
the
infrastructure
and
overlay
network,
they
are
owned
by
the
same
operator
same
company,
but
it
could
be
run
by
by
two
different
departments,
because
normally
that
the
overlay
network
can
be
provisioned
much
more
quickly
than
to
change
it
underlay.
So
there
are
some
of
the
operators
actually
have
the
choices
to
use
the
overlay
network
for
their
for
their
quick
provisioning
on
certain
services.
In
that
case,
they
try
to
use
the
overlay,
in
that
case
they're
the
of
the
overlay,
the
overlay
department,
wrong.
C
I
mean
who
is
running.
This
overlay
network
actually
has
no
way
to
understand,
what's
happening
under
the
for
the
online
network.
So
that's
why
loops
could
be
used
there,
but
trying
to
point
out
loops
actually
itself
doesn't
solve
this
all
kinds
of
problems,
just
trying
to
provide
a
packet
recovery,
yeah.
A
So,
if
I
can
in
can
interject
here
and
to
try
and
wrap
this
up,
it
seems
like
there
are
three
sort
of
actors
that
we
need
to
consider.
A
There's
the
in
this
overly
underlay
case,
there's
the
overly
operator,
the
underlay
operator
and
then
there's
sort
of
like
you
know,
whatever
happens
at
the
the
endpoint
for
recovery
from
the
overlay
operators.
Standpoint.
A
If
I
can
try
and
restate
what
you
said
to
make
sure
that
I
understand
it,
the
overlay
operator
is
essentially
using
loops
in
order
to
emulate
a
certain
set
of
network
characteristics
on
top
of
an
underlay
operator.
That
does
not
provide
those
characteristics
that,
with
respect
to
loss,
that's
correct,
so
you're,
basically
trading
off
jitter
for
loss
on
a
lossy
link
that
you
get
from
the
underlay
okay.
A
C
Yeah
yeah
yeah.
The
second
case
is
for
the
elderly
and
and
and
overly
actually,
they
are
belonging
to
the
same
operator,
but
they
tentatively
to
use
it
in
that
way.
So
that's
also
the
case.
I
just
want
to
add
this.
J
Okay,
so
if
you,
if
brian,
if
it's
okay
again
make
a
small
quick
comment,
there's
there's
a
fundamental
assumption
in
all
of
this,
which
at
least
I'm
hearing
and
if
I'm
wrong,
please
correct
me,
I'm
hearing
that
loss
is
fundamentally
a
latency
inducing
thing
that
is
bad.
J
That
is
a
strong
assumption
of
what
the
endpoints
are
capable
of
doing
or
what
the
traffic
needs
from
the
network.
Typically,
when
we
build
endpoint
protocols,
we
assume
that
losses
will
happen
in
the
network
and
we
build
around
it.
Losses
are
an
indication
of
a
variety
of
things
and
they
do
not
always
introduce
latency
and
importantly
I'll
say
that
hiding
losses
can
actually
be
problematic
in
in
in
cases
of
congestion
and
a
high
loss
rate
is
not
necessarily
a
bad
thing.
J
I'll
give
one
example,
which
is
the
bbr
congestion
controller,
actually
reduces
latency,
while
increasing
retransmission
rates,
that's
always
confused
people,
but
that
does
happen
yeah
and
I'm
happy
to
take
more
questions
later
to
the
end,
but
I'm
definitely
listening.
Curiously,.
A
Thank
you,
so
I
I
think
this
is
actually
the
you
know
stepping
back
with
the
chair
head
on.
I
think
this
is
actually
the
one
of
the
conversations
I
really
wanted
to
make
sure
happened
at
this.
Buff
was
because
sort
of
like
loops
is
proposed
with
very
much
with
sort
of
like
this
network
and
operations
viewpoint,
and
it's
sort
of
like
making
sure
that
the
impedance
is
matched
between
that
and
transport
protocol
design.
A
But
with
that
I
think,
are
there
other
questions
that
people
have
that
they're
really
having
trouble
understanding
what's
going
on
here
before
we
move
on
to
the
charter,
like
sort
of
like
I,
I
think
we
have.
We
have
definitely
points
that
have
been
raised
for
the
design
that
should
be
considered,
but
are
there
sort
of,
like
I
don't
know,
what's
going
on
here,
questions
still.
A
Seeing
none
I'll
hand
this
back
over
to
karsten
to
start
looking
at
the
charter,
oh
wait,
emile
did
you
want
to?
A
Did
you
want
to
ask
you
also
have
to
put
yourself
into
oh,
you
also
have
to
put
yourself
in
the
audio
queue.
Otherwise
we
won't
be
able
to
hear
you.
A
A
Okay
yeah,
can
you
add
that
to
the
can
you
can
you
have
that
in
the
in
the
jabber
and
we'll
try
to
pick
it
up
later
karsten?
Can
you
move
on
to
the
charter
stuff
just
looking
at
the
clock.
D
Okay,
so
I
just
pasted
the
charter
text
on
on
the
slide,
which
is
unfortunately
the
best
way.
I
know
how
to
handle
this,
so
the
charter
proposal
starts
with
some
background
and
I
think
most
people
will
be
able
to
to
agree
with
the
first
slide
here
so
I'll.
Go
on
to
the
part
that
is
not
background,
so
loops
is
is
therefore
enabling
optimizations
within
some
segments
of
an
end
to
end
path,
and
then
the
the
charter
points
out.
This
is
best
done
by
channels
or
in
groups.
D
This
is
done
by
tunnels
and
these
tunnels
are
for
aggregates,
so
many
end-to-end
flows
can
go
into
one
such
tunnel
and
the
focus
is
on
path
segments
that
do
not
include
the
end
hosts.
Of
course,
there
is
not.
There
is
no
technical
difference
between
including
an
end
host
and
not
including
the
end
host,
but
that
influences
the
choices
that
that
will
be
made,
in
particular
on
the
setup
side.
D
So
the
assumption
is
that
the
the
ingress
and
egress
nodes
are
actually
under
control
of
some.
Some
network
operator
and
multipath
is
left
for
future
future
consideration
again.
The
selection
of
the
segments
to
be
optimized
is
out
of
scope,
and
I
think
we
just
discussed
this
sufficiently
so
that
there
is
some
network
configuration
going
on
and
I
apologize
to
to
the
people
who
are
kind
of
scared
by
network
configuration
network
conversation
is
scary
and
on
the
other
hand,
this
means
the
network
configuration
can
supply
parameters
to
the
group's
operation.
D
D
Yeah,
so
this
just
repeats
video
recovery,
we
do
measurement
and
we
interact
with
end-to-end
kardashian
control,
so
the
recovery
can
be
fec
or
on
non-persistent
re-transmission,
and
I
think
this
is
very
important.
So
there
needs
to
be
a
time
limit.
D
D
We
need
to
do
some
measurement,
and
these
may
actually
be
interesting
for
the
network
management
again
and
finally,
we
have
an
interaction
with
the
end-to-end
congestion
control
and
we
do
this
by
relaying
the
loss.
Events
that
have
happened
on
the
segment
as
lost
events
to
the
end,
to
end
congestion,
control
and
since
relaying
would
mean
dropping
for
a
non-ecn
flow.
That's
not
very
great
for
someone
who
wants
to
recover
packets,
so
we
focus
on
ecn,
enabled
entrant
flows
and
very
important.
D
We
will
use
circuit
breakers
to
make
sure
loops
doesn't
become,
doesn't
age
and
abet
bad
behavior
by
by
endnotes.
D
Loops
itself
is
somewhat
agnostic,
but
we
will
focus
on
geneve
for
now,
but
we
also
will
keep
in
mind
that
we
will
add
some
tunneling
protocols
later
there
are
two
irtf
research
groups
that
we
will
need
to
actively
work
with
iccrg,
of
course,
for
for
any
second
order
effects
that
this
might
have
on
condition,
control
and
the
network
coding
research
group,
because
that's
where,
if
you
see
work
happens,
so
if
we
do
something
stupid
in
the
way
we
can
accommodate.
If
you
see
schemes,
we
want
to
know
that
and
yeah.
D
There
are
a
few
other
itf
working
groups,
but
these
are
weak
relationships.
Of
course,
trans
transport
area
is
doing
some
fec
related
work,
transit
area
and
tcpm
are
interesting
and
nvo3
is
interesting
as
the
home
of
the
genevieve
tunnelling
protocol.
Thank
you
david
for
this
correction.
B
B
Karsten,
you
may
want
to
go
to
the
next
couple
of
slides
that
talk
about
the
questions
on
this
and
I'm
thinking.
If
I
start
with
the
second
one
down,
is
the
draft
charter
here,
as
presented
here
ready
for
the
ids
to
take
forward,
and,
if
not,
is
it
close
enough
to
polish
on
the
loose
mailing
list
and
during
a
party
chartering
review
process?
A
Yeah
these
are
going
to
be
the
these
are
going
to
be
the
ones
that
we
ask
at
the
end
of
this
discussion,
but
and
as
you
are,
if
you're
making
a
specific
point
on
a
point
on
the
charter,
try
to
like
preface
it
with
where
in
the
charter
you'd
like
to
discuss,
if
it's
a
more
general
scoping
question,
because
those
are
also
sort
of
like
we're
past
we're
clarifying,
we
should
be
talking
about
scope
and
things
like
that.
A
E
So
a
couple
of
things
on
the
charter
and
so
on.
I
think
someone
mentioned
in
the
chat
already.
The
the
network
coding
group
is
planning
to
wind
down
over
the
next
year,
or
so
so
I
mean,
while
it
makes
sense
to
talk
to
those
people
and
talk
to
the
people
with
the
fec
and
network
coding.
Expertise
in
in
general
do
bear
in
mind
that
that
group
is
not
likely
to
be
massively
long-lived
as
a
at
a
general
point.
E
I
don't
see
any
list
of
deliverables
or
documents
on
these
slides,
but
I
think
the
discussion
earlier
would
seem
to
indicate
that
some
sort
of
a
applicability
statement
or
guidelines
for
operators
on
what
environments
it
would
make
sense
to
enable
loops
in
would
be
a
useful
thing
for
this
group
to
produce.
K
E
Sort
of
thing
that
says
you
know
if,
if,
if,
if
you
have
puffs
with
your
round
trip
times
more
than
x
milliseconds,
you
probably
don't
want
to
be
enabling
loops,
because
the
the
added
delay
and
reordering
will
cause
problems.
That
type
of
document.
E
And
in
terms
of
the
the
overall
approach,
this
seems
like
a
a
reasonable
engineering
problem.
I
think
people
are
going
to
be
building
this
type
of
product
anyway,
whether
or
not
we
standardize
it.
So
I
think
the
itf
should
standardize
it
and
I
think
understanding
the
applicability
is
probably
as
important
as
the
specific
engineering
choices
of
how
it
fits
in
with
geneva
and
so
on.
A
Well,
thank
you.
Corey.
H
Clicking
little
round
thing
in
the
lower
right
corner
does
it
know
what
oh
yeah
well
cool,
two
for
two
good
corey?
Okay,
so
on
bullet
one,
it
mentions
three
one.
Three,
five,
the
pep
rfc
and
one
of
the
things
that
that
rfc
was
very
clear
about
was
that
pets
had
to
be
known
by
the
endpoints
that
were
using
the
service
that
you
shouldn't
just
trade
loss
for
recovery
or
make
trade-offs
in
the
network.
You
should
have
this
somehow
configurable,
so
I'm
wondering
really
whether
that
should
be
brought
out
a
bit
more.
H
I'm
worried
about
operators
who
have
traffic
engineering
teams
who
try
and
engineer
around
loss
and
other
mechanisms
that
this
is
trying
to
also
engineer
around
doing
it
at
the
same
time
and
how
these
work
together.
Have
people
thought
about
that
as
a
possible
thing
to
include
in
the.
H
A
Hello,
thank
you,
spencer.
I
I
pointedly
got
out
of
that.
You
can't
really
change
your
hats
here,
but
I
I
for
people
who
are
actually
watching
the
queue
I
went
into
the
queue
and
got
pulled
out
of
the
cube
by
spencer,
because
I
am
speaking
as
an
individual,
not
as
the
boss
chair
here.
I'm
actually
looking
at
this
this
this
charter
again
in
the
the
context
of
some
of
the
discussion
here
in
the
context
specifically
of
corey's
question.
A
The
question
that
you
asked
carson
is:
is
this
a
minimum
viable
protocol?
And
what
is
I
think
I
want
to
reiterate
that
one
of
the
things
that's
actually
missing
is
some
sort
of
way
for
there
to
be
signaling
beyond
ecn
as
to
whether
or
not
an
endpoint
wants
to
participate
or
wants
to
opt
in
or
opt
out
for
certain
for
certain
traffic
right
like
so.
This
is
basically
seen
as
a
way
to
sort
of
bulk
emulate
one
loss
profile
on
top
of
another
loss
profile
by
your
network
operator.
A
The
point
that
jonah
was
making
earlier
it
sounded
to
me
like
boiled
down
to
you-
might
not
know,
what's
happening
on
that.
Underlay
network,
but
you
also
don't
know,
what's
happening
on
the
endpoint
and
what's
happening
on
the
endpoint
might
like
change
the
network
change
the
properties,
the
network
response
such
that
you're
actually
dealing
with
an
entirely
different
environment
in
both
the
overlay
and
the
underlay.
A
So
I'm
wondering,
if
there's
not
some
sort
of
interaction
with
a
signaling
layer
missing
here
that
should
be
added
to
the
charter
like
there
should
be
some
way
for
for
end-to-end
traffic
to
say
yes,
please
or
no
thank
you
would
be
my
feedback
on
the
charter.
A
Otherwise
I
think,
as
colin
said,
a
lot
of
this
is
happening
right
now,
anyway,
a
lot
of
it
is
happening
with
performance-enhancing
proxies
that,
contrary
to
what
the
rfc
says
in
the
shoulds
and
musts
are
working
already
without
endpoint
cooperation,
there
should
be
a
place
that
we
can
at
least
talk
about
experiments
in
this
space
in
the
ietf.
It
does
seem
like
engineering
works,
so
I
I
I
do
as
an
individual.
A
I
think
the
draft
charter
is
probably
not
quite
there
yet
and
look
at
my
comments,
but
I
think
that
it
can
be
polished
into
something
that
would
be.
D
Yeah,
thank
you
brian
about
25
years
ago
I
I
was
part
of
something
that
became
the
issl
integrated
services
over
specific
link
layers
and
about
since
that
time
I
have
been
telling
people
parts
of
the
network
need
to
know
what
the
intentions
of
the
application
are.
So
I
call
this
intention.
Signaling
I've
never
been
able
to
actually
get
any
of
this
into
any
of
the
protocols
but
yeah.
I
completely
agree
that
intention.
D
Signaling
is
a
useful
thing,
which
is
very,
very
different
from
the
ntos
trying
to
command
the
network
to
do
something
which
hasn't
worked
out
very
well,
but
the
network
can
benefit
in
many
places
from
knowing
more
about
the
intentions
and,
of
course
there
are
privacy
considerations
there
and
so
on
and
yeah
you
are
running
penargy.
So
I
I
don't
have
to
say
all
this
in
this
regular
proposal.
D
K
Hi,
martin,
duke
yeah,
I
mean.
Certainly
this
presentation
has
started
with
a
proposition
that
should
be
completely
transparent
to
the
end
points
and
I
think
we're
hearing
some
feedback
from
the
community
that
maybe
there
should
be
some
explicit
coordination
of
the
endpoints.
I
don't
know
if
people
want
to
stand
up
and
say
that's
a
bad
idea
could
this
be?
Maybe
this
is
a
dumb
or
naive
question,
but
could
this
be
as
simple
as
a
dscp.
D
I
Yeah,
I
just
I
just
won
the
jackpot,
so
I
I
think,
there's
a
there's
a
fundamental
problem
here,
in
that
these
enhancements
are
going
to
be
applied
over
a
fairly
long
span
of
the
network,
which
means
that
there's
going
to
be
additional
latencies
for
any
repairs
or
there's
going
to
be
ffc,
and
these
things
aren't
free
and
they
may
interfere
with
what
the
endpoints
have
to
do
and
want
to
do.
I
I
But
I
don't
think
that's
particularly
good,
but
I
think
colin
did
convince
me
that
with
an
applicability
statement,
this
is
at
least
not
doing
harm.
I
I
think,
without
an
applicability
statement,
it
would
be
actually
actually
quite
harmful
for
for
end
users,
because
without
knowing
what's
going
on
you're,
potentially
wasting
effort
or
in
fact
interfering
with
what's
going
on
end-to-end-
and
I
don't
want
to
tell
you
what's
going
on
end-to-end
because
I
think
that's
that's
a
bad
bad
way
to
go.
B
B
A
Oh
okay,
do
you
want
to
be
an
individual
and
then
we'll
take
jonah,
and
then
I'm
gonna
go
ahead
and
close
the
queue,
because
we
would
like
to
wrap
up
go
ahead,
spencer,.
B
Yeah,
so
the
thing
about
that
the
thing
that
we
were
talking
about
the
endpoint
signaling
is
3135
was
a
beautiful
thing.
I
was
co-chair
of
the
working
group
that
produced
it,
but
the
penargy
draft
on
what
not
to
do
talks
about
endpoints,
not
trusting
the
network
and
the
network,
not
trusting
endpoints
enough
to
where
I
think,
I'm
more
comfortable.
Now,
with
the
network
elements
making
side
deals
between
themselves
than
I
would
have
been
in
2002
when
we
published
3135.
J
It's
a
comment
that
that,
at
a
high
level
does
there's
a
a
big
difference
which
I'd
like
to
see
pointed
out
between
this
and,
as
I
was
pointing
out
earlier,
link
level
re-transmissions
that
link
level
remote
missions
operate
under
ib,
and
this
is
happening
across
multiple
ip
hops
and
above
it's
happening
in
the
overlay.
We
use
multiple
languages
here,
such
as
overlay,
underlay
and
various
other
things.
J
Unfortunately,
it's
still
not
clear
to
me
that
we
understand
where
it
does
now,
just
because
an
operator
deploys
it
and
operate
operators
deploy
snake
oil
devices
all
the
time
that
doesn't
mean
we
should
go
standardizing
them.
I'm
also
not
hearing
that
there
are
operators
screaming
for
a
standard
in
the
space,
so
while
operators
might
be
doing
it
and
they
might
be
deploying
it
here
and
there,
it
is
not
fully
clear
to
me
what
circumstances
they
do
it
under
and
it's
not
clear
to
me
that
they
need
a
standard
here.
B
I
think
so
so
the
the
speaking
as
a
former
area
director
a
long
time
ago
about
this
one
of
the
buffs
that
martin
and
I
did
not
end
up
chartering-
was
the
what
was
it
tunneling
compression
and
multi
multiplexing
traffic
flows
buff.
That
was
like
itf
8889,
something
like
that,
and
you
know
we
had
the
concern
then
that
you
know.
Is
anybody
going
to
need
this
badly
enough
to
do
it?
B
And
it
turned
out
that
after
we
didn't
charter
it,
we
found
out
that
most
of
the
people
who
needed
it
were
in
africa
and
were
not
in
at
ietf
88.89.
B
So
I
not
saying
anything
about
whether
that's
this,
you
know
the
same
case
here
or
not,
but
I
yeah.
I
did
have
that
memory
that
I
wanted
to
share
with
the
group.
I'd
shared
it
in
private
email,
but
it
seemed
worth
saying.
A
A
A
Take
a
hum
on
the
first
question
first,
so
let's
actually
get
a
sense
of
the
room
of
the
93
people
here
we
think
we
kind
of
understand
the
problem
in
the
solution.
Space
let's
actually
take
a
ham
on.
Is
this
a
problem
that
should
be
solved
in
the
ietf?
A
So
if
you
believe
this
is
this
loops
is
describing
a
problem
that
sort
of
this
definition
of
multi-hop
transport
recovery.
You
know
the
fancy
tunnel
solution
if
you
believe
this
is
something
that
the
iatf
should
address.
A
A
Yeah
so
enough,
people
hum
successfully
that
that
was
a
forte,
so
that
was
a
pretty
strong
hum.
Let's
take
a
hum
on
the
other
side.
If,
if
you
think
that
the
problem
that
luke
is
trying
to
solve
here
should
not
be
solved
in
the
ietf,
please
hum
now.
A
Yeah,
okay,
so
do
you
wanna
so
do
you
do
you
wanna?
Do
you
wanna
phrase
that
a
bit
more
informally,
spencer,
I'll
click.
A
A
Another
forte,
if
we
get
a
fourth
forte
hum
here,
I'm
gonna
wonder
if
the
tools
working
so
the
second
hum
will
be
if
you
think
it
is
not
useful
to
have
an
applicability
statement
on
sort
of
the
the
space
in
which
something
like
loops
could
be
deployed.
Please
hum
now.
This
is
for.
A
A
A
Pianissimo
okay,
johnny
you'd,
like
to
comment
on
this.
J
Clarify
yeah.
J
Listen,
it's
not
at
all
clear,
I
think,
there's
on
jabber.
You
can
see
this
confusion
around
exactly
how
the
second
question
applies
to
the
first
one,
meaning
yeah
yeah.
What
does
that
yeah?
You
have
to
do.
A
So
the
second
question
is,
I
understand
it
and
correct
me
if,
if
I
understood
this
incorrectly
before
calling
the
question
spencer,
I
understood
basically
the
question
was:
is
it
useful
for
us
to
look
into
the
applicability
of
technologies
like
this,
and
that
was
actually
pretty
clear,
so
that
was
I
mean
unless
a
bunch
of
people
didn't
hum?
No,
because
they
didn't
know
what
was
being
hummed.
B
A
So
I
did
not
think
it
would
be.
I
would
not
think
it
would
be
independent
of
working
group,
but
like
actually
we
could
discuss
that
a
little
bit
right
like
so.
The
question
is:
does
it
it's
entirely
possible
that
it
doesn't
make
sense
for
us
to
charter
a
working
group
to
standardize
this,
but
it
does
make
sense
for
us
as
a
body
to
experiment
with
this.
J
Okay,
just
asking:
if,
when
we're
talking
about
the
applicability
statement,
are
we
talking
about
the
applicability
statement,
independent
of
anything
else
like,
I
think,
there's
a
fair
amount
of
interest
in
actually
thinking
about
an
applicability
statement
yeah?
But
if
the
question
is
preconditioned
on
well,
if
the
working
group
is
formed,
then,
should
we
work
on
an
applicability
statement
is
a
very
different
question
than
blanket.
B
J
We
just
work
on
this
applicability.
J
J
B
We
have
plenty
of
varied
directors
on
the
call
to
answer
the
question,
but
one
answer
that
they
might
choose
from
would
be
that's
the
kind
of
thing
that
you
charter
the
working
group
to
deliver
the
applicability
statement
and
then
recharter.
A
H
Corey
go
ahead.
Okay,
I
was
only
speaking
as
tsbwg
chat,
saying
that
this
is
a
transport
network,
perhaps
operator
interaction
thing.
So
it's
well
within
what
we
normally
do
in
tspwg.
To
think
about
this.
H
H
A
L
So
I
don't
quite
understand
why
an
applicability
step
needs
to
be
done
in
a
working
group
at
all
right
this.
This
should
be
the
proponents
of
this
work.
If
you
know,
if
they
ask
here,
is
that
the
applicability
statement
should
be
done,
it's
up
to
the
proponents
of
this
work
to
do
this.
In
my
opinion,
before
we
have
anything
charted
in
the
itf,
because
at
the
moment
we
don't
quite
understand
what
this
is
right
and
given
that
we
had
a
pretty
split
hum
just
earlier,
the
itf
should
do
anything.
L
I'm
feeling
pretty
negative
about
this
attempt
to
sort
of
put
a
positive
spin
on
this
and
come
to
something
where
we
can
say
the
itf
will
do
something
in
this
space.
Now,
I'm
in
my
book,
this
is
pretty
clear
and
you
know
more
work
is
needed
before
we
can
have
a
discussion.
Whether
we
should
do
something
here.
A
So
go
do
the
applicability
statement
and
come
back
if
that's
a,
if
that's
a
rephrasing
of
of
what
you
said.
A
Okay,
I
don't
know
we
got
four
minutes
left
spencer,
so
I
think
it's
pretty
clear
from
the
discussion
that
we've
had
that
the
draft
charter
is
presented
here
is
not
ready
for
the
ads
to
take
forward.
I
think
one
of
the
things
that
I've
heard
is
a
possible
way
forward
is,
is
write.
This
applicability
statement,
work
on
it
with
transport
input,
possibly
in
tsvwg,
and
then
take
that
as
an
input
to
a
second
working
group
forming
boff.
I
think
that's
what
I've
heard
his
outcome,
but
martin
as
a.d.
K
Yes,
thank
you
brian.
I
would
agree
with
your
assessment
of
the
sense
of
the
room
that
I
don't
think
people
are
ready
to
to
to
set
this
up.
As
a
working
group,
I
think,
having
an
apple
applicability
statement
in
tspwg
is
a
fine
idea,
and
hopefully
that
would
push
the
can
down
the
road
too
far.
K
I
would
also
encourage
proponents.
To
I
mean
we
have.
There
are
certainly
a
lot
of
open
research
questions
here
and
I
would
encourage
proponents
to
maybe
do
some
of
the
research
they
just
kind
of
wait
around.
For
this
to
happen,
there's
certainly
a
lot.
K
We
can
learn
out
there
to
make
a
lot
of
the
unknowns
clear
before
we
try
to
charter
next
time,
and
I
don't
know
if,
if
colin
wants
to
point
to
a
particular
research
group
or
not
to
to
house
that
work,
but
I
think
that
would
be
a
wise
thing
to
do.
E
I
I
mean
jonah
is
on
the
call
and
may
push
back
violently
against
this,
but
that's
the
congestion
control
research
group
wouldn't
be
a
bad
place
to
have
some
of
these
initial
discussions.
I.
J
Two
minutes
left
or
whatever
time
here.
I
I'm
not
convinced
that
this
is
limited
to
congestion
control.
I
think
this
is
a
broader
transport
level
problem,
not
that
I
want
to
fund
this.
I
think
this
can
be
a
very
interesting
discussion
and
the
document
can
actually
be
useful,
as
people
have
been
pointing
out
these
devices
exist
and
if
we
can
give
guidance
as
to
how
these
devices
ought
to
be
deployed
if
when
where
they
are
deployed,
I
think
that
could
be
actually
quite
useful,
but
yeah
I
mean
my
my.
E
Yeah,
I
think
I'd
agree
with
that.
If,
if
people
are
gonna
write
a
document
it,
it
should
probably
be
discussed
in
iccig,
it
should
probably
also
be
discussed
in
tsvwg
tsv
area
and
the
like
yeah.
I
I
don't
think
we're
setting
up
a
long-term
work
item
of
any
of
those
groups,
we're
doing
a
relatively
short
term
bit
of
work
that
gets
discussed
in
a
bunch
of
places
to
to
see.
If,
if
there
is,
then
if
it
makes
sense
to
do
the
longer
term,
bit
of
work.
A
Karsten,
would
you
be
available
and
willing
to
drive
this
forward
sort
of
in
the
I
I'm
used
to
saying
bangkok
time
frame,
but
I
don't
actually
believe
we'll
be
in
bangkok,
so
the
109
time
frame.
A
Getting
something
that
we
can
discuss
in
the
transport
working,
I
think
we
need
a
little
bit
more
sort
of
like
exposure
to
wider
parts
of
the
transport
area
here,
so
something
could
be
discussed
in
in
iccrg
and
tsvwg
and
it
would
be
so
the
the
outcome
of
those
discussions
goes
into
that
document
and
that's
an
input
to
and
a
deliverable
before,
the
second
off.
J
B
B
But
but
yeah,
but
the
point
that
the
point
I
was
making
was
that
saying
you
know
we're
going
to
go
from
forte
to
dump
this
on
carson
and
the
other
proponents,
it
seems
like
seems
like
a
real
shrinkage
on
the
amount
of
resources.
So.
B
A
Yeah,
so
I
think
that
the
the
discussion
on
this
like
on
on
looping
this
or
looping
this
up
spinning
this
up,
should
be
on
the
loops
mailing
list.
A
I
I
would
second
yeah,
so
lars
is
saying
in
the
chat
we
had
forte
for
and
against
the
point
that
we're
making
is
that
we
had
forte
four,
which
means
that
there
are
certainly
people
who
are
interested
in
seeing
this
happen
and
and
the
people
who
work
on
the
applicability
statement
and
help
karsten
out
with
that
should
be
drawn
from
the
set
of
people
who
hummed
there
so
yeah.
I
think
the
discussion
on
that
we'll
take
it
to
the
mailing
list.
Carson.
A
Please
recruit
people
from
from
among
those
who
were
here
today
and
ex.
I
would
expect
to
to
see
the
discussion
of
that
document
on
the
list
and
to
see
something
relatively
quickly
that
we
can
take
around
to
transport,
focused
venues
to
get
feedback
on
and
polish
up
for
the
next
polish
up
for
a
next
edition
of
this
buff.
A
With
that
we
are
two
minutes
over.
Thank
you
all
very
much
for
a
informative
up
off
useful
discussion,
and
I
wish
you
all
a
good
rest
of
your
ietf.
B
A
B
A
Looking
at
the
thank
you
very
much
for
the
note
takers,
if
you're
still
here,
looking
at
the
the
notes,
they
look
pretty
good,
so
we'll
compile
those
and
get
those
out
soon.
All
right.