Re: [Rmt] Last Call: draft-ietf-rmt-bb-fec-rs (Reed-Solomon Forward Error Correction (FEC) Schemes) to Experimental RFC

[Vincent Roca <[e-mail]>]

Dear Igor,

Thanks a lot for the issue you noticed!

There's indeed an error in section 6.1, since room must of course be reserved
for the future parity symbols when defining the maximum source block length, B.
So we suggest to replace current section 6.1. Here is the new text (where the
only change is the definition of max1_B):

---------
6.1.  Determining the Maximum Source Block Length (B)

   The finite field size parameter, m, defines the number of non zero
   elements in this field which is equal to: q - 1 = 2^^m - 1.  Note
   that q - 1 is also the theoretical maximum number of encoding symbols
   that can be produced for a source block.  For instance, when m = 8
<NEW TEXT>
   (default) there is a maximum of 2^^8 - 1 = 255 encoding symbols.

   Given the target FEC code rate (e.g. provided by the user when
   starting a FLUTE sending application), the sender calculates:

      max1_B = floor((2^^m - 1) * rate)

   This max1_B value leaves enough room for the sender to produce the
   desired number of parity symbols.
</NEW TEXT>

   Additionally, a codec MAY impose other limitations on the maximum
   block size.  Yet it is not expected that such limits exist when using
   the default m = 8 value.  This decision MUST be clarified at
   implementation time, when the target use case is known.  This results
   in a max2_B limitation.

   Then, B is given by:

      B = min(max1_B, max2_B)

   Note that this calculation is only required at the coder, since the B
   parameter is communicated to the decoder through the FEC OTI.
----------

Nothing else needs to be changed. The following check, in section 6.2:
        if (max_n > 2^^m - 1) then return an error ("invalid code rate");
is a sanity check that should never raise any problem if max1_B is initialized
as recommended.

Concerning the need to calculate max_n first and then n, instead of calculating
just n = ceil(k/rate) (what you suggested), the motivation is that the _target_
rate parameter (a floating point value) is not communicated to the receiver.
Instead the receiver knows B and max_n, i.e. a _rounded_ rate: B/max_n. That's
enough.

Best regards,

   The authors


Igor Slepchin wrote:
> I realize Last Call is not the best time to bring up issues with a draft
> but here it goes...
> 
> As far as I can tell, the n-algorithm described in section 6.2 of
> draft-ietf-rmt-bb-fec-rs-03 is badly broken. Let's go through the steps:
> 
> 1. Maximum source block length is computed as
> 
> B = min(max1_B, max2_B) where max1_B = 2^^m - 1 and max2_B is an
> additional limitation imposed by the codec that may or may not be there.
> Let's assume it's not there so B = 2^^m - 1.
> 
> 2. Maximum number of encoding symbols for any block is defined by
> n-algorithm as
> 
> max_n = floor(B / rate). Given that rate is defined as k/n, its value is
> <= 1. Hence, max_n is >= B, i.e., max_n >= 2^^m - 1
> 
> 3. Now, the next step of n-algorithm is:
> 
> if (max_n > 2^^m - 1) then return an error ("invalid code rate");
> 
> So n-algorithm will pretty much _always_ returns an error for
> non-trivial code rates in this scenario, even if the block partitioning
> algorithm produced source blocks of the length that allows generating
> the required number of repair symbols.
> 
> One way to fix step 3 is to redefine B as the maximum length of all
> source blocks _produced by the block partitioning algorithm_, i.e., as
> A_large. But even then the resulting number of repair symbols may be
> less than required by the input code rate due to the two "floor"
> operations. Am I missing anything?
> 
> That said, I don't think I understand the point of getting floor(B /
> rate) and then floor(k * max_n / B) in the first place. Why not just say
> that n = ceil(k/rate) and return an error if n turns out to be larger
> than 2^^m-1 for any of the source blocks? As mentioned in the draft
> itself, client does not need to know n so the value of max_n is
> irrelevant for the decoding operation. If we really want to give the
> client some rough idea of n, one could set max_n to ceil(A_large/rate).
> 
> Thank you,
> Igor Slepchin
> 
> The IESG wrote:
>> The IESG has received a request from the Reliable Multicast Transport WG
>> (rmt) to consider the following document:
>>
>> - 'Reed-Solomon Forward Error Correction (FEC) Schemes '
>>    <draft-ietf-rmt-bb-fec-rs-03.txt> as an Experimental RFC
>> <...>
> 
> 
> 
> CONFIDENTIALITY NOTICE:  This email message and any attachments contain
> proprietary and privileged information of Roundbox, Inc., which are
> provided for the sole and confidential use of the intended recipients. 
> Any review, use, disclosure or distribution of this information is
> restricted and must comply with the nondisclosure agreement between
> Roundbox, Inc. and you (or your company).  All other uses are
> prohibited.  If you are not an intended recipient, please contact the
> sender by reply email and promptly delete and otherwise destroy all
> copies of the message and its attachments.
> 
> 


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