►
From YouTube: IETF105-MPTCP-20190722-1550
Description
MPTCP meeting session at IETF105
2019/07/22 1550
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
C
C
Thank
you
very
much
to
Michael
for
taking
the
notes.
I
guess
you'll
be
doing
them
in
the
ether
pad
yeah.
So
if,
if
anybody
wants
to
help
out
because
you
can
collaborate
and
that
that
would
be
very
good,
is
somebody
able
to
monitor
the
jabber
room?
Please
I
bet
that
people
still
use
jabber
/
anybody
able
to
monitor
it.
I
guess
we'll
run
yo,
she'll,
try
and
leap
and
honor.
When
you
come
to
the
mic.
C
Please
remember
to
say
your
name
perfectly
slowly
so
that
the
note-taker
can
know
who
you
are,
and
everybody
else
is
here
can
hear
who
you
are
and
the
usual
remind
us
about
the
draft
names.
The
blue
sheet
is
going
round.
I
think
we're
just
gonna
do
one
day:
vocals
one
will
do,
though
I
should
say
I'm,
I'm,
Phillip,
nerdly
and
my
co-chair
is
Yoshi.
C
Here's
our
agenda
for
today,
first
of
all,
just
to
let
you
know
the
status
of
them
of
the
of
our
this
document.
Sic
the
RFC
682
for
this.
The
protocol,
so
that
has
now
completed,
is
G.
Review
and
Nia
has
pushed
our
ad
is
pushed
the
button.
So
it's
now
gone
Ayanna
so
that
that's
been
a
a
lot
of
work
are
a
number
of
people
over
quite
a
period
of
time.
So
thank
you
and
congratulations
to
everybody.
C
C
C
So,
as
always,
we
have
an
open
mic
or
news
about
implementations,
what's
happening
on
that
with
the
Linux
implementation
or
with
with
any
of
the
other
ones
that
they're
all
about.
So
this
is
kind
of
the
opportunity
for
anybody
who
wants
to
to
say
anything
about
implementation.
What's
happening,
what
any
news
there
is.
Sometimes
we
have
several
pieces
of
news,
and
sometimes
we
we
don't
so
just
pause
to
see.
If
anybody
wants
anything
on
us
today,.
C
E
E
E
E
It
separates
first,
the
functionality
of
guaranteeing
robustness
and
which
is
part
of
the
simple,
robust,
robust
establishment
and
second,
the
latency
throughput
improvement.
If
he
can
really
use
all
power
from
the
very
beginning
and
we
can
merge
the
flows
that
I
will
explain
in
in
a
minute
yeah.
Second.
E
The
audience
mentioned
that
the
key,
a
which
was
part
of
the
motive
power
capital
option,
is
not
available
anymore
in
multi-party
city
version,
one
from
the
very
beginning.
It
is
first
available
in
the
last
part
of
the
three-way
handshake.
So
that
is
something
I
had
to
consider.
When
I
designed
the
Roby
xed,
then
there
was
a
hint
that
robust
establishment
should
not
add
extra
Orion,
so
ordinary
computing
overhead.
That
is
especially
important.
E
A
E
E
So
again
we
headed
on
all
park
attend
the
multi-part
capable
the
first
one,
which
succeeds
from
a
client
view,
is
selected
at
the
initial
part
and
all
the
other
part
are
reset
at
them,
and
then
the
traditional
multipath
join
the
procedure
can
be
applied
yeah
the
pros
are,
it
is
simple:
it
is
the
sender
side
only
implementation.
It
is
full
compliant
to
multiple
TCP
version,
0
and
version
1.
E
It
guarantees
robust
session
setup,
at
least
for
multiple
TCP
version
0
and
the
setup
latency
profits
from
the
fastest
pass
in
the
game.
The
cons
are,
we
are
wasting
resources
when
resetting
flows,
that
is
obvious
and
what
we
do
not
solve,
or
that
we
have
some
dependency
on
that.
The
multiple
TCP
version
1
is
depending
on
a
successful
egg
in
the
three-way
handshake.
That
means
the
last
acknowledgment
has
to
be
successful
transmitted
and
we
are
depending
on
that
as
well.
E
E
E
A
E
E
E
Similar
to
the
simple,
robust
establishment,
we
profit
from
the
latency
of
the
fastest
path.
Yes,
and
what
is
different
to
this
to
the
symbol,
robust
establishment
is
that
we
have
very
very
early,
all
subfloors
available,
which
means
we
can
gain
a
higher
throughput.
Wonder
from
the
very
beginning
of
a
session
set
up
the
con
is
it
requires
a
new
multiple
TCP
option
called
multipath
join
cap.
All
this
looks
like
can
we
see
in
the
next
slide,
so
on
the
Left
I
proposed
the
option
format.
E
E
E
The
key
be
passed
hash,
which
is
part
of
the
H
Mac,
is
used
to
make
the
relationship
between
potential
initial
flows
and
not
yet
fully
established
initial
flows
that
what
I
meant
or
that
is
that
is
related
to
version
1
of
TCP
meant,
for
example,
the
the
final
leg
of
the
initial
flow
hasn't
arrived.
Yet
then
we
can
make
sure
that
we,
the
key,
be
fast
hash
of
a
potential
initial
flow.
You
can
establish
such
a
flow
and
we
can
merge
them
and
the
h-net
itself.
E
So
all
the
other
information
which
is
anxiety
th-,
is
then
used
for
authentication
for
identification
purposes,
similar
to
multi,
pass
capital
and
multipaths
on,
so
that
attackers
cannot
modify
the
option
or
can
take
over
paths
or
sessions
of
multi
pass
tsuki.
The
detailed
explanation
of
this
can
be
found
found
on
the
mailing
list.
There
was
already
some
discussion
on
that
how
the
the
option
has
to
look
like
and
which
information
need
to
be
inside,
and
it's
also
passed
the
part
of
the
trough
document.
E
E
Unfortunately,
it
is
more
or
less
outdated,
so
it's
more
than
two
years
old
and
all
the
changes
since
ITF
99,
the
definition
of
the
simple,
robust
establishment
and
extend
the
purpose
establishment
is
not
part
of
that
and
I
recommend
an
implementation
from
from
scratch.
So
if
someone
is
in
the
room
may
be
from
a
university
who
is
interested
in
that
topic,
I
think
this
could
be
a
good
work
for
for
a
student,
maybe
for
Jesus,
to
implement
something
like
this
and
to
investigate
it.
E
Another
point
is
which,
which
was
already
brought
up
on
the
mailing
list,
is
that
maybe
the
signaling,
especially
for
the
extended
progress
establishment,
has
to
be
discussed.
Maybe
it
requires
a
4
Way,
handshake
7
to
the
multipath
charm
and
also
which
is
currently
not
considered
in
the
draft
just
as
a
section,
but
without
any
content
how
many
negotiation
or
the
extended
prophecy
statement
can
be
made
and
how
potential
fallback
mechanism
has
to
look
like.
E
So
for
sure,
that
is
that
there
are
things
which
have
to
be
in
discussed
and
then
in
general,
we
have
to
improve
the
first
draft
version.
We
have
to
integrate
such
things
like
the
signalling,
maybe
the
four,
by
handshake
with
negotiation
and
fallback
mechanisms
and
integrate
this
in
the
next
version
of
the
trough
document
yeah.
The
goal
is
that
it
becomes
working
proof
adopted
at
some
time
and
also
I
had
some
discussion
with
potential
of
it
with
interested
persons
who
maybe.
E
E
A
F
One
or
the
other,
your
your
main
target
or
I
also
noticed
the
the
simple
one
is
quite
similar
in
functionality
as
to
what
is
developed
in
the
in
the
taps:
crew
with
the
transport
services,
where
you
have
racing
between
protocols,
but
would
be
the
same
behavior.
But
it
happens.
One
level
up
as
opposed
to
inside
and
to
TCP
I
think
the
effect
would
be
very
similar.
Nick.
E
Yeah,
that
is
a
good
point,
also
something
which
was
raised
from
olivier
in
the
manning
list
that
there
are
already
similar
phonology
is
also
the
happy
eyeball
and
I
think
at
least
V.
We
should
consider
this
in
the
trough
that
there
that
they
are
similar
functional
he
is
available,
but
maybe
it
is
good
to
have
something
at
least
described
directly
in
the
multiple
TCP
contacts
and
I'm
not
familiar
with
the
taps
functionality
so
I
have
to
convert
it.
It
taps.
F
C
E
I'm,
open
and
flexible,
so
it
depends
maybe
be
sure
to
have
some
discussion
and
remaining
this
considering
this.
No,
that
is
just
a
proposal
now,
in
the
first
draft
version,
it's
now
basic
to
to
have
a
discussion,
I,
I,
guess,
and
if
there
are
good
reasons
to
remove
the
simple
from
the
draft,
why?
Why
not
for
sure
the
more
most
sophisticated
approach
would
be
extended,
which
also
promised
the
the
best
effect
and
the
highest
impact
on
a
certain
establishment?
So
that's
why
I
personally
prefer
the
and
robust
establishment,
but
just
to
comprise
any
solution.
D
E
Yes
or
no,
as
I
mentioned,
we,
we
have
some
prototype
available,
an
outdated
one,
which
we
developed
to
produce
some
meaningful
results,
in
particular
for
the
paper
we
published,
and
this
one
proved
that
robust
establishment
is.
This
is
very
beneficial
beneficial,
but
pretty
convinced
that
we
should
not
share
this
outdated
version
because,
as
I
said,
it
is
very
buggy
and
I'm
not
sure
if
others
can
really
use
it
that
why
I
propose
to
develop
it
from
scratch
and
directly
integrate
the
the
functionalities
of
the
current
current
draft
version.
E
What
I
proposed
at
ITF
99
was
far
away
from
from
these
two
modes,
the
simple
and
the
extended
what
our
proposed
No.
So
that's
I!
That's
why
I
would
be
very
happy
if,
yes,
if
someone
is
in
the
room
who
might
imagine
to
happen,
something
like
this
currently
I,
don't
see
that
we
found
out
to
telecom,
have
really
the
resources
to
develop
something
from
scratch
again.
C
C
H
H
H
H
So
there
are
two
years
grades
to
use
the
options.
The
first
is
the
host
one
to
keep
the
seasonal
life
through
the
transient
failure.
So
to
do
that,
it
could
request
this
fearful
and
enough
patio
for
this
speed.
This
strength
does
not
work
because
not
somehow
might
just
terminate
the
connection,
but
for
mpg
speed
not
is
not
a
problem.
H
H
The
option
is
indicatives,
which
means
that
local
policy
could
have
right
these
options
and
is
unreliable,
but
we
can
improve
the
delivery,
for
example,
by
just
saying
it
multiple
times
per
second
or
ITT
or
through
the
lifetime.
Another
way
is
to
attach
it
to
us,
TCP
sequence
number
and
let
disappear
transmission
and
do
it
next
slide.
H
So
the
next
option
is
to
really
meet
on
a
stop
flow.
It's
like
the
motivation
is
for
the
mobile
user.
They
usually
have
the
limited
cellular
data
Kota,
but
they
want
to
use
the
cellular
network,
but
they
need
to
limit
the
cost
in
terms
of
money
or
reserve.
The
doctor
quota,
if
that
is
fixed,
but
the
kyon
basically
cannot
control
the
downstream
data.
So
the
solution
is
that
client
requests
the
server
a
mustard
sending
rate
on
a
stuff
flow
next
slide.
H
So,
as
we
think
of
a
similar
option
format,
but
for
the
rate,
it
should
be
longer
to
be
able
to
opt
to
express
a
longer
range,
a
bigger
range,
so
so
that
we
try
to
use
the
floating
point
format
of
62
bit.
So
it
means
that
basically,
it
could
range
from
0
to
here
you
can
see
the
value
is
very
big
and
this
option
also
indicative
and
unreliable
next
slide.
H
H
H
So
what
about
requesting
a
rate
limited
zero
because
it
could
allow
the
pr2
this
several
several
temporarily.
For
example,
if
we,
the
client,
have
to
connection
Wi-Fi
and
cellular,
but
then
he
move
between
the
route,
Wi-Fi
and
bad
Wi-Fi
or
to
go
out
home,
so
it
can
smoothly
disable
the
cellular
path
based
on
the
Wi-Fi
condition
next
slide.
H
So
there
are
others
open
questions
like
how
to
improve
the
reality.
So
it's
similar
to
the
timer
option
that
we
can
send
several
times
or
we
can
let
the
server
to
respond
to
the
request,
maybe
with
a
flat
bit
then
what
about
the
duration
of
bread
limit
policy?
Should
we
let
it
until
the
end
of
the
connections
or
allow
the
client
to
specify
because
yeah,
if
we
we
allowed
that
it
will
occupy
more
TCP
option
space
or
we
can
compile
it?
H
Other
use
case,
like
we
said
on
it's
a
flow
to
be
in
backup
most
as
long
as
the
network
quality
is
that
is
fries.
We
can
have
specified
the
traffic
ratio,
the
most
up
flows
or
we
can
cut
the
amount
data
is
that
of
the
read,
but
he
personally
I
think
that
there
are
different
use
case,
and
maybe
that
is
too
complex
if
we
mix
them
together.
H
D
Know
this
is
your
secret
program
about
the
rate
control
option.
So
in
this
proposal
the
center
side
capped
the
window
size.
Yes,
how
it
is
actuate
or
not
activate
all
right.
You
know
if
we,
the
client-side
controlled
advertisement
window
size
to
some
extent
we
can
do
the
semester
and
then,
but
why
you
are
trying
to
control
at
the
server
side,
not
cryin
side,
because
it's
not
very
accurate.
D
D
H
H
D
H
D
H
C
D
I
I
In
this
document
we
stuff
and
Amelia,
what
we
have
tried
to
do
is
to
make
an
analysis
of
the
potential
privacy
threats
that
multiple
TCP
protocol
has,
and
so
the
scope
here
is
very
similar
to
what
we
have
done.
Regarding
security.
That
is
basically
try
to
understand
compared
to
regular
TCP,
whether
the
use
of
the
multiple
TCP
protocol
introduces
additional
privacy
threats
right,
it's
out
of
the
scope
of
the
document
to
try
to
perform
a
general
analysis
of
privacy
threats
that
affect
the
same
electricity
and
multi-party
city
right.
I
The
goal
here
is
to
understand:
if,
because
we're
using
multiple
TCP
we're
exposing
additional
information,
that
would
not
be
visible
if
we
only
use
this
it
okay.
So
basically,
the
goal
here
is
to
eventually
restore
the
same
level
of
privacy
that
you
have
when
you
use
TCP.
When
you
start
using
multipath
visit.
Okay,
so
I
mean
you
can
easily
see
that
that
multiple
TCP
may
have
some
potential
privacy
threats
right.
Essentially,
what
you're
doing
is
you're
exposing
multiple
IP
addresses,
but
whoever
is
able
to
observe
that
particular
signaling
will
be
able
to
bind
together
right.
I
So
essentially,
the
you
can
conceive
to
potential
privacy
threats
here.
One
is
regarding
movement
tracking
right
so
because
I
Mabel
to
observe
the
same
device
is
changing.
Ips
I
can
actually
track
where
this
device
is
going
right
and
eventually,
if
one
part
in
the
device
is
exposing
multiple
of
IPRs.
At
the
same
time,
maybe
I
can
actually
have
a
more
accurate
position
of
that
particular
device
because
I
don't
know.
Maybe
the
Wi-Fi
has
a
shorter
range,
shorter
scope,
some
more
precise
location
than
a
cellular
I
mean
an
IP
really
is
associated
to
a
cellular.
I
So
if
we
go
into
the
detail,
mechanics
of
the
of
the
attacks,
there
are
two
types
of
attacks:
one.
When
you
use
and
pick
a
problem
between
another
one
will
use
analysis.
These
are
the
two,
the
the
protocol
messages
that
are
susceptible
of
this
type
of
attacks,
all
right.
So,
if
you're
using
MP
cable
NP
join.
I
Basically,
if
you
observe
the
token
that
has
been
a
change
in
the
MP
cable
and
you
observe
the
same
talk
in
different
MP
joint
messages,
you
can
actually
track
down
that
it's
the
same
device
that
has
and
bind
all
these
houses
together
all
right.
In
the
case
of
the
other
address,
you
can
actually
bind
that
addresses
containing
the
other
s
message
to
the
between
them.
If
you
have
multiple
of
them
and
to
the
others
that
is
being
used
for
that
particular
flow,
where
there
are
others
messages
being
exchanged.
J
I
If
you
want
to
solve
the
other,
there
is
vulnerability.
The
only
thing
that
you
need
to
do
is
to
encrypt
their
addresses
containing
the
multi
party
CP
message
with
multiple
TCP
connection:
key
right
with
that,
essentially
anyone
who
can
observe
the
first
message
can
actually
decrypt
this,
but
you're,
essentially
imposing
that
the
vulnerability
is
only
if
the
attacker
is
on
the
initial
path
right,
which
is
basically
the
spirit
of
the
whole
multi-party
CP
security.
So
probably
that
will
restore
to
a
similar
level
to
all
the
rest
of
security
features
of
multi
participant.
I
If
you
want
to
prevent
the
multi
path,
keep
the
NP
cable
and
is
joined
by
that.
Well,
essentially,
what
you
need
to
do
is
to
actually
change
the
token
for
every
MP
joint
right
and
you
can
actually
change
it
in
a
predictable
way
right.
So,
if
you
do
write
on
a
hash
of
the
address
and
and
the
key
for
instance,
that
will
actually
allow
you
to
to
not
expose
always
the
same
token
and
hence
restore
the
privacy
features.
As
I
said,
I
mean
this.
These
are
fairly
straightforward.
I
So
prior
some
guidelines,
when
you
should
be
doing
that,
I
mean
if
you
have
ten
addresses
it's
not
worthwhile,
exposing
all
of
them
at
the
same
time
and
only
use
the
expose,
the
one
that
you
are
planning
to
use
or
stuff,
like
that.
Some
guidelines
like
that
that
will
create
some
form
of
awareness
regarding
these
these
issues
and
that's
pretty
much
it
so
I
guess.
The
question
is
whether
the
working
group
is
interested
in
doing
something
in
this
pace
or
or
not,
and
I
guess.
D
You
know
Yoshi
from
flora,
yeah
I,
think
I,
understand
the
motivation
and
then
so
one
question
I
have
is
please
say
the
attacker
monitors
March
for
point
and
then
sorry,
sorry,
ok,
they
attack
our
monitors,
traffic's
at
multiple
point
and
then,
instead
of
a
data
well
MP
join.
They
check,
monitor
the
DSS
option,
data
sync
as
number
and
then
if
they
observed
this
beta
seekest
number
and
they
no
different.
No
connection
has
just
almost
a
similar
data's
incorrect
number
and
then
the
attacker
might
be
invite
this
connection.
Dyskinesia
belong
to
the
same
in
PPC
pieces.
D
I
D
D
I
Iii
I
mean
I,
understand
or
one
option
that
you're
saying
is:
okay:
let's
provide
a
framework
that
provides
overall
security
or
confidentiality
of
the
whole
thing.
The
other
thing
would
be,
and
maybe
regional
is
you
protect
everything
with
the
session
key
and
you
enable
different
ways
of
creating
decision
the
session
key
at
this
point.
Basically,
what
you
have
is
you
you
exchange
it
in
clear,
but
if
you
manage
to
negotiate
that
key
from
which
some
other
means,
then
it
automatically
protects
the
whole
nor
the
rest
of
the
things
that
could
work
as
well.
I
I
Probably
if
we
want
to
do
that,
it
would
make
sense
to
actually
provide,
like
a
thread,
analysis
for
the
whole
protocol
and
try
to
define
what
are
the
security
goals
for
for
the
multi
party
city,
secure
version
that
that's
something
that
probably
worthwhile
I
mean
I
mean.
If
you
want
to
go
that
path,
that's
something
that
we
should
what
I
was
trying
to
do
in
this
particular
document
is
to
actually
because
the
thing
is:
if
you
go
in
that
path,
it's
a
major
change
in
the
product.
It's
not
a
minor
update.
I
This
is
like
a
significant
change
in
the
product.
What
I
was
trying
to
provide
here
that
I
think
it
is
feasible,
is
doing
minor
tweaks
in
potential
for
the
future
version
or
or
even
in
a
document
like
this,
just
simply
updating
the
base
spec,
because
it's
really
a
minor
update
I
mean
the
stuff
that
that
I'm
proposing
here
I
really
really
mind
right.
I
C
K
Adam
Whittaker
AX
enterprise,
so
we've
been
using
multipath
TCP
for
a
little
bit
now
in
the
u.s.
area.
K
But
we
haven't
been
doing
anything
with
and
we
don't
have
the
expertise
so
I'm
opening
it
up
to
everyone
here.
That
is
an
MP
TCP
to
hopefully
garner
some
discussion
because
we
feel
like
maybe
it's
something
has
to
happen
at
the
MP,
TCP
side
or
hip
side,
or
both
we're
not
sure
where
it
merges
together.
So
tonight,
at
610
in
room
C
two
on
floor
21
we're
having
a
hip
side
meeting.
K
It's
mostly
based
on
trustworthy
multi-purpose,
remote
ID,
which
is
our
current
focus,
but
because
we've
been
using
MP
TCP
in
the
UAS
spectrum,
we'd
be
more
than
happy
to
chat,
get
comments,
suggestions,
etc
so
feel
free
to
stop
by
and
say
hello,
so
that
that's
tonight
at
10
p.m.
tonight
at
us
610,
Oak,
610
610,
yes,
6,
1,
0
yeah
good.
Could
you
send
a
limo?
Yes.
C
C
So
we're
now
moving
on
to
the
topic
form
the
agenda
at
the
future.
The
working
group
I've
got
brief
summary
to
talk
through
Mason.
There's
lots
of
time
for
an
open
discussion
about
us
and
just
to
note
that
in
the
TSB
area,
meeting
on
Thursday
afternoon
is
a
little
time
stopped
there
to
talk
about
where
multi-path
work
should
be
done
in
the
ITF
and
future.
So
really,
this
discussion
today
impinges
on
that
bit
and
that
that
topic
on
thirst
is
slightly
broader
because
it
includes
things
like
melting
pot,
quick
as
well.
C
C
Right
so
the
future,
the
working
group
I
guess
the
default.
We've
talked
about
this
a
bit
before
about
you
know,
having
largely
what
we
have
now
completed,
what
we
got
reach
arted
to
do
so,
which
the
main
item
was
to
develop
the
best
version
of
the
protocol,
and
that's
now
in
the
kind
of
final
editing
with
Ayane
and
the
RFC
editor,
which
is
great
but
unders,
mean
we've.
We've
basically
completed
what
we
set
out
to
do
in
in
the
recharter.
So
we
need
to
think
about
what
so
what
to
do.
C
C
There's
not
a
problem
of
doing
that,
but
until
you
need
to
be
active
items
to
to
progress
in
the
working
group,
and
that
really
means
that
there
needs
to
be
multiple
people
involved
to
do
the
design,
the
documentation
and
reviewing
and
see
and
somebody's
going
to
implement
the
ID
live
as
well
and
I.
Guess
we
need
more
than
one
kind
of
small
topic
that
applies
to
those
active
items,
so
you
know
get
here
today
and
then
over
the
next
few
weeks
min
before
the
next
night.
C
So
as
a
as
a
kind
of
point
of
information
in
the
next
slide
of
we've
listed
the.
If
you
go
on
the
beta
track
of
the
active
individual
drafts
that
there
are
so
these
the
ones
that
the
data
track,
that
considers
a
kind
of
live
documents,
I
mean
the
worst
set
will
expire
draft
that
I
think
people
may
want
to
reactivate.
C
You
know
we
just
heard
about
the
one
of
combining
for
best
security,
combining
them
with
TLS
and
that's
no
longer
neck
to
drop.
It
was
there
an
impasse.
There
may
be
other
ones
as
well,
so
this
that
this
is
a
list
of
active
individual
graph.
So
this
it
kind
of
maybe
things
that
people
want
to
to
take
on
and
there's
a
sufficient
group
of
people
who
are
prepared
to
work
on
them
and
development.
We
can.
We
can
keep
going
as
a
working
group.
C
So
this
the
robust
session
establishment
stuff
that
we
heard
out
about
today
from
for
Marcus
and
he
made
requests
for
some
beater
to
implement
that
there's
an
active
there's.
A
draft
called
initial
path,
selection,
which,
to
me
kind
of
sounds
a
similar
problem
because
trauma
tackles
so
that
might
be
a
way
of
trying
to
get
some
extra
people
working
on
the
same
idea.
C
I've
tried
bearing
in
brackets
by
by
the
way
to
list
the
main
author
and
then
I
put
some
affiliation
so
after
you
know,
Marcelo's
at
u3
uc3m,
but
then
I'd
put
affiliations
in
practice
after
to
indicate.
There
is
actually
already
in
on
that
one.
A
group
of
people
from
different
institutions
who
are
all
sufficiently
interested
in
this
work
to
have
been
a
co-author
on
it.
C
Thus,
the
work
that
Sebastian
did
looking
at
how
to
get
TFO
and
not
of
TCP
to
play
well
with
each
other
and
posting
some
mobster
MPG
see
people
where
there's
a
he
is
five
PI
D
session
continuity
work.
It's
the
sweet,
EVP
session
continuity
stuff.
We
look
identified
some
inefficiencies
of
getting
that
to
not
a
novice
beater
to
as
the
solution
from
the
session
continuity
and
up
with
some
ideas
for
overcoming
those
inefficiencies.
C
C
There
was
a
proposal
from
a
song
to
measure
one-way
latency
to
kind
of
help
with
the
scheduler,
a
multi-speed
scheduler,
and
then.
Lastly,
there
was
another
shephelah
related
one,
that's
fantastic,
optimal
scheduler,
which
is
a
draft
on
there,
I'm
not
sure
we've
ever
had
she
had
that
presented
and
a
meeting,
though
that's
another
life
dropped,
and
so
that
was
kind
of
for
information
as
the
list
of
individual
graphs.
C
Small
group
who
are
interested
in
it
and
it
doesn't
get
that
much.
It's
been
hard
to
grow
those
from
Lee
from
the
proposer,
a
big
interview
draft
and
that's
not
true
for
absolutely
to
all
the
people
that
in
genuine
country
it's
a
kind
of
now
it's
it's
kind
of
open
for
discussion
already
about
how
people
see
futures
working
group.
If
people
are
happy,
if
we
close,
if
people
want
to
try
and
pick
some
of
these
or
some
different
ones,
to
really
get
some
some
live
work
with
with
several
different
people,
contributing
to
the
review
side.
C
E
Again,
Marcus
Allen,
so
I
have
several
questions.
Maybe
some
of
them
are
related
to
Miriah
comfort
area
director.
So
can
you
go
to
the
previous
slide?
Please?
First,
okay!
So
in
the
first
point
you
raise
that
maybe
my
next
tensions
maintains
us
made.
It
is
p.m.
my
question
is
what
are
minor
extensions.
For
example,
today
I
proposed
the
robust
establishment.
It
was
a
minor
extension
or
a
major
extension.
E
E
We
also
proposed
market
cost
DCP,
for
example,
so
in
general
it
makes
sense
to
or
shall
we
collect
them
may
be
in
one
working
in
second
point-
and
the
third
point
is-
and
that
is
one
also
one
of
the
active
draft
documents
we
have
in
the
in
the
last
slide
that
multiple
TCP,
the
protocols
elected
by
three
TPP
for
market
multiple
activity
purposes.
So
that's
why
I
wanna
ask
it
as
part
of
the
liaison
between
you
could
appear
an
ITF,
and
for
that
reason,
does
it
make
sense
to
keep
multiplicity.
L
So
basically
everything
that's
on
there
under
this
right
now
are
probably
my
extension.
The
only
reason
to
keep
the
working
group
is,
if
there's
like
a
long
list
of
mine
extensions,
you
all
want
to
do
and
then
maybe
you
know,
I'm
working
with
make
sense
and
question
number
two.
Yes,
that's
exactly
my
problem.
L
We
have
all
these
magic
press
work
which
is
discussed
in
different
problems,
and
we
want
to
make
sure
that
we
we
have
people
exchanging
their
ideas
and
not
like
working
on
two
things
in
parallel
and
whatever
coming
to
different
conclusions
for
whatever
reason.
So
that's
the
main
problem
here,
but
that's
a
discussion
I
want
to
have
in
Gees
the
area
fantastic
and
Third
Point.
Yes,
the
3gpp
liaison
is
very
aware
of
this
usage
of
empathy
TCP,
but
they
use
it
as
specified.
M
Other
circum
and
a
strictly
related
on
3gpp,
if
you
practically
have
two
drafts
better
dependencies,
one
of
them
percolate
since
the
last
code,
the
other
one
which
would
I
assume
that
you're
gonna
conclude
it.
So
from
this
perspective,
is
artistic
extensions
for
multiple
operation,
multiple
addresses
so
once
met
on
it
is
concluded.
You
practically
have
zero
dependencies
from
this
work,
so
there
is
another
reason.
M
I
kind
of
live
there
are
two
drafts.
Okay,
one
of
them
is
a
zero
RTP
PCP
convert
protocol.
It
is
the
last
call,
okay
from
what
I
understood
the
other
one
is
the
main
draft
that
you
have
26
tensions
for
multi
path,
operation
with
multiple
addresses,
which
will
gonna
conclude
it
I,
assume
by
xiah
TF
406
yeah.
L
So
the
way
we
GP
is
that
we
keep
a
list
of
dependencies,
so
we
know
which
documents
which
RFC
drafts
are
referenced
in
three
documents
and
there
are
two
references
which
are
relevant
to
the
NPT
CP
work.
One
is
to
the
best
document,
which
is
now
approved.
Therefore
we're
good
here
and
the
other
one
is
to
the
TCP
converter,
which
is
working
TC
p.m.
and
this
is
approaching
as.
D
C
The
who
has
been
turned
off
so
it
was
it
was
this
the
people
support
having
all
the
options
encrypted
to
get
a
more
secure
version
lot
of
these
three
maps
across
America.
Do
people
want
to
comment
on
that?
That's
probably
easier
than
having
a
hum.
Isn't
it
people
like
that
idea
of
working
on
a
more
secure
version
where
you
tripped
all
the
options?
C
C
D
D
D
C
C
D
Comment
from
Chuck
and
saw
a
dimension
here
is
that
trust,
MPT
speed
digression.
The
raft
has
been
submitted
long
time
ago,
and
then
he
said:
if
people
are
interested
in
it,
I
would
contribute
I
mean
that
means
probably
he
can
divide
the
drug
in
the
back
unit,
and
this
is
relatively
easy,
rather
than
building
something
from
scratch
to
integrate
and
to
add
more
security
feature
in
any
TCP
spec,
and
so
there
might
be
interesting,
pass
or
secure
button
of
MPCP.
O
Ohio
I
just
wanted
to
flag
up
that.
Obviously,
a
lot
of
people
don't
want
to
do
encryption
at
the
TCP
level
and
that's
kind
of
sensible
we've
got
teased
the
ink
already.
You
don't
want
to
go
into
reinventing
the
wheel
here,
but
we
have
T
a
TLS
and
the
proposal
we
put
in
that
draft
I
posted
a
link
for
was
simply
to
do
TLS
key
extraction
and
use
the
keys
to
engage
the
TLS.
The
engage
use,
the
keys
and
TLS
to
do
the
session
security.
O
If
it's
only
like
a
four-page
graph,
because
that's
all
you
need
to
do
this
and
there
was
next
grand
prix,
tcp
operon
farming.
I
haven't
thought
about
how
much
would
be
one.
This
was
still
a
v0
thing,
but
if
there
is
an
increased
interest
in
doing
encryption,
I
would
like
to
propose
that
as
a
starting
point
for.
I
G
L
C
I
C
G
Echoing
fella
from
Germany
I
have
a
question:
could
it
be
that
a
lot
of
people
are
in
holiday
and
so
because
you
have
a
lot
of
individual
drafts?
What
we
have
seen
and
I
here
see
you
not
so
much
discussion
today,
but
in
Prague
we
see
a
lot
of
discussion
more
discussions.
I
remember
so
maybe
it
is
only
a
bad
day
yeah.
A
P
P
Shred
in
the
valley
I'd
like
to
encode
that
comment,
I.
Think
if
you
look
at
if
you
go
back
to
the
next
slide,
please
so
many
of
these
proposals-
I
remember
you
know
you
have
discuss
this
war,
so
light-years
right,
but
you
know
when
did
thought,
though
the
consensus
of
the
room.
There
was
general
interest
for
doing
that
work.
P
So
now
I
think
you
know,
but
we
haven't
properly
closed
it
right,
whether
we
haven't
issued
an
eruption
call
or
any
of
those
work
items
right,
so
my
recommendation
would
be
like
you
know,
delay
this
decision
to
do
this
here
and
some
other
group.
It's
your
decision,
but
some
of
these
work
items
have
relevance
in
my
opinion,
so
maybe,
instead
of
106,
maybe
move
this
discussion.
Let's
make
sure
this
proper
participation.
Also
today,
the
attendance
is
somewhat
very
light.
There's
also
some
other
Bop
going
on
I.
Think
for
multiple
reasons.
L
L
Regarding
you
just
said,
some
of
these
items
have
support
and
they
are
light.
That's
great.
We
can
do
them.
We
don't
have
to
do
them
in
this,
mainly
in
this
working
group.
Right,
but
like
the
more
important
part,
is
it's
not
enough?
It
only
that
you
also
support
it.
You
need
people
who
are
reviewing
this
who
are
implementing.
This
were
contributing
to
it
right
if
we
have
10
items
and
each
of
the
items
has
only
the
officers
contributing
to
it.
It's
not
helpful
at
all.