Subject: [Fecframe] Review of draft-ietf-fecframe-framework-03

From: Vincent Roca <[email-masked]>
Date: Fri, 03 Apr 2009 14:22:37 +0200

Mark, everybody,

Since the goal was to start a WGLC on the framework document, I anticipated
a little bit the announce... (sorry if it creates problems).
Here are my comments.

Regards,

   Vincent
Comments to draft-ietf-fecframe-framework-03 - VR
-------------------------------------------------

For discussion...

1/ Terminology:
---------------
The terminology is not sufficiently well defined and throughout the text we
find several terms for the same concept (I won't list them here). I tried to
compile them below.

At the sender, from top to bottom:
* the application layer provides "Source Transport Data Payloads"
  through one or several "Source Data Flow(s)".
* the "Source Transport Data Payloads" are gathered in a "Source Block".
* after the F, L and padding fields have been added to each "Source Transport
  Data Payload" for the purpose of FEC encoding, the resulting unit of data
  is called the "Source Packet Information (SPI)"
  (NB: this comes from the Raptor I-D).
* from the FEC scheme point of view, we now have "Source Symbols" (i.e., a
  subset of the "Source Packet Information") and "Repair Symbols". They are
  globally called "Encoding Symbols".
* the unit of data containing the source information, plus the "Explicit
  Source FEC Payload ID" (if used), is now called the "FEC Source Packet".
  It is given to the transport protocol.
* the unit of data containing repair information, plus the "Repair FEC
  Payload ID", is now called "FEC Repair Packet". It can contain one or more
  "repair symbols" depending on the FEC scheme. It is given to the transport
  protocol.

We should discuss the above names IMHO...

In particular I'm not satisfied by the "Source Transport Data Payloads"
which follows the transport protocol point of view (payload given to the
transport protocol) rather than what leaves the application layer.
Additionally, it's no longer the transport payload if the "Explicit Source
FEC Payload ID" is appended by the FEC framework.
I suggest: "Application Source Data Units", or simply "Application Data Units".

There is also a clash between the "Source Packet Information" and the
"Source Transport Data Payload". The two names should be close to one another.
I suggest: "Application (Source) Data Unit Information"

I think that, inside the FEC scheme itself, the usual terminology
(source/repair/encoding symbols) must be used. This is common terminology
with the FEC schemes coming from the RMT WG.

Then we must make sure that the agreed terminology, and only it, is used in
this I-D and others.

2/ Section 6.5. "FEC Framework Configuration Information"
---------------------------------------------------------
I have several comments WRT the pieces of information included in the FFCI.

2.1/ It is said: 
"      1.  Identification of the packet flow(s) carrying FEC Repair
      packets, known as the FEC repair flow(s)."
I think we need more than just an identification. We need to know the
*number* of FEC repair flows for this FEC framework instance and  the
*definition* of each FEC repair flow (e.g., the associated tuple).

2.2/ It is said:
"        b.  An integer identifier for this flow definition (i.e.
         tuple).  This identifier MUST be unique amongst all source
         packet flows which are protected by the same FEC repair flow."
So, if I follow this text, if a source flow is protected by 2 FEC repair
flows, this source flow can be assigned two different identifiers. This is
a bit strange! I suggest that the identifier be unique among a FEC
framework instance. The drawback I see, however, when this identifier is
encoded in a single byte (e.g. Raptor or R-), is the limited number (256) of
source data flows that can be protected globally. But is 256 really an issue?

2.3/ It is said:
"     4.  The length of the Explicit Source FEC Payload Id, in bytes"
Why should the length be communicated to the FEC framework instance whereas
the Explicit Source FEC Payload ID is totally defined by the FEC scheme,
whose FEC Encoding ID is provided to the FEC framework?

