February 2002 - Test - lists.nanog.org

Reducing Usenet Bandwidth
by Stephen J. Wilcox 04 Feb '02

04 Feb '02

Hi all, as we all know Usenet traffic is always increasing, a large number of people take full feeds which on my servers is about 35Mb of continuous bandwidth in/out. That produces about 300Gb per day of which only a small fraction ever gets downloaded. The question is, and apologies if I am behind the times, I'm not an expert on news... how is it possible to reduce bandwidth used occupied by news: a) Internally to a network If I site multiple peer servers at exchange and peering points then they all exchange traffic, all inter and intra site circuits are filled to the above 35Mb level. b) Externally such as at public peering exchange points If theres 100 networks at an exchange point and half exchange a full feed thats 35x50x2 = 3500Mb of traffic flowing across the exchange peering LAN. For the peering point question I'm thinking some kind of multicast thing, internally I've no suggestions other than perhaps only exchanging message ids between peer servers, hence giving back a partial feed to the local box's external peers. Any thoughts? TIA Steve -- Stephen J. Wilcox IP Services Manager, Opal Telecom http://www.opaltelecom.co.uk/ Tel: 0161 222 2000 Fax: 0161 222 2008

11 12

RE: SlashDot: "Comcast Gunning for NAT Users"
by JC Dill 04 Feb '02

04 Feb '02

On 01:40 PM 1/31/2002 -0500, Greg Pendergrass wrote: > >It doesn't make sense that an ISP should complain that customers use 100% of >what they pay for. So if 1% of your customers use %50+ of your bandwidth, >your 1% is getting their money's worth. If you don't want the customer to >use it, don't sell it to them. The problem is that ISPs are not configuring products that meet customer needs. What the average broadband customer WANTS is: o The highest transmission rate possible, both for uploading and downloading o A reasonable "consumption" of the above bandwidth per month, perhaps 1 GB aggregate (both directions) o For a reasonable "home user" monthly rate o With the ability to buy additional consumption at a moderate increase if their needs are higher than the typical "home user" o The ability to use NAT to have more than one home machine on the connection, so that they can share the connection among all the residents of their home But the home user broadband accounts ISPs sell are: o Accounts with tiered bandwidth pricing o No consumption cap so they limit speed instead (meeting the ISPs needs, but not the customer's needs) o Unreasonable NAT policies o Expensive upgrade paths Until ISPs start making broadband services which match end users needs these problems will continue. You can't address this with TOS policies, you have to have products that MEET your customer's needs! Web hosting providers have figured out how to make products that meet their customers needs by metering and charging for excessive bandwidth consumption, (or shutting off the site's access if it consumed the limit for the day, or the month) without throttling the site's "speed". This isn't rocket science, you just need to apply the same pricing schemes and bandwidth management systems to broadband. Instead of cutting the broadband customer off when they have used their bandwidth consumption, rate limit the connection to 14.4 so that they can still access their email and see your message telling them that they've over-consumed their bandwidth and exhausted their allotment. They can either accept the rate limited circuit until the beginning of the next cycle, or they can opt to pay extra to have a higher bandwidth consumption allotment. The only reason that broadband providers don't do this already is that there are artificial barriers to true competition. When those barriers are removed and any given broadband customer can select from dozens or hundreds of options (as is the case with website hosting), these options WILL be available and customers will opt for services that have them. jc

2 1

Re: Reducing Usenet Bandwidth
by Joe St Sauver 03 Feb '02

03 Feb '02

