<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!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 ***** --> number="9265" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IRTF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <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 abbrev="FEC Coding and congestion">Coding Congestion">Forward Erasure Correction (FEC) Coding and congestion control
    Congestion Control in transport</title> Transport</title>
    <seriesInfo name="RFC" value="9265" />
    <author fullname="Nicolas Kuhn" initials="N" surname="Kuhn">
      <organization>CNES</organization>
      <address>
        <email>nicolas.kuhn.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Emmanuel Lochin" initials="E" surname="Lochin">
      <organization>ENAC</organization>
      <address>
        <email>emmanuel.lochin@enac.fr</email>
      </address>
    </author>
    <author fullname="Francois fullname="François Michel" initials="F" surname="Michel">
      <organization>UCLouvain</organization>
      <address>
        <email>francois.michel@uclouvain.be</email>
      </address>
    </author>
    <author fullname="Michael Welzl" initials="M" surname="Welzl">
      <organization>University of Oslo</organization>
      <address>
        <email>michawe@ifi.uio.no</email>
      </address>
    </author>
    <date month="July" year="2022"/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
     in the current day and month for you. If the year is not the current one, it is
     necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
     purpose of calculating the expiry date).  With drafts it is normally sufficient to
     specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>IRTF</area>

    <workgroup>NWCRG</workgroup>

    <!-- 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
    <workgroup>Network Coding for the search engine. -->

        <!-- ######################################################-->
        <!-- ######################################################-->
        <!-- Head of the document -->
        <!-- ######################################################-->
        <!-- ######################################################--> Efficient Network Communications</workgroup>

    <keyword>Coding</keyword>
<keyword>congestion</keyword>
    <abstract>
      <t>Forward Erasure Correction (FEC) is a reliability mechanism that is distinct and separate from the retransmission logic in reliable transfer protocols such as TCP. FEC coding can help deal with losses at the end of transfers or with networks having non-congestion losses. However, FEC coding mechanisms should not hide congestion signals. This memo offers a discussion of how FEC coding and congestion control can coexist. Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems.</t>
      <t>This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG). The scope of the document is end-to-end communications: communications; FEC coding for tunnels is out-of-the out of the scope of the document.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="sec:introduction" title="Introduction"> 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, 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 retransmission could improve the experience of applications using short flows. Another example is a network where non-congestion losses are persistent and prevent a sender from exploiting the link capacity.</t>
	<t>Coding

<t>
Coding and the loss detection of congestion controls are two distinct
and separate reliability mechanisms that is distinct and separate from the loss detection of congestion controls. mechanisms.
Since FEC coding repairs losses, blindly applying FEC may easily lead to an implementation that also hides a congestion signal from the sender.  It is important to ensure that such information hiding of information does not occur, because loss may be the only congestion signal available to the sender (e.g. (e.g., TCP <xref target="RFC5681"/>).</t> target="RFC5681" format="default"/>).</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 channels. This memo offers a discussion of how FEC coding and congestion control coexist. Another objective is to encourage the research community also to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems. This document does not aim at proposing to propose guidelines for characterizing
        FEC coding solutions.</t>
      <t>We consider three architectures for end-to-end unicast data transfer:<list style="symbols">
		<t>with transfer:</t>
      <ul spacing="normal">
        <li>with FEC coding in the application (above the transport) (<xref target="sec:fec-above"/>),</t>
		<t>within target="sec_fec-above" format="default"/>),</li>
        <li>within the transport (<xref target="sec:fec-in"/>), or</t>
		<t>directly target="sec_fec-in" format="default"/>), or</li>
        <li>directly below the transport (<xref target="sec:fec-below"/>).</t>
	</list></t> target="sec_fec-below" format="default"/>).</li>
      </ul>
      <t>A typical scenario for the considerations in this document is a client browsing the web Web or watching a live video.</t>
      <t>This document represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not nor a standard. The document follows the terminology proposed in the taxonomy document <xref target="RFC8406"></xref>.</t> target="RFC8406" format="default"/>.</t>
    </section>

        <!-- ######################################################-->
        <!-- ######################################################-->
        <!-- Body of the document -->
        <!-- ######################################################-->
        <!-- ######################################################-->

        <!-- ######################################################-->
        <!-- New section -->
        <!-- ######################################################-->

        <!-- ######################################################-->
        <!-- New section -->
        <!-- ######################################################-->
    <section anchor="sec:notations" title="Context">

    <section anchor="subsec:def_fairness" title="Fairness, anchor="sec_notations" numbered="true" toc="default">
      <name>Context</name>
      <section anchor="subsec_def_fairness" numbered="true" toc="default">
        <name>Fairness, Quantifying and Limiting Harm, and Policy Concerns"> Concerns</name>
        <t>Traffic from or to different end users may share various types of bottlenecks. When such a shared bottleneck does not implement some form of flow protection, the share of the available capacity between single flows can help assess when one flow starves the other.</t>
        <t>As one example, for residential accesses, the data rate can be guaranteed for the customer premises equipment, equipment but not necessarily for the end user. The quality of service that guarantees fairness between the different clients can be seen as a policy concern <xref target="I-D.briscoe-tsvarea-fair"></xref>.</t> target="I-D.briscoe-tsvarea-fair" format="default"/>.</t>
        <t>While past efforts have focused on achieving fairness, quantifying and limiting harm caused by new algorithms (or algorithms with coding) is more practical <xref target="BEYONDJAIN"></xref>. target="BEYONDJAIN" format="default"/>. This document considers fairness as the impact of the addition of coded flows on non-coded flows when they share the same bottleneck. It is assumed that the non-coded flows respond to congestion signals from the network. This document does not contribute to the definition of fairness at a wider scale.</t>
      </section>
      <section title="Separate channels, separate entities">
		<t><xref target="fig:sep-channel-cc"></xref> numbered="true" toc="default">
        <name>Separate Channels, Separate Entities</name>
        <t>Figures <xref target="fig_sep-channel-cc" format="counter"/> and <xref target="fig:sep-channel-fec"></xref> target="fig_sep-channel-fec" format="counter"/> present the notations that will be used in this document and introduces introduce the Forward Erasure Correction (FEC) and Congestion Control (CC) channels. The Forward Erasure Correction FEC channel carries repair symbols (from the sender to the receiver) and information from the receiver to the sender (e.g. (e.g., signaling which symbols have been recovered, loss rate prior and/or after decoding, etc.). The Congestion Control CC channel carries network packets from a sender to a receiver, receiver and packets signaling information about the network (number of packets received vs. lost, Explicit Congestion Notification (ECN) marks <xref target="RFC3168"/> marks, target="RFC3168" format="default"/>, etc.) from the receiver to the sender. The network packets that are sent by the Congestion Control CC channel may be composed of source packets and/or repair symbols.</t>
        <figure anchor="fig:sep-channel-cc" title="Congestion anchor="fig_sep-channel-cc">
          <name>Congestion Control (CC) channel">
        <artwork> Channel</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 SENDER                                RECEIVER

+------+                               +------+
|      | <![CDATA[-----]]> -----   network packets  ---->|      |
|  CC  |                               |  CC  |
|      | <![CDATA[<---]]> <---  network information  ---|      |
+------+                               +------+
        </artwork>
        ]]></artwork>
        </figure>
        <figure anchor="fig:sep-channel-fec" title="Forward anchor="fig_sep-channel-fec">
          <name>Forward Erasure Correction (FEC) channel">
        <artwork> Channel</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 SENDER                                RECEIVER

