8 ms·

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

98 points by ossama 12y ago

jrapdx3 12y ago
Maybe it's just my nature to be guarded about grand visions, but does this idea really have a good chance of succeeding? Will it displace TCP/IP given the extent of IP deployment around the world? No doubt there are people here who are network experts who can give a more learned review than I can after quickly reading the overview on the website. I have a lot to learn about the subject...
- fla 12y ago
  I am no network expert, but I guess their idea is to optimize the traffic in-between endpoints. The last segments (you <-> ISP) would still be using TCP over IP.
- tgflynn 12y ago
  Though I'm hardly a networking expert I did some contract work implementing NDN simulations so I probably know a bit more about it than most people. I'm highly skeptical that data entities provide a better (or even adequate) base abstraction for networking than network addresses associated with physical machines (ie. hosts, routers, etc.). It seems to me that the problems NDN wants to solve, primarily content caching, would be better addressed at a higher abstraction level, as I think CDN's already do. This is my opinion, and I'm certainly open to being proved wrong by more qualified viewpoints. As for the likelihood of NDN ever (a word I would almost never use, especially in regards to technology) replacing TCP/IP, it seems hard to believe given the extreme slowness with which IPv6, a comparatively minor change, is being adopted.
- takeda 12y ago
  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 NDN<->HTTP 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.
  - SudoNick 12y ago
    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?
    - takeda 12y ago
      Oh this is not a big problem. You simply encrypt the data, the protocol even has a support for marking encrypted data [1]. That said the NDN does not impose how you do it and it is left for the application. Now if the data is only end-to-end you probably would do something similar to TLS. If the data supposed to be accessible by multiple users, then you encrypt it with generated key, and then encrypt the key using public keys of intended recipients. [1] http://www.ccnx.org/pubs/ccnx-mosko-tlvmessages-01.html http://www.ccnx.org/pubs/ccnx-mosko-tlvmessages-01.html (Section 3.5.2.2.1. PayloadType)
fleitz 12y ago
I wonder if it's just my naiveté however it sounds like this is more likely to produce an X400 than an SMTP. The vision seems pretty grand and all encompassing wholesale replacement of the entire networking stack, rather than small and easy to implement iterative approach. It seems that the biggest thing the TCP/IP folks got 'wrong' was the 32 bit address space, and even that small change is taking forever to be deployed. Yes you could certainly improve TCP/IP but is it going to be 10X better?
- tgflynn 12y ago
  Yes you could certainly improve TCP/IP but is it going to be 10X better? Doubtful, and I think you'd really need to see that level of improvement to have any hope of replacing TCP/IP.
- mmaunder 12y ago
  But it's a great way to sell more stuff.
- drvdevd 12y ago
  The "forever to be deployed" part is a crucial observation. Perhaps research into how to get the Internet community to adopt new protocols is more relevant than the protocols themselves. In other words: how can we speed up the adoption of IPv6?
- signa11 12y ago
  > It seems that the biggest thing the TCP/IP folks got 'wrong' was the 32 bit address space, and even that small change is taking forever to be deployed. i guess you are alluding to ipv6 here. and imho, ipv6 provides quite a large number of changes from vanilla ipv4. it is not just a much larger address space...
  - jacquesm 12y ago
    That is absolutely true but the main driver behind the replacement is the increased address space. None of the other changes seems to have been a driver at all. So as far as the consumers go IPv4 is 'good enough' and if and when IPv6 will finally take over it will remain the de-facto world wide networking protocol used to power the internet for a very very long time. Cisco attempting to drive a wedge between IPv4 and IPv6 in the midst of this (very very slow) transition seems like a very strange move to me, almost certainly bound to fail or in the end not replacing IPv4/IPv6 but maybe ending up as a transport layer underneath it (killing most of the advantages it would offer in the process). And that's besides trying to replace TCP which would require re-writing/adapting of virtually every computer program active on the net today.
Sami_Lehtinen 12y ago
There's already IEEE_802.1aq which is optimizing routing and allowing multiple parallel routing paths. https://en.wikipedia.org/wiki/IEEE_802.1aq https://en.wikipedia.org/wiki/IEEE_802.1aq Lecture well worth of watching: Frank Fitzek, Aalborg University: Network Coding for Future Communication and Storage Systems https://www.youtube.com/watch?v=qaJYWrYKVRo https://www.youtube.com/watch?v=qaJYWrYKVRo
- pyvpx 12y ago
  this is a layer 2 protocol and has nothing to do with routing, which is layer 3 in the OSI model
