The case for a VPN service

Research & Dev
#1

I’m sure I’m not the first person to consider the possibility of using NKN technology to create a VPN service, but I might be the first to appreciate its distinct advantages over the existing VPN offerings.

Let’s say I’m in France but I want a Japanese IP. With an ordinary VPN, I just switch to a Japanese exit node, and I’m done. The only problem is that the international bandwidth between France and Japan is probably much lower than what I can achieve domestically in France. This limit is often imposed by carriers due to the comparatively smaller bandwidth available when exiting the country. That international pipe might be Tbps in size, but I get only my 10 Mbps or whatever.

But with NKN this gets interesting because I might for example be connecting to 5 nodes near me in France. Each of those nodes probably has about the same 10 Mbps international limit. But now I have 50 Mbps (and just a little more latency). When the connections arrive in Japan, they all land on the same exit node (because I don’t want to confuse the destination server by accessing the same web page with many different IPs simultaneously). Yes, now the exit node has become the bottleneck, but that’s OK because it has high domestic bandwidth to the final destination in Japan. (If the destination is outside of Japan, then it’s my own fault for choosing an inefficient exit node.)

So, qualitatively, I would get domestic bandwidth with international connectivity. That’s a game changer, especially if pay-per-use is an option, so I can pay just when I want to watch Japanese movies, for example. There is no comparable offering from any ISP or VPN, as far as I’m aware, other than to pay a lot more for a fatter pipe, most likely on the basis of a contract with a high setup fee.

It would be so useful to have this functionality in a router. All that’s really needed is a web interface from which to select an exit node. You might even be able to integrate with existing open-source router firmware. I’m not assuming that this is a trivial task, but given the effort involved, it seems like it could really pay off.

At least, please consider it.

#2

You can try out VPN over NKN for mobile, using Android or iOS, the latter currently only available to try from TestFlight.
Android: https://play.google.com/store/search?q=CantinaVPN
iOS: https://testflight.apple.com/join/5bnRwk2L

Feedback welcome.

Bundling this type of service to a router, for example running on OpenWrt, is a nice idea too.

#3

This would be an essential feature if VPN-over-NKN were to see significant adoption. As a practical matter, as much as Android and iOS VPN apps are also essential to making this happen, masking only one’s mobile devices is inadequate from a security perspective. Even if it were confined to only one of the several flavors of open-source router software, such as OpenWRT, that would be a huge leap in the right direction. I personally face this constant problem of poor transborder bandwidth over VPN, and there’s literally nothing I can do about it. No amount of additional local bandwidth or router upgrades is going to make a wit of difference. There are countless other people and businesses faced with the same issue, and none of the existing VPN providers seems able to address it (no doubt because it’s ultimately the internet provider who is forcing per-IP transborder bandwidth limitations).

A much easier first step might be to have an NKN box sitting between the VPN router and the cable modem. I’m not immediately sure whether I could implement that off the shelf, however. Eventually, you would have this same arrangement within a single router device.

One obvious consideration is that NKN would now have knowledge of which real world person was connecting to which VPN node (because one pays for NKN services with a credit card). That’s a nonstarter from a security perspective. This could be fixed by supporting anonymous payments (Zcash etc.) or at least pseudonymous ones (such as NKN itself, or its Ethereum equivalent).

#4

I should caveat all this by admitting that I’m still a bit fuzzy on how much parallelism NKN can actually achieve. If it enforces strong in-order arrival, then it can only choose the fastest of N routes. If it weakly enforces in-order arrival (for example by allowing out-of-order arrival within some particular fixed-size packet group), then it can achieve parallelism up until the threshold at which the fastest route is starved for packets while slower ones catch up. If it doesn’t enforce in-order arrival at all, then it can get full parallelism. I’ve been told that the last scenario is not and will not be the case, due to the O(N) cost of unpermuting the packets on arrival, or worse if some of them need to be corrected or resent.

That said, if one of the NKN nodes connected to me can get double the bandwidth across the border because it happens to be using a more generous ISP, then it’s still a big win.

The point is that even under assumptions of minimal parallelism, VPN service is still a worthy project for ecosystem development. It would have the side effect of creating more demand on NKN nodes, thereby supporting miners. All the moreso because people tend to use VPNs constantly rather than sporadically.