►
From YouTube: IETF111-TSVWG-20210726-2130
Description
TSVWG meeting session at IETF111
2021/07/26 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
So
this
is
tsv
wg
and
we're
the
chairs
online
and
we're
glad
to
meet
you
remotely
today
in
person
someday
soon
and
today,
we're
going
to
be
looking
at
the
status
and
we're
going
to
be
going
through.
The
ecn
drops.
B
So
I
get
to
run
the
status.
This
is
a
title
slide.
This
is
a
note
well
slide
with
which
you're
all
expected
to
be
familiar.
Courtesy
of
registering
for
this
meeting.
It
applies
to
you.
B
B
Okay,
excellent
in
general,
we
need
reviewers
working
group
drafts,
the
more
the
merrier
and
a
reminder
to
please
add
tspwg
to
the
name
of
any
internet
draft
submitted
that
you
want
to
bring
the
attention
of
tsvwg.
We
eventually
find
them.
B
Some
echo
you
usage
tips,
chat
and
meeting
notes,
separate
tabs
and
windows
may
be
easier
to
use,
chat
can
be
torn
off
into
a
into
a
jabber-like
window
and
meeting
notes.
Often
work
in
a
separate
tab
or
window
enables
you
to
keep
the
meat
echo
focused
on
speakers
cue
and
slides
in
discussion.
Please
use
meet
echo
mic.
Cue
click
the
hand
icon
to
join
the
mic
queue.
Please
do
not
use
the
mic
icon
until
I
get
to
acknowledge
knowledge
by
the
chairs.
B
As
noted
earlier,
dr
quality
relies
on
reviews.
Please
review
documents
here
and
at
least
one
doctor
one
of
the
working
group.
If
you
like
documents
you
care
about
review,
then
please
put
the
effort
into
review
other
documents
so
so
that
there's
work
going
on
to
advance
all
of
them.
There's
a
list
on
the
slide
of
some
upcoming
ids
that
need
review
all
right.
What
have
we
done
since
last
time?
We
met
virtually
transgender
confidentiality
impacts.
Rfc
1965
has
been
published,
congratulations
and
thank
you
colin
and
gory.
B
A
C
Yeah,
just
as
far
as
I
see
it,
that
is
currently
the
walls
of
the
court
of
the
authors.
There
are
some
ad
review
comments
out
and
we're
just
waiting
for
a
new
draft.
B
B
We
have
two
ideas
for
group
chairs
and
authors
after
work
last
call.
Well,
that's
actually
me
trying
trying
to
get
these
drafts
to
advance.
I'm
one
for
two,
the
ecn
for
tunnels
that
you
shim
headers
draft
has
no
open
issues.
We
resolve
the
fragmentation
issue,
these
encapsulate
from
lower
layer
protocols.
I
sent
a
note
to
the
list
recently.
B
We
need
to
replace
reframing
interaction
text,
get
this
draft
on
its
way
and
then
go
explore
that
area
in
detail
in
in
an
additional
draft
or
drafts,
I'm
hoping
to
work
with
the
editor,
and
perhaps
we
can
get
these
on
on
their
way
to
the
adasg
before
before
we
next
meet,
and
we
do
need
to
do
that
because
we
have
nine
other
working
group
drafts
list
on
this
slide,
including
one
that
we
just
adopted
on
a
default
dscp
selection
for
for
diffserv,
a
few
related
drafts
you
might
be
interested
in
path.
B
Mtu
discovery
is
a
topic
on
which
work
never
seems
to
cease.
There
gory
has
a
draft
on
adding
this
to
udp
options.
There
is
a
draft
in
six
man
on
ipv6
and
this
the
tram
working
group
is
working
on
a
draft
for
stun.
B
In
addition,
there
is
now
another
draft
from
transfer
protocols
and
satellites
that
is
on
the
pathway,
networking
research
group
agenda
for
thursday.
In
addition,
I
think
I've
seen
some
discussion
over
in.
I
think
it's
int
area
on
on
satellite
internet
concerns.
B
There
is
an
application
of
where
networking
off
friday
noon,
u.s
pacific
time
that
may
be
of
interest
as
applications
use
transport
and
interact
with
it.
Multi-Path
dccp,
there's
the
draft
name,
it's
on
cwg
agenda
and
sure
every
time
I
do
these
drafts,
there's
always
a
mistake.
There's
your
offline
one
off
a
one
day
mistake
you
saw
the
chair
is
not
perfect,
it'll
be
on
tcpg
agenda
on
thursday
recruit
option
requested
network
layer.
B
Multipath
is
another
type
of
interest
and
we
have
a
real-time
transport
object
over
unidirectional
transport,
a
name
that
got
the
acronym
route.
This
will
be
on
the
tsv
area
agenda
fridays
motivated
by
multicast.
It's
the
same
problem
area
as
flute,
which
is
rfc
6726.
B
Please
do
go
to
tsv
area
and
take
a
look
at
this,
because,
if
there's
interest
in
this
it
may
come
to
us
as
transport
area
working
group
of
last
resort
agenda.
Okay,
we're
about
to
go
bash!
The
agenda.
We've
done
the
note
well
and
there's
another
off.
I
want
to
error
it's
thursday.
I
get
to
upload
v4
after
this
clearly
so
dark
caution
status.
We'll
do
a
very
brief
milestones
review
in
particular
we're
not
going
to
try
to
update
the
milestones.
B
As
part
of
this,
the
chairs
will
do
that
offline
general
request,
we're
tissue,
g's
very
short,
meeting
time
this
week.
We
only
have
two
hours.
We
could
easily
have
used
four.
Please
keep
comments
briefly
to
the
point
to
make
best
use
of
time.
B
Okay,
very
quick
fly
through
of
milestones.
There
are
three
drafts
on
this
page
that
had
june
21st
milestones.
Two
of
them
are
these
encapsulation
drafts,
which
I'm
hoping
will
be
submitted
fairly
soon,
and
the
chairs
will
determine
new
udp
options.
Draft
date,
that's
the
third
one
after
this
meeting
week.
B
This
page
all
has
milestones.
We
haven't
overrun
yet
so
far
they
look.
Okay,
chairs
will
revise
based
on
what
we
think
is
actually
plausible
and
reasonable,
as
we
somehow
don't
think
all
of
the
drafts
are
going
to
get
all
of
these
drafts
going
to
get
out
of
the
working
group
between
now
and
the
next
meeting.
New
dates
will
be
determined
for
the
office
operations
draft,
which
will
be
sometime
after
october.
B
Dtl
says
ctp
draft
and
the
diffserv
default
section
draft
we
just
adopted.
We
will
figure
out
dates
for
those
after
the
meeting
week.
Those
are
all
likely
to
be
at
least
sometime
in
2022,
as
we
have
more
than
that
drafts
for
2021.,
okay
time
to
go
bash
the
agenda
so
today
is
agenda
and
draft
status
chairs
update,
which
you're
getting
part
of,
and
we
will
also
quickly
talk
about
three
liaison
communications
that
we've
dealt
with
since
last
meeting
cycle.
B
We
will
be
doing
ecn
drafts
today,
l4s
and
elfre's
ecn
drafts
and
the
alfred's
operational
guidance
drafts,
and
so
today
is
entirely
devoted
to
to
l4s
thursday
brief
update
on
the
sctp
biss
spec,
which
is
going
to
go
to
work
with
last
call.
Sometime
soon,
we
believe
two
working
group
drafts
on
sctp
sctp
dls
and
the
nat
trap.
B
We
talked
about
talked
about
recently,
we'll
pick
this
pick
up
on
friday,
the
new
dscp
selection
draft,
the
nqb
php
draft
and
udp
options
and
then
down
at
the
end,
and
we
will
try
very
very
hard
to
get
here.
I
think
we've
short
changed
more
than
once
we
will
get
to
marcus's
draft
of
multi-path
dccp,
for
which
rook
adoption
is
is
requested,
and
I
will
go
fix
that
draft
name
and
upload
the
slides.
B
That's
not
the
right
name
either
you
tell,
I
did,
did
last
minute
slide
preparation,
so
a
slide
from
fixing
the
bugs
in
the
slides.
Does
anybody
want
to
bash
the.
B
B
Okay,
seeing
nobody
I'm
going
to
see
the
agenda
bash.
Let's
quickly,
do
the
liaisons
hang
on.
I
got
to
go
switch
windows
there.
Okay,
let's
click
through
the
liaisons
and
I've
got
to
go
fix
these
slides,
okay,
so
the
wba
liaison.
We
got
to
be
a
liaison
that
basically
suggested
in
pursuit
of
of
qos
and
nqos
across
wi-fi
and
5g
that
the
ietf
ought
to
work
on
a
on
a
mapping
between
5g,
5qis
and
idfjcps.
B
Response
was
sent
back
to
the
to
the
wba,
indicating
a
plausible
area
of
focus
and
we'll
wait.
We'll
we'll
wait
to
see
what
we
hear
back
from
them.
A
A
It
was
a
request
to
update
that
spec
and
mainly
to
send
larger
payloads,
and
we
have
taken
a
work
item
to
service
that
if
we
try
and
keep
to
their
deadline,
we'll
have
to
be
sharp
and
quick
on
completing
it.
So
we'll
just
move
and
the
oh
gsma
relates
to
the
dccp
work.
That's
going
to
be
discussed
for
adoption
later
this
week
and
as
we
discuss
that
we'll
be
able
to
provide
more
feedback
to
that
group.
B
Okay
sounds
good
with
that.
I
think
I'm
I
I
get
to
exit
and
go
go.
Go
fix
my
slides
wes
you
get
to
organize
the
l4s.
B
D
Okay,
so
we
wanted
to
do
a
quick
recap
on
the
state
of
the
four
working
group
adopted
l4s
drafts
and
wanted
to
start
with
letting
people
know
that
we
had
a
virtual
interim.
D
I
think
it
was
a
couple
of
months
ago
and
well
may
10th.
It
says
on
this
chart,
and
this
was
focused
on
two
topics.
There
were
a
few
dozen
attendees
and
we
wanted
to
try
to
make
progress
in
the
working
group
on
the
two
classes
of
issues
that
we
still
saw.
A
lot
of
discussion
on
going
on
and
the
the
first
topic
was
finalizing
transport
requirements
for
l4s
id
use.
D
There
was
a
lot
of
feedback
about
the
reasonableness
of
the
requirements
for
implementers
to
take
and
be
able
to
build
something
with
and
multiple
implementation
teams
provide
feedback,
and
we
think
we're
in
a
good
state
on
that
now
after
some
document
updates
happen
following
interim
and
then
we
also
wanted
to
make
more
time
for
interactive
discussion
on
the
safe
for
experimentation
on
the
internet
topic,
and
that
continues
to
be
one
where
we
have
lively
discussion
on
the
mailing
list.
Some
good
things
have
happened
since
the
last
cycle.
D
So
there
bob
will
talk
about
more,
but
there's
been
work
on
the
anti-replay
and
resequencing
kinds
of
things
that
could
lead
to
problems
when
reordering
is
induced,
potentially,
and
I
think
that's
moving
in
the
right
direction
on
that
topic.
D
We
also
in
general,
pulled
the
working
group
at
this
interim
on
whether
people
were
feeling
that
the
mechanisms
defined
were
suitable
for
experimentation
in
parts
of
the
internet.
There
was
not
full
agreement,
yet
there
are
some
issues.
D
I
think
david
actually
has
a
recap
list,
we'll
briefly
go
to
before
bob's
charts,
but
there
was
a
majority
of
the
working
group,
actually
a
strong
majority
that
were
participating
that
meeting
and
felt
we
were
able
to
effectively
use
the
developing
operational
guidance
draft
to
safely
proceed
with
experimentation,
and
so
I
think,
we're
now
feeling
like
we're
ready
for
next
steps
of
making
a
quick
document
update
that
the
editors
have
agreed
to
on
removing
any
potential
suggestion
about
changes
to
ipsec.
D
We
don't
want
that
to
be
on
the
table.
Ipsec
is
ipsec
as
it
is
today
and
l4s
isn't
going
to
change
it,
and
we
want
to
take
the
three
protocol
documents
to
working
group
last
call
to
gauge
whether
there
support
the
working
group
to
publish
these
and,
in
the
meantime,
we're
continuing
work
on
the
l4s
draft.
I
guess
bob's
in
the
queue
already
go
ahead.
Bob.
E
Now
I
just
wanted
to
say
that
the
draft
would
have
been
updated
with
that
change,
but
there's
an
xml
problem.
It
now
insists
on
the
new
version
of
already
filed
a
bug
months
ago,
which
I
can't
get
past.
So
I
can't
post
the
draft
at
the
moment,
but
I'll
have
to
sort
that
out
with
a
bit
longer
time
to
do
it.
Okay,.
D
So
yeah
the
high
order
bit
is
that
that
update
update
is
going
to
happen
as
soon
as
bob
sorts
out
the
xml
issue,
and
then
we
will
be
planning
on
starting
a
working
group.
Last
call
on
these
three
documents.
David
has
a
list
of
issues.
I
can
hand
the
paul
to
you
now
david,
if,
if
it's
good
david
has
a
list
of
things
that,
from
his
standpoint,
we've
heard
are
still
concerns
in
the
working
group.
D
G
A
B
Icon
shouldn't,
I
all
right.
Let's
start
over
again,
these
these
slides
were
assembled
working
with
jonathan
morton
and
a
number
of
other
folks
who've
been
expressing
concerns
about
lfrs.
B
So
I'm
going
to
basically
quickly
re,
read
these
into
the
record
and
then
hand
control
back
over
to
to
wes
figure
out
to
take
me
forward.
So
the
first
slide
concerns
l4s
internet
coexistence.
B
Receiver
can't
distinguish
whether
ce
marching
on
packets
are
are
from
l4s
or
rfc
3168
marking
it's
a
fundamental
confusion
that
underpins
a
lot
of
the
alphas
issues.
You'll
see
on
these
slides
and
particular
is
not
compatible
with
rfc
4774
option.
Three
friendly
coexistence
offers
transports
assuming
ce
mark
124
signals
was
often
not
the
case
today.
The
schneider
middle
box
deployments
of
rsc
3168
alternative
backup
with
ecn
rcd511
still
requires
multiplicative
decrease
normal
force
transports.
Don't
do
that
if
l4s
and
conventional
flows
share
a
fifoq
and
aqm,
the
conventional
flow
may
suffer
badly.
B
Perhaps,
even
though
the
five
three
criminal
cards
from
all
typical
rfcs
and
the
general
state
of
things
is
safety,
compatibility
and
coexistence
are
still
problematic
in
the
running
code.
That's
available
for
l4s
all
right
now.
Second,
second
slide
is
that
this
is
about
mostly
about
the
dual
queue
structure
and
the
eq
do
qaqm.
B
That
structure
is
creating
our
service
model.
Building
some
tunnels,
which
have
a
replay
window
attacker
advances
protect
window
by
sending
low
latency
traffic
conventional
traffic
arrives
after
window,
has
advanced
and
gets
discarded
rather
than
forwarded.
B
It
gives
an
uncontrolled
throughput
bonus
to
traffic
on
the
low
latency
queue
ease,
exploited,
no
enforced
congestion
control
or
required
admission
control
in
it.
You
know
before
this
is
currently
proposed.
A
diff
served
php
would
likely
require
mission
control.
Take
a
look
at
the
other
voice,
admit
php,
as
as
an
example
acre
algorithm
disadvantage,
fragments
small
mq
traffic,
because
it's
congestion,
marking
algorithms
bias
in
small
packets
and
the
dual
qa
algorithm
is
intolerant
of
bursty.
Traffic
bursts
from
real-time
video
or
bursty
link.
B
D
So
I
think
bob
you're
going
to
provide
a
update
on
what's
happened
in
the
drafts.
Do
you
want
me
to
project
charts
or
do
you
have
them
yeah?
I
apologize
I'll
have
to
do
it
from
the
browser,
so
they
won't
be
properly
zoomed
and
such,
but
I
can
do.
E
That
can
I
just
while
you're
doing
that
clarify
david
were
those
was
that
you
presenting
those
slides
or
was
that
you
presenting
them
for
jonathan
and
was
it
you
presenting
them
as
a
chair
or
what.
B
I
think
it's
a
it's
a
mix,
the
issues
arise
from
jonathan
and
a
number
of
collaborators,
and
I'm
passing
them
along
as
preview
of
coming
attraction.
We're
going
to
get
to
deal
with
these
when
we're
another
working
group
last
call
right
because
I
mean
well.
I
wouldn't
have
disputed
many
of
those
points.
So
I
understand
that-
and
this
was
this
was
not.
B
This
was
not
intended
as
an
authoritative
statement
of
of
this
is
this
is
the
way
things
are,
but
a
heads
up
this
is
this-
is
this
is
a
little
bit
of
the
adventure?
That's
coming
yeah,
okay,.
E
All
right,
so
this
is
I've,
been
asked
to
just
do
a
sort
of
more
administrative
update,
but
there's
some
interesting
stuff
in
here
as
well.
So
this
is
about
all
three
alfres
drafts.
Just
got
10
minutes
next.
E
And
this
is
a
very
quick
recap
of
what,
for
us,
is
essentially
very
low
queueing
day
for
all.
It
could
delay
for
all
internet
applications,
not
just
for
some,
including
capacity
seeking
ones,
so
you
get
full
throughput
next.
E
So
before
we
get
on
to
the
drafts
just
a
bit
of
activity
outside
of
the
itf
just
to
keep
people
updated
on.
What's
going
on
in
the
3gpp
emr
reports
to
us
in
our
johnson
that
things
are
progressing
on
alfres
in
3gbp
and
the
current
favor
is
for
for
us
to
have
5g
cause
identifiers,
a
5g
cause
identifier
to
separate
it,
which
sort
of
seems
strange.
E
But
we
can
talk
about
that
and
then
use
feedback
and
forward
much
like
the
master's
thesis
that
you
are
pointed
to
that
was
done
under
his
supervision
rather
than
adding
ecm
bits
down
at
the
radio
link
control
layer.
E
The
there's
a
also
engineer
has
pointed
us
to
a
couple
of
papers,
one
with
a
lot
of
useful
simulation
results
with
performance
evaluations.
So
there's
generally
a
lot
going
on
there.
One
more
cable
modem
has
been
certified
for
low
latency
docsis,
which
is
includes
the
support
for
alfres
like
low
lansing.
Does,
therefore,
that
modem
does
and
nokia
reports
that
they
have
more
wi-fi
devices
they've
released
and
soon
some
fixed
wireless
access
ones
that
support
l4s
and
they've
also
initiated
several
trials
with
operators
and
application
providers.
E
We've
had
pete
heist,
continuing
testing
and
evaluation,
which
greg
mentions
in
his
talk,
so
I
won't
say
any
more
on
that
here
and
some
really
good
work
on
the
linux.
Implementation
of
the
whole.
The
whole
suite,
but
primarily
tcp,
prague
and
and
particularly
acura
ecm,
is
now
available
for
vbr,
decent
tcp,
tcp
plugins,
in
fact
any
congestion
control
in
in
linux.
E
So
you
can
do
sort
of
a
b
testing
changing
the
congestion
control
without
also
having
to
change
the
feedback.
So
you
you
can
look
for
differences
in
the
congestion
controls
that
without
being
confused
by
the
feedback.
That's
everything
so
far
on
that.
So
next,
please.
E
All
right,
so
the
three
drafts
I'm
going
to
go
through
just
very
quickly
what
has
changed
in
them
and
why
vde
gave
a
great
review
of
alfresar
architecture
document,
which
is
now
at
draft
10..
It's
been
there
for
most
of
the
month
asked
to
explain
how
an
fq
frs
node
works
a
bit
more
clearly,
so
have
done
that.
E
I
won't
say
now
how
you
can
go
and
read
the
draft,
and
there
were
some
numerical
examples
of
what
the
scaling
problem
was
with
reno
and
cubic,
and
it
didn't
include
cubics
renault
friendly
mode,
so
that's
now
fixed
and
the
numbers
are
all
fixed
and
extensive
clarifications,
et
cetera
improvements
based
on
vidi's
comments
and
you'll
see
all
that
having
gone
on
the
list
as
well.
E
So
next,
so
the
architecture
draft
is
now
up
to
spec,
at
least
as
far
as
really
could
find,
and
the
ecm
protocol
for
l4s,
which
is
econo
press
id,
would
be
19.
As
I
said,
that's
where
I
put
the
plus
plus
here,
except
I
couldn't
post
it,
and
thank
you
stuart
for
the
advice
I
think
I'll
just
end
up
posting
it
without
the
xml.
E
The
interaction
with
the
vp
vpn
anti-replay
protection
that
was
talked
about
before
the
essentially
we
have
stuck
to
talking
about
vpn
configuration
in
the
draft.
Given
it's
not
meant
to
be
in
scope
to
talk
about
vpn
implementations
and
changes
to
them.
That's
how
to
scope
for
l4s.
E
So
we've
focused
on
configuring,
the
the
vpn,
so
it's
got
sufficiently
large
anti-replay
window
which
gets
rid
of
the
attack
that
or
if
you
do
that,
and
of
course
that
is
the
big.
If,
then,
you,
you
won't
have
that
problem,
and
you
won't
have
the
relative
to
the
attack,
which
was
mentioned
in
those
slides
jonathan
pointed
out,
and
we
have
put
the
put
the
attack
in
the
security
considerations
and
documented
all
this,
and
thank
you
very
much
for
sebastian
originally
for
pointing
it
out.
E
There's
something
david
wanted
done.
Rc4774
is
cited
in
the
draft
and
it's
put
in
better
context.
Thank
you
for
that.
I
hope
it's
now.
Okay,
lots
of
consistency
between
drafts
done
and
the
editorial
changes
and
a
couple
of
things
we
haven't
changed,
one
of
which
I've
just
been
talking
with
on
the
list.
E
I
put
out
a
general
request
on
into
area
and
panels
lists
for
whether
there's
any
likelihood
that
there
are
any
tunnels
that
do
resequencing
and
l2tp
can
do
it,
but
it's
generally
used
for
the
control
channels
and
derek
has
pointed
out
that
there
are
gtp
towers
that
do
that
and
there's
also
a
microsoft
vpn
product.
E
Now
it's
just
a
question
of
whether
we
need
to
say
don't,
go
and
enable
re-sequencing,
because
then,
if,
if
anything,
if
there's
any
change
in
the
order
of
the
packets
within
that
tunnel,
you
know
where,
where
your
el
press
traffic
is,
is
put
through
the
queue
before
the
classic
traffic,
three
sequencing
will
just
put
it
all
back
the
other
way
again
and
put
it
back
how
it
was
when
it
started.
E
E
They
wouldn't
then
re-signals
it.
So
it
didn't
have
low
delay
anymore.
So
it's
sort
of
it's
just
a
question
of
whether
we
ought
to
put
in
something
that's
slightly
patronizing,
to
tell
people
not
to
do
something
daft.
So
we
can
have
some
conversation
on
that
during
the
wedding
group.
E
Last
call,
but
it's
not
something
I'd
like
to
put
in
the
draft
if
you
don't
have
to,
but
only
because
I
find
it
rather
patronizing
to
people
and
the
work
we
did
mostly
at
the
at
the
interim
on
the
product
requirements
or
up
to
the
interim,
which
is
mostly
in
section
four.
It's
been
pretty
stable
since
then,
and
the
the
comments
we
had
from
all
the
developers
were
very
useful
change
the
text
and
it
seems
that
they're
now
happy
with
that.
E
Obviously,
we
haven't
had
any
further
requests
to
change
anything,
so
that's
that
next.
E
E
Actually,
I
don't
think
anyone's
ever
ever
had
a
nine
page
report
on
why
one
particular
parameter
is
set
to
a
certain
number,
but
it
goes
into
some
depth,
including
lots
of
survey
of
the
characteristics
of
the
internet,
different
countries
and
all
the
rest
of
it
and
added
some
justification
for
why
the
other
parameters
are
set,
the
way
they
are
all
in
the
appendix.
So
I
just
wanted
to
jump
to
the
next
side.
How
long
have
we
got?
Where
are
we
yeah?
E
I
can.
I
was
going
to
jump
this
if
we
hadn't
got
time,
but
just
to
say
that
part
of
that
exercise
of
doing
the
parameters
justifying
the
parameter
involved,
justifying
the
target
15
millisecond,
then
we're
looking
at
the
the
rtt
around
the
world
to
from
user
to
cdn,
using
a
ripe
atlas
and
probes
study,
and
this
plot
shows
those
figures,
along
with
the
average
bandwidth
per
country
from
another
study
as
a
scatter
plot,
and
just
just
for
everyone's
interest.
E
We've
put
on
top
of
that,
the
the
curve
at
which
cubic
switches
to
or
from
its
reno
friendly
mode
and
discovered
that
actually,
once
you
introduce
aqms
and
this
this
allows
for
the
15
millisecond
target
in
the
aqm.
So
the
points
have
shifted
up,
15
milliseconds
from
their
base.
Rtts,
then
still,
nearly
everyone
in
the
world
is
running
reno,
even
if
they
think
they're
running
cubic,
or
at
least
it's
not
quite
the
same.
Because
you
get
a
you
get.
You
still
get
the
acceleration,
but
essentially
you're
running
an
unscathed.
E
You
know
the
completely
unscalable
reno
and
it
looks
like
no
matter
how
much
we're
trying
to
get
away
from
it.
We
know
still
there
underneath
everything
next.
D
Yeah
we
were,
we
were
planning
to
save
q
a
for
after
greg's
talk
just
because
the
agenda
is
so
tight,
so
greg.
Did
you
want
to
project
your
own
charts,
or
do
you
want
me
to
try
to
pull
those
up
too.
F
I
can
try
to
project.
I
have
not
tried
that
before
with
meet
echo,
but.
F
Slides,
yes,
yes,
okay!
Thank
you
all
right,
so
this
is
the
update
on
the
l4s
ops
draft
and,
as
a
reminder,
I'm
the
editor
of
the
draft,
it's
product
of
contributions
from
a
number
of
people
within
the
working
group
and
as
as
I've
said
in
the
past,
if
you
think
there's
something
missing
from
this
draft
or
something
could
be
written
better
explained
better.
F
Certainly,
comments
are
helpful.
Contributions
of
text
to
address
the
issue
is
even
more
helpful,
so
a
reminder
on
the
scope
of
the
draft
and
its
current
status.
F
This
is
intended
to
focus
on
the
concern
that
was
raised
around
the
possible
rate
imbalance
in
shared
queue,
rfc
3168
bottlenecks.
So
many
of
the
issues
that
were
listed
in
in
the
slides
a
few
minutes
ago
that
david
presented
it's
intended
to
provide
guidance
for
operators
of
n-hosts,
operative
networks
and
researchers
in
order
to
identify
if
those
issues
actually
exist
in
practice
and
how
to
prevent
them
from
from
causing
rate
and
balance.
F
The
work
group
drop
adopted
the
draft
in
march
of
this
year
and
since
then
there
have
been
two
working
versions
posted
I
presented
at
the
interim
meeting.
The
draft
zero.
F
Then
draft
one
I
have
uploaded
just
recently.
This
is
not
a
draft
that
we're
seeking
working
group
last
call
on
currently,
as
was
discussed
earlier
on
a
little
bit
longer
timeline
in
terms
of
the
deltas
in
draft
one
versus
the
previous
version.
F
Not
a
lot
of
major
change
in
this
draft.
Probably
the
biggest
change
is
organizational,
but
it
does
have
have
some
importance
to
it.
That
is
the
the
op
options
that
we
describe
for
network
operators,
operators
of
networks
that
implement
rfc
3168
bottlenecks,
we've
organized
those
into
a
preferred
set,
a
less
preferred
set
and
a
last
resort
set
and
I'll
talk
a
little
bit
more
about
that
in
a
couple
slides
also
added
a
mention
of
afd
or
approximate,
fair
dropping,
which
is
a
feature
supported
by
some
switch
equipment.
F
I
think
primarily
cisco
equipment
and,
as
we've
added
a
section
on
that
and
how
it
could
be
configured
to
address
the
issue,
a
mention
of
who
is
impacted.
Specifically,
it's
generally
not
going
to
be
the
l4s
experimenter
that
sees
any
degradation
and
throughput
if
there's
a
shared
3168
bottleneck.
F
So
that's
mentioned
more
more
upfront
than
document
document
added,
more
discussion
of
fq,
including
a
request
from
pete
heist
to
discuss
a
configuration
that
is
used
apparently
by
some
network
operators
where
they
use
the
linux,
fq
coddle
q
disk,
but
configure
the
hashing
in
a
way
that
turns
it
instead
of
a
per
flow
cueing
system
into
a
per
user
queuing
system
and
result
of
that
is
that,
from
each
user's
perspective,
they're
effectively
seeing
a
single
shared
queue,
running
caudal,
and
so
it
looks
an
awful
lot
like
the
situation
that
this
draft
is
intending
to
talk
about.
F
So
that's
discussed
here
and
then
a
little
bit
more
detail
on
some
of
the
recent
detection,
experiments
that
had
been
done
fairly
recently,
apple's
study,
jay
collins
study
and
then
pete
heiss
work
with
a
czech
isp
and
then
a
mention
of
a
measurement
study
less
to
do
with
ce
detection,
but
more
just
monitoring
traffic
and
looking
at
prevalence
of
ecn
marking
all
right.
The
outline.
I
won't
go
this
go
through
this
in
detail.
F
F
What
can
you
do
to
make
things
work
better
in
the
all4s
world
and
as
we
split
these
options
again
into
these
three
buckets,
the
ones
that
fall
into
the
less
preferred
or
last
resort
options
are
options
that
have
some
downside
to
them.
That
may
outweigh
the
benefits
that
that
they
would
provide,
and
so
that's
why
we've
split
those
out
into
separate
sections
or
subsections.
I
should
say
in
particular
the
less
preferred
options.
There
were
several
that
are
listed
there.
F
I
grouped
them
all
for
purposes
of
this
slide
into
a
single
bullet
treat
ect1
as
not
ect,
and
so
that
addresses
the
fairness
imbalance
that
could
potentially
exist
with
classic
traffic
mixed
with
l4s
traffic.
The
downside
to
it
is
it
disables
low
loss
for
the
l4s
traffic.
Basically,
l4s
traffic,
then
is
treated
as
not
ect
and
would
see
packet
loss
as
its
congestion
signal.
F
F
The
bottom
two
in
the
last
resort
section
are
still
included
in
the
draft.
I
think
I've
gotten
a
comment,
at
least
from
one
person
that
maybe,
since
those
are
the
last
resort
options,
maybe
we
really
shouldn't
even
be
mentioning
them.
We
do
explicitly
indicate
that
these
are
not
recommended,
but
they're
listed
more
or
less
for
completeness,
I'm
turning
off
3168
support
altogether.
F
So
no
ecn
support
in
the
network
would
be
one
and
revert
the
network
to
classic
packet
drop
behavior
and
then
the
other
one
bleaching,
the
ect1
packets,
to
not
ect,
as
listed
as
well
also
addresses
the
fairness
and
balance,
but
then
not
only
disables
l4s
within
the
network
that
has
the
3168
equipment
but
elsewhere
down
the
path
as
well,
and
if
that
option
is
implemented
by
a
lot
of
networks,
would
make
any
potential
future
use
of
ect1
in
the
event
that
the
l4s
experiment
ends
and-
and
we
decide
to
try
to
reclaim
that
code
point
for
a
different
purpose
would
make
that
more
difficult.
F
So
the
rest
of
the
options
I'll
go
back
up
at
the
top.
The
preferred
options
are
listed
more
or
less
in.
I
think
a
preference
order,
starting
with
upgrading
those
bottlenecks,
to
be
elf,
for
us
aware
as
being
the
the
most
beneficial
approach
and
then
a
number
of
options
that
may
be
more
easily
implemented
in
some
equipment,
but
don't
provide
all
the
benefits
that
complete,
l4s
awareness
would
provide,
and
then
the
one
at
the
bottom
of
the
preferred
options
list
do
nothing.
F
So,
in
situations
where
fairness
about
imbalance
is
not
considered
to
be
an
issue
is
doing,
nothing
is
better
than
the
options
that
are
later
in
the
slide.
F
So
that's
again
the
main
change
so
far
in
this
draft.
In
addition,
there
are
some
expectations
on
how
the
experiment
goes
and
how
it
gets
deployed,
as
as
we
move
into
the
the
start
of
the
experiment.
F
Some
of
this
is
mentioned
in
the
draft.
In
section
five
of
the
draft
and
the
question
on
the
next
slide
is
too:
should
we
see
more
on
this,
but
general
view
is
that
starts
with
networks
enabling
l4s
support,
either
via
the
dual
queue
coupled
aqm
functionality?
That's
provided
in
that
draft
or
via
an
l4s
aware,
fq
implementation.
Those
are
both
options
that
have
been
discussed.
F
Quite
a
bit
in
the
in
the
working
group
and
then
along
the
same
timelines
as
network
enablement
of
the
of
the
feature,
applications
and
operating
systems.
Add
support
for
congestion
control
features,
both
receiver
feedback
and
the
senior
behavior
expectation
is
the
receiver
congestion.
Feedback
could
be
on
by
default
and
available,
and
then
the
center
behavior
starts
as
default
off,
and
that
is
kind
of
the.
F
F
Rather
that
end
host
operators
would
selectively
enable
l4s
on
senders
and
use
some
canary-based
methods
of
turning
it
on
on
a
subset
of
paths
or
a
subset
of
connections
on
paths
and
leaving
other
paths
or
other
connections
with
either
classic
ecn
or
not
ect,
and
then
comparing
the
the
performance
across
those
different
variants
and
and
those
types
of
methods
used
in
a
progressive
way
right,
starting
off
with
lab
tests,
moving
to
limited
fuel
tests,
large-scale
field
test,
etc.
And
so
the
idea
is
to
run
an
experiment
in
a
a.
F
As
far
as
I
know,
in
the
draft
a
couple
of
items.
D
C
F
So
I
so
there
is
text
in
section
five
that
mentions
progressive
deployment,
so
starting
with
lab
tests
and
and
and
increasing
from
there
nothing
that
nothing
mentions
canary-based
methods.
So
that's
kind
of
the
question
I
had
for
the
group
is:
should
we
say
more
on
that
in
order
to
give
experimenters
more
guidance.
A
F
B
With
corey,
I
think
it
would
be
good
to
write
this
up
in
particular,
because
this
is
one
of
the
very
few
things
we
seem
to
have
available
to
us.
That
might
help
with
the
innocent
bystander
concern.
F
Okay,
good
yeah.
I
would
definitely
appreciate
suggestions
on
text
for
that,
so
gory
I'll
definitely
take
you
up
on
that.
A
F
Yeah,
I
think
it's
a
it's.
A
common
technique
used
for
deploying
new
features
on
internet
services
in
general,
beyond
even
congestion
control
right,
so
I'm
sure
there's
a
lot
of
material.
We
can
draw
on
and
expertise.
D
I
think
it
would
be
meaningful
if
the
people
who
are
concerned
about
the
effect
on
bystanders
would
find
this
compelling
that
you
were
adding
it
and
fleshing
out
more
information
and
guidance
on
it,
but
I
guess
jonathan's
in
the
queue-
maybe
maybe
he's
going
to
talk
about
this,
go
ahead.
Jonathan.
G
So
I
I
don't
yet
have
any
opinion
the
canary
based
stuff,
I'm
going
to
have
to
have
to
see
how
powerfully
is
this
defined,
but
who
was
going
to
talk
about
short
flows
that
they
just
point
out
that
tens
is
definitely
too
long
to
be
the
short
flow.
F
Okay,
fair
enough
yeah.
That
was
a
comment
that
showed
up
on
the
mailing
list.
F
F
And
I
can't
see
the
mic
cue,
so
I'm
on
full
screen
here.
So
if
there
are
others.
D
Do
not
see
anyone.
Thank
you
at
the
moment.
I
don't
know
if,
in
response
to
that
you're
asking
jonathan
back
what
he
thinks
a
short
flow
should
be.
I
I
heard
him
say:
10
seconds,
isn't
a
good
magic
number,
but
I
and
you
say
you're
asking
for
feedback
on
that,
but
I
don't.
G
I
think
this
thing
about
short
flows
being
harmless.
It's
probably
the
other
rock
version
entirely,
but
when
we
have
a
if
we
start
starting
a
bike
flow
in
petition
with
a
iptv
setup
box,
the
ipv4
dv
setup
top
box
comes
out
of
buffer
in
tens
of
seconds.
G
B
F
Comments:
okay:
I
was
double
muted
there,
so
I
don't
think
it
can
be
coming
from
me,
but.
F
Yeah,
jonathan
or
I
guess
it
was
pete
who
brought
it
up
on
the
mailing
list.
If
there
is
a
different
way,
you
think
we
could
describe
that.
That
is
more
useful
to
application
developers
and
deployers
of
of
servers.
I'd
be
interested
in
in
reviewing
that.
I
think
the
key
thing
is
this
is
a
steady
state
unfairness
situation
right
where
the
imbalance
in
interpretation
of
ce
marks
results
in
the
appearance
at
steady
state.
F
So
I
think
it's
something
like
you
know,
flows
that
exit
the
startup
behavior
and
are
in
a
congestion
avoidance
mode,
and
how
do
we
define
that
in
a
in
a
way?
That's
easy
for
a
server.
H
F
You
have
flows
that
are
long
enough.
That.
F
Their
you
know,
I
think,
we're
past
the
initial
startup,
where,
where
the
flow
is
pushing
into
the
the
channel
trying
to
make
space
for
itself,
where
we
expect
other
flows
to
be
impact
right
there,
they
have
to
throttle
down
to
allow
the
new
flow
in
at
some
point,
at
the
end
of
that,
you
get
into
this
regime
where
it's
possible
for
the
different
interpretation
of
the
ce
marks
to
cause
low
throughput
for
a
classic
ecn.
F
10
seconds
is
an
example
that
was
given
in
in
the
document
currently,
but
that
was
intended
to
be
the
entire
flow
completion
time
of
that
flow.
But
clearly
we
can
say
something
better
on.
A
E
Yeah,
I
just
wanted
to
say
that
this
is
a
difficult
area,
because
it's
also
true
that
if,
when
a
new
flow
enters
a
system,
the
the
system
gives
its
capacity
to
quickly.
E
You
know
like
if,
if
another
flow
is,
has
a
certain
amount
of
capacity
and
then
suddenly
it's
cut
to
half
say
because
two
flows
appear.
That
can
also
be
a
problem
for
the
for
the
first
floats.
It
just
doesn't
have
time
for
the
application
to
adapt
it.
So
you
know
there
there
is
some
number
that
and
that
is
required
here
to
you
know
you
mustn't,
have
immediate
fairness
either
or
it's
not
necessarily
good.
To
have
immediate
fairness.
E
I
won't
say
you
mustn't,
and
so
one
also
has
to
look
at
the
behavior
of
of
non-alpha
s
flows
and
how
long
they
take
to
converge,
which
can
be
you
know,
multiple
tens
of
seconds
and
now
certainly
they
they
reach
near
convergence.
You
know,
maybe
maybe
after
10
seconds
or
something
but
there's
you
know,
if
we're
trying
to
make
things
exactly
fair
all
the
time.
That's
that's
not
a
good
idea,
I
don't
think
and
and
so
there's.
E
If
I
don't
think
we
could
put
a
number
on
it,
but
we
can
say
something
relative
to
other
the
behavior
of
other
flows,
and
you
know
it
shouldn't
be
any.
You
know
significantly
worse
than
other
flows
or
something
like
that,
how
long
they
take
to.
D
Does
anyone
else
have
comments
on
the
l4s
ops
draft
or
the
other
three
l4s
drafts
that
we're
bringing
to
working
group
last
call
after
the
meeting.
E
I
need
to
quickly
say
I
have
now
posted
that
update
to
the
id
draft
perfect.
D
B
Is
that
one
of
the
purposes
of
working
class
call
is
to
round
up
the
issues,
let's
figure
out?
What
we
are
looking
at
that
is
is
a
is
a
potential
problem
error
in
the
draft,
and
where
do
things
stand?
Not
all
working
glass
calls
are
successful.
I
speak
as
the
shepherd
of
a
draft.
It
took.
Three
working
glass
calls
to
get.
B
D
Yep,
I
think
that's
a
good
thing
to
point
out
last
call
doesn't
mean
the
drafts
are.
D
D
Okay,
well,
that
was
all
we
had
on
the
agenda
for
today,
and
we
have
one
minute
left.
A
Well,
I'd
say:
it'd
be
really
good
to
come
to
the
next
meeting,
where
we
discuss
all
the
other
drafts,
so
the
we're
also
going
to
be
organizing
some
interims
as
we
look
to
see
what
work
is
left
over
at
this
ietf.
So
this
is
a
meeting
where
we're
going
to
move
quickly
through
a
lot
of
material
in
the
next
session.
So
my
reason
for
mentioning
now
is:
please
have
a
look
ahead
and
think
what
it
is
that
you
really
want
to
talk
about
in
the
next
session.