Subject: Re: [nwcrg] Sliding window draft and coding schemes (e.g. RLNC)

From: "Morten V. Pedersen" <[email-masked]>
Date: Sun, 3 May 2015 20:26:28 -0400

Hi everybody,
I've just finished reading RFC 6363, and I agree with Vincent's 
assessment that the general concepts and architecture looks okay. As 
Vincent points out in draft-roca-nwcrg-fecframev2-problem-position-00 it 
is mostly a question of removing the limitation of fixed size blocks.

Below are my comments to draft-roca-nwcrg-fecframev2-problem-position-00:

Section 1.

   However, it is REQUIRED in [RFC6363] that the FEC scheme operate in a
   block manner, i.e., the input flow(s) MUST be segmented into a
   sequence of blocks, and FEC encoding (at a sender/coding node) and
   decoding (at a receiver/decoding node MUST be performed
   independently on a per-block basis. This approach has a major impact
   on coding and decoding delays.

I don't think the fact that we operate in a block manner impacts the 
delay significantly. It is possible with most blocked RLNC codes to code 
only over the symbols currently available (and for the decoder to 
"detect" full rank of a sub-matrix). The crux of the problem is however 
captured in the next statement.

   Encoding requires that all the source symbols be known at the encoder.

This is the real problem causing delay. Mapping this back to RFC 6363 
(Section 4.1 p.12 top) I would say that the following statement :

   The FEC Framework then performs two operations. First, it appends
   the Source FEC Payload IDs, if provided, to each of the ADUs, and
   sends the resulting packets, known as "FEC source packets", to the
   receiver. Second, it places the provided FEC repair packet payloads
   and corresponding Repair FEC Payload IDs appropriately to to construct
   FEC repair packets and send them to the receiver.

Which specifically defines an order in which source and repair symbols 
should be sent should be softened. Such that we are allowed to 
dynamically generate repair according to some rate defined in the CDP.

Section 2.2

   A Code Rate close to 1 indicates that a small number of Output
   Symbols have been produced during the encoding process.

I think Output Symbols should be replaced with Repair Symbols to match 
the definitions?

Section 4.2

   The question of having multiple in-network re-coding operations
   is not considered in [RFC6363]. The question whether this is feasible
   and appropriate, given the typical FECFRAME use-cases, is an open
   question that remains to be discussed.

I think it worth including, but maybe not in this first iteration. 
If/when we decide to do it. I think most of the logic for this could 
reside in the CDP. The additional functionality needed by the FEC scheme 
would (I think) be minimal. Also the FEC payload ID for encoded and 
recoded packets would probably be the same for most FEC schemes.

Section 4.5

   The question of having FECFRAME used in lower protocol layers is not
   considered in [RFC6363]. Whether this is feasible and appropriate,
   given the typical FECFRAME use-cases, is an open question that
   remains to be discussed.

It is a good question. I would probably just say that it is a bridge we 
will cross should it ever become relevant. I would probably not try to 
include anything on that into the document.

Section 5.1

In the description of the interaction between the FEC Framework v2 and 
the FEC Scheme. I think it would be nice to describe it in terms of a 
"pull model" where the FEC Framework v2 or the CDP "pulls" repair 
symbols from the FEC Scheme at a suitable rate (defined by the CDP). The 
way it is formulated now it is not clear whether it is the FEC Scheme 
that defines how many repair symbols are created or the FEC Framework v2 
/ CDP. But I think that is also unclear in RFC6363, perhaps it is just me ;)

Section 5.2

   with FECFRAMEv2 in window mode, can be dynamic and chosen on a
   per-window basis. In that case the length of repair symbols will
   dynamically evolve as well in order to be equal to the maximum
   ADUI size in the encoding window at the time of encoding.

I would say we can even "loosen" this a bit more and way that the length 
will be "equal to the maximum ADUI size included in a repair symbol". So 
even though we have a very long symbol in the window, if it isn't 
included in a specific encoding it will not impact the length of that 
repair symbol. This will not have much impact on high field codes - but 
for binary/sparse codes it may.

For Figure 2 the definition of the F and L fields should be given. I did 
not find it - but perhaps I missed it.

Section 5.3

   at the FECFRAME instance level

Should be "at the FECFRAMEv2 instance level"

   if the sender knows that a particular ADU has been correctly
   received by the receiver(s), the corresponding source symbol(s)
   is(are) removed. Of course this mechanism requires that an
   acknowledgement mechanism be setup to inform the FECFRAMEv2 sender
   of good ADU reception, which is out of the scope of FECFRAMEv2.
   Whether or not this is desirable is an open question;

I think we should consider including it. One way of doing it is to let 
the FEC Scheme decoder (receiver) be queried, whether it has feedback 
for the encoder (sender) or not. If it has feedback to send and the CDP 
has a method of getting that feedback to the sender then it can take 
advantage of it. However, no FEC scheme should rely on the feedback e.g. 
to move the window, but simply utilize it for performance reasons. I 
think this is also in-line with what is already in RFC 6363 Section 6. 
However, we many want to explicitly generate some working around that 
and define a container for it FEC Feedback Information.

Section 5.4

I don't this the symbol identifiers should be specified by the 
FECFRAMEv2, but rather left up the specific FEC Scheme. I might have 
missed something here but to me the symbol identifiers specified by RFC 
6363 see adequate for our purpose here as well.

That was it, let me know your thoughts.

Best regards,
Morten

