Subject: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-fecframe-ext-06: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Tue, 09 Oct 2018 16:07:31 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-tsvwg-fecframe-ext-06: 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-fecframe-ext/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4332

COMMENTS
S 1.
>      However [RFC6363] only considers block FEC schemes defined in
>      accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681],
>      [RFC6816] or [RFC6865]).  These codes require the input flow(s) to be
>      segmented into a sequence of blocks.  Then FEC encoding (at a sender
>      or an encoding middlebox) and decoding (at a receiver or a decoding
>      middlebox) are both performed on a per-block basis.  This approach

This text could probably be clearer. I think what this means is that
say you have a flow that's a sequence of symbols S_1..... S_n and then
you segment it into a set of blocks (E.g., S_1...S_b, S_b+1.. S_n) and
then each block is separately encoded into a set of packets with its
own FEC. And that that's bad. Is that correct?

S 2.
>      The following list of definitions and abbreviations is copied from
>      [RFC6363], adding only the Block/sliding window FEC Code and
>      Encoding/Decoding Window definitions (tagged with "ADDED"):
>   
>      Application Data Unit (ADU):  The unit of source data provided as
>          payload to the transport layer.

It would be helpful to give an example. I am assuming that I should be
thinking something like "compressed video frame"?

S 3.
>   
>      The FECFRAME architecture is illustrated in Figure 1 from the
>      sender's point of view, in case of a block FEC Scheme.  It shows an
>      application generating an ADU flow (other flows, from other
>      applications, may co-exist).  These ADUs, of variable size, must be
>      somehow mapped to source symbols of fixed size.  This is the goal of

Is the requirement that the source symbols be of fixed size just a
simplification? It's not a generic requirement of ECCs, right?

S 4.3.
>      4.  The FEC Scheme uses the received FEC Payload IDs (and derived FEC
>          Source Payload IDs when the Explicit Source FEC Payload ID field
>          is not used) to insert source and repair packets into the
>          decoding window in the right way.  If at least one source packet
>          is missing and at least one repair packet has been received and
>          the rank of the associated linear system permits it, then FEC

This bit about the rank of the linear system seems kind of like
misplaced concreteness for a framework document.