draft-ietf-tsvwg-rlc-fec-scheme-01.txt | draft-ietf-tsvwg-rlc-fec-scheme-02.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: April 29, 2018 October 26, 2017 | Expires: September 5, 2018 March 4, 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-01 | draft-ietf-tsvwg-rlc-fec-scheme-02 | |||

Abstract | Abstract | |||

This document describes two fully-specified FEC Schemes for Sliding | This document describes two fully-specified FEC Schemes for Sliding | |||

Window Random Linear Codes (RLC), one for RLC over GF(2) (binary | Window Random Linear Codes (RLC), one for RLC over GF(2) (binary | |||

case), a second one for RLC over GF(2^^8), both of them with the | case), a second one for RLC over GF(2^^8), both of them with the | |||

possibility of controlling the code density. They are meant to | possibility of controlling the code density. They are meant to | |||

protect arbitrary media streams along the lines defined by FECFRAME | protect arbitrary media streams along the lines defined by FECFRAME | |||

extended to sliding window FEC codes. These sliding window FEC codes | extended to sliding window FEC codes. These sliding window FEC codes | |||

rely on an encoding window that slides over the source symbols, | rely on an encoding window that slides over the source symbols, | |||

skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||

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 April 29, 2018. | This Internet-Draft will expire on September 5, 2018. | |||

Copyright Notice | Copyright Notice | |||

Copyright (c) 2017 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 | |||

carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||

to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||

include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||

the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||

skipping to change at page 2, line 23 ¶ | skipping to change at page 2, line 23 ¶ | |||

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||

1.1. Limits of Block Codes with Real-Time Flows . . . . . . . 3 | 1.1. Limits of Block Codes with Real-Time Flows . . . . . . . 3 | |||

1.2. Lower Latency and Better Protection of Real-Time Flows | 1.2. Lower Latency and Better Protection of Real-Time Flows | |||

with the Sliding Window RLC Codes . . . . . . . . . . . . 4 | with the Sliding Window RLC Codes . . . . . . . . . . . . 4 | |||

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 . . . . . . . . . . . . . . . . . . 5 | 1.4. Document Organization . . . . . . . . . . . . . . . . . . 5 | |||

2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6 | 2. Definitions and Abbreviations . . . . . . . . . . . . . . . . 6 | |||

3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||

3.1. Parameters Derivation . . . . . . . . . . . . . . . . . . 6 | 3.1. Parameters Derivation . . . . . . . . . . . . . . . . . . 7 | |||

3.2. ADU, ADUI and Source Symbols Mappings . . . . . . . . . . 8 | 3.2. ADU, ADUI and Source Symbols Mappings . . . . . . . . . . 9 | |||

3.3. Encoding Window Management . . . . . . . . . . . . . . . 9 | 3.3. Encoding Window Management . . . . . . . . . . . . . . . 10 | |||

3.4. Pseudo-Random Number Generator . . . . . . . . . . . . . 10 | 3.4. Pseudo-Random Number Generator . . . . . . . . . . . . . 11 | |||

3.5. Coding Coefficients Generation Function . . . . . . . . . 11 | 3.5. Coding Coefficients Generation Function . . . . . . . . . 12 | |||

4. Sliding Window RLC FEC Scheme over GF(2) for Arbitrary ADU | 4. Sliding Window RLC FEC Scheme over GF(2^^8) for Arbitrary ADU | |||

Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||

4.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 13 | ||||

4.1.1. FEC Framework Configuration Information . . . . . . . 13 | ||||

4.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 13 | ||||

4.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 14 | ||||

4.1.4. Additional Procedures . . . . . . . . . . . . . . . . 14 | ||||

5. Sliding Window RLC FEC Scheme over GF(2^^8) for Arbitrary ADU | ||||

Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||

5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 14 | 4.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 14 | |||

5.1.1. FEC Framework Configuration Information . . . . . . . 14 | 4.1.1. FEC Framework Configuration Information . . . . . . . 14 | |||

5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 15 | 4.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 15 | |||

5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 16 | 4.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 16 | |||

5.1.4. Additional Procedures . . . . . . . . . . . . . . . . 17 | 4.1.4. Additional Procedures . . . . . . . . . . . . . . . . 17 | |||

6. FEC Code Specification . . . . . . . . . . . . . . . . . . . 17 | 5. Sliding Window RLC FEC Scheme over GF(2) for Arbitrary ADU | |||

6.1. Encoding Side . . . . . . . . . . . . . . . . . . . . . . 17 | Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||

6.2. Decoding Side . . . . . . . . . . . . . . . . . . . . . . 18 | 5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 18 | |||

7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 | 5.1.1. FEC Framework Configuration Information . . . . . . . 18 | |||

8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . 18 | |||

8.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 19 | 5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 18 | |||

8.1.1. Access to Confidential Content . . . . . . . . . . . 19 | 5.1.4. Additional Procedures . . . . . . . . . . . . . . . . 18 | |||

8.1.2. Content Corruption . . . . . . . . . . . . . . . . . 19 | 6. FEC Code Specification . . . . . . . . . . . . . . . . . . . 18 | |||

8.2. Attacks Against the FEC Parameters . . . . . . . . . . . 19 | 6.1. Encoding Side . . . . . . . . . . . . . . . . . . . . . . 18 | |||

8.3. When Several Source Flows are to be Protected Together . 20 | 6.2. Decoding Side . . . . . . . . . . . . . . . . . . . . . . 19 | |||

8.4. Baseline Secure FEC Framework Operation . . . . . . . . . 20 | 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 20 | |||

9. Operations and Management Considerations . . . . . . . . . . 20 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||

8.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 20 | ||||

8.1.1. Access to Confidential Content . . . . . . . . . . . 20 | ||||

8.1.2. Content Corruption . . . . . . . . . . . . . . . . . 21 | ||||

8.2. Attacks Against the FEC Parameters . . . . . . . . . . . 21 | ||||

8.3. When Several Source Flows are to be Protected Together . 21 | ||||

8.4. Baseline Secure FEC Framework Operation . . . . . . . . . 21 | ||||

9. Operations and Management Considerations . . . . . . . . . . 22 | ||||

9.1. Operational Recommendations: Finite Field GF(2) Versus | 9.1. Operational Recommendations: Finite Field GF(2) Versus | |||

GF(2^^8) . . . . . . . . . . . . . . . . . . . . . . . . 21 | GF(2^^8) . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||

9.2. Operational Recommendations: Coding Coefficients Density | 9.2. Operational Recommendations: Coding Coefficients Density | |||

Threshold . . . . . . . . . . . . . . . . . . . . . . . . 21 | Threshold . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||

10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | |||

11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 | |||

12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||

12.1. Normative References . . . . . . . . . . . . . . . . . . 22 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 | |||

12.2. Informative References . . . . . . . . . . . . . . . . . 22 | 12.2. Informative References . . . . . . . . . . . . . . . . . 24 | |||

Appendix A. Decoding Beyond Maximum Latency Optimization . . . . 24 | Appendix A. Decoding Beyond Maximum Latency Optimization . . . . 26 | |||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 | |||

1. Introduction | 1. Introduction | |||

Application-Level Forward Erasure Correction (AL-FEC) codes are a key | Application-Level Forward Erasure Correction (AL-FEC) codes, or | |||

element of communication systems. They are used to recover from | simply FEC codes, are a key element of communication systems. They | |||

packet losses (or erasures) during content delivery sessions to a | are used to recover from packet losses (or erasures) during content | |||

large number of receivers (multicast/broadcast transmissions). This | delivery sessions to a large number of receivers (multicast/broadcast | |||

is the case with the FLUTE/ALC protocol [RFC6726] in case of reliable | transmissions). This is the case with the FLUTE/ALC protocol | |||

file transfers over lossy networks, and the FECFRAME protocol for | [RFC6726] in case of reliable file transfers over lossy networks, and | |||

reliable continuous media transfers over lossy networks. | the FECFRAME protocol for reliable continuous media transfers over | |||

lossy networks. | ||||

The present document only focusses on the FECFRAME protocol, used in | The present document only focusses on the FECFRAME protocol, used in | |||

multicast/broadcast delivery mode, with contents that feature | multicast/broadcast delivery mode, with contents that feature | |||

stringent real-time constraints: each source packet has a maximum | stringent real-time constraints: each source packet has a maximum | |||

validity period after which it will not be considered by the | validity period after which it will not be considered by the | |||

destination application. | destination application. | |||

1.1. Limits of Block Codes with Real-Time Flows | 1.1. Limits of Block Codes with Real-Time Flows | |||

With FECFRAME, there is a single FEC encoding point (either a end- | With FECFRAME, there is a single FEC encoding point (either a end- | |||

host/server (source) or a middlebox) and a single FEC decoding point | host/server (source) or a middlebox) and a single FEC decoding point | |||

(either a end-host (receiver) or middlebox). In this context, | (either a end-host (receiver) or middlebox). In this context, | |||

currently standardized AL-FEC codes for FECFRAME like Reed-Solomon | currently standardized AL-FEC codes for FECFRAME like Reed-Solomon | |||

[RFC6865], LDPC-Staircase [RFC6816], or Raptor/RaptorQ, are all | [RFC6865], LDPC-Staircase [RFC6816], or Raptor/RaptorQ, are all | |||

linear block codes: they require the data flow to be segmented into | linear block codes: they require the data flow to be segmented into | |||

blocks of a predefined maximum size. The block size is a balance | blocks of a predefined maximum size. | |||

between robustness (in particular in front of long erasure bursts for | ||||

which there is an incentive to increase the block size) and maximum | Defining this block size requires to find an appropriate balance | |||

decoding latency (for which there is an incentive to decrease the | between robustness and decoding latency: the larger the block size, | |||

block size). Therefore, with a multicast/broadcast session, the | the higher the robustness (e.g., in front of long packet erasure | |||

block code is dimensioned by considering the worst communication | bursts), but also the higher the maximum decoding latency (i.e., the | |||

channel one wants to support, and this choice impacts all receivers, | maximum time required to recover an lost (erased) packet thanks to | |||

no matter their individual channel quality. | FEC protection). Therefore, with a multicast/broadcast session where | |||

