Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-07.txt

From: [email-masked]
Date: Fri, 04 Jan 2019 06:37:28 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group WG of the IETF.

        Title           : Forward Error Correction (FEC) Framework Extension to Sliding Window Codes
        Authors         : Vincent Roca
                          Ali Begen
	Filename        : draft-ietf-tsvwg-fecframe-ext-07.txt
	Pages           : 21
	Date            : 2019-01-04

Abstract:
   RFC 6363 describes a framework for using Forward Error Correction
   (FEC) codes to provide protection against packet loss.  The framework
   supports applying FEC to arbitrary packet flows over unreliable
   transport and is primarily intended for real-time, or streaming,
   media.  However FECFRAME as per RFC 6363 is restricted to block FEC
   codes.  This document updates RFC 6363 to support FEC Codes based on
   a sliding encoding window, in addition to Block FEC Codes, in a
   backward-compatible way.  During multicast/broadcast real-time
   content delivery, the use of sliding window codes significantly
   improves robustness in harsh environments, with less repair traffic
   and lower FEC-related added latency.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-fecframe-ext-07
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-fecframe-ext-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-fecframe-ext-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Vincent Roca <[email-masked]>
Date: Fri, 4 Jan 2019 15:51:17 +0100

Dear all,

You’ll find below an update of the FECFRAME extension I-D, taking into account IESG comments.

At the end of this email you’ll find explanations on how we addressed IESG comments.
This is a concatenation of https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ballot/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ballot/>
with "[Authors]" tagged answers. If this is a bit long, however there is no major modification.

Cheers,

  Vincent and Ali

> =====================================================================
> Spencer Dawkins Yes
> Comment (2018-10-01)
>
> These are a couple of minor items that weren't worth delaying IESG Evaluation for the draft, but just so you know about them along with anything else you hear during IESG Evaluation ...
>
>  Checking nits according to https://www.ietf.org/id-info/checklist :
>   ----------------------------------------------------------------------------
>
>   -- The draft header indicates that this document updates RFC6363, but the
>      abstract doesn't seem to directly say this.  It does mention RFC6363
>      though, so this could be OK.
>
> I don't feel strongly about asking you to change this to "this document updates RFC 6363" in the abstract, but tastes differ. I find the current phrasing clear for human readers, but I've heard rumors that some people scrape Abstracts looking for specific text. I'll trust you to do the right thing.

[Authors] I've added this magic: "this document updates RFC 6363" text in abstract.

> In Section 2. when you add the new boilerplate, you delete the old one, so
>
> OLD
>
>   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.
>
> NEW
>
>    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.

[Authors] Sure, this is a stupid mistake. Done.

> In 13.  Acknowledgments, it looks like there's a missing "of"
>
>    The authors would like to thank Christer Holmberg, David Black, Gorry
>    Fairhurst, and Emmanuel Lochin for their valuable feedbacks on this
>    document.  This document being an extension to [RFC6363], the authors
>    would also like to thank Mark Watson as the main author this RFC.
>                                                           ^ of

[Authors] Done. Also added IESG members who provided comments to the acknowledgments.

> =====================================================================
> Ben Campbell No Objection
> Comment (2018-10-10)
>
> 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?

[Authors] Yes, of course. Fixed.

> =====================================================================
> Benjamin Kaduk No Objection
> Comment (2018-10-10)
>
> 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.

[Authors] Yes for the executive summary (hard to be more concise). Following your
advice, I've added a new bullet. However I omit "with no other signaling",
since this FEC Encoding ID is not repeated in each packet header but
communicated in a session description that must be signaled to the receivers
in some way.

NEW:
   This document is fully backward compatible with [RFC6363].  Indeed:

   o  this FECFRAME update does not prevent nor compromise in any way
      the support of block FEC codes.  Both types of codes can nicely
      co-exist, just like different block FEC schemes can co-exist;

   o  each sliding window FEC Scheme is associated to a specific FEC
      Encoding ID subject to IANA registration, just like block FEC
      Schemes;

   [...]

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

[Authors] Done (BTW, the current definition is a carbon copy of RFC 6363).

NEW:
   FEC Payload ID:  Information that identifies the contents and
       provides positional information of a packet with respect to the
       FEC Scheme.

> Thank you for providing the summary in Section 3!

[Authors] You're welcome. I always felt it was missing in RFC 6363!

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

[Authors] You're right. It's now split into two sentences.

NEW
   o  MUST define the management of the decoding window. This usually
      consists in managing a system of linear equations (in case of a
      linear FEC code);

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

[Authors] I agree with the first goal (modify application's behavior), but think
the second one (dropping lots of traffic) is covered by the "compromise the
receiver's behavior" item.

NEW:
 However, for the sake of completeness, the following goal can be added
 to the list provided in Section 9.1 "Problem Statement" of [RFC6363]:

   o  Attacks can try to corrupt source flows in order to modify the
      receiver application's behavior (as opposed to just denying
      service).

It's better to do that here (rather than just in the RFLC I-D) since it
equally applies to block and sliding window codes.

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

[Authors] Fixed. Okay for this vs. that distinction!

> =====================================================================
> Eric Rescorla No Objection
> Comment (2018-10-09)
>
> 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?

[Authors] Yes.

NEW:
   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. For instance if
   the current block encompasses the 100's to 119's source symbols
   (i.e., block of size 20 symbols) of an input flow, encoding (and
   decoding) will be performed on this block independently of other
   blocks.

> 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"?

[Authors] Good idea, here is my proposal:

NEW:
   Application Data Unit (ADU):  The unit of source data provided as
       payload to the transport layer. For instance, it can be a
       payload containing the result of the RTP packetization of a
       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?

[Authors] It's a fundamental requirement of any block or sliding window FEC Scheme.

NEW:
   These ADUs, of variable size, must be
   somehow mapped to source symbols of fixed size (this fixed size is a
   requirement of all FEC Schemes that comes from the way mathematical
   operations are applied to symbols content).

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

[Authors] Agreed.

NEW:
       If at least one source packet
       is missing and at least one repair packet has been received, then
       FEC decoding is attempted to recover missing source payloads.

> =====================================================================
> Adam Roach No Objection
> Comment (2018-10-09)
>
> 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..."

[Authors] Done.

> ---------------------------------------------------------------------------
>
> §1:
>
> >  the transport or application layer, is an efficient technique to
>
> Nit: remove comma

[Authors] Done.

> >  separately defined FEC schemes.  Any CDP defined according to the
>
> Nit: "...separately-defined..."

[Authors]  Done.

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

[Authors] Done. It was indeed a stupid mistake.

> ---------------------------------------------------------------------------
>
> §3:
>
> >  an ADU to symbols mapping process that is FEC Scheme specific (see
>
> "...ADU-to-symbols..."

[Authors] Done.

> "...FEC-Scheme..."

[Authors] Done.

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

[Authors] Done.

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

[Authors] Done.

>
> >     FEC Scheme dependant and must be defined in the associated
>
> "...FEC-Scheme-dependent..."

[Authors] Done.

> (note both insertion of hyphens and spelling of "dependent")

[Authors] Done.

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

[Authors] Done.

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

[Authors] Done.

>
> ---------------------------------------------------------------------------
>
> Appendix A:
>
> >  new ADU is available at the sender, after the ADU to source symbol
>
> "...ADU-to-source-symbol..."
>

[Authors] Done.