idnits 2.17.1 draft-irtf-nwcrg-coding-and-congestion-04.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 329 has weird spacing: '...packets inf...' -- The document date (October 30, 2020) is 1274 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-05 Summary: 0 errors (**), 0 flaws (~~), 3 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: May 3, 2021 ENAC 6 F. Michel 7 UCLouvain 8 M. Welzl 9 University of Oslo 10 October 30, 2020 12 Coding and congestion control in transport 13 draft-irtf-nwcrg-coding-and-congestion-04 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 transfer tail losses or with networks having non-congestion losses. 21 However, FEC coding mechanisms should not hide congestion signals. 22 This memo offers a discussion of how FEC coding and congestion 23 control can coexist. Another objective is to encourage the research 24 community to also consider congestion control aspects when proposing 25 and comparing FEC coding solutions in communication systems. 27 This document is the product of the Coding for Efficient Network 28 Communications Research Group (NWCRG). The scope of the document is 29 end-to-end communications: FEC coding for tunnels is out-of-the scope 30 of the document. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 3, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Separate channels, separate entities . . . . . . . . . . . . 4 68 3. FEC above the transport . . . . . . . . . . . . . . . . . . . 6 69 3.1. Flowchart . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7 71 4. FEC within the transport . . . . . . . . . . . . . . . . . . 8 72 4.1. Flowchart . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 74 5. FEC below the transport . . . . . . . . . . . . . . . . . . . 9 75 5.1. Flowchart . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 9 77 6. Fairness, redundacy rate and congestion signals . . . . . . . 10 78 6.1. Fairness, a policy concern . . . . . . . . . . . . . . . 10 79 6.2. Fairness and impact on non-coded flows . . . . . . . . . 11 80 6.2.1. FEC above the transport . . . . . . . . . . . . . . . 11 81 6.2.2. FEC within the transport . . . . . . . . . . . . . . 11 82 6.2.3. FEC below the transport . . . . . . . . . . . . . . . 11 83 6.3. Congestion control and recovered symbols . . . . . . . . 11 84 6.3.1. FEC above the transport . . . . . . . . . . . . . . . 11 85 6.3.2. FEC within the transport . . . . . . . . . . . . . . 12 86 6.3.3. FEC below the transport . . . . . . . . . . . . . . . 12 87 6.4. Interactions between congestion control and coding rates 12 88 6.4.1. FEC above the transport . . . . . . . . . . . . . . . 12 89 6.4.2. FEC within the transport . . . . . . . . . . . . . . 12 90 6.4.3. FEC below the transport . . . . . . . . . . . . . . . 13 91 6.5. On the useless repair symbols . . . . . . . . . . . . . . 13 92 6.5.1. FEC above the transport . . . . . . . . . . . . . . . 13 93 6.5.2. FEC within the transport . . . . . . . . . . . . . . 13 94 6.5.3. FEC below the transport . . . . . . . . . . . . . . . 13 95 7. Open research questions . . . . . . . . . . . . . . . . . . . 13 96 7.1. Activities related to congestion control and coding . . . 13 97 7.2. Open research questions . . . . . . . . . . . . . . . . . 14 98 7.3. Advices for evaluating coding mechanisms . . . . . . . . 14 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 102 11. Informative References . . . . . . . . . . . . . . . . . . . 15 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 105 1. Introduction 107 There are cases where deploying FEC coding improves the performance 108 of a transmission. As an example, it may take time for the sender to 109 detect transfer tail losses (losses that occur at the end of a 110 transfer, where e.g., TCP obtains no more ACKs to repair the loss via 111 retransmission quickly). Allowing the receiver to recover such 112 losses instead of having to rely on a retransmission could improve 113 the experience of applications using short flows. Another example 114 are networks where non-congestion losses are persistent and prevent a 115 sender from exploiting the link capacity. 117 Coding is a reliability mechanism that is distinct and separate from 118 the loss detection of congestion controls. [RFC5681] defines TCP as 119 a loss-based congestion control; since FEC coding repairs such 120 losses, blindly applying it may easily lead to an implementation that 121 also hides a congestion signal from the sender. It is important to 122 ensure that such information hiding does not occur. 124 FEC coding and congestion control can be seen as two separate 125 channels. In practice, implementations may mix the signals that are 126 exchanged on these channels. This memo offers a discussion of how 127 FEC coding and congestion control can coexist. Another objective is 128 to encourage the research community also to consider congestion 129 control aspects when proposing and comparing FEC coding solutions in 130 communication systems. This document does not aim at proposing 131 guidelines for characterizing FEC coding solutions. 133 The proposed document considers an end-to-end unicast data transfer 134 with FEC coding at the application (above the transport), within the 135 transport or directly below the transport. The typical application 136 scenario considered in the current version of the document is a 137 client browsing the web or watching a live video. This memo may be 138 extended to cases with multiple paths. 140 This document represents the collaborative work and consensus of the 141 Coding for Efficient Network Communications Research Group (NWCRG); 142 it is not an IETF product and is not a standard. The document 143 follows the terminology proposed in the taxonomy document [RFC8406]. 145 2. Separate channels, separate entities 147 Figure 1 presents the notations that will be used in this document 148 and introduces the Congestion Control (CC) and Forward Erasure 149 Correction (FEC) channels. The Congestion Control channel carries 150 source packets from a sender to a receiver, and packets signaling 151 information about the network (number of packets received vs. lost, 152 ECN marks, etc.) from the receiver to the sender. The Forward 153 Erasure Correction channel carries repair symbols (from the sender to 154 the receiver) and potential information signaling which packets have 155 been repaired (from the receiver to the sender). It is worth 156 pointing out that there are cases where these channels are not 157 separated. 159 SENDER RECEIVER 161 +------+ +------+ 162 | | ----- source packets ---->| | 163 | CC | | CC | 164 | | <--- network information ---| | 165 +------+ +------+ 167 +------+ +------+ 168 | | ----- repair symbols ---->| | 169 | FEC | | FEC | 170 | | <--- info: repaired symbols --| | 171 +------+ +------+ 173 Figure 1: Notations and separate channels 175 Inside a host, the CC and FEC entities can be regarded as 176 conceptually separate: 178 | ^ | ^ 179 | source | coding |packets | sending 180 | packets | rate |requirements | rate (or 181 v | v | window) 182 +---------------+source +-----------------+ 183 | FEC |and/or | CC | 184 | |repair | |source 185 | |symbols | |packets 186 +---------------+==> +-----------------+==> 187 ^ ^ 188 | signaling about | network 189 | losses and/or | information 190 | repaired symbols 192 Figure 2: Separate entities (sender-side) 194 | | 195 | source and/or | packets 196 | repair symbols | 197 v v 198 +---------------+ +-----------------+ 199 | FEC |signaling | CC | 200 | |repaired | |network 201 | |symbols | |information 202 +---------------+==> +-----------------+==> 204 Figure 3: Separate entities (receiver-side) 206 Figure 2 and Figure 3 provide more details than Figure 1. Some 207 elements are introduced: 209 o 'network information' (input control plane for the transport 210 including CC): refers not only to the network information that is 211 explicitly signaled from the receiver, but all the information a 212 congestion control obtains from a network (e.g., TCP can estimate 213 the latency and the available capacity at the bottleneck). 215 o 'requirements' (input control plane for the transport including 216 CC): refers to application requirements such as upper/lower rate 217 bounds, periods of quiescence, or a priority. 219 o 'sending rate (or window)' (output control plane for the transport 220 including CC): refers to the rate at which a congestion control 221 decides to transmit packets based on 'network information'. 223 o 'signaling repaired symbols' (input control plane for the FEC): 224 refers to the information a FEC sender can obtain from a FEC 225 receiver about the performance of the FEC solution as seen by the 226 receiver. 228 o 'coding rate' (output control plane for the FEC): refers to the 229 coding rate that is used by the FEC solution. 231 o 'source and/or repair symbols' (data plane for both the FEC and 232 the CC): refers to the data that is transmitted. The sender can 233 decide to send source symbols only (meaning that the coding rate 234 is 0), repair symbols only (if the solution decides not to send 235 the original source packets) or a mix of both. 237 The inputs to FEC (incoming data packets without repair symbols, and 238 signaling from the receiver about losses and/or repaired symbols) are 239 distinct from the inputs to CC. The latter calculates a sending rate 240 or window from network information, and it takes the packet to send 241 as input, sometimes along with application requirements such as 242 upper/lower rate bounds, periods of quiescence, or a priority. It is 243 not clear that the ACK signals feeding into a congestion control 244 algorithm are useful to FEC in their raw form, and vice versa - 245 information about repaired blocks may be quite irrelevant to a CC 246 algorithm. 248 The choice of the adequate transport layer may be related to 249 application requirements: 251 o In the case of an unreliable data transfer, the transport layer 252 may provide a non-reliable transport service (e.g. UDP or DCCP 253 [RFC4340] or a partially reliable transport protocol such as SCTP 254 with partial reliability [RFC3758]). Depending on the amount of 255 redundancy and network conditions, there could be cases where it 256 becomes impossible to carry traffic. 258 o In the case of a reliable data transfer, the transport layer may 259 implement a retransmission mechanism to guarantee the reliability 260 of the file transfer (e.g. TCP). Depending on how the FEC and CC 261 functions are scheduled (FEC above CC, FEC in CC, FEC below CC), 262 the impact of reliable transport on the FEC reliability mechanisms 263 is different. 265 3. FEC above the transport 267 3.1. Flowchart 268 | source ^ source 269 | packets | packets 270 v | 271 +-------------+ +-------------+ 272 |FEC | signaling|FEC | 273 | | repaired| | 274 | | symbols| | 275 | | <==| | 276 +-------------+ +-------------+ 277 | source ^ ^ source 278 | and/or | sending | and/or 279 | repair | rate | repair 280 | symbols | (or window) | symbols 281 v | | 282 +-------------+ +-------------+ 283 |Transport |source network|Transport | 284 |(incl. CC) |and/or information| | 285 | |repair <==| | 286 | |packets | | 287 +-------------+==> +-------------+ 289 SENDER RECEIVER 291 Figure 4: FEC above the transport 293 Figure 4 present an architecture where FEC operates on top of the 294 transport. 296 3.2. Discussion 298 The advantage of this approach is that the FEC overhead does not 299 contribute to congestion in the network. When congestion control is 300 implemented at the transport layer, the repair symbols are sent 301 following the congestion window. This approach can result in 302 improved quality of experience for latency sensitive applications 303 such as VoIP. 305 This approach requires that the transport protocol does not implement 306 a fully reliable data transfer service (e.g., based on lost packet 307 retransmission). UDP is an example of a protocol for which this 308 approach is relevant. For reliable transfers, coding usage does not 309 guarantee better performance and would mainly reduce goodput for 310 large file transfers. 312 This discussion section is extended in Section 6. 314 4. FEC within the transport 316 4.1. Flowchart 318 | source | sending ^ source 319 | packets | rate | packets 320 v v | 321 +------------+ +------------+ 322 | Transport | | Transport | 323 | | | | 324 | +---+ +--+ | signaling| +---+ +--+ | 325 | |FEC| |CC| | repaired| |FEC| |CC| | 326 | +---+ +--+ |source symbols| +---+ +--+ | 327 | |and/or <==| | 328 | |repair network| | 329 | |packets information| | 330 +------------+ ==> <==+------------+ 332 SENDER RECEIVER 334 Figure 5: FEC in the transport 336 Figure 5 presents an architecture where FEC operates within the 337 transport. The repair symbols are sent within what the congestion 338 window allows, such as in [CTCP]. 340 4.2. Discussion 342 The advantage of this approach allows a joint optimization between 343 the CC and the FEC. Moreover, the transmission of repair symbols 344 does not add congestion in potentially congested networks but helps 345 repair lost packets (such as tail losses). 347 For reliable transfers, including redundancy reduces goodput for 348 large file transfers but the amount of repair symbols can be adapted, 349 e.g. depending on the congestion window size. There is a trade-off 350 between the cost in capacity used to transmit source packets and the 351 benefits brought out by transmitting repair symbols (e.g. unlocking 352 the receive buffer if this is limiting). The coding ratio needs to 353 be carefully designed. For small files, sending repair symbols when 354 there is no more data to transmit could help to reduce the transfer 355 time. In general, sending repair symbols could avoid a silent period 356 between the transmission of the last packet in the send buffer and 1) 357 firing the retransmission of lost packets, or 2) the transmission of 358 new packets. 360 This discussion section is extended in Section 6. 362 5. FEC below the transport 364 5.1. Flowchart 366 | source | sending rate ^ source 367 | packets | (or window) | packets 368 v v | 369 +--------------+ +--------------+ 370 |Transport | network|Transport | 371 |(including CC)| information| | 372 | | <==| | 373 +--------------+ +--------------+ 374 | source packets ^ source packets 375 v | 376 +--------------+ +--------------+ 377 | FEC |source | FEC | 378 | |and/or signaling| | 379 | |repair repaired| | 380 | |symbols symbols| | 381 | |==> <==| | 382 +--------------+ +--------------+ 384 SENDER RECEIVER 386 Figure 6: FEC below the transport 388 Figure 6 presents an architecture where FEC is applied end-to-end 389 below the transport layer, but above the link layer. Note that it is 390 common to apply FEC at the link layer, in which it contributes to the 391 total capacity that a link exposes to upper layers. This application 392 of FEC is out of scope of this document. In the scenario considered 393 here, the repair symbols are sent on top of what is allowed by the 394 congestion control. 396 5.2. Discussion 398 In this case, including redundancy adds congestion without reducing 399 goodput but leads to potential fairness issues. The effective 400 bitrate is indeed higher than the CC's computed fair share due to the 401 sending of repair symbols and the losses are hidden from the 402 transport. This may cause a problem for loss-based congestion 403 detection, but it is not a problem for delay-based congestion 404 detection. 406 The advantage of this approach is that it can result in performance 407 gains when there are persistent transmission losses along the path. 409 The drawback of this approach is that it can induce congestion in 410 already congested networks. The coding ratio needs to be carefully 411 designed. 413 Examples of the solution could be adding a given percentage of the 414 congestion window as supplementary symbols or sending a given amount 415 of repair symbols at a given rate. The redundancy flow can be 416 decorrelated from the congestion control that manages source packets: 417 a separate congestion control entity could be introduced to manage 418 the amount of repaired packets to transmit on the FEC channel. The 419 separate congestion control instances could be made to work together 420 while adhering to priorities, as in coupled congestion control for 421 RTP media [RFC8699] in case all traffic can be assumed to take the 422 same path, or otherwise with a multipath congestion window coupling 423 mechanism as in Multipath TCP [RFC6356]. Another possibility would 424 be to exploit a lower than best-effort congestion control [RFC6297] 425 for repair symbols. 427 This discussion section is extended in Section 6. 429 6. Fairness, redundacy rate and congestion signals 431 The objective of this section is to further detail some aspects that 432 have been expressed in previous discussion subsections. 434 6.1. Fairness, a policy concern 436 The contract between the client and the operator may guarantee a 437 minimum data-rate (e.g. mobile networks). However, for residential 438 accesses, the data-rate can be guaranteed for the customer premises 439 equipment, but not necessarily for the client. The quality of 440 service that guarantees fairness between the different clients can be 441 seen as a policy concern [I-D.briscoe-tsvarea-fair]. 443 While flow level fairness does not embody the actual application 444 level fairness, the share of available capacity between single flows 445 can help assess when one flow starves the other. Clients may share a 446 bottleneck that may not be ruled by a quality of service mechanism, 447 e.g. in case of: 449 o a mobile network client running several applications; 451 o two clients on a residential access. 453 This document considers fairness as an index to quantify the impact 454 of the addition of coded flows on non-coded flows when they share the 455 same bottleneck. This document does not aim at contributing to the 456 definition of fairness at a wider scale. This document assumes that 457 the non-coded flows respond to congestion signals from the network. 459 6.2. Fairness and impact on non-coded flows 461 6.2.1. FEC above the transport 463 The addition of coding within the flow does not impact on the 464 interaction between coded and non-coded flows. This interaction 465 would mainly depend on the congestion controls embedded in each host. 467 6.2.2. FEC within the transport 469 The addition of coding within the flow may impact the congestion 470 control mechanism and hide congestion losses. Specific interaction 471 between congestion controls and coding schemes can be proposed (see 472 Section 6.3, Section 6.4 and Section 6.5). If no specific 473 interaction is introduced, the coding scheme may hide congestion 474 losses from the congestion controller and the description of 475 Section 6.2.3 may apply. 477 6.2.3. FEC below the transport 479 In this case, the coding scheme may hide congestion losses from the 480 congestion controller. There are cases where this can drastically 481 reduce the goodput of non-coded flows. Depending on the congestion 482 control, it may be possible to signal to the congestion control 483 mechanism that there was congestion (loss) even when a packet has 484 been recovered, e.g. using ECN, to reduce the impact on the non-coded 485 flows (see Section 6.3.3 and [TENTET]). 487 6.3. Congestion control and recovered symbols 489 The objective of this subsection is to describe potential 490 interactions between the congestion control and the recovered 491 symbols. 493 6.3.1. FEC above the transport 495 The congestion control may not be able to differentiate repair 496 symbols from actual source packets. The relevance of adding coding 497 at the application layer is related to the needs of the application. 498 For real-time applications, this approach may reduce the number of 499 retransmission. The usage of a non-reliable transport is more 500 adequate in this case. 502 6.3.2. FEC within the transport 504 If the two FEC and CC channels are decoupled, the endpoint may 505 exploit different protocols for each channel. The channels may be 506 coupled and one single protocol may be exploited. In both cases, the 507 receiver can differentiate source packets and repair symbols. The 508 receiver may indicate both the number of source packets received and 509 repair symbols that were actually useful in the recovery process of 510 packets. 512 6.3.3. FEC below the transport 514 The congestion control may not know what is going on in the network 515 underneath and whether a coding scheme is introduced or not. The 516 congestion control may behave as if no coding scheme is introduced. 517 The only way for a coding channel to indicate that symbols have been 518 recovered is to exploit existing signaling that is understood by the 519 congestion control mechanism. An example would be to indicate to a 520 TCP sender that a packet has been recovered (i.e., congestion has 521 occurred), by using ECN signaling [TENTET]. 523 6.4. Interactions between congestion control and coding rates 525 This section discusses to what extent the interaction between the 526 congestion control and the coding rates is possible. 528 6.4.1. FEC above the transport 530 The coding rate applied at the application layer mainly depends on 531 the available capacity given by the congestion control underneath. 532 Adapting the coding rate to the minimum required data rate of the 533 application may reduce packet losses and improve the quality of 534 experience. 536 6.4.2. FEC within the transport 538 In this case, there is an important flexibility in the trade-off, 539 inherent to the use of coding, between (1) reducing goodput when 540 useless repair symbols are transmitted and (2) helping to recover 541 sooner from transmission and congestion losses. As explained in 542 Section 6.3.2, the receiver may indicate to the sender the number of 543 packets that have been received or recovered. The sender may exploit 544 this information to tune the coding ratio. As one example of 545 flexibility of this case, coupling an increased transmission rate 546 with an increasing or decreasing coding rate could be envisioned. A 547 server may use an increasing coding rate as a probe of the channel 548 capacity and adapt the congestion control transmission rate. 550 6.4.3. FEC below the transport 552 In this case, the coding rate can be tuned depending on the number of 553 recovered symbols and the rate at which the sender transmits data. 554 The coding scheme is not aware of the congestion control 555 implementation, making it hard for the coding scheme to apply the 556 relevant coding rate. 558 6.5. On the useless repair symbols 560 There are cases where useless repair symbols may be transmitted. 561 These impact on the network load and may reduce the goodput of the 562 flow without concrete gains. 564 6.5.1. FEC above the transport 566 In this case, the discussion depends on application needs. The only 567 case where adding useless repair symbols does not result in reduced 568 goodput is when the application needs a limited amount of goodput 569 (e.g., VoIP traffic). In this case, the useless repair symbols would 570 only impact the amount of data generated in the network. 572 6.5.2. FEC within the transport 574 The sender may exploit the information given by the receiver to 575 reduce the number of useless repair symbols and the resulting goodput 576 reduction. 578 6.5.3. FEC below the transport 580 In this case, the useless repair symbols only impact the load of the 581 network without actual gain for the coded flow. 583 7. Open research questions 585 This section provides a simplified state-of-the art of the activities 586 related to congestion control and coding. The objective is to 587 identify open research questions and contribute to advice when 588 evaluating coding mechanisms. 590 7.1. Activities related to congestion control and coding 592 We map activities related to congestion control and coding with the 593 organization presented in this document: 595 o For the FEC above transport case: TBD 596 o For the FEC within transport case: 597 [I-D.swett-nwcrg-coding-for-quic], [QUIC-FEC], [RFC5109]. 599 o For the FEC below transport case: [NCTCP], 600 [I-D.detchart-nwcrg-tetrys]. 602 7.2. Open research questions 604 The research questions should be mapped following the organization of 605 this document. In all these three use-cases, open questions remain. 606 There is a general trade-off, inherent to the use of coding, between 607 (1) reducing goodput when useless repair symbols are transmitted and 608 (2) helping to recover from transmission and congestion losses. 610 For the FEC above transport case, there is a trade-off related to the 611 amount of redundancy to add, as a function of the transport layer 612 protocol and application requirements. 614 For the FEC within transport case, recovering lost symbols may hide 615 congestion losses to the congestion control. Some existing solutions 616 already propose to disambiguate acked packets from rebuilt packets 617 [QUIC-FEC]. New signalling methods and FEC-recovery-aware congestion 618 controls could be proposed. 620 For the FEC below transport case, there are opportunities for 621 introducing interaction between congestion control and coding schemes 622 to improve the quality of experience while guaranteeing fairness with 623 other flows. An open question also resides in the relevance of FEC 624 when there are multiple streams that exploit the FEC channel. 626 7.3. Advices for evaluating coding mechanisms 628 The contribution to research questions should be mapped following the 629 organization of this document. Otherwise, this may lead to wrong 630 assumptions on the validity of the proposal and wrong ideas about the 631 relevance of coding for a given use case. 633 The discussion provided in this document aims at encouraging the 634 research community to also consider congestion control aspects when 635 proposing and comparing FEC coding solutions in communication 636 systems. As one example, this draft proposes discussions on the 637 impact of the proposed FEC solution on congestion control, especially 638 loss-based congestion control mechanisms. When a research work aims 639 at improving the throughput by hiding the packet loss signal from the 640 congestion control, the authors should 1) discuss the advantages of 641 using the proposed FEC solution compared to replacing the congestion 642 control by one that ignores a portion of the encountered losses, 2) 643 critically discuss the impact of hiding packet loss from the 644 congestion control mechanism. 646 8. Acknowledgements 648 Many thanks to Spencer Dawkins, Dave Oran, Carsten Bormann, Vincent 649 Roca and Marie-Jose Montpetit for their useful comments that helped 650 improve the document. 652 9. IANA Considerations 654 This memo includes no request to IANA. 656 10. Security Considerations 658 FEC and CC schemes can contribute to DoS attacks. This is not 659 specific to this document. 661 In case of FEC below the transport, the aggregate rate of source and 662 repair packets may exceed the rate at which a congestion control 663 mechanism allows an application to send. This could result in an 664 application obtaining more than its fair share of the network 665 capacity. 667 11. Informative References 669 [CTCP] Kim (et al.), M., "Network Coded TCP (CTCP)", 670 arXiv 1212.2291v3, 2013. 672 [I-D.briscoe-tsvarea-fair] 673 Briscoe, B., "Flow Rate Fairness: Dismantling a Religion", 674 draft-briscoe-tsvarea-fair-02 (work in progress), July 675 2007. 677 [I-D.detchart-nwcrg-tetrys] 678 Detchart, J., Lochin, E., Lacan, J., and V. Roca, "Tetrys, 679 an On-the-Fly Network Coding protocol", draft-detchart- 680 nwcrg-tetrys-05 (work in progress), February 2020. 682 [I-D.swett-nwcrg-coding-for-quic] 683 Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding 684 for QUIC", draft-swett-nwcrg-coding-for-quic-04 (work in 685 progress), March 2020. 687 [NCTCP] Sundararajan (et al.), J., "Network Coding Meets TCP: 688 Theory and Implementation", IEEE 689 INFOCOM 10.1109/JPROC.2010.2093850, 2009. 691 [QUIC-FEC] 692 Michel (et al.), F., "QUIC-FEC: Bringing the benefits of 693 Forward Erasure Correction to QUIC", IFIP 694 Networking 10.23919/IFIPNetworking.2019.8816838, 2019. 696 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 697 Conrad, "Stream Control Transmission Protocol (SCTP) 698 Partial Reliability Extension", RFC 3758, 699 DOI 10.17487/RFC3758, May 2004, 700 . 702 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 703 Congestion Control Protocol (DCCP)", RFC 4340, 704 DOI 10.17487/RFC4340, March 2006, 705 . 707 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 708 Correction", RFC 5109, DOI 10.17487/RFC5109, December 709 2007, . 711 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 712 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 713 . 715 [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort 716 Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 717 2011, . 719 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 720 Congestion Control for Multipath Transport Protocols", 721 RFC 6356, DOI 10.17487/RFC6356, October 2011, 722 . 724 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 725 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 726 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 727 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 728 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 729 June 2018, . 731 [RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion 732 Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, 733 January 2020, . 735 [TENTET] Lochin, E., "On the joint use of TCP and Network Coding", 736 NWCRG session IETF 100, 2017. 738 Authors' Addresses 740 Nicolas Kuhn 741 CNES 743 Email: nicolas.kuhn@cnes.fr 745 Emmanuel Lochin 746 ENAC 748 Email: emmanuel.lochin@enac.fr 750 Francois Michel 751 UCLouvain 753 Email: francois.michel@uclouvain.be 755 Michael Welzl 756 University of Oslo 758 Email: michawe@ifi.uio.no