SF-SCTP: An Extension of Stream Control Transmission Protocol to Support QoS

Jianping Zou, M. Umit Uyar, Mariusz A. Fecko, Sunil Samtani

Abstract— Multiple streams in an SCTP association providean aggregation mechanism to accommodate heterogeneous ob-jects, which belong to the same application but may requiredifferent types of QoS from the network. However, the currentSCTP specification lacks an internal mechanism to support thepreferential treatment among its streams. Our work introducedthe concept of grouping SCTP streams into subflows based ontheir required QoS. We proposed to modify the current SCTPto implement subflows, each with its own flow and congestionmechanism to prevent the so-called false sharing. In this paper,we integrate Fractional Congestion Control into subflow-capableSCTP (SF-SCTP) to improve the fairness of SF-SCTP towardsthe original SCTP. The throughput performance evaluation ofSF-SCTP is studied through ns-2 experiments in a simplifiedDiff-Serv network. The results show that the proposed SF-SCTPdesign is able to support QoS among the SCTP streams and thatfalse sharing is avoided. The results also indicate that SF-SCTP ismore fair to the original SCTP after fractional congestion controlis integrated into the design.

I. INTRODUCTION

The Stream Control Transmission Protocol (SCTP) [6] isa reliable, message-oriented transport protocol operating ontop of potentially unreliable connectionless networks such asIP. Designed to overcome the shortcomings and limitationsof TCP, SCTP is more suitable for applications that requireadditional performance and reliability due to its new servicessuch as multi-homing, multi-streaming, message boundarypreservation, alleviated head-of-line blocking, and enhancedsecurity features. 1 2 3

Using independent streams in an SCTP association, SCTPdecouples the reliable data transfer from the strict order-of-transmission data delivery. The messages from the applicationlayer will be assigned to different streams according to therequirements of an SCTP user. Since ordered delivery is onlyneeded within each stream, if required, SCTP is able to re-duce the unnecessary head-of-line blocking between differentstreams. Multi-streaming equips SCTP with an internal mech-anism to support transmission of several objects concurrently.For example, the HTTP protocol using SCTP as the transportlayer could load a web page with multiple objects (e.g., JPG,voice, text and video) by opening only one SCTP associationinstead of several TCP connections.

1J. Zou and M.U. Uyar are with the City College and the Graduate Centerof the City University of New York, USA. M.A. Fecko and S. Samtani arewith Applied Research, Telcordia Technologies, Inc., Piscataway, NJ, USA.

2Prepared through collaborative participation in the Communications &Networks Consortium sponsored by the U.S. Army Research Lab underthe Collaborative Technology Alliance Program, Cooperative AgreementDAAD19-01-2-0011. The U.S. Government is authorized to reproduce anddistribute reprints for Government purposes notwithstanding any copyrightnotation thereon.

3Copyright c© 2005 Telcordia Technologies, Inc. and the City Universityof New York. All rights reserved.

The current SCTP employs a TCP-like congestion controlmechanism at the association level, which means the streamscarrying different objects are treated equally according tothe same congestion state information. Assuming that SCTPpackets could only bundle messages from the streams re-questing the same type of QoS, and that SCTP could markits packets with Differentiated Services Codepoints (DSCPs)so that the network will treat those packets differently (interms of packet loss rate, delay, etc.), the shared congestioninformation could result in the so-called false sharing [1].False sharing happens when flows sharing the congestioninformation do not actually share the same network bottleneck.The occurrence of false sharing could worsen the overallperformance of SCTP association. Since the transport layertries to moderate the performance for all streams, whenstreams have different packet drop rates, the performance ofthe higher priority streams will be penalized due to the sharedinformation from the lower priority streams. In the case wherestreams experience different round trip times (RTTs), falsesharing has catastrophic effects on SCTP performance in thatall streams, regardless of their priorities, will be penalized dueto unnecessary Fast Retransmits or time-outs.

