idnits 2.17.1 draft-ietf-mboned-mcast-apps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1999) is 9019 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IGMPV2' is mentioned on line 106, but not defined == Missing Reference: 'SADP' is mentioned on line 717, but not defined == Missing Reference: 'MZAP' is mentioned on line 718, but not defined == Unused Reference: 'MASC' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: 'MADCAP' is defined on line 1139, but no explicit reference was found in the text == Unused Reference: 'RM' is defined on line 1152, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. 'AnyCast') -- Possible downref: Non-RFC (?) normative reference: ref. 'Bradner' -- Possible downref: Non-RFC (?) normative reference: ref. 'Canetti' -- Possible downref: Non-RFC (?) normative reference: ref. 'Chouinard' -- Possible downref: Non-RFC (?) normative reference: ref. 'DiffServ' ** Downref: Normative reference to an Informational RFC: RFC 2502 (ref. 'DIS') -- Possible downref: Non-RFC (?) normative reference: ref. 'Estrin' -- Possible downref: Non-RFC (?) normative reference: ref. 'Finlayson' -- Possible downref: Non-RFC (?) normative reference: ref. 'IMJ' -- Possible downref: Non-RFC (?) normative reference: ref. 'LSMA' -- Possible downref: Non-RFC (?) normative reference: ref. 'MASC' -- Possible downref: Non-RFC (?) normative reference: ref. 'Maufer' -- Possible downref: Non-RFC (?) normative reference: ref. 'Maufer2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Miller' -- Possible downref: Non-RFC (?) normative reference: ref. 'MADCAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIX' -- Possible downref: Non-RFC (?) normative reference: ref. 'Obraczka' ** Downref: Normative reference to an Informational RFC: RFC 2357 (ref. 'RM') -- Possible downref: Non-RFC (?) normative reference: ref. 'RTP API' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAP' ** Obsolete normative reference: RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' ** Obsolete normative reference: RFC 2001 (ref. 'SlowStart') (Obsoleted by RFC 2581) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBoneD Working Group Bob Quinn 2 Internet Engineering Task Force Stardust Forums 3 INTERNET-DRAFT Kevin Almeroth 4 26 February 1999 UCSB 5 Expires August 1999 7 IP Multicast Applications: 8 Challenges and Solutions 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes the challenges involved with designing and 37 implementing multicast applications. It is an introductory guide 38 for application developers that highlights the unique considerations 39 of multicast applications as compared to unicast applications. 41 To this end, the document presents a taxonomy of multicast 42 application I/O models and examples of the services they can 43 support. It then describes the service requirements of these 44 multicast applications, and the recent and ongoing efforts to build 45 protocol solutions to support these services. 47 Copyright (C) The Internet Society (1999). All Rights Reserved. 49 Table of Contents 51 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 53 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2 Focus and Scope. . . . . . . . . . . . . . . . . . . . . 4 57 2. IP Multicast-enabled Network. . . . . . . . . . . . . . . . 4 58 2.1 Essential Protocol Components. . . . . . . . . . . . . . 5 59 2.11 Expedient Joins and Leaves. . . . . . . . . . . . . . 5 60 2.12 Send without a Join . . . . . . . . . . . . . . . . . 6 62 3. IP Multicast Application Taxonomy . . . . . . . . . . . . . 6 63 3.1 One-to-Many Applications . . . . . . . . . . . . . . . . 8 64 3.2 Many-to-Many Applications. . . . . . . . . . . . . . . . 9 65 3.3 Many-to-One Applications . . . . . . . . . . . . . . . . 10 67 4. Common Multicast Service Requirements . . . . . . . . . . . 12 68 4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . 12 69 4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . 12 71 5. Unique Multicast Service Requirements . . . . . . . . . . . 13 72 5.1 Address Management . . . . . . . . . . . . . . . . . . . 15 73 5.11 Scope Discovery . . . . . . . . . . . . . . . . . . . 15 74 5.2 Session Management . . . . . . . . . . . . . . . . . . . 16 75 5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . 16 76 5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . 18 77 5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . 20 78 5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . 21 80 6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . 22 82 7. Security Considerations . . . . . . . . . . . . . . . . . . 23 84 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 23 86 9. References. . . . . . . . . . . . . . . . . . . . . . . . . 23 88 10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 25 90 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . 26 92 1. Introduction 94 IP Multicast will play a prominent role on the Internet in the 95 coming years. It is a requirement, not an option, if the Internet 96 is going to scale. Multicast allows application developers "to add 97 more functionality without significantly impacting the network" 98 [Bradner]. 100 Developing multicast-enabled applications is ostensibly simple. 101 Having datagram access allows any application to send to a multicast 102 address. A multicast application need only increase the Internet 103 Protocol (IP) time-to-live (TTL) value to more than 1 (the default 104 value) to allow outgoing datagrams to traverse routers. To receive 105 a multicast datagram, applications join the multicast group, which 106 transparently generates an IGMP [IGMPV2] group membership report. 108 This apparent simplicity is deceptive, however. Enabling multicast 109 support in applications and protocols that can scale well on a 110 heterogeneous network is a significant challenge. Specifically, 111 sending constant bit rate datastreams, reliable data delivery, 112 security, and managing many-to-many communications all require 113 special consideration. Some solutions are available, but many of 114 these services are still active research areas. 116 1.1 Motivation 118 The purpose of this document is to provide a framework for 119 understanding the challenges of designing and implementing multicast 120 applications. In order to use multicast communications correctly, 121 application developers must first understand the various I/O models 122 and the network services (in addition to basic multicast 123 communication) that are required. Secondly, application developers 124 need to be aware of efforts underway to provide these services. 125 Such efforts range in maturity from deployed commercial products to 126 basic research efforts to evaluate feasibility. 128 Multicast-based applications and services will play an important 129 role in the future of the Internet as continued multicast deployment 130 encourages their use and development. It is important that 131 developers be aware of the issues and solutions available--and 132 especially of their limitations--in order to avoid protocols that 133 negatively impact networks (thereby counter-acting the benefits of 134 multicast) or wasting their efforts "re-inventing the wheel." 136 The hope is that by raising developers' awareness, we can adjust 137 their expectations of finding solutions and lead them to successful, 138 scalable, and "network-friendly" development efforts. 140 1.2 Focus and Scope 142 Our initial premise is that the multicast infrastructure is 143 transparent to applications, so it is not directly relevant to this 144 discussion. Our focus here is on multicast application protocol 145 services, so this document explicitly avoids any discussion of 146 multicast routing issues. We identify and describe the multicast- 147 specific issues involved with developing applications. 149 We assume the reader has a general understanding of the mechanics of 150 multicast, and in this respect we intend to compliment other 151 introductory documents [Maufer, Maufer2, Miller]. Since this is an 152 introductory survey rather than a comprehensive examination, we 153 refer readers to other multicast application requirements 154 descriptions [LSMA, Miller] for more detail. 156 In the remainder of this document we first define the term "IP 157 multicast enabled network," the multicast infrastructure and 158 essential multicast services. Next we describe the types of new 159 functionality that multicast applications can enable and their 160 requirements. We then examine the services that satisfy these 161 requirements, the challenges they present, and provide a brief 162 survey of the solutions available or under development. We wrap up 163 with a discussion of application programming interfaces (APIs) for 164 multicast services. 166 2. IP Multicast Enabled Network 168 An "IP multicast-enabled network" provides end-to-end services in 169 the IP network infrastructure to allow any IP host to send datagrams 170 to an IP multicast address that any number of other IP hosts widely 171 dispersed can receive. 173 At the time of this writing end-to-end "global" multicast service is 174 not yet available, but the size of the "multicast-enabled" Internet 175 is growing. Recent development and deployment of interdomain 176 multicast routing protocols and multicast-friendly Internet 177 exchanges [MIX] have enabled peering between major ISPs. This, 178 along with the increasing availability of compelling content, is 179 spurring deployment and availability of the IP Multicast Enabled 180 Network. 182 In the remainder of this document we assume that the multicast- 183 enabled network is already ubiquitous. Since such a large and 184 growing portion of the global Internet is IP multicast-enabled now, 185 and many enterprise networks (intranets) are also, this perspective 186 is relevant today. 188 2.1 Essential Protocol Components 190 An IP multicast enabled network requires two essential protocol 191 components: 193 1) An IP host-based protocol to allow a receiver application to 194 notify a local router(s) that it has joined the group, and 195 initiate the data flow from all sender(s) within the scope 197 2) An IP router-based protocol to allow any routers with multicast 198 group members (receivers) on their local networks to 199 communicate with other routers to ensure that all datagrams 200 sent to the group address are forwarded to all receivers within 201 the intended scope 203 Ideally, these protocol components are transparent to multicast 204 applications. However, there are two aspects of their functionality 205 requirements that are worth mentioning specifically, since they 206 affect application performance and design. These are the multicast 207 application requirements for: 209 - Expedient Joins and Leaves 210 - Sends without a Join 212 2.11 Expedient Joins and Leaves 214 Some applications require expedient group joins and leaves, as their 215 usability or functionality are sensitive to the latency involved 216 with joining and leaving a group. 218 Join Latency: The time it takes for data to begin flowing after an 219 application issues a command to join a multicast group 221 Leave Latency: The time it takes for data to stop flowing after an 222 application issues a command to leave a multicast group 223 [IGMPv2] 225 For example, using distributed a/v as a multicast-based "television" 226 must allow users to "channel surf"--changing channels frequently. 227 Each channel change generates a group leave and group join, so 228 delays in either will affect usability. In a sense, this is more of 229 a user requirement than an application requirement. 231 The functionality of distributed interactive simulations [DIS] is 232 often sensitive to join/leave latency. This is particularly true 233 when trying to exchange information to represent fast moving objects 234 that quickly enter and exit the scope of a simulated environment 235 (e.g. low-flying, fast-moving aircraft). If the join latency is too 236 long, the information provided may be old by the time it is 237 received. 239 Applications cannot affect control over either join or leave 240 latency, but are dependent on the multicast infrastructure to enable 241 expedient operations. This is a basic multicast service 242 requirement. 244 2.12 Sends without a Join 246 Applications that send to a multicast address should be able to 247 start sending immediately, without having to join the destination 248 group first. This is important for embedded devices and bursty- 249 source applications with low-delay delivery requirements. 251 The current IGMP-based multicast host model and all current 252 implementations allow senders to send to a group without joining it 253 as a standard feature. 255 3. IP Multicast Application Taxonomy 257 With an IP multicast-enabled network available, some unique and 258 powerful applications and application services are possible. 259 "Multicast enables coordination - it is well suited to loosely 260 coupled distributed systems (of people, servers, databases, 261 processes, devices...)" [Estrin]. 263 A "multicast application" is simply defined as any application that 264 sends to and/or receives from an IP multicast address. These may or 265 may not also reference IP unicast addresses, as we describe later. 267 What differentiates IP multicast applications from one-to-one 268 unicast applications are the other sender and receiver relationships 269 multicast enables. There are three general categories of multicast 270 applications: 272 One-to-Many (1toM): A single host sending to two or more (n) 273 receivers 275 Many-to-Many (MtoM): Any number of hosts sending to the same 276 multicast group address, as well as receiving from it 278 Many-to-One (Mto1): Any number of receivers sending data back to a 279 (source) sender via unicast or multicast 280 +-----------------------------------+ 281 | Host 2->n ("many") | 282 +-------------+---------------------+ 283 | One-Way | Two-Way | 284 +-------------+---------------------| 285 | A B | C D E | 286 +-----------+-------------+---------------------+ 287 | I/O | | S(m)/ S(u)/ S(m)/| 288 | Operations| S(m) R(m) | R(m) R(m) R(u) | 289 +-------+---+-----------+-------------+---------------------| 290 | | 1 | S(m) | 1toM | MtoM | 291 | Host | 2 | R(m) | Mto1 | MtoM | 292 | +---+-----------+-------------+ | 293 | 1 | 3 | S(m)/R(m) | Mto1 1toM MtoM | 294 | | 4 | S(m)/R(u) | Mto1 | 295 |("one")| 5 | S(u)/R(m) | Mto1 | 296 +-------+---+-----------+-----------------------------------+ 298 Legend: S: "Send" (u): "unicast" 299 ------ R: "Receive" (m): "multicast" 301 Table 1: Application types characterized by I/O relationships 302 and destination address types (multicast or unicast) 304 Table 1 defines these application types in terms of the I/O 305 relationships they represent. These categories are defined in terms 306 of the combination of communication mechanisms they use. At the IP 307 level, all multicast I/O is only 1toM or MtoM and unicast is always 308 one-to-one (1to1). The Mto1 category, for example, refers to 309 several possible combinations of IP-level relationships, including 310 unicast. We created the Mto1 category to help differentiate between 311 the many applications and services that use multicast. 313 1toM: MtoM: Mto1: 314 R1 S1/R1 S1 315 / / | \ \ 316 S-R2 S2/R2-+-S3/R3 S2-R 317 \... \ | / .../ 318 Rn Sn/Rn Sn 320 Legend: S: "Sender" 321 ------ R: "Receiver" 323 Figure 1: Generalization of the three application categories 325 Figure 1 illustrates the general model for each of the three 326 multicast application categories. Again it is worth emphasizing 327 that Mto1 is an artificial category defined by the application-level 328 relationship between sender(s) and receiver. At the IP-level, 329 multicast does not provide an Mto1 I/O mechanism, since it does not 330 allow senders to limit receivers, nor even know who they are. 331 Receiver information and limitations are enabled at the application 332 level, as required by the multicast application. 334 We describe each of these general application types in more detail 335 and provide application examples of each in the sub-sections below. 336 The list of examples is not comprehensive, but attempts to define 337 the prominent multicast application and service types in each of the 338 three general categories. We reference the items in these lists in 339 the remainder of this document as we describe their specific service 340 requirements, define the challenges they present, and reference 341 solutions available or under development. 343 3.1 One-to-Many Applications 345 One-to-Many (1toM) applications have a single sender, and multiple 346 simultaneous receivers. Entry B1 in Table 1 represents the classic 347 1toM relationship. Entry B3 differs only slightly, as the sender 348 also acts as receiver (i.e. it has loopback enabled). 350 When people think of multicast, they most often think of broadcast- 351 based multimedia applications: television (video) and radio (audio). 352 This is a reasonable analogy and indeed these are significant 353 multicast applications, but these are far from the extent of 354 applications that multicast can enable. Audio/Video distribution 355 represents a fraction of the multicast application possibilities, 356 and most do not have analogs in today's consumer broadcast industry. 358 a) Scheduled audio/video (a/v) distribution: Lectures, 359 presentations, meetings, or any other type of scheduled event 360 whose multimedia coverage could benefit an audience (i.e. 361 television and radio "broadcasts"). One or more constant-bit- 362 rate (CBR) datastreams and relatively high-bandwidth demands 363 characterize these applications. When more than one datastream 364 is present--as with an audio/video combination--the two are 365 synchronized and one typically has a higher priority than the 366 other(s). For example, in an a/v combination it is more 367 important to ensure a legible audio stream, than perfect video. 369 b) Push media: News headlines, weather updates, sports scores, or 370 other types of non-essential dynamic information. "Drip-feed," 371 relatively low-bandwidth data characterize these applications. 373 c) File Distribution and Caching: Web site content, executable 374 binaries, and other file-based updates sent to distributed end- 375 user or replication/caching sites 377 d) Announcements: Network time, multicast session schedules, 378 random numbers, keys, configuration updates, (scoped) network 379 locality beacons, or other types of information that are 380 commonly useful. Their bandwidth demands can vary, but 381 generally they are very low bandwidth. 383 e) Monitoring: Stock prices, Sensor equipment (seismic activity, 384 telemetry, meteorological or oceanic readings), security 385 systems, manufacturing or other types of real-time information. 386 Bandwidth demands vary with sample frequency and resolution, 387 and may be either constant-bit-rate or bursty (if event- 388 driven). 390 3.2 Many-to-Many Applications 392 In many-to-Many (MtoM) applications two or more of the receivers 393 also act as senders. In other words, MtoM applications are 394 characterized by two-way multicast communications. 396 The many-to-many capabilities of IP multicast enable the most unique 397 and powerful applications. Each host running an MtoM application 398 may receive data from multiple senders while it also sends data to 399 all of them. As a result, many-to-many applications often present 400 complex coordination and management challenges. 402 f) Multimedia Conferencing: Audio/Video and whiteboard comprise 403 the classic conference application. Having multiple 404 datastreams with different priorities characterizes this type 405 of application. Co-ordination issues--such as determining who 406 gets to talk when--complicate their development and usability. 407 There are common heuristics and "rules of play", but no 408 standards exist for managing conference group dynamics. 410 g) Synchronized Resources: Shared distributed databases of any 411 type (schedules, directories, as well as traditional 412 Information System databases). 414 h) Concurrent Processing: Distributed parallel processing. 416 i) Collaboration: Shared document editing. 418 j) Distance Learning: This is a one-to-many a/v distribution 419 application with "upstream" capability that allows receivers to 420 question the speaker(s). 422 k) Chat Groups: These are like text-based conferences, but may 423 also provide simulated representations ("avatars") for each 424 "speaker" in simulated environments. 426 l) Distributed Interactive Simulations [DIS]: Each object in a 427 simulation multicasts descriptive information (e.g. telemetry) 428 so all other objects can render the object, and interact as 429 necessary. The bandwidth demands for these can be tremendous, 430 as the number of objects and the resolution of descriptive 431 information increases. 433 m) Multi-player Games: Many multi-player games are simply 434 distributed interactive simulations, and may include chat group 435 capabilities. Bandwidth usage can vary widely, although 436 today's first-generation multi-player games attempt to minimize 437 bandwidth usage to increase the target audience (many of whom 438 still use dial-up modems). 440 n) Jam Sessions: Shared encoded audio (e.g. music). The bandwidth 441 demands vary based on the encoding technique, sample rate, 442 sample resolution, number of channels, etc. 444 3.3 Many-to-One Applications 446 Unlike the one-to-many and many-to-many application categories, the 447 many-to-one (Mto1) category does not represent a communications 448 mechanism at the IP layer. Mto1 applications have multiple senders 449 and a single receiver, as defined by the application layer. Table 1 450 shows that Mto1 applications can be one-way or use a two-way 451 request/response type protocol, where either senders or receivers 452 may generate the request. Figure 2 characterizes the I/O 453 relationship possibilities in Mto1 applications: 455 1) S1 2) S1 3) S1 4) S1 456 \ \ \ \ 457 S2-R S2-R S2-R S2-R 458 .../ .../ .../ .../ 459 Sn Sn Sn Sn 461 Data(m) Request(m) Request(m) Request(u) 462 ------> ----------> <---------- ----------> 463 Response(u) Response(u) Response(m) 464 <----------- -----------> <---------- 466 Figure 2: Characterization of Mto1 I/O possibilities 468 Receivers in Mto1 applications have scaling issues. Too many 469 simultaneous senders can potentially overwhelm a receiver. In other 470 words, they may have an "implosion problem." 472 o) Resource Discovery: Service Location, for example, leverages IP 473 Multicast to enable something like a "host anycasting service" 474 capability [AnyCast]: A multicast receiver to send a query to a 475 group address, to elicit responses from the closest host so 476 they can satisfy the request. The responses might also contain 477 information that allows the receiver to determine the most 478 appropriate (e.g. closest) service provider to use. 480 In Table 1, this application is entry D4. It is also 481 illustrated in Figure 2 by possibility number 3. Alternately, 482 the response could be to a multicast rather than unicast 483 address, although technically that would make it an MtoM 484 application type (this is how the . Service Location Protocol 485 [SLP] operates, when a user agent attempts to locate a 486 directory agent). 488 p) Data Collection: This is the converse of a one-to-many 489 "monitoring" application described earlier. In this case there 490 may be any number of distributed "sensors" that send data to a 491 data collection host. The sensors might send updates in 492 response to a request from the data collector, or send 493 continuously at regular intervals, or send spontaneously when a 494 pre-defined event occurs. Bandwidth demands can vary based on 495 sample frequency and resolution. 497 This is illustrated in Table 1 by entries A1 and A3, the only 498 difference being that A3 has a loopback interface. In Figure 499 2, this is possibility number 1. Since the number of receivers 500 can easily be more than one, this is really an MtoM 501 application. 503 q) Auctions: The "auctioneer" starts the bidding by describing 504 whatever it is for sale (product or service or whatever), and 505 receivers send their bids privately or publicly (i.e. to a 506 unicast or multicast address). 508 This is possibility number 2 in Figure 2, and D5 in Table 1. 509 The response could be sent to a multicast address, although 510 technically that would make it an MtoM application. 512 r) Polling: The "pollster" sends out a question, and the "pollees" 513 respond with answers. This is possibility number 2 in Figure 514 2, and could also be characterized as an MtoM application if 515 the response is to a multicast address. 517 s) Juke Box: Allows near-on-demand a/v playback. Receivers use an 518 "out-of-band" protocol mechanism (via web, email, unicast or 519 multicast requests, etc.) to send their playback request into a 520 scheduling queue [IMJ]. 522 This is characterized by possibility number 4 in Figure 2, and 523 entry D4 in Table 1. The initial unicast request is the only 524 difference between this type of application and a typical 1toM. 526 If that initial request were sent to a multicast address, this 527 would effectively be an MtoM application. 529 t) Accounting: This is basically data collection but is worth 530 separating since it is such an important application. In some 531 multicast applications it is imperative to know information 532 about each receiver, possibly in real-time. But such 533 information can be overwhelming. Current mechanisms, like RTCP 534 (which is actually MtoM since it is multicast but could be made 535 Mto1), use scaling techniques but trade-off information 536 granularity. As a group grows the total amount of feedback is 537 constant but each receiver sends less. 539 4. Common Multicast Service Requirements 541 Some multicast application service requirements are common to 542 unicast network applications as well. We characterize two of them 543 here--bandwidth and delay requirements. 545 4.1 Bandwidth Requirements 547 Figure 2 shows multicast applications approximate bandwidth 548 requirements. 550 | 551 1toM | b, d c, e a 552 | 553 MtoM | k g, i f, h, j, l, m, n 554 | 555 Mto1 | o, q, r p, q s 556 | 557 +----------------------------------------------- 558 Low Bandwidth High Bandwidth 560 Figure 3: Bandwidth Requirements of applications 562 Unicast and multicast applications both need to design applications 563 to adapt to the variability of network conditions. But as we 564 describe in section 4.1, it is the need to accommodate multiple 565 heterogeneous multicast receivers--with their diversity of bandwidth 566 capacity and delivery delays--that presents the unique challenge for 567 multicast applications to satisfy these requirements. 569 4.2 Delay Requirements 571 Aside from those with time-sensitive data (e.g. stock prices, and 572 real-time monitoring information), most one-to-many applications 573 have a high tolerance for delay and delay variance (jitter). 575 Constant bit-rate (CBR) data--such as streaming media (audio/video)- 576 -are sensitive to jitter, but applications commonly counteract the 577 effects by buffering data and delaying playback. 579 Most many-to-one and many-to-many multicast applications are 580 intolerant of delays because they are bidirectional, interactive and 581 request/response dependent. As a result, delays should be 582 minimized, since they can adversely affect the application's 583 usability. 585 This need to minimize delays is most evident in (two-way) conference 586 applications, where users cannot converse effectively if the audio 587 or video is delayed more than 500 milliseconds. For this and other 588 examples see Figure 3, which plots multicast applications on a 589 (coarse) scale of sensitivity to delivery delays. 591 | 592 1toM | b, c a, d e 593 | 594 MtoM | g, i, j, k f, h, l, m, n 595 | 596 Mto1 | r o, p, s q 597 | 598 +----------------------------------------------- 599 Delay Tolerant Delay Intolerant 601 Figure 4: Delay tolerance of application types 603 For delay-intolerant multicast (or unicast) applications, quality of 604 service (QoS) is the only option. IP networks currently provide 605 only "best effort" delivery, so data are subject to variable router 606 queuing delays and loss due to network congestion (router queue 607 overflows). IP QoS standards do exist now [RSVP] and efforts to 608 enable end-to-end QoS support in the Internet are underway 609 [DiffServ]. 611 However, QoS support is an IP network infrastructure consideration 612 and relevant to unicast as well as multicast. Since our focus is on 613 multicast-specific application services, further discussion of the 614 QoS protocols and services is beyond the scope of this document. 616 5. Unique Multicast Service Requirements 618 The three application categories described earlier are very general 619 in nature. Within each category and even among each of the 620 application types, specific application instances have a variety of 621 application requirements. One-to-many application types are 622 relatively simple to develop, but as we pointed out there are 623 challenges involved with developing many-to-one and many-to-many 624 applications. Some of these have requirements bandwidth and delay 625 requirements, similar to unicast applications. 627 Multicast applications can be further differentiated from unicast 628 applications and from each other by the services they require. In 629 this section we provide a survey of the various services that have 630 unique requirements for multicast applications. 632 +------------------------------------------------------+ 633 | Multicast Application | 634 +--------------------------------------+ +-----------+ 635 +-------------------------------------+| |+----++----+ 636 | Multicast Security || || || | 637 +----------------------+ +----------+| ||Sys-||Co- | 638 +----------++---------+| |+---------+| ||tem ||decs| 639 | Reliable || Address || || Session || ||Time|| | 640 | Delivery || Mgmnt. || || Mgmnt. || || || | 641 +----------++---------++---++---------++---++----++----+ 642 +----------------------------------------++------------+ 643 | Basic IP Multicast Service || IP Unicast | 644 | (e.g. UDP and IGMPv2) || Service | 645 +----------------------------------------++------------+ 647 Figure 5: Multicast service requirements summary 649 Here's the list of multicast application service requirements: 651 Address Management - Coordinated address allocation service that 652 provides some assurances against "address collisions". 654 Session Management - Making session descriptions available (via 655 advertisements and explicit queries) within appropriate scopes, 656 and also enabling registration of new sessions 658 Heterogeneous Receiver Support - Sending to receivers with a wide 659 variety of bandwidth capacities, latency characteristics, and 660 network congestion requires feedback to monitor receiver 661 performance. 663 Reliable Data Delivery - Ensuring that all data sent is received 664 by all receivers 666 Security - Ensuring content privacy among dynamic multicast group 667 memberships, and limiting senders 669 Synchronized Play-Out - Allow multiple receivers to "replay" data 670 received in synchronized fashion 672 In the remainder of this section, we describe each of these 673 application services in more detail, the challenges they present, 674 and the status of standardized solutions. 676 5.1 Address Management 678 One of the first questions facing a multicast application developer 679 is what multicast address to use. Multicast addresses are not 680 assigned to individual hosts, assignments can change dynamically, 681 and addresses sometimes have semantics of their own (e.g 682 Administrative Scoping). Multicast applications require an address 683 management service that provides address allocation or assignment 684 queries: 686 There are a number of ways for applications to learn about multicast 687 addresses: 689 Hard-Coded: Software configuration, encoded in a binary 690 executable, or burned into ROM in embedded devices. These 691 applications typically reference IANA statically allocated 692 multicast addresses (including relative addresses). 694 Advertised: Session announcements (as described in the next 695 section), or via another "out-of-band" query or discovery 696 protocol mechanism. 698 Algorithmically Derived: Using a programmatic algorithm to 699 statistically 701 | 702 1toM | c, e a, b d 703 | 704 MtoM | f, j, k, n g, h, i, l, m 705 | 706 Mto1 | r o, p, s q 707 | 708 +----------------------------------------------- 709 Hard-Coded Advertised Algorithmic 711 Figure 6: Multicast address usage for application types 713 5.11 Scope Discovery 715 Scope Discovery is a function of address management required by some 716 applications, to discover the scoped multicast addresses in use 717 [SADP]. This service assumes the use of Multicast Zone Announcement 718 Protocol [MZAP] as a back-end. 720 5.2 Session Management 722 Multicast applications need a "namespace" that provides session 723 directory services that can be used to co-ordinate application 724 schedules and resources, and describe session attributes. These map 725 multicast address and port combinations to a date and time, content 726 description, and other session attributes (e.g. bandwidth and delay 727 requirements, encoding, security and authorization methods, etc.). 729 The session description protocol [SDP] is designed for this purpose, 730 but it does not provide the transport for dissemination of these 731 session descriptions, nor does it enable the address allocation and 732 management. SDP only provides the syntax for describing session 733 attributes. 735 SDP session descriptions may be conveyed publicly or privately by 736 means of any number of transports including web (HTTP) and MIME 737 encoded email. The session announcement protocol [SAP] is the de 738 facto standard transport and many multicast-enabled applications 739 currently use it. SAP limits distribution via multicast scoping, 740 but the current protocol definition has scaling issues that need to 741 be addressed. Specifically, the initialization latency for a 742 session directory can be quite long, and it increases in proportion 743 to the number of session announcements. This is to an extent a 744 multicast infrastructure issue, however, as this level of protocol 745 detail should be transparent to applications. 747 The session management service needs to: 748 - Advertise scheduled sessions 749 - Provide a query mechanism for retrieving information about 750 session schedules 752 5.3 Heterogeneous Receiver Support 754 The Internet is a network of networks. IP's strength is its ability 755 to enable seamless interoperability between hosts on disparate 756 network media, the heterogeneous network. 758 When two hosts communicate via unicast--one-to-one--across an IP 759 network, it is relatively easy for senders to adapt to varying 760 network conditions. The Transmission Control Protocol (TCP) 761 provides reliable data transport, and is the model of "network 762 friendly" adaptability. 764 TCP receivers send acknowledgements back to the sender for data 765 delivered. A TCP sender detects data loss from the data sent that 766 is not acknowledged. When it detects data loss, TCP infers that 767 there is network congestion or a low-bandwidth link, and adapts by 768 throttling down its send rate [SlowStart]. 770 User Datagram Protocol (UDP) does not enable a receiver feedback 771 loop the way TCP does, since UDP does not provide reliable data 772 delivery service. As a result, it also does not have a loss 773 detection and adaptive congestion control mechanism as TCP does. 774 However, it is possible for a unicast UDP application to enable 775 similar adaptive algorithms to achieve the same result, or even 776 improve on it. 778 A unicast UDP application that uses a feedback mechanism to detect 779 data loss and adapt the send rate, can do so better than TCP. TCP 780 automatically reduces the "congestion window" when data loss is 781 detected, although the updated send rate may be slower than a CBR 782 audio/video stream requires. When a UDP application detects loss, 783 it can adapt the data itself to accommodate the lower send rate. 784 For example, a UDP application can: 786 - Reduce the data resolution (e.g. send lower fidelity 787 audio/video by reducing sample frequency or frame rate) to 788 reduce data rate. 790 - Modify the data encoding to add redundant data (e.g. forward 791 error correction) offset in time to avoid fate sharing. This 792 could also be "layered", so a percentage of data loss will 793 simply reduce fidelity rather than corrupt the data. 795 - Reduce the send rate of one datastream in order to favor 796 another of higher priority (e.g. sacrifice video in order to 797 ensure audio delivery). 799 - Send data at a lower rate (i.e. with a different encoding) on a 800 separate multicast address and/or port number for high-loss 801 receivers. 803 However, with multicast applications--one-to-many or many-to-many-- 804 which have multiple receivers, the feedback loop design needs 805 modification. If all receivers return data loss reports 806 simultaneously, the sender is easily overwhelmed in the storm of 807 replies. This is known as the "implosion problem." 809 Another problem is that heterogeneous receiver capabilities can vary 810 widely due to the wide range of (static) network media bandwidth 811 capabilities and dynamically due to transient traffic conditions. 812 If a sender adapts its send rate and data resolution based on the 813 loss rate of its worst receiver(s), then it can only service the 814 lowest common denominator. Hence, a single "crying baby" can spoil 815 it for all other receivers. 817 Strategies exist for dealing with these heterogeneous receiver 818 problems. Here are two examples: 820 Shared Learning - When loss is detected (i.e. a sequenced packet 821 isn't received), a receiver starts a random timer. If it 822 receives a data loss report sent by another receiver as it 823 waits for the timer to expire, it stops the timer and does not 824 send a report. Otherwise, it sends a report when the timer 825 expires. The Real-Time Protocol and its feedback-loop 826 counterpart Real-Time Control Protocol [RTP/RTCP] employ a 827 strategy similar to this to keep feedback traffic to 5 percent 828 or less than the overall session traffic. This technique was 829 originally utilized in IGMP. 831 Local Recovery - Some receivers may be designated as local 832 distribution points or "transcoders" that either re-send data 833 locally (possibly via unicast) when loss is reported or they 834 re-encode the data for lower bandwidth receivers before re- 835 sending. No standards exist for these strategies, although 836 "local recovery" is used by several reliable multicast 837 protocols. 839 Adaptive multicast application design for heterogeneous receivers is 840 still an active area of research. The fundamental requirements are 841 to maximize application usability, while accommodating network 842 conditions in a "network friendly" manner. In other words, 843 congestion detection and avoidance are (at least) as important in 844 protocol design as the user experience. The adaptive mechanisms 845 must also be stable, so they do not adapt too quickly--changing 846 encoding and rates based on too little information about what may be 847 a transient condition--to avoid oscillation. 849 This "feedback loop" service necessary for support of heterogeneous 850 receivers is not illustrated in the services summary in Figure 4, 851 although it could be added alongside "Reliable Transport" and the 852 others. This service could be implemented within an application or 853 accessed externally, as provided by the operating system or a third 854 party. 856 5.4 Reliable Data Delivery 858 Many of the multicast application examples in our list--like 859 audio/video distribution--have loss-tolerant data content. In other 860 words, the data content itself can remain useful even if some of it 861 is lost. For example, audio might have a short gap or lower 862 fidelity but will remain legible despite some data loss. 864 Other application examples--like caching and synchronized resources- 865 -require reliable data delivery. They deliver content that must be 866 complete, unchanged, in sequence, and without duplicates. The "Loss 867 Intolerant" column in Figure 5 shows a list of applications with 868 this requirement, while the others can tolerate varying levels of 869 data loss. The tolerance levels are typically determined by the 870 nature of the data and the encoding in use. 872 | 873 1toM | b a, d c, e 874 | 875 MtoM | f, j, k, l, m, n g, h, i 876 | 877 Mto1 | o, p, r, s q 878 | 879 +------------------------------------------------ 880 Loss Tolerant Loss Intolerant 882 Figure 7: Reliability Requirements of Application types 884 Some of the challenges involved with enabling reliable multicast 885 transport are the same as those of sending to heterogeneous 886 receivers, and some solutions are similar also. For example, many 887 reliable multicast transport protocols avoid the implosion problem 888 by using negative acknowledgements (NAKs) from receivers to indicate 889 what was lost. They also use "shared learning" whereby receivers 890 listen to others' NAKs and then listen for the resulting 891 retransmission of data, rather than requesting retransmission by 892 sending a NAK themselves. 894 Although reliable delivery cannot change the data sent--except, 895 perhaps, to use a loss-less data compression algorithm--they can use 896 other adaptive techniques like sending redundant data, or adjusting 897 the send rate. 899 Although many reliable multicast protocol implementations exist 900 [Obraczka], and a few are already available in commercial products, 901 none of them are standardized. Work is ongoing in the "Reliable 902 Multicast" research group of the Internet Research Task Force [IRTF] 903 to provide a better definition of the problem, the multicast 904 transport requirements, and protocol mechanisms. 906 Scalability is the paramount concern, and it implies the general 907 need for "network friendly" protocols that detect and avoid 908 congestion as they provide reliable delivery. Other considerations 909 are protocol robustness, support for "late joins", group management 910 and security (which we discuss next). 912 The current consensus is that due to the wide variety of multicast 913 application requirements--some of which are at odds--no single 914 multicast transport will likely be appropriate for all applications. 916 As a result, most believe that we will eventually standardize a 917 number of reliable multicast protocols, rather than a single one. 919 5.5 Security 921 For any IP network application--unicast or multicast--security is 922 necessary because networks comprise users with different levels of 923 trust. 925 Network application security is challenging, even for unicast. And 926 as the need for security increases--gauged by the risks of being 927 without it--the challenges increase also. Security system 928 complexity and overhead is commensurate with the protection it 929 provides. "No one can guarantee 100% security. But we can work 930 toward 100% risk acceptance ...Strong cryptography can withstand 931 targeted attacks up to a point--the point at which it becomes easier 932 to get the information some other way ...A good design starts with a 933 threat model: what the system is designed to protect, from whom, and 934 for how long." [Schneier] 936 Multicast applications are no different than unicast applications 937 with respect to their need for security, and they require the same 938 basic security services: user authentication, data integrity, data 939 privacy and user privacy (anonymity). However, enabling security 940 for multicast applications is even more of a challenge than for 941 unicast. Having multiple receivers makes a difference, as does 942 their heterogeneity and the dynamic nature of multicast group 943 memberships. 945 Multicast security requirements can include any combination of the 946 following services: 948 Limiting Senders - Controlling who can send to group addresses 950 Limiting Receivers - Controlling who can receive 952 Limiting Access - Controlling who can "read" multicast content 953 either by encrypting content or limiting receivers (which isn't 954 possible yet) 956 Verifying Content - Ensuring that data originated from an 957 authenticated sender and was not altered en route 959 Protecting Receiver Privacy - Controlling whether sender(s) or 960 other receivers know receiver identity 962 Firewall Traversal - Proxying outgoing "join" requests through 963 firewalls, allowing incoming or outgoing traffic through, and 964 (possibly) authenticating receivers for filtering purposes and 965 security [Chouinard, Finlayson]. 967 This list is not comprehensive, but includes the most commonly 968 needed security services. Different multicast applications and 969 different application contexts can have very different needs with 970 respect to these services, and others. "Two main issues emerge, 971 where the performance of current solutions leaves much to be 972 desired" [Canetti]: 974 Individual authentication - how is sender identity verified for 975 each multicast datagram received? 977 Membership revocation - how is further group access disabled for 978 group members that leave the group (e.g. encryption keys in 979 their possession disabled)? 981 Performance is largely a factor when a user joins or leaves a group. 982 For example, methods used to authenticate potential group members 983 during joins or re-keying current members after a member leaves can 984 involve significant processing and protocol overhead and result in 985 significant delays that affect usability. 987 Like reliable multicast, secure multicast is also still under 988 investigation in the Internet Research Task Force [IRTF]. Protocol 989 mechanisms for many of the most important of these services--such as 990 limiting senders--have not yet been defined, let alone developed and 991 deployed. 993 As is true for reliable multicast, the current consensus is that no 994 single security protocol will satisfy the wide diversity of 995 sometimes-contradictory requirements among multicast applications. 996 Hence, multicast security will also likely require a number of 997 different protocols. 999 5.6 Synchronized Play-Out 1001 This refers to having all receivers simultaneously play-out the 1002 multicast data they received. This may be necessary for fairness-- 1003 playing-out prices for auctions, or stock-prices--or to ensure 1004 synchronization with other receivers, such as when playing music. 1006 Here is an analogy to illustrate: Imagine a multi-speaker stereo 1007 system that is wired throughout a home (via analog). With the 1008 stereo playing on all speaker sets, you will hear continuous music 1009 as you walk from room-to-room. 1011 Now imagine a house full of multi-media and network enabled computer 1012 systems. Although they will all receive the same music datastream 1013 simultaneously via multicast, they will provide discontinuous music 1014 playback as you walk room-to-room. 1016 To provide synchronized playback that would enable continuous music 1017 from room-to-room would require three things: 1019 1) system clocks on all systems should be synchronized 1020 2) datastreams must be framed with timestamps 1021 3) the playback latency of the multimedia hardware 1023 The third of these is the most difficult to achieve at this time. 1024 Hardware and drivers don't provide any mechanism for retrieving this 1025 information, although different audio and video devices have a wide- 1026 range of performance. 1028 6. Service APIs 1030 In some cases, the protocol services mentioned in this document can 1031 be enabled transparently by passive configuration mechanisms and 1032 "middleware." For example, it is conceivable that a UDP 1033 implementation could implicitly enable a reliable multicast protocol 1034 without the explicit interaction of the application. 1036 Sometimes, however, applications need explicit access to these 1037 services for flexibility and control. For example, an adaptive 1038 application sending to a heterogeneous group of receivers using RTP 1039 may need to process RTCP reports from receivers in order to adapt 1040 accordingly (by throttling send rate or changing data encoders, for 1041 example) [RTP API]. Hence, there is often a need for service APIs 1042 that allow an application to qualify and initiate service requests, 1043 and receive event notifications. In Figure 4, the top edge of the 1044 box for each service effectively represents its API. 1046 Network APIs generally reflect the protocols they support. Their 1047 functionality and argument values are a (varying) subset of protocol 1048 message types, header fields and values. Although some protocol 1049 details and actions may not be exposed in APIs--since many protocol 1050 mechanics need not be exposed--others are crucial to efficient and 1051 flexible application operation. 1053 A more complete examination of the application services described in 1054 this document might also identify the protocol features that could 1055 be mapped to define a (generic) API definition for that service. 1056 APIs are often controversial, however. Not only are there many 1057 language differences, but it is also possible to create different 1058 APIs by exposing different levels of detail in trade-offs between 1059 flexibility and simplicity. 1061 7. Security Considerations 1063 See section 4.4 1065 8. Acknowledgements 1067 The author would like to acknowledge and thank the following 1068 individuals for their helpful feedback: Kevin Almeroth, Ran Canetti, 1069 Brian Haberman, Eric A. Hall, Kenneth C. Miller, and Dave Thaler. 1071 9. References 1073 [AnyCast] C. Partridge, T. Mendez, W. Milliken, "Host Anycasting 1074 Service", RFC 1546, November 1993 1076 [Bradner] S. Bradner, "Internet Protocol Multicast Problem 1077 Statement", , 1078 September 1997, Work in Progress 1080 [Canetti] R. Canetti, B. Pinkas, "A taxonomy of multicast security 1081 issues(temporary version)", , May 1998, Work in Progress 1084 [Chouinard] D. Chouinard, "SOCKS V5 UDP and Multicast Extensions to 1085 Facilitate Multicast Firewall Traversal", , Nov 1997, Work in 1087 Progress 1089 [DiffServ] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K. 1090 Nichols, and M. Speer, "A Framework for Use of RSVP with 1091 Diff-serv Networks", Internet Draft , November 1998, Work in Progress 1094 [DIS] J.M.Pullen, M. Mytak, C. Bouwens, "Limitations of 1095 Internet Protocol Suite for Distributed Simulation in the 1096 Large Multicast Environment", RFC 2502, February 1999 1098 [Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech 1099 Earthlink Seminar Series, April 22, 1998 1101 [Finlayson] R. Finlayson, "IP Multicast and Firewalls", , November 1998, Work in 1103 Progress 1105 [IGMPv2] B. Fenner, "Internet Group Management Protocol, Version 1106 2", RFC 2236, November 1997 1108 [IMJ] K. Almeroth and M. Ammar, "The Interactive Multimedia 1109 Jukebox (IMJ): A New Paradigm for the On-Demand Delivery 1110 of Audio/Video", Proceedings of the Seventh International 1111 World Wide Web Conference, Brisbane, AUSTRALIA, April 1112 1998 1114 [IRTF] A Weinrib, J. Postel, "The IRTF Guidelines and 1115 Procedures", RFC 2014, January 1996 1117 [LSMA] P. Bagnall, R. Briscoe, A. Poppitt, "Taxonomy of 1118 Communication Requirements, for Large-scale Multicast 1119 Applications," , 1120 November 1998, Work in Progress 1122 [MASC] D. Estrin, R. Govindan, M. Handley, S. Kumar, P. 1123 Radoslavov, D. Thaler, "The Multicast Address-Set Claim 1124 (MASC) Protocol", , August 1125 1998, Work in Progress 1127 [Maufer] T. Maufer, C. Semeria, "Introduction to IP Multicast 1128 Routing," , 1129 July 1997, Work in Progress 1131 [Maufer2] T. Maufer, "Deploying IP Multicast in the Enterprise", 1132 (c) 1998 Prentice Hall, Upper Saddle River NJ 1133 ISBN 0-13-897687-2 1135 [Miller] C. K. Miller, "Multicast Networking and Applications", 1136 (c) 1999 Addison Wesley Longman, Reading MA 1137 ISBN 0-201-30979-3 1139 [MADCAP] B. V. Patel, M. Shah, S. R. Hanna, " Multicast Address 1140 Dynamic Client Allocation Protocol (MADCAP)", 1141 , February 1999, 1142 Work in Progress 1144 [MIX] H. Lamaster, S. Shultz, J. Meylor, D. Meyer, "Multicast- 1145 Friendly Internet Exchange (MIX)," , Dec 1998, Work in Progress 1148 [Obraczka] K. Obraczka "Multicast Transport Mechanisms: A Survey and 1149 Taxonomy", IEEE Communications Magazine, Vol. 36 No. 1, 1150 January 1998 1152 [RM] A. Mankin, A. Romanow, S. Bradner, V. Paxson, "IETF 1153 Criteria for Evaluating Reliable Multicast Transport and 1154 Application Protocols", RFC 2357, June 1998 1156 [RSVP] J. Wroclawski, "The Use of RSVP with IETF Integrated 1157 Services", RFC 2210, September 1997 1159 [RTP API] J. Rosenberg, "Columbia RTP Library API Specification," 1160 (Note: Does not include RTCP processing), February 1997 1162 [RTP/RTCP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 1163 "RTP: A Transport Protocol for Real-Time Applications", 1164 RFC 1889, January 1996 1166 [SAP] M. Handley, "SAP: Session Announcement Protocol", , November 1996, Work in Progress 1169 [SDP] M. Handley, V. Jacobson, "SDP: Session Description 1170 Protocol", RFC 2327, April 1998 1172 [Schneier] B. Schneier, _ Why Cryptography Is Harder Than It Looks", 1173 December 1996, http://www.counterpane.com/whycrypto.html 1175 [SlowStart] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast 1176 Retransmit, and Fast Recovery Algorithms", RFC 2001, 1177 January 1997 1179 [SLP] J. Veizades, E. Guttman, C. Perkins, S. Kaplan, "Service 1180 Location Protocol", RFC 2165, June 1997 1182 10. Authors' Addresses 1184 Bob Quinn 1185 IP Multicast Initiative (IPMI) 1186 Stardust Forums, Inc. 1187 1901 S. Bascom Ave. #333 1188 Campbell, CA 95008 1190 +1 408 879 8080 1191 rcq@ipmulticast.com 1193 Kevin Almeroth 1194 Department of Computer Science 1195 Office: 2113, Engineering I 1196 University of California 1197 Santa Barbara, CA 93106-5110 1199 +1 805 893 2777 1200 almeroth@cs.ucsb.edu 1202 11. Full Copyright Statement 1204 Copyright (C) The Internet Society (1999). All Rights Reserved. 1206 This document and translations of it may be copied and furnished 1207 toothers, and derivative works that comment on or otherwise explain 1208 it orassist in its implmentation may be prepared, copied, published 1209 anddistributed, in whole or in part, without restriction of any 1210 kind,provided that the above copyright notice and this paragraph are 1211 includedon all such copies and derivative works. However, this 1212 document itselfmay not be modified in any way, such as by removing 1213 the copyright noticeor references to the Internet Society or other 1214 Internet organizations,except as needed for the purpose of 1215 developing Internet standards inwhich case the procedures for 1216 copyrights defined in the Internetlanguages other than English. 1218 The limited permissions granted above are perpetual and will not be 1219 revoked by the Internet Society or its successors or assigns. 1221 This document and the information contained herein is provided on an 1222 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1223 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1224 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1225 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1226 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."