►
From YouTube: IETF111-TSVWG-20210729-1900
Description
TSVWG meeting session at IETF111
2021/07/29 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
B
A
A
B
B
I
invited
somebody
to
take
another
fresh
look
at
this,
because
we're
aiming
at
proposed
standard
with
the
hope
of
elevating
this
after
we've
published
the
rfc
and
we're
waiting
for
a
revised
id
after
this
ietf,
where
we're
going
to
discuss
a
couple
of
the
topics
that
came
up
in
that
review
and
there
might
be
a
confirming
working
group
last
call
on
the
latest
revision
and
that's
also
true
of
the
nutsupwork
and
both
of
these.
We
will
hopefully
conclude
at
the
current
meeting
next
slide.
B
Agenda
review
we're
going
to
have
496,
or
this
first
michael
tutson,
is
going
to
talk
to
this
and
we'll
tidy
up
the
discussion.
Magnus
westland
is
going
to
talk
about
the
sctp
dtls
draft
and
we're
going
to
revisit
not
alternatives
for
sctp
briefly,
and
maybe
follow
up
later
on
that
one.
If
needed
and
there's
a
price.
B
Dual
touch
is
going
to
talk
about
udp
options,
except
I'm
going
to
talk
about
it
instead
of
joe
udp
options
is
one
of
the
targets
for
a
future
interim,
so
we
likely
will
not
be
able
to
clear
all
the
issues
with
udp
options.
Now
we'll
simply
take
that
to
an
interim
in
early
september
and
then
which
we're
going
to
do
is
a
status
update.
Only
yeah,
that's
true,
marcus
is
going
to
present
multipath
dccp.
B
This
has
been
the
slide
decks
of
tsvwg
for
many
meetings
it's
here,
because
it
is
being
requested
to
be
adopted
as
a
work
item
and
we're
going
to
discuss
around
that
topic.
We
are
not
going
to
start
the
adoption
call
now,
but
we're
going
to
talk
about
the
coming
possibility
of
an
adoption
call,
and
we
would
love
input
on
that
next
slide.
B
We
have
just
one
hour:
if
we
need
it,
we
will
take
the
topics
to
an
interim,
for
instance,
the
remaining
sctp
issues,
udp
options
etc,
and
there
are
ipr
concerns
have
been
talked
about
on
the
list
concerning
the
multi-path
dccp
draft.
We
believe
these
will
be
resolved
and
we
will
not
start
the
adoption
call
until
the
ipr
is
really
clear.
B
D
You
see
that
there
have
been
three
revisions
based
on
our
comments
during
the
last
call.
One
was
pretty
easy:
the
definition
of
control
chunk.
Then
timo
reported
something
about
association,
mtu
or
association
path.
Mtu
wasn't
very
clear,
so
we
use
introduced
a
new
term
for
that
and
magnus
provided
a
review.
D
And
here's
what
what
the
changes
where?
Basically
you
see
it's
clarifications
on
various
things
like
ssn
generation,
tsn
generation?
What's
a
counties
and
act
clarifications
on
fragmentation
of
user
messages,
some
of
this
stuff
is
is
going,
I
guess
going
back
to
if
you,
if
you
have
read
quick
documents,
you
you
might
want
to
emphasize
the
differences
between
quick
and
http.
D
It
was
also
added
or
changed
a
text
that
avoids
sending
an
error
message
or
an
abort
chunk.
A
message
within
the
board
chang
with
verification
take
zero,
which
shouldn't
be
the
case,
and
we
are
allowing
the
l
factor
for
abc
not
to
be
one
based
on
the
tcpm
discussion.
This
is,
I
think,
that's
a
good
thing
and
a
reference
was
added
to
details
over
sctp.
D
What
has
not
been
accepted
is
magnus
brought
up
a
point
that
sctp
is
supporting
multi-homing
and
each
endpoint
has
a
list
of
the
addresses
of
the
peer
and
for
these
remote
addresses
it
has
counters
for
errors.
It
has
a
congestion
window
and
all
this
stuff,
and
so
this
is
only
per
destination.
Address
magnus.
D
Suggested
that
this
should
be
based
on
a
pair
of
source
address
and
destination
address.
Basically,
this
is
has
so.
This
was
a
very
early
decision
in
the
design
process
only
to
to
look
up
only
to
consider
the
remote
address.
So
this
is
not
an
issue
or
a
mistake,
or
something
like
that.
That's
that's
that's
something
you
can
change,
but
we
don't
consider
it
a
change
within
the
base
back
so
render
stewart
and
myself
think
that
this
would
be
a
different
flavor
of
sctp
magnus
can
can
say
something
about
that.
D
D
So
I'm
planning
to
remove
that
and
based
on
the
discussion
with
magnus,
there
will
be
added
text
that
whenever
the
sctp
stack
gets
notified,
that
a
route
to
a
particular
destination
has
changed,
it
resets
its
parameters,
that's
completely
valid,
that's
we
have
already
text
there
or
if
we
change
the
diffs
of
code
points.
So
this
is
very
easy
that
will
come,
but
I
think
the
open
point
is
or
might
be,
the
one
magnus
brought
up
yeah
from
the
perspective
of.
B
F
Yeah,
yes,
I
I'm
fine
with
this.
I
understand
that
we
decided
to
keep
this
and
going
to
full
standard
here,
etc
and-
and
yes,
I
think
the
core
really
core
issue
about
the
paths
when
resetting
congestive
control
state
and
all
these
things
is
being
addressed
is
sufficient
at
this
point,
and
yes,
I
understand
that
there's
maybe
want
to
update
ssdp
for
being
fully
pathway
rather
than
yes
destination,
aware,
but
that's
I
I
I
understand
it's
it's
proposed
an
extension
in
a
separate
draft.
G
D
G
G
B
Just
I
think
that's
it
a
really
useful
contribution,
and
I
think,
if
you
add
that
I
would
be
willing
to
start
a
working
group
last
call
on
the
updated
version
of
this
document
to
confirm
all
those
changes
and
if
anyone
else
wishes
to
contribute
a
review
of
this
at
that
stage,
that
will
be
fine.
So
we
can
take
questions
during
working
group.
Last
call
and
please
make
the
addition
that
jonathan
said
and
the
proposals
you
just
change
and
submit
a
new
id.
F
F
So
this
update
was
quite
substantial.
One
of
the
biggest
changes
is
that
we
actually
moved
to
using
the
adaptation
layer
indication
to
understand
that
you're
trying
to
do
details
over
http
here
and
have
that
singled
and
negotiated
in
your
in
the
national
in
init
and
unit
response
there.
We
clarified
a
couple
of
things
about
replay
protection
failure
cases.
F
F
So-
and
we
have
a
mechanism
now
based
on
how
you
track
the
key
changes
between
and
it's
receiver
dropping
the
old
dtls
key
after
one
full
epoch.
After
so
when
you're
going
to
key
m
plus
one
you're,
dropping
t
n
minus
one
so
to
say,
and
that's
the
trigger.
However,
in
general,
one
of
the
biggest
problems
we
have
headers
is
around.
Detail
is
1.3,
which
is
not
giving
us
future
parity.
F
One
of
the
biggest
issues
is
that
it
removed
renegotiation,
which
means
that
we
have
no
perfect
forward
secrecy,
rekeying
and
no
servery
authentication
so
and
then
in
the
current
version,
we'd
have
a
serious
limitation
seriously.
If
you
have
any
limitations,
both
in
in
length
with
details,
it's
probably
not
serious,
because
it's
several
years
of
normal
usage,
but
it's
that
you
actually
only
have
16
bits
of
key
epoch.
F
F
F
This
is
to
be
fully
certain
is
hard,
it's
basically
impossible,
because
there
could
be
some
message
on
the
way
that
you
haven't
received.
So
we
have
limitations
here
and
potentially
we
could
have
impact
on
application.
We
don't
think
the
existing
application,
but
we
really
would
be
good
to
hear
about
if
someone
has
some
usage
where
they
have
large
user
message
and
long
live,
then
maybe
want
to
adopt
dtls.
F
That
would
be
a
problem
here,
because
apparently
one
user
message
might
as
long
as
leave
for
one
key
epoch
and
and
that's
give
us
a
limitation
in
time
and
space
etc
for
how
long
it
will
be
so
so,
if
someone
has
anything,
please
speak
up,
but
otherwise,
let's
move
on
to
the
next
slide,
where
we
talk
a
little
bit.
What
we
think
we're
gonna
do
here,
so
detail
is
1.3.
We
have
been
thinking
about.
F
F
F
But
we
don't
think
that's
rated
so
either
we
try
to
find
something
that
works
or
one
other
potential
solution
would
be
to
actually
just
do
with
update
for
support
and
detail
as
1.2
now
and
make
a
lot
more
long-term
work
on
1.3
to
meet
the
deadlines
you
have,
but
we
are
going
to
give
a
try
or
trying
to
meet
some
of
these
before
giving
up
but
and
on
the
re-keying
is
completed.
We
have
several
different
cases
and
things
here
and
it's
we're
trying
to
see
what
different
trade-offs
are.
F
So
we
could
take
the
detailers
and
protect
the
user
message
and
actually
split
it
over
multiple
lists
to
be
user
message,
and
that
way
we
could
actually
change
overall,
the
cancellation
key
when
we
desire
in
the
middle
of
of
the
upper
layer,
user
message
or
add
another
signal
for
explicit
message,
but
yeah.
So
we
have
a
couple
of
ideas,
we're
trying
to
evaluate
and
think
about,
but
we
basically
realized
the
week
before
the
deadline
here
that
we
have
these
quite
significant
issues
still
and
want
to
look
forward
so
next
slide.
F
A
F
Correct
to
my
understanding
and
what
I
mean
john,
is
more
active
in
3d
people
and
writing
contributions
towards
the
security,
fair,
but
basically,
3dp
is
currently
accepting
and
continue
to
use.
Dtls
1.2,
that's
the
recommendation.
I
mean
basically
and
accepted
secured
solutions
for
for
them
from
from
their
perspective,
so
it
could
be
one
way
forward
here
and
if
others,
that's
active,
essentially
pp
or
cross,
etc.
We're
willing
to
discuss.
F
F
F
A
F
A
F
D
Okay,
so
we
have
a
document
for
a
long
time
and
there
have
been
two
reviews
from
eighties
magnus
from
as
of
homer,
ade
martinez,
current
eddie
and
claudio,
and
some
of
these
comments
were,
I
would
say,
in
the
range
of
what's
expected
in
a
working
blast
called
we
have
some
clarification,
some
corrections,
some
additions
and
so
on,
and
it
matches
what
magnus
said
at
the
last
meeting.
So
it's
like
he's
expecting
a
new
draft
to
to
address
these.
D
D
We
can
change
the
addresses,
but
not
the
port
numbers
and
for
multi-homing
you
need
some
special
procedure
for
iterative
setup
of
the
multi-homing
stuff
and
that's
also
agreed
on.
The
basic
question
is:
when
you
do
an
ad:
how
do
you
handle
a
local
port
number
collision?
So
two
point
two
endpoints
behind
an
ad
with
the
same
local
port
number,
one
to
talk
to
a
server
to
the
same
server.
D
D
Just
in
case
you
have
a
port
number
collision,
let
the
endpoint
jll
change
the
local
port
number
and
retry
or
time
it
out,
and
that's
a
completely
different
thing
how
to
integrate.
So
that's
why
this
document
hasn't
progressed.
I
need
to
say
that
the
original
focus
of
the
net
document
was
nets
at
it's.
At
home
somewhere
doing
this
claudio
is
more
focusing
on
nets
coming
into
the
game
when
you
do
container
stuff
and
and
deploy
sctp
there.
So
that's
why
I
didn't
progress
further
any
input.
D
A
B
Right,
I,
I
think
what
we
need.
I
think
what
we
need
to
do
here
is
think
a
little
bit
more,
maybe
discuss
a
little
bit
on
the
list.
One
option
might
be
to
continue
with
the
document
through
the
publication
chain.
This
is
not
something
new
that
we've
discovered.
We
knew
this
all
the
time
we
just
didn't
have
a
use
case
for
the
other
way
of
working.
B
So
we
could
publish
this,
and
I
think
we
might
want
to
toss
that
through
the
working
group.
We
could
also
think
about
the
other
one.
I
don't
think
we
have
time
to
discuss
those
now
and
I'm
going
to
call
a
little
bit
of
a
go
back
on
the
list
and
talk
a
bit
more
about
this.
Let's
publish
the
sctp
base
spec
and
then
let's
move
rapidly
on
this,
so
I
I'm
not
suggesting
it's
a
long
pause,
but
maybe
a
little
bit
of
time
to
do
some
reflection
find
my
pain.
B
Okay.
Let's
do
that
again,
maybe
a
september
interim,
and
we
should
we
should
have
this
resolved
if
not
before,
and
if
the
proponents
of
the
other
method
would
like
to
write
an
internet
draft
that
would
really
help
clarify
the
details.
Only
only
a
little
bit
has
to
do
in
that
draft,
but
it'd
be
nice
just
to
have
on
paper
what
exactly
it
looks
like.
D
I
I
I
So
I
just
like
to
thank
the
working
group
for
the
adoption
first
of
all
and
for
all
the
feedback
that
we
got
so
far
and
say
we're
very
excited
to
progress
this.
So
just
a
quick
reminder
in
case
you're
not
familiar
with
the
draft.
This
draft
exists
because
because
there
has
been
an
interest
within
the
working
group
on
new
dhcp
assignments,
but
there
are
several
dynamics
and
pathologies
on
internet
paths
that
are
played
that
need
to
be
taken
into
account
when
choosing
a
new
dscp.
I
Undesirable
side
effects
like
priority
inversions
or
you
can
end
up
with
a
lot
of
traffic,
remarked
to
the
same
unexpected
code
point
that
leads
to
traffic
being
aggregated
in
weird
ways
and
so
on.
We
know
these
pathologies
exist
and
we
know
of
what
their
prevalence
in
the
internet
is
because
we've
been
conducting
measurements
several
measurements
over
a
number
of
years.
I
But
the
main
aim
of
the
of
the
working
group
for
this
draft
is
to
provide
considerations
for
new
dhcp's
dhcp
assignments.
If
we
can
move
on
to
the
next
slide,
please
yeah
we've
adopted
the
zero
zero
version
of
this
draft
this
week,
but
we
would
like
some
input
from
the
working
group,
particularly
on
mapping
on
mappings
between
the
saps
and
various
lower
lower
layers.
I
So
if
you're
interested-
and
you
want
to
have
a
read-
and
you
have
some
input
on
any
of
these,
then
please
let
us
know
would
be
we'd,
be
very
happy
to
hear
from
you
and
let's
make
version
zero
one
happen
next
slide,
please!
Yes,
so
here's
the
point
where
I
briefly
pause
for
questions
before
introducing
the
next
talk,
which
is
greg
stock
on
the
nqb
php
and
the
scp.
B
B
We
can
write
that
down,
but
if
I
put
my
working
group
chair
hats
on
I'll
say
this
is
about
how
dscps
work
so
and
it's
not
a
new
recommendation
for
new
things.
It's
a!
How
are
these
registers
being
registries
being
used,
so
another
draft
could
could
change
that
behavior.
But
I
think
this
has
to
document
what
is
actually
used
in
the
wild
against
and
include
perhaps
what
the
ietf
expects
to
be
used
in
the
world,
even
if
that's
not
really
used
by
everyone,
yeah
martin,
what
it's
wonderful,
okay,.
A
A
I
I
Know
if
I
clashed
with
someone?
Yes
thanks,
everyone
for
the
input.
It
would
be
very
good
to
know
what
I
can
look
for
in
measurements
in
terms
of
measurements
when
we
do
the
next
round.
But
yes,
we
can
take
this
up
to
the
mailing
list,
and
I
can.
I
can
now
move
forward
to
talk
a
bit
about
the
data
that
we
have
for
the
nqpd
scp
right.
I
So
what
we
did
is
we
examined
another
pair
of
code
points
that
fit
greg's
initial
criteria,
and
these
are
45
and
five
and
the
advantage
is
there.
There
are
no
well-known
code
points
that
we
will
result
in
the
scp-5
when
they
are
bleached,
but
the
the
concern
with
the
cold.5
was
that
it
used
to
be
in
a
pool
used
for
experimental
assignments.
I
Next
slide,
please,
so
we
actually
ran
some
measurements
to
check
the
viability
of
call
points
45
and
5,
and
we
have
good
news
all
around.
We
found
no
weird
breakage
that
results
from
using
these
code
points.
We
found
that
in
terms
of
remarking,
is
not
different
at
all
from
the
previously
proposed
coil
points,
42
and
2.,
and
we
only
found
two
parts
that
remarked
to
the
scp-5
in
the
wild,
and
one
of
them
is
a
weird
department
of
defense
network.
I
But
the
main
key
takeaway
here
is
that
we
have
no
concerns
about
the
new
pair
of
code
points
and
I'm
very
happy
to
just
let
greg
take
it
over
from
here.
Just
a
note,
there's
another
slide
after
this
one
about
how
we
conducted
the
measurements
and
what
the
methodology
was
feel
free
to
examine
that
and
get
in
touch
with
me.
If
you
have
more
questions
on
on
the
measurements.
B
H
Go
ahead,
I
actually
joined
the
queue
before
the
nqb
bit
just
to
so.
This
is
relevant
to
that
I
wondered
once
you
know
the
itf
was
published,
I've
seen
saying
what,
as
david
said,
what
the
itf
thinks
ought
to
happen,
and
then
this
is
publishing
what
is
happening
in
the
process
of
publishing
this.
Might
that
confuse
people
into
them
now
thinking
the
itf
is
saying
what
is
happening
should
happen.
H
H
B
Yeah,
as
a
chair,
I
I
think
we
we
will.
We
we
I'm
so
pleased
to
be
made
a
work
item.
We
will
have
to
do
work
to
figure
out
what
this
is.
It
could
even
become
bcp
at
some
point
if
we
have
very
concrete
recommendations
on
the
chord
point,
allocation
and
usage,
but
this
is
not
so
much
about
documenting
weirdisms,
it's
about
documenting
how
to
use
dscps
and
and
to
get
there
we'll
have
to
go
through
this
process.
K
K
Bob
posted
another
set
of
comments
to
the
mailing
list
shortly
after
those
six
was
published.
Oh
seven
now
includes
edits
to
address
those
comments,
including
restructuring
the
text
in
the
in
the
draft.
So
he
pointed
out
that
the
flow
of
the
the
material
could
be
improved
upon,
and
so
I
agreed
with
that
and
I
changed
the
order,
which
unfortunately
makes
the
diff
a
bit
hard
between
six
and
seven.
K
So
in
addition
to
reordering
the
sections,
a
new
paragraph
on
3gpp
networks
was
provided
by
kevin
smith
from
vodafone.
So
I
popped
put
that
into
the
new
draft
and
then
wrapped
up
my
work
on
addressing
david
black's
comments.
So
I'm
sure
they
haven't
had
a
chance
to
look
at
those
yet,
but
hopefully,
in
due
time,
we'll
take
a
look
and
see
if
you
think
I
address
those
correctly
milestone
currently
is
to
submit
proposed
rfc
pro
standard
rfc
by
the
end
of
september.
K
K
There
had
been
questions
in
the
past
as
to
well.
How
does
an
application
know
whether
it
is
below
the
available
capacity
in
the
path
I,
like,
I
said,
resisted,
putting
anything
specific
in
the
draft
on
that,
but
I'm
I
guess,
bending
to
the
pressure
now
and
the
next
slide
has
the
the
detail
on
that,
and
we
won't
have
time
to
go,
have
discussion
on
it,
but
we
can
take
a
look
at
it.
K
A
few
other
significant
changes
added
a
note
that
just
marking
your
traffic
and
qb
doesn't
let
you
off
the
hook.
You
still
need
to
implement
some
kind
of
congestion
response,
reorganize,
the
wi-fi
section
to
make
it
clear
that
wi-fi
gear
can
fully
support
the
php.
The
focus
had
been
more
on
the
interoperability
with
existing
equipment,
so
I
made
that
organized
better
and
then
one
of
the
shoulds
changed
to
a
must.
I
won't
go
into
detail
on
that
so
next
slide.
K
K
K
Okay
and
the
second
bullet,
the
draft
does
include
a
requirement
for
rfc
8525
gear
is,
it
should
basically
says
8325
gear
should
map
the
nqb
code
point
to
the
video
access
category
and
that's
in
the
case
that
the
equipment
doesn't
fully
support
the
the
php
so
but
one
case
where
you're
implementing
8325
and
nqb.
I
think
that's
fine,
that's
not
necessarily
an
update
of
esp-25,
but
this
one
is
in
the
case
you're,
not
implementing
nqb.
K
K
Okay
and
then
the
last
largest
thoughts
on
working
group
last
call
there've
been
a
number
of
changes
you
know,
including
yesterday,
so
I'm
not
seeking
working
last
call
today
on
this,
but
I
think
we're
getting
awfully
close
I'd
like
particularly
the
folks
who
provided
a
recent
set
of
comments
to
double
check,
they're
happy
with
what
I
did
to
address
those
comments
and
then
hopefully
we
can
go
to
working
group
last
call
in
a
couple
of
weeks.
From
now
with
me,
my
goal.
A
B
Okay
literally
starts
now
next
time.
While
I
start
I'm
not
joe
touch,
I
am
gory
joel,
isn't
at
the
meeting
and
we
plan
to
have
an
interim
and
we
will
ensure
that
joe
is
present
which
might
allow
a
bit
of
discourse
between
him
and
people
like
tom
herbert
who
have
been
discussing
the
issues
on
the
list.
B
B
This
is
just
list
of
pending
issues
which
should
align
roughly
with
what
I
said
again
jules
willing
to
discuss
these
on
list
and,
of
course,
with
the
we
expect
at
least
one
revision
of
the
document
before
the
interim
meeting.
Thank
you
right.
I
managed
that
in
one
minute
is
there
anyone
who
wants
to
comment
on
joel's
draft
or
needs
to
ask
something
at
the
might
know.
Please
go
ahead
as
we
prepare
for.
B
B
L
Go
ahead
thanks,
carl
thanks
glory.
This
is
marcus
from
deutsche
telekom.
I
hope
you
can
hear
me
well
yeah.
I
want
to
talk
about
multi-parts
tcp
and
also
look
together
with
you.
Two
words
working
group
adoption
so
having
first
a
look
into
a
potential
multi-pass
dccp
deployment,
as
you
can
see
it
in
the
figure
at
the
bottom,
when
the
mpdccp
is
deployed
as
a
proxy
in
a
core
network,
potentially
a
5g
core
network
or
in
a
cloud
infrastructure
along
with
mp,
dcp
implementation
and
a
residential
gateway
in
a
smartphone.
L
And
if
this
is
even
enhanced
with
some
encapsulation
scheme,
then
this
is
able
to
carry
any
traffic
and
it
offers
a
lightweight
steering.
Switching
and
a
splitting
multi-power
support,
for
example,
hybrid
axis,
where
it
is
able
to
carry
any
kite
type
of
traffic
regardless.
If
it
is
a
tcp
or
udp
or
it
could
be
implemented
for
the
5g
80
triple
s,
which
is
specified
in
3gbps
of
release.
L
L
Also
back
in
time.
There
was
a
liaison
request
from
3gbp
to
itf,
requesting
a
support
for
non-tcp
multipath
transport
for
the
80
triple
s
use
case
and
in
general
there
seems
to
be
a
strong
interest
from
operators
and
vendors
who
communicated
and
expressed
their
interest
on
the
tsbwg
mailing
list
that
hand
overs
me
to
the
next
slide.
L
Yeah
multiple
institutions
individually
sent
their
interest
to
the
tsv
wg
mailing
list
and
or
expressed
it
as
a
part
of
the
formal
liaison
request
from
a
gsma
on
the
right
side.
You,
you
see
the
logos
of
all
the
supporters
who
were
who
were
engaged
here
beside
that.
We
also
worked
on
many
other
things,
so
we
published
in
the
meantime
an
open
source
linux
reference
implementation,
which
is
available
at
multiparse
dccp.org,
which
provide
the
basic
and
mpdccp,
but
also
with
a
flexible
modular
scheduling
and
reordering
scheme.
L
L
There
was
also
some
discussion
on
the
mailing
list
about
the
implementations
and
testbeds,
which
are
available
so
city
university
of
london
and
british
telecom
announced
some
testbed
activities.
There
is
a
testbed
in
in
sweden
with
cardstock
university.
That's
also
quite
interesting,
because
it's
not
just
using
the
linux
reference
implementation.
L
Yesterday
there
was
a
note
on
the
on
the
mailing
list
about
the
existing
ipr
disclosure,
so
that
one
has
been
updated
on
monday
and
declares
a
lost
relation
to
the
mptc
speed
draft
after
a
european
patent
offers
a
review
process.
Unfortunately,
it's
not
possible.
It's
not
published.
It's
at
the
secretariat,
which
is
probably
busy
due
to
ongoing
ietf,
so
I
hope
within
the
next
day
that
will
be
published
yeah.
Moreover,
we
also
published
two
papers
at
a
rw21
that
was
part
of
the
monday
session.
L
Also
some
individuals
offered
already
that
they
would
support
in
reviewing
the
drafts.
You
find
the
names
here
at
the
bottom
of
the
slide
yeah
coming
now
to
the
next.
It
was
the
last
slide
to
the
conclusion.
We
believe
that
we
are
now
mature
enough
to
go
for
adoption.
That's
why
we
want
to
request
it
here
if
this
would
be
conducted
in
a
timely,
timely
manner
that
would
also
open
the
room
to
provide
mpdccp
as
a
solution
into
the
started.
3Gpp
release,
18
discussion
on
80
triple
s.
L
B
A
A
B
A
B
Adoption:
okay,
an
adoption
call
is
always
made
on
the
itf
mailing
list,
so
normally
would
take
a
sense
of
the
room
to
get
some
clarity
about
whether
that
adoption
call
was
felt
by
the
people
in
the
room
and
we've
done
the
basic
test
there,
and
we
can
note
that
there
was
strong
support
for
work
in
this
area.
So
the
adoption
call
will
be
for
adopting
this
particular
draft,
and
we
will
start
that
on
the
working
group
mailing
list.
L
The
the
only
relation
I
see
that
mp,
quick,
combined
with
data
chrome
extension
combined
with
mask,
could
provide
a
similar,
a
similar
deployment
as
as
we
proposed
with
mpdccp,
but
we
think
it's
much
more
much
more
complex
and
and
much
more
heavy
you're
going
to
take
yeah,
probably
probably
yeah,
that
that
is
really
what
pushes
us.
So
our
goal
is
to
to
bring
this
into
3gpp
and
and
hopefully
get
the
gap
fixed
there
in
the
release.
18
time
frame.
B
E
All
right
yeah
just
to
to
maybe
for
the
information,
the
community,
so
we've
we've
approached
quick
a
number
of
times
about
maybe
taking
up
a
multi-path
work
item,
and
I
think
it's
a
fair
summary
that
they
are
not
interested
at
this
time.
One
thing
I
am
excited
about
is
that
this
I
think
I
think
there
are
generic
multi-path
problems
that
are
protocol
independent
regarding
scheduling
and
so
on.
E
That
are
research
questions,
at
least
at
this
point,
and
I'm
I'm
excited
that
we
all
have
a
good
platform
between
fbtcp
and
mpdccp
to
explore
those
experimental
questions
and
then
one
day
come
come
to
back
to
this
working
group
or
maybe
a
special
group
to
actually
standardize
whatever
the
outcome.
That
research
is.
M
I
just
would
like
to
clarify
the
state
in
3gbp
on
what
atss
is
doing
so
in
for
release
18.
There
was
people
were
much
in
favor
of
using
a
quick
based
solution,
but
because
mp,
quick
wasn't
available
at
the
time.
This
was
delayed
until
I'm
released
18
now
so
kind
of
the
discussion
starts
over
again,
but
so
far
I
have
not
seen
a
proposal
for
using
mpdccp
and
so
far
I've
sensed
a
lot
of
support
for
using
some
kind
of
quick
based
solution.
L
Yeah
yeah,
just
just
to
give
some
words
here,
you're
absolutely
right,
but
I
think
that
is
because
there's
no
alternative
so
far,
which
is
seen
by
three
tpp
and
with
a
potential
working
group
adoption
of
the
mpdccp.
There
is
an
alternative
which
which
can
be
used
and
then
it's
depending
for
sure
on
the
supporter
on
people
or
our
companies
who
support
this
proposal,
then
sure,
but
the
room
is
open
in
release
18.
I
think
for
alternatives.
A
A
B
Marcus
as
well
say
thank
you
for
for
bringing
this
here
and
we'll
be
carrying
this
story
on
the
mailing
list.
I
was
also
going
to
say
that
there
are
a
number
of
things
that
will
be
brought
up
on
the
mailing
list
and
you
need
to
keep
your
eyes
out.
We
have
an
adoption
call.
We
have
some
working
group
last
calls
and
we
will
have
some
important
decisions
to
make.
So
please
keep
your
eye
on
the
mailing
list.