A Comment on Packet Video Remote Conferencing and the Transport/Network Layers
RFC 1453

Document Type RFC - Informational (April 1993; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1453 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        W. Chimiak
Request for Comments: 1453                                         BGSM
                                                             April 1993

         A Comment on Packet Video Remote Conferencing and the
                        Transport/Network Layers

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is


   The new generation of multimedia applications demands new features
   and new mechanisms for proper performance.  ATM technology has moved
   from concept to reality, delivering very high bandwidths and new
   capabilities to the data link layer user.  In an effort to anticipate
   the high bandwidth-delay data link layer, Delta-t [Delta-t], NETBLT
   [RFC 988], and VMTP [RFC 1045] were developed.  The excellent
   insights and mechanisms pioneered by the creators of these
   experimental Internet protocols were used in the design of Xpress
   Transfer Protocol (XTP) [XTP92] with the goal of eventually
   delivering ATM bandwidths to a user process.  This RFC is a vehicle
   to inform the Internet community about XTP as it benefits from past
   Internet activity and targets general-purpose applications and
   multimedia applications with the emerging ATM networks in mind.

1.  Introduction

   Networking is no longer synonymous with analog telephony.  High-
   performance lower-layer networks have made possible exciting new
   applications: collaboratory environments, distributed client/server
   computing, remote conferencing, teleclassrooms, and distributed
   life-sciences imaging.  These applications normally demand a great
   deal of bandwidth and often create operating system bottlenecks.
   Enabling these new multimedia applications entails delivering
   bandwidth to the applications, not just having bandwidth available on
   the network.  This statement may appear obvious, but often solutions
   at the transport layer are satisfied by having bandwidth at that
   layer without sufficient sensitivity to higher-layer access to the
   bandwidth.  The unavailability of bandwidth at upper layers is
   becoming the real issue as the networks are becoming a high-
   performance virtual backplane without concomitant high-performance
   control schemes.  It appears that new services are needed that
   require communication with all layers.  The ATM architecture calls

Chimiak                                                         [Page 1]
RFC 1453             Comments on Video Conferencing           April 1993

   for such an integrated control scheme.

2.  Remote Conferencing

   The challenges of remote conferencing is an application whose
   challenges may be met at the data link layer by the emerging
   broadband networks.  If so, important medical applications such as
   medical imaging for diagnosis and treatment planning would be
   possible [CHIM92].  Remote conferencing would permit imaging
   applications for life sciences through the use of national resource
   centers.  Collaboratory conferences in molecular modeling, design
   efforts, and visualization of data in numerous disciplines could
   become possible.

   At the Second Packet Video Workshop, held December, 1992, at MCNC in
   the Research Triangle Park, North Carolina, a recurrent theme was the
   use of multimedia in remote conferencing.  Its applications included
   the use of interactive, synchronized voice and video transmission,
   multicast transmission, data transfer, graphics transmission,
   noninteractive video and audio transmission, and data base query
   within a virtually shared workspace.  A few participants doubted the
   ability of current computer networks to handle these multimedia
   applications and preferred only connection-oriented, circuit-switched
   services.  Most participants, however, looked forward to using an
   integrated network approach.

2.1.  Remote Conferencing Functions and Requirements

   Remote conferencing as seen at the workshop requires a set of
   functions.  It must provide session scheduling that deals with
   initiating a session, joining in-progress sessions, leaving a session
   without tearing it down if there are multiple participants, and
   terminating a session.

   The remote-conferencing session needs a control subsystem that is
   either tightly controlled for an n-to-n connection for two to 15
   participants, or loosely controlled for a 1-to-n connection for any
   number of participants.  The Multipeer-Multicast Consortium is
   working on defining the control requirements and the mechanisms for
   control.  At the Packet Video Workshop, one participant presented a
   conference control protocol (CCP) shown in Figure 1 [CCP92].  In this
   architecture the CCP controls the Network Voice Protocol (NVP)
   [RFC741] and the Packet Video Protocol (PVP) [PVP81] over the
Show full document text