►
From YouTube: IETF109-TSVWG-20201118-0730
Description
TSVWG meeting session at IETF109
2020/11/18 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
C
A
A
C
A
E
So
I
might
get
it
wrong
as
well
right,
so
there
there
are
separate
strings
for
the
meet
echo
session,
because
it's
like
two
sessions
is
two
sessions,
but
the
agenda
page
actually
links
back
to
the
same
for
the
two
sessions
things.
That's
actually
probably
something
we
should
talk
to
me
to
echo
about
for
the
second
time,
but
let's
use
the
link
that
I
posted
so
they're
all
in
the
same
place,
just
to
keep
keep
you
all
from
having
to
merge
things.
Okay,
I
will.
C
G
H
H
I
I
J
J
D
B
Started
yeah,
so
I
think
we
I've
already
spent
time
wrestling
with
tools
here,
so
I
think
we
probably
should
just
jump
into
the
agenda.
So
I
think
today
we
have
greg
on
the
operational
guidance,
then
bob
on
the
other
l4s
drafts
and
if
there's
any
time
left,
there's
some
l4s
and
5g
work
that
ingomar
will
discuss.
So
if
there's
nothing
else
or
any
agenda
bashing
people
want
to
do.
I
think
we'll
go
straight
to.
B
H
H
H
H
H
In
all
these
cases,
l4s
traffic
and
classic
traffic
coexist
well,
except
for
the
one
in
red.
Where
there's
a
problem,
that's
been
identified
where
classic
flows
will
receive
less
throughput
than
l4s
flows
when
they
are
coexisting
in
a
bottleneck.
That
is
a
single
queue
and
classification
and
just
the
focus
of
the
draft.
There
is
an
asterisk
on
the
fq
classic
ecn
case,
getting
back
to
jake
and
pete's
comment
that
there
are
scenarios
in
an
fq
classic
ecm
bottleneck
where
we
don't
see
fairness
being
enforced
by
fq.
H
One
of
those
is
a
case
where
you've
got
mixed
traffic
in
tunnels
that
are
going
through.
The
fq
fq
is
known
to
not
provide
fairness
for
the
flows
that
are
inside
tunnels,
and
in
this
case,
if
you
have
a
tunnel
that
has
a
mix
of
classic
and
l4s
traffic,
there's
a
further
unfairness
between
the
flows
that
are
within
the
tunnel.
H
K
Can
I
do
you
hear
me?
Yes,
please
go
ahead,
okay,
so
this
looks
fine
and
very
systematic,
except
that
the
first
draw
in
this
table
is
pretty
much
under
discussion.
So
it
says,
duracu
coupled
akm
provides
reasonable
fairness
across
a
range
of
conditions,
which
is
true.
I
admit
that
the
problem
is
whether
the
range
of
tested
conditions
actually
is
sufficiently
broad
to
allow
extrapolation
onto
the
wider
internet,
and
I
do
not
believe
that
this
is
currently
true.
That's
just
the
point
I
wanted
to
make.
H
Maybe
that's
the
the
reason
why
it's
less
impacted
to
hide
bdb,
okay,
but
in
the
cases
where
the
impact
is
at
its
worst,
it's
been
shown
to
to
result
in
more
than
ten
to
one
flow
rate
ratio
and
there's
an
example
of
some
of
the
data.
That's
been
shown
on
that
there's
a
number
of
experiments
have
been
done
over
the
past
year
or
more
on
that,
but
you
can
see
figure
one
in
the
in
that
link
for
an
example.
B
H
The
operator
from
l4s
host
breaks
down
the
host
into
two
categories,
so
one
that
would
be
deployed
in
a
constrained
whether
there's
a
constrained
set
of
networks
or
clients
that
it's
serving
where
there
are
opportunities
for
coordination
and
and
pre-launch
testing
across
that
constrained
set
of
networks
of
clients,
and
so
the
graph
talks
about
what
some
of
those
options
are.
And
you
know
as
as
I
mentioned,
this
is
a
work
in
progress
draft.
H
The
second
kind
of
sub
bullet
under
section
3.1,
is
in-band
detection
monitoring,
so
the
l4s
id
draft
has
some
mandatory
features
that
hosts
need
to
support
to
facilitate
this,
to
attempt
to
detect
rfc
3168
in
in
the
bottleneck,
and
then
the
server
could
fall
back
in
real
time.
So
when
it
detects
the
potential
presence
of
rc3168,
it
immediately
discontinues
the
l4s
congestion
response
and
utilizes
the
classic
congestion
response.
H
Still,
the
in-band
methods
apply
in
either
a
real-time
or
non-real-time
response
for
those
real
time
might
be
a
little
bit
more
feasible.
There
also
could
be
some
per
destination
path.
Testing
that
could
take
place
in
addition
to
the
in-band
detection,
monitoring
and
draft
has
a
placeholder
for
specific
tests
there
again.
Feedback
or
input
would
be
helpful
to
flesh
out
that,
as
well
as
the
other
components
of
this
section.
D
B
H
H
That's
a
good
question,
so
it
probably
depends
a
bit
on
the
network.
So
one
scenario
that
has
been
highlighted
on
the
mailing
list
is
a
residential
isp,
where
the
individual
customer,
so
a
single
ip
address,
may
have
an
implementation
of
a
single
qr,
6138
bottleneck
in
their
network,
and
so
results
of
this
testing
could
be
different
on
an
ip
address
by
ip
address
basis.
H
It
provides
currently
a
a
list
of
potential
options
for
configuring
that
bottleneck
to
or
those
bottlenecks
to
work
better
with
l4s
traffic,
and
I
won't
go
through
all
these
in
detail
on
the
call,
but
the
first
one
there's
a
question
on
the
mailing
list.
Whether
routers
are
able
to
to
actually
support
that.
I
think.
H
A
M
D
O
O
A
H
I
think
it's
also
been
suggested
that
you
know
the
working
group
could
consider
formally
deprecating
treating
ect1
identically
to
ect
0.
I
think,
as
a
good
point
out,
it's
not
required
to
be
treated
the
same,
but
it
could
be
formally
deprecated
and
that
might
nudge
things
along
towards
implementing
borderline.
C
H
Obviously,
detecting
3168
through
measurement
campaigns
would
be
an
interesting
step.
There's
been
some
attempt
at
that
in
the
past,
but
more
useful,
also,
out-of-band
measurement
of
l4s
versus
classic
performance
might
be
something
that
be
done
as
well
and
then
not
in
the
graph.
Yet,
but
something
is
pointed
out
off
list
to
me
research.
H
H
Next
slide,
so
there's
some
additional
meaningless
comments.
Recently,
last
few
days,
sebastian
had
a
comment
to
reword
the
phrase:
more
precise
flow
balance
in
reference
to
dual
cue
jonathan
morton
pointed
out
that
if
the
working
group
had
gone
a
different
path,
then
we
wouldn't
have
to
write
this
draft
and
then
jake
had
a
couple
of
other
comments
around
adding
some
references.
That
help
illustrate
the
unfairness
issue
and
then
raise
the
question.
H
H
There
have
been
several
who
have
contributed
texts,
but
I
would
hope
that
with
adoption,
we'll
bring
the
commitment
from
the
working
group
to
to
flesh
this
out
and
provide
a
full
list
of
what
we're
aware
of,
in
terms
of
guidance
for
for
making
l4s
work
well
with
the
presence
of
3168
bottlenecks.
So.
B
H
H
H
N
H
H
P
P
H
Q
Hi,
I
love
stuart.
I
love
the
zero
percent
to
many
decimal
places
by
the
way,
I'd
love
to
know
yeah.
The
the
thing
I
wanted
to
say
about
this
draft
is
that
I
think
it's
the
general.
It
makes
a
lot
of
sense
to
have
an
operational
guidance
draft
in
the
working
group.
For
for
for
this,
I
think
the
the
questions
that
are
being
raised
and
addressed
in
this
draft
are
very
useful,
and
I
I
think
this
ought
to
be
adopted.
Q
I've
taken
a
look
at
the
draft
I'll
admit
to
not
having
read
it
carefully.
It
seems
very
thin,
but
I
suspect
that
can
be
resolved
as
we
get
into
the
as
it
gets
into
the
working
room.
I
would
definitely
encourage
adoption
of
this.
The
one
thing
I
would
I
would
also
suggest
is
maybe,
to
articulate
a
little
bit
more
of
articulate
the
the
the
the
the
goal
as
not
to
promote
fairness,
but
to
avoid
unfairness.
I
think
there
is
a
difference
between
the
two,
but
again
that
isn't
it.
H
C
Yeah,
so
I
I
did
a
presentation
at
map
rg
the
interim
map
rg.
I
think
it
was
just
after
last
ietf
and
it
was
interim
with
with
that
at
the
conference
right
yeah
and
they
so
we
did
not
see
zero
percent.
There
were
several
networks
in
which
we
saw
non-zero
percentage
deployment
of
ecn
when
we
looked
according
to
asn,
so
I
I
would
be
very
interested
stuart
if
you
get
a
chance
to.
C
C
When
you
look
in
the
aggregate
it
was,
it
was
only
zero
percent
down
to
down
to
two
decimal
places
for
us
overall
and
I
think
we're
we
are
getting
probably
a
different
data
set
than
the
then
you
know
what
iphone
would
see
in
general,
but
we
we
did
have
some.
You
know.
Zero
percent
to
many
decimal
places
was
not
our
observation,
so
it
might
be
good
to
sort
of
see
if
we
can
link
those
up
a
little
better
and
maybe
even
get
an
ongoing.
P
P
The
one
suggestion
I
would
have
is
when
we
first
collected
data,
we
were
seeing
some
plausible
amount
of
ecn
marking
in
argentina,
notably
and
in
france,
and
it
led
us
to
a
false
sense
of
optimism
at
the
start
and
when
we
dug
into
a
little
bit
deeper,
it
turned
out
to
be
bogus.
It
wasn't
actual
working
smart
queuing
with
ecm.
P
C
Thank
you.
We.
We
did
note
that
when
we
started
our
project-
and
we
were
looking
for
it
also
and
and
did
fail
to
replicate
that
I
think
I
reported
that
in
the
in
the
presentation
I
did
and
but
nonetheless
there
were
other
networks
where
they're
there
and
by
country
it
was
hard
to
find
anything
with
that
remotely
approached
some
of
the
numbers
you
reported
in
the
initial
stuff,
and
I
understand
that
was
found
to
be
bugs.
C
C
H
D
A
B
O
O
O
I
guess
I
could
just
start
by
saying
that
the
next
door,
what
the
next
talk
is
going
to
be
before
we
get
the
title
side.
It's
a
status,
update
on
l4s
and
the
the
three
main
alfres
drafts
other
than
the
one
greg
has
just
been
talking
about.
That's
the
architecture
draft,
the
alphas
id
and
the
dual
queue
couple
day:
qm
right,
that's
fairly
small
on
my
screen.
A
Yeah
there
were
15
people
said
that
they'd
read
one
of
the
operational
drafts,
one
of
the
two
revisions
and
there
were
19
people
who
said
that
they
hadn't,
presumably
intended
to
so
a
reasonable
number
of
people
have
read
this
and
that's
useful
input
to
our
processor's
chairs.
Thanks
ever
so
much
that
polls
closed
back
to
you,
bob.
O
So
you
can
keep
your
get
your
aqm
right
tight
and
you
and
you
also
get
them
scalable
throughput,
which
is
the
s
part
of
the
l4s
which
otherwise,
that
has
has
been
known
since
early
work
in
the
1990s
which
sally
floyd
published
as
an
rfc
3649.
I
think
you
you
get
longer
and
longer
time
between
each
sawtooth,
as
as
you
try
and
get
faster
and
you
get
less
tight
control
next.
O
I'll
try
and
speed
up
the
just
just
a
bit
of
news
on
various
implementation
things
been
going
on.
Since
the
last
time
we
gave
a
status
update,
which
was
april,
I
believe,
maybe
july.
I
can't
remember
the
low
latency
docsis
working
group
has
been
continuing
doing
interop
testing,
currently
three
independent
implementations,
two
cable
modems
one
cmts
and
two
implementations
now
completely
pass
all
the
functional
tests.
There
was
a
I
know
before
I
left
cleveland.
O
There
was
a
large
set
of
conformance
tests
and
functional
tests
that
that
were
defined
against
the
spec
next
one.
This
work
hasn't
started
yet,
but
the
only
new
news
is
that
it
it's
got
a
date
for
when
it's
planned
to
start
and
that's
the
data
plane
development
kit,
that's
the
open
source,
libraries
for
virtualization
for
a
variety
of
cpu
architectures
and
that's
planned
for
dual
queue:
coupled
aqm
implementation
in
q1
next
year,
and
then
there's
a
lot
of
publications
coming
out
of
ns3.
O
O
O
It's
been
added
and
about
to
be
released
in
fq,
pi
and
fq
cobalt
in
their
models
in
ns3,
and
it's
already
in
the
linux
fq
cuddle,
and
that
adds
as
as
well
that
they
add
to
the
the
itf
dual
cue
coupled
acre,
meaning
the
one.
That's
in
the
itf
draft,
the
sort
of
reference
pseudocode,
the
the
code
for
that
is
also
modeled
in
ns3
and
has
been
for
some
time
right.
O
O
O
We
have
a
congestion
control
that
gives
really
low
latency
over
a
range
of
conditions,
as
in
that
paper
you
know
reasonable
rtts
and
link
rates,
but
you
know
pieces
of
it
are
still
missing.
You
know,
that's
absolutely
obvious,
so
it's
easy
to
think
up
conditions
where
it
doesn't
work
well
and
show
that
and
we
admit
progress
has
been
slow
covering
up
all
those
holes
and
and
fixing
it
all.
O
We
we're
primarily
for
network
companies
and
and
being
network
operators
or
vendors
for
for
networks,
and
you
know
we've
got
a
bit
of
a
background
in
congestion
control
over
the
years,
but
we're
not
the
guys
that
will
produce
this.
So
you
know
we're
having
to
do
it
in
spare
time
because
it's
not
funded
by
our
companies
and
so
on.
O
We
imagined
a
different
way
of
building
congestion
control
if
you
like,
whereas
mostly
what
a
congestion
control
has
been
given
as
a
blob
to
the
community
by
researchers-
and
we
were
thinking
it'd-
be
great-
to
have
something
where
different
components
were
were
brought
in
by
different
different
groups
as
more
of
open
source
project.
And
that
didn't
happen,
and
that's
probably
our
fault,
nearly
certainly
our
fault
as
the
core
team.
O
Just
you
know
we
didn't
do
it
right,
didn't
make
it
open
enough
at
the
start,
but
now
with
something
worse
has
happened,
we've
sort
of
got
a
toxic
code
point
war.
That's
you
know
it's
it's
good
to
have
a
red
team.
You
know
to
be
picking
holes
in
in
everything,
but
it's
it's
now
getting
to
the
point
where
it's,
I,
I
think,
being
a
bit
more
destructive
in
that
it's.
You
know
there
are
problems
that
aren't
really
anything
to
do
with
l4s
congestion
controls
in
particular
that
you
could.
O
J
Bob
so
yeah
there's
there
was
some
confusion
about
the
the
deadline
for
this
meeting,
and
and
that's
not
your
fault.
However,
I
and
many
other
people
are
not
going
to
be
able
to
stretch
this
until
55
past.
Is
there
any
way
you
can
bring
forward
like
the
key
takeaways
and
then
for
people
who
are
interested
they'd
be
welcome
to
stick
around
for
okay.
O
O
O
So
all
three
drafts
that
you
know
the
rest
of
the
rest
of
the
talk
is
about
is
about
the
alfres
drafts,
because
we've
been
putting
a
lot
of
work
into
them
to
get
them,
get
them
finished
and
ready
for
working
group.
Last
call
in
our
humble
opinion
that
stands
for
or
it's
an
anagram
of
ohio
and
there.
The
only
bit
left
really
is,
is
what
the
status
of
this
alpha
s.
O
O
So
there's
some
shits
and
musts
on
what
on
what
has
to
be
in
those
things
about
pacing
and
stuff
and
finally,
the
dual
queue
coupled
aqm,
that's
very
stable.
Wasn't
I
couldn't
find
anything
to
change
in
that
just
some
modern
editorial
stuff.
So
that's
the
top
level
for
martin.
If
you
want
to
go
now.
A
B
Q
Q
Are
there
any
major
issues
pending,
but
the
extent
that
I've
seen
my
understanding
is
that
the
biggest
issue,
the
biggest
issue
I've
see
I've
seen
and-
and
forgive
me
if
I've
not
seen
all
the
issues-
is
the
competition
with
classic
eqn
at
fifo
queues,
and
is
that
the
biggest
issue-
that's
spending,
because
I'd
like
to
speak
to
that?
If
that
is
the
biggest
issue,
that's
pending.
O
Q
So
so
so
maybe
I'll
just
take
a
minute
to
speak
to
to
to
both
of
those
points,
because
I
think
my
my
point
will
ought
to
cover
them
both
at
a
high
level.
I
feel
I
I'm
I
I
feel
like
this
is
ready
for
an
experiment.
I
absolutely
think
that
we
should
outline
precisely
what
the
outcomes
of
the
experiment
ought
to
be,
meaning
that
what
are
we
measuring?
What
are
we
looking
to
see
but
era?
It
absolutely
seems
like
we
are
ready
to
launch
this
experiment.
Q
Q
D
D
A
Yeah,
I
can
care
with
that,
and
I
think
that's
that
is,
I
mean
just
so
to
clarify
for
anybody
who's
watching
this
or
listening
remotely
and
the
working
group
last
call
doesn't
confirm
the
document.
The
working
group
last
call
gives
people
a
last
call
for
comments
on
it,
where
we
have
to
in
detail
check
that
things
are
right
and
the
document
could
be
frozen
after
that
or
the
document
could
be
published
or
the
document
could
be.
Could
we
have
certain
pieces
of
work
identified
that
need
to
be
done
so
or
indeed
it
could
be
dropped?
A
C
A
Q
Q
It's
it's
it's
a
brand
new
one
and
I
think
that
putting
that
on
the
critical
path
rushes,
the
draft,
I
think
it's
worth
spending
some
time
getting
that
ironed
out
just
in
terms
of
getting
the
text
right
and
everything
else,
but
I
still
don't
understand
why
that
needs
to
be
on
the
critical
path
for
getting
these
two
experimental
status.
If
people
know
how
to
deploy
this
stuff,
then
they
can
do.
Q
C
So
I'm
in
the
queue
after
jonah,
but
I
see
colin
and
john-
are
still
ahead
of
me.
Or
should
I
just
speak?
I
guess
yes,
I
will
so
the
you
know.
The
tests
that
jonathan
and
pete
have
published
lately
do
show
some
some
bad
problems.
I
guess
the
you
know.
The
claim
is
that
this
is.
As
I
understand,
it
is
essentially
sufficient
to
to
call
the
l4s
experiment
likely
to
fail.
C
So
I'm
not
sure
if
the
intent
is
to
sort
of
just
fix
that
after
seeing
the
experiments
and
I'm
not
sure
why
that
wouldn't
happen
in
lab
before
moving
it
forward,
but
I
guess
the
sentiment
here
seems
to
be:
let's
get
this
rolled
out
so
that
people
can
try
it
or
something
I
think,
there's
already
an
implementation.
People
can
try.
So
I'm
a
little
confused.
What
the
what
the
hold
up
is
on
running
an
experiment
just
in
terms
of
gathering
data,
I'm
not
sure
how
that
relates.
C
C
You
know,
that's
that's
just
my
sort
of
take
on
on
the
experiments
I've
seen
so
far,
but
yeah
in
terms
of
I
guess
the
the
goal
here
is
to
get
wider
operational
experiment
and
that's
waiting
on
a
draft,
I'm
a
little
just
confused
on
a
on
an
rfc
rather
than
than
on
a
draft,
and
I'm
a
little
confused
on
how
that
even
relates
exactly
so.
I
don't
know
who
wants
to
speak
to
that,
but.
L
So
I'm
not
sure
who's
running
with
q,
but
I
guess
I
may
be
next-
I
I
don't
think
we
need
to
wait
for
the
abstract
here,
I'm
confused
as
to
why
we're
not
just
proceeding
with
this
already
the
the
problems
we've
seen
identified
seem
very
minor
and
unlikely
to
be
a
practical
issue,
so
I
don't.
I
don't
quite
understand
why
we're
not
proceeding
with
the
the
experiment.
So
yes,
I
I
would
encourage
us
to
to
move
forward
with
this.
R
Yes,
so
I
think
the
experiment
is
so.
I
think
problems
that
have
been
detected
about
dual
queue
actually
make
certain
assumptions
about
deployments,
so
part
of
the
experiment
is
actually
to
figure
out
if
these
deployments
are
do
exist
in
our
problem,
because
we
assume
that
it's
not
the
case,
so
you
know
that's
something
we
can
figure
out
from
a
larger
scale,
experimentation
and
the
and
to
also
like
hit
on
last
point.
R
I
S
The
main
problem
is,
of
course,
classic
ecn
fallback
and
the
longer
we
wait,
the
more
classic
ecn
will
be
an
alternative
because
nobody
starts
to
believe
in
whether
alphas
will
actually
really
happen.
That's
that's
the
main
danger
and
I
I
don't
think
a
lot
of
people
are
convinced
that
the
problems
in
in
the
current
implementation
cannot
be
solved.
It's
a
huge
opportunity
to
to
to
experiment
and
to
again
gain
better
experience.
S
In
the
beginning.
We
thought
okay
data
center
tcp
would
would
be
the
reference
and
we
didn't
need
to
work
on
on
the
congestion
control.
But
in
the
meantime,
this
this
prague
has
become
a
kind
of
reference,
implementation,
status
and,
and
now
even
asked
to
be
to
prove
everything
that
that
it
can
gain.
I,
I
think
it's
a
wrong
expectation,
especially
from
the
people
working
on
that.
S
If,
if
people
are
really
concerned
that
there
is
no
improvement
possible,
then
then
okay,
we
we
should
stop
here
or
wait
until
this
is
really
the
case,
but
I
don't
have
the
the
impression
that
people
are
are
thinking
in
that
way.
People
are
waiting
for
deployment
and
really
to
to
to
get
things
running
and
see
this
also
what's
important.
Is
we
get
a
lot
of
traction
in
implementations
if
you're
going
to
wait?
S
Q
To
to
last
this
question
of
what
is
the
experiment,
I
think
I
think
he
is
right
in
that
we
should
articulate
precisely
what
the
experiment
here
is,
and
I
think
answer
some
of
the
questions.
I'll
emphasize
just
two
points
in
there.
One
of
them
is
that
our
history,
history
has
shown
that
just
getting
this
deployed
itself
can
be
a
simple
experiment.
What
I
mean
by
that
is,
even
though
it
does.
Yes,
you
write
large
that
you
know.
Q
Q
I
would
also
ask
a
a
slightly
different
question,
which
is:
do
we
think
that
by
keeping
it
in
committee
so
to
speak
or
keeping
it
as
a
draft
in
the
working
group,
we
gain
anything
if
we
don't
gain
anything
by
making
it
an
experiment
out
there?
My
question
would
be:
what
do
we
gain
by
keeping
it
in
the
working
group.
B
K
Thanks,
so
the
concern
I
have
at
the
moment
is
that
the
operational
safety
of
all
of
the
lfrs
design
and
implementation
over
the
wider
internet
has
not
been
proven
sufficiently
at
the
current
time.
Speaking
about
deploying
what
we
have
seems
rather
premature
without
data
showing
that
it
really
is
safe
over
the
long
haul
and
not
just
over
the
short
rtt
low,
hop
count,
links
between
end
user
and
cdns
seems
rather
uncautious.
K
I
think
l4s
simply
isn't
there
that
we
should
talk
about
the
lost
last
call.
Now
the
data
is
missing.
I'm
it's
sad
that,
after
seven
years
the
data
is
still
on
there,
but
that's
how
it
is,
I'm
pretty
sure
that
this
data
can
be
produced
relatively
quickly
and
presented,
and
if
it's
safe,
no
matter
whether
I
like
it
or
not,
then
make
it
an
experiment,
but
if
it's
not
safe,
let's
just
drop
them.
But
let's
make
this
based
on
data
and
not
just
how
we
feel
about
this.
K
S
S
S
So
we
should
also
see
what
is
the
relevance
of
the
problems
that
we
see
today
in
in
practice.
They
I
I
think
they
are
zero.
It's
just
a
matter.
If
there
is
interest
for
people
with
a
very
long
round
trip
time
to
have
a
buffer
of
one
millisecond
instead
of
15
milliseconds,
it
will
be
worked
on.
Otherwise
the
the
congestion
controls
will
automatically
fall
back,
but
all
these
things
that's
experience
that
we
need
people
working
on
it
and
and
the
right
people
with
the
right
incentives
working
on
that
and
improving
it.
S
If,
if
you're,
if
everybody
looks
at
us
and
and
and
expects
that
we
are
going
to
make
this,
this
ultimate
super
perfect
congestion
control,
then
then
that
is
the
wrong
way
of
progressing.
We
will
probably
starve
at
the
end
from
from
exhausting,
I
mean,
let's
engage,
let's
other
people
get
the
opportunity
to
work
on.
I
see
only
one
main
problem,
which
is
not
that
big,
it's
the
the
classic
ecn
detection
so
and
the
longer
we
wait,
the
more
classic
ecn
will
be
the
alternative.
S
So
I
don't
see
any
gain
in
waiting.
Let's
go
forward.
The
question
is:
is
the
network
part
okay,
then
we
should
go
ahead
if
the
congestion
control
is
okay,
I
think
now
it's
not
perfect,
but
it
can
be
improved.
So
what's
why
stopping,
I
would
say:
go
ahead,
make
sure
we
can
as
fast
as
possible,
go
to
work
group
lost,
call
and,
and
the
rest
will
follow.
H
I
I
didn't
want
to
sound.
Oh,
my
audio
is
really
garbled.
I
didn't
want
to
sound
like
I
was
going
to
require,
like
the
perfect
congestion
controller
for
for
this
experiment
right,
but,
but
you
know,
asking
for
a
fabric
upgrade
is
a
pretty
tall
ask
and
not
being
able
to
motivate
it
to
application
developers
that
you
also
talked
about
kind
of
that
you
know.
No
application
can
use
this
without
there
being
a
congestion
controller
that
delivers
some
sort
of
benefits
to
that
application
right.
I
So
you
can
throw
this
in
the
network,
but
if
you
can't
be
exploited
by
the
app
it's,
it's
not
going
to
be
a
very
great
deployment
story
right,
so
we
can
argue
whether
what
we
currently
have
as
a
congestion
controller
is
good
enough.
But
I
think
this
is
an
integral
part
of
of
this
experiment.
If
you
think
back
right,
we've
done
a
few
classes
of
this
before
so
either.
We've
done
queueing
improvements
that
intended
to
improve
existing
tcp
traffic
without
tcp
changes
right.
We
know
how
to
do
that.
I
We've
also
done
tcp
changes
to
try
to
you
know,
work
better
with
whatever
cues
they
found
in
the
network,
and
we
know
how
to
do
that
and
then
we've
done
ecn
right.
We
changed
both
changed
the
network
and
changed
gcp
and
it
was
a
pretty
integrated
design
right.
It
was
pretty
minimal,
but
it
was.
It
was
integrated
and,
in
my
mind,
this
this
needs
to
be
a
similarly
integrated
activity.
I
S
Okay,
so
so
I
I
agree,
it's
it's.
It's
very
important
to
have
both
and
looking
at
the
past.
In
the
past,
we
had
the
congestion
control
for
acn,
which
was
very
simple.
Just
do
the
same
as
before,
instead
of
drop
and
afterwards,
we
didn't
see
any
or
hardly
any
deployment
in
the
network
now
is
the
opposite.
S
We
have
a
network
with
a
lot
of
interest,
with
a
lot
of
plans
to
deploy
with
standards
already
defined
people
working
on
products,
and
now
we're
saying:
let's:
let's
wait
until
the
end
host,
which
are
usually
the
easiest
one
to
change
things
are,
are
at
par.
I
I
think
we
are
blocking
this
at
the
moment.
We
we
have
good
engagement
in
networks
and
and
plans
to
deploy.
S
S
So
so,
but
anyway,
the
short
thing
is:
we
have
something
which
is
good,
which
can
be
used
at
the
moment
already
within
a
specific
range,
with
some
corner
cases.
Not.
But
if,
if
that's
the
pro
or
the
the
the
question,
we
have
that
already
we
can
do
the
the
experiment.
Applications
can
use
it
already
within
certain
constraints
defined
in
the
operational
guidelines.