►
From YouTube: DASH Workgroup Community Meeting 20220323
Description
March 23, 2022 Community Call
A
So
we
talked
about
that
number
a
lot
and
we
wanted
to
make
sure
that
people
understand
that
those
were
the
tests
that
were
in
the
past,
that
we
wanted
to
make
sure
that
you
understand
more
now
what
the
real
numbers
will
look
like
in
product
environment.
So
it's
16
million.
You
should
not
have
in
your
head
because
in
actual
fact
the
requirement
is
really
64
million.
A
B
And
so
that's
that's
kind
of
the
next
two
bullet
points,
and
so
when
we
say
we
want
to
protect
the
space
of
one
million
total
active
connections
per
eni,
the
implication
for
that
is
that
the
way
that
we
run
high
availability,
we
do
something
called
partner
replication,
and
so
you
would
have
one
card.
That's
active!
B
B
That's
just
looking
across
clouds
today
be
that
azure
be
that
aws
gcp,
whatever
the
the
total
active
connections
for
any
size
given
virtual
machine
would
be
around
this
one
million,
if
not
more
mark
and
so
and
if
you're
looking
for
some
sort
of
reason
why
we
chose
that
number.
It's
just
kind
of
accommodating,
where
we
need
to
be
to
optimize
workloads
and.
A
So
also
james,
just
one
more
comment
that
I
think
that
if
people
have
ever
measured
this
before
small
vms
tend
to
have
smaller
table
sizes
and
bigger
ones
have
larger.
So
this
is
still
like
a
committed
average.
It's
not
necessarily
that
we're
going
to
give
a
two-core
vm
a
million
entries
in
a
float
table.
B
C
B
So
so
you're
correct,
so
an
eni.
Essentially
you
take
a
destination
mac
address
behind
your
that
you
wish
to
optimize
you
also
like
eni
mapping.
You
do
look
at
the
v-net
id
and
you
do
look
at.
I
think
some
of
the
ip
addressing
and
you
look
at
the
destination
mac
and
that's
kind
of
taking
you
to
a
a
single
optimized
target
that
you
can
refer
to
now.
B
C
D
A
B
D
A
I'm
I
both
the
traffic
just
doesn't
arrive,
but
you
know
we
we
direct
traffic
up
like
half
to
one
and
a
half
to
the
other
until
such
an
event
occurs,
and
then
everything
goes
on
in
the
future.
It
will
actually
that
will
have
ecmp
to
make
that
even
better.
But
right
now
everything
will
be
practiced
to
the
one
card.
A
B
And
this
is,
this
is
still
something
we
want
to
provide
more
clarity
around
and
so
think
of
this,
as
kind
of
a
a
first
communication
to
the
group
to
to
help
really
define
what
we're
looking
at
and
in
the
future,
we'll
we'll
try
and
further
provide
clarity
here,
but
we
thought
this
was
important
enough
to
kind
of
explain
what
we
were
looking
at
and
why
we
were
arriving
at
the
numbers.
We
were
get
this
in
documentation
and
bring
it
to
the
group
to
discuss
if
anyone
had
any
questions.
A
Later
this
has
been
added
playing
time
before
done
just
later,
we
will
just
so
you
know:
we've
been
looking
at
this
from
like
how
you
use
memory,
and
we
believe
that
this
will
take
up
approximately
two-thirds
of
the
32
gig
of
memory.
So
that's
what
we're
looking
at
practitioning
the
memory
and
making
sure
that
we
32
gig
is
enough
to
support
this,
and
currently
we
believe
it
is.
F
Yeah
yeah,
so
I
I
I
have
some
questions.
I
it
was
my
understanding
that,
like
an
eni,
is
actually
like
load
balanced
across
like
many
dpus,
and
so
like
it's
unclear
to
me,
like,
like
the
one
million
connections
here
per
eni,
would
that
be
like
for
a
given
eni
that
one
million
connections
would
be
split
across
you
know
eight
gpus
or
some
number
of
dpus
that
are
in
the
appliance.
A
And
there
can
be
there
there
can
be.
This
is
the
simplest
form
that
we
could
describe.
This
is
really
a
memory
calculation
thing.
Okay
in
the
future.
Today
we
don't
actually
use
the
ecmp,
but
very
soon
we
will
be.
And
yes
once
you
go
to
ecmd,
it
means
that
you're
going
to
have
even
more
eni
per
card,
but
fewer
connections.
D
A
Will
receive
less
pure
connection,
so
it
will
balance
the
same
way.
It's
just
that
for
over
subscription.
It
makes
a
lot
better
when
you
do
it
that
way
and
also
for
redundancy,
but
the
the
numbers
won't
change.
You'll
just
have
okay.
Well,
some
numbers
will
change
because
you
you
need
to
have
space
to
have
more
unites,
but
not
for
more
flows.
The
flow.
D
A
Which
is
dominant
memory,
user
won't
change,
but
some
of
the
policy
tables
but,
of
course,
haven't
been
increased.
So
that
is
the
consideration
for
ucmk
and
you
know:
do
you
do
you
spread
across
all
cards
or
some
cards,
and
that's
that's
actually
what
the
consideration
is?
How
much
memory
do
you
use
for
having
more
and
more
eni
on
a
particular
card?
Yeah,
okay,.
A
F
Okay-
and
I
have
a
couple
more
sort
of
follow-ups
to
that
is
this:
are
these
connections
like
any
of
the
six
or
seven
services?
Are
these
v4
v6?
Does
this
include
nat?
Is
this
just
v-net
to
v-net
like?
Is
it
like,
like,
for
example,
do
you
expect
that
the
capacity
of
64
million
connections
do
you
expect
that
capacity
for
ipv6
flows?
F
B
The
that's
actually
an
excellent
question,
and
so
a
lot
of
it
is
in
the
ipv4
space,
because
it's
in
our
data
centers
and
essentially
we
can
control
cipa
addressing
and
like
there
are
some
instances
where
you
do
need
ipv6
and
certainly
when
you
start
having
heavy
requirements
for
ipv6
it
kind
of
it.
It
begins
to
start
getting
into
these
these
numbers
quickly
and
I
think
the
64
million
is
still
the
space.
B
B
A
But,
but
also,
I
think,
the
answer
to
that
will
become
clearer
when
we
define
all
the
mappings
something
that
we
were
discussing
last
night-
and
I
was
thinking
this
morning
more
as
we
define
all
the
mapping
the
mappings
actually
translate
to
how
much
how
much
memory
is
required
to
perform
those
mappings
those
transformations.
And
yes,
they
will
be
different
debates
based
on
different
services.
So,
as
we
can
finally
define
those
mappings,
you
can
actually
draw
them
from
the
documents.
A
Then
you
could
more
accurately
create
the
the
memory
music.
You
know
different
happenings
translate
to
different
encapsulations,
including
ipv6,
including
that
and
and
all
and
slb
and
all
of
them.
So
once
we
do
that,
you'll
get
probably
be
able
to
calculate
it
much
more
clearly,
but
your
your
question
is
definitely
a
good
one.
F
A
B
Yep-
and
I
put
I
put
some
notes-
we
need
to
kind
of
characterize
these
connections
right,
so
there's
there's
a
lot
more
visibility.
We
want
to
give
you
and
if
there
are
things
that
you
think
would
be
very
relevant
breakdowns
of
six
versus
four
percent,
not
connections
other
things
like
breakdown
by
scenario
or
pieces
of
the
seven
services
that
might
make
up
the
total
composition.
B
B
And
so
this
is
an
excellent
discussion,
but
this
was
this
was
also
something
we
knew
we,
you
know
the
group
an
update,
and
so
we'll
we'll
start
here,
but
continue
to
to
give
more
visibility
and
also
provide
points
for
feedback.
So,
as
you
guys
look
at
this,
you
can
definitely
direct
the
conversation
and
help
us
arrive
together
at
the
correct
answers
here.
So,
even
if
you
have
any
questions
you
haven't
thought
of,
please
do
always
keep
them
coming.
C
B
And
we're
working
through
that
now
so
there's
the
men
and
macs
are
are
driven
in
separate
areas
and
we
can
look
at
different
things
like
acls,
mappings
routes,
etc
and
determine
a
min
and
a
max
size
per
eni.
And
when
I
started
talking
about
characterizing
connections,
that's
that's
some
of
the
stuff.
B
B
G
B
G
I'm
sorry,
I
joined
a
little
late.
I
may
you
may
have
already
said
this
because
obviously
just
on
the
bullet
point
protect
space
of
one
million
total
active
connections
per
eni.
So
basically,
this
is
just
a.
If
I
understand
you're
saying
there
should
be
no
way
that
one
eni
eats
up
all
the
flow
space
and
prevents
some
eni
from
getting
at
least
one
million.
Is
that
the.
B
So
so
that's
actually
an
excellent
question
as
well.
In
most
cases,
if
we're
provisioning
out
these
cards,
we
might
find
that
we're
getting
to
some
sort
of
optimization
that
we
divide
the
capacity
of
the
card
to
be
able
to
accommodate
30
enis,
but
the
implementation
does
leave
open
that
you
could
have
one
one
eni
that
scales
to
the
capacity
of
the
card
right.
So
if
you
wanted
one
super
duper
eni
for
whatever
reason
and
there's
there's
valid
scenarios
for
that
right.
B
B
Consume
a
total
capacity
so
like
if
you
want
to
take
32
64
million
total
active
connections
and
take
all
of
your
cps
and
make
one
giant
eni
that's
possible.
However,
when
you
look
at
the
workloads
in
clouds
today,
it's
not
always
going
to
happen
like
that,
and
so,
if
you're
sizing
realistically
to
your
workloads
yeah,
you
may
not
have
a
lot
of
super
giant
enis
like
that,
and
so
in
general
you
know
this
is
this?
Is
average
right?
So
you
may
you
may
have
a
few
outliers
where
you
have.
A
D
A
Decide
how
to
pack
these
cards
and
it
will
consider
some
level
of
over
subscription
if,
if
necessary,
but
for
example,
it
wouldn't
say
I'm
going
to
put
a
graphic,
huge
cni
that
consumes
all
the
space
and
then
go
put
a
bunch
of
other
enis
on
the
same
card.
The
allocator
would
actually
take
that
into
account.
It
takes
the
constraint
and
then
says:
okay,
that
big
vm
is
going
to
is,
is
going
to
take
a
large
part.
A
That's
that's
highly
unlikely,
so
it
makes
more
sense
to
at
least
accommodate
some
level
of
oversubscription,
which
we
would
also
set
by
by
allocating
more
enis
to
a
particular
card
than
the
numbers
actually
indicate,
but
it
wouldn't
be
too
over
subscribed
by
the
way,
but
we
may
use
some
level
of
older
subscriptions.
So
the
designs
need
to
accommodate
for
that.
A
You
need
to
be
able
to
support.
Different
numbers
of
connections
per
eni
is
what
it
comes
down
to
and
whatever
we
set,
then
you
know
if
you
have
over
a
subscript
and
there's
always
a
chance
when
you
go
to
build
a
flow
that
there's
no
more
table
left
because
it
was
over
subscribed.
That's
that's
over
subscription
right
and
that's
what
it
means,
but
generally
we
wouldn't
expect
it
because
it
would
never
over
subscribe
that
much
that
you
should
ever
run
into
that.
G
If
you
want
to
make
sure
if
it's
got,
let's
say
8
million
capacity
flow
table,
let's
say
you,
I
think,
want
to
be
able
to
configure
it
or
it
should
operate
such
that
juani,
and
I
cannot
take
up
all
8
million
and
leave
0
left
over
for
the
other
one.
You
want
correct.
Both
of
them
have
at
least
a
billion,
and
then
there's
a
shared
leftover
that
either
one
of
them
can
take
is
sort
of
the
behavior.
I
think
you
want,
maybe
whatever
behavior
you
do
want.
That
would
be
good
to
document.
For
that.
A
Yeah,
we
need
to
document
that
behavior
and
you're
and
you're
right.
We
we
need
to
document
how
oversubscription
is
actually
how
it's
implemented
and
and
that's
when
possible,
what
you
just
said
that
there's
some
other
consequences
as
well,
but
in
any
case
it
can't
be
that
you
get
zero
for
sure
everybody
needs
to
get
a
minimum
and
the
number
that
it
gave.
A
You
is
not
the
minimum,
that's
just
the
average,
based
on
what
we
see
across
that's
more
of
a
looking
across
all
of
the
clouds
looking
at
what
they
offer
measuring
it
and
then
saying
yeah.
We
need
to
support
this
name
because
that's
what's
competitive
today,
but
it's
not
your
min.
It's
not
your
max
and
it
has
nothing
to
do
with
building
subscription,
that's
more
of
the
marketing
requirement
and
how
we
get
to
do
some
more
work,
but
64
million.
We
can
tell
you
that
we
can.
A
We
think
it
is
realistic
to
have
64
million
flows
in
a
cpu
with
32
gig
of
memory.
We
we
know
that
piece
and
in
the
future,
what
it
will
you
know
what
things
like
you've
already
mentioned,
that
will
you
know
change
it.
A
bit
as
you
know,
as
we
go
to
ecmp,
and
we
have
to
replicate
more
policy,
we
get
a
little
bit
more
experience.
Maybe
those
numbers
will
change
a
bit,
but
right
now
we
believe
that
64
million
is
achievable,
based
on
our
experience
and
calculations.
B
E
B
Okay
yeah:
absolutely
we
can
do
that
and
the
the
eni
number
actually
does
become
very
important
because,
essentially
that's
that's
the
number
of
of
things.
A
single
or
dpu
number
of
targets,
you're
going
to
optimize,
becomes
right
and
so
there's
essentially
a
one-to-one
mapping
of
the
eni
to
the
the
optimization
target,
and
so
it
it
does
become
important
fast
and
I
think
you're
you're
concentrating
in
the
right
place
for
the
right
reasons,
because
it
it
is
the
majority
of
basically
your
memory
use
and
so
yeah.
B
F
B
H
H
B
E
Do
I
just
have
one
so
thanks
james
for
coming
and
spending
more
time
than
I
thought
you
would.
I
appreciate
your
time
and
I'll
send
out
notes
on
to
you
and
to
the
community
and
what
we
talked
about.
I've
just
been
documenting
in
the
background
here,
and
what
we're
going
to
do
is
have
andy
summarize
what
happened
at
the
p4
meeting
if
he
feels
like
it
andy.
G
G
Yeah,
that's
right.
Also,
okay,
christine
you
can
double
check,
so
the
there
are,
I
mentioned
a
while
ago
that
the
current
p4
code
and
the
serious
pipeline
checked
into
the
dash
repo
has
some
keywords
that
are
not
in
the
p4
language
standard
and
I
asked
what
they
meant
and
so
on
monday
alan
presented,
what
they
meant
and
where
they
came
from
they've,
been
made
up
by
nvidia
and
they
would
be
interested
long
term.
If
those
were
part,
you
know,
became
part
of
the
p4
language
standard
and
nate
foster.
G
Also,
you
know
involved
in
the
beef
language
design
group
was
there
and
his
summary,
I
think
is,
is
correct,
which
is
you
know?
The
language
language
group
is
fairly
conservative,
but
they
are
open
to
things.
Especially
you
know,
driven
by
actual
real
world
use
cases
are
much
more
interesting
than
say,
let's
say
more
academic
use
cases,
and
this
is
definitely
you
know,
driven
by
by
real
world
use
cases
and
the
recommendation
to
allen
and
others
was
to
create
some
more
similar
examples
other
than
the
dash
examples
for
consideration
going
forward.
G
I
suspect
that
in
the
meantime
this
could
be
a
like.
I
doubt
it
would
be
less
than
a
four
to
six
month
process.
That
would
be
a
fast
track
to
get
a
new
thing
like
this
ahead
of
the
language,
I
think,
potentially
in
the
meantime,
from
what
I
understand
from
what
allen
presented.
There
are
other
ways
to
write
this
in
p4
that
have
equivalent
behavior
that
could
be
used
in
the
meantime.
I
G
I
G
And-
and
I
also
as
a
side
note-
mario
did
contact
me
by
email
recently
and
I'm
going
to
take
the
action
item
with
an
intel.
I
think
we
mentioned
a
couple
months
ago
that
at
some
point
there's
a
dpdk
open
source,
dpdk
backend,
a
dvda
soft
based
software
switch.
That
has
a
p4
back
end
and
it
might
be
getting
the
point
where
it's
imminent,
that
it's
featureful
enough
to
handle
some
of
these
features.
But
I
will
go
double
check
that
and
get
back
to
you
on
how
imminent
that
is,
whether
it's
a
month
or
more.
D
D
A
D
E
So
that's
what
we'll
do
today
if
we've
missed
anything
or
if
you
can
think
of
anything,
please
let
us
know,
but
we
have
the
you
know,
compare
the
the
one
version
to
the
other
for
the
for
the
connection
tracking
and
then
all
these
udp
ipv6,
the
ones
that
have
to
do
specifically
with
connection
I
prefaced
with
connection
tracking
here
and
then
the
rest
of
things
so
nvidia's
taken
on
at
least
four
of
these
items
here,
row
three
and
row
7
and
row
9
and
row
10..
So
anyway,
we're
working
on
that
today.