Proceedings
`
`21“ IEEE Conference on
`Local Computer Networks
`
`October 13 - 16, 1996
`
`Minneapolis, Minnesota
`
`Sponsored by
`IEEE Computer Society Technical Committee on C
`Computer Communications
`
`IEEE Computer Society Press
`
`Los Alamitos, California
`
`Washington
`
`- Brussels
`
`-
`
`Tokyo
`
`RPX Exhibit 1032
`
`RPX Exhibit 1032
`RPX v. DAE
`
`RPX V. DAE
`
`

`
`
`
`IEEE Computer Society Press
`10662 Los Vaqueros Circle
`P.O. Box 3014
`
`Los Alamitos, CA 90720-1264
`
`Copyright © 1996 by The Institute of Electrical and Electronics Engineers, Inc.
`All rights reserved.
`
`Copyright and Reprint Permissions: Abstracting is permitted with credit to the source. Libraries may
`photocopy beyond the limits of US copyright law, for private use of patrons, those articles in this volume
`that carry a code at the bottom of the first page, provided that the per-copy fee indicated in the code is paid
`through the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923.
`
`IEEE Copyrights Manager, IEEE
`Other copying, reprint, or republication requests should be addressed to:
`Service Center, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331.
`
`The papers in this book comprise the proceedings of the meeting mentioned on the cover and title page. They
`reflect the authors’ opinions and, in the interests of timely dissemination, are published as presented and
`without change. Their inclusion in this publication does not necessarily constitute endorsement by the
`editors, the IEEE Computer Society Press, or the Institute of Electrical and Electronics Engineers, Inc.
`
`IEEE Computer Society Press Order Number PR07617
`IEEE Order Plan Number 96TB100073
`
`Library of Congress Number 83-641144
`
`ISBN 0-8186-7617-5 paper
`ISBN 0-8186-7619-1 microfiche
`
`ISSN 0742-1303
`
`IEEE Computer Society Press
`Customer Service Center
`10662 Los Vaqueros Circle
`P.O. Box 3014
`Los Alamitos, CA 90720-1264
`Tel: +1-714-821-8380
`Fax: +1-714-821-4641
`Email: cs.books@computer.org
`
`Additional copies may be orderedfrom:
`
`IEEE Service Center
`445 Hoes Lane
`P.O. Box 1331
`Piscataway, NJ 08855-1331
`Tel: +1-908-981-1393
`Fax: +1-908-981-9667
`
`IEEE Computer Society
`13, Avenue de l’Aquilon
`B-1200 Brussels
`BELGIUM
`Tel: +32-2-770-2198
`Fax: +32-2-770-8505
`
`IEEE Computer Society
`Ooshima Building
`2-19-1 Minami-Aoyama
`Minato-ku, Tokyo 107
`JAPAN
`Tel: +81-3-3408-3118
`Fax: +81-3-3408-3553
`
`Editorial production by Regina Spencer Sipple
`Cover design by Joseph Daigle/Studio Productions
`
`Printed in the United States of America by KNI, Inc.
`
`® The Institute of Electrical and Electronics Engineers, Inc.
`
`

`
`This material may be protected by Copyright law (Title 17 U.S. Code)
`
`

`
`low bit-rate audio
`a Loss sensitivity is high for
`streams due to the high information density of
`the encoded stream and the common practice of
`transmitting relatively long audio intervals in each
`packet. Putting long intervals of speech into each
`packet is motivated by the desire to avoid consum-
`ing a significant fraction of the network bandwidth
`
`with packet headers. For example, a 17 kbits/s
`data rate generates only 170 bytes in an 80 ms pe-
`riod. If this data is carried as a Real-Time Proto-
`
`col (RTP) [20] packet over UDP, each audio packet
`includes 40 bytes of protocol header before link
`layer encapsulation (12 bytes for the RTP header,
`8 for UDP, and 20 for II’). If the packet size were
`40 ms, one-third of the total bandwidth used to
`transmit the audio stream would consist of pro-
`tocol overhead. As a result Internet—based audio
`
`protocols typically use 80 ms or larger packets for
`low-bandwidth links, in contrast with 20 or 40 ms
`
`packets for higher bandwidth links.
`
`Loss sensitivity is difficult to quantify and heavily
`dependent on the encoding technique. With large
`packets, however, even single-packet losses are of-
`
`ten significant for quality and /or intelligibility at
`the receiver
`Since interpolation techniques to
`mask losses at the receiver do not work well for
`
`large packets [9], packet-level error control is at-
`tractive for low—bandwidth audio.
`
`Natural
`
`interactive conversation is difficult
`
`for
`
`users to maintain when the roundtrip delay expe-
`rienced exceeds a few hundred milliseconds. While
`
`the threshold involves subjective judgments of
`quality, studies have reported minimal detrimental
`effect for one-way delays in the 200-300 ms range
`
`[4, 22, 13] and users reporting annoyance with
`one—way delays in the 320-440 ms range [22, 10].
`However, [10] reports that, while users complained
`about delays in the latter range, they also compen-
`sated effectively for them in the context of video-
`conferencing.
`
`To meet the requirement for bounded roundtrip
`
`delays, audio protocols focus on the one-way end-
`to-end delay of the audio samples. The compo-
`nents of end-to-end delay include: the time audio
`data spends at the sender during packetization,
`network delays, buffering and hardware delays at
`the audio receiver. The component delays most
`
`readily controlled by the audio protocol are the
`packet size used for network transmission and the
`receiver buffering algorithm.
`
`In the campus—to—home network scenario, end—to-
`end delays tend to be long due to the transmission
`latency over the dial-up link and the long packe-
`
`tization time at the transmitter. Long end—to—end
`delays place pressure on the receiver buffering al-
`gorithm to minimize the buffering time, if interac-
`tive or near-interactive delays are to be achieved.
`
`In this study two popular Internet audio tools are
`used to collect packet-level
`traces of audio streams
`transmitted over a campus-to—home connection,
`i.e.,
`across a campus network followed by a modem-based
`dial-up connection. With these traces, a simulation
`study is constructed to investigate trade—offs in delay
`and loss during audio playback.
`In addition to jitter
`control, the simulations are used to extrapolate the ef-
`
`fects of using a version of the redundancy-based error
`control scheme proposed in [3] for protecting the audio
`stream from network loss. Support of error control was
`
`not considered in the design of current jitter buffer al-
`
`gorithms, and the simulation results demonstrate that
`modification is required to support this form of error
`control effectively. Modification of one well-known jit-
`
`ter algorithm is proposed and the performance trade-
`offs evaluated.
`
`The paper is organized as follows. Section 2 dis-
`cusses key points of terminology, background, and re-
`lated work on Internet audio transmissions. Section 3
`
`describes how the packet-level traces of audio transmis-
`sions for this study were obtained. Section 4 analyzes
`the conventional receiver buffering algorithm and the
`proposed modification using trace-driven simulations
`
`of the audio playback. Section 5 presents conclusions.
`
`2. Background and Related Work
`
`In order to discuss related work, it is important to
`establish a consistent terminology, which can be de-
`
`rived from the timeline for audio playback in Figure 1.
`Packet speech consists of bursts of activity, talkspurts,
`
`separated by pauses, silence periods. As shown in Fig-
`ure 1, we denote the transmission time of the ith packet
`in a talkspurt as time t, and its arrival time at the au-
`dio receiver as a,~. The packet size of the ith packet
`is defined as A, = t,~ — t,~_1, and the network delay
`
`346
`
`

`
`work on TCP roundtrip time estimation done by Van
`
`Jacobson [11]. For the other packets in a talkspurt,
`
`Ih=P1+t¢-ti
`
`(4)
`
`Jitter buffering strategies differ only in the way they
`estimate cl, in Equation 3.
`Given stochastic network delays, buffering algo-
`rithms attempt to adapt the hold time to changing
`network delay and delay variations. The accuracy of
`
`a measuring a packet’s network delay is itself depen-
`dent on factors such as timestamp granularity and lo-
`cal clock drift. Adaptation to changes in the network
`delay requires some form of filtering past samples, e.g.,
`using a low-pass filter modeled after the TCP roundtrip
`time estimator. For wide-area Internet transmissions,
`
`the effects of sudden large changes in the delay, delay
`spikes, can skew network delay estimates badly. The
`
`study in [18] develops a network delay estimator (Al-
`gorithm 4) that explicitly considers the phenomenon
`of delay spikes. Using wide—area Internet audio traces,
`this estimator is shown to perform somewhat better
`than three other buffering algorithms for jitter control.
`Using a similar motivation, [2] also gives an algorithm
`designed to recover quickly from sudden delay spikes
`and presents evidence of good performance.
`I
`Work in timely recovery of network losses has ad-
`vanced rapidly in recent years. Retransmission-based
`schemes have been proposed and shown effective un-
`
`der some conditions [5, 6], but, in the campus-to-home
`audio scenario, retransmission is not viable for inter-
`
`active trafiic due to high roundtrip delays. Receiver-
`only techniques refer to those that attempt to mask
`lost packets using interpolation at the receiver, such
`as waveform or silence substitution. The large packet
`sizes associated with low-bandwidth audio, however,
`render these techniques much less effective than with
`
`With redundant transmissions, a
`shorter packets
`source sends multiple copies of the audio data so that
`
`the impact of packet losses is mitigated by the arrival
`of at least one copy of the data at the receiver. Re-
`dundancy avoids the latency penalty of retransmission,
`at the expense of some additional network bandwidth,
`computation, and delay.
`This study focuses on redundancy-based error con-
`trol since this technique is applicable to our network
`scenario and has demonstrated promise for maintain-
`
`Figure 1. Playback Timeline for Audio.
`
`is d,- = a,~ — t,-. At the audio receiver, each packet in
`the talkspurt has a scheduled playback time, pi. The
`end-to-end delay of the ith packet is the time between
`placement of the first audio sample into the ith packet
`at the transmitter and the beginning of the playback
`of that packet at the audio receiver,
`
`62' =Pz' _té+Aé
`
`(1)
`
`The time spent by the ith packet in the receiving buffer
`before being submitted to the audio playout device is
`the slack of the ith packet
`
`31' =Pz' — ai-
`
`(2)
`
`The purpose of the buffering algorithm at the re-
`ceiver is to calculate a hold time before the first packet
`in atalkspurt is played out. The hold time, 31,
`is
`crucial since it determines the playback time for all
`subsequent packets. For jitter control, the hold time
`calculation has the competing goals of minimizing the
`extra delay introduced by buffering while ensuring that
`each packet has a positive slack.
`The playback time for each packet is usually de-
`termined by a timestamp, either implicit or explicit,
`carried in the packet and an estimate of the network
`delay.
`In the context of jitter control, several meth-
`ods for network delay estimation have been proposed
`
`[15, 18, 2, 1, 14]. Given an estimator for network de-
`lay, most audio protocols determine the playback time
`of each packet as follows. For the first packet in a talk-
`spurt
`
`P1 = t1 + Li,‘ + 4'1’),
`
`(3)
`
`where cl, and 17, are estimates of the mean and variation
`of the network delay. The use of 413,- is motivated by the
`
`ing good audio quality over wide—area lossy paths [3, 8].
`For low-bandwidth links, this technique could be used
`
`347
`
` .
`
`a1
`
`ai+1
`
`9-
`1
`
`P.
`1 1
`
`I
`Receiver .
`.
`
`II I
`
`'e————--—>
`
`S _
`I
`
`

