Re: Cringely weighs in on multicast push

Joe Kiniry (kiniry@cs.caltech.edu)
Wed, 11 Jun 1997 12:38:13 -0700 (PDT)


Ron Resnick writes:
> 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.

i'm sure eve can give us some even-more-up-to-date references on work
related to the above, right eve? <g> the above does look like
interesting work though; i'll have to spend some time there (when i
have some - time, that is). in fact, i can pretty much guarantee it
is/will be good work since i'm friends with the p.i. from umass (jim
k.) and my first industry job offer was from tasc. :)

> 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.

actually, this is what ibm's cryptolopes claim to provide - exactly a
p-2-p ack for arbitrary content much like the acks you get with
smtp-derivatives nowadays on wintel boxes (and the next five years
ago). interestingly enough, the privacy issues are what folks and
corporations are screaming about, not the network load-related ones.

> 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.

what about some kind of collated, inverse-multicast acks? is there
such a thing?

> 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?

or perhaps the karma-kids?

---removed dan's excellent and well-balanced comments---

Mark Baker writes:
> On Wed, 11 Jun 1997, Dan Kohn wrote:
> > Remember, as Deering says, that unicast communication is merely a
> > special case of multicast.
>
> Moreover, unicast to an object is a special case of multicast to an
> object group, even with response semantics - be they reliable mcast ACKs
> or responses from an RPC to that group (ala VS).
>
> Put *that* in your pipe and smoke it you "document caching solves all
> my problems" web-heads! 8-)

puff puff...cough cough.

> Mark "recently confirmed at the Church of Objectology" Baker

joe