Subject: Re: mboned: BGMP & DVMRP status Q.

From: Tom Pusateri <[email-masked]>
Date: Tue, 23 Mar 2004 11:18:41 -0800

In message <[email-masked]> you write:
>I was told that in the routing area meeting of the 59th ietf,
>it was declared that BGMP will go to experimental and DVMRP to PS.
>
>I was wondering what kind of discussion has preceeded these
>decisions, as and what the large group of people is that is in
>agreement with it.
>
>As for me, i would strongly suggest to make BGMP today informational
>and DVMRP historic:
>
>I don't think there's sufficient proof that the IETF wants for the
>model proposed by BGMP to be the standard solution for interdomain
>ASM, nor do i see any real activity in taking BGMP from powerpoint
>to the real world (*oops*, from drafts to routers). As far as DVMRP
>is concerned, i think it should be classified historic because 
>it violates what i would consider to be the most fundamental Internet
>IP multicast routing architecture principle: Separation/independence
>of RPF and tree building.
>
>Cheers
>        Toerless

Each routing protocol submitted as a proposed standard has an
applicability statement describing its use. While you may not use
DVMRP for global multicast, it is a viable alternative in certain
cases.

Therefore, there is no reason not to move it forward as a proposed
standard as long as the areas where it is applicable are specified.

Now, as for "the most fundamental Internet IP multicast routing
architecture principle: Separation/independence of RPF and tree
building", this has caused as many problems as it has solved so I
wouldn't be waving this flag...

Tom

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 23 Mar 2004 11:18:41 -0800

Tom

---

From: Pekka Savola <[email-masked]>
Date: Tue, 23 Mar 2004 21:28:55 +0200 (EET)

> standard as long as the areas where it is applicable are specified.

I'd argue for moving it to Informational, and placing a strong 
disclaimer in the spec itself.

We can achieve interoperability and deployment in those specific cases
without going to standards track; IMHO, Informational would send the
correct signal to the IETF and the community about the "applicability"  
(or lack thereof) of the protocol in general.

FWIW, BGMP should also be Informational.  It's useful to document it,
but again, it needs stronger disclaimers so that folks don't think
it's actually useful as specified.

I'll certainly raise these issues in the appropriate Last Calls or
other fora when given a chanche if the PS + Exp line continues..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: [email-masked]
Date: Tue, 23 Mar 2004 09:42:03 -0800

Cheers
        Toerless

---

From: David Meyer <[email-masked]>
Date: Tue, 23 Mar 2004 12:11:26 -0800

>> of RPF and tree building.

	Regarding BGMP:

	It is not that advancing BGMP to Experimental is in and of
	itself problematic; in fact, this seems completely
	reasonable and is arguably consistent with what it means
	to advance to Experimental. Rather, my concern is the
	around implicit statement the IETF is making by taking
	both of the IPv4 ASM candidate protocols (MSDP and BGMP)
	to Experimental and SSM to PS. Just to be very clear
	here, taking SSM to PS is again completely reasonable.  

	My concern, however, is whether the combination of these
	actions implicitly states something like "inter-domain
	IPv4 ASM isn't an IETF standards track activity". The
	reasoning might go something like "What does the IETF
	have on standards track for inter-domain ASM...?" (well,
	nothing), and go from there. Of course, one might argue
	that bidir is the eventual solution here, and hence
	"someday" this argument will be moot. 

	So one of the problems here, as Bill correctly pointed
	out, is that we don't have anyone working on an
	alternative (and that this can be taken as a measure of
	the interest in a hypothetical alternate IPv4
	inter-domain ASM protocol). It might also be taken as a
	statement like "MSDP works well enough"...but then why
	don't we put MSDP on standards track? Well, other than
	that no one likes its architecture, etc. 

	Summary
	------
	It is the statement potentially implied by our
	classification of the various protocols described above
	which is of concern. In particular, it doesn't seem 
	outside the realm of possibility for one to conclude that
	inter-domain ASM isn't an IETF standards track activity
	(which of course, mod some future event with bidir, it
	currently is not). However, it would seem clear that this
	not our intended statement. This, combined with the fact
	such a conclusion would not reflect deployment practices
	in the IPv4 Internet, is what I find troubling.  

	Dave

---

From: David Meyer <[email-masked]>
Date: Tue, 23 Mar 2004 12:11:26 -0800

Regarding BGMP:

	Summary
	------

	Dave

---

From: Pekka Savola <[email-masked]>
Date: Tue, 23 Mar 2004 21:28:55 +0200 (EET)

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 23 Mar 2004 12:35:19 -0800

>	in the IPv4 Internet, is what I find troubling.  

I don't think we should worry about what we "imply". Each protocol
should be moved forward according to the best information we have
available without unnecesary delay. If someone wants to waste their
time making inferences from the combination of these actions then
so be it but it certainly should not concern us.

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 23 Mar 2004 12:35:19 -0800

Tom

---

From: Jeremy Hall <[email-masked]>
Date: Tue, 23 Mar 2004 16:00:43 -0500 (EST)

In the new year, Toerless Eckert wrote:
> On Tue, Mar 23, 2004 at 03:39:56PM -0500, Jeremy Hall wrote:
> > If we are using MSDP as "the official method" of ASM interdomain 
> > controlling, then the IETF status should reflect that.  It's confusing 
> > enough to have all the multicast protocols in their various status, but as 
> > it is now, you have to have history in running the stuff to be able to 
> > successfully deploy it, or in the least, have a mentor that can point you 
> > in the right direction.  What is wrong other than philosophical scaling 
> > issues with making the status of the protocols consistent with what is 
> > deployed?
> 
> Other question: How would changing the IETF status of the documents
> improve on the chance of getting working IP multicast deployment.
> Eg: Almost all of the protocol specs are everything but helpful to
> understand the challenges of IP multicast deployment. 
> 
If we make it clear what is useful, but not relevant to current 
deployment, new implementors will have an easier time deciding what 
exactly to implement and how to make that happen.  With more vendors 
coming online WRT multicast, the more likelihood the code will be present 
on day 1 when a new router vendor is deployed into the industry.

_J

> Cheers
> 	Toerless
> _______________________________________________________________
> user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
> web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
>

---

From: Jeremy Hall <[email-masked]>
Date: Tue, 23 Mar 2004 16:00:43 -0500 (EST)

_J

---

From: David Meyer <[email-masked]>
Date: Tue, 23 Mar 2004 13:02:46 -0800

>> >	in the IPv4 Internet, is what I find troubling.  

	Tom,

>> available without unnecesary delay.

	With regard to the latter statement, no disagreement (and
	FWIW, I didn't take anything said in this thread as
	suggesting anything should be unnecessarily delayed). 

>> If someone wants to waste their time making inferences from
>> the combination of these actions then so be it but it
>> certainly should not concern us. 

	Understand. The implication thing just occurred to me
	during the open routing area meeting, and so I thought I
	might recount it here. Basically, since I try to take a
	system-wide view of what the IETF does (both in terms of
	its technology, as well as its process), occasionally
	things like this turn up.    

	In any event, if it is all a non-issue, so much the
	better.  

	Dave