On 04/12/2015 10:35 AM, Vincent Roca wrote:
> Hello Brian and everybody,
>
> In order to move forward and enrich the end-to-end transport use-case 
> discussions, I have
> worked on an update to FECFRAME in order to support the sliding window 
> approach (see
> my other email). The general architecture and concepts seem okay to me 
> at first glance.
>
> Here also the next step is now to specify a first convolutional FEC 
> Scheme… This I-D will be,
> for some parts, FECFRAME specific, but the rest will be common with 
> other NC proposals.
>
> And we need a public repository to work collaboratively on this and 
> other documents
> (e.g., taxonomy)…
>
> Cheers,
>
>   Vincent
>
>
>> Le 6 avr. 2015 à 18:44, Brian Adamson <[email-masked] 
>> <mailto:[email-masked]>> a écrit :
>>
>> As a result of some discussion with Marie, I thought it would be a 
>> good idea to share a few of my thoughts on some of the near term 
>> activities we seem to have identified and making some progress on. 
>>  One of the nearer-term “products” of our NWCRG discussion is the 
>> end-to-end transport use case with the developing sliding window 
>> approach being documented in Jonathan, et al’s draft.
>>
>> To support that work, it could be good to consider trying to document 
>> an accompanying “FEC Scheme or two (e.g. RLNC, etc) that could be 
>> applied with the sliding window protocol.  That may help us get the 
>> framework right.  It would perhaps even be an interesting thought 
>> exercise to see if something like RLNC could documented in the form 
>> of an RMT or FecFrame “FEC Scheme”?.  One thing to note here is the 
>> the main value proposition for _unicast_ end to end use of coding 
>> lies somewhat with the delay improvements and that the sliding window 
>> type approach helps maximize the gains here as compared to the 
>> transport efficiencies coding yields for multicast (it also gets some 
>> delay benefits too under certain use cases).  While some of the 
>> formats / semantics of RMT/FecFrame may be reused, they may be too 
>> "block code oriented” as they are currently specified?
>>
>> So I think we are sort of on a good course to get some consensus for 
>> defining a sliding window framework that one could then “plug in” 
>> RLNC and some of the other coding algorithms discussed (all the IPR 
>> issues notwithstanding).  It may be necessary to have the sliding 
>> window document to provide a reference for how to specify RLNC.  We 
>> did that in RMT where we wrote the “FEC Building Block” document that 
>> established some core packet formats (and IANA registries) so we 
>> could go on to document specific FEC coding algorithms (we called 
>> them FEC Schemes) including non-proprietary stuff like Reed Solomon, 
>> LDPC as well as the proprietary Raptor codes, etc.
>>
>> I haven’t been too explicitly vocal on this aspect because it seemed 
>> we were getting some progress on this with Jonathan’s draft and more 
>> recently Morten’s constructive comments on that.  This may be one of 
>> the pieces that can transition more early to IETF working group 
>> activities for end-to-end transport purposes while we continue in 
>> NWCRG to work on the more “researchy” items. I think having this 
>> initiated in NWCRG is OK since we’ve assembled a set of people that 
>> may be able to work the problem?  And if we establish a basis of 
>> components (e.g. packet formats, coding scheme definitions) from this 
>> that may also be useful for other applications of network coding 
>> (i.e. more “in network” things like your DNC concept, ideas like 
>> Cedric described, SDN applications of coding, etc), then it is also 
>> beneficial to ongoing NWCRG work, too.  Then, when it’s sufficiently 
>> mature it might find a (transport area) working group home for the 
>> longer term?
>>
>> Again I personally haven’t explicitly articulated this like I’ve done 
>> here since we seemed (to me) to be sort of proceeding (perhaps 
>> lurching) along this path anyway, but (with Marie’s help) have 
>> realized these might thoughts worth sharing.
>>
>> best regards,
>>
>> Brian
>> _______________________________________________
>> nwcrg mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.irtf.org/mailman/listinfo/nwcrg
>
>
>
> _______________________________________________
> nwcrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nwcrg

---

From: Muriel Medard <[email-masked]>
Date: Mon, 4 May 2015 01:58:28 +0000

Dear all,

Thank you. I think it is important that coding not be restricted to blocks, which can be highly limiting and incompatible with sliding windows. Recoding is crucial. Otherwise,  it is just a code, like RS or Fountain,  not a network code.

Best, Muriel.

Sent from my Verizon Wireless 4G LTE smartphone

-------- Original message --------
From: "Morten V. Pedersen" <[email-masked]>
Date: 05/03/2015 20:28 (GMT-05:00)
To: [email-masked]
Subject: Re: [nwcrg] Sliding window draft and coding schemes (e.g. RLNC)

Hi everybody,
I've just finished reading RFC 6363, and I agree with Vincent's assessment that the general concepts and architecture looks okay. As Vincent points out in draft-roca-nwcrg-fecframev2-problem-position-00 it is mostly a question of removing the limitation of fixed size blocks.

Section 1.

I don't think the fact that we operate in a block manner impacts the delay significantly. It is possible with most blocked RLNC codes to code only over the symbols currently available (and for the decoder to "detect" full rank of a sub-matrix). The crux of the problem is however captured in the next statement.

This is the real problem causing delay. Mapping this back to RFC 6363 (Section 4.1 p.12 top) I would say that the following statement :

Which specifically defines an order in which source and repair symbols should be sent should be softened. Such that we are allowed to dynamically generate repair according to some rate defined in the CDP.

Section 2.2

I think Output Symbols should be replaced with Repair Symbols to match the definitions?

Section 4.2

I think it worth including, but maybe not in this first iteration. If/when we decide to do it. I think most of the logic for this could reside in the CDP. The additional functionality needed by the FEC scheme would (I think) be minimal. Also the FEC payload ID for encoded and recoded packets would probably be the same for most FEC schemes.

Section 4.5

It is a good question. I would probably just say that it is a bridge we will cross should it ever become relevant. I would probably not try to include anything on that into the document.

Section 5.1

In the description of the interaction between the FEC Framework v2 and the FEC Scheme. I think it would be nice to describe it in terms of a "pull model" where the FEC Framework v2 or the CDP "pulls" repair symbols from the FEC Scheme at a suitable rate (defined by the CDP). The way it is formulated now it is not clear whether it is the FEC Scheme that defines how many repair symbols are created or the FEC Framework v2 / CDP. But I think that is also unclear in RFC6363, perhaps it is just me ;)

Section 5.2

I would say we can even "loosen" this a bit more and way that the length will be "equal to the maximum ADUI size included in a repair symbol". So even though we have a very long symbol in the window, if it isn't included in a specific encoding it will not impact the length of that repair symbol. This will not have much impact on high field codes - but for binary/sparse codes it may.

For Figure 2 the definition of the F and L fields should be given. I did not find it - but perhaps I missed it.

Section 5.3

I think we should consider including it. One way of doing it is to let the FEC Scheme decoder (receiver) be queried, whether it has feedback for the encoder (sender) or not. If it has feedback to send and the CDP has a method of getting that feedback to the sender then it can take advantage of it. However, no FEC scheme should rely on the feedback e.g. to move the window, but simply utilize it for performance reasons. I think this is also in-line with what is already in RFC 6363 Section 6. However, we many want to explicitly generate some working around that and define a container for it FEC Feedback Information.

Section 5.4

I don't this the symbol identifiers should be specified by the FECFRAMEv2, but rather left up the specific FEC Scheme. I might have missed something here but to me the symbol identifiers specified by RFC 6363 see adequate for our purpose here as well.

Best regards,
Morten

In order to move forward and enrich the end-to-end transport use-case discussions, I have
worked on an update to FECFRAME in order to support the sliding window approach (see
my other email). The general architecture and concepts seem okay to me at first glance.

Here also the next step is now to specify a first convolutional FEC Scheme… This I-D will be,
for some parts, FECFRAME specific, but the rest will be common with other NC proposals.

And we need a public repository to work collaboratively on this and other documents
(e.g., taxonomy)…

Cheers,

  Vincent

Le 6 avr. 2015 à 18:44, Brian Adamson <[email-masked]<mailto:[email-masked]>> a écrit :

As a result of some discussion with Marie, I thought it would be a good idea to share a few of my thoughts on some of the near term activities we seem to have identified and making some progress on.  One of the nearer-term “products” of our NWCRG discussion is the end-to-end transport use case with the developing sliding window approach being documented in Jonathan, et al’s draft.

