From: Craig A. Huegen <c-huegen@quadrunner.com> To: Jack Rickard <jack.rickard@boardwatch.com> Cc: nanog@merit.edu; marketing@keynote.com Subject: Re: Keynote/Boardwatch Internet Backbone Index A better test!!! Date: Friday, June 27, 1997 3:19 PM

On Fri, 27 Jun 1997, Jack Rickard wrote:

==>This assumes that you consider web server location and web server ==>performance to NOT be a part of overall network performance. Our view

But insofar as the article goes, the stated intent was to measure BACKBONE PERFORMANCE, not backbone web server performance.

There is a HUGE difference between the two.

==> I would hope so. Can we break it down into what is purely web server ==>hardware performance, what is web server software performance, what is NIC ==>card on the web server, what is the impact of the first router the web ==>server is connected to, what is the impact of hub design and the interface ==>between IP routing and ATM switching, what part is the impact of ==>interconnections with other networks, what part is peering, what part is ==>just goofy router games? Uh,,, NO we can't.

You *can*, however, come up with a better methodology to attach to your stated intent behind the study; or, if you care to leave your methodology, clear up the misconceptions that your readers will take in.

==>results should factor to zero relatively. They didn't. They didn't to a ==>shocking degree. And at this point I am under the broad assumption

---------- that

==>server performance doesn't account for all of it, perhaps little of it. ==>But I could be widely wrong on the entire initial assumption.

I would challenge that assumption that it accounts for little. The machine the web server is running on, combined with the OS, load average, and even down to the web server software, probably makes up a very good portion of any delays you may have seen.

It may. It may not. It would seem intrinsic that it would. At this point I probably think it won't.

How many times do you go to a web site and see "Host contacted... awaiting response"? When you see that, you have made the network connection and have given your query. Any time you see that at the bottom, it's usually indicative of web server delay. (There is a possibility of packet loss in the initial sent query, but I'd venture to state that it's a very small percentage of queries made to web servers).

==>In any event, the networks have total control and responsibility for

==>own web servers, much as they do for their own network if you define

their that

==>as something separate from their networks. We measured web page downloads ==>from an end user perspective, and those are the results in aggregate. If ==>it leads to a flurry of web server upgrades, and that moves the numbers, ==>we'll know more than we did. If it leads to a flurry of web server ==>upgrades, and it FAILS to move the numbers, that will tell us something as ==>well.

But again, if I were in the business to provide nationwide network service for my customers, and provided my web site as a marketing tool (like most companies out there), I would architect my network so that the customer comes first. The web site could be used for information about the business, but isn't A-1 critical to operation of the network. I'd side with the priori.net folks here in their architecture; that the web server really shouldn't be put into a pop.

Where you choose to locate a web server, and how you choose to operate it, is rather your own affair. I would certainly put my best face on mine, if web hosting had any portion of my business, or if providing dedicated access to people who hosted theirs were any part of my business.

==>Our broad theory is that nothing is going to improve as long as anything ==>you do doesn't count and is not detectable by anyone anywhere. If a ==>particular network can move their results in any fashion, that is an ==>improvement in the end user experience, however achieved.

But the results you publish don't match the study's intent.

Actually, they do. Jack Rickard