---

From: David Meyer <[email-masked]>
Date: Tue, 23 Mar 2004 13:02:46 -0800

Tom,

	Dave

---

From: Bill Fenner <[email-masked]>
Date: Tue, 23 Mar 2004 13:50:54 -0800

>I think if we can not get an agreeement about this fundamental point
>in the IETF (and i was under the impression that we did have this
>agreeement since 1993/4 when PIM was first introduced), then i think
>it will be very hard to agree on any other points about the IP multicast
>architecture.

I don't think that the integration of routing and tree building protocol
is a problem on the scale that DVMRP is useful.  It may affect the
scalability, but other of DVMRP's problems are probably more important.

[Sorry, combining replies to two different messages]
>So you think that new vendors should implement DVMRP ?

Well, should new vendors implement RIP?

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Tue, 23 Mar 2004 13:50:54 -0800

Bill

---

From: [email-masked]
Date: Tue, 23 Mar 2004 15:37:28 -0800 (PST)

> Well, should new vendors implement RIP?

This should be determined by each vendor - NOT the IETF.

Greg

---

From: [email-masked]
Date: Tue, 23 Mar 2004 15:37:28 -0800 (PST)

Greg

---

From: Jeremy Hall <[email-masked]>
Date: Tue, 23 Mar 2004 17:05:11 -0500 (EST)

In the new year, Toerless Eckert wrote:
> On Tue, Mar 23, 2004 at 04:00:43PM -0500, Jeremy Hall wrote:
AFAIK that recommendation was made several years ago.  Since DVMRP is 
still deployed, it should be considered for implementation by potential 
vendors.

> I also have my doubts about the way you describe the behavior of vendors
> who now get into the game. I don't think they care about what's written
> in the specs themselves - in my experience, commodity vendors do implement
> whatever tops their RFPs as long as it is an RFC - never mind it's status.
> 
If a vendor waited for an RFP, it is already behind the game curve.  
Vendors that already understand the industry are welcomed inthusiastically 
by ISPs.  Vendors that must be hand-held are more the norm and thus we're 
used to it, but if this happened in the unicast world, nobody would 
tolerate it.  Imagine if there was as much confusion surrounding MPLS as 
there is surrounding multicast.  Sure there are many flavours of MPLS out 
there, but the fundamentals aren't disputed.  Are RSVP and LDP considered 
experimental protocols?

> Last but not least: Let's not target vendors but rather users with
> whatever we do, eg: ISPs and enterprises!

By making the relevant protocols proposed standards, ISPs have an easier 
time getting the vendors to comply.  In the end, resistence is futile to 
progress, and anything that does not provide a clear direction is 
resistence.

I'm not saying we have to throw out this protocol or that one, I'm simply 
saying we need to unite together and decide what the direction should be, 
whatever that might be.  AFAIK ISM and ASM have been going strongly for 
several years, perhaps we should come to the table and make some hard 
choices.

_J

---

From: Jeremy Hall <[email-masked]>
Date: Tue, 23 Mar 2004 17:05:11 -0500 (EST)

_J

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 12:29:23 -0800

Actually i think historic is more appropriate than informational
because i would hope that status does both honor the important role 
it actually has played in the development of ip multicast but it as
well would makes a point about preferring PIM-DM over DVMRP even for
small scale deployments for reasons of being better in line with
the automatic RPF/unicast congruency and modularization between
routing and tree building.

If at all, i would recommend DVMRP today only for small, maybe
ad-hoc networks that do not run _any_ unicast, but only multicast
(so that you actually do not have a unicast routing protocol nor
 unicast reachability in the network).

Cheers
	Toerless

---

From: Jeremy Hall <[email-masked]>
Date: Tue, 23 Mar 2004 15:39:56 -0500 (EST)

_J

---

From: Jeremy Hall <[email-masked]>
Date: Tue, 23 Mar 2004 15:39:56 -0500 (EST)

_J

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 12:49:24 -0800

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 12:40:08 -0800

Dave,

All your questions are valid. I think we might want to start
trying to resolve them by defining through IMDOC first what the
architecture looks like - and do it in such a way that the most
useful classification of the involved protocols will be clearer at
the end of the process.

Imagine for example everybody who has Internet at home today would be
able to do IP multicast across the Internet to everybody else in the
Internet. Do you really think that would work with ASM ? And i am
not even talking about MSDP scalability, let's assume we have really 
brutally well scaling implementations (*grin*). I am talking about
the basic DoS problem of the ASM service model and the nature of the
Internet at large.

Eg: I think the ASM service model (rfc1112) can only be internet standards
track for scopes that have certain characteristics of control and/or
membership (either lots of control or friendly membership). This 
can never be the case for the Internet, neither in IPv4 nor in IPv6. 
We only see it working because effectively what is global scope in
IP multicast today consists of a pretty small subset of the Internet
which actually is still quite friendly.

On the other hand, ASM of course makes perfect sense for all smaller
scopes that do have this property (not only todays limited Internet
multicast scope, but more specifically enterprise scopes, scopes of
research networks across continents, etc..).

So, besides the point that i think we should clarify the applicability
of ASM along these lines in IMDOC: What impact would this applicability
limitation of ASM have on the RFC status of both the service model RFC
(1112 - which needs to be reworked to include ipv6 anyhow) as well as
the protocols ?

Eg: Are there protocols on standards track that have similar applicability
limitations ?

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 12:40:08 -0800

Dave,

Cheers
	Toerless

---

From: Bill Fenner <[email-masked]>
Date: Tue, 23 Mar 2004 15:30:22 -0800

>If they think they have a market for RIP, then they should implement it,
>as well as IGMP proxying or PIM-DM, but not DVMRP.

I don't get it.  DVMRP is more flexible than IGMP proxying and more
efficient than PIM-DM, but you want the IETF to try to remove it from
the selection of tools that a customer may have available?

  Bill

---

From: [email-masked]
Date: Tue, 23 Mar 2004 17:35:49 -0800 (PST)

> as well as IGMP proxying or PIM-DM, but not DVMRP.

Huh, I thought the customers decided what they want to deploy? We 
(vendors) can make recommendations, and I would hope that they (customers) 
research the options (IETF) on their own. But to think Toerless has 
the final word on what can and can't be deploy kinda' scares me. Do I need to 
go buy blue shoes now too?? ;-) ;-)

Greg

---

From: [email-masked]
Date: Tue, 23 Mar 2004 17:35:49 -0800 (PST)

Greg

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 12:29:23 -0800

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 12:46:25 -0800

> wouldn't be waving this flag...

If this is your opinion, then i think we have a major disagreement.

Note that i think it is perfectly fine to have separe unicast and
multicast topologies, it just has to be a problem of routing protocols,
not a problem of tree building protocols.

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 12:49:24 -0800

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 12:46:25 -0800

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 13:13:39 -0800

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 13:13:39 -0800

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 16:03:46 -0800

