Subject: Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-rlc-fec-scheme-14: (with COMMENT)

From: Vincent Roca <[email-masked]>
Date: Wed, 12 Jun 2019 18:16:03 +0200

IESG Members, all,

Thanks a lot for this second IESG review round (last time it was part of the RLC I-D).
I have copied below all Discuss/Comments made for this -03 version of the document
(previous comments for -02 have already been considered) and added our answers.

Many thanks, the document quality has been further improved.
Cheers,

   Vincent, on behalf of the authors

==========

> Roman Danyliw Discuss
>
> Discuss (2019-05-28)
>
> (1) Section 1.  Per “The TinyMT32 PRNG initialization depends, among other things, on a parameter set -- namely (mat1, mat2, tmat) -- that needs to be well chosen (pre-calculated values are available in the official web site).”, why is there a reference to an external website when Section 3.1 explicitly lists the constant and mandates their usage?  I’m elevating this to a discuss as there should be no ambiguity on the location of these constants.

[VR] You're right, it brings confusion. We have removed this
part of the sentence.

NEW:
   The TinyMT32 PRNG initialization depends, among other things, on a
   parameter set, namely (mat1, mat2, tmat).  In order to facilitate the
   use of this PRNG and make the sequence of pseudo-random numbers
   depend only on the seed value, this specification requires the use of
   a specific parameter set (see Section 3.1).  This is a major
   difference with respect to the implementation version 1.1
   (2015/04/24) that leaves this parameter set unspecified.

> (2) Section 3.1.  A comment in tinymt32_next_state() notes code changes made to the “original code … [so it is] not depend on the representation of negative integers by 2's complements.”  The following code in tinymt32_temper() appears to suffer from this same, original portability issue:
> t0 ^= -((int32_t)(t1 & 1)) & s->tmat;

[VR] Shame on me, I've omitted this line.
You're perfectly right and here is the fix. Thanks!

NEW:
       /*
        * The if (t1 & 1) {...} block below replaces:
        *     t0 ^= -((int32_t)(t1 & 1)) & s->tmat;
        * The adopted code is equivalent to the original code
        * but does not depend on the representation of negative
        * integers by 2's complements. It is therefore more
        * portable, but includes an if-branch which may slow
        * down the generation speed.
        */
       if (t1 & 1) {
           t0 ^= s->tmat;
       }

==========

> Comment (2019-05-28)
>
> (1) Section 1.  “BigCrush in TestU01 and AdaptiveCrush” needs a reference.

[VR] I have added the two URLs for the academic publicatons behind these
two PRNG statistical tests, keeping also the two URLs to the related
software web sites.

> (2) Abstract and Section 1.  I found characterizing the quality of the randomness as “pretty good” imprecise (relative to what?).  Can this statement be qualified or qualified in some way?

[VR] Yes, I've clarified the abstract by refering to Park-Miller PRNG.
I think the new Section I paragraph contains enough information to
further support this claim.

NEW (abstract):
   The main
   advantage of TinyMT32 over MT is the use of a small internal state,
   compatible with most target platforms including embedded devices,
   while keeping a reasonably good randomness that represents a
   sigificant improvement compared to the Park-Miller Linear
   Congruential PRNG.

> (3) Section 1 (“This is the first difference …”) and Section 3.1 (“The TinyMT32 PRNG reference implementation is reproduced in Figure 1, with the following differences …”) both enumerate a list of differences between the github repo and the code in this text.  Why are both required? Section 3.1 seems more precise.

[VR] You're right, we now only refer to the specialization of the
(mat1, mat2, tmat) tuple in Section 1 (because of its importance in
the way we use the PRNG), leaving the details for Section 3.1.

> (4) Section 1.  I am confused by the terminology of “official web site” and “official github site”.  What makes them official?

[VR] Right, and we changed the wording:

NEW:

   This document specifies the TinyMT32 PRNG, as a specialization of the
   reference implementation version 1.1 (2015/04/24) by Mutsuo Saito and
   Makoto Matsumoto, from Hiroshima University, that can be found at
   [TinyMT-web] (TinyMT web site) and [TinyMT-dev] (Github site).  This
   specialisation aims at having a simple-to-use and deterministic PRNG,
   as explained below.

> (5) Section 1.  With due respect to the first two authors, it seems odd to mention them by name three times in this section.  Also, the fact that this document is derived from a github repo is mentioned twice in this section and once in the code comments of Section 3.1.

