An Analysis of Fault Isolation in Multi-Source Multicast Session

1. An Analysis of Fault Isolationin Multi-Source Multicast Session Network Research Workshop 2003. 8. 28 Heonkyu Park hkpark@cosmos.kaist.ac.kr Korea Advanced Institute of Science and Technology

2. Table of Contents • Motivations / Problem Definition • Background • Analysis • Issues • Candidate Model • Simulation Results • Conclusion References

3. : perceiving the fault in somewhere in the network : locating the fault that on-tree router or link which is the origin of a fault. Hmm… Fault is in somewhere… OK! I found the Fault! Fault Isolation Fault Detection Before we start… • Terminology • Unicast : to a single receiver • Multicast : to a specific subset of receiver • single-source : only one source in a session (one-to-many multicast) • multi-source : many sources in a session (many-to-many multicast) • Fault Detection • Fault Isolation

4. Motivation / Problem Definition • Network monitoring is necessary to detect and discover of network problems. • Some participants in multicast experience severe packet loss. • Fault detection / isolation approaches in multicast are focused on single-source network. Obtained using Rqm [rqm] tool • In multi-source multicast, little work has been done for fault isolation. • Straightforward reuse single-source solution is not sufficient for large number of multi-source multicast.  New model for fault isolation in multi-source multicast is needed.

5. Multicast Packets When fault occur receiver receiver source send to a multicast session receiver receiver Background • IP Multicast • Multi-Source Multicast Applications • Challenges of Multicast Monitoring • Needs for Multicast Fault Isolation • IP Multicast routing path is changed when a fault is occurred.

6. Multi-Source Multicast Applications • Networked virtual environments • Synchronized resource like database updates • Distributed or parallel concurrent processing • Large-scale distributed military simulation • Peer-to-peer multicast file transfer model • Large-scale multimedia conference • Large-scale replicated database • Cooperative web cache protocols • Shared editing and collaboration • Interactive distance learning • Network games or chatting • and more… Group Size [LN01] Number of Senders Peer-to-PeerApplications 1,000,000 Distributed InformationSystems 1,000 Games 10 Streaming CollaborationTools ContentDistribution 1 10 1,000 1,000,000 Numberof Receivers

7. Time Debugging Management Modeling mrmap mrinfo mrdebug rtpmon mtrace mwatch mlisten Dr. Watson MultiMon mhealth RouteMonitor MantaRay NIMI * mantra sdr-mon Otter MRM * mwalk HPMM ~1992 mstat mview mrtree GDT NetIQ’s Chariot * mmon SNMP_NG ~1997 ~2000 recent research work Multicast Monitoring Tools [SA01] Management, Debugging and Modeling via Active / Passive Monitoring Monitoring Mah’s Study Yajnik’s Study Handley’s Study MINC * * : can be used for active monitoring

8. Needs for Multicast Fault Isolation • Monitoring of multicast network has become a crucial for maintaining the multicast operations • since the delivery service in multicast is more complex than in traditional unicast networks • Supervising multicast traffic is more difficult problem as each multicast tree involves multiple hosts with correlated, simultaneous faults. • There are various reasons causing multicast fault. • session announcement problem, reception problem, multicast router problem, congestion and rate-limiting problems, multicast routing problem, etc. [TA00] • It is not easy work even in single-source multicast, to say nothing of multi-source multicast.

9. Analysis on Single-Source Approach • Only for fault detection • MRM(Multicast Reachability Monitoring) [SA01] • active probing from a test sender(TS) to a test receiver(TR) by MRM manager • SMRM(SNMP-Based MRM) [AT02] • SNMP-based approach defined several MIB for multicast monitoring • Both detection and isolation • HPMM(Hierarchical Passive Multicast Monitoring) [WL00] • passive monitoring scheme that agents are organized in a hierarchy and communicate with each other using unicast • MTR(Fault Isolation in Multicast Tree) [RGE00] • receiver-driven method using IGMP multicast traceroute  Most approaches up to now focused on single-source multicast.

10. MRM (Multicast Reachability Monitor) [SA01] - Description Step 3: TR(s) Monitor Group Transmission R1 R2 TR2 Step 2: TS Transmits TS R6 TR3 R3 R4 R5 TS: Test sender TR: Test Receiver TR1 MRM Manager Step 4: Mgr Collects and Displays TR Reports Step 1: Mgr Configures TS(s) and TR(s) Manager  Agent Communication Router End-Host

11. SMRM (SNMP-Based MRM) [AT00] - Description smrmMIB Group in Extended MIB II

12. HPMM(Hierarchical Passive Multicast Monitor) [WL00] - Description Foreign domain 1 Foreign domain 2 source 1 source 2 1 2 group 1 Local domain 1 group 2 A 2 B 1 1 C D E 2 • Each node knows exactly which upstream agent to notify in case of a fault occurrence. • Node D has only one parent for both multicast groups 1 and 2, which is node B • Node E defines a parent agent in B for group 1 and a parent agent in C for group 2.

13. : Fault Isolated Fault Region R R R R R R b b a a c c MTR (Fault Isolation in Multicast Tree) [RGE00] - Description Before After Source Source common ancestor router of Ra & Rc

14. Comparison on Related Works ※ No suggested approaches are sufficient for fault isolation in multi-source multicast network.

