Cell Relay Archive

[James Carlson <carlson@ironbridgenetworks.com>]

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.

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