To support that work, it could be good to consider trying to document an accompanying “FEC Scheme or two (e.g. RLNC, etc) that could be applied with the sliding window protocol.  That may help us get the framework right.  It would perhaps even be an interesting thought exercise to see if something like RLNC could documented in the form of an RMT or FecFrame “FEC Scheme”?.  One thing to note here is the the main value proposition for unicast end to end use of coding lies somewhat with the delay improvements and that the sliding window type approach helps maximize the gains here as compared to the transport efficiencies coding yields for multicast (it also gets some delay benefits too under certain use cases).  While some of the formats / semantics of RMT/FecFrame may be reused, they may be too "block code oriented” as they are currently specified?

So I think we are sort of on a good course to get some consensus for defining a sliding window framework that one could then “plug in” RLNC and some of the other coding algorithms discussed (all the IPR issues notwithstanding).  It may be necessary to have the sliding window document to provide a reference for how to specify RLNC.  We did that in RMT where we wrote the “FEC Building Block” document that established some core packet formats (and IANA registries) so we could go on to document specific FEC coding algorithms (we called them FEC Schemes) including non-proprietary stuff like Reed Solomon, LDPC as well as the proprietary Raptor codes, etc.

I haven’t been too explicitly vocal on this aspect because it seemed we were getting some progress on this with Jonathan’s draft and more recently Morten’s constructive comments on that.  This may be one of the pieces that can transition more early to IETF working group activities for end-to-end transport purposes while we continue in NWCRG to work on the more “researchy” items. I think having this initiated in NWCRG is OK since we’ve assembled a set of people that may be able to work the problem?  And if we establish a basis of components (e.g. packet formats, coding scheme definitions) from this that may also be useful for other applications of network coding (i.e. more “in network” things like your DNC concept, ideas like Cedric described, SDN applications of coding, etc), then it is also beneficial to ongoing NWCRG work, too.  Then, when it’s sufficiently mature it might find a (transport area) working group home for the longer term?

Again I personally haven’t explicitly articulated this like I’ve done here since we seemed (to me) to be sort of proceeding (perhaps lurching) along this path anyway, but (with Marie’s help) have realized these might thoughts worth sharing.

best regards,

Brian
_______________________________________________
nwcrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/nwcrg

_______________________________________________
nwcrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/nwcrg

---

From: jonathan detchart <[email-masked]>
Date: Mon, 4 May 2015 15:29:25 +0200

Morten,
I re-read your email. We fully agree on the use of windows since this is what Tetrys has been doing from the start. 

Muriel,
On the re-encoding :
while this should be a valued feature we all know of many use cases where re-encoding is not feasible or practical.

So our modified FECFRAME (NCFRAME ?) should be use-case driven to allow maximum flexibility and even in some cases the use of network codes as simple (AL-)FEC (block codes, or not).

Jonathan DETCHART
> On 04 May 2015, at 03:58, Muriel Medard <[email-masked]> wrote:
> 
> 
> Dear all,
> 
>>> Le 6 avr. 2015 à 18:44, Brian Adamson <[email-masked] <mailto:[email-masked]>> a écrit :
>>> 
>>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
>> 
>> 
>> 
>> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>
>

---

From: Vincent Roca <[email-masked]>
Date: Mon, 4 May 2015 17:06:38 +0200

Hello Morten,

Excellent comments.

> I've just finished reading RFC 6363, and I agree with Vincent's assessment that the general concepts and architecture looks okay. As Vincent points out in draft-roca-nwcrg-fecframev2-problem-positi…

Exactly. And doing that while keeping backward compatibility since Fecframe is already included in several standards.
BTW, this backward compatibility requirement also justifies that we keep (for this particular document/activity) the
terminology in use in RFC6363, which may differ a little bit from that of NWCRG.

> I don't think the fact that we operate in a block manner impacts the delay significantly. It is possible with most blocked RLNC codes to code only over the symbols currently available (and for the decoder to « detect" full rank of a sub-matrix).

VR: Yes, you’re right, but I’m not considering blocked RLNC codes here, but the block codes that have been
defined for FECFRAME.

> The crux of the problem is however captured in the next statement.
> 
> This is the real problem causing delay.

VR: Of course. So I’ve rephrased it as follows to better highlight it.

NEW:
	This approach has a major impact on coding and decoding delays when used with
	block FEC codes (e.g., [RFC6681], [RFC6816] or [RFC6865]) since encoding
	requires that all the source symbols be known at the encoder.

> Mapping this back to RFC 6363 (Section 4.1 p.12 top) I would say that the following statement :
> 

VR: Exactly. That’s the kind of over-specification that should remain illustrative rather than
being written as if it was a mandatory feature. We’ll have to soften the wording, fully agree.

> I think Output Symbols should be replaced with Repair Symbols to match the definitions?

VR: This is a mistake, indeed. Fixed.

> I think it worth including, but maybe not in this first iteration. If/when we decide to do it. I think most of the logic for this could reside in the CDP. The additional functionality needed by the…

VR: It also depends on the FEC scheme being considered. But yes, let’s the question
open for the moment as it depends on the target use-cases as well as on IPR considerations
(e.g., do we want to use RLC with in-network recoding?)

> It is a good question. I would probably just say that it is a bridge we will cross should it ever become relevant. I would probably not try to include anything on that into the document.

VR: This is also my opinion. FECFRAMEv2 should remain close to FECFRAME, i.e., be a
shim layer above UDP (or similar). I just didn’t want to close the door at this stage.

> In the description of the interaction between the FEC Framework v2 and the FEC Scheme. I think it would be nice to describe it in terms of a "pull model" where the FEC Framework v2 or the CDP "pull…

VR: The chief (i.e., FEC Framework v2) decides how many repairs are needed, and when.
I kept this figure and text close to the original one that was clearly in « push mode », but
I agree this is not necessarily the best approach. I have changed the wording as follows:

OLD:
   If needed, one or several repair symbols are created by the FEC Scheme (step 5), and
   communicated to FECFRAME along with their Repair FEC Payload ID (step 6).

NEW:
   When FECFRAMEv2 needs to send one or several FEC repair packets, it asks
   the FEC Scheme to create one or several repair symbols (step 5) along
   with their Repair FEC Payload ID (step 6).

> I would say we can even "loosen" this a bit more and way that the length will be "equal to the maximum ADUI size included in a repair symbol". So even though we have a very long symbol in the windo…

VR: Good point, it should work.

> For Figure 2 the definition of the F and L fields should be given. I did not find it - but perhaps I missed it.

VR: I forgot, you’re right. Added to the beginning of the paragraph:

NEW:
As in FECFRAME, each ADU is first prepended with its {flow ID, length} information
(respectively the F and L fields of Figure 2), and potentially zero padded to align with
the target symbol length (see below) (Pad field of Figure 2).

In the future FECFRAMEv2 specifications, there will be a clean paragraph for the various
fields.

> Should be « at the FECFRAMEv2 instance level"

VR: Fixed. There is a similar mention to FECFRAME Instance in section 5.4 that I also fixed.

> I think we should consider including it. One way of doing it is to let the FEC Scheme decoder (receiver) be queried, whether it has feedback for the encoder (sender) or not. If it has feedback to s…

