►
From YouTube: IETF109-TSVWG-20201116-0900
Description
TSVWG meeting session at IETF109
2020/11/16 0900
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
A
Yeah
those
would
be
my
mouse
clicks
waiting
for
gory.
I.
B
B
And
while
we
wait,
I
think
we
need
also
our
note-taking
and
jabber
scribe
roles.
If
anyone
wants
to.
A
A
David,
can
you
hear
us
yeah?
I
think
so
now
need
to
put
my
headset
on.
Let's
wait
wait
early
in
the
morning
here
I
don't
see,
I
don't
see
gory
yet.
A
All
right,
let
me
go,
have
a.
A
A
All
right
should
we
just
go
ahead
and
go
ahead
and
get.
B
Started
yeah
we
may
need
to
I
see
in
the
chat
pete
mentioned
that
gory's
on
regular
jabber.
I
guess
if
you
could
thank
him.
That
would
be
helpful.
A
Okay,
I
hope
this
works
welcome
to
transparent
working
group
jsvwg
at
ietf
109..
This
is
the
notewell
slide.
Please
read
it.
It
applies
to
you,
okay.
I
need
folks
to
watch
the
jabber
window
and
take
notes.
Although
I'm
hoping
is
simply
with
the
clever
note
taking
tool,
we
can
get
all
the
notes
captured
as
we
go
along.
A
C
If
that
simply
means
relaying
questions
to
the
mic,
I'm
I'm
glad
to
do
that.
I
I'm
probably
a
little
too
stupid
to
make
useful
notes.
A
Of
things,
relaying
questions
to
the
mic
is
what's
wanted
in
case.
We
stop
paying
attention
attention
to
the
chat
window.
The
detachable
chat
should
be
gatewayed
into
into
jabber,
and
it
should
all
work
very
good.
I
can
do
that.
Please
do.
Thank
you.
A
Somebody
want
to
volunteer,
be
note,
taker
to
make
sure
we
get
crucified
captured
the
notes.
We
don't
we
we
don't
need
blow-by-blow.
We
just
need
to
keep
key
key
points
and
key
decisions
made.
D
A
A
Okay,
a
little
bit
on
medieco
usage
tips
chat
can
be
separated
into
a
jabra
like
window
and
you
can
open
up
the
note
taker
tool
which
is
kodi
md
in
a
separate
editor
tab
or
window
that'll.
Enable
me
echo
to
stay
focused
on
the
meeting
for
discussion.
Please
use
meat,
echo
mic
cue,
click
hand
the
hand
plus
microphone.
I
can't
join
the
mic.
Cue
please
avoid
the
triangle
plus
microphone.
Icon
till
we
tell
you
to
interrupting,
is
not
not
not
a
best
practice.
A
A
There
we
go
that
might
look
better
now.
I've
got
a
slide,
footer,
okay,
review
of
what
we've
done.
There's
been
one
rfc
published
since
the
last
ietf
datagram
pl
pmtud,
rfc
8899,
the
diffserv
and
webrtcqs
draft
is
still
in
the
authors.
48
done
state
at
the
rfc
editor
sometime
soon
it
is
promised
or
threatened
all
of
the
webrtc
cluster
drafts,
including
this
one
infamous
cluster
238
will
be
published.
A
We
have
one
id
at
the
iesg,
our
area
director
is
reviewing,
or
if
you
like
evaluating
this
is
transport
header,
confidentiality.
A
We
have
three
internet
drafts
with
the
chairs
and
authors
after
a
glass
call.
The
two
east
ecn
drafts
where
bob
and
I
need
to
work
over
the
fragmentation
text.
I
see
you
posted
new
versions
this
morning.
I
will
read
them
when
I'm
when,
when
I'm
more
awake
and
see
whether
how
close
we
are
to
fragmentation
text
will
get
the
job
done.
Sctp
nat
support.
That's
with
the
shepherd
who
is
gory
and
it's
winning
doc
shepard
write-up.
We
have
no
unit
drafts
worker
glass
call.
A
There
are
six
other
drafts
in
the
working
group,
the
main
sctp
revision,
the
three
elf
rest
drafts,
the
non-queue
building
of
php
draft
and
the
udp
options
draft.
We
might,
there
will
probably
be
requests
to
adopt
more
drafts
than
me.
I
think
I
think
at
least
one
more
in
the
udp
options
area.
A
A
There
is
a
path
into
discover:
ipv6
draft
over
in
six
man,
the
low
latency
docsis
draft,
including
including
docs's
q
protection,
have
been
submitted
to
the
independent
submission
editor,
the
udp
options
for
datagram
path,
mtu
discoveries-
this
is
actually
dplpm2d
doing
it
by
udp
options
is,
and
is
this
individual
draft
draft
fairhearst
we
have
an
offers
operations.
A
Draft
michael
clickson
has
a
draft
on
udp
and
caps
considerations
for
sctp
and
there's
a
couple
of
drafts
listed
here,
proposing
new
work
on
congestion
control,
okay
agenda:
we
are
in
the
middle
of
bashing
the
bashing
the
agenda
monday
is
dr
calls
with
the
status
milestone,
review
coming
up
next
drafts
and
wednesday
agenda
is
more
drafts.
The
l4s
and
nqb
drafts
are
on
wednesday.
A
Okay,
milestone,
review,
hang
on.
Okay,
sctp
nat
support
is,
was
a
september
milestone,
it's
almost
done.
No
date
change.
We
submitted
to
our
ad
for
processing
towards
becoming
an
rfc
shortly
we
had
an
opportunity,
an
october
2020
date
on
one
of
the
off
restaurants.
That's
been
moved
up
toward
2021
with
all
the
alfres
drafts.
A
A
We
can
get
those
published
this
month,
so
don't
change
those
drafts
december
2020
submit
sctp
as
a
proposed
standard
rfc
we're
going
to
need
to
move
that
date
into
sometime
early
next
year-
probably
mark
probably
mark
mark
march
or
april,
and
then
these
are
the
remaining
milestones,
the
udp
options
draft
and
the
end
the
the
nqb
draft
currently
for
february,
we'll
see
whether
those
happen
or
not
adjust
those
at
the
next
meeting
if
they
don't
and
then
a
couple
of
october
milestones
for
the
alfresco
wraps
and
we'll
move
the
other
alfresco
drafts
out
here.
A
Let
me
just
quick
check.
Yes,
we
have
nine
drafts,
nine
milestones,
so
it
matches
the
chairs
are
doing
cherry's
doing
something
to
earn
our
exorbitant
salaries.
A
Okay,
this
is
the
I
was
in
the
queue.
I
think
he
probably
wants
to
talk
about.
The
l4s
milestones,
yeah,
okay,
so
so
I'm
staring
at
powerpoint,
which
makes
it
a
little
harder
to
to
look
at
the
queue.
E
By
the
way
I
I
now
have
fibre
to
the
home,
rather
than
a
little
bit
of
verdigris
connected
by
copper
atoms
anyway,
the
milestone
I
I
did
send
a
note
to
where's
asking
why
that
had
been
put
out
to
october
2021
when
we
noticed
it
had
happened,
didn't
see
any
conversation
about
it
and
we've
been,
you
know,
pulling
out
all
the
stops
to
get
them
all
done
for
this
meeting.
So
I'm
not
sure.
What's
going
on
there.
A
E
I'm
sure
it
was
you,
but
it
might
have
been
wes
anyway.
What's
going
on.
A
A
successful
worker
glass
call
on
l4s
requires
the
working
group
to
get
to
rough
consensus
that
it's
safe
to
run
the
experiment
on
the
internet,
and
I
I
was
on
the
impression
the
carrier
for
that
for,
but
that
mature
was
going
to
be
the
operations
draft.
E
A
Okay,
I
mean,
I
don't
believe
that
goal.
Let's
see
that
goal
of
needing
a
safe,
a
safety
case
should
not
be
a
surprise.
The
mechanics
of
doing
so.
A
I
believe
I
believe
that
was
stated
in
the
conclusion
of
from
the
interim
meeting
and
when
we
decided
we're
going
going
to
move
forward
focusing
on
restaurants.
It
was
stated.
A
I'll
have
to
go,
dig
we'll
have
to
go,
dig
dig,
we'll
have
to
go
dig
out
the
various
things
my
understanding
is,
that
is,
is
that
the
working
group
has
to
come
up
with
a
safety
case.
Now.
If
you
believe
that
the
main
drafts
contain
the
safety
case,
we
can
try
that
yeah.
B
So
I
would
think
that
the
key
is
not
the
status
of
the
other
draft,
but
rather
the
working
groups
feeling
that,
what's
going
into
it,
is
going
to
work.
Yeah.
B
E
As
long
as
there
was,
you
know
the
the
the
if
you
like
the
concepts
behind
it
or
the
or
the
you
know
the
the
the
way
forward.
As
long
as
there
was
consensus
on
that,
the
actual
text
didn't
have
to
have
been,
you
know,
finished
and
gone
to
working
group
last
call
yes,.
F
A
Certainly,
certainly
a
possibility,
we
need
to
come
up
with
a
tentative
date
to
move
all
to
move
all
move,
all
three
of
them
too.
G
I'm
all
scoring
here
I'd
be
okay
to
consider
working
group
last
calling
these
documents
as
soon
as
they
are
ready
to
be
working
group
last
cold.
G
I,
when
they
progressed
to
the
iesg's
just
when
they
progressed
to
the
isg.
When
that
safety
case
is
clear
and
the
milestone
doesn't
really
change
this
time.
Does
it.
E
It
sounds
like
this
is
why
we
got
mixed
or
got
the
wrong
message,
because
different
chairs
seem
to
be
saying
different
things.
A
Mm-Hmm,
I
I
I'm
quite
certain
that
the
the
the
notes
that
we
were
sent
out
after
we
got
through
all
of
the
decisions
made
around
that
we're
going
to
focus
on
for
us
says
a
successful
working
glass
call
requires
requires
there
to
be
us
to
be
a
satan
to
be
a
safety
case.
G
E
Yeah,
I
mean
put
it
this
way,
all
the
the
three
main
alphas
documents-
I've,
you
know
pulled
out
all
the
stops.
I
just
reposted
them
all.
Last
night,
they've
all
been
spell
checked.
Grammar
checked,
they've
been
stable
for
a
while
we've
been,
you
know,
battering
on
the
wording,
so
they're
ready
for
working
group
last
call
and
it
does
no
harm
to
go
through
a
working
group.
Last
call,
even
if
they're
not
going
to
go
to
the
iesg.
A
Well,
at
the
very
least,
we
know
we
have
to
settle
the
queue
protection
issue
before
we
take
work.
Group
last
call
yeah,
and
I
think
we
need.
I
think
we
we
need
to
understand.
Where
would
understand
where
the
safety
where
the
safety
case
is
is
to
is
to
be
found.
A
A
All
right,
I
think,
chairs,
will
will
will
consult
offline
with
first
draft
authors
to
figure
out
what
the
what
the,
what
the
new,
what
the
new
milestone
ought
to
be
october.
2021
might
be
too
far
out,
but
I
don't
I
don't
think
it's.
I
don't
think
it's
this
month.
I
may
be
I
I
could
be
wrong
and
surprised.
A
A
A
I
can't
quite
figure
out
where
the
slide,
where,
where
the
slide
is
we're
going
to
do
a
sctp
udp
options,
both
the
main
uv
options
draft
and
the
draft
on
the
gdp
options
for
datagram
popm2d
in
qb
draft
dccp
extensions,
then
here's
the
wednesday
agenda,
l4s,
okay,
we
haven't.
Yes,
we
managed
to
move
and
nqb
into
today.
L4S
is
most
of
when
it
is
the
entire
the
entire
wednesday
session.
A
If
we
get
really
lucky
and
run
short
today,
we
might
start
in
on
some
of
the
alphas
topic
alpha's
topics
today.
Okay,
so
now
hang
on,
that's
not
gonna
work.
A
A
I
think
next
up
is
and
is
a
one
slide
update
on
sce,
which
I
haven't
looked
at
before
I
click
on
this.
Let's
see
what
happens
here,
it
is.
A
So
jonathan
you
wanna
say
you
do.
Do
you
wanna
say
a
few
words
about
this
slide.
F
We've
been
putting
sc
in
the
background
for
now,
while
the
working
group
is
dealing
with
l4s
as
agreed
in
march,
we
have
updated
our
main
draft
to
bring
it
up
to
date
with
our
technical
process
progress
over
the
past
year,
we
have
a
more
detailed
design
rationale
and
an
outline
of
our
use
of
diffserv
to
perform
an
isolated
experiment
on
internet
scale
paths
and
I'd
also
like
to
say
that
we
are
now
funded
for
the
next
year,
so
we
will
carry
on
working
in
the
background
and
of
more
immediate
concern.
F
We
have
recently
posted
a
fresh
set
of
red
team
tests
about
l4s
performance
and
we've
kicked
off
some
discussion
of
that
on
the
list,
and
we
will
continue
to
do
so.
A
Okay,
I
something
didn't
work
in
the
slide
material
for
generic
transport
functions.
I
got
a.
I
got
a
zip
archive
that
I
have
no
idea
how
how
how
display
let's
try
this
thing
and
see
what
happens
this
other
one
see
what
happens.
A
Okay,
the
author
want
to
say
a
few
words
about
this
draft
draft
aside:
tscwg
transport
review:
okay,.
H
Okay,
can
you
hear
me?
Yes,
I'm
just.
I
propose
I
debut
the
transport
radio
authority
to
develop
a
new
protocol,
transformatory
protocol
for
new
distributed
computing
paradigms,
such
as
the
communication
edge
computing
and
metal
computing.
So
I
reviewed
the
current
transporter
here
and
I
want
to
define
and
divide
the
transport
layer
into
the
two
sub-layers
data
path,
layer
and
the
data
flow
layer.
This
data
path
layer
should
handle
some
kind
of
related.
The
functions
related
to
the
audit
path,
such
as
the
demand,
trajectory
monitoring
or
waypoint
management.
H
That
is
related
to
the
the
I
can
say,
the
password
computing
research
group,
password
networking
research
group
and
it's
used
handled
by
direction,
connection
quality,
monitoring
for
congestion
control
and
they
throw
much
stretching
it
may
support
some
patent
duplication
for
the
highly
highly
reliable
communication
and
beyond
that
data
flow
layer,
handles
the
the
transmission
flow
control
from
prioritization
entertainment,
security
and
investment
breaching
for
multiple,
multiple
or
multi
multiple
transport
protocols.
So
please
leave
the
the
draft
and
then
discuss
it
on
the
mailing
list.
A
If
you're
interested
in
draft,
please
follow
up
with
the
mailing
list
and
with
the
author
directly
okay,
thank
you.
Thank
you
all
right.
A
A
A
Go
ahead,
kariki.
A
Okay,
to
go
ahead,
you
need
to
click
on
when,
when
we
tell
you
to
go
ahead,
you
need
to
click
on
the
the
mic
plus
triangle
button.
It
turns
to
my
plus
square
and
then
we
should
be
able
to
hear
you
there
we
go.
Thank
you.
No!
Yes,
now.
I
Oh
perfect,
okay,
I
was
talking
to
myself,
then
I'm
sorry,
which
is
not,
which
is
not
surprising.
It's
1
30
in
the
morning
for
some
of
us,
so
I
have
the
draft
I
mean
I
have
the
the
slide
on
generic
transport
functions.
I
can,
I
don't
know.
A
How
I
try
to
share
it
and
and
talk
to
it
for
for
for
a
cup
for
a
couple
of
minutes
go
ahead.
Luckily,
I'll
take
my
screen
off.
How
do
I
share
you?
A
A
A
I
A
A
All
right,
okay,
okay,
so
get
us
get
get
us
a
get
us
a
pdf
by
by
before
the
wednesday
meeting
and
we'll
put
that
up
at
the
start
at
the
start
of
the
wednesday
meeting,
I
think
the
thing
is,
I
think,
is
what
we
need
to
do.
We,
unfortunately,
do
need
to
move
on
all
right.
A
Okay,
so
what
I
think
is.
A
Next
is
sctp
this
update.
Michael,
do
you
want
to
speak
to
that?
I
don't
think
I
see
slides
for
that.
K
I
sent
slides
this
morning
no
yesterday
night
to
gauri.
L
A
K
K
Since
I
focused
on
the
net
document,
which
is
finished
now
from
the
perspective
of
the
authors,
what
needs
to
be
done
is
and
that's
what
I'm
currently
working
on
is
change
the
xml
v2
to
v3,
which
might
result
in
some
formatting
changes,
but
no
content
change.
There
are
still
some
editorial
comments.
I
have
to
integrate
from
gory,
which
are
a
no-brainer
and
the
removal
of
appendix
a
which
is
ecn.
K
K
Related
to
http
and
to
update
the
acknowledgement
section,
which
is
also
uncritical
because
we
have
to
adopt
it
to
to
the
inclusion
of
the
errata
document
that
will
be
finished
this
week
and
then
the
document
is
ready.
K
Gory
asked
last
time
to
reach
out
to
people
for
reviews
and
I
managed
to
get
a
linux
maintainer.
So
one
of
the
maintainers
of
the
linux
stp
stacks
as
a
reviewer,
marcelo
and
kachong
from
oracle
oracle
also
has
an
sctp
implementation
in
the
kernel
the
freebsd
kernel
implementation
is
covered
by
the
authors.
K
We
have
two
reviewers
from
proprietary
stacks,
which
is
barry
zuckerman
from
addicts
and
claudio
porfiri
from
ericsson
and
teemu
folker.
Who
will
read
the
document
at
a
whole
without
knowing
the
the
past?
K
K
A
K
A
Okay,
do
you
want
those
reviews
before
working
with
last
call,
or
do
you
want
those
reviews
done
as
part
of
her
group
last
call.
A
I
would
suggest
just
go
ahead
and
when
the
document
is
ready,
get
the
reviews
posted
and
post
to
reviews
the
list
don't
befall
the
last
week
before
I
I
think
before
we
last
call
is
gory
on.
B
K
A
Yes,
please,
and
then
we
can
take
a
look
at
that
and
decide
whether
we're
less
call,
but
it
sounds
like
we
are
close
to
anticipated
schedule,
which
means
we'll
work
with
less
quality
either
next
month
or
in
january.
A
A
A
Okay,
tom,
you
want
to
go
and
speak
to
these
I'll
click,
I'll
click,
the
slides
forward,
as
we
need.
A
A
C
J
A
A
C
Gorey
says
I
wanted
to
present
dplp
mtu
d
for.
C
A
A
C
But
gory
says
to
the
chairs
my
computer
rebooted
and
I
lost
off
to
join.
There
are
technical
issues
I
can
hear
and
use
regular
jabber.
N
A
Queue:
okay,
karini:
we
we
were
able
to
find
a
slide.
I
A
I
A
I
It
only
needs
to
identify
the
fragment
number,
so
we
need
more
of
a
more
of
an
identification,
so
we're
using
the
same
functionality,
adding
a
little
bit
to
it
and
trying
to
say,
let's
reuse,
that
for
fragmenting
other
things
besides
ip
that's
and
in
general,
we
think
we
can
use
it
for
other
things
as
well
as
perhaps
esp
payloads,
but
but
we're
starting
with
fragmentation.
I
A
Okay,
so
please
send
a
note
to
the
list
with
the
draft
name
and
when
you're
more
awake,
please
send
the
chairs
a
cop.
This
slide
that
doesn't
have
the
juniper
business
use
only
footer
on
it,
so
we
can
post
that
okay,
I
I.
C
David
gory
made
a
comment
in
the
jabber
room.
He
says
the
fragmentation
work
may
be
relevant
to
several
working
groups.
It
could
touch
transport
such
as
gre
and
it
might
be
work
in
another
group
anyway.
Please
read
and
make.
F
A
A
J
J
A
A
Right,
yeah
I'll,
be
afraid
of
that
I
suspect.
Given
the
meat
echo
problems,
I
see
an
ed
on
my
my
institution
was
going
to
be
that,
maybe
maybe
we
simply
declare
that
we've
been
overcome
by
events
and
we
need
to
schedule
an
interim
in
fair
in
the
very
near
future
to
go
pick
up.
What
we're
going
to
do
here.
N
Well,
so
so
the
other
alternative
that
there
is
is
to
extend
our
second
session
into
the
break
time
a
little
bit
so
that
we
can
get
through
more
of
the
agenda.
If,
if
the
consensus
that
we
want
to
do
that,
I
can
request
that.
I'm
sure
we
can
get
the
time
from
beat
echo
since
they've
made
this
not
viable.
N
So
would
would
do
we
want
to
extend
the
the
second
session
into
the
time
leaning
up
to
the
plenary.
N
E
Can
I
suggest,
rather
than
abandoning
the
meeting
just
everyone
holding
into
it,
carrying
on
with
I
don't
know
whatever
they're
doing
and
in
case
the
miteko
comes
back,
because
it
would
be
silly
to
abandon
the
meeting
before
the
end
if
mateco
gets.
N
Fixed,
I
do
know
they're
working
on
the
problem
right
now.
Of
course,
some
some
of
us
are
in
a
position
where
we
would
go
to
bed
if
this
investment
work
on
other
things,
but
I
let
me
see
if
I
can
get
some
idea
what
the
timing
is.
N
All
right,
so,
while
I'm
waiting
for
a
reply
on
that,
do
we
want
to
have
a
longer
meeting
wednesday,
or
do
you
just
want
to
say
heck
with
it
and
have
an
interim.
A
We
could
use
the
time
we
do
have
here
to
see
if
bob
and
the
two
chairs
were
on
audio
have
the
same
view
of
what's
supposed
to
happen
to
the
l4s
drafts
not
having
had
coffee
this
morning,
I
think
where
we
are,
is
that
all
three
of
the
drafts
go
go
to
last
call
it's
not
necessary
to
last
call
the
lfrs
operations
draft
with
the
three
main
drafts,
but
a
successful
working
glass
call
requires
rough
consensus
that
elf,
the
alvarez
experiment
is
safe
to
run
and
to
the
extent
that
the
l4s
operations
draft
is
the
carrier
of
that
safety
case.
A
A
Okay-
and
we
don't
have
that-
we
don't
have
a
a
communication
problem
to
resolve.
Aside
from
the
fact
that
this
hour
of
meeting
requires
copy
for
the
north
american
participants,
which
I
can't
go
out
in
the
hall
and
get.
E
I
and
presumably,
as
spencer,
said
we
can
meet
the
milestone
early,
but
I
don't
know
whether
the
chairs
want
to
schedule
an
earlier
time
in
case
we
do
or
for
their
own
schedule,
but
I
would
really
hope
this
is
not
going
to
take
another
year.
Well,
I
wouldn't
only
hope
it.
You
know
it's
just
just
impossible.
If
it's
going
to
take
another
year,
it's
it.
E
It
was
four
years
when
we
did
the
working
group
last
call
in
in
or
when
we
were
about
to
in
march,
but
two
weeks
before
that
sce
came
up
and
it
it's
just.
You
know
people
are
no
longer
on
projects
on
this.
It's
you
know
it's
very
difficult
to
pull
it
all
together.
A
Off
the
top
of
my
head,
let's
give
ourselves
one
more
one,
one
more
one
more
meeting
cycle
and
the
milestone,
which
is
the
milestone
for
when
we're
done
working
with
last
call,
would
then
be.
I
think,
I
think
april.
E
Right
that
sounds
more
real,
reasonable.
N
A
A
N
Well,
so
this
is
a
little
irregular
right
because
then
yeah
so
in
principle,
we
send
this
to
ietf
last
call
with
no
document,
except
maybe
an
informational
reference
to
an
adopted
draft
that.
N
Like
accepted,
you
know,
approved
documentation
on
these
operational
concerns,
and
so
aren't
we
need
to
get
through
it.
Flashcard
isg,
isg
review
without
a
approved
method
for
or
a
set
of
requirements
for
proper
endpoint
behavior,
which
seems.
A
It's
well,
you
know,
I'm
not
the
operations
for
how
much
operations
draft
is
endpoint
behavior
and
how
much
of
it
is
operator.
I
is
operator
network
defense,
yes,
okay,
pardon
me,
yes,
you're
right
is
the
the
endpoint
behavior.
I
I
think
tcp
prague
is
headed
for
iccrg.
A
And
so
maybe
what
we're
trying
to
do
is
if,
if
a
bunch
of
stuff
has
a
bunch
of
stuff,
has
been
moved
to
get
the
alpha
restaurants
into
what
is
believed
to
be
near
final,
I
guess
focus
in
in
the
next
few
months
needs
to
shift
to
the
operations,
wrap
and
getting
it
adopted
and,
and
let's
see
see
how
fast
we
can,
how
fast
we
can
move
that
along.
M
Sorry
for
interrupting
you
for
a
second,
so
we
just
heard
that
meet
echo
has
just
restarted
server
and
that
will
kick
everybody
out
out
and
then
it
might
take
a
few
minutes
until
everybody
can
rejoin.
So
if
the
session
suddenly
ends,
that's
what's
happening
just
to
let
you
know.
E
N
N
N
This
is
a
very
like
bureaucratic
concern,
but
I
I'm
struggling
a
little
bit
with
this
having
a
standard
where
there
are
kind
of
necessary
safety
requirements
which
are
documented
in
an
informational
draft,
which
obviously
is
a
don
ref,
and
I'm
wondering
if,
if
I'm
wondering,
if
something
needs
to
be
something
like
that,
I
I
hate
to
say
this
operational
draft
has
to
be
standard
track,
or
some
of
it
needs
to
move
into
the
standards
track
documents
because
we.
N
Oh
part,
b,
experimental,
okay,
very
good
pizza
in
the
queue
I'm
gonna
give
the
floor.
A
C
In
except
we
lost
our
illustrious
chairs
there
for
a
bit.
L
David
so
you're,
you
cut
that
for
me
at
least
when
you
start
saying
it's
a
hair
to
be
split
here:
okay,.
G
So
corey,
can
you
hear
me
now?
Yes,
we
can
whoa
hello,
everybody
yeah.
I
I
think
the
the
seeming
disconnect
between
chairs
is
in
that
hair
splitting
area.
We
all
talked
about
this
as
chairs,
and
we
we
agreed
that
we
there
has
to
be
ways
to
stop
things
going
wrong
and
the
question
is
really:
what
level
is
that
guidance
that
is
it
actual
tooling?
Is
it?
Is
it
just
the
method
to
turn
it
off
somewhere
along
that
spectrum
of
different
possibilities?
A
Yeah-
and
I
think
it's
mostly
the
making
sure
really
bad
things
don't
happen
by
analogy,
I
think
of
this
as
being
guard
rails
along
the
side
of
the
road,
as
opposed
to
advice
to
the
driver
to
how
to
keep
the
car
centered
in
the
lane.
N
N
I
have
a
little
difficulty
with
the
the
the
working
group
requiring
a
certain
document
to
safely
judge
the
l4s
package
and
then
sending
it
to
itf
and
the
isg.
Without
that
complete
package
and
saying
here
this
is
good.
It
seems
a
little
problematic.
N
I
mean,
especially
if
there
were
some
issue
with,
for
some
reason,
with
the
ops
document
that
that
held
it
up
further,
but
this,
but
I
think
now
that
now
that
we
have
the
ability
to
have
a
normal
meaning
again,
why
don't
we
go
back
to
the
agenda
and
I
think
I
think
that
the
most
need
is
to
have
a
conversation
about
this
and
yeah
and
figure
out
where
we're.
A
At
it
sounded
independent
of
the
process
details,
the
focus
for
the
next
meeting
cycle
needs
to
be
on
that
operations.
Draft
as
providing
the
guard
rails
to
run,
to
run
the
experiment
and,
at
the
very
least
the
the
the
next
goal
to
shoot
for
is
is
working
adoption
of
it
all
right.
So
where
were
we
when
we,
when
we
started
to
be
unable
to
do
things.
A
O
O
A
Check
that
you
can
present
something
about
to
do
that,
my
turn
to
restart
something
it
lost
track
of
acrobat
for
some
reason:
cool.
So,
while
you're
getting
ready
pump,
the
chair
slides
back
up
again.
G
A
I
think
udp
options
is
next:
okay
and.
A
A
All
right,
I'm
gonna,
okay,
corey!
Why
don't
why
don't
you
can
you
share
materials?
I'm
gonna
have
to
drop
out
and
restart
as
well
something's
going
wrong
in
the
browser.
P
G
Up
so
david
and
group,
I
I
think
we
covered
4.1
is
that
correct.
A
Yes,
you're
up
on
the
udp
options:
fine,
which
would
luck.
G
I've
just
shared
yes,
I
see
that
okay
before
I
talk
to
this
I'd,
like
a
quick
update
for
joe
touch's
work
on
the
udp
options,
draft
itself,
so
joe
is
still
working
on
this
draft.
He
has
a
new
revision
which
he
intends
to
upload
after
this
meeting,
which
will
address
the
issues
that
were
raised
last
iatf,
so
the
work
is
progressing,
but
we're
still
in
need
of
a
new
revision
in
the
archive
to
see
the
results
of
joe's
work.
G
G
This
particular
slide
deck
is
about
the
datagram
plp
mtud
support
for
udp
options,
I'm
going
to
give
a
little
bit
of
history
here,
because
at
the
end
of
this
side,
deck
we're
going
to
ask
for
a
working
group
adoption.
G
So
this
particular
draft
is
draft
revision
3.
The
original
work
was
done
within
the
dplp
mtud
draft
itself,
which
is
now
published.
So
what
does
the
options
draft
now
contain?
It
contains
the
mechanisms
for
making
udp
options,
support
dplp
mtud
and,
as
such,
it
provides
connect
confirmation
of
connectivity
across
a
path,
something
essential
for
dplp
mtud.
G
It
describes
the
sending
of
udp
options
for
the
probe
packets
that
are
used
how
to
validate
the
path,
ptb
handling,
and
mainly
the
issue
that
ptb
messages
don't
necessarily
make
use
of
space
and
the
last.
But
one
line
is
the
most
important
it's
intended
as
a
template
for
other
drafts
that
need
to
describe
how
to
make
dplp
mtud
work.
G
I
kind
of
expect
that
other
protocols
will
follow
this
specification,
we've
produced
in
tsvwg
and
we'll
need
to
write
short
drafts
to
say
how
their
particular
protocol
works
with
the
discovery
of
the
pmtu,
and
one
thing
that's
important.
As
I
say
this
is
that
the
actual
draft
is
only
seven
pages
plus
appendices,
so
it's
a
very
short
draft
that
just
basically
describes
the
extra
machinery
needed.
G
G
What's
new
since
version
two
of
this
draft,
since
revision,
two
we've
updated
to
refer
to
the
published
rfc,
we've
rewrote
the
text
on
sending
method
on
the
probe
construction
path,
validation.
These
are
mainly
just
text
edits
to
bring
this
in
line
and
we've
added
security
considerations.
So
the
draft
is
complete
next
slide.
Please.
G
There
is
work
to
implement
this.
We
it'd
be
rather
foolish
to
define
a
method
and
not
try
it.
So
we
have
seen
two
implementations.
One
is
the
scappy-based,
tooling
and
test
suite
basically
to
see
if
the
mechanism
works.
The
other
one
is
the
freebsd
kernel
implementation,
which
is
available
at
the
url
below
it's
a
individual
contribution.
So
it's
a
set
of
deltas
to
the
actual
kernel
implementation.
G
G
G
We
we
think
the
draft
is
more
or
less
finished.
It's
seven
pages
of
text,
plus
the
pen
dc's
we've
got
some
chord,
which
says
this
chord
can
be
made
to
work
within
an
operating
system.
G
To
us
this
seems
mature,
maybe
to
you
it's
time
to
read
it.
So
our
question
to
the
group
is:
will
tsvwg
adopt
the
current
topic?
I'd
imagine
this
was
for
publication
as
a
ps.
If
udp
options
is
also
a
ps.
I
would
imagine
this
might
be
a
ps.
What
do
people
think
about
this
topic?
What
people
think
about
adoption
I'll
take.
P
P
So
my
question
is:
we
do
dp,
dpl,
pmtud
and
quick,
and
we
use
quick
header
itself
to
do
that.
Right
and
quick
is
built
on
top
of
udp.
P
So
is
this
like
mainly
for
you
know,
protocols
that
use
plain
code,
plain
udp,
because
I
mean
for.
J
P
It
even
necessary
to
know
the
pattern
to
you,
because
ip
can
do
fragmentation
so
for
non
reliable
protocol
that
runs
over
utp.
P
G
G
G
There
are
various
reasons
why
you
might
not
want
to,
but
particularly
for
dplp
mtud.
This
is
this
would
be
duplication
of
discovery
probing.
It
might
well
work.
That'd,
be
an
interesting
research
project,
see
if
the
two
actually
worked,
but
there's
no
point
in
this,
and
the
extra
traffic
is
certainly
isn't
wanted.
G
G
Maybe
it's
a
udp
tunnel
encapsulation,
and
maybe
it's
just
another
protocol,
that's
sending
messages
of
a
particular
size,
and
you
want
to
know
what
size
is
the
largest
size
you
can
use.
G
Ip
fragmentation
is
a
different
game
and
there
are
problems
with
ip
fragmentation
and
c
8900
for
why
ip
fragmentation
is
not
necessarily
the
right
solution.
So
this
is
really
adding
that
dplp
mtud
function,
that's
already
in
quick
to
the
udp
options
framework
to
allow
other
applications
built
on
top
of
udp
options.
To
also
have
the
same
features.
G
Did
that
help
yeah,
explain
video.
You
need
to
your
microphone.
P
I'm
sorry,
but
it
was
just
yeah.
Thank
you
for
the
explanation.
I
was
that
that
does
make
sense
to
use
udp
for
for
for
those
kind
of
scenarios.
P
I
had
a
follow-up
question,
but
so
this
udp
option
can
it
be
used
for
other
things.
I
didn't
see
what
specific
options
are
there,
but
can
it
be
used
like?
Is
it
generic
option
or
is
it
specifically
for
dpl
pmtod.
G
Equivalent
functions
to
tcp
options,
so
it's
meant
to
be
a
generic
set
of
functions
which
you
can
build
upon
when
you
build
a
udp
based
transport
and
most
transports
are
not
as
sophisticated
as
quick,
so
they
don't
have
as
much
machinery,
and
this
is
a
way
to
provide
some
common
machinery
to
those
other
transports.
G
So
you
can
negotiate
other
things.
Yeah
udp
options
itself
allows
much
more
than
dplp
mtud
yeah.
A
There
there
is
a
draft
on
udp
options
in
general.
Let
me
go
find
the
name
of
that
there.
If
you
look
like
on
twg's
main
page,
there's
a
draft
on
edp
options
in
general.
It
may
have
expired
at
this
point,
which
is
why
why
it's
hard
to.
A
P
A
All
right,
my
apologies
for
for
for
stumbling
around
again:
okay,
let's
try
the
short
hands
tool
and
meet
in
in
mate
echo.
Let
me
see
if
I
can
make
this
work.
A
A
Do
okay,
we're
trying
trying
to
show
a
hands
tool,
raise
your
hand
if
you've
read
the?
If
you,
if
you've
read
this.
A
A
Okay,
I
think
about
four
people
have
read
the
draft,
I'm
going
to
say
an
adoption
call
seems
appropriate
as
an
except,
but
we'll
need
will.
I
think
we
should
run
that
run,
run
run
that
run
that
on
the
list.
G
A
Greg
we
go
greg
if
you're
on.
Please
turn
your
mic
and
say
something
we
can
go
to
the
nqb
draft.
O
A
O
Move
on
to
the
next
slide,
this
is
discussing
draft
on
the
nqb
per
hot
behavior
non-cube
building,
perhaps
behavior
just
a
quick
update
on
the
status,
so
this
was
an
adopted
draft
as
of
shortly
after
ietf105,
so
it's
been
adopted
now
for
over
a
year
a
couple
of
drafts.
I
talked
about
in
previous
ietf's
graph,
zero
graph
one
since
the
last
ietf
there
have
been
two
updates:
scrapto,
2
and
draft03,
with
the
additions
and
and
changes
listed
here.
O
Most
of
these
items
were
things
that
were
identified
as
tool
necessary
to
align
the
draft
with
the
requirements
for
php
definitions.
That's
provided
in
rfc
2475,
so
I
think
those
are
all
complete
now
and
we
can
move
on
well
and
then
just
a
reminder.
The
milestone
here
is
to
submit
this
as
proposed
standard
rfc
by
february
of
next
year.
So
now
we
can
move
on
remaining
work
items
for
this
draft,
so
these
I
summarized
also
in
an
email
to
the
mailing
list.
Yesterday.
O
My
time
I
don't
know
where
it
landed
in
all
of
your
inboxes,
but
there
was
some
discussion
on
list
about
interconnection
and
the
code
point
that
the
draft
recommends.
O
Currently
is
42
and
and
sort
of
some
discussion
about
how
that
works
across
interconnections,
with
the
goal
of
this
traffic
marking
being
carried
and
across
the
internet,
but
there
might
be
some
some
issues
with
interconnection
and
the
value
42
and
so
rudiger
guide
and
dave,
and
I
had
some
off
list
discussion
and
came
up
with
these
seven
items
most
of
them.
I
think
that
between
the
three
of
us
we
had
agreed
seem
like
good
next
steps.
O
I
think
there
are
a
couple
of
items
that
maybe
need
some
further
discussion,
so
let
me
run
through
these
quickly
and
all
these
have
a
little
bit
more
detail
in
the
email
I
sent
to
the
mailing
lists,
but
just
go
through
one
by
one
here.
O
So
the
first
one
is
pretty
simple:
there's
some
terminology
in
the
draft
currently
that
talks
about
standardized
dscps,
and
it
was
pointed
out
that
that
really
is
not
the
the
way
that
rfc
2474
lays
things
out,
and
nor
is
it
the
way
things
have
been
done
with
dseps
so
far
in
the
ietf,
in
that
what
are
standardized
are
the
phps
and
the
dscps
are
are
recommended
by
itf.
O
So
well,
pretty
simple
terminology
update
there.
I
think
second,
one
is
eliminate
the
implication
that
this
server
was
not
intended
to
be
used
end-to-end
for
some
of
the
texts
in
the
draft
that.
O
A
lot
of
the
different
code
points
that
are
recommended
in
other
graphs
are
not
carried
end-to-end
for
various
reasons
and
that
goal
of
nqb
was
that
it
eliminates
some
of
the
hurdles
or
roadblocks
that
have
prevented
that,
and
so
it
potentially
could
be
carried
end-to-end.
O
But
in
that
language
it
maybe
overstates
things
a
bit
and
there's
some
clarification
needed
there.
O
The
next
one
number
three
clarify
aggregation
of
nqb
traffic
with
default
and
discuss
backbone
networks,
and
this,
I
think,
has
been
discussed
quite
a
bit
on
the
more
at
least
some
on
the
mailing
list
and
is
not
covered
in
as
much
detail
as
is
needed
in
the
draft.
O
The
idea
is
that
the
nqb
phb
can
be
supported
in
networks,
and
it
provides
a
parallel
cue,
that's
at
the
same
priority
level
as
default,
but
just
segregates
nqb
traffic
from
cue
building
traffic
or
default
traffic,
but
in
networks
that
don't
support
the
php
that
the
nqb
traffic
should
be
aggregated
with
with
default
traffic,
and
that's
not
really
very
clearly
stated
in
the
draft.
O
So
I'd
used
to
add
that
as
it
should,
and
also
in
that
case,
where
the
aggregations
happening
have
the
should
that,
additionally,
that
the
nqb
marking
is
preserved
as
well
and
then
describe
in
a
bit
more
detail
where
full
nqb
support
is
needed
versus
where
aggregation
with
default
traffic
is
likely.
Fine.
Here
we're
talking
about.
We
have
a
set
of
use
cases
that
that
the
draft
outlines
where
support
for
nqb
php
would
be
pretty
useful,
and
the
belief
is
that
in
backbone
networks
the
aggregation
with
default
is
likely
fine
there.
O
So
that's
one
chunk
of
text
that
needs
to
be
added
to
the
draft
item.
Four
discuss
interworking
with
practices
in
place
and
some
interconnects
and
backbones
regarding
dsep
aggregation,
and
so
this
is
the
one
that
kind
of
kicked
off
reuters
comments
that
in
some
interconnects
and
and
some
networks,
particularly
those
that
are
running
in
pls.
O
O
Aggregations
and
although
I
don't
think
is
documented
in
the
rfc,
those
aggregations
typically,
it
sounds
like
use
essentially
iprecedence
bits
in
order
to
group
dhcps
into
those
aggregations,
and
so
if
this
traffic
is
intended
to
be
aggregated
with
default,
the
use
of
a
zero
zero
zero
xxx
code
point
when
sending
traffic
into
those
networks
or
across
those
interconnects
would
make
it
much
easier
for
those
networks
to
properly
aggregate
this
traffic
with
with
default
and
also
make
it
easier
for
them
to
preserve
the
nqb
marking.
O
O
Sensitive
network
control
falls
into
that
category,
but
I'm
just
pointed
out
that
that
could
be
a
problem
if
network
network
control
is
aggregated
with
any
traffic
the
stability,
the
network
could
be
difficult
to
maintain
in
cases
where
that
traffic
is
delayed,
and
I
don't
have
a
strong
feeling
on
this
one.
It
was
intended
as
an
example,
but
unless
some
treatment
of
that
is
needed
in
the
draft,
so
maybe
some
discussion
on
that
on
the
list
would
help
guide
the
direction
there.
O
Then
item
six
clean
up
the
wi-fi
section
to
recommend
php
compliance
more
strongly.
This
section
started
out
with
a
discussion.
O
Initial
drafts
started
out
with
a
discussion
about
existing
wi-fi
gear
and
the
default
mapping
that
that
gear
uses
to
map
all
of
the
different
code
points
into
wi-fi
access
categories
and
the
selection
of
a
recommended
code
point
for
nqb
that
allows
that
traffic
and
qb
traffic
to
be
aggregated
into
a
or
carried
on
in
a
access
category
that
is
separate
from
default.
So
that.
O
So
that
it
can
not
be
queued
alongside
with
q,
billing
traffic,
and
it
also
draft
also
mentions
rfc
8325,
which
defines
a
a
different
mapping
of
code
points
into
access
categories,
but
all
that
was
was
written
under
the
belief
that
interoperation
with
these
two
mappings
was
the
only
thing
that
needed
to
be
discussed.
O
I
recently
added
a
statement
that
indicates
well
actually,
a
wi-fi
device
certainly
could
implement
support
for
the
php
directly
and
completely
support
requirements,
and
I
think
that
that
section
on
wi-fi
really
could
be
cleaned
up
to
more
emphasize
that
that
compliance
aspect
and
and
then
talk
about
these
inner
operation
situations,
as
maybe
a
secondary
aspect,
so
I'm
working
there
and
then
the
last
point.
This
was
brought
up
by
rudiger,
since
in
some
networks,
mqb
and
default
should
be
aggregated.
O
A
Okay,
a
few
comments
on
this
greg
working
bottom
up,
turning
nqb
into
a
php
group
with
default
should
be
a
last
resort,
not
a
particularly
not
a
good,
not
a
good
thing
to
do
unless
we
have
no,
unless
we
have
other
choices
right
now,
my
initial
takes
is
not
necessary.
I'll.
Take
a
look.
I
will
take
a
look
at
the
email
and
comment
comment
on
the
list.
The
wi-fi
section,
as
we
discussed,
saying
off,
list
we're
gonna
discuss
on
list.
A
This
interacts
strongly
with
the
selection
of
the
default
dscp
use
of
42
is
motivated
by
wi-fi
we're
going
to
need
an
on-list
discussion
of.
Why
that's
being
done?
There's
some
comments
in
the
chat
room
about
the
the
wi-fi
access
class
that
it
maps
to
income
and
consequences
of
that
and
then
on
and
then
numbers
three
and
four.
A
It's
going
to
take
some
careful
crafting
of
text
because,
in
essence,
where
we're
trying
to
go
is
that
in
access
networks
such
as
wi-fi
there's
a
dscp,
that
appears
make
a
lot
of
sense,
but
once
you
get
away
from
the
access
networks,
it
looks
like
a
different
dscp
makes
a
lot
of
sense.
O
Okay,
thanks
for
that
clarification,
yeah,
I
think,
what's
a
bit
unclear
to
me
on
the
the
core
networking
of
backbone
networks
aspect
is:
is
that
fairly
universal
that
the
use
of
a
zero
zero
zero
xxx
code
point
would
be
preferred,
or
is
that
in
some
networks
and
not
others,
and
so.
A
Let's
see,
operator
survey
survey
is
tough.
We
can
try
to
do
what
we
can.
I
mean
the
the
general
problem
that
that
mps
background
operators
are
up
against
is
that
there
is.
A
There
is
very
limited
room
in
the
mpls
label
for
for
what
amount
to
d,
dscp
values,
and
that's
that
plus
of
the
the
widespread
practice
of
bleaching
dhcp
zero
at
network
network
interconnects.
A
Interacts
with
three
and
four
and
may
make
some
of
the
desire
to
reserve
the
nqb
marking
some
wishful
thinking.
A
O
Yeah,
so
this
was
to
get
into
that
a
little
bit,
maybe
at
least
provide
what
the
rationale
was
for
for
recommending
42
and
but,
as
you
said,
some
of
this
discussion
probably
needs
to
take
place
on
the
list.
So.
O
One
of
the
big
rationales
for
recommending
dhcp
42
is
that,
for
the
you
know,
the
end
host,
which
is
marking
its
traffic
as
nqb,
yet
having
the
best
a
priori
knowledge
as
to
what
its
sending
behavior
is
and
so
having
the
best
knowledge
as
to
whether
it's
appropriate
to
mark
that
traffic
in
qb
or
not.
O
In
many
cases
that
end
host
is
launching
traffic
into
a
network
where
there
is
no
opportunity
for
a
network
element
to
remap
that
dhcp
into
another
value
prior
to
an
important
link
where,
where
nqb
treatment
or
pseudo
nqb
treatment
is,
is
possible.
And
that's
a
wi-fi
link.
And
we
noted
that
there
is.
There
are
applications
today
that
are
compatible
with
nqb.
O
And
even
beyond
that,
the
applications
that
do
that
today
future
applications
that
can
that
would
that
would
like
to
make
use
of
nqb
in
you
know
across
the
network,
would
also
presumably
want
to
have
their
traffic
huge
separately
from
best
effort
traffic
on
wi-fi
links,
and
so
would
similarly
want
to
choose
a
district
code
point
that,
in
these
defaults
default
wi-fi
networks
maps
to
a
separate
access
category
from
from
best
ever
so
the
video
access
category
is
the
is
the
one
that
would
be
useful
for
that.
O
So
the
belief
here
is
that
if
we
were
to
choose
a
different
recommended
code,
point
one
that
does
not
map
into
the
video
access
category
in
this
default
mapping
that
that
would
go
unused.
That
applications
would
instead
fall
back
to
a
a
non-recommended
code
point
for
this
and
whether
whether
that's
cs5
or
ef
or
cs7,
in
some
cases,
that
that
would
continue
to
be
used
as
a
as
opposed
to
the
recommended
code.
Point.
O
O
Access
network
technologies
that
might
want
to
aggregate
those
four
code
points
together
can
do
that
with
a
mask
on
the
diffser
code.
Point
looking
for
the
pattern:
one:
zero
one:
don't
care!
Don't
care
zero!
O
So
that's!
You
know
the
rationale
that
we
have
for
42
and
then,
as
discussed
a
few
minutes
ago,
there
is
some
rationale
for
interconnections
and
backbone
routers,
where
this
value
zero,
zero,
zero
xxx
would
be
a
more
easily
used.
Okay,.
A
O
Q
You
hear
us-
and
this
is
all
garbage
I'll
try.
Nevertheless,
so
I
like
the
draft
a
lot,
but
I
have
concerns
about
the
default
wi-fi
mapping,
because
any
network
out
there
is
going
to
up
prioritize
nqb
packets
without
having
all
of
the
measures
in
place
that
the
draft
states
that
make
nqb
safe
to
deploy.
Q
O
Point,
okay,
so
I
think
that
the
the
main
issue
with
taking
that
that
path
is
the
one
that's
listed
on
on
the
slide
here.
That.
O
A
H
A
A
A
Marcus
go
ahead,
turn
on
your
audio
and
we'll
flip
slides
for
you,
hello,.
R
Very
good
so
hi
everyone
or
from
a
german
facility
good
morning,
everyone,
so
it's
11,
40
german
time
fairly,
reasonable
time
to
present
you
something
around
multiples
dccp.
R
As
you
probably
all
know,
we
have
three
drafts
published
in
the
tsvwg.
However,
this
time
it's
less
on
an
update
regarding
the
craft
itself,
it's
more
on
our
practical
experience
with
our
multi-path
dcp
ue
implementation.
Next
slide.
Please.
R
Yes,
so
first
start
with
the
figure
on
the
right
side
on
what
the
prototype
implementation
is
about,
so
maybe
starting
on
the
top
of
the
figure
above
the
dashed
line,
so
we
implemented
multiples.
This
is
the
multiple
thesis
between
android
phone
here
it
is
called
ue
user
equipment
and
on
the
right
side,
an
aggregation
point.
So
we
leverage
your
multi-part
gccp
for
providing
multi-path
capabilities
for
at
least
udp
traffic,
complementing
them
existing
multi-pass
tcp,
but
it's
not
restricted
to
udp
traffic.
It
can
even
transport
ip
traffic
or
even
layer
2..
R
So
the
aggregation
point,
then,
is
the
interface
to
the
internet,
so
we
provide
them
multiple
over
cellular
access
and
wireless
and
or
fixed
access.
If
you
look
below
the
dashed
line
into
the
engine
room
so
what's
implemented
in
the
specific
devices
I
I
mentioned
the
user
equipment
and
the
aggregation
point,
you
can
see
that
we
encapsulate
any
traffic
coming
from
applications
through
a
virtual
network
interface
into
the
dccp
flows
or
dccp
tunnels.
R
We
apply
a
scheduling
scheme,
it's
a
model
modular
one.
On
the
receiver
side,
we
have
a
modular
reordering
scheme
to
bring
packets
in
order
again
and
then
forward
it
to
the
internet.
We
also
employ
a
path
manager,
all
the
stuff.
I
will
explain
later
on
in
my
presentation:
let's
go
through
the
points
on
on
the
left
side.
R
R
On
the
other
hand,
dccp
is
unreliable,
so
that
is
the
difference
to
tcp
here
and
this
encapsulation
of
traffic
into
multi-pass
dccp.
That
is
part
of
a
draft.
We
call
multipath
framework.
So
please
look
into
that.
If
you,
if
you
need
more
information,
but
it's
it's
fairly
easy,
so
we
just
provide
encapsulation
into
the
multipost
gccp
protocol
and,
last
but
not
least,
referring
to
our
last
trough.
R
We
have
available
that
the
dccp
udp
header
conversion-
that
is
an
overhead
free
conversion,
just
for
the
sake
of
metal
boxes,
which
does
not
allow
dccp,
forwarding
or
part
through
for
that.
We
convert
any
dccp
traffic
into
udp
on
when
we
transport
this
traffic,
so
middle
boxes
which
allow
udp
traffic
will
also
allow
our
traffic
in
that
case,
and
then
we
reconvert
on
receiver
side
next
slide.
Please.
R
Okay,
coming
a
little
bit
to
the
deployment
settings.
So,
as
I
already
mentioned,
it's
part
of
the
linux
kernel
code,
we
implemented
the
multi-pass
dccp
and
also
the
encapsulation
for
hamburgers
loadable
kernel
modules.
R
We
deployed
this
setup
over
commercial
network,
so
it's
it's
not
part
of
a
lab
setup
or
a
local
setup.
It's
really
commercial
and
the
aggregation
point
is
located
in
a
cloud
internet
server.
For
that
scenario,
the
ue
specifications
are
google
pixel,
4
and
using
android
version
10..
So
the
multi-pass
d60p
is
running
in
the
linux
kernel
where
the
android
based
on-
and
we
have
also
some
implementation,
then
in
the
android
version,
10
network
manager
to
bring
up
the
multi-pass
tcp
and
all
that
stuff
on
server
side.
R
R
Yeah
so
yeah,
I
jump
into
a
probably
new
topic
for
some
of
you,
so
starting
with
the
title
prepared
for
3gbp
80,
triple
s
udp
or
ip
support,
so
2gb
p80
triple
s.
That
is
something
which
is
defined
as
part
of
the
5g
specification
within
3gpp
and
82.s
is
exactly
what
we
have
seen
in
the
figures
before,
where
multi-path
or
multi-connectivity
is
provided
to
mobile
handsets
by
the
5g
core,
where
the
aggregation
point
is
part
of
the
5g
core.
R
R
So
explaining
you,
what
is
80
triple
s,
that
is
axis
traffic,
and
then
we
have
the
first,
as
that
is
steering
that
allows
for
path
election
whenever
we
communicate
with
the
internet.
So
it's
a
or
decision
either
to
use
cellular
or
wi-fi.
Then
we
have
the
switching.
So
we
have
to
decide
for
one
access
or
for
one
path,
but
there
is
the
opportunity
to
seamlessly
switch
to
the
other
axis
and
we
have
the
splitting
support.
That
is
the
well-known
path
aggregation
also
provided.
R
For
example,
by
multi-pass
tcp,
where
we
can
leverage
the
capacities
of
both
axises
or
paths,
so
all
these
3s
are
enabled
in
our
setup,
in
our
multiparse
tcp
setup,
by
the
combination
of
scheduling,
reordering
and
path
management,
as
you
have
seen
in
the
figures
before
so.
The
path
manager
that
the
one
which
detects
local
network
interfaces
and
initiates
connection
on
on
ue
side
again,
that
is
similar
to
multi-pass
tcp
and
that
one
enables
at
least
the
steering,
but
it
also
reacts
to
changes
in
the
network.
R
So
when
the
interface
status
change
appear,
addresses
whatever
then
path
manager
is
responsible
for
trigger
the
switching
the
scheduling
that
the
entity
which
select
the
subflow
through
which
data
is
to
be
sent
that
execute
the
steering
and
switching
functionality,
but
it
also
allows
for
executing
splitting
while
it
distributes
traffic
among
the
subflows.
R
Last
but
not
least,
we
have
the
reordering
and
that
we
consider
as
a
very
important
if
we
talk
about
multi-path
for
unreliable
traffic
as
it
is
with
udp
or
with
ip
traffic.
If
we
encapsulate
this,
then
we
have
to
to
bring
the
packets
again
into
the
order
they
originated.
R
We
consider
this
very,
very
important,
because
we
cannot
rely
on
the
service
or
transport
capabilities
to
to
deal
with
an
unordered
stream,
which
is
pretty
likely
if
we
apply
multipath
and
we
have
accesses
with
different
latencies
and
so
on.
So
reordering
compensates
overall
packets,
cramping
introduced
by
different
parts.
Latencies
and
that's
again
supports
the
splitting
use
case.
R
To
enable
all
these
3ss
in
the
atroci
that
requires
as
well
the
transmission
of
signaling
information,
so
we
achieved
this
by
implementing
multipath
options
defined
in
our
multi-pass
tccp
draft,
like
mp,
sec
for
sequencing
mprtt
for
transmitting
rtt
information,
but
also
new
ones.
We
have
already
implemented
in
our
prototype,
but
not
updated
already
in
the
multicast
tcp
track.
That
is
something
what
we
would,
but
we
will
do
after
this
iatf.
R
Yeah,
so
the
scheduling
schemes
we
have
implemented
are
in
line
with
a
80
triple
s,
so
in
the
atss
specification
in
the
finalized
release
16,
where
atss
was
defined
first,
but
also
in
the
starting
phase.
Now
for
the
next
release,
17
different
steering
or
scheduling
options
are
defined
or
discussed,
and
we
provide
most
of
this
scheduling
options
as
well
in
our
prototype
that
is
cheapest
pipe.
First,
that's
a
prior
priority
based
mechanism
which
allows
the
operator
or
the
uae
to
assign
a
cost
value
to
each
network
path.
R
That
means
we
send
data
on
the
cheapest
flow
whenever
possible,
and
if
the
congestion
window
then
of
the
cheapest
path,
is
full
or
exceeded
it
sends
on
the
next
available
part.
So
that
is
the
splitting
use
case.
R
R
We
support
handover
use
case,
so
that
is
more
or
less
similar
to
the
cheapest
pipe.
First
principle,
however,
aggregation
disabled
in
that
case,
so
we
send
data
on
the
prioritized
path
as
long
as
the
dccp
panel
is
available
for
this
particular
access
or
path,
and
if
the
dccp
tunnel
is
broken,
it
sends
on
the
next
available
power,
so
that
is
switching
and
it's
seamless.
R
We
also
support
an
academic
or
scheduler,
that
is
the
round-robin
one
which
distribute
the
traffic
equally.
I
think
I
have
not
to
explain
this
further.
We
also
support
fixed
ratio
and
redundant.
I
hope
I
hope
they
are
self-explanatory.
Next
slide,
please
reordering
options.
There.
R
We
support
three
in
the
moment
that
is
active
fixed
with
fixed,
refers
here
to
a
static
timeout
until
we
assume
a
packet
to
be
lost
and
then
process
the
next
packets
on
receiver
side,
we
have
it
active
adaptive
which
tries
to
to
figure
out
or
which
make
this
static
time
out
from
the
previous
active
fixed
example,
make
this
adaptive
based
on
the
rtt
or
latency
difference
information
we
have
available
and
also
we
have
delay
equalization
function.
That
is,
strictly
speaking,
spoken.
Not
a
reordering
option.
R
It
just
tries
to
to
delay
packets
on
the
faster
path
by
the
amount
of
of
latency
difference.
Next
slide.
Please.
R
And
that
is
now
one
of
our
results.
We
were
able
to
generate
last
week,
so
that
was
with
the
switch,
that
is
in
the
switching
scenario
where
we
set
up
a
real
skype.
Video
call
and
we
activated
the
handover
scapular,
which
allows
for
the
seamless
handover
from
one
axis
to
the
other.
R
Priority
was
set
on
the
wi-fi
part
and
at
37
seconds
you
see
it
on
the
right
side
in
the
in
the
figure
the
wi-fi
axis
was
broken
and
there
was
a
seamless
handover
from
the
wi-fi
to
the
cellular
to
the
lte
access
in
this
case
and
the
skype
call
remain
active,
and
that
is
exactly
what
we
expected
to
see
so
during
and
after
the
switching,
the
video
call
remains
active.
R
That,
I
think,
is
a
is
a
great
outcome
here.
Next
slide,
please,
as
I
said,
our
prototype
also
allows
the
splitting
use
case
where
we
aggregate
the
capacities
of
accesses.
So
there
we
have
earlier
results
available.
R
R
However,
we
have
to
conclude,
while
first
results
gives
encouraging
results.
It
was
identified
that
the
splitting
performance
has
dependencies
on
congestion,
control,
reordering
scheduling,
rtt
ratio,
though
there's
still
something
to
do,
and
you
will
find
more
information
in
our
presentation
at
this
ietf
109
iccrg
session
next
slide.
Please
I
I
think
that,
for
the
sake
of
time,
I
will
skip
this
just
making
it
short
here.
We
also
implemented
new
congestion
control
schemes
for
dcc
for
dccp.
R
In
that
case,
it
is
bbr
version,
one
which
we
make
available
and
with
that
we
have
a
very
good
experience
in
terms
of
multi-part
performance.
Next
slide,
please
so
coming
to
the
conclusion
native
android
mobile
phone
implementation,
as
I
have
presented
today,
tested
over
commercial
networks,
reveals
functionality
for
path,
election
and
seamless
handover.
The
splitting
aggregation
is
supported
by
design
but
needs
further
investigation.
R
Next
steps.
We
will
update
the
multiparse
ccp
draft.
According
to
our
current
prototype
development,
deutsche
telekom,
internally,
we
have
initiated
the
process
to
publish
the
multi-pass
tccp
implementation
open
source.
G
Ahead,
hello,
I'm
yes,
I'm
wondering
whether
I'm
understanding
this
correctly
is
the
network
path.
You're,
considering
scheduling
packets
at
the
packet
level
without
any
flow
awareness
at
all,
or
is
this
behaving
like
ecmp
would
and
trying
to
stickily
send
the
same
flow
along
the
same
path,
because
these
look
like
different
problem
spaces
and
I'm
curious
as
to
which
you
you're
looking
at,
and
why.
R
So
yeah,
thank
you.
So
what
we
do
is
we
encapsulate
traffic.
R
Into
the
multi-pass
tcp
framework,
so
it
at
this
point:
it
is
independent
if
this
udp
is
at
ip
traffic
as
a
layer,
2
traffic
that
doesn't
matter
what
you
leverage
here
is
the
dccp
flows.
We
have
established
between
ue
and
aggregation
point
and
into
this
flows.
We
encapsulate
the
traffic
we
get.
Obviously
we
receive
from
the
applications
and
are
sent
through
this
virtual
network
interface
and
scheduling
decisions
are
then
based
on
the
dccp
flow
informations.
R
So,
okay,
that
that
depends
so
currently
in
our
prototype.
That's
the
case.
However,
we
could
implement
a
logic
to
employ
different
schedulers
based
on
ip
information,
for
example,
or
even
on
application
service
information,
whatever
yeah.
G
R
However,
I
think
that
is
more
related
than
to
the
framework
craft.
It's
not
to
the
multi-party
draft
as
such,
and
what
our
prototype
would
support
already
today
is
to
set
up
different
mp
dccp
tunnel
connections,
so
that
we
expose
different
virtual
network
interfaces
in
the
ue
and
the
aggregation
point
and
use
this
to
separate
ipflows,
then
with
different
scheduling
and
or
even
reordering
schemes.
R
G
G
I
have
a
few
questions
on
the
adoption
question
to
the
working
group
as
a
whole,
I
mean
one
of
the
things
I'm
interested
in
is
whether
people
have
read
these
drafts,
and
there
are
several
so
we'll
have
to
make
the
right
question
available
for
that.
The
second
one
is
is
doing
this
over
dccp.
A
G
Yeah,
I
think
so
too
david
do
you
think,
there's
time
to
hold
a
quick
feel
around
the
room
for
who
who
has
read
these
drafts?
We
can
try
to
do
that
quickly.
G
Just
take
the
red
question,
as
at
least
while
dave
is
getting
that
prepared,
we'll
take
the
red
question
as
being
a
sign
of
first
interest,
but
if
you've
become
interested
during
this
talk,
then
of
course
you
won't
have
read
them
and
we
just
expect
discussion
on
the
list.
So
if
you've
read
them
at
the
moment,
can
you
indicate
when
david
tells
us,
which
is
no.
G
And
while
we're
talking
about
this
a
couple
of
things
to
remind
people,
one
is
this
is
going
to
be
talked
about
in
iccrg
from
the
congestion
control
perspective,
hopefully
this
week.
So
please
look
there
and
the
second
is.
There
are
multiple
areas
of
ietf
interest
in
atss
in
multipath,
and
we
are
aware
of
these
different
things
going
on
and
we'd
like
to
make
sure
we
coordinate
well
across
these.
So
we're
going
to
talk
to
our
area
director
to
help
do
that
coordination.
A
Okay,
I
see
that
at
least
half
a
dozen
people
have
read
the
draft,
so
there
is
some
of
the
interest.
I
think
we
need
to
go.
A
David,
yes,
we
need
needs
of
the
ad
and
we'll
figure
out
whether
to
run
on
adoption,
column
list.
G
Okay,
so
authors,
please
keep
in
touch
with
the
your
chairs
on
this
one
and
prompt
us,
because
we're
going
to
make
some
discussions
go
forward
and
then
we're
going
to
report
back
to
the
working
group.
What
we
find
by
way
of
a
suggestion
for
progress
and
see
if
people
like
it,
okay,.
A
Okay,
and
with
that,
I
think
we're
done
I'm
going
to
keep
stay
on
the
editor
session
for
a
little
while
to
see.
If
I
can
capture
everything,
make
sure
everything
that's
crucial
gets
captured
in
the
minutes.
I
think,
though
we
are
done.
Thank
you
all
very
much.