Our earlier work introduced the concept of grouping streamsinto subflows to support preferential treatment of the SCTPstreams [9], [10]. Each subflow includes streams with thesame type of QoS requirement from the network. Dependingon the number of QoS types requested, an SCTP associationmay have one or more subflows. We also proposed that eachsubflow is an independent unit with respect to flow and con-gestion control. In this modified subflow capable SCTP (SF-SCTP), each subflow has its own flow and congestion controland consists of SCTP streams that require the same type ofQoS from the network. Depending on the QoS required, anSCTP association may have one or more subflows, which serveas the independent transmission channels between an SCTPcommunication peer. Since the congestion state information isonly shared by the SCTP streams requesting the same QoS,SF-SCTP design inherently avoids false sharing.

With the introducing of multiple-subflow communicationchannels, SF-SCTP is able to support QoS among SCTPstreams. However, due to multiple subflows, its behavior issimilar to the aggregation of concurrent SCTP associations.As a result, SF-SCTP has a much faster growing CongestionWindow (cwnd) and is more resistant to packet losses, whichmakes SF-SCTP more aggressive than the original SCTP.As the number of subflows increases, the SF-SCTP behaviorgets more aggressive, thereby having a negative impact ofincreasing packet drop rates in the network [2]. Our SF-SCTPmay thus perform better in terms of its throughput by unfairlyharming other traffic in the network. To alleviate the over-

780

aggressiveness of SF-SCTP, in this paper, we introduce to SF-SCTP a mechanism called fractional congestion control (FCC)(first suggested for TCP [3], [4]). FCC reduces the aggressive-ness of SF-SCTP by increasing the subflow’s cwnd slower thanthe original SCTP in congestion avoidance phase.

The performance evaluation of SF-SCTP with FCC inte-grated is studied through ns-2 [7] simulation experimentsunder an idealized Diff-Serv network. Subflows travellingthrough the Diff-Serv network may experience different packetdrop rates or RTTs. The simulation results illustrate thenegative effects of false sharing and show that SF-SCTP avoidsthis phenomenon; therefore, SF-SCTP is able to provide pref-erential treatment among its streams. The simulation resultsalso point out that, for a network where no QoS is providedand packet losses are due to link errors rather than congestion,SF-SCTP with FCC can achieve near total fairness towardsthe original SCTP. The simulation results confirm as well theaccuracy of our analytic models derived in Refs. [9], [10].

II. RELATED WORK

False sharing can severely impair the performance of anend-to-end system that shares congestion control informationacross multiple concurrent flows. Ref. [1] has investigated theorigin and impact of false sharing on TCP performance. Falsesharing occurs in networks with QoS enhancements wherea flow classifier segregates flows into different queues, orin networks with path diversity where different flows to thesame destination are routed differently [1]. Their simulationresults show that faster applications are heavily penalized as aresult of false sharing. Without a separate flow and congestioncontrol for each subflow in SF-SCTP, the benefits of a networksupporting QoS might be forfeited due to transport layer’sunawareness of QoS and inability to avoid false sharing.

To address the unfairness of competing aggregate TCPflows towards a single TCP flow, the concept of fractionalcongestion control is introduced in Refs. [3], [4]. Comparedto a single TCP flow, the aggressiveness of multiple parallelTCP flows is due to a faster cwnd growth rate and a largerresistance to loss. Parallel TCP flows compete unfairly towardsa single flow in that they open their congestion windowsn (the number of flows) times faster. When packet losses occur,parallel flows absorb the losses over the affected flows, whileallowing the rest of the flows to continue normal operation.For high speed networks where packet losses result exclusivelyin Fast Retransmits, parallel TCP flows could achieve a fairthroughput towards a single flow given that each one of theparallel flows increase its cwnd 1

n2 times slower [3], [4].Since the behavior of our SF-SCTP design is similar to anaggregated group of original SCTP flows, we could also applythe fractional congestion control mechanism to SF-SCTP toimprove its fairness towards the SCTP.

III. SF-SCTP DESIGN

Our work [9], [10] proposed an earlier version of SF-SCTPwithout FCC integrated, an extended SCTP implementationthat is able to meet different QoS requirements of streams.

Flow & CongestionControl for SF #1

Message

Message

MessageStream #1 DSCP=20H

Message

Message

MessageStream #2 DSCP=20H

Message

Message

MessageStream #3 DSCP=40H

Message

Message

MessageStream #4 DSCP=40H

Flow

Mapping Flow & Congestion

Control for SF #2

ApplicationLayer SCTP Association Layer

Association startup, maintenance & teardown (Shared by All SFs)

