- NANOG - lists.nanog.org

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

09 Feb '02

>Date: Fri, 08 Feb 2002 22:09:12 -0800 >From: Stephen Stuart <stuart(a)tech.org> >Subject: Re: Reducing Usenet Bandwidth >To: David Schwartz <davids(a)webmaster.com> >Cc: nanog(a)merit.edu [snip] >Some of those problems in that vein that appeared insurmountable ten years >ago might have solutions in current "peer-to-peer" networking technologies >(thus the off-hand comment about Napster). What you're really asking for is a NNTP-over-FastTrack (Kazaa/Morpheus) feed object. This is sort of/really an odd idea, but if you think about it, all the required parts are pretty easy to articulate in skeleton form: 1) Each file dumped into FastTrack/Kazaa/Morpheus would get as its "filename" the article's message-ID. A site that wanted to retrieve an article would issue (via FastTrack/Kazaa/Morpheus) a search request for that message-ID, retrieve the article from a FastTrack/Kazaa/Morpheus server that offered that file, and then add it to the local news news server spool (and/or, optionally, a FastTrack/Kazaa/Morpheus shared directory on the local server). 2) How would servers know what article IDs to ask for? Well, Usenet overview data for each group could also be published by news servers via FastTrack/Kazaa/Morpheus with filenames of the format pathtag!hierarchy.subhierarchy.group!yy:mm:dd:hh:mm:ss The pathtag would be required because obviously different news servers will know about different articles, and you will want to disambiguate which server's overview data you want (not because there's any expectation that any news server will in fact provide public access to any articles, but simply because one might expect that N servers might all simultaneously offer comparable but non-identical overview data for any given group, and you might want to choose the view from server foo, or bar, or baz over other alternatives). The hierarchy.subhierarchy.group component of the overview file name simply allows folks to identify the overview data file they'd want. The date/time stamp (GMT) provides a means of selecting the most recently available overview data from a list of matching responses. Overview data would obviously need to be cryptographically signed with a key tied to the pathtag to avoid problems with people providing forged overview data (wouldn't want people to be fed lists of bogus/inappropriate lists of message ID's as a DOS/spam attack, right?). Overview files could be generated at some server-determined periodicity, and to avoid inspiring any sort of synchronization effect, I'll omit mentioning a value here except to say that I've got something in the double-digits-of- minutes in mind here. (Besides, if you're going to publish overview data for some tens of thousands of groups, it will take a while to walk that tree). 3) Client servers interested in retrieving articles via FastTrack/Kazaa/Morpheus could routinely retrieve overview records for groups of interest, retrieving all/some of the articles as a "prefetch" for popular groups routinely read by their users, or the server could wait until articles have been requested, then retrieve an overview file, then retrieve articles. Alternatively, individual users with "News over FastTrack/Kazaa/Morpheus" clients could be retrieving articles directly from Kazaa, removing any need for an intervening news server whatsoever (although hopefully a local "regular" news server would always be faster than a distributed FastTrack/Morpheus/Kazaa-based news spool). Regards, Joe P.S. Needless to say, this would really change the FastTrack/Kazaa/Morpheus content base, and given the volumes Usenet is currently transferring, would be sort of an interesting experiment if we're talking about a full feed...

1 0

Contact for Telemail.com.mt / Datastream.com.mt
by Avleen Vig 09 Feb '02

09 Feb '02

Foreword: I know this list is be definition for 'North America' but I've run out of places to turn to. telemail.com.mt are currently operating a huge smurf amplifier in Malta, and the have been unresponsive to requests to fix it, for 3 weeks. Emails to their upstream provider's abuse address (abuse(a)datastream.com.mt) are bouncing. This is a Bad Thing. If anyone has a contact address for either of these ISP's, please contact me off list. For the curious, the average number of responses from this network is currently ~17,000. -- Avleen Vig Network Security Officer Smurf Amplifier Finding Executive: http://www.ircnetops.org/smurf

2 1

Re: Contact for Telemail.com.mt / Datastream.com.mt
by Stephane Bortzmeyer 09 Feb '02

09 Feb '02

