- NANOG - lists.nanog.org

Re: Bay Networks in bed with commie censors?
by Vadim Antonov 16 Jan '97

16 Jan '97

Matt Ranney <mjr(a)wacky.eit.com> wrote: >So if a bunch of Commies came over to your office with a dump truck >full of money and said, "So comrade, we need IP networks that are the >fastest they can possibly be. If we dump this in your lobby will you >help us?" I'd tell them to get a hike. Did that many times, actually, and not in safety of an American office. >You'd say no? What if they just bought a bunch of Cisco routers on >the open market without any special deal? Should Cisco turn that >money away? Look, it is impossible to keep technology from being used by communist regimes. Like it's impossible to keep knives from hands of murderers. But what do you say about a person who gives a knife to a known murderer knowing very well that it is going to be used to kill yet another victim? And teaches him how to wield it more efficiently? And gets paid for it? --vadim

1 0

Re: Bay Networks in bed with commie censors?
by Dave O'Shea 16 Jan '97

16 Jan '97

> > Ok, it looks like Bay Networks made a sweet deal with > Chinese commies. Essentially, they will provide > technology for the state propaganda network and > censored Internet. Personally, I think Bay does make for more easily-modified access control; with Cisco, removing one IP from an Access List From Hell is usually too much task to be worth it. And if I could have undersold Bay by a percent, I'd be doing the Taipei Tango whilst plugging away on a 7513. > > Their "partnership" with censors of a communist regime > is repugnant. Using the modern technology to build a > giant brainwashing machine is very scary. Actually, few brainwashing schemes could beat what Madison Avenue churns out. When you can get the American public thinking that a certain type of shoes or jeans will make you socially acceptable, you've got the Chinese beat pretty bad. Mao Tse Tung ain't got nothing on the Marlboro Cowboy. > > Some companies will do anything for a buck, though. The corporation exists maximize shareholder value; the good press from the sale (and the sale itself) obviously outweighs the risk of bad press. > > How about boycotting their products in U.S. and other > democratic countries? I dunno; suppose I boycott every company that sells to some organization that I find repugnant? Pretty soon, I won't be able to find a car to drive, a grocery store to shop in, or a telephone to talk on.

1 0

Re: Bay Networks in bed with commie censors?
by Paul Ferguson 16 Jan '97

16 Jan '97

At 03:21 PM 1/15/97 -0800, Michael Dillon wrote: > >Have you changed from a Soviet imperialist into an American imperialist? >Don't you realize that parallelism can be exploited in politics as well as >in routing? Create millions of small opportunities for Chinese people to >share information and they will do the rest. > Can we move this thread entirely to com-priv, please? Somehow, this reminds me of Godwin's Law, and a couple of associated corollaries: "As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one." - "Godwin's Law of Nazi Analogies", Mike Godwin, EFF staff counsel. "As global connectivity improves, the probability of actual Nazis being on the net approaches one." - "Van der Leun's Corollary to Godwin's Law", Gerard Van der Leun, former EFF Cambridge office director. This corollary is already proven. "Thread bandwidth consumption increases in inverse proportion to thread content quality." - "McCandlish's Second Corollary to the Wilcox/McCandlish Law", Stanton McCandlish, EFF online activist; 1995. On second thought, this thread actually reminds me of Sturgeon's Law: "90% of everything is crap." - "Sturgeon's Law", Theodore Sturgeon - paul

1 0

Re: Bay Networks in bed with commie censors?
by Selina F. Priestley 15 Jan '97

15 Jan '97

Can we move this thread to com-priv only? I got enough to read. Or at least maybe you could discuss primatology, which at least I find interesting. Thanks, Selina > On Wed, 15 Jan 1997, Vadim Antonov wrote: > > > Their "partnership" with censors of a communist regime > > is repugnant. Using the modern technology to build a > > giant brainwashing machine is very scary. > > Since you are a person that saw up-front and close the democratizing > effects of a telecommunications network on the democratization of a > communist country, I find this a rather surprising statement. > > The network will let more Chinese citizens communicate with each other > than ever before. And I strongly expect that there will be dozens of > gateways between this "intranet" and China's Internet providers. > > You, of all people, should realize that withholding commnications > technology sterngthens and isolates communist regimes. But hooking them > into the global capitalist economy at the state level will eventually pay > dividends by creating a bourgeois class (the educated middle class) which > will force democratization to occur. > > Not everybody follows the U.S. model of democracy, for instance Canada > does not. But that doesn't mean we aren't free and it doesn't mean we > aren't happy. > > Have you changed from a Soviet imperialist into an American imperialist? > Don't you realize that parallelism can be exploited in politics as well as > in routing? Create millions of small opportunities for Chinese people to > share information and they will do the rest. > > Michael Dillon - Internet & ISP Consulting > Memra Software Inc. - Fax: +1-250-546-3049 > http://www.memra.com - E-mail: michael(a)memra.com >

