- Test - lists.nanog.org

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 05 Feb '98

05 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

Quality of Service by Ferguson and Huston
by Gordon Cook 05 Feb '98

05 Feb '98

I want to call everyone's attention to Quality of Service (Jan 1998) Wiley Computer Books, $35, an important new book by Paul Ferguson and Geoff Huston. Last week in London Paul gave me a copy and conscented to an interview. I suspect that this will be a very important book that will sell very very well. Why? Because EVERYONE who is doing any kind of network engineering in an ISP no matter how small will profit from using this book. I find the title somewhat misleading in that QoS usually means the more esoteric concept of guaranteeing packet priority or network bandwidth. In our interview Paul pointed out that this book is much broader in scope and is intended to be a guide to how to properly engineer a network so as to achieve maximum possible performance from one's network connection. For ordering data on the book see: http://www.wiley.com/compbooks/catalog/24358-2.htm Quality of Service: Delivering QoS on the Internet and in Corporate Networks Paul Ferguson ; Geoff Huston Table of Contents What is Quality of Service? Implementing Policy in Networks. QoS and Queuing Disciplines, Traffic Shaping, and Admission Control. QoS and TCP/IP: Finding the Common Denominator. QoS and Frame Relay. QoS and ATM. The Integrated Services Architecture. QoS and Dial Access. QoS and Future Possibilities. QoS: Final Thoughts and Observations. Afterward. Glossary. Bibliography. The following URL contains an amazingly detailed hot linked QoS bibligraphy ranging from Internet drafts to more general QoS articles. http://www.wiley.com/compbooks/ferguson ************************************************************************ The COOK Report on Internet New Special Report: Building 431 Greenway Ave, Ewing, NJ 08618 USA Internet Infrastructure ($395) (609) 882-2572 (phone & fax) www.cookreport.com/building.html cook(a)cookreport.com Index to 6 years of COOK Report, glossary, executive summaries, special reports found at www.cookreport.com ************************************************************************

2 1

Re: [Fwd: smurf... still?]
by Murray S. Kucherawy 04 Feb '98

04 Feb '98

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: with a flap flap here and a flap flap there...
by Sean M. Doran 04 Feb '98

04 Feb '98

Marc Slemko <marcs(a)znep.com> writes: > But the loop avoidance from having paths constrains you to the width of > the Internet in terms of ASes. It isn't completely a distance vector > protocol. Yakov Rekhter also made a similar observation. I was caught up in rhetoric and was imprecise. (I could also be wrong; it happens.) BGP records paths and the loop avoidance scheme prevents a count-to-infinity problem in a way slightly better than RIP with split horizons does. In a network like this: C /| A--B< | \| D if A-B goes down in a split-horizons RIP network, there can still be a count-to-infinity problem between C and D announcing reachability to A. BGP does not have this problem. However, a withdrawal of a network from D can cause A to see a transition from ABD to ABCD to unreachable. This effect is what was complained about in the message I initally followed-up to. BGP is also not formally a distance vector protocol because the AS_PATH attribute is a trail of breadcrumbs rather than a distance. However, I argue that in common practice, it is a distance, and offer up AS-path prepending to affect path selection remotely as evidence. > I guess I'm just suprised at how wide the Internet has grown and at the > lack of noticeable public acknowledgment of the resulting problems. I'm not so surprised by the first bit, and I think I have become jaded about the second. Sean.

1 0