- NANOG - lists.nanog.org

RE: [off topic]Re: NANOG costs
by Randy Neals 11 Apr '02

11 Apr '02

Howard C. Berkowitz said, >Chinese poutine. The mind reels. Wrong Province, but not so far off really..... While your eating your imported poutine you can visit the Feng Shui Research Center around the corner from the Hotel on West Beaver Creek. -R

2 1

Re: Shielded Cat-5E Ground Loop - Myth or Reality?
by Peter J. Cherny 11 Apr '02

11 Apr '02

At 17:43 10/04/02 +0000, chris(a)neitzert.com wrote: >I'm in the process of managing cabling for a large install (500-ish runs) >and a vendor came to me with a story about the creation of ground loops in >running sheilded+gounded cat-5e in large installations. > ... A perspective from the audio/video world ... ... we tie shields down at BOTH ends to the local mass/frame ground, the price paid for this can be LARGE currents flowing in the braids. This is BAD(tm) because no matter how good the common mode rejection is, there is always enough un-balance to inject noise. It's also rather dangerous to man and machine. The remedies are designed at an overall system level. Firstly a radial earth scheme is employed (referencing to an equi-potential point). This works well within an installation, but is a little cumbersome across larger distances where hum-bucking hardware (transformers et al) are used. Secondly "sacrificial earths" are used to cope with those circulating currents that just can't be avoided, i.e. we place highly over-dimensioned cables electrically in parallel with the bundles of individually shielded pairs, but locate the run away from where the fields can impact cables carrying signals. In summary, STP earthing is tricky and needs to be considered in conjunction with the overall earthing scheme in the installation, but not tying down both ends is an unacceptable and unsafe practice. p.s. there are a number of other issues relating to the Electrical Safety Standards and Safety Earths that have to be fed into the mix.

1 0

Re: Sheilded Cat-5E Ground Loop - Myth or Reality?
by Mr. James W. Laferriere 10 Apr '02

10 Apr '02

On Wed, 10 Apr 2002, David Schwartz wrote: > On Wed, 10 Apr 2002 18:17:01 -0400 (EDT), David Lesher wrote: > >If you use that sand-based media instead of the copper; > >you'll avoid LOTS of issues -- ground loops, induced noise, > >corrosion resistance, etc... > >Fiber Is Your Friend. > You do have to worry about shark attack though. Hmmm , Flying sharks ;-) . JimL +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr(a)baby-dragons.com | Coudersport PA 16915 | only on AXP | +------------------------------------------------------------------+

1 0

RE: NANOG costs
by Randy Neals 10 Apr '02

10 Apr '02

