I think Cringeley's completely on the right track on pushing for
multicast, and it is true that the multicast "plumbing" has been
around for over a decade. I also like his newsstand vs. subscriber
metaphor; in all the crap I've read about push, I hadn't seen that
simple point made.
As to the satellite arena: Teledesic spends a lot of time explaining
why our low-Earth-orbit satellites (with small footprints and
consequently very high frequency reuse of over 300 times over the US)
are a much better platform for two-way communications than traditional
geostationary satellites (that are 25 times farther out,
continent-size footprints, frequency reuse between 1 to 12 times over
the US).
For nationwide multicast, however, GEO satellites probably do have a
valuable role to play. Basically, think of everyone in the country
having access to a constant data stream by plugging their PC into
their Direct Broadcast Satellite antenna. Your PC saves the info it
thinks you want and ignores the rest. Also, if we ever have a
nationwide system of Web caches (like @Home was looking at), DBS would
be a great way of pre-loading the caches every night.
However, http://www.direcpc.com is ignoring the inherent multicast
nature of their service (they send every Web page to the whole country
whether they want to or not) in order to target the unicast consumer
Internet market. This is a little odd, since they have the same total
capacity for the entire US (30 Mbps), that cable modem brings to 300
homes.
Remember, as Deering says, that unicast communication is merely a
special case of multicast.
P.S. I believe Protocol Independent Multicast (PIM) has been approved
as a Proposed Standard but not given an RFC number yet. There's this
constant confusion of, oh, that will be coming with IPv6. PIM (both
sparse mode and dense mode) work fine with IPv4. All the IP security
work that's being implemented for IPv6 is being implemented for IPv4.
Ditto for all the QOS priority headers. Notice a trend here? Now,
try to explain what's going to cause a transition to IPv6.
- dan
-- Daniel Kohn <dan@teledesic.com> Teledesic Corporation +1-206-602-6222 (voice) 602-0001 (fax) http://www.teledesic.com-----Original Message----- From: Ron Resnick [SMTP:resnick@interlog.com] Sent: Wednesday, June 11, 1997 1:55 AM To: Rohit Khare; FoRK Cc: Eve Schooler; rajit@cs.caltech.edu Subject: Re: Cringely weighs in on multicast push
At 09:29 PM 6/10/97 -0400, Rohit Khare wrote: >http://www.pbs.org/cringely/archive/may2997_text.html > >Recently, the Real Cringely pontificated on the problems with push, how >mcast might just solve them, but there are too many engg roadblocks. He >thinks some smart-aleck entrant will yet upset TIBCO, PointCast, etc, >and make mcast work where it currently cannot. > >"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." > >I refrain from comment for a moment, just to hear what some FoRKees >might think first. > >RKSure, 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. > > > >