different receivers experience different packet loss rates, the block | ||||

size should be chosen by considering the worst communication | ||||

conditions one wants to support, but without exceeding the desired | ||||

maximum decoding latency. This choice will impact all receivers. | ||||

1.2. Lower Latency and Better Protection of Real-Time Flows with the | 1.2. Lower Latency and Better Protection of Real-Time Flows with the | |||

Sliding Window RLC Codes | Sliding Window RLC Codes | |||

This document introduces two fully-specified FEC Schemes that follow | This document introduces two fully-specified FEC Schemes that follow | |||

a totally different approach: the Sliding Window Random Linear Codes | a totally different approach: the Sliding Window Random Linear Codes | |||

(RLC) over either Finite Field GF(2) or GF(8). These FEC Schemes are | (RLC) over either Finite Field GF(2) or GF(8). These FEC Schemes are | |||

used to protect arbitrary media streams along the lines defined by | used to protect arbitrary media streams along the lines defined by | |||

FECFRAME extended to sliding window FEC codes [fecframe-ext]. These | FECFRAME extended to sliding window FEC codes [fecframe-ext]. These | |||

FEC Schemes are extremely efficient for instance with media that | FEC Schemes are extremely efficient for instance with media that | |||

skipping to change at page 4, line 32 ¶ | skipping to change at page 4, line 35 ¶ | |||

(symbols) are generated and sent on-the-fly, after computing a random | (symbols) are generated and sent on-the-fly, after computing a random | |||

linear combination of the source symbols present in the current | linear combination of the source symbols present in the current | |||

encoding window. | encoding window. | |||

At the receiver, a linear system is managed from the set of received | At the receiver, a linear system is managed from the set of received | |||

source and repair packets. New variables (representing source | source and repair packets. New variables (representing source | |||

symbols) and equations (representing the linear combination of each | symbols) and equations (representing the linear combination of each | |||

repair symbol received) are added upon receiving new packets. | repair symbol received) are added upon receiving new packets. | |||

Variables are removed when they are too old with respect to their | Variables are removed when they are too old with respect to their | |||

validity period (real-time constraints), as well as the associated | validity period (real-time constraints), as well as the associated | |||

equations they are involved in (Appendix A introduces an optimisation | equations they are involved in (Appendix A introduces an optimization | |||

that extends the time a variable is considered in the system). | that extends the time a variable is considered in the system). Lost | |||

Erased source symbols are then recovered thanks this linear system | source symbols are then recovered thanks to this linear system | |||

whenever its rank permits it. | whenever its rank permits it. | |||

With RLC codes (more generally with sliding window codes), the | With RLC codes (more generally with sliding window codes), the | |||

protection of a multicast/broadcast session also needs to be | protection of a multicast/broadcast session also needs to be | |||

dimensioned by considering the worst communication channel one wants | dimensioned by considering the worst communication conditions one | |||

to support. However the receivers experiencing a good to medium | wants to support. However the receivers experiencing a good to | |||

channel quality observe a FEC-related latency close to zero [Roca17] | medium communication quality will observe a FEC-related latency close | |||

since an isolated erased source packet is quickly recovered by the | to zero [Roca17] since an isolated lost source packet is quickly | |||

following repair packet. On the opposite, with a block code, | recovered with the following repair packet. On the opposite, with a | |||

recovering an isolated erased source packet always requires waiting | block code, recovering an isolated lost source packet always requires | |||

the end of the block for the first repair packet to arrive. | waiting the end of the block for the first repair packet to arrive. | |||

Additionally, under certain situations (e.g., with a limited FEC- | Additionally, under certain situations (e.g., with a limited FEC- | |||

related latency budget and with constant bit rate transmissions after | related latency budget and with constant bit rate transmissions after | |||

FECFRAME encoding), sliding window codes achieve more easily a target | FECFRAME encoding), sliding window codes achieve more easily a target | |||

transmission quality (e.g., measured by the residual loss after FEC | transmission quality (e.g., measured by the residual loss after FEC | |||

decoding) by sending fewer repair packets (i.e., higher code rate) | decoding) by sending fewer repair packets (i.e., higher code rate) | |||

than block codes. | than block codes. | |||

1.3. Small Transmission Overheads with the Sliding Window RLC FEC | 1.3. Small Transmission Overheads with the Sliding Window RLC FEC | |||

Scheme | Scheme | |||

The Sliding Window RLC FEC Scheme is designed so as to reduce the | The Sliding Window RLC FEC Scheme is designed so as to reduce the | |||

transmission overhead. The main requirement is that each repair | transmission overhead. The main requirement is that each repair | |||

packet header must enable a receiver to reconstruct the list of | packet header must enable a receiver to reconstruct the set of source | |||

source symbols and the associated random coefficients used during the | symbols plus the associated coefficients used during the encoding | |||

encoding process. In order to minimize packet overhead, the set of | process. In order to minimize packet overhead, the set of source | |||

symbols in the encoding window as well as the set of coefficients | symbols in the encoding window as well as the set of coefficients | |||

over GF(2^^m) (where m is 1 or 8, depending on the FEC Scheme) used | over GF(2^^m) (where m is 1 or 8, depending on the FEC Scheme) used | |||

in the linear combination are not individually listed in the repair | in the linear combination are not individually listed in the repair | |||

packet header. Instead, each FEC repair packet header contains: | packet header. Instead, each FEC Repair Packet header contains: | |||

o the Encoding Symbol Identifier (ESI) of the first source symbol in | o the Encoding Symbol Identifier (ESI) of the first source symbol in | |||

the encoding window as well as the number of symbols (since this | the encoding window as well as the number of symbols (since this | |||

number may vary with a variable size, elastic window). These two | number may vary with a variable size, elastic window). These two | |||

pieces of information enable each receiver to easily reconstruct | pieces of information enable each receiver to easily reconstruct | |||

the set of source symbols considered during encoding, the only | the set of source symbols considered during encoding, the only | |||

constraint being that there cannot be any gap; | constraint being that there cannot be any gap; | |||

o the seed used by a coding coefficients generation function | o the seed used by a coding coefficients generation function | |||

(Section 3.5). This information enables each receiver to generate | (Section 3.5). This information enables each receiver to generate | |||

the same set of coding coefficients over GF(2^^m) as the sender; | the same set of coding coefficients over GF(2^^m) as the sender; | |||

Therefore, no matter the number of source symbols present in the | Therefore, no matter the number of source symbols present in the | |||

encoding window, each FEC repair packet features a fixed 64-bit long | encoding window, each FEC Repair Packet features a fixed 64-bit long | |||

header, called Repair FEC Payload ID (Figure 7). Similarly, each FEC | header, called Repair FEC Payload ID (Figure 7). Similarly, each FEC | |||

source packet features a fixed 32-bit long trailer, called Explicit | Source Packet features a fixed 32-bit long trailer, called Explicit | |||

Source FEC Payload ID (Figure 5), that contains the ESI of the first | Source FEC Payload ID (Figure 5), that contains the ESI of the first | |||

source symbol (see the ADUI and source symbol mapping, Section 3.2). | source symbol (see the ADUI and source symbol mapping, Section 3.2). | |||

1.4. Document Organization | 1.4. Document Organization | |||

This fully-specified FEC Scheme follows the structure required by | This fully-specified FEC Scheme follows the structure required by | |||

[RFC6363], section 5.6. "FEC Scheme Requirements", namely: | [RFC6363], section 5.6. "FEC Scheme Requirements", namely: | |||

3. Procedures: This section describes procedures specific to this | 3. Procedures: This section describes procedures specific to this | |||

FEC Scheme, namely: RLC parameters derivation, ADUI and source | FEC Scheme, namely: RLC parameters derivation, ADUI and source | |||

skipping to change at page 6, line 20 ¶ | skipping to change at page 6, line 23 ¶ | |||

This document uses the following definitions and abbreviations: | This document uses the following definitions and abbreviations: | |||

GF(q) denotes a finite field (also known as the Galois Field) with q | GF(q) denotes a finite field (also known as the Galois Field) with q | |||

elements. We assume that q = 2^^m in this document | elements. We assume that q = 2^^m in this document | |||

m defines the length of the elements in the finite field, in bits. | m defines the length of the elements in the finite field, in bits. | |||

In this document, m is equal to 1 or 8 | In this document, m is equal to 1 or 8 | |||

ADU: Application Data Unit | ADU: Application Data Unit | |||

ADUI: Application Data Unit Information (includes the F, L and | ADUI: Application Data Unit Information (includes the F, L and | |||

padding fields in addition to the ADU) | padding fields in addition to the ADU) | |||

E: encoding symbol size (i.e., source or repair symbol), assumed | E: size of an encoding symbol (i.e., source or repair symbol), | |||

fixed (in bytes) | assumed fixed (in bytes) | |||

br_in: transmission bitrate at the input of the FECFRAME sender, | ||||

assumed fixed (in bits/s) | ||||

br_out: transmission bitrate at the output of the FECFRAME sender, | br_out: transmission bitrate at the output of the FECFRAME sender, | |||

assumed fixed (in bits/s) | assumed fixed (in bits/s) | |||

max_lat: maximum FEC-related latency within FECFRAME (in seconds) | max_lat: maximum FEC-related latency within FECFRAME (in seconds) | |||

cr: AL-FEC coding rate | cr: RLC coding rate, ratio between the total number of source | |||

plr: packet loss rate on the erasure channel | symbols and the total number of source plus repair symbols | |||

plr: packet loss rate on the packet erasure channel | ||||

ew_size: encoding window current size at a sender (in symbols) | ew_size: encoding window current size at a sender (in symbols) | |||

ew_max_size: encoding window maximum size at a sender (in symbols) | ew_max_size: encoding window maximum size at a sender (in symbols) | |||

