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@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Richard Irving Sent: Monday, July 01, 2002 6:50 PM To: deepak@ai.net Cc: pr@isprime.com; nanog@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@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