COMPUTER
`NETWORKS
`
`and
`ISDN SYSTEMS
`
`The International Journal of Computer
`and Telecommunications Networking
`
`Theme issue
`
`ITC 14 Special Sessions Presentations
`
`Guest Eo'r‘tor:
`
`~‘-W F‘°be"5
`
`<
`
`‘ii?
`
`mum F. WENDT LIBRARY
`cowaaa or ENGANEERING
`
`APR 0 4 W
`
`UW»M7Afii6@N._ M 59705
`
`ELSEVIER Amsterdam -— Lausanne — New York - Oxford — Shannon — Tokyo
`RPX Exhibit 1130
`RPX v. DAE
`
`RPX Exhibit 1130
`
`RPX V. DAE
`
`

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

`
`646
`
`J.-C. Bait!!! Crmtpufer Nettvrrrks and ISDN S_v.rferns 28 (1996) 645-65.’
`
`for the quality of the data delivered to the destinations.
`The cost of implementing the first approach is high,
`since it requires that the architecture of the Internet be
`changed. and that admission control. policing, reserva-
`tion. pricing, andfor sophisticated scheduling mecha-
`nisms be implemented in the network. The second ap-
`proach does not require special support from the net-
`work, and hence it can be implemented in the current
`Internet. However, it is not clear whether real-time ap-
`plications in general can be made to adapt to network
`conditions, and whether adaptation only is enough to
`provide the desired performance levels.
`We discuss these issues next. In Section 2, we de-
`scribe our experience with adaptive applications in the
`current Internet. In Section 3, we describe how this
`
`experience can lead to understand the need for new
`services, and how these services could be offered in
`
`an integrated service Internet.
`
`2. Supporting real-time applications in the
`current Internet
`
`The current Internet offers a single class best ef-
`fort service. From a connection’s point of view. this
`amounts in practice to offering a channel with time-
`varying capacity. This capacity is not known in ad-
`vance since it depends on the (a priori unknown) be-
`havior of other connections throughout the network.
`To avoid rate mismatch { and hence network conges-
`tion), it is crucial that applications adapt to the capac-
`ity available in the network at any given time. One way
`to do this is via a control mechanism which adjusts the
`rate at which packets are sent over a connection based
`on feedback information about the network state.
`
`Feedback control mechanisms are already used in
`the Internet to control sources of non real-time traffic.
`
`The best example is the window control mechanism of
`TCP. There. the feedback information is packet losses
`detected by timeouts or multiple acknowledgements at
`the source, and the control scheme is Jacobson’s dy-
`namic window scheme [12]. The idea of using simi-
`lar control mechanisms for sources of real-time traffic
`
`is not new. Consider for example the case of video
`sources. Video has conventionally been transmitted
`over speei fie networks which provide connections with
`constant or nearly constant capacity channels (e.g.
`telephone or CATV networks). However, the rate ofa
`
`video sequence can vary rapidly with time due to the
`effects of scene complexity and motion. The problem,
`‘therefore, is to obtain from the variable rate sequence
`a constant rate stream that can be sent into the net-
`
`work. This is typically done by sending the variable
`rate stream into a buffer which is drained at a con-
`stant rate. The amount of data in the buffer is used as
`a feedback information by a controller which adapts
`the output rate of the coder in order to prevent buffer
`overflow or underflow [4]. Feedback mechanisms for
`video sources have also been proposed for networks
`with variable capacity channels. There, the goal is to
`adjust the output rate of video coders based on feed-
`back information about changing network conditions,
`i.e. changing capacity in the network [925].
`For both fixed and variable capacity channels, the
`feedback control mechanism trades off image qual-
`ity for network resource (specifically bandwidth) re-
`quirements, the goal being to maximize the perceptual
`quality of the image received at the destinations while
`minimizing the bandwidth used by the video trans-
`mission. We next illustrate this tradeoff with measure-
`ments and results obtained with IVS. IVS is a software
`
`videoconferenee system for the Internet developed at
`INRIA [23]. It includes a H.261 video codec [10]
`and a panoply of audio codecs. IVS data is sent over
`the Internet using IP multieast, UDP and RTP.
`A central part of the video codec is the compres-
`sionfcoding algorithm. In H.261. a picture is divided
`into blocks of 8 >< 8 pixels. A discrete cosine trans-
`form (DCT) converts the blocks of pixels into blocks
`of frequency coefficients. These coefficients are quan-
`tized and then encoded using a Huffman encoding
`technique. In addition, images can be coded using in-
`traframe or interframe coding. The former encodes
`each picture in isolation. The latter encodes the dif-
`ference between successive pictures.
`It turns out to be surprisingly easy to change the
`output rate of the coder by adjusting parameters of
`the coder. In IVS, we adjust three such parameters.
`namely the refresh rate. the quantizer, and the move-
`ment deteetion threshold. The refresh rate character-
`
`izes the rate at which frames are grabbed from the
`camera. Decreasing the refresh rate decreases the av-
`erage output rate of the coder. However,
`it also de-
`creases the frame rate and hence the quality of lhfi
`video delivered at the receivers. The quantizer charac-
`terizes the granularity used to encode the coeffieients
`
`

`
`J.-C. Balm/Coriipmer Nenvorks and ISDN .S'y.rtem.r 28 (1996) 645—65."
`
`647
`
`Frame
`Grabbing
`
`Dcteetieai
`' ‘
`E';‘§£'é‘m”’i
`
`_ Movcnicm
`
`Video frames
`
`Fig. 1. Structure of the H26! coder.
`
`obtained from the discrete cosine transformation. In-
`
`creasing the quantizer is equivalent to encoding the
`frequency coefficients more coarsely, and thus reduc-
`ing the quality of the transmitted image. However,
`it
`is also equivalent to reducing the number of bits used
`to encode pixels, and thus reducing the output rate of
`the coder. The movement detection threshold charac-
`
`terizes the blocks in a frame which are “sufficiently
`different“ from those in the previous frame. Increas-
`ing the threshold value decreases the number of blocks
`which are considered to have changed since the last
`frame. However, it also decreases the sensitivity of the
`
`coder to movement and yields lower image quality.
`Thus adjusting the parameters of the video coder
`is an easy way, particularly in a software coder such
`as IVS, to trade off a lower output rate (i.e. lower
`
`bandwidth requirements) for a lower image quality.
`Which of the three parameters above is adjusted de-
`pends on the specific requirements of a video applica-
`tion. The refresh rate is adjusted if the precise rendi-
`
`tion of individual images is important. The quantizer
`and the movement detection threshold are adjusted if
`
`the frame rate or the perception of movement is im-
`portant. Other ways to control the output rate of video
`coders are described in [l4,15.'i'}.
`
`Unfortunately, it is not so easy to modify the param-
`cters of an audio coder to adjust its output rate. This
`is essentially because different compression schemes
`based on very different principles are used to obtain
`audio streams with different bandwidth requirements.
`One way around this problem is to use a panoply of
`audio codecs. IVS and other audioconference systems
`such as VAT [13] typically use PCM (at 64 kbfs),
`ADPCM (between 16 kbfs and 48 kbr's),GSM (at 11
`kbfs), and LPC (below 5 kbfs) codecs. This makes
`
`it possible to choose the coding scheme most appro-
`priate for the bandwidth available in the network at
`
`any given time.
`
`At this point, we have shown that videoconference
`applications in general can adjust their bandwidth re-
`quirements. To use these applications over the Inter-
`net, however, we need a feedback mechanism to elicit
`information about the state of the network, and a con-
`
`trol algorithm to adjust the audio or video output rate
`
`accordingly. The goal of the feedback mechanism is to
`estimate the state of the network, or rather its impact
`on the quality of the image received at the destinations.
`Since the number of destinations can be large and
`
`might even be unknown (recall that most audio and
`videoconference applications are expected to run in
`a multicast environment), the mechanism must scale
`
`well with the size of the multicast group. One such
`mechanism is described in [2]. Furthermore, we need
`
`to identify variables to evaluate the perceived quality
`of the images received at the destinations.
`The Mean Opinion Score (MOS) has been used
`extensively as a subjective measure to design and
`compare video coding algorithms [11]. However, a
`MOS-based feedback mechanism would be impracti-
`cal, since it would have to include the user in some
`
`kind of continual rating procedure. We thus have to
`rely on objective measures. Unfortunately, objective
`measures typically do not reflect the user's perception
`of an image [11]. The signal to noise ratio (SNR) is
`a measure of the spatial quality of the image. How-
`ever,
`it is an imperfect measure because the percep-
`tual quality in a sequence of frames depends on the
`quality of each frame in the sequence. Furthermore, it
`cannot be computed by the receivers since it requires
`that the original image be available. Another objective
`measure is the frame rate, i.e. the rate at which video
`frames arrive at the destinations. Yet another measure
`
`is the loss rate ofthe packets on the paths between the
`source and the destinations. We have chosen in IVS a
`
`feedback information based on measured packet loss
`
`rates at the destinations. Specifically. each receiver
`
`
`
`

`
`648
`
`J.-C. Bola:/Crmrmirer Ne.-‘wm-k.v and ISDN S_v.c.'ems 28 (I996) 645-651
`
`measures an average packet loss rate observed during
`a given time interval. It then considers the network to
`be unloaded, reasonably loaded, or overloaded (i.e.
`congested) depending on the measured rate.
`The control algorithm at the source gradually in-
`creases the audio or video bandwidth until
`the net-
`
`work is reasonably loaded. The source then transmits
`at this rate, continually polling its receivers to ensure
`that
`the network does not become congested. If the
`network is detected by one or more of the receivers
`to be congested, the source then reduces its output
`rate. Of course, a lower bandwidth at the source trans-
`
`lates into a lower image quality for all destinations.
`However,
`it also translates into lower bandwidth re-
`
`quirements, and hence lower losses and delays in the
`network. There remains to quantify this bandwidth»
`gained;/quality-lost tradeoff. The problem again is to
`find a way to estimate the quality of the video data
`delivered to the receivers. We argued earlier that the
`loss rate and the frame rate are good indications of
`this quality. Experiments carried out with colleagues
`at University College London (UCL) show that the
`control mechanism decreases the bandwidth require-
`ments as well as the loss rate at the receiver. as long
`as the video traffic makes up a significant part of the
`total traffic on the path from INRIA to UCL.
`
`3. Supporting real-time applications in an
`integrated services Internet
`
`Our experience and that of others obtained with var-
`ious audio and video transmission systems for the In-
`ternet such as VAT [13], NV [7], or NEVOT [20]
`indicates that the rate adjustment of audio and video
`coders makes it possible to maintain videoconferences
`of reasonable quality over the Internet. Of course, the
`audio and video signals (and therefore the user sat-
`isfaction) are degraded as the available capacity de-
`creases,
`i.e. as the network load increases. It is not
`
`clear, however. whether this degradation is still tolera-
`ble when the available capacity is “very small”. Con-
`sider for example the case of audio data. Known audio
`compression algorithms require a bandwidth equal to
`at least a few hundred bits per second [I 1]. There is
`clearly a problem if the available capacity in the net-
`work is lower than this minimum value. Ergonomic
`studies and anecdotal evidence from the Internet sug-
`
`gest (although this question would certainly benefit
`from further work) that users find audio and video
`data useful as long as the information content is above
`some minimum level which depends on the task at
`hand [26,l]. Therefore, there is a lloor to the rate at
`which a real-time application can transmit and still
`send a useful stream of infonnation. This presents the
`problem of who to satisfy when two applications com-
`pete for the same bandwidth, and whose combined
`
`minimum bandwidth requirements, i.e. combined lloor
`rates, exceed the available bandwidth. The problem
`can be resolved either by turning off one of the appli-
`cations (this is generally done by the end user who
`realizes that the network does not provide the desired
`service), or by preventing this situation from happen-
`ing in the first place. This latter solution is typically
`implemented by means of admission control mecha-
`nisms.
`
`However, it is important to note that the above prob-
`lem is not likely to occur frequently (and hence ad-
`mission control is not likely to be required or useful}
`if the floor rates are low and if the network is di-
`
`mensioned appropriately. Unfortunately, it is not clear
`yet which fraction of applications will be rate adap-
`tive, and what their floor rates will be. The answers
`
`to these questions impact the way the network archi-
`tecture should be designed to provide the services re-
`quired by the applications.
`Scott Shenker has recently developed a simple
`model which brings out this impact [2] ]. Consider a
`network with a single bottleneck link with bandwidth
`b shared by N applications. For simplicity. all appli—
`cations are assumed to be identical. The quality of an
`application as observed by a user of this application is
`captured by a function referred to as a utility function
`U which depends on the service provided by the net-
`work. In our case. we assume that the service is com-
`
`pletely characterized by the available capacity. The
`utility for one application is U( b/N), and the total
`network utility is T(N) = N X U(b/N). The questifln
`then is how to maximize T(N). The answer to this
`question depends on the shape of the utility function
`U. Refer to Fig. 2. Shenker has shown that T(Nl in‘
`creases monotonically if U is concave as in case (3)-
`However, T(N) first increases but then decreases as
`N exceeds some value No if U is convex near me
`origin as in case (b). It is clear that in the latter C1159:
`the number of applications sharing the bandwidth
`
`

`
`J.-C. Brrlrit/Crmiputer Netivrrrks and ISDN 5__\‘.'t‘.i‘£m'.§' 28 {[996} 645-65}
`
`649
`
`qualityJ
`
`quality
`a
`
`(31)
`
`service
`tbanclwirlllij
`
`([1)
`
`service
`(bandwidth)
`
`Fig. 2. Example utility functions.
`
`i.e. admission control should
`should not exceed No,
`be exercised at the entrance to the network.
`
`We mentioned earlier that rate adaptive audio and
`video applications are characterized by a curve as
`shown in case (b) above. This suggests that admis-
`
`sion control mechanisms, and more generally that ser-
`vices other than the current best effort service, be im-
`
`plemented in the Internet to obtain an integrated ser-
`vices Internet '
`. This is indeed the solution advocated
`
`in [3].
`
`A widely held approach divides the services to be
`provided in an integrated packet switched network into
`a few basic types of services [3,8]. One type is the
`guaranteed service which provides an application with
`guaranteed performance such as bandwidth, delay. or
`loss. Another type is the predictive or statistical ser-
`vice which provides an application with statistical per-
`formance guarantees. Yet another type of service is
`the best effort service.
`
`One possible solution to providing these different
`services is as follows. Each output queue in a router
`
`would be organized as parallel FIFO queues shar-
`ing the output link bandwidth via a Fair Queueing or
`equivalent packetized head-of-line processor sharing
`scheduling policy [19]. In this policy, each queue is
`guaranteed a particular minimum bandwidth. Thus, the
`flows in each FIFO queue are isolated, which in turn
`allows different flows to be associated with services
`
`with different quality of service (QoS) characteristics.
`The traffic from applications requiring a guaranteed
`service must be regulated, or shaped, before entering
`the network, for example via a leaky bucket mecha-
`nism. The network can then reserve, using protocols
`
`that this conclusion does not
`‘ We point out again. however.
`necessarily hold if most of the applications which are expected to
`use the integrated Internet are rate adaptive applications with very
`low floor rates.
`
`such as RSVP [27] or ST—2 [22], appropriate size
`
`buffers and minimum guaranteed bandwidth such that
`guaranteed end-to-end delays are satisfied 3 . A video-
`conference application using bandwidth reservation
`with ST-2 is described in [6].
`
`The traffic for applications requiring a statistical
`service is segregated and managed based on statis-
`tical characteristics and desired QoS. The statistical
`characteristics and Q05 requirements of an application
`
`would be described by measures such as the effective
`bandwidth [ 16]. and they would be part of a contract
`negotiated before data transmission. In practice. appli-
`cations with similar Q03 requirements could simply
`share FIFO queues.
`The best effort traffic can either be allocated a frac-
`
`tion of the bandwidth. or receive service only after the
`
`guaranteed and statistical traffic.
`It is clear that, all other things being equal, it would
`be desirable to provide different types of services in
`the Internet rather than only the best effort service.
`However,
`it
`is also clear that providing these extra
`
`services is costly. The implementation of mechanisms
`such as the Fair Queueing discipline does involve ex-
`tra cost compared to the FIFO discipline. However.
`the impact of providing new services is much more far
`reaching. For example, it is then necessary to provide,
`in addition to the new services, incentives to encour-
`
`age applications to request the proper service class for
`their requirements. In the absence of such incentives,
`applications could request the guaranteed service no
`matter what their requirements.
`One way of providing incentives is via pricing. Cur-
`rently. most users (or organizations in general) are
`
`3 Note. however. that end-to-end delays here do not include the
`delay incurred by the as-yet-unshaped traffic in the leaky bucket.
`which can be extremely high for bursty traffic.
`
`
`
`

`
`650
`
`J.-C. Bnlat/ Computer Nenvrirlcs and ISDN S_vsrem.t 28 ( I996) 645-65!
`
`charged a Hat fee to access and use the network. How-
`
`it would be desirable to charge more users and
`ever.
`applications that request the guaranteed service. This
`would provide the desired incentive in the sense that
`
`only those applications that do need the performance
`guarantees would be ready to pay for them [5]. The
`introduction of such usage—based pricing mightchange
`the (erroneous,_but surprisingly common) “Internet
`is free“ mentality which has been responsible in part
`for the explosive increase of the Internet in recent
`years. Furthermore,
`it requires that tariffing, billing,
`and monitoring mechanisms be implemented in the In-
`ternet. Even though several have argued that the over-
`head associated with the billing mechanisms would be
`manageable [ 18]. several problems might prove dif-
`ficult
`to solve. For example, suggestions that tariffs
`should be based on traffic characteristics could be hard
`
`to implement in practice given the difficulties experi-
`enced in measuring and identifying such characteris-
`tics l [7].
`
`One might then wonder whether the benefits ex-
`pected from the new Internet architecture are worth
`
`the pain associated with the change. Much of the work
`being done in a number of IETF working groups is in
`fact related to answering this question. The currently
`held view is that the architecture ofthe Internet will be
`
`changed to provide services similar to the guaranteed
`and statistical services described above in addition to
`the current best effort service.
`
`Recall that the discussion on the evolving Internet
`architecture was triggered in this paper by the work in
`Section 2 on rate adaptive applications. One question
`then is whether such applications still have a place
`in the new architecture. Clearly, the results from Sec-
`tion 2 are still applicable to those applications that re-
`quest only the best effort service. Applications that re-
`quest the statistical or guaranteed service have to trade
`off the cost (i.e. the charge) associated with the ser-
`vice requested, and the quality obtained when using
`this service. One way to do this in a flexible manner
`is to use. for example in the case of a video applica-
`tion. a layered or hierarchical video coding scheme.
`In such a scheme, the stream of video data generated
`by an application is split into multiple streams, each
`one with different bandwidth requirements than the
`original stream. In the two layer case, the base stream
`includes the low resolution information, and it can be
`decoded into a meaningful service. The other stream
`
`includes enhancement information. The idea then is
`to transmit the important stream (the base stream in
`the two layer case) using the guaranteed service, and
`the enhancement stream using the best effort service.
`Note that a similar idea can already be implemented in
`the current Internet [24}. For example, the data from
`the base stream could be sent such that it is resilient
`(up to a point) to loss. One way to do this is to add
`redundancy, e.g. using forward error correction tech-
`niques. In any case,
`the ability to trade off cost and
`quality makes rate adaptive applications attractive in
`an integrated services network.
`
`Acknowledgements
`
`The insights obtained with IVS are the result ofjoint
`work with Thierry Turletti, Christian Huitema, and Ian
`Wakeman. The ideas presented in the paper have been
`shaped very much by work carried out in the End-
`to-Encl, RSVP, and Integrated Services IETF working
`groups, and by discussions with members (in addition
`to those mentioned above) of the networking groups
`at INRIA and UCL and with colleagues at Bellcore
`and at the AT&T Bell Laboratories.
`
`References
`
`[11 U. Bilting. A. Sasse. C-D. Schulz and T. Turletti. Remote
`seminars
`through multimedia conferencing: Experiences
`from the MICE project, Prat‘. .’NET'94. Prague. June I994.
`[2] .l-C. Bolot, T. Turletti and I. Wakeman. Scalable feedback
`control for multicast video distribution in the Internet. Pmc.
`
`'94. London. September I994. pp. 58-61‘.
`ACM Sigcoinni
`I3} B. Braden. D. Clark and S. Shenker. Integrated services in
`the Internet architecture: an overview, RFC 3633. I993.
`[4| C-T. Chen and A. Wong. A self-goveming rate buffer control
`strategy for pseudoconstant bit
`rate video coding.
`IEEE
`Trans. Image Process. 2 (I) (1993) 50-59.
`[5] R. Cocchi. S. Shenker. D. Estrin and L. Zhang, Pricing in
`computer networks: Motivation, fonnulation, and example.
`IEEE/ACM Trans. Nenvrirkiitg 1 (6) ([993) 614-626.
`I6] C. Elliott, High quality multimedia conferencing through El
`long-haul packet network. Pmc. ACM Mulriirtedia '93. L05
`Angeles. Calif.. August I993. pp. 91-98.
`[7| R. Frederick, Experiences with real—time software video
`compression, Prue. 6n‘: Packet
`lrldeo llbrksltriir. Portland-
`Oreg., September I994.
`[BI M.W. C-an‘ett, ATM service architecture: From applicationsto
`scheduling, Contribution to the ATM Forum. avaiiable from
`URL
`ftp:2't/thumper.bellcore.com{pub/'n1wglATMF-fl°5‘
`inwg
`
`

`
`J'.~C. Bolor/Corrtpttter Networks aria‘ ISBN S_vstem.r 28 ( 1996) 645-65}
`
`65|
`
`
`
`received his
`Jean-Chrysostome Bolot
`M5. and Ph.D. from the University of
`Maryland at College Park in [988 and
`[99l. respectively. Since then, he has
`been working at INRIA in Sophia An-
`tipolis (France) in the high speed net-
`working research group. His research in-
`terests include resource allocation and
`
`control algorithms, multimedia applica-
`tions, and traffic measurement and anal-
`ysts.
`
`|
`
`|
`
`|t)| M. Gilge and R. Guseila. Motion video coding for packet—
`switching networks — An integrated approach, Proc. SPJE
`Cmif on Vimal Cotnrnrorr'catt'rm.r and forage Processing,
`Boston. Mass. November 1991.
`for audiovisual
`|(}| Recommendation H.261: Video codec
`services at p*64 kbfs. CCITT White Book. I990.
`I N. Jayant. J. Johnston and R. Safranek. Signal compression
`based on models of human perception. Proc. IEEE 81 {I0}
`t_ I993) 1385-1422.
`|’3] V. Jacobson. Congestion avoidance and control. Proc. ACM
`Sl_i{{‘rllJlJJl
`'88, Stanford. Calif.. August I983. pp. 3l4—329.
`|;3| V.
`Jacobson and S. MacCanne. VAT. Manual pages.
`Lawrence Laboratory. University of Califomia, Berkeley.
`Calif.
`
`[
`
`i
`
`|
`
`|]4{ K. Jeffay. D_L. Stone. T. Talley and FD. Smith. Adaptive,
`best—effort delivery of digital audio and video across packet-
`switched networks. Proc. 3rd lnt. Workfltop on Network and
`()3 Sttpporrfltr Digital Audio and Video. San Diego. Calif..
`November 1992.
`
`P. Mishra and A. Reibman. An adaptive
`J I5! H. Kanakia.
`congestion control
`scheme
`for
`real-time packet video
`transport. Proc. ACM Sigcomm '93. San Fransisco, Calif..
`September I993. pp. 20-3!.
`1 lol F.P. Kelly. Efiective bandwidths at multi-ciass queues.
`Qtietreirtg Systems 9 (1991) 5-16.
`[ |7| W. Leland. M. Taqqu, W. Willinger and D. Wilson. On the
`self-similar nature of Ethernet traffic. Proc. ACM Sigcomm
`'93. San Fransisco. Calif., September I993. pp. 183-193.
`|I8| J. Macléie-Mason
`and
`H.
`Varian.
`Pricing
`the
`lntemet, available from URL ftp:2'I'gopher.econ.lsa.umich.
`cdut’pub!PaperslPricingJhe-lntemet.ps.Z.
`|I9| A. Parekh and R.G. Gallager, A generalized processor
`sharing approach to flow control
`in integrated services
`networks. Proc.
`IEEE lnfocom '93. San Fransisco. Calif.,
`March I993. pp. 521-530.
`I20! H. Schulzrinnc, Voice communication across the Internet:
`11 network voice terminal. Research Report, Department
`of Electrical Engineering. University of Massachussets at
`Amherst. July 1992.
`l2| I S. Shertker. Fundamental design issues forthe future Internet.
`presentation at the July I993 IETF meeting.
`l22| C. Topolic. Experimental Internet Stream Protocol Version
`2 (ST-2). Internet RFC I190, October 1990.
`[23] T. Turtetti. H.261 software codec for videoconferencing over
`the Internet. INRIA Research Report 1834, January I993.
`|24| T. Turletti and J-C. Bolot.
`Issues with multicast video
`delivery in heterogeneous networks, Proc. 6:}: Pocket Video
`lvl/orksltop. Portland. Oreg., Sepember I994.
`interaction
`|251 l. Wakeman. Packetized video — Options for
`between the user. the network, and the codec. Comprrt. J.
`36 (I) (1993).
`|26| F. Wilson.
`I. Walreman and W. Smith. Quality of
`service parameters for commercial application of video
`telephony. Pmc. Human Factors in Telecontmunication
`S_\vnp.. Darmstadt. Germany, March I993.
`|27| L. Zhang. S. Deering. D. Estrin, S. Shenker and D. bppalq.
`RSVP: at new resource Reservation Protocol. IEEE Network
`
`[September 1993}.