►
From YouTube: IETF103-AVTCORE-20181106-1120
Description
AVTCORE meeting session at IETF103
2018/11/06 1120
https://datatracker.ietf.org/meeting/103/proceedings/
A
Something
just
swell
so
Ronnie
is
taking
notes
in
the
ether
pad.
If
you
have
a
second
person
to
watch
that
say
neither
pad
and
fix
anything,
he
overlooks
with
nothing
you
a
bad
thing.
If
anybody
wants
to
volunteer
Bo,
okay
and
since
I
have
far
too
many
laptops
on
the
table,
I
can't
actually
pay
attention
to
the
jabber.
So
if
anybody
we
do
have,
we
do
have
remote
participants.
So
if
anybody
wants
to
be
anybody
in
that,
you
want
to
be
in
the
jabber
room.
A
A
A
A
B
A
C
A
A
This
is
following
the
working
new
blast
call.
So
people
who
had
comments
and
working
class
call,
which
is
I
think
mostly
me
at
Magnus,
should
read
over
the
changes
and
see
if
his
art
hours
were
reflected
and
follow
up
on
the
list.
Oh
I,
think
I
see
my
outside
that's
looks
like
an
almost
silhouette.
There
I
think
he's
going
to
the
other
door.
Okay,
somebody
make
sure
the
door
isn't.
It
is
mo
excellent.
E
E
The
the
one
I
should
probably
call
out
is
there
was
a
tl0
pic
index.
There
was
a
note
that
it
was
valid
to
have
zero
as
a
valid
running
index,
and
so
there's
a
question
about
whether
or
not
if
it's
unknown,
is
it
valid
to
still
mark
it
as
zero.
So
we
updated
text
to
say
if
it's
unknown,
you
actually
must
submit
it
so
that
that
a
receiver
can
be
aware
whether
it's
truly.
E
Make
me
so
I
should
clarify
the
text
to
say:
omit
means
a
reduced
length,
so
it
means
truly
remove
it
and
reduce
the
length
field.
So
it's
not
in
the
payload
at
all,
and
there
was
also
a
point
about
lrrr,
since
we
updated
the
the
restriction
frame
marking
that
you
can
only
use
it
for
temporally
nested
streams,
so
LR
temporal
air
refresh
is
really
never
needed
because
the
the
streams
are
always
self
refreshing
because
they're
nested,
but
that
that
raises
an
issue
that
is
this
restriction.
E
Okay
for
for
future
needs
and
I'm
aware
of
a
few
I'm
aware
of
some
work
that
that
is
not
planning
to
do
nested
streams
and
in
the
restrictive
way
that
frame
working
currently
says.
So,
that's
to
me,
that's
the
only
open
issue.
Whether
or
not
people
have
an
opinion
of.
Is
that
too
restrictive
or
not.
A
E
If,
then,
we
have
a
Biss,
you
know
you
know
six
weeks
six
months
later,
because
a
new
payload
format
wants
to
do
or
even
existing
payload
formats
want
to
do.
You
know
more
elaborate
markings,
more
elaborate
structures,
scalability
structures,
so
I'll
send
a
email
to
the
list
about
what
the
issues
are,
but
all
the
other
points
are
mostly
editorial.
So
I
don't
think
discussion.
A
A
H
Ping
book
seems
to
turned
into
a
pink
cross,
which
I'm
not
sure,
is
an
improvement
all
right,
so
hi
I'm,
Colin,
Perkins
I'm
gonna
talk
about
the
congestion
control
feedback,
so
this
is
a
joint
draft
with
ahead
Varun
and
Michael,
but
none
of
the
co-authors
have
seen
these
slides
and
commented.
So
this
is
entirely
my
fault
and
blame
me
for
anything.
H
So
we
have
the
congestion
control
feedback
draft,
which
we've
discussed
a
bunch
of
times.
This
is
the
the
outline
of
the
format.
I
think
the
only
change
which
is
going
to
happen
is
that
the
insect
post
one
is
going
to
turn
into
a
lambda
field.
At
some
point,
I
think
we
discuss
that
at
the
last
meeting,
Jonathan
and/or
take
Neal
and
I
think
we
had
someone
remotes
socio
remotely
we're
trying
to
implement
this
at
the
hackathon
over
the
weekend
and
Jonathan
sent
some
feedback
based
on
his
experiences.
Oh
I
guess:
they're
expert
their
experience.
A
A
H
H
H
Reports
then
you
just
realize
you've
just
got
the
time
step
left,
and
that
means
you've
got
to
the
end,
and
this
is
passed.
It's
unambiguous
to
pass,
but
it's
a
bit
weird
and
it's
perhaps
a
little
bit
of
a
nuisance.
The
problem
is:
there's
not
actually
a
lot
of
space
for
a
report
count
right.
We
we
could
stick
one
at
the
beginning
of
the
packets
that
a
misaligns,
everything
and
exactly
I
think
also
conflicts
with
the
standard
for
congestion
control,
feedback,
packets,
which
ones
the
SSR
season.
H
A
H
I
H
A
H
Okay,
all
right
timing,
so
the
current
version.
The
draft
says
that
the
time
stamps
used
for
the
report
type
that
the
clock
used
for
the
reports.
Time
stamp
is
derived
from
the
same
clock
used
to
generate
the
MTP
time
stamp
in
SR
packets
and
it
seems
Jonathan,
is
not
desperately
thrilled
by
that
choice.
H
If
the
rate
is
used,
I
don't
know,
I
thought
it
was
useful
that
we
have
an
unambiguous
reference
to
which
clock
to
use,
but
maybe
that
doesn't
actually
matter
so
everything
in
practice.
I,
don't
think
it
makes
sense
to
use
the
media
time
stamp
here,
since
there
are
a
bunch
of
different
clock
rates.
I
think
we
want
something
more
consistent
than
that,
especially.
H
A
A
Again,
as
an
individual
I,
don't
I'm
not
going
to
be
standing
up
because
yeah
yeah
there's
a
lot
of
stuff
on
the
people's
yeah,
so
yeah.
My
main
concern
is
that
you
know
typically,
your
auntie
be
time
stamp
will
come
from
something
like
the
POSIX
clock
real
time
if
people
are
familiar
with
that
which
is
basically
good
time
of
day,
whereas
for
send
time
stamp,
which
is
thus,
you
know,
subject
to
adjustments.
As
you
know,
MTP
kicks
in,
or
you
know,
somebody
discovers
their
clock
is
off.
H
C
C
If
he
has
this
downside,
it
made
results
in
discontinuities
in
in
the
intimate
time
measurements
in
herself
and
maybe
recommend
just
recommend,
saying:
choose
a
clock
that
doesn't
have
this
property
and
that
should
be
sufficient
for
this
document.
But
maybe
we
can
even
reference
some
of
the
reasonable
clock
formats
if
they
are
available
based
on
the
box
or
draft.
So.
F
A
Yeah
I
guess
the
main
thing
is
there.
Is
there
ever
any
interesting
reason
to
correlate
these
timestamps
to
anything
other
than
each
other
I
mean?
Is
there
a
reason
why
you
want
to
be
able
to
say
when
this
feedback
message
was
generated
versus
assess
our
time
step,
or
is
our
duties
only
need
to
be
relative
to
other
CC
feedback
messages.
H
I,
don't
know,
my
guess
would
be
that
people
are
going
to
at
some
point
and
for
some
random
reason
dislike
to
compare
them
with
the
timing
of
all
the
other
things
which
are
timed
even
if
we
don't
think
we
can't
think
of
a
reason
to
do
that
now,
but
I
yeah
I,
don't
have
a
reason
why
you
would
care
about
that.
Currently.
H
H
A
A
H
A
H
D
H
J
H
H
A
H
A
They
had
theythey,
they
did
something
they
don't
fit
in
the
report.
It's
that
they
is
that
their
arrival
time
doesn't
fit.
They
can't
be
represented
at
the
arrival
time
offset
I've,
given
that
the
arrival
time
offset
is
epsilon
under
eight
seconds.
This
basically
requires
your
reporting
interval
to
have
gone
above
eight
seconds
yeah.
So
basically
so
this
would
but
that's
a
vain
is
that
you
know
you
can
see
and,
and
also
things
are
in
turrets
reordered
by
more
than
eight
seconds.
Essentially,
this.
A
H
A
H
A
This
is
the
same
issue
as
previously
that
the
time
the
report
was
so,
if
you
discover
that
you
can't
represent
well,
you
know
you've
got
more
than
eight
seconds
of
evidence
to
report.
Yes,
so
you
have
so
one
of
them.
You
have
to
pretend
that
you
generated
this
report
eight
seconds
ago,
so
that
you
can
represent
the
arrival
time
offsets
of
the
oldest
packets.
Yes,
then,
the
report
types
have
will
not
be
when
the
packet,
when
this
report
was
generated,
because
that's
now
you
know
you're
faking
it
speaking
eight
seconds
ago.
A
A
A
H
H
H
I
A
H
A
I
H
H
Okay,
so
we
currently
say
that
the
consecutive
report
should
just
be
consecutive
sequence.
Number
ranges
should
not
overlap.
Obviously,
if
you
have
a
big
outage,
then
you
don't
want
to
send
a
report
on
the
last
ten
billion
packet
or
ten
thousand
packets
which
which
were
in
the
outage.
So
we
need
some
words
to
say,
do
something
sensible
as
an
outage
and
that's
just
a
bit.
There's.
A
All
this,
because
my
email
will
sort
of
incoherent,
there's
also
the
converse
case
here
that
if
you
had
package,
sometimes
you'll
actually
get
a
slight
overlapping
reports.
If
you
have
to
say
pact
and
reordering
right
at
the
plate,
you
set
a
feedback.
You
want
to
actually
go
back
and
say:
hey
yeah,
so
yeah
I,
previously
reported
through
packet.
Seven
saying
back
at
six
was
lost
now
a
reporting
saying
that
get
six
arrived
and
yeah
packet
seven
still
arrived.
And
yes
so
there's
some
overlap.
Yeah,
okay,.
H
So
again,
that's
just
a
clarification
of
exactly
what
to
do
in
the
budget
corner
cases
report
on
duplicates.
If
you
get
a
packet
and
if
you
have
multiple
copies
of
a
packet
which
one
should
you
report
on
I
suspect
it
doesn't
matter.
My
my
gut
feeling
would
be
to
say
we
report
on
the
last
copy
of
the
packet
received.
But
if
you
want
to
make
it
first,
they
don't
care
I.
H
K
K
E
I
H
A
E
Yeah
this
is
the
the
firt.
This
is
the
one
that
actually
made
me
think
about.
We
really
need
to
bring
this
up
to
the
congestion
control
pointers.
The
other
ones
may
also
be
relevant,
but
this
one
immediately
struck
me
is
that
if
I
was
implementing
the
congestion
control,
I
would
want
to
know
the
first
packet
received,
because
the
deltas
that
I'm
calculating
and
and
the
the
the
delivery
offsets
that
I'm
calculating
the
duplicates
are
irrelevant
to
me.
E
H
I
mean
you're
right
that
we
should
probably
bring
it
up
for
the
congestion
control
people.
Yeah
certainly
thought
about
that:
okay,
okay,
which
SSRC
ste
reports
button.
Sir
currently
says
reports
on
every
SS,
SE,
that's
being
congestion
controls.
The
issue
is,
of
course,
to
receive
a
counter
which
sources
are
being
congestion
controlled.
So
you
should
probably
just
say
report
on
every
active
SSRC.
H
H
Can
imagine
weird
corner
cases
like,
for
example,
if
you're
sending
variable
bitrate
video,
along
with
low
rate,
constant
bitrate
audio
you
possibly
don't
care
about
reporting
on
the
audio
for
congestion
control,
because
you
can't
congestion
control
is
anything
in
the
congestion
control
is
just
to
stop
sending
it,
and
you
know
if
you
have
10
kilobits
of
audio
and
5
megabits
of
video.
Who
cares
about
the
audio?
So
maybe
you
might
want
to
do
that.
Yeah.
H
I
Told
me
I
think
in
this
case
it's
this
should
apply
to
your
RTP
transport,
not
to
the
actual
coded
correct.
This
is
agnostic
of
the
codec,
but
yes,
the
rtcp
feedback
specification
is
I
mean
yeah.
You
showed
me
like.
The
implementation
worst
are
I
guess
I
mean
the
question
is:
if
that
needs
to
be
written
down
here
in
the
draft
to
say
like
it
always
needs
to
be
happen
with
for
all
the
codecs
you're
offering
having
that
I
can.
H
A
H
D
Difference
how
do
lava
strum
and
the
we
recently
started
out
on
this
stuff
was
because
we
need
a
transport
right
congestion
control
implementing
the
mechanism
in
such
a
way
that
you
can
usefully
use
feedback
on.
Only
a
few
packet
types
in
this
session
is
going
to
be
severely
complicating
implementations
and
make
it
less
useful
for
what
we
set
out
to
do
so.
I'd
strongly
strongly
strongly
at
least
strongly
suggest
so
that
we
just
say
report
for
everything.
D
All
the
time
don't
and
implementers
should
not
have
to
care
about
the
case
where
you,
the
implementers
of
the
fee
of
the
sending
feedback,
should
not
have
to
care
what
what
the
other
side
does
with
it.
That's
the
whole
point
and
the
sender
has
to
sort
out
yes,
I'm
getting
packet
loss
and
now
I
have
to
allocate
bandwidth
between
the
text
channel
and
audio
channel
and
the
video
channel.
That's
the
sender's
problem
sure,
but
it's
the
sender's
problem
in
this
case
as
well.
Yes,.
H
D
H
A
D
If
you,
if
you
specify
for
some
media
sections
and
not
others,
well,
that's
the
thing
something
you
can
do
with
it.
We
will
STP,
that's
sad,
but
I
think
you
should
I
think
that
the
the
use
case
we
definitely
want
to
support
if
congestion
control
for
a
whole
transport
and
anything
that
makes
that
life
more
complicated
for
implementers
should
go
away
until
unless
it
has
a
compelling
use
case
okay,
so
we
just
specify
that
if
you
have
to
specify
all
types.
H
I
Because
if
we
allow
that,
then
you
actually
need
to
require
from
the
implementers
to
go
through
all
the
pale
up
types
and
ensure
that
it's
actually
turned
on
for
all
of
them
and
handle
the
corner
cases
of
like
what
happens.
If
it's
not
implement
not
offered
on
one
of
them.
So
I
think
the
easiest
solution,
then,
is
to
just
say,
like
it
has
to
be
done
both
star.
Okay,
the
end
of
story,
okay,
sure
that
makes
sense.
E
A
That
separate
section
is
a
whole
other
thing,
but
but
I
think
you
would
want
that
because
you
want
to
get
feedback
because
again
it's
you're
kidding.
You
want
to
figure
out
how
much
total
so
I
was
getting
through
on
the
session
and
obviously
what's
what's
experiencing,
congestion,
which
particular
SRC
has
experienced.
The
congestion
does
not
have
to
be
which,
just
as
our
C's
you'll
adjust.
A
L
So
can
you
hear
me
yes,
okay,
cool
all
right.
This
is
a
presentation
about
quick
multiplexing.
It's
a
follow-on
to
a
presentation
that
Cullen
made
at
IETF
100,
so
we're
gonna
give
an
update
on
where
we
are
and
what
I'd
like
to
recommend
the
group
do
from
here.
Next
slide:
okay,
so
just
recapping
the
problem
Creek
is
potentially
attractive
as
a
peer
data
exchange
mechanism
for
WebRTC
applications.
L
L
L
So
some
non
requirements
are
support
for
turn
channel
multiplexing,
that's
an
optimization
which
I
believe
is
not
supported
in
any
web,
urges
the
implementation,
where
you
have
a
core
architect.
Prefix
excited
the
standard
36
like
text
on
overhead.
Also
ZRTP
is
used
in
wherever
to
see
as
far
as
I
know
and
that's
an
alternate
key
exchange
mechanism.
So
we
don't
require
that
these
actually
work.
Although
okay,
they
don't
break
anything
Thanks.
L
L
So
this
was
the
t
multiplex
for
clothes
that
I
kept
running
underneath
it.
The
main
differences
here
are
that
there's
potentially
some
overlap
between
quick
and
the
turn
channel,
but
as
I
mentioned
that
isn't
really
consequential
cause
where'd,
you
see
em
invincibility
valve
support
the
turn
child
and
then
quick
is
also
in
the
range
252
to
5,
which
is
the
long
hitter.
So
basically,
this
this
meets
all
the
requirements
and
some
things
that
were
non
requirements
like
not
conflicting
the
vo
to
be
next.
L
Okay,
now
a
few
words
about
the
DTLS
allocation.
Here,
it's
important
to
understand
that
currently
DTLS
does
not
use
anywhere
near
the
full
allocation.
As
you
can
see,
this
is
the
Ayane
table
and
for
DTLS
the
requires
coordination,
which
means
a
potential
conflict
with
79-83
is
in
the
0
to
19,
and
the
60
40
to
55
range,
but
25
to
63
are
currently
unassigned.
L
L
So,
since
the
presentation,
I
tip
100,
the
idea
of
using
quick
and
web
urgency
has
gained
some
traction.
We
have
a
JavaScript
API
spec
on
their
active
development
in
w3c,
its
protrude
a
lot
from
annotation
experience
and
has
been
following
the
quick
transport
dock,
adding
support
for
unidirectional
streams
as
an
example
and
lots
of
lots
of
interest
in
it
and
some
implementations
are
coming,
there's
been
an
attempt
to
implement
filed.
There
are
people
experimenting
potentially
with
additional
scenarios
like
carriage
of
media,
so
so
quite
a
bit
of
interest
here.
Next.
L
So
why
can't
we
declare
victory
at
ITF?
100
basically
said
we
would
document
this
purely
in
the
quick
spec.
What's
wrong
with
that.
Well,
history
shows
that
if
you
have
an
undocumented
algorithm
or
agreement,
something
is
likely
to
go
wrong
over
time.
One
of
the
things
that
can
go
wrong
is,
if
you
don't
document
8
document
requirements
in
the
IANA
registries,
like
what
we
have
for
DTLS.
Someone
could
assign
a
code
point
and
step
on
something
without
realizing.
L
Another
problem
is
that
I
think
more
relevant
here
is
that
if
you
have
an
undocumented
algorithm,
it's
likely
particularly
one
that
changes
with
different
drafts
of
quick,
it's
likely
to
exhibit
interoperability
problems
and
as
I'll
describe
the
original
proposal
from
IGF
100
needs
to
change
a
bit,
and
if
we
don't
write
this
down
eventually,
some
developer
is
going
to
find
some
old
set
of
slides,
go
implement
it
in
something.
Bad
will
happen,
and
that's
particularly
true,
since
we
have
trials
of
approaching
with
this
and
once
those
are
out,
people
will
start
to
depend
on
multiplexing.
L
You've
got
whereby
GC,
which
is
being
deployed
all
over
the
place,
some
100
applications,
1.5
billion
users.
So
it's
very
easy
for
something
to
get
out
in
the
wild
and
be
very
difficult
to
recall
if
it's
broken,
and
so
at
this
point,
if
there
are
problems
with
multi
node,
some
support
that
would
have
consequences
and
I
believe
I'll.
Try
to
make
the
argument
that
are
we
needed
to
document
this
in
an
RFC
79-83
this
just
so
developers
know
how
it
all
works.
L
L
So
this
was
particularly
brought
home
to
me
and
going
over
the
transport
draft
version
16
and
comparing
it
to
the
o8
and
trying
to
figure
out
what
changes
were
needed
in
the
d
multiplex
algorithm,
the
long
header
didn't
change
and
the
type
values
field
values
are
pretty
much
the
same,
so
that
was
more
or
less
as
it
was
in
Colin's
presentation.
So
at
least
that
part
is
good
expired,
but
I
noticed
a
few
things
that
I
had
to
scratch.
L
My
head
about
one
is
that
there's
a
stateless
reset
packet
with
a
key
phase
bit
so
the
the
actual
short
header
has
changed.
There
was
a
C
bit
in
it
that
we
talked
about
it.
I
tip
100,
it's
now
a
K
bit
for
key
phase,
and
this
brings
up
the
possibility
of
potential
overlap
for
DTLS,
namely
code
point
48,
as
I
described
earlier.
It's
not
actually
48
adnan.
L
L
So
the
short
packet
header
header
has
also
changed,
and
there
there's
now
and
some
orbits,
which
you
said
randomly
that
generates
for
point
value,
is
48
to
55
for
the
potential
overlap
with
each
LS
for
a
k,
value
of
1,
that's
in
the
range
112
to
119,
which
was
taken
into
account
in
the
previous
I
chip
100
proposal.
So
that's
not
an
issue.
But
again
we
this
potential
overlap
with
GG
LS,
which
is
not
documented
in,
are
currently
in
RFC
1793
Thanks.
L
L
So,
based
on
what
I've
just
shown
you
here's,
what
I
think
the
revised
e
multiplex
proposal
looks
like
and
again.
This
is
something
I
think
you
has
to
be
double
a
triple
check,
but
here's
where
I
think
it
ends
up
which
is
pretty
similar.
What
came
before,
except
that
code
points
48
to
55,
would
be
forwarded
to
quick
that
would
be
from
the
short
header.
L
You'd
get
one
swell
to
119,
also
from
a
short
header,
potentially
for
4
different
values
of
the
Cape
it
you
would
forward
128
1,
1901,
RTP
and
rtcp,
but
only
if
the
version
field,
the
next
32
bits
was
not
0
and
then
I
think
52
to
55
would
still
go
to
a
quick
and
that's
the
long
header,
so
a
little
bit
different
from
what
we
had
an
idea.
100
I
think
still
workable,
but
a
little
a
little
bit
different
and
also
some
additional
checks
that
have
to
be
done
from
what
we
had
there.
E
L
Rely
on
good
point
mode.
This
is
why
I
think
we'd
have
to
discuss
this
good,
double
double
check.
This
I
think
that
yeah
there
would
be.
If
you
potentially
had
a
time
stamp
of
0,
you
could
make
mistake.
There
might
be
something
else
we
would
have
to
look
at.
In
that
case,
I
guess
the
point
I'm
trying
to
make
your
mo
is
that
this
is
worth
documenting
and
reviewing
in
the
ITF
rather
than
leaving
this.
E
And
one
other
questions
so
sorry,
I
forgot,
where
things
landed
on
the
multiplexing
draft
I
thought
those
discussion
of
squeezing
the
turn
range
to
something
much
narrower.
That
didn't
happen.
It's
still
the
full
range
in
the
in
the
multiplexing
draft,
the
RTP
multiplexing
draft
of
squeezing
the
turn
range
into
something
very
narrow,
even
narrower
than
this
in
this
64-bit
79.
Well,
I.
L
Don't
recall
it.
That's
certainly
something
that
again.
If
we
had
a
draft
to
actually
talk
about,
we
could
we
could
do
and
might
well
be
worthwhile,
so
I
guess
that
would
be
another
reason
to
actually
have
a
document
and
put
it
through
the
process
so
that
we
look
at
it
and
understand
exactly
where,
where
we
stand,
I.
A
L
A
E
So
I
think
the
problem
here
is
that
we're
thinking
about
it
only
from
one
entity's
viewpoint
and
there's,
maybe
multiple
entities
that
are
concerned
about
this
and
want
to
do.
It
may
not
actually
be
the
receiver
that
that
cares
about
this.
There
may
be,
you
know,
stateful
boxes,
on
the
path
that
you
know.
E
L
E
A
A
Yeah
I
would
I
was
going
to
say,
is
I
feel
like
quick
sort
of
had
this
there's
what
the
current
quick
to
be
doing
s
they're,
calling
it
now
is
doing
and
then
there's
what
quick
is
guaranteeing
for
the
future,
which
is
the
wire
image
and
I
feel
like
this
needs
to
be
more.
What
is
the
wire
image
guaranteeing
which
might
be
need
to
talk
to
I?
Guess
it's
Martin
Thompson
about
just
sort
of
say:
what
is
he
willing
to
say
that
click
is
going
to
guarantee
not
just
in
this
version
but
in
all
future.
L
Versions
of
hotel,
the
agreement
was
that
we
were
only
talking
about
quick
version,
one
because,
by
definition,
the
quick
version
numbers,
if
you
go
to
a
different
version,
negotiated
a
different
version.
You
can
change
almost
anything
so
and
I
think
the
thinking
was
basically
the
inversion
to
you
know.
Who
knows
what
it
could
do,
so
you
can't
really,
you
know,
make
absolute
promises
about
it,
but
so
that
so
my
recommendation
would
be
to
just
try
to
document
what
goes
on
and
quick
v1.
H
A
My
advice
would
be
submitted,
draft
for
I,
guess,
progress,
the
next
meeting
and
then,
or
even
even
sooner.
We
don't
have
to
do
everything
at
meetings
but
submit
a
draft,
and
we
will
take
a
look
at
the
side
at
that
months.
We
have
a
draft
look
at
whatever
you
want.
I've
got
it
as
a
go
through
this
any
pupils.
K
L
A
M
Okay,
so
hi
I'm
York-
and
this
is
a
very
quick
heads
up
there-
of
a
about
a
piece
of
work
that
:
I
put
together
and
responds
to
all
the
artifact
engineering
work
that
has
been
going
around
and
around
RTP
and
quick
and
running
real
time
streams
over
over
quake.
So
this
came
from
a
paper
we
submitted
to
a
workshop,
that's
going
to
be
published
in
December
there's
and
we
submit.
M
M
The
the
main
observation
is
that
many
people
have
been
looking
at
different
flavors
of
running
RTP
over
a
quick.
We
are
guilty
of
of
a
draft
of
outlining
some
of
the
ideas
ourselves,
but
quite
a
bit
of
these
have
been
done
more
or
less
in
an
internet
hoc
fashion.
A
M
Okay,
so
in
the
slides
that
will
be
there,
there
is
a
table
with
21
features
that
describe
what
RTP
has
been
doing,
how
this
is
crimp,
how
this
could
be
addressed
on
top
of
quake
and
how
that
could
in
the
end,
be
all
this.
But
the
fourth
slide
is
here
the
fourth
one
here,
but
not
the
third
that
the
last
mode,
not
the
one
before
anyway.
So
we
have
a
big
tape.
Yeah.
A
A
M
M
Any
and
it's
too
long
to
go
through
this
anyway,
so
take
a
look
at
it
at
the
paper
at
that
table.
Out
of
this
analysis,
we
try
to
come
up
with
a
minimum
feature
set
that
one
could
use
as
a
strawman
proposal
on
how
to
co-evolved
RTP
and
quick
advance,
and
we
call
these
arty
streams
that
have
minimal
edu
sequence
numbering
rather
rather
than
fight
offsets.
M
We
have
media
specific
timestamps,
as
we
know
from
RTP
ways
to
control
we
transmissions
on
a
per
channel
fine-grained
basis,
and
then
we
have
more
detailed
reception
reporting,
which
is
what
we
figured
would
be.
The
use
for
common
transport
layer
features
that
are
worthwhile
adding
to
quick.
We
also
have
a
wall
top
wall,
clock
time,
synchronization
for
interest
into
the
stream,
what
our
TCP
usually
does
by,
by
means
of
a
separate
method,
a
packet
type
and
any
push
of
all
the
rest
to
the
application
layer.
M
The
nice
thing
about
this
that
most
of
these
things
are
optional.
So
if
you
leave
out
everything
yet
this
reduces
nicely
to
the
Datagram
style
service
that
we
have
right
now,
except
that
it
doesn't
use
this
Ness.
The
strange
framing,
so
this
is
a
heads
up,
because
we
feel
that
probably
quite
a
few
endpoints
will
be
implementing
quick
and
we
will
also
want
to
do
real-time
at
some
point,
and
so
we
want
to
come
up
with
something
that
makes
sense
in
the
long
run.