RPX Exhibit 1019
`RPX v. DAE
`
`

`
`
`Multimedia
`
`SYSTEMS
`
`Aims and Scope
`Multimedia systems publishes original
`research articles and serves as a forum
`for stimulating and disseminating
`innovative research ideas, emerging
`technologies, state-of—the-art methods
`and tools in all aspects of multimedia
`computing, communication, storage,
`and applications among researchers,
`engineers, and practitioners. Theoreti-
`cal, experimental, and survey articles
`are all appropriate to the journal.
`Specific areas of interest include:
`1
`integration of digital video and audio"
`capabilities in computer systems
`2 Multimedia information encoding
`and data interchange formats
`
`3 Operating system mechanisms for
`digital multimedia
`‘
`4 Digital video and audio networking
`and communication
`
`5 Storage models and structures
`6 Methodologies, paradigms, tools,
`and software architectures for sup-
`porting multimedia applications
`7 Multimedia applications and applica-
`tion program interfaces, and multi-
`media endsystem architectures
`
`
`
`A2
`
`o
`
`Copyright
`Submission of a manuscript implies: that
`the work described has not been published
`before (except in the form of an abstract or
`as part of a published lecture, review, or
`- thesis); that it is not under consideration for
`publication elsewhere; that its pubiication
`has been approved by all coauthors, if any,
`as well as by the responsible authorities at
`the institute where the work has been car-
`ried, out; that, if and when the manuscript
`is accepted for pubiication, the authors
`agree to automatic transfer of the copyright
`to the publisher, and that the manuscript
`wili not be published elsewhere in any lan-
`guage without the consent of the copyright
`holders.
`
`All articles published in this journal are pro-
`tected by copyright, which covers the ex-
`clusive rights to reproduce and distribute
`the article (e.g., as offprints), as well as all
`translation rights. No material published in
`this journal may be reproduced photogra-
`phically or stored on microfilm, in electronic
`data bases, video disks, etc., without first
`obtaining written permission from the pub-
`iisher.
`
`The use of general descriptive names, trade
`names, trademarks, etc., in this publication,
`even if not specifically identified, does not
`imply that these names are not protected
`by the relevant laws and regulations.
`While the advice and information in this
`journal is believed to be true and accurate
`at the date of its going to press, neither the
`authors, the editors, nor the publisher can
`accept any legal responsibility for any errors
`or omissions that may be made. The pub-
`lisher makes no warranty, express of im-
`plied, with respect to the material contained
`herein.
`
`Special regulations for photocopies in the
`USA: Photocopies may be made for per-
`sonal or En-house use beyond the limita-
`tions stipulated under Section 107 or 108 of
`U.S. Copyright Law, provided a fee is paid.
`This fee is US $ 0.20 per page per copy,
`plus a basic fee of US $ 2.00 per article. All
`fees should be paid to the Copyright Clea-
`rance Center, lnc., 21 Congress Street,
`Salem, MA 01970, USA, stating the ISSN
`0942-4962, the voiume, and the first and
`last page numbers of each article copied.
`The copyright owner’s consent does not in-
`clude copying for general distribution, pro-
`motion, new works, or resale. in these
`cases, specific written permission must first
`be obtained from the publisher.
`
`.3
`
`Subscription information
`Volume 1 (6 issues) will appear in 1993.
`North ‘America. Recommended annual sub-
`scription rate: approx. US $ 238.50 (single
`issue price: approx. US $ 46.00) including
`carriage charges. Subscriptions are entered
`prepayment only. Orders should be
`addressed to:
`Springer-Verlag New York Inc.
`Service Center Secaucus
`44 Hartz Way
`Secaucus, NJ 07094, USA
`Tel. (201) 348-4033, Telex 0023-1 25 994
`Fax (201) 348-4505
`‘
`All other countries: Recommended annual
`subscription rate: DM 320.00 plus carriage
`charges; [Federal Republic of Germany: DM
`11.24 incl. value added tax; all other coun-
`tries: DM 21.00 except for the foltowing
`countries to which SAL delivery (Surface Air-
`mail Lifted) is mandatory: Japan, lndia, Aus-
`tralta/New Zealand. SAL charges and airmail
`delivery to all other countries are availabie
`upon request].
`Volume price: DM 320.00. single issue price:
`DM 64.00 plus carriage charges. Reduced
`rate for personal subscribers is available
`upon request.
`. Orders can either be placed via a bookdealer
`or sent directly to:
`‘Springer-Verlag, Heidelberger Platz 3
`D-14197 Berlin, Germany
`Tel. (0) 30/82 07-0, Telex 183 319
`FAX (0) 30/8 21 40 91
`Changes of address: Allow six weeks for all
`changes to become effective. All communi-
`cations shouid include both old and new ad-
`dresses (with postal codes) and should be
`accompanied by a mailing label from a re-
`cent issue.
`According to § 4 section 3 of the German
`Postal Services Data Protection Regulations,
`the German Federal Post Office can inform
`the publisher of a subscriber's new address
`even if the subscriber has not submitted a
`formal application for mail to be fon/varded.
`Subscribers not in agreement with this pro-
`cedure may send a written complaint to
`Springer-Verlag’s Berlin office within 14 days
`of publication of this issue.
`Microforrn
`Microforrn editions are available from:
`University Microfilms international 300 N.
`Zeeb Road, Ann Arbor, Ml 48106, USA
`Production
`Springer-Verlag, May Doebl
`Journal Production Department ll
`Postfach 105 280, D-69042 Heidelberg,
`Germany
`Tel. (0) 62 21/48 7439, FAX (O) 62 21/4876 25
`Responsible for advertisements
`Springer-Verlag, E. Ltickermann
`Heidelberger Piatz 3, D-14197 Berlin, Germany
`Tel. (0) 30/8207-0, Teiex 185411
`FAX (0) 30/8 20 73 00
`Printers
`Zechnersche Buchdruckerei
`D-67346 Speyer, Germany
`© Springer-Verlag Berlin Heidelberg 1993
`Springer-Verlag GmbH & Co. KG
`D-14197 Berlin, Germany
`Printed in Germany
`
`

`
` svsnams
`Multimedia
`
`Volume 1
`
`Number 1 1993
`
`Rangan PV, Ferrari D,
`Herrtwich RG
`
`Editorial
`
`1
`
`Schooler EM
`
`The impact of scaling on a multimedia connection
`architecture 2
`
`Zhang HJ, Kankanhalli A,
`Smoliar SW 4
`
`Automatic partitioning of fufl-motion video
`
`10
`
`Borenstein NS
`
`MIME: a portable and robust multimedia format for
`internet mail 29
`
`Amenyo JT, Lazar AA,
`Pacifici G
`
`Proactive cooperative scheduling and buffer management
`for multimedianetworks 37
`
`Events 50
`
`
`
`Springer International
`
`A3
`
`

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

`
`3
`
`which each system supports simultaneous teleconferencing
`sessions.
`
`Although shared workspace applications, such as MM-
`Conf, function across WANs, they perform markedly better
`within LANS (Crowley 1990). This comes as no surprise
`since to maintain an actively changing global view of the
`workspace, these applications require reliable communica-
`tion among all users. Typically the application is built on
`top of an N-by-N collection of TCP/IP streams, which can
`be problematic within the general Internet (Postal 1981; Pos-
`tel 1980). A badly timed network outage or routing problem
`between one pair of conferees might lead to inconsistency in
`the shared view. To reconstitute the state, a WAN—sensitive
`
`session protocol might be layered above the transport to de-
`tect and correct peers that are out of synchronization.
`
`Real~time teleconferencing systems, such as Etherphone
`and Phoenixphone, the CAR project and various CoDesk
`applications, support digital media over a LAN with central-
`ized conference management (CM) (Eriksson E992; Hand-
`ley 1992; Swinehart 1990; Vin et al. 1991). In contrast, the
`Touring Machine and Rapport represent a class of systems
`that combine analog media with centralized computer—based
`session control (Ahuja et al. 1988; Arango 1992). In both
`cases, concurrency is supported, but only as much as the
`media crossbar switches or the LANs can physically sup-
`port. To approximate WAN conferencing, analog systems
`use a proxy to link two distinct LAN communities through
`a commercial codec.
`
`The second row of diagrams shows systems that are well-
`equipped for certain aspects of WAN operation by virtue of
`their decentralized architectures (Chen et al. 1992; Schooler,
`
`in press; Schulzrinne 1992a; Turletti 1993). In addition, the
`multimedia conference control program (MMCC) was de-
`signed to accommodate the likelihood in a WAN environ-
`ment of heterogeneity at the end systems and the need to
`provide robust sessions across the network (Schooler,
`in
`press). Popular IETF tools, such as the visual audio tool
`(vat) from Lawrence Berkeley Laboratory, Xerox PARC’s
`
`network video program (nv), the INRIA videoconferencing
`system (ivs), the network voice terminal (nevot) from Uni-
`versity of Massachusetts, and Bolt, Beranek and Newman’s
`desktop video conferencing program (dvc), specifically use
`a lightweight session model to support larger conferences of
`widely distributed participants (Schulzrinne 1992a; Turletti
`1993). All of these systems, however, are bound in varying
`degrees by the number of users per conference. None provide
`explicit support for large numbers of concurrent conferences,
`due to the Internet’ s lack of infrastructure for real-time media
`
`and wide—scale multicast addressing. These last two classes
`of systems, formally differentiated by their style of session
`moderation, will be contrasted in a later section.
`
`As can be seen in all five diagrams, even projects that
`scale in one dimension typically have architectural defi—
`ciencies in the other dimensions. To understand the prob-
`lem space better, we analyze how conference requirements
`change as we travel along each axis of scale.
`
`Teleconf Applicatio
`
`
`
`Fanidpants:
`Eva. Steve. and Joe
`
`
`Audio: high qua]
`Wduo: adequate qua!
`
`Speed: rmdarala
`Cosl: modarada
`
`Connection Manager
`
`
`
`Video agents:
`
`Audio agents:
`PicTol
`PC“
`___
`
`AEJPCM
`
`
`Camuctian
`Carurol
`Pramcal
`
`VI/I//////A
`
`
`
`Fig. 1. Flow of control information
`
`tridge 1992). Peer connection managers work to negotiate
`a suitable coruiguration by relying on interactions between
`each connection manager and its media agents, and between
`each media agent and the underlying network services.
`For example, in the simplified scenario in Fig. 1, an ap-
`plication asks the connection manager for highmquality au-
`dio and adequate—quality video over moderate-speed links
`for moderate cost. The configuration directory service is
`consulted by the connection manager and identifies media
`agents that both meet the specifications and are available. In
`this case, the configuration directory service translates qual-
`ity, speed and cost into media agents that provide specific
`encoding/data rate capabilities. Once notified, the initiator’s
`local media agents may opt to reserve any devices (cam-
`eras, codecs, etc.) and network bandwidth upon which they
`will rely. The initiator’s connection manager then commur1i—
`cates the request to the other participants’ connection man-
`agers, negotiating particulars as needed. At this stage, the
`remote connection managers go through the same process
`of _locating appropriate media agents and reserving the re-
`quired resources. Finally, each connection manager instructs
`its local media agents to begin sending data, which means
`that the media agents estabiish real-time transport sessions
`(Schulzrinne 1992b). In a more optimistic scheme, the me-
`dia agents would wait to reserve resources until all members
`have actually responded to the initial participation request;
`delayed reservation however may lead to service denial.
`
`2 The problem of scale
`
`Most experimentation with packet teleconferencing systems
`has been conducted within local area network (LAN) set-
`tings, with few users and with a modest degree of support for
`simultaneous conferences. In Fig. 2 we display a sampling of
`these systems. The x—axis denotes users per conference, the
`y—axis the locality of the users {LAN vs wide area network
`(WAN)], and the z~axis depicts concurrency, or the degree to
`
`

