idnits 2.17.1 draft-eggert-tcpm-tcp-retransmit-now-01.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 681. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 12) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 187 has weird spacing: '...mediate sched...' == Line 188 has weird spacing: '...ransmit retr...' -- 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 (September 10, 2004) is 7167 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: '6' is defined on line 522, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2988 (ref. '3') (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 2581 (ref. '4') (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '16') (Obsoleted by RFC 6275) == Outdated reference: A later version (-04) exists of draft-ietf-dna-goals-00 -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '19') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '20') (Obsoleted by RFC 4306) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Eggert 2 Internet-Draft S. Schuetz 3 Expires: March 11, 2005 S. Schmid 4 NEC 5 September 10, 2004 7 TCP Extensions for Immediate Retransmissions 8 draft-eggert-tcpm-tcp-retransmit-now-01 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. This document may not be modified, and derivative works of 18 it may not be created, except to publish it as an RFC and to 19 translate it into 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 24 Internet-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 March 11, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 This document describes a modification to TCP's standard 46 retransmission scheme that improves performance across intermittently 47 connected paths. In addition to the regular retransmission attempts 48 scheduled at exponentially increasing intervals, this extension 49 causes additional, speculative retransmission attempts upon receiving 50 external connectivity indicators. One example of such a connectivity 51 indicator is "first hop router reachable." This document does not 52 define the specifics of such connectivity indicators, although it 53 describes some examples. Instead, it defines how a conforming TCP 54 implementation operates when it receives a connectivity indicator. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Examples of Connectivity Indicators . . . . . . . . . . . . . 5 62 5. TCP Immediate Retransmission Extension . . . . . . . . . . . . 6 63 5.1 Variant Based on Fast Retransmit . . . . . . . . . . . . . 8 64 5.2 Variant Based on Retransmission Option . . . . . . . . . . 9 65 6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 72 11.2 Informative References . . . . . . . . . . . . . . . . . . . 12 73 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 75 A. Document Revision History . . . . . . . . . . . . . . . . . . 15 76 Intellectual Property and Copyright Statements . . . . . . . . 16 78 1. Introduction 80 Depending on the specific path between two nodes in the Internet, 81 disruptions in connectivity may be frequent. Host mobility and other 82 factors can further increase the likelihood of connectivity 83 disruptions. When hosts communicate with the Transmission Control 84 Protocol (TCP) [1], their connections may abort during periods of 85 disconnection. 87 The main reason for connection aborts during periods of disconnection 88 is TCP's "user timeout." It defines the maximum amount of time that 89 transmitted segments may remain unacknowledged. If a disconnection 90 lasts longer than the user timeout, the TCP connection will abort. 91 Many TCP implementations default to user timeout values of a few 92 minutes [7]. The proposed TCP Abort Timeout Option [8] allows 93 conforming TCP implementations to use longer user timeout values and 94 consequently tolerate long disconnections without disruption. 96 Although the TCP Abort Timeout Option enables TCP connections to 97 survive extended periods of disconnections, experiments have shown 98 that TCP connections perform significantly worse when operating along 99 paths with frequent disconnections [9][10]. This decrease in 100 performance is caused by TCP's retransmission behavior after 101 connectivity is restored. 103 This document describes a modification of TCP's retransmission scheme 104 to improve performance over a path with frequent disconnections. The 105 basic idea is to trigger a speculative retransmission attempt when a 106 TCP implementation receives an indication that connectivity to a 107 previously disconnected peer node may have been restored. 108 [Comment.1] 110 Section 3 discusses TCP performance over intermittently connected 111 paths in more detail, comparing it to similar proposals [11][12][13], 112 and Section 4 describes the proposed "immediate retransmission" 113 extension to TCP. Section 7 investigates security aspects of the 114 proposed modification and Section 8 summarizes and concludes this 115 document. 117 2. Conventions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [2]. 123 3. Background 125 When a disconnection occurs along the path between a host and its 126 peer while the host is transmitting data, it stops receiving 127 acknowledgments. After the retransmission timeout (RTO) expires, the 128 host attempts to retransmit the first unacknowledged segment. TCP 129 implementations that follow the recommended RTO management proposed 130 in RFC 2988 [3] double the RTO after each retransmission attempt 131 until it exceeds 60 seconds. This scheme causes a host to attempt to 132 retransmit across established connections roughly once a minute. 133 (More frequently during the first minute or two of the disconnection, 134 while the RTO is still being backed off.) 136 When the disconnection ends, standard TCP implementations still wait 137 until the RTO expires before attempting retransmission. Figure 1 138 illustrates this behavior. Depending on when connectivity becomes 139 available again, this can waste up to a minute of connection time for 140 TCPs that implement the recommended RTO management described in RFC 141 2988 [3]. For TCP implementations that do not implement RFC 2988, 142 even more connection time may be lost. For example, Linux uses 120 143 seconds as the maximum RTO. 145 sequence 146 number X = successfully transmitted segment 147 ^ O = lost segment 148 | : : : X 149 | : : :X 150 | XO O O O O : X 151 | X: : : 152 | X : :<------------>: 153 | X : : wasted : 154 | X : : connection : 155 |X : : time : 156 +-----:---------------------:--------------:--------> 157 : : : time 158 connectivity connectivity TCP 159 gone back retransmit 161 Figure 1: Standard TCP behavior in the presence of a disconnection 163 This retransmission behavior is not efficient, especially in 164 scenarios where connected periods are short and disconnections 165 frequent [14]. Experiments show that TCP performance across a path 166 with frequent disruptions is significantly worse compared to a 167 similar path without disruptions [9][10]. 169 In the ideal case, TCP would attempt a retransmission as soon as 170 connectivity to its peer was re-established. Figure 2 illustrates 171 the ideal behavior. 173 sequence 174 number X = successfully transmitted segment 175 ^ O = lost segment 176 | : : X : 177 | : :X : 178 | XO O O O O X : 179 | X: : : 180 | X : :<------------>: 181 | X : : efficiency : 182 | X : : improvement : 183 |X : : : 184 +-----:---------------------:--------------:--------> 185 : : : time 186 connectivity connectivity next 187 gone back = immediate scheduled 188 TCP retransmit retransmit 190 Figure 2: Ideal TCP behavior in the presence of a disconnection 192 The ideal behavior is difficult to achieve for arbitrary connectivity 193 disruptions. One obviously problematic approach would use 194 higher-frequency retransmission attempts to enable earlier detection 195 of whether connectivity was restored. This can generate significant 196 amounts of extra traffic. Other proposals attempt to trigger faster 197 retransmissions by retransmitting buffered or newly-crafted segments 198 from inside the network [11][12][13]. Section 6 compares these 199 approaches to the "immediate retransmission" extension. 201 4. Examples of Connectivity Indicators 203 This section describes examples of connectivity indicators, which the 204 retransmission mechanism described in the next section acts upon. 205 This document does not define the specifics of such connectivity 206 indicators but merely discusses them to illustrate the operation of 207 the "immediate retransmission" extension. 209 Connectivity indicators signal TCP when connectivity to a previously 210 disconnected peer may have been restored. They depend on the 211 specifics of a node and its environment, for example network-layer 212 mechanisms such as DHCP [15], MobileIP [16] or HIP [17]. The IETF's 213 Detection of Network Attachment (DNA) working group currently 214 investigates the specifics of providing such connectivity indicators 215 [18]. 217 One example of a connectivity indicator is "next hop reachable." This 218 indicator could occur if a combination of the following conditions is 219 true, depending on host specifics: 221 o Network-layer connectivity along the path to the destination is 222 restored, e.g., the outbound interface has an IP address and a 223 next-hop router is known, maybe due to DHCP [15] or IPv6 router 224 advertisements [19]. 226 o Link-layer connectivity of the link to the next-hop router along 227 the path to the destination is restored (e.g., link-layer "link 228 up"). 230 o Other local conditions that affect reachability of the destination 231 are satisfied (e.g., IKE exchanges [20], MobileIP binding updates 232 [16] or HIP readdressing [21] have completed). 234 The "next hop reachable" connectivity indicator only depends on 235 locally determinable information (e.g., state of directly-connected 236 links, etc.) and does not require network cooperation. It can signal 237 TCP to restart active connections across intermittently connected 238 links where disruptions occur on the first or last hop. This simple 239 indicator has the potential to improve TCP performance in many cases, 240 because connection disruptions at the first or last hop are arguably 241 the most common cause of disconnections in today's Internet. 243 A second, more general example of a connectivity indicator would be 244 "end-to-end connectivity restored." If hosts have the ability to 245 detect or be notified of connectivity changes inside the network 246 (i.e., not only at the first or last hop), a more general 247 retransmission mechanism could act on those pieces of information. 248 This can improve TCP performance across intermittently connected 249 paths where disruptions occur at arbitrary links along the path, even 250 inside the network. However, providing this more general 251 connectivity indicator is problematic due to its dependence on remote 252 information and its related issues, such as trust. 254 Connectivity indicator are generally asymmetric, i.e., they may occur 255 on one peer host but not the other. As discussed above, a local 256 event at one host may trigger the "immediate retransmission" 257 mechanism, while the other host is unable to detect this event across 258 the network. Symmetric connectivity indicators are a special case 259 and always occur concurrently at both communicating hosts. Examples 260 for such symmetric connectivity indicators are handshake events such 261 as IKE exchanges or HIP readdressing. Symmetric indicators are an 262 important special case, because the retransmission procedure required 263 in response to a symmetric indicator is simpler than that for an 264 asymmetric one. The next section will describe this in detail. 266 5. TCP Immediate Retransmission Extension 268 This section describes the main contribution of this document, i.e., 269 TCP extensions for immediate retransmission in response to 270 connectivity indicators. The basic idea behind the "immediate 271 retransmission" extension is to allow TCP to restart stalled 272 connections as soon as it receives an indicator that connectivity to 273 previously disconnected peers may have been restored. 275 This document does not specify how TCP determines which connections 276 are affected by a specific connectivity indicator, i.e., for which 277 connections it should initiate retransmission attempts. This is a 278 property of individual connectivity indicators. For example, the 279 "next hop reachable" indicator described in the previous section 280 affects connections to all destinations routed through that hop. 282 It is important to note that this retransmission extension does not 283 modify TCP's basic congestion control, fairness properties or 284 slow-start algorithms. The only difference in TCP behavior is the 285 timing of retransmission events and, in some cases, a minor, fixed 286 increase in the number of initially retransmitted segments. The 287 "immediate retransmission" extensions increases performance through 288 better utilization of connected periods, not through sending traffic 289 at a faster rate or modifying TCP's congestion control mechanisms. 291 Hosts that implement the "immediate retransmission" TCP extension 292 MUST implement the following retransmission mechanism whenever a 293 connectivity indicator is received: 295 When receiving a symmetric or asymmetric connectivity indicator, 296 conforming TCP implementations MUST immediately initiate the standard 297 retransmission procedure for connections affected by the connectivity 298 indicator - just as if the RTO for those connections had expired. 300 If the connectivity indicator is symmetric, i.e., all peers receive 301 it concurrently; this simple change is sufficient to kick-start the 302 relevant TCP connections. 304 If the connectivity indicator is asymmetric, this simple extension is 305 not always sufficient, because only one peer has received the 306 indicator. In case the host receiving the connectivity indicator has 307 no (or too little) unacknowledged data awaiting retransmission, it 308 will not emit enough segments to cause its peer node, which may have 309 unacknowledged data as well, to attempt retransmission. Transmission 310 would thus only resume in one direction, which is ineffective for 311 two-way communication. 313 To avoid this issue, conforming TCP implementation MUST perform a 314 different retransmission procedure in response to an asymmetric 315 connectivity indicator. The following sections describe two 316 alternative TCP modifications that aim to improve retransmission 317 behavior after receiving an asymmetric connectivity indicator. 318 Section 5.1 describes the first variant. As described in an earlier 319 revision of this document, this variant generates duplicate ACKs to 320 activate the peer's fast retransmit algorithm. Section 5.2 describes 321 the second variant, based on an explicit, new TCP "immediate 322 retransmission" option. 324 5.1 Variant Based on Fast Retransmit 326 This variant of improving TCP retransmission scheme based on 327 connectivity indicators uses duplicate ACKs. Conforming TCPs MUST 328 send at least four segments that all acknowledge the last segment 329 received from a peer for all connections affected by the connectivity 330 indicator. These triple-duplicate ACKs will activate the peers' fast 331 retransmit algorithms and cause them to immediately restart 332 communication in the reverse direction, i.e., before their next 333 scheduled retransmission. 335 In this variant, if a TCP connection affected by a connectivity 336 indicator has four or more unacknowledged data segments in the 337 retransmission queue, it SHOULD piggyback the triple-duplicate ACK to 338 the regular retransmissions of those data segments. In this case, 339 the "immediate retransmission" TCP extension does not require 340 additional messages, compared to standard TCP. 342 For connections where the retransmission queue contains only three or 343 less unacknowledged data segments, TCP implementations supporting the 344 "immediate retransmission" TCP extension MUST send additional pure 345 ACKs until a complete triple-duplicate ACK has been sent. In the 346 worst case, when the retransmission queue is empty, this scheme 347 requires four additional ACKs, compared to standard TCP. 349 After the peer's fast retransmit algorithm sends the assumed missing 350 segment, TCP performs either fast recovery or a slow-start [4], 351 depending on the length of the disconnection. If the connectivity 352 indicator occurs before the RTO, i.e., for very short disconnections, 353 TCP has not yet lost its ACK clock and can thus perform fast 354 recovery. After longer disconnections, TCP falls back to slow-start 355 to restart the ACK clock, just as it does at the beginning of a 356 connection. 358 The result of this modification is twofold. First, TCP connections 359 receiving the connectivity indicator attempt retransmission of their 360 unacknowledged segments before the next scheduled RTO. This 361 increases utilization of connected periods. Second, TCP connections 362 receiving the connectivity indicator use an existing TCP mechanism 363 (triple-duplicate ACK) to signal their peer. Although the peer may 364 not have received a connectivity indicator itself (e.g., the 365 indicator was asymmetric), this causes it to attempt faster 366 retransmission as well. 368 As mentioned above, the "immediate retransmission" scheme can 369 generate up to four additional segments, compared to standard TCP. 370 All additional segments are pure ACKs and hence small, resulting in a 371 minor total overhead. Furthermore, measurements have shown that 372 increasing TCP's initial window is not problematic [22]; this may 373 indicate that a minor increase in traffic at retransmission time may 374 be tolerable as well. 376 5.2 Variant Based on Retransmission Option 378 Unlike the mechanism described in the previous section, the second 379 variant described in this section does not overload an existing TCP 380 mechanism - i.e., fast retransmit - to improve retransmission after a 381 disconnection. Generating duplicate ACKs in the manner described in 382 Section 5.1 was criticized by some working group participants as an 383 abuse of a well-defined TCP mechanism for an unrelated purpose. 385 The variant described in this section uses a newly defined TCP 386 "Immediate Retransmission" Option to explicitly signal the remote 387 peer to activate its fast retransmit algorithm instead of generating 388 duplicate ACKS. It was suggested by Kacheong Poon [23]. 390 In this variant, conforming TCP implementations MUST send a single 391 segment to each peer affected by a connectivity indicator. This 392 segment will contain the TCP Immediate Retransmission Option and may 393 either be a retransmission or a pure ACK if the connection has no 394 data awaiting retransmission. Upon reception of such an option, 395 conforming TCPs MUST immediately initiate their fast retransmit 396 algorithm. 398 The TCP Immediate Retransmission Option could be a single-byte 399 option. Use of this option MUST be negotiated during the SYN 400 handshake in the usual way. [Comment.2] 402 One major drawback of this variant compared to the one described in 403 Section 5.1 is that it requires both communicating TCPs to implement 404 this modification. Triggering a peer's fast retransmit with 405 duplicate ACKs only requires the triggering local peer to support 406 this extension - the triggered remote peer may run an unmodified TCP 407 stack. Additionally, firewalls may block segments carrying unknown 408 TCP options. Finally, TCP option space is becoming limited. 410 6. Related Work 412 Several other approaches try to improve TCP performance in the 413 presence of connectivity disruptions [11][12][13]. They attempt to 414 improve TCP startup after a disconnection by retransmitting buffered 415 or newly-crafted segments from inside the network. 417 These proposals can be problematic, because TCP is built on the 418 assumption that segments older than the maximum segment lifetime 419 (MSL) of 2 minutes [1] will never be received. When a disconnection 420 lasts longer than the MSL, these proposals will either become 421 ineffective or risk leaking buffered old segments onto new 422 connections, violating TCP's semantics. 424 The "immediate retransmission" modification also improves performance 425 over a path with frequent disconnections. The basic idea is to 426 schedule an additional, speculative retransmission attempt when a TCP 427 implementation receives an indication that connectivity to a peer 428 node has been restored. Unlike the other proposals, the "immediate 429 retransmission" scheme uses regular retransmissions, i.e., 430 retransmits data that is buffered at the end systems. Because that 431 data has not entered the network yet, it is not subject to the 432 problematic MSL rule. Consequently, the "immediate retransmission" 433 scheme remains effective even for disconnections longer than the MSL, 434 without the risk of compromising connection integrity. 436 Other transport-layer approaches such as the Explicit Link Failure 437 Notification [24] or TCP-F [25] use specific messages generated by 438 intermediate routers to inform TCP senders about disrupted paths. 439 The former extends the TCP state machine with a new "stand by" state 440 during which the standard retransmission timers are disabled. In 441 this state, TCP periodically probes the network to detect 442 connectivity reestablishment. Depending on the frequency of the 443 probes and the network environment, this can cause significant 444 amounts of extra traffic. TCP-F completely suspends ongoing 445 connections until receiving "route reestablishment notifications" 446 that indicate peer reachability. Both proposals are primarily 447 designed for ad hoc networks and rely on changes to intermediate 448 routers, whereas the "immediate retransmission" extension only 449 requires end system support. 451 ATCP [26] uses a similar approach as the Explicit Link Failure 452 Notification, but discovers link failures through ICMP Destination 453 Unreachable messages. Caceres and Iftode [27] propose and evaluate a 454 solution similar to the TCP "immediate" retransmission extension that 455 improves performance during MobileIP handoffs. Unlike the solution 456 proposed in this paper, the handoff mechanism is targeted at 457 disconnections of a few seconds. 459 7. Security Considerations 461 To protect against abuse of the TCP "immediate retransmission" 462 extension, e.g., denial-of-service attacks by flooding TCP with 463 connectivity indicators, a control mechanism that "rate-limits" these 464 indicators may be effective. This document does not currently 465 discuss the security aspects of connectivity indicators and the 466 "immediate retransmission" extension to TCP. 468 8. Conclusion 470 This document described the "immediate retransmission" extension to 471 TCP's standard retransmission scheme. The new extension improves 472 performance across intermittently connected paths through additional, 473 speculative retransmission attempts upon receiving external 474 connectivity indicators. One example of such a connectivity 475 indicator is "first hop router reachable." This document did not 476 define the specifics of such connectivity indicators, although it 477 described some examples to illustrate the operation of the "immediate 478 retransmission" extension, which is its main contribution. 480 9. IANA Considerations 482 This section is to be interpreted according to [5]. 484 This document does not define any new namespaces. It uses an 8-bit 485 TCP option number maintained by IANA at 486 http://www.iana.org/assignments/tcp-parameters. 488 10. Acknowledgments 490 The following people have helped to improve this document through 491 thoughtful suggestions and feedback: Marcus Brunner, Kacheong Poon, 492 Juergen Quittek and Joe Touch. 494 Part of this work is a product of the Ambient Networks project, 495 partially supported by the European Commission under its Sixth 496 Framework Programme. It is provided "as is" and without any express 497 or implied warranties, including, without limitation, the implied 498 warranties of fitness for a particular purpose. The views and 499 conclusions contained herein are those of the authors and should not 500 be interpreted as necessarily representing the official policies or 501 endorsements, either expressed or implied, of the Ambient Networks 502 project or the European Commission. 504 11. References 505 11.1 Normative References 507 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 508 September 1981. 510 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 511 Levels", BCP 14, RFC 2119, March 1997. 513 [3] Paxson, V. and M. Allman, "Computing TCP's Retransmission 514 Timer", RFC 2988, November 2000. 516 [4] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", 517 RFC 2581, April 1999. 519 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 520 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 522 [6] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 524 11.2 Informative References 526 [7] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", 527 Addison-Wesley , 1994. 529 [8] Eggert, L., "TCP Abort Timeout Option", 530 draft-eggert-tcpm-tcp-abort-timeout-option-01 (work in 531 progress), July 2004. 533 [9] Schuetz, S., "Network Support for Intermittently Connected 534 Mobile Nodes", M.S. Thesis, University of Mannheim, Germany, 535 June 2004. 537 [10] Schuetz, S., Eggert, L., Schmid, S. and M. Brunner, "Protocol 538 Enhancements for Intermittently Connected Hosts", under 539 submission (work in progress), July 2004. 541 [11] Scott, J. and G. Mapp, "Link layer-based TCP optimisation for 542 disconnecting networks", ACM Computer Communication Review, 543 Vol. 33, No. 5, October 2003. 545 [12] Dawkins, S., "End-to-end, Implicit 'Link-Up' Notification", 546 draft-dawkins-trigtran-linkup-01 (work in progress), October 547 2003. 549 [13] Karn, P., "Advice for Internet Subnetwork Designers", 550 draft-ietf-pilc-link-design-15 (work in progress), December 551 2003. 553 [14] Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE 802.11b for 554 Automobile Users", Proc. INFOCOM 2004, March 2004. 556 [15] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 557 March 1997. 559 [16] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 560 IPv6", RFC 3775, June 2004. 562 [17] Moskowitz, R., "Host Identity Protocol Architecture", 563 draft-moskowitz-hip-arch-06 (work in progress), June 2004. 565 [18] Choi, J., "Detecting Network Attachment in IPv6 Goals", 566 draft-ietf-dna-goals-00 (work in progress), June 2004. 568 [19] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 569 Specification", RFC 2460, December 1998. 571 [20] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 572 RFC 2409, November 1998. 574 [21] Nikander, P., "End-Host Mobility and Multi-Homing with Host 575 Identity Protocol", draft-nikander-hip-mm-02 (work in 576 progress), July 2004. 578 [22] Allman, M., Hayes, C. and S. Ostermann, "An Evaluation of TCP 579 with Larger Initial Windows.", ACM Computer Communication 580 Review, Vol. 28, No. 3, July 1998. 582 [23] Poon, K., "Personal Communication", August 2004. 584 [24] Holland, G. and N. Vaidya, "Analysis of TCP Performance over 585 Mobile Ad Hoc Networks", Proc. 5th Annual ACM/IEEE 586 International Conference on Mobile Computing and Networking, 587 1999. 589 [25] Chandran, K., Raghunathan, S., Venkatesan, S. and R. Prakash, 590 "A Feedback Based Scheme For Improving TCP Performance In 591 Ad-Hoc Wireless Networks", IEEE Personal Communication Systems 592 (PCS) Magazine: Special Issue on Ad Hoc Networks, Vol. 8, No. 593 1, February 2001. 595 [26] Liu, J. and S. Singh, "ATCP: TCP for Mobile Ad Hoc Networks", 596 IEEE Journal on Selected Areas in Communication, Vol. 19, No. 597 7, July 2001. 599 [27] Caceres, R. and L. Iftode, "Improving the Performance of 600 Reliable Transport Protocols in Mobile Computing Environments", 601 IEEE Journal on Selected Areas in Communication, Vol. 13, No. 602 5, 1995. 604 Editorial Comments 606 [Comment.1] LE: The authors have seen the idea of triggering 607 retransmits based on connectivity events of 608 directly-connected links attributed to Phil Karn, but 609 were unable to locate a specific reference. Pointers are 610 highly appreciated. 612 [Comment.2] LE: If this variant is seen as superior, the details of 613 the negotiation must be described here. 615 Authors' Addresses 617 Lars Eggert 618 NEC Network Laboratories 619 Kurfuerstenanlage 36 620 Heidelberg 69115 621 Germany 623 Phone: +49 6221 90511 43 624 Fax: +49 6221 90511 55 625 EMail: lars.eggert@netlab.nec.de 626 URI: http://www.netlab.nec.de/ 628 Simon Schuetz 629 NEC Network Laboratories 630 Kurfuerstenanlage 36 631 Heidelberg 69115 632 Germany 634 Phone: +49 6221 90511 10 635 Fax: +49 6221 90511 55 636 EMail: simon.schuetz@netlab.nec.de 637 URI: http://www.netlab.nec.de/ 638 Stefan Schmid 639 NEC Network Laboratories 640 Kurfuerstenanlage 36 641 Heidelberg 69115 642 Germany 644 Phone: +49 6221 90511 54 645 Fax: +49 6221 90511 55 646 EMail: stefan.schmid@netlab.nec.de 647 URI: http://www.netlab.nec.de/ 649 Appendix A. Document Revision History 651 +-----------+-------------------------------------------------------+ 652 | Revision | Comments | 653 +-----------+-------------------------------------------------------+ 654 | 00 | Initial version. | 655 | 01 | Updated terminology according to [10]. Added | 656 | | "retransmission option" variant as Section 5.2. | 657 +-----------+-------------------------------------------------------+ 659 Intellectual Property Statement 661 The IETF takes no position regarding the validity or scope of any 662 Intellectual Property Rights or other rights that might be claimed to 663 pertain to the implementation or use of the technology described in 664 this document or the extent to which any license under such rights 665 might or might not be available; nor does it represent that it has 666 made any independent effort to identify any such rights. Information 667 on the procedures with respect to rights in RFC documents can be 668 found in BCP 78 and BCP 79. 670 Copies of IPR disclosures made to the IETF Secretariat and any 671 assurances of licenses to be made available, or the result of an 672 attempt made to obtain a general license or permission for the use of 673 such proprietary rights by implementers or users of this 674 specification can be obtained from the IETF on-line IPR repository at 675 http://www.ietf.org/ipr. 677 The IETF invites any interested party to bring to its attention any 678 copyrights, patents or patent applications, or other proprietary 679 rights that may cover technology that may be required to implement 680 this standard. Please address the information to the IETF at 681 ietf-ipr@ietf.org. 683 Disclaimer of Validity 685 This document and the information contained herein are provided on an 686 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 687 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 688 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 689 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 690 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 691 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 693 Copyright Statement 695 Copyright (C) The Internet Society (2004). This document is subject 696 to the rights, licenses and restrictions contained in BCP 78, and 697 except as set forth therein, the authors retain all their rights. 699 Acknowledgment 701 Funding for the RFC Editor function is currently provided by the 702 Internet Society.