►
From YouTube: IETF106-NWCRG-20191121-1330
Description
NWCRG meeting session at IETF106
2019/11/21 1330
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
B
F
F
H
E
This
is
a
I
think
the
continuation
of
a
number
of
of
the
work
that
we've
been
doing
for
a
while,
but
I
think
there's
always
new
things.
I
think
I
was
also
welcome,
Raymond,
who
is
usually
online
and
is
finally
here
with
us.
So
welcome
to
the
group
and
yes,
we
have
a
number
of
interesting
presentations.
We're
also
very
happy
to
have
today
the
people
from
loops
who
are
looking
at
similar
things,
but
more
from
the
IETF
point
of
view.
So
again
we're
not
the
IETF
with
the
IRT.
E
So
our
goal
is
to
foster
research
and
mostly
and
network
and
application
layer
coding
to
improve
network
performance
and
I
have
a
presentation
a
bit
later.
It's
not
just
the
networks
that
we
know
like
now,
but
also
the
future
of
the
networks
where
you
start
having
computing
elements
everywhere.
So
we
want
to
look
at
coding
and
coding,
libraries
protocols
and
a
lot
of
real-world
use
case
and
I
think
this
is
where
there's
a
lot
of
cool
stuff
happening
also
in
the
work
in
progress.
E
E
More
and
more
foster
an
environment
where
people
feel
safe
to
express
opinions,
and
this
one
say
states
explicitly
the
goal
of
the
IRT
F,
which
is
not
to
do
standardization,
but
it's
very
much
to
foster
research
and
foster
communities
of
research
along
the
topics
that
we're
talking
about
this
case
coding
and
applications
and
I.
Think
that
makes
it
very
important
to
see
also
how
I,
RTF
and
IETF
can
work
together
so
that
the
research
is
done
here
and
then
eventually
we
can.
Actually,
you
know,
send
it
to
the
IETF
when
there's
something
that
needs
standardization.
H
So
this
is
about
an
instructive
stuff.
There's
no
big
change,
just
to
remind
you
that
you
can
have
a
look
at
the
github
repository
where
we
store
all
the
presentations.
All
the
minutes,
everything
that
concerned
this
working
group
with
the
troops.
Sorry,
as
well
as
the
swift,
correct
implementation,
so
everything
is
there,
so
do
not
hesitate.
There
is
also,
of
course,
the
death
tracker.
H
H
Okay,
so
we'll
go
for
it.
First
of
all,
a
few
news
about
current
internet
drafts
and
so
on,
written
internet
resto.
Concerning
the
group
documents
except
the
presentation
we'll
have
later
on,
we
have
two
topics:
two
sets
of
internet
drafts
that
will
not
be
presented
there,
the
first
one
that
is
about
network
coding
for
CDN,
so
sorry
see
CN
and
DN
environments
with
requirements
and
challenges
so
Dave
you
may
document
some
time
ago.
It
was
in
ITF
104.
H
I
I
H
H
Unfortunately,
nobody
from
the
author's
was
able
to
come
to
this
or
I
turned
remotely
this
meeting,
but
the
situation
is
the
following:
in
who's
told
us
that
record
there
was
an
update
on
the
RNC
single
citation
documents,
small
tech
fixing
a
few
things,
not
nothing
very
essential.
There
is
also
another
document
that
expired.
Unfortunately,
at
the
moment,
they
don't
have
any
clear
view
on
what
to
do
next.
H
So
the
situation
is
about
is
a
little
bit
ambiguous.
He
asked
earth
chairs.
He
asked
us
to
ask
to
the
group
to
everybody
to
to
have
a
look
and
to
provide
feedbacks,
and
we
will
also
have
to
decide
together
what
we
want
to
do
with
two.
With
these
two
documents
accept
them
as
working
a
recent
groupie
team
or
or
not.
So
that's
an
open
question
to
everybody.
H
E
Would
actually
really
support
what
they
saw
has
said
and
I
think
it's,
because
it
goes
to
the
notes.
So
please
put
it.
There
I
think
it's
extremely
important
that
we
have
a
document
on
on
our
LNC
and
I
would
put
also
the
people
of
titlis
on
the
underline
here.
I
think
one
of
the,
since
one
of
them
is
here
I'm
looking
at
him
now
and
I.
E
Think
one
of
the
goals
of
this
group
at
the
beginning
was
to
have
a
set
of
documentation
on
existing
FEC
solutions
or
network
coding
solutions,
and
because
again
we
have
in
the
room
the
people
from
loops
who
are
actually
looking
for
for
directions
when
they
start
doing
some
FEC
beyond
the
stuff
that
is
already
existing
on
open
source
and
everything.
So
I
think
it
would
be
extremely
important
to
continue
in
this
in
this
way
of
having
a
set
of
documents.
I
think
we're
having
very
soon
they
are
the
RFC's
from
and
so
on.
E
J
E
J
E
H
Yes,
thank
you.
If
you
want
about
the
three
related
internet
drafts
so
about
fake
friend
or
C&T
mg42,
so
do
three
documents
are
almost
done
in
the
sense
that
the
I'll,
C
and
T
90
52
PNG,
have
been
not
yet
really
published,
but
almost
published
as
I
see.
We
already
have
the
the
numbers
86-81
and
62
for
those
two
documents,
and
now
we
are
just
waiting
for
final
approval
by
Magnus,
our
ad
actor
and
the
effect
for
an
extension
to
sliding
window
cards
just
a
matter
of
rewarding
issues
here
and
there
on
the
documents.
H
H
Right,
:,
okay,
so
this
is
just
a
quick
feedback
from
the
Hakkasan
on
Saturday
and
Sunday.
So
I,
remember
when
you
do
the
goal
of
this
like
a
song.
This
is
to
develop
an
open
source
reference,
correct,
free,
correct
for
sliding
window
cuts
and
also
to
challenge
document
on
the
API
for
such
a
colleague.
H
So
we
were
three
people
at
that
time
for
this
hackathon
myself,
Omaima
and
Siri,
and
very
happy
that,
in
between
this
hackathon
previous
one,
second
Omaima
managed
to
work
a
lot
on
this
project
and
we
are
approaching
not
the
end,
but
we
are
approaching
a
situation
where
things
will
start
working
very
well.
So
what
has
been
done
so
the
end?
Color?
H
We
also
this
see
demonstration
application,
that's
almost
done
and
the
Python
work
of
rapper
and
demos
on
top
of
this
rapper
that
are
almost
on.
So
we
are
approaching
the
end,
even
if
the
still
work
to
be
done.
We
also
managed
to.
We
also
found
an
issue
in
the
API
stupid
thing
and
four
points
that
remain
open
in
this
document
and
in
particular,
Rd
I
would
like
to
say
a
few
words
about
the
ESI,
the
encoding
symbol
idea.
H
It's
not
something
a
very
trivial,
because
currently
the
way
it's
implemented
is
just
type
def,
it's
type
def
to
an
unsigned,
int
32
bits,
and
that's
all.
But
if
you
look
at
some
of
the
documents
were
working
on.
In
particular,
this
I'll
see
for
quick
document.
You
will
see
that
this,
including
symbol
ID,
is
represented
as
a
variable
int
integer
in
the
sense
of
quick
meaning
that
can
be
a
small
or
larger
integer.
H
So
that's
something
non-trivial
to
do
in
order
to
map
this
fireball
size
into
the
API
in
a
way
that
can
be
used
in
different
contexts.
So
that's
something
we'll
have
to
fix
in
the
next
cycle.
Hopefully
so
next
step
now
is
for
next
time.
I
said
Montrell,
but
that's
mistake.
It's
Vancouver
so
in
our
ITF
107
at
Vancouver,
we'll
have
our
fifth
Agathon
and
do
some
kind
of
improvement
of
the
code
cleaning
and
things
like
that.
H
Documentation
also
something
that
could
be
very
useful,
explaining
much
better
how
to
do
and
cutting
the
coding
how
to
write
an
application
on
top
of
deuce
decoder
and
colors
and
decoders
so
and
once
this
will
be
done,
then
we
will
be
able
to
move
to
the
next
step,
which
is
which
will
consist
in
having
this
soil
and
see
like
codec
being
implemented.
It's
just
a
matter
of
changing
a
few
things
inside
the
incorrect
buts.
It
seems
simple,
say
it
like
that.
H
E
Questions
comments
for
those
of
you
who
have
not
participated
in
the
hackathons,
yet
I'm
actually
also
running
another
one.
In
parallel
this
we
didn't
manage
to
get
the
same
table
but
I
think
it's
becoming
more
and
more
a
really
nice
way
of
learning
with
the
other
groups
in
both
the
IETF
and
the
IRT
F
for
doing
because
for
two
days
were
actually
co-located
as
when
we
here
we're
so
much
distributed
in
different
places.
So
I
would
really,
if
you
can
arrive
early
on
the
Saturday
I,
would
really
recommend
that
you
show
up.
H
And
there's
also
this
presentation
on
Sunday
afternoon,
where
you
will
get
a
feeling
of
what's
going
on
during
the
accident,
so
everybody
will
present
you
in
a
few
minutes
what
they
managed
to
do
the
NGO
project,
and
so
it's
very
interesting
to
have
a
global
view,
overview
of
what's
going
on
in
ITF
and
IIF
I
RT
F
as
well.
Thank.
G
B
Okay,
so
let's
go
okay,
so
hello,
everyone
and
furry,
because
that's
a
very
worst
part
of
the
day
for
me,
I've
been
sleeping
every
early
afternoon
this
week,
so
I
hope
you're,
not
sleeping
and
I
hope
I'm
not
and
he's
an
update
for
the
network
coding
for
satellite
systems
document.
So
these
that
melibea
will
go
through
what
happened
and
for
those
who
are
not
familiar
with.
What
is
the
scope
of
document?
B
B
We
have
a
second
one
in
the
15th
of
October
and
we
received
the
lloyd
would
comment
on
the
fixed
on
26.
So
I
have
here
some
slides
on
explaining
how
we
dealt
with
every
single
comments.
They
are
also
available
on
the
github
repository
of
the
research
group,
where
we
made
an
issue
for
every
comment
we
received,
so
I
can
go
through
them.
I
don't
know
have
time,
but
ok,
ok
code
is
not
here.
Anyway,
from
but
I
will
go
sweeten,
you
ok
in
case
ok
medically.
B
That
was
that
was
a
comment
on
the
fact
that
it's
not
really
clear
whether
we
are
speaking
about
link
layer
and
physical
layer
or
not.
We
tried
to
clarify
that
lots
of
times.
Apparently
it
was
not
enough,
so
we
skipped
lots
of
things
from
the
introduction
to
be
narrow
directly
down
to
what
the
actual
problem
and
the
document
is
tackling.
B
So
that
is
one
of
the
many
changes
we've
done,
another
one
that
you've
more
satellite
speaking
to
a
satellite
guy
on.
Do
we
need
to
specify
what
those
effect
fame
is,
as
opposed
to
a
be
befriend,
and
in
the
document
we
say:
that's.
It
is
a
satellite
discussion,
so
we
points
to
the
DVB
standard
documents
and
we
you
just
not
need
here
to
know
what
and
below
the
access
layer.
So.
H
B
That's
a
comment
related
to
also
the
problem
on
I
see
em
I
see
em.
If
the
mechanism
we
have
a
drink
layer
in
satellite
systems
to
actually
have
horrible
transmissions
that
enable
us
seeing
clouds
coming
and
that
recording
rate
and
and
what
we
say
in
the
document
is
that
this
mechanism
do
not
go
as
quickly
I
have
they
should
for
mobile,
yet
mobile
users
or
when
we
go
through
higher
bandwidth
bands
such
as
UV
bands.
B
So
we
basically
here
tried
to
make
that
way
clearer
in
the
document
that
all
these
link
layer,
stuff
are
out
of
the
scope
and
I
hope
it's
better.
But
then
we
thought
we
were
over,
but
then
we
received
also
comments
from
vents
on
so
basically
the
weather
another
error
on
the
fake
in
the
glossary.
There
was
wording
issues
introduction
in
the
end.
B
If
you
want
what
so,
this
has
been
done
this
week
earlier
this
week,
because
we
just
sat
down
with
one
song
and
took
one
of
all
the
issues
you
had
one
by
one
and
work
directly
on
the
github
of
the
the
document.
So,
basically,
when
something
was
compute
in
general,
when
something
was
computing
we
removed
it
try
to
have
very
short,
a
document
to
go
straight
to
the
point
of
what
is
in
the
scope
of
the
document.
What
is
not,
we
tried
to
have
a
better
wedding.
B
We
are
not
native
speakers,
so
if
anyone
wants
to
hold
you
our
English
you're
welcome,
we
removed
the
figure
that
one
that
was
confusing.
Also
that's
another
problem.
We
have
when
you
mix
words,
that
a
payload
for
satellite
is
actually
the
thing
that
is
flying
and
of
the
payload
of
the
packet.
So
that's
can
lead
to
some
confusion.
It's
the
same
issues
such
as
we
had
with
a
fig
frame,
so
we
just
remove
that.
We
just
pick
about
satellites
and
not.
H
Yes,
so
just
to
make
it
clear,
this
document
is
hopefully
close
to
the
end.
It
was
a
recent
copy
terms
for
sometime.
We
went
through
already
two
last
calls
and
now
the
last,
perhaps
some
programs,
but
there
arm
on
the
editorial
side
and
improvement
things
like
that.
Hopefully
it
will
be
fixed
rapidly.
So
the
idea
is
to
ask
for
volunteers
to
review
this
document
if
feasible.
Imagine
myself
will
read
it
again
as
it
is
now
and
trying
to
fix
the
last
few
mittens,
but
hopefully
it
will
soon
move
to
the
next
step.
K
H
So
we
now
have
a
presentation
from
Raymond.
It
is
a
great
that
you
managed
to
come
this
time.
Well,
very
pleased
of
that,
as
we
said
before,
just
to
remind
you
that
was
working.
Progress
on
this
topic
on
bat
skirts
and
remand
made
several
presentations
of
those
skirts
and
also
the
use
case
where
these
those
cuts
are
going
to
be
deployed
and
so
on.
So
this
is
an
update
of
the
situation.
There
is
also
an
intern
draft
that
is
associated
to
this
twist
work
and
also
like
to
discuss
about
it
again.
L
L
The
thing
is
that
there
are
a
lot
of
equipments
on
the
small
impose
and
they
must
be
connected
to
the
Internet
backbone
and
possible
technologies
are
optical,
fiber,
cellular
and
one
infinite
choice,
pads,
which
is
say
kind
of
like
an
efficient
implementation,
random
linear,
neural
coding,
okay,
so
for
optical
fiber,
you
know,
we
know
that
that
has
got
very
high
data
rate,
highly
reliable
and
unless
you
accidentally
lit
the
cup
the
fiber.
However,
it
has
high
installation
cause
it's
a
very
long
set
of
time.
For
example,
I
was
told
that
you
know
in
many
cities.
L
If
you
want
to
get
all
the
licenses
for
developer
row,
it
may
take
two
to
three
years,
which
is
a
to
long
time
to
wait
for
many
applications,
and
so
realistically,
only
a
very
small
number
of
lampposts
in
the
inner
system
can
be
directly
connected
to
optical
fiber.
Now,
the
rest,
you
still
need
to
find
some
way
to
connect
them
to
the
Internet.
So
how
about
we
use
a
4G
or
all
upcoming,
5g?
Okay,
so
it's
very
simple:
you
just
install
a
4G
card
at
each
lamppost,
converting
each
one
into
have
like
a
cell
phone.
L
The
pros
are
easy
to
deploy
and
relatively
inexpensive,
but
the
cons
are.
It
has
a
very
high
in
recurring
cost.
Also
you
upload
data
24
hours
a
day
and
7
days
a
week
and
you
need
to
pay
the
monthly
service
fee.
I
mean
you're
talking
about
a
city
with
10,000
M
post
and
you
have
a
pretty
huge,
a
monthly
fee
to
pay,
and
the
government
usually
do
not
pay
for
this
kind
of
solution
and
for
40.
Another
problem
is
that
bandwidth
drastically
drops
during
rush
hours,
hopefully
will
not
be
the
case
for
5g.
L
Now
the
so,
what
we
are
introducing
is
a
multi
hop
solution
called
bats.
So
now,
in
this
particular
illustration,
we
have,
on
the
left
hand,
side
lamppost,
which
has
direct
connection
to
an
optical
fiber,
and
what
we
do
is
that
we
connect
the
rest
of
the
lamppost
on
the
same
street
using
a
wireless
multi
hub
network
okay.
So
why
do
we
want
to
talk
about
bats?
L
The
problem
here
is
that
multi-hop
is
a
long-standing
problem
in
wireless
communications,
for
the
reason
that
for
each
hub
you
lose
packets
and
if
you
regard
you
know,
packets
as
being
a
commodity,
then
there's
no
way
that
you
can
prevent
hackers
from
losing
a
long
way
and
the
and
the
throughput
drops
exponentially
fast
with
the
number
of
house.
Now
the
I
talked
to
some
people
in
industry,
and
sometimes
they
call
this.
L
The
multi-hop
curse
and
bats,
as
I
mentioned,
is
an
efficient
implementation
of
randomly
in
enamel
coating
and
with
this
technology
you
know,
transmission
can
sustain
tens
or
even
hundreds
of
hops,
without
relying
on
link
by
language
transmission,
which
actually
is
very
bad
for
video
transmission
itself.
You
may
know:
okay
now,
the
the
idea
is
to.
Instead
we
employ
recoding
at
the
intermediate
nodes
and
with
paths.
A
very
long
multi-hop
network
can
be
realized.
L
L
So
in
this
case
we
assume
that's
the
the
packet
loss
on
each
lane
without
retransmission
is
equal
to
20%,
so
that
after
one
hop,
you
know
you
got
only
0.8
okay
and
if
you
use
store-and-forward
along
the
way,
then
you
every
hobby,
multiplied
by
0.8
and
you
throughput
drops
exponentially
fast,
whereas
with
with
them
ran
Venini
Annelle
coding.
Ideally,
you
know
the
throughput
won't
change
with
the
number
of
hops
and
which
is
in
these
in
Tonica
results.
L
Now
with
a
bad
service,
is
kind
of
like
a
good
approximation
of
this
orthotic
implementation
of
randomly
ninel
coding,
except
that
it
is
highly
efficient
and
keeping
implemented
on
most
platforms.
We
see
that
there's
a
drop
in
performance,
but
the
drop
is
it's
very
slow?
Okay,
so
so
after
50
halves,
you
still
get
about
0.7
and
and
the
drop
actually
becomes
slow
and
slower,
and
in
this
part
we
see
that
after
1,000
hops,
you
still
get
about
point
six,
six
of
the
original
through
poetry,
okay.
L
So
these
are
some
technical
features
of
bat
since
Scott
high
throughput
load
agency,
as
we
know
for
running
and
never
coding,
it
is
basically
pipelining
operation
so
that
you
don't
wait
for
for
for
any
lost
packets
or
the
cutting,
and
it's
got
a
little
coding
complexity
and
low
source
requirements.
These
the
last
two
features
are
regarding
the
efficiency
of
implementation,
and
now
I
would
like
to
talk
about
the
real
deployment
of
bats
in
the
Hong
Kong
small
n
post
project.
The
the
plan
was
to
install
400
spar
lamppost
starting
some
last
summer.
E
L
So
this
particular
boxes
is
the
install
recall
the
best
boxes
and
industrial
PC
and
the
the
best
box
was
actually
co-developed
with
event
tech,
as
some
of
you
may
know,
it
event
is
one
of
the
leading
IPC
vendors
from
Taiwan,
and
the
current
status
is
that
we
have
already
successfully
deployed
at
two
streets.
Unfortunately,
as
some
of
you
may
know,
there's
a
picture
more
in
hong
kong
and
on
the
on
august
24th.
There
was
a
protest
in
which
the
the
spar
lamppost
at
one
of
the
streets
were
heavily
vandalized.
L
So
this
one
thing
I
would
like
to
mention
which
I
didn't
realize
before.
Instead,
the
best
actually
has
got
a
very
close
connection
with
for
computing.
This
fence
is
inherently
a
for
computing
application,
for
the
reason
that
the
competition
must
be
done
at
edge.
Okay
for
most
other
applications.
You
know
you
can
do
it
at
a
cloud
except
that
the
performance
may
be
degraded,
but
for
best
it
must
be
done
at
edge,
so
best
is
actually
inherently
for
edge
computing
application.
L
So
we
planned
to
install
our
24
note
base
model
impose
on
the
on
our
own
University
campus,
with
vets
being
provided
as
service
by
by
the
node,
and
this
is
meant
to
be
a
prototype
for
the
next
generation,
smart
and
post
and
there's
some
further
opportunities
that
ripping
exploring.
We
talked
to
some
some
departments
in
the
government.
L
They
are
very
interested
in
installing
spot
lampposts
in
country
parks
and
which
not
largely
not
covered
by
our
seller
networks,
and
this
poses
some
threats
to
to
the
hikers
okay,
so,
and
also
that
we
learned
that
many
cities
in
Southeast
Asia
are
interesting
in
having
some
kind
of
party
small
and
post
projects,
so
as
mentioned
by
Vincent,
we
have
submitted
a
and
internet
draft,
and-
and
this
is
the
the
list
of
patents
that
we
have
obtained
so
far.
Ok,
thank
you
for
your
attention.
M
J
L
M
L
Okay,
we
don't
have
dozens
of
thousands
of
those.
At
this
point
we
have
let's,
for
example,
in
Hindi
and
the
small
lamppost
application.
For
example,
you
know
that
devices
on
each
lamppost
and
there
each
one
of
them,
is
connected
back
to
to
the
lamppost
on
the
left-hand
side
in
our
in
the
picture.
Yeah,
ok,.
J
E
L
J
H
Thank
you.
I
would
like
to
just
look
a
bit
about
the
internal
drafts,
so
in
the
same
way
we
asked
for
having
something
from
the
audience
he
and
Tetris
people.
We
have
now
something
for
bats.
That's
also
something
that
is
what
this
is
solution
that
is
currently
employed.
So
that's
great,
and
so
the
question
is:
what's
the
future
for
this
document.
What
do
you
as
a
contributor
would
like
to
do
achieve
with
this
document?
So
we
hope
that
at
some
point
it
could
be
considered
as
as
part
of
a
part
of
a
standard
yeah.
H
So
so,
as
we
said
before,
as
we
said
in
introduction,
we
our
research
group,
so
there
is
no
standard
see,
but
we
can
publish
informational
RFC,
that's
feasible,
that's
okay,
but
it
will
not
be
considered
on
as
an
idea
first
on,
that's
not
possible,
but
still
we
can
restore
that.
That
was
work
being
done.
That's
something!
That's
seems
to
be
sound
from
the
ITF
on
view,
and
we
have
this
document
this
IC
with
none.
That's
Dave.
I
H
I
I
N
D
L
E
E
E
I
K
N
Colin
Perkins,
so
I
think
they've
probably
makes
a
good
point.
So,
though,
I
haven't
read
the
draft
so
who
would
have
to
defer
to
that
other
than
that
provided
the
appropriate
ideas?
A
PR
disclosures
have
been
missed.
N
E
H
Yes,
so
this
is
a
follow
up
on
our
effects
scheme
for
quick.
So
just
to
remind
you,
we
are
considering
in
this
group
because
it's
more
appropriate
for
the
moments
some
work
on
quick
and
adding
possible
FEC
schemes
in
quick.
It's
absolutely
impossible
to
push
this
work
at
ITF,
quick
walking
group
for
the
moment,
but
still
it
makes
sense
to
have
this
discussion
and
to
do
that
kind
of
work
and
also
evaluate
all
of
this
inside
this
research
group.
So
this
is
why
we
proposed
this.
So
we
have
two
documents.
H
One
of
them
is
coding
for
quick.
This
is
the
general
framework.
How
can
we
add
coding
inside
quick,
and
there
is
also
another
good
document
which
is
this
one-
how
to
do
that
for
RC
cuts
themselves?
So
we
in
this
document
that
we
just
updated
recently,
we
explain
how
we
can
do
that
in
quick
using
our
sequence,
so
the
specific
details
this
document
is
now
in
line
with
the
also
document
was
not
the
case
until
recently.
H
So
that's
the
motivation
for
doing
these
updates,
so
it
is
in
line
with
the
coding
for
quick
version
I
presented
at
previous
site.
Ef,
just
to
remind
you
very
briefly,
we
want
to
do
cross
packet
frames
protection,
so
it
means
that
we
consider
packet
and
we
protect
the
wolf
stuff
in
the
packet
for
at
least
a
few
exceptions,
because
someone
friends
are
maybe
less
important,
but
that's
a
little.
Let's
say
that
we
want
to
protect
the
packets
as
a
war
on
the
frames
of
the
packet,
as
opposed
to
protecting
one
stream
inside
quick
session.
H
The
great
benefit
of
doing
that
is
that
we
are
a
frame
agnostic,
so
we
can
protect,
whatever
type
of
frame
is
defined
in
quick.
So
that's
the
main
advantage
in
this
artifact
scheme.
We
leverage,
of
course,
on
these
those
two
ifcs
I
already
mentioned:
I've,
see
86
81
and
86
82,
so
that's
great
because
it
makes
the
document
quite
small
and
easy
to
read.
We
only
focus
in
this
document
on
the
mapping
and
signaling
aspects
and
whatever
concerns
the
code
itself
is
already
defined
as
well.
So
that's
now
very
easy
to
do.
H
That's
just
one
example
of
X
Kim
we
may
add,
and
if
that
is
coding
inside
which
we
probably
will
add
ourselves
or
somebody
else,
it's
not
matter.
We
will
add
additional
internet
draft
specifying
additional
effects
schemes
for
quick
when
it
makes
sense
they
don't
work
in
the
same
way.
They
don't
have
exactly
the
same
use
cases
and
it
would
make
sense,
for
instance,
to
consider
our
C
schemes
when
you
have
real
time
constraints
and
small
windows
and
cunning
windows.
H
Let's
say
because
it's
a
situation
where
those
codes
are
working
very
well
and
perhaps
when
you
have
a
very
high
bandwidth
delay
product
flow
with
a
lot
a
lot
of
packets
take
together.
Maybe
block
codes
are
good
approach
for
protecting
them
because
there's
less
processing
overhead,
perhaps
so
there
is
no
clear
boundaries.
This
is
something
we
had.
We
need
to
experiment.
It
really
depends
on
the
exact
conditions,
working
conditions
for
each
case,
but
just
want
to
say
that
there
won't
be
a
single
solution,
most
probably
so.
H
I
don't
want
to
go
too
much
into
details,
because
I
really
introduced
had
previous
ITF
the
some
of
those
details.
So
this
slide
is
just
to
remind
you
that
there
is
necessarily
a
mapping,
and
that's
perhaps
one
of
the
key
aspects
inside
this
document
is
mapping
between
F
is
between
quick
packets
and
source
symbols.
H
So
source
symbols
is
the
stuff
the
piece
of
data
that
will
be
managed
data
chance
that
will
be
managed
inside
the
officiant
coder
inside
the
FCC
decoder,
so
that's
essential,
but
otherwise
quick
packets
will
be
sent
as
as
they
were,
with
just
one.
Additional
frame.
I
will
just
mention
after
after
that,
so
there
is
a
mapping
where
there
is
a
mapping
between
tooth
quick
packets
and
so
symbols.
H
So
the
first
symbols
be
a
little
bit
shorter,
because
that
means
more
overhead
and
more
will
had
some
additional
information
at
the
beginning
of
this
simile.
Also
ones
will
be
a
bit
shot,
a
bit
larger,
so
they
are
not
all
exactly
the
same
size,
but
either
a
minus
5
or
a
minus
1
like
bytes,
where
he
is
a
single
size.
So
unless
there
are
questions,
I
don't
want
to
go
into
these
those
details.
I
mentioned
them
last
time.
H
Otherwise,
so
now
we
need
to
transmit
quick
packets,
so
quick
packets
will
be
sent
as
they
are,
with
just
one
exception,
wide
one
more
frame
in
these
induced
packets.
So
this
is
the
source,
fpi
fact:
payload
information,
that's
in
that
case
a
very
simple
piece
of
information
is
just
so
simple
identifier
which
is
in
this
version
of
the
document.
We
suggest
to
use
a
viable
integer,
but
we
may
decide
something
else.
It's
not
very
important
so
but
I
mean
that
each
symbol
will
be
identified
very
precisely
with
only
light
and
with
an
identifier.
H
Otherwise,
quick
packet
or
a
repair
packets
that
have
been
produced
by
the
encoder
will
be
transmitted.
We
propose
to
transmit
them
as
another
type
of
frame
that
we
call
repair
friends,
so
that
can
be
one
or
more
repairs
involves
repair
frames.
We
can
adapt,
depending
on
the
maximum
payload.
We
can
have
well
depending
on
the
path
MTU
and
the
symbol
size.
H
So
we
need
to
put
more
information
that
case,
because
we
have
to
explain
now
this
disorders
or
repair
symbols
have
been
produced,
so
we
need
to
specify
what
was
the
and
cunning
window
and
this
encoder
at
that
time.
So
this
is
why
we
had
not
find
first
symbol
in
inside
this
and
cunning
window.
We
also
need
to
specify
how
many
symbols
were
in
this
and
cunning
window.
H
We
also
need
to
specify
an
additional
parameter.
Dt
I
won't
explain
what
it
is,
and
we
also
need
to
specify
how
many
we
pass
symbol
has
been
produced
and
put
in
this
repair
frame,
because
it
needs
to
be
self-sufficient
by
processing
is
either
you
need
to
identify
exactly
what
is
the
size
of
this
frame.
So
that's
the
reason
for
this
number
of
replacing
bells
and
RS.
H
H
So
the
situation
is
the
following.
We
have
reference
implementation,
the
reference
implementation
from
Francoise
mission,
which
is
open
source,
so
we
can
download
it
and
test
it.
There
are
few
open
questions,
but
it's
far
from
being
finished.
Of
course,
some
of
them
may
also
mention
price.
Itf
I
have
two
more
open
questions
that
those
are
design
things
I,
don't
think
it's
so
so
important
to
detail
them
at
the
moment,
but
we
are
making
progress.
That's
the
good
part,
so
it's
not
finished,
but
we
already
have
some
something.
H
That's
spirit
that
start
to
be
a
bit
sound.
I
would
say
we
start
to
be
confident
in
what
we
are
doing.
We
have
this
working
implementation.
It's
we
can
recover
from
packet
losses.
We
can
adapt
to
several
situations,
so
we
especially
Francois
but
also
is
our
manual
and
people
are
working
on
this
topic
and
we're
making
progress
well
so
making
tests,
and
so
there
will
be
additional
presentation
performance
results.
We
can
expect
from
those
from
this
evolution
of
potential
evolution
of
quick
in
the
future
ITF
meetings.
H
O
H
Okay,
so
the
question
from
Caston
is
about
the
value
for
e,
so
I
think
yes,
I
have
an
additional
slide.
This
is
one
slide.
I
mentioned
last
time,
so
the
e
value
is
the
symbol
size
value.
So
it's
something
which
is
important
because
in
practice
you
may
choose
any
value
between
few
bytes
and
a
few
hundreds
or
thousands
of
bites
and
depends
that's
one
of
the
key
parameters
and
there
is
no
single,
and
so
it
really
depends
on
the
use
case.
H
H
If
you
have
largely
variables
symbol,
quick
packet
sizes,
having
a
small
values,
will
enable
you
to
adjust
very
efficiently
to
those
variable
sizes
efficiently.
You
won't
be
obliged
to
produce
very,
very
large
repair
symbols
if
all
this
incoming
sauce
packets
are
very
small,
it
would
be
sufficient,
but
ok
having
a
small
value.
Small
Y
value
in
that
case
is
interesting,
is
a
good
choice.
H
But
at
the
end,
if
you
use
something
which
is
too
small,
then
you
will
end
up
with
large
number
of
source
symbols
with
large
linear
systems,
which
means
that
you
will
have
more
processing
overhead
that
the
encoder
decoder,
so
that
is
also
well.
There
is
a
balance
to
find
between
all
of
them.
I
don't
have
any
magic
value,
that's
the
parameter!
We
need
to
test
and
find
a
good
balance.
It
will
probably
be
use
case,
dependent,
I,
don't
know.
J
J
E
H
H
H
We
have
either
original
quick
packets
containing
source
data
plus
this
FBI
frame,
because
we
need
to.
We
need
to
provide
this
additional
information
in
order
to
keep
both
ends
synchronized.
So
that's
one
possibility,
but
basically
those
quick
packets
are
not
modified
accepted.
We
had
frame
or
we
have
repair
packets,
and
in
that
case
those
quick
packets
contain
those
repair
fret,
okay,
that
can
be
one
or
more
than
one,
but
I
guess
that
in
one
but.
H
H
O
H
E
Also
the
same
team
in
Inuvik:
they
have
a
in
architecture.
It
is
called
pluggable
quick
to
allow
extending
quick
without
changing
the
basic
protocols
in
the
basic
mechanisms,
and
we
feel
that
that
could
be
a
really
good
example
or
a
use
case
for
the
pluggable,
the
pluggable
quick
so
and
they
had
a
paper
in
sitcom
this
year.
So
this
is
actually
could
be
one
way
of
doing
this
without
again
touching
too
much
the
the
current
implementations
when
they
get
to
v1
yeah.
H
H
P
P
H
H
O
H
That's
the
main
benefit
of
having
a
specification
of
the
code,
specific
fall
of
the
codes
dot
where
all
those
mathematical
and
more
complex
aspects
are
specified,
and
then
you
just
design
fake
schemes.
So
that
explain
what
is
additionally
required
to
use
you
do
Scots
in
this
context,
with
those
protocols
and
now,
of
course,
usually
seven
ways
to
do
that.
J
Yes,
I'm
an
illusion
again,
just
to
complete
I,
think
adding
effect
to
quick
is
completely
different
from
adding
effect
to
stoner
UDP,
so
we
cannot
mix
both
together
and
just
a
little
bit
of
tied
advertisement.
You
can
use
the
trees
if
you
want
to
play
UDP,
for
instance,
but
I
have
another
question
about
the
packet
format.
Just
the
years
reaper
sambar
you
got
here,
is
it
optional
or
if
I
don't
use,
for
instance,
inside
quick,
rather
than
see
packet,
the
a
no
repair
frame?
There
is
no
repair
frame.
H
J
J
H
H
J
J
E
E
So
we're
the
next
presentation
about
coding,
congestion
control,
so
today,
I
think
we're
dressing
things
that
we
had
for
a
long
time
on
our
list
and
there
was
no
real
contribution.
So
we're
very
happy
about
this
contribution.
Now,
as
it
is
absolutely
a
question
every
time
you
add
coding
anywhere
the
first
question
that
people
ask:
you
is:
how
does
it
interact
with
congestion
control.
B
Thank
you
for
the
nice
introduction.
We
were
lucky
to
have
Francois
Michel,
coming
to
Toulouse,
to
do
some
tests
on
satellites
and
Francois.
They
don't
really
like
the
way
in
research.
You
have
people
comparing
coding
mechanisms
that
ignore
congestion
with
coding
in
Caen
ISM
that
do
congestion.
So
basically
it's
always
an
unfair
comparison.
People
do
coding
and
show
oh
look.
My
coding
mechanism
is
great
sure.
You
are
just
ignoring
losses
so
because
it
was
slightly
pissed
off
with
that.
B
We
decided
to
start
a
draft
to
explain
what
we
think
on
best
current
practice,
even
if
it's
not
the
place
of
an
RTF
group
to
speak
about
this
based
on
practice,
but
at
least
what
we
at
least
err
based
on
which
we
can
discuss
and
can
we
put
must
or
not,
even
if
it's
a
research
group,
you
know
that.
So
if
we
look
at
the
FCC
56
81
TCP
is
a
loss
based
congestion
control.
We
know
that
VB
are
around,
that
you
know
losses,
but
that's
another
topic.
B
So
just
a
disclaimer,
because
we
wrote
that
without
the
tooling
in
mind,
so
just
something
we
wanted,
because
we
are
worried
on
quick,
ignoring,
is
you
know
a
satellite
use
case,
so
that
was
reapplied
and
twins
what
we
started
like
that?
Maybe
it
can
be
applied
to
tunnels,
but
that's
not
the
initial
discussion.
B
What
we
propose
is
simple,
because
even
between
the
others,
we
didn't
agree
with
the
tradition,
but
you
need
to
have
a
base
solution
and
you
may
need,
if
you
have
a
draft,
when
you
only
say
you
may
do
that,
you
may
do
that.
You
just
end
up
saying
nothing.
So
what
if
I
did
you
need
to
say
things?
So
we
said
the
receiver
most
indicates
to
the
sender
that
one
or
multiple
packets
have
been
recovered
using
a
scheme.
B
So
then
how
it
does
so
depends
on
the
condition
control
on
mechanism
that
is
using
for
them
for
you,
you
could
use
this
hand
signals
if
you
are
using
TCP.
You
could
use
a
new
type
of
signals
such
as
recovered
frame
in
quick,
so
that
it
depends
on
how
you
were
doing
things,
but
the
receiver
mass
indicates
because
we
think
the
didn't
decision
is
at
the
sender,
because
he
knows
more
about
the
situation
in
the
network.
He
knows
more
things
and
the
client
on
me.
So
so
the
favour
must
be
able
to
detect
the
signal.
B
Those
are
the
base
idea.
We
do
not
describe
how
we
must
react,
but
then
we
can.
We
just
drive
list
of
possibilities
because,
on
the
sender
side,
when
you
do
coding,
you
could
just
ignore
the
condition
window
provision,
you
could
just
decide
that
whatever
I
do
I
just
add
ten
packets
or
whatever
I
do
I
just
add
a
coding
rate,
so
every
packet
I
could
do
whatever
I
want
I
just
ignore
the
condition
window
position.
That
was
something
you
could
do
that
some
things
that
some
people
in
research
papers
do.
Q
My
Keveza
nitpicking,
if
I
consider
the
previous
slide
again
I
was
thinking
about
this
statement
of
the
receiver
must
indicate
to
the
sender
that
one
or
more
multiple
packets
have
been
recovered.
So
the
point
here
is
that
the
sender
doesn't
doesn't
well
learns
about
loss
right
thoughts,
so
that
is
one
thing
which
is
okay
to
do
Bob.
Q
Q
B
You
still
inform
that
the
packet
has
been
lost
because
you
don't
acknowledge
them
and
when
you
just
then,
if,
if
it
either
unavailable
transfer
the
favor
knows
about
it,
it
knows
it's
an
unreliable
transfer,
so
it
would
just
ignore
that
the
packet
has
been
lost
and
go
on
sending
new
packets.
That's
that's
more.
The
more
things
are
at
the
offender
because
he
knows
what
you're
sure.
Q
Iiii
agree
with
that,
but
I'm
thinking
that
there
there
is
a
corner
case
here
that
may
this
may
require
a
bit
too
much.
Actually
so
there
can
be
a
case
where
I
send
ten
packets
and
five
of
them
are
lost
and
two
of
them
are
recovered
right.
Then,
if
it's
an
unreliable
data
transfer
where
I
don't
need
to
retransmit
everything
I
care
about
knowing
about
the
five
but
I
may
not
care
about
the
tool.
B
Okay,
I
think
it's
true
that,
but
then
it
depends
on
how
what
signals
you
used
to
notify
what
has
been
lost
or
what
hasn't
been
lost
and
then
how
you
actually
do
it
that,
because
you
could
say
you
could
sack
and
say:
okay,
these
paper
packets
have
been
recovered.
This
one
have
been
lost.
This
one
are
on
my
side.
You
could,
if
you
are,
if
you're,
using
a
new
type
of
framing
quick,
you
would
actually
do
that.
B
O
B
At
me,
you
can
have
networks,
we
are
doing
later.
We
are
doing
and
you
actually,
we
cover
a
packet
that
your
knowledge
dressed
white
right
after
that's
something
that
indeed
we
have
discussed
with
Emanuel
recently,
and
we
were
thinking
that
they've
also
an
impact
on
the
GA
acknowledgements,
because
we
don't
act
every
packet.
You
may
have
a
delay
that
could
cover
this
kind
of
effects.
I
think
that's
something
we!
Yes,
we
need
to
have.
If
we
go
further
with
the
document.
That's
the
end
of
the
presentation.
B
I
Difference
so
this
is
fine,
but
I
think
you're
missing
the
inverse
case,
which
is
you
aren't
losing
very
many
packets
or
even
any.
But
you
don't
know
how
many
extra
coded
packets
you
sent
that
the
receiver
actually
didn't
need
to
recover
the
data
packets,
and
if
you
knew
that
you
could
actually
figure
out
whether
the
right
thing
to
do
is
to
increase
your
congestion
window
or
reduce
your
coding
rate
when
you
have
adaptive
coding
rates
and
so
I've
encouraged
you
to
also
look
at
on
the
success.
I
The
the
the
success
cases
where
you've
decoded
Pat
you've
decoded
something
with
with
to
repair
packets
right.
But
you
actually
wound
up
receiving
five
repair
packets
because
the
sender
was
sending
five.
So
it
gives
you
an
extra
degree
of
freedom
to
play
with
whether
you
want
to
increase
your
congestion
window
or
decrease
your
coding
rate.
B
Yes,
you're
right
point
taken
I
think
we
need
to
add
some
things
about
that
document
and
thank
you
because
I
think
it's
useful
if
we
want
to
go
further
with
that
to
gather
all
these
issues,
if
you
want
to
go
with
us
on
the
draft
you're
welcome.
Just
there
are
all
these
kind
of
corner
cases.
We
need
to
think
if
we
want
to
have
a
good
document
on
the
interactions
between
these
two
things.
We
need
to
have
people
that
know
a
lot
of
of
coding.
B
B
B
K
Spencer
Dawkins
I
I
wanted
to
just
thank
you
for
starting
this
work
and,
if
I'm
understanding
this
correctly
you're
at
zero,
zero
of
a
base,
solution
and
you're
already
getting
an
awful
lot
of
interest.
I
think
that's
a
really
good
sign
for
a
research
group.
So
thank
you
especially
for
bringing
it
I
hope
this
all
works
out,
because
I
know
that
there
are
people
who
need
it.
Thank
you
very
much.
E
B
Have
lots
of
slides
on
which
we
can
disagree,
and
that's
also
why
we
wanted
to
have
statements
very
strong
statements
from
the
beginning
because
you
interest
people
if
you
have
strong
statements,
if
you
just
say
we
may
do
that,
we
may
do
that.
Nobody
cares
and
to
have
a
thing
on
who
is
interested
and
come
with
us
on
that
document.
So,
on
the
Thunder
side,
basically,
dispensations
are
in
the
document.
There
are
two
things:
femicides
coding
solutions,
and
then,
and
then
what
do
you
do
because
everything
on
the
Thunder,
whatever
happens?
B
The
I
know
that
the
clients,
then
that
might
be
issues
because
we
don't
report
the
good
things,
but
at
least
when
we
cover
a
packet,
we
report
it
and
then
what?
If
the
the
first
part
of
the
presentation?
If
what
with
how
the
Thunder
ad
coding
and
the
second
part
is,
what
do
you
do
when
you
receive
recovered
packets
information?
B
There
are
two
parts.
The
first
part
is
you
could
just
ignore
the
congestion
window
and
do
ad
according
a
repair
window
that
could
be
based
on
another
congestion
control.
You
could
use
let
bat,
for
example,
to
try
to
have
somehow
lower
than
based.
If
there
are
many
collisions
here,
just
you
could
just
have
your
constraint
window
and
that
we
know
that
are
the
same
and
you
just
add
packets,
you
ignore
congestion.
B
The
other
solution
is
you
have
your
congestion
window
and
within
that
you
include
you
in
packets,
and
that
is
when
your
point
Dave
is
important.
It
with
there
are.
The
link
between
the
data
rates
ends
actual
data
and
timing.
So
that
is
where
that
maybe
they
offer
the
solution
with
one
way
of
seeing
the
things
for
the
sender
side
reactions,
we
could
say
when
I
receive
a
recovered
packet.
I
consider
that
as
the
lost
packet,
if
I
have
the
same
type
of
reaction,
that
I
do
when
I
lose
a
packet.
B
That's
a
solution,
but
when
you
are
considering
anything
like
your
lamp
was
saying
when
you
have
huge
losses,
you
don't
want
to
have
this
kind
of
behavior,
because
what
the
hell
you
need
and
coding,
if
you
just
behaving
as
if
a
packet
was
lost,
you
just
maybe
save
some
entities
but
not
really
relevant.
Another
solution
is
doing
from
how
what
what
you
have
in
your
I
have
seen.
Eighty
five
eleven
saying:
I
just
have
my
congestion
window
and
there's
the
loss
and
when
that's
a
Reaper
packet,
I
just
diminish
it,
but
with
a
lower
level.
B
B
Because
that's
because
maybe
for
the
man
who
just
have
three
solution.I
I
just
consider
the
packet
is
lost.
I
do
the
same
thing:
that
for
love
packets,
I
do
not
sing.
That's
what
lots
of
research
papers
do
I,
ignore
losses
and
go
on
increasing
my
career
in
window
as
if
there
is
no
loss-
and
this
is
somehow
maybe
a
trade-off.
That
would
be
interesting
on
I.
Don't
ignore
all
the
losses
but
I
still
reduce
in
case
there
was
actual
collision.
You
don't
make
it.
E
Q
K
So
mr.
Dawkins
again
I
just
wanted
to
mention
one
other
thing
here
so
yeah
the
the
the
the
thing,
the
thing
where
we
spent
I
don't
know
how
much
time,
but
you
know
maybe
four
or
five
thousand
RFC
numbers
amount
of
time,
trying
to
decide
that
EC
and
signals
weren't
just
the
same
yeah
the
same
as
loss
and
going
to
be
treated
as
loss
and
that
we
wanted
to
do
scalable
congestion
control,
the
the
you
know
the
silver
it's
like.
K
Now
we
want
to
do
easy,
act1
and
getting
that
through
the
community
and
into
into
RFC's
was
a
hugely
big
deal.
So
I
would
ask
you
you
you
might
want
to
think
about
kind
of.
Do
you
want
to
shoot
for
it's
the
same
as
loss,
which
is
the
other
ct0
view
of
the
world
or
it
is
do
I.
Do
I
just
want
to
live
in
a
nice
et1
world
it.
K
You
know
where
I
can
tell
people
to
speed
up
a
little
bit
and
slow
down
a
little
bit,
and
that
might
tell
you
things
also
about
how
much
coding,
you're
doing
or
not
doing
and
I
think
that
not
to
step
on
courses
toes,
but
that's
something
that
would
be
extremely
helpful
for
the
many
kinds
of
proposals
that
are
like
loops.
You
know
it's
like
you
know.
We
know
something
happened
and
we
don't.
You
know
we
want
to
do
the
right
thing
and
we
don't
know
what
that
is.
J
Point
good
point:
definitely,
in
fact
what
we
want
to
highlight
here
is
there
is
an
antagonism
by
using
both
congestion,
control
and
errors,
you're
coding
at
the
transport
level-
and
it
will
be
the
case
for
every
kind
of
protocol,
whatever
it
is
TCP
or
quick.
We
will
get
the
exact
exact
case
because
you
got
one
is
going
to
grow
up
because
there
are
more
more
laces
if
it's
adaptive
as
set
by
your
Dave
or
and
you
will
get
a
congestion
control
but
is
going
to
decrease.
J
So
there
is
a
problem
and
you
you
won't
get
a
good
result
anyway.
So
the
fact
is
how
we
manage
that
is
the
network
is
going
to
manage
the
redundancy
and
to
drop
it.
If
it's
too
much
rodents
inside
the
network
treat
it
as
a
best-effort
traffic
using
some
scheduling
mechanisms
that
gives
all
I
don't
know
how
we
are
going
to
manage
both.
Maybe
it's
not
that
the
TCP
level
or
the
transport
level
we
have
to
do
that.
Maybe
it
should
be
stick
at
the
IP
or
low
level
link
layer
level.
J
H
May
I
add
something
as
I
understand
this.
The
goal
of
this
document
is
not
to
solve
all
the
problems.
The
goal
is
to
highlight
that
guys,
as
Emanuel
said,
an
antagonism
and
that's
the
bunch
of
proposals.
I
won't
say
solutions,
but
proposals
and
we
need
to
discuss
them.
The
goal
is
to
make
it
to
bring
some
some
light
in
this
domain.
O
We're
talking
about
goals,
why
do
you
want
to
do
interesting?
Control,
I?
Think
the
obvious
answers
to
protect
the
network,
but
there's
also
always
the
question:
do
you
want
to
have
TCP
fairness,
I
think
you
have
to
be
very
explicit
about
what
your
objective?
Yes,
do
you
just
want
to
protect
the
network?
Ok,.
B
So
I'm,
not
the
type
of
guy
that
hide
my
objectives.
My
objective
is
to
have
quick
working
on
satellite
links
and
I,
see
that
we
have
issues
in
our
networks
where
we
have
losses
so
I
think
maybe
having
people
to
sync
together
on
whether
we
can
include
FEC
in
quick
is
what
happened
and
I
know
that
when
one
of
the
wall
that
we
will
have
when
for
quick
v3,
we
will
have
FEC
in
quick
there
will
be.
But
how
do
you
manage
interactions
between
FEC
and
corrosion
control?
B
We
will
have
this
discussion
happen
if
we
end
up
adding
FEC
in
quick.
That's
my
main
that
I
said
owners.
We
are
end-to-end
networks
with
losses
where
we
have
to
manage
some
congestion,
and
so
I
want,
with
this
document,
to
prepare,
at
least
by
base
on
which
we
may
agree
on
advantages
or
disadvantages.
B
When
we
will
have
the
walls
of
deploying
this
kind
of
solution
for
quick,
otherwise
efficient
quick
will
not
happen.
We
could
be
people,
lots
of
people,
don't
like
it,
and
people
would
say
how
do
you
manage
it?
Country
control
is
complicated
and
so
on.
So
if
we
end
up
with
some
simple
solutions,
we
may
end
up
having
that
deployed.
Yeah.
O
O
B
Okay,
so
we
may
want
to
put
that
in
the
document
that,
because
this
is
this
is
something
that
we
have
added
on
the
slides-
that
it
is
not
for
the
tunnels.
We
have
to
insist
on
the
site
that
it
is
for
end-to-end,
where
we
need
to
have
some
sort
of
TCP
finish.
Even
if
there's
a
huge
paper
of
bubbly
school
on
TCP
Finance
same
thing,
it's
useless,
but
that's
very
nice
paper.
If
you
are,
if
you
have
time
on
your
plane
like
so.
I
I
You
know
have
fun
so
so
you
know
I'd
encourage
a
lot
of
people
in
the
room
who
are
interested
in
either
no
coding
or
congestion
control,
or
both
together
to
sort
of
help,
give
some
guidance
and
and
and
and
sort
of
point
people
in
the
right
direction,
because
we
could
spend
a
lot
of
time
doing
useless
simulations
and
and
research
that
doesn't
actually
inform
the
final
solution.
Yes,.
B
F
E
In
sake
of
time,
this
sketch
he
could
be
going
on
forever.
In
the
sake
of
time,
we
would
like
to
cut
the
line,
but
I
again
for
those
of
you
who've
been
involved
with
us
for
quite
a
long
time.
Congestion
control
and
the
interaction
with
coding
was
one
of
the
original
research
group
items
that
we
had.
E
Think
now
we're
at
the
point
where
we
need
to
start
looking
at
the
implications
of
coding
and
protocols,
and
this
is
a
perfect
ID
for
it,
and
if
everybody
agrees,
we
will
bring
back
the
work.
The
research
group
work
item
and
and
actually
make
progress
on
this,
and
if
somebody
disagrees,
please
come
to
the
microphone.
E
M
Thank
you.
It's
a
kind
of
follow-up
of
a
discussion
by
mention
on
the
fake,
generate
fake
API
codec
that
has
been
presented,
and
that
is
ongoing
and
my
presentation
here
is
more
about.
How
can
it
be?
Excellent
watch
is
needed
and
it's
just
to
start
the
discussion.
There's
no
definite
answer,
of
course
now,
and
it's
linked
also
to
the
general
problem,
but
of
course
in
many
protocol
unitary
challenge,
States
and
some
of
it
is
related
to
your
coding
state,
and
this
should
be
reflected
back
into
that.
M
You
have
on
the
left
side,
verse
under
on
the
right
side,
which,
if
a
node
it's
a
systemic
code,
so
it's
awesome
bellossom
directly
and
then
the
IP
I
divided
the
application
with
encoder
and
the
application
feed
was
watsonville
to
encoder
and
from
time
to
time
it
will
ask
for
a
Rita
packet
and,
oh
it
does
that
is
by
specifying
which
source
ID
it
wants
in
the
linear
combination,
also
implicitly,
whatever
coefficient
that
it
wants.
So
these
are
then
the
application
asked
for
repair
it
is
then
obtained
son
of
our
guai
and
various
fell.
M
Note
does
the
symmetric
things
which
is
filled
all
the
received
packet
inside
the
decoder
and
then
when
it's
a
repair
packet,
specify
exactly
which
of
source
ID
and
which
have
coefficient
value,
which
is
amplitude
but
can't
be
explicit,
and
then
we
recovered
sauce
sambal
a
thumbtack.
So,
as
you
can
see
this,
this
is
the
most
of
grunge
genetics
I
copy.
You
can
do
a
lot
of
things
with
it,
but
there
is
a
question
of
you:
don't
see
a
lot
of
state
exchange,
so
here
is
a
question
of
okay.
M
If
you
want
to
do
more
general
protocol
like
if
you
had
feedback,
we
have
description
logic
back
or
if
you
want
to
do
information,
centric,
networking
or
on
them,
lineal
cutting
a
rainy
sea
and
doing
the
recording
part,
or
even
if
you
want
to
do
some
multicast
transport.
So
there
was
a
discussion
this
week
from
Stinson
multicast,
the
in
the
LP
one
group
where
they
want
to
do
potentially
a
new
kind
of
fake
resident
basis,
but
a
very,
very
short
packet.
M
Those
on
the
bytes-
and
if
you
want
to
do
that,
can
you
do
that
with
the
current
API
and
the
thing
is
that
if
you
look
at
you
on
protocol
implementation,
they
don't
always
do
have
a
codec
abstraction.
So
if
you
make
a
codec
abstraction
and
want
to
look
at
alpha
motion
through,
it
will
be
a
little
bit
like
on
this
diagram.
So
the
receiver
States
has
to
go
from
the
codec
to
application
and
then
it
has
to
be
sound
of
other
way.
M
If
you
have
some
kind
of
feedback,
it
can
be
a
summary
of
a
local
state
of
the
local
state
of
a
codec.
So
it
could
be
ever
want
a
state
or
it
would
be
a
summary
and
then
the
sound
annoyed
will
typically
also
get
rocker
state
of
encoder
and
using
both
affirmations
it
will
generate
a
coded
summer.
So
I
think:
okay,
there's
not
much
affirmation,
you
know,
but
it's
just
described
formation
flow
and
everything
is
the
detail
of
all.
M
M
Is
it's
not
if
you
do
recording
you,
don't
have
access
to
all
the
saw
some
more
so
you
need
to
have
formation
about
which
sample
you
could
generate,
and
then
you
need
to
match
both
what
you
need
and
what
you
can
generate,
and
this
is
not
straightforward
because
you
can
end
up
having
to
solve
and
ex
coding,
prime,
if
you
didn't
think
well
all
week
I'd.
So
there
is
a
kind
of
research
and
design
issue
here
now.
M
We
I
don't
have
as
I,
don't
have
precise
solution
to
external
API
on
this
subject,
but
if
we
look
at
what
we
will
do
in
the
current
implementation,
so
of
course
local
state
as
we
do
in
our
coding,
can
be
represented
as
in
matrix.
So
we
could
imagine
two
paths
to
you
can
imagine
to
pass
the
matrix
back
to
the
application,
but
it's
of
course
it's
large
its
growers.
It's
not
nice,
because
when
typically
we
will
have
to
do
algebra
in
the
application
of
protocol
part,
maybe
even
eight
representation.
M
For
instance,
if
you
do
kind
of
DPC,
pealing
decoder
and
ready
to
and
sunder,
maybe
a
Tanner
graph
representation.
I
don't
know
so
there
is
this
open
question
for
the
API,
for
the
local
state
and
for
remote
state
summary
so
era.
Okay,
there
are
several
things.
So,
first
of
all
you,
you
could
generate
lease
on
your
state,
so
maybe
even
with
the
previous
magics,
all
you
could
request
directly
what
you
want.
M
So,
if
use
on
your
state
of
course,
the
other
side,
we
know
what
you
need,
then
you
could
also
implicitly
state
what
you
have
by
doing
a
acknowledgement.
Then,
if
suppose
know
what
receiver
as
lost
and
what
it
has
received,
he
can
deduce
at
least
a
passionate
kiss
pessimistic
bound
of
what
with
the
receivers.
M
And
then,
if
you
want
an
explicit
summary,
so
you
can
send
the
matrix
or
you
can
do
some
kind
of
compression
of
information,
your
own
matrix,
for
instance,
up
to
where
you
have
decoded,
or
you
can
also
specify,
for
instance,
on
the
sandbar
ID
level
which
which
ID
you
want.
You
don't
want.
You
are
interested
in
unity
or
on
which
which
are,
or
you
can
send
something
created
with
you.
So
here
are
various
also
for
the
IP
I,
the
question
of
which
is
a
what
is
a
good
representation
of
a
remote
state.
M
And
then
we
can
look
quickly
at
some
existing
protocol,
which
is
more
on
the
remote
state
level,
so,
for
instance,
for
net
code
coding
sources,
yen
and
yen
draft.
They
have
much
the
emotion
of
feedback
int
and
also
how
to
transmit
us
information
in
Dragon
cast
and
Dragonette.
The
information
that
you
use
on
protocol
level
is
the
last
sample
decoded
and
then
wrong
and
highest
symbology.
M
H
H
Let's
do
things
more
specific,
let's
leave
them,
he
has
implementation
specific
features.
Is
this
generic
get
fake
parameters
that
does
not
require
you
to
specify
exactly
how
to
do
that
that
can
be
used
in
an
implantation
specific
way.
So
we
will
talk
about
it,
but
it's
good
to
point
this
requirement.
Okay,
thank
you.
So
I
suggest
we
skip
the
last.
It
done
from
module,
and
now
we
have
a.
E
So
now
we
have
more
time
for
you,
Kirsten,
and
this
is
actually
the
view
from
the
IETF
I
think
at
the
IRT
F
opened.
We
talked
a
lot
about
collaborations
between
the
ietf
and
the
IRT
F
and
how
to
you
know,
move
things
from
one
place
or
another
or
how
to
use
technology
or
the
research
that
was
used
that
was
developed
here
and
the
technology
that
was
developed
in
the
ITF
and
make
sure
that
they
they
match
better
together.
So
thank
you,
Carson
for
doing
this.
O
Yeah
I
want
to
give
a
quick
introduction
into
what
oopss,
who
has
been
at
previous
loops
site
meeting
about
half
of
the
people
here
in
this
room.
Okay,
so
I
will
have
to
speed
up
considerably
and
you
may
need
to
stop
me
if
you
are
missing
some
context,
yeah,
so
we're
in
the
net
recording
research
group,
so
I
think
we
all
agree
that
packet
loss
is
something
we
want
to
avoid.
In
particular,
tailors
and
loops
has
a
completely
different
approach
from
the
things
that
you
have
seen
here
so
far.
O
We
want
to
do
something
in
the
network,
so
the
hosts
are
completely
oblivious
to
what's
going
on.
The
hosts
are
sending
probably
encrypted
stuff
that
we
don't
understand.
Now
we
have
no
idea.
What
transfer
protocol
is
they
are
speaking.
All
we
are
seeing
is
IP
packets
and
we
want
to
be
able
to
recover
IP
packets
that
get
lost
within
one
segment
of
the
path
and
well.
This
can
be
done
locally.
O
Doing
things
locally
always
is
good,
because
we
can
do
this
fast
with
low
latency
and
we
also
don't
have
to
send
recovery
packets
end
to
end
and
spend
the
beds
everywhere.
We
can
do
this
in
the
network,
so
we
don't
have
to
upgrade
hosts
to
do
this
and
yeah.
The
new
thing
here
is
the
assumption
is:
we
are
not
going
to
rotate
through
the
packets.
We
are
not
going
to
touch
the
packets
and,
of
course,
traditionally
performance-enhancing
proxies
have
done
all
of
this
very
much
so
there
will
be
two
ways
of
doing
recovery.
O
One
approach
here
is
that,
given
this
is
that
this
is
in
the
network.
We
assume
there
is
some
management,
so
we
are
not
going
to
define
that
part
of
the
protocol
that
does
set
up
for
these
path
segments.
We
have
a
controller
model
here.
Maybe
there
will
be
a
yang
module
at
some
point
that
contains
all
this,
but
this
is
kind
of
out
of
scope.
O
Yeah
I
think
we
have
talked
about
congestion,
control
and,
given
that
we
are
a
tunnel,
we
have
to
export
congestion,
control
information
out
of
the
tunnel,
of
course,
preferably
with
ecn
and
possibly
with
silane.
If
dropping
now.
This
is,
of
course,
confusing
we're
trying
to
recover
packets,
and
then
we
are
dropping
some.
Of
course.
O
This
means
we're
just
recovering
a
few
packets
less
then
we
could,
and
the
assumption
is
if
there
are
modes
of
doing
this,
where
we
are,
the
recovery
still
is
a
net
win,
but
that's
not
what
I
want
to
talk
about
today,
but
really
loops
is
a
protocol
that
feels
a
lot
like
a
transfer
protocol,
but
isn't,
first
of
all,
it's
completely
separate
from
the
entrant
transfer
protocol.
We
are
not
meddling
with
that,
but,
of
course
we
are
providing
information.
We
are
sending
congestion
feedback,
so
the
ideas
that
loops
itself
is
not
controlling
the
sending
rage.
O
Maybe
it's
doing
some
pacing,
but
the
sending
rate
really
is
under
control
of
the
end-to-end
transfer
protocols
and
the
other
thing
is
residual
losses.
Okay,
this
is
an
unreliable
protocol
and
yeah.
We,
we
also
can
maybe
get
more
information
extracted
from
the
path
segment
that
your
traditional
transfer
protocol
could,
because
the
tunnel
is
carrying
aggregated
traffic.
O
O
We're
never
going
to
send
more
than
10%
overhead
and
everything
the
protocol
does
stays
within
these
10%,
and
that,
of
course,
has
some
interesting
effects
on
how
you
look
at
congestion
control,
because
you,
you
cannot
really
blow
up
the
network
with
those
10%,
so
you
might
have
a
slightly
different
view
at
this.
And,
finally,
since
this
is
a
tunnel,
we
have
multiple
flows
in
there
and
we
usually
have
a
lot
of
packets
in
flight
at
any
particular
point
in
time.
So
we
might
have
much
better
measurement
opportunities,
then
a
traditional
transfer
protocol.
O
There
are
a
few
strongly
documents
out
there.
There
is
a
use
case
and
problem
statement,
a
document
by
jove
and
gesture
right.
There
is
a
generic
information
search
by
by
unlikely
and
me-
and
this
is
pretty
much
the
the
protocol,
but
not
yet
bound
to
specific
bits
in
a
packet,
because
you
want
to
do
this
specific
to
encapsulations,
because
different
network
environments
have
differ
and
encapsulation
preferred
encapsulations.
So
this
is
the
generic
information
said,
and
this
is
then
bound
to
a
specific
encapsulation
like
genève
or
gue
or
GRE.
O
I
O
O
I
O
O
We
have
to
talk
to
a,
for
instance,
the
transport
area
working
group
has
been
discussing
congestion
feedback,
so
we
want
to
make
use
of
that
and
there's
lots
of
other
things
and
there's
of
course,
in
particular,
this
research
group,
which
we
plan
to
tap
for
all
the
information
about
radar
coding
and
recovery
that
we
can
get,
and
we
also
see
that
you
have
a
lot
of
experience
with
encapsulation
techniques.
So
one
of
the
figures
out
of
the
FEC
of
a
quick
document
already
made
it
into
our
slide
rail.
Yes,.
E
O
The
but
my
assumption
is
that
we
first
have
a
look
at
products
of
the
research
group.
For
instance,
these
documents
are
being
created.
They
actually
already
have
moved
to
the
IDF,
but
they
come
out
of
the
research
group.
So
it
makes
sense
to
talk
to
the
research
group
about
why
they
are
the
way
they
are
because
we
are
not
using
them
unchanged,
we're
using
the
general
general
approach.
O
So
this
is
one
part,
and
the
other
part
is
that,
based
on
the
number
of
assumptions,
we
will
have
specific
questions
so,
for
instance,
this
lists
three
classes
of
FEC
schemes
that
we
might
want
to
use,
and
this
is
a
random
guess
and
I'm
sure.
A
lot
of
people
in
this
room
have
a
more
refined
opinion
on
which
have.
O
The
ideas
that
the
the
group
will
formulate
questions
like
this
and
get
from
the
research
group
in
answering
these
questions,
or
at
least
formulating
hypotheses,
and
in
some
cases
the
result
may
be
a
research
question
that
actually
you
have
to
sit
down
and
do
a
simulation
like.
Like
my
question
about
a
couple
of
minutes
ago.
We
don't
know
what
that
number
will
be
and
we
will
have
to
design
some
research
to
find
out.
J
Definitely
I
think
there
is.
There
are
many
research
issues
here
when
you
when
we
deal
with
tuners,
so
you
get
multiple
flows
and
you
treat
the
aggregate
inside,
for
instance,
one
sliding
window
schemes
or
whatever
schemes
you
are
doing
and
following
their
redundancy
produc'd,
you
might
have
at
the
end
of
Virginia
some
ed
of
light
blocking,
because
the
protection
is
different
between
multiple
flows
and
you
need
the
sauce
repel
packet
to
be
able
to
decode.
Maybe
you
don't
have
a
good
sweeper
packet
for
a
given
flow.
J
J
O
J
J
N
Colin
Perkins
speaking
very
much
without
any
hats
on
I
mean
you
list
a
bunch
of
different
FEC
schemes,
though,
and
obviously
they
have
very
different
characteristics.
Yes,
one
of
the
things
we
found
with
doing
the
the
FEC
for
video
and
audio
in
apt
is
is
that
it
was
possible
to
build
general-purpose
mechanisms
that
you
started
out
with
a
very
simple
parity.
N
If
you
see
scheme
and
then
we
gradually
added
more
of
more
things
and
it
worked,
okay
was
the
the
simple
scheme
and
it
worked
perhaps
better
with
the
more
complex
schemes,
but
you
you
could
choose
where
in
the
spectrum
you
left.
Do
you
expect
this
to
be
the
same
sort
of
thing
where
there
will
be
multiple?
If
you
see
schemes
which
you
can
address
different
levels
of
protection
with
a
different
complexity,
IPR,
etc
trade-offs
or
giving
this
something?
That
needs
a
particular
FEC
scheme
to
make
this
work.
O
My
hunch
would
be
that
we
actually
want
to
dynamically
change
between
these
houses.
So
if
you
just
have
a
very
low
level
of
random
losses,
then
a
purchase
in
may
be
fine
for
you
and
when
things
start
to
become
interesting,
then
probably
you
want
to
have
a
better
scheme,
and
then
you
do
have
a
reason
to
expend
the
CPU
that
you
can
save
by
the
simple
expose.
E
O
O
We
did
the
same
with
the
real-time
media,
so
yeah,
so
that's
exactly
the
the
the
part
of
the
protocol
that
needs
to
be
designed
so
whatwhat's
in
the
forward
information-
and
this
is
this-
is
pretty
much
the
index
or
the
set
of
indexes
you
need
and
a
format
for
the
repair,
packets
and
in
the
reverse,
the
information
all
that
feedback
information
would
come.
That
is
needed
to
make
decisions
of
this
guy.
Yes,.
O
O
O
Yeah
it's
divided
up
and
this
is
not
necessary
related
to
the
way
they
are
sent
forward
and
then
maybe
we
want
to
do
some
piggybacking
schemes,
so
we
we
don't
actually
get
more
Pickers,
but
we
already
get
longer
packets
and
that
may
be
an
optimization,
that's
actually
useful
and
on
the
other
hand
we
made
too
may
want
to
split
packets
that
are
larger
than
the
MTU.
So
that's
very
much
open
whether
that
makes
sense.
O
What
are
these
classes
of
easy
schemes,
assuming
that
we
can
define
classes
that
need
approximately
is
the
same
kind
of
feedback
information.
So
within
the
class
we
can
be
algorithm
AJ.
But
when
you
go
to
a
different
class,
you
just
need
different
feedback
information
and
different
index
information
ideas
about
mitigating
the
entry
you
problem
would,
of
course,
always
be
a
help
for
how
do
we
make
use
of
feedback,
for
instance,
for
controlling
the
fec
rage?
O
We
haven't
been
chartered
yet
that
what
we
had
at
the
last
IDF
was
a
non
work
group
for
me
buff.
So
we
we
are
talking
to
the
AG's
on
getting
the
working
group
chartered,
but
that
doesn't
stop
us
from
actually
doing
the
taking
you
work.
At
the
same
time,
and
in
particular
you
want
to
explore
the
design
space.
O
There
is
a
github
repository.
There
is
a
mailing
list.
Please
join
the
mailing
list,
it's
not
going
to
kill
you
traffic
wise
and
if
you
are
interested
in
this
and
of
course,
if
you
have
input
to
the
Charter
proposal
that
is
at
github,
that
also
would
be
very
much
welcome
and
the
timeline
for
the
whole
thing
is
that
we
believe
it
should
be
possible
to
charter
a
working
group
in
time
for
IGF
1
over
7.
Let's
see
if
we
pull
this
off.
E
O
H
E
H
We
are
done
Wow
four
minutes
for
five
minutes
late
before
splitting.
I
would
like
to
say
something
we
are
about
to
adopt
several
documents
and
there
is
a
requirements.
If
you
want
your
documents
to
be
reviewed
by
others,
then
it
seemed
very,
very
important
that
you
yourself
review
documents
of
others.
That's
the
way
it
must
work.
So
please
read
and
send
comments,
especially
when
we
are
doing
last
calls,
but
not
only
so
please,
review,
read
and
review
and.
E
E
Thank
you
very
much
and
I
guess
we'll
see
you
and
Vancouver
and
for
those
of
you
who
are
interested
in
computing
in
the
network,
I
will
do
some
advertisement
and
please
come
and
if
you
hear
tomorrow,
please
come
to
the
other
working
group,
the
other
research
group
that
keep
keeps
me
awake
at
night
and
this
one
is
really
keeping
me
awake
at
night
computing
Network
tomorrow
morning
at
10:00.
Thank
you
very
much.