Subject: RE: DNS opcode DISCOVER [Re: multicast DNS without multicast (in IPv6 only)]

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 12 Jan 2007 10:43:08 -0800

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. 

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-masked] 
> [mailto:[email-masked]] On Behalf Of Pekka Savola
> Sent: Friday, January 12, 2007 4:37 AM
> To: Paul Vixie
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> 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-masked] 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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Jan 2007 11:22:38 -0800

>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 un…

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

>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.