- Test - lists.nanog.org

RE: QOS or more bandwidth
by Kavi, Prabhu 29 May '01

29 May '01

There is definitely a break-point for when QoS (or even a single component of QoS like traffic engineering) makes sense. Someone asked earlier in this thread if it was cheaper to add capacity or pay for the bright engineers to make TE or QoS work. For large carriers, the right answer is often to pay for the bright engineers. I did some traffic engineering work for a major IP carrier a few years ago. The cost savings from traffic engineering at the time more than paid for the cost of the quality engineers they had. Of course, the same amount of bandwidth they had then would now cost much less, and be considered a small network, and the results today could well be different. Prabhu ---------------------------------------------------------------------- Prabhu Kavi Phone: 1-978-264-4900 x125 Director, Adv. Prod. Planning Fax: 1-978-264-0671 Tenor Networks Email: prabhu_kavi(a)tenornetworks.com 100 Nagog Park WWW: www.tenornetworks.com Acton, MA 01720 > -----Original Message----- > From: RJ Atkinson [mailto:rja@inet.org] > Sent: Tuesday, May 29, 2001 1:22 PM > To: nanog(a)merit.edu > Subject: RE: QOS or more bandwidth > > > > At 10:15 29/05/01, Irwin Lazar wrote: > > >FWIW, I recently heard someone ask the question - "how do > you go to your > >investors and tell them you need more money for more > bandwidth because you > >don't want to efficiently manage your existing capacity?" > > > >This is the business case for QoS, IMHO. > > Whenever I did the cost of deploying and managing fancy QoS > and compared it with the cost of getting and managing more capacity, > it was always MUCH MUCH cheaper to get and manage more capacity > than to mess with more QoS. > > Other folks mileage might vary. I'd encourage folks in > that situation to fire up a spreadsheet and do the math. The > critical variable in my cases was accounting properly for the > increased ongoing operational costs of maintaining a QoS-enabled > network. Those turned out to be quite high. > > Ran > rja(a)inet.org > >

1 0

Frame-relay outage: Nolo Contendere
by Sean Donelan 29 May '01

29 May '01

Intersting cover letter included with SBC's FCC Outage report on Friday's frame-relay problems in California and Nevada. "Attached please find an Initial Service Disruption Report by SBC Advanced Solutions, Inc (SBC-ASI) This report is submitted on an informational basis, and without admission that the provisions of 47 CFR 63.100 are appliaable to SBC-ASI or to the services provided by SBC-ASI." http://www.fcc.gov/Bureaus/Engineering_Technology/Filings/Network_Outage/20… I note that both Worldcom and AT&T filed FCC initial outage reports about their frame-relay and ATM network problems, and final outage reports without such words in their cover letter.

3 2

Re: QOS or more bandwidth
by smd＠clock.org 29 May '01

29 May '01

"E.B. Dreger" <eddy+public+spam(a)noc.everquick.net> asks: | Although I generally agree, how does one keep QoS out of the core for CBR | and jitter-sensitive applications? Magic technology called SONET. In general, applications that really need CBR/ultra-low-jitter should stay on TDM, because it's the cheapest approach. Meanwhile applications which can benefit from the statistical multiplexing gain of the imperfect Internet (with occasional bursty loss and jitter) can migrate over to cheaper IP based networks. There are probably not very many applications which really need CBR/ultra-low-jitter: most that use TDM networks today work reasonably well across today's imperfect Internet with no QoS assistance whatsoever. As to the core: if there's no queue, there's no opportunity for (work conserving) fancy queueing. Does it pay to do work non-conserving fancy queueing? Does it pay to do fancy queueing on transients? Obviously if you don't, you can't perfectly simulate a TDM-based network, and thus can only make statistical promises about bit rate and jitter. I believe that for perfection it's cheaper to maintain a real TDM network than it is to use fancy queueing and fancier signalling to avoid and manage transient congestion in an IP based one. Sean.

2 1

Re: port filtering list
by chrisb＠kippona.com 29 May '01

29 May '01

