The Internet Protocol Journal - Volume 1, No.

2
Reliable Multicast Protocols and Applications
C. Kenneth Miller, StarBurst Communications Multicast IP network services offer new opportunities to provide value-added applications that involve many-to-many transmission such as conferencing or network gaming, or one-to-many transmission such as multimedia events, tickertape feeds, and file transfer, where the many could be thousands or even conceivably millions. Multicast IP services use a different kind of IP address, called Class D. In contrast to individual host addresses (Classes A?C), which include a host and a network component and usually are semipermanent, Class D multicast addresses may by design be used only for a particular session, or can be semipermanent, as multicast groups may be set up and torn down relatively quickly, on the order of seconds. The IP address structure is shown in Figure 1. Figure 1: IP Address Types

(Click on image to enlarge.) Hosts join groups at the receiver?s initiation using the Internet Group Management Protocol (IGMP). When a host joins a group, it notifies the nearest multicast subnet router of its presence in the group, as shown in Figure 2. First defined in RFC 1112 [1] , IGMPv1 is still the version of IGMP most widely supported. IGMPv2 has recently been documented as an official RFC (RFC 2236 [2] ). The main feature that IGMPv2 brings is reduced latency for leaving groups. In IGMPv1, the designated multicast router for the subnet polls for multicast group members; no response between polls indicates that all hosts in a particular multicast group have left the group, and that the routers can prune back the multicast routing tree.

Figure 2: IGMPv1 Dialog

(Click on image to enlarge.) Network infrastructure devices, for example, routers, need to provide a routing protocol to forward multicast packets to group members, in a fashion similar to that performed for unicast routing. Multicast IP packet forwarding is best effort, just as it is with unicast packet forwarding. However, most unicast applications use TCP as a transport layer to provide guaranteed packet ordering and delivery. Some examples of applications that use TCP are the File Transfer Protocol (FTP) for file transfer and the Hypertext Transfer Protocol (HTTP) for Web access. However, TCP is a unicast (point-to-point) only transport protocol. Thus, all multicast applications must run on top of the User Data-gram Protocol (UDP) or alternatively, interface directly to IP via ?raw? sockets and provide their own customized transport layer, as shown in Figure 3. UDP provides only minimal transport-layer ser-vices, error detection, and port multiplexing. Thus, if any errors or packet loss due to congestion occur, packets are simply lost to the application, and they are not recoverable. Thus, all multicast applica-tions must have a specific transport-layer service to support that particular application. When that transport layer operates over UDP, it operates in the application layer with the application. When it inter-faces directly to IP using ?raw? sockets, the specialized transport layer operates at the transport layer, but is specialized to the particular application that uses it. It should be noted that TCP supports only data reliability; it is not suited for transport of multimedia streams, which require consistent time delivery at the receiver and only need to be semireliable. Thus, multimedia streaming applications need a specialized transport layer such as the Real-Time Transport Protocol (RTP) [3] for unicast as well as multicast transmissions.

Figure 3: Specialized Multicast Transport Protocols Operate over UDP or IP

(Click on image to enlarge.) Many equate multicast with multimedia, thinking that the Internet and private intranets will become an alternative entertainment media to television by using multicast IP network services and multimedia streaming technology. However, numerous other multicast applications require reliability rather than timeliness; they are multicast applications that are similar to those unicast applications that operate over TCP, except that delivery is to many recipients rather than just one. Reliable Multicast Application Categories and Requirements Reliable multicast applications come in three basic categories with differing requirements, as shown in Figure 4. Figure 4: Reliable Multicast Application Categories

(Click on image to enlarge.) Collaborative applications such as data conferences (whiteboarding) and network-based games are many-to-many applications with modest scaling requirements of less than 100 participants. This kind of applica-tion requires low latency of less than 400 msec so that responses do not cause discomfort to the human participants. Transmission does not always need strict reliability; for example, refresh of background infor-mation for a network game could wait for the next refresh. Message streaming applications such as tickertape and news feeds also often require low latency. Tickertape feeds to brokerage houses need to be very timely because the information loses value greatly with time. Time is very much money in this application, and there is also a need for strict reliability. Tickertape feeds to consumers are purposely delayed by minutes because they are usually transmitted without charge, but they cannot be so stale as to be viewed as ?old? information. This data does not have a strict reliability requirement because the next trade of a particular security

