wdiff rfc8406.original rfc8406.txt

NWCRG
Internet Research Task Force (IRTF) B. Adamson
Internet-Draft
Request for Comments: 8406 NRL
Intended status:
Category: Informational C. Adjih
Expires: September 19, 2018
ISSN: 2070-1721 INRIA
J. Bilbao
Ikerlan
V. Firoiu
BAE Systems
F. Fitzek
TU Dresden
S. Ghanem
Independant
Independent
E. Lochin
ISAE - Supaero
A. Masucci
Orange
M-J. Montpetit
Independant
Independent
M. Pedersen
Aalborg University
G. Peralta
Ikerlan
V. Roca, Ed.
INRIA
P. Saxena
AnsuR Technologies
S. Sivakumar
Cisco
March 18,
June 2018

Taxonomy of Coding Techniques for Efficient Network Communications
draft-irtf-nwcrg-network-coding-taxonomy-08

Abstract

This document is the product of the Network Coding Research Group
(NWCRG). It summarizes a recommended terminology for Network Coding
concepts and constructs. It provides a comprehensive set of terms in
order to avoid ambiguities in future IRTF and IETF documents on
Network Coding. This document is in-line the product of the Coding for
Efficient Network Communications Research Group (NWCRG), and it is in
line with the terminology used by the RFCs produced by the Reliable
Multicast Transport (RMT) and FEC Framework (FECFRAME) IETF working
groups.

Status of This Memo

This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the
provisions Internet Research Task Force
(IRTF). The IRTF publishes the results of BCP 78 Internet-related research
and BCP 79.

Internet-Drafts are working documents development activities. These results might not be suitable for
deployment. This RFC represents the consensus of the Coding for
Efficient Network Communications Research Group of the Internet Engineering
Research Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts (IRTF). Documents approved for publication by
the IRSG are draft documents valid not candidates for a maximum any level of six months Internet Standard; see
Section 2 of RFC 7841.

Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 19, 2018.
https://www.rfc-editor.org/info/rfc8406.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. General definitions Definitions and concepts Concepts . . . . . . . . . . . . . . 4
3. Taxonomy of Code Uses . . . . . . . . . . . . . . . . . . . . 7
4. Coding Details . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Coding Types . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Coding Basics . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Coding In in Practice . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 13 14
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Additional references . . . . . . . . . . . . . . . 14
Appendix B. Authors and Contributors . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 15

1. Introduction

This document is not an IETF product and is not a standard. This
document is the product of and represents the collaborative work
and consensus of the Network Coding for Efficient Network Communications
Research Group (NWCRG). (NWCRG); it is not an IETF product and is not a
standard. In 2017, it has been the document was discussed during three audio
conferences, each of them gathering 6 to 8 key experts, experts; it has been co-edited, was
co-edited and finally subject subjected to a an RG Last Call. The general feeling was
that the document was ready for the next step. ready. Additional information about Network
Coding may be found on these NWCRG pages: <https://irtf.org/nwcrg>
and <https://datatracker.ietf.org/rg/nwcrg/about/>.

The literature on Network Coding research and system design,
including IETF
included, documentation, led to a rich set of concepts and
constructs. This document collects terminology used in the domain,
both outside and inside IETF, provides concise definitions, and
introduces a high-
level high-level taxonomy. Its primary goal is to be useful
to IETF and IRTF activities. It is also in-line in line with the terminology
already used by the RFCs produced by the Reliable Multicast Transport
(RMT) and FEC Framework (FECFRAME) IETF working groups, in particular [RFC5052]
[RFC5740] [RFC5775] [RFC6363]
[RFC5052], [RFC5740], [RFC5775], [RFC6363], and [RFC6726]. This
document is also related to IETF work being done in the PAYLOAD and
TSVWG WGs (in particular, the extension of FECFRAME to support
Sliding Window Codes and the Random Linear Coding (RLC) sliding
window FEC scheme) and past work in the AVTCORE and MMUSIC WGs. Note
that in the definitions, the "(IETF)" tag indicates that the
associated term is already used in IETF documents. documents (Internet-Drafts
and RFCs).

