Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding window extensions and RLC FEC

Vincent Roca <> Thu, 17 May 2018 11:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D76D12D7E4 for <>; Thu, 17 May 2018 04:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.898
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EF4YtGJIrbOC for <>; Thu, 17 May 2018 04:07:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6359512D77B for <>; 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 ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2018 13:07:27 +0200
From: Vincent Roca <>
Message-Id: <>
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: <>
Cc: Vincent Roca <>, Wesley Eddy <>, "" <>,
To: Jonathan DETCHART <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <>
Subject: Re: [tsvwg] [nwcrg] WGLC on FECFRAME sliding window extensions and RLC FEC
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:


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...


  Vincent and Belkacem

> Le 17 mai 2018 à 10:16, Jonathan DETCHART <> 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 : <>
> 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) <> 
>>> (2) <> 
>>> ...
>> 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 mailing list