Submitted to the PILC working group V. Magret Internet Engineering Task Force M. Yang INTERNET DRAFT Alcatel July 1, 2000 Long-lived TCP connections draft-magret-pilc-lltcp-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an individual submission to the Internet Engineering Task Force (IETF). Comments should be submitted to the authors. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract Magret Expires January 1, 2001 [Page 1] INTERNET DRAFT Long-lived TCP connections July 1, 2000 This document specifies a protocol enhancement allowing TCP connec- tions to switch from an active state to an idle state during a wire- less link's outage. Within such state all timers are cancelled and packets' transmission is suspended. The protocol defines a mechanism by which the mobile station may detect a link failure and changes TCP connections' state to idle. This same mechanism allows the mobile host to detect connectivity regain. All TCP connections are then resumed. The protocol defines how the supervisor host, which can monitor the wireless link quality, can alert the fixed host of a failure of the wireless link. The fixed host can suspend the outgoing activity with the unreachable mobile node. When the fixed hosts start receiving packets from the mobile node, the activity can be resumed. This protocol increases the capacity of both parties involved in a communication that is carried via a wireless link to handled connec- tivity disruption without impacting the overall performance of the TCP connections. Magret Expires January 1, 2001 [Page 2] INTERNET DRAFT Long-lived TCP connections July 1, 2000 Table of Contents 1. Introduction ................................................ 3 2. Conventions ................................................. 3 3. Protocol overview ........................................... 5 3.1. Probing the presence of the supervisor host ............... 5 3.2. Wireless link failure notification ........................ 6 4. The mobile host behavior .................................... 7 4.1. Underlying layer event not available ...................... 7 4.2. Underlying layer event available .......................... 9 5. The supervisor host ......................................... 9 5.1. Underlying layer event not available ...................... 9 5.2. Underlying layer event available .......................... 11 6. The fixed host behavior ..................................... 11 7. Protocol description ........................................ 12 7.1. ICMP suspend message ...................................... 12 7.2. ICMP probe message ........................................ 13 8. Security considerations ..................................... 13 9. References .................................................. 14 Authors' addresses ............................................. 15 Magret Expires January 1, 2001 [Page 3] INTERNET DRAFT Long-lived TCP connections July 1, 2000 1. Introduction The development of portable devices in the recent years had made mobile computiung more and more popular. Through a wireless network (e.g. cellular network), a user is able to access the services pro- vided by the Internet (e.g. E-mail, WWW) "anywhere, anytime". But a mobile user may experience temporary disconnection frequently due to user mobility and the deficiencies of wireless communication. A tem- porary disconnection may cause a serious performance drop on data communication or, even worse, the termination of the communication. Since the problem of frequent disconnection can hardly be avoided in wireless mobile communication, the only way we can do is trying to reduce the effect of this problem on wireless communications. The transmission control protocol [RFC793] [RFC1122] is a standard, connection oriented transport protocol widely used in the Internet. TCP provides reliable end-to-end data transmission on wired, fixed networks, but it does not provide optimal support in wireless environment. By adding the capability of mobility-awareness to TCP, we are able to provide an answer to the problem of frequent discon- nection. The Long-lived TCP (or LL-TCP) protocol is a "mobility aware" TCP that provides a long-lived connection support with suspend-resume operations. This protocol is proposed to mitigate the effect of fre- quent disconnections on the performance of TCP connections involving a mobile device. This document defines extension to the ICMP protocol [RFC792] in order to support the new feature. 2. Convention The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The following terms are defined: 1. The mobile host 2. The supervisor host or intermediate host is either capable of monitoring the traffic between mobile hosts and fixed host or it is a device that is somehow informed of the status of the wireless link. How events are communicate to the supervisor host is out of the scope of this document. Magret Expires January 1, 2001 [Page 4] INTERNET DRAFT Long-lived TCP connections July 1, 2000 In this document we consider the supervisor host to be the first router located after the wireless link. 3. The fixed host refers to any node addressable in the Inter- net network. 4. The wired network refers to the network located between the supervisor hosts and the various fixed hosts. We do not make any requirements on this network. 3. Protocol overview Note: Some Wireless technologies may be capable of delivering events including updates on the wireless link's status. We do recommend whenever possible usage of such mean of information as it is accurate and reliable. Although, in some cases, this liaison between the transport protocol and the underlying layer can not be achieved. The LL-TCP protocol describes both situations. The following services are defined: 3.1. Probing the presence of the supervisor host The mobile host may need a mechanism to detect any changes to the wireless link status as in some cases the underlying layer may not be able to inform the transport layer on the wireless link status' changes. The LL-TCP protocol defines a mechanism allowing a mobile host to probe the presence of the supervisor host, i.e. probe the fact that the link is up or down. When a mobile node detects a link failure, all its active TCP connections are suspended. The same mechanism allows the mobile node to detect that the wireless link is again available. In such case, all TCP connections are resumed. A mobile host SHOULD implement whenever the underlying layer cannot provide information on the wireless link status (e.g. up or down) the following mechanism. The mobile host SHOULD periodically send an ICMP probe message to test the presence of the supervisor host. The ICMP message is sent to all routers on the nework. If the mobile host does not receive a response from the supervisor host within a specified amount of time, the mobile host SHOULD suspend all TCP connections. Magret Expires January 1, 2001 [Page 5] INTERNET DRAFT Long-lived TCP connections July 1, 2000 The mobile host enters a suspended phase. During the suspended phase, the mobile host SHOULD continue probing the presence of the supervisor host. The implementation MAY define a maximum number of attempts before considering closing all suspended TCP connections. The connections can be resumed by the mobile host, when it receives an ICMP probe response from the supervisor host. The design of the protocol allows the mobile host to regain connec- tivity with another supervisor host, as a supervisor host does not hold any packet associated with any connection. When the mobile host can receive events from the underlying layer informing the transport layer about the current status of the wire- less link, the mobile host SHOULD NOT implement the previously described protocol. The mobile host SHOULD immediately suspend all its connections when informed of a connectivity problem on the wire- less link. 3.2. Wireless link failure notification The fixed host does not have any mechanism by which it is informed of the wireless link's status. The supervisor host's role is to monitor the status of the wireless link. When the underlying layer cannot informe the supervisor host of status changes of the wireless link, the supervisor must be able to monitor the TCP traffic. In both cases, when a link failure is detected, the supervisor host sends to the fixed host a message informing it of the new wireless link status. The server host is then able to suspend its activity related to all connections with the unreachable mobile node. The supervisor host's main role in the LL-TCP protocol is to inform the fixed host of the changes of the wireless link status. The super- visor host SHOULD be able to monitor the traffic between the fixed hosts and the mobile hosts when the underlying layer is not capable of informing the upper layer on the wireless link status' changes. The principle developed for the supervisor host relies on some mechanisms defined for Snoop [Snoop]. The Snoop protocol was proposed to improve the end-to-end performance on networks with wireless links without changing existing TCP implementations on hosts located on the wired network. The supervisor host (i.e. the node implementing Snoop) is be able to monitor the traffic between the fixed hosts and the mobile hosts. A Snoop module is put at the supervisor host (which Magret Expires January 1, 2001 [Page 6] INTERNET DRAFT Long-lived TCP connections July 1, 2000 could be a base station in some cases) to monitor every TCP packet sent by the fixed host to the mobile host and the acknowledgement sent by the mobile host. The Snoop module maintains a cache of unack- nowledged TCP segment sent from the fixed host and keep track of ack- nowledgement sent from the mobile host. When an acknowledgement from the mobile host is received, the acknowledged TCP segment(s) is (are) removed from the cache and the acknowledgement is forward to its final destination (i.e. the fixed host). Snoop has a local retransmission timer, much like TCP, and it does retransmissions of unacknowledged segments based on this timer. Snoop monitors also duplicate acknowledgements (DUPACKS) to offer a local retransmission that DUPACKS do not impact on the settings of the TCP connection at the fixed host. Snoop also defines a persist timer, that triggers a retransmission when there are unacknowledged TCP segments present in the cache and the Snoop module has not seen any activity (in both directions) during this period. The Long-lived protocol, if implemented along with Snoop, suppresses Snoop's persist timer and introduces a suspension timer. This suspen- sion timer triggers the suspension algorithm that sends a ICMP suspend message to the fixed host, informing it that the wireless link is broken and the TCP connection should be suspended. When the wireless link's outage is over, the mobile node will be alerted and will resume the activity with the fixed host. 4. The mobile host behavior 4.1. Underlying layer event not available The mobile host MUST implement the TCP protocol as described in [RFC793] and [RFC1122] and SHOULD implement recommendations emerging from the PILC working group [PILC]. The algorithm described in this section SHOULD be implemented when the mobile host cannot be informed by underlying layer of the new status of the wireless link. 1. The mobile host SHOULD periodically send ICMP PROBE REQUEST packets to the supervisor host. The ICMP probe message MUST be sent to all routers on the networkk (e.g. multicast address 224.0.0.2). This allows the mobile host to roam from one point of attachement to another. The mobile host sets a probe response failure time. At the Magret Expires January 1, 2001 [Page 7] INTERNET DRAFT Long-lived TCP connections July 1, 2000 timer's expiration, the mobile host considers that the link is broken, as the mobile host has not received a response from the supervisor host. The probe response failure timer SHOULD be set to reflect a value greater than the worst round-trip delay conceivable between the mobile host and the supervisor host. The mobile host also sets a probe timer to trigger the emission of the next ICMP PROBE REQUEST message. 2. If the mobile host receives the ICMP PROBE RESPONSE prior to the expiration of the probe response failure timer, the mobile host knows that it can keep on sending TCP segments. The mobile host MUST cancel the probe response failure timer. 3 If the response is not receive from the supervisor host at the expiration of the probe timer, the mobile host SHOULD consider that the wireless link between itself and the supervisor host is disrupted and the mobile host SHOULD transfer every TCP connection into the idle state. In such state, the TCP connection does not send TCP segments and all timers are disabled. 4 While operating in the suspended mode (i.e. TCP connections are idle) the mobile host needs a mechanism to detect any link status change. The mobile host SHOULD continue apply- ing the previously described algorithm (i.e. probing the supervisor host) as the mobile host is not able to receive link status update from the underlying layer. In such case the mobile host SHOULD send periodically ICMP probe mes- sages. The periodicity is to be determined. 5. When connectivity is regained, the mobile host will recieve an ICMP PROBE RESPONSE message to one of its ICMP probe request. The mobile host SHOULD resume all TCP connections' activity. 6. If the mobile host receives an ICMP PROBE RESPONSE after the probe response failure timer's expiration, the mobile host SHOULD resume all TCP connections' activity. The mobile host MAY adjust the probe response failure timer's value to take into account the transmission round-trip Magret Expires January 1, 2001 [Page 8] INTERNET DRAFT Long-lived TCP connections July 1, 2000 degradation. If the mobile host wants to adjust the value of the probe response failure timer, the mobile host SHOULD keep track of the time at which the ICMP probe request was sent. The mobile host SHOULD NOT attempt to adjust the value to the probe response failure timer if the identifier of the response does not match the identifier of the request for which the mobile host has the emission's time. 4.2. Underlying layer event available When the transport layer can be informed of the status of the wire- less link the mechanism of probing the supervisor host described in the previous section is not required. The mobile host SHOULD suspend all its TCP connections when it is informed of a link failure. When the mobile host is informed that the link is back, the mobile host SHOULD resume activity on all suspended connections. 5. The supervisor host 5.1. Underlying layer event not available The basic mechanism of the LL-TCP protocol relies on the fact that the supervisor host monitors the TCP traffic between the fixed hosts and the mobile hosts. The monitoring consists of keeping track of the TCP segments sent in both directions. For each TCP segment sent from the fixed host to the mobile host, a copy of the IP header and the first 8 bytes of the TCP header SHOULD be stored and a suspensing timer SHOULD be launched. If the supervisor host receives from the mobile host an acknowledgement, the timer is cancelled and the TCP segment (eventually several TCP segments) is (are) removed from the cache. Otherwise the supervisor host SHOULD apply the suspension algorithm detailled in the following section. Note: The supervisor host MAY implement the Snoop protocol. In such case, the persist timer defined in Snoop protocol SHOULD be replaced by the suspension timer defined in the LL-TCP protocol. The suspension timer allows the supervi- sor host to alert the fixed host on the new status of the Magret Expires January 1, 2001 [Page 9] INTERNET DRAFT Long-lived TCP connections July 1, 2000 wireless link. 1. If the supervisor host receives an ICMP PROBE REQUEST, it MUST immediately respond with an ICMP PROBE RESPONSE. The response is sent to the unicast address of the request's sender's address. The identifier MUST be copied from the ICMP PROBE REQUEST message. 2. When the supervisor host is informed of the link failure (i.e., at the expiration of the suspension timer), the supervisor host SHOULD initiate the suspend phase. When receiving TCP packets for a mobile host that is in a suspended phase, the supervisor host SHOULD discard them and SHOULD sent to the originator (i.e. the fixed host) an ICMP SUSPEND REQUEST. The ICMP SUSPEND REQUEST includes the IP header and the first 8 bytes of the TCP header of the packet that has triggered the suspension timer. This infor- mation is needed by the destination (i.e. the fixed host) to dispatch the ICMP suspend request. The ICMP suspend request is sent to the fixed host IP address. 3. If the fixed host keeps on transmitting TCP packets to the unreachable mobile host, the supervisor host MUST reply to each packets with an ICMP suspend request. The identifier MUST remain identical to the first ICMP suspend request message sent. After a certain number of retransmission (which remains to be defined), the supervisor host MAY send an ICMP unreachable destination to the fixed host, as the mobile is temporally unreachable and as the fixed host is ignoring the ICMP SUSPEND REQUEST messages. 4. If the supervisor host receives an ICMP suspend response that includes the same identifier, the supervisor host MUST stop sending ICMP SUSPEND REQUEST message. 5. If during the suspend mode, the supervisor host receives an ICMP PROBE messagefrom a mobile host, the supervisor host MUST immediately send and ICMP probe response to the mobile host. Magret Expires January 1, 2001 [Page 10] INTERNET DRAFT Long-lived TCP connections July 1, 2000 6. If the supervisor host receives a TCP window probe packet and if there is a still a wireless link failure the super- visor host MUST ignore the message. 7. If the supervisor host receives a TCP probe window packet and if the supervisor host has received from the mobile host an ICMP probe message, the supervisor host SHOULD for- ward the message to the mobile host so that the mobile can respond to the fixed host request. 5.2. Underlying layer event available If the supervisor host can rely on underlying layer event to send ICMP SUSPEND REQUEST message to the fixed host, then the supervisor host SHOULD NOT implement the suspension timer as described in the previous section. Upon reception of an event indicating that the wireless link is bro- ken. the supervisor host SHOULD send an ICMP suspend request message to the fixed host whenever the fixed host is attempting to send a TCP packet to an unreachable mobile host. The supervisor host SHOULD use the IP header and 8 first bytes of the TCP header to build the pay- loed of the ICMP SUSPEND REQUEST message. The supervisor SHOULD NOT store the IP header and 8 first bytes of the TCP header and SHOULD NOT attempt to match packets with ack- nowledgements. 6. The Fixed host behavior The fixed host SHOULD be able to process ICMP suspend messages. 1. When receiving an ICMP suspend request, the fixed host SHOULD transfer its TCP connections from their current state to the idle state (i.e., suspended mode). In this mode the fixed host is not anymore granted permission to send TCP packets to the mobile host. All pending timer SHOULD be canceled, avoiding exponential back-off algo- rithm. The fixed host SHOULD send an ICMP SUSPEND RESPONSE message to the supervisor host. This message MUST include the identifier given by the supervisor host in the ICMP SUSPEND REQUEST. Magret Expires January 1, 2001 [Page 11] INTERNET DRAFT Long-lived TCP connections July 1, 2000 2. If the fixed host receives identical ICMP SUSPEND REQUEST messages, the fixed host SHOULD send an ICMP SUSPEND RESPONSE message to the supervisor host. This is needed since the transmission of ICMP messages is unreliable. 3. To detect a connectivity regain and since there might be situation where on the fixed host has some data to transfer, the fixed host SHOULD use the persist timer and probe window message to detect connectivity's regain. Note: The description of the protocol is based having in mind a connection between a mobile host and a fixed host, this may not always be the case. There might be some cases where we will have a connection between two mobile hosts. Thus we RECOMMEND that the mobile host implements as well the behavior described in this sectiion for the fixed host. 7. Protocol description The Long-lived TCP connection (LL-TCP) protocol defines two new ICMP messages. This section includes the definition of an ICMP message created to suspend a TCP connection and an ICMP message created to probe the supervisor host. 7.1. ICMP suspend message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IP header and 64 bits of the original datagram | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type field is 20 and 21 for suspend request and for suspend Magret Expires January 1, 2001 [Page 12] INTERNET DRAFT Long-lived TCP connections July 1, 2000 response (values are given as example only) Code is unused and MUST be 0. Identifier aids in matching the requests and the responses. The IP header and the 64 bits of the data payload are used by the fixed host to match the message to the appropriate process. If a higher level protocol uses port numbers, they are assumed to be in the first 64 data bits of the original payload. The IP header and the 64 data bits are not present in the response message. 7.2. ICMP probe message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type field is 22 and 23 for probe request and probe response (values are given as example only). Code is unused and MUST be 0. Identifier aids in matching the requets and the responses. 8. Security considerations The Long-lived TCP connection protocol described in this document may require access to the TCP header for being able to monitor TCP pack- ets in both directions. IP security for instance can not be used. IP security ESP (Encapsulation Security Payload, [RFC2406]) header can- not be employed as the header is encrypted. However, IP security AH (Authentication Header [RFC2402]) which keep the datagram header in clear in the IP packet can be used. This implies a requirement on the fixed host as this node SHOULD NOT discard ICMP message sent with IPSec headers (in this case, AH header). As stated in [RFC2401] in section 6: "An Icmp message not protected by AH or ESP is unauthenti- cated and its processing and/or forwarding may result in denial or service. This suggest that, in general, it would be desirable to ignore such message. However, it is expected that many routers (vs. security gateways) will not implement IPsec for transit traffic and Magret Expires January 1, 2001 [Page 13] INTERNET DRAFT Long-lived TCP connections July 1, 2000 thus strict adherence to this rule would cause many ICMP messages to be discarded. The result is that some critical IP functions would be lost, e.g., redirection and PMTU processing. Thus it MUST be possible to configure an IPsec implementation to accept or reject (router) ICMP traffic as per local security policy" 9. References [RFC2119] S. Bradner, "Key words for use in RFCs to indicate requirement levels", BSP 14, RFC 2119, March 1997. [Snoop] H. Balakrishnan, S. Seshan, E. Amir, and R. H. Katz, "Improving TCP/IP performance over wireless networks", Proceeding of the 1st ACM International Conference on Mobile Computing and Networking (Mobicom95), November 1995. [PILC] Performance Implications of link characteristics, IETF working group in the transport area, http://pilc.lerc.nasa.goc/pilc. [RFC972] J. Postel, "Internet Control Protocol", RFC 792, Sep- tember 1981. [RFC793] J. Postel, "Transmission Control Protocol", RFC 793, September 1981. [RFC1122] S. Bradner, Editor, "Requirements for Internet Host - Communication Layers", RFC 1122, October 1989. [RFC2401] S. Kent, R. Atkinson, "Security Architecture for Internet Protocol", RFC 2401, November 1998. [RFC2406] S. Kent, R. Atkinson, "IP Encapsulation Security Pay- load (ESP)", RFC 2406, November 1998. [RFC2402] S. kent, R. Atkinson, "IP Authentication header (AH)", Magret Expires January 1, 2001 [Page 14] INTERNET DRAFT Long-lived TCP connections July 1, 2000 RFC 2406, November 1998. Authors' addresses Questions or comments about this document may be directed at the author addresses. Vincent Magret Alcatel USA, Inc 1201 Campbell Richardson Texas 75081 USA M/S 446-310 Voice: +1-972-996-2625 Fax: +1-972-996-5902 E-mail: vincent.magret@usa.alcatel.com Mingguey Yang Alcatel USA, Inc. 1201 E. Campbell Road Richardson Texas 75081 USA M/S 446-310 Voice: +1-972-996-2537 Fax: +1-972-996-5902 E-mail: mingguey.yang@usa.alcatel.com Magret Expires January 1, 2001 [Page 15]