rfc9265xml2.original.xml   rfc9265.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY nbsp "&#160;">
.2119.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc
category="info"
docName="draft-irtf-nwcrg-coding-and-congestion-12"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc category="info" docName="draft-irtf-nwcrg-coding-and-congestion-12" number= "9265" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType ="IRTF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="tr ue" version="3">
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="Coding and congestion">Coding and congestion control in trans
port</title>
<title abbrev="FEC Coding and Congestion">Forward Erasure Correction (FEC) C
oding and
Congestion Control in Transport</title>
<seriesInfo name="RFC" value="9265" />
<author fullname="Nicolas Kuhn" initials="N" surname="Kuhn"> <author fullname="Nicolas Kuhn" initials="N" surname="Kuhn">
<organization>CNES</organization> <organization>CNES</organization>
<address> <address>
<email>nicolas.kuhn.ietf@gmail.com</email> <email>nicolas.kuhn.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Emmanuel Lochin" initials="E" surname="Lochin"> <author fullname="Emmanuel Lochin" initials="E" surname="Lochin">
<organization>ENAC</organization> <organization>ENAC</organization>
<address> <address>
<email>emmanuel.lochin@enac.fr</email> <email>emmanuel.lochin@enac.fr</email>
</address> </address>
</author> </author>
<author fullname="François Michel" initials="F" surname="Michel">
<author fullname="Francois Michel" initials="F" surname="Michel">
<organization>UCLouvain</organization> <organization>UCLouvain</organization>
<address> <address>
<email>francois.michel@uclouvain.be</email> <email>francois.michel@uclouvain.be</email>
</address> </address>
</author> </author>
<author fullname="Michael Welzl" initials="M" surname="Welzl"> <author fullname="Michael Welzl" initials="M" surname="Welzl">
<organization>University of Oslo</organization> <organization>University of Oslo</organization>
<address> <address>
<email>michawe@ifi.uio.no</email> <email>michawe@ifi.uio.no</email>
</address> </address>
</author> </author>
<date month="July" year="2022"/>
<date year="2022"/>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc will fill
in the current day and month for you. If the year is not the current one, i
t is
necessary to specify at least a month (xml2rfc assumes day="1" if not speci
fied for the
purpose of calculating the expiry date). With drafts it is normally suffic
ient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>IRTF</area> <area>IRTF</area>
<workgroup>Network Coding for Efficient Network Communications</workgroup>
<workgroup>NWCRG</workgroup> <keyword>Coding</keyword>
<keyword>congestion</keyword>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<keyword>Coding, congestion</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<!-- ######################################################-->
<!-- ######################################################-->
<!-- Head of the document -->
<!-- ######################################################-->
<!-- ######################################################-->
<abstract> <abstract>
<t>Forward Erasure Correction (FEC) is a reliability mechanism that i <t>Forward Erasure Correction (FEC) is a reliability mechanism that is dis
s distinct and separate from the retransmission logic in reliable transfer proto tinct and separate from the retransmission logic in reliable transfer protocols
cols such as TCP. FEC coding can help deal with losses at the end of transfers o such as TCP. FEC coding can help deal with losses at the end of transfers or wit
r with networks having non-congestion losses. However, FEC coding mechanisms sho h networks having non-congestion losses. However, FEC coding mechanisms should n
uld not hide congestion signals. This memo offers a discussion of how FEC coding ot hide congestion signals. This memo offers a discussion of how FEC coding and
and congestion control can coexist. Another objective is to encourage the resea congestion control can coexist. Another objective is to encourage the research c
rch community to also consider congestion control aspects when proposing and com ommunity to also consider congestion control aspects when proposing and comparin
paring FEC coding solutions in communication systems.</t> g FEC coding solutions in communication systems.</t>
<t>This document is the product of the Coding for Efficient Network Comm <t>This document is the product of the Coding for Efficient Network Commun
unications Research Group (NWCRG). The scope of the document is end-to-end commu ications Research Group (NWCRG). The scope of the document is end-to-end communi
nications: FEC coding for tunnels is out-of-the scope of the document.</t> cations; FEC coding for tunnels is out of the scope of the document.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sec_introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>There are cases where deploying FEC coding improves the performance of
a transmission. As an example, it may take time for a sender to detect transfer
tail losses (losses that occur at the end of a transfer where, e.g., TCP obtains
no more ACKs that would enable it to quickly repair the loss via retransmission
). Allowing the receiver to recover such losses instead of having to rely on a r
etransmission could improve the experience of applications using short flows. An
other example is a network where non-congestion losses are persistent and preven
t a sender from exploiting the link capacity.</t>
<section anchor="sec:introduction" title="Introduction"> <t>
<t>There are cases where deploying FEC coding improves the performance of Coding and the loss detection of congestion controls are two distinct
a transmission. As an example, it may take time for a sender to detect transfer and separate reliability mechanisms.
tail losses (losses that occur at the end of a transfer, where, e.g., TCP obtai Since FEC coding repairs losses, blindly applying FEC may easily lead to an impl
ns no more ACKs that would enable it to quickly repair the loss via retransmissi ementation that also hides a congestion signal from the sender. It is important
on). Allowing the receiver to recover such losses instead of having to rely on a to ensure that such hiding of information does not occur, because loss may be t
retransmission could improve the experience of applications using short flows. he only congestion signal available to the sender (e.g., TCP <xref target="RFC56
Another example is a network where non-congestion losses are persistent and prev 81" format="default"/>).</t>
ent a sender from exploiting the link capacity.</t> <t>FEC coding and congestion control can be seen as two separate channels.
<t>Coding and the loss detection of congestion controls are two distinct In practice, implementations may mix the signals that are exchanged on these ch
and separate reliability mechanisms that is distinct and separate from the loss annels. This memo offers a discussion of how FEC coding and congestion control c
detection of congestion controls. Since FEC coding repairs losses, blindly appl oexist. Another objective is to encourage the research community to also conside
ying FEC may easily lead to an implementation that also hides a congestion signa r congestion control aspects when proposing and comparing FEC coding solutions i
l from the sender. It is important to ensure that such information hiding does n communication systems. This document does not aim to propose guidelines for ch
not occur, because loss may be the only congestion signal available to the sende aracterizing
r (e.g. TCP <xref target="RFC5681"/>).</t>
<t>FEC coding and congestion control can be seen as two separate channels
. In practice, implementations may mix the signals that are exchanged on these c
hannels. This memo offers a discussion of how FEC coding and congestion control
coexist. Another objective is to encourage the research community also to consid
er congestion control aspects when proposing and comparing FEC coding solutions
in communication systems. This document does not aim at proposing guidelines for
characterizing
FEC coding solutions.</t> FEC coding solutions.</t>
<t>We consider three architectures for end-to-end unicast data transfer:< <t>We consider three architectures for end-to-end unicast data transfer:</
list style="symbols"> t>
<t>with FEC coding in the application (above the transport) (<xre <ul spacing="normal">
f target="sec:fec-above"/>),</t> <li>with FEC coding in the application (above the transport) (<xref targ
<t>within the transport (<xref target="sec:fec-in"/>), or</t> et="sec_fec-above" format="default"/>),</li>
<t>directly below the transport (<xref target="sec:fec-below"/>). <li>within the transport (<xref target="sec_fec-in" format="default"/>),
</t> or</li>
</list></t> <li>directly below the transport (<xref target="sec_fec-below" format="d
<t>A typical scenario for the considerations in this document is a client efault"/>).</li>
browsing the web or watching a live video.</t> </ul>
<t>This document represents the collaborative work and consensus of the C <t>A typical scenario for the considerations in this document is a client
oding for Efficient Network Communications Research Group (NWCRG); it is not an browsing the Web or watching a live video.</t>
IETF product and is not a standard. The document follows the terminology propose <t>This document represents the collaborative work and consensus of the Co
d in the taxonomy document <xref target="RFC8406"></xref>.</t> ding for Efficient Network Communications Research Group (NWCRG); it is not an I
ETF product nor a standard. The document follows the terminology proposed in the
taxonomy document <xref target="RFC8406" format="default"/>.</t>
</section> </section>
<!-- ######################################################--> <section anchor="sec_notations" numbered="true" toc="default">
<!-- ######################################################--> <name>Context</name>
<!-- Body of the document --> <section anchor="subsec_def_fairness" numbered="true" toc="default">
<!-- ######################################################--> <name>Fairness, Quantifying and Limiting Harm, and Policy Concerns</name
<!-- ######################################################--> >
<t>Traffic from or to different end users may share various types of bot
<!-- ######################################################--> tlenecks. When such a shared bottleneck does not implement some form of flow pro
<!-- New section --> tection, the share of the available capacity between single flows can help asses
<!-- ######################################################--> s when one flow starves the other.</t>
<t>As one example, for residential accesses, the data rate can be guaran
<!-- ######################################################--> teed for the customer premises equipment but not necessarily for the end user. T
<!-- New section --> he quality of service that guarantees fairness between the different clients can
<!-- ######################################################--> be seen as a policy concern <xref target="I-D.briscoe-tsvarea-fair" format="def
<section anchor="sec:notations" title="Context"> ault"/>.</t>
<t>While past efforts have focused on achieving fairness, quantifying an
<section anchor="subsec:def_fairness" title="Fairness, Quantifying and Li d limiting harm caused by new algorithms (or algorithms with coding) is more pra
miting Harm, and Policy Concerns"> ctical <xref target="BEYONDJAIN" format="default"/>. This document considers fai
<t>Traffic from or to different end users may share vario rness as the impact of the addition of coded flows on non-coded flows when they
us types of bottlenecks. When such a shared bottleneck does not implement some f share the same bottleneck. It is assumed that the non-coded flows respond to con
orm of flow protection, the share of the available capacity between single flows gestion signals from the network. This document does not contribute to the defin
can help assess when one flow starves the other.</t> ition of fairness at a wider scale.</t>
<t>As one example, for residential accesses, the data rat </section>
e can be guaranteed for the customer premises equipment, but not necessarily for <section numbered="true" toc="default">
the end user. The quality of service that guarantees fairness between the diffe <name>Separate Channels, Separate Entities</name>
rent clients can be seen as a policy concern <xref target="I-D.briscoe-tsvarea-f <t>Figures <xref target="fig_sep-channel-cc" format="counter"/> and <xre
air"></xref>.</t> f target="fig_sep-channel-fec" format="counter"/> present the notations that wil
<t>While past efforts have focused on achieving fairness, l be used in this document and introduce the Forward Erasure Correction (FEC) an
quantifying and limiting harm caused by new algorithms (or algorithms with codi d Congestion Control (CC) channels. The FEC channel carries repair symbols (from
ng) is more practical <xref target="BEYONDJAIN"></xref>. This document considers the sender to the receiver) and information from the receiver to the sender (e.
fairness as the impact of the addition of coded flows on non-coded flows when t g., signaling which symbols have been recovered, loss rate prior and/or after de
hey share the same bottleneck. It is assumed that the non-coded flows respond to coding, etc.). The CC channel carries network packets from a sender to a receive
congestion signals from the network. This document does not contribute to the d r and packets signaling information about the network (number of packets receive
efinition of fairness at a wider scale.</t> d vs. lost, Explicit Congestion Notification (ECN) marks <xref target="RFC3168"
</section> format="default"/>, etc.) from the receiver to the sender. The network packets t
hat are sent by the CC channel may be composed of source packets and/or repair s
<section title="Separate channels, separate entities"> ymbols.</t>
<t><xref target="fig:sep-channel-cc"></xref> and <xref target="fi <figure anchor="fig_sep-channel-cc">
g:sep-channel-fec"></xref> present the notations that will be used in this docum <name>Congestion Control (CC) Channel</name>
ent and introduces the Forward Erasure Correction (FEC) and Congestion Control ( <artwork name="" type="" align="left" alt=""><![CDATA[
CC) channels. The Forward Erasure Correction channel carries repair symbols (fro
m the sender to the receiver) and information from the receiver to the sender (e
.g. signaling which symbols have been recovered, loss rate prior and/or after de
coding, etc.). The Congestion Control channel carries network packets from a sen
der to a receiver, and packets signaling information about the network (number o
f packets received vs. lost, Explicit Congestion Notification (ECN) <xref target
="RFC3168"/> marks, etc.) from the receiver to the sender. The network packets t
hat are sent by the Congestion Control channel may be composed of source packets
and/or repair symbols.</t>
<figure anchor="fig:sep-channel-cc" title="Congestion Control (CC) chann
el">
<artwork>
SENDER RECEIVER SENDER RECEIVER
+------+ +------+ +------+ +------+
| | <![CDATA[-----]]> network packets ---->| | | | ----- network packets ---->| |
| CC | | CC | | CC | | CC |
| | <![CDATA[<---]]> network information ---| | | | <--- network information ---| |
+------+ +------+ +------+ +------+
</artwork> ]]></artwork>
</figure> </figure>
<figure anchor="fig_sep-channel-fec">
<figure anchor="fig:sep-channel-fec" title="Forward Erasure Correction (F <name>Forward Erasure Correction (FEC) Channel</name>
EC) channel"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
SENDER RECEIVER SENDER RECEIVER
+------+ +------+ +------+ +------+
| | source and/or | | | | source and/or | |
| | <![CDATA[-----]]> repair symbols ---->| | | | ----- repair symbols ---->| |
| FEC | | FEC | | FEC | | FEC |
| | signaling | | | | signaling | |
| | <![CDATA[<---]]> recovered symbols ----| | | | <--- recovered symbols ----| |
+------+ +------+ +------+ +------+
</artwork> ]]></artwork>
</figure> </figure>
<t>Inside a host, the CC and FEC entities can be regarded as <t>Inside a host, the CC and FEC entities can be regarded as
conceptually separate:</t> conceptually separate:</t>
<figure anchor="fig_sep-entities-srv">
<figure anchor="fig:sep-entities-srv" title="Separate entities (sender-si <name>Separate Entities (Sender-Side)</name>
de)"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
| ^ | ^ | ^ | ^
| source | coding |packets | sending | source | coding |packets | sending
| packets | rate |requirements | rate (or | packets | rate |requirements | rate (or
v | v | window) v | v | window)
+---------------+source +-----------------+ +---------------+source +-----------------+
| FEC |and/or | CC | | FEC |and/or | CC |
| |repair | |network | |repair | |network
| |symbols | |packets | |symbols | |packets
+---------------+==> +-----------------+==> +---------------+==> +-----------------+==>
^ ^ ^ ^
| signaling | network | signaling | network
| recovered symbols | information | recovered symbols | information
</artwork> ]]></artwork>
</figure> </figure>
<figure anchor="fig_sep-entities-clt">
<figure anchor="fig:sep-entities-clt" title="Separate entities (receiver- <name>Separate Entities (Receiver-Side)</name>
side)"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
| | | |
| source and/or | network | source and/or | network
| repair symbols | packets | repair symbols | packets
v v v v
+---------------+ +-----------------+ +---------------+ +-----------------+
| FEC |signaling | CC | | FEC |signaling | CC |
| |recovered | |network | |recovered | |network
| |symbols | |information | |symbols | |information
+---------------+==> +-----------------+==> +---------------+==> +-----------------+==>
</artwork> ]]></artwork>
</figure> </figure>
<t>Figures <xref target="fig_sep-entities-srv" format="counter"/> and <x
ref target="fig_sep-entities-clt" format="counter"/> provide more details than F
igures <xref target="fig_sep-channel-cc" format="counter"/> and <xref target="fi
g_sep-channel-fec" format="counter"/>. Some elements are introduced:</t>
<dl newline="true">
<dt>'network information' (input control plane for the transport includ
ing CC):
</dt>
<dd>refers not only to the network information that is explicitly
signaled from the receiver but all the information a congestion
control obtains from a network.
</dd>
<t><xref target="fig:sep-entities-srv"></xref> and <xref target="fig:sep- <dt>'requirements' (input control plane for the transport including CC)
entities-clt"></xref> provide more details than <xref target="fig:sep-channel-cc :
"></xref> and <xref target="fig:sep-channel-fec"></xref>. Some elements are intr </dt>
oduced:<list style="symbols"> <dd>refers to application requirements such as upper/lower rate
<t>'network information' (input control plane for the tra bounds, periods of quiescence, or a priority.
nsport including CC): refers not only to the network information that is explici </dd>
tly signaled from the receiver, but all the information a congestion control obt
ains from a network.</t>
<t>'requirements' (input control plane for the transport includin
g CC): refers to application requirements such as upper/lower rate bounds, perio
ds of quiescence, or a priority.</t>
<t>'sending rate (or window)' (output control plane for the trans
port including CC): refers to the rate at which a congestion control decides to
transmit packets based on 'network information'.</t>
<t>'signaling recovered symbols' (input control plane for the FEC
): refers to the information a FEC sender can obtain from a FEC receiver about t
he performance of the FEC solution as seen by the receiver.</t>
<t>'coding rate' (output control plane for the FEC): refers to th
e coding rate that is used by the FEC solution (i.e. proportion of transmitted
symbols that carry useful data).</t>
<t>'network packets' (output data plane for the CC): refers to th
e data that is transmitted by a CC sender to a CC receiver. The network packets
may contain source and/or repair symbols.</t>
<t>'source and/or repair symbols' (data plane for the FEC): refer
s to the data that is transmitted by a FEC sender to a FEC receiver. The sender
can decide to send source symbols only (meaning that the coding rate is 0), repa
ir symbols only (if the solution decides not to send the original source symbols
) or a mix of both.</t>
</list></t>
<!-- <t><xref target="fig:sep-entities"></xref> provides more details tha <dt>'sending rate (or window)' (output control plane for the transport
n including CC):
<xref target="fig:sep-channel"></xref> by focusing on the server side. -- </dt>
> <dd>refers to the rate at which a congestion control decides to
<t>The inputs to FEC (incoming data packets without repair symbols, and s transmit packets based on 'network information'.
ignaling </dd>
<dt>'signaling recovered symbols' (input control plane for the FEC):
</dt>
<dd>refers to the information a FEC sender can obtain from a FEC
receiver about the performance of the FEC solution as seen by the
receiver.
</dd>
<dt>'coding rate' (output control plane for the FEC):
</dt>
<dd>refers to the coding rate that is used by the FEC solution (i.e.,
proportion of transmitted symbols that carry useful data).
</dd>
<dt>'network packets' (output data plane for the CC):
</dt>
<dd>refers to the data that is transmitted by a CC sender to a CC
receiver. The network packets may contain source and/or repair
symbols.
</dd>
<dt>'source and/or repair symbols' (data plane for the FEC):
</dt>
<dd>refers to the data that is transmitted by a FEC sender to a FEC
receiver. The sender can decide to send source symbols only (meaning
that the coding rate is 0), repair symbols only (if the solution
decides not to send the original source symbols), or a mix of both.
</dd>
</dl>
<t>The inputs to FEC (incoming data packets without repair symbols and si
gnaling
from the receiver about losses and/or recovered symbols) from the receiver about losses and/or recovered symbols)
are distinct from the inputs to CC. The latter calculates a are distinct from the inputs to CC. The latter calculates a
sending rate or window from network information, and it takes sending rate or window from network information, and it takes
the packet to send as input, sometimes along with application requiremen ts the packet to send as input, sometimes along with application requiremen ts
such as upper/lower rate bounds, periods of quiescence, or a priority. such as upper/lower rate bounds, periods of quiescence, or a priority.
It is not clear that the ACK signals feeding into a congestion control It is not clear that the ACK signals feeding into a congestion control
algorithm are useful to FEC in their raw form, and vice versa - info algorithm are useful to FEC in their raw form, and vice versa; infor
rmation mation
about recovered blocks may be quite irrelevant to a CC algorithm. <!- about recovered blocks may be quite irrelevant to a CC algorithm.
- However, </t>
there can be meaningful other interactions (indicated by the horizon </section>
tal double arrow) <section numbered="true" toc="default">
between the two entities, usually as a result of their operation rat <name>Relation between Transport Layer and Application Requirements</nam
her than e>
by relaying their own raw inputs. For example, the network measuremen <t>The choice of the adequate transport layer may be related to applicat
ts carried ion requirements and the services offered by a transport protocol <xref target="
out by CC can yield a longer-term statistical measure such as a loss RFC8095" format="default"/>:</t>
ratio
which is useful input for a FEC coding scheme. Similarly, unequal er
ror
protection using fountain codes can be used to assign different prio
rities
to blocks of data, and these priorities can be honored by a CC mechan
ism. --> </t>
</section>
<section title="Relation between transport layer and application requirem
ents">
<t>The choice of the adequate transport layer may be related to application <t indent="3">
requirements and the services offered by a transport protocol <xref target="RFC8 The transport layer may implement a retransmission mechanism to guarantee the re
095"></xref>:<list style="symbols"> liability of a data transfer (e.g., TCP). Depending on how the FEC and CC functi
<t>The transport layer may implement a retransmission mechani ons are scheduled (FEC above CC (<xref target="sec_fec-above" format="default"/>
sm to guarantee the reliability of a data transfer (e.g. TCP). Depending on how ), FEC in CC (<xref target="sec_fec-in" format="default"/>), and FEC below CC (<
the FEC and CC functions are scheduled (FEC above CC (<xref target="sec:fec-abov xref target="sec_fec-below" format="default"/>)), the impact of reliable transpo
e"/>), FEC in CC (<xref target="sec:fec-in"/>), FEC below CC (<xref target="sec: rt on the FEC reliability mechanisms is different.
fec-below"/>)), the impact of reliable transport on the FEC reliability mechanis </t>
ms is different.</t></list></t>
<t>The transport layer may provide an unreliable transport service (e.g. UDP
or DCCP <xref target="RFC4340"></xref>) or a partially reliable transport servi
ce (e.g. SCTP with the partial reliability extension <xref target="RFC3758"></xr
ef> or QUIC with the unreliable datagram extension <xref target="I-D.ietf-quic-d
atagram"></xref>). Depending on the amount of redundancy and network conditions,
there could be cases where it becomes impossible to carry traffic. This is furt
her discussed in <xref target="sec:fec-above"/> where "FEC above CC" case is ass
essed and in <xref target="sec:fec-in"/> and in <xref target="sec:fec-below"/> w
here "FEC in CC" and "FEC below CC" are assessed.</t>
</section>
<section title="Scope of the document concerning transport multipath and <t>The transport layer may provide an unreliable transport service (e.g.
multi-streams applications"> , UDP or the Datagram Congestion Control Protocol (DCCP) <xref target="RFC4340"
<t>The application layer can be composed of several streams above format="default"/>) or a partially reliable transport service (e.g., the Stream
FEC and transport layers instances. The transport layer can exploit a multipath Control Transmission Protocol (SCTP) with the partial reliability extension <xre
mechanism. The different streams could exploit different paths between the send f target="RFC3758" format="default"/> or QUIC with the unreliable datagram exten
er and the receiver. Moreover, a single-stream application could also exploit a sion <xref target="RFC9221" format="default"/>). Depending on the amount of redu
multipath transport mechanism. This section describes what is in the scope of th ndancy and network conditions, there could be cases where it becomes impossible
is document in regards with multi-streams applications and multipath transport p to carry traffic. This is further discussed in <xref target="sec_fec-above" form
rotocols.</t> at="default"/> where a "FEC above CC" case is assessed and in Sections <xref tar
<t>The different combinations between multi-stream applications a get="sec_fec-in" format="counter"/> and <xref target="sec_fec-below" format="cou
nd multipath transport are the following: (1) one application layer stream as in nter"/> where "FEC in CC" and "FEC below CC" are assessed, respectively.</t>
put packets above a combination of FEC and multipath (Mpath) transport layers (< </section>
xref target="fig:multi-scope-single-stream"></xref>), and (2) multiple applicati
on layer streams as input packets above a combination of FEC and multipath (Mpat
h) or single path (Spath) transport layers (<xref target="fig:multi-scope-multi-
stream"></xref>). This document further details cases I (in <xref target="subsec
:multipath_above"></xref>), II (in <xref target="subsec:multipath_in"></xref>) a
nd III (in <xref target="subsec:multipath_below"></xref>) illustrated in <xref t
arget="fig:multi-scope-single-stream"></xref>. Cases IV, V and VI of <xref targe
t="fig:multi-scope-multi-stream"></xref> are related to how multiple streams are
managed by a single transport or FEC layer: this does not directly concerns the
interaction between FEC and the transport and is out of the scope of this docum
ent.</t>
<figure anchor="fig:multi-scope-single-stream" title="Transport multipath <section numbered="true" toc="default">
and single stream applications - in the scope of the document"> <name>Scope of the Document Concerning Transport Multipath and Multistre
<artwork> am Applications</name>
<t>The application layer can be composed of several streams above FEC an
d transport-layer instances. The transport layer can exploit a multipath mechani
sm. The different streams could exploit different paths between the sender and t
he receiver. Moreover, a single-stream application could also exploit a multipat
h transport mechanism. This section describes what is in the scope of this docum
ent with regard to multistream applications and multipath transport protocols.</
t>
<t>The different combinations between multistream applications and multi
path transport are the following: (1) one application-layer stream as input pack
ets above a combination of FEC and multipath (Mpath) transport layers (<xref tar
get="fig_multi-scope-single-stream" format="default"/>) and (2) multiple applica
tion-layer streams as input packets above a combination of FEC and multipath (Mp
ath) or single path (Spath) transport layers (<xref target="fig_multi-scope-mult
i-stream" format="default"/>). This document further details cases I (in <xref t
arget="subsec_multipath_above" format="default"/>), II (in <xref target="subsec_
multipath_in" format="default"/>), and III (in <xref target="subsec_multipath_be
low" format="default"/>) as illustrated in <xref target="fig_multi-scope-single-
stream" format="default"/>. Cases IV, V, and VI of <xref target="fig_multi-scope
-multi-stream" format="default"/> are related to how multiple streams are manage
d by a single transport or FEC layer; this does not directly concern the interac
tion between FEC and the transport and is out of the scope of this document.</t>
<figure anchor="fig_multi-scope-single-stream">
<name>Transport Multipath and Single-Stream Applications - in the Scop
e of the Document</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
CASE I CASE II CASE III CASE I CASE II CASE III
+---------------+ +---------------+ +---------------+ +---------------+ +---------------+ +---------------+
| Stream 1 | | Stream 2 | | Stream 3 | | Stream 1 | | Stream 2 | | Stream 3 |
+---------------+ +---------------+ +---------------+ +---------------+ +---------------+ +---------------+
+---------------+ +---------------+ +---------------+ +---------------+ +---------------+ +---------------+
| FEC | | FEC | |Mpath Transport| | FEC | | FEC | |Mpath Transport|
+---------------+ | in | +---------------+ +---------------+ | in | +---------------+
|Mpath Transport| |Mpath Transport|
+---------------+ | | +-----+ +-----+ +---------------+ | | +-----+ +-----+
|Mpath Transport| | | |Flow1|...|FlowM| |Mpath Transport| | | |Flow1|...|FlowM|
+---------------+ +---------------+ +-----+ +-----+ +---------------+ +---------------+ +-----+ +-----+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|Flow1|...|FlowM| |Flow1|...|FlowM| | FEC |...| FEC | |Flow1|...|FlowM| |Flow1|...|FlowM| | FEC |...| FEC |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
</artwork> ]]></artwork>
</figure> </figure>
<figure anchor="fig_multi-scope-multi-stream">
<figure anchor="fig:multi-scope-multi-stream" title="Transport single pat <name>Transport Single Path, Transport Multipath, and Multistream Appl
h, transport multipath and multi-stream applications - out of the scope of the d ications - out of the Scope of the Document</name>
ocument"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
CASE IV CASE V CASE VI CASE IV CASE V CASE VI
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|Stream1|...|StreamM| |Stream1|...|StreamM| |Stream1|...|StreamM| |Stream1|...|StreamM| |Stream1|...|StreamM| |Stream1|...|StreamM|
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+
| | | FEC | | Mpath Transport | | | | FEC | | Mpath Transport |
| FEC | +-------------------+ +-------------------+ | FEC | +-------------------+ +-------------------+
| above/in/below | | above/in/below |
| Spath Transport | +-------------------+ +-------------------+ | Spath Transport | +-------------------+ +-------------------+
| | | Mpath Transport | | FEC | | | | Mpath Transport | | FEC |
+-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+
+-------------------+ +-----+ +-----+ +-----+ +-----+ +-------------------+ +-----+ +-----+ +-----+ +-----+
| Flow | |Flow1| ... |FlowM| |Flow1| ... |FlowM| | Flow | |Flow1| ... |FlowM| |Flow1| ... |FlowM|
+-------------------+ +-----+ +-----+ +-----+ +-----+ +-------------------+ +-----+ +-----+ +-----+ +-----+
</artwork> ]]></artwork>
</figure> </figure>
</section>
<section anchor="subsec_def_code" numbered="true" toc="default">
<name>Types of Coding</name>
<t><xref target="RFC8406" format="default"/> summarizes recommended term
inology for Network Coding concepts and constructs. In particular, the document
identifies the following coding types (among many others): </t>
</section> <dl>
<section anchor="subsec:def_code" title="Types of coding"> <dt>Block Coding:
</dt>
<dd>Coding technique where the input Flow must first be segmented
into a sequence of blocks; FEC encoding and decoding are performed
independently on a per-block basis.
</dd>
<t><xref target="RFC8406"></xref> summarizes recommended terminology for <dt>Sliding Window Coding:
Network Coding concepts and constructs. In particular, the document identifies t </dt>
he following coding types (among many others): <list style="symbols"> <dd>General class of coding techniques that rely on a sliding
<t>Block Coding: Coding technique where the input Flow mu encoding window.
st first be segmented into a sequence of blocks; FEC encoding and decoding are p </dd>
erformed independently on a per-block basis.</t> </dl>
<t>Sliding Window Coding: general class of coding techniq
ues that rely on a sliding encoding window.</t>
</list></t>
<t>The decoding scheme may not be able to decode all the symbols. The cha <t>The decoding scheme may not be able to decode all the symbols. The chance of
nce of decoding the erased packets depends on the size of the encoding window, t decoding the erased packets depends on the size of the encoding window, the codi
he coding rate and the distribution of erasure in the transmission channel. The ng rate, and the distribution of erasure in the transmission channel. The FEC ch
FEC channel may let the client transmit information related to the need of suppl annel may let the client transmit information related to the need of supplementa
ementary symbols to adapt the level of reliability. Partial and full reliability ry symbols to adapt the level of reliability. Partial and full reliability could
could be envisioned.<list style="symbols"> be envisioned.</t>
<t>Full reliability: The receiver may hold symbols until
the decoding of source symbols is possible. In particular, if the codec does not
enable a subset of the system to be inverted, the receiver would have to wait f
or a certain minimum amount of repair packets before it can recover all the sour
ce symbols.</t>
<t>Partial reliability: The receiver cannot deliver sourc
e symbols that could not have been decoded to the upper layer. For a fixed size
of encoding window (for Sliding Window Coding) or of blocks (for Block Coding) c
ontaining the source symbols, increasing the amount of repair symbols would incr
ease the chances of recovering the erased symbols. However, this would impact on
memory requirements, on the cost of encoding and decoding processes and on the
network overhead.</t>
</list></t>
</section>
</section> <dl>
<dt>Full reliability:
</dt>
<dd>The receiver may hold symbols until the decoding of source symbols is
possible. In particular, if the codec does not enable a subset of the system
to be inverted, the receiver would have to wait for a certain minimum amount
of repair packets before it can recover all the source symbols.
</dd>
<!-- ######################################################--> <dt>Partial reliability:
<!-- New section --> </dt>
<!-- ######################################################--> <dd>The receiver cannot deliver source symbols that could not have been
<!-- decoded to the upper layer. For a fixed size of encoding window (for Sliding
<section anchor="sec:scope" title="Scope"> Window Coding) or of blocks (for Block Coding) containing the source
<t>This section describes the scope of the document.</t> symbols, increasing the amount of repair symbols would increase the chances
<section anchor="sec:scope:appli" title="Type of application"> of recovering the erased symbols. However, this would have an impact on memory
<t>The document focuses on reliable data transfers.</t> requirements, the cost of encoding and decoding processes, and the
</section> network overhead.
<section anchor="sec:scope:e2e" title="End-to-end"> </dd>
<t>The document focuses on end-to-end coding, i.e. cases where codin </dl>
g is added at the server and client end points. The discussions should then cons
ider fairness with non-coding solutions.</t> </section>
</section>
</section> </section>
-->
<!-- ######################################################-->
<!-- New section -->
<!-- ######################################################-->
<!-- <section anchor="sec:fec-cc" title="FEC and CC layering">
<t>This section discusses how FEC and CC can relate in different cases (F
EC above the transport, FEC within the transport, FEC below the transport).</t>
-->
<!-- ######################################################--> <section anchor="sec_fec-above" numbered="true" toc="default">
<!-- New section --> <name>FEC above the Transport</name>
<!-- ######################################################--> <figure anchor="fig_fec-above">
<section anchor="sec:fec-above" title="FEC above the transport"> <name>FEC above the Transport</name>
<figure anchor="fig:fec-above" title="FEC above the transport"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
| source ^ source | source ^ source
| packets | packets | packets | packets
v | v |
+-------------+ +-------------+ +-------------+ +-------------+
|FEC | signaling|FEC | |FEC | signaling|FEC |
| | recovered| | | | recovered| |
| | symbols| | | | symbols| |
| | <![CDATA[<]]>==| | | | <==| |
+-------------+ +-------------+ +-------------+ +-------------+
| source ^ ^ source | source ^ ^ source
| and/or | sending | and/or | and/or | sending | and/or
| repair | rate | repair | repair | rate | repair
| symbols | (or window) | symbols | symbols | (or window) | symbols
v | | v | |
+-------------+ +-------------+ +-------------+ +-------------+
|Transport | network|Transport | |Transport | network|Transport |
|(incl. CC) | information| | |(incl. CC) | information| |
| |network <![CDATA[<]]>==| | | |network <==| |
| |packets | | | |packets | |
+-------------+==> +-------------+ +-------------+==> +-------------+
SENDER RECEIVER SENDER RECEIVER
</artwork> ]]></artwork>
</figure> </figure>
<t><xref target="fig_fec-above" format="default"/> presents an architectur
<t><xref target="fig:fec-above"></xref> presents an architecture e where FEC operates on top of the transport.</t>
where FEC operates on top of the transport.</t> <t>The advantage of this approach is that the FEC overhead does not contri
bute to congestion in the network when congestion control is implemented at the
<t>The advantage of this approach is that the FEC overhead does n transport layer, because the repair symbols are sent following the congestion wi
ot contribute to congestion in the network when congestion control is implemente ndow or rate determined by the CC mechanism. This can result in an improved qual
d at the transport layer, because the repair symbols are sent following the cong ity of experience for latency-sensitive applications such as Voice over IP (VoIP
estion window or rate determined by the CC mechanism. This can result in improve ) or any not-fully reliable services.</t>
d quality of experience for latency sensitive applications such as Voice over IP <t>This approach requires that the transport protocol does not implement a
(VoIP) or any not-fully reliable services.</t> fully reliable in-order data transfer service (e.g., like TCP). QUIC with the u
<t>This approach requires that the transport protocol does not im nreliable datagram extension <xref target="RFC9221" format="default"/> is an exa
plement a fully reliable in-order data transfer service (e.g., like TCP). QUIC w mple of a protocol for which this is relevant. In cases where the partially reli
ith unreliable datagram extension <xref target="I-D.ietf-quic-datagram"/> is an able transport is blocked and a fallback to a reliable transport is proposed, th
example of a protocol for which this is relevant. In cases where the partially r ere is a risk for bad interactions between reliability at the transport level an
eliable transport is blocked and a fall-back to a reliable transport is proposed d coding schemes. For reliable transfers, coding usage does not guarantee better
, there is a risk for bad interactions between reliability at the transport leve performance; instead, it would mainly reduce goodput.</t>
l and coding schemes. For reliable transfers, coding usage does not guarantee be <section anchor="subsec_fairness_above" numbered="true" toc="default">
tter performance; instead, it would mainly reduce goodput.</t> <name>Fairness and Impact on Non-coded Flows</name>
<t>The addition of coding within the flow does not influence the interac
<section anchor="subsec:fairness_above" title="Fairness and impac tion between coded and non-coded flows. This interaction would mainly depend on
t on non-coded flows"> the congestion controls associated with each flow.</t>
<t>The addition of coding within the flow does no </section>
t influence the interaction between coded and non-coded flows. This interaction <section anchor="subsec_cc-recov-interaction_above" numbered="true" toc="d
would mainly depend on the congestion controls associated with each flow.</t> efault">
</section> <name>Congestion Control and Recovered Symbols</name>
<t>The congestion control mechanism receives network packets and may not
<section anchor="subsec:cc-recov-interaction_above" title="Conges be able to differentiate repair symbols from actual source ones.
tion control and recovered symbols"> This differentiation requires a transport protocol to provide more than t
<t>The congestion control mechanism receives network pack he services described in <xref target="RFC8095" format="default"/>, such as spec
ets and may not be able to differentiate repair symbols from actual source ones. ifically indicating what information has been repaired. The relevance of adding
This differentiation requires a transport protocol providing more than the serv coding at the application layer is related to the needs of the application. For
ices described in <xref target="RFC8095"/>, in particular specifically indicatin real-time applications using an unreliable or partially reliable transport, this
g what information has been repaired. The relevance of adding coding at the appl approach may reduce the number of losses perceived by the application.</t>
ication layer is related to the needs of the application. For real-time applicat </section>
ions using an unreliable or partially reliable transport, this approach may redu <section anchor="subsec_cc-nc-interaction_above" numbered="true" toc="defa
ce the number of losses perceived by the application.</t> ult">
</section> <name>Interactions between Congestion Control and Coding Rates</name>
<t>The coding rate applied at the application layer mainly depends on th
<section anchor="subsec:cc-nc-interaction_above" title="Interacti e available rate or congestion window given by the congestion control underneath
ons between congestion control and coding rates"> . The coding rate could be adapted to avoid adding overhead when the minimum req
<t>The coding rate applied at the application lay uired data rate of the application is not provided by the congestion control und
er mainly depends on the available rate or congestion window given by the conges erneath. When the congestion control allows sending faster than the application
tion control underneath. The coding rate could be adapted to avoid adding overhe needs, adding coding can reduce packet losses and improve the quality of experie
ad when the minimum required data rate of the application is not provided by the nce (provided that an unreliable or partially reliable transport is used).</t>
congestion control underneath. When the congestion control allows sending faste </section>
r than the application needs, adding coding can reduce packet losses and improve <section anchor="subsec_cc-useless-interaction_above" numbered="true" toc=
the quality of experience (provided that an unreliable or partially reliable tr "default">
ansport is used).</t> <name>On Useless Repair Symbols</name>
</section> <t>The only case where adding useless repair symbols does not obviously
result in reduced goodput is when the application rate is limited (e.g., VoIP tr
<section anchor="subsec:cc-useless-interaction_above" title="On u affic). In this case, useless repair symbols would only impact the amount of dat
seless repair symbols"> a generated in the network. Extra data in the network can, however, increase the
<t>The only case where adding useless repair symb likelihood of increasing delay and/or packet loss, which could provoke a conges
ols does not obviously result in reduced goodput is when the application rate is tion control reaction that would degrade goodput.</t>
limited (e.g., VoIP traffic). In this case, useless repair symbols would only i </section>
mpact the amount of data generated in the network. Extra data in the network can <section anchor="subsec_partial_order_above" numbered="true" toc="default"
, however, increase the likelihood of increasing delay and/or packet loss, which >
could provoke a congestion control reaction that would degrade goodput.</t> <name>On Partial Ordering at FEC Level</name>
</section> <t>Irrespective of the transport protocol, a FEC mechanism does not requ
ire implementing a reordering mechanism if the application does not need it. How
<section anchor="subsec:partial_order_above" title="On partial or ever, if the application needs in-order delivery of packets, a reordering mechan
dering at FEC level"> ism at the receiver is required.</t>
<t>Irrespective of the transport protocol, a FEC </section>
mechanism does not require to implement a reordering mechanism if the applicatio <section anchor="subsec_partial_rel_above" numbered="true" toc="default">
n does not need it. However, if the application needs in-order delivery of packe <name>On Partial Reliability at FEC Level</name>
ts, a reordering mechanism at the receiver is required.</t> <t>The application may require partial reliability. In this case, the co
</section> ding rate of a FEC mechanism could be adapted based on inputs from the applicati
on and the trade-off between latency and packet loss. Partial reliability impact
<section anchor="subsec:partial_rel_above" title="On partial reli s the type of FEC and type of codec that can be used, such as discussed in <xref
ability at FEC level"> target="subsec_def_code" format="default"/>. </t>
<t>The application may require partial reliability. In th </section>
is case, the coding rate of a FEC mechanism could be adapted based on inputs fro <section anchor="subsec_multipath_above" numbered="true" toc="default">
m the application and the trade-off between latency and packet loss. Partial rel <name>On Multipath Transport and FEC Mechanism</name>
iability impacts the type of FEC and type of codec that can be used, such as dis <t>Whether the transport protocol exploits multiple paths or not does no
cussed in <xref target="subsec:def_code"></xref>. </t> t have an impact on the FEC mechanism.</t>
</section> </section>
</section>
<section anchor="subsec:multipath_above" title="On multipath tran
sport and FEC mechanism">
<t>Whether the transport protocol exploits multip
le paths or not does not have an impact on the FEC mechanism.</t>
</section>
</section>
<!-- ######################################################--> <section anchor="sec_fec-in" numbered="true" toc="default">
<!-- New subsection --> <name>FEC within the Transport</name>
<!-- ######################################################--> <figure anchor="fig_fec-in">
<section anchor="sec:fec-in" title="FEC within the transport"> <name>FEC in the Transport</name>
<figure anchor="fig:fec-in" title="FEC in the transport"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
| source ^ source | source ^ source
| packets | packets | packets | packets
v | v |
+------------+ +------------+ +------------+ +------------+
| Transport | | Transport | | Transport | | Transport |
| | | | | | | |
| +---+ +--+ | signaling| +---+ +--+ | | +---+ +--+ | signaling| +---+ +--+ |
| |FEC| |CC| | recovered| |FEC| |CC| | | |FEC| |CC| | recovered| |FEC| |CC| |
| +---+ +--+ | symbols| +---+ +--+ | | +---+ +--+ | symbols| +---+ +--+ |
| | <![CDATA[<]]>==| | | | <==| |
| |network network| | | |network network| |
| |packets information| | | |packets information| |
+------------+ ==> <![CDATA[<]]>==+------------+ +------------+ ==> <==+------------+
SENDER RECEIVER SENDER RECEIVER
</artwork> ]]></artwork>
</figure> </figure>
<t><xref target="fig_fec-in" format="default"/> presents an architecture w
<t><xref target="fig:fec-in"></xref> presents an architecture whe here FEC operates within the transport. The repair symbols are sent within what
re FEC operates within the transport. The repair symbols are sent within what th the congestion window or calculated rate allows, such as in <xref target="CTCP"
e congestion window or calculated rate allows, such as in <xref target="CTCP"/>. format="default"/>.</t>
</t> <t>The advantage of this approach is that it allows a joint optimization o
f CC and FEC. Moreover, the transmission of repair symbols does not add congesti
<t>The advantage of this approach is that it allows a joint optim on in potentially congested networks but helps repair lost packets (such as tail
ization of CC and FEC. Moreover, the transmission of repair symbols does not add losses). This joint optimization is the key to prevent flows to consume the who
congestion in potentially congested networks but helps repair lost packets (suc le available capacity. The amount of repair traffic injected should not lead to
h as tail losses). This joint optimization is the key to prevent flows to consum congestion. As denoted in <xref target="I-D.singh-rmcat-adaptive-fec" format="de
e the whole available capacity. The amount of repair traffic injected should not fault"/>, an increase of the repair ratio should be done conjointly with a decre
lead to congestion. As denoted in <xref target="I-D.singh-rmcat-adaptive-fec" / ase of the source sending rate.</t>
>, an increase of the repair ratio should be done conjointly with a decrease of <t>The drawback of this approach is that it may require specific signaling
the source sending rate.</t> and transport services that may not be described in <xref target="RFC8095" form
at="default"/>. Therefore, development and maintenance may require specific effo
<t>The drawback of this approach is that it may require specific rts at both the transport and the coding levels, and the design of the solution
signaling and transport services that may not be described in <xref target="RFC8 may end up being complex to suit different deployment needs.</t>
095"/>. Therefore, development and maintenance may require specific efforts at b
oth transport and coding level and the design of the solution may end up being c
omplex to suit different deployment needs.</t>
<t>For reliable transfers, including redundancy reduces goodput f
or long transfers but the amount of repair symbols can be adapted, e.g. dependin
g on the congestion window size. There is a trade-off between 1) the capacity th
at could have been exploited by application data instead of transmitting source
packets, and 2) the benefits derived from transmitting repair symbols (e.g. unlo
cking the receive buffer if it is limiting). The coding ratio needs to be carefu
lly designed. For small files, sending repair symbols when there is no more data
to transmit could help to reduce the transfer time. Sending repair symbols can
avoid the silence period between the transmission of the last packet in the send
buffer and 1) firing a retransmission of lost packets, or 2) the transmission o
f new packets.</t>
<t>Examples of the solution could be to add a given percentage of
the congestion window or rate as supplementary symbols, or to send a fixed amou
nt of repair symbols at a fixed rate. The redundancy flow can be decorrelated fr
om the congestion control that manages source packets: a separate congestion con
trol entity could be introduced to manage the amount of recovered symbols to tra
nsmit on the FEC channel. The separate congestion control instances could be mad
e to work together while adhering to priorities, as in coupled congestion contro
l for RTP media <xref target="RFC8699"/> in case all traffic can be assumed to t
ake the same path, or otherwise with a multipath congestion window coupling mech
anism as in Multipath TCP <xref target="RFC6356"/>. Another possibility would be
to exploit a lower than best-effort congestion control <xref target="RFC6297"/>
for repair symbols.</t>
<section anchor="subsec:fairness_in" title="Fairness and impact o
n non-coded flows">
<t>Specific interaction between congestion contro
ls and coding schemes can be proposed (see <xref target="subsec:cc-nc-interactio
n_in"></xref> and <xref target="subsec:cc-useless-interaction_in"></xref>). If n
o specific interaction is introduced, the coding scheme may hide congestion loss
es from the congestion controller and the description of <xref target="sec:fec-b
elow"></xref> may apply.</t>
</section>
<section anchor="subsec:cc-nc-interaction_in" title="Interactions
between congestion control and coding rates">
<t>The receiver can differentiate between source
packets and repair symbols. The receiver may indicate both the number of source
packets received and repair symbols that were actually useful in the recovery pr
ocess of packets. The congestion control at the sender can then exploit this inf
ormation to tune congestion control behavior.</t>
<t>There is an important flexibility in the trade
-off, inherent to the use of coding, between (1) reducing goodput when useless r
epair symbols are transmitted and (2) helping to recover from losses earlier tha
n with retransmissions. The receiver may indicate to the sender the number of pa
ckets that have been received or recovered. The sender may use this information
to tune the coding ratio. For example, coupling an increased transmission rate w
ith an increasing or decreasing coding rate could be envisioned. A server may us
e a decreasing coding rate as a probe of the channel capacity and adapt the cong
estion control transmission rate.</t>
</section>
<section anchor="subsec:cc-useless-interaction_in" title="On usel
ess repair symbols">
<t>The sender may exploit the information given b
y the receiver to reduce the number of useless repair symbols, and improve goodp
ut.</t>
</section>
<section anchor="subsec:partial_order_in" title="On partial order <t>For reliable transfers, including redundancy reduces goodput for long t
ing at FEC and/or transport level"> ransfers, but the amount of repair symbols can be adapted, e.g., depending on th
<t>The application may require in-order delivery of packe e congestion window size. There is a trade-off between 1) the capacity that coul
ts. In this case, both FEC and transport layer mechanisms should guarantee that d have been exploited by application data instead of transmitting source packets
packets are delivered in order. If partial ordering is requested by the applicat and 2) the benefits derived from transmitting repair symbols (e.g., unlocking t
ion, both the FEC and transport could relax the constraints related to in-order he receive buffer if it is limiting). The coding ratio needs to be carefully des
delivery: partial ordering impacts both the congestion control and the type of F igned. For small files, sending repair symbols when there is no more data to tra
EC and type of codec that can be used, mostly at the receiver that may need to i nsmit could help to reduce the transfer time. Sending repair symbols can avoid t
mplement partial reordering.</t> he silence period between the transmission of the last packet in the send buffer
</section> and 1) firing a retransmission of lost packets or 2) the transmission of new pa
ckets.</t>
<t>Examples of the solution could be to add a given percentage of the cong
estion window or rate as supplementary symbols or to send a fixed amount of repa
ir symbols at a fixed rate. The redundancy flow can be decorrelated from the con
gestion control that manages source packets; a separate congestion control entit
y could be introduced to manage the amount of recovered symbols to transmit on t
he FEC channel. The separate congestion control instances could be made to work
together while adhering to priorities, as in coupled congestion control for RTP
media <xref target="RFC8699" format="default"/> in case all traffic can be assum
ed to take the same path, or otherwise with a multipath congestion window coupli
ng mechanism as in Multipath TCP <xref target="RFC6356" format="default"/>. Anot
her possibility would be to exploit a lower-than-best-effort congestion control
<xref target="RFC6297" format="default"/> for repair symbols.</t>
<section anchor="subsec_fairness_in" numbered="true" toc="default">
<name>Fairness and Impact on Non-coded Flows</name>
<section anchor="subsec:partial_rel_in" title="On partial reliabi <t>Specific interaction between congestion controls and coding schemes c
lity at FEC level"> an be proposed (see Sections <xref target="subsec_cc-nc-interaction_in" format="
<t>The application may require partial reliabilit counter"/> and <xref target="subsec_cc-useless-interaction_in" format="counter"/
y. The reliability offered by FEC may be sufficient, with no retransmission requ >). If no specific interaction is introduced, the coding scheme may hide congest
ired. This depends on application needs and the trade-off between latency and lo ion losses from the congestion controller, and the description of <xref target="
ss. Partial reliability impacts the type of FEC and type of codec that can be us sec_fec-below" format="default"/> may apply.</t>
ed, such as discussed in <xref target="subsec:def_code"></xref>.</t> </section>
</section> <section anchor="subsec_cc-nc-interaction_in" numbered="true" toc="default
">
<name>Interactions between Congestion Control and Coding Rates</name>
<section anchor="subsec:multipath_in" title="On transport multipa <t>The receiver can differentiate between source packets and repair symb
th and subpath FEC coding rate"> ols. The receiver may indicate both the number of source packets received and th
<t>The sender may adapt the coding rate of each o e repair symbols that were actually useful in the recovery process of packets. T
f the single subpaths, whether the congestion control is coupled or not. There i he congestion control at the sender can then exploit this information to tune co
s an important flexibility on how the coding rate is tuned depending on the char ngestion control behavior.</t>
acteristics of each subpath.</t> <t>There is an important flexibility in the trade-off, inherent to the u
</section> se of coding, between (1) reducing goodput when useless repair symbols are trans
mitted and (2) helping to recover from losses earlier than with retransmissions.
The receiver may indicate to the sender the number of packets that have been re
ceived or recovered. The sender may use this information to tune the coding rati
o. For example, coupling an increased transmission rate with an increasing or de
creasing coding rate could be envisioned. A server may use a decreasing coding r
ate as a probe of the channel capacity and adapt the congestion control transmis
sion rate.</t>
</section>
<section anchor="subsec_cc-useless-interaction_in" numbered="true" toc="de
fault">
<name>On Useless Repair Symbols</name>
<t>The sender may exploit the information given by the receiver to reduc
e the number of useless repair symbols and improve goodput.</t>
</section>
<section anchor="subsec_partial_order_in" numbered="true" toc="default">
<name>On Partial Ordering at FEC and/or Transport Level</name>
<t>The application may require in-order delivery of packets. In this cas
e, both FEC and transport-layer mechanisms should guarantee that packets are del
ivered in order.
</section> If partial ordering is requested by the application, both the FEC and
transport could relax the constraints related to in-order delivery; partial
ordering impacts both the congestion control and the type of FEC and type of
codec that can be used.
</t>
</section>
<section anchor="subsec_partial_rel_in" numbered="true" toc="default">
<name>On Partial Reliability at FEC Level</name>
<t>The application may require partial reliability. The reliability offe
red by FEC may be sufficient with no retransmission required. This depends on ap
plication needs and the trade-off between latency and loss. Partial reliability
impacts the type of FEC and type of codec that can be used, such as discussed in
<xref target="subsec_def_code" format="default"/>.</t>
</section>
<section anchor="subsec_multipath_in" numbered="true" toc="default">
<name>On Transport Multipath and Subpath FEC Coding Rate</name>
<t>The sender may adapt the coding rate of each of the single subpaths w
hether the congestion control is coupled or not. There is an important flexibili
ty on how the coding rate is tuned depending on the characteristics of each subp
ath.</t>
</section>
</section>
<!-- ######################################################--> <section anchor="sec_fec-below" numbered="true" toc="default">
<!-- New subsection --> <name>FEC below the Transport</name>
<!-- ######################################################--> <figure anchor="fig_fec-below">
<section anchor="sec:fec-below" title="FEC below the transport"> <name>FEC below the Transport</name>
<figure anchor="fig:fec-below" title="FEC below the transport"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
| source ^ source | source ^ source
| packets | packets | packets | packets
v | v |
+--------------+ +--------------+ +--------------+ +--------------+
|Transport | network|Transport | |Transport | network|Transport |
|(including CC)| information| | |(including CC)| information| |
| | <![CDATA[<]]>==| | | | <==| |
+--------------+ +--------------+ +--------------+ +--------------+
| network packets ^ network packets | network packets ^ network packets
v | v |
+--------------+ +--------------+ +--------------+ +--------------+
| FEC |source | FEC | | FEC |source | FEC |
| |and/or signaling| | | |and/or signaling| |
| |repair recovered| | | |repair recovered| |
| |symbols symbols| | | |symbols symbols| |
| |==> <![CDATA[<]]>==| | | |==> <==| |
+--------------+ +--------------+ +--------------+ +--------------+
SENDER RECEIVER SENDER RECEIVER
</artwork> ]]></artwork>
</figure> </figure>
<t><xref target="fig_fec-below" format="default"/> presents an architectur
e where FEC is applied end to end below the transport layer but above the link l
ayer. Note that it is common to apply FEC at the link layer on one or more of t
he links that make up the end-to-end path. The application of FEC at the link la
yer contributes to the total capacity that a link exposes to upper layers, but i
t may not be visible to either the end-to-end sender or the receiver, if the end
-to-end sender and receiver are separated by more than one link; this is therefo
re out of scope for this document. This includes the use of FEC on top of a link
layer in scenarios where the link is known by configuration. In the scenario co
nsidered here, the repair symbols are not visible to the end-to-end congestion c
ontroller and may be sent on top of what is allowed by the congestion control.</
t>
<t>Including redundancy adds traffic without reducing goodput but incurs p
otential fairness issues. The effective bit rate is higher than the CC's compute
d fair share due to the transmission of repair symbols, and losses are hidden fr
om the transport. This may cause a problem for loss-based congestion detection,
but it is not a problem for delay-based congestion detection.</t>
<t>The advantage of this approach is that it can result in performance gai
ns when there are persistent transmission losses along the path.</t>
<t>The drawback of this approach is that it can induce congestion in alrea
dy congested networks. The coding ratio needs to be carefully designed.</t>
<t>Examples of the solution could be to add a given percentage of the cong
estion window or rate as supplementary symbols or to send a fixed amount of repa
ir symbols at a fixed rate. The redundancy flow can be decorrelated from the con
gestion control that manages source packets; a separate congestion control entit
y could be introduced to manage the amount of recovered symbols to transmit on t
he FEC channel.
<t><xref target="fig:fec-below"/> presents an architecture where The separate congestion control instances could be made to work together w
FEC is applied end-to-end below the transport layer, but above the link layer. hile adhering to priorities, as in coupled congestion control for RTP media <xre
Note that it is common to apply FEC at the link layer on one or more of the link f target="RFC8699" format="default"/> in case all traffic can be assumed to take
s that make up the end-to-end path. The application of FEC at the link layer con the same path, or otherwise with a multipath congestion window coupling mechani
tributes to the total capacity that a link exposes to upper layers, but may not sm as in Multipath TCP <xref target="RFC6356" format="default"/>. Another possib
be visible to either the end-to-end sender or receiver, if the end-to-end sender ility would be to exploit a lower-than-best-effort congestion control <xref targ
and receiver are separated by more than one link, and therefore is out of scope et="RFC6297" format="default"/> for repair symbols.</t>
for this document. This includes the use of FEC on top of a link layer in scena <section anchor="subsec_fairness_below" numbered="true" toc="default">
rios where the link is known by configuration. In the scenario considered here, <name>Fairness and Impact on Non-coded Flows</name>
the repair symbols are not visible to the end-to-end congestion controller and m <t>The coding scheme may hide congestion losses from the congestion cont
ay be sent on top of what is allowed by the congestion control.</t> roller. There are cases where this can drastically reduce the goodput of non-cod
<t>Including redundancy adds traffic without reducing goodput but ed flows. Depending on the congestion control, it may be possible to signal to t
incurs potential fairness issues. The effective bit-rate is higher than the CC' he congestion control mechanism that there was congestion (loss) even when a pac
s computed fair share due to the transmission of repair symbols, and losses are ket has been recovered, e.g., using ECN, to reduce the impact on the non-coded f
hidden from the transport. This may cause a problem for loss-based congestion de lows (see <xref target="subsec_cc-recov-interaction_below" format="default"/> an
tection, but it is not a problem for delay-based congestion detection.</t> d <xref target="TENTET" format="default"/>).</t>
<t>The advantage of this approach is that it can result in perfor </section>
mance gains when there are persistent transmission losses along the path.</t> <section anchor="subsec_cc-recov-interaction_below" numbered="true" toc="d
<t>The drawback of this approach is that it can induce congestion efault">
in already congested networks. The coding ratio needs to be carefully designed. <name>Congestion Control and Recovered Symbols</name>
</t> <t>The congestion control may not be aware of the existence of a coding
<t>Examples of the solution could be to add a given percentage of scheme underneath it. The congestion control may behave as if no coding scheme h
the congestion window or rate as supplementary symbols, or to send a fixed amou ad been introduced. The only way for a coding channel to indicate that symbols h
nt of repair symbols at a fixed rate. The redundancy flow can be decorrelated fr ave been lost but recovered is to exploit existing signaling that is understood
om the congestion control that manages source packets: a separate congestion con by the congestion control mechanism. An example would be to indicate to a TCP se
trol entity could be introduced to manage the amount of recovered symbols to tra nder that a packet has been received, yet congestion has occurred, by using ECN
nsmit on the FEC channel. The separate congestion control instances could be mad signaling <xref target="TENTET" format="default"/>.</t>
e to work together while adhering to priorities, as in coupled congestion contro </section>
l for RTP media <xref target="RFC8699"/> in case all traffic can be assumed to t <section anchor="subsec_cc-nc-interaction_below" numbered="true" toc="defa
ake the same path, or otherwise with a multipath congestion window coupling mech ult">
anism as in Multipath TCP <xref target="RFC6356"/>. Another possibility would be <name>Interactions between Congestion Control and Coding Rates</name>
to exploit a lower than best-effort congestion control <xref target="RFC6297"/> <t>The coding rate can be tuned depending on the number of recovered sym
for repair symbols.</t> bols and the rate at which the sender transmits data. If the coding scheme is no
t aware of the congestion control implementation, it is hard for the coding sche
me to apply the relevant coding rate.</t>
</section>
<section anchor="subsec_cc-useless-interaction_below" numbered="true" toc=
"default">
<name>On Useless Repair Symbols</name>
<t>Useless repair symbols only impact the load on the network without ac
tual gain for the coded flow. Using feedback signaling, FEC mechanisms can meas
ure the ratio between the number of symbols that were actually used and the numb
er of symbols that were useless, and adjust the coding rate.</t>
</section>
<section anchor="subsec_partial_order_below" numbered="true" toc="default"
>
<name>On Partial Ordering at FEC Level with In-Order Delivery Transport<
/name>
<t>The transport above the FEC channel may support out-of-order delivery
of packets; reordering mechanisms at the receiver may not be necessary. In case
s where the transport requires in-order delivery, the FEC channel may need to im
plement a reordering mechanism. Otherwise, spurious retransmissions may occur at
the transport level.</t>
</section>
<section anchor="subsec_partial_rel_below" numbered="true" toc="default">
<name>On Partial Reliability at FEC Level</name>
<t>The transport or application layer above the FEC channel may require
partial reliability only. FEC may provide an unnecessary service unless it is aw
are of the reliability requirements. Partial reliability impacts the type of FE
C and codec that can be used, such as discussed in <xref target="subsec_def_code
" format="default"/>.</t>
</section>
<section anchor="subsec_multipath_below" numbered="true" toc="default">
<name>FEC Not Aware of Transport Multipath</name>
<t>The transport may exploit multiple paths without the FEC channel bein
g aware of it. If FEC is aware that multiple paths are in use, FEC can be applie
d to all subflows as an aggregate, or to each of the subflows individually. If F
EC is not aware that multiple paths are in use, FEC can only be applied to each
subflow individually. When FEC is applied to all the flows as an aggregate, the
varying characteristics of the individual paths may lead to a risk for the codin
g rate to be inadequate for the characteristics of the individual paths.</t>
</section>
</section>
<section anchor="subsec:fairness_below" title="Fairness and impac <section anchor="sec_research" numbered="true" toc="default">
t on non-coded flows"> <name>Research Recommendations and Questions</name>
<t>The coding scheme may hide congestion losses f <t>This section provides a short state-of-the art overview of activities r
rom the congestion controller. There are cases where this can drastically reduce elated to congestion control and coding. The objective is to identify open resea
the goodput of non-coded flows. Depending on the congestion control, it may be rch questions and contribute to advice when evaluating coding mechanisms.</t>
possible to signal to the congestion control mechanism that there was congestion <section numbered="true" toc="default">
(loss) even when a packet has been recovered, e.g. using ECN, to reduce the imp <name>Activities Related to Congestion Control and Coding</name>
act on the non-coded flows (see <xref target="subsec:cc-recov-interaction_below" <t>We map activities related to congestion control and coding with the o
></xref> and <xref target="TENTET"></xref>).</t> rganization presented in this document:</t>
</section>
<section anchor="subsec:cc-recov-interaction_below" title="Conges <dl>
tion control and recovered symbols">
<t>The congestion control may not be aware of the
existence of a coding scheme underneath it. The congestion control may behave a
s if no coding scheme had been introduced. The only way for a coding channel to
indicate that symbols have been lost but recovered is to exploit existing signal
ing that is understood by the congestion control mechanism. An example would be
to indicate to a TCP sender that a packet has been received, yet congestion has
occurred, by using ECN signaling <xref target="TENTET"></xref>.</t>
</section>
<section anchor="subsec:cc-nc-interaction_below" title="Interacti <dt>For the FEC above transport case:
ons between congestion control and coding rates"> </dt>
<t>The coding rate can be tuned depending on the <dd><xref target="RFC8680" format="default"/>
number of recovered symbols and the rate at which the sender transmits data. If </dd>
the coding scheme is not aware of the congestion control implementation, it is h
ard for the coding scheme to apply the relevant coding rate.</t>
</section>
<section anchor="subsec:cc-useless-interaction_below" title="On u <dt>For the FEC within transport case:
seless repair symbols"> </dt>
<t>Useless repair symbols only impact the load on the net <dd> <xref target="I-D.swett-nwcrg-coding-for-quic"
work without actual gain for the coded flow. Using feedback signaling, FEC mech format="default"/>, <xref target="QUIC-FEC" format="default"/>,
anisms can measure the ratio between the number of symbols that were actually us and <xref target="RFC5109" format="default"/>
ed and the number of symbols that useless, and adjust the coding rate.</t> </dd>
</section>
<section anchor="subsec:partial_order_below" title="On partial or <dt>For the FEC below transport case:
dering at FEC level with in-order delivery transport"> </dt>
<t>The transport above the FEC channel may suppor <dd><xref target="NCTCP" format="default"/> and <xref
t out-of-order delivery of packets: reordering mechanisms at the receiver may no target="I-D.detchart-nwcrg-tetrys" format="default"/>
t be necessary. In cases where the transport requires in-order delivery, the FEC </dd>
channel may need to implement a reordering mechanism. Otherwise, spurious retra </dl>
nsmissions may occur at the transport level.</t>
</section>
<section anchor="subsec:partial_rel_below" title="On partial reli </section>
ability at FEC level"> <section numbered="true" toc="default">
<t>The transport or application layer above the F <name>Open Research Questions</name>
EC channel may require partial reliability only. FEC may provide an unnecessary <t>There is a general trade-off, inherent to the use of coding, between
service unless it is aware of the reliability requirements. Partial reliability (1) reducing goodput when useless repair symbols are transmitted and (2) helping
impacts the type of FEC and type of codec that can be used, such as discussed i to recover from transmission and congestion losses.</t>
n <xref target="subsec:def_code"/>.</t> <section numbered="true" toc="default">
</section> <name>Parameter Derivation</name>
<t>There is a trade-off related to the amount of redundancy to add as
a function of the transport-layer protocol and application requirements.</t>
<t><xref target="RFC8095" format="default"/> describes the mechanisms
provided by existing IETF protocols such as TCP, SCTP, or RTP. <xref target="RFC
8406" format="default"/> describes the variety of coding techniques. The number
of combinations makes the determination of an optimum parameters derivation very
complex. This depends on application requirements and deployment context.</t>
<t><xref target="RFC8681" sectionFormat="of" section="C" format="defa
ult"/> describes how to tune the parameters for a target use case. However, this
discussion does not integrate congestion-controlled end points.</t>
<section anchor="subsec:multipath_below" title="FEC not aware of <dl>
transport multipath"> <dt>Research question 1:
<t>The transport may exploit multiple paths without the F </dt>
EC channel being aware of it. If FEC is aware that multiple paths are in use, FE <dd>"Is there a way to dynamically adjust the codec characteristics
C can be applied to all subflows as an aggregate, or to each of the subflows ind depending on the transmission channel, the transport protocol, and application r
ividually. If FEC is not aware that multiple paths are in use, FEC can only be a equirements?"
pplied to each subflow individually. When FEC is applied to all the flows as an </dd>
aggregate, the varying characteristics of the individual paths may lead to a ris
k for the coding rate to be inadequate for the characteristics of the individual
paths.</t>
</section>
</section> <dt>Research question 2:
</dt>
<dd>"Should we apply specific per-stream FEC mechanisms when
multiple streams with different reliability needs are carried out?"
</dd>
</dl>
<!-- ######################################################--> </section>
<!-- New section -->
<!-- ######################################################-->
<section anchor="sec:research" title="Research recommendations and quest
ions">
<t>This section provides a short state-of-the art overview of act <section numbered="true" toc="default">
ivities related to congestion control and coding. The objective is to identify o <name>New Signaling Methods and Fairness</name>
pen research questions and contribute to advice when evaluating coding mechanism
s.</t>
<section title="Activities related to congestion control
and coding">
<t>We map activities related to congestion contro
l and coding with the organization presented in this document:<list style="symbo
ls">
<t>For the FEC above transport ca
se: <xref target="RFC8680"></xref>.</t>
<t>For the FEC within transport c
ase: <xref target="I-D.swett-nwcrg-coding-for-quic"></xref>, <xref target="QUIC-
FEC"></xref>, <xref target="RFC5109"></xref>.</t>
<t>For the FEC below transport ca
se: <xref target="NCTCP"></xref>, <xref target="I-D.detchart-nwcrg-tetrys"></xre
f>.</t>
</list></t>
</section>
<section title="Open research questions"> <t>Recovering lost symbols may hide congestion losses from the congesti
on control. Disambiguating ACKed packets from rebuilt packets would help the sen
der adapt its sending rate accordingly. There are opportunities for introducing
interaction between congestion control and coding schemes to improve the quality
of experience while guaranteeing fairness with other flows.</t>
<t>Some existing solutions already propose to disambiguate ACKed packe
ts from rebuilt packets <xref target="QUIC-FEC" format="default"/>. New signalin
g methods and FEC-recovery-aware congestion controls could be proposed. This wou
ld allow the design of adaptive coding rates.</t>
<t>There is a general trade-off, inherent to the <dl>
use of coding, between (1) reducing goodput when useless repair symbols are tran <dt>Research question 3:
smitted and (2) helping to recover from transmission and congestion losses.</t> </dt>
<dd>"Should we quantify the harm that a coded flow would induce on
a non-coded flow? How can this be reduced while still benefiting
from advantages brought by FEC?"
</dd>
<section title="Parameter derivation"> <dt>Research question 4:
<t>There is a trade-off related to the amount of </dt>
redundancy to add, as a function of the transport layer protocol and application <dd>"If transport and FEC senders are collocated and close to the
requirements.</t> client, and FEC is applied only on the last mile, e.g., to ignore
<t><xref target="RFC8095"></xref> describes the m losses on a noisy wireless link, would this raise fairness issues?"
echanisms provided by existing IETF protocols such as TCP, SCTP or RTP. <xref ta </dd>
rget="RFC8406"></xref> describes the variety of coding techniques. The number of
combinations makes the determination of an optimum parameters derivation very c
omplex. This depends on application requirements and deployment context.</t>
<t>Appendix C of <xref target="RFC8681"></xref> d
escribes how to tune the parameters for target use-case. However, this discussio
n does not integrate congestion-controlled end points.</t>
<t>Research question 1 : "Is there a way to dynam
ically adjust the codec characteristics depending on the transmission channel, t
he transport protocol and application requirements ?"</t>
<t>Research question 2 : "Should we apply specifi
c per-stream FEC mechanisms when multiple streams with different reliability nee
ds are carried out ?"</t>
</section>
<section title="New signaling methods and fairnes <dt>Research question 5:
s"> </dt>
<t>Recovering lost symbols may hide conge <dd>"Should we propose a generic API to allow dynamic interactions
stion losses from the congestion control. Disambiguate acked packets from rebuil between a transport protocol and a coding scheme? This should
t packets would help the sender adapt its sending rate accordingly. There are op consider existing APIs between application and transport layers."
portunities for introducing interaction between congestion control and coding sc </dd>
hemes to improve the quality of experience while guaranteeing fairness with othe </dl>
r flows.</t>
<t>Some existing solutions already propos
e to disambiguate acked packets from rebuilt packets <xref target="QUIC-FEC"></x
ref>. New signaling methods and FEC-recovery-aware congestion controls could be
proposed. This would allow the design of adaptive coding rates.</t>
<t>Research question 3 : "Should we quantify the
harm that a coded flow would induce on a non-coded flow ? How can this be reduce
d while still benefiting from advantages brought by FEC ?"</t>
<t>Research question 4 : "If transport and FEC se
nders are collocated and close to the client, and FEC is applied only on the las
t mile, e.g. to ignore losses on a noisy wireless link, would this raise fairnes
s issues ?"</t>
<t>Research question 5 : "Should we propose a gen
eric API to allow dynamic interactions between a transport protocol and a coding
scheme ? This should consider existing APIs between application and transport l
ayers."</t>
</section>
</section> </section>
</section>
<section numbered="true" toc="default">
<name>Recommendations and Advice for Evaluating Coding Mechanisms</name>
<section title="Recommendations and advice for evaluating <dl>
coding mechanisms">
<t>Research Recommendation 1: "From a congestion
control point-of-view, a recovered packet must be considered as a lost packet. T
his does not apply to the usage of FEC on a path that is known to be lossy."</t>
<t>Research Recommendation 2: "New research contr
ibutions should be mapped following the organization of this document (above, be
low, in the congestion control) and should consider congestion control aspects w
hen proposing and comparing FEC coding solutions in communication systems."</t>
<t>Research Recommendation 3: "When a research wo
rk aims at improving throughput by hiding the packet loss signal from congestion
control (e.g., because the path between the sender and receiver is known to con
sist of a noisy wireless link), the authors should 1) discuss the advantages of
using the proposed FEC solution compared to replacing the congestion control by
one that ignores a portion of the encountered losses, 2) critically discuss the
impact of hiding packet loss from the congestion control mechanism."</t>
</section>
</section> <dt>Research Recommendation 1:
</dt>
<dd>"From a congestion control point of view, a recovered packet must be conside
red as a lost packet. This does not apply to the usage of FEC on a path that is
known to be lossy."
</dd>
<!-- ######################################################--> <dt>Research Recommendation 2:
<!-- ######################################################--> </dt>
<!-- Tail of the document --> <dd>"New research contributions should be mapped following the organization of t
<!-- ######################################################--> his document (above, below, and in the congestion control) and should consider c
<!-- ######################################################--> ongestion control aspects when proposing and comparing FEC coding solutions in c
ommunication systems."
</dd>
<section anchor="sec:acknowledgements" title="Acknowledgements"> <dt>Research Recommendation 3:
<t>Many thanks to Spencer Dawkins, Dave Oran, Carsten Bormann, Vincent Roca </dt>
and Marie-Jose Montpetit for their useful comments that helped improve the docum <dd>"When a research work aims at improving throughput by hiding the packet loss
ent.</t> signal from congestion control (e.g., because the path between the sender and r
</section> eceiver is known to consist of a noisy wireless link), the authors should 1) dis
cuss the advantages of using the proposed FEC solution compared to replacing the
congestion control by one that ignores a portion of the encountered losses and
2) critically discuss the impact of hiding packet loss from the congestion contr
ol mechanism."
</dd>
<section anchor="sec:IANA" title="IANA Considerations"> </dl>
<t>This memo includes no request to IANA.</t>
</section>
</section> </section>
<section anchor="sec:ecurity" title="Security Considerations"> <section anchor="sec_IANA" numbered="true" toc="default">
<t>FEC and CC schemes can contribute to DoS attacks. Moreover, the tr <name>IANA Considerations</name>
ansmission of signaling messages from the client to the server should be protect <t>This document has no IANA actions.</t>
ed and reliable otherwise an attacker may compromise FEC rate adaptation. Indeed </section>
, an attacker could either modify the values indicated by the client or drop sig <section anchor="sec_ecurity" numbered="true" toc="default">
naling messages.</t> <name>Security Considerations</name>
<t>In case of FEC below the transport, the aggregate rate of source and repa <t>FEC and CC schemes can contribute to DoS attacks. Moreover, the transmi
ir packets may exceed the rate at which a congestion control mechanism allows an ssion of signaling messages from the client to the server should be protected an
application to send. This could result in an application obtaining more d reliable; otherwise, an attacker may compromise FEC rate adaptation. Indeed, a
n attacker could either modify the values indicated by the client or drop signal
ing messages.</t>
<t>In case of FEC below the transport, the aggregate rate of source and re
pair packets may exceed the rate at which a congestion control mechanism allows
an application to send. This could result in an application obtaining more
than its fair share of the network capacity.</t> than its fair share of the network capacity.</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie
s:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (
as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml
"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml"
)
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included fil
es in the same
directory as the including file. You can also define the XML_LIBRARY environ
ment variable
with a value containing a set of directories to search. These can be either
in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<!-- <references title="Normative References"> <displayreference target="I-D.briscoe-tsvarea-fair" to="FLOW-RATE-FAIRNESS"/
&RFC2119; >
</references> --> <displayreference target="I-D.singh-rmcat-adaptive-fec" to="FEC-CONGESTION-C
ONTROL"/>
<displayreference target="I-D.swett-nwcrg-coding-for-quic" to="CODING-FOR-QU
IC"/>
<displayreference target="I-D.detchart-nwcrg-tetrys" to="TETRYS"/>
<references title="Informative References"> <references>
<?rfc include="reference.RFC.3168.xml"?> <name>Informative References</name>
<?rfc include="reference.RFC.3758.xml"?> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2r
<?rfc include="reference.RFC.4340.xml"?> fc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
<?rfc include="reference.RFC.5109.xml"?> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2r
<?rfc include="reference.RFC.5681.xml"?> fc.ietf.org/public/rfc/bibxml/reference.RFC.3758.xml"/>
<?rfc include="reference.RFC.6297.xml"?> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2r
<?rfc include="reference.RFC.6356.xml"?> fc.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml"/>
<?rfc include="reference.RFC.8095.xml"?> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2r
<?rfc include="reference.RFC.8406.xml"?> fc.ietf.org/public/rfc/bibxml/reference.RFC.5109.xml"/>
<?rfc include="reference.RFC.8680.xml"?> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2r
<?rfc include="reference.RFC.8681.xml"?> fc.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml"/>
<?rfc include="reference.RFC.8699.xml"?> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2r
<?rfc include="reference.I-D.briscoe-tsvarea-fair.xml"?> fc.ietf.org/public/rfc/bibxml/reference.RFC.6297.xml"/>
<!-- <?rfc include="reference.RFC.7567.xml"?> --> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2r
<!-- <?rfc include="reference.RFC.8511.xml"?> --> fc.ietf.org/public/rfc/bibxml/reference.RFC.6356.xml"/>
<!-- <?rfc include="reference.I-D.ietf-rmcat-coupled-cc.xml"?> --> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2r
<!-- <?rfc include="reference.I-D.ietf-tcpm-rto-consider.xml"?> --> fc.ietf.org/public/rfc/bibxml/reference.RFC.8095.xml"/>
<!-- <?rfc include="reference.I-D.ietf-tcpm-rack.xml"?> --> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2r
<?rfc include="reference.I-D.singh-rmcat-adaptive-fec.xml"?> fc.ietf.org/public/rfc/bibxml/reference.RFC.8406.xml"/>
<?rfc include="reference.I-D.swett-nwcrg-coding-for-quic.xml"?> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2r
<?rfc include="reference.I-D.ietf-quic-datagram.xml"?> fc.ietf.org/public/rfc/bibxml/reference.RFC.8680.xml"/>
<?rfc include="reference.I-D.detchart-nwcrg-tetrys.xml"?> --> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2r
<reference anchor="TENTET"> fc.ietf.org/public/rfc/bibxml/reference.RFC.8681.xml"/>
<front> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2r
<title>On the joint use of TCP and Network Coding</title> fc.ietf.org/public/rfc/bibxml/reference.RFC.8699.xml"/>
<author initials="E" surname="Lochin">
</author> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2r
<date year="2017"/> fc.ietf.org/public/rfc/bibxml/reference.RFC.9221.xml"/>
</front>
<seriesInfo name="NWCRG session" value="IETF 100"/> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://datat
</reference> racker.ietf.org/doc/bibxml3/draft-briscoe-tsvarea-fair.xml"/>
<reference anchor="QUIC-FEC">
<front> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://data
<title>QUIC-FEC: Bringing the benefits of Forward Erasure Correc tracker.ietf.org/doc/bibxml3/draft-singh-rmcat-adaptive-fec.xml"/>
tion to QUIC</title> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://datat
<author initials="F" surname="Michel (et al.)"> racker.ietf.org/doc/bibxml3/draft-swett-nwcrg-coding-for-quic.xml"/>
</author>
<date year="2019"/> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://datat
</front> racker.ietf.org/doc/bibxml3/draft-detchart-nwcrg-tetrys.xml"/>
<seriesInfo name="IFIP Networking" value="10.23919/IFIPNetworkin
g.2019.8816838"/> <reference anchor="TENTET" target="https://datatracker.ietf.org/meeting/10
</reference> 0/materials/slides-100-nwcrg-07-lochin-on-the-joint-use-of-tcp-and-network-codin
<reference anchor="NCTCP"> g-00">
<front> <front>
<title>Network Coding Meets TCP: Theory and Implementation</titl <title>On the joint use of TCP and Network Coding</title>
e> <author initials="E" surname="Lochin">
<author initials="J" surname="Sundararajan (et al.)">
</author>
<date year="2009"/>
</front>
<seriesInfo name="IEEE INFOCOM" value="10.1109/JPROC.2010.209385
0"/>
</reference>
<reference anchor="CTCP">
<front>
<title>Network Coded TCP (CTCP)</title>
<author initials="M" surname="Kim (et al.)">
</author>
<date year="2013"/>
</front>
<seriesInfo name="arXiv" value="1212.2291v3"/>
</reference>
<reference anchor="BEYONDJAIN">
<front>
<title>Beyond Jain's Fairness Index: Setting the Bar For The Dep
loyment of Congestion Control Algorithms</title>
<author initials="R" surname="Ware (et al.)">
</author> </author>
<date year="2019"/> <date month="November" year="2017"/>
</front> </front>
<seriesInfo name="HotNets '19" value="10.1145/3365609.3365855"/> <refcontent>NWCRG Session, IETF 100</refcontent>
</reference> </reference>
</references>
</back> <reference anchor="QUIC-FEC">
<front>
<title>QUIC-FEC: Bringing the benefits of Forward Erasure Correction t
o QUIC</title>
<author initials="F" surname="Michel" fullname="François Michel">
</author>
<author initials="Q" surname="De Coninck" fullname="Quentin De Coninc
k">
</author>
<author initials="O" surname="Bonaventure" fullname="Olivier Bonavent
ure">
</author>
<date month="May" year="2019"/>
</front>
<seriesInfo name="DOI" value="10.23919/IFIPNetworking.2019.8816838"/>
</reference>
<reference anchor="NCTCP">
<front>
<title>Network Coding Meets TCP: Theory and Implementation</title>
<author initials="J" surname="Sundararajan" fullname="Jay Kumar Sundar
arajan">
</author>
<author initials="D" surname="Shah" fullname="Devavrat Shah">
</author>
<author initials="M" surname="Médard" fullname="Muriel Médard">
</author>
<author initials="S" surname="Jakubczak" fullname="Szymon Jakubczak">
</author>
<author initials="M" surname="Mitzenmacher" fullname="Michael Mitzenma
cher">
</author>
<author initials="J" surname="Barros" fullname="João Barros">
</author>
<date month="March" year="2011"/>
</front>
<seriesInfo name="DOI" value="10.1109/JPROC.2010.2093850"/>
<refcontent>Proceedings of the IEEE (Volume: 99, Issue: 3)</refcontent>
</reference>
<reference anchor="CTCP">
<front>
<title>Network Coded TCP (CTCP)</title>
<author initials="M" surname="Kim" fullname="MinJi Kim">
</author>
<author initials="J" surname="Cloud" fullname="Jason Cloud">
</author>
<author initials="A" surname="ParandehGheibi" fullname="Ali ParandehGh
eibi">
</author>
<author initials="L" surname="Urbina" fullname="Leonardo Urbina">
</author>
<author initials="K" surname="Fouli" fullname="Kerim Fouli">
</author>
<author initials="D" surname="Leith" fullname="Douglas Leith">
</author>
<author initials="M" surname="Medard" fullname="Muriel Medard">
</author>
<date month="April" year="2013"/>
</front>
<seriesInfo name="DOI" value="10.48550/arXiv.1212.2291"/>
<refcontent>arXiv: 1212.2291v3 </refcontent>
</reference>
<reference anchor="BEYONDJAIN">
<front>
<title>Beyond Jain's Fairness Index: Setting the Bar For The Deploymen
t of Congestion Control Algorithms</title>
<author initials="R" surname="Ware" fullname="Ranysha Ware">
</author>
<author initials="M. K." surname="Mukerjee" fullname="Matthew K. Mukerj
ee" >
</author>
<author initials="S" surname="Seshan" fullname="Srinivasan Seshan" >
</author>
<author initials="J" surname="Sherry" fullname="Justine Sherry">
</author>
<date month="November" year="2019"/>
</front>
<seriesInfo name="DOI" value="10.1145/3365609.3365855"/>
<refcontent>HotNets '19: Proceedings of the 18th ACM Workshop on Hot Top
ics in Networks </refcontent>
</reference>
</references>
<section anchor="sec_acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Many thanks to <contact fullname="Spencer Dawkins"/>, <contact fullname
="Dave Oran"/>, <contact fullname="Carsten Bormann"/>, <contact fullname="Vincen
t Roca"/>, and <contact fullname="Marie-Jose Montpetit"/> for their useful comme
nts that helped improve the document.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 94 change blocks. 
882 lines changed or deleted 891 lines changed or added

This html diff was produced by rfcdiff 1.48.