CS514: Intermediate Course in Operating Systems

1. CS514: Intermediate Course in Operating Systems Professor Ken Birman Ben Atkin: TA Lecture 5: Sept. 7

2. IP multicast • Has already been briefly mentioned by Professor Birman • Today we’ll see how it works • rationale for multicast • multicast between LANs • multicast on the Internet • a few words about reliability

3. Unicast to multiple hosts

4. Multicast to multiple hosts “to group”

5. Why do multicast? • Send to a group, not to individual hosts • Reduces overhead in sender • Reduces bandwidth consumption in network • Reduces latency seen by receivers (all receive “at the same time”, in theory)

6. Logical addressing • Multicast groups “handled by network” • Senders, receivers do not need to know each others’ identities • Group persists as long as it has at least one member • a “rendezvous” mechanism

7. Applications • Teleconferencing • Distance learning • Multimedia streaming • Directory service lookup • ...

8. Multicasting for resource location • Expanding-ring search • We want to find an instance of a resource (database, etc) which is close by • Use multicast with IP time-to-live (TTL) values

9. Time-to-live and hop counts • TTL is a counter in the packet header • Decrement at each “hop” through a router • When TTL reaches zero, the packet is dropped • special values for “global” and “regional” TTL (use with care!)

10. Expanding-ring search “Find me a database”, TTL=1

11. Expanding-ring search “Find me a database”, TTL=2 “I’m a database, what can I do for you?”

12. Multicast addresses • Class D IP addresses for group • 224.0.0.0 to 239.255.255.255 • Treated like any other IP address: can send from it or listen to it • In practice, use UDP as well (more on this later)

13. Multicast at the LAN level • Ethernet is a broadcast medium: all network cards see all packets • Register the multicast address in the network card • only pass matching packets to OS • all other packets are ignored

14. Multicast beyond the LAN • We would like to multicast between hosts on different LANs • LANs are joined together directly by bridges • or can be connected through the Internet by a sequence of routers • need an inter-LAN (WAN) protocol • (in fact, this is rarely enabled!)

15. A naive approach • We want to send multicasts everywhere where there are group members • use flooding to send multicast between routers • when we get to a LAN, use regular (Ethernet) multicast

16. Multicast by flooding router group member non-member

17. Multicast by flooding router group member non-member

18. Why simple flooding doesn’t work router group member non-member

19. Why simple flooding doesn’t work wasted! router group member non-member

20. Multicast flooding • Not a scalable mechanism • every LAN sees every multicast • every WAN router sees every multicast: wastes bandwidth, CPU • Requires a two-part solution • determining LAN group members • omitting WAN routers from multicast

21. Multicast trees • Shortest-path tree to all multicast members, rooted at sender • But must be computed independently by each router • And must be dynamically adjusted for joins and leaves

22. A multicast tree

23. A multicast tree

24. IGMP • Internet Group Management Protocol (Deering and Cheriton) • Developed from work in V distributed operating system • introduced notion of process groups (Cheriton and Zwaenepol) • groups for services, e.g. name resolution, remote paging

25. IGMP • Detects if a multicast group has any members within a LAN • Query and report messages • router sends query of group membership periodically • hosts report groups they’re in

26. IGMP Internet “Who is a member?”

27. IGMP Internet “I am” “I am” “I am”

28. IGMP Internet “I am” “I am” “I am”

29. Avoiding overloading • Report packets may overload router • upon getting a query, each group member sets a timer • if it sees a report for its group before the timer expires, it suppresses its report • otherwise reports on expiration

30. Building multicast trees • Want to avoid loops, duplicates • Dalal and Metcalfe: reverse path forwarding • relies on existing (point-to-point) shortest-path data for next hops to decide where to forward to • forward a packet only if it arrived on the shortest path to its source

31. Reverse shortest-path forwarding

32. Reverse shortest-path forwarding • Doesn’t eliminate all duplicates • A further enhancement is to only forward a packet to a neighbour if you’re on its shortest-path to the source

33. Pruning nodes from the tree • When they get a multicast, routers decide if they should prune themselves out • LAN routers can use IGMP to find if they have members • tell preceding node on the shortest-path tree not to forward to you • recursive

34. Pruning

35. Pruning

36. Pruning

37. Rejoining a group • A LAN router with a group member may find it has no link into the multicast tree • either sends a graft message to add itself to the tree • or use flood-and-prune: routers are periodically added back into the tree; they prune themselves again if they still have no members

38. The MBONE • Multicast Backbone • Layer over the Internet • permitted rapid deployment • only certain routers participate • “tunnel” between MBONE routers • has to do its own routing • upper limit on bandwidth consumption

39. Multicast reliability • Best-effort reliability, “as good as UDP” • But has some additional problems not shared by unicast UDP • fragmentation • interlinked failures

40. UDP fragmentation • Recall that UDP packets are bigger than IP packets • With a fixed loss probability, more members = more losses • losing one IP packet drops the entire UDP packet • makes repairing failures more expensive, not used in practice (use IP-sized packets)

41. Interlinked failures • Traditionally we assume that packets p, q being lost could be independent events • but with IP multicast they could be very correlated • an omission at a parent node causes all children to miss the packet

42. Interlinked failures

43. Multicast behaviour • A “bad Internet citizen” • No backoff, unlike TCP • Runs on MBONE, not Internet! • Only really usable in an intranet • Problems with bridges • Multicast flooding/storms • Everybody gets them

44. Multicast problems • Even if routers don’t forward multicasts, they still have to process them • Similarly, a network card may be forced to drop packets if it gets too many • So too many simultaneous multicasts can cause problems!

45. Multicast storms • Retransmissions to fix losses must be carefully controlled • too many can just aggravate the problem • and can affect the performance of non-multicasting hosts • Bridges typically drop multicasts to stop storms propagating • Want to avoid “router collapse”

46. Retransmission requests

47. Making IP multicast a good citizen • A hot area for research • Sender-based and receiver-based schemes • forward error correction • combining retransmission requests

48. Forward error correction (FEC) • Sender-based mechanism • repeat multicasts in order to overcome the likelihood of packet loss: anticipate retransmission requests • or use parity, Hamming codes, etc, to generate parity packets, and receiver reconstructs dropped packets

49. Combining retransmission requests • Receivers are more intelligent about when to make requests for retransmissions • e.g. watch to see if others make requests, if so, suppress ours • can still cause storms! • e.g. SRM, RTP2, PGM: we will return to these later

50. Further reading • S. Keshav. An Engineering Approach to Computer Networking. Addison Wesley, 1997 • Internet Group Management Protocol, Version 3 (Cain, Deering, Kouvelas, Thyagarajan)http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-04.txt • S. Deering. "Host Extensions for IP Multicasting", RFC 1112, SRI "requests for comments" repository, August 1989. • Yogan K. Dalal and Robert M. Metcalfe. "Reverse Path Forwarding of Broadcast Packets". Communications of the ACM 21:12, pp1040-1048, December 1978.