►
From YouTube: IETF110-MBONED-20210311-1200
Description
MBONED meeting session at IETF110
2021/03/11 1200
https://datatracker.ietf.org/meeting/110/proceedings/
C
A
Days
too
man
it's
we
used
to
see
each
other
yeah.
We
used
to
be
in
a
room,
that's
true.
We
used
to
see
each
other.
Yes,
I
forgot
about
that.
Yeah
yeah
I
I
can
certainly
contribute.
I
would
need
help,
of
course,
for
you
know
for
for
the
parts
where
I'm
talking.
A
Great
but
yeah
I'm
happy
to
to
help
here.
I
guess
I
will
paste
in
the
agenda.
E
B
A
Went
I
got
up
too
yeah
last
week
I
started
on
trying
to
be
proud.
I
mean
this
isn't
real
prague
time.
This
is
like
this
is
like
be
nice
to
east
coast,
prog
time
right,
which
is
actually
which
is
actually
really
helpful
for
us
on
the
west
coast
as
well,
at
least
in
my
opinion
like
it's
way
better
to
get
up
at
three
than
it
is
to
get
up
at
you
know,
11,
30.
A
and
but
yeah
I've
been
doing
it
all
week
because
it
just
works
better.
That
way,
I
think
we're
and
it's
not
any
worse
than
traveling
we're
at
pride
lunch
time
yeah,
which
is
fine
ish
as
long
as
you're,
not
in
the
wrong.
You
know
I
mean
unless
you're
in
australia,
I
guess
but
fine
for
a
week
or
or
lots
of
places.
Yeah
I
mean
it's,
it's
gotta
suck
for
somebody
right,
it
sucks
a
little
for
me.
It
could
be
worse.
A
B
Right
greg:
do
you
think
we're
ready
to
start
looks
like
we've
got
a
decent
number
of
folks
online,
ready.
F
Enough
yeah,
absolutely
we
got
to
get
rolling,
they
didn't
shut
us
down
on
tuesday,
though
we
were
about
15
minutes
over
and
we
continued
to
roll.
It
was
great.
They
didn't
suddenly
chop
us
off,
but
I
don't
want
to
push
resources,
let's,
let's
not
shoot
for
that.
B
G
B
All
right,
so
why
don't
we
get
started
here
hold
on
here.
B
You
can
all
I
assume
see
the
note.
Well,
please
do
note
it
well
very
important
stuff
and
I'm
sure,
you've
seen
it
multiple
times
this
week
should
be
the
same.
All
right.
Here's
our
agenda,
mike's
gonna,
provide
some
updates
and
one
of
embundi's
charters
is
charter.
Items
is
to
receive
reports.
Deployment
reports
from
folks
who
are
really
using
multicast,
really
excited
to
have
oriole
from
umetsat
talk
about
their
use
of
multicast,
and
they
are
a
true
classic
m-bone
application.
B
They
are
using
multicast
over
the
rna
networks
and
delivering
their
content
natively
to
customers
across
to
their
customers
across
true
inner
domain,
multicast
routing,
both
ssm.
They
had
done
asm
in
the
past,
not
sure
about
now,
but
lots
of
interesting
stuff
that
he's
going
to
talk
about,
and
it's
an
application
of
many
of
the
things
we've
discussed
over
the
years.
B
A
So
lenny,
your
slides
are
not
advancing.
You
maybe
have
the
wrong
screen
showing
or
something
agenda.
I
Yeah,
if
you're
using
presentation
mode
in
some
cases,
it
becomes
a
different
window
that
the
browser
is
not
able
to
capture.
So
it's
still
capturing
the
domain
content
instead.
So
it
varies
from
browser
to
browser.
So
it's
hard
to
to
figure
out
that
if
you
remain
with
this
view,
you're,
probably
okay,.
B
All
right-
and
hopefully
everybody
can
just
squint
and
see
this
okay.
We
won't
be
here
for
long.
The
next
up,
jake's
gonna
talk
about
his
four
drafts
and
then
lorenzo
is
going
to
talk
about
how
meat
echo
uses
multicast
comments
on
the
agenda.
B
All
right
in
terms
of
the
status
of
the
active
working
group
drafts
the
multicast
problems.
The
wi-fi
problems,
draft
problem
statement
draft
has
been
revised
to
address
the
iesg
comments.
Mike's
gonna
provide
the
latest
update
on
that
the
yang
models
draft
sandy.
Anything
to
say
about
that
one.
You
presented
that
in
109..
A
Sorry
about
that
I
will.
I
will
get
right
on
that.
Then
thank
you
for
I.
I
must
have
dropped
that
sorry.
I
I
will.
A
I
will
look
for
that
and
make
sure
you
get
it
by
the
next
week.
C
B
Else
who
wants
to
to
review
as
well
I'm
sure
sandy,
you
would
appreciate
other
reviews
as
well.
B
Misspelled
poorly
the
seaback
and
dorms
draft
were
sent
to
the
yang
doctors,
and
jake
is
oh.
The
the
the
nat
draft
has
been
adopted
since
109
and
josh
and
jake
is
going
to
provide
updates
on
all
four
of
those
today
and
mike
is
gonna
mike
or
one
of
his
co-authors
will
talk
about
the
telemetry
draft
other
drafts.
B
There
was
the
redundant
ingress
failover
draft
that
was
presented
in
109
informationally,
haven't
seen
looking
for
comments
at
the
time
I
haven't
seen
any
updates
or
anything
from
that
since.
E
Yeah,
can
you
hear
me?
Okay,
yes,
all
right,
very
good,
so
this
draft
and
warren
can
feel
the
pain
as
well.
But
we've
been
working
on
this
for
a
long
long
time
and
we
received
a
daunting
amount
of
comments,
discusses
during
iesj
review
and
we've
been
slowly
picking
away
at
them
at
first,
we
just
kind
of
just
ignored
them,
because
we
had
a
lot
more
better
things
to
do
and
we're
just
kind
of
over
the
draft,
but
we
are
still
picking
away
at
them.
If
you
go
to
the
next.
E
E
You'll
see
the
document
history
in
just
the
last
few
months
anyway,
and
so
what
we've
done
is
so
alyssa
is
the
first
one
who
made
a
quite
a
list
of
of
comments
and
just
in
in
total,
it's
just
a
it's
just
a
lot
of
work,
just
editing
and
adding
explanations
of
different
things,
and
so
we
submitted
a
new
draft
after
her
comments
and
her
discuss
was
then
cleared.
E
E
E
Yeah
just
stay
on
three,
then
that's
perfect
yeah!
This
just
gives
you
an
example
of
some
of
the
editing
that
was
needed
because,
with
all
the
comments
people
say,
why
is
it
taking
you
so
long?
Well,
there's
just
a
lot
of
comments
like
and
that
just
take
time
to
address
and
recreating
paragraphs
and
one
of
them
was
you
know
it
appears
that
you're
using
recommend
using
arp
sponge
and
so
providing
some
general
caution
about
our
poisoning
and
false
advertising.
E
And
so
then
we
just
recreated
that
and
kid
gave
an
explanation
about
it
and
had
to
look
up
arp
sponge
and
all
that
and
try
to
make
a
reasonable
discussion
about
it
and
then
just
on
and
on
ago.
So
just
this
is
what
we're
doing
and
it
the
process
is
slow,
but
it
is
working,
and
I
would
anticipate
that
we
will
be
done
and
really
done
with
this
strap
by
next
ietf.
E
Assuming
that
the
remaining
discusses
are
addressed.
If
you
go
to
the
next
slide,
let's
yeah,
okay,
so
benjamin's!
These
are
the
remaining
he's,
the
last
one
who
made
a
list
of
comments
and
there's
pages
of
them,
and
so
we
will
address
those
and
submit
a
new
draft
in
the
next
few
weeks
and
then,
if
he
clears
them,
which
he
probably
will,
then
we
hopefully
are
done.
There
are
several
other
people
who
made
comments
during
the
review,
but
yeah.
E
If
you
go
to
the
last
slide,
but
we
should
be
good
to
publish
once
that
last
discuss
is
cleared,
so
it
is
a
good
you
know
unbiased,
but
it
is
a
good
document
that
just
discusses
issues
in
multicast
in
a
wi-fi
environment,
and
there
have
been
comments
to
add
additional
things
to
it,
because
there's
always
some
good
points
and
we've
added
a
lot
of
them,
but
now
we're
not
adding
anything
else
to
it.
We're
just
trying
to
finish
it
up
and
be
done
any
questions
about
any
of
that.
D
J
D
B
Like
while
I'm
furiously
clicking
around
here,
why
don't
you
begin
to
start
talking
about
this?
Drawing
yeah.
E
E
Sure
yeah
there's
not
a
ton
to
be
said
about
it
anyway,
I
do
see
how
you
on
the
line
as
well.
So
one
of
my
co-authors
is
here
we're
sharing
in
the
morning
pain
with
all
of
you.
Thank
you
how
you
so
chime
in.
If
there's
anything
you
want
to
add,
but
so
this
draft
was
recently
adopted
by
mbondi
working
group.
E
It's
we
added
a
few
authors
as
well,
who
are
very
interested
in
working
on
this
topic
and
anxious
to
contribute.
E
Solutions
in
the
draft
and
describe
the
problem,
I
think
probably
what
we'll
do
is
there
is
a
fair
amount
of
interest
in
increasingly
interest,
which
is
good
in
oam
related
topics,
so
we'll
probably
make
that
more
robust
in
the
document
just
kind
of
describing
that
better,
if
it
gets
too
big,
we'll
propose
spitting
it
off
into
its
own
oam
draft,
perhaps
in
just
more
of
a
multicast
story
and
type
of
a
draft.
E
But
I
am
looking
forward
to
working
on
this
draft
because
it
is
a.
It
is
a
a
good
topic
if
you
go
to
the
next
slide,
we'll
probably
just
fly
through
some
of
these
slides.
So
this
is
is.
B
Is,
can
you
see
this
slide
clearly
or
is
it
good?
It
looks
a.
E
Little
enough,
but
it
does
there's.
K
E
Little
squares
in
the
upper
right
hand
side,
but
it's
fine.
I
can
see
all
the
words
in
it.
Yeah
there
you
go
moving
it
around
helps
a
little
bit,
keep
doing
whatever
you
got
to
do.
That's
fine
to
try
to
make
look
good
for
future
presentations,
but
so
multicast
traffic
monitoring
is
important,
just
like
as
it
is
with
unicast.
E
It's
important
to
reconstruct
and
visualize
that
multicast
tree
for
performance,
monitoring
and
troubleshooting,
and
there
are
some
techniques
that
can
be
used
for
multicast
and
that's
those
techniques
for
unicast
are
being
developed
in
ippm
working
group.
It
was
agreed
to
work
on
the
multicast
pieces
here.
E
They
do
have
flaws
for
multicast
the
current
on
path
techniques,
and
so
there
are
some
solutions
that
are
discussed,
maybe
some
new
ones
that
will
perhaps
introduce
to
the
draft
as
well
to
get
some
idea
but
the
whole.
The
goal
is
to
to
allow
the
original
multicast
tree
to
be
correctly
reconstructed
without
unnecessary,
unnecessary
replication
of
the
telemetry
information
next
slide.
E
So
there
are
a
couple
different
solutions
that
we
have
there's
a
per
post
card
per
hot
postcard
and
a
per
section
postcard,
which
are
both
enhancements.
The
per
postcard
is
a
branch,
node
replicates
the
packets
and
each
branch.
Node
adds
a
branch
identifier
to
the
instruction
header.
E
So
per
section
per
section
postcard,
it's
it's
a
postcard!
Is
it's
and
that's
what
it's
called
in
the
fppm
working
group?
It's
the
postcard
is
set
that
each
section's
endnode
and
the
postcard
contains
data
for
the
entire
section
and
those
postcards
can
be
easily
stitched
together.
There's
no
need
to
modify
the
existing
iom,
header
format.
E
E
E
So,
as
I
mentioned
at
the
beginning,
perhaps
we
will
add
more
of
an
oem
overview
at
the
start,
we'll
develop
the
sections,
I'm
seeing
a
variety
of
things
here,
but
I
think
that's
basically
what
we're
the
point
we
wanted
to
make
is
that
anything
else
you
wanted
to
add
value
to
what
we
plan
to
do
in
the
future.
For
this
draft.
E
I
suppose
not
so
yeah
any
questions.
E
Just
kind
of
as
a
general
comment
and
wendy,
and
I
kind
of
swap
some
emails
back
and
forth,
but
there
are
some
newer
applications
for
multicats
that
are,
in
my
opinion,
making
multicast
more
and
more
relevant,
including
live
streaming
which
is
taking
off,
and
it's
not
all
about
sports
anymore
and
it's
even
live
sports,
and
so
I
think
of
these
oem
related
techniques
as
multicast
is
projected
to
take
more
and
more
of
network.
E
A
Free
to
speak
sorry,
yes,
all
right,
all
right,
good,
so
yeah,
just
a
quick
question
about
the
is
there
I
I
skimmed
the
draft,
but
I
there
there
was
some
detail
like.
Are
you
addressing
the
sort
of
scalability
issues
of
the
analysis
of
the
oem
telemetry
across
a
multicast
network
or
as
part
of
the
draft,
or
is
that
sort
of
the
to
the
apps?
E
Okay,
that
okay.
A
So
there's
not
like
recommendations,
you
think,
need
to
go
in
there.
That's
like
already
sort
of
reasonably
well
covered
by
the
by
the
apps.
E
Yeah,
you
know
that's
a
great
point.
Maybe
we
probably
should
add,
because
I'm
not
even
familiar
with
some
of
those
apps.
So
that
would
be
a
good
thing
to
look
into
of.
A
E
B
Great
thanks,
mike
and
and
just
a
little
bit
background
I
forgot
to
mention
this
draft
was
adopted
it's
so.
This
was
presented
in
109
in
both
mbondi
and
pim
previously
had
been
adopted
or
had
been
presented
in
ippm,
and
there
was,
I
think
you,
like
you,
started
at
ipp
ippm.
B
They
were
busy
not
interested
and
then
presented
in
pim
and
and
then
bondi
last
time,
and
it
was
decided
that
mbondi
with
the
operational
aspects
of
this
draft
seemed
like
a
better
fit.
So
that's
how
we
we
ended
up
with
it
and
it
was
adopted
with
fairly
strong
consensus.
So.
B
F
D
K
So
hello,
everybody,
my
name
is
oriol
espanol
and
I
work
as
a
umedcast
system
engineer
for
umezad.
I'm
actually
very
excited
to
be
here
today
and
share
some
details
of
our
services
with
you
just
as
a
background
short
story.
Why
we're
here
today,
apparently-
and
I
didn't
know
this
before-
is
one
of
the
top
three
contributors
of
multicast
traffic
on
the
mbom
with
our
umed
cast
terrestrial
service.
K
I
understand
that.
I
understand
that
some
of
you
thought
it
would
be
interesting
to
know
more
about
our
case,
so
leonard
made
this
possible
thanks
to
common
contact
that
we
have
engine,
so
thank
you
leonard
for
making
this
possible
okay,
so
next
slide.
So
the
plan
is
that
we
have
a
short
presentation
on
who
we
are
and
what
we
do.
Quick
system
overview
on
our
satellite
and
terrestrial
services
follow
up
by
the
details
about
terrestrial
service,
which
I
presume
is
the
most
interesting
part
to
you.
K
I
have
around
15
slides
in
total
to
present
but
feel
free
to
ask
me
any
questions
during
the
presentation.
If
something's
not
clear
or
you
won't,
you
want
more
details
about
that.
So
next
slide,
please
so
who
who
we
are
and
what
we
do.
Umitat
stands
for
european
organization
for
the
exploitation
of
meteorological
satellites
and
we
are
a
public
sector
organization
with
currently
30
funding
european
member
states.
Our
mission
is
to
maintain
and
exploit
the
european
meteorological
satellites.
K
That
means
that
umassat
is
responsible
for
the
launch
and
operation
of
the
satellites
and
especially
relevant
for
us
today,
delivering
satellite
data
to
the
end
users,
the
end
users
use
this
data
for
weather
prediction
and
global
monitoring
of
climate
change,
climate
change
and
weather
prediction
is
a
common
global
interest
and
has
established
cooperation
with
partners
from
other
countries
such
as
china,
india,
japan,
russia,
south
korea
and
the
united
states.
K
K
K
These
slides
present
a
system
overview
of
the
umedkas,
which
is
umidsat's
push
service
that
delivers
environmental
data
in
near
real
time
to
its
registered
users.
The
data
delivery
is
implemented
as
an
ip
multi-class
one-to-many
dissemination
system,
with
a
single
transmission
from
the
server
and
guaranteed
timeliness
distribution
to
the
end
users
reception
stations.
K
Therefore,
it
allows
the
end
users
to
receive
the
data
on
the
reception
station
shortly
after
umitzat
makes
it
available.
On
the
left
side,
you
see
the
data
acquisition
process
directly
from
the
satellites
operated
by
umezad
and
into
the
ground
into
the
ground
station
and
into
headquarters
in
armstrong.
Germany
from
there
is
sent
out
via
ip
multicast
to
our
satellite
and
terrestrial
services.
K
On
the
top
side.
This
is
the
humid
cast
satellite
service
for
this
service.
The
multicast
is
transferred
via.
K
Link
from
yumasa
to
the
abilene
facility
there,
the
multicast
is
encoded
into
a
dvd
signal
and
transmitted
to
geostationary
communication
satellites
for
broadcast
to
user
reception
stations,
its
reception
station
decodes,
the
signal
and
recreates
the
original
multicast
stream
in
the
middle
you
see
humid
cast
terrestrial
over
jian.
This
is
an
evolution
of
the
humid
cast
satellite
system.
However,
instead
of
using
commercial
satellites
for
dissemination
to
the
users,
the
terrestrial
service
relies
on
the
network
infrastructure
provided
by
gm
across
europe.
K
The
service
relies
on
all
native
multicasts,
however,
in
order
to
overcome
islands
of
non-multicast-enabled
networks,
gn
also
provides
the
option
to
use
gre
tunnels
directly
to
the
reception
stations
of
the
end
users.
These
are
manually
activated
on
demand
when
a
temporal
loss
of
multicast
is
detected
at
the
bottom.
You
see
humid
cast
terrestrial
over
internet
service.
This
is
a
further
evolution
of
the
the
terrestrial
system.
However,
instead
of
using
the
gm
network,
this
service
relies
on
the
internet.
K
One
added
benefit
of
this
setup
is
that
it's
not
traversal
without
requiring
a
reconfiguration
of
the
end
users
firewalls.
A
key
takeaway
from
this
slide
is
that
we
have
only
one
source
of
multicast
traffic.
We
have,
however,
different
groups.
Other
different
group
addresses
for
the
satellite
and
terrestrial
service.
The
motivation
for
this
is
that
these
groups
require
different
reliability
configurations,
so
we
prefer
to
split
them.
However,
this
being
multicast,
we
could
have
the
same
groups
for
the
satellite
and
restore
services
as
well.
K
Next
slide,
please
so
again,
this
slide
represents
the
segregation
of
the
two
terrestrial
streams
and
and
the
motivation
why
this
is
needed.
On
one
side,
we
we
have
the
the
native
multicast
service
provided
by
gian.
This
is
the
most
cost
effective
solution,
hence
the
default
and
and
prefer
transport
layer,
then,
on
top
of
that,
gn
also
provides
these
on-demand
gre
tunnels
to
to
overcome
these
islands
of
non-enabled
multicast
and
typically
when
the
user
is
connected
to
an
enron
that
does
not
support
native
multicast.
K
However,
we
run
into
what
we
call
the
the
eligibility
problems,
that
is,
that
the
user,
either
the
user
is
not
eligible
to
to
connect
to
the
entrant,
maybe
because
the
users
to
not
belong
to
a
representative
institution,
for
instance,
or
radio
and
second,
you
must
set
data-
might
not
be
eligible
circulating
in
the
end,
because
the
enron
considers
this
data
of
non-non-researched
nature
because
needs
to
guarantee
access
to
to
its
data
to
to
all
national
member
states.
K
The
internet,
lack
of
of
the
human
thruster
services
was
developed,
which
then
uses
this
l2tp
ipsec
encapsulation
to
deliver
the
multicast
traffic
because,
as
we
know,
the
internet
is
not
multicast
capable
yeah.
So
next
slide,
please
so
how
how
is
humid?
This
is.
How
is
this
service
implemented?
K
So
is
a
near
real-time
dissemination
system
based
in
ib
multicast
push
with
guaranteed
timeliness
delivery.
We
distribute
our
data
as
files
and
they
have
like
a
sort
expiration
date,
so
to
speak.
That
means
that
all
data
not
distributed
within
timeliness
is
not
that
interesting
for
the
users
anymore.
We
do
not
distribute
any
video.
It's
just
files
plain
files
with
with
satellite
data.
K
K
Because
of
because
of
this
underlying
multicast
technology,
our
output
stream
is
is
highly
scalable
with
the
number
of
users
and
volumes
of
data,
and
it
provides
you
with
side
with
a
sequel,
secure
way
to
deliver
data
to
its
users.
We
can
target
target
data
delivery
to
specific
users
or
groups
of
users.
Moreover,
we
we
can,
we
can
do
that,
ensuring
that
our
data
policy
is
is
respected.
K
K
However,
telecast
implements
three
different
and
complementary
reliability
mechanisms
and
for
two
of
those,
the
recipients
need
to
communicate
with
the
sender.
So
these
three
reliability
mechanisms
are
fake
forward,
error,
correction,
knack,
negative
acknowledgement
and
ack
acknowledgement.
So
first
the
fact
is,
this
is
performed
on
the
fly
and
does
not
trigger
retransmission.
K
On
our
operational
platform.
This
is
currently
configured
at
a
10,
10
percent
effect.
Then
we
have
second
the
next,
which
are
generated
when
a
client
detects
loss
packets.
In
that
case,
a
negative
acknowledgement
is
sent
upstream
to
the
source
which
retransmits
the
loss,
packets
via
multicast
to
all
subscribed
recipients.
K
The
the
knacks
are
sent
back
to
the
source
using
unicas
udp.
Then
we
have
the
acts
which
are
generated
after
the
file.
Transmission
is
over
then,
those
recipients
that
still
have
loss,
packets
from
the
nominal
transmission
and
and
and
the
max
report
their
status
to
the
server
which
then
initiates
a
new
multicast
transmission.
K
K
I
would
like
to
know
that
the
knacks
trigger
immediate
transmissions
and
do
not
significantly
impact
the
overall
timeliness
of
of
the
deliberate
files.
On
the
other
hand,
the
retransmissions,
triggered
by
the
arc
messages
introduce
a
delay
on
the
file
delivery
and
also
produce
files
delivered
to
the
end
user
out
of
order.
K
So
what?
What
can
we
recover
from
these
loss
packets
with
this
reliability
mechanisms?
So
our
testing
shows
that
random
packet
loss
below
five
percent
is
fully
recovered
by
fec
alone,
without
any
retransmissions
that
interruptions
of
less
than
400
milliseconds
are
fully
recovered
by
effect
alone,
without
retransmissions
that
interruptions
of
less
than
one
two
seconds
are
fully
recovered
by
knack
and
fec
working
together
and
interruptions
of
more
than
two
seconds
can
can
be
recovered
by
ack,
but
they
introduce
a
delay
in
the
file
delivery.
K
Now,
with
the
with
the
increase
of
number
of
recipients,
we
can
have
the
case
where
one
or
several
recipients,
with
low
quality
links
impact
the
nominal
transmission
to
the
rest
of
the
participants.
K
The
telecast
software
has
several
countermeasures
in
place
for
each
of
those
mechanisms,
for
instance,
for
for
the
knack
there
is
a
configurable
maximum
bandwidth,
a
percentage
of
the
total
available
bandwidth
that
can
be
used
for
transmissions,
so
the
nominal
transmission
is
always
guaranteed.
This
is
currently
set
at
50
for
our
operational
settings.
K
For
then,
for
for
the
x,
there
is
a
configurable
minimum
that
the
recipient
must
have
received
of
the
send
file
in
order
to
to
trigger
a
transmission.
This
is
currently
set
at
40
percent
of
in
our
operational
platform.
That
means
that
users
end
users
that
receive
less
of
40
of
the
file
are
discarded
for
for
the
transmissions.
K
These
settings
are
based
on
trial
and
error
tuning
on
the
platform,
so
some
more
additional
relevant
settings
of
our
operational
implementation
is
this
time
to
lift
that
is
currently
set
at
60
64.
K
K
Okay,
yeah
next
slide,
please
just
a.
B
K
Yeah
now
good
question,
so
this
is
a
commercial
of
the
shelf.
This
is
cots
and
is
it's
kind
of
kind
of
a
very
kind
of
old
or
yeah,
an
old
implementation-
maybe
it's
from
10
15
years
ago,
and
but
it's
still
being
used
operationally
by
the
the
company
that
produced
this
initially
and
they
use
it
mainly
for
satellite
communications.
K
However,
they
still
use
it
for
their
own
operations,
so
we
are
one
of
their
last
users
that
do
not
rely
on
the
actual
on
their
actual
hardware
that
we
use
this
software
just
standing
alone,
with
no
hardware,
with
no
without
their
hardware
right:
okay,
yep
thanks
so
g
and
acts
as
the
sole
network
as
a
network
service
provider.
K
An
interface
point
for
us
with
the
rest
of
the
the
national
research
and
educational
networks
and
gm
provides
the
backbone
network
topology
for
the
european
region,
but
also
collaborates
with
other
entrance
to
provide
global
connectivity
to
to
the
users.
Therefore,
we
rely
on
gm
to
grant
us
access
to
end
users
called
worldwide
yeah,
and
this
is
this
is
what
this
map
shows.
All
the
connections
that
gn
gives
us,
especially
especially
relevant
for
your
case,
probably
with
the
internet
too.
K
Okay
next
slide,
please
so
these
slides,
present
colored
in
in
dark
blue
all
the
countries,
countries
where
there
are
unit
cast
terrestrial
stations
operating
and
receiving
our
traffic,
so
that
you
see
that
the
terrestrial
service
provides
access
to
users
outside
the
unit
outside
the
satellite
footprint
which
is
over
over
europe,
mainly
and
especially
relevant
to
the
unborn
working
group
is
probably
the
university
of
wisconsin
madison,
because
thanks
to
this
user,
that
the
native
multicast
flows
through
the
internet,
2
and
the
emblem
there
is
another
user
in
the
usa
that
receives
our
traffic.
K
Then,
however,
they
receive
it
via
gre
tunnel
and
the
reason
for
that
is
that
some
institutional
users
do
not
like
multicast
traffic
flowing
into
their
system,
so
they
prefer
the
the
good
old
known
tcp
all
right
next
slide.
Please.
K
K
This
is
what
we
call
end-to-end
end-to-end
file
based
monitoring.
Basically,
we
compare
for
each
station
what
files
it
should
have
received
against
the
actual
files
it
received,
and
then
we
compute
the
the
percentage,
so
the
color
coding
is,
has
been
inherited
from
from
the
sla
that
we
have
for
the
satellite
service,
where
file
availability
below
99.5
percent
is
not
acceptable,
so
these
computations
are
based
on
on
the
act,
packets,
from
the
feedback
channel
and
and
in
our
experience,
the
common
reasons
for
achieving
achieving
lower
availability
are
so
network
bottlenecks
and
and
congestion.
K
Some
countries
have
very
good
links
like
within
europe
to
japan
or
the
us.
However,
in
other
countries
the
networks
are
not
so
good,
also
due
to
insufficient
last
mile
bandwidth,
and
this
is
typically
the
end
user
subscribing
to
more
data
than
than
they
can
actually
receive.
K
B
Or
oriole
the
the
the
feedback
channel
is
that
unicast
or
is
that
multicast.
K
That
that
is
unique,
tcp
unicast.
B
K
So
we
we
have
two
feedback
channels.
We
have
the
negative
acknowledgement
which
is
udp
unicast
udp,
and
then
we
have
the
acknowledgement
which
is
tcpip
unicast.
K
However,
you
can
still
have
like
a
knack
implosion
if
you
like,
but
we
have
measures
in
place
to.
I
think,
if
you
go
to
a
previous
slide,
we
have
we
have
measures
in
place
to
prevent
that
from
impacting
the
other
users.
That
is
this
one
that
that
is
so.
You
see
these
three
history
method
that
the
nag
and
the
act
so
the
return
channel,
udp,
unicast
or
tcp
unicas
for
the
nag.
K
K
So
we
are
always
sure
that
the
the
end
users
that
have
a
good
link
will
be
able
to
receive
will
be
not
will
not
be
impacted
by
end
users
that
have
a
a
low
quality
link
and
that
are
generating
a
lot
of
of
negative
acknowledgements,
but
at
the
at
the
numbers
that
we're
managing
at
the
moment,
we
obviously
they
are
still
small.
K
So
we
don't
see
that
as
of
an
issue
for
the
moment,
okay,
I
think
we
were
slide
12
yeah,
that
one
so
yeah,
so
satellite
industry
has
very
long
cycles,
so
we
can
predict
fairly
well
what
our
bandwidth
needs
will
be
in
the
future.
K
This
slide
presents
the
future
bank
with
needs
for
satellite
and
terrestrial
for
terrestrial.
You
see
it
goes
from
the
current
400
megabits
to
a
peak
of
almost
one
gigawatt
per
second
by
the
end
of
2025.
Then
it
it.
It
stands
around.
800
megabits,
yeah,
the
steep
increase
between
years
2023,
24
and
25
are
due
to
introducing
new
missions
and
new
satellites.
K
The
satellite
bandwidth
needs
are
lower.
Motivation
is
that
the
satellite
capacity
is
much
more
expensive
than
the
terrestrial
bandwidth,
and
then
that
is
by
an
order
of
magnitude,
therefore
has
strategically
decided
to
send
via
satellite
only
what
we
call
essential
data.
K
K
K
We
are
still
at
the
very
early
stage.
We
have
done
some
testing
with
the
amt
gateway
implementation.
From
from
from
this
from
this
link
from
github,
I
understand
mike
collin
is
one
of
the
main
contributors
of
this
solver.
So
many
thanks
for
that
really
appreciate
it.
Basically,
it
worked
out
of
the
box.
K
K
This
is
based
in
a
400
megabits
per
second
internet
connection
in
germany,
so,
basically
the
data
the
data
was
going
from
from
darmstadt
via
multicast
to
internet2
and
then
via
the
relay
back
to
germany,
and
we
do
we
did
several
tests.
So
when
no
written,
no
no
feedback
channel
and
with
a
bandwidth
of
around
100
megabit
stream,
0.6
packets,
0.6.
K
Of
the
packets
were
were
lost
after
the
even
after
the
fact.
However,
that
has
a
dramatic
impact
in
the
number
of
lost
files
yeah,
because
if
we
lose
just
a
few
bytes
of
one
of
the
files-
and
we
are
not
able
to
recover
them,
then
the
the
the
file
is
considered
corrupted
and
and
discarded.
Therefore,
just
a
few
a
few
lost
packets
have
have
a
very,
very
big
impact.
K
So,
however,
the
results,
the
results
look
very
different
when
the
negative
acknowledgement
channel
is
enabled
then
for
90
megabits
per
second
bandwidth
and
for
a
period
of
two
hours
that
we
did
our
testing.
There
were
no
loss,
packets
at
all
and
100
files.
A
hundred
percent
of
the
files
were
were
received,
so
these
are
very,
very,
very,
very
good
results.
We
also
tested
reception
at
full
stream
of
300
megabits
per
second,
and
it
was
possible.
However,
we
just
stopped
the
test
immediately.
B
Yeah,
by
the
way
for
those
interested
yeah,
that's
jake's,
jake
was
the
owner
of
this
github,
repo
jake,
holland
and
there's
a
question
from
stig
about.
Is
this
service
freely
available
to
private
end
users
with
amt
without
the
feedback
channel,
or
was
this
just
testing.
K
B
K
F
K
Do
for
the
other
for
for,
for
the
other
implementations
via
native
multicast,
vign,
and
so
on
and
yeah
at
the
moment,
we're
working
together
with
with
jin
to
see
if
we
can
enable
the
amt
gateways
on
the
and
on
the
border
on
the
border
routers
of
the
network,
because
they
also
have
juniper
equipment,
so
they
could
potentially
enable
that
if
they
see
but
but
first,
we
so
we're
working
with
them
to
see.
K
If
this
has,
if
this
can
have
some
some
effect
on
their
network
or
not
so
we're
still
in
the
in
the
lab
working
on
the
lab.
If
you
like,
okay,
so
this
just.
K
Oh
sorry,
I'm
almost
over
yes,
okay!
So
this
this
is
so
we
run
this
amt
on
our
wanted.
Distro,
and
you
see
the
this
is
the
test
capture
of
the
traffic
received.
So
a
next
slide.
Please-
and
this
is
the
last
one.
K
Basically
a
recap
of
the
predicted
ways,
so
we
have
one-to-many
distribution,
one
single
source,
which
is
highly
scalable
with
the
number
of
digital
data.
Our
cost
model
shows
that
this
is
solution
is
cost
effective
for
above
10
users.
We
have
at
the
moment
4
000
users
of
the
netcast
satellite
service.
So
in
the
future
we
might
be
migrating
many
of
those
users
from
satellite
terrestrial
high
availability.
K
Yes,
but
only
if
pro
protocol
reliability
is
implemented
yeah.
If
this
feedback
channel
is
enabled
work,
coverage
versus
satellite
footprint
only
and
we
can
handle
any
type
of
file
format
and
size.
K
However,
I
must
say
so
obviously
for
this
to
work.
It
requires
a
multicast
enabled
network
infrastructure,
and
we
know
internet
is
not
yet
multicast
ready.
It
requires
expertise
in
network
setup.
It's
not
straightforward
for
somebody
who
has
not
much
experience
with
this,
and
there
is
also
some
end
user
resistance
to
enable
native
multicast
on
the
network
and
as
already
mentioned,
there
is
a
risk
of
of
course,
impact.
That
is
if,
if
this
is
not
properly
handled,
users
with
bad
quality
links
can
impact
the
availability
and
timeliness
of
nominal
transmission.
B
I
have
a
question:
do
you
use
any
kind
of
access
control
encryption?
Anything
like
that.
K
Yeah,
so
we-
yes,
that's
a
very
good
question,
so
we
we
need
to
have
a
strong
authentication
and
encryption
for,
for
various
reasons.
First,
to
enforce
the
data
policy.
That
is
only
those
users
those
users
registered
and
allowed
to
receive.
Our
data
can
actually
do
so.
Then
there
is
also
the
data.
What
we
call
the
data
denial
service
for
certain
streams,
for
instance
all
the
for
for
some
some
instruments.
K
That
is
when
certain
data
need
to
be
made
available
only
to
a
subset
of
users,
for
instance
in
case
of
conflict
or
war,
and
yes,
we
do
have
authentication
and
encryption.
This
is
based
on
usb
token,
in
combination
with
username
and
password.
So
this
is
a
two
key
factor
system.
We
distribute
these
usb
tokens
to
the
end
users
and
they
can
only
unencrypt
our
data
if
the
eq
is
blocked
plugged
in
and
and
configured.
K
So
basically,
we
have
two
types
of
streams.
If
you
like
so
first
stream
is,
is
the
what
we
call
the
announcement
channel.
This
is
unencrypted,
and
that
means
that
any
user
can
listen
can
listen
to
this
channel.
This
channel,
however,
contains
all
the
information
on
on
the
data
channels.
At
what
time
did
they
start,
what
files
they
contain
and
so
on
and
so
forth,
and
then
these
data
channels
themselves
are
encrypted
and
only
users
with
with
a
functioning,
you
can
all
encrypt
that
data.
A
Jake
yeah
follow
up
on
that.
This
is
jake.
The
is
that,
like
once
the
file
is
completely
downloaded.
Then
you
can
only
unencrypt
it
when
you're
holding
the.
If
you
have
the
right
key
or
is
that
sort
of
like
as
you're
going
you're
able
to
get
the
bits
and
pieces.
K
That's
correct
so
first
the
file
is
completely
downloaded
and
then
it
checks
for
the
existence
and
of
these
eku
of
this
dongle
and
then,
if
that
is
granted,
then
the
file
is
encrypted
great.
J
Thanks,
I
just
wanted
to
ask
you
mentioned
obviously,
with
joan
from
the
under
ends.
You
can
run
natively
the
n
sites,
or
it
can
be.
Tunneled
is
the
case
for
tunneling,
usually
at
the
end
site
does
not
support
multicast
rather
than
the
neon
rings,
and
chart,
because
I
think
most
enrons
in
jail
to
support
multicast
natively,
just
like
they
support
v6
natively,
for
example,
is
it
usually
the
end
site
rather
than
the
end
range
just
for
clarity?
K
Yes,
but,
however,
I
must
say
that
gian
is
doing
an
excellent
work
on
that.
So
whenever
we
detect
that
or
we
have
an
end
user
located
on
an
end
run
that
is
not
multicast
enabled,
then
they
do
their
best
to
support
them
and
help
them
enable
it,
and
eventually
it
takes
some
time.
So
we
use
the
these
gre
tunnels
to
just
to
bridge
the
gap
that
might
take
from
you
know
a
few
weeks
to
a
few
months
on
until
that
end
and
then
start
supporting
multicast
natively.
So
it's.
J
Okay,
yeah,
I
mean
I
I'm,
I
believe
in
the
in
the
uk
example
with
the
ecwmf
sorry
ec
mwf
and
the
met
office
that
it's
those
sites
that
don't
have
multicast.
That
means
it
needs
to
be
terminal,
whereas
the
uk
and
rn
janet
does
support
multicast.
I
just
wonder
whether
that's
common
across
europe
or
or
not,
that's,
because.
K
It
varies
from
country
to
country,
that's
why
we
have
like
a
portfolio
of
services,
because
our
mission
is
to
make
the
you
want
to
get
the
content.
K
Exactly,
however,
we
always
try
to
we
encourage
the
users
to
use
native
multicast,
because
we
understand
that,
for
instance,
one
study
is
enabled
in
a
country,
for
instance,
the
case
of
I
know
any
new
countries
that
doesn't
have
native
multicast.
We
have
one
user
there
and
once
once
native
multicast
is
supported,
then
it
doesn't
matter
how
many
users
we
have
there
yeah
and
it
will
be
just
black
and
play
if
you
like.
J
K
Yes,
so,
satellite.
This
is
the
first
service
that
that
we
started
with
multicast.
It
started
like
15
years
ago,
and
we
have
at
the
moment
4
500
users,
then
for
the
terrestrial
service
native
multicast.
We
have
between
around
25
users
and
with
a
combination
of
all
the
rest
of
gre
tunnels
and
l2p
ipsec.
We
have
10
more
users.
K
However,
we
we're
in
the
in
kind
of
a
transition
phase
where
we
know
that
most
of
our
data
in
the
future
will
only
be
available
through
the
terrestrial
links
and
mainly
through
the
native
multicast.
So
we
are
encouraging
now
our
users
to
start
migrating
or
setting
up
their
stations
via
the
terrestrial
links
via
via
native
multicast.
B
K
Or
cdns,
okay,
yeah,
how
our
data
is
it's
very
dynamic.
We
only.
We
only
send
the
data
file
once
and
after
a
certain
period
of
time
it
has
expired,
has
no
no
much
more,
no
more
value
to
our
users.
K
Therefore,
the
concept
with
this
with
the
cdn-
I
don't
see
it
really
applicable
to
our
case,
because
I
understand
that
it
makes
sense
for
the
cdns
for
the
data,
this
data
replication
to
stay
on
those
for
longer
periods
of
time
like
if
you
like,
like
netflix,
for
instance,
but
for
our
case
I
don't
see
it
and
besides,
I
don't
know
the
cost
of
of
multicast
native,
because
our
terrestrial
link
is
so
low
compared
to
the
alternatives
that
I
think
that
from
the
cost
per
perspective,
I
don't
think
it
will
make
sense
either.
K
That's
my
so
we
maybe
I
can
share
a
little
more
on
the
cost
side,
so
we
have
done
some
evaluations
internally,
and
we
see
you
know.
K
K
However,
the
the
bandwidth,
the
satellite
capacity,
is
very
expensive.
That's
why
we're
migrating
to
similar
concept
of
disseminating
via
multicast,
but
over
terrestrial
links
with
it.
Has
this
also
this
fixed
cost,
regardless
of
the
number
of
users,
and
it's
probably
it's
around
one
magnitude,
one
order
of
magnitude
less
so
it's
quite
cost
efficient,
yeah,
great.
B
Yes,
well,
we
have
to
move
on
to
our
next
freezo,
but
this
this
was
great.
I
think
you
you
you're
putting
together
pretty
much.
You
know
every
bit
of
multicast
between
access
control,
encryption,
reliability
and
and
inner
domain
ssm.
K
Yeah
actually,
actually
this
amt
technology.
It
looks
very,
very
promising
for
our
for
our
case,
and
we
are
looking
forward
to
to
test
to
test
that
more
extensively,
so
maybe
I'll
get
back
to
some
of
you
for
some
support
at
some
point
I'll,
if
you
don't
mind
I'll
share
my
also
my
contacts
in
in
the
chat-
and
you
can
please
contact
me
if
you
have
any
further
questions.
A
Oh,
that
was
very
cool
good
to
hear
you're
getting
100
megabits
out
of
the
amt
yeah.
I
I
don't
think
I've
run
it
that
fast
yet,
and
it
wasn't
just
me
by
the
way.
I
think
I
put
it
up
in
its
current
sort
of
location
and
cleaned
it
up
a
bit,
but
this
was
this
working
group
actually
did
the
bulk
of
the
work
and
I
just
sort
of
got
it
got
it
running
again
so,
and
that
was
all
before
my
time
so
yeah
right.
A
I
think
I
will,
by
my
account
we
are
about
17
minutes
behind,
I
think,
and
so
I'm
going
to
try
and
be
really
fast,
because
I
really
want
to
hear
lorenzo's
presentation.
B
Yeah
so
jake
you
have
told,
can
you
can
you
take
it
to
the
bottom
of
the
hour,
5
30
your
time,
23
minutes.
I.
A
I
will
try
to
be
done
by
then
yeah,
all
right,
so
yeah,
I'm
jake,
I'm
working
on
these
four
drafts,
mostly
what
I'm
really
working
on
is
trying
to
make
the
deployment
more
plausible,
and
these
drafts
are
are
more
like
a
a
step
that
helps
me
do
that,
but
but
I
I
I
do
want
them
to
happen
so
yeah
next
slide.
Please
did
I
did
I
get
you
the
outline
in
time.
A
They
had
an
outline,
I
think,
there's
four
things:
I'm
going
to
cover
the
trial
status,
the
the
a
brief
overview
of
the
the
benefits
we're
seeing,
in
our
benefit
analysis,
modeling,
the
status
of
the
implementations
we
have
ongoing
and
some
the
updates
on
the
docs
and
their
sort
of
current
status
and
and
the
next
steps
we're
looking
at
so
the
the
first
thing
is
the
trial
status,
so
the
we've
hooked
up
with
six
isps
that
are
working
with
our
ingest
platform.
A
That
includes
the
amt
gateway
and
the
dryad
based
sort
of
look
up
to
drive
it
based
on
a
a
presented
about
that
before.
So
I'm
not
gonna.
Go
over
it
now
the
traffic
we're
running.
We
have
a
couple
different
pieces
there's,
so
we've
got
some
of
our
own
test
traffic,
but
we
also
have
some
production
traffic
from
several
different
content
providers.
That
are,
I
think,
I
think,
they're
customers
of
ours.
A
I
assume
and
they're
geo
located
with
the
relevant
isps
to
sort
of
prove
out
the
the
notion
of
distributing
some
of
the
local
content
with
multicast
ingested
sort
of
in
the
over-the-top
method
into
the
isps
and
then
distributed
within
the
isps
virgin
media.
You
know
shout
out
to
loba
and
neil
and
harry
thanks
for
the
feedback.
A
The
other
partners
we've
got
have
not
yet
given
permission
to
use
their
name,
so
we're
respecting
that
most
of
the
trials
are
still
active
and
people
are
still
messing
with
the
with
the
setups.
A
few
of
them
have
not
yet
started
so
the
six
only
refers
to
the
ones
that
that
we've
got
actually
some
level
of
work
has
actually
begun
in
those
isps.
A
B
And
jake,
did
you
say
you
had
newer,
slides,
I'm
sorry
I
might
not
have.
I
might
have
missed
those.
A
Sorry,
my
bad
and
just
realizing,
I
had
left
out
the
outline
so
there's
a
few
key
insights,
we've
gotten
from
the
trials
one.
Is
that
consistently
some
of
the
feedback
we're
getting
from
usps,
and
this
includes
not
just
the
ones
that
have
participated
in
the
trials,
but
some
that
we've
talked
to
that
are
have
not
participated
yet
or
that,
don't
you
know,
don't
believe
us.
Yet
the
game
downloads
are
a
big
part
of
why
they're
interested
right
now.
A
This
is
a
one
of
the
key
pain
points
that
people
are
experiencing.
So
it's
not
just
about
delivering
video
and
real-time
stuff.
It's
also
about
just
getting
a
better
job
done
on
the
you
know
the
peak
offloads
another.
Is
that
mnat
it
maybe
I
shouldn't
say
m
not,
but
rather
the
problems
that
mnat
can
work
around
were
more
prevalent
than
we
expected
of
the
of
the
six
that
have
started.
One
of
them
has
like
proven
it
out
without
needing
any
mnat
two
of
them.
A
We
didn't
think
we
were
going
to
need
m-nap,
but
it
turned
out.
We
did,
and
it
was
a
good
thing
that
we
had
a
a
build
sort
of
almost
running
by
then
and
the
fourth
one.
We
knew
from
the
front
that
we
were
going
to
need
mnat
and
then
there's
two
that
we
haven't.
We
haven't
yet
gotten
them
working
yet
so
we
aren't
totally
sure
yet
whether
it's
going
to
be
necessary
or
not.
A
But
this
was
I
mean
it's
a
small
sample
size,
but
it's
relatively
high
like
some
of
the
the
issues
it
encountered.
I
I
think
there
might
be
one
more.
I
need
to
add
to
the
motivation
section
of
the
I'm
not
draft,
but
mostly
they're,
in
line
with
the
things
we've
seen
there.
A
It
was
basically
like
their
tv
service
was
only
using
asm
and
so
their
home
gateways
did
support
multicast,
but
only
igmp
v2,
and
although
they
think
they
can
upgrade
that
with
the
firmware
at
some
point
and
they
do
sort
of
manage
the
home
gateways,
it's
going
to
that's
a
whole
update
cycle.
That's
going
to
take
a
while
and
they
were
able
to
proceed
by
using
mnat
all
the
way
south
of
the
home
gateway
with
the
egress.
A
So
we're
looking
into
I'll
get
to
that
in
the
in
the
browser
update,
but
the
overall
answer
is
that
we
are
it's
looking
like
cautious
optimism
is
about
the
right
way
to
look
at
this.
We
haven't
hit
any
stoppers
yet
and
we're
we're
thinking
that
this
is.
This
is
going
to
be
plausible
and
pretty
good,
based
on
the
sort
of
feedback
that
we're
getting
so
yeah
good.
It
is
pretty
slow
right
now.
A
The
implementations
are
are
a
bit
crappy
of
the
prototype
stuff,
so
that's
gonna
that
might
impact
the
drafts.
Also
so
yeah
next
slide
and
I
think
we're
into
the
yeah
the
benefit
analysis
I'll
be
real,
quick
on
this.
So
the
the
this
is
a
work
in
progress,
and
I
just
wanted
to
give
a
quick
preview,
but
the
the
basic
idea
is:
there's
a
bunch
of
the
traffic
that
we're
actually
sending
according
to
our
logs
and
our
stats
of
whatever.
A
So
this
is
a
snapshot
of
like
one
isp
on
one
normal
day,
so
nothing
special
here,
there's
a
bunch
of
the
traffic
that
we
haven't
like
managed
to
pin
down
like
how
would
we
multicast
it
or
not?
And
it's
less
that
we
think
it's
not
multicastable,
then
that
there's
details
of
of
doing
the
log
analysis
that
we
haven't
got
to
yet.
So,
although
we
think
that
some
of
it
will
remain
as
probably
not
multicastable
in
a
broader
sense,
it's
not
quite
as
big
as
what
that
blue
represents.
A
But
the
green
part
is
the
part
that
we
have
analyzed
and
the
dark
green
part
is
the
part
we
think
we
can
chop
off
based
on
what
we've
got.
So
if
you
go
to
the
next
slide,
that
brings
into
the
the
green
bit
there
and
we're
from
this
part
with
conservative
estimates
we're
seeing
about.
We
think
that
an
eight
percent
of
the
total
traffic
into
the
isp
is
a
lower
bound
on
what
we
think
we
can
offload
and
we
think
it's
going
to
get
better
as
we
go
forward.
A
So
this
is
part
of
why
we
think
it's
as
we
get
sort
of
more
of
this
analysis
done.
So
this
is
part
of
why
we
think
it's
it's
going
to
be
feasible
here
and
we're
seeing
a
sort
of
long
tail
effect.
Where
you
know
the
the
these
colors
here
are
are
different
levels
and
they're
they're
in
the
top
left
of
the
chart
there.
It's
like
that
first
block
is,
if
you
just
had
one
object
that
was
being
multicasted,
then
that's
how
much
you'd
be
able
to
offload
of
the
traffic.
A
If
you
take
the
top
object
that
we
think
we
can,
if
you
take
another
five
objects
and
that's
the
next
block
and
then
it
goes
to
10
and
then
20
and
50,
you
can
see
there's
sort
of
a
diminishing
return,
but
again
those
numbers
should
get
somewhat
bigger
when
we
get
when
we
get
access
to
more
objects
in
there.
A
So
this
is
the
sort
of
direction
we're
going
with
how
we're
looking
at
the
analysis
and
what
we're
hoping
to
achieve-
and
it's
it's
mostly
about
shaving
off
the
peak-
is
the
is
the
big
driver
for
the
isp.
So
that's
where
we're
looking
to
sort
of
capture
the
most
value
on
that
side
of
it,
and
this
is
also
an
important
consideration
on
our
side,
although
we're
not
sure
that
this
style
of
modeling
really
captures
the
whole
thing,
because
it's
based
it's
based.
A
Only
on
what
we're
actually
doing
today,
not
covering
necessarily
all
the
potential
improvements,
as
we
shift
more
things
to
be
able
to
use
this,
so
so
looking
at
this
as
a
lower
bound
on
what
we
think
we
can
achieve
is.
Is
it's
a
good
start,
but
there's
a
lot
more
to
do
on
this,
so
don't
take
it
as
as
any
kind
of
final
yeah
next
slide.
Unless
there's
any
hang.
F
On
jake,
I
had
a
question
for
the
slide
right.
This
is
greg.
Can
we
go
back
to
the
previous
line,
so
I
can
talk
when
it
comes
up
there.
We
go.
Is
this
based
on
just
download
traffic
or
you're,
looking
at
your
entire
traffic
profile?
That
could
be.
A
Offloaded
so
the
blue
chart
in
the
one
before
that
is
based
on
the
entire
traffic
profile
of
everything
we
sent
into
the
isp,
okay,
grand
total
and
and
which
is
and
that
that
only
counts
download.
A
F
A
Oh
this
part,
I
think
so
on
some
of
the
analyses
we've
done
we're
trying
to
get
to
where
we
merged
them,
and
it's
not
quite
done
yet.
I
think
this
one
covers
mostly
things
that
we
think
would
be
achievable
game
downloads,
I'm
not
sure
whether
we
got
any
live
content
in
this
one
or
not.
The
live
ones
are
more
interesting.
So
far,
we've
seen
on
the
big
peak
days
with
a
with
a
popular
sporting
event
right
and
so
yeah.
A
That
is
not
one
of
these
days
and
that's
not
part
of
this
analysis.
This
is
more
like
just.
This
is
like
a
normal
tuesday,
where
there's
some
game
documents
or
something
that.
A
Right
now,
the
mother's
day,
events,
we
know
it's
going
to
be
a
lot
bigger.
We
and
again,
this
analysis
is
not
quite
complete,
actually
are
clusters
having
trouble,
which
is
why
I
don't
have
more
of
these
charts
but
yeah
the
next
one,
I'm
hoping
will
have
some
more
interesting
numbers.
A
Quick
snapshot
of
what
we've
got
here
and
actually
and
showed
that
even
even
a
very
sort
of
pessimistic
view
of
this
is
it's
hard
to
say
that
that
it's
not
going
to
be
profitable,
so
we're
we
really
do
want
to
look
into
how
to
make
that
happen.
Yeah
next
slide.
A
Right
so
the
chromium
upstream
is
currently
stalled
and
kind
of
in
negotiations,
we're
trying
to
get
through
process
hurdles
and
and
kind
of
get
the
security
review.
We
need
to
be
able
to
check
the
the
early
stuff
in
so
that
we
don't
have
to
carry
the
fork
that
kind
of
fell
through
so
we're
gonna
plan
to
carry
a
fork
until
we
can
sort
it
out
and
we'll
be
releasing
or
at
least
building
regular
updates.
I
think
we'll
be
releasing
them.
A
That's
the
intent
to
just
put
up
a
binary
that
we'd
built
automatically
with
the
regular
dev
updates,
plus
plus
one
from
the
stable.
I
think-
and
that's
so
that's
ongoing,
we'll
try
to
get
it
sorted
out.
We
would
still
like
to
get
into
chromium
if
we
had
more
public
web
developer
support.
A
That
would
be
helpful.
So
if
you
know
anybody
who
wants
this
stuff
in
the
as
a
web
api,
then
you
know
get
them
to
speak
up.
I
was
able
to
cite
several
people
who
had
contributed
such
statements.
So
thanks
to
those
that
that
included,
morton
peterson
martin
peterson's
comment
about
it.
Guyan
mishra's
comment
about
the
way
verizon's
using
stuff
and
and
the
bbc's
hackathon
from
some
time
ago,
where
they
did.
A
They
did
a
multicast
video
to
the
browser
demo,
but
it
required
using
websockets
unicast
to
a
local
gateway
that
actually
did
the
multicast
received,
which
I'm
I
I
assume
that
they
would
have
preferred
to
have
a
browser
api.
A
So
the
other
thing
is
that
we
think
ambi
is
more
important
to
the
end
user,
particularly
the
browser,
the
ambi
being
the
the
authentication
spec.
That
is
that's
in
our
the
asymmetric
authentication
right,
yes,
and
but
we
think
we're
gonna
put
the
m-net
egress
behavior
into
the
browser
api
before
we'll
get
the
envy
in
there,
because
it's
the
way
we're
doing
it
now
for
the
m.
A
Not
egress
is
sort
of
emulating
an
operating
system,
embedded
version
of
the
egress
so
that
you
don't
have
to
have
a
separate
box
south
of
the
home
gateway
where
the
where
some
of
the
problems
are.
So
it's
like
running
in
the
receiver
as
an
external
thing,
and
that
thing
is
is
kind
of
a
problem.
A
So
if
it's,
if
it's
embedded
in
the
browser
api,
then
it
should
be
able
to
receive
the
the
added
version
of
the
of
the
traffic
authenticate
it
as
though
it
was
global
and
pass
it
to
the
web
api
that
only
everyone
had
to
know
about
the
global
stuff.
So
that's
what
we're
trying
to
put
in
first,
it's
also
easier
to
do
and
can
help
us
with
some
of
the
prerequisites
that
we're
going
to
need
for
ambi
as
well.
So
yeah
next
slide.
A
Please
the
m-net
implementation,
it's
running!
It's
not
great!
It's
it's
polling!
Right
now
and-
and
we
might
have
to
look
at
at
this
also
plus
the
dorms-
we
might
have
to
look
at
updating
the
specs
to
support
a
long
pole,
sort
of
path
for
receiving
updates,
because
it's
like
the
jet
conf
implementation
for
rest
comp
doesn't
have
the
push
easily
built
in
I'm,
not
sure
if
we
can
make
it
happen,
and
so
I'm
looking
into
how
to
how
to
do
that.
A
But
that
that'll
be
ongoing.
The
slowness
is
because,
because
it's
doing
like
a
10
second
pull
and
we're
gonna
have
to
do
a
little
better
than
that.
Probably
well,
we
might
have
to
do
a
little
better
than
that
like
for
our
purposes.
This
is
actually
kind
of
okay,
because
we
run
with
unicast
for
a
while
and
then
like
once,
the
multicast
starts
working.
We
just
start
using
it,
but
I'm
not
sure
that'll
really
be
okay
for
everybody.
A
That
wants
to
do
multicast
development
in
the
web
browser
anyway,
and
that
is,
is
running
in
three
of
our
trial
partner
labs
and
using
it.
We've
got
ip6
support,
but
only
so
far
for
local
sg
assignments,
not
yet
for
global
sgs.
That's
basically
because
one
of
our
trial
partners
needed
that
and
we
haven't
needed
it
yet
for
the
global
sg.
But
we
would
like
to
get
that
in
there
too.
Yeah
next
slide.
Please.
A
The
ingest
platform
implementation
cleaned
up
a
bit
and
componentized
some
of
the
pieces,
so
I'd
be
happy
to
get
into
more
details
with
anybody
who
wants
to
know
more
about
that,
but
the
ingest
platform
is
sort
of
key
to
the
making
it
easy
for
isps
to
to
perform
the
actual
ingest
of
traffic
from
outside
and
and
redistribute
it
as
native
multicast
inside
so
yeah.
But
we
also
added
a
see
back
thing.
I
think
I
sent
something
in
the
list
about
it
too.
A
A
Next
right,
so
dorms
and
see
back
early
review
request,
sent
I'm
hoping
to
get
some
good
feedback
there.
I
might
there
was
a
couple
updates
to
see
back
and
there's
a
couple
updates.
We
probably
are
going
to
want
to
make
also
the
priority
concept.
I'm
not
sure
is
really
good.
The.
A
A
A
A
So
so
I
think
we're
going
to
do
some
experiments
on
that
and
and
see
if
I
can
get
something
working
but
right
now,
it's
anything
that's
using
it
is
just
polling,
so
it
I'm
not
sure
how
that
that'll
be
enough,
especially
with
regard
to
speed
of
updates.
As
we
go
forward,
it
could
be
done
as
a
later
rev.
A
So
if
we
need
to
then
then
I
could
get
the
dock
pushed
earlier
than
that,
but
yeah,
I'm
not
I'm
not
sure,
it's
quite
good
enough
as
it
stands.
It
could
use
more
review
and
engagement
from
people
messing
with
it
feedback
about
it.
But
anyway,
I'm
working
on
these
but
they've
taken
a
backseat
to
to
the
work
with
the
isps
and
trying
to
get
this
deploy,
bowl
and
and
maybe
even
deployed
in
places.
A
So
I
I
feel,
like
the
progress
has
looked
slow
on
these
docks,
but
but
there's
a
lot
of
behind
the
scenes
stuff
happening
so
yeah
next
slide.
Please
jake.
B
In
terms
of
review,
you
know
with
four
drafts
which
would
you
say
is
you
know
if
people
were
to
prioritize
which
one
should
they,
you
know,
help
with
review
which
which
docs
would
you
say,
are
mostly
important
or
are
they
all
equally.
A
Like
would
I
actually
equally
important
yeah,
so
what
I
actually
care
the
most
about
is
whether
it's
really
going
to
work.
So
what
I'd
love
to
see
is
more
people
experimenting
with
the
actual
implementation
and
seeing,
if
there's
and
it's
it's
really
like,
if
there's
parts
of
the
implementation
that
won't
be
adequate
for
people,
then
that's
where
I'd
like
to
see.
A
There's
things
we
can
fix
in
the
implementation,
then
great
fix
them
in
the
implementation,
but
if
it
requires
a
spec
change,
that's
the
part
that
I'm
worried
about
like
if
we
make
this
rfc
and
then
it's
like
not
quite
good
enough,
then
you
know
either
we
have
to
rev
it
or
like
it
makes
it
a
little
more
noisy.
A
I
feel
like
and
and
less
likely
to
succeed,
so
the
the
biggest
problems
I
see
right
now
are
the
sort
of
slowness
of
the
update
of
changes,
and
so
I'm
curious
like
how
much
do
people
care
and
how
bad
is
it
and
like
what?
What
sort
of
join
time
do
you
need
to
succeed?
A
I'm
not
sure
join
time
is
the
only
consideration
there,
but
but
it's
probably
one
of
the
big
ones,
and
then
also
things
like
see
back
like
how
variable
is
your
maximum
bit
rate,
and
can
you
like
put
a
cap
on
the
maximum
bit
rate
and
handle
it
like?
Is
this
actually
going
to
work
for
other
people
who
need
to
use
it?
These
kinds
of
questions
I
think
are
are
are
where
I
have
the
most
concerns
right
now,
I'm
you
know
like
I'm,
making
them
work
for
me.
That's
great!
A
You
guys
want
to
send
it
through
okay,
but
I'm
not
sure
it
will
really
meet
my
needs
if,
if
it,
if
it
sort
of,
gets
adopted
and
turns
into
a
spec,
but
more
people,
don't
use
it
than
just
me
right.
So
I
think
it
needs
to
actually
be
usable
for
more
people,
not
just
like
look
usable
right
right.
A
So
did
that
answer
your
question
and
yes,
one
minute
left
so
next
steps.
A
I
want
to
take
the
trials
public
make
it
so
that
people
can
sort
of
self-serve
and
set
it
up
and
have
all
the
pieces
they
need
to
to
run
things,
including
the
browser
testing
and
a
video
stream
to
use
it
with
I'd
like
to
in
you
know,
supporting
people
who
are
trying
to
do
it,
maybe
make
a
little
community
with
a
mailing
list
and
a
website
or
something
anybody
who
wants
to
join
me
in
in
trying
to
make
that
work.
A
Please
reach
out
I'd
like
I
love
to
talk
about
it.
I
don't
think
this
needs
to
be
a
sort
of
aqua.
A
My
internal
effort
only
and
I
I
also
would
like
to
try
doing
native
delivery
on
i2,
where
they
have
i2
and
also
giant
that,
like
i2,
is
the
only
one
I
knew
about,
but
if
gian
is
also
doing
native
multicast,
then
yeah,
let's,
let's
get
a
an
ingest
platform
set
up
and
and
running
in
there
and
see
if
we
can
get
the
traffic
delivered
to
those
who
can
who
can
receive
it.
A
Natively
other
contacts,
I
think,
would
would
also
be
great
like
we're
trying
to
sort
of
widen
these
trials
and
I
think
any
place.
That's
willing
to
forward
native
multicast
is
a
good
candidate
to
to
talk
about
it
with,
and
I
want
to
get
the
the
file
delivery
sort
of
better
done.
A
One
idea
I've
got
is
to
to
try
extending
apt
the
the
ubuntu
package
delivery
system
like
if
we
can
make
it
so
that
that's
sort
of
auto
updating,
with
with
the
most
popular
downloaded
downloads
and
packages
and
they're
available
over
multicast,
and
maybe
trying
to
do
it.
A
That
might
be
a
really
interesting
path
to
sort
of
get
some
useful
traffic
that
doesn't
have
to
be
gated
on
on
a
company
buying
in
so
I'm
I'm
gonna
see
if
I
can
do
any
looking
into
that
and
and
see
sort
of
what
hurdles
I
run
into
like
right
now,
the
the
like
raptor
implementation,
there's
some
distribution
limits
on
it.
A
So
I
need
to
sort
of
figure
out
what
I
can
do
to
solve
that,
but
I
would
like
to
get
to
make
sure
that
the
file
download
use
case
actually
works,
because
that's
one
of
the
big
drivers
for
the
isps
and
the
other
thing
is
to
engage
some
big
game
delivery
partners,
because
because
that
also
is
we're
talking
to
them.
A
But
we
don't
have
we're
not
as
far
along
as
I'd
like
to
be
on
that
and
we
either
got
to
get
into
chromium
or
or
start
doing
this
work
in
a
different
browser.
We
had
some
interest
in
doing
things
in
rust
from
a
couple
of
of
student
researchers,
so
actually
I
would
love
to
end
up
doing
it
in
both
and
in
more
browsers.
But
you
know
chromium
is
sort
of
the
more
widely
distributed
one.
So
far,
so
I
was
starting
there,
but
I'm
not
too
hung
up
on
it.
A
So
if
we
can't
get
into
the
upstream
on
that,
then
we
might
want
to
look
into
somewhere
else,
but
I'm
still
hopeful
that
we'll
get
into
everywhere,
ultimately
yeah
and
I'd
like
to
get
dorms.
But
I
want
to
make
sure
that
push
updates
are
feasible.
I
think
dorms
is
the
closest
to
done
in
terms
of
the
spec,
but
see
back
is
probably
not
too
far
behind,
but
I
think
needs
a
little
more
work
on
the
on
the
circuit.
A
Breaker
behavior
part
and
my
biggest
concern
on
dorms
is
really
just
the
push
updates.
So
I
think
that's
all
I've
got
any
questions.
I'm
sorry,
I'm
two
minutes
late.
F
Yeah,
can
I
throw
just
a
couple
at
you,
quick
jake,
you
mentioned
this
in
beer
a
bit
about
working
with
web
rtc
or
you
know
webrc,
and
I
was
wondering,
if
is
it-
is
the
expectation
that
they
would
just
be
able
to
use
the
browser
plugin
or
do
you
think,
there's.
A
Actually
so
webrc
being
the
the
congestion
control
strategy
recommended
by
flute,
I'm
not
sure
everybody's
familiar
with
right,
so
webrtc
is
a
different
thing
from
webrc
yeah,
so
the
flute
spec
requires
the
use
of
webrc
and
it's
the
it's
only
experimental,
but
it's
required
to
implement
a
part
of
flute
as
written
and
I'm
not
sure
it's
actually
good
enough.
It's
like
kind
of
a
weird
waveform
equation
based
receiver,
driven
congestion
control
or
something
and
the
that
doesn't
match
the
actual
pattern.
A
Traffics
of
the
the
the
actual
traffic
pattern
of
anybody
who's
sending
multicast
that
I
know
of
including
ourselves.
This
sort
of
idea
that
you
can
send
at
a
rate
and
then
have
it,
have
it
decay
and
then
by
decaying
you're,
gonna.
A
Going
delay
to
determine
what
the
congestion
rate
is,
I
don't
think
it
actually
works
and
nobody
who's
using
multicast
seems
to
be
doing
it.
So
I
think
it
might
need
an
update
if
it's
to
be
a
sort
of
fully
rfc
compliant
thing
and
the,
and
that
is,
is
in
some
sense
important,
because
the
raptor
ipr
restrictions
are
tied
to
fully
full
rfc
compliance.
F
A
I
don't
have
one
I
just
have
the
chromium.
I
have
the
old
chromium
built
for
mac.
I
would
like
to
do
that
working
too
and
the
the
dead
for
ubuntu
or
the
binaries
for
any
linux.
I
think
yeah,
if
you,
if
you
want
I'd,
be
happy
to
give
you
the
source.
It's
it's
right.
There
I'd
be
happy
to
help
you
get
it
running
all
right.
If
you
have
the
target
that
you're
interested
in
sure
thanks.
B
And
thanks
jake
and
in
terms
of
your
you
know,
question
about,
and
you
know
other
multicast
enabled
networks.
I
bet
that
tim
shown
would
probably
be
the
expert
in
this
group
on
the
rens
and
he
could
probably
direct
you
I'll
volunteer
him
as
probably
the
one
who
could
give
you
the
best
guidance
as
to
who
else
is
out
there.
That
is
multicast,
enabled.
B
B
A
Yeah
we're
looking
to
start
sending
traffic
to
more
public
people,
and
so
we'd
like
to
we'd
like
to
hook
up
with
those
who
are
doing
it
and
and
start
getting
traffic
enabled
in
there.
So
I'll
reach
out
to
you
and
and
thanks
for.
J
A
Yeah
we
we
are
trying
to
get
to
the
point
where
we
can
spin
up
some
production
traffic,
we're
not
right.
Now,
it's
it's
still
a
bit
sort
of
r
d-ish
and
we're
not
in
a
position
to
be
doing
like
slas.
So
our
customers
are
a
little
like
they're,
not
necessarily
unwilling,
but
they
don't
want
to
be
relying
on
it.
This
kind
of
thing
so,
but
yeah
we'd
we'd
love
to
get
some
people
using
it,
especially
I
think
in
the
research
community.
A
It
would
be
a
really
good
fit
and
and
so
like
traffic,
that
they're
trying
to
get
and
when
they're
connected
on
these
nrn
networks,
if
they,
if
if
it
was
easy
for
them,
for
example,
with
an
apt
update
and
maybe
if
there
was
some
some
content,
that
was
interesting
for
them
to
to
put
into
a
browser,
readable
thing.
It
seems,
like
that's
a
good
place
to
start
to
get
some
real
traffic
going,
but
yeah.
B
So
we're
gonna
have
to
move
cut
off,
but
thanks
jake
and
everybody
please
do
reach
out
to
him
and
review
of
the
drafts
would
be
most
helpful.
B
So
with
that
lorenzo
you're
up
and
you
can
take
us
home,
you
have
until
the
rest
of
the
end
of
the
meeting
and
since
you're
kind
of
in
charge
of
need
echo,
I'm
sure
you
could
buy
us
even
extra
time.
So
you
have
as
much
time
as
you're
willing
to
give.
I
H
I
Yes,
I
do
okay,
so
first
of
all,
thanks
for
for
the
opportunity,
it's
a
really
it's
a
real
honor
for
me
to
to
be
here
especially
to
to
speak
to
to
such
skilled
people
in
in
a
technology
that
I'm,
admittedly
less
knowledgeable
about
so
I'll,
try
to
explain
a
bit
how
we
actually
use
or
try
to
use
multicast
in
our
own
deployments,
especially
for
the
purpose
of
scaling,
webrtc
deployments
and
as
you'll
see
during
the
presentation.
I
This
will
mostly
cover
how
we
do
this,
basically
in
an
intro
domain,
so
from
a
server-side
perspective
on
how
to
scale
things
that
we
then
use
unicast
for,
and
so
it
may
be
possibly
a
bit
boring
for
you,
but
hopefully
you'll
find
some
some
interesting
things
in
there
as
well,
towards
the
end
of
the
presentation
and
before
I
can
actually
explain
how
we
do
that.
I
I
I
first
have
to
to
introduce
the
the
janus
webrtc
server,
but
basically
janus
is
a
component
that
that
I
brought
a
few
years
ago
for
for
our
own
purposes
and
is
an
open
source
webrtc
server,
which
we
conceived
as
general
purpose,
meaning
that
it
can
be
extended
to
do
several
different
things
and
I'll
cover
some
of
these
things
later
on
in
this
presentation
as
well,
and
basically,
this
open
source
component
is
what
we
build
everything
upon.
So
even
this
conversation
that
we
are
having
right
now
is
actually
being
powered
by
janus
right
now.
I
So
all
of
the
audio
video
slide
stream
that
you
are
seeing
are
coming
and
going
through
journals
right
now,
and
these
are
a
few
links
if
you
want
to
experiment
with
it
yourself
a
bit
after
this
presentation
and
just
to
give
you
a
bit
the
idea
of
the
different
bricks
that
we
use
to
then
make
all
of
this
possible.
I
mentioned
modularity
and
modularity
means
that
we
have
different
plugins
that
can
actually
do
different
things.
So,
for
instance,
we
have
the
audiobridge
plugin.
I
That
is
basically
an
audio
mixer
that
allows
us
to
receive
multiple
audio
contributions,
mix
them
all
together
and
then
send
a
mix
back
to
each
of
the
active
participants,
and
so
basically,
your
your
traditional
audio
conference,
but
webrtc
compliant.
If
you
will-
and
we
have
a
different
approach
for
video
typically
instead,
where
you
can
use
the
video
room
plugin,
which
is
what
is
typically
called
in
the
webrtc
lingo
and
sfus
selective
forwarding
unit-
and
in
this
case
video
is
not
mixed.
I
K
I
That's
true
as
well
anytime,
more
people
get
the
wrong
video
and
start
interacting
with
each
other
and
so
on
and
so
forth.
I
And
then
we
have
a
third
important
plugin,
possibly
the
most
important
plugin,
for
the
purpose
of
this
very
presentation,
which
is
the
streaming
plugin
which
in
a
nutshell,
acts
as
a
very
simple
rebroadcaster
of
plain
rtp
streams.
And
so
I
don't
know
how
many
are
you
are
familiar
with
rtp
in
the
first
in
the
first
place.
So
I,
of
course
I
won't
delve
too
much
into
details
of
this,
and
you
don't
really
need
to
be
that
familiar
with
it.
But
just
to
to
give
you
an
idea.
I
Rtp
is
the
protocol
that
is
used
to
transport
in
real
time,
audio
and
video
frames
over
the
internet
and
it's
at
the
very
basis
of
webrtc
as
a
technology.
And
so
basically
you
can
see
a
stream
of
rtp
packets
being
a
stream
of
packetized,
audio
and
video
frames
that
are
then
distributed
over
the
internet.
And
in
this
case
the
streaming
plugin
makes
it
very
easy
to
receive
a
plain
artist,
rtp
stream
and
then
turn
this
into
a
broadcast.
I
That
can
actually
generate
rtp
streams
that
can
be
consumed
in
different
ways,
which
means
that
if
we
have
ways
to
generate
a
plain
okay
stream
and
get
it
to
janus,
then
we
can
make
it
available
via
webrtc
to
two
one
or
one
hundred
or
one
thousand
participants
via
webrtc.
Just
by
doing
this,
this
simple
trick
so
using
the
streaming,
plugin
and
I'll
exactly
explain
later.
I
This
is
actually
one
of
the
key
blocks
that
actually
makes
it
all
possible
and
one
of
the
key
components
that
is
also
important
for
the
multicast
aspect
that
I'll
go
in
in
the
minutes
before
going
there.
I
just
wanted
to
spend
a
few
words
on
how
we
did
itf
meetings
before
the
pandemic
started.
So,
as
you
may
remember,
we
whenever
you
went
in
a
in
a
room
wherever
the
itf
venue
was
you.
I
You
saw
that
we
had
a
camera
placed
somewhere,
that
we
were
duplicating
the
the
beamer
feed
and
so
on
and
so
forth,
and
we
were
doing
this
so
that
we
had
basically
a
small
raspberry
pi
in
the
room
that
would
capture
both
of
these
sources.
I
The
camera
in
the
room
focused
on
the
chair
on
the
speaker
and
the
video
being
duplicated
from
the
projector
would
capture
these
and
then
we'll
broadcast
this
via
plain
rtp
to
a
generous
instance,
and
in
this
case
you
can
see
how
the
streaming
plugin
becomes
an
important
component
here,
because
we
are
taking
basically
something
that
knows
nothing
about
webrtc
like
this
static
camera
and
this
video
and
this
projector
splitter.
I
So
they
didn't
really
need
to
know
that
the
source
of
those
components
were
not
rtc
rtp
and
we're
actually
using
multicast
a
lot
in
this
specific
context,
because
in
this
case-
and
it's
clear
from
this
other
picture-
probably
basically
the
the
rtp
address
that
we
were
using
to
broadcast
these
rtp
streams
too
was
actually
a
multicast
address.
I
And
this
was
important,
for
instance,
when
at
the
moment
we
had
to
start
supporting
youtube
streaming
as
well.
So
just
make
a
simple
example
for
the
plenary.
We
have.
We
give
the
usual
access
that
you
see
right
now
as
well,
but
we
also
allow
people
to
watch
the
plenary
via
youtube
as
well
and
in
order
to
make
this
possible,
we
had,
of
course,
to
to
make
these
streams
available
not
only
to
janus
but
also
to
another
component
that
could
then
act
as
the
video
mixer.
I
That
would
then
broadcast
the
video
to
youtube
eventually
and
I'll-
spend
a
few
words
on
this
as
well
later,
but
very
very
basically.
This
would
allow
us
to
only
send
the
stream
once
to
a
to
a
specific
multicast
address
group
and
then
different
components
interested
in
the
video
feeds
from
those
specific
cameras
could
then
basically
just
subscribe
to
the
group
that
they
were
interested
in,
and
so
it
made
the
whole
process
of
orchestration
and
management
of
the
different
resources
that
we
had
much
easier
in.
I
In
this
context,
and
of
course
I
mean
this
worked,
and
we
were
quite
happy
with
this.
But
then,
as
you
all
know,
I
mean
pandemic
hits
and
then
we
had
to
stop
meeting
in
person,
which
meant
that
we
had
to
find
a
way
to
basically
bring
the
the
conversation
that
we
are
having
in
a
hybrid
approach,
completely
virtual.
Instead,
which
was
the
the
main
topic
of
a
presentation
that
I
did
in
the
most
working
group
at
the
last
itf,
and
here
is
the
link
to
the
to
the
full
video.
I
If
you
will,
if
you
want
to
hear
a
bit
more
about
it,
I'll
give
a
very
quick
recap
of
what
was
there
just
to
give
you
the
the
important
the
important
bits
that
are
needed
in
order
to
figure
out
the
way
that
we
use
that
we
can
use
multicast.
In
this
context.
I
First
of
all,
I'm
bringing
the
audio
bridge
here
again
by
audio
bridge.
If
you
remember
from
episodes
ago,
is
the
component
that
can
act
as
a
audio
mixer
for
the
different
streams
and
an
interesting
feature
that
we
added
to
this
study
was
the
ability
to
basically
forward
externally
the
current
mix
that
was
being
generated
in
a
room
via
plane,
rtp
to
a
separate
component
and
we'll
see
in
a
minute
why
this
is
important
and
same
thing
for
the
video
room.
I
So
if
we
have,
if
I
am
sending
my
own
video
stream
to
a
janus
instance,
so
that
other
participants,
for
instance,
you
can
receive
it
in
a
browser.
At
the
same
time,
I
can
also
instruct
the
genes
instance
to
relay
this
my
video
feed
as
a
plain
rtp
stream
to
a
different
address
instead,
so
that
it
can
be
used
or
consumed
in
different
ways.
I
So
you
actually
only
need
webrtc
to
receive
the
video
from
the
participant
in
this
case
me
from
a
browser,
for
instance,
but
then
how
you
distribute
this
video
internally
on
your
own
network.
How
you
found
out
is
completely
and
entirely
up
to
you
and
using
features
like
the
rtp
forwarding
that
I
just
described
makes
it
very
easy
to
then
use
components
that
are
completely
webrtc
unaware
for
the
job
or
even
multicast
networks,
as
we'll
see
in
a
second.
I
And
then
in
this
case
they
can
all
serve
their
own
independent
users
and,
of
course,
I'm
I'm
using
different
colors
here,
meaning
that
I
could
actually
inject
different
streams
rather
than
just
one
using
the
same
distribution
technology
that
I
have
at
my
disposal
and
so
used
within
the
context
of
the
itf,
for
instance,
how
we
are
using
it
here.
It
works
pretty
much
like
this.
I
So
for
the
audio
part,
as
I
was
mentioning,
all
the
audio
streams
are
actually
mixed
in
these
in
this
platform,
and
so
it
means
that
the
active
participants
are
actually
contributing
to
the
audio
bridge
plug-in,
so
they
are
being
mixed.
I
So
you
need
to
do
the
same
approach
for
each
video
that
is
injected
in
the
platform,
so
basically
treating
each
video
stream
as
a
separate
broadcast,
which
means
that
again,
we
can
just
rtp
forward
this
stream,
two
different
generous
instances
and
streaming
instances
to
basically
fan
out
and
serve
more
users
that
we
could,
with
with
a
single
instance,
and
of
course,
these.
I
This
is
how
it
works
in
a
nutshell,
for
the
for
itf
meetings.
In
this
case,
we
have
a
single
mixer,
audio
mixer.
That
is
a
reference
point
for
each
of
the
rooms
that
we
are
that
we
are
having
here,
for
instance,
in
this
unbone
session,
we
have
a
dedicated
with
a
mixer
for
that,
and
then
the
video
streams
are
injected
via
one
or
more
video
room
instances
instead,
so
that
they
are
then
made
available
via
streaming
plugin
to
everybody.
I
So
all
of
you
right
now
are
passive
attendees,
which
means
that
you
are
all
receiving
the
video
streams
that
I'm
ingesting
via
a
streaming
plugin
actually-
and
this
is
how
it
currently
works
for
all
itf
meetings
and
one
of
the
things
that
could
actually
be
done
and-
and
I
was
incorrect
in
saying
that
we
were
doing
it
already
in
mops.
I
was
already
chastised
by
my
colleagues
for
for
that.
I
Error
is
something
like
this,
which
means
that
this
is
something
that
we
can
do,
meaning
that,
since
the
main
purpose
is
being
able
to
fund
out
the
the
media,
that
an
audio
bridge
and
video
room
plugin
are
handling
to
multiple
streaming
instances.
We
can
do
this
via
unicast,
as
I've
showed
in
the
in
the
previous
slide,
but
we
could
actually
take
advantage
of
multicast
for
the
purpose
instead,
which
means
that
both
the
audio
bridge
and
the
video
room
could
send
to
a
dedicated
multicast
address
to
that.
I
I
can
just
phone
a
new
instance
and
have
them
point
to
the
existing
multicast
resources
and
they
will
pull
the
resources
automatically
without
me
needing
to
make
the
audio
bridge
and
video
room
plugins
aware
of
the
fact
that
I
need
to
unicast
this
stream
to
a
new
component,
and
this
is
something
that
we
can
actually
do,
and
we
have
done
in
in
our
lab
for
a
few
times.
But
we
cannot
do
right
now
due
to
to
the
cloud
infrastructures
that
we
have
available.
I
So,
for
instance,
last
time
we
used
azure
right
now
we
are
using
google
cloud
engine,
but
even
if
we
use
aws,
none
of
them
have
a
native
multicast
support.
So
there
are
some
of
our
customers
that
are
able
to
do
something
like
this
using
components
like
weave
and
kubernetes
and
something
like
this.
But
since
we
use
docker
a
lot
in
using
our
own
technology,
we
haven't
investigated
that
that
part
yet.
I
But
it's
definitely
something
that
we
want
to
investigate
more
in
the
future,
because
we
want
to
take
advantage
of
that
and
something
that
I
should
point
out,
though,
is
that
if
you
have,
if
your
own
data
center
or
data
distribution
network
is
multicast
aware,
this
is
something
that
you
can
indeed
do,
and
in
fact
we
do
have
customers
that
are
involved
in
the
webrtc
broadcasting
services
that
are
actually
using
something
like
this
and
are
actually
pushing
it
even
further.
I
So,
rather
than
doing
just
something
like
this,
where
they
have
ingestion
point
using
multicast
to
distribute
multiple
streaming
instances,
they
are
also
doing
the
same
with
multiple
data
centers
involved.
So
let's
say
that
you
have
this
kind
of
setup
that
we've
just
seen
on
one
of
your
data
centers.
I
If
you
want
to
take
advantage
of
another
data
center
that
you
have
to
also
increase
the
amount
of
audience
that
you
can
support,
you
can
do
something
like
this,
where
you
basically
have
possibly
the
two
data
centers
that
are
not
connected
via
multicast
network,
but
are
only
available
to
a
unicast
network.
Instead,
you
have
them.
I
You
have
some
sort
of
a
bridge
in
the
middle,
so
in
this
specific
context,
these
customers-
that
that
we
know
are
of
are
not
using
amt
as
of
yet,
even
though
I
think
that
amt
may
actually
be
a
perfect
use
case
for
these
for
these.
In
this
context,
because
the
main
purpose
here
is
to
make
sure
that
a
multicast
resource
is
available
on
one
data
center
is
made
available
on
a
multicast
network
on
another
data
center,
so
that
it
can
be
distributed
to
even
more
streaming
instances.
I
So,
for
instance,
I
I
explain
how
the
video
streams
are
basically
can
be
treated
as
individual
broadcasts
that
are
then
tied
together
as
a
conversation
at
an
application
layer,
and
the
main
reason
is
that
we
basically
went
for
webrtc
from
the
from
the
very
start,
which
was,
of
course,
the
obvious
choice,
to
make
an
interactive
platform
for
communication.
It's
what
everybody
uses
today,
it's
very
simple
to
use
and
is
available
in
all
browsers,
which
means
that
everybody
can
just
open
their
browser
and
participate.
I
Multicast
itself,
mostly
because
it
was
natively
conceived
as
a
peer-to-peer
technology,
and
one
of
the
major
impediments
is
the
fact
that,
as
part
of
this
peer-to-peer
communication,
there
is
also
a
dedicated
peer-to-peer,
secure
connection
establishment
via
dtls,
which
means
that
each
peer
connection,
each
connection
that
you
have
established
with
the
peer,
be
it
another
user
or
a
server
you're,
actually
creating
an
ad
doc
cryptographic
context
which
can
not
be
shared
among
multiple
recipients.
In
this
case.
I
So
as
a
technology
itself,
webrtc
is
currently
not
suited
for
multicast
usage,
even
though
webrtc
among
the
technologies
that
webrtc
makes
use
of.
There
is
also
a
bit
of
multicast,
because,
due
to
a
few
privacy
considerations
issues,
there
is
actually
the
usage
of
multicast
dns
to
advertise
candidates
in
the
sdp
that
are
being
exchanged.
I
So
there
is
a
bit
of
multicast
in
there,
but
this
is
just
for
connection
establishment,
not
for
actual
multimedia
delivery,
even
though
I
guess
that
some
multicast
would
actually
be
leveraged
more
from
a
broadcasting
perspective
and
especially
with
possibly
with
the
usage
of
amt.
As
I
was
saying
before,
and
the
basic
example
here
would
be
broadcasting
as
we
intended
in
a
more
broad
sense.
I
So
I
was
mentioning
before
how
you
can
actually
make
some
working
groups
available
via
youtube
as
well,
and
I
was
making
the
example
of
the
plenary,
for
instance,
and
it
works
pretty
much
this
way.
So
you
have
multiple
participants,
interacting
with
each
other,
that
if
you
are
connected
to
the
meteco
interface,
you
see,
as
as
you
are
supposed
to
see,
so
with
the
different
streams
appearing
and
disappearing
as
different
streams.
But
we
also
have
a
separate
component,
a
mixer,
slash
broadcaster
that
is
receiving
in
real
time.
I
So
the
moment
that
we
have
a
stream
that
we
can
broadcast
and
distribute
in
in
real
time,
even
even
though
there
may
be
a
bit
of
latency
involved.
These
broadcasts
may
be
available,
may
be
made
available
to
an
amt
relay.
I
So
that
it
can
be
consumed
by
multiple
multicast
recipients,
somehow
and
right
now,
this
is
mostly,
let's
say,
thinking
out
loud
kind
of
slides.
We
don't
really
have
anything
done
in
this
context,
but
it's
something
that
we
are
thinking
about
doing
in
the
future
sooner
or
later,
and
just
one
one
last
slide
just
to
to
to
tie
into
the
presentation
that
that
oriole
was
making
before
there
is
actually
some
interesting
efforts
being
done
within
the
university
of
naples.
I
So
you
may
not
know
that
mitech
was
a
company
was
actually
born
as
a
academic
spin-off
for
the
university
of
naples.
We
all
got
our
master
thesis
and
phd
there,
and
we
still
have
some
connections
with
university
and,
for
instance,
simon
romano,
who
is
part
of
meteco,
but
is
also
a
professor
at
university
university
of
naples
is
acts
as
a
tie-in
for
these
kind
of
activities
and
one
of
the
activities
that
we've
done
there
is
actually
a
project
called
shine.
I
I
Something
like
I
described
so
far
in
terms
of
the
the
fan
out
distribution
using
an
architecture
as
ssla,
basically
a
tree-based
distribution,
but
then
using
satellites
for
and
multicast
networks
in
order
to
to
expand
the
distribution
even
further-
and
I
mean,
if
you
have
any
question
on
this
specifically
simon-
can
probably
be
much
more
responsive
than
me
on
this
context,
but
I
just
thought:
I'd
I'd
contribute
some
information
on
this
as
well,
especially
in
case
it
may
be
of
interest
to
to
you
all-
and
I
hope
I
I
made
it
in
time,
so
I
hope
there
will
be
some
some
time
for
questions.
I
A
Yeah
hi
thanks
lauren,
so
that
was
that
was
great.
Would
you
be
interested
in
like
what
do
you
think
of
porting,
the
I
forget
which
which
piece
it
was
called
but
there's
so
instead
of
using
webrtc
trying
trying
the
browser
api
to
receive
multicast
and
then
feeding
the
the
rtp
into,
I
think
you
can
do
it
in
the.
What
do
we
call
it?
The
s
s
sre,
the
the
media?
No
there's
like
browser
apis
to
to
actually
display
the
media
right.
A
I
Think
of
also
because
it's
it's
probably
going
to
be
what
was
what
some
time
ago
was
called
the
webrtc
nv,
so
the
new
version
of
webrtc,
where
they
they
are
trying
to
learn,
learn
about
the
mistakes
that
about
from
webrtc
first
version
and
try
to
improve
in
the
next
one,
and
so
one
of
the
ideas
was
basically
to
try
and
possibly
use
quick,
for
instance,
rather
than
use
rtp
and
anything
like
this
to
then
transport
media
in
different
ways
over
quick
and
then,
as
you
said,
use
webassembly
to
both
encode
streams
and
decode
streams
on
on
the
way
back
and
forth.
I
We
haven't
done
this
yet,
even
though
there
are
some
some
people
already
working
in
this
direction.
So,
for
instance,
if
you
take
the
zoom
web
client,
for
instance,
it's
it's
webrtc
only
in
in
in
in
quotes
because
they
actually
don't
use
webrtc
much
at
all,
so
they
actually
only
use
the
apis
to
capture
media
and
then
encode
stuff
themselves
in
the
browser
using
webassembly
and
exchange
stuff
on
their
own
rather
than
doing
webrtc.
I
In
this
case.
For
us,
it
would
be
a
bit
more
complex
than
that,
because
it's
not
just
a
matter
of
packetizing
and
so
on,
but
we
would
lose
a
lot
that
the
browser
gives
us
natively
for
the
moment
so
right
now,
all
we
need
to
ask
the
browser
to
do
is
basically
ask
you
for
permission
to
access
your
your
microphone
and
webcam,
and
then
once
you
do
that
it's
the
browser
itself
that
actually
does
captures
the
component
does
the
encoding
in
at
a
much
much
lower
level.
I
It
is
not
accessible
to
javascript
and
takes
care
of
distributing
the
streams
back
and
forth
and
takes
care
also
the
feedback
mechanisms
involved
in
terms
of
bandwidth
estimation,
negative
acknowledgements
and
all
of
these
kind
of
things,
and
this
is
something
that
is
very
powerful
and
is
done
not
at
the
javascript
level
for
sure.
So
it's
something
that
is
done
at
a
much
more
much
lower
level
and
basically
frees
us
from
many
of
the
complexities
that
are
involved
here.
Of
course,
some
of
those
complexities.
I
We
have
to
take
care
at
this
server
level
in
order
to
take
care
of
the
of
the
feedback
involved
and
these
sort
of
things,
but
from
a
client-side
perspective,
it's
much
lighter
the
moment.
You
start
using
webassembly.
It
means
that
you
need
to
worry
about
encoding
stuff
yourself,
which
the
more
streams
you
encode,
the
the
higher
the
the
cpu
usage,
will
be
and
no
more.
How
optimized,
robust
simply
is.
I
For
the
moment,
I
think
it's
a
bit
premature,
because,
just
because
of
the
the
usage
of
resources
that
may
be
involved
that
we're
actually
a
bit
due
to
high,
but
this
is
something
that
we
definitely
want
to
keep
track
of
and,
for
instance,
I
was
interested
in
your
presentation
before
just
to
take
to
see
what
we
could
do
in
using
multicast
directly
from
the
browser
to
see
if
there
could
be
some
step
that
we
could
do
in
order
to
to
avoid
webrtc.
I
In
some
cases
and
use
multicast
for
the
purpose
instead,
which
may
be
useful,
for
instance,
even
in
just
in
the
context
of
just
attending
a
an
event,
for
instance,
in
this
case,
there's
no
there's
no
encoding
involved.
The
coding
may
be
more
much
more
likely
in
this
case.
Receiving
a
broadcast
would
be
much
easier
to
to
do.
K
I
A
So
your
clients-
don't
do
any.
You
don't
have
a
client,
that's
not
a
webrtc,
then
that
sort
of
yeah.
B
Lorenzo
for
for
this
model,
what
what
what
would
you
say
are
the
gaps,
because
this
I
mean
this
seems
like
this
is
exactly
what
amt
was
built
for.
You.
I
First
of
all,
I
would
have
to
familiarize
myself
a
bit
more
with
the
technology,
because
I've
heard
I've
read
about
a
bit
about
it,
but
I'm
admittedly
not
not
that
much
knowledgeable
knowledgeable
about
it.
So
I
want
to
study
a
bit
more
about
how
the
technology
works,
especially
within
the
context
of
live
distribution,
so
not
just
distribution
of
static
files
or
something
like
this.
So
what
can
be
done
for
the
purpose?
I
know
that,
for
instance,
I
think
it
was
you
that
were
involved
in
integrating
this
support
in
vlc
as
well.
I
So
that
might
be
an
interesting,
an
interesting
thing
to
to
look
into,
especially
for
the
for
the
for
the
attendees
perspective,
so
how
they
can
actually
consume
a
stream
that
we
are
introducing
that
way
in
general,
it's
a
matter
of
figuring
out
how
media
should
be
encoded
and
packetized
in
order
to
distribute
it
somehow
and
what
can
be
done
in
order
to
minimize
the
impact
on
the
recipient's
site
so
that
they
can
reuse
existing
tools
rather
than
writing
other
tools
for
that
as
well.
B
Great-
and
I
just
I
just
added
into
the
comments-
look
for
a
little
more
information
about
that
vlc
port
and
how
we're
using
it
in
the
multicast
menu.
It's
a
you
know
it's
it's
a
good
primer
to
see.
You
know
all
the
pieces
in
place
that
multicast
menu
basically
lists
all
the
active
multicast
streams
on
the
mbone,
and
you
can
just
click
on
a
minute.
B
It'll
launch
vlc.
If
you
have
the
correct
vlc,
the
latest
version
of
vlc
it'll
run
amt
capable
and
you'll
be
able
to
watch
over
amt.
I
Now,
thanks
that's
very
helpful
because
I
just
need
some.
We
just
need
some
reference
to
to
know
what
we
should
basically
construct
in
order
to
make
it
compliant
with
what
is
what
is
out
there.
So,
basically,
to
reply
to
your
point:
what's
missing
is
we
need
to
do
some
homework?
Basically,
that's
it.
B
And
and
I'll
say
this,
that
the
multicast
menu
we're
we're
looking
for
way
more
content.
So
if
you've
got
test
streams,
if
you've
got
real
streams,
even
better
we'd
be
happy
to
to
add
them
to
that.
So,
okay
content
is
king.
B
All
right,
so
I
guess,
if
that's
all
like
to
say
thanks
everybody
for
for
joining,
especially
those
on
the
west
coast
of
north
america,
who
had
to
wake
up
extremely
early
for
this
and
look
forward
to
hopefully
seeing
everyone
in
person,
maybe
at
1
11.
We
can
only
hope,
but
we'll
see
otherwise,
we'll
see
in
a
couple
months.