Association Path Management (Shared by All SFs)

SF Management ModuleScheduler

IPNetwork

Fig. 1. Architectural Overview of SF-SCTP Design (SF = subflow).

In SF-SCTP, streams are grouped into subflows based ontheir QoS requirements, and only messages coming from thesame subflow could be bundled together. Flow and congestioncontrol are migrated from the association to subflow level toavoid false sharing or any other possible interactions betweensubflows. Some common functionalities such as associationstartup, maintenance, tear-down, and path monitoring areshared by all subflows and provided at the association level.

The introduction of subflow and individual congestion con-trol modifications requires the modification of the formats ofSCTP data chunk, Selective Acknowledgement (SACK), Initi-ation, Initiation Acknowledgement, Cookie Echo and CookieAcknowledgement control chunks. The detail descriptions forthe new chunk formats of SF-SCTP can found in our earlierwork [9], [10].

Fig. 1 shows an instance of the SF-SCTP implementationand provides the architectural overview for our design. TheSF-SCTP association in Fig. 1 has four streams of messages.Streams 1 and 2 require the same QoS with a DSCP value of20H, while streams 3 and 4 require the service DSCP of 40H.Based on the DSCP markings, the flow mapping module ofSF-SCTP assigns streams 1 and 2 into subflow 1 and streams3 and 4 into subflow 2. The separate flow and congestioncontrol parameters for both subflows are stored in the SubflowManagement Module (SMM).

SMM is the central collector and processor of subflows’newest flow and congestion control state information. Theindependent flow and congestion control for each subflow inSF-SCTP are supported by the separated state information inSMM. In SMM’s internal table, a separate set of flow and con-gestion parameters are maintained and updated timely for eachsubflow. These include Congestion Window, Advertised Re-ceiver Window Size, Slow Start Threshold, Smoothed Roundtrip Time, Retransmission time-out, Transmission SequenceNumber, etc.

Packets from all subflows are regulated by a scheduler be-fore being injecting into the network. We implement the First-Come First-Served (FCFS) scheduling algorithm for SF-SCTP,which provides no bias against subflows. The throughput dif-ference between subflows is due to the differentiated services

781

provided to the subflows from the networks. Currently, SF-SCTP is able to support QoS inside an SCTP association, butdoes not provide internally any kind of QoS.

The elegance of our SF-SCTP design lies in the inclusionof SMM and scheduler for regulating data transmission. Thisdesign provides ample flexibilities to extend the SF-SCTPto support additional functionalities. For example, by usingPriority Scheduling or Multilevel Queue Scheduling insteadof FCFS in the scheduler and modifying SMM appropriately,SF-SCTP can provide internal QoS for subflows. Also propercooperation among subflows can be realized by enhancingthe SMM and scheduler implementation, which will not bediscussed in detail since it is beyond the scope of this paper.

Compared to the original SCTP, SF-SCTP without FCC hasa much faster cwnd growth rate and a greater resistance topacket losses [3], [4]. During the congestion avoidance period,the cwnd of each subflow increases by 1 ∗ MTU per RTT ifthere is no packet loss, which implies that the overall cwnd ofthe whole association will increase by n ∗ MTU per RTT (nrefers to the number of subflows). When there is a packet lossdetected by an SCTP association, the cwnd of the originalSCTP is reduced to half after a Fast Retransmit. However, forSF-SCTP, its overall cwnd will only reduce to (2n−1)/2n ofits previous value since only one subflow is affected by thispacket loss. Benefiting from its faster cwnd growth rate andthe fact that it can absorb packet losses to partial subflows,the SF-SCTP presented in our earlier work [9], [10] competesunfairness against the original SCTP even when the networkdoes not provide QoS. As the number of subflows in SF-SCTPincreases, this unfairness problem becomes more severe.

In this paper, we introduce FCC [3], [4] into SF-SCTP toalleviate the unfairness between SF-SCTP and the originalSCTP. Under the premise of FCC, the cwnd of each subflowincreases only 1∗MTU per Φ RTTs, where Φ is the subflow’swindow growth parameter directly related to n and adjustableto make SF-SCTP fair to the original SCTP. The larger Φ is,the slower a subflow’s window growth rate becomes. To ensurefairness, Φ must be greater than n so that the overall cwndof SF-SCTP increases less than 1 ∗ MTU per RTT to offsetSF-SCTP’s greater resistance to packet losses.

