- Test - lists.nanog.org

Re: SONET Interconnect (was RE: MCI)
by avg＠postman.ncube.com 30 Mar '96

30 Mar '96

> 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

2 1

Re: SONET Interconnect (was RE: MCI)
by avg＠postman.ncube.com 29 Mar '96

29 Mar '96

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

2 1

Re: SONET Interconnect (was RE: MCI)
by avg＠postman.ncube.com 29 Mar '96

29 Mar '96

>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 :)

2 1

RE: SONET Interconnect (was RE: MCI)
by Bharat Ranjan 29 Mar '96

29 Mar '96

>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(a)microsoft.com * ******************************************************* * The opinions/ideas in this memo are not necessarily * * those of Microsoft Corp. * ******************************************************* >

1 0

Re: SONET Interconnect (was RE: MCI)
by Paul Ferguson 29 Mar '96

29 Mar '96

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

4 4

RE: SONET Interconnect (was RE: MCI)
by bajaj＠bellcore.com 29 Mar '96

29 Mar '96

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

1 0

RE: SONET Interconnect (was RE: MCI)
by bajaj＠bellcore.com 29 Mar '96

29 Mar '96

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

1 0

Re: SONET Interconnect (was RE: MCI)
by avg＠postman.ncube.com 29 Mar '96

29 Mar '96

Steve Steinberg <steve(a)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

1 0

Re: SONET Interconnect (was RE: MCI)
by Paul Ferguson 29 Mar '96

29 Mar '96

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

1 0

Re: SONET Interconnect (was RE: MCI)
by Paul Ferguson 29 Mar '96

29 Mar '96

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 >

1 0