►
From YouTube: IETF115-AVTCORE-20221108-0930
Description
AVTCORE meeting session at IETF115
2022/11/08 0930
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
C
A
A
A
E
A
All
right,
so,
let's.
A
A
It
also
lets
you
join
the
mic
queue
for
using
the
virtual
mic
if
you're
using
the
full
client,
please
keep
audio
and
video
off
and
wear
a
mask,
except
when
speaking
and
even
if
you
choose,
while
speaking
remote
participants,
please
keep
audio
and
video
off
unless
you're.
Actually
speaking,.
A
For
remote
participants,
here's
the
tips
on
how
to
use
the
Medico
client
I.
Remember
you
need
to
actually
enable
your
audio
and
call
it
on.
You
can
turn
on
your
video
if
you
want
it's
helpful,
but
the
important,
but
you
have
to
turn
on
the
audio
separately
or
we'll
see
you
about
hear
you,
which
is
usually
not
that
useful
here
are
some
links,
no
well.
A
You've
all
had
to
click
through
this
to
be
here,
but
just
in
case
reminder
of
everything,
the
code
of
conduct
and
the
various
IPR
policies,
emphasizing
particularly
the
code
of
conduct
these.
If
you
are
aware
of
any
problems
along
these
lines,
please
call
either
contact
me
if
this
is
related
to
this
working
group
or
the
onputs
team
Mass
policy.
Please
wear
your
mask
when
in
meeting
rooms,
except
when
actively
eating
and
drinking
or
speaking
at
the
microphone.
A
If
you
need
a
mask
I
think
it
really
hears
the
math,
but
if
you
need
a
mask,
we
have
some
up
here.
If
your
mass
breaks
or
something
here
are,
the
notes
on
this
chairs
are
me
and
Bernard.
Bernard
is
remote.
Today,
I'll
keep
an
eye
on
the
chat,
but
if
other
people
can
in
case
I'm
distracted
that'd
be
good
and
we
have
magnets
taking
notes.
A
A
Yeah
our
agenda:
if
anybody
has
any
comments
on
anything
they'd
like
to
tweak
or
change
or
ADD,
you
know,
let
us
know
speak
now
or
interrupt
as
we
go.
A
We
have
some
things
in
our
of
the
editor.
We
have
one
thing
in
Miss,
ref
frame
marking.
Well,
we
still
need
that
revised
draft,
for
that
MO
is
nodding.
So
just
reminder
demo.
A
Working
group,
The,
Working
glass,
call
you
completed
the
the
skip
draft
we've.
There
was
a
revised
draft
on
you
know,
based
on
the
various
director
at
Malik
and
reviews.
A
Reviewers
could
have
been
contacted
to
make
sure
they
like
the
changes
so
983.
This
did
this
working
class.
Call
that's
on
me
to
do
the
work
with
the
write-up
which
I'm
sorry
I
didn't
get
to
get.
I
will
try
to
do
that
soon.
A
There
was
an
there
was
a
call
for
adoption
game
State
over
our
RTP.
There
was
not,
there
were
hardly
any.
There
were
only
two
responses,
one
of
which
was
from
a
co-worker
of
the
proponent,
so
we
didn't
feel
like
that
was
terribly
exciting.
Colin.
Do
you
wish
to
speak?
Are
you
still
interested
in
doing
this,
and
can
you
get.
F
I
mean
there's
it's
moving
to
multiple.
You
know
companies
sort
of
looking
at
this
and
using
it
at
this
point
and
I
mean
I.
Think
the
real
the
the
most
interesting
comment
really
is
that,
like
the
part
of
negotiating
the
the
defining
the
media
container,
it
sure
this
working
group
would
be
happy
to
do
it
if
there
was
a
document
done
somewhere.
That's
like
like
here's,
the
format
itself
and
but
doing
the
format
in
this
working
group
I
believe,
is
within
our
Charter
technically,
but
is
of
no
interest
whatsoever
to
anyone
in
this
working
group.
F
It's
completely
independent
from
anything.
That's
done
so
Dispatch
sent
me
here
here
has
not
really
rejected
me
to
go
back
to
dispatch
and
say
I
can't
do
this
here,
but
it
never
made
sense
for
it.
I
didn't
think
it
should
be
done
here.
Okay
and
so
I'm,
not
I'm,
not
sad
about
that
and
I
agree
with
the
you
know,
suhas
and
his
sock
puppet
fluffy
both
like
this
is
sort
of
irrelevant,
but
you
know
so
I
I,
like
I
I'm,
not
I,
I'm,
not
denying
the
response.
There
was
also
no
responses
against
it.
F
But
it's
it's
that
there's
not
a
strong
interest
or
strong
expertise
in
defining
a
game
format
in
this
working
group
is
true
right,
so
I
mean
what
do
you
think
you
should
like
as
a
chair
or
what
you
know?
What's?
What's
your
advice
to
me,
I'm
trying
to
bring
some
new
work
that
is
actually
sort
of
relevant
to
the
ITF?
What
do
you
tell
me
to
do.
A
I
mean
I
think
the
issue
is
more
the
expertise
than
the
interest
like
I.
Don't
know
anything
about
game,
States,
I,
don't
I,
couldn't
tell
you
if
we
get
it
right
or
not
and
I,
don't
think
anybody
very
many
people
in
this
room
have
that
expertise
either.
So,
if
you
can
find
the
people
who
do
have
the
expertise
and
say,
are
you
willing
to
participate
in
this
working
group?
For
you
know
how
long
it
takes
to
do
this
work
that
and
you
know
and
they're
interested
in
it,
then
you
know.
A
F
So
look
I'm
not
really
sure
what
to
do
with
it
next,
but
I
feel
a
little
bit
like
I've
been
bounced
around.
It's
been
a
year
now
and
no
one
has
a
location
at
ITF
that
could
possibly
do
this
work
and
that's
not
your
fault.
It's
not
this
working
group's
fault,
but
it
is
the
reality
of
what's
going
on.
H
So
David
scanazi
internet
architecture
board,
so
I
have
not
read
the
draft,
but
just
from
a
like
high
level.
Just
I
want
to
start
with
a
clarification
question
for
Colin,
like
what
is
the
benefit
for
you
in
having
this
as
an
RFC,
as
opposed
to
a
blog
post,
a
Wiki
page,
whatever.
F
H
H
So
oh,
the
80s
coming
I'm
running
away,
I'm
running
away.
C
C
So
I
would
gladly
yield
to
the
error
director,
of
course,
but
since
he
goes
away
I,
you
know,
I
I
was
grumbling
here
in
the
corner
saying
this
is
not
the
idf's
business
and
I
I
continue
to
believe
this
is
not
the
itf's
business.
C
It's
I
mean
if
we
Define,
if
we
Define,
making
the
internet
better
or
whatever,
as
as
basically
encompassing
everything
that
can
be
coded
into
bits
and
being
sent
over
over
a
while
or
Wireless
to
some
other
place
using
a
protocol
roughly
a
like
IP,
then
of
course
it's
the
itf's
business,
but
I
think
this
is
a
classical
example
of
often
often
often
coding
technology,
even
if
it's
mostly
metadata-ish
type
of
stuff,
and
that
should
go
to
comedies
who
know
what
they
are
doing
in
this
field,
and
that
would
be
MPEG.
C
That
would
be
aom.
That
would
be
those
places
and
not
here
yeah
we
have.
We
had
the
the
vast
majority
of
the
people
running
around
here.
Don't
understand
this
stuff
nor
care
about
it.
Thank
you.
F
So
I
would
like
to
reply
to
Stefan
on
this,
though,
but
Stefan,
you
said
exactly
those
same
words
when
we
said
we
wanted
to
do
an
audio
codec
in
ITF
called
Opus
is
now
the
most
used
codec
in
the
internet.
You
said
exactly
those
same
words
when
we
wanted
to
publish
av1,
which
is
one
of
the
most,
not
sorry,
not
av1
vp8,
which
we
did
through
Independence
dream
back
to
the
recommendation.
F
To
me,
it's
one
of
the
most
used,
video,
codecs
and
aom
has
no
interest
in
doing
this
game
type
move
data,
it's
very
different
than
the
type
of
other
work
they
do.
This
is
totally
the
wrong
place
to
do
it.
Mpeg
has
no
interest
in
this
type
of
minimal
compression.
We've
discussed
that
it
is
this
is
this
is
more
like
a
Json
format.
You
could
maybe
say
w3c
should
do
this
or
you
know
the
open
spatial
Consortium
or
something
like
that,
but
those
places
that
you
recommend
they're
they're,
not
practical,.
C
So
you
know
I
go
to
these
impact
meetings.
As
an
example,
I
haven't
seen
you
guys
going
there
and
proposing
anything
like
that.
So
don't
say
it
they're,
not
interested,
because
I
wouldn't
know
I'm
also
going
to
aom.
Also,
quite
often
and
and
I
mean
you
go
there
to
the
to
the
Cause
right,
I
haven't
seen
the
Cisco
initiative
over
there
either.
So
don't
say
they
are
not
interested
I.
Don't
think
you
know
right
or
if
you
know,
then
at
least
it
wasn't
publicized
in
any
in
any
significant
way.
C
I
agree
that
Opus
was
a
success.
I
disagree
that
it
was
an
ITF
success.
It
was
a
success
of
a
handful
of
people
who
used
the
ITF
as
a
venue,
all
the
others.
I
don't
even
want
to
go
there,
but
Opus
was
was
not
the
classical
collaborative
effort
of
creating
a
protocol.
It
was
just
a
handful
of
people
who
were
talking
to
each
other
anyway,
all
the
time
so
I
I,
I
I
still
wouldn't
want
to
see
this
organization
becoming
a
an
an
organization
that
steps
on
other
people's
Turf
without
need.
Really.
B
Hi
hi
Colin
Harold
may
be
about
to
say
the
same
thing,
but
I
recall
having
a
discussion
in
the
w3c
about
the
game,
State
API,
and
what
to
do
with
it,
how
to
how
to
send
stuff
over
the
network
from
that
API.
So
you
may
have
something
there
Cullen
about
the
w3c
and
they
have
had
game
related
workshops
before
so
that
that
might
be
one
way
to
find
some
of
these
people
just
a
thought.
A
I
I
The
problem
here
is
really
that
this
group
has
set
this
itself
up
as
a
gatekeeper
for
registration
of
RTP
formats.
I
I
The
alternatives
for
this
group
are
basically
lead,
follow
or
get
the
hell
out
of
the
way
so
where
this
document,
where
this
the
technical
details
of
this
proposal,
needs
to
be
discussed
well,
any
any
group
consists
of
10
people,
no
matter
how
many
people
who
are
in
it
and
that's
another
question.
But
if
this
group
is
a
gatekeeper
for
registering
stuff
that
needs
RTP
payloads
well,
this
group
needs
to
accept
that
that
it
either
needs
to
lead,
follow
or
get
the
hell
out
of
the
way.
J
C
A
direct
response
to
Harold
I
tend
to
agree
and
I
have
agreed
that
the
payload
format
in
this
email
that
cited
there
I
have
agreed
that
the
payment
format
itself
is,
in
my
opinion,
clearly
within
the
charter
of
this
group
and
I,
wouldn't
at
all
stand
in
the
way
of
doing
that.
However,
there
is
a
format,
a
media
format
defined
in
the
same
specification
and
that
that
simply
shouldn't
be
done
here.
So
if
that
were
done
somewhere
else
in
parallel
or
sequentially
I,
don't
care
right.
C
I
I
wouldn't
stand
here,
yep,
it's
the
the
problem
is
that
this
is
a
document
that
does
what
traditionally
has
been
done
in
two
different
documents,
one
being
the
actual
media
technology,
the
other
being
the
payload
format,
including
the
registry,
and
that
obviously
is
well
within
the
charter.
Here
go
go
for
it!
No
no
trouble
with
that.
Thank
you.
A
E
Buying
this
question
yeah
react
to
how
I'll
say
about
the
skate,
keeping
when
it
comes
toxicity
failure.
Foremost.
I
would
note
that,
first
of
all,
as
Stefan
said,
it's
like
it's
the
format
versus
the
RTP
payload
format
for
the
two
different
aspects
here
and
the
second
one
is
that
actually
any
OTP,
the
only
thing
you
need
to
register
a
code
points
for
r2p
payloader
formats
is
a
stable
specification.
You
don't
need
to
go
through
this
group
at
all,
but
that's
I
mean
we
encourage
it.
E
We
have
the
expertise
and
we
want
to
provide
input
Etc
about
that
proposal.
So
that's
I
mean
I.
I
asked
a
temporary
a
little
bit
so,
but
I
understand
the
struggle
here
to
actually
Define
a
format
when
you
have
a
hard
time
finding
body,
but.
K
L
Mercenary
I,
don't
think
this
is
just
about
registration
I
think
we
really
need
to
figure
out
if
there's
a
good
venue
to
have
the
discussions
for
this
kind
of
thing,
because
it's
not
just
you
know,
let
Khan
publish
something
that
only
Cohen's
going
to
use
the
the
the
core
aspect
of
this
is
you
know,
describing
things
and
there's
two
two
main
aspects
describing
you
know
meshes
or
geometrical
structures
efficiently
and
I
agree
with
Stefan
that
that's
the
purview
of
other
groups-
and
there
are
there-
are
you
know
other
groups
actively
working
on
this,
but
their
scope
is,
is
worlds
not
you
know,
small
telemetry,
so
they're
going
to
be
biased
towards
you
know
something,
that's
you
know
very
Compact
and
efficient
for
a
very,
very
large
object.
L
You
know
mesh
compression
for
an
entire
world,
not
for
five
points
or
something
like
that.
So
the
other
aspect
of
this
is
it's
also
more
like
you
know,
Telemetry
or
real-time
input
and
we've
we've
seen
other
requests
and
and
like
media
over
quick
about
use
cases
like
remote,
desktop
and
things
like
that.
How,
how
is
you
know,
input
whether
it's
you
know
human
input
or
some
other
form
of
input
going
to
be
carried
over
RTP,
and
this
is
just
one
specific
type
of
input.
L
This
is,
you
know,
polygonal
mesh
input,
but
how
you
encode
input
in
general
and
how
you
describe
it
is,
you
know,
is
also
you
know
something
that
needs
to
be
discussed
and
so
I.
Don't
think
that
it's
just
let's
just
register
something
and
and
get
it
out
there
and
nobody
else
will
ever
use
it.
I
think
we
need
to
really
think
about.
L
How
do
we
describe
you
know
simple
geometries,
and
how
would
we
also
describe
input
and
where's
the
right
place
to
to
have
conversations
about
those
two
things
and
there
is
work
at
Alm
and
MPEG
on
political
mesh
compression,
but,
like
I
said
it's
it's
for
compressing
worlds,
not
you
know
not
I
move
my
hand
an
inch.
This
way.
H
David
Scott
I
just
wanted
to
react
to
What
Harold
was
saying
so
forgive
me.
I
wouldn't
consider
myself
an
avt
core,
Enthusiast
I'm,
very
new
to
this
space
and
I.
Just
was
kind
of
walking
by
in
the
hallway,
but
I
know
Hawaiian.
It
works.
H
The
I
was
looking
through
the
RTP
Registries
and
all
of
them
have
a
registration
procedure
of
expert
review
or
specification
required
and
specification
required.
Me
means
expert
review
and
the
expert
has
verified
that
there
is
some
kind
of
a
spec.
The
spec
could
be
written
on
the
back
of
a
paper
napkin
that
you've
taken
a
picture
on
and
posted
on
your
website.
That's
fine!
H
It
is
actually
like
it.
The
specification
does
not
have
to
be
an
ITF
specification.
H
No
yeah
exactly
like
the
if
I
promise
that
I
will
keep
serving
that
picture.
Forever
on
that
URL
anyway,
like
the
the
ex
that's
the
expert's
purview,
but
that
does
not
mean
that
you
need
any
like
a
standard
track.
Rfc,
it
doesn't
mean
you
need
any
kind
of
RFC
like
the
simplest
way
is
a
draft
zero
zero
like
that
is
definitely
agree
accepted
as
a
stable
reference.
H
They
stay
on
the
archive,
so
this
group
is
not
actually
a
gatekeeper
to
any
of
these
Registries
and
similarly,
this
group
is
not
a
gatekeeper
to
create
a
new
registry,
so
I
think
as
someone
who's
done.
Something
like
this
before
the
two
options
here
is
telecon,
like
sure
we're
interested.
We
want
to
work
on
this.
Let's
do
it
here
or
we're
not
interested
just
go,
publish
it
on
the
independent
stream.
You
get
everything
you
want
and
all
right
win-win-win.
H
So,
like
the
the
only
reason
where
you
can
get
a
little
Ken
Block
is,
if
you
think,
okay,
this
is
so
harmful
that
we
want
to
use
the
INR
registry
as
a
way
to
tell
Colin
no,
no,
no
bad
bad
bad,
but
I.
Don't
think
that's
the
case
here.
People
are
just
saying:
Matt
shrug
so
I
think
there's
a
clear
path
forward
here
and
Colin,
but
does
that
work
for
you
I'm,
just
I'm
trying
to
help
but
yeah.
A
B
Yeah
I
think
we
should
close
the
line
but
yeah
to
follow
up
on
what
David
just
said.
I
think
the
question
is
Cullen.
What
Ayana
policy
would
you
want,
and
you
know
who,
if
it's
expert
review
required?
Who
would
the
expert
be?
Do
you
have
a
volunteer
in
mind
and
how
do
you?
How
do
you
want
this
to
work?
I,
wouldn't
worry
about
the
working
group
or
getting
it
published.
Just
think
about
how
you
want
to
set
it
up.
Do
you
have
any
comments.
F
B
Yeah,
so
actually
you
really
don't
need
that
much
expertise
in
the
working
group.
All
you
need
is
a
is
a
document
that
creates
the
registry
with
your
your
it
kind
of
Will
self-function
on
its
own.
Once
you
do
that
right
with
the
expert
review
and
the
the
Ayana
policies.
F
F
What
I
don't
want
to
do
is
go.
Do
it
through
the
independent
stream?
Have
it
go
to
the
isg
review
and
have
them
tell
me
this
is
clearly
in
the
scope
of
this
working
group,
because
it
is
in
the
scope
of
this
working
group's
Charter,
which
is
a
valid
reason
for
the
isg
to
block
the
independent
stream
from
publishing
this
document.
I
do
not
want
to
do
that,
so
you
guys
have
to
tell
me
in
the
minutes
that
you're
recommending
I
take
it
to
the
independent
stream
or
I'm
not
taking
it.
There
yeah.
A
It
okay
is
there
anybody
to
do
do
we
want.
Does
anybody
object
just
telling
Colin
take
us
to
be
an
independent
stream,
and
this
group
has
no
problem
with
publishing
it
as
independent
stream.
Hearing
no
objection,
let's
put
that
in
the
minutes,
so
that
if
anybody
at
the
iesg
complains
you
can
point
them
at
these
minutes.
A
Yeah
I
hope
it
doesn't
make
that
long
either,
but
if
yeah
yeah
okay,
so
that
is
Murray
is
kind
of
like.
A
A
A
All
right
all
right,
much
less
controversial
we're
doing.
We
had
a
CFA
on
on
the
RV
trailer
for
b3c.
A
We
had
several
affirmative
responses,
saying
we
like
to
do
it
so
I
think
the
conclusion
is
we're
going
to
adopt
that
Bernard.
Is
that
I
think
you
were
writing
that?
So
do
you
want
to
confirm
that
yeah.
B
I
mean
it
looks
to
me
like
there's
consensus
to
adopt.
If
are
there
any
objections
in
this
room.
B
If
not,
then
the
author
should
just
submit
a
draft
ietf
avt
core
doc.
A
All
right,
we
are
still
have
a
CFA
going
on
the
rgcp
messages
for
green
metadata.
The
draft
is
available.
That's
going
to
November
30th.
If
you
have
any
opinions
on
that.
Please
comment
on
the
list
or
if
you
have
something
you
need
to
say
here
about
it,
let
us
know,
but
that
seems
only
if
it's
you
know
urgent,
okay
and
next
up
is
RTP
for
skip.
G
Here
I
am
good
morning,
so
go
through
pretty
quickly
here.
Let's
take
in
not
a
whole
lot
to
report,
but
we
did
submit
the
revision
03
draft
in
next
slide,
not
on
October
17th,
responding
directly
to
reviewers
questions
again,
revise
the
abstract,
obstruct
introduction
and
mapping
to
STP
sections
submitted
it
as
XML
file.
G
I.
Think
we've
resolved
this
issue
before
I
got.
It
keeps
coming
up
and
all
these
reviewers
whether
the
skip
210
referenced,
is
a
normative
or
informative
reference,
and
if
we
need
to
bring
that
issue
up
again
or
not
or
just
I,
think
we've
decided.
The
group
has
decided
us.
F
Queue,
oh
I
just
had
myself
I
I
think
it
is
really
important
that
remains
an
informative
reference
and
not
necessarily
for
this
specification,
but
in
general,
because
we've
gone
through
this
whole
argument
before
and
the
reason
why
is
it
gets
you
out
of
a
complex
it?
It
means
that
if
there
is
I'm
not
talking
about
Skip
I'm
talking
about
some
other
codecs,
if
there
was
IPR
on
the
codec,
there's,
not
necessarily
IPR
on
this
and
I
think
that's
a
really
I
think
that
should
be
a
fundamental
policy.
I.
F
G
Most
of
them
are
ready
with
issues
I,
guess
more.
So
I
guess
next
slide.
Just
to
talk
about
what
to
do
about
requesting
another
formal
review
to
have
all
the
reviewers
be
satisfied
with
the
current
state
of
the
document
and
allowing
it
to
go
forward.
Did.
B
They
respond
to
you
in
each
case,
I
mean
that's
I,
don't
know
that
they
need
to
re-review
it
just
we
need
I
I,
just
basically
what
I
want
is
just
a
citation
from
these
people
saying
yeah,
I'm
fine
and
you
adjust
my
comments.
That's
all.
B
B
Yeah,
just
maybe
send
one
last
episode,
you
know,
that's,
that's
it!
You
can't.
We
can't
haggle
them
forever,
right,
right,
okay,.
A
Resolve
anything
to
say:
okay,
all
right
and
that's
all
that's
the
only
side.
You
have
all
right
so.
C
Yeah
on
the
subject
on
the
subject-
and
this
is
this-
is
not
at
all
going
power
down
over
here-
I've
noticed
recently,
I
mean
over
the
last
three
years,
or
so
a
real
increase
in
bureaucracy.
You
have
to
sign
this
off
and
the
sign
off
has
to
be
recorded,
and
can
we
cut
down
a
little
bit
on
that?
Please
it's
it's
getting
frankly,
really
annoying
it
I
mean
this
is
this?
Is
we're
not
that
close
from
ISO
style,
a
sign
of
procedures?
Now,
thank
you.
Yeah.
B
Well,
that
that
is
a
good
point,
Stefan
the
the
amount
of
questions
you
now
have
to
the
the
size
of
the
public
questions
has
kind
of
grown
enormously
in
the
just
in
the
last
six
months.
B
So
I
think
those
sentiments
are
good
ones,
but
for
this
purpose,
I
think
we've
we've
gone
through
enough
Hoops
to
write
the
public,
so
you
know
well,
if,
if
hassling
is
required
for
the
director,
it's
they'll
be
hassled
later
in
the
process,
but
I
think
you've
done
what
you
needed
to
do
Dan.
So
all.
A
B
Okay,
next
yeah,
so
at
the
interim
meeting
we
basically
talked
about
a
little
sandbox,
where
we
could
experiment
with
RTP
over
quick
in
JavaScript.
So
next
slide
there
were
some
Curious
observations.
B
A
few
things
were
that,
first
of
all,
the
glass
to
gas
latency
was
considerably
higher
than
the
measured
frame
rtt
and
there
was
noticeable
lag
when
you
went
to
high
resolutions
like
full
HD
at
30
frames
and
a
megabit
average
Target
I
was
measuring,
like
630
millisecond
glass
latency
within
our
frame
rtt
of
100
milliseconds.
B
The
other
thing
that
was
weird
was
that
we
didn't
observe
any
reordering
on
the
receiver,
I
think
in
hundreds
of
tests,
no
reordering
at
all,
so
that
raised
a
bunch
of
questions
about
what
was
going
on
exactly
why
it
wasn't
being
why
we
didn't
see
reordering
and
also
the
bandwidth
consumption
was
considerably
lower
than
the
average
Target
bit
rate,
except
for
a
weird
vp9
bug
where,
with
a
certain
with
variable
bit
rate
and
temporal
scalability,
with
three
layers,
it
sent
like
at
10
times
more
than
the
target
average
bit
rate.
B
We
I
think
finally
figured
it
out,
which
was
basically
that
you
have
to
be
very
careful
in
the
way
you
write
in
the
web
transport
API
in
particular,
it
is
not
recommended
to
a
weight
right
or
dot
write,
because
that
promise
returns
once
a
chunk
is
handed
off
to
the
quick,
send
queue
and
that
effectively
prevents
the
quick
stack
from
multiplexing
frames
or
streams
on
web
transport,
and
so
you,
you
suppress
the
concurrent
sending
of
P
frames
and
iframes,
and
that's
why
the
reordering
was
rarely
observed
on
the
receiver,
because,
basically,
you
were
sending
the
iframe
waiting
until
it
was
essentially
almost
sent
and
then
sending
the
next
keyframe
and
that
also
reduced
the
bandwidth
usage
by
stretching
out
the
delivery
times.
B
So
the
way
to
fix
that
is,
you
only
await
a
write
or
dot
ready
promise,
which
happens
as
soon
as
you
can
send
on
the
stream.
And
then
you
just
write
the
chunk,
and
then
you
call
writer.close
and
and
Dot
Bend
for
whatever
you
do
once
it's
closed.
B
So
once
you
do
that
the
frames
and
iframes
get
sent
concurrently,
I'll
show
you
some
some
graphs,
but
it
also
looks
like
this
results
in
more
rapid
congestion
window
growth
so
that
your
iframe
actually
gets
sent
with
fewer
rtts,
which
is
kind
of
interesting.
We
did
start
re,
observing
reordering
at
the
receiver,
so
we
had
to
do
a
reorder
buffer.
B
The
Jitter
buffer
is
actually
implemented
in
another
API.
It
seems
like
the
smoothing
is
now
occurring.
Also
the
video
looks
a
lot
smoother
yeah
and
that's
occurring
in
the
media
stream
track
generator
API.
B
So
that's
kind
of
interesting
between
this
reorder
buffer
and
that
smoothing
you
almost
you
seem
to
get
the
effect
of
a
Jitter
buffer
without
doing
hardly
any
work,
and
then
also
the
bandwidth
consumption
is
now
closer
to,
but
slightly
larger
than
the
average
Target
bit
rate
and
the
glass
to
glass
latency
is
considerably
lower.
B
It's
hundreds
of
milliseconds
lower
now,
and
particularly
you
can
run
now
the
demo
at
high
resolutions
with
complex
codecs
like
av1
and
it's
close
to
near
real-time
performance.
So
that
actually
is
pretty
good
news
for
things
like
ingestion,
video
ingestion
or
potentially
distribution
scenarios,
because
it
seems
to
work
pretty
darn
well
anyway.
B
B
So
this
is
an
example
of
comparison
of
before
and
after
and
if
you
click
on
the
before
you'll
get
the
the
code
that
that
runs
with
before
do
removing
these
bottlenecks
and
then
after
you'll
see
what
happens
afterwards.
B
But
one
of
the
interesting
things
in
the
after
is
is
it
does
look
much
closely
clustered
around
the
rtt
min
for
the
P
frames
and
then
the
large
frame
at
around
11
000
bytes,
is
probably
the
iframe,
and
the
other
thing
you
can
see
is
the
the
combination
of
well
there's,
basically
minimal
extra
delay
above
the
transmission
line,
which
kind
of
indicates
that
by
this
point
the
sea
wind
has
grown
to
be
able
to
send
these
11
000
bytes
in
one
rtt.
B
So
anyway,
the
the
bottom
line
of
all
of
this
is
that
it's
very
possible
to
do
interactive.
The
the
performance
of
RTP
over
quick
can
potentially
be
extremely
good
without
even
a
lot
of
effort
done.
This
is
entirely
in
JavaScript,
no
wasm
or
anything
like
this.
B
So
it
looks
like
you
can
get
interactive
performance
out
of
this
without
a
lot
of
effort.
Anyway,
that's
the
update.
B
Oh,
and
here
are
some
pointers:
if
you
want
to
learn
more
about
how
to
about
this
stuff
pointers
to
the
code
for
the
the
optimized
version,
the
old
version,
so
you
can
see
the
comparison
and
also
there's
a
web
codex,
only
demo,
which
has
no
transport
at
all,
and
at
this
point
the
the
one
with
network
transport
is
pretty
pretty
close
to
the
performance
of
the
no
transport
demo.
A
All
right,
thank
you,
Bernard.
Any
questions
on
this
we'll
move
on
to
Peter.
N
A
Oh
and
hold
on
Martin
Thompson
has
from
the
room.
I
was
just
giving
notice
about
the
talk.
Why
were
the
S
frame
tariffs
not
aware
of
this
he's
in
another
room,
a
long
way
away.
N
A
N
Just
reviewing
simple
things:
RTP
over
quick
allows
you
to
have
big
RTP
packets,
perhaps
a
whole
frame
in
one
RTP
packet
and
one
quick
stream
next
slide
and
S
frame.
Lets
you
encrypt
the
media
next
slide.
N
N
Now
someone
might
say
well
what,
if
we
just
use
S
packet
instead
of
s
frame
over
RTP
over
quick,
but
that
has
the
same
problem,
because
you
can
have
a
really
large
RTP
packet
using
S
packet
as
well,
because
when
you
have
a
really
large
RTP
packets,
like
with
quick
streams,
there
isn't
much
difference
between
this
from
a
nurse
packet,
because
you
basically
have
one
frame
per
big
RTP
packet
next
slide,
similar,
but
somewhat
different.
N
You
still
have
the
problem
if
you
do
RTP
over
quick
stream,
so
this
isn't
unique
to
quick
or
sorry
over
quick
datagrams.
This
isn't
unique
to
Quick
streams,
because
if
you
have
quick
datagrams,
you
can
have
slightly
larger
overhead.
So
when
you
translate
in
the
other
direction
from
RTP
over
UDP
to
RTP,
really
quick,
you
can
end
up
needing
to
be
packetized
to
make
it
the
payload
slightly
smaller.
So
it
fits
with
the
slightly
larger
overhead
next
slide.
N
So
a
summary
of
the
problem
is
that
with
RTP
over
quick,
you
can
have
big
RTP
packets.
You
can
have
MTU
differences
also,
and
these
require
repacketizing
by
repacketizing,
as
mentioned
in
the
year
to
be
a
quick
draft
is
codex.
It
may
be
codec
specific,
which
might
mean
a
string
specific,
and
this
can't
be
solved
purely
by
the
endpoints.
This
is
something
the
fiddle
box
needs
to
be
able
to
do
but
has
to
work
within
the
bounds
of
what
has
with
that,
with
s
frame
which
is
encrypted
next
frame
or
next
slide.
N
N
But
you
might
think
this
looks
a
little
bit
like
RTX,
where
there's
another
sequence
number
in
our
tx's
case,
it's
the
original
sequence
number,
which
is
used,
and
in
this
case
we're
using
the
S
frames
sequence
number,
but
we'll
do
it
multiple
times,
one
for
each
chunk.
So
next
slide
I'll
give
an
example.
N
You
can
see
there
one
zero
one
three
times,
one
zero
two
three
times
and
then
the
smaller
RTP
packets
have
normal
sequence,
numbers
one
two,
three
four
five
six
and
to
keep
track
of
how
to
put
the
chunks
back
together.
When
you
receive
them
all
the
chunk
indexes.
Let
you
know
what
we're
going
to
go.
N
E
N
Yeah,
that's
that's
a
drag,
but
there
are
two
different
ways.
We
can
do
that
and
the
way
I
have
it
written
down
at
the
moment.
We
use
the
marker
bit,
but
there's
a
slide
later,
where
I
have
there's
some
technical
discussion,
we
can
have
over
different
options,
but
before
we
get
there,
I
want
to
make
sure
we
decide
whether
this
whole
idea
is
worth
going
down
as
a
solution
for
us.
E
From
my
perspective,
I
think
considering
what
this
Frame
is.
Etc
you
you're
not
going
to
be
able
to
do
anything
better
than
you
just
take
the
whole
s
frame
shop
it
up
in
the
suitable
way
for
the
underlying
transport
and
and
doing
that
in
the
r2p.
Payload
performance
seems
to
be
the
reasonable
Way
Forward
here
about.
You
might
also
have
to
consider
if
you
need
a
if
the
shank
index
yeah,
if
it
only
started
there,
you
always
know
where
to
start
is
so
I
guess
it's
fine,
but.
N
Yeah
another
one
of
the
issues
that
we
trade-offs
we
can
discuss,
which
is
on
a
future
slide,
involve
whether
to
use
a
chunk
index
or
kind
of
derive
that
from
the
sequence
number
with
the
first.
So
there
are
different
options
we
can
have,
but,
like
I
said,
first
I
want
to
open
the
question.
If
we
go
to
the
next
slide,
perhaps.
K
Here
quickly,
you've
got
thanks,
Peter,
so
fundamentally,
I
kind
of
think
this
should
be
workable.
How
does
this
thing
work
with
cascaded
translators?
After
all,
you
are
creating
a
consecutive
index
sequence
and
I
suspect
if
you
had
a
requirement
to
re-do
the
whole
thing
at
a
second
stage
where
you
still
get
even
smaller
packets.
N
No
I
had
not
thought
about
that,
but
I
suppose
that
you
could
have
two
layers
of
it
where
this
smaller
one
gets
broke
up
into
even
smaller
ones
and
then
you've.
So
you.
K
Know,
but
just
needs
to
think
about
this
I
also
had
a
a
general
question
to
the
group,
maybe
also
to
Magnus
as
the
living
avt
directory
dictionary,
whatever
I
try
to
find
my
translators
have
existed
for
a
long
time.
So
in
that
regard,
MTU
size
considerations
would
have
needed
to
be
addressed
for
a
long
time,
but
looking
at
the
topologies
draft
I
couldn't
find
anything
that
I,
don't
think
the
term
MTU
even
appeared
in
that
document.
I'm
not
sure.
K
N
B
Well,
in
in
conferencing
it
was
there
we
have
seen
repacketization
and
it
is
as
as
was
described
in
the
RGB
over
quick
draft,
which
is
it's
codec
specific.
So
the
conference
server
can
repacketize
say
for
a
participant
with
a
lower
MTU
in
a
codex
specific.
K
A
Thanks
Peter
just
quickly,
do
you
have
more
for
your
slides.
N
L
Mozinary,
the
the
mechanics
of
of
the
chunking
seem
like
it
would
work.
Okay,
one
small
knit
would
be
I
think
should
look
into
having
chunk
offsets
instead
of
indexes.
I
think
you
know
a
lot
of
different
fragmentation
and
reassembly
techniques
go
back
and
forth
between
indexing
and
byte
indexing.
L
You
should
look
at
that
to
see
what
what
use
cases
work
best
for
you
there,
but
at
the
highest
level,
I'm
scratching
my
head
a
little
bit
about
the
the
purpose
of
this,
because
I
thought,
one
of
the
main
goals
of
s
frame
was
to
have
single
off
tag
for
some
media
for
some
large
media,
and
now
you
Dice
it
up.
L
However,
you
want
deliver
it,
however,
you
want
and
then,
when
it
gets
there,
you
still
have
this
one
big
large
auth
tag,
but
that
means
that
something
everything
delivering
that
in
in
the
middle
can't
authenticate
that
thing,
and
so
you
have
this
object,
that's
maintaining
State
across
all
of
your.
L
You
know
your
your
network,
that's
delivering
these
things,
and
so
it
seems
like
the
the
benefit
of
s
frame,
of
being
able
to
just
have
this
single
off
tag
over
a
large
Media
frame
and
now
you're
going
to
chunk
it
back
down
into
smaller
objects.
Are
you
going
to
authenticate
those
smaller
objects
as
well
and,
if
so,
wouldn't
that
defeat?
L
The
whole
purpose
of
you
know
where
you
started
from
the
first
place
of
of
consolidating
that
off
tag,
and
if
you're
not
going
to
do
that,
then
don't
you
run
the
risk
of
of
providing
amp
vectors
for
attackers
that
can
flood.
You
know
a
lot
of
unauthenticated
packets
to
to
to
a
lot
of
different
parts
of
your
delivery.
Network.
N
I've
always
viewed
the
purpose
of
s
frame
to
be
the
end
in
encryption,
but
if
you
want
to
do
hop
by
hop
authentication
of
the
whole
frame
using
S
frame,
a
middle
box
still
could
because
it
can
be
assemble
the
frame
from
the
chunks
if
it
wants.
It
would
add
some
latency
to
authenticate
that
before
forwarding
the
first
piece,
but
that
happens
the
same.
If
you're
going
to
read
the
entire
quick
stream
and
authenticate
it
before,
you
start
forwarding
the
quick
stream.
So
it's
kind
of
the
same
thing.
L
So
you
expect
the
chunking
to
be
purely
hop
context
with
no
no
end
to
end
guarantees
right.
N
Yes,
but
the
any
any
place
in
the
middle
Could
reconstruct
the
entire
frame
if
it
wanted
to
for
forwarding
the
pieces,
so
it
could
apply
the
end-to-end
guarantees
if
it
wants
just
like
it
could
by
reading
in
an
entire
quick
stream
and
then
sending
it
out,
but
if
it
doesn't
want
to
do
that,
it
can
just
afford
it
immediately.
So
it's
kind
of
up
to
the
middle
box
to
decide
I.
A
Really
don't
know
Sergio,
okay,.
A
J
Yeah
the
well
first,
my
first
question
is:
it
seems
that
you
are
only
trying
to
solve
how
to
interoperate
between
quick
over
datagrams
versus
big
cover
the
streams
to
a
quick
over
data
grants
when
using
a
s
frame
to
encrypt
a
whole
and
an
RTP
packet
with
a
an
infinite
MTU.
Is
that
correct.
N
I
think
so,
I
think
if
I
understood
you
correctly,
but
more
generally
anytime,
you
have
to
take
a
larger
RTP
packet
and
break
it
up
into
smaller,
RTP
packets.
Then
there
are
various
reasons
you
might
have
to
do
that
and
you
can't
do
it
in
the
classic
codex
specific
way,
because
you're
also
using
S3.
J
Okay,
but
this
is
first
just
to
try
to
narrow
the
scope.
This
is
something
very
specific
to
RTP
over
quick,
because
how
the
way
that-
and
they
are
doing
quick
over
a
RTP
over
quick
coverage
streams,
because
it
will
require
a
packetization
but
first
first
I
think
that
we
are
trying
to
solve
a
problem
without
even
specified
how
it's
packed
over.
J
This
packet
is
going
to
be
done
in
in
RTP
or
or
in
sdp.
So.
M
J
Think
that
it
is
a
bit
of
a
trying
to
to
to
solve
one
problem
that
it
is
not
even
on
the
table
because,
first
we
don't
have,
we
don't
know
how
to
a
packet
is
our
signal,
as
frame
over
even
in
the
version
that
does
the
pocketization
of
the
whole
Media
frame
or
even
if
it
is
in
just
in
a
in
the
RTP
packet.
J
So
I
think
that
is
a
bit
premature
and
that's
I
mean,
as
I
was
trying
to
to
make
this
work
with
a
in
a
generic
way
and
and
has
hit
some
walls
to
get
it
done.
I
I
like
to
see
the
discussion
going,
but
I'm
not
sure
if
just
narrowing
it
down
to
how
we
are
going
to
and
or
just
to
specifically
to
the
S3
to
the
quick
over
datagrams
versus
quick
over
stream
is
a
good
way
to
solve
the
issue.
J
That
I'm
not
sure
if
you
are
trying
to
yes
solve
a
very
narrow
part
of
the
frame
as
packet
without
even
have
the
even
without
being
I
mean
without
even
having
specified
how
this
packet
works
with
a
normal
RTP,
so
I
I
know
sorry.
We
are
starting
to
to
look
at
the
problem
in
the
in
the
from
the
from
the
brown
Nets.
J
Suggesting
no,
my
question
is
that
we
don't
even
know
how
his
package
is
meant
to
work
with
RTP.
So
why
are
we?
We
are
trying
to
make
to
solve
the
interpretability
between
s
packet
with
with
a
we
say
over
quick
when
we
don't
even
have
a
specified,
how
is
Packet
Works
in
normal
RTP.
N
But
it
kind
of
doesn't
matter
anytime,
someone
would
have
an
encrypted
payload,
regardless
of
the
mechanism
for
that
encrypted.
Payload,
like,
for
example,
right
now
with
the
webrtc
apis
and
application
can
do
its
own
into
an
encryption
mechanism
right
and
anytime.
You
do
that
and
you
try
and
do
it
and
now
you
try
and
apply
that
with
RTP
over
quick
you're
going
to
run
into
this
problem,
where
one
side
is
large
and
the
other
side.
Small
yeah.
J
This
median
critone
a
medium
format
over
RTP,
without
being
something
that
it
is
completely
or
just
depending
on
what
whatever
formatted
in
the
people
are
using
to
to
increase
the
content.
N
Okay,
well
then
it
sounds
like
basically
you're
saying
is
we
don't
need
to
solve
issue
in
29,
because
s
frame
and
S
packet
aren't
mature
enough
in
their
standardization,
and
so
we
should
wait
until
they
are,
and
perhaps
that's
what
the
working
group
decides.
But
that's
kind
of
my
question
so
I
I
think
we
should
work
on
it
before
that.
But
sure
I
can
understand
that
position.
H
Sorry
I
was
in
the
queue,
but
then
my
laptop
went
to
sleep
and
me
Deco
thought
he's,
probably
not
in
the
room
anymore
anyway,
David
skanazi,
quick,
datagram,
enthusiasts
good
to
see
you
again
Peter,
it's
been
a
while
yeah,
so
this
I
mean
like
the
problem
you
describe,
is
a
fundamental
problem
in
packet
switch
networks
like
when
you
go
from
circuits
to
packets,
then
you
have
MTU
issues,
and
this
was
you
know
one
of
the
early
things
of
the
internet
and
in
ipv4
they
were
like.
Oh
yeah.
We
have
this
problem
all
right.
H
Let's
allow
routers
to
fragment
packets
and
what
you're
describing
is
just
a
clone
of
ipv4
fragmentation.
If,
if
I'm
understanding
and
doing
it
correctly,
that
doesn't
work
that
works
horribly
poorly
because
you
know
once
you
fragment
something
a
single
lost
ruins
the
whole
thing,
especially
in
a
context
where
you
have
like
a
security
with
a
tag
like
you
can't
decrypt
anymore
and
in
IPv6.
We,
you
know
banned
that
because
it
didn't
work
so
I.
H
Don't
think
this
is
the
right
solution
like
if,
if
quick
datagram
frames
are
what's
shooting
you
in
the
foot
here,
one
option
is
to
switch
to
Quick
streams.
H
Think
you're!
Okay!
So
then
maybe
I'm
misunderstanding!
Then
why
are
you
fragmenting
it
like
if
the
where's
the
MTU
coming
from,
if
you're
going
over
a
stream
I.
M
B
H
So,
like
you,
you
have
a
frame
that
you
want
to
send
to
a
bunch
of
people
over
mixed
media
and
then
some
of
them
it's
going
to
fit,
and
some
of
them
it's
not
going
to
fit.
Is
that
the
idea.
B
Yeah,
some
of
them
are
RTP
over
quick.
Some
are
RTP
over
UDP.
That's
what
that's
kind
of
what
a
translator
does
or
a
conferencing
stuff.
H
I
see
yeah.
The
these,
like
intuitively,
doesn't
feel
right
to
me
because,
like
I,
I
can
see
how,
like
the
previous
model,
made
sense
where
you
would
re-encode
and
like
do
codex
specific
things
at
the
splitting
point
which
made
sense,
but
it
sounds
like
here.
What
you
want
is
what
we
ended
up
doing
in
IP,
which
is
path
MTU
Discovery,
so
you,
you
kind
of
realize
this
is
happening.
Tell
the
sender
not
to
do
that,
but
maybe
I'm
misunderstanding.
The
problems.
B
The
conference
servers
aren't
routers
yeah
conference
servers,
aren't
routers,
so
mq
Discovery
doesn't
work
through
a
conferencing
server
like
end
to
end.
N
If
it
helps
so.
H
B
That's
not
true
either.
That's
not
how
Compton
servers
work
with
translators,
no.
H
B
D
A
A
Right
I
think
I'm
I'm
next
to
you,
I
think
all
right,
so
as
an
individual,
Jonathan,
Lennox
I
was
gonna,
say
I
feel
like
regardless
of
how
we
solve
this
I
feel
like
this
is
a
problem
for
the
S
frame
of
our
RTP
draft
to
solve
not
the
RTP
over
quick
draft
to
solve
I
think
that
you
know
mostly
having
to
do
with
hey.
This
is
an
S3
specific
issue
and
be
hard
to
be
over.
A
Quick
is
significantly
further
along
the
process,
so
I
feel,
like
you
know,
maybe
the
there
are
to
be
over
quick
draft
should
say
you
know,
rather
than
just
say
codex
specifics
like
codec
or
you
know
other.
You
know
a
metakota
container
or
whatever,
and
you
know
have
some
informative
reference,
but
I
think
the
actual
issue
to
solve
should
be
solved
in
the
in
the
S
frame
document,
rather
than
trying
to
solve
it
in
the
RTP
over
quick,
because
a
it's
applicable
to
anything
that
needs
to
do.
A
N
Well,
on
the
second
issue
that
we
don't
have
to
have
a
normative
dependence
in
this
Frame,
if
we
don't
want
to
because
there's
there's
nothing
in
the
solution
that
needs
to
reference
that
screen,
it's
just
that
s
frame
provides
a
motivation
for
having
a
mechanism
like
this.
N
If
there
were
some
other
mechanism
for
encrypting
end
to
end
that
disallowed
RTP
over
quick
being
able
to
be
translated
to
RTP
over
UDP,
you
would
have
the
same
issue.
So
in
a
sense,
it's
not
s,
frame
specific!
It's
just
into
an
encrypted.
A
Yeah
I've
agreed,
but
my
point
is
that
I
think
s
frame
has
this
problem,
regardless
of
where
they
go
about
to
be
over
quick
or
not
so
I
feel
like
s
frame
is
the
appropriate
and
I
feel
like
in
some
sense,
this
kind
of
fragmentation
is
what
you're
doing
with
s
frame
quite
as
frame
to
begin
with,
which
is
that
your
taking
a
frame
encrypting
and
authenticating
it
and
then
chopping
it
up
and
so
I
feel
like
the
chocolate
making.
A
If
we
design
the
chop
it
up
process,
so
you
can
re-chop
it
up
without
messing
with
those
tags.
I
feel
like
that
solves
the
problem.
Yes,
the
translator
still
has
to
have
an
S
frame,
aware
knowledge
if
it's
going
to
do
that
re-chopping,
but
that's
sort
of
what
the
this
draft
means
like
codec
aware
this
is
this
meta
codec,
not
the
codec
proper,
but
it's
still,
you
know,
I
think
it
doesn't
change
anything
about
how
hard,
if
you
ever
quick
works
and
making
sure
that
the
process
is
possible,
is
s
frame's,
responsibility.
A
D
Yeah,
there's
that
this
is
I
think
this
is
an
appropriate
time
for
me
to
leave
in
here,
as
as
soon
as
we
were
doing
nothing.
So.
The
direction
that
the
S
frame
working
group
is
going
in
right
now
is
to
make
the
S
frame
of
document
to
specify
only
the
encryption
framing,
because
there
is
been
so
much
ambiguity
around
frame
level
versus
packet
level
versus
you
know.
D
Other
ways
you
you
might
choose
the
the
units
that
you
encrypt
with
with
this
Frame
and
so
I
I
sort
of
agree
with
Sergeant
like
how
you
carry
an
S
frame
thing
in
in
a
a
chunk
of
data
is
encrypted
with
the
S
frame
encryption
framing
in
an
RTP
pack
when
in
one
or
more
RTP
packets
right,
because
you
can
Envision
it
in
the
full-frame
version,
we
have
multi
multi-frame
multi-factored
frames
like
you
might
have
multiple
RTP
frames
carrying
a
single
s
frame
unit.
D
So
all
that
is
super
ill
defined
right
now
and
there's
not
really
a
path
to
getting
it
defined.
As
far
as
I
know,
the
history
and
working
group
is
focused
on
getting
the
encryption
bits
done
so
yeah.
There
may
be
some
some
intermediate
work
here
to
be
done
in
any
case
with
regard
to
aspiring,
which
is
probably
not
the
job
of
RPA.
Real,
quick
I
was
sort
of
got
A,
plus
one
David
here,
and
that
this
seems
like
a
generic
issue,
not
an
S
frame
issue
at
all.
D
This
is
a
generic
issue
for
actually,
as
Peter
said
at
the
very
top
of
this
presentation,
like
the
underlying
issue.
Here
is
doing
this
repacketization
when
you
don't
know
anything
about
the
Enterprise
codec
and
that
could
be
because
the
underlying
codec
is
encrypted
because
vestream
could
just
be
because
you,
as
the
repackathizer,
don't
know
anything
about
it,
and
so
you
can't
make
any
Intelligent
Decisions
about
what
you're
the
data
you're
looking
at.
So
it
suits
to
the
degree
that
there's
a
solution
necessary
here.
D
D
One
final
note:
that's
the
the
Bernard
and
David
discussion
that
was
just
going
on
about.
You
know
whether
this
is
a
router
or
not.
It
does
seem
like
there
you,
you
could
have
something
pmtud
like
here:
I've
got
them
to
you,
discover
it
like
here
in
the
sense
that
you
know
if
you
have
and
SFU
that
is
sitting
in
the
conferencing
service
sitting
in
the
middle
of
a
bunch
of
connections,
it
it
no
it's
doing
repacketization
and
it
has
some
idea
of
what
the
ntus
are
out
to
it's.
D
It's
the
endpoints
is
serving,
and
so
in
principle,
if
you
had
the
right
control
plane,
you
could
distribute
that
information.
Have
people
send
those
mtus
and
do
you
know
bushing
and
not?
You
know,
not
fragmentation.
N
B
A
B
A
D
Is
I
actually
disagree
with
the
the
very
end
of
that
sentence,
so
I
think
we
probably
do
need
a
document.
I
think
the
AVC
first,
probably
the
right
spot
for
it,
but
I.
Don't
think
that
this
issue
actually
touches
that
because
well
I
mean
maybe
maybe,
as
an
extreme
of
RCP
doctor
needs
to
deal
with
repacketization
but
like
it
seems
like
book
cover.
Rtp
is
the
one
that
has
the
apj.
Has
a
generic.
You
know,
I,
don't
know
the
codec
revocetization
issue
so.
K
D
A
B
Bring
up
a
good
question:
Jonathan
we've
been
waiting
for
almost
two
years
for
an
art
s
frame
of
rgp
proposal,
and
you
know,
since
s
frame,
is
only
transported
over
RGB
not
having
a
proposal.
The
only
way
it
can
be
transported
is
kind
of
awkward.
B
So
some
you
know
something.
I
I
knew
there's
been
discussion
among
the
80s
of
closing
the
s-frame
working
group
and
just
giving
you
know
moving
it
somewhere
else,
but
it
seems
like
there.
There
has
to
be
a
document
here
somewhere.
A
Bernard,
are
you
speaking,
are
you
so
impure,
or
is
that
your
comment?
Okay,
Harold,
I,
guess
you're
next.
I
So
it's
not
that
it's
not
been
proposed
is
that
the
proposed
was
because
rejected,
and
the
other
point
was
to
move
which
is
at
if
your
SRAM
is
intended
for
end
to
end
encryption
protection
and
so
on.
I
A
E
Yeah
Magnus
wrestling
yes
fully
agree
with
Harold's
second
part
here
about
yes
use,
hope,
I,
hope
for
hope,
I
hope,
protection
and
and
to
end,
and
on
the
general
issue
of
RTP
fragmentation
or
or
MTU
issues
dealing
I
mean
for
any
RTP
payload
format
that
sense
any
significant
size
payload
that
can
be
loaded
and
expected
IBM.
Do
you
basically
need
to
have
some
type
of
fragmentations
a
little
bit
of
this
datagram
and
the
model
to
my
understanding
has
all
along
been
that?
E
Yes,
if
you're
gonna
have
ideas
and
small
enough
packet
that,
if
it
in
in
all
the
links
or
you
need
to
have
an
RTP
middle
box
that
can
actually
re-fragment
the
packet
into
something,
that's
the
payload
into
something
that
fits
the
RTP
packets,
that
is
kind
of
have
been
the
model
I
think
we
have
some
discussions
around
things
like.
Oh,
how
do
you
actually
detect?
E
What's
this
MTU
that
works,
but
in
this,
especially
in
the
context
of
this
SFA
who's
but
yeah,
it
isn't
great
this
model,
but
it's
it
is
what
we
have
Etc
and
I.
Think
in
the
context
of
s-frame
yeah
you're
gonna
have
to
write
the
thought
to
be
payload
format
and
I.
Don't
see
you
way
around,
defining
a
generic
s
frame,
payload
format
which
cam
fragment
you're
gonna
need
something
again.
Unless
you
ask
how
could
how
smart
can
you
do
it?
And
yes,
it's
not
gonna
have
ideal
transport
properties.
You
lose
a
fragment.
E
You
lose
the
whole
frame.
It's
it's
gonna,
be
that
bad,
but
yeah,
I
I,
don't
see
an
easy
way
around
that
and
and
and
you're
when
you
start
to
talk
about
like
RTP
in
quick
Etc,
you
have
choices
where
it's
makes
this
better
by
relying,
for
example,
on
stream,
individual
streams
for
per
frame,
and
things
like
that,
if
you
can
do
it,
if
you're
of
your
other
message
based
transmission
capabilities,
that's
focused
on
just
transmitting
one
data
object,
so
you
don't
have
to
care
about
that.
So.
L
Mosinati,
so
just
to
clarify
what
Harold
said
earlier
about
what
got
rejected.
There's
some
Nuance
here
that
that
maybe
people
are
missing
what
was
rejected
earlier.
It
was
s
frame,
was
first
attempting
to
have
a
generic
packetizer
over
the
RTP
Elementary
stream
itself.
L
L
The
median
coder
generates
an
RTP
frame,
an
RTP
packet
that
big
in
the
S
frame
can
wrap
that
we're
originally
talking
about
dicing
having
a
generic
packetizer
over
the
elementary
streams
of
of
the
RTP
packets
of
the
RTP
payload
formats,
and
that
was
rejected
because
there's
a
lot
of
nuance
and
and
how
to
do
that
and-
and
you
know,
different
different
payload
formats-
do
it
in
different
ways
and
it's
difficult
to
harmonize
all
those
together.
So
I
think
it
was
wise
for
the
S
frame
decision
to
say
no
we're
not
going
to
do
that.
L
Think
that's
really
the
fundamental
question
and
I
would
argue
that
s
form
knows
it's
going
to
go
over
some
transports
and
it
knows
it's
going
to
get
chomped.
So
why
would
it
not
have
a
a
native
chunking
inside
of
it
so
I
kind
of
agree
with
with
Peter's
direction
that
it
needs
to
whether
it
goes
over
RTP
or
over
anything
else?
It's
going
to
go
over
packets
and
it
probably
cares
about
how
it
gets
chunked
into
packets.
L
So
I
think
it
does
make
sense
to
define
something
like
this
I'm
a
little
bit
concerned
of
how
naive
you
know.
The
simple
approach
is
because
it
seems
like
it's
automatically
going
to
double
your
packet
rate
if
there's
ever
an
empty
mismatch
and
that
can
totally
destroy
a
lot
of
networks
that
are
packet
weight,
sensitive,
your
media
delivery
may
end
up
being.
L
You
know
twice
as
bad
as
you
expected,
because
you
have
a
two
or
four
byte
Mt
mismatch,
so
that
would
be
a
bad
outcome
for,
for
a
naive
and
coding
like
this,
but
I
think
it
is
fundamental
to
S
frame
to
know
that
it's
going
to
go
over
smaller
object
transports
and
Define
its
own
chunk
layer
inside
of
it,
so
that
the
higher
level
transport
doesn't
have
to
do
something
special
for
it.
M
So
I'm
Spencer
Dawkins
I
got
up
to
say
something
a
long
time
ago,
but
I
actually
do
think
I
remember
what
it
was
the
so
the
introduction
of
the
sorry,
the
abstract
of
the
RTP
over
quick
specification
talks
about
it
doing
a
minimal
specification,
and
that
was
kind
of
where
I
thought
we
were
going
at
the
last
meeting
or
two
and
I'm
I'm,
not
just
I'm,
not
recording
a
problem,
I'm,
making
a
suggestion
that
we
may
want
to
decide.
M
What's
it,
what
is
really
what
problems
really
need
to
be
solid
events
but
specification
and
what
the
problems
need
to
be
solved
in
other
specifications
more
broadly
than
just
MTU
mismatch.
We've
we've
mentioned
conference
Bridges,
and
things
like
that.
That
may
be
translating
from
RTP
over
quick
to
RTP
over
something
else,
and
you
know
the
topology
draft.
There's
apology.
Rfc
is
a
pretty
good
sized
chunk
of
writing.
I
think
it
would
be
good
for
us
to
be
looking
at
that.
M
Specifically,
you
know
like
what
topologies,
rather
than
expecting
the
minimal
specification
draft
authors
to
solve
that
problem
on
their
own,
but
I
I
know
you
all
will
do
the
right
thing
and
I
don't
actually
know
what
the
right
thing
is,
but,
like
I
said
I
would
I
would
suggest
that
we
think
for
a
little
bit
about
feature
creep
and
I
am
fine
with
the
answer
changing
because
I
mean
it's
time
has
passed
and
we're
now
talking
about
a
working
group
adoptive
specification
and
not
just
couple
of
really
smart
guys
writing
a
draft.
M
So
it's
fine
for
the
answers
to
change,
but
for
us
to
just
be
a
little
explicit
about
what
Target
we're
shooting
at
and
I
think
that
may
make
some
other
things
off
easier
itself
too.
Thank
you.
F
So
Colin
James
here
I
think
going
way
back
to
to
David's
comments.
I
mean
that
we
do.
We
do
have
a
complex,
you
know
router,
not
a
router
and
the
RTP
terminology,
sense
of
it,
but
we
have
a
device
in
the
middle
that
needs
to
occasionally
send
things
out
over
things
that
are
not
quick
streams
or
not
a
TCP
stream
that
this
chunk
or
that
this
thing
data
arrived
in.
They
need
to
be
able
to
re-chunk
it
or
make
sure
it's
small
enough
to
get
down
to
those
smaller
connections.
F
Right-
and
you
know
you
know,
Jonathan,
you
said
like
we've
got
to
have
that
it
doesn't
work
over
RTP.
If
it
can't
have
that
property,
which
seems
true
and
we've
got
another
group,
that's
you
know
Richard's
trying
to
make
it
not
be
S
frames.
Pro,
the
S
frameworking
groups
problem
to
figure
out
how
to
solve
this,
which
I
mean
I,
understand
that
too,
but
we're
just
creating
an
impossible
set
of
scenarios
here.
So
I
I
think
that
the
way
that
makes
sense
is
a
way
out
of
this.
F
To
me,
it
you
know
is
right
that
this
this
fragmentation
inside
the
network,
which
is
what
this
is,
is
always
problematic,
and
it's
really
it's
a
very
hard
problem
to
solve,
and
that's
what
we're
running
into
this
was
mentioned
when
we
chartered
all
of
this
work
in
the
first
place
by
the
way,
so
I
don't
think
we
can
do
path.
F
Mtu,
Discovery
I
think
it's
too
hard
to
do
any
form
of
that
across
the
conference,
because
people
come
and
leave
too
quickly
and
we've
never
got
it
to
work
so
I
think
that's
fantasy
and
I
think
that
really
only
leaves
us
one
real
option,
which
is
we
pick
an
MTU
of
1200
in
s
frame
and
the
S
frame
documents
are
defined,
such
that
the
S
frameworking
group,
and
what
comes
out
of
that
is
never
passing
into
the
RTP
layer
or
something
that's
that's.
N
Right
so
we're
basically
deciding
how
to
proceed,
and
it
sounds
like
maybe
a
separate
draft
with
a
different
name.
But
here
in
this
working
group.
F
I
I
think
that's
complete
garbage,
okay,
that
it
doesn't
that
doesn't
help
the
splitting.
The
the-
how
not
the
number
of
drafts
or
the
number
of
working
groups
is
not.
The
problem
here
has
nothing
to
do
with
the
problem,
so
that
will
not
fix
it
and
it
won't
help
and
we
shouldn't
even
discuss
it
until
we
figure
out
how
we're
going
to
solve
the
problem.
F
F
F
E
I
mean
it
is
frame.
Fragmentation
is
not
RTP
or
quickest
problem.
It's
s,
frame's
problem,
and
it's
it's
it's
from
my
perspective.
Either
you
do
it
as
a
generalist
most
suggesting
ens
frame
to
fragment.
However,
I
think
that's
Easter
in
other
cases
where,
as
friends
gets
fragmented,
if
not
do
it
in
the
bloody
RTP
payload
for
s-frame,
you're
gonna
need
one
the
right
home
for
that
document.
I
think
you
still
think
is
here
in
avt
core,
because
it's
going
to
be
RTP
problems
more
than
as
friends
problems.
E
N
Yeah
I'm
happy
to
rename
my
thing
s
frame,
packetization
for
RTP
or
whatever,
and
do
it
here.
D
N
A
D
Wonderful
document,
but
it's
not
the
document
you
you
said
Hudson
to
propose
here,
I
think
it's
a
different
topic
yeah.
The
short
problem
here
is
like
whether
RTP
is
okay
with
repacketization
that
doesn't
pay
attention
to
codex,
because
that's
the
underlying
problem
here,
the
only
thing
S3
was
doing
here-
is
making
it.
So
you
can't
see
the
the
actual
codec.
D
If
that's
a
solvable
problem,
we
should
solve
it
at
the
RTP
layer
so
that
we
don't
have
to
redo
this
for
every.
So
we
get
the
generic
decoupling.
We
don't
have
to
do
it
for
every
case
where
you
can't
or
don't
want
to
look
at
the
end
of
internals
the
codec.
A
So
as
an
individual
and
I've
cleverly
arranged
to
look
at
the
last
word
here,
I
mean
RTP
was
designed
to
have
tight
coupling
to
the
Codex,
because
there's
a
lot
of
benefits
to
that
and
one
of
the
consequences
that
is
now
you
have
to
know
about
the
codec.
If
you're
going
to
do
things
with
the
RTP
player
and
yeah,
that's
a
trade-off,
and
if
you
want
to
just
I
mean
that's,
why
we
use
RTP
and
not
just
send
these
things
over
TCP.
A
So
as
a
con,
so
I
mean
so
for
S
frame
s
frame
is
a
potentially
a
Meta
Meta
payload.
So
something
we'll
have
to
know
about
s
frame
to
do
this
work,
but
that's
that's
fine.
A
It
won't
have
to
know
about
the
contents
because,
like
you
say
it
can't
anymore,
that
it
doesn't
know
about
the
you
know
it
might
be
able
to
repacketize
issue
six
four
with
fragmentation
units,
but
it
doesn't
have
to
know
about
how
you
know
inverse
cosine
transfer
transforms
work
or
anything
like
that,
and
so
that's
so
I
mean
I.
Think
and
I
as
I
said,
I
think
what
Peter
said
is
writing
an
S
frame.
A
Payload
for
RTP
would
be
an
excellent
document
entirely
in
scope
of
this
work
group
and
something
we've
needed
for
a
while
to
get
S3
working
proper
did
actually
have
Mass
frame
defined
I
mean
I
would
have
thought
that
it
would
be
in
scope
for
the
S
framework
in
group
two.
But
if
you
want
to
do
it
here,
I
mean
I
think
the
argument
that
it
needs
the
RTP
knowledge
is
fine,
I'd,
be
happy
to
say
it's
in
scope,
but.
J
But
you're
not
done
we
we
when
we
when
calling
they
presented
the
the
game
State
data,
it
was
kind
of
their
response
of
the
group
that
the
media
should
be
done
outside
of
the
ABT
core,
and
then
the
packet
decision
should
be
done
in
our
in
in
RTA
in
ABT
core.
So
it
is
kind
of
I
mean
what
the
dependent
of
the
college
we
choose
to
do.
The
bucket
Edition,
also
outside
of
the
of
a
IV
Decor
or
not
or
How.
Does
it.
M
J
So
how
this
Frame
is
frame
has
to
make
sure
that
it
is
said
that
it
works
in
RTP,
but
I
think
that
the
people,
the
decision
for
this
frame
for
this
packet
must
be
done
in
a
vehicle.
I
have
presented
several
times
the
the
generic
packetizer
try
to
overcome
the
issues
right
by
the
by
the
ABT
Core
group
and
I
failed.
So
that's
why
it
has
not
been
for
the
progression.
It
is
not
that
we
have
not
made
extensive
effort
to
make
it
work
in
here,
but
it
is
not
possible.
I.
A
Mean
I
think
it's
it's
not
that
the
concept
is
bad.
Is
that
you
know
you
need
to
have
codex
specific.
You
need
there
needs.
You
need
to
expose
enough
codec
knowledge
such
that
things
can
make
a
Intelligent,
Decisions
and
honestly
I
feel,
like
you
know,
just
this
is
the
you
know.
One
of
the
problems
that
s
frame
has
had
is
that
because
of
the
pandemic,
we
haven't
been
able
to
have
side
meetings
with
this
I
think
if
we
had,
you
know
a
two-hour
side
meeting
with
the
right
people.
J
Is
coming
from
from
the
fact
that
the
RTP
over
quick
has
decided
to
make
something
that
it
is
not
playing
well
with
the
rest
of
the
RTP
implementation?
Not
there
I
mean
we
have
never
have
a
problem
in
real
life.
About
mtus
I
mean
we
have
svus
that
that
forward
buckets
from
one
network
to
another.
J
Even
if
then
the
empties
could
be
different,
I
mean
which
reality
I
don't
know.
If
it
is
the
case,
there
has
been
no
no
issue
in
in
transferring
packet
without
having
to
repackathize
I.
A
Don't
think
that
sorry
I
mean
that
yeah,
it's
absolutely
true
that
until
now,
I
think
Colin's
thing
of
just
assumed
the
empty.
The
palette
MTU
is
1200
and
work
with.
That
is
what
everybody
has
done
and
that's
been
fine.
One
of
the
ideas
of
artificial,
real
quick
is
don't
do
is
because
you
have
streams.
No,
you
can
treat
it
as
though
you
have
unloaded
mtus
and
that
works.
But
that
means
that,
yes,
if
you're
Gateway
into
something
that
still
has
that
limit.
J
J
So
it
is
a
decision
that
has
been
made
by
the
RTP
over
quick
to
to
send
the
the
RTP
package
with
an
infinite
NTU.
That,
in
fact,
does
not
play
well
with
any
other
RTP
over
any
other
thing.
So,
instead
of
pushing
this
problem
with
a
2s
frame
or
two
other
pair,
all
to
other
media
formats,
I
I
agree
with
what
Richard
said
that
it
is
not
only
a
problem
with
a
string.
J
It's
a
problem
if
we
want
to
do
a
an
SVU
or
a
media
element
that
does
not
really
need
to
have
knowledge
of
the
of
the
packet
decision
and
the
magnetization
of
the
or
the
or
the
Codex
itself,
because
it
is
not
what
typical
SVU
does.
So.
We
are
adding
an
extra
requirement
in
the
in
the
to
these
Network
elements
and
just
because
of
what
a
RTP
over
Queen
has
decided
to
do
with
say
with
a
with
the
with
the
quickest
streams,
and
it
has
just
left
us.
M
A
Is
that
issue
29
is
a
special
case
of
the
idea
that,
because
the
infinite
MTU
abstraction
is
causing
problems
for
anything
where
you
need
to
Gateway
To
traditional
rgp
over
UDP
and
yeah,
that's
true,
and
so
maybe
maybe
that's
something
that
that
the
RDP
over
quick
draft
could
talk
about
not
specifically
to
S
frame,
but
in
general
the
infinite
MTU
causes
problems.
F
K
K
So
we
had
a
bunch
of
different
updates,
allow
for
mixing
streams
and
datagrams
now,
but
I
want
to
first
talk
about
the
length
Grid
in
quick
streams
in
order
to
support
translators
or
things
like
that.
That
would
actually
need
to
chop
big
things
up
into
smaller
things.
Next
slide.
K
We
have
included
an
explicit
length
field
here
so
that
a
sender
could
actually
do
Center
side
segmentation
into
meaningful,
resize
chunks,
while
still
transmitting
the
whole
thing
over
a
quick
stream,
and
you
would
find
the
identifiable
borders
like
you
do
when
you
try
to
send
something
over
TCP
over
sctp
or
something
else,
so
that
would
allow
if
there
existed
a
an
S
frame,
fragmentation
to
come
back
to
our
previous
discussion
at
the
sender.
K
To
preserve
these
boundaries
that
you
insert,
even
though
you
are
using
a
quick
stream
for
transmission
and
then
a
translator
could
would
have
the
natural
packet
boundaries
to
send
that
forward.
The
choice
of
the
size
of
these
frames
would
ultimately
be
up
to
the
sender,
and
if
you
have
negotiated
that
you're
talking
straight
over
streams
to
it
to
directly
to
appear
without
any
translator,
then
maybe
you
don't
need
those.
If
you
have
negotiated
something
different,
then
you
can,
then
you
can
choose
smaller
units,
and
this
may
be
180u.
K
K
So
if
we
can
send
one
or
more
packets
over
the
stream,
we
had
mechanisms,
or
we
do
have
mechanisms
in
the
RTP
over
quick
Draft
when
using
streams
to
cancel
outstanding
Transmissions.
So
a
sender
who
is
figuring
out
that
maybe
my
queue
is
too
long.
This
is
never
going
to
make
it
up
to
the
receiver
in
time.
I
can
send
the
reset
stream
to
terminate
to
terminate
this
transmission.
At
the
same
time,
a
receiver
could
possibly
find
out
that
oh
stuff
is
coming
in
too
late.
K
I'm
not
going
to
use
this
packet
anymore,
or
this
this
Adu
anymore.
So
maybe
I
should
tell
the
sender
to
stop
retransmitting
and
so
I
could
send
I
could
cancel
a
stream
using
stop
sending
the
interesting
question
is
the
moment
we
have.
We
may
have
multiple
packets
on
that
stream.
K
You
don't.
The
sender
doesn't
exactly
know
whether
there
is
the
receiver
doesn't
exactly
know
whether
the
sender
has
put
180u
on
the
stream
or
multiple.
So
if
I,
if
I
would
say,
stop
sending
and
cancel
an
incoming
stream
I
have
no
idea
how
many
bits
I'm
going
to
rip
off
of
that
Stream
So.
What
I'm
going
to
lose
next
slide?
K
So
first
option
is.
A
Thank
you.
It's
actually
quick
right
side.
Okay,
okay,
now,
just
search
audio
there's
something
you
want
to
say
are
you
just
in
the
keyboard.
K
K
So
maybe
you
have
an
agreement
that
you're
always
going
to
just
use
180u,
and
you
are
maybe
this
isn't
the
problem
that
we
need
to
solve
at
the
transport
layer
and
so
and
then-
and
we
are
just
done-
we
could
also
require
just
a
single
Adu
per
stream
would
be
an
option,
but
we
might
also
have
a
single
group
of
pictures
or
something
on
the
per
stream
because
they
are
dependent.
They
have
the
exhibit
dependencies
anyway.
K
So
maybe
that
b
might
be
too
harsh
an
option
or
we
might
invent
some
signaling,
but
that
appears
to
be
arbitrarily
complex
to
have
semantically
Rich
enough
expressiveness.
So
we
probably
have
a
kind
of
a
tendency
to
go
for
for
solution.
Number.
A
just
curious
about
comments
from
people.
Does
anybody
care.
B
Yeah
I
mean
I,
think
there's
an
inherent
Advantage
for
the
sender
to
cancel
a
stream,
because
it
knows
what
came
out
of
the
encoder.
So,
for
example,
it
knows
it's
a
keyframe
I
can't
really
cancel
it.
I
need
to
get
it
through,
or
maybe
it's
an
enhancement
layer.
So
when
I
was
implementing
this,
it
made
the
most
sense
to
do
the
cancellation
on
the
sender
anyway.
B
So
I
think
you've
stated
the
issue
and
I
I.
Don't
see
why
the
receiver
would
would
have
to
do
the
cancellation-
and
maybe
we
just
just
say,
hey-
don't
need
to
Sender
can
do
it
in
this
case.
H
David
skanazi,
quick
Enthusiast.
There
is
no
such
thing
in
quick
as
a
receiver,
canceling,
a
stream.
So
we're
like
we're
talking
about
unidirectional
streams.
A
receiver
can
send
a
stop
sending
that's.
H
Yeah
but
but
the
important
distinction
there
is
the
stop
sending
frame
is
not
does
not
cancel
the
stream.
The
stop
sending
frame
tells
the
sender.
Please
cancel
this.
The
Stream,
and
so
the
sender
will
has
to
just
in
quick
decide
whether
to
cancel
the
stream
and
to
resend
a
reset
stream
and
when
it
will
so.
H
So
that
that's
your
easy
solution,
there
is
you,
you
should
add
some
text
to
say
that,
like
if
you
receive
what
to
do,
if
you
receive
a
stop
sending
like
don't
do
the
dumb
thing
be
smart
about
it
and
that
might
your
life
might
be
a
bit
harder,
because
some
quick
implementations
might
just
say:
okay,
they
said
stop
sending
I'm
going
to
reset
the
stream
right
away
without
sending
it
to
the
application.
So
that
might
be
an
implementation
issue,
but
from
a
standards
perspective.
There's
no
problem
here.
A
P
Hey
Lucas,
Pardo,
I,
I,
love
streams
like
this
stuff
is,
is
causes
so
many
bugs,
as
David
said,
yeah
I'm,
aware
of
bugs,
where
people
have
received,
stop
sending
and
not
actioned
it
and
all
sorts
of
fun
and
games.
But
for
me
I,
don't
understand
RTP
that
well
to
know
what's
safe
versus
unsafe.
Is
this
like
safe
in
the
security
Center?
Is
it
just
non-optimal
that
some
things
get
dropped
on
the
floor?
I
thought
that
might
help
to
understand
the
problem.
Like
the
the
impact
of
the
problem,
we're.
P
P
P
So
that
doesn't
seem
too
bad
and
and
like
hb3,
has
this
problem
right.
We
send
frames
on
streams
and
if,
if
you
get
reset
at
any
point
on
that
stream,
you
don't
know
what
frames
are
going
to
come
after
it
and
we
kind
of
live
live
with
that.
Yeah
yeah.
Just
accept
that
this
could
happen.
I
think
is,
is
what
we're
saying,
maybe
you
could
say
well
like
David
just
alluded
to
implementations,
could
do
something
smarter
and
try
and
send
the
reset
at
the
right.
P
You
know
the
offset
that
that
it
makes
sense
in
the
packet.
The
problem
I
think
you
might
hit,
though,
is
that
if,
if
there's
any,
if
you're
expecting
that
all
of
the
data
before
that
reset
was
received
on
the
other
end,
it
might
not
have
been
before
the
the
other
end
sees
the
reset
stream
and
it
discards
all
the
state
that
you
were
hoping
that
it
would
have
read
beforehand
like
there's
not
going
to
be
any
Transmissions
at
that
point,
so
you're,
probably
still
in
the
situation
of
a
anyway.
P
K
I
suspect
with
us
with
David's
comments,
we'll
need
to
bang
our
head
a
bit,
get
ahead
around
that
in
order
to
see
what
kind
of
interaction
that
actually
leads
to
and
given
that
that
also
every
interaction
causes
an
extra
rtt.
What
that,
then,
in
the
end,
means
for
a
a
sensible
choice
of
action,
Colin.
F
So
I
I,
notwithstanding
status,
comment,
which
is
great
I
I,
do
come
sort
of
towards
back
to
a
because
I'm
thinking
about
the
use
cases
where
we
use
this
and
usually
what
you
want
to
do
when
you're
doing
this
is
cause
ban
it
like
causes
you,
you
really
decide
you're
abandoning
the
whole
thing
everything
you
previously
sent
you're
trying
to
get
the
bandwidth
to
stop
as
quickly
as
possible,
so
I
think
leaving
and
you
stuff
that's
already
been
sent.
F
You
can't
cancel
it's
already
in
Flight
right
and
with
you
know,
the
basic
model
of
RTP
is
you're,
never
guaranteed.
Anything
was
going
to
happen
to
get
delivered
anyway,
so
some
packets
didn't
arrive.
It's
just
like
well
within
an
RTP
model.
I
like
I,
think
our
I
think
what
the
the
at
the
must
level
in
the
draft
is.
When
this
happens,
you
really
don't
know
what
will
happen
of
any
of
the
stuff
that
was
in
Flight.
It
might
get
lost,
it
might
go,
it
might
not
like
it
like.
F
Just
don't
make
any
assumptions
about
it
and
then
maybe
there
should
be.
Perhaps
some
should
level
things
of
something
clever.
You
can
do
but
I
think
the
clever
advice.
Oh
I
mean
it's
going
to
be
hard
to
decide
what
the
policy
is
that
you
want
like
what
would
be
do
the
right
thing,
even
if
we
had
all
the
mechanisms
to
do,
it
is
very
hard
to
tell
and
I
I.
Don't
think
this
really
matters
for
the
users
of
this,
so
I
I
sort
of
lean
towards
the
the
a
like
like.
F
H
David
schenazi
is
me
again:
I
realized
that,
in
my
previous
comment,
I
was
being
clever.
So
for
that
I
apologize,
that's
generally
always
a
bad
idea.
H
One
Jonah
made
an
interesting
point
to
me
yesterday
in
a
completely
different
conversation
that
we
kind
of
made
a
mistake
in
quick.
In
that
we
called
these
things
streams.
We
should
have
called
them
messages.
H
The
the
the
like
the
mental
model
that
we
worked
in
in
quick,
and
you
know,
as
we
were
designing
it
for
its
initial
use
case
of
HTTP
3,
was
like
their
messages
like
you're,
an
HTTP
request,
an
HTTP
response
and
the
the
concept
of
stop
sending
and
reset.
Is
you
know
actually
this
message,
this
Atomic
unit
of
information,
I,
don't
care
anymore
or
like
I'm,
trying
to
send
this
and
like
no
forget
it,
the
whole
thing
is
done
so
I.
H
You
know:
option
b
sounds
like
a
much
better
fit
to
quick,
like
have
one
Media
frame,
a
per
unidirectional
stream
I,
don't
think
you're.
Getting
many
benefits
from
putting
two
on
the
same
stream
like
just
have
them
be
separate.
You'll
make
your
life
a
lot
easier
because
you'll
fit
into
the
quick
model
better.
K
I'd
be
certainly
happy
with
that
as
well.
We
had
it
before
in
the
in
the
draft,
and
then
some
discussion
arose
whether
that
might
be
a
useful
alternative
to
have
to
allow
for
more,
but
maybe
option
b
is
indeed
the
right
thing,
because
it
keeps
it
preserves
semantic.
You
Unity,
at
the
same
time,
with
the
length
Fields
allowing
for
things
to
be
pre-tropped
in
case
you
need
to
forward
them
that
doesn't
preclude
the
whole
thing
to
come
in
multiple
pieces,
even
though
it's
just
one
unit.
A
O
Was
just
going
to
say
yeah
that
in
some
ways
the
sort
of
putting
it
over
streams
is
a
bit
like
kind
of
running
conferencing
stuff
over
TCP
in
in
some
sense,
in
like
you're
kind
of
reliable
to
really
the
you
want
to
be
aiming
for
the
UDP,
the
datagram
solution
within
quick
in
that
that's
probably
gives
you
a
a
better
match
kind
of
closer
match
to
the
original
RTP
type
distribution.
So
in
some
senses
that
sort
of
I
guess
this
is
just
like
a.
O
If
you
can't
do
the
datagrams
approach,
then
you
go
for
the
streams,
and
so
presumably
the
diagrams
approach
give
you
a
better
approach.
O
Mapping
anyway
in
terms
of
the
original
RTP
semantics,
and
that
you
don't
necessarily
end
up
with
some
junk
being
sent
that
you
don't
want.
K
Right
that
is
true,
but
people
have
been
had
had
some
interest
in
doing
streams
that
there
may
be
sense
in
having
some
things
reliable
because
they
are
iframes
or
something
like
that.
So
that's
why
this
is
here
or
what
we'll
have
to
dig
a
bit
more
about
the
through
the
through
the
technical
details
of
when
to
when
to
use
what
and
how
these
things
fit
together.
But
that's
and
datagrams
are
optional
and
quick
to
begin
with
yeah,
so
people
have
been
using
streams
happily
for
many
for
many
in
many
applications.
K
So
if
it
felt
wrong
to
to
preclude
this
plus,
there
was
also
an
explicit
desire
from
the
working
group
to
actually
have
that
included
and.
O
K
J
K
For
STP
Magnus,
oh
not
even
getting
there.
E
Yeah
you're,
not
getting
there
I
I
think
there's
need
to
be
some
Analyze.
This
is
what
actually
puts
like
limitation
of
session
link
length
with
B.
If
you're
gonna
go
for
it
estimate,
I
mean
yes,
it's
probably
you
should
do
skill
bit.
Layers
are
different
videos,
Maybe,
so
you're
one
per
sampling
whatever
times
a
few
times.
Okay,
it's
fairly
long,
but
it's
not
infinite,
so
I
think
some
analysis
of
that
Etc
was.
E
It
actually
implies
in
being
clear
that
this
actually
limits
session
length
compared
to
normal
RPP,
which
I
don't
think,
have
the
same
limitations
of
any
kind
of
hard
stop.
Because
this
has
a
hard
stop
you're
running
at
the
streams,
then
you
must
restart
a
quick
connection.
You
have
no
other
choice:
When
You,
Reach
stream,
identifications
up
to
two
up
to
62.,
so
yeah.
K
K
K
Okay
quickly,
quickly
next
slide,
so
we're
not
going
to
get
through
this
now,
but
the
fundamental
things
we
have
been
discussing,
what
scope
this
draft
should
be
having
in
terms
of
multiplexing,
and
we
were
advised
that,
depending
on
which
kind
of
different
transport
streams,
one
would
use
one
would
one
would
need
to
have
different
alpns.
K
One
thought
was
that
we
just
defined
this
for
RTP
over
quick,
only
and
don't
allow
other
media
types
in,
so
that
there
is
no
question
on
with
which
congestion
control
to
use,
how
to
prioritize
different
streams
and
packets
across
each
other.
But
then
there
was
also
some
discussion
on
whether
one
should
have
different
multiplexing
schemes,
and
one
interesting
question
that
arises
from
all
of
this
is
how
one
would
cope
with
this
problem.
K
With
this
multiplexing
now
we
have
been
and
how
to
demultiplex
on
the
receiver
side
and
who
is
going
to
define
the
framing
or
the
identification
of
different
logical
streams
or
flows
inside,
for
example,
quick,
datagrams
or
inside
quick
streams
and
and
how
that
would
happen.
Assuming
that
you
might
have
different
applications
that
will
be
mapping
things
to
Quick
data
diagrams
between
the
same
two
endpoints
and
it
was.
We
originally
proposed
a
session
identifier.
K
K
Now
we
have
been
doing
some
thought
experiments
where
the
web
transport
could
be
a
suitable
alternative
as
as
a
multiplexing
scheme,
but
that
seems
to
have
other
limitations
into
which
I
don't
want
to
go
in
in
the
interest
of
time
right
now,
but
maybe
rather
Reach
Out
offline
to
some
of
the
web
web
transport
Forks
to
find
out
what
these
implications
would
be.
K
Skip
the
next
slide
that
just
takes
us
too
long
in
the
meantime,
I
updated
the
first
bullet
on
this
side
on
this
slide.
For
that
we
probably
just
document
something
for
S
frame
for
for
the
MTU
size
issues,
we
are
looking
at
further
topology
considerations
and
then
next
slide.
To
conclude,
we
need
to
think
more
about
multiplexing.
A
Perfect,
all
right,
I,
sorry,
Spencer,
I'm,
afraid
we,
the
other
stuff
I
mean
you
want.
You
want
to
try
to
talk
in
three
minutes.
M
Thank
you
for
that
opportunity
and
I
will
probably
take
two
if
I,
if
I
could
execute
a
move.
Next
slide
next
slide
this.
So
this
is
what
I
was
talking
about
with
making
sure
that
I
understood
what
the
scope
of
the
RTP
over
quick
draft
was
figuring
out.
What
a
AVP
profiles
to
register
has
been
easy,
because
every
time
I
decided
what
we
were
going
to
register.
Somebody
else
made
another
suggestion.
So
I
had
the
starting.
The
the
starting
proposal
was
mine,
the
top
line.
M
Then
we
moved
to
just
doing
ABP
avpf.
Then
we
said
oh
good
I.
Think
several
of
us
figure
this
out.
At
the
same
time,
oh,
we
need
to
prepend
UDP.
To
that,
then
we
said
oh
we're
going
to
do.
We
need
to
do
stream,
dgram
and
shared,
and
then
most
recently
had
the
conversation
a
little
bit
on
the
on
the
mailing
list
about
whether
we
needed
to
Define
TCP,
quick,
RTP
avpf,
to
allow
TCP
ice
path.
So
this
is
basically,
if
I
do
my
ice.
M
Lookups
can
I,
you
know
and
I
don't
get
anything
back
for
quick,
but
I
do
get
something
back
for
TCP.
Can
I
use
that,
and
that
was
the
that
was
the
question
you
know,
I
had
two
questions
for
the
group
which
are
better
on
the
mailing
list.
Anyway,
do
people
understand
that
last
one
and
do
people
agree?
This
is
why
I
would
like
to
adopt
this
draft
so
that
we
can
make
some
consistence
calls
and
nail
down
the
scope
and
a
few
things
like
that.
M
If
you
show
the
next
slide,
it
will
be
fun
because
we're
also
talking
about
quick,
doing
quick
congestion
control.
We
think
we
figured
out
how
to
do
this
and
we
you
know,
if
I,
we
need
to
figure
out
how
much
RTP
information
we're
going
to
be
able
to
replace
with
quick
information
and
not
that'll,
mean
theoretically
I
mean
in
practice
and
that
Loops
back
around
to
what
AVP
profiles
to
register
this.
This
concludes
my
abbreviated
Ted
talk.
Thank
you
for
coming
and
I
will
see
you
all
at
the
interim.
M
F
I
I
was
going
to
say
that
this
just
looks
like,
like
that's.
The
leap
like
I
think
there's
a
ton
of
things
that
we
need
to
hit
here
like
like
how
you
identify
the
flow
IDs
in
the
STP
that
are
presumably
going
to
be
used
and
how
you
end
the
negotiation
of
which
congestion
control
you
I
mean
like
it
seems
like
when
I
go
and
read
the
RTP
over
quick
draft,
a
ton
of
the
thing
that
clear
like
like
most
of
the
things
that
you
would
need
to
negotiate
to
make
that
draft
work.
F
Are
we
don't
have
a
way
to
do
in
this
at
all,
yet
so
I
I
think
this
is
barely
started,
that
we
should
I
think
I,
don't
know
how
we're
going
to
move
forward
on
this,
but
it's
it.
This
is.
This
is
not
at
all
ready
to
sort
of
adopt.
Quite
yet
I
mean
it's
missing
most
of
what
we
need
here.
So
we
need
to
get
a
bunch
of
those
in
and
I
apologize
for,
not
having
sent
comments
on
the
list.
F
I
will
try
and
send
stuff,
but
yeah
yeah,
yeah,
yeah,
yeah
yeah,
but
but
fair
I
I
just
think.
It's
I
show
this
in
the
comments,
but
there's
a
ton
of
stuff.
Here
we
need
to
figure
out
how
to
do
and
the
the
which
what
the
string
is
at
the
top
is
like.
Yes,
that
will
be
a
bike
shed
discussion,
but
it's
the
least
of
the
issues
yeah
and.
D
M
A
O
M
The
last
slide
in
started
out
with
requesting
that
the
chairs
considered
a
call
for
adoption
and
now,
okay.
A
M
F
A
All
right,
I,
guess,
Bernard
and
I
will
talk
about
that
or
sadly
we
did
not
have
enough
time
to
talk
about
this.
So
I
apologize
for
that
I
should
have
kept
more
control
over
the
previous
conversation
and
but
we
will
follow
up
on
the
list
and
we
will
have
an
interim
and
possibly
also
a
site,
a
virtual
side
meeting
about
aspirin,
which
we'll
also
announce
on
the
list,
and
thank
you
all
for
coming
and
see
you
around
the
meeting.