►
From YouTube: DASH HA Working Group 20220614 (June 14, 2022)
Description
June 14, 2022
Discussion of API requirements
A
B
So
I
have
been
taking
a
few
assumptions
and
topology
constraints
into
defining
this
proposal,
so
I
want
to
go
over
that
first,
we
we
want
to
assume
that
peers
share
the
same
virtual
ip,
meaning
that
there
is.
There
is
no
notion
of
two
dpus
for
the
for
the
host
side
in
case
of
failover.
There
is
no
action
to
be
taken
on
the
by
the
controller
on
the
host
side.
All
the
configuration
there
stays
the
same.
B
C
Hey
so
marion,
I
I
I
don't
necessarily
have
a
problem
with
this,
but
I
kind
of
understood
it
differently.
I
thought
that
it
was
like
some
form
of
ecmp
that
was
like
dividing
like
flows
to
the
you
know
the
to
the
two
dpus
and
not
like
you
know,
like
entire
enis,
are
active
on
one,
and
you
know
back
up
on
the
other.
D
I
thought
that
the
locally
learned
flows
should
be
forwarded
using
that
device
and,
as
we
sync
locally
learned,
flow
information
to
the
peer
who's
participating
in
h
a
you
know.
Those
flows
will
not
be
folded
by
the
peer
device
and
by
you
know,
in
the
same
manner,
the
peer
device
will
have
its
own
locally
learned
flows,
which
it
will
be
forwarding
yeah.
It
could
be
done
both
ways.
It
would
be
good
to
discuss
that.
E
Question
on
that,
so
what
is
a?
What
does
it
really
represent
right?
This?
Is
it's
not
really
the
or
that
is
there
another
ip
address
for
the
peer
that
it
would
use
for
the
flows
that
it
is
active,
because
if
the
third
sentence
says
that
it's
actually
not
active
backup,
it's
active
active
right.
Some
photo
flows
out
on
appear.
Other
flaws
are
on
the
other
pair.
B
Now
the
problem
with
that
is
that,
since
we're
talking
about
having
this
active
active
scenario
where
some
of
e
I's
are
active
on
one
gear
and
other
in
eyes,
are
active
on
the
other
gear,
it
contradicts
a
little
bit
with
the
with
the
topology,
with
the
dp
having
one
whip,
because
it
means
that
all
of
the
all
of
the
traffic,
all
of
the
it's
it's
all
or
nothing.
It's
either.
B
B
The
there
are
constraints
that
prevent
us
from
having
just
half
of
enis
active
on
one
on
one
peer
due
to
the
topology,
because,
as
topology
defines
it
we
will
have,
we
will
have
only
one
one
dpu
in
a
pair
that
can
be
active
at
a
time
or
we
would
need
to
change
the
definition
of
topology,
because
how
it
is
defined
right.
Now
that
the
the
active
one
is
defined
by
a
shorter
bgp
path.
B
B
A
B
B
How
do
you
identify
a
peer
probably
by
the
ip
address,
but
it
cannot
be
a
shared
virtual
ip
as
it
it
cannot
be
properly
routed
to
to
a
virtual
ip.
So
we
we
should
use
some
other
address.
Maybe
there
is
so
maybe
there
is
a
unique
unique
allocated
address
on
the
dpu,
which
is
another
blue
book
ip
or
maybe
we
can
use
address
assigned
on
the
port
of
the
dpu.
B
So
this
is
something
that
will
probably
need
for
further
clarification.
How
we
do
that-
and
this
is
a
mandatory
attribute,
so
we
the
question
here-
is
what
address
do
we
pick
and
what
will
be
the
requirement
for
for
a
dpu
configuration
in
order
to
be
able
to
establish
a
cha
session,
because
again,
a
virtual
ip
will
probably
not
do.
B
D
B
B
Then
administrative
state,
so
we
this
is
basically
for
the
session
setting
it
down,
will
just
stop
saying
effectively,
stop
syncing
the
information
to
appear,
but
it
will
preserve
the
it
will
preserve
the
configuration
of
that
session
and
putting
it
up
when
both
sides
have
it
up.
It
means
that
the
state
synchronization
can
start.
B
Then
we
have
two
attributes
role
and
eni
list,
so
those
two
are
derived
from
from
the
requirement
that
or
from
the
assumption
that
we
will
have
granularity
of
on
the
eni
level,
and
we
and
the
controller
will
will
tell
dp
which
enis
are
active.
So
for
that
we
will
provide
a
list
of
enis
to
be
synced
with
with
this
session.
So
for
the
active
role,
connections
belonging
to
the
cni's
are
sent
to
the
backup
and
role
is
defined
by
this
attribute.
B
B
B
B
B
It's
the
greatest
latency
allowed
for
a
newly
learned
connection
to
be
sent
to
appear
in
if
batch
is
not
full,
so
under
some
circumstances,
circumstances
where
we
have
not
exhausted
our
batch
size
for
a
specified
amount
of
time.
It
will
be
sent
in
a
shorter
message
to
to
have
a
let's
say,
a
fixed
or
deterministic
latency.
B
C
C
D
D
G
I
guess
that
it's
different
layer
like
from
the
part
of
perspective
it's
it,
sends
a
chunk
in
the
size
of
the
max,
whether
the
network
consent
between
one
packet
or
two
packet.
It's
up
to
the
network,
it's
very
hard
to
correlate
between
those
two,
because
you
really
don't
really
control
the
interface
in
which
this
packet
arrives
or
sends.
And
what
is
the
path
into
you
on
that
industry?.
G
C
C
B
H
G
B
G
H
I
B
E
Point
on
the
the
previous
thing
that
we
discussed
right
the
vip.
If,
if
the
whip
is
per
eni,
then
you
know,
then
then
it
would
make
sense
of
what
you're
saying
right.
Nha
group
is
exclusively
to
suddenly
nice
to
be
handled,
having
only
one
active
that
way
that
whip
can
be
used
by
the
hosts
to
steer
all
the
traffic
towards
that
appliance,
dpu
right.
In
that
case
your
administrative.
The
happier
session
need
to
have
maybe
another
attribute
to
say
how
do
you
define
that?
B
B
E
B
E
B
B
So
expectation
here,
probably
for
next
time,
when
I
will
convert
it
to
psi,
it
will
be
clearer,
but
the
idea
is
that
you
take
object
of
eni
that
you
create
created
beforehand
when
you
are
creating
eni
when
you
assign,
like
all
of
the
mappings
like
to
from
which
mac
address
this
eni,
is
mapped.
What
are
the
qos
attributes
like
what
is
the
maximum
cps
for
that
eni,
etc?
C
Marion,
do
you
do
you
assume
that,
like
for
a
given
session,
that
any
of
the
enis
in
this
list
can
have
messages
coalesced
with
each
other,
you
know
as
part
of
like
a
bigger
coalesced
message
like
is.
That
is
that
the
reason
why,
like
is
that
sort
of
the
reason
why
you
should
specify
these
as
a
list
of
enis
and
not
call
this
api
like
one
at
a
time
on
each
individual
eni
like?
Is
there
an
implication
to
the
coalescing.
B
C
Yeah.
Okay,
so
I
I
get
what
you're
saying,
but
let
me
ask
the
question
differently:
if
the
controller
were
to
you
know,
combine
a
list
of
va
enis
and
make
a
single
psi
api
call
would
that
create
a
different
behavior
than
if
the
controller
decided
to
make
multiple
api
calls
with
one
eni
at
a
time,
even
though
they
all
have
the
same
attributes.
E
G
I
tend
to
agree
to
that
because
otherwise
you
can
find
yourself
in
the
tons
of
corner
cases
in
which
the
timer
are
not
the
same.
And
now
are
you
combining
them
or
not
like
what
is
the
benefit
of
creating
multiple
object
session
objects
with
the
same
parameters
again
and
again,
and
the
singularly
and
I
image.
C
I
I'm
just
I
I
I
don't
know
that
that's
what
I'm
asking
like
is
is.
This
is
like
I,
I'm
okay
with
saying.
If
you
do,
that,
that
will
result
in
a
different
behavior
that
will
result
in
like
no
coalescing
of
those
and
if
you
combine
them
all
into
one
api
call,
then,
though,
that
list
can
be
coalesced
together
I
mean
I'm
okay,
either
way,
I'm
just
asking
the
question
of
like:
what's
the
intent.
G
A
G
G
G
But
no,
I
believe
it
should
be
again
keep
if
I
don't
know
it's
it's
a
discussion
for
the
second
one.
I
believe
it's
an
option.
It's
like
some
user
will
prefer
availability
and
versus
like
the
ability,
like
it's
asynchronous.
So
you
some
connection
won't
be
100.
Think
in
that
case,
but
then
it's
it's
a
trade-off
right
and
the
other
option.
Is
you
always
sure
that
your
two
devices
are
in
sync
but
you're
paying
for
that,
because
if
one
of
them
is
dead,
you're
not
getting
any
new
connections.
B
D
E
D
New
ones,
yeah
new
ones,
right,
new
ones,
okay,
the
new
ones
and
the
events
closest
to
the
failover
right,
the
events
closest
to
the
failover
or
such
events
that
you're
saying
that
the
peer
is
dead
and
cannot
communicate.
Those
cannot
be
fully
guaranteed
and
that
we
can
define
that.
You
know
how
much
can
someone
please
go
on
me.
D
D
C
I
I
don't
think
that
that
statement
is
necessarily
true.
I
mean,
I
think,
that
if,
if
you
know,
if,
if
let's
say
the
link
between
the
two
peers
are
is
broken,
you
know
you
could
decide
to
not
forward,
for
example,
a
sin
packet
and
not
even
allow
like
a
new
connection
to
be
established
right
so
like
that,
like
I
don't
think
it's
like
true
that
you
say
like.
Oh,
like
there's,
always
this
uncertainty
around
the
failover,
where
some
connections
are
like
in
an
unknown
state.
G
Again,
it's
a
trade-off.
It's
it's
clear
that
you
can
guarantee
it's
up
to
you
to
the
user
to
decide
what
you
prefer,
100
guarantee
and
then
most
likely
other
thing.
Synchronization
is
a
synchronize
all
the
they're
always
synchronized
in
case
of
backup
your
peer
failure,
you're
not
getting
any
sin
versus
something
which
is
more
loose,
but
most
likely
will
give
you
more
performance.
C
I
agree
that
there
are
trade-offs
and-
and
I
also
think
that
that,
like
that,
the
vendors
should
have
flexibility
in
which
of
those
they
support
and
the
buyers
should
have
you
know
their
own
sets
of
requirements
as
to
what
they
require
right.
But
I
I
agree
with
you:
there
are
many
trade-offs
with
respect
to
the
aha
algorithms.
H
I
mean
it's:
it's
a
function
of
scale
and
the
deployment
scenarios.
Here
we
want
to
contend
with
right.
I
guess
to
make
these
trade-offs.
So
do
we
want
the
api
to
be?
You
know
flexible
enough
to
do
that
or
or
do
we
want
to
kind
of
hardwire
it
in
a
way
that
we
can
organically
improve
on
this?
As
time
goes,.
C
I
mean
I
put
out
a
proposal
that
that
that
tried
to
show
like
a
way
that
it
could
be
done
without
requiring
the
ap
like
these
setup
apis
to
to
have
knowledge
of
it.
You
know
where,
like
the
receiver
of
the
sync
messages
is
invariant
it.
It
just
has
a
very
fixed
behavior,
but
the
sender
of
the
sync
message
has
a
lot
of
flexibility
as
to
whether
it
wants
to
do
things
loosely
or
statelessly
or
statefully
so,
like.
G
G
C
It's
a
tradeoff,
but
but
what
if
there's
like
you
know
a
hundred
variations
of
loose,
you
know,
do
you
want
to
expose
all
100
variations
of
loose
as
something
that
that's
like
defined
in
dash
in
the
psi
api?
Or
do
you
want
those
hundred
variations
to
be
something
that's
like
configured
outside
of
psi.
C
C
B
C
To
50
different
trade-offs
they
can
make
and
they
make
sense
in
different
use
cases.
Do
we
have
to
define
all
of
those
and
agree
to
all
of
those
and
what
they
are
or
is
there
some
way
that
we
can
allow
for
that
flexibility
without
having
to
have
agreement
like?
I
think
that
there's
a
way
to
make
them
all
interoperate
without
having
to
agree
on
what
they
all
are.
G
C
You're
saying
there's
two
different
approaches.
I
think
that
there's
200
different
approaches
I
mean,
I
think
that,
like
there
are
all
different
forms
of
looseness,
for
example,
it's
not
just
like
like
strict
and
loose,
I
mean
it's
like
you
could
be
very
loose,
you
could
be
less
loose,
I
mean
there's
there's
like
what
what's
defined
as
loose
again,
I
don't.
I
understand
what
is.
G
C
C
You
know
there's
you
know,
there's
potentially
like
seven
state
updates
for
a
connection.
Maybe
you
know
maybe
maybe
more
like
there's
periodic
ones
too.
If
the
connection
is
long-lived
right,
maybe
maybe
in
some
cases
you
don't
even
sink
the
sin.
You
only
sink.
The
sin
act
like
there's
like
many
choices
you
can
make
about,
like
which
of
those
seven
events,
do
you
want
to
sink
and
which
ones
do
you
not
want
to
sink
like
in
terms
of
being
loose?
C
And
you
know
that
creates
a
lot
of
very
potentially
a
lot
of
variations,
also
like
when
you
talk
about
strict,
maybe
only
certain
events
you
want
to
be
strict
on,
but
other
events
you
want
to
be
loose
on
so
that,
like
it's
not
like,
like,
I
don't
see
it
as
it
is
that
there's
just
like
two
modes
and
you
can
support
both.
I
see
is
that
there's
many
many
many
trade-offs
that
can
be
made
in
in
and
they
could
make
sense
in
different
use
cases
and.
J
John
though
the
way
I
understand
you,
it
seems
like
you
know
that
what
you're
suggesting
is
that
certain
capabilities
that
you
want
to
introduce,
let's
say
at
the
receiver
side
right
and
then
at
the
receiver's
side,
thai
api
is
flexible
enough
to
really
you
know,
give
these
kind
of
requirements,
and
these
kind
of
I
should
say
you
know,
attributes
setting
of
the
attributes
to
say
that
hey
what
type
of
capabilities
you
are
setting
it
up
and
what
do
you?
What
would
you
like
receiver
to
do
right
now.
C
I
I
just
don't
feel
that,
first
of
all
that
it's
worth
us
defining
like
every
possible
trade-off,
because
there
are
so
many,
I
think
it
would
be
better
abstracted
into
some
some
kind
of
something
abstract.
And
then
you
know
give
a
lot
of
flexibility
to
each
vendor
to
decide.
You
know
not
just
the
implementation
but
like
which
trade-offs
they
want
to
support
and
and
do.
H
A
F
B
If
there
will
be
use
case
for
that,
those
two
can
be
active
and
then
sending
sync
messages
to
one
another.
If
there
is
a
clear
active
backup
for
that
eni,
one
of
the
sessions
will
be
configured
as
active
to
send
another
one
will
be
configured
as
backup
to
to
clearly
tell
the
dpu
to
accept
to
accept
flows
that
belong
to
that.
E
B
D
D
G
K
Hi
miriam,
if
I
mean
the
nature
of
active
or
backup,
is
based
on
the
traffic
right
I
mean
it's
not
so
much
of
the
controller
will
dictate
that.
Isn't
it
because
depends
on
the
load
balancing
across
the
dpu,
I
mean
if
you
receive
the
flow
and
you
processing
it.
You
are
in
the
active
role,
then
you
are
automatically
synced
to
your
peers.
B
B
K
No,
that's
the
reason
why
I'm
asking
if
the
role
of
active
backup
need
to
be
explicitly
set
by
the
controller,
because
this
is
the
basically
the
load
balancing
from
the
server
that
will
dictate
what
dpu
will
receive
the
new
flow
right.
And
then,
if
you
know
you
always
have
an
h
ap.
If
you
processing
the
new
flow,
then
you
would
have
to
sync
that
flow
to
your
peer.
K
B
B
So
if
we
consider
active
active,
it
means
that
each
peer
will
send
will
sink
all
the
flows
that
it
received
to
to
the
other
peers.
If
we
have
active
backup
active
means
that
it
will
again
sync
all
the
flows
to
the
peer,
but
backup
means
that
it
will,
if
it
will
receive
a
flow,
it
is
not
syncing
it
to
the
other
guy.
G
Yeah,
I
I
I
do
agree
that
we
need
to
define
better
why
we
need
a
backup
state
again,
it's
not
the
it's,
not
the.
Actually.
You
can
have
two,
the
two
box
to
be
active
and
still
act
like
an
active
backup
right.
If
you
are
not
doing
ecmp,
you
are
only
doing
shortest
path
right,
so
only
one
will
receive
all
the
sins
and
the.
K
G
Question
is
why
we
need
a
state
backup.
What
is
the,
why
is
what
is
different
in
the
state
backup?
Then
the
state
active,
if
your
answer
will
be
in
backup,
I'm
not
getting
any
new
connections.
Every
new
sim
is
not
folded,
because
I'm
a
backup-
and
I'm
not
supposed
to
get
sims
to
my
box.
That
and
I
I
will
understand
what
is
backup
and
then
we'll
figure
out
whether
it
is
needed
this
behavior,
in
which
you
are
rejecting
any
new
scene
and
you
are
receiving
only
old
connection,
like
a
established
already
established
connection.
E
K
Setting
it
does
have
an
implication
when
you
handle
the
failover,
because
if
you
go
with
the
strict
backup
definition
that
means
you're
not
supposed
to
process
anything
new
and
sync.
If
that's
the
definition,
then
you
have
to
wait
for
the
controller
to
come
down
and
change
it
right
and
your
failover
will
have
a
bigger
impact.
G
I
totally
agree.
I
I
agree
that
this
is.
This
is
a
clear
approach
in
which
a
backup
not
supposed
to
possess
any
new
sin
and
only
and
then
you're
waiting
for
the
controller,
either
to
change
your
all
or
to
bring
up
a
new
active
and
then
you
won't
get
any
sins
but
you're
not
following
any
new
sins
at
that
point,
because
it
means
that
most
likely,
you
don't
have
a
backup.