►
From YouTube: IETF102-RMCAT-20180720-0930
Description
RMCAT meeting session at IETF102
2018/07/20 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
A
A
A
A
A
A
The
draft
up
is
now
in
a
VT
core,
and
then
we
want
to
briefly
discuss
some
points
for
how
to
move
forward.
We
have
a
framework
document
that
we
need
to
discuss
a
little
bit
if
we
want
to
progress
that
at
this
point
and
there's
also
been
some
discussion
about
the
possible
hackathon,
so
we
wanted
to
catch
it
interest
in
that.
A
A
We
have
the
couple
congestion
control
draft
that
is
already
in
RFC
editor
queue,
it's
waiting
for
the
NADA
draft,
so
we
expect
to
get
both
of
those
drafts
out
quite
soon,
and
then
we
have
an
expired
draft
on
the
GCC
congestion
control
room.
The
shares
have
had
some
discussion
with
the
authors
there
and
they
are
not
planning
to
pursue
that
draft
further
at
this
moment.
So
once
we
get
the
NADA
draft
through,
we
will
be
done
with
this
round
of
documents
for
algorithms
coming
out
of
the
working
group
as
experimental
algorithms.
In
the
first
step.
A
We
have
a
requirements
draft,
that's
in
the
RFC
edit
CQ,
since
a
very
long
time
waiting
for
some
web
RTC
documents,
and
then
we
have
the
evaluation
drafts.
So
we
have
three
of
these
drafts
that
are
in
the
working
group
last
call
the
adult
has
draft
the
eval
criteria
and
the
video
traffic
models
and
we,
according
to
the
original
schedule.
This
working
group
last
called
closed
today,
but
we
really
need
some
more
reviews
of
these
drafts
to
take
them
forward.
So
we've
had
the
two
reviews
on
the
video
traffic
model
and
this
one.
A
A
C
So
the
test
specification
and
the
criteria
were
on
hold
for
quite
a
while,
and
there
were
like
concept
reviews
at
the
very
beginning
right
so
I,
don't
think
a
lot.
A
A
D
Yes,
okay
for
the
even
test
I
got
an
individual
review
from
Colin
I
addressed
it,
but
I'm
waiting
for
more
reviews
so
that
I
can
ship
out
one
single
change
that
that
actually
covers
most
of
the
reduce
the
evil
evil
test
and
about
you
will
catch
it
up
at
recently.
Some
changes
but
evil
test
I,
don't
think
like
we
have
changed
anything
since
thirty
years,
so
yeah
just
have
it.
If
you
just
tell
us
like
what
do
you
think
about
it,
yeah.
A
Okay,
any
more
people
that
can
already
this
meeting
commit
to
having
a
look
at
the
draft
and
seeing,
if
you're,
all
okay
with
them.
We
will
also
take
it
to
the
list,
of
course,
to
remind
everyone,
but
we
have,
as
mayor
said,
these
draft
have
been
debated
before
and
they
have
been
used
by
the
candidate
algorithm,
so
I
think
they
should
be
in
in
good
shape
when
you
read
them.
A
Okay,
we
will
also
take
it
to
the
list
to
remind
people
that
we
do
need
some
reviews.
So
please
help
out
with
that.
It's
possible.
We
have
one
last
draft
that
belongs
to
the
evaluation
draft
Wireless
tests
drafts,
so
shouting
and
her
colleagues
have
been
working
also
on
integrating
this
into
the
industry
code.
So
this
was
why
this
had
been
not
cold
out.
At
the
same
time
now
I
think
they
are
still
working
on
that
and
there
were
some
industry
problems.
So
it's
not
clear
how
fast
this
will
be.
A
We
finished,
so
our
plan
is
to
have
this
draft
also
go
to
work
in
group
last
call
as
soon
as
we
complete
the
other
three
drafts,
so
it
doesn't
make
sense
to
send
another
draft
working
group
last
call.
While
we
are
waiting
to
get
some
feedback
on
the
other
three,
but
that
draft
is
also
ready
to
proceed
with
the
process
as
soon
as
we
can
move
the
other
three
documents
on.
So
that
is
the
plan
for
that.
A
Then
we
have
the
RTP
CC
feedback
draft,
which
is
connected
to
the
ABT
core
draft
and
colin
has
updated
the
calculations
for
that
draft
to
the
latest
version
of
the
feedback
message
draft
and
we
have
the
feedback
message
draft
on
the
yam
McCauley
will
give
an
update
on
that.
Then
we've
had
some
drafts
on
the
interfaces,
CC
codec
interaction
and
what
is
still
an
individual
draft
on
the
framework,
and
we
will
return
to
that
point
and
discuss
what
to
do
with
these
documents.
At
the
end
of
the
agenda,
we
have
a
number
of
milestones.
A
A
F
Okay,
hi
I'm
a
slightly
louder
version
of
confidence,
so
I'm
hits
talk
about
the
rtcp
feedback
for
congestion
control.
This
was
presented
in
a
bt
cora
earlier
this
week,
so
mostly
this
is
going
to
be
a
repeat
of
that
discussion.
That's
how
people
working
people
happy,
and
so
we
submitted
these
your
a2
version
of
this
draft
just
before
the
meet
so
just
before
the
meeting
actually
on
Sunday.
So
it's
are
really
just
before
the
meeting,
mostly
to
address
feedback.
F
The
changes
were
mostly
relating
to
the
timing
and
sequence
numbers
resynchronizing
after
loss
reports
and
fixing
up
the
STP
signaling
and
as
I
say,
we
took
out
this
in
a
boutique
or
earlier
in
the
week,
so
the
the
only
real
technical
change,
the
only
significant
technical
change
in
this
version
of
the
draft
we've
clarified
that
the
ntp
format
timestamp
matches
that
in
sr
packets,
rather
than
saying
it
matches
that
in
SR
or
RR
packets.
F
In
addition,
both
of
these
changes
lets
us
signal
no
packets
received
as
part
of
this
reports.
You
could
always
infer
that
from
looking
at
the
sender
reports
or
the
receiver
reports
coming
back,
but
having
it
all
in
a
single
block.
If
you
makes
the
implementations
a
little
simplex,
you
don't
have
to
jump
between
us,
so
those
are
benefiting
okay
there
as
well.
F
The
previous
versions
of
the
draft
had
some
discussion
about
what
to
do
with
large
gaps
in
the
sequence
number
space
as
a
crude
sort
of
in
window
checks
to
make
sure
the
reports
were
valid.
We've
added
some
words
in
this
version
that
says,
if
you
have
actually
had
a
very
long
outage,
and
you
get
one
of
these-
your
thoughts
such
that
the
sequence
number
of
jumped
by
more
than
a
quarter
of
the
sequence
number
space.
F
You
should
probably
consider
it
valid,
because
if
it
has
actually
been
long
enough
that
the
source
I
can
tell
if
it
was,
of
course,
if
you're
using
SRTP,
these
would
be
authenticated
anyway.
So
you
can
check
that
they're
valid.
For
that
reason,
we
also
added
a
note
again
to
do
with
this.
In
window
checks
that
you
must
not
put
more
than
16384,
thank
you
metric
blocks
in
one
of
these
reports.
Now
that
wasn't
actually
possible
in
UDP
because
of
the
MTU
considerations,
but
I
guess
it's
good
to
clarify
it.
F
Finally,
we
have
a
technical
change:
we've
updated
the
ionic
considerations
mostly
to
register
the
appropriate
SDP
parameter
signals
there's
a
mechanism
in
RFC
for
five,
eight
five,
which
is
the
the
feedback
form
at
this
extent,
which
allows
you
to
do
the
signalling
we've
just
registered
a
CC
FB
tag,
there's
no
escape
eh,
oh,
so
that's!
Basically
it
the
planet
is
that
we
will
submit
the
zerotree
version
very
quickly
and
change
the
PN
sequence
number,
plus
once
the
length,
which
will
hopefully
be
the
final
change
to
the
packet
format
and
add
some
more
discussion
of
why.
F
We
believe
this
is
the
right
format
to
use
and
some
comparison
with
the
draft
homer
feedback
mechanism,
which
I
believe
is
what
sees
in
implemented
in
Chrome,
currently
to
explain
why.
We
think
this
is
the
right
approach.
I
think
it
has
benefits
partly
just
future
proofing,
because
it
fits
@
c,
@,
CP
and
better,
partly
because
it
allows
you
to
do
separate
congestion
control
of
the
different
SSR
seats.
F
So
if
we
start
sending
multiple
video
streams,
that
gives
you
the
information
to
control
each
one
separately,
if
one
doesn't
in
due
to
the
way
uses
a
single
sequence
number
space,
so
that
is
basically
it
if
there
any
comments
happy
to
to
take
them
into
account.
If
not,
they
say
we,
let's
get
this
finished
in
Febby
sorter.
G
Got
a
clinic
just
thinking
about
this
briefly,
it
occurred
to
me
that
you
know
packets
receipt,
given
that
we
now
have
a
way
of
say
no
packets
received.
There
should
probably
be
guidance
as
to
when
you
can
send
no
back
perceive,
as
opposed
to
just
spamming,
about
every
SSS.
If
you've
ever
heard
of
saying,
hey
I
haven't
you
know,
this
I
haven't
heard
me
thinking
this
receiver
in
three
hours
still.
F
G
F
I
F
I
Maybe
those
those
bits
might
be
useful
in
the
in
the
future.
You
never
know
and
also
to
say
that
so
as
soon
as
you
upload
the
new
version
of
it,
we
will
modify
or
our
source
code
to
all
reflect
the
changes.
I'm
gonna
place
the
thing
we
have
mentioned
it
in
previous
meetings,
but
I'm
gonna
paste
the
the
URL
to
the
source
code
in
case
anybody's
interested
look
into
it.
I'm
gonna
put
in
little
chat.
F
A
Okay,
so
we
wanted
to
have
a
few
points
discussed
for
how
to
move
forward.
So
we've
had
the
framework
document
we
had
in
the
past
the
CC
codec
interaction,
and
then
we
decided
at
one
point
that
it
would
be
good
to
tie
these
things
together
and
have
the
framework
for
the
congestion
controls,
the
components
that
are
there.
The
interactions
and
we
have
an
individual
draft
for
that
that
size
and
Xiao
Jing
worked
on
some
time
ago
at
ITF
99.
A
So
it
depends
also
on
the
energy
we
have
in
the
working
group
to
work
on
these
documents
at
this
time.
If
you
see
it's
useful
and
if
you
see
your
algorithms
progressing-
and
you
would
be
helped
by
having
this
this
document
to
align
the
algorithms
in
the
next
step,
so
we
like
to
hear
some
some
feedback
on
this.
A
D
As
you
have
been
looking
into
the
energy
of
the
work,
you
look
like
the
work.
New
lustful
reviews
is
getting
hard
to
get
some
reviews
and
stuff
like
that
when,
when
Anna
reminded
us
that
we
have
an
action
point
on
us
and
we
actually
me
and
were
in
last
last
high
tech
meeting,
we
said
like
we'll
we'll
work
on
it,
but
nothing
happened.
So
it
also
tells
the
story
of
the
authors.
We
are
not
getting
the
energy
behind
from
the
working
group
to
drive
this
work.
D
Basically,
so
if
we
take
an
example
on
the
framework,
the
company,
it
has
a
lot
of
interactions,
it
has
interests
on
the
transport,
it
interaction
to
the
different
modules
like
correct
and
stuff,
like
that.
That
means
a
wider
range
of
review
to
get
it
right
and
I
agree
on
like
this
is
because
the
framework
document
can
describe
different
things
and
a
different
way.
So
my
thinking
my
question
was
basically
two
chairs
like
do
we
have
the
working
group
energy
to
which
actually
work
on
this
frame?
D
I'd
recommend
get
it
through
so
that
it
makes
is
full
I
do
see
benefit
of
having
this
working
group
working
on
this
framework
document,
because
this
will
help
in
the
future,
especially
when
you
go
to
a
starter
Krakov.
If
somebody
new
come,
the
new
working
algorithm
comes
in
two
armed
cat,
that
will
be
very
helpful.
It
will
align
the
terminology
it
in
a
line
how
this
interaction
happens
and
also
I
think
it
helps
actually
to
understand
all
the
existing
algorithms
we
have
and
so
I
see
the
benefit.
D
C
Meuk
11,
so
one
of
the
important
points
about
the
framework
document
was
also
about
terminology,
because
we
could
have
been
trying
to
understand
where
the
difference
between
the
different
schemes
are
and
we're
like
similarities
are
and
we're
trying
to
use
the
same
wording.
I
don't
like
this.
Only
like
some
of
the
words
have
are
now
the
same.
C
Even
if
we
just
decide
we
want
to
go
for
with
one
of
the
schemes
to
propose
then
that
it's
probably
not
needed
so
I
guess
we
could
try
and
just
like
we,
we
live
the
trimeric
document
at
the
point,
we're
ready
to
move
on
was
to
propose
standard
together
with
the
schemes.
At
that
point
it
can
and
not
do
anything
work
on
it
right
now.
Yeah.
B
So
I'm
the
author
for
the
framework
draft
I
just
want
to
also
mention
that,
and
we
also
have
the
corresponding
implementation
in
industry
to
reflect
Stephen
kind
of
the
model
in
congestion
control
and
one
one.
Maybe
one
suggestion
is
as
I
understand.
This
describes
the
interaction
of
the
congestion
control
modular
with
respect
to
other
modulars
in
the
sender.
B
Do
we
want
to
get
feedback
from
none
kind
of
the
broader
or
maybe
transport
good
sort
of
yet
outside
of
this
working
group
and
I
agree
with
the
suggestions
so
far
that
the
main
goal
of
this
framework
is
to
align
terminology
across
multiple
candidates
schemes
within
the
same
model,
sort
of
multiple
embodiments
of
the
same
model.
That's
my
understanding,
yeah.
Thank
you.
A
So
we
clearly
should
have
a
wider
review
and
input
on
this
document
when
we
take
it
forward,
so
I
guess
the
question
is:
maybe
that
part
we'll
also
car
I
mean
if
we
now
see
that
we
don't
have
the
energy
at
this
time
and
we
don't
really
need
the
document
until
we
get
to
this
point
of
where
we
will
drive
the
algorithms
to
standardization.
Maybe
that
will
also
be
the
time
to
approach
the
broader
transport
area
to
get
get
feedback.
B
A
A
Okay,
good,
then
we
had
one
other
issue
that
was
up
brought
up
briefly
in
the
last
meeting
as
a
suggestion,
and
that
was
if
it
would
be
useful
to
have
a
hackathon
their
own
around
the
common
feedback
format.
We
didn't
really
follow
up
in
time
on
that
and
pursue
that
for
this
meeting.
So
we
now
wanted
to
see
with
the
working
group
if
there
is
interest
in
this
for
the
next
time.
So
if
you
have
the
implementations
that
could
try
this
out
or
we
would
like
to
help
work
on
this.
A
D
Yeah
I
think
that's
a
good
idea.
Actually,
the
thing
is
like
then
also
you
know
like
some
people
has
a
petition
of
it.
I
think
Sergey
has
some
implementation.
D
Maybe
we
can
think
about
putting
this
at
the
part
of
the
screen
out
open
source.
Think
I
will
have
to
look
into
the
practicalities
of
that
internally,
but
yeah
I
think
there's
a
valid
assumption
like
we
can
go
for,
though
this
one
for
open
source
and
implemented
arm
and
also
screams
feedback,
because
it's
pin
currently
doesn't
use
yeah.
D
I
I
We
didn't
come
up
with
anything
to
this
meeting,
because
you
know
we
don't
have
basically
anything
to
present,
but
in
principle
we
we
might
be
able
to
send
something
to
the
mailing
list
short
about
the
habitant.
Well,
I,
don't
know
if
we
can
participate
remotely
I
personally,
not
sure
what
I'll
get
the
funding
to
get
Wonka.
But
if
it's
you
know,
if
we
can
participate
remotely
I
would
be
very
happy
to
do
ya
participate.
I.
D
F
I
A
G
I
I
mean
I,
haven't
done,
I
have
we
mentioned
it
in
the
boutique
workgroup
I
didn't
get
any
specific
responses,
I
mean
I'm
personally
I
might
be
able
to
participate,
but
that's
enough
episode.
You
know
that's
not
as
a
chair,
that's
as
a
individual,
but
I
didn't
I
didn't
get
it,
but
I
suspect
that
probably
everybody
who'd
be
interested
is
also
here.
So.
G
A
If
not
we're
at
the
end
of
the
agenda,
so
we
have
a
short
meeting
today.
So
thank
you
all
for
coming
and
see
you
in
Bangkok,
so
I
guess.
We
will
also
probably
have
a
short
meeting
there
to
follow
up
on
the
on
the
feedback
and
then
maybe
on
the
hackathon
and
the
status
and,
of
course,
we're
always
interested
if
you
start
to
get
some
results
or
experiences
with
the
algorithms
and
then
let
us
know,
and
we
will
of
course
put
that
up
there.