Evaluation of Transport Layer Protocols for Voice ... - ResearchGate

Evaluation of Transport Layer Protocols for Voice Transmission inVarious Network ScenariosSreekanth Asodisrik02003@gmail.comS Vijay Ganeshgnsh.vjy@gmail.comE Seshadrisesh_iiitm@yahoo.co.inP K Singhpksingh@iiitm.ac.inAtal Bihari Vajpayee - Indian Institute of Information Technology and ManagementGwalior, IndiaAbstractCarrying voice over Internet Protocol, known asVoIP, is a rapidly growing technology. It is aninteresting real-time application which requiresconstant bit streaming of application data (voice).There are three protocols – TCP, UDP and SCTP –at the transport layer to carry the data between asource node and a destination node in the Internet.TCP is a reliable, byte-oriented protocol with builtincongestion control mechanism. UDP is anunreliable, connectionless protocol without anycongestion control mechanism, hence, may causecongestion collapse. SCTP is a reliable messageorientedprotocol which has been designed fornewer applications, such as voice, which requiremore sophisticated service than TCP can provide.In this paper, we have made an attempt to evaluatethese protocols for voice application under variouscongestion scenarios. We see that SCTP and UDPcompete with each other under the consideredquality metrics for voice transmission.1. IntroductionVoice over Internet Protocol (VoIP) refers todigitization of voice streams and transmitting thedigital voice packets over a conventional IP-basednetwork [1]. Carrying voice traffic over InternetProtocol (IP) is an interesting and relatively newreal-time application over Internet which requiresconstant bit streams of application data (voice). Theuse of VoIP is growing because of low cost ofcommunication compared to Public SwitchedTelephone Network (PSTN) and increasedfunctionality. However, concerns about the Qualityof Service (QoS) of VoIP are inhibiting itsproliferation more rapidly. The factors whichinfluence quality of VoIP service include speechcodec, packetization, packet loss, delay and delayvariation (jitter) [2].Every VoIP system uses the underlying IPnetwork for the transmission of packetized voice.The IP traffic is based on best-effort communication,i.e., guarantee for the delivery is not provided. TheIP routers transmit the packet on first-come, firstservebasis. These characteristics introduce largedelays, large delay variations and packet loss whichare the most important concerns of QoS in VoIP. Asthe guaranteed delivery is provided by the higherlayer protocols, transport layer protocols play amajor role in deciding the voice quality of a VoIPsystem. In this paper, we analyze the VoIP trafficand study the performance of transport layerprotocols (UDP, TCP and SCTP) under variousnetwork scenarios for voice application withreference to three quality metrics: packet loss, delayand delay variation.Rest of the paper is organized as follows. Section2 describes the quality of metrics. A brief review ofrelated work is presented in Section 3. We describeour experimental model and results in Section 4.Finally, we conclude in Section 5.2. Quality Metrics2.1 Packet lossVoIP packet loss occurs when a large amount oftraffic hits the network and causes it to drop packets.Packet loss is mainly attributed to link failure, highlevels of congestion that lead to buffer overflow andoccasional misrouted packets. It results in droppedconversations, a delay in receiving the voicecommunication or extraneous noise on the call.Unfortunately, packet loss occurs frequently in datanetworks and dropped voice packets are discarded;they are not retransmitted. High packet loss cancause noticeable degradation in the call quality.Packet loss of 1% translates into one voice clip every3 minutes whereas packet loss of 0.25% translatesinto one error every 53 minutes [3]. Voice traffic cantolerate less than 3% loss of packets before callersfeel perceivable gaps in conversation.2.2 Delay978-1-4244-4457-1/09/$25.00 ©2009 IEEE 238Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on April 06,2010 at 12:43:30 EDT from IEEE Xplore. Restrictions apply.

