Subject: [nwcrg] New version of draft-detchart-nwcrg-tetrys

From: Detchart <[email-masked]>
Date: Mon, 6 Jul 2015 17:36:11 +0200

Dear all,

Please find the new version of the Tetrys draft :

https://tools.ietf.org/html/draft-detchart-nwcrg-tetrys-02 <https://tools.ietf.org/html/draft-detchart-nwcrg-tetrys-02>

Comments are welcome.

See you in Prague.

Jonathan DETCHART

---

From: Cedric Adjih <[email-masked]>
Date: Mon, 20 Jul 2015 15:31:55 +0200 (CEST)

Hi Jonathan,

  I'm happy that Tetrys draft now includes some extension for
managing recoding. So we are likely to converge to some 
generic packet format.

  I think that with Morten's survey, we could be some further
commonalities for a generic (or extensible) "Acknowledgment Packet Format".

  Also do you plan to support classical network coding
encoding vectors as an option ? (is it the SRLC?)

  Finally, seeing that you use Vandermonde-based coefficients,
is it your intent to support "one-symbol" network coding [TP12] 
for recoding ?

[TP12] "Toward one symbol network coding vectors"
N. Thomos, P. Frossard - Communications Letters, IEEE, 2012

cheers,
-- Cedric

----- Original Message -----
| From: "Detchart" <[email-masked]>
| To: [email-masked]
| Cc: "Jonathan DETCHART" <[email-masked]>
| Sent: Monday, July 6, 2015 5:36:11 PM
| Subject: [nwcrg] New version of draft-detchart-nwcrg-tetrys
| 
| 
| Dear all,
| 
| 
| Please find the new version of the Tetrys draft :
| 
| 
| https://tools.ietf.org/html/draft-detchart-nwcrg-tetrys-02
| 
| 
| Comments are welcome.
| 
| 
| See you in Prague.
| 
| 
| Jonathan DETCHART
| _______________________________________________
| nwcrg mailing list
| [email-masked]
| https://www.irtf.org/mailman/listinfo/nwcrg
|

---

From: Vincent Roca <[email-masked]>
Date: Mon, 20 Jul 2015 16:29:52 +0200

Hello Cedric,

Tetrys (just like FECFRAMEv2) is rather independent from the Coding Scheme(s) being used.

If the target use-case requires it, you may want to do in-network recoding. But not all use-cases
have this requirement. Then, if you need re-coding, yes, you’ll have to use specific Coding
Scheme(s) as they are not all compatible with this requirement (e.g., SRLC).

Recoding could be done with RLNC, by transmitting coding coefficients as you mentioned…
…But there’s the potential problem of MIT IPR on the subject then, don’t forget it.  And
in any case, sending coefficients is not efficient in terms of transmission overhead!

Cheers,

  Vincent

> Le 20 juil. 2015 à 15:31, Cedric Adjih <[email-masked]> a écrit :
> 
>  Hi Jonathan,
> 
> _______________________________________________
> nwcrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nwcrg

---

From: Detchart <[email-masked]>
Date: Mon, 20 Jul 2015 18:41:28 +0200

Hi Cedric,

To complete Vincent’s answer:

We propose something slightly different from TP12:
- we do not work in block mode, we use an elastic encoding window,
- [TP 12] does not really use a Vandermonde matrix but rather a generator matrix of MRD codes. We use a pure Vandermonde matrix.
- it appears [TP 12] has a limit when you want to combine source symbols (using GF(256), you can only combine 8 elements). We do not have such a limit (but have a matrix inversion they don’t have)
- [TP 12] can loose diversity compared to RLNC because of the dependency between the combinations (due to their matrix construction). This is not the case for our construction .

Concerning the encoding vectors, we proposed a solution to avoid transmitting the coefficients, even when you do recoding, and to reduce the overhead when you need to transmit the IDs of the source symbols included in the coded symbols (if you use an elastic encoding window, not block codes).
It is just another approach, but if you really need to store the coefficients for any reason, you can (see our encoding vectors format). I guess this is what you call “classical network coding encoding vectors”.

Jonathan

> On 20 Jul 2015, at 16:29, Vincent Roca <[email-masked]> wrote:
> 
> Hello Cedric,
> 
> .