- Test - lists.nanog.org

Re: Bell vs. Internet Providers (fwd)
by kai＠netcom.com 10 Nov '95

10 Nov '95

The question is where are the real costs of a local phone call? Are they in the call setup? Are they in the length of time for the call? Some combination? What switch resources need to be expanded to deal with long holding time calls? What switch resources can be reduced if you need to process fewer call setups? It is possible that modem calls are a bad deal for phone companies, but it is also possible they are a good deal. Does anyone really know? -Jeff Ogden Merit This is classic traffic engineering. The cost of providing service is almost exclusively governed by capacity size, and that is chosen following a sole parameter: peak usage. You never ever want to run out of local switch trunks for local calls: modern switch matrixes can interconnect 50% of all lines internally, interconnecting trunks to other switches can handle maybe 20% of line capacity. Traffic patterns show that peak usage is during business hours, with call volume (lines engaged) being 3-4 times the average of after-hour use. There is no telco in the world, that can show me they are being ripped off by the growing number of modem users, this is really just another case of 'cashing in on the super information highway' . The few people who stay on 24 hours are an EXCEPTION, not a rule, and in most cases such people have several phone lines in their home (I have 3, one is on 24 hours , hence on average I don't use my phone lines more than 33% of all times, as the other lines are seldomly in use: the phone co. is cashing in by selling me three lines !). Also: there are many people who get second phone lines exclusively for modem use now, hence a single modem line an ISP has installed might create an additional 2-3 lines with residential customers. Did you ever hear the phone co. complaining about too many residential (or other) phone lines ? All Nynex whines of how residential service would really cost them much more than the customer is actually paying aside: this must be one of the really dirty secrets of the RBOCS. Short: off-peak usage of telco facilities is not costing the telco any real money, (this is especially true for LD companies!) as the capacity planning (and purchase) is governed by peak usage, any screams by them in that general direction should be ignored, their monopolistic actions fought with a vengeance: EdTel of Edmonton,Alberta started making noises as described no sooner than they were beginning to plan their own internet service. I hear they have a special tariff discount for fax lines (business or residential) too, or at least used to. Are they talking with two tounges ? bye,Kai

1 0

Re: Bell vs. Internet Providers (fwd)
by Scott Mace 10 Nov '95

10 Nov '95

> > > 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. > > What does that have to do with anything? The T1 still drops into a phone > switch and uses up channels. T1's are designed to stay up all the time, and centrex lines aren't. It doesn't really solve the capacity problem, but when Bell sells a T1 they sell it with the full knowledge that the line will be using all channels all the time (unless its a frac T). From what I read, the major concern was problems in planning for switch capacity. Bell really doesn't have a way of knowing that the Centrex lines they just sold to a company (that just happens to be an ISP) are going to be up all the time. This would not be the case if the information collected from the Bell sales rep filters all the way to the people doing the planning (which I doubt it does). I can see Bell charging more for a Centrex line, but I can't see Bell charging more for a T1 or T3 _just_ because an ISP is using it. Scott

2 1

Bell vs. Internet Providers (fwd)
by Paul Ferguson 10 Nov '95

10 Nov '95

>From the 'For What Its Worth' Department. - paul BELL VS. INTERNET PROVIDERS Bell Canada plants to increase line rate charges for Internet service providers by as much as 400%, saying the higher charge is necessary because those providers use lines for 55 to 60 minutes every hour compared with voice usage on a Centrex line of about 10 minutes. The service providers say the move aims to eliminate competition for Bell when it introduces its Worldlinx Internet access by the end of this year. (Montreal Gazette 9 Nov 95 D7) ***************************************************************** Edupage, 9 Nov 95. Edupage, a summary of news items on information technology, is provided three times each week as a service by Educom, a Washington, D.C.-based consortium of leading colleges and universities seeking to transform education through the use of information technology. *****************************************************************

7 6

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