Performance of SCTP Stream Control Transmission Protocol Student

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 TCP UDP IP / IPv 6 Link layer ? ? ?

SCTP history ● ● ● SIGTRAN comittee wanted a transport protocol for SS 7 MDTP (Multinetwork Datagram Transmission Protocol): did what SIGTRAN wanted, but it ran over UDP MDTP evolved until becoming SCTP that is a transport protocol MDTP SCTP UDP SCTP IP / IPv 6

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 Streams Terminal

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) Msg #4 Msg #3 Msg #2 Msg #1 Fluxos Msg #3 Wait msg#1 retransmission Msg #2 Msg #1 lost

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 #3 Waits #1 retransm. Msg #2 urgent Delivered as soon as it arrives Msg #1 lost

Multihomed associations ● Multihomed computer: connected to a TCP/IP internetwork by two or more ways ● SCTP offers automatic fail-over in this case ● Rivu. S extension also allows load balancing ● Terminal Inexpensive network redundancy without having to be an AS (Autonomous System) Inter-rede (e. g. Internet) Terminal

More SCTP details ● No half-open state, immune to blind spoof and SYN flood ● Checksum is 32 bits (CRC 32 c) ● Congestion control exactly like TCP ● Architecture of TLV structures instead of bitmaps ● API BSD Sockets: TCP and UDP style Type (8 b) Flags (8 b) Length (16 b) Value Valule – 32 -bit aligned

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 Tests applied in these points TCPM TCP IP / IPv 6 SCTP TCPM application proto Byte 0 x. EE Payload byte 0 x. FF

• Loopback - throughput ● ● Message size is varied TCP: performance well over SCTP (9 x to 4 x). Causes: ● ● ● ● CRC-32 c (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 2 x worse than TCPM Serialization of all latencies Library lksctp-tools deemed NOT guilty SCTP extra latency is inside the kernel

• 100 Mbps ● ● Message size is varied SCTP throughput below TCP and TCPM (even 10 x 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 ●

• ● ● ● 100 Mbps, 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 (1000 ms) but can be tuned TCP-inherited congestion control Tuned RTOs deliver same performance as TCP Still needs more tests

10 Mbps latency from 5 ms to 300 ms • ● ● 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)

10 Mbps latency 5 ms to 300 ms loss 1% • ● ● ● SCTP throughput 27% less SCTP latency 2 x more than TCP Both differences to TCP narrow as the network latency increases ● ● Reception buffer not tuned Default minimum RTO too high

• 1 Mbps net latency 50 ms ● ● ● Net latency 50 ms +/- 25 ms with 50% correlation 1% packet duplication Variable losses because of shaping 1 Mbps No constant losses SCTP throughput 8% less Latency SCTP 9% more ● ● Default Minimum RTO too high Constant loss of 0, 1%: no change

• 11 Mbps wireless ad-hoc ● Path with 2 segments ● ● Total throughput: 3 Mbps ● ● ● 802. 11 e Ethernet Wifi signal quality was bad, on purpose SCTP throughput 25% less SCTP latency 22% more

• Two clients 100 Mbps ● ● “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/11 Mbps ● ● ● 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-32 c influence in latency less than expected Minimum and default RTOs of 1000 ms (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 MP 3 over UDP RFC 2250, RFC 3119, FEC Partial reliability SCTP ● ● Unordered delivery, finite time to live PR—SCTP increased resistance against network problems Partial reliability demand application changes for full potential

• Other tests published ● KANG & FIELDS (2003) ● ● RAJAMANI et al. (2002) ● ● ● Usage of several streams to increase throughput, much like our HTTP test 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)

THE EN D •