--- 1/draft-ietf-mboned-mcast-apps-00.txt 2006-02-05 00:20:08.000000000 +0100 +++ 2/draft-ietf-mboned-mcast-apps-01.txt 2006-02-05 00:20:08.000000000 +0100 @@ -1,21 +1,20 @@ - MBoneD Working Group Bob Quinn Internet Engineering Task Force Stardust Forums INTERNET-DRAFT Kevin Almeroth -26 February 1999 UCSB -Expires August 1999 +25 June 1999 UCSB +Expires December 1999 IP Multicast Applications: Challenges and Solutions - + Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -50,68 +49,68 @@ Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Focus and Scope. . . . . . . . . . . . . . . . . . . . . 4 2. IP Multicast-enabled Network. . . . . . . . . . . . . . . . 4 2.1 Essential Protocol Components. . . . . . . . . . . . . . 5 - 2.11 Expedient Joins and Leaves. . . . . . . . . . . . . . 5 - 2.12 Send without a Join . . . . . . . . . . . . . . . . . 6 + 2.1.1 Expedient Joins and Leaves . . . . . . . . . . . . . 5 + 2.1.2 Send without a Join. . . . . . . . . . . . . . . . . 6 3. IP Multicast Application Taxonomy . . . . . . . . . . . . . 6 3.1 One-to-Many Applications . . . . . . . . . . . . . . . . 8 3.2 Many-to-Many Applications. . . . . . . . . . . . . . . . 9 3.3 Many-to-One Applications . . . . . . . . . . . . . . . . 10 4. Common Multicast Service Requirements . . . . . . . . . . . 12 4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . 12 - 4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . 12 + 4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . 13 - 5. Unique Multicast Service Requirements . . . . . . . . . . . 13 + 5. Unique Multicast Service Requirements . . . . . . . . . . . 14 5.1 Address Management . . . . . . . . . . . . . . . . . . . 15 - 5.11 Scope Discovery . . . . . . . . . . . . . . . . . . . 15 + 5.1.1 Scope Discovery . . . . . . . . . . . . . . . . . . 16 5.2 Session Management . . . . . . . . . . . . . . . . . . . 16 - 5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . 16 - 5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . 18 + 5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . 17 + 5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . 19 5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . 20 - 5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . 21 + 5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . 22 6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 23 9. References. . . . . . . . . . . . . . . . . . . . . . . . . 23 - 10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 25 + 10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 26 - 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . 26 + 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . 27 1. Introduction IP Multicast will play a prominent role on the Internet in the coming years. It is a requirement, not an option, if the Internet is going to scale. Multicast allows application developers "to add more functionality without significantly impacting the network" [Bradner]. Developing multicast-enabled applications is ostensibly simple. Having datagram access allows any application to send to a multicast address. A multicast application need only increase the Internet Protocol (IP) time-to-live (TTL) value to more than 1 (the default value) to allow outgoing datagrams to traverse routers. To receive a multicast datagram, applications join the multicast group, which - transparently generates an IGMP [IGMPV2] group membership report. + transparently generates an [IGMPV2] group membership report. This apparent simplicity is deceptive, however. Enabling multicast support in applications and protocols that can scale well on a heterogeneous network is a significant challenge. Specifically, sending constant bit rate datastreams, reliable data delivery, security, and managing many-to-many communications all require special consideration. Some solutions are available, but many of these services are still active research areas. 1.1 Motivation @@ -142,21 +141,21 @@ Our initial premise is that the multicast infrastructure is transparent to applications, so it is not directly relevant to this discussion. Our focus here is on multicast application protocol services, so this document explicitly avoids any discussion of multicast routing issues. We identify and describe the multicast- specific issues involved with developing applications. We assume the reader has a general understanding of the mechanics of multicast, and in this respect we intend to compliment other - introductory documents [Maufer, Maufer2, Miller]. Since this is an + introductory documents [Maufer, Miller]. Since this is an introductory survey rather than a comprehensive examination, we refer readers to other multicast application requirements descriptions [LSMA, Miller] for more detail. In the remainder of this document we first define the term "IP multicast enabled network," the multicast infrastructure and essential multicast services. Next we describe the types of new functionality that multicast applications can enable and their requirements. We then examine the services that satisfy these requirements, the challenges they present, and provide a brief @@ -203,21 +202,21 @@ Ideally, these protocol components are transparent to multicast applications. However, there are two aspects of their functionality requirements that are worth mentioning specifically, since they affect application performance and design. These are the multicast application requirements for: - Expedient Joins and Leaves - Sends without a Join -2.11 Expedient Joins and Leaves +2.1.1 Expedient Joins and Leaves Some applications require expedient group joins and leaves, as their usability or functionality are sensitive to the latency involved with joining and leaving a group. Join Latency: The time it takes for data to begin flowing after an application issues a command to join a multicast group Leave Latency: The time it takes for data to stop flowing after an application issues a command to leave a multicast group @@ -230,26 +229,29 @@ a user requirement than an application requirement. The functionality of distributed interactive simulations [DIS] is often sensitive to join/leave latency. This is particularly true when trying to exchange information to represent fast moving objects that quickly enter and exit the scope of a simulated environment (e.g. low-flying, fast-moving aircraft). If the join latency is too long, the information provided may be old by the time it is received. + A fast leave phase is highly desirable both for effective congestion + control mechanisms, to stop undesirable flows quickly, and for the + network in general, to better filter unwanted traffic [Rizzo]. Applications cannot affect control over either join or leave latency, but are dependent on the multicast infrastructure to enable expedient operations. This is a basic multicast service requirement. -2.12 Sends without a Join +2.1.2 Sends without a Join Applications that send to a multicast address should be able to start sending immediately, without having to join the destination group first. This is important for embedded devices and bursty- source applications with low-delay delivery requirements. The current IGMP-based multicast host model and all current implementations allow senders to send to a group without joining it as a standard feature. @@ -439,42 +442,63 @@ n) Jam Sessions: Shared encoded audio (e.g. music). The bandwidth demands vary based on the encoding technique, sample rate, sample resolution, number of channels, etc. 3.3 Many-to-One Applications Unlike the one-to-many and many-to-many application categories, the many-to-one (Mto1) category does not represent a communications mechanism at the IP layer. Mto1 applications have multiple senders - and a single receiver, as defined by the application layer. Table 1 - shows that Mto1 applications can be one-way or use a two-way - request/response type protocol, where either senders or receivers + and one (or a few) receiver(s), as defined by the application layer. + Table 1 shows that Mto1 applications can be one-way or use a two-way + request/response type protocol, where either senders or receiver(s) may generate the request. Figure 2 characterizes the I/O relationship possibilities in Mto1 applications: 1) S1 2) S1 3) S1 4) S1 \ \ \ \ S2-R S2-R S2-R S2-R .../ .../ .../ .../ Sn Sn Sn Sn Data(m) Request(m) Request(m) Request(u) ------> ----------> <---------- ----------> Response(u) Response(u) Response(m) <----------- -----------> <---------- Figure 2: Characterization of Mto1 I/O possibilities - Receivers in Mto1 applications have scaling issues. Too many - simultaneous senders can potentially overwhelm a receiver. In other - words, they may have an "implosion problem." + Mto1 applications have many scaling issues. Too many simultaneous + senders can potentially overwhelm receiver(s), a condition + characterized as an "implosion problem." Another considerable + scaling problem is the large amount of state in the network that + having many multicast senders generates. This is largely + transparent to applications and the effect may be diminished in the + future with the use of bidirectional trees in multicast routing + protocols, but nonetheless it should be considered by application + designers. + + No standards yet exist for alternate and equivalent Mto1 application + designs, but there are a number of possibilities to consider [HNRS]. + Since the main advantage of using multicast in a Mto1 application is + that senders need not know the receiver(s) unicast address(es), one + alternative is for the each receiver to advertise its unicast + address via multicast. However, since this strategy still leaves + the potential for implosion on each receiver, additional strategies + may be needed to distribute the load. For example, it may be + possible to increase the number of receivers (in a "flat" receiver + topology) or establish localized receivers (in a "hierarchical" + topology) as used in "local recovery" (section 5.3). Such methods + have coordination issues, and although standard solutions have not + yet been identified, Mto1 application developers should consider + their alternatives carefully. o) Resource Discovery: Service Location, for example, leverages IP Multicast to enable something like a "host anycasting service" capability [AnyCast]: A multicast receiver to send a query to a group address, to elicit responses from the closest host so they can satisfy the request. The responses might also contain information that allows the receiver to determine the most appropriate (e.g. closest) service provider to use. In Table 1, this application is entry D4. It is also @@ -537,48 +560,47 @@ constant but each receiver sends less. 4. Common Multicast Service Requirements Some multicast application service requirements are common to unicast network applications as well. We characterize two of them here--bandwidth and delay requirements. 4.1 Bandwidth Requirements - Figure 2 shows multicast applications approximate bandwidth + Figure 3 shows multicast applications approximate bandwidth requirements. + Unicast and multicast applications both need to design applications + to adapt to the variability of network conditions. But as we + describe in section 4.1, it is the need to accommodate multiple + heterogeneous multicast receivers--with their diversity of bandwidth + capacity and delivery delays--that presents the unique challenge for + multicast applications to satisfy these requirements. + | 1toM | b, d c, e a | MtoM | k g, i f, h, j, l, m, n | - Mto1 | o, q, r p, q s + Mto1 | o, q, r p, q, t s | +----------------------------------------------- Low Bandwidth High Bandwidth Figure 3: Bandwidth Requirements of applications - Unicast and multicast applications both need to design applications - to adapt to the variability of network conditions. But as we - describe in section 4.1, it is the need to accommodate multiple - heterogeneous multicast receivers--with their diversity of bandwidth - capacity and delivery delays--that presents the unique challenge for - multicast applications to satisfy these requirements. - 4.2 Delay Requirements Aside from those with time-sensitive data (e.g. stock prices, and real-time monitoring information), most one-to-many applications have a high tolerance for delay and delay variance (jitter). - Constant bit-rate (CBR) data--such as streaming media (audio/video)- -are sensitive to jitter, but applications commonly counteract the effects by buffering data and delaying playback. Most many-to-one and many-to-many multicast applications are intolerant of delays because they are bidirectional, interactive and request/response dependent. As a result, delays should be minimized, since they can adversely affect the application's usability. @@ -578,47 +600,47 @@ Most many-to-one and many-to-many multicast applications are intolerant of delays because they are bidirectional, interactive and request/response dependent. As a result, delays should be minimized, since they can adversely affect the application's usability. This need to minimize delays is most evident in (two-way) conference applications, where users cannot converse effectively if the audio or video is delayed more than 500 milliseconds. For this and other - examples see Figure 3, which plots multicast applications on a + examples see Figure 4, which plots multicast applications on a (coarse) scale of sensitivity to delivery delays. | 1toM | b, c a, d e | MtoM | g, i, j, k f, h, l, m, n | - Mto1 | r o, p, s q + Mto1 | r o, p, s, t q | +----------------------------------------------- Delay Tolerant Delay Intolerant Figure 4: Delay tolerance of application types For delay-intolerant multicast (or unicast) applications, quality of service (QoS) is the only option. IP networks currently provide only "best effort" delivery, so data are subject to variable router queuing delays and loss due to network congestion (router queue overflows). IP QoS standards do exist now [RSVP] and efforts to - enable end-to-end QoS support in the Internet are underway - [DiffServ]. + enable end-to-end QoS support in the Internet are underway [E2EQOS]. - However, QoS support is an IP network infrastructure consideration - and relevant to unicast as well as multicast. Since our focus is on - multicast-specific application services, further discussion of the - QoS protocols and services is beyond the scope of this document. + However, QoS support is an IP network infrastructure consideration. + Although there are multicast-specific challenges for implementing + QoS in the network for multicast flows, they are beyond the control + of applications, so further discussion of the QoS protocols and + services is beyond the scope of this document. 5. Unique Multicast Service Requirements The three application categories described earlier are very general in nature. Within each category and even among each of the application types, specific application instances have a variety of application requirements. One-to-many application types are relatively simple to develop, but as we pointed out there are challenges involved with developing many-to-one and many-to-many applications. Some of these have requirements bandwidth and delay @@ -688,40 +711,46 @@ Hard-Coded: Software configuration, encoded in a binary executable, or burned into ROM in embedded devices. These applications typically reference IANA statically allocated multicast addresses (including relative addresses). Advertised: Session announcements (as described in the next section), or via another "out-of-band" query or discovery protocol mechanism. Algorithmically Derived: Using a programmatic algorithm to - statistically + allocate a statistically random (unused) address. | 1toM | c, e a, b d | MtoM | f, j, k, n g, h, i, l, m | - Mto1 | r o, p, s q + Mto1 | r o, p, s q, t | +----------------------------------------------- Hard-Coded Advertised Algorithmic Figure 6: Multicast address usage for application types -5.11 Scope Discovery +5.1.1 Scope Discovery Scope Discovery is a function of address management required by some - applications, to discover the scoped multicast addresses in use - [SADP]. This service assumes the use of Multicast Zone Announcement - Protocol [MZAP] as a back-end. + applications. An option for [MADCAP] allows clients to learn which + scopes nest inside each other, for the purpose of executing + expanding ring searches (among other things) [Kermode]. Scoped + Address Discovery Protocol [SADP] allows applications to discover + the administratively scoped multicast addresses already allocated to + a session within one or more administrative scopes in a hierarchy of + nested scopes. These protocols assume the use of Multicast Zone + Announcement Protocol [MZAP] as a _back-end_ (transparent to + applications), since it enables the creation of such hierarchies. 5.2 Session Management Multicast applications need a "namespace" that provides session directory services that can be used to co-ordinate application schedules and resources, and describe session attributes. These map multicast address and port combinations to a date and time, content description, and other session attributes (e.g. bandwidth and delay requirements, encoding, security and authorization methods, etc.). @@ -843,44 +872,46 @@ protocol design as the user experience. The adaptive mechanisms must also be stable, so they do not adapt too quickly--changing encoding and rates based on too little information about what may be a transient condition--to avoid oscillation. This "feedback loop" service necessary for support of heterogeneous receivers is not illustrated in the services summary in Figure 4, although it could be added alongside "Reliable Transport" and the others. This service could be implemented within an application or accessed externally, as provided by the operating system or a third - party. + party. See [HNRS] for a taxonomy of strategies for providing + feedback for multicast, with the ultimate goal of developing a + common multicast feedback protocol. 5.4 Reliable Data Delivery Many of the multicast application examples in our list--like audio/video distribution--have loss-tolerant data content. In other words, the data content itself can remain useful even if some of it is lost. For example, audio might have a short gap or lower fidelity but will remain legible despite some data loss. Other application examples--like caching and synchronized resources- -require reliable data delivery. They deliver content that must be complete, unchanged, in sequence, and without duplicates. The "Loss - Intolerant" column in Figure 5 shows a list of applications with + Intolerant" column in Figure 7 shows a list of applications with this requirement, while the others can tolerate varying levels of data loss. The tolerance levels are typically determined by the nature of the data and the encoding in use. | 1toM | b a, d c, e | MtoM | f, j, k, l, m, n g, h, i | - Mto1 | o, p, r, s q + Mto1 | o, p, r, s, t q | +------------------------------------------------ Loss Tolerant Loss Intolerant Figure 7: Reliability Requirements of Application types Some of the challenges involved with enabling reliable multicast transport are the same as those of sending to heterogeneous receivers, and some solutions are similar also. For example, many reliable multicast transport protocols avoid the implosion problem @@ -893,21 +924,24 @@ Although reliable delivery cannot change the data sent--except, perhaps, to use a loss-less data compression algorithm--they can use other adaptive techniques like sending redundant data, or adjusting the send rate. Although many reliable multicast protocol implementations exist [Obraczka], and a few are already available in commercial products, none of them are standardized. Work is ongoing in the "Reliable Multicast" research group of the Internet Research Task Force [IRTF] to provide a better definition of the problem, the multicast - transport requirements, and protocol mechanisms. + transport requirements, and protocol mechanisms. The IETF Relialbe + Multicast Transport (RMT) working group is focusing on designing + some working solutions in recognition of the urgent need for + scalable reliable multicast transport [RMT BLOCKS, RMT DESIGN]. Scalability is the paramount concern, and it implies the general need for "network friendly" protocols that detect and avoid congestion as they provide reliable delivery. Other considerations are protocol robustness, support for "late joins", group management and security (which we discuss next). The current consensus is that due to the wide variety of multicast application requirements--some of which are at odds--no single multicast transport will likely be appropriate for all applications. @@ -1057,110 +1089,130 @@ APIs by exposing different levels of detail in trade-offs between flexibility and simplicity. 7. Security Considerations See section 4.4 8. Acknowledgements The author would like to acknowledge and thank the following - individuals for their helpful feedback: Kevin Almeroth, Ran Canetti, - Brian Haberman, Eric A. Hall, Kenneth C. Miller, and Dave Thaler. + individuals for their helpful feedback: Ran Canetti, Brian Haberman, + Eric A. Hall, Kenneth C. Miller, and Dave Thaler. 9. References [AnyCast] C. Partridge, T. Mendez, W. Milliken, "Host Anycasting Service", RFC 1546, November 1993 [Bradner] S. Bradner, "Internet Protocol Multicast Problem Statement", , September 1997, Work in Progress - [Canetti] R. Canetti, B. Pinkas, "A taxonomy of multicast security - issues(temporary version)", , May 1998, Work in Progress + issues", , April 1999, + Work in Progress [Chouinard] D. Chouinard, "SOCKS V5 UDP and Multicast Extensions to Facilitate Multicast Firewall Traversal", , Nov 1997, Work in + aft-mcast-fw-traversal-01.txt>, November 1997, Work in Progress - [DiffServ] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K. - Nichols, and M. Speer, "A Framework for Use of RSVP with - Diff-serv Networks", Internet Draft , November 1998, Work in Progress + [E2EQOS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, + M. Speer, R. Braden, B. Davie, "Integrated Services + Operation over Diffserv Networks", , June 1999, Work in Progress [DIS] J.M.Pullen, M. Mytak, C. Bouwens, "Limitations of Internet Protocol Suite for Distributed Simulation in the Large Multicast Environment", RFC 2502, February 1999 [Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech Earthlink Seminar Series, April 22, 1998 - [Finlayson] R. Finlayson, "IP Multicast and Firewalls", , November 1998, Work in - Progress + [Finlayson] R. Finlayson, "IP Multicast and Firewalls", RFC 2588, + May 1999 + + [HNRS] Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy + of Feedback for Multicast", June 1999, Work in Progress [IGMPv2] B. Fenner, "Internet Group Management Protocol, Version 2", RFC 2236, November 1997 [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] A Weinrib, J. Postel, "The IRTF Guidelines and Procedures", RFC 2014, January 1996 + [Kermode] R. Kermode, "MADCAP Multicast Scope Nesting State + Option", February 1999, , Work in Progress + [LSMA] P. Bagnall, R. Briscoe, A. Poppitt, "Taxonomy of Communication Requirements, for Large-scale Multicast - Applications," , - November 1998, Work in Progress + Applications," , + May 1999, Work in Progress [MASC] D. Estrin, R. Govindan, M. Handley, S. Kumar, P. Radoslavov, D. Thaler, "The Multicast Address-Set Claim (MASC) Protocol", , August 1998, Work in Progress - [Maufer] T. Maufer, C. Semeria, "Introduction to IP Multicast - Routing," , - July 1997, Work in Progress - - [Maufer2] T. Maufer, "Deploying IP Multicast in the Enterprise", + [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] B. V. Patel, M. Shah, S. R. Hanna, " Multicast Address Dynamic Client Allocation Protocol (MADCAP)", , February 1999, Work in Progress [MIX] H. Lamaster, S. Shultz, J. Meylor, D. Meyer, "Multicast- - Friendly Internet Exchange (MIX)," , Dec 1998, Work in Progress + [MZAP] M. Handley, D. Thaler, R. Kermode, "Multicast-Scope Zone + Announcement Protocol (MZAP) ", , Feb 1999, Work in Progress + [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] A. Mankin, A. Romanow, S. Bradner, V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998 + [RM BLOCKS] B. Whetten, L. Vicisano, R. Kermode, M. Handley, + S. Floyd, "Reliable Multicast Transport Building Blocks + for One-to-Many Bulk-Data Transfer", , June 1999, Work in Progress + + [RM DESIGN] M. Handley, B. Whetten, R. Kermode, S. Floyd, + L. Vicisano, "The Reliable Multicast Design Space for + Bulk Data Transfer", + June 1999, Work in Progress + [RSVP] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997 + [RTP API] J. Rosenberg, "Columbia RTP Library API Specification," (Note: Does not include RTCP processing), February 1997 [RTP/RTCP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996 [SAP] M. Handley, "SAP: Session Announcement Protocol", , November 1996, Work in Progress @@ -1157,24 +1209,28 @@ [RTP API] J. Rosenberg, "Columbia RTP Library API Specification," (Note: Does not include RTCP processing), February 1997 [RTP/RTCP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996 [SAP] M. Handley, "SAP: Session Announcement Protocol", , November 1996, Work in Progress + [SADP] R. Kermode, D. Thaler, "Scoped Address Discovery Protocol + (SADP) ", , Jan 1999, Work + in Progress + [SDP] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998 - [Schneier] B. Schneier, _ Why Cryptography Is Harder Than It Looks", + [Schneier] B. Schneier, "Why Cryptography Is Harder Than It Looks", December 1996, http://www.counterpane.com/whycrypto.html [SlowStart] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997 [SLP] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, "Service Location Protocol", RFC 2165, June 1997 10. Authors' Addresses