The IP over ATM Mailing List Archive by date

[Jim Forster <forster@cisco.com>]

> > > I was referring to the market: given uncertainty, some customers might
> > > hold off on ip-over-atm, and use lane instead (just so it's clear, I'm
> > > advocating nothing; it's just an opinion about how the market might react
> > > to changing the default encapsulation(s) at this point in time).
> > 
> > I don't think that a little tweak like changing the packet format is
> > going to influence the deployment of Classical IP very much at this
> > point, especially when compared to the inability to multicast or
> > broadcast.

Folks,

I agree that Multicast over ATM is very important, however I take issue with
the view that changing an encapsulation is 'a little tweak'.  Changing the
encapsulation, or even adding a new one for multicast, is something that we
should undertake only after a lot of long hard work convincing ourself that
there is absolutely, positively, no other way to do multicast over ATM.

I'll readily admit to not following this discussion closely, but the
thought of an encaps change really woke me up.  Folks: we, and others, put
a lot of effort into optimizing code and hardware.  If we didn't do this,
our products would be more expensive and go slower.  This optimization
takes a lot of effort.  We'd like to put stuff into hardware, and make it
even faster and cheaper, but we can only do this if the specs stabilize.
Is is important to this group to have stable specs and faster and cheaper
hardware?

My understanding is that it the use of the multicast server, and the
consequent packet echos, that are driving the encaps change.  I also
understand that there are other approaches to multicast over ATM that don't
use a multicast server.  As always, there are tradeoffs.  Multcast servers
have some desirable properties (fewer VC's in the net is perhaps the
biggest) and some undesirable properties (natural choke points, double
hopping traffic).  I believe another undesirable property is that they
apparently force us to consider 1483 & 1577 as experimental, rather than
mature.

I also have an issue with the complexity brought about by the multicast
server.  But I've found that arguing against complexity invariably falls on
deaf ears in the 'standards committee' environment.  Ability to understand
and explain complex ideas becomes a badge of intellectual horsepower which
carries more weight than saying we should keep it simple.  So I don't
expect much support for an appeal for simplicity over complexity.

  -- Jim