Proceedings
`
`Volume 3
`
`IEEE INFOCOM’96
`
`The Conference on Computer Communications
`
`Fifteenth Annual Joint Conference of the IEEE Computer
`and Communications Societies
`
`Networking the Next Generation
`
`March 24-28, 1996
`
`San Francisco, California
`
`Sponsored by
`
`IEEE Computer Society
`
`IEEE Communications Society
`
`IEEE Computer Society Press
`
`Los Alamitos, California
`
`Washington
`
`o
`
`Brussels
`
`o
`
`Tokyo
`
`RPX Exhibit 1026
`
`RPX Exhibit 1026
`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 dissernination, 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 ofElectrical and Electronics Engineers, Inc.
`
`IEEE Computer Society Press Order Number PR07292 (set of 3 volumes)
`IEEE Order Plan Catalog Number 96CB 35887
`ISBN 0-8186-7292-7 (paper)
`IEEE Order Plan ISBN 0-8186-7293-5
`Microfiche ISBN 0-8186-7294-3
`ISSN 0743-166X
`
`Additional copies may be orderedfrom:
`
`IEEE Computer Society Press
`Customer Service Center
`10662 Los Vaqueros Circle
`PO. Box 3014
`Los Alamitos, CA 90720-1264
`Tel: +1-714-821-8380
`Fax: +1-714-821-4641
`Email: cs.books @computer.org
`
`IEEE Service Center
`445 Hoes Lane
`P.O. Box 1331
`Fiscataway, NJ 08855-1331
`Tel: +1-908-981-1393
`Fax: +1-908-981-9667
`misc.custserv@computer.org
`
`IEEE Computer Society
`13, Avenue de l’Aqui]on
`B—l200 Brussels
`BELGIUM
`Tel: +32—2-770-2198
`Fax: +32-2-770-8505
`euro.ofc@computr.org
`
`IEEE Computer Society
`Ooshima Building
`2-19-1 Minami-Aoyama
`Minato-ku, Tokyo 107
`JAPAN
`Tel: +81—3—3408—3l 18
`Fax: +81-3-3408-3553
`tokyo.ofc@ computenorg
`
`Editorial production by Penny Storms
`Cover by Joseph Dagle/Studio Productions
`Printed in the United States of America by KNI, Inc.
`
`® The Institute of Electrical and Electronics Engineers, lnc.
`
`

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

`
`service provided by the network. This amounts in
`practice to adapting applications to the time—varying
`characteristics of the connection over which the appli-
`cation data packets are sent, the goal being to maxi-
`mize the quality of the data delivered to the destina-
`tions. Experimental evidence suggests that the quality
`of the audio depends essentially on the number of lost
`packets and on the delay variations between successive
`packets. Thus, the most important network character-
`istics for audio applications are the delay variance (or
`jitter), and the loss distributions. Furthermore, for
`live audio applications such as audioconferences, the
`average end—to—end delay must be small to allow inter-
`actions between participants.
`The goal then in this approach is to develop mech-
`anisms that attempt to eliminate or at least minimize
`the impact of packet loss and delay jitter on the qual-
`ity of the audio delivered to the destinations. We have
`developed a set of such mechanisms. One mechanism
`adjusts the playout time of audio packets at the desti-
`nation, the objective being to minimize the impact of
`delay jitter. A second mechanism adds redundancy in-
`formation in the audio packets sent by the source, the
`objective being to minimize the impact of packet loss.
`A third mechanism controls the rate at which pack-
`ets are sent over a connection, the objective being to
`match the send rate to the capacity of the connection
`and hence to minimize packet loss. The second and
`third mechanisms both attempt to minimize the im-
`pact of packet loss, and they really are two sides of a
`joint error/’rate control mechanism.
`These mechanisms have been implemented in a new
`audio tool developed at INRIA. For lack of space (and
`as suggested by reviewers) we do not describe in the
`paper the jitter control mechanism. We focus instead
`on the rate and error control mechanisms.
`In Sec-
`tion 2, we describe the structure of the audio tool.
`In Section 3, we characterize the loss process of au-
`dio packets, and describe and evaluate a packet loss
`recovery scheme. In Section 4, we describe and eval-
`uate a joint error and rate control scheme. Section 5
`concludes the paper.
`
`2 The audio tool
`
`The structure of the audio tool is shown in Figure 1
`below. It is being developed within the MICE project
`in collaboration with a group at University College
`London (UCL). Work at UCL has focused on device-
`independent audio input, eflicient mechanisms for si-
`lence detection, automatic gain control, and echo can-
`cellation, and on the evaluation of the auditory qual-
`ity of the signal delivered to the destinations. Work at
`INRIA has focused on coding schemes, and on jitter,
`rate, and error control mechanisms.
`The coding schemes available at this time use 8-
`
`Figure 1: Structure of the audio tool
`
`kHz sampled speech with bit rates varying from a few
`kb/s to 64 kb/s. Specifically, they include a 64-kb/s ,u—
`law PCM, various adaptive delta modulation (ADM)
`coders with rates varying from 16 kb/s (for ADM2)
`to 56 kb/s (for ADM6), a 13 kb/s GSM coder, and
`a 4.8 kb/s LPC low bit rate coder. Work is under-
`way to include wideband speech coders. The PCM,
`ADM6, ADM5, and GSM coders deliver high qual-
`ity audio with MOS scores above 3.5. The ADM2,
`ADM3, and LPG coders delivers audio with a some-
`what lower quality. However, even a mediocre low bit
`rate coder turns out to be useful for error control pur-
`poses (refer to Section 3). The boxes in the figure
`which involve one of the control mechanisms of inter-
`
`est in the paper have been highlighted. They include
`the redundancy box (which involves the error control
`mechanism), the congestion information and feedback
`information boxes (which involve the error/ rate con-
`trol mechanism), and the playout buffer box (which
`involves the jitter control mechanism).
`The audio packets are sent from the source to the
`destination(s) using IP (or its multicast extension),
`UDP, and RTP. To each audio packet is associated a
`timestamp and a sequence number. The timestamp is
`used to measure end—t0-end delays, and the sequence
`number is used to detect packet losses.
`
`3 A loss recovery mechanism
`Anecdotal evidence suggests that audio quality is
`still mediocre in many audio connections because of
`
`2c.4.2
`
`23
`
`sender
`
`,/J
`
`automatic ..
`
`..--,
`
`jg
`
`compression
`
`garncontrol
`(
`imputj jcancellation Tifdemjon
`
`1
`
`echo
`
`__
`
`silence
`
`audio
`
`schemesWT
`compressmn
`
`.
`
`1"
`
`_
`
`.
`
`
`
`packet
`transmission
`
`N
`
`feedback .
`information
`
`,_W___
`
`
`
`
`
`congestion
`information
`reception
`
`packet
`
`receiver
`
`
`
`,
`
`3Udl°
`¢C0nSfI1lCTi0 (
`I-docomprcssroilicsequcncrng
`
`'
`
`.
`
`<-
`
`mlxlng
`
`a
`
`-
`
`l
`l
`decompression
`schemes
`
`

`
`packet losses. This makes it important to implement
`an efficient loss recovery mechanism for audio appli-
`cations. We address this problem in this section. Our
`main result is that open loop error control mechanisms
`based on forward error correction are adequate to re-
`construct most lost audio packets. We describe one
`such mechanism and report on improvements of audio
`quality obtained with it.
`
`Analysis of the loss process
`Many different quantities can be used to charac-
`terize the loss process of audio packets. The obvious
`measureis the average loss, or unconditional loss prob-
`ability. Let l,, denote a boolean variable which is set to
`1 if packet 72, is lost, and 0 otherwise. The average loss
`is thus equal to the expected value of Zn. We denote
`ulp : E[l.,,,]. However, ulp does not characterize the
`burstiness of the loss process, or equivalently the cor-
`relation between successive packet losses. One way to
`capture such correlation is to consider the conditional
`probability that a packet is lost given that the previous
`packet was lost. We denote clp = P[l,,+1 = llln :2 1].
`We have analyzed clp and ulp in the Internet us-
`ing measurements and analysis. The measurements
`have all be done using the PCM coder with 320-byte
`packets (or 40 ms of speech) between INRIA Sophia
`Antipolis and University College London (UCL) in the
`UK. Figure 2 shows the evolutions of the number of
`consecutively lost packets as a function of 7; measured
`at 3:00 pm. The average loss ulp = 0.21 is quite high
`
`12
`11
`H)
`
`
`
`
`
`NmiberdDOIBQGIINQ10554:
`
`aAInca-4mm
`
`2 t . y .
`lt"l<;1|":msn.l.illi':
`o
`soon
`mono
`V5000
`0:
`1
`1
`Sequence numoav
`
`,
`.=L..{‘s':li
`25003
`
`20000
`
`zoom
`
`Figure 2: Evolutions of the number of consecutively
`lost packets
`
`because the INRIA-UCL connection is heavily loaded
`during daytime. However, it appears that most loss
`periods involve one or two packets. This observation
`is confirmed by looking at the frequency distribution
`in Figure 3, which shows the frequency distribution
`of the number of consecutive losses (i.e.
`the num-
`ber of occurrences of 71, consecutive losses for different
`
`72,) corresponding to the trace in Figure 2. The slope
`of the distribution decreases linearly near the origin.
`
`moon
`
`1000
`
`100
`
`NuntwrI!occiwncas
`
`IO 15
`
`10Number 04 wnsoaunva bases
`
`20
`
`25
`
`so
`
`Figure 3: Frequency distribution of the number of con-
`secutively lost packets
`
`Since the figure is drawn on a log scale, this indicates
`that the probability distribution decreases geometri-
`cally fast away from the origin.
`We have examined the loss process of audio packets
`over unicast connections other than the INRIA-UCL
`connection, and over multicast connections as well. In
`all cases, we have found that the frequency distribu-
`tion of the number of consecutively lost packets is sim-
`ilar to that described above
`Packet loss recovery schemes
`A loss recovery scheme is required if the number
`of lost audio packets is higher than that tolerated
`by the listener at the destination. Loss recovery is
`typically achieved in one of two ways. With closed
`loop mechanisms such as Automatic Repeat Request
`(ARQ) mechanisms, packets not received at the desti-
`nation are retransmitted. With open loop mechanisms
`such as Forward Error Correction (FEC) mechanisms,
`redundant information is transmitted along with the
`original information so that (at least some of) the lost
`original data can be recovered from the redundant in-
`formation.
`
`ARQ mechanisms are not generally acceptable for
`live audio applications because they increase end to
`end latency. Furthermore, they do not scale well to
`large multicast environments. FEC is an attractive
`alternative to ARQ for providing reliability without
`increasing latency
`However, the potential of FEC
`mechanisms to recover from losses depends crucially
`on the characteristics of the packet loss process in the
`network. FEC mechanisms are more effective when
`lost packets are dispersed throughout the stream of
`packets sent from a source to a destination. Thus, our
`measurements above indicate that FEC is particularly
`well suited for audio applications over the Internet.
`Many FEC mechanisms proposed in the literature
`involve exclusive-OR operations,
`the idea being to
`send every nth packet a redundant packet obtained by
`exclusive-ORing the other 71 packets [25]. This mech-
`
`234
`
`20.4.3
`
`

`
`anism can recover from a single loss in a n packet mes-
`sage. It is a very simple mechanism, but it increases
`the send rate of the source by a factor of 1/7L, and it
`adds latency since 11 packets have to be received before
`the lost packet can be reconstructed.
`Within the MICE project, we have developed a
`novel mechanism for loss recovery. Consider for exam-
`ple the case when audio is sent using PCM encoding.
`In our mechanism, packet 12. includes in addition to the
`PCM encoded samples, a redundant version of packet
`11,- 1 typically obtained with a. low bit rate coder such
`as the LPC or GSM coder. LPC is a CPU-intensive
`
`coding algorithm. However, it adds very little over-
`head (24 bytes) per 320-byte PCM encoded packet.
`Our mechanism improves upon an earlier mechanism
`in which the redundant information in packet n in-
`cludes short-term energy envelopes as well as the num-
`ber (and possibly the location) of zero crossings of
`packet 71, - 1 [10].
`Both mechanisms can recover from isolated losses.
`
`the destination Waits for packet
`If packet n is lost,
`n + 1, decodes the redundant information, and sends
`the reconstructed samples to the audio driver. In our
`case, the audio output consists of a mixture of PCM-,
`LPC-, or GSM— or ADM-coded speech. The subjective
`quality of this reconstructed speech has been carefully
`eva.lu_ated by our MICE colleagues at UCL. They have
`obtained results (detailed in [13l) that Show that audio
`quality as measured by intelligibility hardly decreases
`as the loss rate reaches 30% even when a relatively
`low quality LPC coder is used to obtain the redundant
`informationl.
`
`Even though most loss periods involve one packet
`(i.e. most losses are isolated), it is important to re-
`cover from multiple consecutive losses. This is in-
`tuitively clear since longer loss periods have a larger
`(negative) impact on audio quality than do shorter pe-
`riods do. Of course, we could combine the above mech-
`anism with packet repetition to recover from two con-
`secutive losses. However, this does not yield much an-
`dio quality improvement over the original mechanism.
`Furthermore, we have found that in high loss and high
`load situations, the most important task of an audio
`tool is to deliver decent quality audio to the destina-
`tions. Thus, our approach in such cases is to increase
`the amount of redundancy carried in each packet. We
`can use as redundant information in packet 72,, LPC or
`GSM versions of packets n — 1 and n — 2, or of packets
`n~1, n—2 and n—3, or ofpacketsn—1 andn—3,
`etc.
`
`information increases
`Clearly, adding redundant
`the CPU and the bandwidth requirements of the
`
`1Tho eflicacy of this scheme can be checked at URL
`http://www.inria.ir/rodeo/’personnel/huitema/audio.html.
`
`coder. Table 1 shows the cost in terms of CPU and
`
`bandwidth of various coding schemes. The CPU cost
`is the time, measured on a 75-Mhz SparC20 worksta-
`tion, needed to encode a packet relative to that re-
`quired to encode a PCM packet.
`
`Relative CPU cost
`
`Bandwidth (kb/s)
`
`
`
`Table 1: Relative CPU cost and bandwidth require-
`ments of various coders
`
`For convenience of exposition, we use through-
`out the rcst of the paper the notation (coding algo-
`rithm, redundant algorithm
`to indicate that an-
`dio packet 71. includes as redundant information audio
`packet 72, — 2' encoded with the appropriate coding al-
`gorithm. For example, (PCM, ADM(1)) or (PCM,
`GSM(1), GSM(3)). In the later example, both pack-
`ets n -— l and n —— 3 encoded with the GSM coder
`
`are included in packet n along with the main PCM-
`coded information. To each combination of main and
`redundant information we associate a. CPU cost, band-
`width requirements, a delay, and a reward. The CPU
`cost and the bandwidth requirements have been exam-
`ined above. The delay characterizes the time required
`at the destination to reconstruct lost packets. This
`time can become quite large if the redundant informa-
`tion includes packet 11. — i with 1} large, since 1} packets
`have to be received after a loss to reconstruct the lost
`packet. In this section, we use the maximum value of
`i in a packet as the delay. The reward characterizes
`the auditory quality perceived at the destination given
`the chosen combination of main and redundant infor-
`mation. Given the lack of objective measures of audio
`quality, we use the loss rate after reconstruction as the
`reward (note that the reward then unfortunately he-
`comes independent of the scheme used to encode the
`redundant information).
`Table 2 shows for a few combinations the associated
`
`delay and reward. In all cases, the reward is relative
`to that of the base combination, i.e. (PCM). For ex-
`ample, a relative reward equal to 3 indicates that the
`loss rate at the destination after packet reconstruc-
`tion is 1/3 that before reconstruction. The results
`have been measured over 10 experiments carried out
`over the INRIA-UCL connection at various times of
`
`the day. The bandwidth requirements a.nd the rela-
`tive CPU cost of each combination are easily obtained
`from Table 1.
`As expected, adding redundant
`
`information in-
`
`2c.4.4
`
`235
`
`

`
`Combination
`
`
`
` (PCM, ADM4(1))
`(PCM, GSM(1))
`(PCM, LPC(1))
`
`(PCM, ADM4(2))
`(PCM, ADM-1(1), ADM2(2))
`(PCM, ADM4(1), ADM2(3))
`
`
`
`(PCM, ADM4(1), ADM2(2), ADM2(3))
`
`
`
`formation added in audio packets at the source based
`on feedback information about the loss process mea-
`sured at the destination. We use theisame approach
`in the case of a multicast audio connection. However,
`the feedback information there reflects the loss process
`measured at all the destinations. We consider this gen-
`eral case of multicast audio delivery in the remainder
`of this section.
`
`There has been much work in the past on control
`mechanisms for packet audio. However, most of it has
`focused on dynamic rate control mechanisms in a ho-
`mogeneous environment, i.e. with audio sources only
`(e. g.
`[9, 30]), or on selective packet discarding in inte-
`grated environments, i.e. with data and audio sources
`(eg.
`[28, 22]). Work on dynamic error control has fo-
`cused on control mechanisms for ARQ—type protocols
`(e.g.
`[18]). We believe our tool is the first packet au-
`dio tool that uses joint dynamic error and rate control
`mechanisms.
`
`In practice, we combine the rate control and the er-
`ror control mechanisms into one joint rate/error Con-
`trol mechanism. The goal then is to adjust at the
`source both the send rate and the amount of redun-
`
`dant information to minimize the perceived loss rate
`at the destinations. To achieve this goal, we must be
`able to i) adjust the rate at which packets at sent into
`the network, ii) adjust the amount of redundancy in-
`formation added in these packets,
`iii) elicit feedback
`information about the loss rates measured at the des-
`
`tinations, and iv) define a control mechanism which
`takes this feedback information to adjust the redun-
`dant information and send rate at the source accord-
`
`ingly. We consider these issues next.
`Regarding point i), there does not seem to exist an
`audio coder the output rate of which can be controlled
`over a wide range of bit rates with a relatively fine
`granularityz. This is unlike for video, where efficient
`algorithms have been devised to produce embedded
`bit streams that can be easily controlled by dropping
`less important bits [19, 8]. One way around this prob-
`lem is to use a panoply of audio codecs. As mentioned
`earlier, we use PCM (at 64 kb/s), various ADM (be-
`tween 16 kb/s and 48 kb/s), GSM (at 11 kb/s), and
`LPG (below 5 kb/s) coders. This makes it possible to
`choose the coding scheme with a bandwidth require-
`ment closest to that desired. However, the granularity
`of the rate adjustment is coarse.
`Regarding point ii), we have seen in Section 3 that
`combinations of redundant information can be used to
`
`provide different levels of error correction.
`Regarding point iii), we have chosen a feedback in-
`formation based on packet loss rates (measured be-
`
`2However, variable bit rate coders with a. limited range of
`output bit rates do exist (e.g. [14]).
`
`Table 2: Delay and reward for various combinations
`of main and redundant information
`
`creases the CPU cost, the bandwidth requirements,
`and the delay as well as the reward. We note that the
`last few combinations in the table are clearly overkills
`if the network load is low a.nd packet losses are rare
`occurrences. Thus, we need a mechanism to adjust
`the amount of redundancy added at the source based
`on the loss process in the network as measured at the
`destination. We describe one such mechanism next.
`
`4 A combined rate and error control
`mechanism
`Let us first consider the case of a unicast audio con-
`
`nection. Most packet losses observed over such a con-
`nection are caused by congestion in the network. The
`state of congestion might have been created by the au-
`dio connection, by other connections sharing common
`resources with the audio connection, or by both. Typ-
`ically, sources react to congestion by decreasing their
`bandwidth requirements in an attempt to reach a state
`where network utilization is high. If all sources use the
`same bandwidth control mechanism, and if this mech-
`anism is designed adequately, then all sources share
`the resources of the network fairly
`In practice,
`however, not all sources use the same mechanism. Fur-
`thermore, some sources do not use any control mecha-
`nism at all. As a consequence, an audio source which
`decreases its bandwidth requirements upon detecting
`congestion might not observe any decrease in its loss
`rate as a result of its action. Thus, it is difiicult to
`evaluate and to control the impact of a bandwidth (or
`rate) control action taken by a source on the state of
`the network in general, and on the loss rate for this
`source-destination pair in particular. Note that the
`problem essentially stems from the current stateless
`architecture of the Internet illustrated by the FIFO
`discipline at the switches which makes the delay and
`loss processes of a connection strongly dependent on
`the arrival processes of other connections.
`Minimizing audio packet losses then cannot be done
`reliably by simply controlling the send rate of the au-
`dio connection. Our approach is to minimize packet
`losses by controlling the send rate as well as the loss
`recovery process at the destination, which in practice
`is done by controlling the amount of redundant in-
`
`236
`
`2c.4.5
`
`

`
`fore possible packet loss reconstruction) at the desti-
`nations. Specifically, each receiver measures an aver-
`age loss rate observed during a given time interval.
`This measure is then sent back to the source and to
`
`the other destinations using the QoS reporting mech-
`anism of RTP V2 [23]. This reporting mechanism is
`interesting because it is scales well to a large number
`of receivers [11], and because it provides interoperabil-
`ity with other audio tools.
`Regarding point iv), the first task of the control
`mechanism is to relate the state of the entire multi-
`cast group within the context of the application.
`In
`other words,
`the source must convert the Q03 (i.e.
`the loss rates) received from each destination into a
`global QoS measure which represents the overall qual-
`ity of the audio received at the destinations. We take
`our global QoS measure to be a 90 percentile Q03, i.e.
`the smallest QoS better than 90% of the Q08 values
`reported by the destinations. The control algorithm
`then will strive to keep this value below some tolerable
`loss rate. Packet loss rates of between 1 and 10% can
`be tolerated depending on the way in which voice is
`coded and missing packets are masked [16].
`The choice of the 90 percentile QOS as the global
`QoS is ad hoc, and it might not always be adequate in
`a heterogeneous network. Clearly, a source-based rate
`control mechanism as that considered here attempts
`to deliver at any given time a uniform quality of au-
`dio to all the destinations on the multicast tree even
`
`with different branches of the tree have widely differ-
`ent bandwidth (and thus experience widely different
`loss rates). A solution to this problem [27, 19] is to use
`a layered coder in conjunction with a receiver-based
`control mechanism in which receivers adapt to net-
`work conditions (i.e. to loss rates on different branches
`of the tree) by adding and dropping layers. Unfortu-
`nately (refer to our discussion earlier), very few layered
`audio coders are available.
`
`We now describe the control algorithm used by the
`audio coder. Let us first consider the case when the
`
`coder adjusts only its output rate in response to feed-
`back information. The algorithm gradually increases
`the send rate at the source if the global Q08 (i.e. the
`90 percentile loss rate) is below a threshold.
`It de-
`creases the bandwidth if the global Q08 is above an-
`other threshold. Figure 4 shows example evolutions of
`the send rate and the global QoS measured between
`INRIA and UCL. In this case, the low threshold was
`set to 5% and the high threshold to 15%. The interval
`between the reception of successive QoS reports, and
`hence between successive control actions, is equal to 5
`seconds. As expected, we observe that the send rate
`and hence the bandwidth requirements of the source
`decrease when network congestion increases. Unfor-
`tunately, we have little control over the traffic and
`
`loss rate
`Oman! vats (R?/33
`
`lossva1a(%)
`
`oulpmrats(kbls) zqoIIIIBNEI l'|
`
`Figure 4: Evolutions of the loss rate at the destination.
`and the output rate of the coder
`
`the network load between INRIA and UCL. To bet--
`ter understand the behavior of this and other control
`
`mechanisms, we have set up a test network at INRIA.
`with known topology and link bandwidths, and with
`controlled traffic sources.
`
`We have carried out an experiment over this net-
`work in which a variable number of audio connections
`
`share a 100 kb/s link. The initial coding scheme used
`by the sources is the 64 kb/ s PCM scheme.
`If the
`source coders do not use the error/rate control mech--
`anism, then packet losses increase rapidly with the
`number of active sources. We have found that an-
`
`dio quality at the destinations becomes mediocre as
`soon as this number exceeds 3. With the rate con--
`trol mechanism switched on, source coders decrease
`their output rates upon receipt of bad QoS reports by
`switching from PCM coding to ADM6, then ADM5,
`down to ADM4 and GSM coding. As a result, the loss
`rates at the destinations remain close to 0 and audio
`quality is kept relatively constant since all the PCM,
`ADM5 /6, and GSM schemes have MOS scores above
`3.5. Figure 5 shows the evolutions of the output rates
`of the coders3. Source 1 is active during the entire ex-
`periment. Source 2 starts transmission at time t = 5
`and stops at time t = 345. Source 3 starts transmis-
`sion at time t : 160 and stops at time t : 245. As
`expected, active sources share the bandwidth fairly
`evenly. The large oscillations in the output rate for
`t Z 250 s occur because all connections share the same
`links and buffers. Therefore, QoS reports from differ-
`ent destinations tend to arrive at the sources at the
`
`same time. Thus, sources tend to take control actions
`synchronously, which creates large-amplitude oscilla-
`tions.
`
`3It appears that at time 0 a single source sends data at 66
`kl)/s as opposed to the 64kb,/s associated with PCM. This is
`because the output rate figure has been obtained by including
`the RTP header data in addition to the audio data proper.
`
`2c.4.6
`
`Z37
`
`

`
`
`
`loss thresholds were both set to 3%, meaning that
`the control mechanism attempts to keep the loss rate
`at the destination after packet reconstruction around
`3%. The figure shows the evolutions of the loss rate
`at the destination before and after reconstruction. It
`
`also shows which combination (identified by the com-
`bination number in the table above) was used at any
`given time. We observe that the mechanism achieves
`its goal of keeping the loss rate between 0 and 5%
`most of the time even though the loss rate in the net-
`work varies from 15 to higher than 40%. This clearly
`shows that our mechanism makes it possible to main-
`tain good quality audioconferences even across fairly
`congested links in the Internet.
`__,
`I
`
`..,_.__._,.
`,.—...
`lass me never: reconstruction :
`loss rate mar reconsuucvlc
`----
`combination numb
`-~
`
`
`
`
`
`
`
`Packetloss(7.)
`
`ComblnalivnI
`
` 130 150 200 250
`
`
`
`300
`TIn19(sec)
`
`Figure 6: Evolutions of the loss rate at the destination
`(before and after reconstruction) and of the combina-
`tion used by the control mechanism
`
`5 Conclusion
`
`We believe that the work presented in the pa-
`per suggests that it is possible to build an “Internet
`telephone" that can provide good quality audio even
`across fairly congested links. Of course, the load (and
`thus the delay and the loss rate) in the network are
`sometimes so high that audio delivered at the destina-
`tions is not intelligible. This situations seems difficult
`to avoid until better support is available from the net-
`work, and in particular until discriminatory schedul-
`ing disciplines such as Fair Queueing have been widely
`deployed.
`
`Acknowledgements
`The work presented in the paper has been shaped by
`many discussions with members of the networking groups
`at INRIA and UCL. We would like to single out and thank
`Christian Huiterna at INRIA, as well as Vicky Hardman
`and Mark Handley at UCL for many fruitful interactions.
`Thanks also to the anonymous reviewers for valuable com-
`ments and feedback. Jon Crowcroft at UCL and Vern Pax-
`son at LBL provided machines that made some of the mea-
`surements possible. Early work on audio coding at INRIA
`
`
`
`
`
`70
`~:
`I
`v
`.
`r
`u
`r
`
`source I —_.
`Set. as
`----
`
`65
`Son :9 3
`so
`55
`so
`45
`40
`35
`so
`25
`no
`as 0
`
`zoo
`Time (.595)
`
`25c
`
`sec
`
`350
`
`400
`
`
`
`
`
`Sandvale(W5)
`
`so
`
`me
`
`150
`
`Figure 5: Evolutions of the output rate of multiple
`sources sharing a 100 kb/s link
`
`We demonstrated earlier that a rate control mech-
`anism alone is not sufficient to deliver good quality
`audio at the destinations given the current Internet
`architecture. Thus we now consider the general case
`when the coder adjusts the amount of redundant infor-
`mation as well the output rate in response to feedback
`information.
`The control mechanism chooses one of the combi-
`nations in Table 4 next page. It changes from combi-
`nationi to combination 1+1 if the global QoS (i.e. the
`90 percentile loss rate) is below a threshold. It changes
`from combination 2' to 7? ~ 1 if the global QOS is above
`another threshold. Note that the control mechanism is
`essentially an error control mechanism for low values
`of 7?, and a rate control mechanism for large values of 2'.
`Upon detecting congestion, the source send rate does
`not decrease. Instead, the amount of redundant infor-
`mation increases. Thus, the audio streams uses more
`network resources than it would with a TCP—like con-
`
`trol mechanism. This amounts in practice to giving
`priority to the audio stream over other streams. Not
`surprisingly, we have found this specific mechanism to
`provide slightly better audio quality than other TCP—
`like mechanisms we experimented with.
`Our algorithm is a very unsophisticated version of
`a joint source/channel coding algorithm. The use of
`such algorithms has been advocated in both the net-
`working and the signal processing communities (e.g.
`[12]), and we are investigating better designed and
`more efficient algorithms. However,
`the algorithm
`above is useful because it is very simple to imple-
`ment and it is computationally cheap“. Furthermore,
`it serves as a baseline to evaluate future algorithms.
`Figure 6 shows measurements obtained between IN-
`RIA and UCL during daytime. The low and high
`
`‘The combinations in Table 4 involve ADM-coded redun-
`dant information preciscly so as to minimize the CPU require-
`ments at the source.
`
`238
`
`2c.4.7
`
`

`
`-1338]4
`(ADM6, ADM3 (1))
`(ADM6, ADM3 (2))
`(ADM5, ADM3 (1), ADM2 (2))
`(ADM5, ADM3 (1), ADM2 (3))
`(ADM4, ADM3 (1), ADM2 (2))
`(ADM4, ADM3 (1), ADM2 (3))
`(ADM3, ADM3 (1), ADM2 (2), ADM2 (3))
`(ADM3, ADM2 (1), ADM2 (2), ADM2 (3))
`(ADM2, ADM2 (1), ADM2 (2), ADM2 (3), ADM2 (4))
`(ADM2, ADM2 (1). ADM2 (2), ADM2 (4))
`(ADM2, ADM2 (1), ADM2 (3))
`(ADM2, ADM2 (1))
`(ADM2, ADM2 2)
`
`
`
`0123456789
`
`Table 3: Combinations and associated bandwidth requirements
`
`[15]
`
`[16]
`
`I171
`
`[13]
`
`[19]
`
`F201
`
`l21]
`
`[22]
`
`[231
`
`[241
`
`[35]
`
`[Nil
`
`[27]
`
`[23]
`
`[29]
`
`[30]
`
`E. I. Isaacs, J. C. Tang, “What video can and cannot do for
`collaboration: a case study”, Multimedia Systems, vol. 2, pp.
`63-73, 1994.
`N. Jayant, “Effects of packet losses in waveform—coded speech”,
`IEEE Trans. C17mm., vol. 29, no. 2, pp. 101-109, Feb. 1981.
`V. Jacobson, S. MacCanne, “vat”, Manual Pages, Lawrence
`Laboratory, University of California, Berkeley, CA.
`S. Kalle}, “Efficient hybrid ARQ protocols with adaptive for-
`ward error correction”, IEEE Trans. Comm., vol. 42, no. 2,
`pp. 281-289, Feb. 1994.
`S. McCanne, M. Vetterli, “Joint source/channel coding for
`multicast packet video”, Prac. ICIP ’95, Washington, DC,
`Oct. 1995.
`
`The MICE home page is at URL
`http://www.cs.ucl