►
From YouTube: IETF105-NWCRG-20190726-1000
Description
NWCRG meeting session at IETF105
2019/07/26 1000
https://datatracker.ietf.org/meeting/105/proceedings/
C
B
Okay,
I
think
we're
going
to
start,
since
some
people
need
to
leave
and
it's
Friday.
So
thank
you
for
showing
up
again.
This
is
the
coding
for
efficient
network
communication
research
group,
where
we
do
all
kinds
of
fun
things
to
recover,
lost
packets,
so
again,
okay,
so
a
goal
obviously
is
to
foster
research
in
network
and
application
layer
coding
and
to
improve
network
performance,
and
so
what
we
are
doing
for
those
of
you
who
historically
were
not
with
us.
B
So
this
is
the
usual
note.
Well,
I
know
that
there's
going
to
be
another
approach
to
coding
later
in
the
presentation
and
I
hope
the
people
Mihiel
and
company
that
you
have
really
looked
at
note.
Well,
because
I
know
you
work
for
a
company.
So
if
there's
any
IP
are
related
to
your
presentation,
please
mention
it.
B
We
really
have
moved
I
think
this
group
has
done
it
much
better
than
my
other
group.
We
have
moved
very
much
into
the
github
to
maintain
the
list
of
papers
and
drafts
and
related
material.
Obviously
the
Charter
is:
did
that
attract
her?
Like
everybody
else,
we
have
a
mailing
list
that
you
probably
all
are
all
subscribe
to.
Our
slides
are
going
to
be
on
the
github
and
under
data
tracker
and
we're
going
to
have
net
echo
and
actually,
when
we
did
the
you
who
got
to
put
that
when
we
did
the
hackathon.
B
That
was
also
a
slack
channel,
which
was
interesting
for
the
people
who
were
part
of
the
hackathon
to
be
able
to
collaborate.
So
this
is
the
agenda.
We
have,
in
fact
six
presentation,
I,
think
the
hackathon
feedback
was
going
to
be
pretty
fast.
Then
we
have
a
update
on
that.
We're
coding
and
satellite
then
updates
on
what
we
are
doing
for
coding
for
quick
and
there's
actually
three
presentations
on
that.
B
There's
the
approach
that
we're
doing,
which
we
do
here,
then
quick
and
you're,
going
to
see
that
there's
a
presentation
that
does
it
as
some
kind
of
a
quick
tunnel
or
I
see
it
coding.
Tunnels
were
quick
and
then
I'm
going
to
do
a
small
presentation
on
what's
going
on
with
the
other
groups
that
are
related
to
this.
Actually,
at
the
chairs
dinner
on
Wednesday,
we
all
recognize
that
they
should
be
more
collaborations
between
the
different
groups,
because
a
lot
of
time,
what
we're
doing
is
closely
related
buzzie
its.
F
She
was
about
180,
intern
dress,
loser
in
the
group.
We
will
talk
about
a
few
of
them
today
morning,
so
I
did
not
mention
them
in
the
lists,
but
otherwise
there
was
no
update
for
the
network
korean
forces,
yen
and
yen
requirements
and
challenges
engine
draft.
So
we
discussed
with
the
authors
and
they
explained
that
didn't
have
time
to
do
that
for
this
side,
chef
meeting,
so
their
position
and
agreed
to
to
have
it
ready
for
for
next
idea.
F
G
Just
by
way
of
advertising
the
the
base
protocol
specs
for
CCN
have
been
published
as
RFC
s
experimental
RFC,
so
we
have
a
concrete,
pretty
stable
base
to
do
the
binding
of
any
protocol
machinery
that
you
for
the
network
hurting
to
refer
to,
so
something
we
might
want
to
tell
them
is
when
they
change
their
references
to
the
MC
version
thanks.
Okay,
thank
you.
F
There
was
a
slight
update
from
the
RNC
based
symbol,
representation
documents
not
much
difference,
but
the
office
did
not
believe
it
was
meaningful
to
have
a
new
presentation.
Today
there
was
a
much
bigger
update
for
the
bats
coding
scheme
for
multi
of
data,
transport
documents
and
I
hope
we
will
be
able
to
discuss
about
this
at
next
ITF
in
Singapore.
F
And
finally,
the
good
news
also
is
not
work
being
done
in
this
group,
but
closely
rated
the
free
documents
that
I
pushed
forward
in
DTS,
vwg
working
group
or
fake
frame
extension
for
sliding
window
codes
and
the
second
one
on
Alice's
lining
Widow
cards
and
the
third
one
on
tini
mg42
PNG
for
being
used
in
RC
and
perhaps
somewhere
else
protocols,
all
those
free
documents
of
being
accepting
the
grid
by
GE.
And
now
there
are
the
I've.
Cid
talked
you.
So
that's
the
good
news.
F
A
F
So
this
is
the
swift
codec
a
katana,
just
to
remind
you.
The
goals
of
this
Agathon
is
to
design
reference,
open
source
and
free
correct
for
slanging
window
cards.
This
is
the
third
time
you
meet
the
we.
We
did
the
work
we
organized
the
work
in
such
a
way
to
be
able
to,
in
the
first
step,
produce
something
that
is
somewhat
compatible
with
what
we
did
in
the
I'll
see
draft,
so
just
end-to-end
encoding
and
decoding,
no,
nothing
in
the
middle.
F
F
Another
goal
is
to
challenge
our
Jerrica
api
in
the
draft
that
specifies
our
to
interact
with
such
a
collection
of
something
else
that
would
become
so
in
terms
of
API.
So
this
time
the
team
was
a
bit
smaller
than
it
used
to
be.
In
the
past
we
were
free
people,
silic
was
there
for
the
two
days,
Saturday
and
Sunday,
but
was
obliged
to
work
also
in
a
different
project,
so
he
was.
He
was
sharing
his
time
between
these
two
projects.
F
Francois
Michel
was
there
on
Saturday
remotely,
but
he
contributed
actively
and
as
far
as
I'm
concerned,
I
was
supposed
to
be
there,
both
from
Saturday
and
Sunday
and
fortunately,
I
had
some
programs
and
I
was
only
able
to
to
attend
this
Sunday.
So
that's
all
of
this
to
say
that
okay,
we
didn't
make
as
much
progress
as
we
anticipated
as
we
would
decide.
But,
okay,
it's
like.
We
also
add
some
contributions
from
umeƄ.
We
would,
since
the
previous
ITF
meeting,
managed
to
further
update
some
parts
of
the
correction.
She
will
continue
on
doing
that.
F
F
The
ending
part
is
more
or
less
well.
The
main
part
of
the
encoder
is
done.
We
still
have
to
include
a
few
additional
work,
a
foolish
move
method
for
sharing
a
few
things
anyway,
but
most
of
it
is
done.
The
decoder
is
in
progress,
that's
the
most
complicated
part.
This
is
where
we
have
to
manage
and
solve
linear
systems
and
do
all
this
complex
mathematical
machinery.
F
F
So
the
next
step
in
for
fight
EF,
I
kep
on
in
the
next
ITF
Agathon,
will
be
to
have
something
that's
working
that
managed
to
do
encoding
and
decoding
and
interoperate
I
think
it
may
be
physical.
If
we
manage
to
do
some
work
in
between
and
then
we
will
continue,
as
I
said,
with
the
oil
and
sea
so
being
able
to
do
rien
coding
within
the
network.
So
that's
the
goal.
I
don't
know.
If
there's
any
comment,
question
no
ok,
custom.
H
F
H
F
Think
there
will
be
potential
for
performance
improvement
at
the
end,
a
significant
performance
improvement
for
what
I
saw
in
the
mathematical
operations.
Then,
with
a
few
things
we
can,
that
could
be
done,
but
whoever
wants
to
contribute
on
this
particular
point
is
welcome,
of
course,
to
do
that
now.
Also,
some
conflict
of
interest
for
some
of
us,
myself
included
I,
have
a
proprietary
implementation
of
this.
F
F
J
We
were
in
working
who
pressed
call
process
since
the
last
ACF,
and
we
had
lots
of
comments
from
john
and
lloyd
and
yourself
forgot
you
on
the
slide.
Sorry
for
theft,
I
should
have
put
it
some
like
and
many
others
well,
basically
think
there
were
some
very
deep
changes
in
all
the
wording
and
lots
of
different
aspects
on
the
draft
rather
than
just
presenting
a
deef,
as
we
did
a
lot
recently
for
this
draft.
J
So
coding
in
the
document
is
a
linear
combination
of
packets
and
operates
above
the
network
layer,
and
it's
true
that
for
that
previous
versions
of
the
draft
was
not
always
very
clear
if
there
were
lots
of
small
issues
in
wordings,
so
I
think
for
that
and
the
reviews
in
the
comments
we
received
our
very
own
food
in
improving
the
document.
So
we
have
the
break
TVs
to
detail.
What
is
a
multi
gateway
satellite
systems
to
identify
cases
where
ad
encoding
is
what
happened
so
we
have
residual
losses
and
to
end.
J
So
if
we
go
more
into
the
details
on
what
the
taxonomy
document
says
is
that
we
do
not
consider
a
physical
layer
coding,
all
that
is
physical
layer
related
is
out
of
the
scope
of
the
document.
We
have
FEC
that
operates
above
the
network
layer
and
we
only
have
a
combination,
linear
combination
of
packets.
J
We
don't
know
any
application
level
coding
such
as
it
could
be
the
case
to
compress
the
video
flow,
for
example,
and
we
see
that
this
activity
has
been
very
widely
discussed
in
the
research
community
and
we
think
document
Alps
in
the
notifying
we're
using
coding
is
relevant.
Just
a
quick
clarification
question.
G
J
G
G
J
Thank
you.
So
this
is
a
description
of
what
you
can
find
in
to
the
generic
satellite
system
today
following
the
gbps2
standard.
So
when
I
say
above
the
network
layer
is
that
we
don't
play
with
these
BB
frames
and
specific
DBS
to
latest
standards,
because
this
is
very
out
of
the
scope
of
the
ITF
and
what
so
it's
so.
This
is
I
think
most
more
to
introduce
some
of
the
wording
that
I
used
in
the
rest
of
the
documents
as
towards.
J
For
the
first
use
case,
I
will
now
go
through
the
different
use
cases
and
for
all
some
of
them
these
are
not
high
level
description
use
cases.
This
one
is
the
use
case
where,
basically,
we
have
two
satellite
terminals
communicating
to
each
other
to
the
recording
server.
On
the
return
link
we
have
with,
we
have
settled
at
Terminal
A,
who
sends
a
satellite
on
Nibiru
things
be,
and
basically
the
coding
server
sent
a
and
B
on
the
forward
link.
So
that
is
huge
capacity
optimization.
J
We
have
introduced
this
use
case
not
really
because
there
are
lots
of
industrial
and
application
use
cases
that
are
relevant,
but
this
is
something
that
we
can
do
and
has
been
demonstrated
using
will
satellites
in
a
SMS
2010.
So
we
should
at
least
that's
why
we
mention
it
they've
the
variable
multicast,
when
we
have
a
multicast
and
flow
going
to
different
users,
satellite
terminal,
ay
and
B,
but
we
have
packets
losses,
so
a
and
B
can
send
the
to
the
mallika
server.
J
The
packets
that
are
not
received
and
a
em
flow
can
induce
coded
packets
to
recover
what
has
been
lost.
We
agree
that
this
could
be
done
by
lots
of
other
multicast
about
CAD
systems
such
as
norm
or
fruit,
but
they
do
not
use
the
limited
to
block
coding
and
the
newt
actually
supports
sliding
window
schemes.
So
that
is
why
we
mentioned
that
in
the
document.
J
Another
use
case
is,
it
would
access
if,
when
you
have-
and
that
is
really
typical
in
many
satakam
applications,
when
you
have
ample
users
in
the
boat
or
in
oil
platform
or
whatever,
there
is
not.
Only
the
satellite
satellite
is
one
of
the
many
links
that
are
available,
so
we
can
have
a
CPE
on
the
end
user
side
and
a
concentrator
in
the
operator
network.
J
So
we
have
lots
of
MPCP,
for
example,
could
go
through
these
networks,
and
sometimes
there
are
packet
losses
on
one
of
these
links
and
in
using
coding,
techniques
could
be
introduced
both
at
the
CPE
or
the
concentrator,
to
cover
an
cup
from
packet
losses.
So
this
is
open
lots
of
research
questions
on
how
do
you
impact
on
MPT,
CP,
congestion
control,
for
example?
So
that's
why
we
mentioned
that
in
this
document.
J
This
use
case
concerns
a
lot
more
than
the
others.
I
think
that
in
this
figure
you
have
basically
your
web
applications
every
hour
that
com-system
a
multi
gateway
system.
So
if
you
look
at
the
operator,
thank
you
that
fat
growing
segment.
This
is
what
good
light
look
could
look
like.
We
have
tens
of
gateways
in
Europe,
for
example,
and
then
you
have
a
satellite
that
you
use
a
dvb-s
to
standards
to
send
the
data
from
the
Gateway
to
that
right,
Tammy,
no
and
the
user
DiBiase's
to
standards
for
the
returning.
J
J
So
in
this
case,
we
don't
have
only
an
IOT
network,
but
we
also
have
an
IAT
with
losses
network
and,
in
this
case,
I
think
that
if
people
working
on
quick
and
fake
are
looking
for
use
cases,
if
they
can
make
it
work
in
this
use
case,
that
would
help
us
a
lot.
So
if
you
want
sizing
numbers
or
use
cases,
that
would
be
very
relevant
for
you
to
experiment
and
for
us
to
have
the
results,
because
this
is.
J
We
have
not
experimented
network
coding
in
this
version,
but
we
have
a
satellite
at
home.
We
have
a
good
wave
of
satellite
terminal.
So
this
is
a
real
experiment.
You
think
a
real
satellite
flying
above
and
basically
we
have
an
HTTP
to
transfer
of
2
megabytes
file
from
the
two
endpoints,
and
here
we
have
one
opossum
classes.
I
will
not
go
deep
into
the
details,
but
because
I
have
all
the
results
and
show
you,
if
you
are
interested,
you
can
have
a
chat.
J
But
basically,
if
we
look
at
the
page
loading
time
without
these
losses,
there
is
no
congestion
is
only
one
to
make
by
megabytes
file
transfer.
Basically,
we
have.
We
compare
these
PDF
without
and
with
losses,
and
what
we
can
see
is
that
when
you
have
one
person
losses
for
the
median
median
page
loading
time,
we
have
more
than
five
seconds
increase
and
for
the
80%
of
the
cases
we
have
18
seconds
increase,
and
so
we
go
from
11
to
30
seconds
so
that
very
bad
quality
of
experience.
So
we
need
to
do.
J
J
Another
use
case
we
haven't
satellite.
Is
that
I
told
you
that
in
this
use
case
we
have
no
losses,
but
there
are
cases
where
we
have
loss
reasons
that
are
a
satellite
link
and
we
think
that
in
these
cases
the
physical
layer
is
very
constrained,
so
providing
higher
layers
relevancy
can
help
in
releasing
the
constraints
on
the
physical
layer.
J
Sorry
for
mentioning
the
physical
layer
here-
and
this
is
more
something
that
I'm
not
really
perfectly
familiar
with,
but
what
I
can
tell
you
is
that
we
have
basically
the
losses
pattern
you
have
when
you
are
an
antenna
on
the
train,
so
we
can
see
that
we
have
this.
We
have
very
low
snr
areas
of
the
DBS
2x
standard,
so
you
have
here
the
signal-to-noise
ratios
and
the
modulations
that
are
used,
and
in
this
context
we
have
raised
your
losses
and
the
picks
with
here
are
basically
the
poles
along
the
railway.
J
So
you
have
repeated
losses
in
in
another
case,
we
have
been
looking
at.
We
have
an
LMS,
so
basically
mobile
and
mobile
user,
so
neither
in
moving
through
the
trees
a
lot
of
issues.
So
we
have
this
kind
of
patterns
these
traces
are
available
and
then
to
the
lists.
If
you
want
to
play
with
that,
we
have,
we
can
easily
play
them
in
open
source
tools.
J
We
have
so
if
you
want
to
so
to
put
that
in
your
experiments,
but
would
be
great,
we
have
been
another
use
case
that
is
very
trendy
in
that
calm
industry.
At
the
moment
is
using
optical
links,
but
the
problem
with
optical
link
that
we
have
at
the
moment
it's
at
sometimes
a
cloud,
and
so
we
have
on
a
very
short,
fading,
even's
I,
don't
understand
everything
in
this
figure,
but
I
put
it
here
and
the
reference
just
to
explain
that.
J
Basically,
we
have
lots
of
people
working
on
it
and
we
want
to
explain
them
that
they're,
not
there's,
not
much
needs
in
improving
a
lot
of
equal
layer.
Let
her
let
us
deal
with
improving
the
quality
of
experience
and
dealing
with
these
losses.
So
we
expect
to
do
some
measurements
in
this
use
case
in
the
next
coming
months,
but
we
have
done
some
results
with
the
previous
traces
I
had
shown
earlier.
So
that's
the
train
that
the
mobile
user.
So
this
is
an
open
source
tool
we
have
and
we
we
through
port.
J
So
if
you
want
to
use
it
it
here,
everything
is
on
the
wiki.
Everything
is
available,
so
we
have
a
gateway
of
that
comm
satellite
terminal
between
the
fat
and
the
factory
know
we
have
we
induce
these
losses
and
we
have,
on
top
of
that,
Anu
has
recorded
shadow
with
a
sliding
window
effect
with
the
K
or
4
in
the
age
of
20,
I,
hope,
I,
think
the
room
is
familiar
with
these
kind
of
schemes.
If
you
want
more
details,
we
can
have
a
chat,
but
basically
what
I
show
here
is
the
residual
losses.
J
So
on
the
train
case,
because
the
pattern
is
very
big,
you
are,
we
can
actually
find
the
parameterization
and
K
value
of
K
that
solve
all
the
problem
with
at
some
point.
K
is
too
high
and
basically
we
have
residual
losses
Servais
and
in
the
other
case,
the
pattern
is
so
strange
that
we
can.
We
can't
actually
do
anything
with
the
basic
scheme
represented,
so
I
think
that
this
is
very
open
research
issue
that
may
be
of
interest
for
the
persons
in
this
group.
J
We
also
are
trying
to
see
all
this
impact
on
TCP
first
and
then,
when
we
have
mpeg-dash
traffic
and
because
that
is
the
use
case
that
we
are
interested
in,
and
we
think
that
is
very
at
least
funny
to
look
at,
because
when
you
have
all
these
multiple
layers
that
play
to
each
other
and
strange
things
happen
with
at
least
interesting
use
case.
And
so
how
much
time
do
I
have
left
so
another,
but
that
we
go.
C
J
I
think
that
yeah,
if
I
am
might
be
beating
in
the
legend
here,
is
where
we
could
add
meta
coding,
because
a
network
function
block
is
basically,
we
have
IP
packets
coming
in
and
that
IP
packets
coming
out,
and
so
we
can.
That
is
where
we
have
all
these
pipes
and
all
lots
of
firewalls
and
all
these
things
you
could
expect
and
access
gateways
as
they
have
IP
packets
coming
in.
They
could
also
do
some
things
on
it,
and
so
one
of
the
the
trend
at
the
moment
is
to
try
to
thought.
J
Basically
that
is
a
use
case
where
we
have
lots
of
gateway
and
overs
for
lots
of
values,
reasons
we
may
want
to
move
the
traffic
from
one
gateway
to
another,
and
in
this
case
we
may
have
losses.
So
we
may
be.
That
may
be
a
use
case
of
interest
for
network
owning
enough
of
the
research
challenge
part.
So
we
know
that
we
have
proprietary
solutions
to
hosts
coding
techniques
in
terms
of
deployment.
We
are
I
know
that
it
is
possible,
but
then
we
have
a
problem
on
the
interactions.
J
J
Another
important
thing
is:
it
is
a
good
thing
to
have
real
variability
and
to
have
more
resiliency,
but
the
problem
is
that
capacity
is
expensive
in
the
satellite.
So
there's
a
trade-off
in
how
much
residency
you
had
and
how
much
you
can
improve
the
quality
of
experience.
But
how
much
does
it
costs
in
capacity?
Because
that's
a
big
open
question
we
have,
and
then
that
is
more
related
to
another
working
group.
That
is
all
the
neutralization
thing,
it's
more
because
we
have
lots
of
CTE
and
gateways
and
data
centers.
J
Now
we
are
moving
toward
this
in
satellite.
So
basically
we
can
ask
easily
these
coding
techniques
end
to
end
and
between
at
least
two
endpoints,
which
more.
How
do
we
integrate
this
solution
in
and
virtualized
environment?
That
is
something
that
is
maybe
not
a
research
challenge,
but
at
least
something
to
do
cuts
debris,
because
when
you
go
deep
into
the
details
that
way
issues
may
commit.
J
We
have
to
open
issues
on
the
github
because
we
have
very
happy
to
use
github.
So
if
you
have
any
comments
of
the
document,
we
are
happy
to
welcome
emails,
but
issues
on
the
github
is
way
better,
because
it's
very
easier
way
for
us
to
explain
to
you
how
we
assess
your
comments.
So
we
had
a
comment
on
virtualization
and
the
research
challenges
were
basically,
we
proposed
to
close
it.
J
Because
the
question
was
because
we
are
punting
now
our
comments
was
that
there
were
no
ID
on
what
the
section
means.
So
do
we
want
to
be
authorized
antennas
or
virtualize
reflector.
So
that
is
not
what
we
want
to
do,
but
we
try
to
make
it
clearer
in
the
text
and
then
another
comment
was
on
DTN
and
all
these
ccsd's
stuff,
we
don't
want
to
mess
with
CCSD.
J
Yes,
that's
an
also
standard,
it
has
its
specific
use
case
in
satellite
industry
and
we
don't
want
to
consider
that,
and
so
we
just-
and
we
explained
in
this
document
that
we
are
just
using
DVB
as
an
example
of
what
a
satellite
system
is
and
not
as
a
base
line,
and
we
don't
have
a
specific
location
trail,
even
if
rid
of
it.
So
we
published
a
closed
issue
as
well.
F
K
J
J
F
F
Yes,
so
what's
next
step,
so
we
received
comments
from
Scott
recently
yesterday.
Thank
you
very
much.
I
suggest
you
answer
those
commands
during
a
date
and
then
I
see
no
reason
not
to
start
a
new
working
group
a
result
group.
It's
not
a
working
group
research
group
Lascaux
on
this
dating
documents;
okay,
no
opinion!
No!
It's!
Okay!
F
So
this
is
a
technical
presentation
of
what
we
have
done
for
this
coding
for
quick
document.
We
change
a
lot
of
things
I,
as
I
will
explain.
So
this
is
joint
work
with
Francois,
my
shoe
and
onion.
So
just
a
summary
of
what
we
the
situation
at
previous
ITF.
There
were
two
proposals
for
adding
quick
earth
adding
FEC
within
quick.
The
one
that
I
mentioned
here
is
the
the
one
what
was
implemented
in
previous
revision
of
this
document.
The
idea
was
to
do
that
within
a
stream.
F
You
know
stream
notion
of
trim
from
quick
with
good
properties,
meaning
that
some
of
the
streams
have
more
requirements
in
terms
of
reliability
and
others,
so
it
makes
sense
to
protect
more
new
streams
than
the
rest.
There
was
also
a
good
property
that
it
was
possible
to
do
that
without
changing
at
all
at
all
the
quick
sauce
packet
you're
in
your
packets.
So
that's
great
to
do
that,
but,
of
course,
there
are
consequences
side
effects.
F
One
of
those
side
effect
is
the
fact
that
okay,
this
is
a
stream
concept,
so
being
a
stream
concept,
there
is
no
separate,
there's
no
boundary.
No
notion
of
boundaries,
and
it's
doesn't
it's
not
something
that
could
be
easily
applicated
to
data
graham
approach,
another
way
to
transport
data
transport
build
within
quick.
So
that's
not
very
good.
From
this
point
of
view,
there's
also
another
side
effect
that
was
a
bit
annoying.
This
notion
of
stream
makes
it
in
post.
F
It
makes
it
possible
for
a
symbol
to
straddle
several
packets
and
that's
something
that
we
don't
want
so
much.
So
the
second
proposal
from
Francois
was
doing
it
totally
differently.
The
idea
was
to
protect
packets,
to
consider
packets,
consider
the
payload
of
this
packet
and
to
segment
this
payload
into
symbols
so
as
to
do
a
protection
for
all
those
frames
within
these
packets
within
those
packets.
So
it's
another
way
to
do
that.
It
preserves
packet
boundaries.
That's
a
good
point
when
you
recover
something,
you
know
that
it
fits
inside
a
given
quick
packets.
F
You
also
had
this
good
property
that
saucy
motion
ever
straddles.
They
were
quick
packets.
So
that's
also
something
nice
with
some
additional
one
side
effects:
that's
okay!
We
need
to
change
which
will
be
the
original,
quick
packets,
but
something
that
can
accommodate,
and
it's
also
bit
more
difficult
to
try
to
protect
a
subset
of
a
packet.
So
do
that
think
that
we
will
elaborate
a
little
bit
more
in
this
presentation
too
much
into
details
at
the
moment.
F
So
we
add
discussion
so
together
and
we
decided
to
change
totally
the
way
we
propose
to
do
efficient,
quick
and
to
follow
what
more
or
less
what
consol
was
proposing,
namely
doing
that
inside
packet
cross
packet
friends.
So
that's
what
is
now
implementing
in
this
every
revision
of
this
document.
We
added
a
few
additional
features,
as
I
will
explain.
So
many
things
are
still
the
same.
F
Several
key
architectural
concepts
remain,
one
of
them
being
that
we
apply
FEC,
encoding
and
decoding
before
doing
encryption,
which
means
that
middle
boxes
will
not
be
able
to
do
anything
from
this
data
flow.
It
will
be
an
encrypting
data
flow,
no
way
to
distinguish
between
source
and
repair
packets.
There's
no
way
to
do
that.
That's
the
first
aspect.
F
Another
aspect
is
that,
as
before,
we
try
to
provide
a
generic
picture
which
is
compatible
Morris
with
any
fax
scheme
that
we
may
want
to
use
within
quick,
and
we
have
moved.
We
move
all
the
facts,
keep
specific
considerations
our
to
do
that
with
such
or
such
cut,
for
instance,
within
a
separate,
dedicated
internet
drafts.
So
that's
the
case
with
this
existing
with
the
existing
I'll
see
for
quick
internet
draft.
F
The
third
point
that
we
kept
is
that
we
absolutely
want
to
be
congestion
control
compatible.
We
do
not
want
to
interfere
with
the
way
a
congestion
control
may
happen
within
quick,
so
we
use
dedicated
recovered
friends
to
inform
the
sender
that
some
packet
has
been
lost
but
has
been
recovered
by
a
fish
decoding
at
the
receiver,
so
so
that
the
sender
can
take
it
into
account.
F
G
F
G
If
multipath
has
done
not
on
a
stream
basis
itself,
but
on
a
packet
basis,
the
second
thing
is
this:
recovery
frame
thinks
is
very
nice.
Have
you
thought
about
whether
this
also
could
be
used
to
change
the
level
of
coding
so
that
you
get
recovered
frames
in
there's
very
few
of
them?
Based
on
your
current
coding,
you
might
want
to
reduce
the
coding
or
increase
it
if
the
covered
frames
are
showing
a
lot
of
recovered
frames.
Yes,.
F
I
F
F
So
the
the
key
point
in
all
those
in
this
work
is
the
question
I'll
doing
not
quick
packets
to
source
symbols.
That's
really
the
key
aspects,
and
there
are
several
things
to
consider.
First
of
all,
of
course,
the
quick
sauce
packet
is
of
variable
size,
but
we
absolutely
want
to
keep
the
symbol
size
fixed
for
the
world
ration
of
a
quick
connection,
because
next
things
much
simpler
to
manage
within
the
encoder
and
decoder.
If
we
have
this
fixed
property,
fixed
size
property.
F
F
Of
course,
if
we
use
larger
assimil
size,
that
will
be
perhaps
the
opportunity
to
fit
all
the
quick
packet
payload
within
a
single,
so
symbol
mu,
so
that
makes
things
easier
to
manage,
but
at
the
same
time,
if
we
have
variable
size,
bluntly,
viable
size,
sauce,
packets,
a
lot
of
small
sauce
packets
and
from
x
times,
bigger
sauce
packets,
then
it's
a
waste
it
will
include.
It
will
generate
more
overhead
transmission
over
it.
So
there
is
a
waste
of
efficiency.
From
this
point
of
view,
so
we
need
to
find
balance.
F
F
That's
something
that
will
not
be
fixed
inside
these
documents
into
a
generic
framework,
that's
something
that
remains
to
be
adjusted
based
on
the
use
case
based
on
deployment
considerations,
so
it
will
be
so,
but
we
have
this
flexibility
to
manage
at
the
same
time,
small
or
larger
size
since
symbol
size
in
this
document.
That's
what
simple
is
most
important.
F
F
We
add,
first
of
all,
we
add
padding
to
packet
payload
in
order
to
be
a
multiple
of
e
minus
one,
plus
this
a
minus
v
initial
chunk.
So
we
need
to
add
this
to
have
a
multiple
number
of
chunks.
Well,
no,
sorry,
the
the
the
padded!
Sorry,
the
padded
length
must
be
a
multiple
of
e
minus
one
and
E
minus
five.
Why
does
the
difference
between
a
minus
5
and
E
minus
1
will
be
explained
later?
F
F
So
by
doing
by
putting
this
padding
at
the
beginning,
rather
than
the
end
of
the
packet
payload,
it
makes
it
possible
for
decoder
to
skip
all
those
padding
frames,
even
if
the
size
of
the
frame
is
not
specified
on
the
other
friend
is
not
specified,
which
is
something
which
may
happen.
So
this
is
a
bit
complex,
but
by
that
at
the
beginning
of
the
parrot,
instead
of
at
the
end
of
the
period
removes
this
requirement
to
have
an
additional
signalling
film.
F
That
will
tell
you
how
long
it
is
how
long
the
payload
is
so
that
for
the
receiver
to
skip
the
final
padding,
if
we
are
doing
that
this
way.
So
it's
something
that
is
a
quite
efficient.
So
we
do
that
that
padding
and
we
then
segment
this
padded
packet
payload
into
chunks.
So
in
this
example,
we
have
three
packets,
wick,
wick
packets
and,
as
you
can
see,
there
are
four
chunks
for
the
first
one
three
for
the
second
and
front
ones.
So
that's
the
first
step
we
have
chunks
now.
F
So
what
do
we
do
with
chunks?
Now
we
need
to.
We
need
to
do
a
mapping
between
chunks
and
source
symbols
and
the
way
we
do
that
is
by
prepending
one
bytes
of
metadata.
I
will
explain
you
what
is
inside
this
one
byte
metadata
and
then
for
the
first
chunk.
We
have
this
additional
packet
number,
which
is
a
quick
packet
number
which
is
protected
explicitly
in
the
first
row,
symbol
of
a
quick
packet.
So
the
association
of
this
metadata
press
packet,
number
press
packet
trunk-
is
constitute
this
awesome.
F
So
that's
for
the
first
chunk
of
a
quick
packet
and
the
remaining
chunks
of
sauce
packets.
Only
this
metadata
there
is
no
need
to
repeat
the
packets
and
number
that
will
be
anywhere
protected
by
the
previous
awesome.
So
in
that
case
we
simple
is
this
method
that
I
went
back
metadata,
press
packet,
choke
and
all
of
these
constitute
disassemble.
F
So
that's
the
way
it
works
so
now
what
we
put
inside
this
metadata
byte.
Well,
it's
pretty
simple.
There
are
three
bytes
sorry.
There
are
three
bits
that
are
used.
The
first
one
is
just
to
indicate
the
N
field
is
just
to
indicate
that
there
is
a
packet
number
that
will
follow.
Four
bytes
packet
number,
the
s
and
E
bits
are
there
to
seen
all
that.
F
Okay,
this
is
the
first
chunk
of
a
quick
packets
for
the
fatherĆs
s
start
needs
or
the
last
chunk
of
a
quick
packet
for
the
e
bits,
and
with
this
we
can
inform
the
decoder
we
can
infer
the
receiver
after
decoding
back.
Okay,
that's
the
first
chunk.
That's
the
last
chunk!
Those
chunks
are
in
the
middle
or
maybe
there's
a
single
chunk
for
a
given
packet
payload.
That's
the
only
chunk
because
there
will
be
at
the
same
time
the
first
and
last
bits
that
will
be
set.
F
So
that's
an
easy
way
to
do
that
and,
as
I
said,
I
said
number.
This
is
also
important
to
add
this
quick
packet
number
inside
some
of
the
chunks,
because
no
sorry
not
the
tracks,
but
the
source
symbols,
because
it's
something
important
for
decoder
to
indicate
what
packets
has
been
recovered
by
the
FEC
decoding
process.
I.
Remember
that
I
is
this
recovered
frame.
That
will
go
to
the
sender
to
indicate
to
the
sender
that
this
frame
has.
This
packet
has
been
decoded
as
been
lost,
but
decoded.
F
So
we
need
to
indicate
to
the
receiver
which
packet
it
is
and
since
the
quick
header
is
not
protected
by
FEC
itself,
we
need
to
carry
this
information
in
some
other
way
and
we
do
that
by
including
this
quick
packet
number
inside
the
first
symbol
of
our
packets.
So
that's
a
trick
to
inform
the
decoder.
We
went
from
the
sender
that
this
this
packet
and
not
another
one,
has
been
recovered.
So
that's
why
it's
important
so
the
big
picture
now,
which
way
so
that
we
have
this
quick
packet.
We
do
padding
initial
padding.
F
We
split
the
contents
of
this
packet,
payload
plus
padding
into
chunks.
In
this
example,
we
have
four
tracks
and
then
we
create,
with
this
additional
metadata
and
potentially
for
the
first
chunk
for
the
first
sample,
the
packet
number.
We
create
those
source
symbols
and
this
way
it's
working,
it's
working
I
just
want
to
convince
you
that
it's
working,
that's
a
an
example.
F
So
let's
imagine
that
in
orange
we
received
or
read
accordion
or
maybe
something
is
missing,
several
soft
symbols
at
the
beginning
and
for
the
for
the
for
the
last
part
and
in
the
middle
at
some
point
of
time
the
decoder
can
decode
those
for
source
signals.
So
by
looking
at
the
first
pie
at
the
first
bite
of
each
source
symbol,
it
will
determine
that
for
the
first
one,
this
is
the
first
drink
or
the
packet
for
the
last
so
simple.
It
really
determined
at
this
last
one
and
was
to
in
the
middle
just
in
window.
F
So
it
will
determine
all
of
this
and
you
will
be
able
to
construct
by
removing
those
additional
bytes,
M
meta
data
bytes
remove
that.
But
you
will
reconstruct
the
original
quick
packets
and
be
able
to
do
what
he
has
to
do
with
this
recovered
sauce
packet,
quick
sauce
packets.
So
it
explains
why
we
need
to
add
two
additional
metadata
stuff.
F
Then
we
change
just
a
little
bit
the
the
original
quick
packets.
With
this
approach,
we
need
to
carry
this
additional
fact,
sauce,
FBI
fact,
payload
information,
so
that's
signaling
information
that
we
need
to
put
inside
the
original,
quick
packets,
but
carries
sauce
packets,
the
source
data
or
a
journal
data
to
the
send
to
the
receiver.
We
need
to
do
that
just
to
the
receiver
decoder.
Okay,
that's
that
quick
packet
carries
this,
do
so
symbols
we
have
this
awesome
or
identifier
that
is
typically
inside
this
additional
frame.
F
If
we
are
dealing
with
block
codes,
maybe
we
will
also
have
an
indication
of
an
identification
of
the
block.
It
corresponds
to
for
the
few
things
like
that
that
we
need
to
be
that
needs
to
be
carried
inside
quick
packets,
original,
should
quick
packets
and
concerning
the
repair
frames,
we
can
transmit
them
in
additional,
quick
packets.
We
can
perhaps
put
several
with
their
frames
together
inside
the
same
quick
packet.
It's
not
a
big
deal.
F
That's
the
case
of
perhaps
acknowledgement
frames
so,
and
it
also
be
the
case
for
non
real-time
non,
the
less
sensitive
streams.
Maybe
so
we
may
want
to
do
that
I'm,
not
totally
sure
it's
important
in
any
case,
if
we
want
to
do
that,
it
means
that
we
need
to
inform
the
receiver.
We
need
to
keep
both
encoder
and
decoder
synchronized,
so
it
means
additional
signalling
and
at
the
moment
we
don't
really
know
how
to
do
this
additional
signal,
and
so
there
are
point
questions
yeah.
This
is
something
that
needs
to
be
experimenting
implementing.
F
We
need
to
have
more
background,
more
information,
more
thoughts
on
those
or
techniques.
If
we
really
want
to
do
that,
otherwise
we
protect
the
full
payload,
quick
packet,
so
it's
say
always
possible.
There's
also
this
choice
of
this
symbol,
size
parameter-
that's
I
already
mentioned
next
next
things
to
be
done.
Well,
we
need
to
add
8
the
IOC
for
quick
documents.
We
need
not
have
time
to
do
that
presently
switched
you're
compatible
with
its
general
France
in
the
previous
version
of
this
framework
document.
F
C
F
F
G
G
B
G
F
I
F
L
John
Porter,
quick
observation
that
at
least
as
we
presented
it,
N
equals
s.
So
it's
redundant,
there's
a
systematic,
a
non
systematic
code.
Would
that
help
in
this
context,
idea
was
brought
earlier
of
being
able
to
adapt
how
much
code
extra
coding
you're
putting
in
because
I'm
definitely
interested
in
that
because
of
my
latency
over
satellite.
That
has
the
error.
If
I
go
into
rain
fade,
can
I
increase
the
coding
on
the
fly
if
I
can
detect,
I
have
a
higher
loss
rate,
etc.
L
F
Depends
on
the
nature
and
the
code
with
a
sweet,
fun,
slanging
window
codes,
it's
pretty
easy
to
add
more
repair
packets,
it's
just
a
matter
of
creating
if
you
new,
linear
combination
of
what
is
at
the
moment
inside
the
training
coding
window
and
send
it.
So
it's
pretty
easy
with
also
code
star
constraints.
Okay,
but
yes,
we
have
this
Plex
ability
to
use
whatever
we
want
in
terms
of
code
inside
the
this
quick
protocol.
So
at
least
this
is
the
way
we
want
to
design
it.
So
so.
L
C
Okay,
this
looks
like
it
probably
constrains
us
to.
If
we're
doing,
hybrid
air
q2
doing
type
1
doesn't
look
like
it
would
support
a
type
2
or
am
I
missing
something
and
thanked
1
and
type
2.
What
do
you
refer
to
type
2
would
be
an
incremental
redundancy
hybrid,
a
RQ
where
additional
repair
packets
are
sent
in
response
to
an
ack
as
opposed
to
repair
packets.
Are
you
just
pick
a
priori
how
many
you're
going
to
send
and
perhaps
adapt,
at
least
by
the
number
in.
F
C
F
The
only
constraints
in
that
case
is
to
manage
this
lining
window
in
an
appropriate
way,
because
once
this
all
packets
have
been
removed
from
the
sliding
window
and
then
there's
nowhere
for
the
encoder
to
produce
repair
CMOS,
really
protecting
news
packets.
So
it's
not
more
a
matter
of
using
correctly
those
FEC
codes.
If
we
are
discussing
that
signing
window
cuts
than
anything
else,
it's
a
matter
of
choosing
it
in
the
right
way
compared
to
what
we.
What
are
your
requirements?
Yeah.
G
So
they've
written
somebody's
made
a
nice
comment
and
it's
just
sort
of
flew
by
which
is
the
way
you've
described
the
encoding
s
and
n
bits
are
redundant
because
you
can
only
put
set
the
N
bit
if
the
S
bit
is
set
and
it's
invalid
to
have
a
packet
with
the
S
bits
that
and
not
the
end
bit
set.
What
I
mean
is
there's
some
kind
of
activity
there
that
you
meant
to
describe
and
didn't
yes,
the
N.
F
G
F
F
H
F
F
J
F
They're
coding
for
quick,
current
working
progress,
reference
implementation,
so
next
slide
so
compared
to
the
promised
version.
The
draft
has
changed
quite
a
lot
and
at
the
same
time
we
had
a
no
made
version
of
an
implementation
of
a
fake
extension
or
quick
that
we
made,
but
that
was
based
on
no
version
of
of
a
quick
implementation
and
it
was
also
in
the
multipath
extension.
So
it
was
quite
complicated
to
maintain
and
complicated
to
make
evolve.
F
So
we
decided
to
propose
a
new
fermentation
from
scratch
and
whose
goal
is
to
be
simple,
easy
to
learn
and
to
play
with,
and
the
goal
is
also
to
stay
up
to
date,
with
the
draft
specification
and
also
with
the
the
base,
quick
indentation,
which
is
quick,
googly
so
next
time,
and
so,
if
you
want
to
check
the
source
codes
it's
available
on
github.
The
slide
are
also
on
the
NW
c
RG
github.
So
you
will
be
able
to
get
the
link
there.
Currently,
the
implementation
only
supports
a
block
code.
F
It's
easier
and
the
RSC
specification
is
still
evolving.
We
currently
provide
a
simple
kisara
and
we
already
use
the
recovered
frame
as
I
explained,
and
so
currently,
what
we
are
doing
is
that
we
are
not
protecting,
add
frames,
so
we
can
discuss
about
that.
You
are
stepping
out
of
the
or
the
packet
payload,
we
protect
the
packet
payload
and
the
implementation
is
closely
tied.
The
design
of
the
draft.
F
F
So
if
you
want
a
simple
example,
say
that
you
can
see,
green
onion
type
implement,
read
functions
and
you
should
be
able
to
to
make
it
work.
So,
for
example,
you
can
decide
to
implement
a
block-based
already
currently
and
you
can
also
decide
to
implement
convolution
of
skins
and
stuff,
but
it's
a
little
bit
more
complicated
and
excite.
F
So
what
do
we
do?
Next?
So,
first
to
add
a
sliding
window
fix
scheme
and
also
wire
the
code
with
the
swift
codec.
What's
it
done,
we
would
like
to
add
a
proper
test
shoot.
So
currently
the
the
quick
go
test
shoot
is
still
working,
but
we
would
like
to
add
new
unit
to
test
the
extension,
and
we
would
also
like
to
move
forward
in
a
general
way
to
have
a
more
clever,
simple
scheduling,
because
currently
it
works.
F
But
it's
not
really
efficient,
because
we
do
not
do
things
very
cleverly
and
we
can
also
try
to
run
wire
new
applications
about
the
implementation,
because
we
chose
a
quick
go
because
it's
an
implementation
that
provides
the
rich
API,
which
is
easy
to
use
and
play
with.
So
that's
something
we
already
try
to
do
next
slide,
and
so
finally,
there
is
a
list
of
other
interesting
implementations
to
look
at,
so
there
is
first,
a
quick
which
will
be
presented
in
less
than
five
minutes.
F
And
finally,
we
will
also
present
another
quick
implementation
at
signal
19,
which
is
done
with
the
paper,
which
basically
revisits
the
way
on
how
we
can
deploy
in
a
complex
extension
such
as
effect,
so
the
the
source
code
of
this
implementation
will
also
be
publicly
available.
So
you
can
stay
tuned
and
you
can
get
access
to
it
after
your
sitcom.
So
next
slide,
so
thank
you
very
much
and
feel
free
to
ask
your
questions.
F
Also
just
100
mean
name
to
me:
oh,
we
have
the
old
one.
We
have
this
new
one
and
we
have
the
the
one
for
for
sitcom.
So
three
bands,
but
the
old
one
I
think,
will
get
rid
of
it.
Okay,
you
you
always
to
continue
with
the
quick
go
implementation
to
maintain
it
as
the
main
reference
implementation.
Yes,
this
one
and
the
second
one,
the
the
destroyer
and.
F
F
F
B
Like
I
said
at
the
beginning,
there
was
a
strong
I
think
need
and
a
strong
opinion
about,
starting
to
link
a
lot
of
groups
together,
and
you
know
we're
essentially
a
service
for
in
the
network,
so
we
obviously
have
links
to
other
people
and
there's
other
groups
who
are
looking
at
ways
of
implementing
the
coding.
So
obviously
they
also
have
implement
well
issues
or
they
actually
have
related
issues.
So
they
are
gonna,
get.
B
So
we've
had
it's
sad
that
they've
just
left,
but
we've
had
a
long-running
relationship
with
ICN
RG,
which
dates
back
to
a
paper
I
wrote
about
ten
years
ago,
and
this
led
to
this
idea
of
network
coding
for
content,
centric
networking
requirements
and
challenges.
There's
the
draft
that
was
discussed
at
the
beginning
and
it
is
going
to
be
a
joint
that
we're
coding
and
I
see
NRG
RFC
when
it
comes
to
that
and
it's
it's
been
reviewed
as
they
saw
mentioned,
but
this
is
has
been
I.
B
Think
one
example
of
a
relationship
that
has
worked
really
well
between
the
two
groups
and
there
was
a
bit
of
a
win-win
because
it
showed
that
you
could
implement
and
that
were
coding
inside
a
information
centric
network.
So
that
was
very
nice
coin.
This
is
really
new
coin.
We
had
a
coin
with
my
other
co-chair
group
and
we
had
a
hackathon
on
Saturday
where
we
started
looking
at
things
that
could
be
done
with
p4,
which
is
this
language
allows
you
to
program
low
level,
switching
and
there's.
B
Actually
a
group
with
Salvatori
Signorelli
and
his
team
and
Lisbon
are
actually
low.
Looking
at
an
implementation
of
network
coding
in
p4,
which
was
one
of
the
projects
that
I
had
on
my
list,
actually
it's
fun
that
they're
doing
it,
and
this
also
is
interesting
for
another
reason
that
it
will
prove
that
the
ideas
of
doing
re-encoding
in
switches
inside
the
network
can
be
done
really
fast.
So
that
could
be
interesting
results.
B
They
were
not
ready
for
this
IETF,
they
are
going
to
upload
their
paper
and
they
want
to
write
a
draft
on
it
and
it's
going
to
be
a
joint
coin
network
coding
draft,
so
it
will
be
submitted
in
both
groups
and
we
hope
that
it's
going
to
be
presented
in
Singapore
in
both
groups.
So
that's
going
to
be
fun
and
really
show
the
present
the
relationship.
B
So
this
is
actually
something
that
I've
been
involved
since
Monday
and
a
few
of
us
have
been
involved
since
Monday,
there
was
a
non
forming
buff
on
Monday
about
something
called
loops,
which
is
some
kind
of
hop
by
hop
performance,
optimization
and
with
FEC
on
selected
paths.
There
was
a
mention
of
Swift
in
the
presentation.
There
was
no
mention
of
the
other
potential
codecs,
but
obviously
soif
is
really
the
work
of
Swift
is
related.
There
was,
you
know,
we
know
from
the
work
that
we've
done
here,
that
congestion
control
will
be
an
issue.
B
You
saw
from
the
quick
presentation
that
we
now
signal
that
the
packet
has
been
recovered
so
that
we
don't
start
messing
up
with
the
congestion
control.
They
have
there's
been
a
lot
of
work
in
this
group
on
this
and
it's
going
to
be
important,
I
think
for
it
for
the
loops,
if
it
ever
becomes
and
yes,
you
have
Kirsten,
you
have
a
question.
H
H
So
basically,
the
the
point
is
that
within
a
path
that
generally
is
okay,
there
may
be
a
challenged
subset
and
you
may
want
to
install
something
at
the
ingress
and
egress
of
that
challenge,
subset
through
to
fix
things
and
mainly
right
now.
We're
looking
at
retransmission
and
FEC
is
just
another
option
that
has
been
implemented
by
the
people
who
are
building
property
prototypes
of
this,
and
the
main
point
is
this:
is
don't
look,
don't
touch
things,
so
we
don't
care
what
we
transpose
long
as
it
is
a
package.
B
I
B
H
Yeah,
don't
look,
don't
touch
also
includes
that
we
don't
talk
to
the
host,
so
whatever
the
host
does.
Is
it's
completely
opaque?
Of
course
the
ingress
or
the
egress
might
actually
be
the
host
in
the
end
yeah.
So
that's
an
interesting
special
case,
but
the
things
supposed
to
be
really
simple
and
get
by
without
talking
to
the
host
yeah.
B
And
actually,
if
you
saw
the
presentations
from
Nicholas,
though
some
of
his
architectures
looked
a
lot
like
some
of
the
slides
I
saw
on
Monday,
so
I
think
there's.
So
the
message
here
is
that
you
know
there
is
collaboration,
we're
all
in
them
saying
mailing
lists
and
you
know
again.
Historically,
we
ended
up
being
a
research
group,
because
the
IETF
was
not
ready
five
six
years
ago
for
a
working
group
that
dealt
with
the
type
of
architectures
that
would
discuss
in
here.
B
That
could
be
a
way
for
some
of
the
work
that
was
done
here
to
move
into
the
IETF,
because
there's
people
in
this
room
who
know
that
the
type
of
architecture
you're
discussing
with
loops,
including
FEC,
is
actually
running
code
and
a
lot
of
different
implementations
may
be
more
proprietary,
maybe
a
little
bit
more
less
known,
there's
probably
ways
that
some
of
these
things
may
end
up
being.
You
know
in
the
public
domain.
B
H
H
B
M
M
Of
the
day,
good
morning
to
the
personal
attendees,
my
name
is
Mihai
I'm,
a
PhD
student
from
University
of
Montana
and
Caroline
Research
Center.
We
don't
have
any
patents,
nothing
dangerous
here
so
and
all
the
participants
that
are
mentioned
here,
this
slider
are
okay.
Me
is
presenting
publicly
the
contents
of
this
presentation
I'm
going
to
present
a
robust
week
or
our
week,
which
is
another
implementation
of
fact.
Week
are
a
lot
to
the
work
that
was
presented
in
construction
next
I
kiss.
M
M
B
I
have
a
question
says
Marshall
say
without
the
chair
Harry.
The
chair
at
your
last
statement,
says
which
quick
fec
is
better
and
in
which
cases,
and
is
it
worth
merging,
I
think
I
have
an
answer
to
this
I
think
we
don't
know
which
quick
fec
is
best,
because
we're
still
testing
these
things
and
the
worth
merging
my
experience
in
network
coding
would
say
that
merging
them
is
probably
not
a
good
idea.
B
I
think
a
decision
that
we
made
when
we
started
working
with
Google
on
on
the
quicken
FEC
was
that
we
were
going
to
give
operators
a
choice
of
the
code
that
we're
going
to
use
in
our
case
it's
inside,
and
in
your
case
it
could
be
that
they
also
decide
to
use
your
approach,
but
I
don't
think
both
together
would
work,
because
then
you
would
have
a
lot
of
issues
with
repair
packets,
which
ones
are
repairs.
We
are
above
the
encryption
you're
below
I.
B
K
M
I
was
referring
more
to
today,
good
practice.
For
these
cases,
that's
all
I
was
thinking
yes,
okay,
next
one,
okay,
according
to
code
with
badness
encoded
version,
we
didn't
know
so
much
document
exam.
We
mean
codes
after
Egyptian
for
two
reasons.
The
first
one
is
because
it
seems
more
simpler
limitation,
and
the
second
reason
is
because
this
way
we
can
evolve
towards
quick
with
network
coding
in
a
more
easier
and
easier
way.
This.
B
B
M
M
Okay,
the
packet
our
budget,
so
we
will
not
expecting
anything
interview
here,
I'm
trying
to
depict
this
off
well
I
would
week
we
never
couldn't
look
like
before
and
after
routing
before
and
after
decoding,
so
in
sent
over
in
emergent
a
minute
if
you
encode
before
encryption
is
impossible
or
very,
very
hard
to
record
it
in
mediate.
Notes.
M
Some
technical
details
here
we
took,
we
are
basing
our
code
on.
We
go
budget
by
estimate,
not
assuming
we
took
the
coffee
after
the
release,
division,
Oh
simple:
we
want
to
be
that
we
have
implemented
only
one
coding
scheme
with
every
second
call
it
packet
how
because
it
depends
on
where
loss
is
observe.
So
far
we
have
a
four
byte
header,
four
by
four
big
packet
right.
Well,
this
will
show
you
change
in
the
next
future.
M
M
M
Okay,
yeah:
it's
our
code,
what
we
simulations
and
physical
setup,
which
other
art
week
isn't
in
pairing
them
up
each
session,
so
we
have
considered
for
simulations
three
cases:
wireless
network,
no,
no
more
typical
war,
fine,
solar
network
and
satellite
communications.
In
physical
setup
we
had
solar
Network
parents
Wi-Fi,
we
had
two
kinds
of
traffic,
both
transfer
and
we're
browsing
as
the
output
attic
see,
the
main
output
is
the
completion
ratio.
That
is
the
time
in
which
our
quick
sense,
the
necessary
information
divided
by
the
time
that
normally
could
do
that.
M
As
you
can
see
in
both
transfer,
we
had
of
significant
improvements
in
the
in
all
cases,
however,
in
web
browsing,
the
improvement
is
not
that
that
big.
We
believe
that
it's
because
our
adaptive
preto
algorithm
is
not
optimized
for
the
slow
start
phase
in
the
congestion
control
window.
We
are
working
on
it
and
the
summary,
which
is
the
next
slide.
M
I
J
P
P
P
P
M
I
Brandon
Williams,
the
the
specific
difference
between
this
mechanism
and
the
the
other
one
that
sits
above
the
encryption
layer
that
I'm
curious.
Whether
you
have
thoughts
about
is
the
it
seems
to
me
that
the
parameters
you
want
or
the
desirable
characteristics
that
you
want
from
the
network
differ
distinctly
between
a
bowl
between
a
bulk
data
transfer.
That
wants
to
be
reliable
and
say
video-streaming
that
doesn't
put
as
high
a
priority
and
reliability.
M
M
I
The
do
you
mean
that
I
didn't
get
the
sense
from
the
talk
and
maybe
I
need
to
read
the
document
to
get
a
better,
better
idea.
I
didn't
get
the
sense
that
you
were
selectively
applying
the
the
FEC
or
that
you
have
the
capability
to
have
any
kind
of
differences
applied
between
between
different
streams.
Are
you
selectively
applying
the.
M
I
I
And
then
that
that
seems
like
something
that's
going
to
be
something
that's
going
to
be
important
for
you
to,
for
you
to
look
into.
That,
certainly
is
one
of
one
of
the
things
that
has
come
up
in
discussions
about
applying
fact
for
quick
that
some
streams
will
benefit
in
some
streams,
won't
benefit
much
and-
and
you
know,
there's
a
desire
to
be
selective
about
it,
as
well
as
selective
about
the
parameters
that
are
applied
based
on
the
nature
of
the
individual
stream.
Okay,.
B
B
So
you
need
to
really
I
think
look
at
your
implementation
in
terms
of
how
it
works,
especially
in
the
congested
network
where
the
losses
will
not
be
due
to
physical
layer.
Read
you
know,
residual
errors,
but
obviously
because
it
was
needed
to
drop
the
packets
to
maintain
Network
integrity
and
I.
Think
what
you
proposed
here
I
think
it
works
when
there's
no
congestion
and
it's
great,
but
if
you
get
into
a
more
like
the
I,
would
say
the
architecture
that
Carsten
was
mentioning
when
you
have
more
than
one
path
segments
who
have
very
different
characteristics.
B
But
once
you
get
on
the
wired
part
of
the
network,
it
may
be
a
very
different,
very
something
very
different
happening
and
I'm
speaking
from
experience
here,
and
you
may
not
want
to
be
very
as
aggressive
as
correcting
everything
and
since
you
do
not
know
what
these
packets
are,
I
think
you
need
to
really
look
at
how
you're
going
to
make
sure
that
you're
not
creating
actually
making
things
worse
for
the
network
and
even
you
know,
sending
things
into
congestion
collapse.
Okay,
thank
you.
M
B
Okay,
so
I
guess
we're
we
finished
early,
which
is
always
good.
So
thank
you
for
coming
and
I
guess:
everybody's
going
home
in
the
next
few
hours
few
days
and
have
a
safe
trip
back
and
next
time
for
people
who
came
from
far
we're
going
to
be
the
ones
the
people
on
the
east
coast
of
the
US
are
going
to
be
the
one
doing
the
long
trek
so
we'll
see
you
in
Singapore,
hopefully
not
too
jetlag.
Thank
you.