[tsvwg] Adam Roach's No Objection on draft-ietf-tsvwg-rlc-fec-scheme-09: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-tsvwg-rlc-fec-scheme-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/



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