[VR] Yes, you're right. Their names now appear only once in text, once in source code, and of course in the authors list and in references. This is fair.

> (6) Section 3.1.  There are normative C code blocks in this text.  The obvious fact that this is C code needs to be specified – consider C99 (ISO/IEC 9899:1999), C11 (ISO/IEC 9899:2011), C18 (ISO/IEC 9899:2018)

[VR] Yes, you're right. I've checked with the -c99, -c11, -c17
(I'm using CLANG and -c18 does not exist yet) C dialect flags
and it compiles/runs without any problem.

NEW:
   The TinyMT32 PRNG reference implementation is reproduced in Figure 1.
   This is a C language implementation, compatible with the C99 (ISO/IEC
   9899:1999), C11 (ISO/IEC 9899:2011) and C18 (ISO/IEC 9899:2018)
   versions of the C language.  ...

> (7) Section 3.1.  I agree with ekr’s original comment that hard coded a constant in tinymt32_init() makes the code less readable -- “s->status[i & 3] ^= i + UINT32_C(1812433253)”

[VR] In general I would agree but in this particular case I have
no idea what this constant means. Hard to assign it a meaningful
constant name. Is that really a problem?

> (8) Editorial Nits
>
> Abstract.  No references are permitted in the abstract.

[VR] removed (the reference still appears in Section I so this is not an issue).

> Section 1.  Typo.  s/variatnt/variant/
> Section 1.  Typo.  s/randomnes/randomness/
> Section 3.1.  Typo.  s/licence/license/

[VR] done.

==========

> Adam Roach Discuss
> Discuss (2019-05-29)
>
> The normative portion of this document is the machine code in section 3.1. There
> is no definition or citation for the formal language used in this document. The
> document needs to either define or normatively cite the definition of this
> language.
>
> I suspect that the citation you want is ISO/IEC 9899:1999 (or a newer document
> in that same series).

[VR] Yes, you're perfectly right. See my answer to Roman Danyliw's comment.
We now explicitely refer to the C99 to C18 flavors of C (all three work).

==========
> Benjamin Kaduk No Objection
>
> Comment (2019-05-28)
>
> In Section 3.1:
>
>    o  the original copyright and licence have been removed, in
>       accordance with BCP 78 and the IETF Trust's Legal Provisions
>       Relating to IETF Documents (http://trustee.ietf.org/license-info);
>
> The original copyright holder's permission is needed to do this!  Perhaps
> it is appropriate to note that the original authors are now listed as
> authors on this document.

[VR] Done.

> Please also specify what language the code in Section 3.1 is written in,
> including reference (so as to specify which version of C it is to be
> intepreted as).

[VR] Done (see answer above).

> I agree with the secdir reviewer and Mirja that some more references
> would be good.
>
> Section-by-section comments follow.
>
> Abstract
>    while keeping a reasonably good randomness.
>
> please add the "non-cryptographic" qualifier.

[VR] Done (it's suggested in the following comment anyway).

> Section 1
>
>                           According to statistical tests (BigCrush in
>    TestU01 and AdaptiveCrush), the quality of the outputs of TinyMT
>    seems pretty good in terms of randomnes (in particular the uniformity
>    of generated numbers), taking the small size of the internal state
>    into consideration (see [TinyMT-web]).  [...]
>
> I'd suggest rewording as "The outputs of TinyMT satisfy several
> statistical tests for (non-cryptographic) randomness, including BigCrush
> in TestU01 and AdaptiveCrush), leaving it well-placed for
> non-cryptographic usage, especially given the small size of its internal
> state." or similar.  (This avoids the "pretty good" construct and moves
> the emphasis from the tests to the usability of the algorithm.)

[VR] Done. Much better like that.

> Section 3.1
>
>    o  mat1 = 0x8f7011ee = 2406486510
>    o  mat2 = 0xfc78ff1f = 4235788063
>    o  tmat = 0x3793fdff = 932445695
>
> side note: these first two have the MSB set, and thus when the
> decimal form of the constant is used in C code, the implicit type will
> be a signed integer type of width strictly greater than 32, as opposed
> to an unsigned integer type (which would presumably have width 32 bits
> on most modern sytsems).

[VR] The above three definitions are from the textual part of the document.
In the C implementation, UINT32_C(...) is used, which brings us to your
comment below.

>        for (int i = 1; i < MIN_LOOP; i++) {
>            s->status[i & 3] ^= i + UINT32_C(1812433253)
>                * (s->status[(i - 1) & 3]
>                   ^ (s->status[(i - 1) & 3] >> 30));
>
> side note: I note that the UINT32_C macro produces a result of type
> uint_least32_t, which in theory could be wider and of greater conversion
> rank than uint32_t.  This would result in the intermediate calculations
> being done in a type other than uint32_t, though for the specific
> calculation here this should not cause any difference in the final
> output after truncation to 32 bits.

[VR] I agree with your analysis. This least32 mapping is pretty subtle!

> Section 3.2
>
>    This PRNG MUST first be initialized with the following function:
>
>       void tinymt32_init (tinymt32_t * s, uint32_t seed);
>
> nit: the pointer declaration style here was missed in the style pass
> done in a recent revision.

[VR] Fixed.

>    It takes as input a 32-bit unsigned integer used as a seed (note that
>    value 0 is authorized by TinyMT32).  [...]
>
> nit: perhaps "permitted" is a better word than "authorized", which can
> have some different connotations to IETF readers.

[VR] Done.

>                                     The use of this structure authorizes
>    several instances of this PRNG to be used in parallel, each of them
>    having its own instance of the structure.
>
> nit: here, "admits" is a better replacement for "authorizes" (but
> "permits" would be fine, too).

[VR] Done.

> Section 3.3
>
>                Consequently, any implementation of the TinyMT32 PRNG in
>    line with this specification MUST comply with the following criteria.
>    Using a seed value of 1, the first 50 values returned by
>    tinymt32_generate_uint32(s) as 32-bit unsigned integers MUST be equal
>    to values provided in Figure 2.  [...]
>
> I don't think it's appropriate to attempt to use "agreement with these
> test vectors" as a compliance mechanism (i.e., normative "MUST") -- the
> normative requirement must surely be to have the same observable
> behavior as the algorithm specified in the C code of Section 3.1.  These
> vectors are just test vectors to give an implementor some confidence
> that they agree with the reference behavior.
>
> (You also need to say whether I read rows first or columns first in the
> Figure's contents.)

[VR] Yes to both comments. We changed as suggested.

NEW:
   Consequently, any implementation of the TinyMT32 PRNG in
   line with this specification MUST have the same output as that
   provided by the reference implementation of Figure 1.  In order to
   increase the compliancy confidence, this document proposes the
   following criteria.  Using a seed value of 1, the first 50 values
   returned by tinymt32_generate_uint32(s) as 32-bit unsigned integers
   are equal to values provided in Figure 2, to be read line by line.

===========

> Barry Leiba No Objection
> Comment (2019-05-28)
>
> — Abstract —
>
>    The main
>    advantage of TinyMT32 over MT is the use of a small internal state,
>    compatible with most target platforms including embedded devices,
>    while keeping a reasonably good randomness.
>
> The difference between “most target platforms including embedded devices,” and “most target platforms, including embedded devices,” is too subtle to be sure that readers get the meaning right.  I think the sentence would be clearer if it said, “most target platforms that include embedded devices,”.

[VR] Yes, it's subtle. We changed as suggested.

> — Section 1 —
>
>    the quality of the outputs of TinyMT
>    seems pretty good in terms of randomnes
>
> Make it “randomness”.

[VR] Done.

>    However, neither the TinyMT
>    nor MT PRNG are meant to be used for cryptographic applications.
>
> This seems a bit more buried than it should be, as it’s important.  I suggest putting some version of this in the Abstract, and also moving it more toward the beginning of the Introduction (probably in the first paragraph.

[VR] You're right, it's essential. We added a sentence at the end
of the Abstract, and clarified it at the end of 1st paragraph of
Section 1.

===========

> Martin Vigoureux No Objection
> Comment (2019-05-28)
>
> Hi,
>
> I only have a minor question:
> In which direction should the numbers of Figure 2 be read, per column or per line?

[VR] Good point. It's clarified.

NEW:
   Figure 2: First 50 decimal values (to be read per line) returned by
   tinymt32_generate_uint32(s) as 32-bit unsigned integers, with a seed
                                value of 1.

> nit:
> s/will then updated/will then be updated/

[VR] Done.

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 13 Jun 2019 16:00:08 +0000

Hi!

I’m keeping the subject line but we’re really talking about draft-ietf-tsvwg-tinymt32 here.

Your changes in -04 addresses all of my DISCUSSes and almost all of my COMMENTs.  Thanks for the update.  Adam is holding a DISCUSS that’s nearly identical to my remaining COMMENT (about having a normative reference for C99) so I’ll let him hold the issue.

More details inline …

From: iesg [mailto:[email-masked]] On Behalf Of Vincent Roca
Sent: Wednesday, June 12, 2019 12:16 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-rlc-fec-scheme-14: (with COMMENT)

IESG Members, all,

==========

NEW:

[Roman] Thanks.  This addresses my feedback.

NEW:
       /*

[Roman] Thanks.  This addresses my feedback.

==========

[Roman]  Thanks.  This addresses my feedback.

NEW (abstract):
   The main

[Roman]  Thanks.  This addresses my feedback.

[Roman]  Thanks.  This addresses my feedback.

NEW:

[Roman]  Thanks.  This addresses my feedback.

[Roman]  Thanks.  This addresses my feedback.

NEW:

[Roman]  This language correct, but it needs to explicitly cite one of these a normative reference.  FWIW, I think you can just say C99.

[Roman]  No problem.

[VR] done.

[Roman]  Thanks!

Regards,
Roman

---

From: Vincent Roca <[email-masked]>
Date: Tue, 18 Jun 2019 10:45:52 +0200

Hi Roman, Benjamin, all,

Back to the RLC I-D.
I have copied below the Discuss/Comments made for the -14 version of the document.

   Vincent and Belkacem

===

> Roman Danyliw Discuss
> Discuss (2019-05-28)
>
> A few code nits for Section 3.6 so that the code compiles:
> ** To make the combination of this source code and that in draft-ietf-tsvwg-tinymt32 compile requires that the directive “#include <string.h>” be added (for the memset).
>
> ** The final return in Section 3.6 is missing a semicolon:
> s/return 0/return 0;/

[VR] Done. I usually don't add system headers to focus on key aspects, but it does not hurt. And thanks for the ";".

===

> Comment (2019-05-28)
>
> (1) Section 3.5  Is there any guidance that needs to be provided on the value of the seed to tinymt32_init?

[VR] Good point. Anything is accepted, which is now clearly stated. Since we already discuss Repair_Key management (this repair_key is used as seed), we refer to section 6.1.

NEW:
   With the FEC Schemes defined in this document, the seed is in
   practice restricted to a value between 0 and 0xFFFF inclusive (note
   that this PRNG accepts a seed value equal to 0), since this is the
   Repair_Key 16-bit field value of the Repair FEC Payload ID
   (Section 4.1.3).  In practice, how to manage the seed and Repair_Key
   values (both are equal) is left to the implementer, using a
   monotonically increasing counter being one possibility (Section 6.1).

> (2) Section 3.6.  In the code comments for cc_nb, I recommend explicitly stating:
> s/number of entries in the table/
> number of entries in the cc_tab[] table/

[VR] Done.

> (3) Section 3.6.  Multiple C code fragments are used in the text.  Somewhere the text should state that the examples are C code and made a reference to what version -- consider C99 (ISO/IEC 9899:1999), C11 (ISO/IEC 9899:2011), C18 (ISO/IEC 9899:2018).

[VR] Yes. I added the same C99 normative reference as in the TinyMT32 I-D
and included some text to clearly state it. I did it for both Sections, 3.5
and 3.6.

NEW (3.6):
   Figure 3 shows the reference generate_coding_coefficients()
   implementation.  This is a C language implementation, written for C99
   [C99].

> (4) Other References Nits
> Section 1.  Please include a reference for FECFRAME on first introduction.

[VR] Done.

> Section 1.1.  What is the reference for Raptor/RaptorQ?

[VR] Added RFC6681.

> (6) Editorial Nits
> Abstract.  No references are permitted in the abstract

[VR] Removed.

> Section 1.1.  Multiple Typos.  s/either a end-/either an end-/g
> Section 1.2.  Extra space. s/constraints) ./constraints)./
> Section 1.4.  Multiple Typos.  s/signalling/signaling/g
> Section 6.2.  Typo.  s/Section Section 3.6/Section 3.6/

[VR] Done. Thanks.

===

>  Benjamin Kaduk (was Discuss) No Objection
> Comment (2019-05-28)
>
> Thank you for resolving my Discuss points!  Additionally,
> I really like the reorganization of the document(s) -- it seems to do a
> great job at putting the core protocol/algorithm elements in the
> spotlight, while retaining the interesting discussion about use cases
> and parameter derivation in a less-prominent location.  The introductory
> material for Appendix C also does a great job to frame the subsequent
> discussion.  Thank you!

[VR] You're welcome.
> I agree with Roman that the code snippets should be more clearly marked
> as (a specific version of) C and in the case of
> generate_coding_coefficeints() as a normative part of the protocol
> specification.

[VR] Done.

> Section 3.1
>
>    Appendix C proposes non normative technics to derive those
>    parameters, depending on the use-case specificities.
>
> nit: I think "techniques" would be more conventional usage than
> "technics" here.

[VR] Changed.

> Section 3.5
>
>    Any implementation of this PRNG MUST fulfill three validation
>    criteria: the one described in [tinymt32] (for the TinyMT32 32-bit
>    unsigned integer generator), and the two others detailed in
>    Appendix A (for the mapping to 4-bit and 8-bit intervals).  [...]
>
> As I noted on the tinymt32 document, this phrasing is a bit odd, though
> it feels less out of place here than in the tinymt32 document.

[VR] Yes, and I updated this I-D in the same way.

NEW:
   Any implementation of this PRNG MUST have the same output as that
   provided by the reference implementation of [tinymt32].  In order to
   increase the compliancy confidence, three criteria are proposed: the
   one described in [tinymt32] (for the TinyMT32 32-bit unsigned integer
   generator), and the two others detailed in Appendix A (for the
   mapping to 4-bit and 8-bit intervals). [...]

> Section 3.6
>
>     * (in/out) cc_tab[]  pointer to a table of the right size to store
>     *                    coding coefficients. All coefficients are
>     *                    stored as bytes, regardless of the m parameter,
>     *                    upon return of this function.
>
> Assuming this is C, it's perhaps a bit jarring to spell the function
> parameter as "cc_tab[]" but describe it as a pointer.  (In either case,
> the encoding for the function call will be that of a pointer, of course,
> so the array syntax seems needlessly confusing.)

[VR] "uint8_t* cc_tab" and "uint8_t cc_tab[]" declarations are equivalent.
        Both are pointers to uint8_t elements so there's nothing wrong.
        However I see your point and changed for the explicit pointer
        syntax.

> Section 3.7.1
>
>    The two RLC FEC Schemes specified in this document reuse the Finite
>    Fields defined in [RFC5510], section 8.1.  More specifically, the
>    [...]
>    The following irreducible polynomial MUST be used for GF(2^^8):
>
>       x^^8 + x^^4 + x^^3 + x^^2 + 1
>
> Given the former chunk, the normative "MUST" in the second chunk is
> redundant, since the authoritative source for this polynomial is the
> cited portion of RFC 5510.

[VR] Removed the second upper case MUST.

NEW:
   The following irreducible polynomial is used for GF(2^^8):
      x^^8 + x^^4 + x^^3 + x^^2 + 1

> Section 3.7.2
>
>              For each byte of position i in each source and the repair
>    symbol, where i belongs to {0; E-1}, compute:
>
> nit: do we expect the usage of the curly braces {} to indicate a closed
> interval to be well-understood by the readership (as opposed to square
> brackets [])?

[VR] Well it depends. In France, it seems preferable to use {...} for an
enumeration, and [] for a span, but conventions may differ in other
countries. Given you comment, I've changed for [].

>                                       The XOR sum of the byte of
>    position i in each source is computed and stored in the corresponding
>    byte of the repair symbol, where i belongs to {0; E-1}.  […]
>
> (ditto)

[VR] Done.

> Section 6.1
>
> I might add a note that the scheme for chosing the repair key is
> entirely at the discretion of the sender, since it is communicated in
> the wire format to the receiver(s), and that the sequential counter is
> presented as the simplest method that ensures new coefficients for each
> repair packet.  As already mentioned, other schemes are possible, and we
> definitely don't want any receivers hardcoding the assumption of
> sequentially incrementing counter.

[VR] Yes, definitively. It even didn't come to my mind that a receiver
may hardcode the way the repair key is managed. I've further reinforced
this.

NEW:
   In any case, chosing the repair key
   is entirely at the discretion of the sender, since it is communicated
   to the receiver(s) in each Repair FEC Payload ID.  A receiver should
   not make any assumption on the way the repair key is managed.

> Section 9.1
>
>                                               In case of small encoding
>    windows, the associated processing overhead is not an issue (e.g., we
>    measured decoding speeds between 745 Mbps and 2.8 Gbps on an ARM
>    Cortex-A15 embedded board in [Roca17] for an encoding window of size
>    18 or 23 symbols).  [...]
>
> Just to double-check: does the 2.8 Gbps correspond to the window of 18
> symbols or 23?

[VR] Not exactly, it essentially depends on the code rate (the higher,
the faster) and channel conditions, in addition to the ew_size that is
determined by the code rate.
It's well described in the paper and I don't want to put all details here,
however this is misleading and I've changed the wording.

NEW:
   In case of small encoding
   windows, the associated processing overhead is not an issue (e.g., we
   measured decoding speeds between 745 Mbps and 2.8 Gbps on an ARM
   Cortex-A15 embedded board in [Roca17] depending on the code rate and
   the channel conditions, using an encoding window of size 18 or 23
   symbols; see the above article for the details).

> Appendix A
>
> Please note whether the numbers should be read out column-first or
> row-first.

[VR] Done.

> I refer again to my comment on the tinymt32 document regarding the
> normative "MUST" language here vs. stating that these are test vectors.

[VR] Done.

> Appendix B
>
> side note: I don't propose to have you redo the analysis, but looking at
> the small sequences generated using seed values from 0 to 1,000,000 - 1
> is not terribly representative of the FEC usage, since the seed values
> there are limited to the range from 0 to 16k.  Comprehensive statistics
> on the 16k possible sequences (corresponding to the 16k possible repair
> keys) of 20 pseudo-random numbers would be more compelling.
>
> Also, for the scenario presented in Figure 12, I'm not sure I agree with
> the claim that "although the distribution is not perfect, there is no
> major bias".  Not in that I think there is bias, but in that I think
> that we should not expect the average occurrences column to be a
> constant -- the numbers here seem largely within the expected sort of
> variances for this type of sampling.

[VR] I need to give it a second thought... I've submitted -15 without
considering this comment and will see how to adress it in -16.

> Appendix D
>
>    Finally, it is worth noting that a receiver that benefits from an FEC
>    protection significantly higher than what is required to recover from
>    packet losses, can choose to reduce the ls_max_size.  In that case
>    lost ADUs will be recovered without relying on this optimization.
>
> nit(?): It's not entirely clear to me that this statement is well-placed
> in its current location.

[VR] I think it's well placed. We talk about ls_max_size and here we
say that using a too large value is not necessarily meaningful.

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 18 Jun 2019 09:23:32 +0000

Hello!

From: Vincent Roca [mailto:[email-masked]]
Sent: Tuesday, June 18, 2019 4:46 AM
To: Roman Danyliw <[email-masked]>; Benjamin Kaduk <[email-masked]>
Cc: Vincent Roca <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-rlc-fec-scheme-14: (with COMMENT)

Hi Roman, Benjamin, all,

Back to the RLC I-D.

   Vincent and Belkacem

===

===

NEW:

[VR] Done.

NEW (3.6):

[VR] Done.

[VR] Added RFC6681.

[VR] Removed.

[VR] Done. Thanks.

[Roman] Thank you for making these changes.  They address all of my feedback.

Regards,
Roman

---

From: Vincent Roca <[email-masked]>
Date: Tue, 18 Jun 2019 21:25:26 +0200

Benjamin,

I said in my previous email there was an unanswered comment.
Here it is, reflected in the brand new -16 I-D version.

> > keys) of 20 pseudo-random numbers would be more compelling.

[VR] I agree on the principle: PRNG usage is limited to 65536 different seeds (we re-use
a 16-bit field to carry this seed as the repair key) and the above tests are not in line with
the PRNG actual usage. I’ve done complementary tests limited to these 65536 seeds
and updated the document. Of course convergence to a uniform distribution is less good,
but I don’t see any risk for the RLC FEC Schemes efficiency.

NEW:
   Since the RLC FEC Schemes use of this PRNG will be limited to 16-bit
   seed values, we carried out the same test for the first 2^^16 seed
   values only.  The distribution (not shown) is of course less uniform,
   with value occurences ranging between 6.2121% (i.e., 81,423
   occurences out of a total of 65536*20=1,310,720) and 6.2948% (i.e.,
   82,507 occurences).  However, we do not believe it significantly
   impacts the RLC FEC Scheme behavior.

> considering this comment and will see how to adress it in -16.

[VR] I’ve left the document unmodified. In fact, if we compare these results with the
one achieved with the Park-Miller LC PRNG we see that the second one does not
work at all and MUST (yes) be avoided, while TinyMT32 even after truncation to 4-bits
is reasonably good. That was my initial idea.

Thanks for your feedback.
Cheers,

  Vincent and Belkacem