idnits 2.17.1 draft-irtf-nwcrg-coding-and-congestion-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 423 has weird spacing: '...packets inf...' -- The document date (February 22, 2021) is 1158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-detchart-nwcrg-tetrys-06 == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NWCRG N. Kuhn 3 Internet-Draft CNES 4 Intended status: Informational E. Lochin 5 Expires: August 26, 2021 ENAC 6 F. Michel 7 UCLouvain 8 M. Welzl 9 University of Oslo 10 February 22, 2021 12 Coding and congestion control in transport 13 draft-irtf-nwcrg-coding-and-congestion-06 15 Abstract 17 Forward Erasure Correction (FEC) is a reliability mechanism that is 18 distinct and separate from the retransmission logic in reliable 19 transfer protocols such as TCP. Using FEC coding can help deal with 20 losses at the end of transfers or with networks having non-congestion 21 losses. However, FEC coding mechanisms should not hide congestion 22 signals. This memo offers a discussion of how FEC coding and 23 congestion control can coexist. Another objective is to encourage 24 the research community to also consider congestion control aspects 25 when proposing and comparing FEC coding solutions in communication 26 systems. 28 This document is the product of the Coding for Efficient Network 29 Communications Research Group (NWCRG). The scope of the document is 30 end-to-end communications: FEC coding for tunnels is out-of-the scope 31 of the document. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 26, 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. Separate channels, separate entities . . . . . . . . . . 4 70 2.2. Relation between transport layer and application 71 requirements . . . . . . . . . . . . . . . . . . . . . . 6 72 2.3. Fairness, a policy concern . . . . . . . . . . . . . . . 7 73 3. FEC above the transport . . . . . . . . . . . . . . . . . . . 7 74 3.1. Fairness and impact on non-coded flows . . . . . . . . . 9 75 3.2. Congestion control and recovered symbols . . . . . . . . 9 76 3.3. Interactions between congestion control and coding rates 9 77 3.4. On the useless repair symbols . . . . . . . . . . . . . . 9 78 3.5. On partial ordering . . . . . . . . . . . . . . . . . . . 9 79 3.6. On partial reliability . . . . . . . . . . . . . . . . . 9 80 3.7. On multipath transport . . . . . . . . . . . . . . . . . 10 81 4. FEC within the transport . . . . . . . . . . . . . . . . . . 10 82 4.1. Fairness and impact on non-coded flows . . . . . . . . . 11 83 4.2. Congestion control and recovered symbols . . . . . . . . 11 84 4.3. Interactions between congestion control and coding rates 11 85 4.4. On the useless repair symbols . . . . . . . . . . . . . . 11 86 4.5. On partial ordering . . . . . . . . . . . . . . . . . . . 11 87 4.6. On partial reliability . . . . . . . . . . . . . . . . . 12 88 4.7. On transport multipath . . . . . . . . . . . . . . . . . 12 89 5. FEC below the transport . . . . . . . . . . . . . . . . . . . 12 90 5.1. Fairness and impact on non-coded flows . . . . . . . . . 13 91 5.2. Congestion control and recovered symbols . . . . . . . . 13 92 5.3. Interactions between congestion control and coding rates 14 93 5.4. On the useless repair symbols . . . . . . . . . . . . . . 14 94 5.5. On partial ordering . . . . . . . . . . . . . . . . . . . 14 95 5.6. On partial reliability . . . . . . . . . . . . . . . . . 14 96 5.7. On transport multipath . . . . . . . . . . . . . . . . . 14 97 6. Open research questions . . . . . . . . . . . . . . . . . . . 14 98 6.1. Activities related to congestion control and coding . . . 15 99 6.2. Open research questions . . . . . . . . . . . . . . . . . 15 100 6.3. Advice for evaluating coding mechanisms . . . . . . . . . 15 101 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 104 10. Informative References . . . . . . . . . . . . . . . . . . . 16 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 107 1. Introduction 109 There are cases where deploying FEC coding improves the performance 110 of a transmission. As an example, it may take time for the sender to 111 detect transfer tail losses (losses that occur at the end of a 112 transfer, where e.g., TCP obtains no more ACKs to repair the loss via 113 retransmission quickly). Allowing the receiver to recover such 114 losses instead of having to rely on a retransmission could improve 115 the experience of applications using short flows. Another example is 116 a network where non-congestion losses are persistent and prevent a 117 sender from exploiting the link capacity. 119 Coding is a reliability mechanism that is distinct and separate from 120 the loss detection of congestion controls. [RFC5681] defines TCP as 121 a loss-based congestion control; since FEC coding repairs such 122 losses, blindly applying it may easily lead to an implementation that 123 also hides a congestion signal from the sender. It is important to 124 ensure that such information hiding does not occur. 126 FEC coding and congestion control can be seen as two separate 127 channels. In practice, implementations may mix the signals that are 128 exchanged on these channels. This memo offers a discussion of how 129 FEC coding and congestion control coexist. Another objective is to 130 encourage the research community also to consider congestion control 131 aspects when proposing and comparing FEC coding solutions in 132 communication systems. This document does not aim at proposing 133 guidelines for characterizing FEC coding solutions. 135 We consider an end-to-end unicast data transfer with FEC coding at 136 the application (above the transport), within the transport or 137 directly below the transport. The typical application scenario 138 considered in the current version of the document is a client 139 browsing the web or watching a live video. 141 This document represents the collaborative work and consensus of the 142 Coding for Efficient Network Communications Research Group (NWCRG); 143 it is not an IETF product and is not a standard. The document 144 follows the terminology proposed in the taxonomy document [RFC8406]. 146 2. Context 148 2.1. Separate channels, separate entities 150 Figure 1 presents the notations that will be used in this document 151 and introduces the Congestion Control (CC) and Forward Erasure 152 Correction (FEC) channels. The Congestion Control channel carries 153 source packets from a sender to a receiver, and packets signaling 154 information about the network (number of packets received vs. lost, 155 ECN marks, etc.) from the receiver to the sender. The Forward 156 Erasure Correction channel carries repair symbols (from the sender to 157 the receiver) and information from the receiver to the sender (e.g. 158 signaling which packets have been repaired, loss rate prior and/or 159 after decoding, etc.). There are cases where these channels are not 160 separated. 162 SENDER RECEIVER 164 +------+ +------+ 165 | | ----- source packets ---->| | 166 | CC | | CC | 167 | | <--- network information ---| | 168 +------+ +------+ 170 +------+ +------+ 171 | | ----- repair symbols ---->| | 172 | FEC | | FEC | 173 | | <--- info: repaired symbols --| | 174 +------+ +------+ 176 Figure 1: Notations and separate channels 178 Inside a host, the CC and FEC entities can be regarded as 179 conceptually separate: 181 | ^ | ^ 182 | source | coding |packets | sending 183 | packets | rate |requirements | rate (or 184 v | v | window) 185 +---------------+source +-----------------+ 186 | FEC |and/or | CC | 187 | |repair | |source 188 | |symbols | |packets 189 +---------------+==> +-----------------+==> 190 ^ ^ 191 | signaling about | network 192 | losses and/or | information 193 | repaired symbols 195 Figure 2: Separate entities (sender-side) 197 | | 198 | source and/or | packets 199 | repair symbols | 200 v v 201 +---------------+ +-----------------+ 202 | FEC |signaling | CC | 203 | |repaired | |network 204 | |symbols | |information 205 +---------------+==> +-----------------+==> 207 Figure 3: Separate entities (receiver-side) 209 Figure 2 and Figure 3 provide more details than Figure 1. Some 210 elements are introduced: 212 o 'network information' (input control plane for the transport 213 including CC): refers not only to the network information that is 214 explicitly signaled from the receiver, but all the information a 215 congestion control obtains from a network (e.g., TCP can estimate 216 the latency and the available capacity at the bottleneck). 218 o 'requirements' (input control plane for the transport including 219 CC): refers to application requirements such as upper/lower rate 220 bounds, periods of quiescence, or a priority. 222 o 'sending rate (or window)' (output control plane for the transport 223 including CC): refers to the rate at which a congestion control 224 decides to transmit packets based on 'network information'. 226 o 'signaling repaired symbols' (input control plane for the FEC): 227 refers to the information a FEC sender can obtain from a FEC 228 receiver about the performance of the FEC solution as seen by the 229 receiver. 231 o 'coding rate' (output control plane for the FEC): refers to the 232 coding rate that is used by the FEC solutioni (i.e. proportion of 233 transmitted symbols that carry useful data). 235 o 'source and/or repair symbols' (data plane for both the FEC and 236 the CC): refers to the data that is transmitted. The sender can 237 decide to send source symbols only (meaning that the coding rate 238 is 0), repair symbols only (if the solution decides not to send 239 the original source packets) or a mix of both. 241 The inputs to FEC (incoming data packets without repair symbols, and 242 signaling from the receiver about losses and/or repaired symbols) are 243 distinct from the inputs to CC. The latter calculates a sending rate 244 or window from network information, and it takes the packet to send 245 as input, sometimes along with application requirements such as 246 upper/lower rate bounds, periods of quiescence, or a priority. It is 247 not clear that the ACK signals feeding into a congestion control 248 algorithm are useful to FEC in their raw form, and vice versa - 249 information about repaired blocks may be quite irrelevant to a CC 250 algorithm. 252 2.2. Relation between transport layer and application requirements 254 The choice of the adequate transport layer may be related to 255 application requirements and the services offered by a transport 256 protocol [RFC8095]: 258 o In the case of an unreliable data transfer, the transport layer 259 may provide a non-reliable transport service (e.g. UDP or DCCP 260 [RFC4340] or a partially reliable transport protocol such as SCTP 261 with partial reliability [RFC3758]) or QUIC with the unreliable 262 datagram extension [I-D.ietf-quic-datagram]. Depending on the 263 amount of redundancy and network conditions, there could be cases 264 where it becomes impossible to carry traffic. 266 o In the case of a reliable data transfer, the transport layer may 267 implement a retransmission mechanism to guarantee the reliability 268 of the file transfer (e.g. TCP). Depending on how the FEC and CC 269 functions are scheduled (FEC above CC, FEC in CC, FEC below CC), 270 the impact of reliable transport on the FEC reliability mechanisms 271 is different. 273 The application layer may be composed of several streams above each 274 FEC and transport layers instances. The different streams could 275 exploit different paths between the sender and the receiver or not. 277 The document considers one application layer stream as input packets 278 above a combination of FEC and transport layers. The case of 279 multiple application level streams above multiple FEC and transport 280 layers instances is currently out of the scope of the document and 281 not further described. 283 2.3. Fairness, a policy concern 285 End users may share a bottleneck that may not be ruled by a quality 286 of service mechanism that should ensure the fairness between the 287 different flows. In this case, the share of available capacity 288 between single flows can help assess when one flow starves the other. 290 As one example, for residential accesses, the data-rate can be 291 guaranteed for the customer premises equipment, but not necessarily 292 for the end user. The quality of service that guarantees fairness 293 between the different clients can be seen as a policy concern 294 [I-D.briscoe-tsvarea-fair]. 296 While past efforts have focused on achieving fairness, quantifying 297 and limiting harm caused by new algorithm (or algorithms with coding) 298 is more practical [BEYONDJAIN]. This document considers fairness as 299 the impact of the addition of coded flows on non-coded flows when 300 they share the same bottleneck. 302 This document assumes that the non-coded flows respond to congestion 303 signals from the network. This document does not aim at contributing 304 to the definition of fairness at a wider scale. 306 3. FEC above the transport 307 | source ^ source 308 | packets | packets 309 v | 310 +-------------+ +-------------+ 311 |FEC | signaling|FEC | 312 | | repaired| | 313 | | symbols| | 314 | | <==| | 315 +-------------+ +-------------+ 316 | source ^ ^ source 317 | and/or | sending | and/or 318 | repair | rate | repair 319 | symbols | (or window) | symbols 320 v | | 321 +-------------+ +-------------+ 322 |Transport |source network|Transport | 323 |(incl. CC) |and/or information| | 324 | |repair <==| | 325 | |packets | | 326 +-------------+==> +-------------+ 328 SENDER RECEIVER 330 Figure 4: FEC above the transport 332 Figure 4 present an architecture where FEC operates on top of the 333 transport. 335 The advantage of this approach is that the FEC overhead does not 336 contribute to congestion in the network. When congestion control is 337 implemented at the transport layer, the repair symbols are sent 338 following the congestion window. This approach can result in 339 improved quality of experience for latency sensitive applications 340 such as VoIP or any not-fully reliable services. 342 This approach requires that the transport protocol does not implement 343 a fully reliable data transfer service (e.g., based on lost packet 344 retransmission). QUIC with unreliable datagram extension 345 [I-D.ietf-quic-datagram] is an example of a protocol for which this 346 approach is relevant. In cases where QUIC traffic is blocked and a 347 fallback to TCP mechanism is proposed, there is a risk for bad 348 interactions between the TCP reliability mechanisms and coding 349 schemes. For reliable transfers, coding usage does not guarantee 350 better performance and would mainly reduce goodput for large file 351 transfers. Moreover, the recovered symbols may not be known to the 352 transport. 354 3.1. Fairness and impact on non-coded flows 356 The addition of coding within the flow does not impact on the 357 interaction between coded and non-coded flows. This interaction 358 would mainly depend on the congestion controls embedded in each host. 360 3.2. Congestion control and recovered symbols 362 The congestion control may not be able to differentiate repair 363 symbols from actual source packets. The relevance of adding coding 364 at the application layer is related to the needs of the application. 365 For real-time applications, this approach may reduce the number of 366 retransmissions. The usage of a non-reliable transport is more 367 adequate in this case. 369 3.3. Interactions between congestion control and coding rates 371 The coding rate applied at the application layer mainly depends on 372 the available capacity given by the congestion control underneath. 373 The coding rate could be adapted to avoid adding overhead when the 374 minimum required data rate of the application is not provided by the 375 congestion control underneath. When it is not the case, coding would 376 reduce packet losses and improve the quality of experience. 378 3.4. On the useless repair symbols 380 The discussion depends on application needs. The only case where 381 adding useless repair symbols does not obviously result in reduced 382 goodput is when the application needs a limited amount of goodput 383 (e.g., VoIP traffic). In this case, the useless repair symbols would 384 only impact the amount of data generated in the network. Extra data 385 in the network can, however, increase the likelihood of increasing 386 delay and/or packet loss, which could provoke a congestion control 387 reaction that would degrade goodput. 389 3.5. On partial ordering 391 Whether the transport protocol includes a reordering mechanism or 392 not, the FEC mechanism does not require to implement a reordering 393 mechanism if the application does not require it. However, if the 394 application requires in-order delivery of packets, a reordering 395 mechanism at the client is required. 397 3.6. On partial reliability 399 The application may require partial reliability only. In this case, 400 the coding rates of the FEC mechanisms could be adapted accordingly 401 based on inputs of the application and the trade-off between latency 402 and packet loss. Partial reliability impacts the type of FEC and 403 type of codec that can be used. 405 3.7. On multipath transport 407 Whether the transport protocol exploits multiple paths or not does 408 not have an impact on the FEC mechanism. 410 4. FEC within the transport 412 | source | sending ^ source 413 | packets | rate | packets 414 v v | 415 +------------+ +------------+ 416 | Transport | | Transport | 417 | | | | 418 | +---+ +--+ | signaling| +---+ +--+ | 419 | |FEC| |CC| | repaired| |FEC| |CC| | 420 | +---+ +--+ |source symbols| +---+ +--+ | 421 | |and/or <==| | 422 | |repair network| | 423 | |packets information| | 424 +------------+ ==> <==+------------+ 426 SENDER RECEIVER 428 Figure 5: FEC in the transport 430 Figure 5 presents an architecture where FEC operates within the 431 transport. The repair symbols are sent within what the congestion 432 window allows, such as in [CTCP]. 434 The advantage of this approach allows a joint optimization of the CC 435 and the FEC. Moreover, the transmission of repair symbols does not 436 add congestion in potentially congested networks but helps repair 437 lost packets (such as tail losses). 439 For reliable transfers, including redundancy reduces goodput for 440 large file transfers but the amount of repair symbols can be adapted, 441 e.g. depending on the congestion window size. There is a trade-off 442 between1) the capacity that could have been exploited to transmit 443 source packets and 2) the benefits brought out by transmitting repair 444 symbols (e.g. unlocking the receive buffer if this is limiting). The 445 coding ratio needs to be carefully designed. For small files, 446 sending repair symbols when there is no more data to transmit could 447 help to reduce the transfer time. In general, sending repair symbols 448 could avoid a silent period between the transmission of the last 449 packet in the send buffer and 1) firing the retransmission of lost 450 packets, or 2) the transmission of new packets. 452 4.1. Fairness and impact on non-coded flows 454 The addition of coding within the flow may impact the congestion 455 control mechanism and hide congestion losses. Specific interaction 456 between congestion controls and coding schemes can be proposed (see 457 Section 4.2, Section 4.3 and Section 4.4). If no specific 458 interaction is introduced, the coding scheme may hide congestion 459 losses from the congestion controller and the description of 460 Section 5 may apply. 462 4.2. Congestion control and recovered symbols 464 The receiver can differentiate source packets and repair symbols. 465 The receiver may indicate both the number of source packets received 466 and repair symbols that were actually useful in the recovery process 467 of packets. 469 4.3. Interactions between congestion control and coding rates 471 There is an important flexibility in the trade-off, inherent to the 472 use of coding, between (1) reducing goodput when useless repair 473 symbols are transmitted and (2) helping to recover sooner from 474 transmission and congestion losses. The receiver may indicate to the 475 sender the number of packets that have been received or recovered. 476 The sender may exploit this information to tune the coding ratio. As 477 one example of flexibility of this case, coupling an increased 478 transmission rate with an increasing or decreasing coding rate could 479 be envisioned. A server may use an decreasing coding rate as a probe 480 of the channel capacity and adapt the congestion control transmission 481 rate. 483 4.4. On the useless repair symbols 485 The sender may exploit the information given by the receiver to 486 reduce the number of useless repair symbols and the resulting goodput 487 reduction. 489 4.5. On partial ordering 491 The application may require in-order delivery of packets. In this 492 case, both FEC and transport layer mechanisms should guarantee that 493 packets are delivered in order. If partial ordering is requested by 494 the application, both the FEC and transport could release the 495 constraints related to in-order delivery of packets : reordering 496 mechanisms at the receiver may not be necessary. 498 4.6. On partial reliability 500 The application may require partial reliability. In this case, the 501 transport and FEC mechanisms could be conjointly designed. As one 502 example, the reliability offered by FEC may be sufficient and no 503 retransmission required. This depends on application requirements 504 and the trade-off between latency and loss. Partial reliability 505 impacts the type of FEC and type of codec that can be used. 507 4.7. On transport multipath 509 The sender may adapt the coding rate of each of the single subpaths, 510 whether the congestion control is coupled or not. There is an 511 important flexibility on how the coding rate is tuned depending on 512 the characteristics of each subpath. 514 5. FEC below the transport 516 | source | sending rate ^ source 517 | packets | (or window) | packets 518 v v | 519 +--------------+ +--------------+ 520 |Transport | network|Transport | 521 |(including CC)| information| | 522 | | <==| | 523 +--------------+ +--------------+ 524 | source packets ^ source packets 525 v | 526 +--------------+ +--------------+ 527 | FEC |source | FEC | 528 | |and/or signaling| | 529 | |repair repaired| | 530 | |symbols symbols| | 531 | |==> <==| | 532 +--------------+ +--------------+ 534 SENDER RECEIVER 536 Figure 6: FEC below the transport 538 Figure 6 presents an architecture where FEC is applied end-to-end 539 below the transport layer, but above the link layer. Note that it is 540 common to apply FEC at the link layer, in which it contributes to the 541 total capacity that a link exposes to upper layers. This application 542 of FEC is out of scope of this document. In the scenario considered 543 here, the repair symbols are sent on top of what is allowed by the 544 congestion control. 546 Including redundancy adds traffic without reducing goodput but leads 547 to potential fairness issues. The effective bitrate is indeed higher 548 than the CC's computed fair share due to the sending of repair 549 symbols and the losses are hidden from the transport. This may cause 550 a problem for loss-based congestion detection, but it is not a 551 problem for delay-based congestion detection. 553 The advantage of this approach is that it can result in performance 554 gains when there are persistent transmission losses along the path. 556 The drawback of this approach is that it can induce congestion in 557 already congested networks. The coding ratio needs to be carefully 558 designed. 560 Examples of the solution could be adding a given percentage of the 561 congestion window as supplementary symbols or sending a given amount 562 of repair symbols at a given rate. The redundancy flow can be 563 decorrelated from the congestion control that manages source packets: 564 a separate congestion control entity could be introduced to manage 565 the amount of repaired packets to transmit on the FEC channel. The 566 separate congestion control instances could be made to work together 567 while adhering to priorities, as in coupled congestion control for 568 RTP media [RFC8699] in case all traffic can be assumed to take the 569 same path, or otherwise with a multipath congestion window coupling 570 mechanism as in Multipath TCP [RFC6356]. Another possibility would 571 be to exploit a lower than best-effort congestion control [RFC6297] 572 for repair symbols. 574 5.1. Fairness and impact on non-coded flows 576 The coding scheme may hide congestion losses from the congestion 577 controller. There are cases where this can drastically reduce the 578 goodput of non-coded flows. Depending on the congestion control, it 579 may be possible to signal to the congestion control mechanism that 580 there was congestion (loss) even when a packet has been recovered, 581 e.g. using ECN, to reduce the impact on the non-coded flows (see 582 Section 5.2 and [TENTET]). 584 5.2. Congestion control and recovered symbols 586 The congestion control may not know what is going on in the network 587 underneath and whether a coding scheme is introduced or not. The 588 congestion control may behave as if no coding scheme is introduced. 589 The only way for a coding channel to indicate that symbols have been 590 recovered is to exploit existing signaling that is understood by the 591 congestion control mechanism. An example would be to indicate to a 592 TCP sender that a packet has been recovered (i.e., congestion has 593 occurred), by using ECN signaling [TENTET]. 595 5.3. Interactions between congestion control and coding rates 597 The coding rate can be tuned depending on the number of recovered 598 symbols and the rate at which the sender transmits data. The coding 599 scheme is not aware of the congestion control implementation, making 600 it hard for the coding scheme to apply the relevant coding rate. 602 5.4. On the useless repair symbols 604 The useless repair symbols only impact the load of the network 605 without actual gain for the coded flow. That being said, using 606 feedback signaling, FEC mechanisms can measure the actually used 607 symbols and adjust the coding rate. 609 5.5. On partial ordering 611 The transport above the FEC channel may support out-of-order delivery 612 of packets: reordering mechanisms at the receiver may not be 613 necessary. In cases where the transport requires in-order delivery, 614 the FEC channel may need to implement a reordering mechanism 615 otherwise there may be spurious retransmissions at the transport 616 level. 618 5.6. On partial reliability 620 The transport or application layer above the FEC channel may require 621 partial reliability only. In this case, FEC may provide an 622 unnecessary service if it is not aware of the reliability 623 requirements. Partial reliability impacts the type of FEC and type 624 of codec that can be used. 626 5.7. On transport multipath 628 The transport may exploit multiple paths without the FEC channel 629 being aware of it. This depends on whether FEC is applied to all 630 subflows or each of the subflows individually. When FEC is applied 631 to all the flows, there is a risk for the coding rate to be 632 inadequate for the characteristics of the individual paths. 634 6. Open research questions 636 This section provides a short state-of-the art overview of activities 637 related to congestion control and coding. The objective is to 638 identify open research questions and contribute to advice when 639 evaluating coding mechanisms. 641 6.1. Activities related to congestion control and coding 643 We map activities related to congestion control and coding with the 644 organization presented in this document: 646 o For the FEC above transport case: [RFC8680]. 648 o For the FEC within transport case: 649 [I-D.swett-nwcrg-coding-for-quic], [QUIC-FEC], [RFC5109]. 651 o For the FEC below transport case: [NCTCP], 652 [I-D.detchart-nwcrg-tetrys]. 654 6.2. Open research questions 656 There is a general trade-off, inherent to the use of coding, between 657 (1) reducing goodput when useless repair symbols are transmitted and 658 (2) helping to recover from transmission and congestion losses. 660 For the FEC above transport case, there is a trade-off related to the 661 amount of redundancy to add, as a function of the transport layer 662 protocol and application requirements. 664 For the FEC within transport case, recovering lost symbols may hide 665 congestion losses to the congestion control. Some existing solutions 666 already propose to disambiguate acked packets from rebuilt packets 667 [QUIC-FEC]. New signaling methods and FEC-recovery-aware congestion 668 controls could be proposed. 670 For the FEC below transport case, there are opportunities for 671 introducing interaction between congestion control and coding schemes 672 to improve the quality of experience while guaranteeing fairness with 673 other flows. New signaling methods and FEC-recovery-aware congestion 674 controls could be proposed. An open question also resides in the 675 relevance of FEC when there are multiple streams that exploit the FEC 676 channel. 678 6.3. Advice for evaluating coding mechanisms 680 The contribution to research questions should be mapped following the 681 organization of this document. Otherwise, this may lead to wrong 682 assumptions on the validity of the proposal and wrong ideas about the 683 relevance of coding for a given use case. 685 The discussion provided in this document aims at encouraging the 686 research community to also consider congestion control aspects when 687 proposing and comparing FEC coding solutions in communication 688 systems. As one example, this draft proposes discussions on the 689 impact of the proposed FEC solution on congestion control, especially 690 loss-based congestion control mechanisms. When a research work aims 691 at improving throughput by hiding the packet loss signal from 692 congestion control, the authors should 1) discuss the advantages of 693 using the proposed FEC solution compared to replacing the congestion 694 control by one that ignores a portion of the encountered losses, 2) 695 critically discuss the impact of hiding packet loss from the 696 congestion control mechanism. 698 7. Acknowledgements 700 Many thanks to Spencer Dawkins, Dave Oran, Carsten Bormann, Vincent 701 Roca and Marie-Jose Montpetit for their useful comments that helped 702 improve the document. 704 8. IANA Considerations 706 This memo includes no request to IANA. 708 9. Security Considerations 710 FEC and CC schemes can contribute to DoS attacks. This is not 711 specific to this document. 713 In case of FEC below the transport, the aggregate rate of source and 714 repair packets may exceed the rate at which a congestion control 715 mechanism allows an application to send. This could result in an 716 application obtaining more than its fair share of the network 717 capacity. 719 10. Informative References 721 [BEYONDJAIN] 722 Ware (et al.), R., "Beyond Jain's Fairness Index: Setting 723 the Bar For The Deployment of Congestion Control 724 Algorithms", HotNets '19 10.1145/3365609.3365855, 2019. 726 [CTCP] Kim (et al.), M., "Network Coded TCP (CTCP)", 727 arXiv 1212.2291v3, 2013. 729 [I-D.briscoe-tsvarea-fair] 730 Briscoe, B., "Flow Rate Fairness: Dismantling a Religion", 731 draft-briscoe-tsvarea-fair-02 (work in progress), July 732 2007. 734 [I-D.detchart-nwcrg-tetrys] 735 Detchart, J., Lochin, E., Lacan, J., and V. Roca, "Tetrys, 736 an On-the-Fly Network Coding protocol", draft-detchart- 737 nwcrg-tetrys-06 (work in progress), December 2020. 739 [I-D.ietf-quic-datagram] 740 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 741 Datagram Extension to QUIC", draft-ietf-quic-datagram-01 742 (work in progress), August 2020. 744 [I-D.swett-nwcrg-coding-for-quic] 745 Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding 746 for QUIC", draft-swett-nwcrg-coding-for-quic-04 (work in 747 progress), March 2020. 749 [NCTCP] Sundararajan (et al.), J., "Network Coding Meets TCP: 750 Theory and Implementation", IEEE 751 INFOCOM 10.1109/JPROC.2010.2093850, 2009. 753 [QUIC-FEC] 754 Michel (et al.), F., "QUIC-FEC: Bringing the benefits of 755 Forward Erasure Correction to QUIC", IFIP 756 Networking 10.23919/IFIPNetworking.2019.8816838, 2019. 758 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 759 Conrad, "Stream Control Transmission Protocol (SCTP) 760 Partial Reliability Extension", RFC 3758, 761 DOI 10.17487/RFC3758, May 2004, 762 . 764 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 765 Congestion Control Protocol (DCCP)", RFC 4340, 766 DOI 10.17487/RFC4340, March 2006, 767 . 769 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 770 Correction", RFC 5109, DOI 10.17487/RFC5109, December 771 2007, . 773 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 774 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 775 . 777 [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort 778 Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 779 2011, . 781 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 782 Congestion Control for Multipath Transport Protocols", 783 RFC 6356, DOI 10.17487/RFC6356, October 2011, 784 . 786 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 787 Ed., "Services Provided by IETF Transport Protocols and 788 Congestion Control Mechanisms", RFC 8095, 789 DOI 10.17487/RFC8095, March 2017, 790 . 792 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 793 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 794 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 795 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 796 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 797 June 2018, . 799 [RFC8680] Roca, V. and A. Begen, "Forward Error Correction (FEC) 800 Framework Extension to Sliding Window Codes", RFC 8680, 801 DOI 10.17487/RFC8680, January 2020, 802 . 804 [RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion 805 Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, 806 January 2020, . 808 [TENTET] Lochin, E., "On the joint use of TCP and Network Coding", 809 NWCRG session IETF 100, 2017. 811 Authors' Addresses 813 Nicolas Kuhn 814 CNES 816 Email: nicolas.kuhn@cnes.fr 818 Emmanuel Lochin 819 ENAC 821 Email: emmanuel.lochin@enac.fr 823 Francois Michel 824 UCLouvain 826 Email: francois.michel@uclouvain.be 827 Michael Welzl 828 University of Oslo 830 Email: michawe@ifi.uio.no