Transcription
In Proc. of International Symposium on Telecommunications (IST2005),Shiraz, Iran, September 2005Adaptive Coding and Packet Rates for TCP-Friendly VoIP FlowsC. Mahlo, C. Hoene, A. Rostami, A. WoliszTechnical University of Berlin, TKN, Sekr. FT 5-2 Einsteinufer 25, 10587 Berlin, Germany.Emails: mahlo@cs.tu-berlin.de, hoene rostami wolisz@tkn.tu-berlin.deAbstractIf low-rate VoIP is transmitted over congestedlinks, both the coding and the packet rate need tobe adapted to achieve the best conversational quality: On an Ethernet network it is better to jointlychange packet rate and speech coding rate; inWLAN networks it is sufficient to change thepacket rate. We also study whether TCP-friendlyrate control algorithms are suitable fordynamically adapting packet and coding rate of aVoIP flow. Our results show that cannot be usedfor VoIP applications as they only control thepacket rate do not consider packet sizes. Also, theydo not transmit small (speech) packets fairly. Wepresent an enhanced version of the TCP friendlyrate control (TFRC) protocol that transmits smallpackets fairly and evaluate it with networksimulations.Keywords: VoIP, packetisation, packet rate, codingrate, TCP-friendliness, TFRC, packet switchingoverhead.IntroductionVoice over IP (VoIP) is increasingly considered tooffer telephone services because it can be used overexisting IP-based access networks and backbones. Inopposite to TCP-based traffic, which still accounts formajority of data transport in IP networks, the sendingrate of VoIP flows usually remains constant over theduration of a call. Of course, available bandwidth isoften plenty enough for VoIP so that there might notbe an immediate need to adapt the sending rate ofVoIP flows dynamically. However, existing andupcoming wireless networks like cellular networks,sensor networks, or multiple hop ad-hoc networksmight require an efficient and low-rate transmissionof application data because wireless links on thosenetworks have sparse capacities. This fact is partlydue to the tremendous costs of the communicationinfrastructure (e.g. base stations), partly due to thetight energy consumption constrains of batterypowered nodes, but also because of restrictions onwireless spectrum usage.In this paper we discuss how such an efficientcommunication may be achieved for voice over IP(VoIP) applications. Our approach is to dynamicallyadapt both the coding rate and packetisation in anTCP friendly manner in order to optimize the qualityof VoIP flows.The conversational call quality of VoIP flows dependson the transmission delay and on the speech quality[2]. For example, a higher coding rate usually gives abetter speech quality. On the other hand, if the packetrate is set low and the packetisation time is high, theoverall transmission delay increases and conversationcall quality is harmed.Both packet and coding rate influence the grossbandwidth requirements of VoIP, either by theamount of user data or the number of packet headers.This leads to an interesting question: If the link iscongested and packet losses occur, should we adaptthe coding or the packet rate? As we show in thispaper, the underlying physical link technology definesthe best adaptation strategy.As a second contribution we consider how to useTCP-friendly congestion control to adapt a low-rateVoIP flow dynamically (Fig. 1).Fig. 1: TCP-friendly VoIP control.
Internet’s congestion control algorithms regulate theresource distribution among multiple flows andprevent a congestion collapse of the Internet [4].Congestion control in the Internet is based on TCP orTCP-friendly transport protocols.It is known that the throughput of a TCP-like protocolscales linearly with the packet size [5]. Thus, theoptimal packet size for TCP-friendly protocols is themaximal transfer unit (MTU). However, this causessome problems in the case of Internet telephony. Infact, due to the interactive nature of telephony, itwould be more useful if small packets at a higher rateare generated instead of generating large packets at alower rate. The reason is that smaller packets enjoylower packetisation time and thus lower transmissiondelays.Our study shows that a fair treatment of small packetsdepends on packet switching overhead of thebottleneck link. As a consequence, we show that if thepacket switching overhead would be known to thecongestion control protocol, the protocol could actfair.The remainder of this paper is organized as follows.First, we continue with a related work section. Inchapter two we present the consideration on codingand packet rate. Then, we discuss the difficulty ofdealing with small packets TCP-friendly. Finally, weconclude.1. Related WorkThe requirements of VoIP differ greatly to those ofTCP-based applications: First VoIP is delay sensitive.An increased delay harms the conversational callquality. Second, to cope with high delay variations adejittering buffer is required, which increases the endto-end delay. Last, VoIP suffer from packet loss.Packet loss decreases the speech quality. An overviewon VoIP quality requirements is given in [2].Bolot [12] has suggested to control the transmissionof packet audio by a joined rate and forward errorcontrol (FEC). Based on the receivers’ packet lossfeedback, the sender lowers coding rate and/orincreased the amount of FEC. Bolot demonstrated theeffeteness of the propose solution experimentally bytransmitting multiple sources of a common 100 kb/slink.In [13] the authors simulated the transmission of voicecommunications over IP networks adapting the codingrate. They showed that an adaptive coding rateoutperforms a fixed rate approach, if transmittedparallel to over TCP-like flows and even constant-rateflows. As Bolot, the authors did not apply a TCPfriendly control schemes nor did they alter the packetrate.Boutremans et al. [14] optimized the rate-, error- anddelay control for interactive VoIP. By applying aquality model, which takes into account both packetloss and delay impairment, the author could findanalytically the best coding rate and amount of FECfor a given packet loss process and round trip time.Also, they included TCP friendliness module, whichcontrol the application data rate, keeping the packetrate constant.In a Voice over WLAN system Veeraraghavan etal. [15] considered an adaptive packetisation. Theproposed system support a single-hop and none IPbased transmission of interactive speech only.None of the rate-control protocols for VoIP jointlyoptimize the packet and the coding rate in a TCPfriendly manner.Widmer presents a comprehensive survey on the latestTCP-friendly congestion control protocols [6] andlists eleven proposals. In [1] we evaluated differentrate control algorithms. Our simulation resultsindicated that TCP-friendly rate control (TFRC [7]) ismost suitable for VoIP, mainly due to its smoothsending rate. Thus, in this paper we concentrate onTFRC.TFRC [7] is based on analytic derived equation,which calculates the packet sending rate of a TCPflow. To gather the parameters necessary for the TCPequation, the receiver sends back loss rate, round triptimes and round trip time variation. The throughput ofTCP is largely influenced by the parameters roundtrip time tRTT retransmission timeout value tRTO,segment size s, and the packet loss rate p. The lossrate is measured in terms of loss intervals, spanningthe number of consecutive loss intervals. A certainnumber of loss intervals are averaged, using decayingweights so that old loss intervals contribute less to theaverage timeouts. The following equation calculatesthe sending rate T of a TCP connection.sT t RTT(2p27 p t RTOp 32 p 338)(1)In [8] the authors suggest a technique for router whichdetects congestion early to avoid extensive packet lossin a network. The Random Early Detection (RED)algorithm monitors the queue lengths of routers. Withincreasing queue length the drop probability isincreased. In contrast, drop-tail queues just droppackets when the queue is full. By early packet lossesRED indicates the TCP protocol that congestion willprobably occur in the future. Thus, the TCP protocoldrops its sending rate to prevent congestion. REDworks with two different modes. The first counts thenumber of packets in the queue and the second countsthe number of bytes in the queue.
In [5] the negative impact of a variable packet size onthe TFRC protocol is analyzed. To recover fairnessbetween flows with different packet sizes a purenetwork-based approach using a RED gateway in bytemode does not ensure fairness. The authors argue thatthe TCP equation cannot be used in conjunction withvariable packets and a simple modification by usingthe MTU as packet size is insufficient. The authorspresent four new algorithms and conclude that theknowledge on the correlation between loss rate andpacket size is important.Figure 3 displays the optimal configuration of packetand coding rate, if the bandwidth is limited.Interestingly, the coding rate needs not to be lowerover a width range of networking conditions. On thepacket rate has to be decreased.2. Coding and Packet RateBoth packetisation and coding rate influence the grossbandwidth requirements of VoIP. The coding ratedepends on the operational mode of codec. Forexample, AMR supports eight different modesbetween 4.75 and 12.2 kbps [3]. Higher coding rateshave a better speech quality. The packetisationcontrols how many speech frames are concatenated inone VoIP packet. For example, AMR generated aspeech frame every 20 ms and VoIP packets have alengths of 20 or 40 ms. If a high packetisation isselected, the packet rate is low and less packet headersare sent.Let us study, how a VoIP flow shall be adapted to acongested link that was limited bandwidth. Weassume that the capacity of a connection remainsconstant and is known. The transmission delay isgiven and remains constant for each packet. Thequestion to answer is how to choose the optimalcoding rate and packetisation under thesecircumstances. In [2], we discuss this question forcircuit-switched and Ethernet links: We calculate thebest VoIP configuration1 on an Ethernet link if bothpacket and coding rate are ideally chosen to limitedbandwidth. We assume the AMR codec and a 150 msend-to-end delay excluding the packetisation time.The Fig. 2 shows that the perfect packetisationincreases if the available bandwidth drops. Only at avery low bandwidth the coding rate needs to bedecreased, too.Let us extend these studies and analyze the IEEE802.11b WLAN protocol. Due to compatibilityreasons 802.11b is the MAC protocol, which seems tohave the highest packet switching overhead of allcommon MAC protocols. The overhead for eachpacket has been calculated and validated in [10]. Weassume a long physical preamble and no RTS/CTS.Then, an 11 Mbps WLAN packet has an overhead ofabout 1500 bytes (For the Ethernet link we used apacket overhead of about 67 bytes.) As in Fig 2,1To measure the conversational call quality we applythe ITU E-model [2]: The R factor considers bothspeech quality and delay. Zero refers to bad quality;100 is perfect call quality.Fig. 2: Choosing optimal coding rate and packetisation on Ethernetlike packet-switched link.Fig. 3: Choosing optimal coding rate and packetisation on anIEEE 802.11b WLAN link.In the case of limited bandwidth, the rate parameter toadapt depends on the underlying networkingtechnology. In the case of a circuit-switched linkwithout any packet overhead, the coding rate shouldbe lowered [2]. On an Ethernet-like link, both codingand packet rate have to be adapted to achieve anoptimal quality. On a link technology with largepacket switching overhead like IEEE 802.11b, thepacket rate should be lowered but the coding rate canremain the same. Thus, this leads to an interestingconclusion on how to support congestion control forlow-rate VoIP. If the bandwidth is to low for evennarrow-band telephony, instead of changing the justcoding rate both the packet and the coding rate has tobe reduced.
3. Small PacketsT ' T factorThe TCP-friendly throughput scales linear with thepacket size as shown in [5]. Thus, in cases ofcongestion TCP transmits packets with the largestpacket size (MTU) to achieve the highest throughput.In case of telephony this leads to a problem. Becauseof the interactive requirement it would be useful, ifsmall packets at a higher rate are generated instead oflarge packets at a low rate. Smaller packets have alow packetisation time and thus decrease the roundtrip time. MSS factor s Flows of small packets are discriminated because if aflow decides to transmit small packets, the link is lessutilized. Then, other parallel flows increase theirsending rate to fill up the capacity gap. Thus, theparallel flows benefit. This fact has been shown – forexample – with ns-2 simulations [1]. This behavior isnot fair because the bandwidth distribution should beindependent of the packet size.(2)αwith 0 α 1T has the unit of byte/s and is a function of the packetsize s. MSS describes the maximum size of a datapacket. The difficulty of the adaptation is in thesuitable choice of the weighting exponent α, whichdepends on the properties of the used transmissionmedium. For example, Fig. 4 shows the graphicalcourse of the factor for selected values of α and atypical value of MSS 1500 byte. This equationworks well for packet size about 120 bytes, assimulation have shown [1].How should be TCP-friendliness be modified so thatthe flow with small packet does not suffer to thatextend that the other flows gain a benefit? Widmersuggested a definition of TCP-friendliness [6], whichis: A flow is TCP-friendly, if other flows devote thesame amount of resource as if the flow would be aTCP flow.In general, TCP-friendly rate control algorithms arenot suitable for the transmission of voice flows thatneed to transmit small packets. For this reason wesuggest two alternate solutions which are suitable toimprove the fairness.First, small packets can be treated differently in therouter, e.g. by the Random Early Dropping. The ideawas to use RED in byte mode instead of packet. Inthis case the arrival of a large packet causes the queueto fill faster and the probability increases that thelarge packet will be dropped. On the other side smallpackets will be dropped with a lower probability.Thus, TCP-friendly flows with small packets aretransmitted at higher rates because of a lower lossrate.Second, the TCP-friendly rate protocols like TFRCcan be changed so that data streams with smallpackets are not disadvantaged. The idea was tochange the TFRC sender, which calculates themaximal sending rate. If a TFRC sender uses a smallpackage size s for the data transmission, this upperlimit of the possible sending rate is reduced. Wepropose therefore an empirical extension of the TCPequation, which produces fairness between differentpackage sizes. The calculated sending rate is enhanced by a weighted ratio of the maximum and thecurrent package size:Fig. 4: Adaptation factor α4. Simulation ResultsThe evaluations of the proposals were performed withthe network simulator ns-2 version 2.1b9 [11]. Thescenario is shown in Fig. 5 and contains a mixture ofwired and wireless network. The bottleneck here iscreated by the shared wireless medium. On thewireless channel we used a Gilbert/Elliott bit errormodel to simulate transmission errors.Fig. 5: Scenario wireless networkFor the evaluation of the protocols we chose awireless transmission rate of 2MBit/s and an activatedRTS/CTS-exchange. Within these simulations wecould take into account the influences of the wirelesschannel on the behavior of the protocols. Theavailable bandwidth of the wireless medium was
exhausted by five simultaneous TFRC connections.The senders were placed in the wired network and thereceivers accordingly in the wireless access network.The simulation time was 120s. The common, wirednetwork path was configured with a transmission rateof 4MBit/s in order not to be the transmissionbottleneck. The delay of this link was 50ms and had adrop tail queue with a sufficient packet buffer size.The wired nodes were connected by 10MBit/s linkswith different but constant delays.In the first simulation, we simulated five parallelTFRC flows sending with packet size of 600 bytesusing a drop-tail queue. We display the sending rateover time in Fig. 6. All five flows have a similarsending rate. In Fig. 7 one flow sends with smallpackets bidirectional. One can clearly see that thesending rate of this flow is far lower whereas the otherfour flows with large packets gain more bandwidth.Fig. 8: TFRC and RED queue in byte modeFigure 9 shows the results of our simulations with theimproved TFRC protocol. Flows with small packetsare treated fairly and have a stable sending rate.However, the factor α has to be chosen properly. Byempirical examination and detailed simulations [1] wehave determined a suitable value of α 0.6 for thetransmission within the wireless Ethernet.Fig. 6: All five TFRC flows use 600 byte packets.Fig. 9: TFRC improvedIn other simulations [1] we replace the wireless linkby a shared Ethernet link. Then the factor α is lowerdue to the lower MAC-overhead and medium accessby collision detection. We have found out a suitablevalue of α 0.35 for this case.ConclusionFig. 7: Four TFRC flows use 600 byte packets and one (bold line)uses 159 byte packets.Next, we simulated the RED queue in byte-droppingmode. In comparison to the drop tail queue results thevariance of the sending rate is higher (Fig. 8). TheTFRC protocol seems to dislike REDs random packetdrops. However, all flows have a similar throughput.Thus, small packets are treated fairly. RED in thebyte-mode increases fairness for small packets at theexpense of stability.If a low-rate VoIP flow needs to reduce its bandwidthto prevent congestion, it must reduce both coding andpacket rate. On WLAN links it is sufficient to lowerthe packet rate as they have a large packet switchingoverhead. This packet switching overhead includesthe packet header but also MAC packet header,contention period, physical framing, and collision2.2Interestingly, using IP header compression does notdecrease the packet switching overhead significant, asit only compresses IP, UDP, and RTP header, whichcontribute only marginally to the switching overhead.
If one wants to use TCP-friendly rate control to selectthe best coding and packet rate of a VoIP flow, somefundamental properties of TCP friendliness have toconsider: Comput. Commun. Rev., vol. 34, no. 2, pp. 137–151, 2004.[6] J. Widmer, R. Denda, and M. Mauve, “A Surveyon TCP-Friendly Congestion Control,” IEEENetwork, vol. 15, no. 3, pp. 28– 37, May 2001.TCP and TFRC just control the packet rate anddo not consider the bandwidth or the packet sizes.They assume that every flow transmits with themaximal transfer unit.[7] S. Floyd, M. Handley, J. Padhye, and J. Widmer,A flow shall be called TCP-friendly, if otherflows devote the same amount of resource as ifthe flow would be a TCP flow.[8] S. Floyd and V. Jacobson, “Random EarlyTo overcome with the issue of small packets,using Random Early Dropping (RED) in the bytemode has been proposed. But RED controlledflows are not stable and RED is not implementedin all routers.[9] ITU, “The E-Model, a computational model forAlternative, we propose an enhanced TFRC,which considers the packet switching overhead ofthe bottleneck path to share the link fairly amongflows with different packet sizes.We think that VoIP, video, games, and transactionslike communication can benefit from small packets.Nevertheless, no standard proposal has been made onhow to support small or variable size packets TCPfriendly. Also, it would be required to inform thesender about the packet switching overhead of thebottleneck link. Otherwise, a fair treatment of flowswith small packets is not possible.References“Equation-based congestion control for unicastapplications,” in SIGCOMM 2000, Stockholm,Sweden, Aug. 2000, pp. 43–56.Detection Gateways fo
If low-rate VoIP is transmitted over congested links, both the coding and the packet rate need to be adapted to achieve the best conversational qual-ity: On an Ethernet network it is better
