Multicast Communications in Next-Generation Internet

Copyright © IFAC Large Scale Systems: Theory and Applications, Osaka, Japan, 2004

ELSEVIER

IFAC PUBLICATIONS www.elsevieLcomllocatelifac

MULTICAST COMMUNICATIONS IN NEXT-GENERATION INTERNET Miki Yarnamoto·

• Gmduate School uf Enginee1ing, Osaka Univc7'S'ity, S1J:ita-shi, 565-0871 Japan

Abstract: Multicast communications have been expected as an effective way to disseminate inforlllation to potentially large nUllIber of receivers. IP mult.i cast. is a well- known multicast protocol for the Intemet.. However, IP multicast has several technical problems to be resolved until it is widely deployed. These includes service-model of lllulticast group, reliable transport protocol, congestion cont.rol and security. Lots of researches trying to resolve these teclmical problems make multicast comlllunications a hot research area in these couple of decades. This paper overviews the present style of IP multicast and c1earlify technical issues of it. The paper also surveys important approaches t.o t.hese problems and discuss about future directions of multicast conlHlUnications. Copyr'ight ©2004 [FA C Keywut Js: mlliticast, IP mlllt.icast. , deployment.

1. INTRODUCTION

to an int.erface below which there are receivers . Multicast is scalable in the following two points. One is reducing packet-transmission overhead at the source because only one data packet is necessary to be sent by the source. The other is reducing redundant bandwidth wasted by transmission of the multiple same packets on a link .

In the next-generation Intemet, a conllnunication model of point-t.o-multipoint or multipointto-multipoint is very promising because dissemination of the same data to potentially large number of receivers is now becoming an attractive application. These applications include teleconference, real-time information (voice or image , or both) distribution and file distribution. This type of comlllunication model is called multicast.

IP Illulticast (Deering 1989; Deering and Cheriton 1990) is the first communication protocol supporting network layer multicast. In IP lI1ulticast., the concept of lI1ulticast group is introduced for supporting lI1ulticast service. One mult.icast. addrt'ss chosen frolll a class D block of JP address is assigned t.o a lllulticast group. When a source would like to send a datagram to multiple receiven; in a lI1ulticast group , the only thing the source should do is to send a dat.agram to t.his a.ssigned multicast address. Group membership is managed by routers inside a network and this datagralll sent by the source is forwarded to one or 1Il0re interfaces of a router below which there are receivers by making a replication at an adequate router( a router locat.ed at. a branching point).

There can be several ways to implement a point.to-multipoint communication lIlodel J in a network layer . The easiest way is to use lIlult.iple point-to-point cOllllnunications(Fig.1(a)). In t.his case, the same data is transmit.t.ed mult.iple times redundalltly on a link . The Illost cost-t'tfective way is multicast(Fig.1(b)) . In multicast., only onc packet is transmitted on each link . A data packet is replicated at an adequate rout.er and fOlwarded I A multipoint-to-n ... itipoint model can be imple me nted as superposition of multiple point-to-lIlultipoint ones. So, we focus on a point-to-multipo int model here.

621

please see section 2.3). After a distributed tree is established , a datagram of a corresponding multieast group arrives at an edge router and this edge router transmits a datagram to all interested receivers below it by using multi cast in LAN . The sender has no necessity to manage receivers. It only has to send a datagram to an aiming multicast group.

Receiver

(a) Multiple point-to-point

(b) M ulticast

In IP multieast , membership model is frat , i.e. no identification of the sender and receivers. All members of a multicast group can send a datagram to other members. This means all members can be a sender of a multicast datagram . Even a host of non-member of a multicast group can send a datagram to a multieast group , i.e. all members of a multicast group.