dw_size: decoding window current size at a receiver (in symbols) | ||||

dw_max_size: decoding window maximum size at a receiver (in symbols) | dw_max_size: decoding window maximum size at a receiver (in symbols) | |||

ls_max_size: linear system maximum size (or width) at a receiver (in | ls_max_size: linear system maximum size (or width) at a receiver (in | |||

symbols) | symbols) | |||

ls_size: linear system current size (or width) at a receiver (in | ||||

symbols) | ||||

PRNG: pseudo-random number generator | PRNG: pseudo-random number generator | |||

pmms_rand(maxv): PRNG defined in Section 3.4 and used in this | pmms_rand(maxv): PRNG defined in Section 3.4 and used in this | |||

specification, that returns a new random integer in [0; maxv-1] | specification, that returns a new random integer in [0; maxv-1] | |||

DT: coding coefficients density threshold, an integer between 0 and | ||||

15 (inclusive) the controls the fraction of coefficients that are | ||||

non zero | ||||

3. Procedures | 3. Procedures | |||

This section introduces the procedures that are used by this FEC | This section introduces the procedures that are used by this FEC | |||

Scheme. | Scheme. | |||

3.1. Parameters Derivation | 3.1. Parameters Derivation | |||

The Sliding Window RLC FEC Scheme relies on several key internal | The Sliding Window RLC FEC Scheme relies on several key parameters: | |||

parameters: | ||||

Maximum FEC-related latency budget, max_lat (in seconds) A source | Maximum FEC-related latency budget, max_lat (in seconds) A source | |||

ADU flow can have real-time constraints, and therefore any | ADU flow can have real-time constraints, and therefore any | |||

FECFRAME related operation must take place within the validity | FECFRAME related operation must take place within the validity | |||

period of each ADU. When there are multiple flows with different | period of each ADU. When there are multiple flows with different | |||

real-time constraints, we consider the most stringent constraints | real-time constraints, we consider the most stringent constraints | |||

(see [RFC6363], Section 10.2, item 6, for recommendations when | (see [RFC6363], Section 10.2, item 6, for recommendations when | |||

several flows are globally protected). This maximum FEC-related | several flows are globally protected). The maximum FEC-related | |||

latency accounts for all sources of latency added by FEC encoding | latency budget, max_lat, accounts for all sources of latency added | |||

(sender) and FEC decoding (receiver). Other sources of latency | by FEC encoding (at a sender) and FEC decoding (at a receiver). | |||

(e.g., added by network communications) are out of scope and must | Other sources of latency (e.g., added by network communications) | |||

be considered separately (e.g., they have already been deducted). | are out of scope and must be considered separately (said | |||

It can be regarded as the latency budget permitted for all FEC- | differently, they have already been deducted from max_lat). | |||

related operations. This is also an input parameter that enables | max_lat can be regarded as the latency budget permitted for all | |||

to derive other internal parameters; | FEC-related operations. This is an input parameter that enables | |||

to derive other internal parameters as explained below; | ||||

Encoding window current (resp. maximum) size, ew_size (resp. | Encoding window current (resp. maximum) size, ew_size (resp. | |||

ew_max_size) (in symbols): | ew_max_size) (in symbols): | |||

these parameters are used by a sender during FEC encoding. More | these parameters are used by a sender during FEC encoding. More | |||

precisely, each repair symbol is a linear combination of the | precisely, each repair symbol is a linear combination of the | |||

ew_size source symbols present in the encoding window when RLC | ew_size source symbols present in the encoding window when RLC | |||

encoding took place. In all situations, we MUST have ew_size <= | encoding took place. In all situations, we MUST have: | |||

ew_max_size; | ||||

Decoding window current (resp. maximum) size, dw_size (resp. | ||||

dw_max_size) (in symbols): | ||||

these parameters are used by a receiver when managing the linear | ||||

system used for decoding. dw_size is the current size of the | ||||

decoding window, i.e., the set of received or erased source | ||||

symbols that are currently part of the linear system. In all | ||||

situations, we MUST have dw_size <= dw_max_size; | ||||

In order to comply with the maximum FEC-related latency budget, | ew_size <= ew_max_size | |||

assuming a constant transmission bitrate at the output of the | Decoding window maximum size, dw_max_size (in symbols): at a | |||

FECFRAME sender (br_out), encoding symbol size (E), and code rate | receiver, this parameter determines the maximum size of the | |||

(cr), we have: | decoding window. Said differently, this is the maximum number of | |||

received or lost source symbols in the linear system (i.e., the | ||||

variables) that are still within their latency budget. In | ||||

situations where packets are sent with a fixed period, the | ||||

dw_max_size parameter directly determines the maximum decoding | ||||

latency experienced by the receiver, which necessarily needs to be | ||||

in line with the maximum FEC-related latency budget. Note also | ||||

that the optimization detailed in Appendix A can extend the linear | ||||

system with additional old source symbols (that timed-out) beyond | ||||

dw_max_size; | ||||

Symbol size, E (in bytes) and RLC code rate (cr): the E parameter | ||||

determines the (source or repair) symbol sizes. The cr parameter | ||||

determines the code rate, i.e., the amount of redundancy added to | ||||

the flow (it is the ratio between the total number of source | ||||

symbols and the total number of source plus repair symbols). | ||||

These two parameters are input parameters that enable to derive | ||||

other internal parameters as explained below. In practice they | ||||

will usually be fixed, especially with multicast/broadcast | ||||

transmissions. In specific use-cases, in particular with unicast | ||||

transmissions in presence of a feedback mechanism that estimates | ||||

the communication quality (out-of-scope of FECFRAME), the code | ||||

rate may be adjusted dynamically. | ||||

Let us assume that the encoding symbol size (E, in bytes) and code | ||||

rate (cr) are constant. Let us also assume a constant transmission | ||||

bitrate (br_out, in bits/s) at the output of the FECFRAME sender (as | ||||

in [Roca17]). It means that the source flow bitrate needs to be | ||||

adjusted according to the added repair flow overhead in order to keep | ||||

the total transmission bitrate fixed and equal to br_out. In order | ||||

to comply with the maximum FEC-related latency budget we need: | ||||

dw_max_size = (max_lat * br_out * cr) / (8 * E) | dw_max_size = (max_lat * br_out * cr) / (8 * E) | |||

This dw_max_size defines the maximum delay after which an old source | Sometimes the opposite can happen: the source flow bitrate at the | |||

symbol may be recovered: after this delay, this old source symbol | input of the FECFRAME sender is fixed (br_in, in bits/s). It means | |||

symbol will be removed from the decoding window. | that the transmission bitrate at the output of the FECFRAME sender | |||

will be higher, depending on the added repair flow overhead. In | ||||

order to comply with the maximum FEC-related latency budget we need: | ||||

It is often good practice to choose: | dw_max_size = (max_lat * br_in) / (8 * E) | |||

ew_max_size = dw_max_size / 2 | Finally, there are situations where no such assumption can be made | |||

(e.g., with a variable bit rate input flow). In that case the | ||||

encoding and decoding window maximum sizes may be initialized, based | ||||

on the input flow features (e.g., the peak bitrate if it is known) | ||||

and great care must be taken on timing aspects at a sender (see | ||||

Section 3.3) and receiver. The details of how to manage these | ||||

situations are use-case dependent and out of scope of this document. | ||||

Then, once the dw_max_size has been determined, the ew_max_size can | ||||

be defined. For decoding to be possible, it is required that the | ||||

encoding window maximum size be at most equal to the decoding window | ||||

maximum size. It is often good practice to choose [Roca17]: | ||||

ew_max_size = dw_max_size * 0.75 | ||||

However any value ew_max_size < dw_max_size can be used without | However any value ew_max_size < dw_max_size can be used without | |||

impact on the FEC-related latency budget. Finding the optimal value | impact on the FEC-related latency budget. Finding the optimal value | |||

can depend on the erasure channel one wants to support and should be | will depend on the use-case details and should be determined after | |||

determined after simulations or field trials. | simulations or field trials. This is of course out of scope of this | |||

document. | ||||

Note that the decoding beyond maximum latency optimisation | Note that the decoding beyond maximum latency optimization | |||

(Appendix A) enables an old source symbol to be kept in the linear | (Appendix A) enables an old source symbol to be kept in the linear | |||

system beyond the FEC-related latency budget, but not delivered to | system beyond the FEC-related latency budget, but not delivered to | |||

the receiving application. Here we have: ls_size >= dw_max_size | the receiving application. In any case, the linear system maximum | |||

size is greater than (with the decoding optimization) or equal to | ||||

(without) the decoding window maximum size: | ||||

ls_max_size >= dw_max_size | ||||

3.2. ADU, ADUI and Source Symbols Mappings | 3.2. ADU, ADUI and Source Symbols Mappings | |||

An ADU, coming from the application, cannot be mapped to source | An ADU, coming from the application, cannot be mapped to source | |||

symbols directly. Indeed, an erased ADU recovered at a receiver must | symbols directly. Indeed, a lost ADU recovered at a receiver must | |||

contain enough information to be assigned to the right application | contain enough information to be assigned to the right application | |||

flow (UDP port numbers and IP addresses cannot be used to that | flow (UDP port numbers and IP addresses cannot be used to that | |||

purpose as they are not protected by FEC encoding). This requires | purpose as they are not protected by FEC encoding). This requires | |||

adding the flow identifier to each ADU before doing FEC encoding. | adding the flow identifier to each ADU before doing FEC encoding. | |||

Additionally, since ADUs are of variable size, padding is needed so | Additionally, since ADUs are of variable size, padding is needed so | |||

that each ADU (with its flow identifier) contribute to an integral | that each ADU (with its flow identifier) contribute to an integral | |||

number of source symbols. This requires adding the original ADU | number of source symbols. This requires adding the original ADU | |||

length to each ADU before doing FEC encoding. Because of these | length to each ADU before doing FEC encoding. Because of these | |||