+------+                               +------+
|      |           source and/or       |      |
|      | <![CDATA[-----]]> -----    repair symbols  ---->|      |
| FEC  |                               | FEC  |
|      |           signaling           |      |
|      | <![CDATA[<---]]> <---   recovered symbols  ----|      |
+------+                               +------+
        </artwork>
        ]]></artwork>
        </figure>
        <t>Inside a host, the CC and FEC entities can be regarded as
            conceptually separate:</t>
        <figure anchor="fig:sep-entities-srv" title="Separate entities (sender-side)">
        <artwork> anchor="fig_sep-entities-srv">
          <name>Separate Entities (Sender-Side)</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  |            ^             |             ^
  | source     | coding      |packets      | sending
  | packets    | rate        |requirements | rate (or
  v            |             v             | window)
+---------------+source     +-----------------+
|    FEC        |and/or     |    CC           |
|               |repair     |                 |network
|               |symbols    |                 |packets
+---------------+==>        +-----------------+==>
  ^                                       ^
  | signaling                             | network
  | recovered symbols                     | information
        </artwork>
        ]]></artwork>
        </figure>
        <figure anchor="fig:sep-entities-clt" title="Separate entities (receiver-side)">
        <artwork> anchor="fig_sep-entities-clt">
          <name>Separate Entities (Receiver-Side)</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  |                                 |
  | source and/or                   | network
  | repair symbols                  | packets
  v                                 v
+---------------+              +-----------------+
|    FEC        |signaling     |    CC           |
|               |recovered     |                 |network
|               |symbols       |                 |information
+---------------+==>           +-----------------+==>
        </artwork>
        ]]></artwork>
        </figure>

	<t><xref target="fig:sep-entities-srv"></xref>
        <t>Figures <xref target="fig_sep-entities-srv" format="counter"/> and <xref target="fig:sep-entities-clt"></xref> target="fig_sep-entities-clt" format="counter"/> provide more details than Figures <xref target="fig:sep-channel-cc"></xref> target="fig_sep-channel-cc" format="counter"/> and <xref target="fig:sep-channel-fec"></xref>. target="fig_sep-channel-fec" format="counter"/>. Some elements are introduced:<list style="symbols">
			<t>'network introduced:</t>
	<dl newline="true">
	  <dt>'network information' (input control plane for the transport including CC): refers
	  </dt>
	  <dd>refers not only to the network information that is explicitly
	  signaled from the receiver, receiver but all the information a congestion
	  control obtains from a network.</t>
		<t>'requirements' network.
	  </dd>

	  <dt>'requirements' (input control plane for the transport including CC): refers
	  </dt>
	  <dd>refers to application requirements such as upper/lower rate
	  bounds, periods of quiescence, or a priority.</t>
		<t>'sending priority.
	  </dd>

	  <dt>'sending rate (or window)' (output control plane for the transport including CC): refers
	  </dt>
	  <dd>refers to the rate at which a congestion control decides to
	  transmit packets based on 'network information'.</t>
		<t>'signaling information'.
	  </dd>

	  <dt>'signaling recovered symbols' (input control plane for the FEC): refers
	  </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.</t>
		<t>'coding
	  receiver.
	  </dd>

	  <dt>'coding rate' (output control plane for the FEC): refers
	  </dt>
	  <dd>refers to the coding rate that is used by the FEC solution (i.e. (i.e.,
	  proportion of transmitted symbols that carry useful data).</t>
		<t>'network data).
	  </dd>

	  <dt>'network packets' (output data plane for the CC): refers
	  </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.</t>
		<t>'source
	  symbols.
	  </dd>

	  <dt>'source and/or repair symbols' (data plane for the FEC): refers
	  </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) symbols), or a mix of both.</t>
	</list></t>

	<!-- <t><xref target="fig:sep-entities"></xref> provides more details than
	<xref target="fig:sep-channel"></xref> by focusing on the server side. --> both.
	  </dd>

	</dl>

	<t>The inputs to FEC (incoming data packets without repair symbols, symbols and signaling
	from the receiver about losses and/or recovered symbols)
        are distinct from the inputs to CC. The latter calculates a
        sending rate or window from network information, and it takes
        the packet to send as input, sometimes along with application requirements
        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
            algorithm are useful to FEC in their raw form, and vice versa - versa; information
	    about recovered blocks may be quite irrelevant to a CC algorithm. <!-- However,
            there can be meaningful other interactions (indicated by the horizontal double arrow)
            between the two entities, usually as a result of their operation rather than
	    by relaying their own raw inputs. For example, the network measurements carried
            out by CC can yield a longer-term statistical measure such as a loss ratio
            which is useful input for a FEC coding scheme. Similarly, unequal error
            protection using fountain codes can be used to assign different priorities
	    to blocks of data, and these priorities can be honored by a CC mechanism. -->
	     </t>
      </section>
      <section title="Relation numbered="true" toc="default">
        <name>Relation between transport layer Transport Layer and application requirements"> Application Requirements</name>
        <t>The choice of the adequate transport layer may be related to application requirements and the services offered by a transport protocol <xref target="RFC8095"></xref>:<list style="symbols">
		    <t>The target="RFC8095" format="default"/>:</t>

