idnits 2.17.1 draft-irtf-nwcrg-coding-and-congestion-03.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 305 has weird spacing: '...packets inf...' -- The document date (July 9, 2020) is 1386 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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: January 10, 2021 ISAE-SUPAERO 6 F. Michel 7 UCLouvain 8 M. Welzl 9 University of Oslo 10 July 9, 2020 12 Coding and congestion control in transport 13 draft-irtf-nwcrg-coding-and-congestion-03 15 Abstract 17 FEC coding is a reliability mechanism that is distinct and separate 18 from the loss detection of congestion controls. Using FEC coding can 19 be a useful way to deal with transfer tail losses or with networks 20 having non-congestion losses. However, FEC coding mechanisms should 21 not hide congestion signals. This memo offers a discussion of how 22 FEC coding and congestion control can coexist. Another objective is 23 to encourage the research community to also consider congestion 24 control aspects when proposing and comparing FEC coding solutions in 25 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 January 10, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Separate channels, separate entities . . . . . . . . . . . . 3 68 3. FEC above the transport . . . . . . . . . . . . . . . . . . . 6 69 3.1. Flowchart . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. FEC within the transport . . . . . . . . . . . . . . . . . . 7 72 4.1. Flowchart . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. FEC below the transport . . . . . . . . . . . . . . . . . . . 8 75 5.1. Flowchart . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 9. Informative References . . . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 There are cases where deploying FEC coding improves the performance 86 of a transmission. As an example, it may take time for the sender to 87 detect transfer tail losses (losses that occur at the end of a 88 transfer, where e.g. TCP obtains no more ACKs to quickly repair the 89 loss via retransmission). This would improve the experience of 90 applications using short flows. Another example are networks where 91 non-congestion losses are persistent and prevent a sender from 92 exploiting the link capacity. 94 Coding is a reliability mechanism that is distinct and separate from 95 the loss detection of congestion controls. [RFC5681] defines TCP as 96 a loss-based congestion control; because FEC coding repairs such 97 losses, blindly applying it may easily lead to an implementation that 98 also hides a congestion signal to the sender. It is important to 99 ensure that such information hiding does not occur. 101 FEC coding and congestion control can be seen as two separate 102 channels. In practice, implementations may mix the signals that are 103 exchanged on these channels. This memo offers a discussion of how 104 FEC coding and congestion control can coexist. Another objective is 105 to encourage the research community to also consider congestion 106 control aspects when proposing and comparing FEC coding solutions in 107 communication systems. This being said, this document does not aim 108 at proposing guidelines for characterizing FEC coding solutions: 109 comparing FEC Schemes without considering congestion control can be 110 relevant if the goal is to compare those schemes only. 112 The proposed document considers FEC coding at the transport or 113 application layer for an end-to-end unicast data transfer. The 114 typical application scenario that is considered in the current 115 version of the document is a client browsing the web or watching a 116 live video. This memo may be extended to cases with multiple paths. 118 This document represents the collaborative work and consensus of the 119 Coding for Efficient Network Communications Research Group (NWCRG); 120 it is not an IETF product and is not a standard. The document 121 follows the terminology proposed in the taxonomy document [RFC8406]. 123 2. Separate channels, separate entities 125 Figure 1 presents the notations that will be used in this document 126 and introduces the Congestion Control (CC) and Forward Erasure 127 Correction (FEC) channels. The Congestion Control channel carries 128 source packets from a sender to a receiver, and packets signaling 129 information about the network (number of packets received vs. lost, 130 ECN marks, etc.) from the receiver to the sender. The Forward 131 Erasure Correction channel carries repair packets (from the sender to 132 the receiver) and potential information signaling which packets have 133 been repaired (from the receiver to the sender). It is worth 134 pointing out that there are cases where these channels are not 135 separated. 137 Sender Receiver 139 +------+ +------+ 140 | | ----- source packets ---->| | 141 | CC | | CC | 142 | | <--- network information ---| | 143 +------+ +------+ 145 +------+ +------+ 146 | | ----- repair packets ---->| | 147 | FEC | | FEC | 148 | | <--- info: repaired packets --| | 149 +------+ +------+ 151 Figure 1: Notations and separate channels 153 Inside a host, the CC and FEC entities can be regarded as 154 conceptually separate: 156 | ^ | ^ 157 | source | coding |packets | sending 158 | packets | rate |requirements | rate (or 159 v | v | window) 160 +---------------+source +-----------------+ 161 | FEC |and/or | CC | 162 | |repair | |source 163 | |packets | |packets 164 +---------------+==> +-----------------+==> 165 ^ ^ 166 | signaling about | network 167 | losses and/or | information 168 | repaired packets 170 Figure 2: Separate entities (sender-side) 172 | | 173 | source and/or | packets 174 | repair packets | 175 v v 176 +---------------+ +-----------------+ 177 | FEC |signaling | CC | 178 | |repaired | |network 179 | |packets | |information 180 +---------------+==> +-----------------+==> 181 repaired packets 183 Figure 3: Separate entities (client-side) 185 Figure 2 and Figure 3 provide more details than Figure 1. Some 186 elements are introduced: 188 o 'network information' (input control plane for the transport 189 including CC): refers not only to the network information that is 190 explicitly signaled from the receiver, but all the information a 191 congestion control obtains from a network (e.g. TCP can estimate 192 the latency and the available capacity at the bottleneck). 194 o 'requirements' (input control plane for the transport including 195 CC): refers to application requirements such as upper/lower rate 196 bounds, periods of quiescence, or a priority. 198 o 'sending rate (or window)' (output control plane for the transport 199 including CC): refers to the rate at which a congestion control 200 decides to transmit packets, based on 'network information'. 202 o 'signaling repaired packets' (input control plane for the FEC): 203 refers to the information a FEC sender can obtain from a FEC 204 receiver about the performance of the FEC solution as seen from 205 the receiver. 207 o 'coding rate' (output control plane for the FEC): refers to the 208 coding rate that is used by the FEC solution. 210 o 'source and/or repair packets' (data plane for both the FEC and 211 the CC): refers to the packets that are transmitted. There can 212 only be source packets (if the coding rate is 0), repair packets 213 (if the solution decides not to send the original source packets) 214 or a mix of both. 216 The inputs to FEC (packets to work upon, and signaling from the 217 receiver about losses and/or repaired packets) are distinct from the 218 inputs to CC. The latter calculates a sending rate or window from 219 network information, and it takes the packet to send as input, 220 sometimes along with application requirements such as upper/lower 221 rate bounds, periods of quiescence, or a priority. It is not clear 222 that the ACK signals feeding into a congestion control algorithm are 223 useful to FEC in their raw form, and vice versa - information about 224 repaired blocks may be quite irrelevant to a CC algorithm. 226 The choice of the adequate transport layer may be related to 227 application requirements: 229 o In the case of an unreliable data transfer, the transport layer 230 may implement a non-reliable transport layer (e.g. UDP or DCCP 231 [RFC4340] or a partially reliable transport protocol such as SCTP 232 with partial reliability [RFC3758]). Depending on the amount of 233 redundancy and network conditions, there could be cases where it 234 ends up being impossible to carry traffic. 236 o In the case of a reliable data transfer, the transport layer may 237 implement a retransmission mechanism to guarantee the reliability 238 of the file transfer (e.g. TCP). Depending on how the FEC and CC 239 functions are scheduled (FEC above CC, FEC in CC, FEC below CC), 240 the impact of a reliable transport on the FEC reliability 241 mechanisms is different. 243 3. FEC above the transport 245 3.1. Flowchart 247 | source ^ source 248 | packets | packets 249 v | 250 +-------------+ +-------------+ 251 |FEC | signaling|FEC | 252 | | repaired| | 253 | | packets| | 254 | | <==| | 255 +-------------+ +-------------+ 256 | source ^ ^ source 257 | and/or | sending | and/or 258 | repair | rate | repair 259 | packets | (or window) | packets 260 v | | 261 +-------------+ +-------------+ 262 |Transport |source network|Transport | 263 |(incl. CC) |and/or information| | 264 | |repair <==| | 265 | |packets | | 266 +-------------+==> +-------------+ 268 SERVER CLIENT 270 Figure 4: FEC above the transport 272 Figure 4 present an architecture where FEC is on top of the 273 transport. 275 3.2. Discussion 277 While CC is in principle independent of other transport functions 278 such as reliability, we note that CC is often embedded in reliable 279 transfer protocols (e.g. TCP). This approach may require that the 280 transport protocol does not implement a fully reliable data transfer 281 service (e.g., based on lost packet retransmission), otherwise this 282 could lead to spurious retransmissions. UDP is an example of a 283 protocol for which this approach is relevant. 285 The advantage of this approach is that the FEC does not contribute to 286 adding congestion in the network. When a congestion control is 287 implementedd at the transport layer, the repair packets are sent 288 within what the congestion window allows. 290 4. FEC within the transport 292 4.1. Flowchart 294 | source | sending ^ source 295 | packets | rate | packets 296 v v | 297 +------------+ +------------+ 298 | Transport | | Transport | 299 | | | | 300 | +---+ +--+ | signaling| +---+ +--+ | 301 | |FEC| |CC| | repaired| |FEC| |CC| | 302 | +---+ +--+ |source packets| +---+ +--+ | 303 | |and/or <==| | 304 | |repair network| | 305 | |packets information| | 306 +------------+ ==> <==+------------+ 308 SERVER CLIENT 310 Figure 5: FEC in the transport 312 Figure 5 presents an architecture where FEC is within the transport. 313 The repair packets are sent within what the congestion window allows, 314 such as in [CTCP]. 316 4.2. Discussion 318 The advantage of this approach is that it can enable conjoint 319 optimization between the CC and the FEC. Moreover, the transmission 320 of repair packets does not add congestion in potentially congested 321 networks but helps repair lost packets (such as tail losses). 323 The drawback of this approach is that it may not result in much gains 324 as opposed to classical retransmission mechanisms and it costs 325 bandwidth that could have been exploited to transmit source packets. 326 The coding ratio needs to be carefully designed. 328 Examples of the solution would be sending repair packets when there 329 is no more data to transmit or preferably send repair packets instead 330 of the following packets in the send buffer. 332 5. FEC below the transport 334 5.1. Flowchart 336 | source | sending rate ^ source 337 | packets | (or window) | packets 338 v v | 339 +--------------+ +--------------+ 340 |Transport | network|Transport | 341 |(including CC)| information| | 342 | | <==| | 343 +--------------+ +--------------+ 344 | source packets ^ source packets 345 v | 346 +--------------+ +--------------+ 347 | FEC |source | FEC | 348 | |and/or signaling| | 349 | |repair repaired| | 350 | |packets packets| | 351 | |==> <==| | 352 +--------------+ +--------------+ 354 SERVER CLIENT 356 Figure 6: FEC below the transport 358 Figure 6 presents an architecture where FEC is below the transport. 359 The repair packets are sent on top of what is allowed by the 360 congestion control. 362 5.2. Discussion 364 The advantage of this approach is that it can result in performance 365 gains when there are persistent transmission losses along the path. 367 The drawback of this approach is that it can induce congestion in 368 already congested networks. The coding ratio needs to be carefully 369 designed. 371 Examples of the solution could be adding a given percentage of the 372 congestion window as supplementary packets or sending a given amount 373 of repair packets at a given rate. The redundancy flow can be 374 decorrelated from the congestion control that manages source packets: 375 a secondary congestion control could be introduced underneath the FEC 376 layer. The separate congestion control mechanisms could be made to 377 work together while adhering to priorities, as in coupled congestion 378 control for RTP media [I-D.ietf-rmcat-coupled-cc]. Another 379 possibility would be to exploit a lower than best-effort congestion 380 control [RFC6297] for repair packets. 382 6. Acknowledgements 384 Many thanks to Spencer Dawkins, Dave Oran, Carsten Bormann, Vincent 385 Roca and Marie-Jose Montpetit for their useful comments that helped 386 improve the document. 388 7. IANA Considerations 390 This memo includes no request to IANA. 392 8. Security Considerations 394 FEC and CC schemes can contribute to DoS attacks. This is not 395 specific to this document. 397 In case of FEC below the transport, the aggregate rate of source and 398 repair packets may exceed the rate at which a congestion control 399 mechanism allows an application to send. This could result in an 400 application obtaining more than its fair share of the network 401 capacity. 403 9. Informative References 405 [CTCP] Kim (et al.), M., "Network Coded TCP (CTCP)", 406 arXiv 1212.2291v3, 2013. 408 [I-D.ietf-rmcat-coupled-cc] 409 Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion 410 control for RTP media", draft-ietf-rmcat-coupled-cc-09 411 (work in progress), August 2019. 413 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 414 Conrad, "Stream Control Transmission Protocol (SCTP) 415 Partial Reliability Extension", RFC 3758, 416 DOI 10.17487/RFC3758, May 2004, 417 . 419 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 420 Congestion Control Protocol (DCCP)", RFC 4340, 421 DOI 10.17487/RFC4340, March 2006, 422 . 424 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 425 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 426 . 428 [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort 429 Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 430 2011, . 432 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 433 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 434 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 435 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 436 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 437 June 2018, . 439 Authors' Addresses 441 Nicolas Kuhn 442 CNES 444 Email: nicolas.kuhn@cnes.fr 446 Emmanuel Lochin 447 ISAE-SUPAERO 449 Email: emmanuel.lochin@isae-supaero.fr 451 Francois Michel 452 UCLouvain 454 Email: francois.michel@uclouvain.be 456 Michael Welzl 457 University of Oslo 459 Email: michawe@ifi.uio.no