►
From YouTube: DASH HA Working Group 20220607 (June 7, 2022)
Description
June 7, 2022
B
Yeah
and
and
not
to
get
too
deep
into
the
weeds,
but
if
we're
tweaking
it
would
it
just
be
a
matter
of
tweaking
the
apis
per
implementation
or
consumer
of
you
know
the
let's
just
call
it
dash.
Is
that
fairly
easy
to
do
or
is
that
how
it
would
be
done.
C
I
I
think,
actually
you
probably
do
this
through
modes
like
each
vendor
can
have
different
modes
of
operation,
and
we
can.
We
can
optimize
those
modes
for
the
different
use
cases.
For
example.
That's
one
way
to
do
it,
but
there
could
be
other
ways
to
do
it,
but
we
could
literally
program
with
mode
we
watch
and
and
that
could
change
based
on
the
actual
buyer
of
the
product
like
like,
like
he
said,
if
you
were
doing
say:
200
000
connections
per
second,
you
said:
look
I
wanted
to
choose
the
simplest
mode
possible.
C
I
just
want
to
send
all
my
all
my
connection
state
packets
over
the
other
side
and
back
yeah,
I'm
okay
with
that,
because
that's
only
200
000
mac
and
it's
simple
and
and
it's
robust
and
that's
what
I
want
and
that
could
be
mode
one
and
that
that
would
work
for
it
like
if
you
were
limited
to
200
000
connections
per
second.
That
would
work
just
fine.
C
And
then
then,
another
mode
of
operation
would
be
like.
I
I
have
five
million
connections
per
second,
I
need
something
more
efficient
and
I
need
to
go
into
a
different
mode,
it's
more
complex
and
it
might
even
compromise
something
like
amazing,
lose
a
few
connections,
but
I'm
like
now,
I'm
operating
at
five
million
connections
per
second,
it's
a
totally
different
paradigm.
Now
and.
B
B
C
Always
thought
they'll
be
mode,
and
I
and
I
don't
think,
there's
a
right
answer,
like
literally
200
000
connections
per
second,
it's
okay
for
your
application.
Then
then
it's
okay
and
and
you
might
be
able
to
go
with
a
simpler,
more
robust,
smaller
example.
B
D
I
think
it
would
be
preferable
to
understand
that,
but
if
it's
not
the
right
forum,
I
think
we
can
talk
to
today
to
the
to
the
users
directly,
because
it
all
requires
work
and
prioritization.
We
cannot
have,
as
I'm
sure
other
vendors
as
well,
cannot
have
all
of
the
variations
of
implementations
available
at
day
one.
C
Our
system
yeah
from
a
microsoft
point
of
view,
we
will
have
four
to
five
million
connections
per
second,
it's
not
double
back
right
on
a
gpu,
so
you
have
to
design
for
that
for
us
other,
simpler
modes
that
could
be
for
somebody
else,
but
at
least
you
know
that
we're
not
looking
for
that.
Microsoft
is
looking
for
millions,
it's
four
to
five
million
per
every
200
kicks.
If
you
have
400
gigs,
then
you
double
the
number.
So
that's
why
it's
so
important
that
you
understand
that,
but
this
has
to
be
designed
for
that
scale.
C
B
So
this
could
be
our
first
use
case
and
the
first
set
of
coding
to
code
for
this
particular
one.
A
A
defined
packet
format
for
state
synchronization
and
a
way
to
achieve
interoperability,
while
still
allowing
for
each
vendor
and
and
the
community
to
define
their
have
algorithmic
flexibility
in
how
aha
should
work
and
because
I
think
that
there
are
a
lot
of
trade-offs.
I
think
you
know
some.
A
Some
vendors
have
different
constraints,
different
hardware
constraints
than
other
vendors,
and
I
think
that
like
without
that
flexibility,
I
think
that
we
could
kind
of
degrade
into
sort
of
a
situation
where
it's
like
a
least
common
denominator,
or
it's
a
like
impossible
for
some
vendors
to
do
some
things
that
that
other
vendor.
C
B
Yeah,
okay!
Well,
we
have,
you
know
just
a
few
minutes
left.
So
in
the
short
term,
how
can
we
move
forward
to
the
next
week's
discussion.
D
D
It
overlaps
with
what
michael
was
saying
it
has
so,
first
of
all
like
we
need
an
ability
to
establish
a
peering
which
is
defined
by
by
the
session
itself,
and
we
would
like
to
come
up
with
a
set
of
attributes
to
that
session.
That's
number
one
number
two
is
we
would
like
to
know
what
is
the
synchronization
state
right
now,
so
we
would
be
able
to
query
it
directly
from
the
session
or
even
more,
preferably
get
the
notifications
and
also
we.
D
We
will
probably
need
some
telemetry
as
well
the
one
that
is
related
to
state
synchronization
itself,
which
may
help
us
make
a
decision
when.
D
Losing
a
state
for
one
reason
or
another
due
to
issues
in
the
network,
so
these
are
three
aspects
that
I
have
outlined
right
now.
Also
michael
was
mentioning
that
we
would
need
to.
We
will
need
a
way
to
have
a
to
have
a
knob
to
potentially
delay
advertisement
of
the
of
of
this
device
via
bgp.
D
D
I
will
send
it
over
the
email
and
I
would
like
to
get
some
feedback
and
talk
about
it
next
time,
if
possible,
and
also
if
we
agree
on
that,
I
would
convert
it
to
to
say
apis
and
come
up
with
the
proposal
to
say
community.
D
So
that's
what
I'd
like
to
do
for
for
the
api
for
aha.
B
That
sounds
like
a
good
plan
for
next
week.
Everyone
else
on
board
with
that.
C
B
Yep
yep
great
guys,
unless
you
know,
unless
anyone
has
something
else
to
discuss.
You
know,
I
really
appreciate
the
the
thought
that
went
into
this
last
round
of
conversation.
It
was
huge,
john,
thank
you
very
much
and
I'll
talk
to
the
rest
of
you
later
and
have
a
good
day,
bye.
D
B
I'll
have
the
recording
posted
on
the
youtube
channel
as
well.
Bye-Bye.