idnits 2.17.1 draft-gomez-tcpm-delack-suppr-reqs-01.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 26, 2020) is 1491 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-lwig-tcp-constrained-node-networks-09 == Outdated reference: A later version (-15) exists of draft-ietf-tcpm-rack-08 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM Working Group C. Gomez 3 Internet-Draft UPC 4 Intended status: Informational J. Crowcroft 5 Expires: September 27, 2020 University of Cambridge 6 March 26, 2020 8 Sender Control of Delayed Acknowledgments in TCP: Problem Statement, 9 Requirements and Analysis of Potential Solutions 10 draft-gomez-tcpm-delack-suppr-reqs-01 12 Abstract 14 TCP Delayed Acknowledgments (ACKs) allow reducing protocol overhead 15 in many scenarios. However, in some cases, Delayed ACKs may 16 significantly degrade network and device performance in terms of link 17 utilization, latency, memory usage and/or energy consumption. This 18 document presents the problem statement regarding sender control of 19 Delayed ACKs in TCP. The document discusses the scenarios and use 20 cases in which sender control of Delayed ACKs offers advantages. 21 Then, requirements for a potential solution are derived. Finally, a 22 number of potential solutions are discussed, based on the 23 requirements, and also considering pros and cons in each case. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 27, 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 3. Problem statement: issues due to Delayed ACKs . . . . . . . . 3 62 3.1. Slow start . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.2. High bit rate environments and short data segments . . . 4 64 3.3. IoT scenarios . . . . . . . . . . . . . . . . . . . . . . 4 65 3.4. Beyond classic ACK transmission behavior . . . . . . . . 4 66 4. Requirements for sender control of Delayed ACKs . . . . . . . 5 67 4.1. Sender-triggered mechanism . . . . . . . . . . . . . . . 5 68 4.2. Per-segment granularity . . . . . . . . . . . . . . . . . 5 69 4.3. Header/Message overhead . . . . . . . . . . . . . . . . . 6 70 4.4. Support for enabling generic ACK ratios . . . . . . . . . 6 71 4.5. Middlebox traversal . . . . . . . . . . . . . . . . . . . 6 72 4.6. Safe return to normal Delayed ACKs operation . . . . . . 6 73 4.7. Impact on existing TCP functionality . . . . . . . . . . 7 74 4.8. Impact on future TCP development . . . . . . . . . . . . 7 75 4.9. Avoidance of 'hacks' . . . . . . . . . . . . . . . . . . 7 76 4.10. Who is in control? . . . . . . . . . . . . . . . . . . . 7 77 5. Potential solutions for sender control of Delayed ACKs . . . 7 78 5.1. AckCC . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 5.2. TLP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 5.3. TCP ACK Pull (AKP) flag . . . . . . . . . . . . . . . . . 8 81 5.4. A new 'ACK Pull' TCP option . . . . . . . . . . . . . . . 9 82 5.5. Reuse of existing TCP header fields . . . . . . . . . . . 9 83 5.6. 'Hacks' . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 89 9.2. Informative References . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 Delayed Acknowledgments (ACKs) were specified for TCP with the aim to 95 reduce protocol overhead [RFC1122]. With Delayed ACKs, a TCP delays 96 sending an ACK by up to 500 ms (often 200 ms, with lower values in 97 recent implementations such as ~50 ms also reported), and typically 98 sends an ACK for at least every second segment received in a stream 99 of full-sized segments. This allows combining several segments into 100 a single one (e.g. the application layer response to an application 101 layer data message, and the corresponding ACK), and it also saves up 102 to one of every two ACKs under many traffic patterns (e.g. bulk 103 transfers). The "SHOULD" requirement level for implementing Delayed 104 ACKs in RFC 1122, along with its expected benefits, has led to a 105 widespread deployment of this mechanism. 107 However, there exist traffic patterns and scenarios for which Delayed 108 ACKs can actually be detrimental to performance. When a segment 109 carrying a message of a size up to one Maximum Segment Size (MSS) is 110 transferred, if the message does not elicit an application-layer 111 response, and a second data segment is not transferred earlier than 112 the Delayed ACK timeout, the ACK is unnecessarily delayed, with a 113 number of negative consequences. Furthermore, there may be reasons 114 to allow a sender communicate the ACK ratio to be used in a TCP 115 connection, and thus dynamically override (or restore) use of Delayed 116 ACKs at the receiver. 118 This document presents the problem statement regarding sender control 119 of Delayed ACKs. The document discusses the scenarios and use cases 120 in which sender control of Delayed ACKs offers advantages. Then, 121 requirements for a potential solution are derived. Finally, a number 122 of potential solutions are discussed, based on the requirements, and 123 also considering pros and cons in each case. 125 2. Conventions used in this document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 3. Problem statement: issues due to Delayed ACKs 133 This section provides scenarios and use cases where performance 134 issues arise due to Delayed ACKs. 136 3.1. Slow start 138 During slow start, the congestion window (cwnd) increases by up to 139 Sender Maximum Segment Size (SMSS) upon receipt of an ACK covering 140 new data [RFC5681]. However, use of Delayed ACKs reduces the amount 141 of ACKs received by the sender, thus reducing the rate of cwnd 142 growth, increasing transfer time and reducing throughput, when 143 compared with sending an ACK for each incoming data segment. Note 144 that, while Appropriate Byte Counting (ABC) [RFC3465] might be used 145 to address this problem, it remains as an experimental mechanism, not 146 fully included in RFC 5681, which specifies standard TCP congestion 147 control. Furthermore, Delayed ACKs preclude using sender behaviors 148 intended to quickly and non-intrusively probe for available capacity 149 during slow start. One example of such behaviors is chirping, where 150 a sender follows a predetermined pattern to send data segments (e.g. 151 decreasing intersegment time gaps) and measures the gaps between ACKs 152 [I-D.kuehlewind-tcpm-accurate-ecn] (see Appendix B.4 of revision -03 153 of the referenced document). 155 3.2. High bit rate environments and short data segments 157 When the Nagle algorithm is used, in some cases the sender may be 158 prevented from sending more data while awaiting a delayed ACK. In 159 some high bit rate environment (e.g. Gigabit Ethernet) use cases, 160 such a delay may be very large, and link utilitzation may be 161 dramatically reduced, since the Delayed ACK timeout may be several 162 orders of magnitude greater than the Round Trip Time (RTT) [RFC8490]. 164 3.3. IoT scenarios 166 Delayed ACKs are also detrimental in Internet of Things (IoT) 167 scenarios, where TCP is being increasingly used 168 [I-D.ietf-lwig-tcp-constrained-node-networks]. Many IoT devices, 169 such as sensors, transfer small messages (e.g. containing sensor 170 readings) rather infrequently, therefore if the receiver uses Delayed 171 ACKs, the ACK will often be unnecessarily delayed. The sender cannot 172 release the memory resources associated to a transferred data segment 173 until the ACK is received and processed. This may be a problem for 174 many IoT devices, which are typically memory-constrained, and may 175 even lead to subsequent packet drops if their scarce memory resources 176 are blocked while awaiting an ACK. Moreover, if the IoT device uses 177 a radio interface for communication, in some scenarios Delayed ACKs 178 will lead to increased energy consumption (e.g. with the radio 179 interface of the device staying in receive mode while awaiting the 180 ACK). Since many IoT devices run on small batteries, the device 181 lifetime may significantly decrease. Furthermore, the delay suffered 182 by the ACK may interact negatively with layer two mechanisms, 183 especially in wireless network technologies where devices remain in 184 low-power states for long intervals [RFC8352], potentially leading to 185 a further exacerbated delay (by even one or more orders of 186 magnitude). 188 3.4. Beyond classic ACK transmission behavior 190 In some scenarios, it may be desirable to enable ACK transmission 191 behaviors beyond the classic ones. 193 For example, it may be beneficial to apply congestion control to ACKs 194 [RFC5690]. Reducing the amount of ACKs on a congested reverse path 195 may allow alleviating congestion on that path, with minimal impact on 196 a relatively independent forward path. 198 On the other hand, in some scenarios, the rate at which ACKs arrive 199 at the sender limits the achievable performance of data transfer. 200 This happens due to forward and reverse path asymmetric capacity 201 (with the latter being significantly limited, e.g. in terms of 202 bandwidth) [RFC3449]. In some environments, the issue is mitigated 203 by using middleboxes that perform ACK thinning, i.e., deleting a 204 subset of the ACKs. Examples of technologies where deployments have 205 been reported to do ACK thinning include satellite links, DOCSIS 206 cable networks, mobile cellular networks, among others. 208 4. Requirements for sender control of Delayed ACKs 210 This section provides the requirements for a potential solution to 211 enable sender control of Delayed ACKs. 213 4.1. Sender-triggered mechanism 215 An assumption is that the sender knows when Delayed ACKs operation 216 should be overriden. For example, the sender may know in advance the 217 pattern of the traffic it will generate, or it may know whether an 218 application-layer response will be sent by the receiving endpoint 219 upon reception of a given message. Therefore, control of Delayed 220 ACKs has to be sender-triggered. 222 4.2. Per-segment granularity 224 One approach that cannot be recommended as a general solution for 225 controlling Delayed ACKs is (permanently) disabling Delayed ACKs at 226 the receiving TCP. In fact, the latter may interact with a wide 227 variety of devices and many of those may still benefit from the 228 advantages of Delayed ACKs. 230 Another approach would be determining suppression of Delayed-ACKs per 231 connection. However, within the same connection, a sender may offer 232 a mixed traffic pattern comprising single data segments that will 233 lead to unnecessarily delayed ACKs, with other data segments upon 234 which Delayed ACKs will act as intended. Therefore, the solution has 235 to be provided at a per-segment granularity. 237 4.3. Header/Message overhead 239 Since the presented problem is about low performance in various 240 scenarios, another requirement for the solution is to minimize 241 incurring overhead in terms of header size increase or additional 242 packets sent. For example, in IoT scenarios, every additional 243 communicated byte consumes scarce resources (e.g. energy, bandwidth 244 and computational resources). 246 Another benefit of keeping a low header/message overhead is 247 alleviating the processing workload of a receiving TCP. 249 4.4. Support for enabling generic ACK ratios 251 For many of the scenarios and use cases described in Section 2, an 252 ACK ratio of 1 (i.e. a receiver sending one ACK per incoming data 253 segment) would solve the mentioned issues. However, the ability of 254 enforcing a generic ACK ratio (including values different from 1 and 255 2) allows to enable a wider range of ACK behaviors, which may support 256 congestion control for ACKs, sender behaviors not based on ACK- 257 clocking, etc. 259 The desired generic ACK ratio is intended to be in force for the 260 current data segment, and for subsequent data segments (at least, 261 during a time interval of a duration that may depend on several 262 factors). 264 The mechanism used to indicate the desired receiver Delayed ACK 265 behavior might exploit soft state (i.e. using explicit information 266 carried by data segments) or connection state (which needs to be 267 stored by the receiver). 269 4.5. Middlebox traversal 271 Deployment of new functionality for TCP faces the risk of packets 272 being discarded by existing middleboxes upon detection of unexpected 273 or discouraged formats, header field values or even traffic patterns. 275 A solution for sender control of Delayed ACKs should offer relatively 276 good middlebox traversal (to the extent possible). 278 4.6. Safe return to normal Delayed ACKs operation 280 A solution for sender control of Delayed ACKs must ensure that normal 281 Delayed ACKs operation is in force by default, and also once 282 temporary action on Delayed ACKs needs to end. 284 4.7. Impact on existing TCP functionality 286 A solution for sender control of Delayed ACKs should not reduce the 287 space of existing TCP functionality. 289 4.8. Impact on future TCP development 291 A solution for sender control of Delayed ACKs should not pose 292 significant risk of preventing future TCP development. If an 293 available resource (e.g. a reserved bit of the TCP header, a new TCP 294 option, etc.) is used by a solution, careful analysis must be carried 295 out regarding the risks and benefits of using such resource. 297 4.9. Avoidance of 'hacks' 299 Sender control of Delayed ACKs might be achieved by using 300 workarounds, such as implementation techniques that may produce the 301 desired effect. However, such approaches may be suboptimal regarding 302 implementation cleanliness, and may entail other performance issues 303 (see section 5.6). 305 4.10. Who is in control? 307 The receiver might not always be able to honour the ACK behavior 308 desired by the sender. Therefore, the semantics of sender control of 309 Delayed ACKs have to be of a hint, not a command. 311 If the receiver is actually not able to apply the ACK behavior 312 desired by the sender, then the former has a range of options with 313 regard to communicating so to the latter, from remaining silent, to 314 providing explicit feedback to the sender. Each option has 315 associated trade-offs. For example, remaining silent might degrade 316 performance if a sender relies on a receiver that uses the ACK 317 behavior intended by the sender. 319 5. Potential solutions for sender control of Delayed ACKs 321 This section enumerates and discusses potential solutions that might 322 be considered to enable sender control of Delayed ACKs. The list of 323 solutions is not necessarily comprehensive. This section intends to 324 illustrate the trade-offs that arise when considering potential 325 solutions for sender control of Delayed ACKs. (Note: the analysis 326 needs to be completed for many of the solutions below.) 328 5.1. AckCC 330 In Acknowledgment Congestion Control (AckCC) [RFC5690], the sender 331 tells the receiver the ACK ratio R to use, where the receiver sends 332 one ACK per R data packets received. AckCC defines a 2-byte "TCP ACK 333 Congestion Control Permitted Option" for negotiating use of AckCC, 334 whereas it defines a 3-byte "ACK ratio TCP option" to communicate the 335 ACK Ratio value from the sender to the receiver. 337 Middlebox traversal of a new TCP option is often regarded as 'bad' 338 (to be confirmed). 340 5.2. TLP 342 Tail Loss Probe (TLP) [I-D.ietf-tcpm-rack] is intended to avoid RTO- 343 expiration-based retransmission when tail loss occurs by inducing 344 additional ACKs at the receiver. This is achieved by sending a probe 345 segment after a probe time-out (PTO) when data have been sent but not 346 confirmed. Of course, this means sending a whole new packet to 347 trigger ACKs, which adds significant overhead. 349 This approach might offer good middlebox traversal (to be confirmed). 351 5.3. TCP ACK Pull (AKP) flag 353 One solution that has been proposed for sender control of Delayed 354 ACKs is called 'TCP ACK Pull' [I-D.gomez-tcpm-ack-pull]. 356 TCP ACK Pull defines the AKP flag as bit number 6 of the 13th byte of 357 the TCP header. When a TCP sender needs a data segment to be 358 acknowledged by the receiving TCP without additional delay, the 359 sender sets the AKP flag of the data segment TCP header. Upon 360 reception of a segment with the AKP flag set, a conforming receiving 361 TCP behaves accordingly by sending the corresponding ACK without 362 additional delay. 364 This solution would entail zero header or message overhead. However, 365 it would consume a TCP header bit, leaving only two available TCP 366 header reserved bits. A question is thus whether one TCP header bit 367 should be dedicated to this purpose or not. 369 Middlebox traversal characteristics of bit 6 of the TCP header need 370 to be assessed. 372 5.4. A new 'ACK Pull' TCP option 374 Another approach relies on defining a new option-kind-only TCP option 375 with the same semantics as the AKP flag, which might be called 'ACK 376 Pull Option' or 'AKP Option'. 378 This solution would consume an available TCP Option Kind number. 379 However, most of the 256 numbers in the TCP Option Kind number space 380 are currently available. Therefore, consuming one such number does 381 not appear to significantly limit future TCP development. 383 The header overhead of the AKP Option is one byte. 385 Middlebox traversal of a new TCP option is often regarded as 'bad' 386 (to be confirmed). 388 5.5. Reuse of existing TCP header fields 390 Another approach that might be used to enable sender control of 391 Delayed ACKs is based on reusing existing TCP header fields. For 392 example, use of the Urgent pointer has been suggested (e.g. by 393 reserving 3 of its 16 bits to encode an ACK ratio exponent that may 394 be communicated by the sender to the receiver), when URG=0. A 395 problem with this approach is that the semantics of the reused TCP 396 header field may become overloaded. Therefore, in some cases either 397 the original intended use of the reused TCP header field may become 398 limited, or if it prevails, then sender control of Delayed ACKs might 399 not always be available for use. 401 Middlebox traversal characteristics of this approach might be 402 relatively good (to be confirmed). 404 5.6. 'Hacks' 406 One approach that allows eliciting an immediate ACK after sending a 407 data segment is sending a subsequent segment carrying a previously 408 acknowledged data byte. However, in addition to the inefficiency of 409 sending a byte that has previously been sent, this approach may 410 require the transmission of a new packet (even carrying a single byte 411 of data payload) just for that purpose, which represents significant 412 overhead. Furthermore, sending a previously sent byte is not a clean 413 solution from an implementation perspective. 415 Another workaround intended to trigger an immediate ACK from the 416 receiving TCP, which is used in the Contiki operating system (a 417 popular operating system for constrained devices in IoT scenarios) is 418 splitting the data to be sent into two segments of smaller size. A 419 standard compliant TCP receiver will acknowledge the second MSS of 420 data. However, this 'split hack' may not always work since a TCP 421 receiver is required to acknowledge every second full-sized segment, 422 but not two consecutive small segments. Furthermore, the overhead of 423 sending two IP packets instead of one is another downside of the 424 'split hack'. 426 6. Summary 428 The next table summarizes whether the different solutions presented 429 in Section 4 are able to satisfy the requirements stated in 430 Section 4. 432 +-------+-------+-------+-------+-------+------+------+ 433 | Per- | Over- |Generic|Middle-|Impact |Impact|Hack | 434 |segment| head |ACK rat|box tr.|current|future|Avoid.| 435 +------------+-------+-------+-------+-------+-------+------+------+ 436 | ACKcc | Yes | Low | Yes | Bad? | No | Low | Yes | 437 +------------+-------+-------+-------+-------+-------+------+------+ 438 | TLP | No | High | No | Good | No | No | Yes | 439 +------------+-------+-------+-------+-------+-------+------+------+ 440 | AKP flag | Yes | No | Yes | ? | No |Med/Hi| Yes | 441 +------------+-------+-------+-------+-------+-------+------+------+ 442 | AKP option | Yes | Low | Yes | Bad? | No | Low | Yes | 443 +------------+-------+-------+-------+-------+-------+------+------+ 444 |Reuse fields| Yes | No | Yes | Good? | Yes | ? | Yes | 445 +------------+-------+-------+-------+-------+-------+------+------+ 446 | Hacks | ? |Med/Hig| No | Good? | No | No | No | 447 +------------+-------+-------+-------+-------+-------+------+------+ 449 Note: all considered potential solutions satisfy the following requirements: 450 i) sender control of Delayed ACKs, and ii) safe return to normal 451 Delayed ACKs operation. A receiver may be unable to always honour 452 the ACK behavior desired by the sender regardless of the specific 453 potential solution considered. 455 Figure 1: Summary of potential solutions for sender control of 456 Delayed ACKs. 458 7. Security Considerations 460 TBD 462 8. Acknowledgments 464 Bob Briscoe, Jonathan Morton, Richard Scheffenegger, Michael Tuexen 465 and Jana Iyengar provided useful input for this document. 467 Stuart Cheshire, Ted Lemon, Michael Scharf, and Christoph Paasch 468 participated in a discussion that was seminal to the TCP ACK Pull 469 proposal, which eventually led to this document. 471 Carles Gomez has been funded in part by the Spanish Government 472 (Ministerio de Ciencia, Innovacion y Universidades) through 473 Secretaria d'Universitats i Recerca del Departament d'Empresa i 474 Coneixement de la Generalitat de Catalunya 2017 SGR 376. 476 9. References 478 9.1. Normative References 480 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 481 Communication Layers", STD 3, RFC 1122, 482 DOI 10.17487/RFC1122, October 1989, 483 . 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, 487 DOI 10.17487/RFC2119, March 1997, 488 . 490 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 491 Sooriyabandara, "TCP Performance Implications of Network 492 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 493 December 2002, . 495 [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte 496 Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February 497 2003, . 499 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 500 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 501 . 503 [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding 504 Acknowledgement Congestion Control to TCP", RFC 5690, 505 DOI 10.17487/RFC5690, February 2010, 506 . 508 9.2. Informative References 510 [I-D.gomez-tcpm-ack-pull] 511 Gomez, C. and J. Crowcroft, "TCP ACK Pull", draft-gomez- 512 tcpm-ack-pull-01 (work in progress), November 2019. 514 [I-D.ietf-lwig-tcp-constrained-node-networks] 515 Gomez, C., Crowcroft, J., and M. Scharf, "TCP Usage 516 Guidance in the Internet of Things (IoT)", draft-ietf- 517 lwig-tcp-constrained-node-networks-09 (work in progress), 518 November 2019. 520 [I-D.ietf-tcpm-rack] 521 Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "RACK: 522 a time-based fast loss detection algorithm for TCP", 523 draft-ietf-tcpm-rack-08 (work in progress), March 2020. 525 [I-D.kuehlewind-tcpm-accurate-ecn] 526 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 527 Accurate ECN Feedback in TCP", draft-kuehlewind-tcpm- 528 accurate-ecn-05 (work in progress), October 2015. 530 [RFC8352] Gomez, C., Kovatsch, M., Tian, H., and Z. Cao, Ed., 531 "Energy-Efficient Features of Internet of Things 532 Protocols", RFC 8352, DOI 10.17487/RFC8352, April 2018, 533 . 535 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 536 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 537 RFC 8490, DOI 10.17487/RFC8490, March 2019, 538 . 540 Authors' Addresses 542 Carles Gomez 543 UPC 544 C/Esteve Terradas, 7 545 Castelldefels 08860 546 Spain 548 Email: carlesgo@entel.upc.edu 549 Jon Crowcroft 550 University of Cambridge 551 JJ Thomson Avenue 552 Cambridge, CB3 0FD 553 United Kingdom 555 Email: jon.crowcroft@cl.cam.ac.uk