Mailing List Archive

Bharat,

> Has there been any thought given to How the OC-3c signal from a router
> will be connected to a OC-48 or 192 signal in a typical SONET ring?

Currently, the only way of doing this is the "traditional way" of using
SONET add-drop muxes to get you up to higher rates. You mux the STS-3c into
an STS-12 and then mux the 12's into a STS-48. This is what we are doing
in ATDNet which is a ATM OC-48 bidirectional line-switched ring for ARPA and DoD.
(see http://www.atd.net/atdnet.html).

As per our previous discussion, the trend seems to be putting the switching
and transport functions in one box so that you may be able to buy an
ATM switch that also does SONET protection switching.

> I would think that the SONET vendors (Alcatel, Fujitsu, etc) would have to
> work with the router vendors to ensure that SONET overhead information
> is passed properly to the higher level signal. This overhead provides
> data on performance, net management, etc. The kicker here is that SONET
> contains undefined overhead bytes that many vendors have used for
> proprietary services. This is the reason why different vendors'
> equipment cannot be mixed within the same ring. The CMISE set of
> standards is supposed to take care of incompatibilities, but as with any
> other standard, it will be complete years from when it is needed.

The SONET standards (at least for frame and overhead) generation are well
documented so that router vendors, theoretically, should not need to work
with traditional SONET vendors to get transport and framing functionality.
For ATM over SONET, there are also a number of chips/chipsets which will perform SONET
framing. PMC-Sierra (which FORE Systems uses) and IGT immediately come to mind (and I
know that I have missed some others). Of course, if a router and SONET vendor
want to work together to also offer some value-added functionality, that is an
issue.

You are entirely correct that many vendors have used the undefined overhead
for proprietary services. The most common overhead used are the growth
bytes (Z-bytes) and DCC bytes (D-bytes). In many cases, those bytes are used to pass
proprietary messages for network element control and maintainance. That is a
major reason why you don't see multiple vendors on the same ring. More than
likely the transport would work fine but the OAM would be a nightmare.

If and when the vendors fully implement CMISE, that would solve a lot of headaches.
Until then, we have to deal with a mixture of partial CMISE support, proprietary
interfaces, and TL-1 (Transmission Language-1, an old Bell System management
protocol). In lieu of this (and other factors), it is not surprising that
strategic partnerships between carriers and vendors are so common.


Shikhar

>According to Sean Doran:
> Someone suggested to me that it's because so much money has
> been spent on developing the technology that it HAS to be
> used in order to recover the investment.
>
>Doesn't the fact that they recover the investment mean that enough
>people wanted the product and were willing to pay for it?
>
>Shikhar

Nah, rather that they woudln't get a choice or would not know
better. ATM is like a pyramid craze.

--vadim

PS Can you say that loss writeoff is a way to recover investment?
I've certainly seen some clever accounting going on :)

| Doesn't the fact that they recover the investment mean that enough
| people wanted the product and were willing to pay for it?

Well, I dunno, it could also mean that an organization
with enormously successful marketing skills was able to
make hay out of an alternative that makes heedless yompers pay excessively
for often really unsuitable machinery. No?

Sean. (looking for better suggestions for a 'y' word)

At 10:48 AM 3/26/96 -0500, Shikhar Bajaj wrote:

>
>Currently, the only way of doing this is the "traditional way" of using
>SONET add-drop muxes to get you up to higher rates. You mux the STS-3c into
>an STS-12 and then mux the 12's into a STS-48. This is what we are doing
>in ATDNet which is a ATM OC-48 bidirectional line-switched ring for ARPA
and DoD.
>(see http://www.atd.net/atdnet.html).
>
>As per our previous discussion, the trend seems to be putting the switching
>and transport functions in one box so that you may be able to buy an
>ATM switch that also does SONET protection switching.
>

I fail understand, however, why ATM over SONET is desirable when there is
such a loss to overhead, especially when viable alternatives may exist to
get more bang-for-the-buck.

Perhaps someone could enlighten me on this particular datapoint?

- paul

Someone suggested to me that it's because so much money has
been spent on developing the technology that it HAS to be
used in order to recover the investment.

This may be somewhat apocryphal, but it's eminently
believable.

Sean.

According to Paul Ferguson:
>
> At 10:48 AM 3/26/96 -0500, Shikhar Bajaj wrote:
>
> >
> >Currently, the only way of doing this is the "traditional way" of using
> >SONET add-drop muxes to get you up to higher rates. You mux the STS-3c into
> >an STS-12 and then mux the 12's into a STS-48. This is what we are doing
> >in ATDNet which is a ATM OC-48 bidirectional line-switched ring for ARPA
> and DoD.
> >(see http://www.atd.net/atdnet.html).
> >
> >As per our previous discussion, the trend seems to be putting the switching
> >and transport functions in one box so that you may be able to buy an
> >ATM switch that also does SONET protection switching.
> >
>
> I fail understand, however, why ATM over SONET is desirable when there is
> such a loss to overhead, especially when viable alternatives may exist to
> get more bang-for-the-buck.
>
> Perhaps someone could enlighten me on this particular datapoint?

Several of our clients seriously consider
ATM/SONET the best way to go because they feel that a switched
technology like ATM is the best single technology (currently)
to offer them high speed and support for multiple applications (like
video and voice, as well as data). They are not just sending around
200-byte IP packets. Furthermore, the ability to get
quality of service support and guarantees is important them. They don't
think that RSVP, when it comes, will be enough. Finally,
to them, the economics makes sense. They understand the limitations
(i.e. overheads) and believe that they are acceptable.

If viable alternatives exist that are cheaper and better for your
applications, you should use them. All I'm saying is that to lots of
other people, ATM/SONET is just as viable.


Shikhar

At 12:36 AM 3/29/96 -0500, Shikhar Bajaj wrote:

>
>Several of our clients seriously consider
>ATM/SONET the best way to go because they feel that a switched
>technology like ATM is the best single technology (currently)
>to offer them high speed and support for multiple applications (like
>video and voice, as well as data). They are not just sending around
>200-byte IP packets. Furthermore, the ability to get
>quality of service support and guarantees is important them. They don't
>think that RSVP, when it comes, will be enough. Finally,
>to them, the economics makes sense. They understand the limitations
>(i.e. overheads) and believe that they are acceptable.
>

What you fail to mention, however, is that in an effort to achieve
these noble goals across the Internet, you are relegated to using IP
over ATM. This is the fatal flaw.

Sorry. I remain unconvinced.

Unless you begin building massive [native] long-haul ATM networks, this
is not an acceptable transport for the reasons I mentioned earlier.

- paul

> I fail understand, however, why ATM over SONET is desirable when there is
> such a loss to overhead, especially when viable alternatives may exist to
> get more bang-for-the-buck.
>
> Perhaps someone could enlighten me on this particular datapoint?

Telecom and datacom have historically been different worlds. Telecom kept
coming up with faster ways to do standard-interface long haul, and datacom
kept jumping into each new telecom technology.

Eventually the telecom people and the datacom people started talking to each
other and they decided to come up with an ubertechnology that would solve
all problems in both fields, once and for all.

Only a small number of the datacom people in the room knew anything about IP.

IP people have historically been "tin cups and string" users; as a rule, we
believe in context free switching (no virtual circuits), and we believe in
end-to-end {congestion control, error checking, connection management, and
reassembly}. IP's view is that you can build arbitrary complexity on top
of a good fabric, whereas an overspecified fabric makes down-simulation very
expensive and often unusable.

Traditional datacom and telecom people believe the opposite of all these
things. Witness X.25 as the canonical example of traditional principles in
action.

Both the X.25/ISO/ATM/telecom crowd, and the IP/datagram/end-to-end crowd,
believe that their ideology is best since it enables all other things to be
layered on top.

What ATM has is an excellent set of buzzwords and a lot of vendor support.

What IP has is an actual market with real end-to-end products and users.

With iPhone and cu-seeme and mbone starting to come into wide use, we are
running into a situation where IP needs more bandwidth than it can get from
most of the pre-ATM telecom solutions. The IP looks at ATM and says "this
thing wastes a lot of bandwidth*delay on things I'm already doing end-to-end,
and it does them in a way that my end-to-end implementation considers
pathological, so let's look for another solution." Hmmm, ATM seems to be
running on top of SONET. SONET is faster than modulating a bent coathanger,
let's run IP over SONET.

A worldwide fabric of IP-over-SONET and IP-over-bent-coathangers and IP-over-
tin-cups-and-string is _going_ to occur, and soon.

A worldwide fabric of end-to-end ATM may or may not occur, depending on the
PR capabilities of the folks who think it's the right way to go.

One of these nets will come up sooner, work better, and be cheaper. The
other one will go the way of X.25.

Where's Padlipski when we need him?

According to Sean Doran:
>
> Someone suggested to me that it's because so much money has
> been spent on developing the technology that it HAS to be
> used in order to recover the investment.
>
> This may be somewhat apocryphal, but it's eminently
> believable.
>
> Sean.
>

Doesn't the fact that they recover the investment mean that enough
people wanted the product and were willing to pay for it?


Shikhar

According to Paul Ferguson:
>
> At 12:36 AM 3/29/96 -0500, Shikhar Bajaj wrote:
>
> >
> >Several of our clients seriously consider
> >ATM/SONET the best way to go because they feel that a switched
> >technology like ATM is the best single technology (currently)
> >to offer them high speed and support for multiple applications (like
> >video and voice, as well as data). They are not just sending around
> >200-byte IP packets. Furthermore, the ability to get
> >quality of service support and guarantees is important them. They don't
> >think that RSVP, when it comes, will be enough. Finally,
> >to them, the economics makes sense. They understand the limitations
> >(i.e. overheads) and believe that they are acceptable.
> >
>
> What you fail to mention, however, is that in an effort to achieve
> these noble goals across the Internet, you are relegated to using IP
> over ATM. This is the fatal flaw.
>

Yes, I admit my guilt. Our clients are looking at solutions in
parallel with the Internet. They feel that sole reliance on the
Internet will not cut it.

> Sorry. I remain unconvinced.

That's fine. I'm not trying to sell anything to anyone :).


Shikhar

At 01:12 AM 3/29/96 -0500, Shikhar Bajaj wrote:

>>
>> What you fail to mention, however, is that in an effort to achieve
>> these noble goals across the Internet, you are relegated to using IP
>> over ATM. This is the fatal flaw.
>>
>
>Yes, I admit my guilt. Our clients are looking at solutions in
>parallel with the Internet. They feel that sole reliance on the
>Internet will not cut it.
>
>> Sorry. I remain unconvinced.
>
>That's fine. I'm not trying to sell anything to anyone :).
>

No -- I didn't mean to appear sanctimonious or self-righteous. This just
happens to be one of my pet rants.

If folks want ATM services, running then adjacent to the Internet is
a foolish thing to do. Parallel to the Internet fabric is certainly
doable.

- paul

>
>Shikhar
>

At 09:48 PM 3/28/96 -0800, Paul A Vixie wrote:

>
>Where's Padlipski when we need him?
>

Running IP datagrams across barbed-wire, methinks. ;-)