1 0

NetSCARF Workshop Sunday (1-5PM) before NANOG
by William B. Norton 15 Jan '97

15 Jan '97

Hi all - The Merit Network Statistics Collection And Reporting Facility (NetSCARF) Project will be hosting its *second* free workshop in the afternoon on the day *before* NANOG in the San Francisco Grand Hyatt Grand Ballroom. We will provide an overview of the (2.x and February release 3.0) technology (see agenda below), future release plans, and open the floor to feedback and discussion about how you would like to see the product evolve. The NetSCARF SCION software package is a public domain network statistics collection and reporting package that uses SNMPv1 or SNMPv2u to collect stats from network devices and reports the network performance on the web. Release 3 is scheduled to be released early February and features real-time display of certain data, "clickable graphs", an administration and installation tool and security mechanisms to restrict access to network statistics. For this second workshop, we have openings for the first hundred (100) that register at http://www.merit.edu/~netscarf. If you get a chance, read the Connexions NetSCARF article on our web page before the workshop. If you have any questions, please feel free to e-mail me at ala(a)merit.edu or call at 313.763.6378. Thanks, -Andy Adams ======================================================================== NetSCARF Workshop Tentative Agenda - February 9, 1997 1-5PM ------------------------------------------ Welcome, Model and Rationale - Bill NSFNET Operations 3 Graphs of proven utility Proposal to RAC Architecture Overview - Andy NetSCARF Model - abstractions, functionality divisions, etc. New Features Scollect Component - Bill SNMP Overview Scollect Task Storage of Stats: Rtdata Tree Scook Component - Tom Motivation behind aggregating data (statistics on file sizes, etc.) The four aggregate files e-mail report Administration Tool - Tom Functionality ScServer Component - Adam Highlighting new security features Functionality ScClient, Scache Component - Bill, Andy & Eric Highlighting new real-time display of some data Highlighting the clickable bar/pie chart How Existing Reports are generated NetSCARF Futures - Discussions - all Our visions, customer visions -------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (313) 764-9430

1 0

Whois InterNIC?
by Chris A. Icide 15 Jan '97

15 Jan '97

Thanks for the hundres of hints on that AS6245. For those that think me stupid. I had a routing loop to the InterNIC, and the only info I was able to dredge from the tools I had at the time were the origin AS. Thanks for the info from everyone, we greatly appreciate the test of our office mail server. P.S. whoever was the first one, you helped me figure out the problem, thanks. Chris A. Icide

2 1

Re: Questions about Internet Packet Losses
by William Allen Simpson 15 Jan '97

15 Jan '97

