►
From YouTube: IETF100-IPPM-20171113-0930
Description
IPPM meeting session at IETF100
2017/11/13 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
This
is
Prague,
as
you
can
see
the
you
know,
it's
really
it's
a
meeting
room
and
the
same
windowless
thing
in
the
basement
anyway
yeah.
So
this
is
clearly
IETF,
100
and
Singapore,
and
today
is
Monday.
The
13th
November
2017
Phil,
couldn't
make
it
here
so
I'll
be
running
the
meeting.
This
is
a
ATF
working
group
meeting,
IETF
IP
our
rules
apply.
This
is
the
note.
Well
if
this
is
your
first
IETF
meeting-
and
this
is
your
first
session
of
your
first
I-
usually
do
these
on
like
on
Friday.
A
So
it's
like
it's
all
yours
I
know.
Well,
if
you
haven't
seen
it
by
now
than
it
yeah,
so
it's
actually
entirely
possible
that
you
haven't
seen
the
note
well
by
now.
So
if
you
haven't
I'm,
actually
just
gonna
keep
talking
louder
until
everybody
gets
quiet
enough.
That
people
can
hear
so
I
mean
I
am
amplified.
I
nice
thing
about
having
the
mic
up
front
is
I
can
actually
get
louder
and
louder.
If
you
do
want
to
have
side
conversations
there
are
hallways
can
take
it
outside.
Please
thank
you.
A
So
this
is
a
important
group
meeting.
This
is
the
note.
Well,
these
VIP
rolls,
if
you
have
not
seen
this,
these
are
kind
of
important.
Please
go,
have
a
look
at
RFC,
53,
78,
RFC,
81,
79,
so
working
group
status
since
Prague,
hey,
we've
reach
our
turd.
Welcome
to
all
the
I
am
IO
am
folks
in
the
room.
We
are
happy
that
you
have
a
home
with
us
here.
We
published
8250
and
we've
got
three
drafts
that
are
basically
ready
to
go.
A
Is
that
editor
comments,
unsurprising
and
we
have
one
in
I,
used
a
evaluation,
the
alt
mark
graph,
that's
I,
think
that's
on
the
telus
at
after
this
meeting
there
was
a
one
comment
and
then
an
officer
review
that
came
in
bit
delayed
that
after
the
idea
of
100-
and
we
have
2905,
which
is
in
need
right,
upstate,
and
then
it
goes.
The.
B
C
A
That's
not
working
okay
right,
it's
a
Mac!
It's
not
focused
follows
mouse.
Here's
today's
agenda,
we've
got
three
working
group
documents:
twenty
to
thirty
ipv6,
the
the
update,
modernization
event.
We've
got
the
two
registry
drafts
which
we'll
be
talking
about
together
and
then
we've
got
IOM
data
Frank.
You
said
you
needed
five
minutes,
but
I'm
giving
you
15
because
it
seems
like
we
might
actually
want
to
discuss
a
couple
of
things
there
yeah.
A
Then
we
have
individual
contributions,
so
the
IP
PM
advanced
routing,
Gregg's
two
drafts
on
stamp,
and
then
this
is
the
port
key
lamp
test
update
where
we're
also
going
to
be
talking
about
to
amp
yang,
correct.
That's.
B
B
A
A
Cool
then
we
have
a
relatively
long
lightning
talk
queue,
but
it
looks
like
yes
since
we're
starting
on
time
here,
we'll
probably
get
to
all
of
these
Onis.
He
tells
name
there.
So
thank
you
very
much
Tala
for
taking
minutes
if
we
have
one
remote.
So
if
we
get
somebody
who's
already
on
Jabbar
Jabbar,
scribe
in
case
of
the
me
deco
doesn't
work
there.
Anybody
our
neon
driver,
probably
not
you'd
otherwise,
you'd
show
up
in
the
thing
there
re
both
will
assume
that
me
deco
works.
Then.
C
Okay,
so
I'm
going
to
be
presenting
the
ipv6
update
two
two:
three
three
zero.
So
this
was
this
next,
since
this
was
necessary
rate
by
it
comments
by
Fred
and
what
it
defines
and
rank
of
intent.
What
it
defines
his
standard
form
packets.
What
should
be
like
a
valid
measurement
packet
and
the
results
are
depending
on
what
kind
of
packet
a
measurement
type
packet
do
you
have,
so
we
call
it
abstract
packet
of
type
P.
C
So
this
I'm
going
through
the
initial
sites
quickly,
because
this
hasn't
presented
in
the
working
group
for
quite
some
time
quite
some
time
before
so
ipv6
ipv6-
is
currently
out
of
out
of
scope
for
RFC
two-30
IP
VM
framework.
So
the
idea
was
to
write
a
draft
that
gets
it
into
the
tooth.
83
0
format
and
and
defined
the
same
as
as
I
mentioned
trigger
was
input
by
brand
carpenters
in
know.
Ipv6
coverage,
so
ipv6
support
by
PBM
was
also
sorted
heat
it
up,
and
this
is
that
draft.
C
So
so
the
night
I
ate,
if
99
meeting
there
were
bunch
of
open
topics
handling
of
large
packets
in
ipv6,
which
leads
to
fragmentation.
The
extent
of
coverage
for
six
low
and
ipv6
header
compression
I
think
this
was
suggested
by
a
Spencer,
and
then
there
was
a
discussion
about
the
theoretical
concept
of
a
minimum
standard
form
packet
and
the
way
ipv6
header
treatment
is
done
in
Indian
intermediate,
and
so
those
of
you
who
are
subscribed
to
the
IETF
discussion,
mailing
list
and
I,
think
v6
ops.
C
C
C
So
since
the
last
working
group,
as
in
the
major
change,
was
the
suggestion
of
600
and
6
lope,
and
so
we
were
locum
and
me,
and
the
other
co-authors
actually
went
up
and
looked
at
6
low,
6lowpan
related
routes,
and
we
realized,
especially
the
header
part,
whether
it
is
header
compression
using
slack
or
I.
Think
if
I
remember
I'd
shake
it
actually
debates,
it
has
some.
It
deviates
from
the
ipv6
header
format
quite
a
bit.
Also.
C
There
is
some
amount
of
local
knowledge
that
is
stored
in
the
end
node
to
reconstruct
the
header
information,
and
we
that,
if
you
want
to
address
excellent
6lowpan,
rather
than
do
it
in
this
rough,
we
would
probably
want
to
have
a
separate
draft
that
looks
at
six
learnt
6lowpan,
so
move
it
out,
just
as
we
have
done
five,
maybe
six.
So
that
seems
like
a
better
approach
of
handling
things
rather
than
cramming
everything
into
this
draft,
which
looks
at
ipv6.
C
C
Yeah,
so
this
was
the
other
big
topic,
which
was
the
treatment
of
treatment
of
extension
headers.
So
there
are
two
camps
in
in
six.
One
is
to
allow
extension,
headers
and
letter
middleboxes
touch
it
and
other
ones.
Other
camp
says
you
know
you
should
not
touch
it
at
all
because
it
violates
so
there
are
I
think
as
far
as
I
know,
there
are
implementations
of
both
in
the
field,
so
there
is
no
consensus
honestly
on
this.
C
So
this
is
a
version
2
of
the
rename
draft
this
stuff
has
been
around
for
a
long
time.
It
results
all
the
open
items.
All
of
the
comments
that
were
there
on
the
list
and
the
WG
Elsie
has
started
and
ended
as
well.
The
tract
is
considered
to
be
stable
and
all
of
the
open
requests
have
a
handle.
There
is
no
additional
feedback,
WLC,
so
I
think
I
think
we
are
good
to
go.
So
if
you
have
any
questions,
I
me
and
some
of
the
co-authors
are
either
we'll
be
happy
to
answer
any
questions.
D
C
So
the
other
question
is
whether
six
low
and
6lowpan
does
fall
under
the
purview
of
IB.
I
ppm
that
that
is,
that
is
the
question.
I
would
have
to
you
as
well.
If
it
does,
then
it
would
make
sense
to
extend
this,
and
you
know,
handle
all
of
the
like.
The
header
compression
is
that
one
of
the
biggest
things
that
raised
70.
A
B
It
did
come
al
Morton.
It
did
come
to
Al
Morton's
attention
that
there
were
some
folks
who
were
making
measurements
more
of
the
IO
and
M
milk
on
a
six
low
kind
of
wireless
networks
and
I
think
the
work
that's
being
talked
about
here
is
just
defining
what
is
a
standard
form
packet
for
these
reduced
rate,
etter
sized
compressed
things
right,
and
so
it's,
it's
just
I
think
it's
just
that
additional
work
that
has
been
the
asset.
Okay,.
A
A
A
It
needs
so
it
needs
a
shepherd.
Then
right
I
mean
we're
done.
We
have
no
Shepherd
dot
dot.
Sorry,
let
me
be
more
explicit
about
this
question.
Would
anyone
like
to
Shepherd
this
document
through
the
process
who's?
Not
an
author,
preferably
I?
Sorry
I
saw
one
hand
in
the
back.
Who'd
read
it
start
there
yeah,
so
we're
basically
looking
for
someone
just
to
do
a
quick,
a
quick
write-up
of
sort
of
the
process
in
the
working
group
and
so
that
we
can
send
that
up.
So
that's
bencher
can
read
it
and
say:
okay.
A
A
B
Good
morning
everybody
I'm
al
Morten
and
we've
been
working
on
a
registry
in
the
AI
ppm
working
group
for
a
long
time-
and
this
is
actually
the
this
title
slide
for
the
initial
rent
registry
contents,
which
I'm
working
on
with
those
stately
gentlemen
next
slide,
but
the
the
registry
format
is
in
this
draft
and
and
this
time
around,
almost
all
the
changes
were
in
the
initial
content.
So
when
I
put
up
first,
there's
always
some
implications
for
the
registry
format,
so
we're
just
going
to
take
that
ahead.
Please
go
alright,
very
quick
summary.
B
The
problem
was:
how
do
we
summarize
our
metrics
in
a
very
precise
way,
we
defined
them
very
flexibly
in
AI
ppm.
That
was
the
intent,
but
when
we
want
to
use
these
things
for
very
precise,
comparable
measurements,
sometimes
with
great
implications
like
comparing
service
providers,
for
example,
then
we
really
want
to
nail
down.
What's
exactly
being
done
so
we've
we've
got
a
registry
that
helps
to
do
that.
We
also
provide
unique
IDs
and
detailed
exposition
of
the
methods
and
the
metrics
and
so
forth.
Lots
of
references
next
slide,
please.
B
So
here's
a
quick
summary
again.
This
is
how
the
registry
concept
was
constructed,
we're
up
to
version
13
now
and
so
each
entries
a
row
and
each
row
is
indexed
by
an
ID.
We've
got
control
and
reporting
protocols
using
a
URI
or
the
ID
to
identify
the
metric,
they're
measuring
and
the
next
slide
shows
the
categories
and
column
headings.
Thank
you.
So
here's
how
its
organized
summary,
metric
definition,
methods
of
measurement
output,
an
administrative
info,
those.
E
B
All
the
categories-
and
you
can
see
the
important
stuff
that
sneaks
in
here
now
that
the
IDS
the
names,
the
URIs,
which
include,
which
include
a
name
and
a
URL,
and
then
we
have
the
metric
definition
with
an
explicit
set
of
references,
and
then
we
start
to
talk
about
fixed
parameters.
The
parameters
that
are
absolutely
going
to
be
they
were
completely
flexible
in
the
standards,
but
now
we're
going
to
nail
those
down
to
numeric
values,
typically
for
the
measurements
that
take
place.
The
same
thing
happened
with
the
methods
of
measurement.
B
We've
got
parameters
there
and
so
forth
that
those
are
now
nailed
down
and
then
eventually
we
allow
some
parameters
to
be
flexible.
What
we
call
runtime
parameters,
okay,
so
there's,
then
the
outputs,
every
kind
of
result
of
the
metric
is
going
to
be
nailed
down
and
that's
an
explicit
list
of
things.
Typically
in
the
output,
there
may
be
a
reference
method
for
calculations
there
as
well,
and
the
unit's
a
method
of
calibrating
the
metrics.
B
F
B
Udp
round-trip
delay
and
loss,
so
new
metrics
for
ICMP.
This
was
a
request
from
the
last
meeting.
That's
all
in
section
9,
it's
all
going
to
be
round-trip,
delay
and
round-trip
loss.
Obviously,
we've
got
these
statistics,
the
min
and
the
max
and
the
mean,
but
I
had
to
come
up
with
a
new
sending
discipline.
This
is
like
this
is.
B
Ok,
so
you
can
quickly
see
how
we're
mocking
up
the
most
important
parts
of
the
registry
there
and
they
are
the
names
and
the
URIs
and
description.
You
want
to
be
able
to
read
this
from
the
back,
but
you
can
see
how
the
name
changed
when
we
change
the
sampling
discipline,
it's
now
periodic
instead
of
a
song
next
slide.
B
So
here's
what
happened
with
the
registry
format.
We
we
had
to
update
the
registry.
That's
got
the
elements
for
naming,
so
fortunately
we
already
had
ICMP
and
TCP,
but
we've
added
the
units
of
packets
and
packets
per
second
and
in
the
output
category.
We've
added
count
and
I
already
mentioned,
send
on
receive.
That's
also
going
to
be
a
name
element
for
the
sending
discipline
next
slide,
so
we're
up
to
slide
9
now
for
those
playing
at
home.
So
this
is
a
look
up.
B
But
but
you
know,
we've
we've,
but
you
can
see
where
the
interest
is
because
this
is
where
we've
actually
gotten
some
comments
now.
So
it's
it's
kind
of
cool
next
slide,
so
the
passive
metrics-
and
this
is
where
I
want
to
spend
the
most
time.
That's
why
we're
rushing
ahead
here?
We
now
so
we're
fairly
sure
that
the
registry
accommodates
passive,
pretty
well
just
because
of
the
way
that
the
naming
work
we
had.
We
ended
up
some
with
some
new
name
elements,
of
course,
but
that's
fairly
routine.
B
Every
time
we
look
at
a
new
class
of
metrics,
we
found
you
know
a
couple
of
things
that
had
to
be
added
to
the
naming
element.
So
that's
why
we
made
that
a
separate
sub
register.
It's
working
very
well.
So
here's
the
new
metrics
round-trip
delay
passive
IP
TCP,
the
RFC
that
specifies
the
metric
it's
going
to
be
in
seconds
as
the
units
and
then
there
will
be
separate
ones
for
each
of
these
statistics,
Mean,
Max
and
the
minimum,
and
then
will
us
as
just
a
packet
and
account
of
losses.
B
I
think
that's
the
best
way
to
go
with
this.
So
our
next
slide
Brian,
so
here's
the
game
board
when
you're
measuring
TCP
round-trip
time
we've
taken
the
position
in
this
method
that
you
are
a
sort
of
a
mid
path
observer
and
according
to
Brian's
reference
they're
in
line
data
integrity
signals
for
passive
measurement.
That
means
that
you
have
to
split
the
round-trip
time
measurement
in
half,
so
you
measure
the
reverse
direction
and
the
forward
direction
you'll
end
up
adding
those
together.
So,
fortunately,
we've
got
composition
functions
in
an
IP
PM.
B
We
can
we
referenced
things
there
to
be
able
to
put
these
two
measurements
together
and
to
do
that,
and
you
also
notice
a
little
delay
there
between
the
between
the
sender
receiving
the
first
acknowledgment
and
then
subsequently
pushing
out
the
the
next
packet
to
the
to
the
receiver,
and
that
is
sort
of
a
source
of
error
which
we've
identified
it's
kind
of
the
application
not
sending
immediately.
So
that's
going
to
be
an
additional
time.
That's
viewed
in
the
RT
t
of
reverse
direction.
B
Next
slide,
so
I
sort
of
concluded
that
there's
no
standard,
metric
and
method
in
any
RFC
so
far
for
passive
TCP
measurement.
So
I
looked
at
all
the
references
that
Brian
sent
and
wrote
one,
and
now
that
huge,
not
huge,
but
several
page
long
metric
definition
and
method
of
measurement
with
heuristics
is
in
the
registry
entry.
So
there's
a
lot
to
look
at
there.
B
Let's
see
anything
else.
Yeah
the
the
heuristics
are
really
important
because
it's
you
know
and
passive
you're,
looking
at
things
and
you're
trying
to
make
their
measurement
as
correct
as
possible.
Things
can
go
wrong
like
the
little
delay
thing
I
just
described
and
let's
see
oh
yeah
yeah
one
of
the
choices
I
made
was
that
all
these
statistics
would
apply
to
a
single
TCP
connection.
So
we
looked
for
the
sin,
the
sin
AK
and
the
AK
that
actually
helps
us
to
describe
the
nomenclature.
B
So
in
the
metric
definition,
you've
got
a
host
a
which
is
the
sender
in
the
previous
picture
and
the
host
B,
which
is
the
the
one
that's
generally
the
receiver
and
and
that's
defined
by
who
sends
the
syn,
okay
and
in
a
fin
fin
ACK
pairs
would
terminate
the
connection.
They'd
also
terminate
the
measurement
interval,
assuming
we
see
those
so
next
slide.
Okay,
so
there
are
some
open
issues
here,
and
this
is
worthwhile
quickly
discussing
today.
So
if
you
search
the
draft
for
the
quad
at
you
will
find
them
so
really
still
no
standard
metrics.
B
Nobody
looked
this
up.
While
we
were
going
through
that
slide.
Okay.
Well,
then,
we'll
just
go
with
what
we
got.
So
one
question
is
in
IP
PM,
we've
always
defined
delay.
As
from
the
first
bit
of
the
packet
observed
on
the
wire
to
the
last
bit
of
the
packet
observed
someplace
else
on
the
wire,
and
do
we
want
to
keep
that
convention
here?
I
think
I
mean
I
think
we
could
but
I'm
not
sure
that
passive
really
gives
us
enough
information
to
provide
that
kind
of
timestamp.
So
that's
an
open
question:
no,
no!
Okay!
B
B
Yeah,
so
let's
not
fake
it,
let's
just
say
I
can't
do
that,
yet
all
right
good
enough
and
that's
worthwhile
mentioning
great.
So
so
that's
a
so
that's
a
feedback
for
the
draft.
I
I
kind
of
think
that
the
round-trip
delay
that's
measured
on
the
syn
syn
ack
ack
three-way
handshake
that
that's
a
good
metric
to
separate
out
on
its
own
I
am
suggesting
in
the
method
that
we
measure
it
or
they
didn't
pull
it
out
as
an
output
parameter
or
result.
So
I
think
that
we
should
do
that.
A
Now
hi
Brian
Trammell
speaking
as
an
individual,
so
I
think
it's
a
very,
very,
very
good
idea
to
take
the
syn
syn
ack
ack
out
as
a
separate
metric
for
a
number
of
reasons.
An
unbounded
number
of.
E
A
Unbounded
reason
number
one
is
that
in
a
lot
of
cases,
the
handshake
is
going
to
be
treated
differently
than
other
packets
in
a
flow
right
like
you
may
have
additional
delays
based
on
the
fact
that
a
load
balancer
needs
to
figure
out
how
to
take
a
five
tuple
and
assign
it
to
something
or
State.
That's
getting
ripped
along
the
path
as
you
as
you
send
that
sin,
because
anther
special
yeah.
A
The
second
reason
is
that
this
is
doing
this
metric
definition
for
TCP
lays
the
groundwork
for
doing
different
metric
definitions
for
other
transport
protocols
and,
for
example,
it
is
an
open
issue
in
quick
there'll,
be
a
report
I
think
tomorrow
from
the
RTT
design
team,
which
you
may
have
heard
of
since
you're
on
it.
So
am
I
I.
Have
that
basically
says?
A
E
A
B
It's
my
first
attempt
at
this
so
and
then
Rachel
from
Huawei
I
read
the
draft.
Thank
you
for
your
comments,
Rachel,
and
she
suggested
that
we
also
pull
out
round-trip
delay
forward
and
round-trip
delay,
reverse
as
being
useful,
metrics
as
well.
So
I
think
that's.
That
should
be
fairly
easy
to
do.
No
any.
D
You
know
one
thing:
it's
sort
of
a
Christmas,
you
know,
especially
in
in
hearing
Brian
in
the
handshake
a
lot
of
times.
The
first
end
number
of
packets
of
us.
You
know,
as
we've
talked
about,
are
different,
and
some
of
them
is
of
course
the
TCP
since
intact,
but
then
especially
now
that
with
TLS
you've
got,
you
know
the
first
ants
number
also
so
I
just
is
I
just
wanted
to
throw
that
out,
not
to
confuse
the
issue,
but.
D
J
J
J
B
A
B
B
Looking
for
feedback
on
all
of
this,
you
know
I
mean
people
are
gonna,
have
to
implement
these
and
be
happy
with
it
and
and
and
be
comfortable
that
there's
no
ambiguity
now
when
you're
making
these
measurements
so
review.
Thank
you
next
slide.
Please.
We
still
got
to
sort
out
something
with
DNS
the
the
loss
DNS
loss
metric.
A
A
I
have
a
I
have
a
question
about
the
I.
Actually
haven't
read
the
most
recent
version
of
this
with
respect
to
the
DNS
response
time,
do
you
get
you're,
basically
looking
for
DNS
response
time
for
a
specific
or
are?
Are
you
looking
for
a
DNS
response
time
where
you
get
to
encode
information
in
the
ours
I
think.
A
He
has
ads,
do
DNS,
lookups
and
he's
doing
a
bunch
of
measurement
based
on
that
and
he's
actually
using
the
thing
that
he's
querying
for
to
encode
the
information
right
so
and
because
you
get
to
query
sort
of
like
sub
are
very
sub
games
names.
There
might
be
so
the
question.
So
the
question
is:
what's
the
requirement?
Here's
the
requirement
here
is
that
you
need
to
look
at
response
time
for
a
specific
or
R
right,
like
I
care,
about
www.google.com,
for
example,
or
is
there?
A
Are
you
looking
to
measure
the
response
time
of
the
DNS
infrastructure
where,
for
example,
you'd
want
to
make
sure
that
the
RR
that
you're
querying
isn't
cached
somewhere?
In
which
case
you
would
be
encoding
information
in
the
query
itself?
That's
an
interesting
distinction
to
the
cache,
so
I
think
I.
Think
here
for
this
open
issue.
We
need
to
like
step
back
whole
bit
and
figure
out
what
it
is
exactly
we're
trying
to
measure
we
trying
to
measure
user
experience
for
the
DNS
component
of
some
of
you
know
of
some
larger
transaction.
A
B
A
B
B
B
E
B
Given
that
there's
value
in
both
of
those-
let's,
let's
nail
that
down
for
both
so
that's
another
action
item
for
the
registry,
you're
welcome
all
right.
I'll
just
quickly
mentioned
that
the
traceroute
we've
got
a
route
metric
proposed
you'll,
see
more
about
that
and
many
methods
of
measurement
actually.
But
fortunately
the
draft
is
going
to
really
nail
that
down
fairly
exactly
so
we're
in
much
better
shape
when
we
finally
get
around
to
registering
that
next
slide.
B
A
J
I
do
CPX
oh
yeah.
B
Yeah
that
one
yeah
so
like
I,
said
on
the
list
I
prepared
that
a
long
time
ago
to
prove
that
it
could
be
done.
It's
not
in
the
right
form
and
I.
Think
the
question
I
asked
on
the
list
was:
what
do
we
really
want
to
measure
that
rtcp
XR
provides
I
mean
I
just
chose
the
burst
and
gap
as
something
to
do
because
of
something
I
was
familiar
with,
but
but
if
we
want
to
do
something
else,
there
then
make
that
suggestion
on
the
list.
J
L
G
G
G
Well,
whereas
MSP
is
it
this
one
or
that
one?
So
we
harmonize
that
with
a
reminder,
but
there
weren't
any
real
other
things
that
needed
to
go
get
cleaned
up
from
an
editorial
perspective,
which
brings
me
to
two
discussion:
topics
John
and
Mickey.
Here
come
along
next
slide,
I,
don't
know
which
one
is
first
up:
oh
yeah!
Well,
there
was
one
thing
that
that
Mickey
raised
on
on
github
as
an
issue.
G
We
don't
really
include
data
lines
as
far
as
opaque
stage,
not
a
snapshot
that
needs
to
get
cleaned
up.
There
was
even
a
pull
request
in
there.
We
just
need
to
go
and
hit
OK
right
after
the
meeting,
so
we
could
have
filmed
that.
But
that
usually
confuses
people.
If
you
publish
you
know
to
write
Monday
morning,
so
we
decided
not
to
do
that
and
then
we
go
into
the
media
discussion
around
what
John
ones
next
slide.
E
So
this
is
proposing
adding
NTP
in
addition
to
PTP
and
letting
the
user
choose
one
or
the
other
and
indicating
by
the
bits
which
type
of
timestamp
is
included.
This
has
been
discussed
on
well
sort
of
discuss
a
little,
not
much
on
the
on
the
list
and
previous
github
poll,
but
needs
to
be
updated.
Also,
yes,.
H
E
My
original
proposal
actually
was
to
just
include
one
or
the
other,
and
assuming
that
you
would
that
the
entire
domain
would
all
be
running
the
same
type
of
timestamps.
But
I've
been
told
that
that
is
a
false
assumption
and
that
there
are
some
servers
that
need
to
be
able
to
communicate
with
users
that
are
using
NTP
and
some
or
clients
using
PTP.
And
so
it
would
actually
be
handy
to
be
able
to
have
both
transpiring
at
the
same
time.
And
this
would
allow
the
server
to
figure
out
which
of
their.
H
E
E
H
E
H
H
Know
but
again
the
pro
K.
If
you
will
say
that
we
don't
support
it,
that's
capability,
you
can
do
it
advertisement
in
control,
plane
capability.
You
don't
need
to
do
it
in
attack.
If
you
dare
say:
okay,
I
don't
put
timestamps
period,
don't
look
at
me,
okay
and
that
will
be
control
plane,
but
it's
timestamp
format.
I,
don't
see
the
combination
that
it's
really
needed
because
to
me
it
looks
over
complication.
Just
my
opinion.
E
M
Indication
of
PTP
I
mean
we
need
a
bit
type
to
indicate
that
we
need
to
include
the
timestamp
in
the
in
the
per
packet
control,
but
whether
it
is
PDP
or
NTP,
given
that
IOM
is
going
to
be
defined
for
the
main
I,
don't
think
they'll
have
a
mix
of
PTP
notes
that
would
differently
insert
the
timestamp.
So
it's
more
like
a
control
global
flag
which
doesn't
have
to
go
in
for
packet.
M
E
Reason
I
tried
to
explain
before
is
that
you
might
have
a
node
that
is
running
both
ntp
and
PTP,
so
that
it
can
communicate
on
two
different
timing
domains
at
the
same
time,
and
it
needs
to
be
able
to
accept
a
timestamp
in
either
ntp
format
or
PTP
format,
depending
upon
who
it's
communicating
with.
But.
M
But
would
it
be
responding
to
two
different
iom
domains
at
the
same
time,
yeah,
but
still
right,
given
that
node,
ID
and
other
stuff
that
needs
to
go
in
as
a
control
mechanism
to
the
node?
This
could
also
be
conveyed
on
a
per
iom
domain
when
it
when
the
control
plane
is
setting
it
up,
rather
than
in
a
per
packet
basis.
A
Yeah
all
right
and
I'm
hi
Frank
Ramos
speaking
as
an
individual,
so
the
general,
the
general
requirement
here,
I
strongly
and
wholeheartedly
support,
especially
because
we've
also
done
this
and
you
have,
but
in
all
other
places
where
we've
made
assumptions
about
we're,
only
going
to
use
a
single
kind
of
time
stamp
and
that
bites
us,
and
now
we
do
NTP
MPTP
right.
So
this
is
consistent
with
the
rest
of
the
work
in
the
working
group
and
I
applaud.
It.
A
A
This
seems
dangerous
to
me
in
ways
that
you
may
not
be
looking
at
right.
So
there's
a
there's,
a
well-known
problem
with
trying
to
interpret
time
stamps
in
in
nut
flow
version.
Nine,
because
it
basically
has
a
two
fields
internally
that
it
uses
for
counting
for
the
time
base.
It
uses
the
seconds
and
the
fractional
seconds
and
they
just
don't
export
the
fractional
seconds
right.
So
you
can
end
up
in
a
situation
where
you're,
using
sort
of
like
times
the
reference
other
times,
and
you
just
truncate
the
time
and
now
you
have.
A
You
know
one
second
of
error
that
you
have
to
like
do
heuristics
to
guess
so.
I
can
kind
of
I
can
kind
of
see
where
you
might
want
to
be
in
a
situation
where
you
would
turn
off
bit.
You
have
fit
to
on
and
bit
three
off
or
bit
twelve
on
and
bit,
thirteen
off
the
other
combination
bit
twelve
off
and
bit.
A
Thirteen
on
right,
like
so
NTP
fractional
seconds
and
only
NTP
fractional
seconds
without
a
second
base
seems
really
weird
to
me
seems
a
little
bit
less
weird
to
me
for
PTP,
because
you
know
in
that
case
you
really
are
like
actually
sort
of
like
down
at
the
metal
carrying
about
nanoseconds,
I.
Think
so
Franks
probably
gonna
say
something.
That's
you
know
similar,
but
different.
A
I
think
you
should
probably
take
all
of
this
feedback
and
come
back
with
a
different
either
a
different
design
suggestion
or
a
different
or
a
set
of
design
rationales
as
to
why
this
is
here,
because
there
are
trade-offs
in
this
space
right,
we
can't
do
it
perfectly
and
I'm
not
convinced
that
this
is
the
optimal
point
in
that
trade-off.
Space
Thanks.
G
G
G
The
node
is
capable
of
doing
typically,
whether
it's
using
1588
or
MTP,
but
it's
rarely
seen
or
maybe
there
is
a
use
case-
tell
me
where
the
node
would
either
insert
1588
or
NTP
depending
on
a
particular
use
case.
Are
you
making
things
up
here?
If
that's
not
the
case,
then
we
may
not
need
that
indication,
but
we
can
go
with
two
fields
and
maybe
what
you're
telling
me
is
we're
overly
specific,
even
than
saying
well
it's
seconds
and
nanoseconds.
G
Basically,
Brian's
comment:
I
think
you're
raising
a
really
good
topic
and
a
really
good
discussion,
but
it
needs
more
thought
on
how
we
gonna
go
and
resolve
that,
because
we
don't
want
to
be
imperative
from
what
we're
doing
from
a
formatting
perspective
so
that
we
are
not
going
down
the
slippery
slope
of
having
eventually
to
accommodate
the
world
of
different
formats,
not
only
here,
but
you
can
take
this
over
also
to
interface,
IDs
or
whatever
right.
So
then,
people
say
I
want
this
format
and
not
that
format
and.
H
I
think
that,
basically,
the
suggestion
to
look
at
this
information
being
part
of
configuration
and
control
plane
is
in
a
very
good
direction
and
I
think
that
to
me,
what
it
suggests
is
that,
should
we
look
at
the
control
plane
of
our
IOM
or
and
data
model,
so
again
it
they're
granular.
This
is
not
probably
only
the
question
of
times
temperament.
H
E
H
E
Next
slide,
in
addition
to
wanting
the
oh
right,
so
there's
a
there
meta,
there's
metadata
that's
available
on
the
hop-by-hop
basis
that
we
would
like
to
be
able
to
access
on
just
edge-to-edge.
While
it's
possible,
I
mean,
while
it's
possible,
to
take
all
the
information
from
hop
I
hop
added
up
together
and
come
up
with
a
total
delay.
We
would
prefer
in
many
cases
not
to
have
to
rely
on
every
hop
by
hop
and
instead
just
have
an
end-to-end
measurement
and
so
we're
asking
that
there
be
timestamps
at
the
same
timestamp
information.
P
G
N
G
Let's
fix
this
forever,
so
Frank
runners,
so
what
might
make
sense
if,
if
you
come
up
with
proposed
text
and
sent
that
to
the
list
for
the
two
ones,
so
that
we
well
are
a
little
bit
more
specific
on
how
things
would
would
work
out?
I
do
believe
that
having
additional
attach
options
is
not
a
problem,
it's
relatively
easy
to
do
so,
let's
do
it
all
right,
so
I,
think
of
having
short
and
long
formats
for
sequence
number.
Well,
we
do
this
for
many
other
fields
as
well.
G
N
Q
E
P
Not
that
tall,
so
one
thing
I
noticed
while
coding
things
up
for
the
hackathon
was
that
the
current
definition
of
the
we
have
undefined
bits
in
the
IOM
trace
type,
but
we
do
not
say
anything
about
what
you're
supposed
to
do,
either
on
transmission
or
reception
of
an
undefined
bit
in
the
in
the
IOM
trace
type
and
it's
the
reception
one.
That
is
the
issue
of
concern.
P
If
you
want
to
be
able
to
use
those
bits
in
the
future,
if
you
look
at
the
way
the
encoding
works
anytime,
you
have
a
bit.
You
expect
a
data
field
after
that,
corresponding
to
that
bit
so
ignoring
the
bit
will
not
work
if
you're
not
adding
the
the
info,
but
the
bit
is
set,
then
it
will
not
be
possible
when
you
get
at
the
other
end.
So
we
have
to
do
something
two
obvious
approaches.
One
is
if
an
undefined
bit
is
set.
Don't
add
anything
at
this
hop.
P
P
So,
but
but
the
the
problem
right
now
is:
if,
if
your
implementation
today
implementing
this
version,
the
bid
is
undefined
and
you
ignore
the
bit,
then
you're
not
going
to
add
that
information
into
the
packet.
But
when
you
actually
pull
the
information
out
of
the
packet
every
time
you
see
a
bit,
you
expect
that
the
information
from
any
one
hop
will
include
that
length
of
data
for
that
bit.
P
P
So
let
me
give
a
simple
example:
so
if
you
have
to
you're
implementing
this
version
of
the
spec,
this
makes
it
the
RFC
you
go
out,
you
implement
and
off
you
go
then
in
in
the
trace
bits.
You
may
say:
I
want
note,
ID
and
interface
IDs,
so
every
hop
would
add.
Node
ID
interface,
ID,
note
ID
interface
ID,
when
you
pull
all
that
apart
at
the
end
you're
going
to
assume
that
after
every
two
bits,
it's
another
hot.
So
the
first
two
headers
is
the
last
hop
no.
P
Not
before
that
so
on
now,
if
later
on,
we
define
some
undefined
bit
and
now
the
source
sets
three
bits
to
rhythm
that
were
previously
defined
and
one
that's
new,
a
new
version
of
this
back
then
now
the
the
expectation
when
you
get
to
the
end
is
that
every
node
is
adding
three
fields
and
it
will
go
through
the
first
three
fields
and
assume
that's
the
last
hop
and
three
after
that
is
hot.
Before
that
and
so
on.
If
I
hop
back,
she
only
adds
two
fields.
Then
you
start
mixing
and
matching
well.
G
E
H
Basically,
you
have
some
TLD
effectively,
so
you
can
parse
it
without
really
relying
that
you
have
a
fixed
size
records
on
your
bits.
Another
approach
is
that
okay?
Well,
you
know
it
might
be
not
backward-compatible
and
third
approach
would
be
that
this
information
about
capability
will
be
advertised
in
the
control,
plane
or
data
model,
and
then
somehow
will
correlate
to
the
packets
that
you
receive
so
choose
what
you
like.
R
P
R
P
A
Friend,
Ramon
speaking
as
individual,
this
is
trying
to
con
him.
I've
had
this
discussion
before
in
a
whole
lot
of
different
protocols
and
everyone
does
it
a
little
different
and
some.
A
I
think
that
they
do
it
a
little
different
is
because
they
have
different
requirements
and
some
of
the
reasons
because
it's
like,
oh
hopefully,
we
haven't,
looked
at
what
was
done
before
I.
Don't
I'm,
not
deep
enough
into
how
IOM
works,
to
make
a
coherent
suggestion
here,
but
I'm
gonna
make
one
anyway,
I
think
that,
so,
if
you
want
an
extensibility
system
to
be
used
and
useful,
you
basically
need
to
set
it
up
before
you
start
I
mean
like
at
at
you
know
before
you
start
allocating
code
points
in
this
code
space.
A
Ipv6
extension,
header
types,
there's
the
attempt
to
say
you
know
whether
you
know
you
know
there
must
ignore
a
bit
and
must
for
a
bit
and
so
on
and
so
forth.
It
seems
here
that
the
main
problem
is
a
problem
of
length.
Rate
of
you
must
understand
every
bit
in
order
to
be
able
to
figure
out
what
your
offset
is
when
you're
sending
do.
I
understand
that
correctly,
it's
an
offset
calculation
problem.
P
A
P
A
All
right
yeah,
then
you
either
need
to
define
a
fixed
length
record
per
hop,
and
you
know
each
hop
just
basically
adds
stuff
until
it
runs
out
of
things
to
add
or
out
of
space
or
and
then
like.
Maybe
that's,
you
know,
it's
variable
link,
but
it's
fixed
length
for
a
given
trace
or
you
need
to
basically
have
each
code
point
in
the
space.
Even
the
reserved
ones
define
what
their
length
is
right
now
and
you.
A
A
I
Are
you
so
from
poly
a
tray?
We
wrote
it
dropped?
Maybe
that
might
help
to
solve
this
problem.
So
in
case
one
node
can
note
process
or
add
some
data
to
the
IOM
header.
It
can
use
a
extended
bit
map
to
indicate
validation
of
the
data.
It
can
just
reset
that
bit
to
zero,
to
indicate
this
node
not
had
validated
to
two
to
the
IOM
header.
Then.
I
Obviously
this
will
require
our.
We
know
the
size
of
the
data,
so
maybe
bad
for
be
just
the
you
know
assume
every
re
datatype,
it's
just
as
32-bits.
So
in
that
case
we
just
add
some-
maybe
all
app
data
to
the
to
the
to
note,
but
sets
that
bitmap
beat
to
zero
to
indicate
this
no
cannot
had
any
data
valid
data,
so
this
can
help
to
address
this
issue.
I
think.
F
Kyle
eros
and
vine
just
a
comment
about
the
0xff
at
the
fan
option.
One
problem
with
that
is:
it
does
limit
the
range
of
valid
options
for
all
existing
types
and
all
future
types
by
one,
not
really
a
big
deal,
but
if
there
is
some
type
we
wanted
to
find
in
the
future
and
all
possible
values
inside
that
type
makes
sense,
then
you
might
run
into
issues.
If
is
your
xff
yeah.
P
S
A
So,
thank
you
very
much.
I
have
a
chair
comment
about.
This
is
just
something
I
noticed
on
the
the
github
repository.
There
is
an
emerging
de
facto
sort
of
method
for
doing
the
use
of
github
within
a
working
group
like
we're.
Basically,
the
you
know,
the
repository
gets
moved
over
from
whatever
individual
organization
into
a
working
group
organization
and
also
a
standard
for
the
arrangement
of
those
which
is
you
need
a
contributing
file.
The
points
in
the
note.
Well,
that's
the
big
thing.
A
So
if
anybody
comes
in
and
looks
at
a
github
repository
from
outside
the
IETF,
they
understand
that
contributions
for
this
document
have
are
subject
to
a
ETF
IPR
rules
like
that's
the
big
thing
that
that
we
figured
out
and
I
just
looked
at
this
repo,
and
it
doesn't
do
that,
so
we
should
yeah.
So
we
should
get
that
fixed
and
I.
You
know
with
my
chair
hat
on
I
have,
since
this
work
had
a
long,
independent
life
before
it
came
into
the
working
group.
I.
A
G
Along
the
same
lines,
because
well
you
you
notice
that
we're
starting
the
journey
with
all
the
various
yep
protocol
working
groups
to
go
and
find
a
home
for
where
to
put
the
data
fields.
So
there
will
be
more
of
the
same
yep
and
rather
than
just
continuing
down
the
wrong
path
kind
of
thing.
It's
still
early
enough
to
go
and
switch
parts.
I
will.
G
A
Alright,
so
thank
you
very
much
we're
going
to
I'm
gonna,
alright,
actually,
now
we're
gonna
switch
over
you
and
forth
discussion
now.
B
That's
the
right
place
to
start.
Thank
you:
okay,
I'm
mal,
Morton,
I'm,
working
with
Ruth's
civil
and
Rashad
ramen
and
Mahesh
chef
from
Donnie
and
Custis
Penn
acoustics
is
our
editor
working
on
the
yang
model,
40
WAMP
next
slide.
So
here's
a
summary
of
our
interim
of
progress
and
we
had
a
working
group
last
call
and
there
were
no
comments.
But
there
wasn't
a
call
of
the
consensus
of
the
last
call.
That's
something
action
point
for
you
or
someone
else
and
the
Chairman
seats.
B
B
So
while
we
were
working
on
on
last
call,
we
also
had
a
rear
view
from
our
yang
dr.
Yan
Lindblad,
and
we
cleared
up
a
few
issues
with
him,
and
then
we
had
a
review
by
our
volunteered
document,
Shepard
Nalini
elkins.
So
thank
you
for
taking
that
job
Malini
and
for
volunteering
to
do
a
big
is
if
this
was
a
big,
a
big
step
for
somebody
who
hadn't
really
read.
Tea
went
before
so
much
appreciation
for
jumping
into
the
breach
on
this.
B
Considerately
in
that
she
took
everybody
else's
comments
that
had
been
raised
like
yawns
and
and
others
along
the
way,
greg's
and
and
and
said,
did
you
guys
really
resolve
this?
You
know
show
me
that
show
me
the
way
you
did
this,
and
so
almost
everything
that
was
done
against
this
draft
for
several
years
has
been
checked
and
Nalini
was
finally
satisfied
with
it.
B
B
Yes,
and-
and
it
really
has
a
lot
of
relevance
to
this
draft,
which
Greg
and
I
put
together
during
the
last
meeting
on
the
reassignment
of
UDP
port
for
the
T
web
test
protocol.
So
this
really
covers
both
these
these
drafts.
Although
this
one's
individual,
as
you
will
notice
next
slide,
please
so
Greg
was
seeking
to
align
the
ports
draft,
which
you
just
saw
the
title
supreme
for
with
the
yang
model
and
Greg
proposed
that
we
do.
B
B
So
that's
kind
of
an
issue
where
we
can't
do
this
by
sort
of
retro
actively
and
I'm
and
I
wasn't
getting
a
mandatory
default
from
reading
this
sentence,
which
is
at
the
bottom
of
the
slide,
but
I
realized
that
we
could
probably
clarify
it
and
Greg
agreed
that
we
should
clarify,
and
so
then
the
proposal
to
clarify
it
went
on
the
list
which
is
on
the
the
next
slide.
So
you've
got
the
old
sentence,
therefore,
for
reference,
but
what
I
did
was
to
separate
it
into
three
items,
which
should
be
very
understandable.
B
The
first
sentence
basically
just
requests
the
reassignment
to
I
Anna
and
it
stops
there,
but
now
we
qualify
what
that
new
reassigned
port
means
to
t
when
it's
optional
in
standards
track
Oh,
wham
and
T
win,
and
then
the
last
sentence
provides
the
future
looking
clarifications
that
we
were
hoping
for.
It
may
simplify
some
operations
to
have
a
well
known
port
available
for
test
protocols
and
for
future
specifications
involving
T
web
tests
to
use
this
port
as
a
default
port.
B
Any
comments
on
that
wording
I've
already
heard
from
Greg
on
the
list
that
this
is.
This
is
okay,
I
think
I
mean
to
be
honest,
I
think
I
could
connect
it
better
here,
but
but
I
unless
I'm
really
moved
I.
Think
I'm,
just
gonna
put
this
in
the
draft,
our
draft
and
and
that
will
clarify
the
situation
so
I
think
that's
it
Brian
or
wait.
There's
next
steps
here,
oh
yeah,
so
next
steps
for
the
port
draft.
Assuming
we
can
agree
on
the
wording
in
slide.
Five
then,
which
we
just
did.
B
A
That
seems
reasonable
to
me
so
so
this
is
because
this
is
a
little.
This
is
slightly
esoteric
right,
so
I
I'll
ask
who's,
read
the
draft
and
understands
the
the
issue
here:
port
reassignment,
oh
great,
yeah,
the
port
reassignment
thing:
yeah,
okay,
yeah!
So
that's
like
the
number
of
hands.
We
usually
get
14
stuff
right,
yeah.
A
A
Are
there
other
updates
that
comes
out
of
come
out
of
this
that
have
to
go
back
on
to
the
TMP
engraft?
No,
so
there's
so.
The
I
just
changed
the
status
to
W
consensus
waiting
for
right
up
right,
which
I
should
have
done
a
while
ago
right
because
we
already
have
a
write-up,
so
we're
not
technically
waiting
for
a
write-up.
So
I
can
click
the
button
now
and
send
that
up
to
the
iesg
Ben.
B
T
H
H
H
H
B
A
Anybody,
if
anybody
decides
that
that
you
know
the
particular
yang
implementation
here,
means
that
they
are
no
longer
comfortable
with
having
working
group
consensus
on
this.
Then
please
raise
that
concern
on
the
list.
Otherwise
this
is
the
plan
we'll
go
with
yeah
good,
okay,
cool
thanks.
A
B
Like
my
stuff,
okay,
so
this
is
an
individual
draft
on
the
advanced
unidirectional
route
assessment,
whoa
whoa.
B
Ignacio
and
Al
and
yokum
Fubini
have
all
been
working
on
this.
This
is
our
second
reversion,
so
we're
trying
to
get
this
to
where
the
working
group
likes
it
enough
to
adopt
it
and-
and
carlos
pinero
suggested
this
acronym
by
just
recognize
again,
it
was
already
in
the
title.
Hora
sounds
pretty
good.
I
think
we'll
insert
that
in
a
future
draft
name
if
we're
successful
with
adoption
next
slide,
good,
all
right.
So
here's
the
background
we
developed
a
route
metric
and
we
introduced
it
before
IETF
99.
B
We
got
rid
of
your
guides
comments,
which
became
our
initial
to-do
list.
Seven
items
we've
addressed
pretty
much
all
of
those
now
and
have
some
replies
on
the
list.
So
that's
all
that
sort
of
thing
is
is
in
zero
one,
but
then,
in
the
interim
after
the
meeting
we
got
extensive
comments
from
Carlos
pignataro.
So
thank
you
for
those
when
you,
when
we
get
to
the
to
do's,
you'll,
see
a
lot
of
things
that
are
labeled
CMP.
Those
are
all
addressing
Carlos
comments
as
well,
but
many
of
them
have
have
been
addressed.
B
So
several
remain,
though
some
we're
going
to
discuss
today.
So
there's
actually
going
to
be
some
real
interaction
here,
get
ready
for
it.
That's
what
we're
gonna
do
we're
going
to
talk
about
expanding
the
scope?
That's
a
big
deal
off
less
comments
from
Frank
Bruckner's.
Do
you
remember
reading
this
Frank?
B
And,
of
course,
multipath
means
that
you
can
have
different
sub
paths
along
the
way,
so
that
meant
that
we
had
to
have
something
called
a
root
ensemble
which
I
will
get
to,
but
but
the
most
important
thing
was
that
we
originally
referred
to
this.
These
H
IJ's
as
hosts
and
what
we
quickly
found
in
looking
at
the
methods
of
I/o,
a
and
M,
and
some
other
things
that
are
around
is
that
there's
there's
additional
information
available
at
every
hop
and
I've
got
it
listed
there.
B
It
has
to
include
a
host
identity,
but
it
may
also
include
an
arrival
interface
identification
same
for
departure
arrival
timestamp.
We
were
just
talking
about
formats
for
that
round-trip
delay,
measurements,
which
are
measured
elsewhere,
but
still
can
be
put
into
this
Tuffle
there's
other
things
to
MTU
cue
state.
Lots
of
things
could
be
really
measured
here
that
that
and
different
interrogation
protocols
tend
to
make
these
things
possible.
So
what
we've
done
is
really
to
expand
our
our
representation
of,
what's
being
measured,
to
include
all
this
information
as
a
possibility
and
that's
a
big
step.
B
I
think
that
we've
we've
now
covered
a
lot
of
a
lot
of
new
information,
that's
available
beyond
the
old
traceroute
methods
and
will
be
available
in
the
future.
So
next
slide.
So
the
also
we've
have
we
have
an
update,
which
is
a
foundation
for
all
these
three
components.
So
we've
identified
a
host
identity
as
the
addresses
the
host
reveals
when
communicating
it's
under
normal
and
error
circumstances.
B
B
It's
the
IP
PM
working
group.
It
means
that
our
framework
was
really
strongly
based
on
IP
layer
measurements,
but
there's
so
much
good
synergy
with
the
tools
and
the
additional
information
that
can
come
from
LSP
ping
and
LSB,
traceroute
and
and
some
of
the
other
nicely
constructed
features
that
are
available
now
in
MPLS,
wide
area.
Networking
that
we
could
easily
expand
our
definitions
here,
sort
of
generalize
them
and
include
MPLS
routes
and
in
this
work
so
open
mic.
Now,
Greg.
K
H
B
B
We
simultaneously
write
the
definitions
for
standard
formed
packets
at
the
MPI
layer,
okay,
because
in
order
to
measure
round-trip
delay
and
loss
and
the
other
things
that
that
Ignacio
was
proposing,
we
do
here,
we
kind
of
have
to
include
them
in
our
framework
and
that's
the
way
to
do
it.
I,
don't
think.
H
H
Yeah
and
actually
what
what
would
be
very
helpful
and
valuable
is
recommendation,
because
for
some
other
networks
there
is
a
consideration
whether
include
the
time
stamp
and
what
how
many
times
them.
How
much
of
a
space
for
the
time
stamp
to
include?
Because
I
I
agree
with
you
that,
if
we're
doing
a
unidirectional
time
stamp,
we
don't
need
to
have
more
than
one
time
step
filled.
A
D
B
U
B
D
B
A
So
individually,
I
really
like
this
idea,
because
I
think
that
you
know
basically
it
one
of
the
things
that
we've
so
the
the
IETF
is,
is
basically
structured
in
a
way
that
there's,
like
you,
know,
layer,
three
and
below
and
layer,
three
and
above
and
never
shall
we
meet,
but
the
way
that
networks
are
run
right
now,
like
everything's,
an
overlay
over
and
overlay
in
a
tunnel
over
and
overlay,
and
you
actually
in
order
to
be
able
to
understand
it.
You
need
to
not
quite
have
this
strict
layering
idea
in
how
you
measure
it
so.
A
A
If
I
may,
the
end
goal
of
all
of
this
measurement
is
to
determine
the
quality,
performance
and
reliability
of
Internet
data,
delivery
services
and
applications
running
over
transport
layer
protocols
over
IP.
It's
the
end
goal
right.
We
care
about
what's
going
on
in
the
tunnel
or
over
the
tunnel
or
through
the
substrate,
because
we
care
about
what
happens
to
the
packets
over
it
yeah.
So
it's
it's.
The
work
to
generalize
the
route
metric
seems
to
be
defensible.
The
work
to
on
say,
here's
how
you
apply
it
to
MPLS
and
here's.
O
Lowered
a
bit
first,
which
is
there's
different
styles
of
managing
working
groups.
One
is
the
one
where
you
come
up
with
the
work,
the
Charter
and
then
never
change
it
until
it
is
so
obviously
out-of-date
that
no
one
will
come
to
your
working
group
anymore
and
the
other
one
is
to
keep
it
up
to
date,
as
as
things
develop,
I'm.
Actually,
okay,
with
keeping
something
up
today,
there's
new
work
arises,
and
you
know
that
is
at
the
edge
of
the
scope.
You
know
that
that's
actually,
that
seems
like
to
me
responsible
working
group
management
practices.
O
O
It
seems
like
to
me
that
what
matters
is
what
work
needs
to
be
done
and
whether
we
can
assemble
a
community
to
do
it
that
might
be
here
that
might
yeah.
You
know.
I
actually
had
this
question
about
Instituto
a.m.
is
this
going
to
be
so
big
that
it
swamps
everything
else?
The
working
group
is
trying
to
do
I'm,
not
saying
that
it
does
the
chartered
it
the
way
we
did,
but
there
was
my
first
thought,
so
my
thing
is:
this
might
be
the
right
place.
O
This
might
not
right,
be
the
right
place,
I'm,
fine,
with
figuring
out
whether
the
work
needs
to
be
done,
and
then
we
can
figure
out
where
it
needs
to
happen,
because
if
it
needs
to
happen,
that's
you
know.
That's
an
IHG
responsibility
so
make
sure
that
we
do
the
work
that
we
need
to
do
for
the
internet.
So.
A
E
A
It
seems
to
have
worked
is
that
this
work
on
sort
of
the
topology
metrics
is
generalizable
and
it
should
be
built
in
a
generalizable
way,
but
I
would
say
that
for
right
now
we
develop
it
with
an
eye
toward
the
present
framework.
Okay,
with
the
understanding
that
we
don't
want
to
do
anything
that
you
know
we're
understanding.
Now
that
we're
not
just
you
know
it's
just
like
down
to
the
first
IP
header,
and
then
we
don't
care
anymore.
We
might
want
to
care
below
the
first
IP
header.
A
We
know
that
now
we
didn't
know
that
123
30
was
written
right
because
the
internet
wasn't
made
of
tunnels.
Yet
right
where
you
see
mp4
that
so
I
would
say
like
basically
go
go
ahead
with
route
as
you're
doing
it.
Yeah.
T
A
Now
know
that
we
might
need
to
to
extend
23
30
further
after
we
have
the
route
work
done,
but
let's
do
the
route
work,
first,
okay
and
then
generalizable,
but
still
focused
above
IEP
way.
That
would
be
my
suggestion.
So
generalizable.
S
Thank
you
all
for
bringing
this
discussion
to
the
working
group.
You
know
my
main
goal
of
this
discussion
is
like
you
were
saying
before
Bram,
that
this
is
generalizable,
that
we
don't
need
to
reinvent
the
wheel
that,
whatever
we
do,
you
know
serves
as
a
framework
foundation
whatever
you
want
to
call
it.
So
you
know
with
that
in
mind.
I,
like
the
suggestion.
I
would
add.
S
A
A
B
E
A
People
and
they're
over
here-
and
they
don't
talk
to
each
other
point
of
having
this
all
together,
is
so
that
we
can
actually
cross
pollinate
some
of
these
ideas
and
if
it
gets
so
big
that
everybody's
only
focusing
on
their
little
thing,
then
it
doesn't
work.
So
we
do
actually
need
to
figure
this
scope
out
and
I,
not
sure
I
want
to
move
this
over
the
routing
area.
Quite
yet,
why.
A
L
A
B
So
so
we'll
generalize
the
metric
definition.
Currently
the
methods
are
modular
and
sort
of
distinguished
between
the
active
trace,
Rowdy
kind
of
things
and
the
interrogation,
IO
and
M
kind
of
things
and
there's
space
that
we
could
eventually
insert
other
methods
there
which
are
unique
to
their
their
lair.
Let's
say,
and
that's
what
I
just
said
so,
let's
see
so
the
week,
we've
actually
clarified
the
checksum
calculations
thanks
to
Tallis
RFC.
That
was
an
easy
reference
to
make
much
appreciated
and
new
sections
define
it
combine,
combining
different
methods.
That's
really
important.
B
That
was
one
of
Ruettiger
comments.
You
know
if
we,
if
we
do
an
interrogation,
eying
them
on
a
single
domain.
How
do
we
combine
that
with
an
active,
traceroute
sort
of
thing
and
what
we've
identified
there
is.
The
key
is
that
you
have
to
have
overlapping
host
identities.
Then
we
can
put
these
different
collection
results
together
and
then
we've
got
these
discussion
development
areas,
the
interaction
between
host
identity
and
the
be
ability
to
discern
subpaths.
That's
discussed
there
in
some
detail.
The
the
co-authors
discussed
a
temporal
composition
for
route
metrics.
B
We've
we've
got
some
thoughts
about
that
assessment.
At
IP
layer,
this
is
the
important
point
to
your
question.
Nalini
assessment
at
IP
lair
reveals
the
route
ensemble
for
IP
and
higher
actually
because
we're
talking
about
ports
and
other
things
that
are
higher.
So
that's
the
conclusion
there
and
also
this
idea
of
Class
C,
which
was
an
important
notion
in
the
original
framework
packets
treated
equally
it's.
It
would
be
very
useful
to
know
that
to
incorporate
it
as
parameter
in
the
route
metric.
B
A
L
B
Okay,
so
here's
the
to-do
list-
I
won't
go
through
this
in
detail,
but
you
can
see
that
there
was
lots
of
things
here
that
Carlos
suggested
and
we
thank
him
again
for
that
and
also
the
the
one
from
Frank
on
using
the
IO
am
loop
back
bit
and
then,
if
we
do
MPLS
I
guess
we're
not
going
to
do
that,
but
we
might
be
able
to
still
talk
about
TTL
propagate
or
something
like
that.
Nalini.
D
D
B
A
A
B
Next
steps,
please
read
and
review
how
many
people
already
read
it
decent,
showing
plus
the
people
who
aren't
here,
and
we
did
get
a
lots
of
comments
so
we're
we're
kind
of
interested
in
working
group
adoption
of
the
draft
now
that
we
have
a
clearer
view
of
the
scope
really.
This
is
the
metric
side
of
the
work
we
took
up
earlier
this
year.
The
telemetry
data
I,
oh
I,
am
I
mean
this
is
a.
B
This
is
a
tool
that's
going
to
enable
measurement
of
the
route
that
we'd
like
to
put
a
metric
on,
and
this
is
our
traditional
work.
We
started
out
defining
metrics
here
and
the
methods
of
measurement.
Well,
now
we've
got
to
catch
up.
Really
that's
my
appeal:
let's,
let's
have
a
route
metric
available
when
this
IOM
data
becomes
available
and
we
could
create
a
milestone
for
this
as
a
first
step.
That
would
be
great
too
so.
A
So
actually
could
I
see
the
hands
for
who's.
Read
it
again,
can
I
see
the
hands
for
who
hasn't
read
it
yet,
but
after
this
presentation
is
interested
in
reading
it,
okay,
that
looks
alright.
That's
enough
for
me.
I'm
gonna
go
ahead
and
ask
for
a
really
loud
hum,
because
they've
turned
on
the
turbines
to
change
the
air
out
in
here.
A
So
if
you
would
like
to
see
us
adopt
a
milestone
for
unidirectional
route
metrics
and
this
as
the
initial
document
for
that
with
the
title
craft,
IETF,
I
ppm,
I
ppm,
our
I,
like
the
title
so
I'm
going
to
go
ahead
and
put
that
in
the
hum.
Please
hum
now.
A
H
H
Sender,
format
and
reflector
format
that
used
in
the
t1
test,
but
at
the
same
time
there
is
an
experience.
So
we
looked
at
certain
feedback
from
deployments,
especially
t1
plight
and
document
developed
and
broadband
forum.
Tr
390
performance
measurement
between
C
and
IP
edge,
which
suggests
that
default
symmetrical
packets
is
very
much
appreciated
and
useful.
H
H
So
that's
the
idea,
so
the
reflector
format
will
be
somewhat
different.
But
again,
the
idea
is
that
it
will
be
symmetrical,
of
course,
for
the
control
from
the
data
model
that
can
be
changed,
but
otherwise
it's
symmetrical
yeah.
That's
the
sender
and
that's
reflector
now
so
we
can
figure
it
out
within
offers,
our
idea
of
where
we
want
to
take
unauthenticated
mode,
but
then
the
security
comes
and
taking
advantage
of
our
proposal
that
we
discussed
in
Prague
and
now
I'll
present
it
on
reassigning
a
UDP
port,
a
62
for
the
test
protocol.
H
We
propose
that
this
port
will
be
used
as
a
default
port
for
the
stamp
protocol,
and
other
options
will
have
use
of
all
dynamic
range,
so
that
gives
us
compatibility
again
with
the
t1
in
unauthenticated
mode.
At
the
same
time,
there
visioning
of
the
reflector
becomes
much
more
simpler
because
we
can
have
a
default
and
don't
touch
it
unless
we
need
it.
H
The
next
question
is
so
because
introduction
and
definition
of
well
known
port
creates
a
potential
attack
vector
or
somebody
will
be
trying
to
skew
the
measurement
by
intercepting
packets
and
holding
them
hostage
for
a
while,
so
that
measurements
will
go
and
accurate.
How
we
can
do
that.
The
initial
idea
of
QM
test
protocol
to
use
and
negotiate
dynamic
pores
was
very
nice
because
it
prevented
this,
so
the
detecting
of
test
flow,
which
was
much
harder
now
with
the
well-known
port
it
becomes
more
exposed.
H
So
what
we
do
there
is
a
trade-off
and
that
for
us
something
is
the
open
question
that
we
want
to
have.
The
discussion
with
the
working
group
is
so
how
we
can
protect
the
test
data
plane,
the
test
packets
at
the
same
time
providing
accurate
and
meaning
for
measurement,
because
the
problem
with
authentication
and
encryption,
as
already
being
pointed
out
in
5357,
is
such
that
we
want
to
do
timestamp
very
close
to
their
hardware.
At
the
same
time,
we
need
to
do
certain
operation
on
securing
the
packet.
H
There
was
interesting,
very
useful
comment
from
Henrik
who,
after
zero
version
now
joined
us
and
now
is.
The
cover
of
this
proposal
is
to
have
characteristic
of
how
the
timestamp
being
acquired
in
the
packet
so
basically
introduced
sub
registry,
where
we
can
define
the
code
points
that
characterize
whether
it's
a
software-based
timestamp,
whether
it's
a
hardware
close
to
transmit
or
when
it's
Hardware
being
put
on
fly
in
the
transmitter.
H
So
exactly
meaning
interpretation
of
the
components
is
open
for
discussion,
but
this
is
something
that
can
be
discussed.
At
the
same
time,
we
realize
that
that
can
be
information
that
only
communicated
in
the
data
model,
so
there
is
a
trade
off
whether
we
put
it
in
the
packet
or
we
just
expose
it
in
the
data
model
again
something
to
discuss.
H
Yes,
another
thing
is
back
to
the
discussion
of
the
timestamp
format
like
in
tea
womp.
We
already
provision
possibility
of
using
NTP
and
PTP
timestamp
formats
and
it's
in
the
manner
that
actually
the
sender
and
reflector
they
can
use
different
times
than
formats,
but
that
is
communicated
in
a
packet
so
that
the
sender-
because
only
the
sender,
does
a
calculation
of
delay
and
jitter.
So
he
needs
just
to
interpret
both
formats,
and
this
is
a
control
playing
function.
Nothing
to
do
with
the
data
plane
and
that's
why
this
heterogeneous
deployment
in
our
opinion
is
possible.
H
H
So
yes,
the
idea
is
that
in
unless
the
gating
mode
stamp
Center
can
be
compatible
with
the
tea
womp
white
reflector,
and
especially,
we
got
discussion
with
the
offer
of
TR
390
that
it
will
be
good
that
it
is
well
known.
Port
will
be
default
port,
so
that's
t1,
quite
equipment
that
compliant
with
the
TR
390
doesn't
need
to
have
to
be
provisioned
and
works
seamlessly.
H
H
Because
we
have
a
single
point
of
control,
we
can
control
both
configuration
and
operational
state
of
sender
and
reflector,
and
so
data
model
reflects.
What
already
being
said
is
that
symmetrical
size
use
of
UDP
port
862
as
a
default
port?
And
then
we
propose
performance
metrics,
including
percentile,
the
feedback
from
operators.
H
The
percentile
is
very
useful
in
their
operation
and
they
suggested
to
have
it
something
that
the
level
of
percentile
can
be
set,
whether
it
will
be
set
throughout
the
old
metrics
or
for
each
metric
like
percentile
scale
for
one-way
delay
will
be
different
for
percentile
scale
for
packet
loss.
That's
something
to
discuss.
I
we
believe
that
one
scale
percentile
for
all
metrics
is
sufficient,
because
we
provide
option
to
configure
define
three
different
levels
of
person.
H
A
C
A
Understanding
is
that
so
they,
the
the
ceasing
new
development
on
ipv4,
doesn't
mean
don't
secure
stuff
on
ipv4,
but
I
mean
so
then
there's
that
there's
the
real
question
in
the
case,
so
they're
real.
You
have
to
look
at
what
the
what
the
encryption
is
buying.
You
rate,
so
that's
I,
think
that's
where
that
that's
where
this
question
needs
to
happen,
what
are
the
requirements
great
like?
So
what
are
the
requirements?
One
of
the
trade-offs
and
the
trade-offs
are.
Somebody
knows
that
this
is
stamp.
A
H
A
This
is
something
that
would
need
to
be
addressed
in
the
security
consideration
section.
There
have
to
be
an
analysis
done
in
an
eventual
draft,
so
you
just
made
a
a
request:
I'm
trying
to
have
speed
up,
so
we
can
get
through
through
the
Lightning
talks,
I'd
like
to
try
and
give
everybody
some
time
you
made
a
request
for
adoption.
A
I
brought
up
the
list
of
current
drafts
just
to
see
how
much
room
we
have,
because
what
we've
done
in
a
lot
of
cases
is,
you
know,
brought
stuff
on
until
we
have
like
a
certain
amount
of
stuff
and
then
develop
things
in
a
holding
pattern
as
individual
and
then
went
ahead
and
adopted
them
and
brought
them
through
I'm.
Looking
at
where
we
are
with
our
current
drafts,
though
so
we've
got
this
one,
which
is
V
602
that
is
gonna,
go
into
last
call
know
a
tiny
Sheppard
right
up
that
ones.
A
We
have
alt
mark,
which
is
an
ISDN
evaluation.
We
have
model-based
metrics,
which
is
in
the
@q
we
have
to
yang,
which
is
going
to
have
a
0
6
and
is
going
to
be
out.
A
So
we've
got
three
that
are
off
our
list:
we've
we're
bringing
on
t
om
port,
which
will
be
really
quick,
yeah
we're
bringing
on
our
o,
which
will
probably
not
take
as
long
as
model-based
metrics
but
might
and
I
think
we
have
another
slot
here.
So
I'm
gonna
go
ahead
and
do
the
humming
thing
again.
Who
is
so?
This
has
a
this
draft
has
kind
of
a
very
long
history
right,
so
it
started
off
as
he
went
up
late.
Yes,.
A
Effort
to
essentially
standardize
that,
in
a
way
that
is
safe
to
use
and
what's
happened
in
the
in
the
intervening
time,
is
the
the
juggernaut
and
behemoth
that
his
yang
has
now
given
us
a
way
to
put
a
control
plane
on
top
of
this
thing
and
that
that's
sort
of
what's
changed
here
so
who
here
has
read
this
draft
or
is
familiar
with
tea?
Lamplight
I
see
a
show
of
hands.
A
Okay,
it's
the
same
usual
futile
act
of
measurement
protocol
suspects,
so
I'll
go
ahead
and
and
do
the
hum
for
a
I'll
have
to
we'll
have
to
figure
out
how
to
do
okay
so
to
adopt
a
milestone
for
the
definition
of
a
tea
wimp
light
compatible
protocol
controlled
by
yang
called
stamp,
and
this
document
as
the
as
the
milestone
for
that
please
hum
now,.
F
A
Hum
slightly
higher
acoustic
energy
than
the
air
conditioner
for,
if
you
would
not
like
to
adopt
this
document,
please
hum
now
that's
below
the
noise
floor
on
the
conditioner,
but
given
that
it's
a
tea
one
thing
I
think
that's
sufficient
to
take
it
to
the
list.
So
we'll
do
a
call
for
adoption
on
the
last
busy
on
the
list
after
after
this.
So
with
that,
we
are
now
into
the
lightning
round
of
our
meeting
and
we
are
about.
A
We
had
five
minutes
a
buffer
and
we're
ten
minutes
late.
So
I'm
gonna
ask
the
lightning
talk
people
to
be
quick
if
you
can
so
that
we
get
a
chance
for
everybody
who
is
on
this
list
to
go
I'd
really
like
to
of
dollar
chance,
he's
been
over
there
furiously
typing
the
discussions
up
and
I'd
really
like
them
to
get
a
chance
to
say
it
stop.
So
how
are
you
song?
You've
got
three
in
a
row:
yeah.
I
Of
course,
the
proposed
solution
here
is
not
the
only
way
to
solve
this
issues,
but
we
just
hope
this
can
help
the
community
to
be
aware
of
these
issues
and
eventually
come
come
up
with
a
newer
or
even
better
solutions.
Here's
it's
just
a
or
the
best
solution.
We
can
think
of
to
address
this
issues.
I
Okay,
the
first
one
is
about
the
data
type
extension.
Currently,
the
specification
defined
using
a
16-bit,
it's
bitmapped
indicates
different
data
types,
so
it
can
and
most
support
up
to
16
standard
data
types,
but
we
can
see
with
the
new
applications
emerged.
New
use
case
emerged.
We
will
eventually
use
up
all
these
bits.
So
if
we
want
to
continue
to
scale
to
support
more
data
types,
we
and
it
still
uses
this-
a
bitmap
encoding
stay
out
and
we
need
to
find
a
way
to
extend
it.
I
So
here's
a
the
proposal
is
we
just
reserved
the
last
debate
in
this
current
a
bitmap
to
indicate
there's
another
extended
bitmap
follow
the
the
first
header
words.
So,
with
this
a
simple
extension,
we
can
immediately
support
another
up
to
31.
You
did
it
haves.
So
again
we
reserved
the
the
next
bitmap
last
bit
to
indicate
if
it's
one
maybe
indicates
and
another
bit
follow
that.
I
So
with
this
using
this
approach,
we
can
continue
to
extend
the
bitmap
to
support
more
and
more
standard,
did
it
hatched
and
if
we,
the
last
bit,
is
set
to
zero,
which
means
okay,
there's
no
more
bitmaps
follows,
and
after
that
we
are
see
the
actual
note
data.
So
this
is
the
first
next
next
slide,
so
there
are
several
use
cases
we
already
find.
In
some
example,
there
are
some
meter
box
in
the
network
which
will
change
the
flow
packed
header.
You
want
you.
I
If
we
want
to
keep
tracking
the
the
flow
identification,
we
need
to
have
a
way
to
actually
save
some
of
the
header
fields
into
the
IOM
data,
so
we
may
need
to
define
new
data
types
in
the
bitmap.
Also,
there
are
different
different
application
scenarios
like
in
the
wireless
mobile
and
optical
networks,
which
may
require
a
different
type
of
data,
such
as
power
temperature
signal
chance,
GPS,
location
and
so
on.
They
may
all
need
their
own
data
types
defined
in
the
bitmap
okay.
I
There
are
also
other
possible
data
types
like
the
metered
flow
band,
waist
time
gap
between
two
consecutive,
a
flow
packets
and
the
buffer
occupancy
of
the
node,
and
so
on.
So
we
can
see.
There
are
plenty
of
use
case
which
may
require
more
data
types,
so
this
first
improvement
might
be
necessary.
Ok,
next
one,
ok,
so
the
second
and
proposal
is
about
how
we
can
limit
the
IOM
data
overhead.
So
we
know
the
IOM
header
can
propose
a
significant
overhead
to
the
packet
itself.
I
If
we
want
collect
more
data
and
per
node
and
also
the
the
past
collecting
past
is
long,
then
the
accumulated
data
made.
It
have
a
big
chunk
of
use,
useful
network
bandwidth,
so
how
to
limit
that?
So
one
way
to
do
that
is,
we
simply
know.
What's
a
maximum
overhead,
we
can
a
support,
then
also,
if
we
know
how
much
data
we
want
to
collect
at
each
node,
then
we
can
calculate
how
many
hops
we
can
accumulate
the
data
and
then,
at
that
point
we
have
to
strip
off
the
IOM
data
and
shipped
it
out.
I
Then
start
from
there.
We
will
refresh
the
IOM
header
and
the
start
to
collects
the
data
from
scratch
and,
of
course,
as
a
collector
and
the
connector
it
can
combine.
You
know
this:
the
IOM
data
data
for
each
segment
and
combine
them
together
to
form
the
to
gather
data
for
the
entire
in
high-pass.
So
the
the
proposal
is
also
very
simple:
we
just
reuse
some
one
pi,
it
helps
up
header
a
header
field
and
we
use
one
bit
in
the
flag
field
to
to
indicate
this
is
a
segment
IOM
right.
I
Then
then,
we
use
for
for
P
to
indicate
the
segment
size
which
actually
just
indicates
a
number
of
hops.
We
can
collect
the
IOM
data
and
this
is
the
remaining
half.
So
the
indicates
okay,
which
part
be
already
in
this
segment,
and
each
hop
is
simply
I.
D
Crimmins.
This
number
by
one,
so
if,
if
the
our
hop
reached
there-
oh
you
know,
we
already
reach
the
segment
boundary,
then
we
need
strip
of
the
IOM
data
and
then
we
reset
this
to
the
to
be
equal
to
the
second
size
and
start
working.
I
So
by
doing
this
we
can,
we
can
know,
what's
a
maximum
size
of
I
ôm
iom
header,
so
next
slice
released
several
use
cases,
so
you
want
extreme
case.
We
can
just
set
the
segment
size
to
one
which
basically
asked
require
that
each
node
to
stand
the
IOM
data
out
immediately.
It
never
puts
a
data
extra
data
in
the
IOM
header,
so
we
can
minimize
the
overhead
also.
It
has
a
side
benefit
if
the
packet
is
happily
dropped
in
the
network.
We
know
exactly
where
it's
dropped
by
just
a
check.
I
Okay,
and
at
which
point
we
stopped
receiving
any
more
IOM
data
for
flow.
Also
there
there
might
be
some
practical
limitations
on
MTU.
So
this
give
us
the
upper
upper
boundary
for
the
practice
size.
So
we
can
based
on
the
what
what
amount
of
data
we
need
to
collect
and
each
node,
then
we
can
calculate
exactly
what's
the
segment
size
is
also
there.
There
might
be
a
very
long
past.
So
if
you
want
to
keep
accumulate
data,
you
want
each
node.
I
You
know
it's
very
ventually
exceeds
the
capability
of
the
each
node,
because
each
node
they
deplane
device
may
use
that
use
a
mean
and
most
that
amount
of
a
header
header
data.
If
it's
a
true
deep,
it
can
not
no
longer
to
process
it.
So
in
that
case
we
have
to
limit
the
size
of
the
IOM
header.
So
we
have
to
use
as
a
sum
idea
like
segment.
Io
am
okay
next
one.
So
here
comes
a
last
one
about
the
OM
iom
data
a
well
at
it
validation
option.
I
Well,
validator
indicator.
The
first
one
is
a
bitmap
is
for
to
indicate
the
note
Verity
to
validate
the
notes,
so
some
some
IOM
capable
knows
they
can
precise
the
IOM
header,
but
for
some
reason,
maybe
is
too
busy
or
for
some
other
reason
it's
just
refused
to
add
the
IOM
data,
so
it
can
simply
set
a
bit
in.
In
this
note,
valid
bitmap
to
indicate
okay,
I
will
not
participate
this
session
and
I
won't
Adam
and
it
ate
her
to
the
to
this
following
data
list.
I
So
another
useful
bitmap
is
applied
for
each
node
in
this
data
list
right
so
so
there
might
be.
The
source
may
require
us
for
different
type
of
datas
data,
but
some
nodes
may
find
it
can
note
support.
This
type
of
data
may
be
due
to
the
you
know.
The
version
difference
or
just
the
sauce
ask
for
some
data.
This
notice
is
incapable
for
providing
that
type
data,
or
it
might
be
also
too
busy
to
handle
that
request.
So,
in
that
case,
it
can
also
set
just
add
a
bit
in
this
in
the
bitmap,
for
example.
I
Here
is
the
result
as
for
this,
this
this
data,
one
two,
three,
four,
five,
six,
seven,
seven
different
type
of
data-
but
here
are
we
have
this
validate
a
bitmap
for
each
each
data
node
to
indicate
okay,
this
data
and
this
data,
or
we
cannot
provide
it.
Then
we
can
only
provide
five
of
them.
So
then,
the
following
data
array.
We
only
provide
five
valid
data,
but
these
two
atoms
are
just
invalid.
We
can
can
be
ignored.
So
by
doing
this
we
can
also
support
different
use
cases.
I
I
So
yeah
I
already
mentioned-
maybe
I
will
not
repeat
it
just
this
is
used
to
handle
the
case
that
some
nodes
just
want
to
refuse
to
serve
some
data
requirement,
or
it
can
even
have
a
ball
fighting
that
kind
of
data.
So,
for
this
use
cases,
this
improvement
is
useful.
So
that's
one,
that's
it!
Thank
you.
U
U
U
U
A
Please
have
a
look
and
if
you,
if
you
see
something
you
like
take
the
list,
if
you
see
something
you
don't
like,
take
it
the
list
and
then
next.
U
U
U
This
is
an
extension
to
Q
AB
test.
First,
the
standard
test
packet
and
you
send
a
text
counter-
is
added
to
this
packet,
and
this
set
said
to
the
number
of
IP
packets
of
the
particular
monitored
flow
transmitted
towards
the
factor.
Thanks
for
the
reflector
test
packet,
three
new
counters
in
it
I
did
so
okay.
Next,
this
is
the
calculation
formulas
for
the
traffic
elastic
calculation,
and
you
can
use
this
formulas
to
calculate
the
fire
in
the
rows
here
and
the
last
fan
the
loss
ratio
and
the
end
row
special.
A
L
Document
changed
from
zero,
zero
ashen
to
zero.
One
version
make
to
true
important
modification,
the
addition
of
a
new
section
about
correlation
with
our
FSC
56:44,
thanks
to
all
Martin
for
comment.
In
particular,
we
need
to
extend
some
definition
of
this
RFC,
because
this
is
limited
to
active
measurement.
L
So
in
this
way
you
can
choose
the
identification
fields
and
the
create
the
filter
criteria
without
any
constraint.
Next,
so
in
general,
for
example,
you
can
imagine
to
have
an
SDN
controller
if
you,
if
you
have
an
SDN
controller
than
can
manage
all
your
network
with
a
marking
method,
you
can
calculate
and
the
network
packet
rows.
That
is
the
difference
between
the
number
of
input,
packets,
Minho's,
number
of
output,
packets.
So,
in
case
of
in
case,
we
have
no
pocket
rows.
Okay,
no
problem,
but
in
case
we
are
part
it
was.
L
L
So
we
can
individual
the
classic.
Why
is
a
useful
identification
of
this
cluster
and
of
these
sub
networks?
Because
if
you
have
your
wall
network-
and
if
you
are
experiment-
some
packet
rows,
you
can
make
a
per
cluster
basis
analysis.
So
in
the
few
I
want
you
have
individual
to
the
cluster.
That
is
experimented
pocket
rows.
You
can
make
a
detailed
analysis
on
only
on
that
cluster
without
so
without
use
a
lot
of
resources
and
so
on.
So
this
give
more.
L
This
part
of
presentation
is
about
the
delay,
so
the
min
delay
works
in
case
of
multi
point.
The
double
marking
delay
doesn't
work
in
how
to
make
multi
point,
but
we
have
found
some
result
in
narrow,
feci,
5474
and
5475
about
using
a
hashing
selection
for
simple
pockets,
and
these
make
this
a
methodology
that
caplet
with
the
marking
methodology
very
powerful.
Next,
in
fact,
they
are
FSC
5475
of
the
same
weakness
that
can
be
solved
by
the
coupling
with
marking
method
methodology.
L
First
weakness
is
that
we
have
a
difficult
implementation
of
the
ashing
selection
in
a
continuous
packet
flow,
but
the
marking
method
can
anchor
the
same
pulse
width
in
a
marking
period,
and
this
is
very
useful,
in
particular
for
the
correlation
aspect.
The
second
problem
that
is
solved
by
marking
method
is
the
possibility
to
have
a
dynamic
cache
so
to
change
within
a
marking
batches
the
number
of
ash
bits
in
order
to
make
sure
and
to
guarantee
that
number
of
samples
are
almost
constant
within
a
marking
field.
L
E
N
T
T
Okay
thanks.
So
what
we're
trying
to
do
here
is
to
measure
the
performance
between
two
measurement
points:
MP,
1
and
MP
2.
Next,
please
and
alternate
marking
in
general,
is
a
method
which
uses
a
marking
field
in
the
header.
This
field
is
used
for
coloring
the
packets
between
the
two
MP
measurement
points
and
it
splits
the
traffic
into
consecutive
blocks
of
data
X
please.
T
So
the
scope
of
this
draft
is
to
define
a
set
of
compact
alternate
marking
methods,
which
means
we
use
just
one
bit
or
data
packet
or
0
bits
per
data
packet.
Next,
please
so
one
existing
alternate
marking
method,
which
is
used,
which
is
worth
mentioning
in
this
context.
Next,
please
is
the
double
marking
method.
The
idea
is
that
in
every
data
packet
we
use
two
bits.
One
bit
is
used
as
a
color
indication.
The
other
is
used
as
a
timestamp
indication.
T
Next
next,
please,
okay!
So
in
this
draft
one
of
the
methods
we
define,
which
uses
just
a
single
bit
per
packet,
is
it
called
multiplexed
marking.
The
idea
is
that,
instead
of
using
the
two
bits
from
the
double
marking
method,
we
multiplex
these
two
bits
we
use
the
rusev
or
between
them
and
that
allows
the
same
level
of
accuracy
as
the
double
marking
method
we
with
just
one
bit
per
data
packet.
Next,
please,
another
possible
compact,
alternate
marking
method
is
called
pulse
marking.
T
The
idea
is
that
in
each
time
period
we
have
just
one
packet
which
uses
a
different
marking
value
and
that
one
packet
per
period
is
used
as
a
reference
for
the
measurement,
both
lost
and
delay
measurement
in
that
period.
Next,
please,
the
draft
also
defines
methods
with
zero
marking
and
the
idea
is
to
use
hash
based
selection.
T
Okay.
So
the
draft
also
includes
a
summary
of
all
the
existing
alternate
marking
methods
and
the
new
methods
which
are
presented
in
this
draft.
It
also
presents
kind
of
a
comparison
and
a
trade-off
between
them.
Next,
please
so
one
thing
that
may
come
to
mind
is
okay,
another
internet
draft,
which
presents
things
that
will
never
get
implemented.
So
this
is
not
the
case
here.
T
T
So
please
do
not
read
this
draft
if
you're
not
interested
in
performance
measurement.
However,
if
you
are
interested
in
performance
measurement,
you
should
definitely
read
this
draft.
You
should
definitely
have
an
opinion
about
it
and
we
want
to
hear
that
opinion
on
the
mailing
list.
Thank
you.
Thank
you
very
much.
A
Wow
we
have
two
minutes
left,
it's
not
enough
for
any
other
business.
So
thank
you
very
much
everyone.
This
was
I
think
this
is
a
really
good
meeting.
I've
got
a
bunch
of
to-do
items
which
roll
at
some
point
later
in
the
week
once
once
my
queue
drains
a
bit
will
lead
to
a
flurry
of
emails
to
the
mailing
list.
A
So
there's
some
Shepherd
write-ups
to
do.
We've
got
one.
Two
three
working
group
calls
for
adoption
coming
out
and
yeah.
So
with
that
I
will
see
you
all
in.
Where
are
we
next
frog?
Yeah,
okay,
London?
Yes,
okay,
so
I'll
see
you
all
in
London
have
a
great
rest
of
your
year
and
a
great
rest
of
your
week.
Thanks
a
lot.