VR: I fully agree that adding this feedback mechanism is feasible and can reduce processing
as in Tetrys or similar. However the point is whether we should add it since it was specifically
considered out of scope of FECFRAME, both RFC6363 and the associated WG charter.
I prefer to let it as an optional external component, specified separately. It’s true that it was
not that important for FECFRAME in block mode with block FEC codes, it will be more useful
with FECFRAMEv2 in sliding mode.

> I don't this the symbol identifiers should be specified by the FECFRAMEv2, but rather left up the specific FEC Scheme. I might have missed something here but to me the symbol identifiers specified…

VR: I tried to clarify why it is important to consider this aspect in the i-d, and why the situation
is different from RFC6363. Maybe I was not clear enough.
Concerning the FECFRAMEv2 level versus FEC scheme level, yes, I agree that most of the
technical details will be in the FEC scheme, but this document is a « problem position » i-d
that tries to identify and discuss (all?) aspects to consider. So it’s important to have this discussion
here.

> That was it, let me know your thoughts.

Thank you so much!
Cheers,

  Vincent

---

From: Muriel Medard <[email-masked]>
Date: Mon, 4 May 2015 23:22:44 +0000

Dear all,

re-encoding is only infeasible, I believe, if non network (end-to-end) codes are used. The scaling gains of NC do not hold without re-encoding, so I think it is critical. I shall look forward to talking about it at the tutorial.

Best,

Muriel.

On May 4, 2015, at 9:29 AM, jonathan detchart <[email-masked]<mailto:[email-masked]>> wrote:

Morten,

Muriel,
On the re-encoding :

Jonathan DETCHART
On 04 May 2015, at 03:58, Muriel Medard <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Best, Muriel.

-------- Original message --------
From: "Morten V. Pedersen" <[email-masked]<mailto:[email-masked]>>
Date: 05/03/2015 20:28 (GMT-05:00)
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [nwcrg] Sliding window draft and coding schemes (e.g. RLNC)

Hi everybody,

Section 1.

Section 2.2

Section 4.2

Section 4.5

Section 5.1

Section 5.2

Section 5.3

Section 5.4

Best regards,
Morten

Cheers,

  Vincent

best regards,

Brian

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Mon, 4 May 2015 23:13:16 -0400

Hi Jonathan,
I'm a bit puzzled by your statement "many use cases where re-encoding is 
not feasible or practical". Do you have any specific scenarios in mind?

- M

On 05/04/2015 09:29 AM, jonathan detchart wrote:
> Morten,
> I re-read your email. We fully agree on the use of windows since this 
> is what Tetrys has been doing from the start.
>
> Muriel,
> On the re-encoding :
> while this should be a valued feature we all know of many use cases 
> where re-encoding is not feasible or practical.
>
> So our modified FECFRAME (NCFRAME ?) should be use-case driven to 
> allow maximum flexibility and even in some cases the use of network 
> codes as simple (AL-)FEC (block codes, or not).
>
> Jonathan DETCHART
>> Thank you. I think it is important that coding not be restricted to 
>> blocks, which can be highly limiting and incompatible with sliding 
>> windows. Recoding is crucial. Otherwise,  it is just a code, like RS 
>> or Fountain,  not a network code.
>>
>> Best, Muriel.
>>
>>
>> From: "Morten V. Pedersen" <[email-masked] <mailto:[email-masked]>>
>> To: [email-masked] <mailto:[email-masked]>
>> Vincent points out in draft-roca-nwcrg-fecframev2-problem-position-00 
>> it is mostly a question of removing the limitation of fixed size blocks.
>>
>> delay significantly. It is possible with most blocked RLNC codes to 
>> code only over the symbols currently available (and for the decoder 
>> to "detect" full rank of a sub-matrix). The crux of the problem is 
>> however captured in the next statement.
>>
>> Which specifically defines an order in which source and repair 
>> symbols should be sent should be softened. Such that we are allowed 
>> to dynamically generate repair according to some rate defined in the CDP.
>>
>> Section 2.2
>>
>> reside in the CDP. The additional functionality needed by the FEC 
>> scheme would (I think) be minimal. Also the FEC payload ID for 
>> encoded and recoded packets would probably be the same for most FEC 
>> schemes.
>>
>> Section 4.5
>>
>> It is a good question. I would probably just say that it is a bridge 
>> we will cross should it ever become relevant. I would probably not 
>> try to include anything on that into the document.
>>
>> Section 5.1
>>
>> In the description of the interaction between the FEC Framework v2 
>> and the FEC Scheme. I think it would be nice to describe it in terms 
>> of a "pull model" where the FEC Framework v2 or the CDP "pulls" 
>> repair symbols from the FEC Scheme at a suitable rate (defined by the 
>> CDP). The way it is formulated now it is not clear whether it is the 
>> FEC Scheme that defines how many repair symbols are created or the 
>> FEC Framework v2 / CDP. But I think that is also unclear in RFC6363, 
>> perhaps it is just me ;)
>>
>> Section 5.2
>>
>> I would say we can even "loosen" this a bit more and way that the 
>> length will be "equal to the maximum ADUI size included in a repair 
>> symbol". So even though we have a very long symbol in the window, if 
>> it isn't included in a specific encoding it will not impact the 
>> length of that repair symbol. This will not have much impact on high 
>> field codes - but for binary/sparse codes it may.
>>
>> For Figure 2 the definition of the F and L fields should be given. I 
>> did not find it - but perhaps I missed it.
>>
>>
>> Section 5.3
>>
>> I think we should consider including it. One way of doing it is to 
>> let the FEC Scheme decoder (receiver) be queried, whether it has 
>> feedback for the encoder (sender) or not. If it has feedback to send 
>> and the CDP has a method of getting that feedback to the sender then 
>> it can take advantage of it. However, no FEC scheme should rely on 
>> the feedback e.g. to move the window, but simply utilize it for 
>> performance reasons. I think this is also in-line with what is 
>> already in RFC 6363 Section 6. However, we many want to explicitly 
>> generate some working around that and define a container for it FEC 
>> Feedback Information.
>>
>> Section 5.4
>>
>> missed something here but to me the symbol identifiers specified by 
>> RFC 6363 see adequate for our purpose here as well.
>>
>>>> To support that work, it could be good to consider trying to 
>>>> document an accompanying “FEC Scheme or two (e.g. RLNC, etc) that 
>>>> could be applied with the sliding window protocol.  That may help 
>>>> us get the framework right.  It would perhaps even be an 
>>>> interesting thought exercise to see if something like RLNC could 
>>>> documented in the form of an RMT or FecFrame “FEC Scheme”?.  One 
>>>> thing to note here is the the main value proposition for _unicast_ 
>>>> end to end use of coding lies somewhat with the delay improvements 
>>>> and that the sliding window type approach helps maximize the gains 
>>>> here as compared to the transport efficiencies coding yields for 
>>>> multicast (it also gets some delay benefits too under certain use 
>>>> cases).  While some of the formats / semantics of RMT/FecFrame may 
>>>> be reused, they may be too "block code oriented” as they are 
>>>> currently specified?
>>>>
>>>> So I think we are sort of on a good course to get some consensus 
>>>> for defining a sliding window framework that one could then “plug 
>>>> in” RLNC and some of the other coding algorithms discussed (all the 
>>>> IPR issues notwithstanding).  It may be necessary to have the 
>>>> sliding window document to provide a reference for how to specify 
>>>> RLNC.  We did that in RMT where we wrote the “FEC Building Block” 
>>>> document that established some core packet formats (and IANA 
>>>> registries) so we could go on to document specific FEC coding 
>>>> algorithms (we called them FEC Schemes) including non-proprietary 
>>>> stuff like Reed Solomon, LDPC as well as the proprietary Raptor 
>>>> codes, etc.
>>>>
>>>> I haven’t been too explicitly vocal on this aspect because it 
>>>> seemed we were getting some progress on this with Jonathan’s draft 
>>>> and more recently Morten’s constructive comments on that.  This may 
>>>> be one of the pieces that can transition more early to IETF working 
>>>> group activities for end-to-end transport purposes while we 
>>>> continue in NWCRG to work on the more “researchy” items. I think 
>>>> having this initiated in NWCRG is OK since we’ve assembled a set of 
>>>> people that may be able to work the problem?  And if we establish a 
>>>> basis of components (e.g. packet formats, coding scheme 
>>>> definitions) from this that may also be useful for other 
>>>> applications of network coding (i.e. more “in network” things like 
>>>> your DNC concept, ideas like Cedric described, SDN applications of 
>>>> coding, etc), then it is also beneficial to ongoing NWCRG work, 
>>>> too.  Then, when it’s sufficiently mature it might find a 
>>>> (transport area) working group home for the longer term?
>>>>
>>>> Again I personally haven’t explicitly articulated this like I’ve 
>>>> done here since we seemed (to me) to be sort of proceeding (perhaps

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Tue, 5 May 2015 00:25:05 -0400

Hi Vincent,

See inline:

> terminology in use in RFC6363, which may differ a little bit from that of NWCRG.

MVP: Yes, I agree with that.

> 	requires that all the source symbols be known at the encoder.

MVP: I like it.

> (e.g., do we want to use RLC with in-network recoding?)

MVP: Yes, I we really need to get started on specifying the building 
blocks and their interfaces. Recoding could then be specified as an 
optional sub-block withing the sliding window FEC Scheme. Or something 
along those lines.

> shim layer above UDP (or similar). I just didn’t want to close the door at this stage.
MVP: Makes sense.

>     with their Repair FEC Payload ID (step 6).

MVP: Excellent. Only thing I would consider adding there is support for 
both rate-less and rate-limited schemes. E.g. something like:

   When FECFRAMEv2 needs to send one or several FEC repair packets (step 
5), it
   follows one of the following two approaches. 1) In case the FEC 
