RE: Sprint peering policy (fwd)

From: Paul A Flores <floresp10@cox.net>

Since this is basically a financial issue (and not really a regulatory
issue), the only way you could make it 'fair' is to have some kind of
mandate from a government body to MAKE peering 'fair'. The only way _I_
would buy off on that, would be to have some kind of subsidy paid from tax
dollars to the carriers in question to 'force' them to peer with people who
have no other redeeming value.

You wouldn't buy the notion of reciprical billing? I think this would most likely be the fairest, but maybe the hardest to implement. It would either have to be done at the end points, or at every interconnect. In this method, if the traffic across an interconnect would truely be a 1 to 1 ratio, then the bills would cancel each other out, where the 1 to 1.6 or so would lean in towards favoring the company taking more traffic onto it's network.

It's just a thought, and I am not sure how it would work world-wide.

The RBOCs thought the same when they pushed for recip-comp. The CLECs
in general then targeted ISP traffic and recip-comp became a drain to
the RBOC coffers instead of the boon.

Look at the current recip-comp scenario as an exchange of bits/sec instead
of minutes. Do you really think the model will fare any better in the
IP world? In a peering relationship, each derives benefit. Trying to
pin a monetary value on that benefit will never reach a wide enough
agreement to handle a recip-comp model. I think the current 'bill and keep' model ( which the telco interconnect agreements seem to be trending toward )
works best for Internet traffic.

To put this another way, imagine two networks. One is a large
content provider, they target webhosting customers. One is a large
access provider, they target end-users. I think that being able to reach
a large number of end-users is a benefit to the first network. I also
think that being able to reach a large amount of content is a benefit to
the second network. If they peer, their traffic ratio will be
1:1 yet both networks gain significant ( imho ) benefit. Bill and keep
seems the only sensible way to me.

-Chris

[deleted]

To put this another way, imagine two networks. One is a large
content provider, they target webhosting customers. One is a large
access provider, they target end-users. I think that being able to reach
a large number of end-users is a benefit to the first network. I also
think that being able to reach a large amount of content is a benefit to
the second network. If they peer, their traffic ratio will be
1:1 yet both networks gain significant ( imho ) benefit. Bill and keep
seems the only sensible way to me.

Whoops. I rewrote that part and forgot the 'nowhere near'.

-Chris

These people are highly likely to peer.

The ones not likely to peer with either party are the traditional tier
1's, who would rather have them both as customers and make 2x the money.

As Dan Golding put it, the first 50% of your traffic is easy to peer off.
And that number is only increasing, as more and more networks move to
cheaper and better locations like Equinix, to peer with all the people out
there who aren't tier 1's.

Why favor the company that took more traffic? Why not favor the company that
provided more traffic? Your customers pay you both to delivery their packets
to others and to deliver packets to them, right? If I go to a web page,
presumably the web page owner wants to receive my request and show me his
content about as much as I want to see his content, no?

  DS

I don't see that either.

Whether you do hot potato or cold potato routing, one of the ISPs is paying
more (i.e. number of bits x distance) than the other one.

Simply put, the web hosting content is being delivered to the access
provider either at first or last exit. If its first exit, the access
provider is paying the largest piece, if its last exit, the web hosting
provider is paying the largest piece.

You achieve price symmetry when push/pull ratios match or approach each
other because the amount of bits x distance for each party is more equal.
This is what many tier-1's would consider an equal peering relationship.

Regards,

Deepak Jain
AiNET

Date: Mon, 1 Jul 2002 16:58:10 -0400
From: Deepak Jain

You achieve price symmetry when push/pull ratios match or
approach each other because the amount of bits x distance for
each party is more equal. This is what many tier-1's would
consider an equal peering relationship.

Alternatively, two providers could peer via a { cell | packet }-
switched fabric, splitting the cost.

ISP1: NYC, SJC, CHI
ISP2: LAX, SJC, SEA

A cloud connects the five cities. ISP1 and ISP2 split the cost,
and exchange traffic via the cloud. Suddenly traffic ratios
become less important, and traffic levels become the primary
justification metric.

Eddy

Deepak Jain wrote:

I don't see that either.

Whether you do hot potato or cold potato routing, one of the ISPs is paying
more (i.e. number of bits x distance) than the other one.