<t indent="3">
The transport layer may implement a retransmission mechanism to guarantee the reliability of a data transfer (e.g. (e.g., TCP). Depending on how the FEC and CC functions are scheduled (FEC above CC (<xref target="sec:fec-above"/>), target="sec_fec-above" format="default"/>), FEC in CC (<xref target="sec:fec-in"/>), target="sec_fec-in" format="default"/>), and FEC below CC (<xref target="sec:fec-below"/>)), target="sec_fec-below" format="default"/>)), the impact of reliable transport on the FEC reliability mechanisms is different.</t></list></t> different.
</t>

        <t>The transport layer may provide an unreliable transport service (e.g. (e.g., UDP or DCCP the Datagram Congestion Control Protocol (DCCP) <xref target="RFC4340"></xref>) target="RFC4340" format="default"/>) or a partially reliable transport service (e.g. SCTP (e.g., the Stream Control Transmission Protocol (SCTP) with the partial reliability extension <xref target="RFC3758"></xref> target="RFC3758" format="default"/> or QUIC with the unreliable datagram extension <xref target="I-D.ietf-quic-datagram"></xref>). target="RFC9221" format="default"/>). Depending on the amount of redundancy and network conditions, there could be cases where it becomes impossible to carry traffic. This is further discussed in <xref target="sec:fec-above"/> target="sec_fec-above" format="default"/> where a "FEC above CC" case is assessed and in Sections <xref target="sec:fec-in"/> target="sec_fec-in" format="counter"/> and in <xref target="sec:fec-below"/> target="sec_fec-below" format="counter"/> where "FEC in CC"  and "FEC below CC" are assessed.</t> assessed, respectively.</t>
      </section>

      <section title="Scope numbered="true" toc="default">
        <name>Scope of the document concerning transport multipath Document Concerning Transport Multipath and multi-streams applications"> Multistream Applications</name>
        <t>The application layer can be composed of several streams above FEC and transport layers transport-layer instances. The transport layer can exploit a multipath mechanism. The different streams could exploit different paths between the sender and the receiver. Moreover, a single-stream application could also exploit a multipath transport mechanism. This section describes what is in the scope of this document in regards with multi-streams regard to multistream applications and multipath transport protocols.</t>
        <t>The different combinations between multi-stream multistream applications and multipath transport are the following: (1) one application layer application-layer stream as input packets above a combination of FEC and multipath (Mpath) transport layers (<xref target="fig:multi-scope-single-stream"></xref>), target="fig_multi-scope-single-stream" format="default"/>) and (2) multiple application layer application-layer streams as input packets above a combination of FEC and multipath (Mpath) or single path (Spath) transport layers (<xref target="fig:multi-scope-multi-stream"></xref>). target="fig_multi-scope-multi-stream" format="default"/>). This document further details cases I (in <xref target="subsec:multipath_above"></xref>), target="subsec_multipath_above" format="default"/>), II (in <xref target="subsec:multipath_in"></xref>) target="subsec_multipath_in" format="default"/>), and III (in <xref target="subsec:multipath_below"></xref>) target="subsec_multipath_below" format="default"/>) as illustrated in <xref target="fig:multi-scope-single-stream"></xref>. target="fig_multi-scope-single-stream" format="default"/>. Cases IV, V V, and VI of <xref target="fig:multi-scope-multi-stream"></xref> target="fig_multi-scope-multi-stream" format="default"/> are related to how multiple streams are managed by a single transport or FEC layer: layer; this does not directly concerns concern the interaction between FEC and the transport and is out of the scope of this document.</t>
        <figure anchor="fig:multi-scope-single-stream" title="Transport multipath anchor="fig_multi-scope-single-stream">
          <name>Transport Multipath and single stream applications Single-Stream Applications - in the scope Scope of the document">
	<artwork> Document</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
      CASE I             CASE II            CASE III
 +---------------+  +---------------+  +---------------+
 |    Stream 1   |  |    Stream 2   |  |    Stream 3   |
 +---------------+  +---------------+  +---------------+

 +---------------+  +---------------+  +---------------+
 |      FEC      |  |      FEC      |  |Mpath Transport|
 +---------------+  |      in       |  +---------------+
                    |Mpath Transport|
 +---------------+  |               |  +-----+   +-----+
 |Mpath Transport|  |               |  |Flow1|...|FlowM|
 +---------------+  +---------------+  +-----+   +-----+

 +-----+   +-----+  +-----+   +-----+  +-----+   +-----+
 |Flow1|...|FlowM|  |Flow1|...|FlowM|  | FEC |...| FEC |
 +-----+   +-----+  +-----+   +-----+  +-----+   +-----+
        </artwork>
        ]]></artwork>
        </figure>
        <figure anchor="fig:multi-scope-multi-stream" title="Transport single path, transport multipath anchor="fig_multi-scope-multi-stream">
          <name>Transport Single Path, Transport Multipath, and multi-stream applications Multistream Applications - out of the scope Scope of the document">
	<artwork> Document</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
      CASE IV                CASE  V                CASE VI
+-------+   +-------+  +-------+   +-------+  +-------+   +-------+
|Stream1|...|StreamM|  |Stream1|...|StreamM|  |Stream1|...|StreamM|
+-------+   +-------+  +-------+   +-------+  +-------+   +-------+

+-------------------+  +-------------------+  +-------------------+
|                   |  |        FEC        |  |  Mpath Transport  |
|        FEC        |  +-------------------+  +-------------------+
|  above/in/below   |
|  Spath Transport  |  +-------------------+  +-------------------+
|                   |  |  Mpath Transport  |  |        FEC        |
+-------------------+  +-------------------+  +-------------------+

+-------------------+  +-----+       +-----+  +-----+       +-----+
|        Flow       |  |Flow1|  ...  |FlowM|  |Flow1|  ...  |FlowM|
+-------------------+  +-----+       +-----+  +-----+       +-----+
        </artwork>
        ]]></artwork>
        </figure>
      </section>
      <section anchor="subsec:def_code" title="Types anchor="subsec_def_code" numbered="true" toc="default">
        <name>Types of coding"> Coding</name>
        <t><xref target="RFC8406"></xref> target="RFC8406" format="default"/> summarizes recommended terminology for Network Coding concepts and constructs. In particular, the document identifies the following coding types (among many others): <list style="symbols">
			<t>Block </t>

	<dl>

	  <dt>Block Coding: 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.</t>
			<t>Sliding basis.
	  </dd>

	  <dt>Sliding Window Coding: general
	  </dt>
	  <dd>General class of coding techniques that rely on a sliding
	  encoding window.</t>
	</list></t> window.
	  </dd>