requirements, an intermediate format, the ADUI, or ADU Information, | requirements, an intermediate format, the ADUI, or ADU Information, | |||

is considered [RFC6363]. | is considered [RFC6363]. | |||

For each incoming ADU, an ADUI is created as follows. First of all, | For each incoming ADU, an ADUI is created as follows. First of all, | |||

3 bytes are prepended: (Figure 1): | 3 bytes are prepended (Figure 1): | |||

Flow ID (F) (8-bit field): this unsigned byte contains the integer | Flow ID (F) (8-bit field): this unsigned byte contains the integer | |||

identifier associated to the source ADU flow to which this ADU | identifier associated to the source ADU flow to which this ADU | |||

belongs. It is assumed that a single byte is sufficient, which | belongs. It is assumed that a single byte is sufficient, which | |||

implies that no more than 256 flows will be protected by a single | implies that no more than 256 flows will be protected by a single | |||

FECFRAME instance. | FECFRAME instance. | |||

Length (L) (16-bit field): this unsigned integer contains the length | Length (L) (16-bit field): this unsigned integer contains the length | |||

of this ADU, in network byte order (i.e., big endian). This | of this ADU, in network byte order (i.e., big endian). This | |||

length is for the ADU itself and does not include the F, L, or Pad | length is for the ADU itself and does not include the F, L, or Pad | |||

fields. | fields. | |||

Then, zero padding is added to the ADU if needed: | Then, zero padding is added to the ADU if needed: | |||

Padding (Pad) (variable size field): this field contains zero | Padding (Pad) (variable size field): this field contains zero | |||

padding to align the F, L, ADU and padding up to a size that is | padding to align the F, L, ADU and padding up to a size that is | |||

multiple of E bytes (i.e., the source and repair symbol length). | multiple of E bytes (i.e., the source and repair symbol length). | |||

Each ADUI contributes to an integral number of source symbols. The | The data unit resulting from the ADU and the F, L, and Pad fields is | |||

data unit resulting from the ADU and the F, L, and Pad fields is | called ADUI. Since ADUs can have different sizes, this is also the | |||

called ADU Information (or ADUI). Since ADUs can be of different | case for ADUIs. However an ADUI always contributes to an integral | |||

size, this is also the case for ADUIs. | number of source symbols. | |||

symbol length, E E E | symbol length, E E E | |||

< ------------------ >< ------------------ >< ------------------ > | < ------------------ >< ------------------ >< ------------------ > | |||

+-+--+---------------------------------------------+-------------+ | +-+--+---------------------------------------------+-------------+ | |||

|F| L| ADU | Pad | | |F| L| ADU | Pad | | |||

+-+--+---------------------------------------------+-------------+ | +-+--+---------------------------------------------+-------------+ | |||

Figure 1: ADUI Creation example (here 3 source symbols are created | Figure 1: ADUI Creation example (here 3 source symbols are created | |||

for this ADUI). | for this ADUI). | |||

Note that neither the initial 3 bytes nor the optional padding are | Note that neither the initial 3 bytes nor the optional padding are | |||

sent over the network. However, they are considered during FEC | sent over the network. However, they are considered during FEC | |||

encoding. It means that a receiver who lost a certain FEC source | encoding, and a receiver who lost a certain FEC Source Packet (e.g., | |||

packet (e.g., the UDP datagram containing this FEC source packet) | the UDP datagram containing this FEC Source Packet) will be able to | |||

will be able to recover the ADUI if FEC decoding succeeds. Thanks to | recover the ADUI if FEC decoding succeeds. Thanks to the initial 3 | |||

the initial 3 bytes, this receiver will get rid of the padding (if | bytes, this receiver will get rid of the padding (if any) and | |||

any) and identify the corresponding ADU flow. | identify the corresponding ADU flow. | |||

3.3. Encoding Window Management | 3.3. Encoding Window Management | |||

Source symbols and the corresponding ADUs are removed from the | Source symbols and the corresponding ADUs are removed from the | |||

encoding window: | encoding window: | |||

o when the sliding encoding window has reached its maximum size, | o when the sliding encoding window has reached its maximum size, | |||

ew_max_size. In that case the oldest symbol MUST be removed | ew_max_size. In that case the oldest symbol MUST be removed | |||

before adding a new symbol, so that the current encoding window | before adding a new symbol, so that the current encoding window | |||

size always remains inferior or equal to the maximum size: ew_size | size always remains inferior or equal to the maximum size: ew_size | |||

<= ew_max_size; | <= ew_max_size; | |||

o when an ADU has reached its maximum validity duration in case of a | o when an ADU has reached its maximum validity duration in case of a | |||

real-time flow. When this happens, all source symbols | real-time flow. When this happens, all source symbols | |||

corresponding to the ADUI that expired SHOULD be removed from the | corresponding to the ADUI that expired SHOULD be removed from the | |||

encoding window; | encoding window; | |||

Source symbols are added to the sliding encoding window each time a | Source symbols are added to the sliding encoding window each time a | |||

new ADU arrives, once the ADU to ADUI and then to source symbols | new ADU arrives, once the ADU to source symbols mapping has been | |||

mapping has been performed (Section 3.2). The current size of the | performed (Section 3.2). The current size of the encoding window, | |||

encoding window, ew_size, is updated after adding new source symbols. | ew_size, is updated after adding new source symbols. This process | |||

This process may require to remove old source symbols so that: | may require to remove old source symbols so that: ew_size <= | |||

ew_size <= ew_max_size. | ew_max_size. | |||

Note that a FEC codec may feature practical limits in the number of | Note that a FEC codec may feature practical limits in the number of | |||

source symbols in the encoding window (e.g., for computational | source symbols in the encoding window (e.g., for computational | |||

complexity reasons). This factor may further limit the ew_max_lat | complexity reasons). This factor may further limit the ew_max_size | |||

value, in addition to the maximum FEC-related latency budget | value, in addition to the maximum FEC-related latency budget | |||

(Section 3.1). | (Section 3.1). | |||

3.4. Pseudo-Random Number Generator | 3.4. Pseudo-Random Number Generator | |||

The RLC codes rely on the following Pseudo-Random Number Generator | The RLC codes rely on the following Pseudo-Random Number Generator | |||

(PRNG), identical to the PRNG used with LDPC-Staircase codes | (PRNG), identical to the PRNG used with LDPC-Staircase codes | |||

([RFC5170], section 5.7). | ([RFC5170], section 5.7). | |||

The Park-Miler "minimal standard" PRNG [PM88] MUST be used. It | The Park-Miler "minimal standard" PRNG [PM88] MUST be used. It | |||

skipping to change at page 11, line 16 ¶ | skipping to change at page 12, line 16 ¶ | |||

implements the Park-Miller "minimal standard" algorithm, defined | implements the Park-Miller "minimal standard" algorithm, defined | |||

above, and that scales the raw value between 0 and maxv-1 inclusive, | above, and that scales the raw value between 0 and maxv-1 inclusive, | |||

using the above scaling algorithm. | using the above scaling algorithm. | |||

Additionally, the pmms_srand(seed) function must be provided to | Additionally, the pmms_srand(seed) function must be provided to | |||

enable the initialization of the PRNG with a seed before calling | enable the initialization of the PRNG with a seed before calling | |||

pmms_rand(maxv) the first time. The seed is a 31-bit integer between | pmms_rand(maxv) the first time. The seed is a 31-bit integer between | |||

1 and 0x7FFFFFFE inclusive. In this specification, the seed is | 1 and 0x7FFFFFFE inclusive. In this specification, the seed is | |||

restricted to a value between 1 and 0xFFFF inclusive, as this is the | restricted to a value between 1 and 0xFFFF inclusive, as this is the | |||

Repair_Key 16-bit field value of the Repair FEC Payload ID | Repair_Key 16-bit field value of the Repair FEC Payload ID | |||

(Section 5.1.3). | (Section 4.1.3). | |||

3.5. Coding Coefficients Generation Function | 3.5. Coding Coefficients Generation Function | |||

The coding coefficients, used during the encoding process, are | The coding coefficients, used during the encoding process, are | |||

generated at the RLC encoder by the generate_coding_coefficients() | generated at the RLC encoder by the generate_coding_coefficients() | |||

function each time a new repair symbol needs to be produced. Note | function each time a new repair symbol needs to be produced. The | |||

that the fraction of coefficients that are non zero (density) is | fraction of coefficients that are non zero (i.e., the density) is | |||

controlled by a dedicated parameter, DT (Density Threshold). When | controlled by the DT (Density Threshold) parameter. When DT equals | |||

this parameter equals 15, the maximum value, the function guaranties | 15, the maximum value, the function guaranties that all coefficients | |||

that all coefficients are non zero (i.e., maximum density). When the | are non zero (i.e., maximum density). When DT is between 0 (minimum | |||

parameter is between 0 (minimum value) and strictly inferior to 15, | value) and strictly inferior to 15, the average probability of having | |||

the average probability of having a non zero coefficients equals (DT | a non zero coefficient equals (DT +1) / 16. | |||

+1) / 16. The density is reduced in a controlled manner. | ||||

These considerations apply both the RLC over GF(2) and RLC over | These considerations apply both the RLC over GF(2) and RLC over | |||

GF(2^^8), the only difference being the value of the m parameter. | GF(2^^8), the only difference being the value of the m parameter. | |||

With the RLC over GF(2) FEC Scheme (Section 4), m MUST be equal to 1. | With the RLC over GF(2) FEC Scheme (Section 5), m MUST be equal to 1. | |||

With RLC over GF(2^^8) FEC Scheme (Section 5), m MUST be equal to 8. | With RLC over GF(2^^8) FEC Scheme (Section 4), m MUST be equal to 8. | |||

<CODE BEGINS> | <CODE BEGINS> | |||