Scheme is rate-
   limited it asks the FEC Scheme to create between 
{1,...,available_fec_repair}
   repair symbols. 2) In case the FEC Scheme is rate-less the amount of 
repair
   symbols is unrestricted. In both cases the FEC Scheme returns the repair
   symbols with their Repair FEC Payload ID (step 6). In case

This would strengthen the backward compatibility with existing block 
codes. This would of course have two implications on the text we need to 
define rate-limited and rate-less FEC Schemes and how a CDP may know 
whether a scheme is one or the other. Also I'm not so happy with the 
unrestricted word there, it seems a bit too fluffy. Any thoughts?

The "available_fec_repair" number would also have to be defined. I chose 
that name to indicate that it is not a fixed number. I.e. it MAY 
decrease as repair symbols are pulled. But potentially also increase as 
source symbols are added to the FEC Scheme (could be the case for some 
sliding window codes).

> In the future FECFRAMEv2 specifications, there will be a clean paragraph for the various

MVP: Looking at this section again - I actually did not fully get what 
Figure 2 shows. Is it an "internal" format i.e. how the ADUI fed to to 
the FEC Scheme?

> with FECFRAMEv2 in sliding mode.

MVP: Ok, I think that makes sense. I think that feedback type/format 
will be specific to the individual FEC Schemes, so I guess it would be 
OK to leave it out of FECFRAMEv2. I don't see a specific must have 
reason to specify it here. I guess the only reason would be if somebody 
proposes a FEC Scheme that cannot work without any feedback (but that 
would probably not be within the scope of FECFRAME).

> that tries to identify and discuss (all?) aspects to consider. So it’s important to have this discussion

MVP: Ok, I think I get it ;) So the reason you specify it here is that 
some FEC Schemes may require this information to be available? But I 
think this is already covered in FECFRAME with the  Explicit Source FEC 
Payload ID field.

  RFC 6363 Section 4.1 p. 11

   The FEC source packets MUST contain information that identifies the
   source block and the position within the source block (in terms
   specific to the FEC scheme) occupied by the ADU.  This information is
   known as the Source FEC Payload ID.  The FEC scheme is responsible
   for defining and interpreting this information.  This information MAY
   be encoded into a specific field within the FEC source packet format
   defined in this specification, called the Explicit Source FEC Payload
   ID field.  The exact contents and format of the Explicit Source FEC
   Payload ID field are defined by the FEC schemes.

So if we change the wording a bit to e.g.

   The FEC source packets MUST contain information that identifies the
   source block and the position within the source block, flow or coding
   window (in terms specific to the FEC scheme) occupied by the ADU.

Then we basically say that the FEC Scheme fully controls the ID. Would 
that work?

All the best,
Morten

---

From: Vincent Roca <[email-masked]>
Date: Tue, 5 May 2015 11:21:12 +0200

Hi Morten,

I’ve removed all parts where we agree (i.e., most of it :-)

> MVP: Yes, I we really need to get started on specifying the building blocks and their interfaces. Recoding could then be specified as an optional sub-block withing the sliding window FEC Scheme. Or something along those lines.

VR: just to clarify… None of the use-cases that were considered in the FECFRAME WG needed re-coding.
FECFRAMEv2 can be thought as being a « small » update to FECFRAME, keeping the same target use-cases.

The next step: what are the practical consequences of extending the use-cases to ones that perform re-coding?
Can it be done transparently to FECFRAMEv2, by hiding all the details within the FEC Scheme? I’m not sure of
the answer at this point. Also, is there a real benefit of doing that within FECFRAMEv2 rather than in Tetrys or
another TBD NC transport?

> MVP: Excellent. Only thing I would consider adding there is support for both rate-less and rate-limited schemes. E.g. something like:
> 
>   When FECFRAMEv2 needs to send one or several FEC repair packets (step 5), it
>   follows one of the following two approaches. 1) In case the FEC Scheme is rate-
>   limited it asks the FEC Scheme to create between {1,...,available_fec_repair}
>   repair symbols. 2) In case the FEC Scheme is rate-less the amount of repair
> This would strengthen the backward compatibility with existing block codes. This would of course have two implications on the text we need to define rate-limited and rate-less FEC Schemes and how a CDP may know whether a scheme is one or the other. Also I'm not so happy with the unrestricted word there, it seems a bit too fluffy. Any thoughts?
> 
> The "available_fec_repair" number would also have to be defined. I chose that name to indicate that it is not a fixed number. I.e. it MAY decrease as repair symbols are pulled. But potentially also increase as source symbols are added to the FEC Scheme (could be the case for some sliding window codes).