This document focuses on packet transmissions and packet losses. These
losses will typically be triggered by various types of networking
issues and/or impairments (e.g., congested routers or intermittent
wireless connectivity). The notion of "packet" itself is multiform,
depending on the target use-case use case and the notion of network (e.g., in
which layer of the protocol stack does the coding middleware
operate?). For instance, a "packet" may be a data unit to be carried
as a UDP payload because the coding middleware is located between the
application and UDP. In another configuration, coding may be applied
within an overlay network and the notion of "packet" will be totally
different. In any case case, the goals of Network Coding can be to
improve the network throughput, efficiency, latency, and scalability,
as well as providing to provide resilience to partition, attacks, and
eavesdropping (NWCRG charter). Both End-to-End Coding and systems
that also perform re-coding recoding within intermediate forwarding nodes are
considered in this document.

This document does not consider physical layer physical-layer transmission issues,
nor physical layer
physical-layer codes, nor or error detection: if low layer low-layer error codes
detect but fail to correct bit errors, or if an upper layer upper-layer checksum
(e.g., within IP or UDP) identifies a corrupted packet, then
this the
packet is supposed to be dropped.

1.1. Requirements Language

The keywords key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

2. General definitions Definitions and concepts Concepts

This section gathers provides general definitions and concepts that are used
throughout this document.

Packet Erasure Channel:
A communication path where packets are either dropped or received
without any error. This type of packet drop is referred to as an
"erasure" or "loss". The term "channel" must be understood as a
generic term for any type of communication technology (e.g., an
Ethernet link, a WiFi network, or a full path between two nodes
over the Internet). The "Erasure" channels are As opposed to the "Erasure" channels, "Error"
channels are where one or multiple bit errors may happen during a
packet transmission. These "Error" channels are out of scope.

Erasure Correcting Code (ECC), (ECC) or (IETF) Forward Erasure Code Correction
(FEC):
A code for the Packet Erasure Channel (only). These codes are
also called "Application-Level FEC" FECs" to highlight that they have
been designed to be used for use within the higher layers of the protocol stack,
stack to protect against packet losses. These codes are As opposed to ECCs/FECs,
"Error" correction codes that are capable of identifying the presence and/or correcting
of bit errors. errors and perhaps correcting them. The "Error" correction
codes are out of scope.

End-to-End Coding:
A system where coding is performed at the source or (coding)
middlebox, and decoding is performed at the destination(s) or
(decoding) middlebox. There is no re-
coding recoding operation at
intermediate nodes. This is the approach followed in the
FLUTE/ALC [RFC6726][RFC5775], [RFC6726] [RFC5775], NORM [RFC5740] [RFC5740], and FECFRAME
[RFC6363] protocols.

Network Coding:
A system where coding can be performed at the source as well as at
intermediate forwarding nodes (all or a subset of them). End-to-End End-to-
End Coding is regarded as a special case of Network Coding.
Depending on the use case, additional assumptions can be made: for instance
the knowledge by
instance, the destination of knowing the coding nodes Coding Nodes' topology and
coding operations can help during decoding operations.

Packet versus Symbol:
Generally speaking, a Packet is the unit of data that is sent in
the Packet Erasure Channel, while a Symbol is the unit of data
that is manipulated during the encoding and decoding operations.

Original Payload, or Uncoded Payload, or Systematic Symbol, or (IETF)
Source Symbol:
A unit of data originating from the source that is used as input
to encoding operations. When there is a single
Source Symbol per Source Packet, an Original Payload
corresponds to a Source Packet.

Coded Payload, Coded Symbol, or (IETF) Repair Symbol:
A unit of data that is the result of a coding operation, applied
either to Source Symbols or (in case of recoding) Source and/or
Repair Symbols. When there is a single Repair Symbol per Repair
Packet, a Coded Payload Repair Symbol corresponds to a Repair Packet.

Input Symbol and Output Symbol:
A unit of data that is used as input to an encoding operation or
that is generated as output of an encoding operation. At a re-coding
recoding node, Repair Symbols are also part of the Input Symbols.
With Systematic Coding, Source Symbols are also part of the Output
Symbols.

(IETF) Encoding Symbol:
A Source or a Repair Symbol.