Transmission time or delay is the average time ittakes for a packet to travel from its source to itsdestination. Delay causes disruption in the voicequality when voice packets take more time thanexpected to reach their destination. The InternationalTelecommunications Union (ITU) recommendationG.114 [4] considers network delay for voiceapplications. This recommendation defines 3 bandsof one-way delay with adequately controlled echo asshown in the table 1. A voice call can toleratemaximum latency (delay) of 150 milliseconds,however, 100 milliseconds is preferred.2.3 Delay VariationIf the delay is small and constant, the speech maybe acceptable. However, the delay is variable inpacketized networks; this variation in delay is knownas jitter. It is effectively a variation of packet delaywhere delays actually impact quality of theconversation. It can be handled through the de-jitterbuffer at the receiving router/gateway. De-jitterbuffer imposes a delay on early packets and passeslate packets with less delay to compensate thevariable delay. Any packet which arrives later thanthe length of buffer is discarded. The buffer shouldbe able to compensate the maximum delay variationthat we expect. It will minimize packet loss too. Nowonwards, we will use the term ‘jitter’ for delayvariation in the paper.Range inmillisecondsTable 1. Delay BandsDescription0-150 Accepable for most user applications150-400Above 4003. Related WorkAcceptable for internationalconnectionsUnaccepable for general networkplanning purposes; however, it isrecognised that in some exceptationalcases this limit will be exceededChang and Su [5] compare the performance ofTCP and UDP for P2P streaming media withreference to average values of missing index andaverage download rate. They conclude that bothUDP and TCP provide reasonable service quality butTCP is more stable and reliable. It is partly thereason that most P2P streaming systems use TCP asits transport protocol. Kiesel and Scharf [6] study theperformance of SCTP, TCP and UDP over a firewallsignaling protocol - simple middlebox configurationprotocol (SIMCO). They observe that SCTPsignificantly outperform TCP because of its ability totransmit over multiple streams; SCTP reduces theresponse time of SIMCO. TCP and UDP both sufferfrom significantly larger delays.Ha et al. [7] study the throughput performance ofSCTP and TCP over the Linux platform underdifferent scenarios as variable size of user’s inputdata and fairness under competition of traffic. Theyobserve that SCTP outperform TCP in throughputand fairly competes with it. They also observe thatmulti-homing SCTP provides better performancethan the single-homing case. Camarillo et al. [8]implements SIP over SCTP, UDP and TCP protocolsunder different network conditions and observe thatUDP is good only for the light traffic. Under heavytraffic load, TCP and SCTP are better than UDP.However, SCTP has some advantage over TCPowing to its features as multi-streaming and multihoming.In general, SCTP performance increaseswith worsening of network conditions.Wang et al. [9] study the performance of PR-SCTP (an unreliable extension of SCTP), TCP, andUDP for MPEG-4 video traffic over mobilenetworks. They observe that PR_SCTP is moresuitable for real-time traffic as its selectiveretransmission can improve the quality of images.Moreover, it can provide unified congestion controlto both reliable and unreliable traffic which is notpossible by any other protocol.Kumazoe et al. [10] study the throughputcharacteristic of high speed transport protocols:HighSpeed TCP (HSTCP), Scalable TCP and SimpleAvailable Bandwidth Utilization Library (SABUL)experimenting on the Japan Gigabit Network (JGN).They observe that in TCP-based protocols the simpleand robust strategy of ACK packets for rate and errorcontrol works well with variety of networkcircumstances but it may not be suitable for longdistance networks because performance depends onboth the distance and receiver-side TCPimplementation. Rate control and error controlmechanisms should be separated for betterperformance.Rajamani et al. [11] study the performance ofSCTP and TCP over HTTP protocol and concludethat SCTP can help reduce the latency and theimproved throughput. Additionally, other features ofSCTP like multihoming and better protection againstDoS attacks makes it more suitable for future webapplications. Dantas and Jardini [12] compare andobserve that Xpress Transport Protocol (XTP) issuperior to TCP for reliable multicastcommunications. Heidemann et al. [13] develop ananalytical model and use it to compare the relativeperformance of TCP, Transaction TCP and requestresponseprotocol based on UDP over HTTP forvarious network characteristics and workloads.Hence, the literature suggests that performancestudy of transport layer protocols is crucial for any IPbased network application. VoIP is becomingincreasingly popular and has the potential to replace239Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on April 06,2010 at 12:43:30 EDT from IEEE Xplore. Restrictions apply.

