- NANOG - lists.nanog.org

Re: Legal Question
by Carl Oppedahl 01 Jul '97

01 Jul '97

At 08:33 AM 07/01/97 -0700, Scott Reubelt wrote: >May not be for this alias but I need to ask. > >I have an ISP that may be guilty of receiving copies of everyone's >emails associated with the ISP. What can be done legally? What can be done is consulting competent counsel who are knowledgeable about Internet issues, in particular to study the ECPA (Electronic Communications Privacy Act) as it may relate to your situation. --- Carl Oppedahl, Oppedahl & Larson, patent law firm http://www.patents.com/ has hundreds of pages of answers to frequently asked questions on patent, copyright, and trademark law

3 2

RE: Plethora of UUnet outages and instabilities
by Peter Cole 01 Jul '97

01 Jul '97

I am just a multihomed customer with Two T1s running BGP4. I had no trouble with my Ts from Sprint and MCI until about two months ago. I am running a 7206 with 64meg of RAM on 11.1(12). Our customer support started getting complaints about customers not being able to reach us(AS7201) from MSN dialup in Houston. The network 153.36.0.0/14 was in my BGP tables but not my IP route table. I called Cisco and after a little work they concluded that the reason the routes were being removed was more specific routes 153.36.50.0 & 153.36.51.0 inside the CIDR were removing the 153.36.0.0/14. I didn't understand the logic but a simple distribute list ignoring announcements for the two class Cs seemed to solve the problem. Later I sent a note to Sprint, MCI, MSN, & UUNET. Spint and MCI responded quickly stating that Cisco was mistaken. Cisco wants to look into it further. I have herd nothing from MSN or UUNET. I have to update the software on the router for other reasons. I thought I would wait to see if the problem is still present after my upgrade. I have no route Damping setup and can think of no other explanation for this bizarre behavior. My point is that maybe there are other reasons that so many ASs are having problems with UUNET routes. Peter Cole of Telescan, Inc. (281)588-9155 Better computing through lack of sleep. > ---------- > From: Josh Beck[SMTP:jbeck@connectnet.com] > Sent: Monday, June 30, 1997 4:12 PM > To: nanog(a)merit.edu > Subject: Plethora of UUnet outages and instabilities > > Has everyone else been seeing the almost daily UUnet outages recently, > does anyone know what the true causes of these have been? > > Josh Beck > jbeck(a)connectnet.com > ---------------------------------------------------------------------- > -- > CONNECTNet INS, Inc. Phone: (619)450-0254 Fax: > (619)450-3216 > 6370 Lusk Blvd., Suite F-208 San Diego, CA > 92121 > ---------------------------------------------------------------------- > -- >

2 1

Re: Keynote/Boardwatch Internet Backbone Index A better test!!!
by smd＠clock.org 01 Jul '97

01 Jul '97

randy(a)psg.com (Randy Bush) writes: > > Just out of curiosity, why do many (not all) of the large backbone providers > > establish their face to the web (their corporate webserver) on slow, > > badly positioned machines? > > Because it is done by marketing, not engineering? In my opinion, this alone should reduce the Value Number of any given provider. Personally, flaws or not, I welcome Boardwatch's attempts to come up with a widely-published metric for the Internet. This likely will lead other publications into similar investigations, some of which may well bring the writers and editors of various periodicals into contact with the folks at CAIDA. Also, flaws or not, Boardwatch did do something fantastically clever, and that's examining things on an end-to-end basis, rather than obsessing about details of what's going on between the endpoints. People concerned about the abysmal end-to-end throughput of even modern TCP across much of the present Internet should be rejoicing and helping other journalists develop better and more scientific approaches to categorizing expected versus observed end-to-end performance. The combination of work aimed at measuring the internals of one's network and work that measures the "(un)happiness" of certain classes of applications should be of enormous value to engineers willing to admit that they don't know all the things that affect network performance observed by end-users. The reality, however, is that most American ISPs seem to engage in knee-jerk denial or aggressive posturing whenever there is a suggestion that their network is anything but perfect. I certainly have been in the middle of that kind of thing, so I can hardly claim innocence. Such reactions are pure marketing: we can't admit that maybe there is some way we could improve things or some set of things our network doesn't do well because that would hurt our product image. People who react with marketing-think and who build with marketing-think in the first place deserve to be torn apart by analyses based in marketing-think. While the article in question isn't in my hands yet, based on Mr Rickard's and others' comments on the NANOG list, I think it's safe to guess that this is precisely what the Boardwatch study does. Sean.

3 2