</dl>

<t>The decoding scheme may not be able to decode all the symbols. The chance of decoding the erased packets depends on the size of the encoding window, the coding rate rate, and the distribution of erasure in the transmission channel. The FEC channel may let the client transmit information related to the need of supplementary symbols to adapt the level of reliability. Partial and full reliability could be envisioned.<list style="symbols">
			<t>Full envisioned.</t>

<dl>
  <dt>Full reliability: The
  </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.</t>
			<t>Partial symbols.
  </dd>

    <dt>Partial reliability: The
  </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
  Window Coding) or of blocks (for Block Coding) containing the source
  symbols, increasing the amount of repair symbols would increase the chances
  of recovering the erased symbols. However, this would have an impact on memory
  requirements, on the cost of encoding and decoding processes processes, and on the
  network overhead.</t>
	</list></t> overhead.
  </dd>
</dl>

</section>
    </section>

        <!-- ######################################################-->
        <!-- New section -->
        <!-- ######################################################-->
	<!--

	<section anchor="sec:scope" title="Scope">
		<t>This section describes the scope of the document.</t>
        <section anchor="sec:scope:appli" title="Type of application">
            <t>The document focuses on reliable data transfers.</t>
        </section>
        <section anchor="sec:scope:e2e" title="End-to-end">
            <t>The document focuses on end-to-end coding, i.e. cases where coding is added at the server and client end points. The discussions should then consider fairness with non-coding solutions.</t>
        </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 (FEC anchor="sec_fec-above" numbered="true" toc="default">
      <name>FEC above the transport, FEC within the transport, FEC below the transport).</t> -->

	<!-- ######################################################-->
        <!-- New section -->
        <!-- ######################################################-->
	<section anchor="sec:fec-above" title="FEC above the transport"> Transport</name>
      <figure anchor="fig:fec-above" title="FEC anchor="fig_fec-above">
        <name>FEC above the transport">
        	<artwork> Transport</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 | source                               ^ source
 | packets                              | packets
 v                                      |
+-------------+                      +-------------+
|FEC          |             signaling|FEC          |
|             |             recovered|             |
|             |               symbols|             |
|             |                   <![CDATA[<]]>==|                   <==|             |
+-------------+                      +-------------+
 | source  ^                            ^ source
 | and/or  | sending                    | and/or
 | repair  | rate                       | repair
 | symbols | (or window)                | symbols
 v         |                            |
+-------------+                      +-------------+
|Transport    |               network|Transport    |
|(incl. CC)   |           information|             |
|             |network            <![CDATA[<]]>==|            <==|             |
|             |packets               |             |
+-------------+==>                   +-------------+

    SENDER                               RECEIVER
		</artwork>
		]]></artwork>
      </figure>
      <t><xref target="fig:fec-above"></xref> target="fig_fec-above" format="default"/> presents an architecture where FEC operates on top of the transport.</t>
      <t>The advantage of this approach is that the FEC overhead does not contribute to congestion in the network when congestion control is implemented at the transport layer, because the repair symbols are sent following the congestion window or rate determined by the CC mechanism. This can result in an improved quality of experience for latency sensitive latency-sensitive applications such as Voice over IP (VoIP) or any not-fully reliable services.</t>
      <t>This approach requires that the transport protocol does not implement a fully reliable in-order data transfer service (e.g., like TCP). QUIC with the unreliable datagram extension <xref target="I-D.ietf-quic-datagram"/> target="RFC9221" format="default"/> is an example of a protocol for which this is relevant. In cases where the partially reliable transport is blocked and a fall-back fallback to a reliable transport is proposed, there is a risk for bad interactions between reliability at the transport level and coding schemes. For reliable transfers, coding usage does not guarantee better performance; instead, it would mainly reduce goodput.</t>
      <section anchor="subsec:fairness_above" title="Fairness anchor="subsec_fairness_above" numbered="true" toc="default">
        <name>Fairness and impact Impact on non-coded flows"> Non-coded Flows</name>
        <t>The addition of coding within the flow does not influence the interaction between coded and non-coded flows. This interaction would mainly depend on the congestion controls associated with each flow.</t>
      </section>
      <section anchor="subsec:cc-recov-interaction_above" title="Congestion control anchor="subsec_cc-recov-interaction_above" numbered="true" toc="default">
        <name>Congestion Control and recovered symbols"> Recovered Symbols</name>
        <t>The congestion control mechanism receives network packets and may not be able to differentiate repair symbols from actual source ones.
	This differentiation requires a transport protocol providing to provide more than the services described in <xref target="RFC8095"/>, in particular target="RFC8095" format="default"/>, such as specifically indicating what information has been repaired. The relevance of adding coding at the application layer is related to the needs of the application. For real-time applications using an unreliable or partially reliable transport, this approach may reduce the number of losses perceived by the application.</t>
      </section>
      <section anchor="subsec:cc-nc-interaction_above" title="Interactions anchor="subsec_cc-nc-interaction_above" numbered="true" toc="default">
        <name>Interactions between congestion control Congestion Control and coding rates"> Coding Rates</name>
        <t>The coding rate applied at the application layer mainly depends on the available rate or congestion window given by the congestion control underneath. The coding rate could be adapted to avoid adding overhead when the minimum required data rate of the application is not provided by the congestion control underneath. When the congestion control allows sending faster than the application needs, adding coding can reduce packet losses and improve the quality of experience (provided that an unreliable or partially reliable transport is used).</t>
      </section>
      <section anchor="subsec:cc-useless-interaction_above" title="On useless repair symbols"> anchor="subsec_cc-useless-interaction_above" numbered="true" toc="default">
        <name>On Useless Repair Symbols</name>
        <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 traffic). In this case, useless repair symbols would only impact the amount of data generated in the network. Extra data in the network can, however, increase the likelihood of increasing delay and/or packet loss, which could provoke a congestion control reaction that would degrade goodput.</t>
      </section>
      <section anchor="subsec:partial_order_above" title="On partial ordering anchor="subsec_partial_order_above" numbered="true" toc="default">
        <name>On Partial Ordering at FEC level"> Level</name>
        <t>Irrespective of the transport protocol, a FEC mechanism does not require to implement implementing a reordering mechanism if the application does not need it. However, if the application needs in-order delivery of packets, a reordering mechanism at the receiver is required.</t>
      </section>
      <section anchor="subsec:partial_rel_above" title="On partial reliability anchor="subsec_partial_rel_above" numbered="true" toc="default">
        <name>On Partial Reliability at FEC level"> Level</name>
        <t>The application may require partial reliability. In this case, the coding rate of a FEC mechanism could be adapted based on inputs from the application and the trade-off between latency and packet 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"></xref>. target="subsec_def_code" format="default"/>. </t>
      </section>
      <section anchor="subsec:multipath_above" title="On multipath transport anchor="subsec_multipath_above" numbered="true" toc="default">
        <name>On Multipath Transport and FEC mechanism"> Mechanism</name>
        <t>Whether the transport protocol exploits multiple paths or not does not have an impact on the FEC mechanism.</t>
      </section>
    </section>

	<!-- ######################################################-->
	<!-- New subsection -->
        <!-- ######################################################-->

	<section anchor="sec:fec-in" title="FEC anchor="sec_fec-in" numbered="true" toc="default">
      <name>FEC within the transport"> Transport</name>
      <figure anchor="fig:fec-in" title="FEC anchor="fig_fec-in">
        <name>FEC in the transport">
        	<artwork> Transport</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 | source                               ^ source
 | packets                              | packets
 v                                      |