VR: I don’t like the idea of adding a rate-less versus rate-limited discussion here, especially as the
idea of « unrestricted number of repair symbols » should not be understood strictly as you said.
However I may add a sentence like the following one:

NEW:
	When FECFRAMEv2 needs to send… (step 6).
	Note that depending on the FEC scheme, the number repair symbols may be limited at a certain point of time.

> MVP: Looking at this section again - I actually did not fully get what Figure 2 shows. Is it an "internal" format i.e. how the ADUI fed to to the FEC Scheme?

VR: yes, this is internal. It is an example of mapping between a set of ADUIs and the corresponding set of source symbols
that are fed to the FEC scheme. Other mappings are possible. For instance you can have a look at RFC 6681,
"5.  General Procedures for Raptor FEC Schemes ». But it’s pretty hard to understand… (like other Raptor(Q) documents).

> MVP: Ok, I think that makes sense. I think that feedback type/format will be specific to the individual FEC Schemes, so I guess it would be OK to leave it out of FECFRAMEv2. I don't see a specific must have reason to specify it here. I guess the only reason would be if somebody proposes a FEC Scheme that cannot work without any feedback (but that would probably not be within the scope of FECFRAME).

VR: Exactly. FECFRAME was specified with broadcast networks in mind, without any feedback channel,
or for situations where the number of receivers prevents the use of feedbacks for scalability reasons.

> MVP: Ok, I think I get it ;) So the reason you specify it here is that some FEC Schemes may require this information to be available? But I think this is already covered in FECFRAME with the  Explicit Source FEC Payload ID field.
> 
> Then we basically say that the FEC Scheme fully controls the ID. Would that work?

VR: Yes, you’re right that Section 4.1 of RFC 6363 needs to be updated. That will be
done in the future FECFRAMEv2 specifications.

However the goal of section 5.4.  « About symbol identifiers » is to highlight the fact
that the concept of ESI (encoding symbol ID) of RFC 5052 is not applicable any more.
Adding a source/repair flag may be needed with some convolutional FEC schemes,
but not necessarily all of them (this is what the section says).

May be I could add a 5.4.1 sub-section to better highlight that what is explained hereafter
is just an example that is by no means universal, and that the FEC scheme will have
to specify the details. I’ll do that along with a rewording of the section to avoir confusion.

Thanks a lot.
Regards,

  Vincent

---

From: jonathan detchart <[email-masked]>
Date: Tue, 5 May 2015 17:10:47 +0200

Hi Morten,

For example, if you don’t control the intermediate nodes, or if you have a single hop, re-encoding is not feasible or practical.

Some use cases : 
- a coded tunnel (as we introduced at IETF86)
- a transmission over the internet (assume you don’t control the route and the intermediate nodes)

Jonathan DETCHART
> On 05 May 2015, at 05:13, Morten V. Pedersen <[email-masked]> wrote:
> 
> Hi Jonathan,
> I'm a bit puzzled by your statement "many use cases where re-encoding is not feasible or practical". Do you have any specific scenarios in mind? 
> 
> - M
> 
> 
>>> On 04 May 2015, at 03:58, Muriel Medard <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> Dear all,
>>>

---

From: Vincent Roca <[email-masked]>
Date: Tue, 5 May 2015 18:52:25 +0200

Hello Morten,

I would add to the list of use-cases broadcast networks where you have no backward channel or don’t want to use it
(i.e. don’t want to have feedbacks) in order to remain as scalable as possible.

I don’t think we have problems finding use-cases where re-coding is not desirable/feasible. That’s probably a « degenerated »
version of NC, but I think we’re still in the scope of the NWCRG and in-line with Brian’s initial message.

Cheers,

  Vincent

> Le 5 mai 2015 à 17:10, jonathan detchart <[email-masked]> a écrit :
> 
> Hi Morten,
> 
>> On 05 May 2015, at 05:13, Morten V. Pedersen <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Jonathan,

---

From: Muriel Medard <[email-masked]>
Date: Tue, 5 May 2015 19:10:46 +0000

Dear all,

if you have no access to the network, the network part of network coding will be hard:). We can only code where we can.

Best,

Muriel.

-------- Original message --------
From: jonathan detchart <[email-masked]>
Date: 05/05/2015 11:10 (GMT-05:00)
To: "Morten V. Pedersen" <[email-masked]>
Cc: Muriel Medard <[email-masked]>, [email-masked]
Subject: Re: [nwcrg] Sliding window draft and coding schemes (e.g. RLNC)

Hi Morten,

Some use cases :

Jonathan DETCHART
On 05 May 2015, at 05:13, Morten V. Pedersen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jonathan,

- M

Muriel,
On the re-encoding :

Jonathan DETCHART

Dear all,

Best, Muriel.

-------- Original message --------
From: "Morten V. Pedersen" <[email-masked]<mailto:[email-masked]>>
Date: 05/03/2015 20:28 (GMT-05:00)
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [nwcrg] Sliding window draft and coding schemes (e.g. RLNC)

Hi everybody,

Section 1.

Section 2.2

Section 4.2

Section 4.5

Section 5.1

Section 5.2

Section 5.3

Section 5.4

Best regards,
Morten

Cheers,

  Vincent

best regards,

Brian

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 5 May 2015 20:57:43 +0000

:-)

I guess the question becomes: when does an application layer code become a network code? 

Are you suggesting removing the end-to-end use cases from the RG charter and the scope of the research group? Thus solely focus on those applications where re-encoding is necessary: peer to peer, some storage, some NFV/SDN, MANETs, multicast, some but not all multi-path etc. In principle I would not totally disagree with this as Application Layer Coding would still be part of FECFRAME2 but in the IETF not the IRTF (Vincent prove me wrong).

But actually, from an architecture point of view, you can start from an end to end implementation and add intermediate coding nodes as your network grows with new middleboxes, as you get more access to in-network nodes or as the need (or not) for coding at the intermediate nodes appears. As you remember some of the coding decisions were discussed in the “Myth paper”.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6852100 <http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6852100>
It could be a continuum… So then keeping the end to end use cases can be justified as a first step of that evolution.

I guess it is for the list to decide which use cases need keeping?

And yes a network code without a network is just a code… But potentially still very useful :-)

Marie-Jose Montpetit, Ph.D.
[email-masked]
@SocialTVMIT

> On May 5, 2015, at 3:10 PM, Muriel Medard <[email-masked]> wrote:
> 
> Dear all,
>

---

From: Vincent Roca <[email-masked]>
Date: Tue, 5 May 2015 23:15:24 +0200

You’re right Muriel, but we can have control of two tunnel endpoints within the network (e.g., two middleboxes, or a host and a network
component) but not of the rest of the infrastructure. FECFRAME can be deployed in this way for instance. From this point of view, we’re
doing some in-network coding, without necessarily doing re-coding.
Multi-Path TCP also works end-to-end, without in-network (re-)coding as far as I understood. It’s however recognized as in-scope for
our group.

