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. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
At 02:15 PM 7/1/2002 -0400, Ukyo Kuonji wrote:
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 -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless! \ Director, Engineering | @ @ | \ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Wholesale Internet Services - http://www.megapop.net
[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. --- 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]. Regards, Deepak Jain AiNET
At 03:01 PM 7/1/2002 -0400, Deepak Jain wrote:
[deleted]
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.
---
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].
Whoops. I rewrote that part and forgot the 'nowhere near'. -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless! \ Director, Engineering | @ @ | \ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Wholesale Internet Services - http://www.megapop.net
On Mon, Jul 01, 2002 at 03:01:50PM -0400, Deepak Jain wrote:
[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.
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. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
--- 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
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 -----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
DJ> Date: Mon, 1 Jul 2002 16:58:10 -0400 DJ> From: Deepak Jain DJ> You achieve price symmetry when push/pull ratios match or DJ> approach each other because the amount of bits x distance for DJ> each party is more equal. This is what many tier-1's would DJ> 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 -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
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 -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of E.B. Dreger Sent: Monday, July 01, 2002 5:12 PM To: nanog@merit.edu Subject: RE: Sprint peering policy (fwd) DJ> Date: Mon, 1 Jul 2002 16:58:10 -0400 DJ> From: Deepak Jain DJ> You achieve price symmetry when push/pull ratios match or DJ> approach each other because the amount of bits x distance for DJ> each party is more equal. This is what many tier-1's would DJ> 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 -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
DJ> Date: Mon, 1 Jul 2002 20:10:44 -0400 DJ> From: Deepak Jain [ snipping throughout ] DJ> [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? DJ> If, on the other hand, you are connecting your three routers DJ> to the same cloud and peering at a NAP, you are essentially DJ> using someone else's network. This is one of the reason large DJ> networks put pipe-size point-to-point requirements in their DJ> 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? DJ> People who think ATM or FR sucks over long distances won't do DJ> 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. DJ> Anyone who uses a large cloud like this from another network DJ> 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... DJ> The biggest reason this is bad is because of the single point FUD alert! DJ> of failure issues here. A single switch in the cloud loses DJ> its marbles and all of your PVCs, MPLS tunnels, or whatever DJ> 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 -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
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
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
On Mon, 01 Jul 2002 14:15:21 -0400, Ukyo Kuonji wrote:
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.
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
participants (8)
-
Chris Parker -
David Schwartz -
Deepak Jain -
E.B. Dreger -
Phil Rosenthal -
Richard A Steenbergen -
Richard Irving -
Ukyo Kuonji