►
From YouTube: IETF99-MPTCP-20170721-1150
Description
MPTCP meeting session at IETF99
2017/07/21 1150
https://datatracker.ietf.org/meeting/99/proceedings/
B
B
So
I
thought,
since
there's
been
a
lot
of
discussion
on
the
list
in
the
last
couple
of
days
about
both
the
converter
draft
and
the
Sox
draft.
I
really
wanted
to
give
people
a
chance
to
follow
up
all
in
you
know
in
a
face-to-face
session
on
those
two
drafts.
So
does
anybody
on
us?
There
was
kind
of
a
burst
of
discussion
which
is
actually
died
down
in
the
lost
day,
which
mmm-maybe
implies.
We
have
some
consensus
on
it,
or
perhaps
just
implies
that
people
have
got
other
things
to
do
at
the
moment.
B
B
So
that's
that's
great
and
I
think
it's
good
that
we
remain
in
in
the
discussion,
but
I
don't
think
it's
unlikely
would
be
the
working
group
reading
it.
On
the
converter
thing,
my
read
of
the
discussion
that
happened
for
coming
on
Tuesday
and
Wednesday
in
particular,
was
quite
promising
and
that
that
people
seem
to
quite
like
the
approach
and
the
people.
B
So
unless
anybody
wants
to
make
any
further
comments
and
follow
up
any
of
the
points,
my
suggestion
is
that
the
authors
of
that
draft
do
a
rev,
a
new
version,
taking
account
of
the
comments
which
were
lots
of
clarification
things
Durov
do
revision
will
ask
for
comments
again
on
all
the
relevant
mailing
this
and
then
will
work
out
with
Mia.
What
the
right
working
group
is
to
do
it,
because
you
know,
obviously,
should
be
the
corporate
call
for
it
to
be
adopted
as
to
say
what
working
group
will
work
on
it.
B
So
topic
2
today
is
this
is
a
new
security
attack
which
Xeon
and
sorry
apologize
for
mangling.
Your
name
Xion
and
colleagues
raised
a
couple
of
days
ago
on
the
mailing
list,
and
this
is
really
great
that
they
brought
it
forward
and
notified
us
and
there's
been
some
nice
discussion
in
the
last
couple
of
days
of
it,
so
that
for
those
of
you
who
haven't
caught
up
I've
tried
to
extract
some
points
from
the
email.
Now
that
we
just
look
at
me
technically
I.
B
B
So
that's
that's
the
vulnerability
if
you
like
that
the
this
proposed
attack
is
exploiting
so
that
the
solution
that
seemed
to
that
the
Xion
and
others
have
suggested
is
the
possible
solution
is
to
remove
the
address
identifier
from
the
option
and
my
read
of
the
discussion
that
was
on
the
list
is
this
was
seen
to
not
have
very
many
down
sights
and
that
he
would
cure
the
issue.
So
we
ought
to
have
some
discussion
so
I
will
throw
open
the
mic.
Alan
Alan.
C
D
So
Allah,
given
OTO
I,
think
the
attack
is,
is
important
in
practice
because
you
have,
let's
consider
one
case
where
your
you
have
a
smartphone
and
you
are
connected
to
a
Wi-Fi
access
point
and
a
cellular
network.
If
you
control
the
Wi-Fi
access
point,
then
you
can
tell
with
the
attack
that
the
cellular
network
should
not
be
used
to
transmit
data.
D
So
you
move
all
the
traffic
over
the
Wi-Fi
access
point
and
the
reason
is
that
in
the
NP
prior
option
and
I,
don't
remember,
for
which
reason
we
have
placed
an
address
identifier
in
addition
to
the
bit
and
this
address,
identifier
should
indicate
that
you
would
put
as
a
backup
all
the
sub
flows
that
are
used
that
are
using
this
specific
address
identifier-
and
this
is
a
really
strange
use
case
and
as
far
as
I
know,
no
implementation
is
doing
that.
So
I
would
support
the
removal
of
the
address
identifier
from
the
NP
prior
option.
D
And
if
you
remove
the
address
identifier
from
the
MP
prior
option,
then
you
are
forced
to
use
the
MPI
option
on
the
sub
floor
that
you
want
to
change
the
backup
status,
which
means
that
you
need
to
be
on
path
to
attack.
This
particular
sub
group
and
I.
Think
this
solves
the
problem
and
we
keep
the
protocol
simple
and
usable.
B
B
B
E
Yeah
good
morning
my
name
is
Marcos
from
the
company
with
a
magenta
color.
As
you
can
see,
it's
a
telecon
and
yeah
today,
I
want
to
talk
about
real,
existent
and
annoying
problem.
We
were
faced
with
into
the
field
and
yeah
my
my
goal
for
today
that
I
can
gather
them
feedback
from
your
site,
because
it's
the
first
time
for
me
at
ideas
and
I'm
not
pretty
familiar
with
process
here.
E
So
please
support
me
during
you
know
the
presentation
or
afterwards
so
can
we
go
to
the
like
I
think
that
we
can
skip
directly
and
okay,
so
I
have
an
example
where
I
try
to
explain
the
problem
you
have
faced.
First,
we
start
with
the
standard
empty
TCP
and
we
have
a
you
see
a
smartphone
and
we
assume
that
it
is
system-wide
enabled
with
standard
MP
TCP
and,
as
you
know,
it's
not
fun.
E
Today
it
has
a
Wi-Fi
interface
and
a
cellular
interface,
and
if
it
tries
to
connect
MP
capable
receiver,
it
will
work
like
that
that
it
first
tries
to
open
initial
flow
over
or
through
the
default
default
route.
And
if
it
is
successful,
then
afterwards
it
can
open
subsequent
flows.
So
I
think
most
of
you
know
this
process
and
yeah
as
soon
as
a
to
succeed
point
succeeds,
so
you
have
a
subsequent
flow.
Then
you
have
multi
path,
capabilities,
which
means
resilience
and
possibly
event
with
a
cognition
yeah.
E
Ok,
what
is
now
the
our
problem
or
the
motivation
for,
or
a
proposal
for,
a
robust
establishment?
What
happens
if
the
default
route
is
not
able
to
transmit
or
succeed
in
reaching
the
server
in
establishing
an
initial
flow?
And
the
answer
is
pretty
simple:
nothing
will
happen.
Even
if
you
have
another
working
path.
You
know,
for
example,
the
cellular
network.
You
can
not
reach
the
destination
and
that's
it's
it's
a
problem.
So
the
question
is
always:
where
do
you
put
the
default
route?
E
E
E
You
want
to
have
potential
initial
flows
using
all
paths
available
during
the
establishment
process
and
do
not
rely
any
more
on
one
half,
and
that
is
what
you
can
see
here
now
we
directly
start
on
both
interface
potential
initial
flows
and
even
if
on
the
default,
a
default
route,
it
cannot
succeed,
it
will
work
over
the
cellular,
so
any
path
can
be
used
to
establish
a
connection,
the
idea
and
for
that
we
developed
three
different
proposals.
I
want
to
present
now.
E
That
means
that,
at
the
end,
guarantees,
robustness
and
overall
latency
reduction.
Why
overall
latency
reduction?
We
have
two
things
in
respect
to
to
latency,
first,
the
quickest
path
and
Abel's
communication,
and
secondly,
we
have
the
path
all
the
flows
earlier
available
and
can
use
them.
For
example,
earlier
for
bandwidth,
I
could
and-
and
the
last
point
we
do
not
Institute
with
this
concept.
Any
kind
of
network
overhead.
E
Yeah
that
guarantees
robustness
as
well.
We
have
some
nitrogen
reduction,
so
it's
of
the
same
s
and
through
the
don't
write
approach.
So
the
quickest
party
in
game
determine
the
the
handshake,
latency
and
second
emergency,
but
then
we
reset
all
the
other
one
and
again
we
have
to
use
the
MP
join,
so
the
sub
flows
will
not
be
there
earlier.
As
in
the
don't
write
approach
yeah,
it's
then
like
standard
MP
TCP,
and
we
cause
a
business
network
overhead
because
we
have
a
lot
of
handshaking
which,
at
the
end,
we
reset.
E
Yeah
and
the
last
proposal
that
we
call
the
time
solution,
we
don't
like
it,
but
it
has
the
benefit
that
list
Falls,
then
they're
compliant,
but
compared
to
the
two
other
proposals
we
have
already
seen.
It
is
less
efficient
and
of
course
it
guarantees
robustness
as
well
what
we
are
doing,
and
that
is
pretty
like
the
happy
eyeballs
concept
from
RFC
six
five,
five
five.
E
We
start
with
a
normal,
soon
request
over
the
first
interface.
It
will
the
default
route
interface
and
if,
after
some
time,
we
do
not
have
success
in
establishment
a
connection
to
the
receiver
side,
then
we
tried
on
another
interface
and
if
you
could
assume
that
can
introduce
a
lot
of
delay,
because
we
have
to
recognize
that
one
or
several
paths
will
not
work.
E
But
it
needs
sender
and
receiver
modifications,
possibly
some
standard
extension,
and
there
are
pretty
sure
that
we
meet
some
standard
extension
for
such
an
approach
and
yeah.
At
the
end,
it's
the
most
challenging
one
in
terms
of
a
send
that
extension
and
of
implementation
now
to
the
middle
column
right
before
make
it.
It
also
provides
for
Buster's
it
had
the
initial
flow
latency
reduction.
So
compared
to
the
don't,
read
it's
a
little
bit
less
efficient
yeah
again
it
needs
something
that
we
see
by
modifications.
It
will
need
some
standard
extension
I.
E
Guess
it's
challenging
as
well
and
introduce
some
additional
network
overhead,
because
we
have
to
reset
all
that
one
and
then
we
have
to
proceed,
be
the
empty
throne
again
on
the
right
side
on
the
right
for
now
the
the
timer
solution,
so
it
provides
through
buses
as
well.
That
is
why
we
are
doing
that.
E
You
define
a
question:
no,
no
okay,
so
we
defined
some
some
criteria
to
evaluate
our
own
proposals.
We
we
made
and
obviously
the
important
point.
The
important
point
is
robustness
and
all
of
them
fulfill
this
criteria,
then
compared
to
MP
TCP
as
well
to
a
standard,
MP
TCP,
the
network
overhead
should
be
minimized,
and
that
is
true
for
proposal
1
and
proposal
3,
but
not
for
proposal
2,
because
we
we
said
all
the
unnecessary.
E
Initial
flows
or
potentially
initial
flows,
the
latency
also
compared
to
to
spend
a
template.
If
you
should
not
be
increased
and
in
the
best
case,
we
can
also
reach
use
it,
and
that
is
fully
true
for
proposal
born,
because
there
we
we
can
or
we
will
reduce
the
overall
ED
latency
before
the
cricket
path
over
the
quickest
potential
initial
flow
will
win
and
establish
a
connection
and
yeah
for
proposal
to.
We
will
not
increase
the
latency
and
we
will
have
some
little
reduction
just.
F
Hi,
my
name
is
Uma
from
Huawei.
Very
good
draft
hi
quickly,
skim
through
it
I
didn't
understand
why
you
didn't
put
mbb
kind
of
Sena
make
before
break.
Is
it
not
applicable
at
all
in
this
case,
or
a
little
people
are
symptoms.
We
have
this
mbb
right
make
before
break
was
very
heavily
used
in
a
rama
routing
background
guy.
So
why
not?
This
is
applicable
here.
First,
you
make
the
connection
then
break
it.
E
E
Yeah
and
propose
three
people
most
probably
have
some
latency
increase
in
the
case.
If
the
default
route
is
not
working
and
yeah,
they
were
not
reach
use
the
latency
compared
to
standard
mpg
CP
and
the
last
point
is
standard,
a
standard
compliance
that
I
have
to
explain
a
little
bit.
So
we
assume
that
for
all
proposals
either
we
can
directly
incorporate
with
the
existing
MP
TCP
standard,
or
we
need
just
a
little
mini,
just
minor
updates
of
the
standard,
but
it's
solvable
from
you.
So
it's
all
of
them.
True,
okay,.
E
We
decided
to
investigate
a
little
bit
more,
the
preferred
approach,
the
preferred
approach
for
the
dark
right
approach
and
interested
first
in
an
environment,
so
we
developed
a
prototype.
We
implemented
in
the
standard,
MP
TCP
in
version
0,
&
9,
and
he
feels
like
a
lab
setup
where
we
casted
it
first.
So
we
have
a
host
a
and
host
B.
Both
are
multi
path,
capable
and
host
a
has
two
interfaces
where
a
one
at
the
default
rod
and
a
two
is
a
secondary
path.
E
We
had
no
packet
loss
on
the
secondary
part
and
the
latency
was
the
same
on
both
paths
and
what
you
can
see
now
in.
On
the
left
side,
we
show
the
average
handshaking
time
over
the
packet
loss
of
the
default
rod
and
you
see
for
MP
TCP
the
ever
attend
shaking
time
increased
tremendously
over
the
packet
loss
and
with
100%
it's
not
possible
to
establish
any
connection
and
with
our
preferred
approach,
mptp
Rob.
We
call
it
the
blue
line.
E
E
Now
again
the
same
test,
but
now
we
want
to
show
the
latency
benefit
and
the
default
rod
that
we
introduced:
40,
milliseconds,
one-way
latency,
so
no
packet
loss
anymore,
trust,
the
40,
milliseconds,
one-way
latency
and
on
the
secondary
path,
20,
20,
millisecond,
one-way
agency.
So
from
theory
the
handshaking
needs
three
times
the
one
when
agency
and
that
you
can
see
now
in
the
in
the
figure.
So
for
every
TCP
we
have
around
130
my
120
milliseconds
and
shaking
curation.
E
E
So
that
means
of
the
route
the
default
route
between
the
host,
a
on
the
left
side
and
the
application
server
and
on
the
secondary
part,
be
introduced
in
20,
milliseconds,
one-way
them
can
see
ya
and
what
you
can
see
now
on
the
figure
it
the
loading
time
over
the
different
websites
and
the
different
approaches,
the
MP
TCP
or
entities.
Here,
oh
and
yeah,
you
see
in
9
of
10
websites.
There
is
a
benefit
by
entities
of
Europe,
it's
just
in
the
case
of
vk.com
yeah,
there's
no
benefit
but
I
assume
again.
E
E
First,
some
general
effects:
MP
TCP
rope
can
protect
MP
TCP
against
network
auditors
during
the
connection
establishment.
It
can
improve
the
user
experience
in
terms
of
reliability
and
latency
under
most
circumstances.
Learning
times
can
be
shortened
by
having
maximum
throughput
earlier
available,
and
we
already
did
some
reference
implementation
based
on
mt
tcp
version
0-9
and
now
the
important
point
for
me
that
question
I
want
to
discuss
with
you
if
they
are
generally
need
for
us
to
stablishment.
E
If,
yes,
there
should
it
take
place,
so
I
had
already
some
discussion
with
Ollie
bein
on
the
mailing
list,
and
there
was
one
proposal
from
his
side
to
do
it
in
the
application
layer.
So
in
the
responsibility
of
open
developer.
I.
Personally,
don't
like
this
approach.
I
think
it
should
be
in
the
MT
TCP
layer
know
that
we
have
multipath
capabilities
from
the
very
beginning.
I
was
an
MP
TCP
session
yeah.
The
next
question
want
to
benefit
from
only
robustness
or
a
won't.
We
benefit
from
robustness
and
latency
reduction.
E
Yeah,
which
approach
in
general
fits
best
in
future.
So
is
it
any
of
the
proposals
I
present
today
or
there?
Any
other
approach
which
can
be
bit
can
fit
how
to
integrate
the
MP
TCP
Rob
into
the
MPEG
key
standard
or
the
implementation
and
yeah
how
to
develop
or
improve
the
existing
reference
implementation
and
make
it
available
all
of
the
process.
If
you,
if
you're,
interesting
about
and
and
so
on,
but
before
I,
hopefully
get
some
answers
from
your
side.
E
E
E
E
Okay,
so
this
as
I
mentioned,
we
be
duplicating
the
key
a
and
here
you
see,
host
a
and
host
B.
So
it's
pretty
simple.
But
what
happens
if
at
the
same
time,
there's
a
host
C
which
try
to
reach
host
E
and
by
accident
or
by
intention
its
uses?
To
that
the
same
key,
a
what
happened,
then,
then
we
have
a
problem
because
key
a
X
in
the
approach
as
an
identifier
that
flows
belonged
belongs
to
the
other
and
there
we
need
some
solution
to
handle
this.
So.
E
So
we
have
some
ideas:
how
how
we
can
mitigate
the
problem,
so
we
cannot
fully
use
it,
but
you
can
mitigate
it.
I
guess
so.
We
can
reduce
the
time
frame
where
we
allow
allow
use
and
request
with
the
same
here
or
we
can
use
some
remaining
space
in
the
m
capital
options,
for
example,
to
introduce
some
additional
identifiers
that
that
flows
belongs
together.
E
Also,
we
have
to
solve
the
problem
of
the
SSID
because
from
the
fgetc
key
standard,
normally
the
atrocity
is
0
for
the
initial
flow
and
for
all
the
others
it
is.
It
then
negotiated
and
may
be
that
we
can
solved
in
the
same
way
that
we
introduced
some
additional
information
into
the
NP
capital
in
general.
There's
a
question:
if
there
a
need
to
negotiate
rope,
support
between
client
and
server
can
be
solve
it
in
another
way.
E
So
there
was
from
the
NRC
T
at
ikf
97,
a
proposal
which
is
pretty
similar
to
our
afraid
before
make
no
sorry
for
it.
Approach
and
I
had
already
the
chance
two
days
ago
to
discuss
with
a
Qian
on
from
Nick
and
realized
that
we
have
the
same
focus
and
maybe
work
together
on
on
the
traffic
or
whatever
yeah,
and
we
have
the
API
balls
which
can
be
implemented
in
the
application
layer.
E
C
But
the
semantics
of
the
key
simply
aren't
aren't
the
same
as
what
you're
using
you
know,
it's
a
key
that
the
pair
of
keys
for
the
entity
is
once
they're
involved
once
it's
set
up,
have
a
semantic
meaning,
but
you
simply
can't
assume
that
two
keys
on
the
wire
from
two
random
IP
addresses
are
the
same
thing.
As
you
say,
you
have
identified
that
as
a
risk,
but
I
as
far
as
I
can
see
it's
pretty
much
a
showstopper
more
than
anything
else,
but.
C
64
but
but
we
are
firmly
especially
for
a
malevolent
attacker,
wasn't
an
accident,
so
that's
a
concern,
but
how
I'm
most
curious,
given
you've
identified
or
less
there's,
no
point
rehashing
it
but
I'm
most
concerned
about
how
you
see
it
working
without
the
key.
On
that
last
point,
you
said
you
said
you
had
a
way
around
that.
E
E
So
if
you
don't
have
the
key
a
from
the
very
beginning,
so
it's
missing
in
the
first
soon
yeah.
Obviously
then
we
don't
have
the
information
and
you
cannot
use
it
and
that
identifier,
but
in
the
last
acknowledgment
we
have
both
keys
available
and
I.
Think
then
you
can
make
the
decision
on
receiver
side,
for
example,
because
so
but
I
assume.
C
C
E
Then
we
would
then
be
what
replays
all
right.
If
you
talk
about
not
sending
the
key
a
in
the
soon,
then
we
are
not
aware
of
it
and
Ho
speed.
The
receiver
will
answer
with
different
keys.
Yes,
but
at
the
end,
if
knowledge
month
arrives
again
the
host
P,
then
he
can
identify.
The
flows
belong
together
because
of
the
key,
a
for
example,
or
some
other
information,
and
then
he
can
be
replaced
internally.
C
D
Divya
bharati
I
think
I
totally
agree
with
the
use
case.
So
there
are.
There
is
a
good
motivation
to
do
that,
but
my
feeling
is
that
looking
at
what
has
been
done
with
a
pea
eyeballs,
because
when
you
have
a
queue
before
and
ipv6
is
the
same
issue,
you
don't
really
know
whether
you
should
connect
over
v4
v6.
D
So
if
you
look
at
smart
phones,
for
example,
applications
do
not
connect
directly
by
using
the
socket
of
the
socket
API.
They
have
an
underlying
API
which
is
provided
by
this
wonderful
vendor,
and
it
already
takes
care
of
you,
selecting
which
source
address
to
use
depending
on
whether
the
Wi-Fi
is
available
or
the
LG
is
available.
D
And
so,
if
you
decide
to
use
both,
then
you
can
use
both
in
the
API
and
you
can
use
a
timer
with
whatever
value
you
want,
but
that
would
be
part
of
G
and
this
is
completely
hidden
from
the
application.
So
there
is
a
shim
layer
that
does
this
for
you
without
requiring
any
changes
to
the
protocol.
So
I
think
the
use
case
is
really
valid
and
I
encourage
you
to
continue
to
work
on
the
use
case.
D
But
I
would
focus
on
looking
at
the
application
level
solution,
because
you
get
almost
the
good
benefits
that
you
want
and
the
just
the
cost
that
you
have
is
that
you
might
open
connections
that
are
useless
and
that
you
reset
already.
But
this
is
done
by
many
applications.
So
this
shouldn't
not
be
an
issue
and
the
advantage
of
the
library
is
that
you
can
remember
what
you
have
done
in
the
past
easily
and
then
you
can
avoid
sending
too
many
duplicate
scenes.
D
E
D
D
But
whatever,
as
I
said,
applications
will
interact
with
the
shim
library
anyway
and
taps
is
building
this
kind
of
library,
and
you
should
look
at
the
neat
project.
They
are
writing
this
library,
which
allows
to
select
transfer
protocols,
and
this
is
more
complex
than
just
selecting
the
source
address.
So
this
is
a
shoot.
They
are
doing
a
superset
of
what
you
need.
E
D
E
G
Chrissa
posh
apple
I
also
want
to
say
this
is
really
important
where
we're.
Basically,
it's
really
important
to
get
a
robust
connection
establishment
and
in
iOS
we
have
something
that
is
called
wife
Isis.
That
is
basically
doing
the
timer
based
approach
and
to
kind
of
reiterate
whatever
Olivia
already
said.
G
The
advantage
of
the
time
of
its
approach
is
that
as
it's
sitting
inside
the
library,
it's
also
independent
of
the
transport
layer
protocol,
so
whether
it's
MP
TCP
TCP,
whether
the
server
supports
it
or
not,
it
just
works
like
the
application,
doesn't
need
to
do
anything,
and
another
point
also
were
at
the
time
of
is
approaches
curved.
It's
a
timer
you're,
not
constantly
erasing
Wi-Fi
versus
cell,
because
you
want
to
favor
Wi-Fi
and
only
you
cell.
E
E
Do
you
need
some
time
I
think
to
detect
that
the
Wi-Fi
is
not
working
well,
I,
don't
know
how
all
your
algorithms
work
and
maybe
be
introduced
a
lot
of
delay
to
recognize
that
there
is
a
problem.
That
is
the
the
negative
point
of
the
timer
based
approach
from
from
ICU.
But
the
question
is
what
you
want
to
have
at
the
end.
Is
it
just
a
bastard
or
is
it
more.
H
Crying
brain
Trammell,
I
really
like
proposal
one
but
I
share
Alan's
sort
of
security
heebie-jeebies.
When
I
look
at
it,
we
need
actually
to
have
serious
security
people
throw
some
cycles
at
it
to
say
that
it's
okay,
the
other
thing
that
makes
me
less
enthusiastic
about
it-
is
that
I
don't
see
a
partial
implementation
or
partial
transition
solution.
Do
it
it's
like
we
put
it
in
a
standard,
then
it's
magically
there.
You
need
to
have
some
negotiation
as
to
whether
or
not
you're
a
modified
receiver
that
can
support
protocol
one.
H
H
D
B
H
I
Another
instruments
that
have
been
on
the
mic
already
I
just
wanted
to
add
one
thing,
and
that's
it's
also
not
the
latency
trade-off.
It's
not
so
simple,
so
it's
not
necessary
that
you
know
using
both.
The
paths
is
always
going
to
give
you
the
best
latency,
because
if
you
want
to
have
them
both
for
robustness,
you
want
to
have
the
most
for
short
flows.
Once
you
get
into
the
path
being
heterogeneous,
it's
not
necessarily
always
a
win.
E
I
What
I
was
saying
was
that
when
you
have
two
paths
and
they're
heterogeneous
also,
if
you
just
say
you
know,
I
want
to
have
both
of
them,
because
they
all
is
gonna.
Give
me
less
latency.
That
is
not
necessarily
true,
because
when
the
paths
are
heterogeneous,
you
may
not
want
to
use
both
of
them.
It
may
actually
make
it
slower,
because
you
may
get
traffic
on
the
short
path
and
it
could
dominate
the
completion
time.
Yeah.
I
E
J
So
ello
everyone
I'm
Kanta
from
UC
lugar,
and
this
is
a
proposal
for
fastest
of
procreation.
So
so
why
do
we
propose?
This?
Is
fact
that,
for
instance,
current
of
implementation
typically
initiate
a
connection
and
then
they
create
sub
flows
on
all
pairs
of
IP
addresses,
and
this
is
great
for
bandwidth
segregation,
but
in
the
case
of,
for
instance,
Matt
phone.
This
is
not
useful
and
in
fact
it
can
be
worse
than
what
we
can.
J
J
J
So
the
idea
is
in
fact
we
want
to
either
break
before
make
approach
at
the
subfloor
level
and
we
want
to
delay
the
creation
of
backups
of
flow.
In
your
case,
the
cellular
sub
flows
so
yeah
this
nice
for
from
the
office
allocation
for
energy
consumption,
but
yeah
it's
a
kind
of
reactive
approach,
and
so
you,
if
you
need
some
time
to
detect
if
you
really
need
to
create
a
cellular
acid
flow,
and
so
you
can
have
larger
latency
and
yeah.
You
don't
want
with
to
a
latency,
and
this
is
annoying
up
in
the
sense.
J
Furthermore,
establishing
stop
flows
in
multiple
CP
takes
some
time
right,
as
shown
here.
Actually,
when
you
want
to
us
your
smartphone
that
that's
data
to
be
sent,
and
you
want
to
create
a
new
subfloor,
you
have
to
wait
to
RTT
before
actually
sending
your
data
and
so
yeah.
If
the
latency
of
your
cellular
network
is
quite
high,
you
will
wait,
which
you
have
an
increased
latency,
which
is
annoying
and
so
yeah.
J
If
we
could
create
sub
flows
in
a
one
RTT
or
even
in
as
0rt
fashion,
it
would
be
nice
if
we
could
do
some
kind
of
TFO,
but
at
multi
pass
CP
level
using
multi
pass
connection
information
to
establish
the
subfloor.
It
would
be
great
because
you
can
send
that
in
the
sin
and
then
you
can
have
the
answer
or
just
a
total
cynic,
and
so
in
it's
just
a
latency
of
using
sending
data
on
the
cellular
if
in
this
case,
so
it's
like.
J
Backup
path-
and
we
see
that
compared
to
the
classical
joint
way
of
doing
things
you
around
at
least
one
acity-
you
save
at
least
one
entity
when
requests
are
quite
large
and
if
the
request
fit
in
the
syn
packets,
in
fact,
you
can
save
towards
the
to
RTT
of
the
establishment
of
the
so
flow,
which
is
which
could
be
nice.
So
next
slide.
J
So
about
the
proposal
except
the
concrete
proposal.
We
want
to
wait,
Alicia
additional
multiple
City
auction,
a
first
one
that
would
create
a
Sapru
when
you
want
to
send
data.
So
typically,
when
you
have
requests
based
on
traffic
and
the
client
detects
that
your
Wi-Fi
stats-
and
so
you
will
send
your
data
directly
in
a
when
creating
the
Sutro
Oh
another
option
when
you
want
to
create
a
sub
flow,
but
the
clay
on
earth
not
to
send,
but
it
knows
that
it
has
that
are
to
be
received.
J
For
instance,
you
are
in
the
middle
of
a
build
up
route
and
for
some
reason
this
is
the
subfloor
definition
which
you
are
receiving.
Data
is
lossy
and
you
want
to
say
okay,
I
think
I
will
open
the
cellular
and
see
if
I
can
continue
my
transfer
on
the
cellular,
and
this
is
the
case
for
the
other
one.
So
next,
so
this
is
kind
of
proposal
like
we.
We
implemented
it
in
a
in
our
technical
report.
J
So
this
is
the
option
we
will
shoot
use
in
the
scene
option
to
create
to
create
quickly
and
user
flow
so
compared
to
the
multi
pass
and
picturing
option
here
are
the
four
you
change.
The
first
one
is
that
we
will
include
the
data
sequence
number,
because
you
you
need
to
know
which
that,
as
you
consider,
the
data
goes
onto.
J
Of
course
you
need
to
add
a
data
level
length
like
in
the
DSS
and
because
of
security
consideration.
You
want
to
adjudicate
in
some
way
your
sub
flowing,
so
you
use
IH
match,
don't
get
it
to
4
bytes.
We
will
discuss
this,
a
factor
that
and
so
to
compute
the
the
H
Mac.
You
can
use
the
token
of
the
connection
and
the
DSN
of
the
data
you
want
to
send
next
and
it's
an
ACK
in
fact
can
directly
send
H
Mac
computed
over
at
the
DSN
and
the
attack
that
that
is
present
on
the
connection.
J
So
next
and
we
are
in
a
similar
way
after
I
think
with
when
you
don't
have
that
that
you
sent,
then
you
use
the
attack
itself
and
you
can
compute
ashmac
using
the
data
and
the
token
of
definition,
and
similarly,
with
with
the
syn
ACK,
we
used
at
the
SN
of
the
fuel.
So
next,
so
of
course
this
introduced
the
critical
Z
direction.
The
first
one
is
that
in
this
in
the
MP,
John
I
think
it's
a
bytes
and
then
20
bytes
of
the
H
max.
J
Here
we
we
shortened,
especially
in
a
the
fashion
out
option
the
H
back
to
4
bytes
because
of
CP
space
tipsy,
be
options
based
on
situation.
Of
course,
we
can
modify
it,
but
this
is
mainly
to
fit
in
the
Linux
implementation
of
TCP
and
as
I,
don't
think
we
we
should
give
our
office
about
sin
we
prior
at
when
you
have
the
DSN,
you
have
the
data,
you
have
the
H
Mac,
so
you
can
replay
the
packet
on
another
subfloor
and
create
additional
sub
floors
with
the
same
packets.
J
If
you
have
seen
this
packet
in
the
network,
which
is
quite
annoying-
and
so
we
can
say,
ok,
the
server
should
limit
the
number
of
supports
that
are
created
for
a
specific
DSN
over
a
specific
connection.
This
is
a
possible
way
of
mitigating
so
next
slide,
and
so
to
conclude,
in
fact,
this
is
a
proposal
to
tune.
J
Will
T
pass
itself
to
fit
a
smartphone
consideration,
because,
because
of
the
case
of
the
cellular
and
and
the
mobile
nature
of
the
smartphone-
and
we
are-
we
actually
implemented
this
solution
with
inside
MP
TCP,
oh
that
91
and
within
Android
1/6
6.1
on
Nexus
5,
and
so
is
there
any
interest
to
follow
up
this
work
at
least
at
the
ITF?
Is
there
a
need
follow-up
for
this
proposal?
This
is
the
main
question,
in
fact,.
F
Hi,
this
is
Maha.
We
are
looking
at
low
latency
applications
for
couple
of
these
cases
in
Fiji
and
related
Phi.
G
requirement
is
1
milliseconds,
but
we
don't
go
that
far.
But
you
know
the
low
latency
is
very,
very
important
topic.
I
just
wanted
to
ask
what
is
the
comparison
after
sub
flow
creation
and
with
your
changes
yeah?
What
is
the?
What
is
the
gain
you
got
with
this
with
your
approach
with
the.
J
J
C
C
J
C
J
In
fact,
the
the
impact
will
be
clearly
visible.
If
you
have
your
main
network,
which
has
low
latency
and
your
additional
network,
which
is
I,
let
and
see,
we
have
a
much
more
much
higher
impact
because
in
fact,
the
time
we
will
have
to
create
your
sub
fro
will
be
saved
somewhere
but
yeah
when,
when
this
is
comparable,
yeah,
the
all
all
is
about
being
a
good
data
detection
system,
which
is
yeah.
We
proposed
one
in
our
work,
but
yeah
yeah.
You
have
Indians
Latin
T
because
of
the
detection
and
yeah
I.
G
G
B
Okay,
thanks
going
to
this,
sounds
like
this
is
something
that
needs
small
time
for
people
to
think
about
and
discuss,
but
I've
taken
the
message
that
we
can
go
ahead
with
the
bits
without
worrying
about
this,
because
it's
something
like
that,
it's
an
extension.
If
that
people
think
that's
wrong,
then
we
need
to
come
to
conclusion
on
it
with
book.
G
G
G
The
draft
MPGs
P
plus
T
fo
has
been
implemented
in
Linux
for
RFC
68
when
t4
by
Gregory
a
few
years
back,
and
it
has
been
used
as
far
as
I
know
by
many
people
when
I
did
the
implementation
of
the
the
base
draft
I
made
sure
that
it
works
with
empathise
p+
t
fo
as
well,
and
in
iOS
we
have
it
invented.
Also,
so
my
request
is
kind
of.
K
Writing
what
so
this
is
Michael
speaking
as
TCP
ensure
I
have
not
ended
multiple
City
for
quite
some
time.
I
just
think
we
have
to
think
in
TCP
M
about
whether
we
should
move
this
at
some
point
in
time
to
standard
strike
and
I'm,
not
sure
if
this
would
be
of
interest
with
the
multi-faceted
City
working
group.
So
far,
TF
always
experimental.
K
K
G
D
It
could
be
in
a
generic,
a
TCP
M
document
where
they
recommend
that,
when
whatever
size
you
do
should
fit
with
the
options
that
you
use
in
the
scene,
because
that's
basically
what
what
needs
to
be
done
and
then
there
is
a
data
sequence
mapping
which
is
very
specific
to
MP,
TCP
and
I.
Think
this
part
should
be
in
the
RFC
68
when
T
for
this
document,
the
cookie
size
is
just
an
implementation
detail
on
a.
A
B
M
K
B
C
B
J
J
A
J
The
in
fact,
the
client
receive
an
eye
before,
but
this
is
only
and
the
commercial
of
the
embedding
of
the
v4
address
into
v6
is
actually
done
by
the
DNS
resolver
at
an
active
form
and
performing
the
commercial
in
the
of
the
address
in
the
Nazis
for
is
probably
a
very
bad
ID
because
we
don't
want
to
have
Middleburg.
Additionally,
the
box
is
doing
funny
stuff
and
you
could
have
additional
program
due
to
the
TCP
or
option
space,
because
I
am
a
PB
six
addresses
that,
rather
than
being
for
others.
J
So
what
we
can
do
instead
is
to
try
the
clan
could
try
to
infer
the
embedding
in
some
way.
So,
for
instance,
here
we
we
are
using
at
the
idea
the
well
no
prefix,
which
is
error.
So
when
we
were
sieve,
an
ipv4
address,
it's
quite
easy
to
try
to
assign
to
that
embedded
address,
and
it's
implementable.
It's
it
was
done
it.
It
works
it's
nice.
The
only
issue
is
that
not
64
can
have
the
window
perfect,
but
also
the
need
for
specific
prefixes
and
the
inferring.
That
was
specific.
J
Perfect
is
quite
art,
and
it's
quite
a
key
in
some
sense
and
may
be
a
way
to
sort.
This
is
to
to
rely
on
a
draft
that
is
currently
done,
which
could
allow
the
that
is
for
2
and
by
Avaya.
Other
idea
should
be
to
communicate
the
embedding
of
the
neva
specific
address.
No,
that
was
with
big
projects
and.
N
N
You
can
see
France
that
an
extension
of
the
defined
for
the
protocol
PCP
that
we
list,
for
instance,
to
forward
to
interact
with
you
not
64,
and
then
you
learn
the
list
of
all
the
prefixes
of
the
nat64
bit,
because
we
may
have
multiple,
not
64
in
path,
and
then
it
gives
the
ability
to
provide
this
kind
of
prefix
to
a
to
the
host.
And
then
you
will
do
the
the
other
synthesis
bit
under
RFC
60
50,
if,
if
it
turned
on
the
house
itself,
so
this
is
a
generic
problem.
N
The
the
DHCP
one
is
not
is
not
an
option,
because
there
is
a
recommendation
from
the
behavior
working
group
to
not
go
with
that
with
that
way.
That
means
that
yeah,
because
various
issues
with
DHCP
itself,
it
does
not
allow
you
to
discover,
for
instance,
if
you
have
multiple,
not
64
in
a
single
network
with
one
single
DGP
option.
We
don't
have
this
limitation
and
there
is
actually
one
RFC
which
go
through
all
this
list
of
alternatives
to
discover
the
prophets
and
the
disappear
option
was
discarded
by
the
behavior
working
group.
M
Through
the
scrubber
track,
I'm
going
to
use
some
strong,
strong
vocabulary
here
so
I
would
like
all
the
miners
in
the
room
to
leave
before
I.
Do
there
is
one
possible
point
of
view
that
nat64
is
a
hack
that
doesn't
belong
in
the
internet
and
I'm
still
hoping
that
more
read
that
there
will
be
some
a
sudden
outburst
of
common
sense
and
people
will
be
using
things
like
map
II
that
don't
have
the
problem.
That
nat64
has
I'm
wondering
about
the
wisdom
to
accommodate
for
nat64
broke
for
nat64,
with
an
MP
TCP.
N
Just
one
quick
command
to
wear
to
jealousy
had
you
you
seed
map,
II
had
not
it
returned
at
in
the
CP
itself.
The
only
difference
there
is
that
there
is
a
fortress
fix
it
not
in
that
CP
and
you
have
the
same
problem
two
two
two
bit
in
for
the
communication
for
a
host
which
located
behind
the
CP.
Even
if
you
have
the
map
in
the
network
side,
so
the
nut
will
be
always
there.
You
have
fair
walls
and
the
problems
are
there,
so
I.
N
Don't
think
this
is
the
opportunity
to
to
to
say
this
is
bad
or
not.
This
is
the
situation
we
have
today
and
the
nat64
is
really
declarant
in
meaning
networks
and
multiple
customers.
Millions
of
customers
are
enjoying
the
service
to
have
the
ipv6
and
the
ipv4
service
continuity,
so
that
you
can
also
join
to
the
majority
of
the
servers
which
does
not
support
ipv6.
So
not
64
is
something
which
is
really
helpful
for
this
for
these
people,
and
this
is
really
a
good,
a
good
problem
to
be
solved.
N
G
Christoph
I
just
want
to
cover
confirm
like
that.
This
is
a
really
big
problem
where
we
am
when
the
device
is
on
an
ipv6
only
network,
and
previously
we
were
on
an
ipv4
only
network.
So
we
only
have
an
ipv4
address.
How
can
you
establish
a
subfloor
over
the
ipv6
only
network
and
we
are
doing
in
iOS?
B
A
B
It
you
know
I
mean
that
sounds
great.
If
you,
if
you
can
go,
is
something
that
people
like
in
the
near
future,
then
that's
that's
great
yeah,
okay,
so
I
think
we've
got
about
one
minute
left
so
I'll,
just
summarize
where
I
think
we've
got
to
today.
So
if
I
remember
right,
we're
going
to
we've
at
least
here
agreed
to
confirm
things,
of
course,
that
the
MP
prior,
which
is
we're
going
to
make
that
modification.
B
And
we're
going
to
try
and
try
and
get
the
bits
in
it,
sort
of
we
thought
it's
been
in
a
stable
state
for
a
while,
but
we
keep
making
the
odd
change
too.
So
when
hopefully
this
will
mean
it
really
will
be
stable
in
the
next
month.
I
guess
all
of
these
bits
of
text
can
be
done
and
then
we're
going
to
work
out
how
to
push
it
up
into
is
G
land
and
wider
review.
We
have
to
do
working
great
last
call
first.
B
I'm
assuming
Mir,
do
you
want
to
make
me
for
closing
comments?
Last
minute,
you're,
happy,
okay,
right!
Thank
you
very
much
to
everybody.
We've
used
to
our
time
up!
It's
the
end
of
the
idea.
Congratulations
see
you
or
hear
you
in
Singapore,
bye,
bye!
Thank
you
for
all
the
good
discussions
and
contribution.