Subject: [NEXTEL-1] ATM

From: "Paul J. Zawada" <[email-masked]>
Date: Tue, 5 Aug 2003 11:28:10 -0500

My apologies for coming back into the the discussion so late; I 
haven't had a chance to keep up with the Nextel-1 email volume...

Let me point that I worked with ATM for quite a long time, going back 
to the first Fore ASX-100 switch NCSA bought in late 1993.  In the 
mid-90s I built a production MAN backbone and with Cisco LS-1010 
switches and worked with Ameritech on a WAN service based on an AT&T 
GCNS 2000 switch in Chicago.  (Both switches, IMHO, were the best 
available.)  I was also involved with a wide area OC12 ATM network 
using ASX-1000s operated by MCI in the mid-90s.  We used PVCs, 
soft-PVPs, and SVCs.   We had direct-attached workstations as well as 
Xylan/Alcatel LAN switches and Cisco 7XXX series routers with ATM 
interfaces.  Speeds ranged from NxT1 to OC12.  When I was on a 4.5 
year "sabbatical" (1999 through the beginning of this year) at a very 
large utility we also had an ATM WAN backbone based on LS-1010 
switches.  Suffice to say I have had a lot of experience with ATM in 
the real world.

There a lot of things I liked about ATM however the technology seems 
too complicated to get it to work  properly in the real world.  We 
invested a lot of time in money the technology but it never lived up 
to its promise.  Stuff always broke or under-performed. The reasons 
varied but usually came down to either the unintended interactions 
between TCP and ATM or differing interpretations of ATM Forum specs. 
When I was at the utility we attempted to use T1-emulation over ATM 
to provide connectivity between the IMC and Stargate switches in our 
EDACS  land mobile radio network.  Talk about a complete disaster- we 
had to migrate everything back the SONET TDM-backbone after many wide 
area failures.  Our customers suffered a lot through that fiasco.  If 
you think ATM doesn't have jitter and latency issues, you are 
mistaken.

Before you say, "well TCP/IP or T1-emulation is to blame" I will cut 
you off to remind you that in the world I live in, providing these 
services reliably is a requirement and will continue to be in the 
foreseeable future.  If ATM can't reliably provide reliable transport 
for these services, even for a transition period, it will continue to 
be relegated to niche markets.   In homogenous environments like in a 
carrier's frame or DSL backbone, ATM appears to work pretty well, but 
when you start to build a multi-service, multi-technology network ATM 
just falls apart.  Perhaps in theory it's a superior architecture, 
but implementations are at fault.  As an end-user (builder of 
networks) I don't care, all I know is that ATM was (is?) a horrendous 
pain in the behind.

I agree with you though that QoS and its cousins are red herrings. 
It's amazing how folks forget that that if QoS is implemented, 
someone loses... (traffic will be dropped or delayed.)  For these 
folks, QoS is great unless their traffic is the traffic taking the 
performance hit.  And like you say, these schemes are complicated at 
best and add a terrible amount of overhead.  I advocate what I call 
"brute force QoS"- providing enough bandwidth for everyone where they 
need it.    As example, check out what's going on with I-Wire ( 
www.i-wire.org ) or CA*Net 4 ( www.canarie.ca/canet4 ): deploying 
GigE or 10-GigE over WDM networks.  If you have enough bandwidth in 
the first place, requirements for things like QoS drop out.

TCP is undeniably broken as well, it's a chatty protocol that 
incorporates a congestion avoidance scheme that is especially brutal 
in low speed, lossy environments like radio.  Yes, for all of TCPs 
problems no one has some up with a decent substitute (and UDP doesn't 
count).  I haven't researched it in depth yet, but SCTP shows some 
promise as a replacement for TCP.

