Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding window extensions and RLC FEC
Vincent Roca <vincent.roca@inria.fr> Thu, 17 May 2018 11:07 UTC
Return-Path: <vincent.roca@inria.fr>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D76D12D7E4 for <tsvwg@ietfa.amsl.com>; Thu, 17 May 2018 04:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EF4YtGJIrbOC for <tsvwg@ietfa.amsl.com>; Thu, 17 May 2018 04:07:31 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6359512D77B for <tsvwg@ietf.org>; Thu, 17 May 2018 04:07:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.49,410,1520895600"; d="scan'208,217";a="327279091"
Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2018 13:07:27 +0200
From: Vincent Roca <vincent.roca@inria.fr>
Message-Id: <C41587E5-36CC-44F2-A865-80250054E5B1@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_62550B0A-598A-4830-8BD3-4968CB98453C"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Thu, 17 May 2018 13:07:27 +0200
In-Reply-To: <4b35a291-f5da-f878-a21f-e05211a55b8e@isae-supaero.fr>
Cc: Vincent Roca <vincent.roca@inria.fr>, Wesley Eddy <wes@mti-systems.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, nwcrg@irtf.org
To: Jonathan DETCHART <jonathan.detchart@isae-supaero.fr>
References: <53be4942-bb4f-94a9-b7db-cf023717257c@mti-systems.com> <fffeb7b2-847f-c8f3-e78a-3266cfff7b97@mti-systems.com> <4b35a291-f5da-f878-a21f-e05211a55b8e@isae-supaero.fr>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/4O5dy2dXkYdmyUPhwZYgWnKqP54>
Subject: Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding window extensions and RLC FEC
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 May 2018 11:07:33 -0000
Hi Jonathan, Excellent comments! We need to clarify the Finite Field used, I agree. Here is a new section to address this comment: NEW: 3.6. Finite Fields Operations The two RLC FEC Schemes specified in this document reuse the Finite Fields defined in [RFC5510], section 8.1. More specifically, the elements of the field GF(2^^m) are represented by polynomials with binary coefficients (i.e., over GF(2)) and degree lower or equal to m-1. The addition between two elements is defined as the addition of binary polynomials in GF(2), which is equivalent to a bitwise XOR operation on the binary representation of these elements. With GF(2^^8), multiplication between two elements is the multiplication modulo a given irreducible polynomial of degree 8. The following irreducible polynomial MUST be used for GF(2^^8): x^^8 + x^^4 + x^^3 + x^^2 + 1 With GF(2), multiplication corresponds to a logical AND operation. The reference to (the excellent) Plank’s research report is already in version -03. The two typos are fixed. We’ll submit a new -04 version with the above corrections plus an improved section 3.1. Possible Parameter Derivations. More to come soon... Cheers, Vincent and Belkacem > Le 17 mai 2018 à 10:16, Jonathan DETCHART <jonathan.detchart@isae-supaero.fr> a écrit : > > I read the draft-ietf-tsvwg-rlc-fec-scheme. > 2 typo : > > - p3, $1.2. : "the Sliding Window Random Linear Codes (RLC) over either Finite Field GF(2) or GF(8)". Should it be GF(2^8)? > - p22, $7 : "Lincencing" -> "Licencing" > > > As the document "introduces two fully-specified FEC Schemes". Considering the field GF(2^8), it can be implemented in several ways, depending on the irreducible polynomial that is used and the implementation (xor-based representation or polynomial representation with lookup tables or not). All the implementations are not compatible. > So, how do the encoder and decoder agree on the field and the implementation used to be compatible? Do they exchange some parameters? Should the document propose a default configuration for that? > > I suggest the document propose a default specification for galois field arithmetic: it should give the irreducible polynomial used (like in the rfc 5510), and the implementation to use. For gf(2^8), a lookup table implementation (with optional SIMD vector instructions) seems to be the best on most devices : http://web.eecs.utk.edu/~plank/plank/papers/UT-CS-13-717.html <http://web.eecs.utk.edu/~plank/plank/papers/UT-CS-13-717.html> > Jonathan DETCHART > On 16/05/2018 03:42, Wesley Eddy wrote: >> On 4/17/2018 12:30 AM, Wesley Eddy wrote: >>> (on behalf of all three TSVWG chairs) >>> >>> This email is to start a TSVWG working group last call on the sliding window FECFRAME extensions, and random linear code FEC scheme drafts: >>> >>> (1) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/> >>> >>> (2) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/> >>> >>> ... >>> >> >> >> Many thanks for the couple of technical reviews that were submitted (Emmanuel and Gorry), and to Vincent for quickly updating the drafts in response. >> >> Since this is work for standards track, I think we really need to get a bit more feedback though. >> >> In order to get more reviews, and give people time to look at the updated drafts, so will plan to keep the WGLC open for a couple more weeks in order to give more time for reviews. Please provide comments on the updated documents by 5/29. >> >> Thanks in advance. >> >> >> _______________________________________________ >> nwcrg mailing list >> nwcrg@irtf.org <mailto:nwcrg@irtf.org> >> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg> > > _______________________________________________ > nwcrg mailing list > nwcrg@irtf.org > https://www.irtf.org/mailman/listinfo/nwcrg
- [tsvwg] WGLC on FECFRAME sliding window extension… Wesley Eddy
- Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding wind… Emmanuel Lochin
- Re: [tsvwg] WGLC on FECFRAME sliding window exten… Gorry Fairhurst
- Re: [tsvwg] WGLC on FECFRAME RLC FEC Gorry Fairhurst
- Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding wind… Vincent Roca
- Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding wind… Emmanuel Lochin
- Re: [tsvwg] WGLC on FECFRAME RLC FEC Vincent Roca
- Re: [tsvwg] WGLC on FECFRAME RLC FEC Gorry Fairhurst
- Re: [tsvwg] WGLC on FECFRAME sliding window exten… Wesley Eddy
- Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding wind… Jonathan DETCHART
- Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding wind… Vincent Roca
- Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding wind… Ali C. Begen