/* | /* | |||

* Fills in the table of coding coefficients (of the right size) | * Fills in the table of coding coefficients (of the right size) | |||

* provided with the appropriate number of coding coefficients to | * provided with the appropriate number of coding coefficients to | |||

* use for the repair symbol key provided. | * use for the repair symbol key provided. | |||

* | * | |||

* (in) repair_key key associated to this repair symbol | * (in) repair_key key associated to this repair symbol. This | |||

* parameter is ignored (useless) if m=2 and dt=15 | ||||

* (in) cc_tab[] pointer to a table of the right size to store | * (in) cc_tab[] pointer to a table of the right size to store | |||

* coding coefficients. All coefficients are | * coding coefficients. All coefficients are | |||

* stored as bytes, regardless of the m parameter, | * stored as bytes, regardless of the m parameter, | |||

* upon return of this function. | * upon return of this function. | |||

* (in) cc_nb[] number of entries in the table. This value is | * (in) cc_nb number of entries in the table. This value is | |||

* equal to the current encoding window size. | * equal to the current encoding window size. | |||

* (in) density_threshold value between 0 and 15 (inclusive) that | * (in) dt integer between 0 and 15 (inclusive) that | |||

* controls the density. With value 15, all | * controls the density. With value 15, all | |||

* coefficients are guaranteed to be non zero | * coefficients are guaranteed to be non zero | |||

* (i.e. equal to 1 with GF(2) and equal to a | * (i.e. equal to 1 with GF(2) and equal to a | |||

* value in {1,... 255} with GF(2^^8)), otherwise | * value in {1,... 255} with GF(2^^8)), otherwise | |||

* a fraction of them will be 0. | * a fraction of them will be 0. | |||

* (in) m Finite Field GF(2^^m) parameter. In this | * (in) m Finite Field GF(2^^m) parameter. In this | |||

* version only 1 and 8 are considered. | * document only values 1 and 8 are considered. | |||

* (out) returns an error code | * (out) returns an error code | |||

*/ | */ | |||

int generate_coding_coefficients (UINT16 repair_key, | int generate_coding_coefficients (UINT16 repair_key, | |||

UINT8 cc_tab[], | UINT8 cc_tab[], | |||

UINT16 cc_nb, | UINT16 cc_nb, | |||

UINT8 density_threshold, | UINT8 dt, | |||

UINT8 m) | UINT8 m) | |||

{ | { | |||

UINT32 i; | UINT32 i; | |||

if (repair_key == 0 || density_threshold > 15) { | if (dt > 15) { | |||

/* bad parameters */ | return SOMETHING_WENT_WRONG; /* bad dt parameter */ | |||

return SOMETHING_WENT_WRONG; | } | |||

if (repair_key == 0 && dt != 15 && m != 2) { | ||||

return SOMETHING_WENT_WRONG; /* bad repair_key parameter */ | ||||

} | } | |||

pmms_srand(repair_key); | ||||

switch (m) { | switch (m) { | |||

case 1: | case 1: | |||

if (density_threshold == 15) { | if (dt == 15) { | |||

/* all coefficients are 1 */ | /* all coefficients are 1 */ | |||

memset(cc_tab, 1, cc_nb); | memset(cc_tab, 1, cc_nb); | |||

} else { | } else { | |||

/* here coefficients are either 0 or 1 */ | ||||

pmms_srand(repair_key); | ||||

for (i = 0 ; i < cc_nb ; i++) { | for (i = 0 ; i < cc_nb ; i++) { | |||

if (pmms_rand(16) <= density_threshold) { | if (pmms_rand(16) <= dt) { | |||

cc_tab[i] = (UINT8) 1; | cc_tab[i] = (UINT8) 1; | |||

} else { | } else { | |||

cc_tab[i] = (UINT8) 0; | cc_tab[i] = (UINT8) 0; | |||

} | } | |||

} | } | |||

} | } | |||

break; | break; | |||

case 8: | case 8: | |||

if (density_threshold == 15) { | pmms_srand(repair_key); | |||

if (dt == 15) { | ||||

/* coefficient 0 is avoided here in order to include | /* coefficient 0 is avoided here in order to include | |||

* all the source symbols */ | * all the source symbols */ | |||

for (i = 0 ; i < cc_nb ; i++) { | for (i = 0 ; i < cc_nb ; i++) { | |||

do { | do { | |||

cc_tab[i] = (UINT8) pmms_rand(256); | cc_tab[i] = (UINT8) pmms_rand(256); | |||

} while (cc_tab[i] == 0); | } while (cc_tab[i] == 0); | |||

} | } | |||

} else { | } else { | |||

/* here a certain fraction of coefficients should be 0 */ | /* here a certain fraction of coefficients should be 0 */ | |||

for (i = 0 ; i < cc_nb ; i++) { | for (i = 0 ; i < cc_nb ; i++) { | |||

if (pmms_rand(16) <= density_threshold) { | if (pmms_rand(16) <= dt) { | |||

do { | do { | |||

cc_tab[i] = (UINT8) pmms_rand(256); | cc_tab[i] = (UINT8) pmms_rand(256); | |||

} while (cc_tab[i] == 0); | } while (cc_tab[i] == 0); | |||

} else { | } else { | |||

cc_tab[i] = 0; | cc_tab[i] = 0; | |||

} | } | |||

} | } | |||

} | } | |||

break; | break; | |||

default: | default: | |||

/* bad parameter m */ | /* bad parameter m */ | |||

return SOMETHING_WENT_WRONG; | return SOMETHING_WENT_WRONG; | |||

} | } | |||

return EVERYTHING_IS_OKAY; | return EVERYTHING_IS_OKAY; | |||

} | } | |||

<CODE ENDS> | <CODE ENDS> | |||

Figure 2: Coding Coefficients Generation Function pseudo-code | Figure 2: Coding Coefficients Generation Function pseudo-code | |||

4. Sliding Window RLC FEC Scheme over GF(2) for Arbitrary ADU Flows | 4. Sliding Window RLC FEC Scheme over GF(2^^8) for Arbitrary ADU Flows | |||

This fully-specified FEC Scheme defines the Sliding Window Random | This fully-specified FEC Scheme defines the Sliding Window Random | |||

Linear Codes (RLC) over GF(2) (binary case). | Linear Codes (RLC) over GF(2^^8). | |||

4.1. Formats and Codes | 4.1. Formats and Codes | |||

4.1.1. FEC Framework Configuration Information | 4.1.1. FEC Framework Configuration Information | |||

4.1.1.1. Mandatory Information | ||||

o FEC Encoding ID: the value assigned to this fully specified FEC | ||||

Scheme MUST be YYYY, as assigned by IANA (Section 10). | ||||

When SDP is used to communicate the FFCI, this FEC Encoding ID is | ||||

carried in the 'encoding-id' parameter. | ||||

4.1.1.2. FEC Scheme-Specific Information | ||||

All the considerations of Section 5.1.1.2 apply equally here. | ||||

4.1.2. Explicit Source FEC Payload ID | ||||

All the considerations of Section 5.1.1.2 apply equally here. | ||||

4.1.3. Repair FEC Payload ID | ||||

All the considerations of Section 5.1.1.2 apply equally here. | ||||

4.1.4. Additional Procedures | ||||

All the considerations of Section 5.1.1.2 apply equally here. | ||||

5. Sliding Window RLC FEC Scheme over GF(2^^8) for Arbitrary ADU Flows | ||||

This fully-specified FEC Scheme defines the Sliding Window Random | ||||

Linear Codes (RLC) over GF(2^^8). | ||||

5.1. Formats and Codes | ||||

5.1.1. FEC Framework Configuration Information | ||||

The FEC Framework Configuration Information (or FFCI) includes | The FEC Framework Configuration Information (or FFCI) includes | |||

information that MUST be communicated between the sender and | information that MUST be communicated between the sender and | |||

receiver(s). More specifically, it enables the synchronization of | receiver(s). More specifically, it enables the synchronization of | |||

the FECFRAME sender and receiver instances. It includes both | the FECFRAME sender and receiver instances. It includes both | |||

mandatory elements and scheme-specific elements, as detailed below. | mandatory elements and scheme-specific elements, as detailed below. | |||

5.1.1.1. Mandatory Information | 4.1.1.1. Mandatory Information | |||

o FEC Encoding ID: the value assigned to this fully specified FEC | o FEC Encoding ID: the value assigned to this fully specified FEC | |||

Scheme MUST be XXXX, as assigned by IANA (Section 10). | Scheme MUST be XXXX, as assigned by IANA (Section 10). | |||

When SDP is used to communicate the FFCI, this FEC Encoding ID is | When SDP is used to communicate the FFCI, this FEC Encoding ID is | |||

carried in the 'encoding-id' parameter. | carried in the 'encoding-id' parameter. | |||

5.1.1.2. FEC Scheme-Specific Information | 4.1.1.2. FEC Scheme-Specific Information | |||

The FEC Scheme-Specific Information (FSSI) includes elements that are | The FEC Scheme-Specific Information (FSSI) includes elements that are | |||

specific to the present FEC Scheme. More precisely: | specific to the present FEC Scheme. More precisely: | |||

Encoding symbol size (E): a non-negative integer that indicates the | Encoding symbol size (E): a non-negative integer that indicates the | |||

size of each encoding symbol in bytes; | size of each encoding symbol in bytes; | |||

This element is required both by the sender (RLC encoder) and the | This element is required both by the sender (RLC encoder) and the | |||

receiver(s) (RLC decoder). | receiver(s) (RLC decoder). | |||

skipping to change at page 15, line 18 ¶ | skipping to change at page 15, line 36 ¶ | |||

Encoding symbol length (E): 16-bit field. | Encoding symbol length (E): 16-bit field. | |||

0 1 | 0 1 | |||

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | |||

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||

| Encoding Symbol Length (E) | | | Encoding Symbol Length (E) | | |||

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||

Figure 3: FSSI Encoding Format | Figure 3: FSSI Encoding Format | |||

5.1.2. Explicit Source FEC Payload ID | 4.1.2. Explicit Source FEC Payload ID | |||