> From: Bob Metcalfe <metcalfe(a)infoworld.com> > Is Merit's packet loss data (NetNow) credible? The measurement needs more data points located inside other providers, but is pretty accurate regarding links into and out of the major NAPs. > Do packet losses in the > Internet now average between 2% and 4% daily? This is nothing new. In fact, it used to be much worse. Remember 1986? 1989? 1994? We've had pretty serious loss rates at times. > Are 30% packet losses common > during peak periods? I've personally measured 40% pretty regularly, and 80% at times. But it is much better now than a few years back. > Is there any evidence that Internet packet losses are > trending up or down? > Losses are on the rise again (past few months), but there was a downward trend during 1996 for my own connections. I specifically saw MCI and Sprint put in faster links last year, and add more private interconnects. Improved my life immensely. > Were Merit's data correct, what would be the impact of 30% packet losses on > opening up TCP connections? TCP will keep working. It's much harder on UDP, as the UDP applications often aren't very good on recovery. Lots of applications use UDP that should have used TCP. TCP is very robust. > On TCP throughput, say through a 28.8Kbps > modem? Compared to what? I remember using TCP pretty well over 300 bps and 1200 bps modems. Even at 28.8 Kbps, the delay in the modem swamps the delay of the net. > On Web throughput, since so many TCP connections are involved? The Web is actually a major source of the problem. It was not very well designed, protocol-wise. It causes rapid transient congestion. > On DNS look-ups? Yes, DNS uses UDP, and fails a lot more often. So, I just try again. > On email transport? SMTP uses TCP, and still works great. Neither delay nor packet loss are an issue. > How big a problem is HTTP's opening of so many TCP connections? It is a terrible problem. There is no time for the congestion and round trip estimation algorithms to kick in, as each connection is so short. But, HTTP is being fixed. > Does TCP > need to operate differently than it does now when confronted routinely with > 30% packet losses and quarter-second transit delays? No. It works fine. BTW, 1/4 second delays are not a problem; as I said earlier, this is actually better than we had when we developed the code, 2 second delays were typical in modems (576 byte payloads at 2400 bps). > What is the proper > response of an IP-based protocol, like TCP, as packet losses climb? Try > harder or back off or what? Exponential backoff. This is all well described by Van Jacobson nearly a decade ago. This kind of question is what makes folks think you haven't done your homework, Bob. > How robust are various widespread TCP/IP > implementations in the face of 30% packet loss and quarter-second transit > delays? > BSD 4.4 and derivatives work fine. Newer implementations with Sack work a bit better. Karn's KA9Q stack (used in many small enterprise routers and some MS-DOS hosts) is even more robust, as it was developed for amateur radio. High losses and high delay are typical in radio. FTP Software's stack seems to perform very well, and they update it regularly. MacTCP is terrible. And many early WWW servers and clients were Mac based, so they have terrible TCP characteristics. But, they still actually worked! But Apple replaced MacTCP last year with Open Transport, which works much better. Everyone should upgrade to MacOS 7.6. I've also had some problems with Win'95, and actually removed it and went back to Win 3.1. Since I gave up on it, I never really got to the bottom of why it was performing so badly. As an ISP, we actually charge more to setup folks with Win'95, while we charge nothing for Macs with Open Transport. Amazing difference in user support costs. I've noticed that there are a rather a lot of old SunOS systems out there. They don't have modern versions of TCP/IP, with MTU Discovery et cetera. But they should have been upgraded years ago, and are probably about to fall over anyway. > Is the Internet's sometimes bogging down due mainly to packet losses or > busy servers or what, or does the Internet not bog down? > Busy servers is the worst problem I've had in the past year. Much worse (more frequent) than the packet losses. > What fraction of Internet traffic still goes through public exchange points > and therefore sees these kinds of packet losses? What fraction of Internet > traffic originates and terminates within a single ISP? > >From personal experience at my clients, virtually all traffic is distributed across multiple providers. Hardly any is local. This has always been true of email, and is also true of WWW traffic. But as far as I know, there is no serious data available on internal versus external traffic of ISPs. In the ISP I partly own, most of the traffic is external. Where dial-up users POP their email from the server locally, the email still came via other providers to the server. > Where is the data on packet losses experienced by traffic that does not go > through public exchange points? > As far as I know, there is no data on how much traffic goes through public versus private exchange points. But, we should encourage more exchange points of every kind. > If 30% loss impacts are noticeable, what should be done to eliminate the > losses or reduce their impacts on Web performance and reliability? > The losses are noticable. What _should_ be done is fairly well known. We've been talking about it for years. I've been fairly active on the topic. Link speeds do not increase at the rate of Internet traffic. Merely making the links faster is doomed to fail. Routing performance will not increase at the rate of Internet traffic. Merely adding links between the same places is doomed to fail. Resource reservation on already congested links is doomed to fail. Resource reservation on many short flows is doomed to fail. We need providers to share faster links, such as inter-continental. By the very nature of Internet traffic multiplexing, it is better to share one bigger link than many smaller ones. Traffic shaping would ensure each provider getting their "fair share". We need more exchanges, both public and private. There should be one or more major public exchanges in every metropolitan area. Massive parallel inter-connections. More robust in the case of link failure and as backhoe protection. It's the only way we can scale at the rate of Internet traffic. Unfortunately, both these solutions require cooperation, which is in short supply. > Are packet losses due mainly to transient queue buffer overflows of user > traffic or to discards by overburdened routing processors or something else? > Most of the packet losses I see and have verified are _link_ underprovisioning! That is, providers have sold more subscriber connections than they can carry to other providers, and subscribers have bought links that are too small for the amount of traffic they generate. I've seen the provider version of the problem a lot more often than I've seen the subscriber problem. > What does Merit mean when they say that some of these losses are > intentional because of settlement issues? In some cases, the decision to keep the small congested link to other providers appears to be political and deliberate. > Are ISPs cooperating > intelligently in the carriage of Internet traffic, or are ISPs competing > destructively, to the detriment of them and their customers? > Major ISPs are not cooperating very well. Regional ISPs are doing a better job of cooperating. There are plenty of examples of both. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

