GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1453

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
 unlimited.

Abstract

 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
 experimental Internet Stream Protocol, Version 2 (ST-II) [RFC1190]
 rather than IP.
 Latency and intramedia synchronization and intermedia synchronization
 (lip-sync) are critical for the interactive voice and video streams

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

 of remote conferencing.  Client/server applications including data
 base operations are equally important.  The ability to display
 noninteractive video and high-resolution graphics is necessary.
 As with most applications, security will eventually be an issue.  At
 the very least, there must be a mechanism to determine who can find
 out what about conference and who can join a conference.  This
 determination will be part of an upper-layer protocol.
    +--------------+ +--------+ +-----+ +------------+
    |Teleconference| |  File  | |Email| |   Domain   |
    |   (CCP)      | |Transfer| |     | |Name Service|
    +----+-------+-+ +-----+--+ +-+---+ +-----+------+
         |       |         |__  __|           |
         |       |            ||              |
   +-----+--+ +--+-----+    +-++-+       +----+---+
   |Network | | Packet |    | T  |       |    U   |
   | Voice  | | Video  |    | C  |       |    D   |
   |Protocol| |Protocol|    | P  |       |    P   |
   +---+----+ +--+-----+    +-+--+       +--+-----+
       |__     __|            |__         __|
          |   |                  |       |
        +-+---+--+             +-+-------+-+
        | Stream |             |     I     |
        |Protocol|             |     P     |
        +---+----+             +---+-------+
            |                      |
      +-----+----------------------+----+
      |IEEE_802.X,FDDI,DARTnet,ATOMIC...|
      +---------------------------------+
        Figure 1: The Connection Control Protocol Architecture
 The solutions must range in geography from single machines through
 LAN, CAN, MAN, WAN conferences, as well as in data content from PCs
 to high-end workstations.  Implicit in the scaling is the notion of
 product and application interoperability.
 Remote conferencing applications should take advantage of future
 network enhancements, as well as the functions provided by ATM, FDDI,
 and SMDS.  Doing so should provide function versus resource trade-
 offs such as cost versus error control and cost versus rate control.
 As a result, the transport layer should be able to provide the
 services offered by the data link layer.
 Most of the presentation on remote conferencing indicated a need for
 some degree of multicast functionality, ranging from the 1-to-n, with
 conference membership completely known, to conferences for which

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

 existence of a group is known, but exact membership is not.
 In remote conferencing, it is preferable to use one network for all
 information traffic.  This network should have an offered quality of
 service (QOS) criteria to accommodate tradeoff metrics, which would
 include guaranteed throughput, connection reliability, high call-
 completion rate, few dropped calls, tolerable error rate, varying
 degrees of compression on the video and audio streams, and tolerable
 motion artifacts, flow control, and latency.  The QOS should be an
 input to the transport layer from the application or transport
 service user.
 The compression/coding function should provide time-stamping and
 packetizing information, as well as real-time echo cancellation.
 These functions are usually at the presentation and session layer of
 the Open System Interconnection (OSI) model or the at the application
 in some Internet models, but not the transport layer.

3. Potential Solutions

 RFC 1193 deals with the requirements of real-time communications,
 which include some of the same capabilities [RFC1193].  But the
 requirements articulated create the necessity for new
 transport/network protocols.  The new protocols under development by
 the Audio Visual Transport [SCHU92] (RTC, RTCP), and other protocols
 in this area (ST-II) suggest an architecture like that shown in
 Figure 2.
 These approaches may work.  However, they encourage a discipline that
 creates a protocol for each new class of application.  Another
 approach might be to unify the protocols.  It is felt that this is
 one of the main goals of XTP (see Figure 3).
 Other design considerations of XTP include the following:

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

           +----------------------+
           |          media       |
           |       application    |
           +--------+----+-+------+
           |        |RTCP| |      |
           |        +----+ |   T  |
           |         RTP   |   C  |
           +-----+-----+   |   P  |
           |ST-II| UDP |   |      |
           +     +-----+---+------|
           |     |       IP       |
           +-----+-------+--------+
           |    Data Link Layer   |
           +----------------------+
            Figure 2: One emerging multimedia architecture
   +--------------+  +--------+ +-----+ +------------++-----------+
   |Teleconference|  |  File  | |Email| |   Domain   ||   media   |
   |              |  |Transfer| |     | |Name Service||application|
   +------+-------+  +----+---+ +--+--+ +-----+------++-----+-----+
          |               |        |          |             |
          +---------------+--------+----------+-------------+
                                   |
                           +-------+--------+
                           |Unified Protocol|
                           +----------------+
                           |Data Link Layer |
                           +----------------+
         Figure 3: Another integrated multimedia architecture
 (1)  Developing a protocol based on the work and experience of
      the protocol groups such as IETF, which produced NETBLT,
      VMTP, TCP, IP, and UDP.
 (2)  Incorporating lessons from Delta-t.
 (3)  Observing the design paradigm shift of ATM, SONET, and  VMTP
      in the header, trailer, and information segment construction.
 (4)  Targeting the real-time requirements articulated by the
      Department of Defense SAFENET committee and the French
      Ministry of Defense military real-time specification [GAM-T-103].
 Mechanisms in XTP allow an application to approach the performance
 desired.  A session-scheduling mechanism for joining and leaving a

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

 multicast conference exists.  The XTP mechanism for multicast
 satisfies the loosely controlled session requirements.  The tightly
 controlled session would require the use of multiple XTP
 associations.
 The priority mechanism that uses the 32-bit SORT field permits an
 application to prioritize data.  Because XTP is a transport layer,
 this priority mechanism follows through every node tranversed.  There
 is also an out-of-band delivery mechanism.  However, XTP does not
 offer latency control by itself; it just provides a priority
 mechanism.
 The selective acknowledgement, fast negative acknowledgement, and
 selective retransmission permit an application to choose an
 appropriate level of error control.  The combination of the priority
 mechanism and these error-control mechanisms is likely to approach
 the latency and synchronization requirements of remote conferencing.
 Noninteractive audio and video, as well as graphics presentation, can
 be accommodated in many ways by the application.  It is important
 that the transport layer provides adequate mechanisms to deliver the
 appropriate data streams in a manner compatible with the
 applications.  These applications can probably be accomplished by
 means of extant protocols, as well as XTP.
 The scalability of the solution will be a function of the standards
 used.  At the Packet Video Workshop, some of the applications
 sacrificed computer network standards in favor of desired
 performance.  This approach usually impedes scalability.  From the
 explanation of the applications taking this approach, it appeared
 that using XTP would have provided an adequate transport service for
 the applications.
 XTP was designed to provide mechanisms to accommodate application
 requirements, that is, the ability to respond to QOS requests.  For
 example, guaranteed throughput may be accomplished by using XTP's
 rate and burst control together with flow control or no flow control.
 Tolerable error rate can be accomplished with partially error
 controlled connections (PECC), a service which can be placed in the
 application or just above the transport layer [PECC92].  Motion
 artifacts and varying degrees of compression should be done above the
 transport layer in coordination with the transport layer or possibly
 in a network management function.

3.1. Synthesize the Hardware Fabrication Process into the Design

 To produce an affordable solution, the hardware fabrication process
 should be a design consideration.  Technologies are evolving too

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

 rapidly to assume that a generic protocol design will anticipate all
 fabrication advances, but this fact should not impede use of the
 features of advanced hardware fabrication processes.
 System interface problems and VLSI techniques should be considered in
 the specification of the protocol.  An examination of the ATM and
 SONET standards appears to support this philosophy.  Similarly,
 NETBLT and VMTP design efforts seem to support this approach.  XTP
 does use it.
 It is very helpful to break down the protocol into parallel-state
 machines for execution on more inexpensive hardware.  This procedure
 reduces the context switching and interrupt handling requirements of
 the hardware, thereby decreasing production costs while producing a
 scalable protocol machine.

4. Multimedia Applications over XTP

 In parallel with the IETF efforts to enable multimedia applications
 such as remote conferencing, the XTP forum members have been
 experimenting with major elements of these applications.
 (1)  At the University of Virginia, more than 100 simulated voice
      channels were run on an FDDI network [UVAVOICE92].  The
      purpose of this experiment was to test the limits of FDDI
      and a software version of XTP in a simulated interactive
      voice environment.  Multicasted, noninteractive video has
      been supported there for several years.
      UVa also has a video-mail demo over XTP/FDDI that uses
      Fluent multimedia interface and standard JPEG compression.
      This PC-based demo delivers full frame, full color, 30
      frames/sec video from any network disk to a remote VGA
      screen.  It is important that users could not discern any
      difference  in  playback  between  a local disk and a remote
      disk.  An Xpress File System (XFS) is used on server and
      client systems.
 (2)  The Technical University of Berlin, Germany, reports that
      the coordination, implementation, and operation of
      multimedia services (CIO) of the R&D in Advanced
      Communications Technologies in Europe (RACE) is using XTP as
      a starting point for design [XTPRACE].
 (3)  At the Naval Command, Control, and Ocean Surveillance Center
      Research, Development, Test and Evaluation Division NRaD
      (formerly the Naval Ocean Systems Command (NOSC)), voice is

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

      multicasted over XTP/FDDI.  A simple multicast is
      distributed to a group with a latency of around 25 ms, where
      the latency represents delay from the voice signal from the
      microphone to the audio signal to the speaker.  This group
      is currently doing research on an n-party multicast of voice
      (telephone conference-call paradigm [n x n multicast]).
 (4)  Commercially, Starlight Networks Inc., migrated a subset of
      XTP into the transport layer of its video application
      server.  By using XTP rate control, full-motion, full-screen
      compressed video is delivered at a constant 1.2 Mbps, over
      switched-hub Ethernet to viewstations.  This network
      delivers at least 10 simultaneous video streams.
 Therefore, XTP has been used in applications that were previously
 placed over IP or even a data link layer.