refreshes the data. News feeds likewise have only a moderate latency requirement. If the news feeds are sent in a carousel fashion, that is, each news story is repeated, strict reliability may not be needed because it is refreshed in the next transmission of the same story. Bulk data delivery has no specific latency requirement. Often there is a desire to schedule delivery during the night, when there is less network traffic. At other times, the desire is to receive the data almost immediately. However, at all times the entire ?file? or piece of data needs to be received to be complete. Strict reliability is the rule; for example, if any bit of a software image is lost, the data is worthless. Message streaming and bulk data application scaling requirements span the gamut from tens to possibly even millions. Reliable multicast transport protocols, in contrast to multimedia streaming transport protocols, have not yet been standardized. However, numerous reliable multicast protocols exist; some have been used only for research, while others have been commercialized. The Reliable Multicast Research Group (RMRG) in the Internet Research Task Force (IRTF) is now studying reliable multicast. It is chartered to recommend techniques for a working group in the Internet Engineering Task Force (IETF) to create a set of reliable multicast standards. Standardization Effort The standardization effort has been started in an IRTF research group to study the problems and possible solutions by Internet researchers. This effort was first placed in the hands of researchers because the problems were considered very difficult to solve in the global Internet. Some of the concerns about reliable multicast were discussed in an expired Internet Draft published in November 1996 by the Transport Area Directors of IETF. These concerns formed the basis for the work of the RMRG, which was formed in early 1997. The concerns from that document follow: ?A particular concern for the IETF (and a dominant concern for the Transport Services Area) is the impact of reliable multicast traffic on other traffic in the Internet in times of congestion (more specifially, the effect of reliable multicast traffic on competing TCP traffic). The success of the Internet relies on the fact that best-effort traffic responds to congestion on a link (as currently indicated by packet drops) by reducing the load presented on that link. Congestion collapse in today?s Internet is prevented only by the congestion control mechanism in TCP. There are a number of reasons to be particularly attentive to the con-gestion- related issues raised by reliable multicast proposals. Multicast applications in general have the potential to do more congestion-related damage to the Internet than do unicast applications. This is because a single multicast flow can be distributed along a large, glo-bal multicast tree reaching throughout the entire Internet. Further, reliable multicast applications have the potential to do more congestion-related damage than do unreliable multicast applications. First, unreliable multicast applications such as audio and video are, at the moment, usually accompanied by a person at the receiving end, and people typically unsubscribe from a multicast group if congestion is so heavy that the audio or video stream is unintelligible. Reliable multicast applications such as group file transfer applications, on the other hand, are likely to be between computers, with no humans in attendance monitoring

