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

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
Rmt@ietf.org
https://www1.ietf.org/mailman/listinfo/rmt