rfc1453.txt

<VC++网络游戏建摸与实现>源代码

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]