15. Message Complexity of Current Approaches • Network overload exponentially increased by extending number of members • As extend member size, mtrace request packets and mtrace reply packets are excessive. • Simulation result by ns-2 • tree topology: 100 nodes, out-degree : 3 • number of members : 5 ~ 60 (increased by 5) • 5 times average calculation • Thus, it needs different strategy to handle multi-source multicast fault detection and isolation.

16. Issues • Application Characteristics • Message Complexity • Fault Isolation Error • Scalability • Deployment • Application Characteristics Comparison on two applications [CRSZ01]

17. Issues for Multi-Source Multicast Fault Isolation • Message Complexity • Message complexity will be main concern. • Not to increase linearly, but to logarithmic • not O(N), but O(logN) or O(1) • Fault Isolation Error • Should be same or decreased compared to previous approach. • No sudden computation overload to isolate faults • near-realtime fault detection and isolation function • Scalability • not effected with the number of members • dynamic member action like join / leave actions • Deployment • should be easily deployable not depend on protocols and techniques. not good message complexity Acceptable size of members

18. Candidate Model • Goal : Isolate the fault promptly and accurately using efficient and scalable approach in the multicast network when the fault is occurred. • Basic Idea : member grouping • do not let all member send probe • there exists shared path from local member to other members • make maximum use of shared information • only group leader send probe for fault isolation to other group leaders • Benefits • reduce message complexity • scalable since not depend on size of members

19. Group A Group B A2 B2 B1 A3 A1 D2 C1 D1 Group D Group C Draft Model • Each group select a group leader. • Group leader manages its member and sends probes for fault isolation. • Not send to all other group leaders, but send just common ancestor router with other group leaders.

20. Member Grouping • how the members are grouped • simply, boundary within border router • need to find a way to make a group bigger since the number of group can be still large • how the members in a group know their group leader • group leader send a probe to group member periodically “i-am-leader” packet one group group leader border router • how know group leader exist • newly joined member send “i-am-leader” packet in a group using multicast scoping • if no response, it becomes the leader. • if somebody send “i-am-leader” packet, consider there is a leader.

21. Group Leader Action Lists • Managing members in group • use “i-am-leader” to control group member • “you-are-leader” packet when leave • Fault Isolation • primarily function for group leader • exchange among other group leaders • Group leader announcement • It is not easy work to announce and to find out the group leaders

22. Simulation Results • Overview • Simulated a simplified protocol using ns-2 simulator • Random graph by GT-ITM • Average value after five time simulations • Compared with best approach among related works • Results • All-member-based (best-performance) • Group-leader-based • reduced the message complexity 68%

23. Conclusion • It is important to locate the fault in a network. • Little work has been done for fault isolation even in detection in multi-source multicast. • In multi-source multicast fault isolation, message complexity is main concern. • One candidate approach is a group-based architecture to locate the fault in a multi-source multicast session. • Simulation results show group-based approach reduced the message complexity as amount of 68% than the best performance approach among other ones. • However, group-based approach is not fully enough for scalability reason, etc.

24. Future Works • Need more efficient approach for message complexity. • Possible model is suppressed one-way probing mechanism. • Source sends a special packet to multicast group. • All internal router records its routing information in the special packet. • Without packet suppression, implosion problem will be occurred. • Receiver compare to check whether routing path was changed. • Simulation results show that this suppressed one-way probing is well suit for multi-source multicast network. • Several things to elaborate… • Any comment will be appreciated.

25. References [AT02] E. Al-Shaer and Y. Tang, “SMRM: SNMP-based multicast rechability monitoring,” in IEEE/IFIP Network Operations and Management Symposium (NOMS) 2002, Florence, Italy, April 2002. [CRSZ01] Yang-hua Chu, Sanjay G. Rao, Srinivasan Seshan and Hui Zhang, “Enabling conferencing applications on the Internet using an overlay multicast architecture,” in ACM SIGCOMM 01, San Diego, California, August 2001. [LN01] J. Liebeherr and M. Nahas, “Application-layer multicast with Delaunay Triangulations,” Global Internet Symposium, IEEE GlobeCom 2001, San Antonio, Texas, November 2001. [RGE00] A. Reddy, R. Govindan and D. Estrin, “Fault isolation in multicast trees,” In Proceeding of ACM SigComm 2000, Stockholm, Sweden, Aug. 2000. [Rqm] C. Perkins, “RTP Quality Matrix,” (RTP Quality Matrix), [online], http://www-mice.cs.ucl.ac.uk/multimedia/software/rqm/ (Accessed: 7 March 2003). [SA01] K. Sarac and K. C. Almeroth, “Supporting multicast deployment efforts: A survey of tools of multicast monitoring,” Journal of High Speed Networking--Special Issue on Management of Multimedia Networking, vol. 9, num. 3/4, pp. 191-211, March 2001. [TA00] D. Thaler, B. Aboba, “Multicast Debugging Handbook,” Internet draft, draft-ietf-mboned-mdh-*.txt, Internet Engineering Task Force (IETF), November 2000. [WL00] J. Walz and B. N. Levine, “A hierarchical multicast monitoring scheme,” In 2nd International Workshop on Networked Group Communication, Nov. 2000.

26. Thank you. Question? Comment?