>> the selection of tools that a customer may have available?

    The IETF should not make any subjective calls on technology. They have
    been wrong in the past and will continue to be wrong in the future.

    We (the IETF) need to build the right stuff. And sometimes that means, 
    not the too creative stuff.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 16:03:46 -0800

Dino

---

From: Bill Fenner <[email-masked]>
Date: Tue, 23 Mar 2004 15:30:22 -0800

Bill

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 15:20:41 -0800

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 15:20:41 -0800

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 09:39:37 +0900

> the basic DoS problem of the ASM service model and the nature of the

Neither MSDP nor BGMP scales, regardless of how you implement it.

> Eg: Are there protocols on standards track that have similar applicability

All.

However, more fundamental problem is that almost no one
understand what is the appropriate scalability requirement
for multicast.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 09:39:37 +0900

All.

						Masataka Ohta

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 16:48:06 -0800

>> Neither MSDP nor BGMP scales, regardless of how you implement it.

    Correction. Any protocol scales to a specific level or size. From my
    inspection, MSDP seems to be holding around 2500-3000 sources right now.
    What has done that before it's time?

    And BGMP could work too, it's all a matter of cost and complexity. After
    all we got OSPF to work, you think that was cheap?

>> understand what is the appropriate scalability requirement

    I think people do, but as time goes on, things keep changing and people
    change their mind.

Dino

---

From: Bill Fenner <[email-masked]>
Date: Tue, 23 Mar 2004 16:55:44 -0800

>architecturally, i think the IETF should promote IGMP proxying over
>DVMRP for simple routers because of explicit join vs. flood & prune as
>well as simplicity

I think that IGMP proxying is too simple to be deployed in networks with
more than one router.

>and it should promote PIM-DM over DVMRP because of
>clear separation of RPF and trees.

I still don't see why this aspect is so important.

  Bill

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 16:54:05 -0800

> > Eg: Are there protocols on standards track that have similar applicability

;-))

> understand what is the appropriate scalability requirement

Good point. I actually have pretty simple ideas about the level of
scalability at which i'd call multicast successfull enough for the time
being:

  - IP multicast service connectivity between all hosts that also
    have IP unicast connnectivity.
  - few 100k worth of active application instances across the Internet core.

And i think we can do this with SSM or ASM/embeddeRP today.

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 16:54:05 -0800

;-))

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 16:42:54 -0800

On Tue, Mar 23, 2004 at 03:30:22PM -0800, Bill Fenner wrote:
> efficient than PIM-DM

Are we playing quartett with cards of protocols now ? If so, then yes, you win.

If not: architecturally, i think the IETF should promote IGMP proxying over
DVMRP for simple routers because of explicit join vs. flood & prune as
well as simplicity, and it should promote PIM-DM over DVMRP because of
clear separation of RPF and trees.

>  but you want the IETF to try to remove it from

Where did i say that the IETF should remove it from the selection ?
I just said that it fits best into worthy historic artefacts section
of the shelf - in my opinion. Or else: please define what the selection
of the IETF is.

Cheers
	Toerless

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 10:09:55 +0900

> And i think we can do this with SSM or ASM/embeddeRP today.

Not at all.

The basic problem is that multicast routing table entries can
not be aggregated, as was proven in our INET'98 paper, which
makes multicast communication resource (routing table entry)
reserving one.

That is, multicast scales only if people pay money proportional
to the duration and area of the communication and the payment
mechanisms are scalably automated.

Note that RSVP and related protocols made it completely wrongly.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 10:09:55 +0900

Not at all.

							Masataka Ohta

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 17:12:10 -0800

>> You misunderstand the word "scale".

    Does any protocol then scale if I decide that my table size needs to be
    5,000,000 routes?

    I guess IPv6 scales because it has 128 bits?  ;-)

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 17:12:10 -0800

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 17:13:53 -0800

>> makes multicast communication resource (routing table entry)

    If you use a shared tree where a group range uses the same root, you
    can aggregate the state.

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 17:15:28 -0800

> I think that IGMP proxying is too simple to be deployed in networks with

To be more precise - any stub network without redundancy or with extreme
simple redundancy. Like for example two PIM core router connecting to 
20 DSL-RBAS routers that are only running IGMP proxy and that connect each
to maybe - 20k users@home, each of which has a home router also with IGMP
proxy. To me that is something like 400,020 routers. But based on your
definition of a network, it might as well be 400,020 networks of one router
each...

There is a set of other similar stub network scenarios where i'd pray
to get IGMP proxying any time before i get a flood&prune edge.
(of course a fully PIM/SM/Bidir/SSM based network is better, but i think
 that wasn't considered to be under contention anyhow, right ?)

> I still don't see why this aspect is so important.

Reuse of operational (unicast) knowledge, strong promotion of congruent
ubiquitous deployment, knowledge separation between unicast topology and
multicast tree engineering and troubleshooting, simplicity, minimization of
reinvention of the wheel, personal preferences, pigheadedness.

Nevertheless, i would never admire a PIM-DM trophy in a museum, while
i would do so for DVMRP: If we have to recommend a flood&prune protocol
in the IETF at all, then i would simply choose PIM-DM out of necessity
(reasons above), as much as i may admire the more elegant design of DVMRP.

Cheers
	Toerless

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 10:28:49 +0900

>     If you use a shared tree where a group range uses the same root, you

Wrong, completely.

Route from source to the tree root, which essentially is unicast,
can be aggregated.

Route from the root to the receivers can not be.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 10:28:49 +0900

Wrong, completely.

					Masataka Ohta

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 16:48:06 -0800

Dino

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 10:38:42 +0900

>     Does any protocol then scale if I decide that my table size needs to be

Yes, of course.

With a proper parallel architecture and protocol, it costs about
O(N*log(N)) to support N routes that 5,000,000 is doable.

>     I guess IPv6 scales because it has 128 bits?  ;-)

It does not, though IP architecture does scale.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 09:59:39 +0900

>     Correction. Any protocol scales to a specific level or size.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 09:59:39 +0900

Masataka Ohta

---

From: Bill Fenner <[email-masked]>
Date: Tue, 23 Mar 2004 16:55:44 -0800

Bill

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 16:42:54 -0800

Cheers
	Toerless

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 17:13:53 -0800

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 17:15:28 -0800

Cheers
	Toerless

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 10:38:42 +0900

Yes, of course.

						Masataka Ohta

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 22:05:40 -0800

>> Route from the root to the receivers can not be.

    Sorry, I have an existance proof (read: implementation).

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 22:05:40 -0800

Dino

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 15:13:06 +0900

>     Sorry, I have an existance proof (read: implementation).

Sorry, you don't have any proof.

					Masataka Ohta

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 22:12:20 -0800

>> Sorry, you don't have any proof.

    Then I guess I nothing more to discuss with you. Thanks for wasting my
    time. I can only blame myself.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 22:32:06 -0800

>>   Could you tell us why you consider 5,000 is enough and
>>   5,000,000 is too much for the Internet, please?

    My point is that "scaling" is relative.