Fig. 1. Point-to-multipoint communications Almost routers available today have capability of handling IP multicast . However , only few ISPs(Internet Service Providers) support IP mulbeast and almost ISPs inactivate IP multicast intentionally (Diot et al., 2(00) due to several technical issues. These issues include a service model , reliable multicast, congestion control and security in multicast. In the paper, we would like to focus on the issues of reliable multicast and congestion control, and survey important research approaches.

2.2IGMP Multicast routing has three-tier structure, clientto-edge router, intra-domain routing and interdomain routing, as shown in Fig.2. For intradomain and inter-domain routing, we would like to discuss in detail in the following section. For client-to-edge router, IGMP(Internet Group Management Protocol) (Fenner, 1997) is used. When there are one or more hosts having an interest of receiving datagrams of a multieast group in a local network, an edge router attached to this local network forwards a datagram of a corresponding multicast group to a local network in a style of local multicast . Thus, an edge router has no necessity of having information of all interested hosts, but has to know about whether there is at least one host in a physically attached local network.

The paper is structured as follows. Section 2 presents current status of IP multi cast and discusses about deployment issues of it. In section 3, reliable multi cast is highlighted and retransmission control is picked up as a focused issue. In section 4, congestion control is treated and coexistence of muIticast traffic and unicast traffic is important discussion here . Section 5 concludes the paper.

2. IP MULTICAST -PRESENT TECHNOLOGYIn IP multi east , the concept of multicast group is introduced to represent receivers having interest of receiving multi cast datagram. The source has no necessity to manage membership information of a corresponding multieast group. This fact shifts the burden of handling information of receivers from the source to routers on the path to receivers , which leads to scalability of IP multieast. In this section, we would like to explain about the current technology of IP multicast in detail.

An edge router running IGMP sends a query named "a membership query" to its attached local networks periodically. When there is a host having an interest of receiving a multi cast datagram, it responds to this query by sending a response named " a membership report". As described above, an edge router should keep records of exis-

•• .......•

2.1 Service Model

In IP multicast, a concept of multicast group is used for managing receivers . A receiver having an interest of receiving multicast datagram informs its interest to an edge router( see section 2.2 for details of this operation). When an edge router has one or more interested receivers of a multicast group, it establishes path to a multicast distributed tree of a correspondlllg multicast group by a multicast routing protocol(for details,

G ubnet

~

Intra-domain Routing

Inter-
Fig. 2. Hierarchical structure of multicast routing

622

domain routing, which include BG~IP(Kumar et al., 1998). However, Inter-domain routing in IP multieast is remained research issues.

an edge router may receive lots of membership reports. To avoid this situation of concentration of membership reports , when a host receives a query, it sets random delay timer for each multicast group . When a timer expires without receiving another report for a corresponding multicast group, a host sends a membership report to an edge router. This report is multicast to a local network, so other members of a multicast group reveive it. When a host receives a membership report of a corresponding multi cast group before its timer expiration, this host quits sending a membership report . This operation reduces the number of generated reports for each multicast group, which leads to scalability. When a host would like to leave a multieast group, it only acts as not sending a response when it receives a query.

2.4 Deployment Issues

Several papers are discussing the deployment issues of IP multicast(Diot et al.20(0)(Almeroth 20(0) . They list the following issues for deployment of IP multicast .

• Motivation to Deployment of IP Multicast For the source and receivers, there cannot be seen any advantages for deployment of IP multicast. For them, the fact that the same data is arrived to expected receivers is very important and they do not care about how data is transmitted inside a network. • Poor Contents In MBone, no attractive contents have been served. Popular applications in MBone are real-time broad east service of IETF meeting, NASA events and some audio distribution. • Service Model The concept of multicast group gives scalability to network-layer multicasting but is not suitable for business model of multi casting. For example, the source cannot identify receivers of its providing contents. This prevents the source to collect fee for providing contents.

2.3 Routing Routing in the Internet can be divided into two categories, intra-domain routing and inter-domain routing. This is also the case for multicast routing. In this section, we would like to explain about current status of IP multicast routing in these two categories.

[Intra-domain routing] In multicast communications, routing protocols generally make a tree-shaped path. Multicast routing protocols can be categorized into two categories by the shape of generated distribution tree . One is a protocol using a source-based tree and the other is a protocol using a shared tree. A source-based tree is constructed by making the source as a root of the tree and interested hosts as leaves. In a source-based tree protocol , a multicast distribution tee is made for each source when a multieast group has multiple sources. DVMRP(Distance Vector Multicast Routing Protocol)(Waitzmann et al., 1997), PIM-DM(Protocol Independent Multicasting-Dense Mode)(Deering et al.1999) and MOSPF(Multieast OSPF)(Moy 1994) are examples of a source-based tree protocol. In a shared-tree approach , a shared-tree is constructed and multicast groups share this tree to distribute their data . PIM-SM(PIM Sparse Mode)(Fenller et al. 2002) and CBT(Core Based Tree)(Balladie et al. 1995) are categorized to a protocol of a shared-tree approach.

In the paper, we would like to survey attractive research results for future multicast communications, in the following sections. These researches are trying to address these issues. Due to lack of space, we especially focus on reliable multicast and congestion control, which will resolve the first and second issues listed above.

3. RELIABLE MULTICAST JP multicast is based on best-effort communication and in IP multieast UDP is generally used for a transport protocol. So, no function for supporting reliability, such as retransmission control and congestion control, is implemented in IP multieast. This feature regulates applications of IP multicast to real-time one. When reliability is supported on IP multieast , new type of applications can emerge and encourage deployment of IP mu 1tieast. These promising applications include software distribution, file distribution and distribution of stock quote . In IETF, discussion of reliable multieast communication protocols which support reliability on IP multicast , started in early 1990's. Main functions necessary for reliability support are retransmission control and congestion control.

[Inter-domain Routing] Protocols described above, e.g. DV t\.I RP, MOSPF, PIM-SM and CBT are not suitable for inter-domain routing. This is because, for example, when DVMRP is applied for inter-domain, DVMRP is flooding-based approach and data is flooded to all routers in the Internet-wide area . There have been several proposals for inter-

623

Even though a NAK-based protocol has better scalability than an ACK-based one, NAK implosion may cause performance degradation when multicast group size is large. To resolve this implosion problem , several approaches have been proposed. SRM(Scalable Reliable Multicast)(Floyd et al.1997) applies a timer-based approach . Whenever a receiver detects a packet loss , it schedules a pending NAK transmission at a randomly chosen point of time in the future . If the receiver receives a NAK generated by another receiver , it cancels its NAK transmission. This mechanism is called NAK suppression. When a timer expires without receiving a NAK from other receivers , the receiver multicast a NAK . With this NAK suppression mechanism , the number of generated NAKs is significantly reduced(Yamamoto et al. 1997) , which brings good scalability. For this timer approach, several papers have discussed about how to decide a timer length (Grossglauser1996; Nonenmacher and Biersack 1998a) . Another approach for resolving NAK implosion is local recovery. In local recovery approach, a receiver receiving a packet correctly initiates retransmission. Nonnenmacher et al. (1998b) compare sender-based error recovery (they call centralized error recovery in the paper) and local recovery(distributed error recovery) and show that local recovery outperforms sender-based error recovery from the viewpoint of average delay and bandwidth consumption. Performance comparison also shows that local recovery with parity retransmission(see description of FEC below) gives better performance than local recovery with ARQ. Kasera et al. (1998) compare two approaches of local recovery, server-based and receiver-based , and shows server-based approach where designated servers initiating retransmission are located in the network has better performance . In local recovery, configuration of groups among whose members local recovery is tried, is very important. This group configuration Issues are discussed in (Yamamoto et al. 2000a) .

ACK-based Using feedback

NAK-based FEC+ Feedback

Without feedback

FEC

Fig. 3. Retransmission control for reliable multicast 'vVe devote the next section for discussion about congestion control including not only reliable multicast but also real-time multicast . In this section, we focus on retransmission control issues . There are two approaches for retransmission control. using feedback information and without it (Fig.3) . For a feedback approach , retransmission control can be categorized into the following three , ACK-based , NAK-based and FEC+feedback. In the early stage of reliable multicast research , applicability of an ACK-based protocol and a NAK-based protocol was discussed. In point-topoint communications, burden for the source and the receiver is almost the same. However, in multicast communications, the burden for the sender is high because all feedback information concentrates to the sender. This concentration of feedback at the sender may cause performance degradation, which is called feedback implosion. For an ACK-based approach, all receivers send an ACK to the source, so ACK implosion is a serious problem. Paul et al.(1997) propose a hierarchical approach, RMTP(Reliable Multicast Transport Protocol), to resolve ACK implosion problem. In RMTP, some special nodes called DR(Designated .Receiver) are located on the path of a multicast distribution tree. This DR manages some receivers in its downstream direction. A DR aggregates ACKs from these receivers and forwards only one ACK to the source(or to neigh boring DR in its upward direction). Aggregation mechanism decreases the number of arrived ACKs to the source, which brings scalability to RMTP.

The third approach for retransmission using feedback information is FEC+feedback. Conventionally, FEC technology is applied for recovery caused bit error in telecommunication field . Rizzo(1997) shows FEC technology can be applied to recovery of emsure, missing packets in a stream, in reliable multicast. He also shows a coding method using Vandermonde matrix whose computation time for coding is short enough for practical use . FEC t~chnology introduces redundant packets for error recovery to be distributed to members , which may lead to bandwidth consumption. So, location where FEC is applied is very important problem. Nonnenmacher and Biersack (1996) discuss where to use FEC technology. Noguchi et al. (2001) claim FEC to be applied at links close to the source. Packet loss pr ob-

For a NAK-based approach, only receivers suffering packet loss send a N AK to the source, so the number of feedback packets should be smaller than an ACK-based approach. Both approaches are mathematically analyzed and evaluated from the viewpoint of throughput performance in (Pingali et aL.1994) and from the viewpoint of delay performance in (Yamamoto et al. 1997). Performance evaluation results in these papers show that a NAK-based approach has better scalability than an ACK-based one. Simulation results in (Yamamoto et al. 2001) show that an ACKbased approach has worse scalability even though a hierarchical structure is applied .

624

4. CONGESTION CONTROL

ability on links close to the source is reported to be high(Yajnik et al.1996) and a packet loss here means almost members are suffered by this shared loss. So, they show that FEC applied locally to these links brings significant performance improvement. NOllnenmacher et al. ( 1997) propose an interesting way to recovery a lost packet in multieast com mWlicat ions . When packet loss pattern at each receiver is different , each receiver sends back the number of lost packets in a predefined block and the sender multieast this number of recovery packets, called parity packets. Each receiver can recover a block of packets when these parity packets arrives correctly.

Congestion control is an essential element of communication protocols in the Internet because the Internet is a world-wide network shared with large number of users. IP multicast does not implement congestion control because it uses UDP in the transport layer. In this section, future direction of multieast congestion control is discussed by introducing remarkable research results in this field. Multieast congestion control can be categorized into a source-based approach and a receiver-based approach. In a source-based approach, the source regulates its transmission rate by feedback information sent back from receivers. In a receiverbased approach, the source divides information into several layers and sends them in different multieast groups. A receiver-based approach, in general, uses this layered transmission.

The other way than using feedback information is FEC where only FEC is used and no feedback information is ~·lt back to the sender. Digital Fountain(Byers et al. 1998) and Feast(Gemmel et al.2000) are examples of this approach. Both of them make use of Tornado Codes with which a large file can be coded. The source repeats transmission of file and redundant packets. A receiver joins a multicast group whenever it likes and leaves when it receives enough packets necessary to recover a transmitted file .

The first receiver-based approach, RLM(Receiverdriven Layered Multicast) is proposed by McCan ne et al.(1996) . In RLM, the source has no active operation, just transmitting layered data to each multicast group. The receiver searches its optimal rate of data subscription by joining and leaving groups . When a receiver detects packet loss and quality degradation, it can learn that its subscription is too high and leaves the highest subscription group. A receiver adds groups when it experiences no congestion.

Recently, a new approach for resolving feedback implosion problem, a network support approach is widely discussed in a multieast research field. Technical background for enabling network support is active network technology(Tennenhouse and Wetherall 1.'.16; YI1Jllamoto 2001). Network support for reliable multicast includes NAK aggregation and caching. In NAK aggregation, a router on the path of feedback information(NAKs) only forwards a first-arrived NAK to the source and discards NAKs arrived later. A router marks links from which a NAK arrives. When a retransmitted packet arrives at a router, it replicates and forwards a retransmitted packet only to marked links. With this operation, the number of NAKs arrived at a source is significantly reduced and bandwidth wasted for redundant retransmission is also reduced . Another way for network support is caching. When a router receives a retransmitted packet, a router stores it in its local cache. When a retransmitted packet is also lost at a receiver, retransmission of a packet is initiated from this cache. PGM(Pragmatic General Multieast)(Speakman et al.2001) and ARM(Active Reliable Multicast)(Lehman et al. 1998) are examples of network support approach . In a network support approach, it is very important to investigate how much percentile of routers which can provide a network support function are necessary for obtaining good performance. Performance evaluation in (Yamamoto et al. 2000b) shows that a network support approach outperforms end-toend approaches v. "en 20% of routers are equipped with a network support function.

Recently, co-existence of multicast session with unicast sessions is widely discussed . In the current Internet, TCP is widely used as a congestion control. In order to prevent a multieast session from exploiting network resources, multicast congestion control should share congested resources fairly with TCP sessions. This kind of fairness issue is called TCP friendly. As a TCP friendly congestion control in a receiver-based approach , Vicisano et al.(1998) propose a layered multi cast congestion control. Transmission rate of each layer increases exponentially, for example twice . When a receiver leaves from a goup, receiving data rate decreases exponentially. This follows multiplicative decrease behavior of TCP. However, additive increase nature cannot be followed by this operation. Byers et al.(2001} propose Fine-grained Layered Multieast, where transmission rate of each layer is divided into finer grain. This enables additive increase of transmission rate by joining a one-level higher layer. For a source-based approach, loss path multiplicity problem is reported to be a serious problem(Bhattacharrya et al.1999} . When loss of the same packet is suffered at multiple receivers and transmission rate of the source is regulated by loss indications, e.g. NAKs, sent from these receivers, transmission rate of the source is too much

625

Almost activities introduced in this paper take care of scalability problem, e.g. NAK suppression in reliable multicast and a nominee approach in congestion control. These research activities will resolve technical problems of IP multicast and make multicast a real attractive communication model in the next-generation Internet.

regulated. This leads to serious degradation of throughput performance of a multicast session. To avoid loss path multiplicity problem, a nominee approach is generally applied to a source-based approach. In a source-based approach, transmission rate of the source is regulated by the receiver of the worst throughput, i.e. the receiver suffered by congestion in the network. From this observation, a nominee is selected as the receiver of the worst throughput. Rizzo(20oo) proposes pgmcc based on these ideas. In pgmcc, a nominee sends a NAK when it detects a loss of packet . In this NAK, receiver's RTT(Round Trip Time) and packet loss rate , p, is included as a feedback information. When a source receives these NAKs sent by receivers suffered by a packet loss, it elects the receiver of the worst TCP throughput as a nominee. TCP throughput(T) is reported to be simply expressed in the following form(Mathis et al.1997; Padhye et al. 1998), 1

REFERENCES Almeroth,K.(2000) . A Long-Term Analysis of Growth and Usage Patterns in the Multicast Backbone(MBone) , Proc. IEEE INFOCOM 2000, pp.824-823, Tel Aviv, Israel. Ballardie,A., P.Francis and J.Crowcroft(1995) . Core Based Trees(CBT) : An Architecture for Scalable Multicast Routing, Proc. ACM SIGCOMM'95, pp.85-95, Cambridge, MA , U.S.A. Bhattacharyya,S. , D.Towsley and J .Kurose(1999). The Loss Path Multiplicity Problem in Multicast Congestion Control, Pmc. of IEEE INFOCOM'99, pp.856-863, New York, U.S.A. Byers,J., M.Luby, M.Mitzenmacher and A.Rege (1998). A Digital Fountain Approach to Reliable Distribution of Bulk Data, Pmc. of ACM SIGCOMM'98, pp.56-67, Vancouver, Canada. Byers,J., M.Luby and M.Mitzenmacher(2001), "Fine-grained Layered Multicast," Proc. of IEEE INFOCOM 2001, pp.1l43-1151, Anchorage, U.S .A., April 2001. Deering,S.(1989) . Host Extensions for IP Multicasting, IETF RFC 1112. Deering,S., and D.Cheriton(1990) Multicast. Routing in Datagram Inter-Networks and Extended LANs, ACM Tmns. on Computer Systems, Vo1.8, No.2, pp.85-110. Deering,S., D.Estrin, D.Farinacci, V.Jacobson, A.Hehny, D.Meyer and L.Wei(1999) . Protocol Independent Multicast Version 2 Dense Mode Specification, IETF Internet Draft, draft-ietfpim-v2-dm-03.txt. Diot,C., B.Levine, B.Lyles. H.Kassem and D.Balensiefen(2000). Deployment Issues for the IP Multicast Service and Architecture, IEEE Network, Vo1.14, No.l, pp.78-88. Fenner,W.(1997). Internet Group Management Protocol, Version 2, IETF RFC 2236. and Fenller,B., M.Handley, H.Holbrook I.Kouvelas(2002). Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) ," IETF Internet Draft ,

(1)

From this equation, the worst throughput receivers can be elected as the receiver which has the highest value of KIT,;p. After selecting a nominee, an ACK-based window flow control is applied between the source and the selected receiver. Feedback implosion problem is prevented because only the selected receiver sends an ACK to the source. Kasera et al.(20oo) propose. similar congestion control. They applies active service for gathering throughput information. In their proposal, all receivers send their measured RTT and packet loss rate to the source. A server attached to a router inside a network is introduced. When this server on the path to the source receives these measured information, it only forwards information with the highest value of the product of RTT and packet loss rate, i.e. information of the worst throughput node. It has better scalability than pgmcc because only one feedback information is sent back to the source. These two proposals above apply window-based congestion control with an ACK sent back from the elected receiver, a nominee. Thus, they have TCP-friendly nature.

5. CONCLUSIONS

draft-ietf-pim-~m-v2-new-05.txt .

Multicast communication is an effective way to disseminate the same information to large number of receivers. One of the most important issues for multicast communications is scalability because multicast session includes lots of receivers. The paper surveys attractive research activities of reliable multicast and congestion control. For other interesting research activitie:; in multicast communications, please see (Yamamoto 2003).

Floyd,S., V.Jacobson, C.Liu, S.tv1cCanne and L.Zhang(1997). A Reliable r,iulticast Framework for Light-Weight Sessions and Application Level Framing, IEEE/ ACM Tmns. on Networking, Vo1.5, No.6, pp.784-803 . Gemmel,J., J .Gray and E.Schooler(2000) . Fcast Multicast File Distribution, IEEE Network, pp.58-68, Vo1.14 , No.1.

626

Grossglauser,M. (1996). Optimal Deterministic Timeouts for Reliable Scalable Multicast, Proc. of IEEE INFOCOM'96, pp.1425-1432, San Francisco, U.S.A. Kasera ,S., S.Bhattacharyya, M.Keaton , D.Kiwior, J.Kurose, D.Towsley and S.Zabele(2000) . Scalable Fair Reliable Multicast Using Active Services, IEEE Network, Vo1.l4, No.1, pp.48-57. Kasera,S ., J .Kurose and D.Towsley(1998), A Comparison of Server-based and Receiver-based Local Recovery Approaches for Scalable Reliable Multicast , Proc. of IEEE INFOCOM'98, pp.988-995, San Francisco, U.S.A. Kumar ,S., P.Radoslavov, D.Thaler, C.Alaettinoglu, D.Estrin and M.Handley (1998). The MASC/BGMP Architecture for Inter-domain M.,lticast Routing, Proc. of ACM SIGCOMA-f'9L>, 'vancouver, Canada. Lehman,L. , S.Garland and D.Tel1nenhouse(1998) , Active Reliable Multicast, Proc. of IEEE INFOCOM '98, pp.581-589, San Francisco, U.S .A. Mathis,M., J .Semke, K.~lahdavi and T .Ott(1997). Macroscopic Behavior of the TCP Congestion Avoidance Algorithm, ACM Computer Communication Review, Vo1.27 , No.3, pp.67-82. McCanne ,S., V.Jacobson and tv1.Vetterli(1996) . Receiver-driven Layered Multicast, Proc. of ACM SIGCOMM'96, pp.1l7-130, U.S.A. Moy,J .(1994). Multicast Extensions to OSPF, IETF RFC 1584. Noguchi ,T. , M.l .•mamufo and H.lkeda(2001). Reliable Multicast Protocol Applied Local FEC, Proc. of IEEE ICC 2001, pp.2348-2353 , Helsinki , Finland . Nonnemuacher,J ., and E. Biersack( 1996). Reliable Multicast: Where to use..FEC, Proc. IFIP 5th Int. Workshop on Protocols for High-Speed Networks, pp.134-148, Sophia Antipolis, France. Nonnenmacher ,J ., E.Biersack and D.Towsley (1997) . Parity-based Loss Rocovery for Reliable Multicast Transmission, Proc. of ACM SIGCOMM'97, pp.289-299, Canne, France. Nonnenmacher,J ., and E.Biersack(1998a). Optimal multicast feedback, Proc. of IEEE INFOCOM '98, pp.96 1-971, San Francisco, U.s.A . Nonnenmacher,J ., M.Lacher, M.Jung, E.Biersack and G.Carle(1998b) , How Bad is Reliable Multicast without Local Recovery? , Proc. of IEEE INFOCOM '98, pp.972-979, San Francisco, U.S.A. Padhye,J ., V .Firoiu, D.Towsley and J .Kurose(1998) . Modeling TCP Throughput: A Simple Model and Its Empirical Validation, Proc. of ACM SIGCOMM '98, pp.303-314 , Vancouver, Canada. Paul,S., K.Sabnani , J .Lin and S.Bhattacha.ryya (1997). Reliable Multicast Transport Protocol (RMTP), IEEL Journal on Selected Areas m Comm., Vo1.l5, No.3, pp.407-421.

Pil1gali,S. , J.Kurose and D.Towsley(1994) . A Comparison of Sender-initiated and Receiverinitiated Reliable Multicast Protocols , Proc. of the 1994 ACM SIGMETRICS '94 , pp.221-230 . Rizzo,L.(1997) , Effective Erasure Codes for Reliable Computer Communication Protocols, ACM Comput er Communication Review, Vo1.27, No.2, pp.24-36. Rizzo,L.(2000) . pgmcc: A TCP-Friel1dly SingleRate Multicast Congestion Control Scheme, Proc. of ACM SIGCOMM 2000, pp.17-28, Stockholm, Sweden. Speakman,T., J.Crowcroft , J.Gemmell , D.Farinacci , S.Lin, D.Leshchiner, M.Luby, T .Mol1tgomery, L.Rizzo, A.Tweedly, N.Bhaskar, R.Edmonstone , R.Sumanasekera and L.Vicisano(2001). PGM Reliable Transport Protocol Specification," IETF RFC 3208 . Tennenhouse,D., and D.Wetherall(1996) . Towards an Active Network Architecture, ACM Computer Commun. Review, Vo1.26, No .2, pp.5-18. Vicisano,L., J .Crowcroft and L.Rizzo(1998) TCPlike Congestion Control for Layered Multicast Data Transfer, Proc. of IEEE INFOCOM'98, pp.996-1003, San Francisco, U.S.A. Waitzmanll,D. , C.Partridge and S.Deering(1997) . Distance Vector Multicast Routing Protocol, IETF RFC 1075. Yajnik,M., .1. Kurose and D. Towsley(1996) . Packet Loss Correlation in the MBone Multicast Network , Proc. IEEE Global Internet '96, pp.94-99 , London, UK. Yamamoto,M., J .Kurose, D.Towsley and H.lkeda (1997). A Delay Analysis of Sender-Initiated and Receiver-Initiated Reliable Multicast Protocols, Proc. of IEEE INFOCOM'97, pp.480488, Kobe, Japan. Yamamoto,M. , T .Hashimoto and H.lkeda(2000a) . Performance Evaluation of Local Recovery Group Configuration in Reliable Multicast , IEICE Trnns . on Comm. , VoI.E83-B , No.12, pp.2675-2684. Yamamoto ,M., M.Yamaguchi, T.Hashimoto and H.lkeda(2000b) . Performance Evaluation of Reliable Multicast Communication Protocol with Network Support, Proc. of IEEE GLOBECOM 2000, pp.1736-1741, San Francisco, U.S .A. Yamamoto,K ., M.Yamamoto and H.lkeda(2001) . Performance Evaluation of ACK-based and NAK-based Flow Control Mechanisms for Reliable Multicast Communications, IEICE Trans . on Comm ., voI.E84-B , no.8 , pp.2313-2316. Yamamoto,M.(2001). A Survey of Active Network Technology (Invited Paper) , IEICE Trnnsactions on Communications, vol.J-84-B, no.8 , pp.1401-1412.(in Japanese). Yamamoto,M.(2003) . Multicast Communications -Present and Future- (Invited Paper) , IEICE Trnns . on Commun., Vol.E86-B, No.6, pp. 17541767.

627