►
From YouTube: IETF108-TSVWG-20200728-1410
Description
TSVWG meeting session at IETF108
2020/07/28 1410
https://datatracker.ietf.org/meeting/108/proceedings/
A
B
Yeah,
I
suppose
I
have
things
set
up
with
a
room
mic
as
opposed
to
a
head,
as
opposed
to
a
headset
bike.
But,
yes,
I
think
audio
is
working.
I
see
gory
out
there,
let's
check.
B
Right
so
I
guess
I
get
to
run
the
chair
slides,
so
welcome
to
the
transfer
area
working
first
transfer
working
group
meeting
session
at
ietf
108
online.
I
want
that
window,
okay,
cool.
This
is
the
note.
Well,
if
you
haven't
seen
it
before,
please
read
it.
It
applies
to
everything
that
happens
in
in
this
in
this
meeting.
B
Okay
need
a
note
taker
and
a
jabber
scribe.
Most
important
person
we
need
is
a
jabber
scribe
and
recommendation
here
is
to
run
jabber
in
a
separate
window.
So
you
can
so
you
can
join
the
mic
queue
and
monitor
the
jabra
session.
At
the
same
time,
david
spencer
has
volunteered
to
be
jabber,
scribe
magnificent
and
for
notetaker.
I
think
michael
scharf
has
volunteered
to
do
his
note-taking,
but
in
practice,
folks,
what
I've
done
is
I've
pasted
the
entire
agenda
into
the
shared
error.
B
The
shared
note-taking
application,
which
is
now
kodi
md,
is
replaced
pad
please
type
in
there,
we're
not
after
all
the
blow
by
blow.
We
really
do
need
to
record
anything
significant
that
we
that
we
decide
upon
okay.
So
this
is
a
new
meat.
Echo
experience
for
most
of
us.
A
few
tips
separate
tabs
and
windows
may
be
easier
to
use
for
meeting
notes
so
that
you.
D
Where
did
I
stop
speaking
almost,
I
would
say
45
seconds
ago,
it
feels
like
all
right.
Let
me
let's
see,
and
you
have
videos
as
well.
Yes,
yeah,
that's
good.
B
B
Picking
up
from
there
david
all
right
notes
being
typed
into
the
online
tool,
so
I
must
have
been
on
okay.
I
must
have
been
back
back
here
anyhow,
so
we've
got
a
javascribe.
We've
got
note
taker,
please
feel
free
to
read
the
online
tool.
I
just
dropped
the
agenda
in
there
hang
on.
Let
me
see
if
I
can
get
I'm
having
trouble
with
multiple
screens
demonstrating
how
much
fun
this
this.
This
is.
B
Okay,
some
meat,
echo
usage
tips
for
jabber
and
the
note
separate,
windows
or
tabs
are
really
good
idea
to
keep
meat.
Echo
focused
on
speakers
slides
and
queue
particular
particular
for
for
chat.
A
separate,
jabber
client
helps
a
lot
in
that
allows
me
to
echo
to
stay
on
the
speakers
in
queue.
Please
use
the
microphone
queue
for
in
meet.
Echo
click
the
hand,
microphone
icon
with
a
hand,
not
the
one
with
the
triangle
that
way.
B
You'll
join
the
mic
cue
and
the
chairs
will
turn
on
your
audio
to
to
recognize
you.
Please
don't
send
video
in
meat
echo,
it
might
work,
but
me
had
problems
with
multiple
video
displays
during
testing
and
we
just
assumed
not
not
not
invite
the
problems
to
rear
them
to
to
show
up
in
this
session,
chairs
will
display
all
slides
for
this
meeting
document
review
request.
Please,
folks.
Draft
reviews
are
how
how
the
ietf
gets.
It
gets
work
done.
B
So
please
review
documents
here
and
in
another
working
group.
If
you'd
like
documents,
you
care
about
reviewed,
please
please
continue
by
reviewing
other
documents:
okay,
accomplishments
and
status.
B
I've
gone
back
two
ietfs
here
back
to
singapore,
we
have
three
rfg's
been
published
since,
since
singapore,
these
are
the
two
ford
error,
correction,
rfcs,
plus
the
tiny
mt-32
pseudo
rng
rfc.
Does
that
that
supports
the
sliding
window
mechanisms,
big
progress,
the
our
draft
that
is
part
of
the
infamous
webrtc
draft
cluster
is
now
not
only
an
auth
48,
it's
in
off
48
done,
and
we
got
the
updates
for
the
lephb
into
that
draft.
B
So
the
transport
area
is
no
longer
on
the
critical
path
for
finally
getting
all
the
web
rtc
drafts
published
as
rfcs.
Many
thanks
to
everybody
for
the
patients
sticking
with
them.
I
think
this
draft
has
spent
about
four
years
at
the
rfc
editor,
which
is
not
a
record
that
we
want
to
try
to
try
to
beat
in
the
future.
B
B
There
are
no
ids
at
the
iesg,
yet
we
have
three
internet
drafts
with
working
group
chairs
and
authors
post
working
group
last
call
the
two
ecn
encapsulation
drafts
bob,
and
I
need
to
put
our
heads
together
offline
and
come
up
with
some
fragmentation
text
that
we
can
live.
We
we
can
live
with
and
that
doesn't
try
to
modify
rc30
rfc
3168.
B
Now
that
some
of
the
excitement
around
what
to
do
with
elf,
with
l4s
sc
ecn
has
died
down,
we
might
have
some
cycles
to
work
on
that
transfer,
header
confidentiality
impacts.
I
just
sent
the
note
to
the
list
announcing
the
conclusion
of
the
third
and
last
last
call
on
this
one.
It's
now
waiting
for
a
shepherd
for
a
shepherd,
write-up
and
it'll
be
on
its
way
and
in
our
ads
hands
shortly.
We
have
no
ideas
for
class.
B
Call
we're
likely
to
do
working
glass
call
on
the
sctp
nat
draft.
Soon
we
have
these
seven
additional
drafts
that
are
in
the
working
group.
Most
of
these
are
on
the
most
of
these
are
on
the
agenda.
Transition
feedback
is
not
that
one's
been
more
or
less
on
hold,
while
progress
is
made
elsewhere
on
drafts
that
use
that.
B
Bunch
of
related
drafts,
six
man
is
working
on
on
path,
mtu
discovery
for
ihf
v6
loops.
There
is
a
friday
friday.
First
thing.
B
This
is
fairly
important
as
they're,
basically
proposing
to
do
some
amount
of
loss,
loss,
detection
and
reaction
on
part
of
a
path
not
going
to
discuss
it
more
discuss
it
more
here,
but
please
we
do
need
to
have
some
good
transfer
representation
in
that
buff,
because
they're
looking
at
trying
to
do
better
on
loss
and
that
interacts
strongly
with
congestion
control,
which
we
all
know
from
experience.
B
The
this
sfc
draft
i8
sfc
nsa,
gt10
support.
This
is
the
draft
that
uses
terminal
congestion
feedback.
That's
over
the
sfc
working
group,
low
latency
docsis
draft
has
been
sent
to
the
independent
submission
editor
and
we
put
the
the
datagram
path.
Energy
discovery
via
udp
options
into
a
separate
draft.
That
right
now
is
an
individual
draft.
As
we
get
udp
options
moving
forward,
we
will
likely
be
asked
to
adopt
to
adopt
this
draft
to
pick
up
pick
up
that
functionality
elsewhere
over
in
the
interior
group.
B
There
are
three
drafts
of
interesting,
there's.
There's
a
tunnels
draft.
There
is
a
fragmentation,
fragility,
draft
and
sox
sox6
and
then
there's
a
couple
of
sctp
drafts
listed
on
this
slide
that
have
been
submitted
as
possible
additions
to
sctp.
B
Hang
on
what
have
I
got
here?
Yeah,
let
me
pick
up
bob.
I
suspect
I,
okay,
yes,
bob
go
ahead.
Sorry.
E
All
right
it
was
that,
can
you
guys
slide?
It
was
just
not
on
the
encapsulation
thing
it
was
on
the.
Can
you
hear
me?
E
Yes,
I
can
hear
you
which
side
do
you
want
the
other
one,
so
these
are
twice
either
two
there's
one.
E
E
B
Bob
says,
in
addition
to
the
latency
docsis,
there's
also
a
cue
protection
draft,
both
of
which
have
gone
to
the
independent
submission
editor,
both
of
which
will
be
useful
information
for
how
this
for
how
these
these
topics
have
been
addressed
in
in
the
dot
in
docsis
context.
Good
enough
bob.
B
Cool
and
as
noted
on
the
encapsulation
drafts
bob-
and
I
are
going
to
put
our
head-
put
our
heads
together
offline
and
try
to
come
up
with
come
up
with
some
fragmentation
text.
That'll
get
these
drafts
get
these
get
these
drafts
moving
in.
We
know
what
has
to
be
done
and
we've
both
been
way
too
busy
doing
other
things,
and
this
language
is
not
going
to
be
the
easiest
thing
to
write.
B
All
right,
so
this
is
the
overall
agenda
outline
for
the
meeting.
We
are
in
the
middle
of
agenda
back.
We
we
are
in
the
middle
of
getting
things
started.
We're
about
to
go.
Do
some
agenda
bashing!
B
We
have
drafts,
we
have
a
milestone,
review,
I'm
trying
to
go
trying
to
go,
I'm
going
to
try
to
go
through
relatively
quickly
drafts
today,
more
drafts
on
thursday,
all
right
milestones
review.
We
have
five
milestones
on
this
slide
that
have
gone
past
that
have
that
have
effectively
gone
past
us
with
luck
within
the
next
month.
B
Three
of
these
we
checked
off
is
done,
and
so,
as
opposed
to
trying
to
revise
the
milestones
in
this
meeting,
we're
going
to
see
if
we
can't
get
those
three
milestones
done
and
then
come
up
with
better
dates
for
the
other
two
offline
between
the
chairs
and
chairs
and
draft
authors,
preview
of
upcoming
attractions,
the
sct,
the
sctp
revision
draft
is
intended
for
september
l4s
for
october
and
another
couple
of
drafts
for
the
end
of
this
year.
B
Bestly
plans
of
mice
and
men
have
been
laid
low
by
a
number
of
things,
including
including
the
virus.
These
look
a
little
bit
aggressive
chairs,
we'll
work
offline
to
try
to
to
see
whether
whether
we
need
to
make
adjustments
to
these
okay,
it's
agenda
bashing
time.
So
here's
the
agenda
document,
status
charter
and
accomplishments,
including
working
group
drafts
relay
drafts
and
milestones,
did
that
items.
Two
and
three
are
the
agenda
and
agenda
bashing.
You
are
here
I'll,
read
you
the
agenda
and
we'll
come
and
and
then
we
can
bash
it.
B
Today,
we're
gonna
go
to
a
couple
of
sctp
drafts:
the
updated
spec
and
the
nat
draft,
followed
by
two
protocol
drafts
update
on
the
udp
options.
Draft
that
draft,
I
believe,
is
expired
and
needs
to
be
resubmitted,
but
we
are
still
trying
to
work
on
it
and
the
nqb
draft,
a
php
for
non
q
building
flows,
then
nat
for
quick,
is
on
this
agenda
as
individual
draft
we're
expecting
only
a
brief
update,
as
I
believe
this
is.
This
is
headed
for
the
quick
working
group.
B
Martin
martin,
we'll
explain
when
the
time
comes
thursday.
We
have
two
parts.
First
part
is
the
work
group
drafts
on
ecn,
which
is
a
status
and
an
update
on
the
elf
rest
drafts,
plus
some
discussion
on
plans
for
drafts
in
both
tcp
prague
and
l4s
operational
guidance.
The
need
for
these
was
identified
during
the
during
the
previous
interim
meeting.
F
Yeah,
can
you
hear
me?
Yes,
yes,
indeed,
two
slides
back
just
review
them.
The
upcoming
milestones
just
hang.
F
Back
to
here
this
one
right,
the
last
one
on
the
list,
the
nqb
drafts
is
actually
a
milestone,
is
to
submit
that
as
a
proposed
standard,
rfc,
not
informational,.
B
We'll
fix,
I
will
make
a
note
and
fix
that.
Please
note
that
in
the
please
put
that
in
the
minutes
as
well,
so
we
notice
that.
B
And
I'm
making
a
note
to
myself
to
fix
chair
slides
so
that
anyone
who
gets
the
meeting
slides
later
will
get
that
that
correct.
Thank
you.
Thank
you.
C
Yeah
and
I'm
good
to
ask
to
bash
our
own
agenda
david.
I
I
think
my
communication
with
joe
had
a
time
zone
problem,
so
we
just
made
slides
on
udp
options,
but
we
don't
have
them.
So
I
suggest
we
put
that
to
the
next
time
slot
for
tsvwg.
It
will
be
short.
B
Okay,
all
right
so
5.1
is
going
to
move
to
thursday.
B
All
right,
if
we
have
to
let's
see
we
had
at
least
one
request
to
take
up,
take
up
these
drafts
today,
in
particular.
B
C
B
Okay,
I
think
we
can
give
that
a
shot.
Unfortunately,
I
can't
I
can't
quickly
scan
the
attendee
list
and
figure
out
whether
we've
got
the
presenters
here
or
not.
It'll
become
a
part
okay.
So
so
presenters
of
these
two
drafts
pan
and
draft
die.
Please
drop
the
chairs,
an
email
note
if
you're
online
and
would
be
willing
to
present
towards
the
end
towards
the
end
of
this
session.
B
Okay,
so
the
agenda's
bashed
and
I
need
to
get
in
the
right
screen
to
go,
change,
slides
and
the
net
is
that
udp
options
will
shift
to
thursday
we'll
do
some
kind
of
update
there,
and
we
may
try
to
bring
the
data
center
control
drafts
into
today.
If,
if,
if
we
can
and
with
that,
I
think
our
next
step
is
the
49.60.
B
This
draft,
let
me
go
get
the
slides
for
that.
C
C
B
H
So
the
update
is
that
we
have
a
seventh
revision
of
the
this
document.
Basically,
the
changes
are
addressing
comments
from
gory,
which
are
editorial
changes
and
he
spent
some
time
to
double
check
mandatory
text.
So
there
was
a
lot
of
mandatory
texts
used
in
notes
that
has
been
changed
and
there
was
a
mandatory
text
in
the
icmp
description,
which
is
an
appendix,
so
it
was
also.
H
The
goal
was
also
to
not
have
mandatory
texts
in
a
panic,
so
we
moved
the
icmp
text
from
the
appendix
to
the
main
text.
That's
what
what's
in
the
seventh
revision
next
slide.
H
And
so
what
is
work
in
progress?
One
issue
brought
up
by
gory
has
not
been
addressed.
I
will
discuss
that
on
the
next
slide.
If
that
issue
is
addressed,
then
the
document
is.
H
Has
no
open
issues
except
for
changing
the
xml
sources
from
b2
to
bc
v3,
which
means
with
the
formatting
stuff
that
might
be
a
bit
tricky,
but
that
will
be
done
and
then
it's
ready
for
working
group
last
call.
So
if
you're
interested
in,
if
you're
willing
to
review
this
document,
I
think
the
authors
and
the
chairs
are
interested
in
that
next
slide.
H
And
this
is
the
the
last
open
issue
and
it's
appendix
a
appendix
a
of
rc4960
describes
how
to
use
ecn
in
sctp.
Actually
it
mostly
describes
the
packet
formats
being
used.
So
how
do
you
negotiate
ecm
support?
And
how
do
you
signal
other
stuff
when
it
comes
down
to
actually
what
is
done?
It's
very
it's
very
preliminary
and
hand
waving,
because
at
the
time
when
the
document
was
written,
things
were
not
pretty
stable.
H
So
we
have
this
text
in
an
appendix
and
it
has
mandatory
text,
and
so
gauri
wants
to
get
rid
of
this,
and
there
are
at
least
three
options.
One
is
remove
the
the
appendix
and
put
the
discussion
of
ecm
for
http
in
a
separate
document.
We
did
this
in
the
past.
H
The
second
option
would
be
keep
the
text
in
appendix
a
but
remove
the
mandatory
text.
So
just
work
around
this,
this
thing
or
the
third
option-
is
move
it
to
the
main
text.
So
the
question
was
what
to
do-
and
I
talked
about
this
with
randy
stewart
yesterday-
move
the
text
to
the
main
text
is,
I
think,
not
what
we
really
want
to
do,
because
the
text
is
hand-waving
style,
and
that
was
the
reason
why
it
was
put
in
an
appendix
and
not
in
the
main
text.
H
So
we
wanted
to
have
the
packet
formats,
but
nothing
more.
So
that's
why
the
authors
do
not
feel
pretty
good
with
option.
Three.
Keep
it
as
an
appendix,
but
remove
mandatory
text
is
kind
of
a
does,
not
really
improve
the
situation.
H
So
what
most
likely
makes
most
sense,
at
least
from
our
perspective,
is
remove
it
just
remove
it
and
put
the
document
put
the
ecn
stuff
in
a
separate
document
and
see
if
this
can
evolve
in
tsv.
H
The
question
was
also
brought
up
by
gory
what
about
testing?
So,
as
far
as
I
know,
the
negotiation
was
tested
in
interrupts,
but
the
ecn
reaction
actually
was
never
tested.
So
I
I'm
not
sure
I
have
never
seen
a
bake-off
where
we
were
using
where
we
were
marking
packets
and
see
if
the
reaction
is
correct.
C
Maybe
david,
I
could
take
a
couple
of
comments
on
this
when
we,
when
I
looked
at
this,
I
think
we
have
to
do
something
if
this
document
is
going
forward
as
a
as
a
standards
track
document
and
we're
aiming
full
standard
eventually
with
this
document.
So
we
need
to
be
very
clear
about
the
language
and
I
was
unhappy
with
appendix
say
so.
I'm
pleased
you're
looking
at
it.
C
My
preferred
option
would
have
been
three
personally,
because
if
this
tech
had
been
really
good
and
people
had
implemented
it,
that
was
the
way
to
go,
but
you
say
not:
okay,
I'm
not
hugely
sold
on
number
two.
C
I
think
we
already
have
an
rfc
that
describes
what
this
was
and
we
don't
need
to
further
document
it.
So
I'm
interested
in
what
the
working
group
thinks
about
these
things.
Do
people
in
the
working
group
really
want
to
have
two
or
one
or
even
three?
I
H
So
you
are
asking:
if
there
is
a,
if
there
is
an
rfc,
are
referencing
the
ecn
stuff
for
sctp.
B
No,
what
I'm
asking
is
if
we
do
option
one
and
the
response
to
to
max's
question
is
that
the
chunks
and
ids
used
by
ecn
stay
assigned.
Does
that
result
in
a
normative
reference
from
the
4960
bist
draft
to
the
new
sctpecn
draft.
H
C
I
think
there
is,
there
is
also
scope
for,
as
speaking
as
a
chair,
there
is
also
scope
for
resurrecting
the
ecn
draft
when
this
was
first
brought
up
as
a
topic
of
adding
ecn
to
sctp
ecn
was
not
a
topic.
We
talked
about
that
much
at
that
time.
C
Now,
there's
been
a
lot
of
talk
about
ecn,
so
maybe
it's
appropriate
to
bring
a
work
item
to
the
group
with
some
status
that
can
talk
about
the
use
of
ecn
with
sctp,
so
we
could
put
something
on
the
roadmap
there
and
I
would
feel
very
comfortable
in
asking
rad
to
go
ahead
with
a
milestone
for
that
one
yeah.
I
would,
I
think.
B
There's
five
dudes,
of
course,
yeah.
Sorry,
I
think
a
milestone
is
fine,
a
question
that
I
would
have-
and
this
is
basically
me
drawing
a
blank-
are
the
various
ideas
assigned
in
iana
registries.
B
Yes,
okay,
in
which
case
we
don't
have
a
problem,
because
the
ana
registry
preserves
the
assignments
that
max
asked
about,
and
we
don't
have
to
discuss
in
the
4960s
draft.
Okay.
Now,
I'm
with
you
thank
you.
C
There's
some
more
comments,
because
this
is
a
a
final
change
to
this
document.
Is
there
any
more
comments
on
either
appendix
a
or
really
on
anything
in
this
particular
document
likeness?
Do
you
have
a
comment.
A
Yeah,
you
have
been
anybody
cause
power.
Your
sky
doesn't
seem
to
do.
Bob
briscoe
had
a
comment.
The
current
text
mimics
rfc
3168,
which
is
being
updated
to
tcpm
by
accurate
sn.
So
it
would
only
make
sense
to
include
easy
and
sp
if
it
goes
straight
for
more
accuracy
as
in
quick
and
tcp.
B
Yeah,
my
reaction
is,
I
think,
what
bob
said
is
one
more
reason
to
do
the
split
in
option,
one
because
my
general
sense,
both
from
what
michael
described
and
other
discussion,
is
that
the
ecm
sctp
is
far
less
mature
than
the
rest
of
4960
bits.
It
needs
more
soak
time
and
work
running
code
would
be
really
nice
and
hence
a
splitting
it
out
into
a
separate
dock
with
the
new
with
a
new
milestone
for
the
written
group
makes
a
lot
of
sense.
B
C
C
For
preparing
the
the
transcription
to
rev3
format
and
how
long
do
you
think
before
we
have
a
document,
that's
ready
for
wider
review?
C
I
guess
give
me
four
weeks
for
for
the
translation,
okay,
so
one
month,
and
if
people
are
willing
to
review
this,
we
will
need
reviewers
for
this
document.
We
will
need
multiple
reviewers.
I
know
people
have
read
it,
but
we
need
people
to
read
the
document
entirety.
C
If
you
would
like
to
volunteer,
please
come
forward,
otherwise
we
will
press
for
volunteers.
This
document
can
only
be
finalized
and
sent
forward.
The
wicked
group
last
call
with
some
committed
reviewers.
C
C
B
J
B
B
Sounds
like
it's
about
a
month
to
revise
it
about
a
month
to
review
it,
and
then
with
luck
that
gets
us
into
sort
of
october,
we
might
be
able
to
working
through
a
glass
call
up.
Then.
B
Hang
on
a
minute,
let
me
go,
I
I
need
to
go
find
the
next
slide.
Give
me
a
minute
here.
Sorry,
we
need
the
next
slide
deck
right.
K
K
In
the
meantime,
please
go
ahead
from
bob
the
the
current
text-
mimics
rfc
3168,
which
is
being
updated
in
tcpm
by
acc
ecn.
So
it
only
makes
sense
to
include
ecn
and
sctp
if
it
goes
straight
for
more
accuracy
as
in
quicken
tcp.
C
H
H
Okay,
then,
let
me
see
where
the
slides
are.
I
need
to
have
them
locally,
okay
and
go
to
the
second
thing
this.
This
is
a
bit
of
outdated.
This
was
when,
when
wrote
the
slides
at
the
weekend,
so
the
latest
version
revision
17
at
that
point
of
time,
had
changes
addressed
maxim's
comments.
Basically,
he
said
that
the
net
function
is
not
required
to
send
sctp
packets
so
that
we
have
a
should
there
and
not
a
must,
and
we
changed
that
and
mohammed
had
also
comments.
H
H
Yeah
and
the
to-do's
are
not
to-do's
anymore,
so,
and
so
we
discussed
about
so
he
wanted
changes
for
the
reassembly
code.
One
statement
was
that
ip
reassembly
shouldn't,
so
it's
it.
Why
is
it
required
that
a
nat
box
must
do
ip
reassembly
and
it's
not
true?
It
just
must
be
able
to
handle
satp
packets
which
come
in
fragmented,
how
it
does
it's
left
unspecified,
so
that
was
that
was
changed
and
some
other
clarifications
were
also
changed.
H
So
I
think
the
latest
revision,
it's
revision,
20
addresses
all
of
muhammad's
comments
and
maxim
also
had
one
more
must
versus
should,
which
I
missed
so
revision.
20
has
no
to-dos
anymore.
H
C
Were
the
magic
words?
Does
anybody
have
any
comments
on
the
draft
or
any
comments
on
the
on
the
proposal?
To
start
a
working
group
last
call
apart
from
spencer,
who
says
he
likes
to
see
progress
during
our
atf
week?
C
C
So
it's
great
to
get
more
comments
at
this
stage,
so
my
proposal
would
be
unless
anybody
says
something
on
the
list.
We
will
start
working
group
last
call
at
the
end
of
this
week
for
this
document
with
a
three
week
period
to
get
review
comments.
C
F
Okay,
thank
you
update
on
the
nqb
draft.
You
can
go
to
the
next
line.
F
Remaining
work,
items
that
were
discussed
at
that
time
still
have
not
been
addressed
in
a
in
a
draft
document,
but
I've
got
a
couple
of
slides
that
follow
that
outline
ways
forward
on
a
couple
of
these,
so
continue
the
next
slide,
so
one
of
them
is.
F
It
was
requested
that
we
take
a
look
at
some
of
the
common
remarking
policies
or
pathologies
that
have
been
discovered
in
in
studies
and
and
published
in
in
literature
and
in
particular,
looking
at
the
proposed
value
for
the
nqb
code
point
which
is
42,
and
what
would
happen
to
that
code
point
if
it
traversed
a
network
that
implemented
one
of
these
pathologies.
F
So
with
two
references
which
I
found
had
a
fairly
a
good
description
of
studies
that
have
been
done
on
remarking
pathologies
and
were
relatively
recent
through
listed
in
the
references
there
in
those
references,
I
found
six
policies
that
were
considered
to
be
common.
I
think
there
are
like
the
others
that
are
less
common,
that
are
kind
of
one-off
situations,
but
in
any
case,
these
six
were
listed
as
common
ones.
So
bleaching.
F
Obviously,
that's
well
known
in
this
table
list
the
policy
and
then
what
the
outcome
would
be
for
this
value,
42
or
the
first
column
or
first
sub
column.
I
guess
under
that
being
what
v42
would
translate
into
in
this
situation
and
then
a
little
bit
of
note
on
what
the
ramifications
of
that
might
be
so
bleaching
everything
it
gets
to
be
zero.
Everything
gets
to
be
the
same,
no
differentiation
from
other
traffic
that
seems
as
harmless
as
any
other
disturb
marked
traffic.
F
F
F
Were
were
seen,
zeroing
them
out
or
setting
the
value
one
or
value
two
or
zero
one
zero,
and
these
all
three
of
these
pathologies
would
map
a
set
of
code
points
into
either
dscp
value,
2
or
af11,
the
f11
or
af21,
and
so
nqb
would
fall
into
that
group
that
that
gets
mapped
into
those
three
specific
code
points,
so
nqb
mark
traffic
would
then
become
indistinguishable
from
af41
af31,
af21
af11,
as
well
as
three
currently
unassigned
code
points,
250
and
58..
F
F
Nonetheless,
this
seems
to
me
to
be
relatively
benign,
so
these
af
classes,
although
they
do
indicate
different
priorities.
You
know
above
best
efforts
above
default.
F
Nqb
traffic,
but
again
this
is
a
pathological
situation,
so
we're
not
expecting
obviously
full
support
for
the
nqb
php.
F
The
next
one,
setting
the
low
three
bits
to
all
zeros
would
result
in
42
getting
mapped
into
cs5,
along
with
voice,
admit
x
by
forwarding
and
three
other
unassigned
code
points.
F
This
also
may
not
be
the
end
of
the
world,
so
in
some
contexts
all
of
those
code
points
are
treated
the
same
already.
For
example,
in
a
lot
of
wi-fi
networks,
all
those
code
points
are
put
into
the
video
queue,
video
access
category.
F
So
it
doesn't
seem
to
be
catastrophic.
The
last
one
remarking
all
traffic
to
some
value
x
where
that
value
x,
there
were
a
number
of
observed
values
that
that
were
fairly
commonly
used
and
again
here.
If
all
traffic
is
remarked
to
a
specific
value,
then
similar
to
bleaching
there's
no
differentiation
possible.
F
Is
that
there
were
no
observations
of
x
equals
42
in
the
literature,
so
it
seems
like
it's
relatively
safe
to
use
42
for
nqb
that
you
won't
have
networks
that
are
mapping
all
traffic
into
42
into
the
nqv
code
point
and
so,
which
is,
I
guess,
highlight
again
the
note
in
the
bottom
left.
H
B
Let
me
put
a
little
bit
of
gloss
on
this
and
I
probably
should
state
this
in
an
email
to
the
list,
I'm
good,
because
it's
probably
going
to
go
by
too
fast
table's
excellent
greg.
Thank
you
for
the
analysis.
The
next.
The
last
row
is
the
most
important
role
in
the
table
because,
in
addition
to
setting
low
three
bits
triple
zero,
there's
also
going
to
be
some
gear
out
there.
B
That
does
forwarding
differentiation
only
on
only
on
the
three
most
significant
bits
and
so
that
row
something
reasonable
needs
to
happen,
namely
it
should
be
okay
to
treat
nqb
traffic
roughly
the
same
as
cs5
voice,
admit
and
explain,
forwarding
and
it's.
So
that
is
a
positive
design
criteria.
It
sounds
like
you
think
that
that
yes,
that's
reasonable,
whereas
all
the
other,
the
other
five
rows.
The
first
four
rows
in
the
last
row
are
pathologies,
which
we
simply
need
to
make
sure
nothing.
B
Disastrous
happens
an
example
of
something
disastrous
would
be
if
nqb
was
remarked
to
le
lower
effort.
That
would
be
disastrous.
Fortunately,
we
dealt
with
that
at
the
time
when
we
picked
the
default
dscp
for
for
lower
effort.
B
F
B
F
I
I
agree
with
that,
and
I
think,
like
I
mentioned,
wi-fi
networks
for
these
residential
wi-fi
networks,
are
the
example
of
networks
that
do
exactly
as
you've
indicated,
treating
or
ignoring
the
low
three
bits
of
the
disk
or
code
point
and
mapping
packets
into
access
categories
and.
F
That
is,
and
that's
discussed
in
the
in
the
graph
specifically
how
nqb
is
treated
in
wi-fi
access
points
or
residential
y
access
points,
and
there
are
recommendations
around
configuring
access
points
in
a
way
that
preserves
the
segregated
queuing
between
the
access
categories
but
eliminates
the
prioritization,
that
is
by
default,
applied
to
the
video
access
category
relative
to
best
effort.
So
so
that
aspect
is
discussed
in
the
draft
already.
B
Cool
all
right-
and
I've
made
note
to
myself
this
to
basically
send
a
note
outlining
my
comments
to
the
list,
because
if
we
go
to
the
next
slide
exercise
two
slides
down
where,
where
this
top
will
come
up
again,.
F
So
what
do
you
greg
yeah?
One
of
the
other
action
items.
Action
items
was
to
just
include
in
the
draft
discussion
of
impact
on
higher
layer
protocols.
F
One
comes
to
mind
and
if,
if
anyone
has
further
suggestions
on
impacts
that
we
should
discuss
in
the
draft,
I
certainly
would
welcome
those
the
one
that
comes
to
mind
is
in
cases.
So
the
draft
recommends
the
implementation
of
a
cue
protection
algorithm
or
actually
referred
to
as
a
traffic
protection
algorithm
that
can
prevent
the
nqbq
from
being
harmed
by
mismarked
traffic,
so
it
analyzes
the
flows
microflows
that
are
entering
that
queue.
F
F
We
direct
those
packets
into
the
other
queue
the
q
building
queue,
so
it's
protecting
the
latency
there
result
of
that
is.
If
you've
got
traffic
in
both
queues,
the
the
q
building
queue
could
have
a
queue
built
in
fact,
and
so
it
could
have
higher
latency
than
the
non-q
building
queue.
F
That's
expected,
and
so
if
a
flow
is
mismarked
or
perhaps
is
kind
of
on
the
borderline,
it's
potentially
could
see
some
of
its
packets
going
remaining
in
the
nqbq
and
some
of
the
packets
being
redirected
to
the
q
building
queue
and,
and
so
that
could
then
result
in
out-of-order
delivery.
C
C
How
significant
is
that
issue
if
the
traffic
falls
well
within
the
nqb
profile.
F
In
addition,
a
flow
that
marks
its
packets
as
well
in
a
in
a
node
that
implements
both
nqb
and
l4s,
that
the
nqbq
is
expected
to
also
be
supporting
l4s
style,
ecn,
marking
or
ce
marking.
F
So
an
nqb
flow
could
mark
its
packets,
also
ect1
and
then
get
an
early
indication
that
it
might
be
on
the
borderline.
If
you
start
seeing
ce
marks,
that's
an
indication
that
it
may
be
building
up
a
queuing
score
and
could
be
heading
towards
that
territory
of
seeing
someone's
back
as
being
sanctioned.
C
F
Okay
next
slide,
then
next
step
so
still
have
the
action
item,
obviously
to
revise
the
draft
with
text
reflecting
the
previous
two
slides,
as
well
as
the
others
that
were
mentioned
on
slide
two,
so
that
will
happen
within
the
next
next
few
weeks.
Here,
unfortunately,
didn't
get
to
it
in
time.
For
this
meeting,
the
main
item,
I
think
for
discussion
on
the
mailing
list
is
consensus
on
the
dscp.
I
F
The
discussion
on
this
draft
there
was
some
discussion
on
the
mailing
list
about
potential
other
dseps
and
there
was
a
fair
amount
of
discussion
a
couple
of
ietfs
ago.
About
about
that.
I
think
that.
B
F
Way?
Okay,
so
unless
there
are
other
comments
again
that
we'll
post
a
revised
draft,
soon
ask
for
reviewers
for
that
and
any
concerns
about
the
selection
of
code
point.
Please
make
them
in
the
mailing
list.
F
F
B
I
think
that's
possible,
I
mean
if,
if
we,
if
we
in
relatively
short
order,
get
to
a
relatively
strong
consensus,
this
is
dfcp
want
to
use.
There
are
procedures
for
for,
for,
for
early
allocation,
that'll
be
my
problem.
I
think
I'm
the
responsible
working
chair
and
shepard
for
this
draft,
so
I
will
have.
I
don't
forget
to
make
that
happen,
but,
yes,
it
ought
to
be
possible
good
suggestion.
C
Okay,
so
so
heads
up
to
the
working
group,
it
has
been
proposed
to
use
number
42
from
our
dscp
iona
registry
for
this
purpose.
If
you
see
issues,
please
speak
up.
B
Right
and
and
the
questions
iteration,
I'm
gonna,
you
know
how
to
go
back.
A
few
slides
cruise
consideration
is
this
row
here.
This
is
the
next
to
last
row
on
greg's
slide,
three,
which
basically
says
that
there
is
a
good
possibility
that
in
some
net
in
some
network
environments,
this
traffic
will
be
treated
like
cs5
voice,
admit
and
expedited
forwarding.
B
And
greg,
it
sounds
like
from
the
ten
of
this
discussion
that
working
group
last
call
for
this
draft
by
the
end
of
the
year
is,
is
what
is
well
within
reason.
Yes,
I
believe
so
yeah,
okay,
one
less
milestone
to
go
with
jest.
B
Okay,
let
me
go
back
to
okay.
B
Let
me
go
back
to
the
agenda
here,
hang
on
a
minute.
B
Hang
on,
okay,
all
right,
so
here's
the
agenda
and
martin.
I
think
you
asked
in
chat
that
we
move
the
nap
the
quick
net
draft
to
thursday.
J
B
Okay
and
we've
moved
udp
options
to
thursday,
so
I
think
we're.
I
think,
we've
run
off
the
end
of
the
agenda.
That's
an
unusual
occurrence
for
tsbwg.
We
generally
have
the
reverse
problem.
C
Can
you
pop
up
the
agenda
for
the
thursday
meeting?
Please
just
start
it
up.
H
B
And
actually,
hang
on.
C
C
We
will
take
a
short
input
from
martin
jr
on
how
he
got
on
with
talking
about
not
with
quick
and
how
not
to
use
nuts
with
quick.
C
And
then
we
will
go
into
the
ecn
story
with
the
l4s
drafts
and
also
ecn
within
the
data
center
context,
just
to
dip
our
tools
into
that
idea
of
doing
some
sort
of
work
and
looking
at
how
you
might
use
ecn
differently
in
a
data
center
and
whether
this
is
suitable
work
for
the
ietf.
So
the
last
group
of
talks
we'll
really
be
looking
ahead
as
to
what
we
might
do
soon,
but
it'd
be
great
to
have
a
look
at
those
ahead
of
the
meeting
so
that
you
have.
J
Since
we're
so
massively
ahead
of
time,
this
came
up
in
jabber
I
from
the
nqb
draft.
You
know
there
was
all
this
research
that
these
believe
these
are
the
implications
using
these
various
dhcp
code
points.
So
it
points
to
the
existence
of
research
that
the
speaking
from
the
dscp
code
space
is
not
a
it's,
not
a
neutral
or
random
process,
and
I
wonder
if
there
would
be
a
way
to
document
some
of
the
considerations
in
picking
dscps.
K
B
Yeah,
I
think
it'd
be
good
idea,
I'm
not
sure
how
short
it
is.
I
see
rod
grimes
in
chat
says
yes,
yes,
yes
do
this,
and
I
mean
I
recall
the
nasty
surprise
when
we
thought
we
were
done
with
the
le
php
draft
and
then
discovered
that
the
code
point
that
had
been
chosen,
that
looked
like
good
idea
was
subject
to
remarking
pathologies
and
so.
K
Yeah
exactly
I
mean
exactly
this,
is
this
is,
if
you
you
know,
if,
if,
if
the
draft
has
any
more
content
than
here
be
dragons
whatever
you
have
would
be
useful,
because
it's
really
easy
for
people
to
just
assume
that
this
is
a
lot
cleaner
than
we'd
like
to
think
you
know.
B
Yeah,
at
the
very
least,
I
think
we
need
to
warn
that
the
entire
new
cl
entire
class
of
code
points
that
we
we
moved
over
to
standards
track
in
order
to
get
the
code
point
for
le
all.
The
other
code
points
in
that
class
are
subject
to
remarking
to
le
be
very
careful.
What
you
do
with
them
is
is
is
the
kind
of
thing
that
is
in
people's
heads,
so
I
think
you're
right.
K
C
So
I
put
myself
in
the
queue
as
an
individual
now
and
so
it's
gory
fairhurst
again
we're
not
speaking
we're
not
declaring
our
names
at
the
mic.
I
noticed
which
is
equally
the
chair's
fault,
but
gary
paris
and
individual.
We
have.
We
have
this
tools
that
we
developed
for
doing
those
analysis
when
we
did
the
le
phb
and
we're
using
them
currently
to
support
some
work
in
six
man
and
we
have
a
containerized
version
of
our
pro,
which
we
were
looking
for
places
to
run.
C
These
tests
from
we
could
easily
add
some
more
php
measurements
if
well
dscp
measurements.
If
people
were
interested
so
as
an
individual,
I
think
me
and
the
research
group
I
work
with,
would
be
very
happy
to
try
and
undertake
some
measurements
in
this
space
and
would
look
for
people
to
collaborate
with
hosting
measurement.
B
B
And
I'm
guessing
from
past
experience
that
map
rg
will
also
be
a
good
place
to
take
not
only
the
measurements
but
but
the,
but
the
initial
draft
suggests
suggesting
what
the
consequences
made
of
the
measurements
both
existing
and
new
are.
B
In
addition,
I
mean
we
would
probably
work
on
the
draft
and
turn
from
rfc
in
tsuwg,
but
map
rg
is
a
really
useful.
What
seems
like
a
really
useful
form
for
this
kind
of
discussion
as.