draft-ietf-rmt-bb-fec-rs-02 Comments

1) The document currently defines a single FEC Encoding ID and a 
single EXT_FTI format.  I think the formats for FEC Payload and 
EXT_FTI providede are generally useful for 8 and 16 bit RS codes. 
But, it may be useful to additionally have separate FEC Encoding ID 
specifically for 8-bit Reed Solomon codes.  I propose that document 
_also_ assign a FEC Encoding ID for the fully-specified 8-bit (m = 8) 
Reed Solomon code and G =1.  Then a more compact EXT_FTI could be 
specified for this format.  The rationale for this is the case where 
very loosely coordinated multicast operation may wish to include 
EXT_FTI as part of the packet header.

E.g., for an m = 8, G = 1 RS code, the corresponding EXT_FTI could be:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   HET = 64    |     HEL       |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                      Transfer-Length (L)                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Encoding Symbol Length (E)  | MaxBlkLen (B) |   max_n       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


2) We may also wish to assign an "instance id" value for the 
underspecified small block systematic FEC codes (defined in the FEC 
Basic Schemes BB) that corresponds to this fully-specified protocol? 
This may seem unnecessary but the rationale for this is that the FEC 
Payload ID formats of that specification could then be used if 
desired.  More specifically, the FEC Payload ID format of the Small 
Block Systematic FEC Scheme has the "Source Block Length" field 
available if needed.

3) Section 6.4

Comment: There are a couple of minor editorial issues in wording of 
sentences in the first two paragraphs.  And I found the third 
paragraph difficult to read.  I also came up with an alternative 
"Figure 5" Here is a suggested rewording for these first three 
paragraphs of this section:

In a packet erasure channel, each packet (and symbol(s) since packets 
contain G >= 1 symbols) is either correctly received or erased.  The 
location of the erased symbols in the sequence of symbols must be 
known.  The following specification describes the use of Reed-Solomon 
codes for generating redundant symbols from the k source symbols and 
for recovering the source symbols from any set of k received symbols.

The k source symbols of a source block are assumed to be composed of 
S m-bit elements.  Each m-bit element corresponds to an element of 
the finite field GF(2^^m) through the polynomial representation 
(Section 6.1).  If some of the source symbols contain less than S 
elements, they are virtually padded with zero elements (it can be the 
case for the last symbol of the last block of the object).

The encoding process produces n-k repair symbols of size S m-bit 
elements where the k source symbols are also part of the total n 
encoding symbols (Figure 5) (i.e., a systematic FEC code).  The m-bit 
elements of the repair symbols are calculated using the corresponding 
m-bit elements of the source symbol set.  A logical j-th source 
vector, comprised of the j-th elements from the set of source 
symbols, is used to calculate a j-th encoding vector.  This j-th 
encoding vector then provides the j-th elements for the set encoding 
symbols calculated for the block.  As a systematic code, the first k 
encoding symbols are the same as the k source symbols and the last 
n-k repair symbols are the result of the Reed Solomon encoding.


        Input:  k source symbols

  0             j                                  S-1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |X|                                   | source symbol 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |X|                                   | source symbol 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              . . .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |X|                                   | source symbol k-1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                *

        +----------------+
        |                |
        |  generator     |
        |    matrix      |
        |      GM        |
        |   (k x n)      |
        |                |
        +----------------+

                |
                V

      Output: n encoding symbols (source + repair)

  0             j                                  S-1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |X|                                   | encoding symbol 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |X|                                   | encoding symbol 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              . . .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Y|                                   | encoding symbol n-1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


         Figure 5: Packet encoding scheme


-- 
Brian
__________________________________
Brian Adamson
<mailto:[email protected]>