- Test - lists.nanog.org

Re: ATM Wide-Area Networks (was: sell shell accounts?)
by Vincent J. Bono 27 Jul '96

27 Jul '96

<snip> > ATM can be used in two main modes: as a funny form of TDM > or as a means of overcommitting resources. > > The former is in use now in the land of InternetMCI, > ESNET, NSI and others, for better or for worse, and has > been for some time. As Tim and others have pointed out, > it works, given some tweaking here and there with things > like EPD. > > The latter has been observed in use as an offering by MFS, > and it had obvious problems. It has also been observed > from time to time at the ATM-using NAPs, and also had > obvious problems. These problems were arguably not > directly the fault of ATM, but of arguably broken > interface and adaptation devices like ADSUs, ethernet > framers and FRADs. I'd wonder if a large part of the problems are not avoidable, but that since most persons do not as yet have a "feel" for ATM, its harder to see and diagnose building problems, or predict failure points. ATM acting like TDM *still* isn't TDM. "Load" testing is fine and well (sorry DISA folks) but it's the field use that matures technology and turns proposed process into good technique. We've watched the ATM simulations (and even helped with the code for a few) but nothing came close to predicting what happened in real life when clients implemented it, especially in the multimedia (IP/TV/VOICE) applications. -v

1 0

Re: Why aren't people changing their subject lines when threads drift?
by Justin W. Newton 26 Jul '96

26 Jul '96

At 11:42 PM 7/25/96 -0700, you wrote: >> Isn't IBM doing some sort of fancy load redistribution for the WWW >> servers its running for the 1996 Summer Olympics? I seem to recall they >> were determining the "closest" server via a technique called "ping >> triangulation", whatever that is. > >If so, that's pretty silly and is probably not leading to performance >that's very different from either purely random or strict round robin. > >Ping times only correlate to available bandwidth when congestion is bad. >Otherwise these two factors are militantly unrelated to each other. Well, I suppose all they have to do is buil a global OSPF network encompassing the entire internet and they'd be set. Justin "Yes I'm kidding" Newton Justin Newton Internet Architect Erol's Internet Services

1 0

route servers
by Shifter 25 Jul '96

25 Jul '96

Are there any other routers that allow incoming telnet sessions without a password besides route-server.cerf.net? -John -- shifter(a)portal.stwing.upenn.edu -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzF+qeMAAAEEALdaUpOTi8EtNjZMA9URTXGmQq1NPdyRSx2JXhQ7Q8Yz9qxU q3tqRtlydRqp37VPmygibGB8eS7RptqolTlYvrVMHXSDcZjKpgpZA9d+3rCKUaLM F9Hvltl2EafIEspVoNUYahpdXof4oMjs2sKGzJO8aDwyM34pRaicZR8SZJz9AAUR tClTaGlmdGVyIDxzaGlmdGVyQHBvcnRhbC5zdHdpbmcudXBlbm4uZWR1Pg== =Eucp -----END PGP PUBLIC KEY BLOCK-----

1 0

None
by Alejandro Ortiz 25 Jul '96

25 Jul '96

suscribe ========================================================================= Alejandro Ortiz Herrera. Coordinador de Telecomunicaciones y Redes Ruteo Tel. (52)(8) 3 58 20 00 ext.4134 Direccion de Informatica (52)(8) 3 28 41 34 I.T.E.S.M Campus Monterrey Fax. (52)(8) 3 28 42 08 alortiz(a)campus.mty.itesm.mx ==========================================================================

1 0

Re: ATM Wide-Area Networks (was: sell shell accounts?)
by reb＠ieng.com 24 Jul '96

24 Jul '96

