Subject: [nwcrg] Symbol representation

From: Janus Heide <[email-masked]>
Date: Fri, 1 Jun 2018 13:27:03 +0200

Dear All,

On the last meeting in London, there was several documents related to 
representations of coded symbols and as pointed out by Vincent, his 
FECFRAME draft is currently in review.

A comment we received from Vincent was to essentially split our 
submitted document into two. One focusing on a generic symbol 
representation, and one containing information about RLNC more generally.

In order to find a representation for symbols that is useful to the 
largest group of people, we think it would be useful to agree on the 
premise of that representation. So its general motivation, the objective 
of the work, what features it should support etc. should be defined 
before attempting to produce a common solution.

We would be happy to start a document to reflect our current 
considerations and submit that for discussion. Everyone would of course 
be free to produce a similar document expressing another view. Would 
this approach be considered useful and productive at this time?

Additionally;
Is there a general interest to review and comment on such a document if 
produced?
Is anyone interested to produce a similar type of document providing an 
alternative view?

Best Janus Heide

---

From: Vincent Roca <[email-masked]>
Date: Fri, 1 Jun 2018 15:31:03 +0200

Hello Janus, everybody,

I confirm: one goal is to have common solutions.

It’s difficult to achieve when we design a coding solution that needs to fit into an existing transport protocol that has its own logic
(e.g., flute/alc, fecframe and quic). However even in that case, parts of an FEC specification remain untouched, coding details
in particular but also some key concepts and signaling techniques.

So let me clarify my thoughts (perhaps a bit differently from what I said during London meeting).

We need guidelines on how to specify FEC codes/schemes in the context of nwcrg (and a potential generic transport TBD).
RFC 6363 does it for FECFRAME (i.e., real-time flows), and RFC 3452 does the same for RMT (i.e., file transfers). Both docs
explain:
	- general principles;
	- how to specify a FEC BB to be used in the FECFRAME or RMT context (expected sections and topics);
	- provide some hints (e.g. RFC3452 introduce the key notions of block and symbol IDs).
It’s more than symbol representation and generic headers.

What exactly to put in this guideline document is the challenge. May I suggest we all think about it and then share ideas (I-D
or mailing list discussion)? It’s more or less what you were asking for. 

Then I see an RLNC FEC Scheme (or maybe several schemes to address several needs) specification as a proof-of-concept
for these guidelines (did we miss something or did something wrong?).

Thanks for starting the discussion.

Cheers,

   Vincent

> Le 1 juin 2018 à 13:27, Janus Heide <[email-masked]> a écrit :
> 
> Dear All,
> 
> On the last meeting in London, there was several documents related to representations of coded symbols and as pointed out by Vincent, his FECFRAME draft is currently in review.
> 
> A comment we received from Vincent was to essentially split our submitted document into two. One focusing on a generic symbol representation, and one containing information about RLNC more generally.
> 
> In order to find a representation for symbols that is useful to the largest group of people, we think it would be useful to agree on the premise of that representation. So its general motivation, the objective of the work, what features it should support etc. should be defined before attempting to produce a common solution.
> 
> We would be happy to start a document to reflect our current considerations and submit that for discussion. Everyone would of course be free to produce a similar document expressing another view. Would this approach be considered useful and productive at this time?
> 
> Additionally;
> Is there a general interest to review and comment on such a document if produced?
> Is anyone interested to produce a similar type of document providing an alternative view?
> 
> Best Janus Heide

---

From: Janus Heide <[email-masked]>
Date: Mon, 4 Jun 2018 09:37:33 +0200

Hi Vince and all,

Thanks for your views, below shortly my understanding of your suggestion 
to make sure that I understand you correctly.

What I had in mind was more or less to draft the first few (maybe 3 or 
4) pages of a "future" RFC, writing up the motivation for it and listing 
identified features it should support, known challenges these kinds of 
things.

What you are suggesting, if I understand correctly is to take a step 
back and think about, in general what the content of this document 
should be, correct?

My personally preference here would be something with a short turnaround 
time and I am ok with a bit of trial and error, which is the reason 
behind the first suggestion. However, I think the objective here is too 
include as many in the discussion so we can stay as unified as possible, 
so I look forward to hear what peoples opinion are.

Best Janus

On 06/01/18 15:31, Vincent Roca wrote:
> It’s difficult to achieve when we design a coding solution that needs 
> to fit into an existing transport protocol that has its own logic
> (e.g., flute/alc, fecframe and quic). However even in that case, parts 
> of an FEC specification remain untouched, coding details
> We need *guidelines on how to specify FEC codes/schemes in the context 
> of nwcrg *(and a potential generic transport TBD).
> RFC 6363 does it for FECFRAME (i.e., real-time flows), and RFC 3452 
> does the same for RMT (i.e., file transfers). Both docs
> explain:
> - general principles;
> What exactly to put in this guideline document is the challenge. May I 
> suggest we all think about it and then share ideas (I-D
> Then I see an RLNC FEC Scheme (or maybe several schemes to address 
> several needs) specification as a proof-of-concept
>> Le 1 juin 2018 à 13:27, Janus Heide <[email-masked] 
>> <mailto:[email-masked]>> a écrit :
>>
>> Dear All,
>>
>> premise of that representation. So its general motivation, the 
>> objective of the work, what features it should support etc. should be 
>> defined before attempting to produce a common solution.
>>
>> considerations and submit that for discussion. Everyone would of 
>> course be free to produce a similar document expressing another view. 
>> Would this approach be considered useful and productive at this time?
>>
>> Additionally;

---

From: Vincent Roca <[email-masked]>
Date: Tue, 5 Jun 2018 16:32:09 +0200

Hello Janus,

I think that both aspects, namely: « writing up the motivation for it and listing identified features it should support, known challenges these kinds of things »
and also « guidelines on how to specify FEC codes/schemes in the context of nwcrg » are in line with one another.
It’s essentially a matter of bootstraping the work. So let’s propose something and see how to move forward.

Cheers,

  Vincent

> Le 4 juin 2018 à 09:37, Janus Heide <[email-masked]> a écrit :
> 
> Hi Vince and all,
> 
> Thanks for your views, below shortly my understanding of your suggestion to make sure that I understand you correctly.
> 
> What I had in mind was more or less to draft the first few (maybe 3 or 4) pages of a "future" RFC, writing up the motivation for it and listing identified features it should support, known challenges these kinds of things.
> 
> What you are suggesting, if I understand correctly is to take a step back and think about, in general what the content of this document should be, correct?
> 
> My personally preference here would be something with a short turnaround time and I am ok with a bit of trial and error, which is the reason behind the first suggestion. However, I think the objective here is too include as many in the discussion so we can stay as unified as possible, so I look forward to hear what peoples opinion are.
> 
> Best Janus
> 
>>> Le 1 juin 2018 à 13:27, Janus Heide <[email-masked] <mailto:[email-masked]>> a écrit :
>>> 
>>> Dear All,
>>>