
The Mission to Save the Internet by Rewiring It from the Name Up - jawngee
http://motherboard.vice.com/read/the-internet-of-names
======
skywhopper
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.

~~~
navait
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](http://arxiv.org/pdf/1112.2205)

------
snowy
"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??

~~~
spdustin
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?

------
bagosm
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.

~~~
rfugger
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...](http://named-data.net/wp-content/uploads/comcom-stateful-
forwarding.pdf)

This challenges the notion that IP's statelessness is one of its core
strengths.

------
zyx321
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?

~~~
rfugger
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](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.

~~~
Kalium
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.

------
pronoiac
NDN sounds a lot like [http://ipfs.io/](http://ipfs.io/)

------
throwaway7767
If this interests you, you might want to check out Freenet:
[https://freenetproject.org/](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.

------
amelius
Why can't something like this be built on top of the existing internet?

And why doesn't the article mention DNS?

~~~
justonethrowa2
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/](http://named-data.net/project/execsummary/) and
this [http://named-data.net/project/archoverview/](http://named-
data.net/project/archoverview/) (also they have this on Github
[https://github.com/named-data/ndn-cxx](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.

~~~
chongli
_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?

~~~
s_baby
A BT magnet link is a type of URN or "Uniform Resource Name". But you're right
that is an unsolved problem.

------
yellowapple
This sounds like a modernized and more-general-purpose successor to Usenet.
Exciting.

------
desult
Slightly fuzzy still on where the data actually lives.

------
dghf
Is this URNs again?

------
endymi0n
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!

~~~
andrewstuart2
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.

~~~
numeromancer
Nuh-uh. Vide:

[http://www.economist.com/node/196071](http://www.economist.com/node/196071)

[http://www.mythbusters.com/some-myths-about-the-qwerty-
keybo...](http://www.mythbusters.com/some-myths-about-the-qwerty-keyboard-
part-i.html)

[http://www.straightdope.com/columns/read/221/was-the-
qwerty-...](http://www.straightdope.com/columns/read/221/was-the-qwerty-
keyboard-purposely-designed-to-slow-typists)

[http://reason.com/archives/1996/06/01/typing-
errors/1](http://reason.com/archives/1996/06/01/typing-errors/1)

~~~
Dylan16807
>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.

~~~
andrewstuart2
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.