A FEC source packet MUST contain an Explicit Source FEC Payload ID | A FEC Source Packet MUST contain an Explicit Source FEC Payload ID | |||

that is appended to the end of the packet as illustrated in Figure 4. | that is appended to the end of the packet as illustrated in Figure 4. | |||

+--------------------------------+ | +--------------------------------+ | |||

| IP Header | | | IP Header | | |||

+--------------------------------+ | +--------------------------------+ | |||

| Transport Header | | | Transport Header | | |||

+--------------------------------+ | +--------------------------------+ | |||

| ADU | | | ADU | | |||

+--------------------------------+ | +--------------------------------+ | |||

| Explicit Source FEC Payload ID | | | Explicit Source FEC Payload ID | | |||

+--------------------------------+ | +--------------------------------+ | |||

Figure 4: Structure of an FEC Source Packet with the Explicit Source | Figure 4: Structure of an FEC Source Packet with the Explicit Source | |||

FEC Payload ID | FEC Payload ID | |||

More precisely, the Explicit Source FEC Payload ID is composed of the | More precisely, the Explicit Source FEC Payload ID is composed of the | |||

following field (Figure 5): | following field (Figure 5): | |||

Encoding Symbol ID (ESI) (32-bit field): this unsigned integer | Encoding Symbol ID (ESI) (32-bit field): this unsigned integer | |||

identifies the first source symbol of the ADUI corresponding to | identifies the first source symbol of the ADUI corresponding to | |||

this FEC source packet. The ESI is incremented for each new | this FEC Source Packet. The ESI is incremented for each new | |||

source symbol, and after reaching the maximum value (2^32-1), | source symbol, and after reaching the maximum value (2^32-1), | |||

wrapping to zero occurs. | wrapping to zero occurs. | |||

0 1 2 3 | 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 | 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 | |||

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||

| Encoding Symbol ID (ESI) | | | Encoding Symbol ID (ESI) | | |||

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||

Figure 5: Source FEC Payload ID Encoding Format | Figure 5: Source FEC Payload ID Encoding Format | |||

5.1.3. Repair FEC Payload ID | 4.1.3. Repair FEC Payload ID | |||

A FEC repair packet MUST contain a Repair FEC Payload ID that is | A FEC Repair Packet can contain one or more repair symbols. When | |||

prepended to the repair symbol as illustrated in Figure 6. There can | there are several repair symbols, all of them MUST have been | |||

be one or more repair symbols per FEC repair packet. When this is | generated from the same encoding window, using Repair_Key values that | |||

the case, the number of repair symbols within this FEC repair packet | are managed as explained below. A receiver can easily deduce the | |||

is easily deduced by comparing the known received FEC repair packet | number of repair symbols within a FEC Repair Packet by comparing the | |||

size (equal to the UDP payload size when UDP is the underlying | received FEC Repair Packet size (equal to the UDP payload size when | |||

transport protocol) and the symbol size, E, communicated in the FFCI. | UDP is the underlying transport protocol) and the symbol size, E, | |||

When this is the case, all the repair symbols MUST have been | communicated in the FFCI. | |||

generated from the same encoding window. | ||||

A FEC Repair Packet MUST contain a Repair FEC Payload ID that is | ||||

prepended to the repair symbol as illustrated in Figure 6. | ||||

+--------------------------------+ | +--------------------------------+ | |||

| IP Header | | | IP Header | | |||

+--------------------------------+ | +--------------------------------+ | |||

| Transport Header | | | Transport Header | | |||

+--------------------------------+ | +--------------------------------+ | |||

| Repair FEC Payload ID | | | Repair FEC Payload ID | | |||

+--------------------------------+ | +--------------------------------+ | |||

| Repair Symbol | | | Repair Symbol | | |||

+--------------------------------+ | +--------------------------------+ | |||

Figure 6: Structure of an FEC Repair Packet with the Repair FEC | Figure 6: Structure of an FEC Repair Packet with the Repair FEC | |||

Payload ID | Payload ID | |||

More precisely, the Repair FEC Payload ID is composed of the | More precisely, the Repair FEC Payload ID is composed of the | |||

following fields (Figure 7): | following fields (Figure 7): | |||

Repair_Key (16-bit field): this unsigned integer is used as a seed | Repair_Key (16-bit field): this unsigned integer is used as a seed | |||

by the coefficient generation function (Section 3.5) in order to | by the coefficient generation function (Section 3.5) in order to | |||

generate the desired number of coding coefficients. Value 0 MUST | generate the desired number of coding coefficients. Value 0 MUST | |||

NOT be used. When a FEC repair packet contains several repair | NOT be used. When a FEC Repair Packet contains several repair | |||

symbols, this repair key value is that of the first repair symbol. | symbols, this repair key value is that of the first repair symbol. | |||

The remaining repair keys can be deduced by incrementing by 1 this | The remaining repair keys can be deduced by incrementing by 1 this | |||

value, up to a maximum value of 65535 after which it loops back to | value, up to a maximum value of 65535 after which it loops back to | |||

1 (note that 0 is not a valid value). | 1 (note that 0 is not a valid value). | |||

Coding coefficients Density Threshold, DT (4-bit field): this | Density Threshold for the coding coefficients, DT (4-bit field): | |||

unsigned integer carried the Density Threshold (DT) used by the | this unsigned integer carried the Density Threshold (DT) used by | |||

coding coefficient generation function Section 3.5. More | the coding coefficient generation function Section 3.5. More | |||

precisely, it controls the probability of having a non zero coding | precisely, it controls the probability of having a non zero coding | |||

coefficient, which equals (DT+1) / 16. When a FEC repair packet | coefficient, which equals (DT+1) / 16. When a FEC Repair Packet | |||

contains several repair symbols, the DT value applies to all of | contains several repair symbols, the DT value applies to all of | |||

them; | them; | |||

Number of Source Symbols in the Encoding Window, NSS (12-bit field): | Number of Source Symbols in the encoding window, NSS (12-bit field): | |||

this unsigned integer indicates the number of source symbols in | this unsigned integer indicates the number of source symbols in | |||

the encoding window when this repair symbol was generated. When a | the encoding window when this repair symbol was generated. When a | |||

FEC repair packet contains several repair symbols, this NSS value | FEC Repair Packet contains several repair symbols, this NSS value | |||

applies to all of them; | applies to all of them; | |||

ESI of first source symbol in encoding window, FSS_ESI (32-bit | ESI of First Source Symbol in the encoding window, FSS_ESI (32-bit | |||

field): | field): | |||

this unsigned integer indicates the ESI of the first source symbol | this unsigned integer indicates the ESI of the first source symbol | |||

in the encoding window when this repair symbol was generated. | in the encoding window when this repair symbol was generated. | |||

When a FEC repair packet contains several repair symbols, this | When a FEC Repair Packet contains several repair symbols, this | |||

FSS_ESI value applies to all of them; | FSS_ESI value applies to all of them; | |||

0 1 2 3 | 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 | 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 | |||

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||

