Sure, I'll give you some comment :-).
First, on what I think of Cringley, at least as evidenced here:
He seems to like pontificating in public about stuff he doesn't
seem to know very much about. This is something that I,
for one, would never, ever do, right? :-).
To wit:
> The Internet architects, in their infinite wisdom, included
>in their original design a facility called multicasting that is hardly
>ever used.
Um, no. At least, depending how you define 'original'. Back in DARPAnet
days things were generally hooked up over point-to-point async,
so there wasn't any physical way to do hardware multicast. Once
Ethernet (and perhaps TokenRing) started to become more common
though, it was obvious that IP would need an extension to take
advantage of the fact that every packet was getting to every node
anyway. The multicast RFCs that I'm aware of are
966, 988, 1054, 1075, 1112, mostly by Deering, with the last being
the general benchmark for current-gen IP multicast. These all date
from the 80s, I believe - the early framers back in the 70s most
certainly did not 'include a facility in their infinite wisdom'.
Class D addreses seem to date to Postel RFCs 990 & 997 (I'm
looking up all the RFCs in an old book - Comer - blame him not me
for errors).
And also from Cringley:
> Baloney. With traditional magazine publishers currently
>losing about $300 million per year on their webzines, there is an
>enormous business opportunity. Some joker will solve the technical
>problems with multicast distribution shortly, then this column will
>appear unbidden to torment you forevermore.
Yeah, sure. And the same joker will develop cold fusion, Star Trek
transporters, remove network latency completely
by making photons move at infinite speed, and solve world hunger.
Anyway, enough of past history RFCs - current gen work is
progressing as well. Try
http://snad.ncsl.nist.gov/snad-staff/night/study.html (Stephen Nightingale)
for a really nice, concise overview (circa 1995) about recent mcast
work, including PIM (Protocol Independent Multicast), which seems
to be Deering revising IGMP etc. from RFC 1112 with a more adaptive
scheme for building mcast groups. (I think PIM is built into IPv6?
Anybody know?) The citations here seem to be all
"Internet drafts" - don't know what's made it to issued RFCs. Also,
the better leads off Nightingale's page seem to be broken :-(, but at
least it's a start. You can get through his site in half an hour and
learn a lot, I think.
Also, mcast on its own isn't really enough; you need notions of
reliability too. Just compare to the p-to-p world: Is UDP enough?
'Fcourse not. Need UDP *&* TCP. Same in mcast. For a good
site on reliable multicasts, try Tascnets MIST
http://www.tascnets.com/mist/doc/mist.html
and specifically the comparisons at
http://www.tascnets.com/mist/doc/mcpCompare.html
and even more specifically RAMP at
http://www.tascnets.com/mist/doc/RAMP.html
(Once you're there, have a look around Tascnets in general -
including TBONE (no relation to the TBONE Mark just dug
up in another context). Cool place.
Why,you ask, does Internet publishing for magazines etc. care
about rel mcast, instead of unrel? Well, for the same reasons
Cringley points out as to advantages of Internet publishing in pull
mode - ability to get an accurate read on who's paying attention, and
actually getting their 'push'. Of course, for this you *really* want
ACK based reliability, not NAK as is used in RAMP. ACK let's
you confirm not merely that every node gets every desired packet
(As NAK does), but also can be used to discover who's actually
'read' their bits, rather than just tossing them in the trash.Compare
this, say, to Time-Warner wanting the US Post Office not just
to confirm that every household was delivered their issue of Time,
but also discover who actually read the thing, rather than just sticking
it on the coffee table for a week, then throwing it out. Advertisers
care about this sort of thing...
Unfortunately, (naive) ACK definitely won't scale to the 'Net : just
imagine an efficient hardware multicast to a million nodes, with
a million point-to-point replies back to the origin! Ack! Ack! No
kidding. I'd like to see even Apache running on an Alpha try
to keep up with that :-). Of course, you don't have to be naive:
you can build a tree fanout, and acks don't go back to the root.
Still, ACK is generally seen as less scalable than NAK.
So, unrel mcast could conceivably scale pretty high, I guess, and
even NAK based rels could too. (I'm just guessing here, of course).
But I doubt ACKs could go to the limit.
Another question that would need answers wrt mcasts is mcast
over wireless IP networks - of particular interest to munchkin fans I think.
Does anyone know of wireless mcast work? Unlike Ethernet,
where's the 'shared bus' to deliver packets for free? Perhaps
all participating mcast nodes tune into the same wireless frequency,
not unlike how radio and TV broadcasts work. But I thought wireless
data networks are much lower power, and need very local transmisison
stations - kind of like current gen. cellular networks. Then a real
wide area mcast still needs to do a lot of p-to-p propagation to all
the transmitters, no? Hey - maybe put all of them on a common Ethernet
structure? Hell, I'm clueless here. Does anyone know??
Dan at Teledesic maybe?
Ron.
>============================================================
>
>
>I've fallen and I can't get up! Why Web pages like this one won't be a
>business success without new technology.
>
>
>
> By Robert X. Cringely
>
>
> ------------------------------------------------------------
>--------
> So you found my Web page! Maybe a friend told you about it.
>Maybe you heard me plug it on some radio or TV show. Maybe you are an
>old friend from my InfoWorld days who has been looking every week for
>my second coming. Now if I write something you find interesting, you
>just might bookmark this page. And if I am not only interesting, but
>very, very lucky, you might come back to that bookmark every week.
> This is no way to build a media empire, believe me.
> The Web magazine, of which this page is a minimalist
>example, is a very difficult business proposition. Sure, it looks good
>on the outside, with no printing, postage, paper, or returns. But on
>the inside, we see the potentially fatal flaw in the current Webzine
>economics: it isn't a subscriber medium. That's why very few web
>magazines make money. And with the likelihood that Web advertising
>won't reach break-even for another two to three years, most of the Web
>publications you read now aren't likely to survive.
> Read on to learn not only why this is the case, but also
>how the problem is likely to be solved.
> While the Internet offers a way to reach millions of
>potential readers, the nature of the Net to this point has been that
>those subscribers must be reached one at a time. This is point-to-point
>communication and it works well for electronic mail, but poorly for
>publishing electronic magazines or sending any large binary file to
>large groups of recipients.
> The trend among would-be Internet publishers has been to
>hire experts to help them on technical issues. These experts tend to be
>Internet experts, not publishing experts, and the solutions they offer
>don't fit well with the traditional publishing business model, relying
>on point-to-point techniques.
> The Internet distribution model publishers seem to be
>following most closely approximates a newsstand. The reader has to find
>the publisher's Web server and ask for the magazine every time it is
>published. Readers have to remember to look for the magazine, rather
>than have it automatically delivered to them on a regular schedule.
>Sounds like newsstand sales, and of course this kind of distribution
>has always been a problem for advertisers. This is why Playboy
>(primarily a subscription publication) has always been more profitable
>than Penthouse (primarily a newsstand publication).
> This distinction between subscriber and newsstand
>distribution could be the difference between making a profit and making
>a loss for most Web magazines. And that's the difference between life
>and death. Turning a Web magazine from newsstand to subscription allows
>an immediate 50-100 percent increase in ad rates. Better still, the
>circulation can be audited, which appeals to advertisers. As a would-be
>media mogul, I like that.
> The common thinking among Internet businesspeople is that
>the advertisers will just have to learn a new way of behaving and
>accept this browsing model. Publishers fear they'll starve to death
>before that learning process is complete.
> The way to turn your web magazine from a financial loser to
>a financial winner, then, is to PUSH it out to subscribers. That
>explains the current frenzy of push technologies, because some sort of
>push is necessary for this part of the Internet to succeed.
> But there are lost of push technologies and some of them --
>some of the most popular, in fact -- aren't suitable for sending a big
>magazine out over the wire every week. Pointcast, for example, is lousy
>for this application. That's because Pointcast would send a copy to you
>and then a copy to me and then a separate copy to each of the many
>thousands of subscribers. And since each of these subscribers would be
>expecting their copy on Monday morning, the Net would be flooded and
>chaos would reign.
> Nope, we need something better. We need a technology that
>can send one copy of the magazine out to be shared by every reader.
>It's called multicasting.
> The Internet architects, in their infinite wisdom, included
>in their original design a facility called multicasting that is hardly
>ever used. Multicasting is sending a signal, or in this case a file,
>from a single workstation to the Internet as a whole. One file goes
>everywhere and is literally grabbed by qualified subscribers as it
>passes by.
> While multicasting was never envisioned as a method of
>publishing Internet magazines, it is perfectly suited to that task. The
>fact that the academic side of the house (the Internet) never needed
>any such thing and has not bothered with a cohesive set of standards on
>the subject does not mean that the capability is not there, rather it
>was one of the initial Internet design requirements.
> The original purpose of the Internet was to make sure that
>in the case of thermonuclear war, the e-mail would go through. This did
>not mean that the Pentagon would send out a DEFCON alert to Ft. Meade
>and another to Ft. Monmouth and another to Patrick AFB and another to
>Carswell AFB, but one message to everybody -- a multicast. It also
>meant that Cheyenne Mountain could send a single message and have it go
>to every SAC base and nowhere else, which is how one would use
>multicasting to reach a specific group of subscribers.
> There is an entire class of approximately 15,000 Class D
>Internet addresses set aside for multicasting, though rarely used.
> With multicasting, a magazine can be published by sending a
>single copy from a Class D address to a specific Internet region, say,
>North America. So from a single PC, one copy of an electronic magazine
>can be sent to all of North America.
> Multicasting is a completely different form of distribution
>ideally suited to Internet magazine publishing. It is very network
>efficient and offers guaranteed delivery. It was made possible by the
>fundamental design of the Internet, but to this point has not been
>effectively implemented. Many Internet routers do not yet fully support
>multicasting, and this is the major problem facing multicast push
>technologies.
> There are also some technical problems to be solved for
>multicast. For one thing, most of the research to date on multicasting
>has been aimed at distributing multimedia information to large groups
>of recipients right now. The best example of this is Mbone, the
>Multimedia Backbone that uses multicasting to deliver sound and video
>across the Internet. Mbone demands large amounts of network bandwidth
>to keep megabytes of video data synchronized in near real-time. Mbone
>is very impolite. Distributing a magazine, however, requires a version
>of multicasting that is polite, that makes room for other traffic on
>the Net. As long as the magazine is there in the morning when
>subscribers turn on their computers, it's there on time.
> The published research on multicasting also depends on
>algorithms that do not scale well. While it is presently possible to do
>multicasting within a subnet -- say to several thousand workstations on
>a campus -- conventional wisdom says that multicasting to the entire
>Internet is not feasible.
> Baloney. With traditional magazine publishers currently
>losing about $300 million per year on their webzines, there is an
>enormous business opportunity. Some joker will solve the technical
>problems with multicast distribution shortly, then this column will
>appear unbidden to torment you forevermore.
>
>
>
>