Subject: Re: A technical discussion on multicast

From: Masataka Ohta <[email-masked]>
Date: Fri, 27 Feb 98 15:19:16 JST

Jon;

>  >>From my experience, it is a waste of time to discuss purely technical
>  >>matter on why some WG is wrong to exist in the WG, becasue the WG
>  >>won't reach the consensus. Do you remember what happed to ION,
>  >>when it was proven that NHRP does not scale?
>  
> WGs are all different - IDMR is not anything like ION

Can you demonstrate it against a message like:

:This worries me.  It looks too much like "because we don't understand
:how to do with with the current model, it can't be done".
:
:Remember - Fourier transforms were incredibly painful to do in 1940,
:and then somebody looked at it in a different way and invented the
:FAST Fourier transform.  Until that happened, a lot of people were
:convinced it was "proven" that Fourier transforms were difficult.
:-- 
:				Valdis Kletnieks
:				Computer Systems Senior Engineer
:				Virginia Tech

?

Well, actually, what I want to say is "Multicast is easy because
we don't have to worry about aggregation" while IDMR's way of
life is to say "Multicast is difficult becasue we must aggregate
everything".

>  >>So, I am not and will not be a member of IDMR.
> 
> well, i think youneed to be, or else have a BOF...

So far, my point is whether multicast routing table aggregation
possible or not and whether multicast address aggregation
meaningful without much constructive proposal.

As I say "IP over ATM is easy becasue we don't have to worry about
short cutting, which is proven not to scale" and "Multicast is easy
because we don't have to worry about aggregation, which is proven
not to scale", it is really easy to propose a scalable constructive
proposals on IP over ATM or on Internet multicast.

However, it is important to let people recognize the impossibilities.

>  >>That's an application layer issue, solved by application layer
>  >>relays. You can even say "reflectors", if you are so sure that
>  >>some application make strong aggregation possible.
> 
> the interface between applicaton level cast and IP level cast is
> something that has ben discussed n IDMR (also in LSMA< and more in the
> IRTF's Reliable Multcast group)

Those were wrong places to discuss.

>  >>According to the end-to-end argument, internetwork layer is
>  >>unrelated to the applicatio specific issues.
> 
> this is NEVER as black and white  an argument as peole make out,
> especially in multicast (which was not envisaged by clark, saltzer and
> reed in the e2e argument paper nor in the original internet
> architecture).

The problem of the end-to-end principle is that it is so easy to
ignore it. However, the result of the ignorance is a network of
telephon companies.

If you think current multicast architecture does not strictly follow
the end-to-end principle, it means the architecture is no good.

For further argument, you must give some specific examples.

> a LOT of transport protocol work for multicast needs network level
> help  how much is still a matter for debate - its not a closed debate
> at all....variations from chanig the IP forwarding model fro
> mdeeering's original multicast (proposed by stanford and cisco and
> others) to providing anycast, subcast and host proximity services are
> all being worked on

I acknowledge that there is a lot of transport and routing
protocol work for problems already solved simply in internetworking
or application areas.

>  >>> there are some modest propietary nets i know of with between 100 and
>  >>> 400,000 hosts that get VERY good aggregegation
>  >>
>  >>OK. With the VERY good aggregation, the hosts should share a single
>  >>multicast group. There are enough number of UDP ports for them.
>  >>
> 
> no - you're wrong here - we get aggregatio o those nets oof the order
> of 1000 streams per multicast tree....

Huh? Even with IPv4, you can have 3,500,000,000 streams in a multicast
group distinguished by source addresses.

>  >>Or, if application layer has a knowledge that some multicast
>  >>application has nearly the same distribution pattern with
>  >>some aggregation, it is the responsibility of the application
>  >>to have application-layer relays in each aggregated area.

> there are situations where you can't do this exactly that way....but
> something along those lines is typically envisaged often...

Wrong.

If the application does not have application specific knowledges,
lower layer's can't.

>  >>Still, it is wrong to assume that the application-specific aggregation
>  >>is based on BGP domain strucuture, because organizations related to
>  >>the application will choose and change ISPs and its ASes
>  >>psuedo-randomly based on the cost-performance of ISPs or on
>  >>other factors.
> 
> in the general internet, this observation is true, but many ISPs don't
> permit multicast in the general internet, but deliberately construct
> seperate topologies for which they make this feasible..this is called
> traffic engineering...