From: "Avleen Vig" <avleen(a)ivision.co.uk> > >> Does anyone keep track of packet filtering based on destination >> port, of the form: >> >> provider ports action >> ------------------------------------------------ >> uu.net 25 drops all outbound >> <another>.net 25,465,587 drops all outbound >> aol.com ?? ?? >> msn.net ?? ?? >> earthlink.net ?? ?? >> demon.co.uk ?? ?? >> ... ... ... >> >> More and more users want to roam and knowing this info ahead of >> time helps. > >Not as far as I know >do you want to? I'll get one started. Chris

2 2

Re: last mile capacity [was Re: QOS or more bandwidth]
by smd＠clock.org 29 May '01

29 May '01

someone asked: | Wouldn't that tend to lead to problems wrt maintenance and capacity | issues? I mean, we know how well our local governments work. This just | seems to me that it would tend to have capacity continuously at 95% | and brokn fibers taking weeks to repair. Stokab and its kind work about as well as the water and gas utilities. You can get two diversely routed dark fibre pairs between a pair of locations in Stockholm for about the same price as a 128kbps protected leased line. How would _you_ deal with potentially long outages? (See http://www.stokab.se/english/ under "products"). Sean. P.S.: Capacity issues? They sell _dark fibre_. That's TERAbits per second, per pair, if you want...

2 1

Re: More BW, Less Taxes
by smd＠clock.org 29 May '01

29 May '01

| It might make more sense to ask "Why is bandwidth so cheap (and getting | cheaper so fast) in the US?" The simple answer is: Moore's law, competition | (leading to a "fiber glut") and economies of scale. ignoring detours into the land of atm/fr/x25/etc-under-IP: 1. ripping out t1 channel banks and using t1s directly for ip 2. ripping out m13 muxes and using t3s directly for ip 3. ripping out all sorts of weird t3 gear and using sonet (oc3->oc48) direclty for ip 4. ripping out sonet gear and using sonet-framing between unsynchronized pairs of routers over wdm systems built with sonet in mind this has made things cheaper and easier to manage over time, so the cost of supplying each chunk of 64kbps has gotten cheaper over time. result: fewer $ per mbps of p2p bandwidth for router connections. note that long haul individual DS0s are really not that much cheaper now than they were a few years ago. on the ip side, in a vendor-specific timeline ordering: 1. better forwarding algorithms ('fast switching') 2. multi-chip specialized forwarding engines 3. aggregation 4. "subnet of small routers" linecard+backplane model of distributed forwarding 5. specialized silicon getting cheaper (this is your "Moore's law" comment) on the "fibre glut" front there are parallel evolutions: I. fibre-based networks constructed for inhouse bell-head-apps II. "patchy" builds mitigated by cross-selling/leasing arrangements III. more companies lighting up "patchy" regional networks IV. pipeline and other right-of-way companies turning on sizable "patchy" nets V. companies which "exist to dig" - developments in fast-digging, etc. many of II-V sell/sold towards the original I companies, as well as startup plays who do bell-head or even Internet focused optical subnets. and perhaps even more importantly, in parallel: 1. WDM 2. DWDM 3. EDFA, Raman etc. 4. Ultra-long-haul optics with tight filters which competes with the "more fibre" approach as more bandwidth is required. | If you're across an ocean from the US, you have to factor in the cost of | running underwater cable. Having done this, I can say that in general the tricky part is mostly on land, and in the selection of not-so-bell-head-focused equipment & contractors. Thanks to points 3 and 4 in the last set (optical stuff) above, the wet pieces in future fibre builds aren't really much more than strings of glass that adapt reasonably well to bending and sharkbite. Digging is probably the expensive piece in future, followed by paying off the the people who can charge you for the use of the land you're dropping stuff into. Sean.

1 0

Re: More BW, Less Taxes
by smd＠clock.org 29 May '01

29 May '01