congestion levels. In addition, reliable multicast applications do not necessarily have the natural time limitations typical of current unreliable multicast applications. For a file transfer application, for example, the data transfer might continue until all of the data is transferred to all of the intended receivers, resulting in a potentially-unlimited duration for an individual flow. Reliable multicast applications also have to contend with a potential explosion of control traffic (e.g., ACKs, NAKs, status messages), and with control traffic issues in general that may be more complex than for unreliable multicast traffic. The design of congestion control mechanisms for reliable multicast for large multicast groups is currently an area of active research. The challenge to the IETF is to encourage research and implementations of reliable multicast, and to enable the needs of applications for reliable multicast to be met as expeditiously as possible, while at the same time protecting the Internet from the congestion disaster or collapse that could result from the widespread use of applications with inappropriate reliable multicast mechanisms. Because of the setbacks and costs that could result from the widespread deployment of reliable multicast with inadequate congestion control, the IETF must exercise care in the standardization of a reliable multicast protocol that might see widespread use.? One of the statements in this document is very specious: ?First, unreliable multicast applications such as audio and video are, at the moment, usually accompanied by a person at the receiving end, and people typically unsubscribe from a multicast group if con-gestion is so heavy that the audio or video stream is unintelligible. Reliable multicast applications such as group file transfer applications, on the other hand, are likely to be between computers, with no humans in attendance monitoring congestion levels.? This statement is a very weak argument; it is not reliable to depend on a human to turn off a nonfunctioning event. Do we typically turn off the television when we leave the house? Or leave the room to do something else? In contrast, some of the reliable multicast protocols such as the Multicast File Transfer Protocol (MFTP) have the sense of a finite session, and automatically time out and leave a group, even if all group members did not receive all the content. Essentially what is desired is a reliable multicast protocol that behaves like TCP in that it backs off in the face of congestion approximately the same way as TCP and shares the bandwidth with TCP traffic ?fairly.? This feature is of prime importance to Internet researchers who wish to specify protocols that can scale to the global Internet and not cause harm to the traffic already present. Two additional significant problems need to be solved: scalability and the ability to operate with scalability over many different network infrastructures. Scaling Issues and How Current Reliable Multicast Protocols Solve Them Two primary issues are related to scaling, that is, the ability to handle large groups. The first and most significant is widely known as acknowledgment/negative acknowledgment (ACK/NAK) implosion. As the number of receivers grows, the amount of back traffic to the sender eventually overwhelms its capacity to handle them. Additionally, the network at the sender site becomes congested from the cumulative

back traffic from the receivers. The second issue is one of retransmissions (often referred to as ?repairs?). If the packet loss is uncorrelated at the receivers, retrans-missions grow, so the data may need to be sent multiple times to satisfy all the receivers. Measurements of the Multicast backbone (Mbone) have shown that loss consists of both correlated and uncor-related parts [4] . Satellite networks will also exhibit mostly uncorrelated loss, unless receivers are geographically close. Various methods have been used to achieve scaling by reducing the amount of ACK/NAK administrative traffic while still retaining reliability. A straightforward approach is to simply deploy repeaters/ aggregators in the network, as shown in Figure 5. This approach is provided by the Reliable Multicast Transport Protocol (RMTP) [5] . RMTP provides for designated receivers (DRs) that collect status messages from nodes in a local RMTP domain and provide repairs (retransmissions of missing data), if available. Receivers direct the administrative messages to the DR by unicast. Thus, the DR provides both local recovery and consolidation of control traffic to the next DR in the hierarchy if the data requested is not available. Figure 5: RMTP Designated Receivers

(Click on image to enlarge.) A second approach is to allow any receiver to provide the repair, biasing the request to the nearest

receiver that has the requested data. This approach, called Scalable Reliable Multicast (SRM) [6] , depends on the concept of repair by any receiver that has the data to gain scalability in reducing administrative back traffic to the source, putting the onus of responsibility on receivers to ensure that they get missed data. Group members in SRM send low-frequency session messages to the group so that their neighbors can learn their status, measure the delay among group members and learn group membership, and detect the last packet in a burst. Session messages are designed to take only about five percent of the traffic in the session. Receivers with missing data wait a random time period before issuing repair requests, allowing suppression of duplicate requests similar to the mechanism that IGMP uses on its subnet. A similar process occurs for making the actual repairs. The random backoff time for both repair requests made by receivers and repairs made by senders is a function of ?closeness? to the sender and requesting receiver. Thus, those closest to each other time out first and make the repair request or the actual repair in an attempt to keep repairs as local as possible. A receiver that sees the first request and determines that it is the same request that it would have made simply stays silent, reducing potential redundant requests. The requester continues to send repair requests until the repair is received. Any receiver may satisfy the repair request, because all receivers are required to cache previously sent data. Any receiver that can satisfy the request is prepared to do so; a random backoff timer is used before a repair is sent, and if it sees the repair being sent by another group member, it stays silent to reduce the probability of sending duplicate repairs. SRM was first developed to be the reliable multicast protocol to operate with the wb whiteboard data conferencing tool developed by Lawrence Berkeley Labs (LBL) researchers, SRM is currently operational over the Mbone, the experimental multicast network of the Internet. A third approach is to have the network infrastructure, that is, routers, help in providing scaling. This approach, called Pretty Good Multicast (PGM) [7] , is a new proposal that was first publicly presented to the RMRG meeting held in February 1998. One design goal of the creators of PGM was simplicity and the ability to optimally leverage routers in the network to provide scalability. PGM is an example of a protocol that bypasses UDP and interfaces directly to IP via ?raw? sockets, as shown in Figure 6.