Wrong. Many ISP's don't permit multicast in the general internet,
because there was a misunderstanding that having intra- and inter-
domain multicast was a way to go.

How can you connect two ISP's in different domains, if all the
multicast protocols operates only within a single domain?

Note that you, and, according to your opinion, IDMR, are denying
IPv6 renumbering, and promoting provider monopoly.

>  >>> don't judge a technique by its current usage always!
> 
>  >>We should base our argument on the current multicast model.
> 
> 1/ the model is not completely fixed
> 2/ the usage is not the model...

So, I haven't assumed unfixed part of the model nor your claim on
your usage.

>  >>> but aggregation for sources or RP/centers may be
>  >>
>  >>No. As long as packets are forwarded to receivers, aggregation
>  >>of routing table entry is impossible. The path from the source
>  >>to somewhere unrelated to the locations of the receivers is
>  >>an optional  unnecessary redundant overhead of some multicast
>  >>protocol. But, such an extra aggregation is meaningless because
>  >>data must finally be forwarded from "somewhere unrelated to
>  >>the locations of the receivers" to the locations of the receivers.
> 
> um, i'm not sure you see why we have centered trees - the reason is
> not just some arbitrary "unnecessary redundnt overhead"....its coz for
> sparse groups of MANY sources with intermittant traffic, its genuinely
> better appproach...

I'm not against but for having a centers, though it's better to have
multiple centers.

However, with the approaches, the route to the center(s)/core/RP
is determined by the unicast routing table.

So, with PIM-SM or CBT, there are no problem at all from the
beginning. It is NO necessary to aggregate multicast address
assignment.

>  >>Shared tree based CBT are PIM-SM with RP/core advertisement through
>  >>DNS is the only approach I know which archive the minimal complexity.
> 
> other approaches are in hand...
> 
> MASC/BGMP addresses this problem partly - there

It does not, not even party.

CBT and PIM-SM can treat *MANY* senders from the beginning without
MASC/BGMP.

MASC/BGMP makes it no better.

>  >>But, let's solve the problem step by step.
> 
> ???
> 
>  >>Current topic is that multicast routing table entry can not be
>  >>aggregated and that multicast address aggregatio is meaningless.
> 
> thats you topic - during a debte, wr can find ways to accomodate a
> move in the basis of the argument-  if not, sure - you may have
> defined an argument that you always win - fine-  i'm not going to
> waste time arguing on that basis....

OK. Fine. You agree that:

	Current topic is that multicast routing table entry can not be
	aggregated and that multicast address aggregatio is meaningless.

Then, we can proceed to the next step.

>  >>Solutions for "its current usage" are provided already.
> 
> nope- some parts of the net cannot deply application level relays, but
> ca accomodate sub-optimal assignmen f load to links via multiplexing
> multiple streams over a single treee - thats a given...its not common
> mbone use, but the mbone is a tiny fraction of IP multicast i nthe
> world n reality....

Some parts of the net cannot deploy any multicast protocol.

People use sub-optimal assignments of reflectors.

People do not need multicast.

PERIOD. :-)

>  >>So, don't say that the current usage needs the current architecture
>  >>because it is running over it.
>  >>
> see above....see PGM from cisco, see HLA from the DIS world.

See what?

>  >>It is only that the current usage is running over the current
>  >>architecture but will run better if the architecture is replaced.
> 
> this also is under consideration in IDMR

OK. And the debate should be like "....see PGM from cisco, see HLA
from the DIS world.". No, thank you.

>  >>IDMR approach, or making multicast routing dependent on unicast
>  >>routing protocol, makes incremental deployment more difficult.
> 
> well, we seem to be making some headway but then you're not in the
> group, so i guess you hadn't seen that:-)

I look at MASC/BGMP and decided to stay away from those who
thought it good.

