Cell Relay Archive

[Koen Peeters <koen@ciminko.be>]

James Carlson wrote:
> 
> albert.e.manfredi@boeing.com writes:
> > Perhaps you didn't, but I agree with Ronald. Voice, when it is CBR voice, i.e.
> > like ISDN, is better over AAL1 than AAL5, obviously. The tradeoff with voice
> > over IP, assuming it ever becomes really useful, will be to trade off IP's
> > additional burden of things like RSVP + QoS IP routing, compared with ATM
> > signaling.
> >
> > Or sure, you can just ignore all the problems, assume best effort packet
> > switching with no QoS is fine for packet voice over IP, and then ATM will seem
> > unnecessarily complicated.
> 
> There are middle grounds -- such as using explicit mapping of TOS
> values on network boundaries to provide small numbers of QsoS where
> necessary.  This is better in many respects -- it avoids the signaling
> and state overhead and it avoids the complexity where undesired.  ATM
> does not generally allow that level of flexibility; you're either
> doing all signaled point-to-point connections perhaps with QoS (UNI
> 3.1 versus 4.0) or you're doing nothing.
> 
> > You said this twice, and I disagreed both times. In a decent sized ATM
> > network, many most of the intervening ATM switches should not care about most
> > of the VCIs they see going by. That's why you have VPs. Bundles of VCs would
> > be transferred through most of the ATM switches in a large mesh without those
> > switches caring about individual VCIs. Only for VPs which terminate at a
> > switch would the VCIs matter. In any event, telephone switching has been
> > going on for a good many decades, so this aspect of ATM is not completely
> > unchartered territory.
> 
> Yes, I'm well aware of how VPs work.  In this case, two levels just
> aren't enough if you want to take ATM from the edge (DSL-line) all the
> way through the core.
> 
> > > IP has state for routing only, so it does NOT need per-flow storage,
> > > and employs more sophisticated summarization techniques on the routing
> > > as well.  (PNNI is like OSPF, but there's no ATM equivalent of BGP.)
> >
> > IP will have state for flows as well. See RSVP. How successful RSVP will be in
> > a real network is still a bit of a question.
> 
> Except for folks who want to pay for the explicit signaling (which I
> suspect are a small minority), I doubt that RSVP will have any meaning
> in the long term.  Like UNI 4.0, it's just too damned complicated, so
> it doesn't really do any one job particularly well.
> 
> The good news for IP is that RSVP isn't really necessary to do QoS.
> In fact, RSVP just makes IP just as bad as ATM.  The really good news
> is that when protocols don't work, the IETF just abandons them, so
> there is some hope that this mess will resolve itself.
> 
> > I agree on PNNI being similar to
> > OSPF, but I fail to see why a BGP equivalent, when multiple ATM carrier
> > backbones become established, wouldn't be possible over ATM. I don't see PNNI
> > v1.0 as the end of that development process.
> 
> Well, of course not.  But it will have to go through the same learning
> curve.  IP is way ahead of ATM here.
> 
> > > Things are much better still for IP if you rip out the useless ATM
> > > layer and run IP over SONET, or, better still, IP directly on fiber.
> >
> > Fiber? What does that have to do with anything? The physical layer is hardly
> > the big deal here.
> 
> No, of course it's not.  Insert your favorite physical layer for
> "fiber" if you like.  I used that term only because the predominant
> use of ATM today is over SONET/SDH, and that's probably because, to a
> bell-head, ATM smells a lot like SONET/SDH just with much finer
> granularity of bandwidth provisioning.
> 
> The point I was making is that IP runs even better if you remove the
> SONET/SDH layer as well, since it's just yet more unnecessary
> overhead.  Gigabit Ethernet over DWDM is much, much cheaper than the
> equivalent SONET/SDH solution.
> 
> > Obviously, data buffers need to be large even over ATM, if the bursty nature
> > of data must be handled efficiently. Voice-sized buffers won't do.
> 
> The problems that WAN folks are seeing have to do with the fact that
> the large deployed ATM switches today are generally sized for voice.
> Of course, that's not true in Fore's "campus network" niche.
> 
> > > About the only solid argument I've seen in favor of ATM is that,
> > > unlike IP, telcos know how to use it now.  It's integrated into TRKS
> > > and TMN.  Of course, there are some good integrated CMIP/SNMP
> > > management tools available today, and things are still improving, so I
> > > doubt this meager advantage will hold long.
> >
> > The real question is just how successful IP can be for interactive, high
> > quality voice and video communications. You can either assume away all the
> > problems and see a rosy picture, or you can be realistic and add things like
> > QoS routing and RSVP to IP. At that point, you might want to reconsider which
> > system is simpler. There are a lot of people who know these things asking
> > themselves this question.
> 
> The implication being that I know nothing of these things?  Hmm,
> where'd *you* learn to debate?
> 
> When there's sufficient bandwidth, QoS is not necessary.  The question
> to me is whether it is easier or cheaper to manage a network with
> excess capacity using simpler protocols or if it's cheaper to attempt
> to manage a barely sufficient network using complex reservation
> schemes.  My off-the-cuff answer is that the cost of people (network
> management staff) to maintain a decent QoS network is far above the
> cost of the raw bandwidth, and therefore the limited resources should
> be spent going faster, not smarter.
> 

I think you are quite wrong here. I have been running IP over an ATM
network for 3 years now.
The network has become easier to manage, it has become more reliable as
well.
We run Voice over ATM through CES and get voice quality that is better
than the public network !
Don't even think of ever getting this quality by only trowing bandwidth
to the problem.

We can run this network now with less staff than a pure IP network. We
can't wait to make it still easier to maintain and more reliable by
trowing out all cisco's and replace them with an MPOA based routing
server.

We are not talking vaporware here but a really existing network with
about 60 sites.
 
> --
> James Carlson, Consulting S/W Engineer  <carlson@ironbridgenetworks.com>
> IronBridge Networks / 55 Hayden Avenue  71.246W    Vox:  +1 781 372 8132
> Lexington MA  02421-7996 / USA          42.423N    Fax:  +1 781 372 8090
> "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

-- 
 +--------------------------------------------------------------------+
 | Koen Peeters                || E-mail: koen@ciminko.be             |
 | CIMINKO NV                  || http://ciminko.be/                  |
 | Catherinalaan 37            || Tel. : +32 16 441933                |
 | 3110 ROTSELAAR              || GSM  : +32 95 501933                |
 | Belgium                     || Fax  : +32 16 441007                |
 +--------------------------------------------------------------------+