Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME
draft-ietf-tsvwg-rlc-fec-scheme-16

Posted related IPR disclosure: Code On Network Coding LLC (As Exclusive Licensee of Patents declared below and originally filed by NUIMaynooth and MIT )'s Statement about IPR related to draft-ietf-tsvwg-rlc-fec-scheme

Posted related IPR disclosure: Code On Network Coding LLC (As Exclusive Licensee of Patents declared below and originally filed by NUIMaynooth and MIT )'s Statement about IPR related to draft-ietf-tsvwg-rlc-fec-scheme

Posted related IPR disclosure: Code On Network Coding LLC (As Exclusive Licensee of Patents declared below and originally filed by California Institue of Technology)'s Statement about IPR related to draft-ietf-tsvwg-rlc-fec-scheme

Posted related IPR disclosure: Code On Network Coding LLC (As Exclusive Licensee of Patents declared below and originally filed by MIT)'s Statement about IPR related to draft-ietf-tsvwg-rlc-fec-scheme

[Ballot comment]
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!

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.

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.

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.

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

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.

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 [])?

                                      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)

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.

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?

Appendix A

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

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

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.

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.

[Ballot discuss]
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 ” be added (for the memset).

** The final return in Section 3.6 is missing a semicolon:
s/return 0/return 0;/

[Ballot comment]
(1) Section 3.5  Is there any guidance that needs to be provided on the value of the seed to tinymt32_init?

