Re: [Rmt] Last Call: draft-ietf-rmt-bb-fec-rs (Reed-Solomon Forward Error Correction (FEC) Schemes) to Experimental RFC
Igor Slepchin <igor@roundbox.com> Wed, 26 September 2007 03:06 UTC
Return-path: <rmt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaNEl-0002KV-AV; Tue, 25 Sep 2007 23:06:55 -0400
Received: from rmt by megatron.ietf.org with local (Exim 4.43) id 1IaNEk-0002Ju-3s for rmt-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 23:06:54 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaNEj-00020n-OS for rmt@ietf.org; Tue, 25 Sep 2007 23:06:53 -0400
Received: from mailman.roundbox.com ([208.122.3.166]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaNEf-0006a1-7u for rmt@ietf.org; Tue, 25 Sep 2007 23:06:49 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailman.roundbox.com (Postfix) with ESMTP id BFD19CC8020; Tue, 25 Sep 2007 23:07:00 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Score: 1.586
X-Spam-Level: *
X-Spam-Status: No, score=1.586 tagged_above=-10 required=6.6 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_NJABL_DUL=1.946, RCVD_IN_SORBS_DUL=2.046]
Received: from mailman.roundbox.com ([127.0.0.1]) by localhost (mailman.roundbox.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtnOLRgZzqPP; Tue, 25 Sep 2007 23:06:54 -0400 (EDT)
Received: by mailman.roundbox.com (Postfix, from userid 100) id B3507CC8021; Tue, 25 Sep 2007 23:06:52 -0400 (EDT)
Received: from [192.168.1.100] (pool-141-153-206-144.mad.east.verizon.net [141.153.206.144]) by mailman.roundbox.com (Postfix) with ESMTP id CFDF5CC8020; Tue, 25 Sep 2007 23:06:51 -0400 (EDT)
Message-ID: <46F9CCBD.4090702@roundbox.com>
Date: Tue, 25 Sep 2007 23:06:37 -0400
From: Igor Slepchin <igor@roundbox.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20070719)
MIME-Version: 1.0
To: Vincent Roca <vincent.roca@inrialpes.fr>
Subject: Re: [Rmt] Last Call: draft-ietf-rmt-bb-fec-rs (Reed-Solomon Forward Error Correction (FEC) Schemes) to Experimental RFC
References: <E1IYNrI-00035t-H5@stiedprstage1.ietf.org> <46F4271E.6010408@roundbox.com> <46F8C8A8.3080602@inrialpes.fr>
In-Reply-To: <46F8C8A8.3080602@inrialpes.fr>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Copyrighted-Material: Please visit http://www.roundbox.com/privacy.htm
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: sami.peltotalo@tut.fi, jerome.lacan@ensica.fr, rmt@ietf.org
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
Errors-To: rmt-bounces@ietf.org
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. _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt
- [Rmt] Last Call: draft-ietf-rmt-bb-fec-rs (Reed-S… The IESG
- Re: [Rmt] Last Call: draft-ietf-rmt-bb-fec-rs (Re… Igor Slepchin
- Re: [Rmt] Last Call: draft-ietf-rmt-bb-fec-rs (Re… Vincent Roca
- Re: [Rmt] Last Call: draft-ietf-rmt-bb-fec-rs (Re… Igor Slepchin
- Re: [Rmt] Last Call: draft-ietf-rmt-bb-fec-rs (Re… Vincent Roca
- Re: [Rmt] Last Call: draft-ietf-rmt-bb-fec-rs (Re… Igor Slepchin