Programming distributed multimedia applications
Adam Beguelin and Hui Zhang
{adamb,hzhang}@cs.cmu.edu
Introduction
The advent of high speed networks to the desktop will enable a range of
new applications. Many of those new applications will involve
distributed multimedia. Video on demand, desktop video conferencing
and telepresence are several examples we can think of today; others
will follow.
We are interested in the problems of programming distributed multimedia
applications in heterogeneous networks. The widely varying
characteristics of these networks will require innovations for
distributed multimedia both at the transport layer as well as the
application programmer interface. We propose to develop network
transport layer mechanisms and an API to address these issues. In order
to enable effective applications, aspects of the transport layer must
be exposed to the API and application information must be provided to
the transport layer. For this reason we will take a vertical approach
where the API and transport mechanisms are developed in concert.
Here is a chart showing the role of Pyxis in developing
distributed multimedia applications.
Applications
Distributed multimedia applications abound. Consider the medical
field. Patient and physician interactions, physician to physician
consulting, and medical education are examples of distributed
multimedia for collaboration. Referential uses are also very important.
Referential examples include the transmission of visual medical
information, exact numerical test results, and medical record text.
Referential distributed multimedia will need to be lossless while
collaborative aspects of applications can tolerate losses or
degradation of services.
Education and training is another domain where distributed multimedia
applications will be of great importance. Distributed multimedia
applications can facilitate student teacher interaction in terms of
conferencing as well as multimedia educational material.
There are many fields in which distributed multimedia will make an
impact. Our research is not intended to focus on specific application
domains but to develop the infrastructure that will enable applications
to be built rapidly and to efficiently take advantage of the underlying
networks.
Pyxis: The API
In any distributed application the programmer must control the flow of
information among multiple processes. In a distributed multimedia
application this flow of information will have real time constraints
and may have a complicated format, i.e., compressed digital video.
Protocols such as Real Time Protocol (RTP) are being developed for
distributed multimedia. These protocols are a first step in building
distributed multimedia applications. However, for the programmer that
is interested in building an application that incorporates video,
audio, and referential material, the packet level specifications in RTP
are too low level. The programmer is interested in controlling video
streams, not network packets that make up a part of a single frame of
video. For this reason Pyxis provides abstractions such as frames,
streams, and devices, which are suited to programming distributed
multimedia applications but are not so high level that efficiency is
lost. Pyxis can be thought of as a thin veneer on top of the underlying
network services such as IP sockets or ATM virtual circuits.
The programmer must also be concerned with quality of service issues.
However, it is not important that the application programmer deal with
all the details of ensuring a certain level of quality in the
application. In order for the underlying protocols to work well there
are mechanisms that keep track of lost packets, latency, bandwidth,
jitter, etc. The programmer need not deal with these issues directly.
Our approach is to allow the programmer to set bounds on these
attributes. When these bounds are exceeded then the program is
notified and it can take the appropriate action. the program can
either adjust its usage level or negotiate for resources with the
network for more resources. For example the program could reduce its
frame rate to satisfy a reduced latency requirement from the network.
Alternatively the program could decide to pay more in order to keep
its current latency guarantee.
Here is a current specifiction of the Pyxis API.
Transport Issues
There are a number possible of transport services and the task of Pyxis
is to present a unified abstraction and mask the details of each
individual transport service.
The possible underlying services are: guaranteed performance internetworking
service (e.g. Tenet Protocol), predicted internetworking
service (e.g. RSVP), best-effort internetworking
service (e.g. current Internet), guaranteed performance ATM
service (ATM constant bit rate, CBR, or variable bit rate, VBR, service),
and flow controlled ATM service (rate-based or credit-based ABR service).
For guaranteed services and predicted services, we need to map the
application level quality of service parameters to the transport level
parameters. While different protocols support different traffic
specification interfaces, Pyxis will support a unified abstraction that
is independent of the underlying interfaces.
For best-effort service, no quality of service is provided by the underlying
network, however many techniques can be applied to minimize the quality
degradation in the presence of packet losses. These techniques are usually
media specific, i.e. different techniques will be used for MPEG compressed
video, or JPEG compressed video, or voice. Pyxis will implement media-specific
control software and signals application by a call-back interface only when
the quality degradation cannot only be masked by the control software.
Flow controlled ATM services are more robust than the best-effort service
provided by the current Internet. Although the techniques used in Internet
can be directly applied in this environment, they can be further enhanced
by utilizing the specific characteristics of the ABR service.
Evaluation
In order to test our API and transport mechanisms we will use our API
and transport level innovations to build distributed multimedia
applications that are both collaborative and referential.
Initial applications for Pyxis will be a video conferencing tool that
will interoperate with the MBONE tool Vic and a remote client interface
for the Informedia project.
Conclusion
We are building a system software middleware layer, called Pyxis, that
will support the programming of distributed multimedia applications.
Currently a distributed multimedia application needs to worry about low level
details such as the format of network packets and transmission
protocols. We believe that a small amount of abstraction can greatly
enhance the programability of such systems as well as provide a framework
for the negotiation between an application and the underlying network
protocols.