►
From YouTube: IETF103-TSVWG-20181105-1350
Description
TSVWG meeting session at IETF103
2018/11/05 1350
https://datatracker.ietf.org/meeting/103/proceedings/
A
Clearly,
everybody
had
clearly
everybody
had
had
very
good
lunches.
Mchale
is
gonna,
be
our
jabber
scribe.
We
do
need
reviewers
for
working
group
drafts
always
and
general.
Please
add
tht
to
GT
any
ID
submitted.
My
hard-working
coach
shirt
didn't
do
that
to
one
of
his
drafts.
They'll
explain
why
later.
A
Okay,
a
standing
reminder
document
quality
relies
on
reviews.
Please
review
documents
in
your
group
at
least
one
other
document
from
other
working
group.
If
you'd
like
documents
that
you
care
about
reviewed,
please
put
any
effort
to
review
review
other
documents,
ok,
conscience
and
status.
We
had
grandiose
plans
got
a
whole
lot
of
stuff
done.
Since
Montreal
we
got
a
few
things
done,
but
as
you'll
see
best
laid
plans
of
mice
and
then
went
went
slightly
off
the
rails.
The
DCP
Ayana
process
changes
draft
is
published
as
RFC
8436.
A
This
is
setting
up
for
getting
the
lower
effort
of
the
diffserv
lower
effort,
phb
draft
publish
which,
which
should
be
happening
between
now
and
prague.
We
have
100
draft
the
RFC
under
queue.
It's
been
there
a
long
time
diffserv
and
web
RTC
QoS
it's
in
this
reference
about
web
RTC
drafts.
If
you
read
Alyssa's
blog.
This
is
part
of
the
infamous
cluster
238
that
the
WebRTC
folks
are
really
trying
really
really
trying
to
clear
this
time.
A
Fortunately,
all
of
our
other
drafts
that
were
part
238,
we've
managed
to
to
extract.
We
won't
tell
you
what
tools
were
using,
who
we
use
the
bada,
so
this
this
is
this
is
this
is
only
one
left
and
I
am
fervently
grateful.
The
TSV
WG
is
not
on
the
critical
path
for
the
web
RTC
tar
draft
tarball.
Thank
you
very
much
to
everybody
who
helped
who
who
helped
us
help
this
get
not
get
into
that
state.
All
right.
A
Three
internet
drafts
at
iesg,
the
SCTP
errata,
an
issues
draft
is
there
will
be
an
update
later
in
this
meeting.
Spencer
will
lose,
is
losing
yet
more
of
what
little
hair
he
has
over
this
one.
The
two
FEC
drafts
are
at
the
iesg.
We
will
have
an
update
on
those
later
in
the
meeting.
The
framework
extension
draft
is
in
fine
shape,
needs
a
few
minor
edits.
The
sliding
window
random
linear
code
draft
actually
explains
how
to
do
something
useful
engine,
a
number
discusses.
A
There
are
some
security
issues
and
some
issues
around
source
code
and
source
source
code.
Copyright
Vincent
will
be
here
later
than
later
meeting
to
update
those
diffserv
lower
effort.
Php
in
still
is
still
in
my
hands.
My
intent
is
to
get
the
artsy
publication
request
to
be
submitted
later
this
week
and
finish
working
group
last
call.
We've
made
some
minor
updates
and
I
simply
run
out
of
time
in
October
to
send
the
publication
request
so
not
to
re
Spencer.
A
You
shall
have
a
job,
no
idea
last
call
we're
going
to
need
to
second
to
real
ask
all
the
EC
an
encapsulation
draft,
the
two
shown
here.
We
had
people
who
signed
up
to
review
and
then
your
working
group
chairs
neglected
to
nag
the
reviewers.
We
won't
neglect
to
nag
reviewers
next
time
around.
We
won't
name,
won't
name
names
to
participate
to
protect
the
innocent.
There
are
additional
working
group,
IDs
interaction
on
the
slide
transfer
header
confidentiality
impacts
has
been
added
since
the
last
last
IETF.
A
This
is
this
is
usual
cast
of
characters,
we're
trying
working
moving
forward
on
them
all
right.
We
related
drafts.
The
fonts
gone
down
in
this
slide,
we're
clearly
getting
popular.
There
are
three
drafts
on
ipv6
path:
MTU
discovery,
electron,
whose
last
time
I
hope
I
have
much
too
badly
is
going
to
talk
about
the
one
in
the
middle,
which
is
a
Silkwood
G,
which
is
a
general
sort
of
solution.
Address
space
draft
exploring
what's
what's
possible,
tcp
go
ahead
that
once
on
wednesday.
B
A
Sorry
so
you
talk
about
in
this
in
this
meeting,
I
forget
the
last
class
time
we
hit
me
at
all
session.
On
the
same
day,
teach
me
encapsulation
considerations,
ipv6,
reservation,
protocol,
priority
scheduling,
switcher
for
our
party
party,
switching
scheduler
yeah
draft
Finzi.
This
one
is
this
one's
in
good
shape.
There
have
been
reviews-
and
here
I
get
to
here-
I-
get
to
pull
another
eye.
Pockit
thank
reviewers,
Vincent,
Roca,
Nicolas,
Kuhn
I.
Think
it's
not
a
co-author
that
myself
and
Ruettiger
guide
all
reviewed.
A
This
draft
I
talked
in
a
pen
submission
editor
at
the
reception
yesterday
and
he
agrees
that
what
we
plant
do
this
draft,
would
you
send
it
to
the
Senate
to
the
independence
mission?
Editor
with
a
recommendation.
Twg
seems
like
a
fine
way
to
handle
this
draft
overlay
fording
behavior.
This
is
on
the
wednesday
TS
vwg
Genda,
but
we
might
get
four
today
depending
on
how
a
basket
Genda
and
a
draft
on
passive
RTT
measurement.
That
is
a
generalization
of
the
of
the
well-known,
perhaps
too
well-known
a
quick
spin
back
over
the
SFC
working
group.
A
A
Draft
interior
tunnels
is
a
general
draft
but
tunnels
for
us.
It's
the
MTU
considerations
that
are
particularly
relatives,
working
group,
fragmentation,
fragility
and
Sox
protocol,
vert
version,
6,
ok,
so
the
agenda
here
we
will
do
gender
bashing
in
a
minute.
Monday's
agenda
doctrine,
accomplishments
the
status
which
were
in
the
middle
of
milestones
of
you
about
to
come
and
drafts
and
on
Wednesday.
Yet
more
drafts,
ok,
milestones
review.
This
is
where
some
of
our
best
laid
plans
ran
aground.
These
are
all
yellow,
/
orange
because
we
didn't
quite
get
that
done.
Get
them
done.
A
A
We
were
a
little
bit
over
the
optimistic
about
when
these
are
going
to
get
done.
Your
chair,
chairs
best
guess
right
now
is
we're
going
to
put
June
29
29
days
on
them
and
hope
and
hope
that's
more
realistic
for
getting
these
three
core
drafts
through
we
still
have.
We
still
have
open
technical
issues
against
these
October.
A
There
were
two
drafts.
These
are
the
two
Telegraph's
needed
working
class
called
again
we're
going
to
move
those
dates,
February
19,
hoping
that
we
can
last
call
them
nothing
major
happens
and
they
can
be
submitted
publication
thereafter.
The
SCTP
net
draft.
Well,
that
was
an
interesting
theory.
I
got
delayed
by
the
SCTP
erotic,
adventure
about
which
will
have
more
to
stay.
This
meeting
I'm
going
to
move
that
to
April
UDP
transport
options.
This
one
seems
to
be
relatively
stable.
A
It's
on
the
Wednesday
agenda,
we're
guessing
that
it's
just
about
done
and
we
may
be
able
to
submit
it
for
last
call
in
like
January
or
early
February,
submitted
in
February
packetization
path,
MTU
discovery
for
Datagram.
That
means
UDP
and
the
like
December
22
optimistic
move
that
to
August
of
next
year
and
telling
session
feedback.
A
I
have
no
idea
this
one's
taken,
a
while
guessing
April,
2020
December
2019
is
still
a
good
guess
for
the
are
the
SCTP
Biss
draft
and
we
need
to
add
new
milestone
for
transport
header
confidentiality
draft
and
we're
gonna
put
that
as
September
2019.
Any
comments
from
anybody
affected
are
not
affected
by
the
milestones,
seeing
none
we'll
carry
on
with
that.
Okay.
A
So
here
we
go
with
the
agenda
and
it's
probably
Genda
I'm
gonna
we're
gonna
cover
a
few
small
small
items,
probably
gender
review,
so
we've
just
done
workgroup
trashley
draft
some
milestones,
an
errata
reminder.
Just
shortly.
Prior
to
the
montreal
meeting,
we
put
an
errata
into
our
11
Eastern
experimentation.
A
Ayane
needed
to
put
a
I
hadn't
needed
a
justification
to
put
a
footnote
in
the
registry
that
ECT
one
is
for
experimental
use.
Only
we
filed
the
errata
I
am
a
put
put
the
footnote
the
registry.
Nothing
to
see
nothing
to
see
here,
move
nothing
to
see
here.
Move
along
agenda
bash
we're
about
to
get
into
you
gory
anything
on
hackathon,
update.
B
A
Okay
check
that
off
all
right
into
today's
agenda,
we're
going
to
start
with
the
transport
header
encryption
impacts.
Then
we
get
an
update,
convinced
sent
on
the
FEC
drafts
and
I
suspect.
We're
gonna
have
some
indie
discussion
there
to
make
sure
we
understand
what
what
the
options
are
for
the
path
forward
there
on
the
FEC
Scheme
draft.
A
Don't
think
so.
So
what
we're
going
to
do
is
we're
going
to
swap
this
with
the
last
draft
on
the
Wednesday
agenda,
which
is
the
the
the
overlay
forwarding
behavior
draft
as
I
believe
the
one
of
the
authors
of
QC
I
draft
will
be
here
in
Wednesday,
non
cue
building
flows
and
then
Bob
goes
up
for
round
two
for
a
more
L
forest
and
diffserv
discussion.
Moving
to
Wednesday
Wednesday
is
a
Transfer
Protocol
drafts,
UDP
options
and
there's
Corey's
draft
without
TS
vwg
in
its
name.
Oh.
B
A
Just
having
fun
up
here,
SCTP
drafts,
probably
mostly
about
forty
nine
sixty
forty
nine
sixty
errata.
What
are
we
gonna
do
about
that
and
moving
forward
to
460
bits,
Datagram,
p,
@p,
l,
mt
p,
MTU
discovery
and
then
more
pet,
more
PMT.
You
discovery
this
time
in
ipv6
and
finally,
we're
going
to
swap
this
overlay
forwarding
behavior
draft
with
the
cues,
with
with
the
q
CI
draft
in
my
copious
spare
time,
I'll
prepare
an
updated
version
of
these
slides
of
that.
Where
that
reflects
that
reflects
that
swap,
okay,
anything
missing!
A
Well,
you
can
tell
all
your
friends
and
family.
You
actually
saw
an
agenda
bash.
We
made
some
changes,
one
more
one.
More
related
event:
this
Saturday
after
Saturday
afternoon
there's
an
actively
802
IETF
data
center
workshop
Paul
Paul
Condon,
whom
you've
seen
here
working
on
congestion.
Isolation
is
the
principal
organizer
of
this.
There
are
several
congestion
topics
on
the
agenda
if
you're
here
Saturday
afternoon,
this
might
be
a
productive
use.
Your
time,
it's
in
this
hotel,
there's
no
fee,
but
you
do
need
to
write.
A
C
D
A
G
D
D
It
was
then
adopted
as
a
working
group
draft
the
zero
zero
version
of
the
working
group
draft
was
submitted
with
no
content
changes
just
to
changing
the
file
name,
and
then
we
submitted
zero
one
version
just
prior
to
this
meeting
to
fix
a
few
more
Nicks
changes
since
Montreal.
We
have
added
a
set
of
examples
briefly
talking
about
showing
the
impacts
of
ossification
on
the
transport
protocols.
D
In
particular,
this
mentions
a
multipath,
TCP
and
and
the
issues
with
middleboxes
that
track
congestion,
window
growth
and
get
upset
when
multiple
TCP,
at
least
some
versions
of
it's
made,
the
congestion
window
grow
in
a
way
they
didn't
expect.
We
mentioned
briefly
TCP
fast,
open
and
the
issues
of
middle
boxes
which
misbehaved
when
they
saw
unknown
TCP
options
or
that
get
upset.
D
We've
also
revised
the
introduction
to
perhaps
better
explain
what
the
point
of
this
draft
is.
We've
revised
some
discussion
about
the
observation
points
and
the
rationale
for
on
path,
measurements,
which
just
wasn't
terribly
clear
to
keep
Brian
happy
and
then
he
goes
and
not
turns
up
to
this
meeting,
we've
referenced
the
what
wire
image
draft
that
he
wrote
and
we've
made
a
bunch
of
editorial
fixes
and
updated
the
references
and
all
those
usual
things.
D
So
open
issues
remaining
not
too
much
I.
Don't
think
we
need
to
look
at
and
revise
the
conclusions
which
are
currently
long
and
perhaps
could
be
described
as
rambling
and
not
necessarily
making
a
clear
point
and
just
make
them
a
bit
crisper,
and
you
actually
have
a
actually
conclusion
in
the
draft
and
we
have
a
section
in
there
which
is
talking
about
metrics
derive
from
the
network
layer
headers,
which
again,
it's
not
quite
clear
how
well
it
fits
in
the
draft.
D
Some
of
this,
the
discussion
there
about
things
like
ECM
code
points
here,
is
a
clear
relation
to
exposed
or
not
exposed
transport
headers,
and
that
I
think
is
a
clear
fit
with
what
we've
got
in
this
drift
of
a
part
of
it
talk
about
things
like
diffserv
or
the
ipv6
flow
label
and
there's
clearly
good
operational
reasons
for
for
looking
at
those
for
managing
the
network.
They
have
obvious
implications
friends
when
performance,
but
it's
not
clearly
necessarily
interact
with
the
the
issues
around
encrypting,
the
transport
headers.
So
we
might,
we
might
consider
taking
that
out.
D
Also,
if
we
wish
to
talk
about
some
of
the
work
people
are
discussing
with
path,
layer
and
and
hesitant
to
say
the
word
plus
or
spud,
but
plus
or
spud,
then
this
would
be
the
appropriate
section
to
do
that.
If
we
want
to
do
it
and
we're
considering
whether
whether
to
expand
that
section
and
include
that
sort
of
discussion
or
just
to
trim
it
down
to
something
much
more
focused
on.
Perhaps
just
DC
encode
points
and
another
hole.
D
What
else
and
you
know
if
people
have
opinions
or
suggestions
for
what
the
right
way
to
go
in
there,
and
that
is
then
we
would
be
happy
to
hear
them.
And
similarly,
if
you
have
any
any
suggestions
for
what
you
think
we
ought
to
be
concluding,
then
we
would
be
happy
to
discuss
that
and
then
hear
what
you
think
and
if
not,
we
will
just
conclude
something.
D
D
B
D
I
I
So
to
me
hanging
on
to
that
a
minute
longer
than
needs
to,
then
you
need
to
hang
on
to
it
is
not
help
is
not
serving
the
Internet
or
the
ITF.
Well,
don't
let
it,
but
don't
let
go
of
it
before
it's
ready.
You
know
I'm
not
asking
for
that,
but
I
think
I
think
that
you
I
think
that
what
you
were
suggesting
my
understanding
of
what
you
were
suggesting
is
exactly
the
right
thing
to
do.
From
my
perspective,
I've
been
wrong
before
and
I'm.
K
Michael
Abrahamson
so
the
same
way
that
you
and
beginning
here
had
drafts
that
are
relevant
to
this
working
group.
I
think
this
work
is
relevant
to
other
working
groups,
so
we
should
ping
before
last
call
here
because
they
did
I
just
I
I'm
going
to
read
this
document
and
already
I
saw
the
MSS
statement
here:
interfere
with
both
MTU
discovery,
I,
don't
understand
where
that
statement
comes
from
and
why
it
states
that
I
would
like
to
know
more
I'm
gonna
make
that
comment.
You
know
on
the
list.
K
B
As
a
co-author
on
this
I
think,
that's
really
valuable
and
the
reason
I
asked
the
other
clear.
The
question
was
to
figure
out
because
we
may
nearly
be
done
with
this,
and
it
may
be
just
the
right
time
to
start
asking
wider
input
on
this
document.
If
it's
looking
good
next
rep
should
be
put
before
other
people
to
really
see
that
they
have
a
buy-in.
I
see
Cullen
nodding,
you
know
I,
guess
he'll
say
more
if
he
wants
to
yes.
D
K
D
B
B
You
can
go
to
record
the
TCP
spec
correct,
which
means
that
now
you
can't
figure
out
the
path
actually
supports
a
bigger
MSS,
which
it
does
because
the
end
system
says
it
does,
because
the
MSS
is
an
end-to-end,
a
negotiation
and
therefore
this
seems
to
be
some
sort
of
a
combination
of
two
different
things:
the
end-to-end
negotiation.
What
might
some
segment
size
was
done
at
the
end
to
end
point
and
then
the
network
somehow
changed
that
to
prevent
it
doing
path,
MTU
discovery,
sure,
okay,.
B
K
The
operator
who
put
in
the
egg
at
the
clamping
statement
there
on
the
road
roof.
Probably
you
had
a
pretty
good
idea
what
the
MTU
was
on
the
link
that
that
is
handling
these
packets.
So
this
is
a
this.
Is
he
like
the
way
I
see
people
using
it?
It's
okay,
pppoe
and
oh,
oh,
by
the
way
we
screwed
up
the
path,
MTU
discovery,
so
we're
gonna,
clamp
them
MSS
to
1452
or
whatever.
It
is
for
me
for
to
do
this.
K
B
I
can
give
you
lots
of
data
which
shows
that
operators
at
some
point
in
the
network
path
are
clamping
to
numbers
that
are
smaller
than
the
actual
segment
size
they
actually
support.
We
did
probing
measurements
because-
and
these
were
not
people
who
were
doing
nice
PPE
or
a
or
whatever
encapsulations
there
were
people
who
optimistically
reducing
a
little
bit
to
make
the
network
a
little
bit
more
reliable
in
their
view.
For
so
maybe
we
should
25
at.
B
K
B
I
I
I
I
found
with
my
draft
that
it's
it's
turning
out
to
be
important
to
get
people
who
are
responsible
for
the
things,
I'm
characterizing
to
look
at
them
and
make
corrections,
and
things
like
that.
I
to
me.
That's
almost
like
an
early
review
thing
that
you
could
kick
off
at
any
time.
So
I
trust
you
guys
to
manage
the
working
group
speaking
back
as
Spencer
the
area
director,
but
the.
I
E
E
K
At
least
the
Cooper
said
on
said
on
a
job
or
that
she
thought
that
this
should
go
to
for
security
area
review
as
well,
and
so
not
only
like
trying
to
reach
operate
or
like
a
little
bit.
Also
security.
Yes,.
A
D
I
I
What
Lauren
who
actually
stands
for
that
conversation
was
not
well-informed
and
I,
get
to
say
that
as
a
transporter
director
who
was
sitting
there,
this
document
would
have
helped
I
belted
on
the
draft
that
went
through
the
IETF,
and
it
seemed
like
to
me
that
this
draft
would
have
been
helpful
for
that
situation.
Also,
so
I
could
point
to
at
least
two
worked
examples
where
I
think
as
the
responsible
area
director,
for
you
know
this
working
group
and
a
few
other
things
that
that
would
be
that
this
would
that
this
would
be
helpful.
I
Speaking
as
the
responsible
one
of
the
two
responsible
area,
directors
or
the
area,
we
had
this
fascinating
conversation
in
TSP
area
today.
That
was
basically
talking
about
Kevin
veering
off
into
discussions
about
well.
But
you
know
we
knew
what
we
were
doing
with
peps
in
1998
when
we
published
Darcy.
What
was
it?
I
31
31,
45
or
whatever
was
in
2001
that
actually
came
out
in
2001,
but
the
work
was
done
before
that,
but
but
we
really
have
we
in
transport,
if
not
really
had
a
meaningful
conversation
about
what
peps
were
intended
to
do
and
why
they
were
why
they
were
done
and
again
I
think
that
this
work
informs
a
discussion
like
that.
You
know,
I
can
only
say
as
the
past
as
the
chair
as
a
co-chair
of
the
concluded
pill,
working
group
and
satellite
links
are
still
out
there.
You
know
step
one
right.
I
So
what
people
do
about
that?
You
know
that's
up
to
cell
operators,
but
again
I
think
this
is
work
that
will
inform
a
lot
of
decision,
a
lot
of
conversations
that
will
be
had
whether
they
aren't
informed
or
not
notice.
That
I
didn't
mention
quick
in
the
spin
bet,
which
I'm
also
responsible
for
asked
me
about
my
week.
C
A
A
B
Wait
good
beats
all
right
so
to
give
context
and
the
document
that
Vincent's
going
to
talk
about
and
was
discussed
in
two
parts
that
one
parts
already
gone
through:
I
guess
G.
This
part
raised
discussion
items
from
the
iesg
relating
to
how
the
document
is
put
together,
and
here
we
have
the
slides,
go
talk
about
the
results.
The
iesg
review.
J
Yes,
so
this
talk
is
more
specifically
focusing
on
this
second
document:
I
see
sliding
noise
scheme.
We
got
very,
very
good
comments
from
ISD
during
the
I
review
on
this
document,
particularly
so
I
will
try
to
discuss
and
read
some
of
them.
The
document
has
not
yet
been
updated
and,
while
still
working
on
the
answer
to
the
EIC
overture,
okay,
so
most
of
those
comments,
though
the
most
important
comments,
we're
about
the
teeny
mg42
p
on
g
random
number
generator.
J
Just
some
background
on
this.
We
have
two
parts:
is
the
core
part
of
this
P
ing
which
produces
a
random
number
in
the
as
a
42
bit
value?
So
this
part
is
coming
from
the
Pew
Energy
Office
I'm
not
concern
about
this,
and
we
have
the
second
part
which
is
matching
on
this
value
value
into
something.
Smaller,
typically
is
four
bits
or
8
bits.
So
that's
the
the
mapping
pot
and
we
have
our
own
code
to
do
this
mapping.
J
So,
let's
go
to
the
commands
and
see
how
we
propose
to
address
them.
So
the
first
moment
was,
but
the
core
thought
itself.
Is
it
safe
across
several
types
of
platforms?
Several
types
of
CPUs
operating
systems
of
compilers,
though
that's
a
very
important
question,
because
the
data
mystic
behavior
of
PNG
is
a
key
point
for
inter
probable,
FEC
codecs.
So
that's
very,
very
important.
So
the
proposal
our
proposal
is
to
do
better
tests
in
particularly
focusing
on
very
small
devices
that
run
specific
microcontrollers
cortex
and
something
and
z13.
J
J
Competent
in
these
domains,
one
right
at
first
office,
so
these
rare
operating
system,
so
we
started
to
do
tests
on
those
very
small
devices
and
compare
them
with
what
we
observe
with
laptops
with
more
powerful
machines
and
the
copy
ing
seems
quite
ok,
so
we
still
need
to
be
additional
tests,
but
it
seems
ok
and
mapping
to
a
smaller
range
of
value
needs
to
be
tested.
So,
though,
while
working
this,
of
course,
there
is
no
way
we
can
guarantee
that
it
will
continue
to
work
on
future
CPUs
and
future
compilers.
J
Yes,
it's
a
major
problem,
but
it's
quite
small
piece
of
work,
and
additionally
I
forgot
to
mention
this
in
the
slides.
We
I
want
to
include
a
set
of
values
that
must
be
produced
by
the
PNG,
including
mapping,
to
be
conformed
to
be
convert
conformant,
so
there
will
be
in
the
document
a
set
of
values.
If
you
don't
produce
these
values
on
your
target
platform,
this
will
not
work.
This
cannot
work
so
I
think
that,
with
that
it
should
be.
Okay.
J
Second
comment
is
bad
licensing
aspect,
so
we
are
copied
and
pasted
some
secret
inside
the
documents.
So
it
comes
with
the
original
license
of
the
authors,
and
there
is
no
way
we
can
remove.
This
license
not
well
possible
without
the
authorization.
So
there
is
potentially
a
program
that
needs
to
be
discussed.
J
There
is
no
way
to
abstract
the
PNG,
providing
just
the
algorithm
of
this
pure
energy,
because
it's
something
quite
complex
and
I
will
make
mistakes
if
I'm
trying
to
translate
it
into
something
more
like
in
an
algorithmic
way
manner.
So
I
prefer
to
keep
it
as
such,
so
we
need
to
find
a
way
to
address
the
solution.
Is
it
compatible
with
the
IETF?
Let's
say
license
yes
or
not.
I
have
no
idea
on
this.
The
original
license
is
more
or
less
a
BSD
license,
so
it's
no
it's
not
more
or
less.
The
original.
H
I
could
even
des
the
ad
holding
that
is
cuts
for
this
yeah
processing
issue
and
so
that
the
problem
is
not
the
license.
The
BSD
license
is
compartment
with
the
IETF
licensed
by
on
purpose.
The
problem
is
a
copyright
statement
in
there
because
there's
a
copyright
statement
that
the
copyright
only
belongs
to
the
original
authors,
while
the
copyright
statement
of
the
whole
document,
including
the
code
you've
put
in
there,
says
the
copyright
belongs
to
the
ITF
in
only
the
authors
of
the
of
the
draft.
So
this
is
a
conflict
that
we
cannot
have.
Okay,.
H
H
One
I
think
the
main
concern
here
was
not
the
actual
technical
details
if
it
will
run
or
not
whatever
the
main
concern
but
brought
up
was
also
that
it's
not
a
good
practice
to
describe
a
specification
in
code,
because
that,
like
it's
hard
to
update
and
it's
like
yeah,
it's
it's
just
better
practice
to
describe
the
specification
in
English
language
and
provide
pseudo
code.
Examples.
B
B
H
B
H
The
one
that
has
the
copyright
statement
is
in
the
Annex
yeah
I
actually
put
another
question
on
the
under
legal
concen.
We
have
and
say
you
know:
can
this
not
be
regarded
as
a
literal
citation
of
something
right
and
I
didn't
get
a
reply,
but
I
think
the
answer
would
be
no.
If
we
can
find
a
different
solution,
that
would
be
better
I.
A
Would
observe
that
the
problems
here
being
caused
by
the
fact
that
this
is
third-party
code,
and
it
is
also
the
case
that
the
copyright
statement
that
causes
the
problem
is
in
fact,
part
and
parcel
of
how
the
bsd
license
is
used.
So
it's
it's.
It's
not
like
somebody.
Somebody
did
something
weird
like.
J
H
J
I
D
H
So
and
the
common
worth
and
I'm,
just
reflecting
other
carbons
from
other
80s,
was
it's
a
problem
to
have
code
as
the
only
specification
you
still
should
specify
the
protocol
in
other
terms,
and
only
have
the
code
as
it
is
trading.
What
you
mean
like
only
having
the
code
as
a
specification
has
caused
problems
in
the
past
I.
I
Understand
and
Spencer
Dawkins
is
the
responsible
area
director
channeling
area,
who
is
channeling
other
IDs,
the
you
know
the
the
best
people
to
talk
to
that
I've
tripped
over
NIH
G
evaluation
with
this
are
probably
been
and
Adam
again,
maybe,
and
maybe
a
look
okay,
perhaps
actor
I'm
trying
to
remember
but
I,
but
at
least
the
two
of
them
that
were
involved
in
the
codec
work
to
produce
the
opus,
codecs
and
codec
and
the
basically
dismiss
of
Kate
yeah.
The
code
was
the
specification,
but
everybody
changed
the
code
in
their
implementations.
I
So
when
so,
when
they
wanted
to
update
the
specification
to
add
some
functionality
every
they
couldn't
talk
about
functionality
without
everybody
going
in
and
figuring
out
what
they've
done
to
their
code.
That
would
be
different
and
seeing
if
they
could
still
do
it,
and
so
it
made
it
very
difficult
to
evolve
what
they
were
talking
about.
Doing
you
guys
could
come
up.
Yeah
I
mean.
Let
me
try
it.
Let
me
try
and
help
you
guys
could
come
back
and
say
you
know.
This
is
good.
This
is
the
future.
It
will
never
change.
I
There
would
be
a
fine
response.
You
know
it
might
even
be
true.
Do
you
you
can
you
know
you
can
come
at
you?
You
can
come
back
and
say
we.
You
know
the
pseudocode
thing
you
know
makes
lets
people
who
made
changes
to
the
code.
That's
the
specification
there
was.
There
was
the
specification
I
and
was
included
in
the
included
in
the
RFC.
It
helps
them
to
help.
You
know
it
helps
them
to
have
the
conversation
about
new
functionality
without
having
to
recode
the
realities,
read
each
other's
code.
I
Basically,
at
that
point,
so
I
mean
I.
Think,
there's
I,
think.
There's
ways
out
of
this
and
I
would
really
like.
I
would
really
like
to
work
with
you
guys
on
figuring
out
what
those
are
like.
You
know,
if
having
of
having
the
conversation
with
the
Japanese
guys
helps
some
of
this,
please
feel
free.
I
If,
if
talking
to
me
about
sending
me
off
to
play
with
the
the
IET
out,
trust
and
see
what
we
could
do
I'm
happy
to
do
that,
you
know
it's
responsible,
Eric
Roger,
but
like
I
say
just
you
know,
you
guys
are
doing
I.
Think
a
good
job
of
working
through
the
concerns
that
have
been
raised
and
just
you
know,
just
trying
to
make
sure
that
you
kind
of
understand
what
my
understanding
is
all
those
of
those
concerns.
No
so,
okay.
A
Spencer
I
wanted
to
inject
here
a
difference
from
the
openness
situation
that
may
affect
how
we
think
about
code
as
a
spec
opus
was
a
codec.
You
do
that
period
here,
I
get
to
give
Vincent
credit
for
writing
two
drafts.
He
wrote
this
one
grabbed
the
FE
C
scheme,
but
is
cluding,
including
all
that
is
consuming
all
of
our
time,
and
he
wrote
a
second
draft
that
allows
multiple
schemes
to
be
registered.
A
J
I
Yeah,
an
excellent
point,
I
think
I,
think
this
points
out
again
why
it's
important
for
the
community
to
understand
that
discusses
are
a
potentially
multi
round-trip
discussion,
where
both
where
both
guys
can
say
yeah,
but
that
reminds
me
about
this
other
thing
that
that's
relevant
to
the
concern
you
know
so
I
think
I
think
that
that's
that
could
be
a
fine
thing
to
point
out.
It's
helpful
and
true
do
the
right
thing
so
Cory.
B
Coming
back
with
a
another
one
on
those
same
thing,
if
the
record
is
constructed
in
such
a
way
using
this,
that
you
need
this
to
decode
this
yeah,
which
means
that
this
actually
is
the
only
way
of
formulating
this,
because
if
you
don't
have
this
PRNG
sequence
in
it,
then
you
end
up
with
a
different
chord,
exactly
yeah.
So
this
is
not
like
a
quartet
where
you
have
quite
boxing
you're
describing
using
C
and
it's
wrong.
Maybe
I
think
this
is
the
way
in
which
these
pieces
are
put
together
as
transport
packets.
B
J
Okay
and
we
had
additional
concerns-
and
this
is
come
some
free
about
the
way
we
are
using
the
PNG
the
right
way.
So
we
were
using
floating
point
calculation,
which
is
surely
not
the
best
way
to
always
deterministic
behavior.
So
we
remove
this
and
we
move
to
fools
integer
and
mathematics.
So
the
next
steps,
of
course,
our
address
all-
recommends
ready
to
all
see.
J
Apart
from
that
and
fake
frame,
much
easier,
we
still
have
some
work
to
be
done
on
1,
&
2
so
made
me
second
1
and
3,
and
clarification
on
licensing
aspects,
then
I
have
also
a
question
to
you.
Die
speak
sense
to
remove
the
spew
Angie
specification
from
the
current
policy
document
and
it's
something
in
a
separate
document
create
normative
reference
between
the
two
documents,
so
that
so
as
to
divide
the
programs,
I
would
say
so.
J
It
makes
it
easier
to
and
faster
to
clear
all
the
ASG
discuss
on
I'll
see
itself,
and
it
will
also
increase
the
visibility
on
this
PNG
specification,
which
might
be
use
in
different
contexts
for
different
protocols.
We
are
missing
something
I.
Think
I
did
a
quick
search
before
going
to
this
development.
Is
there
anything
any
RFC
describing
an
existing
and
good
enough?
Png
I
found
nothing
that
I'm,
not
oh.
Well,
whatever
has
been
published.
Maybe
I
missed
something
but
I
think
there's
nothing
so
it
could
be
meaningful
so
to
have
this
separate
genome
t32
document.
J
B
Trying
to
channel
where's-
you
isn't
here
and
I
suggest.
If
you
have
a
pinions
on
this
from
the
working
group,
please
talk
to
Vincent
or
use
the
mailing
list.
Otherwise,
Vincent
you
should
work
with
Wes,
as
your
document
Shepherd
to
find
a
solution.
Please
involve
the
two
ADEs
who
obviously
have
some
expertise
was
also
will
be
able
to
guide
you
as
to
which
of
these
options
is
the
most
likely
door
to
push
on
first
yeah
I.
B
A
F
Quick
recap
on
l4s
motivation
is
extremely
low,
queuing
delay
for
all
internet
traffic
and
all
means,
including
link
saturating
traffic.
So,
ultimately,
the
idea
is
that
everything
can
go
in
there.
L
4sq
the
only
reason.
There's
another
queue
there
is
for
legacy.
Existing
congestion
controls
typical
measurements.
You
get
about
mean
of
Fryman
of
microsecond
queuing
delay
versus
about
5
to
15
milliseconds,
with
your
best
state
of
the
art
ATMs
today
so,
and
the
three
drafts
a
roughly
map
to
the
about
work.
One
two
three
picture
there.
F
Although
the
order
I'm
going
to
doing
the
mean,
isn't
one
two:
three
it
to
sort
of
age
anyway,
there's
the
idea
is:
there's
scalable
congestion,
controls
at
the
sender,
there's
a
protocol
which
we've
honed
in
on
et1
as
the
as
the
Co
point
that
signifies
this
traffic.
That's
in
the
EC
Enfield
mm,
there's
the
dual
Q
cap
of
a
QM
that
does
the
work
in
the
network,
so
the
protocol
is
the
first
but
I'm
going
to
go
on
to,
but
before
I
do
I'll.
F
Cool
yeah
well
I've
got
discussion
of
the
reordering
in
the
middle,
yes,
yep
all
right,
so
there
are
three
core
alpha
us
working
group
drafts
in
this
working
group:
the
architecture,
the
semantics
of
the
identifier
and
your
cap
of
a
QM,
the
architectures
been
stable.
Now
I
went
through
it
because
I'm
preparing
for
working
group
last
call
I
went
through
it
with
a
fine-tooth
comb
or
fine-tooth
soaring.
F
F
To
be
honest,
there
was
very
little
wrong
with
it,
even
though
it
was
written
quite
a
time
ago,
and
so
there's
minor
updates
there,
the
identifying
modified,
easy
and
semantics
one
was
a
lot
more
problematic
in
terms
of
it
was
written
right
at
the
start
of
the
activity.
It
was
the
primary
thing
to
do
to
get
the
code
point
standardised
and
it
was
to
be
honest,
a
bit
of
a
mess.
So
what
I
did
I
did
it
in
two
updates?
F
C
F
We
added
this
requirement
to
be
rack
like,
hence
it's
in
green,
because
it's
not
gray,
because
it's
not
in
this
cycle,
but
David
has
raised
a
question
on
that
which
I
will
discuss
or
bring
bring
out,
and
it's
essentially
about
incremental
deployment
of
all
these
requirements,
then
moving
on
to
the
dual
queue
coupled
aqm.
This
is
a
sort
of
top-level
summary,
so
you
know
whether
you
can
go
and
check
your
email
or
whether
you
really
ought
to
listen
at
certain
points.
F
There
are
a
number
of
extra
normative
requirements
we've
put
in
during
a
review.
It
was
pointed
out
that
we
hadn't
sufficiently
specified
the
thing.
The
maths
wasn't
rigorous
I'll
quickly
go
through
that
the
there's
some
this
doesn't
sound
very
interesting.
Does
it
management
requirement
details?
You
know,
there's
only
no
words
in
that
sentence
that
that
sound
interesting,
but
there
are.
There
are
some
interesting
stuff
in
there
on
how
you
measure
queuing
delay
and
how
you
compare
it
for
the
experiment
and
stuff
like
that.
F
Then
there's
some,
the
other
two
bits
are
pseudocode
updates
in
the
appendices
and
there's
just
a
bit
of
news
there
on
what
we're
doing-
and
you
know
things
like
shared
buffers
versus
dedicated
buffers
and
stuff
okay
and
then
at
the
end
of
the
talk.
I'll
just
give
some
heads
up
on
what
else
is
happening
about
l4s
in
other
working
groups
and
outside
the
ITF.
F
So
the
first
draft
identifying
modified
ecn
semantics
the
identifier
draft.
It's
gone
through
two
revisions
bit
of
an
eye
test,
this
one,
the
it
shows
the
contents
before
and
after
between
three
and
four
we're
now
on
draw
five
and
the
primary
point
of
all.
This
is
those
two
emboldened
headings:
prerequisite
transport
layer,
behavior
and
prerequisite
network
node
behavior.
F
F
F
Game
sync
updates
things
like
that
that
a
low
latency,
but
also
not
Q,
building
not
capacity
seeking
stuff
right,
and
so
the
idea
is
that
you
can
freely
use
any
form
of
classifier
to
do
that.
Maybe
the
latest,
you
know,
look
at
the
DNS.
If
you
want
look
at
look
at
your
layer,
seven
protocol
or
or
look
at
DSC
ps4
EF
for
voice,
admit
things
like
that.
F
To
add
to
that
and
there's
a
later
talk
from
Greg
white
on
possible
new
diffserv
code
point
called
non
cue
building
that
pulls
together
all
those
things
like
game
updates
and
things
I
just
mentioned,
so
you
don't
have
to
look
around
everywhere
then.
The
second
example
here
instead
of
inclusion,
its
exclusion,
it's
saying
well
what?
If
the
operator
wants
to
exclude
stuff
from
that
queue
either
or
for
some
policy
reason,
I've
given
two
examples
here:
a
security
policy
reason,
for
instance,
you've
got
a
malicious
host,
you
don't
you
know
sending
stuff
in
there.
F
You
want
to
want
to
kick
it
out
or
maybe
a
malicious
protocol.
You
know
that
a
badly
formed
protocol
that
you
want
to
kick
out
and
commercial
reasons,
maybe
maybe
an
early
deployment
certain
operators
might
want
to
say.
Well,
let's
do
this
for
all
our
traffic,
but
other
operators
might
want
to
say
we're
just
going
to
do
this
for
our
business
customers
or
our
high
tier
customers,
or
something
like
that.
So
we'll
exclude
anyone
that
isn't
in
that
category
from
their
l4s
queue.
F
Even
though
it's
got
the
right,
DCM
code
point,
and
so
the
idea
there
is
that
if
they
do
that,
it's
a
local
thing
only
so
the
ecn
code
point
goes
through
their
network
unchanged,
but
they
add
another
classifier
that
says:
okay.
You've
got
the
EZ
&
Co
point,
but
you're
from
a
network
that
I
I
don't
want.
You
know
your
so
from
someone
else's
network.
I,
don't
want
to
give
you
this
service,
and
so
it
kicks
you
off
into
the
classic
queue
and
then
later.
F
If
they
want
to
make
this
undifferentiated
service,
they
can
just
remove
that
classifier
and
it
will
all
start
working
and
the
ECM
stuff
will
still
be
going
through
and
it
will
be
going
through
to
everyone
else's
networks.
So
it's
a
very
important
must
in
the
draft
to
say
you
must
not
change
the
EC
encode
point
in
order
to
do
that.
It
go.
It
survives
your
network,
but
you
add
another
classifier
to
knock
it
out
of
a
queue.
F
The
next
category
of
classifiers
and
identifiers
for
those
classifiers
is
when
you're
sitting
within
a
diff
serv
queueing
hierarchy,
and
this
is
really
there's
a
narrow,
green
arrow
on
here
saying.
This
is
mostly
about,
what's
going
to
be
in
a
later
talk,
but
so
I'm
just
going
to
give
a
flavor
flavor
of
it
here.
So
the
previous
example
was
about
splitting
the
default
diffserv
class.
F
If
you
like
into
assuming,
you
only
have
the
default
hop
behavior
in
your
network
before
you
split
it,
but
if
you
want
to
do
some
bandwidth
prioritization
in
the
example
here,
maybe
not
just
a
voice
service
but
a
priority
by
a
voice
service
where
it
survives,
even
if
everything
else
doesn't
or
something
like
that.
So
you
want
you
want
to
make
it
survive
in
bandwidth
terms.
A
David,
blacks
from
speaking
on
the
floor
as
an
individual
Bob
nice
slide
and,
in
particular,
I
believe
this
finally
resolves
a
confusing
discussion
you
and
I
have
had
about
classification.
The
diagram
is
excellent.
Allows
you
to
make
to
make
the
point
that
I'm
interested
in,
which
is
that
for
incremental
deployment,
I
think
it's
important
for
an
operator
to
be
able
to
sort
of
go
through
their
DSC
P's
and
use
and
turn
l4s
on
or
off
on
a
dscp
by
dscp
basis.
That's
roughly!
A
What's
going
on,
because
I've
got
I've
got
two
cues
here:
priority
voice
and
and
priority
via
VR
that
have
clearly
been
classified,
probably
on
dscp
before
we
even
got
here
and
the
stuff
that
didn't
land
on
those
two
cues
then
goes
through
l4s
I.
Think
there's
more
text
we
worked
on
here,
but
I
believe
we
have
the
structure
of
the
solution
here,
and
we
just
have
to
make
sure
that
this
upstream
classifier
PHP
is
before
before
before.
Dual
queue
is
something
that
is
at
least
strongly
recommended.
A
F
I
know,
but
I
also
want
to
emphasize
that
all
this
you
know
theoretical
discussion
about
Harold
furrows
might
work
with.
Diffserv
is
theoretical
discussion.
You
know
we're
just
making
sure
it
will
work,
we're
not
necessarily
saying
you've
got
to
do
this
or
it's
sensible
to
do
it,
and
the
point
of
f-4s
was
really:
let's
just
make
this
separation
between
low
latency
and
old
stuff
that
causes
high
latency,
and
that
should
be
enough
from
for
the
public
internet.
F
You
know,
so
this
is
all
added
complexity
that
we
didn't
design
to
to
add
it
I,
don't
think
you
need
it,
but
you
could
you
know,
and
certainly
in
corporate
networks
that
do
all
this
bandwidth
stuff
then
they
may
well
want
to
continue
doing
that
and
the
other
point
to
make
is
incremental
deployment,
which
is
David's
points.
A
good
one,
incremental
deployment
isn't
the
only
way
this
might
happen,
because
once
you've
got
a
once,
you've
got
a
way
to
do
latency
without
bandwidth.
F
K
F
Theoretically,
yes,
you
could
do
fq
coddled
in
the
CQ
and
couple
it
to
the
lq.
For
instance,
we
show
two
examples
in
the
draft:
the
dual
q
draft.
This
is
where
you
had
pie
in
the
CQ,
and
then
you
can
couple
it
to
the
elk.
You
read
in
the
CQ
in
comes
vlq.
If
he
comes
a
bit
more
difficult
because
the
coupling
means
you've
got
a
couple,
some
congestion
level
to
the
to
the
elk
you
but
you've
got
many
many
congestion
levels
in
all
the
different
queues.
K
K
F
The
moment
I
wouldn't
recommend
FQ
coddles
default
for
the
dual
queue
couple.
Just
because
we
haven't
been
at
you
know,
implemented
it
so
as
a
point
as
only
default,
implemented
that
the
PI
code
we
get,
but
as
good
or
better
latency
in
the
classic
Q
as
FQ
coddle
anyway,
without
having
all
the
Q's,
so
I'd
recommend
that
I'm,
just
because
we've
implemented
it
and
and
in
fact,
late
a
later
slide
in
this
set
says.
We
have
now
released
that
code.
F
K
F
H
Mia
Kulemin,
sir
I
would
like
to
add
to
that
discussion
that
I
think
that
is
actually
kind
of
an
alternative
to
FQ
caudill,
because
the
goal
of
FD
Caudill
is
to
separate
the
small
Q's
to
give
them
no
latency.
While
if
you
have
l4s,
you
don't
need
it
anymore,
but
I
mean
this
is
a
different
deployment
story.
So,
but
yeah.
A
F
F
I
I
guess
I
just
will
say
one
more
thing:
that
if
you've
got
n
system
congestion
controls
that
are
going
to
give
you
low
latency,
which
is
the
whole
point
of
l4s,
then
the
the
real
aim
of
all
this
is
to
be
able
to
have
low
latency
in
your
high
bandwidth
applications
for
the
future,
not
just
low
latency
for
the
for
the
sparse
applications.
Now
that's
and
that's
the
extra
thing
you
get
aside
from
that
Google
right
next.
F
So,
moving
on
to
exactly
what
David
wanted
to
hear,
this
is
a
copy
of
the
site.
For
the
last
time
we
added
a
fifth
requirement.
There's
requirements
in
this
draft
for
what
senders
must
do
and
we
added
the
fifth
one
saying
that
the
sender
must
count
in
units
of
time
when
it's
considering
lost
detection,
not
in
units
of
packets,
which
is
like
Rach
sorry.
F
Handing
in
units
of
time
is
like
radical,
whereas
in
units
of
packets,
it's
like
the
three
three
do
back
rule
and
that
was
to
give
link
technologies
that
support
l4s
the
ability
to
remove
head-of-line
blocking
delay
all
right
now,
I
realized
in
discussion
with
David
who's
coming
up
to
the
mic.
That
I'm
not
gonna,
explain
all
this
again,
because
I
did
this
last
time,
but
I
realized
that
this
this
point
doesn't
just
apply
to
RAC
I.
Think
what
Davis
quit?
F
F
We
could
end
up
getting
stuck
in
the
trial
state
with
this
thing
that
doesn't
comply
with
the
requirements,
and
so
how
do
we
get
out
of
that
state
if
we
start
doing
trials,
we
think
that
don't
don't
comply
with
the
requirements.
How
do
we
move
to
a
production
environment?
They
do
you
want
to
clarify
if
that
is
the
real
question.
A
Actually
that
a
consequence,
what
I
think
the
real
question
is
I
can
let
you
go
up
your
choice,
you
since,
since
you're
up
there
in
the
victim
position,
your
choice
is
to
whether
you
like,
like
with
rest,
is
slide
or
whether
we
like
like
to
start
discussion
here
and
let
and
let
the
audience.
Reach
are
we'd
the
sliding
screen
well.
F
I'll
carry
on
with
the
question
because
I
think
it's
a
fairly
question.
Even
if
it
wasn't
your
question
or
wasn't
exactly
your
question
and
and
so
the
the
possible
answers
to
that
are
either
you
can
just
move
gradually
and
you
don't
get
all
the
advantages.
Well,
you've
got
all
these.
These
rtcp
things
still
using
that
q
but
they're
going
to
move
out
gradually
and
then
it
all
becomes
sweetness
and
light
and
apple
pie.
F
So
you
could
you
could
deploy
queue
protection
for
that
sort
of
thing
you
you
could
deploy
polices,
etc,
etc.
But
the
the
main
point
is
that
you
start
start
running
out
of
general
answers.
You
have
to
go
in
to
get
into
each
specific
requirement
and
the
first
three
requirements
are
all
about
essentially
ttp
friendliness
with
old
tcp,
and
it's
it's.
It's
all
to
do
an
RTT
bias
and
things
like
that
and
so
I
really
don't
think
you
need
to
worry
about
that.
F
If,
if
that's
a
problem,
it's
been
a
problem
for
ever
and
the
idea
of
putting
in
these
requirements
is
to
make
it
better
from
the
start.
But
if
it
doesn't
get
better
right
from
the
start,
it
will
get
better
fairly
soon.
I,
don't
think
I
wouldn't
really
recommend
putting
in
right
polices
and
things
to
enforce
rate
fairness
and
all
the
rest
of
it.
But
you
know:
that's
up
to
the
network
operator.
F
If
we
set
the
requirement
to
detect
loss
in
units
of
time,
what
that
means
is
it
if
you've
got
congestion
controls
on
the
network
that
are
not
doing
that?
The
reason
for
having
that
requirement
in
there
was
then
it
gives
more
flexibility
for
the
network
to
be
able
to
turn
off
resequencing,
which
is
trying
to
keep
things
in
order
in
the
network
just
because
TCP
is
so
sensitive
to
ordering,
and
so
we
wanted
to
start
from.
F
F
But
if
you
have
congesting
controls
that
don't
do
that
on
your
network,
what
it
will
mean
is
that
if
you
do
start
allowing
more
reordering
in
the
network,
those
congestion
controls
will
start
doing
more
to
spurious
retransmissions,
all
right
and
so
in
a
sense.
You've
got
a
mechanism
for
kicking
them
off
gradually
by
gradually
opening
up
that
space
and
allowing
them
to
hurt
themselves
until
they
upgrade
okay.
A
So
this
is
david
from
floor
again,
and
I
want
to
try
to
take
this
up
a
level
because
I
believe
we
let
say
the
middle
name,
the
IETF,
engineering
and
I
believe
we
are
looking
at
an
engineering
trade-off
across
levels
in
the
stack
and
I
think
Bob's
actually
done
a
nice
job
of
summarizing
isn't
very
bottom.
The
slide
I'll
observe
that
this
slide
and
all
of
the
details
on
it
are
consequence
of
making
engineering
decision
one
way
and
I'd
like
to
focus
of
engineering
decision.
A
In
essence,
the
trade-off
is
roughly
as
follows
that
if
you
don't
impose
the
rack,
like
requirement,
detect
loss
in
in
units
of
time,
we
have
existing
code,
we
can
use
it's
DC
TCP
it
works
with
this.
Now
it
will.
It
will
continue
to
work
at
the
cost
of
spending
the
engineering
resources
on
on
the
links
to
do
the
resequencing
and
the
buffer
required.
A
The
reverse
engineering
trade-off,
which
is
the
one
that
leads
to
the
whole
discussion
on
on
on
this
slide,
is
to
say
that
the
cost
of
resequencing
in
the
links
is
getting
out
of
hand
and
and
the
benefits
of
removing
link.
Resequencing
is
worth
all
of
the
cost
and
complexity
on
this
slide
and
Beyond,
including
starting
out
with
no
running
code
that
can
use
l4s
as
specified
I.
Don't
know
what
the
right
answer
is,
but
I
do
think.
F
H
B
That
requirement
should
be
in
on
the
point
of
TS
vwg,
and
we
certainly
haven't
talked
about
that
in
int
and
ops
and
other
areas,
because
this
is
a
change
to
this.
The
dead
center
tcp,
which
he
always
says
a
transport
thing,
but
it
would
affect
anything
that
else
will
goes
into
that
queue
and
your
previous
slide
showed
other
trust
transports,
putting
things
in
that
queue
such
as
video
and
other
weirder
stuff.
That
I
don't
understand.
Syd
look
come
from
transport,
but
he's
an
app
stuff,
and
these
people
all
be
impacted
by
this
decision.
A
F
Help
our
understanding
the
there
is
no
requirement
on
the
network
to
turn
off
resequencing
press
start
that
what
we're
aiming
to
do
here
is
put
a
requirement
on
end
systems
to
be
more
live
if
you
like
about
their
their
their.
The
way
they
deem
that
there's
been
a
drop,
in
other
words,
rack
shows
the
example
of
how
to
do
that.
Then,
a
and
and
and
actually
I
didn't
point
out
the
important
two
words
on
that
bottom
line
in
magenta.
F
There
are
two
scale
so
then,
as
network
scale,
they
can
scale
by
doing
more
link
bonding.
You
know
not
not
worrying
about
getting
things
back
in
order
before
they
leave
the
network,
but
it
this
is
like
a
transition
point
now
whether
they've
obviously
got
the
speed
that
they've
got
at
the
moment.
That
can
lick
and
cope
with
that
and
and
we've
got
a
certain
balance
point
between
the
way
real
ring
is
perceived
in
n
systems
and
the
world
and
how
much
is
allowed
in
the
network.
F
What
we're
saying
here
is:
well,
let's
just
move
some
of
the
complexity
into
the
end
systems.
At
this
point
in
history,
if
you
like
as
we're
starting
a
new
queue
and
then
as
networks
scale,
then
they
can
take
up
some
of
the
the
liberal,
nough
stat.
The
end
systems
are
giving
them,
so
they
can.
They
can
make
cheaper,
faster
networks,
an
assertion.
A
F
A
Care
there
are,
there
are
systems
running
out
there
that
are
better
part
of
a
decade
old
and
they
get
patched
at
risk
of
the
of
the
operators,
life
or
or
at
least
career
I,
said
I.
I
think
this
is
an
engineering
trade-off.
I
understand
that
you
firmly
believe
that
enabling
links
to
scale
without
resequencing
buffers
is
the
overriding
priority.
A
F
B
Yeah
you
understand
what
the
chairs
are
saying:
I,
don't
know
how
to
engineer
it.
If
you've
got
a
suggestion
of
how
to
get
that
process
going,
that's
okay.
Otherwise
we
can
sit
together
and
we
can
make
one
because
I'm
not
against
this
I
can
see
the
rationale,
but
I
just
want
to
know
that
the
idea
believes
it
until
it
pops
up
to
the
iesg
and
then
it
comes.
B
F
B
F
I'll
run
through
this
quickly,
because
this
is
there's
not
serious
issues
here.
It's
just
telling
you
what's
happened.
Really,
the
the
dual
Q
draft
Greg
did
a
very
useful
review
and
pointed
out
that
the
normative
requirements
go
in
there.
We
try
to
be
minimalist
and
they
were
a
bit
too
minimalist,
because
if
you
just
follow
the
normative
requirements,
you
wouldn't
have
anything
there
wasn't
enough
in
there.
You
know
so
we
they
were
really
only
normative
requirements
about
the
controversial
things
not
about
the
basic
stuff.
B
F
Yeah
and
in
the
relation
between
the
square
relation
between
the
two
queues,
Greg,
retinue
I-
don't
know
whether
this
wording
satisfies
Greg.
Now
I
asked
him
that,
but
he
it
didn't
seem
to
be
enough.
The
way
we'd
written
it
before
to
link
back
to
one
of
the
equations.
You
know
just
said:
the
power
must
be
to
sort
of
thing
which,
which
I
think
this
is
a
stronger
statement
of.
F
It's
got
to
be
lower
there,
no
lower
than
etc,
etc,
and
the
the
final
one
there
say
that
the
parameter-
and
this
is
actually
one
of
the
management
requirements
for
the
target
queuing
delay
in
each
queue-
must
be
expressed
in
units
of
time
again.
You
know
so
it's
the
same
thing
as
pi
and
coddle,
and
everything
does
now
pull
that
one
out
as
well,
that
one
Greg
didn't
suggest,
but
I
noticed
that
one
yep
okay
and
if
anyone's
wondering
what
the
little
stars
and
footnotes
are,
they
must
be
two
queues.
F
The
in
the
process
of
doing
this
had
to
rework
all
the
equations
in
order
to
be
able
to
refer
to
that
equation
as
a
normative
requirement
because
realized
that,
while
greg
pointed
out
that
they
were,
they
weren't
actually
rigorously
correct.
It
was
because
we
were
equating
instantaneous
things
with
with
values
that
only
applied
on
the
average
and,
and
so
we
worked
all
that
to
make
it
more
rigorous.
F
Right
I
mentioned
the
management
quality,
adding
details
as
three
most
interesting
words
in
the
world.
The
main
thing
is
4q
delay
measurement.
What
we're
suggesting
is
that
an
implementation
should
allow
mean
and
99th
percentile
cue
delayed
to
be
derived
now.
99Th
percentile
is
quite
a
difficult
thing
to
do,
particularly
on
cheap
equipment
or
whatever,
so
we
have
suggested
a
course
histogram
method
for
doing
that,
and
the
idea
of
saying
this
is
because
we
want
as
experiments
proceed
and
also
you
know
existing
experience
with
F
cuoco
or
with
everything
else.
F
B
F
Must
admit:
I
was
surprised
that
didn't
get
picked
up
by
the
iesg
bit
and
I
think
they
will
know
yeah,
because
I
noticed
when
the
RC
83
11,
which
enabled
all
these
experiments
that
David
did.
One
of
the
IAS
G
comments
was
you'll
need
to
ensure
that
all
the
components
of
this
have
experimental
management
and
operational
requirements
in
them,
and
so
I've
made
well
actually
I'd
already
made
sure
and
then
I
went
and
checked
the
checklist
in
RSC
photo
no.6
and
I've
already
done
it
all.
So
that's
good
keep
going.
F
That's
a
good
thing
to
do
so
then
the
pseudocode
we
came
near
the
end
with
general.
We
had
a
step,
a
aqm
in
the
l4
SQ,
just
like
DC
tcp
has
a
simple
step
for
to
turn
on.
You
know,
start
easy
and
marking
above
a
threshold
when
generalized
that
to
a
ramp,
because
we
want.
We
believe
that
we
we
want
to
enable
experiments
with
faster
convergence
when
we
move
the
tcp.
F
There
was
an
assumption
that
we
were
using
shared
buffers
and
because
that's
how
we've
implemented
in
Linux,
partly
because
you've
got
a
very
small
queue
generally
in
the
in
the
lq.
So
you
didn't
really
want
to
allocate
a
lot
of
memory
to
that
just
in
case,
given
you
had
spare
memory
across
the
two,
but
he
pointed
out
that
with
large
sea
bass
classic
bursts
from
slow
start,
you
can
get
tail
drop,
which
then
hits
the
other
one
if
you're
using
a
shared
buffer.
So
the
the
the
less
memory
efficient
but
more
isolating
way
to
there.
B
Now,
no,
but
I
think
we
should
take
the
status
updates
or,
while
I
ask
a
few
questions
rather
than
talk
through
them.
Okay-
and
these
are
in
the
slide
deck
and
could
I
ask
who
ret
who
has
read
the
latest
jewel
queue.
I,
know
it's
pushing
it
and
has
anybody
read
the
latest
jewel
Kouta
you'd
be
pushing
it.
Cuz
I
posted
it
this
morning.
If
there's
a
follow-on
who
plans
to
read
the
Geo
q
draft
that
Bob
issued
one
two,
three
four:
five:
six,
seven,
eight
and
at
least
take
people
in
the
room.
That's
good!
B
That's
it
and
we
need
some
reviewers
for
these
documents
and
they
are
nearing
ready.
They
will
never
be
ready
unless
people
commit
to
review
them
and
we
saw
the
benefit
of
Greg
white
going
through
with
a
fine-tooth
comb
and
the
other
documents
are
no
maturing
as
well
and
does
anybody
wish
to
volunteer
as
a
reviewer.
A
B
B
A
A
F
A
B
A
N
Erickson,
yes,
so
I
asked
represents
the
people
working
on
on
the
ECM
portal.
Quick
so,
but
give
you
update
here.
N
Did
I
do
the
wrong
way?
Yes,
so
yeah
so
anyway,
this
is
just.
This
slide
is
just
to
recap,
and
it
shows
also
the
one
of
the
changes
to
the
ECM
format.
But
it's
this
is
the
AK
format
very
Zn.
Now
it's
an
easy
on
section,
which
is
it's
not
any
more
different
named
frame
types,
it's
using
the
lowest
frame
type
bits
to
separate
between,
without
or
with
the
eastern
section
and
the
still
the
counters,
so
so.
N
N
N
N
What
also
spent
a
lot
of
time,
including
quite
a
some
time
in
thinking
that
the
inter
meeting
for
quick
in
New
York
in
September
was
this
about
more
explicit
information
around
the
insane
bits.
So
should
we
actually
get
the
seein
markings
for
each
individual
packets?
A
conclusion
was,
for
we
want
not
change.
This
is
one
one
aspect.
N
This
is
actually
you
get
quite
a
lot
of
overhead
when
you
need
to
fridge,
see
mark
indicate
the
changes,
etc
and,
as
the
bdp
goes
up,
and
especially
in
the
context
of
l4s,
where
you
will
have
frequent
changes,
so
this
is
gonna,
be
a
challenge
going
forward.
If
you
could
do
l4s
combined
with
easy
and
explicit
marking,
that's.
N
H
N
N
Yes,
but
at
the
same
time
it's
it's,
it's
up,
I
mean
going
to
buy
it
say
you,
you
have
to
think
about
how
you
report
and
it's
up
quite
a
lot
of
the
country-
spaces.
There's
there's
trade-offs
here,
but
and
I
think
for,
and
this
is
actually
why
we
want
to
go
forward
discussion
for
v2,
maybe
to
do
other
ways
that
reporting
this
etc,
but
for
b1
I
think
this
is
it's
the
simplest
etc,
and
it
gives
you
reasonable,
especially
for
the
congestion
controllers.
That
I
mean.
H
N
H
B
F
Don't
know
how
much
these
attacks
are
real
attacks,
but
we
wanted
to
make
sure
that
we've
learned
from
that
experience
and
and
I'm
not
saying
that
those
attacks
are
possible
in
quick,
because
I
haven't
even
thought
about
it,
but
just
as
a
high-level
thought,
you
know
it
when
you,
when
you
do
your
feedback
in
packets.
That
allows
that
splitting
and
and
all
the
other
attacks,
that
baby
weather.
F
Then
there
were
there's
other
things
like,
for
instance,
something
I'm
going
to
be
talking
about
in
t2
p.m.
this
afternoon.
Later
this
afternoon,
is
the
ability
to
be
able
to
alter
your
response,
depending
on
the
size
like
if
you're,
if
you've
got
a
knack
with
ACN
on
it,
you
don't
do
a
full
congestion
window
reduction
compared
to
a
full
day
to
packet,
and
things
like
that,
you
know
so
so
it's
most
of
the
things
I.
B
N
So
really
this
and
I
have
two
basic
questions:
lots
more
but
related
to
what
we
discussed
already.
But
it's.
This
is
what
I
think
from
my
perspective
is
that
these
are
not
really
open
issues.
There
are
solutions
in
quick
v1
which
do
make
them
work
but
and
the
base
avoids
those
issues,
but
they
might
arise
in
the
future
because
people
want
to
do
other
things
which
changes
in
sir.
N
A
lot
of
CPU
is
cetera
for
the
protocol
and
it's
probably
so
and
then
spin
that
it
you
can
get
it
to
work,
but
at
least
with
other
congested
controllers
like
PBR,
etc.
So
that
has
spacing
in
the
sending
so
yeah.
This
topic
is
coming
back.
Yes,
as
quick
goes
into
v2
and
evolves,
etc.
People
and
I
under
do
want,
and
there
have
been
discussion
about
happily
having
senders
side
controlled
what
the
receiver
does
for
a
king,
etc.
H
Sorry
and
I
should
know,
and
so
what
we
say,
an
accurate
easy
and
it's
actually
that
when
the
when
it
changes
like,
if
you
receive
an
on,
see
eMac
packet,
and
then
you
receive
his
eMac
packet,
you
should
send
an
immediate
egg.
But
if
you
receive
like
a
whole
bunch
of
sea
eMac
packet
in
a
row,
you
don't
have
to
send
an
immediate
egg
for
everything
only
if
it
change
it.
If
the
marking
changes
again,
okay,
I
think
that's
the
right
thing
to
do
here
as
well.
N
But
yeah
so,
and
also
this
utility
of
this
more
detail,
see
information
but
what's
happening
on
the
different
packets,
etc.
Yes,
pipe
counting
one
possibility.
Do
it
that
way,
all
right,
how
many
encounters,
but
also
it's
the
question
of
how
how
you'd
want
to
congesting
controls,
etcetera,
what
you
need
so
it's
time
to
think
about
it
and
it's
gonna
affect
this
and
how
possible
to
do
it
so
yeah.
There
was
everything
for
me
any
more
questions.
N
B
O
B
A
D
L
Thanks
folks,
so
I
submitted
this
draft
shortly
before
the
deadline.
I
think
minutes
before
the
deadline,
and
it
was
intended
as
a
kind
of
problem
statement.
L
Coming
from
the
fq
coral
context,
so
a
few
caudal
has
this
functionality
where
it
identifies
automatically
sparse
flows
and
gives
them
a
strict
priority
over
the
book,
both
PCB,
both
traffic
flows.
Does
it
an
application
neutral
way?
It's
not
looking
at
protocol
construct
is
just
looking
at
the
packet
arrival
behavior.
I'm
israel
way
that
we
can
get
a
similar
benefit
in
non
fq
systems
and
devices
that
maybe
can't
support
or
don't
want
to
support
the
fq
construct
and
then
the
second
perspective
is
in
from
the
l4s
context.
L
We've
got
these
two
cues
you've
got
one
that
provides
great
latency
performance
for
this
new
version
of
TCP
or
DC,
TCP
and
and
future
versions.
What
other
kinds
of
traffic
can
you
include
in
that
queue
as
well,
so
some
high-level
goals
we
later
provide
liable,
and
this
caterer
talking
about
have
statistically
fairly
reliable
99?
Is
our
nine
percentiles
kind
of
our
American
using
low
latency
and
low
loss
both
for
these
bars
graphic
flows
of
giving
the
same
kinds
of
performance
characteristics
that
the
l4
s
DC
TCP
traffic
can
get
through.
L
That
lq
also
allow
capacity
seeking
applications
to
compete
for
bandwidth.
So
again
it
as
a
differentiator
between
the
VAR
s
approach
and
the
fq
carl
approach,
where
congestion
controllers
are
sharing
a
queue
and
then
allows
for
innovations
around
the
way
they
see
capacity
and
share
bandwidth
and
then
supporting
out
for
us
for
this
long.
Okay.
So
this
terminology
of
just
using
terms
queue
building
and
non
queue,
building
to
refer
to
application
flows
that
can
fit
well
in
the
in
the
two
queues
in
the
l4s
system.
L
The
queue
building
flows
are
definitely
the
capacity
seeking
flows
are
using
a
traditional
congestion
controller.
Well,
that's
we
know,
or
cubic
or
even
b,
dr
as
well
as
highly
bursty
flows
that
maybe
aren't
using
a
congestion
controller,
but
are
sending
large
large
messages
that
you
lots
of
back-to-back
packets.
That
would
exceed
the
link
capacity
and
cause
the
queue
to
build
up
in
the
network
and
then
non
cube.
Link
flows
are
all
the
flows
that
don't
do
that
right
that
they're,
typically
relatively
low
data
rate
I'm,
not
capacity
seeking
they
may
be
late.
L
Lazy
sensitive,
like
a
lot
of
them,
maybe
are,
but
that's
not
necessarily
a
criteria
here,
and
the
idea
is
that
they're
highly
unlikely
to
be
sending
large
bursts
of
traffic,
that's
going
to
build
up
a
queue
in
the
network,
but
they
might
send
short
bursts.
So,
along
the
lines
with
you
do
for
us
approach.
L
We've
got
these
two
queues
effectively
and
you
know
the
work
works
well
for
queue.
Building
close
you've
got
the
classic.
You
got
a
deep
buffer
and
we
using
some
kind
of
a
classical
aqm
pie
or
coddle,
and
then
a
shallow
queue
for
these
donkey.
Pony
clothes
next
slide.
So
the
question
is:
how
do
you
identify
them?
How
do
you
know
what's
a
non
queue
building
flow
versus
two
building,
so
the
draft
talks
about
a
couple
of
ways
to
go
about
doing
that.
L
One
is
allowing
the
application
or
the
operating
system
to
mark
packets
and
the
view
there
is
that
an
application
or
the
operating
system
has
a
pretty
good
I
guess
concept
of
whether
what
the
application
behavior
is
and
so
could
mark
the
traffic
accordingly
and
then
introduce
this.
This
possibility
of
defining
a
standardized
code.
Point
to
indicate
that
it
was
non
cue,
building,
behavior,
you'll
approach.
L
And
then
you
you
validate
that
in
in
the
network
element.
So
first
of
all,
you
know
stable
is
that
endpoint,
marking
and
I
guess
the
the
view
here
is
that
it
really
isn't
an
incentive
to
lie
that
the
cue
building
flows
that
that
are
going
to
send
you
a
burst
of
traffic
they'll,
do
better
in
the
in
the
C
Q
or
the
Q
building
q.
The
ones
that
are
non
Q
building
will
do
better
in
the
non
key
building
q.
So
it's
not
really
a
reason
to
miss
more
traffic,
but
sometimes
bad
things
happen.
L
Things
get
miss
mark
also
may
not
be
totally
concrete's
how
an
application
can
characterize
itself.
It's
kind
of
in
gray
area
between
cube
building
and
non
key
building,
so
introduce
this
Q
protection
function,
basically,
looking
into
traffic
arrival
patterns
for
packets
that
are
marked
non
Q
billing
and
redirect
them
to
the
Q
building
to
you
if
they
start
to
cause
queuing
delay,
I
think
you.
A
A
The
I
think
you
need
the
protection
I,
don't
believe.
The
incentive
system
is
going
to
result
in
an
ability
to
rely
on
the
marks.
The
incentives
are
indirect
and
they
rely
on
people.
Configuring
applications
correctly
that
which
can
be
configured
can
be
misconfigured.
Yeah.
Sorry
that
which
can
be
configured
will
be
misconfigured.
L
Yes,
so
definitely
maybe
some
value
in
in
this
Lobby
reply.
No,
it
may
be
mandatory.
Yes,
so
got
some
feedback
on
the
mailing
list.
Already
on
this
one
was
it
wasn't
super
clear
in
the
graph
what
the
problem
statement
requirements
were
so
I'll
update
that
and
then
sorry
for
the
little
storm
he
comes
here.
G
L
A
L
That's
it
so.
Okay
does.
E
E
Yeah
yeah
I
wouldn't
take
it
as
a
given
that
the
incentives
lie
with
me.
Staying
in
the
qubit
it
killed,
I
mean
you
know.
We
know.
Buffalo
is
a
big
problem
at
first
glance.
I
would
think
that
the
the
small
Q
would
be
advantageous
to
me
something
I
just
to
hammer
a
little
bit
or
at
the
point
of
incentives,
and
that
you
have
to
verify
I
I'm,
not
sure
that's
accurate
I
mean
in
a
way
just
having
small
cues
in
the
network
would
be
a
good
thing.
E
B
M
Hello,
this
is
eacho
speaking
so
I'm
going
to
talk
a
little
bit
about
this
new
work
for
this
overlaid
pass
segment
for
the
next
page.
Please
yeah!
So
here
the
motivation
for
this.
So
quite
a
lot
of
researchers
and
even
some
departments
already
trying
to
you
to
leverage
the
cloud
router
nodes
in
various
clouds
to
build
a
better
path
in
order
to
provide
the
performance,
chrome
or
closer
to
the
leased
line.
M
So
we
also
ran
some
preliminary
experiments
that
shows
71%
percent
our
chances
that
we
can
find
out
better
over
the
palace
compared
with
the
default
one.
So
now
it's
becoming
more
and
more
practical
thanks
to
the
technologists
of
the
NV
in
the
various
instances
that
provided
by
the
cloud
providers
next
page,
please.
So
we
want
to
take
the
opportunities
of
this
overlay
passed
over
when
and
to
do
loops,
which
is
localized
optimization
on
path
segments
to
achieve
better
reliability
in
this
report.
So
basically
the
picture
shows
under
the
end-to-end
pass.
M
Naturally,
the
path
already
being
broken
into
multiple
overlaid
path
segments.
So
there
are
segments
running
between
two
overlaying
nodes.
So
there
are
some
some
problems
and
opportunities
that
we're
trying
to
overcome
like
florrick
loss
recovery
over
the
long
haul
and
the
sending
rate
decrease
and
the
sender
might
be
I
mean
the
the
Inc
accuracy
in
this,
and
you
read
a
incinerated
decrease
and
also
with
this
overlaid
path
and
normally
the
version
of
a
limited
capacity
and
in
case
of
the
impairment
of
the
virtual
hub.
M
We
need
to
handle
the
detour
or
reroute
next
page,
so
we
figure
out
some
of
the
key
elements
of
a
solution.
There
basically
includes
the
local
recovery,
which
means
the
recover
between
two
over
a
node
in
the
second
one
is
a
congestion
control
interaction.
We
certainly
want
to
avoid
the
retransmission
competing
between
the
end-to-end
layer
in
the
local
recovery.
M
So
we
are
trying
to
have
this
side
meeting
to
steer
the
work.
The
loops
discussion
will
be
tomorrow
evening.
6:30
p.m.
in
sevens
floor
meeting
five.
So
the
purpose
is
to
discuss
the
user
case
and
the
problem,
possibly
some
potential
solution,
ideas
and
what
should
and
could
be
done
in
ITF
here
are
two
related
drafts,
so
everyone's
welcome
and
if
you
are
interested,
please
talk
to
me
or
custom,
who
is
the
organizer
he's
not
here
yeah?
So
thanks.
So
thank.
B
You
for
the
talk
and
I'm
sure
many
people
recognize
things
on
that
list
of
things
that
were
desirable
and
we
will
have
opinions
from
the
transport
area
on
these
topics,
so
please
go
and
to
the
side
meeting.
Please
talk
to
the
presenters.
Please
use
this
list
to
talk
about
this
draft
and
I.
Think
we're
over
for
today.
Are
we
David?