dinglefuk 12y ago
I don't see how this would work at all, given that public key encryption wouldn't work at all with caching data?
SixSigma 12y ago
> more secure If something is already secure, how can you make it moreso ? What they mean is "less insecure".
- deciplex 12y ago
  Something can be secure enough that the computational power required to break it is probably not available to various actors up to and perhaps including nation-states (e.g. RSA), yet still well short of the "requires more energy to compute than is available in the visible universe" benchmark (e.g. AES, probably). Yet both could still be regarded as "secure".
  - dchest 12y ago
    Also, protection against different kinds of attacks. For example, we can consider SHA3 more secure than SHA2, because it's not vulnerable length extension attack. Likewise, a system which protects against passive attacks is secure against passive attacks, but the system which protects against passive and active attacks is more secure than it.
erik123 12y ago
In NDN, all data is signed by data producers and verified by the consumers, and the data name provides essential context for security. Centralizing the concept of security in the network's architecture will create an intractable problem. Certain parties will still want to impose their desire to be able to eavesdrop on the data. Therefore, there cannot be any real security in such centralized design for security. The in tempore non suspecto in which it was still possible to roll out security jokes such as SSL, is over now. Nowadays, 95% of the world population (and their governments) will refuse to adopt any centralized security design, because they do not trust it. In my impression, the project is dead on arrival.
- jrapdx3 12y ago
  I'm wondering how the proposed security model differs from current practices. What you've quoted doesn't seem different. After all, on the web today, data producers send a certificate which the client "verifies". At least the long list of "CA" names in my browser purports to be "verified" by an "authority". Maybe the point you're making is exemplified by the news item concerning a security breach that was detected after going on for 13 years. (http://cybertinel.com/wp-content/uploads/2014/09/HARKONNEN-OPERATION-CYBER-ESPIONAGE.pdf http://cybertinel.com/wp-content/uploads/2014/09/HARKONNEN-O...) The part that got my attention was the criminals having fooled users into revealing passwords using certificates purchased from CAs (at a total cost of $150,000). That seems to mean the current CA system is broken. It's not a big surprise that a centralized security concept is in NDN--Verisign is one of its main supporters.
- reilly3000 12y ago
  That is why I'm of the mind that both canonical identity and permission need to be managed in a globally distributed fashion with blockchain. In order to facilitate the level of data transfer that would need to happen between devices to accommodate the distribution of global scale permission data, networking does need to change fundamentally. I envision my fridge having a permission entry that neighbor can use my car tomorrow, and also that a person I will never meet has purchased a ticket for a flight to Argentina next week. That data is constantly being shared on a mesh network with my car and everybody else's I drive down the road next to, across all of my devices and those of every other participant. No government or corporation should be able to have the whole set of data, and none of it should be able to have a very long half-life. The only way we can move forward to a truly connected version of the future is with trust, and the only way to have a truly trusted security model is to have it be globally distributed. NDN may or may not be the next version of networking to support it, but I'm rather confident that TCP/IP isn't going to be the way we get there.
radicalbyte 12y ago
So if I've understood this correctly, NDN works be giving each piece of content a unique address, instead of stopping at the host? Basically baking a URI into the low-level protocols?
- tgflynn 12y ago
  Yes, and the contents can be cached by the routers, so to get a piece of a video you don't need a connection all the way to the source of that video but only to the nearest router that caches it. That may make sense for content that has few sources and many users, like video (although I think CDN's mostly already solve this problem). I don't think it makes much sense for interactive data and hence I don't think it's a good basis for implementing all networking protocols.
