►
From YouTube: IETF104-RMCAT-20190325-1120
Description
RMCAT meeting session at IETF104
2019/03/25 1120
https://datatracker.ietf.org/meeting/104/proceedings/
A
B
B
B
B
B
So
we
have
a
fairly
short
agenda
today,
so
we're
going
to
go
over
the
status
of
the
working
group
and
the
different
documents.
Jonathan
has
promised
to
give
a
short
update
on
the
hackathon
that
was
during
the
weekend
and
Colleen
is
gonna
talk
about
the
RTC,
the
feedback
work
that
is
now
driven
in
abt
core.
B
So,
let's
start
with
overview
of
our
working
group
documents.
So
we
are
finishing
up
our
algorithm
document,
so
we
already
have
the
screamin
SPD
that
has
been
published.
Naida
is
ready.
Martinus
writing
this
up.
He
was
gonna
submit
it
before
today,
but
he
got
sick,
so
I
hope
we
will
get
this
submitted
very
shortly
and
otherwise
your
column
will
have
to
help
on
this
one
and
of
course
the
GCC
draft
is
dormant
and
we
don't
really
expect
any
updates
on
that.
B
So
the
algorithm
draft
that
has
had
some
activities
since
the
last
meeting
is
the
coupled
CC
draft.
So
this
draft
was
finished
quite
some
time
ago,
but
it
has
been
waiting
in
the
editor
queue
for
the
norther
draft
because
of
the
normative
reference.
So,
in
the
meantime,
there
was
experimentation
with
this
draft
and
there
was
a
corner
case
detected
that
in
some
instances,
all
the
bandwidth
was
not
fully
used.
So
this
was
detected
by
julius
in
doing
some
of
the
measurements
and
experiments
with
the
draft,
and
this
was
also
presented
in
our
last
meeting.
B
So
the
decision
there
was
to
try
and
solve
this
corner
case
before
we
got
the
draft
published
as
an
RFC.
So
as
a
result
of
that,
the
draft
has
been
returned
to
the
working
group
to
solve
this
issue,
and
the
authors
have
also
made
an
update
to
the
draft
that
has
been
sent
on
the
list
for
any
comments.
B
There
were
some
things
that
could
be
a
bit
more
optimized
in
the
presentation,
so
the
shares
are
working
together
with
the
authors
to
use
refine
and
have
a
bit
more
compact
and
general
description
of
the
the
solution
that
was
in
the
draft.
So
as
soon
as
we
finish
up
that
part,
which
should
be
very
soon,
we
expect
to
then
return
the
draft.
It
first
needs
to
go
to
our
aid
for
approval
and
then,
if
we
have
understood
the
process
correctly,
we
can
return
the
draft
directly
into
the
RFC
editors
q.
C
D
B
C
No
change
anymore,
so
maybe
just
like
officially
running
the
last
call
again
and
then
I
can
also
put
it
as
a
returning
write
and
when
the
I
use
gender
I
mean
it
shouldn't,
it
doesn't
really
doesn't
have
any
implications
for
you
just
to
follow
the
process
correctly.
I
think
it's
the
right
thing
to
do.
Okay,.
B
Yes
sure
the
process
was
not
fully
clear
to
us
or,
but
if,
if
you
prepare,
we
can
run
a
formal
working
group
last
call
when
we
done
put
and
I
think
we
used
to
do
that
on
the
new
version,
because
we
have
a
new
version
that
has
been
based
on
the
discussions
between
the
shares
and
the
waters
to
refine
the
presentation.
Okay,
Thank
You
Miriam.
So
we
will
do
that,
but
still
I
think
this
will
be
solved
and
finished
up
very
soon.
B
Then
we
have
the
requirements
and
the
valuation
draft
requirements
still
waiting
in
the
editor
queue
has
been
there
for
quite
some
time.
We
now
also
have
the
video
traffic
model
draft
finished,
so
that
is
now
in
the
RFC
editor
skew.
The
valtor's
draft
has
also
been
submitted
to
the
eye
gee
and
the
waters
are
working
to
solve
that.
The
last
comments
that
are
coming
through
that
review
so
I
think
that
this
draft
will
also
very
soon
be
passed
on
to
the
RFC
editor.
Then
we
have
the
eval
criteria
draft.
This
draft
is
basically
also
done.
B
It's
passed,
the
working
group
last
call,
but
we
are
waiting
for
the
authors
to
make
the
final
update
so
I
think
it's
the
security
section.
That
needs
a
little
bit
of
a
work
still
and
then
this
draft
will
be
submitted
to
the
IEC,
and
then
we
have
the
orange
at
the
wireless
test
draft.
This
draft
is
also
passed.
The
working
group
last
call
and
we're
waiting
for
an
author
update
to
take
care
of
the
comments
that
came
up
during
the
working
group.
Last
call
there
were
not
so
many,
but
there
were
with
you.
B
Then
we
have
the
work
related
to
the
feedback,
so
here
the
the
draft
on
the
feedback
message
is
now
with
a
BT
core
and
it's
also
a
larger
agenda.
That
column
will
give
the
working
group
an
update
on
what
how
this
draft
is
progressing
there
and
the
work
that
has
been
done,
and
then
we
have
the
RT
PCC
feedback
draft
that
is
Oran
kept
draft
and
that
will
be
updated
once
the
feedback
message
draft
is
completed
to
reflect
the
the
final
version
of
that
draft.
B
We've
had
some
draft
related
to
interfaces
and
this
is
on
hold
and
will
be
eventually
picked
up
again
when
the
candidate
algorithms
are
progressing
towards
proposed
standards.
If
we
get
there
the
milestones,
we
are
finishing
up
most
of
our
milestones,
so
we
had
the
milestone
in
December
for
the
requirements
and
evaluation
drafts
we
submitted
the
most
of
them,
but
we
have
the
the
two
that
was
just
mentioned.
B
B
E
E
With
him
using
Firefox,
which
and
be
using
our
proprietary
algorithm
successfully
under
operating
I
mean
we
didn't
do
clever,
we
didn't
do
careful
studies
because
it
basically
got
it
working
dishes,
the
hackathon
finished,
but
it
stabilized
at
about
350
kbps,
which,
for
the
VIP
mount
of
video
we
were
sending
and
for
the
link
we
were
using
seemed
pretty
plausible
number.
I
think
he
has
was
feeding.
E
E
You
know
that,
obviously
you
can
you
don't
want
to
lost
feedback
too
cause
I.
Oh
my
god,
there's
terrible
congestion
slam
down,
but
you
also
don't
want
it
to
be.
Oh,
no
I'm,
sure,
everything's,
fine,
I
think
it
possibly
be
wrong.
So
exactly
how
that's
something
that
the
algorithms
need
to
think
about
a
little
bit
another
issue
there
you
ran
into
I
mean
partially
because
of
some
bugs
and
are
working
on
our
interrupt,
but
the
CC
feedback,
unlike
most
our
CP
messages,
isn't
actually
inherently
bounded
in
size.
E
So
we
ran
into
the
issue
that
we
had
CC
set.
When
you
know
one
side
of
the
other
was
getting
its.
That
feedback
interval
badly
wrong.
We
ended
up
blowing
out
the
our
MTU
with
the
feedback
messages.
We
had
a
duplicate
like
2k
or
3k
of
feedback
in
a
single
packet
which
doesn't
work
well,
so,
unfortunately,
that
you
can
break
it.
The
format's
fairly
easy
to
break
out,
but
you
had
to
actually
take
that
into
account
and
and
do
that.
So
that's
that's,
not
normal
behavior!
That's
about
correct!
Oh
I
mean
it's,
it
was.
E
It
was
I
guess,
but
I
mean
it
basically
become,
but
I
mean
I
could
imagine
situations
where
you
have
sufficiently
asymmetric
bandwidths
between
the
two
sides.
Where
you
know
one
side
is
getting
quite
large
bit
rate.
The
other
side
is,
has
very
little
bit
rates
and
so
has
to
have
a
relatively
slow
feedback
interval.
So
I
mean
the
place
is
in
just
a
matter
of
okay.
You
know
when
you
hit
an
empty,
you
stop
putting
this
back
and
put
in
the
next
packet,
but
it
was
a
yeah.
E
E
E
So
that's
something
we
could
potentially
look
at
any
comments
or
surge
or
senior
here
does
anything
else
you
wanted
to
say:
yeah
I,
don't
I'm
the
Java
scrap
you'd
have
to
actually
do
it
in
the
meet
ago
or
no
all
right.
So
that's,
basically
the
status
of
it
I,
don't
think
we
found
anything
spec
wise.
That
was
wrong.
E
Yeah
Sergio
did
note
that
transport
CC
has
like
I,
think
a
feedback
sequence
number,
which
makes
it
a
little
easier
to
discover
when
you've
lost
something.
But
after
we
discussed
I
realized
that,
because
you
have
the
RTP
sequence
numbers,
you
can
figure
out
unnecessarily
how
many
feedbacks
you
lost,
but
how
many
feedbacks
of
how
many
packets
were
lost.
So
that's
probably
sufficient
for
anything.
You
need
to
do
a
sure,
sure
sure,
okay,.
G
G
D
E
So
he
was
saying
that
you
know
most
most
kadesha
-1,
a
single
sequence.
Number
space
across
all
streams.
I
mean
I,
think
that
was
what
the
transports
CC
did
I
mean
you
can
do
with
this
level
of
indirection.
You
can
do
that
basically,
just
have
to
keep
of
the
structure
locally
mapping
your
sequence,
number
and
SRC
pair
to
a
the.
E
D
So
Colin
Perkins
as
an
individual
I,
just
you
know
too
hard
to
walk
to
the
microphone
so
yeah
I
mean
that
has
certainly
been
suggested
before.
As
Johnson
says,
he
if
you
give
the
sequence
numbers
per
s,
si
si
you
can
reconstruct
a
single
sequence
number
space
and
by
doing
that,
you
can
congestion
control
each
flow
separately,
which
you
can't
do
if
they're
all
combined
into
a.
E
D
E
D
D
E
B
B
D
D
E
D
H
D
D
Aren't
we
clarified
that,
rather
than
reporting
on
every
SSRC,
this
being
condition
controlled,
you
reports
on
every
active
SSRC
since
there's
a
receiver
you
can
tell
which
SSR
sees
are
being
congestion
controlled
on
months,
so
you
have
to
report
on
them
all
and
let
the
sender
do
the
right
thing.
You.
E
D
E
And
so
that
needs
to
be
clarified,
you
know,
should
it
be
allowed.
If
so,
what
does
it
mean?
Yeah
so
and
the
other
thing
that
came
up
which
is
not
directly
about
its,
but
it
just
occurred
to
me,
also
is
that
you
need
to
make
sure
an
offer
answer
that
at
least
for
an
answer
or
they,
you
only
negotiate
one
congestion
feedback
mechanism,
because
we
had
a
situation
where,
like
you
know,
your
offering
you
know,
transport,
CC
and
RAM
and
CC
FB
and
the
other
side
can
happily
say
sure.
D
Yeah,
if
you
can
send
email,
then
I
will
make
sure
that
gets
put
in
yeah
other
than
that.
What
do
we
do?
We
clarified
that
overlapping
reports
may
be
sent
and
specified
what
happens
when
you
get
overlapping
reports.
You
know
in
that.
If
a
packet
is
reported
as
received,
and
you
then
send
a
later
report
which
give
us
the
same
sequence
number
range,
then
you
need
to
mark
the
packet
has
received
in
that.
So
you
don't
see
you
avoid
contradictions.
D
We
also
clarified
what
happens
with
duplicate
packets,
saying
that
you
report
the
arrival
time
of
the
first
copy
of
you
know
the
first
of
the
copies
of
the
duplicate
that
arrives
and
if
any
of
the
duplicates
of
ECM
congestion
experienced
marked
you
report
it
as
congestion
experienced.
Otherwise,
you
report
the
ec
n
mark
of
the
first
copy
and
the
en
mark
should
be
consistent,
but
who
knows
so
we
at
least
specified
what
to
do.
Is
there
not?
D
So
you
should
just
use
whatever
mechanism
you're
doing
for
the
rest
of
your
rtcp
implementation
to
detect
that
things
have
failed
and
you're
recovering,
and
we
clarified
some
of
the
SDP
that
there
was
a
comment
that,
whether
you,
whether
you
allowed
to
signal
this
for
particular
payload
types
within
the
SDP,
however,
it
has
to
apply
to
all
payload
types
and
that
the
suggestion
of
the
last
meeting
was
that
issued
apply
to
all
payload
types.
So
that's
like
I
wrote
that
into
the
draft
and
I
think
the
final.
D
If
I'm,
remembering
right
thing,
we
added
was
a
section
clarifying
how
it
relates
to
the
ECM
capable
RTP
in
the
previous
ECM
feedback
formats,
since
that
they
both
allow
you
to
report
on
ec
n.
So
we've
provided
some
guidance
on
what
to
do
and
what's
the
right
things
doing
that
space
other
than
that
at
the
time,
I
wrote
the
slides
when
I
open
issues,
but
Jonathan
has
just
given
me
a
couple
more.
So
there
are
a
couple
of
things
we
all
have
to
clarify.
D
B
So
thank
you
all
for
attending
and
if
you're
an
author
on
the
two
outstanding
in
well
draft,
let's
try
to
get
those
final
pieces
submitted,
so
we
can
get
those
drafts
also
something
and
then
we
hope
to
maybe
have
some
results
on
experimenting
with
algorithms
in
the
next
meeting.
So
if
you're
working
on
that
and
want
to
present
something
next
time,
then
let
us
know-
and
we
have
one
more
comment
on
music.
Oh
so
please
so
just
point
out.
G
That,
even
if
we
are
not
presenting
anything
this
during
this
aren't
cut
meeting
searching
myself
and
others,
we
are
actively
working
on
getting
nada
into
Firefox
in
order
to
do
experimental
results.
Searching
already
showed
some
preliminary
ones
based
on
our
RTT
and
we're
now
working
on
one
way,
delay
which,
for
which
we
need
actually
to
combine
our
work,
which
is
B,
so
expect
some
results
soon.
B
Okay,
Thank
You
Sergio,
that's
very
good
to
hear
and
I
know
that
Ingmar
has
also
been
working
on
the
screen,
some
scream
experiments,
so
maybe
that
next
time
we
will
see
both
some
results
for
both
scream
and
nada,
which
will
be
nice.
Okay,
thank
you
all
for
attending,
and
this
concludes
our
meeting
for
today.