►
From YouTube: IETF109-TCPM-20201117-0500
Description
TCPM meeting session at IETF109
2020/11/17 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
King
and
in
this
shared
editor
used
for
note.
A
A
A
A
So
I
guess
we
can
start
welcome
everybody
to
the
tcpm
meeting.
We
have
three
coaches
yoshi
was
running
the
slides
today,
michael
scharf,
and
myself.
Next
slide
is
the
note.
Well
I
put
everything
on
there.
You
have
seen
it
in
other
working
groups
and
if
you
want
to
read
it
with
more
details
using
the
links
you
can
go
to
the
url
shown
on
the
top
of
the
page
next
slide.
A
A
In
case
you
are
submitting
a
draft
where
you
expect
tcpm
to
look
at
use
tcpm
in
the
name
of
the
draft,
so
we
can
find
it
easily
using
the
data
tracker
tool
next
slide.
This
is
the
agenda.
We
have
a
packed
agenda,
so
we
have
120
minutes
and
we
have
presentations
for
120
minutes.
We
started
with
the
working
group
status,
hopefully
not
for
15
minutes.
A
We
have
presentations
on
four
working
group
documents,
the
yang
one,
then
the
two
ecn
related
ones
and
then
rc
793
biz
from
west,
and
then
we
have
a
couple
of
individual
documents
drafts
tcp
egg
rate.
We
have
seen
that
already.
A
A
I
should
note
next
slide.
A
This
is
the
the
status
of
the
working
group
documents.
We
have
the
rto
consider
which
is
an
auth
48.
So
it's
done
from
the
working
group
perspective.
We
have
the
rack
document
and
the
slide
is
wrong.
The
the
isg
last
call
was
triggered,
I
think,
an
hour
ago.
A
So
this
is
also
past
handling
of
the
working
group.
We
have
rfc
793
this,
which
is
it's
a
wars
and
working
group
last
call
so
we
haven't
officially
stopped
the
working
through
class
core,
but
it
was
running
and
we
have
an
update
on
this
document
for
the
presentation
on
this.
A
Then
we
have
the
21
40
bis.
The
authors
are
working
on
it.
We
don't
have
an
active
draft
on
it.
That's
why
it's
red.
We
have
accurate
ecn
and
generalized
dcn,
where
we
are
presentations
from
bob.
We
have
tcp
edo,
we've
also
known
active
document
right
now,
so
it's
with
the
authors
and
we
have
hivestar
plus
plus
and
the
yang
document.
A
I
put
the
milestones
in
parenthesis
and
you
see
I
it's
good
to
to
make
this
overview,
because
we've
figured
out
that
we
don't
have
a
milestone
for
the
yang
document,
but
we
will
discuss
this
when
we
come
to
that.
I
should
also
note
that
so
this
is
the
the
list
of
current
working
group
documents
upcoming
work
in
in
the
sense
of
biz
documents.
A
We
have
also
83
12
bis,
which
is
cubic.
Work
was
started
on
that,
but
we
haven't
seen
the
presentation
on
that.
I
think
it's
up
for
next
for
the
next
meeting
and
we
still
have
on
the
to-do
list
3465
this,
which
is
abc.
A
We
haven't
seen
it
for
that,
but
this
is
upcoming.
So
this
this
is
on
the
radar
next
slide
and
I
think
it's
it's
all
we
have
for
for
the
working
group
slides
right.
A
Yeah,
so
that
would
mean
any
agenda
bashing.
If
you
go
back
one.
B
B
You
probably
saw
the
email
to
revise
rfc
8312,
which
is
cubic
and
there's
a
repo
for
it,
and
there
was
a
dash
0
individual
draft
yesterday,
there's
not
a
ton
of
changes
that
we're
planning
on
making
it's
basically
bringing
the
spec
back
in
line
with
what
at
least
is
doing,
and
hopefully
we
can
hear
from
windows
and
other
implementations
that
they're
doing
also
what
linux
is
currently
doing,
or
we
can
also
see
if
there's
other
changes
that
we
might
want
to
roll
into
the
spec
and
then
push
to
linux.
B
I
expect
this
to
move
pretty
quickly
and
obviously
we're
going
to
ask
for
working
group
adoption
at
some
point
soon,
which
I
hope
will
be
a
non-event
and
and
this
could
this
could
basically
be
done
in
a
couple
of
weeks
or
a
couple
of
months.
I
don't.
I
don't
think
this
will
need
a
long
time.
B
So,
if
you're
interested
in
this,
I
know
that
a
bunch
of
quick
people
are
implementing
cubic
for
the
first
time
based
on
the
rfc
and
they've,
given
some
feedback,
if
you're
interested
in
this
sort
of,
please
follow
along
in
the
github
repo
and
interact
there.
Thank
you.
A
Thank
you,
can
you
actually,
can
you
go
back?
One
slide.
C
Yeah,
so
that's
five
like
right.
B
The
status
at
the
moment
is
an
individual
draft,
and
oh,
are
you
asking
about
what,
because
it
says
standards
track?
C
B
Yeah,
so
the
so,
the
structure
of
the
document
at
the
moment
is
exactly
like.
We
had
an
rfc
8312
so
that
diffing
the
changes
in
the
future
is
easier.
I
optimistically,
I
didn't
want
to
have
a
long
discussion
about
it,
so
I
didn't
say
anything
about
it.
I
submitted
it
with
a
target
for
standard
strike,
simply
because
I
think
it's
time
for
cubic
became
a
standard
strike
document.
B
I
know
we
typically
don't
do
this
for
congestion
control
algorithms,
but
for
this
one
it,
it
kind
of
seems
like
a
no-brainer,
and
we
can
certainly
discuss
this
when
it
comes
to
adoption
time.
I
don't
feel
strongly
about
this,
but
I
at
least
wanted
to
try
and
make
the
argument
that
we
should
do
that.
C
A
I
think
that
this
one
perfect,
so
anyone
wanting
to
change
the
agenda.
A
D
E
All
right,
so
I
will
be
talking
about
the
updates
to
the
yang
model
draft,
since
it
became
a
workgroup
document.
I'm
sorry,
it
says
zero
zero
here,
but
actually
it
means
it
includes
zero,
zero
and
zero
one
zero
zero
doesn't
have
too
many.
I
don't
have
any
changes
per
se
next
slide.
Please
all
right.
As
I
said,
zero
zero
was
the
individual
draft.
That
was
just
the
name.
E
We'll
talk
a
little
bit
about
the
include
tcp
options
versus
ignore
tcp
options
in
the
next
slide.
Sorry,
I'm
not
quite
ready
to
go
to
the
next
slide.
Okay,
we
for
the
accept
ao
mismatch
versus
accept
key
mismatch.
E
We
accepted
that
change
and
have
incorporated
that
in
the
upcoming
changes,
and
then
there
was
a
request
to
add
the
complete
tree
diagram
for
the
model,
which
I
believe
we
had
done
in
the
appendix
of
the
draft
and
as
a
process
we
supposed
to
have
a
idea
of
copyright
statements
in
the
model
so
went
ahead
and
added
that
we
decided
that
I
think
we,
the
draft
needed
an
additional
reference
to
the
keychain
model,
as
described
in
rfc
8177,
because
that
is
something
that
would
be
needed
if
anyone
was
trying
to
configure
tcpao
and
then
we
opportunistically
looked
took
the
draft
that
draft
touch.
E
Tcpm
aortas
vectors
has
some
good
examples
on
ao
and
we
took
that
as
a
basis
for
giving
setting
up
an
example
of
how
to
configure
tcpao,
so
that
example
is
now
also
in
the
draft.
E
E
So
there
was
some
discussion
on
the
mailing
list
about
what
to
call
essentially
when
tcpaos
include
tcp
options,
so
rfc
7950,
which
is
the
yang
1.1
rc,
has
the
following
definition
for
default,
not
definition,
but
it
has
the
following
description
for
default
value
of
the
leaf.
E
E
So
with
that
in
mind
and
based
on
what's
being
discussed
in
the
mailing
list,
it
seems
the
consensus
is
around
setting
the
node
to
default.
True,
but
keeping
the
name
include
tcp
options
now
some
have
suggested
well.
Why
not?
Just
rename
include
tcp
options
itself,
because
the
word
include
is
a
key
word
in
yang
and
it's
used
to
include
other
models,
but
its
meaning
here
is
different
and
in
my
mind
at
least
it's
clear.
So
if
you
do
want
to
change
it,
what
are
the
options
we
haven't
run?
E
Okay,
as
no
questions,
so
let's
move
to
the
I
think.
What's
the
final
slide,
all
right
so
as
soon
as
next
steps
are
concerned,
we're
looking
at
possible
implementations
of
the
model
on
in
linux
and
then
and
if
that
happens,
we'll
present
the
results
of
that
implementation
in
this
working
group
and
that's
pretty
much
it.
A
Thank
you,
questions.
A
A
So
this
we
had
some
sort
of
discussion
yesterday,
so
I
would
suggest
a
milestone
of
april
next
year,
which
allows
another
feedback
round
on
at
the
next
tcpm
meet
or
at
the
tcpa
meeting
of
the
next
ietf
and
then
going
to
work
into
class
call.
Are
there.
A
So
the
next
is
bob
bobset
has
two
presentations
more
accurate
ecn,
feedback
and
tcpm
in
ecm
plus
he
has
one
set
of
slides
so
yeah.
She
can
bring
that
up.
F
Hi,
can
you
hear
me
perfect
good?
Well,
these
slides
are
actually
in
the
opposite
order
to
the
agenda
so
but
yeah
we'll
go
straight
to
that.
One
then
we'll
jump
to
the
first
one
okay.
So
this
is
a
status
update
on
more
accurate
ecn
feedback
in
tcp.
F
The
draft
there
is
13
next
slide,
please
a
very
quick
recap:
explicit
congestion
notification
feedback
in
original
tcp
only
allowed
for
one
or
more
feedback
of
congestion
indications
per
round
trip,
because
that
was
all
tcp
needed
at
the
time,
but
this
is
to
allow
more
than
one
next.
F
The
yeah
sorry
next
yep
so
essentially
there's
two
fields
in
the
accuracy
and
protocol
a
three
bit
field
in
the
main
header,
repurposing
three
flag,
bits
to
make
a
counter
after
the
handshake
and
an
option
next
so
activity.
Since
the
last
update,
which
was
in
april
you'll,
see,
there's
been
quite
a
few
drafts.
F
Sorry,
you
probably
can't
read
that
image
at
the
top,
but
it
says
that
in
october,
if
you
read
the
text,
the
there
was
just
some
minor
editorial
fixes
and
that
that
reminded
michael
that
I
hadn't
dealt
with
the
field
order,
which
I
thought
I
had
so
I
dealt
with
that
and
also
at
the
same
time,
realized
the
reason
I
hadn't
dealt
with.
It
was
because
I
found
another
to-do
list.
F
My
to-do
list
had
a
fork
in
it,
so
there
were
two
other
things
which
I
will
I
have
separate
slides
on.
So
I'll
go
straight
to
the
next
slide,
please
yeah.
So
this
was
what
michael
wanted
to
deal
with
the
field
order
which
previously
had
the
receiving
implementation,
taking
the
order
from
the
first,
the
initial
value
which
was
fragile
to
implement.
F
So
I've
switched
to
a
different
way
of
doing
it,
which
is
much
simpler,
suggested
by
michael
and
that's
to
just
use
two
option
kinds,
one
for
each
order.
You'll
see
here.
The
problem
is
that
we
want
to
be
able
to
use
either
one
two
or
three
fields:
that's
where
the
square
brackets
are
there
in
inside
the
fields
and
so
but
but
depending
on
which
counter
is
changing,
whether
it's
the
echoing
sd0
or
st1,
depending
on
which
one
is
changing.
F
More
often
you
you,
the
implementation,
might
want
to
use
a
different
order
to
for
efficiency,
so
you've
got
each
tv,
0
condition
is
experienced
in
east
d1
or
the
other
way
around
east.
He
won
congestion
experience
and
he
sees
zero.
F
There
were
two
alternatives:
either
the
well
two
main
alternatives,
either
two
option
kinds
or
adding
a
flags
bite
which
elbow
proposed
and
he
had
a
use
for
one
of
the
flags.
F
I've
said
no
other
proposals
were
forthcoming.
That's
michael's
pointed
out
that's
wrong.
Since
I
wrote
these
slides
on
the
list
that
there
was
one
where
you
could
have
a
flag,
an
extra
byte
for
one
of
the
orders
and
not
the
other,
so
that
you
could
use
the
length
field
instead
of
the
kind
field
I'll
come
on
to
that.
F
So
the
concern
of
not
having
a
flags
bite
is,
you
haven't,
got
future
extensibility,
but
the
downside
of
that
is.
You
have
to
burn
one
bite
of
option
space
on
most
packets
because
you're
sending
this
option
quite
frequently
and
in
the
draft,
for
I
think
since
the
beginning,
but
it
was
probably
added.
F
Maybe
you
know
draft
one
or
something
there's
been
a
forward
compatibility
which
would
allow
you
to
add
a
flags
bite
by
saying
that
the
the
implement
the
receiving
implementation
has
to
understand
lengths
that
are
not
valid
for
the
for
the
current
specification,
and
it
just
reads
three
byte
fields,
or
at
least
up
to
three
three
byte
fields
and
ignores
the
rest.
F
And
so,
if
you
had
lengths
five,
eight
or
seven,
you
would
read
the
three
bite
fields.
If
you
had
length
six,
nine
or
whatever
I
just
said
11.
In
other
words,
one
more
bite,
then
you
could
you
could,
or
in
the
future
the
working
group
could
define
a
flags
bite
to
stick
on
the
end
of
either
a
one
one,
three
bite
field,
two
bite
fields
or
three
three
bite
fields
to
to
allow
future
extensibility.
F
If
we
do
need
a
flags
bite
or
any
other
extensibility,
we
might
want
to
well,
not
any
other.
You
know
you're
slightly
limited,
but
you've
got
a
reasonable
amount
of
flexibility
just
by
allowing
that
bit
of
forward
compatibility.
F
So
the
the
logic
of
choosing
the
two
option
kinds
means
it's
most
efficient
for
now,
given
we
have
or
we
don't
need
the
flags
by
it,
but
we
can
add
one
in
the
future,
so
it's
sort
of
best
work
both
worlds,
just
to
explain
why
we
don't
need
a
flags
bike
now,
because
ilpo
proposed
one
flag
bit
or
two
sorry,
two
flag
bits
to
be
used
for
a
counter
of
which
field
in
future,
you
would
assume
was
changing
if
you
didn't
get
any
of
the
fields,
but
the
problem
with
that
was
it
was
designed
for
atklos
in
case
there
was
that
class,
but
it
didn't
allow
for
the
fact
that
it
itself
could
get
lost.
F
So
it
seemed
a
bit
circular.
So
we
don't
really
have
any
robust
proposals
for
a
flags
bite.
So
let's
leave
it
as
the
possibility
of
future
extensibility
and
use
two
kinds.
That
was
the
conclusion.
That's
what
written
up
and
we
can
have
discussion
about
that
at
the
end,
I'm
hoping
to
allow
time
for
that
next.
F
Right,
so
the
other
change
I
found
on
my
to-do
list
was
to
add
in
a
recommendation
not
a
requirement
to
check
that
you're,
not
getting
constant
congestion,
exposure
marking
on
every
packet
and
it's
written
flexibly,
so
that
implementers
can
use
future
experience
on
what
mangling
has
found
to
change
things.
But
it
says
for
three
or
four
rounds.
F
If
you
continually
get
ce
marking,
then
disable
ecm,
but
still
feedback
any
you
get
from
the
other
direction
in
case
it's
an
asymmetric
problem
right
and
that's
current
practice
in
at
least
three
implementations.
I
know
of
of
of
normal
ecm
classicising.
F
So
next
slide.
F
And
the
final
change
we've
made
this
time
round
other
than
the
odd
editorial
fix,
is
to
considerably
beef
up
the
section
on
recommendations
for
middle
boxes
and
and
clarify
and
and
divide
it
up
into
four
sections
which
it
talked
about,
but
didn't
really.
F
It
wasn't
really
clear
what
you
were
talking
about
as
you
went
through
the
section
so
we've
put
subheadings
in
and
there's
no
change
to
the
sections
are
subsections
on
proxies
and
normalizers
other
than
putting
a
heading
on
them
and
then
there's
there's
more
clarification
on
the
last
two
on
ack
filtering.
F
F
Now
it
previously
said
you
should
not
coalesce
at
all,
but
we've
put
a
condition
on
the
conditioned
on
that,
and
that
is
that,
if
it's
an
accurate
ecm
packet
and
if
the
middle
box,
that's
doing
it,
can
ec
and
mark
the
idea
being
here
that
you
continue
doing
act
filtering
otherwise,
if
you're
doing
act
filtering
to
improve
the
performance
like
on
a
satellite
link
or
well,
you
know
any
challenged
upstream
link.
F
But
if
you're,
if
you're
ecn,
marking
you're,
essentially
giving
the
responsibility
for
doing
act,
filtering
to
the
end
system
and
you're,
giving
it
the
information
or
the
network
is
giving
it
the
information
to
do
that,
because
accurate
ecn
can
pick
up
ecn
information
on
purex
and
we
will
leave
the
specification
of
that
of
potential
congestion
control
of
the
axe
stream
for
the
future.
F
But
we
we've
got
the
mechanism
now
in
there,
and
we've
got
a
recommendation
to
middle
boxes
of
how
to
give
that
information
to
the
end
systems,
and
that
will
also
allow
things
like
encryption
to
be
used
in
future.
If
you
want
so
that
the
the
end
systems
can
have
a
way
of
doing
act
filtering
themselves
for
their
own
performance.
F
It's
been
some
list
discussion
on
this
some
considerable
discussion.
I
don't
know
whether
gory
wants
to
complete
that
discussion,
because
it
was
rather
long
discussion
and
I
think
I
was
the
last
one.
F
F
No
act,
congestion
control
at
all
if
which
was
gory's
concern,
but
it
allows
us
to
add
it
in
the
future.
F
The
next
one
on
segmentation
offload.
No
sorry,
not
next
slide.
The
next
bullet
go
back.
Please
yeah.
The
segmentation
offload,
we've
just
described
better.
How
incremental
deployment
would
happen
from
today's
practice,
where,
if
you
see
or
if
a
offload
hardware
sees
these
in
flags
change,
it
ejects
as
much
of
a
segment
as
it's
as
it's
built
from
the
cache
to
allowing
the
field
to
change,
but
ejecting
it
before
it
wraps.
This
is
the
three
bit
field,
and
so
we
described
how
that
incremental
deployment
would
happen
right
next.
F
So,
just
now
the
procedural
side
just
to
explain
that
accurate
ecn,
which
is
the
second
draft
there
in
the
middle,
is
now
intended
for
proposed
standard.
F
The
ecn
plus
plus
draft
that's
experimental
depends
on
it
normatively
and
they're
both
hanging
at
the
moment,
waiting
for
the
allocation
of
ect1
in
that
tsp
wg
draft
down
there,
the
l4s
one,
which
has
a
milestone
for
next
april
and
the
that
sets
up
the
possibility
of
future
drafts
on
congestion
control
that
could
depend
normatively
on
accurate,
ecm,
so
accurate
ecm,
doesn't
depend
on
anything
else,
but
other
things
depend
on
it.
It's
the
conclusion
of
this
slide
next.
F
Yep,
that
is
the
end,
so
I've
said
ready
for
wedding
group.
Last
call,
as
I
said,
there's
that
conversation
with
gary
to
complete
whether
he's
happy
with
that
argument
and
if
not,
we
can
make
a
minor
changes
to
the
text
before
any
working
group.
Last
call
and
there's
also
a
conversation
that
excuse
me
that,
under
the
subject
error
in
accurate
ecn,
where
there's
a
possible
wording
change
to
clarify
the
which
again
is
a
conversation
that
hasn't
quite
finished
on
the
list
to
clarify.
F
Excuse
me,
I'm
just
trying
to
think
of
how
to
describe
it
briefly,
the
the
possibility
that
a.
F
An
ack
of
a
pure
act,
or
at
the
moment
the
way
the
wording
is
stated.
It
looks
like
you've
got
to
akapurak,
so
we've
just
got
to
make
that
clear
without
precluding
possible
acts
of
pure
acts
in
the
future,
in
a
sort
of
keep
alive
type
situation
that
I
mentioned
on
the
list,
but
we
can
deal
with
that
on
the
list
and
yoshi
is
offered
to
help
with
that
as
well.
F
A
F
And
otherwise,
yeah
I'd
like
to
hear
what
the
chairs
believe
the
current
statuses
regarding
whether
this
would
go
to
working
group
last
call.
G
Yeah
hi,
this
is
mike,
michael
speaking
from
the
floor.
Just
a
quick
comment,
since
I
mean
I
agree
with
the
current
content
of
the
document.
So
it's
pointless
to
argue
about
the
alternatives,
but
bob.
I
think
your
reasoning
against
links
encoding
is
not
entirely
correct
and
I
will
follow
up
on
that
on
the
list
and
that's
to
me
that's
an
example.
G
You
should
actually
have
the
discussion
before
the
meeting
on
the
list,
so
I
will
not
have
any
discussion
here
for
the
sake
of
time,
but
I
think
what
you
just
said
is
not
entirely
correct
the
trade-offs
with
the
different
encodings
and
it's
a
bit
concerning
to
me
that
you
have
not
discussed
this
on
the
list
before
doing
edits
to
the
document.
But.
F
F
Yeah
I
apologize
for
that.
That
was
like
I
say
because
I
I
lost
my
to-do
list,
half
of
my
to-do
list.
Sorry
about
that.
H
A
Okay,
okay,
so
this
means
please
continue
discussion
on
the
list
and
if
things
are
resolved,
we
can
come
back
to
working
in
class.
To
the
question
related
to
what
your
class
call
you
have
a
slider
regarding
ecm,
plus
plus.
F
F
F
Okay,
it's
very
easy.
We
just
refreshed
this
draft.
There's
been
no
changes.
It's
just
waiting
in
a
holding
pattern
for
the
accurate
ec
and
draft.
They
were
just
minor
changes.
That's
it!
You
have
two
minutes
discussion
if
you
want
on
maybe
on
what
the
status
of
both
these
is
regarding
working
group
last
school.
A
Yeah,
I
guess,
since
this
is
since
the
the
ecm
plus
plus,
is
referring
to
the
more
accurate
one
and
the
more
accurate
one
needs
some
discussion
on
the
mailing
list.
I
would
say.
A
We
wait
until
the
the
more
accurate
is
finished
before
starting
and
working
the
glass
call
on
the
generalized
one.
A
Okay,
thank
you
for
the
presentation.
If
there
are
no
questions.
I
So
we
have
been
working
on
updating
rxd73
for
a
while,
and
there
was
a
working
group
last
call
some
time
ago.
A
few
sets
of
comments
came
in
and
the
revision
that's
posted.
Now,
revision
19
addresses
most
of
those
comments.
I
The
small
number
that
are
left
dangling
are
itemized
here
and
I'm
planning
on
trying
to
drive
these
to
closure
in
the
near
term
by
starting
a
threat
on
each
of
them
and
proposing
a
path
forward.
I
I
think
that
none
of
them
are
huge
compatibility
issues,
they're
mainly
just
questions
of
what
we
want
the
messaging
to
be
in
this
document,
so
to
go
through
them
really
quickly.
In
case
they
give
anyone
strong
ideas
about
what
we
should
do.
There's
a
question
on
how
we
phrase
the
fact
that
options
must
have
a
length
field.
I
It's
it's
really,
a
matter
of
big
must
or
little
must.
So.
I
think
we
just
need
to
find
specific
wording
that
people
can
agree
on
there.
I
I
I
think
that's
a
good
suggestion
and
I
think
it's
in
the
spirit
of
things
we've
done
previously
like
in
the
tcp
roadmap,
so
I
think
it's
probably
okay,
but
I
would
definitely
like
to
hear
if
there's
more
working
group
support
for
that
or
if
there's
any
pushback,
because
it
is
slightly,
I
would
say,
outside
of
our
scope,
of
not
changing
anything,
that
the
standards
track
documents
say
should
be
done
in
a
tcp
implementation,
which
was
sort
of
the
ground
rule
going
in
on
this
document
when
we
started
that
work
same
thing
actually
true
for
the
the
next
two
bullets,
which
are
syn
timeouts.
I
Having
a
requirement
of
three
minutes,
praveen
suggested
that
that
is
a
large
number
and
well
that's,
I
guess
hard
to
argue
against.
It's
also
true
that
changing
that
is
sort
of
outside
the
scope
that
we
chartered
this
document.
For.
I
So
I
would
really
like
to
hear
if
anyone
else
has
thoughts
on
that
and
additionally,
I
think
there's
a
good
suggestion
that
we
should
say
that
rfc
5681
congestion
control
is
a
sort
of
baseline
that
must
be
supported,
but
that,
of
course,
other
algorithms
can
be
supported
as
they
are
in
common
implementations
and
those
can
be
optionally
enabled.
I
I
I
would
like
to
I
have
so
two
more
charts
and
then
maybe
we'll
come
back
to
this
one.
If
anyone
wants
to
say
anything
so
I'll
go
to
the
next
chart,
which
is
a
plan
for
next
steps,
so
get
closure
on
the
items
previously
mentioned.
I
want
to
update
the
draft.
I
However,
we
agree
and
also
work
a
little
bit
more
on
the
changes
from
rfc
793
section,
and
then
I
think
this
revision,
20,
that
will
be
posted,
should
be
ready
to
go
forward
unless
there's
some
reason
to
keep
the
working
group
last
call
open
for
even
longer
either
way
is
is
fine
with
me,
but
I
would.
I
would
think
that
it's
getting
ready
for
ad
review
or
for
the
working
group
shepard
review,
at
least
if
you
go
to
the
next
chart.
I
I
just
wanted
to
briefly
acknowledge
the
huge
number
of
people
that
have
been
contributing
to
this
over
the
years.
I
think
the
activity
level
is
hard
to
see
because
we've
been
working
on
it,
so
long
and
sort
of
individuals
contribute
in
spurts
over
the
years,
but
this
has
actually
been
quite
quite.
A
number
of
people
have
contributed
this
over
the
years
and
I
just
wanted
to
acknowledge
that
here.
F
Yeah,
I
was
just
a
feedback
on
the
last
point
about
5681
from
praveen.
I
was
just
thinking
if
it's
a
challenge
device,
and
so
it's
implemented
co-app
or
something
similar.
I'm
not
quite
sure
why
you
would
want
to
say
it's
got
to
have
the
baseline
in
it
as
well.
That
seems
like
a
just
purely
implementation:
choice,
not
a
something
that
should
go
in
an
rfc.
A
A
J
Yeah,
similar
to
bob's
comment,
I
think
it's
a
little
odd
to
say
that
you
must
implement
5681,
that
we
would
say
that
a
tcp
implementation
that
just
jumps
straight
into
cubic
or
something
would
be
wrong.
Somehow,
I'm
not
sure
what
the
language
is
I'll
think
about
it
a
little
bit
and
when
you
start
that
thread,
maybe
I'll
have
something
better.
I
Yeah,
so
I
think
this,
the
the
source
of
this
is
1122
actually
says
that
sort
of
reno
is
the
you
must
implement
for
congestion
control,
and
we
have
never
changed
that
over
the
years.
Although
we've
implem
adjusted
and
incremented
the
description
of
reno
from
what
1122
had
through
2581
and
5681
over
the
years,
I
don't
think
anything
changed.
The
1122
requirement
that
that
is
the
sort
of
basis.
J
I
mean
it
is
true
that
we
don't
have
a
ton
of
standards
in
this
area,
although
I
guess
lars
is
doing
his
best
to
fix
that.
A
A
A
K
Okay,
magic,
I
just
had
to
toggle
it
again
so
just
very
quickly.
I
don't
have
a
good
suggestion
on
the
text
here,
but
I
would
strongly
recommend
in
general
that
we
move
away
from
trying
to
standardize
these
things
in
the
the
tcp
rfc
at
least
be
very
much.
It's
it's
a
question
really
of
whether
we
want
to
hang
on
to
something
that
we've
written
down
like
30
years
ago,
or
we
want
to
reflect
what
common
practice
is
these
days
and
for
all
practical
purposes.
K
Almost
nobody
uses
reno
widely
speaking,
so
we
we
should
consider
that
republishing
something
with
just
text,
because
it's
already
there,
I
think
I
would
argue,
is
not
the
most
sensible.
A
A
J
J
But
do
we
have
a
document
today
that
that
really
kind
of
puts
out
the
the
expectations
of
a
new
congestion,
control
and
kind
of
the
st
and
kind
of
the
the
things
that
the
the
the
qualities
it
needs
to
have
to
sort
of
be
judged
to
be
friendly.
J
It's
probably
too
large
of
a
thing
to
put
in
this
draft,
but
but
if
there's
something
succinct,
we
can
say
in
that
area
that
maybe
fall
short
of
an
actual
full
spec.
That
would
be
valuable.
I
I'm
I'm
actually
thinking
the
right
thing
to
do
is
to
say
an
ietf
standards
track.
Congestion
control
is
what
must
be
included
and
others
can
be
included
at
an
implementer's.
Will.
K
I
I
would
gently
push
back
against
that
again.
For
the
same
reason,
I
don't
see
a
reason
to
require
an
id
standard
congestion
controller
when
nobody's
going
to
follow
that
requirement
now
we're
requiring
because
we
want
to
be
consistent
with
our
document
set
or
are
we
trying
to
reflect
reality
here?
K
K
Martin
duke's
question
is
a
good
one
and
that's
something
that
we
actually
tried
to
chase
for
the
quick
loss
direction
and
congressional
control
draft
and
unfortunately,
that
isn't
a
good
set
of
common
principles
or
a
document
that
says:
okay,
here's
what
a
condition
control
condition
control
ought
to
have
as
as
its
properties,
but
but
just
because
we
don't
have.
That
doesn't
mean
that
we
we.
K
So
I
mean
I'm.
I'm
I'd
be
personally
comfortable
with
in
the
document
saying
that
you
need
some
sort
of
condition,
controller
and
and
it's
that
that
we
have
one
in
5681
and
there
are
other
alternative
ones.
Yes,
we
can
point
to
cubic
if
you
want-
and
we
can
even
point
to
something-
that's
not
an
rfc
form.
Bbr
is
used
commonly
these
days
and
despite
what
we
think
about
it,
it
is
being
commonly
used.
K
K
A
A
F
M
D
D
D
We
have
identified
two
sets
of
such
scenarios
in
terms
of
the
congestion
window
size
in
use
the
first
one
being
so-called
large
congestion
window
scenarios,
meaning
congestion
windows
size
much
greater
than
the
mss
and
the
other
one
so-called
small
congestion
window
scenarios,
meaning
congestion
windows
size
up
to
the
order
of
one
nss.
D
For
example,
we
have
data
centers
where
the
bandwidth
delay
product
may
be
up
to
the
order
of
one
mss.
So
in
that
case
the
led
x
will
incur
a
delay
much
greater
than
the
rtt.
Therefore,
possibly
degrading
performance
severely
and
also
in
transactional
data
exchanges
or
when
the
congestion
window
has
decreased
eliciting
immediate
acts
may
help
avoid
idle
times
and
may
help
allow
faster
congestion
window
growth.
D
Next,
please
so
about
the
updates
in
dash
01.
The
first
update
is
in
section
one.
This
is
intended
to
address
the
comment
by
stuart
tjer.
Well
now
we
have
expanded
the
motivation
for
the
need
to
use
immediate
acts.
In
some
iot
environments,
there
are
some
iot
devices
with
really
constrained
memory,
with
enough
ram
only
for
some
buffer
of
one
mss.
D
The
first
one
was
a
suggestion
by
janna,
by
which
tcp
sender
in
this
case
can
indicate
that
it
has
some
reordering
tolerance
by
setting
a
new
field
in
this
option,
which
we
call
ignore
order
here,
and
in
that
case
the
tcp
receiver
must
continue
to
send
monarch
every
our
data
segments,
even
when
reordering
occurs.
By
the
way
here,
we
have
used
the
same
name
for
the
field,
as
in
the
draft
that
janna
pointed
to
which
is
drafting
the
context
of
the
quick
protocol.
D
D
So
here,
tcp
center
can
request
now
an
immediate
act
for
a
data
segment
and
also
for
the
subsequent
and
data
segments.
Thanks
again
for
the
suggestions
and
next
please
so
this
would
be
the
updated
option.
Format
which
now
includes
two
new
fields
which
correspond
to
the
two
new
features
mentioned
in
the
previous
slide.
D
The
first
field
is
the
inner
order
field,
which
is
a
one
byte
field
which
is
boolean,
may
be
set
to
true
or
false,
and
the
next
fill
is
n,
which
indicates
the
number
of
subsequent
data
segments
for
which
we
are
requesting
immediate
x
when
power
is
set
to
zero.
D
So
here
there's
a
question
that
maybe
answered,
maybe
today
or
on
the
list
depending
on
available
time,
which
is
that
perhaps
we
might
want
to
consider
to
save
one
byte,
for
example,
thinking
about
iot
environments,
where
every
single
byte
is
is
relevant,
so
we
might
want
to
reduce
the
size
of
the
r
field
from
eight
bits
to
seven
bits
and
perhaps
use
the
remaining
one
bit
as
the
ignore
or
the
field.
D
And
the
other
update
in
the
draft
is
that
now
we
explain
that
the
tcp
endpoint
announces
that
it
supports
the
tar
option
by
including
the
option
format
in
package
with
the
same
bit
set.
However,
well,
in
that
case,
the
r
ignore
order
and
end
fields
would
be
ignored,
and
that
would
be
perhaps
an
alternative
which
could
be
using
a
dedicated
short
for
byte
format.
L
D
N
Yes,
I
have-
I
read
this
through
this
morning
and
something
like
question
one
occurred
to
me
or
just
on
reading
that.
N
D
A
A
A
Okay,
so
you
got
some
feedback
charts
and
I
would
say
just
continue
the
discussion
on
the
list
and
thanks.
C
O
Hey
can,
can
you
hear
me.
M
O
Hi
this
is
kevin.
I'm
president,
I'm
going
to
presentation
present
this
tcp
ets
for
extensible
timestamp
options
accessories.
O
O
We
want
to
have
a
meccans
mechanism
in
loss
recovery
to
have
a
better
a
minimum
rto
estimation.
So
in
the
legacy
implemented
implementation,
the
minimum
rtl
is
set
to
200
milliseconds,
which
which
might
be
two
on,
and
the
third
motivation
here
is
to
improve
the
pacing
rate
computation
as
we
compute
the
pacing
rate
by
k
times
conjunction
window
divided
by
smooth
rtd,
and
this
srtd
is
measured
by
the
ltd
that
includes
the
delay
x.
O
So
it
will
bloated,
hugely
say
100
times
than
the
natural
quality
next
size
piece.
The
existing
problem
in
the.
O
Next
slide,
please,
so
here
is
how
we
compute
this
ecr
delay.
This
idea
can
be
computed
by
this
algorithm,
so
we
will
have
ts
latest.
O
O
So
in
the
next
I
will
show
two
examples
demonstrates
how
we,
how
we
compare
these
two
components
and
what's
the
meaning
of
these
two
components,
also
note
that
you
see
so
also
note
that
each
idea
is
zero.
When
there's
no
act,
delay
and
the
tcci
is
the
latest
received
timestamp
next
piece.
O
O
So
we
have
the
green
color
mark
marked
to
the
latest
act
delay.
That
is
the
the
time
from
when
the
act
is
sent
to
the
time
this.
This
data
package
is
received,
so
it's
10
minus
2,
which
is
8.
So
so
when
the
t3a
received
this
act,
it
can
compute
this
network
t
by
11,
which
is
the
arrival
time
of
this
act,
minus
one,
which
is
the
tccr
minus
ecl
delay,
which
is
eight.
O
Okay
sure
how
many
minutes
do
I
have.
O
O
When
the
ack
is
is
acting
two
packets,
so
the
tcpa
is
sent
to
send
the
first
package
that
is
delayed.
The
act
is
delayed
and
then
send
another
package
at
time.
5..
O
D
O
O
So
it's
it
is
four
and
then,
when
the
sender
received
this
act,
it
can
compute
this
naturality
to
be
seven,
which
is
the
arrival
time
minus
one
minus
four.
So
this
is
the
rdt
of
p1
prime,
which
is
the
second
package
next
race.
Please.
O
K
O
Yeah,
I
guess
this
the
second
last
slice
before
discussion,
so
so
we
also
exchanged
the
maximum
act
delay
in
the
sim
package
during
the
handshake.
So
this
maximum
activate
can
be
used
to
binding
the
minimum
rtl.
O
Which
which
will
be
useful
for
computing,
the
rto
timer
yeah
next
size
piece.
O
So
in
the
discussion,
I
will
quick
discuss
some
interaction
with
pause
check,
so
this
required
that
we
disable
the
pause
check
if
the
connection
is
idle
for
say
half
an
hour
and
if
your
detection
algorithm
will
stay
the
same.
O
O
The
transmission
timeout,
we
don't
it's,
not
affected,
so
it
is
using
the
same
mechanism
and
we
this
option.
We're
left
with
left
space
for
three
sac
blocks,
acceleration.
O
Please
come
to
an
end:
yeah
mailbox
security.
We
don't
add
new
security
so
for
future
extension.
P
P
With
the
soon
option
option
to
be
really
much
more
space
efficient
and
for
ideas
how
to
do
this,
I
would
like
to
refer
to
the
tcpm
timestamp
negotiation
draft
that
I've
had
a
couple
years
ago
and
also,
I
believe
this
must
need
to
be
an
exclusive
dedicated
option.
It
could
be
an
extension
of
73,
23
and
just
differentiated
by
the
length
field
again.
Thank
you.
F
A
L
Yes,
sorry,
I
was
yeah,
probably
my
mic
and
a
problem.
So
I
was
saying
this
is
good.
Work
and
delayed
act
should
be
considered
during
the
calculation
of
retransmission
timeout
and
the
draft,
or
at
least
a
slice
mentioned
that
those
would
not
be
affected
by
this
change
or
this
new
addition
in
the
timestamp.
L
L
Exactly
yeah
so
yeah,
so
ledpad
is
one
of
them
and
I
have
been
recently
seeing
some
problems
with
delayed,
rtt,
sorry
delete
x
and
the
rtt
gets
really
inflated
when
the
network
rtt
is
actually
not
so
definitely.
This
is
something
I
would
look
into.
Thank
you.
O
O
Yeah,
the
the
max
dealer
is
actually
a
really
useful
thing.
It
solves
the
they
may
not
your
problem
in
the
data
center,
so
I
think
that's
very,
very
useful.
I'm
not
very
convinced
about
coupling
that
with
timestamps,
but
I
will
continue
to
review
this
draft.
O
One
question
I
have
is:
are
you
considering
considering
to
publish
this
as
experimental,
or
are
you
planning
to
request
like
a
formal
option,
type
of
those
yeah
we
we
are
requesting
for
formal
option
kind
after
we
get
in
ifc.
A
Okay,
so
we
have
to
stop
here.
We
have
five
minutes
behind
the
schedule,
so
I
think
next
is
mptcp.
Rob
e.
M
Best,
so
I
want
to
give
you
an
update
to
the
multi-part
tcp
robust
session
establishment.
We
proposed
some
ideas
ago.
That's
some
joint
work
and
presentation
from
ciao
and
colleagues
from
huawei
and
myself
next
slide,
please
so
just
a
short
recap.
So,
multiple
tcp,
ruby,
robust
establishment,
is
a
set
of
extensions
to
regular
mptcp.
M
It
do
not
distinguish
between
the
old
mptcp
rse
6824
and
the
newer
one.
We
support
both
and
the
idea
is
to
design
a
robust
establishment
process
for
mptcp
sessions,
which
is
not
given
by
the
aforementioned
rfcs.
M
We
have
the
aerobic
sim
and
ether
both
are
firing
simultaneously,
the
handshake
process
on
all
available
parts,
and
last
but
not
least,
we
have
the
ruby
ips,
which
makes
some
smart
decisions
on
which
path
is
the
best
one
to
start
the
initial
handshake
process
next
slide.
Please.
M
So
what
has
been
done
so
far?
As
I
said
it
was
presented
some
eight
years
ago
it
was
90
f-106,
where
we
presented
it
the
first
time
for
107.
Then
we
prepared
a
hackathon
contribution.
Unfortunately,
that
has
not
happened.
Did
you
covet
19.?
M
Nevertheless,
everything
we
planned
for
the
hackathon,
then
we
presented
in
itf
108,
so
we
performed
all
the
things
we
prepared
for
the
hackathon
and
we
tried
to
do
their
offline
and
represented
the
results.
Then,
as
I
said
in
108,
and
these
results
were
very
promising
and
presented
that
there
is
a
benefit
of
applying
robert's
establishment
to
multiples
tcp
next
slide,
please.
M
M
I
think
we
made
some
clarifications
in
the
meantime
on
that.
Please
follow
the
links
in
this
presentation
to
see
what
we
updated
there
and
there
was
another
concern
from
the
tcpm
chairs
that
we
shall
include
the
multi-pass
tcp
experts
into
the
development
of
the
draft,
and
I
think
we
did
this.
Can
you
please
go
to
the
next
slide.
M
M
I
think
we
gave
some
answers
or
some
guidelines
to
this
in,
in
the
sense
that
we,
let
me
conclude
that
robert's
establishment
is
something
optional,
so
it
has
not
to
be
applied.
It
can
be
selected
by
by
sender
and
probably
also
by
receiver,
so
in
case
of
load
balancers.
M
I
fully
agree
that
would
be
an
issue
but
load
balancer
has
not
to
select
or
has
not
to
support,
robust
establishment,
it's
more,
something
which
I
see
either
to
be
end
to
end
applied
or
maybe
in
such
cases
where
we
have
multiple
tcp
proxies
as
it
is,
for
example,
in
3
gbp
80
triple
s
the
next
iteration
of
the
draft
we
plan
for
itf
110
and
again
I
want
to
put
the
question
here.
A
So,
thank
you
so
you
you
said
you
clarified
the
ipr
declaration,
at
least
when
I
looked
at
it.
There's
no
statement
about
the
license,
except.
P
F
L
A
Yeah,
okay,
so
but
so
it's
it's
my
understanding,
it's
something
which
is
so
you're
making
no
statement
about
if,
if
it's
possible
to
include
it
in
an
open
source,
implementation.
M
That
is
a
good
point.
To
be
honest,
I
I
think
huawei
is
currently
discussing
this
on
internally
to
make
their
code
open
source
so
far.
There
is
no
result
from
this
internal
discussion,
but
maybe
jiao
can
jump
in
if
there
are
some
updates,
so
she
I
think
she
is
part
here
of
this
session.
A
Depending
on
the
time,
I
would
say
get
that
to
the
mailing
list:
okay,
anyone
lars
be
quick.
I'm.
B
Very
possible
for
you
hi,
yes,
why?
So,
if
you
guys
open
source
your
code,
that's
great,
but
I
think
the
question
is
actually
whether
other
people
can
implement
the
specification
given
the
licensing
declaration
in
open
source
without
the
need
to
get
a
license
from
you.
I
think
that's
that's
the
question.
Yeah.
M
Okay,
so
is
that
the
only
hurdle
you
see
to
getting
adopted
or
is
that
there's
something
else.
B
M
Okay
yeah,
because
then
we
lose
probably
some
time
if
and-
and
I
would
like
to
do
things
in
parallel
if
possible.
So
if
you
know
there
are
other
hurdles
seen
from
your
side,
we
could
work
on
getting
them
around.
In
the
meantime,
when
we
clarify
the
ipr
stuff.
A
Okay,
thank
you
yeah,
thanks
for
the
presentation.
Next
is
accurate
data
scheduling
by
server
and.
A
Q
Q
Yeah
this
is,
we
have
a
server
meet
a
new
version
and
we
update
some
a
description
of
the
use
case,
update
the
definition
of
mp
navigation
option
and.
Q
From
the
mail
list
discussion,
data
scheduling
on
client
will
receive.
Mp.
Navigation
will
be
considered
later.
The
last
one
is
security
will
be
considered
because
we
want
to
analyze
the
possibility
whether
this
option
will
be
abused
by
our
attacker
and
the
underneath.
The
list
paragraph
leave
the
key
points.
If
I
start
right
in
the
tcp
email
list
discussion
some,
they
said
what
advantages
comparing
to
current
energy
priority
option
and
also
how
about
this
scheduling.
Q
Q
Q
We
with
interface
form
that
the
the
kpi
of
one
network
interface
is
not
better
than
before.
He
will
change
the
traffic
from
this
one
to
another,
one
that,
with
better
kpi
and
for
scenario,
two
is
that
a
new,
a
new
network
interface
be
added
during
an
mp
tcp
session
and
the
third
one
just
of
or
one
requirement
is
for
tests
that
want
to
change
some
traffic
to
the
new
one
for
for
test.
The
network,
interface
and
scenario.
Q
Three
is
just
for
operating
operation
requirement
that
for
for
the
service
owner,
he
wants
to
provide
his
keep
his
vip
user
with
with
subflow
that,
with
a
better
kpi,
better
performance.
The
last
one
is
that
that
the
mg's
mptcp
server
hope
to
adjust
the
traffic
based
on
the
changes
in
the
network.
Of
course,
this
these
four
scenarios,
what
we
found
for
the
requirements.
Q
Okay,
let's
go
to
next
page
this.
This
is
the
definition
for
these
options
that
can
send
a
send
from
server
to
client
to
inform
a
server
requirement
to
the
client.
Q
I
think
the
gsid
is
used
to
to
use
it
to
identify
the
target
network
in
the
face
that
the
server
wants
to
traffic
the
traffic
to
okay.
Let's
go
to
the
next
page:
let's
that's
the
plan
for
our
work.
We
think
that
scheduling
on
client
will
receive
mp.
Navigation
will
be
considered.
Q
We
will
consider
it
in
in
you
more
in
details
about
how
to
implement
it
and
and
the
important
is
the
security
problem
and
we
we
are
planning
to
arrange
a
demo
for
it
if
required.
In
fact,
we
have
a
f1
developer.
He
is
also
the
core
author
of
this
chapter.
He
told
me
that
if
this
draft
is
valuable
to
a
tcpm
group
and
the
demo
is
required,
he
can
put
some
some
some
time
on
this
on
this
work.
Q
A
A
A
Okay,
so
no
comments
here:
you
have
another
presentation
on
fault
management,
right.
Q
Q
Yeah,
okay:
this
is
go
ahead.
Okay,
this
is
also
our
new
idea
for
mptcp.
It's
also
from
from
our
operation
requirement
that
we
want
enhancement
in
current
fort
management.
We
have
submitted
the
chapter
to
jcpm
group,
okay,
next
page
yeah,.
Q
Q
When,
when
two
parts
are
encode
encounter
the
problems,
this
problem
will
cause
the
the
parts
cannot
be
used
for
data
transmission.
You
mean
that
the
problem
is
happened
suddenly,
so
we
can
use
other.
Q
We
have
used
other
parts
to
transfer
the
problem
of
the
of
this
rom
subflows
to
to
the
server
you
have
as
sure
by
the
green
errors,
and
the
server
can
collect
all
the
all
the
wrong
info
all
around
info
and
he
can
use
the
info
from
multiple
from
multiple
clients
to
determine
which
which
node
is
wrong
on
the
path
yeah.
This
is
the
key
key
idea
for
for
the
so.
Okay,
let's
go
to
next
page.
Q
Oh,
and
this
is
the
flow
for
the
for
the
re
firm
for
the
solution.
During
mp
gdp
session.
There
are
multiple
subflows
and
the
client
determined
that
one
ongoing
flow
is
40,
and
this
40
is
is
suddenly
so
what
how
he
can
determine
the
this
problem?
Maybe
what
a
client
can
have
a
tour.
He
can
listen
to
the
part
he
can
detect
the
the
problems
and
another
way
he
can
receive.
The
report
from
the
third
part
tour
on
the
network
and
the
network.
Q
Why
another
subflow
that
running
will
and
the
server
can
receive
these
options
and
next
page
we
use.
We
think
we
think
we
we
define
a
new
option.
That's
called
force
announcement
option
and
this
option
have
the
main
changes
to
current.
To
to
this
main
changes
to
this
option
is
that
we
define,
of
course,
and
the
destination
destination
address
id
and
the
source
address
id
the
course.
Q
We
know
that
there
is
a
reason
have
defined
in
a
current
mpdp
protocol
if
it
can
reduce,
we
can
add
some
new
values
to
this
grid
field
and
the
definition
address
id
and
the
source
suggests
that
is
used
to
identify
the
4g
subflows
to
the
server,
and
that's
all
our
our
suggestion
for
the
option
next
page-
and
I
think
oh,
that's
all
our
suggestion
and
adding
comments
are
welcome.
Yeah
yeah,
are
there
comments.
C
Q
I
think
this
info
is
used
before
the
softcam
uses,
an
input
to
determine
which,
depending
on
the
path
which
notice
is
the
forehead
as
yeah
immediately
maybe
from
from
one
plant
from
from
one
plant,
is,
cannot
determine
the
the
location
but
from
multiple
from
multiple
clients.
If
we
all
report
that
to
the
sub
the
the
subflow
over
the
all
one
machines
around,
I
think
the
server
can
use
to
determine
the
pushing.
Q
Now.
This
is
the
operating
requirement.
C
Yeah
to
some
extent
I
understand,
but
maybe
you
can
clarify
in
your
draft
in
the
next
version.
A
Okay,
then
thank
you
for
the
presentation,
and
next
up
this
is
matt.
We
can
see
him
so
go
ahead.
R
Okay,
it's
good
to
be
speaking
to
the
ietf.
Again,
it's
been
a
couple
years,
I'm
here
today
to
ask
to
bring
proportional
weight
reduction
in
as
a
work
item
for
tcpm
to
bring
it
to
proposed
standard
next.
R
Slide
just
to
recap:
prr
the
idea,
the
primary
mode.
R
By
all
estimations
a
vast
majority
of
the
web
traffic
is
is
prr.
Somebody
thought
somebody
told
me
that
they
thought
50.
I
think
it's
actually
considerably
more
than
that,
given
the
the
high
volume
of
this
operating
system
is
listed
there,
there
have
been
no
changes
to
the
algorithms
that
were
in
the
original
document.
R
The
congestion
control
picked
some
reasonable
rate,
like
five
or
seven
megabits,
and
the
network
drops
every
nine
out
of
ten
or
seven
out
of
ten
or
four
out
of
five
packets
and
the
congestion
control
had
no
warning
what
the
new
rate
was
and
both
of
the
algorithms
in
the
current
rfc
don't
handle
it
very
well.
In
2015
there
was
another
heuristic
discovered
that
lets
you
dynamically
switch
between
the
two
algorithms
and
the
consequence
behaves
much
better
than
either
algorithm
by
itself.
R
R
Next
slide
we'd
like
to
introduce
it
as
a
work
item.
I
don't
think
it'll
take
very
long.
I'm
hoping
two
ietfs,
but
sometimes
these
things
have
a
long
tail.
R
R
Rereading
it
later
it's
much
much
too
verbose
and
and
it's
annoying
to
read-
and
I
would
like
to
make
it
if
I'd
had
more
time,
I
would
have
made
it
shorter,
as
they
say,
and
focus
on
what
implementers
need
to
know
and
a
lot
of
the
prior
results
and
the
prior
explanations
are
available
in
the
existing
document
and
can
be
included
by
reference
by
non-normative
reference.
So
because
they're,
it's
non-standard.
E
A
A
Any
comments
supporting
this
work
or
richard.
P
I
like
this
work
I
like
to
make
this
the
proposed
standard
looking
into
the
heuristics,
and
I
wanted
to
update
your
list.
Freebsd
is
now
also
doing
a
pr,
but
not
by
default.
You
have
to
explicitly
enable
it.
It's
been
included
a
couple
weeks
ago,
cool.
Thank
you.
N
Yes,
you
said
that
it
is
only
active
during
fast
recovery.
R
N
Right,
I
I
think
it
might
be
worth
addressing
that
in
the
new
version.
R
O
Photo
of
this
work
standard,
I
have
one
question
so
the
2015
problem
observed
with
policers
is
there
recent
data
to
suggest
that
that
is
still
a
problem.
R
Yes,
I
know
that
people
are
very
aware
of
now
that
we've
seen
policers
are
very
aware
of
the
consequences
of
policers
in
the
network.
It
would
be
nice
to
eradicate
them,
but
there's
some
older
hardware
that
that's
sort
of
the
default
way
of
doing
traffic
management
and
as
it
moves
out
especially
into
the
southern
hemisphere.
K
Hear
you,
okay,
wow,
okay,
this
is
magic,
we'll
finally
get
this
right
someday.
Thank
you
for
bringing
this
up
here
and
I
I
I'd
be
supportive
of
moving
this
forward.
Pr
has
been
used
quite
extensively.
One
one
thing
to
note
is
6937un
says
that
prr
is
a
form
of
soft
pacing.
K
I
want
to
ask
if,
if
anyone
has
documented
or
has
looked
into
the
the
interaction
between
prr
and
pacing,
I
think
that
would
be
worth
some
text
going
forward,
given
that
a
lot
of
implementations
and
a
lot
of
deployments
are
using
pacing
by
default
these
days,
it
would
be
important
to
consider
what
the
both
the
value
of
prr
in
the
face
of
pacing
and
also
the
interaction
between
pacing
and
prr
would
be.
R
That's
that's
a
good
point.
Thinking
about
it,
there's
a
there's,
a
sort
of
a
complicated
piece
which
has
to
do
with.
How
do
you
manage
the
time
stamps
the
schedule
times
on
the
packets
for
the
pacing
and
that's
the
kind
of
thing
that
the
ietf
hasn't
specified
very
well.
It
doesn't
normally
specify
as
an
implementation
detail,
but
it
matters
a
lot
for
the
answer
of
your
to
your
question.
K
I
think
it
matters
a
lot
in
terms
of
how
people
think
about
deploying
both
pacing
and
pr.
R
Yes,
yes,
and
and
and
for
instance,
when
we
run
when,
when
we
run.
R
K
K
R
S
Let
me
explain
a
little
bit
about
pacing
and
pr
so
single
pr,
as
when
you
get
the
x
pr
will
try
to
release
a
certain
amount
of
traffic
sort
of
at
the
some
ratio
of
the
amount
that's
been
delivered
by
what
the
act
would
indicate.
S
But
in
the
case,
when
you
actually
get
some
kind
of
ad
compression
during
fast
recovery
or
accident,
due
to
middle
boxes,
you
could
have
actually
released
say
10,
packets,
15,
packets,
into
the
network,
because
and
then
this
kind
of
burst
will
have
to
be
handled
by
the
say,
linux
pacing,
which
will
break
up
this
burst,
based
on
the
current
pacing
rate
and
the
pacing
rate
at
least,
say
in
the
cubic
model,
is
still
based
on
c1,
divided
by
the
rtt.
S
So
that's
sort
of
the
relationship
between
prr
and
and
pacing.
So
pr
is
still
at
clock,
but
in
case
of
when
the
act
is
being
seen
or
compressed,
you
still
need
the
sort
of
a
more
fine
granularity
pacing
to
break
up
the
burst.
So
that's
the
way
to
think
about
pr
and
pacing.
K
Oh,
thank
you.
I
I
I
completely
agree
with
that.
Acting
is,
is
the
is
the
one
I
was
thinking
about,
which
actually
was,
I
think
for
me.
The
question
was
given
that
I
will
need
pacing
to
deal
with
all
of
those
conditions
anyways.
What
does
pr
offer
to
me
as
as,
if
I've
already
deployed
pacing?
What
does
it
offer?
In
addition,
that
was
my
question
youtube.
A
Okay,
so
I
heard
support
for
work
or
tcp
I'm
working
on
this,
so
we
need
to
get
this
on
the
mailing
list
and
discuss
it
between
the
chairs.
You
can
think
about
a
potential
milestone,
a
realistic
milestone.
C
A
T
Yes,
so
this
is
tcpls.
This
is
a
joint
work
with
florenta
roche
in
emory
asuka
from
uc
luva
next
slide.
T
So
if
we
look
at
what's
happening
with
tcp
and
tls
is
that
both
protocols
are
often
used
together,
especially
in
the
one
and
tls
provides
security
and
tcp
provides
connection,
abstraction,
reliability,
congestion
control
and
it's
still
the
most
popular
transport
protocol.
Today,
and
if
we
look
at
what's
happening
on
the
wide
area
networks,
it's
very
likely
that
tcp
and
tls
could
always
be
used
together
next
slide.
T
So
let's
go
back
to
tcp
and
in
tcp
when
tcp
was
designed,
we
have.
We
have
a
very
simple
separation
between
the
control
channel
and
the
data
channel
in
tcp,
so
the
control
channel
is
part
of
the
tcp
adder,
with
the
tcp
option,
which
has
a
restricted
length
and
the
data
is
part
of
the
payload
of
the
tcp
segment
next
slide.
T
T
T
So
what
we
could
do
is
that
we
could
integrate
tls
and
tcp
closely
together.
So
we
could
use
tls
record
to
carry
tcp
control
information
and,
in
fact,
what's
possible
is
that
we
could
have
two
control
channels
for
tcp,
one,
which
is
the
regular
tcp
options
and
the
second
one
which
is
using
encrypted
tls
records
next
slide.
T
So
we
have
two
control
channels,
one
in
the
tcp
header
and
another
one
on
the
tls
record,
which
gives
us
lots
of
extensibility
and
unlimited
space
to
exchange
tcp
options
in
the
tls
reports
next
slide.
T
So,
let's
use
let's
look
at
some
things
that
we
could
do
by
closely
integrating
tcp
and
tls,
and
I
have
a
few
examples,
but
you
probably
have
other
ideas.
So
first
example
is
securing
multi-pass
tcp.
When
we
designed
multi-party
cpa,
we
decided
to
put
the
token
in
the
steel
synap,
which
is
the
key
which
is
exchanging
clear
and
then
we
had
issues
with
authenticating
address
and
making
address
reliable.
T
Another
example
is
tfo:
in
tfo
we
have
a
tfo
option
which
uses
small
size
cookies
to
exchange
and
to
validate
the
client
using
tcpls.
We
could
use
tls0,
ltt
and
then
code
information
in
the
clientele
and
in
the
server
halo,
which
would
allow
us
to
use
cookies
that
are
much
larger
than
the
current
tfo
option.
T
Obviously,
using
longer
information
in
the
payload
of
the
scene
and
of
the
simplestack
could
create
some
issues
with
middle
boxes.
But
if
you
look
at
the
measurements
that
christoph
from
apple
mentioned
a
few
years
ago,
he
showed
that
it
doesn't
seem
that
tfo
is
blocked
by
the
presence
of
long
payload
in
the
scene
or
the
synagogue.
But
it's
more
the
tcp
options
that
creates
problems
with
middle
boxes
next
slide.
T
Another
example
is
that
with
tcpls
we
would
have
more
space
for
tcp
options,
since
tcp
options
could
be
part
of
a
new
type
of
tls
record,
and
we
have
already
implemented
that
in
the
tcpls
prototype.
So
you
could
exchange
the
tcp
option
during
the
handshake.
So,
for
example,
the
server
hello
can
provide
an
additional
option
in
the
synack.
T
With
the
encrypted
extension,
we
can
define
a
tls
record
to
carry
tcp
option
and
we
have
done
that
for
the
user
timeout
option
which
is
not
supported
by
linux,
but
we
can
put
this
user
timeout
option
in
tcpls
and
then,
when
the
client
or
the
server
receives
the
tls
record
that
contains
the
the
user
timeout
option,
then
it
can
do
the
set
socket
option.
It's
also
possible
to
do
a
late
negotiation
of
the
tcp
extensions
using
tcpls
next
slide.
T
We
could
have
tls
records
that
are
used
to
encode
tcp
keep
alive
that
allow
that
allow
to
check
whether
tcp
connection
is
still
alive
by
just
sending
dummy
data
inside
tls
records,
and
you
have
a
kind
of
new
ping
pong
tcpls
record,
which
is
not
part
of
the
data.
Next
slide,
you
can
do
secure
connection
release
by
having
a
new
type
of
tls
record
that
marks
the
end
of
the
tcpls
station
and
which
cannot
be
caused
by
middle
boxes,
which
cannot
be
sent
by
middle
boxes.
T
Next
slide,
you
can
do
api
balls
by
having
the
server
provide
its
alternate,
ipv4
or
ipv6
address
in
the
server
hello
encrypted
extension.
So
this
information
is
encrypted
and
authenticated,
and
so
the
client
learns
the
internet
address
of
the
server
and
it
can
try
to
create
the
tcp
connection
over
the
ipv4
if
it
started
over
ipv6
next
slide.
T
So
in
the
example
you
see
that
the
client
and
the
server
are
connected
to
a
30
megabits
per
second
link
and
the
client
receives
ipv4
and
ipv6
addresses
from
the
server
and
it
starts
over
ipv4
and
after
some
time
it
decides
to
switch
to
ipv6,
and
the
connection
continues
without
any
problem
for
the
application.
Next
slide.
T
So,
to
conclude,
this
was
a
heads
up
to
show
you
that
tcp
and
tls
should
not
always
be
considered
as
separate
and
independent
protocols,
and
there
are
many
benefits
that
can
be
obtained
by
coupling
these
two
protocols
together
and
it's
possible
to
efficiently
combine
them
together.
There
are
more
details
in
the
paper
and
there
is
a
running
code
which
is
based
on
picot
tls,
and
if
you
have
ideas
on
things
that
you
would
like
to
do
with
tcpls,
please
contact
us
and
we
would
be
happy
to
discuss
with
you.
K
Thanks
olivier
I'm
assuming
I
can
be
heard,
so
how
does
this
work
with?
With
proxies
that
terminate
the
tcp
connection,
but
not
the
tl
connection.
C
K
But
there's
a
lot
of
metal
boxes
do
this
as
well,
where
they
terminate
the
tcp
connection,
but
they'll
just
become
they'll
forward
the
bytes
that
are
in
the
tcp
connection,
along
to
the
next
top.
T
But
then
the
tcp
options
that
are
sent
in
the
tcp
header
won't
work,
but
the
tcp
options
that
you
would
send
in
a
tls
would
work,
and
it's
also
with
this
solution.
It's
also
possible
to
detect
this
kind
of
proxies,
because
you
could
take
the
tcp
segment
that
you
send.
You
put
it
in
a
tls
record
and
you
encrypt
it,
and
so
on
the
server
side.
You
check
that
the
tcp
segment
that
was
sent
by
the
client
is
the
same
that
was
received
by
the
server.
So
you
could
have
the
sequence
number.
K
The
presence
of
a
proxy
right
now
I
get
that
and
and
and
what
I'm
saying
is-
is
it's
not
to
detect
the
presence
of
a
proxy
but
the
negotiation.
So
if
I
send
the
options
that
I
am
trying
to
negotiate
with
my
tcp
peer
and
I
send
them
via
tls,
it
goes
to
let's
say
it
goes
to
the
next.
So
if
I,
if
say,
it's,
two
segmented
connections
like
this
right
and
I'm
trying
to
negotiate
with
my
peer,
but
I
end
up
negotiating
this
with
that
end
point
now.
K
This
end
things
that
it's
peaking
those
options
with.
I
don't
know
how
to
explain
this
without
a
picture,
but
I'm
negotiating
tcp
options
with
the
peer
with
whom
I'm
not
speaking,
tcp.
Does
that
make
sense.
T
K
Right,
I'm
saying
that
you
would
have
to
otherwise.
T
Yeah,
basically
so
you
can
check
that
so
you
could.
You
could
exchange.
For
example,
the
tcp
sequence
numbers
in
a
tls
record
to
check
that
you
have
the
same
values
of
the
tcp
sequence,
numbers
for
the
scene
and
the
synap
for
example,
and
then,
based
on
that
you
can
detect
whether
you
have
a
proxy
on
the
path
or
you
can
do
more
advanced
heuristics
to
detect
that
there
is
a
proxy
on
the
past.
A
Right
just
a
note,
we
are
over
time
and
I
think
we
are
kicked
out
in
a
minute.
So
yoshi
you
have
whatever
time
is
left.
C
Okay,
so
thanks
for
presenting
a
very
interesting
idea,
I,
like
you,
know,
reading
your
paper
and
then
so.
One
naive
question
I
have
is
this:
technology
contains
a
lot
of
stuff.
It
has
similar
type
grip.
It
has
similar
feature
for
mpdcp.
T
Yes,
so
first,
our
objective
is
to
understand
what
are
the
real
use
case,
where
coupling
the
two
would
provide
most
of
the
benefit
and
then
to
to
develop
running
code
and
to
extend
the
running
code
so
that
we
can
do
experiments.
T
And
once
we
have
running
code,
and
we
know
that
the
solution
works,
then
we
can
come
to
the
itf
and
bring
the
ids
to
the
itf.
But
I
think
what's
important.
Now
is
that
if
you
are,
if
within
tcpm,
you
are
blocked
by
the
difficulty
of
exchanging
tcp
options
or
exchanging
tcp
options,
that
would
need
to
be
reliable.
T
So
we
will
need
to
prioritize
and
we
need
to
see
what,
where
there
is
most
of
the
benefit
by
coupling
the
two
together
and
there
are
parts
where
there
is
no
benefit
so,
for
example,
doing
sac
it's
not
possible
to
do
sac
with
tcpls,
but
for
mptcp
you
can
do
ad
address
and
you
can
simplify
the
exchange
of
the
keys.
So
there
is
a
benefit
for
mptcp.
T
There
are
other
benefits
that
you
could
do
so
we
are
discussing
congestion
control
and
things
like
that.
You
might
know
that
congestion
control
now
it
can
be
implemented
using
ebpf
on
linux.
So
it's
possible
with
this
approach
to
exchange
the
ebpf
congestion
control
scheme
over
a
tcpls
connection,
so
the
server
could
send
a
different
congestion
control
scheme
to
the
client
to
adapt
the
client
to
the
current
networking
conditions,
because
you
can
encode
the
ebpf
code
that
contains
the
congestion
controller
inside
tls
records
that
are
sent
by
the
server.
A
Thank
you.
Thank
you
very
much
for
this
interesting
presentation.
I
think
this
concludes
this
tcpm
session.
Thank
you
for
participating
and
joining
and
see
you
at
the
next
idf
bye.