IV. ANALYTIC MODELS

In this section, we present SCTP analytic models in asimplified Diff-Serv network where each DSCP is mapped toa unique packet drop rate and RTT. In this network, the flowswith different DSCPs shall experience different packet droprates and RTTs after reaching steady state since the networktreats each flow with different priorities. In this section, wedescribe the stochastic analytic models for the following threeimplementations of the SCTP:• Original SCTP: The current SCTP specified in RFC 2960

which has no subflow modification and is unaware of QoS.• SF-SCTP: The modified SCTP with subflows, each imple-

menting its own flow and fractional congestion control.• SF-SCTP-shared: The SCTP with subflows, all sharing flow

and congestion control at the association level; a Weighted

1 … Time (RTT)

subflow’s cwnd (MTU)

21

ijW −

2

ijW

ijW

ijX

ΦFast Retransmit Period

thi

thj

… Φ

Packetloss

ijβ

1+ijX

Fig. 2. Simplified cwnd behavior of SFi in the congestion avoidance period

Round-Robin (WRR) scheduler is used to apportion theachieved bandwidth among subflows.The accuracy of an SCTP throughput analytic model de-

pends on how well it captures the congestion control behaviorof the SCTP. For example, considering the ith subflow (SFi)in SF-SCTP, the SFi increases its cwnd exponentially duringthe slow start period, and linearly (one MTU per Φ RTTs)during the congestion avoidance period. On the detection ofa packet loss, the cwnd of SFi is reduced to half for a FastRetransmit event, or to one MTU for a time-out event. Whenthe packet losses result exclusively in Fast Retransmits, thecongestion behavior of SFi can be simplified in a way asshown in Fig. 2, which captures only the congestion avoidanceperiods and Fast Retransmit events of SFi.

Starting from Ref. [5], and considering the differencesbetween the SCTP and TCP-Reno congestion control [8], ourearlier work [9], [10], without the consideration of factionalcongestion control, obtained the the analytic expression for thethroughput of SFi in SF-SCTP as

Bi(pi)M

=6ηi + 2pi

(ξ +

√ξ2 + 24ηi

pi

)

pi

(6 + ξ +

√ξ2 + 24ηi

pi

)RTTi

(1)

≈ 1RTTi

√3ηi

2pifor small pi (2)

where ξ = 3 − ηi, pi is the packet drop rate, M is the MTUsize of the network, ηi = Ki

M , Ki is the packet size for SFi.For SF-SCTP with FCC addition, it can be proved that the

throughput expression for SFi becomes

Bi(pi)M

=6ηi + 2pi

(� +

√�2 + 24Φηi

pi

)

pi

(6 + � +

√�2 + 24Φηi

pi

)RTTi

(3)

≈ 1RTTi

√3ηi

2Φpifor small pi (4)

where Φ is the subflow’s window growth parameter and � =2 + Φ − ηi.

The throughput for the entire SF-SCTP association,Bsf−sctp, is the sum of all subflows’ throughput:

Bsf−sctp

M=

n∑i=1

Bi(pi)M

≈n∑

i=1

1RTTi

√3ηi

2Φpi(5)

782

When all subflows have the same packet size ηi = η, thesame packet drop rate pi = p, and the same round trip timeRTTi = RTT , Eq. (5) becomes

Bsf−sctp

M≈ n

RTT

√3η

2Φp(6)

When SF-SCTP has only one subflow, it becomes equivalentto the original SCTP, whose throughput is obtained from (5):

Borig−sctp

M≈ 1

RTTo

√3ηo

2po(7)

where ηo, RTTo and po are the packet size over MTU, RTTand packet drop rate for the original SCTP, respectively.

Comparing the original SCTP with SF-SCTP using Eqs. (6)and (7), we find that, when Φ = n2, SF-SCTP achieves thesame throughput as the SCTP, for equal η, RTT and p values.This result implies that, when SF-SCTP increases its overallcwnd by 1/n ∗ MTU per RTT , it reduces its aggressivenessand becomes fair to the original SCTP.

