3) you must know the playback latency of the multimedia hardware
The third of these is the most difficult to achieve at this time.
Hardware and drivers don't provide any mechanism for retrieving this
information, although different audio and video devices have a wide-
range of performance.
6. Service APIs
In some cases, the protocol services mentioned in this document can
be enabled transparently by passive configuration mechanisms and
"middleware". For example, it is conceivable that a UDP
implementation could implicitly enable a reliable multicast protocol
without the explicit interaction of the application.
Sometimes, however, applications need explicit access to these
services for flexibility and control. For example, an adaptive
application sending to a heterogeneous group of receivers using RTP
may need to process RTCP reports from receivers in order to adapt
accordingly (by throttling send rate or changing data encoders, for
example) [RTP API]. Hence, there is often a need for service APIs
that allow an application to qualify and initiate service requests,
and receive event notifications. In Figure 5, the top edge of the
box for each service effectively represents its API.
Network APIs generally reflect the protocols they support. Their
functionality and argument values are a (varying) subset of protocol
message types, header fields and values. Although some protocol
details and actions may not be exposed in APIs--since many protocol
mechanics need not be exposed--others are crucial to efficient and
flexible application operation.
A more complete examination of the application services described in
this document might also identify the protocol features that could be
mapped to define a (generic) API definition for that service. APIs
are often controversial, however. Not only are there many language
differences, but it is also possible to create different APIs by
exposing different levels of detail in trade-offs between flexibility
and simplicity.
7. Security Considerations
See section 5.4
8. Acknowledgements
The authors would like to acknowledge and thank the following
individuals for their helpful feedback: Ran Canetti, Brian Haberman,
Eric A. Hall, Kenneth C. Miller, and Dave Thaler.
9. References
[AnyCast] Partridge, C., Mendez, T. and W. Milliken, "Host
Anycasting Service", RFC1546, November 1993.
[BeauW] B. Williamson, "Developing IP Multicast Networks, Volume
I", (c) 2000 Cisco Press, Indianapolis IN, ISBN 1-57870-
077-9.
[BULK] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S. and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer", RFC
3048, January 2001.
[Deering] Deering, S., "Host Extensions for IP Multicasting", STD
5, RFC1112, August 1989.
[DIS] Pullen, J., Mytak, M. and C. Bouwens, "Limitations of
Internet Protocol Suite for Distributed Simulation in the
Large Multicast Environment", RFC2502, February 1999.
[E2EQOS] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Speer, M., Braden, R. and B. Davie, "Integrated Services
Operation over Diffserv Networks", RFC2998, November
2000.
[Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech
Earthlink Seminar Series, April 22, 1998.
[Finlayson] Finlayson, R., "IP Multicast and Firewalls", RFC2588,
May 1999.
[HNRS] Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy
of Feedback for Multicast", June 1999, Work in Progress.
[IGMPv2] Fenner, B., "Internet Group Management Protocol, Version
2", RFC2236, November 1997.
[IGMPv3] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan,
"Internet Group Management Protocol, Version 3", Work in
Progress.
[IMJ] K. Almeroth and M. Ammar, "The Interactive Multimedia
Jukebox (IMJ): A New Paradigm for the On-Demand Delivery
of Audio/Video", Proceedings of the Seventh International
World Wide Web Conference, Brisbane, AUSTRALIA, April
1998.
[IRTF] Weinrib, A. and J. Postel, "The IRTF Guidelines and
Procedures", BCP 8, RFC2014, January 1996.
[Kermode] Kermode, R., "MADCAP Multicast Scope Nesting State
Option", RFC2907, September 2000.
[LSMA] Bagnall, P., Briscoe, R. and A. Poppitt, "Taxonomy of
Communication Requirements for Large-scale Multicast
Applications", RFC2729, December 1999.
[MADDR] Albanna, Z., Almeroth, K., Meyer, D. and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments",
BCP 51, RFC3171, August 2001.
[MASC] Estrin, D., Govindan, R., Handley, M., Kumar, S.,
Radoslavov, P. and D. Thaler, "The Multicast Address-Set
Claim (MASC) Protocol", RFC2909, September 2000.
[Maufer] T. Maufer, "Deploying IP Multicast in the Enterprise",
(c) 1998 Prentice Hall, Upper Saddle River NJ ISBN 0-13-
897687-2.
[Miller] C. K. Miller, "Multicast Networking and Applications",
(c) 1999 Addison Wesley Longman, Reading MA ISBN 0-201-
30979-3.
[MADCAP] Hanna, S., Patel, B. and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC2730,
December 1999.
[MRM] K. Sarac, K. Almeroth, "Supporting Multicast Deployment
Efforts: A Survey of Tools for Multicast Monitoring",
Journal of High Speed Networking--Special Issue on
Management of Multimedia Networking, March 2001
[MSec] Multicast Security (msec) IETF Working Group charter
[MZAP] Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope
Zone Announcement Protocol (MZAP)", RFC2776, February
2000.
[Obraczka] K. Obraczka "Multicast Transport Mechanisms: A Survey and
Taxonomy", IEEE Communications Magazine, Vol. 36 No. 1,
January 1998.
[Rizzo] L. Rizzo, "Fast Group management in IGMP", HIPPARC 98
workshop, June 1998, UCL London
http://www.iet.unipi.it/~luigi/hipparc98.ps.gz
[RM] Mankin, A., Romanow, A., Bradner, S. and V. Paxson,
"IETF Criteria for Evaluating Reliable Multicast
Transport and Application Protocols", RFC2357, June
1998.
[RSVP] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC2210, September 1997.
[RTP API] H. Schulzrinne, et al, "RTP Library API Specification,"
http://www.cs.columbia.edu/IRT/software/rtplib/rtplib-
1.0a1/rtp_api.html
[RTP/RTCP] Schulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC1889, January 1996.
[SAP] Handley, M., Perkins, C. and E. Whelan, "Session
Announcement Protocol", RFC2974, October 2000.
[SDP] Handley, M., and V. Jacobson, "SDP: Session Description
Protocol", RFC2327, April 1998.
[Schneier] B. Schneier, "Why Cryptography Is Harder Than It Looks",
December 1996, http://www.counterpane.com/whycrypto.html
[SlowStart] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC2001,
January 1997.
[SLP] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan,
"Service Location Protocol", RFC2165, June 1997.
[SSM] Holbrook, H. and B. Cain, "Specific Multicast for IP",
Work in Progress.
10. Authors' Addresses
Bob Quinn
Celox Networks
2 Park Central Drive
Southborough, MA 01772
Phone: +1 508 305 7000
EMail: bquinn@celoxnetworks.com
Kevin Almeroth
Department of Computer Science
University of California
Santa Barbara, CA 93106-5110
Phone: +1 805 893 2777
EMail: almeroth@cs.ucsb.edu
11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.