(En)coding versus Recoding versus Decoding:
(En)coding is an operation that takes Source Symbols as input and
produces Encoding Symbols as output. Recoding is an operation
that takes Encoding Symbols as input and produces Encoding Symbols
as output. Decoding is an operation takes Encoding Symbols as
input and produces Source Symbols as output.

(IETF) Source Packet:
A packet originating from the source
which that contributes to one or
more Source Symbols. For instance, an RTP packet as a whole can
constitute a Source Symbol. In other situations (e.g, (e.g., to address
variable size packets) packets), a single RTP packet may contribute to
various Source Symbols.

(IETF) Repair Packet:
A packet containing one or more Repair Symbols.

Figure 1 illustrates the relationships between packets (what is sent
in the Packet Erasure Channel) and symbols (what is manipulated
during encoding and decoding operations) in case of FEC encoding, a Systematic
Coding at a Coding Node that performs Encoding (rather than
Recoding). FEC decoding procedures are similarly performed in the
reverse order.

source packet

Source Packet
|
| source packet Source Packet to source symbols Source Symbols transform
| (one or more symbols per packet)
v
source symbols
Source Symbols
|
v input symbols Input Symbols
+----------------------+
| FEC encoding |
+----------------------+
| output symbols Output Symbols |
v v
source symbols repair symbols
Source Symbols Repair Symbols
| |
| | symbol to packet symbol-to-packet transform
| | (one or more symbols per packet)
v v
source packet repair packet
Source Packet Repair Packet

Figure 1: Packet and symbol relationships Symbol Relationships at a Coding Node that
performs That
Performs Encoding (rather than Recoding). (Rather Than Recoding)

Source Node:
A node that generates one or more Source Flows.

Coding Node:
A node that performs FEC Encoding or Recoding operations. It may
be an end-host end host or a middlebox (Encoding case), or a forwarding
node (Recoding case).

(IETF) Flow:
A stream of packets logically grouped.

(IETF) Source Flow:
A flow of Source Packets coming from an application on a given host,
host and to which FEC encoding is to be applied, potentially along
with other Source Flows. Depending on the use case, Source Flows
may come from the same application, from different applications on
the same host, or from different applications on different hosts.

(IETF) Repair flow: Flow:
A flow containing Repair Packets, Packets after FEC encoding.

3. Taxonomy of Code Uses

This section discusses the various ways of using coding, without
going into coding details.

Source Coding versus Channel Coding:
(see Figure 2) When both terms are opposed, used, "Source Coding" usually
refers to compression techniques (e.g., audio and video
compression) within the upper application that generates the source flow. On the
opposite,
Source Flow. "Channel Coding" refers to FEC encoding in order to
improve transmission robustness, for instance instance, within the lower
physical layer (out of scope of this document) or as part of
Network Coding. These terms should not be confused with respectively "FEC
coding within the Source Node" and "FEC re-coding recoding within an
intermediate Coding Node". Node", respectively.