Figure 6: PGM Interfaces Directly to IP

(Click on image to enlarge.) PGM provides no notion of group membership; it simply provides reliability within a source?s transmit window from the time a receiver joins a group until it departs. PGM has only a few data packets that are defined: ODATA: original content data NAK: selective negative acknowledgment NCF: NAK confirmation RDATA: retransmission (repair) SPM: source path message Each PGM packet contains a Transport Session Identifier (TSI) to identify the session and source of that data, so multiple sessions may be easily identified by PGM-aware routers and receivers. ODATA, NCF, RDATA, and SPM packets flow downstream in the distribution tree, and NAK packets flow upstream toward the source. PGM is designed for scalability as well as the ability to serve real-time applications. Thus there is a need for timeliness. This need is handled by the transmit window, which defines a sliding window of data such that if no NAKs are received by the sender or a designated local retransmitter by the time the window is up, the data is simply not available for repairs. PGM is totally NAK based, so the scaling issue is to reduce the number of NAKs sent back to the source, while at the same time protecting against lost NAKs. Enter here the router assist, as shown in Figure 7.

Figure 7: PGM NAK/NCF Dialog

(Click on image to enlarge.) NAKs are unicast from PGM-router to PGM-router, initiated by the receiver that lost data sending a NAK to its nearest PGM-aware router. Each PGM-aware router keeps forwarding NAKs until it sees an NCF or RDATA, which indicates that a repair is being sent. NAK suppres- sion is provided by a receiver?s subnet PGM-aware router, and all PGM-aware routers eliminate duplicate NAKs all the way upstream to the source. The unicast path back to the source must be the same path as the downstream multicast tree. SPMs are sent downstream interleaved with ODATA packets to establish a source path state for a given source and session. PGM-aware routers use this information to determine the unicast path back to the source for forwarding NAKs. SPMs also alert receivers that the oldest data in the transmit window is about to be retired from the window and will thus no longer be available for repairs from the source. SPMs are sent by a source at a rate that is at least the rate at which the transmit window is advanced. This rate provokes ?last call? NAKs from receivers and updates the receive window state at receivers. PGM-aware routers also keep state on where the NAKs come from in the distribution tree so that they may constrain the forwarding of RDATA repairs to only those ports from which NAKs requesting that repair were received. This scenario eliminates the transmission of repair data to parts of the distribution tree where the repair is not needed. The PGM feature can also optionally redirect NAKs to a designated local retransmitter (DLR) rather than the source. A DLR announces its presence to provoke the redirection of NAKs for that session and source. A fourth approach is to not have a low-latency requirement (that is, only serve ?bulk data? delivery applications) and use this feature to advantage to gain scalability. MFTP was first published as an Internet Draft in February 1997, and an update was submitted in April 1998 [8] .

MFTP also has a provision for sender-based group creation, with different group models, and the group setup protocol to notify receivers to join the group. Group creation is discussed later in this article. The basic MFTP protocol breaks the data entity to be sent into maximum size ?blocks,? where a block by default consists of thousands or tens of thousands of packets, depending on packet size used. This setup is shown in Figure 8. Figure 8: MFTP Blocks

