From ravlousy@blackberry.net Sun May 4 18:27:50 2008 Return-Path: X-Original-To: ietfarch-rmt-archive@core3.amsl.com Delivered-To: ietfarch-rmt-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568D43A6F8F for ; Sun, 4 May 2008 18:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.156 X-Spam-Level: X-Spam-Status: No, score=-19.156 tagged_above=-999 required=5 tests=[DOS_OE_TO_MX=2.75, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=2.188, RCVD_IN_PBL=0.509, RCVD_IN_XBL=2.896, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7TEnYOil2hC for ; Sun, 4 May 2008 18:27:49 -0700 (PDT) Received: from mx3.ridsa.com.ar (mx3.ridsa.com.ar [190.136.7.244]) by core3.amsl.com (Postfix) with ESMTP id A6B503A6F5E for ; Sun, 4 May 2008 18:27:44 -0700 (PDT) Message-ID: <001201c8ae36$1513df30$00f11acc@LOGINF2598B2B6> From: "Solomon Dodge" To: "Rmt-archive" Subject: Mall for Man's Date: Sun, 4 May 2008 22:27:48 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C8AE36.1513DF30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.2963 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.2963 ------=_NextPart_000_000F_01C8AE36.1513DF30 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable You won't find High-quality low-priced incredible at unbelievable low = prices in your local chemist's!!! If you buy medication to enhance erections now, we really should check = out!!! We sell only premium stuff!!! Order now!!! ------=_NextPart_000_000F_01C8AE36.1513DF30 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

You won't find High-quality low-priced incredible at = unbelievable low prices in your local chemist's!!!
  
If you = buy medication to enhance erections now, we really should check = out!!!


We = sell only premium stuff!!!





------=_NextPart_000_000F_01C8AE36.1513DF30-- From rmt-bounces@ietf.org Mon May 26 04:05:15 2008 Return-Path: X-Original-To: rmt-archive@megatron.ietf.org Delivered-To: ietfarch-rmt-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC8D3A6A5A; Mon, 26 May 2008 04:05:15 -0700 (PDT) X-Original-To: rmt@core3.amsl.com Delivered-To: rmt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160E73A68A5 for ; Mon, 26 May 2008 04:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9ST8d3oSAW2 for ; Mon, 26 May 2008 04:05:11 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id BD16828C10E for ; Mon, 26 May 2008 04:05:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,542,1204498800"; d="scan'208";a="12713975" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 May 2008 13:05:07 +0200 Message-ID: <483A9963.1000903@inrialpes.fr> Date: Mon, 26 May 2008 13:05:07 +0200 From: Vincent Roca User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Brian Adamson , rmt@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.95.6 Cc: Neumann Christoph , Magnus Westerlund , Vincent Roca , David FURODET Subject: Re: [Rmt] Question to working group regarding LDPC Draft X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rmt-bounces@ietf.org Errors-To: rmt-bounces@ietf.org Dear all, Here is the new LDPC document that includes the modifications suggested in a previous email: http://planete.inrialpes.fr/~roca/doc/rfc5170_VR.txt And the associated diff: http://planete.inrialpes.fr/~roca/doc/rfc5170_VR-from-preliminary.diff.html Note that these modifications have been made W.R.T. the document edited by the RFC Editor, not version -08. When reviewing the document once again, we also identified a non critical error, section 5.7 (pmms_rand() return value can be equal to 0). Regards, Vincent, on behalf of the authors Brian Adamson wrote: > All, > > There hasn't been any object to alteration of the LDPC document as > described below ... but there hasn't been _any_ response! > > If there are no objections by the end of this week (2 May 2008), we > will honor the authors' request for this change and help accommodate > as quick as publication process as possible. > > best regards, > > > > At 9:37 AM -0400 4/17/08, Brian Adamson wrote: >> During the publication process of the LDPC FEC Scheme document, one >> of the author's brought to attention a technique to dramatically >> improve the erasure decoding performance of the subject codes (the >> LDPC staircase and triangle codes). >> >> For application of this technique to the LDPC Staircase code (that >> has lower encoding/decoding computational complexity), a >> modification to the parity check matrix is needed to realize its >> full benefits. >> >> Therefore, the authors have proposed a modification to the document, >> including a change to the format of the FEC OTI for the LDPC codes, >> to support this. >> >> The publication process of this document has been halted pending a >> decision based on Working Group concensus as to whether this change >> is acceptable. The authors feel this is a worthwhile modification >> >> So, the question to the RMT Working Group is a query as to whether >> there is objection to this change. The change will slightly delay >> the publication process here, but we will work to make it continue >> as quickly as possible. >> >> >> Below is the authors' description of the change and rationale >> including a link to a paper that describes the performance benefits: >> >>> ** Motivations: >>> >>> Any LDPC decoder needs to solve a system of linear equations. >>> Several techniques are possible, among which the iterative algorithm sketched >>> in the I-D, a Gaussian elimination, or anything else. Some of them favor the >>> decoding time at the price of a certain sub-optimality in terms of erasure >>> recovery capabilities (e.g., iterative decoding), and vice-versa (e.g., >>> Gaussian elimination). >>> >>> We recently implemented and carried out performance evaluation of a hybrid >>> iterative decoding/Gaussian elimination scheme [1] and found that >>> LDPC-triangle codes can be made almost ideal, while keeping a reasonable >>> decoding time (it's significantly faster than Reed-Solomon codes) for >>> medium-sized objects. >>> >>> We recently discovered that by increasing the density of "1s" in the left >>> side of the parity check matrix, similar improvements can be achieved with >>> LDPC-staircase codes [2] (e.g., they are less than 1% away than ideal codes). >>> >>> >>> ** Proposal: >>> >>> We'd like to carry an additional parameter in the Scheme-Specific Elements >>> of the FEC Object Transmission Information: the target column density of the >>> left submatrix: >>> >>> - the default recommended value remains 3 (value which is currently >>> hard-coded >>> in the I-D). It is optimal for both LDPC variants when using an iterative >>> decoding, and it remains almost optimal with LDPC-triangle codes featuring >>> a Gaussian elimination. >>> >>> - for a specific use-case, when it is recommended to use LDPC-staircase and >>> a Gaussian elimination, a higher value could be used (current tests suggest >>> values between 4 to 8, depending on the code rate). >>> >>> For practical reasons (3 bits left only), we do not carry the target column >>> density but this value minus 3. >>> >>> >>> ** Details of the modifications: >>> >>> 3.2. Notations >>> N1 denotes the target number of "1s" per column in the left side of >>> the parity check matrix (Section 6.2) >>> >>> N1m3 denotes the value N1 - 3, where N1 is the target number of "1s" >>> per column in the left side of the parity check matrix >>> >>> 4.2.3. Scheme-Specific Elements >>> o G: an integer between 1 (default) and 31 inclusive indicating >>> the number >>> of encoding symbols per group (i.e., per packet). [...] >>> >>> ==> we need to restrict the G value since it is now encoded in a 5-bit field. >>> >>> >>> o N1m3: an integer between 0 (default) and 7, inclusive. The number >>> of "1s" per column, N1, is equal to N1m3 + 3. Using N1m3 equal to >>> 0 is recommended when the sender has no information on the decoding >>> scheme used by the receivers. A value greater than 0 for N1m3 can >>> be a good choice in specific situations, e.g., when using >>> LDPC-staircase codes with a Gaussian elimination decoding scheme. >>> Nevertheless, the current document does not mandate any specific >>> value. This choice is left to the codec developer. >>> >>> >>> 4.2.4.1. Using the General EXT_FTI Format >>> >>> ==> New EXT_FTI: >>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Encoding Symbol Length (E) | N1m3| G | B (MSB) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> 4.2.4.2. Using the FDT Instance (FLUTE-Specific) >>> >>> ==> New Scheme-Specific Information: >>> >>> 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 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | PRNG seed | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | N1m3| G | >>> +-+-+-+-+-+-+-+-+ >>> >>> >>> 6.2. Parity Check Matrix Creation >>> >>> ==> In this section we replace all references to "3 "1s" per column" >>> by N1 "1s" per column, both in the comments and in left_matrix_init() >>> and add the N1 parameter to this function prototype. >>> >>> >>> >>> NB: We need to cross-check the whole document carefully, but I believe that >>> modifications are restricted to the above sections. >>> >>> >>> ** Practically speaking: >>> >>> This change does not impact the interoperability of LDPC decoders using >>> different types of decoding algorithms. >>> >>> The current value of 3 remains the recommended, general purpose value. >>> Detailed recommendations on when to use a value greater than 3 will be >>> made in separate documents (we are working on it). >>> >>> This modification is only meaningful with LDPC-Staircase codes. The current >>> situation is already adequate to LDPC-Triangle codes, no matter the type of >>> decoding algorithm used. >>> >>> The current LDPC-staircase and triangle reference codec already features >>> this parameter (called leftDegree in the InitSession prototype): >>> ldpc_error_status InitSession (int nbSourceSymbols, >>> int nbParitySymbols, >>> int symbolSize, >>> int flags = FLAG_BOTH, >>> int seed = 1, >>> SessionType codecType = >>> TypeTRIANGLE, >>> int leftDegree = 3); >>> >>> >>> ** References : >>> >>> [1] M. Cunche, V. Roca, >>> ``Improving the Decoding of LDPC Codes for the Packet Erasure Channel with >>> a Hybrid Zyablov Iterative Decoding/Gaussian Eliminiation Scheme'', >>> INRIA Research Report RR-6473, March 2008. >>> http://planete.inrialpes.fr/people/roca/doc/RR-6473.pdf >>> >>> >>> [2] M. Cunche, V. Roca, >>> `Optimizing the error recovering capabilities of LDPC-Staircase codes >>> featuring a Gaussian elimination decoding scheme'', >>> >>> >> >> >> -- >> Brian >> __________________________________ >> Brian Adamson >> > > _______________________________________________ Rmt mailing list Rmt@ietf.org https://www.ietf.org/mailman/listinfo/rmt From rmt-bounces@ietf.org Fri May 30 10:45:04 2008 Return-Path: X-Original-To: rmt-archive@megatron.ietf.org Delivered-To: ietfarch-rmt-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66EC228C229; Fri, 30 May 2008 10:45:04 -0700 (PDT) X-Original-To: rmt@ietf.org Delivered-To: rmt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 91DE428C214; Fri, 30 May 2008 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080530174501.91DE428C214@core3.amsl.com> Date: Fri, 30 May 2008 10:45:01 -0700 (PDT) Cc: rmt@ietf.org Subject: [Rmt] I-D Action:draft-ietf-rmt-bb-norm-revised-05.txt X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Reliable Multicast Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rmt-bounces@ietf.org Errors-To: rmt-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Multicast Negative-Acknowledgment (NACK) Building Blocks Author(s) : B. Adamson, et al. Filename : draft-ietf-rmt-bb-norm-revised-05.txt Pages : 40 Date : 2008-05-30 This document discusses the creation of reliable multicast protocols utilizing negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-norm-revised-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-rmt-bb-norm-revised-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-30103536.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rmt mailing list Rmt@ietf.org https://www.ietf.org/mailman/listinfo/rmt --NextPart--