On Saturday 9 February 2002, at 3 h 5, Avleen Vig <lists-nanog(a)silverwraith.com> wrote: > If anyone has a contact address for either of these ISP's, please contact > me off list. Did you try the phone numbers in the RIPE database? After all, maintaning that database up to date is so much work that it has to be useful some times :-) person: Philip Cassar address: Telemail Limited address: Suite 1 Cali House address: Naxxar Road address: San Gwann address: Malta address: SGN07 phone: +356 380180 fax-no: +356 380190 e-mail: philip(a)telemail.com.mt nic-hdl: PC4939-RIPE changed: philip(a)telemail.com.mt 20000703 source: RIPE person: Christopher Debono address: Telemail Limited address: Suite 1 Cali House address: Naxxar Road address: San Gwann address: Malta address: SGN07 phone: +356 380180 fax-no: +356 380190 e-mail: chris(a)telemail.com.mt nic-hdl: CD3238-RIPE changed: chris(a)telemail.com.mt 20000703 source: RIPE person: Geoffrey Cauchi address: Datastream Ltd. address: Telepage Buildings address: Psaila Street address: B'Kara address: Malta address: BKR 02 phone: +356 2567 7257 fax-no: +356 446830 e-mail: geoffrey.cauchi(a)datastream.com.mt nic-hdl: GC5493-RIPE notify: geoffrey.cauchi(a)datastream.com.mt mnt-by: GC5493-RIPE-MNT changed: geoffrey.cauchi(a)datastream.com.mt 20011203 source: RIPE

1 0

The Cidr Report
by CIDR Report 09 Feb '02

09 Feb '02

This is an auto-generated mail on Fri Feb 8 23:00:00 PST 2002 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 08Feb02 0) General Status Table History ------------- Date Prefixes 010202 105568 020202 105595 030202 105578 040202 105667 050202 105600 060202 105584 070202 105721 080202 105598 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 96.0.0.0/20 from AS3549 AS Summary ---------- Number of ASes in routing system: 12381 Number of ASes announcing only one prefix: 7537 (4280 cidr, 3257 classful) Largest number of cidr routes: 717 announced by AS701 Largest number of classful routes: 1357 announced by AS701 1) Gains by aggregating at the origin AS level --- 08Feb02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1156 892 264 22.8% Telstra Pty Ltd AS701 1357 1126 231 17.0% UUNET Technologies, Inc. AS577 323 197 126 39.0% Bell Advanced Communications Inc. AS16473 198 77 121 61.1% Bell South AS7018 821 703 118 14.4% AT&T AS4151 261 149 112 42.9% USDA AS6595 168 60 108 64.3% DoD Education Activity Network As AS17557 195 88 107 54.9% Pakistan Telecom AS705 293 189 104 35.5% UUNET Technologies, Inc. AS852 425 325 100 23.5% Telus Advanced Communications AS7046 329 230 99 30.1% UUNET Technologies, Inc. AS19632 94 9 85 90.4% Metropolis Intercom S.A. AS2048 185 105 80 43.2% State of Louisiana AS12302 110 31 79 71.8% MobiFon S.A. AS1239 475 398 77 16.2% Sprint AS4755 221 150 71 32.1% Videsh Sanchar Nigam Ltd. Autonom AS4323 406 340 66 16.3% Time Warner Communications, Inc. AS703 279 217 62 22.2% UUNET Technologies, Inc. AS3464 157 97 60 38.2% Alabama SuperComputer Network AS7303 107 49 58 54.2% Telecom Argentina Stet-France Tel AS724 209 151 58 27.8% DLA Systems Automation Center AS16758 63 6 57 90.5% IKON Office Solutions AS3908 320 264 56 17.5% Supernet, Inc. AS226 145 89 56 38.6% Los Nettos AS13999 70 14 56 80.0% Mega Cable S.A. de C.V. AS19834 63 8 55 87.3% NetForce, Inc. AS702 654 600 54 8.3% UUNET Technologies, Inc. AS1 491 438 53 10.8% BBN Planet AS2149 308 256 52 16.9% Performance Systems, Inc. AS9051 73 22 51 69.9% INCONET Autonomous System Total 53855 42131 11724 21.8% For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: Reducing Usenet Bandwidth
by Michael Painter 09 Feb '02

09 Feb '02

>>If you ask a question, you should pay. If I provide you with useful help, you should pay. If I suggest a commercial solution to your problem, who should pay? If I harass you for not knowing the answer to the question, I should pay.<< Hmm, reminds me of the Compu$erve Forums, which, ironically, met their demise (imho) when the WWW (and Usenet) started to blossom. ex 70720,151 ----- Original Message ----- From: "David Schwartz" <davids(a)webmaster.com> To: "Stephen Stuart" <stuart(a)tech.org>; <nanog(a)merit.edu> Sent: Friday, February 08, 2002 3:32 PM Subject: Re: Reducing Usenet Bandwidth > > > >I would argue that what USENET needs is a way for the cost of > >publication to be incurred by the publisher; storing the data in your > >own repository (or repositories) while pointers get flooded through > >the USENET distribution system would give publishers an incentive to > >do garbage collection that they do not have today. > > Like many Internet settlement schemes, this seems to not make much sense. If > a person reads USENET for many years enjoying all of its wisdom, why should > he get a free ride? And why should the people who supply that wisdom have to > pay to do so? A USENET transaction is presumed to benefit both parties, or > else they wouldn't have configured their computers to make that transaction. > > Does it make sense for the New York Times to pay me to read it? But perhaps > it does for the Weekly Advertiser. > > The reason that automated schemes such as "publisher pays" will fail is > because determining who "should" pay is too complex for automated schemes. > You will just push around who takes advantage of who. > > If you ask a question, you should pay. If I provide you with useful help, > you should pay. If I suggest a commercial solution to your problem, who > should pay? If I harass you for not knowing the answer to the question, I > should pay. > > DS > >

