nanog mailing list archives

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


From: Hugo Slabbert <hugo () slabnet com>
Date: Wed, 14 May 2014 21:29:12 -0700

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)

Attachment: signature.asc
Description: Digital signature


Current thread: