Sprint peering policy (fwd)

Mon Jul 1 23:25:55 UTC 2002

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

-----Original Message-----
From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu]On Behalf Of
Richard Irving
Sent: Monday, July 01, 2002 6:50 PM
To: deepak at ai.net
Cc: pr at isprime.com; nanog at merit.edu
Subject: Re: Sprint peering policy (fwd)

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.

> Regards,
>
> Deepak Jain
> AiNET
>
> -----Original Message-----
> From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu]On Behalf Of
> Phil Rosenthal
> Sent: Monday, July 01, 2002 3:27 PM
> To: nanog at merit.edu
> Subject: RE: Sprint peering policy (fwd)
>
> ---
>
> If they peer, the traffic ratio will _NOT_ be 1:1, more like 10:1 or
> 1:10 [depending on which way you are looking].
>
> ---
>
> It will not be a 1:1 push pull ratio, BUT it will be 1:1 in a "expensive
> part of ISP1:expensive part of ISP2" ratio...
>
> --Phil