On 3/28/06, Patrick W. Gilmore <patrick@ianai.net> wrote:

On Mar 28, 2006, at 8:42 AM, Peter Cohen wrote:

...

On 3/27/06, andrew matthews <exstatica@gmail.com> wrote:

...

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.

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.

-- TTFN, patrick

P.S. This is not a slam on Peter just 'cause Telia is proud of their RFP response department. If you have to go the RFP route, it's nice to know that there's a network out there who is good at responding to them.

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

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 (:-) (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.?