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

Vincent,

I don't think the proposed change completely solves the problem, it only
lets us pass the sanity check.

As I briefly mentioned in my previous email, taking the two floors in
the n-algorithm will not produce the required number of repair symbols
in some situations. For example, let's say the code rate is 0.9, m=8,
and B=229 (e.g., max1_B=floor(255*0.9)=229, or max2_B=229 for whatever
reason). Let's assume that the block partitioning algorithm produced a
source block of 180 symbols, i.e., k=180. Then we have:

max_n=floor(B/rate)=floor(229/0.9)=254.
n=floor(k * max_n / B)=floor(180*254/229)=199.

Thus, the n-algorithm generated 199-180=19 repair symbols. However, the
requested code rate requires 180/0.9=200 encoding symbols, i.e., 20
repair symbols. So the n-algorithm causes us to generate fewer repair
symbols than requested by the code rate.

More comments below.

Vincent Roca wrote:
> <...>
> 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.

Right, I understand that we cannot communicate the floating point code
rate to the client. However, since knowing the rate is not required for
decoding of Reed-Solomon codes, knowing the exact number of repair
symbols is not really required for decoding either. I understand that
having a reasonable estimate for that number may make memory management
on some implementations easier, but I don't think that knowing the 
precise value is critical. For example, if the server sets max_n to
the maximum number of encoding symbols generated for any of the source
blocks, it gives the client a reasonable estimate for pre-allocating its
memory structures. The estimate may be off (on the plus side) by up to 2
encoding symbols for A_small source blocks, but that doesn't sound too
bad for me.

That said, I've nothing against determining the exact number of encoding
symbols for each source block on the client based on just max_n and B, I
just could not come up with a way to do that without running into the
issue I described above.

Thank you,
Igor Slepchin


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.