The good news is that the Hotel costs in Richmond Hill are considerably less than past venues. And, the exchange rate is currently USD$1 to about CAD$1.60, And, the beer has more alcohol content. If your really trying to save money fly to Buffalo on Jet Blue, rent a car, and drive to Toronto. It's a 1-2 hr drive and you can visit Niagara Falls. Sheraton Standard Room Rate: $149 CDN (approx. $95 USD) Sheraton Deluxe Jacuzzi Room Rate: $169 CDN (approx. $107 USD) Best Western Standard Room Rate: $109 CDN (approx. $70 USD) -Randy -----Original Message----- From: Susan Harris [mailto:srh@merit.edu] Sent: April 10, 2002 5:50 PM To: Richard A Steenbergen Cc: NANOG Subject: Re: NANOG costs > Unless of course, they'd like to give discounts for people who have > attended many past NANOGs are who are now unemployeed. :) Unfortunately discounts just aren't feasible - there'd be administrative problems and questions of fairness to other attendees (and to Merit, since our per-attendee costs wouldn't change.) Plus, we're not sure it would solve the problem, considering everyone's high travel and hotel costs. There's always multicast and RealAudio ...

2 1

why buffering?
by Vadim Antonov 10 Apr '02

10 Apr '02

Well, so far nobody provided a valid explanation for the necessity of buffering in routers (and any other stochastically multiplexing devices). The real reason for having buffers is the fact that information about congestions takes some time to propagate. (In TCP/IP congestion are detected by seeing lost packets). If buffers are not sufficient to hold packets until TCP speakers see congestion and slow down, the system becomes unstable. Buffers are, essentially, inertial elements in the delayed negative-feedback control loop. Insufficient inertia causes oscillations in such systems, which is sometimes useful, but in case of networks leads to decreased througoutput because the wire is utilized fully only at upswings and underutilized on downswings (collapsed TCP windows aggravate the effect futher). Consequently, the holding capacity of buffers should be sufficient to bring the inertia of the system up to the reaction time of the negative feedback (this is a simplification, of course). This reaction time is about one round-trip time for end-to-end packets. In real networks, the RTTs differ for different paths, so some "characteristic" RTT is used. So, to hold packets until TCPs slow down a router needs cRTT * BW bits of buffer memory (where BW is the speed of the interface). This rule can be somewhat relaxed if congestion control loop is engaged proactively before congestion occured (by using Random Early Detection), but not much. Even with properly sized buffers, sessions with longer RTTs suffer from congestions disproportionately because TCPs on the ends never get enough time to recover fully (i.e. to bring windows to large enough size to maintain steady stream of packets), while small-RTT sessions recover quickly, and, therefore, get bigger share of bandwidth. But I'm digressing :) --vadim

1 0

OT? cRTP header compression
by Thomas Kernen 10 Apr '02

10 Apr '02

I'm looking for real world experience related to deploying cRTP header compression on Cisco routers related to VoIP flows. We are trying to evalute what type of hardware (ie: CPU power since cRTP is CEF switched since 12.2x IIRC) is required to handle 96/192/384 VoIP calls over a single circuit (HDLC/PPP/FR). This is related to specific overseas circuits where the cost of the circuit is still very expensive vs the cost for the extra hardware to handle the header compression. I'm disregarding all QoS info at this stage. Cheers Thomas

1 0

Re: NANOG costs
by Ukyo Kuonji 10 Apr '02

10 Apr '02

>From Nanog web site: "Waiving the Registration Fee The NANOG registration fee is waived for: Speakers Employees of the hosting organization who are actively involved in meeting setup Full-time students in the local hosting city with current ID. The fee for all other full-time students is $100. Beer 'n Gear sponsors: up to two vendor engineering staff available to answer attendee questions about the vendor's products. NANOG staff " >Date: Wed, 10 Apr 2002 11:03:28 -0700 >From: Doug Clements <dsclements(a)linkline.com> >To: nanog(a)merit.edu >Subject: Re: NANOG costs > > >Woah, students get a reduced fee? Where do I sign up? I looked and looked >for something like this, but I've ended up paying full price for the last 2 >NANOGs. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

1 0

Re: NANOG costs
by Ukyo Kuonji 10 Apr '02

10 Apr '02

I could have sworn that I looked this question up on Nanog's web page a year ago, but I couldn't find it there. The cost of the conference goes to a number of things: 1) 14 people on the Merit staff are involved in organizing the conference. I am sure that some of the monies goes to paying expenses they incur setting it up, if not to help offset their salaries for the time they spend. 2) Insurance - I am sure that merit and nanog have to cover some sort of insurance to cover damage caused by attendees of the conferences. 3) Misc expenses not covered by the host of vendors. Also, you must realize that not everyone gets hit with the $300 charge. Hosts and presenters get free admission, and students get a greatly reduced fee. As other people say, this is probably the best value for your money of anything else. You get to hear what is going on, you get to put faces to names (and voices), and you get to talk shop with others in your field without all the "business" people around saying what you can and can't say. >Date: Tue, 9 Apr 2002 19:48:58 -0700 (PDT) >From: Paul Revere <mr_paul_revere(a)yahoo.com> >To: nanog(a)merit.edu >Subject: NANOG costs > > >We used to pay $150 or so to attend NANOG conferences. > Why are we charged $300 now? Where is our $150,000+ >going? > >Inflation? > >Are we paying for the salaries and RIPE attendance of >MERIT employees, and to what tune? > >Conference space is free or greatly subsidized in >return for room blocks. Connectivity, terminal rooms >(who uses those anyway?), operational support, and >hardware are all no-cost items to MERIT. > >Continental breakfast costs $8k to sponsor. Morning >or afternoon break costs $6k. Lunch or dinner, $18k. > Beer and Gear is $6k per vendor, and has been booked >solid for the last ten NANOG conferences. That's a >lot of money right there. > >So what are we actually paying for, the t-shirts? Are >we subsidizing other MERIT money losers? > >With IT and engineering budgets shrinking, and >unemployment on the rise, should MERIT be obligated to > share with us a more detailed financial accounting, >or is this none of our business? _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