3/ Section 8. "Transport protocols"
-----------------------------------
It is said: "The following transport protocols are supported:"
What does "supported" mean, since the framework is relatively independent of
the transport protocol used (it impacts the tuple used to identify flows and
it should preserve the data unit boundaries, but that's all). I'd be in favor
of having a less directive text, like:

"The FEC framework is compatible with any transport protocol that fulfills the
 requirements (e.g., in terms of real-time delivery of datagrams) of the
original source data flows. Examples of such protocols include:
  o  User Datagram Protocol (UDP)
  o  Datagram Congestion Control Protocol (DCCP)"

4/ Section 9.1 "Normative requirements"
---------------------------------------
I do understand and agree with the fact that there is a reasonable limit to the
repair overhead. However I'm wondering if it makes sense to provide an actual
figure. This limit depends on the target use-case, and the framework I-D 
specifies the architecture, not the use-case.

There is also a potential problem with the current wording:
"   The bandwidth of FEC Repair packet flows MUST NOT exceed the
    bandwidth of the source packet flows being protected."
In complex scenarios, it could result in non desirable limitations. This can
be the case with Fig. 1 of draft-ietf-fecframe-sdp-elements-02:

                                          ____| FEC FRAMEWORK
                                         /    | INSTANCE
                                        /     | 3: Repair Flow
                                       /
                  SOURCE FLOWS        /       | FEC FRAMEWORK
                  0: Source Flow |___/ |------| INSTANCE
              __| 1: Source Flow |            | 4: Repair Flow
             |  | 2: Source Flow
             |                          | FEC FRAMEWORK
             |__________________________| INSTANCE
                                        | 5: Repair Flow
                                        | 6: Repair Flow
                                        | 7: Repair Flow

Admittedly (1) the total bit rate of the 7 repair flows can be lower than
that of the 3 source flows and (2) there are several framework instances.
But this is an example where the section 9.1 limit can be a problem if we
measure the aggregated repair flow bandwidth at the sending host.

I suggest to have a less directive text, like:

The bandwidth of FEC Repair packet flows MUST NOT exceed a certain threshold
of the bandwidth of the source packet flows being protected. This threshold
depends on the use-case where the FEC framework is used. When transmissions
take place over Internet, the bandwidth of the FEC Repair packet flow(s) of a
single FEC framework instance MUST NOT exceed the bandwidth of the source
packet flow(s).

In any case I agree with you, Mark, that using FEC codes in a rateless way is
definitively useless ;-)

5/ Section 6.2. "Structure of the source block"
-----------------------------------------------

It is said:
"  For each source transport payload included in a source block, the
   following information is provided to the FEC Scheme:
   o  A description of the source transport flow with which the
      transport payload is associated (See 6.5)"

I'd rather provide the "identification" of the source flow. The description
of the flow is provided only once, upon FEC framework instantiation
initialization.

6/ Section 6.3.1. "Generic Explicit Source FEC Payload Id"
----------------------------------------------------------

I don't think that any of the current FEC schemes specifies this
Generic Explicit Source FEC Payload Id. This is a problem...

Besides, how is the 2 byte counter managed? Does it take into account
the source block structure or not? It seems that it is the case, but
it is not clearly said that the counter should be reset to 0 at the
beginning of a new source block.

Additionally, the various FEC schemes can have different maximum source
block sizes which means that the source block structure can differ.
Maybe we should say that all the FEC schemes MUST share the same
source block structure if we want the FEC Source Packets to be shared
between the various FEC schemes.

Additional comments:
--------------------

** Current I-D mentions either "Content Delivery Protocol" or CDP.
I suggest to use only CDP throughout of the text.

** Section 6.6. "FEC Scheme requirements"
It is said:
"      ...and the valid packet payload sizes
       (where packet payload refers to the space - not necessarily
       contiguous - within a packet dedicated to carrying encoding
       symbol bytes)."

Sorry, I don't understand "not necessarily contiguous".
I also suggest to say:
       "...and the valid transport (e.g., UDP) datagram payload sizes".
(if I understand correctly the goal).

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 27 Apr 2009 21:29:22 -0700

I mostly agree with Vincent's comments - he did a very detailed review. The draft needs clarifications on the terminology and missing definitions should be provided.

Besides, based on the recent feedback from MMUSIC, I suggest we clarify the multiplexing issues for RTP flows. Essentially, we will somewhat recommend session multiplexing to be mostly aligned with our prior design goals. But, we also have to support SSRC multiplexing so that we cover the applications that use that type of multiplexing to reduce the port usage. We should strongly discourage payload type multiplexing per RFC 3550. I can help with the text, if needed.

BR,
-acbegen

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vincent Roca
> Sent: Friday, April 03, 2009 5:23 AM
> To: [email-masked]
> Subject: [Fecframe] Review of draft-ietf-fecframe-framework-03
> 
> Mark, everybody,
>