>  >>With the domain-boundary based approach, you can't incrementaly deploy
>  >>something over domain boudaries. With a better approach independent
>  >>of unicast routing, we can deploy it any part of the internet
>  >>regardless of the unicast domain boundary.
> 
> um, the BGMP approach is largely independent of unicast - PIM is not
> an inter-domain protocol (if hats what you are referrig to) its an
> intra-domain protocol (despite the name of the WG)

We can completely agree that PIM, as is, of course, is a intra-domain
protocol.

>  >>For the incremental deployment, multicast routing protocols
>  >>should be independent of the unicast routing protocol.
> yes....

So, let's have one (or two). PIM-SM or CBT combined with DNS.

>  >>In the sense, the current specifications of PIM-SM and CBT are no
>  >>good, because they are dependent on the unicst routing protocol
>  >>in a way that core/RP locations are based on flooding within
>  >>a unicast routing domain.
>  
> yes, see above - they are BOTH intradomain -

Yes, agreed. But, it seems to me that Dino, for example, has a
different opinion.

> the WG was named wrong
> for its first few years (my fault -  i set it going, but they were'nt
> really ready to look at inter-domain til recently - it shoud have been
> an IRTF WG for that time...but that idea didn't occur to me then...)

> you've made some useful points, but i do think IDMR could benefit and
> i don't think you would get the same negative experience as you had
> with ION.....

What can you say with Valdis Kletnieks and FFT?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 27 Feb 98 15:19:16 JST

Jon;

?

Wrong.

PERIOD. :-)

See what?

						Masataka Ohta

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 27 Feb 1998 07:24:50 +0000

In message <[email-masked]>, Masataka Ohta ty
ped:

part 1. - retoric
-------

 >>Then, we can proceed to the next step.

no i donbt agree so there's no point proceeding with that part of the
"debate"

we think we have a LOT of ways we can aggregate address usage in such a way
that it reduces state, depending on applications - a LOT of current
mbone applications are not what we beleive to be typical of future
use.....the many-many model of the conferencing tools is (like
telephony) going to play a relatively minor role in the end
often......

part 2. usage versus architecture - surprises.
-------

 >>People do not need multicast.

ah, so you have moved from your original statement that aggregation is
meaningless, to "multicast is not needed"
ok...so there's no point in havign a BOF or a WG on
"topic X is neaningless" :-)

meanwhile, the rest of us who have deployed multicast usefully will
continue to optimise it...like UUNET

 >>See what?

read some of the discussion in idmr and RM .....since you don't go,
then i dont see how you can know what we've devised...
read the specs and look at why they are devised the way they are - se
the papers on how we map share feed for the stock market hierarchical
name space onto the address space, so that, while the name space and
receiver set might apparently be completley orthogonal, _usage_ tends
to be highly aligned....similalry with object and virtual topology
spaces in games and multiuser simulations, and use.......

 >>from the DIS world.". No, thank you.

um,, no - the debate should be based on you and everyone else talking
about content not just repeating your origianl point without adding
evidence - i'm adding pointers to evidence of work and discussion
 which you are just asserting are wrong 

please help this humble fool understand why so many of us think we can
do this thing you say we can't

part 3 intra v. inter domain mcast routing for heterogeneity and deployability
-------

 >>I look at MASC/BGMP and decided to stay away from those who

it might be better if you actuallty ENGAGED in a critique with thm

of course if your critique is "this can't be done" then i see your
point in staying aweay, but why do you care then....

 >>We can completely agree that PIM, as is, of course, is a intra-domain

noone ever said anythign else - yo uare confused if you thouight
(oCBT) or [SD}PIM were ever menat to be interdomain

 >>So, let's have one (or two). PIM-SM or CBT combined with DNS.

um......do what? run that by us again.....

 >>> yes, see above - they are BOTH intradomain -
 
yes yes yes, we NEVER said otherwise ....

 >>Yes, agreed. But, it seems to me that Dino, for example, has a

no he isnt , even if he says he is:-)

 >>> an IRTF WG for that time...but that idea didn't occur to me then...)

 cheers

   jon

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 27 Feb 98 18:46:59 JST

Jon;

> no i donbt agree so there's no point proceeding with that part of the

OK.

But, first of all, which part of the statement you disagree with?

	multicast routing table entry can not be aggregated

or

	multicast address aggregatio is meaningless.

