CC-SCTP: Chunk Checksum of SCTP for Enhancement of ...protocol.knu.ac.kr/pub/2007-tr.pdf · SCTP...

I. INTRODUCTION

The Stream Control Transmission Protocol (SCTP) is

a new reliable transport layer protocol [1]. Differently

from TCP, the SCTP provides the unique features of

multi-streaming and multi-homing [2]. The SCTP multi-

homing allows two endpoints to establish an association

using more than two IP addresses. This multi-homing

feature can be used for an SCTP endpoint to improve the

efficiency of the data transmissions by performing the

switchover to the redundant path in the event of a failure

of the primary path without interrupting data transfer.

On the other hand, the SCTP is designed based on the

window-based error and congestion control [3], as done in

TCP. In SCTP, the corruption of a packet is regarded as a

loss of the packet, which induces the retransmission

request of the packet and the decrease of the congestion

window at the sender side. This tends to result in the

degradation of SCTP throughput performance, in

particular, in the wireless networks with a high bit error

(corruption) rate. The works in [4] reveal that the SCTP

suffers the ''instability'' problem (a large throughput

oscillation in the short-term period) in the wireless multi-

hop networks.

It is noted that an SCTP packet carries only one

checksum in its common header. On reception of an

SCTP packet, if the checksum field indicates a corruption,

the entire packet will be discarded. However, an SCTP

packet may contain one or more data chunks in the packet.

Accordingly, a failure of the checksum in the common

header does not mean the universal corruption of all the

data chunks contained in the packet. That is, even in the

corruption case for a data packet, a certain data chunk

contained in the packet may be still delivered to the upper-

layer application successfully. Moreover, a corruption is

different from the loss (or congestion). Therefore, we may

avoid adjustment of the congestion window (cwnd) in the

corruption case, if we can determine that it is a corruption.

Several works have been done to improve the SCTP

throughput performance over lossy environments. The

work in [5] introduces a MAC-Error-Warning (MEW)

method with a new MAC packet type. The MEW method

690

Stream Control Transmission Protocol (SCTP) uses the 32-bit checksum in the common header, by which a

corrupted SCTP packet will be regarded as a lost packet and then discarded. This may result in degradation of

throughput performance in wireless network environments. This paper proposes a new chunk checksum scheme for

SCTP, called CC-SCTP, in which each data chunk contains its own checksum fields. The proposed chunk checksum

scheme is introduced with the following three purposes: 1) to distinguish the chunk corruption from the chunk loss; 2)

to avoid unnecessary halving the congestion window (cwnd) in the case of chunk corruption; 3) to avoid critical

timeouts caused by chunk corruption. Simulation results using the ns-2 simulator show that the proposed CC-SCTP

scheme could improve the SCTP throughput in the wireless network environments with a high bit error rate.

Keywords: SCTP, Chunk Checksum, Wireless Networks, Throughput

Lin Cui, Seok Joo Koh: Kyungpook National University

CC-SCTP: Chunk Checksum of SCTP for Enhancement of

Throughput in Wireless Network Environments

Lin Cui ·Seok Joo Koh

is similar to the Automatic Request (ARQ) mechanism

[6], but a special MAC packet is generated at the MAC

layer before the data chunk is discarded, which contains

some detailed information (including the stream ID and

the sequence number) to notify the upper layer of the

failed transmission. Arriving at the transport layer, the

MEW packet will be analyzed by the SCTP source and all

the useful information will be recovered so as to trigger

fast retransmission of the data without degrading the

congestion window.

The work in [7] utilizes the ECN [8] indications that

will be marked by an ECN-capable router, which is used

to detect the non-congestion packets loss. A packets loss

with no ECN message in the same data window will be

regarded as non-congestion errors, and then a simple loss-

recovery procedure will be executed without applying the

congestion control mechanism.

This paper proposes a data chunk-based checksum

scheme, called CC-SCTP ( 'CC' denotes Chunk

Checksum), which is purposed to extend the format of the

SCTP data chunk by adding a 'header checksum' and 'data

checksum'. The main purpose of the data chunk checksum

is to handle the chunk corruption differently from the

