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
<draft-chang-mobile-sctp-cc-00.txt>
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]