or both?

Anyway, make a counter argument with concrete evidences.

> telephony) going to play a relatively minor role in the end

Huh? I thought your main concern was many-many model. As we agreed
several weeks ago, I'm not interested in many-many communication
over Internet and digital telephony.

Let's be realistic.

The primary use of multicast/broadcast technology today is for
TV and radio broadcasting.

With such a use, receiver pattern is different channel by channel,
while, the more bandwidth available the more senders are expected.

You may be able to invent other variation of users. But it is difficult
to claim it will be so popular.

> meaningless, to "multicast is not needed"

No. I merely followed the logic of your reasoning.

> "topic X is neaningless" :-)

No, of course. BoF is not necessary to delete a WG. I haven't
proposed a BOF or a WG yet.

> continue to optimise it...like UUNET

That's a problem.

Rest of us who are not bound to some specific way of doing multicast
must replace it, like the Internet replaced UUCP net, despite the
optimizaiton attempts on UUCP networking.

> read the specs and look at why they are devised the way they are

That's why I decided not to join IDMR.

> - se

So?

It does not mean we need aggregated address assignment.

That aggregated address assignment worked in some special case
does not mean unaggregated address assignment can't work
equally well.

> evidence -

I already provided an evidence that receivers of the
multicast belongs to different providers of different ASes.

> i'm adding pointers to evidence of work and discussion

Sorry, but, your pointers to special applications means too little
against TV/radio broadcasting over the Internet.

The assumtions that all the receivers belongs to a single ISP is
not meaningful, even from an IDMR point of view.

> it might be better if you actuallty ENGAGED in a critique with thm

Yes, I do.

> point in staying aweay, but why do you care then....

No. The critique is "it is doable but meaningless.". Read it.

What is impossible is "aggregation of multicast routing table entries".

> um......do what? run that by us again.....

Let's assume we try to use PIM-SM and/or CBT world wide.

The problem of intra-domain PIM-SM or CBT is that it assumes
domain boundary and domain-wide flooding for core/RP selection,
which makes it unicast routing architecture dependent.

So, we should use DNS like:

	bbc.com		CORE	london-station.bbc.com.
			A	225.192.2.3

or

	bbc.com		RVP	london-station.bbc.com.
			A	225.192.2.3

Basically, that's all.

As the DNS lookup of unicast addresses MUST continue to scale,
we have no difficulty to use DNS for multicast addresses and
CORE/RVP locations.

As a unicast scalability issue of DNS, we may need to have
nation-by-nation set of root servers, sharing the same IP
address, which prevent the Internet owned by a single
goverment (don't quote this paragraph, further :-)).

That's the proposal of scalable PIM-SM and CBT.

In addition, we can solve the multicast address assignment
problem through DNS.

For example, if 225.0.0.0/8 is for DNS assignement, we
can map the ownership of 225.192.2.3 as

	mcast.3.2.192.in-addr.arpa.	PTR	bbc.com.

Note that all the policy related complication is delegated as a
unicast assignement issue, which makes a unicast address management
a little more difficult.

Note that the DNS-based assignment does not need but does not
forbid aggregation. Owners of consequetive multicast addresses
may use them with a single core/RP, for example. That is, even
if multicast address aggregation were not meaningless, MASC is
still meaningless.

You may say that you need multicast with local scopes. But, it is
an artifact of intra-domain protocols with poor scalability. Neither
PIM nor CBT needs local scopes, becasue router state is proportional
to the number of mulitcast stream actually running over the router.

If you really are interested in the details of the proposals
above, there is a research paper submitted to INET'98.

> yes yes yes, we NEVER said otherwise ....

Neither of us NEVER.

> no he isnt , even if he says he is:-)

OK. But if you say "no he isnt", which does it mean, he is or he isn't? :-)

						Masataka Ohta

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 27 Feb 1998 17:58:00 +0000

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

 >>	multicast address aggregatio is meaningless.
 
I believe that we can do traffic flow aggregation for point multipoint
flows

i bvelieve that we MAY be able to do this via common core, or common
shared tree, possibly by smart dynamic address allocation

