At 04:57 PM 1/19/96 -0800, Paul A Vixie wrote:
... The telcos have really screwed the pooch with ISDN, SMDS, and ATM. I'm not sure why F-R has worked well without years of delay, but it's a real anomoly. I have little if any confidence that I will be able to buy OC3 speed ATM and use it to contact 200 (or even 20) metro-area NAP partners any time this century.
ISP's who practice conservative engineering (i.e., safe sex) will continue to buy the fastest telco pipes they can get _among_those_which_actually_work_ and this is probably going to be raw fibre before it starts to be 155Mb ATM. I'm not in love with the idea of a barn full of routers all hooked up to a GIGAswitch milking machine, but I have to prefer the config that works.
Religious arguments aside, the obstacle for TCP/IP performance over ATM has been due to two factors, small buffers and no explicit flow control. The new switches have large buffers. TCP works well with these switches. Explicit flow control will allow more flexible bandwidth management. That applies to TCP as well as ATM. Check out the price of an ATM circuit (considering overhead, etc) and if you perceive value for the BW then buy it. No apology needed, just purchase orders. :-) If you find that you prefer raw bandwidth over optical fiber and lots of cisco interfaces, fine, but if you like network level switching, shared network bandwidth and the price for that, buy switched services. --Kent
Religious arguments aside, we are getting superb performance across the OC3 vBNS ATM network nationally for quite some time already, though big buffers had been architected in there from the beginning. Check on www.vbns.net and www.nlanr.net. Can't beat Jon's workstation performance yet, unless we talk about bandwidth*miles. ;) Then again, that may change some time as well. Stay tuned.
At 04:57 PM 1/19/96 -0800, Paul A Vixie wrote:
... The telcos have really screwed the pooch with ISDN, SMDS, and ATM. I'm not sure why F-R has worked well without years of delay, but it's a real anomoly. I have little if any confidence that I will be able to buy OC3 speed ATM and use it to contact 200 (or even 20) metro-area NAP partners any time this century.
ISP's who practice conservative engineering (i.e., safe sex) will continue to buy the fastest telco pipes they can get _among_those_which_actually_work_ and this is probably going to be raw fibre before it starts to be 155Mb ATM. I'm not in love with the idea of a barn full of routers all hooked up to a GIGAswitch milking machine, but I have to prefer the config that works.
Religious arguments aside, the obstacle for TCP/IP performance over ATM has been due to two factors, small buffers and no explicit flow control.
The new switches have large buffers. TCP works well with these switches. Explicit flow control will allow more flexible bandwidth management. That applies to TCP as well as ATM.
Check out the price of an ATM circuit (considering overhead, etc) and if you perceive value for the BW then buy it. No apology needed, just purchase orders. :-) If you find that you prefer raw bandwidth over optical fiber and lots of cisco interfaces, fine, but if you like network level switching, shared network bandwidth and the price for that, buy switched services.
--Kent
*some* new switches have adequate buffering for some potentially useful values of delay-bandwidth product. and other new switches barely have enough to replace a one-room ethernet. -mo
While we are on the subject of delay-bandwidth buffering in ATM switches. Does anyone know where I can get a router that has adequate buffering for those pesky little 1/4 Kbyte average size packets that keep floating around the net :). -joe PS. Also does someone have numbers for the amount of buffering in a DEC gigaswitch, and information on their buffer managment (i.e. variable length buffers vs fixed length buffers).
From "The GIGAswitch System: A High-Performance Packet Switching Platform". Robert J. Souza et al (7 listed authors) Digital Technical Journal, vol. 6, no. 1 1994. The switch fabric is a non-blocking crossbar capable of full 100 Mbps full duplex rates (actually, about 150 Mbps: a 25 Mhz clock with a 6 bit data path). Custom VLSI. The FDDI cards have 1 MB/port that (i believe) is used for packet buffering. Both input and output buffering is required. Cut through forwarding is supported. Bottom line: about 270,000 pps per port, 14 microsec. forwarding latency AND superior reliability. The choice for NAP designers everywhere :)- -- Bilal
While we are on the subject of delay-bandwidth buffering in ATM switches. Does anyone know where I can get a router that has adequate buffering for those pesky little 1/4 Kbyte average size packets that keep floating around the net :).
-joe
PS. Also does someone have numbers for the amount of buffering in a DEC gigaswitch, and information on their buffer managment (i.e. variable length buffers vs fixed length buffers).
PS. Also does someone have numbers for the amount of buffering in a DEC gigaswitch, and information on their buffer managment (i.e. variable length buffers vs fixed length buffers).
The Gigaswitch SCP card has (at last count) 16MB of DRAM for buffering packets (and other stuff) that get forwarded by the crossbar. The FGL cards (FDDI line cards) have 1MB of DRAM. There's a Digital Technical journal article available on-line that describes the Gigaswitch in detail. The URL is http://www.digital.com/info/hpc/sc95/sygiga-dtj.html Buffer management is discussed in the "Design Issues" section: http://www.digital.com/.i/info/hpc/sc95/sygiga-dtj-design.html Module details (like types and quantities of memory) are listed in the (hm) "Module Details" section: http://www.digital.com/.i/info/hpc/sc95/sygiga-dtj-module.html We have a Gigaswitch/FDDI at the Palo Alto interconnect, if you'd like to have a look at one. Stephen - ----- Stephen Stuart stuart@pa.dec.com Network Systems Laboratory Digital Equipment Corporation
Kent,
Religious arguments aside, the obstacle for TCP/IP performance over ATM has been due to two factors, small buffers and no explicit flow control.
I think you forgot one. The requirement to do VC-based reassembly also makes router interfaces hideously complex (relative to interfaces to frame-based networks, certainly), and hence prone to all the difficulties, limitations and unhappy corner cases that complexity breeds. And an additional requirement that the interfaces do something with flow control indications is not going to make them simpler. You know it is very hard not to wax poetic about ATM, despite one's best efforts to be objective. I am quite sure that ATM will support IP just fine in the end, just throw a few more bizillion dollars of R&D at it and fix everything. With all that fancy silicon laying around being sold at bargain-basement prices it'll be impossible to ignore. And all the while the segments of the industry which might be building routers are instead sitting on their hands waiting for the ever-delayed release of the next latest-and-greatest, all-seeing all-knowing SAR chipsets with fantasy visions of big honking ATM switches surrounded by teeny tiny routers dancing in their heads. And so I'm sure we'll get the big honking ATM switches surrounded by teeny tiny routers, and all will be happy and working well, just five years too late and five times too complex as the ATM industry figures out what many people already knew and funds yet more research, and produces yet more Forum standards, to work around the conceived-in defects with the technology when supporting this type of service. So you are indeed right, ATM will work very well for IP in the end and we'll never need to think about how irrelevant it might have been if we'd spent just a tenth of the effort advancing router technology. So, in any case, I agree with you, if you pick your equipment right and shake out the bugs ATM will carry IP just fine. And if the phone company prices the service so that it looks attractive compared to that provided by (cheaper and more reliable) TDMs, it'll sell like hotcakes. But I don't think it is being "religious" to be unwilling to let the phone company use one's own data to get its primary-school education about high-end data networking, and to shake the bugs out of a buggy technology, nor is it being "religious" to have regrets about what might have been. ATM can be its own self-fulfilling prophesy all by itself, just phone (not using ATM, no doubt, even the phone company is smart enough to avoid this for its bread and butter) when you get it working. Dennis Ferguson Speaking only for myself.
This all is probably true if the objective is to provide the best possible IP service. If you apply other requirements, like integration of the current telephony system, or, more accurately, evolve the telephony system, in the telephony company mindset, to something that also supports data, video, and things like that, things look different. Then again, so far I see little activity in the context of service integration. More ATM as a level-2 replacement for data networking. Which brings us back to your comments, as in such an environment the benefit is more marginal (e.g., ATM may still have multiple service qualities before it is being implemented in an IP(+) substrate). Oh well. If there were just concerted goals.
Kent,
Religious arguments aside, the obstacle for TCP/IP performance over ATM has been due to two factors, small buffers and no explicit flow control.
I think you forgot one. The requirement to do VC-based reassembly also makes router interfaces hideously complex (relative to interfaces to frame-based networks, certainly), and hence prone to all the difficulties, limitations and unhappy corner cases that complexity breeds. And an additional requirement that the interfaces do something with flow control indications is not going to make them simpler.
You know it is very hard not to wax poetic about ATM, despite one's best efforts to be objective. I am quite sure that ATM will support IP just fine in the end, just throw a few more bizillion dollars of R&D at it and fix everything. With all that fancy silicon laying around being sold at bargain-basement prices it'll be impossible to ignore. And all the while the segments of the industry which might be building routers are instead sitting on their hands waiting for the ever-delayed release of the next latest-and-greatest, all-seeing all-knowing SAR chipsets with fantasy visions of big honking ATM switches surrounded by teeny tiny routers dancing in their heads. And so I'm sure we'll get the big honking ATM switches surrounded by teeny tiny routers, and all will be happy and working well, just five years too late and five times too complex as the ATM industry figures out what many people already knew and funds yet more research, and produces yet more Forum standards, to work around the conceived-in defects with the technology when supporting this type of service. So you are indeed right, ATM will work very well for IP in the end and we'll never need to think about how irrelevant it might have been if we'd spent just a tenth of the effort advancing router technology.
So, in any case, I agree with you, if you pick your equipment right and shake out the bugs ATM will carry IP just fine. And if the phone company prices the service so that it looks attractive compared to that provided by (cheaper and more reliable) TDMs, it'll sell like hotcakes. But I don't think it is being "religious" to be unwilling to let the phone company use one's own data to get its primary-school education about high-end data networking, and to shake the bugs out of a buggy technology, nor is it being "religious" to have regrets about what might have been. ATM can be its own self-fulfilling prophesy all by itself, just phone (not using ATM, no doubt, even the phone company is smart enough to avoid this for its bread and butter) when you get it working.
Dennis Ferguson Speaking only for myself.
Hans-Werner,
This all is probably true if the objective is to provide the best possible IP service. If you apply other requirements, like integration of the current telephony system, or, more accurately, evolve the telephony system, in the telephony company mindset, to something that also supports data, video, and things like that, things look different.
I can't disagree with this but I think it misses the point, which is an issue which should be orthogonal to ATM. I think it may very well be the case that it is not possible to build a really large, reliable Internet without really large IP routers. I.e. it is not ATM that is the problem, it is this picture of a stinking big ATM switch milking hoards of teeny little routers the may not provide a scalable Internet. If you want to build a big Internet you may very well need big routers, it matters little whether they're plugged into an ATM switch or directly into a TDM (with the proviso that the router interfaces to plug into the former are going to be a technology generation or two more complex than the latter, no matter what you do). We know we want to build a big Internet. Yet somehow the big routers one may absolutely require to do this became (a) uninteresting as topics of research and development, (b) not well-understood as a necessity because of the big-switch-little-router picture, even though this may have no relationship to working reality, and (c) even if none of the above, the big-router development may still be constrained by the view that a big router is useless unless it is equipped with big ATM interfaces, even though the latter may turn out to be harder to build than the former and we're really getting the cart before the horse. So the end result is, no big routers, even though there is apparently little about ATM which eliminates the need for big routers if you want a big Internet. And all ATM has really managed to deliver so far is obfuscation of the issues, putting us in a holding pattern where we're just waiting to see what breaks but not doing that much about it. So I can't deny that the integration thing is attactive (I personally don't dislike ATM either, to tell the truth), but I really do think that somehow the priorities got all mixed up somewhere along the way. Instead of primarily worrying about advancing the state of the art for each of the services people actually want to buy, using whatever delivery technology was mature enough to accomodate this reliably, we've somehow instead made the integration the holy grail and have just forgotten to even care about whether there's anything left worth integrating by the time we find it.
Then again, so far I see little activity in the context of service integration. More ATM as a level-2 replacement for data networking. Which brings us back to your comments, as in such an environment the benefit is more marginal (e.g., ATM may still have multiple service qualities before it is being implemented in an IP(+) substrate). Oh well. If there were just concerted goals.
I would suggest that the reason you don't see a lot of activity in the context of service integration is that (at least at the phone company I know a little about) the guys that run the voice network are about the most pragmatic people in the place, which means they make sure their vendors deliver the big iron switches when they need them, and that they've got enough fiber in the ground to connect them together, so that even if it turns out that ATM isn't as great a thing as it was thought it might be, you still won't get a lot of fast busy signals. I wish one could say the same about the Internet. Dennis Ferguson
On Sun, 21 Jan 1996 15:28:43 -0800 (PST) Hans-Werner Braun wrote:
This all is probably true if the objective is to provide the best possible IP service. If you apply other requirements, like integration of the current telephony system, or, more accurately, evolve the telephony system, in the telephony company mindset, to something that also supports data, video, and things like that, things look different. Then again, so far I see little activity in the context of service integration. More ATM as a level-2 replacement for data networking. Which brings us back to your comments, as in such an environment the benefit is more marginal (e.g., ATM may still have multiple service qualities before it is being implemented in an IP(+) substrate). Oh well. If there were just concerted goals.
Telephony system, Telephony system... Oh yeah, I remember! That was that system they had back in the twentieth century for carrying primitive voice communications. I even think they used to run data across it in the days before the cable companies dominated. later, fletcher
... If you find that you prefer raw bandwidth over optical fiber and lots of cisco interfaces, fine, but if you like network level switching, shared network bandwidth and the price for that, buy switched services.
I find that the telco-supplied fast packet service we use inside CIX goes down several times a day and that about once every 60 hours it is necessary to call the switch technicians and have them power down my line module (which takes two minutes and is usually their prelude to swapping out a card) and then powering it back up (which takes two more minutes for diagnostics) before I can again exchange packets with anybody. I misspoke last time I flamed about this. There's probably very little that's intrinsically wrong (technically speaking) with these fastpacket data services. But the fact is, they are still so new to the telcos that they are not as bottom-line reliable as the things telcos have been providing for much longer, like raw bit pipes. So for example, if my three-carrier T3 buildout won't pass bits, I can make a four-party conference call with a pile of semi-experienced knuckle dragging switch techs and in a few hours over a few days I can cause someone to isolate some problem, fix it, and then we all move on to the next problem. With the fast packet services (SMDS and ATM, at least), when it doesn't work it takes a hell of a lot longer to fix and sometimes it doesn't get fixed at all. F-R, as I said earlier, seems to be the exception to this. ATM may be on the verge of getting better with the new generation of switches Kent spoke of. But up 'til now it's been better for me to buy the kind of bandwidth that the knuckledraggers down at my local telco know how to fix, and then put all the switching intelligence into a box I can lay my own hands on. Your mileage may vary.
participants (9)
-
bac＠serendip.sdsc.edu -
Dennis Ferguson -
Fletcher Kittredge -
hwb＠upeksa.sdsc.edu -
Joseph Lawrence -
Kent W. England -
Mike O'Dell -
Paul A Vixie -
Stephen Stuart