(Click on image to enlarge.) MFTP is a NAK-only protocol; that is, if data is received correctly in a block, nothing is sent back to the sender. If one or more packets are in error or missing in a block, receivers respond with a NAK that consists of a bit map of the bad packets in the block. It is thus a selective reject mechanism. In this respect, MFTP is similar to RMTP; the main difference is that MFTP explicitly attempts to make the block as large as possible for scaling purposes. NAKs are normally sent unicast back to the source, unless aggregation to improve scaling using enabled network routers is used. In this case, the NAKs are sent multicast to a special administrative traffic group address. MFTP does not repair after each block, however; it takes advantage of the non-real time nature of the application for benefit. The data entity, such as a file, is sent initially in its entirety in a first pass . The sender collects the NAK packets for a block from all the receivers. One NAK packet from a receiver can represent thousands or even tens of thousands of bad packets, reducing NAK implosion by orders of magnitudes. The collection of NAKs received by the sender from all the receivers is logically OR-ed together to represent the collective need for repairs for the receiving group. These repairs are sent by the sender in a second pass to the group. If certain receivers already have the repair, it is simply ignored. This scenario is repeated, if necessary, until all repairs are received by all receivers or until a configurable timeout occurs. Thus, packet ordering services are not provided, and holes in the data caused by dropped packets or packets in error are filled in as they are received. The sender is rate based ; in other words, it transmits at a data rate set by the operator to be less than or equal to what the network can handle. The protocol is thus very efficient with high-latency networks such as satellites, and it is impervious to network asymmetry. It also attempts to be as scalable as possible on one-hop networks such as satellite networks, and it provides for extensions so that network elements may aggregate downstream responses to increase scalability further, depending on the network configuration.

This aggregation capability is shown in Figure 9. The network element, which can be a router, collects MFTP administrative back traffic routers are members. These routers aggregate back traffic from all nodes downstream in the multicast tree from the source, including registrations, NAKs, and dones. Registration and done messages are used by MFTPs group setup protocol, and they are described later in this article. Depending on the network configuration, this aggregation capability can further improve the scalability of MFTP by orders of magnitudes. Figure 9: Routers as Network Aggregators

(Click on image to enlarge.) The upper limit to scalability with no network aggregation of administrative traffic is in the tens of thousands of receivers. For example, for a Maximum Transmission Unit (MTU) of 1500 bytes (the Ethernet maximum), the default block size is over 11,000 packets. If the number of receivers is 10,000 and each receiver has at least one bad packet per block, then there will be a total of 10,000 NAK packets coming back to the sender from the group about that block, approximately the same number of packets as were sent in the forward direction in that block. MFTP provides for a NAK backoff timer to spread the NAKs out in time to the sender to avoid bursts. If the bandwidth is symmetric at the sender, the sender should be able to handle this maximum NAK. In many situations, the amount of back traffic could exceed forward traffic. MFTP also has provision for a crude congestion control mechanism. The sender at the beginning of a session sends announce messages. These messages are used for many functions, including the setting up of groups. Additionally, it conveys a packet loss parameter to all receivers. This packet loss threshold parameter may be used by receivers to leave the group if the packet loss exceeds the threshold. Leaving the group prunes the distribution tree, relieving the congestion in that section of the tree. Commercial Usage