raw data flow from camera ^ video flow display
| | ^
v | upper |
+-----------------------+
+------------------------+ | +-----------------------+ +-------------------------+
| source coding | | applica- | source (de)coding |
|(e.g.
|(e.g., mpeg compression)| | tion |(eg. |(e.g., mpg decompression)|
+-----------------------+
+------------------------+ v +-----------------------+ +-------------------------+
| ^
v |
+-----------------------+
+------------------------+ ^ +-----------------------+ +-------------------------+
| network/AL-FEC coding | | middle- | network/AL-FEC coding |
| (e.g. (e.g., RLC encoding) | | ware | (e.g. (e.g., RLC decoding) |
+-----------------------+
+------------------------+ v +-----------------------+ +-------------------------+
| ^
v |
+-----------------------+
+------------------------+ ^ +-----------------------+ +-------------------------+
| packetization | | | depacketization |
| (e.g. (e.g., UDP/IP) | | communi- | (e.g. (e.g., UDP/IP) |
+-----------------------+
+------------------------+ | cation +-----------------------+ +-------------------------+
| | ^
v | layers |
+-----------------------+ | +-----------------------+ +-------------------------+
| PHY layer | | | PHY layer |
| (channel coding) | | | (channel decoding) |
+-----------------------+ v +-----------------------+ +-------------------------+
| ^
| source + repair traffic |
+-------------------------------------------+
+-----------------------------------------+

Figure 2: Example of end-to-end flow manipulation End-to-End Flow Manipulation with Network Coding

Figure 2 shows Network Coding between the application and UDP
layers (as with RMT or FECFRAME architectures). Other
architectures are possible, for instance instance, with
network coding Network Coding
below the transport layer in order to allow re-coding recoding within the network.

Intra-Flow Coding, Coding or Single Source Single-Source Network Coding:
Process where incoming packets to the Coding Node belong to the
same flow.

Inter-Flow Coding, Coding or Multi-Source Network Coding:
Process where incoming packets to the Coding Node belong to
different flows.

Single-Path Coding:
Network Coding over a route that has a single path from the source
to each destination(s). In case of multicast or broadcast
traffic, this route is a tree. Coding may be done end-to-end end to end
and/or at intermediate forwarding nodes.

Multi-Path Coding:
Network Coding over a route that has multiple (at least partially)
disjoint paths from the source to each given destination. Coding
may be done end-to-end end to end and/or at intermediate forwarding nodes.

4. Coding Details

4.1. Coding Types

This section provides a high-level taxonomy of coding techniques.
Technical details are left for the following discussed in subsequent sections.

Linear Coding:
Linear combination of a set of input symbols Input Symbols (i.e., Source and/or
Repair Symbols) using a given set of coefficients and resulting in
a Repair Symbol. Many linear codes exist that differ from the way
coding coefficients are drawn from a Finite Field of a given size.

Random Linear Coding (RLC):
Particular case of Linear Coding using a set of random coding
coefficients.

Adaptive Linear Coding:
Linear Coding that utilizes cross layer cross-layer adaptation. For instance,
an adaptive coding scheme may adapt the generation and
transmission of Repair Packets according to the channel variations
over time, accounting for the predictive loss of degrees of
freedom due to erasures.

Block Coding:
Coding technique where the input Flow(s) must be first be segmented
into a sequence of blocks, blocks; FEC encoding and decoding being are performed
independently on a per-block basis. The term "Chunk Coding" is
sometimes used, where a "Chunk" denotes a block.

Sliding Window Coding, Coding or Convolutional Coding:
General class of coding techniques that rely on a sliding encoding
window. This is an alternative solution to Block Coding.

Fixed or Elastic Sliding Window Coding:
Coding technique that generates Repair Symbol(s) on-the-fly, on the fly, from
the set of Source Symbols present in the sliding encoding window
at that time, usually by using Linear Coding. The sliding window
may be either of fixed size or of variable size over the time
(also known as "elastic sliding window"). "Elastic Sliding Window"). For instance, this the size
may depend on acknowledgments sent by the receiver(s) for a
particular Source Symbol or Source Packet (received, decoded, or
decodable).

Systematic Coding:
A coding technique where Source Symbols are part of the output
Flow generated by a Coding Node.

Rateless and Non-Rateless Non-rateless Coding:
Rateless Coding can generate an unlimited number of Repair Symbols
(in practice practice, this number can be limited by practical
considerations or because of use-
case use-case requirements) from a given
set of Source Symbols, meaning that the code rate is null. RLC
codes are an example of Rateless Codes. On the opposite, Non-Rateless Alternately, Non-rateless
Coding usually has a predefined maximum number of Repair Symbols
that can be generated from a given set of Source Symbols.

4.2. Coding Basics

This section discusses and defines low level low-level coding aspects.

Code Rate:
In case of a Block Code, the Code Rate is the k/n ratio between
the number of Source Symbols, k, and the number of Source plus
Repair Symbols, n. With a Sliding Window Code, the Code Rate is
defined similarly over a certain time interval, since the Code
Rate may change dynamically. By definition, the Code Rate is such
that: 0 < Code Rate <= 1. A Code Rate close to 1 indicates that a
small number of Repair Symbols have been produced during the
encoding process and vice-versa. vice versa.

(En)coding Window:
A set of Source (and Repair in the case of re-
coding) recoding) Symbols used
as input to the coding operations. The set of symbols will
typically change over the time, as the Coding Window slides over the
input Flow(s).

(En)coding Window Size:
The number of Source (and Repair in case of
re-coding) recoding) Symbols in
the current Encoding Window. This size may change over the time.

Payload Set:
The set of Source and Repair Symbols available (i.e., received or
previously decoded) at the receiver and used during FEC decoding
operations.

Decoding window: Window:
The set of Source Symbols (only) that are considered in the
current linear system of a receiver, independently of the fact
these Source Symbols have been received, decoded, or lost. The
Decoding Window will typically change over the time, as transmissions
and decoding progress, and may be different for different
receivers of a session where content is multicast or broadcast.

Decoding Window Size:
The number of Source Symbols (only) in the current Decoding
Window. This size may change over the time.

Rank of a Payload Set, Set or (IETF) Rank of the Linear System:
At a rec
eiver, receiver, number of linearly independent members of a Payload
Set, or equivalently the number of linearly independent equations
of the linear system. It is also known as "Degrees of Freedom".
The system may be of "full rank" and where decoding is possible, possible or
"partial rank", and rank" where only partial decoding is possible.

Seen Payload, Payload or Seen Symbol:
A Source Symbol is Seen when the receiver can compute a linear
combination with this symbol and Source Symbols that are strictly
more recent (i.e., with logically higher Encoding Symbol
Identifiers). Otherwise Otherwise, the Source Symbol is considered as "unseen".

Generation,
"Unseen".

Generation or (IETF) Block:
With Block Codes, the set of Source Symbols of the input Flow(s)
that are logically grouped into a Block, before doing encoding.

Generation Size, or Code Dimension, or (IETF) Block Size:
With Block Codes, the number k of Source Symbols Symbols, k, belonging to a
Block.

Coding Matrix, Matrix or Generator Matrix:
A matrix G that transforms the set of Input Symbols X into a set
of Repair Symbols: Y = X * G. Defining a Generator Matrix is usual
typical with Block Codes. The set of Input Symbols X can consist
only of Source Symbols (e.g., with End-to-End Coding) or can
consist of Source and Repair Symbols (e.g., with re-coding recoding in an
intermediate node).

Coding Coefficient:
With Linear Coding, this is a coefficient in a certain Finite
Field. This coefficient may be chosen in different ways: for
instance, randomly, or in a pre-defined predefined table, or using a pre-defined predefined
algorithm plus a seed.

Coding Vector:
A set of Coding Coefficients used to generate a certain Repair
Symbol through Linear Coding. The number of nonzero coefficients
in the Coding Vector defines its density.

Finite Field, or Galois Field, or Coding Field:
Finite fields, Fields, used in Linear Codes, have the desired property of
having all elements (except zero) invertible for the + and *
operators, and all operations over any elements do not result in
an overflow or underflow. Examples of Finite Fields are prime
fields {0..p^m-1}, where p is prime. Most The most used fields use p=2
and are called binary extension fields {0..2^m-1}, where m often
equals 1, 4 4, or 8 for practical reasons.

Finite Field size, size or Coding Field size:
The number of elements in a
finite field. Finite Field. For example example, the binary
extension field {0..2^m-1} has size q=2^m.

Feedback:
Feedback information sent by a decoding node to a Coding Node (or
from a receiver to a source in case of End-to-End Coding). The
nature of information contained in a feedback packet varies,
depending on the use-case. use case. It can provide reception and/or FEC
decoding statistics, or the list of available Source Packets received
or decoded (acknowledgement), or the list of lost Source Packets that
should be retransmitted (negative acknowledgement), or a number of
additional Repair Symbols needed to have a Full Rank Linear
System.

4.3. Coding In in Practice

This section discusses practical aspects. Indeed, a practical
solution must specify the exact manner in which encoding and decoding is
are performed but also detail all the peripheral aspects, for instance
instance, how an encoder informs a decoder about the parameters used
to generate a certain Repair Packet (signaling).

(IETF) FEC Scheme:
A specification that defines a particular FEC code as well as the
additional protocol aspects required to use a particular this FEC code. In
particular
particular, the FEC Scheme defines in band in-band (e.g., information
contained in Source and Repair Packet header or trailers) and
out of band out-
of-band (e.g., information contained in an SDP description)
signaling needed to synchronize encoders and decoders.

Payload Indices, Index or (IETF) Encoding Symbol Identifiers Identifier (ESI):
An ide
ntifier identifier of a Source or Repair Symbol. If conceptually, With Block Coding,
each symbol of a given block is identified by a unique ESI value, in practice, with value.
With Sliding Window Coding, a continuous flow Source Flow and a limited
field size to hold the ESI, wrapping to zero in is unavoidable and
the same integer value will be re-used reused several times.

(IETF) FEC Payload ID:
Information that identifies the contents of a packet with respect
to the FEC Scheme. The FEC Payload ID of a packet containing
Source Symbol(s) is usually different from that of a packet
containing Repair Symbol(s). The FEC Payload ID typically
contains at least an ESI.

Coding Vector and Encoding Window Signaling:
With Sliding Window Codes, the FEC Payload ID of a Repair Packet
contains information needed and sufficient to identify the Coding
Vector and Coding Window. Concerning the Coding Vector, this may
consist of a full list of Coding Coefficients (that may
be compressed or not), may not
be compressed), or a piece of information (e.g., a seed) that can
be used to generate the list of Coding Coefficients thanks to a
predefined algorithm known by encoders and decoders (e.g., a Pseudo Random
Pseudorandom Number Generator, or PRNG), PRNG) or an ESI that points to a
given entry in a Generator Matrix in case of a Block Code.
Concerning the Coding Window, this may consist of the full list of
ESI of symbols in the Coding Window (that may be compressed or
not), may not be
compressed) or the ESI of the first Source Symbol along with their
number (assuming there is no gap).

