Forward Error Correction (FEC) Framework Extension to Sliding Window Codes
draft-ietf-tsvwg-fecframe-ext-08

Thanks for the work involved in developing this document. I have only a handful
of editorial comments.

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

Abstract:

>  in a backward compatible way.  During multicast/broadcast real-time

Nit: "...backward-compatible..."

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

§1:

>  the transport or application layer, is an efficient technique to

Nit: remove comma

>  separately defined FEC schemes.  Any CDP defined according to the

Nit: "...separately-defined..."

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

§2:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].
>
>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>  "OPTIONAL" in this document are to be interpreted as described in BCP
>  14 [RFC2119] [RFC8174] when, and only when, they appear in all
>  capitals, as shown here.

It is not necessary to include boilerplate from both RFC 2119 and RFC 8174.
Please remove the first of these two paragraphs.

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

§3:

>  an ADU to symbols mapping process that is FEC Scheme specific (see

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

"...FEC-Scheme..."

>  symbols.  After source symbol to ADU mapping, when lost ADUs are

"...source-symbol-to-ADU..."

>  o  ADUs to source symbols mapping: in order to manage variable size

"...ADUs-to-source-symbols..."

>     FEC Scheme dependant and must be defined in the associated

"...FEC-Scheme-dependent..."
(note both insertion of hyphens and spelling of "dependent")

>     prepended with a flow identifier (1 byte) during the ADU to source
>     symbols mapping (see above).  The flow identifiers are also shared

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

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

§4.2:

>       ADU to source symbols mapping as well as the encoding window

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

>       and MUST be detailed there.  Appendix A provides non normative

"...non-normative..."

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

Appendix A:

>  new ADU is available at the sender, after the ADU to source symbol

"...ADU-to-source-symbol..."

Just a nit: 

§3: "The possibility of having feedbacks from receivers(s) is considered out of scope, although such a mechanism may exist within the application (e.g., through RCTP control messages);"

Should RCTP be RTCP?

I tried to deduplicate my comments with the ones already in the
datatracker.

Section 1

It seems like the executive summary of this document would be "now you can
allocate FEC Encoding IDs that use sliding windows".  It might be helpful
to mention explicitly that the use of a sliding window is indicated through
the Encoding ID, with no other signaling.

Section 2

It might be helpful to indicate that a Payload ID includes positional
information as opposed to just content-type information.


Thank you for providing the summary in Section 3!

Section 5.3

   o  MUST define the management of the decoding window, consisting of a
      system of linear equations (in case of a linear FEC code);

I don't think this is the right way to phrase things; it implies that the
system of linear equations is always the information needed to manage the
decoding window, then trying to walk back that statement in a
parenthetical.  It seems better to just state the hard requiremnt for
window management, and make a separate sentence for what this means in the
linear system case.

Section 10

While I agree with the claim that the the security considerations are
basically unchanged for block-based and sliding-window FEC schemes, I do
find the security considerations of RFC 6363 to be slightly lacking.
In particular, its list of possible attack goals seem to omit some
possibilities that come up pretty often, like trying to corrupt source
flows to modify the receiver application's behavior (as opposed to just
denying service) and the arguably degenerate attack of just dropping lots
of traffic (for denial of service).
It's unclear that any of these are significant enough to merit specific
mention in this document, though.

Section 13

              This document being an extension to [RFC6363], the authors
   would also like to thank Mark Watson as the main author this RFC.

nit: "main author of that RFC" (noting in particular the "that", since
the "of" was already mentioned)

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.