I still don't understand what the plan is. There is a lot of Internet broadband content distribution going on today. I do not see where this proposal fits in.
Is this the choice of the right tool or 'have hammer, will use it' or 'have always wanted this particular hammer and looking for excuse to get one' ? > -----Original Message----- > From: Ted Hardie [mailto:[EMAIL PROTECTED] > Sent: Friday, January 12, 2007 2:23 PM > To: Hallam-Baker, Phillip; Pekka Savola; Paul Vixie > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > namedroppers@ops.ietf.org; ipv6@ietf.org > Subject: RE: DNS opcode DISCOVER [Re: multicast DNS without > multicast (in IPv6 only)] > > 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 --------------------------------------------------------------------