Perhaps, but if they are limiting it to their own customers,
which is implied by "peering", as opposed to transit,
it shouldn't be relevant.

They have to carry that traffic to -=somewhere=- anyway,
as the transit customer of -=their=- network paid for it,
as part of the implied contract when purchasing "internet access".

Simply put, the web hosting content is being delivered to the access
provider either at first or last exit. If its first exit, the access
provider is paying the largest piece, if its last exit, the web hosting
provider is paying the largest piece.

  If a provider has a larger network, irrespective of the potential -peers- size,
the probability is -=inferred=- that he will have to carry it further to
get it off his own network, irrespective of "to whom", direct peer, or not.

* shrug *

Hardly an excuse.

This is just a rationalization to shift the burden of the Monkey.

You achieve price symmetry when push/pull ratios match or approach each
other because the amount of bits x distance for each party is more equal.
This is what many tier-1's would consider an equal peering relationship.

  This posture assumes that the customer sending the packet didn't -already- pay
for internet access, and hence transit.

There is a contractual agreement -=already=- in place, implied by buying transit,
that the network in question will carry that packet to the target.

  Should another network extend it's network to pick up that packet,
it should just be a -relief- for the first carrier, or at minimum
the intervening carrier.

  It's that "Monkey on your Back" thing, by not thinking it all
the way through, the large carrier is just shifting the Monkey
onto someone -else's- back.....

  This only -shifts- the burden of the Monkey.... typically
to an intervening carrier...it doesn't eliminate it.
The continuation of this cycle is what no one thinks about....
-someone- still has to carry the Monkey, it's contractually implied.

The Monkey does not go away...

"Out of Sight, Out of Mind" is strictly an illusion.

The large carrier in this case is just making an argument
that it doesn't need to be him.... to his own advantage,
and someone else's disadvantage, always.

"I am so large, and have so -many- paying customers, that
I can't afford to carry my own traffic, it would be too
expensive.... someone else should have to carry it for me."

( Imagine that. )

This is the "Lack of Greenspan Perspective" I was talking about.

A closed looped finite system.

And pretty soon, the -=intervening=- carrier needs to drop
peering because his cost is increasing due to all these
large Monkeys...

So, The intervening carrier demands money from the target network,
so it won't drop peering...

and now, because of the increased flows (Monkeys)....

the Large carrier demands payment for the -=intervening=- carrier peering,
or it will drop it.... since it's network is -so- big...

and so the cycle continues...

If Competitors != NULL.....

For some reason, no one thinks this through much beyond one
carrier.... so hence, IMHO, the common fallacy that was "sold" to the
US Gov't.

  Lets face it folks, if things were fair, we certainly would expect
networks to bear the burden of carrying their -own- packets,
across their -own- fabric for their -=own=- customers,
now wouldn't we ?

We need to break the cycle of pain.

Your argument, specifically regarding customer's expectations vis-a-vis
their purchase agreement has nothing to do with peering and everything to do
with connectivity. A customer has every right to expect connectivity to
Internet destinations, but has no right to tell their provider HOW to do
it -- they simply have the right to decide WHETHER the isp can handle his
packets at all (or say, which destinations).

If a provider is providing connectivity for its customers, the decision to
peer has nothing to do with the customer, provided the customer has decided
to give customer packets to the provider.

If a provider provides excellent connectivity, but for simplicity's sake
does not want to deal with 100 extra interfaces and peering sessions, it is
the provider's option. If this provider becomes big and successful by
following this model because his customers keep deciding to give him
packets, no one outside of the provider's management really has the right to
influence that decision process. If the provider fails, its because
customers haven't decided to provide the provider packets. Either way, the
decision has nothing to do with outsiders.

I can tell you you will save a ton of money by peering with me, but that
doesn't mean you are bright enough to do it. In fact, you are more likely to
suspect my motivations. Plenty of _large_ networks have been screwed by
peering arrangements that take advantage of the topology of the _larger_
network's structure -- I don't think the lesson gets forgotten just because
there is a new crop of small networks that think they are up and comers. We
can talk about big networks failing (financially) all the time, but we don't
even have the time to keep track of all the little networks that made a big
deal about peering with everything they could at a NAP or elsewhere and then
just faded without so much as a goodbye email stating their BGP session
would be going away forever.