To illustrate the deteriorating effect of false sharing onSCTP throughput, SF-SCTP-shared, where all subflows shareone flow and congestion control, has been studied in Ref. [9].In SF-SCTP-shared, a WRR scheduler is employed to appor-tion the throughput among subflows, with λi representing thepercentage of the bandwidth assigned to SFi. Assuming thatλi and pi are known, the average packet drop rate of SF-SCTP-shared can be expressed as psh =

∑ni=1 λipi.

Refs. [9] define the equivalent packet drop rate psh fromthe derivation of the expected value of αsh, which representsthe number of packets sent in a Fast Retransmit period up toand including the first packet lost:

E[αsh] =1

psh≈ 1

psh(8)

Ref. [9] prove that, for small packet drop rates, we can usethe average packet drop rate psh to compute the throughputfor SF-SCTP-shared as

Bsf−sctp−shared

M≈ 1

RTTsh

√3ηsh

2psh(9)

Eq. (9) presents the throughput model for SF-SCTP-sharedwhere all subflows have the same RTTs. If the RTTs are notthe same, unnecessary Fast Retransmits and time-outs, whichare due to unordered packet arrivals at the SCTP receiver, maycause the actual throughput to be much lower than the analyticresult given by Eq. (9).

V. SIMULATION EXPERIMENTS

In this section, we report the results of the simulation ex-periments conducted on the ns-2 [7] platform. We implementour SF-SCTP by extending the ns-2 SCTP module defined byRFC 2960. With the differentiated services provided by theDiff-Serv network shown in Fig. 3, two simulation experimentshave been performed to study SF-SCTP’s capability to supportQoS among its streams.

HostA

Diff-ServDiff-Serv

HostB

ER2

CR1

CR2

ER1 CR3

Path 1P1

RTT1

Path 1P1

RTT1

Path 2P2

RTT2

Path 2P2

RTT2

BWBW

Fig. 3. Simulation topology to investigate SF-SCTP’s ability to support QoS

The simulation topology in Fig. 3 consists of Host A(sender), Host B (receiver), and a simplified Diff-Serv net-work between them. There may be one or multiple SCTPassociation(s) running concurrently between Hosts A and B.For simplicity, no delayed-SACK is used for all SCTP associ-ations. The ER1 (Edge Router 1) in the Diff-Serv network isable to map traffic coming from Host A to two different pathsaccording to the marked DSCPs. Packets travelling through thetwo paths will experience different link error rates (namely, p1

for path-1, p2 for path-2), and RTTs (RTT1 for path 1, RTT2

for path 2). In our simulation setting, path 2 in Fig. 3 alwayshas a higher priority than path 1 with respect to RTT or packetdrop rate, which equals the link error rate in our experiments.

The Diff-Serv network in Fig. 3 is configured as a highspeed one and has almost infinite resources available suchthat adding or removing an SCTP association shall not affectthe packet drop rates and RTTs. It has been observed in oursimulations that all packet losses in this network result in FastRetransmits. Since every lost packet is recovered by a FastRetransmit, we define the notion of Fast Retransmit rate that,from the SCTP sender’s point of view, is an effective indicationof the packet drop rate it experienced. Fast Retransmit rate isobtained by dividing the number of Fast Retransmits over thetotal number of packets transmitted during a simulation.

The Diff-Serv network configurations for the two simulationexperiments are as follows:� Experiment I (effect of different packet drop rates): Thetwo paths between Hosts A and B have the same RTTs(RTT1 = RTT2 = 0.5 sec), but different packet drop rates.For each simulation, path 1 has a fixed packet drop ratep1 = 10−3, while p2 of path 2 varies from 10−5 to 10−3.Four instances of SCTP associations: original SCTP, SF-SCTPwithout FCC (Φ = 1), SF-SCTP with FCC (Φ = n2) and SF-SCTP-shared, are established between Hosts A and B. Theoriginal SCTP, which is unaware of QoS, is mapped to path 1with a higher packet drop rate of p1. Both the SF-SCTP andSF-SCTP-shared associations contain two subflows, SF1 isassigned to path 1 and SF2 to path 2. For SF-SCTP-shared,where the subflows share flow and congestion control, theWRR scheduler apportions each subflow with 50% of theachieved throughput. Since both paths have the same RTTs,packets coming from the two subflows of SF-SCTP-sharedare delivered in order at the SCTP receiver even though theytravel through different paths. This ordered delivery effectivelyavoids unnecessary Fast Retransmits.

