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: 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. 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 On Wed 2014-May-14 01:11:30 -0700, Matthew Petach <mpetach@netflight.com> wrote:
On Sat, May 10, 2014 at 8:04 AM, Rick Astley <jnanog@gmail.com> wrote:
[...] The reality is an increasingly directly peered Internet doesn't sit well if you are in the business of being the middle man. Now if you will, why do transit companies themselves charge content companies to deliver bits? How is it fair to be in the business of charging companies to receive their bits and hand them to a settlement free peer on the hook to deliver them, but not fair for content to just bypass the transit company and enter a paid peering agreement with the company delivering the bits? In this case paid peering is mutually beneficial to both companies involved and is typically cheaper for the content company than it would cost to send that traffic over transit.
What you're missing is that the transit provider is selling full routes. The access network is selling paid peering, which is a tiny fraction of the routes. If I pay transit provider X $10/mb (i know, not realistic, but it makes my math work) to reach the entire internet, it might seem reasonable to pay access network C $5/mb to hand traffic to them, and bypass the transit provider, avoiding potentially congested links.
But then access network A decides they want to cut out the middleman as well--so they do the same thing, run their ports to transit provider X hot; to avoid that, I can pay the cheap price of $4/mb to reach them.
Now access networks F and D want to do the same thing; their prices for their routes are $4 and $5/mb, respectively.
Finally, little access provider T wants in at $2/mb for their routes.
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. Depending on port counts, locations, and commit volumes, your "typically cheaper for the content company than it would cost to send that traffic over transit" has flown completely out the window. It could even end up being many times more expensive to handle the traffic that way.
In order for the costs to work out, you'd really need to apply a formula along the lines of C(n) <= T(n) * C(t) where T(n) =fraction of traffic volume destined for access network X C(t)=cost of transit (ie, full routes, reachability to the entire internet) C(n)=cost of paid peering to access network X
So, if you're an access network and want to charge for paid peering, and you represent 1/20th of my traffic, there's no reason for me to pay more than 1/20th of my transit cost for your routes; otherwise, it's more cost effective for me as a business to continue to pay a transit provider.
I'm constantly amazed at how access networks think they can charge 2/3 the price of full transit for just their routes when they represent less than 1/10th of the overall traffic volume. The math just doesn't work out. It's nothing about being tier 1, or bigger than someone else; it's just math, pure and simple.
Matt (currently not being paid by anyone for my time or thoughts, so take what I'm saying as purely my own thoughts on the matter, nothing more)