>   Further, you can't have long trains on the same tracks with these 
>little voice
>   packets. So the MTUs get set very small and the long trains get 
>broken up. The
>   resulting IP packet tax now imposed on all traffic makes the 15% 
>ATM cell tax
>   (relative to IP's 30+% tax with these small packets) look like chump change.
>   IPv4 has a 24 byte header. With a packet size of 100 bytes 
>(probably too big to
>   avoid anoying delays), the payload is 75 bytes and that's a 33% 
>packet tax. The
>  ATM header is 5 bytes. The payload is 48 bytes yielding the 15% cell tax..

The "cell tax" can be worse, depending on how you look at it...  To 
send 100 bytes of payload with IP, it takes 124 bytes.  With ATM it 
takes 159 bytes.  (It takes 3 cells, with the third cell padded out 
44 bytes to carry the last 4 bytes of real data.  3 x 53 = 159.) 
IMHO, this is a non-issue compared to the other tax you pay in the 
poor performance of ATM SAR implementations.   As someone once said 
on the NANOG mailing list "packet slicing sucks."   (And don't forget 
performing the SAR function adds additional overhead that the above 
calculation doesn't consider.)

I won't disagree that ATM is well-suited to handle voice traffic. 
But as ugly as running Voice over IP is, running data over ATM is 
uglier.

--zawada

-- 
Paul J. Zawada, PE       | Principal Network Research Engineer
[email-masked]          | National Center for Supercomputing Applications
+1 217 649 2233          | University of Illinois at Urbana-Champaign

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sO0ANB/LIdGAA/ySSFAA/61FxlB/TM
---------------------------------------------------------------------~->

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

---

From: Todd Marshall <[email-masked]>
Date: Tue, 05 Aug 2003 13:47:04 -0500

I'm left perplexed:

The carriers use ATM in the cloud. IP uses the cloud. IP is data. You're 
satisfied with IP.
The carriers use ATM in the cloud. Voice uses the cloud. Voice is data. 
You're satisfied with voice.
You're dissatisfied with ATM doing data.
You're dissatisfied with IP doing voice.
You claim that ATM has jitter and latency problems as well ... but voice 
over ATM you're satisfied with.

What's wrong with this picture?

I'll answer my own question with your assertion (but arrive at a 
different conclusion):
ATM appears to work pretty well, but
when you start to build a multi-service, multi-technology network ATM
just falls apart. 

Looking close, you'll find the carriers layer their networks. They 
don't  run voice and data over the same cloud. And they tune each layer 
for its particular traffic. And they tune each layer for its particular 
topology. And they do a whole lot of this tuning manually with 
provisioned PVCs that can take them days, weeks, or even months to 
engineer across the network elements. And they are firm believers that 
all issues can be solved by throwing band width and processing power at 
them, and bandwidth is cheap ... in the cloud. Unfortunately, the issues 
aren't bandwidth and processing power related so they can't be fixed 
with those remedies. But in spite of all that, the clouds "are" ATM.

When you look at the ATM model, you see that you can configure 
connections to deliver deterministic QoS. And you can use AAL1, AAL2, 
and AAL5 to deal with some payload issues (which I think is actually 
being taken in by red herrings). You can use CBR, rtVBR, nrtVBR, UBR, 
and now ABR to help the switches schedule their queues. The switches 
report back through the connection when a cell is dropped and remaining 
cells in transit can,  and in some cases should, be flushed. ATM has the 
ability to do this as soon as it drops a single cell. Most protocols 
restart the whole packet. I think this is foolish.

I contend that the tools are there to make it work. It's a software 
issue. And it's a topology issue. The fact that the model works for data 
and it works for voice is proof that the model is good. And you admit, 
IP is never good for voice.

You complain about the method of loading of cells with IP payloads. You 
claim it contributes to cell tax. This is really not an issue, but if it 
was, it is easily solved at the edge. Rather than throwing huge packets 
into the cloud, the protocol can interact with the source of the data at 
the edge. The long coal train can be loaded and sent a car at a time 
(the ATM cells being the cars). All the cars are filled to capacity 
except the last car. This leaves the data back at the source until the 
connection and the recipient can absorb it.

Dropping a cell is not a big issue using this technique. ATM immediately 
reports the last cell received back to the edge. If it's a live video or 
audio stream, it just continues on. If it's a video download or a large 
file, it flushes in-transit cells; backspaces to the last cell received 
+ 1; and proceeds on. It can do this easily because the cells always 
arrive in order. It can do this easily because it is connection oriented 
and was designed to do it. Nothing is lost that isn't allowed to be 
lost. Such cell losses are virtually always due to congestion (this will 
be less the case when the web nodes use wireless for layer 1).

Improperly layed out (can you say trunked), an ATM topology can be made 
to invite congestion. Properly spread out in a web it can mitigate it.

I also might point out, Cisco's best interests don't include making ATM 
succeed. Is it any surprise that Cisco's ATM boxes don't work well? It's 
widely known that Cisco's ATM offering is the worst in the industry by 
far. I have never heard anyone complain about the FORE boxes or the 
Nortel boxes. I've seen nothing but snickering about Cisco's boxes.

 From what I have seen in the applications of ATM, the model has been 
misapplied and abused. And this misapplication usually comes in the form 
of a heavy fan in-trunk-fan out model. If a web model is used, it 
spreads the connections out, I find it very hard to believe that you 
don't mitigate virtually all of the the issues you cite with a web model.

I have never seen anyone employ this strategy. But now with cheap 
UTOPIA-II chip sets, we should try it and see. ATM is "not" expensive. 
If you know of a case where an ATM web strategy has been tried and 
failed, I want to take a look at it.

/Todd Marshall

Paul J. Zawada wrote:

> Yahoo! Groups Sponsor
> ADVERTISEMENT
> <http://rd.yahoo.com/M=259538.3625325.4914071.1261774/D=egroupweb/S=1707367802:HM/A=1695348/R=0/SIG=11u38u3s2/*http://hits.411web.com/cgi-bin/hit?page=1374-105951838331032> 
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service 
> <http://docs.yahoo.com/info/terms/>.

---

From: "Todd Ellis" <[email-masked]>
Date: Tue, 5 Aug 2003 18:41:09 -0400

Jumping in, if you don't mind.

Alcatel's ATM switch is also used for the FTTH system they offer. The
Customer Premise Equipment/Optical Network Terminal (CPE/ONT) they use
provides up to 100 mbits Ethernet, 4-wire telephony, and an F-connector for
cable television off of the same box.  What's even cooler about it is that
only one fiber, a tri-frequency strand, is used between the switch and the
ONT.  One frequency is used for broadcasting the video, and the other two
are muxed to provide two-way communications from the ONT.  Kewl or what?
Best part, it works.  And, even better, prices have come down 20% each year
for the last two years and expected to drop further.

Todd Ellis

Raleigh, NC

-----Original Message-----
From: Todd Marshall [mailto:[email-masked]] 
Sent: Tuesday, August 05, 2003 2:47 PM
To: [email-masked]
Subject: Re: [NEXTEL-1] ATM

I'm left perplexed:

I'll answer my own question with your assertion (but arrive at a different
conclusion): 
ATM appears to work pretty well, but 
when you start to build a multi-service, multi-technology network ATM 
just falls apart.