chunk loss for each data chunk, so that the congestion

window is not decreased unnecessarily. In addition, the

CC-SCTP is also purposed to prevent the SCTP

retransmission timer from being expired by corruption.

In the CC-SCTP scheme, if the overall checksum in the

common header fails (i.e., it indicates a corruption of the

SCTP packet), the SCTP receiver will check the integrity of

the header and data portions for each data chunk by

verifying the associated checksum fields. After that, the

successfully received data chunks, if any, will be delivered

to the upper-layer application. On the other hand, for each

corrupted data chunk, the associated SCTP Transmission

Sequence Number (TSN) value will be reported to the

sender via Selective ACK (SACK) chunk so as to request a

retransmission, together with a suitable timestamp value. It

is noted that this corruption-related TSN is used to request a

prompt retransmission to the sender, without either

shrinking the congestion window to half or waiting for the

retransmission timer to expire. In summary, the CC-SCTP

could be used to reduce the unnecessary retransmissions

and to avoid shrinking the congestion window to half as

well as unwanted timeouts caused by corruption.

The rest of this paper is organized as follows. Section

2 briefly reviews the existing related works on SCTP. In

Section 3, we describe the proposed CC-SCTP scheme.

Section 4 shows some simulation results for the proposed

scheme using the ns-2 networks simulator. Section 5

CC-SCTP: Chunk Checksum of SCTP for Enhancement of Throughput in Wireless Network Environments 691

Figure 1. Optional parameter in SCTP INIT and INIT-ACK chunks

port numbers and Verification Tag information, the header

checksum in the first data chunk must be responsible for

covering 12-byte packet's common header in addition to

its own 18-byte header portion. With the two checksum

values, the receiver could determine whether or not the

header and data fields are corrupted for each data chunk.

III. Error Recovery Algorithm inCC-SCTP

1. Generation of SACK Chunks by SCTP Receiver

On reception of an SCTP packet, the receiver will first

verify the integrity of the whole SCTP packet by checking

the overall checksum in the common header. In case that

the packet is corrupted, the receiver will then verify the

integrity of each data chunk contained in the packet in turn

by investigating the two additional checksums for each

data chunk.

The procedure of verifying the integrity of a data

chunk is composed of two phases: first checking the

header portion and then checking the data portion. Once

checking the header fails, if it is the first chunk, the

receiver will discard this packet since the common header

may contain some wrong information, whereas if it is not

the first one, the receiver only simply discards this data

chunk and then continues to check the next one. If the

integrity of header portion is verified, the data portion will

be checked then. Failure of the data checksum means that

concludes this paper.

II. PROPOSED SCTP CHUNKCHECKSUM

For compatibility with the standard SCTP, in the

proposed CC-SCTP, the source and the destination will

decide whether or not to use the proposed chunk-based

checksum option in the association by exchanging the

relevant information using the SCTP INIT and INIT-ACK

chunks in the association establishment phase.

Figure 1 shows an example format for the INIT and

INIT-ACK chunks to indicate whether to use the proposed

CC-SCTP scheme (that is, additional checksum fields for

data chunks). In the figure, as an example, the option

parameter '13' is used for the CC-SCTP.

We assume in this paper that the SCTP endpoints

agree to use two additional 16 bits for 1's complement

checksums. In other words, the sender will construct and

transmit each data chunk with the two additional

checksums, as shown in Figure 2.

As shown in the figure, we extend the format of SCTP

data chunk by including two additional checksum fields:

header checksum and data checksum. At the sender side,

the header checksum will be calculated by covering the

first 18-byte header fields of the data chunk (as indicated

with the red lines in the figure), while the data checksum

field will be filled by reflecting the rest portion (as shown

with the green lines in the figure). For ensuring the

integrity of the packet's common header which contains

692 Telecommunications Review·Vol. 17 No. 4·2007. 8

Figure 2. Data chunk with 16-bit checksum in the CC-SCTP

receiver side. It is noted that each corruption event should

be recorded in each subsequent SACK chunk. The detailed

use of this timestamp will be described in the next section.

Figure 4 shows the modified chunk format of SACK

