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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 12 Jan 2007 11:29:50 -0800

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-masked]] 
> Sent: Friday, January 12, 2007 2:23 PM
> To: Hallam-Baker, Phillip; Pekka Savola; Paul Vixie
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> 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-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/>
> >>
> >
> >--
> >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: Jeroen Massar <[email-masked]>
Date: Sat, 13 Jan 2007 13:53:43 +0000

Hallam-Baker, Phillip wrote:
> There is a lot of Internet broadband content distribution
> going on today. I do not see where this proposal fits in.

"Content Distribution" in the form of Akamai and other such solutions
are GREAT for Big Companies(tm).

But Big Companies(tm) are not the only users of the Internet!

Multicast allows EVERY user of the Internet to very easily use a small
amount of bandwidth to send one single copy into the Internet and have
tens of thousands of other users enjoy it.

You could argue "just upload your video's up to youtube". Some users
don't want their works to be owned by third parties, some people want to
provide it in different formats. The Internet is about freedom, freedom
in what you do and how you do it. Having multicast available to end
users gives extra freedom to the users of the Internet.

Multicast will allow that for anything without having to play around in
the application stack and having to make application/protocol specific
caches for every sort of application. Of course we could just do
everything over HTTP, but hey where is the fun in that?

Also, what is the largest cost for ISP's anyway associated by those
traffic hogs like P2P? They are transmitting the same kind of data over
and over over their transit links.

Multicast would solve that as the data is only sent ones and fanned out
to the end users that want it. Read: your data goes over the transit
once, and only once: that actually saves money... and that is where one
of the catches lies, do transit providers want ISP's to save money!? :)

For warez-content distribution it seems that NNTP is nowadays the clear
winner anyway, with companies solely dedicated to providing access to
the TeraBytes of "NNTP Caches" that they have set up.

The big problem with multicast of course is the configuration of it and
the trust one has to have in its peers, as it can create a lot of havoc
when something goes bad, see for nice cruel bedtime horror stories the
various mbone,m6bone etc lists ;)

Greets,
 Jeroen

--
Additional lesson on how to send bypass greylists, especially:
telnet sa.dom.com 25
EHLO purgatory.unfix.org
250-sa.dom.com
250-PIPELINING
250-SIZE 102400000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: <[email-masked]>
250 2.1.0 Ok
RCPT TO: <[email-masked]>
450 4.7.1 <[email-masked]>: Recipient address rejected: Greylisted for 1
minutes

And then send your mail ;)