Subject: [Rmt] Comments to draft-ietf-rmt-fec-bb-revised-00.txt

From: Vincent Roca <[email-masked]>
Date: Fri, 01 Jul 2005 14:47:21 +0200

Dear all,

Here are a few comments for the FEC BB revised I-D.

** Section 2, definitions:
--------------------------

What is a FEC scheme? This is not defined here.
There is no ambiguity with Fully-Specified Schemes (it's an instance of
FEC codes), but with Under-Specified schemes, there can be several
FEC Scheme instances per FEC Scheme, and it begins to be confusing...
For instance, to follow the guidelines of section 6.1 regarding the
share of existing Under-Specified schemes, if FEC codes A and FEC codes B
can both use the FPI and FEC OTI of FEC Encoding ID 128, then they will
be part of the same FEC Scheme, even if they need completely different
codecs?

As a consequence, the definition of "Encoder" and "Decoder" are
ambiguous. From the I-D, and encoder defines the "FEC scheme specific
functions". But with FEC Encoding ID 128 (for instance), there will
be several different __codecs__, one per FEC code instance... What the
I-D defines as Encoder and Decoder is not in line with the traditional
acceptation of these words. I suggest:
Encoder: The FEC Scheme __instance__ specific functions...
Decoder: idem

In other words, Encoder+Decoder == FEC codec

** Section 6.1:
---------------

It is said:
        "The FEC Encoding ID allows receivers to select the appropriate
        FEC decoder".
This is only true with Fully Specified schemes, not with Under-Specified
schemes. Since this sentence appears just after the definition of
Under-Specified Schemes, this is rather misleading.
I'd say instead:
        "The FEC Encoding ID allows receivers to select the appropriate
        FEC Scheme, and in case of Fully-Specified  FEC Schemes, to select
        the appropriate decoder."

** Section 6.1: What about classes of FEC codes?
------------------------------------------------

Just like RFC3452, this I-D does not introduce the possibility of defining
broad classes of FEC codes, that would share the same FEC Encoding ID!
LDPC codes are typically a broad class of FEC codes, that usually share
share the same FPI/FEC OTI, and therefore the same FEC Scheme. This is
what we suggested for LDPC (draft-roca-rmt-ldpc-00.txt).
In that case:
  FEC Encoding ID 132 ==> LDPC codes
  As such this is Under-Specified.
  FEC Encoding ID 132 + FEC Instance ID 0 ==> flavor 1 of LDPC codes
  This time 132/0 is "Completely Specified", i.e. its definition is non
  ambiguous and enables independant implementers to define interoperable
  implementations, just like Fully-Specified FEC Schemes.

To enable that, we only need to change the over-restricting (IMHO) sentence:
        "It is possible that an FEC scheme may not be a Fully-Specified FEC
        Scheme, because either a specification is simply not available or a
        party exists that owns the encoding scheme and is not willing to
        disclose the algorithm and specification."
We can add for instance:
        ... or it gathers a set logically related FEC codes which may
        be extended in the future as new FEC codes are discovered.

The assets:
- it saves a large number of FEC Encoding IDs <= 127 since all sub-codes
  will share the same FEC Encoding ID >= 128. I remember that
  Mike already pointed out this as a potential issue in a previous meeting.

- it does not contradict the Under-Specified definition, since as such, the
  FEC scheme is not completely specified. Only the <FEC Enc ID, FEC Inst ID>
  are __Completely Specified__ (to avoid using the "Fully-Specified" term).

- it saves the burden of defining a new introduction, FPI/FEC OTI, etc.
  stuff since all instances will inherit it from their parent document.

** Section 6.2.1 and later: about the "encoding format"
-------------------------------------------------------

In case the FEC Scheme specifies a binary encoding format (e.g. an
EXT_FTI or similar format), this encoding format may include the FEC
Instance ID (this is the case with an EXT_FTI encoding), which in fact
MUST be defined by the CDP. Contradiction here.
With an XML encoding format specification, this is not an issue since
elements will be listed sequentially, instead of being packed together.

Additional minor remarks:
-------------------------

** Section 2:
        "Decoder: ...to transform received FEC encoded data into..."
        Bad wording, not compliant with rules. Should say instead:
        "...to transform received encoding symbols into..."

** Section 6.2.1 introduces for the 1st time the "encoding format".
        Maybe this term should be defined in section 2?

Cheers,

   Vincent/Christoph

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt