►
From YouTube: IETF101-AVTCORE-20180322-1330
Description
AVTCORE meeting session at IETF101
2018/03/22 1330
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
A
We
decided
that
still
is
still
a
meeting
car
because
it
made
the
did
life
easier
for
the
data
tracker,
even
though
I
kind
of
wanted
to
resurrect
you
know
to
resurrect
the
old
abt
group
so
that
we
could
again
be
the
oldest
group
in
the
idea.
But.
A
A
C
A
We
have
no
takers,
which
is
Bo
and
Bernard
doing
an
ether
pad
and
we
have
magnets
on
the
job
if
your
remote.
Also,
if
your
on
me
Tico,
we
have
our
fancy
red
button.
So
if
you
want
to
participate
remotely
and
actually
talk
to
us
using
some
of
the
protocols
that
we
invented
how
exciting
I'm
pretty
sure,
then
it's
using
floor
control
and
it's
using
WebRTC,
so
Jessi
did
an
RTP,
which
is
this
working
groups
protocol.
A
A
Well,
although
it's
not
very
different
as
I
understand,
it
I
think
they
mostly
just
added
the
additional
like
yeah
I,
think
harassment,
policies
and
things
like
that,
but
I
think
they
also
I
think
there
was
also
abyss
of
one
of
the
relevant
RFC's.
But
don't
ask
me:
I'm
not
a
lair,
what
I
think
privacy
policy
was
added
and
I.
Think
one
of
the
I
think
they
just
list
the
things
might
be
s
by
BCP,
not
RFC
number.
So
we
don't
need
to
update
it
when
they
Beth
when
they
grab
the
BCP.
A
Okay
agenda
start
will
start
with
the
arm
cat
feedback
message.
That
column
is
doing.
That's
for
the
for
the
condition
control
work
coming
out
of
our
I'm
cat,
then
Ronnie
has
his
presentation
about
adding
a
frame
priority,
header
extension
and
then
then
we're
done
and
move
over
to
payload,
which
I
think
if
we
finish
early,
will
let
payload
think
over
right
away
because
we
want,
because
we've
got
XR
block
after
payload,
because
we're
basically
resurrecting
the
old
apt
group
we're
just
doing
it.
A
D
A
What
with
all
the
multi-purpose
yeah
other
side,
what
sure
what
you
really
I
mean
my
suggestion
last
time
is
that
we
should
what
was
to
take
multipath
off
the
milestones,
and
you
know
if
somebody
wants
to
bring
it
back.
They
can
I
think
I
said
last
time.
Somebody
said
no
I
might
want
it,
but
there
has
nonetheless
not
bid
a
lot
of
attention
to
that.
So
is
there
any
objection
at
this
point
to
taking
multipath
RTP
off
the
milestones
and.
A
A
A
E
C
F
E
A
E
G
E
E
A
F
A
I
will
so
you'll
send
the
email
to
the
mailing
list
to
that
effect,
thing
that
were
dropping
the
milestone,
but
we
encourage
people
who
are
interested
in
this
work
to
bring
the
entirety
of
them.
You
know
them
all
the
work
necessary
for
a
real
solution,
the
appropriate
working
groups,
all
right,
multiplex,
tried
guidelines.
Where
are
we
on
that?.
F
Common
Pugin,
so
the
multiplex
guidelines
stall
in
that
a
bunch
of
us
started:
writing
it
and
then
sort
of
lost
the
will
to
live
and
give
up
and
Ronnie
decided.
It
was
important
and
would
resurrect
it,
but
then
I
think
it
stalled
again.
I'm
uncle
unconvinced
there
is
value
in
it,
but
I'm
not
objecting.
If
someone
else
thinks
it's
valuable.
H
I
A
J
J
Had
some
comments
that
were
all
hours
of
the
editorial
I
had
a
noodle
bit
about
your
comments
about
the
tl0
pic
index,
rapping
on
idea
or
not,
and
the
the
use
of
the
I
bit
when
spatial
layers
don't
refresh
but
I,
didn't
see
a
hard
need
to
do
anything
different
normatively
for
either
one
of
those
I
think
it's
it's
acceptable
to.
Let
people
do
the
handling,
whichever
way
they
want
for
both
those
issues,
because
I
don't
think,
there's
going
to
be
a
major
benefit
to
doing
or
specifying
one
certain
way.
I.
A
J
Can
add
some
more
clarification
text
around
around
the
scenarios,
but
I
don't
think
we
want
to
enforce
anything
normative
leave
either
way
either.
You
know
prohibit
streams
that
do
it
one
way
or
tell
receivers
that
they
can
always
count
on
it.
Being
this
way,
I
think
you
either
were
you
know
those
would
be
a
bad
thing
to
put
in
spec,
but
we're
gonna
have
some
clarification
text
around
what
the
scenarios
are
and
all
the
other
comments
were
were
largely
tutorial
and
clarification
as
well.
J
So
for
the
I
bit
it
was:
do
you
want
to
prohibit
layer
structures
where
spatial
layers
do
not
refresh
when
base
layers,
intro
refresh
and
what's
the
meaning
of
the
I,
but
in
that
case,
I
think
it's
as
written
I--but
as
per
layer,
so
it
doesn't
for
anything
to
have
a
base
layer
with
it.
I
bit
set
doesn't
mean
that
the
spatial
enhancement
layers
are
going
to
also
have
their
idea
set.
So
I
think
the
current
semantics
work
work.
J
A
G
G
J
So
I
think
we
can
add
some
clarifying
text
about
why
it
could
be
one
way
or
the
other
depending
on
the
payload
format,
but
we
don't
have
anything
normative
about
requiring
it,
and
the
other
thing
is
that
we
had
a
new
IPR
disclosure
we
already
had
one
before,
but
it
was
the
terms
were
pretty
permissive.
Basically
RF.
If
you
don't
bug
us,
but
the
new
disclosure
is
just
friend,
so
you
know
possibly
royalty
bearing
declaration
there.
So
everyone
please
take
a
look
at
that
and
and
make
your
evaluations
about
it.
A
Okay,
great
and
if
there
were
and
I
guess,
if
you're
making
technical
decisions
on
things
respond
to
them,
you
know
I,
guess
if
you
respond
to
like
my
email,
where
there
are
actually
technical
questions,
not
just
editorial
I'll
try
to
braise
them
MLS
to
just
so.
We
could
make
sure
that
they're
called
out
and
people
can
respond
if
they
disagree
with
those
decisions.
G
A
D
F
F
Next
slide,
please
I'm
here
to
talk
about
the
TCP
congestion
feedback
draft,
so
we
we've
been
discussing
this
in
our
mcat
for
some
number
of
months
now
and
at
the
last
meeting
was
a
decision
to
adopt
this
as
an
AV
T
core
document,
and
we
submitted
the
zero
zero
were
heavy
t
car
working
group
draft
in
October
2017,
which
was
identical
to
the
design
team
output
from
our
MCAT
and
then
just
before
this
meeting,
we
submitted
a
zero
one
update,
which
is
a
much
more
substantial
update
the
summary
of
the
changes
in
the
zero
one
update
is
on.
F
Here.
We
figured
out
the
the
values
for
the
time
stamps
and
the
formatting
of
the
time
stamps
and
adjusted
the
arrival
time
stamp.
Lock
rate
I
made
a
bunch
of
clarifications
on
what
gets
reported
in
which
packets
and
how
to
handle
sequence,
number
referendum.
That
sort
of
thing
and
I'll
talk
about
much
more
about
that
in
a
second,
we
also
just
gave
some
new
expanded.
The
security
considerations
clarified
the
draft
throughout
cited
the
the
CC
feedback
draft
for
the
timing,
rules
and
so
on,
and
so
on.
F
Ok,
so
looking
at
the
technical
changes
in
the
previous
version
of
the
draft,
the
report
time
stamp,
which
indicates
when
this
congestion
control
feedback
was
sent,
was
very
ill
specified.
The
draft
said
it
should
be
should
be
derived
from
the
same
wall.
Clock
used
to
timestamp,
RTP
packet
arrivals
suggested
the
applaud
resolution
of
a
bout
of
a
tenth
of
a
millisecond
made
sense,
but
didn't
specify
anything
else.
So
we
would
have
needed
some
signaling
to
say
what's
clock
rate
was
being
used.
What
the
resolution
was
how
the
clock
was
derived
and
so
on.
F
The
draft
didn't
define
any
of
that
signaling.
What
the
the
new
version
of
that
draft
does
is
that
you
use
the
same
clock
used
to
generate
the
NTP
timestamp
in
the
sender
report
and
the
receiver
report
packets
and
you
font
it
in
the
same
way
as
the
NTP
timestamp
in
those
packets,
and
that
gives
you
a
one,
sixty
five
thousandth
of
a
second
clock
resolution,
which
is
more
accurate
than
that
which
was
suggested
before
and
has
a
sufficient
range
that
it
covers
all
the
appropriate
values.
And
it's
a
clock
you
already
have.
F
If
you
have
an
RCP
implementation,
so
it
seemed
easier
to
just
mandate
an
existing
clock
sauce
than
to
define
some
singing
and
make
everyone
go
to
the
complexity
of
having
different
singling
different
versions
and
hang
to
agree
on
what
was
the
right
thing.
So
it
was
the
first
change
mcslade,
the
the
second
change.
Once
we
did
that
the
arrival
time
offset
fields
which
sure
the
difference
for
when
the
arrival
time
of
the
arrival
time
of
an
RTP
packet
relative
to
that
timestamp
field
were
previously
specified
in
milliseconds.
F
So
I
guess
the
question
is:
does
this
make
sense
and
I
get
the
question
for
our
MCAT?
Is
it
doesn't
make
sense
for
the
King,
the
the
congestion
control,
algorithms,
I
guess?
The
group
from
the
question
for
this
group
is:
does
it
make
sense
for
an
ICP
usage
point
of
view?
Is
this
a
sensible
clock
and
formative
in
an
appropriate
way
and
if
anyone
has
an
objection
to
this
proposal,
I
something
you'd
like
to
hear
but
I.
A
Don't
feel
like
standing
up,
but
you
know
in
my
main
concern
would
be
if
you're
you're,
obviously
comparing
these
arrival
times
to
you're
sending
times
and
if
the
arrival
time
is
I
mean
there's
probably
your
system,
your
your
operating
system
is
not
giving
you
these
times
in
the
other
24.
Second,
so
you
might
end
up
with
roundings
yeah.
F
Yeah
I
mean
you're
gonna,
get
those
roundings
pretty
much
any
way
you
specify
thickness.
Yeah
yeah
I
tend
to
think
that
is
probably
unimportant
for
a
level
of
accuracy
we
care
about
and
it's
its
cleanest
to
specify
it.
This
way
is
I
I'm
inclined
to
probably
agree,
but
but
yeah
there's,
certainly
a
rounding
issue
somewhere.
Yeah.
F
Okay,
next
slide
all
right,
some
of
the
other
triggers
we
specified
what
happens
if
you
don't
get
any
packets
from
an
SSRC
in
in
a
reporting
interval
and
the
recommendation
here
is:
if
you
don't
get
any
packets,
you
don't
send
a
report
and
you
should
send
a
regular,
send
a
report
or
receive
a
report
in
that
case,
and
typically
you'll
be
sending
the
congestion
feedback
as
part
of
a
compound
packet
which
has
one
of
those
anyway.
F
I
guess!
The
alternative
here
will
be
concerned
that
a
congestion
feedback
packet
was
just
the
beginning:
sequence,
equal
to
the
end
sequence
equals
the
last
sequence
number
you
reported
on,
which
was
also
sure,
but
there's
nothing
sent
and
we'd
have
to
specify
what
you
do
if
you
never
got
any
packet
looking,
we
could
work
through
that
to
me
it
doesn't
seem
worth
the
overhead,
but
if
people
thought
that
was
easier,
we
could
suddenly
suggest
that
that
was.
F
The
other
thing
we
did
it
was
specify
what
sequence
numbers
you
should
include
in
each
report
and
the
previous
version.
The
draft
didn't
specify
what
seemeth
number
ranges
were
in
each
report.
The
new
one
just
says
you
report
them
on
all
the
packets
you
got
and
the
sequence
number
range
in
reports
n
starts
one
packet
after
the
reporting
that
the
range
in
packet
n
minus
one,
so
I
just
thought.
Yeah
they're,
just
consecutive
blocks.
It's
doing
the
obvious
thing.
F
F
C
F
That
you
got
that
package
I
tend
to
think
it's
not
worth
it,
because
it
arrives
too
late
to
be
useful
for
congestion
control
in
pretty
much
every
case.
Anybody
but
yeah.
We
had
specify
what
would
happen
if
you
did
it
and
in
addition,
we
put
in
some
some
discussion
about
handling
sequence,
number,
wraparound
and
I
put
it
some
words
about.
If
you
get
a
packet,
which
is
more
than
one
quarter
of
the
sequence
number
space
ahead
of
behind
you
ignore
it.
F
A
F
A
F
F
Okay,
other
than
that,
we
just
made
a
bunch
of
clarifications.
Essentially,
we
fix
the
security
considerations
specified,
that's
sequence:
numbers
can
wrap
around
and
you
have
to
handle
that
and
delegate
it
to
the
errand
cat
draft
for
further
guidance
for
how
you
configure
our
TCB.
So
you
get
the
appropriate
amount
of
feedback
and
just
did
a
bunch
of
editorial
fixes.
C
F
A
A
A
F
A
Rest,
the
rest
would
be
congestion,
control,
algorithms,
probably
but
I
mean
we
I
I
mean
I
would
not
be
inclined
to
have
some
way
of
saying.
Some
sources
should
get
this
feedback
and
some
shouldn't,
because
that
doesn't
feel
like
to
be
useful.
But
if
somebody
thinks
we
should,
then
we
need
to
say
personally
or
say.
F
F
A
Well,
I
will
go
a
little
further
than
please
is.
Can
we
have
anybody
who's
willing
to
volunteer
to
review
this
Harold
volunteers,
to
review
it
and
I'm
Bernard
photographer
ology
review
it
so
and
Magnus?
So
maybe
the
laundry
review,
which
is,
would
be
good
if
that
all
happened.
So
please
said
you
review
the
list.
I'm.
F
C
B
F
A
H
H
It
says
that
that
there
are
drop
up,
that
this
frame
is
droppable
and
by
droppable
it
mean
it's
must
be
decodable,
because,
because
of
all
that's
what
it
says,
it
doesn't
provide
any
more
information
about
it
and
the
the
problem
is
that
I
mean
let's
say
we
have
a
couple
of
free
market
is
even
though
there
are
not
no
definition
about
which
frames
should
be
marked
as
droppable
in
the
non-scalable
one.
It
doesn't.
H
It's
this
provides
more
options
to
the
middle
box
to
address
things
like
congestion
control.
By
deciding
how
many
frames
it
want,
how
many
frames
it
to
drop
part
of
the
frame
in
some
better
way
than
just
doing
it
arbitrarily
it's
a
lot
of
differentiation
between
reference
and
known
reference
be
frame
to
drop.
H
First,
the
known
reference
be
frame,
dropping
frame,
and
this
is
more
like
the
proposal
about
how
we
are
trying
to
we're
currently
testing
how
to
to
do
that
I
out
what
if
this
priorities
was
to
to
differentiate
between
an
orphans,
be
frame
and
reference
be
frame
and
dropping
P
frame
that
are
closer
to
the
end
of
the
group
of
GOP.
It's
better
than
dropping
one
at
the
beginning
can
be
marked.
This
is
droppable
is
Louis
priority
next
slide.
D
H
D
H
D
H
H
A
C
F
H
Basically,
I
wrote
some
of
the
way
that
we
are
doing
based
on
on
the
B
frame
and
P
frames,
but
we
can
add
it
to
the
document.
If
it's
not
there,
I
mean
to
explain
what
what
at
least
I
mean
again
it's
up
to
the
encoder
to
decide
which
frames
he
wants
to
decide
which
one
unless
or
higher
priority,
and
that's
why
I
said
it's
not
it's
not
for
comparing
between
two
different
strain.
It's
in
a
single
stream
to
figure
out.
F
H
F
H
I
H
H
I
H
Probably
probably
yes
but
I,
don't
think
they
did
if
he
drops
that
there
would
a
lot
the
ones
who
will
try,
try
to
drop
certain,
but
they
were
but
I
mean
the
recovery
on
the
receiver
side
can
be
multiple
ways.
I
mean
DUP.
Sixes
are
doing
just
the
motion
estimation
or
things
like
that
in
order
to
recover
afterwards
without
any
FEC
or
anything,
not.
E
E
E
A
H
J
A
D
A
H
A
So
I
guess
the
question
is:
is
this?
Is
there
interest
in
this
and
I
know
it's
always
hard
to
get
traction
here
for
things
in
the
IPTV
space
rather
than
the
conferencing
space
I
mean
it's
obviously
not
a
big
draft
other
than
this
question
of
you
know
is
them
you
know.
Is
there
enough
information
for
the
for
the
marker
to
do
something.
H
H
H
A
H
A
H
J
Mercenary
I'll
just
echo
the
same
comments
I've
had
for
the
last
several
sessions
when
this
is
brought
up.
I
don't
have
any
objection
to
work,
but
my
my
reservation
about
it
is
that
you
know
it
requires
a
certain
amount
of
coupling
between.
You
know
all
system,
components,
senders
and
receivers
need
to
have
a
certain
level
of
understanding.
J
So
the
reason
you
bring
at
the
ITF
would
be
to
standardize
understanding,
but
it
seems
to
me
pretty
hard
to
actually
standardize
the
level
of
understanding
well
enough,
so
that
so
that
senders
and
receivers
you
know,
have
a
good
feel
for
what
what
the
percentages
and
and
and
relative
priorities
are
of
these
packets.
So
so
I.
That's
why
I
think
if
you,
if
you
already
have
coupling
between
your
senders
and
receivers,
you
only
need
ITF
to
do
anything.