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

From: Vincent Roca <[email-masked]>
Date: Fri, 08 Jan 2010 22:23:31 +0100

Mark, all,

Here is a review of draft-ietf-fecframe-framework-05.
It *includes and replaces* the comments I've sent at
the end of October.

Cheers,

     Vincent

** Abstract:

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

** Section 2:

- '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: "Data used
   as the payload for the transport layer". This is misleading, since in
   a FECFRAME system, the transport layer will also carry repair symbols.
   IMHO, the ADU should be defined WRT to the application, e.g.:

    Application Data Unit (ADU):  at a sender (resp. receiver), a unit of
       data coming from (resp. given to) 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 consists
   of ADUs" (either here or in the definition of 'Source data flow').

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

- 'Source Block' is defined as "the group of source data packets which
   are to be FEC protected as a single block". But nowhere the notion of
   "source data packets" has been defined. I suggest to refer to ADUs
   instead.

   IMHO the term "source block" is confusing because it's overloaded.
   It is primarily a term used by FEC codes (i.e. a set of source symbols
   over which FEC encoding takes place). Using the same term in the
   context of the FEC framework creates confusion, especially as some
   FEC Schemes may define several source blocks from a single ADU block
   (e.g. our Reed-Solomon I-D).

   For clarification purposes I suggest to use the term of ADU block in
   this I-D and to keep the traditional meaning of "source block".
   If you agree, there are many locations (e.g. section 5 and 6) that
   refer to source blocks.

- FEC Payload ID and the Source|Repair FEC Payload IDs: These three
   definitions refer resp. to packet|source packet|repair packet. But the
   notion of packet has not been defined. I suggest to add:

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

    FEC Repair Packet:  at a sender (resp. receiver) a repair packet 
submitted
       to (resp. received from) the Transport protocol. It contains a repair
       symbol along with its Repair FEC Payload ID and possibly RTP header.

- IMHO you should add a few definitions coming from [RFC5052] for
   clarity. E.g. 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 ;-)) where we split definitions between those that
   are FEC Scheme specific and those that are FEC Framework specific.
   I think it would help.

** Section 4:

- p.10, end of 1st paragraph: I don't understand the sentence:
    "In this case the interface to the FEC Framework, at
     least for the repair flows, can be thought of as equivalent to that
     between RTP and users of RTP."

   Which "interface to the FEC Framework" does it refer to? The one with
   overlying protocols (e.g. RTP) or the one with underlying ones (e.g.
   UDP)? In any case FEC repair packets with RTP framing won't reach the
   application, so I don't see the relationships with the "users of RTP".
   I suggest to remove the sentence altogether.

- p.10: 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.

- p.10: In 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."

   "encoded FEC Payload ID" -> "repair FEC Payload ID".
   I also suggest to simplify a bit (see comment for Fig. 2 concerning
   the use of "repair symbol"):

    "The FEC Scheme returns repair symbols with their associated
     Repair FEC Payload ID, and in some case the Source FEC Payload ID,
     depending on the FEC Scheme."

- p.10: there is no reason to use "'" in the following sentence since
   Source data flow and Repair data flow have been formally defined in
   Section 2.
    "... and the
     relationship(s) between these 'source' and 'repair' flows..."

- 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 that need to be
   corrected.

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

- p.11, typo: "the the repair payload" -> "the repair payload".
   And in the same sentence, *repair* data is not necessarily *parity*
   data. It depends on the FEC code being used. The term "parity" appears
   two other times in this paragraph.

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

** Section 5:

- Section 5.1 p.14: you refer to "encoded FEC Payload IDs" with both
   FEC source and repair packets. By "encoded" I understand that it is
   stored in a FEC Scheme specific format that does not have to be
   understood by the FEC Framework. I'd rather say in the two bullets
   something like:

   o  optionally, FEC Payload IDs (encoded according to a FEC Scheme
      specific format) for each of...

- a detail, p14: "source Application Data Units" -> "Application Data Units"
   (it's sufficient).

- Section 5.1 says that a CDP MAY define the mapping between ADUs and
   a source block (I prefer "an ADU block" as said above).
   You should also say that a FEC Scheme MAY also define this mapping,
   or at least provide some rules (e.g. a limit on the maximum source
   block size (k) which will limit the maximum ADU block size).
   More generally, the CDP versus FEC Scheme responsibilities in terms
   of what is defined where are not clear, at least for me.

- Section 5.2, bottom of p.16:
     "...on the eventual IP FEC Source Packet..."
   What is an IP FEC Source Packet? I guess you mean "an IP datagram
   carrying a FEC source packet".

- Fig. 2: What is the "Repair transport payload"?  This is not defined
   in section 2. I guess this payload plus the Repair FEC Payload ID form
   the transport payload.
   I suggest you use the term "repair symbol" (which should be
   defined in Section 2 too) instead.

- Fig. 3: Similarly, I don't like "Repair RTP payloads" since this
   name refers to the RTP box below rather than to the FEC Scheme that
   produced this unit of data. I'd rather say: "repair symbol".

   And another remark: step 6 creates the FEC repair packet, but RTP
   framing happens later, after step 7'.
   In my understanding, an FEC repair packet already includes the RTP
   header, isn't it?

- Section 5.3, step 4:
   The algorithm that is described is the one where all the ADUs of an
   ADU block are kept by the FEC framework until it is known that either
   all the ADUs are available (received or decoded), or that no additional
   FEC repair packet will be received for this block in case one or several
   ADUs are missing. This technique corresponds to the strategy where
   the FEC framework performs buffering and in-order delivery of the
   available ADUs to the application (discussion of section 5.1). This
   should be clearly mentioned.

   Additionally, step 4 requires that the received FEC source and repair
   packets be kept in the FEC framework during (at most) the ADU block
   reception duration. This is not mentioned explicitly. I'd like to
   see a loop somewhere in this description.

   In step 5 there a missing final "s" in Units, 1st line.

- Section 5.3, p.21:
   Instead of "source packets" or "original source packets", you should
   use ADUs.

   Additionally:
   The way this paragraph is currently written is strange since what
   you say in the last sentence ("Alternatively, buffering...") is
   exactly what has been detailed before in the algorithm.
   I suggest you just explain here that other strategies are possible
   that do not necessarily rely on buffering unlike what has been presented
   just before. But in any case the FEC framework/scheme usually needs to
   keep a copy of the FEC source/repair packets of the current block (for
   decoding purposes), even if ADUs are given to the application as soon as
   possible.

** Section 6:

I didn't read, sorry.

** 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 alternatives may exist.

** Globally, I have the feeling that the use of RTP for the repair data
   flow is not sufficiently motivated. There's a small paragraph in the
   introduction to say that a motivation is to use "RTP instrumentation".
   Later on, in section 4 (Architecture), it is said that the source and
   repair data flows can be multiplexed on the same UDP flow (1st 
paragraph).
   There are two additional paragraphs in section 4 to explain what the
   RTP repair data packet consists in and the fact it's decoupled from the
   source data flow.

   I'd like to see a sub-section that explains clearly, in a single place,
   all the motivations for using an RTP framing with repair packets
   (in particular the backward compatibility benefits, the possibility
   to multiplex the various flows on the same UDP flow, etc.).

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