IMPACT OF SACK DELAY AND LINK DELAY ON FAILOVER PERFORMANCE IN SCTP Johan Eklund Karlstad University S-651 88 Karlstad, Sweden email: Johan.Eklund@kau.se Anna Brunstrom Karlstad University S-651 88 Karlstad, Sweden email: Anna.Brunstrom@kau.se ABSTRACT The Stream Control Transmission Protocol (SCTP) was de- veloped to support the transfer of telephony signaling over IP networks. One of the ambitions when designing SCTP was to offer a robust transfer of traffic between hosts. For this reason SCTP was designed to support multihoming, which gives the possibility to set up several paths between the same hosts in the same session. If the primary path be- tween a source machine and a destination machine breaks down, the traffic may still be sent to the destination by uti- lizing one of the alternate paths. The failover that occurs when changing path is to be transparent to the application. Consequently, the time between occurrence of a break on the primary path until the traffic is run smoothly on one of the alternate paths is important. This paper presents experi- mental results concerning SCTP failover performance. The focus in this paper is to evaluate the impact of the SACK delay and link delay on the failover time as well as on the maximum transfer time for a single message, which com- plements earlier studies in this area. The results show a significant performance impact of the SACK delay as well as of the link delay. This suggests that the SACK delay is an important parameter to tune to enhance application transparency in failure situations. KEY WORDS IP Networks, SCTP, Multihoming, Failover Performance, Experimental Study 1 Introduction The Stream Control Transmission Protocol (SCTP) [1] is a relatively new general purpose transport protocol, pri- marily designed to enable telephony signaling over IP. One of the demands from telephony signaling was robustness, which requires redundant paths between hosts. This is sup- ported in SCTP by a feature called multihoming. This fea- ture enables the connection of more than one path between the same hosts in the same session. If the data is delivered to the receiver as expected all the traffic is sent on the path denoted primary, but if the traffic on the primary path can- not be delivered the traffic is switched over to one of the alternate paths and the data delivery to the destination host proceeds. A so called failover has occurred. In the experimental study presented in this paper we focus on the failover performance of SCTP. The set up of the experiment is inspired by the telephony signaling per- spective in that we consider the transfer of many small mes- sages. Our contribution is twofold. First we extend the re- search by Grinnemo and Brunstrom [2], by investigating the impact of longer link delays on the failover time and on the resulting longest transfer time for an individual mes- sage. Second, and most importantly, we investigate the im- pact of the SACK delay on these performance parameters. The results indicate that the link delay as well as the SACK delay have a major impact on both the failover time and the maximum message transfer time. The remainder of the paper is organized as follows. In Section 2 SCTP and the failover procedure is further de- scribed. Section 3 presents some related work done in this area. Further, in Section 4 the experimental setup and the parameters used for the experiment are presented. Section 5 presents the results from the experiment as well as an analysis of the results. Finally in Section 6 some conclu- sions are drawn and some suggestions for future work are pointed out. 2 SCTP and Failover SCTP is a reliable transport protocol, which has inherited many features from the traditional reliable transport pro- tocol on the Internet, TCP [3]. The congestion control of SCTP is based on the congestion control of TCP [4]. The slow start, congestion avoidance and fast retransmit mech- anisms have been almost directly inherited from TCP, al- though SCTP uses a byte-oriented congestion window as opposed to the segment-oriented window used by TCP. Al- though recently revised, the original SCTP specification [1] also required four duplicate acknowledgements to be re- ceived before triggering a fast retransmit (as opposed to three in TCP) and this is used in our experiment. SCTP em- ploys a selective acknowledgement (SACK) scheme that is similar to SACK TCP. Although many of the features of SCTP have been in- herited from TCP, there are, however, also some significant differences between the protocols. TCP uses only one inter- face on each host for the transfer of traffic. A path failure is handled by the routers in the network and the time to find a new path may take several seconds [5] if it is possible at all. Furthermore, a failure between the host and the first node