>>   Please, could you tell us why you consider 5,000 is enough and
>>   5,000,000 is too much for the Internet, Dino?

    I said "routes" in the general sense. And when I was typing the message
    I was thinking unicast routes.

    But I do believe we can build routers that can support 50K to 100K 
    multicast routes. We can for unicast so I don't see why we can't do it
    for multicast.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 22:32:06 -0800

Dino

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 15:36:30 +0900

Dino Farinacci wrote:

>     Then I guess I nothing more to discuss with you.

Thank you confirming that you have nothing to discuss
rest of us. Bye.

						Masataka Ohta

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 22:39:43 -0800

>> Thank you confirming that you have nothing to discuss

    No, just you (see original email below). 

    I'm having several very good private discussions on this topic as I type.

Dino

-------------------------------------------------------------------------------
Date: Wed, 24 Mar 2004 15:36:30 +0900
From: Masataka Ohta <[email-masked]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en-us, en
To: Dino Farinacci <[email-masked]>
CC: [email-masked], [email-masked], [email-masked],
   [email-masked], [email-masked], [email-masked]
Subject: Re: mboned: BGMP & DVMRP status Q.
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

						Masataka Ohta

-------------------------------------------------------------------------------

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 22:39:43 -0800

Dino

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 15:48:02 +0900

>     I'm having several very good private discussions on this topic as I type.

That's fine. Please keep them private forever.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 15:48:02 +0900

Masataka Ohta

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 22:54:51 -0800

> there, but the fundamentals aren't disputed.  Are RSVP and LDP considered 

Quite in agreement, Jeremy. I specifically said commodity vendors,
and the diffeentiation i make is that a commodity vendor is one that
would never bother to implement something that's still a draft.

> time getting the vendors to comply.

Yes, but for this to happen, the ISPs have to drive the process. IETF
participation of customers in protocols is quite varyng, and for those
that primarily are of interest (maybe only today) to enterprises,
unfortunately there isn't much participation.

> In the end, resistence is futile to progress, and anything that does
> not provide a clear direction is resistence.

? Come again, Locutus ? ;-)

> several years, perhaps we should come to the table and make some hard 

What would you propose ?

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 23 Mar 2004 22:54:51 -0800

What would you propose ?

Cheers
	Toerless

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 15:13:06 +0900

Masataka Ohta

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Mar 2004 22:12:20 -0800

Dino

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 15:36:30 +0900

Masataka Ohta

---

From: Alex Zinin <[email-masked]>
Date: Tue, 23 Mar 2004 23:20:19 -0800

Masataka,

  <hat = RTG AD>

  Please keep it technical and refrain from using offensive tone.

-- 
Alex Zinin

---

From: Alex Zinin <[email-masked]>
Date: Tue, 23 Mar 2004 23:20:19 -0800

Masataka,

  <hat = RTG AD>

-- 
Alex Zinin

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 16:29:39 +0900

Dear all (save Dino);

Below is a short lecture on scalability of multicast
and routing.

For detailed explanation, see section 2 of my INET paper:

	http://www.isoc.org/inet98/proceedings/6d/6d_3.htm

Routes can be aggregated because

	1) packets are routed with destination addresses

	2) similar addresses are assigned to hosts in an area

With multicast, assumption 2) does not hold. A multicast address
is assigned to a dynamic set of destinations in various areas.

Those who believe otherwise should first try to solve easier
problem of aggregating unicast routes without CIDR. Assign
a multicast address to each /24 in IPv4 swamp and aggregate
them.

With resource reservation with QoS routing, assumption 1) does
not hold.

In either case, separate routing table entry is necessary for
each communication, which is why the communication must be
charged proportional to the duration and area of the
communication.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 16:43:09 +0900

>>>Route from the root to the receivers can not be.

What is the technical point of Dino denying my technical statement

>    Sorry, I have an existance proof (read: implementation).

without giving any technical point or reference?

					Masataka Ohta

---

From: Alex Zinin <[email-masked]>
Date: Tue, 23 Mar 2004 23:40:44 -0800

I'll take this off the list.

-- 
Alex Zinin

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 16:29:39 +0900

Dear all (save Dino);

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 16:43:09 +0900

Masataka Ohta

---

From: Alex Zinin <[email-masked]>
Date: Tue, 23 Mar 2004 23:40:44 -0800

-- 
Alex Zinin

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 20:21:06 +0900

IMAI san;

>   Reading your mail, you may feel 5,000,000 routes is ridiculous
>   requirement. I agree with you if we can limit to use
>   multicast only for alternative usage of current broadcasting
>   media like TV and radio.

Without regulation on radio wave frequency, there will be a lot
lot lot more than 5,000 broadcasters.

If multicast is freely available, people with more than two
family members at a distance, the number of which will be a lot
more than 5,000,000, will want to have a multicast group or two
for thier families.

That's essentially why multicast must be charged.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Mar 2004 20:21:06 +0900

IMAI san;

						Masataka Ohta

---

From: IMAI Yuji <[email-masked]>
Date: Wed, 24 Mar 2004 20:41:23 +0900

Dino, and all.

  I don't want to be involved in the flaming war. I just want to
  know and share the truth of multicast.

From: Dino Farinacci <[email-masked]>
Subject: Re: mboned: BGMP & DVMRP status Q.
Date: Tue, 23 Mar 2004 22:32:06 -0800

>     I was thinking unicast routes.

  Then, you used "routes" as unicast one in following sentence
  you said, didn't you.

=========================================================================

From: Dino Farinacci <[email-masked]>
Message-Id: <[email-masked]>
Subject: Re: mboned: BGMP & DVMRP status Q.
Date: Tue, 23 Mar 2004 17:12:10 -0800

>     Does any protocol then scale if I decide that my table size needs to be
    
==========================================================================

  OK, Next let's talk about MULTICAST route. As I wrote in
  previous mail, I want scalable multicast protocol to
  handle millions of (S,G) type MULTICAST routes. Do you think it
  reasonable requirement or crazy one, Dino?

>     multicast routes.

  To discuss precisely, let me know "100K multicast routes" above
  are grains of (S,G) entry or aggregated multicast entries by your
  method.

  If you mean (S,G), Dino said same opinion with Ohta. Exactly
  saying, Ohta may be much more aggressive than Dino. He told me
  once it is easy to handle 1,000,000 (S,G) type multicast routes.

  As he wrote in his paper of INET98, he analyzed that in order to
  support 1,000,000 multicast routes, router must store grain
  (S,G) entries without aggregation and router must handle
  keep alive messages relatively equal the number of route
  entry.

  If he is correct, such router must process keep alive messages
  almost 4,000 times per second. For me, his analysis seems
  correct theoretically. However I am not sure it is possible to
  make, sell and be accepted such monster router in the
  market. It must cost too expensive.

>     We can for unicast so I don't see why we can't do it
>     for multicast.

  For me, above sentence sounds too rude. (If my expression is
  politically wrong, I apologize previously.) If we can do the
  things for multicast as same as for unicast, we have already
  achieved the multicast deployed Internet ten years ago by the
  similar method we have deployed unicast.

