CS386M: Communication Networks

Homework 1

Spring 2008

Due: March 3^rd, 2008

Basic guidelines:

• You may discuss the homework problems with other students in the class. However, you must prepare your own solutions.
• Please use a text formatter (latex, word, etc.) to prepare your answer. Please submit a hard-copy.
• Homework is due at the beginning on class on the due date.

Mission statement: Your mission is to apply the network design principles you learn in the class to design a massive-scale multicast service overlay (with 64K overlay routers) that can support a billion overlay multicast groups with varying sizes and activity levels:

• Size: We assume that majority of the groups are relatively small (i.e. mice) but there are also a small fraction of groups that are very large (i.e. elephants).
• Activity level: The amount of data traffic for these multicast groups vary across different groups. Specifically, we assume a 10/90 rule here: 10% groups are highly active and contribute to 90% of data traffic, whereas the remaining 90% groups are much less active and contribute to only 10% of data traffic.

Note that both the size and the activity level of a group may vary over time. So a small group may become a large one later and vice versa. Similarly, an active group may become inactive later and vice versa.

What to turn in:

(i) Present your high-level design. Please provide enough details for me to see how your design works. But there is no need to present low-level details such as message types and formats. [40 points]

(ii) Justify why you think your design can support a billion groups. What are the state requirement, resource consumption, control overhead, and data forwarding efficiency of your design? Please provide some back-of-the-envelope calculation here. [30 points]

(iii) Summarize how different network design principles are applied in your design. [30 points]

Some potential design issues:

To guide your design, below I will list a few potential design issues that are worth considering. There are clearly many other challenges/tradeoffs. So please just use my list as a starting point.

· Tradeoff between forwarding efficiency and state requirement: In order to construct an efficient multicast forwarding tree for a group, a lot of on-tree routers (that are not group members) may need to maintain state for that group. If we do so for every group, then the state requirement may become too expensive.

· Cost of maintaining group membership: In IP multicast, end-systems are required to periodically refresh their membership. If we do so for every group, then the control traffic overhead may become too expensive.

· Explicit versus implicit group membership: In IP multicast, the group membership is implicit, i.e. no node knows the set of group members – they just need to know the group address (Recall that this is an example of “indirection”). Clearly, such an approach has both advantages and disadvantages. Now that we have a billion overlay multicast groups with diverse sizes and activity levels, it may be worth re-examining the choice between explicit and implicit group membership.

· Load balancing: With a billion overlay multicast groups, if we are not careful, we can easily overload individual overlay routers (in terms of both state requirement and traffic concentration).