idnits 2.17.1 draft-irtf-nwcrg-coding-and-congestion-05.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 418 has weird spacing: '...packets inf...' -- The document date (February 15, 2021) is 1159 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 19, 2021 ENAC 6 F. Michel 7 UCLouvain 8 M. Welzl 9 University of Oslo 10 February 15, 2021 12 Coding and congestion control in transport 13 draft-irtf-nwcrg-coding-and-congestion-05 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 19, 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 potential information signaling which packets have 158 been repaired (from the receiver to the sender). There are cases 159 where these channels are not separated. 161 SENDER RECEIVER 163 +------+ +------+ 164 | | ----- source packets ---->| | 165 | CC | | CC | 166 | | <--- network information ---| | 167 +------+ +------+ 169 +------+ +------+ 170 | | ----- repair symbols ---->| | 171 | FEC | | FEC | 172 | | <--- info: repaired symbols --| | 173 +------+ +------+ 175 Figure 1: Notations and separate channels 177 Inside a host, the CC and FEC entities can be regarded as 178 conceptually separate: 180 | ^ | ^ 181 | source | coding |packets | sending 182 | packets | rate |requirements | rate (or 183 v | v | window) 184 +---------------+source +-----------------+ 185 | FEC |and/or | CC | 186 | |repair | |source 187 | |symbols | |packets 188 +---------------+==> +-----------------+==> 189 ^ ^ 190 | signaling about | network 191 | losses and/or | information 192 | repaired symbols 194 Figure 2: Separate entities (sender-side) 196 | | 197 | source and/or | packets 198 | repair symbols | 199 v v 200 +---------------+ +-----------------+ 201 | FEC |signaling | CC | 202 | |repaired | |network 203 | |symbols | |information 204 +---------------+==> +-----------------+==> 206 Figure 3: Separate entities (receiver-side) 208 Figure 2 and Figure 3 provide more details than Figure 1. Some 209 elements are introduced: 211 o 'network information' (input control plane for the transport 212 including CC): refers not only to the network information that is 213 explicitly signaled from the receiver, but all the information a 214 congestion control obtains from a network (e.g., TCP can estimate 215 the latency and the available capacity at the bottleneck). 217 o 'requirements' (input control plane for the transport including 218 CC): refers to application requirements such as upper/lower rate 219 bounds, periods of quiescence, or a priority. 221 o 'sending rate (or window)' (output control plane for the transport 222 including CC): refers to the rate at which a congestion control 223 decides to transmit packets based on 'network information'. 225 o 'signaling repaired symbols' (input control plane for the FEC): 226 refers to the information a FEC sender can obtain from a FEC 227 receiver about the performance of the FEC solution as seen by the 228 receiver. 230 o 'coding rate' (output control plane for the FEC): refers to the 231 coding rate that is used by the FEC solution. 233 o 'source and/or repair symbols' (data plane for both the FEC and 234 the CC): refers to the data that is transmitted. The sender can 235 decide to send source symbols only (meaning that the coding rate 236 is 0), repair symbols only (if the solution decides not to send 237 the original source packets) or a mix of both. 239 The inputs to FEC (incoming data packets without repair symbols, and 240 signaling from the receiver about losses and/or repaired symbols) are 241 distinct from the inputs to CC. The latter calculates a sending rate 242 or window from network information, and it takes the packet to send 243 as input, sometimes along with application requirements such as 244 upper/lower rate bounds, periods of quiescence, or a priority. It is 245 not clear that the ACK signals feeding into a congestion control 246 algorithm are useful to FEC in their raw form, and vice versa - 247 information about repaired blocks may be quite irrelevant to a CC 248 algorithm. 250 2.2. Relation between transport layer and application requirements 252 The choice of the adequate transport layer may be related to 253 application requirements and the services offered by a transport 254 protocol [RFC8095]: 256 o In the case of an unreliable data transfer, the transport layer 257 may provide a non-reliable transport service (e.g. UDP or DCCP 258 [RFC4340] or a partially reliable transport protocol such as SCTP 259 with partial reliability [RFC3758]) or QUIC with the unreliable 260 datagram extension [I-D.ietf-quic-datagram]. Depending on the 261 amount of redundancy and network conditions, there could be cases 262 where it becomes impossible to carry traffic. 264 o In the case of a reliable data transfer, the transport layer may 265 implement a retransmission mechanism to guarantee the reliability 266 of the file transfer (e.g. TCP). Depending on how the FEC and CC 267 functions are scheduled (FEC above CC, FEC in CC, FEC below CC), 268 the impact of reliable transport on the FEC reliability mechanisms 269 is different. 271 The document considers one application layer stream as input packets. 272 The application layer may exploit several paths above both the FEC 273 and transport layers; this case is not further described in the 274 document. 276 2.3. Fairness, a policy concern 278 The contract between the client and the operator may guarantee a 279 minimum data-rate (e.g. mobile networks). However, for residential 280 accesses, the data-rate can be guaranteed for the customer premises 281 equipment, but not necessarily for the client. The quality of 282 service that guarantees fairness between the different clients can be 283 seen as a policy concern [I-D.briscoe-tsvarea-fair]. 285 While flow level fairness does not embody the actual application 286 level fairness, the share of available capacity between single flows 287 can help assess when one flow starves the other. While past efforts 288 have focused on achieving fairness, quantifying and limiting harm 289 caused by new algorithm (or algorithms with coding) is more practical 290 [BEYONDJAIN]. Clients may share a bottleneck that may not be ruled 291 by a quality of service mechanism, e.g. in case of: 293 o a mobile network client running several applications; 295 o two clients on a residential access. 297 This document considers fairness as an index to quantify the impact 298 of the addition of coded flows on non-coded flows when they share the 299 same bottleneck. This document does not aim at contributing to the 300 definition of fairness at a wider scale. This document assumes that 301 the non-coded flows respond to congestion signals from the network. 303 3. FEC above the transport 304 | source ^ source 305 | packets | packets 306 v | 307 +-------------+ +-------------+ 308 |FEC | signaling|FEC | 309 | | repaired| | 310 | | symbols| | 311 | | <==| | 312 +-------------+ +-------------+ 313 | source ^ ^ source 314 | and/or | sending | and/or 315 | repair | rate | repair 316 | symbols | (or window) | symbols 317 v | | 318 +-------------+ +-------------+ 319 |Transport |source network|Transport | 320 |(incl. CC) |and/or information| | 321 | |repair <==| | 322 | |packets | | 323 +-------------+==> +-------------+ 325 SENDER RECEIVER 327 Figure 4: FEC above the transport 329 Figure 4 present an architecture where FEC operates on top of the 330 transport. 332 The advantage of this approach is that the FEC overhead does not 333 contribute to congestion in the network. When congestion control is 334 implemented at the transport layer, the repair symbols are sent 335 following the congestion window. This approach can result in 336 improved quality of experience for latency sensitive applications 337 such as VoIP or any not-fully reliable services. 339 This approach requires that the transport protocol does not implement 340 a fully reliable data transfer service (e.g., based on lost packet 341 retransmission). QUIC with unreliable datagram extension 342 [I-D.ietf-quic-datagram] is an example of a protocol for which this 343 approach is relevant. In cases where QUIC traffic is blocked and a 344 fallback to TCP mechanism is proposed, there is a risk for bad 345 interactions between the TCP reliability mechanisms and coding 346 schemes. For reliable transfers, coding usage does not guarantee 347 better performance and would mainly reduce goodput for large file 348 transfers. Moreover, the recovered symbols may not be known to the 349 transport. 351 3.1. Fairness and impact on non-coded flows 353 The addition of coding within the flow does not impact on the 354 interaction between coded and non-coded flows. This interaction 355 would mainly depend on the congestion controls embedded in each host. 357 3.2. Congestion control and recovered symbols 359 The congestion control may not be able to differentiate repair 360 symbols from actual source packets. The relevance of adding coding 361 at the application layer is related to the needs of the application. 362 For real-time applications, this approach may reduce the number of 363 retransmission. The usage of a non-reliable transport is more 364 adequate in this case. 366 3.3. Interactions between congestion control and coding rates 368 The coding rate applied at the application layer mainly depends on 369 the available capacity given by the congestion control underneath. 370 Adapting the coding rate to the minimum required data rate of the 371 application may reduce packet losses and improve the quality of 372 experience. 374 3.4. On the useless repair symbols 376 The discussion depends on application needs. The only case where 377 adding useless repair symbols does not obviously result in reduced 378 goodput is when the application needs a limited amount of goodput 379 (e.g., VoIP traffic). In this case, the useless repair symbols would 380 only impact the amount of data generated in the network. Extra data 381 in the network can, however, increase the likelihood of increasing 382 delay and/or packet loss, which could provoke a congestion control 383 reaction that would degrade goodput. 385 3.5. On partial ordering 387 Whether the transport protocol includes a reordering mechanism or 388 not, the FEC mechanism does not require to implement a reordering 389 mechanism if the application does not require it. However, if the 390 application requires in-order delivery of packets, a reordering 391 mechanism at the client is required. 393 3.6. On partial reliability 395 The application may require partial reliability only. In this case, 396 the coding rates of the FEC mechanisms could be adapted accordingly 397 based on inputs of the application and the trade-off between latency 398 and packet loss. 400 3.7. On multipath transport 402 Whether the transport protocol exploits multiple paths or not does 403 not have an impact on the FEC mechanism. 405 4. FEC within the transport 407 | source | sending ^ source 408 | packets | rate | packets 409 v v | 410 +------------+ +------------+ 411 | Transport | | Transport | 412 | | | | 413 | +---+ +--+ | signaling| +---+ +--+ | 414 | |FEC| |CC| | repaired| |FEC| |CC| | 415 | +---+ +--+ |source symbols| +---+ +--+ | 416 | |and/or <==| | 417 | |repair network| | 418 | |packets information| | 419 +------------+ ==> <==+------------+ 421 SENDER RECEIVER 423 Figure 5: FEC in the transport 425 Figure 5 presents an architecture where FEC operates within the 426 transport. The repair symbols are sent within what the congestion 427 window allows, such as in [CTCP]. 429 The advantage of this approach allows a joint optimization of the CC 430 and the FEC. Moreover, the transmission of repair symbols does not 431 add congestion in potentially congested networks but helps repair 432 lost packets (such as tail losses). 434 For reliable transfers, including redundancy reduces goodput for 435 large file transfers but the amount of repair symbols can be adapted, 436 e.g. depending on the congestion window size. There is a trade-off 437 between the cost of capacity used to transmit source packets and the 438 benefits brought out by transmitting repair symbols (e.g. unlocking 439 the receive buffer if this is limiting). The coding ratio needs to 440 be carefully designed. For small files, sending repair symbols when 441 there is no more data to transmit could help to reduce the transfer 442 time. In general, sending repair symbols could avoid a silent period 443 between the transmission of the last packet in the send buffer and 1) 444 firing the retransmission of lost packets, or 2) the transmission of 445 new packets. 447 4.1. Fairness and impact on non-coded flows 449 The addition of coding within the flow may impact the congestion 450 control mechanism and hide congestion losses. Specific interaction 451 between congestion controls and coding schemes can be proposed (see 452 Section 4.2, Section 4.3 and Section 4.4). If no specific 453 interaction is introduced, the coding scheme may hide congestion 454 losses from the congestion controller and the description of 455 Section 5 may apply. 457 4.2. Congestion control and recovered symbols 459 If the FEC and CC channels are decoupled, the endpoint may exploit 460 different protocols for each channel. The channels may be coupled 461 and one single protocol may be exploited. In both cases, the 462 receiver can differentiate source packets and repair symbols. The 463 receiver may indicate both the number of source packets received and 464 repair symbols that were actually useful in the recovery process of 465 packets. 467 4.3. Interactions between congestion control and coding rates 469 There is an important flexibility in the trade-off, inherent to the 470 use of coding, between (1) reducing goodput when useless repair 471 symbols are transmitted and (2) helping to recover sooner from 472 transmission and congestion losses. The receiver may indicate to the 473 sender the number of packets that have been received or recovered. 474 The sender may exploit this information to tune the coding ratio. As 475 one example of flexibility of this case, coupling an increased 476 transmission rate with an increasing or decreasing coding rate could 477 be envisioned. A server may use an increasing coding rate as a probe 478 of the channel capacity and adapt the congestion control transmission 479 rate. 481 4.4. On the useless repair symbols 483 The sender may exploit the information given by the receiver to 484 reduce the number of useless repair symbols and the resulting goodput 485 reduction. 487 4.5. On partial ordering 489 The application may require in-order delivery of packets. In this 490 case, both FEC and transport layer mechanisms should guarantee that 491 packets are delivered in order. If partial ordering is requested by 492 the application, both the FEC and transport could release the 493 constraints related to in-order delivery of packets : reordering 494 mechanisms at the receiver may not be necessary. 496 4.6. On partial reliability 498 The application may require partial reliability. In this case, the 499 transport and FEC mechanisms could be conjointly designed. As one 500 example, the reliability offered by FEC may be sufficient and no 501 retransmission required. This depends on application requirements 502 and the trade-off between latency and loss. 504 4.7. On transport multipath 506 The sender may adapt the coding rate of each of the single subpaths, 507 whether the congestion control is coupled or not. There is an 508 important flexibility on how the coding rate is tuned depending on 509 the characteristics of each subpath. 511 5. FEC below the transport 513 | source | sending rate ^ source 514 | packets | (or window) | packets 515 v v | 516 +--------------+ +--------------+ 517 |Transport | network|Transport | 518 |(including CC)| information| | 519 | | <==| | 520 +--------------+ +--------------+ 521 | source packets ^ source packets 522 v | 523 +--------------+ +--------------+ 524 | FEC |source | FEC | 525 | |and/or signaling| | 526 | |repair repaired| | 527 | |symbols symbols| | 528 | |==> <==| | 529 +--------------+ +--------------+ 531 SENDER RECEIVER 533 Figure 6: FEC below the transport 535 Figure 6 presents an architecture where FEC is applied end-to-end 536 below the transport layer, but above the link layer. Note that it is 537 common to apply FEC at the link layer, in which it contributes to the 538 total capacity that a link exposes to upper layers. This application 539 of FEC is out of scope of this document. In the scenario considered 540 here, the repair symbols are sent on top of what is allowed by the 541 congestion control. 543 Including redundancy adds traffic without reducing goodput but leads 544 to potential fairness issues. The effective bitrate is indeed higher 545 than the CC's computed fair share due to the sending of repair 546 symbols and the losses are hidden from the transport. This may cause 547 a problem for loss-based congestion detection, but it is not a 548 problem for delay-based congestion detection. 550 The advantage of this approach is that it can result in performance 551 gains when there are persistent transmission losses along the path. 553 The drawback of this approach is that it can induce congestion in 554 already congested networks. The coding ratio needs to be carefully 555 designed. 557 Examples of the solution could be adding a given percentage of the 558 congestion window as supplementary symbols or sending a given amount 559 of repair symbols at a given rate. The redundancy flow can be 560 decorrelated from the congestion control that manages source packets: 561 a separate congestion control entity could be introduced to manage 562 the amount of repaired packets to transmit on the FEC channel. The 563 separate congestion control instances could be made to work together 564 while adhering to priorities, as in coupled congestion control for 565 RTP media [RFC8699] in case all traffic can be assumed to take the 566 same path, or otherwise with a multipath congestion window coupling 567 mechanism as in Multipath TCP [RFC6356]. Another possibility would 568 be to exploit a lower than best-effort congestion control [RFC6297] 569 for repair symbols. 571 5.1. Fairness and impact on non-coded flows 573 The coding scheme may hide congestion losses from the congestion 574 controller. There are cases where this can drastically reduce the 575 goodput of non-coded flows. Depending on the congestion control, it 576 may be possible to signal to the congestion control mechanism that 577 there was congestion (loss) even when a packet has been recovered, 578 e.g. using ECN, to reduce the impact on the non-coded flows (see 579 Section 5.2 and [TENTET]). 581 5.2. Congestion control and recovered symbols 583 The congestion control may not know what is going on in the network 584 underneath and whether a coding scheme is introduced or not. The 585 congestion control may behave as if no coding scheme is introduced. 586 The only way for a coding channel to indicate that symbols have been 587 recovered is to exploit existing signaling that is understood by the 588 congestion control mechanism. An example would be to indicate to a 589 TCP sender that a packet has been recovered (i.e., congestion has 590 occurred), by using ECN signaling [TENTET]. 592 5.3. Interactions between congestion control and coding rates 594 The coding rate can be tuned depending on the number of recovered 595 symbols and the rate at which the sender transmits data. The coding 596 scheme is not aware of the congestion control implementation, making 597 it hard for the coding scheme to apply the relevant coding rate. 599 5.4. On the useless repair symbols 601 The useless repair symbols only impact the load of the network 602 without actual gain for the coded flow. That being said, using 603 feedback signaling, FEC mechanisms can measure the actually used 604 symbols and tune the amount of useless repair symbols. 606 5.5. On partial ordering 608 The transport above the FEC channel may support out-of-order delivery 609 of packets: reordering mechanisms at the receiver may not be 610 necessary. In cases where the transport requires in-order delivery, 611 the FEC channel may need to implement a reordering mechanism 612 otherwise there may be spurious retransmissions at the transport 613 level. 615 5.6. On partial reliability 617 The transport or application layer above the FEC channel may require 618 partial reliability only. In this case, FEC may provide an 619 unnecessary service if it is not aware of the reliability 620 requirements. 622 5.7. On transport multipath 624 The transport may exploit multiple paths without the FEC channel 625 being aware of it. This depends on whether FEC is applied to all 626 subflows or each of the subflows individually. When FEC is applied 627 to all the flows, there is a risk for the coding rate to be 628 inadequate for the characteristics of the individual paths. 630 6. Open research questions 632 This section provides a short state-of-the art overview of activities 633 related to congestion control and coding. The objective is to 634 identify open research questions and contribute to advice when 635 evaluating coding mechanisms. 637 6.1. Activities related to congestion control and coding 639 We map activities related to congestion control and coding with the 640 organization presented in this document: 642 o For the FEC above transport case: [RFC8680]. 644 o For the FEC within transport case: 645 [I-D.swett-nwcrg-coding-for-quic], [QUIC-FEC], [RFC5109]. 647 o For the FEC below transport case: [NCTCP], 648 [I-D.detchart-nwcrg-tetrys]. 650 6.2. Open research questions 652 There is a general trade-off, inherent to the use of coding, between 653 (1) reducing goodput when useless repair symbols are transmitted and 654 (2) helping to recover from transmission and congestion losses. 656 For the FEC above transport case, there is a trade-off related to the 657 amount of redundancy to add, as a function of the transport layer 658 protocol and application requirements. 660 For the FEC within transport case, recovering lost symbols may hide 661 congestion losses to the congestion control. Some existing solutions 662 already propose to disambiguate acked packets from rebuilt packets 663 [QUIC-FEC]. New signaling methods and FEC-recovery-aware congestion 664 controls could be proposed. 666 For the FEC below transport case, there are opportunities for 667 introducing interaction between congestion control and coding schemes 668 to improve the quality of experience while guaranteeing fairness with 669 other flows. New signaling methods and FEC-recovery-aware congestion 670 controls could be proposed. An open question also resides in the 671 relevance of FEC when there are multiple streams that exploit the FEC 672 channel. 674 6.3. Advice for evaluating coding mechanisms 676 The contribution to research questions should be mapped following the 677 organization of this document. Otherwise, this may lead to wrong 678 assumptions on the validity of the proposal and wrong ideas about the 679 relevance of coding for a given use case. 681 The discussion provided in this document aims at encouraging the 682 research community to also consider congestion control aspects when 683 proposing and comparing FEC coding solutions in communication 684 systems. As one example, this draft proposes discussions on the 685 impact of the proposed FEC solution on congestion control, especially 686 loss-based congestion control mechanisms. When a research work aims 687 at improving throughput by hiding the packet loss signal from 688 congestion control, the authors should 1) discuss the advantages of 689 using the proposed FEC solution compared to replacing the congestion 690 control by one that ignores a portion of the encountered losses, 2) 691 critically discuss the impact of hiding packet loss from the 692 congestion control mechanism. 694 7. Acknowledgements 696 Many thanks to Spencer Dawkins, Dave Oran, Carsten Bormann, Vincent 697 Roca and Marie-Jose Montpetit for their useful comments that helped 698 improve the document. 700 8. IANA Considerations 702 This memo includes no request to IANA. 704 9. Security Considerations 706 FEC and CC schemes can contribute to DoS attacks. This is not 707 specific to this document. 709 In case of FEC below the transport, the aggregate rate of source and 710 repair packets may exceed the rate at which a congestion control 711 mechanism allows an application to send. This could result in an 712 application obtaining more than its fair share of the network 713 capacity. 715 10. Informative References 717 [BEYONDJAIN] 718 Ware (et al.), R., "Beyond Jain's Fairness Index: Setting 719 the Bar For The Deployment of Congestion Control 720 Algorithms", HotNets '19 10.1145/3365609.3365855, 2019. 722 [CTCP] Kim (et al.), M., "Network Coded TCP (CTCP)", 723 arXiv 1212.2291v3, 2013. 725 [I-D.briscoe-tsvarea-fair] 726 Briscoe, B., "Flow Rate Fairness: Dismantling a Religion", 727 draft-briscoe-tsvarea-fair-02 (work in progress), July 728 2007. 730 [I-D.detchart-nwcrg-tetrys] 731 Detchart, J., Lochin, E., Lacan, J., and V. Roca, "Tetrys, 732 an On-the-Fly Network Coding protocol", draft-detchart- 733 nwcrg-tetrys-06 (work in progress), December 2020. 735 [I-D.ietf-quic-datagram] 736 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 737 Datagram Extension to QUIC", draft-ietf-quic-datagram-01 738 (work in progress), August 2020. 740 [I-D.swett-nwcrg-coding-for-quic] 741 Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding 742 for QUIC", draft-swett-nwcrg-coding-for-quic-04 (work in 743 progress), March 2020. 745 [NCTCP] Sundararajan (et al.), J., "Network Coding Meets TCP: 746 Theory and Implementation", IEEE 747 INFOCOM 10.1109/JPROC.2010.2093850, 2009. 749 [QUIC-FEC] 750 Michel (et al.), F., "QUIC-FEC: Bringing the benefits of 751 Forward Erasure Correction to QUIC", IFIP 752 Networking 10.23919/IFIPNetworking.2019.8816838, 2019. 754 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 755 Conrad, "Stream Control Transmission Protocol (SCTP) 756 Partial Reliability Extension", RFC 3758, 757 DOI 10.17487/RFC3758, May 2004, 758 . 760 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 761 Congestion Control Protocol (DCCP)", RFC 4340, 762 DOI 10.17487/RFC4340, March 2006, 763 . 765 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 766 Correction", RFC 5109, DOI 10.17487/RFC5109, December 767 2007, . 769 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 770 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 771 . 773 [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort 774 Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 775 2011, . 777 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 778 Congestion Control for Multipath Transport Protocols", 779 RFC 6356, DOI 10.17487/RFC6356, October 2011, 780 . 782 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 783 Ed., "Services Provided by IETF Transport Protocols and 784 Congestion Control Mechanisms", RFC 8095, 785 DOI 10.17487/RFC8095, March 2017, 786 . 788 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 789 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 790 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 791 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 792 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 793 June 2018, . 795 [RFC8680] Roca, V. and A. Begen, "Forward Error Correction (FEC) 796 Framework Extension to Sliding Window Codes", RFC 8680, 797 DOI 10.17487/RFC8680, January 2020, 798 . 800 [RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion 801 Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, 802 January 2020, . 804 [TENTET] Lochin, E., "On the joint use of TCP and Network Coding", 805 NWCRG session IETF 100, 2017. 807 Authors' Addresses 809 Nicolas Kuhn 810 CNES 812 Email: nicolas.kuhn@cnes.fr 814 Emmanuel Lochin 815 ENAC 817 Email: emmanuel.lochin@enac.fr 819 Francois Michel 820 UCLouvain 822 Email: francois.michel@uclouvain.be 823 Michael Welzl 824 University of Oslo 826 Email: michawe@ifi.uio.no