Mailing List Archive

> I suppose the proper quip would be, "gee, wouldn't you have
> better luck talking with your vendor rather than your
> competitor?"

Nahh, there is no way you could decline to offer an opinion. ;-)


Eric Carroll

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

The reality here is that today there is a wide deployment of SONET and
it is accelerating.
A year ago, ATM was the hottest "new" technology and everyone was
rushing to integrate
it into their products. Since ATM assumes a high speed, reliable
transport network, SONET
is the best choice. Thus began a movement by SONET equipment vendors to
merge the ATM
switch functions with the already available SONET mux. Of course, the
growth of the Internet
has changed all that and IP has emerged as a end-to-end protocol that is
here today with fairly
ubiquitous deployment. I suspect you will see the emergence of a
IP/SONET mux this year.


mm mm sssss nnnnnn * Bharat Ranjan *
m m m s nnnnnnn * Network Engineer *
m m m sssss nn nn * Microsoft On-Line Services *
m m s nn nn * (206)-936-0471 *
m m sssss nn nn * bharatr@microsoft.com *
*******************************************************
* The opinions/ideas in this memo are not necessarily *
* those of Microsoft Corp. *
*******************************************************
>

| Ok, NDA aside then, too. Assume you had to decide now. You go multi
| DS3 and wait for new options because you do not need more than 2xDS3
| = OC3c + ATM? Would you go 3xDS3 and load share?

Yes to the latter. When we were thinking about scale
some time ago, Vadim sketched out a very reasonable
proposal for a stacking network topology to build a
3xDS3 network immediately or incrementally.

Router technology has changed to the degree that we could now
do this fairly cheaply in comparison to any solution which
offered comparable bandwidth in a unified form; the key
additional costs would involve space for CSU/DSUs, and the
extra slots to make up for the poor port density HIP cards
give you. This compares favourably with the space
requirements of ATM switching equipment, especially when
factoring in other cost items such as configuration and
maintenance.

If building a network with a relatively small set of POPs
and circuits that follow fibre paths, the trade off thus
would be less space/power/heat/capital costs and more
complexity and the ability to do sustained traffic flows at
more than DS3. Packet forwarding technology changes in the
75xx architecture appear to have ameliorated the latter too.

In networks with very different topologies, YMMV.

I suppose the proper quip would be, "gee, wouldn't you have
better luck talking with your vendor rather than your
competitor?" (or even gee, ATM is neat, go for it!), but I'm
in a helpful mood for some reason today.

Sean.

>
> >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 :)
>
IMHO loss writeoff would be less of a loss than deploying ATM
and having to live with it. It's not that I hate ATM per se,
but why pay the performance penalty when ATM provides no value
add,

Larry Plato
I speak for myself only.

In message <199603290546.VAA26294@lint.cisco.com>, Paul Ferguson writes:
> 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
>


Paul, Shikkar,

Can we move this discussion to alt.religion.atm?

Curtis

Vadim continues:

[ ... ]

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

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

Running real time sensory data, for example that must arrive at remote
locations within a few milliseconds on a packet switched network,
for example.... 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...

--------- attached --------

\bibitem[Ferrari90]{Ferrari90} Ferrari, Domenico,
{\em Client Requirements for Real-Time Communication Services},
IEEE Communications Magazine, November 1990, pp. 65-72.


\bibitem[CSZ92]{CSZ92} Clark, D., Shenker, S., and Zhang, L.,
{\em Supporting Real-time Applications in an Integrated Services Packet Network:
Architecture and Mechanism}, ACM SIGCOM, September 1992.

%\bibitem[QoS95]{QoS95} Lee, W., Hluchyj, M., and Humblet, P,
%{\em Routing Subject to Quality of Service Constraints in Integrated Communications Networks},
%IEEE Network, July/August 1995, pp. 46-55.

\bibitem[Zhang87]{Zhang87}Zhang, Lixia,
{\em Designing a New Architecture for Packet Switching Communications},
IEEE Communications Magazine, Vol. 25, No. 9, September 1987, pp. 5-12.


