Subject: Re: [nwcrg] nwcrg Digest, Vol 28, Issue 13

From: "Thomos, Nikolaos" <[email-masked]>
Date: Thu, 10 Sep 2015 16:13:27 +0000

Hi all,
Apologies for my delayed response. A couple of clarifications about the [TP12]. Indeed, this system has a limitation of a generation size of 8 packets for GF(256). However, this drawback can be easily overcome by considering multiple generations that are encoded together. In this case, instead on having an overhead of a single symbol, you will need to spend for the network coding overhead as many symbols as the number of generations that are encoded together. Following the multi-generation approach you could extend this framework to the sliding or embedded window cases.
Best regards,
-Nikos

On Jul 20, 2015, at 8:00 PM, [email-masked]<mailto:[email-masked]> wrote:

Send nwcrg mailing list submissions to
[email-masked]<mailto:[email-masked]>

To subscribe or unsubscribe via the World Wide Web, visit
https://www.irtf.org/mailman/listinfo/nwcrg
or, via email, send a message with subject or body 'help' to
[email-masked]

You can reach the person managing the list at
[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of nwcrg digest..."
Today's Topics:

  1. Re: New version of draft-detchart-nwcrg-tetrys (Cedric Adjih)
  2. Re: New version of draft-detchart-nwcrg-tetrys (Vincent Roca)
  3. Re: Tutorial discussion (Frank Fitzek)
  4. Re: New version of draft-detchart-nwcrg-tetrys (Detchart)

From: Cedric Adjih <[email-masked]>
Subject: Re: [nwcrg] New version of draft-detchart-nwcrg-tetrys
Date: July 20, 2015 at 2:31:55 PM GMT+1
To: Detchart <[email-masked]>
Cc: <[email-masked]>

 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]>
Subject: Re: [nwcrg] New version of draft-detchart-nwcrg-tetrys
Date: July 20, 2015 at 3:29:52 PM GMT+1
To: Cedric Adjih <[email-masked]>
Cc: Vincent Roca <[email-masked]>, <[email-masked]>, Jonathan Detchart <[email-masked]>

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,

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
|

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

From: Frank Fitzek <[email-masked]>
Subject: Re: [nwcrg] Tutorial discussion
Date: July 20, 2015 at 4:07:09 PM GMT+1
To: <[email-masked]>

comments inline

Am 14.07.2015 um 04:36 schrieb Victor Firoiu:

Regarding the tutorial, here are some ideas for an outline, that include some inputs I got from Joao last year.

1. Brief overview of the Network Coding potential, with an example
- show high-level how it works
- show benefits, e.g. resilience, exploiting multi-path
maybe talk about Delay
- point out components: coding, reliability protocol

2. Overview of the theoretical basis
- fields, linear coding, the randomness benefit
recoding
- Main theorems (max-flow min-cut, multicast capacity)

3. Benefits and costs of NC

4. Practical applications

3 and 4 can be combined.
I think there would be two versions of the tutorial:
- one as a 45-50min presentation, possibly as an IAB talk
- another as a written document, to become a nwcrg draft and later Informational RFC.

Please comment on what you think each version should include, and on which topic you would like to contribute.

Victor

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

From: Detchart <[email-masked]>
Subject: Re: [nwcrg] New version of draft-detchart-nwcrg-tetrys
Date: July 20, 2015 at 5:41:28 PM GMT+1
To: <[email-masked]>
Cc: Vincent Roca <[email-masked]>, <[email-masked]>

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,

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,

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
|

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

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

________________________________________________
Dr Nikolaos Thomos
Lecturer
University of Essex,
Computer Science and Electronic Engineering Department
Colchester, United Kingdom
Tel: 0044 (0) 1206872404