►
From YouTube: IETF114-IPPM-20220729-1630
Description
IPPM meeting session at IETF114
2022/07/29 1630
https://datatracker.ietf.org/meeting/114/proceedings/
A
B
C
C
E
C
C
C
Okay,
we
have
now
been
teleported
to
philadelphia,
so
let's
continue
so
yeah
welcome
everyone.
This
is
ippm
last
session
of
the
week,
I
hope
you're
still
awake
and
fresh
and
yeah,
let's
get
on
with
it.
I
hope
you're
all
familiar
with
this
slide.
If
you're
not,
you
should
really
try
to
read
it
by
now
it
it
sort
of
it's
important
for
whatever
you
try
to
say
and
what
you
contribute
with
there.
So.
C
C
C
F
I
see
I'm
still
the
delegate
from
vienna,
that's
cool
yeah,
so
comp
state,
that's
on
me.
I've
sat
on
that
for
like
almost
a
month
I'll
get
to
that
like
next
week.
Ipv6
options
to
be
clear
is
with
the
well
I
mean
I
I
have
possession
of
it.
But
the
action
item
is
on
the
authors,
just
to
reiterate
that
in
case
they're
listening
and
don't
realize
that
and
8321-8889
will
probably
be
a
while
before
I
guess
through
isg.
F
C
Right
next
slide,
please,
so
we
have
a
quite
packed
agenda
today,
lots
of
drafts,
so
we
will
be
focusing
mainly
on
on
drafts
that
we
are
working
on
that
are
adopted
by
the
working
group.
So
we'll
be
starting
with
a
presentation
of
iom
data,
integrity
and
deployment.
It
will
be
presented
together
and
then
we
have
the
iom,
yang
and
stamp
yang
stamp
srpm.
C
Protocol
followed
by
a
presentation
on
the
explicit
flow
measurements
which
has
just
been
through
working
group
last
call.
Then
we
have
ippm
responsiveness
and
encrypted
pdm
v2.
These
are
the
these.
Are
the
adopted
drafts
that
we
focus
on
this.
This
meeting
are
people
fine
with
this
order
of
presentations.
D
G
G
G
A
A
A
G
H
G
C
J
Hi
xiaomi
from
zte.
I
have
a
comment
on
this
document.
I
suggest
authors
to
add
one
more
reference
to
iom
com
state,
as
you
have
seen
on
this
chair
slide.
That
document
is
now
passing
working
group
last
call
and
with
our
transporter
ad.
So
I
suggest
you
to
add
that
reference
and
add
some
description
on
the
function
of
iom
capabilities
discovery.
G
G
A
K
K
We
adjust
the
comments
from
andy
as
the
young
doctor
early
review.
There
are
some
major
minor
issues:
firstly
use
the
derived
from
our
self
for
the
when
statement
using
identities.
We
followed
this
suggestion
and
modified
the
yam
model
and
then
use
the
interface
with
data
type.
Yes,
we
align
and
the
use
of
plans
string
as
a
list
key
to
adjust.
This
we
add
length
1
to
max,
to
disallow
empty
strings
and
to
cl
clarify
the
use
of
order
by
user.
K
K
We
add
a
description
to
clarify
this.
There
is
no
monetary
type
of
profile
in
the
list,
but
at
least
one
profile
should
be
added,
and
then
there
are
several
points
in
the
model.
The
description
are
very
simple:
we
added
more
detailed
information
here
and
there,
especially
for
the
mentioned
lines
at
last.
We
cleaned
some
needs
and
that's
all
next.
K
L
L
L
L
A
Yeah,
thank
you
for
this
when
you,
when
we
have
a
new
version
that
we
think
addresses
all
of
those
early
comments.
That
looks
like.
I
think
that
early
review
is
done
quite
a
long
time
ago.
Yes,
2018.,
so
I'm
wondering
if
it
would
make
sense.
You
can
just
let
us
know
on
the
list
and
then
we
can
kick
off
another
young
doctor's
review.
L
D
I
I
So
this
is
also
added
for
the
the
two
tlus
defined
in
this
draft,
and
this
also
allows
us
to
transmit
the
tlv
flags
back
to
the
sender
so
other
than
these
two
updates.
We
added
experimental
values
for
the
tlvs
in
order
to
facilitate
the
interrupt
testing
and
implementation,
but
we
also
have
made
the
request
for
earlier
allocation
as
well.
I
I
I
L
Hi,
thank
you,
rakesh,
and
I
just
wanted
to
fyi.
We
talked
with
the
and
footer
about
some
other
methods
and
we
started
work
on
document
ip
udp
encapsulation
of
stamp
in
mpos
and
using
lsp
team
to
bootstrap
stamped
session,
along
with
their
controlling
the
path
for
reflected
test
packets.
So
aiming
this
work
for
mpos
working
group,
but
appreciate
your
reviews
and
comments
to
mpos
and
ittm
working
groups.
Thank
you.
J
I
A
L
I
haven't
thought
of
my
comments
as
objections,
so
it
was
comments
and,
as
rakesh
pointed
out,
so
we
had
a
meeting
and
we
realized
that
there
are
many
ways
to
so.
Okay,
the
problem
that
this
draft
addresses
is
real
operational
problems.
So
now
we
started
to
work
on
a
little
bit
different
approach
to
addressing
the
same
problem
so
yeah.
It's
perfectly
fine
to
go
and
help
with
the
implementations
and
get
the
early
ayanna.
So
to
put
it
in
a
good
footing,.
D
E
B
E
E
E
E
We
also
clarified
that
we
used
a
conventional
communication
setup
with
a
well-known
port
at
the
server
and
the
brian's
observation
that
authentication
mode
can
help
us
with
protections
for
features
like
bit.
Error.
Checking,
let's
see
so
like
I
said,
all
the
all.
That
sort
of
stuff
is
in
touchdown
in
note
2.,
and
we
had
this
the
original
idea
of
four
security
modes
for
operation,
the
unauthenticated
and
the
password
auth
code.
E
E
E
E
Both
parts
of
the
setup
phase
and
we
look
on
those
differently
from
the
test
phase
in
terms
of
their
demands
on
the
hosts
and
their
requirements
and
the
information
they
expose
and
also
exchange.
So
these
in
red,
we
were,
you
know,
zero.
One
of
the
draft.
We
were
adding
the
server
admission
control
and
also
the
load
adjustment
algorithm
check.
E
E
So
that's
a
that's
an
important
ad.
We
think
we
can
do
this.
Obviously
it
means
a
protocol,
modification
and
updating
the
fields
and
so
forth,
but
that
seems
doable
so
then
a
little
more
controversy
comes
when
we
get
to
the
load,
pdus
and
the
feedback
messages.
So
let
me
let
me
talk
about
the
feedback
messages.
First,
we're
sending
these
load
pdus
we're.
What
the
heck
is.
This
lies
more
lies
in
browser
user
agent
strings
from
rich
salts.
I
don't
know
what
the
hell
that
means.
Rich,
are
you.
E
I
guess
not
okay,
so
so,
when
the
load
pdus
are
flowing
in
the
test
phase,
we've
got
this
feedback
messages
and
50
millisecond
default,
and
that's
where
we
communicate
the
loss.
The
delay
the
receive
rates,
all
the
other
parameters
I
mentioned,
like
reordering
and
delay
variation
and
or
if
the.
If
the
server
is
making
these
measurements,
then
the
server
sends
the
new
sending
rate
down
to
the
client
for
an
upstream
test.
E
So
that
means
sending
the
sending
rate
structure
down
and
basically
brian's
question
here
is:
can
we
add
the
auth
authentication,
digest
and
processing
to
the
feedback,
messages
and
yeah?
So
so
this
is.
This
is
what
we'd
like
to
do
is
to
probably
do
this.
It's
probably
going
to
be
an
additional
option
beyond
authenticating
the
control
phase,
the
setup
phase
here,
and
but
it
seems
worthwhile
to
to
try
to
do
that.
E
E
So
three
things
to
keep
in
mind,
test
setup,
test,
activation,
they're,
the
control
exchanges
they're,
the
the
things
that
we
would
probably
be
easily
able
to
to
authenticate,
also,
probably
encrypt,
and
if
we
were
to,
if
you
were
to
imply
in
encryption,
then
we'd
also
need
an
additional
pack
to
open
an
ephemeral
port
on
the
firewall.
Brian,
really
looked
at
our
firewall
operations
and
gave
us
some
really
good
advice
on
that.
E
And
this
is
the
kind
of
stuff
you
know
firewall
at
the
server,
and
this
is
the
kind
of
stuff
that
would
be
really
useful
for
anybody
planning
an
active
protocol
and
installing
it
in
the
network.
So
these
with
all
things
to
keep
in
mind,
you
know,
as
I
go
through
the
details
now
tommy,
you
can
switch
to
slide
five.
E
So
I
think
you
know
we.
I
think
we
can
probably
handle
that
with
at
least
one
more
dummy
packet.
So
that's
again
a
protocol
modification
we'll
be
looking
at
so
then
moving
on
here.
We
need
to
look
at
reorganizing
the
mode
of
operations,
same
thing,
yeah,
yeah,
yeah,
so
basically,
based
on
brian's
input,
we're
looking
at
required,
authentication
for
the
control
modes,
messages,
the
test,
setup
exchange
and
activation
exchange.
D
E
Exchanges,
and
also
maybe-
and
this
a
big,
maybe
maybe
reuse
the
keen
from
the
authentic
from
the
dtls
in
the
authentication
aspects.
Then
we'd
also
have
this
optional,
unauthenticated
mode,
which
obviously
we've
got
working
now.
So
you
know
those
are
that's.
That's
our
reading
of
the
current
requirements
and
and
and
options
for
the
various
modes
of
operation.
E
E
So
basically
we're
we're
trying
to
avoid
that
if
we
possibly
can
and-
and
you
know,
we
think
we
can
do
that
on
the
other
hand,
with
the
status
pdu,
there's
a
skeptical
stuff
to
protect
here-
integrity
wise,
as
I
mentioned,
the
new
measurements
or
the
sending
rate
command
and
the
sampled
rtt
measurements.
Those
are
all
you
know,
sort
of
important
to
to
protect,
so
it
seems
viable
to
protect
those
with
the
digest.
E
E
D
E
Key
identifier
that
could
help
us
to
do
the
key
management.
We
don't
have
that
we
don't
also
have
a
config
file
for
the
key
and
the
id.
So
you
know
these
are
things
we
could
look
into
adding
brian
suggests,
or
we
could
add
a
section
just
describing
the
orderly
key
rollover.
So
there's
lots
of
options
there.
But
this
is
a
you
know:
it's
an
excellent
feedback
and
I'm
really
glad
to
get
it.
E
So
then
the
dtls
for
confidentiality
in
the
setup
phase
it
adds
re-transmission
and
order
delivery.
Those
are
good
things,
but,
with
the
cost
of
you
know
like
a
fairly
fairly
significant
dtls
setup.
As
I
understand
it,
so
you
know
I've
been
looking
at
the
pictures.
I
see
tommy
nodding
there,
it's
a
it's
a
you
know
it's
something
to
keep
in
mind.
E
E
Seems
possible,
so
you
know
we're
going
to
look
into
doing
that
and
then
again
this
I
mentioned
the
deriving
key
from
the
dtls
session.
We'd
be
looking
at
that
on
the
feedback
messages
and
if
we're
wondering,
if
you've
got
the
support
necessary
for
that
in
the
open
ssl
from
the
dtls
session.
It's
a
question.
G
E
So
we've
got
the
topic
of
silent
rejection
during
the
senate
setup
phase
in
authenticated
mode
we'd
likely
use
silent
projection
now,
because
we
don't
really
know
where
the
requests
come
from.
There's
no
authentication,
but
if
we've
got
a
successful
validation
of
authentication,
then
we
could
return
the
full
rejection
message
with
the
area
code.
We've
sorted
this
out
in
the
follow
up
and
discussions
with
brian,
and
if
we
have
authenticated
mode
with
failed
authentication,
we
could
have
the
silent
rejection
again.
E
E
E
Brian
pointed
that
out
it's
a
you
know,
kind
of
we
could
add
in
a
record
of
previously
received
messages
within
that
window
and
we
could
add
an
id
which
can't
be
replayed
with
the
same
hmac,
but
the
you
know
the
idea
is
this:
isn't
an
infrequent
diagnostic
message:
we
can't
measure
capacity
all
the
time
and
also
we're
not
norad
here.
So
maybe
we
could
not
worry
about
this
quite
so
much,
but
the
id
might
help.
E
E
The
strong
authentication
for
all
methods
is
a
good
choice.
We've
got
that
for
well
for
all
of
them
that
we
think
we
can
do
make
it
optional
for
a
site
to
deploy.
That
sounds
good,
require
it
on
the
authentication
of
the
setup
messages,
so
we're
going
to
have
a
mode
for
that
make
it
make
authentication
optional
on
the
data
plane
that
seems
defensible
to
brian
and
because
he
understands
the
effect
on
the
test
accuracy,
the
next
sector
error,
reviewer
or
the
ids.
E
They
might
not
understand
that,
so
you
know
we
got
to
make
that
clear
and
since
orderly
key
rollover
is
a
good
thing
to
have
so
we'll
look
into
adding
the
features
to
support
that
and
also
dtls
and
reusing
the
keys.
Possibly
so
that's
a
good
summary,
I
think,
of
of
all
the
kinds
of
things
we're
looking
into,
but
notice
that
that
brian
asked
the
question
look.
He
said
I
haven't
seen
anywhere
that
full
encryption
is
a
requirement
and
I
I
took
it
from
the
wording
of
of
privacy.
E
E
And
note
that
it
it's
basically
not
in
this
list,
so
so
this
is
brian's
advice
he's
not
speaking
for
the
sector
he's
not
speaking
for
the
ids,
but
this
is
all
very
reasonable
to
us.
So
you
know-
or
we
can
do
this-
I
think-
and
you
know
that's
where
we're
gonna
go
for
now
be
great.
If
we
could
hear
we
want
you
to
do
two
more
things
too.
E
E
So,
let's,
let's
look
at
these
these
measurements.
Basically,
it's
it's
a
two
ten
second
tests
in
series
on
the
one
gigabit
downloading
measurement,
it's
the
one.
It's
a
udp
7.5.0
in
debug
mode
and
we've
got
the
50
millisecond
feedback
measurement.
You
can
get
that
from
the
debug
and
packet
loss.
Measurements
are
in
blue,
so
you
see
those
counts
and.
E
Now
the
big
difference
between
type
b
and
type
c
is
that
we're
going
to
continue
to
retry
a
fast
ramp
up
mode
and
the
fast
ramp
up
mode
is
very
different.
Instead
of
being
linear
at
a
factor
of
10,
it's
now
a
multiplicative
at
a
factor
of
1.5,
the
current
sending
rate
by
the
way,
that's
a
good
thing,
and
now
what
we
see
here
is
the
the
air
bit.
E
E
M
E
E
D
D
E
E
C
E
E
F
E
F
B
E
B
F
Can
so
like
I
mean
you
asked
to
refer
to
the
like
the
previous
conversation
about
like
what
will
get
through
the
isg?
I
don't
want
to
presume
to
speak
for
roman
or
paul,
and
I
personally,
you
know,
don't
have
a
strong
position
on
it.
Maybe
it
would
be
good
to
start
like,
rather
than
just
sort
of
guess,
we
should
just
like
start
a
dialogue
with
with
them,
and
you
know
I'm
happy
to
be
included.
We
can
just
start
discussing
like
you
know
how
much
of
a
deal
breaker
is
this
for
them.
E
F
B
E
E
E
Additionally,
what
we
can
do
with
it
and
then
the
backup,
slides
you'll
see
that
we
can
implement
alternative
rates
of
rate
programming
to
emulate
applications.
So
that's
a
really
valuable
feature
of
this
protocol
and
this
it's
not
just
capacity.
It's
almost
anything.
You
can
imagine
that
you
can
write
the
load
adjustment
system,
for
it
can
be
static
and
it
can
be
dynamic
based
on
the
measurement
feedback,
so
think
about
this.
I'm
almost
sorry,
I
called
it
a
capacity
measurement
protocol
because
we
can
do
so
much
more
than
that.
E
H
E
C
C
A
A
A
E
E
A
E
F
A
L
A
A
And
then
I
was
also
wondering
you
know
like
if
we're
getting
if,
for
some
reason
we
get
pushback
on
not
having
these
authenticated
kind
of
going
into,
you
know
what
do
we
actually
think
an
attacker
could
do
with?
This
would
be
good.
I
mean
you
mentioned
they.
Could
you
know,
stop
the
test
prematurely?
A
Would
there
be
something
we
could
potentially
do
at
the
end,
either
in
a
status
feedback,
or
it
seems
like
like
the
the
final
message,
which
would
be
authenticated
to
indicate
if
one
side
like
thought
it
sent
a
stop
or
just
essentially
detect
after
the
fact
that
something
like
a
stop
bit
was
set
by
an
attacker.
So
you
could
just
confirm
that,
like
yes,
we
ran
this
test
and
there
were
the
number
of
stops
that
we
expected
to
see,
or
there
was
a
mismatch,
and
so
we
should
throw
this
result
out.
E
Yeah,
I
think
I
think
the
client
can
send
the
client
can
send
its
own
stop
bit
and
that
that
that
would
either
be.
It
would
either
be
in
the
load
if
it's
an
upstream
test
or
in
the
feedback,
if
it's
a,
if
it's
a
downstream
test
and
and
both
the
client
and
the
server
have
the
timeouts
for
ending
the
test.
D
B
C
H
Hello
working
great,
so
I'm
igor
lubachev,
I'm
going
to
talk
here
about
the
explicit,
slow
measurement.
That's
a
draft!
That's
in
the
working
group!
Last
call,
if
you
recall
the.
If
you've
been
following
it,
it's
been
basically
merged
together
from
two
different
drafts
that
explore
slightly
different
techniques
to
solve
a
very
similar
problem.
That's
why
we
have
quite
a
list
of
others
here.
Nothing
has
much
changed
since
the
were
since
the
last
call.
So
we
have
the
same
version
of
the
draft.
H
We
haven't
received
a
whole
ton
of
feedback
in
last
call,
maybe
because
it's
perfect,
but
but
so
I'll,
take
this
opportunity
to
kind
of
reintroduce
the
problem
and
show
you
what
we've
come
up
with
and
then
ask
for
hey.
If
you
do
have
some
comments
for
during
the
last
call,
I
mean
it's
awesome
time
to
to
give
them
and
to
improve
things.
So
the
problem
is
well
network
operators
need
to
be
able
to
troubleshoot
problems
such
as
loss
and
latency
issues,
and
I
mean
detect
them
first
and
to
do
that.
H
It's
really
best
to
actually
be
able
to
observe
the
problem,
because
otherwise
a
response
to
a
trouble
call.
Is
we
looked
at
a
few
at
a
few
statistics
here
and
there
we
saw
nothing,
sorry
that
might
be
just
like.
Well,
maybe
you
haven't
looked
enough.
Maybe
you
should
look
at
a
few
more
so
with
protocols
like
tcp
at
the
last
resort,
you
could
pull
out
a
wire
shark
and
try
to
observe
the
problem
as
it's
happening.
H
Tx
stuff
could
lead
leak,
some
information
that
could
be
considered
to
disclose
more
stuff
than
endpoints
wish
to
disclose
so
privacy
risk,
and
the
second
concern
is
that
unpassed
devices
trying
to
be
super
helpful,
to
be
able
to
be
very
helpful,
need
to
understand
what
they're
seeing
and
when
they
understand
what
they're
seeing
they
don't
understand,
any
different
anything
different
and
may
cause
problems,
and,
as
an
effect,
you
have
protocol
classification
that,
basically
you
just
can't
do
any
innovations
can
any
do
any
changes.
We're
all
familiar
with
that.
H
There
are
other
uses
for
these
techniques
that
are
unrelated
to
encrypted
transports,
so
we're
trying
to
find
develop
techniques
that
can
be
used
with
just
a
few
bits
like
really
really
a
few
like
one
or
two
three.
That
would
be
enough
to
figure
out
quite
a
bit
of
information
about
any
problem.
That's
happening
the
advantage
of
having
just
a
few
techniques.
H
H
H
Some
of
them
again,
the
goal
is
not
to
read
the
eye
chart
and
the
like
ever
since
this
table
is
in
the
draft,
but
the
idea
is
that
we
are
discussing
what
different
bits
do
we
compare
their
performance
in
terms
of
fidelity
versus
latency
of
the
measurement
versus
how
how
many
measurements
you
can
do
on
a
particular
flow?
So
that's
about
latency.
Next.
H
And
similar
for
loss,
we
have
many
different
loss,
metrics
you
can
derive
from
using
different
bits
or
their
combinations.
Again
we
have
a
bunch
of
analysis
for
comparing
a
different
alternative.
What
you
can
do
with
just
two
bits,
one
bit
trade-off
between
again
fidelity
and
how
quickly
you
can
see
loss
after
it's
happened.
Do
you
see
lost
shape,
or
do
you
see
just
approximate
average
loss
per
connection
round?
Three,
perhaps
anyway,
so
a
lot
of
different
analysis
here
next.
H
H
So
it
is
referring
to
I
mean
it's
square
bit
is
not
was
not
invented
here.
Okay,
it
is
just
one
of
the
signals,
so
the
purpose
of
the
draft
is
not
to
specify
bits
on
the
wire
that
will
be
up
to
the
protocols
how
to
how
they
choose
to
implement
it.
The
purpose
is
to
give
you
techniques
to
analyze
techniques
and
to
say,
and
basically
to
say,
that's
what
you
can
do
with
as
many
bits
as
you
want
to
spare
yeah.
I.
F
Mean
83-21,
even
though
it's
currently
experimental
and
headed
for
standards.
I
guess
it's
the
same
thing.
It
is
not
attached
to
a
protocol
and
I
guess
there
are
other
draft
other
drafts
that
are
instantiating
that,
but
also,
interestingly,
I
think
they've
gone
away
from
the
like
end
packets
to
having
like
a
time
interval.
H
F
H
N
Hello,
yep
yeah,
just
to
answer
to
martin
point
yeah.
The
square
bit
is
introduced
also
in
the
8321,
but
yeah
the
difference,
as
you
know
that
in
the
8321
in
particular,
in
the
proposed
standard
document,
we
focus
only
on
fixed
timer
blocks,
while
the
square
bit
is
on
based
on
fixed
number.
So
in
case,
of
course,
these
will
be
standard
track.
I
mean
the
explicit
flow
measurement.
This
will
need
a
an
accurate
detail
as
we
do
in
the
83-21.
F
H
F
Well,
I
mean,
I
don't
think
it's
a
question
of
name
class
thing
I
think
name
clashing.
I
think
like,
if
you're
going
to
use
that,
if
you're
going
to
use
a
bit
for
loss
detection,
I
think
communities
to
decide
how
that
works
and
whether
it's
this
or
whether
it's
packets
or
whether
it's
packets
or
time
either
one,
but
we
should
decide
thanks.
Thank
you.
A
A
A
F
H
And
yeah
totally,
we
should
discuss
it
yeah.
Thank
you
all
right,
so
this
slide
is
basically
talking
about
this
being
actually
in
use.
There's
a
number
of
industry,
that's
in
the
implementation,
so,
for
example,
akamai
orange,
implemented
it
and
ran
this.
For
about
a
year
in
production,
we've
made
go
back,
we're.
B
H
Good
so
I'll,
just
summarize
a
number
of
implementations
from
different
operators,
a
number
of
implementations
from
researchers,
so
that's
been
done
and
just
like
the
last
slide,
the
quick
history
of
it
is
that
we've
been
running
last
call
since
july
6.
we
just
received
on
the
least
substantive
good
feedback
from
marcus
about
some
hidden
parts
of
the
delay
bits
I
just
now
feedback
from
martin.
So
let's
looks
like
we
need
another
revision
of
it.
Let's
discuss
on
the
list.
C
A
A
O
O
We
see
it
so
you
know
you
should
see
it
in
the
presentation
mode,
yes
great,
so
so
hello.
Yes,
this
is
responsiveness
under
working
conditions.
We
submitted
a
zero
one
version
shortly
before
this
meeting
here
the
update
from
zero
zero
one
to
zero
one
is
the
mill
is
listed
here.
We
closed
the
set
of
get
up
issues
we
merged
a
few
pr's
got
a
few
contributions
and
in
terms
of
the
significant
changes,
there's
first
stuart
cheshire
added
dns
based
service
discovery
for
the
network,
quality
measurement
or
the
responsiveness
measurement.
O
That
way,
it
means
that,
if
I
am
on
my
network,
I
can
basically
browse
these
dns
based
services
that
are
being
and
the
the
services
that
are
being
announced
through
dns.
I
can
discover
them
on
my
local
network
and
just
discover
endpoints
on
my
network
that
allow
me
to
test
the
responsiveness
in
my
local
network,
so
we
hope
that
this
is
going
to
be
a
very
useful
addition.
O
We
added
server-side
example
configurations
in
the
appendix
so
that
if
people
want
to
deploy
a
responsiveness
measurement
endpoint,
they
can
simply
simply
take
a
look
at
those
example
configurations
and
we
did
a
significant
rework
of
the
measurement
algorithm
and,
of
course,
some
wording
changes
minor,
minor,
minor
fixes
and
so
on.
So
I
want
to
double
click
on
the
significant
rework
of
the
measurement
algorithm.
O
O
The
question
is
whether
we
would
be
able
to
achieve
higher
good
put
by
adding
more
connections,
because
the
bdp
of
the
path
is
is
very
large
right,
and
so
the
only
point
to
do
this
is
we
were
adding
more
connections
right
until
we
again,
we
reached
the
maximum
good
put
at
which
point
it
levels
off
again,
and
so
now
the
question
becomes
well.
Did
we
actually
reach
the
link
capacity?
Yes
or
no,
or
do
we
still
need
to
add
more
connections
and
to
learn
this?
O
We
add
yet
more
connections
into
the
pool
until
we
realize
well,
okay,
the
good
but
didn't
changed
so
there's
no
change
in
good
good
put,
and
so
we
declare
saturation
at
which
point
we
started
the
latency
probes
right.
We
sent
a
set
of
probes
on
the
load,
generating
connections
and
a
set
of
probes
on
the
separate
connections.
O
These
latency
probes
have
a
tendency
to
time
out,
so
we
may
sometimes
not
even
be
able
to
get
a
measurement,
and
finally,
these
kind
of
one-shot
measurement
that
are
happening
only
at
one
point
in
time
have
the
tendency
to
be
impacted
by
short-term
buffer
occupancy
variations
right.
We
have
seen
cases
where
there
is
on
these
load
generating
connections.
There
is
an
effect
of
what
we
call
a
synchronized
packet
loss
where
all
of
these
connections
get
a
packet
loss
at
the
same
time.
O
So
these
here
are
the
again
these
the
the
draw
the
drawbacks
of
this
algorithm.
So
what
we
realize
is
the
way
we
can
actually
solve.
Most
of
these
problems
is
by
basically
well.
We
we
keep
on
trying
to
reach
capacity
right,
but
instead
of
waiting
until
saturation
to
start
the
probing,
we
start
probing
right
away
and
we
probe
every
100
milliseconds.
We
probe
on
separate
connections
and
we
probe
on
the
load
generating
connections,
and
we
just
keep
on
going
through
the
algorithm,
and
we
continuously
probe
every
100
milliseconds.
O
We
send
one
probe
on
the
first
load,
generating
connection
and
one
probe
on
the
separate
connection.
So
what
does
this
means?
As
you
can
already
see
graphically
right?
We
have
a
lot
of
probes
now
right,
and
so
we
get
four
data
sets
with
this
approach.
We
get
latency
on
the
separate
connections,
we
get
tcp
handshake,
latency,
we
get
tls,
handshake
latency
and
we
get
http
rigorous,
respond
latency
under
on
the
separate
connections
on
the
load
generating
connection
which
we
call
itself.
We
get
also
a
http
request,
response,
latency,
and
so
those
are
now
very
large.
O
O
First
of
all,
we
take
the
90th
percentile
right,
so
that
way
we
filter
out
those
probes
that
were
happening
at
the
beginning
of
the
test.
When
the
link
was
not
yet
buff
uploaded,
then
we
need
to
weigh
those
four
different
numbers
right,
and
so
our
goal
is
to
put
equal
weight
on
the
load
generating
and
on
the
separate
connections.
O
Now
for
the
separate
connections,
we
get
three
data
points
right:
the
tcp
handshake,
latency,
the
tls
handshake
latency
and
the
http
latency,
and
so
we
weigh
these
in
in
the
way
we
show
it
here
in
the
in
the
slides.
We
have
one
sixth
for
each
of
the
separate
data
points
and
half
for
the
on
the
low
generating
data
points
that
way
both
are
weighted
equally
now.
O
This
is
going
to
give
us
a
number
in
terms
of
seconds,
and
so,
as
we
want
to
express
responsiveness
in
terms
of
round
trips
per
minute,
we
basically
normalize
it
to
rpm
for
those
interested.
This
is
the
final
formula.
60
000,
divided
by
the
p90,
is
of
the
different
values
normal
appropriately
weighted.
The
way
we
have
described
it.
O
So
the
advantages
of
this
approach
is
first,
we
have
a
very
large
sample
size
about
150
data
points
for
15
second
test,
which
is
great,
which
removes
a
lot
of
variance
which
avoids
all
of
the
issues
that
we
described
earlier.
We
have
much
less
timeout
issues,
because
the
probing
happens
right
from
the
start.
O
O
O
That
way,
any
web
service
could
basically
expose
this
responsiveness
measurement
as
a
service,
and
we
could
simply
discover
it
by
hitting
the
well-known
uri
to
see.
If
there's
a
json
config
available
issue
number
63,
we
need
to
explain
the
impact
of
congestion
control.
It
came
up
in
the
past,
but
we
haven't
yet
had
the
time
to
address
this
question
and
we
want
to
write
a
section
on
how
the
different
congestion
control
algorithms,
like
cubic
bbr
and
so
on,
can
affect
the
responsiveness
issue
number
55.
O
O
Issue
number
66.
What
l
also
brought
up
is
we
need
to
allow
non-tls
measurements
because
on
some
low
end
devices,
if
we
want
to
allow,
for
example,
that
your
router
exposes
the
dns
servers
via
the
the
service
through
dns
space
for
discovery
right
low-end
gateways,
usually
don't
have
the
performance
to
actually
fill
the
link
with
tls
traffic,
which
self-generated
tls
traffic,
and
so
we
want
to
allow
for
non-tls
measurements
and,
finally,
the
most
important
one
search.
O
So
if
we
look
at
what
I
explained
earlier
in
terms
of
our
algorithm
right,
we
have
we
are
measuring.
We
are
trying
to
reach
the
maximum
good.
Put
now
good
put
is
actually
not
what
we
are
measuring.
We
are
trying
to
measure
responsiveness,
which
is
the
buffer
bloat,
and
so
it
means
we
are
trying
to
measure
the
buffer
occupancy.
O
O
So
as
we
go
through
the
algorithm
and
as
we
start
with
four
connections,
right
and
often
one
tcp
connection
has
has
frequently
a
limit
in
terms
of
how
much
data
it
could
can
put
in
flight
and
for
someone
typically,
this
can
be
around
four
megabytes.
Eight
megabytes,
six
megabytes.
For
this
example.
Let's
pick
four
megabytes
right,
so
we
have
four
connections
with
a
maximum
of
in-flight
data
of
being
four
megabytes.
O
That
would
give
us
a
maximum
of
in-flight
data
of
16
megabytes,
which
means,
as
we
are
on
the
top
graph
right.
We
are.
We
have
created
those
four
connections
and
we
are
leveling
out
in
terms
of
good
put.
We
haven't,
however,
yet
achieved
the
maximum
good
put,
which
means
the
buffer
occupancy
will
be
zero
right,
there's
no
buffer
block
yet
happening.
O
Now
our
algorithm
decides
to
add
more
connections.
Let's
say
we
add
eight
connections.
Now:
okay,
so
eight
connections
times
four
megabyte
means
16
megabytes.
So
the,
however,
we
are
still
reaching
to
the
good
puts.
We
haven't
yet
reached
this
point
of
inclination
where
we
are
actually
creating
buffer
bloat.
O
Now,
as
we
reach
the
maximum
good
put,
we
actually
start
building
a
queue
now,
and
so
now
the
queue
starts
filling
up,
but
as
it's
only
eight
connections,
which
means
16
megabytes
worth
of
buffer
occupancy,
we
haven't
yet
completely
filled
the
link.
We
are
only
at
64
megabytes.
Sorry,
we
are
only
at
16
megabytes
on
a
64
megabyte
buffer
right
now
our
algorithm
keeps
on
adding
more
connections
right.
So
now
we
are
at
12
connections
and
the
buffer
occupancy
keeps
on
increasing.
O
Now,
at
this
point
in
time,
we
realize
okay,
we
reached
capacity
for
the
good
put,
and
so
we
declare
saturation
and
we
terminate
the
test.
What
does
this
mean?
Well,
this
means
that
this
is
the
responsiveness
that
we
measured,
but
in
reality
the
responsiveness
is
much
much
worse
right.
We
haven't
even
yet
filled
the
buffer
completely.
O
So
what
is
the
solution
to
this
problem
right?
Well,
the
solution
is
we
go
through
this
algorithm,
but
then
we
see
that
well,
actually,
the
buffer,
the
responsiveness
is
still
evolving
right.
We
haven't
leveled
out
the
responsiveness
yet
and
as
we
realize
that
okay,
with
12
connections,
we
reach
48
megabytes
of
buffer
occupancy,
and
so
we
can
say:
okay,
we
we
leveled
out
at
12
connections.
Let's
add
more
connections
to
see
if
we
can
push
it
even
higher,
so
we
add
more
connections
and
we
realize
that
the
buffer
occupancy
is
increasing.
O
The
only
way
for
us
to
find
out
whether
really
we
achieved
64,
the
full
buffer
occupancy
is
by
have
one
more
iteration
of
adding
more
connections
and
we
realize
by
adding
more
connections.
We
are
not
the
good
but
is
not
changing,
nor
is
the
buffer
occupancy
changing,
and
so
it
means
we
can
declare
saturation
and
we
can
declare
the
final
responsiveness
result.
O
So
this
is
the
new
algorithm,
so
it
means
that
we
not
only
need
to
saturate
good
put,
but
we
also
need
to
saturate
responsiveness
and
once
good,
put
and
responsiveness
stop
changing.
We
declare
saturation
and
so
in
in
the
I
in
the
draft
for
the
upcoming
version.
What
we
need
to
change
is
in
terms
of
the
algorithm
is
that
we
are
adding
connections
as
long
as
either
good
but
increases
or
the
responsiveness
is
decreasing.
O
So
this
is
going
to
be
the
new
algorithm
for
the
next
for
the
upcoming
version.
In
terms
of
other
news,
the
open
source
go,
go,
responsiveness,
implementation
is
evolving
rapidly
and,
of
course,
we
would
like
people
to
try
it
out.
We
invite
everyone
to
to
test
it
will
here
is
on
this
call
and
would
be
very
happy
to
get
pull
requests
and
github
issues
as
well.
O
O
E
Kristoff
and
will
for
your
work
on
this.
I
think
that
the
the
one
thing
you're
going
to
want
to
fix
in
the
draft
is
the
is
the
equation
for
responsiveness.
I
was
about
to
do
something
with
it
and
I
noticed
that
instead
of
one-sixth,
you've
got
one-third
in
all
the
denominators
there,
accepting
the
something
the
last
one.
So
I
I
was
confused
by
that,
but
I
see
now
that
you
mean
one-sixth
and
that
sort
of
adds
up
to
one
with
the
half
half-weighted
aspect.
E
I
think
that
when
you're
also
when
you're
reporting
capacity-
it's
you
know
it's
based
on
it's
based
on
a
lot
of
connections
and
that's
the
then
I
I
tried
it
out
on
a
couple
of
cases.
I
saw
20
connections
and
so
forth,
and
you
know
those
are
you're
going
to
get
if
matt
mathis
was
probably
here
too,
you
would
say
the
same
thing:
you're.
E
H
E
Think
you're
on
the
right
track
in
monitoring
the
delay,
as
well
as
the
good
put,
but
there's
other
factors
here
too.
That
matter-
and
you
know-
we've
been
we've
actually
been-
we've
actually
been
looking
at
in
our
capacity
measurement,
we've
been
looking
at
the
the
possibility
to
reduce
the
some
of
the
factors
we
found
that
reordering
and
duplication
they
happen.
They
happen
on
5g
networks,
more
prevalently
than
any
place
else,
and
the
truth
is
those
are
measurements
that
or
packets
that
are
delivered,
that
contribute
to
capacity.
E
So
tcp
isn't
going
to
tell
you
about
those.
You
know
it's
going
to
discard
those
as
as
it
forwards,
information
up
the
stack,
but
we
can
grab
those
in
the
udp
measurements
and
you
know,
like
we
end
up.
We
end
up,
including
the
reordered
and
duplicate
packets,
now
we're
thinking
about
making
that
the
default,
especially
for
mobile
testing.
So
you
know,
there's
lots
of
there's
lots
of
room
for
improvement
in
our
algorithms
here,
and
you
know
I'm
glad
to
keep
exchanging
ideas
with
you.
Thanks.
D
A
Right
I
jumped
and
cue
not
chair
head
on
just
to
comment
one
earlier.
You
mentioned
the
the
issue
about
using
a
well-known,
and
I
looking
at
that.
I
think,
there's
some
debate
about
you
know
what's
in
that,
is
that
just
the
config
is
that
the
actual
test
overall
within
kind
of
http
I
mean
there's,
certainly
a
sentiment
that
well
known
can
be
overused.
A
I
think
this
is
a
decent
use
of
it,
but
I
think
it'd
be
worth
if
you
want
to
drop
a
line
to
mark
nottingham
who
has
to
review
all
of
those
anyway
to
see
you
know.
Is
this
going
to
be
something
that
would
get
through
the
expert
review
for
adding
well-known
and
any
advice
there
that'd
be
good
to
get
regarding.
D
A
New
new
algorithm,
I
think,
everything's
good
one
of
the
things
that
came
up
in
the
chat.
I
think
there's
questions
about
like.
Why
would
you,
for
example,
not
just
measure
when
the
responsiveness
starts
decreasing
and
I
think
the
answer
to
that
is
you
know
the
responsiveness
won't
actually
decrease
until
there's
enough
load.
A
I
think
then
one
edge
case
came
up
to
me.
It's
like.
Are
there
any
scenarios
in
which
the
responsiveness
only
starts
decreasing
further
to
the
right,
such
that
you
know
like
we
could
get
to
16,
and
you
know
our
good
put
has
flattened
out,
but
the
responsiveness
will
only
start
going
up
starting
at
20
or
24,
and
so
we
could
actually
stop
the
test
too
soon.
Is
that
something
we
should
be
concerned
about.
O
O
M
So
we
kind
of
keep
a
high
score
of
the
highest
throughput
we've
seen
and
the
highest
latency
we've
seen
and
every
time
we
break
that
record.
We
record
the
new
record
after
we've
gone
for
four
seconds.
Without
setting
a
new
record
for
either
of
those
things,
that
means
we've
added
four
more
connections,
we've
put
more
data
into
the
pipe
and
neither
has
changed
and
just
to
back
up
a
little
bit
to
second,
what
kristoff
was
saying
as
we
have
more
data
in
flight.
M
M
If
we're
continuing
to
add
more
data
in
flight,
then
within
four
seconds
we
will
have
seen
the
delay
go
up
and
that
will
cause
us
to
keep
testing
until
delay
stops
going
up.
So
that's
your
answer.
Tommy.
I
think.
If
we
didn't
have
that
four
second
window,
there
would
be
a
risk
of
a
premature
exit,
but
that
four
seconds,
I
think,
is
what
makes
it
work.
M
M
But
as
an
engineer,
I
want
to
know
why
so
we've
been
talking
to
home
gateway,
vendors
and
wi-fi
access
point
vendors
who
actually
want
to
host
a
test
endpoint
on
their
wi-fi
access
points
or
on
the
home
gateway.
So
you
can
eliminate
the
modem
or
the
dsl
from
the
equation
and
do
a
local
test
and
see.
Is
it
my
wi-fi
or
is
it
my
cable
mode,
that's
causing
a
problem.
M
P
D
P
I
I'm
not
sure
how
noisy
it
is,
because
you
know
the
inside
the
the
network,
you
you
got
some
other
traffic
and
perhaps
I
I'm
not
sure
if
you
are
just
mentioning
just
I
I
don't
know
the
the
last
smile
or
something
like
that
or
you
are
measuring
something
more
more
bigger
than
that.
But
I
imagine
that
there
are
the
there
is
some
some
traffic
more
traffic
and
could
be
a
little
noisy.
P
O
Yeah
thanks
for
your
comment,
so
maybe
I
I
didn't
introduce
that
properly
at
the
beginning.
What
we
are
measuring
here
is
end-to-end
capacity
and
end-to-end
responsiveness
so
from
the
client
to
the
server
right.
So
it's
not
necessarily
last
mile
it
is
wherever
the
bottleneck.
The
bottleneck
is
up
for
this
kind
of
communication
right
so.
L
Q
Q
It's
put
on
at
the
source
at
the
end,
use
end
client
and
we
put
in
a
sequence,
number
and
timing.
The
idea
is
to
be
able
to
very
quickly
separate
server
time
from
network
time
and
the
potential
users
are
large
enterprises,
okay,
and
so
what
have
we
done?
We
had
an
early
sector
review
and
I'll
go
through
that
and
we're
working
on
implementation
of
this
and
we're
also
testing
extension
headers
across
the
internet
and
I'll
talk
about
that.
Q
Q
So
this
is
the
sector
review
and
basically
they
said
it
wasn't
ready,
because
it's
still
very
early
and
and
there's
a
few
things
left
to
do
basically
on
authentication
authorization
and
so
on,
and
otherwise
they
think
it's
pretty
good,
and
so
we
will
continue
to
work
with
them.
We
feel
pretty
good
because
it
doesn't
look
like
there's
huge
amounts
to
change
and
we'll
address
whatever
there
is,
so
that
was
that
feels
good,
okay.
Q
Next,
so
the
big
thing
that
we
did
this
last
time
other
than
implementation
is
look
and
see,
can
ipv6
extension
editors
can
actually
be
used
because
if
they
can't
we're
wasting
our
time
in
defining
this
thing,
it
doesn't
matter
encrypted
or
not.
It
won't
work.
So
so
that's
what
that's
what
we
did,
and
so
we
tested
stuff
so
so
next
and
so
what
we
did,
and
so
so
what
we
did-
and
this
is
a
this-
is
the
start
of
the
testing.
Q
Q
So
I'll
show
you
that,
and
the
other
thing
we
did
is
we
did
it
across
on
a
couple
of
different
continents,
maybe
yeah
three
different
continents,
four
different
and
a
bunch
of
different
cities.
The
idea
is
is
to
see
if
it's
going
through
the
core
of
the
internet,
because
if
it's,
you
know
because
we
want
to
find
out,
is
it
being
stopped
at
the
source?
Is
it
being
stopped
at
some
transit
network?
Is
it
stopped
at
the
destination?
Q
If
extension
headers
are
not
getting
through,
then?
Where
are
they
and
ideally,
why
are
they
so
next
and-
and
so
it
was
real
easy
because
pdm,
our
mod
to
the
kernel,
sends
pdm
with
every
packet.
We
can
just
do
a
very
large
ftp
and
that's
what
we
did
and
this
one
happens
to
be
toronto
to
mumbai,
and
you
can
see
it
was
a
big
old
ftp
and
successfully
transferred
next.
C
F
Q
Q
Q
Q
Q
Q
Hey,
let's
just
see
one
step
at
a
time,
let's
see
where
we
got
problems,
because
you
know
the
other
thing
too,
like
like,
let's
find
out
where
what's
the
situation,
where
is
it
being
dropped?
Why
is
it
because
I
tell
you
just
right
in
our
testing
at
the
hackathon,
we
found
one
bug
in
a
particular
router
implementation,
where
the
the
hop
by
hop
header
just
right.
Q
There
wasn't
going
out
at
the
source,
and
so
of
course
the
question
is
what
happened
if
they
fix
their
bug
right
and
like
lo
and
behold,
you
know
so
so
and
and
now
it's
it's
super
interesting
we're
also
talking
to
the
free
router
people.
I
just
had
the
little
young
man
write
me
back,
we'll
we'll
we'll
modify
free
router
to
send
h-by-h.
I
mean
hbh,
because
what
I
think
is
if
we
can
bypass
if
we
can
control
all
the
equipment.
Q
If
we
can
control
the
equipment,
control
the
end
points
and
know
exactly
what
it
is,
we're
testing.
I
think
we
gotta
we
have
some
shot
at
figuring
out.
What
is
the
actual
situation,
yeah
any
feedback
or
comments
or
anything
that
anyone
has
on?
You
know
what
we're
forgetting
you
should
remember
to
test
this.
You
know,
please,
please
let
us
know
we
happy
to
test
yep,
we'll
more
results.
Next
time.
C
N
C
L
So
if
you
look
at
this
figure,
so
you
see
that
their
period
where
their
particular
slow,
a
particular
metric,
is
within
acceptable
range.
But
then
there
are
periods
when
it
exceeds
the
critical
threshold
and
these
periods
are
can
be
considered
as
service
and
unavailability,
whereas
there,
when
it's
acceptable,
that's
acceptable
and
thus
it's
a
service
availability
period.
Next
slide,
please.
F
L
L
L
L
And
with
terminology,
so
if
you
recall
in
the
first
version,
we
were
not
yet
decided
whether
referred
to
the
metrics
as
errored
time
intervals
and
well
violated.
So
we
just
discussed
and
comments
from
that
helped
us
us
to
settle
on
a
violated
term.
So
now
everything
is
referred
to
as
violated
intervals,
severe
violated
intervals
or
violation.
Free
interval
next
slide.