Subject: Re: A technical discussion on multicast (fwd)

From: Masataka Ohta <[email-masked]>
Date: Thu, 26 Feb 98 13:33:49 JST

Forwarded message:
>From mohta Thu Feb 26 13:32:57 1998
From: Masataka Ohta <[email-masked]>
Message-Id: <[email-masked]>
Subject: Re: A technical discussion on multicast
To: [email-masked] (Jon Crowcroft), [email-masked]
Date: Thu, 26 Feb 98 13:32:31 JST
Cc: [email-masked], [email-masked]
In-Reply-To: <[email-masked]>; from "Jon Crowcroft" at Feb 25, 98 10:35 pm
X-Mailer: ELM [version 2.3 PL11]

Jon;

Thank you for your response.

>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?

So, I am not and will not be a member of IDMR.

If some of you are interested in discussing the issue with me,
please include me in Cc: or mail to the ietf mailing list.

>  >>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.
> IF we use hierarchical addresses for layered delivery, virtuallly
> topologically scoped grouping of cyber-proximal game object state
> update, and with scoping, THEN aggregation becomes increasingly
> important...

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.

According to the end-to-end argument, internetwork layer is
unrelated to the applicatio specific issues.

> 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.

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.

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.

> don't judge a technique by its current usage always!

We should base our argument on the current multicast model.

> but you are right that _destiation group_ based aggregation for
> _current_ public internet (aka mbone)
> use is probably not much of  a big deal

The model of the Internet multicast are that senders and receivers
may be located anywhere in the Internet and that membership may
change dynamically.

> 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.

Shared tree based CBT are PIM-SM with RP/core advertisement through
DNS is the only approach I know which archive the minimal complexity.

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.

Solutions for "its current usage" are provided already.

So, don't say that the current usage needs the current architecture
because it is running over it.

It is only that the current usage is running over the current
architecture but will run better if the architecture is replaced.

> plus, as i said on the main ietf list, idmr is not just about
> aggregation - its also about tolerating heterogeniety of routing
> domains....i.e. incremental deployment....

Wrong argument.

IDMR approach, or making multicast routing dependent on unicast
routing protocol, makes incremental deployment more difficult.

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.

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

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.

						Masataka Ohta

---

From: [email-masked]
Date: Thu, 26 Feb 1998 11:13:06 -0500

> We should base our argument on the current multicast model.

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