I believe that right now, you are RIGHT - clearyly logical addresses
such as class D are no more than a handle for a distribution tree
which is determined by the receiver set, not the address allocation

 >>while, the more bandwidth available the more senders are expected.
 
right...

 >>to claim it will be so popular.

maybe....this is where i'm not sure...

 >>>  >>> mbone use, but the mbone is a tiny fraction of IP multicast i nthe
 
.....

 >>Let's assume we try to use PIM-SM and/or CBT world wide.

hmmmm....ok lets assume this for the next part of your proposall....

 >>Basically, that's all.

yes, subject naming in TIBNET and PGM support are thinking along that
line...as we are for virtual multicast address spaces and dynamic
remapping service based on autodetection of common trees -if you
insist on defining them that way, the remappers (content based filters
in tibnet) are application level - but note that they can be
implemented VERY efficiently and do not need to be aprt of a full
scale application relay...

you COULD use DNS if you like - we prefer to use somethign capable of
fast, local update....

 

 >>to the number of mulitcast stream actually running over the router.

hmmmm...

 >>above, there is a research paper submitted to INET'98.

ok - can you send me a copy....i want to see how it relates to our
thinking in RM....

 >>Neither of us NEVER.

ok...

how about you & i collaborate on defining the problem (perhaps we
start from your INET paper, and produce an I-D - i still don't see why
it would be a bad thuing to do in IDMR, but we can run it by the IAB
perhaps and see if there is room to discuss it elsewhere...

note, by the way that MASC makes for a hierarchical address space,m
NOT to do aggregation of trees/traffic, but to allow address
allocation schemes based on the algortithms in SDR and others to
scale.......its nothing to do with layered coding, or games with
hierarchical gamespace descrtiptions, or sharefeed name spaces and
receiver sets with common sub interests......so i wouldn't be so
dismissive of MASC nor of BGMP, which succesfully defines how to
interoperate all the intra-domain scahems whilst providing policy
control of which soruces may flow into, outof or transit a domain (but
as you rightly identify, does not deal with flow aggregation, or
introduce a level of route state aggregation....or address
aggregaioton i nthe same sense as cidrized unicast...)

so yes, you have a point.....a good one, that we weren't unaware of in
idmr...(steve deerig and i went through this loop a year back....) and
i think we need to see what common menchanisms can develope AND which
are not worth looking at

thanks...now do we need to keep this on the main IETF list still....?

 cheers

   jon

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 28 Feb 98 11:07:59 JST

Jon;

> I believe that we can do traffic flow aggregation for point multipoint

Point multipoint flows?

But you are debating on the case when there are many senders, that
is multi(many)point multipoint flows.

As I proved from the beginning and you haven't disagreed, point
multipoint routing table entries can not be aggregated.

> shared tree, possibly by smart dynamic address allocation

As I have said already, having a common core is easy. It solves
multicast routing to the core as unicast routing problem.
You don't need any smart dynamic address allocation to do so.

Please don't try to introduce a smart (that is, complex) mechanism
trying to solve a sloved probelm.

The remaining problem is a multicast routing from the core
to the receivers, the point multipoint case.

And, the aggregation is impossible.

> which is determined by the receiver set, not the address allocation

So, it is important to distinguish two cases: from senders to core(s)
and from the core(s) to receivers, and recognizes the latter is
the problem.

> scale application relay...

I can't understand why you think application layer aggregation
is related to DNS issues.

> you COULD use DNS if you like - we prefer to use somethign capable of

DNS with dynamic update with or without security already allows fast
update. The update is local, if you place your DNS servers locally.

Fast update of multicast address or core(s) is not necessary from
the beginning, though. Note that I say "core(s)" because multiple
cores means redundancy and efficiency.

> ok - can you send me a copy....i want to see how it relates to our

Sure. But, what is RM?

> perhaps and see if there is room to discuss it elsewhere...

Thank you very much for your offer. The problem of IDMR is in
its name that it says inter-domain.

> scale.......

SDR? What is it? Is it source demand routing, in which case
it does not scale with receiver initiated multicast.

Even if SDR means receiver demand routing, different demands
of receivers makes receiver demand routing not aggregatable
and not scale. Then, if you are trying to force some routing
policy to receivers, there is no point to call it receiver
demand routing. Such a policy can be better implemented
by hop-by-hop routing than receiver source routing.

> its nothing to do with layered coding, or games with
> receiver sets with common sub interests......

The receivers of different layer is different that aggregation
between layers is impossible, unless you send all the data to
all the receivers, which make data not layered.

> so i wouldn't be so
> interoperate all the intra-domain scahems

It does not. BGMP have several bugs, some of which, it seems to me,
unfixable.

Note that DNS can be used as

	bbc.com.	COREAS	25

that BGMP does not necessarily mean MASC. So, I don't think further
discussion on BGMP is meaningful.

> whilst providing policy
> control of which soruces may flow into, outof or transit a domain

Wrong.

It was a problem solved by CBT or PIM-SM as a unicast policy control
over the unicast routing table from senders to the core(s) and core(s)
to receivers.

The point is to construct multicast routing table based on unicast
routing table, that is, the unicast routing policy.

> thanks...now do we need to keep this on the main IETF list still....?

We two don't, but others may.

							Masataka Ohta

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 28 Feb 1998 11:48:11 +0000

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

 >>is multi(many)point multipoint flows.

no i am adding other areas of discussion, as is anyones right in a
many to many email list discussion

i agree that it is hard to see how to aggregate the state for
different many-to-many flows....

 >>multipoint routing table entries can not be aggregated.

with the current class D address model, yes...this is possibly
true...though not for all topologies, for instance...
 >>You don't need any smart dynamic address allocation to do so.

you still need information to do common core assignment...

 >>And, the aggregation is impossible.

no - you can reassign cores as the receiver sets change based on
observation of common shared topology -there are algorithms for this
based in diffusive computations that are not too hard...

this means you can also do it for sourc e tree multicast ...its just
it leads to a lot of dynamic address re-assignment, which we havnt
considered yet...
 >>is related to DNS issues.

BECAUSE the paplication knows the relation between the namespaec for
common objects in APPARENTLY different applications..thats why...

 >>update. The update is local, if you place your DNS servers locally.

IF you want to rearchitect quite a few of the software
 systems for DNS implementatios, this is true,
sure...

 >>cores means redundancy and efficiency.
 
sure..we envisaged this in CBT a few years back now....

 >>> ok - can you send me a copy....i want to see how it relates to our
relible multicast research group of IRTF - where we think about the
use of larg e scale multicast for reliable or semi reliable
transmisson, where there is complimentary thinking to some IDMR and
other work, but on longer term basis....

see
[email-masked]
and
http://irtf.cs.berkeley.edu/irtf/rm.html 

 >>its name that it says inter-domain.

ok - so we di i t as a no WG i-d...

 >>it does not scale with receiver initiated multicast.

NO - the address allocator for mbone currently is derivved from the
session directory...nothing to do with routing - sorry....

...

 >>between layers is impossible, unless you send all the data to
 
o
you really should read hthe RM stuff - lots of work has been done
there on how to help with this...

 >>> control of which soruces may flow into, outof or transit a domain
 
NO not wrong - that IS wha BGMP is for  - the fac the CBT and PIM SM
are also possible capable of some policy control via the underlying
unicast is seperate, and less effective and is nothign to do with the
motivation for a proper interdomain polciy controlled multicast
protocol....

 >>over the unicast routing table from senders to the core(s) and core(s)
 
neither CBT nor PIM SM do route advertisement filtering.
not at the level that is visible to the core/rp assignenet, or in a ay
that works if you want to connect dense mode regions togerther and
still control policies....

 >>routing table, that is, the unicast routing policy.

um, yes, CBT and PIM derive routes fro municast therefore are
costrainedby unicast policies, which is why its better to have a
policy control that is seperate and defined for multicast and not
hidden the waay CBT and PIM would hide them, but that is sort of the
motivation for having bgmp....at least partly...

and you didn't answer my point about what MASC Is for so its clea you
adnt read the address assignemnet work...
see handlye's thesis for why we need disjoint regions for address
asignment to scale (completely IRRELEVENT to route state aggregation or
hierarchical addresses or tree/branch aggregation...)
at:
ftp://cs.ucl.ac.uk/darpa/mjh-thesis.ps.gz

 cheers

   jon

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 28 Feb 98 21:54:06 JST

Jon;

> many to many email list discussion

That's fine. But....

> different many-to-many flows....

NO.

It is hard to see how to aggregate the state for different one-to-many
flows.

First half of many-to-many part is a solved issue by CBT or PIM-SM.

> true...though not for all topologies, for instance...

Address model has nothing to do with the proof.

I never used any assumption on the address model.

> you still need information to do common core assignment...

That's the easiest part solved by DNS.

Wrong.

As I said in the first message, if you have 32 hosts/areas/domains,
you need 32 bits for the prefix of the common shared topology.

That is, your common shared topology is not common nor shared,
unless there are 2**32 multicasts.

> common objects in APPARENTLY different applications..thats why...

You misunderstand DNS, then.

DNS name space has no semantics, unless you are interested in
trademark issues.

>  systems for DNS implementatios, this is true,

The dynamic update is already at the proposed standard stage
with implementations.

We are sure that the architecture remains same.

> sure..we envisaged this in CBT a few years back now....

I know. I don't know why it was abandoned.

> relible multicast research group of IRTF -

I have no interest in RM.

> session directory...nothing to do with routing - sorry....

Session directory is a area which also need a complete reform.

Use RTP URL and WWW, instead of dynamic hierarchy of session
announcement multicast channels.

> there on how to help with this...

No, thank you.

If you spend lots of work on something, it's time to think
the goal may be unreachable.

This is the obvious case of impossibility.

> motivation for a proper interdomain polciy controlled multicast

Wrong. That BGMP can control some policy is because it is a buggy
parody of CBT.

The policy control power of CBT and PIM-SM is fundamental.

> neither CBT nor PIM SM do route advertisement filtering.

Both CBT and PIM-SM do route advertisement filtering.

You can filter unicast route advertisement to core/RP at will.

If core/RP is not advertised, senders can't send a data to
a multicast channel, receivers can't join to the multicast.

The control is equivalent to root-domain filtering of BGMP.

> still control policies....

PIM-SM, of course, works connected with PIM-DM. As the dense mode
is farely localized within an AS, it is wrong to mention policy
control on it.

> motivation for having bgmp....at least partly...

There is no point to have different policy control for unicast and
multicast. BGMP does not work, if it can't (because of policy
difference) consult unicast routing table for multicast forwarding.