Hi Stephen, > as we all know Usenet traffic is always increasing, a large number of >people take full feeds which on my servers is about 35Mb of continuous >bandwidth in/out. That produces about 300Gb per day of which only a small >fraction ever gets downloaded. You should be aware that Usenet traffic loads are extremely sensitive to a number of seemingly inconsequential factors. To mention just two of many: (1) The presence or absence of individual groups (and by absence, I mean "poisoning an unwanted group" e.g., dropping any article posted to that group, *AND* any article that's been *crossposted to* that group). For example, consider the top 20 groups from http://www.newsadmin.com/top100bytes.htm (commas added for readability): !Binary Newsgroups Bytes % Total ! 1 alt.chello.binaries 13,757,677,778 4.538 ! 2 alt.binaries.vcd 10,087,744,846 3.327 ! 3 alt.binaries.vcd.repost 10,068,663,162 3.321 ! 4 alt.binaries.multimedia 9,901,822,387 3.266 ! 5 alt.binaries.sounds.mp3 9,159,994,565 3.021 ! 6 alt.binaries.cd.image 7,865,347,722 2.594 ! 7 alt.binaries.erotica.vcd 7,080,622,563 2.336 ! 8 alt.binaries.cd.image.playstation 5,381,405,545 1.775 ! 9 alt.binaries.movies.divx 5,004,619,468 1.651 !10 alt.binaries.music.shn 4,935,170,128 1.628 !11 alt.binaries.movies.divx.french 4,919,381,694 1.623 !12 alt.binaries.anime 4,672,847,011 1.541 !13 alt.binaries.sounds.mp3.complete_cd 4,448,118,991 1.467 !14 alt.binaries.old.games 4,410,750,072 1.455 !15 alt.binaries.multimedia.cartoons 3,898,196,934 1.286 !16 alt.binaries.images 3,768,957,616 1.243 !17 alt.binaries.mpeg.video.music 3,711,531,880 1.224 !18 alt.binaries.movies 3,547,393,708 1.170 !19 alt.binaries.cd.image.games 3,219,286,966 1.062 !20 alt.binaries.movies.divx.german 3,194,581,083 1.054 When carriage of a single group can contribute nearly 14GB worth of traffic to a feed, obviously you should pay attention to what you're carrying. You can say, "We carry and feed everything" if you like, but remember the fact that the presence or absence of a -single- group (out of tens or hundreds of thousands, depending on what you consider to be a valid newsgroup) can change your feed traffic by 14GB (nearly 5%) a day. (2) Your choice of maximum per-article article size in octets. The 80/20 rule holds. You can get 80+% of all articles at a cost of carrying only about 20% of all octets. To see this, look at slide 33 of http://www.uoregon.edu/~joe/ogig-flow-study.{ppt,pdf} quoting a graph by the folks at tele.dk... A couple of "magic values" that you may want to empirically evaluate for your local server are in the range of 40-50KB/article (if you run a "text only"- oriented server), or 250-300KB/article (image-oriented binaries plus text only server). If you are planning on carrying "everything" be sure you don't inadvertently cap articles at 1MB/article or even 4MB/article -- you'd still be missing articles if you choose that low a limit. >a) Internally to a network >If I site multiple peer servers at exchange and peering points then they >all exchange traffic, all inter and intra site circuits are filled to the >above 35Mb level. Locally, news servers should probably be run on gigabit links; average traffic may run 35Mbps for a full feed, but you would need additional capacity for peaking and recovering from outages, to say nothing of loads associated with feeds you may be fanning out, or local reader traffic loads. If you buy the argument that news servers should be gigabit connected, then 35Mbps worth of traffic in the local area really isn't much worth worrying about... >b) Externally such as at public peering exchange points >If theres 100 networks at an exchange point and half exchange a full feed >thats 35x50x2 = 3500Mb of traffic flowing across the exchange peering LAN. Usenet's pre-arranged and predictable server-to-server flows make an excellent "foundation load" when it comes to justifying a decision to participate at an exchange point, and Usenet has always been an important component of exchange point traffic. Consider, for example, the SIX in Seattle -- it is not a coincidence that the SIX it is affiliated with Altopia, a Usenet speciality service provider. >For the peering point question I'm thinking some kind of multicast thing, >internally I've no suggestions other than perhaps only exchanging message >ids between peer servers, hence giving back a partial feed to the local >box's external peers. In the higher education community, deployment of lightly loaded high bandwidth networks such as Internet2's Abilene network (see http://www.internet2.edu/ ) has largely eliminated concerns about accomodating Usenet traffic volumes, at least for Usenet traffic between Internet2- connected institutions... And of course, many I2 schools peer not only with each other, but also with local non-I2 Usenet peers, typically via a local exchange point, thereby "sharing the wealth" assuming you can accept one server's worth of intermediation. For those who want to dig in and see for themselves, check out: http://www.itec.oar.net/abilene-netflow/ Note that for 02/02/02, NNTP traffic (port=119) was the hottest application on a per-destination-port basis for the aggregation of all I2 network nodes, running 12.4% of all octets. Of course, if you change to a per-source-port view, Kazaa/Morpheus/FastTrack traffic (port=1214) was running fully twice that hot at 25+% of all octets for all network nodes. :-; Regards, Joe

1 0

Re: RE: OT: Interesting email I received
by Gregory Hicks 03 Feb '02

03 Feb '02

> Date: Fri, 1 Feb 2002 17:37:04 -0500 > From: John Neiberger <neiby(a)ureach.com> > > > Hmm...I'm still able to reach that site as of 3:30 Mountain > time. Perhaps his service hasn't been discontinued after all. > We can only hope, though. Surely Qwest won't continue to let > this bonehead use their network. > > Perhaps this is actually a Qwest front company and they're > trying to lure people into using their bulkmailing services. > By doing this they can get a lot of the bulk mails to at least > have the same set of source IP addresses making them easier to > filter for the rest of us. :-) Sort of like a honey pot for > idiots, because in this case they'd even be paying to use it. Actually, I don't believe that it *is* a front for quest. One of the responses I got from whois indicated that the name is owned by "CnS Systems, Inc" ... Can anyone say "Cantor and ..." The people that brought the art of spam to its current unloved height? Regards, Gregory Hicks > > ---- On Fri, 1 Feb 2002, Joe Blanchard (jblanchard(a)wyse.com) > wrote: > > > I just had to call that number on his web page > > and ask if it was some sort of joke, The guy > > there "Paul" didn't have any idea that his > > services were disrupted, and he even seemed > > excited at the prospect of doing some Bulk/Spam > > Email for me. > > > > When I mentioned I couldn't get to his webpage > > He seemed surprised. I ended the convo with > > "You should really read the TOS with your ISP" <click> > > > > hahaha. I would love to hear the conversation between him > > and Qwest Tech/Support. > > > > Cheers! > > -Joe ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479 San Jose, CA 95134 | Internet: ghicks(a)cadence.com "The trouble with doing anything right the first time is that nobody appreciates how difficult it was." When a team of dedicated individuals makes a commitment to act as one... the sky's the limit. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff

