Network Working Group                                           M. Honda
Internet Draft                                                Keio Univ.
<draft-micchie-tsvwg-fastmsctp-00.txt>                        Y. Nishida
                                                           Sony CSL Inc.
                                                               M. Kozuka
                                                             Kyoto Univ.
Expires August 26, 2007                                     Feb 26, 2007

   Fast Handover with Stream Control Transmission Protocol (SCTP) on
                           Single-home nodes
                 <draft-micchie-tsvwg-fastmsctp-00.txt>

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

   Providing transport layer mobility is one of the features of SCTP [RFC2960].
   By using Dynamic Address Reconfiguration extension, SCTP can accomplish
   handover between different subnets.
   However, due to some issues in the current SCTP, serious performance
   degradation will happen during the handover process.
   The problem arises especially when a mobile node has only one network
   interface.
   This document describes the issues of current SCTP handover mechanism and
   proposes three functions to achieve smooth and fast handover.













Table of Contents

   1. Introduction ....................................................2
   2. Issues in SCTP Handover Mechanism ...............................2
   3. Proposed Solutions for Fast Handover ............................3
      3.1. Source and Destination Based Congestion Control ............3
      3.2. Definition of Set Primary reception ........................4
      3.3. Recommend Retransmission ASCONF parameter ..................4
         3.3.1. New Parameter Type ....................................5
         3.3.2. Recommend Retransmission ..............................5
      3.4. General rules for immediate retransmission .................6
   4. IANA Considerations .............................................6
   5. References ......................................................6


1. Introduction

   Stream Control Transmission Protocol (SCTP) Dynamic Address
   Reconfiguration [ADD-IP] can support mobility among different subnets
   by reconfiguration of addresses in existing SCTP associations.  When
   a mobile node (MN) moves and obtains or configures a new IP address,
   the MN-side SCTP endpoint is notified of the new address from the
   lower layer.  Then, the MN sends an ASCONF Chunk containing Add IP
   Address parameter to notify a correspondent node (CN) of the new
   address, and the MN and the CN can maintain an existing SCTP
   association.

   Additionally, the MN can make the CN change a primary destination to
   the new address by sending an ASCONF Chunk containing Set Primary
   parameter [ADD-IP].  Therefore, the MN can make the CN send DATA
   Chunks to the new address.

   However, due to some issues in the current SCTP, serious
   communication delay arises during the SCTP handover process,
   especially, when the MN is single-homed, which has only one available
   network interface.  The single-homed MN loses the reachability during
   it connects to a new wireless base station and obtains or configures
   a new IP address.  However, the MN tries to transmit or retransmit
   packets.  These data transmissions cause Retransmission Time Out
   (RTO) expirations and increase the RTO value.  In some cases, the
   increased RTO value exceeds 30 seconds and causes serious performance
   degradation on data transfer.

   In this document, we describe the issues of the current SCTP handover
   mechanism and propose a solution to achieve smooth and fast handover.
   Our solution consists of three proposals.  First, we propose an
   optional congestion control policy, which is source and destination
   based congestion control, while destination based congestion control
   used in the current specification of SCTP.  Second, we propose to
   clarifies the SCTP behavior when SCTP endpoints receive an ASCONF
   Chunk that contains Set Primary parameter.  Third, we propose a new
   ASCONF parameter: Recommend Retransmission that requests immediate
   retransmissions to a specified address to a peer endpoint.


