Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-10.txt

[Vincent Roca <[e-mail]>]

Dear IESG members, all,

First of all, thanks a lot for your highly valuable feedback. It took us time to consider
them all, we sometimes significantly changed some parts of the I-D, but here is the
result.

Because there are many comments, we first answer globally (main  topics, TinyMT32
and parameter derivations) in this email, and in a second email we go through each
comment, as it appears in: 
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ballot/

Once again, thanks you.
Cheers,

  Vincent, Belkacem, Emmanuel.



PART I:  GLOBAL ANSWERS


1- About TinyMT32 source code
-----------------------------

** A PRNG specified through C code is now unavoidable

Time passed and trivial PRNGs like the Linear Congruential one are no longer sufficient.
TinyMT32 is defined by the authors through its C reference codec. Extracting a pseudo-code
description is not feasible.


** Clearing the copyright issue (hopefully)

Being a derived work, we added the following copyrigh after the original licence:
NEW:
   /**
    * The derived work of this document is:
    * Copyright (c) 2018 IETF Trust and the persons identified as the
    * document authors. All rights reserved.
    */

The licence itself is not an issue as the original authors' and IETF Trust licences are the same.


** Addressing IESG concerns on TinyMT32 deterministic behavior

PRNG determinism, for a given seed, is a MUST. With Emmanuel Baccelli (new co-author), we:

- tested on several platforms:
  In particular we used embedded 32-bits platforms featuring ARM Cortex M* and running RIOT,
  plus 8-bit and 16-bit platforms (details in Appendix A. "TinyMT32 Validation Criteria (Normative)").
  Note that TinyMT32 is already the default PRNG in RIOT:
  https://github.com/RIOT-OS/RIOT/tree/master/sys/random/tinymt32

- added 3 normative random number sequences:
  These random number sequences MUST be matched for any implementation of
  the PRNG to be validated. The Japanese authors already provide one in:
  https://github.com/MersenneTwister-Lab/TinyMT/blob/master/tinymt/check32.out.txt
  for the core TinyMT32 functions. We added two new ones for the two functions that
  scale down to 4 and 8 bits, whose determinism is as important as that of the core
  functions.

- moved the normative source code to section 3.5. "Pseudo-Random Number Generator (PRNG)"
  in order to avoid any confusion on what is normative and informative.

- removed the dangerous double-float multiplication/divisions.
  Instead we use define two new functions that scale down the uint32 pseudo-random number
  generated by the tinymt32_generate_uint32 () core function to the target 4-bit or
  8-bit interval (used by generate_coding_coefficients()).
  Using masking to scale down a 32-bit PRNG value is **usually a bad practice**, but
  here it works. This is discussed in:
  Appendix B.  Assessing the PRNG Adequacy (Informational)

** About C language style in the original TinyMT32

We cleaned up a few things as suggested.


2- About section 3.1. "Possible Parameter Derivations"
------------------------------------------------------

** We moved all suggestions as "Informational" in Appendix C

  All the 3.1.* sub-sections provide recommendations (hence the use of
  "Possible" in the title).
  It is non normative because doing differently does not break
  interoperability: an encoder and a decoder written by different programmers
  will still interoperate (a decoder has enough information to correctly decode).

  To reflect this, we moved all the 3.1.* sub-sections in an Annex tagged
  as "(informational)". The remaining Section 3.1 merely introduces the main
  parameters and refers to the annex for **possible** parameter derivations.

  NB: already existing FEC Scheme RFCs do not go so far and omit to
         suggest parameter derivation.  


** An additional parameter in the FEC Scheme-Specific Information (FSSI)

  Adding this parameter avoids the ambiguity in the choice of the arbitrary
  0.75 parameter in certain formulas for parameter derivation.

  We add the WSR (window size ratio) parameter, an integer in {0 .. 255}.
  WSR is communicated at session startup along with the FSSI that anyway
  needs to be shared between encoder and decoder(s).
        value 0: ignore         => it's not used because
                there's another technique to derive parameters.
        0 < value < 1:          => use it as follows:
                ew_max_size = dw_max_size * WSR / 255
                e.g. WSR=191 leads to: 191/255=0.749
                191 is suggested as a "reasonable value"
                but no longer recommended since it is anyway
                communicated to the receiver(s).
                Even if there's a rounding "error", it's not a big deal and
                it does not compromize interoperability.


> Le 17 janv. 2019 à 22:12, [e-mail] a écrit :
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group WG of the IETF.
> 
>        Title           : Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME
>        Authors         : Vincent Roca
>                          Belkacem Teibi
>                          Emmanuel Baccelli
> 	Filename        : draft-ietf-tsvwg-rlc-fec-scheme-10.txt
> 	Pages           : 43
> 	Date            : 2019-01-17
> 
> Abstract:
>   This document describes two fully-specified Forward Erasure
>   Correction (FEC) Schemes for Sliding Window Random Linear Codes
>   (RLC), one for RLC over the Galois Field (A.K.A.  Finite Field)
>   GF(2), a second one for RLC over the Galois Field GF(2^^8), each time
>   with the possibility of controlling the code density.  They can
>   protect arbitrary media streams along the lines defined by FECFRAME
>   extended to sliding window FEC codes, as defined in [fecframe-ext].
>   These sliding window FEC codes rely on an encoding window that slides
>   over the source symbols, generating new repair symbols whenever
>   needed.  Compared to block FEC codes, these sliding window FEC codes
>   offer key advantages with real-time flows in terms of reduced FEC-
>   related latency while often providing improved packet erasure
>   recovery capabilities.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-10
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rlc-fec-scheme-10
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>