idnits 2.17.1 draft-zimmermann-tcpm-spurious-rxmit-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 abstract seems to contain references ([RFC2018], [I-D.zimmermann-tcpm-echo-option]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2015) is 3174 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions (tcpm) A. Zimmermann 3 Internet-Draft R. Scheffenegger 4 Intended status: Standards Track NetApp, Inc. 5 Expires: January 21, 2016 July 20, 2015 7 Using the TCP Echo Option for Spurious Retransmission Detection 8 draft-zimmermann-tcpm-spurious-rxmit-00 10 Abstract 12 The Spurious Retransmission Detection (SRD) algorithm allows a TCP 13 sender to always detect if it has entered loss recovery 14 unnecessarily. It requires that both the TCP Echo option defined in 15 [I-D.zimmermann-tcpm-echo-option], and the SACK option [RFC2018] be 16 enabled for a connection. The SRD algorithm makes use of the fact 17 that the TCP Echo option, used in conjunction with the SACK feedback, 18 can be used to completely eliminate the retransmission ambiguity in 19 TCP. Based on the reflected data contained in the first acceptable 20 ACK that arrives during loss recovery, it decides whether loss 21 recovery was entered unnecessarily. The SRD mechanism further 22 enables improvements in loss recovery. This includes a TCP 23 enhancement to detect and quickly resend lost retransmissions. 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 http://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 January 21, 2016. 42 Copyright Notice 44 Copyright (c) 2015 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 (http://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. The Spurious Retransmission Detection Algorithm . . . . . . . 3 62 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. The Algorithm . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 71 8.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 Using only the sequence number, a TCP sender is not able to 77 distinguish whether the first ACK, acknowledging new data, that 78 arrives after a retransmit, was sent in response to the original 79 transmit or the retransmission. This effect is known as the 80 retransmission ambiguity problem [Zh86], [KP87]. Spurious 81 retransmissions, where a segment is sent multiple times, can be 82 caused by packet reordering, packet duplication, or a sudden delay 83 increase in the data or the ACK path. All these cases are preceded 84 by either a fast retransmit or a timeout-based retransmit. 86 The Eifel Detection Algorithm [RFC3522] aims to address these 87 occurrences, but falls short to completely solve the ambiguity 88 problem due to limitations in how the TCP Timestamps option is 89 processed by the receiver. 91 The TCP Timestamps option already provides a means of marking 92 retransmitted segments differently. However, the method used by a 93 TCP receiver when a Timestamp option is reflected precludes the use 94 of this option in most cases. The notable exception is the recovery 95 of lost segments, when none of the retransmissions is lost or 96 reordered in turn. Similarly, spurious retransmissions can also only 97 be detected and recovered from, when all of the retransmitted packets 98 are delivered in-order and without leaving any gaps in the receive- 99 buffer. Elsewise, the Timestamp option does not allow a solid 100 discrimination between original or retransmitted segments, that 101 triggered subsequent duplicate ACKs. 103 The semantics of the TCP Echo option, and their treatment by a 104 receiver are different from those of the TCP Timestamps option. That 105 allows a complete solution to disambiguate between all 106 retransmissions, including multiple retransmissions of the same 107 segment, packet duplication, and reordering events. 109 Enhancements in the area of TCP loss recovery and spurious 110 retransmission detection are allowed by using synergistic signaling 111 between the TCP Echo option and the selective acknowledgment (SACK) 112 option. This allows to completely address any retransmission 113 ambiguity. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. These 120 words only have such normative significance when in ALL CAPS, not 121 when in lower case. 123 Acceptable ACK: is an ACK that acknowledges previously unacknowledged 124 data. See [RFC0793]. 126 Forward Acknowledgement (FACK): is the the highest sequence number 127 known to have reached the receiver, plus one, using SACK information. 128 See [MM96]. 130 Lost Retransmission Detection (LRD): is a mechanism to timely detect 131 lost retransmissions during loss recovery, and quickly send the lost 132 segment anew instead of waiting for a retransmission timeout. A 133 simple and limited variant, that is not formally specified, is 134 currently in use by the Linux TCP stack. 136 Recover: When in fast recovery, this variable records the send 137 sequence number that must be acknowledged before the fast recovery 138 procedure is declared to be over. See [RFC6582]. 140 3. The Spurious Retransmission Detection Algorithm 141 3.1. Motivation 143 In order to detect spurious retransmissions, the sender requires 144 information to uniquely identify each retransmission of every segment 145 sent. TCP Eifel [RFC3522] uses additional information from the TCP 146 Timestamps option [RFC7323] for this purpose. This can remove some 147 ambiguity, but only under limited circumstances - it only works in 148 the absence of additional impediments like ACK reordering or multiple 149 loss. 151 However, the semantics used by the receiver when reflecting back a 152 received timestamp is such that this approach only works for the 153 first retransmission in a window, every subsequent retransmission 154 cannot be disambiguated from a received original transmission using 155 timestamps in most cases. 157 When a segment is retransmitted without the timestamp clock 158 increasing, Eifel detection also has no signal to differentiate if a 159 spurious retransmission had occurred. This is of particular concern 160 at high data rates and when the RTT is low. 162 Retransmission ambiguity detection during loss recovery (as opposed 163 to the first retransmission in a window) allows an additional level 164 of loss recovery control without reverting to timer-based methods. 165 As with the deployment of SACK, separating "what" to send from "when" 166 to send it, is driven one step further. In particular, less 167 conservative loss recovery schemes, which do not trade the principle 168 of packet conservation against timeliness, require a reliable way of 169 prompt and best possible feedback from the receiver about any 170 delivered segment and the ordering in which they got delivered. 172 SACK signaling [RFC2018] goes quite a long way, but does not suffice 173 in all circumstances, e.g. when retransmissions are lost. Further, 174 DSACK [RFC2883] does indicate if spurious retransmissions occured, 175 but that signal is delayed by one RTT [RFC3708]. However, loss 176 recovery is likely to have ended at that time. Furthermore, the 177 DSACK option by itself will not yield the information, if the late 178 arrived segment was the original or retransmitted segment. 180 Using the facility provided by the TCP Echo option a TCP sender is 181 able to differentiate between original and retransmitted segments, 182 even within the same TCP Timestamps options clock tick (i.e. when RTT 183 is shorter than the TCP timestamp clock interval). In addition, as 184 the TCP Echo option is reflected back with the most recently observed 185 value by the receiver, all instances where Eifel detection [RFC3522] 186 is not able to detect reliably can be addressed. Furthermore, as the 187 sender is immediately notified which segment triggered the ACK, no 188 delay is induced when deducting if a retransmission was spurious. 190 3.2. Basic Idea 192 Using the TCP Echo option, which has different semantics from the TCP 193 Timestamps option, it is possible to uniquely identify and 194 disambiguate each segment, including every retransmission. However, 195 the value carried with the TCP Echo option does not need to be unique 196 by itself (e.g. every segment having a different TCP Echo option 197 value), as other information contained in the TCP Header and TCP 198 options, namely the acknowledgment number and the SACK blocks, 199 differentiate already between segments in the TCP stream space. 200 Thus, it is only necessary to differentiate between segments (of the 201 same size) covering the same sequence space. 203 One simple approach would be to have a per-segment counter, which is 204 set to zero for each new transmission, and incremented whenever that 205 same segment is retransmitted anew. However, this approach would 206 require per-segment state in the sender. To reduce the complexity in 207 the sender, and not require per-segment state, a simpler approach is 208 to use a single global counter, that is increased whenever a segment 209 has to be resent. In ECN environments, an increase of the 210 retransmission counter is expected to typically coincide with CWR- 211 marked segments. 213 Apart from simplifying the design, this also yields additional 214 benefits when the reorder delay is larger than one RTT, and when 215 Acknowledgments are lost or reordered. Note that the wire 216 representation of this counter SHOULD NOT be as simplistic as 217 described here (see Section 6). 219 The retransmission counter has to be large enough to cater for all 220 expected RTOs before a TCP sender gives up and terminates a 221 connection (see [RFC1122], section 4.2.3.5, variable R2), plus all 222 the fast retransmissions of that segment that may have happened 223 before triggering the chain of exponential back-off RTOs. In 224 general, a single octet is enough to convey the retransmission 225 counter. 227 The sender has to transmit every segment with a TCP Echo option. 228 Sending the Echo option only with retransmission has the issue of 229 adding option space, thereby potentially requiring the sender to 230 segment the TCP payload differently (and sending an additional 231 segment) than the original segment. A sender SHOULD therefore add 232 the echo option to every sent segment to simplify the implementation. 233 Sending the TCP Echo option with every segment has the added benefit 234 to make the mechanism tolerate ACK losses. 236 3.3. The Algorithm 238 Spurious Retransmission Detection (SRD) utilizes the TCP Echo option 239 [I-D.zimmermann-tcpm-echo-option], which is used with at least one 240 octet of payload. If another algorithm deployed on the sender also 241 uses the TCP Echo option on a TCP connection, it is up to the 242 implementer to combine the necessary signaling of these mechanisms to 243 fit into a single TCP Echo option (e.g. by mapping the Echo option 244 codepoints into a translation table, or extending the length of the 245 TCP Echo option and matching parts of the data to the different 246 mechanisms). 248 The TCP sender maintains a single, connection-global counter. This 249 retransmission counter MUST be increased by one whenever the sender 250 enters loss recovery, experiences a Retransmission Timeout (RTO), or 251 re-sends a previously already retransmitted segment once more. Care 252 must be taken to limit a malicious receivers ability make genuine 253 retransmissions appear as spurious retransmissions to the sender (see 254 Section 6), when encoding the internal counter value to the wire 255 representation. 257 Every transmitted segment carries a TCP Echo option, where the data 258 reflects the current value of the sender's retransmission counter. 259 When the sender receives an ACK, the TCP Echo option data is 260 extracted and checked against the current value of the retransmission 261 counter, together with a check if the ACK is acceptable. Note that 262 information from not acceptable ACKs MUST be evaluated too. 264 After a retransmission has been sent, either due to a Fast 265 Retransmission or an RTO, the first acceptable ACK is checked. If 266 the received retransmission counter is equal to the current counter 267 value maintained by the sender, a valid retransmission was sent. If 268 the received value is less than the current retransmission counter, a 269 spurious retransmission was sent, and if no valid retransmissions are 270 detected until the end of the loss recovery phase, the TCP sender MAY 271 restore the congestion control state to the state prior to entering 272 loss recovery. Even if some of the retransmissions of this loss 273 recovery phase may have been spurious, the TCP sender MUST NOT react 274 by restoring the congestion control state to the state before 275 entering loss recovery, if any of the retransmissions are deduced to 276 be valid. 278 A TCP sender MAY retain the congestion control state for up to two 279 RTTs since entering the loss recovery state. {TODO: Not after exiting 280 loss recovery?} If all retransmissions that were performed in this 281 period are later found to have been spurious - either by evaluating 282 the retransmission counter values of received unacceptable (first 283 duplicate) ACKs, or a DSACK [RFC3708] indication - the TCP sender MAY 284 revert to the stored congestion control state, e.g. by following the 285 Eifel Response algorithm [RFC4015]. 287 4. Examples 289 This section shows a few examples, from simple to increasingly 290 complex. Some of these scenarios are addressed by exising mechanisms 291 like Eifel, and DSACK; in particular, corner cases that are not 292 adressed with existing mechanisms are demonstrated. 294 In the following examples, each set of three lines starting with 295 "ack#", "sack:", and "sent:" represent one RTT. It is assumed that 296 the sender has sent segments 1 to 8 in the prior RTT, and for 297 readability, the numbers show represent full segments rather than 298 sequence numbers. 300 The two lines following ("ack#" and "sack:") indicate what ACK is 301 being triggered on the receiver. The ACK number is the sequence 302 number of the next expected segment, followed by a dot and the value 303 of the received TCP Echo option value - again for simpilicty, the 304 internal representation of the global retransmission counter value 305 (initially set to zero) is shown, not the wire representation. 307 In the line "sack:" the relevant SACK blocks are depicted, again with 308 a single number representative of an entire segment. When these ACKs 309 are seen by the sender, it will start sending the segment depicted in 310 the line "sent:", again together with the retransmission counter 311 value. 313 Further assumptions in these examples are that the sender is using 314 proportional rate reduction [RFC6937], limited transmit [RFC3042], 315 and selective acknowledgments (SACK) [RFC2018] and [RFC2883], is not 316 application limited when sending data and has a congestion window of 317 9 segments. 319 1. Fast Retransmission 321 ack# X 1.0 1.0 1.0 1.0 1.0 1.0 1.0 322 sack: 2 2-3 2-4 2-5 2-6 2-7 2-8 323 sent: 9.0 10.0 1.1 11.1 12.1 325 ack# 1.0 1.0 11.1 12.1 13.1 326 sack: 2-9 2-10 328 detected as valid retransmission, as for the first acceptable ACK 329 (11.1) after the retransmission the Echo Tag is equal to the 330 retransmission counter. 332 2. Multiple loss 334 ack# X 1.0 1.0 1.0 1.0 1.0 1.0 X 335 sack: 2 2-3 2-4 2-5 2-6 2-7 336 sent: 9.0 10.0 1.1 11.1 338 ack# 1.0 1.0 8.1 8.1 339 sack: 2-7,9 2-7,9-10 9-10 9-11 340 sent: 12.1 8.1 ... 342 SRD detectes this as valid retransmission, as for the first 343 acceptable ACK (8.1) and every other retransmission after the first 344 retransmission the Echo Tag is equal to the retransmission counter. 345 Retransmission counter is not increased when sending (8.1) as loss 346 recovery was not yet exited at the time of sending that 347 retransmission. 349 3. Retransmission Timeout (RTO) 351 ack# X X X X X X X X 352 sack: 353 sent: ----- RTO --> 355 ack# 356 sack: 357 sent: ----- RTO --> 1.1 359 ack# 1.1 360 sack: 362 detected as valid retransmission, as the first acceptable ACK (1.1) 363 after the retransmission contains the Echo Tag of the retransmission. 365 4. Retransmission loss 367 ack# X 1.0 1.0 1.0 1.0 1.0 1.0 1.0 368 sack: 2 2-3 2-4 2-5 2-6 2-7 2-8 369 sent: 9.0 10.0 1.1 11.1 12.1 370 X 371 ack# 1.0 1.0 1.1 1.1 372 sack: 2-9 2-10 2-11 2-12 374 no acceptable ack, but a jump on the counter tag to the current 375 counter. (see {TODO: LRD document}), also FACK is larger than 376 Recovery Point (The condition of FACK > RP will trigger linux LRD). 378 Note: without LRD, the lost retransmission will NOT be retried before 379 an RTO. Can not be detected by Eifel due to TCP Timestamps 380 semantics. 382 5. Multiple loss, first retransmission lost 384 ack# X X 1.0 1.0 1.0 1.0 1.0 1.0 385 sack: 3 3-4 3-5 3-6 3-7 3-8 386 sent: 9.0 1.1 2.1 10.1 387 X 388 ack# 1.0 1.1 1.1 389 sack: 3-9 2-9 2-10 390 sent: 11.1 1.2 12.2 392 no acceptable ack, but a jump on the counter tag to the current 393 counter. see {TODO: LRD document}. Linux LRD would delay the sending 394 of 1.2 until after FACK passes RP (in this example, the last two sent 395 segments was be swapped). Not detectable by Eifel. 397 6. RTT > Reordering delay > DupThresh 399 r 400 ack# R 1.0 1.0 1.0 1.0 6.0 7.0 8.0 401 sack: 2 2-3 2-4 2-5 402 sent: 8.0 9.0 1.1 10.1 11.1 12.1 404 ack# 9.0 10.0 10.1 11.1 12.1 13.1 405 sack: 1 407 detected as spurious retransmission, as the first acceptable ACK 408 (6.0) after the retransmission is received with the Echo Tag unequal 409 the current retransmission counter; DSACK detects this 1 RTT later; 410 Eifel detects this at the same time using timestamps 412 7. Reordering delay > RTT 414 ack# R 1.0 1.0 1.0 1.0 1.0 1.0 1.0 415 sack: 2 2-3 2-4 2-5 2-6 2-7 2-8 416 sent: 9.0 10.0 1.1 11.1 12.1 417 r 418 ack# 1.0 1.0 11.1 12.1 12.0 13.1 419 sack: 2-9 2-10 1 421 detected as valid retransmission, as the first acceptable ACK (11.1) 422 after the retransmission contains the Echo Tag of the retransmission. 424 Note that at (12.0), with the retransmission counter always counting 425 up, this detection becomes possible, by seeing 2nd ACK with lower 426 retransmission counter (SRD) one RTT later: DSACK and SRD both detect 427 at the same time 429 8. Packet duplication 431 SACK is mandatory for SRD, and SACK detects this as duplication 432 event, with no further action 434 9. Reordering and loss 436 r 437 ack# R X 1.0 1.0 1.0 2.0 2.0 2.0 438 sack: 3 3-4 3-5 3-5 3-6 3-7 439 sent: 8.0 9.0 1.1 2.1 441 ack#: 2.0 2.0 2.1 10.1 442 sack 3-8 3-9 1,3-9 444 detected as spurious retransmission, as the first acceptable ACK 445 (2.0) after the retransmission is received with the Echo Tag unequal 446 the current retransmission counter; no undo at that point, since 447 still in recovery. DSACK detects this 1 RTT later; Eifel detects 448 this at the same time using timestamps. 449 Detected as valid retransmission, as for the second acceptable ACK 450 (10.1) after the retransmission the Echo Tag is equal to the 451 retransmission counter, prior to leaving loss recovery 453 10. Loss and reordering (reordered retransmission) 455 ack# X 1.0 1.0 1.0 1.0 1.0 1.0 1.0 456 sack: 2 2-3 2-4 2-5 2-6 2-7 2-8 457 sent: 9.0 10.0 1.1 11.1 12.1 458 R 459 r 460 ack# 1.0 1.0 1.1 12.1 13.1 461 sack: 2-9 2-10 2-11 462 sent: 13.1 1.2 14.2 15.2 464 ack# 14.1 14.2 15.2 16.2 465 sack: 1 467 reordered retransmission 469 LRD triggered (no acceptable ack, when retransmission count increases 470 - {TODO: LRD document}), also FACK > Recovery Point (Linux LRD) 471 Detected as spurious retransmission, as the first acceptable ACK 472 (12.1) after the 2nd retransmission is received with the Echo Tag 473 unequal the current retransmission counter; undo at that point, since 474 recovery is exited at the same time. DSACK detects this 1 RTT later; 475 Eifel detects this at the same time using timestamps. 477 11. ACK reordering after loss 479 ack# X 1.0 1.0 1.0 1.0 1.0 1.0 1.0 480 sack: 2 2-3 2-4 2-5 2-6 2-7 2-8 481 sent: 9.0 10.0 1.1 11.1 12.1 482 R 483 r 484 ack# 1.0 1.0 1.1 11.1 13.1 485 sack: 2-9 2-10 2-11 486 sent: 13.1 1.2 14.2 15.2 488 valid retransmission, as first acceptable ack (11.1) after 489 retransmission has same retransmission counter as the current value. 490 Reordered ACK has still same (not lower!) retransmission counter. 492 12. ACK reordering after reordering 494 rR 495 ack# R 1.0 1.0 1.0 1.0 7.0 6.0 8.0 496 sack: 2 2-3 2-4 2-5 497 sent: 8.0 9.0 1.1 10.1 11.1 499 ack# 9.0 10.0 10.1 11.1 12.1 500 sack: 1 502 detected as spurious retransmission, as the first acceptable ACK 503 (7.0) after the retransmission is received with the Echo Tag unequal 504 the current retransmission counter; DSACK detects this 1 RTT later; 505 Eifel detects this at the same time using timestamps 507 13. ACK loss after reordering 508 r 509 ack# R 1.0 1.0 1.0 1.0 (6.0) 7.0 8.0 510 sack: 2 2-3 2-4 2-5 511 sent: 8.0 9.0 1.1 10.1 11.1 513 ack# 9.0 10.0 10.1 11.1 12.1 514 sack: 1 516 detected as spurious retransmission, as the first acceptable ACK 517 (7.0) after the retransmission is received with the Echo Tag unequal 518 the current retransmission counter; DSACK detects this 1 RTT later; 519 Eifel detects this at the same time using timestamps 520 Note that retransmission counter only increasing helps this case to 521 work both with reordering (spurious retransmission) and 522 retransmission ACK loss - the relevant information is conveyed for 523 about 1RTT thus single ACK loss does not impact the detection. 525 14. TODO: delay ACK 527 Todo: Example necessary? 529 5. IANA Considerations 531 This document contains no requests to IANA, as only a new combined 532 use of TCP options is described. 534 6. Security Considerations 536 This document describes a new use for the TCP Echo option. 537 Transporting the retransmission counter in the clear may pose a 538 security problem when the TCP sender uses SRD to restore the TCP 539 state. A malicious receiver could game the sender to always restore 540 the congestion control state to the one preceding the lost recovery 541 episode, thereby making the sender not back off its transmission 542 rate. 544 As the sender can put any data into the TCP Echo option, the 545 transmission counter value can be masked in various ways. A TCP 546 sender can map the same counter value to multiple TCP Echo option 547 data values, and track which of these data values would be expected 548 for a given acknowledgement. Alternatively, the TCP Echo option data 549 could be a (secure) hash of the sequence number of the sent segment, 550 a random, per-connection secret, and the retransmission counter. The 551 TCP Echo data would look rather as random sequence of octets in both 552 cases, making it very hard for a malicious receiver to obtain an 553 unfair share of bandwidth by masking genuine retransmissions as 554 spurious. 556 7. Acknowledgements 558 The authors like to thank Bob Briscoe and Brian Trammel for their 559 invaluable input. 561 Alexander Zimmermann the European Union's Horizon 2020 research and 562 innovation program 2014-2018 under grant agreement No. 644866 563 (SSICLOPS). This document reflects only the authors' views and the 564 European Commission is not responsible for any use that may be made 565 of the information it contains. 567 8. References 569 8.1. Normative References 571 [I-D.zimmermann-tcpm-echo-option] 572 Zimmermann, A., Scheffenegger, R., and B. Briscoe, "The 573 TCP Echo and TCP Echo Reply Options", draft-zimmermann- 574 tcpm-echo-option-00 (work in progress), June 2015. 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, March 1997. 579 8.2. Informative References 581 [KP87] Karn, P. and C. Partridge, "Estimating Round-Trip Times in 582 Reliable Transport Protocols", Proc. SIGCOMM '87, August 583 1987. 585 [MM96] Mathis, M. and J. Mahdavi, "Forward Acknowledgement: 586 Refining TCP Congestion Control", ACM SIGCOMM 1996 587 Proceedings, in ACM Computer Communication Review 26 (4), 588 pp. 281-292, October 1996. 590 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 591 793, September 1981. 593 [RFC1122] Braden, R., "Requirements for Internet Hosts - 594 Communication Layers", STD 3, RFC 1122, October 1989. 596 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 597 Selective Acknowledgment Options", RFC 2018, October 1996. 599 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 600 Extension to the Selective Acknowledgement (SACK) Option 601 for TCP", RFC 2883, July 2000. 603 [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing 604 TCP's Loss Recovery Using Limited Transmit", RFC 3042, 605 January 2001. 607 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 608 for TCP", RFC 3522, April 2003. 610 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 611 Acknowledgement (DSACKs) and Stream Control Transmission 612 Protocol (SCTP) Duplicate Transmission Sequence Numbers 613 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 614 February 2004. 616 [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm 617 for TCP", RFC 4015, February 2005. 619 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 620 NewReno Modification to TCP's Fast Recovery Algorithm", 621 RFC 6582, April 2012. 623 [RFC6937] Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional 624 Rate Reduction for TCP", RFC 6937, May 2013. 626 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 627 Scheffenegger, "TCP Extensions for High Performance", RFC 628 7323, September 2014. 630 [Zh86] Zhang, L., "Why TCP timers don't work well", Proc. SIGCOMM 631 '86, Sep 1986. 633 Authors' Addresses 635 Alexander Zimmermann 636 NetApp, Inc. 637 Sonnenallee 1 638 Kirchheim 85551 639 Germany 641 Phone: +49 89 900594712 642 Email: alexander.zimmermann@netapp.com 643 Richard Scheffenegger 644 NetApp, Inc. 645 Am Euro Platz 2 646 Vienna 1120 647 Austria 649 Email: rs@netapp.com