From: Daniel Lowd (lowd@cs.washington.edu)
Date: Wed Nov 10 2004 - 02:58:47 PST
This paper was dense, devoid of any confirming experimental studies, and
seemed overly complex for a protocol that would depend on wide deployment.
To its credit, this paper successfully discussed the differences and
limitations of current multicast methods, and proposed something new.
Admittedly, my current tiredness is probably inhibiting my understanding
of a protocol which probably has a lot going for it. Unfortunately,
clear, intuitive writing is clearly not one of those things. Here are a
few examples:
"Data packets never trigger prunes. Data packets may trigger actions
which, in turn, trigger prunes." And you actually voted for that $87
billion before you voted against it, right? I understand that the prunes
may be triggered indirectly... but an indirect triggering is still a
trigering, right?
"The outgoing interface is set to that over which the IGMP report was
received from the new member." Hmmm... outgoing... received... new...
over which... from... While the authors successfully avoided any dangling
prepositions, it takes a bit too much thinking to decode what information
is used to set which values.
I also observed some acronyms lacking definitions or reference... but
perhaps I just missed their definitions early-on. In general, there were
lots of acroynms and qualifiers and details, but little "big picture" or
generic intuition. All sorts of lists were kept, but I had trouble
figuring out what these various lists *meant*. What does it mean to be
added to a list of sources? The authors were also fairly indirect about
how their protocol succeeded in meeting all of their requirements.
Some diagrams of networks larger than 4 or 5 nodes would have been really
helpful. Which router knows what? "RP-bit = 1" doesn't tell me very
much. And then experiments on larger networks would have been good, too.
Finally, all of this seems to require a lot of implementation in every
single router. And if a flaw is discovered after this deployment...
updates would have to be deployed. Routers might have to support 10
different versions of this. Ugh.
I do agree with the authors that the alternative versions of multicast
seem flawed. Sending packets to every host on network doesn't scale well
if you want multicast to work on the Internet. Maintaining a single
source-based tree not only increases path lengths, it also requires all
traffic to go through one source node. If you have many participants in a
multicast conversation, then this could easily overload that one router's
bandwidth.
If I were doing multicast, and wanted something that was moderately
efficient and deployable, I would try for something where end hosts
forward messages to others. Sort of a phone tree approach to multicast
notifications, rather than retraining all the operators in the middle to
handle special requests. By forwarding to nearby neighbors, network usage
could be reduced (relative to unicast), but without requiring complete
participation of the entire network. Of course, this would yield latency
that's potentially logarithmic in the number of listeners... so it
wouldn't be appropriate for all applications. But since I haven't heard
of many killer-apps that would inspire widespread multicast adoption...
new protocols at the end hosts seem more likely, even if my random musings
are flawed and irrelevant.
All in all, I'd have to say that this paper is relevant in its discussion
of other multicast strategies, its list of requirements for an effective
multicast strategy, and its reference to an IETF draft that is perhaps
more readable.
-- Daniel
This archive was generated by hypermail 2.1.6 : Wed Nov 10 2004 - 02:58:48 PST