►
From YouTube: IETF110-TSVWG-20210308-1600
Description
TSVWG meeting session at IETF110
2021/03/08 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
C
A
Okay,
I
think
I
can
make
this
work
outside
of
slideshow
mode,
so
that
give
me
some
some
access
to
it
to
me,
echo
all
right,
folks,
we're
ready
to.
A
C
A
A
A
D
Okay,
I'm
not
mute
okay.
I
am
here
now
a
long
name.
A
Yeah,
it's
just
wonderful,
it's
very
easy
to
to
double
mute
yourself.
Then
you
have
to
left
left
meta
shift,
click
just
to
figure
out
how
to
get
out
of
it
all
right.
I
think
I've
got
things
set
up.
There's
enough
the
slide's
big
enough.
I
think
people
can
see
it,
so
I
can
probably
toggle
back
and
forth
between
windows
and
we'll
try
to
make
that
work.
All
right.
Welcome
to
to
the
transport
area
working
group
meeting
at
ietf,
110
online.
A
All
three
group
chairs
are
here
we're
all
remote.
This
is
the
note
well
reminder
that,
as
part
of
registering
the
meeting
you
agreed
to
this,
this
applies.
This
applies
to
you
all
kinds
of
references
there
which
which,
which
I
will
not
go
through.
Okay,
do
we
have
a
lead.
A
A
Taking
some
notes,
okay
and
if
you
could
start
by
pasting
the
agenda
in
that
that
tends
to
work
really
really
well
with
all
right.
A
Let's
do
that.
I
mean
remo.
We
don't
need
the
blow
by
blowers.
I
suspect
most
people
don't
read,
read
the
minutes
for
blow
by
blow.
We
do
need
to
record
any
any
any
major
decisions
that
get
read.
A
Okay
need
some
people
to
watch
jabber.
All
you
need
to
do
is,
if
is,
if
you've
got
your
your
eyes
on
jabber,
and
you
see
something
turn
up
in
chat,
raise
your
hand
and
with
luck
one
of
us
will
notice
and
we'll
get
somebody
on
we'll
get
you
over
or
we're
making
the
comment
in
jabber
onto
the
mic.
A
As
usual,
we
always
need
reviewers
for
our
working
of
drafts
and
a
reminder.
Folks,
please
do
add
tsvwg
to
the
name
of
any
internet
draft
submitted
that
way.
We
might
actually
notice
them.
A
Okay,
some
meet
echo
usage
tips,
both
the
chat
and
the
meeting
notes
can
be
separated
into
separate
windows
or
tabs.
It's
actually
quite
useful
because
it
means
that
you
can
toggle
back
and
forth
between
windows
on
your
screen
to
change
context,
as
opposed
to
having
to
find
the
right
icon
in
meet
in
meet
echo,
and
it
leaves
you
meet
echo
window
focus
on
speakers
cues
and
slides.
We
just
had
discussion
about
this.
The
icons
have
changed,
in
fact
this
is
hand,
hand
icon
mic
on.
A
Please
don't
use
the
mic
icon
until
acknowledged
by
the
chairs.
You
just
saw
a
demonstration
of
this,
and
what
you're
looking
at
will
be
will
be
uploaded
some
point
as
a
yet
yet
new
and
improved
version
of
the
chair,
slides.
A
In
general,
we
need
reviewers
for
documents.
If
you
are
interested
in
your
documents
reviewed.
Please
review
other
documents
both
here
and
help
out
other
working
groups
by
reviewing
their
documents
best
people
will
help
will
help
us
out
and
listed
on.
This
slide
is
some
idc
new
review.
A
Sctp
core
standard
update,
the
the
main
4960
bis
draft
is,
is
getting
mature,
udp
options
and
all
the
various
other
dots
related
to
ec
in
this
working
group,
okay,
close
to
the
status
first
of
all,
the
diff
server
rtc
webq
os
draft
has
finally
been
published,
as
as
an
rfc,
the
infamous
webrtc
cluster
238
was
popped
out
and
we
did
in
fact
managed
to
get
the
process
rc
underwrite.
A
It
includes
the
updates
we
need
to
make
for
the
lower
effort
of
php,
which
itself
is
documented
rs8622.
We
have
one
id
at
the
iesg.
Finally,
the
transfer
hair
confidentially
density
impacts.
I
expect
the
isg
will
be
taking
this
up,
not
long
after
this
meeting
week
we
have
one
ids
with
the
ad
review
in
progress.
This
is
the
sctp
net
draft
I've
seen
a
major
review
from
the
ad
within
in
the
past
24
hours.
It's
funny
how
meeting
week
cause
is
a
forcing
function
for
stuff
to
happen.
A
Anyhow
expect
to
see
more
on
that
draft
in
the
near
future.
We
have
two
ideas
from
the
chairs
and
authors.
Jefferson,
last
call
and
again
the
meeting
week
is
functioned
as
as
a
forcing
function
in
that
new
draftsman
posted
with
with
what
might
be
close
to
the
final
text.
Yours
truly,
who
is
the
shepherd
for
this
direct?
These
two
drafts
is
getting
tired
of
reading
off
the
status.
These
drafts
will
be
submitted
to
the
iac
publication
by
the
next
next.
A
I
I
etf,
I
think
we're
fairly
close
and
I'm
gonna
going
to
put
in
the
effort
to
get
it
done.
Okay,
here
are
the
additional
working
group
drafts.
There
are
six
of
them
sctp
three
alphas
drafts,
the
the
non-queue
building,
php
and
udp
options,
and,
as
we
get
things
out
of
the
working
group,
we'll
have
some
bandwidth
with
which
to
take
on
new
work.
A
One
of
the
pieces
of
new
work
that
it
does
look
like
a
really
unique
take
on
a
fairly
short
order
is
there's
a
credit
card
request
is
meeting
to
adopt
the
alfres
operational
guidance
draft.
A
Okay,
whole
bunch
of
related
drafts.
Let
me
go
through
them
quickly.
Path.
Mp,
discovery
continues
to
be
an
active
area.
Gory
has
a
draft
on
how
to
do
this.
With
for
udp
with
udp
options,
there
is
a
draft
over
in
six
man
and
how
this
ipv6
and
a
draft
in
the
tram
working
group
on
how
to
do
this.
For
the
stun
that
traversal
mechanism
for
sctp,
michael
tuxen,
has
a
couple
of
drafts,
one
on
edp
encapsulation,
one
on
multipath
and
diffserv
dhcp
selection.
A
Anna
kastura
has
a
draft
on
this.
This
sort
of
very
close
to
the
meeting,
so
we
did
not
put
it
on
the
agenda.
However,
it
is
a
very
promising
draft.
Please
read
this
as
it's
likely
to
be
a
candidate
for
working
with
adoption.
This
is
trying
to
roll
up
all
the
things
we've
learned
the
hard
way
about
how
about
how
to
assign
and
how
not
how
not
to
assign
dscps
to
to
new
new
new,
perhaps
behaviors,
more
related
drafts,
improv
digital
guidelines,
multipath
dccp.
A
I
have
a
status
slide
on
that
which
we'll
put
up
in
a
in
a
little
bit
network
layer,
multipath,
application,
air.
Aware
networking,
oh
gee,
I
misspelled
that
word
didn't.
I
hang
on
one
of
the
nice
things
about
being
this
this
mode.
I
can
fix
my
fix
my
mistakes
in
real
time.
Primary
draft
to
read
is
the
gap
analysis
draft
not
for
discussion
here.
A
This
is
a
top
of
interest
to
a
lot
of
areas
in
ietf
the
primary
discussion
forums
for
this
will
be
the
routing
area
work
group
meeting
on
thursday
and
the
int
area
working
group
meeting
on
friday,
and
we
have
a
new
draft
on
transport
for
satellite.
Yet
another
chapter
in
this
in
in
this
on
ongoing
adventure:
okay,
we're
about
to
go
bash
the
agenda,
but
the
basic
outline
is
dr
collins,
accomplishments
and
status
today,
which
we're
in
the
middle
of
now
milestones,
review
coming
up
shortly.
A
Drafts
wednesday
agenda
more
drafts
and,
in
particular
the
game
plan,
is
that
wednesday
is
pretty
much
devoted
to
the
l4
s,
work
on
which
we
are
endeavoring
in
endeavoring
to
make
make
progress,
and
so
that
that's
what
the
entire
wednesday
agenda
is
going
to
be
devoted
to
also
notice
that
this
agenda
is
completely
full.
It
looks
like
we
may
want
to
ask
for
four
hours
next
time.
Three
is
no
longer
three
appears
no
longer
enough.
A
Okay,
milestone
milestones,
review
and
I'm
going
to
try
and
take
notes.
We
go
along.
We
had
this
optimistic
notion
that
we'd
be
able
to
publish
the
l4s
architecture
draft
before
the
the
two
main
protocol
drafts
not
happening.
So
el
forest
architecture
needs
to
move
to
october
2021..
A
The
next
two
milestones
are
for
our
two.
Each
and
cap
drafts
have
been
hanging
around
for
a
while.
I
just
promised
that
those
will
be
done
by
the
next
ietf,
so
those
two
milestones
change
to
june
of
2021
sctp,
michael.
If
you're
on.
Please
turn
your
mic
on
and
tell
us
what
a
reasonable
time
frame
for
sctp
might
be:
go,
go
ahead.
D
A
Okay,
we'll
we'll
go
look
for
glasgow
reviews
during
this
meeting
and
I
will
put
september
2020
21
on
that
as
a
new
date.
That
way
we've
got
if
things
happen
and
summer
and
and
and
summer
occurs,
we've
still
got
got
a
got
a
plausible
milestone.
A
It
would
be
lovely
if
we
could
get
this
done
between
now
and
next
ietf,
but
I've
been
through
the
we're
gonna
get
everything
on
my
next
meeting
and
then
discovering
that
a
third
to
two-thirds
of
the
things
in
the
next
meeting
bucket,
don't
donate
all
right,
transfer
options
for
udp
this
one's
been
running
slowly,
I
don't
know
genu
push
it
push
it
glory.
What
do
you
think
a
time
frame
for
this
one
might
be.
D
A
I
will
make
a
note
discuss
that
in
joe's
session,
nqb
is
approaching
completion.
We
think
we're
going
to
get
some
viewers
attention
to
it.
I
think
I'm
going
to
apply
the
same
algorithm
to
nqb,
that
we
just
applied
to
sctp
and
put
a
revised
date
of
september
on
that
greg
if
you're
on
the
call
feel
free
to
turn
on
your
mic
and
and
revise
and
send
my
remarks
for
me.
H
Hello
yeah,
I
think
the
draft
itself
is
in
good
shape
and
we'll
have
a
longer
discussion
later
today
on
that,
and
only
one
kind
of
new
aspect
that
was
introduced
since
the
last
meeting.
That
needs
some
discussion
other
than
that
the
the
draft
is
is
in
pretty
good
shape.
A
Okay,
so
I'm
gonna
put
a
september
date
on
that
draft
and
the
scpp
draft
with
that
that
gives
us
that
gives
us
a
meeting
cycle
to
work
through
the
one
new
issue.
A
Then
we've
got
the
lfrs,
the
two
l,
the
three
alpha
s
wraps,
including
the
one
previous
slide,
are
currently
set
for
october.
That's
not
that's
not
a
not
a
bad
date.
Yet,
let's
leave
that
alone.
A
Okay,
quick
review
of
the
agenda.
We've
just
done
the
chairs,
update
announcements
and
heads
up
that's
going
to
come
after
I
run
through
the
agenda.
One
of
the
things
we've
got.
We've
got
a
couple
of
liaison
the
statements
that
I
need
to
briefly
call
attention
to
the
chairs.
I
have
to
respond
to
we'll
go
immediately.
Sc
sctp
drafts
then
joe
touch
for
udp
options.
The
nqb
draft
we
just
talked
about,
and
anna
kastura
has
one
once
once
again.
A
A
Then
the
rest
of
today
is
a
couple
of
individual
drafts.
Q
log
has
been
proposed,
I
think,
initially
the
queue
I
think
it
may
have
initially
stood
for
quick.
It
no
doubt
stands
for
something
else.
Now
it's
looking
like
a
general
logging
mechanism.
We
want
to
get
some
air
time
here
to
see
what
people
think
of
it,
and
then
we
have
some
measurements
of
ecn
act
on
an
exchange
provider
that
will
talk
through
through
this
representing
map.
Rg,
we'll
talk
to
some
implications
here.
A
This
is
in
some
ways
a
setup
for
for
wednesday,
which
is
l
for
which
is
l
for
s
day.
You'll
see,
I'm
gonna
start
the
author's
operational
guidance
draft
which
we're
going
to
adoption
requested.
We
then
have
the
three
main
alfres
drafts
and
ingrimar.
If
we
have
time,
ingomar
will
have
the
opportunity
to
talk
about
some
of
the
work
doing
of
racing.
5G
gory
go
ahead.
D
I
just
wanted
to
note
that
we
had
more
requests
for
time
than
we
could
accommodate
this
time.
So,
if
you're
going
to
make
a
request
for
time
at
an
agenda
in
a
coming
meeting,
please
do
it
ahead
of
the
time.
So
we
can
get
a
feel
as
to
how
much
time
we
need
and
how
to
allocate
it.
Yeah.
A
A
I
A
Let
me
go
let's:
let's,
let's
try
to
do
that
fairly
quickly.
I
believe
you
sent
me
one
slide.
Let
me
see
if
I
can
fish
it
out
of
the
chaos
as
masquerading
as
my
email
inbox,
yeah
there.
It
is.
Let's
put
that
one
slide
up.
I
think
the
right
thing
to
do
is
going
to
be
to
handle
the
adoption
call
on
the
list
all
right
now.
I've
got
the
slide
up
now
I
gotta
figure
out
how
to
do.
A
Stop
screen
share
share
screen,
hang
on
yeah
that.
I
Sure
I
can
do
so.
Maybe
some
of
you
have
seen
that
we
make
some
significant
progress
on
the
multi-pass
dcp,
so
we
updated
the
draft.
I
What
we
exactly
did
you
find
in
the
on
the
tsv
wg
mailing
list,
so
there's
a
link
which
guides
to
this
email.
We
have
a
new
contributor
to
the
draft,
it's
british
telecom
and
I
think,
most
important.
This
time
we
have
published
the
multi-past
thesis
app
open
source,
so
you
can
get
all
the
informations
how
to
access
the
code,
how
to
use
it,
how
to
maybe
set
up
own
test
that
you
find
on
the
multiple
ccp.org.
I
Then
we
have
also
seen
that
some
parties
expressed
their
interest
in
multiples
tccp.
It
was
casa
systems
like
telefonica
and
so
on.
I
can't
remember
all
of
them
yeah!
That's
why
my
plan
this
time
is
to
to
request
adoption
and
happy
to
discuss
this
now
with
you,
okay,
okay,.
D
Go
ahead:
yeah
can
I
I'm
I'm
pretty
sure,
as
we've
been
through
this
before
that,
if
we're
the
ietf
is
to
do
work
on
dccp,
this
is
the
right
working
group,
so
I
think
you're
in
the
right
place
and
dccp
isn't
a
protocol.
We've
seen
a
lot
of
active
development
and
implementation
activities
around
recently,
so
we
would
be
very
interested
in
people
who
would
like
to
implement
this
and
see
a
need
for
an
interoperable
standard.
D
I
So
gary
is
sorry
for
for
asking
again,
because
my
impression
was
all
right.
That
was
also
what
we
discussed
last
time
last
itf
and
my
feeling
was
now
with
publishing
the
multiplex
tccp
open
source
as
part
of
the
linux
network
stack
also
multiple
parties,
who
expressed
already
the
interest
on
the
waiting
list
that
this
is
or
should
be
enough
to
request
the
adoption.
D
D
It's
enough
to
start
asking
the
question
about
adoption
and
there'll
be
more
questions
to
follow.
These
are
encouraging
answers.
I,
like
the
answers,
I'm
hearing.
We
will
have
to
discuss
this
on
the
list.
The
other
thing
is,
when
you
say
part
of
the
linux
stack.
Is
this
core
as
in?
Is
this
a
part
of
the
mainstream
release
that
you're
planning
or
is
it
no?
D
This
is
something
we
obviously
have
to
talk
with
with
you,
and
we
can
also
talk
about
this
in
a
separate
catch-up
meeting
with
you,
but
please
use
the
list
to
discuss
this.
Okay,
yeah.
Thank
you,
jonathan.
Are
you
in
queue
for
the
same
topic.
D
Fair
enough,
fair
enough
and
and
as
I
noted
in
the
in
the
chat
with
you
previously
just
prior
to
this
meeting,
when
pete
got
cut
from
his
questions
in
map
rg,
there
simply
wasn't
time
to
really
ask
questions
or
go
into
the
data,
so
we'd
like
to
open
with
questions
around
the
data
sets
that
have
been
produced
and
and
see
how
that
goes.
I
I
think
it
would
be
useful
to
be
able
to
talk
about
that
data.
It's
useful
data.
A
Turn
that
off-
and
my
apology
has
taken
me
a
little-
I
will
get
better
at
clicking
through
meet
echo
as
the
meeting
goes
on,
but
where
I
think
we
are
now
is,
we
are
back
to
here,
okay,
and
we
need
to
quickly
talk
about
liaison
statements.
So
there's
two
of
them
I'll
talk
about
wba
statement.
The
va
has
sent
us
a
liaison
statement
about
qos
across
across
wi-fi
and
5g.
A
D
A
We've,
I
think
that
takes
care
of
the
announcements
and
heads
up
and
apologies
that
we
are
in
fact
short
on
time
and
needed
and
needed
to
to
to
constrain
the
mpdccp
draft
to
that
heads
up
and
we're
not
able
to
call
these
other
requests.
I
have
taken
a
note
that
we've
got
to
ask
for
four
hours
next
time.
A
Okay,
let
me
stop
screen
sharing
and
michael.
You
want
to
start
talking
about
4960
best,
please.
I
think
you
offered
tom
one
slide.
G
A
K
A
I
wasn't
aware
that
one
slide,
let's
get
okay
new
screen
share
is
getting
started.
Yeah,
yeah
yeah,
give
me
a.
A
Okay,
I
can
share
just
the
window
if
you'd
like
me
to
if
you'd
like
me,
to
do
that.
That
would
be
perfect.
Okay
done
hang
on.
Now
you
get
to
see
how
fast
I
can
click
through
this
yeah.
It's
a.
I
hear
lots
of
complaints
from
people
about
how
some
of
these
tools
work
better
on
windows
than
linux.
Okay,
did
that
come
through
michael,
perfect,
next
slide
cool.
G
This
time,
two
updates
of
the
documents
have
happened
between
the
last
ietf
and
this
one.
The
old
eight
version
is
about
the
transition
from
xml
v2
to
v3.
So
if
you
compare,
both,
you
have
lots
of
white
space
changes
and
the
appendix
a
which
was
about
ecn
has
been
removed,
as
we
discussed
last,
the
last
ietf
and
gory
sent
comments,
and
they
have
also
been
addressed
in
the
version.
08
version
09
incorporated
basically
three
reviews
and
if
you
go
to
the
next
slide,.
A
One
quick
question:
as
you
go
through
accepted
well
path:
mtu
is
a
really
common
concept.
I
had
three
really
drafts
on
there.
Do
we
have
someone
in
the
working
group
who's
trying
to
to
write
her
to
all
the
on
all
the
various
drafts
that
are
working
on
path,
mtu.
G
I
would
say
how
I
use
this
and
what
the
comments
are
so
like
so
the
the
the
document.
So
I
got
lots
of
editorial
comments,
but
this
one
was,
I
would
say,
not
not
only
editorial
so
in
a
lot
of
places
in
the
documents
something
about
the
size
of
the
packet
or
something
like
this
was
mentioned,
and
it
was
vague,
intentionally
vague
and
this
doesn't
seem
to
be
appropriate
anymore.
So
there
are
two
contacts.
G
One
is
a
size
argument
related
to
the
size
of
the
packet
like
does
it
fit?
Does
it
need
to
be
fragmented
and
so
on?
And
so
I
changed.
The
usage
there
to
pmtu,
which
means
the
maximum
size
of
an
sctp
packet
on
a
particular
path
and
the
size
of
the
http
pack
is
the
size
of
the
ip
payload.
G
So
that's
pmtu.
That's
consistently
used
there
as
pmtu,
and
the
size
was
also
used
in
the
context
of
receive
window
congestion
window
where
you
increase
and
and
reduce
our
numbers,
and
there
we
use
now
pmdcs,
which
is
the
path
maximum
data
chunk
size.
And
if
you
are
within
the
context
of
of
this
document,
it's
just
the
pmtu
minus
the
size
of
the
the
common
header
minus.
G
If
you're,
not
a
multiple
of
four,
if
you
have
auth
sap
authentication,
then
you
have
to
also
subtract
the
size
of
the
authentication
header,
but
so
this
is
now
handled
more
precisely.
If
you
want
to
change
the
names,
I
don't
care
to
change
the
names.
Some
of
the
suggestions
which
haven't
been
accepted
was
split
fast
retransmission.
G
There
was
a
suggestion
to
include
this,
but
this
is
used
for
multipath
transport
and
multipath.
Http
is
not
something
the
working
wants
to
work
on,
so
I
didn't
accept
that
the
other
one
was
that
the
association
fails
eventually,
if
the
peer
does
stop
reading
date,
user
data-
and
this
is
not
how
transports
work
so
if
they,
if
the
connection
stays
alive
in
the
sense
of
you,
can
reach
your
peer,
the
peer
just
is
not
reading
anymore.
That's
an
application
layer
problem,
but
not
a
transport
layer
problem.
G
The
next
one
was
that
out
of
the
blue
packets
should
only
be
so.
A
packet
should
only
be
out
of
the
blue
if
it's.
If
it's,
if
it's
for
a
particular
endpoint,
so
if
a
host
running
a
kernel
stack
gets
a
packet
and
there
is
no
open
port
for
it,
it
shouldn't
be
considered
out
of
the
blue.
So
this
in
my
sense,
not
what
out
of
the
blue
means
there
was
a
suggestion
to
change
that
receiver
may
send
it
about
in
response
to
an
out
of
the
blue
packet.
G
Currently,
the
text
says
should-
and
this
is
a
protection
mechanism
for
for
nodes,
not
running
http,
and
it
should
stay
there
and
the
last
one
was
to
provide
a
parameter
set,
which
is
more
appropriate
for
signaling
networks.
But
we
have
been
through
this
discussion.
I
think
in
1999
or
2000,
where
the
ietf
does
things
for
the
internet
and
not
for
signaling
networks,
so
the
parameter
sets
are
for
signal
for
for
the
internet,
not
for
signaling
networks.
I
listed
the
people
who
provided
feedback.
Thank
you
very
much.
G
I
pinged
three
additional
person
people
I
haven't,
got
feedback
from,
but
I
picked
them
again.
So,
from
my
perspective,
if
you
go
to
the
next
slide,
the
documents
to
me
screen
too
many
windows
yeah
next
time
there
we
go
yeah.
So
I
I
got
one
comment
from
magnus
that
he
wants
a
definition
of
control
chunk
which
is
now
in
for
the
next
version,
but
except
for
addressing
new
comments,
there's
nothing
on
it
to
do
with.
So
please
read
it
or
stop
the
writing.
A
L
D
Michael,
are
you
familiar
with
the
implementations?
Are
they
following
this?
This
update?
Is
this
new
stuff
to
them,
or
is
this
stuff
that's
already
done
and
needs
to
be
documented.
A
So,
let's,
let's,
let's
try
something
innovative
here.
We
need
some
working
group
last
call
reviewers.
If
you're
willing
to
review
and
comment
on
this
virtual
ass
call,
assume
working
glass
call
happens
either
later
this
month
or
in
april.
Please
click
on
the
raise
your
hand,
join
q,
icon.
A
I
see
magnus
and
gory
okay
and
we
may
round
ups
try
to
round
up
some
other
reviewers.
Some
of
the
folks
who
provided
comments
michael
has
reached
out
for
comments
on
the
important
thing
is
we
do
need
to
have
a
number
of
people
read
the
draft
at
what
new
glass
call
and
a
fresh
pair
of
eyes
would
almost
certainly
help
as
michael's
working
on
this.
For
quite
some
time
suspect.
He
knows
a
lot
of
the
text
by
heart.
D
A
G
A
A
D
B
This
either
way
yeah-
maybe
I
can
start
so
provide
the
context
there,
because
actually
working
group
hasn't
seen
this.
I
did
a
review
just
finished
friday.
I'm
sorry
for
the
very
long
delay
here
and
my
plan
here
is
now.
After
getting
some
response,
I
will
update
my
ad
review,
based
on
some
feedback
from
michael
and
publish
and
submit
that
publicly,
so
everyone
can
see
it.
I
talked
to
martin
about
doing
that
too.
So
that's
my
plan
going
forward,
so
everyone
can
see
my
feedback
here
and
then
we
can
have
a
public
discussion.
B
I
think
on
the
main
list
about
dealing
with
some
of
these
issues
etc,
but
and
and
and
target
but
yeah.
G
Yeah,
maybe
maybe
one
thing
I
would
say
is
that
the
nut
document
is
very
old.
It
started,
I
think,
15
years
ago,
with
the
main
use
case,
clients
behind
a
consumer
nut
and
talking
to
public
web
servers.
Public
servers
and
magnus
brought
up
a
use
case
in
which
is
with
the
virtualization
stuff.
Where
you
have
multi-homing
is
more
important,
and
so
we
we
didn't
focus
on
that
use
case.
Basically,
so
that's
something
we
might
need.
A
A
Say
that
obviously
the
clock
is
going
to
run.
M
E
On
on
magnus's
a.d
time,
and
so
unfortunately
well,
I'm
gonna
have
to
read
this
thing
and
unfortunately,
you're
essentially
gonna
get
a
double
id
review
and
I
apologize
for
the
to
the
authors
for
that,
but
that's
how
it's
getting
working
out.
I'm
gonna,
I'm
gonna
it's
on
my
list
to
relatively
soon.
I
hope
you
get
those
comments
out
shortly
after
this
meeting.
D
B
I
can
try.
Let's
see,
I
need
to
click
that
then
I
guess.
L
B
Bingo
level
I
see
yeah
I'll
try
to
get
it
to
full
screen.
So,
yes,
this
is
dtls
over
http
enough
proposed
update
to
rfc
6083
draft
is
titles
there.
It's
been
worked
on
by
me
and
my
co-authors
claudio
polly,
ferry
from
ericsson,
john
matson
and
michael
jackson
from
university
flight
science.
So
so
the
background
for
this
update
our
proposal
update
is
that
3dpp
in
the
in
5g
networks
uses
the
lsrtp,
in
other
words
rc
683,
for
securing
several
radio
network
application
protocols,
and
it's
it's
load,
update.
Okay.
B
No-
and
I
was
I
went
into-
let's
see
if
it
works
better
if
it
seems
to
doesn't
pick
up
updated
yeah.
I
will
do
it
from
this.
If
you
let
me
just,
I
can
do
it
like
this.
B
So
yes,
so
in
gdp,
there's
at
least
four
different
radio
network
interface
related
protocols
that
uses
that
has
the
theoretical
potential
to
send
messages
over
16k,
which
is
the
limit
to
rfc
6083
for
user
message
sizes.
B
B
Asking
tsbw
to
address
the
issues,
there's
an
action
in
that
to
respond
if
we
can
deal
with
it,
etc.
So
that's
gonna
need
a
response
in
some
form.
3Dpp
and
basically
people
would
really
prefer
this.
A
general
solution
to
address
this
issue
than
having
to
try
to
address
it
in
their
individual
protocols
for
each
and
every
of
them.
B
So
and
that's
why
they
want
us
to
look
into
if
you
can
update
rc63-
and
it
really
is
the
issue
here-
is
that
683
maps
produce
a
message
to
a
single
detailers
record,
which
then
becomes
too
small,
because
it's
only
16k.
B
We
also
have
the
issues
of
rfc
6083
security
requirements.
I
mean
this
rfc
is,
I
think,
10
years
old
and
it
shows
its
detail,
is
1.0
and
it's
sha
one
in
stp
oauth,
not
that
it's
super
sense
problematic
for
a
moment,
but
at
least
it's
it's
a
little
bit
low
on
security
properties.
So.
B
So
the
proposal
here
really
is
to
replace
our
c63
with
updated
specification,
define
a
secure
fragmentation
mechanism
and
basically
it's
a
very
simple
diff
message.
So
looking
at
the
right
side
of
screen,
we
have
the
plain
text.
User
message
then
use
fragment
that
into
units
that
fits
in
a
detailer's
records
as
many
as
you
need.
B
Then
you
run
on
each
fragment.
You
protect
that
with
it
to
create
the
details
record
and
then
you
concatenate
together
as
a
protected
user
message.
Then
you
transmit
it
over
http
on
a
particular
stream
as
an
individual
user
message,
and
you
basically
rely
on
the
sctp
authentication
to
ensure
that
the
fragments
arrive
at
the
receiver
in
the
correct
order
and
that
no
one
can
interfere
with
it
as
these
aspects
of
the
data
being.
B
We
also
have
the
security
requirements
fixing
that
we
also
looked
into
some
signaling
of
supported
message
sizes
from
the
by
the
end
point-
and
this
is
now
also
defined
as
a
sctp
adaptation
layer
and
with
a
handshake
indication,
and
it
allows
us
to
do
something
which
avoid
some
of
the
uncertainty.
So
when
you're
doing
this
in
the
handshake,
you
already
know
that
you're
gonna
run
details
on
all
the
messages,
so
you
have
no
question
or
not.
If
this
should
be
protected
or
not.
B
You
also
do
like
some
housekeeping
or
saying
oh
eye
data,
for
this
large
message
is
really
useful,
because
otherwise
you're
gonna
run
potentially
into
some
bottlenecks
and
we're
also
trying
to
clarify
some
of
the
details.
1.2
renegotiation.
B
Then
we
have,
as
I
said,
this
is
still
relying
on
sctp
authentication.
You
can't
use
this
without
it.
It's
sap
authentication
is
keyed
by
the
dtls
and
the
details.
Fragmentation
mechanism
and
re
replay
protection
of
details
records
is
provided
by
the
ssp
stack
and
authentication.
So
it's
nothing.
No
data
should
ever
be
duplicated
up
to
words
about
the
http
layer.
If,
if
any
attacker
tries
to
duplicate
data,
it
should
be
caught
and
handled
by
the
stack
so.
B
However,
we
do
have
some
open
issues
and
some
work
for
front
of
us
still
to
before.
This
is
ready.
B
One
of
the
issues
we
actually
realized
is
that
detail
is
1.3
and
re-keying
for
long-lived
flows
is
problematic,
and
the
basic
here
is
that
details
1.3
do
not
support
renegotiation,
so
there's
no
post
handshake
server,
authentication
it
re-authenticates
client,
it
doesn't
run
re-run
the
helmet
or
export
their
secret
updates,
so
it
can
re-key
in
a
certain
way.
But
it's
has
a
mechanism,
that's
not
ideal
for
having
long
lived
sessions
and
when
I
talk
about
long
lead
sessions,
say
we're
talking
days
weeks
months
for
some
of
these
usages,
for
example,
in
mobile
networks.
B
B
We
had
started
some
discussion
in
the
tls
working
group
about
these
things
for
the
telus
1.3,
so
I'll
have
to
see
where
this
is
taking
us,
but
at
least
there's
an
issue
which
I'm
going
and
therefore
dtls
1.2
support
will
be
crucial
initially
for
ensuring
that
property
for
long
lead
flows,
and
we
also
this
adaptation
layer
and
being
certain
that
everything
is
protected
by
detailers
is
good.
But
I
want
to
point
out
that
start.
Tls
will
not
work
under
these
restrictions
and
and
therefore
it's
a
question
more
than
anything
to
see.
B
If
anyone
has
issues
with
us
taking
this
direction-
and
we
also
want
this
clarify
a
bit
about
the
portrait
delivery
or
protect
user
message
between
the
sctp
stack
and
the
upper
layer
of
detail
is
here
and
what
happens
when
you
actually
don't
get
all
the
data
and
what
you
do.
B
We
also
see
in
these
socket
api
changes.
Maybe
have
some
need
for
that,
because
if
you're
require
testing,
for
example,
that
you
should
use
sha-256
the
current
socket
api
for
sdb
auth.
It's
not
clear
on
which
handling
this
like
on
the
on
the
algorithm
side
and
set
and
put
the
requirements
on
those
things,
so
we're
gonna
see
something
there.
We
need
to
deal
with
so.
B
So,
but
the
main
thing
here
is
that
we
actually
want
to
request
a
working
group
adoption
of
this.
As
we
see
it,
it's
it's
1683.
Do
you
need
an
update
to
resolve
this
length
restriction,
it's
a
good
time
to
actually
update
the
security
algorithm
requirements
and
we
do
have
a
time
frame
from
3dpp
in
some
sense
because
they
want
to
fix
this.
I
think
in
the
in
in
the
current
release,
which
is
by
march
2022,
it's
this
stage
free.
B
So
we
need
to
have
something
ready
that
by
then
basically-
and
we
think
we
can
do
that-
we
have
a
year
and
so
discussion,
we're
gonna
start
sending
out
some
of
the
open
issues
on
the
mailing
list.
We
have
some
more
editorials,
etc
to
work
on
and
we
do
have
using
github
for
this.
If
you
have
source
you
can
submit
all
requests
or
file
issues
on
this
link,
so
corey.
D
A
Okay
well-
and
this
is
this-
is
david-
I
think
I'm
interested
enough
to
find
the
time
to
read
the
draft
magnus.
Let
me
quickly
understand
something:
this
draft
is
the
is
the
anticipated
response
to
the
3gpp
liaison
statement
that
is
supposedly
inbound.
Is
that
correct?
It's
not
supposedly
it
has
arrived.
So
it's.
A
B
Yes,
so
it
showed
up
on
friday
all
right
have
you
managed
to
get
it
posted
on
friday?
It's
just
track
there.
So,
but
yes,.
A
D
A
Next
up
would
be
udp,
options
is
joe
presenting
or
someone
presenting
for
joe.
D
Shirt
to
go
with
I'm
afraid
it's
a
bit
too
cold
up
here,
but
let's
talk
about
udp
options:
can
we
get
the
slides
david?
Where
would
I
find
said,
slides.
A
D
So
this
is
joel's
set
of
updates.
He's
made
changes
since
zero
nine.
He
added
the
unsafe
option,
which
is
specifically
for
use
with
fragmentation.
D
It
tries
to
overcome
the
issues
which
we
talked
about
in
length
two
in
person
ietf
so
a
little
while
ago
now,
and
it's
produced
a
simpler
fragmentation
method
he's
also
integrated
fragmentation,
light
so
they're
no
longer
separate
things
and
he's
revised
the
ocs
pseudocode,
with
more
input
from
rafael
zulu
and
to
fix
the
zeroing
issue
he's
clarified.
The
acs
is
not
dropped
by
default.
D
D
Unsafe
is
basically
there
to
deal
with
a
specific
option
that
follows
another
option
and
we
need
to
judge
the
safety.
So
this
is
the
one
place
where
the
results
of
the
receiving
a
udp
option.
Datagram
doesn't
result
in
the
application
receiving
the
datagram.
So
there
it's
an
important
case
and
joel's
written
text
to
look
at
this
and
it's
in
the
latest
draft.
D
The
main
reason
for
highlighting
this
here
is
the
expected
use
case
by
joe
includes
pns
and
dns
needs
to
send
large
records,
and
this
would
be
the
mechanism
that
would
be
used
if
udp
options
were
used
with
dns.
So
it's
important
that
people
who
have
dns
clue
look
at
the
fragmentation
part
next
slide.
D
Acs
and
ae
have
been
revised,
mainly
revised
in
the
text.
So
not
a
lot
of
surprises
here.
Next
one
option
process
principles
have
been
clarified
and
joe
has
strong
opinions
on
this
and
he's
expressed
those
consistently
on
the
list
and
they're
reflected
in
the
draft.
I
think
I
think
it's
clear,
there's
a
new
issue
and
the
new
issue
is
one
relation
to
path
mtu
discovery.
Again,
it's
a
very
small
thing,
but
joe's
looking
for
clarification.
D
So
there
are
two
different
parameters
and
they
could
be
used
in
two
different
parts
of
the
algorithm
which
one
of
these
is
most
useful,
which
one
of
these
should
be
in
the
spec.
I
ask
the
questions
because
they
are
things
that
joel's
going
to
have
to
ask
on
the
list
to
finish
this.
This
is
the
main
issue.
That's
remaining
next
slide,
there's
also
a
few
pending
changes,
but
these
are
not
thought
by
joe
to
be
significant.
D
He
admitted
that
he
misunderstood
the
way
in
which
rock
309.5
was
specified.
It's
complicated
and
the
text
has
been
updated
with
help
from
carsten
boorman
to
get
the
text
right.
So
the
text
currently
in
the
draft
should
be
correct.
With
respect
to
rock
this
isn't
really
a
change
in
udp
options.
It's
a
change
in
text.
D
The
second
one
is
how
to
address
the
mss
issue.
What
should
be
in
an
mss
option?
What
number
goes
there,
and
if
these
two
things
are
fixed,
then
this
document
is
complete
in
the
respect
of
all
the
issues
that
were
raised
by
the
working
group
when
we
did
the
review,
so
is
there
anything
else
that
needs
to
be
covered
by
this
document
before
it
goes
for
a
working
group?
Last
call
that's
my
brief
summary
of
joe's
slides
I'll,
happily
take
questions.
If
there
are
any.
A
D
A
I
A
A
Okay,
now,
with
a
little
any
any
other
comments
on
this
before
I
go
and
switch
to
nqb,
I
think
we
should
go
frankie
b,
all
righty
here
we
go.
It
takes
a
few
clicks
here.
I'm
getting
better
at
this,
though,
should
be
that
one
yeah,
it's
that
one.
H
A
H
Ahead,
thank
you
be
able
to
hear
me.
H
So
there
have
been
a
couple
of
updates
to
the
nqb
draft
since
the
last
ietf
meeting
draft04,
which
I
uploaded
at
the
deadline
for
the
meeting,
it
covered
most
of
the
changes
that
had
been
discussed
at
the
last
meeting
and
afterward
and
then,
while
I
was
working
on
putting
my
slides
together
for
this
talk,
I
realized
there
was
one
one
of
the
to-do
items
I
had
not
actually
gotten
around
to
doing,
and
so
I
did
that
into
draft205,
which
was
published
just
as
the
servers
opened
again
for
this
week
so
and
in
the
process
did
a
little
bit
of
wordsmithing
as
well
on
draft
05..
H
So
the
draft
4,
the
main
changes
are
first
align
the
terminology
with
rfc
2474
and
cleaning
all
that
up
where
it
talks
about
standardizing,
phps
and
recommending
dsdps
and
not
the
other
way
around
or
some
other
permutation
of
those
terms.
H
I
think
that's
good
now
in
the
draft
there's
also
a
mention
that
you
just
served
was
not
intended
for
n10
usage
and
that's
that's
been
reworked
with
some
help
from
brian
carpenter
on
that
and
then
additional
requirements.
So
this
was
discussed
at
the
last
ietf
around
the
implied
behavior
in
earlier
drafts
that
a
network,
node
or
network
that
doesn't
support
the
php
should
be
aggregating,
nqb
traffic
with
default
traffic,
and
so
now
that's
explicitly
stated
in
the
draft.
H
Now
it's
a
little
bit
odd
to
be
saying
in
a
standards
document.
What
non-compliant
nodes
should
should
be
doing
we're,
adding
requirements
for
for
those
that
don't
support
the
php,
but
nonetheless
I
think
it's
valuable
to
do
so.
I
mean
it
is
really
the
intention
of
the
nqb
code
point
and
traffic
marking
that,
if
it's
not
being
queued
separately
along
the
lines
of
what
the
draft
discusses,
then
it
really
should
be
aggregated
with
default
traffic.
H
And
then
second
piece
was
preserving
the
nqb
marking
and
that's
good
that
that's
going
to
be
word
smith,
but,
like
I
understand.
H
A
H
Well
appreciate
that
and
then
there
there's
around
that
discussion
of
aggregating
with
default
in
the
requirement
or
destroyed
around
that
there
is
a
discussion
around
where
that
is
probably
fine.
Particular
talks
about
shallow
buffered
switches
and
core
network
routers
and
switches
that
are
not
typically
points
of
congestion
and
points
of
cueing
delay
in
in
networks.
H
Next
bullet
removing
a
mention
of
aggregating
network
control
traffic
with
nqb.
This
is
in
the
discussion
of
what
traffic
could
be
aggregated,
potentially
in
a
node
that
supports
the
nqb
php.
What
other
traffic
might
you
want
to
potentially
aggregate
with
nqb
marks?
Traffic
network
control
was
initially
listed
there
and
I
was
asked
to
either
put
a
lot
of
guard
rails
around
that
in
the
text
or
not
mention
that,
and
so
I
took
the
easy
path
of
not
mentioning
it.
H
I
guess
in
the
first
section
there
underlined
this
is
the
new
piece
that
I'd
like
to
spend
some
time
discussing
today,
and
this
came
out
of
reviews
from
a
number
of
folks
in
the
working
group
and
suggestions
on
what
would
make
lives
easier
for
people
to
comply
with
some
of
these
requirements,
and
it
amounts
to
asking
for
two
code
points
to
be
assigned
by
ayanna
and
we'll
go
into
the
detail
on
that
on
the
next
slide
and
then
for
the
draft
five
with
the
new
updates.
H
H
The
goal
is
that
wi-fi
networks
in
the
future
actually
support
the
php,
and
so
that
should
really
should
be
the
recommendation
and
then
dealing
with
the
interoperability
with
existing
networks
as
a
secondary
aspect,
so
that
that's
now
in
the
graph
five,
along
with
a
bit
of
word
smithing
in
the
new
text
that
went
into
draft
form.
A
Let
me
quick
check
where
you
think
the
status
is.
It
looks
like
most
of
the
issues
been
closed.
There's
one
major
issue
on
the
next
level:
two
dscps
and
once
that's
resolved,
plus
a
little
more
text
cleanup.
This
is
ready
for
your
glass
call
correct.
That
is
correct.
H
All
right
so
here
we
go
all
right,
so
two
dscps,
so
we're
we're
trying
to
work
within
the
realities
of
the
world
as
it
is
maybe
not
as
we
wish
it
were
to
be,
and
so
there
are
some
constraints
on
the
selection
of
the
the
code
point
to
be
used
for
nqb
in
order
to
make
it
useful
in
the
near
term,
as
well
as
the
long
term
and
the
two
main
constraints
conflict
with
one
another.
H
The
first
one
is
that
there
are
hundreds
of
millions
of
wi-fi
networks
deployed
around
the
world
that
map
dscp
into
access
categories,
the
the
wmm
access
categories
which
provide
separate
cues
as
well
as
priority,
but
not
quite
separate,
cues
and
and
that
mapping
is
by
and
large,
using
what's
called
the
default
mapping.
H
And
there
is
an
interest
in
ensuring
that
the
nqb
code
point
can
be
handled
in
these
existing
wi-fi
networks
and
that
npb
traffic
can
get
a
separate
queue
from
the
best
effort
default
traffic.
And
so
in
order
to
do
that,
we
have,
since
the
beginning
proposed
that
the
code
point
allocated
for
nqbb
value
42,
which
has
the
bit
pattern.
1
0
and
then
1
0,
1
0,
which
would,
by
default
map
into
the
video
access
category,
actually
any
code
point
with
the
value.
H
The
binary
value,
1,
0
x,
x,
x
x,
would
map
into
the
video
access
category
on
my
file.
So
that's
one
constraint
a
related
constraint
that
that
works
well
with
this
assignment
of
value
42.
H
Is
that
there's
a
lot
of
existing
access
network
gear
that
can
configure
classifiers
to
to
put
traffic
into
different
hues
and
has
a
bit
masking
capability
in
doing
that
that
dscp
matching
and
so
selecting
a
code
point
that
is
maskable
and
and
matches
a
a
set
of
other
code
points
that
are
already
assigned
by
ana
that
are
that
carry
traffic
or
indicate
traffic
that
is
compatible
with
nqb
is
a
distinct
advantage.
H
There
are
a
number
of
applications
today
that
already
mark
their
traffic,
but
with
some
existing
code
points
in
particular,
cs7,
cs5
and
ef,
that
is,
traffic
that
is
compatible
with
nqb
and
selects
either
the
voice
or
video
access
category
and
wi-fi,
and
the
belief
is
that
continuing
to
support
those
or
supporting
those
applications
in
networks
that
want
to
implement
the
npb
code
point
would
be
facilitated
by
selecting
a
code
point
for
nqb
that
can
be
easily
grouped
with
some
subset
of
those
three
code
points.
A
Minor
note
here,
use
cs5
and
ef
is
one
of
the
examples.
Applications
should
not
be
marking
cs7,
because
most
diffserv
boundaries
have
to
bleach
cs7
or
to
protect
the
routing
protocols.
H
Yeah
and
the
context
for
for
that
list
really
is
in
end
user
networks,
home
networks.
M
L
H
So
dealing
with
the
reality
of
yeah
usage
in
in
home
networks,
but
point
taken
the
the
next
rationale
there
that
conflicts
with
the
first
one
is
that
across
interconnections
it
was
pointed
out
that,
particularly
for
network
networks
that
run
mpls.
H
Cores
that
traffic
has
to
be
aggregated
or
dhcps
have
to
be
aggregated
in
order
to
fit
into
the
available
mpls
traffic
categories
and
that
nqb
traffic
could
very
easily
be
treated
the
same
as
default,
which
would
be
the
the
intention
in
a
core
network
in
a
lot
of
cases.
H
So
and
if
it
were,
if
such
a
code
point
were
selected,
then
those
mpls
core
networks
and
transit
networks
could
very
easily
carry
the
nqb
code
point
through
unbleached
and
so
that
both
of
those
are
desirable
properties
that
would
enable
end-to-end
usage
of
nqb
in
the
near
firm.
H
So
that
leaves
us
with
these
two
conflicting
constraints
around
the
assignment.
Again,
one
being
that
the
code
point
is
binary,
one:
zero,
xxx,
the
other
one,
that
it's
a
binary:
zero:
zero,
zero
xxx.
H
H
The
top
three
bits
of
the
code
point
that
is
actually
already
a
pathology,
that's
in
place
in
some
parts
of
the
internet,
and
so
naturally,
dhcp
42,
mark
traffic
would
become
the
cp2
in
some
cases
and
in
our
case
that's
an
easy
effects
or
easy
easy
change
to
make
in
the
in
the
dhcp,
and
so
the
way
that's
kind
of
structured
in
the
draft
is
that
end
hosts
applications
essentially
mark
traffic
is
42.
H
as
they
send
you.
The
the
host
is
the
the
entity
that
understands
its
ending
behavior
and
understands
whether
it's
complying
with
the
intention
of
the
mqb
code
point
and
the
php,
and
so
it
marks
at
42
and
then
that
then
traverses
home
networks
and
wi-fi
links
and
gets
the
appropriate
treatment
there.
It's
this
benefit
on
access
networks
of
having
the
value,
42
and
then
somewhere
prior
to
interconnection.
H
H
You
know
a
peer-to-peer
kind
of
communication
as
well,
but
that
is
the
the
gist
of
it
and
that's,
I
think
the
main
discussion
point
today
is
your
concerns
or
thoughts
about
the
concept
of
having
two
dscps
to
deal
with
this,
these
two
constraints
and
then
the
specific
values
of
the
code
points.
I
think
you
know
42
and
two
is
maybe
a
second
theory
topic
that
we
should
touch
on
as
well.
H
So
I
guess,
if
anyone
has
feedback
on
this
two
dscp
concept,
any
concerns
with
that.
A
Okay,
do
you
want
to
get
do
you
want
to
do
the
discussion
now
we're
going
to
get
through
the
rest
of
your
slides,
we're
a
little
tight
on
time
as
usual,.
H
A
Okay,
next
slide
and
just
the
other
thing
is,
we
need
to
figure
out
where
to
put
in
the
honest
presentation
on
dscp2
measurements.
A
H
So
this
is
just
to
say
everything
that
we
identified
the
last
ihf
to
do
is
either
done
or
this
we
decided
not
to
do
it.
Checklist,
checked
next
and
then
discussion,
so
okay
with
two
dscps
and
then
which
ones
and
so
see
anna's
talk
which
has
some
interesting
insight
into
that
topic.
And
then,
where
do
we
go
from
here
on
the
draft.
A
All
right,
so
something
we're
going
to
do
is
get
anna
up
to
talk
about
dscp2
and
then
come
back
to
this
for
some
more
general
discussion
and
try
to
watch.
Try
try
to
watch
the
clock
while
we're
doing
that.
Okay,
hang
on!
Where
are
all
these
windows.
I
N
Great
yeah,
so
hi,
I'm
anna,
I
work
with
gory
fairhurst
at
the
university
of
aberdeen.
I
will
talk
to
you
today
about
some
measurement
data,
new
measurement
data
that
we
have
around
the
code
points
for
t2
and
2
that
are
proposed
in
the
in
the
mqb
draft
that
greg
just
presented.
N
So
if
we
could
go
on
to
the
next
slide,
please
the
data
is
is
is
new
as
it
addresses
some
gaps
there
is.
There
already
is
some
literature
about
the
traversability
of
code
points,
including
42
and
2,
but
only
in
the
core
of
the
internet,
and
all
of
that
is
based
on
on
active
measurements.
So
you
generate
traffic
with
some
dhcp
and
then
you
set
it
out
in
the
internet,
and
you
look
at
what
comes
out
of
the
other
side
and
what
changes
you
see
at
every
hop
in
the
path.
N
But
today
what
we
are
going
to
be
looking
at
is
passive
data
in
the
core
of
the
internet.
I
mean
actual
traffic
in
the
wild,
and
this
is
this
is
a
data
set
that
is
provided
by
keda.
N
We're
also
going
to
be
briefly
looking
at
a
set
of
edge
measurements
that
are
done
from
ripe
atlas
probes
in
the
past.
We've
not
had
that
much
information
on
edge
networks
and
finally,
we've.
I've
looked
at
a
few
sets
of
code
points,
primarily
dhcp's,
40
2,
but
then
a
couple
of
other
pairs
that
would
fulfill
the
criteria
that
that
grid
just
talked
about
that
is
also
specified
in
the
aqb
draft.
N
So
if
you
could
go
on
to
the
next
slide,
I
will
try
to
keep
this
as
short
as
I
can
so,
the
passive
data
this
is
provided
by
keda.
It
comes
from
a
monitor
that
sits
somewhere
in
a
data
center.
It
collects
all
the
traffic
on
a
bad
bull
link,
backbone
link,
rather,
where
a
tier
one
isp
peers,
the
traffic
is
anonymized,
all
of
the
payload
is
removed,
and
what
we
are
left
with
with
is
ip
headers
and
transport
headers
as
well.
So
we
can
look
at
the
dscp
markings.
N
N
N
And
yes,
here
is
a
table
that
analyzes
what
the
scps
were
seen
on
all
of
these
packets
we
looked
at,
and
I
pay
particular
attention
to
those
that
are
proposed
in
the
nqb
draft.
So,
as
you
can
see
in
the
table,
I've
split
the
traffic
per
year
per
direction.
The
the
traffic
is
bidirectional
and
also
per
protocol,
as
in
ipv4
versus
ipv6.
I've
not
split
it
per
transport.
N
N
In
fact,
this
can
be
as
much
as
90
percent
of
all
traffic
carries
this
particular
mark.
This
is
not
a
trivial
amount
of
traffic
and
we'll
explore
why
this
happens
in
a
later
slide,
but
something
else
to
notice
here
is
that
all
of
the
other
codes
don't
appear
code
points
rather
don't
appear
nearly
as
much
as
codepoint2,
and
this
includes
chord
point
42,
which
is
proposed
in
the
nqb
draft.
That's
a
good
thing.
N
It
means
nothing
uses
it,
but
also
in
all
of
for
all
of
the
other
sets
of
chord
points
that
we
used
as
we
we
looked
at
like
44
and
4
and
46
and
6
they
don't
appear,
they
only
appear
for
a
fraction
of
the
traffic.
N
So
the
key
takeaway
from
here
from
the
slide
is
that
on
this
particular
link,
a
lot
of
the
traffic
ends
up
carrying
the
same
code
point
that
is
proposed
for
nqb
traffic
and
because
we
see
it
in
both
directions
and
from
different
prefixes.
N
N
So
if
we
could
go
on
to
the
next
slide,
which
talks
about
the
tests
that
we
did
at
the
edge,
so
we
did
this
test
on
the
ripe
atlas
platform,
which
has
geographically
distributed
probes
and,
in
fact,
in
the
picture
that
you
can
see
on
your
screen
right
now.
These
are
all
the
the
probes
that
participated
in
the
measurement
and
from
all
of
these,
we
sent
tcp
traffic
marked
with
dscp42
towards
our
own
server
at
the
university
of
aberdeen,
and
the
goal
here
was
to
understand
what
remarking
happens
along
a
path.
N
Note
that
this
is
a
trace
route
measurement,
so
we
can
actually
see
what
happens
at
each
hop
and
what
we
find
out
is
that
not
much
remarking
happened
happens
at
at
the
first
stop,
so
in
the
edge
network
where
the
probe
is
with
only
about
five
percent
of
all
of
the
dhcps
are
zeroed
there,
but
by
the
time
the
packets
make
it
to
our
server
to
the
end
of
the
path
the
scp-42
survives
only
on
about
in
about
20
percent
of
traffic,
so
on
around
20
percent
of
the
path
percent
of
the
paths.
N
Rather,
we
also
see
that
about
seven
percent
of
packets
have
the
first
three
bits
of
the
field
zeroed
out,
so
this
is
basically
toss
bleaching,
so
they
arrive
at
the
destination.
Is
the
cp2,
which
is
the
other
proposed
code
point
for
nqb
and,
interestingly,
you
see
about
three
percent
of
them
that
have
the
last
three
bits
as
opposed
the
first
three
bits
zeroed
out,
which
results
in
code
point
40
or
cs5.
N
N
However,
on
the
majority
of
paths,
this
is
not
the
case
on
about
60
percent
of
the
past.
Packets
have
the
entire
field
zeroed
out,
so
by
the
time
they
they
reach
the
destination,
they
carry
the
sap
zero
and
this
corresponds
to
best
effort.
N
So
if
we
move
on
to
the
next
slide,
what
do
we
learn
from
all
of
this
data?
N
Well,
I
just
mentioned
that,
where
edge
and
edges
edge
networks
are
concerned,
you
see
a
lot
of
bleaching
and
resulting
in
code.0,
but
the
keta
data
results
were
surprising
because
now,
we've
we
know
of
at
least
one
backbone
link
we're
using
a
code
point
where
codepoint2
is
used
and
appears
on
a
lot
of
the
traffic,
and
this
is
most
likely
due
to
the
toss-
precedence
bleaching
on
many
packets
that
maybe
have
arrived
from
various
edge
networks
carrying
the
sap,
such
as
af-11
or
f21,
or
31
or
41,
that
toss
bleach
to
the
value
2..
N
So
what
I'm
trying
to
say
is
that
you
have
these
popular
chord
points
like
af,
11
and
21
that
have
established
semantics,
which
end
up
at
the
other
edge
s2,
because
because
of
how
popular
they
are
and
because
there's
a
lot
of
because
the
practice
of
toss
bleaching
is
still
quite
widespread,
I'm
guessing
this.
This
might
mean
that
you
have.
You
could
have
potentially
a
lot
of
q
building
traffic.
That
may
be
remarked
as
nqb,
and
that's
the
only
implication
here,
but
we
also
saw
that
codepoint42
is
not
used.
N
So
all
of
these
kind
of
should
be
kept
in
mind
when
you
assign
new
ones
and
me
and
gory
and
another
one
of
our
colleagues
from
the
university
of
aberdeen
wrote
an
internet
graph
that
attempts
to
provide
some
input
on
what
pathology
remarking
pathologies
exist
and
what
other
semantics
exists
with
regards
to
code
points
and
we're
at
the
stage
where
we'd
love
any
input
on
this.
Thank
you
very
much.
N
H
Okay,
thanks
anna.
This
is
definitely
really
good.
Useful
work
for
helping
help
me
select
code
points
here
for
nqb.
H
H
It
looks
like
5
is
not
used.
Not
it
was
not
seen
heavily.
There
were
a
couple
of
instances,
I
guess
the
direction
b,
both
2018
and
2019,
where
there
was
a
fair
amount
of
code
0.5,
but
in
other
cases
much
less
and
the
value
45
is
available
in
the
assignment
pool
as
well.
H
H
A
Interjecting,
as
a
chair
before
going
congratulating
the
next
person
in
line
voice,
admit,
is
definitely
out
of
the
question.
However,
ef
is
intriguing,
it
might
be
plausible,
since
nqb
traffic
doesn't
build
cues.
A
H
Yes,
interesting
document
responding
to
that,
the
you
in
existing
wi-fi
networks,
ef
and
45
and
42,
and
all
those
which
we've
been
talking
about
and
that
upper
range
would
go
into
the
same
access
category,
and
so,
from
that
perspective
it
would
be
equivalent
and
then,
if
in
a
further
network,
hop
ef
gets
aggregated
with
nqb
traffic,
either
because
they're
in
different
code
points
and
they
get
classified
together
or
because
they
share
the
same
code
point.
That
would
be
fine
too.
H
The
concern
I
think
I
would
have
is
that
recommendations
around
future
wi-fi
support
for
nqb
versus
ef
and
ef
is
generally
considered
traffic.
That
should
be
prioritized
in
networks,
whereas
nqb
is
explicitly
not
supposed
to
be
prioritized,
and
so
the
recommendation
for
future
wi-fi
nodes
is
to
provide
a
separate
queue
in
the
best
effort
access
category
for
nqb,
and
is
that
what
we
would
want
to
recommend
for
ef
traffic
as
well.
A
Okay,
just
want
to
raise
possibility,
vd
go
ahead.
O
O
Hello,
can
you
hear
me?
Yes,
yes,
okay,
cool,
a
question
for
greg,
so
for
in
the
nqb
draft
I
haven't
read.
The
draft
I
just
saw
the
slides
right
now
is
there
is
a
recommendation
to
for
the
edge
to
use
to
bleach
any
of
these
42,
44
or
46
to
2
instead
of
zero
so
that
it
can
be
utilized
for
the
nqb
traffic
on
the
downstream?
I
H
Here
the
intention.
I
H
There
we
go
okay,
good!
Thank
you.
Yes,
the
intention
is
that
we
enable
the
pass-through
of
this
code
point
end
to
end,
and
we
do
whatever
we
can
to
ensure
that
that's
possible.
H
Yesterday,
the
vast
majority,
if
not
all
isps
particular
residential
customers,
bleach
the
code
point
to
zero
or,
to
some
other,
you
know
fixed
value,
most
often
zero,
and
so
the
recommendation
in
the
draft
is
that
it'd
be
carried
all
the
way
through
and,
as
the
diagram
shows
you
know,
is
42
in
the
home
network
segment
yeah
for
traffic,
both
upstream
and
downstream
to
the
user.
H
H
That
might
happen
if,
if
traffic
is
not
being
policed
and
monitored,
and
your
random
traffic
comes
into
the
isp
network,
marked
with
this
low
value,
say
two
or
five,
and
if
that's
the
last
that's
chosen,
and
so
it
recommends
that
unless
the
operator
has
implemented
some
safeguards
to
prevent
that
from
happening,
that
they
leave
the
code
point
at
the
low
value
so
that
the
traffic
stays
in
the
best
effort
access
category
on
wi-fi.
But
the
extent
that
the
the
isp
is
supporting
the
php
and
supporting
those
safeguards
then
yeah
yeah.
H
The
intention
is
that
it
is
42
both
for
upstream
traffic
and
downstream
traffic
in
the
customer's
home
network.
A
Right
now,
there
is
a
risk
there
in
on
this
data,
which
is
that
there
is
existing
use
of
code,
0.2
traffic
on
the
observed
on
the
backbone
and
that
will
get
up
marked
to
42,
even
though
it
didn't
start
out
as
42.
yeah.
Exactly
gloria.
D
D
The
other
option
might
be
that
after
thinking
through
this,
that
greg
wants
to
try
and
propose
a
different
pair
of
dscps,
and
then
I'm
wondering
perhaps
if
we
could
have
a
little
interim
or
something
before
the
next
ietf
to
discuss
the
different
option.
If
one
emerges,
so
we
weren't
kind
of
clocked
by
ietf
meetings
on
assigning
a
diff
serve
called
point
yeah
if
it.
If,
if.
A
It
gets
confusing
enough.
An
interim
would
make
up
would
make
a
whole
lot
of
sense,
but
I
think
it's
definitely
possibilities
anna.
You
want
to
take
the
last
word
on
this,
and
then
we
need
to
move
on.
N
No,
I
just
I
just
had
a
thought,
because
I
think,
whichever
route
you
go,
whichever
pair
of
code
points
you
have,
will
you
do
you
not
need
to
have
some
sort
of
protection,
just
in
case
that
q
building
traffic
actually
ends
up
in
the
nqbq,
regardless
of
what
of
what
code
points
are
used?
So
if
you
have
such
a
box
and
this
box
is,
is
in
the
isp
network,
perhaps
you
don't
actually
need
to
choose
a
different
pair
of
code
points
from
40
to
12.
L
D
M
D
D
D
Yeah,
as
we
start
the
individual
drafts,
let's
do
a
heads-up
display
of
the
satellite
one
and
then
move
through
robin
and
then
finally
back
to
the
the
final
sites.
Okay,
so
tom,
please
press
your
mic
and
talk
for
two
minutes.
D
P
And
we're
not
getting
audio
now
you're
getting
audio
go
for
it.
Okay
next
slide,
please
so
nicholas
gory,
emil
and
john
had
a
draft
that
was
targeting
quick
where
they
looked
at
satellite
considerations
for
the
quick
protocol
and
part
of
that
was
giving
something
that
was
testable
by
implementation,
so
that
satellite
wasn't
left
out
of
the
story.
P
Gauri
asked
me
to
to
look
at
this
draft
to
try
and
align
the
text
with
rfc
2488
and
instead
we,
as
a
group
of
authors,
decided
that
the
document
would
be
better
suited
just
approaching
transport
protocols
generally
and
what
they
need
to
get
from
from
satellite
and
what
satellite
deployment
does.
There
are
two
documents
in
the
rc
series
that
really
cover
satellite
use
cases
2488
and
2760.
P
They
both
came
from
the
tcp
sap
working
group,
which
concluded
in
2000
and
since
2000
geo
satellite
services
become
massively
faster,
there's
just
a
lot
more
capacity
available
and
the
considerations
in
these
documents
were
sort
of
superseded
by
split
tcp,
implementing
the
things
they
discussed,
and
so
the
split
tcps
are
implemented
with
peps
and-
and
this
works
great
for
tcp,
most
tcp
connections
don't
actually
realize
they're
going
over
satellite
because
they
have
the
protocol
split
down
and
satellite
actually
works
quite
well.
Apart
from
for
latency
critical
tasks.
P
The
problem
we
have
is
that
peps
are
a
deployment
barrier
for
new
features
for
tcp
and
they
are
impractical
to
deploy
for
for
quick
or
or
with
vpns,
and
we're
starting
now
to
see
new
satellite
systems
that
are
actually
getting
prominent.
P
So
we're
seeing
a
lot
of
leo
stuff
come
up
and
we're
seeing
neo
and
there's
a
big
case
with
hybrid
operations
with
5g,
and
so
we
want
to
create
an
update
to
2488
and
the
advice
of
2760
and
document
the
relevant
transport
character
characteristics
of
these
satellite
networks,
so
that
we
can
give
advice
for
implementers,
and
so
we
can
design
and
test
and
verify
that
code
will
work
well
and
work
well
in
these
different
cases.
P
But
what
we
really
want
is
input
in
leo
and
mio
and
then
input
from
satellite
network
operators,
application
platform
operators
and
protocol
implementers
so
that
we're
giving
the
best
advice
so
that
the
satellite
use
cases
are
understood.
So
I
just
like
to
ask
everyone
the
working
group
to
read
the
document
and
provide
feedback,
we'll
take
feedback
on
the
mailing
list
individually,
and
we
also
have
a
github
and
I'll
post
a
link
to
the
github
in
the
chat,
and
that
is
all
I
want.
So
please
please.
A
Please
please
read
and
comment
on
the
draft
to
the
list
and
or
to
and
or
to
the
authors.
Okay,
next
up
is
once
I
let
me
go
find
it
is
q
log,
and
I
would
ask
both
of
the
next
main
two
presenters
to
try
to
do
it
in
about
10
minutes
each
sorry
we're
squeezed
on
time
robin
go
for
it.
F
Yeah,
if
I
can
have
slides,
hang
on.
A
Just
a
minute,
I
need
to
go.
Yes,
you
do
need,
you
do
need
to.
F
Excellent,
so
thanks
for
giving
me
a
little
bit
of
time
to
talk
about
q
log
again,
which
has
been
discussed
in
in
tsv
area
before
and
also
throughout
the
week,
so
next
slide.
Please
q
log
started
as
as
the
quick
login
project
intended
to
make
it
easier
to
to
analyze
and
debug
quicken
http
3.
next
slide.
F
This
is
because
what
you
would
normally
do
for
something
like
tcps.
You
would
take
a
packet
capture
somewhere
and
use
something
like
wireshark
to
analyze
that
you
can
still
do
that
with
quick,
but
it's
a
bit
more
difficult
next
slide,
because
quickl,
of
course,
almost
entirely
encrypts,
also
its
transport
level
metadata.
So
to
do
that,
you
would
have
to
store
the
entire
packet
capture,
which
gets
quite
large,
and
you
would
also
need
to
store
the
decryption
secrets,
which
is,
of
course
terrible
for
privacy
and
there's.
A
second
important
aspect
to
this
next
slide.
F
Indeed,
is
that
not
everything
about
the
protocol
is,
of
course
sent
on
the
wire,
especially
things
like
just
control
parameters
are
typically
not
analyzable
in
that
way.
So
for
quick,
reproposed
next
slide
a
new
approach.
Instead
of
doing
a
network
capture,
we
would
capture
at
the
end
points
directly
from
the
implementations
and
qlog.
There
is
the
idea
that
we
can
have
a
single
format,
a
single
schema
that
is
used
across
the
different
implementations,
so
everyone
logs
in
the
exact
same
way.
This
enables
us
to
create
reusable
tooling
in
a
much
more
straightforward
fashion.
F
F
F
Tcp
trace
alike
tool
to
help
debug
congestion
and
flow
control
issues
in
the
protocols
next
slide.
Bishop
pros
has
worked
quite
well
within
quick
with
the
majority
of
the
implementations,
actually
output
in
this
single
format
and,
for
example,
facebook
actually
using
it
in
production
at
scale
as
well
to
to
monitor
their
actual
quick
deployments
next
slide.
F
Up
until
now,
q
log
has
been
two
individual
drafts,
and
so
because
of
this
this,
I
would
say
proof
that
it
can
work
in
practice.
We
will
probably
adopt
it
in
a
quick
working
group
within
the
next
couple
of
months
as
part
of
their
recharter.
F
So
a
main
goal
of
that
is,
of
course,
flashing
this
out
for
quick
and
hp3,
but
the
main
reason
that
I'm
here
today
and
other
working
groups
this
week
is
because
we
also
envision
qlogs
to
be
useful
for
many
other
protocols
as
well.
F
This
basic
concept
of
just
using
a
structured
standard
format
at
the
endpoints
can
be
useful
in
many
different
situations,
and
we
actually
have
pilot
projects
running
for
for
the
ones
that
we
that
have
listed
there
below,
for
example,
tcp
is
an
obvious
target
there,
where
we
are
extracting
some
events
using,
for
example,
evpf
from
the
kernel.
There
are
also
many
people
interested
in
doing
this
from
multibots,
tcp
and
quick,
of
course,
because
these
can
get
quite
difficult
to
to
debug
and
fine-tune
in
practice
next
slide
this.
F
This
goal
of
making
q
log
usable
for
more
protocols
is
actually
already
visible
in
the
current
drafts.
We
have
the
event.
Definitions
for
quick
and
industry
are
separate
from
what
we're
calling
the
main
schema,
which
kind
of
has
the
protocol
agnostic
stuff
of
the
format,
and
the
hope
is
that
this
can
grow
to
a
framework
or
a
set
of
guidelines
that
people
can
use
to
define
new
types
of
schemas
for
different
protocols
next
slide.
F
If
you
want
to
do
this,
we're
of
course
going
to
have
quite
a
few
challenges
ahead
of
us,
which
is
one
of
the
reasons
again.
I'm
here
today
in
the
hopes
that
some
people
might
have
thoughts
or
feedback
on
these,
I'm
going
to
highlight
just
three
of
them
just
just
to
give
you
an
idea
of
what
we
might
be
talking
about
next
slide.
F
So
one
of
the
things
is
that
a
simple
thing
to
do
would
be
to
map
the
wire
image
that
you
would
get
101
to
the
format.
For
example,
here
you
have
a
selective
acknowledgement
missing
the
packet
number
16.,
but
this
doesn't
necessarily
reflect
what
the
implementation
is
actually
doing.
It
might
perfectly
be
that
packet
number
16
isn't
immediately
declared
as
lost,
and
so
we
need
a
second
type
of
of
events
which
you
can
see
on
the
right
side
to
actually
reflect
that
separately.
F
The
second
main
challenge
next
slide
is
on
the
serialization
format
here
we're
currently
using
json,
mainly
because
it's
flexible,
but
it's
also
not
the
most
performant
option,
even
though
it
is
kind
of
usable,
for
example,
used
by
facebook,
but
so
also
in
the
drafts.
We
kind
of
acknowledge
that
we
might
want
to
use
different
things
in
jsons
we
have
our
own
data
type
definition
language
there
to
describe
the
events,
which
is
what
you
can
see
on
the
right
side.
F
But
we
would
like
to
really
move
to
something
more
officially
supported
by
the
ietf,
with
the
goal
of
automatically
generating
serializers
or
dc
realizers
for
different
programming
line,
which
is
based
on
this.
To
make
deploying
this
easier,
we
would
also
like
to
get
some
insight
into
if
people
would
use
this,
what
type
of
processing
or
collection
pipelines
they
would
typically
want
to
use
which
will
help
guide
the
correct
use
of
the
format.
F
So
what
we
envision
now
is
to
have
like
a
set
of
standardization
levels
defined
with
concrete
guidelines
on
how
to
hash
or
obfuscate
certain
fields
that
people
can
then
map
to
individual
things.
F
Our
hope
is
that
if
this
works
quite
well,
and
we
can
scrub
this
for
most
privacy
sensitive
information,
we
can
also
start
to
think
about
actually
actively
sharing
full
qlik
data
sets
or
individual
cue
logs
for
additional
troubleshooting,
which
of
course,
leads
to
a
whole
bunch
of
new
issues
that
might
be
interesting
to
discuss.
So
a
final
slide.
F
A
E
Yes,
thanks
robin
just
to
just
be
crystal
clear
about
the
the
action
items
I
think
come
out
of
this.
As
you
know,
this
court
group
is
basically
a
community
of
components
for
a
bunch
of
protocols.
E
I
would
first
of
all
encourage
all
of
you
to
think
about
the
applicability
of
this
your
protocol,
particularly
if
it
runs
over
some
sort
of
crypto
like
scp
over
dtls
or
what
have
you.
Secondly,
if
you
think
about
how
to
apply
this
to
your
protocols,
you
may
have
some
input
into
the
main
schema
and
number
one
you'll
probably
have
to
come
to
quick
to
participate
in
that
discussion.
E
But
if,
if
we
see
a
lot
of
immediate
interest
in
applying
this
to
more
protocols,
we
might
take
that
and
bring
it
to
another
venue
for
the
core
schema,
not
the
quick,
specific
events
but
but
the
core
schema.
So
that
would
be
very
useful
input
quickly.
If
there's
a
lot
of
of
immediate
interest
in
this,
but
we're.
E
Because
we
want
to
move
this
forward
and
quick
as
a
venue
where
there's
obviously
is
an
interest
of
course.
That
is
a
follow-on
you
could
do.
Your
own
draft
in
whatever
working
group
is
appropriate,
this
one
for
a
bunch
of
protocols,
obviously
using
the
base,
schema
and
then
applying
the
events
relative
to
your
protocol.
So
I.
E
Really
a
lot
of
people
here
to
start
thinking
about
this
and
and
seeing
if
there's
seeing
if
they're,
if
they
can
start
thinking
about
how
to
reply
and
where
and
what
they
need
to
do
in
relatively
short
order.
Thanks.
Q
Yeah,
I
was
just
going
to
quickly
say
that
I
think
that
keeping
it
in
quick
for
the
time
being
is
a
good
thing
and
if
we
spin
it
out
to
a
working
group,
we
might
want
to
look
a
bit
further
and
look
into
how
you
actually
manage
the
quick
server,
not
just
the
output,
but
how
you
apply
feedback.
So
I
think
it
probably
is
bestest
place
in
part
in
a
different
context,
but
not
one
that
we
should
be
looking
at
now.
A
Okay,
and
with
that,
thank
you
very
much
and
we're
gonna
move
on
to
last
one
of
the
session.
Let
me
make
sure,
oh
boy,
make
sure
I
click
in
the
right
place
and
we'll
get
the
right
material
up
jonathan.
How
do
you
want
to
handle
this?
Do
you
want
to
go
through
the
slides,
or
do
you
want
to
pick
up
where
map
rg
left
off.
J
I
think
we
just
pick
up
where
we
left
off.
If
anyone
has
questions,
we
should
try
to
answer
those
and
then
go
on.
A
J
D
D
M
Yes,
it
is,
there
is
a
there,
is
a
link
to
the
repo
and
it's
just
a
script
that
can
run
on
any
any
linux
router.
We
used
it
up
to
a
slash,
16
subnet,
but
there's
800
some
odd
ips,
I'm
not
sure
how
far
it
can
scale,
but
certainly
beyond
this
but
yeah.
We
need
to
collect
more
data
this.
This
was
collected
over
a
fairly
long
time,
three
weeks
but
800
some
ips,
isn't
you
know
it
is
a
relatively
small
installation.
J
And
probably
the
unique
thing
here
is
that
we
have
a
distinction
between
parts
where
we
know
there's
an
aqm
and
a
larger
number
of
parts
where
we
know
that
there
isn't
an
aqm
within
the
isp.
A
Okay,
I
don't
think
those
slot
all
right,
we'll
let
you
share
the
screen.
You
saw
the
guidance
I
sent
you
on
what
to
try
to
cover.
Okay,
oh
hang
on.
I
have
to
stop
sharing
my
screen
in
order
to
get
your
allow
you
to
share
there.
We
go.
J
J
J
J
Now,
I'm
not
going
to
apply
the
aerospace
risk
model
to
the
internet.
That
would
be
absurd,
but
if,
for
example,
a
systemic
congestion
collapse
event
occurred
or
the
root
dns
surface
or
went
down
at
once,
that
would
be
a
catastrophic
level
event
in
internet
terms
and
that's
why
those
servers
are
managed
by
a
decidedly
paranoid
and
very
international
group
of
trustees
at
the
opposite
end
of
the
scale.
A
single
packet
loss
is
something
that
internet
protocols
can
usually
recover
from
very
quickly,
so
would
be
classed
as
trivial.
J
J
J
J
This
seems
consistent
with
many
subscribers
having
both
apple
and
non-apple
devices
in
the
same
household
and
mostly
using
the
non-apple
ones
for
internet
traffic,
we
can
only
easily
observe
aqms
on
ect
flows
that
drive
an
aqm
bottleneck
to
saturation,
so
this
small
proportion
of
ect
flows
was
less
than
ideal,
but
we
were
able
to
observe
aqm
activity
on
sixty
percent
of
parts.
It
had
a
known
aqm
internal
to
the
isp
and
on
ten
percent
of
parts
that
did
not.
J
J
So
here
is
a
serious
question:
fating
facing
this
working
group,
given
a
major
severity
risk
that
could
show
up
on
10
percent
of
powers
at
least
several
times
a
month.
Is
that
acceptable
to
inflict
on
innocent
bystanders?
In
particular,
I
would
say
not,
but
I'm
only
one
voice
and
let
me
be
clear:
existing
networks
and
their
users
are
innocent
bystanders.
J
J
J
A
R
Hi
there
can
you
hear
me?
Yes,
yes
yep.
I
I
appreciate
jonathan,
that
you
know
you're
trying
to
prove
a
point
here.
What
seems
fairly
sort
of
incongruous
to
me
is
that
this,
this
risk
analysis
that
you
talk
about
here
was
never
done
when
fq
is
deployed.
A
J
Wouldn't
it
be
reasonable
to
supply
suppose
that
the
impact
of
a
max
min
fairness
enforcement
would
be
limited
to
minor.
A
R
A
A
Thank
you
all
very
much
we'll
see
you
all
on
wednesday.