Re: Internet Backbone Index

[garyz () savvis com (Gary Zimmerman)]

Sean, we only have 805 Mbps of possible bandwidth to other networks.  I not
sure what you mean by a better engineered network.  If you only have a
routed network, not sure this is the best way to engineer a network today. 
Switch technology can do alot of good things. 

The model does fall apart if you say you are only going to buy from these
three to five, but it does not fall apart if you watch your traffic and you
buy from whom your traffic is going to.  The idea is not to engineer poor
peering in the MAEs and NAPs with a bunch of networks.  Buy and manage from
the networks you are going to and you will engineer a better product.  I
still think that if you really looked at a normal NSP traffic that the bulk
of it is with 5 to 8 networks.

I some what agree with some of what you say, that a peer could be a good
thing if it is private and not in a shared peering in the MAEs and NAPs. 
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. 
Where does most of the latency come from? Routers.  MAEs and NAPs are
yesterdays ideas that everyone who has bought into the concept now has to
live with it, they did not build the business around the fact they had to
pay and manage to provide good service.  

The time is almost upon us that you pay for what you get on the internet
and you must pay for the bandwidth that you use, not what you can over
subscribe until your customer begin to leave.  This is a tough model, few
will make it.

Some day the internet will use measurements, such as QOS and customer will
be willing to pay for those who have engineered their networks to provide
QOS.

I only have one more question for you; how many router hops, on your
network, from New York to Los Angeles?  If it is more than 1, then tell me
what your latency is from end to end.  Let's compare, shall we.  

Gary Zimmerman
V.P. of Network Engineering
Savvis Communications Corp.
email: garyz () savvis com
http://www.savvis.com
Office: 314.719.2423
Address: 7777 Bonhomme Suite 1000
               St. Louis, MO 63105


----------
> From: Sean Donelan <SEAN () SDG DRA COM>
> To: nanog () merit edu
> Subject: Re: Internet Backbone Index
> Date: Wednesday, July 09, 1997 5:45 PM
>
> > SAVVIS.  Fortunately Our target markets are not just libraries and other
> > information providers, it's EVERYONE that needs a T1 and above
connection
> > to the Internet.  How many cities are you in Sean, where are DRA's POPs
for
> > customers to access?  How much bandwidth does DRA have to get these
> > customer to other network?  Let's compare bandwidth shall we.
>
> DRA tries to do one thing well, rather than a lot of things not so well.
>
> Like all things, the correct answer is "It depends."  If you are
interested
> in the DRA network geography, a pretty picture of the DRA North American
POPs
> is at <http://dranet.dra.com/dranet.html>.  BTW, all those locations are
up,
> operational, and have DRA owned and operated equipment in place.  DRA's
> international offices are located in Montreal Canada, Paris France, and
> Melbourne Australia.  The primary NOC is in St. Louis, MO and backup NOC
> operates out of Monterey, CA.
>
> Since DRA also has a lot of private connections (in the old NSFNET AUP
days
> these were called 'backdoor' connections) calculating total bandwidth is
a
> bit confusing.  If you follow the AGIS bandwidth counting method, DRA has
> about 268 Mbps of possible bandwidth to other networks through public and
> private inter-connects, although DRA doesn't have any single link faster
> than 45 Mbps.  However, bandwidth is rarely the problem.  I've found a
> well engineered 56Kbps connection outperformed a DS3 port into a poorly
> engineered network.
>
> > When 80 to 90 percent of the Internet traffic is to MCI, SPRINT and
UUNET
> > then our model is the right way to build this, not to try and see how
many
> > peering agreements one can get.  
>
> Except the model falls apart if 50% percent of the your Internet traffic
> isn't just to MCI, Sprint and UUNET, as in DRA's case.  If you want to
> get anywhere off the commercial beaten path, like many of our customers
> do, things quickly get very bad if you stick with just those three
> providers.  Most of our backdoor connections exist exactly for that
reason.
> Look at the KEYNOTE test sites. Although it might appear heavly weighted
> towards MCI, SPRINT, and UUNET (23 out of 35 sites), the network is never
> so simple.  It works well as long as you are in a US city going to
another
> US city.  But looking at the Bell Canada graph, things don't work as
well.
> Hint: If you are trying to reach a Canadian audience, don't put your web
> server in a US city.  We've had a private 'backboor' connection to the
> University of Toronto for years for precisely this reason.
>
> Further, about half the Keynote test sites seemed to have alternate
> connections.  I couldn't figure out the numbers until I started doing
> traceroutes, and then things started making more sense.  You'll discover
the
> best route isn't always through MCI, Sprint or UUNET.  Those little
exchange
> points can make a difference.
>
> St. Louis, MO       MCI           207.230.62.16       Cybercon/Internet 1st
> $ traceroute 207.230.62.16  
> traceroute to 207.230.62.16 (207.230.62.16), 30 hops max, 38 byte packets
>  1  StLouis22-e3.dra.net (192.65.218.2)  200 ms  10 ms  0 ms
>  2  stlouix.starnet.net (198.32.132.12)  10 ms  20 ms  0 ms
>  3  e0-1-2.starnet2.starnet.net (199.217.255.97)  70 ms  10 ms  10 ms
>  4  router.cybercon.com (199.217.252.58)  10 ms  20 ms  10 ms
>  5  207.230.62.16 (207.230.62.16)  20 ms  10 ms  10 ms
>
> It is amusing to look at AGIS's chart in the Boardwatch directory.  The
> graph dramatically demostrates how badly AGIS's tough-line peering policy
> hurt it in this test.  Refusing to peer with CRL or Goodnet wouldn't have
> changed CRL's or Goodnet's performance very much, but it does appear to
> hurt AGIS's performance.  Maybe Sprint and MCI might want to re-think
their
> peering policies also.  On the other hand, I've never heard of CompuServe
> turning down an opportunity to inter-connect their network with other
> networks.
>
> I'm a pragmatic person.  DRA has connections to several exchange points,
> and has many more private 'backdoor' connections to other networks.  DRA
> even buys (gasp) service from a few other providers, and also sells
service
> to a few other providers.  All work well, customers are happy, and DRA is
> profitable.  Let's compare balance sheets shall we?
> -- 
> Sean Donelan, Data Research Associates, Inc, St. Louis, MO
>   Affiliation given for identification not representation