| 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. |