[Fecframe] review of draft-ietf-fecframe-framework-05

[Vincent Roca <vincent.roca at inrialpes.fr>]

Hello Mark,

I have some comments WRT the fecframe framework 05 document.
However I didn't have time to read the I-D thoroughly (too short
time). Here is the first part, the rest next week hopefully.

Cheers,

  Vincent

----

* Abstract, typo: "This document describes for a framework" -> remove "for"

** Concerning Section 2 "Definitions/Abbreviations"

- 'Transport protocol' is defined as the protocol used for transport of the source data flow.
  This is misleading since it is also used to transport the *repair* data flow.

- 'Application Data Unit' is defined WRT the transport layer. IMHO, the ADU should be defined
  WRT to the application. For instance in draft-roca-fecframe-rs-01.txt, we use the following
  definition:

   Application Data Unit (ADU):  a unit of data coming from (sender) or
      given to (receiver) the media delivery application.  Depending on
      the use-case, an ADU can use an RTP encapsulation.

  I also suggest you add a sentence like: "The Source data flow consist of ADUs" (either here
  or in the definition of 'Source data flow').

- 'FEC Code' mentions it can be used to be resilient to *corruptions*. I understand that
  this definition is for the general case. However it has been clearly stated in Introduction
  that we are only considering the case of erasures. This definition is therefore misleading.

- 'Source Block' is defined as "the group of source data packets which are to be FEC
  protected as a single block".  I have several comments here:
    1- Nowhere the notion of "source data packets" has been defined. I suggest ADU instead
       to highlight the fact it comes from the application.
    2- This is in any case wrong since several FEC schemes also include additional pieces of
       information (ADUI + padding) that are not part of the source data flow, during
       encoding.

  In fact, the "source block" is defined WRT the FEC Code (rather than the Scheme). The
  scheme considers an ADU block, which is then used by the FEC Scheme to define one
  (sometimes several) Source blocks. So I'd rather define the notion of ADU block here.

- FEC Payload ID and the Source|Repair definitions: These three definitions refer to
  packet|source packet|repair packet. The notion of packet is misleading (overloaded)
  and has not been defined previously in any case.

In draft-roca-fecframe-rs-01.txt we define:

   FEC Source Packet:  a data packet submitted to (sender) or received
      from (receiver) the Transport protocol.  It contains an ADU along
      with its optional Source FEC Payload ID, if any.

   FEC Repair Packet:  a repair packet submitted to (sender) or received
      from (receiver) the Transport protocol.  It contains a repair
      symbol along with its Repair FEC Payload ID.

- I think you should add a few definitions directly coming from [RFC5052] for
  clarity (even if the reader of this I-D is supposed to have read RFC 5052 before).
  The definition of a 'Source block' should appear here.
  There's an example in draft-roca-fecframe-rs-01.txt (sorry, the same reference once
  again ;-))


** Section 4:

- it is said:
   "the FEC Framework passes groups of transport packet payloads
   to the FEC Scheme for FEC Encoding."

What does "transport packet payloads" mean? I suggest instead 'ADUs'.
Moreover: Encoding -> encoding.

- I don't like sentence:

   "The FEC Scheme returns FEC
   repair packet payloads, encoded FEC Payload ID information for each
   of the repair packets and, in some cases, encoded FEC Payload ID
   information for each of the source packets."

  I find the wording strange. Additionally use repair rather than encoded in
  "encoded FEC Payload ID". I'd say simply:

   The FEC Scheme returns FEC repair packets (that include the associated
   Repair FEC Payload ID) and FEC source packets (that sometimes include the
   Source FEC Payload ID, depending on the FEC Scheme).

- p.11 and fig 1:
The notion of "transport flow" has not been defined. Use "Source data flow" or
(better IMHO) "ADU flow" instead. And there are many other instances of
"transport flow(s)" in the document...

- p.11:  It is said:
   "From the FEC
   Framework point of view, RTP source flows are sequences of UDP packet
   payloads like any other protocol over UDP."

  It might be another protocol than UDP, right? I know RTP/DCCP has been discussed
  at IETF in the past. I don't know the status.

- p.11, typo: "the the repair payload" -> "the repair payload"

- Fig 1: I suggest you (1) add "example" in the figure caption to highlight the fact
  RTP is not a mandatory part of the architecture and (2) add the "optional" keyword
  in the top RTP box.
  Change "Transport flows" by either Source data flow(s) or ADU flow(s).


** Section 7.

- typos: "recieved", "inaccuate".

- It is said:
    New applications which require such feedback SHOULD use RTP/RTCP
   [RFC3550].

  Isn't "SHOULD" a little bit too strong here? I agree it's a convenient, on the shelf,
  solution, but that's not a sufficient reason I think.


* To finish: the FECFRAME group should probably be thanked too in section 12 ;-)