>
>What ATM has is an excellent set of buzzwords and a lot of vendor support.
>
>What IP has is an actual market with real end-to-end products and users.
>

Therein lies the thrust, Paul. Folks need to devise a more
'real-world' concept of acceptable long-haul data transport services.

- paul

At 12:49 AM 3/29/96 -0500, Shikhar Bajaj wrote:

>
>Doesn't the fact that they recover the investment mean that enough
>people wanted the product and were willing to pay for it?
>

Not that I want to beat a dead horse here, but please explain to
me how, if you consistently manage to only achieve 70%-80% effective
throughput on available bandwidth, you can recoup your investment
from subscribers who are expecting more?

Somehow, this sounds quirky to me. ,-)

- paul

Tim Bass wrote:

>As pointed out by Zhang et. al. in the late 80's, real-time applications
>over a store-and-forward datagram service is very problematic
>because IP is a best-effort service and there are no bandwidth/delay
>guarantees in the IP paradigm.

Real time applications are about as problematic with any transport
method in a public network, period.

Bandwidth reservation is nothing more than another name for
"higher priority". It works fine until your high priority
traffic does not overload the network -- with or without
resource reservation of any kind.

As soon as that point reached (i.e. network is overloaded)
resource-reservation starts to deny service; simple per-packet
prioritization starts to drop packets "fairly". That's the
real difference.

