| "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.