4 3

Re: AS 6245 announces route for Internic?
by Paul Ferguson 15 Jan '97

15 Jan '97

At 03:48 PM 1/15/97 -0600, Chris A. Icide wrote: >I'm receiving announcements for Internic routes via AS 6245. Anyone >have any idea who this might be? It's a little difficult for me to get >contact information from rs.internic.net right now. > InterNIC Registration Services (ASN-INTERNIC) Network Solutions, Inc/SAIC 505 Huntmar Park Drive Herndon, VA 22070 Autonomous System Name: INTERNIC Autonomous System Number: 6245 Coordinator: Kosters, Mark A. (MAK21) markk(a)NETSOL.COM (703) 742-4795 (FAX) (703) 742-4811 Alternate Contact: Crichlow, Allwyn F., III [CSR] (AFC3) allwync(a)RS.INTERNIC.NET (703) 742-0400 ext. 891 (704) 742-4777 (FAX) (703) 742-4811 Record last updated on 01-Feb-96. The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. - paul >Yorktown>sho ip bgp 198.41.0.12 > >6082 6245, (aggregated by 6245 204.70.200.82), (Received from a RR-client) > 192.41.177.73 (metric 3) from 207.7.0.34 (207.112.248.129) > Origin IGP, localpref 100, valid, internal, atomic-aggregate, best > >Chris A. Icide >Nap.Net, L.L.C. >

1 0

UUCP node name information search.
by Alan Clegg 15 Jan '97

15 Jan '97

I hate to do this, BUT... I am doing research for a court case that has pretty serious ramifications. See <http://www.gateway.com/release.htm> for more info. I am looking for proof (USENET postings, ancient maps, or even private e-mail) showing my use of the UUCP node name 'gateway' prior to 1989. Unfortunately, I do not have the 'original' submission for the registration of the node, and the current maps only show date of last update (1990 when gateway.com was registered). If anyone has documented use of the UUCP node name 'gateway' from that era, PLEASE PLEASE PLEASE let me know. Many thanks, -abc, offering a free 9-Track tape of 'mod.sources' dated 1987 to the person that finds the first proof. | Alan Clegg The Internet is not for sissies. [paul(a)vix.com] | Network Guy | gateway.com, inc.

2 1

Re: PacBell
by Thomas Novak 15 Jan '97

15 Jan '97

Brian / Ted I called 415.542.9000. All I can say is give it a try and asked to be transferred to new lines section _Thomas >----- Begin Included Message -----< Brian Horvitz was caught stating: > > Does anybody have a good phone number for PacBell where I can get SMDS = > info? I'm in Boston and haven't had the pleasure of dealing with them = > yet so I figure I'll call the number on the web page...no good, all the = > 800 numbers I've found thus far are disconnected. Hey Brian, fancy meeting you here :) You can try PacBell's Frame Relay/SMDS Noc # - 800-870-9007 -- Ted Beatie ted(a)uu.net Systems Engineer ..uunet!ted UUNET Technologies, Inc., 3060 Williams Drive, Fairfax, VA 22031 "the number of people in the United States who would not recognize the phrase 'Beam me up, Scotty' is roughly comparable to the number of people who have never heard of ketchup." - Lawrence Krauss >----- End Included Message -----<

1 0