>On the other hand, ATM (based on the original ATM charter) was envisioned
>to offer a guaranteed QoS. As pointed out by numerous people in
>this thread and before, IP/ATM is not efficient; and it is for
>this reason and others that many IP protagonists love to bash
>ATM, and with good reason from an IP perspective.

Worse than that, ATM is unable to fulfill its promise of
"guaranteed QoS" in global networks. ATM folks didn't appear to
understand that all routing stability problems won't disappear
just because somebody shreds packets; in fact, it is easily
demonstrable that those problems will be worse than with IP.

>There is no current architecture to *guarantee* a close to zero
>packet loss in the IP world.

Moreover, nobody needs it. Packet loss is a necessary component
of distributed congestion control, and works better than previously
implemented ECN schemes. (That intuitively makes sense, as packet
loss removes packets from congested network, while ECN doesn't).

>Do we need a real-time protocol that is highly reliable in the
>world? The answer, is of course YES.

NO. Name the single application which couldn't be run over
lossy protocol.

>Finally, as pointed out TCP/IP/ATM is not efficient. On the other
>hand, transmitting packets, losing them in the network and
>retransmitting them or just dropping packets from the stream
>is not the most efficient method of delivery either.

Yawn. ATM also loses packets, in a screwy way. It was a way worse
since it used to lose _cells_.

>I am not necessarily a protagonist for ATM, and my personal
>opinion is that ATM is too complex and tries to be all things
>to everyone, and that rarely if ever works.

No, it is simply a bell-head's idea of a data network. If they
no longer can shred things to bits they would shred them to cells.

--vadim

Steve Steinberg <steve@wired.com> wrote:

>I was talking with David Tennenhouse yesterday about why much of the
>Internet community hates ATM and he said something that seems very
>accurate: "Everyone worries about overhead in someone elses layer."

Heh. He's telling that to carrier ISP people who are generally
quite involved in level-2 transport issues? 30% of bandwidth
is something to think of, when it costs more than all your equipment.

>It's true: just think of how much TCP/IP overhead we put up with that
>could be compressed if it was really important.

Have you ever asked why IP compressors were't a smashing success?
Answer -- because most of bulk traffic on Internet is compressed by
hosts (be it GIF or JPEG, or good ol LZW compress). You can't
really compress much of headers necessary for end-to-end reliability
without per-hop header reconstruction (that is done on very slow
links by PPP and C-SLIP, you can do that on T-1s with difficulty,
but forget about in on T-3s).

>(Not to mention HTTP overhead...)

HTTP is being fixed. ATM is beyond repair.

>Perhaps more importantly, stepping up fiber bandwidth is a
>lot easier than improving router speeds. So why does a 15% loss due to
>ATM really matter?

It's 30%, for starters. There's a lot of short ACKs and keystrokes.

Then, if "stepping up fiber bandwidth" isn't really a big deal why
do we need ATM's QoS stuff? Just throw in more bandwidth!

>Tennenhouse, btw, is proof that ATM did not come out of the telecom
>community alone as people like to believe.

You can write a FORTRAN program in any language. You can be a
bellhead without being employed by a telco (and vice versa).

>It's no suprise that they went with something like ATM that's good for
>switch efficiency but bad for transmission line efficiency.

That's a hogwash. ATM is bad for switching efficiency. That's obvious
to anybody who ever heard about relation between size of memory
footprint and speed, and can compare number of forwarding decisions
per byte of user payload in IP and ATM.

>Fortunately, that was probably the right tradeoff to make.

That's apparently why there's no global ATM network on horizon
but you can find Internet in Ust'-Kamenodyrsk.

--vadim

> NO. Name the single application which couldn't be run over
> lossy protocol.

Thats an easy one....

>Any generic system that receives time sensitive real-time information from
>numerous distributed nodes that must be processsed and relayed to
>other processing stations *and* run the typical IP e-mail, ftp, httpd,
>etc. packet services concurrently over the same pipes, as well as
>network management traffic ad. infinitum.....

Real application, not theory, please?

I've had some real experience with telemetry networks (did some harware
design for my dad's Constructor Bureau For Tele-Mechanics And Automated
Systems) and can say for sure that anybody who needs lossless telemetry
with millisecond delay tolerance must be insane to do it over any
public networks.