chunk for the proposed CC-SCTP.

2. Retransmission by CC-SCTP Sender

Normally, the SCTP source uses the two different

the receiver has to append/update the associated TSN and

timestamp for the subsequent SACK chunk, while success

of the data check means the receiver needs to deliver the

data chunk to the application. The detailed checksum

procedure is illustrated in Figure 3.

After inspecting the chunk checksums for each data

chunk, the SCTP receiver will construct the subsequent

SACK chunk, including TSNs and timestamps. Herein, the

timestamp indicates when the corruption is detected at the


SCTP data packet

No

No

No

No

Yes

Yes

Yes

Yes

Yes

Process it as normal

Discards this packet

Continue as normal for the data chunk

Appends/Updates the TSN and timestamp for the subsequent SACK chunk

Constructs a SACK chunk and send it immediately

Figure 3. Checksum calculation by a CC-SCTP receiver

Figure 4. Proposed SACK chunk format

Checksum in commonHeader fails?

Header checksumfails?

Data checksumfails?

First data chunkof this packet? Discards this data chunk

Another data chunk?

IV. NUMERICAL RESULTS

We evaluate the proposed CC-SCTP scheme using the

ns-2 network simulator [9] over a simple test network, in

which two endpoints communicate through either a single

path (single-homing) or two non-overlapping paths (multi-

homing), as shown in Figure 7.

In the figure, the end-to-end paths are in the wired-

cum-wireless manner. Each wired link has the link

bandwidth of 10 Mbps and the transmission delay of

10ms, whereas the wireless link has the bandwidth of 2

Mbps and the transmission delay of 35ms. For each

experiment, we use the file transfer application using

SCTP over the ns-2 simulator.

To emulate the chunk corruption in the wireless

environments, we employ Gilbert model [10], as shown in

Figure 8, and we marked each corrupted packet with a

corruption flag instead of dropping it in the experiments.

In the model, two states of 'good' and 'bad' are

expressed in terms of transition probabilities p and q, and

average 'good' period of t1 seconds and 'bad' period of t2

seconds. If the link is in a 'good' state at present, it will

continue to stay in the 'good' state with probability p, or

transfer to the 'bad' state with a probability 1-p at the next

instance. In the Gilbert model, 'good' state means zero

error probability. Also, if the link is in a 'bad' state at the

current instance, then it will continue to stay in the 'bad'state with probability q, or transfer to the 'good' state with

a probability 1-q at the next instance. When the link is in

the 'bad' state, a SCTP packet experiences a packet


recovery schemes for a lost packet: namely timer-based

retransmission and fast retransmission. In the proposed

CC-SCTP scheme, however, the 'corruption' event will be

processed differently from the loss event, since the

corruption itself indicates an explicit retransmission

request.

By seeing the corruption-related TSN and

corresponding timestamp enclosed in SACK chunk, the

SCTP source can easily infer whether the corruption report

is for a new corruption event. If the source determines

that the corruption-related TSN and corresponding

timestamp reports a new corruption event, it will

retransmit the data chunk (i.e., the sender may retransmit

the same data chunk multiple times before retransmission

timer expires if it is corrupted repeatedly.).

Figure 5 shows the procedure of processing a SACK

chunk at the SCTP sender. In the figure, when the SCTP

sender receives a SACK chunk, it first checks whether

there is any corrupted TSNs enclosed in the chunk. If not,

the sender processes it as normal; If yes, it determines

whether it is a report for a new corruption event or not. If

it is a new corruption report, then the sender records the

TSN and timestamp for retransmission. If not, the sender

simply ignores it and continues to check the next

corruption report.

By means of the retransmission strategy, CC-SCTP

can greatly improve the throughput performance of SCTP.

Figure 6 shows an example traced in our CC-SCTP

simulations which may illustrate the proposed

retransmission strategy.

SACK chunk

Continues as normal

Nothing to do for it.

Retransmits corrupted data chunks together

Figure 5. SACK processing by CC-SCTP sender

Records the TSN and timestamp;Forwards the data chunk with the TSN to sending buffer.

Is there anyCorruption TSN?

Is it a new corruptionevent?

