11.24.06
Review of “Revisiting IP Multicast”
The authors revisit one of computer networking most studied ideas, IP Multicast. Multicast is one of the few ideas that many technical papers proposed ideas for implementation, but hardly any real world, wide-use protocols have been deployed. The complexity and scalability of the multicast idea is what has caused the difficulties. The authors argue that there are enough applications that would benefit from it and maybe we should take another look at multicast.
They provide a short look into the multicast history from its beginnings as an extension to the IP unicast service. They then go through multiple other multicast protocols all improving on one deficiency, but none of them totally solving the complexity and scalability problems of multicast. Their proposal for Free Riding Multicast (FRM), does not necessarily solve the scalability problem either, but instead they move the problem, route computation, to the internals of the routers.
They make a case to revisit multicast because the need by many applications including multiplayer games, IPTV, file-sharing, RSS feeds, and video conferencing, just to name a few. They argue that multiplayer games could benefit from a multicast service to build a more lightweight and cheaper infrastructure because they would decrease the number of servers needed. For IPTV, they argue that multicast would allow the ISPs to deliver the content to more viewers and content providers. They illustrate there are many solutions that could benefit from multicast. In general, the authors wanted to develop a solution in which any user would be able to any group.
Multicast requires two major pieces: which end host are group members and how to reach these members. Many of the multicast solutions combine these components into one protocol. The authors however separate the two gaining the advantage of once group members are known; any source can build a multicast tree from its unicast routes to each member host.
Their FRM approach focuses on inter-domain routing. They add a description of the multicast groups currently in use within the domain to the BGP advertisements. The BGP advertisements are then propagated as normal, thus giving every border router a description of the multicast groups. The addition to the BGP advertisements would be encoded as a Bloom Filter. Because Bloom Filters provide false positives, they have developed a mechanism to prevent this. They have an on-demand control list that will “prune the tree” of the traffic mistakenly sent to networks not a part of the group.
To discover a dissemination tree of a specific group, the source border router searches the BGP table to find the prefixes of the member of that specific group. It then builds a shim header that encodes this dissemination tree. To reduce the amount of overhead, this header can be cached and sent out to on the first packet only. This will assume the additional cost of the lookup. For the router that simple forward packets, they would just examine the shim header and forward to nodes based on the tree encoded in the header.
The authors decided to keep the shim header to a fixed size. In doing so, some trees may be too large for one shim header, so multiple headers will be constructed with different subtrees and transmitted on more than one packet. This obviously increases the bandwidth and overhead, but the authors argue this idea is at least worthy of further consideration.
Their analysis of the FRM scheme is good. They show that their number of packet transmissions are identical for an ideal multicast for small group sizes. As the group sizes increase, their number of transmissions increase to only a few percent higher than the ideal case. They compare this to the number of transmissions needed for per-AS unicast, which at some point is three to four times more than FRM.
Their analysis also shows an increase in memory overhead. The memory required to maintain the group membership is reasonable. For example, they use 1 million active groups with 10 groups per user. This scenario would only require 3 GB of memory. The price of memory is cheap, thus making this reasonable.
They also implement their idea on a prototype router. This shows that they were successful in getting FRM to work. They also discuss how the ISPs could control multicast, per-user or per-group. They mention a little bit about the ability to attack FRM and they discuss shortly intra-domain routing. Remember, they focused mainly on inter-domain routing.
Their protocol FRM takes another look at multicast. The major issue with multicast is its complexity and lack of scalability. Their protocol moves the scalability from the network to inside the routers. Is this an effective multicast scheme? Maybe-Maybe not. They do, however, illustrate that multicast should be looked at again and not abandoned forever.