Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Parent Full thread

I think network operators should have about as much say in what service models Internet protocols should support as the telephone companies do about what apps run on Android and iOS.

I think large open source projects (like BitTorrent) and startups should start thinking about applications that build their own connectivity layer on top of IP, and that don't assume any two nodes will have direct IP connectivity. Obviously, this is already true of the Internet we use today, because a huge percentage of hosts don't expose direct connectivity for reasons of security (not addressing scarcity --- there are companies sitting on /16s that static-address every desktop, but allow none of them direct Internet connectivity).

If you believe TorrentFreak, BitTorrent accounts for double digit percentage points of all Internet traffic. BitTorrent is an overlay design (albeit not one that reliably avoids the need for direct point-to-point connectivity, unlike the Gnutella overlay). We already know designs like this are tenable. I'm saying we should explore them further as alternatives to an Internet design controlled by giant telecoms.

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.

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.

Nobody objects to building layers on top of TCP/IP. We've been doing that forever. I think we are all very confused by the idea that a layer built on top of TCP/IP will replace TCP/IP? It just doesn't make sense.

He's saying it will replace the need to replace IPv4 with IPv6, not that it will replace TCP/IP.

Actually, I'm saying we should replace IP, in the same way that IP "replaced" X.25 (if you want to call Frame Relay the successor X.25) by relegating it to a layer 2 connectivity technology.

I'm saying it would be great if all web pages were delivered over an overlay protocol running on top of some TCP friendly transport provided by an overlay; a "peer to peer" routing system like Skype.

The simplest way to describe the architecture I'm talking about is, "what if you made IRC a modern, fully routed binary connectivity fabric, then tunnelled the Internet over it?"

TCP/IP is peer to peer, and IRC is built on top of TCP/IP. Maybe I'm just misunderstanding your proposal, but it seems like what you want to do is what we already have.

Yes, you're misunderstanding, because I am not being clear.

I'm not saying we get rid of IP (I'm not talking about TCP at all, for what it's worth).

I'm saying, we stop trying to make IP better, accept it for what it is, and building something better ON TOP OF IT.

But why not do both? Honest question?

Because IPv6 is extremely expensive.

But don't get me wrong: I'm not on a crusade to get rid of IPv6, and overlays work just fine on IPv6. I'm just on a crusade to put it into context.

Thanks for clarifying. You should have started out with that.

I agree; I wanted to avoid repeating previous comments from older threads, but that was a bad call.

Reply on news.ycombinator.com