Performance of SCTP (Stream Control Transmission Protocol)

1
Performance of SCTP(Stream Control Transmission
Protocol)

• Student Elvis Pfützenreuter
• Advisor Prof. Luis Fernando Friedrich, Ph.D

2
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 / IPv6
Link layer
3
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

MDTP
SCTP
UDP
UDP
SCTP
IP / IPv6
IP / IPv6
IP / IPv6
4
Associations and streams

• SCTP association analogous to TCP conn.
• Streams unidirectional channels for message
  transmission (up to 216 per direction)
• Number of streams negotiated at connection
  initiation

Streams
Terminal
Terminal
5
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 1
Msg 2
Msg 3
Msg 4
Msg 3
Msg 3
Fluxos
Msg 1
Msg 2
Msg 3
lost
Wait msg1 retransmission
6
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
Msg 1
Msg 2 urgent
lost
Waits 1 retransm.
Delivered as soon as it arrives
7
(No Transcript)
8
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 aligned
Length (16b)
9
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

10
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.

11
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
TCPM application proto
TCP
SCTP
Byte 0xEE
Payload
byte 0xFF
IP / IPv6
12
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

13
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

14
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

15
100Mbps, loss 0 to 10

• SCTP throughput better than TCPM for network
  losses gt1
• SACK of SCTP worked well, but...
• SCTP latency was bad for losses gt1
• 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

16
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)

17
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

18
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

19
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

20
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

21
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

22
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

23
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

24
(No Transcript)
25
(No Transcript)
26
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

27
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
• PRSCTP
• SCTP increased resistance against network
  problems
• Partial reliability demand application changes
  for full potential

28
(No Transcript)
29
(No Transcript)
30
(No Transcript)
31
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

32
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)

33
T H E E N D