> adnt read the address assignemnet work...

I can't see any point of you about MASC.

> ftp://cs.ucl.ac.uk/darpa/mjh-thesis.ps.gz

As I have already shown a way of multicast address assignment
without disjoint regions with scalability of unicast address
assignment, we don't need disjoint regions for address
assignment to scale.

Just rely on DNS, here.

							Masataka Ohta

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 28 Feb 1998 14:53:29 +0000

In message <[email-masked]>, Masataka Ohta ty
ped:
 
re: DNS...
 >>We are sure that the architecture remains same.
 
yes- the problem is that people make assumptions about update v.
lookup
rate in implementations - and these assumptions make VERY big
differences in performance - for unicast name/address binding, DNS
uppdate is rare ...even with mobile ip at least for now...with multicast
its not so clear, so a seperate name space might be useful....

 >>I know. I don't know why it was abandoned.

well, to be honest, because the implementation effort on CBT was a lot
less than othes put in on pim....

 >>I have no interest in RM.

ah, but RM has an interest in scaleable multicast (of any kind), so is
a driver for thinking about it...so you may be missing something there
possibly...

 

 >>announcement multicast channels.

please expand....this alternative is not clear - what is your mechaism
to avoid, or mitgate assignment clashes(which is mostly what the
address assignment work in sdr was...)?

 >>the goal may be unreachable.

