►
From YouTube: DASH Workgroup Community Meeting 20220126
Description
January 26, 2022 Community Call
B
So
for
everyone
on
the
call,
while
she's
getting
ready,
we
were
checking
back
on
item
number
nine
on
the
meeting
notes
the
intel,
cythrif,
ptf
and
extension
to
smartnic.
We
thought
we'd
check
back
in
late
january
to
see
if
we
could
extend
the
framework
to
work
with
a
side
device.
So
that's
the
what
we're
going
to
talk
about
here.
A
A
A
There
is
something
called
ptf
which
stands
for
packet
testing
framework.
It
is
a
python-based
data,
plane
test
framework,
it's
based
on
python
unit
test
and
it
is
using
a
scapi
to
create
and
send
packets
and
in
the
picture
we
can
see
some
examples
of
what
packets
can
be
created
like
here,
tcp
tcp,
v6,
udpns
and
others,
and
here
you
can
see
how
and
how
we
can
verify
the
traffic
like.
If
there
is
a
packet
it
doesn't,
there
aren't
any
packet
and
stuff
like
that
site.
A
Df
is
connecting
these
two
components
all
together:
the
internal
framework
of
for
setting
the
site
functionalities
and
the
set
of
functional
tests.
It
uses
ptf
to
test
our
sai
implementation
on
the
top
of
a
switch
api.
It
verifies
the
correctness
of
switch
behavior
and
it
also
verifies
the
psy
interface
implementation.
A
As
it
is
says
here,
this
can
be
executed
on
both
hardware
and
model
like
for
us.
It's
the
final
model
and
tokino
switches,
and
here
is
the
diagram
showing
us.
The
components
of
a
tofino
switch,
a
control
plane
is
the
switch
or
the
network.
Os
psi
is
the
switch
abstraction
interface
layer
and
bmi
is
the
switch
api
that
we
have
implemented.
A
The
thing
that
we
focus
on
are
the
blue
parts
and
the
filet
parts
normally
switch
os
in
order
to
set
something
on
a
device
calls
psi
functions
which
then
called
bmai,
which
programs
the
p4
tables
and
in
psy
ptf
we
do
the
same,
but
we
don't
directly
call
side
functions
but
use
rpc.
The
black
line
is
the
call
via
rpc
to
our
and
and
our
framework
provides
it
in
order
to
to
be
able
to
run
python
tests
that
then,
via
our
pc,
called
sam.
A
A
A
So
our
our
framework
is
prepared
for
a
different
number
of
parts,
but
unfortunately
the
tests
are
not
so
if
someone
needs
a
different
number
of
parts
like
if
someone
needs
more
ports,
then
it's
it's.
Okay,
it's
easy
to
do,
but
if
someone
needs
less
ports
then
we
then
we
use.
Then
probably
the
tests
couldn't
be
executed
as
they
are
today.
A
So
if
someone
needs
less
a
lower
number
of
ports,
then
it
would
require
to
adjust
the
tests
accordingly
or
write
a
new
set
of
tests
basing
on
ones
that
are
already
there.
But
this
is
only
about
tests,
because
the
framework
as
it
contains
the
class
sci
helper
base
without
any
configuration,
can
be
used
for
any
number
of
parts
that
you
need.
A
A
A
A
test
calls
python
wrapper
in
python
wrappers
inside
adapter,
and
then
it
calls
the
rpc
server,
which
then
calls
psi
implementation.
The
left
part
could
be
a
regular
server.
In
our
case,
it
is
connected
to
a
to
point
to
point
with
a
tofino
switch,
so
here
there
would
be
a
tofino
switch
or
other
network
device,
and
here
you
would
have
a
server,
for
example,
with
ubuntu
or
something
that
would
be
able
to
run
the
script
with
tests
and
that's
basically,
the
most
general
overview
that
I
have
for
today.
E
Yeah
I
I
was
just
trying
to
understand
the
more
high-level
picture.
I
understand.
I
think
I
understand
well
with
what
we
just
said,
but
how
does
this
and
maybe
a
the
first
couple
of
meeting
of
minutes
of
the
meeting,
so
maybe
that
is
very
easy,
but
how
does
this
relate
to
what,
for
example,
kris
has
presented
in
the
past
in
this
diagram?
Is
this
an
alternative?
Is
this
an
addition
just
tried
to
understand
our
disposition.
D
Yeah
yeah
right,
so
what
chris
presented
actually
exactly
what
this
is.
This
is
in
just
a
little
bit
more
detail
on
what
it
entails.
You
know
basically,
the
framework
itself,
this
iptf
test
framework
and
how
it
is
you
know,
used
on
the
client
side
and
what
is
needed
on
the
server
side
and
the
test
cases
themselves,
yeah
just
to
double
click
on
what
chris
had
presented
earlier.
G
D
D
So
our
changes
to
bring
this
into
the
smart
nic
side
would
be
to
you
know
not
have
the
assumption
of
the
large
number
of
ports,
because
a
smart
next
side.
You
know
it's
best
if
the
test
actually
takes
the
input
from
the
user.
So
that's
something
we
are
looking
at.
We
have,
you
know,
identified
sort
of
from
very,
very
high
level
the
changes
that
are
needed
and
we
are
looking
at
the
resourcing
within
intel
yeah.
We
may
have
made
some
progress
there
as
well.
F
Thanks,
I
think
I
think
the
most
important
thing
is
what
chris
mentioned
last
week
is
that
the
tests
themselves
can
be
written
independent
of
the
tools
and
that
you
compile
from
that
into
the
tools
and
therefore
we
can
compile
it
to
exercise
the
data
or
the
southbound
interfaces,
etc.
So,
as
long
as
we
continue
down
so
that
chris
and
others
who
are
working
on
testing
continue
to
write
the
test,
while
we
figure
out
the
details
of
how
you
integrate
those
tests.
G
Yeah
thanks
gerald,
if
I
could
expand
on
that
a
little
bit
and
appreciate
the
support,
so
I'm
proposing
that
we
write
test
cases
in
sort
of
an
abstract
format
and
your
your
comment
is
precious.
We
write
them
in
abstract
format,
so
it's
somewhat
independent
of
the
let's
say
the
data
plane
api,
whether
it's
a
northbound
or
an
interface
and
even
the
packet
generation
framework
and
that's
that's
kind
of
an
aspirational
goal.
G
But
to
get
more
specific,
we
have
created
an
open
traffic
generator
data
model
for
packet,
testers
that
can
be
used
in
both
software
and
hardware
based
packet
testers.
I
talked
about
this
before
in
the
group
meetings,
and
I've
also
documented
it
in
in
the
test
high
level
documents,
I'm
going
to
just
paste
a
couple
of
links
here
in
the
chat
that
people
can
look
at.
It
introduces
this
concept
and
we're
going
to
be
going
down
that
path
for
new
tests.
G
So
I
encourage
people
to
learn
a
bit
about
it,
but
in
a
nutshell,
you
can
write
tests
using
an
open
data
model.
That's
a
community
repo
called
open
traffic
generator
and
we
have
wrappers
with
simple
python
clients
where
you
can
control
traffic
generators
that
are
either
software
or
hardware
based
that's
vendor
neutral.
So
that's
the
path
we're
going
to
go
down
and
I
think
these
two
paths
can
be
complementary
and
both
be
applied
to
dash.
E
E
G
The
the
test
won't
be
the
same.
The
the
representation
at
the
higher
highest
level
could
potentially
be
the
same
and
translated
into
the
appropriate
interface
through
a
wrapper
of
some
sort.
Now
that's.
This
is
a
this
is
an
aspirational.
We
don't
have
working
demonstration
of
this,
but
this
is
the
approach
we'd
like
to
take,
and
so,
for
example,
if
you
have
a
data
model
that
says,
here's
a
routing
table
or
here's
a
list
of
apples,
those
can
be
represented
in
some
abstract
way
and
then
translated
into
the
appropriate
gnmi
interface.
G
Once
we
have
that
data
model
or
it
can
be
translated
into
psi,
table
entries
if
they're
all
actual
rules,
the
content
is
roughly
the
same.
Now,
if
there's
some
much
higher
level
abstractions,
then
we
have
to
maybe
they'll
only
apply
at
one
interface.
So
it's
an
aspirational
goal,
but
I
don't
think
anyone
would
disagree,
be
nice
to
write
the
the
highest
level
test
case
once
and
and
leverage
that
across
different
interfaces.
F
G
G
B
B
D
Sure
we
can,
I
I
will
discuss
with
you
offline
on
that
timeline,
but
but
it
would
take.
You
know
we
can
start
with
the
underlay
features,
of
course,
and
the
most
critical
ones
that
we
can
identify
that
we
have
to
take
up
for
this
effort
and
then
incrementally
add
more
test
cases
that
we
would
like
to
move
to
smartnik
yeah,
and
then
we
have
made
some
progress
in
identifying
the
resource,
but
we'll
you
know,
update
you
offline
on
that
part.
H
D
B
A
For
now
there
are
a
couple
of
sure
full
requests.
First,
pull
request
contains
only
the
framework
and
general
information
about
it,
and
then
there
are
more
pull
requests.
You
can
find
them
all
in
this
repo.
Not
all
of
them
are
merged
yet,
but
they
all
contain
the
tests
that
we
have
there's.
One
pull
request
per
feature.
B
I
G
Okay
regarding
the
previous
presentation,
with
the
ptf
framework,
just
to
point
out
that
those
tests
and
that
framework
uses
scappy
and
scappy
is
not
a
line
rate
packet,
testing
framework
right.
It's
it's
a
python
library,
and
so
it's
going
to
be
pretty
limited
in
terms
of
line
rate
and
it's
really
a
software
kind
of
thousands
or
maybe
millions
of
packets
per
second.
But
not
it's
not
100
megabit
type
speeds.
G
So
that's
another
reason
why
the
open
traffic
generator
framework
is
being
proposed
because
it
this
really
goes
up
to
any
line
rate
commercial
testing,
speed
and
even
with
a
software
nik
based
tester,
it
can
run
you
know
tens
and
tens
of
gigabits
per
second.
So
these
ptf
tests
are
sort
of
functional
tests
or
you
can
send
some
packets
here
and
some
packets
there,
but
I
don't
think
it's
intended
for
line
rate.
If
anyone,
if
I'm
wrong,
please
correct
me.
J
F
So
I
do
want
to
make
sure
that
we
keep
that
in
mind
that,
when
we're
building
this
framework
that
we
think
about,
if
we
moved
it
to
the
cloud,
we
could
make
it
as
big
as
we
want
and
as
wide
as
we
want,
and
we
can
have
as
many
vms
as
we
want
to
create
tests.
So
just
keep
that
in
mind
when
you're
thinking
about
how
you
want
to
write
these
check.
G
Out
the
framework
itself
yeah
gerald
thanks
for
that,
that's
kind
of
a
lead-in,
we're
actually
working
in
some
engagements
where
we're
doing
that
with
our
software
traffic
generators
and
we're
gaining
quite
a
bit
of
experience
with
that
we
can.
We
can
definitely
pursue
that
and
welcome
some
brainstorming
sessions
on
that.
B
F
No,
I
will
have
to
go.
The
only
thing
is
that
I
would
like
people
to
consider
participating
directly
with
the
test
group
and
and
make
sure
that
we're
not
all
watching,
like
there's
people
actively
actively
contributing
their
engineering
might
behind
this.
So
I
really
encourage
people
to
get
involved,
and
I
remind
you
this
is
not
a
microsoft
effort.
This
is
a
community
effort,
so
we
would
like
the
community
to
be
super
involved
in,
but
at
the
same
time
microsoft's
going
to
deploy
this
so
the
faster
we
get
there.
B
B
Charles
thanks
thanks
thanks
and
you
know
guys
tracking
work
item
number
three
where
help
is
needed.
If
any
of
y'all
can
help
would
be
the
pipeline
directory
to-do
list
number
three
from
nvidia,
it's
posted
in
the
meeting
notes,
and
I
can
I'll
resend
that
when
I
collate
the
meeting
notes
again
andy,
why
don't
you
go
ahead?.
K
K
I
Yes,
so
we're
starting
with
not
bmv2
directly,
but
with
the
translation
psi
to
before
runtime
to
be
able
to
configure
the
simulator.
That's
the
first
step,
because
we
have
this
missing
and
only
after
that
we
will
be
looking
at
the
items
related
to
the
bmv2
itself
like
functionality.
It
is
missing,
for
example,
connection
tracking,
but
for
now
we
still
have
a
missing
glue
layer
from
psy
to
to
before
hunting
thanks.
B
H
B
You
know,
we've
put
it
here
in
the
pull
requests
for
building
out
the
high
level
design
for
dash
here,
and
you
know
we
did
see
some
of
this
work
last
week,
some
of
it,
but
we've
been,
you
know,
we're
always
changing
it.
It's
almost
like
a
living
document.
So,
let's
see
you
found
so
again
work
in
process.
I've
been
working
with
the
sonic
team
to
more
clearly
explain
as
we're
moving
on
in
the
development
of
the
project.
B
What
we're
trying
to
do,
and
so
we're
creating
the
text
here
to
read
through
we're,
creating
some
very
high
level,
designs
and
containers
and
again,
if,
if
you
have
comments
or
if
something's,
not
clear,
please
just
make
a
suggestion
and
we
can
take
it
back
and
incorporate
it
into
the
documentation.
We
do
assume
here.
We
do
assume
familiarity
with
the
sonic
architecture
because
we're
basically
adding
you,
know
a
user
space
container.
So
if
there
are
questions,
please
throw
them
in
as
suggestions
or
questions.
B
We
talked
about
the
sdn
controller
a
lot
last
week,
so
we
put
together
a
blurb
here
about
the
sdn
controller
and
then
the
the
dash
container
here
so
we've
moved
we've
fleshed
out
this
piece
and
also
talked
about
multiple
dps
per
device,
and
we've
talked
a
bit
about
the
psi
and
so
long
story
short
we're
just
filling
this
out
as
we're.
You
know,
moving
forward
in
the
project
and
you've
seen
these
where
we
have
the
single
dpu
on
the
neck
here,
and
then
we
have
the
appliance
architecture
with
the
high
level.
B
You
know
this
is
presenting
as
an
appliance
with
all
the
dpus
and
then
the
low
level.
You
know
where
it
works
with
sonic
and
the
dash
container
here
hope
I'm
not
going
too
fast,
and
this
is
just
a
regular
to
be
clear.
This
is
just
a
regular
sonic
tour
inside
of
a
42
or
48
ru
rack
that
sits
with
the
two
servers
that
hold
the
six
nicks
apiece.
B
B
You
know,
dash
on
the
nic
down
here
or
on
an
appliance
over
here.
You
know
there's
a
rack
with
an
appliance
or
so
I
was
trying
or
a
smart
switch.
You
know
anywhere
in
the
data
center,
so
it
was
trying
to
convey
that
you
could
place
this.
You
know
at
different
locations
within
the
data
centers
and
then
that's
the
end
of
the
run
through
here
of
the
high
level
design
we're
sitting
in
a
pr
request.
So
any
comments
would
be
appreciated
and
then
we
also
have
based
on
our
conversation.
B
B
H
Yeah
thanks
a
lot
christina
one,
quick
thing
that
you
know
maybe
it's
worth
mentioning
as
we
talk
about
multiple
different
use
cases,
you
know
especially
saying
which
place
in
the
network
the
the
dash
is,
is
used
and,
as
we
have
heard
in
in
earlier
meetings,
you
know
some
priority
part
right
saying
that
okay,
you
know.
Currently,
we
are
essentially
looking
at
the
smart
switch
use
case.
First
before
we
look
at
other
things,
so
I
guess
it.
You
know
just
just
to
really
reiterate
that.
H
B
H
B
L
L
So
therefore
you
know
as
soon
as
you
know,
those
you
know
the
stores
available.
Then
we
can,
you
know
start
you
know,
testing
the
software
on
top
of
those
those
tours
as
well
right.
So
because
I
think
you
know
on
us
we're
focusing
on
the
software.
You
know
the
size,
all
those
you
know
define
this
activity
which
can
be
used
for
both
deployment
deployment
type.
Does
he
answer.
H
Yeah
yeah
it
does,
I
think
you
know,
but
obviously
you
know
one
thing
is
we
are
working
on
on
the
software
side,
but
another
thing
is
basically,
you
know
testing
as
well,
as
you
know,
qualifying
a
certain
solution,
yeah
and
then
obviously
you
know
everyone
here.
You
know,
as
gerald
also
mentioned.
If
microsoft
has
a
plans
to
deploy
something,
then
people
can
prioritize
one
versus
the
other.
H
Based
on
what
what
is
the
you
know,
the
initial
goal
is,
for
example,
I
mean
we
all
understand
that
you
know
we
we
will
be
doing
and
then
a
lot
of
things
are
are
applicable
across
architectures,
but
it's
just
about
you
know,
testing
and
really
diverting
the
resources
to
to
one
use
case
versus
the
other
right.
Yeah.
L
Yeah
yeah,
I
think
you
know
to
to
to
address
that
right.
So
I
think
you
know
we're
trying
to
work
with.
You
know
the
hardware
vendors
you
know
to
because
so
far
right
now,
so
we
we,
we
didn't
really
have
a
you
know
such
kind
of
smart
tour
with
you
know
those
those
advanced
pro
programmable.
You
know
chips
embedded
with
the
switches,
so
I
think
as
soon
as
we
have
those
you
know,
you
know,
or
anyone
has
any
plans
to
build
such
things.
L
L
Yeah,
but-
but
I
think
you
know
on
this
forum,
I
think
right
so
you
know
everybody
here,
so
we
discuss
all
this.
You
know
the
common
software
architectures.
You
know
ensure
that
you
know
the
same.
Software
will
be
able
to
run
on
both
on
different
deployment
type,
because
I
would
imagine
you
know
even
the
you
know
in
our
in
the
cloud
deployment
right
so
because
you
know
different
deployment
have
a
you
know
pro
and
accounts
and
there
are
various
different
scenarios
we
need
to
take.
L
B
C
C
E
M
G
G
G
I'm
trying
to
show
it
two
ways.
One
is
bottoms
up:
testing
the
data
plane,
starting
at
the
let's
say
what
we've
talked
about
now:
cythrift
traffic
generator
basic
interface
like
the
lowest
data
plane
layer
and
what
I'm
trying
to
do
is
show
us
a
progression,
starting
from
what
is
probably
what's
happening
in
some
cases
right
now
in
different
providers
laboratories
and
even
in
our
laboratory,
where
we
have
proprietary
tools
on
the
on
the
device,
people
are
using
handwritten
tests
and
getting
things
working
kind
of
bootstrapping
themselves.
G
G
Actually,
that's
the
next
stage
where
we
have
vendors
have
implemented
the
side
library
on
their
device,
and
now
we
can
have
truly
standardized
dash
psi
api
tests,
so
this
would
be
site
thrift,
and
this
this
is
kind
of
the
common
meeting
ground,
where
we
first
have
some
kind
of
a
dash
compliance.
Api.
G
This
basically
also
exercises
the
sci
library
but
you're,
also
getting
parts
of
the
sonic
stack
integrated
and
this
level
of
this
abstraction
here
is
easy
to
work
with.
So
it's
like
the
next
step
towards
integrating
with
sonic.
First,
you
just
have
psi
lib
psi
here
with
psi
thrift,
and
then
you've
got
parts
of
sonic,
so
we're
going
to
be
exploring
this
as
well.
G
I
need
to
update
this,
because
this
would
be
the
what
we
call
have
has
been
called
the
dash
container,
but
this
is
a
gnoi
server
with
schema
that
michael
sigmund
said,
he's
working
on
and
will
be
releasing.
Maybe
late
this
month
or
next
early
next
month,
this
is
where
you
actually
have
this:
the
sonic
northbound
interface.
G
G
E
G
E
G
Putting
it
that
way,
I
wrote
in
this
document
that
this
is
like
this
interface
is
the
minimum
one
to
demonstrate,
and
now
I
think,
that's
for
the
community
to
jointly
decide
and
microsoft
probably
has
a
strong
opinion
on
this,
but
this
is
this
is,
I
think,
a
I
would
call
it
a
convenience,
but
it
may
become
very
compelling
convenience,
but
this
is
definitely
probably
a
conformance
requirement,
and
so
does
anyone
have
anything
to
add
to
that
or
inject.
Does
microsoft
have
an
opinion
on
this?
L
G
And
I
I
stated
here
stage
three
duct
configuration
via
side
surface,
deemed
the
minimum
gate
for
dash
performance
and
conformance
testing.
So
that
was
my
proposal
and
I
think
we
basically
come
to
that
conclusion,
and
I
think
stage
four
here
is:
I
think,
when
we
get
to
that
point,
people
will
decide.
You
know
what
works
for
them.
I
don't
think
it
necessarily
is
a
conformance
test,
but
you
know,
as
gohan
has
alluded
in
the
past.
H
Chris,
just
a
quick
question
on
on
these
stages
right,
it's
stage,
three
four
and
five
yeah,
as
you
show
these
data
driven
automatic
tests
yeah,
since
the
interface
is
different
right,
you
know
whether
you
are
calling
scift
or
cyredis
or
in
the
you
know,
in
the
site,
those
those
tests
and
those
call
those
calls
will
be
different
right.
I
mean
we
just
need
to
highlight
those
ones
because
they
all
say
data
driven
automated
test,
but
they
will
be
different
right.
G
G
G
G
If
the
test
case
is
the
same,
that's
an
exercise
for
the
reader,
so
to
speak
right.
What
I
wouldn't
want
to
see
is
someone
translate
three
apple
tables
into
manually.
Here's
the
literal
contents
in
psi.
Here's
the
literal
contents
in
gm
et
cetera
manually,
because
it's
very
hard
to
generate
many
test
cases
when
you
have
to
manually
create
each
one
like
that,
let's
have
one
common
single
source
of
truth
and
then
translate
it.
It
could
even
be
a
program
that
generates
the
three
different
forms
right
python
script
or
something
so
that
that's
the
hope.
E
G
G
G
Does
that
make
sense?
I
mean
it's
just
a
software
development
progression
so
that
it's
not
you're
not
waiting.
Each
party
is
not
waiting
for
the
other
to
be
ready.
Before
you
can
do
your
your
work,
you
can
make
progress
on
your
way
down
from
the
top
down
and
progress
from
the
bottom
up,
and
then
we
meet
in
the
middle
somewhere,
and
these
are
just
conceptual
stages.
It's
like
a
vocabulary
to
describe.
What's
going
on,
it's
not
a
prescription,
here's
how
you
must
proceed.
H
H
You
know,
as
we
have
actually
seen
it's
it's.
You
know
it's
the
heart
of
sonic,
okay,
it's
really
the
heart
of
sonic,
and
this
is
this-
is
where
the
entire?
You
know
you
know
when
we
say
heart
really,
you
know
we
we
mean
it
that
this
without
it
you
know,
sonic
is
not
there
right
right,
but
at
the
same
time,
in
order
to
really
get
everything
working.
This
is
this
is
a
big
piece
of
work
and
then
this
is
also
can
basically
become
complex
as
well
as
also
you
know.
H
H
E
B
B
L
L
But
it's
mostly
you
know
a
shim
translation
layer
where
you
know
it
takes
a
the
gmi
configuration
and
then
put
into
you
know,
depending
on
where
you
know
where
whether
they
need
persistency
or
not
right
so,
depending
on
some
of
the
character
properties,
they
need
for
those
objects.
And
you
know
the
gmi
is
going
to
put
those
configurations
or
you
know
setups,
and
you
know
routing
interest
or
whatever
into
the
into
the
database
right.
L
So
then
the
database
is
going
to
translate
all
those
interests
into
the
into
the
site.
Function
cost
right,
so
yeah.
So
you
know
in
this
case
you
know
we
do
support
the
the
bluebird
apis,
but
we
do
want
to.
You
know,
keep
those
you
know
this
gmi
as
a
scene
layer.
I
think
most
of
the
translation
logic
there
for
is
going
to
be.
You
know
on
the
on
the
oc
side,.
B
Flow
yeah
thanks
prince
okay,
guys
it's
10
and
I'm
sure
you
all
have
a
10
o'clock,
and
I
know
I
do
so
I'll
send
out
meeting
no
saint
gohan.
Thank
you
for
the
explanation.
Let's
anyone
who
has
questions
on
chris's
test
maturity
or
the
hld.
Please
put
them
in
the
github
as
a
comment
suggestion
or
something,
and
if
there's
other
questions,
email
them
in
or
ping
me
offline,
chrisney,
microsoft.com
and
I'll
talk
to
you
next
week.