| Repair_Key | DT |NSS (# src symb in ew) | | | Repair_Key | DT |NSS (# src symb in ew) | | |||

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||

| FSS_ESI | | | FSS_ESI | | |||

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||

Figure 7: Repair FEC Payload ID Encoding Format | Figure 7: Repair FEC Payload ID Encoding Format | |||

5.1.4. Additional Procedures | 4.1.4. Additional Procedures | |||

The following procedure applies: | The following procedure applies: | |||

o The ESI of source symbols MUST start with value 0 for the first | o The ESI of source symbols MUST start with value 0 for the first | |||

source symbol and MUST be managed sequentially. Wrapping to zero | source symbol and MUST be managed sequentially. Wrapping to zero | |||

will happen after reaching the maximum 32-bit value. | happens after reaching the maximum 32-bit value. | |||

5. Sliding Window RLC FEC Scheme over GF(2) for Arbitrary ADU Flows | ||||

This fully-specified FEC Scheme defines the Sliding Window Random | ||||

Linear Codes (RLC) over GF(2) (binary case). | ||||

5.1. Formats and Codes | ||||

5.1.1. FEC Framework Configuration Information | ||||

5.1.1.1. Mandatory Information | ||||

o FEC Encoding ID: the value assigned to this fully specified FEC | ||||

Scheme MUST be YYYY, as assigned by IANA (Section 10). | ||||

When SDP is used to communicate the FFCI, this FEC Encoding ID is | ||||

carried in the 'encoding-id' parameter. | ||||

5.1.1.2. FEC Scheme-Specific Information | ||||

All the considerations of Section 4.1.1.2 apply here. | ||||

5.1.2. Explicit Source FEC Payload ID | ||||

All the considerations of Section 4.1.1.2 apply here. | ||||

5.1.3. Repair FEC Payload ID | ||||

All the considerations of Section 4.1.1.2 apply here, with the only | ||||

exception that the Repair_Key field is useless if DT = 15 (indeed, in | ||||

that case all the coefficients are necessarily equal to 1 and the | ||||

coefficient generation function does not use any PRNG). When DT = 15 | ||||

it is RECOMMENDED that the sender use value 0 for the Repair_Key | ||||

field, but a receiver SHALL ignore this field. | ||||

5.1.4. Additional Procedures | ||||

All the considerations of Section 4.1.1.2 apply here. | ||||

6. FEC Code Specification | 6. FEC Code Specification | |||

6.1. Encoding Side | 6.1. Encoding Side | |||

This section provides a high level description of a Sliding Window | This section provides a high level description of a Sliding Window | |||

RLC encoder. | RLC encoder. | |||

Whenever a new FEC repair packet is needed, the RLC encoder instance | Whenever a new FEC Repair Packet is needed, the RLC encoder instance | |||

first gathers the ew_size source symbols currently in the sliding | first gathers the ew_size source symbols currently in the sliding | |||

encoding window. Then it chooses a repair key, which can be a non | encoding window. Then it chooses a repair key, which can be a non | |||

zero monotonically increasing integer value, incremented for each | zero monotonically increasing integer value, incremented for each | |||

repair symbol up to a maximum value of 65535 (as it is carried within | repair symbol up to a maximum value of 65535 (as it is carried within | |||

a 16-bit field) after which it loops back to 1 (indeed, being used as | a 16-bit field) after which it loops back to 1 (indeed, being used as | |||

a PRNG seed, value 0 is prohibited). This repair key is communicated | a PRNG seed, value 0 is prohibited). This repair key is communicated | |||

to the coefficient generation function (Section Section 3.5) in order | to the coefficient generation function (Section Section 3.5) in order | |||

to generate ew_size coding coefficients. Finally, the FECFRAME | to generate ew_size coding coefficients. Finally, the FECFRAME | |||

sender computes the repair symbol as a linear combination of the | sender computes the repair symbol as a linear combination of the | |||

ew_size source symbols using the ew_size coding coefficients. When E | ew_size source symbols using the ew_size coding coefficients. When E | |||

is small and when there is an incentive to pack several repair | is small and when there is an incentive to pack several repair | |||

symbols within the same FEC Repair Packet, the appropriate number of | symbols within the same FEC Repair Packet, the appropriate number of | |||

repair symbols are computed. The only constraint is to increment by | repair symbols are computed. The only constraint is to increment by | |||

1 the repair key for each of them, keeping the same ew_size source | 1 the repair key for each of them, keeping the same ew_size source | |||

symbols, since only the first repair key will be carried in the | symbols, since only the first repair key will be carried in the | |||

Repair FEC Payload ID. The FEC repair packet can then be sent. The | Repair FEC Payload ID. The FEC Repair Packet can then be sent. The | |||

source versus repair FEC packet transmission order is out of scope of | source versus repair FEC packet transmission order is out of scope of | |||

this document and several approaches exist that are implementation | this document and several approaches exist that are implementation | |||

specific. | specific. | |||

Other solutions are possible to select a repair key value when a new | ||||

FEC Repair Packet is needed, for instance by choosing a random | ||||

integer between 1 and 65535. However, selecting the same repair key | ||||

as before (which may happen in case of a random process) is only | ||||

meaningful if the encoding window has changed, otherwise the same FEC | ||||

Repair Packet will be generated. | ||||

6.2. Decoding Side | 6.2. Decoding Side | |||

This section provides a high level description of a Sliding Window | This section provides a high level description of a Sliding Window | |||

RLC decoder. | RLC decoder. | |||

A FECFRAME receiver needs to maintain a linear system whose variables | A FECFRAME receiver needs to maintain a linear system whose variables | |||

are the received and lost source symbols. Upon receiving a FEC | are the received and lost source symbols. Upon receiving a FEC | |||

repair packet, a receiver first extracts all the repair symbols it | Repair Packet, a receiver first extracts all the repair symbols it | |||

contains (in case several repair symbols are packed together). For | contains (in case several repair symbols are packed together). For | |||

each repair symbol, when at least one of the corresponding source | each repair symbol, when at least one of the corresponding source | |||

symbols it protects has been lost, the receiver adds an equation to | symbols it protects has been lost, the receiver adds an equation to | |||

the linear system (or no equation if this repair packet does not | the linear system (or no equation if this repair packet does not | |||

change the linear system rank). This equation of course re-uses the | change the linear system rank). This equation of course re-uses the | |||

ew_size coding coefficients that are computed by the same coefficient | ew_size coding coefficients that are computed by the same coefficient | |||

generation function (Section Section 3.5), using the repair key and | generation function (Section Section 3.5), using the repair key and | |||

encoding window descriptions carried in the Repair FEC Payload ID. | encoding window descriptions carried in the Repair FEC Payload ID. | |||

Whenever possible (i.e., when a sub-system covering one or more lost | Whenever possible (i.e., when a sub-system covering one or more lost | |||

source symbols is of full rank), decoding is performed in order to | source symbols is of full rank), decoding is performed in order to | |||

recover lost source symbols. Each time an ADUI can be totally | recover lost source symbols. Each time an ADUI can be totally | |||

recovered, it is assigned to the corresponding application flow | recovered, padding is removed (thanks to the Length field, L, of the | |||

(thanks to the Flow ID (F) field of the ADUI) and padding (if any) | ADUI) and the ADU is assigned to the corresponding application flow | |||

removed (thanks to the Length (L) field of the ADUI). This ADU is | (thanks to the Flow ID field, F, of the ADUI). This ADU is finally | |||

finally passed to the corresponding upper application. Received FEC | passed to the corresponding upper application. Received FEC Source | |||

source packets, containing an ADU, can be passed to the application | Packets, containing an ADU, can be passed to the application either | |||

either immediately or after some time to guaranty an ordered delivery | immediately or after some time to guaranty an ordered delivery to the | |||

to the application(s). This document does not mandate any approach | application. This document does not mandate any approach as this is | |||

as this is an operational and management decision. | an operational and management decision. | |||

With real-time flows, a lost ADU that is decoded after the maximum | With real-time flows, a lost ADU that is decoded after the maximum | |||

latency (or an ADU received far too late) should not be considered by | latency or an ADU received after this delay should not be passed to | |||

the application. Instead the associated source symbols should be | the application. Instead the associated source symbols should be | |||

removed from the linear system maintained by the receiver(s). | removed from the linear system maintained by the receiver(s). | |||

Appendix A discusses a backward compatible optimization whereby those | Appendix A discusses a backward compatible optimization whereby those | |||

late source symbols may still be useful to improve the global loss | late source symbols may still be used in order to improve the global | |||

recovery performance. | robustness. | |||

7. Implementation Status | 7. Implementation Status | |||

Editor's notes: RFC Editor, please remove this section motivated by | Editor's notes: RFC Editor, please remove this section motivated by | |||

RFC 6982 before publishing the RFC. Thanks. | RFC 6982 before publishing the RFC. Thanks. | |||

An implementation of the Sliding Window RLC FEC Scheme for FECFRAME | An implementation of the Sliding Window RLC FEC Scheme for FECFRAME | |||

exists: | exists: | |||

o Organisation: Inria | o Organisation: Inria | |||

o Description: This is an implementation of the Sliding Window RLC | o Description: This is an implementation of the Sliding Window RLC | |||

FEC Scheme. It relies on a modified version of our OpenFEC | FEC Scheme limited to GF(2^^8). It relies on a modified version | |||

(http://openfec.org) FEC code library. It is integrated in our | of our OpenFEC (http://openfec.org) FEC code library. It is | |||

FECFRAME software (see [fecframe-ext]). | integrated in our FECFRAME software (see [fecframe-ext]). | |||

o Maturity: prototype. | o Maturity: prototype. | |||

o Coverage: this software complies with the Sliding Window RLC FEC | o Coverage: this software complies with the Sliding Window RLC FEC | |||

Scheme (limited to m=8 as of June, 2017). | Scheme. | |||

o Lincensing: proprietary. | o Lincensing: proprietary. | |||

o Contact: vincent.roca@inria.fr | o Contact: vincent.roca@inria.fr | |||

8. Security Considerations | 8. Security Considerations | |||

The FEC Framework document [RFC6363] provides a comprehensive | The FEC Framework document [RFC6363] provides a comprehensive | |||

analysis of security considerations applicable to FEC Schemes. | analysis of security considerations applicable to FEC Schemes. | |||

Therefore, the present section follows the security considerations | Therefore, the present section follows the security considerations | |||

section of [RFC6363] and only discusses specific topics. | section of [RFC6363] and only discusses specific topics. | |||

skipping to change at page 19, line 51 ¶ | skipping to change at page 21, line 20 ¶ | |||

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]. To summarize, it is | change the recommendations of [RFC6363]. To summarize, it is | |||

RECOMMENDED that one of the solutions mentioned in [RFC6363] is used | RECOMMENDED that one of the solutions mentioned in [RFC6363] is used | |||

on both the FEC Source and Repair Packets. | on both the FEC Source and Repair Packets. | |||

8.2. Attacks Against the FEC Parameters | 8.2. Attacks Against the FEC Parameters | |||

The FEC Scheme specified in this document defines parameters that can | The FEC Scheme specified in this document defines parameters that can | |||

be the basis of attacks. More specifically, the following parameters | be the basis of attacks. More specifically, the following parameters | |||

of the FFCI may be modified by an attacker who only targets receivers | of the FFCI may be modified by an attacker who targets receivers | |||

(Section 5.1.1.2): | (Section 4.1.1.2): | |||

o FEC Encoding ID: changing this parameter leads the receivers to | o FEC Encoding ID: changing this parameter leads the receivers to | |||

consider a different FEC Scheme, which enables an attacker to | consider a different FEC Scheme, which enables an attacker to | |||

create a Denial of Service (DoS); | create a Denial of Service (DoS); | |||

o Encoding symbol length (E): setting this E parameter to a | o Encoding symbol length (E): setting this E parameter to a | |||

different value will confuse the receivers and create a DoS. More | different value will confuse the receivers and create a DoS. More | |||

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

An attacker who only targets a sender will achieve the same results. | ||||

However if the attacker targets both sender and receivers at the same | ||||

time (the same wrong piece of information is communicated to | ||||

everybody), the results will be suboptimal but less severe. | ||||

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, NSS or FSS_ESI. It is therefore | |||

RECOMMENDED that security measures are taken to guarantee the FEC | RECOMMENDED that security measures are taken to guarantee the FEC | |||

Source and Repair Packets as stated in [RFC6363]. | Source and Repair Packets as stated in [RFC6363]. | |||

skipping to change at page 21, line 8 ¶ | skipping to change at page 22, line 18 ¶ | |||

9. Operations and Management Considerations | 9. Operations and Management Considerations | |||

The FEC Framework document [RFC6363] provides a comprehensive | The FEC Framework document [RFC6363] provides a comprehensive | |||

analysis of operations and management considerations applicable to | analysis of operations and management considerations applicable to | |||

FEC Schemes. Therefore, the present section only discusses specific | FEC Schemes. Therefore, the present section only discusses specific | |||

topics. | topics. | |||

9.1. Operational Recommendations: Finite Field GF(2) Versus GF(2^^8) | 9.1. Operational Recommendations: Finite Field GF(2) Versus GF(2^^8) | |||

The present document specifies two FEC Schemes that differ on the | The present document specifies two FEC Schemes that differ on the | |||

associated Finite Field used for the coding coefficients. It is | Finite Field used for the coding coefficients. It is expected that | |||

expected that the RLC over GF(2^^8) FEC Scheme will be mostly used | the RLC over GF(2^^8) FEC Scheme will be mostly used since it | |||

since it warrants a high loss protection. Additionally, elements in | warrants a higher packet loss protection. In case of small encoding | |||

the finite field are 8 bits long, which makes read/write memory | windows, the associated processing overhead is not an issue (e.g., we | |||

operations aligned on bytes during encoding and decoding. | measured decoding speeds between 745 Mbps and 2.8 Gbps on an ARM | |||

Cortex-A15 embedded board in [Roca17]). Of course the CPU overhead | ||||

will increase with the encoding window size, because more operations | ||||

in the GF(2^^8) finite field will be needed. | ||||

Finally, in particular when dealing with large encoding windows, an | The RLC over GF(2) FEC Scheme offers an alternative. In that case | |||

alternative is the RLC over GF(2) FEC Scheme. In that case | operations symbols can be directly XOR-ed together which warrants | |||

operations symbols can be directly XORed together which warrants high | high bitrate encoding and decoding operations, and can be an | |||

bitrate encoding and decoding operations. | advantage with large encoding windows. However packet loss | |||

protection is significantly reduced by using this FEC Scheme. | ||||

9.2. Operational Recommendations: Coding Coefficients Density Threshold | 9.2. Operational Recommendations: Coding Coefficients Density Threshold | |||

In addition to the choice of the Finite Field, the two FEC Schemes | In addition to the choice of the Finite Field, the two FEC Schemes | |||

define a coding coefficient density threshold parameter. This | define a coding coefficient density threshold (DT) parameter. This | |||

parameter enables a sender to control the code density, i.e., the | parameter enables a sender to control the code density, i.e., the | |||

proportion of coefficients that are non zero on average. With RLC | proportion of coefficients that are non zero on average. With RLC | |||

over GF(2^^8), it is recommended that small encoding windows be | over GF(2^^8), it is usually appropriate that small encoding windows | |||

associated to a density threshold equal to 15, the maximum value, in | be associated to a density threshold equal to 15, the maximum value, | |||

order to warrant a high loss protection. | in order to warrant a high loss protection. | |||

On the opposite, with large encoding windows, it it recommened that | On the opposite, with larger encoding windows, it is usually | |||

the density threshold be reduced. With large encoding windows, an | appropriate that the density threshold be reduced. With large | |||

alternative can be to use RLC over GF(2) and a density threshold | encoding windows, an alternative can be to use RLC over GF(2) and a | |||

equal to 8 (i.e., an average density equal to 1/2) or smaller. | density threshold equal to 7 (i.e., an average density equal to 1/2) | |||

or smaller. | ||||

Note also that using a density threshold equal to 15 with RLC over | Note that using a density threshold equal to 15 with RLC over GF(2) | |||

GF(2) is equivalent to using code that XOR's all the source symbols | is equivalent to using an XOR code that compute the XOR sum of all | |||

of the encoding window. In that case it follows that: (1) a single | the source symbols in the encoding window. In that case: (1) a | |||

repair symbol can be produced for a given encoding window, and (2) | single repair symbol can be produced for any encoding window, and (2) | |||

the repair_key parameter is useless (the coding coefficients | the repair_key parameter becomes useless (the coding coefficients | |||

generation function does not rely on the PRNG). | generation function does not rely on the PRNG). | |||

10. IANA Considerations | 10. IANA Considerations | |||

This document registers two values in the "FEC Framework (FECFRAME) | This document registers two values in the "FEC Framework (FECFRAME) | |||

FEC Encoding IDs" registry [RFC6363] as follows: | FEC Encoding IDs" registry [RFC6363] as follows: | |||

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 4 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 5 of this document. | Section 4 of this document. | |||

11. Acknowledgments | 11. Acknowledgments | |||

The authors would like to thank Marie-Jose Montpetit for her valuable | The authors would like to thank Marie-Jose Montpetit for her valuable | |||

feedbacks on this 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-roca-tsvwg-fecframev2 | Area Working Group (TSVWG) draft-ietf-tsvwg-fecframe-ext | |||

(Work in Progress), June 2017, | (Work in Progress), March 2018, | |||

<https://tools.ietf.org/html/draft-roca-tsvwg-fecframev2>. | <https://tools.ietf.org/html/ | |||

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

DOI 10.17487/RFC6363, October 2011, | DOI 10.17487/RFC6363, October 2011, | |||

<https://www.rfc-editor.org/info/rfc6363>. | <https://www.rfc-editor.org/info/rfc6363>. | |||

skipping to change at page 23, line 36 ¶ | skipping to change at page 24, line 50 ¶ | |||

[RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. | [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. | |||

Matsuzono, "Simple Reed-Solomon Forward Error Correction | Matsuzono, "Simple Reed-Solomon Forward Error Correction | |||

(FEC) Scheme for FECFRAME", RFC 6865, | (FEC) Scheme for FECFRAME", RFC 6865, | |||

DOI 10.17487/RFC6865, February 2013, | DOI 10.17487/RFC6865, February 2013, | |||

<https://www.rfc-editor.org/info/rfc6865>. | <https://www.rfc-editor.org/info/rfc6865>. | |||

[Roca16] Roca, V., Teibi, B., Burdinat, C., Tran, T., and C. | [Roca16] Roca, V., Teibi, B., Burdinat, C., Tran, T., and C. | |||

Thienot, "Block or Convolutional AL-FEC Codes? A | Thienot, "Block or Convolutional AL-FEC Codes? A | |||

Performance Comparison for Robust Low-Latency | Performance Comparison for Robust Low-Latency | |||

Communications", HAL open-archive document,hal-01395937 | Communications", HAL open-archive document,hal-01395937 | |||

https://hal.inria.fr/hal-01395937/en/, November 2016, < | https://hal.inria.fr/hal-01395937/en/, November 2016, | |||

https://hal.inria.fr/hal-01395937/en/>. | <https://hal.inria.fr/hal-01395937/en/>. | |||

[Roca17] Roca, V., Teibi, B., Burdinat, C., Tran, T., and C. | [Roca17] Roca, V., Teibi, B., Burdinat, C., Tran, T., and C. | |||

Thienot, "Less Latency and Better Protection with AL-FEC | Thienot, "Less Latency and Better Protection with AL-FEC | |||

Sliding Window Codes: a Robust Multimedia CBR Broadcast | Sliding Window Codes: a Robust Multimedia CBR Broadcast | |||

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-01395937/en/>. | 2017, <https://hal.inria.fr/hal-01571609v1/en/>. | |||

[WI08] Whittle, R., "Park-Miller-Carta Pseudo-Random Number | [WI08] Whittle, R., "Park-Miller-Carta Pseudo-Random Number | |||

Generator", http://www.firstpr.com.au/dsp/rand31/, | Generator", http://www.firstpr.com.au/dsp/rand31/, | |||

January 2008, <http://www.firstpr.com.au/dsp/rand31/>. | January 2008, <http://www.firstpr.com.au/dsp/rand31/>. | |||

Appendix A. Decoding Beyond Maximum Latency Optimization | Appendix A. Decoding Beyond Maximum Latency Optimization | |||

This annex introduces non normative considerations. They are | This annex introduces non normative considerations. They are | |||

provided as suggestions, without any impact on interoperability. For | provided as suggestions, without any impact on interoperability. For | |||

more information see [Roca16]. | more information see [Roca16]. | |||

It is possible to improve the decoding performance of sliding window | It is possible to improve the decoding performance of sliding window | |||

codes without impacting maximum latency, at the cost of extra CPU | codes without impacting maximum latency, at the cost of extra CPU | |||

overhead. The optimization consists, for a receiver, to extend the | overhead. The optimization consists, for a receiver, to extend the | |||

linear system beyond the decoding window: | linear system beyond the decoding window, by keeping a certain number | |||

of old source symbols: | ||||

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

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 8: Relationship between parameters to decode beyond maximum | Figure 8: 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 their transport protocol added latency exceeds the maximum value | if the added latency exceeds the maximum value permitted by the | |||

permitted by the application. It follows that these source symbols | application. It follows that the corresponding ADUs SHOULD NOT be | |||

SHOULD NOT be delivered to the application and SHOULD be dropped once | delivered to the application and SHOULD be dropped once they are no | |||

they are no longer needed. However, decoding these late symbols | longer needed. However, decoding these "late symbols" significantly | |||

significantly improves the global robustness in bad reception | improves the global robustness in bad reception conditions and is | |||

conditions and is therefore recommended for receivers experiencing | therefore recommended for receivers experiencing bad communication | |||

bad channels[Roca16]. In any case whether or not to use this | conditions [Roca16]. In any case whether or not to use this | |||

facility and what exact value to use for the ls_max_size parameter | optimization and what exact value to use for the ls_max_size | |||

are decisions made by each receiver independently, without any impact | parameter are decisions made by each receiver independently, without | |||

on others, neither the other receivers nor the source. | any impact on the other receivers nor on the source. | |||

Authors' Addresses | Authors' Addresses | |||

Vincent Roca | Vincent Roca | |||

INRIA | INRIA | |||

Grenoble | Grenoble | |||

France | France | |||

EMail: vincent.roca@inria.fr | EMail: vincent.roca@inria.fr | |||

Belkacem Teibi | Belkacem Teibi | |||

End of changes. 96 change blocks. | ||||

282 lines changed or deleted | | 352 lines changed or added | ||

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