+------------+                      +------------+
| Transport  |                      | Transport  |
|            |                      |            |
| +---+ +--+ |             signaling| +---+ +--+ |
| |FEC| |CC| |             recovered| |FEC| |CC| |
| +---+ +--+ |               symbols| +---+ +--+ |
|            |                   <![CDATA[<]]>==|                   <==|            |
|            |network        network|            |
|            |packets    information|            |
+------------+ ==>               <![CDATA[<]]>==+------------+               <==+------------+

    SENDER                              RECEIVER
        	</artwork>
        	]]></artwork>
      </figure>
      <t><xref target="fig:fec-in"></xref> target="fig_fec-in" format="default"/> presents an architecture where FEC operates within the transport. The repair symbols are sent within what the congestion window or calculated rate allows, such as in <xref target="CTCP"/>.</t> target="CTCP" format="default"/>.</t>
      <t>The advantage of this approach is that it allows a joint optimization of CC and FEC. Moreover, the transmission of repair symbols does not add congestion in potentially congested networks but helps repair lost packets (such as tail losses). This joint optimization is the key to prevent flows to consume the whole available capacity. The amount of repair traffic injected should not lead to congestion. As denoted in <xref target="I-D.singh-rmcat-adaptive-fec" />, format="default"/>, an increase of the repair ratio should be done conjointly with a decrease of the source sending rate.</t>
      <t>The drawback of this approach is that it may require specific signaling and transport services that may not be described in <xref target="RFC8095"/>. target="RFC8095" format="default"/>. Therefore, development and maintenance may require specific efforts at both the transport and the coding level levels, and the design of the solution may end up being complex to suit different deployment needs.</t>

      <t>For reliable transfers, including redundancy reduces goodput for long transfers transfers, but the amount of repair symbols can be adapted, e.g. e.g., depending on the congestion window size. There is a trade-off between 1) the capacity that could have been exploited by application data instead of transmitting source packets, packets and 2) the benefits derived from transmitting repair symbols (e.g. (e.g., unlocking the receive buffer if it is limiting). The coding ratio needs to be carefully 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, packets or 2) the transmission of new packets.</t>
      <t>Examples of the solution could be to add a given percentage of the congestion window or rate as supplementary symbols, symbols or to send a fixed amount of repair symbols at a fixed rate. The redundancy flow can be decorrelated from the congestion control that manages source packets: packets; a separate congestion control entity could be introduced to manage the amount of recovered symbols to transmit on the 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"/> target="RFC8699" format="default"/> in case all traffic can be assumed to take the same path, or otherwise with a multipath congestion window coupling mechanism as in Multipath TCP <xref target="RFC6356"/>. target="RFC6356" format="default"/>. Another possibility would be to exploit a lower than best-effort lower-than-best-effort congestion control <xref target="RFC6297"/> target="RFC6297" format="default"/> for repair symbols.</t>
      <section anchor="subsec:fairness_in" title="Fairness anchor="subsec_fairness_in" numbered="true" toc="default">
        <name>Fairness and impact Impact on non-coded flows"> Non-coded Flows</name>

        <t>Specific interaction between congestion controls and coding schemes can be proposed (see Sections <xref target="subsec:cc-nc-interaction_in"></xref> target="subsec_cc-nc-interaction_in" format="counter"/> and <xref target="subsec:cc-useless-interaction_in"></xref>). target="subsec_cc-useless-interaction_in" format="counter"/>). If no specific interaction is introduced, the coding scheme may hide congestion losses from the congestion controller controller, and the description of <xref target="sec:fec-below"></xref> target="sec_fec-below" format="default"/> may apply.</t>
      </section>
      <section anchor="subsec:cc-nc-interaction_in" title="Interactions anchor="subsec_cc-nc-interaction_in" numbered="true" toc="default">
        <name>Interactions between congestion control Congestion Control and coding rates"> Coding Rates</name>

        <t>The receiver can differentiate between source packets and repair symbols. The receiver may indicate both the number of source packets received and the repair symbols that were actually useful in the recovery process of packets. The congestion control at the sender can then exploit this information 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 repair symbols are transmitted 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 received or recovered. The sender may use this information to tune the coding ratio. For example, coupling an increased transmission rate with an increasing or decreasing coding rate could be envisioned. A server may use a decreasing coding rate as a probe of the channel capacity and adapt the congestion control transmission rate.</t>
      </section>
      <section anchor="subsec:cc-useless-interaction_in" title="On useless repair symbols"> anchor="subsec_cc-useless-interaction_in" numbered="true" toc="default">
        <name>On Useless Repair Symbols</name>
        <t>The sender may exploit the information given by the receiver to reduce the number of useless repair symbols, symbols and improve goodput.</t>
      </section>
      <section anchor="subsec:partial_order_in" title="On partial ordering anchor="subsec_partial_order_in" numbered="true" toc="default">
        <name>On Partial Ordering at FEC and/or transport level"> Transport Level</name>
        <t>The application may require in-order delivery of packets. In this case, both FEC and transport layer transport-layer mechanisms should guarantee that packets are delivered in order.