Once again, I don’t see this as an issue since network coding is a generic term that gathers different complementary techniques.

Cheers,

  Vincent

> Le 5 mai 2015 à 21:10, Muriel Medard <[email-masked]> a écrit :
> 
> Dear all,
>

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Tue, 5 May 2015 18:31:23 -0400

Ok, I see what you mean. I was thinking about it from a 
computational/algorithmic point of view - in which case re-coding is 
very practical and easy to implement. But, of course as Muriel also 
points out, if you don't have access to the data then there is only so 
much you can do.

Anyways, I'm pretty sure that for every example where we cannot use 
recoding there are others where we can - like p2p, mesh, etc. Not 
considering recoding would be an unnecessary limitation in my opinion.

- M

On 05/05/2015 11:10 AM, jonathan detchart wrote:
> Hi Morten,
>
> For example, if you don’t control the intermediate nodes, or if you 
> have a single hop, re-encoding is not feasible or practical.
>
> Some use cases :
>> I'm a bit puzzled by your statement "many use cases where re-encoding 
>> is not feasible or practical". Do you have any specific scenarios in 
>> mind?
>>
>> - M
>>
>>
>>> I re-read your email. We fully agree on the use of windows since 
>>> this is what Tetrys has been doing from the start.
>>>
>>> Muriel,
>>> On the re-encoding :
>>>> windows. Recoding is crucial. Otherwise,  it is just a code, like 
>>>> RS or Fountain,  not a network code.
>>>>
>>>> Best, Muriel.
>>>>
>>>>
>>>> assessment that the general concepts and architecture looks okay. 
>>>> As Vincent points out in 
>>>> draft-roca-nwcrg-fecframev2-problem-position-00 it is mostly a 
>>>> question of removing the limitation of fixed size blocks.
>>>>
>>>> Below are my comments to 
>>>> draft-roca-nwcrg-fecframev2-problem-position-00:
>>>>
>>>> Section 1.
>>>>
>>>> I don't think the fact that we operate in a block manner impacts 
>>>> the delay significantly. It is possible with most blocked RLNC 
>>>> codes to code only over the symbols currently available (and for 
>>>> the decoder to "detect" full rank of a sub-matrix). The crux of the 
>>>> problem is however captured in the next statement.
>>>>
>>>> This is the real problem causing delay. Mapping this back to RFC 
>>>> 6363 (Section 4.1 p.12 top) I would say that the following statement :
>>>>
>>>> If/when we decide to do it. I think most of the logic for this 
>>>> could reside in the CDP. The additional functionality needed by the 
>>>> FEC scheme would (I think) be minimal. Also the FEC payload ID for 
>>>> It is a good question. I would probably just say that it is a 
>>>> bridge we will cross should it ever become relevant. I would 
>>>> probably not try to include anything on that into the document.
>>>>
>>>> Section 5.1
>>>>
>>>> and the FEC Scheme. I think it would be nice to describe it in 
>>>> terms of a "pull model" where the FEC Framework v2 or the CDP 
>>>> "pulls" repair symbols from the FEC Scheme at a suitable rate 
>>>> (defined by the CDP). The way it is formulated now it is not clear 
>>>> whether it is the FEC Scheme that defines how many repair symbols 
>>>> are created or the FEC Framework v2 / CDP. But I think that is also 
>>>> unclear in RFC6363, perhaps it is just me ;)
>>>>
>>>> Section 5.2
>>>>
>>>> symbol". So even though we have a very long symbol in the window, 
>>>> if it isn't included in a specific encoding it will not impact the 
>>>> length of that repair symbol. This will not have much impact on 
>>>> high field codes - but for binary/sparse codes it may.
>>>>
>>>> For Figure 2 the definition of the F and L fields should be given. 
>>>> I did not find it - but perhaps I missed it.
>>>>
>>>>
>>>> Section 5.3
>>>>
>>>> feedback for the encoder (sender) or not. If it has feedback to 
>>>> send and the CDP has a method of getting that feedback to the 
>>>> sender then it can take advantage of it. However, no FEC scheme 
>>>> should rely on the feedback e.g. to move the window, but simply 
>>>> utilize it for performance reasons. I think this is also in-line 
>>>> with what is already in RFC 6363 Section 6. However, we many want 
>>>> to explicitly generate some working around that and define a 
>>>> container for it FEC Feedback Information.
>>>>
>>>> Section 5.4
>>>>
>>>> FECFRAMEv2, but rather left up the specific FEC Scheme. I might 
>>>> have missed something here but to me the symbol identifiers 
>>>> specified by RFC 6363 see adequate for our purpose here as well.
>>>>
>>>>>> As a result of some discussion with Marie, I thought it would be 
>>>>>> a good idea to share a few of my thoughts on some of the near 
>>>>>> term activities we seem to have identified and making some 
>>>>>> progress on.  One of the nearer-term “products” of our NWCRG 
>>>>>> discussion is the end-to-end transport use case with the 
>>>>>> developing sliding window approach being documented in Jonathan, 
>>>>>> et al’s draft.
>>>>>>
>>>>>> thing to note here is the the main value proposition for 
>>>>>> _unicast_ end to end use of coding lies somewhat with the delay 
>>>>>> improvements and that the sliding window type approach helps 
>>>>>> maximize the gains here as compared to the transport efficiencies 
>>>>>> coding yields for multicast (it also gets some delay benefits too 
>>>>>> under certain use cases).  While some of the formats / semantics 
>>>>>> of RMT/FecFrame may be reused, they may be too "block code 
>>>>>> oriented” as they are currently specified?
>>>>>>
>>>>>> in” RLNC and some of the other coding algorithms discussed (all 
>>>>>> the IPR issues notwithstanding).  It may be necessary to have the 
>>>>>> seemed we were getting some progress on this with Jonathan’s 
>>>>>> draft and more recently Morten’s constructive comments on that. 
>>>>>>  This may be one of the pieces that can transition more early to 
>>>>>> IETF working group activities for end-to-end transport purposes 
>>>>>> while we continue in NWCRG to work on the more “researchy” items. 
>>>>>> I think having this initiated in NWCRG is OK since we’ve 
>>>>>> assembled a set of people that may be able to work the problem? 
>>>>>>  And if we establish a basis of components (e.g. packet formats, 
>>>>>> coding scheme definitions) from this that may also be useful for 
>>>>>> other applications of network coding (i.e. more “in network” 
>>>>>> things like your DNC concept, ideas like Cedric described, SDN 
>>>>>> applications of coding, etc), then it is also beneficial to 
>>>>>> ongoing NWCRG work, too.  Then, when it’s sufficiently mature it 
>>>>>> might find a (transport area) working group home for the longer term?
>>>>>>
>>>>>> done here since we seemed (to me) to be sort of proceeding 
>>>>>> (perhaps lurching) along this path anyway, but (with Marie’s 
>>>>>> help) have realized these might thoughts worth sharing.
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> Brian

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Tue, 5 May 2015 18:42:09 -0400

