►
From YouTube: Multicast Community Group, W3C TPAC 2021-10-27
A
B
A
Okay,
so
we're
recording.
I
also
wanted
to
mention
the
w3c
policies
that
are
in
effect
here
or
under
the
community
contributor
license
agreement.
If
you
have
not
agreed
to
this,
please
do
not
make
substantive
contributions
to
the
specs.
At
least
this
meeting
operates
under
the
code
of
ethics,
be
nice
to
people.
Please.
A
A
A
Anyone
wants
to
add
something
now's
the
time
or
change
something
I
was
gonna
take
15
minutes
to
walk
through
sort
of
where
we
are,
what
we're
doing,
why
we're
doing
it
and
then
just
go
into
our
a
review
of
what
I
think
the
next
steps
are
for
this
work
and
possibly,
if
anybody's
available
schedule
some
working
sessions
for
the
upcoming
month,
where
we
hope
to
do
some
things
and
then
do
a
wrap
up
recap.
Any
action
items
we
have.
Did
anybody
want
to
throw
anything
else
in
that
mix.
A
A
So
this
is
kind
of
normal
and
not
totally
unreasonable,
but
on
a
heavy
traffic
day,
then
it
gets
really
kind
of
bad.
This
is
like
nine
hours
long.
The
way
I
think
of
this
is
about
like
half
the
good
put
for
about
nine
hours,
and
this
was
a
day
when
there
were,
like
you
know
some
some
big
video
game
downloads
that
had
been
released
and,
and
there
might
have
been.
A
A
A
But
you
know
we
do
get
complaints
from
networks
about
this
kind
of
thing
and
the
reason
we're
getting
complaints
from
networks
is
because
their
users
are
seeing
this
kind
of
like
much
worse
than
usual
network
performance,
they're,
calling
them
up
saying.
What's
the
problem
here
and
the
and
the
networks
are
kind
of
stuck
in
it
in
a
difficult
place,
because
there's
so
much
traffic
hitting
them?
A
The
key
problem
that
multicast
solves
that
we
can't
solve
any
other
way
is,
is
the
congestion
on
these
on
the
access
networks
into
the
homes,
so
these
are
typically
over
subscribed
somewhat
and
you
can
put
caches
very
deep
into
networks,
but
you
can't
put
them
inside
here.
There's
no
ip
addressability
on
like
these
cable
networks
in
the
in
the
slides.
It's
not
just
cable
networks.
It's
also
fiber
has
a
similar
kind
of
thing
and
different
kinds
of
access
types
5g.
A
Also
you
can
leverage
these
kinds
of
things
4g
it's
a
little
bit
trickier,
but
but
there's
some
ways
I
put
in
a
list
of
sort
of.
I
I
think
I
told
it
to
skip
this
one.
But
if
you
go
back
and
look
at
the
slides,
you
can
see
a
rough
estimate
of
kind
of
how
much
offload
at
different
points
of
an
access
network
for
different
kinds
of
access.
Topology
is
is
achievable,
but
basically,
when
you've
got
like
know,
3000
customers
on
a
cable,
loop
and
they're.
A
A
When
these
people
try
to
get
the
traffic,
then
it's
possible
to
to
share
much
of
it.
It's
not
always
possible
to
share
all
of
it.
There
are
many
things
that
cannot
be
shared
effectively.
A
lot
of
the
video
on
demand.
That's
just
not
sufficiently
popular
but
anything
live,
is
a
great
candidate
and
anything.
That's
that's
a
large
file
that
it's
basically
going
to
download
the
whole
thing
and
wait
till
the
end.
It
turns
out
those
can
be
shared
as
well.
A
The
other
effects
were
you
know.
Trying
to
to
solve
here
is
really
the
the
climate
impact
it
internet
turns
out
to
take
a
lot
of
power
and
the
power
that
it
takes.
There's.
This
is
a
link
to
some
to
a
bbc
article
summarizing
a
research
project
that
ran
that
concluded
that
the
internet
consumes
3.7
percent
of
global
carbon
footprint
from
the
power
that
it
eats
and
a
lot
of
it
comes
from
watching
video.
A
Some
of
it
comes
from
downloaded
video
games.
There
are
some
other
contributors
too,
that
probably
can't
be
addressed
by
multicast,
but
we,
you
know
we're
looking
to
get
to
something
on
the
order
of
one
percent
of
of
the
the
global
carbon
footprint.
Ultimately,
if
we
can
get
wide
adoption
of
this
kind
of
technology
and
wide
usage
of
this
kind
of
technology,
I
think
that
this
is
a
much
you
know
when
you
compare
this
same
article
did
talk
about
the
about
the
proof
of
work.
Bitcoin
stuff.
A
You
know
these
these
usages
change,
but
at
the
time
it
was
something
like
I
think
it
had
22
million
tons,
and
so
we
think
that,
like
out
of
this
video,
something
like
20
day-to-day
and
50
on
the
big
days
is
probably
addressable
in
some
in
some
form.
If
we
can
get
wider
use
of
multicast,
you
know
that's
the
sort
of
long
view,
but
that's
that's
where
we're
headed.
Why?
One
of
the
big
reasons
this
is
important,
the
other
is
the
costs
to
end
users.
A
You
know
this
is
gonna
turn
into
lower
prices
through
the
network
because
it
reduces
the
infrastructure
required
to
get
the
same
level
of
service,
particularly
for
for
those.
I
mean
really
only
for
those
shared
events,
things
that
a
lot
of
people
are
doing
at
the
same
time,
but
that
does
drive
a
lot
of
a
lot
of
the
the
higher
end
of
traffic.
A
D
Oops
sorry
about
that,
I
was
talking
away
jake
a
question
here
on
the
climate
change.
I
you
know
we
had.
We
had
a
separate
breakup
session
on
sustainability
and
there
seemed
to
be
some
interest
and
I
think
I
believe
you
are
on
that
on
that
call
right-
and
I
think
so,
yeah
yeah
and
I
think,
there's
some
kind
of
a
movement
or
interest
to
include
sustainability
along
side
where
security
and
privacy
is
horizontal
review.
D
I
think
it
is
it's
really
good
that
that
that
you're-
including
this
two
comments
here-
one
one
percent
from
watching
videos
right
and
then
the
video
game.
I
think
you
know
if
you
want
to
just
make-
I
I
think
we
should
try
and
make
that
consistent.
If
you're
going
to
use
percentage
of
the
of
the
total
carbon
footprint
for
watching
videos,
perhaps
we
can
try
to
give
an
estimate
in
terms
of
the
same
measure
for
video
games
as
well.
A
D
Yeah
yeah,
just
just
just
a
comment
here:
yeah
and
then
the
the
second
comment
I
have
is
you
know
if
it'll
be
good
to
educate
the
stakeholders
in
terms
of
how
much
impact
multicast
would
have
right,
because
you
you,
you
outlined
the
problem
here
on
global
warming,
climate
impact
and
then
by
by
being
able
to
articulating
how
much
multicast,
what
kind
of
impact
multicast
potentially
can
have
on
alleviating
that.
That
would
be.
That
would
really
help.
A
So
this
is,
this
is
actually
where
we
started,
because
the
first
question
before
we
came
to
w3c-
and
you
know
we
did-
we
did
some
work
in
ietf
first
and
then
we
went
to
isps
and
we're
like
if
we
were
serving
traffic
this
way,
would
you
actually
use
it
by
the
way
here's
a
busy
day
for
your
network?
We?
This
is
one
of
the
one
of
the
many
isps
that
we
talked
to.
We
picked
a
day
and
kind
of
analyzed
the
traffic
and
said
on
this
day.
A
Here
is
the
traffic
that
you
actually
saw
as
the
top
end
of
this,
and
here
is
the
traffic
that
you
could
have
had
if
you'd
been
able
to
offload
this
with
multicast-
and
you
know,
is
this
interesting
to
you
and
you
know
some
of
them
there
we
had
so
I've
talked
to
something
north
of
30
different
isps
and
there's
been
a
range
of
of
responses
to
like.
Would
they
be
interested
in
this
technology?
A
A
So
you
know
we
we
charge
by
the
amount
of
traffic
that
we
serve
so,
okay,
I
I
guess
we're
not
going
to
move
those
guys,
but
almost
all
the
isps
were
were
more
positive
in
the
in
the
frame
of
more
like
if
we
could
use
a
significant
amount
of
traffic.
That
would
be
great.
You
know
some
of
them
had
kind
of
logistical
difficulties
on
what
it
would
take
for
them
to
roll
out
the
capability,
but
and
that
sort
of
determined
you
know
how
positive
we
think
they
are.
A
We
ran
lab
trials
with
five
of
them,
of
which
four
said.
Yes,
this
is
practical.
We
should
you
know
if
you
can
get
traffic
in
running
here
and
if
other
people
are
are
doing
this,
then
we
would
also
invest
here
several
of
them
most
of
them
didn't.
You
know
put
time
into
running
lab
trials
with
our
technology,
but
but
we're
positive
in
the
sense
of
like
hey
if
you
can
get
traffic
working.
That
sounds
great.
A
We've
seen
people
try
multicast
before
there
were
different
ranges
of
skepticism,
you
know,
and
and
so
some
of
them
were
more
like
and
the
the
the
proof
of
concept
traffic
that
we
had
running
was
helpful
in
this
regard,
but
was
not
sufficiently
convincing
to
some
of
them
to
say
that.
Well,
we
definitely
invest
you
know
it's
not
like.
I
have
timelines
for
any
of
them
exactly,
but
we
do
have
a
sort
of
hey
if
people
are
doing
this
we'd
love
to
be
doing
this
too.
A
If
you
can
help
us
offload
some
of
our
peak
day
traffic,
that's
a
big
problem
for
us.
They
were
not
so
interested
in
the
day-to-day
offload,
but
I
do
think
that's
where
a
lot
of
the
power
savings
comes
from,
but
they
were
interested
in
like
reducing
their
call
load
from
from
complaints
on
the
peak
days
when
when
it
starts
hammering
their
network
never-
and
it
was
also
important
to
them
that
this
is
not
a
you
know.
Akamai
black
box
solution,
but
rather
a
repeatable
thing
that
anybody
can
can
use.
A
So
that's
that's
why
we
were
going
through
the
kind
of
standards
process
to
address
this
kind
of
stuff.
This
is
a
similar
analysis
for
a
video
a
day.
There
was
a
sporting
event
going
on
during
this
time
and
this
is
kind
of
what
the
traffic
actually
looked
like,
but
this
is
what
it
could
have
looked
like.
Had
we
been
able
to
run
the
traffic
with
with
multicast
for
that
sporting
event?
A
A
There's
various
examples
of
this
kind
of
thing,
so
one
of
the
work
one
of
the
pieces
of
work
we've
done
so
far
in
the
group
chris
helped
with
this
it
was
kind
of
fun-
was
writing
up
the
getting
started
primer.
It's
there
in
our
in
our
github
page.
I'd
encourage
people
who
are
interested
to
kind
of
give
it
a
try
and-
and
you
know,
get
some
traffic
with
the
api.
A
We're
running
and
I'd
be
happy
to
get
together
with
people
and
try
to
get
them
up
if
they're
interested
in
sort
of
getting
started,
experimenting
and
contributing
to
this,
where
we
are
now
is
especially
kind
of
on
the
ietf
side,
is
we're
trying
to
get
some
engagement
on
on
our
security
model?
That's
some
of
the
feedback
we
got
from
the
web,
particularly
from
the
chromium
net
devs.
A
A
That
was,
you
know
a
side
standalone
thing,
but
we'll
need
to
do
something:
that's
integrated
with
the
browser
to
do
authentication
of
the
packets
before
processing
them
and
we'll
need
to
do
some
kind
of
a
quick
integration,
probably
for
the
web
transport
work
and
then
that'll
need
to
be
turned
into
into
a
spec.
That's
proposed,
but
that's
kind
of
the
the
next
steps
that
we're
looking
at
there's
some.
The
way
back
pressure
is
going
to
work
and
that
kind
of
a
setup
is
a
little
bit
different
because
the
sender
doesn't
slow
down.
A
What
you
need
to
do
is
like
stop
listening
to
a
channel
and
make
that
decision
in
a
place
where
the
the
javascript
is
not
making
the
decision,
but
rather
something
underneath
the
browser
is
doing
it
and
that
needs
to
be
specced
out,
which
we
have
a
an
adopted
spec
in
the
mbondi
group
about
how
we
propose
to
do
that.
There
are
other
options
here
for
communicating
the
information
involved.
A
It
might
be
that
that
when
we're
doing
it
in
a
web
transport
context,
we
can
extend
this
to
to
send
the
same
kind
of
information
over
over
a
quick
frame.
But
the
you
know
the
bones
are
here
of
what
we
propose
to
do,
but
there's
a
lot
of
flushing
it
out
to
still
be
done
on
the
technical
side
and
then
there's
you
know
the
signaling
for
the
apis
that
we
want
to
integrate
to
in
the
browser
are
really
up
in
the
air.
A
At
this
point,
the
the
quick
http
mcas
draft
here
from
bbc
is
a
really
good
step
in
this
direction.
It's
I
think
it's
the
the
right
place
to
start
experimenting,
but
there's
you
know,
support
for
datagrams,
and
this
is
kind
of
in
the
in
the
current
web
transport
or
the
the
current
multicast
community
group
charter
is
to
go
into
web
transport
first
with
the
intent
of
getting
datagram
support
so
that
we
can
plug
in
existing
multicast.
A
You
know
quick,
datagram
framing
and
sends
it
over
multicast
channel
and
then
successfully
unpacks
it
as
a
datagram
at
the
receiver
side,
and-
and
this
will
give
you
what
we've
got
running
today
in
our
api,
I
should
have
put
a
link
to
the
demo,
video
that
I
put
up.
I
sent
it
out
to
the
to
the
list,
but
I
think
I
should
send
it
out
to
the
to
the
current
participants.
We
have.
D
A
This
is,
I
mean
the
the
thread
on
that
multicast
security,
the
respondent
so
far,
has
been
eric
or
scarlett.
He
is
he's
with
mozilla,
so
I
think
we're
starting
to
see
you
know
some
level
of
review
from
there.
His
initial
reaction
as
usual
was
like
go
away,
but
but
I
have
responded
in
a
way
that
I
think
is
I'm
hoping
that
I'll
see
some
support
from
other
parties
to
make
the
case
that
this
is
worth
looking
at.
What
about.
A
As
you
know,
we
don't
have
a
production
implementation
of
this
yet,
and
so
they
are
trying
to
find
a
good
way
to
do
that
delivery,
because
thursday
night
football
you
know,
has
a
lot
of
viewers
for
for
what
can
be
supported.
This
would
be
a
high
end
of
what
the
internet
can
support,
even
if
you're
not
running
it
at
very
high
quality,
so
this
greatly
exceeds.
A
They
said
that
that
I
was
free
to
to
disclose
that
we'd
been
talking
and
that
they
are
supportive
of
the
of
the
standards
work
that
we're
doing.
It's
not
clear
yet
whether
they'll
be
able
to
make
use
of
it
in
the
time
frame
that
they
need
for
the
thursday
night,
football
delivery,
at
least
at
the
beginning,
and
I
think
they're
scrambling
to
see
what
they
you
know.
A
A
Likewise,
I've
had
just
some
private
conversations
with
various
people
at
google.
Not
everyone
at
google
is
is
convinced,
but
some
of
the
people
who
looked
at
the
at
the
youtube
live
traffic
and
sort
of
thought
about
how
it
would
work
if
something
got
too
popular
said
that
they
are
supportive
of
working
this
direction,
although
I
I
you
know,
they
haven't
really
engaged
yet
to
the
best
of
my
knowledge.
So
I'm
I'm
hoping
that
that
we
can
drive
their
interest,
but
I
have
not
yet
successfully
done
that.
A
A
You
know
there
was,
I
don't
know
if
you
know
any
history
about
it,
but
it's
been
around
since
I
think
before
2000,
when
it
was
originally
proposed
and
there's
a
vast
amount
of
work
that
went
into
trying
to
make
any
source
multicast
work
that
really
didn't
pan
out
and
they
had
to
change
to
store
specific
multicast
recently
published
was.
I
think
it
was
maybe
rfc
8815
that
deprecated
any
source
multicast
for
inner
domain
usage,
where
you're
talking
between
different
networks.
A
It's
you
know
it's,
it's
kind
of
a
deep
dive
to
really
go
down
that
rabbit
hole,
but
any
source
multicast
was
a
big
false
start
for
multicast
and
and
gave
it
kind
of
a
bad
taste
for
a
lot
of
people
who
used
it.
But
on
the
other
side
it
means
that
that
in
the
operating
systems
it
is
already
widely
deployed.
There's
like
igmp,
you
know
on
any
end
user
device
that
you
try
to
use
is
already
there
and
already
runs
and
already
works,
and
people
do
use
it
for
local
network
discovery.
A
There
are
many
isps
that
are
using
it
to
deliver
tv
services
today
and
they
have
sort
of
got
it
running
through
their
whole
chain
for
the
one,
especially
for
the
ones
that
wanted
to
make
it
work
for
end
user
devices
like
their
their
mobile
devices
that
are
connected
to
wi-fi
they've
they've
got
it
running
all
the
way
through
the
delivery
path.
Yeah.
D
I
I
think
the-
and
you
know
we
we've
had
this
in
our
discussion
before
jk.
I
think
the
first
task
for
the
community
group
is
to
articulate
pain,
points
and
business
proposition
to
the
key
stakeholder.
I
think
you,
you
know
you
have
some
potential
stakeholders
that
that
are
natural,
the
the
the
the
effort
needs
to
be
engaging
them
to
to
convince
them
right.
Google,
google,
for
example,
google
is
not
a
single
company
right;
it
is
a
single
single
company
that
has
multiple
groups
all
doing
their
own
thing
right.
A
Yeah,
so
there
is
a
bit
of
a
chicken
and
egg
problem,
because
you
do
also
need
isps
to
be
interested
in
delivering
it.
That's
why
we
started
there
and,
to
some
extent
like
what
I
would
like
to
get
to
happen,
is
to
have
the
technical
capability.
That's
actually
executable,
and
this
raises
the
the
interest
level
in
the
past.
It's
you
know
when
you
just
give
the
slideware
demonstrations,
then
a
lot
of
people
who
might
otherwise
be
interested.
Just
you
know.
D
A
A
You
know
I
I
would
love
to
get
more,
but
from
the
isp
side
they're
going
to
be
less
interested
in
the
browser
work,
they
just
want
it
to
be
there,
so
I
don't
want
to
be
blocked
on
them
like
participating
in
making
the
browser
go,
which
is
really
the
charter
for
this
group.
You
know,
I
I,
I
guess
I'd
love
to
see
I'd
love
to
to.
A
Have
a
big
picture
plan
for
how
this
all
comes
together
that
really
works.
Well,
the
the
the
charter
of
the
multicast
group
is
really
about
bringing
the
browser
to
a
to
a
decent
place,
but
it's
also,
I
think
this
plays
into
the
to
the
overall
story
of
what
needs
to
happen.
Some
of
it
is
going
to
be
outside
standards
bodies,
and
you
know
convincing
people
that
they're,
that
their
interests
lie
in
this
direction
and
that
this
is
worth
investing
in.
D
D
D
B
D
A
Yeah
here
I
this
is
why
I
was
engaging
with
demos,
and
this
is
really
what
the
next
steps
I've
proposed
here
or
are
trying
to
focus
on,
is
getting
demos
closer
to
being
what
would
actually
be
releasable
in
some
form,
something
closer
to
credible
the
standards
work
is
going
to
be
a
part
of
that
and
I
think,
an
important
part
of
that.
That's
that's
going
to
come
before
it
gets
put
into
any
actual
browsers,
but
having
a
browser
fork.
A
That
does
something
useful
is
to
me
one
of
the
one
of
the
key
next
steps
to
to
make
the
case
that
we
can
do
something
real
here.
That
people
will
believe
you
know,
and-
and
the
other
piece
of
that
is-
is
getting
the
buy-in
from
the
browser
from
the
browser
text
ad
that
okay,
this
this
is
not
a
a
I
I
mean
you
know.
Most
of
the
objections
come
on.
The
security
side
is
what
I've
seen.
A
So
this
is
where
we
we
think
that
the
the
next
stage
focus
has
to
be
probably,
but
it
also
has
to
be
like
just
a
sufficiently
credible
proposal
for
people
to
pay
attention
and
that's
why
my
proposal
for
next
steps
is
to
is
to
get
the
demo
closer
to
that
really
credible
proposal
right
now.
What
we
have
is
like,
yes,
it
can
play
video,
but
but
not
something
not
in
a
way
that
could
be
accepted
into
a
browser.
A
A
You
know
there's
racks
and
racks
full
observers
that
they
might
not
have
to
run
if
they,
if
they
get
into
this
work
and
like
the
ongoing
cost
of
those,
can
be
quite
high.
So
you
know
it
could
reduce
their
their
spend
either.
With
you
know,
cdns
or
with
this
is
one
of
the
carrots
that
we
offer
to
the
customers
that
we've
talked
to
to
do
some
of
the
do.
Some
of
the
looking
is
like
discounts
on
them
on
the
traffic
that
can
be
delivered
with
multicast.
A
E
I
agree
it's
an
interesting
problem
to
coordinate
so
many
challenges.
I
guess
part
of
the
conversation
that
might
be
needed
with
stakeholders
will
be
bound
to
a
sense
of
a
timeline,
and
you
brought
up
the
case
of
amazon
earlier,
which
is
quite
interesting.
So
what's
your
best
guess
as
to
how
much
time
would
be
needed
to
align
the
stars?
Yeah.
A
I'll
say
you
probably
shouldn't
trust
my
estimate
because,
from
my
point
of
view
I
have
a
demo
running
there's
you
know,
I've
put
it
into
a
browser.
I
played
video
using
it.
That's
posted
today
on
the
under
the
web,
network's
tpac
thing.
There's
a
chromium
fork
binary
you
can
download
and
install
and
run
and
and
receive
udp
packets
unauthenticated,
but
you
can,
but
you
can
then
process
the
edp
packets,
in
whatever
way
you
want
I'd,
be
happy
to
to
share
a
link.
A
E
So
I
guess
what
I'm
hearing
is
that
in
your
plan
again,
the
security
obstacle
is
a
key
one
to
lift,
to
build
to
to
give
confidence
that
we
can
build
momentum
across
all
the
stakeholders.
Once
you
have
something
that
you
could
convince
a
browser
to
ship,
then
you
can
use
it
to
convince
at
least
one
isp
to
use
it
and
a
big
content
provider
to
use
it,
and
once
you
have
that
you
start
a
virtual
cycle
of
adoption.
Is
that
basically
the
plan?
Basically.
A
Yeah,
you
know,
there's
there's
a
few
other
rays
of
hope
here,
there's
giant
and
internet
two
both
are
I've
been
talking
to
them.
They
have
multicast
working
groups
and
they
are
sort
of
collectives
of
enrons
and
they
have
a
research
mandate
or
or
charter
to
support
some
research
initiatives,
and
they
they
do
think
multicast
is
worthwhile.
A
This
is
this
is
a
big
part
of
what
our
lab
tests
with
isps
we're
looking
at,
but
there's
yeah,
there's
a
there's
a
number
of
moving
parts,
some
of
which
are
outside
the
charter
of
w3c,
but
but
that
are
essential
to
eventual
adoption,
and
so
that
this
is.
This
is
part
of
the
complexity
of
the
problem.
So
in
this
group,
what
I
had
really
been
hoping
to
do
is
is
move
forward
the
received
side
of
this
story,
but
there's
you
know,
I.
A
Interested
people
to
engage
on
the
iatf
side
as
well,
which
is
a
big
part
of
of
moving
the
rest
of
the
story
and
the
isp
side
of
this
as
well
and
and
getting
the
whole
picture
to
the
stakeholders
like
it
is
complicated
with
a
lot
of
moving
pieces.
But
there's
a
lot
of
money
at
stake
too,
and
a
big
impact
in
what
it
can
achieve.
So
it
seems
worthwhile
to
try
to
make
it
happen
to.
F
Yeah
jake,
I
I
have
a
kind
of
a
question
like
I
think
the
customers
really
want
this
solution
if
it's
really
transparent
for
them,
so
as
transparent
as
possible.
So
from
what
I
see
from
the
dvd
side,
so
essentially
they
they
kind
of
enable
the
the
receiver
through
the
impact
dash.
So
like
an
impact
player
and
yeah,
I
haven't
seen
the
really
the
complex
security
model
they
they
made,
they.
Basically
they
have
an
easier
problem.
F
I
would
say,
because
they
have
adjusted
broadcasting
right
so
and
here
we
want
to
resolve
this
matter
cast.
That
means
we
have
to
manage
the
source
and
also
manage
the
the
encryption
on
each
each
marker
stream,
and
so
I
I
have
a
one
question
like.
Yes,
we
consider
the
the
current
the
receiver
side,
but
is
that
possible
on
the
server
side
like
since?
Currently
we
have
this
kind
of
so-called
age
server,
even
the
5g
h,
which
is
much
closer
to
the
last
male
issue
right.
F
A
Yeah,
so
I
have
to
say
it
comes
back
to
this
kind
of
a
situation
like
I
think,
if
you
really
are
making
use
of
the
broadcast
capability
at
the
edge,
then
it
might
be
possible
to
to
do
something.
But
the
issue
here
is
that
you're
trusting
those
edge
servers.
This
has
a
history
in
the
ietf
of
having
some
trouble.
When
you
hand
off
control
on
you
know,
in
a
way
that
they
can
change,
there's
been
cases
of
like
ad
stealing
is
what
they
call
it,
where
the
I.
A
This
is
part
of
the
reason
that
that
end-to-end
encryption
has
become
so
important
right.
If
you,
if
you
send
something
that
that
an
isp
on
the
path
can
change,
then
there's
been
cases
where
they'll
change
the
content
on
the
way,
and
so
it's
not
what
the
sender
sent
it's
it's.
What
got
passed
through,
that
the
end
user
gets-
and
this
is
a
big
source
of
you
know-
I
mean
that
is
actually
the
way
it
works
today
in
like
the
broadcast
tv
world,
because
you
can't
get
the
scale
on
on
internet.
A
But
when
you
talk
to
the
web
people
and
when
you
talk
to
the
ietf
people,
then
you
know
there
is
a
barrier,
a
security
barrier,
to
sort
of
handing
off
control
and
requiring
this
this
chain
of
trust.
That
explicitly
includes
your
last
hop
isp
between
the
the
source
of
the
content
and
the
customer,
and
this
is
part
of
what
we've
addressed
with
the
with
the
ambi
authentication.
A
There's
not
a
way
for
that
to
be
spoofed
anymore.
They
still
do
have
to
pass
it
through
and
to
choose
to
allow
it
or
not
allow
it.
But
this
this
creates
an
end-to-end
authentication
chain
that
that
the
intermediate
isp
can
no
longer
change,
and
so
there's
no
scope
anymore.
For
you
know,
for
ad
theft,
for
example,
or
for
you
know,
unauthenticated
injection,
but
you
know
that's,
that's
only
one
of
the
of
the
several
problems
like
I.
A
This
has
a
different
set
of
problems
to
solve
it's,
not
it's
not
impossible.
That
might
be
a
way
that
that
you
get
the
similar
kind
of
broadcast
scale
in
the
end,
but
the
where
it
gets
more
complex
is
well
a.
It
only
works
for
video
you're
not
going
to
get
vr
this
way,
that'll
be
a
whole
new
set
of
problems
that
have
to
come
in.
A
You
know,
gameplay
kinds
of
things,
there's
other
use
cases.
Also
the
downloads
like
that
is,
it
might
be
that
you
can
standardize
like
what
does
the
download
look
like,
and
you
can
do
the
same
kind
of
story
where
you
hand
off
the
entire
thing
to
an
isp
or
a
you
know
the
access
basically
provider
who
then
distributes
it
with
a
broadcast
technology.
A
F
Sorry
yeah
yeah-
I
I
I
know
so,
but
but
what?
What
I
see
is
that
there's
an
incentive
to
for
for
isp
to
make
some
change
right.
So
since
it's
going
to
save
the
runways
and
and
then
the
problem
is
it's
quite
easy
for
them
to
make
this
traffic
kind
of?
Because
we
are
talking
about
like
a
fallback
to
the
unit
and
it's
easy
to
to
make
the
changes
from
the
from
the
asp
position.
F
A
I
think
the
way
we've
proposed
is
the
easier
way
for
the
isp.
They
don't
have
content
to
manage
that
they
have
to
be
the
source
of
maintaining
it.
All
they
have
to
do
is
pass
through
streams
and
make
decisions
about
yes
or
no.
Are
we
going
to
pass
through
the
multicast
streams?
So
it's
it
is.
This
is
one
of
the
big
design
questions
like
which
way
should
that
be
done?
Should
it
be
like
only
the
end?
A
Isp
is
the
one
that
can
do
the
broadcast
and
you
have
to
give
it
to
them,
as
as
a
a
you
know,
coherent
object
that
they
can
unpack
and
distribute,
or
is
there
a
way
to
do
this
such
that
such
that
when
they
import
traffic
as
a
stream
with
opaque
packets,
they
can
just
stream
those
packets
through
using
the
existing
multicast
work?
And
you
know
people
have
different
opinions
on
this
point.
A
A
They
can
focus
on
getting
the
packets
through
and
maintaining
network
help,
instead
of
having
to
deal
with
the
end
user
applications
that
are
broken
or
not
broken
that
work
with
some
content,
not
other
content
that
you
know
if
you,
if
you
make
the
capability
of
oh,
it's
just
ip
and
they
can
pass
it
on
through
and
it's
the
end
applications
in
the
senders
that
decide.
Well,
how
is
that
content
interpreted
then
you're
in
a
little
bit
better
shape,
it's
it's
closer
to
being
what
http
can
do,
although
there
are
some
some
important
differences.
A
A
And
I,
if
anybody
would
like
to
join
me
on
that,
please
reach
out
contact
me.
I
would
like
to
to
collaborate
with
some
people,
if
possible,
I'll,
probably
be
spending
a
few
weeks
on
this
over
the
next
month,
probably
after
the
ietf
completes,
but
to
see
where
I
can
get
with
some
of
these
existing
quick
libraries
that
that
have
done
some
of
the
this
is
the
the
draft
http
over
quick
from
the
bbc
in
the
nghq
and
the
web
transport.
A
Quick
implementation
uses
this
aio
quick
and
I'm
not
sure
which
one
is
going
to
be
easier,
but
that
will
be
part
of
the
investigation
and
that's
just
a
you
know,
a
very
small
next
step,
but
it's
an
important
one.
I
think
the
ambi
implementation
is
another
important
thing
to
get
moving.
Anybody
who
can
contact,
who
can
comment
on
the
sec
dispatch
thread?
I
think,
if
you've
participated
in
ietf
before
this,
this
seems
potentially
an
important
moment
for
just
demonstrating
that
that
there
is
some
value
in
this.
A
Anybody
who's
interested
in
that
also
please
reach
out,
and
that
would
be,
I
believe
next
week
during
the
hackathon
week
preceding
atf.
I'm
not
sure
if
this
is
coming
together
exactly,
but
it
really
kind
of
depends
depends
on
the
interest,
but
anyone
who
wants
to
participate
I'll
hook
you
up
with
with
the
right
people
to
talk
about
it
right.
So
do
we
have
any
action
items
to
walk
away
with
here?
I
think
we
had
any
final
questions
or
I
hope,
I've.
A
A
A
Anyone
who
wants
to
be
in
the
community
group
we
meet
monthly,
so
the
next
this
one
we
moved.
Usually
it's
the
first
wednesday
of
the
month.
We
moved
it
to
tpack
week
instead,
so
that's
instead
of
next
wednesday,
but
the
first
wednesday
in
december,
that's
usually
at
7
30
pacific
time
at
7,
30
a.m,
pacific
time
so
half
an
hour
before
the
start
of
this.
But
if
you
want
to
contact
me
offline
before
then,
please
do
feel
free
and
I
will
end
the
recording.
Thank
you.