idnits 2.17.1 draft-flach-tcpm-fec-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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3937 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance Working Group T. Flach 3 Internet-Draft USC 4 Intended status: Experimental N. Dukkipati 5 Expires: January 16, 2014 Y. Cheng 6 B. Raghavan 7 Google 8 July 15, 2013 10 TCP Instant Recovery: Incorporating Forward Error Correction in TCP 11 draft-flach-tcpm-fec-00.txt 13 Abstract 15 Ordinary TCP loss recovery takes at least one round-trip time and as 16 such can increase application-perceived latency, especially for short 17 flows such as Web transactions. TCP Instant Recovery (TCP-IR) is an 18 experimental algorithm that allows a receiving end to recover lost 19 packets without retransmissions, thus potentially saving at least one 20 full round-trip time compared to standard TCP. TCP-IR achieves this 21 by judiciously injecting encoded data segments within a TCP stream. 22 This document describes the TCP-IR algorithm at the sending and 23 receiving ends, along with the required protocol changes. 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 16, 2014. 42 Copyright Notice 44 Copyright (c) 2013 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. TCP-IR Option . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.3. Encoding Types . . . . . . . . . . . . . . . . . . . . . 8 66 3.4. TCP-IR Sender . . . . . . . . . . . . . . . . . . . . . . 9 67 3.5. TCP-IR Receiver . . . . . . . . . . . . . . . . . . . . . 9 68 3.6. Processing Acknowledgements . . . . . . . . . . . . . . . 11 69 4. Interaction with middleboxes . . . . . . . . . . . . . . . . 11 70 5. Implementation and Performance . . . . . . . . . . . . . . . 12 71 6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 TCP Instant Recovery (TCP-IR) enables a receiver to recover lost data 80 segments instantly without the need for retransmissions from a 81 sender. Standard TCP retransmission-based loss recovery takes at 82 least one RTT for loss detection and recovery. 84 The main motivation for TCP-IR is to reduce the tail latency of Web 85 transactions. Most Web transfers are short and could finish within a 86 few round-trip times (RTTs), but losses can add multiple RTTs to 87 transfer times and increase the variance in Web page download times. 88 The goal of TCP-IR is to reduce loss detection and recovery to zero 89 RTT while still employing TCP's congestion control principles. 91 Recovery mechanisms, such as fast recovery and retransmission 92 timeout, are fundamentally RTT dependent. Regardless of how fast 93 network bandwidth grows, the number of RTTs that it takes to recover 94 lost packets does not change. TCP-IR employs forward error 95 correction (FEC) to scale the recovery time inversely with bandwidth 96 and make it independent of RTT. It explicitly trades some network 97 bandwidth to reduce RTTs for short transfers. Most bandwidth in the 98 Internet is used by large flows such as video, and thus short, 99 latency-sensitive traffic can benefit using a small degree of FEC 100 without hurting bulk flow throughput. 102 In this document, we specify the TCP-IR mechanism, which requires 103 both sender and receiver changes, to achieve 1-RTT recovery for 104 commonly observed loss scenarios. Instead of complete redundancy for 105 every segment, we employ FEC within TCP. The sender transmits extra 106 FEC segments, which encode previously transmitted segments, so that 107 the receiver can repair a small number of losses. While the use of 108 FEC for transport has been explored in the past, to our knowledge 109 this is the first specification to place FEC within TCP in a way that 110 is incrementally deployable across today's networks with middleboxes. 112 1.1. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 2. Protocol Overview 120 The key idea in TCP-IR is the judicious introduction of a small 121 number of checksum or XOR segments into TCP's data stream such that a 122 receiver can immediately recover lost segment(s) without the need for 123 retransmissions. The core design challenge is in injecting out of 124 band XOR segments within the regular data stream. We outline the 125 main aspects of the protocol below. 127 Several of the design choices we made are rooted in our measurements 128 and observations of Internet loss patterns as documented in 129 [RECOVERY-SIGCOMM13]. We find that among the flows experiencing 130 losses, most flows lose only one or two consecutive packets, commonly 131 at the tail of a burst. As an example, for bursts of at most 10 132 packets, ~35% experienced exactly one loss, and an additional 10% 133 experienced exactly two losses. Further, the latter packets for any 134 given burst size are more likely to be lost. Given these findings, 135 we chose a simple XOR-based encoding scheme that can perform instant 136 recovery of a small amount (one or two segments) of packet loss. 138 A TCP-IR sender and receiver first negotiate the use of instant 139 recovery in the initial handshake. If both hosts support the use of 140 instant recovery, every packet in the connection includes a TCP-IR 141 option. 143 TCP-IR sender: 145 1. Periodically in every round-trip time, a TCP-IR sender places the 146 XOR of newly transmitted segments into a single MSS-length checksum 147 packet. The XOR is only computed for new segments not previously 148 included in checksums. 150 2. Regardless of the sizes of original segments, the sender computes 151 the XORs along MSS byte boundaries. Because every packet carries a 152 payload of at most MSS bytes, such an encoding guarantees that the 153 receiver can instantly recover any single packet loss. 155 3. The encoded XOR packet uses the same sequence number as the first 156 segment it encodes. The encoded packet carries a flag in the TCP-IR 157 option signaling that the payload is encoded. A receiver uses the 158 flag to disambiguate an encoded packet from a regular 159 (re)transmission, since both segments carry the same sequence number. 160 The option also includes the number of bytes that the payload 161 encodes. 163 There is no reliability provided for the XOR segments. 165 TCP-IR receiver: 167 1. A receiver first establishes if the payload of the received 168 segment is encoded, by checking a flag in the TCP-IR option. 170 2. Once the receiver establishes that the payload is encoded, it 171 obtains the encoded range of bytes by using the sequence number of 172 the TCP-IR packet and the the number of bytes encoded. 174 3. The receiver checks for holes in the encoded range. If it 175 received the entire sequence range, the receiver drops the encoded 176 packet. Otherwise, if it is missing at most MSS contiguous bytes, 177 the receiver uses the encoded payload to recover the lost sequence 178 range and forwards it to the regular reception routine, thus allowing 179 0-RTT recovery. 181 4. For the purpose of recovering lost segments, a receiver buffers 182 the last fifteen in-order MSS blocks that it ACKed, even if the 183 application layer has already consumed these blocks. Because an 184 encoded packet is the XOR of at most sixteen MSS segments, the 185 receiver can recover any single lost packet by computing the XOR of 186 the encoded payload and the buffered data in the encoding range. 188 5. If too much data is missing for the encoded packet to recover, 189 the receiver sends a duplicate ACK. This ACK informs the sender that 190 a recovery failed and also denotes the byte ranges lost via the TCP- 191 IR option. The sender marks the byte ranges as lost and triggers a 192 fast retransmit and recovery. 194 6. TCP-IR does not circumvent congestion control. If the receiver 195 were to simply ACK a recovered packet, it would mask the loss and 196 prevent congestion control during a known loss episode. To perform 197 congestion window reduction upon a successful recovery at the 198 receiver, TCP-IR uses a mechanism similar to explicit congestion 199 notification (ECN). Upon a successful recovery, the receiver enables 200 an R_SUCC flag in the TCP-IR option in each outgoing ACK. The sender 201 in turn triggers a congestion window reduction and sets an R_ACK flag 202 in the TCP-IR option of the next packet sent to the receiver. Once 203 the receiver observes R_ACK in an incoming packet, indicating that 204 the sender reduced the congestion window, it disables R_SUCC for 205 future packets. 207 Figure 1 gives an example of TCP-IR in action. 209 TCP A (Client) TCP B (Server) 210 ______________ _____________ 211 | | 212 | < SYN + TCP-IR_OPT > | 213 | --------------------------------------> | 214 | < SYN/ACK + TCP-IR_OPT > | 215 | <-------------------------------------- | 216 | | 217 | < DATA > | 218 | <-------------------------------------- | 219 | < DATA > | 220 | <-------------------------------------- | 221 | < DATA SEGMENT LOST in TRANSIT > | 222 | X <-------------------- | 223 | | 224 | < XOR SEGMENT > | 225 | <-------------------------------------- | 226 Recovery | | 227 of lost | | 228 segment | | 229 | < ACK + SUCCESSFUL_RECOVERY_FLAG > | 230 | --------------------------------------> | 231 | | 232 | | CWND reduction 233 | | on successful 234 | | recovery. 235 | < ACK + WINDOW_REDUCED_FLAG > | 236 | <-------------------------------------- | 238 Figure 1: Sample flow using TCP-IR 240 3. Protocol Details 241 In the following, we describe the TCP-IR option design, negotiation 242 of instant recovery, the supported encoding schemes, and finally the 243 sender and receiver side algorithms. 245 3.1. TCP-IR Option 247 Both the server and the client use a new option to perform the 248 following: 250 o Negotiate the use of TCP-IR, including the encoding type. 251 o Distinguish encoded packets from regular packets. 252 o Communicate the number of encoded bytes in an XOR packet. 253 o Acknowledge the recovery of segments and congestion window 254 reductions. 255 o Indicate the loss of segments. 257 1 2 258 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 259 +---------------+---------------+---------------+ 260 | Kind = TBD | Length = 1 | Encoding Type | 261 +---------------+---------------+---------------+ 263 Figure 2: TCP-IR Option format for packets with SYN flag set 265 During the initial handshake (for packets with the SYN flag set), the 266 option has the format shown in Figure 2. It contains the following 267 fields: 269 Kind (8 bits) 270 This MUST be set to the option number for TCP-IR to be determined 271 by IANA. 273 Length (8 bits) 274 This MUST be set to the length of the TCP option in octets; its 275 value MUST be 1. 277 Encoding Type (8 bits) 278 This SHOULD be set to a value corresponding to a supported encoding 279 type (see Section 3.3). 281 1 2 3 282 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 283 +---------------+---------------+---------------+--------------- 284 | Kind = TBD | Length | Flags | 285 +---------------+---------------+---------------+--------------- 286 Range (optional) | 287 --------------------------------+ 289 Figure 3: TCP-IR Option format (except for packets with SYN flag set) 291 For all other packets, the option has the format shown in Figure 3. 292 It contains the following fields: 294 Kind (8 bits) 295 This MUST be set to the option number for TCP-IR to be determined 296 by IANA. 298 Length (8 bits) 299 This MUST be set to the length of the TCP option in octets; its 300 value MUST be 1, or 4 (if the "Range" field is appended). 302 Flags (8 bits) 303 The field can carry the following flags (each represented by one 304 bit): 306 Bit Flag Name Description 307 0 R_CWR Congestion Window Reduction Acknowledgement 308 1 R_SUCCESS Recovery successful 309 2 R_FAIL Recovery failed 310 3 ENCODED Packet is encoded 311 4-7 Unused 313 The unused bits SHOULD NOT be set. 315 Range (24 bits, optional) 316 This field is only used if either the ENCODED or R_FAIL bit in the 317 "Flags" field is set. If the ENCODED bit is set, this field 318 specifies the number of bytes encoded in the payload. If the 319 R_FAIL bit is set, this field specifies the number of bytes 320 considered lost (see Section 3.4 and Section 3.6). 322 3.2. Negotiation 324 TCP-IR MUST be explicitly negotiated during the initial handshake. 325 If the negotiation succeeds, both endpoints can send and receive TCP- 326 IR packets. More specifically TCP-IR is enabled if: 328 1. The receiver sends the SYN packet carrying the TCP-IR option. 329 The encoding type field MUST carry a valid encoding type (see 330 Section 3.3). 331 2. The sender responds with a SYN/ACK carrying the TCP-IR option. 332 The encoding type field MUST carry the same encoding type as the 333 option in the corresponding SYN packet. 334 3. All following packets (transmitted by either sender or receiver) 335 MUST carry the TCP-IR option. 337 If any endpoint receives a packet (after negotiation succeeds) that 338 does not carry the TCP-IR option, the connection MUST be reset. This 339 is necessary because a receiver can no longer distinguish between 340 regular and TCP-IR packets. We recommend tracking these cases to 341 avoid TCP-IR negotiation on future connections. 343 3.3. Encoding Types 345 The client can select the encoding type to be used by the TCP-IR 346 module but both endpoints have to support it and agree on it during 347 the initial handshake (see Section 3.2). 349 Currently the following encoding types are supported and are 350 therefore valid values in the "Encoding Type" field of the TCP-IR 351 option during negotiation: 353 Value Type Description 354 0 Undefined 355 1 Basic XOR TCP-IR packets carry the XOR of every MSS 356 length segment. One TCP-IR packet encodes 357 up to 16 MSS length segments. 358 2 Interleaved XOR TCP-IR packets carry the XOR of every other 359 MSS length segment. One TCP-IR packet 360 encodes up to 8 MSS length segments. 361 3-255 Undefined 363 We selected these encoding types to demonstrate the flexibility of 364 TCP-IR with respect to user preferences (like the acceptable amount 365 of redundancy) and connection properties. Basic XOR can recover a 366 single segment loss of up to MSS bytes in the encoding range. 367 Interleaved XOR enables the recovery of two consecutive segments of 368 up to MSS bytes. This makes Interleaved XOR suitable for connections 369 observing bursty losses, but can double the number of generated TCP- 370 IR packets. 372 The currently supported encoding types use the MSS value to determine 373 the block size for the encoding process. If the MSS value changes 374 after the initial handshake, TCP-IR MUST be disabled for the 375 remainder of the connection. 377 3.4. TCP-IR Sender 379 All packets after the initial handshake carry the TCP-IR option to 380 ensure that the receiver can always distinguish regular packets from 381 encoded packets (packets carrying a payload encoded by the TCP-IR 382 module), or detect the removal of the option by a middlebox. Encoded 383 packets MUST set the ENCODED bit in the "Flags" field of the TCP-IR 384 option; all other packets MUST NOT set the ENCODED bit. 386 The TCP-IR packet MUST use the same sequence number as the first byte 387 it encodes. This prevents enforcing reliability for encoded packets 388 as well as the overhead of specifying the index of the first encoded 389 byte in a separate option field. 391 In addition to that, the option in encoded packets MUST carry the 392 "Range" field. The value in the "Range" field specifies the index of 393 the byte after the last encoded byte in the payload relative to the 394 sequence number of the encoded packet. 396 TCP-IR adds a short delay in the transmission of encoded packets to 397 the reduce the probability of losing both the original transmission 398 and the encoded packet in the same loss burst. 400 The encoding and transmission routine works as follows: 402 1. Before a regular data packet is forwarded to the IP layer, the 403 TCP-IR timer is armed (unless the timer is already armed). In 404 our prototype implementation the timer is set to a value of RTT/ 405 4. 406 2. Once the timer fires, all transmitted segments not encoded before 407 are now encoded according to the negotiated encoding type and the 408 corresponding encoded packets are transmitted immediately. The 409 maximum number of MSS length segments which can be encoded in a 410 single TCP-IR packet depends on the negotiated encoding type (see 411 Section 3.3). As a result, the number of encoded packets created 412 in this step depends on the encoding type and the number of 413 previously un-encoded segments. The option fields in the encoded 414 packet are populated as described in Section 3.1. 416 3.5. TCP-IR Receiver 418 Receivers distinguish TCP-IR packets from regular packets by checking 419 the ENCODED bit in the "Flags" field of the TCP-IR option. Encoded 420 packets are forwarded to the TCP-IR reception routine (described 421 below). If the packet does not carry the TCP-IR option it is 422 discarded and TCP-IR is disabled for the remainder of the connection. 423 To inform the sender that TCP-IR can no longer be used, the receiver 424 sends an acknowledgement without the TCP-IR option. 426 Additionally, the regular reception routine is modified as follows. 427 The last 15 ACKed MSS length segments remain in the buffer, even if 428 the application layer has already consumed these segments. Segments 429 received out-of-order are already buffered by default and cannot be 430 consumed by the application layer. Since a single TCP-IR packet 431 encodes at most 8 (interleaved XOR) or 16 (basic XOR) MSS length 432 segments, any single segment loss (up to MSS length) in the encoding 433 range can be recovered by the decoder. 435 The reception routine for TCP-IR packets works as follows: 437 1. The encoding range of the TCP-IR packet is extracted. As 438 mentioned earlier, the sequence number of the packet specifies 439 the sequence number of the first encoded byte. The sequence 440 number plus the value stored in the "Range" field in the TCP-IR 441 option minus 1 specifies the sequence number of the last encoded 442 byte. 443 2. If all bytes in the encoding range were already received, skip to 444 Step 5. 445 3. If lost segments in the encoding range can be recovered (in the 446 case of XOR encoding, a loss of at most one MSS length segment in 447 the encoding range can be handled): 449 a. The lost segments are reconstructed. The matching packet 450 headers are appended to the reconstructed segments and the 451 packets are forwarded to the regular reception routine. 452 b. The R_SUCCESS bit in the "Flags" field of the TCP-IR option 453 is set for all future packets. This includes the 454 (potentially delayed) acknowledgement for the recovered 455 segment. Further details are described in Section 3.6. 456 4. If none of the segments in the encoding range are recoverable: 458 a. The sequence number of the last byte lost is extracted. The 459 offset between the sequence number of the next expected byte 460 (RCV.NXT) and the last byte lost defines the loss range. 461 b. An acknowledgement is generated with the following 462 requirements for the TCP-IR option. 464 + The R_FAIL bit in the "Flags" field is set. 466 + The option carries the "Range" field. The "Range" field 467 encodes the loss range, as described above. The context 468 is maintained, since the acknowledgement number will be 469 set to RCV.NXT. 470 5. The TCP-IR packet is discarded. 472 3.6. Processing Acknowledgements 474 If a receiver instantly recovers losses we want to ensure the sender 475 learns of it so as to not circumvent congestion control [RFC5681]. 476 The R_SUCCESS bit in the "Flags" field of the TCP-IR option informs 477 the sender that the receiver successfully recovered a lost packet. 478 Once the sender observes the R_SUCCESS bit in a packet the following 479 steps are executed: 481 1. The sender reduces its congestion window. 482 2. The sender sets the R_CWR bit in the "Flags" field of the TCP-IR 483 option in the next outgoing packet only. 484 3. The sender does not act on any future observations of the 485 R_SUCCESS bit being set until SND.UNA advances past the SND.NXT 486 value observed at the time when Step 2 was executed. This 487 ensures the congestion window is not reduced multiple times in 488 the same loss episode. 489 4. Once the receiver observes the R_CWR bit being set in any 490 incoming packet, the R_SUCCESS bit is reset for all future 491 packets. 493 A failed recovery on the receiver side triggers an explicit 494 acknowledgment sent to the sender to inform it about the segments 495 that are considered lost. This is indicated by the R_FAIL bit being 496 set in the "Flags" field of the TCP-IR option. If the sender 497 observes this bit being set, the following steps are executed: 499 1. The sender extracts the loss range from the "Range" field in the 500 TCP-IR option. The sequence numbers of the first and last byte 501 lost are defined by the acknowledgement number of the packet, and 502 the acknowledgement number plus the loss range value. 503 2. The sender marks the appropriate byte range as lost and triggers 504 Fast Retransmit/Recovery. 506 Explicit notification of loss ranges has the benefit that lost 507 segments are retransmitted faster, avoiding the extra wait time until 508 the RTO fires. 510 4. Interaction with middleboxes 512 An important design goal of TCP-IR is compatibility with middleboxes 513 and support for graceful fallback to standard TCP behavior in 514 situations where middlebox interference prevents proper use of TCP- 515 IR. 517 Even if hosts negotiate TCP-IR during the initial handshake, it is 518 possible for a middlebox to strip the option from a later packet. To 519 be robust to this, if either host receives a packet without the 520 option, it MUST discard the packet and reset the connection. This is 521 necessary since receivers are no longer able to distinguish TCP-IR 522 packets from regular packets. 524 TCP-IR uses relative sequence numbers to convey metadata (such as the 525 encoding range) between endpoints. This prevents issues in the cases 526 of middleboxes performing sequence number translations. 528 Some problems caused by middlebox interference (and their solutions 529 in TCP-IR) are not discussed in the current version of this draft: 531 o Rewriting of the acknowledgement number if the acknowledged 532 segment was not observed by the middlebox. With TCP-IR this can 533 occur after recovering a lost segment. This issue can be 534 circumvented by retransmitting the recovered segment, even though 535 it is not needed by the other endpoint anymore. This plugs the 536 "sequence hole" in the state of the middlebox. 537 o Rewriting payloads of previously seen segments. 538 o Packet coalescing and splitting. 540 5. Implementation and Performance 542 We implemented TCP-IR in Linux TCP in about 1600 lines of code. 20% 543 of the modular implementation includes the parts common to both the 544 sender and receiver, which are option encoding/decoding, and 545 negotiation during connection setup. 50% of the implementation is the 546 receiver components including detection of an encoded packet, 547 decoding the TCP-IR payload, and generating the right 548 acknowledgements upon a successful or failed recovery. The remainder 549 30% of the implementation is the sender component which consists 550 mainly of payload encoding and transmission. 552 We conducted two kinds of experiments. The first was in an emulated 553 setting using loss patterns similar to those observed in our 554 measurement of real traffic. We used the netem module to emulate a 555 200 ms RTT and both random and correlated loss rates of 2%. TCP-IR 556 reduced the latency for short transfers in lossy environments by 28% 557 in the 90th percentile. The benefits diminish as the minimum number 558 of RTTs necessary to complete the transaction increases (due to the 559 message size) because the time to recover from losses no longer 560 dominates the overall transmission time. TCP-IR is better suited for 561 small transfers common in today's Web. 563 In the second set of experiments, we used the Web-page-replay tool 564 and dummynet to replay HTTP resource transfers for actual Web page 565 downloads through controlled, emulated network conditions. We tested 566 a variety of popular Web sites, and ran separate tests for Web pages 567 tailored for desktop and mobile clients. As an example, with TCP-IR, 568 the New York Times website takes 15% less time in the 90th percentile 569 until the first objects are rendered on the screen. 571 Details on performance experiments with TCP-IR are in 572 [RECOVERY-SIGCOMM13]. 574 6. Related Work 576 Applying FEC to transport, at nearly every layer, is an old idea. 577 [Coding-IEEE2011] suggested placing network coding in TCP, and 578 [CodedTCP-2013] extended this work by implementing a variant over UDP 579 mainly for high loss rate wireless environments. Among others, 580 [AdaptiveFEC-2004] and Tickoo et al. [LT-TCP-2005] explored 581 extending TCP to incorporate FEC. Finally, Maelstrom is an FEC 582 variant for long-range communication between data centers leveraging 583 the benefits of combining and encoding data from multiple sources 584 into a single stream [Maelstrom-2011]. The focus of all of this work 585 is on the performance aspects of using FEC over lossy links. None 586 address the protocol level changes required in TCP to incorporate 587 FEC. 589 7. Security Considerations 591 The security considerations outlined in [RFC5681] apply to this 592 document. At this time we did not find any additional security 593 problems with TCP-IR. 595 8. IANA Considerations 597 The two Options for TCP-IR used during negotiation and subsequently 598 in every packet of the connection require IANA allocate one value 599 from the TCP option Kind namespace. Experimentation prior to the 600 allocation SHOULD follow [EXPOPT] and use experimental option kind 601 254 and two magic bytes 0xDC60, and migrate to the new option after 602 the allocation accordingly. 604 Note to RFC Editor: this section may be removed on publication as an 605 RFC. 607 9. References 609 [RECOVERY-SIGCOMM13] 610 Flach, T., Dukkipati, N., Terzis, A., Raghavan, B., 611 Cardwell, N., Cheng, Y., Jain, A., Hao, S., Katz-Bassett, 612 E., and R. Govindan, "Reducing Web Latency: the Virtue of 613 Gentle Aggression", Proceedings of the 2013 ACM SIGCOMM , 614 2013. 616 [Coding-IEEE2011] 617 Sundararajan, J., Shah, D., Medard, M., Jakubczak, S., 618 Mitzenmacher, M., and J. Barros, "Network Coding Meets 619 TCP: Theory and Implementation", Proceedings of the IEEE , 620 2011. 622 [CodedTCP-2013] 623 Kim, M., Cloud, J., ParandehGheibi, A., Urbina, L., Fouli, 624 K., Leith, D., and M. Medard, "Network Coded TCP (CTCP)", 625 arXiv:1212.2291. , 2013. 627 [AdaptiveFEC-2004] 628 Baldantoni, L., Lundqvist, H., and G. Karlsson, "Adaptive 629 end-to-end FEC for improving TCP performance over wireless 630 links", IEEE Communications Society , 2004. 632 [LT-TCP-2005] 633 Tickoo, O., Subramanian, V., Kalyanaraman, S., and K. 634 Ramakrishnan, "LT-TCP: End-to-End Framework to improve TCP 635 Performance over Networks with Lossy Channels ", Proc. of 636 IWQoS , 2005. 638 [Maelstrom-2011] 639 Balakrishnan, M., Marian, T., Birman, K., Weatherspoon, 640 H., and L. Ganesh, "Maelstrom: transparent error 641 correction for communication between data centers ", IEEE/ 642 ACM Transactions on Networking , 2011. 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", RFC 2119, March 1997. 647 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 648 Control", RFC 5681, September 2009. 650 [EXPOPT] Touch, J., "Shared Use of Experimental TCP Options", 651 draft-ietf-tcpm-experimental-options-06 (work in 652 progress), October 2012. 654 Authors' Addresses 655 Tobias Flach 656 University of Southern California 657 941 Bloom Walk 658 Los Angeles, California 90089 659 USA 661 Email: flach@usc.edu 662 URI: http://nsl.cs.usc.edu/~tobiasflach 664 Nandita Dukkipati 665 Google, Inc. 666 1600 Amphitheatre Parkway 667 Mountain View, California 94043 668 USA 670 Email: nanditad@google.com 672 Yuchung Cheng 673 Google, Inc. 674 1600 Amphitheatre Parkway 675 Mountain View, California 94043 676 USA 678 Email: ycheng@google.com 680 Barath Raghavan 681 Google, Inc. 682 1600 Amphitheatre Parkway 683 Mountain View, California 94043 684 USA 686 Email: barath@google.com