Internet Draft M. J. Chang/EWU Document: draft-chang-mobile-sctp-cc-00.txt M. J. Lee/EWU H. J. Lee/Nevada Y. G. Hong/ETRI J. S. Park/ETRI Expires: March 2005 October 2004 Error and Congestion Control Algorithm for mSCTP handover Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Abstract This document describes a novel error and congestion control algorithm for mobile Stream Control Transmission Protocol (mSCTP). This algorithm is simple but very effective means to minimize the lost packet recovery time as well as the handover latency by capitalizing on the transport layer awareness of the mobility. CHANG Expires - March 2005 [Page 1] Error and Congestion Control Algorithm for mSCTP handover October 2004 Table of Contents 1. Introduction...................................................2 2. Terminology....................................................2 3. Background.....................................................2 4. Assumption.....................................................3 5. Two Cases may be incurred by a handover........................3 5.1 One or more rtx timeout is incurred by a handover .........3 5.2 No rtx timeout is incurred by a handover...................4 6. A novel error and congestion control of mSCTP..................5 Security Considerations...........................................6 References........................................................6 Author's Addresses................................................7 1. Introduction The mobile Stream Control Transmission Protocol (mSCTP)[1] which is based on the multi-homing feature of Stream Control Transmission Protocol(SCTP)[2] has been proposed as a transport layer mobility solution. The current specification of mSCTP does not include an error and congestion control algorithm that consider mobile environment. It means that mSCTP is able to use the error and congestion control of SCTP. In this document, we describe an efficient error and congestion control algorithm which minimizes the lost packet recovery time as well as the handover latency, compared to that of original SCTP for handover cases. 2. Terminology 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 RFC 2119[3]. 3. Background SCTP employs error and congestion control algorithms similar to those used in TCP. While supporting multi-homing, SCTP maintains a receive window size per association, and a congestion window size and an outstanding data size per path [2]. In mobile environments, this implies that the congestion window size of the new path is not affected by the ACK sent over the old path before handover. Following the slow start phase, SCTP reduces the congestion window size to one in the case of retransmission timeout (as TCP does) and sets it to two for the new path, respectively. CHANG Expires - March 2005 [Page 2] Error and Congestion Control Algorithm for mSCTP handover October 2004 4. Assumption We are particularly interested in mobile terminals (MTs) equipped with a single wireless network interface that are currently the most common feature. We assume that packet loss is only due to handover and all of the acknowledgements (ACKs) sent by MT for packets that have arrived at it before the handover are successfully delivered to the Correspondent Terminal (CT). 5. Two Cases may be incurred by a handover (1) One or more retransmission timeout is incurred by a handover (2) No retransmission timeout is incurred by a handover In the following subsection, each case is analyzed. 5.1 One or more retransmission timeout is incurred by a handover CT may not received any ACK for a while, after receiving the last ACK sent over to the old path, because of the losses caused by the handover. Then, the CT may exhaust its available window, set its retransmission timer, and thus temporarily stop transmitting. Later, it retransmits the first lost packet as the timer expires. If this happens after the CT receives the ASCONF chunk, the packet would be successfully sent over the new path. But if not, the packet would be sent over to the old path, and lost again, resulting in second timeout, and so on. That is, the number of retransmission for the packet can be more than once depending on the time that the CT receives the ASCONF chunk. For each timeout, the timer doubles its timeout threshold value [2]. If the CT suffers from n_th retransmission timeout before the corresponding ASCONF chunk, the handover latency H_timeout is H_timeout = PAT + Delay(new, ASCONF) + c + Delay(new, DATA) = (SUM_{i=0}^{n} 2^{i})*TO, where 0 <= c <= 2^i*TO. (1) In (1), the handover latency is the elapsed time between the beginning of layer-2 handover and the arrival of the first packet via new route. PAT (Path Acquisition Time) is the elapsed time for the MT between the beginning of the layer-2 handover and the acquisition of a new IP address. D(x, y) denotes the delay to deliver y through the path x, 'TO' denotes the initial retransmission timeout value, and c equals the length of time interval from the time instant that the CT receives the ASCONF chunk till the instance that the current retransmission timer expires. Following the congestion control mechanism of the current SCTP, the new path cannot be used even after the arrival of the ASCONF chunk unless the current retransmission timer expires. This side effects result in exponentially increasing CHANG Expires - March 2005 [Page 3] Error and Congestion Control Algorithm for mSCTP handover October 2004 handover latency with the number of retransmission timeout. Furthermore, every retransmission timeout reduces the congestion window to one and this value increases following the slow start phase. Therefore, given that l (>0) packets are lost and i retransmission timeouts occur during handover before the CT receives the corresponding ASCONF chunk, the total time delay L_timeout at the CT for the lost packet recovery after the arrival of the ASCONF chunk is L_timeout = c + (1 + [log_{2} l]) * RTT (2) , where 0 <= c <= 2^i*TO and RTT denotes the round trip time. 5.2 No retransmission timeout is incurred by a handover The CT may proceed its transmission over the new path without experiencing retransmission timeout. In this case, the handover latency is minimum with the original SCTP. We formulate this handover latency H_no_timeout as in the following: H_no_timeout = PAT + Delay(new, ASCONF) + Delay(new, DATA) (3) In this case, the lost packets are recovered by Fast Retransmission mechanism because ACKs are arriving continuously. Since SCTP Fast Retransmission mechanism requires 4 duplicate ACKs, which takes at least 2RTTs after receiving the ASCONF, the recovery of losses caused by handover may start only after 2RTT passes after receiving the ASCONF. After receiving 4 duplicate ACKs, SCTP applies Fast Recovery congestion control. In this kind of handover case, the congestion window is supposed to be less than 2 packets when the Fast Recovery starts, and Fast Recovery phase increases the size of congestion window by one packet for each RTT. Based on this observation, now we formulate the relationship between the number of lost packets and its recovery time normalized by RTT in Equation (4). The sequence of minimum number of lost packets that requires k*RTT for error recovery, for k>=2, is a sequence of progression of differences with the initial term being 2 and the progression difference being (k+2). Hence, the minimum number of lost packets, which is denoted by Sk, that requires k*RTT recovery time is Sk = 2 + (SUM_{i=1}^{k-1} (i+2)) = (k^2+3k)/2, for k>= 2. (4) CHANG Expires - March 2005 [Page 4] Error and Congestion Control Algorithm for mSCTP handover October 2004 We replace k with (k-1) in (5) in order to include the case with k = 1, and obtain Sk = {(k-1)^2 + 3(k-1)}/2 = k^2+k-2, for k-1>=1. (5) Then, the number of lost packets l becomes l = [(k^2+k-2)/2]. (6) Solving the equation (7) for k, k is obtained as follows: k= [(-1 + sqrt{8*l+9})/2], for l >=1. (7) As a result, without retransmission timeout, the total time delay L_no_timeout at the CT for the lost packet recovery after the arrival of the ADDIP/Set-Primary ASCONF chunk is L_no_timeout = (2 + [(-1 + sqrt{8*l+9})/2]) * RTT, for l>= 1. (8) As formulated in Equation (8), the total time delay to recover all of the lost packets is considerable even with no retransmission timeout. 6. A novel error and congestion control of mSCTP We present a simple but very effective means to minimize the lost packet recovery time as well as the handover latency by capitalizing on the transport layer awareness of the mobility. This algorithm requires changes of SCTP module only at the CT part. Upon receipt of this ASCONF chunk, the CT immediately stops its timer for the last packet transmitted over the old path and sends the packet with the lowest sequence number among the packets which are never sent to the MT yet. This packet is referred to as a probe packet in this paper. SCTP standards allow sending one packet even with zero receiver window if the outstanding data size is zero. Since the outstanding data size of the new path is always zero, transmitting this probe packet is always legitimate with respect to the existing SCTP flow control regardless of the receiver window size. Since SCTP deploys Selective ACK (SACK), the ACK for the probe packet from the MT contains the information about the last packet received by the MT through the old path. Receiving the ACK for the probing packet, the CT starts transmitting the packets that are lost during handover with the slow start congestion control. Note that slow start congestion control assures that the transmission on the new path is not only as friendly as a newly starting SCTP flow but also it grasps the available bandwidth on the new path exponentially fast. CHANG Expires - March 2005 [Page 5] Error and Congestion Control Algorithm for mSCTP handover October 2004 The handover latency of the proposed approach, H_probe is H_probe = PAT + Delay(new, ASCONF) + Delay(new, DATA). (9) Obviously, the proposed approach reduces the handover latency by c (0 <= c <= 2^i*TO) compared to the original SCTP when retransmission timeout occurs. The total time delay L_probe to recover lost packets after receiving the ASCONF chunk is L_probe = (1 + [log_{2} {l+1}]) * RTT. (10) Therefore, the proposed approach indeed reduces the packet loss recovery time by E: E --- L_timeout - L_probe = c, where 0 <= c <= 2^i*TO, | if (number of retransmission timeout > 0) -- L_no_timeout - L_probe =(1 + [(-1 + sqrt{8*l+9})/2]-[log_{2} {l+1}]) * RTT, if (number of retransmission timeout = 0) Security Considerations This document discusses architecture of SCTP mobility support. The associated security issues will be identified as further works go on. References [1] M. Riegel, M. Tuxen, "Mobile SCTP", Internet Draft, Internet Engineering Task Force, August 2003. [2] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels",RFC 2119, March 1997. CHANG Expires - March 2005 [Page 6] Error and Congestion Control Algorithm for mSCTP handover October 2004 Author's Addresses Moon Jeong Chang mjchang@ewha.ac.kr Ewha Womans Univ., Korea Mee Jeong Lee lmj@ewha.ac.kr Ewha Womans Univ., Korea Hyun Jeong Lee hyunlee@unr.edu Univ. of Nevada, Reno Young Geun Hong yghong@etri.re.kr ETRI, Korea Jung Soo Park pjs@etri.re.kr ETRI, Korea Full Copyright Statement Copyright (C) The Internet Society (2004). 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 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." CHANG Expires - March 2005 [Page 7]