| This is exactly the opposite of reality. In reality, having an IP address does not put you on an equal footing --- in a service model sense --- with other servers or companies that have paid massive amounts of money for peering. BigCo IP addresses are already "super-addresses", because they're BGP-advertiseable, and yours aren't. So long as "full membership in the Internet" means "publicly routable IP address", you're going to get what your ISP is willing to give you and nothing more. This is true even in an IPv6 world! I'm not comfortable with this and you shouldn't be either. IP addresses are what network operators are giving greybeards to geek out over while they continue gobbling up the Internet. What we need to do is accept an IPv4/NAT IP layer, define a minimum acceptable service model for ISPs to offer over it ("access to the web" being a good starting point), and then build application-layer overlay networks that provide the real services applications want, like broadcasting, peer-to-peer, location, presence, automatic configuration, and multihoming. This isn't my crazy pie-in-the-sky idea (though the first startup I personally cofounded got this idea funded for several million dollars during the bubble). Is also the MIT PDOS RON idea, which Paul Graham's friend Robert Morris helped oversee. It is also, for what it's worth, the logical conclusion of Saltzer and Reed's "End to End Argument In Systems Design". When you meet a challenge with a lower-level protocol, the answer tends to be to dumb it down to a point where you can build multiple variants of "something smarter" on top of it.
We're at a point now where IP is simultaneously getting less relevant (organically, as more intelligence moves into HTTP-driven protocols) and more important (as we run out of addresses). The answer is not investing more effort in IP. From a pragmatic perspective, the nice thing about this strategy is that it requires nothing from normal people. They'll use whatever IP their ISP gives them (NAT'd or otherwise), and it won't matter; it'll work just fine for the web today, and it'll work just fine for the TCP/SCTP/whatever-driven overlay networks we come up with tomorrow, where all the real action will be anyways. It's also nice to sit back and not worry about the IPv4acolypse and concentrate on building stuff instead. |
Ok, I often find I need to check myself before calling someone out on hacker news... several times I've found myself arguing with someone who was way more qualified than I was on the subject at hand.
but this is the exact opposite of what I understand "peering" to mean. From what I understand, settlement free peering is just that... it's free. Each party pays for half the cost of maintaining the line between them and packets bound from the customers of one peer to the other and vis-a-vis can traverse that link for free.
Generally speaking, when you pay for transit, it's called transit rather than peering.
(Now, my understanding is that there are cases where you would pay for peering... in this case, say you want to shave miliseconds off your ping time to some stock exchange... you can essentially buy transit that is limited to just the customers of your peer. In this case, there is "settlement" based on the number of packets going one way or the other. But, my understanding is that this isn't how it's usually done. Normally you look people up on peeringDB, and if you are exchanging enough traffic for it to make sense and you are on the same exchange, you set up a settlement-free peering agreement. Of course, all this shit is covered by NDA, so all we really have is hearsay)
Also, uh, all IPs are BGP advertisable. If you are small, your ISP does the BGP advertising (and the peering) I mean, if I buy my connectivity from above.net, they peer with everyone, right? so that's pretty close to me peering with everyone. Now, if you buy connectivity from a poorly connected ISP, sure, your network is going to be slightly slower... but it's still certainly BGP-advertiseable - it's just that you've outsourced the management of that BGP advertisement to your ISP.
Right now I'm working on moving the BGP router into my control, so I'm getting first hand experience with things I've watched people do in the past. And really, unless your primary business is infrastructure (and, well, mine is) it often doesn't make sense for you to run your own BGP router. I mean, it's one of those easy to screw up things. Most places I've worked that did their own BGP had more outages due to the new guy jacking with the router than due to upstream outages (which controlling your own BGP router, assuming you have multiple transit providers, can protect you from.)