the existing telephony system. A VoIP applicationhas two phases: signaling and voice transmission. In[8], the authors have evaluated the performance oftransport layer protocols for SIP which is a VoIPsignaling protocol. It motivated us to evaluate theperformance of various transport layer protocols indifferent network conditions for streaming mediaapplications, e.g., VoIP.4. Experimental Model and Results4.1 Experimental modelWe consider the simulation model as suggestedby Camarillo et al. [8] and use the network simulator(ns 2.31) for the simulation. Figure 1 shows thetypical network topology. Nodes 2 and 3 are bufferlimitedtail drop routers which treat each packetidentically and drop the newly arrived packets ifqueue is full to its maximum capacity until the queuehas enough room to accept incoming traffic. Othernodes are the end nodes. Nodes 1 and 5 are the VoIPsource and sink respectively. Nodes 0 and 4 are usedfor simulating FTP traffic while the nodes 6 and 7are used to simulate the pack mime HTTP traffic. Asingle PackMime-HTTP client node generates HTTPconnections coming from a “cloud” of web clients.Likewise, a single PackMime-HTTP server nodeaccepts and serves HTTP connections destined for a“cloud” of web servers. There are many clientapplications assigned to a single client node andmany server applications assigned to a single servernode [15]. All the simulated traffic shares thecommon link 2-3. Thus, this link acts as a bottleneckfor the entire traffic. We can easily study the networkbehavior in different networking scenarios bychanging the parameters for this bottleneck link.2Mbps, (ii) hLlB - a high latency, low bandwidthscenario with a delay of 140ms and bandwidth of 0.6Mbps, and (iii) lLhB – a low latency, high bandwidthscenario with a delay of 70ms and bandwidth of 2Mbps. The parameters between other links (exceptlink 2-3) are as shown in Figure 1 and were notchanged during the experiments. We simulate eachscenario for 300 seconds and compute mean value ofthe delay and delay jitter for every consecutive timeinterval of 5 seconds.4.2. ResultsHigh Latency, High Bandwidth (hLhB)Scenario: Figures 2 and 3 represent the end to enddelay and jitter respectively. Figure 2 shows theexpected trends of the delay. The initial peaks in thedelay of SCTP and TCP are due to the initialhandshake at the time of connection establishment.As SCTP has a four way handshake [18], its initialpeak is the highest. The intermediate peaks in TCPand SCTP are due to the high congestion and apossible packet loss, which increases the delay. TheUDP shows a constant delay as, being aconnectionless protocol, it maintains the data rate.We observe, initial low value of delay in UDP (refer,Figure 2) because the competitive traffic of TCP andSCTP are still in connection establishment stagethen, hence giving UDP a free link to communicate.Later, when the TCP, SCTP, FTP and HTTP trafficestablishes completely, the delay increases becauseof the high traffic.Figure 1. Simulated Network TopologyIn this monogram, we study the transport layerprotocols with the three performance metrics: (i)packet loss, (ii) delay, and (iii) jitter for the VoIPtraffic between node 1 and node 5 by changing theparameters of the bottleneck link 2-3 for creatingdifferent scenarios. We study three differentscenarios: (i) hLhB - a high latency, high bandwidthscenario with a delay of 140ms and bandwidth ofFigure 2. Delay in hLhB scenarioFigure 3 shows the jitter. As UDP does not have acongestion control and packet re-transmissionmechanisms [16], it continuously sends the packetsat a constant rate in to the network. Thus, we do notobserve much difference in the delay. As a result thejitter, which is the variation of packet delays, is verylow. In case of TCP and SCTP, we observe peaks ofjitter because of the congestion control and packetre-transmission mechanisms in these protocols.240Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on April 06,2010 at 12:43:30 EDT from IEEE Xplore. Restrictions apply.

Figure 3. Jitter hLhB scenarioFigure 4. Delay in hLlB scenarioThough UDP performs better in delay and jitter,we observe comparatively more packet loss (refer,Table 2). However, it is well within the limit tocause any noticeable degradation in the call quality.Table 2. Packet loss in hLhB scenarioProtocol Packets No. of % lossSent packets lostSCTP 4716 54 1.145TCP 4978 49 0.984UDP 4990 62 1.242High latency, Low bandwidth (hLlB) scenario:It is a typical existing scenario in the Internet. Figure4 shows the average delay. The average delay ofTCP traffic is observed to be in the range of 260-280ms whereas the delay of UDP and SCTP is observedto be varying between 220-240 ms. The initial peaksin TCP and SCTP, and the initial low delay in UDPmay be explained as in the previous (hLhB) scenario.The intermediate high peaks in TCP and SCTP maybe attributed to the congestion; due to congestion inthe bottleneck link multiple packets get delayedresulting in a momentary increase (a peak) in theaverage delay. It triggers congestion controlmechanism, which reduces throughput in theseprotocols.Figure 5. Jitter in hLlB scenarioLow latency, High bandwidth (lLhB) scenario:It is a typical scenario which exists in the backboneof Internet. Hence, it is the most desirable scenariofor any study of the data transmission on a network.The delay shows an expected behavior by havingvery low end to end delay compared to otherscenarios. The average delay of VoIP over TCP isobserved around 180-190 ms while the average delayof VoIP over SCTP and UDP both is observedaround 140-160 ms (refer, Figure 6). The SCTP andUDP are comparable to each other. The initial highdelay in SCTP is due to the initial 4-way handshakeconnection establishment. A low delay in SCTP andUDP favors them for efficient packet transmission.Table 3. Packet loss in hLlB scenarioProtocol Packets No. of % lossSent packets lostSCTP 4721 52 1.101TCP 5009 55 1.098UDP 4990 50 1.002Figure 5 shows the jitter. The jitter may beexplained as in the previous (hLhB) scenario.However, jitter in TCP is comparatively higher. Inthis case, packet loss in the UDP is least (refer, Table3).Figure 6. Delay in lLhB scenario241Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on April 06,2010 at 12:43:30 EDT from IEEE Xplore. Restrictions apply.

