►
From YouTube: IETF108 NWCRG 20200727 1300
Description
NWCRG session at IETF108
2020/07/27 1300
A
Okay,
so
I
think
it's
time
to
start
this
is
a
small
session
in
a
way
15
minutes.
So
we
need
to
be
on
time
welcome
to
this
coding
for
efficient
network
communications
research
group
online
this
time.
A
A
This
is
an
official
irtf
session,
which
means
that
the
not
well
will
apply.
We
are
supposed
to
follow
all
those
rules.
Nothing
should
be
this
is
this
should
not
be
a
surprise
to
you.
This
is
the
same,
no
change.
A
If
you
contribute
to
this
session,
then
you
are
supposed
to
follow
the
irtf
processes
and
policies
which
are
exactly
the
same
as
the
ietf
one.
So
we
are
supposed
to
disclose
whatever
ipr
you
may
be
reasonably
aware
of,
we
are
also
supposed
to
behave
in
a
reasonable
and
appropriate
manner.
So
that's
the
goal
of
this
slide.
A
A
A
The
blue
sheet
will
be
automatically
filled
based
on
the
mythical
and
data
tracker
logs,
so
you
are
authenticated,
so
it's
not
a
big
deal
to
do
that
and
if
you
want
to
take
part
in
the
discussion,
if
you
want
to
ask
questions
or
do
comments,
so
please
please
raise
your
hand
so
we'll
see
on
the
top
left
corner
a
few
icons
and
in
particular
this
end,
which
enables
you
to
ask
for
to
be
in
the
queue.
So
please
do
that.
I
will
give
you
give
the
floor
to
to
you
in
the
other
arrival.
A
I
will
be
very
brief
for
this
introduction.
Then
I
will
move
to
the
hackathon
feedback
very
briefly
also,
and
then
we'll
continue
with
an
update,
a
presentation
from
nicola
an
update
of
the
coding
and
congestion
control
in
transport.
So
this
document
and
then
we'll
devote
the
end
of
this
session
for
the
next
steps.
A
That's
the
situation
for
the
work
having
been
done
recently
so
for
the
first
document,
the
network
calling
for
satellite
systems
internet
draft,
we
passed
the
isg
review
and
we
are
now
in
isg
review.
So
we
are
pretty
close
to
the
end
and
we
are
very
happy
of
this.
It
will
be.
It
should
be
the
second
ifc
published
from
this
research
group
on
progress,
the
coding
and
conjunction
control
in
transport
documents.
A
I
think
the
document
is
progressing
well,
so
we'll
have
a
presentation
for
this
item
and
then
there
are
a
couple,
a
few
four
documents:
four
five
documents
that
need
to
be
well
that
are
somewhat
in
standby
standby
mode,
for
which
we
need
some
action.
So
this
is
the
case
for
the
nc
for
cc
and
ndn
requirements
and
changes
documents.
In
fact,
we
need
to
start
a
research
triple
school
in
association
with
ic
energy.
A
A
A
A
A
A
B
Yes,
so
there
was
a
problem,
I'm
sorry
everyone,
I'm
late.
There
was
a
problem
with
my
registration
and
by
the
way
gather.com
with
the
secretariat.
It
works.
They
resolved
my
problem
in
three
minutes.
So
this
is
the
good
thing.
A
Okay,
thank
you
so
now
I'm
here
yeah
there's
some
echo,
so
maybe
you
could
solve
it
otherwise,
just
to
let
you
know,
I've
been
through
the
introduction
chair
slides.
So
I'm
now
going
to
talk
about
the
accustomed
feedback.
A
Okay,
here
it
is
so
we
held
our
hackathon
last
week
during
a
full
week.
We
were
sorry
I
need
yes,
so
the
goal
we
are
the
same,
just
to
remind
you
the
goal.
This
is
a
man
to
design
a
reference
open
source
free
codec.
We
are
focusing
on
the
the
simple
ilc
fsc
scheme.
First,
as
a
first
step
and
of
course
the
final
goal
would
be
to
facilitate
fcex
tests
and
adoption
in
itf
in
general,
for
instance,
we
have
a
second
goal,
which
is
to
challenge
the
generic
api
internet
draft
as
well.
A
Small
teams,
this
time,
cedric
myself
and
mary,
jose
all
of
us
part-time.
I
apologize,
but
I
had
a
little
time
to
devote.
Unfortunately,
it's
not
that
easy,
that's
personal
feedback.
I
would
have
it's
not
so
easy
to
to
work
to
devote.
A
More
time
when
you
are
online,
it's
not
the
same
as
being
physically
in
the
same
room
and
working
all
together
on
the
on
the
project
we
do.
There
are
many
distractions
and
at
the
end
I
had
unfortunately
a
little
time
devoted
to
this
hackathon
and
for
different
reasons.
Cilic
also
couldn't
participate,
as
he
would
have
lied
to,
and
my
journal
was
also
part-time.
So
we
made
progress
but
little
progress,
so
the
the
source
code
now
is
here.
A
Most
of
it
is
here
the
c
demo
application
has
is
done,
which
doesn't
mean
it's
working
fine,
because
we
still
have
debugging
to
do
in
the
core.
Swift
click,
but
at
least
the
source
code
is
here,
and
the
python
wrapper
for
tests
and
demos
has
been
done
also,
so
I
would
say
that
we
are
more
now
focusing
on
debugging
than
this.
Yes,
so
that's
a
good
sign
at
least,
but
there
are
still
work
to
be
done.
A
We'll
have
some
time
at
the
end
of
the
week,
hopefully
to
to
devote
in
this
and
then
to
have
a
an
additional
hackathon.
Next
ietf,
with
the
cl,
with
the
goal
to
clean
up
to
do
more
tests
and
to
improve
documentation.
A
Also,
we
have
this
internet
draft
that
has
expired
now,
but
that
could
be
revived
very
easily.
So
currently,
the
goal
of
this
internet
draft
is
to
discuss
and
present
the
api,
the
common
api
only,
but
I
would
like
to
enlarge
the
goal
with
also
some
information
on
how
to
use
it.
That
could
be
useful,
regardless
of
whether
this
entire
draft
is
published
as
information
or
not
that's
a
side
question,
but
at
least
to
have
this
documentation,
along
with
the.
A
A
B
And
it's
one
of
these
days,
so
my
my
jabber
doesn't
work.
So
I'm
not
seeing
what's
going
on
on
jabber.
But
that's
I
guess.
That's
fine.
A
Nicola,
can
you
hear
me?
Yes,
we
can,
if
you
can
speak
a
bit
loudly.
D
Okay,
I
will
try
to
speak
louder,
perfect.
C
D
Hello,
everyone.
This
is
a
quick
update
on
the
draft
on
the
interactions
between
coding
and
condition
control
because
of
what
happened
in
a
recent
few
months.
D
I
will
just
wrap
up
what
we
have
in
the
document
at
the
moment
and
we
have
some
on
the
point
open
point
for
discussion
at
the
end.
The
next
slide,
please,
basically
the
objective.
The
current
objective
of
the
document
is
to
discuss
how
fake
coding
and
constraint
control
can
coexist
and
also,
basically,
we
have
seen
too
many
research
papers
when
people
compare
the
fake
mechanism
with
others
and
from
consider
congestion
losses.
Some
doesn't
so.
D
So
next
slide:
please,
we
have
added
what
what
we
have
tried
to
make
new
in
this
version
of
the
document
is
to
always
mention
the
client
aspect
and
not
only
the
server
aspect,
so
we
I
have
here
all
the
new
figures.
My
point
here
is
not
to
go
through
all
the
figures,
but
basically
try
to
comment.
E
D
Basically,
what
we
start
the
document
with
is
to
be
clear
that
there
are
two
different
channels.
We
have
the
conjunction
control
channel
and
the
fake
channel.
Both
of
them
are
theoretically
decorated,
but
they
can
use
in
different
implementations
the
same
signaling
signals
to,
or
they
can
at
least
interact
between
each
other.
D
So
medically
the
condition
control
channel
is
just
we
send
source
packets
to
a
receiver,
and
we
may
have,
on
the
reverse,
pass
some
information
signaling
that
helps
us
have
information
on
the
current
state
of
the
network.
So
we
can
have
what
packets
have
been
received,
what
have
been
lost,
some
specific
markings
and
on
the
fpc
channel
we
can
send
repaired
packets
with
their
packets
and
also
we
can
have
information
on
what
packets
have
been
repaired
and
how
to
add
that
the
fec
coding
mechanism
so
next
slide.
Please.
D
We
have
divided
the
document
in
different
cases.
Whether
fec
is
about
transport.
Fpc
is
within
the
transport
or
below
the
transport
in
case
where
fec
is
above
the
transport,
what
we
mentioned
in
the
draft
and
is
that
there
are
many
potential
issues
when
we
have
a
rear,
enabled
transport,
because
the
transport
may
detect
losses
where
fec
actually
recover
the
problem.
D
So
in
this
case
we
mentioned
in
his
document
that
unreliable
transports
are
more
relevant.
The
good
thing
with
this
case
is
that,
when
adding
repaired,
packets
does
not
contribute
to
adding
condition
in
the
network.
So
that's
good,
but
then
the
repaired
packets
are
taken
from
what
could
have
been
taken
to
send
actual
data.
So
there
can
be
an
impact
on
the
good
put
for
latch
transfers.
D
Next
slide,
please,
when
fake
is
within
the
transport,
the
cool
thing
is,
is
that
we
can
do
lots
of
concert
and
optimization
there's
not
as
much
gain
as
what
basically
fpc
may
not
do
much
better
than
what
a
classical
transmission
mechanism
can
do,
and
there
is
an
impact
on
the
actual
boundaries.
D
So
in
this
case
they
it's
very
important
to
carefully
design
the
continuation.
D
So
one
from
some
examples
of
what
could
be
interesting
in
this
case
is
to
send
repair
packets
when
there's
more,
no
more
data
to
transmit,
for
example.
So
when
the
communication
is
over,
we
just
send
a
bunch
of
repair
packet
depending
on
what
the
constituent
controller
does
and
also
this
let
us
do
some.
D
Smart
scheduling
defending
what
may
be
needed
to
unlock
the
received
buffer
at
the
other
hand,
of
the
network
when
we
have
received
buffer
sizes
issues
next
slide,
please
fec
can
be
also
put
put
it
below
the
transport.
D
So
that
is
the
case,
for
example,
when
you
are
doing
tunnels
mechanism
so
here
that
we
can
have
lots
of
benefits
when
we
have
losses
on
the
past,
so
we
have
presented
previously
in
different
ietf
meetings
that
we
can
have
more
than
one
parts
and
losses
in
such
common
use
cases,
and
this
can
impact
a
lot,
is
actual
data
transfer
and
for
the
end
user
experience.
D
There
are
cases
where
we
have
a
mix
of
when
we
have
transmission
losses
that
can
be
actually
covered
recovered
by
fcc
mechanism.
The
problem
here
is
when
we
have
contracts
and
losses,
and
we
are
repairing
them
and
we
are
hiding
a
congestion
through
the
transport.
D
D
So
we
have
tried
to
be
more
clear
on
the
classification
or
on
when
basically
be
clear
on
how
fec
and
construction
control
can
interact
depending
on
how
they
are
positioned.
D
D
Mobile
mobile
systems
losses
that
we
have
when
we
have
optical
links
or
congestion
losses,
so
we
expect
to
present
some
results.
We
are
working
on
that
because
this
kind
of
thing
is
important
in
our
use.
Cases
and
distribution
would
take
place
to
carefully
design
the
coding
ratios
not
to
shoot
more
data
packets
in
quantity
networks,
but
then
I
think
we
are
now
facing
a
problem
on
what,
if,
if
what
we
have
in
the
document
here
useful
first,
we
are
just
discussing
some
things.
Should
we
move
towards
more
recommendation
draft?
D
Should
we
extend
more
from
specific
points?
I
think
that
to
move
forward
on
this
document,
we
may
need
some
feedback
from
the
group
on
this
aspect.
D
A
A
What's
what's
the
remaining
work,
what
amount
of
work
remains
to
be
done
for
this
if
we
remain
with
this
optic
with
this,
the
fact
that
this
remains
a
discussion
draft,
what
will
you
say.
D
I
think,
I'm
afraid
to
open
a
pandora
box
on
all
the
potential
solutions
that
could
be
envisioned.
So
I
guess
it
depends
on
the
time
we
could
dedicate
to.
It
could
be
huge,
and
that's
also
my
point.
Basically,
we
could
do
add
more
content,
but
is
it
if
every
time
the
the
amount
of
the
things
we
could
put
in
it
depends
depends
directly
on
the
time
we
would
dedicate
to
it?
So
I
think
it's
important
for
us
to
be
sure
that
this
is
needed,
or
if
the
discussion
is
taken
elsewhere
and.
A
A
Okay,
that's
a
that's
a
good
point
that
needs
to
be
yes
that
needs
to
be
considered
by
the
group,
so
us
so
that
we
have
a
realistic
position
and
this
document.
Yes,
I
understand
we
could
have
something
really
large
discussing
a
lot,
a
lot
of
things
yeah,
which
is
not
necessarily
the
goal
yeah.
Yes,
so
please,
please
do
contribute.
Do
ask
do
do
do
comment
and
how
much
you
want
to
be
in
this
document.
This
would
be
very
useful.
A
A
That
now
otherwise,
I
will
read
the
comment
from
dave.
One
thing
it
might
be
good
to
cover
is
how
to
couple
increasing
transmission
rate
with
increasing
decreasing
coding
rates.
It
might
be
interesting
to
use
increasing
code
rates
as
a
probe
to
more
satisf
safely.
Increased
transmission
rate,
as
this
being
looked
at
and
dave
spencer,
is
agreed.
A
Yes,
yes,
I
was
looking
at
the
chat
and
okay.
I
overlooked
the
queue:
okay
yeah.
Yes,
so
sorry,
sorry
for
that
yeah!
So
please
and
like
you
have
the
floor.
C
Yeah
thanks
so
my
my
question
was
across
like
it's
a
it's
a
two-part
question.
Maybe
one
is
when
we
are
saying
it
usually.
Fec
in
other
systems
is
part
of
the
physical
layer
and
it
involves
some
kind
of
synchronization
across
the
two
ends
because
you're
looking
at
latency
per
se,
when
you
do
any
kind
of
block
or
any
kind
of
a
window
based
mechanism.
C
So
is
there
any
kind
of
synchronization
mechanism
being
thought
about
either
as
part
of
the
underlying
transport
or
within
the
fec
signaling?
And
the
second
part
is
again
on
the
same
lines.
C
Usually,
the
the
packet
networks
have
have
an
underlying
differential
delays,
either
based
on
their
routes
for
the
same
channel
or
for
the
same
session,
or
it
could
be
also
differential
delays
over
time
so
because
of
the
changing
congestion
or
other
aspects
of
the
network.
So
are
these
aspects
being
looked
at
as
part
of
the.
D
Fec,
thank
you
for
for
the
question.
D
For
I
think,
my
my
the
something
that
may
be
missing
in
the
document
is
for
the
moment
we
present
the
two
channels
as
being
different
for
being
the
more
generic
as
possible.
D
We
did
not
dive
into
the
details
on
what
happened
in
if
they
are
not
actually
separated
channels
and
how
the
signaling
would
be
done,
because
I
think
it
is
depend
depends
a
lot
on
the
the
mechanisms
that
are
actually
used,
but
I
think
I
think
the
point,
and
if
we
go
further
with
this
document,
the
synchronization
and
aspects
must
be
pointed
out
as
something
that
must
be.
D
Thank
you.
I
don't
know
if
that
answers
the
questions,
but
I
think
it
was
more
comment
on
how
we
consider
the
synchronization
and
the
different
differential
delays
that
could
happen
between
different
things.
I
think
something
that
depends
on
the
protocol
that
I
use,
so
I
just
can
just
take
the
point
on
that.
We
may
need
to
mention
that
in
the
document.
F
This
is
spencer,
and
I
just
wanted
to
thank
you
for
doing
this
work.
It
is
really
it
is
really
important
for
the
question
about
the
discussion
draft
and
the
recommendation
draft.
I
do
so.
My
my
first
question
is
you're
thinking.
The
recommendation
draft
is
for
other
people
working
in
this
research
group
or
people
designing
protocols
in
the
ietf.
D
Thank
you
for
the
question.
Well,
I
think
that's
something
that
we
should
for
the
moment.
We
are
making
a
general
statement
draft
and
I'm
not
sure
we
have
enough
content
to
make
actual
recommendations
for
protocol
designers.
D
We
can
make
some
general
comment
on
if
you
do
fec,
please
consider
construction
control
may
use
losses
as
a
constituency.
No,
but
I
think
that's
something
that
is
quite
generic.
I'm
not
really
sure
to
what
extent
we
can
actually
make
useful
recommendations.
I
think
it
depends
on
how
deep
we
go
into
the
details
depending
on.
If
we
choose
specific
protocols
and
then
we
may
be
able
to
do
more
recommendations
such
as
how
you
could
use
vcn
signals
or
not,
what
do
we
recommend?
D
F
F
My
suggestion
would
be
to
do
that
as
two
different
drafts,
because
I
think
the
information
that
you're
putting
together
in
the
discussion
draft
is
important
and
I
think
recommendation
draft.
The
protocol
designer
should
be
really
crisp
and
short.
F
So
I
said
this:
this
is
really
important
because
the
people
in
the
itf
have
already
you
know,
raised
the
issue.
What
happens
if
you
manage
to
just
to
disguise
all
the
congestion
signals
by
repairing
all
the
losses?
So
I
I
think
you
know,
I
think,
you're.
I
think
you're
doing
the
right
thing.
My
my
suggestion
is
that
when
you
get
ready
to
do
recommendations
that
you
do
it
as
a
separate
draft,
thank
you.
A
Okay,
if
michelle
said
something
on
the
chat,
I
think
we
could
try
to
recommend
to
ignore
the
losses
or
recover
packets
when
using
a
loss-based
conjugation
control
when
the
path
is
not
completely
controlled.
That
is
to
say,
we
know
that
we
are
on
the
satellite
link
and
that
losses
are
not
due
to
congestion
yeah.
A
Okay,
if
there
is
nothing
else,
I
will
move
to
the
last
item
of
the
day.
Thank
you
nicola.
B
Okay,
so
next
slide.
B
Okay,
so
I
think
this
is
a
little
bit
of
the
review
of
what
we
were
supposed
to
do
and
I
think
we've
done
pretty
well
the
there's
stuff
on
the
tunneling
that
we
haven't
done,
but
the
nc
and
icn
we
did
the
congestion
control.
We've
talked
about
it,
the
vr
we
kind
of
abandoned
it
at
one
point,
because
it
was.
B
Too
much
we,
we
did
a
lot
of
work
on
the
the
I
wouldn't
say
the
common
api,
but
at
least
even
the
stuff
that
we
did
on
the
the
hackathon
was
related
to
that
the
satellite
we've
done
and
the
the
network
coding
and
quick
we're
we're
getting.
We
have
two
drafts
there
and
we're
getting
very
close
to
something.
B
This
was
delayed
actually
by
the
fact
that
quick
was
also
delayed,
and
we
have
a
solution
for
that
now,
but
we
were
a
little
bit
waiting
for
them
and
what
we
have
also
that
is
partly
done
is
we
wanted
to
have
one
draft
for
for
existing
solutions.
We
still
have
the
tetris
team
that
has
promised
to
to
complete
their
their
draft.
The
network
coding,
the
network
coding
from
mit,
the
random
linear
network
coding.
The
drafts
have
been
mostly
abandoned.
B
I
do
not
have
any
status
on
any
of
that,
but
we
have
at
least
one
and
obviously
we
have
based
on
swift
code,
which
is
already
adopted
as
a
fec
frame
rfc.
So
I
think,
in
terms
of
milestones
we're
doing
pretty
well.
B
We've
done,
I
think
you
know,
we've
had
pretty
successful
meetings
with
the
group.
There
was
at
one
point
a
a
thought
of
linking
what
we
do
with
what
they
want
to
do
in
loops,
which
is
a
a
buff
forming
there's
going
to
be
a
buff
forming
meeting
on
friday.
However,
in
the
meantime,
they've
decided
to
look
only
at
congestion,
related
losses
and
not
losses
related
to
non-congestion,
but
it's
still
something
that
they
could
do
in
their
hub
by
hop
in
a
way
a
view
of
the
world.
B
So
that's
actually
the
the
the
summary
again
of
what
I
just
said.
So
we
have
the
rfc
that's
published.
We
have
bats,
I
forgot
bats.
Bats
is
active
and
there's
actually
a
lot
of
work
on
that
rlc
has
been
published.
Like
I
said,
tetris
is
active.
We
have
two
active
quick.
We
have
the
almost
done
for
the
satellite
and
we
have
the
common
coding,
swift
and
I
think
what's
missing.
Maybe
you
have
it
on
the
next
slide.
But
what's
missing
here
is
there's
there's
this
newcomer
thing?
It's
not!
B
It's
not
a
draft,
but
it's
actually
stuff
that
we
have
there
like.
I
said
we
decided
to
let
a
bit
of
it.
Let
it
go
of
the
draft.
We
have
the
congestion
control
that
is
very
much
was
presented
today
and
is
being
in
progress
and,
and
we
want
to
make
progress
on
it
and
the
draft
fancy
in
icn
is
really
active
and,
and
we
you
know,
we
expect
the
last
call
very
soon.
B
B
So,
but
in
spite
of
everything
I
said
so,
let's
now
be
realistic,
where's
the
network
coding
research
going
essentially
right
now.
What
we
see
is
that
coding
is
just
a
subset
of
what
is
being
done
for
efficient
communication.
B
What
is
being
done
for
efficient
storage
in
order
to
you
know,
and
caching
also
and
everything,
there's
a
lot
of
potential
research
and
congestion
control.
B
Although
from
what
I
see
in
terms
of
real
implementation
of
network
coding
and
systems,
a
lot
of
time
again,
they're
done
over
tunneling,
and
then
you
know
you,
you
resolve
the
issues
of
of
congestion
and
other
way,
but
that
actually
is
still
an
open
topic.
But,
as
you
can
see,
there's
a
lot
of
from
the
draft.
Actually
there's
a
lot
of
requirements,
there's
a
lot
of
recognition
of
the
interaction
between
coding
and
congestion
control.
But
you
know
right
now
there
it's
good
examples,
but
there's
not
really
solutions.
B
I
think
what
we
think
is
happening
is
that
the
the
field
is
is
getting
pretty
mature.
This
has
been
going
on
for
quite
a
while
now
and
obviously,
when
it
started.
There
was
still
this
question
that
if
there
was
a
a
role
for
network
coding,
there
was
a
lot
of
research,
a
lot
of
it,
driven
by
the
mit
group
on
essentially
applying
network
coding
to
a
huge
subset
or
even
a
super
set
of
network
applications
and
services,
and
there
was
the
work.
B
Obviously
the
important
work
done
in
both
indriya
and
and
toulouse,
and
so
there
was,
it
was
a
very
active
role.
Active
field
we've
seen
it
a
little
bit
going
down.
B
I
think
another
thing
that
we've
been
burdened
at
this
group
since
the
beginning
of
the
group
has
been
the
huge
ipr
environment
that
has
been
a
problem
because
there's
a
lot
of
patents
in
this
field,
there's
actually
a
growing
number
of
patents,
and
obviously
this
is
a
huge
impediment
for
people
to
go
beyond
the
research.
Obviously,
when
you
just
do
research,
it
costs
nothing,
but
when
you
start
wanting
to
do
technology
transfer
and
there's
a
huge
patent
environment,
everybody
is
a
little
bit
careful.
So
that
has
also
been
an
issue.
B
So
with
that
what
we
vasa-
and
I
we've
talked
a
lot
about
this-
there's
been
other
issues
in
again-
ipr
disclosure
around
the
work
that
we're
doing
that
we're
late
and
a
little
bit
hard
to
take.
So
what
we
suggest
is
to
adopt
the
remaining
ideas
that
are
mature
and
I
think
all
of
our
ideas
right
now
are
very
immature,
so
adopt
them
as
rg
item
publish
them
as
what
they
should
be,
which
is
informational
or
fc,
and
and
what
I
wanted
to
say
there
about
quick.
B
Is
you
know
if
we
have
an
informational
rfc
on
coding
for
quick?
We
would
hope
that
the
quick
group
would
use
that
as
a
basis
for
a
solution
that
could
be
part
of
quick,
and
it
has
always
been
part
of
the
of
them
of
the
road
map
for
quick,
so
that
if
we
have
this,
this
rf
informational,
it
could
be
a
basis
for
either
another
drafting,
quick
or
at
least
to
influence
the
solution,
and
we
will
close
the
group
in
about
a
year
from
now.
B
So
you
know
for
having
done
the
job
we
were
supposed
to
do.
So
this
is
a
suggestion.
This
is
not
obviously
this
final
decision
again
we
we
we
have
these
particular.
I
spoke
a
lot
about
about
the
fec
for
quick,
so
we
can't
really
wait
for
for
quick.
B
You
know
for
our
ideas,
so
what
I
think
I
can
put
my
my
my
other
hat
here
is
that
I
think
we
will
focus
on
the
major
aspects
that
we
don't
expect
to
change
in
quick
and
then
publish
this
id
as
again
like
I
said,
as
is
here
quick
guys,
it
sits
here.
It's
an
it's
a
it's
a
framework
for
your
solution
and,
of
course,
us
authors
are
ready
to
participate
in
making
this
happen
in
quick,
the
fec
at
loops.
I
spoke
to
karsten
a
lot
about
it.
B
Like
I
said
at
first,
they
were
very
open
and
putting
putting
some
coating
inside
loops
for
the
moment
they
they
put
it
a
little
bit
on
the
side.
I
have
the
impression
that
I
know
why,
but
I
will
not
put
words
in
people's
mouth,
but
it's
it's
on
the
side
for
now.
Maybe
it
will
come
back,
but
in
any
case
they
would
have
if
they
ever
decide
to
bring
it
back.
B
They
would
have
the
whole
raft
of
rfcs
that
we
would
have
on
on
the
requirements
for
the
congestion,
for
example,
this
this
interaction
that
they
will
have
to
to
deal
with
between
congestion
and
and
non-congestion
losses.
They
would
have
the
solution
for
tetris
they
would
have.
They
already
have
obviously
the
fec
frame
solution,
so
I
think
that
would
actually
be
a
good
way
to
start
with
loops.
So
I
I
don't
think
that
would
be
problematic
again.
This
is
a
suggestion.
B
This
is
not.
Is
there
another
slide
vessel.
B
This
is
the
okay.
So
again,
this
is
a
suggestion.
We've
discussed
this
with
some
people
before
throwing
this.
We
didn't
want
to
be,
but
I
think
again
that
we've,
I
think,
we've
done
a
lot
of
what
we
wanted
to
do.
I
think
for
people
who've
participated
in
this
since
the
beginning.
B
I
think
we've
had
a.
We
have
now
a
much
better
understanding
of
what
network
coding
can
do
in
a
network.
What
are
the
potential
solutions?
What
are
the
potential
tripping,
wires
and
and
yeah?
I
think
it's
time
to
decide
that.
Maybe
we
want
to
move
to
something
else
and
we
welcome
comments,
obviously
we're
going
to
put
that
on
the
list
eventually,
so
that
other
everybody
can
chime
in
and
the
authors
of
current
drafts
suppose
there's
a
few
on
I've.
B
Seen
a
few
on
the
on
the
the
list
on
that
the
meet
echo
be
prepared
to
to
work
on
your
drafts
to
make
them
ready
to
transition
to
informational
rfcs,
and
I
was
pleased
to
see
that
nicolas
said
he
had
a
little
bit
of
time.
B
We'll
we've
already
again
contacted
the
tetris
team,
so
they're
aware,
I
know
the
bats
team
are
are
very
eager
of
of
moving
forward
and
I
think
the
two,
the
two
others
are
also
very
much
ahead
into
approval.
So
I
think
we're
great
there
and
yeah.
Is
there
any
comments?
Is
there
any?
Yes?
No,
whatever
people,
okay,
spencer,.
E
F
I've
been
talking
to
the
proponents
like
in
the
last
48
hours
and
trying
to
make
sure
that
they
were
really
consistent
on
their
their
position
on
where
fec
was
in
their
proposal.
So
take
a
look
at
their
take
a
look
at
their
slides
that
were
just
uploaded
last
night.
I
guess
and
see
see
what
you
think,
but
I
hope
that
there
is
some
discussion
about
around
that
about
about
fec
with
loops
at
the
buff
on
friday.
Thank
you.
B
E
Yeah
hi,
so
I
think
both
the
the
loops
and
the
quick
documents
are
pretty
close
to
the
idf
work.
So
I
think
we
should
have
a
conversation
about
whether
they
get
published
as
informational
things
here
or
just
moved
into
the
itf
and
pushed
into
the
relevant
working
groups.
There.
E
B
Yeah
as
far
as
the
yeah,
the
congestion
control,
I
think,
is
not
strictly
for
loop,
so
I
think
it.
I
also
spoke
to
yana
by
the
way,
to
push
it
into
the
congestion
control.
I
think
that
could
be
a
standalone.
The
quick,
I
agree
is
closer
to
an
ietf
document
and
we
could
but
I've
I've
been
very
careful.
I've
talked
to
lars
about
it,
and
I've
been
very
careful
of
not
to
overwhelm
them
with
yet
another
document.
B
B
B
Okay,
yeah,
I
saw
there,
there
was
no
okay.
Well,
I
think
then
we're
fine.
I,
like
short
and
sweet
again,
I'm
sorry
to
have
been
late.
I
guess
it's
the
problem
of
being
remote.
I
will
have
now.
I
have
a
few
days
to
resolve
my
my
childhood
problems.
B
Thank
you,
everyone.
I
guess
we
will.
I
don't
know
if
we're
going
to
have
a
an
interim
before
now
in
november,
we'll
see
how
the
documents
evolve,
maybe
to
make
sure
that
they
evolve.
We
could
have
a
very
short
interim,
sometimes
if
not
we're
going
to
obviously
meet
in
november,
so
that
we
can
have
all
these
documents
being
you
know
advancing
to
where
we
would
like
them
to
be
and
yeah.
Thank
you
everyone.
Thank
you
very
soon.
B
Thank
you
nicola
for
the
presentation,
thank
you
for
the
people
who
ask
questions
and
thank
you
for
all
the
participants,
and
hopefully
everybody
is
safe
and
and
healthy.
Thank
you.