- Test - lists.nanog.org

Re: Bell vs. Internet Providers (fwd)
by matthew＠scruz.net 10 Nov '95

10 Nov '95

Original message <199511101720.LAA04353(a)crash.ops.neosoft.com> From: Scott Mace <smace(a)crash.ops.neosoft.com> Date: Nov 10, 11:20 Subject: Re: Bell vs. Internet Providers (fwd) > > > ISP's should consider using a DS1 or better to deliver dialtone for their > modem banks. It makes alot of sense for the ISP and the phone company. > Delivering dialtone over a T1 is certainly more cost effective than paying > a %400 increase for Centrex lines. > > Scott >-- End of excerpt from Scott Mace 1. I suspect that any rate increases would apply to lines delivered over a DS1 as well. 2. Phone company pricing isn't reasonable. (Yet Another) Proof: We have a POP in Santa Cruz, CA. PacBell serves that location. We ran out of pairs to the building, and they refused to add more. We were given a choice,... either pay for more copper pairs to be installed, or have them install fiber, break the POTS service out from the fiber onto DS1 and get it that way. But we'd need to pay for the demux from DS1 to analog, for our modems, or buy (more expensive) modem racks with integral demux capability. They gave us a price of about $25,000 to pull 1200 pair. And since $20/line is significantly cheaper (10x) than you can buy a mux for, and significantly less than the difference in price to get the more expensive modem racks that swallow DS1s directly, we had them pull the copper. -matthew kaufman matthew(a)scruz.net

1 0

Address clustering intuition
by Walter O. Haas 10 Nov '95

10 Nov '95

This has probably been thought of before, or discussed on some other list, and if so I apologize in advance. I've formed an intuition that, if all IP addresses were portable (ie. independent of ISP) and assigned on a strictly geographic basis, then there would *automatically* be clustering of addresses equivalent to that obtained from CIDRization as a result of marketplace forces and the practicalities of technology. Note that this results from the address being, not the property of the ISP or the end user, but rather of a geographic location. In other words under my scheme if I picked up and moved a hundred miles I'd have to renumber, but if I just switched ISPs I wouldn't. -- Walt

9 12

Re: links on the blink (fwd)
by hwb＠upeksa.sdsc.edu 10 Nov '95

10 Nov '95

>I bet myself you would respond the way you did before I finished processing >my mail bag. I won. Sure, 100% packet loss is eminently acceptable if that >loss rate occurs not more than 1% of the time. Maybe 10% packet loss I suppose that is correct. 100% packet loss for 1% of my *connections*, I can live with that. We also lived with high delays (like 0.5 sec satellite round trip on USAN, I don't mean those occasional 75 seconds in some, ahem, other environments at that time), as long as it was predictable. What drives me nuts is if services are unpredictable, like immediate packet services at the 40% percentile, a few seconds and occasional losses for another 40% of the packets, and the opportunity to keep up with Dave's technical field between keystrokes for the remaining 20%. What does a consistent 10% packet loss mean? I think it has little to do with telco line qualities these days, more with resource contention. What is contended? A T1 line (or whatever) is never, ever congested, as it is just a simple bit pipe. The contention is at the equipment, called routers, that aggregate more traffic on the inbound interfaces than it can dump onto the outbound interfaces (e.g., for outbound line capactity reasons, and buffers then filling up in the router). Historically that was often a router problem, as they were too slow to deal with the onslaught of packets for a plain packet-per-second-rate (remember, in 1987 the NSF solicitation asked for a then whopping 1000 packets per second per router, which was just barely achievable then). Today you can buy technology off the shelf that does not have a pps problem for typical situations. So what is the problem, if it is not the rouuter interconnection or the router technology? The answer is bad network engineering, little consideration for architectural requirements, and lack of understanding for the Internet workload profile. Intra-NSP, perhaps even more among NSPs. Or, in other words, it is people that kill the network, not the routers or phone lines, particularly people who are trying to make money off it, probably using their unique optimization function focused on profit and limiting expenses as much as they can, not understanding the fate sharing yet. A constant 10% packet loss (or any constant packet loss) means that the network is underprovisioned. The *deployed* Internet depends heavily on massive aggregation of microscopic transactions (e.g., 10 packets or so at the 50% percentile of transaction, and tens of thousands of them perhaps in parallel). These aggregations result in some degree of steady state, but also burst behavior, which even in a well designed network can result in occasional losses due to overutilization of resources. But it should not happen consistently, if someone were to claim it to be a well designed and implemented network. The conventional wisdom says to upgrade the capacity (e.g., more bandwidth to improve the outflow from the routers) to handle the additional load in cases of resource contention. Can be an expensive undertaking, and an administrative nightmare, especially in the international realm. May be a bandaid could be a prioritization of traffic, so that more deservy traffic gets better services. For example, for my email 10% packet losses I would typically not even know about, but most interactive connections (call it lazyness, stupidity, whatever) create several packets per keystroke, with their demands for end-to-end echos (hey, Dave, you did a bad job of technology transfer out of Fuzzballs, as you got it right, line mode by default, going into character mode only if really necessary; i.e., proof that it is possible to do it right was available 10 years ago). Prioritization can be left to either the service provider (who may have to hide it; and it is also very hard to serve everyone right that way), or by the end-user. If the end-user specifies a service profile (be it IP Precedence or whatever) it will only work if there is a penalty for higher service qualities (e.g., quotas, or precedence-0 is free, higher ones cost the end-user (or someone else in the path who's pain would be desirable here) something). You would still need to understand the workload profile eventually, simple utilization graphs won't suffice if you compare the common microscopic transactions with those exhibiting a high bandwidth * duration product (e.g., them new multimedia thingies). Anyway, no magic here either. This issues are on the table for many years already, nothing new, though if the Internet is to survive, some service providers probably need to adjust their optimization models.

4 9

Re: links on the blink (fwd)
by Vadim Antonov 10 Nov '95

10 Nov '95

Bill Manning wrote: Just for grins, how fast do the LAN interconnects need to be? A FDDI is about as fast as a single DS-3. So it makes little sense to connect mode than one DS-3 to a BB box, since there's no way to get that traffic thru a LAN to customer access boxes in the cluster! Ideally, the capacity of LAN *attachments* (not the total bandwidth of the LAN switch!) should be about the same as the capacity of backbone links, multiplied by the number of backbone links attached to each backbone router. Of course, there are tricks to partially offload traffic from the cluster's LAN (like connecting high-speed customers directly to backbone boxes, and arranging BB topology so the transit traffic won't cross the LAN -- this works in case of "duplicate" backbone). Anyway, that boils down to the LAN switch being the single point of failure. There's no reasonable way to do "parallel" LANs with load sharing, as the number of destinations in intra-POP traffic is relatively small. Aggregations makes things even worse. All in all, the backbone router should be scalable to the point that it does not need any clustering; and redundancy is provided by "internal" duplication. --vadim

3 4

Re: Address clustering intuition
by Hank Nussbacher 10 Nov '95

10 Nov '95

On Thu, 9 Nov 1995 17:37:44 -0600 (CST) you said: >......... Geert Jan de Groot is rumored to have said: >� >� PS: it seems that a FAQ on this is desired (CIDRisation, router capacity >� growth vs routing table growth, flaps, need to renumber, etc), basically >� the topic of various discussions on NANOG, CIDRD, and probably >� other places. Volunteers? > > Hank has done some good work on this avilable at: > > http://www.rain.net/faq/cidr.faq.html > > I wish I'd done it :-) In fact, Hank, if you want to pawn it off, > let me know..... > > It would be nice to see some information on issues such as routing > table size v. address space, flapping, etc...... > > -alan Send me questions/answers to be added to the FAQ and I will update it as necessary. Hank

1 0

Re: links on the blink (fwd)
by Eric Kozowski 10 Nov '95

10 Nov '95

>First you will have to explain to me how taking routing >from the RA route server would help avoid a collapse >of my iBGP mesh... > > Sean. Just out of curiousity, is SprintLink still using AGS+'s in it's backbone? Eric -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1

1 0

Re: links on the blink (fwd)
by Vadim Antonov 09 Nov '95

09 Nov '95

Michael Dillon <michael(a)memra.com> wrote: >Are you sure that creative ways of using lots of smaller T3 bandwidth >boxes couldn't solve the problem? There are hard architectural limits on the number of core routers in the defaultless backbone. Backbone has to have a relatively small number of BGP speakers, to avoid severe routing information propagation problems. There _are_ "creative ways", see for example SprintLink presentations on NANOG, the planned "3-dimensional grid" backbone topology (it allows to grow the aggregate capacity to about OC-3). However, you inevitably run into capacity limitation of LAN interconnects. Then, there's a problem with load balancing, as it generally cannot be done with exterior protocols which have to select a single path. (And there's no easy way to do per-destination load distribution on a large scale). It's only a kludge to survive until (and if) somebody will build real central-office routers. >If you are right, then yes it sucks. Obvoiusly the ATM and OC3 >technologies are right where you have pegged them, but what about >parallelism using existing DS3 technology? And if this is done, are there >mux/demux boxes that can handle DS3's<->OC3 ? There are boxes which can *statically* mux/demux OC-192 to DS-3s. Synchronous muxes is not a high technology, being basicallly decorated shift registers. >One nice side effect is that this may force the video-on-demand folks off >the Internet and into straight ATM instead. I rather like the future >scenario where the globe is girdled by an IPng data network and a separate >parallel video/ATM network. That already happened. I would rather see things going in opposite deirection. (For VOD applications ATM is adequate, as it only demultiplexes big pipes from VOD servers into small access pipes; there's no backwards data flow, and no statistical multiplexing). However, the utility of VOD is very questionable, as the basic need to see the movie quite adequately and cheaply satisfyed by low-tech video rentals. It is not a "killer application", definitely. Video telephony and distributed computing network can be such applications but they beg for symmetrical IP connectivity. --vadim

5 4

Re: links on the blink (fwd)
by scharf＠vix.com 09 Nov '95

09 Nov '95

I think faster routers and bigger pipes will will not solve this problem. As a friend likes to say, that is necessary but not sufficient. HWB is right when he says that the network design is not coping. He left out tools, operations and customer support. I think there is some percentage of the service providers out there who don't care about the service they provide, but I believe (hope) that the mejority really do care. I don't know of a provider who's technical staff is big enough. They all have .45*current staff in open jobs. Until there is a sufficent engineering pool to handle the growth or the growth stops for long enough to catch up, we are stuck being more than a day late. (Hell, several of them have stooped low enough to offer me a job.) Both my direct experience and the discussions I have say that dollars, pounds, dmarks and yen are not the problem. Jerry

6 8

Re: links on the blink (fwd)
by Vadim Antonov 09 Nov '95

09 Nov '95

Dennis Ferguson <dennis(a)Ipsilon.COM> wrote: >Yet not only >can you not buy OC-12 routers off the shelf, or anywhere else, you can't >even buy honest OC-3 routers at this point (I will avoid progressing into >a rant on how the bizillions invested in ATM development to produce very >little of practical use so far might have been better spent...). That's funny to hear from somebody from Ipsilon :) Granted, ATM as is is quite useless. I have serious doubts that it can be made useful at all (as anything but a stupid framing protocol). The router capacity is not the only problem, there's also the long-haul capacity problem. Yes, fibers are not ribbon, and you can put only as many bits in them. So the current games with ATM (throw away 30% of user data capacity) and dual-ring SONET (throw away another 50%) as opposed to native packet switching is not even a silliness, it's plain old stupidity. >And I would suggest that if you were, say, a big phone company, and you >actually understood... You gotta be kidding. The whole corporate culture in telcos is built around single-digit growth rates, when next year's provisioning is done by tweaking previous year's figures, and being a droid is rewarded, while doing something new is regarded as pain in the neck. >So we've got routing problems front and center, here and there, with >bandwidth problems creeping up behind. We've got some companies with >relatively deep pockets, or which are flush with IPO money, which would >very probably spend to fix it if they could, if only to avoid being >featured on the 10 o'clock news when disasters occur, except there doesn't >seem to be anything to spend the money on which is clearly going to fix >anything. Tried to find venture capital for a backbone router company recently? On reasonable terms? There is hardware which physically can route *terabits per second*. It is there. It is real wires and real silicon, not fancy projects. The problem is that there are very few people with a clue on how to make the router software for the boxes, and the management is intent on blessing Americans by saving them trip to the next corner's Blockbuster. No, popcorn on demand is not provided, so you still have to haul your <optional obscenity> off the couch. >I don't think this is a happy state to be in, in fact it sucks, >but I don't think it is correct to attribute this state to counter-productive >profit motives. Never attribute to maliciousness that which could adequately be explained by stupidity. >I think we're victims of our having own success creep up >to and pass the technology when we weren't paying close enough attention, >and the only thing left to do seems to be to try to play catch-up from >a position of increasing disadvantage. No. The screaming about traffic explosion was high for the last few years, and it generally fell on deaf ears. There's a perception among those who has the money that ATM will come and fix everything by magic, so there's no point in building routers. Maybe that's our fault that we allowed the charlatans to push their snake oil to those who don't know better. My personal course in that is to keep playing with my toys and wait till the fun begins. Shouldn't be long. The worse, the better. --vadim (NOT a Sprint employee, just using old mailbox).

1 0

Re: links on the blink (fwd)
by Steven J. Richardson 08 Nov '95

08 Nov '95

Curtis: I was referring to when Merit had the NSFNET NOC...! ;-) Of course you are correct; if you observe the links over a long enough time, you will see loss. I hope that the orders of magnitude between 10% loss and 1E-4/1E-5 make an impression on persons saying that the first number is acceptable. I'm also glad to hear that MCI has continued its vigilance; they were always very ready to look into problems which we reported, run diagnostics with us, etc. Steve R. === >From list-admin(a)merit.edu Tue Nov 7 00:08:47 1995 >Message-Id: <199511070414.XAA17732(a)brookfield.ans.net> >To: "Steven J. Richardson" <sjr(a)merit.edu> >cc: hwb(a)upeksa.sdsc.edu, michael(a)memra.com, D.Mills(a)cs.ucl.ac.uk, > mn(a)tremere.ios.com, nanog(a)merit.edu, nathan(a)netrail.net >Reply-To: curtis(a)ans.net >Subject: Re: links on the blink (fwd) >In-reply-to: Your message of "Mon, 06 Nov 1995 15:18:15 EST." > <199511062018.PAA08597(a)home.merit.edu> >Date: Mon, 06 Nov 1995 23:14:45 -0500 >From: Curtis Villamizar <curtis(a)ans.net> >Status: R >Steve, > >Enough of your wild stories of -0%- loss. :-) The correct figure was >10^-5 for acceptance with 10^-4 being the maximum threshold we would >accept on a running circuit before contacting MCI to take the circuit >in a maintenance window for diagnostics. That doesn't mean we >wouldn't bug MCI to get the circuits back perfectly clean. ;-) > >We still have the same criteria. I think MCInet is also as vigilant. > >Curtis

4 4