idnits 2.17.1 draft-irtf-nwcrg-coding-and-congestion-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 126: '... o The client MUST indicate to the ...' RFC 2119 keyword, line 132: '... o The server MUST be able to detec...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 5, 2019) is 1602 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-swett-nwcrg-coding-for-quic-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NWCRG N. Kuhn, Ed. 3 Internet-Draft CNES 4 Intended status: Informational E. Lochin 5 Expires: June 7, 2020 ISAE-SUPAERO 6 F. Michel 7 UCLouvain 8 M. Welzl 9 University of Oslo 10 December 5, 2019 12 Coding and congestion control in transport 13 draft-irtf-nwcrg-coding-and-congestion-00 15 Abstract 17 This document discusses the interaction between congestion control 18 and coding mechanism at the transport layer. The scope of the 19 document is end-to-end communications. Examples of interest for the 20 proposed solution is to better deal with tail losses or with networks 21 with non-congestion losses. Coding for tunnels is out-of-the scope 22 of the document. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 7, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Separate channels . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Base solution description . . . . . . . . . . . . . . . . . . 3 61 4. Server-side coding solutions . . . . . . . . . . . . . . . . 4 62 4.1. Coded packets without considering CWND progression . . . 4 63 4.2. Coded packets driven by CWND progression . . . . . . . . 4 64 5. Server-side reaction to recovered packet signals . . . . . . 4 65 5.1. The server congestion control considers recovered packet 66 signals as congestion-implied packet losses . . . . . . . 5 67 5.2. The server adapts its window reduction to recovered 68 packet signals . . . . . . . . . . . . . . . . . . . . . 5 69 5.3. The server ignores recovered packet signals . . . . . . . 5 70 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 10. Informative References . . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 There are cases where deploying coding improves the quality of the 80 transmission. As example, the server may hardly detect tail losses 81 that impact may impact the application layer. Another example may be 82 the networks where non-congestion losses are persistent and prevent 83 the server from exploiting the link capacity. [RFC5681] defines TCP 84 as a loss-based congestion control and coding mechanisms can hide 85 congestion signals to the server. This memo discusses simple best 86 practices on how coding and congestion control mechanisms could 87 coexist. 89 The proposed recommendations apply for coding at the transport or 90 application layer and coding for tunnels is out-of-the scope of the 91 document. 93 2. Separate channels 95 Figure 1 presents the notations that will be used in this document 96 and introduce the Congestion Control (CC) and Forward Erasure 97 Correction (FEC) channels. Congestion Control channel carries data 98 packets (from the server to the client) and a potential information 99 signaling the packets that have been received (from the client to the 100 server). Forward Erasure Correction channel carries coded packets 101 (from the server to the client) and a potiential information 102 signaling the packets that have been repaired (from the client to the 103 server). It is worth pointing out that there are cases where these 104 channels are not separated. 106 Client Server 108 +------+ +------+ 109 | | -- { data packet -----| | 110 | CC | | CC | 111 | | -- received packet } --| | 112 +------+ +------+ 114 +------+ +------+ 115 | | -- { coded packet ----| | 116 | FEC | | FEC | 117 | | -- repaired packet } --| | 118 +------+ +------+ 120 Figure 1: Notations and separate channels 122 3. Base solution description 124 The base solution can be described as follows: 126 o The client MUST indicate to the server that one or multiple 127 packets have been recovered using a coding scheme. Such "repaired 128 packet signal" could be based on existing signals (even if the 129 existing signal was not designed for that purpose, such as ECN) or 130 on new type of signals (such as a RECOVERED frame in QUIC). 132 o The server MUST be able to detect the "recovered packet signal". 133 The base solution does not describe how the server reacts to such 134 signal. 136 The proposed solution applies for coding in the transport layer. The 137 proposed approach is inline with the one in 138 [I-D.swett-nwcrg-coding-for-quic]. The proposed solution does not 139 applies for the interaction between coding under the transport layer 140 (i.e. not end-to-end), such as coding for tunnels. 142 4. Server-side coding solutions 144 This section presents solutions for a server to add application 145 coding. 147 4.1. Coded packets without considering CWND progression 149 In this solution, the coded packets are sent on top of what is 150 allowed by a congestion window. Examples of the solution could be 151 adding a given pourcentage of the congestion window as supplementary 152 packets or sending a given amount of coded packets at a given rate. 153 The redundancy flow can be decorrelated from the congestion control 154 that manages source packets : a secondary congestion control can be 155 introduced, such as in coupled congestion control for RTP media 156 [I-D.ietf-rmcat-coupled-cc]. An example would be to exploit a lower 157 than best-effort congestion control [RFC6297]. 159 The advantage of such solution is that coding would help in 160 challenges cases where transmission losses are persistent. 162 The drawback of such solution is that it may result in coding 163 solutions being unfair towards non-coding solutions. This solutions 164 may result in adding congestion in congested networks. 166 4.2. Coded packets driven by CWND progression 168 In this solution, the coded packets are sent within what the 169 congestion window allows, such as in [CTCP]. Examples of the 170 solution would be sending coded packets when there is no more data to 171 transmit or preferably send coded packets instead of the following 172 packets in the send buffer. 174 The advantage of this solution is that it does not contribute in 175 adding more congestion than the congestion window allows. Indeed, 176 all traffic (source and redundancy) is controlled by one congestion 177 control only and TCP metrics for fairness can be indifferently 178 applied in this case. 180 The main drawback is the decrease of goodput if coded packets are 181 sent but are not used at the client side. 183 5. Server-side reaction to recovered packet signals 185 Delay-based congestion controls ignore packets that have been 186 repaired with coding. There is no need to define best current 187 pratices in this case. However, more discussions are required for 188 congestion controls that use loss as congestion signals (potentially 189 among other congestion detection mechanism). 191 5.1. The server congestion control considers recovered packet signals 192 as congestion-implied packet losses 194 In this solution, the server reacts to recovered packet signals as to 195 congestion-implied packet losses. That being said, this does not 196 necessarily means that the packets have actually been lost. The 197 server may have other means to identify that the packet was just out- 198 of-ordered and ignore the recovered packet signals. 200 The advantages of the solution are (1) that coding mechanisms do not 201 hide congestion signals, such as packets voluntary dropped by a AQM 202 [RFC7567] and (2) packets may be recovered faster than with 203 traditionnal retransmission mechanisms. 205 The drawback of this solution is that, if there is a high non- 206 congestion loss rate, the congestion control throughput may decrease 207 drastically. Reporting this amount of loss to a server may reduce 208 the application goodput when there is no actual congestion. 210 5.2. The server adapts its window reduction to recovered packet signals 212 In this solution, the server does not reduce the congestion window 213 with the same amount when the "recovered packet signal" is received, 214 i.e. when a packet has been lost but recovered. Example of this 215 solution could be based on [RFC8511] or considering that recovering 216 an isolated packet is not an actual sign of congestion. 218 The advantage of the solution is that in cases where there is no 219 actual congestion, coding could help in improving the transmission 220 without ignoring congestion signals. 222 The main drawback is the precised design of the solution and its 223 interaction with AQM mechanisms [RFC7567]. Moreover there may be 224 fairness issues since AIMD convergence may not be guaranteed. 226 5.3. The server ignores recovered packet signals 228 This is the case for delay-based congestion controls. The 229 interaction between delay-based congestion controls and the delay 230 induced by a coding mechanisms is an open research activity. That 231 being said, a potential approach would be that loss-based congestion 232 control ignores the "recovered packet signal". 234 The advantage of this solution is that coding would provided 235 substantial benefits in cases where there are transmission losses. 237 However, this solution hides potential congestion losses, making it 238 unfair to other congestion controls. 240 6. Summary 242 This section provides a summary on the content in previous sections. 243 The Figure 2 sums up some recommendations. It is worth pointing out 244 that the "coding without congestion" considers that coded packets are 245 sent along with original data packets, in opposition with the 246 solution where coded packets are transmitted only when there is no 247 more original packets to transmit. Moreover, the values indicated in 248 this Figure consider a channel that does not exhibit a high loss 249 pattern. 251 +-----------------------+--------------------------------+ 252 | Server-side reaction | Server-side coding solutions | 253 | to recovered packet | | 254 | signals | | 255 | +---------------+----------------+ 256 | | Coding adding | Coding without | 257 | | congestion | congestion | 258 +-----------------------+---------------+----------------+ 259 | React as loss | fairness: ~ | fairness: ++ | 260 | | real-time: + | real-time: + | 261 | | bulk: ~ | bulk: - | 262 +-----------------------+---------------+----------------+ 263 | Adapt window reduction| fairness: ~ | fairness: + | 264 | | real-time: + | real-time: + | 265 | | bulk: + | bulk: - | 266 +-----------------------+---------------+----------------+ 267 | Ignore signals | fairness: - | fairness: - | 268 | | real-time: + | real-time: + | 269 | | bulk: + | bulk: - | 270 +-----------------------+---------------+----------------+ 272 Figure 2: Recommendations 274 7. Acknowledgements 276 Many thanks to Spencer Dawkins, Dave Oran, Carsten Bormann, Vincent 277 Roca and Marie-Jose Montpetit for their useful comments that helped 278 improve the document. 280 8. IANA Considerations 282 This memo includes no request to IANA. 284 9. Security Considerations 286 There is no security considerations required for this document. 288 10. Informative References 290 [CTCP] Kim (et al.), M., "Network Coded TCP (CTCP)", 291 arXiv 1212.2291v3, 2013. 293 [I-D.ietf-rmcat-coupled-cc] 294 Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion 295 control for RTP media", draft-ietf-rmcat-coupled-cc-09 296 (work in progress), August 2019. 298 [I-D.swett-nwcrg-coding-for-quic] 299 Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding 300 for QUIC", draft-swett-nwcrg-coding-for-quic-03 (work in 301 progress), July 2019. 303 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 304 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 305 . 307 [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort 308 Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 309 2011, . 311 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 312 Recommendations Regarding Active Queue Management", 313 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 314 . 316 [RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 317 "TCP Alternative Backoff with ECN (ABE)", RFC 8511, 318 DOI 10.17487/RFC8511, December 2018, 319 . 321 Authors' Addresses 323 Nicolas Kuhn (editor) 324 CNES 326 Email: nicolas.kuhn@cnes.fr 327 Emmanuel Lochin 328 ISAE-SUPAERO 330 Email: emmanuel.lochin@isae-supaero.fr 332 Francois Michel 333 UCLouvain 335 Email: francois.michel@uclouvain.be 337 Michael Welzl 338 University of Oslo 340 Email: michawe@ifi.uio.no