783

0

100

200

300

400

500

600

700

800

900

-5-4.9-4.8-4.7-4.6-4.5-4.4-4.3-4.2-4.1-4-3.9-3.8-3.7-3.6-3.5-3.4-3.3-3.2-3.1-3

Drop Rate P2 (Log10 Scale)

Thro

ughp

ut(P

acke

tspe

rse

c)

SF1 of SF-SCTP without FCC (ns-2)SF1 of SF-SCTP without FCC (analytic)SF2 of SF-SCTP without FCC (ns-2)SF2 of SF-SCTP without FCC (analytic)SF1 of SF-SCTP with FCC (ns-2)SF1 of SF-SCTP with FCC (analytic)SF2 of SF-SCTP with FCC (ns-2)SF2 of SF-SCTP with FCC (analytic)SF-SCTP-shared (ns-2)SF-SCTP-shared (analytic)

(a) Experiment I.

0

50

100

150

200

250

300

0.5 0.53 0.55 0.58 0.6 0.63 0.65 0.68 0.7 0.73 0.75 0.78 0.8 0.83 0.85 0.88 0.9 0.93 0.95 0.98 1

RTT of Path 1 (Second)

Thro

ughp

ut(P

acke

tspe

rse

c)

SF1 of SF-SCTP without FCC (ns-2) SF1 of SF-SCTP without FCC (analytic)SF2 of SF-SCTP without FCC (ns-2) SF2 of SF-SCTP without FCC (analytic)SF1 of SF-SCTP with FCC (ns-2) SF1 of SF-SCTP with FCC (analytic)SF2 of SF-SCTP with FCC (ns-2) SF2 of SF-SCTP with FCC (analytic)SF-SCTP-shared (ns-2) SF-SCTP-shared (analytic)

(b) Experiment II.

Fig. 4. Flow throughput for SF-SCTP-shared and SF1, SF2 of SF-SCTP.

� Experiment II (effect of different RTTs): The packet droprates for both paths are fixed at p1 = p2 = 10−4. Thedifferentiated services of paths 1 and 2 are provided by thedifferent RTTs, RTT2 is fixed at 0.5 sec, while RTT1 is variedbetween 0.5 sec to 1 sec.

Experiments I and II are designed to study the throughputdifferences of original SCTP, SF-SCTP and SF-SCTP-sharedunder different packet drop rates or RTTs. The simulationresults and the corresponding analytic expectations for thoseresults are presented in Figs. 4, 5 and 6. Fig. 4 illustrates theflow throughput differences of SF-SCTP-shared with SF1 andSF2 of SF-SCTP. Fig. 5 compares the association throughput,while Fig. 6 compares the Fast Retransmit rates of the originalSCTP, SF-SCTP and SF-SCTP-shared.

The results in Fig. 4 confirm the capability of SF-SCTP tosupport preferential treatment among its subflows, regardlessof whether or not FCC is used. Since all subflows in SF-SCTPhave their own flow and congestion control, each subflowcan adapt to the dynamic change of network characteristicswithout affecting the others. When the two paths have the samedrop rates and RTTs, we observe from Figs. 4(a) and 4(b)that SF1 and SF2 of SF-SCTP achieve approximately thesame throughput. As the Diff-Serv network starts to provide

50

150

250

350

450

550

650

750

850

950

-5-4.9-4.8-4.7-4.6-4.5-4.4-4.3-4.2-4.1-4-3.9-3.8-3.7-3.6-3.5-3.4-3.3-3.2-3.1-3

Drop Rate P2 (Log10 Scale)

Th

rou

gh

pu

t(P

acke

tsp

erse

c)

SF-SCTP without FCC (ns-2)

SF-SCTP without FCC (analytic)

SF-SCTP with FCC (ns-2)

SF-SCTP with FCC (analytic)

SF-SCTP-shared (ns-2)

SF-SCTP-shared (analytic)

Original SCTP (ns-2)

Original SCTP (analytic)

(a) Experiment I.

0

50

100

150

200

250

300

350

400

450

500

550

0.5 0.53 0.55 0.58 0.6 0.63 0.65 0.68 0.7 0.73 0.75 0.78 0.8 0.83 0.85 0.88 0.9 0.93 0.95 0.98 1

