North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: C&W Peering Problem?

  • From: john heasley
  • Date: Sat Jun 02 23:52:30 2001

so, if it is primarily the content providers that these "de-peer"
rampage folks have their middle finger directed toward; if hosting
provider brand X does content caching close to peering locations
(thus the return path very likely being symetrical and neither party
is hauling the traffic farther than "necessary"), will the "de-peer"
folks consider different ratios or no ratios at all?  ignoring the
how/what part of doing the caching.

Sat, Jun 02, 2001 at 02:24:41PM -0400, Leo Bicknell:
> 
> On Fri, Jun 01, 2001 at 07:28:03PM -0700, Sean Donelan wrote:
> > So, can anyone explain why C&W, UUNET or Genuity care about traffic
> > balance, other than to limit competition by providers who are better
> > at attracting particular types of customers than them?  If you are good
> > at being a webhoster, your traffic will have one profile.  If you are
> > good at being an access provider, your traffic will have another profile.
> 
> There are several reasons to care about traffic ratio.  Where I
> think the mistake is made is that providers are looking at ratio,
> but that the ratios they use are fixed regardless of the type of
> network they are evaluating.  That said, it's hard to get more
> flexable guidelines past the lawyers and bean counters, particularly
> in a large orginization.
> 
> Here's a few interesting cases, first, the ratio problem.
> 
>          A1--------------B1---User
>          |                |
>          |                |
>          |                |
> server---A2--------------B2
> 
> Consider "A" is west coast, "B" is east coast.  User requests flow
> B1, B2, A2, while reponses flow A2, A1, B1.  Provider 1 ends up
> carrying more bits a longer distance, and thus incurs a higher
> cost.
> 
> There are several responses to this argument, each with their own
> problems:
> 
> * That's what you get for building and end user network.  If you
>   don't like it, build a data center network.  Most people don't
>   like suggesting their business model is broken.
> 
> * Use BGP MEDs to make the return route A2, B2, B1.  This moves
>   the cost to network 2, which may or may not be fair.  Many times
>   provider 1 does not trust provider 2 to do this properly. Even
>   when they do, sometimes it is impossible.  BBN and ATT are good
>   examples.  If someone sends you a single /8, you have no choice
>   but to hot potato it out, as meds make no sense.  The only solution
>   is deaggregation, which has a large number of other problems.
> 
> * A settlement should be paid from network 2 to network 1.  This
>   is possibly acceptable, if it comes in the form of a settlement.
>   Often the pricing resembles transit, below.
> 
> * Network 2 should buy transit from network 1.  Most of the medium
>   to large networks are trying to be transit free, and reject this
>   outright.  Also, it's quite likely they would by transit from,
>   well, anyone else just so network 1 doesn't get the money from it.
> 
> There is an important factor here many of the depeering crowd are
> missing.  The overall traffic ratio of your network is more or less
> fixed, and is determined by your customer base.  Unless you can
> convert peers to customers (which I have never seen someone be
> successful in doing on any scale), you will simply move the problem
> around.  That is, if you're 2:1 with Sprint, and depeer 5 10:1
> guys, they may well buy transit from Sprint, moving them to 3:1
> (due to traffic volume).  Now what, depeer Sprint?
> 
> Most people from their billing software can add up all customer in
> and all customer out.  If your ratio is under that number, you will
> _NEVER_ reach it, no matter what you do.  Since individual peers
> will be different, you probably want your limit to be about twice
> your customer ratio, at a minimum.
> 
> This is why I believe you have to evaulate people based on value.
> Consider someone like @home peering with someone like Globix.  One
> is a pure end user provider, that in fact prevents most of it's 
> users from running servers and the like.  The other is a pure web
> hosting company, with lots of content and almost no users.
> 
> These two networks _cannot exist without each other_.  If they
> refused to peer with each other based on ratio, it would be utter
> folly.  Clearly there is great value to both of them in peering,
> even though the ratio may well be 10:1 or higher.
> 
> One of the funniest results of the ratio dance is that it may well
> create more competitiors for a large network.  A tight ratio (eg,
> 1.5:1) is really a requirement that you have a similar customer
> mix, so you have a similar amount of in+out traffic.  How many web
> hosting networks, who didn't want to compete for end users have
> been forced to go after end users big time?  How many access only
> networks have done things to attract server users?  Companies that
> could have enjoyed much less competition have forced people to
> compete with them by ratio.
> 
> Equally interesting to me is the "minimum traffic" numbers that
> many large networks want to put forth.  Some of them are quite
> high, with major networks requiring well over a gig of actual
> traffic to qualify for peering.  This has the effect of pushing
> the restrictive peering policies down to smaller providers.  If a
> smaller provider has a lot of peers, they send less traffic to any
> individual peer.  One of the easiest ways to get that traffic level
> is to pull peering with a bunch of transit customers of the network
> you need to increase traffic with, which of course increases your
> reliance on that paritcular peer.
> 
> One could wonder if some large providers pushed C&W due to the
> lack of traffic between their networks (since we know C&W had some
> issues where they couldn't grow their network last year, and had
> trouble turning up new customers) and that wasn't one of the 
> catalysts for this most recent action.
> 
> -- 
> Leo Bicknell - [email protected]
> Systems Engineer - Internetworking Engineer - CCIE 3440
> Read TMBG List - [email protected], www.tmbg.org