1 0

Contact for Telemail.com.mt / Datastream.com.mt
by Avleen Vig 09 Feb '02

09 Feb '02

Foreword: I know this list is be definition for 'North America' but I've run out of places to turn to. telemail.com.mt are currently operating a huge smurf amplifier in Malta, and the have been unresponsive to requests to fix it, for 3 weeks. Emails to their upstream provider's abuse address (abuse(a)datastream.com.mt) are bouncing. This is a Bad Thing. If anyone has a contact address for either of these ISP's, please contact me off list. For the curious, the average number of responses from this network is currently ~17,000. -- Avleen Vig Network Security Officer Smurf Amplifier Finding Executive: http://www.ircnetops.org/smurf

1 0

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

09 Feb '02

In message <00e801c1b0fe$e15f8580$0100007f(a)flex.com>, "Michael Painter" writes: > >Kinda' off topic, but I've seen this gibberish in many spam posts to usenet >groups. What purpose does it serve? > >Thanks, > >--Michael > > >"She may will virtually cook above Ron when the sticky wrinkles >nibble with the sharp river. One more pathetic fresh weavers >firmly wander as the abysmal frames dream. > >Why will you reject the sweet deep tags before Priscilla does? > >Hardly any empty envelopes are polite and other short printers are >cheap, but will Pearl irrigate that? She'd rather cover eventually than >scold with Ophelia's fat dose. > >Are you kind, I mean, arriving without handsome candles? He might >judge the difficult sauce and explain it in front of its light. >Every proud dryers dye Jay, and they wistfully receive Elisa too. Get your >easily climbing ball inside my mirror. You won't help me recommending >outside your smart monument. Some forks fear, excuse, and taste. Others >angrily sow." > Some spammers add random gibberish to foil assorted anti-spam techniques. If this gibberish is different than the gibberish the same ad has in another newsgroup, it will appear to be a different post, and won't be canceled. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

1 0

Ethernet EP - MAC Address Filtering
by David McGaugh 08 Feb '02

08 Feb '02

Just curious if anyone is performing MAC Address Filtering at any of the Ethernet Exchange Points. If so has it been found to be easy to administer or difficult where by peers may be changing Layer 3 devices or Interfaces without notice? Alternately is MAC Address Filtering considered an unneeded security measure? Thanks, Dave

2 3

C&W Engineering
by German Martinez 08 Feb '02

08 Feb '02

Hi, Somebody from C&W Engineering that can contact me off-line Thank you German ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * THE DILBERT FUTURE * * Thriving on Stupidity in the 21st Century * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Internet capacity will increase indefinitely to keep up with the egos of the people using it"

1 0

Re: Reducing Usenet Bandwidth
by Jonas M Luster 08 Feb '02

08 Feb '02

Quoting Vadim Antonov (avg(a)exigengroup.com) > In other words - USENET cannot be fixed with technological improvements as > long as the root problem (admission control) is not solved. Improving > transmission or storage systems would only let spammers to send more spam > for free. > > Therefore, i'd say it is time to declare USENET defunct. It was fun while > it lasted. Usenet. That's the sum of all systems exchanging data via RFC1036. Usenet, that's not the Big5 or, even less so, alt.ALL. Declaring Usenet defunct because a part of it, using its structures, has failed to exercise the righth measures, is about as logical as declaring the Web defunct just because Slashdot is. Usenet's traffic is to some 98% comprised of binaries. A huge amout of them (some 85%, actually) is repeat traffic, IOW the same picture maybe with a different slogan attached to it or a different URL superimposed over it. By limiting Usenet back to something that can be read with more in /var/spool/news, you reduce traffic and storage requirements. Usenet, also, ist not Outlook Express or something one should read with multipart-reassemblers, one hand on the mouse. Let's face it. Usenet is not defunct. It works quite well, and that for more than twenty years, whereas the Web still lies in its infancy and already shows sings of decay. Its users may be defunct. Its adminitative mechanisms may be defunct. But Usenet is not. But, and here i aggree with you, unless clue-midgets such as Cable and Wireless start having an abuse department, unless Joe A CIO learns that networks are more than just cables to bring his website to the masses, Usenet will have no chance to remain what it once was - a bandwidth friendly, system agnostic, blazing fast communications medium.

1 0