The Next Big Thing: Named-Data Networking

Murat Yuksel yuksem at
Fri Sep 5 19:27:35 UTC 2014

As far as I understand, NDN's basic premise is to install "names" into the network layer. I don't think they (the NDN inventors) consider it as a new "app" at this point, even tough eventually it may merely stay as a new app.

I think the final thing that will determine the success of NDN is whether or not pushing names into the network layer rather than handling it at the app layer is going to return significant enough benefits. On the positive side, we will get rid of name -> address -> name mapping we are doing with DNS, we will enjoy content caching in routers themselves without relying on content servers to do it for us, and the story of upgrading to IPv6 will be over. :)  On the negative side, we will have to deal with a whole new set of security and privacy issues (I can see a new wave of funding for cyber-security folks), we will need to revamp our routers (arguably which seems to attract Cisco so far) to handle names rather than IP addresses, and most importantly re-educate our practitioners to configure these "revamped" routers!

The key question is that do we really need to push the names into the network layer? I personally don't see this will happen, particularly as a replacement to TCP/IP as was laid down in the slashdot article. The best bet, IMHO, for NDN is to establish software-based NDN routers that maintain content tagged with names. One way to imagine I guess is to consider each router as a NAT box for this. I just can't see it replacing IP-based forwarding. We all wish things were so easy to change, but simply they are not.



On Sep 5, 2014, at 11:51 AM, Field, Brian <Brian_Field at> wrote:

> Here¹s my $0.02.   I¹m only going to touch on a small part of what I
> understand NDN to be‹ namely making caching a first class citizen of the
> network.  When you think about the types of traffic currently carried over
> our collective networks, there might be value if the network eco system
> more natively supported caching.
> Van¹s first paper proposing this NDN concept (afaik) was in 2009.
> If we were to get into the ³way-back² machine to say 2003, when
> peer-2-peer was a big app, one might have then decided that we really need
> to make ³peer-2-peer² a first class citizen of the network.  In fact the
> IETF tried [at some level] to do this with the DECADE WG.  The app space
> evolved, p2p is no longer as prevalent, and DECADE saw/got little
> traction.  
> In 1998, we might have been thinking about making NNTP a first class
> citizen of the network.
> Maybe we need to think about making *software* [instead of a specific
> service] a first class citizen of the network.   What do I mean by this?
> If software were a first class citizen of our networks in 2003, we might
> have hopped onto our routers and done a ³yum install decade²‹ which would
> install software that would make the network eco system more efficient at
> supporting p2p traffic.
> Today, on our network eco system we might do a ³yum uninstall decade² and
> then do a ³yum install caching²‹ which might embed caching functionality
> into our routing eco system‹ hopefully making the delivery of cacheable
> content more efficient.
> In N years, when there is yet another new app pushing the network eco
> system, we might then be doing a ³yum uninstall caching² and instead doing
> a ³yum install new-app² which would make the network eco system more
> efficient at supporting this new-app.
> Brian
> On 9/5/14, 8:16 AM, "Jay Ashworth" <jra at> wrote:
>> How many Youtube subject tags will fit in *your* routers' TCAM?
>> sortium-to-replace-tcpip
>> [ Can someone convince me this isn't the biggest troll in the history
>> of the internet? Cause it sounds like shoehorning DNS /and Google/ into
>> IP in place of, y'know, IP addresses. ]
>> Cheers,
>> -- jra
>> -- 
>> Jay R. Ashworth                  Baylink
>> jra at
>> Designer                     The Things I Think                       RFC
>> 2100
>> Ashworth & Associates          2000 Land
>> Rover DII
>> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647
>> 1274

Murat Yuksel
Associate Professor
Graduate Director
Department of Computer Science and Engineering 
University of Nevada - Reno 
1664 N. Virginia Street, MS 171, Reno, NV 89557.
Phone: +1 (775) 327 2246, Fax: +1 (775) 784 1877
E-mail: yuksem at

More information about the NANOG mailing list