`
`as sz'ngle—copy redundancy, that is, the n + 1st packet
`of the audio stream carries an LPC-encoded version of
`
`Source
`
`If the nth packet is lost, the
`the nth audio packet.
`LPC-encoded version of that packet arrives in packet
`
`n + 1 for playback. A study [9] has shown that LPG-
`based redundancy is superior to receiver—only substitu-
`
`tion methods in the case of large packet sizes (80 ms)
`that are commonly used in low bit-rate audio transmis-
`sions.
`
`the high network la-
`With low—bandwidth audio,
`tency requires open-loop error control, and small
`amounts of redundancy will be effective in mitigating
`the effects of isolated losses. In order for redundancy-
`based error control to be effective, the low-resolution
`
`copy of the data must arrive in a timely fashion when
`a loss occurs. Specifically, for single-copy redundancy,
`if the loss of the ith packet in the network is to be
`recovered, it must be the case that
`
`pi"a~i+1 > 0
`
`(5)
`
`Buffering algorithms developed for jitter control have
`not been designed to consider this delay constraint ex-
`plicitly. We evaluate the implications of this constraint
`in Section 4.
`
`3. Packet Audio Traces
`
`This section first describes the measurement exper-
`iments used to capture packet-level traces of audio
`
`transmissions across a path combining LAN transmis-
`sion and a dial-up connection. The four traces selected
`for use in this paper are then presented and briefly dis-
`cussed.
`
`3.1. Transmission Scenario
`
`For the experiments two software audio tools were
`
`selected: vat (version 3.4) [12] running on a Sun Ultra-
`Sparc workstation and a PC—based conferencing pack-
`age, CoolTalk, embedded in the popular WWW client,
`Netscape Navigator 3.0. The audio source, a recorded
`classroom discussion, was transmitted from the source’
`machine to a receiving machine located on the same
`
`Ethernet, but it was routed over a dial-up connection
`and a campus local area network, as shown in Figure 2.
`The co-location of source and sink machines allow for
`
`direct measurement of the one—way network delays us-
`ing a third machine on the same Ethernet.
`
`._.
`<1)
`E
`.8
`5
`
`PC Router
`
`Cisco
`Router
`
`
`
`Dial-Up Line
`
`Campus Local Area Network
`
`
`
`
`Packet
`Snooper
`
`Sink
`
`Figure 2. Network Path for Packet Audio
`Transmissions.
`
`The audio stream is sent from the source machine
`across an Ethernet to a 133 MHZ Pentium PC Linux-
`
`based machine that routes the packets across a dial-up
`line. The dial-up line uses the Point-to-Point Proto-
`
`col and has 28.8 kb/s V.34 US Robotics modems on
`each end. At the remote end, a Xylogics Micro Annex
`terminal server is connected directly to the campus net-
`work. After transmission over the dial-up connection,
`the audio stream travels over a path through the cam-
`pus network back to the original local area network
`where the destination machine is located. The path
`through the campus local area network consists of an
`FDDI ring bridged to a campus backbone. Note that
`the technique to create an artificial out—and—back route
`
`does not use IP routing options, i.e., source routing,
`since many IP routers give low priority forwarding to
`IP packets with options.
`
`On the Ethernet connected to the audio sender and
`
`receiver, the packet trace is captured using a commer-
`cial network monitoring tool, LANWatch 3.10 by FTP
`Software, running on a 90 MHz Pentium PC. Times-
`
`tamping of packet events occurs with millisecond gran-
`ularity in the monitor, and these timestamps enable the
`
`direct measurement of one—way network delays. Exper-
`iments show the capture machine has no difficulty keep-
`ing up with the low—bandwidth audio transmissions.
`Hence packet loss during network transmission can be
`accurately measured as well.
`
`348
`
`

`
`Packet Size
`
`80 ms
`
`80 ms
`72 bytes
`
`130 ms
`206 bytes
`
`206 ms
`
`206 bytes
`161 ms (14)
`
`Trace vat-lpc
`
`Trace CT-High
`Trace C'T~Low
`
`110 ms (17)
`173 ms (17)
`
`
`
`Table 2. Network Delay and Packet Size.
`
`ence is significant, due to the importance of packet size
`
`in determining the amount of receiver buffering needed
`for error control, as will be shown in Section 4. Note
`
`that the nominal transmission time over a 28.8 kbits / s
`link for a 206 byte UDP datagram is around 70 ms
`while the measured mean. delays for the CoolTalk traces
`are 163 ms and 173 ms. Significant queuing delays are
`being added at some element(s) in the network path.
`While we can only speculate about where this delay
`occurs in the network path, the dial-up connection is
`
`suspect since data modern transfers are generally opti-
`mized for throughput, not latency.
`
`4.
`
`'I‘race-Based Simulation of Receiver
`
`Buffering
`
`In this section we describe a simulation of playback
`
`timing at the audio receiver using the empirical net-
`work traces. We motivate our selection of a jitter
`buffering algorithm for study and present a generaliza-
`tion to accommodate redundancy-based error control.
`
`The performance of the algorithms are thenievaluated
`in simulation using delay and loss metrics.
`To construct the playback schedules at the audio
`receiver, a network trace is selected and used to set
`
`the sending and receiving time for each packet. Talk-
`spurt boundaries are inferred using a silence threshold
`
`of slightly more than two packet sizes. The playback
`time of each packet is then determined from Equation 3
`
`and Equation 4. Following the absolute timing method
`[14] for playback, packets arriving after their playback
`time are ignored at the receiver and do not alter the
`playback schedule for other packets.
`
`As our baseline receiver buifering algorithm (re-
`ferred to below as the basic algorithm), we use an algo-
`rithm based on a widely recognized heuristic for esti-
`mating network delay, namely Jacobson’s work on TCP
`
`
`
`
`
`
`
`
`
`
`
`
`
`Tool/
`Options
`
`WeekDay/
`Time
`
`Thursday
`10:00 AM
`
`Thursday
`10:30 AM
`
`vat
`
`Trace vat-lpc
`
`LPC
`
`Trace CT-High unknown
`
`CoolTalk
`
`Wednesday
`2:00 PM
`
`28 kbits/s
`CoolTalk Wednesday
`
`Trace CT-Low
`
`unknown
`
`
`
`14 kbits/s
`
`3:00 PM
`
`Table 1. Packet Audio Transmissions.
`
`
`
`
`
`
`
`
`3.2. Selected 'I‘races
`
`Table 1 shows the set of audio transmission traces
`
`selected for the analysis in this paper.. The traces were
`obtained on different weekdays in different weeks, and
`each trace lasts for at least 400 seconds. Each trace
`
`represents a different set of protocol parameters for
`low bit-rate audio. Trace vat-gsm and Trace vat-lpc
`use the vat tool where the audio stream is encoded
`
`at 17 kbits/s GSM and 4.8 kbits/s LPC, respectively.
`Trace CT-High and Trace CT-Low are transmissions
`using the commercial CoolTalk tool in two different
`modes identified in the CoolTa1k interface: one for 28.8
`
`Icbits/s or higher (Trace CT-High) and the other for
`14.4 kbits/s (Trace CT—L0w). The CoolTalk documen-
`tation does not reveal the actual encoding/ compression
`schemes that are associated with these interface op-
`tions.
`
`Figures 3 through 6 show the measured one—way net-
`work delays for the traces in Table 1. Packets lost in
`
`the network are shown as having a network delay of
`zero. Packet loss in the traces shown is low, ranging
`from virtually no loss in Trace vat-gsm to 1.14% in
`Trace CT-Low. The majority of loss is due to an iso-
`
`lated single packet loss (82%), and all other incidents
`of loss were all either two packets in length (16%) or
`three packets (2%). These loss patterns bear out the
`utility of employing single-copy redundancy for error
`control in that most losses are single-packet drops.
`
`Table 2 gives a summary of packet size, packet pay-
`load, and network delay statistics. Virtually all the
`audio packets within a network trace have the same
`
`packet size and payload. The vat tool uses 80 ms pack-
`ets while C0olTalk has much larger packets. The differ-
`
`349
`
`UDP Payload Network Delay
`mean (sdev)
`156 ms
`
`(
`
`28)
`
`146 bytes
`
`

`
`
`
`NetworkDelay(ms)
`
`Send Time (ms)
`
`Figure 3. Network Delays for Trace vat-gsm.
`350
`
`
`NatworkDelay(ms)
`
`Send Time (ms)
`
`
`
`
`Figure 5. Network Delays for Trace CT-High.
`
`Send Time (ms)
`
`4Send Time (ms)
`
`Figure 4. Network Delays for Trace vat-Ipc.
`
`Figure 6. Network Delays for Trace CT-Low.
`
`350
`
`

