►
From YouTube: IETF104-MPTCP-20190327-1120
Description
MPTCP meeting session at IETF104
2019/03/27 1120
https://datatracker.ietf.org/meeting/104/proceedings/
B
A
Everybody
welcome
to
the
meeting.
Thank
you
all
for
coming.
So
we've
got
a
couple
of
people
who
gonna
take
some
notes,
one
one
offline
and
one
in
etherpad,
but
if
you
can
help
out
in
the
ether
pet,
that
would
be
great,
please
as
I
think
it's
easier
as
a
collective
effort,
so
I'm
Philip,
birdly
I'm,
one
of
the
chairs
of
the
of
the
group
Yoshi
can't
be
here,
but
he's
he's
online
as
well
remotely.
A
If
somebody
can
keep
an
eye
on
jabber,
that
would
also
be
good.
Please
remember
when
you
come
to
the
mic,
to
say
your
name,
preferably
slowly,
so
other
people
can
understand
you,
the
blue
sheet.
We
only
seem
to
have
one
which
is
starting
over
this
side.
Please
keep
it
moving
and
make
sure
it
gets
to
the
to
the
right
or
left-hand
side.
Whichever
way
up
you
are
here's
our
usual
note.
Well,.
A
Here's
the
agenda
for
today,
which
you're
welcome
to
bash
in
terms
of
our
formal
charter.
The
good
news
is
that
the
the
best
document,
our
protocol,
which
is
now
on
the
standards
tracking
the
bist
I've
pushed
the
button
a
little
while
ago
to
send
it
off
to
our
ad,
is
Mia
so
she's
planning
to
review
that
after
the
after
this
meeting
and
then
we'll
find
out
what
she
wants
to
do
with
it.
Next,
but
anyway,
hopefully
we're
not
too
far
away
from
getting
it
into
the
rest
of
the
is
G
and
for
publication.
With
luck.
A
A
So,
in
terms
of
the
agenda,
we've
got
a
normal
kind
of
slot
for
implementation,
use
that
we
we
always
have.
We've
then
got
a
couple
of
talks
about
deployment
news,
so
they
should
be
very
interesting.
So
that's
good.
We've
then
got
three
three
talks
based
on
individual
drafts
and
then
at
the
end,
we've
got
a
discussion
time
to
talk
about
potential
future
future
topics
for
the
working
group.
So
I
guess
this
would
imply
a
recharge
ring.
We
had
a
brief
I'm.
A
A
C
For
open
sourcing,
the
best
implementation
we
re
at
leaves
that
happen
when
I
found
the
approval
to
open
sourced
a
handshake,
and
so
I
will
do
this.
Maybe
it
is
afternoon
when
I
was
tagged
and
posted,
at
least
as
a
request
for
comments
to
the
MPT
speed
developers
mailing
list,
so
we're
getting
closer.
It's
nearly
there.
Is
it
yeah?
No,
it's
just
a
question
of
me
doing
the
posting
after
oh.
A
A
We
have
to
approve
to
open-source
everything
so
what
I
mean-
and
that's
that's
great
news
and
I-
think
it
also
means
that
it
gives
charts
for
more
people
and
see
you
guys
have
tested
it.
All
of
that.
That
gives
an
opportunity
for
more
people
now
to
do
that.
I
guess
we
have
a
small
window
to
if
we
need
any
changes
to
the
best,
any
clarifications
or
whatever,
as
a
result
of
people's
tests,
so
encourage
you
to
to
do
them
as
quickly
as
possible.
Once
it's
available,
it's
great
news.
Thank
you.
C
And
then
for
the
main
learning,
Linux
kernel
efforts,
there's
now
the
open
source
community
that
is
working
on
that
is
growing.
There
are
now
a
few
people
from
Red
Hat
and
a
few
people
from
Intel
working
on
it,
as
well
as
Tess
arrestee
startup
in
Belgium,
and
we
are
making
good
progress.
Some
pieces
for
frameworks
have
already
landed
upstream
a
few
weeks
or
two
months
ago,
or
something
like
that.
So
we
are
making
progress
and
well
eventually,
we
will
be
getting
there
from
the
maintainer
of
the
Linux
kernel.
We
have
the
support
to
do
it.
A
A
D
Sorry
for
my
voice,
which
is
disappearing
next
slide,
please.
So
the
the
objective
of
the
presentation
is
to
give
feedback
on
one
of
the
use
case
for
MP
TCP,
which
has
been
using
MP
TCP
to
deploy
it
I,
real
access
network
that
combine
both
LTE
and
DSL
to
yell,
who
improve
the
bandwidth,
mainly
in
rural
areas.
So
as
an
example,
this
is
a
bottle
that
the
European
Commission
is
publishing,
based
on
the
quality
of
the
access
link
and
the
lighter
the
color
used
in
the
lower
the
bandwidth
that
people
have.
D
D
So
the
the
idea
is
very
simple
and
we
have
been
discuss
it
a
lot
in
the
past.
You
have
TCP
connection
that
go
to
the
hybrid
CPE
that
has
both
a
legal
access
and
it
converts
a
TCP
connection
created
by
the
clients
into
multi
pass
tcp
go
through
a
bit
access
gateway
and
the
average
access
gateway.
I
uses
regular
to
see
between
final
destination.
In
this
example,
the
final
destination
is
ITF
dot.
All
that,
as
far
as
I
know,
does
not
yet
support
multi
path
and
next
slide.
D
So
let
me
just
give
you
some
feedback
on
the
deployment
of
this
use
case,
and
there
are
two
issues
in
this
deployment
that
needs
to
be
taken
into
account.
First
issue
is
what
how
do
we
change
those
TPS
and
what
kind
of
TCP
is
and
that
will
operate
Diplo.
Basically,
what
that
weighted
network
operators,
they
have
to
install
a
multipass,
TCP
participe
proxy
on
CB,
and
we
have
seen
three
types
of
develop
deployments.
D
A
first
approach
is
to
add
the
MPP
mp3
proxy
in
an
exiting
dsl
CP
and
attach
this
existing
DSL
CP
to
an
e
CP,
for
example,
with
a
Gigabit
Ethernet
interface.
The
advantage
of
this
solution
is
that
you
can
reuse
the
existing
series,
but
many
of
the
DSL
CPAs
have
a
low
bandwidth
over
low
and
low
speed
CPU,
and
this
restricts
the
bandwidth
that
you
can
get.
A
second
deployment
is
to
use
a
hybrid
CP
that
combines
xDSL
and
LT
on
the
same
box.
D
Usually
those
boxes
have
a
more
powerful
CPU,
and
so
this
gives
better
performance,
but
the
cost
for
the
network
operator
is
to
replace
all
the
existing
CP
and
the
deployment
that
seems
most
interesting
for
the
network
operator
is
to
keep
the
existing
DSL
CPE
with
a
very
small
modification
that
simply
redirect
a
Petrarca,
TCP
and
put
the
ECB
and
the
two
CDs
are
connected
by
using
Gigabit
Ethernet
and
you
implement
the
new
capacity
proxy
on
the
LTE
sequel.
The
next
line.
D
D
The
client
creates
a
scene
which
is
sent
through
the
hybrid
CP,
so
the
hybrid
CPA
will
convert
the
sin
into
a
Nabi
TCP
scene
with
the
NP
capable
option
it
goes
through
the
hag,
then
the
AG
will
send
us
into
the
final
server.
The
final
server
returns
us
in
trees
act
to
the
hag.
The
act
confirmed
the
establishment
of
the
of
the
connection
from
the
final
server.
Then
it
replies
with
a
simple
act
with
MP
capable
to
the
address
II
and
the
abyss
GPS
and
the
scene.
D
Please
act
to
confirm
the
establishment
of
the
connection
through
the
client.
At
this
point
we
have
three
HTTP
connections,
one
from
the
client
to
the
Hobby
TCP,
one
from
the
bridge
CP
to
the
hag
and
one
from
the
hag
to
the
final
server
and
I
can
send
another
reception
to
advertise
its
IP
address
on
the
LTE
network,
and
at
this
point
we
have
reached
the
peak
and
send
us
interest
and
be
joined
to
create
a
subfloor
roadie.
Lt
interface
is
possible
to
use
both
at
the
SL
n
LT
for
this
DCD
connection
next
line.
D
D
The
IP
packet
by
from
overrules
to
the
LTE
CP
to
the
scene
comes
from
the
client.
It
goes
through.
The
DSL
CP,
the
DSL
CP
forwarded
to
the
LTC,
P
and
L
TCP,
does
the
proxy
and
send
us
interest
and
be
capable
to
the
DHCP
and
the
DSM
CP
for
was
it
to
the
hi,
and
the
advantage
of
this
solution
is
that
all
the
other
packets
are
the
same.
But
the
advantage
is
the
solution
is
that
you
can
leverage
two
more
for
whole
cpu
on
the
l
TCP
and
keep
the
existing
gear
sensor
next
line.
D
D
So,
to
give
you
an
idea,
we
have
run
some
experiments
with
an
off-the-shelf
CPE,
which
is
the
Linksys
1200,
which
is
using
a
nominal
CPU
at
one
point:
three
yards
and
we've
connected
it
to
to
eat
planting
traces,
one
with
20
millisecond
delay
and
the
other
is
between
20
50
or
80
millisecond
delay,
because
we
know
that
for
an
PCP,
but
difference
in
delay,
I
can't
think
of
a
comment.
So
we
try
to
deal
with
the
total
bandwidth
that
mere
people
to
be
connection
from
the
client.
D
So
the
the
measurements
on
the
x-axis
you
have
the
total
bandwidth,
which
is
the
film
of
the
DSL
and
LT
links,
go
from
16
to
megabits
per
second
to
one
gigabits
per
second,
and
you
have
three
curves
that
indicates
the
total
value
is
that
we
can
get
so
about
500
megabits
per
second.
There
is
no
impact
of
the
difference
in
delay
between
the
DSL
and
the
LTE
network
and
yielding
both
favor
and
megabits.
There
is
a
small
difference
and
the
higher
the
difference
in
delay
the
lower
the
throughput.
D
D
So
the
second
point
is
the
hybrid
access
gateway,
so
there
are
two
different
deployment
models
for
this:
IPL
access
gateway
that
terminates
the
MP
TCP
connection
in
the
operators
network.
So
one
approach
is
to
use
a
centralized
average
average
access,
the
gateway.
If
the
DSL
and
the
LTE
network
converge
only
in
the
backbone
of
the
network
operator
and
typically
you
would
have
a
large
Hagee
in
this
case.
D
If
you
have
a
network
where
the
GS
hadn't
had
a
network
or
a
share,
multiple
locations,
for
example,
use
the
same
pubs
then
is
possible
to
do
the
to
implement
the
hag
very
close
where
whether
to
medical
school
are
present,
and
you
can
run
the
tag
on
that
it
is
fixed
inside
the
virtual
machine.
The
next
gives
you
an
example
from
one
deployment,
so
that's
a
hag
which
is
played.
D
So
this
is
a
hag
that,
during
this
measurement
was
serving
about
7,000
users,
so
in
during
peak
time
it
had
about
200,000
multipass,
TCP
connections
that
were
active
and
we
saw
about
6000
or
7000
and
PHV
connection
being
established
every
second
and
what
we
see
on
the
bottom
curve
is
that
the
total
throughput,
which
is
the
green
curve,
the
top
green,
the
largest
green
curve,
the
throughput,
which
is
10
gigabits
per
second.
This
is
mainly
incoming
traffic,
so
traffic
coming
from
the
internet
to
the
study
s
mcps.
These
are
home
users.
D
So
this
is
not
surprising
and
then,
if
you
look
at
the
the
two
of
the
curves,
the
two
blue
curves,
we
see
that
in
this
deployment,
the
DSL
and
the
healthy
network
use
every
about
the
same
amount
of
traffic.
Although
the
LTE
network
has
much
more
capacity
than
the
DSL
network
and
network
operators,
they
try
to
first
feel
myself
I
and
then
move
traffic
to
the
LT
Network.
D
Only
when
this
is
required,
feedback
from
users
is
very
positive
and
when
looking
at
the
cpu
load,
you
see
that
twisting
gigabits
per
second
the
cpu
load
is
not
more
than
25
percent.
Next
slide,
I
think
it's
the
last
one,
so
we
can
say
that
multiple
CCP
rings
and
benefits
for
I
will
access
network
and
it
can
boost
internet
access.
D
There
are
different
deployment
models
for
CPS
and
for
hugs,
and
maybe
one
interesting
point
for
the
working
group
is
that
the
work
on
MPDC
proxies
that
we
did
in
the
past
in
this
working
group,
and
then
that
worked
to
the
TC
p.m.
working
group,
which
is
now
the
controller
protocol
has
been
accepted
by
the
algae
by
3gpp
to
provide
access
project,
steering
switch
and
splitting
for
5g
networks,
and
so
we
might
see
a
growing
number
of
MP
TCP
based
services
in
5g
networks
as
well.
Thank
you,
I
see.
It
was
the
last.
E
D
So
so
you
can.
The
converter
is
a
decision
that
you
can
take
many
for
the
hag,
not
for
the
CP,
so
on
the
CPU
use
a
transparent
proxy,
because
the
CPE
sees
all
the
traffic
and
then
it's
a
decision
of
the
network
operator,
whether
you
use
a
hag
with
a
transparent
deployment
or
hacked
with
the
convertor.
So
there
are
advantages
and
drawback
with
both
solution.
Depending
on
how
the
network
is
organized.
E
Thank
you
so
another
question
with
regards
to
the
converter:
do
you
think
extending
the
converter
to
support
like
policy
decisions
such
as
the
scheduler
policy
can
can
be
added
to
the
tcp,
I'm
converter?
They
think
it
makes
sense,
because
right
now,
the
way
I
see
it.
There
is
no
way
to
control
the
policy
from
the
shattering
policy
that
can
be
used.
Oh.
F
F
Second,
few
Corrections,
at
least
if
you
are
considering
the
BBF
for
deployment
scenarios
in
the
context
of
the
5g
based
on
the
current
agreements
in
the
3gpp.
None
of
the
deployments
that
you
show
are
actually
going
to
happen
in
the
release.
16.
We
only
have
a
multipath
tcp
proxy,
which,
for
the
BBF
opana
bees
a
hug
and
not
on
the
CP
part.
F
In
your
particular
figure
that
you
put
it,
it
is
not
fully
finalized
for
BEF,
but
that
is
overall
intention.
Okay
and
the
last
messages
you
already
put
the
draft
IDF
the
CPM
converters
from
the
free
GP
perspective.
This
one
would
be
the
first
half
because,
frankly,
we
do
have
a
dependence
now
on
this
particular
draft.
Yes,.
G
D
G
G
G
Yeah
and
the
last
point
I
want
to
make
is
so
we
started
telecom
at
the
hepatic
source,
a
little
since
several
years
in
Germany,
but
also
now
we
are
working
on
having
this
to
deploy
this
in
all
of
our
footprint
and,
as
you
know,
I
think
we
have
a
cheery
approach
to
cover
the
IP
yeah.
We,
the
IP
traffic
in
Sonora
and
I,
think
multiple
TCP.
G
It
serve
as
a
good
alternative
for
Hyper
taxes,
but
with
the
increasing
traffic
we
have
also
to
cover
or
yeah
we
have
to
handle
this
somehow
and
from
an
operator
perspective
I
think
it's
not
a
solution
to
just
cover
the
TCP
traffic,
because
if
you,
if
you
want
to
design
some
tariffs,
maybe
which
includes
the
the
hyper
taxes
benefit,
then
you
can't
explained
to
a
customer
that
only
TCP
services
can
benefit
from
from
from
hyper
taxes
and
that's
why
we
propose
to
establish
somehow
a
multi-party
UDP
to
complement
the
multipass
tcp.
In
that
sense,.
D
I
hear
that
I
see
that
if
you
look
at
PBF,
so
BBFS
agreed
to
do
both
the
GRE
approach
and
the
NP
tcp
approach,
and
we
will
see
what
operators
will
deploy
some.
There
are
deployment
of
both
solutions
and
for
quick,
and
we
will
see
once
quick
is
finalized.
What's
the
how
it
can
support
it
over
multiple
paths
correctly
well,.
A
G
F
F
D
G
And
create
problems,
I
think
Marcus.
Speaking
again,
one
or
two
years
ago
there
was
a
discussion
on
the
multiple
TCP
mailing
list
about
that,
where
someone
tried
to
encapsulate
a
UDP
traffic
to
send
it
over
multiple
TCP,
and
it
was
agreed
that
this
is
not
a
good
design
decision
and
yeah.
The
other
performance
like
at
the
end.
H
Okay,
much
better
right,
so
IRA
talked
about
multi
pass
transfer,
departmental
smartphone
applications.
My
name
is
Hauser,
and
this
is
a
joint.
What
we
saw
highway.
Pork,
research
lab
and
the
consumer
software
team
in
this
talk
have
account
for
parts
first
of
what
has
been
done
and
lessons
we
learned
and
the
issues
we
found
and
concluded
by
some
thinking
about
future
work.
H
To
start
with,
we
deploy
MPD
Espeon
on
a
we
21
of
the
flagship
products
of
our
honor
brand.
Since
this
January
and
up
to
now
around
several
applications
has
been
labeled
and
more
are
coming,
and
we
make
it
happen
by
through
the
direct
collaboration
with
the
third-party
mobile
applications
and
cloud
and
CDN
providers,
and
we
will
leave
the
decision
to
attain
down
off
to
users
who
are
you
icon,
network
acceleration
in
the
system
settings
and
the
addition
to
MPD
SP?
H
We
also
support
MP
UTP
or
he
might
pass
through
users
face
networking
to
complement
the
scenarios
where
applications
only
use
you
to
be
flows,
and
although
the
above
scenarios
is
only
only
operating
in
China
geography,
now
we
are
trying.
We
are
working
hard
to
bring
somewhere
else
and
in
the
current
deployment,
our
product
team
pays
a
lot
of
attention
to
the
scenarios
that
may
be
intuitively
be
benefited
by
coupling
Wi-Fi
and
LTE
together.
H
The
first
case
we
look
at
is
the
video
downloading,
because
in
Chinese
in
typical
Chinese
reo,
the
application
there's
a
feature
supporting
the
user
to
buffering
the
video
content,
so
that
can
view
them
offline
and
in
this
narrow,
if
the
user
can
coupling
Wi-Fi
and
LTE
together,
they
can
push
their
downloading
speed
and
the
other
use
case
is
mobile,
live
video.
In
this
case,
the
user
experience
may
be
improved
in
broken
and
weak
Wi-Fi
scenarios
and
the
other
very
important
use
case
is
mobile.
H
H
In
general,
we,
the
user
experience,
has
been
improved.
For
example,
the
in
video
downloading,
the
speed
has
been
accelerated
in
general
and
also
for
the
live.
Video
live
video
case
and
also
the
unlike
game
in
case
the
experience
has
been
improved
in
the
run
any
task
in
congested,
but
we
still
meet
some
counterproductive
cases
where
improvement
is
not
visible
and
we
are
working
hard
to
work
around
that
and
for
that
we
are
because
we
just
deployed
that
since
this
generally,
we
keep
collecting
user
feedback
on
this
feature.
H
Those
features
so
in
the
there
are
two
flavors
in
the
current
deployment.
First
one
is
the
director
end-to-end
MPDC
conversation
where
we
provide
SDK
to
application
developer
so
that
we
can
clue
the
application
stack
to
the
MP
TCP
stack
and
also
we
provide
necessary
info
guidance
for
the
cloud
infrastructure
if
they
need
any
guidance
there,
and
the
second
case
is
MPT
Sui
proxy.
Well,
we
are
working.
H
The
smartphone
people
told
us
that
the
simultaneously
use
of
multiple
link
without
user
permission-
it's
not
a
good
idea
at
all,
and
your
user
will
definitely
complain
about
that,
and
also
the
network
people
told
us
that
the
meter
box
is
not
ready
and
the
roaming
service
over
split
paths
is
very
hard
to
operate
and
also
the
mobile
application.
On
the
other
hand,
I
infer
upgrade
if
the
user
experience
can
be
improved,
otherwise
any
upgrade
to
their
cloud
infrastructure
couldn't
happen
any
sooner.
We
take
some
steps
to
overcome
these
issues.
H
First
of
all,
we
design
a
special
UI
to
allow
user
up
in
explicitly
so
that
will
get
shifted
choice
to
the
users
and,
secondly,
we
we
notify
the
any
data
usage
over
the
meat
of
the
link
so
that
the
people
can
be
a
well
that
container
of
he
that
don't
like
it
and
also.
But
we
believe
that
this
is
less
than
you
should,
because
the
data
plan
keeps
becoming
cheaper
and
for
the
networking
issues
we
we
just
found
that
some
force
has
been
taken:
special
care,
for
example,
for
8
80
and
80
80.
H
It
has
much
higher
success
rate
than
the
are
pores,
and
also
you
in
the
host
case,
then
mid
box
is
very
unfriendly
to
MP
TCP
session.
We
make
sure
that
we
can
failover
to
this
regular
TCP
quickly
and
for
the
mobile
application
side.
We
believe
at
this
point
in
time
is
very
it's
very
crucial
if
we
can
work
closely
with
the
mobile
application
vendors
so
that
we
understand
their
scenarios,
we
try
to
persuade
him
to
update
MP
DSP
on
small
set
of
use,
case
first
floor
and
trying
to
explain
to
others
in
the
long
run.
H
H
So
if
he
for
MPD's
we
as
in
a
life
to
figure
uShip,
it
shows
that
if
MPD's
become
actually
major
league
comes
consist
of
downstream
flows
and
one
Lincoln
is
one
pass,
is
tour
and
one
the
other
wine
store
free.
It's
very
important.
The
user
generally
requires
that
more
data
scheduled
to
the
tour,
a
link
and
then
overflow
to
the
top
hauling
right
so
to
the
meter
link.
H
But
the
issue
here
is
that
cross
I
doesn't
have
any
information
about
which
pass
is
Tory,
which
is
not
and
or,
and
also
by
using
the
current
divorce
schedule
more
data.
We
have
the
schedule
which,
with
a
meter,
link
of
this
quicker
and
the
channels
here
that
there's
no
way
in
the
currents
back
to
mark
the
fine
current
program.
You
know
flows
other
than
backup
it,
and
also
the
client,
doesn't
have
any
fine
current
control
over
the
scheduler.
You
said
the
server
the
other
side,
so
luckily
this
has
been
discussion.
I.
I
H
H
I
H
I
So
so
you
know
the
congestion
window
will
close
on
that
path,
right
and
and
that
will
that
will
prevent
the
use
of
that
path
pretty
effectively.
If
you
keep
sending
a
bunch
of
CES
anyway,
you
should
investigate
this
I,
because
I
think
there
is
actually
fine-grained
stuff
that
would
apply
here
and
what
work
and
and
we
don't,
and
so
you
might
need
a
mechanism
at
the
MP
TCP
level,
because
you
have
a
mechanism
at
the
IP
tell.
J
K
L
H
I
G
An
inverted
cone
so
in
general,
this
question,
which
was
put
here
to
exchange
policies
between
multiple
TCP,
client
and
server,
has
to
be
discussed
in
and
I
think
that
also
some
conclusion
of
multiple
TCP
side
meeting
here,
because
maybe
you
can
solve
the
specific
issue
with
priority
scheduling
but
ECM
but
amateur
at
all.
But
there
are
also
some
some
other
use
cases.
H
H
I
Machinery
that's
available
instead
of
inventing
new
stuff
right
in
negotiating
policies
inside
TCP.
Please,
let's
not
do
this
right,
I
mean
I.
It's
very
clear
that,
unlike
on
the
extreme
end
of
be
very
disappointed
of
MPDC,
be
turning
into
a
proxy
solution
for
operators
right
so
this
is.
Everybody
should
be
clear
that
this
is
where
I'm
coming
from
right,
but
it's
it's
just
nuts
to
do
this
at
this
level.
Please,
let's
not
do
this
yeah.
N
I
N
Yeah
before
deciding
whether
we
need
to
do
it
or
not,
I
think
we
need
first
to
understand
the
problem
here.
So
basically
the
one
one
simple
problem
is
when
you
have
for
us,
as
volume
could
on
some
subscription
from
from
the
users
and
the
server
doesn't
know.
If
there's
any
I
would
say
imitation
of
the
of
the
data
which
is
sent
by
some
Sun
Network.
N
So
if
the
server
just
burned
here
or
I
would
say
a
randomly
selected
are
given
a
network
attachment
and
sent
all
the
data
through
that
path,
the
subscriber
will
find
himself
at
the
end
of
the
day,
only
single
single
attached,
so
the
we
are
losing.
If
there's
a
policy
wishes
I
would
say
not
that
well
implemented
in,
for
that
the
server
will
end
up
with
a
customer
which
is
single
attached
and
not
multipath
anymore,
because
we
ditch
the
Dakota
on
sunset,
scription,
so
I
think
that's
yeah.
N
We
need
to
understand
we,
the
the
problem
of
the
policy
here
we
are
sitting
about.
Is
it
without
any
finer
note
and
part
about
my
preference
in
the
way
it
will
in
Jeju
traffic
to
my
network
attachment?
Is
it
this
is
what
we
are
talking
about,
or
something
else
I
think
that's
the
congestion
and
the
polity.
Distribution
is
not
the
same
in
this.
In
the
same
level,
we
need
to
distinguish
them
and,
let's
try
to
understand
the
problem
before
deciding
or
discarding.
A
The
EDD
point
so
we're
kind
of
getting
into
the
discussion
we
were
gonna
have
lighter
but
I,
don't
mind.
Okay,
that's,
okay,
so
I
think
something
that
came
out
on
Monday
and
from
the
last
five
minutes
to
me
is
that
we
need
people
to
write
down
what
the
problem
is
that
they're
trying
to
solve
without
writing
down
an
attempt
at
a
mechanism
to
solve
the
problem.
Yeah.
A
You
know,
we've
the
last
five
minutes:
we've
we've
we've
tried,
we've
been
trying
to
do
both
simultaneously.
Were
people
saying
here's
the
problem,
here's
a
solution
know
that
solution
is
not
good
enough.
This.
The
mechanism
I
would
like
to
use
to
solve
the
problem
that
let's
work
out,
the
problem
is
accurately
first
all
the
problems,
because
people
mention
all
sorts
of
things
and
I
think
that
would
be
really
helpful
because
I
know
there
are
people
who
one
who
think
it's
important
to
solve
particular
problems.
A
But
we,
you
know
when
we've
had
the
discussion
before
we've
ended
up
in
the
position
where
we've
not
come
to
any
agreement,
any
mechanism
to
add
and
I
think
that's,
because
we
haven't
had
proper
agreement
problem
and
we've
been
trying
to
do
two
things
at
once.
Talk
about
problems
and
mechanisms,
so
I
think
you
know
I
said.
H
Continue
the
discussion
on
the
Menem
is
because
there
already
has
been
discussed
and
a
lot
of
people
raise
this
issue
and
we
can
see
how
how
we
handle
is.
We
can
just
close
this
or
we
can
just
to
go
along
with
always,
and
the
only
issue
is
aggregation
perform
is
to
be
simple
because
when
use
are
using
Martina
pass,
we
also
generally
in
spread
that
it
performs
better
than
any
single
pass
and
the
problem
is
that
a
call
if
the
to
Co
the
quality
were
to
pass
the
pass
will
meet
his
charter.
H
The
aggregation
transmission
is
less
efficient
than
the
best
available
pass
along,
and
we
know
this
is
a
hard
problem
and
because
the
first
pass
is
not
fully
utilized
in
this
new
regime
and
spend
a
lot
on,
but
not
on
time,
waiting
for
a
slow
one.
It's
no
one
and
also
sending
on
the
loss
in
linking
the
sacrifice
of
the
opportunity
in
sending
them
faster
link
and
around
the
issue.
There
are
many
academic
work,
but
unfortunately
long
term
has
been
standardized
or
generally
proof
solid,
so
I
think
I,
don't
know,
have
an
answer.
H
H
If
this
am
ice,
float
and
Pt
speak
a
notochord
RTP
of
the
news
flow
I'm
used
to
sacra,
because
there's
no
data
or
flow
to
that
flow
and
how,
for
example,
in
this
figure,
if
the
if
the
Wi-Fi
becomes
weak,
how
does
the
crime
knows
meeting
LTS
useful,
not
is
better
or
worse
and
equally,
when
the
Wi-Fi,
when
the
clients
are
using
only
using
the
LT?
H
The
problem
here
is
that,
for
example,
on
the
figure,
if
the
client
and
cloud
side
has
true
idea
to
assign
from
different
ISPs
a
and
B
the
the
if
the
surf
loss
is
trapped
between
the
IP
address
or
cost
even
highest
piece,
this
Robbie
without
including
subordinate
formance,
and
it
much
better.
If
we
can
do
it
like
to
make
sure
that
the
IP
address
from
the
same
ISPs
were
parallel
to
correctly.
H
F
I
Could
you
go
to
pack
your
last
slide,
this
one
yeah?
Thank
you
last
I
grade
again,
so
I
I
would
actually
suggest
that
this
is
not
a
problem
that
we
need
to
deal
with,
because
so
naturally
the
scenario
on
the
right
should
be
the
one
where
those
two
paths
see
much
better
performance
than
the
other
two
paths.
So
even
if
all
four
are
tried
right,
that
the
traffic
should
sort
of
naturally
be
on
paths
that
that
go
through
the
same
operator,
Network
and
and
whatever
mechanism
you
have
to
not
transmit
a
lot
of
data
down.
I
Lousy
paths
should
already
get
you
into
the
situation.
If
you
are
in
a
situation
where
the
one
on
the
left
actually
gets
declined
better
performance,
so
be
it
right
that
I
would
I
would
not
understand
how
this
is
possible,
but
I
think
the
other
mechanisms
that
you
have
described
already
solve
this
and
we
might
not
need
something
special
for
this
case
and
once
sorry
I
didn't
get
your
point.
I
So
you're
saying
you
want
to
go
a
to
from
the
left
to
the
right,
and,
and
so
you
would
like
a
mechanism
to
to
not
have
the
client
not
even
try
to
establish
these
cross
ISP
flows.
What
I'm
trying
to
say
is
these
cross-ice
P
flows
should
have
much
worse
performance
than
the
flows
that
stay
within
one
ISP
and
since
you
already
need
a
mechanism
to
to
push
the
traffic
to
the
better
flows.
That
was
your
previous
slide
right.
As
for
the
loan
Athens,
you
want
it's
a
store
traffic.
I
H
H
I
L
H
I'm
going
about
the
connections,
tab,
which
is
a
important
component
for
both
high
school
and
the
known
agency,
and
if
the
initial
pass
you've
broken,
the
connection
will
fail
and
the
capacity
is
low,
see
the
or
repair
performance
will
be
degraded,
and
there
are
some
solution
document
well
by
the
lobby.
Solution
from
the
telecom
expert
and
I
were
not
car.
Much
of
about
that,
but
my
contingent.
We
also
occur
to
talk
about
the
need
of
to
couple
with
the
Robbie.
We
say
initial
person
action.
H
F
H
H
A
H
N
N
Okay,
company
must
of
law
is
initiated
in
the
past,
which
is
decided
by
the
default
and
after
success.
The
other
Assam
floor,
where
we
set
up
a
mobile,
for
example,
as
we
know
at
the
mr.
two
scenarios
here
with
some
program
using
current
or
scheme
the
first
one,
the
first
one
if
interested
flow
cannot
be,
cannot
be
establish
a
flow
when
the
matter
pass.
There
won't
be
connectivity,
even
if
you
pass
is
available,
and
the
second
or
second
diagram
is
the
issue.
N
N
N
N
We
propose
this
is
why
we
propose
the
logical
initial
pass,
the
selection,
this
initial
pass.
The
selection
selection
esteem
can
work
together
with
the
timer
pace
of
the
sorta
like
starin
at
the
beginning
as
a
row
beginning
camera-based,
the
solution
is
using
a
steer,
but
when
some
information
gets
occurred
already
the
battery
initial
path
can
be
selected
directory,
then
timeout
and
even
see
where
disappear
like
this
time,
one
also
mobile
phone
tag,
one
where
shoe
the
shoe
the
benefit,
it's
our
expectation.
Well,
you
shall
pass
selection
scheme
use
it
only.
N
H
P
P
N
Therefore,
it
can
be
shared
by
the
collection,
either
same
collection,
same
application
or
different,
accomplish
different
application
and
the
lagg-3
run
the
triptan
lose
rate
and
the
RTO
even
is
a
local,
too
easy
application,
and
then
we
think
it's
much
more
suitable
to
be
shared
within
one
sim
application
and
the
next
one
is
economy
attribute.
We
think
this
new
logical
may
cost
them
more
than
the
default
one.
So
it's
better
to
to
introduce
some
country
from
the
user.
Therefore,
we
think
we
can
provide
or
no
API
for
a
user
to
control.
N
F
Our
SSI,
it
is
not
enough,
it
is
using
the
context
as
a
server.
If
you
want
to
use
signal
strings,
you
may
also
consider
information
regarding
to
the
interference
level.
Yes,
also
in
the
context
of
using
Wi-Fi,
you
already
have
defined
in
Wi-Fi
global
metric,
practically
being
capable
of
providing
you
information
of
achievable
data
rate
over
different
type
of
access
classes,
which
may
be
a
suitable
metric
to
be
generically
if
you
really
look
start
looking
into
metrics.
O
Q
Yes-
and
this
moment,
Chris.
C
Christophe
I
just
want
to
know
to
say
that
the
selection
of
the
initial
interface
for
starting
a
connection
is
really
big
problem.
It
has
a
big
impact
on
the
performance,
but
it
is
independent
from
MBT
CP.
It
is
for
TCP
quake,
MP
TCP,
it's
the
same
problem,
so
we
have
to
think
about.
If
you
want
to
bring
about
the
solution,
try
to
not
design
it
for
MPSP.
Only
because.
J
I'm
Stuart
Cheshire
from
Apple
I
think
I
was
thinking
very
much
the
same
as
Christoph.
He
beamed
me
to
the
microphone.
I
was
surprised
in
your
presentation.
I
didn't
see
any
mention
of
happy
eyeballs,
because
this
sounds
exactly
like
you're
describing
the
happy
eyeballs
problem
in
the
very
narrow
scope
of
only
applying
it
to
multipath
TCP.
J
So
if
you're
not
aware
of
that,
you
should
look
at
the
existing
RFC's
on
on
dealing
with
this
problem,
because
this
is
something
that
has
been
I.
Don't
know
can't
speak
for
Android,
but
on
iOS
for
many
years
on
your
phone.
If
you
have
Wi-Fi
and
cellular,
then
it
will
try
to
choose
which
one
is
working
best
with
the
preference
for
Wi-Fi
you
talk
about.
The
users
may
not
want
to
use
mobile
data.
There
is
a
switch
in
the
settings.
It's
called
Wi-Fi
assist
that
lets
user
control
this.
H
To
Christophe,
yes,
this
should
be
a
general
solution,
not
only
for
MP
DSP,
so
there
luckily
Spencer
has
so
would
like
to
or
guys
some
sign
meetings
on
the
P
IPC,
which
is
a
performance
implementation
implication
of
the
pass
characteristics.
This
sustained
I'd
assume
we
can
have
more
discussion
there.
G
P
Well,
I
just
want
to
make
a
very
quick
point,
Stewart's
point
on
happy
eyeballs.
We
had
looked
at
it
in
the
past
and
one
of
the
problems
with
it
and
we've
discussed
this
in
some
previous
IETF
s
was
because
of
the
keying
material
in
the
initial
exchange,
but
replay
attacks
to
worry
about
in
MB
TCP,
which
make
the
happy
eyeballs
approach
slightly
less
easy
to
use
and
in
the
intimate
a
scenario.
P
N
I
believe
it's
new
skin
initial
plan
selection
is
an
issue
need
to
be
addressed
even
if
can
be
made
at
this
local
information
in
the
way
suggest
an
information
document
along
the
pasture
practice,
and
maybe
some
more
extended
yeah,
so
example-
to
provide
the
interface
for
user
control.
You
need
also
a
single
it's
all.
Thank.
A
R
R
R
So
moment
a
Linux
MPT
CP,
it
already
support
framework
to
support
different
measure
that
base
our
net
link.
It
is
allowed
to
use
allow
user
to
write
the
part
manager
in
the
control
plane
in
the
user
space.
It
provide
a
clean
layer,
but
it's
not
with
our
issues.
Thirty's
Netley
messages
may
be
lost
and
it
may
need
different,
separate
facilities
to
support
various
features
but
may
be
necessary
features
like
we
need
to
get
different
information
from
subfloor
level.
We
might
need
to
get
the
notification
from
the
DCP
state
change
all
week.
R
N
R
R
So
I'll
to
type
with
EB
PF
for
three
minutes.
The
first
is
to
track
the
event
we
used.
The
new
we
create
a
new
TCP
BPF
comebacks,
so
is
on
the
DSP
BPF
in
the
mainstream
Linux
by
Lawrence
Patmore,
and
it
already
provide
different
hook
at
four
different
Fraser
participe
connections
or
when
the
connection
state
changed
it
allowed
to
read
or
write
to
many
fields
of
TCP
stock,
directly
or
indirectly.
R
R
There
are
many
open
issues
now,
with
current
prototype,
the
main
is
used
how
to
handle
the
event.
The
local
IP
address
changed
because
the
TCP
BPF
is
based
on
the
C
groups.
So
the
scope
of
the
BPA
program
is
the
C
group
and
let's
say
that
we
had
many
C
groups,
then
we
need
to
send
the
event
to
multiple
Pierre
program
on
each
secret.
R
R
R
The
the
next
thing
is
at
the
moment
it
only
support
ipv4,
but
to
implement
the
do.
Instead,
support
is
not
too
difficult
because
they
already
other
happy
function.
Do
that
and
the
last
thing
is
currently,
it
does
not
support
multi-part
manager,
for
example,
if
you
want
to
have
a
different
path
measure
for
different
network
namespace.
So
that's
the
nother
issues,
but
is
not
immediate
one,
so
next
slide
so
next
slide.
Okay,
so
to
conclude,
the
EBP
make
it
easier
to
extend
Linux,
NP
TCP,
so
with
good
performance.
R
R
A
S
S
So
one
question
was:
what
is
the
impact
on
the
NPDB
protocol
so
now
the
draft
is
really
really
focusing
on
end
to
end
issues
impacting
the
with
potential
impact
on
the
MP
TCP
protocol,
and
also
some
ideas
for
alternative
solutions
were
provided
and
they
are
in
the
they
are
presented
in
the
draft.
That's
a
client
driven
solutions,
approach
that
we
will
have
later
so
as
a
summary
of
changes
quickly.
We
only
kept
Federation
portunity
related
text,
the
local
impacts
on
the
client.
S
Potential
issues
I
mean
basically
that's
issues
which
are
impacted
by
the
behavior
of
the,
because
the
remote
peer
is
not
aware
that
an
IP
address
replaces
another
one.
It's
just
a
new
IP
address
and
so
potential
issues
will
be
identified.
We
will
list
them
in
the
next
slide
and
several
alternative
approaches
are
also
listed,
and
this
end-to-end
issues
should
apply
when
MPTP
is
used
between
the
4G
device
and
an
mp3,
P
server
or
proxy.
S
So,
just
to
recap
what
was
presented
in
Montreal
quickly,
in
fact
recession.
Continuity
is
only
in
sociology,
is
not
hidden
from
the
MP
TCP
stack,
at
least
in
some
cases.
So
when
both
mobility
support
and
maintaining
low
latency
are
needed,
Virgie
will
use
a
distributed
mobility
solution
either
in
make
before
breakup
break
before
make
mode,
and
in
these
cases,
given
connection,
will
appear
as
a
succession
of
IP
addresses
when
the
device
changes
anchor.
S
Mp
TCP
may
switch
back
and
forth
between
backup
and
active
sub
flows,
so,
instead
of
waiting
for
the
break
before
make
transition
to
complete,
so
that
may
be
unwanted
behavior
that
we
have
an
impact
on
battery
usage,
for
example,
so
in
terms
of
alternative
approaches.
So
the
first
approach.
Since
these
are
not
breaking
issues,
you
could
just
keep
using
MPT
MPT
unmodified
and
then
look
at
the
real
effect
on
real
applications
and
take
it
from
there.
A
second
approach
would
be
to
use
a
client
driven
behavior
in
this
case.
S
A
few
changes
to
the
could
enable
the
mobile
client
to
drive
the
remote
peer.
So
you
could
gracefully
close
the
sub
flow.
That
would
help
with
the
first
issue
and
you
could
specify
the
timer
for
the
backup.
That
would
be
basically
help
for
the
second
issue
that
basically
behavior
that
was
provided
at
in
Montreal
and
then
the
last
approach
would
be
to
have
the
client
communicates
session
continuity
information
to
the
remote
peer
when
adding
either
implicitly
or
explicitly
an
IP
address.
S
M
S
What
you
can
basically
transfer
transfer
of
MPCP,
that
would
be
the
session
continuity
IP
address
type,
let's
define
in
DMM
and
that's
used.
You
know
that's
that
as
a
one-to-one
mapping
to
session
cochinita
modes
into
HPP,
but
that
could
be
also
applied
to
other
types
of
session
continuity,
and
you
would
also
provide
the
original
IP
address
index.
I
think
after
you,
you
have
a
range
of
other
solutions
that
you
could
have
in
between,
because
actually
all
of
these
related
IP
addresses
could
also
be
inside.
S
S
What
has
been
discussed
so
far
and
our
goal
was
we
to
provide
something
useful
that
would
help
future
work
in
this
area
in
thermal
future
work
in
if
the
working
group
decides
to
describe
path
management,
for
example,
that
you
know,
maybe
that
could
provide
some
input
to
that
to
that
draft
and
also,
as
FFG
networks,
become
more
available
to
experiment
with
the
real
applications.
It
will
become
possible
to
further
validate
and
complete
this
analysis.
So
actually,
I
would
like
also
to
propose
adding
this
5g
session.
F
Yes
of
your
another
scope.
Welcome
several.
If
you
use
country
motion
first
of
all,
release
16
in
a
TSSs
study
item
in
no
work
item
introduces
the
notion
of
a
multi
access
pdn
for
the
ones
which
are
not
familiar
with
VPP
terminology
opinion.
It's
a
physical
network,
for
example.
Your
handset
device
connects
at
least
to
an
ims
network,
which
provides
a
new
services
and
the
internal
network
just
technology
release.
F
Second
thing:
practically:
what
are
we
trying
to
achieve?
You
had
a
comment
earlier
that
the
terminal
device
may
not
be
able
to
identify
a
particular
address
that
it
is
new
if
it
is
associated
to
the
previous
address.
This
is
also
another
case,
because
every
single
terminal
would
gonna
know
their
current
address
if
it
is
associated
with
four
cell
love
or
Road
double
on
axis.
S
Okay,
actually,
the
the
client
knows
that
you
have
a
position
committee,
so
you
will
need
to
have
some
form
of
support
in
the
path
manager
in
the
client
kebab',
because
when
an
IP
address
replaces
another
one,
the
first
one
is
a
backup.
The
next
one
should
be
also
a
backup,
for
example,
so
you
have
like
a
continuity
of
policy
that
you
need
to
have
so
the
client
is
aware
of
this
continuity
between
IP
addresses
and
the
remote
peer
is
not
aware
of
that.
S
Because
the
peer
doesn't
know
about
this
relationship,
so
you
have
either
that's
why
you
have
several
solutions:
either
you
ignore
the
problem
and
basically
you
may
get
some
performance
issues,
but
nothing
braking
seemingly
or
you
can
have
the
client
which
knows
about
the
continuity
aspect,
basically
tell
the
server
do
these
do
that
you
know
basically
control
the
server
so
that
performance,
no
good
performances
can
be
maintained
or
you
can
tell
the
remote
peer.
Actually,
these
addresses
are
related
to
each
other,
and
this
one.
S
That's
this
type,
that's
persistent,
so
you
can
expect
it
to
go
out
and
to
be
replaced
after
a
break.
So
you
see
you
have
different
strategies
you
can
have,
and
that's
I
mean
that
may
be
more
okay
with
respect
to
the
proxy
I'm,
not
sure,
but
my
understanding
is
that
the
fact
that
you
use
a
proxy
or
not,
basically,
you
have
this
type
of
you
have
this
problem,
because
the
proxy
is
acting
as
a
form
of
several
from
your
standpoint.
So
that
was
basically
the
approach.
S
S
Not
really
I
mean
that's,
that's
one
possible
issue,
but
yeah.
We
were
careful
to
just
try
to
expose
the
problem
and
then
gather
solutions.
So
that's
why
you
have
the
solution
where
the
client
tells
the
server
or
here
I
close.
This
I
closes
this
supply,
gracefully
so
that
there
is
no
nasty
or
like
you
don't.
M
S
S
The
second
solution
would
be
to
transmit
that
right.
I
think
there
is
maybe
even
a
third
solution
in
between
where
you
group
the
addresses
you
say:
well,
Google
Siro,
that's
my
you
know,
that's
all
addresses
which
are
related
to
each
other,
but
you
don't
necessarily
give
the
type.
So
you
have
a
range
of
solutions,
and
maybe
that's
4b
is
that
that
would
be
after
some
experiment
that
you
know
implementers
would
basically
couldn't
make
a
choice.
So
designers
can
make
a
choice
right.
T
S
Here
I
mean
okay,
we
can
talk
about
this
here.
That
was
basically,
though,
the
mode
the
address
type
plus
the
initial
address.
That
was
used
million,
BTC
P.
So
if
you
change
like
three
times,
you
would
have,
maybe
in
slack
you
have
one
group,
they
all
belong
to
one
group
and
each
address
can
have
a
type
pacifism.
Is
that
does
that
make
sense?
Is
it
need.
I
A
I
I
That's,
so
you
know
if
you
say
that
well,
we
performance
suffers
by
50
percent
and,
like
you
know,
for
for
to
court
first
of
two
connections
or
something
but
but
some
I
mean
just
n,
pz,
p,
pz
p
right.
We
always
like
to
see
TCP
improvement
proposals
come
with
at
least
some
data.
That
sort
of
shows.
You
know
here's
how
it
was
before,
and
here's
how
it
could
be
after
and
after
is
hopefully
much
better
than
before,
and
this
is
what
I
would,
if
expect,
for
these
proposals
as
well.
I
I
F
Thank
you.
No
I
put
my
3gpp
had
so
different
part
from
your
perspective
for
Fiji
because
have
very
clear
items
which
is
a
probe
which
are
a
priority
from
the
point
of
view
of
multi
plasticity.
We
already
specified
vas.
We
would
like
to
see
them
actually
handle
them
as
priorities.
This
item
has
not
being
an
issue
in
the
context
of
the
5g
discussions
in
3gpp
and
at
least
while
jelly
development,
the
standardization
is
still
owned
by
3gpp.
F
A
F
What
are
the
other
side,
the
area
which
is
fully
specified
in
the
context
of
a
TSSs
multipath
tcp?
It
is
publicly
available,
multiple
TCP.
It
is
one
of
the
main
alligator
mechanism
for
the
time
it's
already
sent
to
IETF
for
a
couple
of
drafts
that
are
considered
priority,
which
I
mentioned
earlier
in
this
discussion.
M
A
A
Yes,
so
we
had
a
good
session
for
about
an
hour
on
Monday
morning
with
a
nice
number
of
people.
Thank
you
for
that
likely
was
supposed
to
be
complimentary.
They're
not
I
realized
afterwards.
You
might
miss
read
that
so
we
talked
quite
a
lot
about
the
path,
menu
manager
and
schedule,
er,
which
kind
of
related
topics
we-
and
we've
talked
more
today
about
that.
So
I
think
my
my
some
with
where
we're
at
is
that
this
ATSs.
A
A
We
kind
of
we
got
into
a
discussion
about
sort
of
possible
mechanisms
which
I
think
we've
had
in
the
past.
We've
had
discussion
about
possible
mechanisms
and
if
you
remember,
we
never
reached
any
consensus
when
we
would
talk
about
the
RFC
and
the
Biss
about
adding
anything
more
than
the
backup
that
the
MP
prior
now
there
are
all
sorts
of
things
you
could
do.
A
There
is
room
for
new
sub
option
types,
there's
all
sorts
of
information
exchanges
you
might
want
to
add,
but
I
think
before
we
get
into
mechanisms,
we
need
to
think
more
about
scenarios,
the
requirements,
what
the
problem
is
before
getting
into
that.
So
that
was
my
summary
of
that
that
set
of
all
those
two
topics,
the
path
manager
and
schedule
it
discussion.
We
had.
We
had
some
discussion
about
API,
so
this
is
between
the
application
interface
between
the
application
and
multiple
of
TCP.
A
A
So
there's
a
bit
of
disagreement
there,
some
people
think
it's
useful.
Some
people
are
concerned
about.
You
know
that
various
problems
of
scalability
and
things
Marcus
who's,
who
some
done
work
on
that
he's
planning
a
draft
for
Montreal
and
we
heard
a
bit
of
related
work
today.
So
my
suggestion
was
we
parked
discussion
until
until
that
point
see
people
can
discuss
on
the
mainly
mistis
they
want
so
I
think
Anna.
A
K
So
there
was
a
discussion
about
api's
and
what
information
you
should
convey
to
amputee
city
for
selection,
of
your
all
paths
or
controlling
the
scheduler,
and
in
this
context
we
have
the
ongoing
work
on
transport
services
in
the
tops
working
group.
So
I
thought
it
was
quite
good
for
this
group
to
know
what
is
going
on
there,
because
it's
closely
related.
K
So
the
idea
of
the
the
taps
group
is
to
specify
an
abstract
api
for
the
transport
services.
So,
instead
of
having
your
implementation
directly
connected
to
a
given
transport
protocol
already
at
compile
time,
you
use
this
API
and
then
you
have
a
transport
system
underneath
that
allows
you
to
select
the
protocol
at
the
startup
time
and
there
we
also
have
some
of
these
mechanisms
that
were
mentioned
today
in
relation
to
how
you
select
the
path
and
the
happy
eyeballs
mechanism
between
different
protocols
is
built
into
this.
K
K
K
Yes,
so
I
guess
I'm
on
the
last
slide.
So
these
are
the
three
cool
taps
drafts.
If
you
want
to
see
the
the
structure
of
this,
there
is
a
github
repository,
I
used
to
also
open
an
issue
there
for
the
multipath
part,
because
we
have
discussed
to
have
what
that
interface
needs
to
look
like
and,
of
course
you
have
the
tabs
working
group,
the
page.
U
Tell
me
Polly
so
I
noticed
because
I'm
on
the
taps
documents
I
noticed
that
you
opened
a
issue
for
improving
the
granularity
of
the
multipath
stuff.
I
added
a
comment
back
of
what
we're
currently
doing
in
our
taps:
implementation
on
Apple
devices,
which
is
essentially
using
the
enum
that
Christoph
has
defined
of
we
have
you
know
you
can
have
it
off,
but
then
you
can
have
it
in
handover,
interactive
or
aggregation
mode.
K
A
C
Christoph
with
the
huffman
and
John
scheduled
a
problem,
I
guess:
I've
already
said
that
in
the
past
a
few
times
and
I
really
think
it's
one
of
the
biggest
problems
for
multi-path
is
that
there
are
two
conflicting
goals:
there's
a
client
on
one
side:
you
want
to
have
the
best
performance,
the
best
user
experience
and
on
the
other
side,
you
want
to
avoid
using
the
most
costly
interface
right,
reduce
the
cost.
So
those
are
conflicting
goals,
at
least
on
a
smartphone.
C
Now
that
is
fine
on
the
client,
because
in
the
client
I
know
what
I'm
doing
and
I
know
what
my
goal
is
and
where
the
thresholds
are,
but
these
thresholds
need
to
be
communicated
to
the
server,
because,
when
I'm
connecting
to
a
server
or
lease
a
generic
server,
I
need
him
to
do
it
to
respect
those
thresholds.
Otherwise
I
will
be
consuming
too
much
cellular
data,
and
that
is
the
problem.
That's
not
easy
to
solve
without
additional
signaling
or
some
other
ways
on
our
Seidel
Applewood.
C
The
way
we
deploy
it
at
the
moment
is
well,
we
know
to
which
server
we
talk
and
we
configure
for
each
service.
That
requires
a
certain
policy.
We
configure
the
server
specifically,
so
that
means
basically,
we
have
different
server
infrastructures
for
each
service.
That
requires
a
certain
policy,
so
if
one
would
want
to
now
deploy
a
generic
mptp
service,
he
won't
be
able
to
really
do
this
because
he
would
need
to
specify
some
kind
of
scheduler
on
that,
sir,
on
that
infrastructure,
and
that
scheduler
will
not
be
able
to
satisfy
all
the
policies.
A
Christophe
can
I
ask
you
going
back
to
losses
UCE,
he
suggests
an
experience
point.
Have
you
tried
that
out?
Does
that
work?
Well
enough
in
your
case
or
well.
C
That
may
like
trying
to
slow
down
the
other
side,
like
with
congestion,
experience
or
maybe
setting
the
window
or
things
like
that
that
works
for
for
maybe
for
throughput.
But
if
the
policy
or
the
thresholds
are
latency
days,
then
that
doesn't
work
yet
and
like
for
our
Seri
use
case,
that's
below
E.
What
we
do.
We
have
latency
thresholds
upon
which
we
start
using
on
cellular.
I
I'm
standing
on
a
slide
because
I'm
not
sort
of
particularly
on
on
this,
so
I
check
quick
right.
So
this
is
lies
again.
I
check,
quick
and
quick
is
probably
sometime
later
this
year,
gonna
start
doing
multipath,
quick
and
and
a
lot
of
the
lessons
that
we've
learned
with
multipath
TCP,
but
also
a
lot
of
the
open
issues
that
we're
still
having
like
this
right
path.
I
It
might
even
be
that
we're
really
not
where
we
need
to
be
in
order
to
do
engineering
here.
So
that's
why
I'm
sort
of
studying
on
the
side,
because
I
don't
know
if
this
is
a
discussion
you
want
to
get
into,
but
I
think
the
the
upcoming
push
for
Crick
multipath
will
make
a
lot
of
these
things
very,
very
urgent,
more
urgent,
and
they
have
been
in
a
long
time.
F
F
F
Looking
at
is
a
way
to
see
these
discussions
and
also
being
direct
participant
in
otherwise
do
Swiss
type
of
discussions
like
it
or
not.
The
policy-based
step
of
decision
you
may
need
to
take
it
into
consideration
into
the
context
of
the
scheduler
and
how
this
can
be
better
put
in
place
may
need
to
be
many
to
be
discussed
properly.
I
I
I
My
gut
feeling
is
that
policy
is
not
going
to
make
it
easier,
but
but
we
need
something
that
works
well
enough,
because
otherwise
we
have
the
same
thing:
that
in
multiple
TCP
had
great
potential,
and
it
works
really
well
for
some,
but
it
hasn't
really
sort
of
delivered
on
on
being
broadly
applicable.
What
we
initially
hope
when
we
did
it.
M
V
Some
of
these
questions
do
have
a
relationship
I
see
CEO
G,
because
is
the
relation
to
congestion,
control
and
I,
see
CAG
also
looks
into
a
QM
and
scheduling
music
mechanism
in
the
network,
so
there's
a
big
overlap.
If,
if
that's
not
a
good
idea,
we
can
also
figure
out
if
we
want
a
separate
research
group
for
it,
but
I
don't
want
to
have
I,
don't
want
to
have
a
research
discussion
in
the
working
group
here.
V
The
other
thing
I
heard
is
about
some
minor
extensions
we
may
need,
but
like
fortunately,
we
have
the
working
group
for
my
next
tensions
for
TCP.
This
is
also
TCP,
so
any
any
of
this
work.
If
any
of
this
work
is
needed
and
gets
mature
and
we
want
to
standardize
it,
we
have
an
option
to
standardize
it
outside
of
this
working
group
as
well,
and
the
third
thing
I
heard
was
questions
related
to
interfaces,
and
we
have
a
working
group
for
this
and
I
pointed
out
very
well.
So
there's
there's
a
strong
overlap.
V
The
steps
here
so
right
now,
I,
don't
see
any
reason,
also
like
you're
all
here
and
it's
great
that
you're
interested
in
MB
TCP
but
I
don't
see
any
reason
to
keep
MP
TCP
as
a
special
Northlake
anymore.
Mb
TCP
is
part
of
the
TCP
protocol
and
and
it
swaps
over
into
different
working
groups,
and
that's
where
we
should
have
the
discussion.
H
Iiii,
don't
think
that's
just
research
question
because
that's
basically
operation
no
a
lot
of
scenes
that
stems
from
the
operational
experience
that
require
some
SPECT
to
be
changed
and,
and
secondly,
technically
that's
the
and
secondly,
because
the
we
have
3gpp
and
also
BBF
expert
here,
and
they
are
also
looking
at
this
and
the
liaison
with
existing
the
working
group
to
be
a.
They
should
be
very
helpful
for
the
ecosystem.
V
That's
what
I
said
so
there
are
many
research
questions
to
find
a
solution
that
may
change
the
spec,
but
so
far
my
understanding
is
these
changes
to
specs
are
minor
and
therefore
they
don't
have
to
have
their
own
working
group.
I
don't
want
to
discourage
anybody
to
do
this
work
because
I
think
it's
very
interesting
and
I
see
operations
upon
it
just
doesn't
might
not
need
an
own
working
group.
That's
the
only
difference.
H
Actually,
it
would
be
much
easier.
You
have
working
group
to
solving
this
problem
and
looking
with
the
expert
here,
if
you
are
shipping
to
ICC,
RG
or
ro
research
group,
then
not
the
attention
of
the
that
the
practitioners
will
be
distracted.
Somehow
they
don't
know
if
their
impression
is
that
MPTV
working
who
has
been
closed
and
they
don't
know
ICC
has
been
looking
at
that,
for
example,.
V
H
A
I'm,
a
partly
agree
with
those
comments
I
mean
to
me:
I'm,
not
sure
we
actually
understand
the
problem
that
we're
trying
to
solve
yet.
So
it's
a
bit
hard
know
how
much
research
is
needed
or
if
it's
something
that
actually
can
be
easily
so
and
I.
Think
there's
not
been
agreement
on
that
at
all.
Yet
so.
V
A
A
S
A
F
F
Peer
I
will
proxy
or
tournament
that
may
need
to
implement
a
policy,
and
in
this
particular
case
again
putting
my
3gpp
hat.
I
will
say
that
you
do
have
a
problem
and
we
do
have
very
clear
requirements
for
the
need
of
having
both
policies
is
to
use
a
multiple,
TCP
scheduler.
So
then
we
may
want
to
see
it
addressed,
not
as
a
genetic
research,
academic
or
whatever.
So.
C
A
C
F
Didn't
understand
that
they
she
is
communicating
the
policy.
They
show
that
at
least
I
understood
from
the
comments
was
that
the
overall
a
plan
is
a
policy
together
with
whatever
the
schedulers
of
multipass
tcp
may
be.
An
issue
yes
communicate
is
a
policy
was
not
an
issue.
Genetically
we
happened
to
have
a
draft
two
mums.
That
would
provide
something
like
that.
A
G
Independent
from
the
policy
discussions
and
I
think
I'm,
also
active
in
in
the
three
TPP
and
and
BBF
stuff
and
and
I
think
we
don't
know
that
they're
very
much
interested
in
multiple
CSP
or
this
even
defined
that
they
will
use
multiple
CCP
in
future.
And
so
what
I
want
to
ask
is
I
in
principle,
I
think
it
would
be
good
at
least
to
have
an
informational,
documented
ITF,
which
is
describing
traffic
scheduling
and
impart
miniature
mechanisms,
so
that
others
understand
other
standardization
organizations
knows
about
what
is
what
is
may
be
available.
G
V
So
if
people
think
such
an
informational
document
is
useful,
we
can
do
this
in
the
IETF,
but
as
law
said,
this
is
also
a
topic
that
is
relevant
for
other
protocols
as
well.
It's
not
MBG
specific,
so
this
might
not
be
the
right
word
for
it.
I'm
very
supportive
for
such
a
document,
I
can
and
also
the
work
like
if
you
need
an
extension
for
a
priority.
Please
do
the
work.
Please
write
the
documents
we
will
find
a
home
for
it.
I,
don't
think
we
need
a
separate
working
group.
F
Do
you
really
need
to
say
something
yeah,
just
actually
I
would
totally
agree
with
him
before,
and
they
do
see
this
interest
not
only
from
Fiji
VP,
as
I
also
happen
to
be
in
novel
groups
like
I
Triple
E
having
a
generic
multipath,
we
would
like
to
be
able
to
use
ITF
standardized
protocols
making
sure
that,
were
you
know,
but
also
needs
to
be
from
this
sides.
Only
concern
in
all
of
this
organization
is
the
timeline
like,
for
example,
I
would
need
something
for
the
released
17
timeframe,
which
is
next
December.
F
H
A
H
V
Group
has
a
charter,
we
did
everything
that
was
written
down
in
the
Charter,
so
that's
usually
the
end
of
a
life
of
working
group.
If
you
want
to
do
a
new
work,
we
can
talk
about
it,
it
doesn't
mean
it
has
to
be
done
in
this
working
group
say
in
us,
for
this
working
group
has
currently
one
active
working
group
document
which
is
in
processing.