Network Working Group M. Honda Internet Draft Keio University Y. Nishida Sony CSL Inc. M. Kozuka Kyoto University Expires Aug 21, 2008 Feb 21, 2008 Stream Control Transmission Protocol (SCTP) Readdressing Retransmission Trigger Status of this Memo Distribution of this memo is unlimited. 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. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Stream Control Transmission Protocol (SCTP)[RFC4960] can support mobility by utilizing the multi-home feature and the Dynamic Address Reconfiguration extension (ADDIP)[RFC5061]. By leveraging this feature, applications that use SCTP can continue communication without terminating it when the mobile node migrates to another network. However, the migration of a mobile node often involves connectivity disruption due to bad wireless coverage, potential device overhead on the wireless interface to switch the wireless network to connect, and configuring a new IP address. The connectivity disruption can induce significant delay on the SCTP communications, because it causes retransmission time outs (RTOs) for lost packets that are transmitted in this period. In order to avoid the delay caused by the RTOs, this document describes a new retransmission trigger based on endpoint readdressing events. SCTP can minimize the delay caused by migration involving connectivity disruption with this retransmission trigger. Table of Contents 1. Introduction ....................................................2 2. Conventions .....................................................2 3. Extra Transmission Delay after Migration ........................2 3.1. Migration Involving Disruption .............................2 3.2. Signaling on SCTP Association ..............................3 3.3. Transmission Delay Caused by Retransmission Time Outs ......3 4. New Retransmission Trigger Based on Readdressing Events .........4 4.1. Detection of Endpoint Readdressing Caused by Migration .....4 4.1.1. Mobile Node-side Retransmission Trigger ................4 4.1.2. Correspondent Node-side Retransmission Trigger .........5 4.2. Rules on Starting Retransmission ...........................5 5. IANA Considerations .............................................5 6. References ......................................................6 6.1. Normative References .......................................6 6.2. Informative References .....................................6 Appendix: Evaluation ...............................................6 1. Introduction A mobile node reconfigures the IP address on the wireless interface when it attaches to another wireless access network, provided by different carriers maintaining their own IP address space. Stream Control Transmission Protocol (SCTP)[RFC4960] is a connection- oriented and reliable transport protocol, which provides advanced features in addition to that of the TCP features. Dynamic Address Reconfiguration (ADDIP)[RFC5061] allows SCTP endpoints to reconfigure IP addresses bound to them dynamically, thereby the existing SCTP association can be maintained. Hence, SCTP provides mobility support between different networks. On the other hand, migration to another network often involves connectivity disruption. This is caused by one of the following: passing through an area of bad wireless coverage, potential device overhead on the wireless interface to switch the wireless network to connect, and configuring a new IP address by DHCP, Stateless Address Autoconfiguration or DHCPv6. During the disconnected period, SCTP endpoints on the mobile node (MN) and those on the correspondent node (CN) fail to transmit packets. Due to the retransmission behavior based on Retransmission Time Out (RTO), the packet losses can lead extra transmission delay after the connectivity revival on the SCTP associations. Therefore, SCTP endpoints on the MN and the CN need to retransmit data immediately after the connectivity revival to avoid the extra delay caused by waiting for the next RTO expiration. This document describes the algorithm that SCTP endpoints retransmit unacknowledged data by the detection of connectivity revival. It is based on the preceding research[HNNKT08] that detects the connectivity revival after migration to another network by the endpoint readdressing event, and retransmits unacknowledged data immediately. 2. Conventions 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]. 3. Extra Transmission Delay after Migration This section describes the issue of extra transmission delay in SCTP on mobile nodes migrating between wireless networks. In order to clarify the issue, this section first describes migration involving connectivity disruption with three scenarios. Second, signaling to reconfigure IP addresses with ASCONF Chunks in the existing SCTP association is described. Finally, the extra transmission delay in SCTP is detailed. 3.1. Migration Involving Disruption When the MN migrates to another wireless network, it often involves connectivity disruption. The connectivity disruption occurs when it A)passes an area of bad wireless coverage, B)switches the wireless network to connect on the wireless interface and C)configures a new IP address by DHCP, Stateless Address Autoconfiguration or DHCPv6. If two wireless networks to connect to before and after migration overlap, the MN bypasses (A). However, the MN always experiences (B) and (C) as long as it does not connect to both wireless networks simultaneously with multiple wireless interfaces. Duration for (B) is depending on the wireless device, the driver implementation and reception of the wireless beacon. Although, duration for (C) is depending on the configuration process of a new IP address, for instance, Duplicate Address Detection (DAD) in IPv6 address configuration might take time more than 1 second. 3.2. Signaling on SCTP Association When a mobile node (MN) migrates to another network and configures a new IP address, the SCTP implementation is notified of the new address from the lower layer. The way that the SCTP implementation is notified of it depends on the implementation. For instance, BSD implementation leverages the routing socket. Windows implementation leverages the event notification provided by the operating system. Then, the SCTP endpoints on the MN notify the peers about the address reconfiguration. An SCTP endpoint transmits ASCONF Chunk(s) to the peer, which contains two or three parameters; Add IP Address, Delete IP Address, and optionally, the Set Primary parameter. Delete IP Address parameter contains previous address(es), and operates to remove the address(es) from the association. Add IP Address contains the newly configured address(es), which adds the address(es) to the association. Set Primary also contains one of the new addresses, which makes the peer set the address as the primary destination. The endpoint receiving ASCONF Chunk(s) containing Add IP Address and Delete IP Address processes Add IP Address parameter first, and then, processes Delete IP Address parameter. Subsequently, the endpoint acknowledges the ASCONF by transmitting ASCONF-ACK Chunk(s). At the same time, in order to transmit data to the added destination, the endpoint needs to transmit a HEARTBEAT Chunk to the added destination. This is because, newly added destinations are marked as unconfirmed. The HEARTBEAT Chunk might be bundled to the ASCONF-ACK. Note that Add IP Address parameter MUST be placed at first, according to the ASCONF rules described in [RFC5061] Section 4.2. In addition, each parameter may appear in a same ASCONF Chunk, or may appear in multiple ASCONF Chunks bundled in one SCTP packet, according to address manipulation rules described in Section 4.1 of [RFC5061]. If many addresses are deleted and many addresses are added (e.g., IPv4 and IPv6 addresses), each parameter might be straddle multiple SCTP packets, due to the limitation of the maximum size of an ASCONF Chunks and MTU described in Section 4.1 of [RFC5061]. 3.3. Transmission Delay Caused by Retransmission Time Outs During the disconnected period described in Section 3.1, an SCTP endpoint on the MN fails to transmit packets. An endpoint on the CN also fails to transmit packets to the MN. These failures are observed as packet losses at SCTP endpoints on the MN and the CN. The lost packets are retransmitted on the next RTO expiration. Hence, even when connectivity on the MN returns and the ASCONF signaling completes, the lost packets are not retransmitted until the next RTO expiration. Although the RTO value is calculated by RTT, it can rounded up to 1 second if the RTO value is less than 1 second, according to [RFC2988]. The RTO value is doubled on each RTO expiration and the maximum value is 60 seconds. Therefore, the delay after the connectivity revival becomes longer with the growth of the RTO value. In the worst case, the delay could be almost 60 seconds. 4. New Retransmission Trigger Based on Readdressing Events In order to avoid the extra delay after the connectivity revival, immediate retransmission after migration and the subsequent ASCONF signaling is required. On the other hand, ASCONF Chunks are transmitted not only due to migration, but also due to other events. For instance, configuring new addresses to another wireless interface and deleting addresses from an inactivated wireless interface are expected. In this case, an ASCONF Chunk containing Add IP Address or Delete IP Address parameter is simply transmitted. Therefore, readdressing events caused by migration to another network should be properly distinguished in the SCTP endpoint to avoid inappropriate retransmissions. Section 4.1 describes the detection algorithm of the readdressing event caused by migration. At the same time, the detection is used as the retransmission trigger. In Section 4.2, the transmission rate determined by the congestion window size (cwnd) and the RTO value is described. 4.1. Detection of Endpoint Readdressing Caused by Migration Readdressing events caused by migration to another network includes following operations in the association. o Deletion of address(es) other than adding address(es) o Addition of new address(es) When an endpoint transmits ASCONF Chunk(s) containing Add IP Address for new address(es), Delete IP Address for address(es) other than the adding address(es), and the peer acknowledges them with success response, it is considered as the completion of ASCONF signaling after migration. When the endpoint completes ASCONF signaling caused by the MN's migration to another network, it changes the all local addresses or the all destination addresses by ASCONF Chunk(s) containing Add IP Address and Delete IP Address parameters. This indicates readdressing events caused by the MN's migration to another network. 4.1.1. Mobile Node-side Retransmission Trigger When all local addresses are changed on an ASCONF sender, it indicates that the MN has migrated to another access network. Hence, when the ASCONF sender receives ASCONF-ACK Chunk(s) reporting the success response of Add IP Address parameter, and if it does not have addresses that are still usable before the reception of the ASCONF- ACK, it MAY retransmit unacknowledged data immediately. The usable local address means that the address can be used to transmit any chunks. In addition, addresses that are being deleted and waiting to be transmitted as Delete IP Address parameter are not usable local addresses. IMPLEMENTATION NOTE: Adding multiple IP addresses simultaneously in the SCTP association might not occur in practice as long as the notification of a new address and transmission of the ASCONF are timely. Hence, when an ASCONF sender receiving an ASCONF-ACK Chunk for Add IP Address parameter has only one usable local address, it can work as the retransmission trigger in many cases. 4.1.2. Correspondent Node-side Retransmission Trigger Change of all destination addresses on the ASCONF receiver indicates the MN's migration to another network. Therefore, after processing ASCONF Chunk(s) containing Add IP Address parameter and confirming reachability of the new destination with a HEARTBEAT Chunk, if the endpoint has only newly added destination addresses, it MAY retransmit unacknowledged data immediately. If multiple IP addresses are added with the ASCONF(s), a destination of the immediate retransmission SHOULD be the primary destination. Hence, if the ASCONF(s) includes a Set Primary parameter, the endpoint SHOULD retransmit to the specified destination. 4.2. Rules on Starting Retransmission Endpoint readdressing caused by the MN's migration means change of the communication path on the SCTP association. Based on the change of the communication path, the path parameters, such as the cwnd and the RTO value should be reset on the readdressing event described in Section 4.1. On the CN-side endpoint, the RTO value is naturally initialized by change of the destination address. On the MN-side, due to the congestion control based on a destination address, the cwnd has dipped to 1*MTU if at least one RTO expiration has occurred. If no RTO expiration occurred during the disconnected period, the cwnd is not dipped or kept to the value before the readdressing event. However, since the readdressing event related to migration means change of the communication path, the cwnd should be set to the initial value regardless of the cwnd before the readdressing event. On both endpoints, the cwnd on the retransmission based on the endpoint readdressing SHOULD be initialized, or set to <= 2*MTU. Initial cwnd is described in [RFC4960] Section 7.2.1. In order to prove the available bandwidth of the new communication path, both the MN-side and the CN-side endpoints MUST start retransmission with slow-start[RFC2581]. On the CN-side endpoint, the RTO value is naturally initialized by change of the destination address. Since SCTP performs congestion control based on a destination address, on the MN-side endpoint, the grown RTO value during the disconnected period might remain on the new communication paths. On both endpoints, the RTO value on the retransmission based on the endpoint readdressing SHOULD be set to initial RTO value, or RTO.Initial. On the MN-side endpoint, RTT observed by the ASCONF and the ASCONF-ACK MAY be earmarked to the RTO value. On the CN-side endpoint, RTT observed by the HEARTBEAT and the HEARTBEAT-ACK MAY be earmarked to the RTO value. The calculation algorithm is described in [RFC4960] Section 6.3.1. 5. IANA Considerations This document has no actions for IANA. 6. References 6.1. Normative References [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5061] Stewart, R., Xie, Q., Thuexen, M., Maruyama, S., and Kozuka, M., "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission Timer", November 2000. [RFC2581] Allman, M., Paxson V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999. 6.2. Informative References [HNNKT08] M. Honda, J. Nakazawa, Y. Nishida, M. Kozuka, and H. Tokuda, "A Connectivity-Driven Retransmission Scheme Based On Transport Layer Readdressing", 28th International Conference on Distributed Computing Systems (ICDCS), Jun 2008.(To appear) Appendix: Evaluation This section presents a brief overview of the experimental results on a real implementation of the retransmission trigger. The reduction of the transmission delay depends on the disconnected period. When the next RTO expires soon after the connectivity revival, efficiency of the retransmission trigger is small. However, the later the next RTO expires after the connectivity revival, the more effective the retransmission trigger is. The more details of the evaluation is given in [HNNKT08]. Authors' Addresses Michio Honda Keio University 5322 Endo Fujisawa Kanagawa Japan Email: micchie@sfc.wide.ad.jp Yoshifumi Nishida Sony CSL Inc. 3-14-13 Higashigotanda Shinagawa-ku Tokyo Japan Email: nishida@csl.sony.co.jp Masahiro Kozuka Kyoto University Yoshida-Honmachi Sakyo-ku Kyoto Japan Email: ma-kun@kozuka.jp Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.