►
From YouTube: IETF110-TSVWG-20210310-1430
Description
TSVWG meeting session at IETF110
2021/03/10 1430
https://datatracker.ietf.org/meeting/110/proceedings/
C
B
D
C
C
C
C
C
All
right
well
at
least
get
the
first
two
slides.
This
is
the
note.
Well,
you
should
be
familiar
with
it.
It
applies
to
you
as
a
participant
in
this
meeting
and
now
we're
onto
gory's
item.
We
need
a
note
taker.
Please.
Let
me
see
if
I
can
get
get
the
relevant
portion
agenda
pasted
into
the
the
notes
tool.
E
C
So
we
just
need
somebody
to
volunteer
to
please
try
to
to
capture
the
important
things
that
important
things
that
happen.
We
don't
need
the
blow-by-blow,
but
we
do
need.
We
do
need
to
record
important
points
and
important
decisions
being.
C
C
So
this
is
this
morning's
agenda.
It's
today
is
entirely
l4s.
C
I
got
one
more
slide
coming
as
you
can
sort
of
see
in
my
site
in
in
my
my
little
bar
on
the
side,
that'll
be
in
a
gender
recap,
then
we
need
to
look
at
the
operational
guidance
draft
for
which
adoption
has
been
requested
and
there's
a
call
in
progress
deal
with
the
main
alfred's
ecn
drafts,
and
then
ingomar
has
some
slides
on
the
relationship
of
on
something
about
l4s
and
5g.
And
let
me
let
me
take
back
relationship
word.
Let
ingomar
speak
to
exactly
what
he
intends
to
tell
us.
C
This
is
the
agenda.
Anybody
want
to
pass
it.
B
Can
I
go
ahead,
the
I
thought
we'd
made
it
clear
that
is
doing
7.2
and
I'm
just
wrapping
up.
So
I
just
sent
a
note
saying
I
don't
think
you've
got
slides
in
the
meeting
materials,
but
he
has
sent
them
because
he
cc'd
me.
C
At
7.3
right,
the
ecm
drafts
okay
agenda
bash
is
a
presenter
for
item.
A
C
Okay,
hang
on.
I
hope
the
screen
doesn't
go
away
when
I
do
this.
C
Give
me
a
minute:
okay,
okay,
so
if
I
hit
reload
here,
give
me
a
minute,
I
can
take
it
and
talk
everybody's
retrieving,
their
meeting
materials
right.
E
C
C
There
it
is
agenda
bashed,
second
set
of
slides.
C
This
is
the
chairs
view
of
what
needs
to
be
done
on
the
lforest
drafts,
so
I'm
gonna
read
this
and
with
luck
between
myself,
other
chairs
and
some
discussion,
we'll
have
some
clarity.
What
needs
to
happen
so
there's
two
there's
two
items
that
coming
to
this
meeting
need
attention.
The
first
is
transfer
protocol,
independent
requirements
to
ucl
forest
service,
and
the
goal
here
is
interoperability.
C
Multiple
transfer
protocols
able
to
meet
requirements,
specs
and
or
implementations
working
group
gets
to
decide
what
is
sufficient
and
that
the
dock
that
is
crucial
to
this
is
the
ecn
l4s
id
draft.
The
second
thing
needs
to
be
done.
Is
safety
of
internet
wide
authorized
experiment?
We
really
do
not
want
to
break
the
internet
in
doing
this
goal.
Is
that
the
experiment
is
unlikely
cause
it
can
damage
the
internet
and
any
damage
results
is
expected
to
be
tolerable.
C
The
draft
for
this
is
the
l4s
ops
draft
and
I'll
reiterate
something.
You
said
before.
Working
with
last
calling
alphas
office
draft
is
not
required
to
meet
the
safety
goal
so
that
that's
not
required.
What
is
the
criteria
for
both
goals
is
working
group
rough
consensus
that
each
goal
has
been
reached
and
the
working
group
chairs
we'll
put
on
our
kevlar,
we'll
put
in
our
kevlar
vests
and
figure
out
how
to
run
initial
consensus
calls
before
the
next
ietf
meeting
week.
B
Reason
can
I
say,
go
first
yeah.
I
I
that
it's
relatively
clear
yeah.
I
just
wanted
the
answers
to
the
questions
I
put
on
the
mailing
list,
which
is
which
is
more
about
the
text
in
earlier
emails
and
and
just
just
to
get
a
confirmation
that
you
didn't
mean
it.
Rather
it
just
disappeared.
You
know,
because
this
has
become
a
bit
of
a
no.
I
don't
want
that
rocket,
go
and
get
another
rock
sort
of
type
thing.
C
Okay,
to
continue
that
in
to
continue
that
this
this
slide
contains
the
descriptions
of
the
two
rocks,
get
those
two
rocks
and
we'll
and
and
we'll
be
and
and
we'll
be
in
good
shape.
I
the
crucial
question:
I
think
you
asked
about
whether
I
meant
it
was
do
we
need
two
interoperable
implementations
of
the
transport
protocols.
Honorable
for
us,
the
answer
is
no
working
group
gets
to
decide,
gets
to
decide
what
suffices
the
chairs
will
be
satisfied.
C
The
working
group
believes
that
that
the
requirements
on
the
transport
protocols
are
interoperable.
A
So
we're
talking
about
the
a
specification
with
some
requirements
and
our
implementations,
but
we're
not
talking
about
interop
here
we're
not
this
isn't
ps
status.
This
is
just
existence
status
right.
Does
that
help
basically.
B
C
Performance
and
safety
are
not
the
same
thing.
However.
Complete
absence
of
performance
I.e,
you
can't
get
traffic
there
from
here
starts
to
look
a
whole
lot
like
scenes.
B
C
B
Okay,
let's
move
on
unless
one
of
the
other
guys
wants
to
say
something.
G
Yeah,
can
you
hear
me
yeah,
maybe.
G
The
the
the
presentation
that
I
will
give
will
give
also
some
insight
on
on
what
implementations
or
plant
implementations
that
we
have
so
hopefully
that
will
help
to
decide
whether
it's
the
first
point
at
least
is
sufficient.
C
E
Is
is
this
a
like
already
determined
criteria,
or
is
that,
like
a
sort
of
goal
in
number
two
or
the
the
working
group
last
call
on
l4s
ops
not
required
to
meet
safety
goal
like
I
wasn't.
C
Yeah,
the
the
the
primary
reason
for
that
point
being
here
is
that
if
the
working
group
believes
that
the
l4s
ops
draft
lays
out
a
reasonable
safety
case,
but
there
is
still
quite
a
bit
of
work
to
be
done
on
it.
That's
not
a
reason
to
hold
up
work.
Group
last
call
on
the
elf
restaurant
on
the
alphas
drafts.
E
Okay-
and
this
is
a
point
for
discussion
so
important.
A
For
discussion,
it's
a
point:
jake
we
discussed
last
time
round
where
we
talked
about.
Would
the
experiment
actually
help
to
inform
the
operational
draft
to
inform
how
operators
did
things
so
did
we
want
to
close
this
before
we
started
the
publication
process,
or
did
we
want
to
make
sure
it
was
reasonably
good
shape
and
then
allow
that
draft
to
mature
a
little
bit
in
the
working
group,
and
we
didn't
really
decide
on
how
much
maturing
was
actually
useful
needed.
E
I
I
am,
I
tend
to
be
of
the
opinion
that
that
I
I
would
like
to
see
a
normative
normative
language
somewhere
in
the
experiment,
perhaps
referencing
the
draft,
I'm
not
sure
whether
the
whether
the
core
l4s
drafts
go
forward,
but
in
the
in
the
in
the
I
guess
we
can
get
to
that
later.
After
the
adoption
call
perhaps.
C
We
can
certainly
get
to
that
at
working
group
last
call
on
the
alpharestraf
requesting
a
normative
reference
from
the
alpharest
drafts
to
the
l4s
ops,
so
they
have
to
go
forward
as
rfcs
together
is
completely
reasonable.
As
a
last
call
topic,
if
not
yeah.
Thank
you.
A
E
Yeah,
I
guess
I
mean
you
know,
I'm
not
sure
exactly
what
form
it
would
take,
but
but
sort
of
the
the
to
rephrase
the
opinion
I
put
forth
before.
I
think
that
the
sort
of
current
tcp
prog
implementation
seems
incompatible
with
classic
cues,
et
cetera
in
source
sense
and
therefore
like
the
sort
of
guidance
around
as
a
l4s
sender,
ensuring
that
that
you're
operating
on
paths
that
do
not
contain
classic
cues
is.
E
Is
part
of
the
safety
story
in
such
a
way
that
that
I
I
would
prefer
to
see
some
kind
of
at
least
should
to
that
effect
and
and
the
details
of
how
the
drafts
precisely
point
to
each
other
and
whether
it
has
to
be
an
rfc
first,
I'm
I'm
flexible
on,
but
okay.
C
C
C
A
And
I
guess
the
position
of
the
chairs
on
the
normative
languages
if
we
need
normative
language
for
the
ops
work.
If
that's
what
the
working
group
concedes,
then
there
will
be
a
place
to
put
that
normative
language.
If
that's,
if
that's,
what
comes
out
we'll
find
a
place
to
do
it
if
the
working
group
needs
it.
So
the
fact
that
this
is
put
up
for
adoption
as
informational
doesn't
constrain
the
working
group
from
making
rst219
language
if
we
need
it.
C
H
Okay,
thanks
all
right,
so
this
is
the
second
or
except
the
third
iteration
of
the
alphas
ops
draft,
and
just
to
reiterate
what
I
said
last
time,
I
presented
I'm
the
editor
of
this
document.
The
contributors
include
those
listed
at
the
bottom,
as
well
as
probably
others
on
the
working
group
who
have
done
reviews
and
and
made
suggestions.
H
Hopefully
I
didn't
miss
folks,
but
contributions
of
text
to
improve
the
draft
are
welcome,
and
I
assume,
if
this
gets
adopted
by
the
working
group,
that
we'll
see
more
of
you
and
and
more
contributions.
So
our
next
slide
the
scope
of
the
draft,
so
as
the
the
name
of
it
is
operational,
guidance
for
deployment
of
l4s
and
the
internet
that
may
sound
like
it's
covering
more
ground
than
it
actually
is.
H
The
scope
of
the
craft
actually
is
specific
to
the
issue
of
coexistence
of
l4s
traffic
and
classic
traffic
in
an
rfc
3168
bottleneck.
H
It
has
expanded
since
the
last
iteration
and
to
now
discuss
vpns
in
fq
bottlenecks,
as
well
as
single
cube
bottlenecks.
Although
more
elaboration
that
could
certainly
be
added,
the
goal
is
to
provide
guidance
for
operators
of
l4s
hosts
as
they
deploy
all
for
us
on.
The
internet
also
guidance
for
operators
of
networks,
in
particular
networks
that
are
currently
running,
rfc,
3168
links
and
then
finally,
recommendations
for
researchers
and
the
goal
of
this
document
is
not
just
to
cover
in-band
detection
and
fallback
and
that's
an
aspect.
H
That's
been
discussed
within
the
working
group
paramount
over
the
last
year
or
more.
It
does
include
that,
but
it
also
includes
some
other
aspects
related
to
safe
deployment
of.
H
A
I
lost
great
video
as
well,
so
he'll
be
back
in
a
moment.
I
guess.
C
A
C
A
So
I
just
started
a
poll:
if
you
go
to
the
little
bar
chart
at
the
top,
this
one's
an
easy
one,
how
many
people
have
read
the
oh?
You
spelled
people
correctly.
I
didn't.
I
have
read
the
ops
draft
in
one
of
its
versions,
just
so
we're
going
to
feel
as
a
working
group.
If
you
click
on
that,
please,
if
you've
read
one
of
these
versions,
so
we
know
whether
we're
judging
something
that
people
have
actually.
A
C
C
C
I
A
Currently
see
14
people
have
raised
hands,
25
have
not
pressed
the
do
not
raise
hand
button
of
85
participants,
so
we
have
a
number
of
people.
Who've
raised
their
hands,
saying
that
they've
read
this
and
I'm
going
to
end
the
session
just
now
and
then
we'll
go
back
to
greg's
presentation,
I'll
report
for
the
notes
how
many?
Finally,
finally,
we
had
17
people
said
that
they'd
read
this
or
a
recent
version
of
the
ops
draft,
so
17
had
read
it
and
we'll
continue
this
after
greg's
talk.
If
greg's
able
to
join
us
now,.
H
Great,
I'm
not
sure
when,
when
you
lost
me,
did
I
get
through
the.
C
School
play
probably
about
the
probably
about
at
somewhere
after
provide
recommendations
to
researchers.
If
you
quickly
cover
the
last
two
thirds
of
the
slide,
let's
see
if
we
move
through
the
rest
of
the
slides
quickly,.
H
Okay,
well,
the
middle
bullet
is
just
a
high
level
scope.
Well,
it's
a
little
bit
more
detailed
than
the
top
bullet,
but
in
a
couple
slides
we'll
go
through
the
a
summary
of
the
contents,
so
I
won't
spend
time
on
that
one.
H
The
last
bullet
is
just
to
point
out
that
general
requirements
for
the
experiment
etc
are
intended
to
be
included
in
the
core
l4s
drafts,
not
in
this
one,
but
this
draft
does
rely
on
requirements
that
exist
in
the
l4s
id
draft,
including
the
ability
for
a
host
to
disable
the
l4s
functionality
and
for
a
host
to
monitor
or
provide
statistics
that
can
be
used
to
monitor
for
presence
of
rfc
3168
all
right
next
slide
status.
This
is
the
third
version
of
the
draft
previous
ones
were
discussed
on
previous
ietfs.
H
A
new
material.
This
time
addressed
some
comments
around
mentioning
mentioning
vpns
and
fq
coddle.
That
combination
as
well
as
added
discussion
on
fairness
and
purple
awareness
and
and
then
some
general
text,
improvements
which
we
can
just
go
on
to
the
next
slide.
C
H
I
think
it's
at
a
state
now,
where
that
would
be
useful
cool,
we'll
have
to
see
if
we
can
do
that.
Okay,
all
right.
So
this
is
a
summary
of
the
in
the
contents
of
the
draft
and
I
think,
an
interest
of
time
how
much
detail
to
go
through
here
top
piece.
The
draft
graph
does
discuss
prevalence
of
the
issue
and
severity
of
the
outcomes
that
that
was
a
comment
that
was
made
recently
on
the
mailing
list
that
more
material
there
could
be
helpful.
So
I
don't
disagree
with
that.
H
H
Aside
from
this
issue
with
shared
3168
cues
and
the
two
scenarios
where,
where
that
that
comes
into
play,
then
that's
and
then
it's
primarily
an
issue
for
long
running
flows
to
high
data
rates
with
long
rtts
and
the
result
of
it
is
lforce
flows
out
competing
classic
flows
to
one
degree
or
another,
depending
on
the
scenario
and
then
has
a
summary
of
some
historical
issues
around
peripheral
awareness.
H
The
next
bullet
there's
a
section
that
that
is
dedicated
to
talking
about
detection
of
3168
bottlenecks
via
experiments,
and
then
that
section
is
essentially
a
intended
to
be
useful,
not
just
for
researchers,
doing
experiments,
but
also
for
l4s
host
deployers
to
do
experiments
prior
to
turning
on
l4s
or
as
part
of
their
a
b
testing,
as
they
enable
a
new
congestion
control.
H
Right
now.
That
section
is
essentially
a
pointer
to
the
fallback
report.
The
link
on
the
lower
right
hand
side,
but
the
intention
is
that
we
will
summarize
some
of
the
most
important
methods
that
are
in
that
that
report
in
the
draft
itself.
H
But
now
it's
just
just
a
pointer
one
thing
to
note,
and
there
was
some
discussion
on
the
list
about
this
idea
of
having
l4s
nodes,
disable
3168
ecn,
so
disable
ce
marking
of
ect
0
traffic
in
order
to
facilitate
detection
of
l4s
versus
classic
3168
and
bob
did
a
fairly
in-depth
analysis
of
that
and
then
thinking
through
it
and
put
together
some
slides,
which
come
to
the
conclusion
that
that
may
not
be
as
useful
as
we
maybe
thought
it
might
have
been
a
few
months
back.
H
So
so
currently,
the
draft
does
not
recommend
or
assume
that
l4s
nodes
are
are
doing
that
disabling
of
3160
adcn
and
then
the
last
two
bullets
guidance
for
operators
of
of
hosts
and
guidance
for
operators
of
networks
that
have
bottlenecks
or
the
specific.
H
Guidance
and
and
recommendations
for
those
two
constituents,
and
particularly
on
the
host
side-
we've
broken
it
out
into
general
purpose,
servers
eg
web
server,
servers
versus
more
specialized
servers,
for
example,
cloud
gaming
cloud,
vr
type,
applications,
your
non-tcp
applications
and
then
also
a
partition
between
edge
servers
which
serve
a
small
population
of
networks
or
hosts
versus
more
general
hosts
that
may
be
serving
content
across
longer
paths
or
a
broader
set
of
hosts
all
right
next
slide.
H
There
were
some
comments
on
the
mailing
list
since
the
posting
of
draft
02.,
as
this
summarizes
those,
and
how
are
we
doing
on
time?
Do
we
have
time
to
discuss
these,
or
should
I
just
mention
them.
C
H
Good
yeah,
so
this
is
just
a
summary
of
those
issues.
We'll
work
on
well,
we'll
be
the
mailing
list
as
well.
As
you
know,
people
have
contributions
with
text
that
will
improve
the
draft.
Certainly
those
would
be
useful
all
right.
Okay,
last
slide.
C
Then
is
some
site.
H
C
Adoption
call
in
progress-
and
I
think
it's
productive-
to
leave
this
slide
up
and
open
for
discussion
and
comments.
F
Okay,
now,
I
could
say
a
lot
here,
but
I
will
restrict
myself
to
talking
about
the
long
flows
thing
from
the
previous
slide
and
I'll
just
say
that
I
disagree
with
that
statement
and
we
should
open
a
discussion
about
it
on
the
list
in
the
interests
of
meeting
time.
C
A
I
have
done
it
so
we're
asking
here
how
many
people
think
this
id
this
internet
draft
forms
a
basis
for
a
work
item
in
tsvwg,
I.e
they
support
adoption
and
progression
in
the
working
group.
This
is
a
basis
for
preparing
a
milestone
for
work
on
this.
Please
raise
your
hand
if
you
support
it.
Please
do
press
the
do
not
raise
hand
if
you
think
this
is
not
a
basis
for
work.
C
And
don't
and
don't
press
either
option
if
you
prefer
not
to
express
expression,
opinion
either
way
or
if
you
haven't,
read
it
yet
so.
A
Okay,
so
the
numbers
are
settling
down.
Please
go
to
the
graph
icon
and
press
it
if
you
wish
to
raise
your
hand
to
help
us
judge
that
this
is
ready
for
support,
and
please
note
that
this
is
an
informative
poll.
We
do
this
usually
in
the
working
group
to
see
how
many
people
have
read
the
document.
A
Okay,
we
have
a
stable
entry.
We
have
I'm
going
to
close
it
and
report
the
numbers,
so
25
people
think
this
id
forms
a
basis
for
work
in
tsvwg
to
support
adoption
and
progression
in
the
working
group.
Thank
you
greg
for
presenting
that.
Please
make
sure
you
record
any
comments
you
might
have
on
this
in
the
working
group
email.
So
we
know
if
there
are
any
more
concerns
or
comments
on
the
adoption
process
itself.
I
will
make
a
determination
at
the
end
of
the
period.
C
David
very
good,
and
as
as
noted
in
the
minutes,
we
have
one
one.
One
do
not
raise
hand.
I
think
that
that
I
think
that
that
that
qualifies
as
sense
of
the
room
or
since
the
virtual
room
is
to
adopt
is
to
adopt
the
draft.
A
C
C
C
Nope
hit
wrong
button
happens
off,
okay,
all
right,
so
next
up,
I
need
to
go
find
which
deck
am
I
looking
for
to
start
with
bob.
G
That
should
be
mine.
It's
the
right
requirement.
G
G
D
G
Okay
thanks,
so
this
presentation
is
about
the
prague
requirements
survey
that
we
did
on
the
list.
You
might
have
seen
it
hopefully,
so
it's
an
overview,
a
quick
going
through
it
in
matters
of
time,
so
maybe
next
slide.
G
That
we
we
got
so
the
goal
of
this
survey
was
to
to
get
a
view
on
how
feasible
realizable
the
the
prague
requirements
are
at
the
moment
and
whether
they
were
supported
by
broad
community,
mainly,
of
course,
people
who
would
implement
congestion
controls.
G
So
we
provided
a
template
which
listed
all
the
normative
requirements
and
the
three
performance
requirements
which
were
also
part
of
the
initial
tcp
prague
requirements
set,
but
are
not
really
requirements
but
anyway,
sometimes
considered
as
important
performance
requirements,
and
we
asked
two
questions
whether
you
agree
with
this,
whether
you
want
to
meet
this
requirement
or
not
and
to
what
level
and
and
then
also
another
column,
to
to
get
more
explanation,
any
issues,
experiences
or
even
objections.
You
have
to
the
requirements,
maybe
next
slide.
G
So
we
got
multiple
responses
of
which
three
were
publicly
shared.
So
that
was
our
own
template,
because
we
also
gave,
as
an
example,
a
fielding
template
of
the
tcp
prague
plus,
then
the
scream
congestion
control
by
ingimar
ericsson,
and
then
we
also
received
geforce
now
congestion
control
by
nvidia.
G
So
they
are
listed,
the
the
detailed
responses
they
were
collected
on
the
link.
You
can
have
a
look
at
them
for
for
detailed
responses.
We
also
got
other
responses
shared
privately,
and
at
this
stage
we
didn't
get
any
confirmation
whether
we
could
make
them
public,
so
we
kept
it.
G
We
respected
that,
but
we
made
a
consolidated
summary,
which
is
also
available
on
the
the
same
well
on
the
same
page,
but
directly
in
the
document
that
you
can
find
there
on
the
link
next
slide,
so
to
give
a
a
a
quickly
a
big
overview.
So
these
are
requirements
which
everybody
was
agreeing
with.
Let's
say
they
would
be
compliant
and
support
it
or
plan
to
support
that
it
are
obviously
the
obvious
ones
which
you
need
to
make
it
work.
G
You
could
say
maybe
zooming
in
so
alpha
sender
must
set
ecte
field
to
ect1
ecn
field
to
ect1.
G
There
was
a
concern
or-
or
a
remark
mentioned,
that
operating
system
apis
and
kernels
did
not
support
it
yet,
so
it
would
be
interesting
to
know
what
stops
these
operating
systems
and
kernels
to
put
these
functionalities
into
their
mainstream.
Is
it
really
the
the
the
release
of
rfcs
of
these
documents
or
or
something
else?
G
So
if,
if
there
is
some
insight
in
in
that,
that
would
be
useful
because
it
is,
it
would
be
useful
to
have
these
apis
today
already
and
that
the
kind
of
rollout
could
begin
to
to
be
less
hurdled
by
experiments.
G
And
then
another
thing,
maybe
I
zoom
in
provide
feedback
to
the
extent
of
ce
marking.
Everybody
wants
that
of
obviously,
but
for
the
accurate
ecn
for
the
tcp
protocol
for
other
protocols.
There
were
not
really.
G
G
Also,
the
most
reduced
rtt
bias
was
broadly
accepted
and
also
not
part
of
the
requirements
also
for
the
long-run
trip
times.
They
would
implement
or
already
implement
this
and
also
another
one.
The
rack
requirement.
Let's
say
you
should
should
take
loss
by
in
in
time
based
units
all
of
them
did
already
or
are
planning
to
to
do
this.
The
also
the
non-normative
performance
suggestions
were
all
accepted
and
seen
feasible
and
and
the
results
on
the
draft
were
only
minor
clarifications.
Let's
say
that
were
asked
next
slide.
G
The
the
only
strong
objection
that
we
got
on
the
draft
was
related
to
the
documentation
only
requirements-
I
call
them
here
so
must
specify
in
in
detail
how
the
congestion
control
works
or
how
you
define
quantify
and
justify
burst
limit
approach.
So
the
objections,
where
are
these
documentation
requirements
really
needed?
How
can
we
be
enforced
may
not
be
possible
for
proprietary
protocols
that
don't
want
to
share
this
so,
and
it
would
also
create
kind
of
precedence.
I
think
in
itf
drafts
to
to
have.
G
C
You
yeah:
could
you
put
in
some
language
encouraging
people
to
publish
this
information
for
you
for
for
use
for
the
knowledge
of
the
community?
I
have
no
problem
with
removing
the
must
requirements.
I
think
encouraging
people
to
publish
what
they've
done
is
always
a
good
thing.
G
Yeah,
I
well,
I
don't
know
whether
it's
still
in
there,
but
it's
indeed
we
can
do
that.
I
guess,
then
there
are
a
set
of
requirements
which
needed
experimental
data.
Two
too
high
level
ones.
At
least
the
first
one
is
to
scale
down
to
fractional
congestion
window.
So
not
all
everybody
is
convinced
that
it
really
will
be
a
problem
on
the
internet
and
they
are
not
planning
to
implement
it,
even
multiple
other
ones,
already
supported,
or
have
research
code
available
or
plan
to
implement
it.
G
So
I
think
the
shoot
here
is
in
the
right
place
and
it
is
also
not
really
a
safety
issue
per
se,
because
it's
already
handled
by
the
by
the
aqm
when,
when
the
the
signal
starts
to
saturate,
it
should
use
drop
anyway.
So
it
would
only
be
a
kind
of
performance
improvement
to
prevent
latency
if
there
is
only
alpha
s
or
or
drop
on
on
coupled
equipments.
G
C
I
have
no
idea
where
the
shoot
is
appropriate.
Please
make
sure
the
draft
reflects
the
develop
further
during
further
during
experiment
that
this
is
one
of
the
things
the
experiment
is
investigating.
G
Requirement
that
needed
experimental
data
we
all
know,
is
the
the
classic
ecn
detection.
So
there
are
a
set
of
normative
mustang
shoots
defined.
Currently,
in
the
draft
there
there
was
some,
let's
say,
confusion
about
what
it
exactly
means
meant
is
the
detection
itself
required?
Is
it?
Is
it
well?
The
obviously,
the
robust
detection
scheme
needs
real
deployment,
experience
and
and
others
say,
but
the
combination
with
delay
based
control
would
minimize
potential
issues,
so
it
could
also
be
a
reason
not
to
to
have.
I
G
Detection
per
se
there,
because
it's
already
kind
of
circumvened
by
the
latency
aspect
of
it,
which
is
currently
not
in
tcp
product,
but
several
implementations
have
this
so
so
so,
first
of
all
yeah,
it
should
be
clear
whether
it's
only
the
monitoring
which
is
required
or
also
the
detection
is
required,
and
I
think
the
detection
needs
to
be
developed.
Well,
it's
it's
part
of
the
discussion
and
it's
also
what
greg
already
mentioned
in
the
operational
guidelines
draft.
G
Also
clarifications
on
this
automatically
fall
back,
so
the
next
requirement
says
must
be
replaceable.
While
it
could
also
be
that
the
alpha
s
part
is
disabled,
so
it
becomes
in
the
same
congestion
control,
so
it
becomes
a
normal
classic
response,
only
congestion
control.
So
there
are
multiple
implementations
possible
and
also
whether
it
it
is
required
on
active
flows
or
only
on
new
flows,
especially
if
it
it
is
being
replaced.
G
I
think,
because
of
that
hard
statement,
it
could
be
so
so
anyway,
also
some
clarifications
and
and
disambiguation
is
required
there,
and
I
think
the
requirements
need
to
be
aligned
when
the
operational
guidelines
draft
is
adopted.
C
F
F
We
have
seen
one
of
the
algorithms
from
that
paper
implemented
so
far
and
last
year
and
the
results
from
that
were
not
encouraging.
F
Shall
we
say
there
is
a
second
algorithm
with
a
more
active
profile
which
seems
to
have
a
better
theoretical
basis,
but
I
would
question
how
practical
it
is
due
to
the
volume
of
probe
that
are
needed
to
establish
a
statistical
relationship.
F
So,
of
course,
we
will
need
to
discuss
this
in
more
detail.
G
B
I
just
I
just
wanted
to
come
in.
I
will
also
respond
to
jonathan
what
originally
came
to
the
cue
just
to
say
that
we
haven't
changed
any
of
the
text
in
the
draft
based
on
all
this
feedback
from
the
survey
until
the
adoption
call
is
finished,
because
it
you
know
that
that
makes
a
difference
as
to
what
the
text
is
likely
to
be.
You
know
so,
but
to
to
respond
to
johnson's
point.
B
Yes,
that
you've
picked
up
the
new
idea,
we've
put
into
that
paper
on
using
the
spacing
between
marks,
to
distinguish
between
classic
and
and
alpha
s
and
actually
had
another
idea
since
then,
which
isn't
in
there
to
use
a
pulse
or
a
chirp
to
find
whether
the
aqm
is
smoothing
its
response
or
whether
it's
an
immediate
response,
which
I
think
is
even
possibly
even
even
more
specific
way
of
of
finding
the
two.
B
C
G
And
potentially
also
the
the
deployment
experience
because
well,
the
effectivity
of
all
these
schemes
can
only
be
evaluated
during
the
experiment
itself.
I
think
then
there
was
another
compliant
or
at
least
to
the
intent
of
how
I
think
most
people
will
interpret
the
requirement,
but
it
could
also
be
interpreted
very
strict,
specifically
coexist
safely
with
tcp
renault
congestion
control.
A
lot
of
concerns
are,
what
does
it
mean?
G
Then
the
last
topic,
maybe
in
general
over
all
the
requirements,
is
the
balance
between
openness
to
innovation
and
to
allow
multiple
congestion
controls
and
guidance
and
recommendations.
We
saw
quite
some
requests
for
how
should
it
work?
How
should
this
be
done
so
so
the
the
goal
of
the
draft
at
the
moment,
I
think,
is
to
keep
it
open
for
for
multiple
congestion
controls
even
that
certain
people
might
or
interpret
certain
requirements.
Very
strict,
but
that's
definitely
not
our
goal,
so
if
you
see
like
specific
mechanisms
being
defined,
that
could
be
done.
G
G
C
On
the
red
text,
I'd
suggest
a
two-prong
approach.
One
is,
I
see
a
list
discussion
on
picking
the
precise
words,
and
the
other
thing
I
would
would
suggest
is
pick
one
or
two
well-known
examples
that
do
co-exist
safe
in
tcp
reno,
but
don't
have
reno's
long,
rtt
behavior
and
include
those
and
that
that
should
get
the
point
across.
G
G
Okay,
thanks
as
a
conclusion.
Well,
it's
I
think
it
was
a
very
useful
exercise
to
get
a
better
view
on
on
the
different
positions.
The
strong
objections
were
removed.
G
Okay,
there
is
still
the
suggestion
we
have
to
add,
but
it
also
made
clear
that
live
data
is
is
needed
for
for
those
two,
then,
at
least
and
and
for
the
rest,
that
there
are
quite
already
some
implementations
and
and
all
the
requirements
are
seen
feasible
and
our
plans
to
be
implemented
by
most
of
the
congestion
controls,
so
other
inputs
are
still
welcome,
preferably
public,
but
if
private
we
can
also
take
those
for
the
next
iteration
if
needed.
A
So
my
comment
was
was
rather
quick.
It
was
that
there
are
other
congestion
controllers
out
there
apart
from
reno,
and
this
isn't
the
place
where
we
should
in
tsvwgb,
describing
the
complexities
of
sharing
with
different
congestion
controllers.
So
we
need
to
use
language
which
is
wide
enough.
I
think.
C
Yeah
yeah,
and
for
that
matter,
if
the
examples
exist,
the
examples
will
both
example.
Out
of
the
examples
would
have
two
two
benefits
one
is.
They
would
clearly
show
people
that
you
don't
have
to
have
reno's
long,
rtt,
behavior
requirement
and
the
other
is
they
provide
additional
examples.
Congestion
controls
with
which
alpha
traffic
ought
to
coexist.
I
The
question
in
similar
lines
like
I
wanted
to
ask
if
it's
during
the
experiment,
if
we
have
seen
whether
l4s
conduction
controller
is
fair
or
does
it
coexist
with
cubic
with
cubic?
You
know
like
just
doing
the
classic
ecn.
G
Actually,
reno
tcp
prague
falls
back
to
to
reno
behavior
on
drop,
so
it
is
definitely
even
even
with
reno,
let's
say
almost
compatible
but
well.
These
are
these
are
things
that
most
of
the
implementers
for
real
deployments
want
to
improve.
Obviously,
and
well
it's
it's
at
that
level
that
we
probably
need
the
correct
warning.
J
I
I
think
for
both
loss
is
definitely,
I
think
one
thing
I
think
it's
same.
I
guess
that's
what
coin
was
saying
that
it's
same
for
loss.
G
Maybe,
as
a
clarify
clarification,
I
didn't
say
that
the
tsp
prac
requirements
expect
that
it
has
the
same
response
as
reno
we
want
to
in
the
tcp
prague
requirements
or
in
the
prague
requirements
better.
We
want
to
leave
that
open,
not
describe
the
mechanism.
Necessarily,
I
think
is,
is
the
question
here
when
I
say
tcp,
prague,
implementation
in
linux.
This
is
now
the
current
implementation,
but
it's
not
like
every
congestion
control
should
do
this,
so
we
we
have
to
be
also
tcp.
G
Prague
is
not
the
congestion
control
for
l4s
or
or
rock
requirements.
Maybe
we
should
never
have
called
it
tcp
prague,
because
it's
the
confusion
is
like
these
requirements
mean
that
the
performance
is
not
optimal
in
long
round
trip
times
or
whatever
claims.
I
think
there
are
other
implementations.
G
G
So
it's
it's
up
to
other
people
who
have
the
right.
How
do
you
call
that
the
right
need
for
it
to
to
develop
it?
I
think,
and-
and
it
shouldn't
be
like
relying
on
us
to
to
do
that
job
for
them.
I
think.
C
B
B
This
summarizes
it
all,
really
that
we're
focusing
on
the
congestion
control
implementation,
particularly
faster,
getting
up
to
speed,
which
the
abbreviation
is
guts
and
so
faster
guts
and
the
the
other
activities
that
just
been
talked
about
are
going
on
in
parallel.
Obviously,
next
so
there's
a
new
draft
documenting
the
the
prior
congestion
control
published
yesterday,
some
summaries
there
about
it
being
protocol
and
os
agnostic-
and
you
know
this
point
about
it,
not
being
the
one
true
prague
that
just
said
next.
B
Of
who's
helped
on
all
the
drafts
and
what's
changed
and
and
where
we
are
and
that's
it.
C
And
ingamar
go
for
it
yeah.
Can
you
hear
me
or.
K
This
is
our
ultimate
about.
The
master.
Thesis
is
just
also
done
by
brunello
roughly
one
year
ago.
Actually,
and
it
was
a
published
and
you
have
the
link
there.
If
you
want
to
read
all
the
stuff
and
it's
about
get
on
or
online
and
cloud
gaming
in
5g,
more
or
less,
and
it's
based
on
l4s
and
an
implementation.
You
find
your
own
for
the
alpha.
K
We
can
skip
this
glossary
and
read
it
after
after
presentation,
if
you
like,
but
the
outline
is
that
we
use
a
simulation,
a
system
simulator,
a
proprietary
one
that
models
a
typical
3dpp
deployment
or
a
3dpp
standard
deployment
with
21
cells
base
stations,
and
you
have
a
rather
narrow
bandwidth
and
use
a
screen.
Congestion
control
as
a
baseline
for
for
a
typical
congested
control,
algorithm
that
can
run
with
or
without,
and
you
have
a
variable
load.
K
That's
a
sort
of
increasing
intensity
of
users
and
also
a
number
of
background
traffic
loads
that
hammers
the
links
to
get
more
credible
scenario,
and
we
run
with
various
scheduling
algorithms,
which
means
that
they're
settling
you're,
sadly
one
user.
At
a
time
in
a
in
a
in
a
five-year
system,
well,
first,
we
have
a
round-robin
settling
that
is
typically
used
for
a
normal
mobile-back
mobile
broadband
traffic,
and
then
you
have
something
called
called
quality
of
source.
K
They
give
enhanced
priority
for
the
gaming
users
and
you
can
skip
the
next
slide
and
we
use
here
a
cube
based,
look
it's
okay!
It
is
a
how
we
can
realize
it
in
the
3dpp
network
is
that
we
use
a
quality
of
service
framework
where
you
sort
of
put
set
up
as
an
extra
barrier
actually
for
the
alphas
flows.
K
That
means
that
you
can
keep
the
latency
low
or
that
flow,
and
it,
of
course
it
assumes
that
it's
on
the
l4s
traffic,
then
you
can
help
first
mark
that
and
for
that
we
can
use
the
traffic
filters
that
are
available
and
remap.
The
flows
that
have
this
l4s
other
thor
also
is
capable
to
that
flow,
and
you
can
call
possibly
combine
it
with
the
ip5
tuple.
If
you
like,
also
and
next
slide.
K
Okay,
then
we
have.
What
we're
using
is
this
cube
based
l4s
marker,
which
means
that
you,
actually
you
measure
the
queue
buildup
up
and
rsv
layer,
but
you
mark
on
the
pdp
layer
and
the
reason
why
you
do
that
is
that
the
ip
packets
on
the
rlc
layer
there
are
hidden
by
encryption.
So
you
need
to
actually
feed
up
the
marking
to
the
pcp
layer.
K
Rather,
ip
header
is
visible,
and
essentially
that
is
a
call
you
can
call
it
tail
marking
or
feedback
and
forward
or
whatever
or
you
call
it
in
the
ihf
nomenclature,
and
you
have
something
typical
thresholds
and
you
go
to
a
probability
marking
and
the
threshold,
the
in
the
stimuli
in
the
simulation
studies
that
you
have
with
a
higher
and
lower
threshold
that
are
five
and
ten
milliseconds.
K
That
can
depend
on
the
what
kind
of
numerology
that
you
are
using
on.
Is
it
a
time
division
duplex
or
is
it
frequency
division
duplex?
So
we
can.
You
probably
need
to
tune
those
depending
what
kind
of
raw
nectar
that
you're
running
you
can
skip
two
slides.
K
I
can
believe
you
can
jump
and
this
sort
of
shows
a
time
trace
comparison
when
you
are
using
not
for
us
in
a
congested
network
in
a
contestant
situation
where
you,
though,
the
bit
rate
needs
to
go
down
to
like
30
megabits
per
second
or
even
lower,
to
avoid
you
build
up.
K
First,
you
have
a
note
10
for
s
and
use
a
round
robin
scheduler,
and
you
see
it.
You
have
a
the
network.
K2
delay,
spikes
up
to
like
almost
150
milliseconds,
and
that
can
and
that
can
sort
of
seriously
harm
the
performance
for
for
online
gaming
or
cloud
gaming.
K
And
then
you
have
a
you
enable
l4s.
You
keep
the
same
scheduler
that
is
use
a
normal
mobile
broadband.
You
can
see
that
you
reduce
the
bitrate
a
bit,
but
on
the
other
hand
you
get
a
much
slower
q
delay
and
then
you
have.
If
you
have
used
q
quality
of
service,
you
can
actually
increase
the
bit
rate
a
bit
because
you
push
back
normal
mobile
broadband
users
and
you
still
keep
the
same
low
delay.
K
Here.
We
look
at
the
video
frame
delay
and
here
I
must
say
that
this
video
friendly
also
accommodates
that
you
have
some
capturing
and
and
coding
delay
also
in
the
soup.
That's
why
the
minimum
is
40
milliseconds
here.
What
is
important
here
is
to
see
that
without
fresh
marking,
you
manage
to
keep
the
video
frame
delay
low
up
to
a
relatively
high
high
load
in
the
system.
K
Guess
compared
to
those
when
you
know
not
using
l4s,
and
you
can
probably
skip
the
next
one
here
and
also
one
important.
Okay,
perhaps
won
back
yeah,
okay,
you're
really
really
in
a
hurry
here,
but
okay.
Now
what
the
important
is
that
what
the
alphas
manage
is
to
keep
the
the
network
q
delay
low,
and
that
is
shown
here
that
you
managed
to
keep
the
network
q
build
up
very
low,
and
that
is
the
main
purpose.
K
K
That's
the
shoulder
transmitted
rate-
and
here
it
does-
is
something
that
is
up
to
discussion
here
is
maybe
online
or
offline
on.
Is
that
you
actually
trade
off
a
bit
of
a
throughput
in
order
to
get
a
lower
delay,
and
part
of
the
reason
is
that
the
video
encoders
typically
have
a
very
varying
frame
sizes
which
have
shown
up
in
our
upper
right
grapher
and
another
one
is
that
you
have
in
the
cellular
access.
You
have
fast
fading.
K
A
A
K
B
C
B
A
C
A
A
Excellent
okay:
if
you're
going
to
prepare
presentations
for
the
next
meetings,
please
do
stick
by
the
deadlines
and
send
them
in
advance.
Last
minute,
presentations
are
really
challenging
in
agenda
planning,
but
apart
from
that,
we
just
wish
you
the
best
and
keep
talking
on
the
list.