nnain 12y ago
One of the earliest attempts to replace the the TCP/IP model (or rather the lower layers of the ISO-OSI model) was the Asynchronous Transfer Mode (ATM). Despite being a well-intentioned idea, it failed to see real world usage because of the complexity. Along the way many developments happened. People learned to live and work with IPv4. Even IPv6 hasn't picked up despite solving some important problems. So when it comes to updating the core networking infrastructure, I don't think TCP/IP is replaceable. It just works very well now -- you can have real time chats, high throughput data lines, has time-tested code libraries, there's vast amounts of knowledge so you can build apps fast and all that. As I understand, what this 'Named Data Networking' technology is proposing is to replace IP addressing scheme with Names. I'm not sure if the whole internet backbone infrastructure would change it's networking strategy now. TCP/IP addressing format is very structured and that's its strength. IMHO that's actually how communication should take place; not with names that can have high-variation in format.
- PinguTS 12y ago
  That is not right, that ATM failed to see real world usage. ATM was the backbone of the German infrastructure run mainly by German Telekom for years. It provided a very good service especially for telephony (ISDN). Germany basically had the best telephony network in the world. But the problem is, that IP does not fit with the 55ms time slot in ATM. That is the why all the backbones are replaced with the so-called Next Generation Networks (NGN), which basically is pure IP traffic and everything will be on top of IP, not anymore in parallel to IP. That basically means, moving to VoIP in the backbone and consequently also for the consumer end.
  - nnain 12y ago
    Not just German Telekom, several other operators around the globe deployed ATM in the 90s for ISDN services. However, just after a few years, most companies started dropping ATM in favour of IP based networks. By "it failed to see real world usage", I meant, it failed to sustain itself in real world.
  - dfox 12y ago
    ATM failed to see the usage predicted by it's proponents in the 90's. The reason for that is that most of such statements about ATM as the new unified network for everything were mostly marketing bullshit disconnected from technical reality. ATM is essentially circuit-switched technology lying somewhere between L1 and L2 that allows for efficient QoS for different services sharing same wire at the expense of ludicrous framing overhead and creating networks of such channels with reasonably simple and fast switches. The QoS part is mostly irrelevant today as faster interfaces made the problem significantly easier to solve so is the simple and fast switching. ATM's orientation towards end-to-end circuit-switched channels is what allows fast switches but also requires some external control-plane that builds and tears down the virtual channels, which I think is the major reason why ATM (and OSI in general) didn't catch on, on IP, you just send packet with destination address down the wire, with ATM you have to establish connection first (by using something essentially out-of-band and centralized). In the end, ATM is widely used today, but mostly as pre-existing way of handling QoS and framing on top of some unrelated but relatively slow L1 technology (ATM is the first higher-level layer of both UMTS and xDSL)
Mawaai 12y ago
People are trying for almost 15 years to replace IPv4. That's almost impossible, 96% of the traffic worldwide is still IPv4. This project is dead on arrival.
- wernercd 12y ago
  read other poster(s) above... IPv6 is on the uptick, especially since IPv4 is more or less out of space.
shmerl 12y ago
I hope keeping it all patent free / disarmament patent style is a requirement for participation.
- dredmorbius 12y ago
  I think you'd have to go beyond patent-free and require a mutual defense pact. Might even get DoJ to sign off on that.
- bediger4000 12y ago
  I note that patents/"Intellectual Property" wasn't mentioned in the article at all. I suspect, based on the participants mostly being corporations, that the whole thing will be covered by patents. I think TCP/IP as non-patented, slipped by the major corporations. A protocol anyone can implement, and where the "client" and "server" are pretty hard to tell apart, is disadvantageous to market encumbents, and to surveillance agencies. For instance, nobody can charge fees for implementing TCP/IP. Nobody can license content servers. Nobody can accurately attribute a packet to a legally-responsible entity ("one neck to wring"). The protocol to replace TCP/IP will be patent encumbered, it will make a complete distinction between "client" and "server", it will be centrally routed, it will be subject to surveillance, and servers will be licensed, and costly. If NDN doesn't do some or all of these things, it's already dead.
  - shmerl 12y ago
    > The protocol to replace TCP/IP will be patent encumbered If it will be patent encumbered, it will have zero changes of adoption.
  - j_burke 12y ago
    The participants are actually mostly universities. IP is discussed on the project site: http://named-data.net/project/ndn-copyright-and-patents/ http://named-data.net/project/ndn-copyright-and-patents/ http://named-data.net/consortium/ http://named-data.net/consortium/