The reliable multicast protocols previously discussed are the most prominent ones on the market today. RMTP has been deployed in its message streaming version for a billing record distribution application within a very large telecommunications carrier, but it has had generally limited deployment. It also does not scale over satellite networks, where most of the early multicast deployments reside. SRM has been used by the research community only over the Mbone, and it is still being refined. Another problem with SRM is that in its current incarnation, it supports neither asymmetric nor satellite networks. Some early Internet Service Provider (ISP) multicast implementations, offer multicast support in only one direction; SRM requires total multicast support. PGM is new and offers promise, but there is no deployment yet, and it likely will not occur until early 1999. PGM also requires router support in a terrestrial land-line network to gain scaling. MFTP has the limitation that it supports only bulk transfer applications. However, one trade-off is that it can support all network infrastructures, including satellite infrastructures with scaling. MFTP has also been available commercially in products with the longest application support, dating back to 1995. Thus, MFTP-based products have the largest installed base of any reliable multicast-based product being used over WANs. The largest commercial installation of over 8,500 remote sites in the group is the General Motors[9] dealer network. Several other commercial installations of MFTP-based applications number over 1,000 group members. Advanced Research Topics Discussed in Reliable Multicast Research Group A promising technique to reduce the amount of repair data that needs to be retransmitted is called erasure correction . This technique can significantly reduce the amount of repairs that need to be resent if the packet loss is largely uncorrelated at the receivers. It uses a forward error correction (FEC) code to generate parity packets to be used for repairs only. This setup provides benefit if errors at receivers are uncorrelated. For example, suppose 16 receivers each have one missing packet, but they are all different. Rather than send all 16 original data packets, one FEC packet could be sent that could correct the one missing packet at all 16 receivers, requiring retransmission of only one packet rather than 16. If the loss is correlated, then many of the receivers lose the same data, and erasure correction is of no benefit. However, there is also no penalty, except for the need for computing power at both the sender and the receivers to perform the FEC correction calculations. Simulations have show[10] that there is a greater than 2:1 reduction in the number of repairs needed to be sent with our example of 10,000 receivers. This benefit will be even larger when group sizes become larger than tens of thousands. Perhaps a more significant application for FEC is a congestion control technique known as layering [11,12]. With layering, numerous groups are set up by the sender, all with different rates. Receivers that can receive at the highest rate join all the layer groups. Those receivers that cannot receive at the highest rate simply leave layers until congestion is relieved, and they take longer to receive the data. For this to work without sending data redundantly, the number of parity packets created must be very large compared to the number of data packets.

There are some further issues that have been pointed out by the researchers with the Other issues with the layering approaches have been pointed out by the researchers, however. For layering to be effective, the routing tree should be identical for the different groups; otherwise congestion will not be relieved on a part of the tree. This may not always be the case, especially in sparse mode routing protocols, where selection of the rendezvous point or core is based on group address. Even if the same distribution tree is used for the different layers, it has been pointed out[12] that leaves of hosts downstream from a congested link should be coordinated; otherwise the action of less than all of them has no effect on congestion. Additionally, a receiver could cause congestion by adding a layer that another receiver could interpret as congestion, causing it to drop a layer with no effect. Thus, layering using FEC techniques is an interesting technique that shows promise for use in congestion control. However, there are issues associated with this type of layering that researchers still need to address. Another technique that has been proposed for congestion control is bulk feedback to the sender[13]. If the sender receives an excessive number of NAKs from receivers, it drops the senders transmission rate with an algorithm that attempts to emulate the behavior of TCP. This approach is an obvious one because it is an extension of the process in which TCP falls back in the face of congestion. This approach, however, has two basic problems. The first is that there is delay, because the sender needs to get feedback from the multitude of receivers before it acts. This delay can be considerably longer than in the case of TCP, which needs feedback from only one receiver. The second flaw is that one errant receiver can effectively penalize the whole group, because the sender reduces the rate to the total group. This approach is not viewed as a viable solution for these reasons. In fact, the general consensus is that congestion control decision making will be required at the multiple receivers rather than at the sender for both scaling and timeliness reasons. Another idea that is now receiving intense study by researchers is that of subcasting [14,15,16]. The key idea in subcasting is to optimize local repair to be a retransmitter that may be just above a link congestion point, as shown in Figure 10. The problem is to gain knowledge of the network topology so as to locate a receiving host that is willing to retransmit and that has the repair data. Then the repairs need to be contained within only the region of the network that lost the original transmission, that is, the subcast region.

Figure 10: Optimized Local Repair

