►
From YouTube: IETF 112 Internet Architecture Board (IAB) Open Meeting
Description
The Internet Architecture Board (IAB) will hold an open meeting on 11 November 2021 at 14:30 UTC. This session will provide an opportunity for more direct interaction and technical discussion between the community and the IAB.
A
So,
let's
do
that.
A
A
Yeah,
let
me
show
the
note
well
probably
have
seen
this
by
by
now
already,
even
so,
this
is
an
ib
meeting.
It's
still
a
contribution
to
the
ietf,
so
you
should
be
aware
of
the
ipr
rules
and
all
other
participation
rules,
especially
please
notice,
our
code
of
conduct
and
the
entertainment
procedures,
which
are
also
linked
here
on
the
slide.
A
I
don't
think
we
had
problems
in
this
meeting,
but
it's
generally
important
to
be
friendly
to
each
other
to
respect
each
other,
to
provide
constructive
feedback
to
be
welcoming
newcomers.
So
in
that
sense,
hopefully
we
can
provide
some
good
contributions
in
this
meeting
as
well.
So
please
keep
that
in
mind
also,
not
only
when
you
speak
up,
but
also
everywhere
and
also
in
the
chat.
A
A
Yes,
so
we
have
always
have
this
like
what
is
ib
open,
because
it's
kind
of
still
relatively
new,
but
it's
not
that
new
anymore
more.
We
do
it
for
nearly
two
years
now.
So
this
is
really
an
organized
session
by
the
iav
to
focus
on
some
technical
and
architectural
topics
and
discussions
and
for
two
purposes.
One
is
to
increase
the
visibility
of
what
the
iap
is
doing,
also
to
have
a
forum
to
to
discuss
with
the
community
and
get
feedback
from
the
community.
That's
what
we're
doing
here.
A
I
wanted
to
provide
a
little
bit
more
information
about
how
to
reach
the
iab.
I
usually
have
this
on
the
slides
that
you
can
reach
the
iab
directly
with
an
email
to
iab
iab.org,
and
what
we
noticed
is
that
not
everybody's
aware
that
not
only
iab
members
are
listening
to
this
list,
so
we
have
some
people
from
staff
also
on
this
list
in
our
lives
and
these
kind
of
people.
So
we
put
this
information
now
everywhere,
where
you,
you
might
look
for
it
on
the
web
page
and
these
kind
of
things.
A
A
We
have
the
architecture
discuss
list
which
is
really
an
open
list
for
community
edition,
and
that's
where
all
the
discussion
about
architectural
and
technical
topics
happen
and
also
related
to
ib
documents
so
feel
to
subscribe
there
and
free
to
post
there
and
start
a
discussion.
We
have
just
made
an
open
mailing
list
for
prims,
where
the
community
can
also
subscribe
and
engage
in
a
topic
that
leads
to
the
program.
You
can
propose
topics
that
are
related
to
program
scope
and
we
have
this
there's
no
coordination
and
mailing.
It's
not.
A
It's
just
an
alias,
basically,
which
is
relatively
new,
so
this
is
a
direct
way
if
you
have
any
questions
about
liaisons,
to
reach
somebody
or
to
reach
the
right
person
from
the
iab
about
that.
A
Okay,
so
as
we're
talking
about
the
technical
work,
the
iap's
doing
here,
so
we
will
give
you
a
quick
update,
a
very
domain's
workshop
programs
so
on,
and
then
we
have
some
presentations
so
updates.
We
actually
have
done
quite
a
bit
of
work
like
we
have
published
new
document
which
is
rcm
9120,
so
that
was
some
work
about
cleanups
for
up,
but
basically
not
too
exciting.
But
it's
a
new
document.
A
We
have
one
document
which
is
just.
I
would
send
out
for
no
one
document
which
is
already
approved
by
iab
for
publication
and
will
come
out
as
an
rfc
very
soon
and
we
have
still
one
document
that
is
under
discussion
in
the
ib.
So
it's
already
adopted
as
my
document
and
we
are
working
on
it
and
you
will
hopefully
see
some
progress
on
that
soon.
A
We
have
a
brand
new
shop
report
out
there,
which
was
submitted
just
this
week
on
the
last
workshop
that
we
organized
and
west
we'll
talk
about
that,
and
we
are
running
a
call
for
community
feedback
about
a
new
document
that
we
would
like
to
adopt
in
the
iab
and
start
working
on.
So,
that's
probably
the
most
important
part
if
you,
if
you
want
to
provide
feedback
on
this
document,
please
send
it
directly
to
us
or
go
to
the
architecture,
to
discuss
this.
That's
where
most
of
the
discussion
is
happening.
A
I
just
got
a
note
that
my
audio
and
video
is
a
little
bit
shoppy.
Is
that
true
for
everybody,
because
then
I
turn
off
my
videos.
It's
not.
A
Okay,
maybe
this
is
because
my
partner
is
sitting
in
the
other
room,
also
having
video
calls
as
you
have
it
today.
So
if
you
don't
hear
me,
just
read
the
slides
right,
it's
the
same,
okay,
so
program
updates.
We
have
an
update
later
on
on
the
edm
program,
so
I
will
not
say
much.
We
have
a
second
technical
program
running,
which
is
a
model
t
program.
There
was
an
iab
review.
There
was
a
little
bit
of
silence
recently
and
there
was
just
a
new
discussion.
A
I'm
started
right
now
to
figure
out
how
this
group
could
like
get
rescued
or
continue
some
work.
So
probably
they
were
meeting
on
september,
2nd
that
you
might
want
to
join.
You
can
also
join
the
mailing
list
or
find
further
information
in
the
data
tracker
russ.
Do
you
want
to
add
something
about
the
model
t
program.
B
A
B
No,
no,
I
think
that's
about
right.
We
do
need
to
get
it
moving,
because
it's
interesting
work
and
we
just
need
to
like
figure
out
how
to
push.
A
Yeah
so
watch
out
for
that
meeting
and
subscribe
to
the
list
and
then
one
more
program,
which
is
you
know,
not
the
classical
iab
technical
program.
It's
it's
a
special
case
here
because
it
works
more
like
working
group
like
a
community
program,
but
you
might
or
might
not
be
aware
of
this
program.
It's
the
ioc
future
editor
development
program
and
this
program
is
working
on
a
new
model
for
the
rfc
editor
and
effectively.
A
It
has
concluded
most
of
its
work
and
there
is
one
document,
one
draft
that
is
redefining
this
new
model
and
the
working
group
last
call
the
program
last
call
ended
last
friday,
so
there
are
still
a
few
issues
to
clear
out,
but
nothing
big
anymore.
The
model,
as
it's
described
here
in
the
slide
kind
of
there's,
still
an
opportunity
to
provide
more
feedback.
There
will
be
more
community
calls
before
we
actually
publish
this.
So
please
look
at
the
document.
A
Not
right
now
read
it
provide
feedback
to
the
program
mailing
list
and
you
can
also
probably
join
the
next
end
of
our
meeting.
We
had
a
meeting
yesterday
and
there
were
not
we're
still
a
few
open
issues,
but
so
we
might
need
another
interim,
but
it's
it's
nothing
big
left.
So
this
is
really
coming
to
an
end.
Now.
A
And
then
iab
workshops
so
another
part
of
the
technical
work
we're
doing,
and
so
we
had
a
workshop
on
measuring
internet
called
internet
measuring
network
quality
for
end
users
in
september,
and
that
was
really
quite
well
visited.
We
had
a
huge
amount
of
contributions
and
very
a
lot
of
people
in
the
workshop
I
unfolded
and
joined.
But
wes
will
tell
you
more
about
this
later
and,
as
I
said,
the
report
is
just
out
of
first
version,
the
first
draft
version,
but
you
might
be
able
to
already
find
some
information
there.
A
That's
interesting
for
you
and
then
we
have
another
workshop
that
we
will
organize
end
of
november
and
that
workshop
isn't
analyzing
ietf
data.
So
here
the
idea
really
is
to
look
at
the
data
that
we
provide
the
metadata
drafts
in
the
data
tracker
about,
for
example,
authorship
participation
and
so
on
and
figure
out.
If
we
can
learn
something
from
it.
If
we
can
see
trends
and
what
we
can
analyze
and
effectively,
there's
a
bunch
of
researchers
who
are
already
looking
into
this.
A
So
that's
coming
up
and
we
will
push
the
recordings
afterward
and
I
will
probably
report
back
at
the
next
ietf
meeting
and
with
that
we
go
properly
to
the
next
presentation
except
so,
as
I
said,
there
will
be
a
presentation
from
the
edm
program
and
there
will
be
a
presentation
from
the
last
workshop
and
I
forgot
an
s
here,
so
the
representation,
the
workshop
presentation
is
not
given
by
we,
but
by
with
so
you
know,
if
there's
no
agenda
bashing
or
any
questions
about
what
I
just
showed,
we
can
move
on
with
tommy.
D
All
right,
so
I'm
tommy
pauly
one
of
the
leads
for
the
edm
program.
My
co-lead
david
is
not
here.
He
is
the
one
who
has
the
light
up
suits
that
go
well
with
the
edm
theme.
I
can
only
give
you
this
slide.
I
apologize
anyway.
So
this
is
our
technical
program
on
evolvability,
deployability
and
maintainability.
D
As
a
quick
status
update,
we've
had
two
calls
since
the
last
ietf
meeting
and
the
last
iab
open
one
of
those
was
to
wrap
up
on
draft
ib
user
to
lose
it,
which
was
mainly
authored
by
martin
thompson,
and
then
we
kind
of
completed
it
in
the
working
group
that
is
currently
in
the
rfc
editor
queue
and
should
be
published
soon,
so
really
happy
that
we
can
get
that
moved
along.
I
think
that's
going
to
be
a
very
useful
contribution,
so
now
we're
essentially
moving
on
to
starting
up
some
new
efforts.
D
There's
another
existing
draft
that
we're
looking
at.
But
the
thing
I
want
to
talk
about
today
is
what
we
had
our
last
meeting
on,
which
was
discussing
how
we
track
protocol
implementations
and
deployability
all
right.
So
why
does
this
matter?
Why
are
we
talking
about
this
in
an
ib
program?
Why,
in
this
program
I
mean
overall
running
code
is
how
we
determine
deployability
before
we
ship
our
protocols.
D
So
tracking
the
implementations
is
also
a
way
to
help
implementations
do
interrupt
testing.
We
see
a
lot
of
success
in
working
groups
that
are
able
to
do
a
lot
of
interop
testing
and
that
helps
them
validate
that
their
protocol
is
working
and
will
be
deployable
on
the
internet,
dealing
with
middle
boxes
and
understanding
where
ossification
has
already
happened.
D
Also,
you
know
looking
long-term
towards
the
maintenance
of
protocols,
it's
important
to
understand
how
features
have
been
adopted,
which
ones
are
like
what
extension
points
are
actually
working,
which
ones
are
successful
and
understanding
how
protocols
are
being
used.
Helps
us
get
a
feedback
into
that
loop.
D
D
D
So
some
of
the
ideas
the
draft
puts
forward
is
that
you
could
have
essentially
links
to
your
running
code
or
implementation
status
or
interop
test
matrix
that
you
can
get
too
easily
from
places
like
your
data
tracker
or
from
your
working
group.
Github
or
even
through
the
metadata,
that's
associated
with
drafts
and
rfcs.
D
So
in
order
to
understand
what
would
be
useful
here,
the
first
thing
we've
done
is
send
out
a
survey
to
all
the
working
group
chairs
to
understand,
what's
currently
being
done
so
here's
just
a
little
example
of
some
of
the
stuff
we're
asking
this
was
sent
out.
I
think
a
week
and
a
half
for
two
weeks
ago.
We've
had
some
responses.
D
D
I
think
we
definitely
see
different
trends
in
different
areas
of
the
ietf
and
the
methods
are
inconsistent,
but
almost
all
of
the
working
group
chairs
said
that
they
would
like
to
have
the
information
about
their
implementation
status,
be
more
discoverable
for
people
who
are
coming
into
their
working
groups,
and
most
of
them
also
express
that
they
would
like
to
be
able
to
track
this
implementation
status
in
a
consistent
way
after
rfc
publication,
which
is
something
that
the
current
guidance
around
an
implementation
status.
Section
of
a
draft
does
not
provide.
D
C
Am
I
here?
Yes,
I
am
here
yay.
First,
first
hooray!
Yes,
this
is
great.
Thank
you.
This
is.
This
is
absolutely
brilliant.
C
I
wonder
how
much
the
iesg
has
talked
to
you
about
this
and
whether
this
could
be
folded
into
the
moving
along
the
standards
track
stuff
that
we've
done
a
lousy
job
with,
for
I
can't
remember
how
many
years-
and
this
seems
like
it
would
fold
in
brilliantly
and
if
it
became
sort
of
something
that
working
groups
just
did,
it
would
make
that
whole
question
much
easier.
D
C
So
I
I
mean
ideal
world,
my
my
thought
would
be
you
know.
All
working
groups
would
just
sort
of
do
this
as
a
matter
of
course.
It
would
be
the
thing
you
do
when
you're
working
on
something
you
put
it
into
the
implementation
pipeline.
At
that
point,
you
know
we
used
to
have
this
just
horrible
time,
convincing
people
to
move
things
along
the
standards
track,
which
is
why
we
went
you
know,
got
rid
of
draft
standard.
C
This
to
me
just
and,
and
people
still
are
not
great
about
moving
things
to
full
standard.
If
this
was
just
widespread
people
would,
I
think,
sort
of
fall
into
it
and
say,
oh
sure,
yeah.
If
we've
got
all
the
data
to
show
that
we're
widely
deployed
and-
and
you
know,
implementations
are
interoperable,
they
would
just
do
it
and
we'd
have
a
lot
more
stuff
get
into
standard
yep,
yeah
totally.
C
And
it
would
also
reduce
the
temptation
to
stay
at
proposed
standard
forever
and
have
the
entire
internet
run
on
proposed
standard,
which
kind
of
sort
of
reduces
the
utility
of
calling
things
standards
in
the
first
place.
So
this
all
seems
great
yeah.
D
D
D
A
Thanks
tommy
and
then
we
go
to
wii.
U.
E
I
naturally
closed
the
the
viewer
right
as
the
raise.
I
guess.
A
You
can
use
this
share,
preloaded
slides
button
right
next
to
the
hint
button,
and
that
will
just
give
you
the
slides
from
the
data
tracker.
But
you
have
to
press
it
yourself.
E
See
the
slides
I
assume,
okay,
so
I'm
going
to
talk
about
the
ib
workshop
for
measuring
network
quality
for
end
users,
which
we
just
held.
We
had
three
chairs
for
it,
a
very
large
program
committee
and
as
you'll,
see
in
a
minute
a
large
quantity
of
participation
too,
which
was
awesome.
E
So
a
little
bit
of
background.
You
know
the
world
connectivity
has
gotten
much
much
better.
I
think
you
know
the
the
prevalence
of
increased
bandwidth
everywhere
has
been
fantastic.
We
actually
now
can
do
video
chats.
That
was
not
possible
just
a
few
short
years
ago,
but
you
know
everybody
still
experiences
local
outages
and
issues
that
that
cause
issues
as
myriad.
E
She
had
sort
of
connectivity
issues
earlier
in
this
this
meeting
alone,
and
certainly
we
all
have
those
at
times,
and
you
know,
there's
a
lot
of
inner
application
resource
competition
too.
There's
there
was
video
discussions.
I
think
in
map
rg
this
week
about
what
happens
when
multiple
video
streams
are
trying
to
compete
for
for
competition
and
which
one
wins
and
examining
the
differences
between
different
platforms.
You
know
they're,
not
all
equal,
so
the
goal
was
you
know
what
what?
How
can
we
identify
problem
spaces
in
this
area?
E
What
what
is
a
good
user
experience?
Users
often
don't
know
this
themselves,
and
and
if,
if
users
don't
know,
how
can
we
measure
it
and
then
how
can
we
communicate
these
measurements?
Can
we
do
it
in
a
standardized
way
and
are
there
measurements
that
we
can
do
that
users
can
actually
understand,
or
at
least
be
able
to
report
other
than
some
things
were
not
working?
E
The
this
is
a
graph
from
david
reed
who
attended
the
the
workshop
and
presented
this
slide
and
was
one
of
many
fantastic
presentations
that
shows
the
fcc's
longitudinal
trend,
for
you
know,
load
over
data
cable
over
over
time,
and
you
can
see
that
it's
getting
better,
so
there's
latency
on
the
left-hand
side
and
latency
is
just
generally
decreasing
over
time,
which
is
fantastic,
that's
kind
of
one
of
the
metrics
that
we
want
to
see,
but
still
this
is
from
lucas
pardue
who
who
had
you
know
when
you
start
thinking
about
where
the
problems
are
right.
E
There's
there's
a
huge
number
of
potential
problems,
including
one
of
the
ones
that
was
discussed
a
lot
during
the
workshop
because
it
was
humorous
and
because
it
was
a
good.
A
good
example
of
you
know.
My
mom
was
microwaving
a
potato
and
it
caused.
You
know
the
wi-fi
connection
to
go
bad
and
you
know
you
can
imagine
trying
to
get
those
predicted
by
the
average
end
user
as
to
what
exactly
is
causing
the
problem.
All
they
know
is
something's
not
working.
They
don't
necessarily
know
why.
E
So
we
held
a
workshop
on
this
on
september.
14Th
to
the
16th,
we
hold
it
on
webex
and
we
had
three
days
and
it
was
four
hours
a
day,
and
there
was
an
hour
set
aside.
You
know,
or
plus
there
was
an
hour
afterwards,
where
people
just
hung
out
afterwards
and
and
talked
for
an
additional
hours
beyond
just
the
the
four
hours
a
day.
So
it
was.
It
was
neat
that
we
had
some
side
channel
discussions
and
breakout
rooms
happen
as
well.
E
There
was
90
different
attendees
total
when
I
finally
looked
at
the
logs
and
counted
them
all.
When
we
were
taking
notes,
we
noted
that
there
was
at
least
76
at
one
particular
time,
but
at
least
90
different
people
participated
over
the
course
of
of
the
three
days,
which
is
a
fair
amount
for
a
workshop.
That's
not
a
that's!
E
That's
a
fairly
large
ieb
workshop
and
certainly
if
we
held
it
in
a
physical
in
a
physical
room
that
couldn't
have
happened
so
there's
some
benefit
to
virtual
meetings,
because
you
can
actually
certainly
take
in
a
lot
more
people
every
the
way
that
we
had
structured.
The
workshop
between
the
chairs
and
the
program
community
is,
we
had
three
to
four
five
minute
presentations
with
clarifying
questions
afterwards
and
then
we
allowed
for
a
lot
of
discussion
time
and
that
format
seemed
to
really
work.
Well,
the
discussion
times
were
were
never
blank.
E
We
broke
the
workshop
down
into
details
so
after
reviewing
a
lot
of
the
short
papers
that
were
submitted,
we
realized
that
they
sort
of
broke
into
a
number
of
categories.
So
we
had
introduction
and
background
presentations
about
you
know.
Where
are
we
today
or
you
know?
What's
what's
the
current
status
and
and
how
does
what
metrics
you
know
are
being
used
today,
followed
by
considerations
of
what
metrics
you
know?
E
We
should
actually
be
thinking
about
or
concentrating
on
or
what's
broken
with,
current
ones
and
things
like
that
and
there's
a
lot
of
discussion
around
cross
layer.
In
other
words,
how
do
you
know
multiple
things
interact
and
there's
there's
multiple
aspects
of
of
cross
layer,
which
I
I
think
I
have
a
little
bit
more
detail
on
the
later
slide,
but
consider
wireless
versus
wired
consider
you
know
multiple
layers
of
of
the
osi
stack
and
all
of
these
types
of
things.
E
It's
that's
one
of
the
things
that
makes
it
hard
right
is
you
you
need
to
be
able
to
measure
stuff.
You
know
not
just
at
one
place,
because
that's
not
the
only
place
if
anybody's
ever
studied
ping
or
trace
route,
you
know
they're
very
different
applications
and
even
traceroute,
which
has
a
lot
more
information.
E
Does
not
tell
you
exactly
where
the
problem
is
on
the
path
and
then
finally,
a
synthesis
of
people
that
were
offering
sort
of
bigger
solutions
or
or
more
global
views
was
sort
of
the
concluding
of
the
four
sections,
and
then
we
we
did
offer
a
a
conclusion
discussion
at
the
very
last
hour
which
I'll
go
over
next,
but
so
the
goal
was
to
to
go
from.
You
know
background
to
thinking
through
you
know,
sort
of
solutions
as
the
workshop
progressed.
E
So
we
took
30
minutes
at
the
end
to
allow
people,
and
this
was
sort
of
an
experiment
that
I
I
kind
of
came
up
with
to
allow
people
to
just
make
statements
that
they
thought
everybody
might
agree
with
right.
E
What
were
conclusions
that
kind
of
came
out
of
all
of
the
discussions
over
the
course
of
three
days
that
people
thought
were
were
statements
that
everybody
else
would
stand
up
behind
and
so
24
sentences
were
written
down
and
we
asked
clarifying
questions
about
them
only
as
this
was
going
on,
and
then
we
took
another
30
minutes
to
you
know
where
people
could
actually
say
wait
a
minute.
I
disagree
with
that.
E
One
that
one's
not
under
consensus
after
that
we
actually
only
eliminated
five,
is
really
not
achieving
consensus
consensus
out
of
24,
which
that
ratio
to
me
surprised
me
as,
as
we
know,.
E
We
like
to
debate
everything
right,
but
so
you
know
a
good
percentage
of
them
actually
came
out
is
generally
accepted
and
then
I
later
grouped
them
and
documented
into
the
internet
draft.
So
you
can
go
read
them.
I
edited
them
a
bit
for
context
and
added
more
information.
E
Some
of
them
were
shorter
and
you
know
they
were
really
well
understood
by
people
that
attended
the
group
more
than
anything
else,
so
I'm
going
to
go
over
them
in
general
and
I
group
them
into
a
number
of
different
sections,
and
I
added
bold
words
where
I
think
you
know
you
might
find
the
most
interesting.
You
know
points
coming
around.
One
of
the
nice
things
that
kind
of
came
out
is
a
number
of
short
term
statements
that
that
I
think
describe
the
state
of
of
network
quality.
E
Today,
right
bandwidth
is
necessary,
but
not
alone,
sufficient
one
of
the
things
that
I
think
has
been
pushed
heavily.
I
should
say
the
workshop
really
thought
has
been
pushed
heavily
in
the
past
decade
has
been.
We
just
need
more
speed,
more
speed,
more
speed,
and
that's
that's
not
sufficient,
and
that's
not.
You
know
alone
what
you
need.
E
I
think
gamers
know
that,
well
that
they
need
better
bandwidth
and
better
latency
and
game.
Gaming
was
talked
about
a
lot
because
it's
a
low
latency
desired
application.
So
you
really
need
better
bandwidth
right.
You
need,
you
know
not
just
more
bandwidth,
but
you
need
better
bandwidth.
How
can
we
make
it
better
and
in
order
to
really
figure
out,
if
that's
working,
you
need
both
active
and
passive
measurements?
E
You
know
you
need
to
be
able
to
to
see
a
retrending
right
direction
or,
what's
getting
worse,
I
think
anybody
studying
academic
papers
knows
that
you
know.
Longitudinal
papers
are
often
the
most
interesting
because
they
really
show
trends
over
time,
but
a
meaningful
metric
for
users
is.
Is
this
network
going
to
work
for
me?
Will
my
application
the
thing
that
I
want
to
do?
E
Is
it
going
to
work,
and-
and
this
is
where
we
get
down
to-
how
do
you
measure
stuff
for
end
users
in
a
way
that
they
will
understand,
and
you
know
quite
frequently
it's
does
my
application
work
or
is
my
network
insufficient?
Do
I
you
know,
do
I
have
the
right
sufficient
characteristics
in
a
network
or
not,
and
one
of
the
other
important
takeaways
is
measurements
are
useless?
If
you
don't
actually
make
change,
if
you
don't
incentivize,
goodness
right
so
metrics
that
are
measured
should
be
actionable.
E
Can
we
make
decisions
based
on
measurements
and
are
they
you
know?
Are
they
actionable
to
the
point
where
we
can
improve
things
or
make
changes
to
a
network
in
order
to
to
to
improve
things?
And
one
other
thing
that
came
out
was
you
know
we
in
the
ietf
and
and
of
course,
in
the
ib
workshops,
the
the
goal
should
be
to
benefit
all
end
users
and
just
segmenting
a
a
solution
into
something
that
is
just
for
a
small
section
of
the
internet
is
not
exactly
ideal
right.
E
We
should
come
up
with
technologies
that
benefit
everyone
everywhere,
there's
a
bunch
of
more
specific
statements
and
I'm
not
going
to
read
each
one
of
these.
Quite
as
much
as
I
did
the
generals,
but
one
metric
that
was
thrown
around
a
lot
is
round
trips
per
minute.
It's
a
useful
and
consumable
metric.
I
think,
on
the
server
side.
That's
been
used
for
a
long
time,
but
it's
also
useful
on
the
on
the
user
side
as
well
of
of
how
many
transactions
can
I
can.
E
I
do
or
something
like
that
per
minute,
but
it's
you
know
you
need
to
consider
the
full
communication
path
from
client
to
server
and
back-
and
you
know
how
many
times
can
you
can
you
do
that
cycle?
It's
not
just
a
one-way
trip.
For
example,
applications
you
know
are
really
needed
that
are
new,
that
can
report
good
measurements
in
order
to
identify
insufficient
points
in
network
access.
So
this
is
this,
is,
I
think,
one
of
the
largest
things
that
we're
missing
today
is.
I
know
that
my
my
network
is
broken.
E
I
know
that
my
somebody
on
the
other
side
has
taken
a
measurement
of
my
video
quality
and
my
audio
quality,
and
you
know
and
told
me
that
it's
not
good
right
and
which
reminds
me.
I
hope
that
it's
still
good,
because
I
could
just
be
talking
to
myself.
I
have
no
way
of
knowing
right.
I
have
no
way
of
actually
understanding
whether
my
my
video
and
audio
is
actually
getting
out.
Okay
until
somebody
interrupts
me
to
say
no,
no
you're
still
good
or
nods
their
head
or
something
like
that.
E
Like
you
get
in
a
room,
and
so
we
you
know,
we
need
better
things
that
can
actually
identify
problem
points
across
the
whole.
You
know
network
from
from
one
point
to
another
or
more
likely
you
know
these
days,
you're
actually
having
network
applications
that
are
reaching
out
to
a
lot
of
different
places,
and
where
is
the
exact
javascript
being
pulled
down
to
a
web
page?
That's
actually
breaking
that.
I
can't
get
to
that
little
piece
as
opposed
to
everything
else.
That
actually
is
loading
properly.
E
So
we
need
you
know
simple
metrics
and
we
need
metrics
per
application
which
users
are
able
to
consume
and
report.
You
know
issues
about
what
is
working
and
what
is
not.
I
was
noticing
when
I
was
looking
at
the
data
tracker
earlier
that
that
you
know
I
had
to
click
submit,
and
I
didn't
get
any
feedback
that
that
my
submit
actually
went
through
right.
I
had
no
notion
of
of
yes,
it
is
taking
a
bit.
It
is
loading
because
it
is
loading
in
the
background,
and
so
that's
to
me.
E
I
wasn't
sure
if
it
was
my
network,
I
wasn't
sure
if
it
was
the
server.
I
wasn't
sure
if
it
was
the
the
application.
One
of
the
other
things
that
we
talked
about
a
lot
is
the
differences
between
quality
of
service
versus
quality
of
experience.
E
So
you
know
there's
those
are
thrown
around
quite
a
bit,
but
they're
they're
they
are.
They
are
sort
of
the
quintessential
things
of
how
do
we
measure
quality
of
service?
And
how
do
we
measure
quality
of
experience
and
they're,
not
quite
equal
right?
How
do
we
measure
what
the
user
is
actually
doing
or
experiencing?
E
We
also
looked
at
some
problem
statements
and
concerns.
So
some
of
the
statements
that
were
made
during
the
conclusion
section
were
related
to
things
that
we
we
had
issues
with
latency
mean
and
medians
or
distractions
is
one.
You
know
the
interesting
thing
is,
if
you
I
think
most
people
know
that
if
you
look
at
gaussian,
curves
or
all
sorts
of
other,
you
know
metrics
for
trying
to
determine.
E
You
know
some
statistical
average
about
something
that,
if
you
just
look
at
the
mean
in
the
median
you're
missing
a
whole
lot
of
information
right
a
mean
and
a
median
can
be
great,
but
the
standard
deviation
is
so
large
that
you
know
you
end
up
with
a
lot
of
brokenness.
Well
beyond
the
mean.
B
E
Median
for
just
as
an
example
and
the
second
bullet,
there
is
actually
kind
of
similar
to
some
some
things
that
we
said
before.
Some
of
these
statements
actually
did
have
a
lot
of
overlap,
but
it's
frustrating
that
you
know
if
you
can
only
measure
stuff,
but
you
can't
simultaneously
improve
them
right.
We
should
be
able
to
improve
them
as
well
and
we
need
to
figure
out
a
way
to
motivate
those
improvements
right.
E
So
we
need
to
come
up
with
incentives
for
public
network
access
that
will
motivate
them
and
again
this
is
similar
to
you
know.
If,
if
you
just
measure
it,
then
that's
not
that's
not
very
helpful,
and
there
was
some
discussion
about
the
ecological
impact
of
you
know.
One
interesting
aspect
of
measuring
network
quality
is
not
just
how
well
it
works,
but
how
well
it's
damaging
the
environment
or
how?
How
well
everything
is.
In
the
long
run,
we
could
have
great
networks
that
you
do
lots
of
bitcoin
mining.
E
That's
fantastic,
but
you
know
is
that
is
that
a
long-term
goal?
Or
will
it
actually?
You
know
cause
later
issues
that
will
eventually
erode
our
networks.
For
example-
and
you
know,
there's
there's
not
evidence
that
any
single
metric
is
more
important
than
others
and
one
of
the
hard
things
that
I
I
don't
think
that
the
workshop
came
to
a
complete
conclusion
about
is
how
do
you
do
prioritization
across
multiple
metrics?
How
do
you
find
the
right
metric
for
the
right
time
for
the
right
component
of
a
of
a
network
right?
E
How
do
you
know
there's
not
anyone
that
is
perfect
and
some
are
better
than
others,
and
how
do
you
manage
to
put
them
all
into
one
situation
or
one
evaluation
and
get
a
concrete
solution
out
of
it?
E
So,
in
terms
of
future
work,
we
want
to
document
the
the
workshop
the
draft
ieb,
and
that
is
the
that
acronym
is
yet
horrible,
but
I
figure
we're
good
at
horrible
acronyms,
so
I
just
included,
but
it's
measuring
network
quality
for
end
users,
because
it
was
too
long
to
fit
in
the
draft
name.
So
I
shortened
it
to
an
acronym
that
I
don't
think
had
been
used
until
I
put
it
into
the
draft.
It
is
in
the
ieb,
the
internet
architecture,
github
repository
people
are
welcome.
To
do
it.
E
There
is
the
url
that
takes
you
to
the
workshop
itself.
All
of
the
workshop
discussions
were
actually
held
in
on
recorded
videos,
so
they're
all
in
youtube
and
there's
links
to
them
as
well
as
all
of
the
papers.
From
that
that
link,
it
was
fascinating
to
listen
to
it.
In
fact,
I
still
want
to
go
back
and
re-watch
it
all
before
we
finish
publishing
the
entire
report
and
then
there's
discussions
about
where
to
go
next
right,
so
we
need
to.
E
There
is
some
tasks
that
likely
can
be
delegated
to
existing
atf
working
groups.
If
there's
immediate
work
to
be
done,
and
there
was
general
you.
E
In
where
do
we
take
longer
term
stuff,
and
I
think
that
the
the
takeout
is
really-
we
should
take
research
tests
to
the
irtf.
There
was
a
little
bit
of
discussion
of
do.
We
need
an
ieb
program
for
this.
I
think
the
general
consideration
is.
This
is
probably
not
program
worthy
at
this
point,
but
we
have
a
breakdown
between
ietf
working
groups
and
irtf
research
groups
that
were
we're,
probably
okay,
so
that
is
it
for
slides.
I
think
I
took
it
almost
exactly
ten
minutes.
E
Yeah,
I
will
say
you
know,
there's
so
much
information
in
that
workshop.
It
was
hard
to
there's
no
way
to
summarize
it
all,
and
there
was
it
was
a
very
dense
working
workshop,
which
was
fantastic
to
participate
in,
but
I
was
you
know
looking
at
writing
the
draft
going.
I
don't
even
know
how
to
summarize
all
that,
so.
A
Yeah,
I
think
the
the
discussion
in
the
chat
is
is
actually
a
little
bit
about
metrics
and
there's
also
a
draft
in
iqp.
I'm
talking
about
100
times
per
minute
as
a
different
metric
to
use.
For
example,
I
guess
there
was
also
a
lot
of
discussion
at
the
workshop
about
matrix
right.
E
A
A
And
maybe
to
I
mean
we,
we
have
the
technical
plenary
which
was
already
last
week
and
usually
in
the
not
in
the
technical.
So
we
had
the
administration
and
then
last
week
already
so
usually
we
try
to
concentrate
on
more
of
the
administrative
questions
at
that
plenary.
A
So
this
this
open
mic
is
really
more
for
technical
questions
based
on
any
kind
of
workshop,
any
kind
of
documents
working
on
workshops
or
programs
or
even
if
you
want
to
erase
the
topic
that
you
think
the
ib
should
be
aware
of.
That's
your
chance.
F
I
just
want
to
say
what
I
said
in
the
chat
which
put
in
a
plug
for
ippm
next
session,
which
is
going
to
have
a
draft
about
rpm.
A
A
G
Yeah
I
had
a
quick
question
for
actually
for
tommy
on
the
survey.
Is
there
a
deadline,
or
perhaps
we
should
set
a
deadline
for
when
responses
are
requested
there?
So
people
know
if
that's
something.
We
need
to
kind
of
quickly
do
this
week
or
I
think
we'll
get
more
responses
if
we
put
a
deadline
in
everyone's
bedroom.
E
C
D
A
fair
amount
of
responses.
I
have
been
pretty
happy
with
that.
So
far,
I'm
hoping
that
you
know
this
reminder
and
maybe
I'll
send
a
ping
to
the
list
today.
Just
to
tell
people
hey
here's
the
link
again
go
fill
it
out,
but
I
I
imagine,
after
just
kind
of
naturally
after
like
a
week
or
so
anyone
who's
going
to
respond
will
respond,
something
else,
but
yeah,
probably
you
know
by
you
know,
certainly
by
december
I'll,
just
say:
okay,
here's
the
results
and
we'll
go
look
at
it
as
a
program.
G
Okay
and
then
you
know
one
other
thing
I
put
in
the
chat
just
kind
of
more
of
a
comment.
G
Is
you
know
my
personal
interest
with
the
fine
code
draft
is
also
a
bit
broader
than
implementation
status
and
funding
yeah,
the
interoperability
aspect,
which
is
super
important
and
I
think,
a
goal
as
well,
but
I'm
also
very
interested
in
just
any
code
related
to
it,
like
some
of
the
code
that
we've
done
in
the
hackathon
and
it
kind
of
helps
you
with
understanding
a
protocol
or
maybe
implementing
it
or
or
viewing
traffic
on
the
network,
or
you
know
any
kind
of
test
tools.
Those
types
of
things,
too
are
super
helpful.
G
Just
to
get
people
help
people
to
to
implement
some
of
the
standards
that
we're
specifying
in
these
drafts.
So
I'd
be
interested.
D
H
I
wanted
to
thank
the
the
iab
for
doing
the
public,
viewing
of
it
of
iab
meetings
and
for
one
specific
reason,
which
was
the
iab,
has
been
doing:
reviews
of
research
groups
on
an
ongoing
basis
for
as
long
as
I
as
long
as
I
have
known
about,
and
they
have
not
tended
to
be
very
public.
H
I
had
the
opportunity
to
watch
not
participate
in,
but
watch
the
pan
rg
review
that
the
iab
did
fairly
recently
and
having
that
be
bented
and
viewable,
as
you
know,
as
it
was
happening,
and
things
like
that
was
super
useful
for
me
and
I
I
hope
other
research
group
participants
will
take
advantage
of
that
when
the
iab
is
reviewing
review
their
research
groups.
A
Thank
you
for
the
feedback,
so
yeah
you're,
right
that
these
reviews
haven't
been
that
much
public,
because
usually
we
used
to
do
them
during
the
meeting
week
in
one
of
our
breakfast
meetings
and
those
are
I'm
not
as
public
as
our
calls
usually
are
and
given
the
circumstances
we
now
have
integrated
them
into
our
frequent
calls.
So
we
can
schedule
them
anytime
and
those
calls
are
actually
open
for
observers,
and
so
you
can
join
any
any
ib
call
in
listening.
B
A
Yeah
I
mean
check
out
the
ib
webpage
and
try
to
find
the
agenda
there.
It's
there's
actually
a
direct
link
on
the
front
page
on
the
on
the
right
side,
and
you
can
see
that
we
not
only
have
those
boring
iap
calls
where
we
talk
about
administrative
matters.
A
We
now
have
actually
calls
that
we
label
as
technical
discussions,
where
we
only
discuss
one
technical
topic,
so
this
could
be
interesting
for
you
as
well,
if
you
want
to
check
out,
but
also,
as
you
just
said,
documents
I
just
want
to
remind
people,
please
review
the
passing
this
document,
which,
where
we
have
the
call
for
feedback
out
there
right
now
and
and
and
check
out
the
other
work
we
are
doing
in
the
programs,
and
now
we
have
more
people
in
the
queue.
So
robin
is
next.
I
Okay,
in
fact,
I
my
this,
the
my
some
this,
the
one
who
has
some
of
these
comments
on
this
is
the
draft.
That's
the
past
signal
yeah,
because
you
know
that's
the
this
time.
We
have
this
the
the
evening
work
and
we
propose
that's
the
solution
that
inca,
including
the
data
plane,
encapsulation
and
also
this
is
the
control
plane,
and
this
is
the
young
model
for
this
work.
I
So
this
will
be
helpful
to
understand
this
one
yeah,
but
you
know
that's
the
from
my
point
of
view,
so
you'll
notice,
there's
also
also
there's
the
discussion
about
the
open
internet
and
the
limited
domain,
and,
according
to
our
this,
the
discussion
about
this,
the
epm
work.
So
we
kind
of
feel
this,
so
we
we
can
feel
this
that
possible
difference.
I
Even
for
this,
the
past
signal
and
also
the
ep
work,
it
seems
similar.
That's
the
application
and
the
networking.
That's
this
integration,
but
you
know
that
for
the
for
the
apm
worker,
that
is
the
limited
domain,
so
you
can
use
only
use
available.
This
is
the
package
header
information
to
map
to
some
of
this,
the
api
id,
but
you
notice,
if
this
is
a
pass
signal.
So
this
is
maybe
that
means
this.
The
signal
information
be
directly
derived
as
the
host
and
the
application.
I
That
is
maybe
more
specific,
because
it's
very
clear
about
what's
the
user
and
what's
the
application
so
from
my
point
of
view,
so
that
when
for
this,
the
for
this
drop
from
my
point
of
view,
you
to
you
should
be
thinking
about
the
possible
difference
between
the
open
internet
and
the
limited
domain.
A
So
if
you
remember,
I
think,
at
the
last
ieb
open
meeting,
we
actually
had
a
presentation
about
this
draft
and
we
had
a
bit
of
discussion
there
and
got
a
lot
of
input.
That
was
really
good
and
I
think
a
similar
comment
was
made
so
the
last
revision
of
this
draft.
We
actually
updated
it
to
add
a
little
bit
more
text
about
this
you.
You
should
probably
just
read
it
yourself,
but
I
think
the
considerations
I
personally
think
and
I'm
an
author
of
that
draft.
A
I
think
the
considerations
are
not
that
different
for
limited
domains.
You
need
security,
also
limited
domains
you
have
to
protect
about.
You
know
unknown
attackers
that
attack
your
network,
so
I
don't
think,
there's
a
huge
difference
and
that's
what
we're
mentioning
in
the
draft,
but
I
mean
please
have
a
look
and
provide
more
feedback
and
start
a
discussion
on
the
architecture
discuss
mailing
list.
I
think.
I
E
Thanks,
I
just
wanted
to
follow
on
a
little
bit
about
russ's.
Great
comment
of
the
iab
meetings
are
all
open,
except
for
executive
session,
and
that's
the
part
that
I
wanted
to
talk
about.
E
We
have
almost
nothing
in
executive
session
and
I
know
I
talked
to
somebody
a
year
or
two
ago
that
thought
you
know
we
always
go
straight
into
executive
session,
and
that
is
that
is
we
spent
like
maybe
five
minutes,
and
it's
only
when
we're
looking
at
background
information
for
people
we're
going
to
appoint
or
comments
that
you
know
when
we
collect
public
feedback
that
is
about
it.
We're
we've
actually
had
almost
no
executive
sessions
for
the
past
three
years
that
I've
been
in
the
aba.
H
I
don't
think
you're
supposed
to
say
that
in
front
of
the
iab
members
and
potential
iab
nominees,
but
but
it
is
true,
the
the
question
I
was
going
to
ask
is
probably
for
something
that
russ
was
mentioning
about
having
documents
that
the
iab
would
like
to
have
help
on,
and
I
I'm
a
little
curious
about
two
things.
One
is
kind
of
how
we
would
know
that
and
number
two
is:
is
there
a?
Is
there
an
obvious
time
for
us
to
try
to
be
helpful?
H
You
know,
like
often
the
often
the
notices
I
will
see
are
for
ib
call
for
comments
on
adoption,
or
something
like
that.
I
mean,
but
I'm
a
little
vague
on
how
we,
how
the
people
could
who
could
help
would
know
that
they
should
be
helping
and
should
be
helping.
Now.
A
And
maybe
so
I
mean,
I
think
your
question
is
really
good,
but
maybe
I
also
want
to
pre-empt
this.
So
when
we
publish
the
document
on
the
ice
cream,
it's
also
kind
of
an
opinion
piece
from
the
iob
right.
So
we
were
looking
for
a
lot
of
input
because
the
iab
has
some
smart
people,
but
we
don't
know
everything
and-
and
we
don't
want
to
miss
important
stuff
right,
but
at
some
point
it's
it's
also.
You
know
what
the
iv
thinks
is
the
right
advice
to
the
community.
Russia
wanted
to
say
something.
B
Yeah,
I
was
just
going
to
say
yeah
and
you
know
if
you
attended
some
of
the
technical
sessions.
You'd
see
some
of
the
stuff
we
were
working
on
and
maybe
get
involved
a
bit
sooner
than
when
it's
published,
and
I
don't
really
know
of
another
good
way
of
or
just
look
at
the
meeting
minutes
from
the
old
meeting
minutes
and
look
at
some
of
the
stuff
we're
working
on.
You
don't
have
to
attend
the
meeting
necessarily
just
say:
oh
yeah,
I
see
the
ib
talked
about
blah
blah
blah.
A
So,
just
from
the
process
point
of
view,
for
a
couple
of
years
already,
we
have
two
steps
where
we
actually
reach
out
to
the
explicitly
reach
our
community.
One
is
before
we
adopt
a
document
as
an
ib
document.
That's
what
what
with
passing
document
is
right
now.
So
this
is
an
early
stage,
and
this
is
a
really
good
point
to
provide
a
lot
of
input
because
that's
where
we
can
still
scope
and
change
the
document
and
the
other
one
is
very,
very
late
just
because
before
we
start
want
to
publish
the
document.
A
So
that's
the
point
where
document
is
basically
done
and
if
you
have
a
concern,
we
might
still
consider
it,
but
we're
not
planning
to
change
the
document
a
lot.
But
we
do
have
these
two
points
in
in
the
process
where
you
can
easily
engage
and
between
those
two
points
or
even
before
that
first
point.
We
try
to
actually
bring
it
to
this
meeting
here
because
that's
where
we
have
discussion
time
with
the
community.
I
I
A
So
and
now
I
think
we
actually
reached
the
end
of
the
queue
and
we
can
just
stop
a
few
minutes
early
here.
I
don't
think
anybody
would
be
too
sorry
about
that.
So
in
that
sense,
thank
you.
Everybody
for
the
meeting.
If
you
have
any
further
questions,
please
reach
out
to
the
iab
reach
out
to
me,
reach
out
to
us
or
everybody
else
in
the
iv
and
see
you
next
time.