------- end --------

Hope these help, there are more......

Regards,

Tim

Vadim,

I think we are accidently cross-wired.....

I agree 100 percent that real-time data cannot be guarenteed over
public networks. There is little benefit to discuss .999999s
over public networks.

My point was to point out that there are applications for real-time
packet services where RSVP does not meet the requirements and
neither does ST-II (who tunnels IPv5 over a public network and
does any real-time work ??... none to my knowledge!)

In my previous posts on this thread today, I intentionally did not mention
public networks; sorry I did not specifically state the word
'private' . I assumed that Everyone in Networking knows that
.9999++ delivery over public networks was not what I was discussing.

Hopefully the confusion is clear.... when I mention real-time
data services, I am talking private datagram services, not
public.

Best Regards,

Tim

On Mar 29, 9:20, Mike Trest <trest@atmnet.net> wrote:
> The discussions regarding ATM/SONET and IP over ATM are finally focused
> on a fundamental issue:

In fact, this is getting boring. Your arguments sound convincing,
but don't really say anything else than "ATM is good". In
particular, the apparently wide "industry acceptance" is nothing else
than the outcome of the hysteria which invariably surrounds new,
flashy thingies that promise to solve all problems. It isn't the
first time that essentially non-functional, seriously flawed, and
ridiculously expensive technology is being pursued with great
vigour. It's techno-religion for the masses and the unwitting, and
the vendors are simply satisfying the demand -- they're in business,
after all, it's what vendors do (and that's fine with me).

The fundamental question which remains without an answer is this: In
which way do my packets benefit if transported by ATM? Is it
cheaper? Doesn't look like it. Do they travel faster? No. Can I
send more? No. Is it simpler? No, which means more failure modes
(historical evidence, if nothing else, is plentiful). Is it more
reliable than the alternatives? Probably not. So what do I stand to
gain?

--
------ ___ --- Per G. Bilse, Mgr Network Operations Ctr
----- / / / __ ___ _/_ ---- EUnet Communications Services B.V.
---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL
--- /___ /__/ / / /__ / ------ tel: +31 20 6233803, fax: +31 20 6224657
--- ------- 24hr emergency number: +31 20 421 0865
--- Connecting Europe since 1982 --- http://www.EU.net; e-mail: bilse@EU.net

On Sat, 30 Mar 1996, Per Gregers Bilse wrote:

> On Mar 29, 9:20, Mike Trest <trest@atmnet.net> wrote:
> > The discussions regarding ATM/SONET and IP over ATM are finally focused
> > on a fundamental issue:
>
> The fundamental question which remains without an answer is this: In
> which way do my packets benefit if transported by ATM? Is it
> cheaper? Doesn't look like it. Do they travel faster? No. Can I
> send more? No. Is it simpler? No, which means more failure modes
> (historical evidence, if nothing else, is plentiful). Is it more
> reliable than the alternatives? Probably not. So what do I stand to
> gain?

To put it another way:

What problem does ATM solve that it's alternative doesn't, and what
problem does ATM create that it's alternative doesn't?

You can do your own cost-benefit analysis to determine if you are
interested in ATM.

-dorian

| 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?

I would recommend talking to your sales representative
about getting an NDA presentation.

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

Gee, there are lots of OSI vendors too. Go for it.
You can leverage the fun stuff done by CDNNET. :-)

Sean.

> I would recommend talking to your sales representative
> about getting an NDA presentation.

Ok, NDA aside then, too. Assume you had to decide now. You go multi
DS3 and wait for new options because you do not need more than 2xDS3
= OC3c + ATM? Would you go 3xDS3 and load share?

For sale today, there is nothing other than AIP that you can go OC3
and above with. That's a problem, but it also mean ATM gets
considered, reasonable or not.

> Gee, there are lots of OSI vendors too. Go for it.
> You can leverage the fun stuff done by CDNNET. :-)

haha. good one.

Eric