At 10:43 AM -0800 1/12/07, Hallam-Baker, Phillip wrote: >I am really confused here. > >First, I know that multicast has a base in the IETF. Is there at this point >any real prospect of widespread use? Multicast violates the principle of >keeping the core of the Internet as simple and unchanging as possible. >Multicast is also the amplification mechanism to beat all amplification >mechanisms.
There is ongoing (okay, possibly petering out) discussion on the NANOG list at the moment on this topic, related to "internet video" (the NANOG archives are at http://www.merit.edu/mail.archives/nanog/ . The threads are "Network end users to pull down 2 gig" and "Internet Video: The Next Wave of Massive Disruption to the US Peering Ecosystem".) One of the points made early on by Sean Donelan is that there isn't a bright line here where multicast is useful above and isn't useful below. To quote one of his points: Multicast doesn't have to be real-time. If you collect interested subscribers over a longer time period, e.g. scheduled downloads over the next hour, day, week, month, you can aggregate more multicast receivers through the same stream. TiVo collects its content using a broadcast schedule. I believe you will find the rest of the thread gives an interesting set of perspectives on how multicast fits in among other technologies; particularly, it gives you a sense of how one operational community might use to smooth spikes in usage. Ted >A distributed caching model achieves the same effect with considerably less >impact on the core Internet infrastructure. Instead of doing branching in the >network core we do it at the next level up in the stack. This allows us to >build in security in a coherent way. It also eliminate the probably bogus >assumption that all participants are interacting synchronously. This is not >the case in video-on-demand due to pause features. > >What is it that is being proposed? Is it a feature that is to assist >deployment of multicast or a feature that has some other advantage that >happens to use multicast? > > >I would like to see a concise statement of objectives and requirements that >does not reference a previous post in the thread. > > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Pekka Savola >> Sent: Friday, January 12, 2007 4:37 AM >> To: Paul Vixie >> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; >> namedroppers@ops.ietf.org; ipv6@ietf.org >> Subject: DNS opcode DISCOVER [Re: multicast DNS without >> multicast (in IPv6 only)] >> >> [DNS opcode DISCOVER] >> >> On Thu, 11 Jan 2007, Paul Vixie wrote: >> > yes, it has. >> > >> >> why, under $DIETIES green earth would you want to push a dead >> >> technology? The IESG is dead-set against this. >> > >> > because the IESG has turned over N times during those 8 >> years, and the >> > idea is still solid and useful and interesting, and the current >> > proposed RFC is experimental, and most importantly, because >> the need >> > for it will continue to resurface until we push it over the >> top of the >> > hill and roll it down to the town. >> >> The problem was, AFAIR, that allocating opcodes requires a >> Standards Action. No experimental spec can do that. If >> DISCOVER is to be revived it will need to use one of other >> publication processes. >> >> -- >> Pekka Savola "You each name yourselves king, yet the >> Netcore Oy kingdom bleeds." >> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> >> -- >> to unsubscribe send a message to >> [EMAIL PROTECTED] with the word 'unsubscribe' >> in a single line as the message text body. >> archive: <http://ops.ietf.org/lists/namedroppers/> >> > >-- >to unsubscribe send a message to [EMAIL PROTECTED] with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