`
`roundtrip estimation [11]. The algorithm estimates the
`network delay d,- in Equation 3 as follows
`
`cl,-zaxdh,-_1+(1—a)><d,‘
`
`(6)
`
`and the variation 13,- in Equation 3 as
`
`1‘1,==a><17,'_1+(1~a)x|cl,~—d,~[
`
`(7)
`
`To limit sensitivity to short—term packet jitter and in
`
`accordance with [19], the fixed weighting factor, or, is
`chosen to be, as = 0.998.
`
`This algorithm is presented as Algorithm 1 in [18]
`where, for wide-area Internet audio transmissions, its
`
`performance is compared with three other heuristics.
`Only Algorithm 4 outperforms the basic algorithm.
`As noted earlier, however, the central feature of Algo-
`rithm 4 is its explicit consideration for the phenomenon
`of rapid, short-lived delay fluctuations, or delay spikes,
`when updating the network delay estimator, Li. While
`delay spikes are common in wide-area Internet traflic,
`the campus-to-home network path measured here very
`rarely exhibits this behavior. We therefore do not in-
`clude in our study Algorithm 4 or a similarly motivated
`algorithm in
`
`As with other designs proposed for adaptive buffer-
`ing at the voice receiver, the basic algorithm presented
`in Equation 6 and Equation 7 focuses on jitter con-
`trol. The goal of jitter control algorithms is to ensure
`positive slack for each packet, i.e., pi — a,- > 0 for the
`ith packet. However, in order to support redundancy-
`
`based error control in the audio stream, buffering con-
`siderations should be based on the condition in Equa-
`
`tion 5, i.e., pi —- a.-+1 > 0. Since packet i + 1 enters
`the network at the transmitter exactly one packet time
`later than packet 2', a natural modification is to add
`enough buffering to increase the slack of each packet
`
`by one packet size. To study the effects of additional
`buffering, our approach uses Equation 6 and Equa-
`tion 7 unmodified, but adds a constant scaling factor
`
`(A) in Equation 3 as follows:
`
`p1=t1+d,-+4'f),-+A><[§,-
`
`(8)
`
`where A, is a weighted average of the packet size calcu-
`lated at the receiver, e.g., A; = a x A,-_1 + (1 ——a) x A,-.
`Note that the basic algorithm is now simply the case
`A = 0.0.
`
`
`
`LakePackets
`
`(%)
`
`Scaling Factor (lambda)
`
`'
`
`Figure 7. Jitter Loss.
`
`4.1. Performance Evaluation
`
`This section presents the performance trade-offs in
`
`choosing a value of A for the parameterized buffering
`heuristic defined by Equation 6, Equation 7, and Equa-
`tion 8. The simulation construction enables the ‘perfor-
`
`mance of different buffering algorithms, as defined by
`dilferent values for A, to be compared for the exact
`same traffic pattern, namely each of the four network
`traces in Table 1. The performance criteria for com-
`
`paring buffering algorithms include the percentage of
`packets due to insufficientbuffering for delay jitter, the
`percentage of packets for which single—copy redundancy
`error control provides single-packet loss protection, and
`the end-to-end delay distribution. Note that, due to
`the natural tension between reducing -jitter loss and
`minimizing end-to-end delay, small negative values for
`A are possibly attractive and are included in the study.
`
`4.1 .1
`
`Jitter Control
`
`Figure 7 plots the value of A on the horizontal axis and
`the percentage of packets lost due to late arrival at the
`receiver, e.g., a,- — p,- < 0, on the vertical axis. The
`graphs are piecewise linear interpolations of discrete
`values for the values A = -0.25, 0.0, 0.25, 0.50, and each
`
`curve represents the jitter loss under a specific network
`trace, as labeled.
`
`The data shows that the basic algorithm (A = 0.0)
`
`351
`
`

