From: Avi Freedman <freedman@netaxs.com> To: Jack Rickard <jack.rickard@boardwatch.com> Cc: mohney@access.digex.net; nanog@merit.edu; GeneShklar@keynote.com Subject: Re: Keynote/Boardwatch Results Date: Tuesday, July 08, 1997 9:40 PM
It would appear that everyone is pretty smugly satisfied by concensus
the performance series we ran actually measures server performance and
since all ISPs run weeny home servers, this was not "really" a test, flawed methodology, etc. I corresponded with Doug the Hump at Digex about
Avi: "Cheating" is of course encouraged. This isn't an academic test at your local university. We're all out of school now. If you can figure out a way to beat the game, you have ipso facto figured out a way to make the web look faster to end users. As it appears to be, so it is. As Martha Stewart says, that would be a "good thing." It would be a good thing for you and your product line. It would be a good thing for your web site customers. It would be a good thing for end-users viewing such web sites. If the net effect of all this is that all the smart people on the net get mad at me and go figure out a way to make the web look faster, it will be well and good enough for me as well. I had previously agreed NOT to publish IP numbers of the Keynote host machines. Keynote does make this information available on their web site, so I myself was a little bemused by the request, but I did agree to honor it. In any event, someone else has already posted the locations and networks (which we DID publish), along with the IP numbers, here on the list. So you should have them. If mirroring/caching moves the numbers definitively, it then establishes a "real" value to such a technique, and it can be offered to customers at a higher price with some actual data comparing how they will "look" to the world using both the less expensive simple hosting as compared to the more expensive geographic mirroring technique. I personally think this would move the numbers more than anything else that could be done, but that's what looks LOGICAL to me, not anything I know or have tested. I am rather convinced that moving a single web site to another location, putting it on larger iron, or using different OS will have very minor impact on the numbers. My own personal theory is a little vaguely formed. But I think the heart of the performance problems lie in a visceral connundrum of the network. It is and should be one network. The perceptual disjuncture I already detect, even among NANOG members, between straight "routes" as viewed by traceroute and ping, and the way data actually moves on the network (at least vis a vis the mental model or "theory" I have of it) is a somewhat shocking part of the problem. I was actually unaware that many of the network engineers actually viewed the world in this way until this exercise. I was even a bit flip about not dealing with ping/traceroute at any level of comparison. Perhaps an article on this is in order. But I think most of it has to do with interconnects between networks, and architectural decisions accummulated over the years based on concepts of what should be "fair" with regards to the insoluble, but ever moronic "settlements" concept and who gets value from whom based on what. If decisions had been more based on optimizing data flows, and less on whose packets transit who's backbones and why, performance would have been improved. I don't know how much, but certainly some. When the main thing on the minds of CEOs of networks is preventing anyone from having a "free ride" (ala SIdgemore's theory of optimizing Internet performance by it being owned totally by UUNET), or the relatively mindless routing algorithm of moving a packet to the destination network at the earliest opportunity to make sure "I" am not paying for it's transit, if it goes to "your" location, I suspect performance suffers. My sense is larger numbers of smaller networks, interconnected at ever more granular locations, would be a good thing. This will get me in big caca with the "hop counting" mind set, and of course at about 254 hops a minor little problem arises, but I think so nonetheless. Very small ISPs know this viscerally. They all want to multihome to multiple backbones, and have done some work to interconnect among themselves locally. Savvis actually has a very interesting concept though it upsets everybody. It kind of upsets me because it makes my head hurt, literally. They've carried it almost to another level of abstraction. If you ponder it long beyond the obvious, it has some interesting economic consequences. Checkbook NAPS lead to an inverted power structure where the further away you move from centralized networks such as internetMCI and Sprint, by blending layers after the fashion of a winemaker, the better your product becomes and the better apparent connectivity your customers have. The head hurting part is that if you extend this infinitely we would all wind up dancing to the tune of a single dialup AOL customer in Casper Wyoming somewhere in the end. But there is a huge clue in here somewhere. In all cases, Savvis numbers were better than the either UUNET, Sprint, or internetMCI numbers individually. Would it then be true, that if there were three Savvis's each aggregating three networks with a private NAP matrix, and I developed a private NAP matrix using the three Savvis level meshes, would my performance be yet better again? And what if Savvis opened the gates and allowed UUNET end users to connect to Sprint IP Services web sites transiting via Savvis network? More vaguely, if you have four barrels of wine with one a bit acidic, one a bit sweet, one a bit oakey, and one a bit tannic, and you blend them all together, it would appear apparent that you would have a least common denominator wine that is acidic, sweet, oakey, and tannic. You don't. You get a fifth wine that is infinitely superior than the sum of the parts or any one component barrel. It is an entirely "new thing." This is sufficiently true that it is in almost all cases how wines are made now. Are networks like wine? Jack Rickard ============================================================== Jack Rickard Boardwatch Magazine Editor 8500 West Bowles Ave jack.rickard@boardwatch.com Littleton, CO 80123 (303)973-6038 voice (303)973-3731 fax http://www.boardwatch.com ============================================================== ---------- that that this.
I've liked this guy since I first met him largely because he's funny and doesn't take himself too seriously. He's got a yen for black helicopters that still has me in stitches.
Humph. Doug the Hump indeed. Well, Alex @ our shop wants an Apache Helicopter for our NOC as well. I'm laughing because I'm not sure anyone's called him that before...
Anyway, I'm thinking of putting www.netaxs.net on one of our core routers :)
Think that'd help?
Actually, what we'd do is make it a loopback interface on all of our core routers and thus you'd hit whatever the closest router to the querying machine is, bypassing much of the network.
Hmm. Have to try that one out.
Anyway, I have to take a look at some of the test sites (saw some of them listed in the new Directory) and see if I can figure out some of the topology of the testing.
Jack - could you put up IPs or whatnot of the sources (the test sites) for people to "tune" and test to?
jack.rickard@boardwatch.com Littleton, CO 80123
Avi