From: Alan L. Liu (aliu@cs.washington.edu)
Date: Tue Nov 09 2004 - 22:46:30 PST
The paper introduces a multicast architecture that is designed to handle
both dense and sparse membership. It is new in this respect because
previous multicast architectures were designed for the former, so for
sparse membership situations the overhead from sending membership
information is too high.
The paper describe cases where broadcasting membership information is
unscalable. It's clear that those messages would flood out to the entire
Internet, which is definitely Not A Good Thing. The paper also describes
how a single tree based multicast scheme which cuts down on membership
data broadcasts but has potential downsides in certain cases, for
instance when packets do not travel over the shortest path. Therefore
the paper suggests that there are certain cases one would want to use
one versus the other. This heterogeneity drives PIM's design, which
allows for either, and transitions between the two as well.
One problem with the paper is in the quality of evaluation is limited to
artificial use cases. For instance, all memberships and networks are
randomly generated. We know now that the Internet does not resemble a
random graph, and many properties cannot simply be applied from a random
graph and transferred to the Internet.
Using real traces would have been better, for instance if a very popular
file were downloaded using unicast, one could instead show how different
multicast methods would perform instead.
Frankly, I don't see that much relevance of this paper to our present
state of the Internet. Multicast seems to be such a fringe thing that
even when it has appropriate uses (e.g., for streaming live video),
content providers just overprovision. Seems like ISPs don't really care
either because they make money on bits being pushed around the network,
and I certainly never thought to myself, "gosh, it sure would be nice if
I had a multicast client for <current situation>." But if things are
cyclical and in the future bandwidth becomes scarce, one might want to
revisit multicasting. Until then, is it really useful to come up with
architectures that Internet routers must support?
This archive was generated by hypermail 2.1.6 : Tue Nov 09 2004 - 22:46:32 PST