3 2

Draft agenda for NANOG24
by Susan Harris 03 Feb '02

03 Feb '02

Here's the plan for our Miami meeting, Feb. 10-12: ================================================= SUNDAY TUTORIALS 1:30 - 3:00 p.m. Inter-domain Traffic Engineering: Principles, Applications, and Case Studies Josh Wepman, Ixia, Joe Abley, MFN 1:30 - 3:00 p.m. IS-IS Deployment & Design Guidelines, with Emphasis on New Features Shankar Vemulapalli, Cisco 3:00 - 3:30 p.m. COFFEE BREAK 3:30 - 5:00 p.m. Routing Policy Implementation Guide Dan Golding, Sockeye 3:30 - 5:00 p.m. A Practical Look at Multicast Greg Shepherd, Juniper MONDAY GENERAL SESSION 9:00 a.m. Welcome, Introductions Susan Harris, Merit Monty Bannerman, Terremark 9:15 a.m. Network and Node Availability Improvements through Routing Protocol and Signalling Extensions Dave Ward, Cisco 10:15 a.m. How to Secure Your Job: Implement MPLS VPNs Roger Gottsponer, Nextra 10:45 a.m. BREAK 11:00 a.m. Global Crossing's Operational Experience With MPLS Dave Siegel, Global Crossing 11:45 a.m. - 12:05 p.m. An Approach to IP Network Traffic Engineering Chris Liljenstolpe, Cable & Wireless 12:00 p.m. LUNCH 1:30 p.m. New Directions in Peering for Tier-2 and Content Providers Jeb Linton, EarthLink 2:00 p.m. Panel: Updates From the Exchange Points Mike Hughes, LINX, moderator Paul Vixie, PAIX Lane Patterson, Equinix Tom Bechly, MAE Services Akio Sugeno, NYIIX/LAIIX/6IIX Avi Freedman, Jeff Meltzer, MetroIX Tony Haeuser, SBC NAPs (AADS, PacBell) Matthew Brooks, NOTA Albert Crews, Bellsouth MIX 3:00 p.m. .com/net/org Registry Update Matt Larson, VeriSign 3:30 p.m. BREAK 3:45 p.m. DNS Damage - Measurements at a Root Server Evi Nemeth, CAIDA 4:15 p.m. Internet Measurement: Myths About Internet Data K Claffy, CAIDA MONDAY EVENING BOFs 7:30 - 9:00 p.m. UWho BOF Andrew Newton and Leslie Daigle, Verisgin 7:30 - 9:00 p.m. NAP Update, Part II: Meet the Operators Mike Hughes, LYNX, moderator 9:00 - 10:30 p.m. Route Registry BOF Larry Blunk, Merit 10:30 p.m. PGP Key Signing Party TUESDAY GENERAL SESSION 9:00 a.m. A Detailed Analysis of ISIS Routing Protocol Behavior Cengiz Alaettinoglu and Steve Casner, Packet Design 9:30 a.m. Identifying Problematic Inter-domain Routing Issues Olaf Maennel and Anja Feldmann, Saarland University, Saarbruecken, Germany 10:30 a.m. BREAK 10:45 a.m. Internet Expansion, Refinement, and Churn Andre Broido, Evi Nemeth, and K Claffy, CAIDA 11:15 a.m. Inter-domain Multicast in European Research Networking: TEN-155 Operational Experience and Deployment of GEANT Agnes Pouele, DANTE, and Jan Novak, Cisco 12:00 p.m. LUNCH 1:30 p.m. Operator Requirements of Infrastructure Management Methods Steve Feldman, Vivace 1:45 p.m. NOC Theory and Practice Timothy Brown, Matthew F. Ringel, Akamai 2:30 p.m. Pseudowires and L2TPv3 Engineering Mark Townsley, Cisco 3:00 p.m. Real-world Techniques for Automating the Configuration of Network Devices Mark Epstein, Ponte 3:30 p.m. Closing Remarks