If partial ordering is requested by the application, both the FEC and
transport could relax the constraints related to in-order delivery: delivery; partial
ordering impacts both the congestion control and the type of FEC and type of
codec that can be used, mostly at the receiver that may need to implement partial reordering.</t> used.
	</t>
      </section>
      <section anchor="subsec:partial_rel_in" title="On partial reliability anchor="subsec_partial_rel_in" numbered="true" toc="default">
        <name>On Partial Reliability at FEC level"> Level</name>
        <t>The application may require partial reliability. The reliability offered by FEC may be sufficient, sufficient with no retransmission required. This depends on application 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"></xref>.</t> target="subsec_def_code" format="default"/>.</t>
      </section>
      <section anchor="subsec:multipath_in" title="On transport multipath anchor="subsec_multipath_in" numbered="true" toc="default">
        <name>On Transport Multipath and subpath Subpath FEC coding rate"> Coding Rate</name>
        <t>The sender may adapt the coding rate of each of the single subpaths, subpaths whether the congestion control is coupled or not. There is an important flexibility on how the coding rate is tuned depending on the characteristics of each subpath.</t>
      </section>
    </section>

	 <!-- ######################################################-->
         <!-- New subsection -->
         <!-- ######################################################-->

        <section anchor="sec:fec-below" title="FEC anchor="sec_fec-below" numbered="true" toc="default">
      <name>FEC below the transport"> Transport</name>
      <figure anchor="fig:fec-below" title="FEC anchor="fig_fec-below">
        <name>FEC below the transport">
        	<artwork> Transport</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 | source                               ^ source
 | packets                              | packets
 v                                      |
+--------------+                      +--------------+
|Transport     |               network|Transport     |
|(including CC)|           information|              |
|              |                   <![CDATA[<]]>==|                   <==|              |
+--------------+                      +--------------+
 | network packets                      ^ network packets
 v                                      |
+--------------+                      +--------------+
| FEC          |source                |  FEC         |
|              |and/or       signaling|              |
|              |repair       recovered|              |
|              |symbols        symbols|              |
|              |==>                <![CDATA[<]]>==|                <==|              |
+--------------+                      +--------------+

    SENDER                                RECEIVER
		</artwork>
		]]></artwork>
      </figure>
      <t><xref target="fig:fec-below"/> target="fig_fec-below" format="default"/> presents an architecture where FEC is applied end-to-end end to end below the transport layer, layer but above the link layer.  Note that it is common to apply FEC at the link layer on one or more of the links that make up the end-to-end path. The application of FEC at the link layer contributes to the total capacity that a link exposes to upper layers, but it 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, and therefore link; this is therefore 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 considered here, the repair symbols are not visible to the end-to-end congestion controller 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 potential fairness issues. The effective bit-rate bit rate is higher than the CC's computed fair share due to the transmission of repair symbols, and losses are hidden from 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 gains when there are persistent transmission losses along the path.</t>
      <t>The drawback of this approach is that it can induce congestion in already 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 congestion window or rate as supplementary symbols, symbols or to send a fixed amount of repair symbols at a fixed rate. The redundancy flow can be decorrelated from the congestion control that manages source packets: packets; a separate congestion control entity could be introduced to manage the amount of recovered symbols to transmit on the 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"/> target="RFC8699" format="default"/> in case all traffic can be assumed to take the same path, or otherwise with a multipath congestion window coupling mechanism as in Multipath TCP <xref target="RFC6356"/>. target="RFC6356" format="default"/>. Another possibility would be to exploit a lower than best-effort lower-than-best-effort congestion control <xref target="RFC6297"/> target="RFC6297" format="default"/> for repair symbols.</t>
      <section anchor="subsec:fairness_below" title="Fairness anchor="subsec_fairness_below" numbered="true" toc="default">
        <name>Fairness and impact Impact on non-coded flows"> Non-coded Flows</name>
        <t>The coding scheme may hide congestion losses from the congestion controller. There are cases where this can drastically reduce the goodput of non-coded flows. Depending on the congestion control, it may be possible to signal to the congestion control mechanism that there was congestion (loss) even when a packet has been recovered, e.g. e.g., using ECN, to reduce the impact on the non-coded flows (see <xref target="subsec:cc-recov-interaction_below"></xref> target="subsec_cc-recov-interaction_below" format="default"/> and <xref target="TENTET"></xref>).</t> target="TENTET" format="default"/>).</t>
      </section>
      <section anchor="subsec:cc-recov-interaction_below" title="Congestion control anchor="subsec_cc-recov-interaction_below" numbered="true" toc="default">
        <name>Congestion Control and recovered symbols"> Recovered Symbols</name>
        <t>The congestion control may not be aware of the existence of a coding scheme underneath it. The congestion control may behave as 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 signaling 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> target="TENTET" format="default"/>.</t>
      </section>
      <section anchor="subsec:cc-nc-interaction_below" title="Interactions anchor="subsec_cc-nc-interaction_below" numbered="true" toc="default">
        <name>Interactions between congestion control Congestion Control and coding rates"> Coding Rates</name>
        <t>The coding rate can be tuned depending on the number of recovered symbols and the rate at which the sender transmits data. If the coding scheme is not aware of the congestion control implementation, it is hard for the coding scheme to apply the relevant coding rate.</t>
      </section>
      <section anchor="subsec:cc-useless-interaction_below" title="On useless repair symbols"> 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 actual gain for the coded flow.  Using feedback signaling, FEC mechanisms can measure the ratio between the number of symbols that were actually used and the number of symbols that were useless, and adjust the coding rate.</t>
      </section>
      <section anchor="subsec:partial_order_below" title="On partial ordering anchor="subsec_partial_order_below" numbered="true" toc="default">
        <name>On Partial Ordering at FEC level Level with in-order delivery transport"> In-Order Delivery Transport</name>
        <t>The transport above the FEC channel may support out-of-order delivery of packets: packets; reordering mechanisms at the receiver may not be necessary. In cases where the transport requires in-order delivery, the FEC channel may need to implement a reordering mechanism. Otherwise, spurious retransmissions may occur at the transport level.</t>
      </section>
      <section anchor="subsec:partial_rel_below" title="On partial reliability anchor="subsec_partial_rel_below" numbered="true" toc="default">
        <name>On Partial Reliability at FEC level"> 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 aware of the reliability requirements.  Partial reliability impacts the type of FEC and type of codec that can be used, such as discussed in <xref target="subsec:def_code"/>.</t> target="subsec_def_code" format="default"/>.</t>
      </section>
      <section anchor="subsec:multipath_below" title="FEC not aware anchor="subsec_multipath_below" numbered="true" toc="default">
        <name>FEC Not Aware of transport multipath"> Transport Multipath</name>
        <t>The transport may exploit multiple paths without the FEC channel being aware of it. If FEC is aware that multiple paths are in use, FEC can be applied to all subflows as an aggregate, or to each of the subflows individually. If FEC 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 coding rate to be inadequate for the characteristics of the individual paths.</t>
      </section>
    </section>

        <!-- ######################################################-->
        <!-- New section -->
        <!-- ######################################################-->

        <section anchor="sec:research" title="Research recommendations anchor="sec_research" numbered="true" toc="default">
      <name>Research Recommendations and questions"> Questions</name>
      <t>This section provides a short state-of-the art overview of activities related to congestion control and coding. The objective is to identify open research questions and contribute to advice when evaluating coding mechanisms.</t>
      <section title="Activities related numbered="true" toc="default">
        <name>Activities Related to congestion control Congestion Control and coding"> Coding</name>
        <t>We map activities related to congestion control and coding with the organization presented in this document:<list style="symbols">
						<t>For document:</t>

	<dl>

 	  <dt>For the FEC above transport case: <xref target="RFC8680"></xref>.</t>
						<t>For
	  </dt>
	  <dd><xref target="RFC8680" format="default"/>
	  </dd>

	  <dt>For the FEC within transport case:
	  </dt>
	  <dd> <xref target="I-D.swett-nwcrg-coding-for-quic"></xref>, target="I-D.swett-nwcrg-coding-for-quic"
	  format="default"/>, <xref target="QUIC-FEC"></xref>, target="QUIC-FEC" format="default"/>,
	  and <xref target="RFC5109"></xref>.</t>
						<t>For target="RFC5109" format="default"/>
	  </dd>

	  <dt>For the FEC below transport case:
	  </dt>
	  <dd><xref target="NCTCP" format="default"/> and <xref target="NCTCP"></xref>, <xref target="I-D.detchart-nwcrg-tetrys"></xref>.</t>
				</list></t>
	  target="I-D.detchart-nwcrg-tetrys" format="default"/>
	  </dd>
