12.03.06

The case for making multicast a first-class service in the Internet

Posted in Essays, multicast/anycast at 9:44 pm by mbecchi

A multicast communication service sends packets from a source to a set of destinations, also called multicast group. The basic underlying idea is to propagate the packets into the network so to reduce the bandwidth involved. If, for instance, a packet has to be sent from a source on ISP x to N recipients connected to another ISP y, then a unique copy of the packet will be first sent from ISP x to ISP y, and then ISP y will locally dispatch N copies of the packet to the interested recipients. In a more general scenario a multicast dissemination tree, that is, a minimum spanning tree rooted at the sender, will be used in order to determine how a multicast packet will be propagated in the network. This solution will involve a degree of bandwidth consumption which is far less than simply having many unicast transmissions between the sender and every recipient.

Notice that, for multicast to make sense, recipients should have a way to declare their interest in receiving specific classes of packets. One way to think about this consists in associating the interested recipients with a multicast group address. Another important aspect about multicast communication consists in the fact that it intrinsically involves decoupling between the sender and the receivers: in fact, the source of a packet does not in principle need to know anything about its recipients. Finally, multicast routing conceptually happens by routing the packet away from the source, rather than towards the destination (as is the case for unicast routing). In other words, if the source of a multicast packet is defined as being “upstream”, the router determines which “downstream” interfaces are destinations for a multicast group and forwards the packet through them.

The basic motivation for making multicast a first-class service in the Internet consists in the proliferation of applications involving one-to-many communication. Not only do these applications abound, but their popularity and pervasiveness tends to increase over time. One can think, for instance, of video and audio streaming applications, video teleconferencing, multiplayer games, automatic updates applications, newsgroup, and more. Moreover, it can be noticed that the use of these applications is not restricted to LANs, but it easily spans over WANs. Furthermore, in all cases a huge amount of data is involved in the transmission: therefore, the use of the multicast communication service would involve a dramatic reduction in bandwidth consumptions.

Several solutions have been proposed as possible implementation and deployment framework for IP Multicast, whose concept was first studied in [4]. The authors of [5], noticing the analogies between the multicast and publish-subscribe communication services, propose a rendezvous overlay based implementation. In [5] a proposal is described where a domain’s BGP advertisements are augmented with a description of the multicast group currently in used within the domain. However, each of the proposals fails at addressing the basic issues involved with multicast.

There are several issues hindering the success and the deployment of multicast on a large scale. Some are technical: increased amount of router state involved, aspects related to quality of service and security. Some are pricing related: how could ISPs benefit from the deployment of a multicast service? Let us analyze each of these aspects more in depth.

Router state – A minimum amount of router state is required in order to guarantee a unicast communication service. For routing purposes, the state consists of the forwarding data present in the BGP tables. In case of multicast, the router state has to be augmented. In fact, at the very least, the correspondence between the multicast groups and the downstream interfaces to forward the packets to needs to be stored. Notice that, since recipients can enter and exit multicast groups, this information is dynamic and its variability is presumably higher than the one of the routing data stored in the BGP tables. Therefore, not only does the routing state increase, but its management also needs more sophisticated mechanisms. However, this is not an insurmountable technical issue.

Quality of service – The Internet nowadays provides just a best-effort unicast data delivery service. It belongs to the responsibilities of the upper layers to add quality of service guarantees. In case of unicast communication, a best effort delivery could be acceptable, in that the endpoints involved are just two. A low quality of service (due to packet losses or high delays) will involve just two entities. However, in case of multicast communication many recipients may be involved. Therefore, it may be desirable to include higher quality of service guarantees. Moreover, this is more crucial on those links of the multicast tree which carry traffic to a higher number of endpoints. It can be noticed that, even if introducing quality of service in the network can be seen in general as a positive thing, it implies a change in the way Internet is designed.

Security – Introducing a one-to-many communication service, if not accurately designed, opens the way to security holes. A malicious user, for instance, can very easily flood the network with high volumes of traffic by addressing them to big multicast groups. This, in turn, can saturate the bandwidth of some network links thus generating denials of service. Or, a malicious user can perform a sibyl attack by pretending to be several different users and add all of them to widely used multicast groups.

Pricing - As mentioned above, the basic objective of multicast is to reduce the bandwidth utilization within one-to-many data transmissions. However, nowadays pricing is applied by ISPs on the basis of the number of (high bandwidth) network connections sold. In a unicast environment, if a service wants to distribute data to N users in parallel, then it needs to buy a bandwidth which is N times the bandwidth which would be required for a single user. Notice that the service is the source of data. Therefore, the ISP has no interest in mechanisms to reduce the bandwidth utilization of multicast transmissions. In fact, this would lead to a decrease in the number of connections sold to guarantee the same service.

Given these issues, does it make sense to try to make multicast a first class communication service? Would its benefits justify the complexity of the design? In my opinion, the importance of the applications listed above makes it worthwhile at least to consider the problem. However, I don’t think that multicast can be successfully integrated with or built on top of the current Internet architecture. On the contrary, some aspects in the use of the Internet should be reconsidered. To this end, multicast could be thought of as a service provided within infrastructures like GENI.

Let us first reconsider the pricing issue. Let us assume a different scheme where the ISPs charge the service depending on the amount of end users. In this case, the use of multicast would fit the interests of the ISPs. In fact, it would not decrease their profit, yet would it allow to provision less bandwidth (and, therefore, fewer resources) in order to guarantee the same quality of service. As the bandwidth requirements substantially decrease, the ISPs may decide to increase the minimum amount of bandwidth devoted to a service. Thus, the quality of service itself would improve (with respect to the connection-based pricing scheme) and the recipients would be more satisfied and likely to subscribe to a given service (i.e. buy it), making the interests of both the service provider and the ISP. At the limit, one could envision a pricing scheme which combines the number of users and the quality of service guaranteed. Notice that this pricing scheme would fit a large spectrum of applications: from audio-video streaming to multiplayer games.

The use of the described pricing scheme would also discourage some forms of attacks to security. A malicious user, for instance, would have little interest in flooding the network with traffic sent to large multicast groups. In fact, in order to do so, it would be charged by the ISP on the basis of the number of recipients. Thus, the malicious attack would come at a (not negligible) cost.

For what concerns sibyl attacks, we can assume that becoming part of a multicast group means subscribing to a given service. In general, a subscription expresses a contract between a service provider and a user, and in that has a cost. Thus, attacking the system from the receiver side would also be costly and unattractive to malicious entities.

Notice that, by reducing bandwidth consumption, multicast communication would make it easier to scale a service up to a higher number of users. Thus, it would facilitate the deployment of applications on a wider scale.

From the discussion above it should be clear that an authentication and a proper traffic accounting mechanism are needed for the whole infrastructure to work. In fact, a user based pricing scheme makes authentication of both service providers and recipients necessary. In parallel, as mentioned above, the router state should be augmented not only to allow proper forwarding of multicast traffic, but also because the number of users subscribed to a service is fundamental information to the pricing component. It is essential that the gain in bandwidth consumption and the better guarantees in quality of service pay off the complexity of handling the augmented state.

To sum up, I believe that implementing the multicast service in the Internet could allow an easier and more scalable deployment of applications based on the one-to-many communication paradigm. However, multicast deployment is unforeseeable if the pricing scheme is not reconsidered. Specifically, not only would the adoption of a user based pricing scheme motivate ISPs to make use of multicast, but it would also allow higher quality of service and discourage several forms of attacks to security. Nonetheless, the problem of efficiently and effectively handling the required additional router state deserves attempt consideration.

References

[1] Wikipedia – Multicast: http://en.wikipedia.org/wiki/Multicast

[2] Wikipedia – IP Multicast: http://en.wikipedia.org/wiki/IP_Multicast

[3] Sylvia Ratnasamy, Andrey Ermolinskiy, Scott Shenker, “Revisiting IP Multicast”, in ACM SIGCOMM 2006

[4] Stephen Deering and David Cheriton., “Multicast routing in datagram internetworks and extended LANs”, in ACM Transactions on Computer Systems, 8(2):85–110, May 1990.

[5] Ion Stoica, Daniel Adkins, Shelley Zhuang, Scott Shenker, and Sonesh Surana, “Internet Indirection Infrastructure,” in Proceedings of ACM SIGCOMM, August, 2002

Permalink