►
From YouTube: IETF109-IPPM-20201116-0500
Description
IPPM meeting session at IETF109
2020/11/16 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
A
C
A
A
C
A
A
A
A
A
A
A
A
F
See
if
this
works
great
hi
yeah,
I
just
wanted
to
to
kind
of
one
comment
about
the
stuff
in
iesg
evaluation.
So,
as
you
know,
tommy
I
just
pushed
the
button
a
stamp
option
to
uob.
So
that's
off
the
rc
editor.
So
thank
you.
Greg
for
staying
on
that
and
iom
data
has
been.
I've
been
waiting
on
a
revision
on
that
for
about
three
months
now.
F
A
A
B
C
B
Combination
of
the
v6
deployment
and
the
euler
v6
options
and
then
telus
going
to
go
and
talk
about
the
other
two.
So
on
the
v6
options
draft,
if
you
flip
to
the
next
slide,
there
is
two
updates
that
we've
done
so
you've
seen
two
new
revisions:
the
o3
and
the
o4
version.
The
o3
version
was
a
reflection
of
the
last
working
group
meeting
where
we
at
length
debated
well
how
we
should
go
and
address
the
fact
that
well,
there
was
a
a
section
on
deployment
considerations
which
was
outdated.
B
Well,
that
was
a
stale
paragraph,
because
we
had
all
the
deployment
considerations
moved
to
the
quote-unquote
deployment
draft
and
so
based
on
the
chair's
recommendations.
We
decided
to
go
and
merge
the
two
documents,
as
opposed
to
progress
them
independently,
and
so
that
happened
and
the
o3
version
was
just
an
editorial
merge
with
kind
of
nuances
to
go
and
resolve
circular
references,
otherwise
right
because
the
the
documents
were
referring
to
each
other.
B
So
that's
the
the
all
three
thing
that
that
happened
along
with
obviously
removing
the
the
paragraph
in
question
and
if
you
flip
forward
one
additional
slide,
then
you'll
see
that
after
the
merger
tell
me
if
you
can
go
and
go
to
the
next
slide.
Okay,
thank
you.
Then
tommy
spent
a
little
bit
of
time.
That
was
one
too
fair.
B
Was
this,
like
the
author
list?
Is
too
long,
so
the
typical
thing
that
we
have
and
so
suggestion
is
to
again
move
to
an
editor
model
like
we
had
it
with
the
the
data
draft,
which
would
mean
like,
given
that
sweater
authored,
pretty
much
the
v6
option
document
and
wrote
it
and
I
wrote
the
deployment
draft
to
a
large
extent.
B
The
suggestion
is
just
to
go
and
have
these
two
pieces
with
people
as
editors,
and
if
there
is
nothing
other
major
coming
up,
I
think
we
can
go
and
aim
for
maybe
another
revision,
maybe
none
and
well.
We
need
one
revision
to
go
and
clean
up
the
author
list,
but
maybe
we
can
also
go
and
do
additional
nuances
if
somebody
has
ones,
but
I
believe
what
we're
very
close
to
being
able
also
to
go
and
go
to
work
new
gospel,
that's
pretty
much.
It.
A
Yeah,
I
don't
see
anyone
in
the
queue
yeah.
Thank
you
for
that
update
and
just
a
comment
in
general
on
our
author
lists.
You
know
this
is
kind
of
the
same
comment
we're
going
to
have
on
any
document
that
has
the
warning
within
the
rf
within
data
tracker.
So
please,
if
you
have
a
lot
of
authors,
let's
do
an
editor
model,
there's
nothing
wrong
with
doing
that.
So
thank
you
for
being
willing
to
move
to
that
authors.
A
I
H
H
H
It
clears
that
low
back
flag.
So
on
the
reverse
path,
the
luba
flag
is
not
set,
and
now
iom
transit
nodes
along
the
path
just
push
iom
data
and
once
that
packet
reaches
the
iom
edge
at
the
edge
of
the
domain.
Basically,
the
encapsulating
node,
which
originated
the
lubeck
packet,
receives
that
looped
back
packet
and
detects
the
fact
that
this
was
a
loopback
packet
based
on
comparing
its
node
id
to
the
id
of
the
current
iom
node.
H
H
D
E
E
H
Yeah
we've
had
this
question
in
the
past
and
again
it's
it's
somewhat
of
a
semantical
question,
but
direct
exporting
is,
in
my
view,
management
plan
entity.
Basically,
the
result
is
reporting
to
report
it
to
a
collector,
whereas
blue
back
is
used
by
the
data
plane.
Okay
or
it's
a
control
plane
entity,
but
it's
used
along
the
path
of
the
data
plane.
H
E
But
in
direct
export,
as
I
understand
their
destination
of
this
exported
packet
could
be
their
edge
of
iom
trace
so
right
good
effectively,
it
can
be
anything
including
the
node
which
is
receiving
in
the
loopback.
So
from
that
point
of
view
it
does
look
like
the
loopback
is
a
special
case
of
the
direct
export.
H
Right,
yes
again,
I
think
we've
discussed
this
in
the
past,
so
you
could
implement
loopback
by
direct
export,
but
you
would
get
a
slightly
different
result
because
again
in
loopback,
you
get
the
ion
data
from
each
of
the
iom
nodes
along
the
path
and
in
direct
exporting.
You
only
get
the
information
from
a
single
iom,
node
at
the
time
so
buy
routine.
E
E
I
F
F
I'm
somewhat
concerned
about
corner
cases
where
multiple
namespaces
are
interacting
in
ways
that
cause
geometric
or
even
infinite
loops
of
of
of
of
iom
packets
going
back
and
forth.
I
will
take
that
to
the
list,
because
it
would
be
impossible
for
me
to
explain
verbally
right
now,
but
just
please
look
out
for
that
and
I'd
be
interested
in
your
thoughts
on
this.
If
you
would
like
me
to
talk
through,
I
can,
but
I
have
a
feeling
it
just
gets
too.
J
Yeah,
I'm
actually
still
worried
about
the
amplification
attack
because
it's
different
than
with
trace
routers
tracer.
You
have
to
send
one
packet
for
every
packet
you
receive
back
and
that's
not
the
case
here.
You
have
to
send
one
pack
and
get
like
bunch
packets
back
depending
on
how
long
it
passes.
J
So
I
mean
like
the
minimum
would
be
to
talk
about
rate
limiting
these
kind
of
things
you
can
reflect,
but
I
think
if
you,
if
you,
if
you
consider
a
different
design
for
getting
the
same
information,
that
would
be
worth
it
like,
instead
of
trying
to
reflect
from
every
router
one
single
packet,
you
could
just
send
one
packet
back
on
the
on
the
reverse
part
and
accumulate
information
there,
or
something
like
that.
Because
that's
a
serious
issue
and
I
think
it
needs
to
be
further
addressed.
H
H
Okay,
so
the
magnitude
of
the
amplification
is
limited
and
we
also
discussed
rate
limiting.
Like
you
mentioned,
that's
that's
also
one
of
the
things
that
is
described
in
the
draft,
so
I
think
we
at
least
tried
to
point
out
the
problem
and
to
suggest
solutions,
and
I
think
the
your
your
last
suggestion
to
basically
limit
the
number
of
responses
you
get
from
each
message.
J
Yeah,
so
the
problem
is,
there
is
a
tradeoff
right
and
this
is
a
serious
attack
and
the
problem
is.
This
attack
is
not
really
limited
in
a
protocol
way
that
you
can
say
you
know
it's
never
more
than
this
much
packet
right.
It
can
be
like
a
huge
number
of
packets
and-
and
I
think,
that's
still
not
really
satisfying-
I
did
I
did
somehow
over
at
the
rate
limiting,
because
I
was
looking
at
the
security
section
and
it
doesn't
say
anything
there.
D
H
So
we
had
a
long
discussion
about
this,
both
in
design
team
meetings
and
on
the
mailing
list,
and
we've
recently
submitted
an
updated
draft.
We
have
two
pending
open
issues
which
we're
going
to
discuss
in
the
next
few
slides,
so
bear
with
me.
The
main
change
in
the
current
version
of
the
draft,
which
is
version
zero
two
compared
to
the
previous
version,
is
that
we
moved
the
discussion
about
the
hub
count
to
an
appendix
so
right
now
in
terms
of
the
functionality
of
the
draft.
H
It
does
not
define
a
hop
count
field,
but
it
does
have
an
appendix
that
discusses
the
need
for
hub
count
how
it
can
be.
It
can
be
implemented
by
using
the
ttl
data
field,
the
node
id
hub
limit
data
field
and
the
trade-off
between
having
a
dedicated,
hop
count
field
and
using
the
existing
data
fields.
H
A
few
words
about
this
open
issue,
so,
regarding
the
hubcount
field,
we've
discussed
this
a
few
times
in
the
past.
So
just
a
few
words
to
recap
here,
so
it's
either
we
don't
use
a
spec,
dedicated
hop
count
field
or
we
do
use
it.
So
if
we
don't
use
a
dedicated,
hop
count
field,
the
main
advantage
is
that
iom
nodes
along
the
path
do
not
need
to
update
the
direct
exporting
option
header
they
just
need
to
forward
it
to
process
it,
which
simplifies
what
ion
nodes
need
to
do
in
terms
of
direct
exporting.
H
H
H
Header
and
the
other
is
to
have
a
16
byte
option
header
and
in
the
second
mode
you
also
have
two
fields
which
are
sequence
number
and
the
flow
id,
so
these
two
fields
are
optional
and
the
way
the
draft
defines
it
right
now
is
that
the
length
of
the
option
header
is
implied
by
the
lower
layer
headers.
So
you
know
the
length
by
reading
the
header
of
the
previous
layer,
so
the
open
issue-
and
we've
discussed
this
in
the
past.
H
What
happens
if,
in
the
future,
we
want
to
add
more
fields
to
the
direct
exporting
option?
That
would
mean
we
would
have
to
somehow
indicate
which
which
mode
is
used
which
fields
are
used.
That
would
be
a
problem.
So
how
do
we
handle
this
open
issue?
One
solution
would
be
to
use
the
reserved
flags
right
now.
We
have
quite
a
few
reserved
flags.
We
can
use
some
of
them
to
indicate
whether
we
have
the
optional
fields
or
not.
H
H
A
A
D
B
C
B
We
have
a
sequence
number
defined
for
end
to
end
in
the
current
data
draft,
which
would
redefine
index,
and
I
don't
really
see
a
logic
where
we
would
need
to
go
and
make
dax
a
replication
of
what
we
have
in
other
fields,
as
opposed
to.
We
use
decks
as
a
very,
very
simple
one,
fixed
header,
no
options,
and
then
everything
else
that
should
go
and
have
additional
flexible
fields
could
go
into
other
options
that
are
already
built
for
tracing
for
for
for
flexibility
right.
B
I
think
we
have
one
in
the
lightning
talks
where
people
argue
for
new
fields
and
we
can
have
a
new
field
that
says
well
flow
id,
for
instance,
what
we
have
in
the
data
in
the
dex
option
right
now
and
add
that
maybe
to
e2e,
so
that
would
cut
things
and
make
it
relatively
simple.
We
can
go
and
close
stacks
and
then
resolve
the
issues
that
we
all
have
here.
B
E
Good
update,
thank
you
and
definitely
would
like
to
contribute
to
the
discussion.
I
would
come
reading
and
send
a
note
on
the
mailing
list
about
their
options.
I'm
strong
believer
in
tov
and
I
think
that
that's
the
most
flexible
and
that's
what
we've
done
for
stamp
extensions
so
might
be.
We
can
reuse
this.
A
A
Ago,
all
right
we're
not
hearing
anything.
Maybe
you
could
put
your
comments
in
the
chat
if
that's
okay,
because
we
should
probably
move
on
for
time
reasons
yeah.
So
thank
you
to
all
for
presenting
this.
I
think
we've
gotten
a
lot
of
good
input
here
for
people
who
did
comment.
Please
send
an
email
to
the
list
about
this.
A
Much
all
right
so
next,
I
think
we
are
getting
into
some
of
the
documents
that
we
have
calls
for
adoption
out,
starting
with
the
ones
that
are
related
to
the
spring
working
group
documents,
where
we
have
two
proposed
extensions
to
stamp
and
two
amp
that
have
been
spun
off.
So
we
could
discuss
those
here
in
ippm,
so
rockets
do
you
wanna?
A
A
I
I
So
this
is
addressing
two
requirements:
one
is
being
the
in-band
delay
and
the
synthetic
loss,
as
well
as
a
standalone,
direct
mode
loss
measurement
and
the
scope
of
this
draft
is
t1
lite.
That's,
basically
the
messages
that's
defined
in
five,
three:
five:
seven
test
messages
with
a
user
configure
ipvp
paths
which
are
very
similar
to
the
one
that's
rfc
8762
stamp.
That
became
a
standard
recently
next
slide.
I
Please
so,
as
we
mentioned,
that
there
is
a
spring
draft,
corresponding
drop
for
this
ippm
extensions
and
in
this
string
spring
drops
defines
procedures
for
end-to-end
sr
paths
for
srm
pls,
as
well
as
srv6
data
planes,
as
well
as
for
links,
and
here
the
there
is
basically
the
protocol,
extensions
that
in
theo
applied.
There
are
two
of
them
and
next
slide.
Please.
I
I
I
I
F
I
I
I
I
There
is
also
showing
us
entire
packet
or
loss.
We
should
be
very
clear
about
this-
is
that
word
loss
measurement,
some
editing
to
move
some
text
from
one
section
to
another,
so
yeah
we
would
be
making
those
editorial
changes
as
well.
There
was
a
proposed
well,
maybe
we
can
use
icmp
for
direct
loss
measurement.
We
think
that's
out
of
scope
for
this.
This.
The
focus
of
the
draft
is
the
t1
base
messages
next
slide.
Please.
I
Yeah,
so
these
were
the
comments
very
specific
to
this
draft.
There
are
comments,
some
comments
as
well
for
the
spring
drafts,
and
there
are
some
comments
as
well
for
the
scan
and
apps
that
we
will
take
a
look
the
next.
So
many
thanks
for
all
your
great
support
on
the
mailing
list
and
the
review
comments
that
you
have
provided.
I
I
I
I
I
I
I
Again,
the
review
comments
are
very
similar,
so
draft
status.
I
think
the
previous
comment
doesn't
apply.
This
one
is
already
proposed
standard,
so
we're
just
updating,
rfc
8762,
pretty
much.
Everything
else
is
the
same
in
terms
of
review
so
yeah.
This
is
also
in
adoption
for
many.
Many
thanks
to
your
review
comments
and
suggestions.
Yeah
thanks.
E
E
E
I
I
E
I
F
F
Okay,
that's
interesting!
It's
it's
very
much
conceptually
different
from
what
I
perceive
a
lot
of
iptm
stuff
to
be,
which
is
like
measurement
techniques,
to
like,
say
that
you
know
to
say
that
there's
already
a
device
doing
this
measurement,
we're
just
trying
to
like
extract
it
from
the
device
is
like
why
not
just
use
http
or
something
to
get
that.
I
Yeah,
so
we
already
have
the
t-wamp
like
machinery
which
collects
timestamps
today
and
and
hoping
the
whole
thing
just
to
collect
the
counters
from
tx
and
rxi.
This
has
been
done
in
like
y1732
or
rfc6374,
so
there
are
precedence
of
this
hardware
capabilities
that
exist
for
the
counters,
the
hardware
capabilities
that
exist
for
t1.
I
F
Okay,
fair
enough,
I
I
I.
I
hope
that
between
my
comments
and
greg's,
maybe
some
ideas
and
how
you
could
flush
out,
at
least
like
the
introduction
of
this
document,
a
little
more
just
to
sort
of
say
what
prob
exactly
is
being
solved
and
maybe
not
get
too
deep
into
like
spring
terminology
for
people
who
aren't
familiar
with
it.
Thank
you.
A
A
E
A
A
K
Ippm
connectivity
monitoring
third
version,
I
applied
for
adaption
at
the
work,
and
this
was
actually
running.
The
scope
is
monitoring
second
routed,
subpath
or
links
and
to
detect
and
locate
loss
of
connectivity
and
congestion,
and
that's
the
value,
add
detecting
the
location
of
congestion,
which
is
enabled
if
this
draft
is
supported,
it's
a
based
and
only
work
with
mphs
segment,
routing,
I'm
not
sure,
but
it
could
work
with
ipv6
segment.
Routing
too
so
properties
is
monitor,
network
sections
with
known
topology,
not
unknown
ones.
K
One
measurement
path,
monitored,
link
that
is
important.
The
design
is
so
that
you
roughly
have
the
same
functionality
as
if
you
work
with
a
ping
and
yep.
There
is
one
important
issue
change
point.
Detection
doesn't
require
well
synchronized
timestamps,
so
it's
a
differentiating
matrix
metric
and
it
applies
segment
routing
to
allow
for
an
a
prior
design
network,
tamography
evaluation
and
a
limited
number
of
monitoring
systems.
So
it's
important
you
do
not
have
to
work
on
routers.
You
can
work
on
routers,
so
it's
just
depending
on
what
you
want
to
use
it
for.
K
K
So
this
is
shown
here
in
the
slide.
I
do
not
want
to
go
to
details,
but
you
need
to
be
relatively
strict
in
setting
up
paths
like
shown
here,
and
I
think
that
should
be
done
in
an
automated
fashion
if
you
run
it
out
on
a
larger
scale.
But
this
is
not
part
of
the
draft.
The
draft
is
only
dealing
with
the
methodology
and
the
metric
right.
K
The
important
thing
is,
every
measurement
path
is
set
up,
as
shown
above
you
have
one
u-loop,
you
have
one
downlink
measurement,
one
uplink
and
below
you
see
that
on
each
measured
path
you
have
pretty
much
the
same
mix
of
three
different
paths
or
the
green
one
is
the
uplink
one.
The
blue
one
is
the?
K
So
this
is
a
difference
to
a
ping
where
you
do
not
know
exactly
where
the
congestion
is
located,
because
you
cannot
differentiate
that.
So
that's
the
value
add
of
this
contribution.
All
right.
I
don't
want
to
go
to
details.
If
you
have
time
read
the
slide,
it
roughly
tells
you
what
to
do.
I
received
questions
during
the
discussion
on
the
list
and
these
were
related
to
the
temporal
resolution
of
event
detection.
K
Temporal
properties-
I
just
see
that
I
was
hard
to
hear
and
but
I
didn't
think
that
through
so
this
is
a
a
quite
simple
answer,
and
that
tells
you
what
can
be
done.
The
aim
is
not
to
replace
any
hello
messages
which
are
exchanged
directly
on
a
link
with
neighbors.
The
aim
is
to
monitor
networks
on
a
time
scale-
maybe
seconds
maybe
minutes
and
just
be
aware
where
you're
forwarding
doesn't
work,
because
that
is
what
this
draft
do.
There
is
no
interaction
with
routers.
K
It's
only
measuring
on
forwarding
paths
all
right,
and
that
was
the
presentation.
If
you
are
interested,
read
the
draft
and
support
adaption.
I
don't
know
whether
this
should
be
discussed
here.
I
don't
know
how
big
the
segment
routing
mpls
segment,
routing
know.
How
of
this
work
group
is
here,
so
I
didn't
try
to
present
it
in
segment
routing.
Yet
if
there
is
a
sentiment
that
I
should
do
so,
please
let
me
know:
thanks
are
there
any
questions.
K
I'm
not
sure
if
it
changes
the
forwarding
pattern
and
you
measure
different
times,
then
you
will
notice
that
if
you
are
looking
at
the
situation
of
a
bundle,
then
it
might
go
unnoticed.
I
agree,
but
then
that
depends
on
what
you
want
to
measure.
I
had
a
conversation
with
someone
else
who
tried
to
suggest
it
to
monitor
end-to-end
paths
and
then
that's
something
completely
different.
K
A
A
All
right
yeah,
so
we're
not
hearing
from
you
jose,
ignacio.
If
you
want
to
unmute,
please
do
otherwise.
I
think
you
don't
have
any
other
people
in
queue
yeah,
so
we
haven't
gotten
a
lot
of
feedback
on
the
list
on
this
one.
Thank
you
al
for
sending
your
comments
and
greg.
If
you'd
like
to
kind
of
reply
on
the
list,
that
would
be
great
as
well.
A
K
L
L
L
L
L
L
L
L
L
Since
still
one
version
of
this
draft,
the
defined
tv
sub
tvs
are
reclassified
and
we
adjust
the
relevant
tov
sub
tv
definition.
Accurate
test
and
echo
replied.
Tuvs
are
divided
into
two
separate
sections
list
of
sub-tuvs
is
removed
from
the
echo
request.
Tov
tracing
capabilities
sub-tuv
is
divided
into
pre-allocated
tracing
capabilities,
subtle,
v
and
incremental
tracing
capabilities
sub
to
v.
L
L
L
L
L
F
F
F
Okay,
so
it's
there's
not
an
amplification
problem.
Wonderful
have
you
considered,
possibly
if,
if
the
is
it
is,
is
the
desire
here
to
figure
out
what
is
like
the
actual
common
set
of
capabilities,
that
the
entire
path
is
able
to
support?
And
if
so,
could
you
not
like
have
a
essentially
like
a
list
of
capabilities
that
is
travels
through
the
through
the
path
and
filters
out
the
the
capabilities
that
are
not
common?
It's
like,
for
instance,
hop
one
would
say.
F
Oh,
I
can
do
ten
different
things
and
the
hop
two
says
I
do
eight
of
those
and
so
then
eliminates
two
of
the
fields
and
so
on.
Until
you
end
up
with
you
know
the
five
common
things
that
the
entire
path
uses,
so
you
could
do
it
all
on
one
message
instead
of
a
bunch
or
is
that
not
what
you're
trying
to
achieve.
F
B
C
B
L
L
C
M
L
A
D
O
O
Thanks
all
for
your
comments,
we
have
evolved
several
versions
to
align
with
the
latest
iom
data
draft
and
the
iom
directory
support
draft,
and
the
latest
version
corrected
the
admin
type
scenes,
as
suggested
by
tom,
including
the
reference
copyright
tree
diagram
and
the
correct
reference
of
the
proof
of
transit
and
so
on
and
after
we
submit
submitted
this
slide.
We
received
two
more
detailed
comments
from
the
roof
and
the
russian
not
updated
this
slide,
but
I
will
discuss
this
later
next
slide.
O
The
model
structure
is
like
this:
the
model
is
organized
as
a
list
of
profiles,
as
suggested
by
the
working
group.
Each
profile
container
is
enabled
by
by
the
corresponding
features,
so
the
device
do
not
need
to
support
all
the
features
each
profile
associates
with
one
flow
and
the
corresponding
iom
information.
O
O
O
O
O
The
i1
proof
of
transit
data
is
to
support
the
pass
or
service
function
chain
verification
use
cases
it's
imported
from
the
draft
in
sfc
working
group.
Richard
made.
This
latest
comments
made
the
latest
comments
on
this,
so
one
discussion
is
whether
we
should
incorporate
the
parts
directly
in
this
i1
model
or
still
like
this.
We
import
it
from
the
sfc
and
in
comments.
O
A
Thank
you.
It
looks
at
this
point
that
there
isn't
anyone
in
the
queue
someone
speaks
up
now
and
we
did
get
a
lot
of
good
feedback
on
the
list.
So
thank
you
for
everyone
who
did
respond
there,
all
right
so
yeah.
Thank
you
for
your
presentation
and
we'll
get
back
on
the
list
about
the
status
for
adoption.
O
A
N
E
E
Then
we
have
a
direct
export
which
combines
the
proposal
that
postcard
based
elementary.
I
there
is
a
postcard
based
telemetry
m,
which
uses
as
a
trigger
method
of
packet
marking,
for
example,
as
the
described
in
rfc
8321,
so
in
direct
export
or
marking.
So
the
difference
only
in
what
triggers
the
information.
E
E
Please
so
this
is
outlines
their
proposed
format,
a
follow-up
packet,
the
transport
network
encapsulation,
which
is
should
be
identical
to
the
one
that
used
for
a
layer,
specific
trigger
packet
and
then
information
that
is
required
for
identification
of
the
flow.
The
sequence
number,
it's
a
sequence
number
in
a
queue
of
follow-up
objects
that
are
triggered
by
the
same
data
packet
and
then
telemetry
information
organized
as
a
tovs.
E
So
here
it's
in
the
illustration
how
their
method
of
collecting
transporting
their
telemetry
information
works.
We
have
a
flow
of
data
packets.
Then
there
is
a
trigger
packet
which
produces
the
follow-up
packet
and
follow-up
packet.
The
original
for
packet
may
be
filled
with
their
telemetry
information.
E
Then
their
transit
note
in
this
diagram.
It's
a
node
c
can
generate
another
additional
follow-up
packet
and
then
they
will
arrive
at
the
egress
node,
which
will
remove
them
from
the
network,
because
it's
a
destination
of
the
data
packet
and
then
the
information
can
be
analyzed
or
sent
for
the
processing.
The
advantage
of
it
is
that
it's
easy
to
correlate,
because
all
the
information
like.
E
E
E
J
E
A
G
G
G
Okay,
there
are
some
implementations
that
are
already
made
and
demonstrated
in
the
acaton,
for
example,
during
the
quick
measurement
project
and
the
implementation
are
actually
our
free
telecom
italia.
Implementation
is
on
android
mobile
phones.
The
probe
is
inside
the
mobile
phones,
so
the
idea
is
to
put
the
pro,
not
in
the
network,
but
also
in
the
devices
and
end
user
devices.
There
is
some
implementation
on
core
network
probes
and
the
orange
jakama
implementation,
the
first
one
already
in
field
by
two
years,
the
akamai
production,
cdns
and
core
network
props.
That's
right.
G
I
recap
shortly
the
round:
try
trip
time
spin
bit
that
is
used
to
mark
the
packet
in
a
client
server
protocol
to
measure
the
round
trip
time.
So
the
idea
is
to
create
a
square
wave
signal
that
bunches
between
client
and
server,
and
the
length
of
the
signal
is
equal
to
rtt
time
round
trip
time
next
slide.
G
G
So
an
observer
put
on
the
path
can
measure
the
distance
between
two
delay
sample
two
double
market
packets,
and
so
the
measurement
is
more
precise
because
there
isn't
ambiguity
caused
from
packet
loss,
because
if
the
packet
is
not
detected
in
size,
the
spin
bit
period
that
the
measurement
is
not
done
and
the
delay
beat
detects
a
specific
packet.
So
there
isn't
a
possibility
that
you
can
measure
different
packets
on
the
edges
of
the
periods
next
slide.
G
Okay,
this
is
about
the
one
it's
different
before
the
previous
one,
because
this
is
one
direction.
One
way:
packet
loss,
the
traditional
packet
loss,
because,
because
the
round
three
packet
loss
is
a
new
kind
of
measurement
in
which
we
can
detect
where
the
packet
loss
occurred,
but
in
this
case
measuring
the
one-way
packet
loss,
we
can
measure
the
direction
where
the
packet
loss
occurs.
G
G
In
this
case
the
measurements
happens
between
the
end
point
and
the
measurement
point
in
is
this
quite
different,
because
the
previous
techniques
about
country,
plus
or
round
trip
time
in
this
case
the
measurement
is
not
a
end-to-end
measurement
but
is
between
the
client
and
the
server
in
one
direction
or
the
servant
or
serving
the
other
direction.
So
we
can
measure
the
loss
between
the
endpoint
and
the
observer
next
slide.
G
G
G
G
Every
packet
loss
event
detect
inside
the
protocol,
so
is
only
a
one,
is
a
end-to-end
measurement.
You
know,
server
measure
in
every
point
is,
is
put.
It
always
observe
the
end-to-end
measurement
on
this
direction
on
this
path
so
complement.
The
next
slide.
Complement
is
this
kind
of
measurement
with
the
previous
one,
the
cubit
we
can
have.
We
can
split
them
the
packet
loss
between
the
server
and
the
server
and
between
the
client
and
the
server.
So
we
have
all
the
possibility
to
split
the
measurement
to
locate
the
losses
next
slide.
G
The
alternative
to
l
beat
is
to
use
the
cubit
coupled
with
the
airbeat.
Their
beat
is
a
measurement
that
simply
reflects
the
losses
from
one
side
to
the
other
side,
so
they
could
be
the
mark,
the
packets,
the
64
packets,
for
example,
if
you
find
less
than
64
packet
market
from
the
other
side
of
the
network.
To
the
other
end
point,
this
endpoint
reflects
a
period
that
starts
with
this
number
63,
for
example,
62.
G
If
there
are
this
one
or
two
losses
in
one
side,
so
we
can
measure
on
the
other
side
the
losses
on
the
first
way
and
part
of
the
lawsuit
the
second
way,
so
we
have
in
the
next
slide
next
dice.
Please
the
possibility
to
complement
it
is
to
measurement
to
have
to
split
the
losses
between
the
two
direction
on
one
direction.
For
example,
we
can
subtract
the
qubit
measurement,
the
loss
velocities
direction
to
the
three-quarter
measurement,
seeing
the
reflection
bit.
So
we
can
measure
in
one
direction
the
end-to-end
losses
in
the
opposite
direction.
G
This
using
only
one
direction
server.
This
next
slide.
If
we
add
two
of
two
direction
server,
we
can
split
the
measurement
in
two
parts:
around
three
pluses
right
around
three
plus
is
left
or
the
the
single
losses
between
the
server
and
the
client
and
between
the
client,
the
server
and
the
server.
Okay.
Next
slide.
G
G
Using
three
bit,
we
have
three
possibilities
to
measure
the
precise
rtt
using
two
beat
and
round
three
packet
loss
using
one
bit
or
using
only
one
bit
for
a
spin
beat
for
delay
at
two
beats
for
the
packet
loss.
One
way
using
the
two
alternative
possibility
could
beat
and
that'll
beat
ocubit
and
their
beat
okay
next
slide.
G
So
these
metrics
are
deeply
discussed
on
the
working
group
inside
the
mailing
list.
We
demos
this
technique
inside
the
and
we
joined
the
two
previous
drafts
that
are
about
the
packet
loss
and
we
joined
in
one
draft.
That
is
this
one
comparing
lost
bit
and
the
reflection
bit.
There
are
the
two
alternative
using
jointly
with
the
equipment.
G
A
A
All
right
looks
like
we
have
a
empty
queue,
so
yeah
yeah
again.
Thank
you
for
doing
this.
Thank
you
for
doing
the
work
to
emerge,
the
documents
and
proposals,
and
I
think
this
is
one
that
we
would
like
to
consider
for
adoption,
great
and
so
for
people
watching
the
clock.
We
are
pretty
much
at
the
end
of
our
time
and
we've
gone
through
all
of
the
documents
that
we
wanted
to
kind
of
have
full
slots
available
to.