> At 9:33 PM 7/23/96, Curtis Villamizar wrote: > > In message <199607232130.QAA20147(a)uh.msc.edu>, Tim Salo writes: > > > > "Good" ATM switches are doing Early Packet Discard and Partial Packet > > Discard. You can ask your favorite switch vendor for details, or look > > at the following for a nice summary: > > > > http://www.fore.com/html/atm-edu/whitep/FTBMWP.html > > Also in the "dead horse dept" (I hope) unless you are dealing with > boneheaded switch vendors. Some don't believe in EPD/PPD preferring > ABR. Are any of them still entirely clueless in this regard and not > doing either EPD/PPD or ABR? I think a better question is which switch vendors are supporting _any_ kind of xPD besides Fore? At my last recollection, though I am no switch expert, only Fore. Certainly other switch vendors were starting to throw large buffers at the problem. And still others said "ABR will solve this problem. Wait for ABR." (And I'll add that this was said even when it was clear ABR was a couple of years away.) As for ABR, ATM vendors have been forecasting '96 and '97 deliverables since at least '94. As such, I would expect most of them to be doing or at least working on bringing ABR to fruition. But in order for ABR to be useful in a router environment, routers need to understand ABR. Anyone know what routers do? There are also issues wrt telcos' sunk investment in switches -- switches built when switch vendors were nearly unanimously boneheaded. Given telcos' tendencies to depreciate equipment over long cycles, one can expect those switches to be in telcos' networks for some time. ISPs looking to deploy their own ATM switches needn't be concerned with this but those looking to buy ATM service from telcos most certainly do. All hoping aside, I'm not so sure these issues are in the "dead horse dept"... eric P.S. I took a stab at answering my own question and found that out of the two vendors I checked, at least Cascade now implements EPD. ---- R. Eric Bennett <reb(a)ieng.com> | Internet Engineering Group 313-669-8800 (v) 313-669-8661 (f) | 122 S. Main, Suite 280 http://www.ieng.com/ | Ann Arbor, MI 48104

2 1

Re: sell shell accounts?
by salo＠msc.edu 24 Jul '96

24 Jul '96

> Date: Tue, 23 Jul 1996 19:03:08 -0400 > To: salo(a)msc.edu (Tim Salo) > From: Paul Ferguson <pferguso(a)cisco.com> > Subject: Re: sell shell accounts? > Cc: freedman(a)netaxs.com, nanog(a)merit.edu > > At 05:06 PM 7/23/96 -0500, Tim Salo wrote: > >The desire for a full mesh of VCs between routers becomes more compelling > >if you have more than three routers. The diagram is left as an exercise > >to the reader; I rather dislike having to draw in ASCII. > > > >Note that the two paths between A and C, (directly versus via B), seem > >to take distinctly different paths. (Perhaps, I missed your point). > > Perhaps I missed your point. > > Tim, I could've sworn that you had been following the IETF ION WG > mailing list, where this has been discussed on hundreds of occasions. > I hesitate to even mention this on NANOG (I really don't want to > re-hash this on this list), but I can't hold my tongue. > > The scalability of an ATM network where each end-point is fully meshed > to all other end-points decreases in direct proportion to the number > of end-points. This is not so much a layer 2 problem, per se, but rather > the ability to maintain functional routing (convergence, et al.) in a > fully meshed network topology. > > This does not scale. I believe that given my [secret] assumptions, (some of which are revealed below), it scales well beyond the financial abilities of most any NSP. I assumed that the wide-area ATM service supported only PVCs and PVPs. (I keep hearing promises of SVCs "next year" but I don't think anyone [domestically] has delivered them.) I believe this address your concern about maintaining functional routing, but I make no claims to being a routing expert, so I might not fully comprehend the issue. I also assumed that the going price for a DS-3 xwide-area ATM connection is, to more or less pull a number out of the air, $250,000/year. This has two implications: o Any one NSP isn't going to be able to afford all that many connections. A full mesh of 100 routers, (i.e., $25 millino/year in ATM services) would require 4,950 PVCs. That is a lot to configure, but... o Given that each link is rather expensive, it behooves the NSP to try to avoid needlessly moving a packet back and forth across a DS-3 local loop just because my ATM provider can't provide me with any more PVCs. (Which was my major point, by the way.) On the other hand, you are correct that this doesn't sale to thousands of routers. But, I didn't think that was the problem we were trying to solve here, (just yet). -tjs

1 0

Re: ATM Wide-Area Networks (was: sell shell accounts?)
by salo＠msc.edu 24 Jul '96

24 Jul '96

> From: Dave Siegel <dave(a)rtd.net> > Subject: Re: ATM Wide-Area Networks (was: sell shell accounts?) > To: salo(a)msc.edu (Tim Salo) > Date: Tue, 23 Jul 1996 10:22:23 -0700 (MST) > Cc: dave(a)rtd.net, agislist(a)interstice.com, nanog(a)merit.edu > [...] > Even > with the improved buffering, if you fill your pipe into the ATM switch, > your ATM switch still becomes a packet shredder, compared to the more > graceful packet drops seen on a clear channel line. > [...] "Good" ATM switches are doing Early Packet Discard and Partial Packet Discard. You can ask your favorite switch vendor for details, or look at the following for a nice summary: http://www.fore.com/html/atm-edu/whitep/FTBMWP.html -tjs I am not quite sure how an ATM switch becomes a "packet shredder," or even what a "packet shredder" is...

