idnits 2.17.1 draft-irtf-nwcrg-coding-and-congestion-09.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 525 has weird spacing: '...packets inf...' -- The document date (June 25, 2021) is 1036 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-02 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: December 27, 2021 ENAC 6 F. Michel 7 UCLouvain 8 M. Welzl 9 University of Oslo 10 June 25, 2021 12 Coding and congestion control in transport 13 draft-irtf-nwcrg-coding-and-congestion-09 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. FEC coding can help deal with losses 20 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 December 27, 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. Scope of the document concerning transport multipath and 73 multi-streams applications . . . . . . . . . . . . . . . 7 74 2.4. Types of coding . . . . . . . . . . . . . . . . . . . . . 8 75 2.5. Fairness, a policy concern . . . . . . . . . . . . . . . 9 76 3. FEC above the transport . . . . . . . . . . . . . . . . . . . 9 77 3.1. Fairness and impact on non-coded flows . . . . . . . . . 11 78 3.2. Congestion control and recovered symbols . . . . . . . . 11 79 3.3. Interactions between congestion control and coding rates 11 80 3.4. On useless repair symbols . . . . . . . . . . . . . . . . 11 81 3.5. On partial ordering . . . . . . . . . . . . . . . . . . . 11 82 3.6. On partial reliability . . . . . . . . . . . . . . . . . 12 83 3.7. On multipath transport . . . . . . . . . . . . . . . . . 12 84 4. FEC within the transport . . . . . . . . . . . . . . . . . . 12 85 4.1. Fairness and impact on non-coded flows . . . . . . . . . 13 86 4.2. Congestion control and recovered symbols . . . . . . . . 13 87 4.3. Interactions between congestion control and coding rates 13 88 4.4. On useless repair symbols . . . . . . . . . . . . . . . . 13 89 4.5. On partial ordering . . . . . . . . . . . . . . . . . . . 14 90 4.6. On partial reliability . . . . . . . . . . . . . . . . . 14 91 4.7. On transport multipath . . . . . . . . . . . . . . . . . 14 92 5. FEC below the transport . . . . . . . . . . . . . . . . . . . 14 93 5.1. Fairness and impact on non-coded flows . . . . . . . . . 15 94 5.2. Congestion control and recovered symbols . . . . . . . . 16 95 5.3. Interactions between congestion control and coding rates 16 96 5.4. On useless repair symbols . . . . . . . . . . . . . . . . 16 97 5.5. On partial ordering . . . . . . . . . . . . . . . . . . . 16 98 5.6. On partial reliability . . . . . . . . . . . . . . . . . 16 99 5.7. On transport multipath . . . . . . . . . . . . . . . . . 16 100 6. Research recommendations and questions . . . . . . . . . . . 17 101 6.1. Activities related to congestion control and coding . . . 17 102 6.2. Open research questions . . . . . . . . . . . . . . . . . 17 103 6.2.1. Parameter derivation . . . . . . . . . . . . . . . . 17 104 6.2.2. New signaling methods and fairness . . . . . . . . . 18 105 6.3. Recommendations and advice for evaluating coding 106 mechanisms . . . . . . . . . . . . . . . . . . . . . . . 18 107 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 110 10. Informative References . . . . . . . . . . . . . . . . . . . 19 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 113 1. Introduction 115 There are cases where deploying FEC coding improves the performance 116 of a transmission. As an example, it may take time for a sender to 117 detect transfer tail losses (losses that occur at the end of a 118 transfer, where, e.g., TCP obtains no more ACKs that would enable it 119 to quickly repair the loss via retransmission). Allowing the 120 receiver to recover such losses instead of having to rely on a 121 retransmission could improve the experience of applications using 122 short flows. Another example is a network where non-congestion 123 losses are persistent and prevent a sender from exploiting the link 124 capacity. 126 Coding is a reliability mechanism that is distinct and separate from 127 the loss detection of congestion controls. [RFC5681] defines the 128 loss-based congestion control of TCP; since FEC coding repairs such 129 losses, blindly applying it may easily lead to an implementation that 130 also hides a congestion signal from the sender. It is important to 131 ensure that such information hiding does not occur. 133 FEC coding and congestion control can be seen as two separate 134 channels. In practice, implementations may mix the signals that are 135 exchanged on these channels. This memo offers a discussion of how 136 FEC coding and congestion control coexist. Another objective is to 137 encourage the research community also to consider congestion control 138 aspects when proposing and comparing FEC coding solutions in 139 communication systems. This document does not aim at proposing 140 guidelines for characterizing FEC coding solutions. 142 We consider an end-to-end unicast data transfer with FEC coding in 143 the application (above the transport), within the transport or 144 directly below the transport. A typical scenario for the 145 considerations in this document is a client browsing the web or 146 watching a live video. 148 This document represents the collaborative work and consensus of the 149 Coding for Efficient Network Communications Research Group (NWCRG); 150 it is not an IETF product and is not a standard. The document 151 follows the terminology proposed in the taxonomy document [RFC8406]. 153 2. Context 155 2.1. Separate channels, separate entities 157 Figure 1 presents the notations that will be used in this document 158 and introduces the Forward Erasure Correction (FEC) and Congestion 159 Control (CC) channels. The Forward Erasure Correction channel 160 carries repair symbols (from the sender to the receiver) and 161 information from the receiver to the sender (e.g. signaling which 162 symbols have been recovered, loss rate prior and/or after decoding, 163 etc.). The Congestion Control channel carries network packets from a 164 sender to a receiver, and packets signaling information about the 165 network (number of packets received vs. lost, Explicit Congestion 166 Notification (ECN) marks, etc.) from the receiver to the sender. The 167 network packets that are sent by the Congestion Control channel may 168 be composed of source packets and/or repair symbols. 170 SENDER RECEIVER 172 +------+ +------+ 173 | | ----- network packets ---->| | 174 | CC | | CC | 175 | | <--- network information ---| | 176 +------+ +------+ 178 +------+ +------+ 179 | | source and/or | | 180 | | ----- repair symbols ---->| | 181 | FEC | | FEC | 182 | | signaling | | 183 | | <--- recovered symbols ----| | 184 +------+ +------+ 186 Figure 1: Notations and separate channels 188 Inside a host, the CC and FEC entities can be regarded as 189 conceptually separate: 191 | ^ | ^ 192 | source | coding |packets | sending 193 | packets | rate |requirements | rate (or 194 v | v | window) 195 +---------------+source +-----------------+ 196 | FEC |and/or | CC | 197 | |repair | |network 198 | |symbols | |packets 199 +---------------+==> +-----------------+==> 200 ^ ^ 201 | signaling | network 202 | recovered symbols | information 204 Figure 2: Separate entities (sender-side) 206 | | 207 | source and/or | network 208 | repair symbols | packets 209 v v 210 +---------------+ +-----------------+ 211 | FEC |signaling | CC | 212 | |recovered | |network 213 | |symbols | |information 214 +---------------+==> +-----------------+==> 216 Figure 3: Separate entities (receiver-side) 218 Figure 2 and Figure 3 provide more details than Figure 1. Some 219 elements are introduced: 221 o 'network information' (input control plane for the transport 222 including CC): refers not only to the network information that is 223 explicitly signaled from the receiver, but all the information a 224 congestion control obtains from a network (e.g., TCP can estimate 225 the latency and the available capacity at the bottleneck). 227 o 'requirements' (input control plane for the transport including 228 CC): refers to application requirements such as upper/lower rate 229 bounds, periods of quiescence, or a priority. 231 o 'sending rate (or window)' (output control plane for the transport 232 including CC): refers to the rate at which a congestion control 233 decides to transmit packets based on 'network information'. 235 o 'signaling recovered symbols' (input control plane for the FEC): 236 refers to the information a FEC sender can obtain from a FEC 237 receiver about the performance of the FEC solution as seen by the 238 receiver. 240 o 'coding rate' (output control plane for the FEC): refers to the 241 coding rate that is used by the FEC solution (i.e. proportion of 242 transmitted symbols that carry useful data). 244 o 'network packets' (output data plane for the CC): refers to the 245 data that is transmitted by a CC sender to a CC receiver. The 246 network packets may contain source and/or repair symbols. 248 o 'source and/or repair symbols' (data plane for the FEC): refers to 249 the data that is transmitted by a FEC sender to a FEC receiver. 250 The sender can decide to send source symbols only (meaning that 251 the coding rate is 0), repair symbols only (if the solution 252 decides not to send the original source symbols) or a mix of both. 254 The inputs to FEC (incoming data packets without repair symbols, and 255 signaling from the receiver about losses and/or recovered symbols) 256 are distinct from the inputs to CC. The latter calculates a sending 257 rate or window from network information, and it takes the packet to 258 send as input, sometimes along with application requirements such as 259 upper/lower rate bounds, periods of quiescence, or a priority. It is 260 not clear that the ACK signals feeding into a congestion control 261 algorithm are useful to FEC in their raw form, and vice versa - 262 information about recovered blocks may be quite irrelevant to a CC 263 algorithm. 265 2.2. Relation between transport layer and application requirements 267 The choice of the adequate transport layer may be related to 268 application requirements and the services offered by a transport 269 protocol [RFC8095]: 271 o The transport layer may provide an unreliable transport service 272 (e.g. UDP or DCCP [RFC4340]) or a partially reliable transport 273 service (e.g. SCTP with the partial reliability extension 274 [RFC3758] or QUIC with the unreliable datagram extension 275 [I-D.ietf-quic-datagram]). Depending on the amount of redundancy 276 and network conditions, there could be cases where it becomes 277 impossible to carry traffic. 279 o The transport layer may implement a retransmission mechanism to 280 guarantee the reliability of a data transfer (e.g. TCP). 281 Depending on how the FEC and CC functions are scheduled (FEC above 282 CC, FEC in CC, FEC below CC), the impact of reliable transport on 283 the FEC reliability mechanisms is different. 285 2.3. Scope of the document concerning transport multipath and multi- 286 streams applications 288 The application layer can be composed of several streams above FEC 289 and transport layers instances. The transport layer can exploit a 290 multipath mechanism. The different streams could exploit different 291 paths between the sender and the receiver. Moreover, a single-stream 292 application could also exploit a multipath transport mechanism. This 293 section describes what is in the scope of this document in regards 294 with multi-streams applications and multipath transport protocols. 296 The different combinations between multi-stream applications and 297 multipath transport are the following: (1) one application layer 298 stream as input packets above a combination of FEC and multipath 299 (Mpath) transport layers (Figure 4), and (2) multiple application 300 layer streams as input packets above a combination of FEC and 301 multipath (Mpath) or single path (Spath) transport layers (Figure 5). 302 This document further details cases I (in Section 3.7), II (in 303 Section 4.7) and III (in Section 5.7) illustrated in Figure 4. Cases 304 IV, V and VI of Figure 5 are related to how multiple streams are 305 managed by a single transport or FEC layer: this does not directly 306 concerns the interaction between FEC and the transport and is out of 307 the scope of this document. 309 CASE I CASE II CASE III 310 +---------------+ +---------------+ +---------------+ 311 | Stream 1 | | Stream 2 | | Stream 3 | 312 +---------------+ +---------------+ +---------------+ 314 +---------------+ +---------------+ +---------------+ 315 | FEC | | FEC | |Mpath Transport| 316 +---------------+ | in | +---------------+ 317 |Mpath Transport| 318 +---------------+ | | +-----+ +-----+ 319 |Mpath Transport| | | |Flow1|...|FlowM| 320 +---------------+ +---------------+ +-----+ +-----+ 322 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 323 |Flow1|...|FlowM| |Flow1|...|FlowM| | FEC |...| FEC | 324 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 326 Figure 4: Transport multipath and single stream applications - in the 327 scope of the document 329 CASE IV CASE V CASE VI 330 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 331 |Stream1|...|StreamM| |Stream1|...|StreamM| |Stream1|...|StreamM| 332 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 334 +-------------------+ +-------------------+ +-------------------+ 335 | | | FEC | | Mpath Transport | 336 | FEC | +-------------------+ +-------------------+ 337 | above/in/below | 338 | Spath Transport | +-------------------+ +-------------------+ 339 | | | Mpath Transport | | FEC | 340 +-------------------+ +-------------------+ +-------------------+ 342 +-------------------+ +-----+ +-----+ +-----+ +-----+ 343 | Flow | |Flow1| ... |FlowM| |Flow1| ... |FlowM| 344 +-------------------+ +-----+ +-----+ +-----+ +-----+ 346 Figure 5: Transport single path, transport multipath and multi-stream 347 applications - out of the scope of the document 349 2.4. Types of coding 351 [RFC8406] summarizes recommended terminology for Network Coding 352 concepts and constructs. In particular, the document identifies the 353 following coding types (among many others): 355 o Block Coding: Coding technique where the input Flow must first be 356 segmented into a sequence of blocks; FEC encoding and decoding are 357 performed independently on a per-block basis. 359 o Sliding Window Coding: general class of coding techniques that 360 rely on a sliding encoding window. 362 The decoding scheme may not be able to decode all the symbols. The 363 chance of decoding the erased packets depends on the size of the 364 encoding window, the coding rate and the distribution of erasure in 365 the transmission channel. The FEC channel may let the client 366 transmit information related to the need of supplementary symbols to 367 adapt the level of reliability. Partial and full reliability could 368 be envisioned. 370 o Full reliability: The receiver may hold symbols until the decoding 371 of source symbols is possible. In particular, if the codec does 372 not enable a subset of the system to be inverted, the receiver 373 would have to wait for a certain minimum amount of repair packets 374 before it can recover all the source symbols. 376 o Partial reliability: The receiver cannot deliver source symbols 377 that could not have been decoded to the upper layer. For a fixed 378 size of encoding window (for Sliding Window Coding) or of blocks 379 (for Block Coding) containing the source symbols, increasing the 380 amount of repair symbols would increase the chances of recovering 381 the erased symbols. However, this would impact on memory 382 requirements, on the cost of encoding and decoding processes and 383 on the network overhead. 385 2.5. Fairness, a policy concern 387 Traffic from or to different end users may share various types of 388 bottlenecks. When such a shared bottleneck does not implement some 389 form of flow protection, the share of the available capacity between 390 single flows can help assess when one flow starves the other. 392 As one example, for residential accesses, the data rate can be 393 guaranteed for the customer premises equipment, but not necessarily 394 for the end user. The quality of service that guarantees fairness 395 between the different clients can be seen as a policy concern 396 [I-D.briscoe-tsvarea-fair]. 398 While past efforts have focused on achieving fairness, quantifying 399 and limiting harm caused by new algorithms (or algorithms with 400 coding) is more practical [BEYONDJAIN]. This document considers 401 fairness as the impact of the addition of coded flows on non-coded 402 flows when they share the same bottleneck. It is assumed that the 403 non-coded flows respond to congestion signals from the network. This 404 document does not contribute to the definition of fairness at a wider 405 scale. 407 3. FEC above the transport 408 | source ^ source 409 | packets | packets 410 v | 411 +-------------+ +-------------+ 412 |FEC | signaling|FEC | 413 | | recovered| | 414 | | symbols| | 415 | | <==| | 416 +-------------+ +-------------+ 417 | source ^ ^ source 418 | and/or | sending | and/or 419 | repair | rate | repair 420 | symbols | (or window) | symbols 421 v | | 422 +-------------+ +-------------+ 423 |Transport | network|Transport | 424 |(incl. CC) | information| | 425 | |network <==| | 426 | |packets | | 427 +-------------+==> +-------------+ 429 SENDER RECEIVER 431 Figure 6: FEC above the transport 433 Figure 6 presents an architecture where FEC operates on top of the 434 transport. 436 The advantage of this approach is that the FEC overhead does not 437 contribute to congestion in the network. When congestion control is 438 implemented at the transport layer, the repair symbols are sent 439 following the congestion window or rate determined by the CC 440 mechanism. This can result in improved quality of experience for 441 latency sensitive applications such as VoIP or any not-fully reliable 442 services. 444 This approach requires that the transport protocol does not implement 445 a fully reliable in-order data transfer service (e.g., like TCP). 446 QUIC with unreliable datagram extension [I-D.ietf-quic-datagram] is 447 an example of a protocol for which this is relevant. In cases where 448 QUIC traffic is blocked and a fall-back to TCP is proposed, there is 449 a risk for bad interactions between TCP's full reliability and coding 450 schemes. For reliable transfers, coding usage does not guarantee 451 better performance; instead, it would mainly reduce goodput. 453 3.1. Fairness and impact on non-coded flows 455 The addition of coding within the flow does not influence the 456 interaction between coded and non-coded flows. This interaction 457 would mainly depend on the congestion controls associated with each 458 flow. 460 3.2. Congestion control and recovered symbols 462 The congestion control mechanism receives network packets and may not 463 be able to differentiate repair symbols from actual source ones. The 464 relevance of adding coding at the application layer is related to the 465 needs of the application. For real-time applications using an 466 unreliable or partially reliable transport, this approach may reduce 467 the number of losses perceived by the application. 469 3.3. Interactions between congestion control and coding rates 471 The coding rate applied at the application layer mainly depends on 472 the available rate or congestion window given by the congestion 473 control underneath. The coding rate could be adapted to avoid adding 474 overhead when the minimum required data rate of the application is 475 not provided by the congestion control underneath. When the 476 congestion control allows sending faster than the application needs, 477 adding coding can reduce packet losses and improve the quality of 478 experience (provided that an unreliable or partially reliable 479 transport is used). 481 3.4. On useless repair symbols 483 The discussion depends on application needs. The only case where 484 adding useless repair symbols does not obviously result in reduced 485 goodput is when the application rate is limited (e.g., VoIP traffic). 486 In this case, useless repair symbols would only impact the amount of 487 data generated in the network. Extra data in the network can, 488 however, increase the likelihood of increasing delay and/or packet 489 loss, which could provoke a congestion control reaction that would 490 degrade goodput. 492 3.5. On partial ordering 494 Irrespective of the transport protocol, a FEC mechanism does not 495 require to implement a reordering mechanism if the application does 496 not need it. However, if the application needs in-order delivery of 497 packets, a reordering mechanism at the receiver is required. 499 3.6. On partial reliability 501 The application may require partial reliability. In this case, the 502 coding rate of a FEC mechanism could be adapted based on inputs from 503 the application and the trade-off between latency and packet loss. 504 Partial reliability impacts the type of FEC and type of codec that 505 can be used, such as discussed in Section 2.4. 507 3.7. On multipath transport 509 Whether the transport protocol exploits multiple paths or not does 510 not have an impact on the FEC mechanism. 512 4. FEC within the transport 514 | source ^ source 515 | packets | packets 516 v | 517 +------------+ +------------+ 518 | Transport | | Transport | 519 | | | | 520 | +---+ +--+ | signaling| +---+ +--+ | 521 | |FEC| |CC| | recovered| |FEC| |CC| | 522 | +---+ +--+ | symbols| +---+ +--+ | 523 | | <==| | 524 | |network network| | 525 | |packets information| | 526 +------------+ ==> <==+------------+ 528 SENDER RECEIVER 530 Figure 7: FEC in the transport 532 Figure 7 presents an architecture where FEC operates within the 533 transport. The repair symbols are sent within what the congestion 534 window or calculated rate allows, such as in [CTCP]. 536 The advantage of this approach is that it allows a joint optimization 537 of CC and FEC. Moreover, the transmission of repair symbols does not 538 add congestion in potentially congested networks but helps repair 539 lost packets (such as tail losses). 541 For reliable transfers, including redundancy reduces goodput for long 542 transfers but the amount of repair symbols can be adapted, e.g. 543 depending on the congestion window size. There is a trade-off 544 between 1) the capacity that could have been exploited by application 545 data instead of transmitting source packets, and 2) the benefits 546 derived from transmitting repair symbols (e.g. unlocking the receive 547 buffer if it is limiting). The coding ratio needs to be carefully 548 designed. For small files, sending repair symbols when there is no 549 more data to transmit could help to reduce the transfer time. 550 Sending repair symbols can avoid the silence period between the 551 transmission of the last packet in the send buffer and 1) firing a 552 retransmission of lost packets, or 2) the transmission of new 553 packets. 555 4.1. Fairness and impact on non-coded flows 557 The addition of coding within the transport may impact the congestion 558 control mechanism and hide congestion losses. Specific interaction 559 between congestion controls and coding schemes can be proposed (see 560 Section 4.2, Section 4.3 and Section 4.4). If no specific 561 interaction is introduced, the coding scheme may hide congestion 562 losses from the congestion controller and the description of 563 Section 5 may apply. 565 4.2. Congestion control and recovered symbols 567 The receiver can differentiate between source packets and repair 568 symbols. The receiver may indicate both the number of source packets 569 received and repair symbols that were actually useful in the recovery 570 process of packets. 572 4.3. Interactions between congestion control and coding rates 574 There is an important flexibility in the trade-off, inherent to the 575 use of coding, between (1) reducing goodput when useless repair 576 symbols are transmitted and (2) helping to recover from losses 577 earlier than with retransmissions. The receiver may indicate to the 578 sender the number of packets that have been received or recovered. 579 The sender may use this information to tune the coding ratio. For 580 example, coupling an increased transmission rate with an increasing 581 or decreasing coding rate could be envisioned. A server may use a 582 decreasing coding rate as a probe of the channel capacity and adapt 583 the congestion control transmission rate. 585 4.4. On useless repair symbols 587 The sender may exploit the information given by the receiver to 588 reduce the number of useless repair symbols and the resulting goodput 589 reduction. 591 4.5. On partial ordering 593 The application may require in-order delivery of packets. In this 594 case, both FEC and transport layer mechanisms should guarantee that 595 packets are delivered in order. If partial ordering is requested by 596 the application, both the FEC and transport could relax the 597 constraints related to in-order delivery: reordering mechanisms at 598 the receiver may not be necessary. 600 4.6. On partial reliability 602 The application may require partial reliability. The reliability 603 offered by FEC may be sufficient, with no retransmission required. 604 This depends on application needs and the trade-off between latency 605 and loss. Partial reliability impacts the type of FEC and type of 606 codec that can be used, such as discussed in Section 2.4. 608 4.7. On transport multipath 610 The sender may adapt the coding rate of each of the single subpaths, 611 whether the congestion control is coupled or not. There is an 612 important flexibility on how the coding rate is tuned depending on 613 the characteristics of each subpath. 615 5. FEC below the transport 617 | source ^ source 618 | packets | packets 619 v | 620 +--------------+ +--------------+ 621 |Transport | network|Transport | 622 |(including CC)| information| | 623 | | <==| | 624 +--------------+ +--------------+ 625 | network packets ^ network packets 626 v | 627 +--------------+ +--------------+ 628 | FEC |source | FEC | 629 | |and/or signaling| | 630 | |repair recovered| | 631 | |symbols symbols| | 632 | |==> <==| | 633 +--------------+ +--------------+ 635 SENDER RECEIVER 637 Figure 8: FEC below the transport 639 Figure 8 presents an architecture where FEC is applied end-to-end 640 below the transport layer, but above the link layer. Note that it is 641 common to apply FEC at the link layer, where it contributes to the 642 total capacity that a link exposes to upper layers. This application 643 of FEC is out of scope of this document. This includes the use of 644 FEC on top of a link layer in scenarios where the link is known by 645 configuration. In the scenario considered here, the repair symbols 646 are sent on top of what is allowed by the congestion control. 648 Including redundancy adds traffic without reducing goodput but incurs 649 potential fairness issues. The effective bit-rate is higher than the 650 CC's computed fair share due to the transmission of repair symbols, 651 and losses are hidden from the transport. This may cause a problem 652 for loss-based congestion detection, but it is not a problem for 653 delay-based congestion detection. 655 The advantage of this approach is that it can result in performance 656 gains when there are persistent transmission losses along the path. 658 The drawback of this approach is that it can induce congestion in 659 already congested networks. The coding ratio needs to be carefully 660 designed. 662 Examples of the solution could be to add a given percentage of the 663 congestion window or rate as supplementary symbols, or to send a 664 fixed amount of repair symbols at a fixed rate. The redundancy flow 665 can be decorrelated from the congestion control that manages source 666 packets: a separate congestion control entity could be introduced to 667 manage the amount of recovered symbols to transmit on the FEC 668 channel. The separate congestion control instances could be made to 669 work together while adhering to priorities, as in coupled congestion 670 control for RTP media [RFC8699] in case all traffic can be assumed to 671 take the same path, or otherwise with a multipath congestion window 672 coupling mechanism as in Multipath TCP [RFC6356]. Another 673 possibility would be to exploit a lower than best-effort congestion 674 control [RFC6297] for repair symbols. 676 5.1. Fairness and impact on non-coded flows 678 The coding scheme may hide congestion losses from the congestion 679 controller. There are cases where this can drastically reduce the 680 goodput of non-coded flows. Depending on the congestion control, it 681 may be possible to signal to the congestion control mechanism that 682 there was congestion (loss) even when a packet has been recovered, 683 e.g. using ECN, to reduce the impact on the non-coded flows (see 684 Section 5.2 and [TENTET]). 686 5.2. Congestion control and recovered symbols 688 The congestion control may not be aware of the existence of a coding 689 scheme underneath it. The congestion control may behave as if no 690 coding scheme had been introduced. The only way for a coding channel 691 to indicate that symbols have been lost but recovered is to exploit 692 existing signaling that is understood by the congestion control 693 mechanism. An example would be to indicate to a TCP sender that a 694 packet has been received, yet congestion has occurred, by using ECN 695 signaling [TENTET]. 697 5.3. Interactions between congestion control and coding rates 699 The coding rate can be tuned depending on the number of recovered 700 symbols and the rate at which the sender transmits data. If the 701 coding scheme is not aware of the congestion control implementation, 702 it is hard for the coding scheme to apply the relevant coding rate. 704 5.4. On useless repair symbols 706 Useless repair symbols only impact the load on the network without 707 actual gain for the coded flow. Using feedback signaling, FEC 708 mechanisms can measure the ratio between actually used and useless 709 symbols, and adjust the coding rate. 711 5.5. On partial ordering 713 The transport above the FEC channel may support out-of-order delivery 714 of packets: reordering mechanisms at the receiver may not be 715 necessary. In cases where the transport requires in-order delivery, 716 the FEC channel may need to implement a reordering mechanism. 717 Otherwise, spurious retransmissions may occur at the transport level. 719 5.6. On partial reliability 721 The transport or application layer above the FEC channel may require 722 partial reliability only. In this case, FEC may provide an 723 unnecessary service if it is not aware of the reliability 724 requirements. Partial reliability impacts the type of FEC and type 725 of codec that can be used, such as discussed in Section 2.4. 727 5.7. On transport multipath 729 The transport may exploit multiple paths without the FEC channel 730 being aware of it. This depends on whether FEC is applied to all 731 subflows or each of the subflows individually. When FEC is applied 732 to all the flows, there is a risk for the coding rate to be 733 inadequate for the characteristics of the individual paths. 735 6. Research recommendations and questions 737 This section provides a short state-of-the art overview of activities 738 related to congestion control and coding. The objective is to 739 identify open research questions and contribute to advice when 740 evaluating coding mechanisms. 742 6.1. Activities related to congestion control and coding 744 We map activities related to congestion control and coding with the 745 organization presented in this document: 747 o For the FEC above transport case: [RFC8680]. 749 o For the FEC within transport case: 750 [I-D.swett-nwcrg-coding-for-quic], [QUIC-FEC], [RFC5109]. 752 o For the FEC below transport case: [NCTCP], 753 [I-D.detchart-nwcrg-tetrys]. 755 6.2. Open research questions 757 There is a general trade-off, inherent to the use of coding, between 758 (1) reducing goodput when useless repair symbols are transmitted and 759 (2) helping to recover from transmission and congestion losses. 761 6.2.1. Parameter derivation 763 There is a trade-off related to the amount of redundancy to add, as a 764 function of the transport layer protocol and application 765 requirements. 767 [RFC8095] describes the mechanisms provided by existing IETF 768 protocols such as TCP, SCTP or RTP. [RFC8406] describes the variety 769 of coding techniques. The important level of combinations makes the 770 determination of an optimum parameters derivation very complex. This 771 depends on application requirements and deployment context. 773 Appendix C of [RFC8681] describes how to tune the parameters for 774 target use-case. However, this discussion does not integrate 775 congestion-controlled end points. 777 Research question 1 : "Is there a way to dynamically adjust the codec 778 characteristics depending on the transmission channel, the transport 779 protocol and application requirements ?" 780 Research question 2 : "Should we apply specific per-stream FEC 781 mechanisms when multiple streams with different reliability needs are 782 carried out ?" 784 6.2.2. New signaling methods and fairness 786 Recovering lost symbols may hide congestion losses from the 787 congestion control. Disambiguate acked packets from rebuilt packets 788 would help the sender adapt its sending rate accordingly. There are 789 opportunities for introducing interaction between congestion control 790 and coding schemes to improve the quality of experience while 791 guaranteeing fairness with other flows. 793 Some existing solutions already propose to disambiguate acked packets 794 from rebuilt packets [QUIC-FEC]. New signaling methods and FEC- 795 recovery-aware congestion controls could be proposed. This would 796 allow the design of adaptive coding rates. 798 Research question 3 : "Should we quantify the harm that a coded flow 799 would induce on a non-coded flow ? How can this be reduced while 800 still benefiting from advantages brought by FEC ?" 802 Research question 4 : "If transport and FEC senders are collocated 803 and close to the client, and FEC is applied only on the last mile, 804 e.g. to ignore losses on a noisy wireless link, would this raise 805 fairness issues ?" 807 Research question 5 : "Should we propose a generic API to allow 808 dynamic interactions between a transport protocol and a coding scheme 809 ? This should consider existing APIs between application and 810 transport layers." 812 6.3. Recommendations and advice for evaluating coding mechanisms 814 Research Recommendation 1: "From a congestion control point-of-view, 815 a recovered packet must be considered as a lost packet. This does 816 not apply to the usage of FEC on a path that is known to be lossy." 818 Research Recommendation 2: "New research contributions should be 819 mapped following the organization of this document (above, below, in 820 the congestion control) and should consider congestion control 821 aspects when proposing and comparing FEC coding solutions in 822 communication systems." 824 Research Recommendation 3: "When a research work aims at improving 825 throughput by hiding the packet loss signal from congestion control 826 (e.g., because the path between the sender and receiver is known to 827 consist of a noisy wireless link), the authors should 1) discuss the 828 advantages of using the proposed FEC solution compared to replacing 829 the congestion control by one that ignores a portion of the 830 encountered losses, 2) critically discuss the impact of hiding packet 831 loss from the congestion control mechanism." 833 7. Acknowledgements 835 Many thanks to Spencer Dawkins, Dave Oran, Carsten Bormann, Vincent 836 Roca and Marie-Jose Montpetit for their useful comments that helped 837 improve the document. 839 8. IANA Considerations 841 This memo includes no request to IANA. 843 9. Security Considerations 845 FEC and CC schemes can contribute to DoS attacks. Moreover, the 846 transmission of signaling messages from the client to the server 847 should be protected and reliable otherwise an attacker may compromise 848 FEC rate adaptation. Indeed, an attacker could either modify the 849 values indicated by the client or drop signaling messages. 851 In case of FEC below the transport, the aggregate rate of source and 852 repair packets may exceed the rate at which a congestion control 853 mechanism allows an application to send. This could result in an 854 application obtaining more than its fair share of the network 855 capacity. 857 10. Informative References 859 [BEYONDJAIN] 860 Ware (et al.), R., "Beyond Jain's Fairness Index: Setting 861 the Bar For The Deployment of Congestion Control 862 Algorithms", HotNets '19 10.1145/3365609.3365855, 2019. 864 [CTCP] Kim (et al.), M., "Network Coded TCP (CTCP)", 865 arXiv 1212.2291v3, 2013. 867 [I-D.briscoe-tsvarea-fair] 868 Briscoe, B., "Flow Rate Fairness: Dismantling a Religion", 869 draft-briscoe-tsvarea-fair-02 (work in progress), July 870 2007. 872 [I-D.detchart-nwcrg-tetrys] 873 Detchart, J., Lochin, E., Lacan, J., and V. Roca, "Tetrys, 874 an On-the-Fly Network Coding protocol", draft-detchart- 875 nwcrg-tetrys-06 (work in progress), December 2020. 877 [I-D.ietf-quic-datagram] 878 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 879 Datagram Extension to QUIC", draft-ietf-quic-datagram-02 880 (work in progress), February 2021. 882 [I-D.swett-nwcrg-coding-for-quic] 883 Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding 884 for QUIC", draft-swett-nwcrg-coding-for-quic-04 (work in 885 progress), March 2020. 887 [NCTCP] Sundararajan (et al.), J., "Network Coding Meets TCP: 888 Theory and Implementation", IEEE 889 INFOCOM 10.1109/JPROC.2010.2093850, 2009. 891 [QUIC-FEC] 892 Michel (et al.), F., "QUIC-FEC: Bringing the benefits of 893 Forward Erasure Correction to QUIC", IFIP 894 Networking 10.23919/IFIPNetworking.2019.8816838, 2019. 896 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 897 Conrad, "Stream Control Transmission Protocol (SCTP) 898 Partial Reliability Extension", RFC 3758, 899 DOI 10.17487/RFC3758, May 2004, 900 . 902 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 903 Congestion Control Protocol (DCCP)", RFC 4340, 904 DOI 10.17487/RFC4340, March 2006, 905 . 907 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 908 Correction", RFC 5109, DOI 10.17487/RFC5109, December 909 2007, . 911 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 912 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 913 . 915 [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort 916 Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 917 2011, . 919 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 920 Congestion Control for Multipath Transport Protocols", 921 RFC 6356, DOI 10.17487/RFC6356, October 2011, 922 . 924 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 925 Ed., "Services Provided by IETF Transport Protocols and 926 Congestion Control Mechanisms", RFC 8095, 927 DOI 10.17487/RFC8095, March 2017, 928 . 930 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 931 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 932 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 933 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 934 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 935 June 2018, . 937 [RFC8680] Roca, V. and A. Begen, "Forward Error Correction (FEC) 938 Framework Extension to Sliding Window Codes", RFC 8680, 939 DOI 10.17487/RFC8680, January 2020, 940 . 942 [RFC8681] Roca, V. and B. Teibi, "Sliding Window Random Linear Code 943 (RLC) Forward Erasure Correction (FEC) Schemes for 944 FECFRAME", RFC 8681, DOI 10.17487/RFC8681, January 2020, 945 . 947 [RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion 948 Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, 949 January 2020, . 951 [TENTET] Lochin, E., "On the joint use of TCP and Network Coding", 952 NWCRG session IETF 100, 2017. 954 Authors' Addresses 956 Nicolas Kuhn 957 CNES 959 Email: nicolas.kuhn@cnes.fr 961 Emmanuel Lochin 962 ENAC 964 Email: emmanuel.lochin@enac.fr 966 Francois Michel 967 UCLouvain 969 Email: francois.michel@uclouvain.be 970 Michael Welzl 971 University of Oslo 973 Email: michawe@ifi.uio.no