| "IP Unter Alles", in other words, right? No, not at all. IP under computer-to-computer data. WRT your list, I don't think that either videoconferencing or connectivity to the PSTN is a particularly interesting thing to do with the Internet, in that I don't see either as being a fundamentally important Internet application. Both are features, and some kind of voice and video with what humans consider acceptable lag is kinda neat, particularly when considering things like sex-on-demand, but this is not what the Internet should be designed for, since it's not likely to be the majority traffic by revenue attractor. So, I think that having a parallel infrastructure for real-time traffic is reasonable right now, and my business sense tells me that such an infrastructure would be much more ripe for metered-use than any combination network, whether built on ATM or IP or both. MBONE people will tell you about the fact that videoconferencing works quite well on various IP internets and the Internet now, despite the fact that the MBONE is still fairly primitive in terms of a global multicast plant. CUSEEME works reasonably on cheap equipment and dialup lines, and seems to scale aesthetic response against money fairly well, despite the fact that it's also a fairly simple first-cut. Various people, including a Sprint Canada reseller, will tell you that ALGs exist that convert various voice-over-Internet things into signals that can be dealt with by PBXes and other telephony equipment. There are at least two SS7<->IP gateways in development with what appears to be short times-to-market ahead. One of these is being built along the lines of what PNO like an RBOC or a PTT or a cable company might want to deploy in their own facilities. These are neat hacks which will do fun things to international and national long-distance tariffs worldwide, in that you may suddenly have two QOSes for voice: one which is a side-effect of IP connectivity and which is of iffy-to-tolerable-to-good quality, and one which has metered, often distance-and-time-of-day- sensitive charging and a generally predicatably very-good-to-excellent quality. So, wrt your point 4 (connectivity to PSTN needs ATM), you are right that you can't do it just with Cisco equipment, but you can't do much else just with Cisco equipment, as I don't think they build SONET/SDH MUXes, CSU/DSUs, phone switches and the like anyway. Neither do the currently-popular ATM vendors, for that matter. Go figure. We're now down to 155Mbps medium speed to the desktop. I imagine that we can avoid arguing about the small details of cell tax and the like, and start looking at Gbps ethernet and other forthcoming LAN issues. They really are LAN issues; the Internet vs global ATM really isn't a factor here, nor is really IP vs ATM on a protocol-to-protocol basis. | Oh, and by the way, given that the local loop provider has OC-48 SONET | provisioned to this particular location, we could just as easily have | provisioned the connection to our backbone at OC12 as opposed to OC3. Did | I miss the Cisco announcement of an OC12 IP-SONET card? You may wish to discuss an NDA presentation on the forthcoming generation of routers from each of Cisco, Juniper and Bay Networks. Nothing on the router market now really handles OC12 as a medium rate, whether we're talking POS or ATM or anything else. OC12 is too slow anyway, frankly. | [ATM] | does have some undeniable advantages, and one of them is its ability to | carry voice traffic independent of IP traffic, and to connect in a | reasonably straightforward manner to the PSTN. Would you prefer to have | voice traffic clogging up the IP backbone?? Well, the infrastructure telcos use now, whether based on SONET or on plesiosynchronous stuff, separates PSTN and IP and X25 and Frame Relay and even ATM and so on and so forth. I expect this to continue. The only argument in favour of using ATM rather than TDMish stuff really comes from the mystical promise of ABR, which, so far, doesn't seem to work well when mixing certain traffic loads together, notably enormously-aggregated TCP and anything bursty. If, however, a sizeable amount of dead space really could be recovered from various parallel networks, thus freeing up more bandwidth along fibre paths, I'm all for that. The problem is that this doesn't really work well just yet, and I'm disinclined to believe that it's likely to work well with big-I Internet traffic ever, thanks to its rather fractal nature. So, just to clarify things, I don't discount ATM as a technology entirely, I just think that its time as something between IP and SONET for big-I Internet applications (other than *maybe* for customer aggregation and the like), is ticking away... Sean.