I.e. each small ISP's customer derives 99.9% of benefit from the peering, while large ISP's customer derives only 0.01%. Hence, the large ISP can force small ISP to pay up -- without connectivity to a large ISP the small ISP will be dead pretty soon. This is exactly like grocery chains which can (and do) force consumers to pay up for food -- although you can grow your own tomatoes in your backyard and probably sell them to those grocery chains. Good chances are, they're not interested.
Hrm. Does it matter if the small ISP already has transit with someone else? In such a case, peering does nothing but shorten the path from SmallISP to BigISP in order to no longer make it go through SmallISPs transit provider. The 'value' delta is no longer so large; in fact is it possible that it could benefit BigISP by keeping their customers-who-are-local-to-SmallISP from transiting to the nearest BigISP-TransitISP peering point by keeping the traffic local and using the new SmallISP-BigISP peering. So the main objection to free peering is the offloading of SmallISPs traffic onto BigISPs expensive backbone. So if it were possible to have a form of 'local peering' where BigISP could 'locally peer' with SmallISP, meaning that BigISP would allow SmallISP to deliver traffic that was destined for BigISP-customers-local-to-SmallISP directly to BigISP instead of going first through TransitISP and then through the nearest TransitISP-BigISP peering point, then that would seem to make both nice-guy as well as economic sense, assuming that SmallISP is big enough to meet other requirements (like minimal problem-response-time and cluefulness tests, perhaps) To illustrate: SmallISP========TransitISP===================TransitISP/BigISP Peering \\ \\ SmallISP/BigISP_Local_Peering \\ \\ \\ BigISP_POP_local_to_SmallISP===============BigISP Backbone // \\ BigISPcustomerlocaltoSmallISP RemoteBigISPCustomers and in the above illustration realize that the 'local peering' doesn't let SmallISP talk to RemoteBigISPCustomers without going through TransitISP. Now, wait, this is the Internet of the 90s - all the Real Big ISPs use a technique of routing called 'closest exit'. Which, I think, means that they try and get the packets off of their backbone and one step closer to its destination as soon as possible. So, if we further add the condition that both peering sessions above are located at one place (the LocaltoSmallISP Nap, for instance) then the picture starts looking like: SmallISP========TransitISP===================TransitISP/BigISP Peering===TransitISP Backbone \\ / \\ // SmallISP/BigISP_Local_Peering------------+ \\ // \\ \\ // BigISP_POP_local_to_SmallISP===============BigISP Backbone=====BigISP/TransitISPPeering // \\ BigISPcustomerlocaltoSmallISP RemoteBigISPCustomers with the -- link being the (presumably fast) NAP/MAE media. Now, if TransitISP is in fact using closest-exit (aka 'hot potato') routing, then the route to even RemoteBigISPCustomers is the same distance through BigISPs Backbone whether it goes through TransitISP or the SmallISP/BigISP_Local_Peering connection. Outbound. Hrm. So the only extra cost (not insignificant, I realize) is that of the traffic outbound from RemoteBigISPCustomers to SmallISP across BigISPs backbone, which goes that way since SmallISP is peered with BigISP and is therefore 'closer' that way than via TransitISP. Hrm. Is there no metric that can be set to offset this? I admit ignorance of teh finer points of BGP. It's been interesting. --Zachary