►
From YouTube: IETF115-TCPM-20221109-1300
Description
TCPM meeting session at IETF115
2022/11/09 1300
https://datatracker.ietf.org/meeting/115/proceedings/
A
B
C
B
C
C
D
C
C
D
B
B
If
folks
could
sit
down
and
also
make
sure
to
register
your
attendance
either
scan
the
QR
code
here
or
at
the
door
or
log
in
all
those
things
seem
to
work
well,.
C
B
C
C
And
Yoshi
is
remote,
okay,
so
next
slide.
C
The
session
has
been
being
recorded.
This
is
an
important
information.
Richard
was
so
nice
to
do
then
do
act
as
a
note.
Taker
Yoshi
is
doing
a
JavaScript
and,
if
you're
submitting
in
the
future,
a
document
where
you
think
tcpm
should
be
interested
in,
please
put
tcpm
in
the
name
of
the
document,
so
it
shows
up
in
our
view,
in
the
data
tracker
next
slide.
C
So
this
is
the
agenda.
We
will
provide
a
an
overview
about
the
working
group
status.
We
have
one
presentation
for
working
with
documents.
Basically,
it's
an
current
status
and
overview
about
the
document
being
considered
for
going
into
working
group
last
score
next
and
then
we
have
a
couple
of
other
items.
One
is
future
status
of
Roc
3465,
which
is
ABC.
We
have
TCP
ACC
rate
request,
which
we
have
seen
the
present
a
couple
of
presentations
already
a
new
one,
TCP
service
Affinity
option.
C
Yoshi
is
talking
about
a
new
document
describing
the
differences
between
standard
congestion
controls
and,
if
time
permits,
I
wanted
to
talk
about
whether
120
seconds
is
still
the
correct
value
for
MSL
and
TCP
timeout
agenda
bashing.
Anyone
wants
to
change
anything
here.
D
Martin
Duke,
just
I
I've,
been
using
this
slot
in
working
groups
to
to
show
for
the
congestion
control
working
group
side
meeting
at
5
pm
on
Thursday.
That's
tomorrow
we
will
be
bashing
the
proposed
Charter
the
tsvr.
Actually
this
list
has
an
announcement
with
like
links
and
so
on.
If
people
are
interested
thanks,
yeah.
C
So
these
are
the
documents
we
have
finished
since
last
ITF.
The
TCP
base
back.
It's
now
RC
9293,
thanks
to
Wes
for
for
doing
this
work,
we
have
the
Yang
document
and
the
RC
editor
queue.
It's
there.
It's
it's
done,
but
it's
in
a
misref
state.
C
We
have
high
start
plus
plus
after
the
working
group
last
call
the
ad
had
some
issues,
editorial
questions
and
one
question
regarding
how
to
handle
the
L.
Well,
you
mentioned
there
and
there
was
a
new
revision
submitted
yesterday.
I
think,
which
basically
says
use
l
equals
eight.
If
you're
not
placing
use,
l
equals
infinity.
If
you
are
pacing
with
mandatory
language
and
the
process
is
that
this
is
discussed
between
the
ad
and
the
authors
and
once
it's
finished,
it
comes
back
to
the
working
group
for
a
short
working
group.
D
C
The
next
one
is
cubic
and
Yoshi
is
the
document
Shepard,
so
yeah.
She
will
give
you
an
update
on
that
document.
F
F
So
this
is
right
now
a
working
group:
let's
go
and
we
got
some
comments
and
then
I
see
some
YouTube
is
responding.
So
so,
if
you
have
any
more
feedback
present
to
the
mailing
list
as
soon
as
possible,.
C
The
next
three
documents
which
are
in
our
list
of
Milestones
is
accurate
ecn,
which
is
the
document
we
want
to
last
call.
C
Next
after
that
generalized
ecn,
we
I
think
we
decided
that
I'll
be
the
document
Shepherd
on
accurate
ecn,
and
I
I
n
is
the
generalized
CCN
document
Shepard,
and
then
we
have
TCP
Edo
I,
recently
updated
the
Milestones
of
the
discussion
with
Martin
and
moved
dark
Milestones
being
in
the
past
to
realistic
thing,
I
moved
it
to
the
December
2023,
but
we
recently
got
an
email
from
Joe
that
he
thinks
TCP.
C
Edo
is
ready
for
working
group
last
call,
and
he
also
has
a
another
document
about
extending
this-
the
the
sin
segment,
which
is
right
now,
not
a
milestone
so
for
the
second
one
the
chairs
are
still
discussing
whether
how
to
handle
this
is
the
working
group
had
if
any
feedback
on
TCP
Edo
being
last
called
soon.
G
So
not
having
read
this
in
a
very
long
time,
I
mean
we
have
this
Grand
Edition
in
tcpm
of
publishing
things
on
the
charts
on
the
standard
strike
that
they
have
no
implementation,
but
I
probably
had
sort
of
managed
to
get
away
from
this
a
little
bit
so
I'm,
not
thrilled
right,
but
you
can
make
the
cases
we've
done
it
before
many
times.
B
C
H
So
so
Edo
is
what
standard
status
at
the
moment.
B
H
Yeah,
it's
a
stupid,
must
thing
I
get
the
protocol
wrong,
so
I
said
I
presumed.
Quite
a
lot
of
people
said
they
wanted
to
use
this
in
some
way
and
if
they
did
then
maybe
PS
is
okay
because
there's
a
intent
to
implement.
But
if
there's
no
intent
to
implement
and
there's
no
implementations,
then
perhaps
it's
just
EXP.
I
D
Killing
me
so
I'm
in
the
queue
please
as
an
individual
yeah
like
I,
don't
see
a
reason
not
to
do
it
exp,
but
maybe
I
asked
the
broader
question:
why
are
we
continue
to
progress
this
draft?
If
no
one
has
any
intention
of
implementing
much
just
much
less
deploying
it.
C
G
Can
you
remind
me
if
the
code
plan
can
be
assigned
if
it's
experimental
it
wants?
It
wants
an
option
number
right.
G
F
Yeah
one
exception
is
mptcp.
B
Here
we
go
all
right
with
that.
Shall
we
move
to
the
first
presenter.
F
Sorry,
yes,
well
somehow
you
are
not
showing
in
the
middle
sorry.
B
B
J
Right
this
is
more
accurate,
DC
and
feedback
in
TCP,
and
that
still
looks
like
an
old
slide.
J
B
J
Yeah,
it
should
say
22,
not
21,
that's
the
only
difference
in
20
20
to
21
was
a
sort
of
null
change
in
21
to
22
was
the
actual
change
and
it's
still
minor
anyway.
Are
we
there.
J
All
right
so
yeah,
the
substantive
change
is
actually
21
to
22
and
it's
not
very
substantive
in
fact
Richard.
While
we
were
doing
interrupt
testing
noticed
that
there
was
no
nothing
in
the
spec
about
what
happens
if
multiple
sins
arrive,
or
at
least
what
it
says,
what
happens
if
they
arrive,
but
it
didn't
say
which
one
you
do.
The
feedback
for
it
did,
on
the
other
hand,
handle
a
case
of
multiple
synacs,
and
so
we
just
added
some
text
saying
you
should
feedback
the
latest
one.
J
If
anyone
wants
to
think
about
whether
maybe
you
should
feed
back
the
most
serious
feedback,
you
could
do
that,
but
we
figured
it's
better
to
feedback
latest
feedback
rather
than
stale
feedback.
Yeah.
Okay
and
we
recorded
the
guy
on
early
registrations.
That's
it
you
can.
You
can
move
on
so
the
chairs
asked
if
we
would
do
a
sort
of
retrospective
on
the
whole
of
accurate
ecn
for
this
session.
Given
we're
about
to
go
to
working
group
last
call
I
believe
so.
J
This
is
a
bit
of
a
road
map
on
the
on
the
next
few
slot
about
the
next
few
slides
the
goal
and
the
approach,
the
relation
to
other
activities
where
it
sits
in
the
stack.
What
aspects
you
will
need
to
look
out
for
when
you're
reviewing
it
and
the
implementation
state
is
next.
J
So
the
goal
is
to
feed
back
the
extent
of
congestion,
not
just
his
existence
within
a
round
trip,
so
that
congestion
controls
that
use
that
have
have
the
mechanism
in
the
base
feedback
of
TCP.
J
J
So
the
problem
was
that
RFC
3168
ecn
feedback
that
was
added
to
TCP
back
in
2001,
when
any
number
of
CE
marks
hit
the
receiver.
It
started.
It
latched
up,
Echo
congestion,
experienced
and
started
feeding
that
back
for
a
liability
and
then
only
stopped
when
the
sender
sent
congestion
window
reduced
back
to
the
receiver
again,
which
meant
that
you,
if
you
got
one
or
10
or
300
C
marks,
you
got
the
same
signal
going
backwards,
so
that
was
the
meaning
of
congestion
existence.
J
J
Okay
next,
so
the
solution
to
that
we
adopted
was
to
use
the
two
bits
that
were
already
or
two
flags
that
were
already
in
the
main
TCP
header
for
ecn
to
override
them.
Once
the
three-way
handshake
had
got,
started
and
use
actually
a
third
bit.
That
was
also
used
a
historically
for
the
ucn
nonce
well
used
in
quotes
because
it
wasn't
clear
whether
it
was
used.
J
So
we
we
have
a
loaded
them
and
made
them
into
a
three-bit
counter,
and
that
would
be
essential
and
always
used,
and
then
there
was
an
optional
TCP
option
that
you
could
also
add
for
extra
Precision
with
24-bit
counters
for
the
bytes
and
the
ace
field
counted
just
packets
and
the
Act
and
the
option
we
counts.
Bytes
fed
back
next
Bob.
B
I
may
ask
a
question
as
an
individual,
just
a
clear,
I'm
curious.
What
do
you
think
is
the
likely
deployment
ratio
between
the
option
and
the
core
Ace
functionality
I'm,
just
like
as
an
individual?
Do
you
think
it's
going
to
be
dependent
on
use
case
or
what
are
your
thoughts.
J
I
I
think
that
possibly
more
in
data
centers,
you
might
not
need
the
option.
I
think
you
might
need
the
option
more,
where
you've
got
middle
boxes
and
stuff,
essentially
doing
a
lot
of
that
correlating
and
things
like
that,
so
the
three-bit
field
might
rap
too
fast.
J
Right
so
there's
quite
a
lot
in
the
introduction
about
what
the
relation
is
to
other
activities.
First
of
all,
dctcp
was
the
if
you
like,
post
a
child
of
extent
based
feedback,
and
that
was
where
we
learned
that
it
was
useful.
J
J
That
was
fine
in
a
data
center
that
was
administered
by
one
sysadmin,
and
it
could
that,
since
admin
could
ensure
that
everything
was
configured
correctly
but
on
the
public
internet,
that's
a
bit
more
problematic
because
there
isn't
ones
this
admin
I.
Believe
still.
J
J
J
Right
so,
but
that
can
be
used
internally
in
data
centers
and
privately.
So
the
next
thing
it
relates
to
is
other
congestion
controls.
Now
now
accurate
Asian
is
pure.
The
the
spec
is
purely
about
the
the
feedback
mechanism
and
the
wire
protocol
for
doing
that.
J
It's
still
as
clear
as
saying
anything
about
congestion,
response.
Well,
I
think
it
mentions
the
words,
but
you
know
it
doesn't
doesn't
say:
we've
got
to
do
about
it.
So
really
feedback
is
architecturally
below
the
congestion
control,
and
so
the
congestion
control
depends
on
it.
And
that
means
you
can
use
accurate
ecn
feedback
for
any
congestion
control
algorithm,
and
that
includes
the
the
ones
that
don't
need
the
higher
accuracy.
J
You
know
that
only
want
extent
and
not
existence
like
Reno
and
cubic
so
the
callbacks
in
the
implementation,
but
still
work
just
the
same,
whether
you
use
old
or
new.
So
it
is
a
replacement
for
the
existing
TCP
ecn
feedback,
not
a
just
a
you,
don't
have
to
choose
which
one
you
you
use.
J
The
the
other
thing
this
relates
to
is
the
LPS
experiment,
which
you
you
know
is
a
probably
the
first
example
of
something
that
uses
it.
Hopefully
not
the
last.
It
is
intended
to
be
generic
feedback
and
obviously,
both
ends
have
have
to
be
able
to
use
accurate
ecn
in
order
to
get
that
accurate
feedback,
but
only
one
end
needs
to
actually
be
Alpha
SK
people
as
far
because
l4s
is
a
Ascender
congestion
control
thing,
whereas
the
feedback
is
a
end-to-end
agreement.
J
And
finally,
it
relates
to
another
draft
ecn
plus
plus
that's
what
the
title
calls
it
now.
But
the
draft
name
is
there
and
that
removes
the
rule
in
3168
ucn
about
not
using
ecn
on
CCP
control,
packets
and
re-transmissions.
J
D
J
Accurate
ecn's
package
proposed
standard,
yeah,
okay
and
and
the
other
way
around
the
there
are
also
aspects
in
the
ECM
plus
plus
spec
that
you
can't
use
unless
you're
using
Acura
ACN.
Okay,
thanks.
J
So
where
does
it
fit
in?
This
stack
just
just
to
explain
the
diagram?
That's
not
an
implementation
diagram!
That's
what
works
over!
What
right
and
the
idea
is
you've
got
IP
at
the
bottom
there,
and
ECM,
plus
plus,
is
really
about
whether
you
set
the
ecn
field
in
the
IP
header.
So
it's
it's
really
about
below
TCP,
even
though
it's
in
tcpm
and
then
the
TCP
layer,
I've
split
there
into
two
sub
layers
for
the
feedback
and
then
the
congestion
control
above
it
and
I.
J
Think
I've
I've
mostly
explained
all
this.
On
the
previous
slide,
you
have
to
enable
accurate
ecn
and
it
will
fall
back.
You
have
to
enable
it
on
both
endpoints.
It
will
fall
back
otherwise,
no
dependency
on
anything
in
the
network
and,
as
I
said,
it
replaces
rather
than
and
extends
the
3168
tcpn
feedback,
rather
than
being
an
alternative,
and
also
importantly
out
of
scope
in
the
Acura
ecn.
Spec
is
there's
nothing
about
what
the
sender
puts
in
the
ecn
field.
J
So
these
are
the
sort
of
parts
that
really
need
looking
at
closely,
if
you're
going
to
review
this
for
working
group
last
call-
or
if
you
already
have
hopefully
you've
looked
at
these
things-
negotiation
phase
there's
a
lot
of
stuff
in
there,
particularly
about
detecting
mangling
through
middle
boxes
and
such
like
and
backward
compatibility
with
old
schemes,
forward
compatibility
with
potential
new
schemes,
fullback
contingencies,
and
things
like
that.
J
So
that's
that's,
quite
a
sort
of
sensitive
area
to
have
a
look
at
then
there's
resilience
against
Atlas
and
coalescing,
and
things
like
that.
Please
have
a
look
at
that
and
implications
of
TCP
wire
protocol
changes
on
either
implications
of
middle
boxes
on
there
or
implications
of
that
on
middle
boxes,
because
anything
you
change
on
The
Wire
could
be,
could
affect
that
and
then
there's
a
section
on
interaction
with
TCP
variants.
J
So
if
one
of
those
is
your
favorite
variant,
favorite
variant,
I
think
we've
considered
all
all
the
combinations,
but
please
have
a
look
and
finally
in
security
considerations,
there's
all
stuff
about
flooding,
attacks,
feedback,
Integrity,
downgrade
attacks
and
things
like
that.
So
I'm,
nearly
there.
The
implementation
we've
got
two
slides
on
this.
J
What
we've
been
doing
interrupt
testing
all
this
week
down
in
the
hack
demo,
area
of
l4s
and
Acura
ecn
and
the
Linux
implementation,
the
ilpo
primarily
did
Neil
has
updated
to
be
based
off
the
515
Linux
kernel
and
there's
a
pull
request.
I
think
hasn't
quite
happened
yet,
but
it's
still
a
minute
to
go
into
the
l4s
repo
as
well.
J
Also
the
packet
drill
tests,
Neil
has
updated.
Then
Richard
here
has
been
implementing
it
on
FreeBSD
he's
that
would
be
in
free,
freebsd14,
I,
believe
that's
great
yep,
but
without
the
optional
TCP
option
and
Richard's
done
a
lot
of
the
coding
around
that,
but
still
the
parts
of
the
TCP
option.
J
Well,
there's
there's
some
heuristic
stuff
not
to
do
with
the
TCP
option
left
and
some
details
of
the
TCP
option
as
well
and
so
far
it
passes
all
the
packet
drug
tests.
That
I
mentioned
above
that,
except
except
one
to
do
with
the
TCP
option,
obviously,
because
it's
not
implemented
right,
okay
and
moving
on
second
slide
about
implementation.
Apple
platforms
now
also
implement
the
Acura
ecn,
but
only
the
reflector
side
so
that
we
can
test
it
against
ascender
all
right.
J
So
that
means
that
it
will
not
really
work
as
a
sender,
but
it
will.
It
will
allow
you
to
use
accurate
ECM
between
the
two
it's
off
by
default
in
Mac,
OS,
iOS
and
all
the
other.
J
You
know,
I
iPad,
I,
watch,
I,
think
I,
therefore,
I
am
or
whatever
the
the
way
to
turn
it
on
is
written
there
net
on
it,
TCP
accurate
ecn,
assist
control
and
finally,
as
I
said,
all
that
has
been
being
interrupt
tested
fairly
extensively
over
the
last
week,
which
is
how
Richard
found
the
problem
in
the
spec
the
the
little
thing
about
the
multiple
sins.
J
It's
also
been,
which
is
also
patched
TCP
dump,
but
that
hasn't
got
through
yet.
But
it's
it's
been
submitted
and
the
Wireshark
Michael
has
got
that
patched
through.
So
it's
now
in
4.0,
it
will
show
you
the
correct
accuracy
and
Flags
I
think
that's
getting
close
to
it.
D
J
C
So
we
actually
did
some
tests.
What
was
it
from
my
lab
from
a
FreeBSD
machine
in
my
University's
lab
to
to
the
internet
and
figure
out
that
the
net
module
and
FreeBSD
clears
the
AE
bit?
C
It
will
be
fixed,
but
it
was
one
of
the
results.
The
the
options
went
through
at
least
on
that
path.
J
Yeah
I
mean
for
the
IE
bit.
We
did
many
years
ago,
actually
testing
on
that.
But,
yes,
we
haven't
done
recent
testing.
We
did
a
massive
set
of
tests,
so
that
was
Marcelo
banulo
and.
J
J
Again-
and
we
didn't
actually
find
that
problem
on
your
I
guess
we
were
we,
we
did,
you
know
mobile
networks
and
we
did
it
on
fixed
networks,
but
didn't
see
that
problem
in
our
BSD
net
well,.
C
B
Oh
there's
questions
in
the
queue
Bob.
Let's
go:
okay,
oh
today,
oh
Craig,
sorry
Christian,
I
just
removed
you
accidentally.
Instead
of
letting
you
present.
Could
you
get
back
in
the
cute.
L
E
A
Yes,
okay!
Yes,
do
you
hear
me
now?
Yes,
yes,
good!
Yes,
I
have
a
question
in
the
in
this
easier
negotiation
option.
What
happens
if
there
is
a
past
change.
L
A
J
What
what
is
the
first
out
there
without
watching
the
IP
layer?
Yes,
the
the
Acura
ecn,
negotiation
checks
for
mangling
during
the
handshake,
but
it
doesn't
continue
to
check
for
it.
But
there
are,
there
are
statements
in
the
in
the
spec
about
implementations,
may
I.
Think
I
can't
remember
exactly.
J
You
know,
check
that
things
are
still
continuing,
but
the
idea
being
that
the
idea
for
me
being
that
you
don't
really
want
to
have
everything,
continually
checked
all
the
time
when
you're
in
in
the
in
the
fast
path,
if
you
like
so
and-
and
you
know,
I
don't
want
to
make
people
check
things
for
years
to
come.
J
I
think
that
that
sort
of
depends
on
How
likely.
It
is
to
happen
at
the
moment
from
from
our
testing.
Any
bleaching
tended
to
be
at
the
first
hop,
so
it's
sort
of
less
likely
that
a
path
change
will
will
lose
the
first
or
change
the
first
hop.
J
But
yes,
it
could
happen,
and-
and
all
I
can
say
is
that
Equity
stand
is
a
lot
better
than
ecn,
3168
TCM,
which
did
no
checking
at
all.
So
it's
a
it's
a
compromise
between
how
often
you
check
these
things
and
ultimately,
if
your
ecn
is
mangled,
if
you,
if
you
fill
up
a
a
buffer
somewhere,
you'll
get
a
loss
and
then
you
respond
to
that.
You
know
so.
J
We
well,
we
were.
We
were
testing
from
clients,
so
it
was.
The
first
hop
from
the
client
was
was
tending
to
be
where
any
any
bleaching
of
ECM
was
happening.
So.
G
J
B
Yeah
Richard
I
think
it's
your
turn.
If
you'd
like
to,
could
you
read
your
thoughts.
L
So
I
just
wanted
to
expand
on
the
interrupt
of
testing
across
the
internet.
L
I
just
wanted
to
expand
on
the
intro
testing
across
the
internet,
and
that
was
done
last
time
between
Linux
box
that
danil
provided
in
two
different
hyperscalers,
one
of
which
did
actually
the
bleaching
the
other
one
did
not,
and
we
did
also
do
these
tests
with
the
accuracy
an
option,
basically
reconfirming
what
we
have
found
early
on
like
eight
years
ago,
then
we
did
some
some
real
serious
investigation
about
the
viability
of
the
acquisition
option
and
the
bids
to
Traverse
the
internet.
So
no,
no
big
surprises
there
really.
B
Thank
you,
Richard
great
and
Cory
will
be
the
last
speaker
on
this
because
we
are
just
about
to
run
out
of.
J
Time
can
I
just
say
that
on
on
mangling,
you
know
I'm
sure
there
will
be
a
problem
somewhere
or
however
much
you
test.
You
won't
find
everything
you
know
it's.
H
Yeah
gory
first
to
remember,
is
going
through
the
mangling
test
and
how
often
we
talk
about
this
and
the
rest
of
in
the
draft,
it's
a
bit
complicated.
The
draft,
but
I
guess
answer
to
Christian
is:
please
read
that
draft
and
figure
out
whether
the
text
actually
says
it,
because
we
need
to
make
sure
it's
right
yeah,
but
there
is
text
in
there.
D
Good
afternoon,
I
wanted
to
get
a
sense
from
the
group
about
appropriate
by
counting
in
RFC
3465.
It's
been
inspired
by
some
recent
events.
I've
worked,
like
many
of
you,
have
worked
on
TCP
for
a
long
time.
D
If
you
had
asked
me
a
couple
years
ago,
like
what
is
the
last
word
in
the
RC
series
about
ABC
I
would
say:
oh
well,
it's
RFC
3465
and
isn't
it
annoying?
It
that's
experimental
and
that's
actually
because
you
know
for
document
reasons,
but
that
turns
out
not
to
be
true
and
I.
D
Think
we
should
take
a
look
at
it
next
slide,
please
so
in
the
beginning,
this
is
what
was
in
that
in
that
document
there
was
a
question
avoidance
thing
and
a
slow
start
thing
and
for
a
slow
start
we
had
this
value
L,
which
is
the
maximum
number
of
MSS,
as
you
would
act
in
a
single
act
or
that
you
would
accept
this
act
for
congest
control
purposes
and
that
was
set
to
no
more
than
two
next
slide.
D
Now
that
whole
congestion
avoidant
bit
avoidance
bit.
Actually,
if
you
go
look
at
RFC,
50
5681,
it
takes
that
and
recommends
it.
So
that
5681
is,
of
course,
the
like
the
main
standards
track:
Reno
congestion
control
document,
so
this
is
completely
taken.
Care
of
this
is
now
in
the
standards.
Corpus
5681
also
took
slow
start,
the
slow
start
Behavior,
but
limited
L
to
one,
and
so
so,
if
you
were
doing
L
equals
one,
you
were
completely
standards
track.
D
If
you
were
doing
L
equals
two,
you
were
doing
an
experimental
thing
and,
if
you're
over
two
which,
by
the
way
the
links
kernel
does
by
default,
if
I'm
not
mistaken,
here
we
go
again,
then
then
I
guess
you're
off
the
you
know
completely
out
of
bounds
of
of
ietf
land,
but
you
know
we
know
how
that
goes
next
slide.
D
So
what
is
what
has
changed
recently?
Is
this
High
start
thing,
and
this
is
what
we
alluded
to
briefly
in
the
document
review,
but
in
my
opinion,
in
the
ad
review,
what
the
document
originally
said
was
a
little
bit.
D
It
was
trying
to
massage
the
the
need
to
refer
to
a
experimental
document,
a
down
ref
in
a
way
that
was
a
little
bit
Elusive,
and
so
what
I
pushed
them
to
do
is
actually
just
go
ahead
and
standardize
when
that,
when
you
were
running
slow
start
in
conjunction
with
highstar
plus
plus
that
you
just
you
can
do
ABC
and
there's
no
limit
on
L,
which
is
what
they
actually
you
know
tested
in
the
internet
and
so
right.
So
so
the
current.
D
So
assuming
that
the
working
group
is
fine
with
that,
when
we
do
this,
not
last
call,
but
this
second
pass
through
the
group
consensus
call
through
the
group,
then
this
will
move
on
onto
the
standards
track,
and
so
the
status
will
be.
What
you
see
in
this
table
here
in
the
lower
right
that,
well
again,
the
congestion
avoidance
is
has
always
been
standards
for
a
long
time.
If
you're
doing
High
start
plus,
plus
you
can
sort
of
do
essentially,
whatever
you
want,
they're,
probably
with
any
value
of
L.
D
If
you
are
not
running
High,
start
plus
plus
then,
depending
on
your
value
of
L,
you
were
either
in
proposed
standard
land.
You
were
in
experimental
land
or
you're
once
again
out
in
in
the
wild.
Is
there
another
slide?
Yes,
okay,
so
there
are
a
few
options
here.
One
is
you
could
just
do
nothing,
it's
always
an
option.
Certainly,
you
know
there's
always
a
case
that
that
a
lot
of
these
non-interoperable
issues
that
don't
resolve
don't
relate
to
interoperability
can
be
safely
ignored.
D
But
you
know
I
I
have
the
misperception.
I
was
probably
not
the
only
one
and
I
think
it
is
misleading
to
people
to
point
to
this
document.
D
A
second
like
intermediate
difficulty
option
is
for
me
to
initiate
a
document
action
which
makes
3465
historic
and
just
say,
look
as
a
community,
our
best
practice,
so
there's
there's
a
thing
called
slow
start
and
it
includes
High,
start
plus
plus,
and
so,
if
you're
doing
something
other
than
that
you're,
not
following
the
best
practice
anymore,
and
that
means
that
some
things
are
not
unspecified
but
does
leave
a
nice
tombstone
in
3465.
That
says,
by
the
way,
this
has
been
standardized
in
these
following
other
RCS.
D
So
you
need
not
do
this
experimental
thing
anymore,
which
is
achieving
my
objective
at
least,
and
then
the
last
option
is.
We
think
that
one
corner
where
non-high
start
plus
plus
with
ABC
L
greater
than
one
is
important.
We
could
do
a
new,
tiny
PS
to
to
kind
of
sanctify
that
in
a
standard
I,
whether
that
is
worth
doing
or
not
that's
kind
of
what
I
want
to
ask
the
community.
It
I
know
Ian.
B
Ian
sweat
as
an
individual
I,
have
a
question
which
is
at
some
point.
Presumably
bbr
will
finally
be
standardized
and
bbr's
current
startup
is
not
high
start
plus
plus
it
is
a
notably
different,
algorithm
I've
implemented
both
of
them
yeah.
What
will
we
do
about
that?
Are
we
going
to
just
throw
the
same
text?
B
We
threw
into
high
cert
plus
plus
into
bbr,
start
up
and
just
say
like
it's
duplicated,
but
we
don't
really
care
or
or
do
we
feel
bad
about
that
and
do
we
think
that
well
I'm,
duck
and
start
saying
the
same
thing
over
and
over
again
that
is
duplicative
or
does
bbr
just
reference,
High
start
plus,
plus
and
say
this
isn't
High
start
plus
plus,
but
like
if
you're
doing
bbr,
then
this
also
applies
well.
D
Well,
first
of
all,
I
think
we're
fairly
far
from
bbr
being
standards
track,
but
but
when
that
time
comes
my
understanding
of
bvr
is
it
will
be
like
pretty
new
like
this
whole,
like
congestion
avoidance,
so
slow
start
models
is
really
creaky
and
maybe
breaking,
and
you
really
ought
to
write
down
what
you're
doing
like
when
you
receive
an
ack
which
presumably
have
some
ABC
elements
in
it.
So
you
can
have
as
a
separate
standards
track
document.
D
That
is,
that
is
like
writing
down
what
you're
doing,
and
if
that
makes
the
process
it
makes
you
the
process.
You
don't
need
to
rely
on
these
other
documents
to
to
do
that.
Michael.
C
Like
to
go
next
microphone,
Michael
Jackson
from
the
floor
not
being
able
to
get
into
that
queue,
similar
point
is:
is
I'm
brought
up
with
what
to
do
in
PBR?
C
What,
if,
in
the
future
high
stat
plus
plus,
is
people
are
using
different
things?
So
I
would
prefer
some
future-proof
solution
which
is
not
tied
to
using
a
particular
algorithm.
We
are
having
now
on
the
table
more
or
less
by
accident.
I
mean
it's
the
document
we
have
right
now,
so
we
want
to
shift
something
in,
but
there
is
no
guarantee
that
in
two
years
nothing
else
comes
up
or
so.
D
So,
do
we
so
is
the
group's
consensus
that
high
start
is
not
actually
necessarily
best
practice,
but
kind
of
maybe
an
optional
thing
that
you
can
do
no.
D
Again,
I
think
if
we
specify
a
new
slow
start,
ish
thing
that
that
is
going
to
be
standards
track.
Then
there's
no
there's
no.
Like
document
downref
issue,
it
will
just
specify
what
the
new
behavior
is.
If
you
mess
with
a
slow
start,
you
mess
with
slow
start,
and
you
have
other
things.
D
D
I
I
think
it's
just
an
orthogonal
I,
don't
I,
don't
think
that
the
state
of
New,
new,
slow
start
ish
proposals
in
the
standards
track
is
affected
by
this
one
or
the
other,
because
they
will
simply
specify
what
to
do,
which
may
not
include
include
appropriate
byte
counting
and
if
there's
no
need
to
reference
3465
or
any
or
high
stock,
plus
plus
or
any
of
the
other
documents
they're
just
going
to
State
what
they
do
and
if
they
meet.
If
they
have
consensus,
they
become
a
standard.
D
Now,
if
someone
has
a
credential
control
and
they
want
to
refer
to
5681
slow
start
like
without
really
specifying
it,
then
they're
stuck
with
5681
slow
start,
but
I
mean
it's
just
a
paragraph
to
add
to
the
document
saying
Oh,
but
you
can
also
do
this
other
thing.
G
G
D
Yes,
that
is
a
even
yeah.
That's
that's!
That's
cranking!
This
scale
of
work
up
to
11.,
if
somebody
has
it
into
them,
write
a
56
any
one
best,
zero,
zero
I
would
I
think
everyone
would
welcome
that.
There's
always
some
tweaks
to
be
done,
but
I
I.
Unless
somebody
stands
up
I,
don't
know
that
that's
like
I
mean
I
could
write
out
any
of
these
without
you
know
in
a
day
and
start
the
process
5681.
This
is
a
much
bigger
project.
B
H
Yeah
gory
Fair
hist
at
the
mic
and
Christian
here
Christian
go
ahead.
A
Yes,
I'm
sorry
I
mean
yeah.
A
I
was
I'm
too
old,
I
forgot
to
unmute
I'm
sorry
I
mean
at
some
point
in
a
few
years
my
brain
will
turn
into
mush
and-
and
you
won't
have
that
problem,
because
the
situation
will
be
clear
but
in
between
I
am
with
loss
and
Michael.
On
this
discussion,
it's
a
I
think
it's
a
mistake
for
the
IDF
to
specify
implementations
in
that
case
rather
than
specify
rules
and
desires,
I
mean,
for
example.
Clearly
the
rule
for
slow
start
is
that
you
shall
not
create
big.
A
Overflow
and
and
end
up
with
a
lot
of
losses,
because
that's
bad
okay
and
it's
clear
that
high
start
does
that
it's
not
the
only
way
to
do
that.
I
mean
I
unpointed
the
different
solution,
bbo.
There
is
also
a
lot
of
research
on
shopping,
which
will
make
a
a
quick
assessment
of
the
the
bandwidth
and
it's
particularly
useful
for
long
delay,
links
and
so
I
think
it
would
be
much
better
to
have
principles
rather
than
reference
to
specific
Solutions
if
we
are
to
make
some
kind
of
best
practice
as
a
referencing,
hey.
D
A
Guess
by
myself,
yeah.
D
So
large
proposed
option
four,
so
maybe
option
3.5
is
just
to
rev
flow
start
specifically
and
along
the
lines
of
maybe
something
that
that
that
Christian
outlined
and
that's
certainly
fine,
I
I-
don't
have
the
bandwidth
to
do
that
personally,
whereas
these
are
the
things
I
do
at
the
bandwidth
to
do
so.
I
think
that's
a
concern
as
well.
H
Hey
Gary,
first
I,
don't
normally
do
this
I
don't
like
option
two
and
I
might
prefer
option
one
of
your
list
at
this
moment
and
we
were
just
in
a
side
meeting
talking
about
satellite
systems,
but
I
suspect
other
systems
also
are
playing
around
with
high
star
plus
plus,
and
you
know
the
algorithm
is
an
algorithm.
It
interacts.
Maybe
we
will
come
up
with
something
slightly
different
in
the
short
term.
Maybe
it'll
be
wise,
I,
don't
know
what
the
actual
recommendation
is
so
I
just
wonder
whether
we're
just
kind
of
a
little
bit
ahead.
H
M
Hello
I
would
like
to
propose
it.
I
mean
it
might
be
a
simple
way
out
of
this,
which,
which
is
in
fact
option
three,
but
using
a
shot
I
mean
the
point.
Is
that
what
are
whether
we
have
high
start
or
not?
You
know
whatever
mechanism
we
have.
M
It's
probably
never
going
to
be
a
fantastic
idea
to
have
a
huge
burst
or
a
set
of
huge
bursts
right,
and
we
could
include
the
number
two
in
the
short
instead
of
the
number
one
that
probably
won't
make
the
world
melt,
but
it
is
a
principle
thing
to
avoid
having
bursts
and
if
you
have
good
reasons
against
that,
and
it
could
be
text
explaining
right
that
algorithms,
in
the
style
of
high
start
could
be
a
reason
against
that
decision.
So
you
wouldn't
you
know,
but
make
it
a
shot.
So.
D
What
is
what
is
in
highstar,
plus
plus,
is
may
choose
any
value,
for
l
should
choose
Infinity
if
you
have
pacing
and
without
pacing,
and
if
you
pick
a
pick
whatever
number,
if
you
are
smart
enough
to
do
it,
if
you
don't
know
just
pick
eight,
that's!
What's
that's!
What's
in
that
document
right
now,.
C
D
Yes,
it
is,
should
choose
eight
unless
you
understand
what
you
were
doing
like
people
have
disagreed
about
this,
but
I
think
it
is
important
to
give
the
naive
implementer
some
number
to
grab
as
a
magic
number
rather
than
just
say.
No
just
go
find
a
PhD
to
tell
you
what
your
L
should
be.
D
Other
people
could
disagree
about
that.
We
could
have
that
comment
on
the
list
that
discussion
on
the
list,
but
and
we'll
have
an
opportunity
in
review
for
the
high
start
document.
B
D
So
that
was
not.
That
was
not
the
incredible
encouragement.
I
had
hoped
to
find
so
I
I,
so
I,
I,
I
I,
think
I
mean
we
should
probably
conclude
with
an
action
item
and
I
guess
the
option
is
to
do
nothing
at
this
time,
but
but
to
like
be
more
annoying
about
asking
for
somebody
to
drop
to
draft
this
new
standards
track
document.
Do
people
want.
B
D
D
D
Like
so
so,
the
consensus
from
before
was
let's
do
a
PS
document.
So
so
maybe
like
that's
the
question,
should
we
do
a
PS
document
and
then,
if
we
want
to
have
a
show
of
hands
on
who's
willing
to
help
co-author,
that
that
would
be
amazing.
But
we
can
see
how
that
goes.
D
B
D
B
I'm
not
seeing
any
new
votes,
so
I'm,
gonna,
I'm,
gonna
end
the
session.
There
we
go
and
we
have
nine
people.
Nine
people
raise
their
hand.
Three
people
did
not
raise
their
hand
with
a
total
of
12
people,
it's
quite
a
few
fewer
than
it
is
in
this
room.
Let
her
learn
this
session
I'm,
not
sure
if
that's
an
indication
of
lack
of
Interest
or
what,
but
that's
the
information
we
have.
D
G
B
N
D
Oh
well,
it
could
be
yeah
I'm,
assuming
that
working
group
stands
up.
Oh,
that
would
be
a
great
place
for
it,
although
probably
like
the
people
who
would
write
it
are
in
this
room
anyway,
I
would
guess,
but
all
right
so
I
guess
a
sort
of
I
mean
you
guys
can
judge
the
consensus.
It's
not
my
role
for
in
this
case,
but
I
I
think
we're
gonna
have
to
punt
this
to
without
a
proper.
D
Yeah
so
I
guess
I
will
not
move
forward
with
doing
anything
myself
and-
and
we
will
have
to
discuss
this
more.
Thank
you.
E
E
Know,
okay,
so,
first
of
all,
the
review
of
the
motivation
for
the
draft
delay
Dax
is
a
widely
used
mechanism
which
is
intended
to
reduce
protocol
overhead.
However,
in
some
cases
it
may
also
contribute
to
sub-optimal
Performance.
E
For
example,
when
there
may
be
performance
limitations
due
to
highly
asymmetric
path
capacity
or
when
we
may
want
to
further
reduce
the
computational
cost
and
network
load
of
too
many
acts.
There
is
also
so-called
small
congestive
window
scenarios,
where
the
congesting
window
size
would
be
up
to
the
order
of
around
one
MSS,
such
as
in
data
centers,
where
the
bandwidth
delay
product
may
be
up
to
the
order
of
one
MSS.
In
that
case,
delete
X
will
incur
utterly
much
greater
than
the
RTD,
and
also
in
transactional
data
exchanges
or
when
the
congestion
window
decreases.
E
E
So
on
the
status
of
the
draft,
perhaps
you
may
recall
that
there
was
before
the
creation
of
this
document.
There
was
some
prior
discussion
in
the
area
of
Center
control
of
TCP
acts,
which
appeared
to
converge
to
defining
a
new
TCP
option
serving
two
purposes,
providing
a
sender
with
the
ability
of
requesting
and
give
an
upgrade
or
requesting
immediate
acts,
while
keeping
the
steady
state
pack
rate.
So
today,
I'm
presenting
the
updates
in
version
zero,
six,
which
aims
to
address
the
comments
from
the
last
meeting.
Next,
please
so,
let's
go
through
the
updates.
E
The
first
one
is
in
the
main
format
of
the
option,
the
one
that
conveys
the
requested
act
rate
value
so
after
comments.
In
the
last
meeting,
we
are
going
back
from
a
size
of
six
bytes
to
five
bytes,
because
there
were
commands
that
there's
this
lack
of
space
for
TCP
options,
especially
in
syn
packets.
E
So
now,
with
the
current
format,
the
R
Field,
which
is
the
one
that
carries
the
binary
encoding
of
the
upgrade,
would
be
of
seven
bits.
The
maximum
value
that
could
be
encoded
here
is
127
and
we
still
have
one
reserved
bit
which
might
be
useful
for
future
users
for
perhaps
future
encodings
or
values
of
R,
if
needed.
Next,
please.
E
The
other
main
update
in
this
last
version
is
the
addition
of
appendix
a
after
a
comment
by
Bob,
because
he
mentioned
that
perhaps
star
was
converging
somehow
to
something
similar
to
RFC
5690,
which
is
also
known
as
axcc.
So
we
tried
to
clarify
to
provide
some
comparison
here
to
clarify
the
potential
similarities
and
differences
between
the
two
documents.
E
So,
first
about
the
main
goals
and
features
see,
is
an
informational
RFC
to
our
best
knowledge.
It
has
not
been
implemented.
The
goal
in
this
document
is
reducing
act
traffic
when
there
is
congestion
on
the
reverse
path,
so
it
is
to
apply
congestion
control
on
Ax,
and
it
is
somehow
relatively
complex
mechanism
which
has
different
components:
a
component
to
detect
lost
an
ecn
marked
pure
ax,
a
mechanism
for
calculating
the
ACT
ratio,
a
mechanism
to
announce
access
support
that
means
of
a
new
TCP
option
and
a
method
to
indicate
new
ratio.
E
E
Next,
please
so,
regarding
how
the
new
TCP
options
would
be
defined
in
these
two
documents
regarding
xcc,
it
defines
two
TCP
options:
one
intended
to
announce
access
support,
which
is
always
present
in
syn
packets,
another
one
intended
to
communicate
the
ACT
ratio
and,
as
far
as
I
know,
there
is
no
TCP
option
kind
value
assigned
by
Ayana.
For
this
and
about
tar,
which
is
well
has
been
defined
more
recently,
and
also
it
has
the
experimental
intended
status.
E
It
uses
a
single
TCP
experimental
option
kind
value,
so
it
follows
RFC
6994,
so
this
single
option
kind
value
is
used
to
announce,
support
of
tar
and
also
to
request
the
upgrade
by
the
way
announcing.
The
support
of
tar
may
be
done
in
syn
packets,
but
it
doesn't
have
to
be
okay,
and
then
there
is
one
experimental
ID
value
which
is
zero,
zero
AC,
which
has
been
allocated
by
Ayana
next,
please
so
wondering
about
next
steps
and
considering
the
current
state
of
the
document.
The
authors
feel
that
the
document
is
somehow
getting
stable.
E
The
purpose
and
methods
should
hopefully
be
clear.
There
is
even
some
initial
code
of
a
prototype
implementation
started
by
Michael,
led
by
Michael
for
FreeBSD.
So
we
would
like
to
ask
the
working
group
whether
the
document
is
perhaps
ready
for
working
group
adoption.
B
I
just
started
the
poll
pre-request
and
so
now
I'll
give
you
one
minute
answer.
If
you
would
like
to
adopt
this
draft
into
the
working
group.
O
Can
you
explain
a
little
bit
why
you
need
that
so
because
I
mean
you
say,
data
center
inefficient,
but
application
or
TCP
implementation
just
put
push
frag
right,
so
the
it
can
kind
of
explicitly
the
ask
for
immediate
Act
right.
So
can
you
explain
a
bit
about
what
the
exact
programming
data
center
applications?
O
E
There
is,
there
is
one
DNS
related
document
which
is
referenced
in
the
in
the
draft,
which
describes
this
sort
of
issue.
Where
you
may
send
the
packet,
then
you
will
have
a
delay
until
you
get
the
response
which
is
just
introduced.
E
So
I
I
think
the
interaction
the
issue
there.
It's
obviously
8
000
something
it's
about
DNS.
So
there
was
some
interaction
where
an
endpoint
was
sending
a
packet
and
then
the
response
was
delayed
just
because
of
the
presence
of
the
delayed
tax.
So.
E
This
was
discussed
in
initial
presentations
of
this
effort
and
it
seemed
like
it
was
not
exactly
that
we
could
actually
just
push
for
this.
Wow
I
mean
the
the
answer
was
still
delayed,
I
think
I,
don't
remember
all
the
the
details,
but
I.
B
May
ask
that,
just
in
the
interest
of
time
it
might
be.
This
might
be
a
good
side
conversation
since
this
has
been
discussed
in
the
past,
but
I'd
like
Michael
to
talk.
C
O
L
H
So
Korea
I'm
just
a
little
bit
concerned
that
perhaps
there
are
other
things
in
the
network
doing
three:
four:
four:
nine
on
other
act
mindling
and
we
have
offload
like
with
it
with
quick.
We
understand
the
fact,
probably
with
TCP
I'm
less
sure.
So
is
there
information
about
how
the
network
responds
when
you
kind
of
do
this
and
what
result
you
get
when
you
try
and
do
something
at
the
receiver
and
the
Network's
also
doing
something.
H
E
N
That's
why
I
ended
the
queue
he
said
in
the
chat.
If
we
do
something
for
controlling
accurate
and
TCP,
should
we
try
to
keep
common
concepts
with
the
delayed
option
and
quick?
This
would
be
very.
This
would
help
building
common
experience.
B
C
P
Hi
everyone
I'm
William
from
China,
Telecom
and
I,
will
give
the
presentation
of
this
draft
on
behalf
of
the
co-oplers
next
slide.
Please.
P
First
of
all,
I
will
introduce
our
the
background
and
motivation
of
this
draft.
With
the
rapidly
increasing
of
the
customer
number
and
the
service
requirements,
the
service
we
need
a
more
flexible
and
scalable
Network
and
the
increasing
of
the
age
resource
plots
makes
the
service
note
that
provides
the
same
service
functions
can
be
deployed,
deployed
in
different
resource
ports
and
use
the
same
anycast
IP
address
and
as
the
scenario
shown
in
the
figure
the
R1
was
is
the
increase.
P
Router
and
R2
R3
and
R4
are
equals
routers.
Each
EOS
router
connects
to
a
service
node
and
the
three
service
nodes
provides
the
same
service
function
and
when
the
customer
a
accesses
to
the
service,
it
will
send
a
okay
to
R1
and
R1
will
determine
the
optimal
service
notes
for
the
customer,
a
based
on
the
Network's
status
and
since
the.
P
Oh
yes,
to
keep
the
established
connections
unchanged.
The
the
current
Solutions
need
to
maintain
the
customer
based
connections,
data
tables
in
English
and
English
rotors.
This
is
a
lake
of
flexibility
and
scalability.
P
This
solution
can
eliminate
the
needs
to
to
maintain
such
tables
in
the
networked
devices
and
can
improve
the
flexibility
and
scalability
of
large-scale
deployment
of
any
class
Services
scheduling
necessary.
Please
a
way.
We
think
we
also
need
a
new
flag.
We
call
this
ICF
Flex
to
identify
the
center
can
support
the
TCP
service
Affinity
options,
one
the
custom,
a
accesses
to
the
service.
P
It
will
send
a
TCP
package
which,
in
which
the
x
y
n
and
saf
Flex
are
set
and
the
destination
address
of
this
package
is
set
to
the
anycast
IP
address
of
the
service
and
the
well
R1
received
the
package.
It
will
schedule
the
request
and
determines
that
serve
is
not
behind.
P
R4
will
provide
the
service
and
it
will
forwarding
this
TCP
package
to
R4
or
to
the
service
node
through
R4,
and
the
service
node
will
return
its
IP
address
and
Port
information
through
the
service
Affinity
options
to
the
customer,
a
and
finally
customer
a
will
established
the
connection
to
service
now
behind
R4
and
that's
left
please.
P
Oh,
this
is
the
encoding
of
the
newly
defined
TCP
option
and
this
option
can
identify
the
equivalent
for
or
ipa6
address
and
support
information
owned
by
the
service
node,
which
provides
the
service,
and
this
option
is
carried
in
the
TCP
event
package,
sending
by
the
service
node
after
receiving
the
TCP
flm
package.
If
the
the
newly
defined
option
is
included,
the
customer
will
establish
the
connection
to
the
address
specified
in
this
option
and
next
slide.
P
G
Lars
hi
last.
Second,
thanks
for
the
presentation
that
was
very
clear,
I
really
feel
this
is
the
wrong
level
to
solve
that
problem
at
because
you're,
basically
asking
all
TCP
client
Stacks
to
change
so
that
the
server
side
can
optimize
some
load
balancing
right.
So
hey
you
have
the
problem.
It's
never
really
going
to
happen
to
all
clients,
so
you
need
to
continuously
be
able
to
handle
the
case
that
some
clients
won't
do
this.
G
It
also
introduces
sort
of
the
other
way
to
say
this
is
why
wouldn't
you
do
this,
rather
at
the
application
layer
where
you
can
basically
deploy
this?
You
can
deploy
this
with
TLS,
because
this
information
wouldn't
be
secure.
It
can
be
changed
in
the
network,
so
you
can
imagine
an
attacker
might
want
to
rewrite
those
things
and
have
the
clients
go
over
there
or
just
like
route
them
somewhere,
where
there's
no
response
so
that
there's
a
whole
bunch
of
things
here.
G
I
think
that
come
together
that
make
me
sort
of
think
that
you
probably
want
to
solve
this
at
a
higher
layer
rather
than
at
the
TCP
level.
Thank
you.
P
Thank
you.
We
do
this,
a
large
balances
aren't
transmit
layer
is
because
we
think
the
application
layer
have
difficult
in
obtain
the
network
status
in
real
time,
and
so
we
think
away
can
push
this
push.
This
function
in
the
transmission
layer.
K
So
I
I'm
a
closer
and
next
time
I
explained.
You
know
there
are
two
ways.
Currently
there
are
two
ways
to
explore
and
accomplish
the
such
aim.
The
first
is
the
application
letter
only
so,
but
for
application
letter
the
either
Mr
has
said
the
client
or
the
server
cannot
know
the
network
status.
So
we
think
under
the
network,
cannot
do
any
help
for
the
optimized
of
the
traffic.
So
I
think
our
solution
is
align
with
the
coming
concept
for
the
Computing
and
network
convergency
Trend.
K
So
you
know
the
the
network
can't
get
the
service
status
and
they
can
optimize
the
traffic
by
the
for
the
client
traffic.
So,
by
the
way
we
cannot
depend
solely
on
the
network
to
do
such
thing
because
to
keep
the
service
Affinity,
the
network
device
Master.
K
Stop
much
status
table
on
the
device,
so
our
solution
is
a
hybrid
solution
and
they
depend
partly
for
the
network
device
to
select
the
optimal
application
server
and
we
depend
on
the
client
and
server
to
do
something
for
the
for
the
service
affinity.
This
is
our
aim.
Okay,
pop.
J
Hi
before
last
said
what
he
said:
I
I,
hadn't
thought
of
that
and
I
tend
to
agree
with
him,
but
just
I'll
say
what
I
was
going
to
say
anyway,
because
I'm
not
I'm,
completely
thought
about
all
this,
and
that
was
that
it
might
be
better
to
first
of
all
hash
this
information
and
just
have
like
a
cookie
in
this
option.
J
So
you're
not
you
know
as
it
says,
and
then
that
that
reminds
me
of
something
that
I
was
involved
in
doing
earlier,
which
is
a
a
thin
cookie,
but
it
allows
you
to
have
more
information
in
the
Zen
cookie
than
than
currently
possible
in
that
space.
So
it's
it's
a
very
similar
thing
that
gives
you
effectively
a
bit
of
connection
State,
a
soft
State
moving
with
the
packets.
J
So
there
may
be
other
things
you
could
sort
of
fold
into
it
to
make
it
more
useful
so
that
clients
do
use
it
which
might
mitigate
some
of
the
reasons.
Last
said,
it
wouldn't
happen.
B
Ian
sweat
as
an
individual
I
agree
with
Lars.
That
I
think
this
is
probably
the
wrong
layer
to
put
it
up,
but
I
think
regardless
I
think
there
are
some
potentially
serious
privacy
concerns
about
the
way
you
structure
this
and
I
think
an
opaque
field
along
the
lines
of
what
the
quick
LB
draft
proposes
is
more
aligned
with,
like
the
current
values
of
the
ITF.
B
C
F
F
Okay,
so
what's
in
this
draft,
so
basically
this
draft
provide
a
risk
for
the
difference
between
three
condition:
control
standards.
First,
one
is
Arena
and
the
next
one
is
quick,
cleaner
and
the
last
one
is
cubic
and
then
I
have
basically
three
houses
have
three
motivation
to
write
this
kind
of
draft,
and
first
one
is
during
the
cubic
discussion.
We
have
a
lot
of
productive
nice
comments
for
the
acute
experience
so
having
this
kind
of
document.
Maybe
you
know
with
the
record
for
that.
You
know
really
productive
discussion.
F
Oh
pretty
good.
The
previous
slide,
then
another
motivation
for
me
is:
it
can
be
as
a
useful
reference
for
the
future
discussion
with
the
congestion
control
principles.
So
right
now
there
are
some
difference
between
these
three
standard,
but
it
might
be
better
that
this
instance
three
standards
have
the
same
congestion
control
principles
and
if
we
move
to
that
direction,
this
kind
of
document
may
be
a
good
starting
point
for
the
discussion
and
then
sudden
motivation
for
me
is
you
know
having
this
kind
of
document.
F
May
encourage
further
analysis,
because
you
know
some
difference
in
the
draft
may
require
some
more
large-scale
experiment
or
something
like
that,
and
then
what
is
autofocus
for
this
draft
is
the
evaluation
for
the
differences.
So
there
are
some
differences,
but
this
product
does
not
give.
This
difference
is
big
or
small.
Something
like
that.
The
purpose
of
this
document
is
to
provide
the
list.
That's
that's
it
the
because,
as
I
said,
it
may
take
time
to
evaluate
these
differences.
F
Okay,
please
move
on
to
the
next
slide
and
then
I,
just
sort
of
like
to
quickly
overview
of
the
difference
between
the
draft
and
the
I
would
like
to
start
from
Reno
and
the
quick
cleaner,
and
there
are
several
parameter.
Differences
like
an
initial
window
is
different
and
lost
Windows
difference,
and
then
those
detection
scheme
is
a
little
different
and
then
the
my
thing
it
might
be
the
minor
defense
parties
of
X
performance,
so
you
might
need
to
sort
it
out
to
some
extent,
maybe
on
to
the
next
slide.
F
F
Okay
and
then
also
the
thrusters
threshold
of
the
packet
loss
is
different.
Inc
9002,
through
threshold
after
packet
loss,
is
the
half
value
of
congestion
window.
Then
packet
loss
is
detected,
but
on
the
other
hand,
5681
says
it
is
the
half
value
of
right
side
instead
of
congestion
window
and
then
also
LX
58
5681
basically
prohibit
to
use
congestion
window
here,
because
it
says
an
easy
mistake
to
make
is
the
simple
use
congestion
window
rather
than
flight
size.
F
So
to
some
extent
these
two
documents
seems
to
be
contradict
to
each
other.
Please
move
on
to
the
next
slide,
and
so
another
difference
between
Dino
and
the
quick.
Cleaner
is
window
growth
in
slow
start.
This
may
be
overlap
that
mating
talks
in
9002
congestion
window
can
be
increased
by
the
number
of
acknowledged,
by
acknowledged
by
it,
in
a
sub
packet,
but
in
case
of
5681
zero
limit.
So
it
can
increase
at
most
one
segment
and
that's
the
difference.
F
Okay,
now
I'm
moving
on
to
the
okay:
let's
go
to
them
now,
I'm
moving
on
to
the
next
one,
the
rosary,
caballer
algorithm,
is
different,
so
definition
of
the
loss,
recovery
algorithm
is
different
in
9002
it
can
exit
recovery
period
of
and
one
of
any
packet
sent
during
the
recovery
period
is
acknowledgment
in
5681.
F
It
can
end
the
recovery
field.
All
those
segments
found
before
recovery
period
are
acknowledgment,
so
in
case
of
9002
is
just
one
bit.
Transmission
packet
has
been
sent
and
Arc,
and
then
it
can
end
the
recovery.
Also,
there
is
another
rust
packet,
on
the
other
hand,
5681.
If
we
have
a
product
packet,
then
our
packet
has
been
detransmitted
and
should
be
asked.
Otherwise
it
cannot
end
recovery
period.
That's
the
difference
between
the
genome
and
the
quick,
cleaner,
okay.
F
F
83
12
bits
of
this
0.7
0.7
minor
bit
too
aggressive,
but
it
might
not
be
very
fair
with
5681
okay
moving
on
to
the
next
one
and
then
another
difference
is
a
linear
friendly
model
and,
as
we
have
a
wrong
discussion,
there
are
some
you
know.
Skeptical
skepticism
about
you
know
buried
validity
of
this
model,
so
this
is
also
the
discussion
Point
moving
on
to
the
next
libraries.
F
So
this
is
my
last
slide
so
discussion,
point
of
this
class.
Is
these
differences
accessible?
What
needs
to
be
sorted
out?
If
it's
needed
to
be
sorted
out?
How
do
we
proceed?
Do
we
want
to
update
5681,
or
do
we
have
another
way
to
do
it,
and
their
final
discussion
point
is:
is
it
worth
publishing
this
document
as
a
reference?
Why
not
that's
a
feedback
I
would
like
to
get
from
the
community
we're.
D
Usually
obvious
didn't
coordinate
so
like,
as
for
the
5681
versus
9002,
stuff,
I
would
say,
9002
probably
reflects
I
mean,
aside
from
very
quick
specific
things
is
mostly
kind
of
the
the
best
current
practice
that
would
properly
agree
on
and
that,
rather
than
do
something
like
this
I
mean
you've
created
a
checklist
for
5681
best.
So
let's
do
5681
best.
Rather
than
have
an
intermediate
document
for
cubic
stuff.
I,
don't
I,
don't
know
thanks.
G
For
doing
good
thanks
for
doing
the
legwork,
this
is
a
nice
summary
of
all
the
differences.
So
thanks
for
doing
that
for
9002,
specifically
I
think
we
actually
discussed
all
those
sort
of
pretty
we
deliberated
them
and
they
all
deliberately
changed
us
and-
and
they
all
were
last
called
and
so
there's
a
difference
and
we
can
sort
of
decide
what
we
want
to
do
here.
I
would
sort
of
I
argue
that
9000
is
the
newer
document
and
therefore
more
accurately
reflect
current
thinking.
G
But
you
know
it's
a
discussion
for
another
day,
but
but
thanks.
This
is
an
excellent
starting
point
for
future
work.
B
As
an
individual
I
had
one
comment
that
the
congestion
control
working
group,
if
it
was
created,
might
be
the
right
place
to
ensure
consistency
going
forward,
and
with
that
this
is
the
end
of
the
tcpm
session.
Thank
you
for
being
patient
and
going
three
minutes
over.
F
I
can't
can
I
make
one
last
comment.
Sorry,
yeah,
okay,
go
ahead;
okay!
Sorry
just
make
quick
so
about
9002.
So
I'm,
okay
with
you
know
using
two
tools
of
this
parameter
for
9002,
but
to
be
fair
with
TCP
on
the
quick
I.
Think
then,
if
we
quickly
use
this
parameter,
then
one
argument
is
TCP
might
be
used.
The
same
parameter,
yeah.