►
From YouTube: DASH Behavioral Model WG June 30 2022
Description
TCP state machine discussion and requirements
WB/BB testing discussion
Alignment to P4
Next steps to define APIs
A
Behavioral
model
meeting
today
june
30th
and
it
looks
like
we
have
quite
a
few
people
here-
I'm
gonna
turn
off
my
camera,
and
so
what
I'm
displaying
on
my
screen
is
one
of
the
items
we
wanted
to
bring
over
to
the
behavioral
model.
Meeting
this
week
we
had
talked
about
black
box
versus
white
box
testing
for
a
tcp
state
machine.
I
believe
it
was,
and
we
indicated
that
we
would
discuss
that
here,
and
so
I
added
a
added
a
tracking
item
here.
A
Just
in
my
cheat
sheet
of
things,
we
need
to
work
on,
and
so
maybe
we
could
start
off
that
conversation.
I
think
that
marion
had
indicated
we
we
don't
really
have
apis
to
do
this
and
it
might
be
difficult
per
hardware
supplier.
If
I
remember
is
that
correct
guys
is
that
where
we
left
it
off
last
time.
B
B
A
A
It
looks
like
we
have
a
couple
of
other
people
joining
so
hi
hi,
guys
who
just
joined
we
started
started,
maybe
talking
about
white
box
versus
black
box
testing
and
we
thought
we
might
wait
for
gerald,
since
this
was
more
of
his
question
before
we
got
further
into
it.
So
that's
what
we're
doing
right
now
other
while
we're
waiting.
A
A
A
B
B
B
On
the
inbound
direction,
our
let's
say
final
goal
is
to
find
out
what
is
the
receiving
vm's
public
address
and
do
vxlan
encapsulation
and
send
the
packet
to
it.
So
before
what
we
had
was
that
we
had
an
indirection
of
virtual
machine
and
this
virtual
machine
had
an
attribute
of
the
public
address.
So
basically
the
mapping
was
that
we
previously
found
out
what
eni
we
are
sending
to,
and
we
have
a
mapping
table
from
eni
to
virtual
machine,
and
then
virtual
machine
will
give
us
the
public
address
unrelated
station
ipe
plus
vni.
B
So
from
what
we
saw
when
we
were
reviewing
the
sonic
design
is
that
there
is
no
notion
of
virtual
machine
controller
operates,
and
probably
this
is
even
better,
because
we
have
less
in
directions
and
it
doesn't
really
break
anything.
Controller
simply
operates
with
enis
and
every
dni
has
its
own
public
address.
So
let
me
show
you
that
as
well.
B
So
what
we
want
to
do
is
to
align
behavioral
model
with
this
design
and
move
underlay
ip.
So
we
want
to
remove
those
two
tables
completely
mapping
to
the
virtual
machine
and
simply
put
underlay
ip
and
vxlan
vni
that
is
supposed
to
be.
The
packet
is
supposed
to
be
encapsulated
with
vxlan
header,
just
move
it
directly
to
to
eni
table
like
over
here.
So
we
have
our
eni
table
and
those
two
attributes
now
belong
to
now
belong
to
enid
itself.
So
this
is
the
change.
B
It's
not
really
change
in
the
behavior
like
pack,
it
in
and
pack
it
out
will
look
the
same
for
every
packet
in
that
you
can
come
up
with,
but
we're
just
removing
this
in
direction,
making
less
configuration
flows,
less
less
entities
less
dependencies
that
we
need
to
track
so
kind
of
like
flattened
this
a
little
bit.
So
this
is
the
description
of
the
change.
It's
in
this
pull
request-
and
I
saw
chris
asked
me
to
merge
it
after.
D
E
D
A
F
A
Rupert,
okay,
great
so
yeah,
oh
hey
gerald
hi!
We
were
just
going
over
a
pull
request
from
marianne
to
place
two
attributes
into
a
different
table,
not
not
anything
that
you
really
missed
there.
So
yeah
thanks
for
joining.
We
were
also
talking
about
the
topic
from
last
week,
where
we
wanted
to
move
the
conversation
around
black
box
and
white
box
testing
over
to
the
behavioral
model
meeting
and
the
guys
here
wanted
to
wait
for
you
to
join.
So
we
could
have
your
opinion
as
well.
A
G
G
A
B
And
about
so
the
state
should
be
per
connection
and
the
another
question
I
have:
how
will
do
we
assume
that
we
know
the
five
tuple
or
is
it
something
that
also
api
should
provide
like
a
notification
about
what
five
tuples
are
learned
and
then
we
will
go
over
them
or
do
we
assume
that
the
test
will
know
what
five
tablet
is
interested
in
and
it
will
tell
exactly
I'm
interested
in
this
flow.
So
give
me
its
state.
Is
that.
G
The
assumption
that's
more
realistic,
because,
when
we're
doing
testing
we
know
what
we're
sending
in.
We
know
the
five
tables
we're
just
trying
to
check
the
so
we
expect
that
connection
to
be
in
some
kind
of
state,
depending
on
what
we
just
sent.
So
we
would
be
saying
I
want
to
see
the
state
for
this
five
tuple.
Yes,.
G
I
don't
need
to
do
a
walk
of
it.
It
could
be
like
way
too
many
you
just
like
a
a
five
tuple.
I
wanna
see
the
state
connection
state
of
that
udp
or
tcp.
In
fact,
whatever
we
decide
for
udp
way,
when
we're
doing
functional
testing,
we
can
we
can
get
a
much
better,
clear
understanding
of
the
different
implementations
and
what's
happening
and
that
that
the
behavioral
model
tcp
state
machine,
whatever
it
ends
up
being,
is
being
followed,
not
some
something
completely
different.
G
You
should
have
you
should
have
a
connection
in
your
the
fast
path
table
right.
You
have
a
connection
in
that
connection.
You
have
to
be
holding
stuff,
I
mean
you
have
pointers
to
the
mappings.
You
have
pointers
to
the
to
the
output
interface.
You
have
you'll
have
in
that
you
have
counters
whatever,
but
you
should
also
have
the
tcp
state.
There
too.
I
mean
that,
where
else
would
you
keep
it.
H
C
Let
me
catch
you
up
a
little
bit
from
last
week.
I
think
on
this.
If
I
may
so
gerald
posited
that
we
ought
to
be
able
to
read
the
state,
you
know
exercise
this
tcp
state
machine
through
its
paces.
You
know
at
a
controlled
way
kind
of
like
a
white
box
test.
Then
we
read
back
the
state.
We
didn't
get
into
how
that'll
be
done
and
what
we're
talking
about
is
maybe
how
but
we
did
talk
about
the
need
for
an
api
in
which
you
can
read
the
state.
C
C
Then
we
would
decide
how
to
do
that
and
you
know.
Is
there
a
psi
api
that
just
hand
written
that
says?
Read
me
the
state
or
do
we
use
p4
code
to
model
the
observability
of
the
tcp
state
and
auto
generate
the
header
both
of
those
are
options.
Our
options
right
and
marion
has
already
taken
some
steps,
we'll
be
doing
additional
handwritten
psi
apis
where,
in
which
case,
in
those
cases
where
the
p4
code
doesn't
express,
for
example,
init
sci
api
query.
C
That's
like
an
out
of
band
kind
of
a
api
that
you
have
to
hand
write.
It
doesn't
come
out
of
the
p4
code.
The
the
tcp
state
machine
read
might
be
another
handwritten
api.
If
there's
no
p4
model
of
that,
if
you
don't
try
to
impose
on
the
model,
you
can
read
the
state,
but
that
makes
it
tricky
to
model
in
bmv
too
right.
So
we'll
have
to
sort
that
out.
I
think,
but
there
is
a
tcp
state.
G
E
G
E
G
Want
them
to
they
don't
have
to
implement
the
behavioral
model
like
that,
but
we
do
want
them
to
have
the
exact
same
behavior
of
the
tcp
state
machine
that
we
are
defining
in
the
behavioral
model
only
way
I
can
yes
see.
That
is,
I
mean
if
whether
it's
auto
generated,
because
they
have
a
different
kind
of
model
or
not,
it
still
has
that
same
behavior.
G
I
can
kind
of
try
to
do
that
from
the
outside,
but
I
would
rather
be
able
to,
as
I
stimulated
know,
that
they're
going
through
the
states,
because
that
way
we
can
make
corrections
and
we
can
tell
everybody
about
those
corrections,
etc.
Otherwise,
it's
just
us
finding
out
of
every
single
design
that
don't
behave,
the
same
way
that
sort
of
behave,
but
they
don't
and
they
miss
the
states
or
whatever
we
don't
get
the
shared
learnings
out
of
it
by
the
way.
C
Is
there
going
to
be
a
technical
or
performance
burden
to
do
this,
or
is
it
just
a
little
bit
of
plumbing
and
api
work?
You
know
we
should.
We
should
have
a
reality
checker
to
make
sure
it's
like.
Oh
no.
This
has
massive
implications
on
a
production
version.
For
example,
does
anyone
have
any
opinion
on
that
any
of
the
vendors
just
so
we
don't
ivory
tower
ourselves
into
a
corner.
A
I
I
Exactly
where,
with
a
black
box
test,
you
would
just
shoot
like
a
series
of
packets
at
the
target
and
the
the
timing
is
not
really
an
issue
for
that
type
of
testing
like
with
the
well-crafted
packet.
After
I
mean
sorry,
let
me
take
a
step
back
so
you'd
send
a
bunch
of
packets
to
get
the
flow
table
into
a
certain
state
and
then
you'd
send
a
couple
packets
like
immediately
afterwards.
C
But
do
you
think
if
there
were
programmable
timers
for
the
various
aging
mechanisms
that
that
could
be
part
of
the
test
controller
to
say
we'll
make
this
timer
long
enough
so
that
we
don't
have
any
race
conditions
yeah
sure
another?
Is
that
another
burden
or
that
just
be
kind
of
a
a
low-hanging
fruit
way
of
doing
it?.
I
G
A
G
Yeah,
we
won't
have
a
problem
with
that.
I
don't
think
that
should
yeah,
that
it
really
shouldn't
be
and
it
would
never
be
used.
You
wouldn't
use
this
on
a
live
unit
right
field.
This
is
you'd,
get
junko
right
because
things
just
changed
so
fast
you'd
only
be
using
this
for
for
correctness,
testing,
and
so
it's
the
performance
is
not
what
we're
after
there
you're.
Just
after
doing
functional
tests.
C
Yeah
even
instrumenting
the
implementation
to
do
this,
even
if
you
only
use
it
in
testing
slowly,
would
that
act
of
instrumenting.
It
cause
a
burden
in
production
code
or
would
it
need
to
be
like
a
build
option,
because
you
know
there's
things
like
synchronization
mechanisms
that
could
you
know
artificial
ones
for
this
testing
that
could
then
burden
the
production
code.
G
D
I'm
trying
to
understand
guys,
you
know
the
requirements.
Sorry,
this
is
probably
a
little
slow
on
this
one,
but
if
you,
if
you're
trying
to
you,
know,
find
out
the
current
state
of
a
connection
which
hasn't
really
completely
come
up
right
because
generally,
what
happens
is
that
you
know
if,
if
there
is
a,
if
you're
looking
for
a
flow,
and
if
the
flow
is
a
is
a
mess,
then
essentially
it
is.
It
is
still
is
in
the
connection
tracking.
D
G
If
you
send
a
syn
packet,
it
opens
up
a
connection
in
that
table
as
soon
as
that,
synth
packet
is
arrives
and
then
it
just
it
just
follows
state
until
it
closes
that
connection,
which
is
far
down
the
line
when
you
receive
all
six
packets
or
some
time
out,
it's
not
something
that
happens
slowly.
I
mean
the.
G
In
the
flow
table,
yes
and
then
once
a
connection
is
you
know
it
is
created,
it
has
to
hold
the
tcp
state,
otherwise,
like
there's,
it
has
to
right,
there's
no
other
way
of
doing
that.
I
can't
cure
it
so,
given
that
it
has
to
have
that
state
in
order
for
it
to
implement
the
state
transitions,
we
should
be
able
to
read
it,
and
that's
all
I'm
saying
and
that
every
time
I
send
a
packet,
I
don't
even
need
to
wait
within
nanoseconds.
That
state
will
have
been
updated.
C
C
Go
ahead,
I
would
say
just
for
the
record
if,
if
people
implementing
this,
this
observability
run
into
issues
where
performance
or
interference
is
a
concern
with
production
version,
they
should
consider
a
build
option
for
white
box
testing
versus
production
and
just
kind
of
even
escape
hatch.
There
yeah.
G
G
I
G
G
C
A
Thanks
everybody,
that's
awesome,
and
thanks
for
coming
gerald
to
walk
us
through
your
opinions
on
that.
If
you,
if
you
guys,
can
see
my
screaming,
we
can
shift
topics
here.
We
did
get
a
couple
more
things
done
here
in
our
list
of
items
to
work
on.
So
thank
you
for
that
and
I
believe
we
did
split
out
the
ipv6
ackl
into
a
different
issue.
I
think
we
talked
about
that
already.
We
moved
a
couple
of
things
to
75
percent.
Complete
I've
changed
dependency
here
like
this.
A
A
B
A
H
A
E
E
A
A
A
A
J
A
A
E
D
J
E
No,
I
think
it's
orthogonal,
because
ip
v6
or
v4
is
connectionless,
whether
you
have
optional
headers,
you
know
options
in
the
ipv4
or
extension
headers
in
the
ipv6
in
ipv6.
It's
it's
just
that
we
are
not
currently
able
to
pass
them
and
and
process
them.
So
you
know
if
you
have
a
routing
header,
we
are
not
looking
at
it.
I
I
actually,
I
don't
think
only
we
are
not
looking
at
it.
I'm
not
sure
we
are
skipping
it
and
going
to
the
tcp.