(Click on image to enlarge.) One proposal is to ask for assistance from the network routers. They know the topology and could be used to find the closest willing retransmitter that has the repair. The router could also direct the repair to only the affected region: the subcast . This technique can be viewed as an extension of concepts originally proposed in SRM to provide local recovery. It assumes that most loss is caused by congested links, and that uncorrelated loss is caused by a series of mildly congested links with few group members. This model is probably the right one for many land-line routed networks; it is problematical with other network infrastructures. Nevertheless, it is an interesting proposal that merits further research effort. Local repair is destined to be an important tool to meet the goal of improved scalability with minimal traffic overhead. Group Creation and Destruction The process of joining a group and leaving a group in IP multicast is left to a potential group member that uses IGMP to notify the nearest multicast router of its membership state. However, mechanisms need to be in place to allow potential members of a group to gain the information needed to decide to join the group. There are two basic ways to accomplish this scenario for one-tomany sessions. The first and most common is the broadcast TV model. The Multiparty Multimedia Session Control (MMUSIC) working group of the IETF has developed some protocols that can be used to advertise content. The Session Announcement Protocol (SAP) [17] provides the mechanism to send a stream on a

wellknown multicast address to announce content to any potential listeners who may be interested. It uses the Session Description Protocol (SDP) [18] to describe the contents that are announced. These two protocols together have been used to create a session directory tool that is available on the Mbone. This setup creates essentially the equivalent of a preview channel such as is often available on cable television systems. SDP is also used to post content on Web sites, which advertise that content to anyone who wishes to receive it. Although these protocols were originally developed primarily to advertise multimedia streaming applications, they are also applicable for data. They provide a useful tool for push vendors to advertise multicast channels based on content that any consumer can tune in to. Internet researchers describe this model as providing loosely coupled sessions, because the sender does not know who is listening, much like radio or TV broadcasters do not know who tunes in to their stations. MFTP also includes a group setup protocol. The closed group option in MFTP provides a mechanism to create a tightly coupled session that is very useful to organizations that wish to deliver critical information from a central site to many remote branch offices. The closed group provides a means for the sender to define a group list centrally and direct those members so defined to join the group. This scenario is somewhat similar to e-mail, except more robust. These instructions are sent in an announce message on a special multicast group address that the superset of possible candidate receivers always listens to. Hosts so directed to join the group notify their designated multicast router of their membership directed to join the group notify their designated multicast router of their membership using IGMP and register back to the sender of their presence. Thus, the sender knows group membership before transmission commences, and the sender can then also positively confirm delivery. This approach has proven very desirable for organizations that have many branches where information is desired to be sent at the discretion and time determined by the and desire to send information at the discretion and time determined by the sender, and usually the information is delivered to a branch office server. Several deployments of applications that use MFTP and the closed group model with group members approaching 10,000 exist. The MMUSIC group has also created the Session Invitation Protocol (SIP) [19], which is used to invite members to a conference of some sort, including possibly a data conference. This protocol is appropriate for use with whiteboard applications, for example. Summary and Conclusions

Although multicast has often been viewed as synonymous with multimedia, there is a wide spectrum of reliable multicast applications that involve the transfer of data to multiple group members. Because this wide spectrum of applications has many different requirements, as shown in Figure 4, no one reliable multicast protocol can handle all applications and network infrastructures. The result is that numerous reliable multicast protocols are likely to become standardized, and today numerous reliable multicast protocols are either in commercial products/toolkits or due to be available soon. The reliable multicast standardization effort now resides in the IRTF, because Internet researchers are concerned about congestion control and fairness to TCP for any protocols that might become standardized for general Internet use. This problem is difficult to solve, given the disparate requirements placed on protocols by the wide variety of applications and different network infrastructures. Nevertheless, a significant number of reliable multicast-based product deployments have already occurred over private networks. These have been shown to save organizations much money and to help create new business opportunities for them. Stay tuned; reliable multicast-based applications are ready to be mainstreamed. Together with multimedia multicast applications, multicast applications of all forms will become common soon, first in private intranets and extranets and then in the Internet as a whole. References [1] Deering, S. Host Extensions for IP Multicasting. RFC 1112, August 1989. [2] Fenner, W. Internet Group Management Protocol, Version 2. RFC 2236, November 1997. [3] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V. RTP: A Transport Protocol for Real-Time Applications. RFC 1889, January 1996. [4] Handley, M. An Examination of Mbone Performance. ISI Report, January 10, 1997. [5] Paul, S., Sabnani, K. K., Lin, J. C., and Bhattacharyya, S. Reliable Multicast Transport Protocol (RMTP). IEEE Journal on Selected Areas in Communications , April 1997. [6] Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang, L. A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing. ACM Transactions on Networking , November 1996. [7] Farinacci, D., Lin, A., Speakman, T., and Tweedly, A. PGM Reliable Transport Protocol Specification. Work in progress, Internet Draft, draft-speakman-pgm-spec-01.txt , January 29,

