►
From YouTube: DASH High Availability Working Group July 12 2022
Description
Continue API details
Definition of switch_id
Active/Active convo
Protocol definition convo
A
Talking
about
how
to
synchronize
state
and
between
gpus
ips,
epu's,
etc.
So
we
should
probably
get
started.
I'm
displaying
my
screen
right
now
and
I've
started
the
recording
and
the
reason
I
start
out
with
that
is:
if
people
on
the
youtube
channel
want
to
know
what
date
we're
on
I
can.
They
can
hear
it
right
away,
so
so
yeah,
let's
get
started
now.
Last
time
we
talked
marianne,
we
we
didn't
even
make
it
through
the
whole
api
list.
A
Having
more
of
a
conversation
around
other
things,
so
I'm
going
to
stop
displaying
my
screen
unless
you
need
it
up.
There.
C
C
So
last
time
we
finished
on
the
read-only
attribute,
which
is
called
operational
state,
and
there
was
a
feedback
from
michael
that
we
will
probably
need
more
states
right
at
the
beginning,
we
were
considering
only
basically
down
and
fully
synced,
so
he
proposed
to
have
an
intermediate
state
that
would
signal
that
we
we
established
a
session,
but
we
are
not
yet
in
full
sync
and
then
then
we
are
fully
synchronized
to
to
signal
that
as
well.
C
So
this
will
be
done
here.
The
reason
it's
not
yet
it's
not
yet
in
this
proposal
is
that
we
had
a
little
bit
of
a
confusion
with
psy
maintainers.
They
merged
a
pull
request
a
little
too
soon,
so
I
asked
them
to
regulate
it,
so
we
can
complete
this
one.
So
after
it
will
be
moved
away
from
dash
branch,
I
will
make
the
change
to
have
this
operational
state
as
an
enumeration
with
more
options
than
than
just
up
and
down
okay.
C
So
this
was
the
update
on
the
feedback
from
from
michael
next,
we
have
some
a
couple
of
optional
attributes.
Two
of
them
are
related
to
a
mode
of
or
an
implementation
that
would
want
to
aggregate
updates
into
batches.
So
for
that
we
defined.
C
C
Update
notification
to
to
the
other
side,
so
the
quantity
here
or
the
type
of
this
one
is
in
the
number
of
messages.
So
it's
u32
by
default,
it's
one!
So
we
consider
that
by
default
or
if
this
is
not
supported,
we
are
just
sending
one
update
at
a
time,
and
second,
one
is
the:
let's
call
it
a
necessary
side
effect
of
batching,
since
we
are
not
sending
updates
immediately
after
we
receive
the
new
connection,
there
should
be
some
limit
on
when
we
actually
do
send
it.
C
So
let's
say
we
have
defined
quite
a
large
batch
which
might
take
more
than
desired
time
for
delta
and
time
for
two
systems
to
be
in
sync.
So
we
want
to
limit
that
and
in
case,
if
we
breach
that
timeout,
a
shorter
update
message
will
be
sent
without
waiting
for
the
full
badge
to
be
filled.
C
So
this
is
what
this
one
is
for
and
again
it
assumes
that,
since
this
is
optional,
and
by
default
we
might
not
use
it
so
default
is
zero,
meaning
that
we
send
all
updates
immediately
and
then,
if
the
one
that
is
actually
using,
that
in
production
will
want
to
relax,
this
behavior
provide
a
bigger
timeout
than
it
can.
C
The
timeout
can
grow
so
value
is
in
microseconds
10
to
the
minus
six
of
a
second
yeah.
So
these
are
the
two
remaining
attributes,
and
that
is
it
that's
basically,
all
we
want
to
have
available
from
the
api
point
of
view
for
the
first
iteration
of
high
availability
and
since,
of
course,
this
is
psi
apis
for
those
who
are
not
maybe
that
familiar
with
those.
These
are
just
the
attributes
of
a
new
object,
so
psy
object
model
defines
four
different
apis
for
them,
which
is
create
session.
C
Remove
session
set
session,
attribute
the
one
that
I've
shown
and
get
session
attribute
so
create
session.
Basically,
there
is
an
a
return
parameter
which
will
give
you
a
handle
of
that
session
id.
C
This
is
the
id
of
your
device
that
is
received
when
psi
is
initialized
number
of
attributes
from
from
this
enum
and
this
attribute
list.
So
when
the
session
is
created,
we
pass
the
whole
list
of
attributes.
Basically,
this
is
like
the
constructor
of
the
object.
Then
we
have
properties
and
abilities
to
set
and
get
individual
attributes
over
here
set
attribute,
which
is
done
one
by
one.
So
we
can
change
one
attribute
at
a
time
yeah.
So
that's!
C
That's
it
that's
the
api,
as
I
said
as
soon
as
it
will
be
reverted
because
it
was
merged
by
mistake.
I
will
update
this
one.
Another
thing
that
is
related
to
this
attribute
is,
since
this
is
an
attribute,
a
read-only
one.
We
can
use
it
in
polling
mode,
it's
not
very
convenient.
You
don't
want
to
overwhelm
the
cpu
with
any
kind
of
polling.
C
I
will
also
add
a
notification
function
that
will
signal
any
change
of
this
attribute
that
sonic
just
needs
to
subscribe
to
without
falling.
This
is
a
common
common
way
of
doing
things
inside
we
have
such
callbacks
for
port
operational
state
change,
which
is
similar
in
the
semantics.
C
Fdb
events
like
new
entry
learned
so
to
not
overwhelm
this.
If
you,
we
will
do
the
same
thing
in
here.
It
will
be
event
based
update
yeah
right.
So
these
are
the
two
remaining
changes.
C
D
C
C
It's
I
think
it's
more
complicated
to
start
with
and
not
sure
if
there
is
a
good
reason
to
do
so.
So
in
that
case
it
would
be
the
smart
switch
id
and
in
other
case
we,
even
though
this
is
a
smart
switch,
it
has
a
notion
of
different
npus
inside.
So
we
will.
C
A
I'm
wondering
when
do
you
think
we'll
decide
the
the
answer
was
to
hide
all
the
dps
under
the
same
side,
blah
blah
blah
we'll
probably
decide
that
after
we
look
at
performance
benchmarks.
Is
that
right?
Marianne.
C
I
don't
think
it's
related
to
performance,
it's
more
about
who's,
making
the
decisions.
Do
we
leave
decision
making
to
psy
implementation,
or
we
can
define
some
common
logic,
common
benchmarks,
common
telemetry,
counters,
etc.
That
will
allow
sonic
software
to
make
the
decision
what
to
program
on
what
device,
so
it
will
be
transparent.
E
E
You
know,
and
I
think
from
a
risk
management
point
of
view
we
might
want
to
you
know
sort
of
agree
that
maybe
this
first
disaggregated
model
or
distributed
model
is
more
pragmatic
and
treat
the
other
one
as
an
optimization
option.
I
think
it's
just
a
point
of
view.
You
know
a
wrist
point
of
view.
It's
almost
like
making
a
waterfall
project
out
of
it
and
you
know
you
know,
we
know
how
those
go.
E
E
A
And
and
when
I
forgot
in
the
beginning,
when
mccall
zigg
had
feedback
about
the
operational
state
and
he
had
listed,
you
know
many
different
states
that
we
could
be
in.
Did
anyone
go
back
and
do
any
research?
In
the
past
I
mean
there's
a
lot
of
different
operational
states
for
different
technologies.
Are
we
reusing
anything?
Are
we
just
coming
up
with
our
own
yeah?
Actually.
F
C
Working
with
a
sorry,
I
don't
know
his
exact
position,
but
he's
from
university
of
cornell.
There
is
a
second
paper
by
him
with
regards
to
state
synchronization
of
systems
so
yeah
we
are
working
on
reviewing
the
work
done
before
to
see
if
we
can
use
anything
of
it.
So.
A
Site
yeah,
the
telecom
world
probably
had
this
all
figured
out
or
these
guys.
So
that's
great.
So
so
we've
gone
through
the
content
we
have
today
did
anyone
else
have
questions
or
things
they
wanted
to
bring
up.
I
I
know
that
I
think
vijay
you
had
said.
Maybe
you
would
want
to
contribute
or
was
that
to
behavioral
model.
H
Yeah
hi:
this
is
vijay
from
amd
pensando
yeah.
I
think
we
wanted
to
contribute
to
the
behavioral
model.
I
think
one
particular
thing
in
question
was
one
of
the
open
items
which
was
the
routing
type
we
net
direct.
I
believe
we
have
some
some
changes
which
are
in
line
which
can
address
this
particular
item.
So
that's
the
thing
that
we
wanted
to
just
bring
it
out.
So
I
guess
we'll
reach
out
to
marion
and
christina
separately.
Is
that
okay,
yeah.
A
Do
you
prefer
suggestions
in
a
pr
format,
marion
or
because
it's
so
early,
you
know
just
reaching
out.
C
C
C
A
H
Yeah,
absolutely,
I
think,
that's
kind
of
works
better
for
us
too.
We
can
raise
a
pr
and
we
can
address
comments
on
that
and
discuss
around
that
period.
A
That's
great,
thank
you.
Thank
you
for
volunteering.
I
appreciate
that.
Does
anyone
else
have
anything
this
time
around.
G
Continuing
with
the
high
availability
discussion
right
so
marianne
last
time,
michael
and
all
of
us,
we
had
discussed
that
we
want
the
two
pairs
of
the
session
to
be
in
active,
active
mode
right.
Is
that
still
under
consideration
and
is?
Is
that
what's
reflected
in
the
apis
and
the
model
in
the
document.
C
So
there
is
no,
there
is
nothing
that
prohibits.
C
G
C
They
should
be
applicable.
I
am
still,
however,
looking
into
if
we
didn't
miss
anything
for
smart
switch
scenario,
but
desire
is,
and
intention
is
to
have
the
same
apis
working
on
both.
So
basically,
it's
not
only
it's
the
whole
transition
from
let's
say
appliance,
which
is
easier
to
bring
up
initially,
because
it's
basically
just
gpus
plugged
into
a
pci
and
then
move
it
to
some
more
complex
form
factors.
C
But
the
whole
idea
is
that
we
want
to
have
a
software
which
will
take
a
minimal
effort
to
move
it
to
smart
switch
form
factor,
not
only
everything
else
as
well.
G
Right,
in
the
point
of
view
right,
we
need
two
dpus
to
work
in
pairs
right
for
for
h
a
so
you
know.
One
thing
to
consider
is
that
there
are
the
views
inside
of
a
smart
switch.
G
Will
the
hab
between
the
two
you
know,
pairs
of
the
dps
or
as
a
smart,
switch
on
the
hole
with
another
smart
switch,
and
those
are
the
considerations
as
well
that
we
need
to
look
into.
E
From
from
gerald
talking
about
this
in
the
past,
sorry,
the
the
pure
dpu
could
be
anywhere
in
the
data
center.
G
G
Is
yes
right
anywhere
in
the
data
center
right?
So
now,
if
we
consider
one
smart
switch,
which
has
multiple
dpus
inside
of
it?
Will
there
be?
You
know,
pairs
inside
of
the
smart
switch
or
we
are
looking
at
the
smart
switch
because
you
know
it
has
each
smart
switch,
each
dpu
will
suppose
have
8
million
or
16
16
million
flows,
total
capacity
suppose
so
the
overall
smart
switch
will
have
aggregate
capacity
of
very
large
capacity
right.
G
So
the
total
number
of
flows
that,
if
we
look
at
you
know,
and
if
we
have
a
central
cpu
that
is
managing
all
the
you
know,
distribution
distribution
of
flows
across
all
the
dps
within
the
smart
switch.
One
thing
to
consider
is
that,
okay,
if
the
entire
smart
switch
is
considered
as
one
entity
and
then
do,
we
need
to
have
a
pair
of
that
sort.
You
know
you
know
and
outside
somewhere
in
the
data
center.
B
If
it
so
happens
that
hey
you
know,
if
there
is
only
one
smart
switch
in
in
there
at
all,
then
of
course
you
know
you
try
to
basically
leverage
those
four.
Let's
say
there
are
four
dpos
in
that
smart
switch
and
you
say:
okay,
I'm
gonna
do
a
pairwise
within
those
ones.
But
if
you
have
multiple
smart
switches,
then
you
are
going
to
really
spread
out
that
failure,
domain
and
say.
Okay,
let
me
just
you
know,
pick
up
a
pair
of
that
particular
one
and
I'm
gonna
pair
it
up
with
some
other
smart
switch.
B
So
as
to
really
you
know,
leverage
that
and
also
just
distribute
this
failure
domain
so
to
speak
so
that,
even
if
you
know
one
smart
switch
were
to
fail,
other
smart
switch.
So
you
are
spreading
this
one
out
depending
upon
what
knowledge
you
have
as
a
sdn
controller
about
what
is
the
availability
of
your?
You
know.
Hardware
is
across
the
board
and
then
this
is
how
you're
going
to
make
sure
that
you
protect
one
versus
the
other
in
the
best
manner
possible
right
right,
yeah.
It
doesn't.
G
Shouldn't
make
any
just
yeah
base,
everything
is
orchestrated
with
the
view
of.
What's
of
you
know
the
view,
that's
in
the
controller
you
know
do.
Do
we
think
that
the
controller
will
have
access
to
individual
dpus
inside
of
a
smart
switch
and
control
of
how
many
flows
will
go
everywhere
in
each
of
those
defuse
inside
of
a
smart
switch.
G
E
It's
completely
up
to
the
application
software.
In
the
sdn
controller,
we
we
shouldn't
care,
it's
just
a
blast
radius
choice
right
like
to
simplify
what
hana
said
right.
What's
the
blast,
radius
of
a
failure
do
the
right
thing
and
and
also
take
into
account
the
cost
of
the
traffic
in
the
network
and
the
distance
etcetera
right.
Try
some
there'll
be
some
algorithm,
but
it
doesn't
affect
our
software.
D
I
think
this
goes
back
to
what
hanif
said
right
most
in
most
cases
in
the
in
in
a
data
center,
you
will
not
have
the
hr
pairs
within
the
same
failure
domain
right.
So
if
there
is
any
optimizations
we
need
to
do
to
have.
You
know
mult
different
dps
within
the
same
switch
to
be
pairs.
I
think
that
should
be
of
lowest
priority.
In
most
cases
we
can
assume
there
will
be
at
least
two
smart
switches
and
they
would
be
rather
than
two
dps
within
the
same
search.
E
G
Is
based
on
the
you
know,
based
on
the
failure
domain
right
if
something
goes
wrong
in
that
switch
likely,
all
the
dpos
within
the
switch
will
be
affected.
So
if
we
look
at
two
smart
switches
as
individual
entities
and
pair
them
up
in
some
way
right,
that
would
be
a
good
best
practice
to
have.
B
It
could
possibly
be
done
because
of
the
fact
that
I
mentioned
it.
There
is
only
one
happen
to
be
that
you
know
whatever
be
the
case
right,
whatever
be
the
reason,
if
there
is
only
one
smart
switch
in
a
small
network
where,
basically,
you
know
there
are
four
dpos
in
one
smart
solution.
If
somebody
want
to
pair
it
within
the
smart
switch,
so
be
it
because,
although
yes,
smart
switch
can
fail,
but
so
can
an
individual
dpu
within
a
smart
switch
can
fail
and
it's
still
smart
switch
continue
to
run.
B
H
Right,
I
mean
all
that
is
about
germain
right,
because
once
you
build
the
appropriate
mechanics
on
the
northbound
layers
right,
whether
it's
intra
switch
or
server
and
an
inter
you
know
smart,
yes,
performance,
the
behavior
can
be,
you
know,
made
consistent
exactly
exactly
and
and-
and
there
are
also
other
combinations
of
you
know-
geo-redundancy
and
whatnot-
that
can
come
into
play
between
data
centers
and
you
know
with
other
you
know,
traffic
redirection
capabilities
and
all
of
that
built
right
to
make
it.
You
know
really
esoteric
right.
G
In
that
case,
the
apis
that
we
have
has
switch
id
and
all
that,
so
you
know
how
we
identify
the
dpu
or
the
whole
smart
switch
with
you
know
as
one
entity.
Those
things
will
come
into
picture
and
that's
kind
of
why
I
I
thought
about
bringing
this
up.
H
Yeah
yeah
that
api
is
right
now
fairly
simplistic.
You
can
have
other
translation
layers
built
under
the
guise
of
that
switch
id
right,
switch,
comma
dpu
or
whatever
is
is
the
the
the
numbering
factors
there.
G
A
Yeah
I
just
wanted
to
introduce
up
who
he
works,
with
our
sdn
engineering
team
and
with
james
grantham,
so
he's
joining
in
he's
super
technical
and
excited
to
learn
about.
You
know
how
we're
defining
and
moving
forward
with
h.a
in
this
particular
implementation.
So
I'm
happy
to
have
him
here,
a
poof.
You
can
say
hi
real,
quick.
A
Or
not,
if
you're
on
mute
either
way,
so
so
yeah
I'll
go
ahead
and
stop
the
recording.
If
kind
of
agreement
we've
finished
up
for
the
day.
C
Okay,
actually
yeah,
actually
not
so
two
things
about
that.
First
of
all,
there
are,
it
is
again
a
phased
approach,
so
we
will
definitely
start
with
only
intravendor
compatibility.
C
There
is
no
requirement
out
of
the
batch
to
to
be
able
to
sync
different
dpus
from
different
manufacturers,
etc,
so
that
everyone
can
do
something
under
these
apis
that
they
think
is
optimal
and
later
on,
we
can,
of
course
anyone
can
come
to
this
working
group
propose
their
approach
and
others
can
get
on
board
with
that
and
establish
interventor
compatibility.
A
Right
right
so
would
we
be
defining
a
new
protocol
like
like
we're,
defining
bgp
or
tcp,
or
something
like
that?
Or
I
mean
this
is
kind
of
kind
of
cool
if
we
are
or
reusing
something
so
yeah
anyone
bring
to
the
table
what
you
think
in
the
future.
A
Okay,
so
action
items
for
next
week.
Do
we
have
any
team.
C
Yeah,
probably
not,
I
will
just
leave
the
pull
request
up
to
a
review
when
it
is
updated
and
and
then
I
think
I
would
suggest
if
we
actually
have
agenda,
then
we
can
meet
next
week,
if
not,
who
it's
also
okay,
to
skip
until
there
something
will
come
up.