</dl>

</section>
      <section title="Open research questions"> numbered="true" toc="default">
        <name>Open Research Questions</name>
        <t>There is a general trade-off, inherent to the use of coding, between (1) reducing goodput when useless repair symbols are transmitted and (2) helping to recover from transmission and congestion losses.</t>
        <section title="Parameter derivation"> numbered="true" toc="default">
          <name>Parameter Derivation</name>
          <t>There is a trade-off related to the amount of redundancy to add, add as a function of the transport layer transport-layer protocol and application requirements.</t>
          <t><xref target="RFC8095"></xref> target="RFC8095" format="default"/> describes the mechanisms provided by existing IETF protocols such as TCP, SCTP SCTP, or RTP. <xref target="RFC8406"></xref> target="RFC8406" 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>Appendix C of <xref target="RFC8681"></xref>
          <t><xref target="RFC8681" sectionFormat="of" section="C"  format="default"/> describes how to tune the parameters for a target use-case. use case. However, this discussion does not integrate congestion-controlled end points.</t>
				<t>Research

	  <dl>
	    <dt>Research question 1 : "Is 1:
	    </dt>
	    <dd>"Is there a way to dynamically adjust the codec characteristics
depending on the transmission channel, the transport protocol protocol, and application requirements ?"</t>
				<t>Research requirements?"
	    </dd>

	    <dt>Research question 2 : "Should 2:
	    </dt>
	    <dd>"Should we apply specific per-stream FEC mechanisms when
multiple streams with different reliability needs are carried out ?"</t> out?"
	    </dd>
</dl>

        </section>

	<section title="New signaling methods numbered="true" toc="default">
          <name>New Signaling Methods and fairness"> Fairness</name>

	  <t>Recovering lost symbols may hide congestion losses from the congestion control. Disambiguate acked Disambiguating ACKed packets from rebuilt packets would help the sender 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 ACKed packets from rebuilt packets <xref target="QUIC-FEC"></xref>. target="QUIC-FEC" format="default"/>. New signaling methods and FEC-recovery-aware congestion controls could be proposed. This would allow the design of adaptive coding rates.</t>
				<t>Research

	  <dl>
	    <dt>Research question 3 : "Should 3:
	    </dt>
	    <dd>"Should we quantify the harm that a coded flow would induce on
	    a non-coded flow ? flow? How can this be reduced while still benefiting
	    from advantages brought by FEC ?"</t>
				<t>Research FEC?"
	    </dd>

	    <dt>Research question 4 : "If 4:
	    </dt>
	    <dd>"If transport and FEC senders are collocated and close to the
	    client, and FEC is applied only on the last mile, e.g. e.g., to ignore
	    losses on a noisy wireless link, would this raise fairness issues ?"</t>
				<t>Research issues?"
	    </dd>

	    <dt>Research question 5 : "Should 5:
	    </dt>
	    <dd>"Should we propose a generic API to allow dynamic interactions
	    between a transport protocol and a coding scheme ? scheme? This should
	    consider existing APIs between application and transport layers."</t> layers."
	    </dd>
	  </dl>

        </section>
      </section>
      <section title="Recommendations numbered="true" toc="default">
        <name>Recommendations and advice Advice for evaluating coding mechanisms">
				<t>Research Evaluating Coding Mechanisms</name>

<dl>

<dt>Research Recommendation 1: "From
</dt>
<dd>"From a congestion control point-of-view, point of view, a recovered packet must be considered as a lost packet. This does not apply to the usage of FEC on a path that is known to be lossy."</t>
				<t>Research lossy."
</dd>

<dt>Research Recommendation 2: "New
</dt>
<dd>"New research contributions should be mapped following the organization of this document (above, below, and in the congestion control) and should consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems."</t>
				<t>Research systems."
</dd>

<dt>Research Recommendation 3: "When
</dt>
<dd>"When a research work 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 consist 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, losses and 2) critically discuss the impact of hiding packet loss from the congestion control mechanism."</t> mechanism."
</dd>