/*
 *  Yes. Ohta always sounds offensive because that's his
 *  style. I don't like his way. However, reading his paper, we
 *  can be aware the point why multicast is not so easy. I keep in
 *  my mind to carefully consider to separate his essence of
 *  theory from impression of him.
 */

  Let me go back and ask all who believe aggregation of
  multicast route is possible. Show us the method or proof much
  more precisely. I looked for and read several papers that claims
  so but I could not be convinced. 

  Alex and Bill, please stop me if above question is trivial in
  this community and you have convinced about multicast
  aggregation.

  And I appreciate if we could avoid the word "believe". It
  seems easily cause religiouss flaming.

  Thank you.
----
Yuji

---

From: IMAI Yuji <[email-masked]>
Date: Wed, 24 Mar 2004 20:41:23 +0900

Dino, and all.

    

/*

  Thank you.
----
Yuji

---

From: IMAI Yuji <[email-masked]>
Date: Wed, 24 Mar 2004 21:53:00 +0900

Masataka,

From: Masataka Ohta <[email-masked]>
Subject: Re: mboned: BGMP & DVMRP status Q.
Date: Wed, 24 Mar 2004 20:21:06 +0900

> That's essentially why multicast must be charged.

  You just talking only about the number of POTENTIAL users.

  Realistically thinking, configuring and keeping multicast
  peering costs so expensive that small broadcasters could not
  pay the money for ISPs. Look squarely at the real current
  status of multicast. Many distinguished operators and
  researchers of Internet2 involved in keeping "countable"
  multicast channels for Access Grid. Inter-domain multicast
  channel is precious resource, now.

  And it's you who said

From: Masataka Ohta <[email-masked]>
Subject: Re: mboned: BGMP & DVMRP status Q.
Date: Wed, 24 Mar 2004 10:09:55 +0900

> mechanisms are scalably automated.

  How much will you price the multicast channel for the IESG
  conference by Access Grid? Most difficult point is how to
  share the expense among ISPs. As it includes political layer
  factor, it seems almost impossible to decide automatically.

  Such complicated contract and negotiation will be possible
  only by limited mega-media. Or you say it's just my
  "believing" and start flaming?
----
Yuji

---

From: IMAI Yuji <[email-masked]>
Date: Wed, 24 Mar 2004 21:53:00 +0900

Masataka,

  And it's you who said

---

From: IMAI Yuji <[email-masked]>
Date: Wed, 24 Mar 2004 18:05:24 +0900

Hi, all.

>     multicast routes. We can for unicast so I don't see why we can't do it

  My mail to ask Dino the question on routing-discussion is hold
  by mailman on www1.ietf.org, I attach it once again.

  Sorry for mess.
----
Yuji

============================================================================

Subject: Re: mboned: BGMP & DVMRP status Q.
From: IMAI Yuji <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked], [email-masked],
	[email-masked]
Date: Wed, 24 Mar 2004 13:29:57 +0900
X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley)

Dino,

  Reading your mail, you may feel 5,000,000 routes is ridiculous
  requirement. I agree with you if we can limit to use
  multicast only for alternative usage of current broadcasting
  media like TV and radio. 5,000 will be enough because almost
  channel flows from the anchor desks in N.Y., L.A. or Atlanta
  spread over world wide Internet. Since such flow of popular
  programs are always received by many ISPs, each routing entry
  may be very stable and you may be able to assign multicast
  addresses to aggregate neatly.

  However, once we want the application like instant message
  systems with vic & rat, situation change drastically. In other
  words, why don't you want to provide Access Grid service for
  the consumer market? Members of a virtual venue are sparsely
  distributed over the Internet subscribing different
  ASes. Using SSM or PIM-SM in short cut mode, number of routing
  entry become as same as number of transmitters. That means routes
  grows up to millions very easily.

  To make matter worse, curious customers rapidly loiter from
  venue to venue, joining and pruning (S,G). Whenever they zap
  the channel, PIM-SSM signaling travels from receiver to most
  nearest branching router marking or erasing routing entries.

  That's why I want you to scale your routers up to millions
  multicast routes. If you will not, neither we will be support
  instant video message on the multicast.

  Again.

---

From: IMAI Yuji <[email-masked]>
Date: Wed, 24 Mar 2004 13:29:57 +0900

Dino,

  Again.

---

From: IMAI Yuji <[email-masked]>
Date: Wed, 24 Mar 2004 13:29:57 +0900

Dino,

  Again.

---

From: IMAI Yuji <[email-masked]>
Date: Wed, 24 Mar 2004 18:05:24 +0900

Hi, all.

  Sorry for mess.
----
Yuji

Dino,

  Again.

---

From: Rick Boivie <[email-masked]>
Date: Wed, 24 Mar 2004 11:23:35 -0500

Yuji,
I agree.

It's seems pretty clear that current multicast schemes do not provide very
good support
for an important class of applications (including IP telephony,
videoconferencing,
e-meetings, multiplayer games and other applications in which there are
likely
to be very large numbers of distinct multicast groups).

As the Internet Architecture Board said (in RFC 2902) "providing for many
groups
of small conferences ... scales badly given the current multicast model".

So if we want tapplications like the above to work when there is limited
bandwidth
in the first mile (e.g. DSL, cable modem, wireless etc.) we need a
multicast scheme that
can support very large or unlimited numbers of small groups.

Rick Boivie
IBM T. J. Watson Research Center
[email-masked]

IMAI Yuji <[email-masked]>@ietf.org on 03/23/2004 11:29:57 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:    [email-masked], [email-masked], [email-masked],
       [email-masked], [email-masked],
       [email-masked], [email-masked]
Subject:    Re: mboned: BGMP & DVMRP status Q.

Dino,

  Again.

---

From: Rick Boivie <[email-masked]>
Date: Wed, 24 Mar 2004 11:23:35 -0500

Yuji,
I agree.

Rick Boivie

To:    [email-masked]

Dino,

  Again.

---

From: [email-masked]
Date: Wed, 24 Mar 2004 11:43:06 -0800 (PST)

> IBM T. J. Watson Research Center

Rick,

I'd love to have those problems!!! ;-) ..but for now, we don't even have a 
good live example due to the lack of last-mile deployment. 

Yes, I'd love to improve on the scaling of our current mcast solutions, 
but until the deployment warrents it, let's focus on solving the 
deployment barriers. Then when the availablity of mcast begins attracting 
apps and users we can gather imperical data as to what about the current 
scheme does and does not scale.

As an example, please recall NetAid. This WAS a successful large audience 
mcast event which exposed the scaling limits in RTCP - which was solveable 
at the application layer. Until we have other similar examples exposing 
other limitations, I feel we are just shooting in the air.

Greg

---

From: [email-masked]
Date: Wed, 24 Mar 2004 11:43:06 -0800 (PST)

Rick,

Greg

---

From: Rick Boivie <[email-masked]>
Date: Wed, 24 Mar 2004 13:54:34 -0500

>good live example due to the lack of last-mile deployment.

There seems to be plenty of last mile broadband deployed.  Note
that Nielsen/NetRatings says that 49.5 million or 38% of home Internet
users in the US connect via broadband.
http://www.nielsen-netratings.com/pr/pr_040108_us.pdf

The % of homes with broadband is even higher in some other countries of
course.

So lack of last mile deployment doesn't seem to be the issue.  Rather
the problem seems to be that multicast doesn't provide very good support
for large numbers of small groups  --  as the IAB said in RFC 2902.

My 2 cents.

Rick

[email-masked]@ietf.org on 03/24/2004 02:43:06 PM

To:    Rick Boivie/Hawthorne/IBM@IBMUS
cc:    IMAI Yuji <[email-masked]>, <[email-masked]>,
       <[email-masked]>, <[email-masked]>,
       <[email-masked]>, <[email-masked]>,
       <[email-masked]>, <[email-masked]>,
       <[email-masked]>
Subject:    Re: mboned: BGMP & DVMRP status Q.

Rick,

Greg

> >     Does any protocol then scale if I decide that my table size needs
to
> be

---

From: Rick Boivie <[email-masked]>
Date: Wed, 24 Mar 2004 13:54:34 -0500

My 2 cents.

Rick

Rick,

Greg

to

---

From: [email-masked]
Date: Wed, 24 Mar 2004 13:10:53 -0800 (PST)

> for large numbers of small groups  --  as the IAB said in RFC 2902.

..and what percentage of them have mcast enabled? Even better, what 
percentage of them have mcast enabled to the mcast-anabled Internet and 
not just a walled-garden deployment? I'd say less than 1%.

Greg

---

From: [email-masked]
Date: Wed, 24 Mar 2004 13:10:53 -0800 (PST)

Greg

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Mar 2004 04:37:03 +0900

>   You just talking only about the number of POTENTIAL users.

I'm talking about the number of potential groups or
senders.

Who else are talking about the miserably small number
of currently active groups?

Note that, as you know, in Japan, there should be a lot more
than 5,000 home users receiving multicast.

>   conference by Access Grid?

It involves not only routing table entry but also bandwidth
reservation.

So, the answer depends on how expensive unicast bandwidth
reservation will be, which, IMHO, should cost more than
routing table reservation.

For example, if trans-ocean 6Mbps unicast costs $1/min, multicast
conference with 10 members involving trans-pacific and trans-
atlantic link will cost a little more than $2/min.

Multicast should costs less than doing it with multiple
unicast. Or, people just use multiple unicast.

>   Most difficult point is how to

It involves policy a lot different from that of BGP but is
not political.

The difficulty is to think with BGP and its policy where
communications are flat rated and ASes have their policy
to choose the most favorable next hops.

However, you must be aware that, with telephony, end users
have the right to choose the most favorable long distance
and international operators.

With resource reservation, those who pays have the rights
to have policies. That is, end users choose the route
most favorable to them. It means we can't use DV routing
protocol, such as BGP, but must use LS routing protocol
with rate information flooded to end users, which means
there must be aggressive aggregation.

For multicast policy, it should also be noted that down
stream side of a tree can not have any policy or the
tree will be destroyed to have loops due to inconsistent
policies. So, the policy can be set only by the root
or the sender. It is a proof why BGMP and MSDP are no good.

>   "believing" and start flaming?

It has nothing multicast specific. So, you are saying only
mega-media can use telephony.

In the real world, money is the tool to hide complicated
contract and negotiation. You can just pay the designated
money. There can be arbitrary complex bilateral agreements
between telephone operators and resource reserving ISPs. But,
so are ISPs today with BGP. The important point is that
end users just pay.

We have designed and implemented such LS protocol and
an associated signaling protocol. Search the web with
HQLIP and SRSVP.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Mar 2004 04:37:03 +0900

Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Mar 2004 04:39:14 +0900

> for large numbers of small groups  --  as the IAB said in RFC 2902.

More serious problem is to provide very good support for
large numbers of medium sized groups.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Mar 2004 04:39:14 +0900

Masataka Ohta

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Mar 2004 11:50:02 -0800

On Wed, Mar 24, 2004 at 10:52:33AM -0800, John Zwiebel wrote:
> It -might- be a good idea to suggest some number of participants
> in a conference (or whatever kind of application) under which
> unicast should be the preferred transport method.

But that would also be relative to the total size of the tree in terms
of how many total hops are on it. Or the shape of the treee. Imagine
you've got a group of 50,000 people watching a sports game. We would probably
say that using multicast offhand is fine for this size of receivers, but
if 49,999 are in the USA and one lonely guy in mongolia wants to watch it too,
you'd probably argue that the 10 hop branch down to mongolia might not want 
to waste a state on that. On the other hand if this tree actually has 
25,000 viewers in mongolia and 25,000 in the USA (because it's i don't know
mongoliva vs. the us at the game of soccer) , then the long branch into
mongolia would not be a problem.

At some point in time i'd really love to have someone revisit the idea
which i think in the past Dino and DaveO claimed ownership for: carry
forward across PIM joins the total number of viewers on the downstream
branch. This total number of viewers would be an excellent measure of
importance of a particular OIF entry and could also be used to derive a
per viewer cost model.

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Mar 2004 11:50:02 -0800

Cheers
	Toerless

---

From: [email-masked]
Date: Wed, 24 Mar 2004 13:37:22 -0800 (PST)

Plus, please remember, ANY application with more than one source only 
gains the benefits of mcast transit at the source, not the receivers. Each 
receiver still has receive traffic from each source. So sure, the network 
still gains from mcast replication, but the receivers last mile still has 
N incoming streams.

Greg

On Wed, 24 Mar 2004, John Zwiebel wrote:

> I'd like to ask how many receivers it takes to make the transition
> from a "small group" to a "large group".
> 
> Considering:
>    -- the last-hop deployment problems
>    -- the limited BW on the last hop
>    -- the current difficulty of providing a SSM based multicast tree
>    -- the perceived limit of the total number of groups msdp can handle
> 	(currently about 4000, based on the fact that we're handling less
> 	than that now)
> 
> It would be "fine" with me if everything was multicast (in fact
> I'd probably prefer it) but that would interfere with the deployment
> of some applications.
> 
> I'm looking for a way of suggesting to the user that "for right now,
> until certain multicast questions are answered and deployment 
> established,
> you should use unicast with a view toward transitioning to multicast
> as each of these barriers are removed.
> 
> It makes the app developers problem more difficult to solve, but
> provides a realistic roadmap with which they can make informed 
> decisions.
>

---

From: Bill Nickless <[email-masked]>
Date: Wed, 24 Mar 2004 13:42:43 -0600

At 10:52 AM 3/24/2004 -0800, John Zwiebel wrote:

>until certain multicast questions are answered and deployment established,
>provides a realistic roadmap with which they can make informed decisions.

This is not inconsistent with an end-to-end automatic tunneling model, 
designed in such a way that the internetwork can optimize the transport 
when the capability is available or desired.

What do I mean?

Consider the existing SSM model.  Multicast traffic is requested by 
interested receivers, and is identified by the (S,G) (Source,Group) 
addresses.  This receiver request effectively "grafts" the receiver onto a 
source-rooted distribution tree for the (S,G).  Once the distribution tree 
is created, traffic flows from the source to each interested receiver.

Such a process could be implemented entirely by hosts, without any explicit 
network support.  The distribution tree would still be rooted at the 
source, but the tree would look more like a star.  In other words, for 
small groups the source host itself would receive the receiver traffic 
requests and handle the replication.  Each receiver would get a copy of the 
requested traffic over the existing unicast infrastructure.

Explicit network support could be deployed incrementally.  If the network 
element (router?) was prepared to do multicast replication, it would 
intercept any receiver traffic requests and "bundle" them together as they 
go towards the source.  Likewise, as the traffic comes from the source 
towards interested receivers, the network element would handle replication.

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP: 021D EB98 03B3 2E83 3D71  0397 251D 819A D0BE EA32 [email-masked]

---

From: John Zwiebel <[email-masked]>
Date: Wed, 24 Mar 2004 10:52:33 -0800

Considering:

---

From: [email-masked]
Date: Wed, 24 Mar 2004 13:37:22 -0800 (PST)

Greg

---

From: Bill Nickless <[email-masked]>
Date: Wed, 24 Mar 2004 13:42:43 -0600

What do I mean?

===

---

From: John Zwiebel <[email-masked]>
Date: Wed, 24 Mar 2004 10:52:33 -0800

Considering:

---

From: [email-masked]
Date: Wed, 24 Mar 2004 15:53:01 -0800 (PST)

> large numbers of medium sized groups.

Really? More serious? I don't doubt that it is an issue - in the future - 
I just know of no current networks suffering from global mcast scaling 
today. 

The scaling issue I'm facing involves me, and my ability to gain console 
access to every router on earth in order to enable PIM. Until that is 
solved, or the need for me to do it myself is eliminated, then I'd love 
to help tackle the scaling issues we encounter.

Greg

---

From: [email-masked]
Date: Wed, 24 Mar 2004 15:53:01 -0800 (PST)

Greg

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Mar 2004 08:01:54 +0900

Toerless Eckert wrote:

> to waste a state on that.

Who, do you mean is "you" which argue?

> On the other hand if this tree actually has 
> 25,000 viewers in mongolia and 25,000 in the USA

What if there are 1 receivers in different 100 countries?

What is there are 10 receivers in Mongolia?

There is no generic answer and they are policy issues of the
groups to be determined by the groups' administrators.

A realistic approach is to let the root optionally allow
to specify the areas of multicast, which is what I
implemented. Group administrators should use OOB mechanism to
guess the expected number of receivers in each area.

> importance of a particular OIF entry and could also be used to derive a

That is a stupid idea ignoring network cost and familiar facts
that both routes and receivers change dynamically.

First, the issue is cost performance one that mere number of
receivers without cost information to reach them is useless.

Second, at some point of the tree in USA, the number of receivers
will often reach 1 that there will be transition, just like the
case with mongolia, to unicast. However, the mechanism is almost
useless to reduce the number of routing table entries on the
backbone, where the resource is most precious.

Third, it involves interaction between intermediate routers
and a upper layer protocol in addition to IGMP to let the
upper layer protocol issue unicast packets to control
individual receivers, which does not scale.

Forth, even if there is enough number of receivers in
Mongolia, they may be using different transpacific
links, sharing the same one or the situation changes
dynamically.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Mar 2004 08:01:54 +0900

Masataka Ohta

---

From: Bill Nickless <[email-masked]>
Date: Wed, 24 Mar 2004 17:41:22 -0600

>to help tackle the scaling issues we encounter.

My scaling issue is getting the money to replace every IEEE 802.1 bridge on 
earth with one that can do IGMPv3 snooping properly.  Oh yeah, MLDv2 
too.  And scheduling downtime to do the necessary forklift upgrades.

When I write "every" I'm quite sure it's well in excess of 99%.

===

---

From: Bill Nickless <[email-masked]>
Date: Wed, 24 Mar 2004 17:41:22 -0600

===

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Mar 2004 17:21:01 -0800

> When I write "every" I'm quite sure it's well in excess of 99%.

The other option of course is always to forget snooping,
disable it and be happy. With the typical size of broadcast domains (getting
smaller), attachment speed (getting faster, 100Mbps standard) as well as
processing speed of the hosts themselves (> 1Gbps PCs) and relative speed
of the possible aggregate of multicast traffic to be received (< 10 Mbps
at best in typical enterprises), this rather is getting less than more of
a problem  - within an enterprise environment with i'd hope overwhelmingly
friendly user population (recipe doesn't work for public access or
universities or the like).

On the other hand: If you do have that many switches and are able to act
like a single determined buyer for all of them, then it should be no 
problem to get exactly the feature you want from a vendor.

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Mar 2004 17:21:01 -0800

Cheers
	Toerless

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 25 Mar 2004 07:44:55 -0800

>When I write "every" I'm quite sure it's well in excess of 99%.

I was thinking that AMT might suit this purpose nicely. Even if you
have multicast connectivity but you don't have IGMPv3, you can deploy
a relay to get around those old switches until they can be replaced.

http://www.ietf.org/internet-drafts/draft-ietf-mboned-auto-multicast-02.txt

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 25 Mar 2004 07:44:55 -0800

Tom

---

From: [email-masked]
Date: Thu, 25 Mar 2004 09:37:51 -0800 (PST)

> http://www.ietf.org/internet-drafts/draft-ietf-mboned-auto-multicast-02.txt

Thanks Tom!! I was just about to write the same thing :)

Additionally, AMT will also solve my need to enable PIM on every router. 
=D

The gap I see in the current AMT spec involves the anycast solution for 
mcast/ucast boundary detection. I feel this solution is too crippling in 
that it only addresses last-mile unicast networks but does not allow for 
the bridging of mcast islands over ucast oceans - for mcast enabled 
enterprises, and certain mcast-challanged IXs. It also may make 
load-balancing too complex/difficult/challanging/ugly.. dunno - pick one.

Greg

---

From: [email-masked]
Date: Thu, 25 Mar 2004 09:37:51 -0800 (PST)

Greg

---

From: Bill Nickless <[email-masked]>
Date: Thu, 25 Mar 2004 13:13:06 -0600

>http://www.ietf.org/internet-drafts/draft-ietf-mboned-auto-multicast-02.txt

AMT is close to what I discussed earlier in this thread.

However, AMT (as I read in the referenced draft) requires host support 
*and* explicit network support for deployment.  AMT also requires the 
allocation and management of (an) AMT Subnet Prefix and AMT Unicast AS ID(s).

The system I outlined earlier in this thread only requires host support to 
operate correctly, which means deployment can be driven directly by 
interested applications.

Later, after a critical mass of deployment exists, it's possible to extend 
the underlying network to do more efficient replication.  But again, this 
network capability is not required for correct operation by early adopters.

===

---

From: Bill Nickless <[email-masked]>
Date: Thu, 25 Mar 2004 13:13:06 -0600

===

---

From: Rick Boivie <[email-masked]>
Date: Fri, 26 Mar 2004 11:55:11 -0500

>not just a walled-garden deployment? I'd say less than 1%.

And that probably won't change anytime soon since:
-  the route protocol traffic would be huge if millions or 10's of millions
   of people started using multicast for videoconferencing, say
-  the bandwidth used for the data could be huge if large numbers of people
started
   using multicast for large conferences

So if we want to support large numbers of videoconferences say, it seems we
need a scheme that
-  has minimal (or zero) route protocol traffic
-  limits the amount of bandwidth a given user can use e.g. enough to send
   to 10 or 20 (or x?) destinations, say.  And in those rare occasions when
   somebody needs to send to a very larger number of destinations, they can
   reserve a "broadcast channel" using traditional multicast schemes and
perhaps
   pay for that (?) has Ohta has suggested.

I might also add that xcast seems to be exactly the right approach for
supporting
large numbers of videoconferences since
-  there's zero route protocol traffic
-  xcast (as currently constituted) limits the amount of bandwidth a given
user
   can use

So xcast can eliminate the problems that to this point have held back the
broad adoption of multicast and videoconferencing.

Rick

[email-masked] on 03/24/2004 04:10:53 PM

Greg

---

From: Rick Boivie <[email-masked]>
Date: Fri, 26 Mar 2004 11:55:11 -0500

Rick

Greg

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Mar 2004 09:02:44 -0800

If there was demand for 10th of millions of users doing video-conferencing
between 1..10 people, then you'd already see big hosting servers with
some (proprietary) application that would allow you to do this by
mean of a simple unicast hub&spoke traffic flow model between participating
clients and this server.  Yes, there actually like this deployed already,
yes, it may be increasing in use with the proliferation of VoIP, but as long
as you don't see folks running those servers crying for help from the network,
proposing protocol development for this type of application does not
seem to target any specific business case problem, right ?

Or what am i missing here ?

Cheers
	Toerless

-- 
Thanks
   Toerless Eckert

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 26 Mar 2004 17:28:52 +0000

Toerless
 
<on rant>
you're missing the fact that there was no business for unicast IP - the web came 
10 years after

anyhow engineers dont do business cases - last time they did they did a load of .com crap -
we are tryting to engineer varioius types of network support for scalable
group communication - there is NO point in discsussing why we shouldnt do multicast on a list dedicated to
deployment of multicast   - thats for other lists (like ipv6 has ipv6haters - people who want to laugh at multicast
should set up a "friends of the ISP profiteers doing unnecesary packet replication, and overcharing media server" maillist
and go discuss how silly we all are there-  (but remember what the chinese say (beware you may become
what you laugh at)

build it (and build it right) and they will come...

any how all the h323 stuff for doing loads of hub based video conf is a real pain to configure and run - thats why
we dd all the mmconf stuff on ip multicast - it was because doing something in the net was gong to reduce the pain 
for application developers.

the problem is that we did it all when the net wasnt fast enough so we were asking for 3 thigns to be changed
simulatenously - qos or overprovision force voice/video,  do multicast , and do rtp tool sets - this was 2 things
too many - but starting now, the net is provisioned ok, the rtp tools and end system s/w are all there, so now we
only need to do 1 thing right....multicast -most the pieces for multicast are lying around now...just a lot of
people who know how to put them togetehr have got bored and gone on to other stuff (like setting up p2p systems ,
or doing wireless and mobile right, or
creating lists for laughing at people who revist the same wrong arguments on IETF lists year after year:)

<off rant>

comment on percetnage argument below
 - what percentage of end systems/hosts sites have ipv4  deployed (i.e. non natted so you can reach their
server with unicast)? grenville armiatage had some stats which showed that walled garden unicast is pretty bad.
we dont see people not doing voip because of that, we see lots of creative nat traversal work - 

keep the faith...

 >>> > >   5,000,000 is too much for the Internet, Dino?

 cheers

   jon

---

From: Tim Chown <[email-masked]>
Date: Thu, 25 Mar 2004 04:46:10 +0000

>   -- the current difficulty of providing a SSM based multicast tree

Hi John,

Do you have a pointer to documentation describing the issues causing
this difficulty?

Thanks,
Tim

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Mar 2004 09:02:44 -0800

Cheers
	Toerless

-- 
Thanks
   Toerless Eckert

---

From: Tim Chown <[email-masked]>
Date: Thu, 25 Mar 2004 04:46:10 +0000

Hi John,

Thanks,
Tim

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 26 Mar 2004 17:28:52 +0000

Toerless
 
<on rant>

<off rant>

keep the faith...

 cheers

   jon

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 27 Mar 2004 08:22:27 +0900

> build it (and build it right) and they will come...

That's the point.

All the standard track multicast protocols are built wrongly,
ignoring the scalability property of multicast on the number
of routing table entries.

Dino is guilty. So are those who are for SSM.

Multicast does not scale in a way they dreamed.

						Masataka Ohta

PS

Another major wrongness is in IGMP, which should be independent
from multicast routing protocols but is revised as new multicast
routing protocols are invented.

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Mar 2004 13:19:18 -0800

On Fri, Mar 26, 2004 at 05:28:52PM +0000, Jon Crowcroft wrote:
> <on rant>
> you're missing the fact that there was no business for unicast IP -
> the web came 10 years after

No i am not missing that. See below.

> anyhow engineers
   ... who work in research ...
> dont do business cases

> - last time they did they did a load of .com crap -
> group communication - there is NO point in discsussing why we shouldnt do
[... skipping a few MB ranting ...]
> creating lists for laughing at people who revist the same wrong arguments on IETF lists year after year:)

John, i am not disagreeing with anything you say, i just wanted to
mention the point that we do not live in a world anymore where the internet
solution suite is grown solely through non-commercial interest. Yes, i
would love to have the good old pre 1995 times back, because then we
would be able to get multicast deployed much more easily. Short of
going back in time we have to include the problem of how to create
sufficient business incentive for commercial adoption into a plan to
progress technology beyond the realms of research. And my only point about
that piece was that i think there's so far way too little commercial
provisioning of video-conference facilities... but that i think there's
actually more pickup of that due to VoIP standardization, and maybe
we will see sufficient demand for multi-party (video) conferencing within
a few years to justify moving scalability solutions for the problem space
into the network layer. Right now i would not hold my breath for this.

And of course i completely agree with the fact that small group
multicast is a fascinating research topic, and i would like to see
more research based prototyping and deployment of this. I just wanted
to point out that mboned is not necessarily the best target audience
for such activity.

Cheers
	Toerless

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 27 Mar 2004 08:22:27 +0900

That's the point.

						Masataka Ohta

PS

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Mar 2004 13:19:18 -0800

Cheers
	Toerless