Re: Plethora of UUnet outages and instabilities
by Hank Nussbacher 01 Jul '97

01 Jul '97

At 02:12 PM 6/30/97 -0700, Josh Beck wrote: >Has everyone else been seeing the almost daily UUnet outages recently, >does anyone know what the true causes of these have been? Perhaps this has something to do with it: Glitch slows UUNET to crawl June 23, 1997 Network World If the Internet felt slower than usual last Monday, you were probably a victim of the brownout on UUNET Technologies' network that slowed services in the Northeast. No one is disputing that there was a brownout. But UUNET and Cisco Systems, Inc. - which sold the Internet service provider its routers - are at odds over how it happened. The problem, both sides agree, was a router memory failure. After that, the stories diverge. According to UUNET, the ISP's hubs in Washington, D.C., and Newark, N.J., dropped packets because of a software glitch on its Cisco routers. The hubs are like points-of-presence where UUNET users' traffic is routed to and from the Internet. The routers suffered what the ISP is calling a ``memory leakage.'' Typically, after a router uses a block of memory, it puts the block back into a pool of usable memory. But that is not what happened on UUNET's routers last week. Instead of the memory being usable, it was fragmented, said Alan Taffel, vice president of marketing at UUNET. Large clusters of data that came through the routers could not be handled by the fragmented memory blocks. Once the routers ran out of memory, they automatically reset. UUNET notified Cisco, which sent over a software patch. The software Band-Aid freed up more memory in the routers cache so it would not overload, said Bob Michelet, director of corporate relations at Cisco. The patch is a temporary measure meant to be used until UUNET ups the memory on its routers, he said. UUNET started upgrading the memory on the routers, which Cisco contends was the real culprit. Cisco recommends that its ISP customers use 128M bytes of total memory on their route switch processor boards, Michelet said. UUNET uses 64M-byte memory boards on most, if not all, of its 7,500 routers. UUNET said it never received a recommendation from Cisco concerning memory for its 7,500 routers. ``But clearly, once this event occurred, we discussed the memory issue with Cisco, and we agreed the right course of action would be to upgrade the routing memory to 128M bytesÙ,'' said Jim McManus, vice president of systems engineering at UUNET. Almost every large to midsize ISP uses some Cisco equipment, so should users be concerned? That depends on who answers the question. Cisco claimed UUNET was the only ISP using 64M-byte route switch processor boards. One ISP agrees. Genuity, Inc., Bechtel Enterprises' ISP subsidiary, said it would not run a router with less than 128M bytes of memory. Genuity uses Cisco 7513 routers with fully loaded memory because the routers have to store the routing table for the entire Internet, said Rodney Joffe, chief technology officer at Genuity. Copyright 1997, Network WorldÙ > >Josh Beck jbeck(a)connectnet.com >------------------------------------------------------------------------ >CONNECTNet INS, Inc. Phone: (619)450-0254 Fax: (619)450-3216 >6370 Lusk Blvd., Suite F-208 San Diego, CA 92121 >------------------------------------------------------------------------ > >

3 2

[Fwd: Re: Legal Question]
by Scott Reubelt 01 Jul '97

01 Jul '97