Table 4. Packet loss in lLhB scenarioProtocol Packets No. of % lossSent packets lostSCTP 5041 53 1.051TCP 5025 53 1.055UDP 4990 57 1.142Figure 7 shows the jitter. As expected, thebehavior of UDP is better as its delay of all thepackets is very similar, hence jitter is negligible.Since TCP is having high variation in delay becauseof its congestion control mechanisms [17], its jitter ishigh compared to that of SCTP and UDP. In thisscenario, behavior of SCTP is same as that of theUDP. Though, in this case also UDP performs betterin delay and jitter, like hLhB, we observecomparatively more packet loss (refer, Table 3).However, it is well within the limit to cause anynoticeable degradation in the call quality.5. ConclusionFigure 7. Jitter in lLhB scenarioOur study supports statistically the superiority ofUDP over TCP and SCTP in all the scenarios. Thegood performance of UDP in VoIP applicationsmakes it a preferred transport layer protocol to carryvoice packets from source to destination, e.g., Skype[14] uses UDP. However, it is likely that SCTP mayperform better with some modifications/extensions inthe protocol as, we observe, its performance iscomparable to UDP in most of the cases. We areworking towards this goal as such modified SCTPwill be more promising because it overcomes theshortcomings of both UDP, e.g., traffic controlmechanism, and TCP, e.g., head of line blocking.[3] “VoIP Service Level FAQ – VoIP News”, URL:http://www.voip-news.com/faq/voip-service-levelfaq/[4] “One Way Transmission Time”, ITU-TRecommendation G.114, 1996[5] J. Y. Chang, and X, Su,”An Evaluation of TransportProtocols in Peer-to-Peer Media Streaming”, In Proc.International Conference on Networking,Architecture, and Storage, IEEE Computer Society,pp. 241-247, 2008.[6] S. Kiesel, and M. Scharf,”Modeling and PerformanceEvaluation of Transport Protocols for FirewallControl”, International Journal of Computer andTelecommunications Networking, Vol. 51, Issue. 11,pp. 3232-3251, August 2007.[7] J. S. Ha, S. T. Kim, and S. J. Koh,”PerformanceComparison of SCTP and TCP over Linux Platform”.In Proc. International Conference on IntelligentComputing, Springer, LNCS 3645, pp.396-404. 2005.[8] G. Camarillo, R. Kantola, and H.Schulzrinne,”Evaluation of Transport Protocols forthe Session Initian Protocol”, IEEE Networks, pp. 40-46, October 2003.[9] H. Wang, Y. Jin, and W. Wang,”The PerformanceComparison of PRSCTP, TCP and UDP for Mpeg-4Multimedia Traffic in Mobile Network”, In Proc.International Conference of CommunicationTechnology, pp. 403-406, April 2003.[10] K. Kazumi, Y. Hori, M. Tsuru and Y. Oie,” TransportProtocols for Fast Long-Distance Networks:Comparison of Their Performances in JGN”, In Proc.Symposium on Applications and the Internet-Workshops (SAINT 2004 Workshops), pp.645, 2004.[11] R. Rajamani, S. Kumar and N. Gupta,”SCTP versusTCP: Comparing the Performance of TransportProtocols for Web Traffic”, Tech report: University ofWisconsin-Madison, July 22, 2002.[12] M. A. R. Dantas and G. Jardini,”PerformanceEvaluation of XTP and TCP Transport Protocols forReliable Multicast Communications”, In Proc. 9thInternational Conference on High-PerformanceComputing and Networking, Springer:LNCS 2110,pp. 591-594, 2001.[13] J. Heidemann, K. Obraczka and J. Touch,”Modelingthe Performance of HTTP Over Several TransportProtocols”, IEEE/ACM Trans. On Networking, Vol.5,No.5, pp.616-630, 1997.[14] “Skype Official Website”, URL:http://www.skype.com/intl/en/[15] “PackMime-HTTP”, URL:http://www.isi.edu/nsnam/ns/doc/node552.html[16] J. Postel,” UDP: User Datagram Protocol”, IETF RFC768,1980.[17] M. Allman, V. Paxson and W. Stevens, “TCPCongestion Control”, IETF RFC 2581, 1999.[18] R. Stewart, Q. Xie, K. Morneault, H. Schwarzbauer,T. Taylor, I. Rytina, M. Kalla, L. Zhang and V.Paxson, “Stream Control Transmission Protocol”,IETF RFC 2960, 2000.References[1] C. I. Oliver, “Converged Nertwork Architectures,Delivering Voice and Data over IP, ATM, and FrameRelay”, 1 st Ed., USA, John Wiley & Sons, 2002.[2] B. goode, “Voive Over Internet Protocol (VoIP)”,Proceedings of the IEEE, Vol. 90, No. 9, pp. 1495-1517, September 2002.242Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on April 06,2010 at 12:43:30 EDT from IEEE Xplore. Restrictions apply.