Re: [nwcrg] nwcrg Digest, Vol 65, Issue 2

[Janus Heide <[e-mail]>]

Hi Salvatore,


Thanks for taking the time to read the draft and provide comments, and 
great to hear that it contained information that was useful for you! 
Below some thoughts / comments inline marked with <JH></JH>

Best Janus


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.

<JH> Generally I do not think think it is necessary/helpful to 
distinguish between coded symbols and partially decoded symbols, since 
recoding over symbols before or after the partial decoding will not 
change the maximal rank the output "recoded" symbol can have, so I think 
"partially decoded symbols" could be removed. </JH>

- 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.

<JH> Hinting at good parameters is not easy, as both the reliability, 
delay and computational impact needs to be factored into the system 
performance. But I agree that it would be good to at-least provide some 
useful references, which could also include the impact on throughput and 
maybe also add some basic equations. </JH>


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.

<JH> Correct, to me referencing that section in the background document 
is not helpful, I think it should be removed or replaced with a 
reference that is more formal in its definition of encoding. </JH>


- "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:

<JH> The rank defines the number of symbols over which encoding was 
performed, so when coding over a block that would mean that only the 
first ENCODER RANK coefficients can be non-zero where the remaining 
coefficients must be zero. Appreciate your suggestion to make it 
clearer, will try yo incorporate in the next iteration. </JH>

"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.

<JH> a coding vector is usually defined as SYMBOLS coding coefficients 
!= ENCODER RANK coefficients. So if we only use coding vector and your 
suggestions above we will end up operating over a set of vectors with 
unequal length (all the unspecified coefficients are zero), I think this 
would make it even hard to provide an unambiguous definition </JH>

- "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?

<JH> Depends on what flexibility you want, if a static PRNG is ok then 
no, if you want to use different PRNGs for different sessions then you 
should define it in an outer header (and maybe negotiate it at 
initialization), same if you want to change the PRNG between symbol 
representations - although I would question if there would be a use-case 
for doing that? </JH>

- 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?

<JH> Normally I would say that a generation size of 1024 or smaller 
would provide acceptable flexibility. But there could be instances where 
you want to support larger generation sizes. The reason why not to just 
always go with the larger 18 bits is that this would constitute a larger 
overhead on every packet - and one that would be larger than the max 
target overhead we had </JH>

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

<JH> Great then it worked as hoped, and thanks again for your comments </JH>





On 05.03.2019 21.00, [e-mail] wrote:
> Send nwcrg mailing list submissions to
> 	[e-mail]
>
> 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
> 	[e-mail]
>
> You can reach the person managing the list at
> 	[e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nwcrg digest..."
>
> Today's Topics:
>
>     1. comments on the drafts nwcrg-rnlc-background00 and rlnc-01
>        (Salvatore Todo Signorello)
>
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg