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

From: "Watson, Mark" <[email-masked]>
Date: Fri, 5 Mar 2010 14:46:15 -0800

Vincent,

Thanks for the detailed review. My responses are below. I will submit an -06 draft shortly.

...Mark

On Jan 8, 2010, at 1:23 PM, Vincent Roca wrote:

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

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

Suggest: "The protocol used for transport of the source and repair data flows"

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

How about: "The unit of source data provided as payload to the transport layer"

The problem I see with your definition is that the boundary of "media delivery application" is not clear.

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

Ok

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

Suggestion: "An algorithm for encoding data such that the encoded data flow is resiliant to data loss (Note: in general FEC Codes may also be used to make a data flow resiliant to corruption, but that is not considered here)."

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

Ok

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

I agree that there could be some confusion because for some codes the Source Blocks from the point of view of the code are subsets of the Source Block as defined here. My concern with changing the terminology is that this terminology is used outside this document as well and I'm not confident we will be able to find all the occurrences which need updating and do that in a coordinated manner.

I think here we will just have to be careful when defining FEC Schemes to avoid the term "Source Block" for the systematic part of a codeword when it does not coincide with the FECFRAME Source Block, or just be careful to define clearly.

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

Ok, I suggest the following minor rewording:

FEC Source Packet: At a sender (resp. receiver) a payload submitted to (resp. received from) the Transport protocol containing an ADU along with an optional Source FEC Payload ID.

FEC Repair Packet: At a sender (resp. receiver) a payload submitted to (resp. received from) the Transport protocol containing one or more repair symbols along with a Repair FEC Payload ID and possibly an 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.
>

Ok, I added the same ones as in your draft.

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

Ok.

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

Ok - I think this was just missed when the ADU term was introduced.

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

Ok.

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

Ok.

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

Ok, and I will add a definition for ADU flow.

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

I think what is meant is better said as follows: "From the FEC Framework point of view, RTP source flows are ADU flows like any other, with the RTP header included within the ADU".

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

Ok. I will replace "parity bytes" with "repair data"

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

I'd prefer that the main architecture was not just an "example" ;-) Otherwise ok.

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

Ok.

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

Ok.

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

I suggest adding the following: "FEC Schemes MAY define limitations on this mapping, such as maximum size of source blocks, but SHOULD NOT attempt to define specific mappings."

What is stated is that the CDP or implementations are responsible for defining the mapping of ADUs to Source Blocks. This is as it should be since this mapping is very application-dependent and FEC Schemes are supposed as far as possible to be application independent. But this is all recommendation strength, since FEC Schemes will vary in their generality and some might be quite specific to particular applications.

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

Ok.

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

Ok.

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

Ok.

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

Yes, it should be "repair RTP payloads", though unfortunately that will not fit in the diagram. I hope "repair payloads" is sufficient.

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

Actually, Step 4 describes processing done by the FEC Scheme. Or do you mean that the Framework and Scheme together perform these functions, rather than forwarding received ADUs directly to the applications possibly out-of-order ? I suggest adding "Note that the description above defines functionality responsibilities but does not imply a specific set of timing relationships. For example, ADUs may eb provided to the application as soon as they are received or recovered (and hence potentially out-of-order) or they may be buffered are delivered to the application in-order."

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

Well, this gets into implementation: the FEC Framework is not a software component and implementations are possible where there is no component corresponding to the FEC Framework itself (the functions would be integrated with application packet handling. So I don't think it makes sense to talk about packets being "kept in the FEC Framework" - we are just defining functional components here.

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

Ok.

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

Ok.

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

I don't think the description implies anything about buffering or where it takes place. It describes functions that are performed. Obviously you need input data for those functions, but whether and where that is stored is not described (for example, there may be an implementation where the received source symbols can be processed as they arrive and only the result of some source symbol computations needs to be stored in order to make later use of repair data).

>
> ** Section 6:
>
>
> I didn't read, sorry.
>
>
> ** Section 7:
>
>
> - typos: "recieved", "inaccuate".

Ok

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

I don't have an opinion, but I think this was discussed and we agreed to recommend RTP/RTCP. SHOULD is not really all that strong since the formal definition is essentially "MUST unless you have a good reason" - so we are just saying don't use an alternative for no good reason.

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

Me too, but it was not my proposal or preference to have this option ...

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

Ok!

>
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe