The traditional model of IP multicast is based on a group model of aggregated hosts. This paper identifies and addresses these five problems of the traditional model:
This paper proposes IP multicast channels, which address and provide aa solution to all of these problems. A channel consists of a sender and a receiver pair (S, E), where there is a unique sender for each channel. The EXPRESS channels can be provided as a simple modification to IP multicast using a small portion of the D IP class. The result is many more channels (about 16 million total per host interface) than IP multicast. EXPRESS can be implemented using a simple protocol called ECMP. Using this protocol, a router simply looks up a packet in a Forwarding Information Base (FIB), locates the (S,E) pair, and forwards the packet to the appropriate interfaces in the multicast tree. If the pair is not found then the packet is dropped. EXPRESS also provides a mechanism that counts the number of hosts in the multicast group. All of these improvements help to address the above five problems, or the first four of them, at least.
One other important idea of this paper is what's called a session relay. Because EXPRESS limits one sender per channel, some other mechanisms is needed when another host (perhaps one in the multicast group) wants to transmit. Session relay provides the ability for hosts to take turns to transmit through a session relay. This mechanism reduces the necessity of using multiple channels in a video conference when only one person needs to speak at a time.
I give this paper a rating of 3 for modest contribution. The authors address some important problems with IP multicast; however, there are still some problems with the solutions that they provide. First, EXPRESS's restriction to one sender per channel is a limitation. Yes, session relay provides a way around it, but the delay trade-off involved with session relay makes it difficult to run a group debate, for example. Multiple channels, therefore, are needed, which is a bigger overhead. Second, I'm not convinced that looking up the FIB for every packet doesn't incur a significant overhead. When there are a lot of senders, a linear search can be costly.
The authors are very unclear as to under what condition that they ran the test simulations. I don't think their methodology is convincing. Just for an example, the authors argue under section 5.1 that the cost of looking up entries in a FIB is about 8 cents per session per year of router lifetime. But if you take a closer look at the units of the equation, the numbers work out to be 8 cents per second, not year! That's a major difference and increase in cost.