►
From YouTube: MOPS WG Interim Meeting, 2020-04-15
Description
MOPS WG Interim Meeting, 2020-04-15
A
B
C
D
D
C
C
E
D
D
So
those
of
you
who
may
or
may
not
be
familiar
with
how
we
do
drums
there
is
a
jabber
channel.
It's
on
that
I
know
is
posted
on
our
page
and
there
is
an
Ethernet,
an
ether
pad,
as
eric
has
shared
with
us,
which
is
where
the
notes
are
being
written
in
real
time,
feel
free
to
jump
in
and
help
with
those,
and
please
do
sign
in
sharing
your
name
and
affiliation
so
that
we'll
have
a
record
of
who
was
actually
at
this
meeting
or
future
planning
purposes.
C
Monitor
the
I'll
monitor
the
jabber
channel,
as
well
as
the
the
queue
in
the
chat,
so
a
little
bit
of
logistics
here,
if
you
want
to
get
in
the
queue
to
speak,
just
basically
in
the
chat,
type
plus
q
to
add
yourself
or
q
to
remove
yourself
and
if,
if
you're,
not
speaking,
please
keep
your
mic
muted.
So
we
can
reduce
background
noise.
D
D
D
D
So
this
is
an
IETF
meeting,
so
ITF
policies
are
in
effect,
so
for
various
topics
such
as
patents
or
code
of
conduct,
so
I'm
sure
you're.
All
reading
this
on
the
screen
as
we're
sitting
here,
but
just
by
way
of
reminder
that
you
agreed
to
follow
idea,
processes
and
policies
and
if
you
are
aware
to
any
IETF
contribution
is
covered
by
patents
or
patent
applications
that
are
owned
or
controlled
by
you
or
your
sponsor.
D
You
must
disclose
that
fact
or
not
participate
in
the
discussion
and
as
a
participant
or
in
in
or
attendee
to
any
IETF
activity.
You
acknowledge
that
written
audio,
video
and
photographic
records
of
meetings
making
me
public
that
your
personal
information
provided
the
IDF
will
be
handled
in
accordance
with
the
idea
privacy
statement
and
that
you
agreed
to
work
respectfully
with
other
participants
with
a
pointer
to
the
Ombuds
team.
Should
you
have
need
of
it?
G
I'm
Jake
Holland
I'm,
presenting
about
the
the
current
working
group
draft
that
we
have
and
the
updates
since
our
last
meeting
that
next
like
this,
so
there's
been
a
few
changes
in
kind
of
draft
status
and
things
around
the
draft.
And
to
summarize
these,
the
draft
was
adopted
as
a
working
group
draft
I
had
on
the
mailing
list.
We
renamed
it
to
co-authors,
join
Spencer
and
Ollie
I'm
very
grateful
to
them.
G
I
think
they're
really
going
to
get
us
over
the
hump
into
a
definitely
useful
document
and
I
am
very
pleased
with
their
contributions
and
if
I
had
to
have
them
on
board,
we
have
an
acknowledgement
section
and
made
a
capturing
all
the
comments
from
the
Mike
last
time
and
from
I
think
it
already
had
the
comments.
I
recall
from
any
email
discussion.
So
if
you've
made
a
contribution
and
you
don't
and
we
had
and
I
haven't
been
I've
missed
you
and
be,
please
be
sure
to.
G
G
So,
thanks
to
the
chairs
for
getting
that
set
up,
this
is
its
current
location,
so
go
there
if
you're
looking
for
it
or
for
the
for
the
working
document
of
it
and
there's
a
pointer
to
that
in
the
draft
also
and
accepted
so
there's
a
few
bits
of
content
that
the
draft
will
be
about
itself,
but
also
we've
been
that
we've
gotten
started
with
mostly
my
co-authors.
Thanks
to
them,
and
just
a
few,
you
know
helpful
additions,
getting
us
in
the
right
direction
on
what
the
document
text
should
end
up
talking
about
next
slide.
Please.
G
We
have
a
list
of
issues,
so
these
are
mostly
in
the
issue.
Tracker
I
think
there
might
be
wanted
to
and
inkay
beauties
in
the
text
of
the
draft
still
and
where
I
want
to
spend.
Most
of
my
time
on
the
on
this
update
is
that
there's
a
great
suggestion
from
Spencer
I
thought
and
you
please
do
take
a
look
at
the
issues
list.
Ad
issues
I
think
we
had
one
contribution
already
from
Allen
was
I
think
it
was
Matt
and
that's
much
appreciated,
we'll
be
taking
a
look
at
that
and
incorporating
it.
G
But
Spencer
had
a
great
idea,
and
so
I'll
talk
about
the
the
very
next
thing
that
we're
probably
going
to
grab
the
draft
for
and
put
something
out,
and
that
is
the
template
on
the
next
slide
here.
That's
the
that's
the
feedback
that
we're
specifically
soliciting
in
addition
to
any
sort
of
issues
you
want
to
raise
so
go
ahead
to
the
next
slide.
Please
so.
G
We're
gonna
add
a
section
to
the
draft,
we're
thinkin
and
it's
gonna
look
something
like
this
and
we're
looking
for
feedback
on
this
part
plus
contributions
from
those
of
you
who
are
interested
enough
in
the
operations
that
you're
attending
this
meeting.
For
us,
any
friends
you
might
have
so
the
the
idea
is
that
we
we
would
like
to
collect
a
catalog
of
the
issues
that
people
know
about
in
the
community.
Things
you've
encountered
before
things
that
you.
G
Obviously,
will
be
filling
out
a
few
of
these
from
from
our
own
experience,
but
we
think
we
can
reach
a
broader
audience
or
we
think
that
there's
things
that
we
don't
know
about,
probably
that
people
that
other
people
who
are
taking
a
look
at
this
do
know
about
that.
We
can
probably
incorporate
they're
asking
for
a
name,
a
reference
to
something
describing
the
issue
even
like
a
you
know,
pointer
to
a
mailing
list,
a
comment
about
it.
G
G
Turn
it
into
another
document,
so
we
want
to
make
sure
that
we
have
a
list
of
these
that
were
maintaining
it
might
be
in
the
in
the
mitigations
or
now
and
then
in
a
mitigation
section.
The
draft
for
now
and
then
move
to
a
separate
document
a
little
bit
later,
when
we're
we're
kind
of
ready
to
make
a
division.
But
the
idea
here
is
that
we
want
to
little
right
now.
G
J
See
if
this
works,
can
everybody
hear
me?
Okay,
yep,
all
right
perfect,
so
thanks
I
actually
think
that
the
template
I
think
it's
a
it's
a
good
idea
with
a
document
like
this.
It's
you
know
it
can
end
up
being
an
encyclopedia
right,
so
I.
My
first
reaction
is,
if
we're
targeting
this
towards
people
who
understand
the
video
domain,
but
perhaps
don't
understand
the
network
domain
as
well,
and
it's
intended
to
be
a
survey.
J
I
I
would
think
talking
about
the
challenges,
but
then
referencing,
especially
when
you
start
getting
into
mitigation
techniques
in
detail,
referencing
other
documents
or
best
practices
in
other
places
is
probably
best
because
otherwise
this
could
get
both
out
of
hand
and
stale
very
quickly
so
that
I
go
I.
Guess
that's
my
my
reaction
to
the
to
the
comment,
but
I
do
but
I
do
like
the
way
that
you
know
this
template
is
is
is
trying
to
shore
that
up
a
bit
great.
G
Yeah
thanks.
Another
thing,
I
probably
should
have
mentioned
one.
One
of
the
possibilities
here
is
to
if
we
collect
the
mitigation
techniques
to
turn
them
into.
Perhaps
if
there's
enough
of
it,
if
it
turns
into
really
large
encyclopedia,
then
maybe
it
would
be
multiple
separate
documents
that
could
be
BCP
is
directed
toward
different
audiences.
We
think
that's
a
pretty
good
way
to
collect
it.
So
that's
one
of
the
ideas
on
the
table.
I
think
that
you
know
it
kind
of
depends
what
the
contributions
end
up.
G
A
Traditionally,
I
would
unmute
before
I
started,
talking
right
so
well.
What
we
were
thinking
there
early
on
was
basically
just
to
say
we're
doing
more
than
just
to
say.
You
know
this
is
a
list
of
bad
things
that
can
happen,
so
it
was
important
to
me
to
have
had
the
stuff
that
we
were
collecting
be
actionable
at
some
level.
A
Even
if
to
say
you
know
it's
like.
Let
me
like
a
couple
of
things:
we've
got
in
there
already
it's
like!
Well,
that's
the
way
the
TCP
works.
You
know.
So
you
know
you
even
be
able
to
give
people
an
answer
saying
if
this
is
what
you're
seeing
you
know,
there
may
not
be
a
really
great
mitigation
right
now,
but
for
it
was
important
to
meet
for
these
things
to
be
as
actionable
as
we
could
make
them,
and
so
that's
that's
kind
of
why
I
was
starting
to
talk
about
collecting
the
mitigations
they're,
like
I.
A
Think
that
the
suggestion
to
collect
pointers
is
a
really
good
one,
because
you
use
the
word
encyclopedic
and
I
think
that's
exactly
the
right
thing.
That
I
was
afraid
of
which
was
basically
here's
a
list
of
sad
tales
from
the
video
streaming
community
and
not
really,
you
know
not
really
active
or
anything
like
that.
A
G
Yeah
and
the
you
know,
I'd
like
to
mention
that,
even
if
the
answer
is
like
well,
that's
the
way
it
TCP
works.
So
we
don't
have
another
solution
right
now.
You
know,
maybe
that's
nonetheless,
a
good
hint
that
well,
you
could
consider
going
and
looking
at
quick
or
maybe
you
know
next
year
we
could
consider
looking
at
SRT
depending
what
you're
what
you're
doing
like.
If,
if
TCP
is
the
that
points
in
the
direction
of
useful
solutions
right
so
knowing
that
is
this
half
the
battle.
B
Hey
so
I
wanted
to
follow
up
on
the
comment.
Spencer
just
made
I
think
that
clunky
mitigations
is
really
good,
so
I,
so
you
don't
+1
on
there
doing
that,
although
I
don't
want
to
I,
don't
think
we
should
cast
them
a
sort
of
like
here's,
a
mitigation
and
problem
solved.
You
know
third,
just
like,
as
Jay
commented
I
think,
maybe
where
there
is
issue
we
get
called
out
and-
and
we
sir
can
say
so
we
can
say
well,
here's
a
mitigation
that
sort
of
starts
alleviating
the
problem.
B
However,
there
may
be
better
solutions
and
bigger
solutions
that
are
necessary,
and-
and
maybe
you
know,
this
is
sort
of
a
farming
exercise
as
well
to
collect
requirements
that
could
get
turned
into
problem
statements
and
future
documents
within
both
mops
and
beyond
the
eggs
are
beyond
mops
in
the
ietf
in
particular.
You
know
it
seems
like
well,
let's
just
how
TCP
works.
That's
a
really
good
indicator
that
maybe
there's
something
we
need
to
revisit.
Potentially
someplace
else.
Maybe
if
you
know
like
Jake
said,
maybe
just
look
at
quick
srt.
B
Maybe
it's
a
need
for
something
new
that
isn't
around
today.
You
know,
because
everything
to
do
with
video,
you
know
happens
to
the
internet
at
scale,
so
one
little
bad
thing,
maybe
locally
kind
of
escalates,
very
quickly
into
being
a
very
bad
thing
across
the
board
for
a
lot
of
people.
So
my
two
cents.
C
J
Yeah,
just
a
follow-up
I
think
that
the
other
thing
too,
that
I'm
that
I'm
thinking
about
when
we're
talking
about
mitigations
is
that
I
it
makes
it,
and
maybe
this
is
kind
of
along
the
lines
of
what
Glenn
was
saying-
is
that
it's
it's
not
really
black
and
white
because
often
and
I
think
everybody
will
resonate
with
this.
It's
actually.
What
are
the
trade-offs
and
what
are
you
finding
acceptable?
J
And
so
the
reason
I'm
thinking
about
this
is
as
I
was
the
section
that
I
kind
of
put
in
as
a
something
that
might
be
worth
putting
in
the
document
is
about
personalization
and
advertising
and
how
that
impacts
things
like
cache
ability
and
network
utilization
and
all
of
those
other
things
and
and
it's
more
of
a
hey.
You
know
video
person,
the
choices
that
you
make
have
these
downstream
effects,
and
you
know
you
should
be
aware
of
them.
It's
not
that
oh
personalization
or
advertising
is
bad
or
can't
happen
or
whatever.
J
What
resources
they
might
need,
and
so
on
so
I
think
that
having
that
kind
of
veneer
in
the
document
that
gives
them
the
tools
to
dig
in
use
the
right
nomenclature
to
potentially
find
the
solution
that
fits
their
their
need
is
is
is
kind
of
where
I'm
going
but
I
like
the
idea
of
having
you
know
some
of
the
options
listed,
I
the
the
pointer
comment
was
really
just
you
know.
We
we've
got
it.
J
D
Unconscious
at
the
time,
thanks
for
that
input
matt
of
the
time-
and
I
think
that
we
should
probably
move
on
unless
there
are
other
issues
here,
what
I
would
what
I
would
suggest
is
why
don't
we
try
collecting
some
issues
and
see
what
we
get
and
then
figure
out
the
problem
or
or
a
smaller
problem.
We
actually
have.
G
Thank
You
Leslie,
thank
you,
Matt
Spencer
Glen,
maybe
I'll
send
a
quick
follow-up
to
the
list.
I
thought
I
heard
one
suggestion
in
there
that
might
result
in
the
template
change
like
maybe
we
should
about
trade-offs
or
something
but
yeah
that
was
between
Glenn
and
Matt,
we'll
think
about
that
a
little
bit
move
on.
Thank
you.
Thank.
I
Good
to
go
here,
I
see
the
slides
up
there.
My
name
is
Sanjay
Mishra
and
I'm
from
Verizon,
but
at
the
moment,
speaking
with
the
streaming,
video
Alliance
head-on
and,
of
course,
is
a
member
of
member
company.
So
this
presentation
is
a
little
bit
outside
of
some
of
the
things
that
I've
spoken
in
the
past.
I
Just
as
a
quick
recap
and
I
apologize
for
those
that
are
already
familiar
with
it,
but
just
wanted
to
give
a
quick
view
here.
So
SVA
is
really
it's
a
collaborative
ecosystem
comprising
of
content,
publishers,
content,
distributors
and
the
network,
service
providers
and
technology,
vendors
to
work
on
over-the-top
streaming
media
delivery
and
with
an
SBA
member
companies
share
common
vision
of
making
streaming
media
provide
a
consistent
experience
to
an
end
user
from
glass
to
glass.
I
This
minimally
needs
understanding
of
issues
around
content,
creation,
packaging
underlying
media
protocols
and
transport
protocols,
network
behavior
and
the
end
user
player,
so
lots
of
different
pieces
that
that
actually
go
into
this.
So
so
there's
there's
there's
points
of
interest
in
each
of
these
areas
and
as
an
outcome
for
the
most
part
alliance
will
produce
guidelines
and
best
practices,
but
also
at
times
the
Alliance
would
do,
run
the
trials
and
write
specifications
and
conduct
interoperability
testing.
I
So
I
just
wanted
to
take
a
quick
moment
here
to
highlight
a
few
things
before
we
get
into
some
of
the
specific
projects
within
the
FTA.
So
the
recent
months
have
had
a
profound
impact
globally,
but
then,
as
with
any
challenge,
there
also
is
an
opportunity
and-
and
there
surely
is
a
covert
ninth
in
effect
globally,
but
we
all
have
learned
to
live
in
a
virtual
world,
including
this
meeting
here,
which,
unfortunately
is
not
in
person
and
and
obviously
there
are
some
tidbits
of
relevancy.
I
I
Some
of
the
numbers
just
to
kind
of
share
Comcast,
has
reported
a
video
surge
in
their
network
somewhere
about
38%
and
a
peak
traffic
of
about
32%
AT&T
reported
similar
with
28%
jump
in
core
network
traffic
and
and
that
the
video
traffic
was
with
about
half
of
the
traffic
on
their
mobile
networks,
pretty
significant
and
also
not
to
be
left
out.
Verizon
reported
similar
numbers
where
their
video
traffic
was
up
by
36%
and
also
AT&T
like
AT&T.
I
They
also
have
reported
surge
in
social
media
platforms
as
well
so
from
what
what
is
relevant
above
is
that
swimming
video
is
already
a
significant
part
of
network
traffic,
but
on
top
well
then
so
just
go
vat19
cast
a
big
effect
on
the
network
capacity.
So
while
network
providers
do
plan
for
spikes
and
scaled
and
networks,
but
the
higher
order
point
here
is
that
really
no
one
entity
in
the
OTT
video
delivery
food
chain
of
his
own
can
deliver
or
be
as
effective,
then
solving
for
issues
such
as
a
scaling
and
latency.
D
I
Other
working
groups,
the
live-streaming
working
group
and
also
virtual
reality,
study
groups.
There
are
a
few
initiatives
that
are
looking
into
the
opportunities
to
measure
a
latency
and
NC
where
that
can
be
moved
so
one
other
project.
So
obviously
that
are
listed
here.
The
first
one
is
is
best
practices
document,
basically
for
looking
at
the
latency
glass-to-glass
from
the
encoder
to
screen.
I
This
project
is
holistically.
Looking
at
the
end-to-end
workflow,
examining
points
of
weaknesses
right
from
the
distribution
encoder
to
the
encoders
and
down
through
the
whole
video
delivery
chain,
looking
at
where
there's
opportunity
to
tweet
and
tweet
and
tune
so
so
that
that
is
and
the
outcome
would
really
be
a
best
practices
document
from
that
effort,
the
other
on
the
be
our
study
group.
I
I
The
opportunity
is
here
for
some
tweaks
again
looking
at
the
video
delivery
and
and
seeing
where
might
be
some
out
there,
the
pain
point,
so
this
work
will
obviously
require
some
close
coordination,
eventually
the
IETF
as
well.
If
there
are
areas
that
that
seems
like
worth
looking
at
and
then,
as
we
have
seen
with
the
but
the
code
with
19,
if
scale
abilities
and
made
a
consideration,
and
what
also
is
needed
is
basically
how
about
smartly
using
the
existing
network
resources
as
opposed
to
throwing
more
money
infinitely
into
just
going
the
the
network.
I
I
So
this
one
talks
about
some
potential
new
working
groups
as
well,
so
the
one
of
the
activities
that
the
open
caching
working
group
has
done
as
being
relying
heavily
on
CDN
I.
Some
of
the
work
has
been
done,
but
in
addition,
the
group
they
alliances
are
looking
at
additional
additional
work
around
the
CDN
interoperability.
So
more
has
to
be
defined
here,
but
primarily
some
of
the
work
that
that
has
already
been
done
since
Edie
and
I,
but
really
not
implemented.
I
So
there
are
some
some
feedback
that
members
are
interested
in
bringing
back
so
as
that
work
really
gets
defined.
Hidden.
An
icd-9
interoperability
is
one
area
that
the
work
is
going
to
be
looked
at
within
within
the
within
this
work
group.
The
other
item
is
also
challenges
that
that
are
across
the
myriad
of
video
players
that
you
have
on
the
end-user
devices
and
they're
the
issue
that
they
all
video
players
don't
behave
the
same
way
so
sometimes
they
necessarily
don't
have
a
stickiness
to
be
redirected
source.
I
So
those
are
the
at
least
two
working
groups
that
are
being
considered
to
be
established
in
coming
weeks
and
in
months.
Probably,
but
that's
that
I
think
this
is
probably
the
last
slide
that
I
have
I
think
this
is
the
last
one
yet.
So
this
is
the
last
slide
with.
That
said
thanks
very
much,
and
let
me
back
to
you
and
for
any
questions.
B
We
won
Jake
and
Spencer
right
now
makes
me
by
the
way
so
hey
so.
The
other
thing
I'd
like
to
add
to
Saudis
great
great
presentation,
is
that
I
think
this
sort
of
God
dropped
through
the
cracks
at
the
SBA
went
on
jjt
were
making
up
the
slides,
there's
also
work
that
has
parted
up
very
recently
within
the
networking
transfer
group
of
the
SBA.
B
G
G
Look
like
do
you
think
we'll
just
be
like
SBA
members
commenting
on
the
ITF
mailing
lists
and
the
sort
of
best
fit
they
can
find
where
the,
where
the,
where,
where
you
want
to
have
the
tight
engagement
with
ITF,
because
I
know
that,
at
least
with
regards
to
a
few
folks
there,
the
different
PR
considerations
between
the
SBA
and
and
the
ITF
contributions
was
part
of
the
reason
that
there's
not
like
a
hundred
percent
overlap
in
the
membership.
Oh
yeah,
just
I,
guess
that's
most
of
what
I
wanted.
I
I
What
what
as
individuals,
what
we
can
do
is
bring
back
the
updates
into
the
IETF
and,
more
importantly,
not
only
just
the
updates,
there's
going
to
be
questions
and
things
you
know
which
ITF
is,
you
know,
has
either
looked
at
or
would
be
interested
in
looking
at
so
we
can
always
bring
the
the
problem
statement
and,
in
fact,
bring
it
back
to
this
working.
This
very
working
group
that
this
is
a
specific
problem
which
is
really
well
and
beyond
the
scope
of
something
that
can
be
resolved
in
SVA.
I
But
that's
something
that
maybe
IDF
can
look
at.
So
I
think
the
important
part
would
be
is
for
for
us
from
the
SBS
endpoint
define
a
very
clear
problem:
do
some
research
and
then
bring
the
appropriate
common
statement
and
any
references
that
that
can
point
to
what
work
has
been
done
and
if
there
were
something
that
was
missing,
then
you
know
kind
of
try
to
spell
that
out
that
here's,
the
problem
statement,
here's
what
I
think
has
been
done
but
looks
like
there's
some
room
for
improvements.
I
K
D
B
So
hey
switch
to
different
mic,
maybe
also
work
better.
So
you
can
see
me
when
I
walked
away.
Okay,
I
wanted
to
address
the
concern.
Jake
had
over
potential
IP
conflicts
between
the
two
groups,
so
I
think
when
the
documents
get
done
over
the
SVA,
the
tradition
there
is
to
publish
them
to
the
web
for
anybody
to
read
without
deciding
any
required.
Ipr
agreements
the
IP
over
there
really
pertains
to
members
of
the
Alliance.
B
Who
potentially,
would
you
know,
adopt
or
implement
things
that
instead
of
the
Alliance
would
produce,
but
things
like
use
cases
I
would
stuff
like
that.
Even
best
practices
get
published
onto
the
internet
and
that
way
the
when
they're
done
the
ITF
membership
can
just
take
a
look
at
them
and-
and
we
can
use
them
over
here
in
mops
without
any
concern.
So
I
think
we're
good
to
go
on
that
regard,
and
if
we
have
a
problem,
somebody
should
see
me
because
I'll
do
what
I
can
to
fix
it.
I'm
on
the
board
over
there.
I
D
H
Hi
everyone
thank
you
for
offering
this
time
slots.
My
name
is
Maxime
Rebecca
I
am
senior
software
developer
at
hi-vision,
together
with
SK
Telecom
we've
prepared
and
submitted
the
draft
specific
protocol.
Recently
I
did
a
presentation
of
a
surgery
at
The
Dispatch
session,
to
discuss
how's
our
chicken
fit
into
ITF
workflows,
and
today,
I
would
like
to
do
an
overview
of
the
protocol
features
that
could
potentially
be
useful
for
most
use
cases
next
slide,
please.
H
So
what
is
a
30-30
stands
for
secure,
reliable
transport.
It
is
a
protocol
built
on
top
of
UDP.
It
is
content
agnostic.
It
provides
bi-directional
data,
transmission
with
automatic,
repeat,
request,
forward,
error,
correction
and
bonded
connections
and
also
supports
three
multiplexing,
so
several
connections
can
be
established
over
a
single
in
DP
circuit
next
slide.
Please
30
offers
several
operation
modes
message:
mode
live
mode
and
buffer
mode
message.
Mode
can
be
used
to
transmit
messages
that
spend
over
several
packets
life
mode
is
a
subset
of
message
mode
with
additional
features
to
enable
real-time
live
stream
delivery.
H
H
The
described
operation
modes,
a
search
she
can
cover
a
number
of
use
cases.
This
slide
presents
a
list
of
you
are
cases
when
a
surgery
can
be
used.
The
major
use
case
of
a
30
is
life,
video
contribution
and
distribution,
a
30
offers
mechanisms
of
latency
management,
bacons
retransmission
swamp,
and
this
content
agnostic,
so
usually
30,
transmits
impact
es
RTP
or
elementary
streams
in
its
payload.
H
Now
the
use
case
is
transferring
files
and
segmented
streaming
formats
like
HLS,
and
in
this
case
a
search
ensures
every
packet
is
delivered
to
the
receiver
as
efficient
as
possible,
and
does
it
certainly
doesn't
control
them
to
end
latency,
because
real-time
delivery
is
not
required.
In
this
case,
the
third
potential
use
case
of
a
search
is
tunneling
again,
a
search
is
agnostic
to
the
content,
its
transmits
and
therefore
it
can
turn
on
TCP
packets,
HTTP
requests
and
responses
into
almost
any
other
type
of
payloads
message.
H
H
As
I've
already
mentioned,
the
major
purpose
of
a
30
is
low,
latency
life,
video
contribution
distribution
in
life
operation
mode.
This
modest
30
provides
a
constant
end-to-end
latency
that
includes
network
transmission,
latency
and
a
configurable
buffering
delay
of
the
receiver.
The
buffering
delay
is
used
to
retransmit
lost
packets.
Those
packets
that
fail
to
be
recovered
within
the
given
latency
are
dropped
in
favor
of
following
packets
to
enable
real-time
live
streaming
next
slide.
H
Before
going
deeper
into
the
over
here
for
safety
features,
I
would
like
to
share
some
motivation
why
one
should
consider
using
a
30-30
was
created
and
first
used
in
2013
in
2017,
assertive
was
made
open,
source
and
free
for
public
usage
at
the
moment,
as
it
is
one
of
the
most
widely
used
protocols
for
life
contribution
and
distribution
last
year,
so
he
received
a
technical,
Emmy
Awards
companies
using
search.
We
are
joining
the
City
Alliance
that
currently
comes
more
than
350
members,
and
only
last
year
more
than
100
new
companies
had
joined
such
alliance.
H
This
slide
presents
the
latest
survey
on
the
video
transport
protocols
usage
conducted
recently
by
high
vision.
It
can
be
seen
that
a
surger
holds
a
decent
part
as
the
amount
of
live
video
distributed
over
the
public
network
increases
the
relevance
and
application
for
subject
without
in
doubt,
there
are
alternative
protocols
and
solutions
that
can
be
used
as
well,
each
heaven
its
advantages
and
disadvantages.
Therefore,
I
would
like
to
go
through
a
30
features
to
highlight
what
is
available
in
Sochi
out-of-the-box
and
what
is
not
available
next
slide.
H
Please
this
slide
a
metric,
sofa,
30
features
that
address
the
most
common
tasks
and
issues
associated
with
live-streaming
set
of
tasks
is
connectivity.
An
activity
connecting
two
beers
together
to
exchange
data
without
using
a
third
party
is
often
very
tricky.
Modern-Day
networks
use
nuts
and
firewalls,
while
a30
offers
a
5-volt
reverse
mechanism,
its
legs
knots
traversal.
We
are
interested
in
integrating
it
with
interactive
connectivity
establishment
if
it
makes
sense
an
actual
integration
and
networks.
Vision
are
features
that
also
could
potentially
be
added
in
the
future.
To
distinguish
multiplexed
streams.
H
Assert
already
operates
with
connection
IDs,
which
could
be
used
to
perform
these
kinds
of
switch
next
set
of
tasks.
Is
access
control?
Consider
a
client
who
wants
to
connect
to
a
streaming
server
and
request
a
certain
resource.
The
streaming
server
needs
to
authenticate
the
clients,
probably
share
the
stream
definition
of
the
requested
resource
and
start
sending.
The
data
asserted
currently
supports
this
use
case,
except
for
their
stream
definition,
functionality,
which
is
more
or
less
available,
but
not
yet
fully
defined.
Our
current
vision
is
to
use
the
stream
definition
protocol
for
this
purpose.
H
The
next
thing
is
security.
Once
the
connection
is
established,
content
can
be
transmitted
over
a
public
network
so
that
anyone
can
access
it.
A30
offers
eius
encryption
of
the
payload
of
data
packets,
appreciate
password
is
used
with
the
password-based
key
derivation
mechanism
to
establish
encrypted
connection.
Other
automated
key
distribution
methods
could
potentially
be
adopted
in
the
future.
H
That
is
a
content
delivery,
like
any
loss
in
network.
The
public
internet
suffers
from
packet
losses,
packet,
reordering,
jitter
and
O'brien
entering
linton's
packet
losses,
introduce
artifacts
in
the
video,
the
very
end
to
end
latency
may
cause
unstable,
playback,
speed
freezes
and
so
on.
Some
lost
packets
may
not
be
retransmitted
in
time
they
have
to
be
dropped
to
enable
real-time
streaming.
All
of
this
has
a
major
impact
on
the
quality
of
experience.
H
The
final
point
of
interest
is
utilizing
several
networks,
for
example,
to
duplicate
all
the
data
and
improve
delivery,
or
to
balance
the
load
between
the
available
links
and
increase
the
throughput
or
handle
periods
of
congestion
on
certain
awnings.
So
this
set
of
features
is
a
work
in
progress.
Starting
functionality
will
be
added
in
the
upcoming
release
of
30
next
slide.
Please,
and
that
was
no
worry
of
what
a
city
can
offer.
Thank
you
for
attention
and
feel
free
to
ask
questions.
I
will
be
glad
to
answer
any.
K
H
So,
based
on
this
discussion,
we
decided
that
assertive
should
starts
with
an
informational
track
to
sub
into
what
we
already
have
and
to
have
a
solid
specification
of
it
and,
based
on
this
specification,
we
can
move
on
and
understand
in
which
groups
it
can
be
used
in
which
groups
that
can
be
I
useful
for
for
application.
I.
K
Sorry
so
my
name
is
Alex
I'm
part
of
different
groups
and
I
was
following
that
discussion
on
this
patch
and
I
saw
the
people
that
are
involved
in
the
the
quick
description
and
the
our
CRT
and
proposing
that
these
would
be
more
discussed
in
the
media
transport
group
than
most
but
I
didn't
follow
recently.
So
our
since
I
don't
see
a
slide
to
see
what
the
feedback
of
IETF
was
already
I
wanted
to
see
what
the
situation
was
so.
D
H
D
G
Great,
so
I
also
am
going
to
be
interested
in
that
discussion,
but
I'll
I'll
wait
on
that.
For
now
what
I
was
gonna
say
was
first
of
all,
thank
you
for
bringing
this
to
the
IETF
I.
Think
it's
very
interesting
I
looked
at
it
as
a
possibly
an
exciting
opportunity
to
never
have
to
learn.
Rtp
and
I
haven't
done
of
questions
about
the
about
the
protocol
and
its
its
operational
behavior,
especially
as
used
by
apps
and
senders.
But
the
one
question
I
wanted
to
address.
G
H
Yeah
thanks
for
the
so
right
now
a
search
already
supports
it's
just
the
main.
The
major
use
case
of
it
is
live
stream
because
there
was
an
obvious
need
for
some
protocol
that
would
address
these
issues,
so
I
would
say
that
a
search
is
very
optimized
for
streaming
and
it
can
be
used
for
message,
exchange,
user
content,
delivery
and
so
on.
Just
maybe
some
field
improvements
are
required,
to
example,
improve
congestion,
control
for
file
transfer
and
and
so
on.
G
So
would
that
be
so?
Does
that
include
live
streaming
to
end-users
or
because
the
the
use
of
the
pre
shared
key
I
agree
is
going
to
be
problematic
if
you're
gonna
try
to
like
add
it
as
a
browser
protocol?
So
I
assume
that's
one
of
the
preconditions
but
I'm
not
sure
if
there's
others
that
you
would
also
need
to
do
or
whether
you
give
it
any
thought
to
using
it
in
use
cases
beyond
just
distribution
but
into
into
end-user
delivery
as
well.
H
F
F
Some
I
would
I
would
view
it
similar
to
a
TMP
of
how
it
scales
right.
So
it's
it's
optimal.
Why
it
was
created
is
the
contribution
problem.
How
do
you
get
it
into
the
cloud
from
an
on-prem
location
over
the
public
Internet
and
how
do
you
get
it
across,
but
it
it
works
as
a
protocol
similar
to
and
turn
out
in
P.
So
if
you
have
a
server
as
a
server-
and
you
contribute
a
stream
into
it,
then
obviously
you
can
have
hundreds
or
thousands
of
clients
accessing
that,
depending
on
your
server
capacity.
F
However,
it's
a
it's
not
a
just
since
it
CDP
base.
It's
not
it's
not
directly
in
the
browser
right.
So
it's
a
that's
a
limitation
here.
So
when
we
are
saying
contribution
and
distribution,
what
that
typically
means
is
this
usually
either
a
native
software
somewhere
or
client
that's
receiving
the
stream
and
not
directly
the
browser
window.
C
Yeah,
if
you're,
not
speaking,
could
you
could
you
please
mute?
So
we
don't
get
background
noise,
all
right,
I
guess,
since
Spencer
took
himself
out
until
the
dispatch
discussion,
I,
guess
I'm
up
next,
so
so
taking
off
my
chair
hat
for
a
moment,
one
of
the
things
that
I
think
would
help
would
help
people
at
the
IETF
understand.
C
The
context
for
this
work
is
is
knowing
a
bit
about
about
why
you
decided
to
develop
a
new
protocol
rather
than
take
an
existing
protocol,
or
you
know,
take
an
existing
protocol
as
is
or
extend
one
to
have
some
of
the
properties
that
you
wanted.
What
what
were
the
protocols
that
you
looked
at
before
developing
this
and
why
didn't
they?
Why
didn't
they
measure
up
I?
Think
that
I
think
that's
basically
what
I'm,
under
what
I'm
asking
for.
F
So
back
then,
in
2012,
when
I,
when
I
joined
high
vision.
At
that
point,
I
was
asked
for
solution
to
transmit
low
latency
live
streams
over
the
public
Internet
instead
of
over
protective
networks.
What
we
were
doing
and
being
one
of
the
leaders
at
the
time,
so
they
they
came
to
me
and
I
had
very
little
experience.
To
be
honest,
was
networking
so
I'm,
a
pragmatic
guy,
I
came
from
computer
vision
and
so
I
took
I
looked
on
the
internet.
F
What
I,
found
and
I
found
a
protocol
for
very
high
throughput
for
very
high
data
transfer
over
the
public
internet,
which
was
nudity,
but
it
was
designed
for
fire
transfer,
but
it
behaved
very
well
on
the
network
and
I
was
able
to
utilize
links
at
maximum
capacity,
but
it
was
not
designed
to
have
real-time.
Behavior
was
n25
latency
and
encryption.
F
C
B
Hey
so
first
thank
you
for
bringing
this
into
the
ITF
why
these
presentations
I
know
it
takes
a
lot
of
work
and
the
ITF
can
be
a
little
bit
scary.
So
thank
you
for
for
doing
both
and
and
I
like
those
to
comment.
You
know
so
you
know
I'm
from
Comcast
NBC
Universal
and
we
use
this
stuff
in
our
operations
up
all
the
time,
and
so
this
is.
This
is
our
reality
of
our
media.
Ops.
B
If
using
SRT
to
you
know
all
our
stuff
around,
you
know
in
our
normal
day-to-day
works.
So
I
like
to
see
this,
you
know
succeed
and,
in
particular,
I'm
encouraged
by
the
hope
that
the
lessons
that
have
been
learned
in
other
parts
of
the
IDF
around
you
know
how
to
do
connection
ideas
very
efficiently
and
securely,
and
also
how
to
fold
security
into
the
protocols
like
this
can
be,
may
be
applied
and
adopted
by
SRT
to
make
it
even
better
than
it
is
today.
B
So
one
wish
I
do
have,
though,
is
so.
Where
do
you
sort
of
see
that
the
priorities
for
SRT
is
is
I
mean
reliability
of
Congress
lis?
Delivery
of
packets
is
number
one,
especially
for
live
media.
You
can't
miss
the
the
soccer
score
goal
or
the
hockey
puck
going
into
the
net.
That
would
be
very,
very
bad,
and
so
that's
a
non-starter.
B
F
What
we
call
connection
bonding
functionality
to
add
redundancy,
seamless,
switching
as
part
of
the
protocol,
as
well
as
main
Becca,
failover
functionality
and
balancing
data
over
multiple
links.
What
you
would
need
for
say,
like
a
multiple
bond
that
or
multiple
40
adapters
or
something
to
balance
the
data
over
things
we
that
it
for
us
is
something
that
has
to
be
part
of
a
contribution
protocol
and
that's
the
top
priority.
F
The
other
priorities
are
looking
at
the
security
model
and,
in
addition
to
the
pre
shared
key,
can
we,
for
example,
somehow
adopt
TTLs
model
as
a
protocol
or
TLS
model?
And
that's
that's
where
we
need
I
mean
that's
where
we
can
need
all
the
support
we
can
get
and
all
the
help
working.
Yet
we
are,
you
know,
very
interested
in
because
we
know,
especially
in
this
community
and
in
the
wider
community,
that
that
is
a
question
that
comes
up
obviously
again
and
again
again.
F
So
I
believe
that
those
two
are
the
key
and
at
the
same
time
we
are
putting
a
lot
of
research
effort
into
optimizing.
The
congestion
control
algorithms
to
make
it
friendly
to
the
network
and
and
optimal
in
its
behavior.
That's
that's
been
started
probably
like
a
year
ago
and
we're
making
we're
coming
to
the
point
we
have
where
we
have
good
test
employment
at
a
good
community,
which
is
very
important.
So
we
can.
We
can
invoke
to
community
to
help
us
okay,.
B
Yeah
as
much
like
the
congestion
control,
because
you
know
one
of
the
ongoing
problems
anybody
has
and
pulling
video
out
of
things
like
live
sporting
events
is,
is
the
availability
of
very
reliable
high
speed
networks
and
end
things
that
work
play
well
with
the
existing
network.
You're
very
welcome
because
they
make
everybody's
lives
easier,
but
thank
you
bye.
Thank.
D
So,
at
quarter
past
the
hour
we
are
going
to
move
to
our
next
large
presentation
and
I
will
apologize
an
event
I
skipped
over
Glen's
update
from
MTV,
but
that's
because
I
had
heard
previously
that
he
hadn't
extracted
an
update,
so
we'll
be
doing
that
at
our
next
meeting.
That
agenda
item
is
dropped,
so
I
would
like
to
make
sure
that
we
have
most
three
more
minutes.
Discussion
on
this
topic,
I
would
sum
up
where
we
are
at
this
point.
D
As
there
is
interest
in
this
protocol,
there
is
in
this
group
particularly
interest
around
what
it
means
for
and
what
I
can
do
for
and
how
it
does
for
video.
This
is
not
the
group
that
would
work
on
the
technical
specification,
but
maybe
what
we
can
do
is
take
most
of
the
rest
of
the
discussion
to
the
mailing
list.
If
the
SRT
proponents
are
willing
to
engage
on
the
mailing
list,.
A
Without
without
wandering
through
dispatch
very
much,
it
seemed
like
the
way
that
discussion
ended
up
was
that
you're
going
to
be
doing
a
draft
describing
what
SRT
is
now
that's
something
that
doesn't
exist
in
a
complete
form?
Quite
yet,
if
I
understood
that
correctly,
that
would
that
would
help
mops
discuss
SRT
more
effectively.
So
that
sounds
like
a
wonderful
thing
to
have
happen,
no
matter
what
else
happens
with
SRT
and
the
IETF.
G
So
it
kind
of
starts
back
in
2014.
We
had
some
plans
and
they
basically
looked
like
this,
and
you
get
some
multicast
video
to
play
yet
the
ISPs
to
deliver
multicast
and
profit
right
next
to
them.
So
the
real
motivation
here
is
that
we
could
see
the
looming
scalability
issues
that
that
we've
seen
unfolding
over
the
last
several
years
and
they're
continuing
to
unfold,
and
the
goal
here
is
to
capture.
G
G
You
know,
as
as
time
went
forward,
we
flush
that
out
a
little
bit
and
and
a
couple
pieces
of
this
worked
out
great.
You
know
we
got
the
multicast
video
to
play.
It's
working,
fine,
we,
you
know
shipped
a
product,
it's
a
walled
garden
video
product
and
we
first
deployed
it
in
2019.
Q1
customers
are
happy,
they're
expanding
the
deployment,
but
unfortunately
it
doesn't
solve
the
scalability
issues
without
getting
to
that
inter
domain
multicast
piece,
which
is
an
ongoing
work
in
progress,
but
we're
getting
closer
on
that
so
next-level.
G
Attitudes
that
we've
encountered
for
how
to
make
this
work
I
think
are
probably
no
surprise
to
anyone,
but
just
to
kind
of
summarize
them.
The
the
value
proposition
for
melty
cotta
for
multicast
is
clear.
It's
you
know
it's
all
about
the
scalability,
in
primarily
for
for
things
that
that
can
have
that
are
accessed
concurrently
and
the
viability
of
it
is
also
clear
in
the
it's
you
know,
deployed
and
running
and
works
great
where
it
is
deployed
and
running
the
it's.
G
G
So,
to
summarize,
the
discussion
has
been
you
know
where
were
our
vision
here
is
that
well,
AMT
is,
is
a
useful
way
to
get
this
rolled
out,
and
so
we
we
started
looking
into
that,
and
that
was
in
the
2015
timeframe
and
we're
trying
to
make
that
become
viable.
Some
of
our
early
discussions
with
operators
indicated
that
it's
just
not
going
to
be
possible
to
do
it
with
it,
I
mean
so
it's
it's
no
different
from
peering
if
you
have
to
set
up
static,
IPS
and
a
mapping
with
with
the
static
IP.
G
So
this
is
this
resulted
in
what's
coming
up,
it's
an
off
48,
now
I
for
this.
After
this
meeting,
I'll
probably
go
look
at
my
latest
round
of
responses
if
I've
got
him
and
but
a
way
to
discover
it
that
can
be
sort
of
individually
deployed
by
by
an
AMT
relay
operator
and
can
be
discovered
by
anybody
with
access
to
DNS
is,
is
now
a
a
proposed
status
standard
they're
proposed
standard
data
level,
nearly
captured
as
an
RFC
and
among
the
problems.
G
So
one
of
my
first
contributions
at
the
IETF
on
this
was
trying
to
understand
trying
to
get
a
handle
on
the
way
you
can
do
rate
limits,
because
multicast
doesn't
build
in
any
way
to
do
that
and
we're
very
concerned
about
the
capacity
of
or
how
to
make
the
the
make
it
a
manageable
problem
to
ingest
an
unknown
amount
of
capacity
or
what
would
otherwise
be
an
unknown
amount
of
capacity
into
someone's
network
and
make
it
safe.
So
this
is
one
of
the.
G
G
So
our
attempts
to
address
the
attitudes
is
to
sort
of
you
know,
make
the
cost
specific
like.
Okay,
here
are
some
things.
If
you
do
these
things,
then
we
will
have
a
viable
architecture
and
will
actually
work
and
our
efforts
to
address
the
unknown
savings
that
you
would
get
is
to
quantify
like
what
are
we
going
to
actually
be
able
to
accomplish,
and
our
estimates
are
coming
up
with
or
akamai
traffic
in
terms
of.
G
G
G
So
our
future
plans
at
this
point
are
that
we
want
to
you
know
on
the
transport
part.
We
want
to
expand
our
usage
of
multicast
to
be
able
to
take
care
to
make
use
of
basically
anything
popular.
That's
what
these
these
three
use
cases
have
in
mind.
Linear
video
is
the
one
that
we
have
running
today,
but
we
think
that
it's
addressable
to
access
popular,
on-demand
video.
G
G
This
is
this
is
if
we
can
achieve
peak
50%
peak
offload,
we
think
that
other
people
in
many
cases
can
achieve
a
similar
kind
of
offload.
Then
you
know
we
would
we
think
that
there's
a
good
win-win
story
here
that
they
can
reduce
the
infrastructure
costs
that
that
ISPs
are
going
to
be
faced
with
over
time
and
that
by
engaging
now
and
getting
this
to
move
forward,
that
we
can
really
get
to
a
place.
G
G
If
I
guess
it
is
now
and
to
start
folding
in
the
the
work
that
we're
doing
in
m1d
to
make
this
something,
that's
you
know
reasonable
to
put
into
a
browser,
because
one
of
the
things
that
becomes
immediately
clear
when
you
talk
to
browser
developers
is
that
they're
highly
aware
of
how
malicious
the
web
is.
It's
it's
at
a
scale.
You
know
not
not
meant
for
mortals
to
understand
early,
but
we,
you
know
the
the
two
things
that
we're
trying
to
prevent
so
far.
G
We're
not
sure
if
it's
going
to
be
enough,
but
we
think
that
it's
a
good
start
and
we
think
that
they
are
a
minimum
set
of
what's
necessary
and
we
don't
have
other
good
ideas
that
that
cannot
be
addressed
by
this.
Yet
so
we
think
this
might
be
enough
to
get
going
and
to
annecy
operationally
what
we
run
into.
G
So
that's
that
is
our
intent
and
the
other
intent
for
this
year
is
to
to
begin
to
the
extent
possible
some
trials
with
carriers
and
make
sure
that
the
anti
ingest
architecture
that
we're
proposing
is
going
to.
You
know
work
for
them
to
be
to
be
usable
and
get
the
job
done
for
for
getting
multicast
traffic
transported
the
places
that
it
needs
to
get
to
and
and
then
to
try
to
scale
to
some
real
content
that
gets
delivered.
We're
also
partnering
with
some
content
owners.
G
They
are
heard,
you
know
not
the
ones
that
have
to
do
as
much
work.
So
it's
it's
not
as
hard
a
sell
for
them,
and
we
would
very
much
like
to
make
sure
that
our
our
proposed
mechanism
for
Dan
with
controls
will
work
with
with
you
know,
some
actual
deployed
systems
that
are
used
for
been
with
controllers,
so
we're
we're
interested
in
in
tackling
that
problem.
Next
slide,
Fitz.
G
So,
who
are
our
call
for
participation?
Is
you
know
we're
in
talks
with
with
a
number
of
folks,
but
in
some
cases
it's
not
like
the
people
in
our
company
that
worked
with
the
CDN
side
of
the
of
the
carriers
are
necessarily
all
the
right
people
to
be
talking
to.
So,
if
you
know
somebody
in
a
carrier
that
you
think
would
be
interested
in
this,
then
an
introduction
would
be
wonderful
or
if
you
work
at
a
carrier
that
might
be
interested
in
exploring
this
and
and
capitalizing
on
those
cost
savings.
G
Then
please
do
reach
out
to
us.
We
would
love
to
have
a
meeting
to
give
you
an
architecture,
walkthrough
and
and
decide
after
that,
after
you
have
time
to
look
it
over
and
get
any
questions.
You
have
answered
whether
this
looks
like
something
that
you'd
be
interested
in
leaning
into
and
figuring
out
so,
and
we
can
make
our
overall
estimates
more
specific
to
like
the
observed
traffic
that
we've
been
sending
into
your
network
to
figure
out
like.
Is
this
something
that
really
makes
sense
or
for
what
we
typically
deliver
into
your
network?
G
C
D
C
Yeah,
so
we
now
have
a
you
know
of.
As
Leslie
mentioned,
we
have
a
set
of
repositories,
an
area
whatever
you
want
to
call
it
an
organization
on
github
for
the
mops
Wharton
groups.
So
when
we
adopt
documents
that
are
that
are
going
to
be
managed
through
revision
control,
then
we'll
move
them
into
that
into
that
repo
I
mean
just
to
be
clear:
that's
not
a
not
a
requirement
for
adopting
documents,
we're
not
prescribing
that
everyone
must
use.
C
E
D
D
D
Here
any
I'll
take
the
opportunity
to
thank
everybody
for
coming
out
to
the
meeting,
and
certainly
thanks
to
our
presenters,
for
sharing
their
work
and
taking
on
questions.
I
I
expect
that
there
will
be
more
of
these
because
I'm
personally
fairly
convinced
the
idea
of
a
meeting
face
to
face
anytime
soon,
if
you
have
any
feedback
on
things
that
worked
well
in
this
meeting,
things
could
work
better
or
other
areas
you'd
like
us
to
tackle
in
future.
Thank
you.
Please
share
with
the
hops
chairs
at
IETF,
torgue.