2. Issues in SCTP Handover Mechanism

   The issues in SCTP Handover Mechanism that cause communication delay
   can be categorized into the following four parts.

   If the MN is multi-homed, the MN may be able to keep the reachability
   to the CN by using other network interfaces during the handover
   process in some cases.  Thus, following issues might not be serious
   for multi-homed MNs.

   A) A single-homed MN cannot transmit an ASCONF Chunk right after it
      is notified of an IP address from the lower layer.  Although the
      ASCONF Chunk can be transmitted from the new address, the
      transmission is delayed until the current RTO expires.  When the
      RTO value is increased by the failures of data transmission during
      the lower layer disconnection caused by connecting to a new
      wireless base station and obtaining or configuring a new IP
      address, the delay might be fairly long in some cases.  This issue
      indicates that an SCTP endpoint does not regard the change of a
      source address as the change of communication path.

   B) A CN transmits an ASCONF-ACK Chunk when it receives an ASCONF
      Chunk containing Add IP Address parameter from the MN.  By
      receiving the ASCONF-ACK, the MN can confirm that the CN is
      notified of the new IP address and it can transmit data from the
      new source address.

      However, when the MN fails data transmissions from the previous
      source address during the lower layer disconnection and A), these
      DATA Chunks are not retransmitted from the new source address
      until the next RTO expiration.  Moreover, when many retransmission
      failures are occurred, the RTO value is materially increased.

   C) A CN cannot start data transmissions to the new address of the MN
      right after the handover process.  When the CN receives an ASCONF
      Chunk containing Add IP Address parameter, it marks the new
      destination address as unconfirmed and sends a HEARTBEAT Chunk in
      order to confirm the reachability of the destination as specified
      in Section 4.3 of [ADD-IP].  After the CN receives a HEARTBEAT-ACK
      Chunk for the HEARTBEAT, it can transmit DATA Chunks to the new
      destination.  Hence, even if the CN fails to transmit DATA Chunks
      to MN's old destination by the RTO expirations, the CN can
      retransmit them to the newly confirmed destination.

      However, when the CN fails retransmission many times before the
      reception of the HEARTBEAT-ACK, the RTO value is fairly increased.
      In this case, the CN cannot retransmit DATA Chunks until the next
      RTO expiration.

   D) For smooth handover, the MN should transmit an ASCONF Chunk
      containing Set Primary parameter for the new address in order to
      make a CN change the primary address expressly.  Otherwise, the CN
      might transmit DATA Chunks to the old destination until the number
      of retransmissions exceeds the protocol parameter
      'Path.Max.Retrans'.

      When the CN receives an ASCONF Chunk containing Set Primary
      parameter, it changes the primary destination to the specified
      address.  However, some implementations do not apply this
      specified primary destination to the DATA Chunks that are already
      inserted to send queue or retransmission queue, since the current
      specification is not clear at this point.  This might cause
      several unnecessary retransmission failures and lead long
      communication delay in some cases.


3. Proposed Solutions for Fast Handover

      We propose following three solutions to solve the issues described
      in Section 2.  These solutions are especially effective when the
      mobile node is single-homed.


3.1.  Source and Destination Based Congestion Control

      We propose that SCTP MAY use an optional congestion control policy
      when the handover process, which is source and destination based
      congestion control, while destination based congestion control
      used in the current SCTP.  This means that SCTP endpoints can
      recognize communication paths by a pair of source and destination
      addresses.  This enables that SCTP endpoints consider change of
      the source address as change of the communication path when the
      handover process.

      In some cases, the change of source address does not indicate the
      change of the communication path, such as renumbering source
      addresses.  However, this rarely happens while handover in
      wireless networks happens frequently.

      Additionally, in the mobile environment, the congestion in
      wireless links that are located as edge networks is more
      frequently happens than wired networks that are located as the
      backbone networks.  Therefore, if the change of source address is
      not considered as change of communication path, it might aggravate
      the congestion when the MN's visited link is congested.

      Based on this concept, we propose all the congestion control
      parameters, such as (cwnd, ssthresh, RTO) related to a path should
      be reset to the initial values when the source or destination
      address of the path has been changed.  Besides that, the endpoint
      MUST start sending DATA Chunks with slow-start algorithm.

      According to this, an SCTP endpoint MAY send an ASCONF Chunk
      containing Add IP Address parameter from a newly obtained or
      configured address without waiting for the RTO expiration.

      In addition, we propose an SCTP endpoint MAY retransmit DATA
      Chunks from the new source address without waiting for the RTO
      expiration when they are sent from the new source address.

      In some cases, the CN might receive several duplicated TSN DATA
      Chunks, such as when the handover process is completed during
      especially short time or the MN is multi-homed.  Hence, minimum
      waiting time or rules for the retransmission might be needed.


