idnits 2.17.1 draft-zimmermann-tcp-lcd-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 28, 2009) is 5566 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Zimmermann 3 Internet-Draft A. Hannemann 4 Intended status: Experimental RWTH Aachen University 5 Expires: August 1, 2009 January 28, 2009 7 Make TCP more Robust to Long Connectivity Disruptions 8 draft-zimmermann-tcp-lcd-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 1, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 TCP was designed with fixed, wired networks in mind. As a result TCP 48 performs suboptimal in networks where connectivity disruptions are 49 frequent, e.g., in wireless (multi-hop) networks. One reason for the 50 performance degradation is TCP's over-conservative behavior in face 51 of long connectivity disruptions. 53 This document describes how connectivity disruption indications 54 provided by standard ICMP messages may be exploited to improve TCP's 55 performance. An RTO revert strategy is proposed that enables earlier 56 detection of whether connectivity to a previously disconnected peer 57 node has been restored or not. The scheme is a sender only 58 modification which fully respects the TCP congestion control 59 principles. 61 1. Terminology 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 The term "acceptable acknowledgment (ACK)" in this document refers to 68 a TCP segment that acknowledges previously unacknowledged data (as 69 defined in [RFC0793]). The Transmission Control Protocol (TCP) 70 sender state variable "SND.UNA" and the current segment variable 71 "SEG.SEQ" are used as defined in [RFC0793]. SND.UNA holds the 72 segment sequence number of the oldest outstanding segment. SEG.SEQ 73 is the segment sequence number of a given segment. 75 2. Introduction 77 Connectivity disruptions can occur in many different situation. The 78 frequency of the connectivity disruptions depend thereby on the 79 property of the end-to-end path between the communicating hosts. 80 While connectivity disruptions can occur in traditional wired 81 networks too, e.g., simply due to an unplugged network cable, the 82 likelihood of occurrence is significant higher in wireless (multi- 83 hop) networks. Especially, end-host mobility and wireless 84 interferences are crucial factors. In the case the hosts use the 85 Transmission Control Protocol (TCP) [RFC0793] for their 86 communication, the performance of the connection can exhibit a 87 significant reduction compared to a permanently connected path 88 [SESB05]. 90 According to Schuetz et. al. [I-D.schuetz-tcpm-tcp-rlci] 91 connectivity disruptions can be classified into two groups: "short" 92 and "long" connectivity disruptions. A connectivity disruption is 93 short if connectivity returns before the retransmission timeout (RTO) 94 fires for the first time. In this case, TCP recovers lost data 95 segments through Fast Retransmit and lost ACKs through successfully 96 delivered later ACKs. Connectivity disruptions are declared as long 97 for a given TCP connection, if the RTO fires at least once before 98 connectivity returns. Whether or not path characteristics have 99 changed when the connectivity returns after a disruption is second 100 important aspect for TCP's retransmission scheme 101 [I-D.schuetz-tcpm-tcp-rlci]. 103 This memo will focus on TCP's behavior in face of long connectivity 104 disruptions in the time "before" connectivity is restored. Moreover, 105 this document does not describe any additional optimization to detect 106 if the path characteristics remain unchanged. Therefore, TCP's RTO 107 based Loss Recovery and in particular Slow-Start [RFC2581] will be 108 unchanged. 110 When a long connectivity disruption occurs on path between two 111 communicating hosts, the TCP sender stops receiving ACKs. After 112 expiration of the RTO the TCP sender will repeatedly retransmit the 113 first unacknowledged segment (SND.UNA) until it is successfully 114 acknowledged. TCP implementations that follow the recommended RTO 115 management proposed in RFC 2988 [RFC2988] double the RTO value after 116 each retransmission attempt. However, the RTO growth may be bounded 117 by an upper limit maximum RTO, which is at least 60s, but may be 118 longer: Linux for example uses 120s. If the connectivity is restored 119 between two retransmission attempts, a TCP still have to wait until 120 the RTO expires before resuming transmission, since TCP simply does 121 not have any means to know that the connectivity is re-established. 122 Therefore, depending on when connectivity becomes available again, 123 this can waste up to maximum RTO of possible transmission time. 125 This retransmission behavior is not efficient, especially in 126 scenarios or networks like wireless (multi-hop) networks where 127 connectivity disruptions are frequent. In the ideal case, TCP would 128 attempt a retransmission as soon as connectivity to its peer was re- 129 established. In this document a method how the standard Internet 130 Control Message Protocol (ICMP) can be exploited to improve TCP's 131 performance is described. The presented scheme is a sender only 132 modification, i.e., neither intermediate routers nor the TCP receiver 133 have to be modified. Furthermore, the proposed modification 134 approaches the ideal behavior, if the network allows for it (i.e., no 135 congestion is present). By an RTO revert strategy, higher-frequency 136 retransmissions can be realized to enable earlier detection of 137 whether connectivity to a previously disconnected peer node has been 138 restored. 140 3. Connectivity Disruption Indication 142 As long as the queue of a router experiencing a link outage is deep 143 enough, i.e., it can buffer all incoming packets, a connectivity 144 disruption will only cause variation in delay which is handled well 145 by a contemporary TCP with the help of Eifel [RFC3522] or forward RTO 146 (F-RTO) [RFC4138]. However, if the link outage lasts too long, the 147 router experiencing the link outage is forced to drop packets and 148 finally to discard the according route. Means to detect such link 149 outages comprise reacting on failed address resolution protocol (ARP) 150 queries, unsuccessful link sensing, and the like. However, this is 151 solely in the responsibility of the respective router. 153 Note: The focus of this memo is on introducing a method how ICMP 154 messages may be exploited to improve TCP's performance; how 155 different physical-and link layer mechanisms underneath the 156 network layer may trigger ICMP destination unreachable messages 157 are out of scope of this memo. 159 The removal of the route usually goes along with a notification to 160 the corresponding TCP source about the dropped packets via ICMP 161 destination unreachable messages of code 0 (net unreachable) or code 162 1 (host unreachable) [RFC1812]. Therefore, since ICMP destination 163 unreachable messages of these codes are evidence that packets were 164 dropped due to a link outage, they can be interpreted as a 165 connectivity disruption indication. 167 Note that there are also other ICMP destination unreachable messages 168 with different codes. Some of them are candidates for connectivity 169 disruption indications too, but need further investigation. For 170 example ICMP destination unreachable messages with code 5 (source 171 route failed), code 11 (net unreachable for TOS), or code 12 (host 172 unreachable for TOS). On the other side codes that flag hard errors 173 [RFC1122] are of no use for the proposed scheme. In the following, 174 the term "ICMP unreachable message" is used as synonym for ICMP 175 destination unreachable messages of code 0 or code 1. 177 A router experiencing a link outage is an obvious candidate for being 178 heavily congested because it is not just unable to forward packets 179 fast enough, it is even unable to forward packets at all. Therefore, 180 TCP's exponential back-off may seem appropriate. However, taking 181 into account the congestion control principles [RFC2914], i.e., 182 congestion is indicated by packet loss, receiving an ICMP unreachable 183 message might be an indication that there is no congestion. For 184 instance, when a (re-)transmission is replied to with an ICMP 185 unreachable message, this is a strong indication that there is no 186 congestion in the network - at least on that very part of the path 187 which was traveled by both, the TCP segment eliciting the ICMP 188 unreachable message as well as the ICMP unreachable message itself. 189 Therefore, it seems a little bit harsh for TCP to back-off as if 190 there was true congestion. 192 The accurate interpretation of ICMP unreachable messages as an 193 connectivity disruption indication is complicated by the following 194 two peculiarities of ICMP messages. Firstly, they do not necessarily 195 operate on the same timescale as the packets, i.e., in the given case 196 TCP segments, which elicited them. When a router drops a packet due 197 to a missing route it will not necessarily send an ICMP unreachable 198 message immediately, but rather queues it for later delivery. 199 Secondly, ICMP messages are subject to rate limiting, e.g., when a 200 router drops a whole window of data due to a link outage, it will 201 hardly send as many ICMP unreachable messages as it dropped TCP 202 segments. Depending on the load of the router it may even send no 203 ICMP unreachable messages at all. Both peculiarities originate from 204 RFC 1812 [RFC1812]. 206 Fortunately, according to RFC 792 [RFC0792] ICMP unreachable messages 207 are obliged to contain in their body the Internet Protocol (IP) 208 header of the datagram eliciting the ICMP unreachable messages plus 209 the first 64 bits of the payload of that datagram, i.e., in case of a 210 TCP segment both port numbers and the sequence number. This allows 211 the originating TCP to identify the connection which an ICMP 212 unreachable message is reporting an error about. Moreover, it allows 213 the originating TCP to identify which segment of the respective 214 connection triggered the ICMP unreachable message, provided that 215 there are not several segments in flight with the same sequence 216 number. This may very well be the case when TCP is recovering lost 217 segments. 219 4. Connectivity Disruption Reaction 221 The complete algorithm is specified in Section 4.1. In section 222 Section 4.2, the different steps of the algorithm are discussed in 223 detail. 225 4.1. The Algorithm 227 The following scheme MAY be used by a TCP sender to avoid over- 228 conservative back-offs of the retransmission timer in the case of 229 long connectivity disruptions: 231 (1) Set a "UndoBackOff" variable to UNPROVED (equal 0) 233 UndoBackOff := UNPROVED. 235 (2) Wait for the expiration the retransmission timer, proceed to 236 step (RTO). 238 (3) Wait either 240 for the arrival of an acceptable ACK. When an acceptable ACK 241 has arrived, proceed to step (ACK), 243 or for the arrival of an ICMP destination unreachable 244 message. When ICMP destination unreachable message has 245 arrived, proceed to step (4), 247 or for the expiration the retransmission timer, proceed to 248 step (RTO). 250 (4) Extract the TCP segment header included in the ICMP destination 251 unreachable message 253 SEG := Extract(ICMP_MSG). 255 (5) If "SEG.SEQ == SND.UNA", i.e., ICMP unreachable message reports 256 on a retransmission, then 258 If "UndoBackOff == UNPROVED", then set the "UndoBackOff" 259 variable to PROVED (equal 1) 261 UndoBackOff := PROVED. 263 else revert one RTO back-off 265 RTO := max(MINIMUM_RTO, RTO / 2). 267 (6) Proceed to step (3). 269 (RTO) This is a placeholder for the standard TCP behavior that must 270 be executed at this point in the case the retransmission timer 271 is expired. Proceed to step (3). 273 (ACK) This is a placeholder for the standard TCP behavior that must 274 be executed at this point in the case an acceptable ACK is 275 arrived. Proceed to step (1). 277 4.2. The Algorithm in Detail 279 When an RTO expires a TCP marks all outstanding segments as lost, 280 sets the congestion window (CWND) to one segment, back-offs the RTO, 281 and retransmits the first unacknowledged segment SND.UNA (step 2). 282 If the RTO expires again a TCP will repeat the retransmission of the 283 first unacknowledged segment and back-off again (step 3c). This 284 pattern will be repeated as long as no packet arrives or until the 285 maximum RTO expired. 287 If the first received packet after the retransmission(s) is an 288 acceptable ACK (step 3a), a TCP will proceed as normal, i.e., slow- 289 start the connection. It ignores later ICMP unreachable messages 290 from the window of data which experienced RTO. Late ICMP unreachable 291 messages are of no use as the ACK clock is already restarting due to 292 the successful retransmission. 294 On the other side if the first received packet after the 295 retransmission(s) is an ICMP unreachable message, a TCP SHOULD revert 296 one back-off for each ICMP unreachable message reporting an error on 297 a retransmission. To decide if an ICMP unreachable message reports 298 on a retransmission, the sequence number therein is exploited (step 299 4, step 5). 301 Nevertheless, the first unacknowledged sequence number is suffering 302 from the ambiguity if it refers to the original transmission or to 303 any of the retransmissions. To be conservative, it should be 304 considered to belong to the original transmission (step 5a). 305 However, for each next ICMP unreachable message reporting on the 306 retransmission, TCP SHOULD revert one back-off (step 5b). 308 Upon receipt of an ICMP unreachable message which legitimately 309 reverts one back-off there is the possibility that this new RTO has 310 expired already. Then, a TCP SHOULD retransmit immediately, i.e., an 311 ICMP message clocked retransmission. In case the new RTO has not 312 expired yet, TCP MUST wait accordingly. 314 5. Discussion 316 Apart from the possibility to receive ICMP unreachable messages 317 reporting on the sequence number of the retransmission, there might 318 as well arrive ICMP unreachable messages reporting on the original 319 window of data while a TCP is in RTO induced recovery. As TCP cannot 320 decide by a single or a few ICMP unreachable messages if the whole 321 window of data was dropped because of a link outage, there is the 322 option that at least one of the segments was dropped due to true 323 congestion in the network, calling for back-off. Therefore, to be 324 conservative, a TCP MUST NOT revert the back-off in such a case (step 325 5a). Although, there is still the unlikely possibility that the 326 intermediate router indeed sends an ICMP unreachable message for each 327 dropped segment. Then, TCP should be allowed to even revert the 328 first back-off. However, as this case is very unlikely and requires 329 one more state variable to detect it is not recommended in this 330 document. 332 Besides the ambiguity if the first unacknowledged sequence number 333 refers to the original transmission or to any of the retransmissions, 334 there is another source of ambiguity about the sequence numbers 335 contained in the ICMP unreachable messages. For high bandwidth paths 336 like modern gigabit links the sequence space may wrap rather quickly, 337 thereby allowing the possibility that a late ICMP unreachable message 338 reporting on an old error may coincidentally fit as input in the 339 scheme explained above. As a result, the scheme would wrongly revert 340 one back-off. However, chances for this to happen are minuscule. 341 Moreover, as the scheme is tailored most conservatively no threat to 342 the network from this issues may arise. 344 Finally, the scheme explicitly does not call for a differentiation of 345 ICMP unreachable messages originating from different routers, as the 346 evidence of no congestion still holds even if the reporting router 347 changed. 349 Another exploitation of ICMP unreachable messages in the context of 350 TCP congestion control might seem appropriate in case the ICMP 351 unreachable message is received while TCP is in steady-state and the 352 message refers to a segment from within the current window of data. 353 As the round trip time (RTT) up to the router which generates the 354 ICMP unreachable message is likely to be substantially shorter than 355 the overall RTT to the destination, the ICMP unreachable message may 356 very well reach the originating TCP while it is transmitting the 357 current window of data. In case the remaining window is large, it 358 might seem appropriate to refrain from transmitting the remaining 359 window as there is timely evidence that it will only trigger further 360 ICMP unreachable messages at the very router. Although this might 361 seem appropriate from a wastage perspective, it may be 362 counterproductive from a security perspective since ICMP messages are 363 easy to spoof, thereby allowing an easy attack to the TCP by simply 364 forging such ICMP messages. 366 An additional consideration is the following: in the presence of 367 multi-path routing even the receipt of a legitimate ICMP unreachable 368 message cannot be exploited accurately because there is the option 369 that only one of the multiple paths to the destination is suffering 370 from a connectivity disruption which causes ICMP unreachable messages 371 to be sent. Then however, there is the possibility that the path 372 along which the connectivity disruption occurred contributed 373 considerably to the overall bandwidth, such that a congestion 374 response is very well reasonable. However, this is not necessarily 375 the case. Therefore, a TCP has no means except for its inherent 376 congestion control to decide on this matter. All in all, it seems 377 that for a connection in steady-state, i.e., not in RTO induced 378 recovery, reacting on ICMP unreachable messages in regard to 379 congestion control is not appropriate. For the case of RTO-based 380 retransmissions, however, there is a reasonable congestion response, 381 which is skipping further back-off of the RTO because there is no 382 congestion indication - as described above. 384 6. Related Work 386 In literature there are several methods, which address TCP's problems 387 in the presence of connectivity disruptions. Some of them try to 388 improve TCP's performance by modifying the lower layers. For example 389 [SM03] introduces a "smart link layer" that buffers one segment for 390 each ongoing connection and replaying these segments on connectivity 391 reestablishment. This approach has a serious drawback: previously 392 state-less intermediate routers have to be modified in order to 393 inspect TCP headers, track the end-to-end connection and to provide 394 additional buffer space that lead all in all to an additional need of 395 memory and processing power. 397 On the other hand stateless link layer schemes, like proposed in 398 RFC 3819 [RFC3819], which unconditionally buffer some small number of 399 packets may have another problem: if a packet is buffered longer than 400 the maximum segment lifetime (MSL) of [RFC0793] 2 min, i.e., the 401 disconnection lasts longer than MSL, TCP's assumption that such 402 segments will never be received will no longer be true, violating 403 TCP's semantics [I-D.eggert-tcpm-tcp-retransmit-now]. 405 Other approaches like TCP-F [CRVP01] or the Explicit Link Failure 406 Notification (ELFN) [HV02] inform the TCP senders about disrupted 407 paths by special messages generated from intermediate routers. In 408 case of a link failure they stop sending data segments and freeze 409 TCP's retransmission timers. TCP-F stays in this state and remains 410 silent until either a "route establishment notification" is received 411 or an internal timer expires. In contrast, ELFN periodically probes 412 the network to detect connectivity reestablishment. Both proposals 413 rely on changes to intermediate routers, whereas the scheme proposed 414 in this memo is a sender only modification. Moreover, ELFN also does 415 not consider congestion in the network and may impose serious 416 additional load on the network, depending on the probe interval. 418 The authors of ATCP [LS01] propose enhancements to identify different 419 types of packet loss, by introducing a layer between TCP and IP. 420 They utilize ICMP destination unreachable messages to set TCP's 421 receiver advertised window to zero and thus forcing the TCP sender to 422 do zero window probing with exponential back-off. ICMP destination 423 unreachable messages, which arrive during this probing period, are 424 ignored. This approach is nearly orthogonal to this memo, which 425 exploits ICMP messages to revert a RTO back-off, when TCP is already 426 probing. In principle both mechanisms could be combined, however, 427 due to security considerations it does not seem appropriate to adopt 428 ATCP's reaction as discussed in Section 5. 430 Schuetz et al. describe in [I-D.schuetz-tcpm-tcp-rlci] a set of TCP 431 extensions that improve behavior when transmitting over paths whose 432 characteristics can change on short time-scales. Their proposed TCP 433 extensions modify the local behavior of TCP and introduce a new TCP 434 option to signal locally received connectivity-change indications 435 (CCIs) to remote peers. Upon reception of a CCI, they re-probe the 436 path characteristics either by performing a speculative 437 retransmission or by sending a single segment of new data, depending 438 on whether the connection is currently in the loss state or 439 transmitting in steady-state, respectively. The authors focus on 440 specifying TCP response mechanisms, nevertheless underlying layers 441 would have to be modified to explicitly send CCIs to make these 442 immediate responses possible. 444 7. IANA Considerations 446 This memo includes no request to IANA. 448 8. Security Considerations 450 The proposed mechanism is considered to be secure. For example an 451 attacker cannot make a TCP modified with proposed scheme flood the 452 network just by sending forged ICMP unreachable messages reverting 453 RTO back-offs. Even in the case the attacker could correctly guess 454 the sequence number of the current retransmitted segment, the 455 retransmission frequency is limited by the minimum value for the RTO 456 of 1s specified by RFC 2988 [RFC2988]. 458 9. References 460 9.1. Normative References 462 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 463 RFC 792, September 1981. 465 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 466 RFC 793, September 1981. 468 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 469 RFC 1812, June 1995. 471 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 472 Control", RFC 2581, April 1999. 474 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 475 Timer", RFC 2988, November 2000. 477 9.2. Informative References 479 [CRVP01] Chandran, K., Raghunathan, S., Venkatesan, S., and R. 480 Prakash, "A feedback-based scheme for improving TCP 481 performance in ad hoc wireless networks", IEEE Personal 482 Communications vol. 8, no. 1, pp. 34-39, February 2001. 484 [HV02] Holland, G. and N. Vaidya, "Analysis of TCP performance 485 over mobile ad hoc networks", Wireless Networks vol. 8, 486 no. 2-3, pp. 275-288, March 2002. 488 [I-D.eggert-tcpm-tcp-retransmit-now] 489 Eggert, L., "TCP Extensions for Immediate 490 Retransmissions", draft-eggert-tcpm-tcp-retransmit-now-02 491 (work in progress), June 2005. 493 [I-D.schuetz-tcpm-tcp-rlci] 494 Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami, 495 Y., and K. Le, "TCP Response to Lower-Layer Connectivity- 496 Change Indications", draft-schuetz-tcpm-tcp-rlci-03 (work 497 in progress), February 2008. 499 [LS01] Liu, J. and S. Singh, "ATCP: TCP for mobile ad hoc 500 networks", IEEE Journal on Selected Areas in 501 Communications vol. 19, no. 7, pp. 1300-1315, 2001 July. 503 [RFC1122] Braden, R., "Requirements for Internet Hosts - 504 Communication Layers", STD 3, RFC 1122, October 1989. 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 510 RFC 2914, September 2000. 512 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 513 for TCP", RFC 3522, April 2003. 515 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 516 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 517 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 518 RFC 3819, July 2004. 520 [RFC4138] Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO): 521 An Algorithm for Detecting Spurious Retransmission 522 Timeouts with TCP and the Stream Control Transmission 523 Protocol (SCTP)", RFC 4138, August 2005. 525 [SESB05] Schuetz, S., Eggert, L., Schmid, S., and M. Brunner, 526 "Protocol enhancements for intermittently connected 527 hosts", SIGCOMM Computer Communication Review vol. 35, no. 528 3, pp. 5-18, December 2005. 530 [SM03] Scott, J. and G. Mapp, "Link layer-based TCP optimisation 531 for disconnecting networks", SIGCOMM Computer 532 Communication Review vol. 33, no. 5, pp. 31-42, 533 October 2003. 535 Authors' Addresses 537 Alexander Zimmermann 538 RWTH Aachen University 539 Ahornstrasse 55 540 Aachen, 52074 541 Germany 543 Phone: +49 241 80 21422 544 Email: zimmermann@cs.rwth-aachen.de 546 Arnd Hannemann 547 RWTH Aachen University 548 Ahornstrasse 55 549 Aachen, 52074 550 Germany 552 Phone: +49 241 80 21423 553 Email: hannemann@nets.rwth-aachen.de