Abovenet vs UUnet

So here is the deal, I've delt with both uunet and abovenet (mfn now)
in the past. And a long time ago i switched from abovenet to uunet
when i was with a different company.

Now i'm with a company that has level 3 and Abovenet. Currently the
way the pricing is layed out is by staying with abovenet i'll save
about $1300 over UUnet. Money isn't too much of a concern currently
abovenet is much higher but we are at the time were we need to renew
our contract and we got it with a lower price.

So which way? Abovenet or UUnet.. what are the pros and cons that
you've experienced and what kind of latency do you have over the
providers.

I appreciate your feedback. Thanks

Andrew

So here is the deal, I've delt with both uunet and abovenet (mfn now)
in the past. And a long time ago i switched from abovenet to uunet
when i was with a different company.

Now i'm with a company that has level 3 and Abovenet. Currently the
way the pricing is layed out is by staying with abovenet i'll save
about $1300 over UUnet. Money isn't too much of a concern currently
abovenet is much higher but we are at the time were we need to renew
our contract and we got it with a lower price.

So which way? Abovenet or UUnet.. what are the pros and cons that
you've experienced and what kind of latency do you have over the
providers.

Why don't you put together an RFP that addresses your most important
requirements and send it out to several networks in order to get a
basis from which to compare them, not just on price? I mentioned a
few weeks ago that an RFP would be a good basis from which to compare
different networks objectively, instead of what opinions people might
have with any given provider. Also, where you are could eliminate or
"no bid" some responses due to their congestion, lack of network
there, etc... I hope that helps! There has to be some generic
rfp's floating around the net that you can copy from (or not). Good
luck.

Peter Cohen

Why would someone believe what the networks tell them over what other _users'_ experiences are? You say it is a good basis for comparison, but I have trouble believing that - unless you mean: "A good basis to see which network's marketing department is better."

If I were doing things like leased lines or dark fiber - something more objective and not quite such a moving target - an RFP might make sense. For things like transit, you need real people who know how networks really react to real problems, how networks really pass real packets, how clueful real network NOC techs are, etc., etc. None of these are covered in RFPs (despite what the networks might tell you).

So thanx for the suggestion, but I think I'll stick with _customer_ feedback rather than what the networks want to tell me themselves.

Also, many networks will not respond to an RFP for the levels of traffic people here are considering.

RFP's are a good balance to individual experiences, plus you get
something on paper from which to compare network A with network B, and
how completely/accurately, willingly they answer questions. Use them
both together to get a better methodology for selecting a network.

Every network looking for fiber/colo/transit/etc... is going to be
different, and have a different opinion on what part of their needs is
most important. Put it down on paper, send it out for some responses
and hopefully... suppliers will be honest. Good luck.
Peter Cohen

Those who don't believe that an RFP can work for them don't know how to
write an appropriate RFP.

Clue level is important, but frankly, less important than it used to be, now
that the business of building large IP networks is a more or less known
quantity.

How to assess support? There are plenty of metrics like time to resolve
complaints, and percentage of issues resolved in a single call (very
important). Escalation paths are also an important element of an RFP.

Getting hard numbers on stuff like packet loss across peering and upstream
transit links is important and an RFP is a good way to get these numbers
with more assurance than an email from your sales rep.

Of course, there are plenty of silly RFP questions like "who do you peer
with and where" - with no mention of capacities or utilization!

Even if you decide you don't need to use a formal RFP process to make
your purchasing decision from the dozens of Tier 1, Tier 2, and Tier 3
ISPs that can handle your locations, you might want to do a draft of
an RFP to identify what requirements are important to you and what
requirements are less important.

That's especially true when you're talking about latency - latency
from where to where, at what bandwidths? Some carriers publish
"average" latencies, using statistical methods with dubious
assumptions designed to make them look good (:slight_smile: (My employer's
dubious numbers are about 10ms better than some other carriers'
dubious numbers, but of course I'm not speaking for them and a lot of
the difference is geographical concentration), but for the most part
the dominant factors in latency are average distance (speed of light
in fiber is about 1ms per 100 miles) and insertion delay on smaller
access lines (1500 byte packet takes about 8ms on a T1 - insertion
delay is negligible for T3 and above.) If there's a specific
destination you're trying to get to, then sometimes peering locations
make a difference - if you're in Denver trying to connect to another
Denver location on some third-party DSL, are you going through a
peering point in San Francisco or Seattle or Singapore? If you're
crossing an ocean, does the carrier you're looking at route traffic
across the North Pacific or the South Pacific or both?

Or are you really more concerned about having an abuse desk that
works, or about access line diversity, or is price 90% of the decision
criteria, or are you trying to take advantage of different carriers'
peering patterns, etc.?