On Wed, May 14, 2014 at 9:29 PM, Hugo Slabbert <hugo@slabnet.com> wrote:
So, at the end of the week, I *had* been paying $10/mb to
send traffic through transit to reach the whole rest of the internet. Now, I'm paying $5+$4+$4+$5+$2, or $30, and I don't have a full set of routes, so I've still got to keep paying the transit provider as well at $10.
I would like to agree with you as I'm not a fan (by any stretch) of this type of paid peering to enter access networks, but your formula's off. It supposes that the same bit is traversing multiple paid peering links. The formula (if we ignore commits for now) should be something more like:
C(T) = R(t) * M(t) + R(1) * M(1) ... + R(n) * M(n)
Where: C(T) = total cost R(t) = transit $/mbit rate M(t) = transit mbps R(1) = paid peering agreement #1 $/mbps rate M(1) = paid peering agreement #1 mbps R(n) = paid peering agreement #n $/mbps rate M(n) = paid peering agreement #n mbps
For your $10/mb transit example, suppose we had 1 Gbps of traffic and so our transit cost would be $10,000/month. We take your mixed bag of paid peering and say we give each of those 5 paid peers 100 mbps:
C(T) = 500 * 10 + 100 * 5 + 100 * 4 + 100 * 4 + 100 * 5 + 100 * 2 C(T) = $7,000/month
So, yes, as long as R(n) is lower than R(t), your overall cost should be lower, since you're moving some number of mbps from your higher priced transit link to one or more (slightly) cheaper paid peering links.
Now, as I mentioned, this ignores commits, so it's really more like:
This is exactly where it gets ugly. Pretty much everyone that wants money, also wants minimum commitments in order to keep the link.
C(T) = ( c(t) + R(t) * M(t) ) + ( c(n) + R(n) * M(n) ) Where: c(t) = transit commit $ M(t) = transit mbps over commit c(n) = paid peering agreement #n commit $...I've not personally had to deal with paid peering so I don't know if commit rates are at all common on them, but you can sub or add in other fixed costs e.g. transport to reach the paid peering exchange point M(n) = paid peering agreement #n mbps over commit
So, it starts to get murkier. E.g. if you're not over your transit commit and now you're shifting traffic off of your transit onto paid peering, you may want to lower your transit commits.
You may *want* to lower your transit commits; doesn't mean the transit provider will go along happily with that; they may require turning off some ports, and raising the per-mbit price, throwing your calculations off, as now you're having to haul traffic to centralized hubs to hand off, because you had to shut down transit ports in smaller cities based on your reduced commit level, which can also cause performance issues for users. In the worst case, you get stuck still paying for your transit port (as your need to reach the rest of the internet hasn't gone away), as *well* as the commits for all the individual provider ports.
This also does not account for other potential costs were this type of arrangement to become commonplace, e.g. the additional burden on content providers of maintaining direct business relationships with any access network that would require paid peering for preferential/decent quality.
Again: I'm not a fan of some of the possible abuses or strong-arm tactics of this type of arrangement between eyeball networks and content providers (e.g. running transit or existing peering links hot to push content providers to paid peering to reach the eyeball customers), but the math is not quite so dire as it was made out to be.
-- Hugo
The math *may* not be as dire; but there's no guarantee it won't be, which is the big challenge; working through the scenarios takes multiple iterations, as reducing your transit volumes changes the commit size and pricing on those ports, and may change the count of ports you can maintain; and splitting your traffic up among separate individual links to every access network uses up limited port counts available on routers. There's a lot of factors involved that all working together help provide a strong incentive for transit providers to continue to exist in the ecosystem, which was the main point I was trying to make; while it might be easy at first blush to say "gosh, why doesn't everyone just pay the access networks, bypass the transit providers, and life will be rosy and happy", the reality is that model largely doesn't work out well, as both your math and mine highlight, to differing degrees. But yes, the actual calculations involved are far beyond the realm of a simple NANOG post to completely enumerate. :/ Thanks! Matt