1 0

Re: Reducing Usenet Bandwidth
by Miquel van Smoorenburg 03 Feb '02

03 Feb '02

In article <cistron.g3lmeao4x1.fsf(a)as.vix.com>, Paul Vixie <vixie(a)as.vix.com> wrote: >Pull it, rather than pushing it. nntpcache is a localized example of how >to only transfer the groups and articles that somebody on your end of a >link actually wants to read. A more systemic example ought to be developed >whereby every group has a well-mirrored home and an nntpcache hierarchy >similar to what Squid proposed for web data, and every news reader pulls >only what it needs. Posting an article should mean getting it into the >well-mirrored home of that group. Removing spam should mean deleting >articles from the well-mirrored home of that group. Yes, but who's going to set up the home for movies/pictures/warez/mp3 groups? Nobody, ofcourse, since most stuff is not very legal. But those groups are 98% of todays traffic. So if you *do* manage to switch everybody over to that new system and turn off the old usenet, the new system isn't needed anymore. Mike. -- Computers are useless, they only give answers. --Pablo Picasso

2 1

Re: Reducing Usenet Bandwidth
by Steven M. Bellovin 03 Feb '02

03 Feb '02

In message <g3lmeao4x1.fsf(a)as.vix.com>, Paul Vixie writes: > > It's well and truly past time to pull it >rather than push it. > Agreed -- and I'm one of the people who invented pushing netnews. It was an artifact of the technology of the time. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

1 0

WARNING: Whois mining operation (probably spam related).
by John Palmer (NANOG Acct) 03 Feb '02

03 Feb '02

Starting about 6am eastern time, we began getting several hundred hits per second from IP address 195.188.22.6 to our WHOIS server. It appears that they were running a rather well endowed dictionary against the database. Beware - these are spammers (I know the address very well). Check your logs if you have any email servers or whois databases. This is a jerk from England who is a known fraudster.

4 3

Re: distributed attack, high or not
by Steven M. Bellovin 03 Feb '02

03 Feb '02

In message <20020131025142.A12260(a)monet.titania.net>, "Joseph T. Klein" writes: > >I define it as random because the traffic rise could be seen >coming in from multiple providers and looked to be the same >percent from all sources (separate routers with separate >interfaces to separate ASNs in separate geographic locations). >The traffic was inbound and not backsplash from randomized >source addresses. > >It looks to me like a infection with someone turning a control >knob. Is this common or a precusor of a bad thing? > It's a classic DDoS attack, aimed at you. Someone has lots of zombie machines out there; at some point, they sent a command packet to all of them, saying "bombard such-and-such an IP address for 3600 seconds". Common? It happens frequently to someone. Precursor? Entirely possible, though there's no way to know for sure. But it can be very bad -- see http://news.zdnet.co.uk/story/0,,t269-s2103098,00.html for what happened to a British ISP. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

4 4

NetFlow collector..
by Alex Rubenstein 03 Feb '02

03 Feb '02

I have been looking around for a while now, for a piece of software that can sit on a *nix box, and simply export netflows from a promiscuous mode media adapter. For instance; I've become used to using the ip flow-aggregation stuff (specificall for AS), as follows: ip flow-aggregation cache as export destination x.x.x.y 4444 enabled Problem being tho, that on the 6509/MSFC2/PFC platform, to use this, you have to raise the traffic flow out of hardware-switched PFC to MSFC software switching/routing. What I'd like to do is take a unix box, with a gig-e or whatnot interface, mirror traffic to it, and let it generate the flow's to be collected by another machine. Anyone got some pointers, or insight? How are others doing AS flows? -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

2 1