`
`
`
`ErrorCoverage
`
`(94,)
`
`0.25
`0.5
`Scaling Factor (lambda)
`
`0.75
`
`1
`
`Figure 8. Error Coverage under Single-Copy
`Redundancy.
`
`results in 2—5% loss due to jitter. Given that this level
`of loss may be tolerable, it is interesting to consider
`
`more aggressive buffering, e.g., A = -0.25. As shown,
`for the vat traces, reducing the buffering delay by a
`
`quarter of a packet size results in only modest increases
`
`in the jitter loss, 6.7% for vat—gsm and 7.2% for vat-
`lpc. However, for the CoolTalk traces, the use of larger
`packet sizes and low network delay variation results in
`much less tolerance for less buffering, and the loss level
`explodes to 33.1% for C’T—Hz'gh and 86.4% for C’T—Low.
`
`(The latter value is not shown in Figure 7 to avoid
`distortion of scale.)
`
`Supporting error control implies consideration of
`positive values of A. Figure 7 shows that even a small
`amount of additional buffering as with A = 0.25, which
`is 20-50 ms, produces dramatically fewer jitter losses.
`Three of the traces have less than 0.5% loss when
`
`A = 0.25, and the fourth, Trace vat—lpc, reaches that
`level at A = 0.50.
`
`4.1.2 Single-Copy Redundancy Error Control
`
`Figure 8 plots the value of A against the percentage of
`packets that would be protected against single-packet
`losses if single—copy redundancy were included in the
`audio stream. That is, the vertical axis plots the per-
`
`tion 5). For simplicity, the simulation does not attempt
`to account for the additional delay due to the LPC-
`encoded data carried in each packet. Network delays
`will be larger with the inclusion of LPG data, but, Ta-
`ble 2 in Section 3 indicates low sensitivity in our mea-
`
`surements between the size of the audio packet and the
`
`network delay variation of the packet stream. Delay
`variation is the parameter on which the performance
`
`plotted in Figure 8 is strongly dependent.
`As shown in Figure 8, under the out traces, the basic
`
`algorithm provides error coverage for almost 50% of
`single—packet losses.
`In the CoolTalk traces, on the
`other hand, there is virtually no coverage. Using A =
`-0.25 still results in 40% coverage under vat-gsm, but
`coverage less than 20% for the vat-lpc trace. The cat
`traces reach approximately 80% coverage under A = 0.5
`
`and converge to around 93% at A = 1.0. In contrast,
`the CoolTalk traces have low coverage at A = 0.5 and
`only 75-79% at A = 1.0.
`
`Error coverage can not be 100% when using single-
`copy redundancy. The last packet in each talkspurt has
`no following packet to deliver its LPC—encoded replica
`in a timely fashion. In Figure 8, for each network trace,
`the percentage of the packet stream that can be pro-
`tected from single-packet loss is indicated by a horizon-
`tal line. The lower percentage for the CoolTalk traces
`
`reflects the fact that the average number of packets
`in a talkspurt decreases as the audio packet size in-
`creases. The data shows that 10-13% of the packets in
`the CoolTalk audio stream can not be error controlled
`
`while approximately 5% can not under vat.
`
`4.1.3 End-to-End Delay
`
`For interactive speech, the impact of more buffering
`delay at the receiver must be considered in light of the
`need for low end—to—end delays. Figure 9 plots the end-
`to-end delay distribution curve for Trace vat-gsm under
`A = -0.25, A = 0, and A = 0.25, with indications of the
`90th, 95th, and 99th percentiles for the A = 0 curve.
`
`Figure 10 plots the same information for CT-High.
`End-to-end delay is a function of network delay and
`
`packet size. The packets in Trace vat-gsm experience
`more network delay variation than those in ‘Trace CT-
`
`High, resulting in a longer tail for the end-to-end delay
`distribution of the former. However, due to its 50 ms
`larger packet size, Trace CT-High has larger delays in
`
`the early part of the delay distribution curve.
`
`centage of audio packets for which p,,—a,,+1 > 0 (Equa-
`
`The figures illustrate that most packets in our net-
`
`352
`
`

`
`Cumulative
`
`Probability
`
`
`
`CumulativeProbability
`
`0.9
`
`0.8
`
`0.7
`
`0.5
`
`0.4
`
`lambda = -0.25 —~.-r'
`lambda = 0.0 ----.n
`
`9% percentile
`
`0.3
`
`350
`
`450
`400
`End-to-End Delay (ms)
`
`500
`
`550
`
`600
`
`650
`
`200250300350
`
`400
`450500550600650
`End-to-End Delay (ms)
`
`Figure 9. End-to-End Delay Distribution for
`Trace vat-gsm.
`
`Figure 10. End-to-Eind DelayDistribution for
`Trace CT-High.
`
`work traces experience delays that are at best at the
`high end of the threshold for truly interactive user con-
`versation and most probably beyond that threshold.
`Using different values of A in the receiver buffering algo-
`rithm shifts the overall delay distribution by fractions
`
`of the packet size, at least for cumulative probabilities
`below the knee of the delay curve, e.g., around 0.85
`
`to 0.90 in both figures. After the knee is reached, the
`delay shift is less pronounced in the tail of the distri-
`bution curve.
`
`The overriding question suggested by Figure 9 and
`Figure 10 is: What is the impact on user-perceived qual-
`ity of delay shifts on the order of A = 0.25 or A = 0.50 .9.
`
`5. Conclusion
`
`The paper has presented an evaluation of receiver
`buffering policies for error—control1ed Internet packet
`audio over low-bandwidth links. Packet-level traces
`
`of audio over a campus—to-home network path were
`collected and used to construct a simulation study
`
`It was
`grounded in empirical traffic measurements.
`shown that supporting a novel open-loop error con-
`
`trol scheme proposed in [3] requires a rethinking of re-
`ceiver buffering algorithms, which have conventionally
`focused only on jitter control. The simulations inves-
`
`tigate the impact of providing an amount of buffering
`that ensures, with high probability, that a second copy
`of lost audio data will arrive at the receiver before its
`
`playback deadline passes.
`
`,
`
`The results emphasize that the amount of additional
`
`If this amount of delay changes the audio quality little,
`then additional buffering appears to be very useful in
`
`buffering required for error control is heavily dependent
`on the audio packet size. In the case of 80 ms packets,
`
`improving quality through the reduction of jitter losses
`and network drops. If quality is sensitive to these de-
`lay shifts, then the advantages of additional buffering
`for reducing losses may have to be foregone.
`In this
`case, more investigation of the possibilities for using
`negative values of A are warranted. Unfortunately, a
`
`rigorous study of user-level quality perceptions was be-
`yond the scope of the current study.
`
`as used with vat, significant error coverage is available
`for little additional buffering at the receiver. For ex-
`ample, approximately 80% of the packets in the vat au-
`dio stream were protected against single-packet losses
`by using only 40 ms (A = 0.5) of additional buffering
`at the beginning of each talkspurt. In contrast, with
`the 130 ms and 206 ms packets used in the CoolTalk
`
`tool, large amounts of additional buffering (e.g., above
`
`353
`
`

`
`In
`[11] V. Jacobson. Congestion avoidance and control.
`ACM Sigcomm, pages 314-329, London, England,
`Aug. 1988.
`[12] V. Jacobson and S. McCanne. The LBL audio tool
`vat. Manual page, July 1992.
`[13] R. M. Krauss and P. D. Bricker. Effects of transmission‘
`delay and access delay on the efficiency of verbal com-
`munication. Journal of Acoustic Soc Am, 41:286—292,
`1967.
`
`[14] W. A. Montgomery. Techniques for packet voice syn-
`chronization. IEEE Journal on Selected Areas in Com-
`
`CoolTalk.
`
`munication, SAC-1(6):1022—1028, December 1983.
`[15] W. E. Naylor and L. Kleinrock. Stream traffic com-
`munication in packet switched networks:
`destina-
`tion buffering constraints.
`IEEE Computer, COM-
`30(12):2527~2534, December 1982.
`[16] Netscape Communications Corporation.
`http://home.netscape.com/.
`[17] Progressive
`Networks.
`http: //www.realaudio.com/ .
`[18] R. Ramjee, J . Kurose, D. Towsley, and H. Schulzrinne.
`Adaptive playout mechanisms for packetized audio ap-
`plications in wide-area networks. In IEEE INFOCOM,
`Toronto, Canada, June 1994.
`[19] H. Schulzrinne. Voice communication across the In-
`ternet: A network voice terminal. Technical Report
`TR 92-50, Dept. of Computer Science, University of
`Massachusetts, Amherst, Massachusetts, July 1992.
`[20] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacob-
`son. Rtp: A transport protocol for real-time applica-
`tions. Request for Comments (Standards Track) RFC
`1889, Internet Engineering Task Force, January 1996.
`[2].] Vocaltec,
`Inc.
`Internet
`Phone.
`http://www.vocaltec.com/.
`[22] C. G. Wolf. Video conferencing: Delay and transmis-
`sion considerations. In Teleconferencing and Electronic
`Communications: Applications, Technologies, and Hu-
`man Factors, pages 184-188. 1982.
`[23] Xing Technology Corporation.
`http://wwwxingtech.com/.
`
`Real
`
`Audio.
`
`‘Streamworks.
`
`100 ms) often provides poor or at best modest amounts
`of error coverage. Even a full packet size of additional
`delay yields only about 75% coverage.
`In conclusion, our study provides strong evidence
`
`that open-loop error control can be readily supported
`in low bit-rate audio transmissions using 80 ms or
`
`smaller packets. The buffering to support error con-
`
`trol, moreover, has the significant extra benefit of al-
`most eliminating jitter loss. For packet sizes beyond
`80 ms or for protection against burst losses, however,
`
`buffering adequate for redundancy-based error control
`will likely preclude any ability to provide interactive de-
`lays. Ultimately, the correct balance between loss and
`delay is determined by the trade-offs of user-perceived
`
`quality, and further study of these issues is merited.
`
`References
`
`[1] F. Alvarez—Cuevas, M. Bertran, F. Oller, and J. M.
`Selga. Voice synchronization in packet switching net-
`works. IEEE Networks, 7(5):20—25, September 1993.
`[2] J .—C. Bolot and A. V. Garcia. Control mechanisms for
`packet audio in the internet. Unpublished, 1995.
`[3] J .-C. Bolot and A. V. Garcia. Control mechanisms for
`packet audio in the internet. In