3 2

Re: sell shell accounts?
by Sean Doran 24 Jul '96

24 Jul '96

It's still ATM day, 'cause something else just occurred to me: | Consider the following configuration | | ________ _______________________ ________ | | Router | loop A | | loop C | Router | | | A |=========| Wide-Area ATM Service |========| C | | |________| |_______________________| |________| | | | | local loop B | | | ________ | | Router | | | B | | |________| How is one doing bandwidth allocation in this scheme? Are we assuming CBR (to be very conservative) (or VBR with V=0 for those that don't do CBR)? If so, then local loop B is really two circuits, one of BW X and the other of BW 1-X. Moreover, continuing with the thought of CBR or the equivalent, if one has a hundred routers in one's network, how does one allocate a fixed bandwidth from B to each router? Or does one overcommit and lean on UBR or ABR or some other *BR? These are serious questions I don't have an answer to, and come a result of having remembered the paragraph below and of remembering that a couple of our competitors have very large (admittedly "Frame Relay") PVC meshes. Sean. | The desire for a full mesh of VCs between routers becomes more compelling | if you have more than three routers. The diagram is left as an exercise | to the reader; I rather dislike having to draw in ASCII.

1 0

Re: sell shell accounts?
by Sean Doran 24 Jul '96

24 Jul '96

It's ATM day. | Consider the following configuration | ________ _______________________ ________ | | Router | loop A | | loop C | Router | | | A |=========| Wide-Area ATM Service |========| C | | |________| |_______________________| |________| | | | | local loop B | | | ________ | | Router | | | B | | |________| Consider the following configuration: Ra----fibrepath2----------RbRc------fibrepath2--------Rd or the following: Ra---ll1---[IXCi]---ll2---RbRc---ll3---[IXCii]---ll4--Rd I wonder what the distribution is, in terms of number of backbones, of each of the three models. (You may choose to imagine easy extensions like Ra and Rd really being two routers, with physical connectivity between Ra' and Rd') In terms of designing Internet backbones, do you see any issues other than cost when choosing between your version and either one of my versions? Also, does this change when there are, say, twenty-odd routers at each of the three locations? Sean.

1 0

ATM Wide-Area Networks (was: sell shell accounts?)
by salo＠msc.edu 24 Jul '96

24 Jul '96

> From: Dave Siegel <dave(a)rtd.net> > Subject: Re: sell shell accounts? > To: freedman(a)netaxs.com (Avi Freedman) > Date: Fri, 19 Jul 1996 16:01:01 -0700 (MST) > Cc: vansax(a)atmnet.net, richards(a)netrex.com, agislist(a)interstice.com, > nanog(a)merit.edu > > > Acceptable arguments are: > > o Switches can handle more throughput > > That's difficult to quantify in theory *or* practice. > [...] I may misunderstand your assertion, but it doesn't seem all that difficult to quantify, at least to some coarse level. We have been using wide-area ATM switches at OC-3c for some time. It is pretty clear that the switches can handle OC-3c. The early switches had relatively small output buffers, so they tended to loose cells before TCP could throttle back in congested circumstances. We are now using switches with much larger output buffers, and TCP appears able to throttle back fairly gracefully. After we upgraded our switches to use much larger output buffers, most of the problems we experienced were related to the hosts, (e.g., poor TCP implementations, poor ATM interfaces, etc). By the way, I believe that most people who are using ATM wide-area networks in production or as part of the Internet are using static bandwidth allocation to avoid a number of problems. We also have a number of OC-12c interfaces for our switches. They appear to work, but we haven't really had a chance to stress them yet. (Part of the problem is that it is hard to find OC-12c data sources and sinks.) The current generation of routers appears unlikely to support OC-12c, particularly since their backplanes are only about the same speed. On a more theoretical note, switches, being circuit-switched, make the complicated decisions when the connection is established, (or configured for PVCs), and need to make relatively simple decisions to switch each cell. This probably scales very well is terms of speed, although at some point might have some difficulty in scaling to a very large number of simultaneous connections. Routers, on the other hand, have to make a bit more complicated decisions per packet. This has some limitations in terms of speed and number of simultaneous "connections." -tjs

3 2