idnits 2.17.1 draft-irtf-nwcrg-coding-and-congestion-02.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 227 has weird spacing: '...packets v pac...' == Line 269 has weird spacing: '...g about netwo...' == Line 270 has weird spacing: '... and/or inf...' -- The document date (March 5, 2020) is 1511 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. 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: September 6, 2020 ISAE-SUPAERO 6 F. Michel 7 UCLouvain 8 M. Welzl 9 University of Oslo 10 March 5, 2020 12 Coding and congestion control in transport 13 draft-irtf-nwcrg-coding-and-congestion-02 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 September 6, 2020. 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 and CC layering . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. FEC above the transport . . . . . . . . . . . . . . . . . 5 70 3.2. FEC within the transport . . . . . . . . . . . . . . . . 6 71 3.3. FEC below the transport . . . . . . . . . . . . . . . . . 7 72 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. Informative References . . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 There are cases where deploying FEC coding improves the performance 81 of a transmission. As an example, it may take time for the sender to 82 detect transfer tail losses (losses that occur at the end of a 83 transfer, where e.g. TCP obtains no more ACKs to quickly repair the 84 loss via retransmission). This would improve the experience of 85 applications using short flows. Another example are networks where 86 non-congestion losses are persistent and prevent a sender from 87 exploiting the link capacity. 89 Coding is a reliability mechanism that is distinct and separate from 90 the loss detection of congestion controls. [RFC5681] defines TCP as 91 a loss-based congestion control; because FEC coding repairs such 92 losses, blindly applying it may easily lead to an implementation that 93 also hides a congestion signal to the sender. It is important to 94 ensure that such information hiding does not occur. 96 FEC coding and congestion control can be seen as two separate 97 channels. In practice, implementations may mix the signals that are 98 exchanged on these channels. This memo offers a discussion of how 99 FEC coding and congestion control can coexist. Another objective is 100 to encourage the research community to also consider congestion 101 control aspects when proposing and comparing FEC coding solutions in 102 communication systems. This being said, this document does not aim 103 at proposing guidelines for characterizing FEC coding solutions: 104 comparing FEC Schemes without considering congestion control can be 105 relevant if the goal is to compare those schemes only. 107 The proposed document considers FEC coding at the transport or 108 application layer for an end-to-end unicast data transfer. The 109 typical application scenario that is considered in the current 110 version of the document is a client browsing the web. This memo may 111 be extended to cases with multiple paths. 113 This document represents the collaborative work and consensus of the 114 Coding for Efficient Network Communications Research Group (NWCRG); 115 it is not an IETF product and is not a standard. The document 116 follows the terminology proposed in the taxonomy document [RFC8406]. 118 2. Separate channels, separate entities 120 Figure 1 presents the notations that will be used in this document 121 and introduces the Congestion Control (CC) and Forward Erasure 122 Correction (FEC) channels. The Congestion Control channel carries 123 source packets from a sender to a receiver, and packets signaling 124 information about the network (number of packets received vs. lost, 125 ECN marks, etc.) from the receiver to the sender. The Forward 126 Erasure Correction channel carries repair packets (from the sender to 127 the receiver) and potential information signaling which packets have 128 been repaired (from the receiver to the sender). It is worth 129 pointing out that there are cases where these channels are not 130 separated. 132 Sender Receiver 134 +------+ +------+ 135 | | ----- source packets ---->| | 136 | CC | | CC | 137 | | <--- network information ---| | 138 +------+ +------+ 140 +------+ +------+ 141 | | ----- repair packets ---->| | 142 | FEC | | FEC | 143 | | <--- info: repaired packets --| | 144 +------+ +------+ 146 Figure 1: Notations and separate channels 148 Inside a host, the CC and FEC entities can be regarded as 149 conceptually separate: 151 | ^ | ^ 152 | source | coding |packets | sending 153 | packets | rate |requirements | rate (or 154 v | v | window) 155 +-------------------+source and/or +--------------------+ 156 | FEC |=> repair | CC |=> packets 157 +-------------------+ packets +--------------------+ 158 ^ ^ 159 | signaling about | network 160 | losses and/or | information 161 | repaired packets 163 Figure 2: Separate entities (sender-side) 165 Figure 2 provides more details than Figure 1 by focusing on the 166 sender-side. Some elements are introduced: 168 o 'network information' (input control plane for the transport 169 including CC): refers not only to the network information that is 170 explicitly signaled from the receiver, but all the information a 171 congestion control obtains from a network (e.g. TCP can estimate 172 the latency and the available capacity at the bottleneck). 174 o 'requirements' (input control plane for the transport including 175 CC): refers to application requirements such as upper/lower rate 176 bounds, periods of quiescence, or a priority. 178 o 'sending rate (or window)' (output control plane for the transport 179 including CC): refers to the rate at which a congestion control 180 decides to transmit packets, based on 'network information'. 182 o 'signaling about losses and/or repaired packets' (input control 183 plane for the FEC): refers to the information a FEC sender can 184 obtain from a FEC receiver about the performance of the FEC 185 solution as seen from the receiver. 187 o 'coding rate' (output control plane for the FEC): refers to the 188 coding rate that is used by the FEC solution. 190 o 'source and/or repair packets' (data plane for both the FEC and 191 the CC): refers to the packets that are transmitted. There can 192 only be source packets (if the coding rate is 0), repair packets 193 (if the solution decides not to send the original source packets) 194 or a mix of both. 196 The inputs to FEC (packets to work upon, and signaling from the 197 receiver about losses and/or repaired packets) are distinct from the 198 inputs to CC. The latter calculates a sending rate or window from 199 network information, and it takes the packet to send as input, 200 sometimes along with application requirements such as upper/lower 201 rate bounds, periods of quiescence, or a priority. 203 It is not clear that the ACK signals feeding into a congestion 204 control algorithm are useful to FEC in their raw form, and vice versa 205 - information about repaired blocks may be quite irrelevant to a CC 206 algorithm. 208 3. FEC and CC layering 210 This section discusses how FEC and CC can relate in different cases 211 (FEC above the transport, FEC within the transport, FEC below the 212 transport). 214 3.1. FEC above the transport 216 Figure 3 illustrates the FEC above the transport case. 218 | source 219 | packets 220 v 221 +------------------------------------+ 222 | FEC | 223 +------------------------------------+ 224 ^ | source ^ 225 | signaling about | and/or | sending rate 226 | losses and/or | repair | (or window) 227 | repaired packets v packets | 228 +-----------------+ 229 | Transport | source and/or 230 | (including CC) | repair packets 231 +-----------------+ ===> 232 ^ 233 | network 234 | information 236 Figure 3: FEC above the transport (sender-side) 238 Figure 3 presents an architecture where FEC is on top of the 239 transport. The repair packets are sent within what the congestion 240 window allows. 242 The advantage of this approach is that the FEC does not contribute to 243 adding congestion in the network. 245 While CC is in principle independent of other transport functions 246 such as reliability, we note that CC is often embedded in reliable 247 transfer protocols (e.g. TCP). This approach requires that the 248 transport protocol does not implement a fully reliable data transfer 249 service (e.g., based on lost packet retransmission). UDP is an 250 example of a protocol for which this approach is relevant. 252 3.2. FEC within the transport 254 Figure 4 illustrates the FEC within the transport case. 256 | 257 | source packets, 258 | requirements 259 v 260 +---------------------+ 261 | Transport | source and/or 262 | +-----+ +-----+ | repair packets 263 | | FEC | | CC | | ===> 264 | +-----+ +-----+ | 265 | | 266 +---------------------+ 267 ^ ^ 268 | | 269 signaling about network 270 losses and/or information 271 repaired packets 273 Figure 4: FEC in the transport (sender-side) 275 Figure 4 presents an architecture where FEC is within the transport. 276 The repair packets are sent within what the congestion window allows, 277 such as in [CTCP]. Examples of the solution would be sending repair 278 packets when there is no more data to transmit or preferably send 279 repair packets instead of the following packets in the send buffer. 281 The advantage of this approach is that it can enable conjoint 282 optimization between the CC and the FEC. Moreover, the transmission 283 of repair packets does not add congestion in potentially congested 284 networks but helps repair lost packets (such as tail losses). 286 The drawback of this approach is that it may not result in much gains 287 as opposed to classical retransmission mechanisms and it costs 288 bandwidth that could have been exploited to transmit source packets. 289 The coding ratio needs to be carefully designed. 291 3.3. FEC below the transport 293 Figure 5 illustrates the FEC below the transport case. 295 | source packets | sending rate 296 | requirements | (or window) 297 v v 298 +------------------------------------+ 299 | Transport (including CC) | 300 +------------------------------------+ 301 ^ | 302 | network | source packets 303 | information | 304 v 305 +-----------------+ source and/or 306 | FEC | repair packets 307 | | ===> 308 +-----------------+ 309 ^ 310 | signaling about 311 | losses and/or 312 | repaired packets 314 Figure 5: FEC below the transport (sender-side) 316 Figure 5 presents an architecture where FEC is below the transport. 317 The repair packets are sent on top of what is allowed by the 318 congestion control. Examples of the solution could be adding a given 319 percentage of the congestion window as supplementary packets or 320 sending a given amount of repair packets at a given rate. The 321 redundancy flow can be decorrelated from the congestion control that 322 manages source packets: a secondary congestion control could be 323 introduced underneath the FEC layer. The separate congestion control 324 mechanisms could be made to work together while adhering to 325 priorities, as in coupled congestion control for RTP media 326 [I-D.ietf-rmcat-coupled-cc]. Another possibility would be to exploit 327 a lower than best-effort congestion control [RFC6297] for repair 328 packets. 330 The advantage of this approach is that it can result in performance 331 gains when there are persistent transmission losses along the path. 333 The drawback of this approach is that it can induce congestion in 334 already congested networks. The coding ratio needs to be carefully 335 designed. 337 4. Acknowledgements 339 Many thanks to Spencer Dawkins, Dave Oran, Carsten Bormann, Vincent 340 Roca and Marie-Jose Montpetit for their useful comments that helped 341 improve the document. 343 5. IANA Considerations 345 This memo includes no request to IANA. 347 6. Security Considerations 349 FEC and CC schemes can contribute to DoS attacks. This is not 350 specific to this document. 352 In case of FEC below the transport, the aggregate rate of source and 353 repair packets may exceed the rate at which a congestion control 354 mechanism allows an application to send. This could result in an 355 application obtaining more than its fair share of the network 356 capacity. 358 7. Informative References 360 [CTCP] Kim (et al.), M., "Network Coded TCP (CTCP)", 361 arXiv 1212.2291v3, 2013. 363 [I-D.ietf-rmcat-coupled-cc] 364 Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion 365 control for RTP media", draft-ietf-rmcat-coupled-cc-09 366 (work in progress), August 2019. 368 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 369 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 370 . 372 [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort 373 Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 374 2011, . 376 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 377 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 378 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 379 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 380 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 381 June 2018, . 383 Authors' Addresses 385 Nicolas Kuhn 386 CNES 388 Email: nicolas.kuhn@cnes.fr 389 Emmanuel Lochin 390 ISAE-SUPAERO 392 Email: emmanuel.lochin@isae-supaero.fr 394 Francois Michel 395 UCLouvain 397 Email: francois.michel@uclouvain.be 399 Michael Welzl 400 University of Oslo 402 Email: michawe@ifi.uio.no