1998. [8] Miller, K., Robertson, K., Tweedly, A., and White, M. StarBurst Multicast File Transfer Protocol (MFTP) Specification. Work in progress, Internet Draft, draft-miller-mftp-spec-03.txt , April 1998. [9] Miller, K. Reliable Multicast Protocols: A Practical View. 22nd Conference on Local Computer Networks, November 1997. [10] Kasera, S. K., Kurose, J., Towsley, D., Scalable Reliable Multicast Using Multiple Multicast Groups. CMPSCI Technical Report TR 96-73, October 1996. [11] Nonnenmacher, J., and Biersack, E. W. Asynchronous Multicast Push: AMP. Proceedings of ICCC 97 International Conference on Computer Communications, Cannes, France, November 1997. [12] Crowcroft, J., Rizzo, L., and Vicisano, L. TCP-Like Congestion Control for Layered Multicast Data Transfer. Submitted to INFOCOM 98, August 1997. [13] Sano, T., Yamanouchi, N., et al. Flow and Congestion Control for Bulk Reliable Multicast Protocolstoward coexistence with TCP. Submitted to INFOCOM 98, presented at RMRG meeting in Cannes, France, September 1997. [14] Hofmann, M. Enabling Group Communication in Global Networks. Proceedings of Global Networking 97, June 1997. [15] Papadopoulos, C., Parulkar, G., and Varghese, G. An Error Control Scheme for Large-Scale Multicast Applications. Submitted to INFOCOM 98, presented at RMRG meeting in Cannes, France, September 1997. [16] Levine, B. N., Paul, S., and Garcia-Luna-Aceves, J. J. Deterministic Organization of Multicast Receivers Based on Packet Loss Correlation. Presented at RMRG meeting in Orlando, Fla., February 1998, submitted for publication. [17] Handley, M. SAP: Session Announcement Protocol. Work in progress, Internet Draft, draftietf-mmusic-sap-00.txt , November 1996. [18] Handley, M., and Jacobson, V. SDP: Session Description Protocol. Work in progress, Internet Draft, draft-ietf-mmusic-sdp-07.txt , April 1998. [19] Handley, M., Schulzrinne, H., and Schooler, E. SIP: Session Invitation Protocol. Work in

progress, Internet Draft, draft-ietf-mmusicsip-04.txt , November 1997. (This article is based in part on material in the book Multicast Networking and Applications written by C. Kenneth Miller to be published by Addison Wesley Longman, Inc. in 1998. ISBN 0-20130979-3. Used with permission.) C. KENNETH MILLER is the founder, Chairman, and Chief Technology Officer of StarBurst Communications. StarBurst Communications provides reliable multicast solutions for commercial applications with such corporate customers as GM, Ford, Chrysler, Toys R Us, Thomson Financial, and many others. Miller has been in the data communications industry since 1972. He founded Concord Data Systems in late 1980 and served as its President and CEO until 1986. Concord Data Systems produced high-speed dial modems. He was the author of the IEEE 802.4 LAN standard, which became the lower layer for the Manufacturing Automation Protocol (MAP) factory LAN standard. Miller was a regular columnist in Data Communications Magazine from 1992 to 1994. He has also published numerous articles and participated in many panels at trade show and other industry events. He is now writing a book entitled Multicast Networking and Applications , to be published in 1998 by Addison-Wesley. Miller received a BEE degree from Rensselaer Polytechnic Institute and a MSEE degree from the University of Pennsylvania, specializing in communications. Miller can be reached at [email protected]