elmindreda 12y ago
xkcd 927.
jdimov 12y ago
Umm.. how about let's NOT replace TCP/IP with anything because it's may be the only well-designed thing on the Internet that actually works? If you want an impossible super-hero project to work on, try replacing HTTP instead - at least you'd actually be solving a problem.
- antocv 12y ago
  Whats wrong with HTTP? How would you improve it? Its a Text Transfer Protocol, you can even build applications with text only clients and servers. One only needs echo, bash and netcat to make a server and client.
  - steveklabnik 12y ago
    > One only needs echo, bash and netcat to make a server and client. Not as of HTTP/2.0. :(
- takeda 12y ago
  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.
Luker88 12y ago
This is the old Content Distribution Network. It does work -- provided you can easily identify a resource in the network. URIs are hierarchal, but do not follow the network connections hierarchy. Also, now every router needs to be able to track all the streams that go through it. In short, everything explodes when you try to scale the thing.
ivoras 12y ago
Nothing except efficiency is preventing us from using names as parts of network/subnet hierarchy instead of numbers, e.g. : steve.home.town.country instead of 192.168.5.6 (or the same thing on IPv6), and even efficiency could be improved by the smart use of hashing... BUT! The major problem I see here is that there simply are more numbers than words. In practice, especially at large companies, it will certainly without a doubt degrade into workstation001, workstation002... workstation999 and then we're in effect back where we started from - using numbers. This looks like a solution in search of a problem.
- tgflynn 12y ago
  That's not what NDN is about. NDN assigns names (or addresses) to data contents, not physical machines/interfaces like IP does. So it's conceptually quite different from the way IP routing works. The issue you mention is already solved by DNS. This looks like a solution in search of a problem. NDN attempts to make content distribution more efficient through caching. Whether solving that problem justifies rewriting the entire network stack is highly questionable.
  - j_burke 12y ago
    While content distribution is a significant motivation, a fair amount of the current research is looking at benefits beyond caching: i.e., what do you get with web-style semantics at the lower layers, per-packet crypto, name--rather than host-based addressing, etc.
scrame 12y ago
Yeah, good luck with that. I'm more surprised they didn't say they would fix it with a MongoDB backed Facebook app written in node.js.
higherpurpose 12y ago
Whatever Cisco plans to do, I won't trust it not to have a back door. After all Cisco is the author of the IETF protocol for "lawful intercept" in routers, and if I'm not mistaken they also have a pretty high placed co-chair at IETF. http://www.cisco.com/c/en/us/tech/security-vpn/lawful-intercept/index.html http://www.cisco.com/c/en/us/tech/security-vpn/lawful-interc... https://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/BlackHat-DC-2010-Cross-Attacking-LawfulI-Intercept-wp.pdf https://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/Bl...
islon 12y ago
What could possibly go wrong? It's not like the whole internet as we know it depends at some level of tcp/ip and there's (probably) billions of lines of code depending on it.
allengeorge 12y ago
Isn't this identical in spirit to Content-Centric Networking (CCN) as espoused by Van Jacobsen? I distinctly remember watching his Google Tech Talk on the idea (https://www.youtube.com/watch?v=oCZMoY3q2uM https://www.youtube.com/watch?v=oCZMoY3q2uM) when I first joined AeroFS.
- kv85s 12y ago
  Yes! In fact, this talk first appeared on Google Video, before it all got shunted into youtube (which was an acquisition)
- j_burke 12y ago
  Yes - Van is involved in NDN: http://named-data.net/project/participants/ http://named-data.net/project/participants/
kv85s 12y ago
I believe what they're proposing is largely the same, if not identical, to Content-Centric Networking from Xerox PARC. The central idea is: Instead of asking one particular server for some content, just ask for the content by name. Since the content may come from any handy server, it is up to the receiver to validate it is really the content he requested. Nothing about this implies the evil "centralized security model" people are going on about. Sure, some bad actor could weasel it in later, but it's not there now.
- takeda 12y ago
  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.
  - j_burke 12y ago
    The ideas are related, but the codebase is now separate: http://named-data.net/2014/08/25/first-public-release-ndn-forwarding-daemon-nfd/ http://named-data.net/2014/08/25/first-public-release-ndn-fo...
colanderman 12y ago
Someone who knows more than me; does this intend to complement TCP, or replace TCP? If the latter, how would one use NDN to implement a system that naturally fits the "conversation" model of TCP, e.g. an MMORPG?
- legomylibrum 12y ago
  I don't think you would use TCP for an MMORPG; UDP is more common in games because a dropped frame here and there doesn't matter to most games, and it's worth the lower overhead.

98 points by ossama 12y ago

Maybe it's just my nature to be guarded about grand visions, but does this idea really have a good chance of succeeding? Will it displace TCP/IP given the extent of IP deployment around the world? No doubt there are people here who are network experts who can give a more learned review than I can after quickly reading the overview on the website. I have a lot to learn about the subject...

fla 12y ago
I am no network expert, but I guess their idea is to optimize the traffic in-between endpoints. The last segments (you <-> ISP) would still be using TCP over IP.
tgflynn 12y ago
Though I'm hardly a networking expert I did some contract work implementing NDN simulations so I probably know a bit more about it than most people. I'm highly skeptical that data entities provide a better (or even adequate) base abstraction for networking than network addresses associated with physical machines (ie. hosts, routers, etc.). It seems to me that the problems NDN wants to solve, primarily content caching, would be better addressed at a higher abstraction level, as I think CDN's already do. This is my opinion, and I'm certainly open to being proved wrong by more qualified viewpoints. As for the likelihood of NDN ever (a word I would almost never use, especially in regards to technology) replacing TCP/IP, it seems hard to believe given the extreme slowness with which IPv6, a comparatively minor change, is being adopted.
takeda 12y ago
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 NDN<->HTTP 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.
- SudoNick 12y ago
  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?
  - takeda 12y ago
    Oh this is not a big problem. You simply encrypt the data, the protocol even has a support for marking encrypted data [1]. That said the NDN does not impose how you do it and it is left for the application. Now if the data is only end-to-end you probably would do something similar to TLS. If the data supposed to be accessible by multiple users, then you encrypt it with generated key, and then encrypt the key using public keys of intended recipients. [1] http://www.ccnx.org/pubs/ccnx-mosko-tlvmessages-01.html http://www.ccnx.org/pubs/ccnx-mosko-tlvmessages-01.html (Section 3.5.2.2.1. PayloadType)

fleitz 12y ago

I wonder if it's just my naiveté however it sounds like this is more likely to produce an X400 than an SMTP. The vision seems pretty grand and all encompassing wholesale replacement of the entire networking stack, rather than small and easy to implement iterative approach. It seems that the biggest thing the TCP/IP folks got 'wrong' was the 32 bit address space, and even that small change is taking forever to be deployed. Yes you could certainly improve TCP/IP but is it going to be 10X better?

tgflynn 12y ago
Yes you could certainly improve TCP/IP but is it going to be 10X better? Doubtful, and I think you'd really need to see that level of improvement to have any hope of replacing TCP/IP.
mmaunder 12y ago
But it's a great way to sell more stuff.
drvdevd 12y ago
The "forever to be deployed" part is a crucial observation. Perhaps research into how to get the Internet community to adopt new protocols is more relevant than the protocols themselves. In other words: how can we speed up the adoption of IPv6?
signa11 12y ago
> It seems that the biggest thing the TCP/IP folks got 'wrong' was the 32 bit address space, and even that small change is taking forever to be deployed. i guess you are alluding to ipv6 here. and imho, ipv6 provides quite a large number of changes from vanilla ipv4. it is not just a much larger address space...
- jacquesm 12y ago
  That is absolutely true but the main driver behind the replacement is the increased address space. None of the other changes seems to have been a driver at all. So as far as the consumers go IPv4 is 'good enough' and if and when IPv6 will finally take over it will remain the de-facto world wide networking protocol used to power the internet for a very very long time. Cisco attempting to drive a wedge between IPv4 and IPv6 in the midst of this (very very slow) transition seems like a very strange move to me, almost certainly bound to fail or in the end not replacing IPv4/IPv6 but maybe ending up as a transport layer underneath it (killing most of the advantages it would offer in the process). And that's besides trying to replace TCP which would require re-writing/adapting of virtually every computer program active on the net today.

Sami_Lehtinen 12y ago

There's already IEEE_802.1aq which is optimizing routing and allowing multiple parallel routing paths. https://en.wikipedia.org/wiki/IEEE_802.1aq https://en.wikipedia.org/wiki/IEEE_802.1aq Lecture well worth of watching: Frank Fitzek, Aalborg University: Network Coding for Future Communication and Storage Systems https://www.youtube.com/watch?v=qaJYWrYKVRo https://www.youtube.com/watch?v=qaJYWrYKVRo

pyvpx 12y ago
this is a layer 2 protocol and has nothing to do with routing, which is layer 3 in the OSI model

dinglefuk 12y ago

I don't see how this would work at all, given that public key encryption wouldn't work at all with caching data?

SixSigma 12y ago

> more secure If something is already secure, how can you make it moreso ? What they mean is "less insecure".

deciplex 12y ago
Something can be secure enough that the computational power required to break it is probably not available to various actors up to and perhaps including nation-states (e.g. RSA), yet still well short of the "requires more energy to compute than is available in the visible universe" benchmark (e.g. AES, probably). Yet both could still be regarded as "secure".
- dchest 12y ago
  Also, protection against different kinds of attacks. For example, we can consider SHA3 more secure than SHA2, because it's not vulnerable length extension attack. Likewise, a system which protects against passive attacks is secure against passive attacks, but the system which protects against passive and active attacks is more secure than it.

erik123 12y ago

In NDN, all data is signed by data producers and verified by the consumers, and the data name provides essential context for security. Centralizing the concept of security in the network's architecture will create an intractable problem. Certain parties will still want to impose their desire to be able to eavesdrop on the data. Therefore, there cannot be any real security in such centralized design for security. The in tempore non suspecto in which it was still possible to roll out security jokes such as SSL, is over now. Nowadays, 95% of the world population (and their governments) will refuse to adopt any centralized security design, because they do not trust it. In my impression, the project is dead on arrival.

jrapdx3 12y ago
I'm wondering how the proposed security model differs from current practices. What you've quoted doesn't seem different. After all, on the web today, data producers send a certificate which the client "verifies". At least the long list of "CA" names in my browser purports to be "verified" by an "authority". Maybe the point you're making is exemplified by the news item concerning a security breach that was detected after going on for 13 years. (http://cybertinel.com/wp-content/uploads/2014/09/HARKONNEN-OPERATION-CYBER-ESPIONAGE.pdf http://cybertinel.com/wp-content/uploads/2014/09/HARKONNEN-O...) The part that got my attention was the criminals having fooled users into revealing passwords using certificates purchased from CAs (at a total cost of $150,000). That seems to mean the current CA system is broken. It's not a big surprise that a centralized security concept is in NDN--Verisign is one of its main supporters.
reilly3000 12y ago
That is why I'm of the mind that both canonical identity and permission need to be managed in a globally distributed fashion with blockchain. In order to facilitate the level of data transfer that would need to happen between devices to accommodate the distribution of global scale permission data, networking does need to change fundamentally. I envision my fridge having a permission entry that neighbor can use my car tomorrow, and also that a person I will never meet has purchased a ticket for a flight to Argentina next week. That data is constantly being shared on a mesh network with my car and everybody else's I drive down the road next to, across all of my devices and those of every other participant. No government or corporation should be able to have the whole set of data, and none of it should be able to have a very long half-life. The only way we can move forward to a truly connected version of the future is with trust, and the only way to have a truly trusted security model is to have it be globally distributed. NDN may or may not be the next version of networking to support it, but I'm rather confident that TCP/IP isn't going to be the way we get there.

radicalbyte 12y ago

So if I've understood this correctly, NDN works be giving each piece of content a unique address, instead of stopping at the host? Basically baking a URI into the low-level protocols?

tgflynn 12y ago
Yes, and the contents can be cached by the routers, so to get a piece of a video you don't need a connection all the way to the source of that video but only to the nearest router that caches it. That may make sense for content that has few sources and many users, like video (although I think CDN's mostly already solve this problem). I don't think it makes much sense for interactive data and hence I don't think it's a good basis for implementing all networking protocols.

nnain 12y ago

One of the earliest attempts to replace the the TCP/IP model (or rather the lower layers of the ISO-OSI model) was the Asynchronous Transfer Mode (ATM). Despite being a well-intentioned idea, it failed to see real world usage because of the complexity. Along the way many developments happened. People learned to live and work with IPv4. Even IPv6 hasn't picked up despite solving some important problems. So when it comes to updating the core networking infrastructure, I don't think TCP/IP is replaceable. It just works very well now -- you can have real time chats, high throughput data lines, has time-tested code libraries, there's vast amounts of knowledge so you can build apps fast and all that. As I understand, what this 'Named Data Networking' technology is proposing is to replace IP addressing scheme with Names. I'm not sure if the whole internet backbone infrastructure would change it's networking strategy now. TCP/IP addressing format is very structured and that's its strength. IMHO that's actually how communication should take place; not with names that can have high-variation in format.

PinguTS 12y ago
That is not right, that ATM failed to see real world usage. ATM was the backbone of the German infrastructure run mainly by German Telekom for years. It provided a very good service especially for telephony (ISDN). Germany basically had the best telephony network in the world. But the problem is, that IP does not fit with the 55ms time slot in ATM. That is the why all the backbones are replaced with the so-called Next Generation Networks (NGN), which basically is pure IP traffic and everything will be on top of IP, not anymore in parallel to IP. That basically means, moving to VoIP in the backbone and consequently also for the consumer end.
- nnain 12y ago
  Not just German Telekom, several other operators around the globe deployed ATM in the 90s for ISDN services. However, just after a few years, most companies started dropping ATM in favour of IP based networks. By "it failed to see real world usage", I meant, it failed to sustain itself in real world.
- dfox 12y ago
  ATM failed to see the usage predicted by it's proponents in the 90's. The reason for that is that most of such statements about ATM as the new unified network for everything were mostly marketing bullshit disconnected from technical reality. ATM is essentially circuit-switched technology lying somewhere between L1 and L2 that allows for efficient QoS for different services sharing same wire at the expense of ludicrous framing overhead and creating networks of such channels with reasonably simple and fast switches. The QoS part is mostly irrelevant today as faster interfaces made the problem significantly easier to solve so is the simple and fast switching. ATM's orientation towards end-to-end circuit-switched channels is what allows fast switches but also requires some external control-plane that builds and tears down the virtual channels, which I think is the major reason why ATM (and OSI in general) didn't catch on, on IP, you just send packet with destination address down the wire, with ATM you have to establish connection first (by using something essentially out-of-band and centralized). In the end, ATM is widely used today, but mostly as pre-existing way of handling QoS and framing on top of some unrelated but relatively slow L1 technology (ATM is the first higher-level layer of both UMTS and xDSL)

Mawaai 12y ago

People are trying for almost 15 years to replace IPv4. That's almost impossible, 96% of the traffic worldwide is still IPv4. This project is dead on arrival.

wernercd 12y ago
read other poster(s) above... IPv6 is on the uptick, especially since IPv4 is more or less out of space.

shmerl 12y ago

I hope keeping it all patent free / disarmament patent style is a requirement for participation.

dredmorbius 12y ago
I think you'd have to go beyond patent-free and require a mutual defense pact. Might even get DoJ to sign off on that.
bediger4000 12y ago
I note that patents/"Intellectual Property" wasn't mentioned in the article at all. I suspect, based on the participants mostly being corporations, that the whole thing will be covered by patents. I think TCP/IP as non-patented, slipped by the major corporations. A protocol anyone can implement, and where the "client" and "server" are pretty hard to tell apart, is disadvantageous to market encumbents, and to surveillance agencies. For instance, nobody can charge fees for implementing TCP/IP. Nobody can license content servers. Nobody can accurately attribute a packet to a legally-responsible entity ("one neck to wring"). The protocol to replace TCP/IP will be patent encumbered, it will make a complete distinction between "client" and "server", it will be centrally routed, it will be subject to surveillance, and servers will be licensed, and costly. If NDN doesn't do some or all of these things, it's already dead.
- shmerl 12y ago
  > The protocol to replace TCP/IP will be patent encumbered If it will be patent encumbered, it will have zero changes of adoption.
- j_burke 12y ago
  The participants are actually mostly universities. IP is discussed on the project site: http://named-data.net/project/ndn-copyright-and-patents/ http://named-data.net/project/ndn-copyright-and-patents/ http://named-data.net/consortium/ http://named-data.net/consortium/

elmindreda 12y ago

xkcd 927.

jdimov 12y ago

Umm.. how about let's NOT replace TCP/IP with anything because it's may be the only well-designed thing on the Internet that actually works? If you want an impossible super-hero project to work on, try replacing HTTP instead - at least you'd actually be solving a problem.

antocv 12y ago
Whats wrong with HTTP? How would you improve it? Its a Text Transfer Protocol, you can even build applications with text only clients and servers. One only needs echo, bash and netcat to make a server and client.
- steveklabnik 12y ago
  > One only needs echo, bash and netcat to make a server and client. Not as of HTTP/2.0. :(
takeda 12y ago
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.

Luker88 12y ago

This is the old Content Distribution Network. It does work -- provided you can easily identify a resource in the network. URIs are hierarchal, but do not follow the network connections hierarchy. Also, now every router needs to be able to track all the streams that go through it. In short, everything explodes when you try to scale the thing.

ivoras 12y ago

Nothing except efficiency is preventing us from using names as parts of network/subnet hierarchy instead of numbers, e.g. : steve.home.town.country instead of 192.168.5.6 (or the same thing on IPv6), and even efficiency could be improved by the smart use of hashing... BUT! The major problem I see here is that there simply are more numbers than words. In practice, especially at large companies, it will certainly without a doubt degrade into workstation001, workstation002... workstation999 and then we're in effect back where we started from - using numbers. This looks like a solution in search of a problem.

tgflynn 12y ago
That's not what NDN is about. NDN assigns names (or addresses) to data contents, not physical machines/interfaces like IP does. So it's conceptually quite different from the way IP routing works. The issue you mention is already solved by DNS. This looks like a solution in search of a problem. NDN attempts to make content distribution more efficient through caching. Whether solving that problem justifies rewriting the entire network stack is highly questionable.
- j_burke 12y ago
  While content distribution is a significant motivation, a fair amount of the current research is looking at benefits beyond caching: i.e., what do you get with web-style semantics at the lower layers, per-packet crypto, name--rather than host-based addressing, etc.

scrame 12y ago

Yeah, good luck with that. I'm more surprised they didn't say they would fix it with a MongoDB backed Facebook app written in node.js.

higherpurpose 12y ago

Whatever Cisco plans to do, I won't trust it not to have a back door. After all Cisco is the author of the IETF protocol for "lawful intercept" in routers, and if I'm not mistaken they also have a pretty high placed co-chair at IETF. http://www.cisco.com/c/en/us/tech/security-vpn/lawful-intercept/index.html http://www.cisco.com/c/en/us/tech/security-vpn/lawful-interc... https://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/BlackHat-DC-2010-Cross-Attacking-LawfulI-Intercept-wp.pdf https://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/Bl...

islon 12y ago

What could possibly go wrong? It's not like the whole internet as we know it depends at some level of tcp/ip and there's (probably) billions of lines of code depending on it.

allengeorge 12y ago

Isn't this identical in spirit to Content-Centric Networking (CCN) as espoused by Van Jacobsen? I distinctly remember watching his Google Tech Talk on the idea (https://www.youtube.com/watch?v=oCZMoY3q2uM https://www.youtube.com/watch?v=oCZMoY3q2uM) when I first joined AeroFS.

kv85s 12y ago
Yes! In fact, this talk first appeared on Google Video, before it all got shunted into youtube (which was an acquisition)
j_burke 12y ago
Yes - Van is involved in NDN: http://named-data.net/project/participants/ http://named-data.net/project/participants/

kv85s 12y ago

I believe what they're proposing is largely the same, if not identical, to Content-Centric Networking from Xerox PARC. The central idea is: Instead of asking one particular server for some content, just ask for the content by name. Since the content may come from any handy server, it is up to the receiver to validate it is really the content he requested. Nothing about this implies the evil "centralized security model" people are going on about. Sure, some bad actor could weasel it in later, but it's not there now.

takeda 12y ago
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.
- j_burke 12y ago
  The ideas are related, but the codebase is now separate: http://named-data.net/2014/08/25/first-public-release-ndn-forwarding-daemon-nfd/ http://named-data.net/2014/08/25/first-public-release-ndn-fo...

colanderman 12y ago

Someone who knows more than me; does this intend to complement TCP, or replace TCP? If the latter, how would one use NDN to implement a system that naturally fits the "conversation" model of TCP, e.g. an MMORPG?

legomylibrum 12y ago
I don't think you would use TCP for an MMORPG; UDP is more common in games because a dropped frame here and there doesn't matter to most games, and it's worth the lower overhead.