99.99% of real-life telemetry can live with losses just fine. In fact,
telemetry stuff often designed to receive several measurements and do
sanity check on them before anything actually happens. Practically all
real-life sensors are prone to fluctuations (splashes for liquid level
sensors, falling leaves for light brigtness sensors, ad infinitum).

>Running real time sensory data, for example that must arrive at remote
>locations within a few milliseconds on a packet switched network,
>for example....

Real application, please? I never seen one, not in large controlling
systems, not in military crap, not in scientific experiments (i've got
more than few friends who did lots of data collection & networking stuff for
high-energy physics research; in fact, my old e-mail address at Kurchatov
Institute for Atomic Energy is still valid :) It is always either
delay-tolerant in range of seconds, or it is "collect data now, analyze
later" or it is dedicated lines because you can't afford delays in
switches.

>I'll attach a few references for those who don't wish nor
>have the time to pull down the 12 page postscript draft mentioned
>earlier...

It seems to me that a lot of people are very busy solving a non-existant
problem. Anything new?

--vadim

Sean,

Ok, I will bite. Let's assume for a moment that dual DS3 is not
acceptible and I want IMUXed DS3s or a real optical interface. What do
you recommend for a Cisco?

ATM has the annoying advantage of having alot of people building for it.

Eric Carroll

