[trout]

How many of these P2P overlay networks could run without a centralized head/mapping server? BitTorrent has drastically reduced the size of theirs, but it still needs a mapping of other hosts somewhere. Same thing for Skype. I don't want to sign up for an internet where every connection needs a 'head' in order to determine how to traverse the overlay network.

It's probably also not a coincidence that Skype and Bittorrent are two of the hardest protocols to 'control' inside the network. This sounds good from a 'the internet should be a free democracy' standpoint but bad from a 'let's guarantee the performance of the application' standpoint. In terms of visibility into what is happening, being transferred, and where connections terminate there are more productive rather than draconian reasons for understanding those things.

Today with virtual hosting if the website next to you decides to host illegal content, the entire IP is taken down collateral damages or not. Well, that's part of your choice in choosing a provider as an end host. If the entire next generation internet and application space is based on overlays and other nebulous architectures, much of those same problems are going to exist to larger scales, including at transit points. Except it won't be as optional as changing hosting providers.

Since you've got BGP experience - think about the fun in troubleshooting eBGP neighbor problems when every connection is a GRE tunnel that may actually be tunneling through another BGP AS, which itself may be tunneled again. GRE tunnels are great immediate bandaids and generally awful long term solutions for enterprise networks to say the least. But the application guy gets his green light and thinks everything is great.

[tptacek]

These are great points! I'm definitely not saying you could literally take IRC, give it a routing protocol, make it 8 bit clean, and use it as "the new Internet". It would break down in a lot of the ways you say.

I think we don't know enough yet about how to build reliable network topologies on top of reliable datagram delivery to have immediate answers to all of these issues.

I think one baby-step answer is to say, let's start figuring out how to do this on an application-by-application basis. But then, we're already saying that; that's how Skype worked, and Skype was (a) ambitious and (b) worked!

So then:

* I don't think things need to boil down to a single head. IRC doesn't. I remember IRC working even back during the NSFNet split in the mid-90's, when my ISP (Ripco) lost connectivity to university sites. That's because IRC is a mesh of lots of head-end services that leaf nodes rendezvous with.

* Skype and BT are hard to control because they are deliberately designed to be hard to control, because they're P2P (in the late-90's sense) schemes. Their deployment priority was to work in spite of network policy controls, not with them. But that doesn't need to be true of a next-gen system. Can you think of ideas to make protocols easier to moderate and make policy decisions about? I can, but wouldn't want to belabor the point.

* It's definitely true that running a dynamic routing protocol on top of a transport routed by its own dynamic routing protocol is a recipe for byzantine failure. But mitigating that issue is the fact that routing on top of a well-connected (but not completely-connected) transport is a simpler problem than traditional routing protocols handle; I remember feeling silly going through all the contortions OSPF goes through to carefully forward link state from hop to hop, knowing all along I could just be pulling the whole LSA table from a central database.