University of Notre Dame NetScale Laboratory

Stealth Multicast Project Webpage

Stealth multicast is a novel concept that allows for practical adoption of network-level multicast on a domain-wise basis rather than a global scale. In the stealth multicast framework, redundant unicast packets are dynamically assembled into virtual groups for multicast transmission across the domain. At the edge of the domain, the packets are converted back to unicast, thus hiding the existence of stealth multicast from the external Internet. True to its namesake, stealth multicast operates in complete stealth, providing seamless interoperability without requiring modifications to end-user applications nor requiring inter-domain support.

  • Thesis D. Salyers, "Stealth Multicast: A New Paradigm in Bandwidth Conservation" Masters Thesis, University of Notre Dame, Adviser: Dr. Aaron Striegel, Committee: Dr. Surendar Chandra, Dr. Christian Poellabauer, Dec. 2005.
  • C pdf D. Salyers, A. Striegel, "A Novel Approach for Transparent Bandwidth Conservation," in Proc. of IFIP Networking, Waterloo, Canada, May 2005.
  • C pdf C. Mano, A. Striegel, "Trusted Security Devices for Bandwidth Conservation in IPsec Environments," in Proc. of IFIP Networking, Waterloo, Canada, May 2005.
  • C pdf A. Striegel, "Stealth Multicast: A Novel Catalyst for Multicast Deployment," in Proc. of Third Annual IFIP-TC6 Networking Conference, pp. 817-828, Athens, Greece, May 2004.

Overview

Currently, many large scale applications are forced to rely on inefficient unicasts for dissemination of data due to the absence of true IP multicast support. Even with the use of application-level multicast (ALM), the source may still be forced to send out multiple copies of the data due to the limited richness\footnote{For instance, the asymmetric nature of most broadband connections (large downstream, limited upstream).} of the downstream clients. While packet caching also targets redundancy, the setup time for the cache (set, acknowledgement) negates the usefulness of caching since the burst of redundant data has already passed by the time the setup protocol completes. Furthermore, as the data payload is changing but the makeup of the clients is not, packet caching will always be one step behind of the new data, thus offering little or no benefit.

We propose to research a new model, stealth multicast, for exploiting redundant data in the network that lies in a close temporal proximity. Unlike traditional approaches to multicast (IP multicast or ALM) that can require cooperation among various parties using the service (i.e. application support, inter-domain routing), stealth multicast conceals the multicast transport in a domain (or beyond) by dynamically converting packets to and from multicast at the edge of the domain. Hence, stealth multicast frees a network administrator from relying on any external participation to yield an immediate, tangible benefit to network performance.

Stealth Multicast Concept The picture to the left shows a picture of the proposed model and its fundamental concepts whereby a server dispatches information to four separate clients using separate unicasts. The key component of the model is the stealth multicast module which assembles candidate packets into virtual groups for multicast transmission across the network. The virtual groups themselves are constructed dynamically (note: the actual virtual group itself may have little or no relation to the physical group depending upon the type of multicast transport (broadcast, pre-defined groups, encapsulation, etc.).), based on redundant data payloads from the same source application, and are assembled at the Virtual Group Detection Manager (VGDM). Packets are queued at the VGDM in the hopes of detecting redundant packets that are then condensed into a single multicast packet for the domain and converted back to a unicast packet at the edge. Hence, the notion of stealth comes from the fact that the entire process itself is hidden and nearly unnoticeable to the external Internet. The sequence of events is described in more detail below:

  1. The application transmits packets with the same data payload via separate unicasts to multiple clients.
  2. The packets arrive at the VGDM and are filtered based on statically and heuristically generated rules. Filtered packets simply continue onwards as standard unicast packets.
  3. A digital signature (checksum) is created for the data payload that uniquely identifies the data payload \cite{wetherall:duppkt:USENIX}.
  4. The packet is queued into a virtual group that shares the same attributes (packet size, signature, source IP, source port).
  5. Based on a stimuli (group size, timer, etc.), the contents of the virtual group are released to the dispatch mechanism.
  6. If the group size is sufficient, the packet is given to the tree construction module for multicast transmission. Otherwise, all of the packets in the virtual group forwarded on for unicast transmission.
  7. A virtual tree for the multicast group is constructed. The virtual tree may be encapsulated in the packet itself \cite{striegel02:dissertation}, be a pre-defined tree (broadcast, partial domain tree), or set up over successive virtual group detections.
  8. If necessary, the unique portions of each packet are included as state information in the packet. The unique portions include the destination IP, destination port, and others (DSCP, etc.). The packet is then sent onwards as a multicast packet.
  9. The packet is transported across the domain using the underlying transport mechanism (IP multicast, ALM, broadcast, encapsulated multicast, etc.).
  10. The packet is converted back from multicast to unicast using the state information included in the packet or present at the egress node. The packet leaving the domain is indistinguishable from the packet that was queued into the virtual group.
  11. The packet continues onwards normally to the client as a unicast packet.

The behavior of the stealth multicast model is based on two fundamental principles, namely external invisibility and negligible QoS? impact. The first principle of external invisibility simplifies the issue of deployment significantly. By making stealth multicast externally invisible, one need only be concerned with the operation across an individual domain, not deployment/inter-operability with other domains nor adoption by applications using the Internet. Hence, stealth multicast provides a direct and immediate economic motivation for deployment.

Second, the principle of negligible QoS? impact ensures that despite the fact that packets are queued to create virtual groups, the QoS? requirements of the end user should not be violated. If the QoS? of the end user is significantly impacted, the change may impact the functionality of the applications utilizing the network and hence reveal the presence of stealth multicast. Due to the fact that QoS? is subject to both the perception of the end user and the requirements of the application, we define the term negligible QoS? impact to refer to the end user attributing the poor network performance to something other than the typical variations in Internet traffic behavior.

These two principles are directly impacted by the placement of the VGDM. Depending upon the behavior desired and the involvement of the source application, the VGDM may be placed at various points in the network and with varying levels of interaction from the source applications themselves. In fact, by varying the location of the VGDM, one can create a smooth transition towards IP multicast deployment, a side benefit of employing stealth multicast \cite{striegel03:StealthCSE}. While the VGDM could also be placed on an incoming link from another domain, the stealth and utility of such placement may be reduced depending upon the nature (aggregation) of the underlying traffic.

r1 - 16 Jul 2007 - 17:43:05 - AaronStriegel
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
Syndicate this site RSSATOM