5. Policy versus Mechanism

 Separating protocol policies and mechanisms [XTPbk] permits adoption
 of new policies without altering offered mechanisms.  An excellent
 example is UVa's Partially Error Controlled Connections (PECC).  This
 control system maximizes error control in such a way that receiving
 FIFOs are never starved i.e., the application, driver, or operating
 system buffer control, and not the transport layer becomes the
 bottleneck.
 Because XTP is mechanism-rich and policy-tolerant, this very dynamic
 error control policy mechanism is possible.  Separating policy and
 mechanism permits an error-control or flow-control policy to adapt to
 the data link layer conditions without shutting down a connection and
 rebuilding (or multiplexing) a new one on a different protocol stack.
 This may also provide an easier way for a network management
 subsystem to maintain a desired QOS.

6. Summary

 Remote conferencing presents new opportunities for research,
 business, and administration.  Although some are proposing that only
 classical circuit-switched mechanisms be used, most network engineers
 are searching for ways to use the new features of FDDI, SMDS, and ATM
 in multimedia applications such as remote conferencing.  Some new
 applications have been placed directly on a data link layer.  New
 Transport/Network layer combinations have been proposed and are being
 tested.  It is believed that consideration should be given to XTP as
 a possible solution because its forum membership includes commercial,
 government, and research institutions, some of which have implemented
 various applications that contribute to an overall remote-

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

 conferencing application.

7. References

 [CCP92]     Schooler, E., "An Architecture for Multimedia Connection
             Management", in Proceedings of the 4th IEEE ComSoc
             International Workshop on Multimedia Communications,
             Monterey, CA, April 1992.
 [CHIM92]    Chimiak, W., "The Digital Radiology Environment", IEEE
             JSAC, Vol. 10, No. 7, pp. 1133-1144, September 1992.
 [Delta-t]   Watson, R. W., "Delta-t Protocols Specification",
             Lawrence Livermore Laboratory, April 15, 1983.
 [GAM-T-103] French Ministry of Defense, "GAM-T-103 Military
             Real-Time Local Area Network Reference Model
             (Transfer Layer)", February 7, 1987.
 [PECC92]    Dempsey, B., Strayer, T.  and Weaver A., "Adaptive Error
             Control for Multimedia Data Transfer", in Proceedings
             of the IWACA 92, Munich, Germany, pp. 279-288, March
             1992.
 [PVP81]     Cole, R., "PVP - A Packet Video Protocol", W-Note 28,
             Information Sciences institute, University of
             California, Los Angeles, CA, August 1981.
 [RFC1045]   Cheriton, D., "VMTP: Versatile Message Transaction
             Protocol Specification", RFC 1045, Stanford
             University, February 1988.
 [RFC998]    Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk
             Data Transfer Protocol", RFC 998, MIT, March 1987.
 [RFC1193]   Ferrari, D., "Client Requirements For Real-Time
             Communication Services", RFC 1193, UC Berkeley,
             November 1990.
 [RFC1190]   Topolcic, C., Editor, "Experimental Internet Stream
             Protocol: Version 2 (ST-II)", RFC 1190, CIP Working
             Group, October 1990.
 [SCHU92]    Schulzrinne, H., "A Transport Protocol for Audio and
             Video Conferences and other Multiparticipant
             Real-Time Applications", Internet Engineering Task
             Force, Internet-Draft, October 1992.

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

 [UVAVOICE92] Weaver, A. C. and McNabb, J.F., "Digitized Voice
              Distribution Using XTP and FDDI", Transfer, Vol. 5,
              No.  6, pp. 2-7 (November/December 1992).
 [XTP92]     Xpress Transfer Protocol, version 3.6, XTP Forum,
             1900 State Street, Suite D, Santa Barbara, California
             93101 USA, January 11, 1992.
 [XTPbk]     Strayer, W.T., Dempsey, B.J., and Weaver, A.C., "XTP:
             The Xpress Transfer Protocol", Addison-Wesley
             Publishing Company, Inc., 1992.
 [XTPRACE]   Rebensburg, K. and Miloucheva, I., "The Use of XTP in a
             Large European Communication Project", XTP Forum
             Research Affiliate Annual Report, Document 92-183,
             pp. 105-112, 1992.

Security Considerations

 Security issues are discussed in section 2.1.

Author's Address

 William J. Chimiak
 Department of Radiology
 Bowman Gray School of Medicine
 Medical Center Boulevard
 Winston-Salem, NC 27157-1022
 Phone: 919-716-2815
 EMail: chim@relito.medeng.wfu.edu

Chimiak [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1453.txt · Last modified: 1993/04/14 23:46 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki