draft-ietf-tsvwg-rlc-fec-scheme-05.txt   draft-ietf-tsvwg-rlc-fec-scheme-06.txt 
TSVWG V. Roca TSVWG V. Roca
Internet-Draft B. Teibi Internet-Draft B. Teibi
Intended status: Standards Track INRIA Intended status: Standards Track INRIA
Expires: November 24, 2018 May 23, 2018 Expires: January 26, 2019 July 25, 2018
Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC)
Schemes for FECFRAME Schemes for FECFRAME
draft-ietf-tsvwg-rlc-fec-scheme-05 draft-ietf-tsvwg-rlc-fec-scheme-06
Abstract Abstract
This document describes two fully-specified Forward Erasure This document describes two fully-specified Forward Erasure
Correction (FEC) Schemes for Sliding Window Random Linear Codes Correction (FEC) Schemes for Sliding Window Random Linear Codes
(RLC), one for RLC over GF(2) (binary case), a second one for RLC (RLC), one for RLC over GF(2) (binary case), a second one for RLC
over GF(2^^8), both of them with the possibility of controlling the over GF(2^^8), with the possibility of controlling the code density.
code density. They can protect arbitrary media streams along the They can protect arbitrary media streams along the lines defined by
lines defined by FECFRAME extended to sliding window FEC codes. FECFRAME extended to sliding window FEC codes. These sliding window
These sliding window FEC codes rely on an encoding window that slides FEC codes rely on an encoding window that slides over the source
over the source symbols, generating new repair symbols whenever symbols, generating new repair symbols whenever needed. Compared to
needed. Compared to block FEC codes, these sliding window FEC codes block FEC codes, these sliding window FEC codes offer key advantages
offer key advantages with real-time flows in terms of reduced FEC- with real-time flows in terms of reduced FEC-related latency while
related latency while often providing improved packet erasure often providing improved packet erasure recovery capabilities.
recovery capabilities.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 24, 2018. This Internet-Draft will expire on January 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 28
1.3. Small Transmission Overheads with the Sliding Window RLC 1.3. Small Transmission Overheads with the Sliding Window RLC
FEC Scheme . . . . . . . . . . . . . . . . . . . . . . . 5 FEC Scheme . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Document Organization . . . . . . . . . . . . . . . . . . 6 1.4. Document Organization . . . . . . . . . . . . . . . . . . 6
2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Possible Parameter Derivations . . . . . . . . . . . . . 7 3.1. Possible Parameter Derivations . . . . . . . . . . . . . 7
3.1.1. Case of a CBR Real-Time Flow . . . . . . . . . . . . 8 3.1.1. Case of a CBR Real-Time Flow . . . . . . . . . . . . 8
3.1.2. Other Types of Real-Time Flow . . . . . . . . . . . . 10 3.1.2. Other Types of Real-Time Flow . . . . . . . . . . . . 10
3.1.3. Case of a Non Real-Time Flow . . . . . . . . . . . . 11 3.1.3. Case of a Non Real-Time Flow . . . . . . . . . . . . 11
3.2. ADU, ADUI and Source Symbols Mappings . . . . . . . . . . 11 3.2. ADU, ADUI and Source Symbols Mappings . . . . . . . . . . 11
3.3. Encoding Window Management . . . . . . . . . . . . . . . 13 3.3. Encoding Window Management . . . . . . . . . . . . . . . 12
3.4. Pseudo-Random Number Generator (PRNG) . . . . . . . . . . 13 3.4. Pseudo-Random Number Generator (PRNG) . . . . . . . . . . 13
3.5. Coding Coefficients Generation Function . . . . . . . . . 14 3.5. Coding Coefficients Generation Function . . . . . . . . . 14
3.6. Finite Fields Operations . . . . . . . . . . . . . . . . 17 3.6. Finite Fields Operations . . . . . . . . . . . . . . . . 17
3.6.1. Finite Field Definitions . . . . . . . . . . . . . . 17 3.6.1. Finite Field Definitions . . . . . . . . . . . . . . 17
3.6.2. Linear Combination of Source Symbols Computation . . 17 3.6.2. Linear Combination of Source Symbols Computation . . 17
4. Sliding Window RLC FEC Scheme over GF(2^^8) for Arbitrary ADU 4. Sliding Window RLC FEC Scheme over GF(2^^8) for Arbitrary ADU
Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 18 4.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 18
4.1.1. FEC Framework Configuration Information . . . . . . . 18 4.1.1. FEC Framework Configuration Information . . . . . . . 18
4.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 19 4.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 19
skipping to change at page 3, line 25 skipping to change at page 3, line 23
GF(2^^8) . . . . . . . . . . . . . . . . . . . . . . . . 26 GF(2^^8) . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2. Operational Recommendations: Coding Coefficients Density 9.2. Operational Recommendations: Coding Coefficients Density
Threshold . . . . . . . . . . . . . . . . . . . . . . . . 26 Threshold . . . . . . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. TinyMT32 Pseudo-Random Number Generator . . . . . . 29 Appendix A. TinyMT32 Pseudo-Random Number Generator . . . . . . 29
Appendix B. Decoding Beyond Maximum Latency Optimization . . . . 32 Appendix B. Decoding Beyond Maximum Latency Optimization . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Application-Level Forward Erasure Correction (AL-FEC) codes, or Application-Level Forward Erasure Correction (AL-FEC) codes, or
simply FEC codes, are a key element of communication systems. They simply FEC codes, are a key element of communication systems. They
are used to recover from packet losses (or erasures) during content are used to recover from packet losses (or erasures) during content
delivery sessions to a large number of receivers (multicast/broadcast delivery sessions to a large number of receivers (multicast/broadcast
transmissions). This is the case with the FLUTE/ALC protocol transmissions). This is the case with the FLUTE/ALC protocol
[RFC6726] when used for reliable file transfers over lossy networks, [RFC6726] when used for reliable file transfers over lossy networks,
and the FECFRAME protocol when used for reliable continuous media and the FECFRAME protocol when used for reliable continuous media
skipping to change at page 25, line 27 skipping to change at page 25, line 27
precisely, the FEC Repair Packets received will probably no longer precisely, the FEC Repair Packets received will probably no longer
be multiple of E, leading receivers to reject them; be multiple of E, leading receivers to reject them;
It is therefore RECOMMENDED that security measures are taken to It is therefore RECOMMENDED that security measures are taken to
guarantee the FFCI integrity, as specified in [RFC6363]. How to guarantee the FFCI integrity, as specified in [RFC6363]. How to
achieve this depends on the way the FFCI is communicated from the achieve this depends on the way the FFCI is communicated from the
sender to the receiver, which is not specified in this document. sender to the receiver, which is not specified in this document.
Similarly, attacks are possible against the Explicit Source FEC Similarly, attacks are possible against the Explicit Source FEC
Payload ID and Repair FEC Payload ID: by modifying the Encoding Payload ID and Repair FEC Payload ID: by modifying the Encoding
Symbol ID (ESI), or the repair key, NSS or FSS_ESI. It is therefore Symbol ID (ESI), or the repair key, DT, NSS or FSS_ESI. It is
RECOMMENDED that security measures are taken to guarantee the FEC therefore RECOMMENDED that security measures are taken to guarantee
Source and Repair Packets as stated in [RFC6363]. the FEC Source and Repair Packets as stated in [RFC6363].
8.3. When Several Source Flows are to be Protected Together 8.3. When Several Source Flows are to be Protected Together
The Sliding Window RLC FEC Scheme specified in this document does not The Sliding Window RLC FEC Scheme specified in this document does not
change the recommendations of [RFC6363]. change the recommendations of [RFC6363].
8.4. Baseline Secure FEC Framework Operation 8.4. Baseline Secure FEC Framework Operation
The Sliding Window RLC FEC Scheme specified in this document does not The Sliding Window RLC FEC Scheme specified in this document does not
change the recommendations of [RFC6363] concerning the use of the change the recommendations of [RFC6363] concerning the use of the
skipping to change at page 27, line 14 skipping to change at page 27, line 14
o YYYY refers to the Sliding Window Random Linear Codes (RLC) over o YYYY refers to the Sliding Window Random Linear Codes (RLC) over
GF(2) FEC Scheme for Arbitrary Packet Flows, as defined in GF(2) FEC Scheme for Arbitrary Packet Flows, as defined in
Section 5 of this document. Section 5 of this document.
o XXXX refers to the Sliding Window Random Linear Codes (RLC) over o XXXX refers to the Sliding Window Random Linear Codes (RLC) over
GF(2^^8) FEC Scheme for Arbitrary Packet Flows, as defined in GF(2^^8) FEC Scheme for Arbitrary Packet Flows, as defined in
Section 4 of this document. Section 4 of this document.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Jonathan Detchart, Gorry Fairhurst, The authors would like to thank Gorry Fairhurst, Jonathan Detchart,
and Marie-Jose Montpetit for their valuable feedbacks on this Emmanuel Lochin, and Marie-Jose Montpetit for their valuable
document. feedbacks on this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[fecframe-ext] [fecframe-ext]
Roca, V. and A. Begen, "Forward Error Correction (FEC) Roca, V. and A. Begen, "Forward Error Correction (FEC)
Framework Extension to Sliding Window Codes", Transport Framework Extension to Sliding Window Codes", Transport
Area Working Group (TSVWG) draft-ietf-tsvwg-fecframe-ext Area Working Group (TSVWG) draft-ietf-tsvwg-fecframe-ext
(Work in Progress), March 2018, (Work in Progress), July 2018,
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/
draft-ietf-tsvwg-fecframe-ext>. draft-ietf-tsvwg-fecframe-ext>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363, Correction (FEC) Framework", RFC 6363,
skipping to change at page 29, line 9 skipping to change at page 29, line 9
Case Study", 13th IEEE International Conference on Case Study", 13th IEEE International Conference on
Wireless and Mobile Computing, Networking and Wireless and Mobile Computing, Networking and
Communications (WiMob17), October Communications (WiMob17), October
2017 https://hal.inria.fr/hal-01571609v1/en/, October 2017 https://hal.inria.fr/hal-01571609v1/en/, October
2017, <https://hal.inria.fr/hal-01571609v1/en/>. 2017, <https://hal.inria.fr/hal-01571609v1/en/>.
Appendix A. TinyMT32 Pseudo-Random Number Generator Appendix A. TinyMT32 Pseudo-Random Number Generator
The TinyMT32 PRNG reference implementation is distributed under a BSD The TinyMT32 PRNG reference implementation is distributed under a BSD
license by the authors and excerpts of it are reproduced in Figure 8. license by the authors and excerpts of it are reproduced in Figure 8.
Differences with respect to the original source code are the The differences with respect to the original source code are:
following:
o unused parts of the original source code have been removed; o the unused parts of the original source code have been removed;
o the appropriate parameter set has been added to the initialisation o the appropriate parameter set has been added to the initialization
function; function;
o function tinymt32_rand() has been added; o the tinymt32_rand() function has been added;
o function order has been changed; o the function order has been changed;
o certain internal variables have been renamed for compactness o certain internal variables have been renamed for compactness
purposes. purposes.
<CODE BEGINS> <CODE BEGINS>
/** /**
* Tiny Mersenne Twister only 127 bit internal state * Tiny Mersenne Twister only 127 bit internal state
* *
* Authors : Mutsuo Saito (Hiroshima University) * Authors : Mutsuo Saito (Hiroshima University)
* Makoto Matsumoto (University of Tokyo) * Makoto Matsumoto (University of Tokyo)
* *
* Copyright (c) 2011, 2013 Mutsuo Saito, Makoto Matsumoto, * Copyright (c) 2011, 2013 Mutsuo Saito, Makoto Matsumoto,
* Hiroshima University and The University of Tokyo. * Hiroshima University and The University of Tokyo.
* All rights reserved. * All rights reserved.
* *
* Redistribution and use in source and binary forms, with or without * Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions * modification, are permitted provided that the following conditions
* are met: * are met:
* *
* - Redistributions of source code must retain the above copyright * - Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer. * notice, this list of conditions and the following disclaimer.
* - Redistributions in binary form must reproduce the above * - Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following * copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials * disclaimer in the documentation and/or other materials
* provided with the distribution. * provided with the distribution.
* - Neither the name of the Hiroshima University nor the names of * - Neither the name of the Hiroshima University nor the names of
* its contributors may be used to endorse or promote products * its contributors may be used to endorse or promote products
* derived from this software without specific prior written * derived from this software without specific prior written
* permission. * permission.
* *
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
* CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
* ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
* TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
* THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE. * SUCH DAMAGE.
*/ */
/**
* tinymt32 internal state vector and parameters
*/
typedef struct {
uint32_t status[4];
uint32_t mat1;
uint32_t mat2;
uint32_t tmat;
} tinymt32_t;
static void tinymt32_next_state (tinymt32_t * s); /**
static uint32_t tinymt32_temper (tinymt32_t * s); * tinymt32 internal state vector and parameters
static double tinymt32_generate_32double (tinymt32_t * s); */
typedef struct {
uint32_t status[4];
uint32_t mat1;
uint32_t mat2;
uint32_t tmat;
} tinymt32_t;
/** static void tinymt32_next_state (tinymt32_t * s);
* Parameter set to use for RLC FEC Schemes. Do not change. static uint32_t tinymt32_temper (tinymt32_t * s);
*/ static double tinymt32_generate_32double (tinymt32_t * s);
#define TINYMT32_MAT1_PARAM 0x8f7011ee
#define TINYMT32_MAT2_PARAM 0xfc78ff1f
#define TINYMT32_TMAT_PARAM 0x3793fdff
/** /**
* This function initializes the internal state array with a 32-bit * Parameter set to use for the IETF RLC FEC Schemes specification.
* unsigned integer seed. * Do not change.
* @param s tinymt state vector. * This parameter set is the first entry of the precalculated parameter
* @param seed a 32-bit unsigned integer used as a seed. * sets in file tinymt32dc.0.1048576.txt, by Kenji Rikitake, available
*/ * at: https://github.com/jj1bdx/tinymtdc-longbatch/blob/master/
void tinymt32_init (tinymt32_t * s, uint32_t seed) * tinymt32dc/tinymt32dc.0.1048576.txt
{ * It is also the parameter set used:
#define MIN_LOOP 8 * Rikitake, K., "TinyMT Pseudo Random Number Generator for
#define PRE_LOOP 8 * Erlang", ACM 11th SIGPLAN Erlang Workshop (Erlang'12),
s->status[0] = seed; * September, 2012.
s->status[1] = s->mat1 = TINYMT32_MAT1_PARAM; */
s->status[2] = s->mat2 = TINYMT32_MAT2_PARAM; #define TINYMT32_MAT1_PARAM 0x8f7011ee
s->status[3] = s->tmat = TINYMT32_TMAT_PARAM; #define TINYMT32_MAT2_PARAM 0xfc78ff1f
for (int i = 1; i < MIN_LOOP; i++) { #define TINYMT32_TMAT_PARAM 0x3793fdff
s->status[i & 3] ^= i + UINT32_C(1812433253)
* (s->status[(i - 1) & 3]
^ (s->status[(i - 1) & 3] >> 30));
} /**
for (int i = 0; i < PRE_LOOP; i++) { * This function initializes the internal state array with a 32-bit
tinymt32_next_state(s); * unsigned integer seed.
} * @param s pointer to tinymt internal state.
} * @param seed a 32-bit unsigned integer used as a seed.
*/
void tinymt32_init (tinymt32_t * s, uint32_t seed)
{
#define MIN_LOOP 8
#define PRE_LOOP 8
s->status[0] = seed;
s->status[1] = s->mat1 = TINYMT32_MAT1_PARAM;
s->status[2] = s->mat2 = TINYMT32_MAT2_PARAM;
s->status[3] = s->tmat = TINYMT32_TMAT_PARAM;
for (int i = 1; i < MIN_LOOP; i++) {
s->status[i & 3] ^= i + UINT32_C(1812433253)
* (s->status[(i - 1) & 3]
^ (s->status[(i - 1) & 3] >> 30));
}
for (int i = 0; i < PRE_LOOP; i++) {
tinymt32_next_state(s);
}
}
/** /**
* This function outputs an integer in the [0 .. maxv-1] range. * This function outputs an integer in the [0 .. maxv-1] range.
* @param s tinymt internal status * @param s pointer to tinymt internal state.
* @return floating point number r (0.0 <= r < 1.0) * @return 32-bit unsigned integer between 0 and maxv-1 inclusive.
*/ */
uint32_t tinymt32_rand (tinymt32_t * s, uint32_t maxv) uint32_t tinymt32_rand (tinymt32_t * s, uint32_t maxv)
{ {
return (uint32_t)(tinymt32_generate_32double(s) * (double)maxv); return (uint32_t)(tinymt32_generate_32double(s) * (double)maxv);
} }
/** /**
* Internal tinymt32 constants and functions. * Internal tinymt32 constants and functions.
* Users should not call these functions directly. * Users should not call these functions directly.
*/ */
#define TINYMT32_MEXP 127 #define TINYMT32_MEXP 127
#define TINYMT32_SH0 1 #define TINYMT32_SH0 1
#define TINYMT32_SH1 10 #define TINYMT32_SH1 10
#define TINYMT32_SH8 8 #define TINYMT32_SH8 8
#define TINYMT32_MASK UINT32_C(0x7fffffff) #define TINYMT32_MASK UINT32_C(0x7fffffff)
#define TINYMT32_MUL (1.0f / 16777216.0f) #define TINYMT32_MUL (1.0f / 16777216.0f)
/** /**
* This function changes internal state of tinymt32. * This function changes internal state of tinymt32.
* @param s tinymt internal status * @param s pointer to tinymt internal state.
*/ */
static void tinymt32_next_state (tinymt32_t * s) static void tinymt32_next_state (tinymt32_t * s)
{ {
uint32_t x; uint32_t x;
uint32_t y; uint32_t y;
y = s->status[3]; y = s->status[3];
x = (s->status[0] & TINYMT32_MASK) x = (s->status[0] & TINYMT32_MASK)
^ s->status[1] ^ s->status[1]
^ s->status[2]; ^ s->status[2];
x ^= (x << TINYMT32_SH0); x ^= (x << TINYMT32_SH0);
y ^= (y >> TINYMT32_SH0) ^ x; y ^= (y >> TINYMT32_SH0) ^ x;
s->status[0] = s->status[1]; s->status[0] = s->status[1];
s->status[1] = s->status[2]; s->status[1] = s->status[2];
s->status[2] = x ^ (y << TINYMT32_SH1); s->status[2] = x ^ (y << TINYMT32_SH1);
s->status[3] = y; s->status[3] = y;
s->status[1] ^= -((int32_t)(y & 1)) & s->mat1; s->status[1] ^= -((int32_t)(y & 1)) & s->mat1;
s->status[2] ^= -((int32_t)(y & 1)) & s->mat2; s->status[2] ^= -((int32_t)(y & 1)) & s->mat2;
} }
/** /**
* This function outputs 32-bit unsigned integer from internal state. * This function outputs 32-bit unsigned integer from internal state.
* @param s tinymt internal status * @param s pointer to tinymt internal state.
* @return 32-bit unsigned pseudos number * @return 32-bit unsigned pseudos number
*/ */
static uint32_t tinymt32_temper (tinymt32_t * s) static uint32_t tinymt32_temper (tinymt32_t * s)
{ {
uint32_t t0, t1; uint32_t t0, t1;
t0 = s->status[3]; t0 = s->status[3];
t1 = s->status[0] + (s->status[2] >> TINYMT32_SH8); t1 = s->status[0] + (s->status[2] >> TINYMT32_SH8);
t0 ^= t1; t0 ^= t1;
t0 ^= -((int32_t)(t1 & 1)) & s->tmat; t0 ^= -((int32_t)(t1 & 1)) & s->tmat;
return t0; return t0;
} }
/** /**
* This function outputs double precision floating point number from * This function outputs double precision floating point number from
* internal state. The returned value has 32-bit precision. * internal state. The returned value has 32-bit precision.
* In other words, this function makes one double precision floating * In other words, this function makes one double precision floating
* point number from one 32-bit unsigned integer. * point number from one 32-bit unsigned integer.
* @param s tinymt internal status * @param s pointer to tinymt internal state.
* @return floating point number r (0.0 <= r < 1.0) * @return floating point number r (0.0 <= r < 1.0)
*/ */
static double tinymt32_generate_32double (tinymt32_t * s) static double tinymt32_generate_32double (tinymt32_t * s)
{ {
tinymt32_next_state(s); tinymt32_next_state(s);
return (double)tinymt32_temper(s) * (1.0 / 4294967296.0); return (double)tinymt32_temper(s) * (1.0 / 4294967296.0);
} }
<CODE ENDS> <CODE ENDS>
Figure 8: TinyMT32 pseudo-code Figure 8: TinyMT32 pseudo-code
Appendix B. Decoding Beyond Maximum Latency Optimization Appendix B. Decoding Beyond Maximum Latency Optimization
This annex introduces non normative considerations. They are This annex introduces non normative considerations. It is provided
provided as suggestions, without any impact on interoperability. For as suggestions, without any impact on interoperability. For more
more information see [Roca16]. information see [Roca16].
With a real-time source ADU flow, it is possible to improve the With a real-time source ADU flow, it is possible to improve the
decoding performance of sliding window codes without impacting decoding performance of sliding window codes without impacting
maximum latency, at the cost of extra CPU overhead. The optimization maximum latency, at the cost of extra memory and CPU overhead. The
consists, for a FECFRAME receiver, to extend the linear system beyond optimization consists, for a FECFRAME receiver, to extend the linear
the decoding window maximum size, by keeping a certain number of old system beyond the decoding window maximum size, by keeping a certain
source symbols whereas their associated ADUs timed-out: number of old source symbols whereas their associated ADUs timed-out:
ls_max_size > dw_max_size ls_max_size > dw_max_size
Usually the following choice is a good trade-off between decoding Usually the following choice is a good trade-off between decoding
performance and extra CPU overhead: performance and extra CPU overhead:
ls_max_size = 2 * dw_max_size ls_max_size = 2 * dw_max_size
When the dw_max_size is very small, it may be preferable to keep a When the dw_max_size is very small, it may be preferable to keep a
minimum ls_max_size value (e.g., LS_MIN_SIZE_DEFAULT = 40 symbols). minimum ls_max_size value (e.g., LS_MIN_SIZE_DEFAULT = 40 symbols).
Going below this threshold will not save a significant amount of Going below this threshold will not save a significant amount of
memory nor CPU cycles. Therefore: memory nor CPU cycles. Therefore:
ls_max_size = max(2 * dw_max_size, LS_MIN_SIZE_DEFAULT) ls_max_size = max(2 * dw_max_size, LS_MIN_SIZE_DEFAULT)
Finally, it is worth noting that a good receiver, i.e., a receiver Finally, it is worth noting that a good receiver, i.e., a receiver
that benefits from a protection that is significantly sufficient to that benefits from an FEC protection significantly higher than what
recover from the packet losses, can choose to reduce its ls_max_size is required to recover from packet losses, can choose to reduce the
significantly. In that case lost ADUs will be recovered rapidly, ls_max_size. In that case lost ADUs will be recovered without
without relying on this optimization. relying on this optimization.
ls_max_size ls_max_size
/---------------------------------^-------------------------------\ /---------------------------------^-------------------------------\
late source symbols late source symbols
(pot. decoded but not delivered) dw_max_size (pot. decoded but not delivered) dw_max_size
/--------------^-----------------\ /--------------^---------------\ /--------------^-----------------\ /--------------^---------------\
src0 src1 src2 src3 src4 src5 src6 src7 src8 src9 src10 src11 src12 src0 src1 src2 src3 src4 src5 src6 src7 src8 src9 src10 src11 src12
Figure 9: Relationship between parameters to decode beyond maximum Figure 9: Relationship between parameters to decode beyond maximum
latency. latency.
It means that source symbols, and therefore ADUs, may be decoded even It means that source symbols, and therefore ADUs, may be decoded even
if the added latency exceeds the maximum value permitted by the if the added latency exceeds the maximum value permitted by the
application. It follows that the corresponding ADUs will not be application (the "late source symbols" of Figure 9). It follows that
useful to the application. However, decoding these "late symbols" the corresponding ADUs will not be useful to the application.
significantly improves the global robustness in bad reception However, decoding these "late symbols" significantly improves the
conditions and is therefore recommended for receivers experiencing global robustness in bad reception conditions and is therefore
bad communication conditions [Roca16]. In any case whether or not to recommended for receivers experiencing bad communication conditions
use this optimization and what exact value to use for the ls_max_size [Roca16]. In any case whether or not to use this optimization and
parameter are decisions made by each receiver independently, without what exact value to use for the ls_max_size parameter are local
any impact on the other receivers nor on the source. decisions made by each receiver independently, without any impact on
the other receivers nor on the source.
Authors' Addresses Authors' Addresses
Vincent Roca Vincent Roca
INRIA INRIA
Univ. Grenoble Alpes Univ. Grenoble Alpes
France France
EMail: vincent.roca@inria.fr EMail: vincent.roca@inria.fr
Belkacem Teibi Belkacem Teibi
INRIA INRIA
Univ. Grenoble Alpes Univ. Grenoble Alpes
 End of changes. 28 change blocks. 
196 lines changed or deleted 204 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/