(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/

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

(4) Other References Nits
Section 1.  Please include a reference for FECFRAME on first introduction.
Section 1.1.  What is the reference for Raptor/RaptorQ?

(6) Editorial Nits
Abstract.  No references are permitted in the abstract
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/

[Ballot comment]
Thanks for resolving the copyright issue.

I would prefer to see the Coding Coefficients Generation Function specified normatively in text and not only as code.

[Ballot comment]
Thanks for resolving the copyright issue.

I would prefer to see the Coding Coefficients Generation Function specified normative in text and not only as code.

Putting this back on the IESG agenda as a returning item, now that the normative dependency on the PRNG is also in IESG evaluation. This requires some ballot positions from "new" ADs.

[Ballot comment]
What is the status of interoperable implementations for this specification, and is there any operational experience? Implementation Status section shows one prototype implementation - is there any other running code, has any interoperability validation been done?

[Ballot discuss]
Thank you for making updates in response to the secdir review; they do
help.

That said, while I think this is a useful technology to specify and a clear
improvement over the existing block-based schemes, this document still has
several flaws that need to be fixed before it is ready for publication.

Most notably, it is internally inconsistent in several places, about
whether bitrate must be fixed or can vary, or whether the encoding/decoding
window size ratio is 3/4, or whether the encoding window size only changes
during startup as new ADUs are added to reach the max encoding window size,
etc.  I attempt to note these in my COMMENTs (noting that they were written
as I go through the document and I may not have caught all the places where
text later in the document clarifies the situation).

It's also implied but not entirely clear that the C code is part of the
normative algorithm specification, and the C code itself incurs
implementation-defined behavior (so as to not be usable as a deterministic
protocol standard element), as Ekr notes.

The recommendation to bound ls_max_size in section 3.1.1 does not seem
strong enough to allow this scheme to meet its stated constraints for
maximum latency, since solving very large linear systems can exceed the
provisioned timeslot.

The SDP encoding for the fssi parmeter should explicitly state that the
name value "E" is used to convey the E parameter.

Multi-byte integer protocol fields need to specify the endianness of
encoding (i.e., network byte order).  (E.g., for ESI and E values.)

The security considerations need to be checked about whether only DoS or
data corruption is possible in a few situations.

(More details on almost all of these in the COMMENT section.)

[Ballot comment]
Section 1.1

  With FECFRAME, there is a single FEC encoding point (either a end-
  host/server (source) or a middlebox) and a single FEC decoding point
  (either a end-host (receiver) or middlebox).  [...]

"single decoding point" seems inconsistent with "multicast/broadcast"

  size, the higher the robustness (e.g., in front of long packet
  erasure bursts), but also the higher the maximum decoding latency

Is this supposed to be "in the face of" instead of "in front of"?

Section 1.2

  This document introduces two fully-specified FEC Schemes that follow
  a totally different approach: [...]

The first time I read this I parsed it as "totally different from each
other", as opposed to "totally different from the existing block codes".

Section 2

It seems like a potentially artificial limitation to assume constant
input/output bitrate.

Section 3.1

  Maximum FEC-related latency budget, max_lat (in seconds) with real-
  time flows:

A reader might assume that this is limited to an integral number of
seconds, which seems like an artifical limitation.  Omitting the
parenthetical might actually be an improvement, as whatever mechanism is
used to specify the limit would necessarily include units.

                                                              For
      instance, at session start, upon receiving new source ADUs, the
      ew_size progressively increases until it reaches its maximum
      value, ew_max_size.  [...]

This seems to preclude the window shrinking due to ADUs aging out.  Under
the constant bitrate assumption this is justified, but a somewhat
artificial limitation.

  Symbol size, E (in bytes):  the E parameter determines the source and
      repair symbol sizes (necessarily equal).  This is an input
      parameter that enables a FECFRAME sender to derive other internal
      parameters, as explained below.  An implementation at a sender
      SHOULD fix the E parameter and communicate it as part of the FEC
      Scheme-Specific Information (Section 4.1.1.2).

Under what condition would a sender not fix the E parameter?  (That is, why
is this a SHOULD and not a MUST?  The communication in FEC Scheme-Specific
Information is clearly a SHOULD, though.)

                              The source ADU flow may be a Constant
  Bitrate (CBR) or Variable BitRate (VBR) flow.  The flow's minimum/
  maximum bitrate might or might not be known.  The FEC Schemes can

This seems to contradict the previous assumption of constant bitrate,
absent grossly inefficient padding schemes.

Section 3.1.1

                                                  For the FEC Schemes
  specified in this document, in line with [Roca17], the ew_max_size
  SHOULD be computed with:

      ew_max_size = dw_max_size * 0.75

This is just self-citing to a document that itself makes an arbitrary
choice of parameter.  It would seem that the reference should be limited to
something like "being able to reuse analysis from [Roca17]" rather than
attempting to use it as a definitive explanation for this parameter
selection.

  The ew_max_size is the main parameter at a FECFRAME sender.  It is
  RECOMMENDED to check that the ew_max_size value stays within
  reasonnable bounds in order to avoid hazardous behaviours.

Can you provide concrete values or guidelines for "reasonable bounds", or
describe the spectrum of possible hazardous behaviors?

                                                A receiver can then
  easily compute dw_max_size:

      dw_max_size = max_NSS_observed / 0.75

This formula only holds when the "SHOULD" above is adhered to.
It may be more appropriate to just fix this parameter at 0.75 as a property
of this FEC Scheme and not include text admitting the possibility for other
values.  (Other values could be specified later with different FEC encoding
IDs.)

                It is RECOMMENDED to check that the ls_max_size value
  stays within reasonnable bounds in order to avoid hazardous
  behaviours.

It's unclear that this can only be RECOMMENDED, as the time needed to solve
the system is included in the max_lat latency budget (and the encoder does
not necessarily know the details of the decoder system!).

Section 3.1.2

  Beyond these general guidelines, the details of how to manage these
  situations at a FECFRAME sender and receiver can depend on additional
  considerations that are out of scope of this document.

It would be nice to give some indication of what sorts of things might go
into these additional considerations, like the nature of loss along the
path, the computational capabilities of the receiver(s), if the input
bitrate has predictable structure, etc.

Section 3.2

  At a sender, an ADU coming from the application cannot directly be
  mapped to source symbols.  [...]

It might be better to say "is not" than "cannot", as the latter leaves the
reader searching for an explanation which is not yet available, and to some
extent this is just a design choice made in the protocol specification (a
consequence of allowing multiple flows to use the same FEC context).

  ADU can be assigned to the right source flow (note that transport
  port numbers and IP addresses cannot be used to that purpose as they
  are not recovered during FEC decoding).

Please note that the repair packets are going over a different 5-tuple than
the source packets, to help the reader make the connection about the lack
of address/port information.

Section 3.3

This would be a fine place to mention how symbols are numbered/indexed
and forward-reference to Section 4.1.4

Section 3.4

                                                    In order to
  validate an implementation of this PRNG, using seed 1, the 10,000th
  value returned by: tinymt32_rand(s, 0xffff) MUST be equal to 0x7c37.

"seed 1" sounds like an index into an enumerated list; it's probably better
to say "a seed value of 0x00000001".

  This PRNG MUST first be initialized with a 32-bit unsigned integer,
  used as a seed.  The following function is used to this purpose:

      void tinymt32_init (tinymt32_t * s, uint32_t seed);

This seems to imply that the C code is going to be a normative part of the
specification.  Is that intended?

Section 3.5

                                          When DT is between 0 (minimum
  value) and strictly inferior to 15, the average probability of having
  a non zero coefficient equals (DT +1) / 16.

nit: "between 0 (the minimum value) and 14"
nit: "DT + 1"

  With the RLC over GF(2) FEC Scheme (Section 5), m MUST be equal to 1.
  With RLC over GF(2^^8) FEC Scheme (Section 4), m MUST be equal to 8.

I think "is equal to" is more appropriate than "MUST be equal to", here --
it's just a statement of fact.

    * (in) repair_key    key associated to this repair symbol. This
    *                    parameter is ignored (useless) if m=2 and dt=15

'm' of 2 is not defined in this document.  I assume this is supposed to be
"the GF(2) case", i.e., m == 1.

    * (out)              returns an error code

What value indicates success?


The tinymt usage here is "fragile" in a sense that I would not like if I
was performing a code review on this code, namely which successive
invocation gets used for which output coefficient depends on previous
tinymt output values.  That said, the scheme is deterministic (modulo Ekr's
Discuss points), which is the only feature needed for interoperability.

It looks like this tinymt_init() implementation probably generates and
discards enough output to get past the initial highly correlated stage,
though I'd appreciate if that was explictily confirmed.

Section 4.1.1.2

  When SDP is used to communicate the FFCI, this FEC Scheme-specific
  information is carried in the 'fssi' parameter in textual
  representation as specified in [RFC6364].  For instance:

  fssi=E:1400

I think you should explicitly say that this uses the "name" of "E" for the
SDP encoding.

  If another mechanism requires the FSSI to be carried as an opaque
  octet string (for instance, after a Base64 encoding), the encoding

Wouldn't this be *prior to* Base64 encoding, not after?

      Encoding symbol length (E): 16-bit field.

Generally we still say "encoded in network byte order (big-endian)" for
16-bit integer fields.

Section 4.1.3

How does an encoder select repair_key values to put in repair payload IDs?
(I guess Section 6.1 kind-of covers this but does not explicitly say that
it's an arbitrary choice.)

Section 5.1.3

Leaving the encoder the option of setting an arbitrary repair_key for
DT==15 leaves open the possibility of a covert channel and the
corresponding privacy considerations.  Usually we just say "MUST set to
zero on transmission and ignore on receipt" for this sort of thing.

Section 8

  The FEC Framework document [RFC6363] provides a comprehensive
  analysis of security considerations applicable to FEC Schemes.

I would suggest going with "fairly comprehensive" or similarly couched
language; as my review of draft-ietf-tsvwg-fecframe-ext indicates, it is
not a fully comprehensive analysis.

Section 8.2

  o  FEC Encoding ID: changing this parameter leads a receiver to
      consider a different FEC Scheme.  The consequences are severe, the
      format of the Explicit Source FEC Payload ID and Repair FEC
      Payload ID of received packets will probably differ, leading to
      various malfunctions.  Even if the original and modified FEC
      Schemes share the same format, FEC decoding will either fail or
      lead to corrupted decoded symbols.  This will happen if an
      attacker turns value YYYY (i.e., RLC over GF(2)) to value XXXX
      (RLC over GF(2^^8)), an additional consequence being a higher
      processing overhead at the receiver.  In any case, the attack
      results in a form of Denial of Service (DoS);

I think this could lead to undetected data corruption, which is worse than
DoS.  Similarly for the next bullet point.

Section 8.4

I found where RFC 6363 Section 9 claims that the following subsections will
define a mandatory-to-implement security scheme, but not where IPsec/ESP
was actually specified as such.  Can you give me a pointer?

Section 8.5

As with all random matrix algorithms, there is some chance that the
indicated scheme will produce poorly conditioned matrices (i.e., less than
full rank) for the decoder to process.  The coefficient generation scheme
seems to be deterministic and dependent only on the repair_key and DT
values for a given encoding window, so in principle an attacker could
precompute which inputs would produce singular linear systems under given
packet loss conditions.  That said, an attacker able to modify the
transmitted repair_key, DT, and NSS values can affect the system in more
disruptive ways already, so this sort of attack probably doesn't need to be
mentioned here.

Section 9

[same comment about "comprehensive" as for section 8]

Section 9.2

  Note that using a density threshold equal to 15 with RLC over GF(2)
  is equivalent to using an XOR code that compute the XOR sum of all
  the source symbols in the encoding window.  In that case: (1) a
  single repair symbol can be produced for any encoding window, and (2)

I think this may be more clear as "only a single repair symbol can be
produced".  (Also another occurrence earlier in the document?)

Appendix A

(As Ekr notes, the floating-point mode is not specified, so there are
several multiplications/divisions that are not deterministic.)

Appendix B

  Finally, it is worth noting that a good receiver, i.e., 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: I'd use a different phrase than "good receiver", as the relevant
property is of the network path to the receiver and not its (implementation
or other) quality.  Perhaps, "a receiver that does not experience much
packet loss".

[Ballot comment]
I support Mirja's discuss, and extend it to mention that the inclusion of license language other than that in the Trust Legal Provisions (see the copyright notice boilerplate) is generally not allowed in RFCs.

I agree with Ekr's discuss point and Adam's comments about the normative reference for the TinyMT32 PRNG. I hope the answer is not that the code in Appendix A is normative; as Adam mentioned we've learned from experience (RFC 6716) that normative code is sub-optimal for the IETF standards process as it stands today.

[Ballot comment]
I support Mirja's discuss, and extend it to mention that the inclusion of license language other than that in the Trust Legal Provisions (see the copyright notice boilerplate) is generally not allowed in RFCs.

I agree with Ekr's and Adam's comments about the normative reference for the TinyMT32 PRNG. I hope the answer is not that the code in Appendix A is normative; as Adam mentioned we've learned from experience (RFC 6716) that normative code is sub-optimal for the IETF standards process as it stands today.

[Ballot discuss]
I'm really not an expert on legal questions and get easily confused myself but I think just copying in the code including the copyright into the draft appendix leads to conflicting copyright statements, as the all content of the draft has the following copyright:

  Copyright (c) 2018 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

And the code says this:

  * Copyright (c) 2011, 2013 Mutsuo Saito, Makoto Matsumoto,
  * Hiroshima University and The University of Tokyo.
  * All rights reserved.

[Ballot comment]
I support Eric Rescorla's DISCUSS, in particular the portion dealing with
being clear about which instance of the TinyMT32 PNRG is normative.

---------------------------------------------------------------------------

§1.2:

>  The RLC codes belong to the broad class of sliding window AL-FEC

Nit: "...sliding-window..."

---------------------------------------------------------------------------

§3.1.1:

>  For the FEC Schemes
>  specified in this document, in line with [Roca17], the ew_max_size
>  SHOULD be computed with:
>
>    ew_max_size = dw_max_size * 0.75
...
>  A receiver can then
>  easily compute dw_max_size:
>
>    dw_max_size = max_NSS_observed / 0.75

Since the computation of ew_max_size is only "SHOULD" rather than "MUST," it
seems that the sender and receiver can end up with different notions of
ew_max_size. This raises two questions: (1) is such a situation harmful? and (2)
are there valid reasons a sender would compute ew_max_size differently than the
formula above?

If the answer to (1) is "yes" or the answer to (2) is "no", then I think the
"SHOULD" quoted above needs to be a "MUST."

---------------------------------------------------------------------------

§3.3:

>  new ADU arrives, once the ADU to source symbols mapping has been

"...ADU-to-source-symbols..."

---------------------------------------------------------------------------

§3.5:

>  When DT is between 0 (minimum
>  value) and strictly inferior to 15, the average probability of having
>  a non zero coefficient equals (DT +1) / 16.

This language ("strictly inferior to 15") seems odd, as the statement holds
true for DT=15 as well.

>  These considerations apply both the RLC over GF(2) and RLC over

Nit: "...apply to both..."

>      Figure 2: Coding Coefficients Generation Function pseudo-code

It seems a bit odd to call this "pseudocode": except of a handful of missing
definitions (stdint.h, string.h, tinymt32_t, tinymt32_rand, tinymt32_init, and
the success/error return codes), it is syntactically valid C that compiles
just fine.

---------------------------------------------------------------------------

§3.6.2:

"...and + is an XOR operation."

This is confusing. I understand that this is being done in an attempt to
simulate the "⊕" symbol in a document that is limited to ASCII, but the use of
"+" in a mathematical context is so well established that its use to mean
something different than addition runs the risk of implementor confusion.
Since this document uses "^^" for exponentiation, it would appear that the
symbol "^" remains available for XOR. This is consistent with the use of C in
multiple places in the document.

Alternatively, for complete avoidance of doubt, the computation of the repair
buffer could be denoted with:

      repair[i] = cc_tab[0] * src_0[i] XOR cc_tab[1] * src_1[i]
        XOR ... XOR cc_tab[ew_size - 1] * src_ew_size_1[i]

---------------------------------------------------------------------------

§6.1:

>  and several approaches exist that are implementation specific.

Nit: "...implementation-specific."

---------------------------------------------------------------------------

§6.2:

I agree and reiterate Eric Rescorla's concerns regarding this section. While I
understand that it is somewhat beyond the remit of this document to provide
tutorial information about theories of solving high-order systems of linear
equations, references to related materials would seem to be in order, as such
information is normatively required to implement this specification. If an
exemplary algorithm can be provided for solving the specific systems described
in this document, that would be even better (I understand that might not be
practical).

---------------------------------------------------------------------------

Appendix A:

Presuming the code in this appendix is intended to be normative, it needs to
normatively cite the formal language it uses. In this case, that would be C99 or
newer, as prior to C99, initial declarations in for loops were not allowed. I
believe the citation you want is ISO/IEC 9899:1999 (or something newer, such as
ISO/IEC 9899:2011)

Additionally, if the code in this appendix could also be described in prose, it
would make it more accessible (e.g., for non-C implementations) and more
maintainable. One of the lessons learned from publishing normative code as
part of RFC 6716 is that it is clearer and more maintainable to publish
normative prose accompanied by a non-normative reference implementation. See,
e.g., the discussion thread at
https://mailarchive.ietf.org/arch/msg/video-codec/SSdqF3q96WaLsSuYcjmgzLg32S8

I will further note that this arrangement should address the portability issues
that Eric Rescorla has identified in his discuss, as normative prose will
presumably not be subject to portability concerns.

[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3423


I do not believe that this specification is sufficiently precise to be
interoperably implemented.

DETAIL
S 3.4.
>      value, in addition to the maximum FEC-related latency budget
>      (Section 3.1).
> 
>  3.4.  Pseudo-Random Number Generator (PRNG)
> 
>      The RLC FEC Schemes defined in this document rely on the TinyMT32

What is the normative reference here? We can't really plausibly
normatively reference a github link without even a version hash. Is
the code in the appendix the normative description of the algorithm.


S 3.5.
>      These considerations apply both the RLC over GF(2) and RLC over
>      GF(2^^8), the only difference being the value of the m parameter.
>      With the RLC over GF(2) FEC Scheme (Section 5), m MUST be equal to 1.
>      With RLC over GF(2^^8) FEC Scheme (Section 4), m MUST be equal to 8.
> 
>     

Again, is the normative reference here the code? I note that this code
contains references to constants which are not defined here and
therefore will not compile


S 6.2.
>      ew_size coding coefficients that are computed by the same coefficient
>      generation function (Section Section 3.5), using the repair key and
>      encoding window descriptions carried in the Repair FEC Payload ID.
>      Whenever possible (i.e., when a sub-system covering one or more lost
>      source symbols is of full rank), decoding is performed in order to
>      recover lost source symbols.  Each time an ADUI can be totally

You should provide an algorithm for solving this system or at least a
pointer to a description of how to do so


S 12.2.
>    #define TINYMT32_MEXP 127
>    #define TINYMT32_SH0 1
>    #define TINYMT32_SH1 10
>    #define TINYMT32_SH8 8
>    #define TINYMT32_MASK UINT32_C(0x7fffffff)
>    #define TINYMT32_MUL (1.0f / 16777216.0f)

ANSI C doesn't specify any particular method of computing floating
point arithmetic, so I don't believe that any of this code is portably
deterministic.


S 12.2.
>        s->status[0] = s->status[1];
>        s->status[1] = s->status[2];
>        s->status[2] = x ^ (y << TINYMT32_SH1);
>        s->status[3] = y;
>        s->status[1] ^= -((int32_t)(y & 1)) & s->mat1;
>        s->status[2] ^= -((int32_t)(y & 1)) & s->mat2;

You also can't assume that negative numbers have any particular
representation (e.g., twos complement) so this XOR is not
deterministic.

[Ballot comment]
S 3.4.
>      RLC FEC Schemes defined in this document, the following parameter set
>      MUST be used:
> 
>      o  mat1 = 0x8f7011ee = 2406486510;
>      o  mat2 = 0xfc78ff1f = 4235788063;
>      o  tmat = 0x3793fdff = 932445695.

What is the significance of the semicolons versus periods?



S 3.5.
>      * provided with the appropriate number of coding coefficients to
>      * use for the repair symbol key provided.
>      *
>      * (in) repair_key    key associated to this repair symbol. This
>      *                    parameter is ignored (useless) if m=2 and dt=15
>      * (in) cc_tab[]      pointer to a table of the right size to store

This is not just in, because you are writing it. It is rather in/out.


S 3.5.
>                      if (tinymt32_rand(&s, 16) <= dt) {
>                          cc_tab[i] = (uint8_t) 1;
>                      } else {
>                          cc_tab[i] = (uint8_t) 0;
>                      }
>                  }

This code can be simplified either by using the ternary operator, as
in:

```
cc_tab[i] = tinymt32_rand(&s, 16) <= dt) ? 1 : 0;
```

Actually, you could just do:

```
cc_tab[i] = tinymt32_rand(&s, 16) <= dt);
```

Because C guarantees that comparison operators produce 1 for true and
0 for false.


S 3.5.
>                      do {
>                          cc_tab[i] = (uint8_t) tinymt32_rand(&s, 256);
>                      } while (cc_tab[i] == 0);
>                  }
>              } else {
>                  /* here a certain fraction of coefficients should be 0 */

It's not a certain fraction, it's just a certain probability.


S 12.2.
>    *    Erlang", ACM 11th SIGPLAN Erlang Workshop (Erlang'12),
>    *    September, 2012.
>    */
>    #define TINYMT32_MAT1_PARAM    0x8f7011ee
>    #define TINYMT32_MAT2_PARAM    0xfc78ff1f
>    #define TINYMT32_TMAT_PARAM    0x3793fdff

Is there a reason not to have these be const uint32_t?


S 12.2.
>        s->status[0] = seed;
>        s->status[1] = s->mat1 = TINYMT32_MAT1_PARAM;
>        s->status[2] = s->mat2 = TINYMT32_MAT2_PARAM;
>        s->status[3] = s->tmat = TINYMT32_TMAT_PARAM;
>        for (int i = 1; i < MIN_LOOP; i++) {
>            s->status[i & 3] ^= i + UINT32_C(1812433253)

This constant should not be int he code like this.


S 12.2.
>    /**
>    * This function outputs an integer in the [0 .. maxv-1] range.
>    * @param s    pointer to tinymt internal state.
>    * @return      32-bit unsigned integer between 0 and maxv-1 inclusive.
>    */
>    uint32_t tinymt32_rand (tinymt32_t * s, uint32_t maxv)

This casting is extremely scary. Are you sure that this code is
portably deterministic?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tsvwg-rlc-fec-scheme-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the FEC Framework (FECFRAME) FEC Encoding IDs registry on the Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs registry page located at:

https://www.iana.org/assignments/rmt-fec-parameters/

two new registrations will be made as follows:

Value: [ TBD-at-Registration ]
Description: Sliding Window Random Linear Codes (RLC) over GF(2) FEC Scheme for Arbitrary Packet Flows
Refernce: Secction 5 of [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Sliding Window Random Linear Codes (RLC) over GF(2^^8) FEC Scheme for Arbitrary Packet Flows
Refernce: Secction 4 of [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-09-24):

From: The IESG
To: IETF-Announce
CC: tsvwg@ietf.org, draft-ietf-tsvwg-rlc-fec-scheme@ietf.org, wes@mti-systems.com, Wesley Eddy , tsvwg-chairs@ietf.org, David Black , spencerdawkins.ietf@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME) to Proposed Standard


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'Sliding Window Random Linear
Code (RLC) Forward Erasure Correction
  (FEC) Schemes for FECFRAME'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-09-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

It is intended for Proposed Standard, and Standards Track is indicated in the header.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes two fully-specified Forward Erasure
  Correction (FEC) Schemes for Sliding Window Random Linear Codes
  (RLC), one for RLC over GF(2) (binary case), a second one for RLC
  over GF(2^^8), 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.  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.

Working Group Summary

This document is a companion to draft-ietf-tsvwg-fecframe-ext, which is an update to the FECFRAME work in RFC 6363.  RFC 6363 was a product of the former FECFRAME working group, which closed several years ago.  FECFRAME was in the TSV area.  When several original FECFRAME participants proposed updates/extensions to support new types of codes (with benefits for some real world applications), between the Area Directors and the TSVWG, it was agreed that the work should be done in TSVWG, and two documents including this one were adopted.  Several FECFRAME participants are either authors/editors listed on the documents, or participated in reviews.  Other than this history, there were no other significant issues or events of interest in the working group process on this document.


Document Quality

There have been implementations.  The implementations were reported to the working group, and the documents benefited from the implementation and testing experience.


Personnel

The document shepherd is Wesley Eddy (wes@mti-systems.com), and the responsible AD is Spencer Dawkins.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document has been fully reviewed, and is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

N/A.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, both authors have confirmed that no IPR disclosures need to be made from their institute.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures apply to this document.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The subset of the working group that is interested in FECFRAME seems to have consensus on the document.  The document has also been a topic of discussion in the IRTF Network Coding Research Group since this is a FEC technology, and there does not appear to be any contention there.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

N/A.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are no actual idnits errors or issues.  There are a few spurious idnits notes/warnings, that are related to code lines in the document, rather than actual text.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A


(13) Have all references within this document been identified as
either normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.  All normative references are Proposed Standard or BCP.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

N/A


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations are complete.  Two new values are requested from an existing registry.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A - There are some snippets of C code, but I did not extract or compile it (it is not a self-contained program, and is for example / informational reference, rather than normative text in the standard).