Internet Backbone Index

Peter Cole Peter.Cole at telescan.com
Fri Jul 11 16:11:29 UTC 1997


The users of the net want flashy web pages and better performance.  They
tend to use sites that visually excite them and are respond quickly,
this is human nature.  All commercial sites want a competitive
advantage, such as speed.  Continuously customers are told "Buy more
bandwidth if you want better performance."  Yet link utilization rarely
goes above 50%(in my case).   ISPs and NSPs say that the problem is
overloaded web servers, yet processor utilization has never been
lower(<10%) as more web servers are upgraded to latest Pentium.  Complex
HTML from our local boxes pops up on our screens here, but try it
through our customers ISP.

The lease line users want answers.

The dialup customers want answers.

Both want to use networks that perform faster.  They want to know where
the problems are so that they can avoid them.  If Sprint has an over
utilized T1 to CIX, I want to know. I will let my local engineer and
sales rep know where the T is and if Sprint will not fix it maybe it is
time for me to try a non big name backbone provider.  I think that the
MAEs and NAPs should publish utilization of all ports and that NSPs
should publish link utilization to interconnects as well as long term
plans for their networks infrastructure.  And router CPU stats.

Boardwatch is giving end users what they want some guidance and
direction.  This study is flawed in many ways.  I think that a study of
performance to the top 50 websites and the top 50 ISPs from both Dialup
and leaseline with a web browser and A FTP client would be very
interesting.

Does management want to hide performance figures?  They seem to want it
to be a PR and Advertising war.  NetNow had great graphs of average
delays and performance.  Why is this information now unavailable.  I
guess since I don't have a nation backbone, I can't understand a simple
graph of performance.  Maybe NETNOW should run in Latin.    

BTW I don't want to spend 50,000$ to find out what is wrong with your
networks.

I speak for end users wanting better performance.  Please tell us where
you see problems on your network and others.  

Remember, The better you make the net work the more data we will push
through it and the more you can sell us.


Peter Cole   of   Telescan, Inc.       (281)588-9155
Better computing through lack of sleep.

> ----------
> From: 	Mike Leber[SMTP:mleber at he.net]
> Reply To: 	Mike Leber
> Sent: 	Thursday, July 10, 1997 3:55 PM
> To: 	Gary Zimmerman
> Cc: 	Sean Donelan; nanog at merit.edu
> Subject: 	Re: Internet Backbone Index
> 
> 
> On Thu, 10 Jul 1997, Gary Zimmerman wrote:
> > You talk about engineering good networks, why then use something
> that is
> > unmanaged and uses poor technology and poor engineer designs in a
> MAE or
> > NAP?  Where is most of the packet lost on the internet? MAEs and
> NAPs.
> 
> This is gratutitous and misleading to the journalists and other
> non-network engineers here.
> 
> The packet loss at NAPs and MAEs is caused by providers not upgrading
> the
> size or number of connections they have to/from the various exchange
> points they are experiencing problems at.
> 
> An example of this disingenous usage of exchanges is Sprint's
> completely
> saturated T1 connection to CIX.  There are many other examples.  The
> solution is to not use those routes.
> 
> If a provider is leaking bad routes and flaps continously, would you
> peer
> with them?  Likewise, if a provider has a notoriously saturated
> connection
> to an exchange does it them become a (misleading) casebook example of
> why
> exchange points are bad?
> 
> No and No.
> 
> Mike.
> 
> +------------------- H U R R I C A N E - E L E C T R I C
> -------------------+
> | Mike Leber             Direct Internet Connections     Voice 408 282
> 1540 |
> | Hurricane Electric      Web Hosting & Co-location        Fax 408 971
> 3340 |
> | mleber at he.net
> http://www.he.net |
> +---------------------------------------------------------------------
> ------+
> 
> 



More information about the NANOG mailing list