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

Fri May 16 02:24:18 UTC 2014

On Wed, May 14, 2014 at 9:29 PM, Hugo Slabbert <hugo at 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