RTT of Path 1 (Second)

Thro

ughp

ut(P

acke

tspe

rse

c)

SF-SCTP without FCC (ns-2) SF-SCTP without FCC (analytic)SF-SCTP with FCC (ns-2) SF-SCTP with FCC (analytic)SF-SCTP-shared (ns-2) SF-SCTP-shared (analytic)Original SCTP (ns-2) Original SCTP (analytic)

(b) Experiment II.

Fig. 5. Association throughput for SCTP, SF-SCTP and SF-SCTP-shared.

differentiated services among the two paths by either reducingthe packet drop rate of path 2 or increasing the RTT of path 1,SF2 begins to outperform SF1. From Fig. 4(a), we can tellthat the throughput of SF2 increases while the throughputof SF1 remains relatively constant when the drop rate ofpath 2 is reduced. SF2 gets roughly 10 times the throughputas SF1 when p2 = 10−2 ∗ p1 = 10−5. From Fig. 4(b), weobserve that, as the RTT of path 1 increases, the throughputof SF1 decreases while the throughput of SF2 remains almostunchanged. SF2 obtains about twice the throughput of SF1

when RTT1 = 2 ∗ RTT2 = 1 sec.The comparison of SF-SCTP with SF-SCTP-shared in

Figs. 4, 5 and 6 tells us SF-SCTP’s ability to support QoSpartially lies in the fact that it avoids false sharing byimplementing separate flow and congestion control for eachsubflow. From Fig. 6(a) of Experiment I, where both pathshave the same RTTs, we see that SF-SCTP-shared’s FastRetransmit Rate is close to the average packet drop rates ofSF1 and SF2 of SF-SCTP. This observation confirms ouranalytic models, which imply that, for SF-SCTP-shared, wecould use the subflows’ weighted average packet drop rate asthe equivalent packet drop rate when all subflows in SF-SCTP-shared have the same RTTs. In Experiment II where the two

784

-4.1

-4

-3.9

-3.8

-3.7

-3.6

-3.5

-3.4

-3.3

-3.2

-3.1

-3

-2.9

-5-4.9-4.8-4.7-4.6-4.5-4.4-4.3-4.2-4.1-4-3.9-3.8-3.7-3.6-3.5-3.4-3.3-3.2-3.1-3

Drop Rate P2 (Log10 Scale)

Fast

Ret

rans

mit

Rat

e(L

og10

Sca

le)

SF-SCTP without FCC (ns-2)SF-SCTP without FCC (analytic)SF-SCTP with FCC (ns-2)SF-SCTP with FCC (analytic)SF-SCTP-shared (ns-2)SF-SCTP-shared (analytic)Original SCTP (ns-2)Original SCTP (analytic)

(a) Experiment I.

-4.4

-4.2

-4

-3.8

-3.6

-3.4

-3.2

-3

-2.8

-2.6

-2.4

-2.2

-2

-1.8

-1.6

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

RTT of Path 1 (Second)

Fas

tR

etra

nsm

itR

ate

(Lo

g10

Sca

le)

SF-SCTP without FCC (ns-2)

SF-SCTP with FCC (ns-2)

SF-SCTP-shared (ns-2)

Original SCTP (ns-2)

Analytic drop rate for all four SCTPs

(b) Experiment II.

Fig. 6. Fast Retransmit rate comparison for the original SCTP, SF-SCTPand SF-SCTP-shared.

paths have different RTTs, we see that SF-SCTP-shared’s FastRetransmit Rate is much higher than the subflows’ weightedaverage packet drop rate (Fig. 6(b)). The unequal RTTs andthe falsely shared congestion control in SF-SCTP-shared leadto the unnecessary occurrences of Fast Retransmits. Thissevere degree of false sharing could cause SF-SCTP-shared’sthroughput to be much lower than the analytic expectation, asshown in Figs. 4(b) and 5(b).

