North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Sprint peering policy (fwd)

  • From: Richard Irving
  • Date: Mon Jul 01 18:53:15 2002

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@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of
> Phil Rosenthal
> Sent: Monday, July 01, 2002 3:27 PM
> To: nanog@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