Analysis of SCTP as a
Online Game Transport
Protocol
Kelly Yancey
Fall 2006
http://www.posi.net/sctp/
Standard Internet Transport
Protocols
There are 3 network transport
protocols that are considered
Internet standards:
UDP – RFC 768, August 1980
TCP – RFC 793, September 1981
SCTP – RFC 2960, October 2000
Standard Internet Transport
Protocols
UDP TCP
Connectionless Connection
oriented
Best-effort data Provides data
delivery reliability
Preservation of Data sequence
message preservation
boundaries Flow and
congestion control
UDP as Online Game
Transport Protocol
UDP is the preferred transport
protocol for many fast-paced games
Several notable MMORPGs use UDP
for their transport protocol:
Everquest, City of Heroes, Star Wars
Galaxies, Ultima Online, Asheron’s Call,
Final Fantasy XI
UDP as Online Game
Transport Protocol - Pros
Low overhead
Only 8 bytes of protocol overhead per
packet
Source Port Destination Port
Length Checksum
Payload Data
Minimal processing needed to
encapsulate data payload
Many network adapters support UDP
checksum offloading, reducing CPU load
UDP as Online Game
Transport Protocol - Pros
Preserves message boundaries
Receivers are guaranteed to get one
message per read from UDP socket
Connectionless
Single socket may be used to
communicate with any number of
hosts, avoiding OS limits on
simultaneously open sockets.
Supports broadcast and multicast
UDP as Online Game
Transport Protocol - Cons
No delivery guarantee
Sent messages might not be delivered
No sequence preservation guarantee
Messages may be delivered out of
order
A single message may be delivered
multiple times
No indication of lost, duplicate, or
out-of-sequence messages
UDP as Online Game
Transport Protocol - Cons
No congestion control
Does not “play well” with other Internet
traffic
Increases packet loss on busy networks
May not fairly distribute limited network
bandwidth
No flow control
Sender can send packets faster than
receiver can process them
UDP as Online Game
Transport Protocol - Cons
No source validation at transport
layer (the down side of being
connectionless)
Vulnerable to blind packet injection
attacks
Vulnerable to replay attacks
Denial of service attacks with spoofed
source IP addresses are effective
Application responsible for security
UDP as Online Game
Transport Protocol
Application protocol can work
around deficiencies of UDP. E.g.:
Adding a sequence number to the
game protocol allows detection of
duplicate or out-of-sequence messages
Implementing application-layer
acknowledgments and retransmit timer
allows detection of lost messages
However, congestion control and source
validation are non-trivial
UDP as Online Game
Transport Protocol
Applications must be careful not to
re-implement TCP in terms of UDP
Using the right tool for the job reduces
development time
Likely to re-implement TCP poorly
TCP as Online Game
Transport Protocol
Some MMORPGs that use TCP as
their transport protocol:
World of Warcraft, Lineage I/II, Guild
Wars, Ragnarok Online, Anarchy Online,
Mabinogi
TCP as Online Game
Transport Protocol - Pros
Guarantees reliable data delivery
Received packets are explicitly
acknowledged
Retransmit timeout (RTO) to trigger
sender to resend unacknowledged
packets
TCP as Online Game
Transport Protocol - Pros
Preserves data sequence
Each packet has a unique sequence
number so received duplicates can be
identified and ignored
Sequence number also used by network
stack to reorder received packets to
match order they were sent
TCP as Online Game
Transport Protocol - Pros
Congestion control
TCP will reduce throughput to avoid
packet loss
Relies on Round Trip Time (RTT)
estimation
Flow control
Senders throttled to avoid packet loss
due to exceeding receivers’ processing
capabilities
TCP as Online Game
Transport Protocol - Pros
Source host validation
Rejects packets from hosts for which
there is no TCP connection
Rejects packets with sequence numbers
not within 1 receive window size of the
expected sequence number
TCP as Online Game
Transport Protocol - Cons
Higher overhead than UDP
20-byte fixed header plus up to 40
bytes of TCP options
Three-way handshake to initiate
connection
Each data packet transmitted requires
acknowledgment
Network stack has to maintain per-
connection state
TCP as Online Game
Transport Protocol - Cons
Does not preserve message boundaries
TCP presents a byte stream to readers,
destroying any structure in sent messages
Sender Receiver
Message 1
Message 1
TCP Connection
Message 2
Message 2
Framing must be performed in application
protocol
TCP as Online Game
Transport Protocol - Cons
Guarantees data will be delivered,
not when it will be delivered
“Better late than never” philosophy
Strict order preservation and byte-
orientation precludes any way for
applications to limit retransmit time
TCP as Online Game
Transport Protocol - Cons
Head-of-line blocking increases
average latency and latency jitter
5 4 3 2 1
Network
Sender 3’ 5 4 3 2 1 Receiver
5 4 3’ 2 1
For games, high latency jitter worse
than high latency
TCP as Online Game
Transport Protocol - Cons
TCP Reset attacks threat to long-
lived connections
“Slipping in the Window” – Paul Watson
Some TCP implementations
vulnerable to SYN attacks
TCP “SYN cookies” mitigate threat
But no Windows OS implements SYN
cookies yet
http://www.osvdb.org/reference/SlippingInTheWindow_v1.0.doc
TCP Behavior in MMORPGs
Approximately 3%-4% of all
backbone Internet traffic can be
attributed to 6 popular online games
98% of TCP packets sent by game
clients have payloads of 31 bytes or
less
TCP packets sent by game servers
vary in size considerably with an
average packet payload of 114 bytes
TCP Behavior in MMORPGs
Average bandwidth requirement per
MMORPG client is 7Kbps.
99% of connections consumed less
than 8Kbps of bandwidth (3Kbps
game data + 5Kbps TCP overhead)
99% of connections had a packet
rate less than 15 packets/second
(including TCP ACK packets)
TCP Behavior in MMORPGs:
Lineage II
Lineage II is a MMORPG released in
October 2003 in Korea and April
2004 in North America
Over 14 million subscribers
worldwide
Uses TCP as game’s transport
protocol
Kim, J., Choi, J., Chang, D., Kwon, T., Choi, Y., and Yuk, E., “Traffic Characteristics of a Massively
Multi-player Online Role Playing Game”. In Proceedings of 4th ACM SIGCOMM Workshop on
Network and System Support For Games (Hawthorne, NY, October 10 - 11, 2005). NetGames '05.
ACM Press, New York, NY, 1-8. http://doi.acm.org/10.1145/1103599.1103619
TCP Behavior in MMORPGs:
Lineage II
Researchers at Seoul National
University obtained and analyzed
over 12.72 billion packets of game
data
6.29 billion packets were client-
generated traffic (~49.5%)
6.42 billion packets were server-
generated (~50.5%)
Kim, J., Choi, J., Chang, D., Kwon, T., Choi, Y., and Yuk, E., “Traffic Characteristics of a Massively
Multi-player Online Role Playing Game”. In Proceedings of 4th ACM SIGCOMM Workshop on
Network and System Support For Games (Hawthorne, NY, October 10 - 11, 2005). NetGames '05.
ACM Press, New York, NY, 1-8. http://doi.acm.org/10.1145/1103599.1103619
TCP Behavior in MMORPGs:
Lineage II
Of the 6.29 billion client-generated
packets, only 1.44 billion (~23%)
contained game data
The rest were TCP protocol overhead
Average data payload was 19.06
bytes
99% of packets had less than 50
bytes of payload
Kim, J., Choi, J., Chang, D., Kwon, T., Choi, Y., and Yuk, E., “Traffic Characteristics of a Massively
Multi-player Online Role Playing Game”. In Proceedings of 4th ACM SIGCOMM Workshop on
Network and System Support For Games (Hawthorne, NY, October 10 - 11, 2005). NetGames '05.
ACM Press, New York, NY, 1-8. http://doi.acm.org/10.1145/1103599.1103619
TCP Behavior in MMORPGs:
Lineage II
Average RTT was 126 milliseconds
with bimodal distribution at 0 and
200 milliseconds
Approximately 11% of packets were
acknowledged immediately (within 1
millisecond of receipt)
15% of packets were acknowledged
in 200 ± 1 milliseconds
Kim, J., Choi, J., Chang, D., Kwon, T., Choi, Y., and Yuk, E., “Traffic Characteristics of a Massively
Multi-player Online Role Playing Game”. In Proceedings of 4th ACM SIGCOMM Workshop on
Network and System Support For Games (Hawthorne, NY, October 10 - 11, 2005). NetGames '05.
ACM Press, New York, NY, 1-8. http://doi.acm.org/10.1145/1103599.1103619
TCP Behavior in MMORPGs:
Lineage II
Of the 6.43 billion server-generated
packets, 6.28 billion (~98%)
contained game data
Average data payload was 318.89
bytes
Approx. 5% of packets were
maximally sized (1460 bytes of
payload)
Kim, J., Choi, J., Chang, D., Kwon, T., Choi, Y., and Yuk, E., “Traffic Characteristics of a Massively
Multi-player Online Role Playing Game”. In Proceedings of 4th ACM SIGCOMM Workshop on
Network and System Support For Games (Hawthorne, NY, October 10 - 11, 2005). NetGames '05.
ACM Press, New York, NY, 1-8. http://doi.acm.org/10.1145/1103599.1103619
TCP Behavior in MMORPGs:
Lineage II
Average inter-arrival time of data
packets from the server to clients
was 182.24 milliseconds
Positive correlation between the
number of online players and the
inter-arrival time
Kim, J., Choi, J., Chang, D., Kwon, T., Choi, Y., and Yuk, E., “Traffic Characteristics of a Massively
Multi-player Online Role Playing Game”. In Proceedings of 4th ACM SIGCOMM Workshop on
Network and System Support For Games (Hawthorne, NY, October 10 - 11, 2005). NetGames '05.
ACM Press, New York, NY, 1-8. http://doi.acm.org/10.1145/1103599.1103619
TCP Behavior in MMORPGs:
Lineage II
Average arrival time for new connections:
401.77ms
2.5 new connections per second during
peak times
Average session length is 183 minutes
50% of users play less than 26 minutes;
80% play less than 156 minutes at a
sitting
Kim, J., Choi, J., Chang, D., Kwon, T., Choi, Y., and Yuk, E., “Traffic Characteristics of a Massively
Multi-player Online Role Playing Game”. In Proceedings of 4th ACM SIGCOMM Workshop on
Network and System Support For Games (Hawthorne, NY, October 10 - 11, 2005). NetGames '05.
ACM Press, New York, NY, 1-8. http://doi.acm.org/10.1145/1103599.1103619
TCP Behavior in MMORPGs:
ShenZhou Online
ShenZhou Online is a mid-sized
MMORPG popular in Taiwan
Uses TCP as game transport protocol
Researchers from National Taiwan
University obtained and analyzed
1.356 billion packets of game data
Chen, K., Huang, P., Huang, C., and Lei, C., “Game Traffic Analysis: An MMORPG Perspective”. In
Proceedings of the international Workshop on Network and Operating Systems Support For Digital
Audio and Video (Stevenson, Washington, USA, June 13 - 14, 2005). NOSSDAV '05. ACM Press,
New York, NY, 19-24. http://doi.acm.org/10.1145/1065983.1065988
TCP Behavior in MMORPGs:
ShenZhou Online
TCP/IP headers accounted for 46%
of all network bandwidth
TCP ACK packets accounted for 38%
of all packets
Combined, TCP/IP protocol overhead
consumed ~80% of bandwidth from
clients to servers
Chen, K., Huang, P., Huang, C., and Lei, C., “Game Traffic Analysis: An MMORPG Perspective”. In
Proceedings of the international Workshop on Network and Operating Systems Support For Digital
Audio and Video (Stevenson, Washington, USA, June 13 - 14, 2005). NOSSDAV '05. ACM Press,
New York, NY, 19-24. http://doi.acm.org/10.1145/1065983.1065988
TCP Behavior in MMORPGs:
ShenZhou Online
Server-generated packets tend to
carry larger payloads than client-
generated packets
As such, TCP/IP protocol overhead
“only” consumes 50% of bandwidth
from game servers to clients
Chen, K., Huang, P., Huang, C., and Lei, C., “Game Traffic Analysis: An MMORPG Perspective”. In
Proceedings of the international Workshop on Network and Operating Systems Support For Digital
Audio and Video (Stevenson, Washington, USA, June 13 - 14, 2005). NOSSDAV '05. ACM Press,
New York, NY, 19-24. http://doi.acm.org/10.1145/1065983.1065988
TCP Behavior in MMORPGs:
ShenZhou Online
~89% of client-originated packets
had inter-arrival times less than
300ms
~95% had inter-arrival times less
than 1 second
Chen, K., Huang, P., Huang, C., and Lei, C., “Game Traffic Analysis: An MMORPG Perspective”. In
Proceedings of the international Workshop on Network and Operating Systems Support For Digital
Audio and Video (Stevenson, Washington, USA, June 13 - 14, 2005). NOSSDAV '05. ACM Press,
New York, NY, 19-24. http://doi.acm.org/10.1145/1065983.1065988
TCP Behavior in MMORPGs:
ShenZhou Online
~87% of server-originated packets
had inter-arrival times less than
300ms
~97% had inter-arrival times less
than 1 second
Similar distribution as client-
generated traffic
Chen, K., Huang, P., Huang, C., and Lei, C., “Game Traffic Analysis: An MMORPG Perspective”. In
Proceedings of the international Workshop on Network and Operating Systems Support For Digital
Audio and Video (Stevenson, Washington, USA, June 13 - 14, 2005). NOSSDAV '05. ACM Press,
New York, NY, 19-24. http://doi.acm.org/10.1145/1065983.1065988
TCP Behavior in MMORPGs:
ShenZhou Online
TCP “slow start restart” algorithm
(RFC 2581) negatively impacts
interactive responsiveness
Affects bursts of 3 or more packets
after periods of idleness
12% of client-generated traffic affected
18% of server-generated traffic
affected
Chen, K., Huang, P., Huang, C., and Lei, C., “Game Traffic Analysis: An MMORPG Perspective”. In
Proceedings of the international Workshop on Network and Operating Systems Support For Digital
Audio and Video (Stevenson, Washington, USA, June 13 - 14, 2005). NOSSDAV '05. ACM Press,
New York, NY, 19-24. http://doi.acm.org/10.1145/1065983.1065988
TCP Behavior in MMORPGs:
ShenZhou Online
Packet loss was a problem
Doubled the standard deviation of
packet latency (“delay jitter”) for 22%
of TCP connections
6% of connections incurred more than
4 times the delay jitter
Chen, K., Huang, P., Huang, C., and Lei, C., “Game Traffic Analysis: An MMORPG Perspective”. In
Proceedings of the international Workshop on Network and Operating Systems Support For Digital
Audio and Video (Stevenson, Washington, USA, June 13 - 14, 2005). NOSSDAV '05. ACM Press,
New York, NY, 19-24. http://doi.acm.org/10.1145/1065983.1065988
TCP Behavior in MMORPGs:
ShenZhou Online
Head-of-line blocking problematic
Head-of-line blocking in caused 33% of
connections to incur more than 10%
additional latency
7% of connections incurred more than
20% additional latency
Average delay jitter rose from 77ms to
124ms
Chen, K., Huang, P., Huang, C., and Lei, C., “Game Traffic Analysis: An MMORPG Perspective”. In
Proceedings of the international Workshop on Network and Operating Systems Support For Digital
Audio and Video (Stevenson, Washington, USA, June 13 - 14, 2005). NOSSDAV '05. ACM Press,
New York, NY, 19-24. http://doi.acm.org/10.1145/1065983.1065988
TCP Behavior in MMORPGs:
ShenZhou Online
Game servers did not detect 99.92%
of TCP packet loss, instead relying
on retransmission timer to resend
packets
Servers did not support SACK, instead
relying on RFC 2001 fast retransmit
and recovery behavior to detect packet
loss
Chen, K., Huang, P., Huang, C., and Lei, C., “Game Traffic Analysis: An MMORPG Perspective”. In
Proceedings of the international Workshop on Network and Operating Systems Support For Digital
Audio and Video (Stevenson, Washington, USA, June 13 - 14, 2005). NOSSDAV '05. ACM Press,
New York, NY, 19-24. http://doi.acm.org/10.1145/1065983.1065988
TCP Behavior in MMORPGs:
ShenZhou Online
Why did RFC 2001 fast
retransmit/recovery fail so badly?
Insufficient duplicate ACKs
Bidirectional traffic flow
TCP SACK extension (RFC 2018)
eliminates these problems
Chen, K., Huang, P., Huang, C., and Lei, C., “Game Traffic Analysis: An MMORPG Perspective”. In
Proceedings of the international Workshop on Network and Operating Systems Support For Digital
Audio and Video (Stevenson, Washington, USA, June 13 - 14, 2005). NOSSDAV '05. ACM Press,
New York, NY, 19-24. http://doi.acm.org/10.1145/1065983.1065988
Recommendations for Ideal
Game Transport Protocol
Support both reliable and unreliable
delivery
State updates that contain motions of
in-game characters far from the
observer need not be as reliable as the
acting character on the screen.
The closer the object is, the more exact
the object’s state should be.
Chen, K., Huang, C., Huang, P., and Lei, C., “An Empirical Evaluation of TCP Performance in Online
Games”. In Proceedings of the 2006 ACM SIGCHI International Conference on Advances in
Computer Entertainment Technology (Hollywood, California, June 14 - 16, 2006). ACE '06. ACM
Press, New York, NY, 5. http://doi.acm.org/10.1145/1178823.1178830
Recommendations for Ideal
Game Transport Protocol
Support both in-order and out-of-
order delivery
Delay jitter (as caused by head-of-line
blocking) can be reduced by only
ordering packets when absolutely
necessary.
Chen, K., Huang, C., Huang, P., and Lei, C., “An Empirical Evaluation of TCP Performance in Online
Games”. In Proceedings of the 2006 ACM SIGCHI International Conference on Advances in
Computer Entertainment Technology (Hollywood, California, June 14 - 16, 2006). ACE '06. ACM
Press, New York, NY, 5. http://doi.acm.org/10.1145/1178823.1178830
Recommendations for Ideal
Game Transport Protocol
Multiple streams for reliable in-order
traffic
A delayed message in one stream
should not affect delivery in
independent message streams.
For example, chat messages and game
control commands should be isolated in
separate streams.
Chen, K., Huang, C., Huang, P., and Lei, C., “An Empirical Evaluation of TCP Performance in Online
Games”. In Proceedings of the 2006 ACM SIGCHI International Conference on Advances in
Computer Entertainment Technology (Hollywood, California, June 14 - 16, 2006). ACE '06. ACM
Press, New York, NY, 5. http://doi.acm.org/10.1145/1178823.1178830
Recommendations for Ideal
Game Transport Protocol
Accumulative delivery
Many games send state updates to
clients that override previous state
information; missing one update does
not matter do long as the last in a
series of updates is delivered
successfully.
Chen, K., Huang, C., Huang, P., and Lei, C., “An Empirical Evaluation of TCP Performance in Online
Games”. In Proceedings of the 2006 ACM SIGCHI International Conference on Advances in
Computer Entertainment Technology (Hollywood, California, June 14 - 16, 2006). ACE '06. ACM
Press, New York, NY, 5. http://doi.acm.org/10.1145/1178823.1178830
Recommendations for Ideal
Game Transport Protocol
Congestion control
In order to support thousands of
simultaneous players, the transport
protocol needs to support efficient
bandwidth sharing in terms of fairness
and responsiveness.
Chen, K., Huang, C., Huang, P., and Lei, C., “An Empirical Evaluation of TCP Performance in Online
Games”. In Proceedings of the 2006 ACM SIGCHI International Conference on Advances in
Computer Entertainment Technology (Hollywood, California, June 14 - 16, 2006). ACE '06. ACM
Press, New York, NY, 5. http://doi.acm.org/10.1145/1178823.1178830
Stream Control
Transmission Protocol
Connection oriented
Provides data reliability
Data sequence preservation
Flow and congestion control
Multi-streams
Multi-homing
Preservation of message boundaries
Unordered reliable message delivery
SCTP – Multi-streams
Supports up to 65535 bi-directional
streams multiplexed in a single
connection (“association”)
Stream 0
Stream 1
Stream 2
Stream N
Endpoint SCTP Association Endpoint
SCTP – Multi-streams
Each stream is independent
Sequenced delivery of user messages
within each stream
No head-of-line blocking
Order-of-arrival delivery of individual
messages within a stream also
supported
Data from multiple streams may be
bundled in a single packet
SCTP – Multi-homing
Each endpoint may be represented
by multiple addresses
One address is the primary address
Alternate address used only if
primary address is unreachable
Improves survivability in the event
of network outages by allowing an
endpoint with redundant LANs to
continue association on any LAN
SCTP – Other Properties
Unicast protocol (like TCP)
Data exchange between exactly two
endpoints
Each endpoint may be represented by
multiple addresses (multi-homing)
Message-oriented (like UDP)
Preserves message boundaries
Messages may be arbitrarily large
SCTP – Other Properties
Supports unordered service
Individual messages may be flagged for
unordered delivery
Similar to UDP’s order-of-arrival
delivery
Except reliable delivery still guaranteed
SCTP – Other Properties
Rate-adaptive like TCP
Monitors load conditions on network
Increases packet latency to avoid
packet loss
Designed to behave cooperatively with
TCP sessions and other SCTP sessions
attempting to share same bandwidth
SCTP – Other Properties
Optional partial reliability support
Each user message can have
associated lifetime parameter
If SCTP stack cannot send message
before its lifetime expires, then the
packet can be discarded
However, once message has been sent,
SCTP will continue to resend message
even if retry time exceeds lifetime
SCTP – Packet Format
Source Port Destination Port
Common Header Verification Tag
CRC
Type Flags Length
Chunk Chunk Data
Type=0 Flags Length
Transmission Sequence Number
Stream Id Stream Seq Num
DATA Chunk
Payload Identifier
Payload Data
SCTP – Common Header
Source Port Destination Port
Verification Tag
CRC
Dedicated 32-bit Verification Tag field
Guards against insertion of out-of-date or
false messages by blind attackers
32-bit polynomial CRC rather than 16-
bit ones-compliment Internet checksum
Better error detection
More computationally expensive to compute
SCTP - Chunks
Single SCTP packet consists of one
or more chunks
Each chunk must be padded to a
multiple of four bytes in length
There are 13 SCTP chunk types
defined in RFC 2960 that can be
divided into five main categories:
SCTP – Chunks:
Connection Establishment
Four-way handshake
Client sends INIT
Server responds with
INIT-ACK which includes
a state cookie
Client echos state cookie
with COOKIE-ECHO
Server allocates
resources and replies Client Server
with COOKIE-ACK
SCTP – Chunks:
Data Transport
Data Transport
Supports arbitrarily
large messages
SCTP stack fragments
application messages to
conform to discovered
path MTU
Unordered flag allows
Endpoint Endpoint
order-of-arrival delivery
for individual messages
SCTP – Chunks:
Data Transport
Data Acknowledgment
Single SACK may
acknowledge multiple
DATA chunks
Multiple gaps in received
DATA chunks may be
reported per SACK
SACK may also notify
Endpoint Endpoint
sender of duplicate
received DATA chunks
SCTP – Chunks:
Reachability Verification
HEARTBEAT chunks
verify reachability and
estimate RTT
For primary address if
association is idle
For alternate endpoint
addresses
Can change
HEARTBEAT frequency Endpoint Endpoint
via SCTP API
SCTP – Chunks:
Connection Teardown
Three-way graceful
shutdown
SCTP does not support
TCP’s “half-open”
function
Once the shutdown
process begins, both
endpoints stop sending
Endpoint Endpoint
new data
SCTP – Chunks:
Error Handling / Reporting
ERROR chunk used to report non-
fatal errors to remote endpoint
ABORT chunk reports fatal errors
ABORT chunk causes the SCTP
association to be abruptly
disconnected
SCTP – Benchmarks
Researchers at the University of
Aizu, Japan compared SCTP to TCP
Used FreeBSD 5.3 with experimental
KAME SCTP stack
Unfortunately, study focused mostly
on bulk transfer
Islam, M. N. and Kara, A., “Throughput Analysis of SCTP over a Multi-homed Association”. In
Proceedings of the Sixth IEEE International Conference on Computer and information Technology
(Cit'06) - Volume 00 (September 20 - 22, 2006). CIT. IEEE Computer Society, Washington, DC, 110.
http://dx.doi.org/10.1109/CIT.2006.181
SCTP – Benchmarks
If no packet loss:
SCTP provided higher throughput than TCP for
large messages
Crossover point was at approximately 22KB
Authors expect crossover point to decrease as
SCTP implementations mature
However, Internet packet loss averages
1%~2%
Islam, M. N. and Kara, A., “Throughput Analysis of SCTP over a Multi-homed Association”. In
Proceedings of the Sixth IEEE International Conference on Computer and information Technology
(Cit'06) - Volume 00 (September 20 - 22, 2006). CIT. IEEE Computer Society, Washington, DC, 110.
http://dx.doi.org/10.1109/CIT.2006.181
SCTP – Benchmarks
Throughput comparison with packet
loss (SCTP versus TCP):
Message Size 1% loss 2% loss
30KB SCTP 24x SCTP 43x
faster faster
300KB SCTP 3x SCTP 3x
faster faster
Islam, M. N. and Kara, A., “Throughput Analysis of SCTP over a Multi-homed Association”. In
Proceedings of the Sixth IEEE International Conference on Computer and information Technology
(Cit'06) - Volume 00 (September 20 - 22, 2006). CIT. IEEE Computer Society, Washington, DC, 110.
http://dx.doi.org/10.1109/CIT.2006.181
SCTP – Benchmarks
Multi-streams effectiveness against
head-of-line blocking
Compared 10 stream SCTP association
with single stream SCTP association
Simulated 2% packet loss
10 stream association had 35% higher
throughput
Islam, M. N. and Kara, A., “Throughput Analysis of SCTP over a Multi-homed Association”. In
Proceedings of the Sixth IEEE International Conference on Computer and information Technology
(Cit'06) - Volume 00 (September 20 - 22, 2006). CIT. IEEE Computer Society, Washington, DC, 110.
http://dx.doi.org/10.1109/CIT.2006.181
SCTP - Benchmarks
Researchers at the University of
Stuttgart compared response time of
SCTP and TCP for small messages
Tested both Solaris 10 and Linux
2.6.16 network stacks
Focused on response time rather
than throughput
Kiesel, S., Scharf, M., Beutel, S., Ruschival, T., “Performance Measurement Results of SIMCO over
TCP and SCTP,” University of Stuttgart, IKR, Internal Report 53, 2006. http://www.ikr.uni-
stuttgart.de/Content/Publications/Archive/Ki_IB53-simco-tcp-sctp_36515.pdf
SCTP - Benchmarks
Kiesel, S., Scharf, M., Beutel, S., Ruschival, T., “Performance Measurement Results of SIMCO over
TCP and SCTP,” University of Stuttgart, IKR, Internal Report 53, 2006. http://www.ikr.uni-
stuttgart.de/Content/Publications/Archive/Ki_IB53-simco-tcp-sctp_36515.pdf
SCTP - Benchmarks
Kiesel, S., Scharf, M., Beutel, S., Ruschival, T., “Performance Measurement Results of SIMCO over
TCP and SCTP,” University of Stuttgart, IKR, Internal Report 53, 2006. http://www.ikr.uni-
stuttgart.de/Content/Publications/Archive/Ki_IB53-simco-tcp-sctp_36515.pdf
SCTP - Benchmarks
Researcher’s observations
SCTP packets incur lower delays than
TCP packets of the same size when
packet loss is present
Using more SCTP streams per
association can further reduce delay
SCTP’s message-based API made
source code shorter and simpler than
TCP version
Kiesel, S., Scharf, M., Beutel, S., Ruschival, T., “Performance Measurement Results of SIMCO over
TCP and SCTP,” University of Stuttgart, IKR, Internal Report 53, 2006. http://www.ikr.uni-
stuttgart.de/Content/Publications/Archive/Ki_IB53-simco-tcp-sctp_36515.pdf
SCTP – Comparison with
Ideal Game Transport
Support both reliable and unreliable
delivery
Support both in-order and out-of-
order delivery
Accumulative delivery
Multiple streams
Coordinated congestion control
PR-SCTP
Internet RFC 3758 extends SCTP to
refine partial reliability support
Adds ability to perform unordered,
unreliable data transfer
Unreliable messages can be
multiplexed over a single PR-SCTP
association alongside reliable
streams
PR-SCTP
Defines “timed reliability” service
Application can indicate a limit for SCTP
stack to attempt message delivery
Message lifetime can be set individually
for each message
“Better never than late” policy
Possibility left open for other partial
reliability services in the future
PR-SCTP – Comparison with
Ideal Game Transport
Support both reliable and unreliable
delivery
Support both in-order and out-of-
order delivery
Accumulative delivery
Multiple streams
Coordinated congestion control
SCTP Availability - Solaris
Patch available for Solaris 9, Update
7 or later
Solaris 10 includes SCTP in base OS
All features mandated in base SCTP
protocol (RFC 2960)
PR-SCTP (RFC 3758)
All errata and issues from RFC 4460
SCTP Sockets API (IETF draft)
SCTP Availability - Linux
Linux kernel 2.4.23 and 2.6
lksctp project claims to be trying to
implement all relevant RFCs including
PR-SCTP
• http://lksctp.sourceforge.net/
Not clear what features are currently
implemented
Multiple remote denial of service
vulnerabilities discovered earlier this
year
SCTP Availability - FreeBSD
Patch available for FreeBSD 6.0 or
later
All features in base SCTP protocol (RFC
2960)
SCTP Sockets API (IETF draft)
PR-SCTP (RFC 3758)
Implemented by primary SCTP RFC
author, Randall Stewart, and Cisco
• http://www.sctp.org/
FreeBSD 7.0 will include in base OS
SCTP Availability - Windows
Rumor has it Windows Vista might
include SCTP support
SCTP-related constants defined in
Windows Driver Kit
However, no mention in public
documentation
Commercial implementations
available
Thank You