February 1998 - Test - lists.nanog.org

Re: Transparent Caching Solutions - Information Wanted
by Matt Ranney 05 Feb '98

05 Feb '98

Bill Unsworth <bill(a)u-net.net> writes: > Interesting discussion - no many comments from ISPs currently using caching > regarding the effectiveness - cache hit rates or bandwidth "saved". > > Any strategies for populating caches (in addition to user hits)? [...] I'm not sure sure that hit rate should be the primary means of measuring the effectiveness of an HTTP proxy/cache. As was discussed the SF NANOG, the penalty for packet loss on connections with higher RTTs is severe. So even if a proxy server is fetching a miss on a path with a lower RTT than the requesting client there's still a win. Of course, I know of no good way to measure this type of winnage. I guess I could claim squid's ICMP RTT measurement neighbor selection routing thing as another big win, but I'm sure it flies in the face of all that is Decent and True with the Purists out there. -- Matt Ranney - mjr(a)ranney.com Let's not let the students run the High School.

2 1

Re: MTU of the Internet?
by Tony Li 05 Feb '98

05 Feb '98

jra(a)scfn.thpl.lib.fl.us (Jay R. Ashworth) writes: > > Unless your ISP uses BBN Butterflies and C30 IMPs in its backbone, I > > would discount the odds of running into a link with an MTU of 576. > > How do I program my router to emulate one of those? You don't need to. It's already there. You just need to configure it: conf term int serial 0 ip mtu 576 no ip route-cache <repeat for all interfaces> no router bgp 109 router egp 109 ... ^Z To simulate an IMP, you need to configure X.25 DCE interfaces. This is too gross to discuss on a family mailing list. ;-) Tony

3 3

MTU size & IP packet size distributions
by rja＠corp.home.net 05 Feb '98

05 Feb '98

Not to interrupt a discussion by adding measured data, but there is some collected data on MTU sizes around the net. I believe kc has some packet statistics data online at NLANR. Alternately, there is some @Home packet size data (from Mike Schwartz) online in PDF format at: ftp://ftp.home.net/pub/rja/home-pkt-dist.pdf Folks perusing the @Home data should keep in mind that nearly all residential customers have 10baseT Ethernet access to the Internet. So we have near zero packets larger than Ethernet MTU. :-) Ran

1 0

Re: BBn butterfly
by Jay R. Ashworth 05 Feb '98

05 Feb '98

On Thu, Feb 05, 1998 at 10:32:11AM -0500, Jon Zeeff wrote: > Any idea where we can buy a BBN butterfly? I think customers would > like to see it. This one should have been to the list, who're more likely to know; I've carboned it back; reply to JON, everyone. Or ask in alt.folklore.computers. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com

1 0

RE: Transparent Caching Solutions - Information Wanted
by Barry Raveendran Greene 05 Feb '98

05 Feb '98

On Thursday, February 05, 1998 9:14 AM, Matt Ranney [SMTP:mjr@ranney.com] wrote: > > I'm not sure sure that hit rate should be the primary means of > measuring the effectiveness of an HTTP proxy/cache. Aggreed! When running the Cache Cluster at SingNet (Singapore Telecom) we were more interested in the bytes served vs bytes fetched. Barry

1 0

Re: Quality of Service by Ferguson and Huston
by Hank Nussbacher 05 Feb '98

05 Feb '98

At 03:39 PM 2/4/98 -0500, Gordon Cook wrote: >For ordering data on the book see: >http://www.wiley.com/compbooks/catalog/24358-2.htm Or go to www.amazon.com and save 20% on Wiley's price (ISBN0471243582). -Hank

1 0

Re: MTU of the Internet?
by gary flynn 05 Feb '98

05 Feb '98

My guess is that when you're traversing a network or NAP that is dropping 10-20% of its packets, smaller packets would have a higher survival rate and thus result in better overall throughput due to the lack of timer based retries. It probably has nothing to do with MTUs or fragmentation across the net. Its probably due to the lossy nature of our current environment (i.e. overloaded NAPs). A simple test should show this. Slap a protocol analyzer on the line and see how many retransmitted packets and/or response delays there are for various MTUs. For heaven's sake, don't change system software until we know what the *real* cause is! We've got enought kludges out there already :) Gary Flynn Network Analyst James Madison University

1 0

Re: [Fwd: smurf... still?]
by Michael Gibson 05 Feb '98

05 Feb '98

