►
From YouTube: IETF115-TSVWG-20221107-1530
Description
TSVWG meeting session at IETF115
2022/11/07 1530
https://datatracker.ietf.org/meeting/115/proceedings/
B
B
Okay,
so
we
still
need
a
note
taker
most
immature
got
the
news
cap.
The
point
next
capture
also
need
somebody
to
watch
the
chat
just
in
case
questions
come
up
and
chat
from
people
who
aren't
able
to
join
the
micq.
For
some
reason.
Also
speaking
of
the
Mike
Q
This
is
a
hybrid
meeting.
Therefore,
the
mic
Q
is
what's
up
there
on
the
screen.
B
C
D
D
D
Okay,
this
is
t
t
s
v,
w
g
as
far
as
I
know
the
only
working
group
with
WG
in
the
acronym
and
we're
here
to
look
at
the
transport
area,
topics
I'm
gory,
first
I'm,
one
of
the
working
group
chairs.
This
is
I'm.
F
D
So
welcome
Martin
good
one,
we'll
yep,
let's
go
through
the
note.
Well,
not
well
is
the
standard
ietf
note.
Well,
if
you
haven't
read
it
on
day
one
then
you
should.
This
covers
the
rules
for
IPR
disclosure,
among
other
things.
Next
slide,
we
do
need
help
in
tsbw
dupe.
We
will
be
pursuing
people
to
help
them
help
with
note
taking,
and
we
have
a
note
taken
for
this
session.
Thank
you
very
much.
D
B
B
B
A
quick
reminder:
please
join
the
meeting
of
the
blue
sheets.
Also,
the
mic
line
is
running
entirely
in
meat.
Echo.
You
have
to
join
the
my
line
and
meet
Echo
standing
in
front
of
the
mic.
Does
not
put
you
in
the
mic
line.
We
run
the
mic
line,
automate
Echo,
it's
shown
on
the
smaller
screen
in
the
center
of
the
room,
all
right
as
gory's
noted,
Dr
quality
relies
on
reviews.
If
you
like
documents,
you
care
viewed,
please
in
the
effort
to
review
other
documents.
B
Some
upcoming
documents
that
could
use
some
careful
review
are
multi-path
dccp
and
the
UDP
options
drafts
all
right
time
for
a
review
of
our
greatest
hits
nrc's
published
since
ietf
114.
But
there
are
three
drafts
at
the
art.
All
three
l4s
drafts
are
at
the
RFC
editor.
They
are
being
actively
worked
on.
They
will
appear
in
the
very
near
future.
I
think
we're
closing
in
on
what's
needed
to
get
them
published
no
drafts
at
iesu
after
IHF
last
call.
B
We
have
two
drafts
with
regular
chairs
and
authors
after
work.
Last
call.
This
is
yours.
Truly,
as
as
the
responsible
or
irresponsible
group
chair,
the
issue.
Encapsulation
for
the
lower
layer,
protocols
and
ECM
for
tunnels
that
use
shim
headers
we're
working
through
the
revised
reframing
interaction
text
for
that
first
draft,
using
captivation
for
lower
layer
protocols
with
luck
that
will
con
that
will
close
fairly
soon
and
the
Arts
publication
request
will
be
coming.
B
One
draft
just
completed
a
second
working
group
last
call
is
signing
a
new
recommended
dscp
that
will
be
discussed
in
this
meeting.
We
have
a
draft
in
working
with
last
call.
The
nqb
phb
Greg
is
going
to
discuss
where
we
are
on
that.
One
here
are
the
remaining
six
drafts.
The
first
five
drafts
are
on
the
agenda.
The
sixth
one
use
reports
for
experiments
is
a
fairly
small,
mostly
processed
draft.
The
draft
itself
is
complete.
B
It's
going
to
be
working
group
last
called
fairly
shortly
after
this
meeting
and
we'll
do
them
there.
If
you've
been
paying
very
close
attention,
what
we
do,
you'll
notice,
sctp
Nat,
is
missing
from
a
list.
Above
we
decided.
The
right
thing
to
do
was
remove
it
from
our
plan
of
work,
because
we
could
not
get
convergence
and
agreement
on
what
that.
What
that
draft
ought
to
do.
B
Okay,
bunch
of
related
drafts-
these
are
all
on
the
meeting
agenda.
We
have
three
sctp
drafts,
a
couple
of
updates
and
a
proposal
of
zero
checksum.
We
have
a
general
internet
condition,
control
guidance.
Draft
Martin
Duke
has
found
a
case
that
we
appear
to
have
missed
in
ecn,
interaction
with
tunnels.
So
there's
an
indoor
draft
on
that
and
careful
resumption
of
congestion
control.
Are
you
going
to
talk
about
those
are
going
to
talk
about
that
Glory.
B
Okay
sounds
good,
wait
to
see
here
here:
okay,
some
related
IDs
that
are
not
on
the
agenda,
please
post
list
or
talk
to
the
authors.
If
they're
interested
Jason
livinggood
has
a
Comcast
draft
on
deployment
design,
hpcc
plus
plus
well,
this
is
sort
of
on
the
agenda
sort
of
not
there's
a
there's
one
slide
coming
up.
B
If
we
get
through
the
agenda
quickly,
they'll
be
timed
out
the
end
to
go
into
it
much
more
detail,
but
we'll
have
to
see
we're
trying
to
run
what
would
normally
be
a
three
hour
meeting
in
two
hours,
and
so
things
are
tight
and
John
has
a
draft
on
media
headache
extension
for
wireless
networks,
which
has
been
discussed
some
on
the
list.
D
B
That
will
happen
after
slide
17
you're
on
slide
10,
so
we're
getting
there.
Okay,
Milestone
reviews.
We
have
two
record
Milestones.
It
says
still
about
to
be
achieved
because
I
thought
these
were
almost
done
in
Philadelphia.
I
still
think
they're
almost
done
we're
closer
now
we're
well
into
the
second
we're
well
into
the
last
10
that
takes
the
other.
Ninety
percent
of
the
time
additional
2022
working
group
Milestones
we're
going
to
move
the
UDP
options
drafts
to
March
2023
as
the
new
date
for
them
nqb.
B
Well
we're
not
too
far
off.
It's
in
working
group
last
call
so
we'll
leave
the
milestone
in
September
moving
forward.
We
have
considerations
for
a
shining
new
recommended,
dscp
coming,
which
has
been
working
with
last
called
and
then,
if
we
go
into
next
year,
use
reports
for
experiment
needs
a
new
Milestone
that
looks
like
January
and
then
the
March
details,
sctp
and
July
milestones
for
the
dccp
extensions
and
lfers
operational
guidance
remain
intact.
B
Magnus
you
were
in
and
out
of
the
Mike
queue
I
hope
we
covered
whatever
it
was.
You
were
concerned
about
okay.
B
Agenda
so
we
start
with
these
slides,
including
Milestones
view
which
you've
just
seen,
chairs
update
so
I've,
we've
reviewed
the
Asian
encapsulation
draft
status.
We've
reviewed
the
status
shelf
first
drafts
at
the
RFC
editor
expect
to
actually
be
rfcs
very
soon.
It's
been
a
long
strange
trip,
but
we
got
there
and
the
status
active
working
group
drafts.
We
then
have
a
couple
of
group
drafts
on
on
diff
serving
an
aqm
DHCP
assignment
considerations,
which
it
has
gone
through.
Our
group
last
call.
B
We
have
some
comments,
resolve
the
lfs
operational
guidance,
which
Greg
White's
going
to
talk
about
a
little
bit
that
one's
going
to
stick
around
for
a
while.
B
Moving
on
transport
drafts,
two
sessions
on
multi-path
dccp
there's
been
some
interop
testing
and
I
hear
the
results.
A
bit
have
been
pretty
good
and
then
Marcus
will
talk
about
the
base.
Multi-Path
DCC,
D,
CCP
draft
John
Matson
has
taken
over
SCP
authentication
and
found.
Let's
see
I
think
we
could
politely
call
it
some
opportunities
for
improvement.
Michael
tookson
is
going
to
talk
about
what
to
do
about
those
opportunities.
B
Magnus
has
our
latest
details
of
sctp
draft,
and
then
we
have
the
two
UDP
options:
drafts
I,
think
gory
you're,
going
to
try
to
impersonate
Joe
touch,
good
luck!
Thank
you
and
then
the
deal,
the
DPL
pmtud.
No,
don't
don't
actually
pronounce
that
supporting
UDP
options.
Gory
is
that
yours
at
Tom,
Jones.
B
B
Okay,
individual
drafts,
sctp
UDP,
update
proposed
by
ctps
or
checksum
Nicholas,
is
going
to
talk
about
Carefree,
junk,
careful
resumption
congestion
control.
Gory
is
going
to
talk
about
a
general
draft
on
guidelines
and
recognition
control
and,
as
I
mentioned
earlier,
Martin
Duke
has
found
a
case
that
we
a
case
of
EC
internal
interaction.
That
appears
not
to
be
addressed
as
an
angel
draft
to
address
it
then
down
at
the
end
of
the
meeting
at
the
end
of
item.
Five
is
normally
two
hours
of
gender
time.
B
If
we
get
through
this
more
quickly,
we'll
have
time
down
at
the
end.
To
do
hpcc,
plus
plus
Michael
has
at
least
one
other
sctp
draft
John
has
a
metadata
draft
on
meditative
media,
packets
and
finally,
ingomar
has
a
5G
radio
scheduling.
L4S.
No
draft
he's
also
going
to
talk
about
that
in
iccrg,
so
it's
not
essential
that
we
get
to
it,
but
it's
certainly
usually
have
a
heads
up
here.
B
Okay,
we
need
to
get
through
some
cherish
topics,
administ
trivia
time
liaison
Communications,
so
I'll
start
the
third
liaison
came
a
while
ago.
It's
been
dealt
with
and
nothing
has
been
heard
from
wa
since
we
sent
the
reply
back
in
essence,
what
had
happened
is
a
an
interest
individual
draft
to
come
here,
saying:
hey,
let's
go
to
find
phbs
and
dscps
for
every
5qi
we
can
think
of
to
which
our
response
was.
B
That's
a
lot
of
dhcps,
not
sure
we're
going
to
be
using
that
many
and
oh,
by
the
way,
3gpp
really
does
not
like
what
you're
doing
a
liaison
came
from
WBA
said:
hey,
would
you
please
do
this
once
a
response
went
back?
Was
that
consumed
a
whole
lot
of
dscps?
How
about
something
fewer?
And
would
you
please
get
along
with
3gpp
and
get
back
to
us?
Nothing
has
been
heard
from
wwba
since
I
think
we
can
retire
this.
This
liaison.
D
So
we
have
a
liaison
with
3gpp
relating
to
a
CTP
and
dtls,
and
this
will
come
up
in
the
liaison
discussion
tomorrow,
where
we
do
the
coordination
and
it
may
be
updated.
If
we
need
to.
After
this
meeting,
we
will
see
how
all
this
goes
and.
D
Yeah
gsma
are
aware
of
the
multi-path
dccp
work,
and
this
touches
with
a
3gpp
and
gsma
work
on
on
the
multi-path
dccp
work
really.
D
Is
iepg
presentation
on
dscp
measurement
is
where
Anna
presented
her
data?
If
you
didn't
see
it,
you
missed
it
put
it
still
in
the
archive,
so
you
can
go
and
look
at
it
or
speak
to
Anna.
At
this
meeting
yeah
we
have
an
eye
on
a
registry
for
phb
IDs.
What
do
you
believe
it.
B
Yeah,
well,
it's
really
interesting.
Ayanna
was
going
around
checking
whether
they
had
active
designated
experts,
reach
registry
and
ran
across
this
one.
Yours
truly
want
Disney
experts.
Brian
Carpenter
is
the
other.
We
looked
at
the
registry,
it's
over
a
decade
old,
it's
still
empty.
That's
a
real
strong
suggestion
that
whatever
it
was
trying
to
use
the
registry
isn't
particularly
useful.
B
So
the
path
forward
is
I'm,
going
to
write
a
draft
that
obsoletes
the
stuff
that
uses
the
registry,
which
is
I
under
registered
per
hop
Behavior
dinner,
I
own,
a
relationship,
identification
codes
for
perhap
behaviors
that
aren't
standards
track
and
don't
have,
and
therefore
don't
have
a
default
recommended
dscp.
B
The
only
thing
we're
going
to
do
is
obsolete
those
things
that
we
never
use
because
nobody
ever
registered
one
get
update
our
340
get
rid
of
that
leave
the
existing
format,
which
is
essentially
an
encapsulated
dscp
and
close-handed
registry.
So
no
effect
in
use
of
DSC
fees
are
signaling,
no
effect
on
PHP,
IDs
and
embedded
dscp
nobody's
used.
This
thing
we're
going
to
get
rid
of
it.
Martin.
C
I
propose
nothing.
The
secret
isg
back
handle
says
the
zoo
lip
is
back
up,
so
if
we
can
monitor
the
zulip,
the
chat
is
back
up.
So
if
we
could,
please
monitor
the
chat
Channel.
Thank
you.
B
D
Welcome
Martin
welcome
Martin
Martin.
Would
you
like
to
say
something
on
behalf
of
Martin?
Well,
I
was
going
to
say
this
is
Martin
I
mean
we
said
the
name
Martin
several
times
he's
our
new
working
group
chair,
he's
acclimatizing
to
being
up
here
in
front
of
everybody,
and
it's
really
good
to
have
him
here.
Thank
you.
I
will
be
continuing
as
a
working
group
chair
for
the
foreseeable
future
and
David
black.
B
I
will
be
stepping
down
his
working
group
chair
after
a
long
and
interest
interesting
experience
up
here,
I'm
going
to
continue
to
separate
drafts,
not
quite
true
the
exact
timing
of
this,
but
it
will
happen
some
sometime.
The
next
few
months,
Mr
Duke,
sir
yeah.
C
I
would
just
take
a
moment.
I
would
like
to
take
a
moment
to
recognize
David.
He
has
been
the
tsvw
chair
since,
before
I
started,
coming
to
iitf
meetings,
I've,
never
known
a
tsvwg
that
he
was
not
sharing
and
and,
like
obviously
being
a
very
present
and
active
leader
of
an
expert
on
just
a
wide
swath
of
the
kindness.
C
Oh
first
of
all,
tscw
said
you
know
a
very
robust
group
with
like
a
wide
swath
of
technology
that
it
covers,
and
David
has
done
covered
it
quite
adeptly
and
been
really
an
expert
on
a
whole
lot
of
stuff
and
I
mean
hopefully
you're,
not
gonna.
You're
gonna
be
around
to
to
continue
to
provide
your
expertise
for
the
group.
Just
maybe
from
from
the
floor
where
you
can,
you
know,
take
the
gloves
off,
which
should
be
quite
entertaining
and
aside
from
the
technical
you
know.
Obviously
this
is.
C
This
group
has
had
its
share
of
strife
to
be
quite
Frank
about
it
and
that's
always
a
a
demanding
thing
for
our
chair
to
handle,
and
he
has
been
instrumental
in
doing
that.
So
thank
you
for
everything.
You've
done
for
the
transport
area
and
the
ITF
and,
like
I,
said
I
hope
we
hope
to.
We
hope
to
continue
to
see
you
around.
C
B
Thank
you
very
much.
I
intend
to
stick
around
perhaps
more
virtually
and
physically,
but
I'm
not
going
anytime
soon
and
as
Martin
has
reminds
me.
Occasionally.
I
still
have
some
drafts
and
responsible
for
Shepard
plus
when
I
just
volunteered
to
write.
D
The
next
slides
will
be
the
individual
documents
which
are
just
brought
up
here
for
a
heads
up.
This
is
a
new
experiment.
You
get
two
minutes
to
pitch
up
on
your
draft
if
you
want
to
so
come
up
now,
if
you
wish
to
give
it
a
talk
for
two
minutes
on
your
draft,
if
not,
then
we
will,
we
will
introduce
it
for
you,
so
who's
first
Jason
Jason,
while
Jess
is
coming
to
the
mic.
I'll
clarify
that
Wes
Eddie
will
remain
a
Shepherd
for
the
l4s
Ops
work.
D
G
Right,
no
pressure,
two
minutes,
my
goodness.
Well,
this
one's
pretty
simple
so
in
the
process
of
getting
ready
for
deployment
of
all
Forest
types
of
Technologies,
I've
been
talking
to
a
number
of
folks,
not
just
folks
on
you
know,
sort
of
business
positions,
but
policy
makers.
G
You
know,
researchers,
those
kind
of
folks
that
really
influence
the
technical
environment
in
which
isps
operate
day
to
day
and
the
key
questions
that
they
often
ask
which
this
draft
attempts
to
address
are
what
this
means
in
relation
to
prioritization,
sort
of
Fast,
Lanes
and
slow
Lanes
in
the
American
Regulatory
parlance
and
capacity
or
speed,
because
those
are
very,
very
common
points
of
confusion.
G
And
then,
of
course,
how
does
this
relate
to
the
concept
of
net
neutrality
and
a
fair
treatment
of
all
applications
without
regard
to
the
protocol
being
used
or
or
something
along
those
lines?
And
so
those
are
the
key
two
things
that
it
speaks
to
and
then,
as
a
result,
it
suggests
sort
of
four
key
things.
G
There
might
be
a
few
more
bits
and
Bobs
in
there,
but
really
suggests
this
orientation
towards
applications
marking
the
traffic
rather
than
the
network
and
I
put
that
one
in
particular,
because
as
soon
as
we
started
talking
about
this,
we
had
sort
of
DPI
style
vendors
coming
out
of
the
woodwork
telling
us
that,
because
apps
won't
be
marking
anytime
soon,
we
should
put
this
magic.
You
know
inspection
thing
in
the
network
and
it
will
magically
infer
what
applications
which,
by
the
way,
are
encrypted.
G
You
know
need
what
type
of
you
know
queuing
and
that's
a
nightmare
and
always
results
in
improper
treatment
and
potentially
starvation
or
other
negative
effects,
and
we've
done
that
before
with
TCP
resets
oops.
So
you
know
I
put
that
in
there
application
or
Edge
providers
being
able
to
use
it
really
on
a
sort
of
open
base.
Us
multiple,
you
know,
sort
of
Edge
Equipment
types
should
be
supported.
Okay,.
G
So
that's
that
I'm
happy
to
take
any
changes
and
there's
a
GitHub
repository.
Thank.
E
H
H
You
need
to
build
lossless
networks,
because
this
is
how
we
do
machine
learning
in
general.
You
would
need
to
spend
a
lot
of
time
and
effort
to
build
Network
and
if
you
try
to
build
it
lossless
fashion,
without
better
congestion
control,
the
cost
just
run
out
of
control.
So
practically
what
we
are
doing
here,
we
are
gathering
all
the
data
as
we
travel
the
network,
send
it
back
to
the
sender,
sender,
adjust
the
rate
and
allows
you
to
adjust
the
rate
Within
rtt.
H
So
if
you
would
deploy
something
that
today,
you
would
probably
run
gcqcn
which
works
pretty
well
for
long
flows,
and
you
know
large
environments.
However,
as
you
try
to
put
it
into
machine
learning
clusters,
it
stops
working.
We
spent
a
year
working
on
different
encodics.
You
know,
there's
a
zoo
of
indent
limiting
population,
unfortunately
in
ibpm,
so
we
got
to
support
all
of
this
recordings
and
metadata.
Most
importantly,
we
got
all
four
data
center
silicon
vendors
to
support
it.
H
So
you
see
Sisk,
broadcom,
melanox,
sorry,
Nvidia
and
Intel
supporting
it's
coming
in
Silicon,
that's
going
to
be
shipping
starting
now.
So
please
do
read
the
drafts.
We
expect
a
lot
of
people
to
be
interested
in
this
technology,
it's
much
better
than
what
we
have
today.
Most
importantly,
there
are
implementations
in
deployment.
Alibaba
runs
this
hpcc.
F
H
And
Alibaba
deployed
hpcc
with
TCP
just
three
months
ago,
so
there
is
a
larger
deck
published
and
hopefully
we'll
get
them
next
ITF
to
present
yeah.
B
Thank
you,
John
go
ahead,
yeah,
the
the
the
larger
deck
is,
is
in
the
meeting
materials
and
we
may
get
to
it
if
we
get
get
to
it.
If
we
have
coming
into
session
John
go
ahead.
I
So
this
is
a
draft
that
identifies
some
media
header
extensions
in
terms
of
metadata
that
is
specific
to
wireless
networks,
I
think
for
now,
because
the
media
I
mean
the
the
motivation
is
that
media
applications
demand
low,
latency
and
high
bandwidth
and
handling
this
kind
of
wireless
link
capacity
variation
along
with
network
utilization
and
the
demands
of
media
applications
is
quite
challenging
in
the
wireless
networks.
Along
with
that,
we
have
HTTP,
3
or
quick
based
media.
That's
going
to
be
encrypting
packets,
so
multi-streaming
needs
to
be
considered
in
3gpp.
I
The
xrm
working
group
has
cons.
I
mean
sorry.
Study
has
considered
some
solutions,
but
we
think
that
the
ietf
is
a
good
place
to
look
at
these
options
and
avoid
I
mean
it
have
a
common
solution
to
the
problems
that
exist
for
all
kinds
of
Wireless
I
mean
Wi-Fi
and
3gp
Networks,
and
we've
identified
a
minimum
set
of
things
which
we
think
should
be
secured
and
sent
only
between
trusted
parties.
But
at
this
point
we're
thinking
of
the
priority
or
importance
of
packets.
I
For
example,
an
iframe
should
not,
even
if
it's
past
a
budget
it
should
be
sent
because
otherwise
it
causes
further
damage.
A
scheduler
in
the
radio
network
can
get
use
of
packet
bursts.
So
that's
going
to
be
a
useful
amount
of
information
and
then
delay
budgets
and
last.
The
third
part
is
that
you
know
how
do
we
transport
it
and
there
are
multiple
options
at
this
point
possibly
and
each
have
different
trade-offs.
I
So
there's
media
over
quick
with
just
HTTP
3
UDP
options,
which
is
more
General,
but
we've
got
to
consider
the
API
mask
and
encapsulation,
which
is
more
flexible,
but
then
we're
going
to
consider
the
overhead,
and
so
you
know
that's
that's
where
we
are
at
this
point.
D
For
those
three
drops,
please
look
at
them.
Please
discuss
on
the
list
likely
at
the
next
meeting
every
question.
We
will
ask
people
to
see
if
they've
read
them
or
what
they
think
of
them.
Oh,
it's
me.
D
I
can
actually
be
me
I'm,
one
of
the
co-authors,
of
the
considerations
for
assigning
a
new
recommended
dscp.
This
has
been
through
a
working
group.
Last
call
so
I'll
try
and
be
relatively
quick
on
this.
There
were
changes
in
zero,
three
and
zero.
Four.
We
added
various
clarifications.
D
D
D
We
had
some
issues
in
working
group
last
call
we
had
a
number
of
different
topics
raised
and
we
put
those
in
the
issue
trackers.
The
first
set
here
are
all
things
that
we
think
required
better
text.
It's
amazing
how
many
times
you
can
improve
your
text.
We
found
yet
more
places
where
the
text
could
be
better.
Maybe,
as
other
people
reviewed
this
higher
levels,
I
was
hoping
that
it
passes
out
of
this
working
group,
we'll
find
yet
more
corrections.
D
David,
yes,
well,
we
didn't
include
one
of
the
requests
made
in
the
working
group
must
call
yet
in
our
editor's
version,
and
it
was
to
discuss
an
issue
that
happens
when
you
have
a
remarking
behavior
that
comes
from
a
TOS
precedence,
bleach
and
where
basically,
the
first
three
bits
of
the
dscp
are
reset
and
rudiger
gave
us.
This
example
as
part
of
his
offering
on
comment-
and
we
didn't
include
this
text,
but
we
could
still
do
it
if
people
think
it's
really
important
it
described.
D
D
If
you
were
to
use
some
bleaching
mechanisms,
you
would
simply
zero
some
part
of
it,
as,
in
example,
a
that
anyone
who
knows
anything
about
any
way
in
which
coding
happens,
you'd
realize
these
actually
have
the
same
result.
So
there
are
multiple
ways
to
represent
the
same
thing,
and
this
is
part
of
the
whole
confusion
about
what
it
means
to
bleach.
Something
I
think
the
real
issue
that
we
were
trying
to
convey
in
the
draft
was
the
intent
behind
the
remarking,
not
the
remarking
itself.
D
D
Please
read
the
draft
and
list
text.
If
you
care
David,
let's
slide
number
three
was
somebody
helpfully
asked
us
about
their
owner,
PHP
ID
and
it
was
going
to
be
a
nice
slide,
but
David
already
stole
my
thunder
and
we're
not
going
to
say
anything
about
this.
On
the
last
slide.
D
J
All
right,
thank
you.
Actually,
before
I
get
into
operational
guidance,
I
will
say
one
thing
about
the
nqb
draft,
since
you
mentioned
I
would
talk
about
it.
I
don't
have
a
slot
on
the
agenda
for
it,
so
it
isn't
working
group
last
call
there
already
have
been
a
few
comments
have
come
in
on
the
mailing
list,
but
please
do
review
the
draft
and
contribute
to
that
discussion.
I
believe
it
has
two
more
weeks
until
the
work
group
last
call
ends.
So
again,
please
review
and
provide
comments.
Thank.
J
All
right,
the
l4s
Ops
draft-
you
can
go
on
to
the
next
slide
if
you've
not
been
aware
of
this
document
before
it
talks
about
deployment
of
l4s
on
the
internet
as
it
is
today
which
potentially
could
include
some
RFC
3168
or
classic
ecn
aqm
bottlenecks,
and
if
those
do
exist
on
the
internet
and
classic
traffic
shares
that
bottleneck
with
l4s
traffic.
J
J
We
as
a
working
group,
agreed
to
keep
this
document
open
as
a
living
document,
as
the
experiments
and
deployment
of
l4s
begins
to
capture
any
learnings
that
that
that
come
along
with
that
initial
deployment,
so
I
just
posted
a
new
version
of
the
document
today
and
just
to
keep
it
alive
and
again.
If
anyone
has
any
contributions
for
that
document,
please
bring
them
up
on
the
mailing
list
and
and
we'll
get
them
added.
So.
J
A
J
J
We
had
our
first
ietf
l4s
interop
at
ietf
114
in
Philadelphia
I
was
pretty
well
attended
and
got
a
lot
of
work
done
around
multiple
implementations
of
l4s
congestion,
control
and
network
bottlenecks
and
congestion,
feedback
bugs
were
found
bugs
were
fixed,
different
test
cases
will
run
and
after
Philadelphia,
cable
Labs
hosted
another
interop
event
at
our
facility
near
Denver,
again
nicely
attended
and
and
and
those
include
results
from
that
and
then
currently
downstairs
in
the
other
Tower,
the
main,
the
building.
We
are
running
our
second
ietf
l4s
interop
the
link
on
the
slide.
J
There
is
the
presentation
that
we
did
at
the
conclusion
of
hackathon
yesterday
afternoon,
but
the
testing
still
continues.
Some
of
it
will
will
run
probably
all
week.
We've
got
two
5G
networks
that
are
implementing
l4s
as
well
as
Wi-Fi
gear
and
a
fixed,
Network
emulator,
and
then
a
number
of
different
endpoint
implementations,
congestion
control,
implementations
that
are
running
across
those
networks.
So
that's
going
on
currently
and
after
this
meeting
down
in
the
the
room
where
the
hackathon
was
taking
place.
There
is
a
happy
hour.
Please
stop
by.
J
You
can
see
the
demos
of
the
real-time
streaming
media
applications
that
are
running
over
l4s
bottlenecks.
Some
nice,
nice
graphical
demos,
for
that.
So
please
stop
by
with
that
and
then
upcoming
opportunity
communities.
Cable
apps
is
planning
on
hosting
another
interop
at
our
facility
in
January
end
of
January.
J
G
F
Are
you
I
just
wanted
to
clarify
when
Greg
said
it's
in
where
the
hackathon
was
it's
Admiral
sweet,
which
is
the
low
gram
third
floor
right
at
the
bottom
of
the
East
Tower.
K
K
Here
is
what
we
did.
We
have
ported
the
mptcp
to
Android
13
based
on
Android,
T
version
phones
with
5.10
Kona
world
right
running,
and
we
verified
the
policy
and
the
interoperability
of
mptcp
OC
Land
one
environment
here
here
is
what
we
have
done.
We
read
the
specification,
reported
the
mptcp
internal
module
and
also
the
udccp
commanders,
and
also
we
sold
many
problems
and
finally,
we
approved
performed
as
a
high
Prof
interability
test.
Next.
K
Before
the
test
we
made
some
Gravitation,
we
actually
follow
the
reference
implementation
and
we
prepared
one
mobile
phone
with
dual
WLAN
capability
and
we
modify
the
kernel
with
5.101
version
and
thanks
to
dtz,
provided
the
server
side
implementation.
Why
is
there
for
virtual
machine
and
another?
Is
one
remote
server
located
in
Germany?
K
Then
we
set
up
the
layer
and
the
one
test
environment
of
all
the
IQ
addresses
are
listed
here,
especially
especially
for
the
one
environment.
We
you.
We
are
using
the
udccp
header
convention,
application.
K
To
to
avoid
the
problems
with
middle
boxes
between
China
and
Germany,
internet
transfer,.
K
Or
the
next
one
here
are
the
functions.
K
Verified
in
the
in
our
inability
test,
we
configure
the
all
necessary
options.
K
First,
one
we
we
import
the
mptcp
capability
capability
on
every
physical
interfaces
and
also
we
enable
the
transfer
options.
We
also
configure
the
routine
rules
and
we
set
the
translation
port.
Finally,
we
we
perform
the
right
test.
K
F
K
A
K
This
is
for
the
MP.
Close
function
verified
the
next
one
please.
K
K
This
is
a
address,
remove,
remove
function
and
the
fallback
machine
functions.
K
So
next
one
here
I
will
plan
to
push
the
mptcp
further
right.
Now
we
have
test
the
basic
function
and
the
next
step
we
will
put
the
tomb
prox
to
Android
kernel
under
deploy
the
encapsulation
framework
to
allow
the
multi-pass
transfer
transport
of
any
IP
traffic.
Finally,
we
will
test
the
real-time
service,
such
as
Skype
uip
sources,
so
the
next
one
here
I
will
conclusion
for
the
mptcp
interoperability
test.
K
K
Also
we
we
run
the
test
in
both
slide
and
one
environment,
which
proves
the
complaintenance
and
maturity
of
anti-dccp
draft
206
and
its
usage
and
the
function
operations
are
very
similar
to
the
mptcp
protocol.
L
L
Yeah,
starting
with
the
draft
maturity
State,
how
we
as
authors,
see
it
so
it's
all
already
outlined
in
Philadelphia
the
freeze
feature
state
birds
version,
four,
so
no
further
updates
from
our
site
we're
added
to
the
draft,
and
we
mainly
focused
on
getting
external
reviewers
to
providing
us
feedback
that
accumulated
in
the
current
version.
6
of
the
draft
I
will
get
more
into
detail
on
the
next
slide.
Remaining
minor
work
we
see
at
the
moment
so
there's
some
feedback
from
see
monophel
in
writer,
and
also
some
Ayana
review
here.
L
L
L
We
had
some
editorial
issues
we
solved
and
all
the
other
things
I
really
helped
to
yeah.
All
the
other
issues
are
mentioned
here
helps
to
give
some
clarity
to
the
whole
to
the
whole
draft
and
make
it
better
readable
to
externals,
not
just
to
the
authors.
A
full
change
log
is
available.
Did
you
see
it
on
the
bottom
right?
So
we
maintained
this
with
GitHub,
which
gives
you
a
nice
overview.
L
L
So
last
time
in
Philadelphia
we
mentioned
that
all
the
functionalities
and
multipass
options
we
Define
in
the
draft
in
the
in
the
left
table
were
completed,
and
this
time
we
focused
on
completing
all
the
things
in
the
right
table.
So
we
can
State
implementation
is
completed.
Now
we
fixed
the
last
things
and
improved
them
mainly
about
multi-pass,
confirm
functionality
which
gives
a
reliability
to
some
of
the
multi-pass
options
like
the
editors
remove
address
and
the
prior.
L
We
verify
the
fallback
mechanisms,
also
together
with
xiaomi,
as
you
have
seen
in
the
previous
a
presentation,
and
we
implemented
the
two
different
closing
procedures
based
on
multi-path,
close
and
multi-pass.
Fast
close,
you
also
find
here
right
to
the
table
the
pull
requests
in
which
we
added
those
functionalities
to
the
public
GitHub
repository
of
our
Linux
reference
implementation,
yeah,
and
with
that
we
started
the
interoperability
test,
as
Tommy
has
outlined
next
slide.
Please.
L
Okay
so
ending
with
a
summary
here
yeah
we
did
together
with
some
me
some
or
not.
Some.
We
did
the
interoperability
test,
which
confirmed
that
multi-pass
dccp
as
it
is
specified
so
far
works
and
all
the
different
functionalities.
We
have
specified
worked
with
between
two
different
entities:
a
server
hosted
by
Deutsche
Telecom
in
in
Germany
and
the
UE,
a
smartphone
implementation
running
in
China.
L
based
on
a
5.10
kernel,
and
they
solved
multiple
issues
compared
to
the
Linux
reference
implementation.
They
verified
that
the
code
matched
the
mpdccp
specification
and
yeah.
Last
but
not
least,
as
I
already
said,
so
we
run
the
successful,
successful
interoperability
test.
L
There's
also,
or
what
supported
us
in
that
was
also
a
new
Wireshark
detector,
thanks
to
a
PhD
student
from
City
University
London,
who
made
this
public
available
and
we
improved
this
dissector.
Also
during
the
hackathon
on
Saturday
so
saying
here,
the
wire
Factory
sector
is
available,
which
is
in
line
with
the
mpdcp
trust
version,
6.
L
yeah,
now
coming
to
the
interesting
questions
or
discussions.
Probably
you
have
maybe
have
also
already
seen
on
the
mailing
list,
also
thanks
to
Gary
that
we
approach
to
working
group
last
call
and
there's
also
a
discussion
to
move
the
mpdczp
draft
from
experimental
track
to
proposed
standard.
So.
B
L
So
there
there
are
no
further
remarks
from
my
side.
I
think
it
would
be
no
good
to
get
some
some
feedback
on
this
working
group
last
call
and
propose
standard
track.
Question:
okay,
hang.
D
I
think
the
first
question
I've
got
to
the
group
is
not
this
question,
but
first
of
all
could
I
have
a
show
of
hands
for
people
who
have
read
this
or
a
maybe
the
previous
version,
so
I
want
to
know
how
many
people
have
been
reading
this
work
as
it's
been
developed,
and
are
we
going
to
use
a
tool
to
do
this?
David,
oh
yeah
you're,
showing
the
ticks?
Okay,
there's
there's
a
few
ticks
here.
D
That's
what
you
wanted
to
show.
Isn't
it
right?
Okay,
I'm
going
I'm
going
to
try
using
the
tool
and
then
maybe
as
a
calibration
device,
I'm
going
to
try
using
the
room
and
people's
real
hands
and
see
if
they
cut
if
the
results
calibrate
so
can
I
use
this
tool.
Here
we
go.
D
And,
of
course,
the
next
question
will
be:
do
you
have
input
to
help
us
work
with
our
ad
to
decide
upon
the
appropriate
position
in
the
RFC
series
to
publish
this
so
I'm,
going
to
ask
people
to
come
to
the
mic?
To
comment
on
that?
We've
seen
some
comments
on
the
list
and.
D
B
Think
13
I
think
over
address
people
who've
read
this
read.
This
is
excellent,
so
let's
go
ahead
to
the
next
one.
D
Okay,
so
the
next
question
is:
does
anybody
want
to
provide
any
additional
comments
on
whether
they
think
this
document
should
progress
to
a
working
group
last
call
as
PS,
rather
than
the
current
status,
which
is
experimental?
So
does
anybody
have
any
comments
that
might
help
us
make
this
judgment?
For
instance,
why
wouldn't
it
be
a
PS.
D
Okay,
this
is
actually
not
the
working
group's
call,
but
it's
the
ad
working
with
the
chairs
to
decide,
but
we
need
input
and
Martin's
the
man
who's
going
to
have
to
yeah.
C
Ask
questions
I
definitely
would
like
to
add
the
input,
or
rather
have
some
input
and
I
wanted
to
wait
for
somebody,
but
nobody
stood
up
so
I'll
talk
some
more.
C
So
I
think
Marcus
was
okay,
so
number
one
I'm
always
concerned
about
real
world
deployment
for
this
Beyond,
like
proofs
of
concept
and
so
on.
I
think
there's
an
excellent
point
that
we
also
have
an
MP
quick
thing
going
on,
and
it
makes
sense
for
that
to
align
and
I,
don't
think
my
co-ad,
oh,
my
co-80
is
here:
I
couldn't
see
him
a
second
ago.
He
and
I
need
to
get
together
on
this.
C
My
original
thinking
when
we
started
all
this
multi-path
work
was
that
a
lot
of
the
scheduling
problems
were
very
researchy
problems
and
that
what
we
were
doing
here
was
creating
lots
of
platforms
for
the
research
community
to
be
able
to
run
those
experiments
in
a
way
they
can't
necessarily
do
with
mptcp
very
well
I.
Don't
know
that
if,
in
your
particular
use
case
Marcus,
you
think
you
have
the
the
scheduling
problem
solved
or
not,
but.
L
So
you
talk
about
multiple
scheduling,
yeah
right,
yeah,
okay,
so
multiple
scheduling,
I
think
it's
it's
for
all
of
the
protocols
which
are
currently
discussed
in
IDF,
mptcp,
MPD,
CCP
and
multi-pass,
quick.
That
is
very
implementation
specific
and
we
just
provide
the
protocol
with
that.
From
our
experience
we
more
or
less
adopted
the
scheduler
already
existing
for
the
multicast
TCP
implementation.
L
That
was
quite
simple,
because
the
multiple
dccp
protocol
as
such
provide
the
same
information
to
the
schedulers
at
the
multi-pass
TCP
does
and
I
assume
that
it's
also
similar
to
multipass,
quick,
so
yeah.
C
Yeah
I
think
that's
a
reasonable
approach
and
and
like
I
I,
do
think
this
work
is
certainly
ready
to
progress
as
a
document
or
certainly
go
to
working
with
last
call.
C
It
seems
like
we
have
solid
implementations
and
whatnot
so
like
I,
don't
want
to
cast
any
shade
on
that
at
all,
but
I
am
I
think
when
we
put
out
a
document
as
proposed
standard,
that
it
kind
of
communicates
to
non-experts
that
this
is
kind
of
safe
to
use
in
a
way
that
I
don't
know
that
the
multi-path
community
is
I,
think
there
are
a
lot
of
people
who,
unfortunately,
are
not
in
this
room
to
speak
for
themselves
in
in
the
kind
of
the
research
Community
say
this
is
the
own
research
problem
like
multi-pass
stuff
in
general,
oh
good.
M
N
That
was
very
harsh.
He
does
exist
so
I've
seen
him
standing
in
front
of
me,
large,
accurate,
so
I
haven't
followed
the
multi-path
research
space
a
while
ago,
so
I
might
not
be
up
to
date
on
this,
and
then
somebody
please
correct
me
so
I
think
the
the
scheduling
problem
is
still
sort
of
hard
and
I
don't
have
I
haven't
seen
any
claims
that
somebody
has
a
general
solution.
I
know
we
have
solutions
that
work
for
certain
kinds
of
path:
combinations
like
you
know,
Wi-Fi
and
through
G
and
so
on.
N
But
it's
you
know
it's
an
it's
an
efficiency
problem
in
the
sense
that
if
you
have
a
scheduler
that
isn't
working
very
well,
you
don't
get
the
throughput
or
the
latency
you
you
might
get
with
a
better
one.
But
it's
not
a
safety
concern
it.
It
might
generate
a
bit
more
traffic
because
there
might
be
some
retransmissions
happening
while
the
scheduler
is
doing
like
stupid
stuff,
but
it's
not
like
driving
us
to
congestion
collapse
right
so
from
a
safety
perspective.
N
I
think
this
should
be
fine
to
go
as
proposed,
but
we
still
actually
do
need
some
scheduler
for
more
General
multi-pass
scenarios,
which
is
the
research
question.
D
M
Examples
yeah
I,
just
saw
a
general
question.
I
have
not
read
this
draft
honestly,
but
I
in
now.
If
you
remember
the
mobile
IP
work,
we
did
quite
a
bit
of
work
on
multiple
care
of
addresses,
multiple
tunnels
and
all
of
that
there,
the
underlying
tunnel,
is
a
GRE
tunnel
which
can
GRS
or
IP,
but
gr
is
now
extended
over
gr
UDP.
So
the
question
is
two
questions.
I
think
what
are
the
key
technical
differences
is
that
in
the
scheduling,
the
way
we
use
both
the
links?
M
That's
question
number
one
question
number
two:
as
you
know,
in
Mobile
AP
we
failed.
You
know,
I,
think
you
know
3gb
system,
we
had
references,
but
we
didn't
have
any
deployments
right.
Overall,
we
spend
a
lot
of
time
if
you
look
at
the
mobile
AP
community,
but
we
didn't
find
any
traction.
So
what's
the?
Where
is
it
heading?
How
do
you
see
who
is
going
to
deploy
this
I?
Think
the
previous
reviewer
commenter
had
the
same
question
are
the
same
comment.
M
Yeah
I
think
I'm
trying
to
compare
it
with
the
mobile
AP
system
where,
where
we
support
multipath,
essentially
you
know
you
can
a
mobile
node
can
establish
two
tunnels
from
two
different
access:
Technologies
right
now:
I
have
the
option
to
do
flow
level,
distribution
or
a
packet
level
distribution.
So.
L
L
Mobility
yeah,
so
we
think
with
the
multipass
gcp.
We
support
the
mobility
aspect,
so
we
don't
see
any
issue
with
that,
but
we
don't
follow
this.
C
So
I
I,
I
I
do
feel
pretty
comfortable.
This
is
not
going
to
lead
to
the
collapse
of
the
internet
under
any
circumstances,
but
we
also
don't
have
a
standards
track
approach
to
multi-path
congestion,
control
to
address
shared
bottlenecks
and
the
like,
so
I
do
have
some
concerns
about
fairness,
issues
which
should
not
necessarily
block
everything,
but
there's
that
and
then
people
will
generally
adopt
this
to
improve
their
performance
because
I
think
intuitively
it
makes
sense.
C
You
know
multiple
house
will
improve
performance
and
if
the,
if
like
the
fine
print,
is
that,
if
you
really
don't
know
what
you're
doing
with
the
scheduling
like
you
may
not
get
better
performance
or
get
much
worse,
performance
that
strikes
abusing
may
be
not
something
to
stamp
with
proposed
state,
and
it
applies
to
all
multipasses,
not
a
specific
critique
of
mpdccp
like
maybe
that's
not
something
to
stand
put
standards
track
at
this
point
like
use
with
care
use
the
feeling,
if
you
know
what
you're
doing,
if
you're,
networking
professional.
C
N
Yeah,
that's
actually
a
good
point
right,
so
so
because
we
actually
did
never
publish
a
couple
of
congestion
control.
So
so
this
is
the
old
original.
You
know:
what's
the
guy's
name
from
Cambridge.
N
N
The
couple
connection
control
has
sort
of
this
property
that
is
probably
safe
in
the
sense
that
you
don't
inject
more
traffic
into
the
network
than
a
single
flow
would,
and
that
might
be
actually
something
that
we
could
pick
up
as
a
baseline
congestion
controller,
because
it's
mathematically
proven
that
it's
you
know
pretty
good
and
then
you
could
normatively
depend
on
it.
And
if
people
wanted
to
do
different
things,
then
they
could
but
yeah
good
point
right.
We
would
have
a
before
standard
without
a
congestion
controller.
F
N
We
can
recommend
which
feels
sort
of
dissatisfying,
so
I
don't
want
to
derail
the
discussion,
but
I
think
it's
sort
of.
We
should
probably
figure
out
if
this
is,
if
we
feel
comfortable
doing
that,
what
are
you
using
for
congestion
control
at
the
moment,
the.
L
L
But
but
we
see
no
issues
with
adopting
the
couple
congestion
code
control,
which
was
specified
for
multiple
TCP,
for
example,
so
that
this
could
happen.
N
And
you
know
what
you
do
in
your
implementation
is
obviously
separate
from
what
you
would
recommend
in
a
specification
and
if
we
could
point
to
the
coupled
in
the
specification,
that
would
be
a
solution.
L
I
struggle
now
a
little
bit
because
I
know
that
there
are
rfcs
for
for
the
couple
congression
control
for
Lira,
at
least
I,
think
and
that
we
mentioned
in
the
in
our
craft
that
this
can
be
used.
C
D
O
Right
and
it's
basically
just
explaining
how
to
cut
the
congestion
control
without
kind
of
like
you
could
apply
different
congestion
controls
to
it
and
I
think
it
only
applies
Reno,
but
anyway,
that's
not
what
my
comment
was.
O
I'm
I'm,
usually
like
we
have
the
discussion
very
often
that
the
transport
area
has
been
very
conservative
about
going
for
experimental
force
and,
like
I'm,
actually
been
arguing
many
times
that
we
should
more
often
go
for
proposed
standard,
but
I'm
actually
a
little
bit
uneasy
about
this
one,
because
it's
a
quite
big
change
like
multi
multi-pass
TCP,
was
experimental
at
the
beginning
as
well,
and
then
we
got
a
lot
of
implementation
experience
and
the
one
advantage
we
have
here
is
that
you
can
actually
borrow
from
that
experience
and
you've
taken
over
many
mechanisms
directly
from
multipass
TCP,
but
you
still
had
to
add
a
lot
of
extra
stuff
to
dccp
anything
about
protection,
reordering
and
so
on.
O
So
there's
there's
a
lot
of
stuff.
That
I
think
is
is
an
addition.
So
this
is
for
me
not
a
small
change,
and
so
for
such
a
change,
I
would
like
I
would
like
to
have
like
a
slightly
higher
barrier,
and
it's
great
that
you
now
have
like
a
second
implementation
there,
but
porting
a
Linux
implementation
to
Android
is
kind
of
I'm,
not
sure.
If
that
actually
comes
as
an
independent
implementation
like
I.
O
D
D
If
you
want
to
think
wider,
are
the
same
risks
in
mptcp
are
the
same
risks
in
mp.
Quick.
Please
talk
to
either
the
chairs
or
the
ad,
but
please
do
it
quickly
rapidly,
because
we
will
have
to
make
some
sort
of
determination
and
I.
Don't
think
we
can
say
more
at
this
time
and
we
won't.
We
won't
make
a
decision
until
we're
ready.
D
However,
we
can
ask
about
working
group
last
call
and
I'd
just
like
to
ask
how
many
people
in
the
room
would
be
happy
to
review
this
document
if
it
were
submitted
to
a
working
group
last
call,
maybe
I
could
try
the
tool
again.
If
you
like
there
you
go,
would
you
be
happy
to
review
the
next
version
and
say:
no,
if
you
don't
think
this
is
anywhere
near
ready
or
say
yes,
if
you'd
be
happy
to
review
it,
and
then
you
can
just
make
your
own
comments.
D
Well,
we
we
see
people
if
you're
review
offering
to
review.
We
saw
14
people
say
they'd,
read
this
or
a
recent
version.
We've
heard
some
discussion
at
the
mic.
You
already
have
a
lot
of
feedback.
We
can't
give
you
the
answers
to
your
question,
but
we'll
work
on
them
with
our
ad
and
then
provide
feedback
to
the
list.
Thank
you
very
much
Marcus.
Thank
you.
D
D
D
P
Yep,
so
this
is
about
some
recent
issues
or
opportunities
found
in
sdp
root.
Recently
is
a
joint
work
with
minus
vestalon
and
Claudio
perfori
we're
not
talking
about
history.
I
will
not
talk
about
to
solve
the
problems
that
would
be
in
other
presentations,
so
the
security
requirement
requirement
properties
for
security
protocols
or
systems
have
increased
incredibly
since
sadp
what
was
was
written
for
the
use
and
for
the
use
cases
there.
Modern
systems
typically
require
strong
confidentiality,
strong
Integrity,
strong
replay
protection
and
high
availability.
P
P
Data
here
refers
to
has
to
do
with
external
user
messages,
not
internal
things
like
scdp
chunks.
Availability
is
a
bit
harder
to
Define,
but
given
an
attacker
should
not
be
I
mean
easy
than
expected
to
affect
the
availability
like
Center,
a
single
packet
and
tearing
down
their
Association
Next
slide.
P
So
these
are
the
issues
we
have
found
as
satp
would
use
this.
The
keys
are
not
directional,
you
can
reflect
authenticated
chunks,
for
example,
data
sets
and
to
do
this,
and
you
need
to
be
in
on
path
attacker
with
read
capabilities.
You
don't
need
to
have
right
capabilities
for
the
reflected
chunks
to
be
accepted.
You
need
to
match
t7
stream,
identifier
and
stream
sequence.
Number
stream.
Identifier
is
probably
quite
easy.
P
If
you
have
very
large
messages
in
the
worst
case,
then
the
stream
sequence
number
wouldn't
change
at
all,
and
the
thing
you
need
to
what
match
is
TSM,
so
after
0
to
2
to
the
power
of
31
chunks,
average
total
power
of
30
in
the
worst
case,
it's
trivial
to
do
this,
and
what's
happened,
is
that
you
might
reflect
the
whole
message.
You
might
reflect
part
of
the
message,
corrupt,
the
use
message,
or
it
might
be
some
error
leading
to
a
termination
of
the
association.
P
Next
then,
as
the
replay
protection
duplication
relies
on
TSN
and
TSN
is
only
has
2
to
the
power
of
32
values
when
this
wraps
of
the.
If
you
have
a
very
long
Association,
then
you
can
do
replay
of
data.
What
you
have
to
match
is
the
same
as
in
the
reflection
attack.
P
Still
worst
use
case
is
worst
case.
Is
that
you
have
very
large
messages,
then
they
only
then
you
just
have
to
wait
and
it's
trivial
of
the
two
to
32
messages.
This
is
very
similar
to
the
other.
The
reflection
is
a
little
bit
easier
to
do
than
the
replay
the
break
slightly
different
properties.
P
Next
slide.
Three
more
issues
should
three
is
a
very
theoretical
issue,
as
as-
and
all
of
these
are
analysis
of
the
specifications,
not
any
implementation,
this
is
a
theoretical
issue.
The
specification
allows
you
to
use
the
same
key
with
different
algorithms,
and
this
is
typically
should
not
not
or
must
not
in
modern
RBC,
but
I
don't
see
any
practical
problems
with
the
current
algorithms
number.
Four
is
reflection,
but
of
authenticated
control
chunks
instead
of
data,
and
this
is
easier
because
you
don't
have
to
match
a
TSM.
P
For
example,
the
error
message
can
be
trivially
reflected
back
to
the
sender.
If
you
reflect
the
sac
control
chunk,
this
might
or
would
or
might
lead
to
packet
loss
missing
data.
Any
consistent,
State,
probably
tearing
down
the
association
at
some
point
and
then
heartbeat
act,
might
also
be
an
attack
availability.
If
you
reflect
that,
so
these
four
is
different
and
another.
P
This
is
an
attack
on
availability,
only
not
on
integrity
and
so
on,
and
five
is
that
you
can
do
replay
of
control
chunks
very
similar
analysis,
probably
worse,
with
reflected
stuff
like
ever
like.
P
This
is
what
the
different
overseas
and
drops
says
about
what
they
offer.
What
is
clear
is
that
3dp,
when
reading
when
specifying
this
thought
that
they
basically
got
dtls
same
property
as
dtls
over
UDP,
they
definitely
thought
they
got
replay
protection.
For
example,
in
the
last
version
of
satp
over
details
over
satp,
because
five,
we
have
made
a
very
thorough
list
of
exact
properties
that
are
provided
I,
think
that's
a
general
recommendation.
It
should
be
easy
to
see
what
is
provided
and
what
is
not
provided,
even
if
you're,
not
an
expert
in
sctp.
P
P
Yeah-
and
this
is
analysis
of
the
what
is
broken
satp
was
all
definitely
does
not
offer
shank
origin
authentication,
for
example
like
it
it
promises,
then
it
all
the
other
most
other
things,
whether
it
promises
or
not.
Otherwise,
you
can
say
it
doesn't
offer
them
or
it
offer
them
in
a
weak
way.
Detail
RFC
6083
is
a
better
dtls
uses,
directional
keys
and
it
uses
single
Mac
to
use
the
message,
so
you
don't
break
integrity
and
you
don't
weaken
confidentiality.
P
These
issues
had
a
worse
effect
on
details
over
satp
piece
in
the
version
4
because
it
uses
several
records
per
user
message
in
zero
five
issue,
one
to
four
should
be
sold
as,
but,
in
general,
all
the
attacks
on
the
availability
is
probably
remaining.
This
is
also
a
bit
harder
to
analyze.
A
lot
of
the
handling
is
implementation
specific
and
not
really
mandated
by
the
specifications.
E
Come
on,
we
can
start
with
that.
We
know
the
next
one
yeah,
so
the
first
one
the
reflect
the
reflection
stuff.
That
is
an
issue
in
HTTP
auth.
We
we
missed
putting
in
a
directional
specific
information
in
the
in
the
computation,
however,
for
dtls
over
HTTP.
That
shouldn't
be
an
issue,
because
the
dtls
keys
are
directional
specific,
so
in
attacker
should
not
be
able
to
in
to
reflect
user
data
and
it's
being
delivered.
So
that's
not
an
issue,
I
think
for
details
over
HTTP
yeah.
E
I'm
asking
about
inserting
data
which
looks
like
it's
coming
from
the
peer
and
it's
not,
and
that
is
not
working.
It
would
not
be
accepted
exactly
the
next
slide,
which
is
the
replay
stuff
and
the
replay
stuff.
Sap
authentication
does
not
provide
any
better
replay
protection,
as
the
base
protocol
does.
That's
stated
in
the
document.
D
E
Dtls
does
this
by
doing
renegotiations,
at
least
in
the
the
old
one
where
dtls
1.0
was
used
and
you
could
do
renegotiations.
That's
the
whole
reason
why
we
did
add
support
for
renegotiation,
and
it
is
a
dance
with
sequence,
numbers
and
and
kind
of
stuff,
but
we
do
not
have
text
in
there
when
you
do
this,
because
you
can
do
this
because
sequence
numbers
are
wrapping,
you
can
do
this
because
you're
using
an
extension
at
that
point
or
Define,
we
just
didn't
specify
that
next
slide.
F
E
Just
there
I
don't
know
if
it's
usable,
but
we
just
didn't,
know
four
and
five.
Is
this
I?
Don't
think
you
can
do
anything
except
availability
things,
however,
and
it's
in
my
view,
an
attacker
which
can
take
a
packet
and
send
it
in
in
in
a
wrong
in
the
other
direction,
might
also
be
able
to
just
drop
packets.
So
it's
your
host,
then
anyway,
at
least
this
was
at
the
point
of
time
we
did
satp
auth.
E
There
was
not
a
huge
difference
between
an
attacker
who
could
read
packets
and
who
could
send
packets
compared
to
one
who
can
take
out
packets,
but
that
might
have
changed.
I,
don't
know,
but
availability
might
be
an
issue
yes,
but
can
be
in
other
ways
and
most
of
the
stuff
we
can
fix
in
a
simple
way
which
I
will.
B
Cover
in
the
next
you'll
be
up
to
next
I
wanted
to
get
in
here
more
as
individual
make
one
quick
comment.
The
word
replay
is
being
tossed
around
a
little
bit.
Cavalierly
insecurity,
replay
attacks
usually
refer
to
tax,
where
the
attacker
can
replay
the
attacking
data
at
the
time
and
place
of
her
choosing
these
replay
attacks
here,
they're,
they
are
replay
attack.
They
are
much
more
specific
because
they,
the
replay,
can
only
happen
exactly
when
the
when
the
sequence
number
rolls
over
and
comes
back
around.
B
C
A
E
I
just
forgot
that
yeah.
Thank
you
for
the
analysis,
so
it's
it's.
It
wasn't
up
to
whatever
our
our
view
that
we
should
need
to
put
in
some
directional
stuff,
because
when
we
did
satp
authentication,
we
did
it
in
the
framework
of
protecting
certain
control
chunks,
which
we
didn't
even
foresee
that
they
will
see
there
will
be
a
lot
of
them.
E
Okay.
So
what's
I'm
talking
about
a
Biz
document,
I
started
on
working
on
this.
This
document
way
before
not
way
before,
but
before
I
got
aware
of
the
security
issues.
So
years
ago
there
was
a
document
sap
auth,
based
someone
from
submitted
by
someone
I,
don't
know
basically
covering
some
textual
improvements
where
some
of
the
wording
was
not
clear
enough
for
the
author
and
he
should,
and
he
wanted
to
improve
that.
E
So
that's
definitely
something
one
should
we
should
we
we
we
would
include
the
motivation
of
this
was
based
on
the
discussion
I
had
with
the
authors
of
the
dtls
document.
Basically,
the
mandatory
to
implement
algorithm
is
Shao
one
hmaker
using
Shawan,
and
there
is
the
wish
to
have
other
ones
deal
with
this
stuff,
and
in
particular,
so
defined
are
actually
two,
so
the
dtls
over
HTTP
wanted
to
use
the
other
one
and
make
sure
from
the
API
perspective
that
they
can
do
this.
E
So
this
is
also
something
we
would
add
there
that
you
have
a
way
to
control
this
and
I
think
to
cover
most
of
the
stuff
John
has
brought
up
is
one
is
to
include
a
direction
specific
data
in
the
computation
of
the
of
the
mac,
and
basically
this
can
be.
This
is
part
numbers
and
the
verification
tag
from
the
from
the
common
header.
E
So
this
is
not
equal
and-
and
you
can
just
do
that-
and
this
third
theoretical
one
I
think
could
be
solved
by
doing
a
key
derivation,
a
directional,
specific
one
and
and
then
algorithm
specific
one.
So
the
status
of
the
document
is
I
submitted
the
zero
zero
version
as
similar
as
possible
to
the
existing
RFC
going
through
formatting
it
as
an
internet
draft,
but
using
the
same
XML
sources.
E
I
got
from
the
RFC
editor
I,
updated
it
to
XML
V3
because
it
was
written
earlier
and
I
did
some
wordsmithing
and
updating
the
reference
about
the
old
ionic
in
considerations.
Are
there?
No
technical
content
has
been
changed
because
next
slide
is
that
one
yeah,
because
the
question
is
whether
this
should
be
adopted
as
a
working
group
item
and
if
yes,
then
it
might
be
better
to
to
change
to
a
working
group
document
and
then
do
any
substantial
changes
there.
So
you
can
easily
see
them
in
the
issue
in
the
data
tracker
there.
E
Q
D
B
Q
So
my
name
is
Westland
talk
about
the
details
over
satp,
so
the
latest
version
is
o5
talk
a
little
bit
status.
We
have
three
issues
here
on
the
list
and
a
little
bit
dealing
with
those
what
you
just
talked
about
so,
but
let's
take
the
next
slide,
so
the
current
status
is
where
we've
been
working
through
with
Martin
Thompson's
review.
We
mostly
addressed
the
issues
there
next
slide.
Is
it
yeah?
Q
There
are
a
few
that's
dependent
on
the
issues,
especially
on
the
detailers
versioning
Etc,
which
will
wait
what
to
do
resolve
before
going
ahead
and
do
those
text
changes
but
yeah
I.
Think
a
big
big
relation
is
to
regards
to
this
SD
of
security
issues.
So,
but
let's
go
forward
to
that
issue
then
so
detail
is
over
HTTP
in
this
version.
Q
Has
this
very
higher
than
a
dependency
on
SD
Western
683
has
because
it's
what
ensures
that
the
detailers
record
as
a
part
of
the
user
message,
protected
user
message,
fragments
are
in
the
right
order.
Therefore,
any
replays
Etc
is
really
bad
for
us,
because
that
means
that
you
could
actually
affect
the
resulting
message.
Message:
Integrity,
if
you
actually
get
through
a
data
record,
that's
verifies
so
a
straight
Replay
that
actually
fits
correctly
could
mean
that
you
actually
get
corrupted
message
through.
That
would
be
really
bad.
Q
There
are
mitigations
here
and
I
think
we
could
go
on
to
that.
Next
slide
for
the
reflection
attacks,
Etc
and
for
the
reflection
attacks,
we
could
I
mean
fix.
The
sap
auth
that
takes
care
of
this
would
fix.
That
and
I
think
re-keying
is,
is
a
requirement
from
detailer,
so
sdp
is
a
fairly
straightforward,
making
it
very
clear
that
you
need
to
retire
the
any
sap
auth
Keys
before
you
wrapped.
Q
So
the
fact
that
this
is
that
I'm
going
to
have
implementation
impact
on
sdb
worth
and
the
stack,
which
means
that
some
of
our
baselines
they
go
into
this
is
affected,
but
I
think
it's.
The
other
question
going
forward
here
is
is
if
these
mitigations
are
sufficient
implementable
to
reaching
those
security
goals
we
see
as
being
sufficient
for,
for
example,
3D,
PPS
and
5D
deployments
there
in
very
long
in
sessions,
so
go
to
next
slide.
Q
I
really
would
like
to
encourage
people
to
guess
about
these
two
I'll
have
some
insight
and
need
for
this
to
actually
do
a
security
analysis
in
terms
of
what
what
their
stands
are.
The
other
aspect
we
see
is
that
the
details
of
sdp
is
complex.
There's
a
lot
of
corner
cases
Etc
to
avoid
the
CTP
implementation
impact.
Q
How
we
could
actually
do
detail
as
more
in
satp,
which
would
be
simpler,
enable
a
less
complex
detail,
less
details,
implementation
requirements
will
be
simple,
Etc
and-
and
we
are
actually
proposing
here
to
actually
that
we
would
actually
quote
write
an
individual
draft
for
an
alternative
to
just
present,
as
as
we
will
have
a
delay
at
this
stage
until
satp
watch
is
fixed
if
you
stay
on
the
current
path
and-
and
that
might
be
that
that
alternative
path
is,
is
equally
fast
or
faster
to
basically
it's
as
fast
as
to
complete
and
provides
Better
Properties.
Q
But
you
know
we
want
to
investigate
that
a
bit
so
next
slide.
Q
Q
So,
but
what
was
raised
in
the
discussion
on
the
main
list
when
I
brought
this
up
earlier,
was
that
yeah,
the
availability
detail
is
1.3.
Stacks
is
currently
not
great.
It
is
much
more
limited
details
1.2.
Q
Q
E
Yeah
I
have
a
question:
is
it
relevant
what
open
source
implementation
open
source
details
implementations
provide
since
there
are
API
issues,
so
I
mean
I.
I
are
the
iprs
outside
of
what
you
need
in
a
dtls
implementation.
Q
And
no
I
think
it's
so
I
I.
Q
Let's
see
how
I
should
answer
that
question
I
think
it
brought
talk
about
open
source
details.
Implementation
here
is
about.
If
how
you
get
an
implementation
of
details
of
satp
in
place
and
and
that
I
mean
details.
Taxes
is
not
trivial.
There's
some
lead
time.
If
you
would,
if
you
would
go
order
one
and
want
to
have
it
tested,
secure,
Etc,
it's
going
to
take
quite
a
while,
and
these
extra
features
you're,
probably
gonna,
have
to
order.
That's
that's
I.
Think
is
the
concern
here.
E
Q
B
B
I
I
said
I
think
I
think
you've
opened
up
a
rat
hole.
I
suggest
you
find
legal
counsel
to
to
work
through
the
license.
Details,
yeah.
Q
Yeah
now
yeah
yes,
I
mean
my
point
to
bring
this
up.
We're
just
saying,
what's
what's
looks
appears
to
be
the
current
situation
of
public
known
implementations.
That's
the
only
thing
I
wanted
to
State
here
so
and
next
next
slides,
okay,
but
is
there
anyone
having
any
more
input,
I
mean
otherwise?
What
was
raised
on
the
list
was
saying:
no,
we
don't
want
to
go
to
1.3
and
I
guess
if
no
one
has
more
input.
That
might
be
where
we'll
be
stuck
here.
Martin
now.
C
Q
So
yeah
and
I
think
it's
especially
dependent
on
if
we
can
take
this
alternative
road
that
might
reduce
this
list
of
features
needed,
which
makes
it
even
easier
so
I
think
yeah
I've.
It
might
be
just
best
to
delay
this
question
a
bit
and
see
where
how
long
it
takes
to
fix
the
rest
of
the
aspects
here.
Q
So
on
this
last
issue,
there's
one
important
aspect
has
to
do
with
some
Marty
brought
this
up
and
background.
Here
is
really
that
yeah,
you
have
those
things
that
are
detailed
as
message
between
the
stacks
between
the
endpoints,
the
handshake,
the
errors
and
errors
or
close
notify,
which
is
terminated.
Q
We
have
63,
did
stream
zero
in
order
delivery
of
these,
we
changed
this
to
any
stream
Etc.
What
Martin
wrote
up
was
saying.
Well,
it
might
be
hard
to
optimize
this
to
ensure
that
you
send
the
records
to
the
fast
path
and
only
take
these
messages
to
your
slower
path.
Q
One
interesting
question
in
this
is
the
identification
of
these
messages
and
that's
actually
I
want
to
hopefully
get
some
feedback
on
that
eventually
It's
like
because
1.3
Heights
is
what
they
are.
The
content
type
is
internal,
it's
encrypted
and
Etc.
So
the
stack
when
it's
processed,
you
will
know
if
it
was.
Oh,
this
is
a
allergic
message,
not
so,
but
if
you
can
actually
be
able
to
sort
this
out
before
you
send
them
to
the
details,
implementation.
Q
We
need
to
have
an
identifier
on
them
being
details,
message
already
being
details,
records
we
protected
user
messages
and,
and
that
ends
up
in
a
question
is
we?
Are
we
okay
to
expose
this?
It
leads
to
I
think
some
potentials
for
trying
to
Target
these
measures,
specifically
in
a
low
volume
or
something
to
to
affect
the
session
affecting
availability.
Q
I
would
say
here
and
not
really
other
things
so
and
but
one
way
of
identifying
was
to
do.
Stick
your
ppid
on
this
particular
message.
That's
headed
for
the
the
end
stack,
not
records,
but
if
someone
has
an
input
on
this,
it
would
be
great.
Q
So
yeah
come
talk
to
me
or
send
an
email
or
whatever
the
timeline
of
this
will
be
delayed.
I
was
hoping
that
we
would
actually
have
a
chance
of
meeting
the
March
deadline.
It
doesn't
look
feasible
now
we
need
to
fix
this
to
be
worth
fixed
or
not
use.
Q
Another
version
alternate
detailer
solution,
but
I
hope
that
we
will
be
able
to
move
forward
in
reasonable
Pace
here,
and
we
do
try
to
update
the
drafts
in
not
two
extents
but
yeah
and
I
think
we
might
have
to
notify
3D
people
about
these
delays
and
the
Securities
should
be
listed
both
here,
so
they
are
aware
of
it,
because
so
so
therefore,
I
would
like
to
send
an
Ellis
from
this
group
to
so.
A
D
You
clearly,
we
need
to
gather
some
momentum
around
the
sctp
and
the
authentication,
problems,
text
and
new
techniques,
so
we'll
look
forward
to
inputs
on
that.
We
have
next
this
okay
I'm
going
to
cut
the
announcements
about
Joe,
touche's
UDP
options
and
the
related
DPL
pmtud
for
UDP
options,
we're
awaiting
a
revised
ID
from
Joe
touch,
which
we
intend
to
work
in
group
last
call.
So
what?
D
E
This
is
an
individual
draft
on
next
slide
and
it
basically
deals
with
satp
over
UDP
encapsulation.
So
this
is
one
of
the
possible
ways
to
transfer
sap
over
UDP
through
Legacy
nuts
and
there's
an
RFC
for
it.
It's
69.51
it
does
not
describe
how
to
handle
in
its
packets
containing
an
inner
chunk,
because
you
have
no
verification
tag.
You
have
no
way
to
verify
that
this
packet
is
really
coming
from
your
peers.
E
So
is
that
it
has
an
impact
on
whether
you
should
update
your
port
numbers
or
not,
and
this
issue
is
covered
in
the
draft.
Given
there
and
I
think
when
Magnus
was
already,
it
was
still
transport
ID.
We
asked
how
to
progress
and
the
argument
was
well.
E
Maybe
you
just
do
a
business
document
instead
of
having
two
small
documents
describing
one
thing
and
I
asked
Martin
got
the
same
response,
so
this
is
basically
the
the
the
the
first
document
trying
to
join
these
both
next
slide
and
I
did
what
I
did
with
the
other
documents
submit
zero
zero
as
the
original
RFC
changed
the
XML
V3,
and
do
some
updates
of
the
documents
which
were
outdated.
E
There
are
two
implementations:
oh
there
are
two
open
source.
Implementations
in
corner
sticks
right
now,
which
is
FreeBSD
and
Linux,
and
both
are
covered
on
the
RFC
and
the
draft,
so
both
are
doing
the
right
thing,
but
it's
not
documented
in
a
single
document.
Right
now
in
the
idea
is
to
get
this
cleaned
up,
which
is
I,
think
the
next
slide
right
yep
and,
of
course
we
would
incorporate
any
additional
feedback
coming
up
through
any
kind
of
discussion.
E
E
I
mean
the
implementations:
are
there
the
draft
describing
the
issue?
Is
there
I
can
keep
it
updated?
It's
just
that
if,
if
you're,
just
looking
based
on
the
experience
from
the
Linux
people,
they
they
find
the
RFC,
but
they
don't
find
the
draft
describing
what
they
also
have
to
do.
So.
That's
it.
E
D
I
I'd
encourage
feedback
on
this
one.
It's
something
we've
talked
about
a
number
of
times.
Please
read
it.
Please
progress
it.
Please
come
and
present
again
and
let's
ask
those
questions
when
we
got
more
people
reading
this,
because
I
I
think
it's
something
that
should
be
of
interest
to
this
group.
Given
the
previous
work,
okay,
Michael,
not.
B
E
Okay,
so
this
is
a
document
about
zero
checksum
next
slide,
SUV
uses
as
a
checksum
CSC
32c,
which
is
a
32-bit
checksum,
which
needs
some
CPU
Cycles
to
be
computed,
and
there
are
use
cases
which
is
webrtc
in
particular,
where
you
run
HTTP
over
dtls.
So
you
have
a
much
better
protection
of
your
packet
from
your
lower
layer
than
you
get
from
your
CRC.
E
So
and
there
are
people
using
webrtc
on
CPU
constrained
devices
which
just
don't
compute
the
CRC
on
the
receive
side,
because
they
can
do
this
without
breaking
interoperability,
but
they
can
do
it.
They
can't
do
it
on
the
sender
side.
So
the
idea
is
to
add
to
the
handshake,
a
parameter
stating
I'm
willing
to
accept
zero
as
a
check
sum,
and
then
you
can
do
this
in
the
handshake.
You
can
do
it
backwards
compatible
and
then
you
don't
have
to
compute
the
checksums
anymore.
E
When
you
do
the
data
transfer,
there
are
co-authors
from
Google
trying
willing
to
implement
this
into
the
what's:
the
name
Google
webrtc
implementation
used
in
Chrome.
There
is
a
quarter
from
Mozilla
I'm
willing
to
integrate
this
into
the
Firefox
browser,
and
so
there
is,
there
is
support
from
implementers
next
slide
and
we
have
support
in
Wireshark.
E
We
have
support
and
packet
tool
for
doing
tests,
I'm
working
on
a
on
an
implementation
and
it's
a
very
simple
document,
but
we
need
this
document
to
get
the
assignment
of
this
parameter.
So
it's
specification
required.
F
D
Yeah
all
right:
okay,
let's
go
here,
we
go
who's.
Who
has
read
this
document
coming
in?
No,
who
has
zero
I'll
come
to
the
mic.
If
you
have
any
question.
D
N
N
Something
that
the
Ayana
will
accept
when
they
get
the
request.
There
should
be
a
expert
reviewer
which
might
be
even
you
I'm,
just
pointing
it
out
right.
So
it's
specification
required
is
not
RFC
required,
and,
and
so
there
is
the
option.
D
Right
I'm
going
to
ask
an
additional
question:
Lars
is
correct,
but
let's
ask
this
question
who
thinks
this
is
a
useful
piece
of
work
which
is
abbreviating
wrk
to
doing
this
working
group
for
the
next
group
you
for
fun
in
the
question
to
try
and
stimulate
a
response
at
this
moment,
because
people
might
think
this
is
a
useful
thing
to
do
here,
even
though
they
haven't
read
it,
because
it's
pretty
clear
what
it's
meant
to
do
and
I
will
keep
talking.
I'll
come
to
the
mic.
A
Very
quickly,
if
you
have
specification
required,
it
could
be
published
as
a
outside.
The
working
group,
I
suppose,
is
an
option.
D
C
You
yeah
possible
yeah
Martin,
Duke
Google.
You
know,
I
asked
the
question
about
SCP
working
group
a
couple
months
ago
and
you
told
me
there
was
no
need
now.
We
have
five
drafts.
C
Like
so
yeah
I
to
be
clear,
I've
read
zero
of
these
drafts,
but
I
think
the
presentations
have
made
a
pretty
convincing
case
for
all
of
them.
You
know
addressed
at
some
point
and
I
I
guess.
The
real
question
is
working
group
bandwidth
for
the
from
the
chairs
like
how
many
of
these
can
we
swallow
at
once
and
do
we
need
to
like
have
some
do?
We
need
this
set
up
very
quick
working
group
to
clear
through
this
backlog.
If
these
things
are
Urgent
or
not,
okay,.
D
We
we
will
triage
that
question,
because
we
also
see
the
same
Community,
making
the
responses
for
each
of
these
drafts
and
we
will
check
the
work
Cycles
Etc
yeah.
This
particular
draft
is,
is
simple.
D
We
will
look
at
that
part
of
the
problem
space.
The
answer
to
my
poll
is
clearly
people
think
this
is
a
useful
piece
of
work
to
do
in
this
working
group
and
so
I'd
encourage
you
to
keep
revising
and
come
for
an
adoption
call
in
the
future.
Okay,.
A
Q
I
guess
I
need
to
pull
my
and
to
get
vigorous
about
the
discussion
about
once
just
ensuring
that
I
I
think
this
document
makes
sense
in
the
context
this
it
just
needs
to
be
very
clear
on
on
its
very
limited
applicability
or
is
saying
the
requirement
that
I
think
it's
decently
clear
already.
So
it's
not
a
problem
but
yeah
so
yeah
because
running
without
checksums,
verifying
ports
Etc
over
the
internet
and
having
no
additional
mechanisms
would
be
a
bad
idea
from.
F
R
So
this
draft
is
activities
you
have
been
presenting
in
ITF
in
different
working
groups
and
in
particular
in
a
quick
working
group.
The
Main
Idea
here
on
this
description
is
so
these
first
slides
are
how
to
quickly
catch
up
with
the
activity
about
catching
up
and
on
the
boundaries.
So
in
the
satellite
industry
there
are
some
cases
where
it
takes
a
lot
of
time
for
the
condition
control
to
quickly
ramp
up
to
the
high
bdb
that
is
available.
So
this
is
an
experiment
we
have
been.
R
R
R
The
thing
is,
you
should
not
do
that
without
any
care,
so
you
have
to
be
careful
about
how
to
do
that
and
and
stop
doing
it.
If
you
find
that
anything
has
changed
in
network
next
slide,
please
so
we
have
been
proposing
different
type
of
documents
to
cover
this
issue.
R
In
the
last
summer,
we
there
had
been
a
adoption
core
in
the
Creek
Coffee
group
for
two
drafts,
so
basically
the
first
one
is
careful
regime
is
how
you
can
store
computed,
constant
control
parameters
to
actually
modify
the
Construction
Control
behavior
of
subsequent
connections.
Let's
say,
and
the
first
connection,
I
understood,
I
was
using
a
satellite
link
and,
on
the
next
connection,
to
the
same
peer
I
just
want
to
use
and
previously
computed
control
parameters.
R
R
R
Indeed,
we
need
to
must
we.
This
solution
must
to
effectively
share
the
capacity
with
all
the
transports,
and
maybe
there
is
a
way
to
do
that
with
all
the
transports.
So
that's
why
we
are
here
and
to
see
if
there
are
any
discussions
here
that
are
related
to
and
relevant
for
the
tsv
WG.
R
R
So
if
we
assume
that
we
have
had
a
first
connection
that
I
finished
and
the
information
has
been
stored,
we
think
a
question,
an
open
question
that
we
have
is
what
what
event
information
you
you
can
obtain
to
change
that
the
path
has
not
changed
that
much
so
we're
seeing
that,
for
example,
if
you
lose
back
if
you
lose
packets
after
sending
the
first
ADW,
there
should
be
some
problem
in
the
network.
So
you
may
not
resume
to
the
previous
construction
parameters.
You
can
use
a
minimum
entity
values.
R
You
can
also
use
the
interpack
enter
packets
time,
the
interpacking
time
on
other
activities.
We
have
measured
that
this
metric
was
very
useful
to
detect
conception
in
the
network.
So
we
think
there
is
this
discussion
here.
We
have
discussed
some
algorithms
in
the
draft
that
we
have
been.
We
have
posted
recently,
then,
when
you
know
that
the
path
has
been
checked,
how
do
you
carefully
jump?
R
R
Let's
say
you
just
did
the
jump.
How
did
you
react
if
you
see
any
Collision
in
the
network
and
also
Implement
when
Christiano
implemented,
that
in
Pico
quick,
we
saw
that
there
are
some
aspects
that
are
very
specific
on
the
construction
control
that
you
have
been
using.
R
If
you
use
cubic
or
Reno
it's
different,
you
may
have
I
start
or
I
start
plus
plus
making
your
Construction
Control
going
out
of
the
slow
starts,
so
you
this
is
something
that
we
think
is
very
interesting
to
discuss,
and
these
items
are
currently
discussed
in
the
in
the
current
version
of
the
draft
next
slide.
Please.
R
That's
what
I'm
saying
that
are
related
to
transports,
but
not
maybe
third
relevant
40s
vwg,
it's
basically
how
do
the
clean
tasks
for
this
jump,
because
in
the
quick
implementation
we
have
been
using
the
Sierra
TT
and
the
TLs
certificate
signaling,
or
we
at
least
we
use
a
specific
frame
that
is
protected
by
TLs.
But
the
problem
is
that
when
you
use
you,
may
you
may
end
up
being
very
specific
on
both
Construction
Control
and
the
series
visions
that
you
have.
R
You
are
using
basically
to
know
what
do
you
send
and
when
do
you
send
it
and
how
protected
this
information
is
and
also
another
aspect
is
really
the
real
system,
performances
of
that,
and
that
is
not
covered
in
the
draft
for
the
moment.
But
in
the
end
we
have
been
pushing
out
for
this
working
quick
cooking
group.
We've
been
said
that
maybe
this
should
be
addressed
with
a
more
wider
view.
S
Hi
yeah
I
was
just
wondering
this
has
been
going.
This
has
been
used
by
TCP
in
Linux
kernel
for
some
time,
like
TCP
metrics
or
whether
you've
looked
at
the
how
that
works
with
in
comparison
to
the
approaches
you've
been
considering
because
it
caches
like
a
sea
wind
rtt,
and
then
it
obviously
reuses
those
for
the
different
congestion
control,
algorithms
that
are
kicking
off.
R
Yeah,
so
these
thank
you.
We
there
we
have
been
looking
at
that,
and
also
we
wanted
to
have
this
kind
of
TCP
metrics
save
for
quick
and
in
a
way
that
is
interoperable
in
a
way
that
the
client
can
participate
in
the
decision
on
whether
this
Matrix
is
used
or
not.
S
F
R
S
D
S
D
That'll
be
so
helpful
and
while
we're
talking
about
where
it
might
be
going,
I
think
it's
the
queue
for
Martin
to
come
to
the
mic.
For
one
minute.
C
Yeah
I
just
want
to
announce
to
people.
Many
of
you
probably
remember
from
tsv
area
114
a
discussion
about
now.
Could
you
ask
control
working
group
possibility
that
chartering
work
is
still
going
along
in
the
background
and
for
those
of
you
who
might
be
interested,
it
will
be
a
side
meeting
at
5
p.m.
On
Thursday,
please
come
by
if
this
is
up
your
alley.
Thank
you.
D
D
Obviously,
Thursday
is
an
interestingly
to
attend
if
you
possibly
can
and
I'll
take
my
mask
off
to
stand
here
to
put
yet
another
flavor
on
the
whole
story,
which
is
a
draft
that
I
produced
a
little
while
ago,
which
may
or
may
not
be
related
to
all
the
story.
So
next
slide,
please,
okay,
this
slide
kind
of
captures.
What
I
was
trying
to
do?
The
ITF
has
said
about
much
about
congestion
control
in
the
past.
Much
of
it
has
prevented
a
meltdown
congestion
collapse
on
starvation
of
the
internet.
D
Does
Our
advice
still
apply.
We
should
perhaps
check
this
there's
more
than
40
references
which
are
informative
on
this
and
about
10,
which
are
normative
descriptions
of
congestion,
control
things
you
need
to
do
next
in
2019
and
I
decided
to
write
a
four-page
document
on
the
core
things
that
would
encourage
a
cc
to
play.
Well,
what
happens
if
you
make
a
new
congestion
controller?
What
would
you
be
needed?
And
next
it
took
more
than
four
pages
next,
so
I
wrote
a
draft
I
presented
in
Singapore.
You
might
go
what
happened?
D
This
is
actually
okay,
I,
don't
have
an
opinion,
but
I've
tried
to
write
a
draft,
and
this
is
the
draft
story
and
we're
now
at
draft
seven.
Please
go
quickly.
Next,
please
there's
a
principles
of
congestion
control
and
the
key
thing
that
I'm
motivating
is
that
things
have
changed.
D
We
absolutely
must
be
preventing
persistent
congestion,
that's
things
like
starvation,
congestion,
collapse
and
lots
of
other
horrible
things
which
would
result
out
of
work,
but
we
I
also
have
to
react
to
incipient
congestion
by
adjusting
the
rate
of
particular
flaws
to
nicely
play
with
one
another
and
I
think
these
exist
at
different
levels
of
importance
and
we've
kind
of
recognized
that
over
the
years.
But
it's
not
really
reflecting
the
RFC
series
to
the
same
extent.
So
I've
tried
to
group
the
recommendations
on
these
two
topics
separately.
D
Next
slide,
yeah
I
rewrote
I
changed
a
lot
and
it's
like
there's
a
table
of
contents
just
to
encourage
you,
it's
not
actually
as
long
as
it
looks
because
some
of
this
is
motherhood
and
apple
pie,
and
some
of
it
is
the
new
stuff.
Well,
the
new
stuff,
just
grouping
the
old
stuff.
So
actually
it's
an
easy
read.
D
So
please
read
it
next
slide
and
is
anyone
willing
to
play
with
me
on
trying
to
get
this
right
and
that's
the
reason
for
standing
here,
I've
had
one
or
two
offers
at
this
meeting
of
people.
Who've
worked
in
congestion
control
previously
and
would
be
really
great
people
to
have
on
my
side
to
try
and
get
this
right.
If
you're
willing
to
join
me,
please
do
if
you've
got
different
opinions
to
me.
D
D
C
All
right,
I'm
not
going
to
go
all
the
way
through
this,
but
there's
a
bunch
of
ecn
drafts
out
there.
I,
don't
think
they
cover
all
the
cases.
C
Specifically
I
did
a
review
of
a
ipsec
draft
that,
like
matches
a
bunch
of
packets
together,
if
you
match
together
different
ecn
markings
given
that
CE
is
now
sort
of
ambiguous,
there's
trouble
next
slide,
and
so
after
a
lot
of
thinking
and
a
lot
of
assumptions
which
are
probably
wrong
and
ought
to
be
challenged,
like
I
came
up
with
this
big
truth
table,
please
take
a
look
if
there's
something
we
want
to
do,
we
can
do
it
if
we
want
to
somehow
Munch
documents
together,
it's
getting
late
in
the
day,
but
we
could
do
that
too.
B
So
David
black
speaking,
individual
I,
took
a
look
at
I,
took
a
look
at
this
and
the
existing
drafts.
This
is
a
standalone
piece
of
work.
Mark
we
would
Martin's
take
that
it's
not
covered
in
60
40..
It
looks
like
it
would
be
a
useful
update
and
as
individualized
support,
just
just
taking
this
forward
and
doing
this
as
an
add-on
to
60
40.
B
D
People
here
the
meeting's
not
over
we're
carrying
on
the
IHF
meeting
for
a
while.
So
please
continue
to
talk
about
transport
things
this
particular
session's
finished.
Thank
you
for
attending,
see
you
online
or
in
person.
If
you're
here.
B
C
B
Two,
because
there's
another
hour
material,
we
can
get.