May 2001 - Test - lists.nanog.org

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

RE: NANOG Digest V1 #737
by Roeland Meyer 29 May '01

29 May '01

I got one too...same conditions ... no action on my part. > -----Original Message----- > From: Kai Schlichting [mailto:kai@pac-rim.net] > Sent: Tuesday, May 29, 2001 8:02 AM > To: nanog(a)merit.edu > Subject: Re: NANOG Digest V1 #737 > > > > Hmm, is this just me, or did someone else start receiving the > digest version this morning,too - without any action on his/her own? > Simultaneously, I receive the regular (non-digest) list mail > as well. Both come from the same host (trapdoor.merit.edu) > > > > Received: from trapdoor.merit.edu > (postfix(a)trapdoor.merit.edu [198.108.1.26]) > > by conti.nu (8.9.3/8.9.3) with ESMTP id GAA06067 > > for <kai(a)pac-rim.net>; Tue, 29 May 2001 06:35:35 -0400 (EDT) > > Received-Date: Tue, 29 May 2001 06:35:35 -0400 (EDT) > > Received: by trapdoor.merit.edu (Postfix) > > id 227A291218; Tue, 29 May 2001 06:28:57 -0400 (EDT) > > Delivered-To: nanog-digest-outgoing(a)trapdoor.merit.edu > > Received: by trapdoor.merit.edu (Postfix, from userid 56) > > id B735C91217; Tue, 29 May 2001 06:28:56 -0400 (EDT) > > From: owner-nanog-digest(a)trapdoor.merit.edu (NANOG Digest) > > To: nanog-digest(a)trapdoor.merit.edu > > Subject: NANOG Digest V1 #737 > > Reply-To: > > Sender: owner-nanog-digest(a)trapdoor.merit.edu > > Errors-To: owner-nanog-digest(a)trapdoor.merit.edu > > Precedence: bulk > > Message-Id: <20010529102856.B735C91217(a)trapdoor.merit.edu> > > Date: Tue, 29 May 2001 06:28:56 -0400 (EDT) > > X-UIDL: 913bee7d2f58a5cea4042a463d2a49f6 > >

1 0

Tucows/OpenSRS Down
by Seth M. Kusiak 29 May '01

29 May '01

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? Thanks, -Seth

3 2

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

29 May '01

The problem is, while most vendors support tagging and priority queuing, non of the current vendors can support true end to end QoS. Instead, we have taken to calling their options CoS. The problem that I have seen is that while you can make certain that a good effort is made to ensure that your high proirity traffic is transmitted before your best effort traffic, you have no real way to ensure that the high priority arrives at the destination in the same manner that it was transmitted. I'm talking about packet order, jitter, and latency. Sure, it will probably get there, but will the data still be worth anything. For Internet traffic, QoS/CoS is probably not worth it, as there is no way to realistically do either across two or more network providers. The real need will be on single provider wishing to sell more than just Internet across their expensive backbone. Such applications will be Toll-quality voice, production/broadcast-quality video, VPN, etc. The way I have seen it, either IP QoS will have to become a reality, or the applications themselves will need to change to handle the poor CoS substitute that is offered now. 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. --- Original Message --- Most competitive vendors now provide native and upgrade provisions for QoS in one form or another. The problems most often encountered revolve around multi-vendor cos/qos feature implementation incompatibilities. The "least common denominator features" that are needed for basic interworking usually do not extend to 'differentiating' features that vendors like to hold close to the vest, such as prioritization and cos/qos features. Not without much grief, in any event. It forces one to seriously consider single vendor solutions. fwiw. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

2 1

QOS or more bandwidth
by Sean Donelan 29 May '01

29 May '01

While its generally more effective to add more bandwidth than rationing it with QOS, with the recent downturn in capital markets will QOS become more popular? If your budget for bandwidth has been cut, I'm not sure people will have any budget for QOS either. But what QOS features are included in the standard product offerings?

5 5

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

29 May '01

| I would disagree and argue that your core needs to be running top of the | range routers with fat pipes with spare bandwidth, for a large network if | you run out of CPU or bandwidth your routers will simply fall over. Which CPU are you worried about? My top-of-the-range routers all seem to have more than a dozen in them... The bandwidth I'm worried about right now is on the memory busses; the optical people who make things that blink lights really quickly are well ahead of IP's present needs. | (plus [QoS] will slow down the routing process). Which routing process? Assuming you mean packet forwarding will be slowed down, that really depends on architecture (more modern ones won't show a measurable slowdown, and even less modern ones don't care much about work-conserving fancy queueing - consider Villamizar's projections on SFQ vs CPU/state). Assuming you mean signalling - well - it depends on how you do it. Static support for preset "flavours" (DSCP, diff-serv code points is the jargon - sorry :) ), a small number of priority levels for WFQ or WRED, and so forth is pretty easy to set up. Reservations- based signalling (RSVP et al) is a bit harder, and also consumes more non-human resources. However, I would worry more about QoS signalling slowing down human processes, such as debugging problems and handling complexity, than I would about QoS slowing down high-end packet processing equipment. That said, since detecting blinking lighs fast enough is not presently a constraint on growth, a toolset whose principal use is combatting situations in which there is a bandwidth constraint seems more like an unnecessary frill than essential equipment. Sean.

1 0