UCLA, Cisco and more join forces to replace TCP/IP

Yes, the CCNx was the first implementation of NDN and the NDNx they currently using is fork of it.

AFAIK Parc is still receiving some part of the NSF funding to continue working on CCNx.

The most hardship, from experience, comes from the apps, especially the home-grown ones.

Let me back this up with an anecdote from experience in dual-stacking the websites at my employer (a curious reader might notice that cisco.com, download.cisco.com, software.cisco.com, tools.cisco.com, cisco-apps.cisco.com are all dualstack. The last one is interesting because it hosts the ordering portal, with IPv6 being a transport for a non-trivial portion of the hardware orders).

While the main cisco.com was dualstack since v6 launch, the rest of the properties required more work, because there's bazillion different apps there, so were launched just a ~year ago.

And yet despite all the testing, once we've gone live post-testing, we realized there was one bug that slipped through. The name of the error quite especially ironic and the bug, while in a somewhat infrequently used portion, was very visible for IPv6-enabled users.

http://www.gossamer-threads.com/lists/nsp/ipv6/47796 for the full externally visible recount of the matter.

Back then the % of IPv6 users which was accessing the erroring function was low enough that we did not roll back the entire set of changes, and just had the fix developed and deployed, and the whole scenario was relatively painless. (Besides for some semi-friendly beat-up during IPv6 workgroup in RIPE meeting, where this error showed vividly since we had an IPV6-only pilot WiFi SSID along with the usual dualstack)

If the same story were to happen with 50% of IPv6 adoption ? That would hurt way way more.

The moral:

If you're a big shop - start auditing your apps now even if you do not think you need it until 3 years from now. If you're not sure - there's bazillion resources and people available to help, but for free and for money.

If you're a small shop and don't have any apps - RTFM, assess, and JustDoIt(tm), in a staged manner, of course, all disclaimers apply, etc. - the sooner you get a (small) chance to make your mistakes while doing the first steps with IPv6, the cheaper those mistakes will be. Of course best to avoid them, but.

Ok, I'm officially off my "IPv6 soapbox" on this thread, hopefully these were useful to some folks. ;-)

The NDN was designed based on today's most common Internet use cases. If you think about it, most of the time we are requesting content from specific place, but we don't really care where the server is located, what address it has etc, all we care about is the content and whether it comes from intended (trusted) source.

Assuming that the same name always references the same data, gives an edges, because now routers are aware of the data so they now have ability to cache the content locally and when someone else requests the same thing they can just forward what they have without having to ask uplink about it.

It gives an edge in certain use cases. Probably the biggest ones would be YouTube, Netflix etc. There is a lot of effort on TCP/IP network to provide great experience for the user, through CDN, any cast routing, and other tricks, with NDN you already have network that is very friendly and makes CDN unnecessary as long as you design your protocol in such way that you utilize network's properties. Another nice advantage is on lossy networks like wireless ones. For example when you requesting content which goes through many hops if there if the response was dropped, thanks to caching it can be resend from the same point it was dropped without having to go back to the source. This might also help in such network when the consumer is on the move. NDN also has some nice properties, if for example certain name is set up in such way that can be shared by multiple parties, then it is possible to implement a chat without need of any server, which is quite cool.

Given these benefits the NDN is a two edged sword though, while it makes content publishing to many people simple it makes certain tasks harder. For example implementing something like ssh over it might be a bit difficult. In fact anything that benefits from pushing data/request (simple example from one of the project - controlling lighting infrastructure) will be complex. It is still possible to implement but it is harder to do than in TCP/IP.

As for adaptation, it is hard to say. It definitively won't be easy. The protocol is not a drop in replacement for TCP/IP everything needs to be reinvented again. You can possibly convert existing applications to work with it, and in fact it should be possible to carry TCP/IP over NDN but then you're losing all of the nice properties of the protocol. Some things would work better, for example stripping TCP/IP and having HTTP protocol implemented on top of NDN. Some people already created NDNHTTP gateway.

On the other hand it could be extremely beneficial with specific use cases we are somewhat struggling with, like multicasting of video. One strong point of it is that the protocol can be implemented on top of TCP/IP, and in fact that's how NDN testbed is (or at least was when I was there) implemented currently. The adaptation goal is to have a network built on top of TCP/IP and as it grows and is big enough eventually the TCP/IP layer below will collapse and NDN will take its place. That's of course assuming the NDN will handle all of our needs that will make TCP/IP unnecessary, otherwise it'll be just an overlay network. They also try to avoid other mistakes of IPv6 and concentrating on making it attractive not just technically but also from a business perspective. That's why they are also partnering with vendors.

Source: I actually was involved in NDN between 2010 and 2012. And know people mentioned in the article in person. One of my projects was video streaming over NDN.

The people who are involved in NDN had also huge part in making the current TCP/IP work.

For example Van Jacobson, whom started the idea and made huge contributions, one of them was implementing congestion control in TCP/IP. Some people don't know but in early 90s the Internet actually collapsed under the traffic and was practically unusable until his fix.

Lixia Zhang for example was working on TCP/IP since 1981 she was responsible for Resource ReSerVation Protocol (RSVP), which is implemented by almost every major router vendor today for Internet resource management and traffic control applications.

Most of the time we do care about (not!) exposing information to third parties. This even applies to generally lower-importance scenarios such as watching YouTube and Netflix videos.

ISPs are of special importance, because the exposures can be concentrated. We make use of end-to-end encryption with specific servers in order to reduce the information that ISPs (and others) acquire. How will we hide interest data from ISPs in an NPN world?