Re: [MMUSIC] Re: [MBONED] WG action for draft-savola-mboned-mcast-rpaddr-03.txt

I agree, and this type of statements could be supported by history
(I will be short):

1984 : First IP stack.
1985 : Deering start his thesis (Internet size about 2000 hosts)
December  1985 : RFC 966 "Host groups : a multicast extension to the
Internet Protocol"

September 1986 : start of implementation.
May 1988 : First IP multicast ROUTING based on 4.3+ networking code
(Internet size, about 30000 hosts).

In the old times, when ASM over IP has been invented, Ethernet was pretty
successfull and supported broadcast/multicast. So a natural way
to do multicast over IP, was to deploy Broadcast and prune mechanisms,
which works pretty well for small topologies (dvmrp, pim-dense).

1991 : Deering has finished his thesis, Holbrook start to work on Multicast
1992 : the First internet Audiocast at the IETF : what a wonderful new
techno, but will it scale ? (Internet size : about 800 000 hosts).
Broadcast && Prune is no more considered as a doable solution .

1993-94 : Receiver Initiated multicast protocol time. Achieves very
good scalability but how do we achieve source discovery now ? The
Internet start to become very complex, and now it can be fully
considered as a complex system. Anyway, due to RFC1112 there must
be some "broadcast and prune mechanism" somewhere due to the logical
nature of an IP group (an class D IP multicast address is a Name, and do
not gives any topological information on the group): MSDP.

1994-95 : Web explosion (about 6*10^6 hosts at the end of 1995). Hoolbrook
may then still working on his thesis, looking at what is happening to the
Internet (growing growing growing...) and asking himself : why putting
source discovery in the network ?

2001 : (S,G) channel mode is out. it get rid of Source discovery and many
multicast complex problems only by pushing complexity in the end hosts. No
more multicast address allocation/collision, no more RP discovery, no more
MSDP. It simply obey to a simple rule in any complex system : Core pieces
must but simple, any other mechanisms should be considered at the ends
hosts first, as changing these core pieces may take down the entire
system.

Well, this is just short history, and I am sure that we could write a
pretty interesting document about "IP multicast history 1984-2003" and
what I conclude from history is that :

-Broadcast is OK for LANs

-Broadcast and prune is OK for small domains.

- Receiver driven only mechanisms is OK for big
  size topologies like the Internet that we have TODAY : it scale.

  It is ok too if we consider large domains (but small compared to
  the Internet size) with a few Rendez-vous point, for source discovery,
  if the number of RP becomes to high, we fall in the Broadcast and prune.

- ASM model is not compatible with Receiver driven only technology because
 "Sources just send, and the group is open" - RFC1112.

- SSM model is fully compatible with Receiver driven technology

- To achieve ASM model in the interdomain we'll always need source
  discovery AND some broadcast (at least to the RP). Do not have
  source discovery or broadcast means having one RP per group, or
  having the RP serving a well known set of group : this is the case
  in the Embedded Rp solution, and this is the case with SSM over IP.

Hoerdt Mickaël

On Tue, 22 Jul 2003, David Meyer wrote:

>
> 	Folks,
>
> 	Here's something that would be productive: Let's talk
> 	about facts, and stay away from statements such as
>
> ... ASM for IPv4 is not scalable in interdomain but SSM is ...
>
> 	We need to support this type of statement, otherwise it
> 	is just marketing for SSM (maybe that is appropriate
> 	somewhere, but not on the MBONED list).
>
> 	Let's stay away from marketing and speculating about what
> 	might happen (or for that matter, what might have
> 	happened), and spend our resources on multicast
> 	deployment, which is the charter of MBONED.
>
> 	Thanks,
>
> 	Dave
>
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic