Frequently Asked Questions – Stealth Multicast
General
Performance
Not currently. The first prototype will be available in an alpha version for most UNIX variants based on the libpcap library in fall of 2004. A mailing list will be made public near the end of summer of 2004.
Yes. The simulations for stealth multicast are based on the ns-2 simulator and the GenMCast module for ns-2. The latest simulation code is available upon request and the fixed builds that include stealth multicast are available at the GenMCast webpage.
In our initial studies, the delay impact for stealth multicast is actually quite small. By varying parameters such as the MHT (Maximum Hold Time), one can easily bound the maximum delay that packets can receive. For instance, an additional delay of only 2-5 ms can actually work quite well but yet is a relatively small portion of a 25-40 ms RTT. Our initial studies of the ND live traffic will offer performance results based on actual traffic. In fact, the savings of stealth multicast itself can more than pay for itself on the congested upstream links.
What about scalability?
For stealth multicast, a packet can only be held as long as the MHT. Thus, the maximum queue size is dictated by the MHT times the line rate. Since one must keep the delay impact relatively small, the MHT is inherently limited by the end effect on QoS. Our submission to SIGCOMM fully examines the queue space required for the VGDM.
How do you pick out amenable unicast vs. non-amenable unicast traffic?
The answer is that stealth multicast does not. All traffic is queued into virtual groups. Hence, even normal unicast traffic gets delayed the same as unicast traffic that will be converted into multicast. We believe this is not necessarily a bad thing as all traffic is affected uniformly. While one can employ filtering to reduce traffic that has not recently yielded multicast conversions or absolute rules developed by the administrator, this solution is not required with stealth multicast. As noted in the earlier question, the net impact is fairly small with regards to the RTT of the packet.
What about RTP, HTTP, etc.?
For protocols beyond the L4 headers (beyond UDP, TCP), it is possible to employ customized parsers to recognize redundancy in the L7 header. However, our initial work is strictly focusing on completely redundant L7 payloads.
How much benefit will stealth multicast provide?
One of the issues of considerable debate is whether or not multicast is a worthwhile endeavor to pursue. If only 5% of the overall traffic is multicast, why even bother? We believe that stealth multicast will yield a benefit of around 10-15% when comparing the overall savings of multicast. A key point to remember is that 5% of the actual net traffic (simply measuring net bandwidth consumed) being multicast may really be a 50% savings as 1 multicast packet may represent tens, hundreds, or even thousands of unicast packets.
Furthermore, we believe that with our work on stack optimization, we can easily extend the benefits of stealth multicast to 30-40% and beyond.
Isn’t the main problem economics versus benefit?
A valid criticism of multicast is that ISPs have little incentive to deploy multicast. In essence, one is asking an ISP to deploy a service that reduces the amount of the product that they are selling. Fortunately, the very idea of stealth multicast was conceived from the notion of economics. In short, can one change the principle of multicast such that the benefits are directable? Or, can an ISP be the sole beneficiary of multicast?
At its core, stealth multicast allows an ISP to deploy the service without the knowledge of the customer. Since no interactions are required from external domains, servers, or clients, the very process itself can be kept hidden. Thus, an ISP can deploy stealth multicast and reap the benefits solely for themselves. In the event that an ISP wishes to extend stealth multicast to the customer, the sender-driven nature of stealth multicast (benefits are known at the time of conversion) lends itself extremely well to correctly assessing a price point to converted traffic. Unlike traditional multicast where pricing and provisioning can be quite nebulous, stealth multicast addresses these problems directly in its core architecture.