Simon Lockhart <simonl(a)rd.bbc.co.uk> | In Europe [bandwith is] becoming cheaper too - especially to major cities. You're welcome. Sean. - -- aka Sean Doran <smd(a)ebone.net> PS - The "gigantic plunge" in pricing was triggered by Dave Morton, who, acting with what was then Ebone, negotiated a city-to-city PDH E3 for approximately 10% of the prices on offer from the PTTs. This particular circuit set a benchmark that terrorized the industry in advance of further trans-border deregulation (wisely) promoted by the Commission of the European Union. Previous efforts led by Peter Lothberg, Dave, Stefan Westman and many other former Ebone board and consortium members led to dramatic discounts against PTT 1/2-circuit pricing, and of course, companies like Hermes Europe Railtel (now part of Ebone) also stepped into the market with deep discounts against the traditional telco models of international/intercity pricing. This does not exactly help the North Americans, but to make it NANOG-relevant, there are certainly some things that the NA regulators and consumers of bandwidth can learn from Europe, just as Europeans have learned from successes and failures in earlier large-IP-backbone construction in NA. First and foremost is that "creative destruction" works very well at reducing prices in practise, and incrementalism does not. Service performance itself remains essentially unchanged either way. QoS therefore is a solution to a non-problem (maintaining service levels), and is moreover a contributor to incrementalist thinking.

1 0

RE: QOS or more bandwidth
by Ukyo Kuonji 29 May '01

29 May '01

--- Sean Doran Wrote --- >In the absence of such a document, from which anyone can build >an interoperable "true" "end to end" QoS system into his or her >product, I am tempted to believe that such buzzwords are weapons >in a DoS attack by marketroids. Yeah, I have to agree with you there. I have long been of the opinion that all these are spouted off by marketing types and ATM biggots. As far as I am concerned, a properly designed and run network makes QoS and MPLS more a hassle than a benefit. >TDM. What flavour would you like? SONET/SDH? PDH? "Virtual >dark >fibre"? >ITU-Grid optics? That works very well for always on type service, but in reality, these type of services are not always on. They are periodic, at best, and the time between the periods can be hours to days. Right now they ARE over TDM, but TDM is expensive to supply (payback time and all). Data services (ATM or IP) has a much better payback time. And if you can get the stat mux gain, all the better. Of course, the prices to the customer makes TDM more attractive. (Something wrong with this picture?) >If you're not sure that it'll be worth anything on arrival, >you shouldn't send in the first place. Well, in a voice call, if a packet is out of order, you want to drop it. Same with broadcast video. There is no need to try to pick up that bit. This is real voice and video, not talking about stuff you get with quicktime... >These are all travelling across multiple-provider paths today... Not IP paths. At least not that anyone has pointed out to me. >The latter distributes the problem better. The former requires >well-adapting, well-behaved, Internet-ready apps to subsidize the >migration of apps which are not all of these, and that will not fly. > >(Note that even the poor CoS substitute is unnecessary for current >well-adapting, well-behaved, Internet-ready apps... that's one reason >they're so inexpensive.) Again, I agree totally with you. Get teh apps in shape, and all will be good. UK --- Opinions in this email are the personal opinions of the author and are not associated with author's employer. This email account is a not the regular email account of the author and is being used for the protection of the employer. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

2 1

nanog-digest
by Sue Joiner 29 May '01

29 May '01

Hi, Over the weekend Merit moved the nanog and nanog-digest lists to a new server. During the process there was a glitch with the nanog and nanog-digest lists. Because of this some of you may have received the nanog-digest message by mistake. The problem has been fixed and you should not receive any more digests. Sorry for the confusion and inconvenience. -sue -- Sue Joiner Merit Network, Inc.

1 0

RE: Tucows/OpenSRS Down
by Roeland Meyer 29 May '01

29 May '01

> From: Seth M. Kusiak [mailto:seth.kusiak@yours4less.com] > Sent: Tuesday, May 29, 2001 8:05 AM > > It appears that Tucows/OpenSRS is down and service should be > restored by > 1:00 PM EST today. > > Does anyone know what happened and why there is no > announcement on the ICANN > website? ICANN does not consider operations issues pertinent. It is a policy org. ICANN does not have clue.

1 0