►
From YouTube: IETF99-AVTCORE-20170721-1150
Description
AVTCORE meeting session at IETF99
2017/07/21 1150
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
C
B
D
B
They
are
excellent,
all
right,
okay,
so
now
I
want
yes
all
right.
Yes,
oh
yes,
we
have.
No
no
ticker
is
Varun,
ever
described
is
Jake,
blue
fees
are
going
around,
make
sure
you
sign
them
and
medico
is
going
and
we
have
a
few
people
in
there
Bernard
and
Randall.
That's
good!
Okay!
No!
Well!
This
is
the
exciting
midnight
well
which,
as
far
as
I,
can
tell
its
primary
difference.
B
Is
that
the
we
need
to
have
a
new
version
of
the
RFC,
which
is
now
81
79,
let's
probably
other
diff,
but
I
haven't
read
it,
which
is
very
bad
because
I
should
have
so
you
read
it
and
tell
me
what
it
says
all
right.
So
what
we're
doing
today,
starting
with
our
addenda,
bash
and
status,
update,
which
is
what
we're
doing
right
now
and
then
we
will
have
frame
marketing
with
moe.
Then
we'll
have
our
M
yet
got
feedback
with
Colin
look
confused
or
is
that
just
what
you
usually
look
Bohe?
B
Are
you
setting
up
for
a
reason
or
you
just
and
then
we
will
have
anything
else?
Anybody
wants
to
talk
about.
So
our
working
group
documents.
We
have
a
number
of
working
group
documents
which
are
in
the
RFC
editor
queue.
We
have
three
documents
with
your
mystery
unbundle,
so
we
can't
do
anything
about
that.
We
have
one
document
which
is
mr.
a
for
50
to
85
bits
which
we
can
do
something
about.
Yes,.
E
B
As
individuals
can
do
something
about
bundle,
we
as
a
the
a
media
working
group
cannot
so
yes
and
then
spicy
notification
is
miss
Ralph
on
50
to
85
bits
which
we
can
do
something
about
and
lrr
is
miss
reference
frame
marking
which
hopefully
a
little
bit
something
about
actually
both
of
those.
Hopefully
we'll
do
some
about
today
and
then
re
SRTP
is
and
I
guess
she
evaluation
and
it's
added
some
comments
so
50
to
85
this
and
I
usually
review.
B
B
D
F
Case
for
identical
was
basic,
because
this
is
configuration
on
the
RTP
session
level.
Yes,
you
could
for
individual
media
sources
or
ministry
has
different
needs,
because
if
you
bundle
you
can
hold
the
video
and
therefore
different
sets
of
parameters
and
therefore
different
set
of
ID's,
but
from
from
my
perspective
the
whole
lotta
position.
Do
we
need
to
have
the
capability
to
handlings,
both
I
wasn't
saying
machst
or
a
thing
both
one
of
two
bytes
allowed
to
be
able
to
even
handle
that
case
anyway.
F
So
that's
why
I'm
and
for
these
kind
of
arguments
that
was
made
it's
all
about
having
certain
if
you
have
as
a
client
that
forwards
or
have
independent
parts
which
creates
and
or
restricted
the
kind
of
RTP
session,
that
multiplexing
single
layer
could
actually
still
make
it
into
this
layer
and
I,
don't
see
that
everyone
else
needs
to
pay
for
the
complexity
for
those
entities,
they
should
pay
their
price
themselves.
That's
my
base.
My
argument.
G
At
least
I
I
know
fun.
We
had
in
past
equipment
that
was
doing
the
same.
That
would
probably
be
relevant
for
that.
It
was
like
connecting
a
video
conferencing
system
to
it.
Phone
and
just
the
video
was
going
from
the
phone
he
was
doing
all
they
call
cetera
because
it
was,
it
was
a
PBX
and
just
the
video
was
coming.
G
Is
our
tp'ed
I
redirected
to
the
to
the
to
the
V
to
the
video
system,
so
I
mean
so
at
least
I
I
know
of
such
a
product
that
worth
that
way,
and
at
least
in
my
perspective,
is
what's
the
extra
complexity.
On
the
other
hand,
I
mean
you
can
always
I
mean
when
you
do
normal,
you
can
do
identical.
When
you
do
identical,
you
cannot
do
normal.
G
B
Jonathan
lights
from
the
floor
because
I'm
speaking
as
individual,
so
I
mean
I
think
the
goal
here
is
that
you
know
we
want
it.
We
want
to
move
everybody
to
extract
a
lot
of
mixed
and
it's
not
very
hard
to
pull
back.
If
you
actually
have
the
tube
light
form
anyway,
so
I
mean
in
fact
you
active.
Just
kind
of
work
did
not
allow
mixed,
so
no
dye,
so
I
mean
I
would
argue
for
it.
B
So
I
guess
and
the
counter-argument
to
Ronnie
is
that
it's
not
I
mean
you
can
always
say
identical,
but
the
problem
is
you
know?
What
is
you
know?
It's
it's.
What
does
your
pure?
Do?
That's
the
problem
right!
It's
an
offer
answer!
You
have
to
worry
about
what
you
know,
situation
where
you
have
some
streams
that
are
one
way
at
some
screen
to
the
other
way.
B
H
G
Just
to
answer
to
two
more:
that
was
the
point
that
Magnus's
may
make
was
making
it
says:
if
you
have
this
problem,
then
you
should.
The
burden
should
be
on
the
end
point.
It
doesn't
support
it
or
the
sort
of
the
equipment
that
this
doesn't
support
it
to
change
the
the
the
internally,
the
Heather
extension
to
them.
I
think
I
mean
I'm,
not
gonna,
be
strong
feeling.
So
if
you
everybody
agrees
on.
B
J
B
G
B
G
B
I
L
Needed
it
and
things
like
that,
so
that
X
can
actually
be
moved
out
of
the
but
I
think
we
would
need
a
lot
more
in
terms
of
feedback
or
reviewers
to
in
terms
of
implementations.
I
think
we've
already
demonstrated
Lee
there,
three
or
four
current
implementations.
You've
done,
two
of
them
independently
graduate
students
and
I
think
Cisco
and
I
forget
another
company.
Canon
had
one
so
in
terms
of
that
we've
already
gotten
feedback
from
implementers
and
looks
good.
L
L
L
Group's
bailiwick
right
so-
and
there
are
two
parts
to
it,
so
people
who
are
interested
in
mp,
our
DP
and
DTLS
interworking,
should
read
that
draft.
Of
course,
I
have
fun
proposal
there,
but
there
are
two
proposals
in
the
draft,
so
I,
like
I,
think
people
will
discuss
that
in
Singapore,
so
that
I
think
is
the
stumbling
block.
Maybe
but
I'm
not
the
only
person
with
security
background,
so
I
would
really
appreciate
anything
up
that
I
can
get
so
is.
L
B
B
B
B
L
G
H
H
So
some
of
the
things
that
it
can
do
with
these
frame
markings
is
be
able
to
provide
clean
video
when
speaker
switches
so
know
where
the
intro
boundaries
are
between
frames.
So
it
doesn't
forward
a
bad
or
artifact
video
to
the
end
points
during
packet
loss
it'll
know
how
to
recover
so
that
there's
dependencies
met
between
the
video
frames
and
during
congestion
it'll
be
able
to
drop
less
important
packets,
making
better
more
intelligent
decision
about,
what's
better,
to
draw
up
towards
Laura,
lower
bandwidth
in
points
and
for
endpoints.
H
They
can
also
get
some
benefits
by
being
able
to
make
better
every
decisions
next
slide.
So
this
is
the
layout
of
the
extension
there's
two
variants
of
it
short
and
long
so
that
l
equals
2.
/
0
is
a
length
of
either
a
one-bite
extension
width
which
is
0
and
there's
a
3
by
2
extension
when
ellis
to
the
one-bite.
Only
has
the
the
indicator
bits
s,
CID,
start
end
and
independent
and
discardable
frame,
and
then
the
the
longer
extension
has
layer
information.
H
It
has
a
the
temporal
layer,
ID
and
the
spatial
quality
layer,
IDs
and
also
the
temporal
layer
picture
index
next
slide.
So
the
changes
there
was
a
two
major
changes
on
a
major
but
two
substantive
change:
changes
to
the
layer,
ID
mappings.
There
was
discussion
about
getting
the
vp9
section
right
and
since
it's
in
flux,
we
decided
to
remove
the
vp9
section
completely,
so,
basically
what
layer?
What
is
documented
in
the
draft?
Now
our
existing
RFC's
so
currently
use
billet
formats
that
are
ready,
RFC's.
H
We
document
what
the
lid
mappings
should
be,
but
any
new
payload
will
document
it
in
their
payloads
back.
So
we
basically
moved
vp9
out
and
it's
now
in
the
vp9
spec
and
for
future
codecs
that'll
also
be
the
same,
and
we
added
some
references
for
the
current
payload
specs
and
then
also
under
the
usage
considerations.
There
was
a
discussion
about
how
to
actually
do
the
the
discard
priority.
There's
a
discard
a
little
bit,
but
then
there's
also
temporal
special
layer
IDs.
H
So
we
added
some
text
about
when
you
should
be
able
to
do
the
discard
and
then
finally,
it
was
clear
that
especially
from
the
hell
are
our
discussions
that
there's
some
scalability
structures,
which
are
too
complex
for
frame
marking
too
to
capture.
So
we
added
a
section.
This
is
not
recommended
for
those
complex
structures.
I
B
H
J
I
L
B
B
H
I'll
add
a
note
in
there
that
yeah
several
scale
is
kind
of
built
into
every
codec,
so
they
were
all
of
them.
Make
a
note
just
adds
it
scalable.
Alright
next
slide
this
guy
priority.
So
this
was
the
text
that
was
added
that
he'd
make
use
of
the
discard
bit
when
available.
That'd
be
the
first
priority
to
discard,
but
then
you
can
also
make
use
of
the
highest
values
of
T,
ID
and
lid,
because
those
indicate
the
highest
temporal
and
spatial
enhancement
layers
and
those
layers
tend
to
have
fewer
dependencies
on
them.
H
H
B
Is
okay
I
think
you
want
to
build,
you
want
to
say,
is
what
can
a
receiver
of
a
stream
using
frame
marking
depend
on
that's
the
characteristics
of
the
stream
having
you
need
to
say?
Not
just
you
know,
yeah
don't
use
it
unless
it's
officially
has
these
characteristics
that
the
receiver
can
definitively.
You
know
count
on.
E
Yeah
Kanpur
can
see,
I
mean
the
the
problem
I'm.
Having
with
this
text
is
that
it's
it's
not
really
specifically
enough
to
be
actionable.
It's
a
if
things
are
difficult,
then
don't
do
it,
but
it
doesn't
define
what
difficult
is
so
it
I
think.
Ideally
it
needs
to
say.
If
you
have
these
particular
characteristics,
then
you
know
you
probably
shouldn't
do
this
yeah.
H
Beyond
that
we
can.
We
can
document
what
kinds
of
spatial
work
so
spatial
where
they
only
refer
to
lower
layers
and
temporally
in
your
same
layer
could
also
work.
There's
not
a
good
name
for
that.
So
it's
gonna
gonna
be
kind
of
a
wishy-washy
description,
but
we
can
document
that,
but
then,
outside
of
that
I,
don't
know
of
anything
that
is
really
useful
to
guide
on.
Everything
else
to
me
would
be
kind
of
complex
in
a
regular
yeah.
E
E
B
H
G
I
I
think
these
questions
may
be
related
to
the
previous
one
of
the
with
respect
to
spatial.
Let
me
try
to
put
forward
something
that
that
might
make
sense,
I.
Think
one
of
the
issues
we
were
dealing
with
was
when
you
say
when
you
drop
a
higher
spatial
layer,
when
can
you
bring
it
back
and
one
way
to
do?
I
That
is,
if
you
can,
if
you're,
eventually
going
to
get
a
higher
layer,
that's
the
and
that
that's
where
the
P
in
the
U
bit
come
in
as
an
example,
if
you
had
say
more
than
two
spatial
layers
you
might,
the
B
bit
might
not
be
set
because
it
wouldn't
depend
directly
on
the
base,
and
so
you
wouldn't
necessarily
know
when
to
when
you
could
bring
in
the
higher
the
higher
layer
that
you
had
previously
dropped.
I
think
that's
the
issue.
B
John
clinics
actually
stood
up
this
time.
Speaking
as
an
individual
yeah,
the
in
the
description
you
had
of
the
hierarchical
temporal
structure,
I
believe
the
ubi.
It
would
always
be
one.
U
bit.
Is
it
essentially
is
this
hierarchical
temporal
structure,
it's
less
with
slightly
odd
wording.
So
perhaps
you
can
say
that's
you
know
that
bit
is
indicated
by
presence
of
frame
working
if
we
yeah.
B
A
peat
is
more
interestingly
or
interesting,
and
I'm
I've
been
trying
to
figure
out
is
whether
P
is
in
general,
more
useful
than
B
for
spatial
scalability,
and
if
we
I
mean
potentially,
we
could
even
redefine
what
B
means
for
the
non
based
spatial
layers,
but
I
think
we
need
to.
You
know
if
that
won't
confuse
other
use
cases
for
it.
Thank.
F
H
H
G
There's
another
open
issue:
I
sent
an
email
to
the
least
asking
for
the
non-scalable
case,
and
there
was,
for
my
perspective,
I
think
that
we
are
to
understand
unscalable
case
because
there's
only
the
discardable
bid
for
the
non-scalable.
Now
we
sweet,
we
did
some
tests
with
providing
more
information
by
giving
priority,
because
not
all
be
frames,
for
example,
are
the
same.
That's
why
your.
G
G
At
least
I
can
say
we
did
some
tests
with
this
with
this
functionality,
but
it's
produced
better
result.
I
mean
the
question
that
is
legitimate
to
ask
is
who
will
mark
that
I
mean
for
this,
but
we
think
that
we
should
at
least
provide
the
mechanism
to
have
more
granularity
for
the
non-scalable
case,
because
just
one
bit
and
we
have
the
bits
that
spare
bits
there,
so
we
can
use
them.
So
we
don't
see
why
you
should
not.
Also
graph
I
can
put
text.
That
explains
all
these
motivation,
how
it
works.
G
G
It's
smaller,
it's
more
like
if
we
have
two
streams
that
come
through
the
switch
and
we
need
to
decide
which
one
to
drop
and
they
both
have
the
same
priority,
which
one
do
I
drop.
Okay.
So,
instead
of
so
we
want
to
say:
okay,
you
can
try
also
to
quantify
by
defining
some
other
dimension,
which
may
be
the
demotion.
So
if,
if
you
are
low
motion,
then
it's
better
to
drop
from
this
and
not
to
drop
from
there
high
motion,
that's
all
I.
H
Mean
I
saw
a
good
point
in
in
looking
at
priority
as
something
a
signal.
I
think
my
feedback
was
that
the
the
motion
aspect
didn't
make
sense
to
me
because
you
know
in
a
low
motion
stream.
The
majority
of
the
bits
are
going
to
be
very,
very
sensitive
to
drop
because
the
if
a
codec
is
efficient,
then
it's
not
coding
many
bits
for
the
non
moving
parts,
but
the
parts
that
do
move
that
small
amount
of
low
motion.
If
you
drop
that
it's
gonna
be
a
very
visible
corruption
in
the
main
field
of
view.
H
In
the
thing,
the
only
thing
that's
moving
so
typically
a
packet
loss
on
a
low
motion
stream
could
have
a
much
more
drastic
effect
than
on
the
high
motion
stream.
If
the
codec
is
efficient
and
in
encoding
the
the
actual
you
know
focal
point
and
the
detail
and
the
moving
parts
well
and
spinning
most
of
the
bits
there
so
that
that
part,
I'm
I
would
I
would
push
back
on
trying
to
add.
But
priority
I
could
see,
as
a
general
thing
may
be
useful
to
have
more
than
one
bit
of
discard.
L
G
Okay,
so,
first
of
all
to
the
second
question
that
the
room's
asks
the
idea
behind
it
was
that
I
mean
if
they
they're
a
bit
frame
and
some
of
them
have
dependencies,
but
some
don't,
then
you
couldn't
give
them
different
priorities,
so
you
know
which
one
are
better
to
drop
when
you,
when
you
need
to
drop.
That's
the
reason
for
that
for
the
priority.
Basically,
so
the
information
we
can
specify
text
that
explains
this,
that
the
priority
issue.
G
As
for
the
motion,
I
mean
I,
assume
I
mean
one
of
the
assumption
is
that
some
of
the
system
can
do
receiver
side
recovery
and
they
in
motion.
Usually
they
just
assume
that
the
motion
continues
as
if
it's
slow
motion,
they
continue
the
motion
which
works
because
there's
not
much
change
I
mean
and
if
you
just
take
the
trend
and
continue
the
is
it
work
is
working.
That's
what
some
systems
are
doing
on
the
receiver
side,
error,
correction,.
O
Stevebotts
go
I
think,
but
bothering
me
about
the
whole
area.
Here's
we're
moving
beyond,
what's
needed
to
do
clean,
switching
in
the
RTP
switch
and
starting
to
make
assumptions
about
error,
resilience
and
the
receivers.
So
you
know
we're
providing
priorities
in
motion
and
things.
So
you
could
drop
this
if
you
want,
but
whatever
you
do
in
those
cases
you're
going
to
create
artifacts
right
unless
you
have
a
specific
implementation,
where
you
know
those
are
contained
somehow
and
there's.
This
is
a
big
space
like.
G
Roni,
what
we're
trying
to
do
is
to
make
better
than
what
this
is
today,
because
today
it's
also
on
big
that
says
discardable
or
non
discardable.
So
this
will
be
the
worst
case.
I
mean
the
more
information
you
can
provide
by
the
encoder.
As
far
as
is
the
header
extension,
it
will
make
it
easier
to
discard,
because,
anyhow,
the
switch
will
discard
something
because
it
needs
to
discard
so
the
more
information
we
provide
them,
that
it
will
make
it
the
result.
It
may
be
better
than
just
using
just
discardable.
H
Beep
yeah
I
think
Steve's
point
was
that
it's
maybe
a
slippery
slope
that
you
start
to
provide
a
little
bit
more
information
a
little
bit
more
a
little
more
and
then
you
know,
do
we
start
announcing
the
gap
structure,
so
you're
gonna
get
a
refresh
in
you
know,
eight
more
frames,
you
know,
there's
a
I
guess,
there's
a
question
of
how
much
how
much
information
to
make
the
video
optimal.
We
should
actually
embed
in
these
headers
and
keep
in
mind.
This
is
gonna,
be
on
every
single
frame.
So
we
don't
want.
H
L
What
I'm
saying
again,
yeah
I
was
just
gonna
say
that
the
the
motion
bits
also
like
a
privacy
problem,
because
you
might
actually
leak
information
that
it
was
earlier
not
available
and
and
now
you
know
from
a
bit
that
there
is
motion
and
not
looking
at
as
and
you
could
infer
that
from
the
way
the
packets
come
or
the
frames
come.
But
that
doesn't
that's
not
an
strong
indicator
of
motion,
and
now
you
have
this
additional
information.
B
H
B
H
B
B
You
know
PBR
codec
and
for
a
lot
about
motion
just
by
packet
sizes,
I
mean
obviously
I
said
you
have
to
do
it
statistically
based
on
hey
this
used
to
be
big,
and
now
it's
small,
but
you
can
sort
of
tell
hey,
there's
something
that
others.
It's
clearly
decided.
It
needs
to
include
a
lot
of
bits
here.
So.
G
Know
I
did
dropped
it,
but
just
to
do
because
what
because
maybe
it
was
done
because
of
the
scalable,
but
we're
not
talking
about
the
scalable
case,
was
talking
about
their
non
scalable.
So
there
are
no
layering
in
that.
In
that
case,
we're
not
saying
that
it's
the
base
layer
or
dropping
from
the
base
layer
comparing
to
dropping,
but
it's
more
like
between
different
frames
that
different
frames
that
are
in
the
same
stream,
and
we
did
some
tests
on
that
and
and
it
provided
better
results
in
terms
of
what
was
actually
displayed
by
the
end.
G
If
you
made
a
better
decision
about
which
frames
to
drop.
If
you
provide
this
information
and
that's
why
I'm
think
we
don't
think,
there's
there's
a
problem
with
it
and
as
for
worrying
about
going
to
other
stuff,
I
mean
that's
not
what
we're
asking.
Then,
if
you,
if
you
think,
if
someone
comes
with
something
saying
more
description,
then
we
can
argue
that
this
description,
but
to
look
at
and
say
no,
we
won't
do
it,
because
maybe
someone
will
come
and
say
this
is
this
frame?
H
G
Lot
on
the
other
side
of
the
boundary,
then
you're
already,
first
of
all,
the
priorities
thing
I
mean
you're,
just
saying:
okay,
you,
you
just
discard
a
pile,
and
we
believe
that
just
one
bit
for
discardable,
while
for
the
scalable
case,
you
define
a
lot
of
information
based
on
wanting
from
the
content.
Basically,
then
we're
saying
you
can
do
that
also
on
a
regular
stream
on
a
non
scalable
stream
to
provide
more
information
about
how
these
frames
are,
whether
there
are
more
important
or
less
important
than
just
using
one
bit
for
that.
Well,.
H
It's
a
lot
of
different
case.
What
you're
describing
I
think
is,
is
better
err
concealment,
whereas
what
the
frame
marking
is
erroneous
is
non
error
decodability.
So
in
the
frame
marking
bits,
if
you
follow
those
bits,
you
won't
have
any
decoding
errors.
You
may
have
less
fidelity
because
you're
you're
decoding
a
lower
enhancement
layer,
but
you
don't
have
artifacts
you
don't
there's
no
air
concealment
running.
You
don't
have
artifacts.
G
Being
done,
I
mean
it's
not
like
these
things
are
not
done,
I
mean
people,
people
are
doing
those
or
receiver
side
there
or
concealment
I
mean
it's
practically
being
used,
so
at
least
for
the
priority
one
I
mean
it's.
It's
definitely
there's
a
big
difference
in
the
result,
if
that,
if
they
you
take
out
a
beef
frame
which
is
not
used
by
anyone
or
a
B
frame
that
is
being
used
because
that'sthat's
provide
better.
G
Even
if
you
don't
do
our
consignment
to
provide
you
better
letter
result
by
the
end,
because
it
just
frame
that
reference,
then
it
may
synchronize
afterwards,
so
I
think
the
priority
is
very
important.
As
for
thee,
as
for
the
motion,
we
were
looking
at
more
just
between
between
different
between
just
between
different
streams,
because
the
switch
he
receives.
Multiple
RTP
streams
that
just
to
qualify
something
on
the
priority,
because
the
prey
of
the
priority
could
not
distinguish
between
different
streams
is
just
inside
the
stream.
H
I
feel
I
feel
I
agree
with
you.
There
are
use
cases
where
it
may
be
good
to
that,
but
they're
usually
close
I'm,
aware
of
many
systems
that
that
do
know
what
the
receiver
is
capable
of
and
they
mark
even
at
you
know,
network
layer,
area
of
the
SCP
layer.
You
know
the
the
markings
reflect
the
the
relative
impairment
that
you're
going
to
get
on
the
stream.
If
you
drop
this
so
the
I'm
worse
is
like
that.
We
didn't
bring
any
of
that
into
frame
marking,
because
we
didn't
think
that
it
would
be.
H
You
know
something
that
was
easily
and
widely
interoperable
and
and
in
deterministic
it
mean
it's
sort
of
like
a
fuzzy
kind
of
thing,
whereas
these
bits
are
you're,
gonna
have
perfect
decoding
or
you're.
Not
if
you
obey
these
bits
and
a
fuzzy
thing
like
you
know,
error.
You
know,
you
know
artifact
level
of
artifact
induced
by
by
dropping.
This
is
a
little
fuzzier
and
it
seems
hard
to
make
that
normative
seems
hard
to
give
encoders
a
way
to
actually
make
that
normative.
G
H
G
E
H
H
H
Not
that
it's
not
the
bits
that
were
me,
it's
the
semantics
of
you
know
what
do
they?
When?
How
could
you
actually
more,
you
know
mark
them
from
practical
encoders,
and
what
would
you
mandate
a
decoder
to
do
with
it?
I,
don't
think
we
commanded
either
side,
so
it
seems
weird
to
me
to
have
league
that's.
We.
E
Clearly
cannot
mandate
the
decode
do
anything
differences,
just
gonna.
Do
whatever
it's
gonna.
Do
yes,
the
center
side.
It's
not
clear
to
me.
We
need
to
mandate
anything
other
than
just
you.
If
we
say
these
bits
are
they
drop
reference
set
them?
However,
you
feel
like,
and
you
know
you
know,
there
are
hints
to
the
switches
for
which
ones
to
discard.
We
don't
have
to
say
anything
normative
about
which,
how
you
set
those
bits
or
about
how
you
discount
the
packets,
you
just
say,
they're
a
hint.
It's
a
priority.
E
H
E
H
O
Steve
again,
I'm
not
seeing
a
lot
of
generic
use,
I
tend
to
agree
with
that.
This
is
very
implementation,
specific.
What
results
you
will
get
so
I'm
not
denying
that
you
couldn't
get
good
results
in
some
tests,
but
I
think
with
in
the
general
interoperability
situation
that
might
not
be
so
advantageous.
O
If
you
do
need
to
do
something,
it
would
be
better
to
just
create
a
priority
field
and
and
not
do
the
high
motion
low
motion,
because
you
can
always
encode
that
as
a
priority,
if
you
have
a
specific
application
for
it,
and
then
people
can
set
that
priority
as,
however
they
wish
and
if
the
switch
can
make
sense
of
it
and
the
switch
makes
sense
of
it.
I
agree
with
the
comment
that
this
applies
to
scalable
video,
also
because
it's
the
which
doesn't
have
the
capacity
so
simply
layer,
dropping,
may
not
be
enough.
H
G
Think
that
that
what
I
heard
so
far
is
that
they're
two
different
each
two
different
type
of
bits
that
we
we
proposed,
one
of
them
was
the
priority
and
the
other
was
the
motion.
I.
Think
what
I
heard
from
the
motion?
People
don't
have
a
good
view
about
the
how
the
motion
will
help,
even
though
my
in
my
personal
view,
it
helps
mostly
between
different
streams,
but
I,
don't
mind
this
one
another's
priority
in
from
priority.
G
I
G
Not
all
frames
I
mean
you
ma
you
currently,
you
mouth
all
frames
that
you
make
mark
all
frames
that
are
non
I
frame
to
be
discard
about
in
order
to
help
in
the
middle,
but
if
you
can
provide
more
than
just
one
bit
for
that,
that
would
be
very
helpful
for
for
the
switches
at
least
so
I
guess.
The
question
would
be.
B
O
B
G
H
M
H
H
G
H
This
is
the
way
to
use
it
and
just
to
clarify
to
make
sure
I
understand.
This
is
something
totally
different
from
the
rest
of
the
frame
markings,
because
the
rest
of
the
frame
markings
are
trying
to
say
you
will
be
guaranteed
to
have
a
decodable
experience.
If
you
do
this,
there's
no
decoder,
any
conformant
decoder
will
render
what
you're
what
you're
doing
so
what
this
is.
This
is
different.
This
is
saying
this
is
relative
priority
and
these
things
may
or
may
not
be
decodable
by
somebody.
L
A
bit
confused
in
the
scalable
case,
if
the
priorities
would
actually
make
sense,
because
it
seems
like
the
middle
box,
may
be
more
confused
if
it
sees
a
priority
bit
being
something
inst,
and
then
it
anyway
needs
to
look
at
the
the
layer
to
see
what
decision
he
wants
to
make
and
I'm
not
short
of
the
priority,
but
makes
sense.
There.
G
So
what
you're
saying
in
the
scalable
case,
there's
are
still
the
discardable
Basin
is
comfortable.
This
could
be
fair
frame
inside
the
layer,
so
you
have
the
same
problem
there
I
mean
it's
like
you
can
still
get
an
on
decodable
strain
if
you
just
mark
some
of
the
some
of
the
some
of
the
frames
inside
the
layer.
So
under.
H
E
B
E
So
the
the
drop
priority
right
I
mean
at
this
point.
You
are
going
to
be
dropping
a
packet
anyway
right.
All
this
is
saying
is
pick
which
one
you're
going
to
drop.
You
are,
you
are
damaging
the
stream
at
this
point
so
and
of
the
packets
may
be
lost
in
the
network
anyway.
So
don't
worry
about
whether
it's
deep,
whether
you
end
up
with
something
which
is
decodable
up,
because
you
don't
know
what
else
is
gonna
get
was
so.
C
B
The
could
the
question
I'm
going
to
ask
you
know
semantically
without
worrying,
yet
about
the
encoding
and,
leaving
aside
the
question
of
whether
this
makes
sense
are
scalable.
I
guess,
let's
just
similarly
for
non-scalable
I'm,
not
without
asking
the
question
about
that.
So
idea
for
Skeletor
not
was
simply
for
non
saleable.
Do
people
think
it
would
be
a
good
idea
to
have
a
priority
field
in
the
frame
marking
header,
if
you
think
it
would
be
good
idea
hum
now,
if
you
think
it
would
not
be
hum
now.
B
C
C
B
My
so
I
mean
my
suggestion,
might
be:
I
mean,
he's
probably
already
says,
is,
must
be
zero
on,
transmit,
ignore
done
receive,
and
so,
if
in
the
future,
so
we
have,
if
we
have
those
fair
bits
and
a
few
updates
that
could
what
yeah
that's
my
point.
So
my
point
is
that
this
could
be
added.
You
know,
without
breaking
backward
compatibility
in
the
future
of
people.
G
For
Homme
who's
for
use
against,
okay,
so
I,
don't
still
don't
understand
when
people
saying
they
don't
want
it,
why
they
don't
want
it,
because
we
are
not
doing
anything
that
will
change
the
frame
marking
in
terms
of
the
of
the
format,
we're
not
saying
to
change
any
of
the
structure.
We're
just
saying
these
bits
are
not
used.
We
want
to
use
them
so
that
that's
all
we're
saying
here
I
mean,
and
we
don't.
If
we
don't
even
say
there
is
some
semantics
entitled
to
that.
G
We're
just
saying
this
is
something
that
may
help
a
middle
box
in
order
to
decide
which
frames
to
drop
if
it
needs
to
drop
and
not
just
have
just
one
bit,
which
is
it's
less
than
having
two
bits
to
define
which
which
one
to
because
we
have
a
discardable,
but
we
use
one
bit.
Why
did
we
choose
one
bit?
It
was
probably
because
that's
was
the
DES
structure
was
made,
but
we
could
may
have
could
have
defined
two
bits
or
three
bits
for
discardable
I
mean
same
thing:
I.
L
D
D
H
H
If
you
know,
if
you
know
how
your
decoders
are
going
to
respond-
and
you
know
the
relative
priority
of
the
stuff
at
the
encoder,
you
can-
you
can
have
your
own
header
extension
that
does
this
I'm,
not
necessarily
convinced
that
the
standardized
frame
marking
for
all
systems
would
be
that
beneficial,
because
there's
just
too
much
different
behavior
out
there.
Okay.
E
E
G
P
What
I've
tried
so
two
things
in
a
condition:
control
perspective?
If
you
are
dropping
frames
or
dropping
packets,
it
must
be
as
soon
as
possible
to
react
and
in
the
other
things
that
is
coming
to
my
mind,
that
in
a
path,
awareness,
working
group
or
research
group,
which
was
it
was
Wednesday,
they
said
that
in
the
middle
MOOCs,
the
middle
books
in
the
network,
it
must
be
as
simple
as
possible.
P
C
P
K
K
B
B
B
G
B
G
C
B
L
B
B
E
Hopefully,
I'm
tricky,
so
this
is
a
draft
on
how
to
use
that
a
TCP
feedback
for
congestion
control.
It's
come
out
as
the
RM
cat
working
group,
the
office
of
the
draft
of
myself
as
I
had
rune
and
Michael,
but
but
this
is
a
output
of
a
design
team
in
Arin
cat
okay,
so
that
the
the
goal
here
is
to
provide
a
means
of
getting
feedback
for
the
congestion
control
algorithms
in
RM
cats.
E
I,
don't
think
that
any
changes
needed
I
think
we
can
use
our
TCP
and
all
the
existing
extension
and
configuration
points
as
is
and
I.
Don't
think
that
we
need
to
do
anything
in
this
group
or
anything
in
terms
of
signaling,
but
in
terms
of
feedback.
We
do
need
to
define
some
new
packet
types,
so
we're
here
to
get
some
some
feedback
on
on
how
to
use
our
TCP
to
do
that.
E
E
If
everyone
implements
this
according
to
a
3550,
they
will
begin
with
you
for
a
sender
report
or
a
receiver
reports.
They'll
have
a
sauce
description
packet,
which
has
at
least
C
name
item
in
it
and
maybe
other
as
items,
and
they
may
be
followed
by
other
rtcp
packets
in
the
compact,
while
we're
proposing
from
RM
catties
that
we
define
an
X
our
block,
which
provides
feedback
on
congestion
state
that
can
be
put
into
these
compound
packets
and
also
some
some
non
compound
stuff
which
I'll
talk
about
in
a
minute.
E
E
Obviously,
if
the
packet
was
lost,
the
ecn
and
the
arrival
time
offset
have
just
set
to
zero
because
they're
meaningless
and
if
it
and
if
it
wasn't,
they
tell
you
the
ECM
and
the
timing
and
that
just
repeats
for
everything
between
begin
and
end
sequence
numbers
and
it's
padded
out
for
16
bits
with
zeros
if
necessary,
and
this
just.
We
just
stack
them
up
for
every
SS
SS
in
which
you're
it.
But
ok,
now
we're
defining
this
as
an
X.
E
E
Otherwise,
it's
not
clear
to
me
that
that's
beneficial
that
that
that
is
worth
doing,
although
we
do
say
four
bytes,
if
we
do
it,
the
primary
reason
why
I
don't
think
this
is
worth
doing
is
because
we're
putting
these
into
a
compound
packets
anyway
and
by
the
time
you've
got
said
that
reports.
Your
report
blocks
your
sauce
description,
your
cname,
your
IP
header,
your
UDP
header,
you've,
got
80
odd
bytes
of
overhead
anyway,
and
saving
four
bytes
for
the
using
a
custom
packet,
I
prefer
Lenexa
or
indeed
optimizing.
I
E
I
N
E
Okay,
if
we
want
to
reduce
the
overheads
of
doing
this,
the
most
effective
way
of
doing
that
is
just
to
send
non-campaign
packets,
rather
than
always
stacking
these
on
the
compound
packets.
So
you
know,
add
a
presentation
on
that
in
our
MCATs
earlier
in
the
week
where
I
worked
through
this-
and
you
can
look
at
that-
the
slides
for
that
presentation,
and
it
shows
that
you
actually
get
pretty
big
bandwidth
savings
by
interspersing.
You
know
by
alternating
non
compound
early
feedback
packets,
with
a
full
compound
back
with
everything
on
them.
E
And
yes,
you
still
need
to
send
that
the
schedule
packets,
but
you
use
you,
know
the
schedules
compound
packets,
but
you
send
them
on
compound
packets
in
the
middle,
and
that
gives
you
a
tremendous
bandwidth
for
it.
It's
like
what
we're
proposing
for
the
the
non
compound
packets
is
to
use
the
transport
layer,
feedback
format,
we've
taken
exactly
the
same
information
that
was
in
the
XR
blocks,
format
and
all
we
are
doing
is
we've
we've
slightly
rearranged.
E
It
we
put
the
timestamp
at
the
end
traveler
at
the
beginning,
to
fit
the
format
of
the
transport
layer
feedback.
So
it
requires
us
to
slightly
rearrange
the
packet
from
us,
but
it
doesn't
cost
any
more
bits.
But
by
using
this
transport,
where
feedback
and
we've
just
stolen
block
type
2,
which
is
the
next
unused
value-
and
we
should
probably
ask
Guyana
to
do
that
but
yeah,
but
that's
the
one
they
would
allocate
by
defaults,
we'll
pick
free
or
whatever
it
is.
B
E
E
L
M
B
B
Like
I
should
be
at
the
mic,
but
I
don't
feel
like
it.
So
there's
two
points.
One
is
I,
think
there's
something
stopping
us
from
saying:
any
new
feedback
type
we
say
can
go
into
the
place
and
everything
is
there's
nothing
that
stops
you
from
putting
a
2:05
in
a
regular
compound
package.
That's
the
only
what
you're
supposed
to
do
if
the
next
thing
clay
do
you
have
a
compound
by
that
coming
up,
so
you
know,
so
you
could
say
that
you
don't
need
to
get
to
our
block
at
all.
B
B
L
I,
actually,
that
was
the
clarifying
question.
I
think
2:05
was
the
only
one
which
does
leave
feedback
I'm,
not
sure.
We
could
of
course
write
it
in
a
way
where
we
would
say
like
this
updates.
The
four,
if
I
verify
that
it's
not
only
2:05,
but
also
this
thing
that
can
do
early
feedback.
But
since
we
have
so
many
F
empty
values,
I
mean.
B
E
N
N
E
E
Okay,
if
one
probably
the
last
slide
yeah
okay,
so
we
we've
proposed
some
formats.
The
questions
for
the
working
group
is
the
encoding
in
XR
and
transport
layer
feedback
appropriate
and
it
seems
to
be
that
steer-
is
that
we
should
just
use
transport
layer
feedback
to
everything.
Okay,
that's
easy,
and
the
other
question
is
who's
going
to
do
the
work,
and
you
know
should
this
be
adopted
in
a
week
or,
if
not,
should
our
own
cat
do
it
and
if
it
we
believe
abt
core
is
the
right
home.
Should
it
be
a
working
group
test.
F
My
name
is
Jocelyn.
Actually
one
comment
before
on
the
previous
kind
of
subject:
I
mean
I,
don't
think,
there's
anything
that
prevents
you
just
send
an
early
package
which
is
an
extra
block
either.
That's
it
looks
bigger,
but
I
think
it's
it's
actually
not
strictly
forbidden
in
any
format.
Css
and
only
package,
just
packets
not
see
packet.
You
said
early
its.
E
F
F
Anyway,
I
on
the
word
work,
we
spoke
done,
I
think
every
t
core
is
suitable
for
doing
this
so
and
I
see
no
problem
taking
to
us
a
work
group
soon,
there's
some
recently
yeah.
They
already
exist
a
draft
for
it
I
assume.
So
it's
can
be
not
it's
far
too
soon,
but
maybe
you
should
take
these
steps
of
moving
towards
what's
been
discussed
here.
L
Just
going
back
to
the
non
compound
thing,
I
think
non
compound.
You
can
send
any
time.
I
think
the
leave
feedback
in
only
be
sent
and
2:05
would
prefer
to
use
the
2:05,
because
maybe
the
timers
and
like
all
the
recalculation
and
everything
is
done
on
that
particular
thing.
You
would
not
have
to
write
a
new
code
structure
where
you
would
say
like
if
2:05
and
something
else
or
aside,
my
I
might
prefer
that
my
guess
is.
People
have
probably
implemented
2:05
other
reasons
in
their
applications
anyway
type
yeah.
L
E
B
H
Mohsen
Attia
I
agree
with
Magnus
to
do
that.
Work
at
maybe
two
core,
because
I
think
it's
good.
Also.
The
useful
outside
of
congestion
control
I'm
getting
good
act.
Vectors
for
packets
is
useful
for
even
encoders.
The
free
marking
stuff
is
very
simple:
drop
decisions
for
middle
boxes,
but
if
encoders
had
a
full
information
about
what
what
was
acting
and
what's
what
snack,
then
they
could
make
better
decisions
about.
You
know
what
the
dependency
trees
are.
The
receivers
are
okay,.
B
So
I
guess
to
formally
do
that
do
is:
does
anybody
I
won't,
do
it
as
a
how
much
cuz
I,
don't
I,
haven't
heard
objections
as
I
does
anybody?
Would
anybody
object
to
a
taking
this
on
as
a
work
item
of
the
ABT
core
working
group?
I,
don't
see
any
and
B?
Does
anybody
object
to
taking
this
draft
modulo
the
potatoes
we've
done
as
the
starting
point
for
the
working
group
draft.
N
E
I
B
M
E
P
O
P
Let's
say
the
two
sides
using
to
congestion
controller,
the
only
thing
which
is
not
was
not
clear
to
me
is
the
clock
rate
or
in
the
timestamps,
because
if
they
are
using
the
koodoo
congestion
control
by
using
different
clock
rate
for
generating
the
arrival
time
offset,
the
whole
thing
can
cannot
be
useful.
So
it's
useless
I.
I
N
And
I
had
yeah
I
think
we
have
discussed
this
I
think
this
race
issue
has
moderation.
That
is
until
we
have
discussed
this
and
I
think
the
draft
actually
has
the
sort
of
answer
to
that
one.
Some
coleen
coleen
said
we
pick
up
and
and
I
look
for
it
and
so
far
we
have
not
heard
anything
anybody
objecting
so
I
think
I,
think
I,
think
traffic
will
arise,
I
mean.
L
P
Mark
right,
so
they
also
said
for
the
auto
door.
I
will
time
offset
from
the
moment
and
the
report
is
generated
right,
yeah
yeah,
but
the
report
is
having
time-stamped
reporter
report
times.
Then
that's
time
saying:
yes,
yes,
but
in
both
cases
this
kind
of
report
time
stamp
must
be
from
the
same
clock
rate
right.
No,
so
the
the
report
has
a
timestamp.
Yes,
that's
really
offsets
a.
E
E
N
E
L
B
Yeah
and
so
yeah
and
I
think
you
know,
and
you
know
my
inclination
is
to
keep
the
existing
design
team
at
the
office
for
work
and
Richter
after.
But
if
you
assuming
you,
agree,
okay
I
said
I,
my
inclination
is
to
keep
the
existing
design
team.
As
authors
of
the
working
group
draft
is
something
they
agree,
and
it's
something
it's
a
few
enough.
People
that
you
know
keep
the
Kern's
office,
give
the
guard
office
yeah.
Okay,
all
right
so
yeah
we'll
get
from
them
on
the
list.
But
it
sounds
like
you
have
sure.
Q
F
Bestland,
so
gory
fair
house
is
actually
written
a
draft
about
path,
MTU
discovery
units
packetization
layer
for
datagrams.
It
seems
V,
Working,
Group
individual,
currently,
that's
Alderon,
plus
individual
methods
for
particular
Datagram
usage
on
how
to
do
prophecy.
Probing
I
would
encourage
people.
Maybe
look
at
this.
We
had
some
discussion
around
UDP,
York,
etc.
What
you'd
use
for
this,
and
actually
one
inclination
there
would
be
actually
go
towards
using
stun,
but
you
can
think
about
them
and
maybe
comment
too
gory
I
think
you
would
appreciate
getting
more
feedback
on
honest.
B
B
The
feedback
I
got
is
that
could
be
an
intact
to
be
a
standard
strand.
It
could
be
informational
because
of
the
registration
policy,
but
nobody
else
in
the
opinion
of
whether
I
should
try
to
bring
it
here.
Just
push
it
through
some
other
means.
So
if
anybody
has
an
opinion
about
that,
let
me
know
this
is
the
my
draft
I
think
I
published
it?
B
B
B
B
Fair
enough
so
I
mean
I.
Did
this
because
you
know
I
was
telling
people
hey,
we
have
to
move
to
detail
a
service
desk
and
they
said,
but
you
know
but-
and
you
know
but
yeah
and
they
said
well
we're
doing
this
encryption
now.
Can
we
still
do
that
and
I
said
well,
no
you're
either
after
we
did,
you
see
ever
go
back
to
aes-128
and
they
kind
of
looked
at.
We
said.
C
B
B
B
I
K
B
I
think,
basically
it's
you
know,
you
know
it's
either
what
to
do
if
you're
gonna
do
it
as
obvious
and
then
you
either
do
it
or
you
don't
so
so
yeah
I'm,
gonna
people
through
you
or
okay
I'll
talk
to
you
awful.
If
I
get
eruption
well,
I'll
decide
I,
don't
care.
After
all,
all
right
with
that
anything,
any
other
issues.
Anybody
has,
if
not
well,
that's
for
other
than
people
who
are
on
the
I
star,
we're
done
with
the
ITF
and
see
you
in
Singapore.