Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality (was: Wow its been quiet here...

Hugo Slabbert hugo at slabnet.com
Thu May 15 04:29:12 UTC 2014

>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)

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) )
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.


On Wed 2014-May-14 01:11:30 -0700, Matthew Petach <mpetach at netflight.com> 
>On Sat, May 10, 2014 at 8:04 AM, Rick Astley <jnanog at 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
>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)
>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
>(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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140514/2d60017d/attachment.sig>

More information about the NANOG mailing list