►
From YouTube: IETF99-TSVWG-20170720-1810
Description
TSVWG meeting session at IETF99
2017/07/20 1810
https://datatracker.ietf.org/meeting/99/proceedings/
A
Okay,
welcome
back
to
the
continuation
of
the
TSU
WG
Multi
ring
circus,
better
known
as
the
second
session
of
the
TSV
WG
working
group
meeting
here
in
Prague,
your
chairs
are
gory,
fair,
first
West
Eddie
and
myself
David
black
gory
and
I
are
up
here.
Wes
is
still
back
in
the
back
back
of
back
in
the
u.s.
somewhere.
This
is
the
note
well
noted.
Well,
it
applies
to
you-
and
this
is
the
last
chair
slide
for
today,
unlike
unlike
how
we
started
the
week.
A
So
this
is
item
for
agenda
review,
after
which
we're
going
to
bring
it
up.
Let's
see
at
least
Georg
is
here
from
3gpp2
talked
about
a
little
bit
about
5g
and
how
it
relates
to
transport.
We
then
have
a
couple
of
SCTP
drafts.
A
couple
of
FC
FEC
update
drafts
and
Michael
Tilson
has
an
individual
draft
about
something
that
needs
to
be
fixed
in
the
UDP
and
cap
of
SC
TPS.
It
looks
as
he'll
explain
later
any
anything
else.
B
A
A
B
A
A
D
Yeah,
thank
you
very
much
for
having
me
here.
I
I
have
no
slides.
Sorry
for
that.
We
were
just
like
talking
today,
practically
whether
I
should
say
something.
My
message,
I
hope
is
very
simple.
I
think
the
the
whole
area
here
the
the
work
you're
doing
is
a
very
positive
example
for
how
3gpp
and
ITF
work
together
to
work
on
ECM
I.
D
From
my
perspective,
never
was
a
reason
for
any
controversial
or
anything
like
that
and
when
smoothly
and
the
input
we
gave
as
well
as
the
input
you
gave
to
12
or
3gpp
was
always
welcomed
and
worked
in
so
I.
I
have
really
at
that
point
no
clear
view
on
how
we
will
progress
like
what
additional
topics
and
additional
requests
we
will
have
from
3gpp.
As
I
already
said,
on
Tuesday,
we
are
still
building
up
the
requirements
on
on
the
5g
system.
D
Also,
on
the
protocol
level,
we
got
the
question
during
the
Q&A
whether
somebody
in
3gpp
wants
to
remove
ECM
from
the
5g
system.
I
had
a
few
talks
with
a
few
guys
again
now.
I'm
not
aware
of
this
I
also
did
get
an
indicator.
Also
didn't
get
an
indication
that
anybody
else
is
immediately
aware
of
that
I
think
if
anybody
of
you
who
has
a
concern
or
knows
of
any
activities
on
that
as
I
said,
I'm,
also
not
a
run
expert,
so
there
might
be
activities
or
discussions
in
run.
That
I'm
not
aware
of.
D
Please
come
to
me.
We
can
at
least
and
identify
much
better
whom
to
talk
to
I.
Think
from
the
perspective,
I
have
also
from
what
I
know
from
the
CT
groups.
We
should
go
on
with
the
ecn
work
as
it
is
at
the
moment
and
I,
don't
see
any
any
danger
in
that
respect,
but
I
said
for
further
work.
We
need
to
see
if
something
comes
up.
I
will
produce
a
few
slides
and
come
to
the
next
meeting
or
whenever
it's
time
to
present
issues
of
interest,
or
we
will
have
an
expert
here.
Thank
you.
D
A
See
what
comes
in
the
end,
so
thank
you
very
much.
I
want
to
echo
Spencer's
remarks,
you're
more
than
welcome
here
at
any
time,
the
future
to
talk
about,
I,
think
things,
things
that
are
relevant
and
move
things
along
visibly
faster
than
we
can
get
them
done
by
by
exchanging
liaison
statements.
Absolutely
thank
you.
Thank
you.
F
B
A
A
G
G
What
is
still
being
to
do
is
suggestion
to
split
or
to
rearrange
the
content,
which
is
their
into
two
parts,
one
for
implementers
of
nets
and
one
relevant
to
implementers
of
the
endpoint
so
that
if
you're
only
implementing
one
page
one
part,
then
you
only
need
you
don't
need
to
read
the
whole
document
and
the
our
the
other
one
is
I.
Think
all
the
examples
we
are
using
there
I
are
using
ipv4
addresses.
G
B
H
G
The
next
one
is
a
bit
more
interesting.
It
is
a
document
we
have
around
for
some
time.
It
covers
aratus
in
RFC
4960,
which
is
the
current
base
back
of
SCTP,
and
we
have
added
since
the
last
IETF
a
couple
of
issues.
So
for
the
document
structure
is
for
each
issue.
We
have
a
separate
section
describing
what
has
to
change
in
RC
4960.
So
it
is
based
basically
over
text
new
text
and
it
has
a
textual
description.
What
the
problem
is
and
what
the
solution
is.
G
So
the
issues
we
resolved
is
first
reduction
of
the
initial
RTO.
So
at
the
time
we
were
writing.
Rfc
4960
three
seconds
was
the
initial
value.
Now
it's
one
second,
and
we
just
adopt
that
from
TCP
if
we
are
removing
an
ordering
requirement
of
part
second
territory.
So
it's
stated
in
the
document
that
one
chunk
has
to
be
before
the
other.
In
case
you
receive
a
date
Chang
where
you
don't
support
that
stream,
and
it
doesn't
matter
which
sequence
it
is.
We
just
removed
that
there
was
a
problem
in
the
abstract
API.
G
A
parameter
was
used
there
and
not
described
so.
We
won't
be
remove
the
parameter
because
it's
not
necessary
for
web
RTC.
They
wanted
the.
The
point
is
that
they
want
to
change
over
time
the
DHCP
value,
and
you
can
do
that
in
the
socket
API.
But
we
are
missing
a
statement
and
when
our
consequences
of
this
change
is
that
you
might
end
up
in
a
different
queue,
you
have
to
reset
the
congestion
controller.
So
we
added
a
statement
regarding
that.
G
The
ICMP
handling
which
is
described
in
in
the
document
was
inconsistent
for
ipv4
and
ipv6,
so
some
ipv4
packets
were
handled,
but
some
corresponding
ipv6
packets
were,
and
we
have
removed
that
we
added
text
to
cover
the
heading
of
soft
errors.
So
you
can
now
signal,
what's
called
in
the
host
RFC
soft
errors
to
the
application,
we
clarified
the
congestion
control,
a
congestion
window
handling,
so
it's
you
can
only
grow
the
congestion
window.
G
If
it's
fully
used
in
when
you
when
you,
when
you
want
to
grow
the
congestion
window
and
since
you
can't
fragment
data
based
on
the
congestion
window,
the
statement
is
you
can
over
book
by
Attlee,
but
by
at
most
a
packet
or
a
chunk,
so
that
you
can
always
fully
use
the
congestion
window.
So
if
you
have
two
bytes
left
and
the
next
message
is
10
bytes,
then
you
can
send
10
bytes
and
the
same
applies
to
zero
with
no
probing
well.
G
Your
window
is
so
small
that
the
next
chunk
is
larger
than
that
and
you're
allowed
to
send
it
to
trigger
this.
So
this
has
been
addressed.
We
still
have
remaining
issues
we
want,
and
the
authors
of
the
document
talked
about
this
during
this
week,
how
to
resolve
them.
So
there
is
a
C
32,
the
example
code
which
uses
short/long
in
engine.
We
already
had
a
problem
where
on
some
platforms,
long
as
64-bit
or
some
platforms,
long
as
whatever,
and
so
we
we
will
go
through
explicit
types
where
the
type
states
how
long
this
variable
is.
G
This
covers
the
stuff.
We
still
have
one
issue
left
from
4960.
We
have
a
hostname
parameter
where
you
can
in
the
init
are
in
it
act.
You
can
put
in
a
hostname
parameter,
it's
a
fully
qualified
domain
name,
and
we
meant
we
observed
that
during
all
the
interrupt
tests,
this
parameter
wasn't
this.
The
support
of
this
parameter
never
has
been
successfully
tested.
G
So
we
will
deprecated
this
parameter
in
in
the
base
document
saying
that
it
should
not
be
used
anymore
and
the
supported
address
parameter
will
be
used,
but
the
host
name
parameter
must
not
be
announced
and
when
it's
announced
it
should
be,
it
must
be
ignored.
So
this
helps
in
case
you
have
an
implementation
supporting
this
stuff
and
kernel.
G
Implementations,
don't
support
this
parameter
and
they
are
always
protected
itself
by
not
announcing
this
host
name,
parameter
type
and
the
supported
address
types,
and
the
last
thing
is
that
there
are
three
RFC
is
currently
available:
updating,
RFC
4960
and
that's
RFC
sixty
ninety
six,
which
is
adding
a
chunk
flags
registry.
So
we
will
include
that
in
the
base
document,
the
action
by
an
ax
has
already
been
taken,
but
it's
then
documented.
G
In
that
thing,
we
will
put
a
reference
to
RFC
as
six
three
three
five,
which
updates
the
aya
ini
registration
procedures
for
the
port
numbers,
and
we
will
include
our
C's
1753,
which
adds
a
bit
to
the
data
chancara,
which
is
implemented
by
linux
and
freebsd
for
a
long
time.
So
we
then
have
a
single
document
specifying
the
base
protocol,
and
that
is
basically
what
we
want
to
address
during.
G
Let's
say
the
next
week's
comments
are
still
welcome
and
the
overall
protest,
while
this
document
is
that
it's
an
informational
RFC,
we
want
to
protest
published
as
an
informational
RFC,
and
it
will
be
the
basis
of
another
document,
the
best
document
of
RFC
4960.
So
we
basically
take
ROC,
4960
and
then
take
the
approved
diff,
apply
it
and
then
run
that
through
the
IETF
for
publication.
One
of
the
points
Gauri
wants
to
I.
Think.
Can
you
go
back?
One
slide
sure
a
second.
B
B
Okay,
so
is
there
anything
new
in
the
list
of
features,
know
him
that
have
not
previously
been
in
the
4960
I
mean,
apart
from
those
three
things:
no,
okay,
just
checking
as
we
move
forward.
It's.
B
G
G
B
Okay,
yeah
yeah
six,
three
three
five
is
the
revised
Diana
procedures
for
transport
protocols,
its
BCP
yeah.
It's
got.
This
got
the
correct
status
and
it's
a
change
to
the
ANA
procedures
across
the
whole
transport,
so
that
shouldn't
be
modified
by
this.
But
this
must
then
refer
to
this
yeah
normatively.
A
B
B
The
the
main
criteria
here
is
that
we
don't
add
new
features
correct,
but
we
can
change
text.
We
can
remove
features.
We
can't
clarify
and
the
level
to
which
we
do
that
will
be
determined
exactly
by
what
this
feature
list
is
when
we
present
it,
like
just
Spencer,
I,
think,
there's
the
end,
you
keep.
F
E
H
B
A
Feck
friend
so,
while
I'm
bringing
up
Vincent's
slides
a
giveaway
one
of
the
little
secrets
to
how
we
managed
to
run
this
working
group,
our
ad
was
impressed
the
more
drafts
we
have.
We
assign
shepherds
early
so
that
we
know
for
each
draft
who
the
responsible
working
group
chair
is
and
so
for.
Vincent's
two
drafts,
I'm
gonna,
be
the
Shepherd
and
the
UDP
options
raft
that
we've
recently
adopted
Gauri's,
Mary,
Shepherd,
so
Vincent
I
think
I've
got
your
slides
and
get
them
full
screen
here.
Okay,.
I
Yes,
it's
working
well,
so
the
first
few
slides
is
about
about
its
effect
from
extension
documents.
Well,
this
one
I
made
a
few
improvements
to
the
documents.
First
of
all,
this
is
now
working
repeatin
documents
and
I
change
a
little
bit
the
name
of
these
documents.
Previously
there
was
this
mansion
with
you
that
was
suggesting
that
it
could
be
a
new
version.
This
is
no
longer
than
you
version
for
sure.
I
No,
this
is
certainly
not
a
new
version
she's
just
an
extension
of
the
same
protocol
and
I
wanted
to
reflect
it
in
the
new
document.
Name.
Oh
that's
the
first
point,
then
we
received
a
few
commands
essentially
from
managers,
the
uppity
about
wordings
and
essentially
so.
This
is
the
reason
why
I
get
rid
of
this
convolutional
adjective
and
we
moved
it
and
replace
it
with
a
sliding
window.
I
So
there
was
already
a
section
free,
the
previous
version,
but
this
section
free
was
just
two
lines:
long
saying
that
okay,
there
is
no
change
this
section,
so
please
go
to
go
back
to
IFC
6363
and
the
production
to
this
document
was
more
about.
Why
do
we
want
to
extend
this
protocol?
So
there
was
no
way
to
and
fake
frame
to
understand
what
is
the
concept?
What
is
the
architecture
so
far,
so
I
took
advantage
of
this
new
version
to
add
one
new
section:
3.
I
I
I
I
For
the
same
reason,
I
get
rid
of
conversion,
illogical,
replace
it
with
sliding
window
I
kept
the
Westham
discussion
at
some
point
of
time
was:
we
should
change
name
of
this
effect
scheme
with
something
else.
Well,
finally,
I
decided
to
keep
oil
fee,
but
now
I
make
it
clear
that
is
a
sliding
window,
I'll
see
if
X
Kim,
so
I
added
the
sliding
window
in
this
extension
of
the
acronym.
Well,
that's
a
detail,
but
can
make
sense.
I
Know
if
it
wasn't,
if
I
forgot
to
do
that
before
I,
don't
remember
exactly
how
it
came,
but
there
was
no
way
to
have
multiple
repair
symbols
pawtucket
previously,
so
just
to
try
for
a
little
bit
what
I'm
talking
about
there
is
a
way,
a
mechanism
for
moving
from
an
application
packet
rate
safe
to
make
it
simple
to
symbols
that
are
managed
by
the
FEC
codec
symbols
traditionally
are
much
smaller
than
the
application
packet.
Rtp
packet,
for
instance,
does
good.
I
I
So
there
are
good
reasons
for
having
this
mapping
and
now,
if
you
do
that,
the
consequence
is
that
the
Reaper
symbol
will
also
be
the
size
of
the
source,
symbols
or
four
symbols
worth
small
size,
repair,
symbol,
socks
and
therefore,
if
you
instantly
for
I
think
for
being
able
to
have
multiple
Reaper
symbols
per
repair
packet,
because
it
makes
it
will
remove
some
overhead
when
transmitting
repair
packets.
Instead
of
having
multiple
packets,
you
will
have
only
one,
only
one
UDP
IP
header,
only
one
either
for
the
coding
spot.
So
what
I've?
I
What
you
can
see
in
this
figure
is
the
resulting
packet
that
will
be,
in
that
case,
composed
of
three
Reaper
symbols
and
our
single
adder
and,
of
course,
on
top
of
that,
a
single
UDP,
IP
header.
There
are
few
consequences
if
we
want
to
do
that,
essentially
the
fact
that
those
three
Rita
symbols
will
be
produced
by
you
exactly
the
same
and
cutting
window
using
a
repair
key,
which
is
a
seat
for
the
PNG
that
is
easily.
I
Deductible
from
the
first
version,
so
the
first
repair
key
value
will
be
for
the
first
repair
symbol
and
the
next
two
repairs
involves
will
have
this
value
plus
1
and
this
value
plus
2.
So
it's
pretty
easy.
We
can
manage
this
in
an
implementation
very
easily.
It's
not
a
problem.
So
that's
the
main
change
it's
already
in
the
document,
and
then
there
was
also
another
change.
There
was
a
section
that
was
empty,
called
FEC
code
specification.
This
is
now
completed
and
I
also
added
the
security
considerations
on
the
personal
management
considerations
sexuals.
I
I
The
sliding
window
else
effects
scheme
documents
well,
as
in
the
rest,
very
well,
of
course,
I
need
to
proofread
it
and
I
have
one
or
maybe
two
technical
questions.
What
I'm
mentioning
here-
and
this
slide
is
one
of
them-
I-
have
to
discuss
a
little
bit
with
colleagues.
I
have
to
do
a
few
tests,
but
well
there
is
no
big
question
behind
well,
it's.
The
question
is:
should
we
take
advantage
of
this
document
to
add
some
well
one
or
two
more
technical
extensions
or
not?
Those
extensions
are
not
very
complexed.
I
A
K
I
I
G
G
So.
What
is
the
scope
of
this
document?
So
the
scope
is
to
clarify
a
couple
of
things
which
we
refer
to
SCTP
over
UDP.
You
are
ipv4
SCTP
over
UDP
over
ipv6,
so
it's
really
and
kept
relating
SCTP
directly
over
UDP.
It
does
not
apply
to
SDP
over
details
over
UDP
over
ipv4
ipv6,
which
is
used
by
web
RTC.
So
this
is
not
related
to
web
RTC.
It's
only
for
encapsulating
SDP
over
UDP
to
get
through
the
legacy.
G
Nuts
from
the
document
specifies
the
differences
between
our
C's
six
nine
five
one,
which
is
the
specification
for
IC
over
UDP
and
an
upcoming
this
document
and
one
and
once
this
document
starts
as
an
internet
draft,
this
draft
will
just
die.
So
what
is
the
status
it
describe?
What
is
not
described
in
the
RFC
is
how
you
handle.
G
That
it
describes
the
handling
of
embedded
addresses
in
in
in
it
and
in
attack
choice
and
how
you
verify
these
packets,
so
some
of
the
packets,
you
can't
verify
like
the
init
packet.
So
if
you
get
a
packet
and
you
do
updates
of
the
of
the
port
number,
you
can't
verify
the
verification
tag
and
that's
not
clearly
specified
in
the
and
the
base
RFC.
G
It's
it
tells
you
that
you
have
to
do
this
before
doing,
but
it
doesn't
make
explicit
that
you
don't
do
it
if
you
can't
do
it
and
what
has
recently
been
added
is
a
consideration
for
keeping
netstat
alive.
So
this
means
that
you
reduce
the
heartbeat
rate,
so
SCTP
will
send
periodically
heartbeats
and
the
default
is
30
seconds
which
might
be
not
short
enough
to
keep
net
states
live
for
UDP
traffic.
So
the
suggestion
is
to
reduce
this
to
15
seconds.
A
G
Yeah
and
again,
this
document
is
then
the
base
of
the
base
document.
There
are
any
comments
on
this.
I
would
happy
to
get
them,
except
for
that
the
document
seems
to
be
stable.
Just
so
you
make
starting
at
this
document
seems
to
make.
B
B
G
K
G
It's
not
based
on
measurements,
it's
just
I,
looked
up
what
other
protocols
do
for
keepalive
packets
and
it's
about
15
seconds
what
they
use
and
the
RFC
for
us.
I
mean
right
now
the
RFC
says
for
it,
for
for
heart,
beats
is
30
seconds
and
the
application
can
change
it
anyway.
So
application
content
can
control
this
and
can
do
this,
but
at
might
make
sense
to
just
let
the
STP
stay.
Take
care
of
this
in
case
of
UPN
comes
to
see
us
good.
Thank.
B
B
A
B
So
look
since
we're
releasing
you
early,
maybe
we
can
offer
a
little
bit
of
homework
or
interesting
reading
too,
before
the
next
I,
you
have
to
have
some
discussion
on
TS
b/w
gene
list
number
one
we're
looking
for
data
on
the
le
p
HB
candidates
on
how
different
diffserv
code
points
might
work
in
real
networks.
If
you're
interested
in
this,
please
do
measurements
or
please
talk
about
it
on
the
list
to
help
roll
and
progress
that
draft
l4s
architecture.
We'd
love
people
to
read
this
and
comment
on
it.
B
Alpha
s
is
important
properly
as
we
move
forward.
L4
s.
Architecture
document
is
a
thing
to
get
right
and
CN
n
captain
shim
have
been
talked
about
a
lot
around
the
IETF
this
time,
and
we
said
we
do
a
working
group
last
call
soon.
Please
read
these
and
finally,
the
RFC
496
or
a
rata
we
just
talked
about
if
you
use
SCTP,
if
you're
interested
in
setp,
if
you
think
you
may
use
setp,
please
read
the
list
of
errata
because
we
intend
to
change
the
standard
a
little.