Cell Relay Archive

[guru@deltanet.com (Bill Schultz)]

In <fgoldstein.339.01047CBE@bbn.com>, fgoldstein@bbn.com (Fred R. Goldstein) writes:
:>In article <1995Apr27.140227.20553@nb.rockwell.com> manfredi@engr04.comsys.rockwell.com (Albert E. Manfredi) writes:

:>>On the other hand, the ATM Forum is apparently going to address _real_
:>>use of ATM for voice, in which, I would expect, an SVC is assigned to
:>>each telephone call, at typically 64 Kb/s bandwidth.

[deleted]

:>ATM signaling (Q.2931) is derived directly from Q.931, so that's not the 
:>problem; in a sense, Q.2931 is really just an extension of Q.931 with some new 
:>ideas thrown in.  It was originally intended to be the short-term solution for 
:>ATM, but nobody's working very hard on a successor.  ATM's weakness for voice 
:>(SVC per call) is really one of competitive necessity:  STDM (N-ISDN) does it 
:>better, so why waste much effort on it?   ATM's fault here is that it 
:>introduces packetization delay, about 6 ms. for cells filled with PCM, and 
:>delay is the bane of telephony.  Plus you need a little build-out delay to 
:>de-jitter the incoming cells.  So it can't sound quite as good as STDM.
:>If you work at it, you'll end up with something almost indistinguishable in 
:>quality from STDM, but probably at higher cost.

Ummm, I hardly think that the 6 ms. packetization delay is an issue.  A 250 ms.
delay for a satellite hop IS an issue, but not 6 ms.

I am pretty much operating on the assumption that voice traffic will be totally
indistinguishable over an ATM link with less than 100 ms. of packetization and
switching delay.  Even with two to three switches between ends, this is an
easy standard to beat, given prioritazation of voice cells in each switch and
a relativly low percentage of voice traffic out of the total available ATM
bandwidth.  Thus, a typical implementation ought to be able to select a
build-out delay of something like 50ms. and achieve indistinguishable voice
telephony over ATM, even over long distances.

The alleged cost issue is questionable.  I have not seen any modeling of the
cost of voice traffic over ATM, but I hardly think that the "cost" is an issue.
If anything, the cost should be virtually free, given that the ATM link itself
is justified by the data necessity.

As an example of this, the cost of a 155 Mb ATM link here in Pac Bell land
(inside the Los Angeles LATA) is about $16,000 per month.  If you divide that
out by 20 work days and 9 hours per day you get a cost of $1.50 per minute.
If GDC is correct about a 60% idle time ratio on voice calls (and if the GDC
algorithm to not send cells when no voice signal is being transmitted is
working as advertised), then you ought to be able to cram roughly 4,000
voice channels over an ATM link (as compared with roughly 2,000 in native
SONET mode).  [Now, do you see why the Telcos want this?????]

Now, compare the cost of handling thousands of voice calls for $1.50 per
minute anywhere within the Los Angeles LATA with the cost of local
message units ($0.04/min.) or long distance message units ($0.06 per minute
and UP, depending on carrier and discount plan).  It doesn't take a genius
to figure out that putting 20-30 voice calls on your ATM backbone would
save you the entire proportional part of the monthly cost of the ATM link
(ignoring the depreciation cost of the hardware, which would only add a
minimal amount to this since the ATM switches are low five figure boxes).
And the capacity of the link is THOUSANDS of voice calls.  So how do you
claim that ATM will cost MORE?????

In fact, I believe that knowledgable Internet Service Providers will put in
ATM switches and offer voice traffic in competition with the phone companies
in the very near future because they can beat the pants off of the phone
company's prices.

:>That's why it seemingly makes sense to use T1 circuit emulation to share ATM 
:>pipes between PBX trunk groups and data.  It minimizes delay and keeps things 
:>simple, leaving call intelligence in the arena where it is well understood.

This is very true.  Also, given the GDC description, the unused time slots on a
T1 do not generate cells on the backbone, so who cares if I have to allocate
voice circuits in blocks of 24 anyway?  If I only use one or two time slots in
a given virtual T1 circuit, it will only take up backbone bandwidth for some
fraction (remember, 60% idle) of 128Kb.

:>Now there are potential optimizations by doing SVC voice, so it's not 
:>perpetually hopeless; it's just not likely to set the world on fire very fast.
:>The sad thing, of course, is that it was just this application that the short 
:>cells were designed for; data folks would have preferred 64 or even 128 octet 
:>payloads, but SVC voice is affected too much by the packetization delay.

This is also true, and GDC at least claims to have those optimizations in the
pipe, if not already implemented.  It is just that SVC means a T1 link in the
GVC implementation.  So what?  The kind of large organization with an ATM
backbone will probably have PABX switches at each end anyway.  So, does
a T1 card for a PABX really cost THAT much?

I just believe that the phone companies are trying to spread the word that
this will not work.  However, at least one ATM switch vendor seems to have
a decent spiel about voice over ATM (its GDC, folks), and widespread usage
of this by any significant population would injure the bottom line of a lot of
phone companies.

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|     Bill Schultz     A Warped Mind Is A Terrible Thing To Waste.....
|                                     Use OS/2 Warp: Waste Not, Want Not.....