Another corrupted TSN?

No

No

No

Yes

Yes

Yes

corruption in the network with the probability β.

Table 1 summarizes the parameter values used for the

CC-SCTP experiments.

For each ns-2 experiment, every packet size is 1500

bytes and only one data chunk is contained. We

performed a file transfer application for 100 seconds and


compare the average throughput (Kbps) of CC-SCTP for

both the single-homing and multi-homing cases under the

following various test scenarios:

ⓐ for different packet corruption probability (β);

ⓑ for different time period of two states (t1, t2);

Time=3.06 103/cwnd=66060

Sender Receiver

data chunk(TSN=386)

x(corruption)

data chunk (TSN=387)



x (re-corruption)

SACK {Rax

request fo

r TSN=386

}

SACK {Rax

request fo

r TSN=386

with old t

imestamp

3.288781

}

SACK {Rax

request fo

r TSN=386

with rene

wed times

tamp 3.52

2781}

SACK{Rax

request fo

r TSN=386

with old t

imestamp

3.522781

}

Same TSN and same timestamp, no retransmission

Same TSN and same timestamp, no retransmission

Corruption report for TSN=386 disappears

Figure 6. An example packet flow of retransmissions by CC-SCTP

New corruption event with new TSN and new timestamp1stFasr retransmission: Time=3.331069/cwnd=66060

New corruption event and records itwith TSN=386&Timestamp=3.288781

Re-corruption event and updates it withTSN=386&renewed Timestamp=3.522781

TSN hole on 386 data chunk disappears;Removes related record from subsequent SACKs

Re corruption event with old TSN and renewed timestamp2nd Fasr retransmission: Time=3.565126/cwnd=66060

Single-homed:

Host1

Multi-homing:

Host2

wired

wired

10M 10ms

10M 10ms

Figure 7. Simulation topology

wireless

wireless

2M 35ms

2M 35ms

10M 10ms 2M 35ms

Two-state Gilbert Model

Host1 wired wireless Host2


ⓒ for the secondary (backup) path with packet corruption

probability (β);

ⓓ for the wired links with packet loss rates.

1. SCTP throughput for different corruption rates

Figure 9 shows the comparison of average throughput

between CC-SCTP and conventional SCTP for 100

seconds with the different corruption rates (β) from 0 to

0.5, given the other parameters as those in Table 1.

From the figure, we can see that the proposed CC-

SCTP schemes provide better throughput over the

conventional SCTP schemes for both the single-homing

and multi-homing cases. In particular, in the existing

SCTP single-homing case, the average throughput of

SCTP degrades drastically, as the corruption rate (β)

increases. On the contrary, the proposed CC-SCTP

scheme give better throughput, with the help of the

proposed chunk checksums and retransmission strategy.

This is because the CC-SCTP can successfully avoid the

adjustment of the congestion window size incurred by

timeouts and fast retransmissions due to corruption. That

is, the performance of the CC-SCTP is not sensitive to the

corruption rate, compared to the standard SCTP.

By comparison of single-homing and multi-homing

SCTP, the multi-homing SCTP provides better

performance than the single-homing case, since the multi-

homing SCTP can use the secondary path for

retransmission of corrupted data chunks. Overall, the

multi-homed CC-SCTP gives the best throughput over all

the test cases.

1-q

1-p

Figure 8. Two-state Gilbert model for Packet Corruption

p Good Bad q

250

200

150

100

50

0

SCTP-single

SCTP-multihoming

CC-SCTP-single

CC-SCTP-multihoming

0.0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50%

Packet Corruption Rate in Bad State

Average Throughput (KBytes/s)

Figure 9. SCTP throughput for different β values

Average Period

t1=2.5 seconds (variable)

t2=0.5 seconds (variable)

Transition Probability

p=0.9, (1-p)=0.1

(1-q)=0.7, q=0.3

Packet corruption Rate

α=0

β=0.25 (variable)

State

Good

Bad

Table 1. Parameter values used for experimentations


2. SCTP throughput for different time periods

Figure 10 shows the performance of CC-SCTP for

different time periods of the two states: good (t1) and bad

(t2). In the figure, given the base value of t1=2.5 second,

the t1 values vary from 10s (4 x t1), 5s, 2.5s, 1.25s,

0.625s. 0.3125s, 0.15625s and 0.078125s, respectively,

whereas given the base value of t2=0.5 second, the t2

values vary from 2s (4 x t2), 1s, 0.5s, 0.25s, 0.125s,

0.0625s, 0.03125s and 0.015625s, respectively.

From the figure, the results show that all the

experiments, other than the proposed CC-SCTP multi-

homing, are sensitive to the time periods of two states (t1

and t2). We can see that a shorter time period gives the

worse performance. In the figure, it is noted that the

proposed single-homed and multi-homed CC-SCTP

outperform both the existing SCTP (single-homing and

multi-homing). This is because the corruption does not

induce the shrink of the congestion window size in the

proposed scheme.

3. SCTP throughput for the secondary pathwith corruption

Figure 11 shows the results of SCTP for the secondary

path with corruption. In this scenario, we assume that the

secondary path of the SCTP could also experience the

250

200

150

100

50

0

4t1 2t1 t1 t1/2 t1/4 t1/8 t1/16 t1/324t2 2t2 t2 t2/2 t2/4 t2/8 t2/16 t2/32

Time periods of two states


Figure 10. SCTP throughput for different time periods of two states

SCTP-single

CC-SCTP-single

SCTP-multihoming

CC-SCTP-multihoming

200

150

100

50

04t1 2t1 t1 t1/2 t1/4 t1/8 t1/16 t1/324t2 2t2 t2 t2/2 t2/4 t2/8 t2/16 t2/32

Time periods of two states


Figure 11. Throughput for the SCTP secondary path with a corruption rate

SCTP-single

CC-SCTP

SCTP-multihoming-dualerror

CC-SCTP-multihoming-daulerror

packet corruption in the network. Note that in the

previous scenarios the secondary path did not have the

corruption rate. Based on the simulation environment of

Section 4.2, we apply the same two-state Gilbert model to

the secondary path of SCTP.

In the figure, we see that the proposed CC-SCTP

schemes still give better throughput than the standard

SCTP for both the single-homing and multi-homing cases.

This implies that the proposed CC-SCTP scheme could

give the performance gain in the networks with a high

corruption rate for the secondary path as well as the

primary path.

4. Throughput of SCTP in the networkswith packet losses

Finally, we compare the throughput of CC-SCTP in

the networks with some packet 'losses' in addition to the

packet corruptions. We apply a uniform error (loss) model

for the primary wired-link to generate the packet losses,

with the packet loss rate ranged from 0 to 0.1.

Figure 12 shows the throughputs of the SCTP in the

networks with the packet loss rates as well as the packet

corruptions.

In the figure, we can see that the proposed CC-SCTP

schemes provide the better throughput than the standard

SCTP for both the single-homing and multi-homing cases,

especially, when the packet loss rate is less than 2% in the

wired link, compared to the standard SCTP.

5. Discussion on additional overhead

Notice that the proposed scheme uses the two

additional checksum options, header checksum (2 bytes)

and data checksum (2 bytes), to the existing SCTP data

chunk format. This means that each data chunk has to

carry the small additional data payload (i.e., 4 bytes for

header and data checksums).

This additional overhead may seem to be unnecessary

in the error-free environments such as a fixed broadband

network. However, it is noted that the two end SCTP hosts

will negotiate whether or not the SCTP association uses

the additional 4-byte options in the association

establishment phase, as described in Section 2. That is,

the proposed scheme will be optionally used only for the

SCTP connection in which the two endpoints want to use.

V. CONCLUSIONS

In this paper, we propose the data chunk-based

checksum scheme, CC-SCTP, which is designed to

enhance the SCTP throughput even in the wireless

network environments with a high bit error (or corruption)

rate. From the simulation results, we can see that the

proposed CC-SCTP scheme provides better throughput

than the standard SCTP for both the single-homing and

multi-homing cases in the networks with a high bit error or

corruption rates. In particular, the proposed CC-SCTP

schemes give the better performance gain in the multi-

homing case.

It is noted that the performance gain of the proposed

CC-SCTP scheme comes from the following features: 1)

the proposed scheme can distinguish the chunk corruption

from the chunk loss by using the additional data chunk

checksums; 2) hence, the CC-SCTP scheme can avoid


250

200

150

100

50

0

SCTP-single

SCTP-multihoming

CC-SCTP-singleCC-SCTP-multihoming

0% 0.5% 1% 2% 3% 4% 5% 10%

Packet Corruption Rate in Bad State


Figure 12. Throughput of SCTP with different packet loss rates

unnecessary deflation of the congestion window in the

case of packet corruption; 3) in particular, the CC-SCTP

scheme could exploit a robust retransmission strategy to

avoid the timeouts caused by corruption.

AcknowledgementsThe authors give special thanks to the referees for their

valuable comments and suggestions. This research was

supported by the MIC of Korea, under the ITRC support

program supervised by the IITA (IITA-2006-C1090-0603-

0026).

[References][1] R. Stewart, et al., Stream Control Transmission

Protocol, IETF RFC 2960, Oct. 2000.[2] A. Caro, et al, ''Retransmission Policies with Transport

Layer Multihoming,'' Proceeding of the ICON 2003 Conference, 2003, pp. 255-260.

[3] M. Allman, et al., TCP Congestion Control, IETF RFC 2581, Apr. 1999.

[4] G. Ye, et al., ''SCTP Congestion Control Performancein Wireless Multi-hop Networks,'' Proceeding of the

MILCOM 2002 Conference, Oct. 2002, pp. 934-939.[5] D. Wang, et al., "A Mac-Error-Warning Method for

SCTP Congestion Control over High BER Wireless Network," Proceeding of the International Conference on Wireless Communications, Networking and Mobile Computing, Sep. 2005, pp. 513 - 516.

[6] S. Lin, et al., ''Automatic-repeat-request Error Control Schemes,'' IEEE Communications Magazine, Vol. 22, Dec. 1984, pp. 5-17.

[7] G. Ye, et al., "Improving Stream Control Transmission Protocol Performance Over Lossy Links", IEEE Journal on Selected Areas in Communications, Vol., Issue 4, May 2004, pp. 727-736.

[8] K. Ramakrishnan, et al., The Addition of Explicit Congestion Notification (ECN) to IP, IETF RFC 3168, Sep. 2001.

[9] Network Simulator (ns-2), Available from http://www.isi.edu/nsnam/ns/.

[10] E. N. Gilbert, ''Capacity of a burst-noise channel,''Bell Systems Technical Journal, Vol. 39, Sep. 1960, pp. 1253-1265.


Lin Cui

He received B.S. degree in Electronics Enineering from

Tianjin University, China, and M.S. degree in Computer

Engineering from KyungHee Unicersity, Korea, in 1989

and 2005, respectively. He is currently pursuing his Ph.D

degree in Computer Science from Kyungpook National

University, Korea. His research interests include Transport

Layer Protocols, Advanced Transfer Technologies for the

Next Generation Network, Mobile Communication and

Convergence of Heterogeneous Networks.

E-mail: [email protected]

Seok Joo Koh

He received B.S. and M.S. degrees in Management

Science from KAIST in 1992 and 1994 respectively. He

also received Ph.D. degree in Industrial Engineering from

KAIST in 1998. In 1998, he joined Protocol Engineering

Center in ETRI. Since 2004, he is now with the School of

Electronic Engineering and Computer Science in

Kyungpook National University. He has actively

participated in the standardization in ITU-T SG13, SG17,

SG19 and ISO/IEC JTC1 as an editor. His current research

interests include the mobility management, SCTP, and IP

multicasting.

E-mail: [email protected]

Tel +82-53-950-7356

Fax:+82-53-950-6369

CC-SCTP: Chunk Checksum of SCTP for Enhancement of ...protocol.knu.ac.kr/pub/2007-tr.pdf · SCTP...

Documents

Transcript of CC-SCTP: Chunk Checksum of SCTP for Enhancement of ...protocol.knu.ac.kr/pub/2007-tr.pdf · SCTP...