thats possibly true

 >>This is the obvious case of impossibility.

as i have tried to suggest a few times, most of the work does ntot
view the multicast architecture as fixed at all - IF you read some of
the owther work, you would see that we are evoleving the architecture
somewhat away from the deering/cheriton work of pre 1988....

 >>The policy control power of CBT and PIM-SM is fundamental.

an amusing view - and possibly true - if we got OCBT off the ground in
terms of code, you'd probably be right...i was thinking more about the
designers motivations than about the resulting systems....

 >>You can filter unicast route advertisement to core/RP at will.

could, not do....
 >>a multicast channel, receivers can't join to the multicast.

sure....

 >>The control is equivalent to root-domain filtering of BGMP.

yes, for sparse trees, and for multicore we can load balance, etc
etc....
yes...

 >>is farely localized within an AS, it is wrong to mention policy
 
yep

 >>I can't see any point of you about MASC.

scaling of avoiding address asignment clashes.

 >>Just rely on DNS, here.

how do you intend to avoid assignment
clashes if you only do local updates for globally reachable names.? (btw, the schemes in the mcast
address asignment could be _inside named_ if you insist...)

 cheers

   jon

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 1 Mar 98 9:42:05 JST

Jon;

Don't you think the IETF ML is the place to discuss inter-relationships
between multicast, unicast routing, DNS, session announcement, WWW...