-- Scott F. Reubelt sreubelt(a)whistle.com (http://www.whistle.com)

1 0

Re: Keynote/Boardwatch Internet Backbone Index A better test!!!
by smd＠clock.org 01 Jul '97

01 Jul '97

lhoward(a)UU.NET writes: > 1. Although a variety of backbones is used, the study does not say > which ones. Also, even though the study does point out the assymetrical > routing of a web transavtion (hot-potato), it doesn't point out that the > traffic being measured is a brief web request (which is dumped to the > web server's backbone ASAP) answered by a long response (10KB in this > case, dumped to the querier's backbone). Ironically, the only person I can remember actively (and publically) questioning the wisdom of hot potato routing for several applications is Curtis Villamizar. While Tony Bates and I had what seemed to be good reasons for doing closest-exit routing (among other routing policies) at the time, and there are strong economic incentives for maintaining closest-exit routing among peers, there are certainly drawbacks. Considering that the Keynote/Boardwatch study purports to help content-providers decide where to locate their content, poor performance attributable to closest-exit routing should have engineers considering the wisdom of that particular routing policy with respect to that particular market segment, depending on the focus of their businesses. The nice thing about the Keynote test is that it might get some of the cleverer people around here thinking of the Internet in a more abstract way than they might be used to. When I think in a more end-to-end fashion about comment #1 above, it seems that a provider who is rated poorly deserves the rating, even though the performance problem may be attributable to a peer's network's congested lines, broken equipment, or whatever. In effect, by taking an end-to-end approach, this test also rates networks' routing policies. If the routing policy drives traffic through a competitor's suboptimal path, and this degrades end-to-end performance, then the provider with that routing policy will receive a poorer rating than otherwise. One of the things that should be thought about is that there may be ways to improve end-to-end goodput by changing one's own network based on what one can infer from tests similar to the Keynote ones (or indeed similar to Vern Paxson's tests), as much as what one can infer from what one's own equipment is doing or seeing. > All of the previous notwithstanding, I would be interested in a better > version of this study. Even more interesting would be to track how > providers do over the course of several studies--who responds well to > backbone congestion? Personally, I would take this comment as a sign that the study and its publication is astoundingly successful. Finally, I would rather see people respond to congestion in a cleverer fashion, i.e. by deploying or pressing for the deployment of better WWW transport technology. There are some people with very clever ideas about caching and lazy proxies, and some clever ideas about changing HTTP in dramatic ways, that deserve some attention, as these ideas are more likely to help people and information meet more quickly in the long run than any amount of tweaking the underlying transport fabric ever will. Sean.

1 0

Re: Plethora of UUnet outages and instabilities
by Geoff Haviland 01 Jul '97

01 Jul '97

RSP4 is supported on 7505 At 09:14 AM 7/1/97 +0100, Neil J. McRae wrote: >On Mon, 30 Jun 1997 18:17:48 -3100 (MST) > Wayne Bouchard <web(a)typo.org> wrote: > >> Thats my point. It often ISN'T easy. For example, say you've got a >> 7505 in one spot and find its getting killed. You can't put an rsp4 in >> a 7505. You've got to replace the router. Anyone got any spare 7507s >> or 7513s lying around? Chances are that if they do, its 2 or 3. > >Why _must_ one use a Cisco for this? > >-- >Neil J. McRae. Alive and Kicking. Domino: In the glow of the night. >neil(a)DOMINO.ORG NetBSD/sparc: 100% SpF (Solaris protection Factor) > Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A> > > > Geoff Haviland - SEM for PacBell - haviland(a)cisco.com - 510 327 3490

1 0

Re: Plethora of UUnet outages and instabilities
by Steve Mansfield 01 Jul '97

01 Jul '97

> From: Steve Mansfield <steve(a)nwnet.net> > > Probably because the CPU that's overloaded is not the primary Cisco > processor, but an RSP board or somesuch. > > Gee, and all this time I've been thinking the RSP _was_ the primary > processor in a Cisco. Silly me. :) Yeah, I realised the stupidity of that right after I posted it....I have already flogged myself.... ;-) What I *meant* was the processor on th HSSI board... Steve Mansfield steve(a)nwnet.net NorthWestNet Network Engineer 425-649-7467

1 0

Legal Question
by Scott Reubelt 01 Jul '97

01 Jul '97

May not be for this alias but I need to ask. I have an ISP that may be guilty of receiving copies of everyone's emails associated with the ISP. What can be done legally? Thanks, Scott -- Scott F. Reubelt sreubelt(a)whistle.com (http://www.whistle.com)

1 0

Re: Keynote/Boardwatch Internet Backbone Index A better test!!!
by sob＠academ.com 01 Jul '97

01 Jul '97

> Personally, flaws or not, I welcome Boardwatch's attempts > to come up with a widely-published metric for the > Internet. This likely will lead other publications into > similar investigations, some of which may well bring the > writers and editors of various periodicals into contact > with the folks at CAIDA. I agree that it is important that good, scientifically-sound metrics be widely-published. I hope that all such publicity in the future will make reference to the work of CAIDA. From the information available thus far (to me at least), this metric does not appear to be scientifically-sound and the publicity does not reference the work of CAIDA. > Also, flaws or not, Boardwatch did do something > fantastically clever, and that's examining things on an > end-to-end basis, rather than obsessing about details of > what's going on between the endpoints. People concerned > about the abysmal end-to-end throughput of even modern TCP > across much of the present Internet should be rejoicing > and helping other journalists develop better and more > scientific approaches to categorizing expected versus > observed end-to-end performance. I agree that end-to-end measurement is important. As I am certain you are aware, there is work being done to build useful, scientifically-sound ways of measuring end-to-end performance in which the various factors affecting such performance can be described. This will help everyone involved (consumers, engineers and marketers) more effectively understand performance. The Keynote technique does little to break-down these factors. As others have pointed out, this is one of its key flaws. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0