idnits 2.17.1 draft-quinn-multicast-apps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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 (November 1998) is 9294 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 77, but not defined == Unused Reference: 'RM' is defined on line 817, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bradner' -- Possible downref: Non-RFC (?) normative reference: ref. 'Canetti' -- Possible downref: Non-RFC (?) normative reference: ref. 'DiffServ' -- Possible downref: Non-RFC (?) normative reference: ref. 'DIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'Estrin' -- 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. 'MDHCP' -- 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: 10 errors (**), 0 flaws (~~), 3 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT B.Quinn 2 File: draft-quinn-multicast-apps-00.txt IP Multicast Initiative 3 Expiration: May 1999 November 1998 5 IP Multicast Applications: 6 Challenges and Solutions 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Abstract 30 This document highlights the challenges of creating multicast 31 applications, and describes the solutions available or under 32 development. It provides a taxonomy of multicast applications in 33 terms of their requirements, and discusses some existing multicast- 34 based protocols. Many of the solutions--especially in the areas of 35 reliable multicast data delivery, congestion control, and security-- 36 have not yet emerged from the research realms. We describe the 37 general state of on-going research in these areas, highlighting the 38 strategies under investigation. 40 Table of Contents 42 1. Introduction....................................................2 43 1.1 Motivation...................................................3 44 1.2 Focus........................................................3 45 2. IP Multicast-enabled Network....................................4 46 3. IP Multicast Application Taxonomy...............................4 47 3.1 One-to-Many Applications.....................................5 48 3.2 Many-to-One Applications.....................................6 49 3.3 Many-to-Many Applications....................................7 50 3.4 Bandwidth and Delay Requirements Summary.....................8 51 4. Multicast Service Requirements..................................9 52 4.1 Heterogeneous Receivers.....................................10 53 4.2 Reliable Data Delivery......................................12 54 4.3 Security....................................................13 55 5. Other Considerations...........................................15 56 5.1 Session Management..........................................15 57 5.2 Join and Leave Latency......................................15 58 5.3 Service APIs................................................16 59 6. Security Considerations........................................16 60 7. References.....................................................17 61 8. Author's Address...............................................18 63 1. Introduction 65 IP Multicast will play a prominent role on the Internet in the 66 coming years. It is a requirement, not an option, if the Internet 67 is going to scale. Multicast allows application developers "to add 68 more functionality without significantly impacting the network" 69 [Bradner]. 71 Developing multicast-enabled applications is ostensibly simple. 72 Having datagram access allows any application to send to a multicast 73 address. A multicast application need only increase the Internet 74 Protocol (IP) time-to-live (TTL) value to more than 1 (the default 75 value) to allow outgoing datagrams to traverse routers. To receive 76 a multicast datagram, applications join the multicast group, which 77 transparently generates an IGMP [IGMPV2] group membership report. 79 This apparent simplicity is deceptive, however. Enabling multicast 80 support in applications and protocols that can scale well on a 81 heterogeneous network is a significant challenge. Specifically, 82 sending constant bit rate datastreams, reliable data delivery, 83 security, and managing many-to-many communications all require 84 special consideration. Some solutions are available, but many of 85 these services are still active research areas. 87 1.1 Motivation 89 The purpose of this document is to provide an orientation for 90 application developers to the types of services multicast 91 applications need, and the current state-of-the-art of their 92 development. 94 Multicast-based applications and services will play an important 95 role in the future of the Internet as continued multicast deployment 96 encourages their use and development. It is important that 97 developers be aware of the issues and solutions available--and 98 especially of their limitations--in order to avoid protocols that 99 negatively impact networks (thereby counter-acting the benefits of 100 multicast) or wasting their efforts "re-inventing the wheel." 102 The hope is that by raising developers' awareness, we can adjust 103 their expectations of finding solutions and lead them to successful, 104 scalable, and "network-friendly" development efforts. 106 1.2 Focus 108 Our initial premise is that the multicast infrastructure is 109 transparent to applications, so it is not directly relevant to this 110 discussion. Our focus here is on multicast application protocol 111 services, so this document explicitly avoids any discussion of 112 multicast address management and routing issues. We identify and 113 describe the multicast-specific issues involved with developing 114 applications. 116 We assume the reader has a general understanding of the mechanics of 117 multicast, and in this respect we intend to compliment other 118 introductory documents [Maufer]. Since this is an introductory 119 survey rather than a comprehensive examination, we refer readers to 120 other multicast application requirements descriptions [LSMA] for 121 more detail. 123 In the remainder of this document we first define the term "IP 124 multicast enabled network," the multicast infrastructure. Next we 125 describe the types of new functionality that multicast applications 126 can enable and their requirements. We then examine the services 127 that satisfy these requirements, the challenges they present, and 128 provide a brief survey of the solutions available or under 129 development. We wrap up with a discussion of other application 130 considerations, such as session management and application 131 programming interfaces (APIs). 133 2. IP Multicast Enabled Network 135 An "IP multicast-enabled network" provides end-to-end services in 136 the IP network infrastructure to allow any IP host to send datagrams 137 to an IP multicast address that any number of other IP hosts can 138 receive. This requires two essential protocol components: 140 1) An IP host-based protocol to allow a receiver application to 141 notify a local router(s) that it has joined the group 143 2) An IP router-based protocol to allow any routers with multicast 144 group members (receivers) on their local networks to 145 communicate with other routers to ensure that all datagrams 146 sent to the group address are forwarded to all receivers 148 Additionally, a complete IP multicast-enabled network also requires 149 a global address management infrastructure designed to reasonably 150 avoid "address collisions" [MASC]. An address collision occurs when 151 two different applications send to the same multicast address in the 152 same date/time slot for different purposes, thereby possibly 153 "polluting" each other's datastream. An address management 154 infrastructure includes a host-based protocol mechanism to allow an 155 application to request dynamic address allocations for "lease" 156 periods [MDHCP]. 158 At the time of this writing some of these services are not 159 standardized or deployed. Specifically, global address management 160 and intra-domain multicast routing are incomplete. Nonetheless, in 161 the remainder of this document we assume that the multicast-enabled 162 network is already full-service in these respects, and ubiquitous. 163 Although the global Internet is not yet fully multicast-enabled, a 164 large and growing portion is and many enterprise networks 165 (Intranets) are also, so this perspective is relevant today. 167 3. IP Multicast Application Taxonomy 169 With an IP multicast-enabled network available, some unique and 170 powerful applications and application services are possible. 171 "Multicast enables coordination - it is well suited to loosely 172 coupled distributed systems (of people, servers, databases, 173 processes, devices...)" [Estrin]. 175 The sender and receiver relationships are primarily what 176 differentiate multicast applications from unicast applications. In 177 this respect, we can characterize three very general categories of 178 multicast applications: 180 One-to-Many (1toM): A single host sending to two or more (n) 181 receivers 183 Many-to-One (Mto1): Any number of receivers sending data back to a 184 (source) sender via unicast or multicast 186 Many-to-Many (MtoM): Any number of hosts sending to the same 187 multicast group address, as well as receiving from it 189 For each of these multicast application categories, we provide a 190 list of application and protocol examples. These lists are not 191 comprehensive, but include the prominent multicast application types 192 in each category. We reference the items in these lists in the 193 remainder of this document as we describe their specific service 194 requirements, define the challenges they present, and reference 195 solutions available or under development. 197 In section 3.4 we provide a summary of the bandwidth and delay 198 requirements for the applications listed below. 200 3.1 One-to-Many Applications 202 When people think of multicast, they most often think of broadcast- 203 based multimedia applications: television (video) and radio (audio). 204 This is a reasonable analogy and indeed these are significant 205 multicast applications, but these are far from the extent of 206 applications that multicast can enable. Audio/Video distribution 207 represents a fraction of the multicast application possibilities, 208 and most do not have analogs in today's consumer broadcast industry. 210 a) Scheduled audio/video (a/v) distribution: Lectures, 211 presentations, meetings, or any other type of scheduled event 212 whose multimedia coverage could benefit an audience (i.e. 213 television and radio "broadcasts"). One or more constant-bit- 214 rate (CBR) datastreams and relatively high-bandwidth demands 215 characterize these applications. When more than one datastream 216 is present--as with an audio/video combination--the two are 217 synchronized and one typically has a higher priority than the 218 other(s). For example, in an a/v combination it is more 219 important to ensure a legible audio stream, than perfect video. 221 b) Push media: News headlines, weather updates, sports scores, or 222 other types of non-essential dynamic information. "Drip-feed," 223 relatively low-bandwidth data characterize these applications. 225 c) Caching: Web site content, executable binaries, and other file- 226 based updates sent to distributed replication/caching sites 228 d) Announcements: Network time, multicast session schedules, 229 random numbers, keys, configuration updates, (scoped) network 230 locality beacons, or other types of information that are 231 commonly useful. Their bandwidth demands can vary, but 232 generally they are very low bandwidth. 234 e) Monitoring: Stock prices, Sensor equipment (seismic activity, 235 telemetry, meteorological or oceanic readings), security 236 systems, manufacturing or other types of real-time information. 237 Bandwidth demands vary with sample frequency and resolution, 238 and may be either constant-bit-rate or bursty (if event- 239 driven). 241 3.2 Many-to-One Applications 243 Many-to-one applications are typically two-way request/response 244 applications, where either end (the "many" or the "one") may 245 generate the request. 247 A common challenge among this type of application is dealing with 248 the potential of a "response storm," also known as the "implosion 249 problem." This occurs when receivers overwhelm the sender by 250 forwarding their responses simultaneously. This problem is also 251 common in reliable data delivery and adaptive applications as we 252 describe later along with avoidance strategies. 254 f) Resource Discovery: Service Location, for example, leverages IP 255 Multicast to enable "anycast" capability: A multicast receiver 256 to send a query to a group address, to elicit responses from 257 the closest host(s) so they can satisfy the request. The 258 responses might also contain information that allows the 259 receiver to determine the most appropriate (e.g. closest) 260 service provider to use. 262 g) Data Collection: This is the converse of a one-to-many 263 "monitoring" application described earlier. In this case there 264 may be any number of distributed "sensors" that send data to a 265 data collection host. The sensors might send updates in 266 response to a request from the data collector, or send 267 continuously at regular intervals, or send spontaneously when a 268 pre-defined event occurs. Bandwidth demands can vary based on 269 sample frequency and resolution. 271 h) Auctions: The "auctioneer" starts the bidding by describing 272 whatever it is for sale (product or service or whatever), and 273 receivers send their bids privately or publicly (i.e. to a 274 unicast or multicast address). 276 i) Polling: The "pollster" sends out a question, and the "pollees" 277 respond with answers. 279 j) Juke Box: Allows near-on-demand a/v playback. Receivers use an 280 "out-of-band" protocol mechanism (via web, email, unicast or 281 multicast requests, etc.) to send their playback request into a 282 scheduling queue [IMJ]. 284 3.3 Many-to-Many Applications 286 The many-to-many capabilities of IP multicast enable the most unique 287 and powerful applications. Many-to-many applications are 288 characterized by two-way communications where any host may send to 289 the group as well as receive from it. Since each host may receive 290 data from multiple senders while it also sends data, many-to-many 291 applications often present complex coordination and management 292 challenges. 294 k) Multimedia Conferencing: Audio/Video and whiteboard comprise 295 the classic conference application. Having multiple 296 datastreams with different priorities characterizes this type 297 of application. Co-ordination issues--such as determining who 298 gets to talk when--complicate their development and usability. 299 There are common heuristics and "rules of play", but no 300 standards exist for managing conference group dynamics. 302 l) Synchronized Resources: Shared distributed databases of any 303 type (schedules, directories, as well as traditional 304 Information System databases). 306 m) Concurrent Processing: Distributed parallel processing. 308 n) Collaboration: Shared document editing. 310 o) Distance Learning: This is a one-to-many a/v distribution 311 application with "upstream" capability that allows receivers to 312 question the speaker(s). 314 p) Chat Groups: These are like text-based conferences, but may 315 also provide simulated representations ("avatars") for each 316 "speaker" in simulated environments. 318 q) Distributed Interactive Simulations [DIS]: Each object in a 319 simulation multicasts descriptive information (e.g. telemetry) 320 so all other objects can render the object, and interact as 321 necessary. The bandwidth demands for these can be tremendous, 322 as the number of objects and the resolution of descriptive 323 information increases. 325 r) Multi-player Games: Many multi-player games are simply 326 distributed interactive simulations, and may include chat group 327 capabilities. Bandwidth usage can vary widely, although 328 today's first-generation multi-player games attempt to minimize 329 bandwidth usage to increase the target audience (many of whom 330 still use dial-up modems). 332 s) Jam Sessions: Shared encoded audio (e.g. music). The bandwidth 333 demands vary based on the encoding technique, sample rate, 334 sample resolution, number of channels, etc. 336 3.4 Bandwidth and Delay Requirements Summary 338 For quick reference, we've plotted the bandwidth and delay 339 characteristics of the multicast applications in our lists. Figure 340 1 shows multicast applications approximate bandwidth requirements. 342 We provide this summary here rather than in section 4 (Multicast 343 Service Requirements) because bandwidth and delay requirements are 344 common to unicast as well as multicast network applications. 345 Unicast and multicast applications both need to design applications 346 to adapt to the variability of network conditions. But as we 347 describe in section 4.1, it is the need to accommodate multiple 348 heterogeneous multicast receivers--with their diversity of bandwidth 349 capacity and delivery delays--that presents the unique challenge for 350 multicast applications to satisfy these requirements. 352 | 353 MtoM | p l, n k, m, o, q, r, s 354 | 355 Mto1 | f, h, i g, h j 356 | 357 1toM | b, d c, e a 358 | 359 +----------------------------------------------- 360 Low Bandwidth High Bandwidth 362 Figure 1: Bandwidth Requirements of applications 364 Aside from those with time-sensitive data (e.g. stock prices, and 365 real-time monitoring information), most one-to-many applications 366 have a high tolerance for delay and delay variance (jitter). 367 Constant bit-rate (CBR) data--such as streaming media (audio/video)- 368 -are sensitive to delivery delay variations (jitter), but 369 applications commonly counteract the effects by buffering data and 370 delaying playback. 372 Most many-to-one and many-to-many multicast applications are 373 intolerant of delays because they are bidirectional, interactive and 374 request/response dependent. As a result, delays should be 375 minimized, since they can adversely affect the application's 376 usability. 378 This need to minimize delays is most evident in (two-way) conference 379 applications, where users cannot converse effectively if the audio 380 or video is delayed more than 500 milliseconds. For this and other 381 examples see Figure 2, which plots multicast applications on a 382 (coarse) scale of sensitivity to delivery delays. 384 | 385 MtoM | l, n, o, p k, m, q, r, s 386 | 387 Mto1 | i f, g, j h 388 | 389 1toM | b, c a, d e 390 | 391 +----------------------------------------------- 392 Delay Tolerant Delay Intolerant 394 Figure 2: Delay tolerance of application types 396 For delay-intolerant multicast (or unicast) applications, quality of 397 service (QoS) is the only option. IP networks currently provide 398 only "best effort" delivery, so data are subject to variable router 399 queuing delays and loss due to network congestion (router queue 400 overflows). IP QoS standards do exist now [RSVP] and efforts to 401 enable end-to-end QoS support in the Internet are underway 402 [DiffServ]. 404 However, QoS support is an IP network infrastructure consideration 405 and relevant to unicast as well as multicast. Since our focus is on 406 multicast-specific application services, further discussion of the 407 QoS protocols and services is beyond the scope of this document. 409 4. Multicast Service Requirements 411 The application categories described in the previous section are 412 very general in nature. Within each category and even among each of 413 the application types, specific application instances have a variety 414 of application requirements. One-to-many application types are 415 relatively simple to develop, but as we pointed out there are 416 challenges involved with developing many-to-one and many-to-many 417 applications. 419 The most challenging multicast application service requirements can 420 be summarized into three categories: 422 Heterogeneous Receivers - Sending to receivers with a wide variety 423 of bandwidth capacities, latency characteristics, and network 424 congestion 426 Reliable Data Delivery - Ensuring that all data sent is received 427 by all receivers 429 Security - Ensuring content privacy among dynamic multicast group 430 memberships, and limiting senders 432 In the remainder of this document, we will describe the challenges 433 involved with enabling each of these application services, and the 434 status of standardizing possible solutions. 436 4.1 Heterogeneous Receivers 438 The Internet is a network of networks. IP's strength is its ability 439 to enable seamless interoperability between hosts on disparate 440 network media, the heterogeneous network. 442 When two hosts communicate via unicast--one-to-one--across an IP 443 network, it is relatively easy for senders to adapt to varying 444 network conditions. The Transmission Control Protocol (TCP) 445 provides reliable data transport, and is the model of "network 446 friendly" adaptability. 448 TCP receivers send acknowledgements back to the sender for data 449 delivered. A TCP sender detects data loss from the data sent that 450 is not acknowledged. When it detects data loss, TCP infers that 451 there is network congestion or a low-bandwidth link, and adapts by 452 throttling down its send rate [SlowStart]. 454 User Datagram Protocol (UDP) does not enable a receiver feedback 455 loop the way TCP does, since UDP does not provide reliable data 456 delivery service. As a result, it also does not have a loss 457 detection and adaptive congestion control mechanism as TCP does. 458 However, it is possible for a unicast UDP application to enable 459 similar adaptive algorithms to achieve the same result, or even 460 improve on it. 462 A unicast UDP application that uses a feedback mechanism to detect 463 data loss and adapt the send rate, can do so better than TCP. TCP 464 automatically reduces the "congestion window" when data loss is 465 detected, although the updated send rate may be slower than a CBR 466 audio/video stream requires. When a UDP application detects loss, 467 it can adapt the data itself to accommodate the lower send rate. 468 For example, a UDP application can: 470 - Reduce the data resolution (e.g. send lower fidelity 471 audio/video by reducing sample frequency or frame rate) to 472 reduce data rate. 474 - Modify the data encoding to add redundant data (e.g. forward 475 error correction) offset in time to avoid fate sharing. This 476 could also be "layered", so a percentage of data loss will 477 simply reduce fidelity rather than corrupt the data. 479 - Reduce the send rate of one datastream in order to favor 480 another of higher priority (e.g. sacrifice video in order to 481 ensure audio delivery). 483 - Send data at a lower rate (i.e. with a different encoding) on a 484 separate multicast address and/or port number for high-loss 485 receivers. 487 However, with multicast applications--one-to-many or many-to-many-- 488 which have multiple receivers, the feedback loop design needs 489 modification. If all receivers return data loss reports 490 simultaneously, the sender is easily overwhelmed in the storm of 491 replies. This is known as the "implosion problem." 493 Another problem is that heterogeneous receiver capabilities can vary 494 widely due to the wide range of (static) network media bandwidth 495 capabilities and dynamically due to transient traffic conditions. 496 If a sender adapts its send rate and data resolution based on the 497 loss rate of its worst receiver(s), then it can only service the 498 lowest common denominator. Hence, a single "crying baby" can spoil 499 it for all other receivers. 501 Strategies exist for dealing with these heterogeneous receiver 502 problems. Here are two examples: 504 Shared Learning - When loss is detected (i.e. a sequenced packet 505 isn't received), a receiver starts a random timer. If it 506 receives a data loss report sent by another receiver as it 507 waits for the timer to expire, it stops the timer and does not 508 send a report. Otherwise, it sends a report when the timer 509 expires. The Real-Time Protocol and its feedback-loop 510 counterpart Real-Time Control Protocol [RTP/RTCP] employ a 511 strategy similar to this to keep feedback traffic to 5 percent 512 or less than the overall session traffic. This technique was 513 originally utilized in IGMP. 515 Local Recovery - Some receivers may be designated as local 516 distribution points or "transcoders" that either re-send data 517 locally (possibly via unicast) when loss is reported or they 518 re-encode the data for lower bandwidth receivers before re- 519 sending. No standards exist for these strategies, although 520 "local recovery" is used by several reliable multicast 521 protocols. 523 Adaptive multicast application design for heterogeneous receivers is 524 still an active area of research. The fundamental requirements are 525 to maximize application usability, while accommodating network 526 conditions in a "network friendly" manner. In other words, 527 congestion detection and avoidance are (at least) as important in 528 protocol design as the user experience. The adaptive mechanisms 529 must also be stable, so they do not adapt too quickly--changing 530 encoding and rates based on too little information about what may be 531 a transient condition--to avoid oscillation. 533 4.2 Reliable Data Delivery 535 Many of the multicast application examples in our list--like 536 audio/video distribution--have loss-tolerant data content. In other 537 words, the data content itself can remain useful even if some of it 538 is lost. For example, audio might have a short gap or lower 539 fidelity but will remain legible despite some data loss. 541 Other application examples--like caching and synchronized resources- 542 -require reliable data delivery. They deliver content that must be 543 complete, unchanged, in sequence, and without duplicates. The "Loss 544 Intolerant" column in Figure 3 shows a list of applications with 545 this requirement, while the others can tolerate varying levels of 546 data loss. The tolerance levels are typically determined by the 547 nature of the data and the encoding in use. 549 | 550 MtoM | k, o, p, q, r, s l, m, n 551 | 552 Mto1 | f, g, i, j h 553 | 554 1toM | b a, d c, e 555 | 556 +------------------------------------------------ 557 Loss Tolerant Loss Intolerant 559 Figure 3: Reliability Requirements of Application types 561 Some of the challenges involved with enabling reliable multicast 562 transport are the same as those of sending to heterogeneous 563 receivers, and some solutions are similar also. For example, many 564 reliable multicast transport protocols avoid the implosion problem 565 by using negative acknowledgements (NAKs) from receivers to indicate 566 what was lost. They also use "shared learning" whereby receivers 567 listen to others' NAKs and then listen for the resulting 568 retransmission of data, rather than requesting retransmission by 569 sending a NAK themselves. 571 Although reliable delivery cannot change the data sent--except, 572 perhaps, to use a loss-less data compression algorithm--they can use 573 other adaptive techniques like sending redundant data, or adjusting 574 the send rate. 576 Although many reliable multicast protocol implementations exist 577 [Obraczka], and a few are already available in commercial products, 578 none of them are standardized. Work is ongoing in the "Reliable 579 Multicast" research group of the Internet Research Task Force [IRTF] 580 to provide a better definition of the problem, the multicast 581 transport requirements, and protocol mechanisms. 583 Scalability is the paramount concern, and it implies the general 584 need for "network friendly" protocols that detect and avoid 585 congestion as they provide reliable delivery. Other considerations 586 are protocol robustness, support for "late joins", group management 587 and security (which we discuss next). 589 The current consensus is that due to the wide variety of multicast 590 application requirements--some of which are at odds--no single 591 multicast transport will likely be appropriate for all applications. 592 As a result, most believe that we will eventually standardize a 593 number of reliable multicast protocols, rather than a single one. 595 4.3 Security 597 For any IP network application--unicast or multicast--security is 598 necessary because networks comprise users with different levels of 599 trust. 601 Network application security is challenging, even for unicast. And 602 as the need for security increases--gauged by the risks of being 603 without it--the challenges increase also. Security system 604 complexity and overhead is commensurate with the protection it 605 provides. "No one can guarantee 100% security. But we can work 606 toward 100% risk acceptance ...Strong cryptography can withstand 607 targeted attacks up to a point--the point at which it becomes easier 608 to get the information some other way ...A good design starts with a 609 threat model: what the system is designed to protect, from whom, and 610 for how long." [Schneier] 612 Multicast applications are no different than unicast applications 613 with respect to their need for security, and they require the same 614 basic security services: user authentication, data integrity, data 615 privacy and user privacy (anonymity). However, enabling security 616 for multicast applications is even more of a challenge than for 617 unicast. Having multiple receivers makes a difference, as does 618 their heterogeneity and the dynamic nature of multicast group 619 memberships. 621 Multicast security requirements can include any combination of the 622 following services: 624 Limiting Senders - Controlling who can send to group addresses 626 Limiting Receivers - Controlling who can receive 628 Limiting Access - Controlling who can "read" multicast content 630 Verifying Content - Ensuring that data originated from an 631 authenticated sender and was not altered en route 633 Protecting Receiver Privacy - Controlling whether sender(s) or 634 other receivers know receiver identity 636 This list is not comprehensive, but includes the most commonly 637 needed security services. Different multicast applications and 638 different application contexts can have very different needs with 639 respect to these services, and others. "Two main issues emerge, 640 where the performance of current solutions leaves much to be 641 desired" [Canetti]: 643 Individual authentication - when, how and to whom are encryption 644 keys distributed? 646 Membership revocation - when, why, and how are encryption keys 647 revoked? 649 Performance is largely a factor when a user joins or leaves a group. 650 For example, methods used to authenticate potential group members 651 during joins or re-keying current members after a member leaves can 652 involve significant processing and protocol overhead and result in 653 significant delays that affect usability. 655 Like reliable multicast, secure multicast is also still under 656 investigation in the Internet Research Task Force [IRTF]. Protocol 657 mechanisms for many of the most important of these services--such as 658 limiting senders--have not yet been defined, let alone developed and 659 deployed. 661 As is true for reliable multicast, the current consensus is that no 662 single security protocol will satisfy the wide diversity of 663 sometimes-contradictory requirements among multicast applications. 664 Hence, multicast security will also likely require a number of 665 different protocols. 667 5. Other Considerations 669 In the previous section we surveyed the most challenging service 670 requirements of multicast applications. There are a few other more 671 generic requirements that we haven't mentioned yet that deal 672 specifically with creating and managing multicast application 673 instances. Two of them--session management and join/leave latency-- 674 are borderline infrastructure services required as part of a 675 multicast-enabled network, but requiring some application 676 interaction. The other--Service API definition--is directly related 677 to application development flexibility and control. 679 5.1 Session Management 681 Multicast applications need a "namespace" that provides session 682 directory services that can be used to co-ordinate application 683 schedules and resources, and describe session attributes. These map 684 multicast address and port combinations to a date and time, content 685 description, and other session attributes (e.g. bandwidth and delay 686 requirements, encoding, security and authorization methods, etc.). 688 The session description protocol [SDP] is designed for this purpose, 689 but it does not provide the transport for dissemination of these 690 session descriptions, nor does it enable the address allocation and 691 management. SDP only provides the syntax for describing session 692 attributes. 694 SDP session descriptions may be conveyed publicly or privately by 695 means of any number of transports including web (HTTP) and MIME 696 encoded email. The session announcement protocol [SAP] is the de 697 facto standard transport and many multicast-enabled applications 698 currently use it. SAP limits distribution via multicast scoping, 699 but the current protocol definition has scaling issues that need to 700 be addressed. Specifically, the initialization latency for a 701 session directory can be quite long, and it increases in proportion 702 to the number of session announcements. This is largely a 703 multicast infrastructure issue, however, as this level of protocol 704 detail should be transparent to applications. 706 5.2 Join/Leave Latency 708 Some applications are sensitive to the latency involved with joining 709 and leaving a group. For example, using distributed a/v as a 710 multicast-based "television" must allow users to "channel surf" as 711 they do now, so any delays changing channels--leaving one group and 712 joining another-- will affect usability. Distributed interactive 713 simulations are sensitive to join/leave latency also, particularly 714 when trying to represent fast moving objects that may quickly enter 715 and exit the scope of a simulated environment (e.g. low-flying, 716 fast-moving aircraft). 718 We have not considered the leave/join latency issue thus far, since 719 applications cannot affect its control. Hence, we consider it a 720 feature of a multicast-enabled network [IGMPv2] and beyond the scope 721 of this document. 723 5.3 Service APIs 725 In some cases, the protocol services mentioned in this document can 726 be enabled transparently by passive configuration mechanisms and 727 "middleware." For example, it is conceivable that a UDP 728 implementation could implicitly enable a reliable multicast protocol 729 without the explicit interaction of the application. 731 Sometimes, however, applications need explicit access to these 732 services for flexibility and control. For example, an adaptive 733 application sending to a heterogeneous group of receivers using RTP 734 may need to process RTCP reports from receivers in order to adapt 735 accordingly (by throttling send rate or changing data encoders, for 736 example) [RTP API]. Hence, there is often a need for service APIs 737 that allow an application to qualify and initiate service requests, 738 and receive event notifications. 740 Network APIs generally reflect the protocols they support. Their 741 functionality and argument values are a (varying) subset of protocol 742 message types, header fields and values. Although some protocol 743 details and actions may not be exposed in APIs--since many protocol 744 mechanics need not be exposed--others are crucial to efficient and 745 flexible application operation. 747 A more complete examination of the application services described in 748 this document might also identify the protocol features that could 749 be mapped to define a (generic) API definition for that service. 750 APIs are often controversial, however. Not only are there many 751 language differences, but it is also possible to create different 752 APIs by exposing different levels of detail in trade-offs between 753 flexibility and simplicity. 755 6. Security Considerations 757 See section 4.4 759 7. References 761 [Bradner] S. Bradner, "Internet Protocol Multicast Problem 762 Statement", , 763 September 1997, Work in Progress 765 [Canetti] R. Canetti, B. Pinkas, "A taxonomy of multicast security 766 issues(temporary version)", , May 1998, Work in Progress 769 [DiffServ] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K. 770 Nichols, and M. Speer, "A Framework for Use of RSVP with 771 Diff-serv Networks", Internet Draft , June 1998 774 [DIS] J.M.Pullen, M. Mytak, C. Bouwens, "Limitations of 775 Internet Protocol Suite for Distributed Simulation in the 776 Large Multicast Environment", , September 1998, Work in Progress 779 [Estrin] D. Estrin, "Multicast: Enabler and Challenge", Caltech 780 Earthlink Seminar Series, April 22, 1998 782 [IGMPv2] B. Fenner, "Internet Group Management Protocol, Version 783 2", RFC 2236, November 1997 785 [IMJ] K. Almeroth and M. Ammar, "The Interactive Multimedia 786 Jukebox (IMJ):A New Paradigm for the On-Demand Delivery 787 of Audio/Video", Proceedings of the Seventh International 788 World Wide Web Conference, Brisbane, AUSTRALIA, April 789 1998 791 [IRTF] A Weinrib, J. Postel, "The IRTF Guidelines and 792 Procedures", RFC 2014, January 1996 794 [LSMA] P. Bagnall, R. Briscoe, A. Poppitt, "Taxonomy of 795 Communication Requirements, for Large-scale Multicast 796 Applications," , 797 November 1998, Work in Progress 799 [MASC] D. Estrin, R. Govindan, M. Handley, S. Kumar, P. 800 Radoslavov, D. Thaler, "The Multicast Address-Set Claim 801 (MASC) Protocol", , August 802 1998, Work in Progress 804 [Maufer] T. Maufer, C. Semeria, "Introduction to IP Multicast 805 Routing," , 806 July 1997, Work in Progress 808 [MDHCP] B. V. Patel, M. Shah, S. R. Hanna, " Multicast address 809 allocation based on the Dynamic Host Configuration 810 protocol", , August 811 1998, Work in Progress 813 [Obraczka] K. Obraczka "Multicast Transport Mechanisms: A Survey and 814 Taxonomy", IEEE Communications Magazine, Vol. 36 No. 1, 815 January 1998 817 [RM] A. Mankin, A. Romanow, S. Bradner, V. Paxson, "IETF 818 Criteria for Evaluating Reliable Multicast Transport and 819 Application Protocols", RFC 2357, June 1998 821 [RSVP] J. Wroclawski, "The Use of RSVP with IETF Integrated 822 Services", RFC 2210, September 1997 824 [RTP API] J. Rosenberg, "Columbia RTP Library API Specification," 825 (Note: Does not include RTCP processing), February 1997 827 [RTP/RTCP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 828 "RTP: A Transport Protocol for Real-Time Applications", 829 RFC 1889, January 1996 831 [SAP] M. Handley, "SAP: Session Announcement Protocol", , November 1996, Work in Progress 834 [SDP] M. Handley, V. Jacobson, "SDP: Session Description 835 Protocol", RFC 2327, April 1998 837 [Schneier] B. Schneier, _ Why Cryptography Is Harder Than It Looks", 838 December 1996, http://www.counterpane.com/whycrypto.html 840 [SlowStart] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast 841 Retransmit, and Fast Recovery Algorithms", RFC 2001, 842 January 1997 844 8. Author's Address 846 Bob Quinn 847 IP Multicast Initiative (IPMI) 848 Stardust Forums, Inc. 849 1901 S. Bascom Ave. #333 850 Campbell, CA 95008 852 +1 408 879 8080 853 rcq@ipmulticast.com