►
From YouTube: DASH Workgroup Community Meeting 20220223
Description
February 23, 2022 Community Call
C
C
D
D
A
So,
oh
look,
someone
else
has
already
watched
so
I'll
share
my
screen
thanks
for
the
intro
morning,
everybody,
so
can
you
see
my
screen
yeah
great,
so
the
documentation
folder?
I
did.
I
took
a
stab
at
mapping
out
a
structure
to
anticipate
the
hopeful
big
growth
in
this
repo
over
you
time.
If
you
take
a
look
at
sonic
repo
right,
it's
pretty
large
in
fact,
there's
multiple
projects,
it's
so
large.
It's
spread
out
over
dozens
of
projects.
A
I
don't
know
how
the
dash
will
be,
but
before
this
week
everything
was
just
lumped
into
documentation
and
people
were
asking
questions
like
you
know:
what
are
the
compliance
requirements
exactly
etc
and
silvana
was
asking.
For
example,
I
gave
it
a
thought.
I
realized
you
know
we
really
need
to
map
this
out
so
that
as
documents
get
created,
they
have
a
home
and
that
this
thing
scales.
A
So
this
is
what
the
top
level
documentation
folder
looks
like
now.
It's
divided
into
different
categories
and
there's
not
much
in
these
folders
yet,
but
over
time
they
probably
will
get
filled
up
with
lots
of
goodies,
and
I
tried
to
break
it
into
baseline
specifications
and
requirements
and
then
service
specific
ones,
because
I
anticipate
that
there'll
be
new
services
being
introduced
and
created
even
beyond
these
and
that
each
one
probably
needs
its
own
sort
of
work
area
because
otherwise,
we'll
have
one
giant
mega
directory
it'll
be
hard
to
find
anything.
A
So
I've
tried
to
go
ahead
right.
I'm
agreeing
with
you
on
that.
Oh
thank
you
joe.
So
these
I
believe,
are
areas
where
every
card
will
have
to
have
requirements
and
both
in
the
design
and
well
only
design
documents
and
then
hard
compliance
requirements
and
then
down
here,
service,
specific
and
this
can
grow
over
time.
A
And
if
some
of
these
are
you
know,
incorrectly
named
or
described,
feel
free
to
comment
and
what
you'll
see
is
kind
of
a
general
structure
here,
there's
a
topic:
there's
a
design
folder
and
a
requirements
folder
and
the
reason
I
separated.
Those
is
because
at
some
point,
we're
going
to
need
to
have
hard
requirements
that
are
well
specified
and
easy
to
find
and
not
buried
and
intermingled
through
all
kinds
of
other
places.
A
A
Then
we'll
have
compliance
requirements
and,
for
example,
these
will
be
hard
descriptions
of
either
behaviors
and
or
numerical
parameters
like
10
million
connections
per
second
under
some
condition.
But
I
imagine
a
quite
a
big
list
of
these
at
some
point.
If
you
look
at
things
like,
let's
say,
international
telecommunication
standards,
you'll
see
that
there's
specifications
where
requirements
are
numbered
and
easy
to
find
in
reference
rather
than
being
just
spread
throughout,
I'm
hoping
we
can
have
some
kind
of
a
format
that
we
develop
together.
A
That
makes
these
requirements
easy
to
maintain,
specify
and
even
refer
to
in
other
places.
So
this
is
an
aspirational
approach
here
and
I'm
hoping
we
can
work
together
to
do
something
and
then
test
cases
will
actually
be
statements
of
this.
This
test
is
going
to
do.
You
know,
verify
x,
y
and
z
requirements
and
then
there'll
be
actual
scripts
that
execute
those
test
cases,
and
then
these
scripts
will
produce
some
kinds
of
results.
So
these
are
automations.
A
A
When
you
get
time,
it's
a
bit
much
to
digest
this
early
in
the
project,
but
I
think
it
provides
a
road
map
to
do
this
in
a
logical
way
and
we're
right
now
in
the
process
of
working
on
some
test
scripts
right
now
that
we
will
donate
to
the
community
when
they're
ready
and
they
will
be
able
to
do,
reproducible
repeatable
tests
with
you
know
hard
hard
outcomes
so
I'll
take
a
break
here.
If
there's
any
questions.
E
Hey
chris,
you
know
great
work.
Many
many
thanks
for
doing
this
thing.
This
is
this
is
organizing
this
thing.
You
know
I
actually
looked
at
it
over
the
weekend
and
it
you
know
it
made
a
lot
of
sense
to
to
do
this
way.
So
so
thanks
a
lot,
you
know
one
quick
note.
You
know
much
like
how
we
have
done
for
the
documentation.
Do
you
think
we
want
to
do
the
same
thing
for
the
behavior
models?
Also,
so
we
can
classify
them
in
their
separate.
A
Well,
I
think
the
p4
behavioral
model
will
probably
be
just
like
a
a
p4
program
that
should
be
organized
like
a
software
project,
but
I
guess
if
you
want
to
organize
it
by
service,
it
probably
probably
already
is
right.
There's
p4
modules
or
I
shouldn't
say,
module
because
that's
p4
doesn't
have
modules
exactly,
but
there
there
are
files
right
that
that
implement
the
code
see,
but
that's
probably
something
that
somebody
else
should
comment
on,
but
I
agree
it
should
be
structured.
E
Yeah,
I
I
think
you
know
much
like
how
you
have
done,
because
you
know
there
are
like
seven
use
cases
that
initially
you
know
azure
put
out
to
say.
Okay,
we
want
to
handle
that
you
know
to
start
with,
like
seven
use
cases,
and
if
we
have
models
describing
these
use
cases
separately,
then
perhaps
we
may
want
to
really
you
know,
classify
them
accordingly,
if
that
makes
sense,
yeah
yeah,
I
think.
A
B
We
should
probably
yeah.
I
think
this
is
a
question
to
the
coders.
Does
the
code
actually
compartmentalize
like
that
or
is
the
code
highly
reliant
on
so
does
so
you
know
slb?
Is
it
highly
reliant
on
v-net
and
can
they
be
compartmentalized
exactly
so
that's
something.
Actually
it's
a
good,
very
good
question
to
see
if
they
can
be
compartmentalized
like
that
and
or
if
they
cannot
be,
then
let's
probably
discuss
okay.
What
is
the
alternative.
F
B
That's
my
feeling
as
well
that
you
won't
be
able
to
completely
separate
it,
but
let's
make
it
a
discussion
point
because
we
do
want
to
be
able
to
recognize.
You
know
what
pieces
are
for
what
and
let's,
let's
maybe
christina.
We
need
to
get
maybe
a
few
of
the
coders
like
from
from
anybody
who's
interested
to
get
in
one
call
and
then
discuss
that
and
then
try
to
come
up
with
resolution
together
on
that
one.
I
think
you
know
obviously
melanox.
D
B
Anybody
who
wants
but
try
to
make
sure
that
the
people
attending
our
coders
who
actually
understand
that
is
this
going,
how
how
integrated
this
code
is
and
how
can
it
be
percent
into
these
services.
So
I
would
set
that
up.
That's
a
really
good
topic
and
we
need
to
resolve
that
before
going
so
far
with
that.
A
C
D
A
D
B
C
A
B
A
A
So
that
was
that
was
that
presentation-
and
you
know
shortly
after
this
restructuring
was
done.
We
already
started
getting
some.
So
here's
the
8k
document,
but
if
you
look
at
the
pull
request
see
or
that
bud
did
he's
actually
dropped
a
file
into
this
folder.
So
it's
already
been
saved,
used,
found
and
used
yeah,
it's
already
proving
some
value
right,
because
I
had
a
place
to
live
so
anyway.
That
was
my
presentation
and
thanks
for
the
feedback-
and
you
know
we
still
have
some
time
to
do
some
restructuring.
D
Where
you
know,
if
you
are
in
data
plane
in
one
click,
you
can
go
to
the
parent,
folder,
the
design
or
the
compliance
requirements
and
or
alternatively,
we
could
just.
We
could
just
do
a
double
two
click
design
where
we
could
just
you'd
have
to
click
twice
to
get
down
into
the
structure,
and
so
this
is
how
we
were
using
it
for
now
and
curious
what
everyone
thought
of
the
readability.
A
A
D
A
Yep
exactly
thank
you
and,
if
you
add
a
document,
just
throw
an
entry
in
this
table
right,
it's
easy
just
to
copy
the
folder
and
then
copy
the
line
and
then
just
paste
it
in
it
looks
like
you
know.
The
github
markup
looks
like
this
right.
That's
pretty
simple,
just
copy
the
row
and
then
edit
it
for
your
new
document
and.
A
Yeah,
so
this
looks
kind
of
big
a
little
bit,
maybe
a
little
bit
daunting
at
first,
because
it's
so
big
and
there's
so
little
actual
content,
but
I
like
to
think
of
it
like
planning
out
of
city.
You
know
big
wide
roads
with
stop
lights
on
every
intersection,
because
eventually
the
buildings
will
come.
G
D
D
B
So
that's
the
whole.
That's
the
whole
point
of
this
is
that
in
the
first
packet
there
is
the
layer
four,
and
so
you
will
already
have
a
you
already
have
a
fast
path
for
this
or
you
will
create
one
at
this
point.
But
let's
assume
we
already
had
a
fast,
fast
path
created.
So
in
other
words,
the
flow
table
has
already
been
created
now
you're
receiving
your
first
part
of
a
first
packet
of
a
fragmented
packet.
B
Well,
that's
already
in
the
flow
table
and
what
it
has
is
it
has
the
fragment
id
in
it.
So
now
you
have
to
create
a
temporary
flow
table,
entry
that
looks
for
the
source
destination
and
this
id
fragment
id
as
its
classification,
which
is
equivalent
to
the
layer
4
classification.
Now,
because
the
idea
is
unique
to
that
fragment
by
doing
that,
that
will
only
last
for
the
duration
of
till
the
end
of
packet
and
then
it
will
be
removed,
but
what
it
doesn't
need
is
it
doesn't
need
you
to
do
the
slow
path.
B
So,
just
because
you
don't
see
the
layer
4
in
the
subsequent
packets,
you
already
have
a
connection
and
you've
already
associated
that
connection
with
the
fragment
id
and
source
destination,
and
therefore
that's
the
only
thing
you
need
to
match
on
to
classify
it
and
therefore
it'll
always
stay
in
the
past
path.
It's
just
that
these
entries
will
be
spun
up
very
quickly
and
spun
down
very
quickly
as
the
fragment
fragmented
packet
completes.
B
B
B
G
B
Doesn't
say
what
the
device
should
do
so
true,
so
we
can.
We
can
what
his
is
a
soft
case
of
what
I
mentioned,
but
I
think
we'll
mention
his
too
and
out
of
order,
for
example,
doesn't
really
happen
in
network
because
everything
is
encapsulated
into
layer
4
on
the
outside,
and
this
is
the
inside
of
the
frame
and
no
switch
actually
misorders
a
layer.
4
packet,
I
mean
all
the
hashes
are
done
at
the
airport.
B
You
know
and
in
fact
they're
done
and
if
you
did
miss
order,
we
would
have
found
it
and
kicked
you
out
of
the
network,
so
we
know
that
they
don't
come
in
misordered.
In
fact,
if
it
comes
in
misordered,
it's
probably
an
attack,
it's
called
fragments
smack
and
therefore
we
delete
all
packets
that
are
disordered
by
default
in
our
network
today,
so
that
I
have
checked
on
our
implementation.
That's
what
we
do
because
of
fragment
smack.
I
mentioned
in
a
document.
B
What
he's
saying
also
is
just
say:
just
a
packet
comes,
you've
never
saved
it.
It
could
be
misordered,
but
it
could
also
be
denial
of
service
attack.
So
a
fragment
comes
without
any
previous
notion
of
a
layer,
for
you
know
first
packet
ever
or
a
connection
that
will
be
dropped
as
well,
but
I
think
it's
worth
mentioning
it's
just
a
to
further
emphasize.
We
do
not
expect
that
and
we
should
drop
all
packets
that
are
mis-ordered.
H
B
H
B
B
F
F
B
Oh
you,
how
you
implement
it
in
the
end
will
be
up
to
you.
It's
the
behavior
that
you'll
have
to
obey.
The
the
behavioral
model
doesn't
mean
that
you
can't
come
up
with
a
better
way
of
keeping
the
behavior
right.
So,
even
though
we'll
describe
it
as
fastpass
slow
path,
how
you
implement
inside
I'm
sure
you'll
play
lots
of
tricks,
but
the
test
cases
will
be
based
on
the
behavior.
B
You
don't
have
to
follow
exactly
the
p4
code.
The
way
it's
written.
You
just
need
to
to
make
sure
that
you
understand
that
when
we
test
we're
testing
against
the
p4
code,
so
if
your
implementation
doesn't
match
it,
I
don't
care
how
you
match
it.
I
don't
care
if
you
use
the
drop
of
the
the
people
are
code,
but
the
tests
are
only
based
on
the
people
or
behavioral
model,
so
we're
creating
the
model.
So
it's
like
a
description
of
this
service,
but
it's
not.
E
B
E
B
C
Gerald
I
want
to
make
a
quick
observation
when
you
guys
enter
an
apr.
It's
okay,
to
flag
the
problem.
But
if
you
have
some
ideas
in
mind
that
how
can
you
improve
the
document
and
what
you
think
should
be
the
description
I
would
suggest
to
put
information
there.
So
it
would
be
easier
if
you
don't
mind
when
it's
possible.
C
A
A
So
pr
shouldn't
be
like
open-ended
hey,
you
know,
let's
talk
about
the
mean
of
life,
it
should
be
here's
a
document
change.
Would
you
please
accept
it
right?
So
it's
already
the
content.
You're
proposing
should
already
be
there
right.
That's
what
the
general
use
of
prs
are.
Here's
the
here's,
a
change,
I'm
submitting
for
you
know
once
it's
accepted
solutions
at
hand.
D
Yep,
so
it
sounds
like
we
have
two
potential
pr's
coming
into
gerald's
document,
one
with
the
the
one
we
just
talked
about
the
ip
and
the
other
one
from
andy
to
definitively
say
whether
we
want
to
support
for
a
long
time
the
whatever
you
said
in
the
issue.
I
have
to
look
it
back
up.
Do
we
want
to
handle
fragmented
packs
at
line
rate
and
definitely
do
the
explicit
statements?
So
you
guys
are
going
to
do
that.
Okay,.
B
E
B
I
think
the
last
one
that
wasn't
discussed
in
there
that
I
I
am
still
looking
at
how
we
handle
out
of
order
packets,
even
though
they're
not
supposed
to
be
out
of
order
at
the
at
the
ending
of
a
thin.
I
think,
there's
an
exception
there.
That
has
nothing
to
do
with
really
out
of
order
so
much
as
packets
arriving
after
the
fact,
which
can
happen,
and
I
drew
one
example
in
the
document
of
how
that
can
happen.
B
A
Well,
I'm
going
to
get
an
opinion
from
people.
You
know
if
we're
going
to
start
having
more
and
more
documents
talking
about
deep
stuff
like
that,
we
might
want
to
put
it
in
another
place,
and
that
could
be
a
final.
You
know
just
a
move
at
the
end.
Does
anyone
have
an
opinion
on
that?
So
we
set
a
precedent
so.
E
D
B
B
B
B
Yeah
and
that's
that's
gonna
go
back
also
to
I.
I
would
table
it
for
a
little
bit
later.
That's
gonna
go
to
how
do
we
compartmentalize
the
code,
so
this
this
could
live
within
the
v-net
model,
but
I
think
if
I
was
I'd
rather
listen
to
the
data
path,
coders
to
say
like
where
it
really
should
live
like
should
this
be
something
that
is
is
used
in
all.
G
B
B
We're
just
we're
like
a
switch,
we're
like
in
between,
like
switches,
don't
care
about
sequence
numbers
either,
and
you
know
they:
they
they
determine
where
the
pack
is
supposed
to
go.
They
do
firewall
filters,
but
in
the
end
they
don't
look
at
sequence
numbers
to
determine
whether
they
pass
the
packet.
B
It's
very
similar
here
we're
not
the
end
points,
so
we're
not
reassembling
and
I
think
it's
our
job
to
interfere
with
any
of
that
process.
So
in
a
regular
flow
like
we,
don't
really
need
to
sequence
whether
we
need
to
in
the
fragmentation
it's
a
little
different
on
how
we're
going
to
identify
that,
but
for
regular
tcp.
We
don't
need
to.
We
don't
care.
G
B
And
christina
others
can
be
well.
Let's
have
the
meeting
person
and
we'll
discuss
that
we
are
having
a
discussion
on
closing
of
connections
just
to
make
sure
that
corner
cases
are
actually
covered
properly,
because
it's
easy
to
write
down
what
the
normal
case
is,
but
there's
a
bunch
of
corner
cases
and
we're
trying
to
go
through
them,
and
that
will
should
answer
your
question
when
we
get
to
that
and
we'll
I
hope
by
next
week.
B
We'll
have
already
had
that
meeting
and
we
can
write
down
the
thoughts
there,
because
we
have
some
examples
in
the
world
that
you
know.
I've
already
done
this
before
so
we're
trying
to
learn
up
that
and
make
sure
that
we're
using
best
practices
for
ending
that
connection
and
it's
corner
cases,
so
I
think,
it'll
be
answered.
I
think
your
question
will
be
answered
out
of
that
discussion.
G
B
B
How
often
does
this
happen
doesn't
mean
we
don't
need
to
cover
the
case,
but
I
kind
of
want
to
know
even
for
myself.
How
often
is
is
this
actually
happening
where
vm's
fragment
packets,
because
there's
no
upside
to
it?
In
my
opinion,
and
yet
it
still
does
exist
and
we
still
have
to
cover
it.
But
I'd
like
to
know
is
it
like
one
percent
point
zero
zero
one
percent
try
to
figure
out
a
way
christina.
G
B
G
B
G
G
I
just
I'll
keep
saying
it
again
until
until
I'm
heard,
I'm
sorry
say
it
again.
What
is
your
worry?
I
I'm
saying
a
dash
product
designer
has
many
more
degrees
of
freedom
in
how
they
design
a
product.
If
you
can
promise
that
we
can
drop
any
more
than
say
fifty
thousand
five
magnets
fragments
per
second
and
don't
have
to
handle
them,
because
that
we
don't
need
to
do
in
the
fast
path.
B
B
Actually,
but
I
don't
think
it's
that
big
of
a
deal
in
the
end
when
I
looked
into
it,
I
thought
it
would
be
a
bigger
deal
until
I
looked
into
it
and
said:
that's
not
that
big
of
a
deal-
it's
not
like
you
have
to
do
slow
path
over
you're,
literally
just
creating
a
new
entry
for
a
little
bit.
That
does
take
overhead,
but
the
complexity
of
doing
it
is
not
that
big.
G
B
D
G
They're
extremely
security,
conscious
devices
that
try
to
take
into
like
different
end
host
stacks
do
ip
reasonably
different
and
if
you're
trying
to
protect
against
attacks
on
multiple
different
host
stacks,
there
are.
There
are
network
devices
that
actually
try
to
do
different
things
depending
upon
which
host
they're
protecting.
D
B
B
D
I
B
I
I
D
D
I
I
B
I
I
That
said,
look
models
are
great,
but
if
you
don't
define
the
behavior
with
the
model
and
the
behavior
of
the
p4
pipeline
and
again
as
as
was
said
independent
of
the
details
of
how
it's
implemented,
then
we're
not
going
to
have
stuff,
that's
interoperable
and
we're
not
going
to
cover
the
gateway
space
correctly.
For
you
know,
azure
cloud
or
anyone
else
right,
because
this
will
be
used
more.
D
B
Point,
thank
you.
So
actually
the
one
thing
I
always
point
back
to
is
testing,
so
the
behavior
models
have
to
have
enough
detail
that
the
tests
are
created
to
exercise
all
those
corner
cases,
and
so
everything
will
point
back
to
eventually
you
should
be
able
to
have
a
behavioral
model,
and
if
you
understand
that-
and
now
you
can
make
that
into
a
software
model
which
just
through
compiling
it
and
then
you
you
build
your
test
cases
eventually.