►
From YouTube: 2022-08-03 Monthly Multicast W3C Community Group Meeting
Description
2022-08-03 Monthly Multicast W3C Community Group Meeting
notes here: https://docs.google.com/document/d/1vop1sEctzAGANR6zG37_6QxnUuP-z3R6-LdWXIQ-yfk
meeting series here: : https://github.com/w3c/multicast-cg/tree/main/meetings
A
A
B
A
Yeah
yeah
right,
I
just
I,
I
haven't
written
anything
either,
yet
I
just
had
a
few
more
thoughts
about
it
as
well.
So
I
guess
my
my
main
update
is:
we
had
some
presentations
in
mbondian
quick.
We
did
some
made
some
progress
at
the
hackathon.
I
think
we've
got
some
some
updates
about
what
we're
doing
in
the
implementation
that
are
likely
to
come
from
that.
A
Luke
curley's
proposal
and
and
running
demo
for
warp
using
web
transport,
and
I
think
it
would
actually
mesh
really
well
with
our
our
current
quick
proposal
because
it
uses
the
same
kind
of
you
know.
Server
push
like
idea
for
server,
initiated
streams
that
we
would
be
relying
on
and
a
little
bit
about
just
the
sad
discussions
we've
had.
A
A
A
That,
like
it
is
a
nice
feature
that
the
any
web
transport
application
that
can
use
server
initiated
data
can
make
use
of
the
multicast
stuff
happening
underneath
it
without
having
to
be
specifically
aware
of
any
multicast
stuff
happening
underneath
it.
So
that's
like
that's
kind
of
valuable
in
some
way.
I
think
the
same
is
true
of
server
push,
so
even
request
based
things
that
you
know.
A
If
we
had
any
browsers
that
were
going
to
continue
supporting
server
push,
then
you
know
that
that
would
work
the
same
way
or
offline
application.
The
sort
of
fat
client
applications
right.
You
can
do
server
push
to
build
a
cache
in
the
in
the
receiver
and
then
sort
of
have
a
player
that
wants
to
make
requests
that
you
feed
out
of
your
server
push
cache
right.
B
I
wouldn't
be
shocked
if
the
same
basic
thing,
whether
it's
the
you
know
whether
it's
the
same
implementation
or
interface
or
not
reappears
at
some
point
once
enough
use
cases
that
actually
make
you
know
that
actually
make
good
use
of
it
appear.
It's
just
like
it's
one
of
those
things.
That
was
what
was
it
developed
in
like
2014
or
something
like
that,
and
it
just
never
really
got
used,
and
then
you
know-
and
it's
a
lot
of
code
to
maintain
for
something
that
isn't
used.
A
That's
what
they're
saying
I
don't
know
if
anybody
else
has
been
following
the
threads
where
they've
been
discussing,
that
in
I've
seen
it
in
chromium.
I
haven't.
I
haven't
seen
the
firefox
discussions
about
it,
but
the
basic
issue
is
that
there's
a
lot
of
complexity
there
and
a
most
people
aren't
using
it
and
b
the
people
that
are
using
it
are
not
getting
the
performance
benefits
that
they
that
they
were
expecting.
B
A
A
Right,
but
I
think
that
would
be
something
that,
at
this
point
having
you
know
been
rejected
on
grounds
of
complexity,
not
justifying
or
the
the
benefit
not
justifying
the
complexity,
then
the
the
onus
is
more
on
the
people
who
want
it
to
prove
that
it's
necessary
right.
So
yeah.
I
think
if
we
start
actually
shipping
content
with
multicast,
then
we
might
have
a
case
to
make
for
server
push
again
just
off
the
scalability
right
now
their
plan
is
basically
early
hints
instead,
which
is
the
server,
can
give
a
header
to
the.
I
think.
A
B
B
The
current
hacks
to
deal
with
this
are,
are,
you
know,
referencing
an
object
early
in
a
page
so
that,
as
the
renderer
is
you
know,
or
as
the
as
the
the
dom
code
is
parsing
it
it
can
be
like
oh
yeah,
I'm
going
to
want
to
request
this
right.
It's
horrifying
terrible,
hacks
javascript
is
another
one
used
to
do
this
stuff.
B
A
A
A
Likewise,
we
can
reuse,
I
think,
a
lot
of
the
packet
processing
code
once
we
have
once
we
find
the
right
place
to
plug
that
in,
and
you
know,
in
existing
quick
implementations
and,
like
I
said,
the
the
applications
that
are
built
on
it
have
a
much
lower
burden
in
order
to
make
use
of
those.
Oh,
we
lost
kevin
anyway,.
A
B
I
was
listening
remotely.
I
got
the
remote
pass,
I
wasn't
there,
but
I
was
able
to
attend
the
quick
and
m
bone
sessions
at
least,
and
that
was
one
of
the
things
I
was
going
to
bring
up
where
there
was
kind
of
a
question
about
why
quick
and
you,
I
believe
you
did
mention-
you
know
that
it's
with
a
goal
of
browser
support
but
kind
of,
as
you
just
described
it,
maybe
a
paragraph
somewhere
that
just
kind
of
answers
that
question
you
know
like.
B
A
A
B
Well,
so
I
mean
also,
I
think,
I'm
not
sure
whether
it
was
you
who
said
this
or
somebody
else
right,
but
the
but
there's
you
know,
multicast
itself
is
just
it's
just
an
address
scheme
right.
This
is
something
that
puts
guardrails
around
the
way
that
multicast
is
able
to
be
used
alongside
you
know
alongside
you
know,
web
traffic,
that
assumes
something
about
secure
transport.
So
it's
it's
good
in
that
sense
too,
that
it
says
these
are.
B
This
is
the
type
of
thing
we're
going
to
support
and
it
is
going
to
make
use
of
this
address
family
for
making
it
more
efficient
to
distribute
data,
but
otherwise
it's
going
to
work
the
same
general
way
that
the
web
does
and
carry
a
lot
of
the
properties
that
the
web
has
with
it.
So
I
think
that's
that
is
also
a
compelling
argument
for
some
people.
I
don't
think
we're
ever
gonna.
I
don't
think
we're
gonna
find
a
single
argument.
A
A
I
think
it
almost
is
the
same
thing
as
as
the
aggregated
acts
that
we've
got
already,
except
in
the
case
of
of
high
loss
or
something
also
the
way
norm.
Does
it
there's
like
a
delay
on
the
on
the
neck,
so
you
might
be
able
to
sort
of
reduce
the
number
of
servers
you
need
in
order
to
in
order
to
do
the
serving
of
the
of
the
multicast-based
quick
data,
if
you,
if
you
applied
nax
instead
of
x,
likewise,
there's
there's
like
possibilities
to
add
fec
frames.
A
I
think
there's
been
some
discussion
of
that
kind
of
thing.
In
quick
already,
you
know,
I
think,
the
early
versions
of
it
used
bad
fec
schemes,
and
so
they
concluded
it
was
a
bad
idea,
but
they
did
some.
Some
of
the
some
of
the
people
who
were
investigating
that
I
know
did
like
ian
sweat
in
particular,
did
go
talking
to
the
people
in
the
network
coding
research
group
about
like
real
fec
schemes
like
raptor,
that
that
can
provide
a
good
benefit.
A
A
You
know
all
this
is
relatively
straightforward
to
extend
in
quick
if
there
is
value
in
doing
so,
but
I
think
the
first
step
here
is
just
like
the
most
basic
version
of
a
multicast
transport
protocol
we
can
get,
which
is
what
I
tried
to
what
we
tried
to
put
up
in
the
draft.
That's
there
so
once
that's
operational,
then
you
know,
I
think
there
are
some
down
the
road
future
ideas
to
to
explore
further
if
we
want
to
improve
on
the
efficiencies.
A
But
I
don't
want
to
get
sidetracked
on
that,
but
that
was
some
of
the
kind
of
questions
we
got
in
mbo
d
and
I
I'm
not
sure
how
well
java
did
it.
I've
explained
it
gone
on
the
spot,
but
I
I
don't
think
it
needs
a
write-up
at
this
point.
Probably
we
can
just
ignore
it
until
until
later
and
then
add
it
in
as
a
as
a
you
know,
as
an
as
an
optimization
once
we've
got
some
deployment,
but
you
know
first
things.
A
A
Today,
let's
see
hackathon
kyle
did
a
great
job
got
some
good
stuff
done
max
and
I
well
max
had
a
bit
of
a
wall
on
finding
the
right
place
in
chromium
to
to
receive
the
udp
packets.
I
talked
to
victor
about
it
too
vasily
of
briefly.
He
said
that
well
he's
not
totally
sure
there's
a
bunch
of
places,
but
by
the
way,
he's
also
going
to
be
removing
the
e-pole
server
that
we've
been
using
and
and
putting
in
something
based
on
lib
event.
A
So
you
know
watch
for
that
at
some
point,
so
yeah,
the
the
hitting
the
moving
moving
target
of
having
an
extension
built
on
top
of
chromium,
is
kind
of
a
pain
and
rates
to
be
maybe
kind
of
more
of
a
pain
going
forward
max
had
a,
I
think,
a
good
idea
and
and
started,
I
believe
max.
Maybe
you
want
to
jump
in
here
on
looking
at
aio,
quick,
which
is
somewhat
easier
to
work
with.
I
think
you
know.
I
think,
we've
also
discussed
using
like.
C
A
A
A
D
D
A
I
don't
know
what
it
means
in
terms
of
how
we
would
get
video
out
of
it.
It
might
be
that
we
could
plug
it
into
an
external
video
player
or
use
some
of
the
video
rendering
features
that
are
in
python
somewhere
to
do
a
just.
You
know,
sort
of
a
fat
cloud
that
could
be
launched
from
a
browser
that
would
do
the
receive,
which
is
how
we're
gonna
have
to
deploy
it
anyway.
Until
we
get
actual
some
interest
in
using
browsers
so
yeah,
I
think
there's
a
high
possibility.
A
B
A
So
on
the
server
side,
it
could
be
a
reasonable
concept,
I
think,
but
to
use
it
in
production.
But
you
know
in
terms
of
receiver,
I'm
not
I'm
not
sure,
not
sure
I
mean
I
know,
there's
they
keep
talking
about
in
the
quick
presentations.
There's
like
19
different
implementations
of
quick
out
there
right.
Some
of
them
are
server.
Only
some
of
them
are
client
only,
but
regardless
there's
there's
a
whole
interop
table
where
they
tested
them
all
against
each
other
and
stuff
right.
A
A
A
A
B
Yeah
standard,
I
I
so
I
mean
having
gone
down
as
I
mentioned,
having
gone
down
the
wrong
road
on
on
g
quick
stuff
on
a
few
occasions
and
then
had
to
throw
those
changes
away,
it's
a
little
annoying.
It
sounds
like
they
also
want.
I
mean,
according
to
my
my
conversation
with
ian,
they
want
to
tear
all
of
the
g
code
out
as
well.
So
at
some
point
it
will
disappear
and
hopefully
be
a
lot
simpler.
I
mean
honestly,
I
kind
of
like
the
quiche
code.
It's
pretty
good!
B
A
A
Oh
my,
my
results
on
the
hackathon
I
did
by
the
end
of
the
week,
get
it
working
where
I
can
like
push
a
file
and
have
it
show
up
in
the
browser
in
their
in
their
web
transport
implementation.
So
I
thought
that
part
was
pretty
neat
if
we
do
ever
get
back
to
the
chromium
stuff.
Maybe
we'll
get
back
to
that
push
api,
but
I
imagine
in
the
meantime,
we'll
probably
port
it
over
to
interoperate
with
the
with
the
aio
quick
server.
A
A
A
People's
heads
that
that
making
use
of
broadcast
links
like
in
g,
pawn
and
cable
end
user
loops
you
know
is-
is
a
thing
that
you
can't
do
with
just
a
different
caching
strategy
and
that
this
is
a
real,
a
real
problem
for
network
delivery.
It's
not
just
about
you,
know,
saving
1001
on
your
servers
for
the
live
events,
but
but
also
there's
a
delivery
problem
that
can't
be
solved
in
really
any
other
known
way.
Besides
making
use
of
those
broadcast
links.
A
So
I'm
I'm
hopeful
that
that
will
lead
to
you
know:
reduced
opposition
further
reduced
opposition
and
quick.
It
may
already
have
led
to
reduced
opposition
in
the
in
the
meeting
we
were
in
because
that
was
before
the
meeting,
and
then
nobody
really
spoke
up
against
it,
except
in
terms
of
like
well
should
we
should
we
be
doing
this
in
a
different
way
instead
of
trying
to
inject
it
into
quick.
A
I
think
there
were
separately
some
interesting
developments
on
multicast
in
general,
but
with
regard
to
the
quick
implementation
stuff,
I
don't
know
if
maxie
wanted
to
say
anything
about
we
with
some
feedback
from
one
of
the
network
operators
that
had
been
using
multicast
for
for
tv
delivery
and
tried
to
add
it
to
the
home
networks.
We
found
that
apparently
there's
a
problem
in
the
igmp3
implementations
that
are
widely
deployed
where
which
I've
seen
before
in
lab.
A
But
I
didn't
realize
it
was
such
a
problem
for
their
user
experience,
but
they
when
they
see
an
igmp
v1
membership
report,
then
they'll
stop
the
sending
of
igmp
v3
reports
and
queries
and
such
and
so
when
you're,
using
ssm
to
join
the
tv
flows
from
like
a
wi-fi
connected
device.
That's
that's
sharing
your
network
in
the
home.
A
A
I
think
we're
probably
I'm
thinking
gonna
make
a
case
for
changing
that
made
to
a
should,
not
and
perhaps
submitting
a
patch
to
linux.
If
we
can
find
anybody
willing
to
do
that,
linux
and
maybe
freebsd,
because
that's
what
rdkb
uses
so
that'll
take
a
few
years
to
roll
out.
But
I
think
it's
the
right
thing
to
do
to
try
to
fix,
try
to
fix
that
and
make
multicast
in
general,
more
reliable
in
the
in
the
home
network
environments.
A
Yeah,
so
that
was
another
interesting
point
I
learned
and
thanks
mac
max
for
pointing
out
its
relevance
to
the
to
the
igmp
discussion
like
my
first
take
was:
oh
well,
we'll
never
get
that
rolled
out
in
time
for
me
to
care
about.
You
know
this.
This
year's
deployment
prospects,
but
while
true
it
doesn't
mean
we
shouldn't
do
it
and
it's
a
it's
a
timely
moment
to
get
in
there
and
and
get
the
spec
changed.
I
think
and
use
that
to
justify
changing
the
implementations
as
well.
A
D
They
said
that
would
already
like,
if
that
is
included,
would
already
break
a
bunch
of
implementations
and
make
them
not
compliant
to
the
standard
anymore.
So
now
also
sure
is
changing
a
mate
or
should
not
would
also
make
more
implementations,
not
compliant.
So
I'm
I
mean
it's
the
right
thing
to
do,
but
I'm
not
sure
how
hard
they're
gonna
fight
us
on
that
right
so
but
yeah
we
should
definitely
do
it
anyway.
A
A
C
Well,
I
appreciate
the
opportunity
and
the
side
conversations
were
definitely
very
interesting,
which
yeah
a
lot
of
rethought
about
how
I
could
make
a
minute.
It
could
have
been
a
stronger
case
to
some
of
those
folks
who
are
pushing
back
on
you,
but
I
think
we'll
see
some
pretty
compelling
business
drivers.
You
know,
after.
A
C
A
Yeah,
okay,
I'm
not
a
big
node
fan
really,
but
maybe
if,
if
you
wanna,
certainly
if
you
wanna
be
contributing
and
you
wanna
be
working
in
node,
that
would
that
would
contribute
to
the
discussion.
But
I
like
python
better
for
myself-
I
don't
know,
but
we
can
all
vote
if
you
anyone
who
comes
to
the
to
the
dev
team
meetings
that
we've
been
having
weekly
is
certainly
welcome
to
make
a
case
for
for
using
a
different
platform
while
we're
considering
switching
yeah.
C
C
A
So
yeah,
I
definitely
want
to
push
for
it.
The
other
thing
I'd
like
to
do,
perhaps
that
can
be
rolled
out
more
quickly,
is
to
make
the
case
that
the
linux
implementation
that's
out.
There
can
be
tuned
from
its
current
defaults
and
still
remain
inspect
because
there
it
you
know
what
it
says
now
is
that
there's
a
may
suppress.
A
I
think
the
general
impression
among
operators
is
that
well,
this
implementation
is
according
to
spec.
We
don't
want
to
touch
it,
but
I
think
that
if
we
can
make
the
case
that
there
are
that
there
are
settings
that
you
can
that
you
can
set
that
will
solve
this
kind
of
a
problem
where
you
know.
Oh
we're,
observing
old
devices
that
are
changing
that
are
you
know,
disabling
our
our
use
of
this.
A
A
A
A
Yeah,
that
seems
absolutely
worthwhile
to
me
and
one
of
the
reasons
that
I'm
glad
I
made
it
to
the
in
person
atf,
because
I'm
not
sure
when
I
had
that
conversation
otherwise
right,
so
nobody
has
anything
else
if
they
do
please
interrupt,
but
the
only
other
thing.
So
I
was
going
to
talk
about
where
I
want
to
go
what
I
want
to
do
with
tpack.
My
current
plan
is
to
try
to
justify
to
my
management
chain
that
I
should
in
fact
go.
A
A
Discuss
why
and
to
see
if
we
can
pin
that
down
and
and
fix
it
in
the
security
considerations,
doc,
I
think
so.
That's
you
know
that,
and
I
want
to
have
a
better
grasp
of
what
tpack
is
like
for
next
year,
because
maybe
I'll
have
more
presentations
or
a
group
meeting
that
we
can
get
more
people
in
next
year.
I
do
not
think
I'm
going
to
run
a
meeting
for
this
community
group
at
tpac
unless
it's
it's
remote
or
with
whoever
happens
to
be
there.
E
A
A
E
A
A
Ask
about
the
tpac,
2022,
breakout
session,
scheduling,
process
and
deadlines
and
what
I
should
watch
for
that
yeah.
Thank
you.
Thank
you.
For
that
suggestion.
That's
that's
very
helpful
so
that
that
breakout
session
is
sort
of
an
open
invite.
Is
that
the
idea
and
then
it'll
be
on
the
list
of
here's
all
the
breakout
sessions
and
people
who
are
there
will
just
sort
of
wander
in.
E
That's
exactly
it
so
there'll
be
there'll,
be
like
multiple
sessions
running
in
parallel
and
then
it's
whichever
topic
catches.
People's
interest
is
the
one
that
they
go
to
so
so,
if
you're
going
to
propose
a
session,
then
it's
worthwhile
talking
with
people
ahead
of
time,
so
that
you
know
you've
invited
some
of
the
right
people
that
you've
learned
around
the
table.
E
A
A
A
A
Okay,
I
will,
I
will
start
trying
to
make
that
happen
and
see
where
I
can
get.
It
is
possible
that
the
answer
will
be
no
and
that
I
just
won't
go,
but
but
I
think
it
does
sound
valuable
to
me,
and
hopefully
I
can
make
the
case
to
my
management.
That
is
valuable
for
me
to
go
so
I'll.
Try
to
do
that.
Thank
you
for
the
feedback
on
that
very
much
appreciated
any
other
comments
or
questions.
I
think
we
only
have
three
minutes
left
and.