RFC 9265
Forward Erasure Correction (FEC) Coding and Congestion Control in Transport
Forward Erasure Correction (FEC) Coding and Congestion Control in Transport 🦋
okay bestie, this is RFC 9265 🎀 It's an Informational RFC from the Internet Research Task Force (IRTF), published July 2022, and it's a product of the Coding for Efficient Network Communications Research Group (NWCRG). The authors are N. Kuhn (CNES), E. Lochin (ENAC), F. Michel (UCLouvain), and M. Welzl (University of Oslo). It's filed under ISSN 2070-1721, and the header has no "Obsoletes" or "Updates" line, so it doesn't list any RFCs it replaces or changes. 💖
Abstract ✨
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. 🔥
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; FEC coding for tunnels is out of the scope of the document. 🧚
Status of This Memo 💅
This document is not an Internet Standards Track specification; it is published for informational purposes. 🍓
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Network Coding for Efficient Network Communications Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. 💜
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9265. 🌈
Copyright Notice 🎀
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 🫶
Table of Contents 🦋
1. Introduction
2. Context
2.1. Fairness, Quantifying and Limiting Harm, and Policy
Concerns
2.2. Separate Channels, Separate Entities
2.3. Relation between Transport Layer and Application
Requirements
2.4. Scope of the Document Concerning Transport Multipath and
Multistream Applications
2.5. Types of Coding
3. FEC above the Transport
3.1. Fairness and Impact on Non-coded Flows
3.2. Congestion Control and Recovered Symbols
3.3. Interactions between Congestion Control and Coding Rates
3.4. On Useless Repair Symbols
3.5. On Partial Ordering at FEC Level
3.6. On Partial Reliability at FEC Level
3.7. On Multipath Transport and FEC Mechanism
4. FEC within the Transport
4.1. Fairness and Impact on Non-coded Flows
4.2. Interactions between Congestion Control and Coding Rates
4.3. On Useless Repair Symbols
4.4. On Partial Ordering at FEC and/or Transport Level
4.5. On Partial Reliability at FEC Level
4.6. On Transport Multipath and Subpath FEC Coding Rate
5. FEC below the Transport
5.1. Fairness and Impact on Non-coded Flows
5.2. Congestion Control and Recovered Symbols
5.3. Interactions between Congestion Control and Coding Rates
5.4. On Useless Repair Symbols
5.5. On Partial Ordering at FEC Level with In-Order Delivery
Transport
5.6. On Partial Reliability at FEC Level
5.7. FEC Not Aware of Transport Multipath
6. Research Recommendations and Questions
6.1. Activities Related to Congestion Control and Coding
6.2. Open Research Questions
6.2.1. Parameter Derivation
6.2.2. New Signaling Methods and Fairness
6.3. Recommendations and Advice for Evaluating Coding Mechanisms
7. IANA Considerations
8. Security Considerations
9. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🌸
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 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. ✨
Coding and the loss detection of congestion controls are two distinct and separate reliability 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 hiding of information does not occur, because loss may be the only congestion signal available to the sender (e.g., TCP [RFC5681]).
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 to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems. This document does not aim to propose guidelines for characterizing FEC coding solutions. 🦋
We consider three architectures for end-to-end unicast data transfer:
- with FEC coding in the application (above the transport) (Section 3),
- within the transport (Section 4), or
- directly below the transport (Section 5).
A typical scenario for the considerations in this document is a client browsing the Web or watching a live video. 🍿
This document represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product nor a standard. The document follows the terminology proposed in the taxonomy document [RFC8406]. 🫶
2. Context 💅
2.1. Fairness, Quantifying and Limiting Harm, and Policy Concerns 🦋
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. 👑
As one example, for residential accesses, the data rate can be guaranteed for the customer premises 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 [FLOW-RATE-FAIRNESS]. 🌈
While past efforts have focused on achieving fairness, quantifying and limiting harm caused by new algorithms (or algorithms with coding) is more practical [BEYONDJAIN]. 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. 🧚
2.2. Separate Channels, Separate Entities ✨
okay so Figures 1 and 2 are the cheat sheet 📝 for the notation we're using in this doc. They introduce the Forward Erasure Correction (FEC) channel and the Congestion Control (CC) channel 🦋. The FEC channel carries repair symbols from the sender to the receiver, plus info going back from the receiver to the sender, like which symbols got recovered, the loss rate before and/or after decoding, and stuff like that. The CC channel carries network packets from sender to receiver, and goes the other way with packets that tell the sender what's up with the network: how many packets arrived vs. got lost, Explicit Congestion Notification (ECN) marks [RFC3168], and so on. The network packets sent over the CC channel can be made of source packets, repair symbols, or both 💖
SENDER RECEIVER
+------+ +------+
| | ----- network packets ---->| |
| CC | | CC |
| | <--- network information ---| |
+------+ +------+
Figure 1: Congestion Control (CC) Channel SENDER RECEIVER
+------+ +------+
| | source and/or | |
| | ----- repair symbols ---->| |
| FEC | | FEC |
| | signaling | |
| | <--- recovered symbols ----| |
+------+ +------+
Figure 2: Forward Erasure Correction (FEC) ChannelInside a single host, the CC and FEC entities can be treated as conceptually separate 🎀 (no cap, this is the main character move):
| ^ | ^
| 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
Figure 3: Separate Entities (Sender-Side) | |
| source and/or | network
| repair symbols | packets
v v
+---------------+ +-----------------+
| FEC |signaling | CC |
| |recovered | |network
| |symbols | |information
+---------------+==> +-----------------+==>
Figure 4: Separate Entities (Receiver-Side)Figures 3 and 4 go deeper than Figures 1 and 2 🔍, so a few new terms show up here:
- 'network information' (input control plane for the transport, including CC): this isn't just the network info the receiver explicitly signals back. It's all the info a congestion control gets from a network 🌐
- 'requirements' (input control plane for the transport, including CC): the application's needs, like upper/lower rate bounds, periods of quiescence, or a priority 🍓
- 'sending rate (or window)' (output control plane for the transport, including CC): the rate at which a congestion control decides to transmit packets, based on 'network information' 🚀
- 'signaling recovered symbols' (input control plane for the FEC): info a FEC sender can get from a FEC receiver about how well the FEC solution is doing, as the receiver sees it 👀
- 'coding rate' (output control plane for the FEC): the coding rate the FEC solution uses, meaning the proportion of transmitted symbols that actually carry useful data 🧁
- 'network packets' (output data plane for the CC): the data a CC sender transmits to a CC receiver. These may contain source and/or repair symbols 📦
- 'source and/or repair symbols' (data plane for the FEC): the data a FEC sender transmits to a FEC receiver. The sender can choose to send source symbols only (meaning the coding rate is 0), repair symbols only (if the solution decides not to send the original source symbols), or a mix of both 🌈
The inputs to FEC (incoming data packets without repair symbols, plus signaling from the receiver about losses and/or recovered symbols) are different from the inputs to CC 💅. CC calculates a sending rate or window from network information, and it takes the packet to send as input too, sometimes along with application requirements like upper/lower rate bounds, periods of quiescence, or a priority. It's not clear that the ACK signals feeding a congestion control algorithm are useful to FEC in their raw form, or the other way around. Info about recovered blocks may be pretty irrelevant to a CC algorithm 🙈
2.3. Relation between Transport Layer and Application Requirements
okay bestie, picking the right transport layer depends on what your application needs and what services a transport protocol offers [RFC8095] 🧚
The transport layer may implement a retransmission mechanism to guarantee the reliability of a data transfer (e.g., TCP). Depending on how the FEC and CC functions are scheduled (FEC above CC (Section 3), FEC in CC (Section 4), and FEC below CC (Section 5)), the impact of reliable transport on the FEC reliability mechanisms is different.
Like, if your transport retransmits stuff to keep data reliable (TCP is the classic example 💜), how FEC and CC get scheduled changes how much that affects FEC's own reliability tricks. FEC above CC (Section 3), FEC in CC (Section 4), and FEC below CC (Section 5) all play out differently 😭
The transport layer can also be unreliable, like UDP or the Datagram Congestion Control Protocol (DCCP) [RFC4340], or partially reliable, like the Stream Control Transmission Protocol (SCTP) with the partial reliability extension [RFC3758], or QUIC with the unreliable datagram extension [RFC9221] ✨. Depending on how much redundancy you add and what the network is doing, there could be cases where it just becomes impossible to carry the traffic 💀. This gets dug into more in Section 3, where the "FEC above CC" case is assessed, and in Sections 4 and 5, where "FEC in CC" and "FEC below CC" are assessed, respectively 🫶
2.4. Scope of the Document Concerning Transport Multipath and Multistream Applications
so the application layer can be made of several streams sitting above FEC and transport-layer instances 🌸. The transport layer can use a multipath mechanism, and the different streams could take different paths between the sender and the receiver. A single-stream application can also use a multipath transport mechanism 🦋. This section spells out what's in scope for this document when it comes to multistream applications and multipath transport protocols 👑
The different combinations of multistream applications and multipath transport are these: (1) one application-layer stream as input packets above a combination of FEC and multipath (Mpath) transport layers (Figure 5), and (2) multiple application-layer streams as input packets above a combination of FEC and multipath (Mpath) or single path (Spath) transport layers (Figure 6). This document digs into cases I (in Section 3.7), II (in Section 4.6), and III (in Section 5.7), as illustrated in Figure 5. Cases IV, V, and VI of Figure 6 are about how multiple streams get managed by a single transport or FEC layer. That doesn't directly involve the interaction between FEC and the transport, so it's out of scope for this document 🙈
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 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 5: Transport Multipath and Single-Stream Applications - in
the Scope of the Document 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|
+-------------------+ +-----+ +-----+ +-----+ +-----+
Figure 6: Transport Single Path, Transport Multipath, and Multistream
Applications - out of the Scope of the Document2.5. Types of Coding
[RFC8406] is the go-to glossary for Network Coding concepts and constructs 📚. It identifies the following coding types (among many others) 💖:
- Block Coding: a 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 🧱
- Sliding Window Coding: a general class of coding techniques that rely on a sliding encoding window 🪟
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, and the distribution of erasure in the transmission channel. The FEC channel may let the client send info about whether it needs supplementary symbols, so the level of reliability can be adapted 🔧. Partial and full reliability could both be envisioned ✨
- Full reliability: the receiver may hold symbols until decoding of source symbols is possible. In particular, if the codec doesn't let a subset of the system be inverted, the receiver would have to wait for a certain minimum number of repair packets before it can recover all the source symbols ⏳
- Partial reliability: 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 affect memory requirements, the cost of encoding and decoding processes, and the network overhead 🧠
3. FEC above the Transport ✨
| source ^ source
| packets | packets
v |
+-------------+ +-------------+
|FEC | signaling|FEC |
| | recovered| |
| | symbols| |
| | <==| |
+-------------+ +-------------+
| source ^ ^ source
| and/or | sending | and/or
| repair | rate | repair
| symbols | (or window) | symbols
v | |
+-------------+ +-------------+
|Transport | network|Transport |
|(incl. CC) | information| |
| |network <==| |
| |packets | |
+-------------+==> +-------------+
SENDER RECEIVER
Figure 7: FEC above the TransportOkay so, Figure 7 is the picture of FEC sitting on top of the transport, bestie 🧚. Source packets come down from the app, the FEC layer makes repair symbols, and the transport (with its congestion control, CC 💅) decides how fast everything gets sent. The receiver gets the network info and sends back signaling and recovered symbols. Iconic layering, no cap 🎀.
The big perk here is that the FEC overhead doesn't add to congestion in the network, because the repair symbols get sent following the congestion window or rate that the CC mechanism sets. That can give a much better quality of experience for latency-sensitive stuff like Voice over IP (VoIP) or any not-fully reliable services 🦋✨.
BUT, and this is a big but 🙈, this approach requires that the transport protocol does not implement a fully reliable, in-order data transfer service (like TCP). QUIC with the unreliable datagram extension [RFC9221] is an example of a protocol where this matters 💜. If a partially reliable transport gets blocked and the plan is to fall back to a reliable transport, there's a real risk of bad interactions between transport-level reliability and coding schemes 💀. For reliable transfers, coding doesn't guarantee better performance. It mainly just reduces goodput 😭.
3.1. Fairness and Impact on Non-coded Flows
Adding coding within a flow doesn't change how coded and non-coded flows interact with each other 🌸. That interaction mostly depends on the congestion controls attached to each flow, so the drama is really between the CCs, not the coding 💅.
3.2. Congestion Control and Recovered Symbols
The congestion control mechanism sees network packets, and it might not be able to tell repair symbols apart from actual source ones 🙈. Telling them apart needs a transport protocol that gives you more than the services described in [RFC8095], like specifically indicating what information has been repaired 🔥. Adding coding at the application layer depends on what the app actually needs ✨. For real-time apps using an unreliable or partially reliable transport, this approach may cut down the number of losses the app perceives 🫶.
3.3. Interactions between Congestion Control and Coding Rates
The coding rate at the application layer mostly depends on the available rate or congestion window that the congestion control underneath hands over 👑. The coding rate could be adapted so you don't add overhead when the app's minimum required data rate isn't provided by the congestion control underneath 🌈. When CC lets you send faster than the app needs, adding coding can reduce packet losses and boost quality of experience, as long as you're using an unreliable or partially reliable transport 🦋.
3.4. On Useless Repair Symbols
The only case where adding useless repair symbols doesn't obviously tank goodput is when the application rate is limited, like VoIP traffic 🎀. Here, useless repair symbols only change how much data gets generated in the network. But extra data in the network can increase the likelihood of more delay and/or packet loss, which could set off a congestion control reaction that degrades goodput 😭💀.
3.5. On Partial Ordering at FEC Level
Regardless of the transport protocol, a FEC mechanism doesn't need a reordering mechanism if the application doesn't need one 🧚. BUT if the application needs in-order delivery of packets, then a reordering mechanism at the receiver is required 🔥.
3.6. On Partial Reliability at FEC Level
The application may require partial reliability 🌸. In that 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 affects which type of FEC and which type of codec can be used, as discussed in Section 2.5 💅.
3.7. On Multipath Transport and FEC Mechanism
Whether the transport protocol exploits multiple paths or not doesn't have an impact on the FEC mechanism 🦋. Multipath is not the FEC's problem, periodt 👑.
4. FEC within the Transport ✨
| source ^ source
| packets | packets
v |
+------------+ +------------+
| Transport | | Transport |
| | | |
| +---+ +--+ | signaling| +---+ +--+ |
| |FEC| |CC| | recovered| |FEC| |CC| |
| +---+ +--+ | symbols| +---+ +--+ |
| | <==| |
| |network network| |
| |packets information| |
+------------+ ==> <==+------------+
SENDER RECEIVER
Figure 8: FEC in the TransportFigure 8 shows FEC living inside the transport, right next to CC 🧚. The repair symbols get sent within whatever the congestion window or calculated rate allows, such as in [CTCP] 💖.
The upside is that it allows a joint optimization of CC and FEC 👑. The transmission of repair symbols doesn't add congestion in potentially congested networks, but it still helps repair lost packets (like tail losses) 🫶. That joint optimization is the key to stopping flows from eating the whole available capacity 🔥. The amount of repair traffic injected should not lead to congestion 🙅♀️. As denoted in [FEC-CONGESTION-CONTROL], an increase of the repair ratio should be done conjointly with a decrease of the source sending rate 🦋.
The downside is that it may need specific signaling and transport services that may not be described in [RFC8095] 😭. So development and maintenance may need specific effort at both the transport and the coding levels, and the design might get complex to suit different deployment needs 💀.
For reliable transfers, including redundancy reduces goodput for long transfers, but the amount of repair symbols can be adapted, e.g., depending on the congestion window size 🌸. There's a trade-off between 1) the capacity that could have been used by application data instead of source packets and 2) the benefits of transmitting repair symbols (e.g., unlocking the receive buffer if it's limiting) 💅. The coding ratio needs to be carefully designed ✨. For small files, sending repair symbols when there's no more data to transmit could help reduce the transfer time 🧚. Sending repair symbols can avoid the silence period between the last packet in the send buffer and 1) firing a retransmission of lost packets or 2) transmitting new packets 🎀.
Examples of the solution could be adding a given percentage of the congestion window or rate as supplementary symbols, or sending a fixed amount of repair symbols at a fixed rate 🌈. The redundancy flow can be decorrelated from the congestion control that manages source packets. A separate congestion control entity could be introduced to manage the amount of recovered symbols to transmit on the FEC channel 🦋. Those separate CC instances could be made to work together while adhering to priorities, as in coupled congestion control for RTP media [RFC8699] if all traffic can be assumed to take the same path, or otherwise with a multipath congestion window coupling mechanism as in Multipath TCP [RFC6356] 👑. Another option would be to use a lower-than-best-effort congestion control [RFC6297] for repair symbols 💜.
4.1. Fairness and Impact on Non-coded Flows
Specific interactions between congestion controls and coding schemes can be proposed (see Sections 4.2 and 4.3) 🌸. If no specific interaction is introduced, the coding scheme may hide congestion losses from the congestion controller, and the description of Section 5 may apply 🙈.
4.2. Interactions between Congestion Control and Coding Rates
The receiver can tell source packets and repair symbols apart 🫶. 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 use this info to tune its behavior 👑.
There's an important flexibility in the trade-off, inherent to coding, between (1) reducing goodput when useless repair symbols are sent and (2) helping recover from losses earlier than retransmissions would ✨. The receiver may tell the sender how many packets have been received or recovered 🧚. The sender may use this info 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 💅.
4.3. On Useless Repair Symbols
The sender may use the info from the receiver to reduce the number of useless repair symbols and improve goodput 🎀.
4.4. On Partial Ordering at FEC and/or Transport Level
The application may require in-order delivery of packets. In that case, both FEC and transport-layer mechanisms should guarantee that packets are delivered in order 🔥. If the application requests partial ordering, both the FEC and the transport could relax the constraints related to in-order delivery. Partial ordering affects both the congestion control and which type of FEC and type of codec can be used 🌈.
4.5. On Partial Reliability at FEC Level
The application may require partial reliability. The reliability offered by FEC may be enough with no retransmission required 🦋. This depends on app needs and the trade-off between latency and loss ✨. Partial reliability affects which type of FEC and which type of codec can be used, as discussed in Section 2.5 💜.
4.6. On Transport Multipath and Subpath FEC Coding Rate
The sender may adapt the coding rate of each of the single subpaths, whether or not the congestion control is coupled 🧚. There's an important flexibility in how the coding rate gets tuned depending on the characteristics of each subpath 👑🫶.
5. FEC below the Transport 🌊
okay so this is the picture for FEC sitting below the transport layer (but still above the link layer) 🦋
| source ^ source
| packets | packets
v |
+--------------+ +--------------+
|Transport | network|Transport |
|(including CC)| information| |
| | <==| |
+--------------+ +--------------+
| network packets ^ network packets
v |
+--------------+ +--------------+
| FEC |source | FEC |
| |and/or signaling| |
| |repair recovered| |
| |symbols symbols| |
| |==> <==| |
+--------------+ +--------------+
SENDER RECEIVER
Figure 9: FEC below the TransportFigure 9 shows FEC applied end to end below the transport layer but above the link layer 💖. Here's the tea: it's super common to apply FEC at the link layer on one or more of the links in the end-to-end path 🔗. Link-layer FEC adds to the total capacity a link exposes to upper layers, but the end-to-end sender and receiver might not see it at all if they're separated by more than one link. So that's out of scope for this doc 🙃. The same goes for FEC on top of a link layer when the link is known by configuration. In this setup, the repair symbols are invisible to the end-to-end congestion controller and can be sent on top of whatever congestion control allows 👀.
Okay, the redundancy part is where it gets spicy 🌶️. Adding redundancy adds traffic without boosting goodput, and it can cause fairness issues 😬. The effective bit rate ends up higher than the CC's computed fair share because of those repair symbols, and losses get hidden from the transport. That can be a problem for loss-based congestion detection, but it's not a problem for delay-based congestion detection ✨.
The upside is that this approach can give real performance gains when there are persistent transmission losses along the path 🍓. The downside? It can induce congestion in networks that are already congested 💀. So the coding ratio needs to be designed really carefully 🎀.
Some possible solutions: add a given percentage of the congestion window or rate as supplementary symbols, or send a fixed number of repair symbols at a fixed rate 🧁. The redundancy flow can be decorrelated from the congestion control that manages source packets. You could even introduce a separate congestion control entity to manage how many recovered symbols get sent on the FEC channel 🧚. Those separate congestion control instances could work together while respecting priorities, like coupled congestion control for RTP media [RFC8699] when all traffic can be assumed to take the same path. Otherwise, you could use a multipath congestion window coupling mechanism like the one in Multipath TCP [RFC6356]. Another option is to use a lower-than-best-effort congestion control [RFC6297] for repair symbols 🌈.
5.1. Fairness and Impact on Non-coded Flows
The coding scheme may hide congestion losses from the congestion controller, and that can drastically reduce the goodput of non-coded flows in some cases 😭. 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., using ECN. That can reduce the impact on the non-coded flows (see Section 5.2 and [TENTET]) 💜.
5.2. Congestion Control and Recovered Symbols
The congestion control may not know a coding scheme exists underneath it, so it may behave as if no coding scheme had been introduced 🙈. The only way for a coding channel to say "symbols were lost but we recovered them" is to use existing signaling that the congestion control already understands. For example, you can tell a TCP sender that a packet was received, yet congestion occurred, by using ECN signaling [TENTET] 🦋.
5.3. Interactions between Congestion Control and Coding Rates
The coding rate can be tuned based on the number of recovered symbols and the rate at which the sender transmits data 🌸. But if the coding scheme isn't aware of the congestion control implementation, it's hard for it to apply the relevant coding rate 😤.
5.4. On Useless Repair Symbols
Useless repair symbols only add load to the network and don't give the coded flow any actual gain 🗑️. Using feedback signaling, FEC mechanisms can measure the ratio between symbols that were actually used and symbols that were useless, then adjust the coding rate accordingly 📊.
5.5. On Partial Ordering at FEC Level with In-Order Delivery Transport
The transport above the FEC channel may support out-of-order delivery of packets, in which case reordering at the receiver may not be necessary 🌀. But if 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 😵💫.
5.6. On Partial Reliability at FEC Level
The transport or application layer above the FEC channel may only require partial reliability. FEC can end up providing an unnecessary service unless it knows the reliability requirements 🙄. Partial reliability also affects which type of FEC and codec can be used, as discussed in Section 2.5 ✨.
5.7. FEC Not Aware of Transport Multipath
The transport may use multiple paths without the FEC channel knowing about it 🛣️. If FEC does know that multiple paths are in use, it can be applied to all subflows as an aggregate, or to each subflow individually. If FEC doesn't know multiple paths are in use, it 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 make the coding rate inadequate for some of them 😬.
6. Research Recommendations and Questions 🔮
This section gives a short state-of-the-art overview of activities related to congestion control and coding 📚. The goal is to identify open research questions and help shape advice for evaluating coding mechanisms 💅.
6.1. Activities Related to Congestion Control and Coding
Here's how the activities map onto the organization of this document 🗺️:
For the FEC above transport case: [RFC8680]
For the FEC within transport case: [CODING-FOR-QUIC], [QUIC-FEC], and [RFC5109]
For the FEC below transport case: [NCTCP] and [TETRYS]
6.2. Open Research Questions
There's a general trade-off, built into the use of coding, between (1) reducing goodput when useless repair symbols are transmitted and (2) helping to recover from transmission and congestion losses ⚖️.
6.2.1. Parameter Derivation
There's a trade-off around how much redundancy to add, which depends on the transport-layer protocol and the application requirements 🎯.
[RFC8095] describes the mechanisms that existing IETF protocols such as TCP, SCTP, or RTP provide. [RFC8406] describes the variety of coding techniques. There are so many combinations that working out an optimum parameter derivation is very complex 🤯. It depends on application requirements and the deployment context.
Appendix C of [RFC8681] describes how to tune the parameters for a target use case. However, that discussion doesn't integrate congestion-controlled endpoints 🙃.
Research question 1: "Is there a way to dynamically adjust the codec characteristics depending on the transmission channel, the transport protocol, and application requirements?" 🧠
Research question 2: "Should we apply specific per-stream FEC mechanisms when multiple streams with different reliability needs are carried out?" 🌷
6.2.2. New Signaling Methods and Fairness
Recovering lost symbols may hide congestion losses from the congestion control. Being able to tell ACKed packets apart from rebuilt packets would help the sender adapt its sending rate accordingly 🎀. There are chances to make congestion control and coding schemes interact, which could improve quality of experience while still guaranteeing fairness with other flows 💖.
Some existing solutions already propose disambiguating ACKed packets from rebuilt packets [QUIC-FEC]. New signaling methods and FEC-recovery-aware congestion controls could also be proposed, which would allow the design of adaptive coding rates 🦋.
Research question 3: "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?" 😤
Research question 4: "If transport and FEC senders are collocated and close to the client, and FEC is applied only on the last mile, e.g., to ignore losses on a noisy wireless link, would this raise fairness issues?" 📡
Research question 5: "Should we propose a generic API to allow dynamic interactions between a transport protocol and a coding scheme? This should consider existing APIs between application and transport layers." 🔌
6.3. Recommendations and Advice for Evaluating Coding Mechanisms
Research Recommendation 1: "From a congestion control 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." 🚦
Research Recommendation 2: "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." 🗂️
Research Recommendation 3: "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 and 2) critically discuss the impact of hiding packet loss from the congestion control mechanism." 🫶
7. IANA Considerations 🎀
This document has no IANA actions. Nothing for IANA to do here, bestie 💅.
8. Security Considerations 🔐
This part is serious, so let's be real 😭. 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, an attacker may compromise FEC rate adaptation. Indeed, an attacker could either modify the values indicated by the client or drop signaling messages 🚨.
In the 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 💀.
9. Informative References ✨
Okay bestie, this is the reading list 📚 These are the informative references, so they're here for context and backup, not rules. Every paper, draft, and RFC the doc leaned on lives here, with all the details. 🧾
[BEYONDJAIN]Ware, R., Mukerjee, M. K., Seshan, S., and J. Sherry, "Beyond Jain's Fairness Index: Setting the Bar For The Deployment of Congestion Control Algorithms", HotNets '19: Proceedings of the 18th ACM Workshop on Hot Topics in Networks, DOI 10.1145/3365609.3365855, November 2019,<https://doi.org/10.1145/3365609.3365855>.[CODING-FOR-QUIC]Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding for QUIC", Work in Progress, Internet-Draft, draft-swett-nwcrg-coding-for-quic-04, 9 March 2020,<https://datatracker.ietf.org/doc/html/draft-swett-nwcrg-coding-for-quic-04>.[CTCP]Kim, M., Cloud, J., ParandehGheibi, A., Urbina, L., Fouli, K., Leith, D., and M. Medard, "Network Coded TCP (CTCP)", arXiv: 1212.2291v3, DOI 10.48550/arXiv.1212.2291, April 2013,<https://doi.org/10.48550/arXiv.1212.2291>.[FEC-CONGESTION-CONTROL]Singh, V., Nagy, M., Ott, J., and L. Eggert, "Congestion Control Using FEC for Conversational Media", Work in Progress, Internet-Draft, draft-singh-rmcat-adaptive-fec-03, 20 March 2016,<https://datatracker.ietf.org/doc/html/draft-singh-rmcat-adaptive-fec-03>.[FLOW-RATE-FAIRNESS]Briscoe, B., "Flow Rate Fairness: Dismantling a Religion", Work in Progress, Internet-Draft, draft-briscoe-tsvarea-fair-02, 11 July 2007,<https://datatracker.ietf.org/doc/html/draft-briscoe-tsvarea-fair-02>.[NCTCP]Sundararajan, J., Shah, D., Médard, M., Jakubczak, S., Mitzenmacher, M., and J. Barros, "Network Coding Meets TCP: Theory and Implementation", Proceedings of the IEEE (Volume: 99, Issue: 3), DOI 10.1109/JPROC.2010.2093850, March 2011,<https://doi.org/10.1109/JPROC.2010.2093850>.[QUIC-FEC]Michel, F., De Coninck, Q., and O. Bonaventure, "QUIC-FEC: Bringing the benefits of Forward Erasure Correction to QUIC", DOI 10.23919/IFIPNetworking.2019.8816838, May 2019,<https://doi.org/10.23919/IFIPNetworking.2019.8816838>.[RFC3168]Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001,<https://www.rfc-editor.org/info/rfc3168>.[RFC3758]Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004,<https://www.rfc-editor.org/info/rfc3758>.[RFC4340]Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006,<https://www.rfc-editor.org/info/rfc4340>.[RFC5109]Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007,<https://www.rfc-editor.org/info/rfc5109>.[RFC5681]Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,<https://www.rfc-editor.org/info/rfc5681>.[RFC6297]Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 2011,<https://www.rfc-editor.org/info/rfc6297>.[RFC6356]Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011,<https://www.rfc-editor.org/info/rfc6356>.[RFC8095]Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017,<https://www.rfc-editor.org/info/rfc8095>.[RFC8406]Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and S. Sivakumar, "Taxonomy of Coding Techniques for Efficient Network Communications", RFC 8406, DOI 10.17487/RFC8406, June 2018,<https://www.rfc-editor.org/info/rfc8406>.[RFC8680]Roca, V. and A. Begen, "Forward Error Correction (FEC) Framework Extension to Sliding Window Codes", RFC 8680, DOI 10.17487/RFC8680, January 2020,<https://www.rfc-editor.org/info/rfc8680>.[RFC8681]Roca, V. and B. Teibi, "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME", RFC 8681, DOI 10.17487/RFC8681, January 2020,<https://www.rfc-editor.org/info/rfc8681>.[RFC8699]Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, January 2020,<https://www.rfc-editor.org/info/rfc8699>.[RFC9221]Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, DOI 10.17487/RFC9221, March 2022,<https://www.rfc-editor.org/info/rfc9221>.[TENTET]Lochin, E., "On the joint use of TCP and Network Coding", NWCRG Session, IETF 100, November 2017,<https://datatracker.ietf.org/meeting/100/materials/slides-100-nwcrg-07-lochin-on-the-joint-use-of-tcp-and-network-coding-00>.[TETRYS]Detchart, J., Lochin, E., Lacan, J., and V. Roca, "Tetrys, an On-the-Fly Network Coding protocol", Work in Progress, Internet-Draft, draft-detchart-nwcrg-tetrys-08, 17 October 2021,<https://datatracker.ietf.org/doc/html/draft-detchart-nwcrg-tetrys-08>.
Acknowledgements 💖
Huge thank-you to Spencer Dawkins, Dave Oran, Carsten Bormann, Vincent Roca, and Marie-Jose Montpetit for their useful comments that helped make the document better. You all are literal legends 🫶🌈
Authors' Addresses 🎀
- Nicolas Kuhn, CNES, Email:
nicolas.kuhn.ietf@gmail.com💜 - Emmanuel Lochin, ENAC, Email:
emmanuel.lochin@enac.fr🦋 - François Michel, UCLouvain, Email:
francois.michel@uclouvain.be🌸 - Michael Welzl, University of Oslo, Email:
michawe@ifi.uio.no✨
📦 where this page comes from
- ietf: rfc9265 2022-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms