Performance of SCTP(Stream Control

Transmission Protocol)

Student: Elvis Pfützenreuter

Advisor: Prof. Luis Fernando Friedrich, Ph.D

Why do we need another transport protocol?

● TCP: reliable stream of bytes● UDP: unreliable datagrams● No reliable atomic message transmission● No variable degrees of reliability (only all or nothing)● Several channels or streams in one connection

IP / IPv6

TCP UDP ???

Link layer

SCTP history● SIGTRAN comittee wanted a transport protocol for

SS7● MDTP (Multinetwork Datagram Transmission

Protocol): did what SIGTRAN wanted, but it ran over UDP

● MDTP evolved until becoming SCTP that is a transport protocol

IP / IPv6

UDP

MDTP

IP / IPv6

UDP

SCTP

IP / IPv6

SCTP

Associations and streams● SCTP association: analogous to TCP conn.● Streams: unidirectional channels for message

transmission (up to 2^16 per direction)● Number of streams negotiated at connection

initiation

Terminal Terminal

Streams

Atomic messages● Sent and received atomically (always at once)● Can be bigger than a datagram (if implementation

allows)● Application may ignore message boundaries● Delivery order is obeyed only within each stream

(avoids HOL Blocking)

Fluxos

Msg #1Msg #2Msg #3Msg #4

Msg #1Msg #2Msg #3

lost

Msg #3Msg #3

Wait msg#1 retransmission

Partial reliability● “urgent” messages● Messages with time to live (deadline)● What about unreliable messages?● PR-SCTP (Partial Reliability SCTP) extension:

redefines time to live● All types may go through the same stream

Msg #1Msg #2 urgentMsg #3

lostWaits #1retransm.

Delivered as soon as it

arrives

Multihomed associations● Multihomed computer: connected to a TCP/IP

internetwork by two or more ways● SCTP offers automatic fail-over in this case● RivuS extension also allows load balancing● Inexpensive network redundancy without having to

be an AS (Autonomous System)

Terminal

Terminal

Inter-rede(e.g. Internet)

Link 1

Link 2

Link 1

Link 2

Link 3

More SCTP details● No half-open state, immune to blind spoof and

SYN flood● Checksum is 32 bits (CRC32c)● Congestion control exactly like TCP● Architecture of TLV structures instead of bitmaps● API BSD Sockets: TCP and UDP style

Type Length Value

Type (8b) Flags (8b) Valule – 32-bit alignedLength (16b)

Work objectives

Find oportunities of using SCTP in place of TCP or UDP in preexisting application protocols

Performance tests: raw data and with application protocols (HTTP, SMB, RTP)

Offer examples of SCTP API Sockets usage

Feedback to LK-SCTP maintainers

•SCTP use cases

● In place of TCP● Atomic messages● Multiple connections belonging to a single

transaction● Better security● Multipath

● In place of UDP● SCTP has no broad/multicast!● Some real-time multimedia apps.

•Performance SCTP x TCP● Implementations: SCTP and TCP present in

standard Linux 2.6.9 ● Test validity issues● Latency and throughput tests with reliable

messages● TCPM and UNIXM: application protocols for simple

message separation in TCP e UNIX

Byte 0xEE Payload byte 0xFF

TCPM application proto

IP / IPv6

TCP SCTP

TCPM

Tests applied in these points

•Loopback - throughput● Message size is varied● TCP: performance well over SCTP (9x to

4x). Causes:● CRC-32c (is NOT the bottleneck)● Message separation● Memory-to-memory data copies● Context switches● Unfair comparison● TLV overhead

● TCPM: throughput about the same as UNIXM and SCTP

•Loopback – latency

● Message size is varied● Latency SCTP 2x worse than TCPM● Serialization of all latencies● Library lksctp-tools deemed NOT guilty● SCTP extra latency is inside the kernel

•100Mbps● Message size is varied● SCTP throughput below TCP and TCPM

(even 10x less for 10-byte message)● Problems with SCTP Chunk bundling

● Difference gets narrower as the message size increases (1000 bytes or more)

● SCTP latency 25% bigger than TCPM ● All next texts use 500-byte messages

•100Mbps, loss 0% to 10%● SCTP throughput better than TCPM for

network losses >1%● SACK of SCTP worked well, but...● SCTP latency was bad for losses >1%

● Minimum and initial RTOs set default too high (1000ms) but can be tuned

● TCP-inherited congestion control● Tuned RTOs deliver same performance as

TCP● Still needs more tests

•10Mbps latency from 5ms to 300ms● SCTP throughput 15% less than TCPM● Throughput of both protocols fall and

difference narrows as network latency increases● Cause: untuned reception buffer

● TCPM latency equals SCTP (both follow RTT = inherent net latenc)

•10Mbpslatency 5ms to 300msloss 1%● SCTP throughput 27% less● SCTP latency 2x more than TCP● Both differences to TCP narrow as the

network latency increases● Reception buffer not tuned

● Default minimum RTO too high

•1Mbps net latency 50ms● Net latency 50ms +/- 25ms with 50%

correlation● 1% packet duplication● Variable losses because of shaping

1Mbps● No constant losses● SCTP throughput 8% less● Latency SCTP 9% more

● Default Minimum RTO too high● Constant loss of 0,1%: no change

•11Mbps wireless ad-hoc

● Path with 2 segments● 802.11 e Ethernet

● Total throughput: 3Mbps● Wifi signal quality was bad, on purpose

● SCTP throughput 25% less● SCTP latency 22% more

•Two clients 100Mbps

● “Strong” clients against “weak” (slow) server

● Throughput: SCTP shared it equally by all clients and directions● TCP had problems, summed throughput

was smaller● Latency with 2 clients

● Increased 30% with SCTP, from 1-client latency. Increased only 15% in TCPM

● Cause: SCTP overhead in slow server

•Multipath 10/11Mbps

● Tests if it works, not the performance● Primary path enabled/blocked every 10

seconds● SCTP needed some tuning to work

properly● path_max_retrans lowered from 5 to 1

•Conclusions at this point● SCTP performance “worse” than TCP,

TCP still has the best raw throughput● SCTP migration only if other good reasons

can be found● CRC-32c influence in latency less than

expected● Minimum and default RTOs of 1000ms

(too high)● Congestion control not suitable for

constant loss channels

•HTTP tests● Softwares: thttpd and httperf● Adaptation of HTTP to SCTP, using a

pair of streams per file● Inspired from SSL adaptation to SCTP

● Using several SCTP streams incresases performance● Small open/close connection overhead● Less HOL blocking

•SMB tests

● Softwares: Samba and smbclient● Simple replacement of TCP by SCTP● Performance increase was expected● Reality check: SCTP performance was

(not much) below TCP, much like the raw performance tests

● More elaborated software adaptation would be necessary to explore SCTP to its full potential

• RTP tests● Software: POC version 0.3.7● MP3 over UDP● RFC 2250, RFC 3119, FEC● Partial reliability SCTP

● Unordered delivery, finite time to live● PR—SCTP

● SCTP increased resistance against network problems

● Partial reliability demand application changes for full potential

•Other tests published● KANG & FIELDS (2003)

● Usage of several streams to increase throughput, much like our HTTP test

● RAJAMANI et al. (2002)● KAME/BSD implementation● HTTP

● Overall results agree with ours● Out of order (“urgent”) messages to increase

throughput● KANG & FIELDS ideas can not be used for

preexisting applicaiton protocols based on TCP

•Conclusions● SCTP delivers its promises● Near production quality● No showstopper problem in LK-SCTP● Is not a silver bullet● All detected problems are solvable in

single time● Consistent advantages of using SCTP as

transport for (HTTP, RTP)

•T H E E N D