►
From YouTube: IETF-AVTCORE-20220519-1700
Description
AVTCORE meeting session at IETF
2022/05/19 1700
https://datatracker.ietf.org/meeting//proceedings/
B
B
C
D
A
Do
we
have
a
volunteer
for
notetaker?
Okay,
I
will
give
it
a
try.
Well.
Thank
you
very
much.
Thank
you
very,
very
much,
okay.
Well,
why?
Don't?
We
get
underway?
So
in
case
you
just
stumbled
into
this
room
by
accident.
We
are
the
avt
qr
working
group
and
we're
having
a
virtual
interim
for
two
hours.
We've
got
lots
of
stuff
on
the
agenda.
A
Just
a
few
tips.
You
enter
the
queue
with
a
hand
icon,
I
think
that's
still
true
and
that
you
need
to
enable
audio
or
we
won't
hear
you
and
you
do
that
by
muting
and
you
disable
by
muting.
You
can
also
do
videos
separate
from
audio
it's
encouraged,
but
not
required
a
little
bit
about
the
meeting.
The
agenda
is
up
there
on
the
data
tracker.
A
B
A
B
Yeah,
but
I
mean
I
would
I
guess,
the
only
thing
is
if
somebody
isn't
able
to
use
their
mic
for
whatever
reason,
if
you
know
due
to
our
family
or
whatever,
you
can
comment
in
the
chat
and
it'd
be
good.
If
we
had
somebody,
who's
was
actively
watching
that,
but
we
as
a
tear
as
well
try
to
watch
it
to
see.
If
somebody
wants
to
say
something
that
they
can't
say.
A
So
a
little
bit
about
the
notewell,
it's
a
reminder
of
itf
policies,
in
effect
on
things
like
patents
or
code
of
conduct.
It's
just
to
point
you
in
the
right
direction.
By
participating,
you
agreed
to
follow
these
processes
and
there
are
disclosure
obligations
and
definitive
information
is
in
the
documents
that
are
described
in
the
link
here.
A
Also,
we
have
a
professional
conduct
policy,
as
defined
in
the
itf
guidelines
for
conduct,
anti-harassment
and
procedures
in
the
output
stream,
etc.
They're
striving
to
maintain
an
environment
where
people
are
treated
with
dignity,
decency
and
respect,
and
please
don't
do
anything
outside
of
that.
If
you
believe
you
have
been
harassed,
you
can
talk
with
the
ombuds
persons,
so
I
guess
we
do
have
itf
114
plans,
it's
a
hybrid
meeting.
A
A
Sure,
okay
comment
on
the
chat's:
fine,
if
you're
playing,
I
guess,
if
you're
planning
on
coming
in
person,
comment
in
the
chat,
it'll
just
give
us
an
idea.
I
guess
how
big
a
physical
room
we
would
need,
and
things
like
that
for
the
variety
of
114.,
so
we'll
just
take
a
minute
and
then
we'll
move
on.
A
Okay,
all
right
so
here
is
the
agenda.
For
today
we're
gonna
start
out
with
administrative
stuff.
Then
cryptex
frameworking
skip
rc
7983
this
some
quick
presentations
on
web
transport
liaison,
I
guess,
will
you'll
you'll
handle
liaison
because
johnny
bar
has
coveted
and
then
stp
for
quick
and
then
a
v3c
and
then
we'll
wrap
up
and
figure
out
what
to
do
next.
A
Okay,
so
here
is
the
status
I
think
where
we're
at
so
the
two
most
recent
items
we
published
vp9
is
in
the
rfc
editor
queue,
I
guess
cryptex
we're
gonna.
It
has
finished
itf,
less
call
on
the
fifth
and
and
sergio
will
talk
about
the
items
to
wrap
it
up.
Bbc
just
completed
itf,
let's
call
today-
and
we
will
be-
I
guess
talking
about
that
on
the
list.
Stefan,
it's
not
all.
The
reviews
have
come.
E
A
A
One
thing
which
has
come
up
with
cryptex.
I
think
you've
probably
seen
this
on
the
list,
as
an
ipr
declaration
has
been
submitted
from
qualcomm
and
I
sent
a
notice
to
the
list
on
the
7th,
and
so
we
are
required
or
suggested
to
ask
on
the
list
whether
there's
any
concerns
relating
to
that
ipr
declaration
or,
let's
just
say,
are
there
any
objections
to
proceeding
with
publication.
A
F
F
So
the
first
first
one
is
a
additional
about
the
sdp
declaration
that
we
currently
say
that
the
sap
the
attribute
takes
no
value
and
they
complete
that.
Why
no
value.
So
I
try
to
find
the
definition
that
it
was
in
the
in
the
in
the
sdp
in
the
when
we
define
the
sap
attributes,
and
it
seems
that
it
is
a
an
attribute.
A
technology
is
a
property
attribute,
so
I
have
two
proposals
to
to
change
this
and
this
to
clarify
it
a
bit
further.
F
F
F
F
Anyway,
I
will
let
the
issues
here,
and
this
is
so.
If
anyone
has
to
provide
any
further
comments,
you
can
do
it
in
the
indie
and,
if
not,
I
will
take,
I
will
just
merge
one
pr
with
one
of
both
of
them,
so
the
nsa
feedback
is
a
that
is
when
we
talk
about
the
encrypted
region
and
it
was
not
clear
what
would
mean
the
the
rayon
for
them.
So
I
just
replaced
the
the
region
to
agree
by
the
the
term
that
it
is
using
in
stp
that
it
is
the
encrypted
portion.
F
F
And
this
is
a
was,
is
well
it's
a
a
change
in
the
wording
that
when,
when
we
explain
what
should
an
implementation
do
if
in
case
that
that
the
that
that
chris
said
well,
it
was
negotiation
was
not
negotiated,
but
it
was
considered
as
mandatory
for
the
for
for
the
implementation.
So
we
said
that
then
we
should
reward
this.
So
I
have
proposed
this.
This
alternative
word
link
just
to
make
it
more
clear
that
what
that
is,
a
recommendation
to
implement.
F
A
A
E
A
F
And
there
was
a
feedback
about
a
typo
in
the
in
one
of
the
diagrams
that
has
been
already
fixed
and
then
a
comment
that
if
we
should
define
the
enchronics
for
srtps,
src
and
csrc
and
the
other
ones,
I
don't
think
that
it
is
needed
at
the
s8.
If
you
are
looking
at
this
surface
and
the
last
one
is
a
typo
that
has
also
been
fixed.
F
So
this
is,
there
are
a
couple
of
them
next
slide,
so
I
will,
if
I
don't
hear,
not
hear
any
feedback
from
the
issues.
I
will
just
merge
the
pending
prs
and
I
will
review
the
item
that
we
have
just
does
just
discuss
about
the
latest
clarification
about
the
mandatory
to
implement
in
the
or
how
to
use
in
the
center
and
the
receiver
and
when
it
is
the-
and
I
will
then
create
a
new
draft
and
unpolish
it.
So
we
can
continue
the
process.
F
A
H
Okay,
can
you
hear
me
okay,
yeah
all
right,
so
this
is
the
current
status
of
the
frame
marking
draft
it's
gone
through
last
call
and
received
mostly
editorial
and
meta
feedback
from
from
the
area
reviews.
There's
a.
I
didn't
include
the
text
of
of
all
of
the
reviews
or
the
text
from
the
draft
that
was
being
referenced
because
they
were
mostly
editorial
and
meta
level
comments.
H
We
can
look
at,
but
basically
the
gen
art
area
general
area
wanted
to
clarify
the
scope
of
the
experiment,
its
timeline
goals
and
ionic
changes.
I
looked
at
other
experimental
drafts.
None
of
that
is
in
any
of
the
other
drafts,
so
I'm
not
sure
why
it's
being
requested
here,
we
can
add
a
blurb
of
you
know
very
general
vague
language.
I
don't
know
if
it
really
does
any
good.
H
The
larger
issue
here,
though,
it's
more
of
a
meta
question,
but
the
larger
issue
here
is
that
I
don't
honestly
consider
this
an
experiment.
I
don't
consider
people
are
experimenting
with
to
see
how
things
work
out
and
then
change
something
you
know
promote
it
to
propose
standard.
If
not
people
are
either
going
to
use
it
or
not
use
it
maybe
more
fit,
but
that
would
be
a
totally
new
draft.
H
You
know
a
different
version
of
the
header
extension
with
with
new
semantics,
so
I
guess
the
question
for
the
for
the
work
group
is,
you
know,
do
you
really
all
still
consider
an
experiment
and
if
you
do,
do
you
have
any
input
on
what
the
scope
goal
and
time
of
the
experiment
should
be?
If
not
I'll,
add
some
very
generic
language.
B
Yeah,
I
I
think
I
I
agree.
I
don't
really
consider
an
experiment
either.
I
think
there's
a
tendency
to
use
experimental
to
mean
you
know.
I
don't
think
it's
good
enough
for
proposed
standard,
but
we
still
want
to
publish
it,
but
I
think
maybe
we
should
say
informational
instead,
if
we
meet,
if
that's
what
we
mean,
possibly,
we
should
talk
to
our
area
director
about
this.
A
A
Yeah
I
mean
one
thing
about
experiments
is
you're
kind
of
admitting
that
things
may
change.
You
know
we've
done.
I
counted
at
least
four
of
these
exp.
These
kind
of
rtp
header
extensions
forwarding
extensions
right.
So
it's
not
like
this.
The
whole
thing
is
settled
and
we
understand
that
that's
one
could
be
one
interpretation
of
experiment,
yeah.
H
Like
I
said,
I
can
add
very
generic
language.
You
know
maybe
mentioned
that.
You
know
you
know
experimental.
You
know
implementation
and
deployment
experience
with
this
and
other
header
extensions
like
the
av-1
dependency
descriptor,
and
you
know,
see
the
pros
and
cons
of
each.
I
can
put
some
very
generic
language
around
around
that
in
the
draft.
If
people
think
that's
useful
people
are
using,
you
know
some
sort
of
frame
markings,
whether
it's
this
or
their
own
or
newer
ones
that
are
under
development.
H
A
I
D
H
H
H
Comments
about
header
integrity,
protection
inside
of
the
security
considerations,
martin
had
some
comments
in
the
art
review
about
the
wording
in
one
section
being
better
than
the
wording
in
the
subsequent
sections,
so
I'll
I'll
go
ahead
and
just
make
the
wording
for
tit
and
lid
more
uniform
to
match
the
first
section
331,
it's
just
a
little
bit
more
verbose,
but
it's
a
short
document
anyway.
So
we
won't
extend
the
length
much.
H
H
I
don't
have
a
strong
opinion
of
whether
or
not
that
sentence
should
remain,
but
I
mean,
obviously
you
don't
want
someone
shouldn't
be
misrepresenting.
What's
in
the
payload
by
adding
you
know
bogus
data
in
the
header
extension,
maybe
that
doesn't
need
to
be
said,
but
this
was
just
trying
to
get
at.
If
a
sender
knows
its
payload,
it
should.
You
know,
mark
the
header
extension
properly
to
match
the
payload
or
if
anyone
has
a
view
on
whether
that's
just
an
unnecessary
thing
to
say.
B
I
think
so
yeah
I
mean.
The
only
thing
I
could
think
is
that
you
know
like.
I
can
imagine
cases
where,
like
you
know,
the
you
know
it's
actually
more
complicated
than
that.
This
is
a
simplification,
but
it
kind
of
matches.
It's
still
a
reasonable
thing
to
do.
You
know
if
you
know
if
what
you're
doing
is
more
complicated
than
represent,
which
is
you
know
honestly
often
the
case
but
which
I
think
it's
I
don't
think
I
mean.
Maybe
it's
enforceable.
B
B
A
Yeah,
there's
also
the
question
of
who
is
it
enforcing
right
because
there's
the
sfu,
which
is
may
not
even
look
in
the
payload
right.
So
it's
just
doing
everything
based
on
the
header,
extension
values
and
then
there's
a
receiver
and
are
we
saying
the
receiver
should
check
that?
They're
the
same?
I
don't
know
the
receiver
doesn't
even
may
not
necessarily
even
look
at
the
header
extension
right.
It
may
just
look
at
the
payload
yeah.
B
Like
I
said,
I
think
that
they
do
it
or
won't
work
right,
not
up.
Somebody
has
to
enforce
it
for
security
reasons
or
anything
like
that
yeah.
So
I
think
it's
I
mean.
I
need
to
look
at
the
context
to
make
sure
maybe
it's
confusing
in
context,
but
I
think
it's
you
know
as
a
requirement
on
its
own.
I
think
it's
a
reasonable
one.
H
B
H
H
H
So
no
objections,
I'll
just
add
video
to
the
frame
marking,
title
video
frame
marking
to
the
title,
and
and
that's
it
next
slide
so
there'll,
be,
I
think,
just
one
more
slide
on
next
steps,
so
I'll
propose
the
responses
on
the
list
and
make
sure
everyone
is
in
line
with
it.
Since
this
meeting
is
not
doesn't
have
that
many
attendees
and
then
assuming
no
review
feedback,
I'll
update
the
draft
and
we'll
submit
version
14.
K
K
K
K
G
Okay,
first
question
was
referring
to
some
of
the
language
if
you
will
of
end-to-end
security
and
what
exactly
that
means
in
the
context
of
skip
versus
other
contacts
bernard.
I
guess
you
had
this
question
regarding
in
reference
to
s
frame,
we
didn't.
We
don't
feel
that
s
frame
is
under
consideration
for
skip
at
this
point.
G
Only
because
that's
kind
of
outside
the
scope
of
skip,
if
you
will
it's
skip,
is
what
we
will
be
a
point
to
multi-point
when
using
you
know,
using
a
trusted,
multi-point
control
unit
mcu
for
what
we're
gonna
be
for
for
multi-party
video
conferencing,
so
that's
kind
of
where,
where
we
are
with
that
and
that
kind
of
leads
to
the
second
question
there
of
seeing
you
know
application
layer
security.
While
I
believe
we're
clear
in
that
in
the
section
two
where
we
say
it's
an
end-to-end
security
at
the
application
layer.
G
A
It
was
just
it
was
just
that
it's
at
least
the
way
the
term
has
been
used.
It
refers
to
going
from
one
endpoint
to
another
endpoint
and
since
the
mcu
is
trusted
in
this
model
that
that's
not
really
the
case
for
skip,
I
mean
you
can
use
the
term.
It's
just
it's
just
helpful
to
for
people
to
understand
that
the
model
is
is
not
that
of
an
untrusted
mixer
right
that
mr
mixer's
trusted.
So
the
mixer.
E
G
Right
and
we
didn't
really
have
in
in
under
when
we
came
up
with
the
text,
we
weren't
really
thinking
necessarily
of
the
the
multi-point
video
mixing
situation,
for
that
guy,
normally
skip's
been
primarily
used
for
at
this
point,
is:
is
end-to-end
user
to
you
know
endpoint
endpoint
at
this,
so
there
really
hasn't
been
a
central
mixing
unit.
If
you
will
to
at
this
point
so
it's
kind
of
where
we
tend
to
tend
to
go
with
end-to-end
security.
At
this
point
so.
K
We
consider
that
the
social
security
association
will
be
a
point-to-point
type
of
communication
and
there,
if
there's
or
into
a
conferencing
mode
depending
upon
what
was
negotiated
in
this
session,
it'll
depend
on
how
it'll
be
handled,
but
from
the
networking
perspective,
which
is
really
where
this
this
rfc
is
trying
to
focus.
They
will
not
have
any
knowledge
of
what's
going
on
other
than
the
rtp
payload
types
we
addressed
in
the
previous
frame.
G
G
You
know,
for
example,
changing
it
to
no
transcoding
and
no
lossy
compression
techniques
shall
not
be
performed
on
the
skip
payload.
So
I
guess,
if
there's
any
recommendations
for
better
text,
just
to
say,
don't
don't
modify,
don't
do
anything
to
our
data,
just
let
it
pass
through
no
transcoding.
None
of
that
stuff.
I
don't
know
if
there's
recommendations
for
any
better
terms
to
use
for
that
that
we
could
that
we
could
use.
G
Okay,
next
question
was
about
audio
and
video
multiplexing
at
the
application
layer.
Again
we
hadn't
really
considered
that
in
at
this
point-
and
it's
kind
of
also,
I
think,
beyond
the
scope
of
this
skip
rf
the
skip
request,
if
you
will,
because
that
can
be
implemented
independent
of
how
we
declare
declare
skip
at
this
point,
so
I
think
our
position
is
we
it's
kind
of,
like
I
said,
that's
kind
of
outside
the
scope
of
this
of
this,
and
similarly
for
the
reference
for
the
bundle,
the
rfc
9143.
G
A
G
Correct
I
mean,
like
I
said
I
didn't
see
any
I
didn't
see
any.
I
read
through
those
real
quickly
and
I
didn't
see
anything
that
could
possibly
interfere
with
skip
at
this
point,
how
we've
declared
it.
So
I
think
that
they
are
beyond
outside
the
scope
of
this
and
shouldn't
interfere
with
what
we've
defined.
A
G
A
G
A
G
A
K
K
Yeah,
I
think
it's
a
the
problem
statement
there
to
be
beginning
is
really
why
we're
here,
because
if
people
don't
recognize
the
skip,
audio
and
video
skip
rtp
decorations,
then
it
can
often
be
stripped
out
in
some
settings.
It's
even
unintentionally,
stripped
out,
because
the
particular
network
product
doesn't
have
a
setting
the
pull
down
menu.
K
If
you
want
to
call
it
that
that
says,
skip
in
it
so
in
in
coming
forward,
and
then
bringing
this
to
light
that
this,
what
this
protocol
does
and
and
the
community
that's
out
there
that
supports
it,
and
you
establish
products
that
are
already
out
there
that
are
using
this.
We
need
some
way
to
get
this,
this
globally
accessible
reference
material
out
to
them.
K
K
D
Stefan,
this
is
not
a
question.
This
is
a
comment
I
I
see.
I
have
observed
something
that
I
can.
That
looks
to
me
like
an
orchestrated
campaign
in
showing
support
for
for
the
various
stages.
That's
really
not
necessary.
To
that
extent
yeah.
That's
that's
just
blowing
up
me
to
making
this
traffic.
You
know
you
don't
have
to
do
that.
D
K
B
K
A
A
So
that's
the
scheme,
that's
being
proposed
now
in
terms
of
the
recent
changes
from
o2
to
o3,
we
looked
into
the
compatibility
with
quickv2.
It
turns
out.
Quickv2
doesn't
introduce
any
changes
that
affect
the
multiplexing.
So
it's
fine
with
that.
We
updated
our
reference
for
dtlsv3,
then
for
o3
204.
We
were
made
of
aware
of
the
quick
bit
greasing
draft,
which
does
have
a
major
effect
upon
this,
because
it
essentially
allows
the
second
most
significant
bit
of
this
first
octet
to
to
change
right.
That's
what
the
greasing
is.
A
And
similarly,
if
you
remove,
if
you
set
that
second
most
significant
bit
to
zero
in
the
short
header,
then
you
will
overlap
with
stun
and
zrtp
and
dtls.
So
it's
it's
a.
It's
basically
makes
multiplexing
infeasible
it'll
it'll
break
everything,
so
we
added
a
paragraph
to
section
one
basically
saying
indicating
it's
compatible
with
quick
v2,
but
not
with
quick
bit
greasing,
and
so
basically
the
idea
is.
If
you
want
this,
you
have
to
not
negotiate
bit
greasing,
so
you
don't
indicate
support
in
a
transfer
parameter.
You
don't
negotiate
it!
A
A
A
B
I
G
G
A
C
B
B
H
H
We
have
many
instances
of
this
where
exhaustify
the
first
version
defines
something
and
it
just
you
know,
lingers
forever,
and
I
think
it's
too
late
to
already
think
that
you're
going
to
reclaim
that
bit
now
by
greasing
it
and
make
it
you
know
available,
you
don't
even
know
what
you're
making
it
available
for.
So
in
all
video
payloads,
you
know
we
have
a
similar
thing.
We
have
the
forbidden
bit
in
mpeg,
you
know
it's
a
relic,
and
yet
you
know
it
still
lives
in
almost
all
of
the
video
payloads.
L
L
L
There
was
this
behavior
happening
randomly,
so
I
considered
this
case
with
a
constant
rate,
a
constant
link
limit,
and
we
can
see
on
the
figures
on
the
top
right
that
the
the
target
keeps
decreasing
over
the
time
which
was
kinda.
Well
will
so
I
was
thinking
there
might
be
a
bug
in
the
implementation
next
slide.
L
So
I
displayed
the
all
the
screen
statistic
I
could,
and
I
observed
in
the
that
the
rtpq
delay
was
really
high.
Once
we
we
did.
We
decreased
the
link
capacity,
so
the
rtpq
is
where
steam
screen
stores
in
rtp
packet,
because
in
the
according
to
the
rfc
screen,
does
not
allow
to
transmit
directly
the
rtp
packet
over
the
network.
It
is
enqueued
in
the
eq
before
and
this
screw
is
being
cleared
when
it
switches
a
dv
max
value,
which
is
computed
from
the
rtt
estimated
by
a
scream
and
then
that's.
L
So
in
the
implementation,
when
you
are
using
screen,
you
need
to
to
call
a
specific
method
to
know.
If
you
can
send
a
packet
on
the
network
or
not,
which
is
it's
okay
to
transmit
it.
Will
it
will
return
you
like
minus
-1.
If
the
rtbc
is
empty,
so
you
can't
set
anything
or
the
congestion
window
is
full,
so
you
don't
you
it
doesn't
allow
you
to
to
send
any
packets.
L
Otherwise,
it's
not
a
new
time.
If
it
is
less
than
one
millisecond,
you
can
send
packets,
otherwise
it
is
above
one
millisecond.
This
is
the
pacing
mechanism,
so
you
have
to
wait
this
amount
of
time
before
sending
the
packet
and
when
you
decrease
the
link
limit
this
time,
written
by
this
method
was
always
over
one
millisecond.
L
So
in
the
implementation
in
the
implementation
of
the
experiment,
when
it
was
over
one
millisecond,
you
never
dequeue
the
packet
which
mean
the
attitude
was
always
full
and
was
eventually
clear.
So
by
taking
into
consideration
this
last
scenario,
this
last
return
value.
I
had
like
new
results,
so
next
slide.
L
We
can
see
this
here,
so
the
individuals
look
like
really
similar,
whether
you
use
neoreno
or
not,
next
slide,
please
so
just
in
conclusion.
I've
been
reproducing
this
quick
condition,
control
experiment,
and
I
think
I
found
it
back
in
the
implementation
and
after
things
in
fixing
this,
I
could
see
that
the
behavior
of
screen
on
top
of
neurino
is
like
really
similar
to
running
screen
alone,
because
neurino
is
always
application
limited
and
as
a
next
step,
it
could
be
interesting
to
to
find
a
network
scenarios
where
we
can't
see.
L
L
E
Spencer
yeah.
Thank
you.
Thank
you
for
doing
this
work
david.
I
really
appreciate
it
and
it
was
on
a
pretty
important
topic
for
discussions
that
I've
been
involved
with.
Certainly
is
there
a
place
where
you
describe
the
environment
for
the
experiment
a
little
more
precisely
like
you
know
what
bit
rates
and
thinking
and
things
like
that
that
you're
using.
L
E
B
Yeah
I
mean
there's
something
in
the
kill
comment
I
mean
I
guess
sort
of
the
two
take
away
from
this.
Is
that
scream,
because
it's
keeping
low
delay
basically
limits
you
more
than
neurino
and
nurino
is
essentially
not
doing
anything?
Is
that
sort
of
the
neurino
is
always
application,
limited
so
it'll
always
say
yes,.
L
B
B
C
M
All
right
then,
like
first,
I
think
you're
just
got
to
lower
that
I
have
a
question
to.
I
think
it
was
like
36,
because
I
think
this
fix
it
presented
might
include
one
fix
we
already
presented
in
february
2,
which
was
that
we
sent
a
lot
of
rtcp
feedback
which
caused
the
contrasted
feedback
link
and,
in
turn,
resulted
in
a
bad
bandwidth
estimation
and
here
on
the
slide,
says
the
receive
bandwidth
in
the
blue
line.
M
F
F
My
good
feeling
is
that
it
doesn't
matter
how
much
even
a
small
castle,
how
much
pervert
we
send
in
with
the
screen
that
the
key
is
going
to
see
what
happens
when
when
new
renault
key
is
beginning
because,
for
example,
you're
sending
a
file
with
a
quick
stream
and-
and
there
is
a
screen-
a
screen
screen
going
running
simultaneously,
and
I
think
that
this
is
the
the
main
thing
to
see.
What
is
the
effect
of
of
a
new
reno
over
the
stream.
But
new
reno
is
kicking
in
because
there
is
another.
F
F
But
yes,
I
think
that
we
need
to
to
test
first.
What
is
a
the
what
happens
when,
when
we
have
a
new
reno
or
two
one
screen
stream
and
one
quick
stream
with
a
that,
it
is
a
competing
about
the
bandwidth
of
the
on
the
same
new
reno
transport
and
having
a
one
transport
with
a
new
renault
and
the
one
transfer,
with
a
with
a
stream
alone.
M
F
B
M
Yeah
hi,
so
we
have
not
done
any
new
experiments
today.
We
just
like
to
present
an
update
on
our
draft,
which
we
implemented
last
july,
and
we
have
basically
done
a
couple
of
restructures
in
the
last
weeks
and
months
and
two
versions,
and
I
would
like
to
talk
about
the
main
sections
we
have
on
the
draft
now.
M
So
the
first
one
is
about
encapsulation
and
I
think
the
biggest
slide
we
have
added
is
that
we
included
a
version
for
rtp
over
quick
streams.
Now
and
previous
versions
was
only
datagrams,
and
that
was
also
what
we
had
in
the
tests
we
presented
the
last
two
things
and
the
version
for
rtp
over
quick
streams
now
specifies
that
one
stream
is
used
for
one
application
data
unit.
M
What
what
we
have
from
the
layer
path
is
that
we
have
some,
I
guess,
types
which
are
different
for
different
types
of
data
and
when
we
want
to
put
that
into
an
rtp
packet
and
to
the
quick
screen.
We
just
say
that
there's
or
that
we
put
one
of
the
units
which
comes
from
the
player
above
into
the
rtp
packet
and
only
one
rtp
packet
on
one
stream
and
then
afterwards
the
stream
has
to
be
cancelled.
B
N
B
M
M
M
This
mostly
works
for
receiver
reports,
next
ecm
congestion
control
feedback
and
some
parts
of
extended
reports,
and
then,
of
course,
in
the
future,
if
there
are
more
rtcp
packet
type
definitions
that
can
be
extended
by
future
mappings
and
for
a
few
other
packets
one.
Second,
it
like
read
sender
reports,
for
example,
and
a
lot
of
application
layer
control
packets.
This
cannot
easily
be
mapped
too
quick,
and
in
that
case
we
of
course,
don't
need
to
use
rtcp
what.
B
M
Yeah
exactly
so,
when
the
sender
sends
sr
to
the
receiver
or
the
media
receiver,
he
basically
does
that
to
provide
some
timing
information
and
we
cannot
easily
map
this
timing,
information
to
quick
connection
statistics
and,
of
course
the
sender
report
also
includes
receiver
report
afterwards,
then
that
is
the
same
as
the
receiver
report.
Above.
M
Next
slide,
I'm
still
seeing
the
old
one
thanks
for
congestion
control.
We
also
restructured
a
bit
and
added
more
information
about
how
congestion
control
can
be
done
for
or
in
different
options.
We
give
the
sender
the
choice.
How
to
do
this
and
the
first
option
we
included
is
to
do
congestion
control
only
at
the
quick
layer
and
that
quick,
ideally
lose
use.
M
M
So
then
we
have
some
signaling.
We
included
in
our
first
draft
0
last
year,
section
on
sdp
signaling,
which
we
have
not
updated
since
and
now
there's
also
spencer
strat,
which
is
going
to
present
later.
So
we
didn't
focus
on
updating
our
section
on
this
anymore.
That's
that
talk
to
spencer
about
what
actually
need
to
be
signaled.
M
M
M
M
Yeah,
I
one
I
think,
you're
talking
about
both
in
the
same
connection
right.
I
think
that
was
one
idea
actually
why
we
kept
the
flow
identifier
not
only
to
demultiplex
different
rtp
streams,
but
also
to
demultiplex
between
different
applications
running
on
the
same
application
and
one
question
we
have
as
a
discussion
point
in
our
draft
is
how
this
flow
identifier
can
be
managed
efficiently
between
different
applications,
because
I
think
http,
3
datagrams
also
use
the
flow
identifier
and
if
everyone
defines
their
own
way
to
demo
detects
different
flows.
O
So
you
mentioned
that
do
not
use
timing,
information
from
rtcp
reception,
so
does
that
mean
like
sometimes
rtcp,
also
supports
feedback
messages
such
as
custom
feedback
messages
such
as
viewport
information
and
other
stuff?
So
sometimes
we
may
also
have
information
like
we
probably
need
in
a
viewport
from
certain
time
onwards,
or
something
such
kind
of
timing.
Information
may
be
incorporated
into
the
rtcp
custom
feedback
messages,
so
is
it
just
like
you
just
ignore
the
rtcp
packet
receiving
time
or
even
the
time
information
provided
in
the
rtcp
packets
also
was.
M
We
try
to
map
the
contents
of
the
rtcp
packets,
for
example,
for
congestion
control
feedback,
which
says
that
one
specific
rtp
packet
arrived
at
the
receiver
at
a
certain
timestamp
and
we
try
to
map
this
to
connection
information
from
the
quick
layer.
So
if
the
quick
has
information
about
that
a
certain
packet
arrived,
then
we
can
get
that
in
from
the
quick
connection.
Instead
of
sending
another
rtcp
packet
containing
this
information,
it's
not
directly
about
rtcp
packet,
timestamps.
E
M
Yeah,
that's
the
last
slide
we
have
so
we
would
do
a
few
more
updates.
We
have
which
we
mentioned
above
and
then
security
considerations
and
ayanna
registrations
are
still
missing
and
then
the
next
step,
which
would
be
maybe
the
working
group
adoption,
is
something
yeah.
We
would
like
to
ask
them
to
get
into
discussion
if
that
is
something
that
might
want
to
adopt.
B
A
P
Can
you
hear
me
yes,
yeah,
okay,
good,
I
I
believe
the
the
the
question
for
working
with
adoption.
Actually,
since
we
are
talking
about
the
minimal
security
consideration
section
and
in
diana
registrations,
mostly
plus
some
minor
updates,
I
wonder
whether
we
can
actually
get
a
get
a
sense
right
away
and
I'm
not
sure
whether
we
actually
do
need
to
wait
for
an
update
of
the
draft
since
the
fundamental
aspects.
Don't
change,
of
course.
Certainly
fine.
P
E
E
But
since
we
haven't
adopted
this
draft
or
any
other
draft,
that's
not
actually
a
good
plan
for
them.
So
my
my
from
my
point
of
view,
this
draft
is
certainly
in
shape
for
us
to
use
it
as
the
basis
for
the
working
group
to
work
on
it.
So
I
would
encourage
you
guys
to
ask
the
question
earlier
rather
than
later.
Thank
you.
Q
Yeah
good
morning,
can
you
hear
me
and
see
me
before
I
launch
in
to
the
ether?
Yes,
okay,
thank
you
so
good
morning
my
name
is:
will
my
co-chair
yaniva
was
going
to
do
this
talk
but
he
got
covered
yesterday.
I
got
covered
three
weeks
ago,
so
I
am
the
lesser
of
the
covert
inflicted
in
our
group.
So
I'm
going
to
do
this,
so
thank
you
very
much.
This
is
we're
coming
to
you
as
the
w3c
web
transport
group.
Q
Q
So
we
really
want
to
know
if
rtp
over
quick
can
satisfy
this
use
case,
and
if
the
answer
to
that
is
yes,
then
what
measurements
need
to
be
made
available
and
will
selectable
congestion
withdrawal
be
required?
So
mattis's
prior
presentation
is
actually
very
very
relevant
to
these
questions.
We
have
additional
slides
and
then
we're
going
to
come
back
to
these
questions
later.
So
if
we
can
go
to
next
slide,
please.
Q
Q
There's
copying
happening,
there's
queuing
and
buffering
happening
from
the
the
the
streams
that
the
what
wg
streams
say
that
might
come
from
a
web
codex
implementation
into
the
send
queue
for
web
transport
into
either
streams
or
or
datagrams,
and
the
api
is
no
visibility
into
the
transport
layer.
We
have
an
interface
for
streams.
We
have
an
interface
for
datagrams
next
slide.
Please.
A
One
was
the
information:
that's
in
rfc
888,
section
three
describing
inform,
for
example,
feedback
info
that
was
relevant
potentially
to
these
low
latency
congestion,
control,
algorithms,
and
you
see
here
packet,
arrival
times,
ecm
markings
flows
and
then
draft
angle
bart,
which,
in
its
o2
version
section
5.1,
also
talks
about
metrics
that
they
were
using
to
compute
the
bandwidth
estimation,
which
is
potentially
relevant
some
of
the
same
things.
You
know,
departures,
arrivals,
rtt
estimations
from
the
quick
stack
nacn.
Q
And
here
we
see
what
we
have
today
in
terms
of
stats
accessible
to
the
javascript
client.
So
it's
it's
at
aggregate
level
bytes
sent
packet
sent
in
total
packets
lost
number
of
streams
by
century
siege,
you'll
notice.
We
did
actually
copy
out
the
the
rtt
variants.
Aside
from
the
latest
rtt,
we
do
have
smooth
rtt
variation
and
min
rtt
with
the
same
algorithms
used
to
calculate
those
and
on
the
datagram
side
we
just
have
expired.
Outgoing
dropped
incoming
lost
out
going.
Q
So
what
we're
missing
is
any
explicit
congestion
notification,
ack
info
the
latest
rtt
and
information
about
packet
arrival
and
departure,
because
we're
we're
observated
away
from
the
actual
protocol
next
slide,
please.
So
these
are
our
core
questions,
and
maybe
we
should
just
do
them
one
at
a
time
do
rtt
measurements
need
to
be
adjusted.
I
I
guess
the
bigger
question
here
is:
is
it
actually
feasible
that
a
javascript
application
will
be
able
to
either
apply
its
own
congestion
control
or
work
in
cooperation
with
a
browser
user
agent?
That
is
actually
managing
the
quick
connection.
Q
And
it
seemed
from
what
matters
just
presented,
that
the
answer
might
be:
yes,
that
you
could.
You
could
have
a
default
congestion
control
working
on
quick,
the
given
enough
information.
The
application
in
this
case
javascript,
could
implement
scream
or
another
protocol
and
be
able
to
meet
these
requirements.
Is?
Is
that
in
fact
feasible
if
the
application
is
javascript
in
a
browser.
M
So
I
think
it's
hard
to
answer
specifically
for
javascript
in
the
browser
our
tests
used,
not
javascript.
We
did
like
we
had
access
to
the
quick
stack
and
everything
in
a
separate
application,
so
maybe
some
tests
on
this
would
be
good
to
experiment
with
the
javascript
application
in
a
browser
with
their
specific
environment
can
implement
this
and
whether
this
works
as
well
as
it
did
for
our
experiments
and
the
ones
they
represented
earlier.
Q
That
would
be
very
interesting,
and
in
fact
that
is
our
request.
We
do
not
have
experimental
or
research
access
within
our
group
and
they're
they're,
individuals
and
and
organizations
within
this
group
would
do
so.
It's
a
clear
request
to
make
and
to
use
the
web
transport
it's
available
in
chrome
today,
and
there's
also
a
a
server
implementation
to
see
and
in
the
short
term,
basically
provide
feedback
as
to
what
would
be
the
necessary
minimum
information
to
be
relayed
to
the
to
the
via
the
browser
to
the
javascript
application.
Q
M
I'm
not
sure
if
rtt
measurement
is
that
helpful
anymore.
We
included
that
in
the
first
version
of
our
draft,
but
I
it's
been
now
not
that
sure
anymore.
If
that
is
really
that
necessary,
we
included
it
because
we
thought,
if
the
congestion
control
algorithm
running
on
in
the
application,
only
uses
the
other
information
to
calculate
their
own
rtt.
M
Then
we
can
give
it
directly
from
quick,
but
I
think
what
is
more
important
to
these
algorithms
now
is
to
have
information
about
packet,
departure
and
arrival,
or
maybe
even
something
like
one-way
delays
between
departure
and
arrival.
That
could
also
work,
I
think,
but
maybe
some
people
with
more
insight
to
other
algorithms,
congestion
control,
algorithms.
I
can
say
more
about
that.
J
From
kind
of
independently
working
on
the
congestion
control,
algorithms,
not
necessarily
quick
related,
you
can
do
it
from
javascript.
You
just
need
to
get
the
aggregate
information
about
packet
arrival
you
either
as
a
set
of
inter-packet
arrival
delays
as
an
array
or,
if
that's
too
complicated,
you
can
even
get
away
with
getting
the
like
sum
of
squares
and
sum
of,
and
basically
in
the
in
the
average,
because
that
will
let
you
calculate
essentially
like
a
standard,
deviation,
etc
for
any
given
interval.
J
H
Q
Our
last
question
on
this
slide,
which
is
okay.
We
we
realize
we're
gonna,
we
have
competing
or
not
compete.
We
have
congestion
control,
that's
already
present
and
we've
thought
about
having
a
constructor
in
the
web
transport.
Sorry
an
argument
in
the
web
transport
constructor
that
would
hint
to
the
user
agent.
That's
managing
the
connection
that
we
wanted
to
shift
to
a
different
mode
of
congestion
control.
H
Q
Q
Q
We
can
make
a
generic
entry
called
low,
latency
and
then
later
on
through
experiment,
we
could
determine
that
it's
a
certain
algorithm,
but
if
no
algorithm
is
likely
to
ever
satisfy
that
requirement,
then
we
don't
want
to
bake
in
an
api
argument
at
this
point
that
we
would
then
have
to
remove
later.
That
would
be
that.
A
R
Yes,
thank
you.
So
a
lot
of
things
have
been
discussed
already
now,
while
I
was
in
the
queue,
but
I
think
first
of
all,
mo
is
on
to
a
lot
of
things
that
that
I
was
thinking
about
where
it
really
matters
what
the
congestion
role
inside
the
browser
is,
and,
of
course,
I
think,
to
to
build
an
application
level.
Congestion
control
that
is
really
working
well,
a
circuit
breaker
would
be
the
best
option.
R
R
R
I
would
imagine
that
most
applications
that
want
to
use
web
transport
to
to
essentially
replace
webrtc
would
be
wanting
to
experiment
with
their
own
congestion
control.
Algorithms.
I
think
that's
that's
one
of
the
more
valuable
things
I
think
this
transport
could
expose
to
to
the
application
writers.
Q
R
R
Yeah,
so
I
I
think
it's
it's
possible
to
to
get
that
to
work
well
on
the
application
layer
and
to
decide
at
what
rate
to
send,
based
on
on
the
arrival
times
and
and
the
departure
times
that
that
I
think
it's
is
feasible.
Of
course
it
you
might
end
up
in
situations
where,
where
the
application
is
running
a
bit
too
slowly
and
therefore
you're
not
able
to
maximize
the
throughput
of
the
link.
F
I
think
that
the
idea
is
to
be
able
to
instead
of,
for
example,
as
we
have
seen
before,
the
experimentation
between
screamer
neurino
to
be
able
to
have
the
the
quick,
the
quick
transport
to
use
a
more
friendlier
er
congregation
controls
that
it
is
not
lost
based
but
latency
base.
So
I
think
that
this
is
idea
so
based
on
the
on
the
on
the
experiment
below.
J
So,
if
everything
works
correctly,
the
real-time
congestion
control
will
limit
the
bandwidth
more
than
what
the
default
implementation
should
do,
so
it
it
will
be
more
restrictive.
The
second
thing
like,
if
it's
feasible,
to
implement
it
in
the
javascript
level.
It
is
we
kind
of
played
with
that
a
bit
and
it
did
work
like
the
only
issue
is
like
you
need
to
expose
essentially
either
aggregate
information
or
exposing
from
like
you.
You
don't
expose
information
about
each
packet
individually.
J
Q
Is
that
is
the
batching,
the
batching,
the
time
base
for
the
batching
or
the
count
of
packets
over
which
you're
applying
your
averaging?
Would
that
have
to
be
flexible?
In
other
words,
should
that
be
part
of
the
api
to
say
I
want
my
average
packet
arrival
time
calculated
over
so
many
packets
or
could
the
browser?
Yes,
hey,
yeah,
we
define
a
metric
that
will
work
for
everyone.
Q
A
E
Yeah,
I'm
I'm
shooting
for
shooting
for
five
minutes.
Does
that
sound
excellent
nice?
So,
basically,
I'm
just
reminding
people
that
I'm
keeping
track
of
a
specific,
a
individual
track
specification
that
is
defining
the
stp
for
rgb
over
quick
and
then
I
am
so
that's
a
minimal
specification
and
I've
also
got
a
separate
github
repo
that
I'm
doing
broader
issue
tracking,
where
we
I'm
trying
to
limit
the
first,
the
first
the
work
I'm
doing
on
the
on
the
first
specification
to
boiling
a
small
amount
of
water.
E
E
E
E
Extremes,
datagrams
or
both
I,
I
am
not
seeing
any
convergence
about
about
people
saying
we're
only
going
to
use
one
or
we're
only
going
to
use
the
other
and
being
able
to
convince
people.
So
my
proposal
right
now
is
to
include
both
stream
and
datagram
and
the
sdp,
and,
like
I
say,
that's
where
that
is
and
like
I
said,
I
note
that
I'm
using
the
inglebart
draft
as
the
basis
for
my
work
so
adopting
it
would
be
awesome
soon.
E
So
am
I
getting
close
so
we
talked
about
congestion
control,
so
we
have.
We
have
basically
a
lot
of
bad
ideas
that
I've
even
crossed
out
already
and
where
I
think
we
are
right
now
is
exploring
whether
signaling
anything
quick
about
anything.
We
need
to
do
differently
at
the
quit
level.
For
congestion
control
is
a
problem
in
practice.
You
know
admittedly
limited
testing,
it
hasn't
been.
If
we
find
out
an
additional
testing,
we
can
come
back
to
that
one.
B
N
Let
me
just
push
on
so
a
quick
background,
so
we
introduced
this
topic
first
in
february
and
as
a
reminder,
the
v3c
is
kind
of
compressing
the
video
scene
into
different
bit
streams
once
encoded
with
video,
encoders
and
ones
with
encoded,
with
d3c
encoder,
which
is
just
an
encoder
for
the
atlas
metadata,
and
it
found
it
very
closely
resembles
how
video
is
used
as
well
like
in
terms
of
the
high
level
syntax.
It's
also
based
on
now
units
next
slide.
Please.
N
We
also
looked
into
the
stp,
but
based
on
the
discussion
that
took
place
on
vbc
stp
examples
and
such
we
felt
that
it's
fairly
okay
to
be
very
limited
in
that
regard,
and
if
people
want
to
see
more
examples
in
in
in
the
stp
that
for
the
sdp
that'll,
that's
just
fine.
Let
us
know
we
also
received
a
little
bit
of
public
feedback
regarding
the
missing
acronyms
and
that
we
also
reflected
in
the
next
version.
N
Next
slide,
please
for
the
next
steps.
We
appreciate
a
bit
more
feedback
and
you
can
do
this
directly
on
the
github.
That's
linked
here
on
these
slides
and
we
will
be
continuing
to
update
the
draft
based
on
this
received
feedback
and
we're
also
looking
for
additional
authors
or
contributors
and
definitely
with
value
input
from
the
rtb
payload
format.