6 HN recommenders · recommended in 6 months, 2011–2018
1:21:16 · 52K views · Jul 23, 2007
Van Jacobson's 2006 Google Tech Talk argues that networking should be rethought around named data rather than host-to-host conversations. He contrasts the circuit and datagram views of the internet and sketches content-centric networking as a replacement for the location-centric TCP/IP model.
HN commenters point to it as a clear explanation of why data-centric networking fits how the internet is actually used, and as a core talk on content addressing.
6 comments from Hacker News
The reason we haven't solved DDoS attacks is because we're working on solving the problem at the wrong level. We're trying to solve the wrong problem. This video explains very clearly how this is the case: this video Short(er) explanation: we no longer use the internet primarily for the purpose of communicating between two parties. But the infrastructure of the internet forces us to obtain data by having a conversation with a supposedly trusted party, even though a line of communication is not really what we want; we want a specific piece of data (an internet page, the latest exchange rate of USD to EUR, the ISO for the daily image of Ubuntu 12.04, etc.). It doesn't matter where we get it from (location is irrelevant), it only matters that it's the right data. Our use of the internet today is all about data. Yet, the infrastructure of the internet (TCP/IP) is location-centric; not data-centric. Data is shuttled between computers based, not on the data, but on the location of the computers. This creates the possibility of DoS attacks. The TCP/IP protocol is designed to efficiently route packages from a source to a destination, and a DoS attack simply uses this feature maliciously. When someone is hit by a DoS attack, the routers aiding in this are just following the rules of TCP/IP: routing packages to a destination. That's their job. What we need is a data-centric infrastructure. An infrastructure where data is not obtained via a connection to some location , but an infrastructu
Watching this now. It's great. Thanks! Not only are there some nice restatements of powerful high-level insights in to network effects in general (which I am considering with respect to physical logistics requirements in our current business), but some great historical tidbits too. The resounding rejection of packet switching by period communications experts at this video is awesome. Oh how the mighty have fallen!
I wasn't able to pull anything out of this article. Perhaps I read it too quickly. Did anyone get a sense of what sort of re-thinking he has in mind? Something content-centric, perhaps? [LINK] this video (an excellent google tech talk) [LINK]
"authentication of the content, not the connection" Popular websites that hold themselves out as businesses, i.e. "exclusive" sources of content (often generated by users, go figure), they have no reason to support this concept. Because then it does not matter where the user gets the content. But they might have reasons to support TLS. One could argue users want authentic content (signed content), not authentic "websites" (single sources for content trying to serve too many users, all at the same time). Or maybe many users do not know the difference? Van Jacobsen gave a good talk on this at Google: this video There is another thread on the HN front page right now about a Blackhat conference talk on x86 CPUs. There is another talk on that page about how TLS relies on the trustworthiness of internet routing. What is the point of securing connections when you have no control over routing? Instead of relying on securing "connections", I think schemes that send out "encrypted blobs" with the hope they arrive at the proper destination make more sense. Encrypting blobs is not something for which an "authority" is needed. This is something over which the user can retain full control without involving third parties. As it should be. TLS might have encryption that works well enough to "secure a connection" but if I am not mistaken it still has no reliable way to verify an endpoint (recipient) is the one you want it to be. Some people call that "authentication". I'm not even sure that TLS
As I mentioned elsewhere Netflix does use Level3, Akamai, and Limelight. So the traffic is mainly coming from CDNs. I'm not sure if by "content-aware routers" you mean something like Content Centric Networking: [LINK] If that's the case it'd be up to the ISPs to push that technology to their infrastructure. Van Jacobson gave a very informative presentation at Netflix about it a couple of months ago. It seems you can watch a similar presentation he gave at Google on youtube: this video