"Chris A. Icide" <chris@nap.net> writes:
We use ATM for two reasons, 1) it's still significantly cheaper than long-haul circuits of the same capacity,
My canonical explanation for this is that people are actually deluding themselves into thinking that ABR will work and the "quiet moments" across a large number of VCs can effectively be statmuxed out of existence without hurting goodput. The apocryphal reason is that people with too much influence in carriers' decision making processes are desperately trying to gain enough revenue to justify the ridiculously large amount of money spent on deploying ATM and convincing everyone it was the way the truth and the light of the future, even if that revenue isn't as profitable as selling raw bandwidth. (cf. the canonical explanation) There are cases, however, involving inter-carrier handoffs where muxing at the virtual tributary/virtual container level doesn't work particularly well end-to-end, thus making ATM an alternative to SDH<>PDH<>SDH conversions. These cases are becoming rarer over time as people deploy modern SONET/SDH muxing and terminal equipment.
2) it provides some interesting abilites that are only now beginning to show up in the mainstream IP hardware.
Ok, I'll bite: which ones? The only ones I can think of right off the top of my head involve the counting problem. (Modulo easy deployment of cisco's rate limiting and/or the ability to make tunnels fast). Rather, I guess the question is, which of the "interesting abilities" (which I agree are interesting in a theoretical sense) are actually practically useful when running part of the Internet? Sean.
Ok. I will bite, although I hate to open my mouth, as my shoe always seems to bee-line for it.. ;} Sean M. Doran wrote:
"Chris A. Icide" <chris@nap.net> writes:
We use ATM for two reasons, 1) it's still significantly cheaper than long-haul circuits of the same capacity,
Yup.
My canonical explanation for this is that people are actually deluding themselves into thinking that ABR will work and the "quiet moments" across a large number of VCs can effectively be statmuxed out of existence without hurting goodput.
I don't think so.... how about the ability to mix voice, MPEG, and IP on the same pipe ? Or, how about that with ABR my delay across the ATM fabric is reduced when I have more bandwidth open. (POTS is low on utilization, during this "theoretical moment in time") A couple milliseconds and a few extra Mbs can count ;)
people deploy modern SONET/SDH muxing and terminal equipment.
2) it provides some interesting abilites that are only now beginning to show up in the mainstream IP hardware.
Ok, I'll bite: which ones?
Oh, 2 things come to mind, my variability throughout an ATM cloud is greatly reduced versus a routing cloud, a cell requires WAY less time to cross a switches backplane, versus a packet through a router. And seriuosly less time to determine where to send it... Ok. So, maybe Cisco's Flow Switching approaches VBR having a bad hair day. (and tuned for SERIOUS tolerance, CDVT=10,000), but certainly not traditional routing. And, on ATM, my neighbors traffic never bothers ME. Unless I am sending to him, and he is running lossy, then it affects him ONLY... Most ATM switches have massive backplanes, the problem is usually the port/pipe of the greedy carrier, and does not affect a neighbor. The greed mongers can trash their own ports/pipes, but not yours... (now, if you happen to have paths through a monger.... sigh...) I can't really remember the last time I experienced HOL on my ATM ports (Historical Jibe: ;) On ATM QOS is available now. IP is getting there. The only REAL problem with ATM's QOS, at this time, is the ability for IP to allocate it ...... (At least for those who run the latest spec ATM nets) Legacy switches are not being brought into this..... I wouldn't mind if you weren't my (ATM) neighbor. ;) (And a GOOD one at that....)
Rather, I guess the question is, which of the "interesting abilities" (which I agree are interesting in a theoretical sense) are actually practically useful when running part of the Internet?
See above. Richard. mailto://rirving@onecall.net http://www.onecall.net/ A technical with too much influence in a carriers decision making process, desperately trying to gain enough revenue to justify the ridiculously large amount of money he spent on deploying ATM, and convincing everyone it IS the way, the truth, and the light of the future, even if it isn't CHEAPER than selling raw bandwidth ;> Quality Rules.
On Thu, 11 Sep 1997, Richard Irving wrote:
Oh, 2 things come to mind, my variability throughout an ATM cloud is greatly reduced versus a routing cloud, a cell requires WAY less time to cross a switches backplane, versus a packet through a router. And seriuosly less time to determine where to send it...
Hmm... I thought we went over this fallacy not that long ago on NANOG. Please look up the past NANOG thread with subject _Internet Backbone Index_. -dorian
Dorian R. Kim wrote:
On Thu, 11 Sep 1997, Richard Irving wrote:
Oh, 2 things come to mind, my variability throughout an ATM cloud is greatly reduced versus a routing cloud, a cell requires WAY less time to cross a switches backplane, versus a packet through a router. And seriuosly less time to determine where to send it...
Hmm... I thought we went over this fallacy not that long ago on NANOG. Please look up the past NANOG thread with subject _Internet Backbone Index_.
-dorian
Dorian, I could be wrong about a LOT of things. However, your thread in the NANOG is about network switching vs network routing, not ATM switching. This is Apples to Oranges. Network Switching: Using MAC address to determine next hop. Network Routing: Using layer three address to determine next hop. ATM Switching: A path set up once, by one or more of the above (or none), to deliver cells across a multi hop, or point, path. Although comparisons can be made between "Network Switching and Switching", they are not the same thing. (Although some elements are in common) One is a methodology to determine a path. The other is a method of delivering a requested path. Never forget, A full NxN-point Matrix (non-folded) is almost always faster than a BUS. Although, many would call a Matrix a BUS ;) Sigh..... It reminds of a local Newspaper that was so kind as to point out that Multicast is Infinitely Inferior to HDTV. And they had the GUTS to declare that Multicast would not make it because of this. Can someone point me to the multi-user conferencing specs for HDTV ? And what API set do I use to access it ? ;)
Chris Said: -----------
reasons, 1) it's still significantly cheaper than long-haul circuits of the same capacity,
Your implication is wrt publically resold managed L2 networks such as ATM or Frame Relay. My earlier comments were addressing private management of one's own L1 network using L2 ATM or FR. Not to say either of us are wrong, just to frame the comments. Sean Doran said: ----------------
My canonical explanation for this is that people are actually deluding themselves into thinking that ABR will work and the "quiet moments" across a large number of VCs can effectively be statmuxed out of existence without hurting goodput.
I attempted a large diatribe here to examine what you mean by work, but my semantical misunderstandings lead me to instead ask you: What do you mean by the statement "people .. thinking ... ABR will work"?
The apocryphal reason is that people with too much influence in carriers' decision making processes are desperately trying to gain enough revenue to justify the ridiculously large amount of money spent on deploying ATM and convincing everyone it was the way the truth and the light of the future, even if that revenue isn't as profitable as selling raw bandwidth. (cf. the canonical explanation)
I'd agree with you if you were right, Sean. However, this statement is bullocks. It's not all a conspiracy, though it makes for an interesting plot line for nanpcog. The amount of money spent on ATM research is paltry relative to the current market. ATM achieved prominence in the ISP bb for two reasons: o It worked o It was available ATM will retain prominence for some time for many reasons, some of which are: o It continues to work o It cotinues to grow in if speed o Investment in knowledge o Capital and Installation Investment o Investment in tools This stream of characters from you on how IP can do what ATM achieves is quite puzzling. Do you really, honestly think that IP has QOS built into it? My recollection of the rfcs is not eidetic, but the TOS fields aren't supported by anyone but a nonstandard marketing plan, wrong? ATM allows one to build qos and particularly granular flow modification into one's <L3 network. Additionally, the ability to measure based upon preaggregated src-dest flows is exceedingly valuable data, available from L3 routers with only a large expenditure of effort.
The only ones I can think of right off the top of my head involve the counting problem. (Modulo easy deployment of cisco's rate limiting and/or the ability to make tunnels fast).
Easy and cisco in the same sentence. Let me write this down on my web page of quotes....
Rather, I guess the question is, which of the "interesting abilities" (which I agree are interesting in a theoretical sense) are actually practically useful when running part of the Internet?
See my note from several weeks ago and comments above. -alan ps. for the record I am one of those who believe with most of my heart and not a small fraction of my unimpressive might that a ubiquitous fabric somewhere near L2 will make life good. As bw increases linearly, the interconnections will increase geometrically. Advancements in science will exponentially increase bw as the practical technology is used more commonly. I often wonder if people shouting IP IP IP are really worried about their own lack of malleability in dealing w/ other information pushing technologies. That slight jab aside, the statistical aggregation of muxing ability of one protocol is not all that greater than the other, so whether the aggregation appears at L3 or L2 should, to the best of my knowledge and experience, be fairly approximate, at least today. The downside to today's atm is the 1/ overhead and 2/ one cell/frame drop requiring all cells retransmitted by the higher layer (IP). pps. I'm really not all that in love with ATM. But it does work. If IP could do the things that ATM/FR can, then off we go. My experience and knowledge say that managing a really large, dynamic, and robust network requires more than flexibility than L1 pipes and L3 routers. Something in the middle is needed to smooth out the corners.
At 12:52 PM 9/14/97 -0400, Alan Hannan wrote: [whack...]
pps. I'm really not all that in love with ATM. But it does work. If IP could do the things that ATM/FR can, then off we go. My experience and knowledge say that managing a really large, dynamic, and robust network requires more than flexibility than L1 pipes and L3 routers. Something in the middle is needed to smooth out the corners.
It runs at right angles to my nature and my intellect, but in the networking world I've become a huge fan of pragmatism (if it works right now, do it). Building out a national network on a bizarrely short timeline, with no idea of what traffic flows would look like, I found ATM a great way to get things started. If my initial estimates were wrong (and they were), just provision more bandwidth between the two distressed endpoints. And frequently that bandwidth was available in days/weeks as opposed to the months that it was taking to get DS3s to build out a ring. So now I think in terms of the appropriate technology for the job; packet over SONET is a terrific way to connect two L3 devices which currently exchange ~40 Mbps and will probably want to exchange ~150 Mbps (or ~600 Mbps, or ...) within a few months or a year. But when you're trying to bring up a new device in a bandwidth starved city (Seattle a year ago comes to mind) and DS3 ATM is the only thing you can get, ATM does a bang up job, even if it's only 1 PVC to somewhere else. The network equipment market has made an outstanding leap from one choice (some would argue no choice) of tools to do any given job, to multiple tools to do the same job in any number of slightly different ways. Each tool, and each approach, is appropriate to some real-life situation. So given the pants-on-fire growth in this business, and the disjoint ways demand for equipment and bandwidth move v. supply, I'm in love with whatever works right now. -peter
On Sun, 14 Sep 1997, Peter Kline wrote:
now, do it). Building out a national network on a bizarrely short timeline, with no idea of what traffic flows would look like, I found ATM a great way to get things started. If my initial estimates were wrong (and ....
So given the pants-on-fire growth in this business, and the disjoint ways
While this has been pretty much the MO of most folks in how network is built, but this doesn't have to remaint that way. One of the things that needs to be engineered into building and maintaining national/international backbones is traffic accounting to an arbitrary granularity that paves the way for better traffic engineering and bandwidth projections. There are already ample tools to to per-prefix matrix of traffic right now. Tying this in with good sales projections will alleviate much of the last minute fire fighting. This will most likely never be 100% accurate and precise, but there is no reason why we can't get a better handle on bandwidth forecasts. (say to 95% percentile) Furthermore, with the deployment of WDM and Internet core devices moving closer to the transmission gear, if you have access to fiber, getting more bandwidth may become as straightforward as using an additional wavelength on the ADM that your router's plugged into. -dorian
participants (5)
-
Alan Hannan -
Dorian R. Kim -
Peter Kline -
Richard Irving -
Sean M. Doran