From jburke at remap.UCLA.EDU Wed Jul 1 05:55:56 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Wed, 1 Jul 2015 12:55:56 +0000 Subject: [Ndn-interest] Globecomm workshop on ICN deadline extended Message-ID: <909B3374-7DB7-45FA-BE01-D0CAAB928BB8@remap.ucla.edu> Please note this upcoming ICN workshop paper opportunity will have its deadline extended to July 15 - IEEE Globecom 15 Workshop on ICN Solutions for Real World Applications San Diego, CA, 6-10 December 2015 http://globecom2015.ieee-globecom.org/sites/globecom2015.ieee-globecom.org/files/u42/GC15_WS_ICNS_CFP.pdf http://globecom2015.ieee-globecom.org/ Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Wed Jul 1 19:30:38 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Wed, 1 Jul 2015 19:30:38 -0700 Subject: [Ndn-interest] NFD 0.3.3 and ndn-cxx 0.3.3 released Message-ID: Dear all, We are pleased to announce release of version 0.3.3 of Named Data Networking Forwarding Daemon (NFD) and ndn-cxx library. The detailed notes for the releases: - for NFD: http://named-data.net/doc/NFD/0.3.3/RELEASE_NOTES.html - for ndn-cxx library: http://named-data.net/doc/ndn-cxx/0.3.3/RELEASE_NOTES.html Source code, instruction how to install pre-compiled binaries on Ubuntu Linux (12.04, 14.04, and 15.04), how to install NDN software using MacPort packages or HomeBrew on OS X, tutorials, HOWTOs, a FAQ and other useful resources are available on official webpages of NFD and ndn-cxx: - http://named-data.net/doc/NFD/0.3.3/ - http://named-data.net/doc/ndn-cxx/0.3.3/ The latest version of NFD developer's guide: - http://named-data.net/publications/techreports/ndn-0021-4-nfd-developer-guide/. * * * A special welcome to new contributors: Eric Newberry, Jo?o Pereira, Yukai Tu, and Mickey Sweatt. * * * The NDN/NFD Team: Alexander Afanasyev, Junxiao Shi, Beichuan Zhang, Lixia Zhang, Ilya Moiseenko, Yingdi Yu, Wentao Shang, Yanbiao Li, Spyridon Mastorakis, Yi Huang, Jerald Paul Abraham, Steve DiBenedetto, Chengyu Fan, Christos Papadopoulos, Davide Pesavento, Giulio Grassi, Giovanni Pau, Hang Zhang, Tian Song, Haowei Yuan, Hila Ben Abraham, Patrick Crowley, Syed Obaid Amin, Vince Lehman, Lan Wang, Eric Newberry, and others (http://named-data.net/project/participants/) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alrrrr.mmmm at gmail.com Sat Jul 4 07:51:19 2015 From: alrrrr.mmmm at gmail.com (mana alliar) Date: Sat, 4 Jul 2015 19:21:19 +0430 Subject: [Ndn-interest] efficient lookup method Message-ID: Hello, My name is Mana Aliaar and I'm a student at shahid beheshti university of Tehran, Iran. i would appreciate it if you could help me. I'm currently working on "proposing an efficient routing in NDN" as my master thesis subject. following are some of the papers that i've read so far. Scalable Name Lookup in NDN Using Effective Name Component Encoding Wire Speed Name Lookup: A GPU-based Approach NameFilter: Achieving fast name lookup with low memory cost via applying two-stage Bloom filters and the main challenges that these papers express are: 1)Complex name structure:i)names consists of digits and characters; ii) names have variable length ; iii) the upper bound length of names are unknown. 2) and the size of the routing tables(PIT and FIB) which in NDN are 2 or 3 times larger than IP. __________________________________________________________________________________________________________________________ NOW, based on above papers that see lookup speed and forwarding table size as major challenges in routing in NDN. I've come to a lookup method: first for ENTERING THE NAMES IN TABLES: first each name is divided into multiple parts. an efficient hash function must be used for each name part. and the hash digest must be stored in a table. I was thinking of using some kind of indexing method here. like the hash result of first part of names must be stored in first level hash tables and the hash result of the second part of the name must be stored in second level hash tables. and so on. each entry in table has a pointer to a linked list which the complete names are stored there. and the rest of the name prefixes are sotored in linked lists. and for LOOKING UP THE NAME: first the hash result of first part is computed and found in first level hash table. then the second part is found and... the the rest of the name is found from the linked lists. __________________________________________________________________________________________________________________________ I have the following questions: 1) first of all i would like to know your idea about above papers: am i working on the right subject? i mean are these papers seeing the problem in NDN in the right way? are their work authentic? 2) second, about the proposed method: what is your idea about the above method? 3) if i'm on the wrong subject, can you please guide me to the right direction? can you suggest some similar works that has done on routing in NDN? It would be great to know your idea about these questions. __________________________________________________________________________________________________________________________ I will be eternally grateful for any help you can provide. Thank you. Aliaar -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.AbdollahiSabet at mail.sbu.ac.ir Sat Jul 4 13:25:46 2015 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Sun, 5 Jul 2015 00:55:46 +0430 Subject: [Ndn-interest] efficient lookup method References: Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2973@m-pdc.sbu.ac.ir> Hi Aliaar, What do you mean by parts? You mean name components? Then, what is going to be the first part? How are you going to define that? I mean, is going to be something like putting first components' digest in a table and link each entry to another table, list or something? Thanks, Sabet -----Original Message----- From: Ndn-interest on behalf of mana alliar Sent: Sat 7/4/2015 7:21 PM To: ndn-interest at lists.cs.ucla.edu Subject: [Ndn-interest] efficient lookup method Hello, My name is Mana Aliaar and I'm a student at shahid beheshti university of Tehran, Iran. i would appreciate it if you could help me. I'm currently working on "proposing an efficient routing in NDN" as my master thesis subject. following are some of the papers that i've read so far. Scalable Name Lookup in NDN Using Effective Name Component Encoding Wire Speed Name Lookup: A GPU-based Approach NameFilter: Achieving fast name lookup with low memory cost via applying two-stage Bloom filters and the main challenges that these papers express are: 1)Complex name structure:i)names consists of digits and characters; ii) names have variable length ; iii) the upper bound length of names are unknown. 2) and the size of the routing tables(PIT and FIB) which in NDN are 2 or 3 times larger than IP. __________________________________________________________________________________________________________________________ NOW, based on above papers that see lookup speed and forwarding table size as major challenges in routing in NDN. I've come to a lookup method: first for ENTERING THE NAMES IN TABLES: first each name is divided into multiple parts. an efficient hash function must be used for each name part. and the hash digest must be stored in a table. I was thinking of using some kind of indexing method here. like the hash result of first part of names must be stored in first level hash tables and the hash result of the second part of the name must be stored in second level hash tables. and so on. each entry in table has a pointer to a linked list which the complete names are stored there. and the rest of the name prefixes are sotored in linked lists. and for LOOKING UP THE NAME: first the hash result of first part is computed and found in first level hash table. then the second part is found and... the the rest of the name is found from the linked lists. __________________________________________________________________________________________________________________________ I have the following questions: 1) first of all i would like to know your idea about above papers: am i working on the right subject? i mean are these papers seeing the problem in NDN in the right way? are their work authentic? 2) second, about the proposed method: what is your idea about the above method? 3) if i'm on the wrong subject, can you please guide me to the right direction? can you suggest some similar works that has done on routing in NDN? It would be great to know your idea about these questions. __________________________________________________________________________________________________________________________ I will be eternally grateful for any help you can provide. Thank you. Aliaar -------------- next part -------------- An HTML attachment was scrubbed... URL: From hyuan at wustl.edu Sat Jul 4 22:02:40 2015 From: hyuan at wustl.edu (Haowei Yuan) Date: Sun, 5 Jul 2015 00:02:40 -0500 Subject: [Ndn-interest] efficient lookup method In-Reply-To: <49faeee259a94cb586b90d32565769cc@CY1PR02MB1706.namprd02.prod.outlook.com> References: <49faeee259a94cb586b90d32565769cc@CY1PR02MB1706.namprd02.prod.outlook.com> Message-ID: Hi Aliaar, Since you mentioned hashing, beside these papers, there are also several hash-based name prefix lookup methods that you might be interested, such as Reliably Scalable Name Prefix Lookup, ANCS 2015 Caesar: a content router for high-speed forwarding on content names, ANCS 2014 Fast Name Lookup for Named Data Networking, IWQoS 2014 Named data networking on a router: fast and dos-resistant forwarding with hash tables, ANCS 2013 Hope this helps. Haowei On Sat, Jul 4, 2015 at 9:51 AM, mana alliar wrote: > Hello, > My name is Mana Aliaar and I'm a student at shahid beheshti university of > Tehran, Iran. > i would appreciate it if you could help me. > I'm currently working on "proposing an efficient routing in NDN" as my > master thesis subject. > following are some of the papers that i've read so far. > Scalable Name Lookup in NDN Using Effective Name Component Encoding > > Wire Speed Name Lookup: A GPU-based Approach > > NameFilter: Achieving fast name lookup with low memory cost via applying > two-stage Bloom filters > > > and the main challenges that these papers express are: > 1)Complex name structure:i)names consists of digits and characters; ii) > names have variable length ; iii) the upper bound length of names are > unknown. > 2) and the size of the routing tables(PIT and FIB) which in NDN are 2 or 3 > times larger than IP. > > __________________________________________________________________________________________________________________________ > NOW, based on above papers that see lookup speed and forwarding table > size as major challenges in routing in NDN. I've come to a lookup method: > > first for ENTERING THE NAMES IN TABLES: first each name is divided into > multiple parts. an efficient hash function must be used for each name part. > and the hash digest must be stored in a table. > I was thinking of using some kind of indexing method here. like the hash > result of first part of names must be stored in first level hash tables and > the hash result of the second part of the name must be stored in second > level hash tables. and so on. > > each entry in table has a pointer to a linked list which the complete > names are stored there. and the rest of the name prefixes are sotored in > linked lists. > > and for LOOKING UP THE NAME: first the hash result of first part is > computed and found in first level hash table. then the second part is found > and... the the rest of the name is found from the linked lists. > > > __________________________________________________________________________________________________________________________ > I have the following questions: > 1) first of all i would like to know your idea about above papers: am i > working on the right subject? i mean are these papers seeing the problem in > NDN in the right way? are their work authentic? > 2) second, about the proposed method: what is your idea about the above > method? > 3) if i'm on the wrong subject, can you please guide me to the right > direction? can you suggest some similar works that has done on routing in > NDN? > It would be great to know your idea about these questions. > > __________________________________________________________________________________________________________________________ > I will be eternally grateful for any help you can provide. > Thank you. > Aliaar > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arunkd13 at gmail.com Sun Jul 5 01:27:48 2015 From: arunkd13 at gmail.com (Arunkumar Dhananjayan) Date: Sun, 5 Jul 2015 13:57:48 +0530 Subject: [Ndn-interest] efficient lookup method In-Reply-To: References: Message-ID: Hi Aliaar, I think you are tackling the right problem and I believe your research has good scope in improving the state of the art. You should surely read the papers you have mentioned and the ones suggested by Haowei. I see two directions in which you can proceed with your research: 1. Tackle the fundamental problem of efficient name lookup especially longest prefix matching on which NDN is based on, by coming up with a novel data structure or algorithm or 2. Take some of the existing proposed solutions and do a comparison study of them with data using a real life application I think more research is needed in both areas. wishing you the best, arun On Sat, Jul 4, 2015 at 8:21 PM, mana alliar wrote: > Hello, > My name is Mana Aliaar and I'm a student at shahid beheshti university of > Tehran, Iran. > i would appreciate it if you could help me. > I'm currently working on "proposing an efficient routing in NDN" as my > master thesis subject. > following are some of the papers that i've read so far. > Scalable Name Lookup in NDN Using Effective Name Component Encoding > > Wire Speed Name Lookup: A GPU-based Approach > > NameFilter: Achieving fast name lookup with low memory cost via applying > two-stage Bloom filters > > > and the main challenges that these papers express are: > 1)Complex name structure:i)names consists of digits and characters; ii) > names have variable length ; iii) the upper bound length of names are > unknown. > 2) and the size of the routing tables(PIT and FIB) which in NDN are 2 or 3 > times larger than IP. > > __________________________________________________________________________________________________________________________ > NOW, based on above papers that see lookup speed and forwarding table size > as major challenges in routing in NDN. I've come to a lookup method: > > first for ENTERING THE NAMES IN TABLES: first each name is divided into > multiple parts. an efficient hash function must be used for each name part. > and the hash digest must be stored in a table. > I was thinking of using some kind of indexing method here. like the hash > result of first part of names must be stored in first level hash tables and > the hash result of the second part of the name must be stored in second > level hash tables. and so on. > > each entry in table has a pointer to a linked list which the complete > names are stored there. and the rest of the name prefixes are sotored in > linked lists. > > and for LOOKING UP THE NAME: first the hash result of first part is > computed and found in first level hash table. then the second part is found > and... the the rest of the name is found from the linked lists. > > > __________________________________________________________________________________________________________________________ > I have the following questions: > 1) first of all i would like to know your idea about above papers: am i > working on the right subject? i mean are these papers seeing the problem in > NDN in the right way? are their work authentic? > 2) second, about the proposed method: what is your idea about the above > method? > 3) if i'm on the wrong subject, can you please guide me to the right > direction? can you suggest some similar works that has done on routing in > NDN? > It would be great to know your idea about these questions. > > __________________________________________________________________________________________________________________________ > I will be eternally grateful for any help you can provide. > Thank you. > Aliaar > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From setori88 at gmail.com Sun Jul 5 03:00:23 2015 From: setori88 at gmail.com (stewart mackenzie) Date: Sun, 5 Jul 2015 18:00:23 +0800 Subject: [Ndn-interest] efficient lookup method In-Reply-To: References: Message-ID: On 5 Jul 2015 16:28, "Arunkumar Dhananjayan" wrote: > 1. Tackle the fundamental problem of efficient name lookup especially longest prefix matching on which NDN is based on, by coming up with a novel data structure or algorithm please take a look at how numenta's nupic uses sparse distributed representation. https://m.youtube.com/watch?list=PLyh828DIg4wdSck2_H5A_KruczVscZXv6&v=LbZtc_zWBS4 When naming content one could convert the name into 2k bit SDR (only the index is transmitted to save bandwidth). Now when you add the content into your store the SDR is binary OR'ed into the content store. Thus future Interests just check PIT by binary AND'ing against the content. Now this is a constant nime operation, so you can efficiently determine if the content is there or not. Essentially I propose the naming mechanism for NDN should be SDR. /sjm -------------- next part -------------- An HTML attachment was scrubbed... URL: From tailinchu at gmail.com Sun Jul 5 03:57:02 2015 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Sun, 5 Jul 2015 18:57:02 +0800 Subject: [Ndn-interest] efficient lookup method In-Reply-To: References: Message-ID: I am working on a different problem but it also involves converting an NDN name to one specific bit pattern. But here is the common problem: NDN name space is essentially infinitely large, so the conversion process is lossy (we want these bit patterns to be more concise than names). If I understand the video correctly, (NDN name) >> (hashing 2^N) >> (SDR) >> means that the space is significantly larger. How does SDR solve any existing problem for NDN that comes from properties of any hashing function? Thanks. On Sun, Jul 5, 2015 at 6:00 PM, stewart mackenzie wrote: > > On 5 Jul 2015 16:28, "Arunkumar Dhananjayan" wrote: > >> 1. Tackle the fundamental problem of efficient name lookup especially >> longest prefix matching on which NDN is based on, by coming up with a novel >> data structure or algorithm > > please take a look at how numenta's nupic uses sparse distributed > representation. > > https://m.youtube.com/watch?list=PLyh828DIg4wdSck2_H5A_KruczVscZXv6&v=LbZtc_zWBS4 > > When naming content one could convert the name into 2k bit SDR (only the > index is transmitted to save bandwidth). > Now when you add the content into your store the SDR is binary OR'ed into > the content store. Thus future Interests just check PIT by binary AND'ing > against the content. > > Now this is a constant nime operation, so you can efficiently determine if > the content is there or not. > > Essentially I propose the naming mechanism for NDN should be SDR. > > /sjm > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From setori88 at gmail.com Sun Jul 5 04:39:53 2015 From: setori88 at gmail.com (stewart mackenzie) Date: Sun, 5 Jul 2015 19:39:53 +0800 Subject: [Ndn-interest] efficient lookup method In-Reply-To: References: Message-ID: Okay, Problems possibly solved using SDRs: * determining if content is on that node or not in constant time * get content which is semantically similar One names content not using hierarchical naming mechanisms but tags of semantic meanings. Please be aware, creating a SDRs is not hashing, indeed it's the opposite of hashing. If you really want to push the boundaries, try tying up nupic into NDN. Ie nupic predicts when you need data and pulls it down ahead of time... Problems possibly solved tying in CLAs (Cortical Learning Algorithms ie Nupic) into NDN: * learning about data patterns and initiating calls for that data AOT * just like a post office can forward packages if you're able to come up with some mapping technique to teach the CLAs you might be able to do something about NDNs forwarding issues. BTW is there a sane person on this list dropping the C++ implementation in favour of a Rust implementation? /sjm On 5 Jul 2015 18:57, "Tai-Lin Chu" wrote: > I am working on a different problem but it also involves converting an > NDN name to one specific bit pattern. > > But here is the common problem: NDN name space is essentially > infinitely large, so the conversion process is lossy (we want these > bit patterns to be more concise than names). > > If I understand the video correctly, > > (NDN name) >> (hashing 2^N) >> (SDR) > > >> means that the space is significantly larger. > > How does SDR solve any existing problem for NDN that comes from > properties of any hashing function? > > Thanks. > > > On Sun, Jul 5, 2015 at 6:00 PM, stewart mackenzie > wrote: > > > > On 5 Jul 2015 16:28, "Arunkumar Dhananjayan" wrote: > > > >> 1. Tackle the fundamental problem of efficient name lookup especially > >> longest prefix matching on which NDN is based on, by coming up with a > novel > >> data structure or algorithm > > > > please take a look at how numenta's nupic uses sparse distributed > > representation. > > > > > https://m.youtube.com/watch?list=PLyh828DIg4wdSck2_H5A_KruczVscZXv6&v=LbZtc_zWBS4 > > > > When naming content one could convert the name into 2k bit SDR (only the > > index is transmitted to save bandwidth). > > Now when you add the content into your store the SDR is binary OR'ed into > > the content store. Thus future Interests just check PIT by binary AND'ing > > against the content. > > > > Now this is a constant nime operation, so you can efficiently determine > if > > the content is there or not. > > > > Essentially I propose the naming mechanism for NDN should be SDR. > > > > /sjm > > > > > > _______________________________________________ > > Ndn-interest mailing list > > Ndn-interest at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arunkd13 at gmail.com Sun Jul 5 10:18:14 2015 From: arunkd13 at gmail.com (Arunkumar Dhananjayan) Date: Sun, 5 Jul 2015 22:48:14 +0530 Subject: [Ndn-interest] efficient lookup method In-Reply-To: References: Message-ID: I don't want to hijack this thread to discuss about SDRs, but can you enlighten me on how semantic similarity is ensured? I think to have semantic similarity that everyone agree upon, we need a common encoding that will be used by everyone. I listened through the talk and it was really interesting. I find SDRs quite similar to Bloom Filters and there is considerable literature on using bloom filters to implement content based routing, where a common hash function is used, but the hashes themselves do not represent any semantic meaning. I am finding it intriguing that each bit in an SDR has a semantic meaning. It is probably true within a single brain, because of the coordinated learning it did, but I am pretty sure, the semantic meaning of the bits in the SDR are different in each of our brains. Probably to achieve a common semantic meaning for each bit, the entire network should act as a single brain and keep learning continuously. Or probably retrieving semantically close data is out of the scope of NDN and should probably be left to a totally different 'Google' layer. The future looks interesting :-) regards, arun On Sun, Jul 5, 2015 at 5:09 PM, stewart mackenzie wrote: > Okay, > > Problems possibly solved using SDRs: > > * determining if content is on that node or not in constant time > * get content which is semantically similar > > One names content not using hierarchical naming mechanisms but tags of > semantic meanings. > > Please be aware, creating a SDRs is not hashing, indeed it's the opposite > of hashing. > > If you really want to push the boundaries, try tying up nupic into NDN. Ie > nupic predicts when you need data and pulls it down ahead of time... > > Problems possibly solved tying in CLAs (Cortical Learning Algorithms ie > Nupic) into NDN: > > * learning about data patterns and initiating calls for that data AOT > * just like a post office can forward packages if you're able to come up > with some mapping technique to teach the CLAs you might be able to do > something about NDNs forwarding issues. > > BTW is there a sane person on this list dropping the C++ implementation in > favour of a Rust implementation? > > /sjm > > On 5 Jul 2015 18:57, "Tai-Lin Chu" wrote: > >> I am working on a different problem but it also involves converting an >> NDN name to one specific bit pattern. >> >> But here is the common problem: NDN name space is essentially >> infinitely large, so the conversion process is lossy (we want these >> bit patterns to be more concise than names). >> >> If I understand the video correctly, >> >> (NDN name) >> (hashing 2^N) >> (SDR) >> >> >> means that the space is significantly larger. >> >> How does SDR solve any existing problem for NDN that comes from >> properties of any hashing function? >> >> Thanks. >> >> >> On Sun, Jul 5, 2015 at 6:00 PM, stewart mackenzie >> wrote: >> > >> > On 5 Jul 2015 16:28, "Arunkumar Dhananjayan" >> wrote: >> > >> >> 1. Tackle the fundamental problem of efficient name lookup especially >> >> longest prefix matching on which NDN is based on, by coming up with a >> novel >> >> data structure or algorithm >> > >> > please take a look at how numenta's nupic uses sparse distributed >> > representation. >> > >> > >> https://m.youtube.com/watch?list=PLyh828DIg4wdSck2_H5A_KruczVscZXv6&v=LbZtc_zWBS4 >> > >> > When naming content one could convert the name into 2k bit SDR (only the >> > index is transmitted to save bandwidth). >> > Now when you add the content into your store the SDR is binary OR'ed >> into >> > the content store. Thus future Interests just check PIT by binary >> AND'ing >> > against the content. >> > >> > Now this is a constant nime operation, so you can efficiently determine >> if >> > the content is there or not. >> > >> > Essentially I propose the naming mechanism for NDN should be SDR. >> > >> > /sjm >> > >> > >> > _______________________________________________ >> > Ndn-interest mailing list >> > Ndn-interest at lists.cs.ucla.edu >> > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From setori88 at gmail.com Sun Jul 5 11:54:29 2015 From: setori88 at gmail.com (stewart mackenzie) Date: Mon, 6 Jul 2015 02:54:29 +0800 Subject: [Ndn-interest] efficient lookup method In-Reply-To: References: Message-ID: On Mon, Jul 6, 2015 at 1:18 AM, Arunkumar Dhananjayan wrote: > I don't want to hijack this thread to discuss about SDRs, but can you > enlighten me on how semantic similarity is ensured? I would imagine shared language is the binding ensures semantic similarity. > I think to have semantic similarity that everyone agree upon, we need a > common encoding that will be used by everyone. > > I listened through the talk and it was really interesting. I find SDRs quite > similar to Bloom Filters and there is considerable literature on using bloom > filters to implement content based routing, where a common hash function is > used, but the hashes themselves do not represent any semantic meaning. I am > finding it intriguing that each bit in an SDR has a semantic meaning. It is > probably true within a single brain, because of the coordinated learning it > did, but I am pretty sure, the semantic meaning of the bits in the SDR are > different in each of our brains. > > Probably to achieve a common semantic meaning for each bit, the entire > network should act as a single brain and keep learning continuously. Or > probably retrieving semantically close data is out of the scope of NDN and > should probably be left to a totally different 'Google' layer. NDN is the "google layer", it will break the google, facebook, dropbox monopolies. Though it looks like http://www.cortical.io/technology.html has put down some very good foundations in this area. How about reverse engineering their process and incorporating it into the NDN mix? Though there would need to be some kind of classifier which would map SDR back to human readable words. Maybe the Nupic classifer is enough to do this? I don't know, there are many very interesting slants on this thought direction. If there are people interested in creating an POC implementation of this idea in Rust then lets collaborate. /sjm From alrrrr.mmmm at gmail.com Wed Jul 8 02:12:55 2015 From: alrrrr.mmmm at gmail.com (mana alliar) Date: Wed, 8 Jul 2015 13:42:55 +0430 Subject: [Ndn-interest] efficient lookup method In-Reply-To: References: Message-ID: many thanks for your great suggestions. On Sun, Jul 5, 2015 at 11:24 PM, stewart mackenzie wrote: > On Mon, Jul 6, 2015 at 1:18 AM, Arunkumar Dhananjayan > wrote: > > I don't want to hijack this thread to discuss about SDRs, but can you > > enlighten me on how semantic similarity is ensured? > > I would imagine shared language is the binding ensures semantic similarity. > > > I think to have semantic similarity that everyone agree upon, we need a > > common encoding that will be used by everyone. > > > > I listened through the talk and it was really interesting. I find SDRs > quite > > similar to Bloom Filters and there is considerable literature on using > bloom > > filters to implement content based routing, where a common hash function > is > > used, but the hashes themselves do not represent any semantic meaning. I > am > > finding it intriguing that each bit in an SDR has a semantic meaning. It > is > > probably true within a single brain, because of the coordinated learning > it > > did, but I am pretty sure, the semantic meaning of the bits in the SDR > are > > different in each of our brains. > > > > Probably to achieve a common semantic meaning for each bit, the entire > > network should act as a single brain and keep learning continuously. Or > > probably retrieving semantically close data is out of the scope of NDN > and > > should probably be left to a totally different 'Google' layer. > > NDN is the "google layer", it will break the google, facebook, dropbox > monopolies. > > Though it looks like http://www.cortical.io/technology.html has put > down some very good foundations in this area. > How about reverse engineering their process and incorporating it into > the NDN mix? > > Though there would need to be some kind of classifier which would map > SDR back to human readable words. > Maybe the Nupic classifer is enough to do this? > > I don't know, there are many very interesting slants on this thought > direction. > > If there are people interested in creating an POC implementation of > this idea in Rust then lets collaborate. > > /sjm > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan.rand at imperial.ac.uk Wed Jul 15 08:04:22 2015 From: duncan.rand at imperial.ac.uk (Duncan Rand) Date: Wed, 15 Jul 2015 16:04:22 +0100 Subject: [Ndn-interest] validator hanging Message-ID: <55A67676.4080604@imperial.ac.uk> Hello We are implementing signature validation. In order to familiarise ourselves with the process we're experimenting with the ndn-tool-set: https://github.com/chengyu/ndn-tool-set The validation works but processEvents then hangs (which it didn't before adding the validation). This seems to be triggered by the validator waiting for certificates in the cache to expire (the expiry is added to the asio queue) before returning. Is there any way around this? thanks Duncan From chengy.fan at gmail.com Wed Jul 15 09:49:57 2015 From: chengy.fan at gmail.com (Chengyu Fan) Date: Wed, 15 Jul 2015 10:49:57 -0600 Subject: [Ndn-interest] validator hanging In-Reply-To: <55A67676.4080604@imperial.ac.uk> References: <55A67676.4080604@imperial.ac.uk> Message-ID: Hi Duncan, Sorry to make you confused. The ndn-tool-set contains the tools for personal use. They are not mature code. To make the validation code work, you have to: 1. Follow the CERTIFICATE-CHAIN to generate the key chain 2. Run certs-publisher.cpp to publish producer certificate, but you need to specify the publisher's certificate ID in the onInterest(). For now, it is hard coded 3. Change the file name in the consumer code. The file contains the root certificate as the trust anchor 4. Run the producer and then the consumer to start the validation process On Wed, Jul 15, 2015 at 9:04 AM, Duncan Rand wrote: > Hello > > We are implementing signature validation. In order to familiarise > ourselves with the process we're experimenting with the > ndn-tool-set: > > https://github.com/chengyu/ndn-tool-set > > The validation works but processEvents then hangs (which it didn't before > adding the validation). This seems to be triggered by the validator waiting > for certificates in the cache to expire (the expiry is added to the asio > queue) before returning. Is there any way around this? > > thanks > Duncan > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > -- Thanks, Chengyu -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan.rand at imperial.ac.uk Wed Jul 15 11:08:10 2015 From: duncan.rand at imperial.ac.uk (Duncan Rand) Date: Wed, 15 Jul 2015 19:08:10 +0100 Subject: [Ndn-interest] validator hanging In-Reply-To: References: <55A67676.4080604@imperial.ac.uk> Message-ID: Hi Chengyu Yes, we've done the steps you list and indeed the validation works, but as I said the code hangs in processEvents. Our code shows the same problem. regards Duncan On 15 Jul 2015, at 17:49, Chengyu Fan wrote: > Hi Duncan, > > Sorry to make you confused. The ndn-tool-set contains the tools for personal use. They are not mature code. > > To make the validation code work, you have to: > > 1. Follow the CERTIFICATE-CHAIN to generate the key chain > 2. Run certs-publisher.cpp to publish producer certificate, but you need to specify the publisher's certificate ID in the onInterest(). For now, it is hard coded > 3. Change the file name in the consumer code. The file contains the root certificate as the trust anchor > 4. Run the producer and then the consumer to start the validation process > > On Wed, Jul 15, 2015 at 9:04 AM, Duncan Rand wrote: > Hello > > We are implementing signature validation. In order to familiarise ourselves with the process we're experimenting with the > ndn-tool-set: > > https://github.com/chengyu/ndn-tool-set > > The validation works but processEvents then hangs (which it didn't before adding the validation). This seems to be triggered by the validator waiting for certificates in the cache to expire (the expiry is added to the asio queue) before returning. Is there any way around this? > > thanks > Duncan > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > > -- > Thanks, > > Chengyu -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2989 bytes Desc: not available URL: From vslehman at memphis.edu Wed Jul 15 12:36:13 2015 From: vslehman at memphis.edu (Vince Lehman (vslehman)) Date: Wed, 15 Jul 2015 19:36:13 +0000 Subject: [Ndn-interest] Mini-NDN initial release Message-ID: <24F08906-8E3A-471E-A639-C3623DE11F8D@memphis.edu> Dear all, We are pleased to announce the initial release of Mini-NDN (v0.1.0). Mini-NDN is a lightweight networking emulation tool that enables testing, experimentation, and research on the NDN platform. Based on Mininet, Mini-NDN uses the NDN libraries, NFD, NLSR, and tools released by the NDN project (http://named-data.net/codebase/platform/) to emulate an NDN network on a single system. Detailed release notes with included features can be found at: https://github.com/named-data/mini-ndn/blob/master/docs/RELEASE-NOTES.md More information about Mini-NDN, tutorials, installation and configuration guides, and documentation are available at the Mini-NDN Github repository: https://github.com/named-data/mini-ndn Please report any bugs or issues, make feature requests, or provide feedback at our Redmine page: http://redmine.named-data.net/projects/mini-ndn * * * Mini-NDN Developers and Contributors: Ashlesh Gawande, Vince Lehman, Lan Wang, Alexander Afanasyev, Junxiao Shi, Beichuan Zhang -- Vince Lehman -------------- next part -------------- An HTML attachment was scrubbed... URL: From chengy.fan at gmail.com Wed Jul 15 19:48:03 2015 From: chengy.fan at gmail.com (Chengyu Fan) Date: Wed, 15 Jul 2015 20:48:03 -0600 Subject: [Ndn-interest] validator hanging In-Reply-To: References: <55A67676.4080604@imperial.ac.uk> Message-ID: Hi Duncan, Sorry I misunderstood your question. For the processEvents hanging, you may use m_face->getIoService().stop() to stop the ioservice when the job is done. On Wed, Jul 15, 2015 at 12:08 PM, Duncan Rand wrote: > Hi Chengyu > > Yes, we've done the steps you list and indeed the validation works, but as > I said the code hangs in processEvents. Our code shows the same problem. > > regards > Duncan > > On 15 Jul 2015, at 17:49, Chengyu Fan wrote: > > > Hi Duncan, > > > > Sorry to make you confused. The ndn-tool-set contains the tools for > personal use. They are not mature code. > > > > To make the validation code work, you have to: > > > > 1. Follow the CERTIFICATE-CHAIN to generate the key chain > > 2. Run certs-publisher.cpp to publish producer certificate, but you need > to specify the publisher's certificate ID in the onInterest(). For now, it > is hard coded > > 3. Change the file name in the consumer code. The file contains the root > certificate as the trust anchor > > 4. Run the producer and then the consumer to start the validation process > > > > On Wed, Jul 15, 2015 at 9:04 AM, Duncan Rand > wrote: > > Hello > > > > We are implementing signature validation. In order to familiarise > ourselves with the process we're experimenting with the > > ndn-tool-set: > > > > https://github.com/chengyu/ndn-tool-set > > > > The validation works but processEvents then hangs (which it didn't > before adding the validation). This seems to be triggered by the validator > waiting for certificates in the cache to expire (the expiry is added to the > asio queue) before returning. Is there any way around this? > > > > thanks > > Duncan > > _______________________________________________ > > Ndn-interest mailing list > > Ndn-interest at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > > > > > > -- > > Thanks, > > > > Chengyu > > -- Thanks, Chengyu -------------- next part -------------- An HTML attachment was scrubbed... URL: From kc at caida.org Thu Jul 16 13:10:12 2015 From: kc at caida.org (k claffy) Date: Thu, 16 Jul 2015 13:10:12 -0700 Subject: [Ndn-interest] NDNcomm registration page is up -- please help us create an agenda Message-ID: <20150716201012.GA6233@caida.org> hi folks, NDNcomm web page is up: http://www.caida.org/workshops/ndn/1509/ with link to registration page: http://www.caida.org/workshops/ndn/1509/register.xml note that this is not merely a register-my-interest-in-attending page, but also a register-my-interest-in-participating page, because the draft agenda we put up in august will largely be a function of what you offer to present on, as well other comments you may make in this form. please register by 15 aug, so we have some time to iterate on the agenda a bit. based on feedback from last year, we will do some breakouts, i.e., split into groups so that we can cover more topics of more direct interest to subgroups. we will end by 3pm on day 2 (tue) so folks have time to get up to SF for ICN. thanks, k From ndn at sqh.me Sun Jul 19 19:39:01 2015 From: ndn at sqh.me (ndn ndn) Date: Mon, 20 Jul 2015 10:39:01 +0800 Subject: [Ndn-interest] What is difference between FIB and RIB? Message-ID: FIB is Forward Information base,I think it just like a route table in IP protocol.But I got confused when I see RIB,It seems like FIB.So, What difference between them? -------------- next part -------------- An HTML attachment was scrubbed... URL: From spiros.mastorakis at gmail.com Sun Jul 19 22:55:29 2015 From: spiros.mastorakis at gmail.com (Spyridon (Spyros) Mastorakis) Date: Sun, 19 Jul 2015 22:55:29 -0700 Subject: [Ndn-interest] What is difference between FIB and RIB? In-Reply-To: References: Message-ID: Hello, I will try to elaborate on this a little bit. You can think of FIB as the FIB of IP with the following difference: Instead of IP address prefixes, it contains name prefixes and instead of a single outgoing interface, each entry may contain a list of outgoing faces. RIB stands for ?Routing Information Base? and it is mainly populated by routing protocols (e.g., NLSR). Technically speaking, RIB can also be populated by applications for prefix registration or manually by the network administrator. FIB entries come from RIB entries. That is, FIB updates are triggered by RIB updates. The goal is, based on the RIB entries, to create a consistent forwarding table. This is done by the RIB management module. One RIB update may also generate a number of FIB updates. For more technical details, I would suggest that you take a look at the latest version of the NFD developer guide: http://named-data.net/wp-content/uploads/2015/05/ndn-0021-4-nfd-developer-guide.pdf -- Spyridon (Spyros) Mastorakis Personal Website: http://cs.ucla.edu/~mastorakis/ Internet Research Laboratory PhD Computer Science UCLA > On Jul 19, 2015, at 7:39 PM, ndn ndn wrote: > > FIB is Forward Information base,I think it just like a route table in IP protocol.But I got confused when I see RIB,It seems like FIB.So, What difference between them? > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From ndn at sqh.me Sun Jul 19 23:45:40 2015 From: ndn at sqh.me (ndn ndn) Date: Mon, 20 Jul 2015 14:45:40 +0800 Subject: [Ndn-interest] What is difference between FIB and RIB? In-Reply-To: References: Message-ID: The explain is clear,I think I understand it.I will read NFD developer guide for find more information. BTW: if I run command nfdc create or nfd-autoreg,is it means that application will add a route entry in RIB not FIB.And after that, FIB was updated by RIB trigger. thanks for your reply. 2015-07-20 13:55 GMT+08:00 Spyridon (Spyros) Mastorakis < spiros.mastorakis at gmail.com>: > Hello, > > I will try to elaborate on this a little bit. > > You can think of FIB as the FIB of IP with the following difference: > > Instead of IP address prefixes, it contains name prefixes and instead of a > single outgoing interface, each entry may contain a list of outgoing faces. > > RIB stands for ?Routing Information Base? and it is mainly populated by > routing protocols (e.g., NLSR). Technically speaking, RIB can also be > populated by applications for prefix registration or manually by the > network administrator. > > FIB entries come from RIB entries. That is, FIB updates are triggered by > RIB updates. The goal is, based on the RIB entries, to create a consistent > forwarding table. This is done by the RIB management module. One RIB update > may also generate a number of FIB updates. > > For more technical details, I would suggest that you take a look at the > latest version of the NFD developer guide: > > > http://named-data.net/wp-content/uploads/2015/05/ndn-0021-4-nfd-developer-guide.pdf > > -- > Spyridon (Spyros) Mastorakis > Personal Website: http://cs.ucla.edu/~mastorakis/ > Internet Research Laboratory > PhD Computer Science > UCLA > > > > > > On Jul 19, 2015, at 7:39 PM, ndn ndn wrote: > > > > FIB is Forward Information base,I think it just like a route table in IP > protocol.But I got confused when I see RIB,It seems like FIB.So, What > difference between them? > > _______________________________________________ > > Ndn-interest mailing list > > Ndn-interest at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.goudarzi at mail.sbu.ac.ir Sun Jul 26 23:08:48 2015 From: f.goudarzi at mail.sbu.ac.ir (fatemeh goudarzi) Date: Mon, 27 Jul 2015 10:38:48 +0430 Subject: [Ndn-interest] (no subject) Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03F43000@m-pdc.sbu.ac.ir> Hello everyone, I'm a newcomer to NDN and having read some basic papers, I've come to have some question mostly in the security realm: 1. It is indicated(Jacobson, et al. 2009) that retrieving a content by its publisher is possible as well as by its name. Is it some sort of security mechanism in case of retrieving data which is corrupted by someone, or some alternative for retrieving by name? If latter, is there any vision how Interest/Data is going to be like in that case? I mean it is clear how NDN works by using contents' names. Routing protocols (eg, NLSR) use names. There is also a naming convention for contents as well. But how about publishers? 2. On evidence-based security. Is it something like reputation based trust mechanisms in Bittorrent protocol? If so, how are consumers supposed know of a content's reputation or a publisher's trustworthiness? Actually I'm not sure if I perceived meaning of _secure_ link correctly. Could you elaborate on these a little bit, please? 3. Do we have a definition for the notion of _Identity framework_? As a matter of fact, I don't understand when some one(Van) says privacy and trust frameworks are semantically derived form identity model. What are the specifications, or expectations maybe, that the community has about identity framework? I will be very thankful If you could have a saying. ? Thanks, Fatemeh Goudarzi? -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.AbdollahiSabet at mail.sbu.ac.ir Wed Jul 29 09:52:47 2015 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Wed, 29 Jul 2015 21:22:47 +0430 Subject: [Ndn-interest] (no subject) References: <4AC03A6244C3C34BB52A7EC60B799C4C03F43000@m-pdc.sbu.ac.ir> Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2982@m-pdc.sbu.ac.ir> Hi, With regard to question 1 I think yes. Retrieving content by publisher name/id is a kind of filter anticipated in the packet format. At least I haven't seen the latter interpretation yet, and haven't considered it. But I don't think there would be an architectural prevention for applications to answer an interest in which no specific content is defined, but a publisher id is given. Of course there may be some privacy considerations, but that is application developers' decision on what violates privacy and how to protect that. Unfortunately I have nothing to say about the 2nd question and the 3rd. Thanks, Sabet -----Original Message----- From: Ndn-interest on behalf of fatemeh goudarzi Sent: Mon 7/27/2015 10:38 AM To: ndn-interest at lists.cs.ucla.edu Subject: [Ndn-interest] (no subject) Hello everyone, I'm a newcomer to NDN and having read some basic papers, I've come to have some question mostly in the security realm: 1. It is indicated(Jacobson, et al. 2009) that retrieving a content by its publisher is possible as well as by its name. Is it some sort of security mechanism in case of retrieving data which is corrupted by someone, or some alternative for retrieving by name? If latter, is there any vision how Interest/Data is going to be like in that case? I mean it is clear how NDN works by using contents' names. Routing protocols (eg, NLSR) use names. There is also a naming convention for contents as well. But how about publishers? 2. On evidence-based security. Is it something like reputation based trust mechanisms in Bittorrent protocol? If so, how are consumers supposed know of a content's reputation or a publisher's trustworthiness? Actually I'm not sure if I perceived meaning of _secure_ link correctly. Could you elaborate on these a little bit, please? 3. Do we have a definition for the notion of _Identity framework_? As a matter of fact, I don't understand when some one(Van) says privacy and trust frameworks are semantically derived form identity model. What are the specifications, or expectations maybe, that the community has about identity framework? I will be very thankful If you could have a saying. ? Thanks, Fatemeh Goudarzi? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndn at sqh.me Wed Jul 29 18:58:38 2015 From: ndn at sqh.me (ndn ndn) Date: Thu, 30 Jul 2015 09:58:38 +0800 Subject: [Ndn-interest] how to set freshnessSecond? Message-ID: Hello everyone, I'm using NDN-CCL to writing a NDN application. But I find a problem about data cache. In NDN network ,all data can store in CS.But in my application,some content always changing in 5 seconds,so I think setting a freshnessSecond will help me solve this problem. I try to setMustBefresh value,but it not works.The app also receive the cached value. But in NDN-CCL,I didn't find any method to set this?how to set it? hope you give me some reply. thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dibenede at cs.colostate.edu Wed Jul 29 19:15:40 2015 From: dibenede at cs.colostate.edu (Steve DiBenedetto) Date: Wed, 29 Jul 2015 20:15:40 -0600 Subject: [Ndn-interest] how to set freshnessSecond? In-Reply-To: References: Message-ID: On Wed, Jul 29, 2015 at 7:58 PM, ndn ndn wrote: > Hello everyone, > I'm using NDN-CCL to writing a NDN application. But I find a problem about > data cache. > In NDN network ,all data can store in CS.But in my application,some > content always changing in 5 seconds,so I think setting a freshnessSecond > will help me solve this problem. > I try to setMustBefresh value,but it not works.The app also receive the > cached value. > But in NDN-CCL,I didn't find any method to set this?how to set it? > > hope you give me some reply. > > thanks. > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > Please correct me if I'm wrong, but it sounds like you're trying to ensure the retrieving application always gets the latest data. "Must be fresh" tells NDN nodes to to return Data that have not yet expired. Data with a freshness period of 5 seconds will satisfy a "must be fresh" Interests for 5 seconds. The timer is with respect to when the Data arrived at the node. Depending on the details of your application, you can try a couple things: 1. Set a conservative freshness period (e.g. 1 second). This will result in more Interests reaching the publisher, but mitigate stale Data retrieval. 2. Minimize the freshness period (e.g. 0 ms) so that the content is effectively never fresh. You can combine either approach with the CCL's publisher cache: http://named-data.net/doc/ndn-ccl-api/memory-content-cache.html . Your application can insert Data packets into this application content cache and then query it as Interests arrive. Note, you may need to set the cleanup timer value to something big to prevent it from removing the technically stale Data packets. However, this should simplify the publisher's implementation and keeping your consumers up to date. Hope that helps, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndn at sqh.me Wed Jul 29 19:48:18 2015 From: ndn at sqh.me (ndn ndn) Date: Thu, 30 Jul 2015 10:48:18 +0800 Subject: [Ndn-interest] how to set freshnessSecond? In-Reply-To: References: Message-ID: Dear Steve, Thanks for you reply,I think I misunderstood "Must be fresh" literally. In my point of view,"Must be fresh" means ndn Interests must get the newest data from publisher. Set a freshness period can help me to solve it.At first,I didn't find any way to set freshness value,but now I find it though you help.just using Data. getMetaInfo() and set it. MemoryContentCache is a good way to acheive it,I will try it. Thanks for your help and reply, forgive my poor english spell. qhsong 2015-07-30 10:15 GMT+08:00 Steve DiBenedetto : > > > On Wed, Jul 29, 2015 at 7:58 PM, ndn ndn wrote: > >> Hello everyone, >> I'm using NDN-CCL to writing a NDN application. But I find a problem >> about data cache. >> In NDN network ,all data can store in CS.But in my application,some >> content always changing in 5 seconds,so I think setting a freshnessSecond >> will help me solve this problem. >> I try to setMustBefresh value,but it not works.The app also receive the >> cached value. >> But in NDN-CCL,I didn't find any method to set this?how to set it? >> >> hope you give me some reply. >> >> thanks. >> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> >> > Please correct me if I'm wrong, but it sounds like you're trying to ensure > the retrieving application always gets the latest data. > > "Must be fresh" tells NDN nodes to to return Data that have not yet > expired. Data with a freshness period of 5 seconds will satisfy a "must be > fresh" Interests for 5 seconds. The timer is with respect to when the Data > arrived at the node. > > Depending on the details of your application, you can try a couple things: > > 1. Set a conservative freshness period (e.g. 1 second). This will > result in more Interests reaching the publisher, but mitigate stale Data > retrieval. > 2. Minimize the freshness period (e.g. 0 ms) so that the content is > effectively never fresh. > > You can combine either approach with the CCL's publisher cache: > http://named-data.net/doc/ndn-ccl-api/memory-content-cache.html . Your > application can insert Data packets into this application content cache and > then query it as Interests arrive. Note, you may need to set the cleanup > timer value to something big to prevent it from removing the technically > stale Data packets. However, this should simplify the publisher's > implementation and keeping your consumers up to date. > > Hope that helps, > Steve > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at caida.org Thu Jul 30 17:02:52 2015 From: josh at caida.org (Josh Polterock) Date: Thu, 30 Jul 2015 17:02:52 -0700 Subject: [Ndn-interest] Named Data Networking (NDN) Project Monthly Newsletter for July 2015 Message-ID: <20150731000252.GB31200@caida.org> Named Data Networking (NDN) Project Monthly Newsletter for July 2015 The NDN project team compiles and publishes this newletter monthly to inform the community about recent activities, technical news, meetings, publications, presentations, code releases, and upcoming events. You can find these newsletters posted on the Named Data Networking Project blog. COMMUNITY OUTREACH * Plans continue for the NDN Community Meeting (NDNComm 2015) at the University of California at Los Angeles campus in the Little Theater, MacGowan Hall, UCLA on 28-29 September 2015. Registration is open on the web at http://www.caida.org/workshops/ndn/1509/ . * Hackathon: 26-27 September 2015. We are excited to announce the first NDN hackathon scheduled prior to the upcoming NDNComm 2015. The organizers welcome participants across all experience levels and are reaching out to the community for project suggestions. If you have an idea for a project, please email Steve DiBenedetto (dibenede at cs.colostate.edu). Project representatives will pitch their ideas to hackathon attendees and act as guides/mentors. We also plan projects suitable for NDN newcomers. Please stay tuned to http://www.caida.org/workshops/ndn/1509/#hackathon . We hope to see you in LA! TECHNICAL NEWS * We announceed the release of version 0.3.3 of Named Data Networking Forwarding Daemon (NFD) and ndn-cxx library. Please find detailed release notes: - NFD: http://named-data.net/doc/NFD/0.3.3/RELEASE_NOTES.html - ndn-cxx library: http://named-data.net/doc/ndn-cxx/0.3.3/RELEASE_NOTES.html More details about NFD, source code, install instructions, tutorials, HOWTOs, a FAQ and other useful resources are available on the official webpages of NFD and ndn-cxx: - http://named-data.net/doc/NFD/0.3.3/ - http://named-data.net/doc/ndn-cxx/0.3.3/ The latest version of NFD developer's guide: - http://named-data.net/publications/techreports/ndn-0021-4-nfd-developer-guide/ * New support in NDN-CPP for asynchronous I/O using the Boost ASIO io_service for processing events in a thread-safe way. The NDN-CPP client library now optionally supports Boost's ASIO for more CPU-efficient asynchronous I/O and to make library calls thread-safe. For more details, see this announcement: http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2015-July/000303.html * We are pleased to announce the initial release of Mini-NDN (v0.1.0), a lightweight networking emulation tool that enables testing, experimentation, and research on the NDN platform. Please find detailed release notes at: https://github.com/named-data/mini-ndn/blob/master/docs/RELEASE-NOTES.md More information about Mini-NDN, tutorials, installation and configuration guides, and documentation are available at the Mini-NDN Github repository: https://github.com/named-data/mini-ndn NDN PUBLICATIONS, PRESENTATIONS, and TECHNICAL REPORTS * We are pleased to report four papers, covering a wide spectrum of topics from applications to API to security to scalable forwarding, accepted to the 2nd ACM Conference on Information-Centric Networking (ICN 2015) to be held Sep 30 - Oct 2 2015 in San Francisco, CA.. I. Moiseenko, L. Wang, L. Zhang, "Consumer / Producer communication with application level framing in Named Data Networking". T. Song, H. Yuan, P. Crowley, B. Zhang, "Scalable Name-Based Packet Forwarding: From Millions to Billions". Y. Yu, A. Afanasyev, D. Clark, k. claffy, V. Jacobson, L. Zhang, "Schematizing and Automating Trust in Named Data Networking". P. Gusev, J. Burke, "NDN-RTC: Real-time videoconferencing over Named Data Networking". * NDN TR-33 Revision 1: P. Gusev and J. Burke, "NDN-RTC: Real-time videoconferencing over Named Data Networking" presents the design, implementation in C++, and testing of NDN-RTC on the NDN testbed, using a demonstration GUI conferencing application, NdnCon. This report is the submitted version of the ICN paper listed above. http://named-data.net/publications/techreports/ndntr-0033-ndnrtc/ NDN SEMINARS * Our NDN Seminar series continued during July. The NDN seminars are internally focused. We usually hold these seminars on Wednesday from 2-3p (PST). So, if you would like to be included in the NDN Seminars, please contact Jongdeog Lee for the most up-to-date information regarding upcoming seminars. - July 15th Ashlesh Gawande (Univ. of Memphis) presented: Mini-NDN: A light weight emulation tool for Named Data Networking RELATED NEWS * MIT Professor David Clark and NDN PI k claffy, published "Comments on Cybersecurity Research and Development Strategic Plan" in response to a Request for Information (RFI)-Federal Cybersecurity R&D Strategic Plan, posted by the National Science Foundation on 4/27/2015. https://www.federalregister.gov/articles/2015/04/27/2015-09697/request-for-information-rfi-federal-cybersecurity-randd-strategic-plan http://www.caida.org/publications/papers/2015/comments_cybersecurity_research_development/ * PI k claffy blogged about her contribution on a panel on cyberwarfare and cyberattacks at the 9th Circuit Judicial Conference held in San Diego. Though not directly related to NDN, the blog demonstrates the need for it. k used a visualization of a botnet scanning the entire IPv4 address space to illustrate technical, economic, and legal dimensions of the ecosystem that render the fundamental vulnerabilities of today's Internet infrastructure so persistent and pernicious. http://blog.caida.org/best_available_data/2015/07/20/panel-on-cyberwarfar-and-cyberattacks-at-9th-circuit-judicial-conference/ For more information about the Named Data Networking (NDN) Project please visit http://www.named-data.net/.