►
From YouTube: IETF109-NWCRG-20201117-0730
Description
NWCRG meeting session at IETF109
2020/11/17 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
B
Okay,
so
welcome
everyone.
I
can
see
there's
22
people
on
the
the
meet
techo.
It
is
2
31
a.m
in
montreal,
canada,
and
I
can
tell
you
guys
that
the
last
time
I
was
up
with
such
a
nice,
a
large
number
of
people
at
2
30
in
the
morning
I
had
been
invited
to
the
cast
party
of
a
theater
play,
and
actually
we
had
that
she's
started
going
out
at
midnight,
so
hopefully
this
is
going
to
be
as
entertaining
as
going
out
with
the
cast
of
the
whole
play.
B
B
And
this
is
our
irtf
research
group.
Obviously
your
goal
is
to,
and
has
been
for
quite
a
number
of
years
now
foster
research
in
network
and
application
layer
coding
to
improve
network
performance.
We've
done
a
lot
of
work
in
this
group
in
the
past
years.
We've
done
codes,
obviously
in
coding,
libraries,
but
actually
I
would
say
so.
We
actually
have
developed
codes
and
codes.
Libraries,
but
I
would
say
most
also
important
was
to
the
the
goal
of
the
team
was
to
develop
protocols
actually
to
facilitate
the
use
of
coding,
an
existing
system.
B
We
wanted
to
have
real
world
use
cases
and
work
in
progress,
and
I
think
it's
important
to
highlight
that
this
is
all
in
the
context
of
research,
so
even
the
protocols
and
the
real
world
and
the
coding
we
wanted
to
foster
research
in
that
not
just
develop
codes
for,
for
you
know
the
sake
of
developing
code.
So
there
was
just
looking
at
what
the
re,
what
the
research
in
this
area
was
targeting.
B
B
B
We
are
like,
I
said,
fostering
research
and
even
when
we
say
like
I
said
we
develop,
that
we
develop
codes
and
we
develop
protocols
and
things
it's
all
in
the
context
of
the
research
around
this
not
again
in
the
context
of
developing
a
standard,
and
I
think
for
many
people
it
is
still
a
struggle
because
you
know
people
think
oh
yeah
we're
going
to
take
it
to
the
iotf,
it's
like,
if
we're
taking
it
to
the
ietf
or
to
another
standard
organization.
But
it's
not
the
case.
B
B
B
B
Actually,
even
in
california,
it's
11
30,
it
almost
makes
sense,
so
the
materials
are
on
the
again
the
data
tracker
and
and
on
the
github
repository
and
again,
if
you
go
on
the
ietf
meeting,
you're
going
to
see
that
the
session
is
being
recorded
and
it's
going
to
be
uploaded
to
the
ietf
109
youtube
channel,
we
have
a
bluetooth
automatically
filled
for
those
of
you
who
never
attended
an
ietf
meeting
and
please
sheet
is
stuff.
That
goes
around
the
meeting
to
see.
B
Who
is
participating
if
you
want
to
read
to
join
it?
The
q
manage
the
queue
for
questions,
please
press
the
raise
hand,
icon
and
you're
going
to
join
the
queue
and
vase,
and
I
are
going
to
monitor
the
queue
our
agenda
is
kind
of
simple.
This
is
me
now
doing
the
administrivia
we're
going
to
have
a
presentation
of
the
bats
coding
scheme.
This
is
something
that
is
really
advanced
and
is.
A
B
Okay,
well,
I
think
they
had
also
said
that
maybe
they
would
skip
the
the
meeting
in
the
last
few
days,
so
I
wasn't
sure
if
they
were
going
to
change
their
mind.
So
if
they're
not
there,
maybe
that
means
that
we
do
not
have
a
bats
coding
scheme
presentation
and
where
they're
going
to
rejoin
us
at
the
next
ietf.
But
maybe
we
want
to
say
something
about
the
bats
draft
ourselves
where
it
is
in
terms
of
id
and
becoming
a
research
group
item.
B
We're
going
to
have
a
presentation
on
coding
and
congestion
control,
which
has
been
an
issue
since
coding,
usually
hides
lost
packets,
or
also
used
to
signal
congestion
and
morton,
who
is
going
to
present
us
repair
patterns
for
sliding
window
codes
and
morton.
We.
I
saw
your
message
about
being
at
home
with
young
kids
and
I
really
send
my
best
next.
A
A
Yes,
yes,
yes,
thank
you.
Thank
you,
so
a
few
words
about
the
current
status
of
this
group
and
the
working
items.
So
we
are
approaching
the
end
concerning
the
first
id
that
were
calling
for
satellite
systems.
It
passed
isg
review
recently
it
has
been
updated
based
on
one
comment.
One
final
comment:
we
received
from
isg
review
and
well
now
the
the
floor
in
the
end
of
colleen
perkins,
to
have
a
final
review
of
this
quick
update,
so
it
will
hopefully
be
published
by
next
itf
meeting.
A
What's
up
yeah,
okay,
so
otherwise
the
we?
We
started,
two
calls
in
september,
one
for
the
network
coding
for
ccn
and
dn
requirements
and
challenges,
internet
drafts
and
the
other
one
for
the
bats
coding
scheme.
So
the
first
call
was
about
was
the
research
group
last
call,
which
was
copied
also
to
the
icnrg
mailing
list,
since
it
is
a
document
that
is
shared
between
the
two
groups.
A
We
didn't
receive
any
feedback
from
the
from
either
groups.
I
sent
a
quick
review
yesterday
about
it
from
my
opinion.
Well,
the
document
is
in
good
state,
so
there
are
a
few
changes
to
be
done,
but
nothing
really
serious
from
my
point
of
view.
So
this
is
something
that
we
need
to
confirm,
of
course,
with
the
ic
energy
chairs
and
group,
but
I
think
we
have
something
which
is
quite
solid
right
now
and
next
step,
if
everybody
agrees
will
be
to
to
move
it
to
the
isg
for
rev
to
continue
the
process.
A
A
A
So
we
need
to
decide
what
to
do
if
we
agree
to
have
it
be
a
result.
Group
item
document,
but
that's
something
that
we
can
discuss
later
on.
I
don't
know
if
any
of
the
authors
joined
right
now,
I'm
still
waiting
for
raymond,
but
seems
not
to
be
here.
So
I
suggest
we
discuss
this
at
the
end
of
the
meeting.
I
don't
know
if,
in
the
meantime,
raymond
will
be
able
to
join
and
do
the
presentation
about
the
bats
new
version
of
the
the
new
version
of
the
bats
document
or
not.
A
There
will
be
a
presentation
from
nicola
on
the
topic,
so
we
will
see
then,
what's
what
the
the
the
updates
that
have
been
made
in
this
document
on
this
work
and
we
still
have
two
items
in
standby
mode.
I
would
say
one
for
the
coding
for
quick
and
the
other
one
about
tetris,
so
I
suggest
to
discuss
this
at
the
end
of
the
meeting
and
we
are
almost
done
for
this.
A
A
This
is
still
the
goal
and
we'll,
of
course,
have
an
itf
network
research
group
meeting
network
calling
research
group
meeting
for
next
during
next
itf-
and
hopefully
I
wasn't
able
in
position
to
do
this
accustomed
to
l
this
accustomed
this
time
about
the
swift
codec,
but
I
hope
to
be
able
to
do
so
for
next
atf.
We
have
to
finalize
this
disconnect
between
before
closing
the
group,
so
that's
for
the
status.
A
A
E
This
is
an
update
on
the
coding
and
construction
control
draft.
We
have
been
working
on
in
the
last
few
months.
Just
next
to
me.
There
are
lots
of
word
works,
so
maybe
noise
during
the
condition,
I'm
sorry
in
advance.
For
that
next
slide,
please,
since
last
itf
we
have
done
a
lot
of
experiments
and
also
adding
I
did
a
very
large
discussion
section.
E
E
E
We
have
three
different
types
of
satellite
links
that
I
use.
We
we
have
one
that
is
mobile
and
users.
This
is
a
use
case.
We
have
already
shown
to
the
group
before
basically
the
mumbai
new.
There
is
a
train
and
there
are
obstacles
that
are
regular.
So
when
you
look
at
the
picture
on
the
bottom
right
of
the
slide,
you
can
see
that
we
have
regular
packet
losses
on
the
top.
E
This
is
something
that
reflects
the
losses
that
could
happen
with
optical
links,
so
this
is
a
huge
trend
in
satcom
systems
to
use
optical
links
on
the
feeder
or
on
whatever
length
so
to
go
through
these
frequencies
to
increase
the
data
rate,
so
but
this
can
come
with
losses,
so
a
lot
of
work
on
it.
This
is
very
high
level
view,
but
this
is
something
we
could
see
where.
Basically,
we
have
lots
of
bursts
of
losses
on
the
optical
link.
E
We
also
have
a
case
where
we
have
a
dvds2,
classical
satellite
link
without
any
losses.
Another
thing
that
we
change
during
the
experiment-
and
sometimes
we
use
wi-fi-
we
emulate
wi-fi
losses.
Sometimes
we
don't
so
it's
just
one
person
to
order
classes,
and
sometimes
we
just
run
tests
with
single
flows
and
sometimes
we
just
add
a
load
with
a
viable
amount
of
loads
to
introduce
congestion.
E
E
Basically,
just
throw
one
level
here
when
we
have
the
mobile
user
and
we
download
20
megabytes,
and
we
have
here-
I
just
show
the
median
over
more
than
20
tests.
So
if
we
just
compare
basically
the
fourth,
the
four
first
lines,
I
use
the
fcc
tetris
tunnel,
the
four
below
ones.
Last
ones
do
not.
So
here
we
showcases
with
without
wi-fi
with
and
without
congestion.
E
What
I
wanted
to
highlight.
I
will
not
go
through
the
whole
details
of
the
results,
but
what
I
wanted
to
highlight
is
that
when
we
compare
what
what
we
have
with
the
epc
tunnel
and
when
we
don't
have
it
that
we
have
a
drastic
reduction
of
the
20
megabytes
download
time,
so
this
is
why
we
could
be
very
happy
and
oh
yeah.
My
fpc
solution
is
the
best
it
works
for
both
tcp
and
quick,
and
it's
very
great.
E
I
just
also
wanted
to
say
that
if
we
look
in
the
details,
when
we
speak
about
fec
and
condition
control
interactions,
we
can
see
that
this
depends
on
the
congestion
control
itself,
because
here
we
use
the
exact
same
fpc
tunnel.
But
we
use
quick
and
dcb
and
we
can
see
that
the
results
differ
next
slide.
Please.
E
Here
on
in
green,
this
is
the
accumulated
throughput
of
the
10.
Basically,
we
have
10
coded
flows
and
10
non-coded
flows
we
can
see
here
is
on
in
green.
Is
that
when
we
introduce
the
10
non-coding
flows,
the
amount
of
the
cumulative
data
rate
is
the
same,
but
below
the
flows.
10
flows
are
coded,
10
are
not
so
what
we
can
see
here
is
that
the
rest
of
the
traffic
has
very
fees
its
amount
of
available
that
are
diminished.
So
this
is
a
big
problem.
E
E
E
E
Basically,
this
document
try
to
discuss
all
these
two
things
can
coexist
and
also
encourage
the
retention
community
to
consider
construction
control
when
proposing
and
corporate
effect
solutions.
Otherwise
they
can
fall
in
the
same
trap.
As
we
did
saying,
we
have
a
fabulous
fcc
mechanism
for
all
satellite
use
cases,
but
then
we
end
up
having
very
important
and
fairness
issues
next
slide.
Please.
E
E
There's
something
we
didn't
discuss
before
this
is
from
how
new
in
the
document
is
that
the
relevance
of
the
discussion
of
interactions
between
npc
and
conjunction
control
depends
a
lot
on
the
transfer
transport
layer
itself,
because
we
can
use
non-variable
transport
service
or
partially
reliable
transport
service,
or
we
transparently,
depending
on
how
the
fpc
inclusion
controls
are
scheduled.
The
impact
of
variable
transport
on
fpc
mechanism
is
very
different.
E
E
E
And
so
these
we
have
introduced
in
the
document
and
different
advantages
and
drawbacks
on
having
a
pc
above
within
our
bureau's
transport,
and
what
we
have
added
is
a
more
wider
discussion
section
on
the
different
going
more
into
the
details.
So
this
is
what
are
we
going
to?
I
will
present
now
there
are
been
some
discussions
and
paperwork
under
our
books
when
you
speak
about
policy
fairness,
because
if
we
look
at
this
figure,
we
have
two
different
views.
E
E
Unfairness
between
the
different
users,
satellite
terminals:
this
is
the
theme
that
could
be
seen
at
the
ue
level
in
a
lte
3gpp
network.
Basically,
we
have
we.
We
should
not
have
fairness
issues
when
we
look
at
the
cpe
level
or
the
ue
level
in
a
network.
That
being
said,
when
there
are
flows,
sharing
the
same
qrs
and
the
same
contracts,
then
fairness
discussion
applies,
but
that
could
be,
for
example,
different
applications
running
on
one
viewing
and
3gbp,
or
the
different
computers
behind
one
end
of
the
terminal
at
home.
E
E
How
construction
control
uses
recovered
symbols,
the
impact
of
the
interactions
between
sequential
control
and
the
coding
rates
and
what
happens
to
useless,
sweeper
symbols?
There
are
discussions
and
things
we
had
doing.
The
these
things
were
just
we.
This
is
based
on
comments
we
had
from
the
list
or
when
we
already
presented
the
documents.
Previously,
I
don't
know
chairs.
If
I
have
time
to
go
through
the
different
points
here,
or
should
I
rather
ask
for
people
opinion
not
released?
A
E
Feasible.
Okay,
thank
you.
I
will
then
just
go
quickly
over
this.
Basically,
we
think
something
that
comes
a
lot
from
this
table
is
that
when
we
look
at
the
fairness
and
the
impact
on
the
non-connect
flows,
there
is
an
issue
for
the
fake
bill
transport
case
such
as
we
shown
earlier
on
the
presentation.
E
We
think
that
this
can
this
approach
can
drastically
reduce
a
good
good
for
the
nonprofit
flows,
but
then
specific
signals
can
be
proposed,
such
as
a
technique
that
has
been
proposed
by
manual
earlier
in
previous
ltf
meetings.
This
is
the
solutions
could
be
proposed,
but
would
be
then
protocol
event.
E
This
mostly
very
interesting
for
the
fake
within
transport
case,
because
they
a
very
large
trade-off
between
reducing
the
output
when
we
actually,
we
send
a
us
useless,
reverse
symbols,
but
then
this
can
help
to
recover
fully
from
transmission
and
condition
losses.
But
still
we
should
be
able
to
propose,
in
the
case
of
the
effect
within
transport
signaling,
to
enable
receivers
to
indicate
precisely
the
number
of
source
packets
that
have
been
received.
E
We
they
infinite
issues
and
we
are
not
aware
of
the
constitutional
control
implementation,
so
we
think
this
is
something
that
should
be
either
for
the
moment.
We
just
describe
it
in
the
draft.
We
don't
take
position
on
what
is
advised
or
not,
but
this
is
something
important
to
consider
next
slide.
Please.
E
Jose
recommended
us
to
try
to
come
up
with
open
research
question,
and
indeed
there
are
basically
because
we,
when
we
use
coding,
we
will
use
a
good
put
and
when
we
send
useless
with
a
packet
with
a
symbols
and
but
then
we
can
help
recover
from
transmission
congestion
losses.
So
this
trade-off
is
always
here
and
but
the
the
way
you
actually
can
consider
it
depends
a
lot
on
the
relation
between
the
effect
and
the
transport.
E
So
if
we
start
with
the
right
column
and
when
we
are,
in
the
effect
below
transport
case,
the
wave,
the
fairness
issues
that
we
mentioned
earlier
on
and
also
sometimes
you
may
have
different
streams,
multiple
applications
streams
sharing
the
fcc
channel.
So
this
is
something
that
needs
to
be
considered
because
we
use
the
same
efficiency
mechanism
for
all
frames.
E
E
Because
we
can
actually
disambiguate
the
act
packet
from
the
crippled
packets,
so
we
can
try
to
identify
new
signal
limit
certain
fpc
because
recovery
aware
construction
controls,
then
we
could
even
have
dynamic
coding
rates
using
another
construction
controls,
for
example
lower
than
this
default
one.
There
are
lots
of
things
that
could
be
possible
in
this
faculty
and
transport
case
for
the
effect
you
both
transport.
E
E
The
document
should
be
improved
this
way
we
may
come
up
with
some
recommendations.
I'm
not
sure,
that's
not
the
objective
of
this
document,
but
when
we
have
written
all
that's
in
the
table
of
the
comparison
presented
earlier
on,
I
think
there
may
be
some
recommendations
that
could
be
written,
but
we
need
to
discuss
that
and
obviously
we
are
very
happy
to
have
any
questions
or
comments
on
the
document.
B
This
is
important
work
because,
as
people
have
been
involved
with
coding
for
a
long
time,
no,
you
know
the
the
congestion
control
always
comes
as
a
as
a
problem
and
as
one
way
in
fact
of
dismissing
the
use
of
of
fec
and
what
you
showed.
Yes,
you
know
if
you
go
through
with
your
coded
stream,
everything
every
everybody
else,
you
know
falls
back
and
sure
you,
you
think
you're
coding,
your
recorded
stream
works
perfectly,
but
it's
because
everybody
else
lost
their
bandwidth.
B
E
We
think
there
is
interest
in
these
discussions,
but
we
haven't
had
far
more
feedback
from
other
people
working
on
that.
We
know
that
a
lot
of
people
working
on
fec
mechanisms
as
a
transport
player,
but
we
don't
know
if
they
actually
are
interested
and
if
they
actually
are
looking
in
the
track.
We
are
in
the
process
of
adding
state-of-the-art
section
where
we
listed
all
the
articles
research
articles
with
this
kind
of
discussions.
E
E
E
A
B
B
A
G
Yeah,
thank
you
very
much.
A
nice
presentation
nicholas.
I
agree
it's
it's.
This
is
important
work
to
be
done
right.
So
there's
one
thing
that
that
that
maybe
I
I
I
don't
understand,
maybe
you
can
clarify
a
little
bit
so
when
you
say
coding
above
the
transport
to
me
that
that
doesn't
sort
of
that
wouldn't
make
that
much
sense,
because
if
you
have
something
like
tcp
underneath
which
is
doing
re-transmissions
or
quick,
which
is
doing
re-transmissions,
you
wouldn't
really
see
any
losses
above
the
transport.
G
E
E
E
F
But
what
I
really
wanted
to
comment
about
is
the
that
you
are
missing
a
column.
Your
category
fec
below
transport
really
should
be
called
fec
disconnected
from
transport,
and
I
think
what
what
most
people
who
work
in
this
base
agree
is
that
fsc
actually
has
to
do
some
signaling
to
the
transport,
and
this
is
probably
a
more
interesting
column
than
the
column
where
you
don't
have
any
signaling
at
all.
F
Of
course,
if
you
integrate
fec
into
transport,
then
you
have
that
signaling
implicitly,
so
that
the
efficiency
can
talk
to
to
the
congestion
control
in
the
transport.
But
if
it's
done
by
different
entities,
as
I
understand,
was
the
case
with
your
tetris
tunnel,
then
you
have
to
do
some
some
signaling
and
then,
of
course
the
interesting
question
is:
how
do
we
do
the
signaling
and
I
think,
that's
an
area
where
the
interesting
research
questions
are
so.
F
F
E
Thank
you
for
for
for
these
comments.
On
the
on
the
the
first
part,
I
have
read
the
paper
and
I
think
we
should.
We
could
indeed
include
that
in
the
draft
we
just
wanted
to
also
we
were
not
sure
to
what
extent
we
should
open
the
pandora
box
on
fairness
in
this
document,
but
it
is
true
that
this
is
something
we
need
to
discuss
we
wanted
to.
If
we
look
at
slides
14,
we
also
wanted
to
mention,
because
sometimes
when
fairness
is
discussed
with
a
typical
dumbbell
architecture,.
E
Users,
so
this
is
something
that
needs
also
to
be
discussed
when
you
speak
about
fairness,
and
this
is
a
very
policy
concern,
so
this
is
why
we
refer
to
bob
schools,
work
on
floor
rate
fairness,
but-
and
that's
also,
I
think,
the
definition
on
not
to
harm
others.
It's
something
we
tried
to
map
in
this
presentation,
but
we
may
make
this
more
formally
internet
version
of
this
document.
E
I
would
tend
to
disagree
on
when
you
propose
to
say
that
when
we
have,
the
effect
below
is
the
effect
disconnected
because
we
mentioned
the
case
of
the
tet
net
and
all
these
things
where
we
actually
can
have
a
signaling
between
the
fcc
and
the
transport
layer.
We
just
mentioned
that
this
is
protocol
specific,
and
this
cannot
be
done
in
general,
and
so
I
think
indeed
I
would
agree
with
you
too
research
question.
A
G
Thank
you
very
much.
I
hope
everybody.
The
audio
is
going
through
well
to
everybody,
so
I
have
a
short
presentation
here
on
repair
patterns
for
sliding
window
codes,
and
this
really
came
about
because
we
were
doing
a
couple
of
projects
where
we
were
working
on
very
low
latency
applications.
So
in
an
end-to-end
fashion
and
working
on
those
applications,
we
learned
that
our
intuition
about
how
to
produce
the
repair
wasn't
really
correct.
G
So
I
would
like
to
sort
of
spend
a
few
minutes
presenting
our
our
findings
here
and
maybe
get
some
feedback
from
you
guys
on
on
what
what
your?
If
you
have
some
some
some
views
on
this.
So
if
we
take
the
next
slide,
it
just
a
brief
background
right
for,
for
those
that
may
not
have
seen
sliding
window
codes
before
the
sort
of,
but
most
people
are
probably
familiar
with
the
traditional
blog
codes.
B
G
Then
we
have
another
set
of
packets
and
we
produce
repair
from
those
from
that
and
we
call
those
set
of
packets
a
block,
and
in
this
specific
case
we
have
four
packets
in
every
block
and
we
produce
two
repair
from
every
block.
So
that's
a
that's.
A
most
fec
codes
can
operate
or
erase
your
codes
can
operate
in
this
block
mode
but
sort
of
in
recent
the
years.
G
We
have
also
seen
a
bunch
of
implementations
that
are
looking
more
at
something
called
sliding
window
codes
where,
where
at
the
figure
at
the
bottom,
you
can
see
sort
of
in
the
dashed
line.
The
coding
window
and
it's
sort
of
packets
are
not
sort
of
grouped
into
individual
blocks,
but
packets
are
flowing
through
the
same
coding
window
and
at
any
given
point
in
time
we
can
decide
to
generate
prepare
for
the
packets
that
are
currently
in
the
window.
This
window
can
then
be
managed,
for
example,
in
time.
G
G
But
one
of
the
sort
of
interesting
questions
that
that
come
about
is
that
when
you,
when
you
use
these
protocols,
you
typically
have
some
packet
loss
that
you
want
to
overcome
can
be
that
you're
observing,
let's
say
five
percent
packet
loss,
and
you
want
to
generate
repair
to
to
fix
that
packet
loss
in
advance
right
because
it's
a
low
latency
protocol,
you
don't
really
want
to
use
retransmissions
because
there
you
have
to
go
back
and
forth
over
the
link.
So
that
might
be
okay
if
it's
a
low
latency
link.
G
G
So
here
we
have
two
different
repair
patterns
and
on
the
left.
What
we
have
here
is
symbols
coming
in
so
s1
s2,
s3,
s4,
so
forth.
There
are
symbols,
that's
basically
equivalent
to
a
network
packet
can
be
from
a
video
frame
or
something
like
that,
and
then
what
we
do
is
that
we
can
generate
this
repair,
which
includes
some
of
these
symbols.
Right,
r1
r2
are
including
s1
vs4
and
what
you
have
on
the
left
and
on
the
right
is
two
different
repair
patterns
on
the
left.
G
G
And
if
you
look
at
the
at
a
column,
you
will
see
that
every
symbol
is
covered
by
four
repair
packets.
So,
from
a
protection
point
of
view,
those
these
two
schemes
seem
to
be
equivalent
and
also
from
a
repair
rate
point
of
view.
They
produce
the
same
overhead
from
a
bandwidth
perspective
so
which
one
is
the
better
one
which
one
to
pick
for
certain
situations.
G
So
if
you
take
the
next
slide,
if
you
look
at
the
something
like
a
uniform
traffic,
so
what
do
I
mean
by
that
in
the
in
the
figure?
Here
we
gave
every
symbol
a
different
color
indicating
that
they
arrive
at
different
times.
We
also
put
a
deadline
which
means
that
the
expire
after
80
milliseconds,
so
in
this
case
every
symbol
arrives
after
10,
milliseconds
and
expire
after
80..
G
So
you
see
that
symbol
number
1
will
expire
when
symbol
number
nine
arrives
indicated
by
this
sort
of
dashed
gray
line
right
and
the
what
you
can
also
notice
here
is
that
the
distance
to
repair
is
minimized
right.
We
have
sort
of
shrunk
down.
We
were
generating
repair
as
quickly
as
possible
for
this
specific
repair
rate.
G
So
so
there's
no
way
that
we
can
move
the
repair
closer
to
this
or
sort
of
spread
out
the
repair
uniformly
in
all
the
symbols
right,
so
in
all
the
symbols
and
they
get
the
same
protection,
all
of
them
are
still
covered
by
four
packets
and
the
latency
penalty
of
losing
symbol.
One
is
10
milliseconds,
because
r1
is
generated
directly
after
s2.
G
If
you
then
take
the
4
comma
2
repair
pattern
under
the
same
on
the
next
slide
on
the
same
under
the
same
conditions,
if
you
move
to
yeah
yeah,
if
you
then
take
the
sort
of
the
other
repair
pattern,
you
will
see
that
we
we
have.
The
same
protection
here,
but
but
we
are
not
minimizing
the
distance
to
repair
so
actually
what
will
happen
is
that
if
we
lose
the
first
symbol
s1,
we
actually
have
to
wait.
30
milliseconds
to
generate
the
repair
and
fix
that
packet
loss.
G
But
what
is
interesting
is
what
happens
when
we
actually
look
at
something
like
a
thirsty
traffic
pattern
and
if
you
take
the
next
slide
so
here
you
see
that
we
have
the
first
four
symbols.
They
actually
arrive
at
the
same
time.
So
this
could
be
a
video
frame
consisting
of
four
network
packets,
for
example,
and
now
it's
all
the
same,
but
but
then
in
real
applications.
Of
course,
the
video
frames
would
be
sort
of
made
out
of
different
amounts
of
packets,
but
just
for
simplicity.
G
G
G
We
still
have
the
same
sort
of
distance
to
repair
right,
because
the
four
packets
arrive
at
the
same
time,
but
now
r1
and
r2
both
cover
all
four
packets
inside
the
frame,
which
means
that
a
and,
if
you
then
look
at
the
columns
again,
you
can
see
that
now
everybody
is
covered
by
four
repair
packets
again.
So
so
essentially,
this
seems
like
a
better
pattern
for
for
for
burst
traffic.
G
But
if
you
have
bursty
traffic
like
a
video
feed
coming
from
a
camera,
for
example,
it
actually
makes
more
sense
to
make
the
sort
of
the
the
the
coding
follow
the
bursts
of
the
traffic
in
order
to
maximize
the
protection
of
the
symbols
that
you're
transporting.
And
if
you
want
to
read
a
little
bit
more
about
it,
we
we
wrote
some
stuff
about
it
on
both
in
some
documentation
for
one
of
our
coding
libraries,
but
also
on
our
blog.
G
You
can
utilize
that
knowledge
in
your
fec
scheme
to
actually
make
the
best
possible
protection,
and-
and
you
have
to
do
that
if
you
want
to
get
the
best
possible
protection
and
if
you
want
to
get
in
touch
with
me,
you
can
reach
me
on
my
email
or
you
can
visit
our
website,
which
also
has
some
links
to
contact
us
and
from
further
discussions.
But
yeah.
G
A
Thank
you,
martin
for
this
presentation.
Yes,
it's
quite
interesting
because
it's
more
complex
than
what
we
would
think
deciding
how
to
to
split
interleave,
all
those
repair
packets
with
the
source
flow
source
flows.
There
might
be
several
flaws
as
well.
It's
not
that
trivial.
So
very
interesting!
We
are
running
short
of
time.
Sorry,
for
that
we
are
obliged
to
to
very
quickly
stop
this
session,
but
I
suggest
we
continue
on
the
mailing
list.
B
I'm
sorry
my
my
audio
was
off.
No,
I
think
it's
a
good
idea
to
continue
for
sure
on
the
mailing
list,
especially
as
regards
the
the
open
documents
again.
Thank
you
morton
for
the
presentation
and
yeah
we're
going
to
be
cut
off
in
one
minute.
So
I
guess
not
I'm
fully
awake.
I
don't
know,
I
don't
know
what
what
do
you
do
in
montreal
at
3
30
in
the
morning?
If
anybody
has
a
an
idea,
maybe
I'll
just
read
something.
Thank
you.