idnits 2.17.1 draft-kuhn-coding-congestion-transport-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 96: '... o The receiver MUST indicate to the ...' RFC 2119 keyword, line 102: '... o The sender 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 (October 27, 2019) is 1642 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, Ed. 5 Expires: April 29, 2020 ISAE-SUPAERO 6 F. Michel, Ed. 7 UCLouvain 8 October 27, 2019 10 Coding and congestion control in transport 11 draft-kuhn-coding-congestion-transport-00 13 Abstract 15 There are discussions on how loss-based congestion controls consider 16 lost packets that have been recovered by a coding mechanism. This 17 document analyses to what extent transport protocols could ignore 18 such signals and proposes best current practices on the interaction 19 between congestion control and coding mechanism at the transport 20 layer. Coding for tunnels is out-of-the scope of the document. 21 Examples of interest for the proposed solution is to better deal with 22 tail losses or with networks with non-congestion losses. 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 April 29, 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. Base solution description . . . . . . . . . . . . . . . . . . 2 60 3. Sender-side coding solutions . . . . . . . . . . . . . . . . 3 61 3.1. Coded packets without considering CWND progression . . . 3 62 3.2. Coded packets driven by CWND progression . . . . . . . . 3 63 4. Sender-side reaction to recovered packet signals . . . . . . 4 64 4.1. The sender congestion control considers recovered packet 65 signals as congestion-implied packet losses . . . . . . . 4 66 4.2. The sender adapts its window reduction to recovered 67 packet signals . . . . . . . . . . . . . . . . . . . . . 4 68 4.3. The sender ignores recovered packet signals . . . . . . . 5 69 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 71 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 10. Informative References . . . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 [RFC5681] defines TCP as a loss-based congestion control. Coding 80 mechanisms can be deployed and could hide congestion signals to the 81 sender. 83 Because loss-based and delay-based congestion controls are deployed 84 in the current Internet, this memo discusses simple best practices on 85 how coding and congestion control mechanisms could coexist. 87 The proposed recommendations apply for coding at the transport layer 88 (coding for tunnels is out-of-the scope of the document). Examples 89 of interest for the proposed solution is to better deal with tail 90 losses or with networks with non-congestion losses. 92 2. Base solution description 94 The base solution can be described as follows: 96 o The receiver MUST indicate to the sender that one or multiple 97 packets have been recovered using a coding scheme. Such "repaired 98 packet signal" could be based on existing signals (even if the 99 existing signal was not designed for that purpose, such as ECN) or 100 on new type of signals (such as a RECOVERED frame in QUIC). 102 o The sender MUST be able to detect the "recovered packet signal". 103 The base solution does not describe how the sender reacts to such 104 signal. 106 The proposed solution applies for coding in the transport layer. The 107 proposed approach is inline with the one in 108 [I-D.swett-nwcrg-coding-for-quic]. 110 The proposed solution does not applies for the interaction between 111 coding under the transport layer (i.e. not end-to-end), such as 112 coding for tunnels. 114 3. Sender-side coding solutions 116 This section presents solutions for a sender to add application 117 coding. 119 3.1. Coded packets without considering CWND progression 121 In this solution, the coded packets are sent on top of what is 122 allowed by a congestion window. Examples of the solution could be 123 adding a given pourcentage of the congestion window as supplementary 124 packets or sending a given amount of coded packets at a given rate. 125 The redundancy flow can be decorrelated from the congestion control 126 that manages source packets : a secondary congestion control can be 127 introduced, such as in coupled congestion control for RTP media 128 [I-D.ietf-rmcat-coupled-cc]. An example would be to exploit a lower 129 than best-effort congestion control [RFC6297]. 131 The advantage of such solution is that coding would help in 132 challenges cases where transmission losses are persistent. 134 The drawback of such solution is that it may result in coding 135 solutions being unfair towards non-coding solutions. This solutions 136 may result in adding congestion in congested networks. 138 3.2. Coded packets driven by CWND progression 140 In this solution, the coded packets are sent within what the 141 congestion window allows, such as in [CTCP]. Examples of the 142 solution would be sending coded packets when there is no more data to 143 transmit or preferably send coded packets instead of the following 144 packets in the send buffer. 146 The advantage of this solution is that it does not contribute in 147 adding more congestion than the congestion window allows. Indeed, 148 all traffic (source and redundancy) is controlled by one congestion 149 control only and TCP metrics for fairness can be indifferently 150 applied in this case. 152 The main drawback is the decrease of goodput if coded packets are 153 sent but are not used at the client side. 155 4. Sender-side reaction to recovered packet signals 157 Delay-based congestion controls ignore packets that have been 158 repaired with coding. There is no need to define best current 159 pratices in this case. However, more discussions are required for 160 congestion controls that use loss as congestion signals (potentially 161 among other congestion detection mechanism). 163 4.1. The sender congestion control considers recovered packet signals 164 as congestion-implied packet losses 166 In this solution, the sender reacts to recovered packet signals as to 167 congestion-implied packet losses. That being said, this does not 168 necessarily means that the packets have actually been lost. The 169 server may have other means to identify that the packet was just out- 170 of-ordered and ignore the recovered packet signals. 172 The advantages of the solution are (1) that coding mechanisms do not 173 hide congestion signals, such as packets voluntary dropped by a AQM 174 [RFC7567] and (2) packets may be recovered faster than with 175 traditionnal retransmission mechanisms. 177 The drawback of this solution is that, if there is a high non- 178 congestion loss rate, the congestion control throughput may decrease 179 drastically. Reporting this amount of loss to a sender may reduce 180 the application goodput when there is no actual congestion. 182 4.2. The sender adapts its window reduction to recovered packet signals 184 In this solution, the sender does not reduce the congestion window 185 with the same amount when the "recovered packet signal" is received, 186 i.e. when a packet has been lost but recovered. Example of this 187 solution could be based on [RFC8511] or considering that recovering 188 an isolated packet is not an actual sign of congestion. 190 The advantage of the solution is that in cases where there is no 191 actual congestion, coding could help in improving the transmission 192 without ignoring congestion signals. 194 The main drawback is the precised design of the solution and its 195 interaction with AQM mechanisms [RFC7567]. Moreover there may be 196 fairness issues since AIMD convergence may not be guaranteed. 198 4.3. The sender ignores recovered packet signals 200 This is the case for delay-based congestion controls. The 201 interaction between delay-based congestion controls and the delay 202 induced by a coding mechanisms is an open research activity. That 203 being said, a potential approach would be that loss-based congestion 204 control ignores the "recovered packet signal". 206 The advantage of this solution is that coding would provided 207 substantial benefits in cases where there are transmission losses. 209 However, this solution hides potential congestion losses, making it 210 unfair to other congestion controls. 212 5. Summary 214 This section provides a summary on the content in previous sections. 215 The Figure 1 sums up some recommendations. It is worth pointing out 216 that the "coding without congestion" considers that coded packets are 217 sent along with original data packets, in opposition with the 218 solution where coded packets are transmitted only when there is no 219 more original packets to transmit. Moreover, the values indicated in 220 this Figure consider a channel that does not exhibit a high loss 221 pattern. 223 +-----------------------+--------------------------------+ 224 | Sender-side reaction | Sender-side coding solutions | 225 | to recovered packet | | 226 | signals | | 227 | +---------------+----------------+ 228 | | Coding adding | Coding without | 229 | | congestion | congestion | 230 +-----------------------+---------------+----------------+ 231 | React as loss | fairness: ~ | fairness: ++ | 232 | | real-time: + | real-time: + | 233 | | bulk: ~ | bulk: - | 234 +-----------------------+---------------+----------------+ 235 | Adapt window reduction| fairness: ~ | fairness: + | 236 | | real-time: + | real-time: + | 237 | | bulk: + | bulk: - | 238 +-----------------------+---------------+----------------+ 239 | Ignore signals | fairness: - | fairness: - | 240 | | real-time: + | real-time: + | 241 | | bulk: + | bulk: - | 242 +-----------------------+---------------+----------------+ 244 Figure 1: Recommendations 246 6. Acknowledgements 248 Many thanks to TBD. 250 7. Contributors 252 TBD 254 8. IANA Considerations 256 This memo includes no request to IANA. 258 9. Security Considerations 260 Security section goes here. 262 10. Informative References 264 [CTCP] Kim (et al.), M., "Network Coded TCP (CTCP)", 265 arXiv 1212.2291v3, 2013. 267 [I-D.ietf-rmcat-coupled-cc] 268 Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion 269 control for RTP media", draft-ietf-rmcat-coupled-cc-09 270 (work in progress), August 2019. 272 [I-D.swett-nwcrg-coding-for-quic] 273 Swett, I., Montpetit, M., Roca, V., and F. Michel, "Coding 274 for QUIC", draft-swett-nwcrg-coding-for-quic-03 (work in 275 progress), July 2019. 277 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 278 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 279 . 281 [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort 282 Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 283 2011, . 285 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 286 Recommendations Regarding Active Queue Management", 287 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 288 . 290 [RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 291 "TCP Alternative Backoff with ECN (ABE)", RFC 8511, 292 DOI 10.17487/RFC8511, December 2018, 293 . 295 Authors' Addresses 297 Nicolas Kuhn (editor) 298 CNES 300 Email: nicolas.kuhn@cnes.fr 302 Emmanuel Lochin (editor) 303 ISAE-SUPAERO 305 Email: emmanuel.lochin@isae-supaero.fr 307 Francois Michel (editor) 308 UCLouvain 310 Email: francois.michel@uclouvain.be