From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1453.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc1453.txt (limited to 'doc/rfc/rfc1453.txt') 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 -- cgit v1.2.3