UUNET Pulling Peering Agreements & replacing them with charging under non-disclosure?

Fri May 2 17:46:56 UTC 1997

In message <199705021656.JAA25880 at typo.org>, Wayne Bouchard writes:
>> The argument about national backbones costing money is a red herring.  OF
>> COURSE they cost money.  But they open business markets to you that are
>> otherwise closed - being able to sell in multiple cities without the custome
>r
>> having to backhaul on their own, VPNs across geographical areas, etc.  If yo
>u
>> don't like the price:performance balance of that equation, then you shouldn'
>t
>> build one.
>
>Well, this goes into "cutting off peers means your customers can't
>access mine." There's two problems with this: First, the key point is
>YOU can't access THEIRS without buying transit. Most ISPs aren't gonna
>permit this loss of connectivity and will buy transit.. it just won't
>be from the company that pulls the plug. Lets also note who its gonna
>hurt more.. the company with fewer customer sites that need to get
>accessed. The complaint ratio between the two groups are gonna be
>wholly lopsided. The smaller ISP will receive far more complaints than
>the larger one.
>
>In my view, whats being proposed has more or less been in the works
>for quite a while. Because of the customer's demands for 100%
>connectivity, there's not a whole lot to stand in the way. And as long
>as MFS/UUNET/WorldCom run the two biggest exchange points (and are
>thus getting paid exorbatant amounce for connectivity INTO that NAP --
>thus making it so you really pay *3* times for a packet to cross the
>network -- along with various customer circuits into that NAP because
>of the "near exit" -- making it actually 4 times if you consider loop
>charges), there's no reason it can't continue. If it happens, it
>happens. And chances are that these peering fees will be quite
>high. For the big guys to buy from each other, the fees will more or
>less balance out. For those that depend on the peering, they'll have
>to bite the bullet and pay the fees. For those who can't afford the
>fees, they'll have to look for cheap transit (and possibly degraded
>service as a result). I doubt there will be any who can't afford
>transit.

Based on the models I've run, the cost of peering should work out
to a charge based on the cost of transit/ratio of customer networks/
non customer networks for the "larger ISP", i.e.:
ISP A charges 60,000/month for a DS3, say the
announce as customers 20% of global routeable IP, thus
peering charges should be about 1/5 of that $60,000, or
$12,000.  Assuming ISP B charges $2000/month for a T-1, and announcies
about .1% of global routeable IP space, or $2/month. So net
cash flow between A and B is about $11,998/month.  This doesn't
include local loop charges, port charges, or the issue of different
network design may result in different costs of peering.
If the provider charges $20,000/month for DS3, then  somewhere on
the order of $4000/month would be a reasonable peering charge.

At some point charges between differently sized networks will happen
as the cost structures have to be balanced or it will not be
viable in the long run.  However that doesn't meen that NDAs and
outrages peering charges are justifable.  And if people
use an exchange point and a route server, the costs of peering for
large national providers could be reduced, and provide their
customers better service, and be compensated for their real costs
to do peering.

All of the information to do the cost calculations is publicly
available information, and unless some large ISPs are not being
held to the same 80% utilization standard, (AGIS anyone?), then
there isn't any real market distortion by using routable IP addresses.
And its a lot easier than counting aggregate packet flows.

If worse comes to worse, some large national provider will institute
a policy similar and the rest will face the Net99/CIX scenario all over again.

---
Jeremy Porter, Freeside Communications, Inc.      jerry at fc.net
PO BOX 80315 Austin, Tx 78708  |  1-800-968-8750  |  512-458-9810
http://www.fc.net