May 2001 - Test - lists.nanog.org

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

29 May '01

> -----Original Message----- > From: smd(a)clock.org [mailto:smd@clock.org] > |Prabhu Kavi writes: > | 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. > > Admittedly I have strong biases, but the engineers that I think > are bright will tell large carriers that the right answer is to > spend money on more capacity. > Sounds like we know different sets of bright engineers. My biases are that I worked for a Layer 2 switch vendor at the time, and our IP customers were primarily large ISPs. > What "we" believed in 1995-1997 about ATM cell tax and the like > is no longer valid. Neither is what "they" believed about traffic > management. ATM is a tool. Some carriers used this tool in 95-97 for line-rate OC-12 forwarding and TE. Line-rate forwarding at OC-48+ rates is no longer an issue, and TE is available with MPLS, so ATM is not a very useful for IP traffic these days. However, TE is still a necessary tool for some carriers because "they" know it makes better financial sense for them than adding bandwidth. Your mileage may vary. 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

1 0

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

29 May '01

Prabhu Kavi writes: | 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. Admittedly I have strong biases, but the engineers that I think are bright will tell large carriers that the right answer is to spend money on more capacity. They are also the people _least_ likely to be impressed by money as the currency "to pay for" them. Being taken seriously despite having very non-bell-head ideas, and having an environment in which traditional thinking does not win every argument, is usually much more important. I've done some non-TE work for a couple of networks, and the only bandwidth-constraint they have run into on the technical front has been switching capacity of routers. Yeah, you sometimes have to fight to "remove" fun features like 1+1 protection and monitoring, but this can be done even in the most traditional of telcos, as demonstrated by various people over the years. | 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. In my necks of the woods the retail pricing of international TDM (PDH, SDH, WDM) capacity eroded something like this: 1993 - T1 capacity, 9-12 cents/channel-mile 1994 - T3 capacity, 6-9 cents/channel-mile 1995 - OC3 capacity, 3-4 cents/channel-mile 1997 - (intl) E3/T3, midpoint, $4M (US) we don't count in channel-miles ... 2001 - $4M (US) gets you a multi-city optical subnet at 2.5Gbps What "we" believed in 1995-1997 about ATM cell tax and the like is no longer valid. Neither is what "they" believed about traffic management. | 100 Nagog Park WWW: www.tenornetworks.com Wow I misread this street address several times... lysdexia, I guess. Sean.

1 0

Re: last mile capacity [was Re: QOS or more bandwidth]
by Sean Donelan 29 May '01

29 May '01

On Tue, 29 May 2001, Sean M. Doran wrote: > The correct way of solving this was demonstrated in Stockholm > and duplicated in a handful of Canadian cities. In the first case, > the City of Stockholm "nationalized" the laying down of dark fibre > in the city, and formed an agency (http://www.stokab.se/english/) which > provides unlit/unrepeated/unamplified dark fibre between any pair > of addresses in Stockholm at cost as a public utility. On the other hand, Palo Alto California demonstrates the folly of relying on government to lay fiber optic pipes.

2 1

RE: QOS or more bandwidth
by Spencer.Wood＠dot.state.oh.us 29 May '01

29 May '01

We have done some testing of VoIP across a 802.11b wireless connection, and it appears to be pretty decent, but it really depends on the quantity of the wireless connection. The biggest problem we have run across is jitter... Spencer **************************************************** Spencer Wood, Network Administrator Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: Spencer.Wood(a)dot.state.oh.us Phone: 614.644.5422/Fax: 815.361.0714 **************************************************** Eric Whitehill <eric(a)botbay.net> Sent by: owner-nanog(a)merit.edu 05/29/2001 01:42 PM To: Bill Woodcock <woody(a)zocalo.net> cc: RJ Atkinson <rja(a)inet.org>, <nanog(a)merit.edu> Subject: RE: QOS or more bandwidth I know of someone who is trying to do a VOIP system over a wireless network - they are having limited success, but when they did some packet switching magic, it seemed to help some, but last I checked they are still having issues with it dropping calls and the phone system constantly resetting. Is VOIP really ready for such practices as to allow business to totally rely on VOIP in this matter? ok ok a little off topic ;-) -Eric On Tue, 29 May 2001, Bill Woodcock wrote: > Date: Tue, 29 May 2001 10:34:09 -0700 (PDT) > From: Bill Woodcock <woody(a)zocalo.net> > To: RJ Atkinson <rja(a)inet.org> > Cc: nanog(a)merit.edu > Subject: RE: QOS or more bandwidth > > > > 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. > > We did one VoIP network deployment, and I tried each of the different QoS > services in IOS at that time (about 18 months ago) both in the lab and in > the field, and more bandwidth was the answer then. > > -Bill > > >

1 0

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

29 May '01

Irwin Lazar <ILazar(a)tbg.com> writes | In our | area, we're also seeing a lot of pushback against the continued tearing up | of streets to lay additional fiber, so QoS may become the only option to | meet required service levels. The correct way of solving this was demonstrated in Stockholm and duplicated in a handful of Canadian cities. In the first case, the City of Stockholm "nationalized" the laying down of dark fibre in the city, and formed an agency (http://www.stokab.se/english/) which provides unlit/unrepeated/unamplified dark fibre between any pair of addresses in Stockholm at cost as a public utility. Thus, instead of a dozen or so CLEC-style companies ripping up the same set of streets, Stokab does it approximately once, and provides fibre pairs as necessary to these companies, and any other buyers who come along (lots of corporate buyers use Stokab instead of the traditional telcos or CLECs). This approach has been an unqualified success for Stockholm, which thanks in large part to Stokab's establishment in 1994, has been *the* intersting place to do Internet stuff through most of the years since then, despite the city's geographical remoteness and small population. The major drawback of existing dark fibre utility agencies is their management's tendency to try to be innovative - Stokab for example sometimes appears (misguidedly!) to want to move up the value chain into services their buyers are offering, and into new experimental things involving media other than fibre (e.g. radio). If a single "nationalized" supplier of dark fibre slows down or becomes more expensive as a result of this, it will cease to be a market-enabling success, and start to look like the sort of constraint on the last-mile market that former PTTs are imposing on their captive market. (And then yeah you're back to digging up more streets or using QoS or whatever, sigh.) So, a good idea is to press your local government into duplicating Stokab (it really IS good for you), but stop your local equivalent from ever hiring someone with a bell-shaped-head or technology fetish. Sean.

4 3

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