A simulation-based comparative evaluation of transport protocols for SIP

1. A simulation-based comparative evaluation of transport protocols for SIP Authors: M.Lulling*, J.Vaughan Department of Computer science, University college Cork, Western Road, Cork, Ireland. Publication: ELSEVIER on Computer communications, April 2005 Reporter: Chun-Hui Sung Date: 2007/5/24

2. Outline • Introduction • Transport for SIP • Simulations • Results • Conclusion • Comment

3. Introduction • Uses the Network Simulator – NS2 to investigate the direct effects and subsequent consequences associated with the use of different transport protocols in a SIP context . • Performance evaluation in the result of VoIP SIP signaling from simulation-based experiments underlying transport protocol.

4. Introduction ( Cont. ) • SIP (Session Initiation Protocol) is • A peer-to-peer protocol • An application layer signaling protocol • Create, modify and terminate sessions • Applications can be voice, video, gaming, instant messaging, presence, call control, etc.

5. Transport for SIP • SIP over TCP • TCP Reno • TCP Vegas • TCP Sack • SIP over UDP • SIP over SCTP

6. SIP over TCP • TCP - Reno

7. SIP over TCP • TCP - Vegas

8. SIP over TCP • TCP - Sack

9. SIP over UDP • The user datagram protocol, UDP, is a connectionless transport protocol that does not provide any guarantee of message delivery.

10. SIP over SCTP • The stream control transmission protocol, SCTP, is a reliable end-to-end transport layer protocol, and while support for TCP and UDP is included in the core SIP specifiation.

11. SIP Proxy A Router Router SIP Proxy B Simulations • Network topology • Node 1 and 2 are buffer-limited droptail routers, all other nodes are endpoints, node 1 and 2 are the only bottleneck link. • Node 0 and 3 are SIP proxies. • Node 4 and 5 are used to provide competing cross-traffic.

12. Simulations ( Cont. ) • NS2 parameters: • Delay time are 45 ms between the proxies. • The simulations use a stationary Poisson model to generate the arrival times of 512-byte session establishment requests at node 0. • Individual SIP requests are independent and are generated at node 0 at 160/s, which corresponds to a link utilization of approximately 33% on the bottleneck link.

13. Simulations ( Cont. ) • Induced packet loss • Random packet loss • Competing traffic • Throughput analysis

14. Simulations ( Cont. ) • Induced packet loss • In order to measure and evaluate the delays and delaying effects of packet loss on the system, packets are explicitly dropped from node 1. • The simulation is run 10 times for each of the five transport protocols or variants. • The time at which each message is generated by the application at node 0 and the time at which this message is passed to the application at node 3 is recorded. (delay time)

15. Simulations ( Cont. ) • Random packet loss • Random packet loss percentages of between 0.1 and 0.5% (in 0.1% intervals) are simulated at node 1 with uniform distribution. • The time at which each message is generated by the application at node 0 and the time at which this message is passed to the application at node 3 is recorded. (delay time)

16. Simulations ( Cont. ) • Competing traffic • Simulate the effects of cross-traffic generated between node 4 and 5, providing competition for bandwidth on the bottleneck link between nodes 1 and 2. • TCP Reno is used exclusively as the transport protocol for the competing traffic in all simulations. • Delays are measured as describe in the two previous experiments.

17. Simulations ( Cont. ) • Throughput analysis • Add a variable of buffer size at node 1 • The simulations have been run with buffer sizes of 5, 20, 50, 100, 150, 200 and 250 packets at node 1. • The default value of buffer size is 50.

18. Results • Induced packet loss • Random packet loss • Competing traffic • Throughputs

19. Results – Induced packet loss (1/3)[ Five consecutively dropped packets ]

20. Results – Induced packet loss (2/3) [ Peak delays ]

21. Results – Induced packet loss (3/3) [ Message affects ]

22. Results – Random packet loss (1/4)[ loss rate of 0.3 % ] • SIP traffic with TCP Reno • SIP traffic with SCTP

23. Results – Random packet loss (2/4) [loss rate of 0.3% ] • SIP traffic with TCP Sack • SIP traffic with UDP

24. Results – Random packet loss (3/4) [loss rate of 0.3% ] • SIP traffic with TCP Vegas

25. Results – Random packet loss (4/4) [ loss rate of 0.1% ~ 0.5% ] • Mean delay per packet loss percentage

26. Results – competing traffic (1/4) [ SIP traffic with TCP Reno ]

27. Results – competing traffic (2/4)[ SIP traffic with UDP / SCTP / TCP SACK ]

28. Results – competing traffic (3/4) [ % overall throughput ]

29. Results – competing traffic (4/4) [ Total throughput ]

30. Results – Throughputs • Mean throughput for SIP vs. FTP TCP Sack • Mean throughput for SIP vs. FTP TCP Vegas

31. Conclusion • Authors compare and analyze the performance of SIP over UDP [TCP-Reno/Vegas/Sack, SCTP]. • This paper was found that TCP Sack and SCTP are the best options for a reliable transport protocol for SIP traffic.

32. Comment • They don’t put attention on multi-homing of SCTP.