Subject: [nwcrg] comments on the drafts nwcrg-rnlc-background00 and rlnc-01

From: Salvatore Todo Signorello <[email-masked]>
Date: Tue, 5 Mar 2019 17:04:44 +0000

Dear NWCRG members,

here is Salvatore Signorello, a post-doc researcher at the University of 
Lisbon working with Prof. Fernando Ramos (reading us in cc). Within the 
framework of a recently-started research project on programmable virtual 
networks, we investigate the design of Random Linear Network Coding 
solutions running in Programmable Data-Planes. In the process of 
reasoning about a possible packet format, I ended up reading the related 
drafts the NWCRG has released. I think that is a really valuable read 
for whoever is undertaking a similar design step. So, first of all, 
thank you for your effort with making those documents available.

Then, I would like to share some minor comments and questions (see 
below) after a quick read of both the new drafts. Let me apologize in 
advance if any of the following comments does not make much sense. To be 
honest, I am pretty new to this topic, so I may be missing some 
background knowledge needed to easily grasp some of the content therein. 
When that happens, please feel free to simply throw the related comment 
away. If not, I would be glad if the authors of the drafts could clarify 
the points below.

Thank you very much for your time,

regards,

Salvatore

W.r.t draft-heide-nwcrg-rlnc-background-00:

- I was personally unaware of the precise definition of partially 
decoding, so I had to go through some external references to understand 
that. I think coded, recoded and systematic definitions are much more 
intuitive. So, I was wondering if the "partially decoded symbols" (used 
only twice throughout this draft) might need further explanation somewhere.

- concerning sub-section 2.1.2, there are several related works which 
have already explored the pros and cons of using different specific 
generation/symbol/field size values. So, I was wondering if this section 
could include more concrete details (yet not drawing any 
application-specific guideline) complemented with the proper 
bibliographic references.

W.r.t draft-heide-nwcrg-rlnc-01:

- Sec. 2.1: "...a coding vector as described in Section 1.1 is first 
generated...", there is no Section 1.1 within the current draft. This 
most likely refers to Sec. 1.1 of draft-heide-nwcrg-rlnc-background-00 
and has not updated during the transition from the previous single draft 
to the two actual ones.

- "If the TYPE is ’2’, all symbols included in this symbol 
representation are coded, with coding vectors generated using the 
included SEED and the ENCODER RANK."

Not sure the above could be re-phrased better, yet my understanding is 
that the Encoder Rank here only defines the number of coefficients per 
coding vector. So, something along the line of the following could work 
better:

"If the TYPE is ’2’, all symbols included in this symbol representation 
are coded, with coding vectors of ENCODER RANK coefficients each which 
are generated using the included SEED."

- "If the TYPE is ’3’, all symbols included in this symbol 
representation are either coded or recoded, with the coding coefficients 
included constituting ENCODER RANK coefficients each."

May be, using coding vectors could avoid the repetition of the word 
coefficients and make the sentence clearer.

- "To ensure that SEED can be interpreted correctly at the receiver, the 
same pseudo-random number generator MUST be used by the sender and a 
recoding or receiving node. Otherwise, more than one SEED field would 
need to be used."

Does this raise any requirement (e.g., an additional field) for a 
potential outer header?

- I deem the examples of section 2.3.1 very useful, yet I do not see yet 
the additional value/information the illustrations of packets for small 
and large encoding window sub-sections bring. Could anyone please 
elaborate a bit on this?

Overall, I second the choice of moving the background information into a 
separate draft. That makes the overall presentation of the content neater.