140 likes | 306 Views
TCP vs. SCTP in high-speed cluster environment. Miklos Kozlovszky Budapest University of Technology and Economics BUTE. Outline. Introduction to SCTP Basic comparison Features Performance. SCTP introduction Stream Control Transmission Protocol. Message oriented Multiple streams
E N D
TCP vs. SCTP in high-speed cluster environment Miklos Kozlovszky Budapest University of Technology and Economics BUTE
Outline • Introduction to SCTP • Basic comparison • Features • Performance
SCTP introductionStream Control Transmission Protocol • Message oriented • Multiple streams • Solution to HOL issue One stream may be blocked – the other streams work on • End-host multi-homing • Continuous path monitoring • Reliable transmission • Reliable data delivery - Transmission Sequence Number • Selective acknowledgements • Packet validation (Verification Tag) • Heartbeat keep-alive mechanism
SCTP Packet format • Common header for the whole packet • 1..N control or data chunks • 17 types of control chunks /very extensible/ • 1 type of data chunk SCTP Common Header Control Chunk Data Chunk
TCP vs. SCTP Both: • IPv4 & IPv6 compatible • Reliable • Connection oriented • Offers acknowledged, error free, non-duplicated transfer • Almost same Flow and Congestion Control
TCP weaknesses • Lack of integrity/robustness checks16-bit CRC used by TCP is inadequate at multi-gigabit rates • Lack of high availability option • Susceptibility to denial-of-service (DoS) attacks • Poor support for QoS • Effective implementation of RDMA becomes very difficult on top of a byte stream abstraction (memory BW, caching and access latency issues)
SCTP features • Flexible ordering Each stream can be designated for an in-order or immediate delivery to the upper layer (unordered delivery reduces latency). • Multi-streaming(The flow and congestion control are still on a per association basis) • Multi-homing /multiple “endpoints”/ increases connection level fault tolerance • Protection against denial of service • Robust association (connection) establishment verification tag+ 32-bit CRC and heartbeat mechanism • Can interface with RDMA easily (message oriented) • Very flexible and extensible protocol
WAN vs. cluster needs • Cluster communication • High level of service availability • Low end-to-end latency • Less variable round-trip times • Data rates: 100Mbps-10Gbps • Efficient multi-party communication • Requirements • Special QoS needs (application specific bandwidth) • Low processing overhead • Low communication latency • Low CPU utilization • Good Configurable • Wide OS support • WAN communication • High level of link availability • Large end-to-end latency range • Variable round-trip times • Data rates:1.5Mbps-400Gbps • Requirements • Automatically adapt to the changing environment • Highest possible throughput on lossy links • Be fair to other competing flows
Measurements and Simulations • Simulation • NS-2 network simulator • Measurements • Point-to-point measurements • Machines • Hardware • Pentium 4, with RedHat Fedora Core3, • Intel and Realtek GE NICs • Software • Gnet- own cluster (NxM node) performance measurement software • iPerf and Ethereal, tcpdump
Performance comparison I. • Theoretical study in network simulator (NS-2) • Perform better than TCP • Fair to TCP and to UDP data flows • Real case scenarios – hard to compare • Perform differently on different OSs • Implementation problems • Less effective than TCP (except BSD) • Almost same CPU utilisation as TCP (bad) • HW offloading • TCP checksum offload and transport segmentation offload (TSO) is not supported on available NICs for SCTP.
Performance comparison II. • SCTP is using CRC-32, TCP: CRC-16 this increase the protocol processing cost by 25%-45% • TCP is faster and even if we disable NAGLE algorithm, and CRC calculation TCP is less CPU intensive (due bad implementation…) • On lossy networks SCTP work a bit better
SCTP availability • It’s relative new… • Linux • Kernel space • Lksctp http://lksctp.sourceforge.net/ (from kernel 2.4 optional) • OpenSS7 SCTP http://www.openss7.org • FreeBSD + Apple MAC • KAME (Reference implementation) http://www.kame.net • SUN - Solaris9,10
GRID aspects • SCTP is suitable for GRID because • More secure than TCP • High Availability support for services • Works good on long haul, big delay links
Summary • SCTP inherited all the “good features of TCP” • SCTP want to behave like a next generation TCP • It is more secure than TCP, and has many attractive feature (e.g.:multihoming) • Theoretically it can work better than TCP, but TCP is faster (yet “poor” implementations) • Well standardized, and can be useful for cluster