summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1453.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1453.txt')
-rw-r--r--doc/rfc/rfc1453.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc1453.txt b/doc/rfc/rfc1453.txt
new file mode 100644
index 0000000..10e3a57
--- /dev/null
+++ b/doc/rfc/rfc1453.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+ \ No newline at end of file