Gentlemen,

I was reading this thread with interest and perhaps I have missed
something...... but here is what comes to mind;

As pointed out by Zhang et. al. in the late 80's, real-time applications
over a store-and-forward datagram service is very problematic
because IP is a best-effort service and there are no bandwidth/delay
guarantees in the IP paradigm.

ST-II build another unreliable service (with a smaller IPv5 header)
and created an odd-ball, no tool set, ST/SCMP paradigm that
continues to be unreliable without addition transport services.
Hence, the goal of a real-time QoS for datagrams over a routed
topology was not reached.

RSVP, building with lessons learned from ST-II and the added
IP feature of interdomain multicasting, has a better chance to
survive and to become accepted on a wider scale because
it is built on IPv4 with existing IPv4 tools and toolsets.
But never-the-less RSVP cannot guarantee packet delivery
and completely reliable real-time services. Resource reservation
does *not* guarantee a time-critical packet arrives from
source to sink and requires a transport protocol (like TCP
or some other flow control).

Therefore, for applications where packet loss is acceptable,
RSVP works; but in a real-time distributed internetwork
where data MUST be delivered within a specific QoS, RSVP
hold little real promise. On the other hand, for many applications
of datagram voice and video, packet losses are acceptable
so RSVP/IP is acceptable as well.

On the other hand, ATM (based on the original ATM charter) was envisioned
to offer a guaranteed QoS. As pointed out by numerous people in
this thread and before, IP/ATM is not efficient; and it is for
this reason and others that many IP protagonists love to bash
ATM, and with good reason from an IP perspective.

But, will all the cross fire and debate raging and the ATM - IP
debate raging the fact remains:

There is no current architecture to *guarantee* a close to zero
packet loss in the IP world.

Do we need a real-time protocol that is highly reliable in the
world? The answer, is of course YES. Will a datagram service
ever provide the .99999++++ delivery service required by
distributed, network based real-time systems? Maybe.
But IP based solutions alone will more-than-likely not
solve the problem.

Finally, as pointed out TCP/IP/ATM is not efficient. On the other
hand, transmitting packets, losing them in the network and
retransmitting them or just dropping packets from the stream
is not the most efficient method of delivery either.

Highly efficient, guaranteed packet delivery services with a
close to zero packet loss is an oxymoron and does not exist
and will not exist with RSVP (but will help but not to
.99+++ as required by real-time network services).

On the other hand, it is possible that a transport technology
that can deliver a guaranteed QoS under IP will work,
perhaps inefficiently, but it can deliver real-time data.

I am not necessarily a protagonist for ATM, and my personal
opinion is that ATM is too complex and tries to be all things
to everyone, and that rarely if ever works. But, there are
real-time applications where unreliable datagrams with
heavy transport protocol overheads similar to TCP/IP
are undesirable as well; and this paradigm is not so efficient
either.

Best Regards,


Tim

postscript:

The reader is invited to read and comment on a draft paper
http://www.silkroad.com/working/stii-rsvp.ps related
to this subject (but not addressing the ATM issue).

+------------------------------------------------------------------------+
| Tim Bass | |
| Principal Network Systems Engineer | "... the fates of men are bonded |
| The Silk Road Group, Ltd. | one to the other by the cement |
| | of wisdom." |
| http://www.silkroad.com/ | Milan Kundera |
| | |
+------------------------------------------------------------------------+

> >According to Sean Doran:
> > Someone suggested to me that it's because so much money has
> > been spent on developing the technology that it HAS to be
> > used in order to recover the investment.
> >
> >Doesn't the fact that they recover the investment mean that enough
> >people wanted the product and were willing to pay for it?
> >
> >Shikhar
>
> Nah, rather that they woudln't get a choice or would not know
> better. ATM is like a pyramid craze.
>

In this particular case, it has been (voraciously :)) pointed out that people
have other choices so I don't think that applies. As for "people not knowing better,"
I'm not even going to touch that one.

> --vadim
>
> PS Can you say that loss writeoff is a way to recover investment?
> I've certainly seen some clever accounting going on :)

True. Writeoffs and depreciation are a way to recover some of your costs. But
you still have to sell stuff to recover all of your investments. But, I'm
not an accountant so I don't know how far these things can be stretched.

If you have any good ideas, pass them on. April 15 is fast approaching.
Anyone got a router that I can use as a tax shelter? ;-)


Shikhar

>
> | Doesn't the fact that they recover the investment mean that enough
> | people wanted the product and were willing to pay for it?
>
> Well, I dunno, it could also mean that an organization
> with enormously successful marketing skills was able to
> make hay out of an alternative that makes heedless yompers pay excessively
> for often really unsuitable machinery. No?
>
> Sean. (looking for better suggestions for a 'y' word)
>

Perhaps. But I would hope that people would buy what they need as opposed to
what they THINK they need or are TOLD they need. As for the "heedless yompers,"
they're going to get taken no matter who does what.

>Not that I want to beat a dead horse here, but please explain to
>me how, if you consistently manage to only achieve 70%-80% effective
>throughput on available bandwidth, you can recoup your investment
>from subscribers who are expecting more?


I was talking with David Tennenhouse yesterday about why much of the
Internet community hates ATM and he said something that seems very
accurate: "Everyone worries about overhead in someone elses layer."

It's true: just think of how much TCP/IP overhead we put up with that
could be compressed if it was really important. (Not to mention HTTP
overhead...) Perhaps more importantly, stepping up fiber bandwidth is a
lot easier than improving router speeds. So why does a 15% loss due to
ATM really matter?

Tennenhouse, btw, is proof that ATM did not come out of the telecom
community alone as people like to believe. He was part of the U. of
Cambridge ring project (started in the late 70s) that used lightwight
VCs and fixed-length packets. A number of people familiar with this
project ended up at Bellcore, working on optimizing switch design.
It's no suprise that they went with something like ATM that's good for
switch efficiency but bad for transmission line efficiency.
Fortunately, that was probably the right tradeoff to make.


s.

On Fri, 29 Mar 1996 10:04:56 -0500 (EST) Tim Bass wrote:
>
> Do we need a real-time protocol that is highly reliable in the
> world? The answer, is of course YES. Will a datagram service
> ever provide the .99999++++ delivery service required by
> distributed, network based real-time systems? Maybe.
> But IP based solutions alone will more-than-likely not
> solve the problem.

I see no "of course." Are there some applications which require this
level of service in a WAN? Probably. Are there many? Probably not.
Is end-to-end relability and performance more important for the *vast*
majority of applications? Yes!

I worked on IP over ATM back in 1992-1993 and checked out of the
discussion at that time to move on to greener pastures. The
preliminary facts said that ATM would be a poor transport for IP.
After all these years, ATM still stinks. It still was designed for a
set of applications of decreasing significance (i.e. voice traffic).
Then people said: "wide spread ATM deployment is 4-5 years in the
future." Well, we are 4-5 years in the future now and they still say
the same thing.

Every day the Internet grows, the likelihood that ATM as a WAN
architecture will be successful fades. The only way it was ever going
to be successful is if the powerful RBOCs forced it down people's
throats. Their ability to do that is weakening as we speak.

fletcher

Fletcher replies:

>
> I see no "of course." Are there some applications which require this
> level of service in a WAN? Probably. Are there many? Probably not.
> Is end-to-end relability and performance more important for the *vast*
> majority of applications? Yes!
>

I'll concede the fact that the number of 'surf the net' applications
far exceed the number of real-time systems in the Internet.

But, we am working on a WAN project that required real time data delivery
every few seconds across the US to numerous sites. Even though the
numbers are few *today* they do exist and are growing in number and
complexity. In fact, there are numerous applications and system
designs just waiting for the 'network to support real-time services.'

Just because real-time services are in the minority of datagram services,
does not translate to 'the world should not support real-time services'.
If that is the logic that is used to make decisions, then let's
stop funding libraries because the vast majority get their information
from television!

Real-time WAN services with concrete .99999+ availability of QoS is
one of the growth areas of the next decade, BTW, and is a much
differnet service that providing access so 'Joe&Judy surf-the-net'
can pull down yet another file.

There are numerous applications for real-time datagram delivery
systems. ATM may not be the underlying transport, as mentioned;
but there is an emerging market for .99999+ datagram services.
The average IP provider may never see this market, but believe
me, they exists.

High regards,

Tim

The discussions regarding ATM/SONET and IP over ATM are finally focused
on a fundamental issue:

> Unless you begin building massive [native] long-haul ATM networks, this
> is not an acceptable transport for the reasons I mentioned earlier.
>
> - paul

IMHO, "... massive [native] long-haul ATM networks..." are aready
being put together (as we are doing) because:

(1) ATM is based on "good science" - a lot of people did a
lot of good research before building the first ATM switch

(2) ATM is based on "good economics" - pay large $$ once to
put fiber in the ground. Pay smaller $$ increments for
speed improvements whenever you figure how to build better
electronics at ether end of the glass.

(3) ATM is being supported by "good people" - I am not surprised
by the hundreds of announcements comming from a variety of
vendors. Can that many manufacturers be wrong? [.I admit
that a few are quite naive regarding impact of doing IP
networks over ATM today.]

(4) ATM and IP are already enjoying "good success" together.
We all hear about problems. Not enough is heard about
success. [Not enough press sizzle]. I have encouraged
all our vendors and customers to put their ATM success
story on their WWW page. Guess what! Most are so busy
with new business that they do not want to let their
competition know how they are doing it.

Here at ATMNET we are biased in favor of using ATM for transport
of IP traffic as well as non-IP traffic. We are not stopping
at the use of ATM as our backbone technology. We provide ATM
all the way to the customer premises at OC3 (or higher) speeds.

IMHO, ATM and IP are *NOT* conflicting technologies. The common
goal is to produce a survivable, scaleable, robust networks.
The respective focus is on a different piece of the common problem.
Early ARPAnet researchers and TCP/IP network builders understood
that the protocol had to be independent of the host computers and
the transport mechanisms to endure. [Yes, I date myself with this
admission.] Today's commercial developers still understand
this natural division. As network operators we must contribute
to the continuing IP/ATM dialog and focus our unique perspectives
[i.e. operating profitably] on the common goal.

I think members of NANOG are correctly voicing concerns about
the future of both IP and ATM. BUT have you noticed that a lot
of ATM FORUM members are also the very same manufacturers who
provide us our IP based equipment?

Perhaps we all need to do a better job of telling our IP equipment
providers of our ATM concerns. This is my practice. Unfortunately,
the manufacturers could all improve their responsiveness to
today's IP routing probelms.

We try very hard to keep our vendors informed of our expectations
of them on ATM and IP matters. This way, they go the the ATM
working groups and fight for what *WE* want.

..mike..

Mike Trest EMAIL: trest@atmnet.net
ATMNET Voice: 619 643-1800 / 619 643-1805
5440 Morehouse Dr, #3700 Fax: 619 643-1801
San Diego, CA 92121 Ans/Page: 619 960 9070