Performance of SCTP (Stream Control Transmission Protocol) Student: Elvis Pfützenreuter Advisor:...
-
date post
22-Dec-2015 -
Category
Documents
-
view
221 -
download
1
Transcript of Performance of SCTP (Stream Control Transmission Protocol) Student: Elvis Pfützenreuter Advisor:...
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)