SIP over SCTP performance analysis

Camarillo / Schulzrinne / KantolaNovember 26th, 2001

SIP over SCTP performance analysis

[email protected]@cs.columbia.edu

[email protected]


Outline

Problem statement: signalling transport

Introduction to SCTP

SCTP performance analysis

– SCTP vs UDP

– SCTP vs TCP


Signalling Transport (SIGTRAN)

Providers want to transport telephony signalling over IP

– IP trunking

Let us try to use existing transport protocols

PSTN IP PSTN

SG SG

SG: Signalling Gateway


Traditional transports: UDP and TCP

UDP (User Datagram Protocol)

– Unreliable transfer of datagrams

– Demultiplexing based on port numbers

– Checksum

– Example: RTP

TCP (Transmission Control Protocol)

– Reliable transfer of streams of bytes

– Congestion control: network friendly

– Example: HTTP, FTP, Telnet


TCP limitations

Carry every SS7 call on top of a TCP session

– Every SS7 call is affected by the TCP three-way handshake

Multiple SS7 calls on top of a single TCP session

– TCP provides a stream service: Head of the line blocking problem

Sender R eceiver

Established

SYN

SYN

ack

Sender R eceiver

T C P delivers1:1025

1:513

513:1025

ack 1

1:513


UDP limitations

Use UDP and application level retransmissions

– No flow control: Congestion

– Large amount of state information in the application

In a slightly different context, this solution was adopted by SIP

Sender R eceiver

INVITE

INVITE

0,5

secs


Stream Control Transmission Protocol (SCTP)

SIGTRAN is chartered to develop a transport protocol that fulfils signalling transport requirements

– October 2000; RFC 2960: Stream Control Transmission Protocol

– A connection in SCTP terminology is an “association”

Four-way handshake (avoids DoS attacks)

Sender R eceiver

IN IT

COOKIE ACK

COOKIE ECHOE

INIT ACK

Sender R eceiver

Established

SYN

SYN

ack

SCTP TCP



SCTP allows multihoming

– A receiver can be reachable at multiple IP addresses

– Robustness rather than load balancing

SCTP is a message-based protocol

– Easier parsing

– No need of application specific boundaries



SCTP allows multiple streams within an association

– Flow control performed on association basis (TSN)

– Delivery performed on stream basis (no head of the line blocking)

Sender R eceiver

C hunk deliveredfor s tream id=0

TSN=2Stream id=1Stream seq=0


SACKTSN=1



C hunk deliveredfor s tream id=0

TSN:Transmission Sequence Number

STREAM 0



SCTP uses TCP SACK congestion and flow control mechanisms (per association)

– Slow start, congestion avoidance, fast retransmit, fast recovery

SCTP provides two services (per stream)

– Ordered message delivery

– Unordered message delivery

– It also provides unordered messages within an ordered stream


SIP over SCTP

Two ways of transporting SIP over SCTP

– Send all SIP requests and responses over a single unordered SCTP stream.

– Send requests and responses belonging to the same SIP transaction over the same SCTP stream.

Stream ID can be used as a lightweight transaction identifier instead of the Call-ID, From, To, Via and Cseq header fields

– Server side: Incoming ACKs (non-2xx) and CANCELs

– Client side: Incoming responses


Simulations: SCTP performance analysis

We implemented SCTP in the network simulator (ns)

We only analyzed the SIP hop-by-hop handshake (INVITE-100 Trying)

15 ms 15 ms 15 ms


SCTP vs. UDP

Fast retransmit detects losses much faster than UDP-based timeouts

UDP lacks congestion control

0

100

200

300

400

500

600

12100 12200 12300 12400 12500 12600 12700 12800

SCTP UDP

Delay (ms)

Time a packet is generated (ms)


SCTP transport layer fragmentation

Every fragment a different TSN

Begin and End bits are used for reassembling

Once an SCTP packet is sent it cannot be re-fragmented again

– Sudden changes in the path MTU trigger IP fragmentation

Problems with NATs and firewalls

TSN = 1

10

TSN = 2

00

TSN = 3

01

SCTP DATA chunk


SCTP and TCP window-based congestion control

Congestion window (cwnd) limits the data rate at the sender

– Slow start: exponential growth of cwnd

– Congestion avoidance: linear growth of cwnd

When the data rate at the sender is limited by the application rather than by cwnd, the congestion window grows dramatically

– Bursts of traffic produce heavy congestion


Head Of the Line (HOL) blocking

Comparison between ordered SCTP (which behaves like TCP SACK) and unordered SCTP

61040

61090

61140

61190

61240

61290

61340

60850 60900 60950 61000 61050 61100

No HOL HOL

Time a packet is generated (ms)

Time a packet is received (ms)


Measuring HOL: buffer limited router

Losses due to a buffer-limited router

No HOL HOLMean 397.4 ms 400.8 msVariance 72735.5 72416.9Minimum 48.6 48.6 msMaximum 1016.5 ms 1016.5 msDiff. of means (-6.95 , 0.15)

15 ms 15 ms 15 ms


Measuring HOL: induced packet loss

15 ms 15 ms 15 ms

Induced packet loss

0.2 % packet loss 0.3 % packet lossNo HOL HOL No HOL HOL

Mean 455.9 ms 459.3 ms 840.8 ms 844.8 msVariance 382063 382171 862894 862563Max. 48.6 ms 48.6 ms 48.6 ms 48.6 msMin. 3198 ms 3198 ms 4213 ms 4213 msDiff. (-11.58 , 4.71) (-16.18 , 8.30)


Measuring HOL: competing traffic

15 ms 15 ms 15 ms

Competing traffic

1 competingTCP flow

2 competingTCP flows

No HOL HOL No HOL HOLMean 757.2 ms 771.2 ms 589.1 ms 606.9 msVariance 361544 361980 582583 598105Max. 48.6 ms 48.6 ms 48.6 ms 48.6 msMin. 2135 ms 2135 ms 3284 ms 3284 msDiff. (-21.92 , -6.06) (-27.89 , -7.63)


Conclusions

UDP is not a suitable protocol for proxy to proxy communications

SCTP offers some advantages over TCP– Protection against DoS attacks– Multihoming– Message based– Lightweight transaction identifiers– HOL avoidance

Supposedly the biggest advantage of SCTPOnly significant gain when anyway the delay is unacceptable

SCTP has some limitations– Transport layer fragmentation– Window-based congestion control

Documents

SIP over SCTP performance analysis