Hi Vincent,
I think it all depends on your scenario. We have built networks where we 
use recoding at WiFi repeaters for broadcast. Recoding does not require 
feedback to be useful.

Anyways I think we all agree that the are places in existing systems 
where recoding will not work and will not be practical. On the other 
hand as a research group I think we should also consider the future use 
of the technology - and in that spirit recoding is important.

- M

On 05/05/2015 12:52 PM, Vincent Roca wrote:
> Hello Morten,
>
> I would add to the list of use-cases broadcast networks where you have 
> no backward channel or don’t want to use it
> I don’t think we have problems finding use-cases where re-coding is 
> not desirable/feasible. That’s probably a « degenerated »
>> Le 5 mai 2015 à 17:10, jonathan detchart <[email-masked] 
>> <mailto:[email-masked]>> a écrit :
>>
>> Hi Morten,
>>
>>> I'm a bit puzzled by your statement "many use cases where 
>>> re-encoding is not feasible or practical". Do you have any specific 
>>> scenarios in mind?
>>>
>>> - M
>>>
>>>
>>>>> Thank you. I think it is important that coding not be restricted 
>>>>> to blocks, which can be highly limiting and incompatible with 
>>>>> sliding windows. Recoding is crucial. Otherwise,  it is just a 
>>>>> code, like RS or Fountain,  not a network code.
>>>>>
>>>>> Best, Muriel.
>>>>>
>>>>>
>>>>> the decoder to "detect" full rank of a sub-matrix). The crux of 
>>>>> the problem is however captured in the next statement.
>>>>>
>>>>> symbols should be sent should be softened. Such that we are 
>>>>> allowed to dynamically generate repair according to some rate 
>>>>> defined in the CDP.
>>>>>
>>>>> Section 2.2
>>>>>
>>>>> could reside in the CDP. The additional functionality needed by 
>>>>> the FEC scheme would (I think) be minimal. Also the FEC payload ID 
>>>>> for encoded and recoded packets would probably be the same for 
>>>>> most FEC schemes.
>>>>>
>>>>> Section 4.5
>>>>>
>>>>> are created or the FEC Framework v2 / CDP. But I think that is 
>>>>> also unclear in RFC6363, perhaps it is just me ;)
>>>>>
>>>>> Section 5.2
>>>>>
>>>>> length will be "equal to the maximum ADUI size included in a 
>>>>> repair symbol". So even though we have a very long symbol in the 
>>>>> window, if it isn't included in a specific encoding it will not 
>>>>> impact the length of that repair symbol. This will not have much 
>>>>> impact on high field codes - but for binary/sparse codes it may.
>>>>>
>>>>>>> Le 6 avr. 2015 à 18:44, Brian Adamson 
>>>>>>> <[email-masked] <mailto:[email-masked]>> 
>>>>>>> a écrit :
>>>>>>>
>>>>>>> document an accompanying “FEC Scheme or two (e.g. RLNC, etc) 
>>>>>>> that could be applied with the sliding window protocol.  That 
>>>>>>> may help us get the framework right.  It would perhaps even be 
>>>>>>> an interesting thought exercise to see if something like RLNC 
>>>>>>> could documented in the form of an RMT or FecFrame “FEC 
>>>>>>> Scheme”?.  One thing to note here is the the main value 
>>>>>>> proposition for _unicast_ end to end use of coding lies somewhat 
>>>>>>> with the delay improvements and that the sliding window type 
>>>>>>> approach helps maximize the gains here as compared to the 
>>>>>>> transport efficiencies coding yields for multicast (it also gets 
>>>>>>> some delay benefits too under certain use cases).  While some of 
>>>>>>> the formats / semantics of RMT/FecFrame may be reused, they may 
>>>>>>> be too "block code oriented” as they are currently specified?
>>>>>>>
>>>>>>> for defining a sliding window framework that one could then 
>>>>>>> “plug in” RLNC and some of the other coding algorithms discussed 
>>>>>>> (all the IPR issues notwithstanding).  It may be necessary to 
>>>>>>> have the sliding window document to provide a reference for how 
>>>>>>> to specify RLNC.  We did that in RMT where we wrote the “FEC 
>>>>>>> Building Block” document that established some core packet 
>>>>>>> formats (and IANA registries) so we could go on to document 
>>>>>>> specific FEC coding algorithms (we called them FEC Schemes) 
>>>>>>> including non-proprietary stuff like Reed Solomon, LDPC as well 
>>>>>>> as the proprietary Raptor codes, etc.
>>>>>>>
>>>>>>> while we continue in NWCRG to work on the more “researchy” 
>>>>>>> items. I think having this initiated in NWCRG is OK since we’ve

---

From: Muriel Medard <[email-masked]>
Date: Tue, 5 May 2015 23:58:27 +0000

Dear all,

I agree with Morten.

A network code might not be used as a network code, and simply in a point to point fashion, but it should be able to be used as A network cide. A code that can only be used in a point to point fashion is not a network code. A point to point RS, even if implemented inside a network, does not become a network code.

Best,

Muriel.

-------- Original message --------
From: "Morten V. Pedersen" <[email-masked]>
Date: 05/05/2015 18:42 (GMT-05:00)
To: Vincent Roca <[email-masked]>
Cc: Jonathan Detchart <[email-masked]>, [email-masked], Muriel Medard <[email-masked]>
Subject: Re: [nwcrg] Sliding window draft and coding schemes (e.g. RLNC)

Hi Vincent,
I think it all depends on your scenario. We have built networks where we use recoding at WiFi repeaters for broadcast. Recoding does not require feedback to be useful.

Anyways I think we all agree that the are places in existing systems where recoding will not work and will not be practical. On the other hand as a research group I think we should also consider the future use of the technology - and in that spirit recoding is important.

- M

Cheers,

  Vincent

Le 5 mai 2015 à 17:10, jonathan detchart <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Morten,

Some use cases :

Jonathan DETCHART

Hi Jonathan,

- M

Muriel,
On the re-encoding :

Jonathan DETCHART

Dear all,

Best, Muriel.

-------- Original message --------
From: "Morten V. Pedersen" <[email-masked]<mailto:[email-masked]>>
Date: 05/03/2015 20:28 (GMT-05:00)
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [nwcrg] Sliding window draft and coding schemes (e.g. RLNC)

Hi everybody,

Section 1.

Section 2.2

Section 4.2

Section 4.5

Section 5.1

Section 5.2

Section 5.3

Section 5.4

Best regards,
Morten

Cheers,

  Vincent

best regards,

Brian

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 6 May 2015 00:01:54 +0000

I think we all agree :-)

> On May 5, 2015, at 7:58 PM, Muriel Medard <[email-masked]> wrote:
> 
> Dear all,
> 
> I agree with Morten. 
> 
>>> Le 5 mai 2015 à 17:10, jonathan detchart <[email-masked] <mailto:[email-masked]>> a écrit :
>>> 
>>> Hi Morten,
>>>