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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 29 May 2019 04:33 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF48E120019; Tue, 28 May 2019 21:33:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-tsvwg-rlc-fec-scheme@ietf.org, Wesley Eddy <wes@mti-systems.com>, David Black <david.black@dell.com>, tsvwg-chairs@ietf.org, wes@mti-systems.com, tsvwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.97.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <155910443990.25705.3545445265076552985.idtracker@ietfa.amsl.com>
Date: Tue, 28 May 2019 21:33:59 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/EkHxmtcFTVkX-7pF9elBB_1A1Sg>
Subject: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-rlc-fec-scheme-14: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 04:34:00 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tsvwg-rlc-fec-scheme-14: 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:


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

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}.  [...]


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

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.