Internet DRAFT - draft-irtf-nwcrg-network-coding-taxonomy
draft-irtf-nwcrg-network-coding-taxonomy
NWCRG B. Adamson
Internet-Draft NRL
Intended status: Informational C. Adjih
Expires: September 19, 2018 INRIA
J. Bilbao
Ikerlan
V. Firoiu
BAE Systems
F. Fitzek
TU Dresden
S. Ghanem
Independant
E. Lochin
ISAE - Supaero
A. Masucci
Orange
M-J. Montpetit
Independant
M. Pedersen
Aalborg University
G. Peralta
Ikerlan
V. Roca, Ed.
INRIA
P. Saxena
AnsuR Technologies
S. Sivakumar
Cisco
March 18, 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 with the terminology used
by the RFCs produced by the Reliable Multicast Transport (RMT) and
FEC Framework (FECFRAME) IETF working groups.
Adamson, et al. Expires September 19, 2018 [Page 1]
Internet-Draft Taxonomy of Coding Techniques March 2018
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
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 are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents 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.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 and 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 Practice . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Additional references . . . . . . . . . . . . . . . 14
Adamson, et al. Expires September 19, 2018 [Page 2]
Internet-Draft Taxonomy of Coding Techniques March 2018
Appendix B. Authors and Contributors . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
This document is not an IETF product and is not a standard. This
document is the product and represents the consensus of the Network
Coding Research Group (NWCRG). In 2017, it has been discussed during
three audio conferences, each of them gathering 6 to 8 key experts,
it has been co-edited, and finally subject to a RG Last Call. The
general feeling was that the document was ready for the next step.
The literature on Network Coding research and system design, IETF
included, 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 taxonomy. Its primary goal is to be useful to IETF and IRTF
activities. It is also 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] [RFC6726]. Note that in the
definitions, the "(IETF)" tag indicates that the associated term is
already used in IETF documents.
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 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 the goals of Network Coding
can be to improve the network throughput, efficiency, latency, and
scalability, as well as providing resilience to partition, attacks,
and eavesdropping (NWCRG charter). Both End-to-End Coding and
systems that also perform re-coding within intermediate forwarding
nodes are considered in this document.
This document does not consider physical layer transmission issues,
nor physical layer codes, nor error detection: if low layer error
codes detect but fail to correct bit errors, or if an upper layer
checksum (e.g., within IP or UDP) identifies a corrupted packet, then
this packet is supposed to be dropped.
Adamson, et al. Expires September 19, 2018 [Page 3]
Internet-Draft Taxonomy of Coding Techniques March 2018
1.1. Requirements Language
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. General definitions and concepts
This section gathers 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 opposed to "Error"
channels where one or multiple bit errors may happen during a
packet transmission. These "Error" channels are out of
scope.
Erasure Correcting Code (ECC), or (IETF) Forward Erasure Code (FEC):
A code for the Packet Erasure Channel (only). These
codes are also called "Application-Level FEC" to
highlight that they have been designed to be used within
the higher layers of the protocol stack, to protect
against packet losses. These codes are opposed to
"Error" correction codes that are capable of identifying
the presence and/or correcting bit errors. 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 at the
destination(s) or (decoding) middlebox. There is no re-
coding operation at intermediate nodes. This is the
approach followed in the FLUTE/ALC [RFC6726][RFC5775],
NORM [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 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 the destination of the coding nodes
topology and coding operations can help during decoding
operations.
Adamson, et al. Expires September 19, 2018 [Page 4]
Internet-Draft Taxonomy of Coding Techniques March 2018
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 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 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 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, to address
variable size 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
Adamson, et al. Expires September 19, 2018 [Page 5]
Internet-Draft Taxonomy of Coding Techniques March 2018
during encoding and decoding operations) in case of FEC encoding, at
a Coding Node that performs Encoding (rather than Recoding). FEC
decoding procedures are similarly performed in the reverse order.
source packet
|
| source packet to source symbols transform
| (one or more symbols per packet)
v
source symbols
|
v input symbols
+----------------------+
| FEC encoding |
+----------------------+
| output symbols |
v v
source symbols repair symbols
| |
| | symbol to packet transform
| | (one or more symbols per packet)
v v
source packet repair packet
Figure 1: Packet and symbol relationships at a Coding Node that
performs Encoding (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 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, 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: A flow containing Repair Packets, after FEC
encoding.
Adamson, et al. Expires September 19, 2018 [Page 6]
Internet-Draft Taxonomy of Coding Techniques March 2018
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, "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, "Channel Coding" refers to FEC encoding in order to
improve transmission robustness, for 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 within an intermediate Coding Node".
Adamson, et al. Expires September 19, 2018 [Page 7]
Internet-Draft Taxonomy of Coding Techniques March 2018
raw data flow from camera ^ video flow display
| | ^
v | upper |
+-----------------------+ | +-----------------------+
| source coding | | applica- | source (de)coding |
|(e.g. mpeg compression)| | tion |(eg. mpg decompression)|
+-----------------------+ v +-----------------------+
| ^
v |
+-----------------------+ ^ +-----------------------+
| network/AL-FEC coding | | middle- | network/AL-FEC coding |
| (e.g. RLC encoding) | | ware | (e.g. RLC decoding) |
+-----------------------+ v +-----------------------+
| ^
v |
+-----------------------+ ^ +-----------------------+
| packetization | | | depacketization |
| (e.g. UDP/IP) | | communi- | (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 with Network Coding
between the application and UDP layers (as with RMT or FECFRAME
architectures). Other architectures are possible, for instance with
network coding below the transport layer in order to allow re-coding
within the network.
Intra-Flow Coding, or Single Source Network Coding: Process where
incoming packets to the Coding Node belong to the same flow.
Inter-Flow 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 and/or at intermediate forwarding
nodes.
Adamson, et al. Expires September 19, 2018 [Page 8]
Internet-Draft Taxonomy of Coding Techniques March 2018
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 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 sections.
Linear Coding: Linear combination of a set of 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
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
segmented into a sequence of blocks, FEC encoding and
decoding being performed independently on a per-block basis.
The term "Chunk Coding" is sometimes used, where a "Chunk"
denotes a block.
Sliding Window 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, 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"). For instance, this size
may depend on acknowledgments sent by the receiver(s) for a
particular Source Symbol or Source Packet (received, decoded,
or decodable).
Adamson, et al. Expires September 19, 2018 [Page 9]
Internet-Draft Taxonomy of Coding Techniques March 2018
Systematic Coding: A coding technique where Source Symbols are part
of the output Flow generated by a Coding Node.
Rateless and Non-Rateless Coding: Rateless Coding can generate an
unlimited number of Repair Symbols (in practice this number
can be limited by practical considerations or because of 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 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 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.
(En)coding Window: A set of Source (and Repair in the case of re-
coding) 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) 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: 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.
Adamson, et al. Expires September 19, 2018 [Page 10]
Internet-Draft Taxonomy of Coding Techniques March 2018
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, or (IETF) Rank of the Linear System: At a rec
eiver, 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 decoding
is possible, or "partial rank", and only partial decoding is
possible.
Seen 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 the
Source Symbol is considered as "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 belonging to a Block.
Coding 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 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 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: randomly, or in a pre-defined table, or using
a pre-defined 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, used
in Linear Codes, have the desired property of having all
elements (except zero) invertible for + and * 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 used fields use p=2 and
Adamson, et al. Expires September 19, 2018 [Page 11]
Internet-Draft Taxonomy of Coding Techniques March 2018
are called binary extension fields {0..2^m-1}, where m often
equals 1, 4 or 8 for practical reasons.
Finite Field size, or Coding Field size: The number of elements in a
finite field. For 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. 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 Practice
This section discusses practical aspects. Indeed, a practical
solution must specify the exact manner encoding and decoding is
performed but also all the peripheral aspects, for 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 the additional
protocol aspects required to use a particular FEC code. In
particular the FEC Scheme defines in band (e.g., information
contained in Source and Repair Packet header or trailers) and
out of band (e.g., information contained in an SDP
description) signaling needed to synchronize encoders and
decoders.
Payload Indices, or (IETF) Encoding Symbol Identifiers (ESI): An ide
ntifier of a Source or Repair Symbol. If conceptually, each
symbol is identified by a unique ESI value, in practice, with
a continuous flow and a limited field size to hold the ESI,
wrapping to zero in unavoidable and the same integer value
will be re-used 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.
Adamson, et al. Expires September 19, 2018 [Page 12]
Internet-Draft Taxonomy of Coding Techniques March 2018
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), 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 Number
Generator, or 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), 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 IANA registration.
6. Security Considerations
This document introduces a recommended terminology for network coding
and therefore does not contain any security consideration. This does
not mean that 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>.
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>.
Adamson, et al. Expires September 19, 2018 [Page 13]
Internet-Draft Taxonomy of Coding Techniques March 2018
[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
Email: brian.adamson@nrl.navy.mil
Cedric Adjih
INRIA
France
Email: cedric.adjih@inria.fr
Josu Bilbao
Ikerlan
Spain
Email: jbilbao@ikerlan.es
Adamson, et al. Expires September 19, 2018 [Page 14]
Internet-Draft Taxonomy of Coding Techniques March 2018
Victor Firoiu
BAE Systems
USA
Email: victor.firoiu@baesystems.com
Frank Fitzek
TU Dresden
Germany
Email: frank.fitzek@tu-dresden.de
Samah A. M. Ghanem
Independant
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
Email: marie@mjmontpetit.com
Morten V. Pedersen
Aalborg University
Denmark
Email: mvp@es.aau.dk
Adamson, et al. Expires September 19, 2018 [Page 15]
Internet-Draft Taxonomy of Coding Techniques March 2018
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
Email: ssenthil@cisco.com
Adamson, et al. Expires September 19, 2018 [Page 16]
