Subject: A technical discussion on multicast

From: Masataka Ohta <[email-masked]>
Date: Wed, 25 Feb 98 18:16:24 JST

As there are too much political mails here, let me initiate
a technical discussion for a change of air.

The topic is multicast and aggregation.

I have recently proven that multicast routing table
aggregation is impossible and, thus, multicast address
assignment aggregation is meaningless.

So, I want to receive some comments on it here.

IDMR is not an appropriate WG for the discusison, because,
according to the proof, IDMR is a wrong WG to exist.

The proof follows:

It is impossible to aggregate multicast routing table entries.

That is, the minimum number of state on each multicast router must
be proportional to the number of multicast data of which
is running over it.

The reason is that, the locations of receivers are different multicast
by multicast. Multicast forwarding must be performed over a tree of
receivers. Thus, the tree is different multicast by multicast, which
means the aggregattion is impossible.

It is possible to aggregate multicast address allocation
by making multicast location dependent with, say, a root domain.
Then, it is possible to aggregate routing table entries to the root
domain.

However, it is still impossible to aggregate routing table entries
to the receivers. The disrtibution pattern of receivers is unrelated
to the location of the root domain. That is, separate routing table
entry is necessary for each multicast.

A group of multicast sharing a root domain may still have weak
relationships that most of them do not have any member in
domains far from the root domain. Then, it is possible to
share a default routing table entry not to forward anything.
But, such a entry is meaningless, because there is no data
packet will be forwarded for the entry and we still need
unaggregated routing table entries for each multicast running
over multicast routers.

Or, it is possible to assign multicast addresses aggregated according
to the distribution pattern of the receiver hosts, areas or domains.
However, even with 32 receiver hosts, areas or domains, we need
32 bits for the aggregation prefix of the multicast addresses,
which is too many for IPv4. Even IPv6 address space does not
help a lot. Moreover, as the multicast membership changes dynamically,
the multicast address itself must change dynamically.

That is, according to the current model of the Internet multicast,
it is impossible to aggregate multicast routing table entries.

With the impossiblity, it is meaningless to try to aggregate
multicast address assignment.

Any comments?

					Masataka Ohta

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 25 Feb 1998 11:30:45 +0000

In message <[email-masked]>, Masataka Ohta typ

 >>according to the proof, IDMR is a wrong WG to exist.

...."proof" ommitted for sake of brevity...

 >>Any comments?
 
yes

maybe you're right, and maybe you;re wrong about multicast aggregation, 
but IDMR is the working group with the terms of refrerence to look at this
(amongst other things that it does, which are good reasons for it to
exist.....)

anyhow, IDMR is the focus, AND has the relevant exprts on it, so,
having "aired your grievance" with that WG on this publiclist, perhaps
you'd like to restore the discussion to there, and carry any new folks
who've got interested i nthe topic by this globalcast of your idea, to
the group....

 cheers

   jon

p.s. given the way that some ISPs are provisioning a seperate overlay
network for common sourced multicast of (typically) overlapping
interest at least per city, if not per stockbroker, or internet TV
viewer population, i think your assertion is too strong for some
applications  but certainly for many-to-many conferencing, its true
there's precious little chance of aggregation actually lying along
common network paths.....on the other hand, sparse mode aggregation for
low traffic rate multicasts may not be a problem even if its somewhat
suboptimal in link use...so its not so obvious why your "proof" is so
much a "proof" as a statement of limitations

2ndly, inter-domain multicast routing addresses TWO problems - the
first is aggregation for scaling; the second is the introduction of
schemes to permit deployment of new multicast routing protocols by
defining interworking....this isclearly ALWAYS worth doing...

---

From: Karl Auerbach <[email-masked]>
Date: Wed, 25 Feb 1998 08:09:48 -0800 (PST)

> assignment aggregation is meaningless.

... 
> means the aggregattion is impossible.

I think you are mixing the notions of aggregation *between* multicast
routing domains and multicast distribution within the multicast routing
domain.

I also question another of your assumptions -- we tend to see, at a
minimum, receiver computers joining two groups, typically one for RTP/RTCP
video and one for RTP/RTCP audio.  And often a third for SAP/SDP. 

Even cutting the routing table size to 1/3 of what it would be otherwise
is a substantial improvement.

		--karl--

---

From: [email-masked]
Date: Thu, 26 Feb 1998 15:22:22 +0900

Ohta san,

From: Masataka Ohta <[email-masked]>
Subject: A technical discussion on multicast
Date: Wed, 25 Feb 98 18:16:24 JST

> The topic is multicast and aggregation.

I think the first half of your message is true, the part of proving
the impossibility of multicast address aggregation.
And I think it is also true, if the problem is due to the wrong
multicast address architecture, it is the best way that the problem
is solved with changing the address architecture.

However, I believe IDMR WG mission is to develop interdomain
multicast routing mechanism on the restriction of given multicast
address architecture. So the WG should be existence until success 
to develop routing mechanism or disappearing today's multicast address
assignment.

BTW, I have another idea for multicast address architecture to ensure
the address aggregation which is follow as, 

Multicast address field creates in the network address allocated to 
site or organization. It is regard as same group when the newly
multicast address fields are matched, even if the unicast network
address field are different.

e.g. All following addresses indicate same multicast group. They
include same ethernet address information allocated to use IP
multicast, and all address 

   IP v6 address (hexadecimal)             corresponding MAC address
A: 3ffe:0501:0400::3333:0aff:fe0a:0a0a     33:33:0a:0a:0a:0a
A: 3ffe:0501:0411::3333:0aff:fe0a:0a0a     33:33:0a:0a:0a:0a
C: 3ffe:0201:0400::3333:0aff:fe0a:0a0a     33:33:0a:0a:0a:0a

I think above multicast address architecture includes the same level
of information of group distribution pattern as IP v6 unicast address
architecture.

But, I have not proved and demonstrated whether my idea works or not, 
yet. I think it is still a controversy and a research issue. 

Sorry, this message also include political issue and my awkward idea.

                                                Katsushi Kobayashi
                                                [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 26 Feb 98 15:52:16 JST

Kohayashi san;

> the impossibility of multicast address aggregation.

Thank you.

> is solved with changing the address architecture.

No, that's not what I said. I said aggregated multicast address
assignemt is meaningless, but not wrong.

> address architecture.

Agreed.

> So the WG should be existence until success 

Purely within the IDMR WG discussion. That's right.

However if the IDMR WG mission is proven to be wrong, which is a
matter outside the scope of the WG discussion, which is why I
initiated the discussion in IETF ML, it makes the WG disappear
or reformed.

> the address aggregation which is follow as, 

Address aggregation?

> yet. I think it is still a controversy and a research issue. 

I'm not sure how your proposal is.

But, there already is a research result that multicast address aggregation
is meaningless.

So, why do you bother?

If your proposal is to have mechanical mapping from multicast address
to unicast core/RP address, I think it doable as long as there is only
one (candidate and real) core/RP for each multicast.

But, IMHO, it is an address assignement policy rather than an address
aggregation.

> Sorry, this message also include political issue and my awkward idea.

It may be a good idea to have BoF in the next IETF @ LA on multicast
architecture issues.

Are there anyone else having your own idea?

						Masataka Ohta

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 26 Feb 1998 09:56:36 +0000

>>to develop routing mechanism or disappearing today's multicast address

hey, the working group goes on existing so long as the IESG lets it -
if you have good reason for this not to be, appeal - if you want
another working group propose one.

 >>address field are different.

PLEASE READ the MASC/BGMP work in IDMR

 >>Sorry, this message also include political issue and my awkward idea.
 
hmmmm....

 cheers

   jon