Peering vs. Transit vs. Profit [was: Overall Netflix bandwidth usage numbers on a network?]

Patrick W. Gilmore patrick at ianai.net
Mon Dec 12 22:21:45 UTC 2011


On Dec 12, 2011, at 5:00 PM, Jason Lixfeld wrote:
> On 2011-12-12, at 4:22 PM, Simon Lockhart <simon at slimey.org> wrote:
> 
>> I guess most (i.e. those
>> which aren't Akamai) are more concerned with making money than with delivering
>> a good service to the end user.
> 
> Really?  I always thought that higher profits and buying transit were mutually exclusive relative to higher profits and openly peering.
> 
> So what you are saying is that one stands to make more by paying upstreams for bit swapping?  How's that work?

You are assuming that peering with $ISP will lower someone's transit bill.  That is demonstrably false in the case of Level 3 who (to a first approximation - please do not argue corner cases) pays no one for transit.

It is also likely false over some set of $ISP_n for some peers.  As a trivial example, if $NETWORK peers with your transit, not only would it not save them money to peer with you, it may cost them money if peering with you endangers the peering with your upstream.  This can happen if $NETWORK does not have enough traffic to qualify for peering with your upstream when your traffic is removed from the link.

So peering does not always equal profit.  Would that life were so simple! =)


> If the argument is that the opex required for maintaining peering relationships is too expensive relative to the direct and indirect cost of buying bandwidth, I love to be edumacated on how that math actually works because it makes absolutely no sense to me.

Peering is not free.  I can easily see the cost of bringing up a port to someone with 10 Mbps costing more than it saves for some perfectly valid network topologies.  And that's just the most obvious example.  The one above is another obvious example.

There are reasons not to peer.  Assuming there are not is a bad way to enter a negotiation.  Put yourself in the place of the other network, figure out what their pain points are - performance, complexity, stability, cost, slot density, spare cycles (human and machine), etc., etc.  To be successful in a negotiation, I submit it is useful to help them eliminate one or more of those pain points, i.e. make it worth their while.

Remember, my company's peering policy (at public exchanges) is "YES".  Since I wrote the policy, you can probably guess my view on peering.  But if simply I assumed no one ever had a reason to say "no", I wouldn't get very far.

There are two sides to every story.  Sometimes the other side is confused, or even flat out wrong, but not always.  And even when the other side is wrong, it may not be useful to bash them over the head with the truth.

-- 
TTFN,
patrick

P.S. I also think "giving good service" is one vital component of "making more money".  But maybe I'm silly.





More information about the NANOG mailing list