We at Netcom Canada, only migrated the customer base for portions of the old Hookup network. The Hookup core was torn down, with the address space going to Interhop (another ISP in Toronto). Michael Gibson Sr. Network Admin - Netcom Canada -----Original Message----- From: Murray S. Kucherawy <msk(a)concentric.net> To: Heather Knape <hknape(a)pbi.net> Cc: Sharif Torpis <faust(a)grift.com>; tatsuya(a)giganet.net <tatsuya(a)giganet.net>; djr(a)narnia.n.ml.org <djr(a)narnia.n.ml.org>; nanog(a)merit.edu <nanog(a)merit.edu> Date: Thursday, February 05, 1998 9:45 AM Subject: Re: [Fwd: smurf... still?] >Yep, I left HookUp in very early January of 1997. I wouldn't even know >who to talk to up there at this point. I don't think HookUp exists >anymore, but clearly some of their equipment is still on and running, >presumably for the customer transition to NetCom. > >You guys are on your own with this one. You might try seeking help from >their upstream providers, Sprint Canada I believe. > >Incidentally, my last name isn't "Kucher", it's "Kucherawy". There still >are some last names out there that don't fit in UNIX userids, you know. >:-) > >-MSK > >On Wed, 4 Feb 1998, Heather Knape wrote: >> nope-ola...he's gone down to concentric. >> >> I think he is msk(a)cris.com. >> -Heather >> > >> > This is a multi-part message in MIME format. >> > --------------59171506A0F880CE1989B67C >> > Content-Type: text/plain; charset=us-ascii >> > Content-Transfer-Encoding: 7bit >> > >> > can u forward this to murray? mskucher(a)pbi.net bounces ... is he still >> > there? >> > >> > -- >> > "Gas, grass, or ass, nobody rides for free." >> > >> > >> > --------------59171506A0F880CE1989B67C >> > Content-Type: message/rfc822 >> > Content-Transfer-Encoding: 7bit >> > Content-Disposition: inline >> > >> > Received: from proxy2.ba.best.com (root(a)proxy2.ba.best.com [206.184.139.13]) by shell16.ba.best.com (8.8.8/8.8.BEST) with ESMTP id KAA07467 for <faust+XRCPT.66617573744067726966742e636f6d(a)shell16.ba.best.com>; Wed, 4 Feb 1998 10:57:21 -0800 (PST) >> > Received: from merit.edu (merit.edu [198.108.1.42]) by proxy2.ba.best.com (8.8.8/8.8.BEST) with ESMTP id KAA28004; Wed, 4 Feb 1998 10:55:04 -0800 (PST) >> > Received: from localhost (daemon@localhost) >> > by merit.edu (8.8.7/8.8.5) with SMTP id LAA07668; >> > Wed, 4 Feb 1998 11:30:51 -0500 (EST) >> > Received: by merit.edu (bulk_mailer v1.5); Wed, 4 Feb 1998 11:22:10 -0500 >> > Received: (from majordom@localhost) >> > by merit.edu (8.8.7/8.8.5) id LAA07204 >> > for nanog-outgoing; Wed, 4 Feb 1998 11:22:08 -0500 (EST) >> > Received: from home.merit.edu (home.merit.edu [198.108.60.42]) >> > by merit.edu (8.8.7/8.8.5) with ESMTP id LAA07200 >> > for <nanog(a)merit.edu>; Wed, 4 Feb 1998 11:21:58 -0500 (EST) >> > Received: (from ljb@localhost) by home.merit.edu (8.8.7/merit-2.0) id LAA25311 for nanog(a)merit.edu; Wed, 4 Feb 1998 11:21:57 -0500 (EST) >> > Received: from unix.org (unix.org [209.89.28.200]) >> > by merit.edu (8.8.7/8.8.5) with ESMTP id BAA00138 >> > for <nanog(a)merit.edu>; Wed, 4 Feb 1998 01:23:15 -0500 (EST) >> > From: chris(a)unix.org >> > Received: (from chris@localhost) >> > by unix.org (8.8.8/8.8.8) id BAA27888; >> > Wed, 4 Feb 1998 01:22:23 -0500 (EST) >> > Message-ID: <19980204012222.49227(a)unix.org> >> > Date: Wed, 4 Feb 1998 01:22:22 -0500 >> > To: Tatsuya Kawasaki <tatsuya(a)giganet.net> >> > Cc: Daniel Reed <djr(a)narnia.n.ml.org>, nanog(a)merit.edu >> > Subject: Re: smurf... still? >> > References: <Pine.LNX.3.96.980203203347.6760A-100000(a)narnia.n.ml.org> <Pine.GSO.3.95LJ1.1b4.980204120041.5092L-100000(a)thongvilay.giganet.net> >> > Mime-Version: 1.0 >> > Content-Type: text/plain; charset=us-ascii >> > X-Mailer: Mutt 0.88e >> > In-Reply-To: <Pine.GSO.3.95LJ1.1b4.980204120041.5092L-100000(a)thongvilay.giganet.net>; from Tatsuya Kawasaki on Wed, Feb 04, 1998 at 12:01:49PM +0900 >> > Sender: owner-nanog(a)merit.edu >> > X-Rcpt-To: faust(a)grift.com >> > >> > On Wed, Feb 04, 1998 at 12:01:49PM +0900, Tatsuya Kawasaki wrote: >> > > Daniel, >> > > >> > > Try mskucher(a)hookup.net >> > > >> > > HookUp Communications >> > > 165.154.0.0/16 >> > > >> > > do you think this will help? >> > >> > Daniel, >> > >> > $ whois 167.154.0.0 >> > 1075 North Service Road West, Suite 207 >> > Oakville, Ontario L6M 2G2 >> > Canada >> > >> > Netname: HOOKUP-NET-4 >> > Netnumber: 165.154.0.0 >> > >> > Murray Kucher (mskucher(a)hookup.net, still listed as hookup's contact in >> > various databases) has long left HookUp; I don't believe his @hookup.net >> > address works anymore. >> > >> > To confuse matters further, NetCom Canada has some odd ownership of HookUp, >> > whom I believe declared bankruptcy. Last I heard, NetCom only acquired >> > HookUp's customer base. I mention this in the event that you are unable >> > to find anyone at HookUp -- try a contact from www.netcom.ca instead. >> > >> > noc(a)hookup.net may forward somewhere useful. >> > >> > Hope this helps, >> > >> > -Chris >> > >> > Chris Portman ================================================= chris(a)unix.org >> > Senior Systems Operations and Security iSTAR Internet Inc. >> > (613) 788-7767 Ottawa, ON, CA >> > >> > >> > --------------59171506A0F880CE1989B67C-- > >-- >Murray S. Kucherawy ============================================= msk(a)cris.com >Senior Software Engineer/UNIX Wizard Concentric Network Corporation >(408) 342-2800 NIC Handle "MSK" Cupertino, CA, USA ># "Do you lead, or are you led? Are you sure that you don't care?" -- INXS # > >

1 0

Re: MTU of the Internet?
by Tony Li 05 Feb '98

05 Feb '98

perry(a)piermont.com (Perry E. Metzger) writes: > This will effectively triple the number of packets that routers have > to do processing on, that's why. The intent is right, but the result here is wrong. Unfortunately, 1500 byte packets are rare. About 6.9% of the traffic (by packet). Yes, it would triple that fragment of the traffic. However, that would not affect the other (much more common) packet sizes in the distribution. If you wanna worry about the number of packets in the net, worry about the 40 byte packets. Dem's da killas. ;-) Tony

1 0

Free Software for Fast IP-Address Lookup
by Michael Dillon 04 Feb '98

04 Feb '98

Here's an interesting note I ran across today.... --------------forwarded message begins----------- FREE SOFTWARE FOR FAST IP-ADDRESS LOOKUP Efficient, compact and easily searchable IP routing tables can be built by using an LC-trie, a trie structure with combined path and level compression. The depth of the LC-trie grows as O(log log N) with the number of entries N for a large class of distributions. A node in the trie can be coded in only four bytes and holds 128-bit addresses without modification. We are now making a software implementation publically available that can sustain approximately half a million lookups per second on a 133 MHz Pentium personal computer, and two million lookups per second on a more powerful SUN Sparc Ultra II workstation for random traffic. The number of lookups roughly doubles for real traffic owing to better caching. The size of the main search structure never exceeds 500 kB for the tables in the US core routers. Our results include the full lookup from a given 32-bit address to the resulting port number and next-hop address. The source code and an accompanying paper can be fetched from URL http://www.cs.hut.fi/~sni/papers/router/router.html No patents are pending or awarded for the algorithm. Stefan Nilsson Department of Computer Science Helsinki University of Technology, Finland Gunnar Karlsson Swedish Institute of Computer Science Sweden

2 1