- NANOG - lists.nanog.org

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

Re: backbone routers' priority settings for ICMP & UDP
by Vern Paxson 04 Feb '98

04 Feb '98

> As is (reasonably) well known, TCP has its own congestion control built > in to an extent. This should be put much stronger - TCP's congestion control is *the* mechanism that keeps the network stable today. > Or is Source Quench really broken by design? Pretty much. It's flawed in at least two important ways: (1) it adds traffic to the network during times of congestion; and (2) if a source quench packet is dropped, then the intended target fails to receive the notification to slow down. Both of these lead to the wrong sort of feedback cycle when the network is heavily congested - a cycle that can make congestion self-sustaining, i.e., congestion collapse. Vern (There may be a niche for source quench, though, in environments with high-latency links, where the quicker feedback than that obtainable from RED+ECN might be a sufficiently big win.)

1 0

Re: MTU of the Internet?
by Eric Germann 04 Feb '98

04 Feb '98

-----Original Message----- From: Robert E. Seastrom <rs(a)bifrost.seastrom.com> To: peterf(a)microsoft.com <peterf(a)microsoft.com> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Date: Wednesday, February 04, 1998 1:40 PM Subject: Re: MTU of the Internet? <SNIP> </SNIP> >I have no idea where they came up with this "576 internally" nonsense. >Generally whenever one runs into that number it is as a result of >creaky old software that expects to be running over milnet or arpanet. > IPX used 576 forever whenever you had to cross IPX "subnets". The reason was simple. They were lazy. 576 was the least common denominator between Ethernet, TR, and _Arcnet_ Large IPX (LIPX) allowed them to do basically what IP calls Path MTU discovery. Only took them a day short of forever to figure out how to do it. >Are Microsoft stacks known to be broken in the packet >fragmentation/reassembly department? Or are just acknowledging >deficiencies in their path mtu discovery code by setting the MSS in >the basement? I knew they had problems with window length (this from >my friends with long fat pipes)... > With all the paranoids trying to block all ICMP, not just ICMP_ECHO, doesn't that essentially break PMTUD. 576 may not be efficient, but its probably the safest to assume.

2 1

backbone routers' priority settings for ICMP & UDP
by Marko B. 04 Feb '98

04 Feb '98

Greetings, In my travels I have heard numerous times that it is a popular practice to give ICMP and even UDP traffic a lower priority on backbone routers in times of congestion. Are there any providers that document this policy? How is this policy carried out on the actual hardware? Any pointers would be appreciated. Thanks. -Marko

8 12

Re: backbone routers' priority settings
by vaananen＠NASBPD01BS.ntc.nokia.com 04 Feb '98

04 Feb '98

>>> ICMP in general is or should be given higher priority, since it is >>> necessary for congestion control. Echo requests (pings) could be thrown >> >>Please, tell me of this magic ICMP that is used for congestion control. >>Obsolete things that are now recommended against don't count. >Where is ICMP made obsolete or recommended against? I don't see it. >From rfc1812: ... stuff deleted Also from RFC1812: 4.3.3.3 Source Quench A router SHOULD NOT originate ICMP Source Quench messages. As specified in Section [4.3.2], a router that does originate Source Quench messages MUST be able to limit the rate at which they are generated. DISCUSSION Research seems to suggest that Source Quench consumes network bandwidth but is an ineffective (and unfair) antidote to congestion. See, for example, [INTERNET:9] and [INTERNET:10]. Section [5.3.6] discusses the current thinking on how routers ought to deal with overload and network congestion. A router MAY ignore any ICMP Source Quench messages it receives. DISCUSSION A router itself may receive a Source Quench as the result of originating a packet sent to another router or host. Such datagrams might be, e.g., an EGP update sent to another router, or a telnet stream sent to a host. A mechanism has been proposed ([INTERNET:11], [INTERNET:12]) to make the IP layer respond directly to Source Quench by controlling the rate at which packets are sent, however, this proposal is currently experimental and not currently recommended. Pasi

2 1

Re: MAE-Central
by Sean M. Doran 04 Feb '98

04 Feb '98

"Kent W. England" <kwe(a)geo.net> writes: > (BTW, isn't it scandalous that MFS would copy the PacBell NAP and build a > MAE using S'com BPX switches? No, just tragically stupid. Sean.

5 5