</dl>

      </section>
    </section>

        <!-- ######################################################-->
        <!-- ######################################################-->
        <!-- Tail of the document -->
        <!-- ######################################################-->
        <!-- ######################################################-->

    <section anchor="sec:acknowledgements" title="Acknowledgements">
    <t>Many thanks to Spencer Dawkins, Dave Oran, Carsten Bormann, Vincent Roca and Marie-Jose Montpetit for their useful comments that helped improve the document.</t>
    </section>

    <section anchor="sec:IANA" title="IANA Considerations"> anchor="sec_IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo includes document has no request to IANA.</t> IANA actions.</t>
    </section>
    <section anchor="sec:ecurity" title="Security Considerations"> anchor="sec_ecurity" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>FEC and CC schemes can contribute to DoS attacks. Moreover, the transmission of signaling messages from the client to the server should be protected and reliable otherwise reliable; otherwise, an attacker may compromise FEC rate adaptation. Indeed, an attacker could either modify the values indicated by the client or drop signaling messages.</t>
      <t>In case of FEC below the transport, the aggregate rate of source and repair 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>
    </section>
  </middle>

    <!--  *****BACK MATTER ***** -->

    <back>
    <!-- References split into informative and normative -->
    <!-- There are 2 ways to insert reference entries from the citation libraries:
    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 files in the same
    directory as the including file. You can also define the XML_LIBRARY environment 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">
        &RFC2119;
    </references> -->

    <references title="Informative References">
        <?rfc include="reference.RFC.3168.xml"?>
        <?rfc include="reference.RFC.3758.xml"?>
        <?rfc include="reference.RFC.4340.xml"?>
        <?rfc include="reference.RFC.5109.xml"?>
        <?rfc include="reference.RFC.5681.xml"?>
        <?rfc include="reference.RFC.6297.xml"?>
        <?rfc include="reference.RFC.6356.xml"?>
        <?rfc include="reference.RFC.8095.xml"?>
        <?rfc include="reference.RFC.8406.xml"?>
        <?rfc include="reference.RFC.8680.xml"?>
        <?rfc include="reference.RFC.8681.xml"?>
        <?rfc include="reference.RFC.8699.xml"?>
	<?rfc include="reference.I-D.briscoe-tsvarea-fair.xml"?>
	<!-- <?rfc include="reference.RFC.7567.xml"?> -->
	<!-- <?rfc include="reference.RFC.8511.xml"?> -->
	<!-- <?rfc include="reference.I-D.ietf-rmcat-coupled-cc.xml"?> -->
        <!-- <?rfc include="reference.I-D.ietf-tcpm-rto-consider.xml"?> -->
        <!-- <?rfc include="reference.I-D.ietf-tcpm-rack.xml"?> -->
	<?rfc include="reference.I-D.singh-rmcat-adaptive-fec.xml"?>
	<?rfc include="reference.I-D.swett-nwcrg-coding-for-quic.xml"?>
	<?rfc include="reference.I-D.ietf-quic-datagram.xml"?>
	<?rfc include="reference.I-D.detchart-nwcrg-tetrys.xml"?> -->

    <displayreference target="I-D.briscoe-tsvarea-fair" to="FLOW-RATE-FAIRNESS"/>
    <displayreference target="I-D.singh-rmcat-adaptive-fec" to="FEC-CONGESTION-CONTROL"/>
    <displayreference target="I-D.swett-nwcrg-coding-for-quic" to="CODING-FOR-QUIC"/>
    <displayreference target="I-D.detchart-nwcrg-tetrys" to="TETRYS"/>

    <references>
      <name>Informative References</name>
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3758.xml"/>
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml"/>
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5109.xml"/>
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml"/>
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6297.xml"/>
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6356.xml"/>
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8095.xml"/>
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8406.xml"/>
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8680.xml"/>
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8681.xml"/>
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8699.xml"/>

      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9221.xml"/>

      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://datatracker.ietf.org/doc/bibxml3/draft-briscoe-tsvarea-fair.xml"/>

	<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://datatracker.ietf.org/doc/bibxml3/draft-singh-rmcat-adaptive-fec.xml"/>
      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://datatracker.ietf.org/doc/bibxml3/draft-swett-nwcrg-coding-for-quic.xml"/>

      <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://datatracker.ietf.org/doc/bibxml3/draft-detchart-nwcrg-tetrys.xml"/>

      <reference anchor="TENTET"> anchor="TENTET" target="https://datatracker.ietf.org/meeting/100/materials/slides-100-nwcrg-07-lochin-on-the-joint-use-of-tcp-and-network-coding-00">
        <front>
          <title>On the joint use of TCP and Network Coding</title>
          <author initials="E" surname="Lochin">
                    </author>
          <date month="November" year="2017"/>
        </front>
                <seriesInfo name="NWCRG session" value="IETF 100"/>
        <refcontent>NWCRG Session, IETF 100</refcontent>
      </reference>

      <reference anchor="QUIC-FEC">
        <front>
          <title>QUIC-FEC: Bringing the benefits of Forward Erasure Correction to QUIC</title>
          <author initials="F" surname="Michel (et al.)"> surname="Michel" fullname="François Michel">
          </author>
           <author initials="Q" surname="De Coninck" fullname="Quentin De Coninck">
           </author>
           <author initials="O" surname="Bonaventure" fullname="Olivier Bonaventure">
           </author>
          <date month="May" year="2019"/>
        </front>
        <seriesInfo name="IFIP Networking" 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 (et al.)"> surname="Sundararajan" fullname="Jay Kumar Sundararajan">
          </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 Mitzenmacher">
     	  </author>
          <author initials="J" surname="Barros" fullname="João Barros">
     	  </author>
        <date year="2009"/> month="March" year="2011"/>
        </front>
	<seriesInfo name="IEEE INFOCOM" 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 (et al.)"> surname="Kim" fullname="MinJi Kim">
          </author>
	  <author initials="J" surname="Cloud" fullname="Jason Cloud">
          </author>
          <author initials="A" surname="ParandehGheibi" fullname="Ali ParandehGheibi">
          </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="arXiv" value="1212.2291v3"/> 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 Deployment of Congestion Control Algorithms</title>
          <author initials="R" surname="Ware (et al.)"> surname="Ware" fullname="Ranysha Ware">
          </author>
	  <author initials="M. K." surname="Mukerjee" fullname="Matthew K. Mukerjee" >
	  </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="HotNets '19" name="DOI" value="10.1145/3365609.3365855"/>
        <refcontent>HotNets '19: Proceedings of the 18th ACM Workshop on Hot Topics 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="Vincent Roca"/>, and <contact fullname="Marie-Jose Montpetit"/> for their useful comments that helped improve the document.</t>
    </section>

  </back>
</rfc>