idnits 2.17.1 draft-eggert-tcpm-tcp-retransmit-now-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 871. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 861. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 289 has weird spacing: '...mediate sched...' == Line 290 has weird spacing: '...ransmit retr...' == Line 552 has weird spacing: '...ased on fast ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 28, 2005) is 6877 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) == Unused Reference: 'I-D.dawkins-trigtran-linkup' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tcpm-tcp-uto' is defined on line 730, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) == Outdated reference: A later version (-03) exists of draft-ietf-hip-arch-02 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-uto-00 == Outdated reference: A later version (-07) exists of draft-swami-tcp-lmdr-05 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Eggert 3 Internet-Draft S. Schuetz 4 Expires: December 30, 2005 S. Schmid 5 NEC 6 June 28, 2005 8 TCP Extensions for Immediate Retransmissions 9 draft-eggert-tcpm-tcp-retransmit-now-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 This document may not be modified, and derivative works of it may not 18 be created, except to publish it as an RFC and to translate it into 19 languages other than English. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 30, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document classifies connectivity disruptions along an end-to-end 46 path into four types and describes how standard TCP mechanisms can 47 lead to inefficient or over-aggressive sending behavior when 48 connectivity resumes. The proposed techniques for TCP mobility 49 detection and response (LMDR) can improve behavior for some types of 50 disruptions. This document describes another, complementary and 51 orthogonal modification to TCP's retransmission scheme that improves 52 performance for disruption types that TCP LMDR does not address. 53 This extension is based on connectivity indicators, i.e., generic 54 network events that may indicate that end-to-end connectivity has 55 resumed. This document focuses on TCP modifications that use 56 connectivity indicators to increase performance, but does not define 57 the specifics of such connectivity indicators itself. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Classification of Connectivity Disruptions . . . . . . . . . 4 64 3.1 Short Connectivity Disruptions . . . . . . . . . . . . . . 5 65 3.2 Long Connectivity Disruptions . . . . . . . . . . . . . . 5 66 4. Examples of Connectivity Indicators . . . . . . . . . . . . 8 67 5. TCP Immediate Retransmission Extension . . . . . . . . . . . 9 68 5.1 Variant Based on Fast Retransmit . . . . . . . . . . . . . 10 69 5.2 Variant Based on Retransmission Option . . . . . . . . . . 11 70 5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12 71 6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 73 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 11.1 Normative References . . . . . . . . . . . . . . . . . . 15 78 11.2 Informative References . . . . . . . . . . . . . . . . . 15 79 Editorial Comments . . . . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 81 A. Document Revision History . . . . . . . . . . . . . . . . . 18 82 Intellectual Property and Copyright Statements . . . . . . . 20 84 1. Introduction 86 Depending on the specific path between two nodes in the Internet, 87 disruptions in connectivity may be frequent. Host mobility and other 88 factors can further increase the likelihood of connectivity 89 disruptions. When hosts communicate with the Transmission Control 90 Protocol (TCP) [RFC0793], their connections may either abort during 91 periods of disrupted connectivity or exhibit significant performance 92 reduction compared to permanently connected paths [SCHUETZ- 93 THESIS][SCHUETZ-CCR]. This decrease in performance is mainly caused 94 by TCP's retransmission behavior after connectivity returns. 96 While connection aborts due to TCP's "user timeout" [TCP-ILLUSTRATED] 97 can be prevented with the TCP User Timeout Option [I-D.ietf-tcpm-tcp- 98 uto], additional mechanisms are required to improve TCP performance 99 when operating along paths with frequent connectivity disruptions. 101 This document describes a modification of TCP's retransmission scheme 102 to improve performance in such scenarios. The basic idea is to 103 trigger a speculative retransmission attempt when a TCP 104 implementation receives an indication that connectivity to a 105 previously unreachable peer node may have returned. [anchor2] These 106 extensions increase TCP performance through more intelligent 107 scheduling of retransmission attempts by using periods of 108 connectivity more efficiently. They do not cause significant amounts 109 of additional traffic (at most three empty ACKs in some situations, 110 see Section 5.1) and do not change TCP's congestion control 111 algorithms. 113 Note that this draft treats connectivity indicators as relatively 114 abstract events and focuses on how TCP should react when receiving 115 such triggers. Specific connectivity indicators will be described in 116 separate drafts. Simple connectivity indicators (some of which have 117 already been experimentally implemented [SCHUETZ-THESIS][SCHUETZ- 118 CCR]) include link- and network-layer events occurring at the first 119 and last hop of a path, i.e., on those links that are observable 120 directly from the end hosts. Examples of such simple connectivity 121 indicators are DHCP lease events [RFC2131], IPv6 router 122 advertisements [RFC2460], or MobileIP [RFC3775] binding updates and 123 HIP [I-D.ietf-hip-arch] readdressing events. It is also conceivable 124 to use events inside the network, which are not directly observable 125 by the end hosts, as connectivity triggers. However, it is currently 126 unclear how to signal these events to the end hosts. 128 Section 3 discusses TCP performance over intermittently connected 129 paths in more detail, classifies different types of disruptions and 130 describes their implications on TCP. Section 4 presents examples for 131 connectivity indicators and Section 5 describes the proposed 132 "immediate retransmission" extension to TCP. Section 6 discusses 133 related work, Section 7 investigates security aspects of the proposed 134 modification and Section 8 summarizes and concludes this document. 136 2. Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 3. Classification of Connectivity Disruptions 144 Connectivity disruptions occur in many different situations. They 145 can be due to wireless interference, movement out of a wireless 146 coverage area, switching between access networks, or simply due to 147 unplugging an Ethernet cable. Depending on the situation in which 148 they occur, the implications of connectivity disruptions are 149 different and must be handled appropriately. This section attempts 150 to classify different types of connectivity disruptions and discusses 151 their implications and effects on TCP. 153 Two main properties affect how TCP reacts to a connectivity 154 disruption: the duration of a connectivity disruption and whether the 155 path characteristics have significantly changed after it ends. This 156 draft distinguishes between "short" and "long" disconnections and 157 "changed" and "unchanged" path characteristics. 159 Connectivity disruptions are "short" for a given TCP connection, if 160 connectivity returns before the RTO first fires. In this case, 161 standard TCP recovers lost data segments through Fast Retransmit and 162 lost ACKs through successfully delivered later ACKs. Section 3.1 163 briefly describes this case. 165 Connectivity disruptions are "long" for a given TCP connection, if 166 the RTO fires at least once before connectivity returns. In this 167 case, TCP can be inefficient in its retransmission scheme, as 168 described in Section 3.2. 170 Whether or not path characteristics change when connectivity returns 171 is a second important factor for TCP's retransmission scheme. 172 Standard TCP implicitly assumes that path characteristics remain 173 unchanged for short disruptions by performing Fast Retransmit based 174 on path parameters collected before the disruption. For long 175 disruptions, standard TCP is more conservative and performs slow- 176 start, re-probing the path characteristics from scratch. 178 These implicit assumptions can cause standard TCP to misbehave or 179 perform inefficiently in some scenarios. Figure 1 illustrates the 180 standard TCP behavior. 182 +----------------------+----------------------+ 183 Short | Fast Retransmit | Fast Retransmit | 184 Duration | using collected path | using collected path | 185 < RTO | characteristics | characteristics | 186 +----------------------+----------------------+ 187 Long | | | 188 Duration | Slow-start | Slow-start | 189 >= RTO | | | 190 +----------------------+----------------------+ 191 Unchanged Path Changed Path 192 Characteristics Characteristics 194 Figure 1: Standard TCP behavior 196 3.1 Short Connectivity Disruptions 198 For short disruptions, standard TCP performs Fast Retransmit based on 199 the previously collected path characteristics. When path 200 characteristics remain unchanged after connectivity resumes, this is 201 an effective and efficient mechanism. 203 On the other hand, when path characteristics do change after a short 204 disruption, TCP may be too aggressive in its sending behavior. This 205 can occur, for example, after MobileIP handovers. A TCP extension to 206 inform a peer about such events and trigger the probing behavior is 207 currently being proposed [I-D.swami-tcp-lmdr]. The LMDR extension 208 involves forced invalidation of collected path characteristics and 209 re-probing the new path from scratch. 211 3.2 Long Connectivity Disruptions 213 For long disruptions, standard TCP performs slow-start after 214 connectivity returns. This is a conservative strategy that avoids 215 overloading the new path. However, TCP's general exponential back- 216 off retransmission strategy can time these slow-starts such that 217 performance decreases. 219 This section describes this issue in detail. Later sections of this 220 document propose a different method of scheduling retransmission 221 attempts after connectivity returns, which results in a more 222 efficient retransmission behavior. 224 When a long connectivity disruption occurs along the path between a 225 host and its peer while the host is transmitting data, it stops 226 receiving acknowledgments. After the retransmission timeout (RTO) 227 expires, the host attempts to retransmit the first unacknowledged 228 segment. TCP implementations that follow the recommended RTO 229 management proposed in [RFC2988] double the RTO after each 230 retransmission attempt until it exceeds 60 seconds. This scheme 231 causes a host to attempt to retransmit across established connections 232 roughly once a minute. (More frequently during the first minute or 233 two of the connectivity disruption, while the RTO is still being 234 backed off.) 236 When the long connectivity disruption ends, standard TCP 237 implementations still wait until the RTO expires before attempting 238 retransmission. Figure 2 illustrates this behavior. Depending on 239 when connectivity becomes available again, this can waste up to a 240 minute of connection time for TCPs that implement the recommended RTO 241 management described in [RFC2988]. For TCP implementations that do 242 not implement [RFC2988], even more connection time may be lost. For 243 example, Linux uses 120 seconds as the maximum RTO. 245 Sequence 246 number X = Successfully transmitted segment 247 ^ O = Lost segment 248 | : : : X 249 | : : :X 250 | OO O O O O : X 251 | X: : : 252 | X : :<------------>: 253 | X : : Wasted : 254 | X : : connection : 255 |X : : time : 256 +-----:---------------------:--------------:--------> 257 : : : Time 258 Connectivity Connectivity TCP 259 gone back retransmit 261 Figure 2: Standard TCP behavior in the presence of disrupted 262 connectivity 264 This retransmission behavior is not efficient, especially in 265 scenarios where connected periods are short and connectivity 266 disruptions are frequent [DRIVE-THRU]. Experiments show that TCP 267 performance across a path with frequent disruptions is significantly 268 worse, compared to a similar path without disruptions [SCHUETZ- 269 THESIS][SCHUETZ-CCR]. 271 In the ideal case, TCP would attempt a retransmission as soon as 272 connectivity to its peer was re-established. Figure 3 illustrates 273 the ideal behavior. 275 Sequence 276 number X = Successfully transmitted segment 277 ^ O = Lost segment 278 | : : X : 279 | : :X : 280 | OO O O O O X : 281 | X: : : 282 | X : :<------------>: 283 | X : : Efficiency : 284 | X : : improvement : 285 |X : : : 286 +-----:---------------------:--------------:--------> 287 : : : Time 288 Connectivity Connectivity Next 289 gone back = immediate scheduled 290 TCP retransmit retransmit 292 Figure 3: Ideal TCP behavior in the presence of disrupted 293 connectivity 295 The ideal behavior is difficult to achieve for arbitrary connectivity 296 disruptions. One obviously problematic approach would use higher- 297 frequency retransmission attempts to enable earlier detection of 298 whether connectivity has returned. This can generate significant 299 amounts of extra traffic. Other proposals attempt to trigger faster 300 retransmissions by retransmitting buffered or newly-crafted segments 301 from inside the network [SCOTT][I-D.dawkins-trigtran- 302 linkup][RFC3819]. Section 6 compares these approaches to the 303 "immediate retransmission" extension. 305 Note that scenarios exist where path characteristics remain unchanged 306 after long connectivity disruptions. In this case, even an 307 intelligently scheduled slow-start is inefficient, because TCP could 308 safely resume transmitting at the old rate instead of slow-starting. 309 Although originally developed to avoid line-rate bursts, techniques 310 for the well-known "slow-start after idle" case [I-D.ietf-tcpimpl- 311 restart] may be useful to further improve performance after a 312 disruption ends. This document does not currently describe this 313 additional optimization. 315 Also note that on asymmetric paths, TCP's standard retransmission 316 behavior can be over-aggressive in some scenarios. If the forward 317 and reverse paths have significantly different RTTs, a long 318 disruption for the host that sends along the lower-delay path may 319 still be a short disruption for its peer host, because of its 320 correspondingly longer RTO. When the sender resumes and slow-starts, 321 the peer performs fast retransmit, which can lead to line-rate 322 bursts. An LMDR-like mechanism that resets collected path 323 characteristics and forces a slow-start re-probe could be effective 324 in these cases [I-D.swami-tcp-lmdr]. 326 The following sections of this document focus on mechanisms to 327 improve TCP's efficiency when resuming after long disruptions. They 328 use connectivity indicators to schedule retransmission attempts more 329 effectively than TCP's standard exponential back-off scheme. To 330 improve behavior after short disruptions, the mechanisms in 331 [I-D.swami-tcp-lmdr] are effective. Eventually, the TCP-option-based 332 mechanism described there may be extended to incorporate the 333 retransmission option described in Section 5.2 below. 335 4. Examples of Connectivity Indicators 337 This section describes examples of connectivity indicators, which the 338 retransmission mechanism described in the next section acts upon. 339 This document does not define the specifics of such connectivity 340 indicators but merely discusses them to illustrate the operation of 341 the "immediate retransmission" extension. 343 Connectivity indicators signal TCP when connectivity to a previously 344 unreachable peer may have returned. They depend on the specifics of 345 a node and its environment, for example network-layer mechanisms such 346 as DHCP [RFC2131], MobileIP [RFC3775] or HIP [I-D.ietf-hip-arch]. 347 The IETF's Detection of Network Attachment (DNA) working group 348 currently investigates the specifics of providing such connectivity 349 indicators [I-D.ietf-dna-goals]. 351 One example of a connectivity indicator is "next hop reachable." 352 This indicator could occur if a combination of the following 353 conditions is true, depending on host specifics: 355 o Network-layer connectivity along the path to the destination 356 returned, e.g., the outbound interface has an IP address and a 357 next-hop router is known, maybe due to DHCP [RFC2131] or IPv6 358 router advertisements [RFC2460]. 360 o Link-layer connectivity of the link to the next-hop router along 361 the path to the destination returned (e.g., link-layer "link up"). 363 o Other local conditions that affect reachability of the destination 364 are satisfied (e.g., IKE exchanges [RFC2409], MobileIP binding 365 updates [RFC3775] or HIP readdressing [I-D.nikander-hip-mm] have 366 completed). 368 The "next hop reachable" connectivity indicator only depends on 369 locally determinable information (e.g., state of directly-connected 370 links, etc.) and does not require network cooperation. It can signal 371 TCP to restart active connections across intermittently connected 372 links where disruptions occur on the first or last hop. This simple 373 indicator has the potential to improve TCP performance in many cases, 374 because connectivity disruptions at the first or last hop are 375 arguably the most common cause of connectivity disruptions in today's 376 Internet. 378 A second, more general example of a connectivity indicator would be 379 "end-to-end connectivity returned." If hosts have the ability to 380 detect or be notified of connectivity changes inside the network 381 (i.e., not only at the first or last hop), a more general 382 retransmission mechanism could act on those pieces of information. 383 This can improve TCP performance across intermittently connected 384 paths where disruptions occur at arbitrary links along the path, even 385 inside the network. However, providing this more general 386 connectivity indicator is problematic due to its dependence on remote 387 information and its related issues, such as trust. 389 Connectivity indicators are generally asymmetric, i.e., they may 390 occur on one peer host but not the other. As discussed above, a 391 local event at one host may trigger the "immediate retransmission" 392 mechanism, while the other host is unable to detect this event across 393 the network. Symmetric connectivity indicators are a special case 394 and always occur concurrently at both communicating hosts. Examples 395 for such symmetric connectivity indicators are handshake events such 396 as IKE exchanges or HIP readdressing. Symmetric indicators are an 397 important special case, because the retransmission procedure required 398 in response to a symmetric indicator is simpler than that for an 399 asymmetric one. The next section will describe this in detail. 401 5. TCP Immediate Retransmission Extension 403 This section describes the main contribution of this document, i.e., 404 TCP extensions for immediate retransmission in response to 405 connectivity indicators. The basic idea behind the "immediate 406 retransmission" extension is to allow TCP to resume stalled 407 connections as soon as it receives an indicator that connectivity to 408 previously unreachable peers may have returned. 410 This document does not specify how TCP determines which connections a 411 specific connectivity indicator affects, i.e., for which connections 412 it should initiate retransmission attempts. This is a property of 413 individual connectivity indicators. For example, the "next hop 414 reachable" indicator described in the previous section affects 415 connections to all destinations routed through that hop. 417 It is important to note that this retransmission extension does not 418 modify TCP's basic congestion control, fairness properties or slow- 419 start algorithms. The only difference in TCP behavior is the timing 420 of retransmission events and, in some cases, a minor, fixed increase 421 in the number of initially retransmitted segments. The "immediate 422 retransmission" extension increases performance through better 423 utilization of connected periods, not through sending traffic at a 424 faster rate or modifying TCP's congestion control mechanisms. 426 Hosts that implement the "immediate retransmission" TCP extension 427 MUST implement the following retransmission mechanism whenever they 428 receive a connectivity indicator: 430 When receiving a symmetric or asymmetric connectivity indicator, 431 conforming TCP implementations MUST immediately initiate the standard 432 retransmission procedure for connections that the connectivity 433 indicator affects - just as if the RTO for those connections had 434 expired. 436 If the connectivity indicator is symmetric, i.e., all peers receive 437 it concurrently; this simple change is sufficient to kick-start the 438 relevant TCP connections. 440 If the connectivity indicator is asymmetric, this simple extension is 441 not always sufficient, because only one peer has received the 442 indicator. In case the host receiving the connectivity indicator has 443 no (or too little) unacknowledged data awaiting retransmission, it 444 will not emit enough segments to cause its peer node, which may have 445 unacknowledged data as well, to attempt retransmission. Transmission 446 would thus only resume in one direction, which is ineffective for 447 two-way communication. 449 To avoid this issue, conforming TCP implementation MUST perform a 450 different retransmission procedure in response to an asymmetric 451 connectivity indicator. The following sections describe two 452 alternative TCP modifications that aim to improve retransmission 453 behavior after receiving an asymmetric connectivity indicator. 454 Section 5.1 describes the first variant. As described in an earlier 455 revision of this document, this variant generates duplicate ACKs to 456 activate the peer's fast retransmit algorithm. Section 5.2 describes 457 the second variant, based on an explicit, new TCP "immediate 458 retransmission" option. 460 5.1 Variant Based on Fast Retransmit 462 This variant of improving TCP retransmission scheme based on 463 connectivity indicators uses duplicate ACKs. Conforming TCPs MUST 464 send at least four segments that all acknowledge the last segment 465 received from a peer for all connections that the connectivity 466 indicator affects. These triple-duplicate ACKs will activate the 467 peers' fast retransmit algorithms and cause them to immediately 468 restart communication in the reverse direction, i.e., before their 469 next scheduled retransmission. 471 In this variant, if a TCP connection that a connectivity indicator 472 affects has four or more unacknowledged data segments in the 473 retransmission queue, it SHOULD piggyback the triple-duplicate ACK to 474 the regular retransmissions of those data segments. In this case, 475 the "immediate retransmission" TCP extension does not require 476 additional messages, compared to standard TCP. 478 For connections where the retransmission queue contains only three or 479 less unacknowledged data segments, TCP implementations supporting the 480 "immediate retransmission" TCP extension MUST send additional pure 481 ACKs until they have sent a complete triple-duplicate ACK. In the 482 worst case, when the retransmission queue is empty, this scheme 483 requires four additional ACKs, compared to standard TCP. 485 After the peer's fast retransmit algorithm sends the assumed missing 486 segment, TCP performs either fast recovery or a slow-start [RFC2581], 487 depending on the length of the connectivity disruption. If the 488 connectivity indicator occurs before the RTO, i.e., for very short 489 disruptions, TCP has not yet lost its ACK clock and can thus perform 490 fast recovery. After longer disruptions, TCP falls back to slow- 491 start to restart the ACK clock, just as it does at the beginning of a 492 connection. 494 The result of this modification is twofold. First, TCP connections 495 receiving the connectivity indicator attempt retransmission of their 496 unacknowledged segments before the next scheduled RTO. This 497 increases utilization of connected periods. Second, TCP connections 498 receiving the connectivity indicator use an existing TCP mechanism 499 (triple-duplicate ACK) to signal their peer. Although the peer may 500 not have received a connectivity indicator itself (e.g., the 501 indicator was asymmetric), this causes it to attempt faster 502 retransmission as well. 504 As mentioned above, the "immediate retransmission" scheme can 505 generate up to four additional segments, compared to standard TCP. 506 All additional segments are pure ACKs and hence small, resulting in a 507 minor total overhead. Furthermore, measurements have shown that 508 increasing TCP's initial window is not problematic [ALLMAN]; this may 509 indicate that a minor increase in traffic at retransmission time may 510 be tolerable as well. 512 5.2 Variant Based on Retransmission Option 514 Unlike the mechanism described in the previous section, the second 515 variant described in this section does not overload an existing TCP 516 mechanism - i.e., fast retransmit - to improve retransmission after a 517 connectivity disruption. Generating duplicate ACKs in the manner 518 described in Section 5.1 was criticized by some working group 519 participants as "an abuse of a well-defined TCP mechanism for an 520 unrelated purpose." The variant described in this section uses a new 521 TCP "Immediate Retransmission" Option to explicitly signal to the 522 remote peer that should attempt a retransmit. It was originally 523 suggested by Kacheong Poon [POON] and the specifics are currently 524 under investigation; this section describes the current state of this 525 variant. 527 When receiving a connectivity indicator, conforming TCP 528 implementations MUST send a single segment to each affected peer. 529 This segment MUST contain the TCP Immediate Retransmission Option and 530 may either be a queued data retransmission or a pure ACK, if the 531 connection has no data awaiting retransmission. 533 Upon reception of the TCP Immediate Retransmission Option, conforming 534 TCPs MUST immediately attempt a retransmit. This could either be a 535 fast retransmit for short disruptions or a slow-start for long 536 disruptions. 538 Note that the same effect can be achieved by overloading the TCP LMDR 539 option [I-D.swami-tcp-lmdr], i.e., sending it in response to a 540 connectivity indicator, and triggering a retransmission attempt upon 541 reception. Overloading LMDR in this way also has the benefit of 542 being able to force a reset of accumulated path state followed by a 543 slow-start. However, a flag in the option would be needed to trigger 544 a retransmit without this reset, to cover all types of disruptions 545 discussed in Section 3. Given the similar motivation and relatively 546 orthogonal, complementary mechanisms proposed here and in [I-D.swami- 547 tcp-lmdr], this may be attractive solution. 549 5.3 Discussion 551 One major drawback of using a retransmission option compared to the 552 one based on fast retransmit is that it requires both communicating 553 TCPs to implement this modification. Triggering a peer's fast 554 retransmit with duplicate ACKs only requires the triggering local 555 peer to support this extension - the triggered remote peer may run an 556 unmodified TCP stack. Additionally, firewalls may block segments 557 carrying unknown TCP options. Finally, TCP option space is becoming 558 limited. 560 One major advantage of using an option, however, is that it avoids 561 overloading an established TCP mechanism to produce side effects. 562 Using an option also allows a more careful definition of the 563 semantics of the mechanism, e.g., control of whether and when it 564 should reset accumulated path state or what transmission scheme to 565 schedule retransmits with. 567 6. Related Work 569 Several other approaches try to improve TCP performance in the 570 presence of connectivity disruptions [SCOTT][I-D.dawkins-trigtran- 571 linkup][RFC3819]. They attempt to improve TCP startup after a 572 connectivity disruption by retransmitting buffered or newly-crafted 573 segments from inside the network. 575 These proposals can be problematic, because TCP is built on the 576 assumption that segments older than the maximum segment lifetime 577 (MSL) of 2 minutes [RFC0793] will never be received. When a 578 connectivity disruption lasts longer than the MSL, either these 579 proposals will become ineffective or they risk leaking buffered old 580 segments onto new connections, violating TCP's semantics. 582 The "immediate retransmission" modification also improves performance 583 over a path with frequent connectivity disruptions. The basic idea 584 is to schedule an additional, speculative retransmission attempt when 585 a TCP implementation receives an indication that connectivity to a 586 peer node has returned. Unlike the other proposals, the "immediate 587 retransmission" scheme uses regular retransmissions, i.e., 588 retransmits data that is buffered at the end systems. Because that 589 data has not entered the network yet, it is not subject to the 590 problematic MSL rule. Consequently, the "immediate retransmission" 591 scheme remains effective even for connectivity disruption longer than 592 the MSL, without the risk of compromising connection integrity. 594 Other transport-layer approaches such as the Explicit Link Failure 595 Notification [HOLLAND] or TCP-F [CHANDRAN] use specific messages 596 generated by intermediate routers to inform TCP senders about 597 disrupted paths. The former extends the TCP state machine with a new 598 "stand by" state during which the standard retransmission timers are 599 disabled. In this state, TCP periodically probes the network to 600 detect connectivity reestablishment. Depending on the frequency of 601 the probes and the network environment, this can cause significant 602 amounts of extra traffic. TCP-F completely suspends ongoing 603 connections until receiving "route reestablishment notifications" 604 that indicate peer reachability. Both proposals are primarily 605 designed for ad hoc networks and rely on changes to intermediate 606 routers, whereas the "immediate retransmission" extension only 607 requires end system support. 609 ATCP [ATCP] uses a similar approach as the Explicit Link Failure 610 Notification, but discovers link failures through ICMP Destination 611 Unreachable messages. Caceres and Iftode [CACERES] propose and 612 evaluate a solution similar to the TCP "immediate" retransmission 613 extension that improves performance during MobileIP hand-offs. 614 Unlike the solution proposed in this paper, the hand-off mechanism 615 targets connectivity disruptions of a few seconds. 617 7. Security Considerations 619 To protect against abuse of the TCP "immediate retransmission" 620 extension, e.g., denial-of-service attacks by flooding TCP with 621 connectivity indicators, a control mechanism that "rate-limits" these 622 indicators may be effective. This document does not currently 623 discuss the security aspects of connectivity indicators and the 624 "immediate retransmission" extension to TCP. 626 8. Conclusion 628 This document described the "immediate retransmission" extension to 629 TCP's standard retransmission scheme. The new extension improves 630 performance across intermittently connected paths through additional, 631 speculative retransmission attempts upon receiving external 632 connectivity indicators. One example of such a connectivity 633 indicator is "first hop router reachable." This document did not 634 define the specifics of such connectivity indicators, although it 635 described some examples to illustrate the operation of the "immediate 636 retransmission" extension, which is its main contribution. 638 9. IANA Considerations 640 This section is to be interpreted according to [RFC2434]. 642 This document does not define any new namespaces. It uses an 8-bit 643 TCP option number maintained by IANA at 644 http://www.iana.org/assignments/tcp-parameters. 646 10. Acknowledgments 648 The following people have helped to improve this document through 649 thoughtful suggestions and feedback: Marcus Brunner, Wesley Eddy, 650 Kacheong Poon, Juergen Quittek and Joe Touch. 652 The authors are partly funded by Ambient Networks, a research project 653 supported by the European Commission under its Sixth Framework 654 Program. The views and conclusions contained herein are those of the 655 authors and should not be interpreted as necessarily representing the 656 official policies or endorsements, either expressed or implied, of 657 the Ambient Networks project or the European Commission. 659 11. References 661 11.1 Normative References 663 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 664 RFC 793, September 1981. 666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 667 Requirement Levels", BCP 14, RFC 2119, March 1997. 669 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 670 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 671 October 1998. 673 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 674 Control", RFC 2581, April 1999. 676 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 677 Timer", RFC 2988, November 2000. 679 11.2 Informative References 681 [ALLMAN] Allman, M., Hayes, C., and S. Ostermann, "An Evaluation of 682 TCP with Larger Initial Windows.", ACM Computer 683 Communication Review, Vol. 28, No. 3, July 1998. 685 [ATCP] Liu, J. and S. Singh, "ATCP: TCP for Mobile Ad Hoc 686 Networks", IEEE Journal on Selected Areas in 687 Communication, Vol. 19, No. 7, July 2001. 689 [CACERES] Caceres, R. and L. Iftode, "Improving the Performance of 690 Reliable Transport Protocols in Mobile Computing 691 Environments", IEEE Journal on Selected Areas in 692 Communication, Vol. 13, No. 5, 1995. 694 [CHANDRAN] 695 Chandran, K., Raghunathan, S., Venkatesan, S., and R. 696 Prakash, "A Feedback Based Scheme For Improving TCP 697 Performance In Ad-Hoc Wireless Networks", IEEE Personal 698 Communication Systems (PCS) Magazine: Special Issue on Ad 699 Hoc Networks, Vol. 8, No. 1, February 2001. 701 [DRIVE-THRU] 702 Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE 703 802.11b for Automobile Users", Proc. Infocom 2004, 704 March 2004. 706 [HOLLAND] Holland, G. and N. Vaidya, "Analysis of TCP Performance 707 over Mobile Ad Hoc Networks", Proc. 5th Annual ACM/IEEE 708 International Conference on Mobile Computing and 709 Networking, Seattle, WA, USA, 1999. 711 [I-D.dawkins-trigtran-linkup] 712 Dawkins, S., "End-to-end, Implicit 'Link-Up' 713 Notification", draft-dawkins-trigtran-linkup-01 (work in 714 progress), October 2003. 716 [I-D.ietf-dna-goals] 717 Choi, J., "Goals of Detecting Network Attachment in IPv6", 718 draft-ietf-dna-goals-04 (work in progress), December 2004. 720 [I-D.ietf-hip-arch] 721 Moskowitz, R., "Host Identity Protocol Architecture", 722 draft-ietf-hip-arch-02 (work in progress), January 2005. 724 [I-D.ietf-tcpimpl-restart] 725 Hughes, A., Touch, J., and J. Heidemann, "Issues in TCP 726 Slow-Start Restart After Idle", 727 draft-ietf-tcpimpl-restart-00 (work in progress), 728 March 1998. 730 [I-D.ietf-tcpm-tcp-uto] 731 Eggert, L. and F. Gont, "TCP User Timeout Option", 732 draft-ietf-tcpm-tcp-uto-00 (work in progress), May 2005. 734 [I-D.nikander-hip-mm] 735 Nikander, P., "End-Host Mobility and Multi-Homing with 736 Host Identity Protocol", draft-nikander-hip-mm-02 (work in 737 progress), July 2004. 739 [I-D.swami-tcp-lmdr] 740 Swami, Y. and K. Le, "Lightweight Mobility Detection and 741 Response (LMDR) Algorithm for TCP", 742 draft-swami-tcp-lmdr-05 (work in progress), February 2005. 744 [POON] Poon, K., "Personal Communication", August 2004. 746 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 747 RFC 2131, March 1997. 749 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 750 (IKE)", RFC 2409, November 1998. 752 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 753 (IPv6) Specification", RFC 2460, December 1998. 755 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 756 in IPv6", RFC 3775, June 2004. 758 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 759 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 760 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 761 RFC 3819, July 2004. 763 [SCHUETZ-CCR] 764 Schuetz, S., Eggert, L., Schmid, S., and M. Brunner, 765 "Protocol Enhancements for Intermittently Connected 766 Hosts", To appear: ACM Computer Communication Review, Vol. 767 35, No. 3, July 2005. 769 [SCHUETZ-THESIS] 770 Schuetz, S., "Network Support for Intermittently Connected 771 Mobile Nodes", Diploma Thesis, University of Mannheim, 772 Germany, June 2004. 774 [SCOTT] Scott, J. and G. Mapp, "Link layer-based TCP optimisation 775 for disconnecting networks", ACM Computer Communication 776 Review, Vol. 33, No. 5, October 2003. 778 [TCP-ILLUSTRATED] 779 Stevens, W., "TCP/IP Illustrated, Volume 1: The 780 Protocols", Addison-Wesley , 1994. 782 Editorial Comments 784 [anchor2] LE: The authors have seen the idea of triggering 785 retransmits based on connectivity events of directly- 786 connected links attributed to Phil Karn, but were unable 787 to locate a specific reference. Pointers to a citable 788 reference are highly appreciated! 790 Authors' Addresses 792 Lars Eggert 793 NEC Network Laboratories 794 Kurfuerstenanlage 36 795 Heidelberg 69115 796 Germany 798 Phone: +49 6221 90511 43 799 Fax: +49 6221 90511 55 800 Email: lars.eggert@netlab.nec.de 801 URI: http://www.netlab.nec.de/ 803 Simon Schuetz 804 NEC Network Laboratories 805 Kurfuerstenanlage 36 806 Heidelberg 69115 807 Germany 809 Phone: +49 6221 90511 65 810 Fax: +49 6221 90511 55 811 Email: simon.schuetz@netlab.nec.de 812 URI: http://www.netlab.nec.de/ 814 Stefan Schmid 815 NEC Network Laboratories 816 Kurfuerstenanlage 36 817 Heidelberg 69115 818 Germany 820 Phone: +49 6221 90511 54 821 Fax: +49 6221 90511 55 822 Email: stefan.schmid@netlab.nec.de 823 URI: http://www.netlab.nec.de/ 825 Appendix A. Document Revision History 827 +-----------+-------------------------------------------------------+ 828 | Revision | Comments | 829 +-----------+-------------------------------------------------------+ 830 | 00 | Initial version. | 831 | 01 | Updated terminology according to [SCHUETZ-CCR]. Added | 832 | | "retransmission option" variant as Section 5.2. | 833 | 02 | Added classification of connectivity disruptions and | 834 | | describe the design space in relation to | 835 | | [I-D.swami-tcp-lmdr] and [I-D.ietf-tcpimpl-restart]. | 836 | | Updated references. | 837 +-----------+-------------------------------------------------------+ 839 Intellectual Property Statement 841 The IETF takes no position regarding the validity or scope of any 842 Intellectual Property Rights or other rights that might be claimed to 843 pertain to the implementation or use of the technology described in 844 this document or the extent to which any license under such rights 845 might or might not be available; nor does it represent that it has 846 made any independent effort to identify any such rights. Information 847 on the procedures with respect to rights in RFC documents can be 848 found in BCP 78 and BCP 79. 850 Copies of IPR disclosures made to the IETF Secretariat and any 851 assurances of licenses to be made available, or the result of an 852 attempt made to obtain a general license or permission for the use of 853 such proprietary rights by implementers or users of this 854 specification can be obtained from the IETF on-line IPR repository at 855 http://www.ietf.org/ipr. 857 The IETF invites any interested party to bring to its attention any 858 copyrights, patents or patent applications, or other proprietary 859 rights that may cover technology that may be required to implement 860 this standard. Please address the information to the IETF at 861 ietf-ipr@ietf.org. 863 Disclaimer of Validity 865 This document and the information contained herein are provided on an 866 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 867 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 868 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 869 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 870 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 871 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 873 Copyright Statement 875 Copyright (C) The Internet Society (2005). This document is subject 876 to the rights, licenses and restrictions contained in BCP 78, and 877 except as set forth therein, the authors retain all their rights. 879 Acknowledgment 881 Funding for the RFC Editor function is currently provided by the 882 Internet Society.