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

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

Unicast to multiple hosts

Multicast to multiple hosts “to group”

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)

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

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

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

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!)

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

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

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

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

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!)

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

Multicast by flooding non-membergroup memberrouter

Multicast by flooding non-membergroup memberrouter

Why simple flooding doesn’t work non-membergroup memberrouter

Why simple flooding doesn’t work non-membergroup memberrouter wasted!

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

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

A multicast tree

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

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

IGMP Internet “Who is a member?”

IGMP Internet “I am”

IGMP Internet “I am”

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

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

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

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

Pruning

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

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

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

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)

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

Interlinked failures

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

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!

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”

Retransmission requests

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

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

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

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