From Figs. 4 and 5, we find that SF-SCTP with FCCalways achieves about half the throughput of SF-SCTP withoutFCC. When the two paths of the Diff-Serv network havethe same packet drop rates and RTTs, SF-SCTP with FCCobtains approximately the same throughput as the originalSCTP. This observation suggests that, in a network where linkerrors dominate, SF-SCTP with FCC can achieve a near totalfairness towards the original SCTP when the subflow’s windowgrowth parameter is set at a proper value. Compared with theoriginal SCTP, the slower overall cwnd growth rate of SF-SCTP with FCC counteracts its greater resistance to packetlosses. This behavior is due to the multiple subflows: whenΦ = n2, SF-SCTP stops being over-aggressive.

Except for SF-SCTP-shared, of which we can only predict

the throughput upper limit, we observe in Figs. 4, 5, and 6 thatour analytic models accurately reflect the congestion behaviorof the original SCTP and SF-SCTP. These models are derivedbased on a few idealized assumptions [9], [10], and they donot capture SCTP’s time-outs or consecutive Fast Retransmitsevents. The experiments conducted under the simplified Diff-Serv network, where no occurrences of time-out or consecutiveFast Retransmits have been observed, confirm the accuracy ofour analytic models and justify the assumptions made duringthe derivation procedure.

VI. CONCLUDING REMARKS

When SCTP’s multi-streaming was originally introduced,supporting QoS inside an SCTP association was not a concern.We proposed to modify the current SCTP specification tosupport preferential treatment of SCTP streams. We dividedan association into several subflows based on the requiredQoS such that each subflow has its own flow and congestioncontrol parameters in order to avoid false sharing. In this paper,we introduce FCC into SF-SCTP and conduct simulationexperiments to study its behavior in a Diff-Serv network. Thesimulation results prove the SF-SCTP’s capability to supportQoS among its streams, confirm the accuracy of the analyticmodels, and justify our effect to integrate FCC into SF-SCTP since it improves the fairness between SF-SCTP andthe original SCTP.4

REFERENCES

[1] A. AKELLA, H. BALAKRISHNAN, AND S. SESHAN. The impact of falsesharing on shared congestion management. In Proc. IEEE Int’l Conf.Netw. Protocols (ICNP), pp. 84–94, Atlanta, GA, 2003.

[2] S. FLOYD AND K. FALL. Promoting the use of end-to-end congestioncontrol in the Internet. IEEE/ACM Trans. Netw. 7, pp. 458–472, 1999.

[3] T.J. HACKER, B.D. NOBLE, AND B.D. ATHEY. The effects of systemicpacket loss on aggregate TCP flows. In Proc. ACM/IEEE Conf.Supercomput., pp. 7–21, Baltimore, MD, 2002.

[4] . Improving throughput and maintaining fairness using parallelTCP. In Proc. IEEE INFOCOM, pp. 2480–2489, Hong Kong, 2004.

[5] J. PADHYE, V. FIROIU, D. TOWSLEY, AND J. KUROSE. Modeling TCPthroughput: A simple model and its empirical validation. In Proc. ACMSIGCOMM, pp. 303–314, 1998.

[6] R. STEWART, Q. XIE, K. MORNEAULT, C. SHARP,H. SCHWARZBAUER, T. TAYLOR, I. RYTINA, M. KALLA, L. ZHANG,AND V. PAXSON. Stream Control Transmission Protocol. RFC 2960,IETF, 2000.

[7] UC Berkeley and LBL and USC/ISI and Xeror Parc. NS-2 documenta-tion and software, Version 2.27, 2004. (http://www.isi.edu/nsnam/ns).

[8] Z. YI, T. SAADAWI, AND M. LEE. Analytic model of Stream ControlTransmission Protocol. In Proc. Int’l Wksp Perform. Model. Comput.Commun. Syst. (PMCCS), Monticello, IL, 2003.

[9] J. ZOU, M.U. UYAR, M.A. FECKO, AND S. SAMTANI. Preferentialtreatment of SCTP subflows: Analysis and simulation. In Proc. IEEEInt’l Symp. Comput. Commun. (ISCC), pp. 810–815, Alexandria, Egypt,2004.

[10] . SCTP subflows for survivable FCS applications. In BattlespaceDigitization and Network-Centric Systems IV, Proc. SPIE 5441, pp. 192–203. (SPIE, Bellingham, WA), 2004.

4The views and conclusions contained in this document are those of the au-thors and should not be interpreted as representing the official policies, eitherexpressed or implied, of the Army Research Lab or the U.S. Government.

785