I am sure anyone who has played in more than 1 NAP for any length of time
can share 5 stories about how their NOC diligently tried to notify their
peer of each hiccup (initially) then eventually went to notifying peers if
they were down for x amount of time, and then after y amount of time
realized the session wouldn't come back up on its own and started to
research whether the company was even still around.

All of this costs money and energy (people-bandwidth) so you have to decide
is it really worth the bother? Monkeys (as you put it) can buy transit cheap
nowadays. Very few new networks have the level of usage to make a widely
peered (geographically, not # of peers) strategy actually make cost-sense,
so essentially peering with someone who is overextending themselves is just
creating headache for you and your network later. Customers pay a fee that
should include the amount of headache they create. Peering implies (to me)
that each network creates an equal amount of headache for the other, and
hopefully approaches zero over time.

And as was mentioned many times, peering with the easy guys is just that,
people only complain about peering when they try the less easy ones.

And I top quoted.

Deepak Jain
AiNET

1) I am sure we could bounce all our signals off of satellites too. We could
pick a provider for our telecom needs that does not do mileage sensitive
pricing, or we could just buy transit from another provider and run tunnels.
That really isn't the point, you are running over mileage based pipes. If I
don't want to run over a cloud (which is subject to nasty, hard to diagnose
failures) I shouldn't have to. If you can convince your peer to do this with
you, then you don't have a peering problem, do you?

2) The costs of these clouds tend to be significantly more than the cost of
each underlying circuit then there is a management piece on top of it. If
you have small enough usage this makes sense and your peer feels good about
it, then you are great. If, on the other hand, you are connecting your three
routers to the same cloud and peering at a NAP, you are essentially using
someone else's network. This is one of the reason large networks put
pipe-size point-to-point requirements in their agreements -- to specifically
avoid this.

Either way, if your peer likes the idea, you are in great shape. People who
think ATM or FR sucks over long distances won't do it. Anyone who uses a
large cloud like this from another network and finds it reliable, I'd like
to hear from you privately. A few NAPs did things like this for sites within
a LATA, but you still have to like ATM a lot to make it worth it.

The biggest reason this is bad is because of the single point of failure
issues here. A single switch in the cloud loses its marbles and all of your
PVCs, MPLS tunnels, or whatever could bring down your entire peering fabric.
This defeats at least one of the reasons for multiple connections.

Deepak Jain
AiNET

Date: Mon, 1 Jul 2002 20:10:44 -0400
From: Deepak Jain

[ snipping throughout ]

[Y]ou are running over mileage based pipes.

Exactly. And ingress:egress is meant as an attempt to address
the issue, is it not? If traffic flows are "close enough" to
equal in both directions, everyone feels good that nobody is
taking a free ride over the other's pipe. No?

If, on the other hand, you are connecting your three routers
to the same cloud and peering at a NAP, you are essentially
using someone else's network. This is one of the reason large
networks put pipe-size point-to-point requirements in their
agreements -- to specifically avoid this.

Not that Large Network could create a peering fabric via its own
capacity and charge Small Network roughly half (splitting the
cost) for fabric access. In this case, it's not so much "paid
peering" in the standard sense as it is settlement-free peering
and pay-as-you-go geographical expansion.

In the extreme degenerate case, one approaches paid peering. Do
you mean to state that there is no possible way to find a middle
ground between pay-amount-x-to-peer-y-at-any-given-pop and
settlement-free peering?

People who think ATM or FR sucks over long distances won't do
it.

1. Such fabric could be IP-based.

2. ATM and FR don't suck inherently; they work quite well on
   small, bursty interfaces when statmuxed within sane bounds.
   (Don't blame stupid network design on the technology used.)

3. Any provider big enough to have outgrown FR and ATM probably
   can expand their footprint on their own.

Anyone who uses a large cloud like this from another network
and finds it reliable, I'd like to hear from you privately.

Anyone who use(s|d) a large cloud, I'd like to hear... along with
what reliability (is|was). I won't stretch my case so far as to
claim that regional universities sharing a WAN and peering at a
NAP counts...

The biggest reason this is bad is because of the single point

FUD alert!

of failure issues here. A single switch in the cloud loses
its marbles and all of your PVCs, MPLS tunnels, or whatever
could bring down your entire peering fabric.

If designed improperly. And a single router failure could bring
down an entire WAN, if said WAN were designed improperly. Your
point?

Eddy