`
`Simultaneity
`
`(Bherphone,
`Phomixphonc.
`
`SHARED WORKSPACE:
`targeted,“ LAN
`operation. bul can
`Iundion across WAN
`
`REAL—-TIME MEDIA:
`centralized CM
`
`(l‘om-Eng Mathinz.
`
`I‘
`as FIT ANALOG MEDIA
`centralized CM,
`
`
`
`
`
`
`
`
`102
`:0‘
`10°
`Userslconference
`
`203
`
`to‘
`
`
`
`
`RT MEDIA, TIGHT CTF1‘.L'
`dislnbuled CM.
`tuned for WAN
`
`102
`10‘
`10°
`Users/conference
`
`103
`
`re‘
`
`(IETF mats:
`vat, nv, ivs, never, dvc)
`
`RT MEDIA. LOOSE CTRl_'
`no CM,
`tuned to: WAN
`
`2.1 Scaling to large teleconferences
`
`There is a wide operating range of session sizes and modes.
`We briefly examine three points along the horizontal axis that
`correlate to small, medium, and large conferences. This list
`is by no means complete but gives a sense of the parameters
`affected by the number of users per conference.
`
`small A small number of participants (ones or a few
`tens of individuals) allows impromptu sessions that are
`equivalent to our everyday use of the telephone and face-
`to-face meetings. It a]lows.full connectivity among all users
`in all media (real—time, nonreal—time, control data), flexibility
`in configuration and negotiation of conferencing parameters,
`authentication of participants, and the exchange of data en-
`cryption keys.
`
`medium As we approach medium~sized sessions (hun-
`dreds or thousands of participants), we begin to emulate in-
`teractive seminars that are too large for N-way sharing of ei-
`ther data or control. However, impromptu feedback channels
`are stillneeded along with support for dynamic membership.
`At this size, privacy becomes less practical to provide, even
`though it might still be desired. The IETF teleconferences
`were the first mediurn—sized experiments in the Internet (Cas-
`ner and Deering 1992).
`
`large Large conferences (hundreds of thousands or mil-
`lions of participants) are analogous to TV broadcasts. Infor-
`mation is disseminated in one direction, sessions are pre-
`arranged or even permanent, and descriptions of sessions
`remain static. All except the largest conferences should ac-
`commodate snbconferencing.
`
`2.2 Scaling to a large, dispersed user population
`
`Conferences within LANs often exploit the fixed community
`of user names, simplified authentication, and homogeneity
`among end-system configurations. It is feasible to maintain
`a list of user names in a local directory and list them in a
`calling menu in the user interface. Farther along the axis,
`the interdomain problem of obtaining unique user identifiers
`
`Fig.2. Axes of scale: current teleconferencing architec-
`tures
`
`arises. One naming technique is to combine user names with
`machine names. A drawback with this approach is that it
`normally ties the user to a particular location, and with user
`mobility, the user—to-address mapping requires location inde-
`pendence. However, location-independent addressing will be
`developed for the use of mobile Internet hosts in a more gen-
`eral context; teleconference user naming will need to build
`on this capability.
`WAN conferencing brings greater likelihood of hetero-
`geneity, less assurance of robustness, increased propagation
`delay, and movement away fiom centralized designs to ones
`that are replicated or hierarchical. Although calling menus
`might still be useful to list a personal set of aliases, the po-
`tentially large community of users makes it impossible to
`list all possible callees. More likely, interdomain telecon-
`ferencing will rely on a distributed directory to manage the
`increased naming complexity.
`A dispersed and varied user population will come about
`only when multiple, interoperable teleconferencing systems
`have been implemented in inexpensive hardware and soft-
`ware. For the hardware, we depend upon the vendors. For
`the software, standardized protocols must be developed, and
`modularity and flexibility in the system architecture must he
`achieved as primary design goals.
`
`2.3 Scaling to many simultaneous teleconferences
`
`The sirnultaneity axis is not quite as straightforward, since
`the raw number of concurrent sessions is uninteresting. More
`intriguing is that simultaneous sessions generate competition
`for limited resources, both at end systems and inside the ,
`network. From the network’s perspective, the main resource
`under contention is bandwidth, but group addresses, shared
`multimedia devices and users themselves also become com-
`
`modities. From the user’s perspective, resource discovery
`is needed to locate these shared commodities, and partici-
`pation management is needed for call waiting, forwarding,
`suspension, merging, subconferencing, browsing, and filter—.
`iug, among other functions.
`
`

`
`3 Key issues: discussion and directions
`
`Assessment of the problem space reveals a number of criti-
`cal needs for a scalable teleconferencing architecture: a range
`of session control schemes, multicast-address management,
`
`techniques for bandwidth reduction, a. suite of directory ser-
`vices, and the detailed codification of heterogeneity. There-
`fore, we revisit our choice for a session control protocol,
`discuss the integration of mnlticast addressing and directory
`services into our model, and elaborate on additional tech-
`. niques for bandwidth reduction and heterogeneity.
`
`3.1 A scalable session model and its protocols
`
`A variety of researchers have explored frameworks for well-
`contained conferences (Ahuja 1988; Arango 1992; Chang
`and Whaley 1992; Chen et al. 1992; Crowley et al. 1990;
`Garcia-Luna-Aceves et al. 1988; Lauwers and Lantz 1990;
`
`Leung et al. 1990; Schooler 1992b; Swinehart 1990; Vin et
`al. 1991); in this tightly-controlled model, complete session
`information is actively shared among and consistently main-
`tained by all conference participants. Participants receive ap-
`praisal of who else is involved and acknowledgment that
`conference state information is current and that communica-
`
`tion is reliable. By comparison, ETF multicasts are loosely-
`controlled conferences, where an attendee simply “tunes in”
`to the agreed~upon multicast address and begins transmitting
`and/or receiving data. There is no coordination with other
`end systems, and the conference state is constructed asyn-
`chronously through the passive (but regular) receipt of con-
`trol messages from other group members. Even though the
`IETF experiments used minimal session management, some
`management functions were simply bypassed by shortcuts.
`Since there was only one conference, its parameters could
`be defaulted in the application program, and some functions
`were handled manually that would need to be automated in
`a production system.
`Because the first scheme relies on full interconnectivity
`for conference setup and maintenance, it does not scale as
`well as the latter scheme, which is more lightweight. As we
`scale up in teleconference size, it is not practical to do the
`full exchange of status information among all participants for
`tight control. It would take too long even for one participant
`to contact all the others, and overload would result if all the
`
`participants tried to contact or respond to the same conferee
`at the same time. A second choice would be to distribute
`
`the conference parameters to a set of intermediaries who
`would each be contacted by a smaller set of participants.
`A third, more extreme choice, would be to post a static set
`of parameters to a single third party, like a TV guide, or
`publicly reachable bulletin board.
`
`With many participants, negotiation of parameters also
`would become impractical because it would take too long to
`converge upon an agreement, and the probability of agree-
`ment (finding a common solution) would become small. An
`alternative is to use a common standard chosen by the con-
`
`5
`
`ference originator, and only those who can accommodate
`that standard can participate.
`*
`This is not to say that loose control is the complete so-
`lution. For large conferencing, even passive transmission of
`liveness messages under a loose-control scheme leads to siz-
`able overhead at receivers. Simple communication of partic-
`ipant names on a periodic basis (every 63) will consume
`as much bandwidth as a continuous voice channel when
`
`the number of participants reaches 300. The period of the
`updates could be increased or dynamically regulated, but a
`more explicit control protocol that did not require periodic
`transmission might be a better solution. The more apparent
`disadvantages of loose conferencing is that it lacks support
`for coordinated group interactions or consensus, e.g., for an-
`thentication, floor control, invitations, or quality-of-service
`
`negotiations.
`These two models represent but two points ‘n1 a spectrum
`of services. They are targeted roughly at small and medium-
`sized conferences. Large conferences require yet a different
`session model that (in the extreme) has little (to no) setup,
`maintenance, or communication among participants. Do we
`devise a session protocol to adapt over the range of confer-
`ence sizes and modes, or do we create a family of separate
`
`protocols for distinct circumstances? The trend for Internet
`standards is toward simplicity, which might suggest theAde—
`velopment of a small number of simple protocols instead of
`one complex protocol. The characteristics that differentiate
`these models from one another (level of interconnectivity for
`session management, flexibility in negotiations, reliability of
`communication, dynamics of session state, requirements for
`a consistent global view) need further scrutiny and organi-
`zation, for they will ultimately influence the outcome. They
`will dictate the behavior of a more complete session pro-
`tocol or define the demarcation points where one protocol
`ends and another begins.
`Thus, in Fig. 3 we reframe the architecture in terms of
`a scalable session manager and a scalable session protocol
`upon which it relies. An extension of the original connection
`manager, the scalable session manager provides a range of
`conference types beyond and including the tightly—controlled
`sessions initially supported. We move away from the em-
`phasis on a connection-oriented nomenclature, since some
`of the session types are connection—less in nature (i.e., state-
`less) and since we want to avoid confusion between the use
`of the term “connection” at various levels in the protocol
`stack.
`
`A final, yet important aspect to the design of a scalable
`session model is the evaluation of options for anunderly-
`ing transport service that is both reliable and multicast (Bir-
`man et at. 1990; Cheriton 1989; Sun Microsystems 1988).
`For conferencing in the large, the transport will need to be
`lightweight as well. Reliable multicasting is needed both
`in session management and for shared workspaces that are
`sometimes referred to as groupware. Unlike real-time me-
`dia that require a service to support bandwidth guarantees,
`session control messages and groupware data flows, under
`many conditions, require a transport service that offers reli-
`
`

`
`Suile a_/"Service:
`
`Teleconf Applicatio
`
`Speed: rmdaraln
`
`
`Farficipanuz
`Eva. Steve, and Joe
`Aufioz high qua!
`W100: adequate qua]
`Cast: moderate
`
`
`
`
`
`
`Scalable Session Manager
`
`Scalablc
`Session
`I’ratacaI(:)
`
`Reliable
`Mullicaxt
`Protocol
`
`R:aI—~7'inIe
`Tramrpafl
`Pmlocol
`
`Real-Tiiznc
`Trcuupan
`Prntocal
`
`Fig.3. Architecture components for scalable telecon-
`ferencing
`
`'/////II//A
`
`ability. In Fig. 3, we associate different transport needs with
`the different audio, video and groupware media agents, and
`imply that the scalable session protocol may be built on top
`of a transport service similar to that required by a groupware
`media agent.
`’
`
`3.2 Multicast address management
`
`As teleconferences scale up in numbers of users, multicast
`addressing becomes essential for bandwidth reduction, con-
`sidering that there is an N x N bandwidth explosion for
`media such as video that normally transmit continuously.
`As teleconferences scale up along the other axes, manage—
`merit of these group addresses becomes more difficult. For
`initial IETF experiments, IP multicast addresses have been
`assigned manually and distributed out—of-band. One compli-
`cation is that there is a fixed number of multicast addresses.
`Because most telecollaborations will be transient, address as-
`
`signment and reassignment will be highly dynamic. A global
`scheme is required to avoid unwanted address collisions and
`to promote reasonable address space sharing. A plan has
`been presented (Schulzrinne 1992b) to partition addresses
`among a hierarchy of multicast address servers; addresses
`are borrowed from other servers of than or equal stature in
`the hierarchy, and servers reuse addresses by exploiting lo—
`cality. To offload dynamic addressing mechanisms, we can
`make use of fixed multicast addresses for static conferences
`
`and use unicast addressing in point—to-point calls.
`We envision a local multicast address server being re-
`sponsible for a single LAN. As shown in Fig. 3, the re-
`quest for a multicast address comes from an individual media
`agent, or comes from the session manager if the address is
`being used to send control messages or to multiplex more
`than one media type. For conferences that are not publicly
`registered, the session manager distributes the multicast ad-
`dress(es) as part of the session configuration process.
`
`3.3 Techniques for bandwidth reduction
`
`Conferencing in the large requires network resource manage-
`ment mechanisms to avoid congestion. Those mechanisms
`will have to scale to track many connections or flows at
`once, perhaps using some form of aggregation. Others are
`working on these problems in their research projects, and we
`expect to test and to integrate their solutions as they become
`available (Clark et al. 1992; Crowcroft et al. 1990; Ferrari
`et al. 1992; Topolcic 1991; Zhang et al.,
`in preparation).
`Specifically, the session manager will collect conference op-
`erating parameters from the user interface and will deliver
`them to these lower-level mechanisms for translation into
`flow specifications (Partridge 1992). Before these mecha-
`nisms are deployed, it will be possibie to use lightly loaded
`networks as they are.
`
`While multicasting reduces bandwidth usage by senders,
`in N-way conferencing the receiver is still faced with a band~
`width N times that of the sender. Thus, mechanisms are also
`needed for reductions at receivers. A receiver may only want
`to process M of the N streams that are sent to it, or may
`have a problem decoding and presenting all the information
`(e.g., video windows, text aliases for conferees).
`
`One solution is to allow only a fraction of the sources
`to transmit at any one time. Other researchers have sug-
`gested a market—based approach wherein a source is enabled
`to transmit only if there is a sufficient number of receivers
`requesting that source (Jacobson 1991). A limitation of the
`market—driven scheme is that the data from an enabled source
`
`would still go to all receivers, including those that had not re»
`quested that source. A more general solution is to allow traf~
`fic decisions to be made hierarchically, not just at the sender.
`That is, there may be enough bandwidth (and demand) for
`the traffic of one source to go to some destinations, but not
`to others. It would be possible to set up separate multicast
`trees from each source to exactly the set of receivers desiring
`
`

`
`that source. However, for a large teleconference, that might
`require too many network resources (such as IP multicast
`addresses).
`
`We propose application-level combination nodes that
`work in conjunction with participant sources and sinks —
`to avoid wasting network bandwidth by deferring reduction
`decisions until data arrives at the receiver. They would act
`to combine media streams at the application level hierarchi-
`cally as they head toward the receivers. These include soft-
`ware or hardware modules that embed functions for: mix-
`
`.
`
`ing, as with audio streams; compositing, assembling the in-
`teresting pieces of several video flows into a single flow;
`selection, by a sender (chairperson) or receiver (individually
`tailored);
`translation, between encodings; reduction, when
`scalable coding is used; and combinations of these opera-
`tions along the path from senders to receiver. Multiple com-
`bination operations might occur at different points along the
`path to incorporate additional sources, and the combinations
`may change over time, depending on control inputs from the
`receivers.
`
`Combination nodes are likely to be separate from the end
`systems involved in the conference. As such, they must be
`incorporated into all aspects of session management, address-
`ing, and routing. They are likely to be described in terms of
`the function(s) they perform, to act as shared resources in
`the network and to be located at branching points in the
`spanning trees of multicast routes. The drawbacks of using
`a combination node are control/routing complexity and in-
`creased transmission delay. Fortunately, necessity sometimes
`decides for us, as in the case of a slow link. A mixer up-
`stream from the slow link would be located, then used to
`combine several streams into one to circumvent bandwidth
`hmitations that would otherwise prohibit or restrict confer-
`ence participation. The system behaves similarly when there
`are incompatibilities between end systems due to heterogene-
`ity. For this case, a tra.nslator'might be used to go between
`coding formats.
`In either event, the component that integrates combina-
`tion nodes into the architecture is the resource synthesizer.
`It is intended to sit between the scalable session manager
`and the configuration directory service (Fig.3). The ‘qual-
`ity of the service it provides is somewhat dependent on the
`configuration directory service, like the other directory ser-
`vices, belonging to a larger hierarchy of information that ex-
`tends beyond the local domain. The presence of a resource-
`synthesis hierarchy raises questions about who owns combi-
`nation nodes and who pays for them. A controversial ques-
`tion to resolve will be: under which set of circumstances is
`it more appropriate to perform these combination functions
`at the application level than at the network level?
`
`7
`
`’ ference names and parameters) for large private and public
`teleconferences, and to keep dynamic information on the de-
`scriptions and availability of combination node functionality.
`There is no need to build these directory capabilities from
`scratch. Rather, the applicability of Prospero, X.500, and/or
`DNS for maintaining and distributing various attributes of
`Internet teleconferencing will need to be explored (Mock-
`apetris 1989; Neuman 1992; Weider and Reynolds 1992);
`such a service must support highly dynamic information,
`replication, and privacy enhancements.
`
`3.5 Codification of heterogeneity
`
`A configuration language for Internet teleconferencing must
`support highly detailed configuration descriptions, if a con-
`nection manager is to provide an abstraction beneath which
`we truly hide the details of ‘end-system heterogeneity. Al-
`though we know that configuration translations occur en
`route from users to flow specification at local and remote
`end systems, we concede that much more work needs to be
`done to define useful configuration descriptions at each stage
`of the process.
`Thus far, the idea of a configuration language has been
`applied only to negotiations among participants in the event
`of end-system heterogeneity (Schooler, in press). As the im-
`guage is in the initial stages of development, negotiations are
`still quite rudimentary and are based entirely in terms of a
`(media, encoding format, data rate) tuple. Vtfith exposure to
`a larger community of users and domains, we expect to dis-
`cover a fuller spectrum of configuration parameters that will
`need representation in the configuration language.
`For instance, codification of heterogeneity is needed to
`support resource synthesis. Of utmost importance are ex-
`tensions to support combination node descriptions. This is
`likely to lead to communication classifications (e.g., 1-to-
`N, N-to-N, 1-to-4), which we believe will be beneficial to
`describe additional conference services and modes. These
`classifications would also provide a basis for the develop-
`ment of a less implementation-dependent conference setup
`and configuration language, focusing on the operations of
`the multiparty connection, rather than the particulars of pa-
`rameterization (Touch 1992).-
`There is also the need for configuration descriptions for
`quality of service at different levels of abstraction. Although
`a user might make quality of service choices from knobs
`in the graphical user interface (with markings such as high-
`resolution video or CD-quality audio), these selections need
`translation into media agent capabilities, which in turn re-
`quire a mapping into network-level flow specifications. The
`configuration language should support different degrees of
`expressiveness.
`