February 1998 - Test - lists.nanog.org

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

04 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

BGP mailing list
by Bradley Reynolds 04 Feb '98

04 Feb '98

Because I was tired of BGP questions coming onto a wide variety of lists, I created a mailing list for them. To subscribe, send mail to bgp-request(a)iagnet.net with 'subscribe' in the body. Note: This list deals with more of the ground level BGP understanding. It is not intended to replace/duplicate bgp(a)ans.net. Just a wishful attempt to improve the clue factor :). BR brad reynolds ber(a)cwru.edu

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: > 3333 6905 5623 1136 3300 7018 6478 1 701 814 7189 1691 852 6171 (history entry) > Am I the only one that has a problem with this? You withdraw a > route once, and it has flapped enough to be dampened in numerous > places. I could have been half convinced that we had gone back to > distance vector routing seeing this going on... BGP *is* a distance-vector routing protocol. What you were witnessing was a counting-to-infinity problem that is bounded by timers and toplogical constraints. Welcome to the wonderful world of BGP == RIP. This is precisely why a mechanism which constrains the amount of prefix transitions is so important: magnification of flapping is predictable. However, welcome to the wonderful world of lack of filtering, too. There is no apparent reason why a number of those ASes should have reannounced your routes to each other. Each BGP peering (customer and peer alike) should either explicitly allow announcements only from a list of appropriate ASes, or explicitly disallow announcements which have been through peers and (at least large) other BGP-talking customers. This is an Incredibly Smart Thing To Do. On a Cisco, the _ operator is your best regexp friend... Sean.

2 1