5. IANA Considerations

This document is not subject to has no IANA registration. actions.

6. Security Considerations

This document introduces a recommended terminology for network coding Network Coding
and therefore does not contain any security consideration. considerations. This
does not mean that network coding Network Coding systems do not have any security
implication.

7. References

7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References

[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052,
DOI 10.17487/RFC5052, August 2007,
<https://www.rfc-editor.org/info/rfc5052>.

[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009,
<https://www.rfc-editor.org/info/rfc5740>.

[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation", RFC 5775,
DOI 10.17487/RFC5775, April 2010,
<https://www.rfc-editor.org/info/rfc5775>.

[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363,
DOI 10.17487/RFC6363, October 2011,
<https://www.rfc-editor.org/info/rfc6363>.

[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,
"FLUTE - File Delivery over Unidirectional Transport",
RFC 6726, DOI 10.17487/RFC6726, November 2012,
<https://www.rfc-editor.org/info/rfc6726>.

Appendix A. Additional references

Additional references on network coding are available in the NWCRG
research web site: https://irtf.org/nwcrg

Appendix B. Authors and Contributors

This document is the result of a collaborative work that involved
many authors and contributors from the IRTF NWCRG. They are listed
in alphabetical order in this document.

Authors' Addresses

Brian Adamson
NRL
USA
United States of America

Email: brian.adamson@nrl.navy.mil

Cedric Adjih
INRIA
France

Email: cedric.adjih@inria.fr

Josu Bilbao
Ikerlan
Spain

Email: jbilbao@ikerlan.es

Victor Firoiu
BAE Systems
USA
United States of America

Email: victor.firoiu@baesystems.com

Frank Fitzek
TU Dresden
Germany

Email: frank.fitzek@tu-dresden.de

Samah A. M. Ghanem
Independant
Independent

Email: samah.ghanem@gmail.com

Emmanuel Lochin
ISAE - Supaero
France

Email: emmanuel.lochin@isae-supaero.fr
Antonia Masucci
Orange
France

Email: antoniamaria.masucci@orange.com

Marie-Jose Montpetit
Independant
USA
Independent
United States of America

Email: marie@mjmontpetit.com

Morten V. Pedersen
Aalborg University
Denmark

Email: mvp@es.aau.dk

Goiuri Peralta
Ikerlan
Spain

Email: gperalta@ikerlan.es

Vincent Roca (editor)
INRIA
France

Email: vincent.roca@inria.fr

Paresh Saxena
AnsuR Technologies
Norway

Email: paresh.saxena@ansur.es

Senthil Sivakumar
Cisco
USA
United States of America

Email: ssenthil@cisco.com