►
From YouTube: IETF97-TSVWG-20161116-1110
Description
TSVWG meeting session at IETF97
2016/11/16 1110
A
B
C
A
C
C
A
A
A
A
A
A
Ok,
this
is
the
note.
Well,
it
applies
this
session
as
it
applies
to
every
other
session
at
the
IETF.
This
is
the
I've
got
the
right.
Whoops
no
I've
got
the
wrong
slide.
Deck
hang
on
breakfast
naugahyde
slide
deck,
not
paint
engines
morning.
Dr.
review
reminder
in
particular
I
need
to
say
something
about
this
in
a
minute.
So
is
Jennifer
Wednesday
starting
the
agenda
review.
We
have
four
sctp
drafts.
Some
of
these
are
just
status
reports.
Don't
blink
they're
going
to
go
by
fairly
quickly?
A
Some
of
them
have
slightly
longer
discussion,
and
then
we
have
to
individual
drafts.
I
get
to
try
a
challenge.
Oh
touch
to
talk
about
transfer
options
for
UDP
and
then
visit
Roca
is
going
to
talk
about
a
version
two
of
the
forward
error
correction
framework-
and
I
guess
I'll
be
taking
frantic
notes
during
during
during
during
that
talk.
Since
he's
one
of
the
note
takers.
Okay,
we
have
the
usual
warning
for
speakers.
Where
is
it
oh
yeah
there?
It
is
there's
a
pink
box
here.
Please
stand
the
pink
box.
It
helps
the
remote
participants.
A
A
D
D
So
basically,
what
the
idea
of
this
draft
is
that
we
are
describing
issues
found
since
the
publication
of
RFC
4960,
which
is
the
specification
of
sctp.
We
describe
issues,
solutions
for
them
and
exactly
extra.
We
want
to
address
them
in
the
second
draft.
Rfc
4960
be
so.
This
draft
is
kind
of
prerequisite
for
this
document.
D
D
Since
I
TF
96,
we
describe
six
new
issues
and
in
our
list
we
have
currently
14
open
issues,
but
I
think
that
nine
or
10
of
them
should
be
actually
addressed.
Yeah.
We
use
issue
tracker
and
in
github,
so
all
holy
issues.
All
revisions
of
the
draft
and
some
of
the
discussions
are
there
it's
public
and
anyone
can
go,
then
publish
issues.
D
D
Actually,
we
have
some
issues.
Some
external
issues
I
mean
not
only
published
by
coffers
of
this
draft,
so
anyone
is
welcome
to
publish
issues
and
video
look
at
them
and
we
also
want
to
get
feedback
on
this
draft,
because
now
it's
a
working
group
draft
to
be.
We
want
some
reviews
and
yeah.
We
will
appreciate
if,
if
you
send
us
comments
on
this
draft.
A
A
D
A
If
nothing
else
bring
open
technical
issues
to
the
meeting
the
meet
the
meeting
in
chicago
I
think
we
basically
decided
that
this
dress
going
to
need
to
meeting
cycles
arm
that
were
probably
not
going
to
be
done
with
it
until
the
August
meet
until
the
second
meeting
next
year.
I'm
looking
one
of
the
ad,
she
probably
knows
where
it
is
because
I
because
I
don't
remember
what
we're
going
after
Chicago.
A
A
We
know
we're
noticing
the
usual
suspects
are
okay.
Thank
you
very
much.
Thank
you!
Okay,
Randy!
Well,
you
need
these
have
just
one
to
expand
experiment
for
us.
You
all
three
of
you
have
proven.
The
ten
minutes
is
insufficient
time
between
meetings
Spencer.
You
can
please
take
this
back.
The
IES
geez
a
end
a
week,
wrap-up
meeting
and
Randy
you're
up
next,
let
me
go
Greg
good
good!
Get
your
slides
and
while
Randy's
kind
of
here
I
need
to
announce
a
correction,
something
happened
yesterday.
A
A
Please
read
this
because
this
lower
effort
service,
also
known
as
scavenger
or
less
than
best
effort,
is
becoming
something
that
people
increasingly
like
to
see
and
diffserv,
and
that
draft
is
going
to
be
the
vehicle
for
actually
specifying
it
in
a
fashion
that
we
think
we
can
use.
So
I
apologize
for
goofing
that,
but
the
good
news
is,
I
have
one
less
adoption
called
run
on
the
list:
okay,
Randy,
and
that
would
luck
that
remote
works.
Okay,.
E
A
We
probably
will,
because
this
draft
has
the
dubious
honor
of
being
the
last
gbg
draft
in
the
in
the
web,
RTC
hairball
or
tar
ball
or
whatever
you
call
it.
I
would
not
like
to
be
last
draft
standing
in
that
one,
so
we
will
probably
last
call
it
to
in
the
NFL
in
your
future
with
the
goal
getting
that
out
of
here
and
getting
out
of
the
way
of
what
it
was
going
to
happen.
Web
RTC
as
far
as
implementation
status,
we
have
there's
a
simulation.
E
E
That's
always
a
good
idea.
Next
draft
is
the
NAT
support.
This
has
been
around
for
a
long
time.
There
haven't
been
any
changes
since
the
last
IETF
there's
a
it
sounds
like
Michael
has
AV
box
implementation.
You
started,
there
is
actually
a
previous
implementation.
In
previous
d
of
this,
of
a
past
version
of
this
draft,
that's
been
out
in
the
firewall
/
nat
of
previously
for
quite
a
while
on
the
menus
of
updates.
I'm
not
sure
there
are
still
some
things
to
do.
E
I
think
this,
this
draft
split
and
merged
and
merged
and
split
and
in
the
process
some
of
the
text
need
to
be
shuffled
around
so
that
you
have
NAT
implementation
points
and
endpoint
implementation
points
all
in
correct
places
and
of
course
there
are
some
issues
with
covering
the
ipv4
26
and
vice
versa,
translation.
But
there
are
all
things
to
do:
okay,.
A
And
this
one
we're
hoping
we
talked
about
Skye's
schedule
yesterday,
hoping
that
this
will
move
with
an
index
meeting
cycle
will
be
looking
at
wittenberg
last
call
resolved
in
chicago
in
in
chicago
and
but
will
have
no
word.
Okay,
I
need
to
ask
a
tangentially
related
question:
there
is
a
carrier-grade
NAT
yang
draft.
Looking
for
a
home,
raise
your
hand
if
you're
familiar
with
how
Nats
work
keep
it
up.
If
you
think
you
understand
carrier-grade
Nats,
all
right,
we
aren't
completely
clueless,
but
Spencer
I
think
you
have
some
useful
information.
E
A
E
A
At
the
Prague
yeah,
that's
none
of
that
sounds.
It
sounds
like
sounds
like
a
reasonable
time
and
there's
enough
changes
here
that
it
really
should
be
abyss,
as
opposed
to
and
on
an
update
correction
stock.
Yes,
okay,
how
important
is
what's
being
done
here
to
web
RTC?
He
says
not
shirring,
not
being
sure
he
wants
to
know
the
answer.
Well,.
B
E
A
B
A
A
So
Joe's
been
working
on
this
raft
for
a
while
I
believe
it's
been
presented
here
in
in
TS
VW
g
in
the
past.
This
is
about
a
option
space
for
UDP
and
it's
being
done
by
taking
advantage
of
the
fact
in
a
UDP
packet.
There
are
two
links
which
currently
supposed
to
match,
namely
the
IP
UDP
length
of
both
suppose
describe
the
same
package.
A
Interesting
idea
of
hiding
you
to
be
optioned
down
there,
that'll
make
you
DP
behave
like
UDP
light,
but
use
the
UDP
port.
That's
been
them.
Sorry
use
the
UDP
protocol
number.
That's
been
a
major
obstacle
to
UDP
light
deployment
that
does
not
use
the
same
protocol
number
as
up
as
UDP
he's
got
some
implementation
code
and
there's
a
request
for
the
working
group
to
pick
this
up
as
a
as
a
draft
I'm
a
little
cautious
about
this
one.
How
many
people
have
read
this
draft
or
read
a
read,
read
the
03
version
ago.
A
F
A
G
A
Speaking
as
an
individual
with
scars
from
UDP
encapsulation
and
check
some
nonsense,
if
this
provides
a
better
solution
to
people
who
don't
like
the
UDP,
you
p
checksum,
because
it's
not
a
trailer
but
would
like
to
be
able
to
actually
check
some
a
few
things
that
they
care
about.
Like
oh
say,
the
port
numbers
in
the
UDP
header
and
use
the
UDP
protocol
number
as
individual.
This
could
be
quite
useful.
A
H
Just
check
walking
over
hello,
hello,
everybody,
so
I'm,
Vincent
and
I
will
introduce
you.
The
update
of
this
document
I
already
presented
that
Berlin
meeting.
So
this
is
factoring
version
2
and
the
goal
is
to
add
support
for
congressional
ethics
codes
to
this
fact
framework
just
to
show
just
to
to
to
point
out
the
fact
that
we
didn't
try
to
patent
anything
this
document-
okay.
So
this
is
a
reminder
of
effect
frame
and
what
were
posing
very
compact
manga.
H
So
this
is
a
follow-up
of
ofc
6363
that
was
published
in
2011
by
myself,
Aly
and
Mark.
Watson
fact
frame
is
in
fact
morishim
layer
than
a
protocol,
which
means
that
it
fits
between
RP
and
UDP
most
of
the
time,
and
the
goal
is
to
enable
robust
and
scalable
communications
of
contents
and
particularly
real-time
contents.
So
we
assume
that
there
are
many
people
interested
by
same
content
at
the
same
time,
which
makes
it
meaningful
to
use
multicast
and
broadcast
communications.
That's
the
goal
of
this
fact
frame.
H
It's
already
included
in
3,
PP
mbms,
so
multi
multi,
media
broadcast
and
multicast
services,
and
we
start
to
have
some
deployment
experience.
The
issue
is
that
fake
frame
requires
that
you
are
using
a
block
FEC
codes,
which
turns
out
to
be
a
little
bit
inefficient
in
terms
of
latency.
It
adds
significant
latency
to
all
the
participants
all
the
time,
and
this
issue
can
be
really
solved
totally
solved
almost
by
using
conversion
alleged
codes
that
works
differently
in
very
good
reception
conditions.
H
Receiver
will
not
experience
any
latency
from
this
point
of
view
when
I
mean
when
I
say
in
Latin,
see
I
mean
fake,
related
latency.
Of
course.
That
has
nothing
to
do
with
the
communication
latency,
which
is
a
different
problem,
but
no
latency
from
the
fake
point
of
view
and
in
bad
reception
conditions,
you
still
have
a
very
slow,
smaller
latency
compared
to
that
of
block
codes.
So
the
goal
of
fake
friend
version
2,
is
just
to
add
conversion
called
support
to
this
specification.
H
The
difference
is
with
the
previous
version
that
I
presented
bearing
out
the
following.
We
had
an
implementation
status
section
as
suggested
by
ifc
679
32,
so
just
do
to
tell
you
what's
going
on
from
this
point
of
view,
we
already
have
a
implementation
of
fake
frame
version
1.
So,
which
is
commercial
for
which
we
start
to
have
some
interoperability
experience
and
deployments,
and
I
am
in
the
currently
implementing
fake
friend
version
24
based
on
these
existing
source
code.
So
that's
it.
Then
we
also
added
an
additional
section
at
the
end
of
the
document.
H
That
explains
what
are
the
differences
between
this
version
and
the
ifc
6363
and
which
fix
for
fewer
mistakes
in
the
document,
but
nothing
very
important
I
would
not
like
to
go
into
details,
but
just
highlight
one
point,
so
we
also
make
progress
in
terms
of
blog
vs.
congressional
English
evaluation.
H
What
are
the
performance
you
can
expect,
and
it's
this?
The
message
is
that,
honestly
speaking,
I
don't
understand
why
this
work
has
not
been
done
before,
because
I
really
really
a
big
improvement
in
terms
of
latency
by
using
a
conversion
factor
cut.
It
really
makes
sense
to
do
that.
So
you
have
the
details
in
this
paper.
That
is
a
reference
at
the
bottom
of
this
slide.
If
ever
you
want
to
can
discuss
this
off
time
offline.
H
Sorry,
whenever
you
want
there's
no
problem,
then
I
have
a
question
for
this
group,
and
I
would
like
to
get
your
feedback
on
these
points.
The
question
is
the
following:
should
we
continue
calling
this
version
2
or
should
we
just
say
well,
this
is
not
date
of
FC
6363.
That
would
be
absolutely
so.
Some
background
information
to
make
you
so
that
you
understand
the
situation
in
this
version.
We
do
not
remove
anything.
You
just
have
one
additional
capability
being
able
to
use
convolutional
codes.
That's
the
first
point.
H
The
second
point
is
that
we
do
not
change
anything
in
the
way
a
receiver
can
design
to
join
or
not
to
join
the
session.
The
receiver
just
has
to
retrieve
the
SDP
session
description
file
and
I've
a
look
at
it
have
a
look
at
the
effect
and
Connie
ID
that
identify
the
feck
scheme,
and
if
this
is
a
fake
skin,
that
does
not
support
that
this
receiver
does
not
support.
Then
you
just
have
to
say
or
no
I
don't
want.
I
cannot
and
then
you
choose
an
association,
for
instance.
H
This
is
exactly
the
same
mechanism,
regardless
of
whether
you
are
using
black
cards
or
convolutional
codes.
No
change
from
this
point
of
view,
I,
so
fat
point.
This
is
probably
the
most
important
one.
There
is
no
version
number.
In
fact,
friend.
Vikram
in
fact,
is
not
really
a
protocol,
as
I
said
smashing
layer,
there
is
no
effect
frame
either
Percy,
there
are
leaders
and
trailers,
but
those
are
related
to
the
effect
schemes
and
not
affect
frame.
So
I
think
it
is
an
important
point.
H
The
only
benefit
I
see
in
having
this
version
two
is
that
okay,
it
makes
it
clear
that
we
to
support
additional
effects
schemes
from
the
implementation
point
view
it
also.
I
liked
the
fact
that
okay,
this
is
something
different.
In
fact,
when
you
try
to
implement
both
Russian
one
version
to
you
will
see
that
there's
a
big
difference
in
implementing
conversion
cut
support,
I'm,
not
speaking
about
the
fact
scheme
itself,
which
is
something
different,
but
just
the
way
you
have
to
manage
packets.
H
A
H
Change
all
the
mentions
that
were
very
specific
to
block
codes,
so,
for
instance,
if
in
ifc
63
63
text
mentions
that
okay,
we
accumulate
a
certain
number
of
sauce
packets
and
then
we
create
a
blood
guts.
And
then
you
do
a
fishy
encoding
make
it
simple.
Then
we
change
that
into
the
following
way.
So
we
say
that
in
case
of
block
codes,
then
we
accumulated
rather
blah
the
same
text
but
in
case
of
convolutional
codes.
Then
we
do
something
else.
H
A
H
Yes,
we
do
not
remove
anything,
so
the
if
you
use
a
fake
friend
version
2
in
the
traditional
way
with
blood
codes,
it
won't
make
any
change
to
the
receiver.
They
won't
notice
anything
that
does
absolutely
nothing
new
yeah,
but
you
have
this
capability
of
using
something
else
of
using
different
obstacles
and
in
fact
a
fact
frame
is
agnostic
is
more
less
agnostic.
With
respect
to
the
block
to
the
cuts
you
are
using,
we
are
so
so
far
in
I
c63,
you
can
use.
H
A
This
list
this
sounds
like
an
extension
updates.
I
think
what
you
just
said
is
that
if
I
take
a
version
to
sender
and
try
to
interoperate
with
a
version
1
6363
receiver,
the
receiver
see
is
a
bunch
of
codes
advertised
somebody
support
and
so
much
it
simply
doesn't
recognize
and
picks.
One
picks.
One
that
supports
everybody
falls
falls,
falls
back
to
using
one
of
the
block
codes.
A
Should
look
at
on
the
list
but
base
what
you've
described,
what
I?
What
I
think
I'm
hearing
sounds
like
an
extension
to
63
63
and
oh
by
the
way,
there's
some
language
in
there
that
didn't
anticipate
convolution
codes.
That
requires
some
what
are
effectively
editorial
substitutions
to
avoid
saying
things
that
aren't
true
about
convolution
codes.
Okay,.
H
B
A
In
the
setup-
oh
sorry,
I,
don't
get.
Okay
sender
sends
the
setup
code
info
to
the
receiver
and
says
hi
I
want
to
speak
version
2,
and
here
the
codes
I
support,
but
lists
only
the
block
codes
in
63
63,
there's
a
ver
to
tag
have
any
effect
on
the
receivers.
Behavior,
no,
absolutely
no
effect.
Okay,
then
that
I'm
pretty
sure
you've
got
an
extension.
A
H
H
Hey
go:
hey,
okay,
so
next
step!
Well,
I!
Don't
expect
any
measure
change
in
these
documents,
anymore,
I
think
it's
now
quite
stable.
My
first
to
do
it
on
is
to
finish
this
implementation
of
way
that
will
be
done
for
next
IDF
and
just
want
to
be
sure
that
we
don't
miss
anything
important
but
well.
I've
already
implemented
the
center
side.
Now
I
have
to
finalize
the
receiver
side.
I
think
I'm,
okay,
but
I
would
be
more
confident
when
it's
working
very
well.
That's
my
first
point
and
second
point.
H
So
it
makes
no
sense
to
have
a
flag
framework.
If
we
don't
have
an
effect
scheme
to
put
in
it,
I
mean
conversion
effects
Kim.
So
what
I'm
proposing
here
is
to
specify
this
very
basic
conversion.
Facts,
Kim,
called
I'll
see
randomly
not
codes.
It's
pretty
simple
to
explain.
I
can
explain
to
you
in
two
minutes.
You
will
understand,
there's
nothing
complex
in
it,
and
so
we
have
to
specify
the
code
details,
but
it's
not
big
deal
the
signaling
aspects.
While
we
already
implemented
it
so
I
guess
it
will
be.
H
Okay,
like
that's,
always
also
have
some
expansion.
From
this
point
of
view,
and
then
we
have
to
ask
for
inr
expression
for
the
effect
the
new
freakin
kuniaki.
Oh
that's
anyway.
This
is
the
way
we
I
want.
Penetration
works
for
the
moment.
It's
a
basic
solution,
basic
scheme,
that,
while
using
a
lump
image,
that's
it
okay.
A
Sounds
from
process
standpoint,
what
would
you
like
the
working
group
to
do
when
and
I'll
give
you
a
strong
man?
Go
go,
go,
go
I'll,
give
you
a
straw
person
proposal.
We
can
think
we
can
start
from
there,
which
is
it
sounds
like
you've,
gots
implantation
work
to
do
and
you
need.
You
need
to
write
up
the
to
do
two
on
this
slide.
A
H
H
F
F
You
know
more
specialized
things,
because
if
the
authors
also
implement
the
code,
it's
it's
great
that
you're
doing
this,
but
and
it's
better
than
not
doing
it,
but
it
would
be
even
better
if
somebody
else
would
read
the
document
and
try
to
implement
it
in
there
right
shall
shine,
because
otherwise,
if
you
have
you
guys,
are
the
only
people
implementing
it.
Why
do
we
need
a
standard
and.
H
A
H
A
H
A
I
would
couple
suggestions.
One
is
the
buttonholes
people
on
the
hall
to
read
the
draft.
The
second
is,
if
this
turns
into
an
update,
you
don't
need
to
reproduce
all
the
6363
text.
You
need
to
write
the
text
on
new
convolution
codes
and
then
explain
what
chain
what
has
to
change
in
63
63
to
allow
them.
You
don't
have
to
you,
don't
have
to
completely
replace
60
36,
all
the
texts,
6363
and
obsolete
it.
Yes,
so
what
will
happen
is
when
you've
done.
A
H
A
It's
probably
a
good
starting
point.
In
essence,
the
difference
is
opposed
to
writing
a
63
63
bits
that
completely
replaces
that
RFC
you
right
what
is
what
is,
in
effect
a
companion
document
that
is
red
with
63
63,
to
tell
you
how
to
start
to
q3
63
and
get
convolution
codes
in
addition
to
block
codes,
okay-
and
I
just
had
structure
among
other
things,
it's
likely
the
result
in
a
much
shorter
draft.
Maybe
we
can
get
more
people
to
read
it.
Okay,
thank
you.
Okay,.