Anyway,

> its not so clear, so a seperate name space might be useful....

People may, but DNS and its implementations make no such assumptions.

Everything is controlled by SOA and RR-wise TTL.

So, it WAS better to have a separate DNS name space to have different
SOA.

But, today, NOTIFY makes DNS refresh quick and IXFR makes update
light weight.

Thus, you don't have to have even a separate name space.

That's the current reality of DNS.

> less than othes put in on pim....

Hmmm thanks for the information. But, IMO, PIM should have multiple
RPs, not merely candidate RPs. A proposal is in our INET'98 paper.

> a driver for thinking about it...so you may be missing something there

I'm not sure what "reliable" means. But if you think RSVP makes
multicast reliable, I do think about that.

Otherwise, I think there can be no RM without makeing routers stateful
to store all the packets of an RTT period. I'll be happy to see
a scalable counter-example, though.

> please expand....this alternative is not clear -

The session announcement should have a complex network structure
with moderate caching and proxy. So, reuse WWW.

But, it is not a required role of session announcement to assign
addresses.

We don't have to assign multicast addresses dynamically (though
we can make it as dynamic as you want with DNS dynamic update)
that we can make session announcement and address assignment
separate issues.

> what is your mechaism

It's unrelated to session announcement.

My mechanism is the mechanism used today all over the internet
to avoid assignment clashes of unicast addresses.

It is to say:

	1.2.192.225.in-addr.arpa.	CNAME	mcast.1.2.192.in-addr.arpa.

	mcast.1.2.192.in-addr.arpa.	PTR	bbc.com.

	bbc.com.			A	225.192.2.1

But, the assignemnt problem is not of mechanism but of assignment policy,
which is why I use extra indirection (to be forced by IANA/ISOC):

	1.2.192.225.in-addr.arpa.	CNAME	mcast.1.2.192.in-addr.arpa.

which makes unicast address assignment job a little more
complex but solves all the policy, econimics, protocol
issues of multicast address assignment.

> somewhat away from the deering/cheriton work of pre 1988....

It's surely important to have wider knowledge and wider field of view.

So, I'm rather busy studying how other areas have solved their
problems and how the solutions are applicable to multicast issues.

The problem of people in the routing area is that they try
to solve all the problems by flooding and aggregation.

>  >>You can filter unicast route advertisement to core/RP at will.

The route advertisement filtering is a unicast routing issue,
which is the multicast route advertisement filtering of CBT and PIM-SM.

And, the route advertisement filtering of unicast routing is
what you can see today everywhere.

> address asignment could be _inside named_ if you insist...)

My proposal for address assignment with DNS is to delegate a control
of 225.192.1.2 to an administrator who is delegated a control of
192.1.2.0/24. The administrator may further delegate it to someone
else. If we spend all the multicast address space, we can make it
192.1.2.0/28.

If all the names in a zone is used locally and served by local
name servers, all the update on the local names are performed locally.

We, today, can locally update unicast addresses of globally reachable
names. We can locally update globally reachable names of local unicast
addresses too.

How can you say the same thing not possible with multicast?

Multicast applications are adviced to perform both forward and reverse
lookup of the multicast, of course, if they want to follow the authority
of ISOC.

							Masataka Ohta