The IP over ATM Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <9505052104.AA06491@eng.adaptec.com>, Bryan Gleeson writes:
> Grenville, Dino, Andrew, Jim et al.
> 
> 
> [Grenville ]
> >> >> I'd have to point out that the ip-atm working group has, at last
> >> >> two IETFs, demanded support for both VC meshes and ATM level
> >> >> multicast servers. By constraining your scope as you have, you end
> >> >> up with a solution that would be insufficient for ip-atm's requirements
> .
> 
> This is basically the heart of the matter. With ATM we have two ways
> of doing multicast - full meshes and multicast servers, and each
> shares a wonderful characteristic:
> 
> a) full meshes don't scale (too many VC endpoints)
> b) multicast servers don't scale (bottleneck)

Sure is a good thing we have Classical IP over ATM and the ability to
break the network into smaller LIS and allow the network as a whole to
scale by adding routers.  :-)

> There will always be some trade-offs involved and there clearly isn't
> a one size fits all solution. A solution which is a good solution 
> for 10's of routers may be a very poor solution for 100's of hosts,
> and vice versa. There is a world of difference between a subnet
> with a large number of hosts and a small amount of broadcast
> traffic (say a few NIS packets now and then) and a videoconference
> between a number of hosts. Trying to take one approach and applying
> it to all the broadcast / multicast scenarios simply won't work.
> You will simply keep hitting brick walls due to real world resource
> limitations or performance barriers. Any solution adopted by the
> group has, I believe, got to address both the mesh and server
> approaches. The MARS currently does this. Dino's proposal is
> a neat solution for half the problem - but therein lies the
> problem with it. 
> 
> Bryan Gleeson,
> Adaptec.

Not to pick on you Bryan, but which half isn't Dino's proposal to use
IGMP solving?

I seem to remember the work group earlier rejecting the idea of using
IGMP, but I don't recall the exact reasoning.  I'll admit to not
having been doing my homework with regard to reading each iteration of
the multicast drafts and following all of the arguments.

If someone could recall that reasoning and it still seems sound, then
we can bring this thread to a close.  The justification for an
important decision such as this might also belong in the framework
document, so I'm particularly interested in getting a concise but
solid justification.

Curtis