On TCP friendliness of VOIP traffic By Rashmi Parthasarathy WSU ID # 10975537 A report submitted in partial fulfillment of the requirements of CptS 555 Electrical Engineering and Computer Science Department Washington State University Fall 2007
On the TCP-Friendliness of VOIP Traffic Tian Bu, Yong Liu and Don Towsley Abstract The premise, upon which I evaluate the TCP-friendliness of VOIP traffic, is content and the necessary justification. In the reminder of this paper I will give a description of the paper as well as the assumptions and claims of the authors. Also I will give my own personal conclusions about the authors work along with sufficient justifications. I. INTRODUCTION Internet is the largest repository of information available today. There are many protocols used for interaction. Two such protocols are TCP and UDP. The major concern of the paper is that UDP applications like skype might throttle the TCP users and bring the internet down. Many internet users and researchers believe that UDP does not adjust to the congestion in the network. That is UDP users do not reduce the sending rate when the network gets congested. But contradictory to the belief, VOIP calls are dropped when the quality becomes unacceptable due to congestion. This paper deals with the fairness between VOIP flows and TCP flows. It tries to prove that backing off will help reduce the traffic when the network gets congested. II. MOTIVATION TCP has a built-in layer congestion control mechanism. Researchers believe that such a congestion control mechanism has to be implemented for VOIP applications as well. Many studies have been done and it suggests that skype still doesn t adjust its sending rates based on the network congestion. But the research misses the main concept of user back-off which is being widely used by most VOIP applications. VOIP call generally involves at least two people. If even one of the users becomes dissatisfied then the call will be dropped. Hence VOIP uses a User-level congestion control mechanism in comparison with TCP that uses a layered congestion control
mechanism. That is, in UDP, the user will drop the call when the quality of the call goes below the expected quality. This paper mainly addresses the question Is VOIP traffic TCP friendly? There are many papers that deal with the TCP congestion control and the models used to characterize the packet delay. This paper considers the user back-off as a congestion control mechanism which most papers have not covered. VOIP users back-off has been quantified by approximating the call drop probability as a function of network loss and packet delay. VOIP is TCP friendly in a sense that the VOIP flow drops faster than the TCP flow in a congested network. VOIP flow is vulnerable under bursty conditions. VOIP flow uses much less bandwidth compared to TCP flows. Hence with these conditions, the author assumes that the VOIP flows will not cause the congestion collapse though they do not have built-in congestion control mechanism. The main objective of the author is to provide a proof that VOIP traffic is indeed friendly with the TCP traffic. The author uses the following to prove that VOIP flows do not cause congestion collapse. I. Network loss model: The quality of service as perceived by the network users is mainly based on packet delay and packet loss. TCP determines the sending rate based on the end to end packet delay and packet loss probability. Also the packet delay has a severe impact on the voice flow than packet delay. Propagation delay is nothing but delay between the source node and the destination node. Hence the packet delay variation is ignored to simplify the analysis. To show the TCP friendliness of VOIP flows, first an evaluation of the interaction between TCP and VOIP users across a WAN is done. The different types of loss models under consideration for this are random loss model, bursty model and transient loss model. a. Random loss model: The packet gets dropped randomly inside the network with the probability of p. When the network is not congested and the link utilization is low and traffic not bursty, the packet loss from a droptail is independent. b. Bursty loss model: If the incoming traffic is bursty then the packet loss will also be bursty. Gilbert model is used to define bursty loss in the internet. A Gilbert loss model has two parameters, unconditional and conditional loss probability,
denoted as p u and p c. The conditional loss probability p c captures loss burstiness which indicates that larger the p c, the more bursty loss is. p and q are transition probabilities between non-loss and loss state. c. Transient loss model: Another reason for packet loss would be due to the link failures in the network. Assumption made is that if a link failure or a router failure occurs, all the packets are assumed to be lost until the equipment gets replaced or the packets rerouted. II. Bottleneck Link Model: The bandwidth sharing among the TCP and VOIP users has been demonstrated by using a simplified bottleneck link model. Traffic flows into a router from different sources like TCP and UDP. The arrival rate can be modeled as a Poisson process. At each router queue management has to be adopted. Most routers employ the drop tail mechanism as a queue management scheme than an Active Queue management. Hence the bottleneck link can be modeled as an M/M/1/k model. So the router v of capacity C v can be modeled as a drop tail queue with a total buffer size of B v. Given the traffic arrival rate X v at router v, the average packet loss probability p v and queuing delay d v can be approximately calculated from either the M/M/1/K model or the M/D/1/K model So the packet drop probability and the queuing delay can be defined as functions of traffic arrival rate and the link capacity. This means that two packets arriving to the queue back-to-back might not get dropped independently. As there are many flows in the internet, the packet loss experienced by one flow might be different from that
experienced by another. An assumption is made that each flow experiences a random loss based on the M/M/1/K type of bottleneck link. III. User adaptation to congestion: The authors next compare how the different types of users adapt to congestion. TCP users reduce their sending rate when they are subjected to loss where as UDP users reduce their rates only if there is a persistent loss or might even drop out completely under severe loss. The different types of flows that are present in the internet are long-lived TCP flows, short-lived TCP flows and UDP flows. Long-lived TCP flow is one where the congestion control phase is longer than the slow start phase. A short-lived TCP flow is one where its congestion avoidance phase is relatively small. UDP flows unlike others do not adjust their sending rates. Some UDP flows might adjust their flows only when there is persistent loss. An example is that of changing the codec when the bandwidth availability becomes low. The call drop of a VOIP call depends on the user, codec used and the playout scheme. The quality of an application carried by a UDP flow is usually determined by end-to-end loss rate and packet delay. However the paper considers the quality of the UDP flow as perceived by the application. That is users behave differently to the same application quality. Therefore the sending rate of a UDP flow is determined by the qualities at different sending rate. When the quality becomes unacceptable, some UDP users may drop the call completely therefore reducing the aggregate traffic rate of UDP flows. IV. VOIP user adaptation to congestion: To see the VOIP user adaptation to network congestion, the author first describes a model that relates the network loss and delay. VOIP voice quality is measured by a mean opinion score (MOS) a subjective quality score that ranges from 1 to 5. MOS are obtained by conducting subjective tests. The MOS is used to identify the call quality. As the MOS value drops the quality of the call also decreases. Hence the calls will be dropped. Eventually all users will drop at low MOS scores. The author makes use of some publicly available subjective test to check the MOS scores.
Figure 1 Traffic rerouting due to transient network failure may take from a few seconds to tens of minutes. During this phase, no calls can be maintained. Thus the calls have to be dropped. But the TCP users resume their transmission soon after recovery from this network failure. By varying the input rate of VOIP flow and changing the TCP flow, the author was able to show that the VOIP calls take less bandwidth compared to other TCP flows. Further the VOIP flow using a low bit rate consumes about only one percent of bandwidth. When the incoming traffic is bursty, the VOIP flow uses a lower codec bitrate. This reduces its rate slowly and hence incurs loss. III. RESULTS OF THE TESTS CONDUCTED First the fairness between a TCP flow and a VOIP flow under random loss is compared and then the loss is made bursty and the results are compared again. A graph is plotted for the short-lived TCP flow and various types of VOIP flows related to the long-lived TCP flow as the loss rate increases from 0.5 percent to 20 percent. The slope suggests that the VOIP flow is TCP friendly as the network gets congested.
Figure 2 When the loss becomes bursty, it can be seen that the VOIP flows become less aggressive Figure 3 IV. CONCLUSION This paper successfully demonstrates that VOIP flows are indeed friendly with TCP flows and also consume less bandwidth when compared to TCP. VOIP flows are also responsive to the network congestion. Hence the notion that VOIP flows will eventually melt down the internet has been disproved. The major strength of this paper is that with quantitative results it has disproved the notion that VOIP flows are harmful to the TCP flows and has in fact proved that VOIP flows are very friendly. The major drawback is that the author is only considering the congestion control mechanism but does not consider other features of TCP. This paper
does not cover the other bandwidth consuming applications like multi-person video conferencing, graphic rich multimedia applications. Applications like skype are built on closed network closed protocol as opposed to open standard like SIP or Jingle. Also the results are based on the users reaction to the quality of the call. It is not clearly mentioned as to under what conditions were these tests conducted.
REFERENCES [1] Unknown, Skype Web Page, http://www.skype.com. [2] Tian Bu, Yong Liu and Don Towsley, On the TCP-Friendliness of VoIP Traffic IEEE Infocom 2006 [3] S. A. Baset and H. Schulzrinne, An analysis of the skype peer- to-peer internet telephony protocol, in Columbia University Technical Report CUCS-039-04, 2004. [4] J. M. Jaffe, Bottleneck flow control, IEEE Transactions on Communications, vol. COM-29, no. 7, pp. 954 962, July 1981