The Mission to Save the Internet by Rewiring It from the Name Up(motherboard.vice.com)
motherboard.vice.com
The Mission to Save the Internet by Rewiring It from the Name Up
http://motherboard.vice.com/read/the-internet-of-names
30 comments
So, essentially, in order to lower bandwidth demands on streaming video providers, we just need to rebuild the entire Internet, from protocols to network hardware, in a way that requires us to trust every router on the Internet and every device on our local network with detailed information about the exact content we are requesting. Sounds reasonable.
While the simplistic version of NDN works as snarkily described, the researchers have built security features into NDN to work with untrusted routers and anonymity. They can actually provide better security through encrypting content and Anonymizing Routers than TCP/IP.
For a good analysis of some of the challenges and features in NDN security, I reccomend: http://arxiv.org/pdf/1112.2205
For a good analysis of some of the challenges and features in NDN security, I reccomend: http://arxiv.org/pdf/1112.2205
Think encrypted torrents with keys known to a limited number of people (or some more clever key distribution scheme).
"I said, ‘There’s a simple answer.’ I had my phone on the table, and he had his phone on the table. I said, ‘Look, our phones are next to each other, can they talk to each other?’ He said, ‘of course they can.’ I said, ‘directly?’ And he said, ‘no, they cannot.’ And this is not because physically they can not, physically [you can connect] phone-to phone using WiFi, Bluetooth. But the TCP/IP protocol is the roadblock for phones to directly talk to each other. The protocols need to change because it doesn't enable the communication that we want.”
Am I missing something here? If both phones are on the same network (IE the internet) and have public IP address's (which IPv6 makes it feasible for every device to have) Why can't they talk to each other? Why is the TCP/IP protocol a roadblock??
Am I missing something here? If both phones are on the same network (IE the internet) and have public IP address's (which IPv6 makes it feasible for every device to have) Why can't they talk to each other? Why is the TCP/IP protocol a roadblock??
[deleted]
Isn't that pretty much exactly what AirDrop does on IOS? Connect two phones via Bluetooth when they're in proximity, and they then carry on a conversation?
I think technically you could setup a light weight server on your phone and you could get an address for it and expose it to the internet. However, that would only be for that cafe they are sitting in. Since the server would need to stay in a fixed location or keep updating the DNS everytime it moves. This would then take time to propagate, it's not immediate as far as I can remember. I could be wrong, I'm a little weak on my networking, but I believe that's why.
I still don't understand how this will benefit the internet speed. Don't get me wrong, the built-in CDN (cause that's what this is all about, redistributing data) is kind of good, but would you spend double the money for a router so that it can have a storage device to cache data? Or do you think that your ISP would/should? If so, caching is doable with current infrastructures too, we just don't invest in it...
On the other hand if you were to stream from your neighbours' connections.. Well... That would really require a big advance in current line speeds or it would make everyone DDoSed all the time.
So as I see it no, the IP protocol really isn't the current bottleneck in today's internet usage speeds.
Oh and don't even get me started on device interconnection because it's exactly the same problem but on a different protocol: the problem is how you manage your content (files etc) with software not how it's transported. To move files from a device to the other what's important to develop is better access management (share over 192. ranges, or share on a VPN or share only with a password like ftp etc). A different protocol would only make the respective language's API a bit different, it wouldn't magically create apps and interfaces and systems that would take advantage of it.
On the other hand if you were to stream from your neighbours' connections.. Well... That would really require a big advance in current line speeds or it would make everyone DDoSed all the time.
So as I see it no, the IP protocol really isn't the current bottleneck in today's internet usage speeds.
Oh and don't even get me started on device interconnection because it's exactly the same problem but on a different protocol: the problem is how you manage your content (files etc) with software not how it's transported. To move files from a device to the other what's important to develop is better access management (share over 192. ranges, or share on a VPN or share only with a password like ftp etc). A different protocol would only make the respective language's API a bit different, it wouldn't magically create apps and interfaces and systems that would take advantage of it.
They intend to replace IP's stateless data plane with a stateful data plane that they argue is more efficient:
> In Named Data Networking (NDN), packets carry data names instead of source and destination addresses. This paradigm shift leads to a new network forwarding plane: data consumers send Interest packets to request desired data, routers forward Interest packets and maintain the state of all pending Interests, which is then used to guide Data packets back to the consumers. Maintaining the pending Interest state, together with the two-way Interest and Data exchange, enables NDN routers’ forwarding process to measure performance of different paths, quickly detect failures and retry alternative paths. In this paper we describe an initial design of NDN’s forwarding plane and evaluate its data delivery performance under adverse conditions. Our results show that this stateful forwarding plane can successfully circumvent prefix hijackers, avoid failed links, and utilize multiple paths to mitigate congestion. We also compare NDN’s performance with that of IP-based solutions to highlight the advantages of a stateful forwarding plane.
http://named-data.net/wp-content/uploads/comcom-stateful-for...
This challenges the notion that IP's statelessness is one of its core strengths.
> In Named Data Networking (NDN), packets carry data names instead of source and destination addresses. This paradigm shift leads to a new network forwarding plane: data consumers send Interest packets to request desired data, routers forward Interest packets and maintain the state of all pending Interests, which is then used to guide Data packets back to the consumers. Maintaining the pending Interest state, together with the two-way Interest and Data exchange, enables NDN routers’ forwarding process to measure performance of different paths, quickly detect failures and retry alternative paths. In this paper we describe an initial design of NDN’s forwarding plane and evaluate its data delivery performance under adverse conditions. Our results show that this stateful forwarding plane can successfully circumvent prefix hijackers, avoid failed links, and utilize multiple paths to mitigate congestion. We also compare NDN’s performance with that of IP-based solutions to highlight the advantages of a stateful forwarding plane.
http://named-data.net/wp-content/uploads/comcom-stateful-for...
This challenges the notion that IP's statelessness is one of its core strengths.
Sooooooooooooo...
How are names going to be assigned? And how will the keys be distributed?
With DNS it's relatively simple: The root namespace is divided between TLD registrars. I contact a reseller who buys a domain from the TLD registrars and generally offers a DNS server to administrate it. I then publish the address of my server via that DNS server. Controlling the DNS is sufficient to establish proof of ownership of that domain (set the MX record to an email server where you own the admin@ address) so you can use that to request an SSL certificate from a trusted Certificate Authority - all CAs are trusted for the entire DNS namespace.
With NDN, this all goes out of the window. It seems that as of yet there's no plan on how to divide up the root namespace, and no plan how to manage certificates. Since there are no explicit addresses, all packages need to be signed ( or I could just set up a server and start answering request to /google/ ) but how will we know whether the key is trustworthy? How will we deal with expired or compromised certificates? If I let my key expire, will my service go down completely? How do we manage revoked certificates?
How are names going to be assigned? And how will the keys be distributed?
With DNS it's relatively simple: The root namespace is divided between TLD registrars. I contact a reseller who buys a domain from the TLD registrars and generally offers a DNS server to administrate it. I then publish the address of my server via that DNS server. Controlling the DNS is sufficient to establish proof of ownership of that domain (set the MX record to an email server where you own the admin@ address) so you can use that to request an SSL certificate from a trusted Certificate Authority - all CAs are trusted for the entire DNS namespace.
With NDN, this all goes out of the window. It seems that as of yet there's no plan on how to divide up the root namespace, and no plan how to manage certificates. Since there are no explicit addresses, all packages need to be signed ( or I could just set up a server and start answering request to /google/ ) but how will we know whether the key is trustworthy? How will we deal with expired or compromised certificates? If I let my key expire, will my service go down completely? How do we manage revoked certificates?
I don't know what they have planned, but this would be a perfect opportunity to adopt a more decentralized approach to name registration, like Namecoin.
https://en.wikipedia.org/wiki/Namecoin
Using a Bitcoin-style blockchain as a name registrar ought to be far less controversial than using it as a value store or a payment system.
https://en.wikipedia.org/wiki/Namecoin
Using a Bitcoin-style blockchain as a name registrar ought to be far less controversial than using it as a value store or a payment system.
Nothing consensus-driven like Namecoin or other blockchain-driven registrar should be used by people who take security seriously. Lowering your security level to "inconvenient and/or expensive to attack" is not a desirable goal.
Consensus is no replacement for authority.
Consensus is no replacement for authority.
NDN sounds a lot like http://ipfs.io/
If this interests you, you might want to check out Freenet:
https://freenetproject.org/
It's a similar concept layered on top of UDP, but it is designed as an anonymous system. Theoretically such store-and-forward systems may provide better anonymity than tor due to the lack of a realtime demand.
I'm interested in seeing what comes of these proposals. However they are unlikely to even try to tackle the privacy/anonymity issues. Every router knows every piece of content you request, not just the host you connect to.
It's a similar concept layered on top of UDP, but it is designed as an anonymous system. Theoretically such store-and-forward systems may provide better anonymity than tor due to the lack of a realtime demand.
I'm interested in seeing what comes of these proposals. However they are unlikely to even try to tackle the privacy/anonymity issues. Every router knows every piece of content you request, not just the host you connect to.
Why can't something like this be built on top of the existing internet?
And why doesn't the article mention DNS?
And why doesn't the article mention DNS?
They actually propose to use this on top of TCP and UDP (or any other transport). They want to address content using names (like bittorrent magnet links), not address machines like DNS does. See this http://named-data.net/project/execsummary/ and this http://named-data.net/project/archoverview/ (also they have this on Github https://github.com/named-data/ndn-cxx). They want to use caching at router level as a substitute for client-side congestion control. I'll reproduce below some sections.
Routing and Forwarding
NDN routes and forwards packets on names, which eliminates four problems that addresses pose in the IP architecture: address space exhaustion, NAT traversal, mobility, and address management. There is no address exhaustion problem since the namespace is unbounded. There is no NAT traversal problem since a host does not need to expose its address in order to offer content. Mobility, which requires changing addresses in IP, no longer breaks communication since data names remain the same. Finally, address assignment and management is no longer required in local networks, which is especially empowering for embedded sensor networks.
(...)
Caching
Automatic in-network caching is enabled by naming data. Since each NDN Data packet is meaningful independent of where it comes from or where it may be forwarded to, a router can cache it in its content store to satisfy future requests. Upon receiving a new Interest, the router first checks the Content Store. If there is a data whose name falls under the Interest’s name, the data will be sent back as a response. The Content Store, in its basic form, is just the buffer memory in today’s router. Both IP routers and NDN routers buffer data packets. The difference is that IP routers cannot reuse the data after forwarding them, while NDN routers are able to reuse the data since they are identified by the data names. For static files, NDN achieves almost optimal data delivery. Even dynamic content can benefit from caching in the case of multicast (e.g., teleconferencing) or packet retransmission after a packet loss. Cache management and replacement is subject to ISP policies and is one of our research topics.
Caching named data may raise privacy concerns. Today’s IP networks offer weak privacy protection. One can find out what is in an IP packet by inspecting the header or payload, and who requested the data by checking the destination address. NDN explicitly names the data, arguably making it easier for a network monitor to see what data is being requested. One may also be able to learn what data is requested through clever probing schemes to derive what is in the cache. However NDN removes entirely the information regarding who is requesting the data. Unless directly connected to the requesting host by a point-to-point link, a router will only know that someone has requested certain data, but will not know who originated the request. Thus the NDN architecture naturally offers privacy protection at a fundamentally different level than the current IP networks. Transport
The NDN architecture does not have a separate transport layer. It moves the functions of today’s transport protocols up into applications, their supporting libraries, and the strategy component in the forwarding plane. Multiplexing and demultiplexing among application processes is done directly using names at the NDN layer, and data integrity and reliability are directly handled by application processes where the appropriate reliability checking, data signing and trust decisions can be made.
An NDN network is designed to operate on top of unreliable packet delivery services, including the highly dynamic connectivity of mobile and ubiquitous computing. To provide reliable delivery, Interest packets that are not satisfied within some reasonable period of time must be retransmitted by the final consumer (the application that originated the initial Interest) if it still wants the data. Such functionality is common to many NDN applications, and is provided by NDN common libraries.
NDN routers manage traffic load through through managing the Interest forwarding rate on a hop-by-hop basis; when a router is overloaded by incoming data traffic from any specific neighbor, it simply slows down or stop sending Interest packets to that neighbor. This also means that NDN eliminates the dependency on end hosts to perform congestion control. Once congestion occurs, data retransmission is aided by caching since the retransmitted Interest will meet the Data right above the link the packet was lost, not the original sender. Thus NDN avoids congestion collapse that can occur in today’s Internet when a packet is lost at the last hop and bandwidth is mostly consumed by repeated retransmissions from the original source host.
Traditional transport services provide point-to-point data delivery and most of today’s distributed applications, including peer-to-peer applications, heavily rely on centralized servers. To aid the development of robust and efficient distributed applications, we envision a fundamentally new building block for distributed systems that we are calling Sync. Built on top of NDN’s basic Interest-Data communication model, Sync utilizes naming conventions to enable multiple parties to synchronize their datasets by exchanging data digests, so that individual parties can discover and retrieve new and missing data in a most efficient and robust manner. We expect that Sync’s role in the NDN architecture will evolve to one similar to TCP’s in the IP architecture.
Routing and Forwarding
NDN routes and forwards packets on names, which eliminates four problems that addresses pose in the IP architecture: address space exhaustion, NAT traversal, mobility, and address management. There is no address exhaustion problem since the namespace is unbounded. There is no NAT traversal problem since a host does not need to expose its address in order to offer content. Mobility, which requires changing addresses in IP, no longer breaks communication since data names remain the same. Finally, address assignment and management is no longer required in local networks, which is especially empowering for embedded sensor networks.
(...)
Caching
Automatic in-network caching is enabled by naming data. Since each NDN Data packet is meaningful independent of where it comes from or where it may be forwarded to, a router can cache it in its content store to satisfy future requests. Upon receiving a new Interest, the router first checks the Content Store. If there is a data whose name falls under the Interest’s name, the data will be sent back as a response. The Content Store, in its basic form, is just the buffer memory in today’s router. Both IP routers and NDN routers buffer data packets. The difference is that IP routers cannot reuse the data after forwarding them, while NDN routers are able to reuse the data since they are identified by the data names. For static files, NDN achieves almost optimal data delivery. Even dynamic content can benefit from caching in the case of multicast (e.g., teleconferencing) or packet retransmission after a packet loss. Cache management and replacement is subject to ISP policies and is one of our research topics.
Caching named data may raise privacy concerns. Today’s IP networks offer weak privacy protection. One can find out what is in an IP packet by inspecting the header or payload, and who requested the data by checking the destination address. NDN explicitly names the data, arguably making it easier for a network monitor to see what data is being requested. One may also be able to learn what data is requested through clever probing schemes to derive what is in the cache. However NDN removes entirely the information regarding who is requesting the data. Unless directly connected to the requesting host by a point-to-point link, a router will only know that someone has requested certain data, but will not know who originated the request. Thus the NDN architecture naturally offers privacy protection at a fundamentally different level than the current IP networks. Transport
The NDN architecture does not have a separate transport layer. It moves the functions of today’s transport protocols up into applications, their supporting libraries, and the strategy component in the forwarding plane. Multiplexing and demultiplexing among application processes is done directly using names at the NDN layer, and data integrity and reliability are directly handled by application processes where the appropriate reliability checking, data signing and trust decisions can be made.
An NDN network is designed to operate on top of unreliable packet delivery services, including the highly dynamic connectivity of mobile and ubiquitous computing. To provide reliable delivery, Interest packets that are not satisfied within some reasonable period of time must be retransmitted by the final consumer (the application that originated the initial Interest) if it still wants the data. Such functionality is common to many NDN applications, and is provided by NDN common libraries.
NDN routers manage traffic load through through managing the Interest forwarding rate on a hop-by-hop basis; when a router is overloaded by incoming data traffic from any specific neighbor, it simply slows down or stop sending Interest packets to that neighbor. This also means that NDN eliminates the dependency on end hosts to perform congestion control. Once congestion occurs, data retransmission is aided by caching since the retransmitted Interest will meet the Data right above the link the packet was lost, not the original sender. Thus NDN avoids congestion collapse that can occur in today’s Internet when a packet is lost at the last hop and bandwidth is mostly consumed by repeated retransmissions from the original source host.
Traditional transport services provide point-to-point data delivery and most of today’s distributed applications, including peer-to-peer applications, heavily rely on centralized servers. To aid the development of robust and efficient distributed applications, we envision a fundamentally new building block for distributed systems that we are calling Sync. Built on top of NDN’s basic Interest-Data communication model, Sync utilizes naming conventions to enable multiple parties to synchronize their datasets by exchanging data digests, so that individual parties can discover and retrieve new and missing data in a most efficient and robust manner. We expect that Sync’s role in the NDN architecture will evolve to one similar to TCP’s in the IP architecture.
They want to address content using names (like bittorrent magnet links), not address machines like DNS does
BT magnet links do not address by name, they address by content hash. This leaves intact the principal problem: how to convert between human-readable names and actual addresses for content?
BT magnet links do not address by name, they address by content hash. This leaves intact the principal problem: how to convert between human-readable names and actual addresses for content?
A BT magnet link is a type of URN or "Uniform Resource Name". But you're right that is an unsolved problem.
They're running in on top of TCP in their demos, but their goal is to completely remove the transport layer.
This sounds like a modernized and more-general-purpose successor to Usenet. Exciting.
Slightly fuzzy still on where the data actually lives.
Is this URNs again?
Related: We also need a new keyboard layout. The QWERTY arrangement is horrendously inefficient. It's going to happen very soon now, the gained efficiencies are significant!
You mean Dvorak?
Qwerty is just a relic from the time of typewriters. It was arranged that way to make sure that the typebars didn't bind even at high typing speeds, so yeah, not really optimized for efficiency.
Qwerty is just a relic from the time of typewriters. It was arranged that way to make sure that the typebars didn't bind even at high typing speeds, so yeah, not really optimized for efficiency.
Nuh-uh. Vide:
http://www.economist.com/node/196071
http://www.mythbusters.com/some-myths-about-the-qwerty-keybo...
http://www.straightdope.com/columns/read/221/was-the-qwerty-...
http://reason.com/archives/1996/06/01/typing-errors/1
http://www.economist.com/node/196071
http://www.mythbusters.com/some-myths-about-the-qwerty-keybo...
http://www.straightdope.com/columns/read/221/was-the-qwerty-...
http://reason.com/archives/1996/06/01/typing-errors/1
>It was arranged that way to make sure that the typebars didn't bind even at high typing speeds
>From the very beginning, Sholes arranged his keys to be less likely to jam, based on frequency of use
Weird way to "disagree". QWERTY is pretty good for typing speed in the absence of jams, because the letter spreading helps both, but it wasn't the primary design goal.
As much as I have heard about this "myth" of QWERTY trying to slow down typists, I have never seen a single person that actually believed it. It's like a weird anti-meme.
>From the very beginning, Sholes arranged his keys to be less likely to jam, based on frequency of use
Weird way to "disagree". QWERTY is pretty good for typing speed in the absence of jams, because the letter spreading helps both, but it wasn't the primary design goal.
As much as I have heard about this "myth" of QWERTY trying to slow down typists, I have never seen a single person that actually believed it. It's like a weird anti-meme.
I actually used to believe it, until I learned that it was the careful arrangement of keys opposite each other rather than a decrease in speed that led to fewer jams.
I believe those all support my claim -- that the QWERTY layout was designed to prevent the typebars from binding.
I deliberately do not perpetuate the myth that it's designed to slow typists down.
I deliberately do not perpetuate the myth that it's designed to slow typists down.
There even are one-handed versions of Dvorak, pretty cool I thought:
http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard#One-...