1. Satellite Multicast for Web Applications Hilmar Linder hlinder@cosy.sbg.ac.at University of Salzburg/Austria

2. SatCASTH. Linder - unisal2 Overview Introduction IP multicast Reliable Multicast: –Building Blocks –The RRMP Protocol Summary Questions

3. SatCASTH. Linder - unisal3 Why IP multicast ? Need for efficient delivery to multiple destinations across inter/intranets Broadcast: –Send a copy to every machine on the net –Simple, but inefficient –All nodes “must” process the packet even if they don’t care –Wastes more CPU cycles of slower machines (“broadcast radiation”) –Network loops lead to “broadcast storms”

4. SatCASTH. Linder - unisal4 Why IP multicast ? (contd) Replicated Unicast: –Sender sends a copy to each receiver in turn –Receivers need to register or sender must be pre- configured –Sender is focal point of all control traffic –Latency = time between the first and last receiver getting a copy {can be large if transmission times are large}

5. SatCASTH. Linder - unisal5 Why IP multicast ? (contd) Application-layer relays: –A “relay” node or set of nodes does the replicated unicast function instead of the source –Multiple relays can handle “groups” of receivers and reduce number of packets per multicast => efficiency –Manager has to manually configure names of receivers in relays etc => too much administrative burden Alternative: build replication/multicast engine at the network layer

6. SatCASTH. Linder - unisal6 Multicast Protocol Architecture Internet Protocol Reliable Multicast TCP Middleware Networking Infrastructure IP Multicast Applications Unreliable Reliable

7. SatCASTH. Linder - unisal7 IP multicast concepts Message sent to multicast “group” (of receivers) –Senders need not be group members –Each group has a “group address” – Class D Address –Use “group address” instead of destination address in IP packet sent to group –Groups can have any size –End-stations (receivers) can join/leave groups at will

8. SatCASTH. Linder - unisal8 IP multicast concepts (contd) Packets are not unnecessarily duplicated or delivered to destinations outside the group –Distribution tree for delivery/distribution of packets –Packets forwarded “away” from the source –Only one copy of a packet appears on any subnet –Packets delivered only to “interested” receivers => multicast delivery tree changes dynamically –Network has to actively discover paths between senders and receivers –Non-member nodes even on a single subnet do not receive packets (unlike subnet-specific broadcast)

9. SatCASTH. Linder - unisal9 IP multicast concepts (contd) Group membership on a single subnet is achieved through IGMP (and ICMPv6 in IPv6) Tree is built by multicast routing protocols. –Algorithms based on: Flooding Spanning trees Reverse-path broadcasting Core based trees

10. SatCASTH. Linder - unisal10 Multicast Applications News/sports/stock/weather updates Distance learning Routing updates (OSPF, RIP etc) Pointcast-type “push” apps Videoconferencing, shared whiteboards Distributed interactive gaming or simulations Email distribution lists Voice-over-IP Database replication

11. SatCASTH. Linder - unisal11 Multicast Application Characteristics Number of (simultaneous) senders to the group –1XN versus NxM The size of the groups –Number of members (receivers) –Geographic extent The lifetime of the group Level of human interactivity –Lecture mode versus interactive –Data-only (e.g. database replication) versus multimedia Number of aggregate packets/second The peak/average bandwidth used by source

12. SatCASTH. Linder - unisal12 Real-time Non-real-time Multimedia Data-only Video server Video conferencing Internet audio Multimedia Events Stock quotes News feeds White boarding Interactive gaming Replication: Video & web servers Kiosks Content delivery Intranet & Internet Data delivery Server-server Server-desktop DB replication SW distribution Requires reliability What applications need Reliable Multicast?

13. SatCASTH. Linder - unisal13 Multicast Protocol Architecture Internet Protocol Reliable Multicast TCP Middleware Networking Infrastructure Multicast Applications Unreliable Reliable

14. SatCASTH. Linder - unisal14 Goal Fully reliable multicast: –All packets delivered to all receivers Can’t we just extend TCP? S S R R Data ACKs

15. SatCASTH. Linder - unisal15 Data Reliability S S A A B B C C D D Data

16. SatCASTH. Linder - unisal16 Data Reliability S S A A B B C C D D DataACKs

17. SatCASTH. Linder - unisal17 Data Reliability S S A A B B C C D D “ACK Implosion”

18. SatCASTH. Linder - unisal18 Challenges for Reliable Multicast Scalability to the number of receivers: –Heterogeneity of receivers –Feedback implosion –Congestion control How to achieve reliability: –Automatic Repeat Request (ARQ) –Forward Error Correction (FEC)

19. SatCASTH. Linder - unisal19 Building Blocks Elements from unicast: –Loss detection –Loss recovery: ARQ versus FEC Additional elements for multicast –Mechanisms for control message Implosion Avoidance –Mechanisms to deal with heterogeneous receivers

20. SatCASTH. Linder - unisal20 Where to place the loss detection Receiver-based (NAK) –distributed over receivers –1 NAK per packet (for all receivers) Sender-based (ACK) –centralized –1 ACK per receiver and packet –needs a table of per-receiver ACK

21. SatCASTH. Linder - unisal21 Feedback Processing Assume R receivers, independent packet loss probability Feedback per packet: –average number of ACKs: R - p*R –average number of NAKs: p*R -> more ACKs than NAKs Processing: higher throughput for receiver-based loss detection Reliability needs ACK: No NAK does not mean successful reception!

22. SatCASTH. Linder - unisal22 Feedback suppression At Receivers: –choose a random timer in [0,T] due to a exponential distribution and listen for other’s feedback –On reception of feedback: cancel timer –On timer expiration: multicast feedback, so that other receivers can see it A A B B S S NAK (suppressed)

23. SatCASTH. Linder - unisal23 Loss Recovery FEC versus ARQ: ARQ is the only way to guarantee 100% reliability Who retransmits: –Sender, other receiver, network node How to retransmit: –Unicast or Multicast What is retransmitted –Originals or Parities

24. SatCASTH. Linder - unisal24 Forward Error Correction based on (n,k) Encoding Original packets 12k 12k Decode 12kk+1k+2n Encode (copy 1st k) Take any k

25. SatCASTH. Linder - unisal25 Hybrid ARQ Example A A B B S S 1 2

26. SatCASTH. Linder - unisal26 Hybrid ARQ Example (contd) A A B B S S 11 22

27. SatCASTH. Linder - unisal27 Hybrid ARQ Example (contd) A A B B S S 12

28. SatCASTH. Linder - unisal28 Hybrid ARQ Example (contd) A A B B S S NAK(1 packet lost) (suppressed) 12

29. SatCASTH. Linder - unisal29 Hybrid ARQ Example (contd) A A B B S S =+ Retransmission of Parity 1 1 2 2

30. SatCASTH. Linder - unisal30 Hybrid ARQ Example (contd) A A B B S S 12 PP

31. SatCASTH. Linder - unisal31 Hybrid ARQ Example (contd) A A B B S S 12PP

32. SatCASTH. Linder - unisal32 Hybrid ARQ Example (contd) A A B B S S ++== 1122PP

33. SatCASTH. Linder - unisal33 Hybrid ARQ Example (contd) A A B B S S Two losses recovered with a single retransmission... 2211

34. SatCASTH. Linder - unisal34 Hybrid ARQ Algorithm Hybrid ARQ Algorithm: –Sender send k original packets –Receiver detects that k-l packets have been received and sends a NAK(l) –Sender receives NAK(L1), NAK(L2),.., NAK(Ln) from the receivers and sends Lmax = max {L1, L2,.., Ln} parity packets. A single parity packet can repair the loss of different data packets at different receivers

35. SatCASTH. Linder - unisal35 Performance Measure The mean number of transmission E[M] per packet affects: –The bandwidth needed –The total transfer latency –The processing rate at the sender and receiver With FEC, E[M] can be reduced dramatically Processing costs for FEC need to be considered –How fast is encoding/decoding –Throughput of a protocol based on FEC

36. SatCASTH. Linder - unisal36 Scenario specific selection of Mechanisms FEC is of particular benefit in the following scenarios: –Large groups –No feedback –Heterogeneous RTTs –Limited buffer ARQ is of particular benefit in the following scenarios: –Heterogeneous loss –Loss in shared links of the multicast tree dominates –Small groups –Non-interactive applications

37. SatCASTH. Linder - unisal37 Restricted Reliable Multicast Protocol (RRMP) Error Detection and Correction Module –FEC only –Hybrid ARQ –Proactive ARQ Transport Module: –Bandwidth Management –Flow Control –RTT estimation –Group Management Statistics Module

38. SatCASTH. Linder - unisal38 Proactive Error Control Parities are sent pro-actively along with data –avoid retransmission –reduce latency A A B B S S 11 22 A A B B S S ++== 1122PP

39. SatCASTH. Linder - unisal39 Mercure Network Simulation Connections btw. A Sites Sender in PEK, Receiver in NBO Packet Loss Rate: 5

40. SatCASTH. Linder - unisal40 Summary There is no “one-fits-all” reliable multicast protocol Application requirements influence the decision for the “best” multicast protocol Standardization of RM “building blocks” is currently ongoing Further research for “Internet compatibility” of RM protocols is necessary

41. SatCASTH. Linder - unisal41 Questions ??