3.2.  Definition of Set Primary reception

      We propose to clarify the SCTP behavior when endpoints receive an
      ASCONF containing Set Primary parameter.  In the current
      specification[ADD-IP], it depends on the implementation whether
      endpoints apply the newly specified primary address to DATA Chunks
      which are already copied to the SCTP stack or inserted to the send
      queue.

      However, since this can affect the handover latency for single-
      home nodes seriously, we propose that an endpoint SHOULD apply the
      new primary destination to all DATA Chunks that are not sent yet
      and not specified the destination by user application when it
      receives Set Primary parameter.  Note that this is not applied to
      the DATA Chunks in the retransmission queue.


3.3.  Recommend Retransmission ASCONF parameter

      To avoid data retransmissions to the old primary address when SCTP
      endpoints receive an ASCONF Chunk containing Set Primary
      parameter, this document defines a new ASCONF parameter: Recommend
      Retransmission.  This parameter requests immediate data
      retransmissions to the specified address.  When an endpoint
      receives an ASCONF containing Recommend Retransmission parameter,
      it MAY retransmit all unacknowledged DATA Chunks to the specified
      address without waiting RTO expiration.  This means that the
      endpoints modify the destination of DATA Chunks in the
      retransmission queue to the specified destination, and retransmit
      them immediately.

3.3.1 New Parameter Type

      The one new parameter added follow the format defined in section
      3.2.1 of [RFC2960].  Table 1 describes the parameter.

      Address Configuration Parameters    Parameter Type
      -------------------------------------------------- Recommend
      Retransmission              0xC007

      Table 1: Parameters used in ASCONF Parameter

3.3.2 Recommend Retransmission

       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 = 0xC007          |    Length = Variable          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               ASCONF-Request Correlation ID                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Address Parameter                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      ASCONF-Request Correlation ID: 32 bits

      This is an opaque integer assigned by the sender to identify each
      request parameter.  It is in host byte order and is only
      meaningful to the sender.  The receiver of the ASCONF Chunk will
      copy this 32 bit value into the ASCONF Response Correlation ID
      field of the ASCONF-ACK response parameter.  The sender of the
      ASCONF can use this same value in the ASCONF-ACK to find which
      request the response is for.

      Address Parameter: TLV

      This field contains an IPv4 or IPv6 address parameter as described
      in 3.3.2.1 of [RFC2960].  The complete TLV is wrapped within this
      parameter.  It requests the receiver to retransmit DATA Chunks
      that are not acknowledged by SACK to the specified address.  If
      the address 0.0.0.0 or ::0 is provided, the receiver MAY use the
      source address of the packet as a destination for the
      retransmission.

      An example TLV requesting to make receiver retransmit
      unacknowledged DATA Chunks to an IPv4 address 10.1.1.1.


            +--------------------------------+
            |  Type=0xC007   | Length = 16   |
            +--------------------------------+
            |       C-ID = 0x01023479        |
            +--------------------------------+
            |  Type=5        | Length = 8    |
            +----------------+---------------+
            |       Value=0x0a010101         |
            +----------------+---------------+


3.4 General rules for immediate retransmission.

      Recommend Retransmission is MUST accepted only when the specified
      address is confirmed and reachable state.  Additionally, these
      retransmissions MUST be performed with SCTP congestion control
      mechanism and flow control mechanism that are described Section 7
      of [RFC2960].  Therefore, when there are some Chunks that are
      previously sent to the destination and not acknowledged by SACKs,
      retransmissions by this parameter are started with the current
      congestion state of the destination.

      In some cases, the CN might receive several duplicated TSN DATA
      Chunks, such as when the handover process is completed during
      especially short time or the MN is multi-homed.  Hence, same as
      MN's retransmission described in Section 3.1, minimum waiting time
      or rules for the retransmission might be needed.


4.  IANA Considerations

      This document defines the following new SCTP parameters, Chunks
      and errors.

      o  One parameter type

      This parameter type must come from the range of types whare the
      upper two bits are set, we recommend 0xC007, as specified in this
      document.  The suggested parameter type is listed in Table 1.


6.  References
   [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L., and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

   [ADD-IP]  Stewart, R., Xie, Q., Thuexen, Q., Maruyama, S., Kozuka., M
              "Stream Control Transmission Protocol (SCTP) Dynamic
              Address Reconfiguration", draft-ietf-tsvwg-sctp-addip-
              sctp-17 (work in progress), November 28 2006.


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 (2006).

   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.