2 1

Re: packet reordering at exchange points
by Paul Vixie 10 Apr '02

10 Apr '02

> Routers are not non-blocking devices. When an output port is blocked, > packets going to that port must be either buffered or dropped. While it's > obviously possible to drop them, like ATM/FR carriers do, ISPs have found > they have much happier customers when they do a reasonable amount of > buffering. the important thing to remember about bits per second (or packets per second or anything else per second) is that it's not particularly granular compared to modern link speeds. if at the nanosecond when a packet has finished arriving (assuming that we're not doing cut-through, which is a good assumption in the case of routers) the selected output interface is still busy clocking out another packet, that by itself does not indicate "congestion". it might be that way way later on, like at the end of the current second, that only 1% of the link output space was filled. packet arrival times aren't fractal, or anything like fractal. so we buffer. and because we measure "bits per second" we like to have enough buffering to handle a output pipe worth of inconveniently-timed output events. if the inconveniently-timed packet arrival times are such that more of them arrive than could fit the pipeline between this router and the next one down the line, then we need to (passively) signal the sender that they are trying to put 11 gallons of gasoline into a 10 gallon hat. so we drop in that case. (smd, didn't you write this up for nanog several years ago? encore? encore?)

1 0

RE: [Q] BGP filtering policies
by LeBlanc, Jason 10 Apr '02

10 Apr '02

With enough badgering most providers will accept a /24 announcement of PA space. Exodus is the an exception, using their IP space is nightmarish. -----Original Message----- From: Borchers, Mark [mailto:mborchers@splitrock.net] Sent: Tuesday, April 09, 2002 12:35 PM To: 'nanog(a)merit.edu' Subject: RE: [Q] BGP filtering policies If you'll look at this pointer to one of ARIN's pages, it lists the minimum allocation size for each CIDR block that IANA has given ARIN to manage. From what I've seen, most providers accept at least up to the prefix length that the RIR's are using, if not longer. http://www.arin.net/statistics/index.html#ipv4issued2002 Unfortunately, this doesn't help in your case. My company also has /14's from the traditional class A space. I know of only one case in two years where a customer reported a problem arising from holding a small assignment out of these blocks, which was ultimately corrected by renumbering the customer, a solution which does not scale well. Worst case, however, unless your UUNet connection goes down, you'll still be able to reach most places via your other transit and peering (since /24 is the closest thing to a "universal" allowed prefix length) and will have full reachability via UUNet. IMHO, accepting up to /24 in any of the space listed on the above URL is good service provider practice. > -----Original Message----- > From: Henry Yen [mailto:henry@AegisInfoSys.com] > Sent: Tuesday, April 09, 2002 2:11 PM > To: nanog(a)merit.edu > Subject: [Q] BGP filtering policies > > > > We were recently assigned a /22 from UUNet in conjunction with some > transit we're buying from them. The space is inside their superblock, > 65.242.0.0/14. We are concerned that our route announcement of this > block would be filtered out by some other providers, as it's not > class C/swamp space (or even class B space for that matter). > Verio's current policy, for one, indicates that this would be so. > > This is of particular concern to us as our little network encompasses > several physical partially-meshed locations, with a mix of varying > bandwidths both upstream as well as intra-location. Traffic > Engineering > is what we think is a reasonable (business) approach to address our > flexibility needs, and so we're trying to move to address > space(s) that > would be least likely to be BGP filtered. > > We've asked for a different block from UUNet but the request didn't > meet with success; UUNet suggested that any problems encountered > as a result of this allocation could probably solved by e-mailing > any NSP whose traffic interchange with us might be negatively > affected (unlikely, to be sure, but still...), and would then > change their filter (I'm unconvinced of this scenario). > > I briefly browsed the NANOG archives, and didn't see this > issue discussed > recently. Have the BGP filtering policies for "most" ISP/NSP's been > relaxed to the level of "accept /24's from class A > (ARIN-allocated) space"? > Am I mis-reading Verio's posted policy? Is there anyone from UUNet > who might choose to comment? Is there something else I'm > misunderstanding? > > -- > Henry Yen Aegis > Information Systems, Inc. > Senior Systems Programmer Hicksville, New York >

5 4