►
From YouTube: IETF112-TSVWG-20211112-1600
Description
TSVWG meeting session at IETF112
2021/11/12 1600
https://datatracker.ietf.org/meeting/112/proceedings/
A
Okay,
we're
going
to
use
the
meat
echo
slide,
sharing
tool
so
chairs,
which
means
yours
truly,
is
going
to
be
advancing
slides.
I
will
try
to
listen
carefully
for
for
next
slide
and
other
q
and
other
cues.
B
Well,
this
is
the
last
session
of
this
current
ietf
plenary
meeting.
The
tsvwg
is
meeting
in
this
session.
I'm
gauri
fergus,
I'm
one
of
the
co-chairs
here
david.
Can
you
introduce
yourself.
A
I'm
I'm
david
black,
another
co-chair
other
side
of
the
atlantic
from
gory.
C
And
west
and
I'm
wes
eddy
and
I'm
on
the
same
side
of
the
atlantic
as
david.
B
We
are
going
to
cover
a
set
of
drafts
on
transport
topics.
If
you
haven't
read
the
note
well
at
this
point
in
the
ietf,
it's
a
good
time
to
go
and
read
it.
Otherwise.
I
expect
you're
familiar
with
this
slide
from
other
talks
this
week
next
side,
here's
our
agenda
for
session
two
and
we're
going
to
keep
the
agenda
review
very
short
and
within
it
we're
going
to
invite
michael
to
give
a
brief
update
of
what
happened
in
rfc
496.
B
All
this
as
it
passed
working
group
last
call
and
he's
now
waiting
on
the
iesg
tele
chat.
B
Then
we
will
look
at
two
sctp
drafts,
followed
by
two
drafts
relating
to
udp
options,
a
dccp
draft
and
finally,
some
discussion
of
the
diffser
specs,
this
more
or
less
fills
our
time,
but
as
ever,
we're
interested
in
receiving
questions
and
feedback
on
the
mic.
A
So
that
we
can
move
up
yeah
one
note
for
the
ad
holding
tspwg
down
to
two
hours
this
meeting
week
did
not
work.
We
needed
we
needed
at
least
three
to
four,
and
so
everybody
everybody
gets
squeezed
also
for
the
sharp-eyed
readers
paying
attention
the
there's
an
ietf
token
missing
from
the
name
of
the
very
last
draft.
From
this
slide,
we're
hoping
people
can
figure
out
where
to
follow
this
draft
ietf
tsvwg
dscp
considerations.
A
B
B
We
expect
an
interim
to
come
in
the
next
ietf
period,
and
so
please
help
the
chairs
prepare
for
that
interim
and
look
out
for
it
when
it's
announced
and
we
will
discuss
support
for
starting
an
adoption.
B
Call
of
this
we've
already
done
this.
This
is
an
old
slide
that
got.
B
And
rst
496-
or
this
is
on
the
tele
chat
nuts
up
past
working
group
last
call
then
received
some
external
review,
as
we
invited
an
external
reviewer
to
look
at
it.
It
received
review
comments.
B
B
B
Here
so,
let's
see
if
we
can
get
a
this
is.
This
is
michael
tuxen's
slide
on
this
little
head,
michael.
D
D
We
have
the
director
directorate
reviews
and
we
have
ad
reviews
and
some
of
them,
where
the
form
the
protocol
could
change
in
a
substantial
way
which
were
rejected
and
some
other
changes
which
were
incorporated
next
slide.
D
There
was
a
discussion
with
the
security
people
on
the
cookie,
so
it's
made
explicit
that
the
content
of
the
state
cookie
is
implementation,
dependent
that
the
cookie
is
not
encrypted,
or
at
least
that's.
The
specification
does
not
require
it
to
be
encrypted
and
that
the
key
used
to
sign
this
stuff
should
be
changed
frequently
and
frequently
is
specified
as
hourly,
for
example,
the
limits
for
outstanding
tsns
and
ssns.
D
Well,
we're
using
should
not,
and
that
is
chain
has
been
changed
to
must
not,
and
one
other
change
was
that
during
slow
start,
the
condition
was
only
increased
if
the
comb
egg
point
has
been
moved
forward.
This
has
been.
This
was
changed
in
earlier
versions
of
the
specification
this
applied
to
slow
start
and
congestion
avoidance.
This
was
changed
for
congestion's
avoidance,
but
not
for
slow
start.
This
is
now
also
changed
for
slow
start
and
the
ayanna
section
has
been
updated
and
it
was
missing
a
policy
for
the
ppids.
D
B
Thanks,
michael,
if
anybody
has
questions,
please
ask
michael
and
if
there
are
any
people
who
want
to
look
at
that
draft
and
spot
something
that
needs
to
be
addressed
or
tweaked
within
those
changes,
then
please,
let
us
know
it's
still
changeable,
but
we
we
believe
it's
finished
and
therefore
it
will
be
on
the
telechat
agenda
in
december.
D
Yeah,
this
document
came
back
to
the
working
group
and
I
submitted
version
23
just
because
to
keep
it
alive.
There
are
no
changes
made
right
now
we
got
two
reviews
from
ads
magnus
and
martin,
and
there
is
an
alternative
suggestion
from
claudio.
So
next
slide.
D
Basically
the
the
major
issues,
except
for
wording,
clarification
whatever
is-
are
listed
here,
handing
off
ip
fragmentation
at
the
net.
I
don't
know
how
to
address
that,
so
controlling
net
friendly
behavior
of
an
endpoint.
So
how
does
an
endpoint
know
that
he's
behind
an
ad
and
should
behave
like
this?
This
is
addressable
by
looking,
for
example,
at
the
local
addresses,
multi-homing
support
of
internal
hosts
can
be
improved.
Support
of
multiple
external
addresses
should
be
improved.
D
Remote
addresses
are
not
in
the
nut
binding
table.
They
were
removed
there
to
make
things
simpler.
This
was
it
was
requested
that
this
should
be
put
back,
at
least
in
the
case
where
restarts
are
not
disabled.
D
It
was
the
point
about
the
pack,
the
the
complexity
of
packet
processing
at
the
middle
box.
So
does
the
middle
box
need
to
understand
chunks
or
not,
and
basically
the
most
substantial?
In
my
view,
comment
is
that
the
stock,
the
current
document
changes
the
definition
of
an
association
that
takes
the
verification
tag
into
account
and
has
to
deal
with
the
case
that
this
is
not
supported
by
the
endpoints.
So
basically,
these
are
the
major
issues
and
if
you
go
to
the
next
slide,
then
these
are
potential
ways
forward.
D
One
is
to
improve
the
current
method,
which
addresses
issue
two
to
five.
That
will
make
things
more
complex,
and
one
of
the
issues
also
was
that
the
document
is
already
complex,
so
another
way
to
move
forward
would
be
just
to
use
the
fallback
algorithm.
So
basically,
it's
like
the
endpoints
have
this
understanding
of
this
verification
tag,
but
it's
important
for
the
association,
and
if
this
is
not
possible,
then
they-
the
document
already
has
a
fallback
mechanism,
and
we
could
just
use
that
for
that
mechanism.
D
That
would
address
issue
two
to
seven,
which
is
basically
never
disable
restarts.
Don't
use
verification
tags
anymore,
just
do
net,
as
you
would
do
it
if
you
come
from
udp
or
tcp
land
and
it
reduces
complexity,
it
increases
the
change
of
chance
of
collisions.
D
The
third
way
would
be
switch
to
claudia's
draft
and
drop
the
current
working
document
or
the
fourth
solution
would
be
just
drop
the
work
or
not
at
all,
basically
saying
if
we
go
for
two,
this
is
very
similar
to
udp
or
udp
or
tcp,
so
we
don't
need
to
specify
it.
The
only
way
would
be
how
do
the
endpoints
behave
that
wouldn't
be
specified,
so
these
are
the
four
options
how
to
move
forward
and
that's
what
I
need
input
on
before
changing
the
document.
B
So
does
anybody
currently
on
this
call
wish
to
make
contributions?
Do
you
want
to
comment
on
any
of
these
methods
or
or
offer
to
review
them.
E
E
B
F
B
Yeah
this
has
been
the
longest
work
item.
We've
had
and
that's
not
been
through
lack
of
interest,
but
maybe
because
we
took
on
higher
priority
things
in
between
so
it'd
be
nice
to
see
this
finish,
and
I
don't
want
to
go
for
option
four,
but
inevitably
that
will
be
the
option
we
arrive
at.
If
we
don't
get
conclusion
quite
soon.
G
G
G
G
G
G
D
So
we
we
we
verify
path
before
we
start
using
them,
and
this
kind
of
stuff
is
an
scp.
B
I
think
probably
we
should
take
this
as
an
email
thread
on
the
list.
It
sounds
like
anything
that
probes
into
the
security
aspects
is
likely
to
help
shed
a
little
bit
of
light,
whether
we
need
new
text
or
not.
I
guess
we'll
become
quite
clear
as
we
discuss
it.
Okay,
thanks
christian,
really
appreciate
it.
E
There
so
yes,
so
I
I'm
here
to
talk
about
the
details
of
stp
this
work,
so,
yes,
we
have
done.
Ericsson
has
done
two
ipr
disclosures
related
to
this
draft.
E
It
requires
re-keying
with
probably,
if
you
have
monkey
exchange,
to
ensure
forward
secrecy
to
reduce
the
impact
of
any
key
reveal,
and
we
also
need
to
re-key
stb
auth,
even
if
that
algorithm
is
strong
with
shock
256
and
has
a
long
lifetime.
It's
it's
not
that
long
so
probably,
and
we
also
want
to
support
both
dtls
1.2
and
1.3
for
having
a
upgrade
path,
ensuring
that
we
actually
can
move
forward
with
details
versions.
So
next
slide.
E
So
in
those
issues
we
hadn't
discussed
slot
meeting
emeralds
in
the
new
draft.
We
are
proposing
parallel
dtls
connections
and
there
were
several
issues
that
led
us.
Here
I
mean
detail,
is
1.3
lacs,
mutual
real
authentication
and
has
no
forward
secrets
providing
re-keying
and
dts.
E
1.2
renegotiation
is
unsecured
without
neutral
authentication
and
therefore
it's
often
disabled,
even
if
in
this
use
case
it
would
be
with
mutual
authentication,
and
we
also
struggle
with
determining
when
keys
for
detailers
and
ssv
oauth
could
be
retired
so,
preferably
without
requiring
draining
at
key
updates
so
and
that
be
draining.
I
mean
getting
all
messages,
flushed
out,
basic
footed
connection
to
idle
and
then
re-key
so
solution
we
propose
here
is
to
use
the
dls
connection
spiral.
E
So
when
you
need
to
re-key
or
reauthenticate
the
pair,
you
initiate
a
full
detail
as
handshake
to
enable
this.
We
use
details,
connection
ids
in
all
details,
records
to
multiplex
on
and
because
we're
also
saying
we
don't
need
me
to
have
more
interview
live
at
any
point.
A
single
byte
connection
id
is
fully
sufficient
for
this
use
case
and
they
can
wrap,
and
that
will
be
many
many
hours
between
reducing
the
same
connection,
id
representation
so
and
when
you're
gonna
switch.
E
You
have
to
when
all
else
details
record
records
protected
by
the
old
key
has
been
sent
and
acknowledged
in
a
non-renegable
way,
so
you
know
that
you've
emptied
out
the
pipeway.
You
know
that
all
all
stp
packets
related
to
these
sap
messages
are
on
on
the
receiver
side.
Then
you
go
forward
and
close
the
details,
connection
that
has
these
keys
related
to
and
it
becomes
the
sender's
responsibility
for
this
and
you
do
it
in
each
direction
individually
to
this
indication.
So
when
both
has
closed,
you
can
remove
the
whole
details.
E
So
the
benefits
you
see
it's:
they
have
no
dependency
on
detailers
for
keying
or
re-authentication
features.
There's
no
functionality.
Changes
between
support
and
detail
is
1.2
or
1.3.
We
think
this
is
a
good
property
here.
E
We
currently
see
no
limitations
of
the
number
of
reakings
you
can
perform,
which
we've
before
had.
We
have
neutral
video,
authentications
and
and
full
different
helm
in
exchange
for
each
time
you
rekey
with
forward
secrecy
and
the
key
reveal
basically
comes
limit
to
a
single
key
period.
So
if
you're
working
every
hour,
the
most
data
leak
is
one
hour
basically,
and
it
becomes
very
hard
to
attack
this
because
then
you
basically
need
to
be
able
to
authenticate
as
the
pair
so
yeah
and
yes,
so
this
needs
feedback.
E
The
target
here
would
be
to
go
towards
working
blast
call
after
review
and
draft
updates,
and
we
are
sleeping
a
bit
on
the
timelines
here,
that
we
really
thought
we
could
hold,
but
that's
with
from
the
struggle
of
finding
a
solution.
I
think
so.
B
H
E
I
mean
we
are
declared
ipr
on
that.
We
we
have
some
ipr
that
we
think
relates
to
this
draft.
We
have
made
licensing
statements
about
that.
We
will
license
it.
It.
E
Yes,
I
understand
from
I
mean
parker's
comments.
Is
that
certain
open
source
implementations,
but
perhaps
struggle
with
implementing
this
but
yeah
and
and
the
comment
that
I
I
mean
one
thing
I
can
see
here:
if
the
problem
is
that
we
replace
683,
I
mean
we
don't
need
to
obsolete,
we
need
a
spec.
That
is
a
solution
that
we
can
give
to
provide
to
3dpp.
So
if,
if
the
problem
is
that
the
obsolete,
the
so
far
non-claimed
is
where
there's
no
ipr
claims,
I
mean
that's
fine
for
us,
it's
from
our
perspective.
B
Thank
you.
I
think
we
will
have
to
revisit
the
ipr
status
as
we
progress
the
work.
But
let's
take
michael
tucson's
comment
as
well.
Michael.
D
D
Http
wise,
dtls,
wise,
it's
implemented
in
open
source
implementation,
so
you
can
use
open
source
stacks
for
http
for
dtls
and
networks,
and
I'm
concerned
about
replacing
this
with
something
which
is
iprs,
which
we
don't
know
yet,
and
I
mean
well,
we
don't
know
yet
what
what
the
iprs
cover
and
so
right
now.
This
can't
be
implemented
in
any
open
source
implementation.
D
That's
what
I'm
concerned
about
and
what
I'm
not
sure.
If,
if
that's
the
direction,
the
working
group
wants
to
go-
or
I
mean
the
goals
are
fine
and
I
think
the
original
spec
needs
an
update,
but
I'm
not
sure
if
the
working
group
wants
a
version
which
is
ipr
protected.
B
We
don't
have
to
obsolete
the
current
spec
and
we
could
progress
with
this
work
as
an
adopted
item
it
already
is
adopted
or
we
could
do
something
and
slightly
different,
but
we
should
tackle
this
at
a
future
date
and
finish
this
spec.
I
would
encourage
magnus
to
continue
working
on
it,
so
we
can
see
what
the
final
spec
looks
like.
Would
that
be?
Okay,
likeness.
E
Yeah,
yes,
from
my
perspective,
it's
it's
fine
to
let's
continue,
review
it
etc
and
see
that
it
works.
But
and,
as
I
said,
we
have
no
problem
removing
the
obsolete
683.
If,
if,
if
that
makes
the
working
group
more
happy
from
because
I
think,
there's
there's
a
significant
difference
in
capabilities
here,
which.
B
Yeah,
that
is
certainly
one
of
the
things
that
we
should
consider
at
the
next
meeting,
whether
we
should
remove
the
obsolete
line.
Whether
people
are
happy
with
this
progress
and
I'd
also
like
you
to
try
and
talk
about
who
might
implement
this
specs.
So
we
can
have
some
experience,
but
who
will
review
it
and
implement
it
as
we
get?
The
document
finished.
B
Is
that
okay,
like
this
yeah,
yes
cool,
I
thought
you
would
say
that
that's
good
at
that
case,
any
other
questions
or
we'll
move
on
to
the
next
draft.
B
So
the
udp
options-
what
we
talked
about
to
the
previous
interim
joel-
need
to
go
chase,
slides,
wait
a
minute
here:
yeah,
that's
fine,
joe
attended
that
and
he
has
a
slide
deck,
that
reviews
some
of
the
key
outcomes
of
that
meeting
and
talks
about
the
work
that
remains
for
udp
options.
So
I
shall
present
on
behalf
of
geotouch.
B
That's
great,
so
this
is
the
view
from
joel
tuch's
window.
The
view
from
my
window
is
complete
darkness
and
yeah
we're
in
different
places.
I'm
going
to
present
on
behalf
of
joe
so
next
slide.
If
we
can.
B
So
the
first,
the
first
slide
here,
is
about
an
update
from
the
interim
in
september,
at
which
we
discussed
the
ocs
option
and
important
changes.
That
emerged
were
discussed
as
options
on
this
mailing
list
previously
and
finally
appeared
in
the
text
of
the
id.
B
Really
is
an
option
that
only
exists
behind
the
frag
options.
So
this
note
is
quite
clear
in
the
text
and
please
check
if
that
was
one
of
the
concerns
that
you
raised
and
the
frag
option
has
been
rewritten
re-scoped
and
really
given
a
major
overhaul
which
started
at
the
interim
in
september
and.
H
B
B
Each
fragment
includes
per
fragment
options
that
are
placed
before
the
data,
and
these
options
relate
to
every
datagram
in
every
ip
packet
carrying
a
part
of
the
datagram.
That's
an
ip
fragment
and
they're
things
like
the
ocs,
which
are
always
present,
there's
also
the
possibility
of
having
per
reassembled
datagram
options,
and
they
appear
at
the
end
of
the.
B
The
idea
of
an
mrss
was
brought
up
at
the
interim
and
talked
about
there.
The
I
this
is
a
maximum
value
of
payload
that
can
be
present
in
a
udp
datagram.
It's
a
number!
That's
just
chosen.
It's
chosen
to
reflect
something
larger
than
the
typical
mtu
and
various
numbers
were
speculated
about
in
the
interim.
A
mailing
list
afterwards
and
joe
finally
chose
the
value
3000
as
the
default
expectation
that
a
receiver
could
reassemble
a
datagram
which
had
a
payload
of
3
000
bytes.
B
It's
designed
to
be
big
enough
so
that
you
can
get
a
sizeable
benefit,
but
not
too
large
that
it
claims
lots
of
memory
in
the
stack
when
it's
implemented.
B
B
B
B
And
otherwise,
apart
from
this
joe
believes,
he's
answered
all
the
issues
which
were
previously
haunting
the
spec
as
we
went
through
the
various
revisions,
wanting
lots
of
different
topics
to
be
addressed.
Joe
believes
he's
now
only
got
consistency
to
address
and
is
now
willing
to
take
more
comments
from
the
list.
So
that's
the
last
slide
comments.
Please.
I
I
would
say
that
there
are
at
least
two
more
issues
that
need
to
be
resolved.
One
of
them
is
that
we
don't
have
a
mechanism
spelled
out
in
the
specification
for
sending
pad
padding
packets
that
are
required
for
a
datagram,
p,
plm
tud,
it's
not
something
that
would
require
another
option.
It's
merely
a
means
for
the
upper
layer
protocol
to
be
able
to
specify
that
a
packet
is
inflated
up
to
a
certain
length
with
zeros.
I
On
the
end,
a
second
major
concern
that
I
have
is
per
fragment
options
having
them
at
all.
I
think
that
is
a
very
significant
and
unnecessary
and
undesirable
complication
on
the
spec,
and
I
will
take
the
details
about
this
complaint
to
the
list
and
leave
my.
B
Comments
there,
thank
you
yeah.
Please
do
I
I'm
not
joe,
but
I
would
like
to
apply
a
one
per
fragment
option,
which
is
the
ocs,
which
is
probably
needed
for
traversal
of
a
nut,
all
right,
yeah
right
thanks,
so
so
we
should.
We
should
take
that
to
the
list.
I've
made
enough
of
those
two
issues
and
on
to
david.
Please.
A
I'm
simply
want
to
speak
up
to
support
the
conclusion
on
udp
mrss,
I
think
two
fragments
is
a
good,
is
a
good
design
choice
because
it
cleanly
addresses
the
tunnel
forces
from
fragmentation
case,
which
is
one
of
the
things
that
this
draft's
about
to
solve.
B
Okay,
thanks
david,
I'm
wait.
One
of
the
things
I
was
encouraging
with
my
chair
cut
on
was
really
for
anybody
who
expects
to
use
this
please
come
along
and
tell
us
either
tell
the
chairs
or
speak
up
on
the
list
and
say
what
it
is
you're
expecting
from
this
draft
and
use
cases
are
really
good
for
testing.
Whether
we've
got
all
the
features
we
have
in
the
right
places.
B
J
Nice
try
gary
you're
you're
involved
too
hi,
I'm
I'm
tom
jones.
This
is
our
document
that
describes
dplp
m2d
for
udp
options
or,
I
think
udpodplpmtud,
as
we
were
talking
about
in
transport
earlier.
It's
a
small
document
that
adds
the
necessary
features
for
udp
options,
intended
to
be
an
example
for
how
to
write
small
documents
like
this.
J
J
We
can
send
probes,
we
can
validate
the
path
and
we
can
do
ptp
handling
and
it's
nice
and
short,
it's
seven
pages.
Since
the
the
last
revision
the
document
was
adopted.
There
are
some
temporal
ordering
issues
between
the
adoption
and
the
zero
zero
because
I
was
on
holiday,
and
so,
if
I
have
the
next
slide-
and
so
that
gives
us
the
the
next
steps,
so
we
missed
one
which
was
text
on
generating
padding.
J
So
I
think
we
still
have
text
saying
you
can
use
knocks,
and
this
is
forbidden
by
udp
options.
This
is
fine
because
you
can
create
padding
by
adding
zero
bytes
to
the
end
of
the
packet
and
we're
actually
happy
with
this
method.
We
need
to
do
an
editorial
pass.
Gory
claims
there's
lots
of
typos,
so
I'm
waiting
for
a
pull
request,
but
we
need
to
go
through
and
be
very
thorough
on
this.
We
need
text
now
to
explain
how
dplp
m2d
works
with
fragments.
J
Now
that
fragments
are
starting
to
settle
down
and
because
we're
getting
happier
with
the
design
and
then
we'd
really
like
to
get
more
comments
from
the
working
group,
because
it's
the
way
to
move
the
document.
We
expect
this
to
complete
alongside
udp
options,
and
I
think
once
we've
done
the
the
first
couple
of
things
listed
here.
J
The
document
will
mostly
be
a
maintenance
mode
until
udp
options
is,
is,
is
ready
in
the
working
group
and
we'll
just
have
to
track
what
joe
changes
as
joe
changes
things
so
that
we
stay
in
sync
and
that's
all.
B
So
I'm
willing
to
give
up
time
for
questions
on
this,
because
it's
been
adopted
relatively
recently
and
we'd
like
to
ensure
that
it
can
also
be
working
group
last
cold
soon,
so
that
it
and
coincides
with
the
publication
of
udp
options.
Does
anybody
have
any
questions
about
the
presentation
by
tom.
A
B
Yeah
and
this
draft,
although
it's
kind
of
only
just
become
a
working
group
item,
has
been
around
the
working
group
and
presented
a
number
of
times
in
the
past,
so
there
have
not
been
major
changes
in
between
these
two.
It's
just
that.
We've
now
reached
the
stage
of
this
document
needing
review
from
people.
B
Well,
when
do
you
think
we
can
make
a
new
copy
tom.
J
B
Then
I'll
say
thank
you
ever
so
much
for
tom
coming
to
speak
on
our
joint
draft
right.
Sorry
for
the
speed
at
which
we're
going
through
this
meeting,
but
it's
good
that
we're
keeping
to
time
and
the
next
talk
will
be
by
mike,
but
no
marcus
on
mpdccp.
B
So
without
any
more
introduction,
would
you
like
to
update
us
on
version
two
of
your
document.
K
K
Ideally,
this
is
alive
with
the
timeline
in
3gp
release
18,
because
there
it
is
already
discussed
as
an
eight
as
part
of
an
anticlockwise
and
enhancement,
and
the
discussion
is
currently
in
the
phase
that
they
have.
I
think,
a
december
to
conclude.
If
this
goes
for,
study,
item
approval,
we
also
interfaced,
where
we
now
start
discussions
with
with
industry,
with
vendors
to
go
for
drawing
testbed
and
implementation
activities.
K
K
The
draft
development
is
ongoing
at
github
with
currently
eight
contributors.
We
have
an
established
process
with
issue
tracker
and
pull
request
used
for
reviews
and
and
updates
next
slide.
A
Please
marcus
what
what's
the
timing
you
need
on
this
to
align
with
3gpp
release,
18.
K
K
K
K
Then
we
added
a
very
important
section
from
our
review
on
fallback
strategies.
So
what
is
going
to
happen
if
a
multi-path
cannot
be
established
so,
for
example,
then
we
it
could
be
trigger
to
fall
back
to
single
path.
Dccp,
we
introduced
the
number
of
authors
to
be
compliant
with
the
rfc
editor
style
guide,
and
we
made
some
minor
editorial
things.
K
If
you're
interested
you
can
look
into
in
the
latest
version
we
published
this
week,
we
made
a
lot
of
progress
on
describing
a
new
hand,
checking
procedure
along
with
authentication
capabilities,
to
guarantee
a
safe
establishment
of
subsequent
flows.
I
will
come
to
this
in
the
next
slide.
Also
some
major
work.
We
did
on
defining
or
enhancing
the
multi-path
prior
option
for
fine
granular
steering
of
past
priorities,
backup
and
disable
part
that
goes
far
beyond
the
mp
prior
definition
from
mptcp.
K
Last
but
not
least,
we
improved
the
operational
section
of
the
draft
next
slide.
Please
yeah
now
coming
to
an
interesting
topic
which
we,
which
I
also
started
to
discuss
on
the
mailing
list.
I
shared
the
link
in
the
chat.
Now
let
me
explain
how
we
defined
so
far
the
hand
checking
procedure
and
how
we
improved
it.
So,
on
the
left,
you
see
the
initial
approach
we
had
in
the
draft.
K
It's
a
three-way
approach.
We
call
it
because,
first
of
all,
we
establish
the
multipath
connection
over
one
link
that
you
see
from
a1
to
b1.
It's
a
three
by
hand
track,
as
I
indicated
already
in
that
one,
we
negotiate
the
multi-pass
capabilities,
we
negotiate
key
material
for
later,
a
subsequent
flow
establishment,
and
so
on.
So
after
the
multi-part
connection
is
established,
so
the
three-way
handshake
was
successful.
It
is
safe
to
join
subsequent
flows.
K
The
issues
what
you
can
see
here
is
the
mp
join,
which
is
sent
from
a2
to
b1,
arrives
too
early
at
the
host
b
and
overtakes.
The
final
bccp
acknowledgement
from
the
initial
flow
then
there's
some
confusion,
because
the
multi-pass
connection
has
not
been
successfully
established.
The
mp
joint
tries
to
join
something
which
is
not
available
and
in
our
open
source
implementation.
K
We
then
react
with
the
dccp
reset
on
that
flow,
which
means
the
subsequent
flow
cannot
be
established.
That
is
not
what
we
want.
That's
why
we
drive
to
improve
this
in
the
draft,
as
well
as
in
the
open
source
implementation.
We
are
currently
working
now
on
implementing
what
we
propose
on
the
right
side
and
what
is
already
part
of
the
draft.
So
we
extended
the
three-way
handshake
by
an
additional
acknowledgement.
We
sent
from
the
host
b
to
the
host
a
with
that.
K
We
know
that
the
multipath
connection
has
been
initiated
successfully
and
it's
safe,
then,
to
start
the
joint
procedure
from
a2
to
b1.
It's
a
it's
a
simple
solution:
it
works.
We
could
be
happy
with
that.
However,
we
wonder
if
this
can
be
optimized,
because
it
adds
additional
delay
and
also
it
has
a
high
dependency
that
all
the
four
messages
of
the
initial
flow
will
arrive.
K
That's
why
we
come
to
some
proposals
on
the
next
slide,
starting
again
on
the
left
and
what
we
could
do
to
optimize
this.
We
could
again
go
to
a
three-way
approach
as
it
was
before.
However,
we
do
not
check
when
we
send
the
mp
join
and
the
amp
transfer
arrives
at
host
b.
If
the
multipath
connection
is
already
established,
we
do
it
at
a
later
point
with
the
final
dccp
economic
acknowledgement
of
the
join
process.
That
gives
us
more
time
or
that
gives
the
whole
establishment
process
more
time
that
the
initial
flow
is
successfully
established.
K
However,
that
only
works
if
there
is
not
a
too
big
latency
difference
between
both
paths.
Otherwise
we
run
into
the
same
issue
as
I
introduced
in
the
previous
slide.
That's
why
we
also
do
not
prefer
this.
However,
it's
a
valid
solution-
and
we
are
happy
to
discover
this
with
you.
The
preferred
solution
or
the
optimal
solution
bc
is
on
the
right,
because
that
reduce
the
latency
of
the
establishment
process
or
the
whole
time
of
the
establishment
process,
and
it
uses
the
dependency
on
the
initial
flow.
K
And
what
we
also
do
in
implementation
is
we
already
create
all
the
necessary
multi-parts
structures
in
the
network
stack
after
the
first
dccp
request
arrives
at
host
b,
then
we
reply
to
this
from
host
b2
to
host
a.
K
We
have
ensured
that
with
this,
these
two
messages,
all
the
key
material
is
exchanged
which
is
required
to
derive
the
tokens
and
hmax
for
a
subsequent
flow
establishment.
K
So
that
is
a
big
change
in
the
design
principle
of
the
of
the
hand
checking
procedure,
and
we
want
to
put
the
question
here.
If
this
is
a
good
proposal,
does
it
make
sense,
or
do
we
raise
raise
issues
like
providing
a
tech
surface
for
daniel
of
service
attacks,
because
we
create
multi-pass
structures
already
in
the
beginning
or
or
do
we
raise
security
issues
with
that
yeah?
That
is
the
point
I
would
like
to
discuss
today
with
you
coming
with
that
to
the
last
slide.
K
B
When
do
you
think
you
would
have
more
information
about
the
options
and
the
design
considerations
that
you
just
spoke
about,
I'm
wondering
whether
a
another
meeting
focused
on
specific
points
would
actually
be
a
better
focus
for
bringing
in
other
people
into
discussing
this.
Do
you
think
that
you
might
have
information
about
that
in
the
near
term?.
K
So
it
depends
on
on
what
you
expect.
So
if
it
is
just
a
presentation
to
make
a
deep
dive
into
the
issues,
then
I
think
we
can
go
quickly
for
that.
If
you
expect
to
have
those
different
designs
implemented
somewhere
and
then
it
maybe
takes
a
longer
time
or
it
will
not
be
possible
at
all,
because
we
do
not
plan
to
to
implement
them
before
we
have
the
discussion
with
with
the
itf
community.
K
Yeah,
but
I
would
prefer
and
fully
support
to
go
for
interim.
Maybe
we
can
combine
it
with
one
of
the
other
topics
like
http,
but
up
to
you,
what
you
think
is
best
or
having
a
separate
interim
yeah
happy
to
support
this,
and
I
think
we
can
go
quickly
for
that.
L
Yes
checking
here,
I
don't
have
solution
comments
for
your
your
strategy
here,
but
what
I
know
is
currently
in
essay
2,
3gpp
working
group.
It's
talking
about
atss
for
phase
3
for
release
18.,
so
it
discussed
the
possibility
to
provide
more
than
two
passes
actually
like
two
three
gtp
passes
or
two
non-switch
differences.
L
K
That
that
is
a
yeah.
Thank
you
for
this
question.
I'm
fully
aware
of
this
discussion
in
3gpp,
and
I
think
it's
a
misunderstanding
when
I
presented
today
the
figures
of
the
handshaking
process
that
are
very
generic
figures.
That
does
not
mean
that
we
are
limited
to
two
flows.
It's
the
opposite,
so
we
support
an
unlimited
number
of
okay.
Thank.
B
Thank
you
right.
Okay,
we
will
talk
more
about
this
on
the
mailing
list
and
if
a
meeting
is
what's
required
to
facilitate
something,
we
will
arrange
an
interim
meeting
for
this
and
the
next
one
will
be
greg.
Who
has
already
tried
once
to
be
on
the
agenda
and
now
gets
the
chance
for
the
last
five
minutes
of
this
particular
meeting
so
greg.
You
have
only
five
minutes
and
do
something
useful,
please
to
tell
us
about
enqueue.
M
All
right
I'll
skip
past
the
first
few
slides,
which
are
just
status,
in
fact
that
one,
I
is
a
list
of
changes
in
draft
08
that
I
sent
to
the
mailing
list.
So
that's
already
been
shared.
I'd
like
to
spend
a
little
bit
of
time
on
this
one.
M
M
I'm
going
to
give
some
examples
of
in
today's
network,
no
more
than
one
relatively
large
packet,
every
10
milliseconds,
roughly
a
megabit
per
second,
the
next
paragraph,
then
in
green
points
out
that
just
marking
your
packets
as
nqb,
doesn't
get
you
off
the
hook
in
terms
of
implementing
all
of
the
expected
features
to
make
your
application
safe
on
the
internet,
including
some
sort
of
congestion,
control
or
congestion
response
and
or
circuit
breaker
functionalities.
M
That
sort
of
thing,
and
then
the
last
paragraph
is
where
it
provides
a
specific
recommendation
around
not
marking
traffic
as
nqb,
based
on
the
the
sending
rate
and
and
the
current
text
in
that
kind
of
blue
green
color.
M
If
the
traffic
exceeds
more
than
a
few
packets
per
rtt
or
exceeds
approximately
one
megabit
per
second
on
an
instantaneous
inner
packet
basis,
the
application
should
not
mark
its
traffic
and
the
next
slide.
Then
we
can
go
to
that.
M
M
Maybe
it
would
be
better
to
base
that
on
something
that
that
evolves
over
time
and
suggestion
was
something
like
10
of
the
global
average
access
link
capacity
at
the
time
and
then
and
then
adding
an
example
at
the
time
of
writing
what
that
might
be
and
a
link
to
where
those
numbers
came
from
and
then
at
the
end
it
does
the
math
for
you
and
it
says,
a
very
typical
server
application.
M
That
implies
no
more
than
6.3
megabits
per
second,
at
an
instantaneous
rate
and
for
a
typical
client
application,
no
more
than
1.3
megabits,
and
here
the
because
interpretation
of
a
typical
server
is
effectively
a
server
or
an
application.
That
is
it's
not
aware
whether
it's
sending
traffic
over
a
mobile
access
network
or
a
fixed
access
network,
and
so
it's
the
lower
of
the
two.
But
it's
pretty
certain.
It's
not
sending
traffic
in
the
upstream
direction
on
an
access
network,
it's
almost
really
sending
in
the
downstream
direction
and
then
for
the
client.
M
It
takes
the
the
view
that
it's
almost
certainly
sending
traffic
in
the
upstream
direction,
on
an
access
network
and
but
again
may
not
know
whether
it's
mobile
or
effect,
so
it
takes
the
lower
of
the
two
questions
working
group
on
that.
Are
we
happy
with
this
with
scaling
the
recommendation
over
time
based
on
statistics
that
are
available.
A
At
the
time,
we'll
need
to
take
that
to
the
list.
I'm
concerned
that
you're,
using
average
across
a
distribution-
that's
non-uniform,
but
this
is
not
the
place
to
split
to
go
to
dive
into
the
the
statistics.
M
Yeah,
okay
and
then
moving
on
to
the
next
slide,
then
just
quickly,
I
think
that's
been
discussed
on
the
mailing
list.
Actually,
just
maybe
the
following
slide
a
question
from
my
anna:
what
should
these
nq
these
dsps
be
labeled
in
the
iana
registry?
Should
they
both
be
called
non-cue
building,
I
mean
we
should
label
them
separately
again.
We
can
discuss
that
on
the
mailing
list
and
the
last
slide
yeah.
We.
M
This
last
I
once
once
these
edits
have
been
made
and
we've
settled
on
those
I'm
hoping
we
can
go
to
working
group
last
call,
and
I
want
to
get
a
sense
from
the
chairs
as
to,
if
that
would
be
advisable
to
try
to
start
a
working
group.
Last
call
in
the
interim
before
the
next
idea.
A
I
think
it's
worth
drink,
trying
to
work
in
robust
course
shortly
after
the
first
the
year.
The
other
card
I'd
make
on
this
is
that
your
your
light,
blue
should
text
about,
should
not
use
for
high
bandwidth.
I
need
to
redirect
in
detail
there's
going
to
need
to
be
some
teeth
behind
that
something
that,
if
the
sender
does
that
the
network
that
the
network
is
entitled
to
to
to
evict
the
track
evict
that
flow
of
mqb
yeah,
okay.
B
So
my
fault,
I
started
the
poll,
then
I
realized
you
can't
press
the
mic
button
where
you
press
the
pull,
but
at
least
I'd
be
interested
in
getting
people
to
read
this
recent
version
of
the
spec
or
the
current
version
of
the
spec
and
see
how
near
we
are.
I
can't
really
answer
whether
we
need
more
time
or
not.
Please
look
at
it
on
the
list
and
tell
us
your
comments.
B
Thank
you
greg
and
david
wears.
Do
we
have
anything
else
that
we
should
say
I
I
have
one
more
presentation,
cued
from
anna
castura
and
I
think
anna's
going
to
have
been
caught
by
the
time
so
we'll
take
that
next
meeting
and
anything
else
from
my
co-chairs.
As
we
finish.
B
That's
fine
and
I
I
pled
to
place
a
standing
offer
to
anna
to
present
more
data
if
she
has
any
to
the
next
meeting
and
we
will
try
and
clarify
what
goes
in
that
document.
H
Yeah,
roger
that,
like
I
mean
I
think,
if,
if
if
it's
not
picked
up
a
study,
I
might,
I
think
we
need
to
reevaluate
what
we're
doing
for
sure.
B
Sure-
and
my
final
thing
is-
I
expect
there
to
be
an
interim
before
the
next
meeting,
so
please
keep
a
note
out
for
that.
If
you
have
things
that
you
think
should
appear
on
the
agenda
of
that
interim,
please
contact
the
chairs,
otherwise
we
will
hope
to
see
you
at
the
interim
or
in
person,
perhaps
at
the
next
ietf
meeting.