From lanwang at memphis.edu Wed Oct 1 07:56:43 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 1 Oct 2014 14:56:43 +0000 Subject: [Nfd-dev] Fwd: Strategy for testbed routers References: <56171789-E87B-4157-BCB0-6D04CCDB74F7@memphis.edu> Message-ID: Begin forwarded message: From: Lan Wang > Subject: Re: [Nfd-dev] Strategy for testbed routers Date: October 1, 2014 9:56:30 AM CDT To: Junxiao Shi > On Sep 30, 2014, at 6:43 PM, Junxiao Shi > wrote: Hi Lan 1. Yes, the root cause is that laptops are unable to register a precise prefix on the access router. The most effective solution is to enable remote prefix registration on the access router. 2. NCC strategy forwards an Interest to a nexthop, and that nexthop is never used again before InterestLifetime expires. When there is a packet loss, even if the consumer is able to detect that and retransmit the Interest, the retransmission is suppressed by NCC strategy because it won't forward the Interest again to the same nexthop. When a Data does not reach consumer before it's needed, the video frame cannot be constructed and cannot play out. If the Interest was forwarded along some alternative paths by NCC, then it should still reach the producer and bring back the data, right? And if the primary path is not working, sending the Interest there again probably won't help much either. I just want to have a clear understanding of this problem for NDN-RTC on the testbed and then it's more clear how a more effective strategy should work. 3. Link state routing can ensure all nexthops in FIB entry can reach the destination. Backbone strategy is designed for this scenario. Strategy choice depends on network environment and application needs. Hyperbolic routing might need a different strategy. I'm not sure if the forwarding strategy should make an assumption of what routing protocol is used. After all, the routing protocol may be relying on the forwarding strategy to fix some of the temporary problems so that it doesn't have to respond as quickly as in an IP network (Cheng's paper). 4. The distinction between remote prefixes and local site prefix is: remote prefixes have mostly reachable nexthops and less changes (when link state routing is used), local site prefix suffers more from unreachable nexthops and laptop mobility. I don't know whether there is a major difference in the structure of those two forwarding strategies, but they will at least differ in some parameter settings. It seems to me that as long as the forwarding strategy satisfies the requirement of "Make use of multiple paths in FIB entry, and learn the best path.", then it can handle various failure situations (whether they are caused by laptop mobility or link failures). It would be better if you can make it clear what extra is required for local site prefix. Lan Yours, Junxiao On Tue, Sep 30, 2014 at 10:00 AM, Lan Wang (lanwang) > wrote: Junxiao, Just a few questions and comments: 1. I remember the problem NDN-RTC had is the following: they have two producers connected to the same HUB, but the autoreg server gives them the same prefix even though they serve different content (each producer serves the data from a different camera). Therefore, the forwarding strategy routes all the Interests to one of those producers (best route) or oscillates between the two producers (ncc). They have to use broadcast strategy to get this work. If this is the problem you are referring to, then the problem is not the forwarding strategy, but the lack of a way for the laptops to register their own prefixes with the hub (under the hub's prefix). Is this the problem you are referring to? 2. Can you explain a bit the relationship between "NCC strategy suppresses all consumer retransmissions" and "any packet loss prevents playout of a video frame"? 3. Even on the backbone, you cannot be sure that all the available next hops in the FIB should lead you to the destination. This really depends on the routing protocol. If hyperbolic routing is used, it's possible that some of the next hops do not lead to the destination (due to local minima) and we have observed this. 4. Given the above, I do not feel that there is any major difference between the requirements for remote strategy and local strategy. The following two seem to be enough: > ? Make use of multiple paths in FIB entry, and learn the best path. > ? Recovery from packet loss Lan -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Oct 1 19:50:17 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 1 Oct 2014 19:50:17 -0700 Subject: [Nfd-dev] Strategy for testbed routers In-Reply-To: <56171789-E87B-4157-BCB0-6D04CCDB74F7@memphis.edu> References: <56171789-E87B-4157-BCB0-6D04CCDB74F7@memphis.edu> Message-ID: Hi Lan 2. The problem is not "primary path is not working", but "primary path is working most of the time, but happens to lose one packet". Retrying on the same path helps. 3. Forwarding strategy need not make an assumption on what routing protocol is used, but it should know the quality of paths. High quality routes (such as those from link state routing) can reach the destination UNLESS there's a fault. Retrying is less aggressive, and a temporarily failed path is expected to come back shortly so probing is frequent. Low quality routes (such as those from autoreg-server) are more likely to be incorrect. Retrying is aggressive, and a path that does not work is assumed to be an incorrect path so probing is infrequent. 4. Backbone router strategy assumes all paths can reach the destination UNLESS there's a fault. If there's a fault, Interests go to backup path, but probing is frequent so that traffic can switch back to primary path once it comes back. Access router strategy. When a working path is found, probing on other paths is infrequent. When producer is believed to be moved, the strategy won't expect the old path to work again until the new path fails (which means producer is moving again). Yours, Junxiao On Wed, Oct 1, 2014 at 7:56 AM, Lan Wang (lanwang) wrote: > > On Sep 30, 2014, at 6:43 PM, Junxiao Shi > wrote: > > Hi Lan > > 1. > Yes, the root cause is that laptops are unable to register a precise > prefix on the access router. > The most effective solution is to enable remote prefix registration on the > access router. > > 2. > NCC strategy forwards an Interest to a nexthop, and that nexthop is never > used again before InterestLifetime expires. > When there is a packet loss, even if the consumer is able to detect that > and retransmit the Interest, the retransmission is suppressed by NCC > strategy because it won't forward the Interest again to the same nexthop. > When a Data does not reach consumer before it's needed, the video frame > cannot be constructed and cannot play out. > > > If the Interest was forwarded along some alternative paths by NCC, then > it should still reach the producer and bring back the data, right? And if > the primary path is not working, sending the Interest there again probably > won't help much either. I just want to have a clear understanding of this > problem for NDN-RTC on the testbed and then it's more clear how a more > effective strategy should work. > > > 3. > Link state routing can ensure all nexthops in FIB entry can reach the > destination. > Backbone strategy is designed for this scenario. > > Strategy choice depends on network environment and application needs. > Hyperbolic routing might need a different strategy. > > > I'm not sure if the forwarding strategy should make an assumption of what > routing protocol is used. After all, the routing protocol may be relying > on the forwarding strategy to fix some of the temporary problems so that it > doesn't have to respond as quickly as in an IP network (Cheng's paper). > > > 4. > The distinction between remote prefixes and local site prefix is: remote > prefixes have mostly reachable nexthops and less changes (when link state > routing is used), local site prefix suffers more from unreachable nexthops > and laptop mobility. > I don't know whether there is a major difference in the structure of those > two forwarding strategies, but they will at least differ in some parameter > settings. > > > It seems to me that as long as the forwarding strategy satisfies the > requirement of "Make use of multiple paths in FIB entry, and learn the best > path.", then it can handle various failure situations (whether they are > caused by laptop mobility or link failures). It would be better if you can > make it clear what extra is required for local site prefix. > > Lan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haroonr at iiitd.ac.in Thu Oct 2 00:22:40 2014 From: haroonr at iiitd.ac.in (Haroon Rashid) Date: Thu, 2 Oct 2014 12:52:40 +0530 Subject: [Nfd-dev] Error while installing NDN-CPP Message-ID: Hello All, I am getting an error while installing NDN_CPP. I have included also the screen shot of error message. I am working on Ubuntu 12.04 LTS. Can someone help me to come out of this issue. haroon at hp-envy:~/ndn-cpp-master$ make Making all in include make[1]: Entering directory `/home/haroon/ndn-cpp-master/include' make all-am make[2]: Entering directory `/home/haroon/ndn-cpp-master/include' make[2]: Leaving directory `/home/haroon/ndn-cpp-master/include' make[1]: Leaving directory `/home/haroon/ndn-cpp-master/include' make[1]: Entering directory `/home/haroon/ndn-cpp-master' /bin/bash ./libtool --tag=CXX --mode=link g++ -g -O2 -std=gnu++0x -o bin/test-echo-consumer tests/test-echo-consumer.o libndn-cpp.la -lpthread -lprotobuf -llog4cxx -lsqlite3 -lcrypto libtool: link: g++ -g -O2 -std=gnu++0x -o bin/.libs/test-echo-consumer tests/test-echo-consumer.o ./.libs/libndn-cpp.so -lpthread -lprotobuf -llog4cxx /usr/lib/x86_64-linux-gnu/libsqlite3.so -lcrypto ./.libs/libndn-cpp.so: undefined reference to `google::protobuf::GoogleOnceInitImpl(long*, google::protobuf::Closure*)' collect2: ld returned 1 exit status make[1]: *** [bin/test-echo-consumer] Error 1 make[1]: Leaving directory `/home/haroon/ndn-cpp-master' make: *** [all-recursive] Error 1 -- Haroon Rashid -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ndncpp_error.png Type: image/png Size: 150420 bytes Desc: not available URL: From jefft0 at remap.ucla.edu Thu Oct 2 06:42:15 2014 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Thu, 2 Oct 2014 13:42:15 +0000 Subject: [Nfd-dev] Error while installing NDN-CPP In-Reply-To: References: Message-ID: Hello. I will look at your error report. Do you have an account on our Redmine site? If not, please make an account and let me know. I would like to move this to a Redmine issue for ndn-cpp: http://redmine.named-data.net/projects/ndn-cpp/issues Thank you, - Jeff T From: Haroon Rashid > Date: Thursday, October 2, 2014 12:22 AM To: nfd-dev > Subject: [Nfd-dev] Error while installing NDN-CPP Hello All, I am getting an error while installing NDN_CPP. I have included also the screen shot of error message. I am working on Ubuntu 12.04 LTS. Can someone help me to come out of this issue. haroon at hp-envy:~/ndn-cpp-master$ make Making all in include make[1]: Entering directory `/home/haroon/ndn-cpp-master/include' make all-am make[2]: Entering directory `/home/haroon/ndn-cpp-master/include' make[2]: Leaving directory `/home/haroon/ndn-cpp-master/include' make[1]: Leaving directory `/home/haroon/ndn-cpp-master/include' make[1]: Entering directory `/home/haroon/ndn-cpp-master' /bin/bash ./libtool --tag=CXX --mode=link g++ -g -O2 -std=gnu++0x -o bin/test-echo-consumer tests/test-echo-consumer.o libndn-cpp.la -lpthread -lprotobuf -llog4cxx -lsqlite3 -lcrypto libtool: link: g++ -g -O2 -std=gnu++0x -o bin/.libs/test-echo-consumer tests/test-echo-consumer.o ./.libs/libndn-cpp.so -lpthread -lprotobuf -llog4cxx /usr/lib/x86_64-linux-gnu/libsqlite3.so -lcrypto ./.libs/libndn-cpp.so: undefined reference to `google::protobuf::GoogleOnceInitImpl(long*, google::protobuf::Closure*)' collect2: ld returned 1 exit status make[1]: *** [bin/test-echo-consumer] Error 1 make[1]: Leaving directory `/home/haroon/ndn-cpp-master' make: *** [all-recursive] Error 1 -- Haroon Rashid -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefft0 at remap.ucla.edu Thu Oct 2 11:30:20 2014 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Thu, 2 Oct 2014 18:30:20 +0000 Subject: [Nfd-dev] Error while installing NDN-CPP In-Reply-To: References: Message-ID: I created an issue on Redmine. Please continue the discussion there: http://redmine.named-data.net/issues/2019 Thanks, - Jeff T From: Haroon Rashid > Date: Thursday, October 2, 2014 12:22 AM To: nfd-dev > Subject: [Nfd-dev] Error while installing NDN-CPP Hello All, I am getting an error while installing NDN_CPP. I have included also the screen shot of error message. I am working on Ubuntu 12.04 LTS. Can someone help me to come out of this issue. haroon at hp-envy:~/ndn-cpp-master$ make Making all in include make[1]: Entering directory `/home/haroon/ndn-cpp-master/include' make all-am make[2]: Entering directory `/home/haroon/ndn-cpp-master/include' make[2]: Leaving directory `/home/haroon/ndn-cpp-master/include' make[1]: Leaving directory `/home/haroon/ndn-cpp-master/include' make[1]: Entering directory `/home/haroon/ndn-cpp-master' /bin/bash ./libtool --tag=CXX --mode=link g++ -g -O2 -std=gnu++0x -o bin/test-echo-consumer tests/test-echo-consumer.o libndn-cpp.la -lpthread -lprotobuf -llog4cxx -lsqlite3 -lcrypto libtool: link: g++ -g -O2 -std=gnu++0x -o bin/.libs/test-echo-consumer tests/test-echo-consumer.o ./.libs/libndn-cpp.so -lpthread -lprotobuf -llog4cxx /usr/lib/x86_64-linux-gnu/libsqlite3.so -lcrypto ./.libs/libndn-cpp.so: undefined reference to `google::protobuf::GoogleOnceInitImpl(long*, google::protobuf::Closure*)' collect2: ld returned 1 exit status make[1]: *** [bin/test-echo-consumer] Error 1 make[1]: Leaving directory `/home/haroon/ndn-cpp-master' make: *** [all-recursive] Error 1 -- Haroon Rashid -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun Oct 5 18:20:00 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 5 Oct 2014 18:20:00 -0700 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx Message-ID: Dear folks Sometimes, code needs to be imported from NFD to ndn-cxx, for functional and technical reasons. Strictly speaking, NFD code cannot be imported to ndn-cxx directly. NFD is GPL3; ndn-cxx is LGPL3. LGPL3 code cannot contain GPL3 code. The guideline given in ndn-cxx README-dev.md is to include a LGPL3 license boilerplate for all contributions. Davide is disagreeing with this practice in a code review. Please comment on how license boilerplate should be written for those codes. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.pesavento at lip6.fr Sun Oct 5 18:54:01 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Sun, 5 Oct 2014 18:54:01 -0700 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: References: Message-ID: On Sun, Oct 5, 2014 at 6:20 PM, Junxiao Shi wrote: > Dear folks > > Sometimes, code needs to be imported from NFD to ndn-cxx, for functional and > technical reasons. > > Strictly speaking, NFD code cannot be imported to ndn-cxx directly. > NFD is GPL3; ndn-cxx is LGPL3. > LGPL3 code cannot contain GPL3 code. > > The guideline given in ndn-cxx README-dev.md is to include a LGPL3 license > boilerplate for all contributions. I'm assuming that guideline refers only to new code (it's the only way in which it can make sense). In this case you're not the sole author of the code that you committed, therefore the guideline does not apply. > Davide is disagreeing with this practice in a code review. I don't disagree with it in general. I disagree with what you did in change #1288. IANAL, but applying this "practice" in this case is wrong and constitutes a gross violation of copyright law, for two reasons. 1. You are relicensing code from GPL to LGPL. This requires explicit approval from every copyright holder (i.e. author) of the code that is being relicensed. 2. You dropped all copyright holders except "The Regents of University of California". I believe this is a violation of the GPLv3. Best, Davide From alexander.afanasyev at ucla.edu Sun Oct 5 19:02:36 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Sun, 5 Oct 2014 19:02:36 -0700 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: References: Message-ID: On Oct 5, 2014, at 6:54 PM, Davide Pesavento wrote: > On Sun, Oct 5, 2014 at 6:20 PM, Junxiao Shi > wrote: >> Dear folks >> >> Sometimes, code needs to be imported from NFD to ndn-cxx, for functional and >> technical reasons. >> >> Strictly speaking, NFD code cannot be imported to ndn-cxx directly. >> NFD is GPL3; ndn-cxx is LGPL3. >> LGPL3 code cannot contain GPL3 code. >> >> The guideline given in ndn-cxx README-dev.md is to include a LGPL3 license >> boilerplate for all contributions. > > I'm assuming that guideline refers only to new code (it's the only way > in which it can make sense). In this case you're not the sole author > of the code that you committed, therefore the guideline does not > apply. Guidelines are not the law, they are just guidelines that we recommend to use for our code. Nothing more. One can disagree with guidelines and add something else, which is compatible with the library's or NFD's license in general. In this specific case, as Davide pointed out, we are required by the law to preserve the original copyright. Technically speaking, we will need agreement with each copyright holder to change the license, but I hope this is not an issue at the moment. Again, for this specific case. We should preserve the original copyright that was in NFD and explicitly list contributing authors (as there is no other place where they are listed). I think we still can use the the generic ndn-cxx boilerplate, the original stuff can be put as a separate comment block in files. --- Alex >> Davide is disagreeing with this practice in a code review. > > I don't disagree with it in general. I disagree with what you did in > change #1288. > > IANAL, but applying this "practice" in this case is wrong and > constitutes a gross violation of copyright law, for two reasons. > > 1. You are relicensing code from GPL to LGPL. This requires explicit > approval from every copyright holder (i.e. author) of the code that is > being relicensed. > > 2. You dropped all copyright holders except "The Regents of University > of California". I believe this is a violation of the GPLv3. > > Best, > Davide > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From shijunxiao at email.arizona.edu Sun Oct 5 19:05:04 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 5 Oct 2014 19:05:04 -0700 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: References: Message-ID: Hi Alex Please include those rules in README-dev.md or on a wiki page. Yours, Junxiao On Sun, Oct 5, 2014 at 7:02 PM, Alex Afanasyev wrote: > > On Oct 5, 2014, at 6:54 PM, Davide Pesavento > wrote: > > > On Sun, Oct 5, 2014 at 6:20 PM, Junxiao Shi > > wrote: > >> Dear folks > >> > >> Sometimes, code needs to be imported from NFD to ndn-cxx, for > functional and > >> technical reasons. > >> > >> Strictly speaking, NFD code cannot be imported to ndn-cxx directly. > >> NFD is GPL3; ndn-cxx is LGPL3. > >> LGPL3 code cannot contain GPL3 code. > >> > >> The guideline given in ndn-cxx README-dev.md is to include a LGPL3 > license > >> boilerplate for all contributions. > > > > I'm assuming that guideline refers only to new code (it's the only way > > in which it can make sense). In this case you're not the sole author > > of the code that you committed, therefore the guideline does not > > apply. > > Guidelines are not the law, they are just guidelines that we recommend to > use for our code. Nothing more. > One can disagree with guidelines and add something else, which is > compatible with the library's or NFD's license in general. > > In this specific case, as Davide pointed out, we are required by the law > to preserve the original copyright. Technically speaking, we will need > agreement with each copyright holder to change the license, but I hope this > is not an issue at the moment. > > Again, for this specific case. We should preserve the original copyright > that was in NFD and explicitly list contributing authors (as there is no > other place where they are listed). I think we still can use the the > generic ndn-cxx boilerplate, the original stuff can be put as a separate > comment block in files. > > --- > Alex > > >> Davide is disagreeing with this practice in a code review. > > > > I don't disagree with it in general. I disagree with what you did in > > change #1288. > > > > IANAL, but applying this "practice" in this case is wrong and > > constitutes a gross violation of copyright law, for two reasons. > > > > 1. You are relicensing code from GPL to LGPL. This requires explicit > > approval from every copyright holder (i.e. author) of the code that is > > being relicensed. > > > > 2. You dropped all copyright holders except "The Regents of University > > of California". I believe this is a violation of the GPLv3. > > > > Best, > > Davide > > _______________________________________________ > > Nfd-dev mailing list > > Nfd-dev at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Mon Oct 6 11:04:30 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Mon, 6 Oct 2014 11:04:30 -0700 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: References: Message-ID: <99C28F48-01A2-4ED7-88F4-AC7E3572220C@ucla.edu> I don't think there is anything else that we need to put in either README-dev of wiki. README-dev already includes correct information, merely suggesting to use the boilerplate for LGPL license. --- Alex On Oct 5, 2014, at 7:05 PM, Junxiao Shi wrote: > Hi Alex > > Please include those rules in README-dev.md or on a wiki page. > > Yours, Junxiao > > On Sun, Oct 5, 2014 at 7:02 PM, Alex Afanasyev wrote: > > On Oct 5, 2014, at 6:54 PM, Davide Pesavento wrote: > > > On Sun, Oct 5, 2014 at 6:20 PM, Junxiao Shi > > wrote: > >> Dear folks > >> > >> Sometimes, code needs to be imported from NFD to ndn-cxx, for functional and > >> technical reasons. > >> > >> Strictly speaking, NFD code cannot be imported to ndn-cxx directly. > >> NFD is GPL3; ndn-cxx is LGPL3. > >> LGPL3 code cannot contain GPL3 code. > >> > >> The guideline given in ndn-cxx README-dev.md is to include a LGPL3 license > >> boilerplate for all contributions. > > > > I'm assuming that guideline refers only to new code (it's the only way > > in which it can make sense). In this case you're not the sole author > > of the code that you committed, therefore the guideline does not > > apply. > > Guidelines are not the law, they are just guidelines that we recommend to use for our code. Nothing more. > One can disagree with guidelines and add something else, which is compatible with the library's or NFD's license in general. > > In this specific case, as Davide pointed out, we are required by the law to preserve the original copyright. Technically speaking, we will need agreement with each copyright holder to change the license, but I hope this is not an issue at the moment. > > Again, for this specific case. We should preserve the original copyright that was in NFD and explicitly list contributing authors (as there is no other place where they are listed). I think we still can use the the generic ndn-cxx boilerplate, the original stuff can be put as a separate comment block in files. > > --- > Alex > > >> Davide is disagreeing with this practice in a code review. > > > > I don't disagree with it in general. I disagree with what you did in > > change #1288. > > > > IANAL, but applying this "practice" in this case is wrong and > > constitutes a gross violation of copyright law, for two reasons. > > > > 1. You are relicensing code from GPL to LGPL. This requires explicit > > approval from every copyright holder (i.e. author) of the code that is > > being relicensed. > > > > 2. You dropped all copyright holders except "The Regents of University > > of California". I believe this is a violation of the GPLv3. > > > > Best, > > Davide > > _______________________________________________ > > Nfd-dev mailing list > > Nfd-dev at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Oct 6 11:38:26 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 6 Oct 2014 11:38:26 -0700 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: <99C28F48-01A2-4ED7-88F4-AC7E3572220C@ucla.edu> References: <99C28F48-01A2-4ED7-88F4-AC7E3572220C@ucla.edu> Message-ID: Hi Alex There should be a guideline on how to properly import code from related projects such as NFD, NLSR, repo-ng. Yours, Junxiao On Mon, Oct 6, 2014 at 11:04 AM, Alex Afanasyev < alexander.afanasyev at ucla.edu> wrote: > I don't think there is anything else that we need to put in either > README-dev of wiki. > README-dev already includes correct information, merely suggesting to use > the boilerplate for LGPL license. > > --- > Alex > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.EDU Tue Oct 7 07:10:08 2014 From: lanwang at memphis.EDU (Lan Wang (lanwang)) Date: Tue, 7 Oct 2014 14:10:08 +0000 Subject: [Nfd-dev] [Ndn-interest] NDN link protocol In-Reply-To: References: Message-ID: <9DB27F4A-229F-45B4-A279-2381C755DBCD@memphis.edu> Junxiao, What do we need to change in NLSR to support ethernet tunnel? Lan On Oct 7, 2014, at 3:36 AM, Junxiao Shi > wrote: Hi Emerson NDNLP is a link protocol for NDN. Its implementation is incomplete in NFD. NLSR doesn't currently support Ethernet faces due to its use of `faces/create` API. Only UDP unicast and TCP faces are supported. Yours, Junxiao _______________________________________________ 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 oran at cisco.com Tue Oct 7 08:24:04 2014 From: oran at cisco.com (Dave Oran (oran)) Date: Tue, 7 Oct 2014 15:24:04 +0000 Subject: [Nfd-dev] [Ndn-interest] NDN link protocol In-Reply-To: <9DB27F4A-229F-45B4-A279-2381C755DBCD@memphis.edu> References: <9DB27F4A-229F-45B4-A279-2381C755DBCD@memphis.edu> Message-ID: On Oct 7, 2014, at 10:10 AM, Lan Wang (lanwang) wrote: > Junxiao, > > What do we need to change in NLSR to support ethernet tunnel? > I?m not sure, but PLEASE don?t re-invent ARP. > Lan > On Oct 7, 2014, at 3:36 AM, Junxiao Shi wrote: > >> Hi Emerson >> >> NDNLP is a link protocol for NDN. Its implementation is incomplete in NFD. >> >> NLSR doesn't currently support Ethernet faces due to its use of `faces/create` API. Only UDP unicast and TCP faces are supported. >> >> Yours, Junxiao >> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From davide.pesavento at lip6.fr Tue Oct 7 09:44:43 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Tue, 7 Oct 2014 18:44:43 +0200 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: References: Message-ID: On Mon, Oct 6, 2014 at 4:02 AM, Alex Afanasyev wrote: > > In this specific case, as Davide pointed out, we are required by the law to preserve the original copyright. Technically speaking, we will need agreement with each copyright holder to change the license, but I hope this is not an issue at the moment. > Hope doesn't help in lawsuits. It's better to do this right. And it's also very simple in this case since I am the sole author of the Ethernet code, while FaceUri was written by Junxiao, Wentao, and you (according to git). It takes less than 5 minutes to ask 3 people if they're ok with the relicensing. From davide.pesavento at lip6.fr Tue Oct 7 09:54:24 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Tue, 7 Oct 2014 18:54:24 +0200 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: References: <99C28F48-01A2-4ED7-88F4-AC7E3572220C@ucla.edu> Message-ID: Junxiao, You seem to be missing my point. I'm talking about respecting the original project's license. Seems like an obvious thing to me, do we need a guideline for that too? Then what, the next guideline will be "don't kill the reviewer if he rejects your patch"? Davide On Mon, Oct 6, 2014 at 8:38 PM, Junxiao Shi wrote: > Hi Alex > > There should be a guideline on how to properly import code from related > projects such as NFD, NLSR, repo-ng. > > Yours, Junxiao > > On Mon, Oct 6, 2014 at 11:04 AM, Alex Afanasyev > wrote: >> >> I don't think there is anything else that we need to put in either >> README-dev of wiki. >> README-dev already includes correct information, merely suggesting to use >> the boilerplate for LGPL license. >> >> --- >> Alex >> > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From alexander.afanasyev at UCLA.EDU Tue Oct 7 10:34:32 2014 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Tue, 7 Oct 2014 10:34:32 -0700 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: References: Message-ID: <37FBD4CA-192D-4F93-957E-8B83F76042C8@ucla.edu> On Oct 7, 2014, at 9:44 AM, Davide Pesavento wrote: > On Mon, Oct 6, 2014 at 4:02 AM, Alex Afanasyev > wrote: >> >> In this specific case, as Davide pointed out, we are required by the law to preserve the original copyright. Technically speaking, we will need agreement with each copyright holder to change the license, but I hope this is not an issue at the moment. >> > > Hope doesn't help in lawsuits. It's better to do this right. And it's > also very simple in this case since I am the sole author of the > Ethernet code, while FaceUri was written by Junxiao, Wentao, and you > (according to git). It takes less than 5 minutes to ask 3 people if > they're ok with the relicensing. Unfortunately, this is not that simple. Only copyright "owners" can re-license, which in our case are not the authors of the specific code, but institutions in NDN project. The objective for NDN project is to have code open. The agreement that we had before starting the project is that code can be relicensed later, if needed. This, technically, is the time for invoking such an agreement. --- Alex From jefft0 at remap.ucla.edu Tue Oct 7 13:19:28 2014 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Tue, 7 Oct 2014 20:19:28 +0000 Subject: [Nfd-dev] NFD with a broadcast prefix Message-ID: Hello. I'm working with the ndn-cpp implementation of ChronoSync as described in the 2013 paper ?Let?s ChronoSync: Decentralized Dataset State Synchronization in Named Data Networking? and used in the related ChronoChat. User A and user B are running ChronoChat on separate computers. They register to receive interests for the same broadcast prefix "/ndn/broadcast/ChronoChat-0.3/ndnchat". When the users get a new root hash, they both express the same interest, e.g. "/ndn/broadcast/ChronoChat-0.3/ndnchat/4aa4". User B should receive the interest from user A and vice versa. When I run this on ndnd-tlv, the broadcast insterest is always forwarded to the other user. But on NFD, sometimes the interest is not forwarded. When I turn on NFD logging TRACE, I see user A sends the interest and it is forwarded to user B. But user B sends the interest and it is not forwarded to user A. Can you think of why NFD might have this behavior? (Under the default routing strategy it may be a feature, not a bug.) Or what I should do to get the full broadcast behavior? Thanks, - Jeff T -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Oct 7 13:21:35 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 7 Oct 2014 13:21:35 -0700 Subject: [Nfd-dev] NFD with a broadcast prefix In-Reply-To: References: Message-ID: Hi JeffT Which strategy are you using for this namespace? Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefft0 at remap.ucla.edu Tue Oct 7 13:31:47 2014 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Tue, 7 Oct 2014 20:31:47 +0000 Subject: [Nfd-dev] NFD with a broadcast prefix In-Reply-To: References: Message-ID: I'm using the default installed in nfd.conf.sample. Here is the log trace starting with onIncomingInterest. (I don't see a following onOutgoingInterest.) 1412709671.193284 DEBUG: [Forwarder] onIncomingInterest face=260 interest=/ndn/broadcast/ChronoChat-0.3/ndnchat/4aa4 1412709671.193407 TRACE: [NameTree] lookup /ndn/broadcast/ChronoChat-0.3/ndnchat/4aa4 1412709671.193512 TRACE: [NameTree] insert / 1412709671.193543 TRACE: [NameTree] Name / hash value = 0 location = 0 1412709671.193593 TRACE: [NameTree] insert /ndn 1412709671.193627 TRACE: [NameTree] Name /ndn hash value = 6181921638449679482 location = 122 1412709671.193693 TRACE: [NameTree] insert /ndn/broadcast 1412709671.193734 TRACE: [NameTree] Name /ndn/broadcast hash value = 10179271752148773262 location = 398 1412709671.193809 TRACE: [NameTree] insert /ndn/broadcast/ChronoChat-0.3 1412709671.193861 TRACE: [NameTree] Name /ndn/broadcast/ChronoChat-0.3 hash value = 10460827042937309181 location = 1021 1412709671.193946 TRACE: [NameTree] insert /ndn/broadcast/ChronoChat-0.3/ndnchat 1412709671.194003 TRACE: [NameTree] Name /ndn/broadcast/ChronoChat-0.3/ndnchat hash value = 385463525867948453 location = 421 1412709671.194094 TRACE: [NameTree] insert /ndn/broadcast/ChronoChat-0.3/ndnchat/4aa4 1412709671.194207 TRACE: [NameTree] Name /ndn/broadcast/ChronoChat-0.3/ndnchat/4aa4 hash value = 4194857947738937507 location = 163 1412709671.194346 DEBUG: [BestRouteStrategy2] /ndn/broadcast/ChronoChat-0.3/ndnchat/4aa4?ndn.MustBeFresh=1&ndn.InterestLifetime=500000&ndn.N\ once=982437693 from=260 dontRetransmit sinceLastOutgoing=6950000 From: Junxiao Shi > Date: Tuesday, October 7, 2014 at 1:21 PM To: Jeff Thompson > Cc: nfd-dev > Subject: Re: [Nfd-dev] NFD with a broadcast prefix Hi JeffT Which strategy are you using for this namespace? Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Oct 7 13:34:56 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 7 Oct 2014 13:34:56 -0700 Subject: [Nfd-dev] NFD with a broadcast prefix In-Reply-To: References: Message-ID: Hi JeffT This behavior is by design for best-route v2. Please execute the following: nfdc set-strategy /ndn/broadcast /localhost/nfd/strategy/broadcast to set broadcast strategy for your namespace. It's intentional not to set this in default startup script, because forwarder shouldn't understand names, and /ndn/broadcast is a policy decision, not part of architecture. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefft0 at remap.ucla.edu Tue Oct 7 13:43:45 2014 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Tue, 7 Oct 2014 20:43:45 +0000 Subject: [Nfd-dev] NFD with a broadcast prefix In-Reply-To: References: Message-ID: Great! That did the trick. Thanks for the help and the explanation. - Jeff T From: Junxiao Shi > Date: Tuesday, October 7, 2014 at 1:34 PM To: Jeff Thompson > Cc: nfd-dev > Subject: Re: [Nfd-dev] NFD with a broadcast prefix Hi JeffT This behavior is by design for best-route v2. Please execute the following: nfdc set-strategy /ndn/broadcast /localhost/nfd/strategy/broadcast to set broadcast strategy for your namespace. It's intentional not to set this in default startup script, because forwarder shouldn't understand names, and /ndn/broadcast is a policy decision, not part of architecture. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Tue Oct 7 15:34:13 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Tue, 7 Oct 2014 15:34:13 -0700 Subject: [Nfd-dev] Moving and re-licensing parts of NFD code to ndn-cxx (was Re: License boilerplate for code imported from NFD to ndn-cxx) In-Reply-To: <37FBD4CA-192D-4F93-957E-8B83F76042C8@ucla.edu> References: <37FBD4CA-192D-4F93-957E-8B83F76042C8@ucla.edu> Message-ID: In any case. Let me try to close this particular issue and this is how we should have handled it in the first place. * * * We are moving several pieces of code from NFD codebase (GPL licensed) to ndn-cxx codebase (LGPL licensed). These include: - [NFD] core/ethernet.cpp -> [ndn-cxx] src/util/ethernet.cpp - [NFD] core/ethernet.hpp -> [ndn-cxx] src/util/ethernet.hpp - [NFD] core/face-uri.cpp -> [ndn-cxx] src/util/face-uri.cpp - [NFD] core/face-uri.hpp -> [ndn-cxx] src/util/face-uri.hpp - [NFD] tests/core/ethernet.cpp -> [ndn-cxx] tests/unit-tests/util/ethernet.cpp - [NFD] tests/core/face-uri.cpp -> [ndn-cxx] tests/unit-tests/util/face-uri.cpp As part of the move, it is necessary to re-license these files to be LGPL license, instead of original GPL, as the licenses are not compatible. We will retain the original copyright no these files, which is collectively owned by Regents of the University of California, Arizona Board of Regents, Colorado State University, University Pierre & Marie Curie, Sorbonne University, Washington University in St. Louis, Beijing Institute of Technology, and The University of Memphis. This re-licensing is performed according to our previous agreement to keep the codebase open. Please let us know if there are specific concerns this re-licensing. * * * --- Alex On Oct 7, 2014, at 10:34 AM, Alex Afanasyev wrote: > > On Oct 7, 2014, at 9:44 AM, Davide Pesavento wrote: > >> On Mon, Oct 6, 2014 at 4:02 AM, Alex Afanasyev >> wrote: >>> >>> In this specific case, as Davide pointed out, we are required by the law to preserve the original copyright. Technically speaking, we will need agreement with each copyright holder to change the license, but I hope this is not an issue at the moment. >>> >> >> Hope doesn't help in lawsuits. It's better to do this right. And it's >> also very simple in this case since I am the sole author of the >> Ethernet code, while FaceUri was written by Junxiao, Wentao, and you >> (according to git). It takes less than 5 minutes to ask 3 people if >> they're ok with the relicensing. > > Unfortunately, this is not that simple. Only copyright "owners" can re-license, which in our case are not the authors of the specific code, but institutions in NDN project. > > The objective for NDN project is to have code open. The agreement that we had before starting the project is that code can be relicensed later, if needed. This, technically, is the time for invoking such an agreement. > > --- > Alex From shijunxiao at email.arizona.edu Tue Oct 7 15:36:45 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 7 Oct 2014 15:36:45 -0700 Subject: [Nfd-dev] Moving and re-licensing parts of NFD code to ndn-cxx Message-ID: Hi Alex On ndn-cxx wiki or README-dev.md, please provide a template license boilerplate for all code file imported from NFD, NLSR, and repo-ng. Yours, Junxiao On Tue, Oct 7, 2014 at 3:34 PM, Alex Afanasyev wrote: > In any case. Let me try to close this particular issue and this is how we > should have handled it in the first place. > > * * * > > We are moving several pieces of code from NFD codebase (GPL licensed) to > ndn-cxx codebase (LGPL licensed). > These include: > > - [NFD] core/ethernet.cpp -> [ndn-cxx] src/util/ethernet.cpp > - [NFD] core/ethernet.hpp -> [ndn-cxx] src/util/ethernet.hpp > - [NFD] core/face-uri.cpp -> [ndn-cxx] src/util/face-uri.cpp > - [NFD] core/face-uri.hpp -> [ndn-cxx] src/util/face-uri.hpp > - [NFD] tests/core/ethernet.cpp -> [ndn-cxx] > tests/unit-tests/util/ethernet.cpp > - [NFD] tests/core/face-uri.cpp -> [ndn-cxx] > tests/unit-tests/util/face-uri.cpp > > As part of the move, it is necessary to re-license these files to be LGPL > license, instead of original GPL, as the licenses are not compatible. > > We will retain the original copyright no these files, which is > collectively owned by Regents of the University of California, Arizona > Board of Regents, Colorado State University, University Pierre & Marie > Curie, Sorbonne University, Washington University in St. Louis, Beijing > Institute of Technology, and The University of Memphis. > > This re-licensing is performed according to our previous agreement to keep > the codebase open. Please let us know if there are specific concerns this > re-licensing. > > * * * > > --- > Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Oct 7 17:16:26 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 7 Oct 2014 17:16:26 -0700 Subject: [Nfd-dev] [Ndn-interest] NDN link protocol In-Reply-To: <9DB27F4A-229F-45B4-A279-2381C755DBCD@memphis.edu> References: <9DB27F4A-229F-45B4-A279-2381C755DBCD@memphis.edu> Message-ID: Hi Lan There's no "Ethernet tunnel". All Ethernet communication by NFD is multicast. Routing protocols have deployment difficulty and runtime overhead. It's generally undesirable to run a routing protocol on Ethernet. Local area network should use self-learning forwarding . Yours, Junxiao On Tue, Oct 7, 2014 at 7:10 AM, Lan Wang (lanwang) wrote: > Junxiao, > > What do we need to change in NLSR to support ethernet tunnel? > > Lan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Oct 7 18:43:13 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 7 Oct 2014 18:43:13 -0700 Subject: [Nfd-dev] Interest scoping and broadcast channels In-Reply-To: References: Message-ID: Hi Jeff There's a proposal about supporting parasitic Interests directly using LocalControlHeader. http://redmine.named-data.net/issues/2007 Please provide your comments on this idea. Yours, Junxiao On Tue, May 27, 2014 at 2:07 AM, Junxiao Shi wrote: > Hi Jeff > > Parasitic Interest is possible in NFD 0.1.0. > > To issue such an Interest: > > 1. set client-control strategy on the namespace > 2. send the Interest, and specify application's own face as next-hop, > so that this Interest won't be propagated > 3. to send a regular Interest to be propagated, specify the wireless > multicast face > > > Yours, Junxiao > > On Mon, May 19, 2014 at 3:55 AM, Burke, Jeff > wrote: > >> If this host needs to know the content from other host, use NFD's >> packet capture feature. The packet capture feature allows a program to >> listen for a subset of packets processed by NFD, with filters on face, >> direction, and name prefix. There is no Task for this feature yet. >> [jb] Ok, we'll keep an eye out for this. While I figured that something >> like this was possible, I had previously come to the conclusion that it was >> better to preserve NDN semantics ? if it is Data that an application is >> interested in, wouldn't it be most NDN-like if it issued an Interest for >> it? This sort of "parasitic Interest", which "listens" on a Face for >> data but doesn't propagate, seems useful in a variety of contexts having to >> do with low-bandwidth broadcast channels or power-constrained consumers. >> The advantage is that the callback mechanism is exactly the same as what >> app developers would be used to, without having to descend into a different >> (packet capture) API. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Tue Oct 7 18:49:43 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 8 Oct 2014 01:49:43 +0000 Subject: [Nfd-dev] [Ndn-interest] NDN link protocol In-Reply-To: References: <9DB27F4A-229F-45B4-A279-2381C755DBCD@memphis.edu>, Message-ID: Self learning can work to a certain degree. But if you have a large network, it may be better to run a routing protocol. We have NLSR hello protocol defined for multicast media. Just need to implement it. I was just asking how to specify the Ethernet face in the configuration file. I suppose just the multicast address. Lan -------- Original message -------- From: Junxiao Shi Date: 10/07/2014 7:16 PM (GMT-06:00) To: "Lan Wang (lanwang)" Cc: "" Subject: Re: [Ndn-interest] NDN link protocol Hi Lan There's no "Ethernet tunnel". All Ethernet communication by NFD is multicast. Routing protocols have deployment difficulty and runtime overhead. It's generally undesirable to run a routing protocol on Ethernet. Local area network should use self-learning forwarding. Yours, Junxiao On Tue, Oct 7, 2014 at 7:10 AM, Lan Wang (lanwang) > wrote: Junxiao, What do we need to change in NLSR to support ethernet tunnel? Lan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gpau at CS.UCLA.EDU Wed Oct 8 06:51:10 2014 From: gpau at CS.UCLA.EDU (Giovanni Pau) Date: Wed, 8 Oct 2014 06:51:10 -0700 Subject: [Nfd-dev] Performance Evaluations Message-ID: Hi All, i was asked if we have a bottom line number for NFD in terms of forwarding performance. Did anybody perform experiments? thanks /g. Giovanni Pau, PhD ========================== "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." --Albert Einstein ========================== ========================== It had long since come to my attention that people of accomplishment rarely sat back and let things happen to them. They went out and happened to things. - Leonardo da Vinci ========================== From davide.pesavento at lip6.fr Wed Oct 8 06:56:12 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Wed, 8 Oct 2014 15:56:12 +0200 Subject: [Nfd-dev] Performance Evaluations In-Reply-To: References: Message-ID: See http://redmine.named-data.net/issues/1819 On Wed, Oct 8, 2014 at 3:51 PM, Giovanni Pau wrote: > Hi All, > > i was asked if we have a bottom line number for NFD in terms of forwarding performance. Did anybody perform experiments? > > thanks > /g. > > > Giovanni Pau, PhD > ========================== > "Any intelligent fool can make things bigger and more complex... It takes a > touch of genius - and a lot of courage to move in the opposite direction." > --Albert Einstein > ========================== > > > ========================== > It had long since come to my attention that people of accomplishment rarely sat back and let things happen to them. They went out and happened to things. > > - Leonardo da Vinci > ========================== > > > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From lanwang at memphis.EDU Wed Oct 8 08:01:09 2014 From: lanwang at memphis.EDU (Lan Wang (lanwang)) Date: Wed, 8 Oct 2014 15:01:09 +0000 Subject: [Nfd-dev] Strategy for testbed routers In-Reply-To: References: <56171789-E87B-4157-BCB0-6D04CCDB74F7@memphis.edu> Message-ID: Junxiao, It seems that the main difference is whether the previously failed path is probed frequently or not. I think it's ok to define the different strategies based on the assumption of whether the failed path is expected to come back shortly or not. On the other hand, it is also possible to use one strategy and let it learn how frequently it should probe the failed paths based on past history. In any case, I don't have an objection to split the strategies into two for now. Lan On Oct 1, 2014, at 9:50 PM, Junxiao Shi > wrote: Hi Lan 2. The problem is not "primary path is not working", but "primary path is working most of the time, but happens to lose one packet". Retrying on the same path helps. 3. Forwarding strategy need not make an assumption on what routing protocol is used, but it should know the quality of paths. High quality routes (such as those from link state routing) can reach the destination UNLESS there's a fault. Retrying is less aggressive, and a temporarily failed path is expected to come back shortly so probing is frequent. Low quality routes (such as those from autoreg-server) are more likely to be incorrect. Retrying is aggressive, and a path that does not work is assumed to be an incorrect path so probing is infrequent. 4. Backbone router strategy assumes all paths can reach the destination UNLESS there's a fault. If there's a fault, Interests go to backup path, but probing is frequent so that traffic can switch back to primary path once it comes back. Access router strategy. When a working path is found, probing on other paths is infrequent. When producer is believed to be moved, the strategy won't expect the old path to work again until the new path fails (which means producer is moving again). Yours, Junxiao On Wed, Oct 1, 2014 at 7:56 AM, Lan Wang (lanwang) > wrote: On Sep 30, 2014, at 6:43 PM, Junxiao Shi > wrote: Hi Lan 1. Yes, the root cause is that laptops are unable to register a precise prefix on the access router. The most effective solution is to enable remote prefix registration on the access router. 2. NCC strategy forwards an Interest to a nexthop, and that nexthop is never used again before InterestLifetime expires. When there is a packet loss, even if the consumer is able to detect that and retransmit the Interest, the retransmission is suppressed by NCC strategy because it won't forward the Interest again to the same nexthop. When a Data does not reach consumer before it's needed, the video frame cannot be constructed and cannot play out. If the Interest was forwarded along some alternative paths by NCC, then it should still reach the producer and bring back the data, right? And if the primary path is not working, sending the Interest there again probably won't help much either. I just want to have a clear understanding of this problem for NDN-RTC on the testbed and then it's more clear how a more effective strategy should work. 3. Link state routing can ensure all nexthops in FIB entry can reach the destination. Backbone strategy is designed for this scenario. Strategy choice depends on network environment and application needs. Hyperbolic routing might need a different strategy. I'm not sure if the forwarding strategy should make an assumption of what routing protocol is used. After all, the routing protocol may be relying on the forwarding strategy to fix some of the temporary problems so that it doesn't have to respond as quickly as in an IP network (Cheng's paper). 4. The distinction between remote prefixes and local site prefix is: remote prefixes have mostly reachable nexthops and less changes (when link state routing is used), local site prefix suffers more from unreachable nexthops and laptop mobility. I don't know whether there is a major difference in the structure of those two forwarding strategies, but they will at least differ in some parameter settings. It seems to me that as long as the forwarding strategy satisfies the requirement of "Make use of multiple paths in FIB entry, and learn the best path.", then it can handle various failure situations (whether they are caused by laptop mobility or link failures). It would be better if you can make it clear what extra is required for local site prefix. Lan -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Oct 8 09:28:34 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 8 Oct 2014 09:28:34 -0700 Subject: [Nfd-dev] Fwd: NFD mgmt: eliminate double-dispatch In-Reply-To: References: Message-ID: This proposal describes the original design intention of the Interest dispatch mechanism of NFD management. This message was originally sent on Jun 02. This version is a correction. Current implemented approach: NFD management module consists of: - several Managers, such as FaceManager, FibManager, StrategyChoiceManager - an InternalFace - a configuration parser To process an Interest: - InternalFace receives ndn:/localhost/nfd Interests from forwarding, looks at the third component (management module), and dispatch it to a Manager. - Upon Interest arrival, Manager looks at the fourth component, and do one of the following: - for command verb: validate Command Interest, and then dispatch the Interest to the function that handles this command - for dataset: dispatch the Interest to the function that generates data for this dataset - for notification stream: drop the Interest - Replies are directly written to InternalFace Drawback of this design: - Each Interest is dispatched twice: once in InternalFace, again in Manager. - Authentication is scattered across Managers. - Reply encryption is non-existent. Design intention: partial interface InternalFace { // reply(const Data& data, bool isFinal); // data: unsigned and unencrypted Data // isFinal: true if this is that last Data to send typedef function ReplyFunc; // process(const Interest& interest, const Name& identity, ReplyFunc reply); // identity: verified identity of requester, if available; otherwise empty // reply: a function to send replies typedef function InterestHandler; // accept(const Name& identity) // identity: verified identity of requester, if available; otherwise empty typedef function AcceptContinuation; // reject(bool reply401) // send401: whether to reply 401 or silently drop typedef function RejectContinuation; // authorize(const Name& prefix, const Interest& interest, AcceptContinuation accept, RejectContinuation reject); // accept: function to call if authentication succeeds // reject: function to call if authentication fails typedef function Authorization; // encryptReply(const Name& identity, shared_ptr data); typedef function)> ReplyEncryption void register(const Name& prefix, Authorization, ReplyEncryption, InterestHandler handler); } - During initialization, Manager should register its commands, datasets, and notification streams into InternalFace - examples: face->register("ndn:/localhost/nfd/faces/create", CommandInterestAuthorization("faces"), NullReplyEncryption(), bind(&FaceManager::onCreateCommand, this, _1, _2, _3)); face->register("ndn:/localhost/nfd/faces/list", DatasetAuthorization(), NullReplyEncryption(), bind(&FaceManager::generateFaceList, this, _3)); face->register("ndn:/localhost/nfd/faces/events", DropAllAuthorization(), nullptr, nullptr); - InternalFace receives ndn:/localhost/nfd Interests from forwarding, perform a longest prefix match on registered prefixes - if no registration is found, record to log, and drop the Interest - Perform authorization as requested - CommandInterestAuthorization(const std::string& privilege) accepts valid Command Interests with this privilege, and rejects with 401 otherwise - DatasetAuthorization accepts Interests with Name equal to the prefix, and drops other Interests (they should be satisfied by ContentStore) - DropAllAuthorization drops all Interests; this is used with notification streams because Interests should wait until notification is delivered - Dispatch to the handler - Handler calls ReplyFunc zero or more times with unsigned and unencrypted Data - ReplyFunc is a bound function that knows the ReplyEncryption; it encrypts Data as requested, and then sign and send it In addition, derive a ndn::Face subclass (which has the same API as a client face in ndn-cxx), so that the same Dataset publisher and Notification Stream publisher can be used both in external app and within NFD management. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Wed Oct 8 09:40:38 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 8 Oct 2014 16:40:38 +0000 Subject: [Nfd-dev] Fwd: Invitation to join NDN Consortium References: Message-ID: Begin forwarded message: From: Lan Wang > Subject: Re: Invitation to join NDN Consortium Date: October 8, 2014 9:27:38 AM CDT To: > Cc: Lixia Zhang >, Beichuan Zhang > Just want to point out that this is not the same bug as you reported earlier and it is in NFD, not NLSR. Lan On Oct 8, 2014, at 9:17 AM, > wrote: Dear Lixia, We found a bug of NLSR when we researched VM Full Live Migration over NDN. We have amended the bug but it is not the optimization method. And we have offered optimization method for your reference. You can get it from attachment. Best regards, Dalu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: The Bug of NDN Content Store Replacement Policy-2014-10-8.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 19462 bytes Desc: The Bug of NDN Content Store Replacement Policy-2014-10-8.docx URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From christos at cs.colostate.edu Wed Oct 8 10:55:17 2014 From: christos at cs.colostate.edu (Christos Papadopoulos) Date: Wed, 08 Oct 2014 11:55:17 -0600 Subject: [Nfd-dev] Performance Evaluations In-Reply-To: References: Message-ID: <54357A85.5010702@cs.colostate.edu> On 10/08/2014 07:51 AM, Giovanni Pau wrote: > Hi All, > > i was asked if we have a bottom line number for NFD in terms of forwarding performance. Did anybody perform experiments? This question comes up quite often. Let me add this in addition to the Redmine issue pointed by Davide. We do have such results that you can see in Redmine. John DeHart has done some experiments and more recently Chengyu Fan at CSU repeated his experiments and did some code profiling. Chengyu can point you to the profiling results. I don't think those were added to Redmine yet, he should add them soon. One caveat we always emphasize: NFD at this stage is not performance optimized. It is optimized to be changed :-) In other words the initial emphasis is on modularity, not systematic performance tuning. I say this because there is a push out there to focus on performance. For the PARC people, for example, this is a crucial area. Lixia makes it a point to strongly emphasize the different focus of the two projects (CCN and NDN) when it comes to performance. I think this is important. Christos. > > thanks > /g. > > > Giovanni Pau, PhD > ========================== > "Any intelligent fool can make things bigger and more complex... It takes a > touch of genius - and a lot of courage to move in the opposite direction." > --Albert Einstein > ========================== > > > ========================== > It had long since come to my attention that people of accomplishment rarely sat back and let things happen to them. They went out and happened to things. > > - Leonardo da Vinci > ========================== > > > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From oran at cisco.com Wed Oct 8 11:34:20 2014 From: oran at cisco.com (Dave Oran (oran)) Date: Wed, 8 Oct 2014 18:34:20 +0000 Subject: [Nfd-dev] [Ndn-interest] NDN link protocol In-Reply-To: References: <9DB27F4A-229F-45B4-A279-2381C755DBCD@memphis.edu>, Message-ID: <76FF5F7B-EA32-44C9-AE12-5EEAA4BD94DB@cisco.com> On Oct 7, 2014, at 9:49 PM, Lan Wang (lanwang) wrote: > Self learning can work to a certain degree. But if you have a large network, it may be better to run a routing protocol. We have NLSR hello protocol defined for multicast media. Just need to implement it. I was just asking how to specify the Ethernet face in the configuration file. I suppose just the multicast address. > It?s also fairly crazy to multicast every packet, so there has to be some binding machinery to allow unicast at L2 > Lan > > > > -------- Original message -------- > From: Junxiao Shi > Date: 10/07/2014 7:16 PM (GMT-06:00) > To: "Lan Wang (lanwang)" > Cc: "" > Subject: Re: [Ndn-interest] NDN link protocol > > > Hi Lan > > There's no "Ethernet tunnel". All Ethernet communication by NFD is multicast. > > Routing protocols have deployment difficulty and runtime overhead. It's generally undesirable to run a routing protocol on Ethernet. > Local area network should use self-learning forwarding. > > Yours, Junxiao > > On Tue, Oct 7, 2014 at 7:10 AM, Lan Wang (lanwang) wrote: > Junxiao, > > What do we need to change in NLSR to support ethernet tunnel? > > Lan > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From chengy.fan at gmail.com Wed Oct 8 11:36:05 2014 From: chengy.fan at gmail.com (Chengyu Fan) Date: Wed, 8 Oct 2014 12:36:05 -0600 Subject: [Nfd-dev] Performance Evaluations In-Reply-To: <54357A85.5010702@cs.colostate.edu> References: <54357A85.5010702@cs.colostate.edu> Message-ID: Hi Giovanni, As Christos pointed out, I repeated John's experiments last month using the NFD v0.2. Thanks to John, his scripts make it pretty convenient to conduct the performance experiments. The end of http://redmine.named-data.net/issues/1819 contains the NFD v0.2 performance information. To make the results clearer, please let me update the results report and experiment manual first. I'll let you know when it is ready. On Wed, Oct 8, 2014 at 11:55 AM, Christos Papadopoulos < christos at cs.colostate.edu> wrote: > On 10/08/2014 07:51 AM, Giovanni Pau wrote: > >> Hi All, >> >> i was asked if we have a bottom line number for NFD in terms of >> forwarding performance. Did anybody perform experiments? >> > > This question comes up quite often. Let me add this in addition to the > Redmine issue pointed by Davide. > > We do have such results that you can see in Redmine. John DeHart has done > some experiments and more recently Chengyu Fan at CSU repeated his > experiments and did some code profiling. > > Chengyu can point you to the profiling results. I don't think those were > added to Redmine yet, he should add them soon. > > One caveat we always emphasize: NFD at this stage is not performance > optimized. It is optimized to be changed :-) In other words the initial > emphasis is on modularity, not systematic performance tuning. > > I say this because there is a push out there to focus on performance. For > the PARC people, for example, this is a crucial area. > > Lixia makes it a point to strongly emphasize the different focus of the > two projects (CCN and NDN) when it comes to performance. I think this is > important. > > Christos. > > > >> thanks >> /g. >> >> >> Giovanni Pau, PhD >> ========================== >> "Any intelligent fool can make things bigger and more complex... It takes >> a >> touch of genius - and a lot of courage to move in the opposite direction." >> --Albert Einstein >> ========================== >> >> >> ========================== >> It had long since come to my attention that people of accomplishment >> rarely sat back and let things happen to them. They went out and happened >> to things. >> >> - Leonardo da Vinci >> ========================== >> >> >> >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -- Thanks, Chengyu -------------- next part -------------- An HTML attachment was scrubbed... URL: From chengy.fan at gmail.com Wed Oct 8 13:07:46 2014 From: chengy.fan at gmail.com (Chengyu Fan) Date: Wed, 8 Oct 2014 14:07:46 -0600 Subject: [Nfd-dev] Performance Evaluations In-Reply-To: References: <54357A85.5010702@cs.colostate.edu> Message-ID: Giovanni, I updated the results report and experiment manual for NFD v0.2. Please check the page http://redmine.named-data.net/issues/1819 for details. If you have any questions, please let me know. On Wed, Oct 8, 2014 at 12:36 PM, Chengyu Fan wrote: > Hi Giovanni, > > As Christos pointed out, I repeated John's experiments last month using > the NFD v0.2. > Thanks to John, his scripts make it pretty convenient to conduct the > performance experiments. > The end of http://redmine.named-data.net/issues/1819 contains the NFD > v0.2 performance information. > > To make the results clearer, please let me update the results report and > experiment manual first. I'll let you know when it is ready. > > On Wed, Oct 8, 2014 at 11:55 AM, Christos Papadopoulos < > christos at cs.colostate.edu> wrote: > >> On 10/08/2014 07:51 AM, Giovanni Pau wrote: >> >>> Hi All, >>> >>> i was asked if we have a bottom line number for NFD in terms of >>> forwarding performance. Did anybody perform experiments? >>> >> >> This question comes up quite often. Let me add this in addition to the >> Redmine issue pointed by Davide. >> >> We do have such results that you can see in Redmine. John DeHart has done >> some experiments and more recently Chengyu Fan at CSU repeated his >> experiments and did some code profiling. >> >> Chengyu can point you to the profiling results. I don't think those were >> added to Redmine yet, he should add them soon. >> >> One caveat we always emphasize: NFD at this stage is not performance >> optimized. It is optimized to be changed :-) In other words the initial >> emphasis is on modularity, not systematic performance tuning. >> >> I say this because there is a push out there to focus on performance. For >> the PARC people, for example, this is a crucial area. >> >> Lixia makes it a point to strongly emphasize the different focus of the >> two projects (CCN and NDN) when it comes to performance. I think this is >> important. >> >> Christos. >> >> >> >>> thanks >>> /g. >>> >>> >>> Giovanni Pau, PhD >>> ========================== >>> "Any intelligent fool can make things bigger and more complex... It >>> takes a >>> touch of genius - and a lot of courage to move in the opposite >>> direction." >>> --Albert Einstein >>> ========================== >>> >>> >>> ========================== >>> It had long since come to my attention that people of accomplishment >>> rarely sat back and let things happen to them. They went out and happened >>> to things. >>> >>> - Leonardo da Vinci >>> ========================== >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> > > > > -- > Thanks, > > Chengyu > -- Thanks, Chengyu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giovanni.Pau at lip6.fr Wed Oct 8 05:57:17 2014 From: Giovanni.Pau at lip6.fr (Giovanni Pau) Date: Wed, 8 Oct 2014 05:57:17 -0700 Subject: [Nfd-dev] Performance Evaluations Message-ID: Hi All, i was asked if we have a bottom line number for NFD in terms of forwarding performance. Did anybody perform experiments? thanks /g. Giovanni Pau, PhD ========================== "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." --Albert Einstein ========================== From shijunxiao at email.arizona.edu Wed Oct 8 18:28:34 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 8 Oct 2014 18:28:34 -0700 Subject: [Nfd-dev] [Ndn-interest] NDN link protocol In-Reply-To: <76FF5F7B-EA32-44C9-AE12-5EEAA4BD94DB@cisco.com> References: <9DB27F4A-229F-45B4-A279-2381C755DBCD@memphis.edu> <76FF5F7B-EA32-44C9-AE12-5EEAA4BD94DB@cisco.com> Message-ID: Dear folks If a local area network is using regular Ethernet (learn paths from source MAC address) today, self-learning can work on it. Self-learning idea also has been tested on a 16-server fat tree topology. It's not crazy to multicast every packet. Switches are expected to understand NDN Names and act as NDN forwarders; at physical layer there's no difference between multicast and unicast. Yours, Junxiao On Wed, Oct 8, 2014 at 11:34 AM, Dave Oran (oran) wrote: > > On Oct 7, 2014, at 9:49 PM, Lan Wang (lanwang) > wrote: > > > Self learning can work to a certain degree. But if you have a large > network, it may be better to run a routing protocol. We have NLSR hello > protocol defined for multicast media. Just need to implement it. I was > just asking how to specify the Ethernet face in the configuration file. I > suppose just the multicast address. > > > It?s also fairly crazy to multicast every packet, so there has to be some > binding machinery to allow unicast at L2 > > Lan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oran at cisco.com Thu Oct 9 12:38:03 2014 From: oran at cisco.com (Dave Oran (oran)) Date: Thu, 9 Oct 2014 19:38:03 +0000 Subject: [Nfd-dev] [Ndn-interest] NDN link protocol In-Reply-To: References: <9DB27F4A-229F-45B4-A279-2381C755DBCD@memphis.edu> <76FF5F7B-EA32-44C9-AE12-5EEAA4BD94DB@cisco.com> Message-ID: <313C7A8C-8442-40C4-A417-7D9EEE32165A@cisco.com> On Oct 8, 2014, at 9:28 PM, Junxiao Shi wrote: > Dear folks > > If a local area network is using regular Ethernet (learn paths from source MAC address) today, self-learning can work on it. > Self-learning idea also has been tested on a 16-server fat tree topology. > > It's not crazy to multicast every packet. I beg to differ. Waking up 10,000 hosts on an extended LAN with a data packet when only one of them sent an interest, is, I?m afraid, actually crazy. > Switches are expected to understand NDN Names and act as NDN forwarders; good luck with that. No switches I?ve met in the last 10 years have enough memory to keep a PIT. > at physical layer there's no difference between multicast and unicast. > Also not true for pt-multipoint radios with hidden terminals. Not to mention the rate minimization pathologies of wireless LANs like 802.11. > Yours, Junxiao > > On Wed, Oct 8, 2014 at 11:34 AM, Dave Oran (oran) wrote: > > On Oct 7, 2014, at 9:49 PM, Lan Wang (lanwang) wrote: > > > Self learning can work to a certain degree. But if you have a large network, it may be better to run a routing protocol. We have NLSR hello protocol defined for multicast media. Just need to implement it. I was just asking how to specify the Ethernet face in the configuration file. I suppose just the multicast address. > > > It?s also fairly crazy to multicast every packet, so there has to be some binding machinery to allow unicast at L2 > > Lan From alexander.afanasyev at UCLA.EDU Thu Oct 9 18:02:34 2014 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Thu, 9 Oct 2014 18:02:34 -0700 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component Message-ID: Hi all, Quick background. After many discussions, we concluded that it is important to amend current Name TLV definition, to allow implicit digest component. After this change, Interest that specify implicit digest, must use implicit digest component at the end of the Name in order for the forwarder/applications to consider it as implicit digest. This explicit knowledge would allow us to simplify implementation of on-demand implicit digest calculation in NFD (with the old definition, there are several problems that prevented to implement this/significantly complicate implementation logic). * * * Please review the change to NDN-TLV spec: http://gerrit.named-data.net/#/c/1289/. You can either leave comment in gerrit (+1 / -1) or give your feedback in this mailing list. * * * The change slightly redefines what NameComponent TLV is: Name ::= NAME-TYPE TLV-LENGTH NameComponent* NameComponent ::= GenericNameComponent | ImplicitSha256DigestComponent GenericNameComponent ::= NAME-COMPONENT-TYPE TLV-LENGTH BYTE* ImplicitSha256DigestComponent ::= IMPLICIT-SHA256-DIGEST-COMPONENT-TYPE TLV-LENGTH(=32) BYTE{32} - ``GenericNameComponent`` is a generic name component, without any restrictions on the content of the value. - ``ImplicitSha256DigestComponent`` is an implicit SHA256 digest component and it is required to contain a value of 32 octets. --- Alex From oran at cisco.com Fri Oct 10 05:35:06 2014 From: oran at cisco.com (Dave Oran (oran)) Date: Fri, 10 Oct 2014 12:35:06 +0000 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: References: Message-ID: <0CAA8969-0886-4389-AF90-5A4F0835881D@cisco.com> Here?s a silly question. If the hash is now explicitly in the packet as a name component, isn?t is no long implicit but explicit? On Oct 9, 2014, at 9:02 PM, Alex Afanasyev wrote: > Hi all, > > Quick background. After many discussions, we concluded that it is important to amend current Name TLV definition, to allow implicit digest component. After this change, Interest that specify implicit digest, must use implicit digest component at the end of the Name in order for the forwarder/applications to consider it as implicit digest. This explicit knowledge would allow us to simplify implementation of on-demand implicit digest calculation in NFD (with the old definition, there are several problems that prevented to implement this/significantly complicate implementation logic). > > * * * > > Please review the change to NDN-TLV spec: http://gerrit.named-data.net/#/c/1289/. You can either leave comment in gerrit (+1 / -1) or give your feedback in this mailing list. > > * * * > > The change slightly redefines what NameComponent TLV is: > > > Name ::= NAME-TYPE TLV-LENGTH NameComponent* > > NameComponent ::= GenericNameComponent | > ImplicitSha256DigestComponent > > GenericNameComponent ::= NAME-COMPONENT-TYPE TLV-LENGTH BYTE* > > ImplicitSha256DigestComponent ::= IMPLICIT-SHA256-DIGEST-COMPONENT-TYPE TLV-LENGTH(=32) > BYTE{32} > > > - ``GenericNameComponent`` is a generic name component, without any restrictions on the content of the value. > > - ``ImplicitSha256DigestComponent`` is an implicit SHA256 digest component and it is required to contain a value of 32 octets. > > > --- > Alex > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From shijunxiao at email.arizona.edu Fri Oct 10 07:30:10 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 10 Oct 2014 07:30:10 -0700 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: <0CAA8969-0886-4389-AF90-5A4F0835881D@cisco.com> References: <0CAA8969-0886-4389-AF90-5A4F0835881D@cisco.com> Message-ID: Hi Dave "implicit digest component" is implicit in Data packet. It cannot appear in Data packet, but must be computed when needed. ImplicitSha256DigestComponent can appear in Interest Name as the last component, and in Exclude. Yours, Junxiao On Fri, Oct 10, 2014 at 5:35 AM, Dave Oran (oran) wrote: > Here?s a silly question. > If the hash is now explicitly in the packet as a name component, isn?t is > no long implicit but explicit? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Fri Oct 10 07:31:21 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Fri, 10 Oct 2014 14:31:21 +0000 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: References: Message-ID: On Oct 9, 2014, at 8:02 PM, Alex Afanasyev wrote: > Hi all, > > Quick background. After many discussions, we concluded that it is important to amend current Name TLV definition, to allow implicit digest component. After this change, Interest that specify implicit digest, must use implicit digest component at the end of the Name in order for the forwarder/applications to consider it as implicit digest. This explicit knowledge would allow us to simplify implementation of on-demand implicit digest calculation in NFD (with the old definition, there are several problems that prevented to implement this/significantly complicate implementation logic). Can you elaborate a bit on the rationale? The gerrit page doesn't offer much explanation or context. Lan > > * * * > > Please review the change to NDN-TLV spec: http://gerrit.named-data.net/#/c/1289/. You can either leave comment in gerrit (+1 / -1) or give your feedback in this mailing list. > > * * * > > The change slightly redefines what NameComponent TLV is: > > > Name ::= NAME-TYPE TLV-LENGTH NameComponent* > > NameComponent ::= GenericNameComponent | > ImplicitSha256DigestComponent > > GenericNameComponent ::= NAME-COMPONENT-TYPE TLV-LENGTH BYTE* > > ImplicitSha256DigestComponent ::= IMPLICIT-SHA256-DIGEST-COMPONENT-TYPE TLV-LENGTH(=32) > BYTE{32} > > > - ``GenericNameComponent`` is a generic name component, without any restrictions on the content of the value. > > - ``ImplicitSha256DigestComponent`` is an implicit SHA256 digest component and it is required to contain a value of 32 octets. > > > --- > Alex > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From oran at cisco.com Fri Oct 10 07:36:34 2014 From: oran at cisco.com (Dave Oran (oran)) Date: Fri, 10 Oct 2014 14:36:34 +0000 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: References: <0CAA8969-0886-4389-AF90-5A4F0835881D@cisco.com> Message-ID: <5B451056-4A89-4C89-8134-0F58ED217313@cisco.com> On Oct 10, 2014, at 10:30 AM, Junxiao Shi wrote: > Hi Dave > > "implicit digest component" is implicit in Data packet. It cannot appear in Data packet, but must be computed when needed. > ImplicitSha256DigestComponent can appear in Interest Name as the last component, and in Exclude. > then I?m even more confused than I thought. If the digest is a name component, and the data packet is supposed to echo back the exact name that was present in the interest, why isn?t the hash the last name component of the data packet as well as the interest packet. The CCN 1.0 approach does this differently by not making the hash a name component, but as a separate TLV in the Interest with the semantic of ?hash restriction? as opposed to ?implicit has as part of the name?. > Yours, Junxiao > > On Fri, Oct 10, 2014 at 5:35 AM, Dave Oran (oran) wrote: > Here?s a silly question. > If the hash is now explicitly in the packet as a name component, isn?t is no long implicit but explicit? > From shijunxiao at email.arizona.edu Fri Oct 10 08:11:52 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 10 Oct 2014 08:11:52 -0700 Subject: [Nfd-dev] remote prefix registration Message-ID: Dear folks Please see below for a discussion about which process on the laptop should send remote prefix registration commands. I remember a previous NFD conference call concluded that ndn-autoconfig tool should send such registrations. Yours, Junxiao Background The NDN testbed consists of tens of dedicated router nodes that are always online. Each router is responsible for a site prefix, such as ndn:/ndn/edu/arizona. These routers run NLSR, a link state routing protocol, to maintain a routing table so that every site prefix is reachable from every router. Currently, when a laptop (or other kind of end node) connects to a router, the nfd-autoreg-server process on the router automatically installs a Route of the site prefix toward the laptop. After that, it's up to the forwarding strategy to figure out what contents could a laptop serve. For example, every laptop connected to ARIZONA router will have a Route of prefix ndn:/ndn/edu/arizona, and the forwarding strategy must figure out that ndn:/ndn/edu/arizona/app1 is served by laptop1. While the forwarding strategy SHOULD be able to find the path, it takes time and hurts performance. *Remote prefix registration* is a feature in NFD RIB Daemon (nrd process) that allows a laptop to send a prefix registration command to the RIB Daemon running on the router. This would allow laptop1 to install a Route of prefix ndn:/ndn/edu/arizona/app1, so that the router knows to forward Interests under this prefix to laptop1 instead of other laptops. This feature is fully supported by NFD RIB Daemon, but it's not enabled on NDN testbed routers. Who should send the registration command? A laptop can send a prefix registration command to the router, but which process on the laptop should send the command? There are different opinions. *ndn-autoconfig* is a tool to establish connection to a nearby testbed router, or a user's home router (determined by the user identity). This tool can be extended to install a Route toward the laptop on the router, after a connection is established. Benefit: Route is installed whenever laptop connects to testbed. Drawback: Prefixes to be registered must be configured statically; applications cannot dynamically request a prefix to be registered on the router. *nrd* is a process that handles local prefix registrations. It can be extended to registration command to the router, if a local registration suggests the necessity of a remote prefix registration. Benefit: Prefixes to be registered can be controlled dynamically by applications. Drawback: Both nrd and applications still need to be aware of changes in testbed connections. When a laptop moves to another router, the routable prefix changes, and applications will have to switch to a new prefix. *Applications* can directly send remote prefix registrations. Drawback: This violates network layering. Does the application need to be aware of testbed connections? Yes. (Until we have map-and-encap,) each testbed router has a distinct site prefix. Application must monitor a change in the connection, and switch to the new site prefix. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Oct 10 08:15:56 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 10 Oct 2014 08:15:56 -0700 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: <5B451056-4A89-4C89-8134-0F58ED217313@cisco.com> References: <0CAA8969-0886-4389-AF90-5A4F0835881D@cisco.com> <5B451056-4A89-4C89-8134-0F58ED217313@cisco.com> Message-ID: Hi Dave The full Name of a Data packet is defined to be the Name field plus the implicit digest. An Interest, containing ImplictSha256DigestComponent or not, can be satisfied by a Data packet, if the Interest Name is a prefix of Data full Name. Yours, Junxiao On Fri, Oct 10, 2014 at 7:36 AM, Dave Oran (oran) wrote: > > On Oct 10, 2014, at 10:30 AM, Junxiao Shi > wrote: > > > Hi Dave > > > > "implicit digest component" is implicit in Data packet. It cannot appear > in Data packet, but must be computed when needed. > > ImplicitSha256DigestComponent can appear in Interest Name as the last > component, and in Exclude. > > > then I?m even more confused than I thought. > > If the digest is a name component, and the data packet is supposed to echo > back the exact name that was present in the interest, why isn?t the hash > the last name component of the data packet as well as the interest packet. > > The CCN 1.0 approach does this differently by not making the hash a name > component, but as a separate TLV in the Interest with the semantic of ?hash > restriction? as opposed to ?implicit has as part of the name?. > > > Yours, Junxiao > > > > On Fri, Oct 10, 2014 at 5:35 AM, Dave Oran (oran) > wrote: > > Here?s a silly question. > > If the hash is now explicitly in the packet as a name component, isn?t > is no long implicit but explicit? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Oct 10 08:19:54 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 10 Oct 2014 08:19:54 -0700 Subject: [Nfd-dev] [Ndn-interest] NDN link protocol In-Reply-To: <313C7A8C-8442-40C4-A417-7D9EEE32165A@cisco.com> References: <9DB27F4A-229F-45B4-A279-2381C755DBCD@memphis.edu> <76FF5F7B-EA32-44C9-AE12-5EEAA4BD94DB@cisco.com> <313C7A8C-8442-40C4-A417-7D9EEE32165A@cisco.com> Message-ID: Hi Dave The scenario is: switches understand Names, NICs understand Names. When an Interest / Data arrives at a NIC but the host is not listening to this Name prefix, the NIC should drop or NACK the packet, without waking up rest of the PC. We have high-end home routers running NFD. They have enough memory to keep a PIT. Wireless is a scenario I haven't studied much about. I'll be sure to look up the terms you mentioned. Yours, Junxiao On Thu, Oct 9, 2014 at 12:38 PM, Dave Oran (oran) wrote: > > On Oct 8, 2014, at 9:28 PM, Junxiao Shi > wrote: > > > Dear folks > > > > If a local area network is using regular Ethernet (learn paths from > source MAC address) today, self-learning can work on it. > > Self-learning idea also has been tested on a 16-server fat tree topology. > > > > It's not crazy to multicast every packet. > I beg to differ. Waking up 10,000 hosts on an extended LAN with a data > packet when only one of them sent an interest, is, I?m afraid, actually > crazy. > > > Switches are expected to understand NDN Names and act as NDN forwarders; > good luck with that. No switches I?ve met in the last 10 years have enough > memory to keep a PIT. > > > at physical layer there's no difference between multicast and unicast. > > > Also not true for pt-multipoint radios with hidden terminals. > Not to mention the rate minimization pathologies of wireless LANs like > 802.11. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Fri Oct 10 08:31:21 2014 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Fri, 10 Oct 2014 15:31:21 +0000 Subject: [Nfd-dev] Java forwarder Message-ID: Hi folks, Lixia and Alex recently mentioned the plan to build a forwarder in Java intended for Android. Perhaps someone could explain here the motivation for doing this rather than porting the existing C++ implementation? Is the expectation that it would provide all of the features of the C++ NFD? Also, what is the timeline for completion? For the Open mHealth network environment, I had assumed based on previous conversations that NFD would be used on Android and thus we'd be able to work with the "complete" platform on Android very soon. Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From oran at cisco.com Fri Oct 10 08:31:20 2014 From: oran at cisco.com (Dave Oran (oran)) Date: Fri, 10 Oct 2014 15:31:20 +0000 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: References: <0CAA8969-0886-4389-AF90-5A4F0835881D@cisco.com> <5B451056-4A89-4C89-8134-0F58ED217313@cisco.com> Message-ID: On Oct 10, 2014, at 11:15 AM, Junxiao Shi wrote: > Hi Dave > > The full Name of a Data packet is defined to be the Name field plus the implicit digest. > Therefore, by this logic the digest should not be semantically treated as a name component. Unless I?m misunderstanding the syntax proposal below, it makes the digest a name component. > An Interest, containing ImplictSha256DigestComponent or not, can be satisfied by a Data packet, if the Interest Name is a prefix of Data full Name. > I don?t understand this sentence. > Yours, Junxiao > > On Fri, Oct 10, 2014 at 7:36 AM, Dave Oran (oran) wrote: > > On Oct 10, 2014, at 10:30 AM, Junxiao Shi wrote: > > > Hi Dave > > > > "implicit digest component" is implicit in Data packet. It cannot appear in Data packet, but must be computed when needed. > > ImplicitSha256DigestComponent can appear in Interest Name as the last component, and in Exclude. > > > then I?m even more confused than I thought. > > If the digest is a name component, and the data packet is supposed to echo back the exact name that was present in the interest, why isn?t the hash the last name component of the data packet as well as the interest packet. > > The CCN 1.0 approach does this differently by not making the hash a name component, but as a separate TLV in the Interest with the semantic of ?hash restriction? as opposed to ?implicit has as part of the name?. > > > Yours, Junxiao > > > > On Fri, Oct 10, 2014 at 5:35 AM, Dave Oran (oran) wrote: > > Here?s a silly question. > > If the hash is now explicitly in the packet as a name component, isn?t is no long implicit but explicit? > > From oran at cisco.com Fri Oct 10 08:42:48 2014 From: oran at cisco.com (Dave Oran (oran)) Date: Fri, 10 Oct 2014 15:42:48 +0000 Subject: [Nfd-dev] [Ndn-interest] NDN link protocol In-Reply-To: References: <9DB27F4A-229F-45B4-A279-2381C755DBCD@memphis.edu> <76FF5F7B-EA32-44C9-AE12-5EEAA4BD94DB@cisco.com> <313C7A8C-8442-40C4-A417-7D9EEE32165A@cisco.com> Message-ID: On Oct 10, 2014, at 11:19 AM, Junxiao Shi wrote: > Hi Dave > > The scenario is: switches understand Names, NICs understand Names. > I understand the scenario. I?m pointing out first that it?s highly unrealistic, and second that when you have a big flat L2 waking up all the nodes with multicasts is a very bad idea. I still argue that we need L3<->L2 binding machinery either built into NDN or in some kind of convergence layer, and that either multicasting everything or re-inventing ARP are poor choices. For example, I?d think about at least the following: - use different multicast addresses for Interests and Data - perhaps partition the multicast space using prefix hashes (analogous to what is done when mapping IP multicast to L2 multicast) - Record in the PIT the source MAC address of the interest as well as the incoming face. This allows you to make an intelligent decision as to whether to multicast or unicast the data packet based on how many consumers have asked for a given data packet. - use routing to suppress redundant forwarding of interests received by multiple forwarders on the same LAN. This can be done using designated router techniques as in OSPF/ISIS for IP, or perhaps we can do something cleverer. And there?s probably a whole lot more, including how to do liveness assessment without relying on Hellos - perhaps we just run BFD. > When an Interest / Data arrives at a NIC but the host is not listening to this Name prefix, the NIC should drop or NACK the packet, without waking up rest of the PC. > This seems quite unrealistic for a NIC to do. > We have high-end home routers running NFD. They have enough memory to keep a PIT. No doubt. I?ll grant the home router case. It?s the easy one. Bandwidth is low, node count is low. > > > Wireless is a scenario I haven't studied much about. I'll be sure to look up the terms you mentioned. > > Yours, Junxiao > > On Thu, Oct 9, 2014 at 12:38 PM, Dave Oran (oran) wrote: > > On Oct 8, 2014, at 9:28 PM, Junxiao Shi wrote: > > > Dear folks > > > > If a local area network is using regular Ethernet (learn paths from source MAC address) today, self-learning can work on it. > > Self-learning idea also has been tested on a 16-server fat tree topology. > > > > It's not crazy to multicast every packet. > I beg to differ. Waking up 10,000 hosts on an extended LAN with a data packet when only one of them sent an interest, is, I?m afraid, actually crazy. > > > Switches are expected to understand NDN Names and act as NDN forwarders; > good luck with that. No switches I?ve met in the last 10 years have enough memory to keep a PIT. > > > at physical layer there's no difference between multicast and unicast. > > > Also not true for pt-multipoint radios with hidden terminals. > Not to mention the rate minimization pathologies of wireless LANs like 802.11. > From davide.pesavento at lip6.fr Fri Oct 10 08:45:06 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Fri, 10 Oct 2014 17:45:06 +0200 Subject: [Nfd-dev] remote prefix registration In-Reply-To: References: Message-ID: On Fri, Oct 10, 2014 at 5:11 PM, Junxiao Shi wrote: > Dear folks > > Please see below for a discussion about which process on the laptop should > send remote prefix registration commands. > Hi Junxiao, >From your analysis, it seems to me that using NRD to perform the registrations gives more benefits and less drawbacks compared to the alternatives. I'm wondering why your conclusions are different. > I remember a previous NFD conference call concluded that ndn-autoconfig tool > should send such registrations. > Does this mean that a decision has already been made? If so, what's the purpose of this email? [...] > nrd is a process that handles local prefix registrations. It can be extended > to registration command to the router, if a local registration suggests the > necessity of a remote prefix registration. > Benefit: Prefixes to be registered can be controlled dynamically by > applications. > Drawback: Both nrd and applications still need to be aware of changes in > testbed connections. When a laptop moves to another router, the routable > prefix changes, and applications will have to switch to a new prefix. > Why isn't ndn-autoconfig affected by this problem? Thanks, Davide From shijunxiao at email.arizona.edu Fri Oct 10 08:54:06 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 10 Oct 2014 08:54:06 -0700 Subject: [Nfd-dev] remote prefix registration In-Reply-To: References: Message-ID: Hi Davide That decision was made upon a choice between autoconfig and applications. NRD sending remote registrations is a new proposal, so we need to reconsider. Yours, Junxiao On Oct 10, 2014 8:46 AM, "Davide Pesavento" wrote: > > I remember a previous NFD conference call concluded that ndn-autoconfig tool > > should send such registrations. > > > > Does this mean that a decision has already been made? If so, what's > the purpose of this email? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Fri Oct 10 09:49:21 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Fri, 10 Oct 2014 09:49:21 -0700 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: <0CAA8969-0886-4389-AF90-5A4F0835881D@cisco.com> References: <0CAA8969-0886-4389-AF90-5A4F0835881D@cisco.com> Message-ID: <5E716ABF-43E6-45AD-9524-34BD750A7E5F@ucla.edu> Hi Dave, On Oct 10, 2014, at 5:35 AM, Dave Oran (oran) wrote: > Here?s a silly question. > If the hash is now explicitly in the packet as a name component, isn?t is no long implicit but explicit? Junxiao has already answered this question, but I'll try to do it in slightly different words. This digest component is still "implicit", since it represents the hash of the Data packet. It is not (and physically cannot be) present in the Data packet name, but is, logically, a last component of the Data packet's name. The spec update just makes it explicit that this component represents this digest (so, forwarders don't need to guess) and explicitly defines the digest algorithm (sha256 for now, which can be easily rolled to a new one later if needed). The primary, and I would say the only, reason to explicitly "mark" the implicit digest component in the Interest name is to allow simpler logic while implementing optimized version of NDN packet forwarding (I'll try to elaborate this in reply to Lan's question). I can say for myself, but others would probably agree with me, that putting things directly in the name provides unification of the processing logic. In other words, all selectors: right/left most child, exclude, and any other component-based selectors (the existing and/or new ones in the future) apply universally to any name components. For example, however controversial it is, the exclude filter provides the client an ultimate ability to re-request a different data packet with the same name---when the first packet have wrong signature, is corrupted, or for any other reason the consumer decided that it got the wrong data. Yes, the parc's proposal introduces hash restriction (aka selector). As I understand correctly, this restriction is based on "content hash", rather than "data packet hash". This is very different thing from the implicit hash and has very different use case: content hash identifies "content", while implicit digest identifies specific Data packet (which is the atomic unit in NDN sense). With just content hash it is impossible to "exclude" wrong data, since it is not really known whether the content is wrong or signature is wrong. It also has implications while requesting Data: what you would get back is "content", which can have any name. This may be acceptable in some cases, while not so in others where name is used by the application (e.g., if app needs to know which segment this returned piece of content belongs). --- Alex > On Oct 9, 2014, at 9:02 PM, Alex Afanasyev wrote: > >> Hi all, >> >> Quick background. After many discussions, we concluded that it is important to amend current Name TLV definition, to allow implicit digest component. After this change, Interest that specify implicit digest, must use implicit digest component at the end of the Name in order for the forwarder/applications to consider it as implicit digest. This explicit knowledge would allow us to simplify implementation of on-demand implicit digest calculation in NFD (with the old definition, there are several problems that prevented to implement this/significantly complicate implementation logic). >> >> * * * >> >> Please review the change to NDN-TLV spec: http://gerrit.named-data.net/#/c/1289/. You can either leave comment in gerrit (+1 / -1) or give your feedback in this mailing list. >> >> * * * >> >> The change slightly redefines what NameComponent TLV is: >> >> >> Name ::= NAME-TYPE TLV-LENGTH NameComponent* >> >> NameComponent ::= GenericNameComponent | >> ImplicitSha256DigestComponent >> >> GenericNameComponent ::= NAME-COMPONENT-TYPE TLV-LENGTH BYTE* >> >> ImplicitSha256DigestComponent ::= IMPLICIT-SHA256-DIGEST-COMPONENT-TYPE TLV-LENGTH(=32) >> BYTE{32} >> >> >> - ``GenericNameComponent`` is a generic name component, without any restrictions on the content of the value. >> >> - ``ImplicitSha256DigestComponent`` is an implicit SHA256 digest component and it is required to contain a value of 32 octets. >> >> >> --- >> Alex >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From alexander.afanasyev at UCLA.EDU Fri Oct 10 10:12:41 2014 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Fri, 10 Oct 2014 10:12:41 -0700 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: References: Message-ID: <7B3A2EFD-9C69-4A2A-ABD2-E627D299222E@ucla.edu> On Oct 10, 2014, at 7:31 AM, Lan Wang (lanwang) wrote: > > On Oct 9, 2014, at 8:02 PM, Alex Afanasyev wrote: > >> Hi all, >> >> Quick background. After many discussions, we concluded that it is important to amend current Name TLV definition, to allow implicit digest component. After this change, Interest that specify implicit digest, must use implicit digest component at the end of the Name in order for the forwarder/applications to consider it as implicit digest. This explicit knowledge would allow us to simplify implementation of on-demand implicit digest calculation in NFD (with the old definition, there are several problems that prevented to implement this/significantly complicate implementation logic). > > Can you elaborate a bit on the rationale? The gerrit page doesn't offer much explanation or context. There are two issues here: - (correctness) Explicit definition of the digest algorithm, so it can be changed later without requiring any flag day - (optimization) Simplification of the processing logic. Let me elaborate on the second one. We are assuming that the implicit digest will not be present in the majority of the Interests, therefore a lot of cpu cycles can be saved by calculating the digest only when needed. With the old spec there are two issues of different importance: - (not critical) it is not directly known when exactly Interest carries the digest. One can guess that, but it would be just a guess. It would work most of the time, but can fail sometimes. - (critical) canonical ordering and selector processing. As it currently stays, implicit digest component has the same canonical ordering comparison rules as any other component. Therefore, to guarantee that the selectors (especially, right/left child, exclude) are processed correctly, one must calculate digest before putting Data packet into the content store. Technically, we still can implement delayed digest calculation. However, the implementation has to make sure that relevant packets in CS are re-indexed before processing relevant selectors (which is not trivial and we never end up implementing this). Separating digest into a separate class, simplifies canonical ordering: unique names without implicit digest and with implicit digest will be (should be) ordered the same. When there are different Data packets with the same name (different implicit digest), then they may need to be reshuffled, but this is a special case. Just a basic example. The order without digest: (current spec) /a; /a/b (updated spec) /a; /a/b With the current spec, the with digest: (current spec) /a/b/; /a/ (updated spec) /a/; /a/b/ -- Alex > Lan >> >> * * * >> >> Please review the change to NDN-TLV spec: http://gerrit.named-data.net/#/c/1289/. You can either leave comment in gerrit (+1 / -1) or give your feedback in this mailing list. >> >> * * * >> >> The change slightly redefines what NameComponent TLV is: >> >> >> Name ::= NAME-TYPE TLV-LENGTH NameComponent* >> >> NameComponent ::= GenericNameComponent | >> ImplicitSha256DigestComponent >> >> GenericNameComponent ::= NAME-COMPONENT-TYPE TLV-LENGTH BYTE* >> >> ImplicitSha256DigestComponent ::= IMPLICIT-SHA256-DIGEST-COMPONENT-TYPE TLV-LENGTH(=32) >> BYTE{32} >> >> >> - ``GenericNameComponent`` is a generic name component, without any restrictions on the content of the value. >> >> - ``ImplicitSha256DigestComponent`` is an implicit SHA256 digest component and it is required to contain a value of 32 octets. >> >> >> --- >> Alex >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From wentaoshang at gmail.com Fri Oct 10 10:43:44 2014 From: wentaoshang at gmail.com (Wentao Shang) Date: Fri, 10 Oct 2014 10:43:44 -0700 Subject: [Nfd-dev] [Ndn-interest] NDN link protocol In-Reply-To: References: <9DB27F4A-229F-45B4-A279-2381C755DBCD@memphis.edu> <76FF5F7B-EA32-44C9-AE12-5EEAA4BD94DB@cisco.com> <313C7A8C-8442-40C4-A417-7D9EEE32165A@cisco.com> Message-ID: On Fri, Oct 10, 2014 at 8:42 AM, Dave Oran (oran) wrote: > > On Oct 10, 2014, at 11:19 AM, Junxiao Shi > wrote: > > > Hi Dave > > > > The scenario is: switches understand Names, NICs understand Names. > > > I understand the scenario. I?m pointing out first that it?s highly > unrealistic, and second that when you have a big flat L2 waking up all the > nodes with multicasts is a very bad idea. > > I still argue that we need L3<->L2 binding machinery either built into NDN > or in some kind of convergence layer, Agree. > and that either multicasting everything or re-inventing ARP are poor > choices. > But I don't know what other options we may have. Something like NDN Neighbor Discovery? :) > > For example, I?d think about at least the following: > - use different multicast addresses for Interests and Data > - perhaps partition the multicast space using prefix hashes (analogous to > what is done when mapping IP multicast to L2 multicast) > - Record in the PIT the source MAC address of the interest as well as the > incoming face. This allows you to make an intelligent decision as to > whether to multicast or unicast the data packet based on how many consumers > have asked for a given data packet. > Personally I like this idea. This can be extended to other NBMA links as well. Eventually we should have individual faces per L2 host (or per L2 interface). This will be very useful in wireless mesh networks where L2 multicast is much more expensive than on the Ethernet. Best, Wentao > - use routing to suppress redundant forwarding of interests received by > multiple forwarders on the same LAN. This can be done using designated > router techniques as in OSPF/ISIS for IP, or perhaps we can do something > cleverer. > > And there?s probably a whole lot more, including how to do liveness > assessment without relying on Hellos - perhaps we just run BFD. > > > > When an Interest / Data arrives at a NIC but the host is not listening > to this Name prefix, the NIC should drop or NACK the packet, without waking > up rest of the PC. > > > This seems quite unrealistic for a NIC to do. > > > We have high-end home routers running NFD. They have enough memory to > keep a PIT. > No doubt. > I?ll grant the home router case. It?s the easy one. Bandwidth is low, node > count is low. > > > > > > > Wireless is a scenario I haven't studied much about. I'll be sure to > look up the terms you mentioned. > > > > Yours, Junxiao > > > > On Thu, Oct 9, 2014 at 12:38 PM, Dave Oran (oran) > wrote: > > > > On Oct 8, 2014, at 9:28 PM, Junxiao Shi > wrote: > > > > > Dear folks > > > > > > If a local area network is using regular Ethernet (learn paths from > source MAC address) today, self-learning can work on it. > > > Self-learning idea also has been tested on a 16-server fat tree > topology. > > > > > > It's not crazy to multicast every packet. > > I beg to differ. Waking up 10,000 hosts on an extended LAN with a data > packet when only one of them sent an interest, is, I?m afraid, actually > crazy. > > > > > Switches are expected to understand NDN Names and act as NDN > forwarders; > > good luck with that. No switches I?ve met in the last 10 years have > enough memory to keep a PIT. > > > > > at physical layer there's no difference between multicast and unicast. > > > > > Also not true for pt-multipoint radios with hidden terminals. > > Not to mention the rate minimization pathologies of wireless LANs like > 802.11. > > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -- PhD @ IRL, CSD, UCLA -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ignacio.Solis at parc.com Fri Oct 10 12:48:49 2014 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Fri, 10 Oct 2014 19:48:49 +0000 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: References: <5E716ABF-43E6-45AD-9524-34BD750A7E5F@ucla.edu> Message-ID: >>Yes, the parc's proposal introduces hash restriction (aka selector). As >>I understand correctly, this restriction is based on "content hash", >>rather than "data packet hash". This is very different thing from the >>implicit hash and has very different use case: content hash identifies >>"content", while implicit digest identifies specific Data packet (which >>is the atomic unit in NDN sense). With just content hash it is >>impossible to "exclude" wrong data, since it is not really known whether >>the content is wrong or signature is wrong. It also has implications >>while requesting Data: what you would get back is "content", which can >>have any name. This may be acceptable in some cases, while not so in >>others where name is used by the application (e.g., if app needs to know >>which segment this returned piece of content belongs). The ContentObjectHash restriction in CCN is over the Content Object (as the name implies). This includes the name and signature (if present). It is the same as the implicit hash in the sense that the hash is implicit in the content object. This is calculated over the message. The static headers and the optional headers are NOT part of the message. We don?t exclude data, so that is, effectively, impossible for CCN. Having said that, if you followed the SelectorProtocol described in the NDN-interest list this ContentObjectHash would be able to be used for excludes just like the ones on NDN. It servers the same purpose but it?s not part of a name. It is NOT true that the content you get can have any name. The content has either a) the exact same name as the interest (after all, we do exact matching), or b) no name at all. Also, I don?t understand why you say that the app needs to know what segment you?re getting. Didn?t you request the content with a name anyway? Use that name. Also, if you have a ContentObjectHash, that means somebody gave you that hash, did they not tell you what this hash was for? Nacho From alexander.afanasyev at ucla.edu Fri Oct 10 13:01:07 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Fri, 10 Oct 2014 13:01:07 -0700 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: References: <5E716ABF-43E6-45AD-9524-34BD750A7E5F@ucla.edu> Message-ID: <3435623D-9C62-4E99-ACE1-6F11ADB0C985@ucla.edu> On Oct 10, 2014, at 12:48 PM, wrote: >>> Yes, the parc's proposal introduces hash restriction (aka selector). As >>> I understand correctly, this restriction is based on "content hash", >>> rather than "data packet hash". This is very different thing from the >>> implicit hash and has very different use case: content hash identifies >>> "content", while implicit digest identifies specific Data packet (which >>> is the atomic unit in NDN sense). With just content hash it is >>> impossible to "exclude" wrong data, since it is not really known whether >>> the content is wrong or signature is wrong. It also has implications >>> while requesting Data: what you would get back is "content", which can >>> have any name. This may be acceptable in some cases, while not so in >>> others where name is used by the application (e.g., if app needs to know >>> which segment this returned piece of content belongs). > > The ContentObjectHash restriction in CCN is over the Content Object (as > the name implies). This includes the name and signature (if present). Sorry. I misunderstood then. So, this basically exactly the same thing, covering Name, meta parts of the data packet, Content, and signature parts? > It is the same as the implicit hash in the sense that the hash is implicit > in the content object. This is calculated over the message. The static > headers and the optional headers are NOT part of the message. > > We don?t exclude data, so that is, effectively, impossible for CCN. > Having said that, if you followed the SelectorProtocol described in the > NDN-interest list this ContentObjectHash would be able to be used for > excludes just like the ones on NDN. It servers the same purpose but it?s > not part of a name. > > It is NOT true that the content you get can have any name. The content > has either a) the exact same name as the interest (after all, we do exact > matching), or b) no name at all. > > Also, I don?t understand why you say that the app needs to know what > segment you?re getting. Didn?t you request the content with a name > anyway? Use that name. Also, if you have a ContentObjectHash, that means > somebody gave you that hash, did they not tell you what this hash was for? I just gave an example of what can go wrong with this. Yes, you're requesting by hash. But if the only thing you know is the hash, how would you reliably reconstruct the whole thing without relying on something extra (like the order in manifest). In any case, this is a separate discussion and the primary goal for my original email is to move the NDN spec forward. --- Alex From Ignacio.Solis at parc.com Fri Oct 10 14:42:07 2014 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Fri, 10 Oct 2014 21:42:07 +0000 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: <3435623D-9C62-4E99-ACE1-6F11ADB0C985@ucla.edu> References: <5E716ABF-43E6-45AD-9524-34BD750A7E5F@ucla.edu> <3435623D-9C62-4E99-ACE1-6F11ADB0C985@ucla.edu> Message-ID: On 10/10/14, 1:01 PM, "Alex Afanasyev" wrote: >On Oct 10, 2014, at 12:48 PM, > wrote: >>>> Yes, the parc's proposal introduces hash restriction (aka selector). >>>>As >>>> I understand correctly, this restriction is based on "content hash", >>>> rather than "data packet hash". This is very different thing from >>>>the >>>> implicit hash and has very different use case: content hash >>>>identifies >>>> "content", while implicit digest identifies specific Data packet >>>>(which >>>> is the atomic unit in NDN sense). With just content hash it is >>>> impossible to "exclude" wrong data, since it is not really known >>>>whether >>>> the content is wrong or signature is wrong. It also has implications >>>> while requesting Data: what you would get back is "content", which can >>>> have any name. This may be acceptable in some cases, while not so in >>>> others where name is used by the application (e.g., if app needs to >>>>know >>>> which segment this returned piece of content belongs). >> >> The ContentObjectHash restriction in CCN is over the Content Object (as >> the name implies). This includes the name and signature (if present). > >Sorry. I misunderstood then. So, this basically exactly the same thing, >covering Name, meta parts of the data packet, Content, and signature >parts? Basically yes. It just doesn?t cover the static header and optional headers (which you don?t have in NDN). >> It is the same as the implicit hash in the sense that the hash is >>implicit >> in the content object. This is calculated over the message. The static >> headers and the optional headers are NOT part of the message. >> >> We don?t exclude data, so that is, effectively, impossible for CCN. >> Having said that, if you followed the SelectorProtocol described in the >> NDN-interest list this ContentObjectHash would be able to be used for >> excludes just like the ones on NDN. It servers the same purpose but >>it?s >> not part of a name. >> >> It is NOT true that the content you get can have any name. The content >> has either a) the exact same name as the interest (after all, we do >>exact >> matching), or b) no name at all. >> >> Also, I don?t understand why you say that the app needs to know what >> segment you?re getting. Didn?t you request the content with a name >> anyway? Use that name. Also, if you have a ContentObjectHash, that >>means >> somebody gave you that hash, did they not tell you what this hash was >>for? > >I just gave an example of what can go wrong with this. Yes, you're >requesting by hash. But if the only thing you know is the hash, how >would you reliably reconstruct the whole thing without relying on >something extra (like the order in manifest). You still need a name, otherwise the Interest would not have been forwarded. Also, I?m not sure where you would get a hash only. If you did get the hash (and some potentially uninformative name) from the manifest, then you already have that info, it?s in the manifest. >In any case, this is a separate discussion and the primary goal for my >original email is to move the NDN spec forward. I was just clearing up the CCN methods. Even if you don?t do the same thing in NDN, at least it would hopefully inform you of what we?re doing in CCN so you can make good architectural choices. Nacho -- Nacho (Ignacio) Solis Protocol Architect Principal Scientist Palo Alto Research Center (PARC) +1(650)812-4458 Ignacio.Solis at parc.com From shijunxiao at email.arizona.edu Fri Oct 10 14:48:25 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 10 Oct 2014 14:48:25 -0700 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: References: <0CAA8969-0886-4389-AF90-5A4F0835881D@cisco.com> <5B451056-4A89-4C89-8134-0F58ED217313@cisco.com> Message-ID: Hi Dave Please see the following pseudocode that explains the sentences below. data.fullName = data.name + computeImplicitDigest(data); function matches(interest, data) { if (! interest.name.isPrefixOf(data.fullName)) return false; // test other selectors return true; } Yours, Junxiao On Fri, Oct 10, 2014 at 8:31 AM, Dave Oran (oran) wrote: > > On Oct 10, 2014, at 11:15 AM, Junxiao Shi > wrote: > > > > The full Name of a Data packet is defined to be the Name field plus the > implicit digest. > > > Therefore, by this logic the digest should not be semantically treated as > a name component. Unless I?m misunderstanding the syntax proposal below, it > makes the digest a name component. > > > An Interest, containing ImplictSha256DigestComponent or not, can be > satisfied by a Data packet, if the Interest Name is a prefix of Data full > Name. > > > I don?t understand this sentence. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at UCLA.EDU Fri Oct 10 19:08:52 2014 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Fri, 10 Oct 2014 19:08:52 -0700 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: References: <5E716ABF-43E6-45AD-9524-34BD750A7E5F@ucla.edu> <3435623D-9C62-4E99-ACE1-6F11ADB0C985@ucla.edu> Message-ID: <59C31F88-629E-43C1-8AAD-5AF0CF770572@ucla.edu> On Oct 10, 2014, at 2:42 PM, Ignacio.Solis at parc.com wrote: > On 10/10/14, 1:01 PM, "Alex Afanasyev" > wrote: > >> On Oct 10, 2014, at 12:48 PM, >> wrote: >>>>> Yes, the parc's proposal introduces hash restriction (aka selector). >>>>> As >>>>> I understand correctly, this restriction is based on "content hash", >>>>> rather than "data packet hash". This is very different thing from >>>>> the >>>>> implicit hash and has very different use case: content hash >>>>> identifies >>>>> "content", while implicit digest identifies specific Data packet >>>>> (which >>>>> is the atomic unit in NDN sense). With just content hash it is >>>>> impossible to "exclude" wrong data, since it is not really known >>>>> whether >>>>> the content is wrong or signature is wrong. It also has implications >>>>> while requesting Data: what you would get back is "content", which can >>>>> have any name. This may be acceptable in some cases, while not so in >>>>> others where name is used by the application (e.g., if app needs to >>>>> know >>>>> which segment this returned piece of content belongs). >>> >>> The ContentObjectHash restriction in CCN is over the Content Object (as >>> the name implies). This includes the name and signature (if present). >> >> Sorry. I misunderstood then. So, this basically exactly the same thing, >> covering Name, meta parts of the data packet, Content, and signature >> parts? > > Basically yes. It just doesn?t cover the static header and optional > headers (which you don?t have in NDN). > > > >>> It is the same as the implicit hash in the sense that the hash is >>> implicit >>> in the content object. This is calculated over the message. The static >>> headers and the optional headers are NOT part of the message. >>> >>> We don?t exclude data, so that is, effectively, impossible for CCN. >>> Having said that, if you followed the SelectorProtocol described in the >>> NDN-interest list this ContentObjectHash would be able to be used for >>> excludes just like the ones on NDN. It servers the same purpose but >>> it?s >>> not part of a name. >>> >>> It is NOT true that the content you get can have any name. The content >>> has either a) the exact same name as the interest (after all, we do >>> exact >>> matching), or b) no name at all. >>> >>> Also, I don?t understand why you say that the app needs to know what >>> segment you?re getting. Didn?t you request the content with a name >>> anyway? Use that name. Also, if you have a ContentObjectHash, that >>> means >>> somebody gave you that hash, did they not tell you what this hash was >>> for? >> >> I just gave an example of what can go wrong with this. Yes, you're >> requesting by hash. But if the only thing you know is the hash, how >> would you reliably reconstruct the whole thing without relying on >> something extra (like the order in manifest). > > You still need a name, otherwise the Interest would not have been > forwarded. > > Also, I?m not sure where you would get a hash only. If you did get the > hash (and some potentially uninformative name) from the manifest, then you > already have that info, it?s in the manifest. Yes, manifest can have such information, which in such a hypothetical case would need to be remembered somewhere. However, I think it is important to keep all relevant information in the Name, so it can be (to some extent) used on its own (less things to remember in the app/library). >> In any case, this is a separate discussion and the primary goal for my >> original email is to move the NDN spec forward. > > I was just clearing up the CCN methods. Even if you don?t do the same > thing in NDN, at least it would hopefully inform you of what we?re doing > in CCN so you can make good architectural choices. Sure, you're always welcome. Thanks for the comments and corrections. --- Alex > Nacho > > > -- > Nacho (Ignacio) Solis > Protocol Architect > Principal Scientist > Palo Alto Research Center (PARC) > +1(650)812-4458 > Ignacio.Solis at parc.com From oran at cisco.com Sat Oct 11 07:09:37 2014 From: oran at cisco.com (Dave Oran (oran)) Date: Sat, 11 Oct 2014 14:09:37 +0000 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: References: <0CAA8969-0886-4389-AF90-5A4F0835881D@cisco.com> <5B451056-4A89-4C89-8134-0F58ED217313@cisco.com> Message-ID: <1FA690E3-1DC1-42FD-A9E0-BE4471C2CC30@cisco.com> On Oct 10, 2014, at 5:48 PM, Junxiao Shi wrote: > Hi Dave > > Please see the following pseudocode that explains the sentences below. > > data.fullName = data.name + computeImplicitDigest(data); > > function matches(interest, data) { > if (! interest.name.isPrefixOf(data.fullName)) > return false; > // test other selectors > return true; > } > Ah, forgot NDN does LPM on data even if you supply a hash. Thanks. > > > Yours, Junxiao > > On Fri, Oct 10, 2014 at 8:31 AM, Dave Oran (oran) wrote: > > On Oct 10, 2014, at 11:15 AM, Junxiao Shi wrote: > > > > The full Name of a Data packet is defined to be the Name field plus the implicit digest. > > > Therefore, by this logic the digest should not be semantically treated as a name component. Unless I?m misunderstanding the syntax proposal below, it makes the digest a name component. > > > An Interest, containing ImplictSha256DigestComponent or not, can be satisfied by a Data packet, if the Interest Name is a prefix of Data full Name. > > > I don?t understand this sentence. > From Ignacio.Solis at parc.com Sat Oct 11 10:10:38 2014 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Sat, 11 Oct 2014 17:10:38 +0000 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: <59C31F88-629E-43C1-8AAD-5AF0CF770572@ucla.edu> References: <5E716ABF-43E6-45AD-9524-34BD750A7E5F@ucla.edu> <3435623D-9C62-4E99-ACE1-6F11ADB0C985@ucla.edu> <59C31F88-629E-43C1-8AAD-5AF0CF770572@ucla.edu> Message-ID: On 10/10/14, 7:08 PM, "Alex Afanasyev" wrote: >> >> You still need a name, otherwise the Interest would not have been >> forwarded. >> >> Also, I?m not sure where you would get a hash only. If you did get the >> hash (and some potentially uninformative name) from the manifest, then >>you >> already have that info, it?s in the manifest. > >Yes, manifest can have such information, which in such a hypothetical >case would need to be remembered somewhere. However, I think it is >important to keep all relevant information in the Name, so it can be (to >some extent) used on its own (less things to remember in the app/library). I understand that you want to make things simple, but I?m not sure I see a big difference here. What I hear you say is that in the ?keep all relevant information in the name? method you will keep only that name as state and in the other you need to keep a manifest. So, in the state-in-name you would keep "/foo/bar/version=10/chunk=100? as the context for the stack. This would allow you to predict that the next content is "/foo/bar/version=10/chunk=101?. Is this right? In the manifest method you would need the whole manifest with a list of the names and hashes. However, for the state-in-name method, where did you get the hash from? (We were talking about names with implicit hashes). Even if you got the first hash from a link, where did you get the second hash from? I?m assuming you need to keep these hashes somewhere. And the hashes have to be associated with names. Are these hashes not kept in the app/library? For us, this structure is basically the manifest. Nacho -- Nacho (Ignacio) Solis Protocol Architect Principal Scientist Palo Alto Research Center (PARC) +1(650)812-4458 Ignacio.Solis at parc.com From shijunxiao at email.arizona.edu Sat Oct 11 23:09:54 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 11 Oct 2014 23:09:54 -0700 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: References: <99C28F48-01A2-4ED7-88F4-AC7E3572220C@ucla.edu> Message-ID: Dear folks There needs a guideline on how to write license boilerplate for code imported from NFD to ndn-cxx. The necessity of such a guideline is illustrated by http://gerrit.named-data.net/1254 where the Change Owner fails to produce a correct license boilerplate in 3 patchsets. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun Oct 12 11:17:14 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 12 Oct 2014 11:17:14 -0700 Subject: [Nfd-dev] Fwd: License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: <92AD88A8-DD61-41CA-B2BC-B3F7D4FF0FF9@gmail.com> References: <99C28F48-01A2-4ED7-88F4-AC7E3572220C@ucla.edu> <92AD88A8-DD61-41CA-B2BC-B3F7D4FF0FF9@gmail.com> Message-ID: ---------- Forwarded message ---------- From: Jiewen Tan Date: Sat, Oct 11, 2014 at 11:53 PM Subject: Re: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx To: Junxiao Shi Hi All, I am the owner. I do agree with Junxiao there should be a guideline, otherwise new people like me will be confused while importing codes. Regards, Jiewen Tan On Oct 11, 2014, at 11:09 PM, Junxiao Shi wrote: Dear folks There needs a guideline on how to write license boilerplate for code imported from NFD to ndn-cxx. The necessity of such a guideline is illustrated by http://gerrit.named-data.net/1254 where the Change Owner fails to produce a correct license boilerplate in 3 patchsets. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.pesavento at lip6.fr Sun Oct 12 16:26:23 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Mon, 13 Oct 2014 01:26:23 +0200 Subject: [Nfd-dev] Fwd: License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: References: <99C28F48-01A2-4ED7-88F4-AC7E3572220C@ucla.edu> <92AD88A8-DD61-41CA-B2BC-B3F7D4FF0FF9@gmail.com> Message-ID: Well then maybe the first rule should be: read (and understand) the license of the code you're touching/using. Best, Davide On Sun, Oct 12, 2014 at 8:17 PM, Junxiao Shi wrote: > > ---------- Forwarded message ---------- > From: Jiewen Tan > Date: Sat, Oct 11, 2014 at 11:53 PM > Subject: Re: [Nfd-dev] License boilerplate for code imported from NFD to > ndn-cxx > To: Junxiao Shi > > > Hi All, > > I am the owner. I do agree with Junxiao there should be a guideline, > otherwise new people like me will be confused while importing codes. > > Regards, > Jiewen Tan > > On Oct 11, 2014, at 11:09 PM, Junxiao Shi > wrote: > > Dear folks > > There needs a guideline on how to write license boilerplate for code > imported from NFD to ndn-cxx. > The necessity of such a guideline is illustrated by > http://gerrit.named-data.net/1254 where the Change Owner fails to produce a > correct license boilerplate in 3 patchsets. > > Yours, Junxiao > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From shijunxiao at email.arizona.edu Sun Oct 12 16:49:09 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 12 Oct 2014 16:49:09 -0700 Subject: [Nfd-dev] Fwd: License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: References: <99C28F48-01A2-4ED7-88F4-AC7E3572220C@ucla.edu> <92AD88A8-DD61-41CA-B2BC-B3F7D4FF0FF9@gmail.com> Message-ID: Hi Davide Developers are not lawyers. License is to be interpreted by a lawyer. Requiring consulting a lawyer every time importing NFD code is counter-productive. The guideline should be some mechanical steps that developers could easily follow. Note the scope of this discussion is specifically for importing code from NFD, and probably NLSR and repo-ng. I agree that importing code from an external project should involve consulting with a lawyer. Yours, Junxiao On Sun, Oct 12, 2014 at 4:26 PM, Davide Pesavento wrote: > Well then maybe the first rule should be: read (and understand) the > license of the code you're touching/using. > > Best, > Davide > > > ---------- Forwarded message ---------- > > From: Jiewen Tan > > Date: Sat, Oct 11, 2014 at 11:53 PM > > > > Hi All, > > > > I am the owner. I do agree with Junxiao there should be a guideline, > > otherwise new people like me will be confused while importing codes. > > > > Regards, > > Jiewen Tan > > > > On Oct 11, 2014, at 11:09 PM, Junxiao Shi > > wrote: > > > > Dear folks > > > > There needs a guideline on how to write license boilerplate for code > > imported from NFD to ndn-cxx. > > The necessity of such a guideline is illustrated by > > http://gerrit.named-data.net/1254 where the Change Owner fails to > produce a > > correct license boilerplate in 3 patchsets. > > > > Yours, Junxiao > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Sun Oct 12 17:22:44 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Sun, 12 Oct 2014 17:22:44 -0700 Subject: [Nfd-dev] Fwd: License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: References: <99C28F48-01A2-4ED7-88F4-AC7E3572220C@ucla.edu> <92AD88A8-DD61-41CA-B2BC-B3F7D4FF0FF9@gmail.com> Message-ID: <98EBF759-A842-4D4C-8BEA-6FBCD0F9DF22@ucla.edu> Junxiao, Please, don't make an issue from a non-issue. The license (and license boilerplate) is in itself instructions on how code can be used, re-used, and moved around. There is noting special that needs to be added. For the cases you're referring to. This is the point of code review, when you noticed that boilerplate is not the one we usually use / incorrect copyright/license attribute. There is no guidelines, rather you just need to tell what is the right way. That's it. Licenses are pretty simple to read (at least the boilerplate) and it is important for everybody to understand the limitations of the licenses. --- Alex On Oct 12, 2014, at 4:49 PM, Junxiao Shi wrote: > Hi Davide > > Developers are not lawyers. License is to be interpreted by a lawyer. Requiring consulting a lawyer every time importing NFD code is counter-productive. > The guideline should be some mechanical steps that developers could easily follow. > > Note the scope of this discussion is specifically for importing code from NFD, and probably NLSR and repo-ng. > I agree that importing code from an external project should involve consulting with a lawyer. > > Yours, Junxiao > > On Sun, Oct 12, 2014 at 4:26 PM, Davide Pesavento wrote: > Well then maybe the first rule should be: read (and understand) the > license of the code you're touching/using. > > Best, > Davide > > > ---------- Forwarded message ---------- > > From: Jiewen Tan > > Date: Sat, Oct 11, 2014 at 11:53 PM > > > > Hi All, > > > > I am the owner. I do agree with Junxiao there should be a guideline, > > otherwise new people like me will be confused while importing codes. > > > > Regards, > > Jiewen Tan > > > > On Oct 11, 2014, at 11:09 PM, Junxiao Shi > > wrote: > > > > Dear folks > > > > There needs a guideline on how to write license boilerplate for code > > imported from NFD to ndn-cxx. > > The necessity of such a guideline is illustrated by > > http://gerrit.named-data.net/1254 where the Change Owner fails to produce a > > correct license boilerplate in 3 patchsets. > > > > Yours, Junxiao > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Oct 13 19:50:54 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 13 Oct 2014 19:50:54 -0700 Subject: [Nfd-dev] Using (some features of) C++11 In-Reply-To: References: Message-ID: Dear folks As shown in the survey , "we can use C++11". Can we enable C++11 now? Yours, Junxiao On Fri, Aug 22, 2014 at 11:09 PM, Junxiao Shi wrote: > Dear folks > > My opinion is: all C++11 features supported by all required platforms > should be permitted. > There is no reason to be conservative. > > It's also impractical to approve only certain features without enforcement > from Jenkins. > One example is that we have a limited set of approved Boost libraries > http://redmine.named-data.net/projects/nfd/wiki/Boost but this limitation > is never enforced. > > Yours, Junxiao > On Aug 22, 2014 1:28 PM, "Davide Pesavento" > wrote: > >> Hi guys, >> >> Can we start using some pieces of C++11 [1] in v0.3? >> >> Our oldest supported platform, Ubuntu 12.04, comes with gcc-4.6 that >> supports quite a few C++11 features already [2]. If we want to keep >> compatibility with even older Ubuntu LTS releases, 10.04 (EOL April >> 2015) comes with gcc-4.4, which still has a few interesting pieces of >> C++11 implemented [3], such as rvalue references, "auto" variables, >> initializer lists, and so on. >> >> Unless there's opposition to the idea of using C++11 at all, we should >> decide the minimum supported version of gcc/clang and come up with a >> set of C++11 features that we're allowed to use starting with v0.3 of >> ndn-cxx and NFD. >> >> Thanks, >> Davide >> >> [1] http://en.wikipedia.org/wiki/C%2B%2B11 >> [2] https://gcc.gnu.org/gcc-4.6/cxx0x_status.html >> [3] https://gcc.gnu.org/gcc-4.4/cxx0x_status.html >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Oct 14 04:04:23 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 14 Oct 2014 04:04:23 -0700 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: References: Message-ID: Dear folks Can we move forward on this update? I don't see any objection to the spec itself. Several features depend on this. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Wed Oct 15 07:35:17 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 15 Oct 2014 14:35:17 +0000 Subject: [Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component In-Reply-To: References: Message-ID: <2D8889CB-44A7-47CC-B38E-4D73884B68D3@memphis.edu> No objections to the spec. Lan On Oct 14, 2014, at 6:04 AM, Junxiao Shi > wrote: Dear folks Can we move forward on this update? I don't see any objection to the spec itself. Several features depend on this. Yours, Junxiao _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Wed Oct 15 08:15:02 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 15 Oct 2014 15:15:02 +0000 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: <98EBF759-A842-4D4C-8BEA-6FBCD0F9DF22@ucla.edu> References: <99C28F48-01A2-4ED7-88F4-AC7E3572220C@ucla.edu> <92AD88A8-DD61-41CA-B2BC-B3F7D4FF0FF9@gmail.com> <98EBF759-A842-4D4C-8BEA-6FBCD0F9DF22@ucla.edu> Message-ID: <4D54A6C8-9605-43E0-9CF2-271B3E32B163@memphis.edu> I think it's best for Jiewen to explain what specific problems (questions, confusion) he had when importing the code. If it's something that can be solved by "reading the license and license boilerplate", then there's no need for guidelines. Otherwise, guidelines will be helpful. Lan On Oct 12, 2014, at 7:22 PM, Alex Afanasyev > wrote: Junxiao, Please, don't make an issue from a non-issue. The license (and license boilerplate) is in itself instructions on how code can be used, re-used, and moved around. There is noting special that needs to be added. For the cases you're referring to. This is the point of code review, when you noticed that boilerplate is not the one we usually use / incorrect copyright/license attribute. There is no guidelines, rather you just need to tell what is the right way. That's it. Licenses are pretty simple to read (at least the boilerplate) and it is important for everybody to understand the limitations of the licenses. --- Alex On Oct 12, 2014, at 4:49 PM, Junxiao Shi > wrote: Hi Davide Developers are not lawyers. License is to be interpreted by a lawyer. Requiring consulting a lawyer every time importing NFD code is counter-productive. The guideline should be some mechanical steps that developers could easily follow. Note the scope of this discussion is specifically for importing code from NFD, and probably NLSR and repo-ng. I agree that importing code from an external project should involve consulting with a lawyer. Yours, Junxiao On Sun, Oct 12, 2014 at 4:26 PM, Davide Pesavento > wrote: Well then maybe the first rule should be: read (and understand) the license of the code you're touching/using. Best, Davide > ---------- Forwarded message ---------- > From: Jiewen Tan > > Date: Sat, Oct 11, 2014 at 11:53 PM > > Hi All, > > I am the owner. I do agree with Junxiao there should be a guideline, > otherwise new people like me will be confused while importing codes. > > Regards, > Jiewen Tan > > On Oct 11, 2014, at 11:09 PM, Junxiao Shi > > wrote: > > Dear folks > > There needs a guideline on how to write license boilerplate for code > imported from NFD to ndn-cxx. > The necessity of such a guideline is illustrated by > http://gerrit.named-data.net/1254 where the Change Owner fails to produce a > correct license boilerplate in 3 patchsets. > > Yours, Junxiao > _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Oct 15 18:45:17 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 15 Oct 2014 18:45:17 -0700 Subject: [Nfd-dev] ndn-cxx deprecated feature removal: Controller::start(parameter, onSuccess, onFailure, IdentityCertificate(), timeout) Message-ID: Dear folks The following deprecated function will be removed from ndn-cxx very soon: The function ndn::nfd::Controller::start(const ControlParameters& parameters, const CommandSucceedCallback& onSuccess, const CommandFailCallback& onFailure, const IdentityCertificate& certificate, const time::milliseconds& timeout) previously allows passing empty IdentityCertificate() as fourth parameter. This usage is deprecated before ndn-cxx v0.2.0 release. If you have code that depend on this feature, please reply no later than Oct 17 12:00 UTC. Otherwise, we'll proceed with the removal. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Thu Oct 16 10:54:37 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Thu, 16 Oct 2014 17:54:37 +0000 Subject: [Nfd-dev] Fwd: [NFD - Task #2010] RIB cost guidelines References: Message-ID: I don't have a good answer to this question. I suggest that we discuss this at the next nfd call. Lan Begin forwarded message: From: > Subject: [NFD - Task #2010] RIB cost guidelines Date: October 7, 2014 11:49:34 AM CDT To: Undisclosed recipients:; Issue #2010 has been updated by Junxiao Shi. Routes can come from several sources: * static route (manually configured by nfdc register) * intra-domain routing protocol * inter-domain routing protocol * local application * remote prefix registration (laptop registers a prefix on the access router toward the laptop) The costs from all those sources are not comparable, but forwarding is using an order derived from those costs. ________________________________ Task #2010: RIB cost guidelines * Author: Junxiao Shi * Status: New * Priority: Normal * Assignee: * Category: Docs * Target version: Provide guidelines for how routing protocols should assign RIB cost. Each routing protocol (including static) has its own way to assign costs. Costs from different routing protocols are not necessarily comparable. Forwarding does not interpret or use Cost assigned by routing protocol, but has access to an ordered list of nexthops in the FIB entry. This order is determined by the Costs of Routes, even if they could come from different routing protocols. This Task is to provide guidelines on how routing protocols should assign RIB cost, so that Costs from different routing protocols can be comparable. Some routing protocols may use non-integer costs; the guidelines should recommend how to convert such costs into integers. ________________________________ You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://redmine.named-data.net/my/account -------------- next part -------------- An HTML attachment was scrubbed... URL: From obaidasyed at gmail.com Thu Oct 16 12:05:41 2014 From: obaidasyed at gmail.com (Syed Obaid Amin) Date: Thu, 16 Oct 2014 14:05:41 -0500 Subject: [Nfd-dev] Fwd: [NFD - Task #2010] RIB cost guidelines In-Reply-To: References: Message-ID: The similar problem in IP is solved by Administrative Distance (AD), I think we can use the same approach here? Obaid On Thu, Oct 16, 2014 at 12:54 PM, Lan Wang (lanwang) wrote: > I don't have a good answer to this question. I suggest that we discuss > this at the next nfd call. > > Lan > > > Begin forwarded message: > > *From: * > *Subject: **[NFD - Task #2010] RIB cost guidelines* > *Date: *October 7, 2014 11:49:34 AM CDT > *To: *Undisclosed recipients:; > > Issue #2010 has been updated by Junxiao Shi. > > > Routes can come from several sources: > > - static route (manually configured by nfdc register) > - intra-domain routing protocol > - inter-domain routing protocol > - local application > - remote prefix registration (laptop registers a prefix on the access > router toward the laptop) > > The costs from all those sources are not comparable, but forwarding is > using an order derived from those costs. > ------------------------------ > Task #2010: RIB cost guidelines > > > - Author: Junxiao Shi > - Status: New > - Priority: Normal > - Assignee: > - Category: Docs > - Target version: > > Provide guidelines for how routing protocols should assign RIB cost. > > Each routing protocol (including static) has its own way to assign costs. > Costs from different routing protocols are not necessarily comparable. > Forwarding does not interpret or use Cost assigned by routing protocol, > but has access to an ordered list of nexthops in the FIB entry. This order > is determined by the Costs of Routes, even if they could come from > different routing protocols. > > This Task is to provide guidelines on how routing protocols should assign > RIB cost, so that Costs from different routing protocols can be comparable. > Some routing protocols may use non-integer costs; the guidelines should > recommend how to convert such costs into integers. > ------------------------------ > You have received this notification because you have either subscribed to > it, or are involved in it. To change your notification preferences, please > click here: http://redmine.named-data.net/my/account > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oran at cisco.com Thu Oct 16 12:20:10 2014 From: oran at cisco.com (Dave Oran (oran)) Date: Thu, 16 Oct 2014 19:20:10 +0000 Subject: [Nfd-dev] Fwd: [NFD - Task #2010] RIB cost guidelines In-Reply-To: References: Message-ID: On Oct 16, 2014, at 3:05 PM, Syed Obaid Amin wrote: > The similar problem in IP is solved by Administrative Distance (AD), I think we can use the same approach here? > ?Solved? is somewhat of an overstatement. Perhaps a gross overstatement. > Obaid > > On Thu, Oct 16, 2014 at 12:54 PM, Lan Wang (lanwang) wrote: > I don't have a good answer to this question. I suggest that we discuss this at the next nfd call. > > Lan > > > Begin forwarded message: > >> From: >> Subject: [NFD - Task #2010] RIB cost guidelines >> Date: October 7, 2014 11:49:34 AM CDT >> To: Undisclosed recipients:; >> >> Issue #2010 has been updated by Junxiao Shi. >> Routes can come from several sources: >> >> ? static route (manually configured by nfdc register) >> ? intra-domain routing protocol >> ? inter-domain routing protocol >> ? local application >> ? remote prefix registration (laptop registers a prefix on the access router toward the laptop) >> The costs from all those sources are not comparable, but forwarding is using an order derived from those costs. >> >> Task #2010: RIB cost guidelines >> ? Author: Junxiao Shi >> ? Status: New >> ? Priority: Normal >> ? Assignee: >> ? Category: Docs >> ? Target version: >> Provide guidelines for how routing protocols should assign RIB cost. >> >> Each routing protocol (including static) has its own way to assign costs. Costs from different routing protocols are not necessarily comparable. >> Forwarding does not interpret or use Cost assigned by routing protocol, but has access to an ordered list of nexthops in the FIB entry. This order is determined by the Costs of Routes, even if they could come from different routing protocols. >> >> This Task is to provide guidelines on how routing protocols should assign RIB cost, so that Costs from different routing protocols can be comparable. >> Some routing protocols may use non-integer costs; the guidelines should recommend how to convert such costs into integers. >> >> You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://redmine.named-data.net/my/account > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From lanwang at memphis.edu Thu Oct 16 14:32:26 2014 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Thu, 16 Oct 2014 21:32:26 +0000 Subject: [Nfd-dev] [NFD - Task #2010] RIB cost guidelines In-Reply-To: References: Message-ID: <47C5D48E-1781-4800-9C4A-374F4B99EABA@memphis.edu> On Oct 16, 2014, at 2:20 PM, Dave Oran (oran) wrote: > > On Oct 16, 2014, at 3:05 PM, Syed Obaid Amin wrote: > >> The similar problem in IP is solved by Administrative Distance (AD), I think we can use the same approach here? >> > ?Solved? is somewhat of an overstatement. Perhaps a gross overstatement. What problems does AD have in your experience? Lan > >> Obaid >> >> On Thu, Oct 16, 2014 at 12:54 PM, Lan Wang (lanwang) wrote: >> I don't have a good answer to this question. I suggest that we discuss this at the next nfd call. >> >> Lan >> >> >> Begin forwarded message: >> >>> From: >>> Subject: [NFD - Task #2010] RIB cost guidelines >>> Date: October 7, 2014 11:49:34 AM CDT >>> To: Undisclosed recipients:; >>> >>> Issue #2010 has been updated by Junxiao Shi. >>> Routes can come from several sources: >>> >>> ? static route (manually configured by nfdc register) >>> ? intra-domain routing protocol >>> ? inter-domain routing protocol >>> ? local application >>> ? remote prefix registration (laptop registers a prefix on the access router toward the laptop) >>> The costs from all those sources are not comparable, but forwarding is using an order derived from those costs. >>> >>> Task #2010: RIB cost guidelines >>> ? Author: Junxiao Shi >>> ? Status: New >>> ? Priority: Normal >>> ? Assignee: >>> ? Category: Docs >>> ? Target version: >>> Provide guidelines for how routing protocols should assign RIB cost. >>> >>> Each routing protocol (including static) has its own way to assign costs. Costs from different routing protocols are not necessarily comparable. >>> Forwarding does not interpret or use Cost assigned by routing protocol, but has access to an ordered list of nexthops in the FIB entry. This order is determined by the Costs of Routes, even if they could come from different routing protocols. >>> >>> This Task is to provide guidelines on how routing protocols should assign RIB cost, so that Costs from different routing protocols can be comparable. >>> Some routing protocols may use non-integer costs; the guidelines should recommend how to convert such costs into integers. >>> >>> You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://redmine.named-data.net/my/account >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From oran at cisco.com Thu Oct 16 16:43:20 2014 From: oran at cisco.com (Dave Oran (oran)) Date: Thu, 16 Oct 2014 23:43:20 +0000 Subject: [Nfd-dev] [NFD - Task #2010] RIB cost guidelines In-Reply-To: <47C5D48E-1781-4800-9C4A-374F4B99EABA@memphis.edu> References: <47C5D48E-1781-4800-9C4A-374F4B99EABA@memphis.edu> Message-ID: On Oct 16, 2014, at 5:32 PM, Lan Wang (lanwang) wrote: > > > On Oct 16, 2014, at 2:20 PM, Dave Oran (oran) wrote: > >> >> On Oct 16, 2014, at 3:05 PM, Syed Obaid Amin wrote: >> >>> The similar problem in IP is solved by Administrative Distance (AD), I think we can use the same approach here? >>> >> ?Solved? is somewhat of an overstatement. Perhaps a gross overstatement. > > What problems does AD have in your experience? > 1) It?s too coarse 2) It doesn?t help with traffic engineering 3) It interacts in strange ways with LocalPref and MultiExitDisc in BGP Basically, it?s a minimal mechanism that people can use when they don?t really care to ?solve? the route optimization and selection problem. I wasn?t claiming it didn?t ?work? in the sense it caused loops or led to route oscillation. I claim is doesn?t ?solve? any of the important global route optimization and selection issues we care about. NDN is an opportunity to rethink a lot of these questions in interconnecting routing at boundaries, because it does not need to be beholden to choices that were made 25 years ago with different technical, political, and economic tradeoffs. For example, given the amount of state leakage NDN requires via stateful forwarding, does it still make sense to try to hide path characteristics across peering boundaries the way BGP does? Given the extra computing we have to do anyway for hierarchical name-based forwarding, is it now such big deal compared to the rest of the overhead to do metric mapping and rescaling at boundaries, especially if we can learn from feedback provided in forwarding? Are our loop detection and suppression capabilities in NDN forwarding good enough that we can relax the total ordering that falls out of giving precedence to administrative distances? Can we generalize at least somewhat from admin distance to ?admin boundary cost increment?. I?m not necessarily advocating any or all of these ideas above, only encouraging us to not say ?admin distance worked for IP, therefore we can treat this as a 'solved problem' and stop thinking?. DaveO. > Lan >> >>> Obaid >>> >>> On Thu, Oct 16, 2014 at 12:54 PM, Lan Wang (lanwang) wrote: >>> I don't have a good answer to this question. I suggest that we discuss this at the next nfd call. >>> >>> Lan >>> >>> >>> Begin forwarded message: >>> >>>> From: >>>> Subject: [NFD - Task #2010] RIB cost guidelines >>>> Date: October 7, 2014 11:49:34 AM CDT >>>> To: Undisclosed recipients:; >>>> >>>> Issue #2010 has been updated by Junxiao Shi. >>>> Routes can come from several sources: >>>> >>>> ? static route (manually configured by nfdc register) >>>> ? intra-domain routing protocol >>>> ? inter-domain routing protocol >>>> ? local application >>>> ? remote prefix registration (laptop registers a prefix on the access router toward the laptop) >>>> The costs from all those sources are not comparable, but forwarding is using an order derived from those costs. >>>> >>>> Task #2010: RIB cost guidelines >>>> ? Author: Junxiao Shi >>>> ? Status: New >>>> ? Priority: Normal >>>> ? Assignee: >>>> ? Category: Docs >>>> ? Target version: >>>> Provide guidelines for how routing protocols should assign RIB cost. >>>> >>>> Each routing protocol (including static) has its own way to assign costs. Costs from different routing protocols are not necessarily comparable. >>>> Forwarding does not interpret or use Cost assigned by routing protocol, but has access to an ordered list of nexthops in the FIB entry. This order is determined by the Costs of Routes, even if they could come from different routing protocols. >>>> >>>> This Task is to provide guidelines on how routing protocols should assign RIB cost, so that Costs from different routing protocols can be comparable. >>>> Some routing protocols may use non-integer costs; the guidelines should recommend how to convert such costs into integers. >>>> >>>> You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://redmine.named-data.net/my/account >>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> > From davide.pesavento at lip6.fr Sun Oct 19 07:59:25 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Sun, 19 Oct 2014 16:59:25 +0200 Subject: [Nfd-dev] Using (some features of) C++11 In-Reply-To: References: Message-ID: I've been thinking about this for a while but I haven't found a good solution for the (potential) ABI incompatibilities yet [1]. It might even be a non-issue for us, but unfortunately there's no easy way to check. Would it be too unreasonable to build two variants of ndn-cxx, one using C++98 and one using C++11? [1] Assuming NFD will be compiled exclusively in C++11 mode, while ndn-cxx stays compatible with both C++11 and C++98. Best, Davide On Tue, Oct 14, 2014 at 4:50 AM, Junxiao Shi wrote: > Dear folks > > As shown in the survey, "we can use C++11". > Can we enable C++11 now? > > Yours, Junxiao > > On Fri, Aug 22, 2014 at 11:09 PM, Junxiao Shi > wrote: >> >> Dear folks >> >> My opinion is: all C++11 features supported by all required platforms >> should be permitted. >> There is no reason to be conservative. >> >> It's also impractical to approve only certain features without enforcement >> from Jenkins. >> One example is that we have a limited set of approved Boost libraries >> http://redmine.named-data.net/projects/nfd/wiki/Boost but this limitation is >> never enforced. >> >> Yours, Junxiao >> >> On Aug 22, 2014 1:28 PM, "Davide Pesavento" >> wrote: >>> >>> Hi guys, >>> >>> Can we start using some pieces of C++11 [1] in v0.3? >>> >>> Our oldest supported platform, Ubuntu 12.04, comes with gcc-4.6 that >>> supports quite a few C++11 features already [2]. If we want to keep >>> compatibility with even older Ubuntu LTS releases, 10.04 (EOL April >>> 2015) comes with gcc-4.4, which still has a few interesting pieces of >>> C++11 implemented [3], such as rvalue references, "auto" variables, >>> initializer lists, and so on. >>> >>> Unless there's opposition to the idea of using C++11 at all, we should >>> decide the minimum supported version of gcc/clang and come up with a >>> set of C++11 features that we're allowed to use starting with v0.3 of >>> ndn-cxx and NFD. >>> >>> Thanks, >>> Davide >>> >>> [1] http://en.wikipedia.org/wiki/C%2B%2B11 >>> [2] https://gcc.gnu.org/gcc-4.6/cxx0x_status.html >>> [3] https://gcc.gnu.org/gcc-4.4/cxx0x_status.html > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From shijunxiao at email.arizona.edu Sun Oct 19 08:28:11 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 19 Oct 2014 08:28:11 -0700 Subject: [Nfd-dev] Using (some features of) C++11 In-Reply-To: References: Message-ID: Hi Davide I would say: ndn-cxx, NFD, and all other projects depending on ndn-cxx should be compiled exclusively in C++11 mode. We have never used C++98 mode. Currently we are using C++03 mode. It's unnecessary for ndn-cxx to keep C++03 compatibility, for the following reasons: - ndn-cxx and projects depending on it are almost useless without NFD running on the same machine. - "almost": ndn-cxx's Face needs NFD. Few applications don't use Face: tlvdump is an example. - When NFD is running on the same machine, the platform must have a C++11 compiler, so ndn-cxx and other projects can be compiled in C++11 mode. - Performance benefits of C++11 (mainly from move constructor) are severely limited when ndn-cxx wants to keep C++03 compatibility. Yours, Junxiao On Sun, Oct 19, 2014 at 7:59 AM, Davide Pesavento wrote: > I've been thinking about this for a while but I haven't found a good > solution for the (potential) ABI incompatibilities yet [1]. It might > even be a non-issue for us, but unfortunately there's no easy way to > check. > > Would it be too unreasonable to build two variants of ndn-cxx, one > using C++98 and one using C++11? > > [1] Assuming NFD will be compiled exclusively in C++11 mode, while > ndn-cxx stays compatible with both C++11 and C++98. > > Best, > Davide > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.pesavento at lip6.fr Sun Oct 19 08:45:34 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Sun, 19 Oct 2014 17:45:34 +0200 Subject: [Nfd-dev] Using (some features of) C++11 In-Reply-To: References: Message-ID: On Sun, Oct 19, 2014 at 5:28 PM, Junxiao Shi wrote: > Hi Davide > > I would say: ndn-cxx, NFD, and all other projects depending on ndn-cxx > should be compiled exclusively in C++11 mode. > We have never used C++98 mode. Currently we are using C++03 mode. C++98 and C++03 are the same thing. > > It's unnecessary for ndn-cxx to keep C++03 compatibility, for the following > reasons: > > ndn-cxx and projects depending on it are almost useless without NFD running > on the same machine. > > "almost": ndn-cxx's Face needs NFD. Few applications don't use Face: tlvdump > is an example. > > When NFD is running on the same machine, the platform must have a C++11 > compiler, so ndn-cxx and other projects can be compiled in C++11 mode. > Performance benefits of C++11 (mainly from move constructor) are severely > limited when ndn-cxx wants to keep C++03 compatibility. > Personally, I agree. However I believe we were concerned about third-party applications compiling and linking against ndn-cxx, and that we didn't want to force C++11 onto them. > > Yours, Junxiao > > On Sun, Oct 19, 2014 at 7:59 AM, Davide Pesavento > wrote: >> >> I've been thinking about this for a while but I haven't found a good >> solution for the (potential) ABI incompatibilities yet [1]. It might >> even be a non-issue for us, but unfortunately there's no easy way to >> check. >> >> Would it be too unreasonable to build two variants of ndn-cxx, one >> using C++98 and one using C++11? >> >> [1] Assuming NFD will be compiled exclusively in C++11 mode, while >> ndn-cxx stays compatible with both C++11 and C++98. >> >> Best, >> Davide > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From shijunxiao at email.arizona.edu Sun Oct 19 08:50:51 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 19 Oct 2014 08:50:51 -0700 Subject: [Nfd-dev] Using (some features of) C++11 In-Reply-To: References: Message-ID: Hi Davide C++03 code can be compiled with C++11 compiler. Forcing dependent projects to use C++11 only requires them to change Makefile or wscript, which is trivial; there's no code change needed. There's major performance benefit to make ndn-cxx compile in C++11 exclusively. The benefit mainly comes from move constructors, either used directly or used indirectly from STL. Yours, Junxiao On Sun, Oct 19, 2014 at 8:45 AM, Davide Pesavento wrote: > On Sun, Oct 19, 2014 at 5:28 PM, Junxiao Shi > wrote: > > Hi Davide > > > > I would say: ndn-cxx, NFD, and all other projects depending on ndn-cxx > > should be compiled exclusively in C++11 mode. > > We have never used C++98 mode. Currently we are using C++03 mode. > > C++98 and C++03 are the same thing. > > > > > It's unnecessary for ndn-cxx to keep C++03 compatibility, for the > following > > reasons: > > > > ndn-cxx and projects depending on it are almost useless without NFD > running > > on the same machine. > > > > "almost": ndn-cxx's Face needs NFD. Few applications don't use Face: > tlvdump > > is an example. > > > > When NFD is running on the same machine, the platform must have a C++11 > > compiler, so ndn-cxx and other projects can be compiled in C++11 mode. > > Performance benefits of C++11 (mainly from move constructor) are severely > > limited when ndn-cxx wants to keep C++03 compatibility. > > > > Personally, I agree. However I believe we were concerned about > third-party applications compiling and linking against ndn-cxx, and > that we didn't want to force C++11 onto them. > > > > > Yours, Junxiao > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.pesavento at lip6.fr Sun Oct 19 09:30:24 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Sun, 19 Oct 2014 18:30:24 +0200 Subject: [Nfd-dev] Using (some features of) C++11 In-Reply-To: References: Message-ID: It's not true in general that C++03 code can be compiled with a C++11 compiler. C++11 introduces some changes that may break code that used to be valid in C++03, see [1] for some examples. Admittedly, most of them are corner cases or are trivially fixable. Again, I agree with moving completely to C++11, and given that this project is quite young, there shouldn't be much legacy code around anyway. So should we just ignore C++98/03 compatibility? I'd like to have some consensus before moving forward on this. [1] http://stackoverflow.com/questions/6399615/what-breaking-changes-are-introduced-in-c11 Thanks, Davide On Sun, Oct 19, 2014 at 5:50 PM, Junxiao Shi wrote: > Hi Davide > > C++03 code can be compiled with C++11 compiler. Forcing dependent projects > to use C++11 only requires them to change Makefile or wscript, which is > trivial; there's no code change needed. > > There's major performance benefit to make ndn-cxx compile in C++11 > exclusively. The benefit mainly comes from move constructors, either used > directly or used indirectly from STL. > > Yours, Junxiao > > On Sun, Oct 19, 2014 at 8:45 AM, Davide Pesavento > wrote: >> >> On Sun, Oct 19, 2014 at 5:28 PM, Junxiao Shi >> wrote: >> > Hi Davide >> > >> > I would say: ndn-cxx, NFD, and all other projects depending on ndn-cxx >> > should be compiled exclusively in C++11 mode. >> > We have never used C++98 mode. Currently we are using C++03 mode. >> >> C++98 and C++03 are the same thing. >> >> > >> > It's unnecessary for ndn-cxx to keep C++03 compatibility, for the >> > following >> > reasons: >> > >> > ndn-cxx and projects depending on it are almost useless without NFD >> > running >> > on the same machine. >> > >> > "almost": ndn-cxx's Face needs NFD. Few applications don't use Face: >> > tlvdump >> > is an example. >> > >> > When NFD is running on the same machine, the platform must have a C++11 >> > compiler, so ndn-cxx and other projects can be compiled in C++11 mode. >> > Performance benefits of C++11 (mainly from move constructor) are >> > severely >> > limited when ndn-cxx wants to keep C++03 compatibility. >> > >> >> Personally, I agree. However I believe we were concerned about >> third-party applications compiling and linking against ndn-cxx, and >> that we didn't want to force C++11 onto them. >> >> > >> > Yours, Junxiao > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From shijunxiao at email.arizona.edu Sun Oct 19 09:57:31 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 19 Oct 2014 09:57:31 -0700 Subject: [Nfd-dev] ndn-cxx deprecated feature removal: namespace ndn::Tlv Message-ID: Dear folks The following deprecated function will be removed from ndn-cxx soon: - namespace ndn::Tlv (namespace ndn::tlv should be used instead) This usage is deprecated before ndn-cxx v0.2.0 release. If you have code that depend on this feature, please reply no later than Oct 24 12:00 UTC. Otherwise, we'll proceed with the removal. I've verified that the following projects are unaffected: ndn-tlv-ping, ndn-traffic-generator. I've made changes to the following projects: NFD, NLSR, repo-ng, ndndump. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From haroonr at iiitd.ac.in Mon Oct 20 00:17:05 2014 From: haroonr at iiitd.ac.in (Haroon Rashid) Date: Mon, 20 Oct 2014 12:47:05 +0530 Subject: [Nfd-dev] ndd-cxx vs. ndn-cpp and consumer producer example Message-ID: Hi everyone, >From past one week, I am trying to learn NDN application development using NFD. I have certain queries and I am facing some problems in the same as: With NFD, should I use ndn-cxx or ndn-cpp for application development? I am not getting the clear difference between ndn-cxx and ndn-cpp. Can anyone explain me when should I use ndn-cxx over ndn-cpp or use ndn-cpp over ndn- cxx? I am facing a problem with ndn-cxx while running consumer-producer example. Whenever I type on terminal ./build/examples/producer I get the following output -- ERRBOR: SecPublicInfoSqlite3::getCertificate certificate does not exist What should I do to get rid of this error? Another experiment I am trying is to run producer consumer example on two machines by running consumer on machine/laptop A and producer on machine B. Both of these laptops are connected on LAN. On both of the laptops(A and B) NFD is installed and is running. I am using following steps to run the above example: Step1: ____________________________________________________________________________ on A: nfdc register /ndn udp://192.168.32.11(ip address of B) on B: nfdc register /ndn udp://192.168.32.15(ip address of A) _____________________________________________________________________________ Step2: _______________________________________________________________ In consumer.cpp, I changed following lines setscope changed to 2 interest name changed to "/ndn/example/testApp/..." In producer.cpp, following line changed interestFilter changed to "/ndn/example/..." ______________________________________________________________ step3: ________________________________________________________________ 1. compiled both consumer.cpp and producer.cpp successfully on repective laptops 2. Run producer with ./build/examples/producer on machine A and run consumer with ./build/examples/consumer on machine B. with the run of consumer on B, after sometime it shows TimeOut. I am not getting why it is showing Timeout since everything is configured correctly. Can anyone help me to find out the issue with this example? Thanking you -- Haroon Rashid -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at UCLA.EDU Mon Oct 20 07:12:15 2014 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Mon, 20 Oct 2014 10:12:15 -0400 Subject: [Nfd-dev] ndd-cxx vs. ndn-cpp and consumer producer example In-Reply-To: References: Message-ID: <18B84F04-A4DC-405E-BFED-14EDCCA49F3A@ucla.edu> Hi Haroon, On Oct 20, 2014, at 3:17 AM, Haroon Rashid wrote: > Hi everyone, > > From past one week, I am trying to learn NDN application development using NFD. I have certain queries and I am facing some problems in the same as: > > With NFD, should I use ndn-cxx or ndn-cpp for application development? I am not getting the clear difference between ndn-cxx and ndn-cpp. Can anyone explain me when should I use ndn-cxx over ndn-cpp or use ndn-cpp over ndn-cxx? You can use either, both should work. > I am facing a problem with ndn-cxx while running consumer-producer example. Whenever I type on terminal ./build/examples/producer I get the following output > -- ERRBOR: SecPublicInfoSqlite3::getCertificate certificate does not exist > > What should I do to get rid of this error? The error simply saying that you have not properly configured security credentials on your machine. For now, you can create a self-signed certificate: ndnsec-keygen /somename | ndnsec-install-cert - However, it is strange that you're getting this error. You should have had generated a temporary self-signed identity automatically... For more info about the security library, refer to http://named-data.net/doc/ndn-cxx/current/tutorials/security-library.html > Another experiment I am trying is to run producer consumer example on two machines by running consumer on machine/laptop A and producer on machine B. Both of these laptops are connected on LAN. > On both of the laptops(A and B) NFD is installed and is running. I am using following steps to run the above example: > > Step1: > ____________________________________________________________________________ > on A: nfdc register /ndn udp://192.168.32.11(ip address of B) > on B: nfdc register /ndn udp://192.168.32.15(ip address of A) > _____________________________________________________________________________ > > Step2: > _______________________________________________________________ > In consumer.cpp, I changed following lines > setscope changed to 2 > interest name changed to "/ndn/example/testApp/..." > > In producer.cpp, following line changed > interestFilter changed to "/ndn/example/..." > ______________________________________________________________ > step3: > ________________________________________________________________ > 1. compiled both consumer.cpp and producer.cpp successfully on repective laptops > 2. Run producer with ./build/examples/producer on machine A and run consumer with ./build/examples/consumer on machine B. > with the run of consumer on B, after sometime it shows TimeOut. > I am not getting why it is showing Timeout since everything is configured correctly. Can anyone help me to find out the issue with this example? You don't need to register prefix on producer node, only on client. But this shouldn't be a problem and the changes you made look correct. Check your firewall settings, may be it is blocking all the outgoing or incoming NDN packets. --- Alex > Thanking you > > -- > Haroon Rashid > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Oct 20 09:27:55 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 20 Oct 2014 09:27:55 -0700 Subject: [Nfd-dev] ndd-cxx vs. ndn-cpp and consumer producer example In-Reply-To: References: Message-ID: Hi Haroon This error is caused by ndn-cxx Bug 2080 < http://redmine.named-data.net/issues/2080>. Please watch the issue to know its progress. Yours, Junxiao On Mon, Oct 20, 2014 at 12:17 AM, Haroon Rashid wrote: > I am facing a problem with ndn-cxx while running consumer-producer > example. Whenever I type on terminal ./build/examples/producer I get the > following output > -- ERRBOR: SecPublicInfoSqlite3::getCertificate certificate does not > exist > > What should I do to get rid of this error? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Oct 20 14:48:13 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 20 Oct 2014 14:48:13 -0700 Subject: [Nfd-dev] Using (some features of) C++11 In-Reply-To: References: Message-ID: Hi Davide ndn-cxx's shift to C++11 is approved at 20141020 conference call. Please go ahead and make the changes according to the procedures given in http://redmine.named-data.net/issues/1930#note-5 Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanwake at UCLA.EDU Mon Oct 20 19:26:23 2014 From: alanwake at UCLA.EDU (Jiewen Tan) Date: Mon, 20 Oct 2014 19:26:23 -0700 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: <4D54A6C8-9605-43E0-9CF2-271B3E32B163@memphis.edu> References: <99C28F48-01A2-4ED7-88F4-AC7E3572220C@ucla.edu> <92AD88A8-DD61-41CA-B2BC-B3F7D4FF0FF9@gmail.com> <98EBF759-A842-4D4C-8BEA-6FBCD0F9DF22@ucla.edu> <4D54A6C8-9605-43E0-9CF2-271B3E32B163@memphis.edu> Message-ID: <022301cfecd6$694611f0$3bd235d0$@ucla.edu> Hi All, My confusion is what should be done to the license declaration part of the code. For example, if I copy code from NFD to ndn-cxx, what kind of information I should add to the license declaration part of the file containing the code I just copied. Regards, Jiewen Tan From: Lan Wang (lanwang) [mailto:lanwang at memphis.edu] Sent: Wednesday, October 15, 2014 8:15 AM To: Alex Afanasyev Cc: Junxiao Shi; ; alanwake at ucla.edu Subject: Re: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx I think it's best for Jiewen to explain what specific problems (questions, confusion) he had when importing the code. If it's something that can be solved by "reading the license and license boilerplate", then there's no need for guidelines. Otherwise, guidelines will be helpful. Lan On Oct 12, 2014, at 7:22 PM, Alex Afanasyev wrote: Junxiao, Please, don't make an issue from a non-issue. The license (and license boilerplate) is in itself instructions on how code can be used, re-used, and moved around. There is noting special that needs to be added. For the cases you're referring to. This is the point of code review, when you noticed that boilerplate is not the one we usually use / incorrect copyright/license attribute. There is no guidelines, rather you just need to tell what is the right way. That's it. Licenses are pretty simple to read (at least the boilerplate) and it is important for everybody to understand the limitations of the licenses. --- Alex On Oct 12, 2014, at 4:49 PM, Junxiao Shi wrote: Hi Davide Developers are not lawyers. License is to be interpreted by a lawyer. Requiring consulting a lawyer every time importing NFD code is counter-productive. The guideline should be some mechanical steps that developers could easily follow. Note the scope of this discussion is specifically for importing code from NFD, and probably NLSR and repo-ng. I agree that importing code from an external project should involve consulting with a lawyer. Yours, Junxiao On Sun, Oct 12, 2014 at 4:26 PM, Davide Pesavento wrote: Well then maybe the first rule should be: read (and understand) the license of the code you're touching/using. Best, Davide > ---------- Forwarded message ---------- > From: Jiewen Tan > Date: Sat, Oct 11, 2014 at 11:53 PM > > Hi All, > > I am the owner. I do agree with Junxiao there should be a guideline, > otherwise new people like me will be confused while importing codes. > > Regards, > Jiewen Tan > > On Oct 11, 2014, at 11:09 PM, Junxiao Shi > wrote: > > Dear folks > > There needs a guideline on how to write license boilerplate for code > imported from NFD to ndn-cxx. > The necessity of such a guideline is illustrated by > http://gerrit.named-data.net/1254 where the Change Owner fails to produce a > correct license boilerplate in 3 patchsets. > > Yours, Junxiao > _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at UCLA.EDU Mon Oct 20 20:16:07 2014 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Mon, 20 Oct 2014 23:16:07 -0400 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: <022301cfecd6$694611f0$3bd235d0$@ucla.edu> References: <99C28F48-01A2-4ED7-88F4-AC7E3572220C@ucla.edu> <92AD88A8-DD61-41CA-B2BC-B3F7D4FF0FF9@gmail.com> <98EBF759-A842-4D4C-8BEA-6FBCD0F9DF22@ucla.edu> <4D54A6C8-9605-43E0-9CF2-271B3E32B163@memphis.edu> <022301cfecd6$694611f0$3bd235d0$@ucla.edu> Message-ID: <5F89EF20-7355-4705-8946-E7F2816820A0@ucla.edu> You should always read the license / contact the original copyright holders whenever you're borrowing any code. For some popular licenses, such as GPL/LPGL, there are a numerous explanations on the Internet describing how properly use that code in the project. In this specific case, we were re-licensing the code and we finally recommended you a correct boilerplate. --- Alex On Oct 20, 2014, at 10:26 PM, Jiewen Tan wrote: > Hi All, > > My confusion is what should be done to the license declaration part of the code. For example, if I copy code from NFD to ndn-cxx, what kind of information I should add to the license declaration part of the file containing the code I just copied. > > Regards, > Jiewen Tan > > > From: Lan Wang (lanwang) [mailto:lanwang at memphis.edu] > Sent: Wednesday, October 15, 2014 8:15 AM > To: Alex Afanasyev > Cc: Junxiao Shi; ; alanwake at ucla.edu > Subject: Re: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx > > I think it's best for Jiewen to explain what specific problems (questions, confusion) he had when importing the code. If it's something that can be solved by "reading the license and license boilerplate", then there's no need for guidelines. Otherwise, guidelines will be helpful. > > Lan > > > On Oct 12, 2014, at 7:22 PM, Alex Afanasyev wrote: > > > Junxiao, > > Please, don't make an issue from a non-issue. The license (and license boilerplate) is in itself instructions on how code can be used, re-used, and moved around. There is noting special that needs to be added. > > For the cases you're referring to. This is the point of code review, when you noticed that boilerplate is not the one we usually use / incorrect copyright/license attribute. There is no guidelines, rather you just need to tell what is the right way. That's it. > > Licenses are pretty simple to read (at least the boilerplate) and it is important for everybody to understand the limitations of the licenses. > > --- > Alex > > On Oct 12, 2014, at 4:49 PM, Junxiao Shi wrote: > > > Hi Davide > > Developers are not lawyers. License is to be interpreted by a lawyer. Requiring consulting a lawyer every time importing NFD code is counter-productive. > The guideline should be some mechanical steps that developers could easily follow. > > Note the scope of this discussion is specifically for importing code from NFD, and probably NLSR and repo-ng. > I agree that importing code from an external project should involve consulting with a lawyer. > > Yours, Junxiao > > On Sun, Oct 12, 2014 at 4:26 PM, Davide Pesavento wrote: > Well then maybe the first rule should be: read (and understand) the > license of the code you're touching/using. > > Best, > Davide > > > ---------- Forwarded message ---------- > > From: Jiewen Tan > > Date: Sat, Oct 11, 2014 at 11:53 PM > > > > Hi All, > > > > I am the owner. I do agree with Junxiao there should be a guideline, > > otherwise new people like me will be confused while importing codes. > > > > Regards, > > Jiewen Tan > > > > On Oct 11, 2014, at 11:09 PM, Junxiao Shi > > wrote: > > > > Dear folks > > > > There needs a guideline on how to write license boilerplate for code > > imported from NFD to ndn-cxx. > > The necessity of such a guideline is illustrated by > > http://gerrit.named-data.net/1254 where the Change Owner fails to produce a > > correct license boilerplate in 3 patchsets. > > > > Yours, Junxiao > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From haroonr at iiitd.ac.in Mon Oct 20 21:39:26 2014 From: haroonr at iiitd.ac.in (Haroon Rashid) Date: Tue, 21 Oct 2014 10:09:26 +0530 Subject: [Nfd-dev] ndd-cxx vs. ndn-cpp and consumer producer example In-Reply-To: References: Message-ID: Thanks Alex and Junxaio, I installed a new copy from Git. It is working fine now. All issues got solved with this new copy. On Mon, Oct 20, 2014 at 9:57 PM, Junxiao Shi wrote: > Hi Haroon > > This error is caused by ndn-cxx Bug 2080 < > http://redmine.named-data.net/issues/2080>. > Please watch the issue to know its progress. > > Yours, Junxiao > > On Mon, Oct 20, 2014 at 12:17 AM, Haroon Rashid > wrote: > >> I am facing a problem with ndn-cxx while running consumer-producer >> example. Whenever I type on terminal ./build/examples/producer I get the >> following output >> -- ERRBOR: SecPublicInfoSqlite3::getCertificate certificate does not >> exist >> >> What should I do to get rid of this error? >> >> -- Haroon Rashid -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Oct 20 22:32:36 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 20 Oct 2014 22:32:36 -0700 Subject: [Nfd-dev] License boilerplate for code imported from NFD to ndn-cxx In-Reply-To: <5F89EF20-7355-4705-8946-E7F2816820A0@ucla.edu> References: <99C28F48-01A2-4ED7-88F4-AC7E3572220C@ucla.edu> <92AD88A8-DD61-41CA-B2BC-B3F7D4FF0FF9@gmail.com> <98EBF759-A842-4D4C-8BEA-6FBCD0F9DF22@ucla.edu> <4D54A6C8-9605-43E0-9CF2-271B3E32B163@memphis.edu> <022301cfecd6$694611f0$3bd235d0$@ucla.edu> <5F89EF20-7355-4705-8946-E7F2816820A0@ucla.edu> Message-ID: Dear folks I suggest putting the following onto a wiki page: 1. a sample email template to be used when contacting the authors in order to borrow code from NFD to ndn-cxx 2. the correct boilerplate to be used on code imported from NFD to ndn-cxx Yours, Junxiao On Mon, Oct 20, 2014 at 8:16 PM, Alex Afanasyev < alexander.afanasyev at ucla.edu> wrote: > You should always read the license / contact the original copyright > holders whenever you're borrowing any code. For some popular licenses, > such as GPL/LPGL, there are a numerous explanations on the Internet > describing how properly use that code in the project. > > In this specific case, we were re-licensing the code and we finally > recommended you a correct boilerplate. > > --- > Alex > > On Oct 20, 2014, at 10:26 PM, Jiewen Tan wrote: > > Hi All, > > My confusion is what should be done to the license declaration part of the > code. For example, if I copy code from NFD to ndn-cxx, what kind of > information I should add to the license declaration part of the file > containing the code I just copied. > > Regards, > Jiewen Tan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Oct 21 08:40:45 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 21 Oct 2014 08:40:45 -0700 Subject: [Nfd-dev] ndncatchunks3 and ndnputchunks Message-ID: Dear folks I notice that ndn-cxx has two programs, ndncatchunks3 and ndnputchunks3, in tools directory, but they don't have manpages. I wonder what's the purpose and feature of these two tools? Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at UCLA.EDU Tue Oct 21 12:58:16 2014 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Tue, 21 Oct 2014 15:58:16 -0400 Subject: [Nfd-dev] ndncatchunks3 and ndnputchunks In-Reply-To: References: Message-ID: <46ED2352-527F-4E19-A04D-A935B80D16C1@ucla.edu> They originally meant to be simple debug tools / examples. They probably can be removed or demoted to examples category (and moved to examples/ folder). --- Alex On Oct 21, 2014, at 11:40 AM, Junxiao Shi wrote: > Dear folks > > I notice that ndn-cxx has two programs, ndncatchunks3 and ndnputchunks3, in tools directory, but they don't have manpages. > I wonder what's the purpose and feature of these two tools? > > Yours, Junxiao > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From iliamo at CS.UCLA.EDU Tue Oct 21 11:43:56 2014 From: iliamo at CS.UCLA.EDU (Ilya Moiseenko) Date: Tue, 21 Oct 2014 11:43:56 -0700 Subject: [Nfd-dev] ndncatchunks3 and ndnputchunks In-Reply-To: References: Message-ID: <5CFF62C9-5783-48C4-A877-1C44813DC766@cs.ucla.edu> Dear Junxiao, Not everything in the world has a manual or guidelines attached to it. And most people are totally fine with it. People are not robots and don?t need a precise instruction set in order to operate on daily basis. These 2 apps are quite short and I believe that such a wonderful programmer like you can figure them out in a moment (if you really have to). Yours, Ilya On Oct 21, 2014, at 8:40 AM, Junxiao Shi wrote: > Dear folks > > I notice that ndn-cxx has two programs, ndncatchunks3 and ndnputchunks3, in tools directory, but they don't have manpages. > I wonder what's the purpose and feature of these two tools? > > Yours, Junxiao > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From shijunxiao at email.arizona.edu Tue Oct 21 20:39:18 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 21 Oct 2014 20:39:18 -0700 Subject: [Nfd-dev] ndncatchunks3 and ndnputchunks In-Reply-To: <46ED2352-527F-4E19-A04D-A935B80D16C1@ucla.edu> References: <46ED2352-527F-4E19-A04D-A935B80D16C1@ucla.edu> Message-ID: Hi Alex I think they shall be deleted. ndncatchunks3 fetches segments continuously until there's a timeout, then claims it's done. It doesn't allow version segment, and doesn't recognize FinalBlockId. If pipelining is enabled, the segments could be printed in wrong order. This shouldn't become an example because it doesn't reflect the best practices. This pair of tools could be only useful as traffic generators, but we already have a real traffic generator. Yours, Junxiao On Tue, Oct 21, 2014 at 12:58 PM, Alex Afanasyev < alexander.afanasyev at ucla.edu> wrote: > They originally meant to be simple debug tools / examples. They probably > can be removed or demoted to examples category (and moved to examples/ > folder). > > --- > Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From haroonr at iiitd.ac.in Wed Oct 22 04:16:56 2014 From: haroonr at iiitd.ac.in (Haroon Rashid) Date: Wed, 22 Oct 2014 16:46:56 +0530 Subject: [Nfd-dev] Unicast communication in a distributed application in NDN paradigm Message-ID: Hello All, I am planning to develop a distributed application using NDN paradigm. In this application, each machine should be able to do unicast communication and should not use shared memory (like ccnsync/chronosync). If I am correct, we already have a distributed NDN-chat application which is of broadcast nature (because message written in a namespace gets broadcasted to all members in the same namespace) and hence it uses the shared memory concept. Is there any other distributed application in NDN where unicast communication is supported? If not, how Can I achieve the same in NDN? Should I put the name of the target machine in the Interest packet (name) itself for facilitating such communication? But, would that will not change the basic architecture of NDN/CCN paradigm? -- Haroon Rashid -------------- next part -------------- An HTML attachment was scrubbed... URL: From dibenede at cs.colostate.edu Wed Oct 22 06:01:09 2014 From: dibenede at cs.colostate.edu (Steve DiBenedetto) Date: Wed, 22 Oct 2014 09:01:09 -0400 Subject: [Nfd-dev] ndncatchunks3 and ndnputchunks In-Reply-To: References: <46ED2352-527F-4E19-A04D-A935B80D16C1@ucla.edu> Message-ID: <5DA5B104-3CAF-4286-9227-1044F874AEEB@cs.colostate.edu> I would prefer to keep these applications as examples and improve them to conform to best practices. In general, the more examples of how to use the library, the better. You can assign the ndn-cxx task (if any) to me. -Steve > On Oct 21, 2014, at 11:39 PM, Junxiao Shi wrote: > > Hi Alex > > I think they shall be deleted. > > ndncatchunks3 fetches segments continuously until there's a timeout, then claims it's done. > It doesn't allow version segment, and doesn't recognize FinalBlockId. > If pipelining is enabled, the segments could be printed in wrong order. > This shouldn't become an example because it doesn't reflect the best practices. > > This pair of tools could be only useful as traffic generators, but we already have a real traffic generator. > > Yours, Junxiao > > On Tue, Oct 21, 2014 at 12:58 PM, Alex Afanasyev > wrote: > They originally meant to be simple debug tools / examples. They probably can be removed or demoted to examples category (and moved to examples/ folder). > > --- > Alex > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From dibenede at cs.colostate.edu Wed Oct 22 06:42:34 2014 From: dibenede at cs.colostate.edu (Steve DiBenedetto) Date: Wed, 22 Oct 2014 09:42:34 -0400 Subject: [Nfd-dev] Unicast communication in a distributed application in NDN paradigm In-Reply-To: References: Message-ID: <2BAC0415-A654-4AA2-AC43-DF4F9120F41F@cs.colostate.edu> Hi, I have not read these specific papers, but I recall their topics being similar to what you?re after: http://named-data.net/wp-content/uploads/nomen13.pdf http://named-data.net/wp-content/uploads/TRlighting.pdf In the past, I think we (the project) have discussed how NDN provides a superset of IP?s capabilities. If you really need point to point, there are mechanisms to get there. As you suggested, using a name that uniquely identifies an endpoint is something in that direction. Encrypting the Interest?s name and the Data response can further lock things down. **However**, it sounds like you are questioning whether or not this is the communication model you really want. We may be able to offer some suggestions if you can describe the application. -Steve > On Oct 22, 2014, at 7:16 AM, Haroon Rashid wrote: > > Hello All, > > I am planning to develop a distributed application using NDN paradigm. In this application, each machine should be able to do unicast communication and should not use shared memory (like ccnsync/chronosync). If I am correct, we already have a distributed NDN-chat application which is of broadcast nature (because message written in a namespace gets broadcasted to all members in the same namespace) and hence it uses the shared memory concept. Is there any other distributed application in NDN where unicast communication is supported? If not, how Can I achieve the same in NDN? Should I put the name of the target machine in the Interest packet (name) itself for facilitating such communication? But, would that will not change the basic architecture of NDN/CCN paradigm? > > -- > Haroon Rashid > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Wed Oct 22 12:59:44 2014 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Wed, 22 Oct 2014 19:59:44 +0000 Subject: [Nfd-dev] Unicast communication in a distributed application in NDN paradigm In-Reply-To: <2BAC0415-A654-4AA2-AC43-DF4F9120F41F@cs.colostate.edu> Message-ID: I agree with Steve ? the cases in the publications he sites are pretty specific, and are actually about targeting a physical object (light) not a computing node. We could make suggestions if you could describe the application. Jeff From: Steve DiBenedetto > Date: Wed, 22 Oct 2014 09:42:34 -0400 To: Haroon Rashid > Cc: Nitinder Mohan >, ">" >, Pushpendra Singh >, "ndn-app at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] Unicast communication in a distributed application in NDN paradigm Hi, I have not read these specific papers, but I recall their topics being similar to what you?re after: http://named-data.net/wp-content/uploads/nomen13.pdf http://named-data.net/wp-content/uploads/TRlighting.pdf In the past, I think we (the project) have discussed how NDN provides a superset of IP?s capabilities. If you really need point to point, there are mechanisms to get there. As you suggested, using a name that uniquely identifies an endpoint is something in that direction. Encrypting the Interest?s name and the Data response can further lock things down. **However**, it sounds like you are questioning whether or not this is the communication model you really want. We may be able to offer some suggestions if you can describe the application. -Steve On Oct 22, 2014, at 7:16 AM, Haroon Rashid > wrote: Hello All, I am planning to develop a distributed application using NDN paradigm. In this application, each machine should be able to do unicast communication and should not use shared memory (like ccnsync/chronosync). If I am correct, we already have a distributed NDN-chat application which is of broadcast nature (because message written in a namespace gets broadcasted to all members in the same namespace) and hence it uses the shared memory concept. Is there any other distributed application in NDN where unicast communication is supported? If not, how Can I achieve the same in NDN? Should I put the name of the target machine in the Interest packet (name) itself for facilitating such communication? But, would that will not change the basic architecture of NDN/CCN paradigm? -- Haroon Rashid _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Wed Oct 22 14:13:21 2014 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Wed, 22 Oct 2014 21:13:21 +0000 Subject: [Nfd-dev] ndncatchunks3 and ndnputchunks In-Reply-To: <5DA5B104-3CAF-4286-9227-1044F874AEEB@cs.colostate.edu> Message-ID: Seconded. We need more examples, not fewer. Jeff From: Steve DiBenedetto > Date: Wed, 22 Oct 2014 09:01:09 -0400 To: Junxiao Shi > Cc: ">" > Subject: Re: [Nfd-dev] ndncatchunks3 and ndnputchunks I would prefer to keep these applications as examples and improve them to conform to best practices. In general, the more examples of how to use the library, the better. You can assign the ndn-cxx task (if any) to me. -Steve On Oct 21, 2014, at 11:39 PM, Junxiao Shi > wrote: Hi Alex I think they shall be deleted. ndncatchunks3 fetches segments continuously until there's a timeout, then claims it's done. It doesn't allow version segment, and doesn't recognize FinalBlockId. If pipelining is enabled, the segments could be printed in wrong order. This shouldn't become an example because it doesn't reflect the best practices. This pair of tools could be only useful as traffic generators, but we already have a real traffic generator. Yours, Junxiao On Tue, Oct 21, 2014 at 12:58 PM, Alex Afanasyev > wrote: They originally meant to be simple debug tools / examples. They probably can be removed or demoted to examples category (and moved to examples/ folder). --- Alex _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From haroonr at iiitd.ac.in Wed Oct 22 22:10:02 2014 From: haroonr at iiitd.ac.in (Haroon Rashid) Date: Thu, 23 Oct 2014 10:40:02 +0530 Subject: [Nfd-dev] Unicast communication in a distributed application in NDN paradigm In-Reply-To: References: <2BAC0415-A654-4AA2-AC43-DF4F9120F41F@cs.colostate.edu> Message-ID: Thanks, Steve and Jeff for useful references. First, I want to make it clear that I don?t have any particular application in my mind right now. What all I am thinking of completely unicast communication in NDN in both directions (source->destination && destination->source), *i.e.*, sort of end to end connection. I mean a *distributed computing* type of application (not a lighting one). While going through the paper (lighting), I found that we can communicate with the target machine using its public key. This gives me an answer to one part of my question, but, now my other issue is to differentiate the tasks from different machines. To make it easy to understand let us use the following NDN network with 5 machines connected via LAN. [image: Inline image 1] Now suppose both ?B? and ?D? need some computational results from ?C? and hence accordingly sent the interest packet containing public key of ?C? so that only C (not A or E) can act on the Interest packet. Therefore, ?C? has received interests and did some computations and now it needs to send back computational results to ?B? and ?D? only. Now, accordingly these results should be unicasted back by using the public keys of B and D. But, ?C? does not know anything about these (B and D) because interest packet from ?B and D? to ?C? does not contain any information about their origin. So, I want to know how ?C? will send specific results back to these respective machines. I know that pending interests in PIT of ?C? and in-between routers might help but still I am not quite confident that it will work successfully. This is because in the Interest packet I used Selectors part to reach ?C? , while as in the Data packet I don?t find any such field to specify specific origin machines (B or D). Can anyone help me in the understanding of the same or point out to some references from where I can understand the same. Thanking you, On Thu, Oct 23, 2014 at 1:29 AM, Burke, Jeff wrote: > > I agree with Steve ? the cases in the publications he sites are pretty > specific, and are actually about targeting a physical object (light) not a > computing node. We could make suggestions if you could describe the > application. > Jeff > > From: Steve DiBenedetto > Date: Wed, 22 Oct 2014 09:42:34 -0400 > To: Haroon Rashid > Cc: Nitinder Mohan , "" > , Pushpendra Singh , " > ndn-app at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] Unicast communication in a distributed application > in NDN paradigm > > Hi, > > I have not read these specific papers, but I recall their topics being > similar to what you?re after: > > http://named-data.net/wp-content/uploads/nomen13.pdf > http://named-data.net/wp-content/uploads/TRlighting.pdf > > In the past, I think we (the project) have discussed how NDN provides a > superset of IP?s capabilities. If you really need point to point, there are > mechanisms to get there. As you suggested, using a name that uniquely > identifies an endpoint is something in that direction. Encrypting the > Interest?s name and the Data response can further lock things down. > > **However**, it sounds like you are questioning whether or not this is > the communication model you really want. We may be able to offer some > suggestions if you can describe the application. > > -Steve > > > On Oct 22, 2014, at 7:16 AM, Haroon Rashid wrote: > > Hello All, > > I am planning to develop a distributed application using NDN paradigm. In > this application, each machine should be able to do unicast communication > and should not use shared memory (like ccnsync/chronosync). If I am > correct, we already have a distributed NDN-chat application which is of > broadcast nature (because message written in a namespace gets broadcasted > to all members in the same namespace) and hence it uses the shared memory > concept. Is there any other distributed application in NDN where unicast > communication is supported? If not, how Can I achieve the same in NDN? > Should I put the name of the target machine in the Interest packet (name) > itself for facilitating such communication? But, would that will not change > the basic architecture of NDN/CCN paradigm? > > -- > Haroon Rashid > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > _______________________________________________ Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -- Haroon Rashid -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Network.JPG Type: image/jpeg Size: 12888 bytes Desc: not available URL: From dibenede at cs.colostate.edu Thu Oct 23 06:12:29 2014 From: dibenede at cs.colostate.edu (Steve DiBenedetto) Date: Thu, 23 Oct 2014 09:12:29 -0400 Subject: [Nfd-dev] Unicast communication in a distributed application in NDN paradigm In-Reply-To: References: <2BAC0415-A654-4AA2-AC43-DF4F9120F41F@cs.colostate.edu> Message-ID: <807CBD7F-A613-4975-9559-0E248FC7535E@cs.colostate.edu> > On Oct 23, 2014, at 1:10 AM, Haroon Rashid wrote: > > Thanks, Steve and Jeff for useful references. > > > > First, I want to make it clear that I don?t have any particular application in my mind right now. What all I am thinking of completely unicast communication in NDN in both directions (source->destination && destination->source), i.e., sort of end to end connection. I mean a distributed computing type of application (not a lighting one). While going through the paper (lighting), I found that we can communicate with the target machine using its public key. This gives me an answer to one part of my question, but, now my other issue is to differentiate the tasks from different machines. To make it easy to understand let us use the following NDN network with 5 machines connected via LAN. > > > > > > Now suppose both ?B? and ?D? need some computational results from ?C? and hence accordingly sent the interest packet containing public key of ?C? so that only C (not A or E) can act on the Interest packet. Therefore, ?C? has received interests and did some computations and now it needs to send back computational results to ?B? and ?D? only. Now, accordingly these results should be unicasted back by using the public keys of B and D. But, ?C? does not know anything about these (B and D) because interest packet from ?B and D? to ?C? does not contain any information about their origin. So, I want to know how ?C? will send specific results back to these respective machines. > > How important is it for B and D to be the only possible recipients? If it?s ok for others to receive the response (e.g. cache hit for a future request from A), then I don?t think you need to worry about encrypting the response. If you need B and D to be the unique recipients of their respective requests (B can?t read D?s response and vice versa), then you will want to encrypt. However, you don?t need B or D?s public key for this. Instead, B and D should provide a symmetric key to C as part of the computation request (i.e. encrypt the symmetric key towards C and place in a name component). We used this basic technique implementing ANDaNA (NDN Tor). There?s also a session-based version so that future requests use symmetric keys exclusively (encrypting towards C and the response). See: http://www.internetsociety.org/andana-anonymous-named-data-networking-application > I know that pending interests in PIT of ?C? and in-between routers might help but still I am not quite confident that it will work successfully. This is because in the Interest packet I used Selectors part to reach ?C? , while as in the Data packet I don?t find any such field to specify specific origin machines (B or D). Can anyone help me in the understanding of the same or point out to some references from where I can understand the same. > First and foremost, so long as the PIT entry is present, B and D will get a Data packet back (assuming the computation finishes in time, etc?). If B and D use the exact same Interest, then the PIT entry will have an appropriate set of face records that tells the node where to relay the returning Data. The same thing happens if B and D use different Interests, except there?s now one PIT entry for each with their respective face records. Selectors don?t change this. In fact, selectors are not used for routing the Interests to C in the first place. The selector?s job is to further specify the requested Data (?select something?) when there are one or more options (e.g. in a CS or repo) and determining which PIT entries can be satisfied by a returning Data packet. > > Thanking you, > > > > On Thu, Oct 23, 2014 at 1:29 AM, Burke, Jeff > wrote: > > I agree with Steve ? the cases in the publications he sites are pretty specific, and are actually about targeting a physical object (light) not a computing node. We could make suggestions if you could describe the application. > Jeff > > From: Steve DiBenedetto > > Date: Wed, 22 Oct 2014 09:42:34 -0400 > To: Haroon Rashid > > Cc: Nitinder Mohan >, ">" >, Pushpendra Singh >, "ndn-app at lists.cs.ucla.edu " > > Subject: Re: [Nfd-dev] Unicast communication in a distributed application in NDN paradigm > > Hi, > > I have not read these specific papers, but I recall their topics being similar to what you?re after: > > http://named-data.net/wp-content/uploads/nomen13.pdf > http://named-data.net/wp-content/uploads/TRlighting.pdf > > In the past, I think we (the project) have discussed how NDN provides a superset of IP?s capabilities. If you really need point to point, there are mechanisms to get there. As you suggested, using a name that uniquely identifies an endpoint is something in that direction. Encrypting the Interest?s name and the Data response can further lock things down. > > **However**, it sounds like you are questioning whether or not this is the communication model you really want. We may be able to offer some suggestions if you can describe the application. > > -Steve > > >> On Oct 22, 2014, at 7:16 AM, Haroon Rashid > wrote: >> >> Hello All, >> >> I am planning to develop a distributed application using NDN paradigm. In this application, each machine should be able to do unicast communication and should not use shared memory (like ccnsync/chronosync). If I am correct, we already have a distributed NDN-chat application which is of broadcast nature (because message written in a namespace gets broadcasted to all members in the same namespace) and hence it uses the shared memory concept. Is there any other distributed application in NDN where unicast communication is supported? If not, how Can I achieve the same in NDN? Should I put the name of the target machine in the Interest packet (name) itself for facilitating such communication? But, would that will not change the basic architecture of NDN/CCN paradigm? >> >> -- >> Haroon Rashid >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > -- > Haroon Rashid > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haroonr at iiitd.ac.in Thu Oct 23 19:59:11 2014 From: haroonr at iiitd.ac.in (Haroon Rashid) Date: Fri, 24 Oct 2014 08:29:11 +0530 Subject: [Nfd-dev] Unicast communication in a distributed application in NDN paradigm In-Reply-To: <807CBD7F-A613-4975-9559-0E248FC7535E@cs.colostate.edu> References: <2BAC0415-A654-4AA2-AC43-DF4F9120F41F@cs.colostate.edu> <807CBD7F-A613-4975-9559-0E248FC7535E@cs.colostate.edu> Message-ID: *>>If B and D use the exact same Interest, then the PIT entry will have an appropriate set of face records that tells the node where to* * relay the returning Data.* >>>>Consider if I want to maintain a log (name) of all machines at ?C? which requested for some computational results. In above scenario with interest aggregation at intermediate routers machine ?c? will never be able to know which all machines took benefit from it. In such a case, how can machine ?C? maintain a log of all requesting machines? *>>Selectors don?t change this. In fact, selectors are not used for routing the Interests to C in the first place. The selector?s job is to further specify the * *requested Data (?select something?) when there are one or more options (e.g. in a CS or repo) and determining which PIT entries can be satisfied by a returning * *Data packet.* >>>I was thinking of placing the public key of C in the Selectors part so as to direct the Interest to C in the first place. If it is not possible in this way, then how can I direct the interest to C in the first place? In other words, how should I use the public key of C for directing the Interest to "C" only? Should I use this public key as a part of the name itself rather than specifiying it in other parts of Interest packet? On Thu, Oct 23, 2014 at 6:42 PM, Steve DiBenedetto < dibenede at cs.colostate.edu> wrote: > > On Oct 23, 2014, at 1:10 AM, Haroon Rashid wrote: > > Thanks, Steve and Jeff for useful references. > > > First, I want to make it clear that I don?t have any particular > application in my mind right now. What all I am thinking of completely > unicast communication in NDN in both directions (source->destination && > destination->source), *i.e.*, sort of end to end connection. I mean a *distributed > computing* type of application (not a lighting one). While going through > the paper (lighting), I found that we can communicate with the target > machine using its public key. This gives me an answer to one part of my > question, but, now my other issue is to differentiate the tasks from > different machines. To make it easy to understand let us use the following > NDN network with 5 machines connected via LAN. > > > > > > Now suppose both ?B? and ?D? need some computational results from ?C? and > hence accordingly sent the interest packet containing public key of ?C? so > that only C (not A or E) can act on the Interest packet. Therefore, ?C? has > received interests and did some computations and now it needs to send back > computational results to ?B? and ?D? only. Now, accordingly these results > should be unicasted back by using the public keys of B and D. But, ?C? > does not know anything about these (B and D) because interest packet from > ?B and D? to ?C? does not contain any information about their origin. So, > I want to know how ?C? will send specific results back to these > respective machines. > > > How important is it for B and D to be the only possible recipients? If > it?s ok for others to receive the response (e.g. cache hit for a future > request from A), then I don?t think you need to worry about encrypting the > response. > > If you need B and D to be the unique recipients of their respective > requests (B can?t read D?s response and vice versa), then you will want to > encrypt. However, you don?t need B or D?s public key for this. Instead, B > and D should provide a symmetric key to C as part of the computation > request (i.e. encrypt the symmetric key towards C and place in a name > component). > > We used this basic technique implementing ANDaNA (NDN Tor). There?s also a > session-based version so that future requests use symmetric keys > exclusively (encrypting towards C and the response). See: > http://www.internetsociety.org/andana-anonymous-named-data-networking-application > > > I know that pending interests in PIT of ?C? and in-between routers might > help but still I am not quite confident that it will work successfully. > This is because in the Interest packet I used Selectors part to reach ?C? , > while as in the Data packet I don?t find any such field to specify specific > origin machines (B or D). Can anyone help me in the understanding of the > same or point out to some references from where I can understand the same. > > > First and foremost, so long as the PIT entry is present, B and D will get > a Data packet back (assuming the computation finishes in time, etc?). If B > and D use the exact same Interest, then the PIT entry will have an > appropriate set of face records that tells the node where to relay the > returning Data. The same thing happens if B and D use different Interests, > except there?s now one PIT entry for each with their respective face > records. > > Selectors don?t change this. In fact, selectors are not used for routing > the Interests to C in the first place. The selector?s job is to further > specify the requested Data (?select something?) when there are one or more > options (e.g. in a CS or repo) and determining which PIT entries can be > satisfied by a returning Data packet. > > > > Thanking you, > > > On Thu, Oct 23, 2014 at 1:29 AM, Burke, Jeff > wrote: > >> >> I agree with Steve ? the cases in the publications he sites are pretty >> specific, and are actually about targeting a physical object (light) not a >> computing node. We could make suggestions if you could describe the >> application. >> Jeff >> >> From: Steve DiBenedetto >> Date: Wed, 22 Oct 2014 09:42:34 -0400 >> To: Haroon Rashid >> Cc: Nitinder Mohan , "< >> nfd-dev at lists.cs.ucla.edu>" , Pushpendra >> Singh , "ndn-app at lists.cs.ucla.edu" < >> ndn-app at lists.cs.ucla.edu> >> Subject: Re: [Nfd-dev] Unicast communication in a distributed >> application in NDN paradigm >> >> Hi, >> >> I have not read these specific papers, but I recall their topics being >> similar to what you?re after: >> >> http://named-data.net/wp-content/uploads/nomen13.pdf >> http://named-data.net/wp-content/uploads/TRlighting.pdf >> >> In the past, I think we (the project) have discussed how NDN provides a >> superset of IP?s capabilities. If you really need point to point, there are >> mechanisms to get there. As you suggested, using a name that uniquely >> identifies an endpoint is something in that direction. Encrypting the >> Interest?s name and the Data response can further lock things down. >> >> **However**, it sounds like you are questioning whether or not this is >> the communication model you really want. We may be able to offer some >> suggestions if you can describe the application. >> >> -Steve >> >> >> On Oct 22, 2014, at 7:16 AM, Haroon Rashid wrote: >> >> Hello All, >> >> I am planning to develop a distributed application using NDN paradigm. >> In this application, each machine should be able to do unicast >> communication and should not use shared memory (like ccnsync/chronosync). >> If I am correct, we already have a distributed NDN-chat application which >> is of broadcast nature (because message written in a namespace gets >> broadcasted to all members in the same namespace) and hence it uses the >> shared memory concept. Is there any other distributed application in NDN >> where unicast communication is supported? If not, how Can I achieve the >> same in NDN? Should I put the name of the target machine in the Interest >> packet (name) itself for facilitating such communication? But, would that >> will not change the basic architecture of NDN/CCN paradigm? >> >> -- >> Haroon Rashid >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> >> _______________________________________________ Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> > > > -- > Haroon Rashid > > > > -- Haroon Rashid -------------- next part -------------- An HTML attachment was scrubbed... URL: From dibenede at cs.colostate.edu Thu Oct 23 21:13:25 2014 From: dibenede at cs.colostate.edu (Steve DiBenedetto) Date: Thu, 23 Oct 2014 22:13:25 -0600 Subject: [Nfd-dev] Unicast communication in a distributed application in NDN paradigm In-Reply-To: References: <2BAC0415-A654-4AA2-AC43-DF4F9120F41F@cs.colostate.edu> <807CBD7F-A613-4975-9559-0E248FC7535E@cs.colostate.edu> Message-ID: <35F99CE3-7B85-48FD-B07D-9142643215CA@cs.colostate.edu> > On Oct 23, 2014, at 8:59 PM, Haroon Rashid wrote: > > >>If B and D use the exact same Interest, then the PIT entry will have an appropriate set of face records that tells the node where to > relay the returning Data. > > > > >>>>Consider if I want to maintain a log (name) of all machines at ?C? which requested for some computational results. In above scenario with interest aggregation at intermediate > > routers machine ?c? will never be able to know which all machines took benefit from it. In such a case, how can machine ?C? maintain a log of all requesting machines? > > This sounds like a different problem because you want to know the identity of the requester. There is nothing in an Interest to identify the sender. Conceptually, a PIT entry is providing at most ?the Interest came from that way?. You would need to add identifying information to the Interest. For example, the name could encode ?Perform computation X on 'Alice?s machine? for ?Bob? ?. > > >>Selectors don?t change this. In fact, selectors are not used for routing the Interests to C in the first place. The selector?s job is to further specify the > requested Data (?select something?) when there are one or more options (e.g. in a CS or repo) and determining which PIT entries can be satisfied by a returning > Data packet. > > >>>I was thinking of placing the public key of C in the Selectors part so as to direct the Interest to C in the first place. If it is not possible in this way, then how can I direct the interest to > C in the first place? In other words, how should I use the public key of C for directing the Interest to "C" only? Should I use this public key as a part of the name itself rather > than specifiying it in other parts of Interest packet? Ideally, you should use a sufficiently specific name so that the Interest will be routed to C. Names are the primary driver of forwarding; we do longest prefix match to find the set of possible next hops. Forwarding strategy then chooses which one(s) to use. In the general case, intermediate routers don?t know that there is some machine named C. Instead, they have a bunch of prefixes and one or more may eventually lead to the machine known to the requester as C. Therefore, you want to use a sufficiently specific name in your Interest to make sure your request is getting to the right place. I don?t think it matters too much how you choose to identify C in your protocol. Using the public key digest to name the destination is one option, but it has no special power over forwarding. It?s just another name component to the network. You could just as easily, and possibly prefer to, use a human readable name to refer to C. Encryption guarantees that only C can process the message. For example, when the longest matching routing prefix is not specific to C. As an example usage, suppose you are expressing the computation as one or more name components. You could encrypt the computation components under C?s key to ensure only C is able to perform the computation. > > > On Thu, Oct 23, 2014 at 6:42 PM, Steve DiBenedetto > wrote: > >> On Oct 23, 2014, at 1:10 AM, Haroon Rashid > wrote: >> >> Thanks, Steve and Jeff for useful references. >> >> >> >> First, I want to make it clear that I don?t have any particular application in my mind right now. What all I am thinking of completely unicast communication in NDN in both directions (source->destination && destination->source), i.e., sort of end to end connection. I mean a distributed computing type of application (not a lighting one). While going through the paper (lighting), I found that we can communicate with the target machine using its public key. This gives me an answer to one part of my question, but, now my other issue is to differentiate the tasks from different machines. To make it easy to understand let us use the following NDN network with 5 machines connected via LAN. >> >> >> >> >> >> Now suppose both ?B? and ?D? need some computational results from ?C? and hence accordingly sent the interest packet containing public key of ?C? so that only C (not A or E) can act on the Interest packet. Therefore, ?C? has received interests and did some computations and now it needs to send back computational results to ?B? and ?D? only. Now, accordingly these results should be unicasted back by using the public keys of B and D. But, ?C? does not know anything about these (B and D) because interest packet from ?B and D? to ?C? does not contain any information about their origin. So, I want to know how ?C? will send specific results back to these respective machines. >> >> > > How important is it for B and D to be the only possible recipients? If it?s ok for others to receive the response (e.g. cache hit for a future request from A), then I don?t think you need to worry about encrypting the response. > > If you need B and D to be the unique recipients of their respective requests (B can?t read D?s response and vice versa), then you will want to encrypt. However, you don?t need B or D?s public key for this. Instead, B and D should provide a symmetric key to C as part of the computation request (i.e. encrypt the symmetric key towards C and place in a name component). > > We used this basic technique implementing ANDaNA (NDN Tor). There?s also a session-based version so that future requests use symmetric keys exclusively (encrypting towards C and the response). See: http://www.internetsociety.org/andana-anonymous-named-data-networking-application >> I know that pending interests in PIT of ?C? and in-between routers might help but still I am not quite confident that it will work successfully. This is because in the Interest packet I used Selectors part to reach ?C? , while as in the Data packet I don?t find any such field to specify specific origin machines (B or D). Can anyone help me in the understanding of the same or point out to some references from where I can understand the same. >> > > First and foremost, so long as the PIT entry is present, B and D will get a Data packet back (assuming the computation finishes in time, etc?). If B and D use the exact same Interest, then the PIT entry will have an appropriate set of face records that tells the node where to relay the returning Data. The same thing happens if B and D use different Interests, except there?s now one PIT entry for each with their respective face records. > > Selectors don?t change this. In fact, selectors are not used for routing the Interests to C in the first place. The selector?s job is to further specify the requested Data (?select something?) when there are one or more options (e.g. in a CS or repo) and determining which PIT entries can be satisfied by a returning Data packet. > >> >> Thanking you, >> >> >> >> On Thu, Oct 23, 2014 at 1:29 AM, Burke, Jeff > wrote: >> >> I agree with Steve ? the cases in the publications he sites are pretty specific, and are actually about targeting a physical object (light) not a computing node. We could make suggestions if you could describe the application. >> Jeff >> >> From: Steve DiBenedetto > >> Date: Wed, 22 Oct 2014 09:42:34 -0400 >> To: Haroon Rashid > >> Cc: Nitinder Mohan >, ">" >, Pushpendra Singh >, "ndn-app at lists.cs.ucla.edu " > >> Subject: Re: [Nfd-dev] Unicast communication in a distributed application in NDN paradigm >> >> Hi, >> >> I have not read these specific papers, but I recall their topics being similar to what you?re after: >> >> http://named-data.net/wp-content/uploads/nomen13.pdf >> http://named-data.net/wp-content/uploads/TRlighting.pdf >> >> In the past, I think we (the project) have discussed how NDN provides a superset of IP?s capabilities. If you really need point to point, there are mechanisms to get there. As you suggested, using a name that uniquely identifies an endpoint is something in that direction. Encrypting the Interest?s name and the Data response can further lock things down. >> >> **However**, it sounds like you are questioning whether or not this is the communication model you really want. We may be able to offer some suggestions if you can describe the application. >> >> -Steve >> >> >>> On Oct 22, 2014, at 7:16 AM, Haroon Rashid > wrote: >>> >>> Hello All, >>> >>> I am planning to develop a distributed application using NDN paradigm. In this application, each machine should be able to do unicast communication and should not use shared memory (like ccnsync/chronosync). If I am correct, we already have a distributed NDN-chat application which is of broadcast nature (because message written in a namespace gets broadcasted to all members in the same namespace) and hence it uses the shared memory concept. Is there any other distributed application in NDN where unicast communication is supported? If not, how Can I achieve the same in NDN? Should I put the name of the target machine in the Interest packet (name) itself for facilitating such communication? But, would that will not change the basic architecture of NDN/CCN paradigm? >>> >>> -- >>> Haroon Rashid >>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> >> -- >> Haroon Rashid >> >> > > > > > -- > Haroon Rashid > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.pesavento at lip6.fr Sun Oct 26 07:04:09 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Sun, 26 Oct 2014 15:04:09 +0100 Subject: [Nfd-dev] Switching to C++11, dropping support for C++98/03 Message-ID: Dear all, We are transitioning ndn-cxx and all dependent projects to C++11 only. This means that we are dropping support for building these projects using the C++98 (aka C++03) language standard. For more information see task #1930. http://gerrit.named-data.net/1191 implements the change for ndn-cxx and http://gerrit.named-data.net/1335 does the same for NFD. ndndump has already been fixed, NLSR and other official projects will follow in the next days. If there are no objections, the above changes will be merged no sooner than Wed Oct 29 15:00 UTC. If you have code that compiles against ndn-cxx, please make sure it is compatible with C++11 as soon as possible. Be careful that libstdc++'s C++11 ABI is not considered stable yet, therefore linking objects built with different versions of gcc is not supported, if those objects expose standard library types at their ABI boundaries and have been compiled in C++11 mode. Mixing C++11 and C++98 code is also considered dangerous if std:: types are used. See https://gcc.gnu.org/wiki/Cxx11AbiCompatibility for details. Best regards, Davide From alexander.afanasyev at ucla.edu Tue Oct 28 14:20:50 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Tue, 28 Oct 2014 14:20:50 -0700 Subject: [Nfd-dev] Possibility of dropping support for OSX 10.8 Message-ID: <1C13F8E1-DBAC-4AE3-822F-8CA030EFE3D5@ucla.edu> Hi! Given the recent release of OSX 10.10, I'm considering dropping support for OSX 10.8, so we focus only on last 2 OSX releases. Before that, are there people on this mailing list who are still using 10.8? --- Alex From christos at cs.colostate.edu Tue Oct 28 14:25:55 2014 From: christos at cs.colostate.edu (Christos Papadopoulos) Date: Tue, 28 Oct 2014 15:25:55 -0600 Subject: [Nfd-dev] Supporting objects larger than 8KB Message-ID: <545009E3.9050308@cs.colostate.edu> In the climate domain, the datasizes of objects are quite big, and that makes the current object size restriction of 8KB very small. Is there any reason not to make this configurable and support much larger object size? Christos. From alexander.afanasyev at ucla.edu Tue Oct 28 14:30:04 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Tue, 28 Oct 2014 14:30:04 -0700 Subject: [Nfd-dev] Supporting objects larger than 8KB In-Reply-To: <545009E3.9050308@cs.colostate.edu> References: <545009E3.9050308@cs.colostate.edu> Message-ID: The primary motivation of keeping object (transmission unit) size small is to restrict network-level fragmentation and encourage application-level segmentation. In other words, individual Data packet should be (generally) small enough to fit in one transmission unit. Allowing arbitrary packet sizes would violate this property and require extensive hop-by-hop fragmentation and reassembly. Is there a problem with segmenting larger objects into a bunch of Data packets? --- Alex > On Oct 28, 2014, at 2:25 PM, Christos Papadopoulos wrote: > > In the climate domain, the datasizes of objects are quite big, and that makes the current object size restriction of 8KB very small. > > Is there any reason not to make this configurable and support much larger object size? > > Christos. > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From oran at cisco.com Tue Oct 28 15:08:17 2014 From: oran at cisco.com (Dave Oran (oran)) Date: Tue, 28 Oct 2014 22:08:17 +0000 Subject: [Nfd-dev] Supporting objects larger than 8KB In-Reply-To: References: <545009E3.9050308@cs.colostate.edu> Message-ID: <1C9F2035-6933-4C6C-AF0B-2C2D0D2357AF@cisco.com> It also vastly complicates resource allocation compared with the smaller dynamic range we have now - you certainly can?t do something trivial like interest counting with a such a big dynamic range. As a matter of fact, some time I?d like to discuss whether interest counting won?t work for the 4K dynamic range we have today. On Oct 28, 2014, at 2:30 PM, Alex Afanasyev wrote: > The primary motivation of keeping object (transmission unit) size small is to restrict network-level fragmentation and encourage application-level segmentation. > > In other words, individual Data packet should be (generally) small enough to fit in one transmission unit. Allowing arbitrary packet sizes would violate this property and require extensive hop-by-hop fragmentation and reassembly. > > Is there a problem with segmenting larger objects into a bunch of Data packets? > > --- > Alex > >> On Oct 28, 2014, at 2:25 PM, Christos Papadopoulos wrote: >> >> In the climate domain, the datasizes of objects are quite big, and that makes the current object size restriction of 8KB very small. >> >> Is there any reason not to make this configurable and support much larger object size? >> >> Christos. >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From shijunxiao at email.arizona.edu Tue Oct 28 15:21:41 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 28 Oct 2014 15:21:41 -0700 Subject: [Nfd-dev] Supporting objects larger than 8KB In-Reply-To: <545009E3.9050308@cs.colostate.edu> References: <545009E3.9050308@cs.colostate.edu> Message-ID: Hi Christos The 8800-octet practical packet size limit comes from CCNx. I asked about the reason for this setting, and I agree with their answer: http://www.ccnx.org/pipermail/ccnx-users/2013-October/001355.html Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Tue Oct 28 23:49:49 2014 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Wed, 29 Oct 2014 06:49:49 +0000 Subject: [Nfd-dev] Possibility of dropping support for OSX 10.8 In-Reply-To: <1C13F8E1-DBAC-4AE3-822F-8CA030EFE3D5@ucla.edu> Message-ID: Hi Alex, Please do not make this decision lightly... It's not uncommon for machines in production / turnkey use to have older versions of the operating system, and going two minor releases back from the bleeding edge is really not that far. I'd vote for keeping 10.8 for a while... is it causing some kind of hardship in builds? Jeff On 10/28/14, 2:20 PM, "Alex Afanasyev" wrote: >Hi! > >Given the recent release of OSX 10.10, I'm considering dropping support >for OSX 10.8, so we focus only on last 2 OSX releases. > >Before that, are there people on this mailing list who are still using >10.8? > >--- >Alex > > >_______________________________________________ >Nfd-dev mailing list >Nfd-dev at lists.cs.ucla.edu >http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From davide.pesavento at lip6.fr Wed Oct 29 05:48:31 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Wed, 29 Oct 2014 13:48:31 +0100 Subject: [Nfd-dev] Possibility of dropping support for OSX 10.8 In-Reply-To: <1C13F8E1-DBAC-4AE3-822F-8CA030EFE3D5@ucla.edu> References: <1C13F8E1-DBAC-4AE3-822F-8CA030EFE3D5@ucla.edu> Message-ID: Alex, Personally, I couldn't care less about the level of support for OS X, as we exclusively use Linux for our research. However, if we want to say that we support OS X, we should at least be serious and credible about it. Mountain Lion was released a little more than 2 years ago, and I believe it's still supported by Apple (although there's no clear official policy on this so feel free to correct me if I'm wrong). I think it's a bit premature to drop support for it. If the reason for this proposal is the libstdc++ vs. libc++ issue (which is blocking C++11 adoption, or at least making it harder to build NFD with C++11 on 10.8), I believe it's probably better to postpone the switch to C++11 until v0.4 or even v0.5. Thanks, Davide On Tue, Oct 28, 2014 at 10:20 PM, Alex Afanasyev wrote: > Hi! > > Given the recent release of OSX 10.10, I'm considering dropping support for OSX 10.8, so we focus only on last 2 OSX releases. > > Before that, are there people on this mailing list who are still using 10.8? > > --- > Alex > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From shijunxiao at email.arizona.edu Wed Oct 29 07:11:58 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 29 Oct 2014 07:11:58 -0700 Subject: [Nfd-dev] Possibility of dropping support for OSX 10.8 In-Reply-To: References: <1C13F8E1-DBAC-4AE3-822F-8CA030EFE3D5@ucla.edu> Message-ID: Dear folks OSX 10.8 clang's default usage of GCC 4.2's libstdc++ shall contribute to the desire of dropping support for OSX 10.8. However, this is a solvable problem. OSX 10.8 is still a required platform for NDN Platform. According to Wikipedia, it's still supported by Apple for security updates and printer drivers. We shouldn't drop support for OSX 10.8 now. The solution for compiling with libc++ on OSX 10.8 may be complex (eg. build Boost from source or use Brew instead of MacPorts), but these complications should be acceptable. C++11 will greatly increase programmer efficiency and program performance. We shouldn't block C++11 adoption in favor of easier installation on an ancient platform. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From christos at cs.colostate.edu Wed Oct 29 12:42:12 2014 From: christos at cs.colostate.edu (Christos Papadopoulos) Date: Wed, 29 Oct 2014 13:42:12 -0600 Subject: [Nfd-dev] Supporting objects larger than 8KB In-Reply-To: References: <545009E3.9050308@cs.colostate.edu> Message-ID: <54514314.10803@cs.colostate.edu> I should have been more clear in my question. I was asking if there is a reason not to make it configurable. The answers I got offer wisdom about not exceeding size X when running over the big-I Internet. I want to separate the question of selecting the appropriate size and what NFD should support. If I have my private network where I want to support a large object size or even if I want to experiment with different sizes to try out different fragmentation algorithms, I should be able to do it, right? Hopefully the max object size is a configuration parameter somewhere and NFD does not make any assumptions. Maybe the answer is go ahead and try it and file a bug report if it breaks :-) Christos. On 10/28/2014 04:21 PM, Junxiao Shi wrote: > Hi Christos > > The 8800-octet practical packet size limit comes from CCNx. > I asked about the reason for this setting, and I agree with their > answer: http://www.ccnx.org/pipermail/ccnx-users/2013-October/001355.html > > Yours, Junxiao From shijunxiao at email.arizona.edu Wed Oct 29 13:01:53 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 29 Oct 2014 13:01:53 -0700 Subject: [Nfd-dev] Supporting objects larger than 8KB In-Reply-To: <54514314.10803@cs.colostate.edu> References: <545009E3.9050308@cs.colostate.edu> <54514314.10803@cs.colostate.edu> Message-ID: Hi Christos Practical limit of NDN packet size is controlled by ndn::MAX_NDN_PACKET_SIZE constant in ndn-cxx (common.hpp). There shouldn't be hard-coded packet size limit anywhere else, otherwise it's a bug. You may change this constant, and recompile everything. Yours, Junxiao On Oct 29, 2014 12:42 PM, "Christos Papadopoulos" wrote: > I should have been more clear in my question. > > I was asking if there is a reason not to make it configurable. > The answers I got offer wisdom about not exceeding size X when running > over the big-I Internet. > > I want to separate the question of selecting the appropriate size and what > NFD should support. > > If I have my private network where I want to support a large object size > or even if I want to experiment with different sizes to try out different > fragmentation algorithms, I should be able to do it, right? > > Hopefully the max object size is a configuration parameter somewhere and > NFD does not make any assumptions. > > Maybe the answer is go ahead and try it and file a bug report if it breaks > :-) > > Christos. > > > On 10/28/2014 04:21 PM, Junxiao Shi wrote: > >> Hi Christos >> >> The 8800-octet practical packet size limit comes from CCNx. >> I asked about the reason for this setting, and I agree with their >> answer: http://www.ccnx.org/pipermail/ccnx-users/2013-October/001355.html >> >> Yours, Junxiao >> > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oran at cisco.com Wed Oct 29 13:06:14 2014 From: oran at cisco.com (Dave Oran (oran)) Date: Wed, 29 Oct 2014 20:06:14 +0000 Subject: [Nfd-dev] Supporting objects larger than 8KB In-Reply-To: References: <545009E3.9050308@cs.colostate.edu> <54514314.10803@cs.colostate.edu>, Message-ID: <9EBB6259-D031-4EB7-B725-174C24621AE0@cisco.com> And of since there will be instances of NFD on e net with different values of this parameter, we have a fully cooked PMTU discovery protocol to make sure this works, right? ___________________________ iDevice - please excuse typos. On Oct 29, 2014, at 1:02 PM, Junxiao Shi > wrote: Hi Christos Practical limit of NDN packet size is controlled by ndn::MAX_NDN_PACKET_SIZE constant in ndn-cxx (common.hpp). There shouldn't be hard-coded packet size limit anywhere else, otherwise it's a bug. You may change this constant, and recompile everything. Yours, Junxiao On Oct 29, 2014 12:42 PM, "Christos Papadopoulos" > wrote: I should have been more clear in my question. I was asking if there is a reason not to make it configurable. The answers I got offer wisdom about not exceeding size X when running over the big-I Internet. I want to separate the question of selecting the appropriate size and what NFD should support. If I have my private network where I want to support a large object size or even if I want to experiment with different sizes to try out different fragmentation algorithms, I should be able to do it, right? Hopefully the max object size is a configuration parameter somewhere and NFD does not make any assumptions. Maybe the answer is go ahead and try it and file a bug report if it breaks :-) Christos. On 10/28/2014 04:21 PM, Junxiao Shi wrote: Hi Christos The 8800-octet practical packet size limit comes from CCNx. I asked about the reason for this setting, and I agree with their answer: http://www.ccnx.org/pipermail/ccnx-users/2013-October/001355.html Yours, Junxiao _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Oct 29 13:10:04 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 29 Oct 2014 13:10:04 -0700 Subject: [Nfd-dev] Supporting objects larger than 8KB In-Reply-To: <9EBB6259-D031-4EB7-B725-174C24621AE0@cisco.com> References: <545009E3.9050308@cs.colostate.edu> <54514314.10803@cs.colostate.edu> <9EBB6259-D031-4EB7-B725-174C24621AE0@cisco.com> Message-ID: Hi Dave PMTU discovery cannot help in this case, because: * Consumer and producer are not necessarily online at the same time. Data can be produced earlier, be cached, and sent to consumer later. Existing Data cannot be segmented at NDN layer because this breaks signature. * Data delivery can be multicast, where each path has a different MTU. Yours, Junxiao On Oct 29, 2014 1:06 PM, "Dave Oran (oran)" wrote: > > And of since there will be instances of NFD on e net with different values of this parameter, we have a fully cooked PMTU discovery protocol to make sure this works, right? > > > ___________________________ > iDevice - please excuse typos. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Mosko at parc.com Wed Oct 29 13:29:24 2014 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Wed, 29 Oct 2014 20:29:24 +0000 Subject: [Nfd-dev] Supporting objects larger than 8KB In-Reply-To: References: <545009E3.9050308@cs.colostate.edu> <54514314.10803@cs.colostate.edu> <9EBB6259-D031-4EB7-B725-174C24621AE0@cisco.com> Message-ID: <6B1C5C88-9F39-464F-88E0-A3A19A971F52@parc.com> That said, it does seem like if the Interest does path discovery it can avoid a lot of fragmentation in the cases of dynamic content. Marc On Oct 29, 2014, at 1:10 PM, Junxiao Shi > wrote: Hi Dave PMTU discovery cannot help in this case, because: * Consumer and producer are not necessarily online at the same time. Data can be produced earlier, be cached, and sent to consumer later. Existing Data cannot be segmented at NDN layer because this breaks signature. * Data delivery can be multicast, where each path has a different MTU. Yours, Junxiao On Oct 29, 2014 1:06 PM, "Dave Oran (oran)" > wrote: > > And of since there will be instances of NFD on e net with different values of this parameter, we have a fully cooked PMTU discovery protocol to make sure this works, right? > > > ___________________________ > iDevice - please excuse typos. _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From oran at cisco.com Wed Oct 29 13:46:52 2014 From: oran at cisco.com (Dave Oran (oran)) Date: Wed, 29 Oct 2014 20:46:52 +0000 Subject: [Nfd-dev] Supporting objects larger than 8KB In-Reply-To: References: <545009E3.9050308@cs.colostate.edu> <54514314.10803@cs.colostate.edu> <9EBB6259-D031-4EB7-B725-174C24621AE0@cisco.com>, Message-ID: Good points. So, max object chunk size has to be an architectural constant? ___________________________ iDevice - please excuse typos. On Oct 29, 2014, at 1:10 PM, Junxiao Shi > wrote: Hi Dave PMTU discovery cannot help in this case, because: * Consumer and producer are not necessarily online at the same time. Data can be produced earlier, be cached, and sent to consumer later. Existing Data cannot be segmented at NDN layer because this breaks signature. * Data delivery can be multicast, where each path has a different MTU. Yours, Junxiao On Oct 29, 2014 1:06 PM, "Dave Oran (oran)" > wrote: > > And of since there will be instances of NFD on e net with different values of this parameter, we have a fully cooked PMTU discovery protocol to make sure this works, right? > > > ___________________________ > iDevice - please excuse typos. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Oct 30 14:49:30 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 30 Oct 2014 14:49:30 -0700 Subject: [Nfd-dev] code style rule 3.20 In-Reply-To: References: Message-ID: Dear folks rule 3.20 states: 0 should be used instead of NULL. In C++ 11, a null pointer is typically written as std::nullptr. Usage of std::nullptr is already permitted, because it doesn't violate this rule. Should we amend this rule as follows? "std::nullptr" should be used to represent null pointer. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Thu Oct 30 14:57:41 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Thu, 30 Oct 2014 14:57:41 -0700 Subject: [Nfd-dev] code style rule 3.20 In-Reply-To: References: Message-ID: <4FBC5A5E-6C83-41DA-847C-775210B57CA6@ucla.edu> Given the amount of code we have, I would suggest we keep both notations as allowed. > On Oct 30, 2014, at 2:49 PM, Junxiao Shi wrote: > > Dear folks > > rule 3.20 states: 0 should be used instead of NULL. > > In C++ 11, a null pointer is typically written as std::nullptr. > Usage of std::nullptr is already permitted, because it doesn't violate this rule. > > Should we amend this rule as follows? > "std::nullptr" should be used to represent null pointer. > > Yours, Junxiao > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Oct 30 15:00:31 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 30 Oct 2014 15:00:31 -0700 Subject: [Nfd-dev] code style rule 3.20 In-Reply-To: <4FBC5A5E-6C83-41DA-847C-775210B57CA6@ucla.edu> References: <4FBC5A5E-6C83-41DA-847C-775210B57CA6@ucla.edu> Message-ID: Hi Alex I'm not saying 0 is forbidden. My suggestion is: any new code should use nullptr to represent null pointer, instead of 0 or NULL. Yours, Junxiao On Oct 30, 2014 2:57 PM, "Alex Afanasyev" wrote: > Given the amount of code we have, I would suggest we keep both notations > as allowed. > > On Oct 30, 2014, at 2:49 PM, Junxiao Shi > wrote: > > Dear folks > > rule 3.20 states: 0 should be used instead of NULL. > > In C++ 11, a null pointer is typically written as std::nullptr. > Usage of std::nullptr is already permitted, because it doesn't violate > this rule. > > Should we amend this rule as follows? > "std::nullptr" should be used to represent null pointer. > > Yours, Junxiao > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Thu Oct 30 15:03:07 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Thu, 30 Oct 2014 15:03:07 -0700 Subject: [Nfd-dev] code style rule 3.20 In-Reply-To: References: <4FBC5A5E-6C83-41DA-847C-775210B57CA6@ucla.edu> Message-ID: <496338A2-FFC7-4FAD-8645-FB3FF4CA6F52@ucla.edu> Ok. I misunderstood. Yes, for the new code it makes more sense to use nullptr ?-- Alex > On Oct 30, 2014, at 3:00 PM, Junxiao Shi wrote: > > Hi Alex > > I'm not saying 0 is forbidden. > > My suggestion is: any new code should use nullptr to represent null pointer, instead of 0 or NULL. > > Yours, Junxiao > > On Oct 30, 2014 2:57 PM, "Alex Afanasyev" > wrote: > Given the amount of code we have, I would suggest we keep both notations as allowed. > >> On Oct 30, 2014, at 2:49 PM, Junxiao Shi > wrote: >> >> Dear folks >> >> rule 3.20 states: 0 should be used instead of NULL. >> >> In C++ 11, a null pointer is typically written as std::nullptr. >> Usage of std::nullptr is already permitted, because it doesn't violate this rule. >> >> Should we amend this rule as follows? >> "std::nullptr" should be used to represent null pointer. >> >> Yours, Junxiao >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.pesavento at lip6.fr Thu Oct 30 15:30:30 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Thu, 30 Oct 2014 22:30:30 +0000 Subject: [Nfd-dev] code style rule 3.20 References: Message-ID: There is no such thing as std::nullptr. In C++11 nullptr (without std) is a language keyword, it is *not* part of the standard library. The type of nullptr, on the other hand, is std::nullptr_t, and is part of the standard library. That being said, I agree with the proposal. Thanks, Davide On Thu, Oct 30, 2014, 10:49 PM Junxiao Shi wrote: > Dear folks > > rule 3.20 states: 0 should be used instead of NULL. > > In C++ 11, a null pointer is typically written as std::nullptr. > Usage of std::nullptr is already permitted, because it doesn't violate > this rule. > > Should we amend this rule as follows? > "std::nullptr" should be used to represent null pointer. > > Yours, Junxiao > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Oct 30 21:21:09 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 30 Oct 2014 21:21:09 -0700 Subject: [Nfd-dev] ndn-cxx feature deprecation in nfd::Controller class Message-ID: Dear folks The following items are deprecated in ndn-cxx: - Controller::start overloads, except the overload taking CommandOptions - Controller::Sign typedef - Controller::getDefaultCommandTimeout - ControlCommand::getPrefix - ControlCommand::getRequestName(ControlParameters) - Controller::Controller(Face&) If you have code that uses any of those features, please migrate to the new syntax as described in Doxygen. I will add DEPRECATED macro onto those items soon, but no earlier than Nov 05 13:00 UTC. This means compiler will produce a warning whenever they are used. If your project uses "-Werror" flag, this would become an error. Those deprecated items will be deleted in v0.4. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Fri Oct 31 10:04:28 2014 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Fri, 31 Oct 2014 17:04:28 +0000 Subject: [Nfd-dev] Building NFD on Windows Message-ID: Hi folks, It is likely that the software used to interface with the Siemens building monitoring system that we will access as part of the "enterprise building automation and management" network environment has a Windows SDK. I believe that we have already tested building NDN-CPP on Windows. Has any one tried to build and run NFD on Windows? Can we consider adding support for this if it is not already there? I realize it is not a favorite for many academic CS environments, especially in the US, but it is fairly common in enterprise environments such as building monitoring. Being able to build against SDKs and/or run NDN-enabled applications on the same boxes as these enterprise applications would be very helpful. Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.ARIZONA.EDU Fri Oct 31 10:11:20 2014 From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi) Date: Fri, 31 Oct 2014 10:11:20 -0700 Subject: [Nfd-dev] Building NFD on Windows In-Reply-To: References: Message-ID: Hi Jeff Can you explain more about the platform? Specifically: - What version of Windows? - Intel or ARM architecture? - Server or Enterprise or Professional or Home or RT edition? - Windows XP or Windows 7 or Windows 8? - What kind of hardware? - Server or Desktop or embedded system? - How much memory available? - How many CPU cores? - Does the CPU support VT-X (so that we can use Hyper-V or VirtualBox to run a Ubuntu VM alongside Windows)? Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Fri Oct 31 10:23:13 2014 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Fri, 31 Oct 2014 17:23:13 +0000 Subject: [Nfd-dev] Building NFD on Windows In-Reply-To: Message-ID: Hi Junxiao, My current understanding is below. Jeff From: Junxiao Shi > Date: Fri, 31 Oct 2014 10:11:20 -0700 To: Jeff Burke > Cc: "nfd-dev at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] Building NFD on Windows Hi Jeff Can you explain more about the platform? Specifically: * What version of Windows? * Intel or ARM architecture? Intel * Server or Enterprise or Professional or Home or RT edition? Server 2008 64-bit (though we may have other options) * Windows XP or Windows 7 or Windows 8? * What kind of hardware? * Server or Desktop or embedded system? Server * How much memory available? Whatever is needed, >4GB available shouldn't be a problem * How many CPU cores? Whatever is needed, multicore * Does the CPU support VT-X (so that we can use Hyper-V or VirtualBox to run a Ubuntu VM alongside Windows)? Not sure as we haven't purchased the hardware yet but my question is about running NFD natively on Windows. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From wchao at us.fujitsu.com Fri Oct 31 10:49:23 2014 From: wchao at us.fujitsu.com (Wu Chao) Date: Fri, 31 Oct 2014 10:49:23 -0700 Subject: [Nfd-dev] Permission Denied while trying to install ndn-cxx Message-ID: <5453CBA3.1030507@us.fujitsu.com> Hi, I was trying to build ndn-cxx from source on Ubuntu14.04. The configure and waf were successful. However, the sudo waf install failed since "Permission Denied". I also have tried install with root but it did not work. I include the screen capture of the sudo waf install process. Regards Chao -------------- next part -------------- A non-text attachment was scrubbed... Name: err1.png Type: image/png Size: 238091 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: err2.png Type: image/png Size: 240141 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: err3.png Type: image/png Size: 249028 bytes Desc: not available URL: From shijunxiao at email.arizona.edu Fri Oct 31 10:59:37 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 31 Oct 2014 10:59:37 -0700 Subject: [Nfd-dev] Building NFD on Windows In-Reply-To: References: Message-ID: Hi Jeff Windows Server 2008 contains Windows Services for UNIX. There's a possibility of running NFD natively on Windows without major changes to the code If you haven't purchased the hardware, the CPU is likely to have VT-X because every CPU produced in recently years support it. So the alternate is to install a minimal Ubuntu VM in VirtualBox, expose its TCP port, and make Windows applications connect to it. The performance penalty due to virtualization is less than 5%. Deployment cost isn't necessarily higher, because it could be automated. (reference: BOINC VM jobs) Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Oct 31 11:02:05 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 31 Oct 2014 11:02:05 -0700 Subject: [Nfd-dev] Permission Denied while trying to install ndn-cxx In-Reply-To: <5453CBA3.1030507@us.fujitsu.com> References: <5453CBA3.1030507@us.fujitsu.com> Message-ID: Hi Wu Please report a Bug on http://redmine.named-data.net/projects/ndn-cxx/issues In the bug, please include: - output of "uname -a" command - commit hash, obtained from "git log | head -2" - what commands you are running, and the error message (as text, not screenshot) Yours, Junxiao On Fri, Oct 31, 2014 at 10:49 AM, Wu Chao wrote: > Hi, > I was trying to build ndn-cxx from source on Ubuntu14.04. The configure > and waf were successful. However, the sudo waf install failed since > "Permission Denied". I also have tried install with root but it did not > work. > I include the screen capture of the sudo waf install process. > Regards > Chao > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Fri Oct 31 11:12:44 2014 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Fri, 31 Oct 2014 11:12:44 -0700 Subject: [Nfd-dev] Permission Denied while trying to install ndn-cxx In-Reply-To: <5453CBA3.1030507@us.fujitsu.com> References: <5453CBA3.1030507@us.fujitsu.com> Message-ID: <9B23CE46-5D7E-4228-84C0-ABB6917BEA83@ucla.edu> Hi Chao, Are you building/installing on NFS-mounted disk? From my experience, it has configuration to disallow creating files in the folder as root. If so, try it to do in non-NFS folder (e.g., in /tmp). Also. It seems that installation succeeded... Though it is a little weird that it triggered the error at the end. --- Alex > On Oct 31, 2014, at 10:49 AM, Wu Chao wrote: > > Hi, > I was trying to build ndn-cxx from source on Ubuntu14.04. The configure > and waf were successful. However, the sudo waf install failed since > "Permission Denied". I also have tried install with root but it did not > work. > I include the screen capture of the sudo waf install process. > Regards > Chao From alexander.afanasyev at UCLA.EDU Fri Oct 31 11:34:09 2014 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Fri, 31 Oct 2014 11:34:09 -0700 Subject: [Nfd-dev] Building NFD on Windows In-Reply-To: References: Message-ID: <5C62870D-B696-4CB7-B345-0D256FE5E8F2@ucla.edu> Anybody wants to try docker for windows? http://docs.docker.com/installation/windows/ ?-- Alex > On Oct 31, 2014, at 10:59 AM, Junxiao Shi wrote: > > Hi Jeff > > Windows Server 2008 contains Windows Services for UNIX. > There's a possibility of running NFD natively on Windows without major changes to the code > > If you haven't purchased the hardware, the CPU is likely to have VT-X because every CPU produced in recently years support it. > So the alternate is to install a minimal Ubuntu VM in VirtualBox, expose its TCP port, and make Windows applications connect to it. > The performance penalty due to virtualization is less than 5%. > Deployment cost isn't necessarily higher, because it could be automated. (reference: BOINC VM jobs) > > Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.pesavento at lip6.fr Fri Oct 31 11:36:36 2014 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Fri, 31 Oct 2014 19:36:36 +0100 Subject: [Nfd-dev] Building NFD on Windows In-Reply-To: References: Message-ID: Junxiao, The first and potentially biggest problem I see is the compiler. What compiler do you (have to) use to build a SUA-based application for Windows? Thanks, Davide On Fri, Oct 31, 2014 at 6:59 PM, Junxiao Shi wrote: > Hi Jeff > > Windows Server 2008 contains Windows Services for UNIX. > There's a possibility of running NFD natively on Windows without major > changes to the code > > If you haven't purchased the hardware, the CPU is likely to have VT-X > because every CPU produced in recently years support it. > So the alternate is to install a minimal Ubuntu VM in VirtualBox, expose its > TCP port, and make Windows applications connect to it. > The performance penalty due to virtualization is less than 5%. > Deployment cost isn't necessarily higher, because it could be automated. > (reference: BOINC VM jobs) > > Yours, Junxiao > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From shijunxiao at email.arizona.edu Fri Oct 31 14:39:56 2014 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 31 Oct 2014 14:39:56 -0700 Subject: [Nfd-dev] Building NFD on Windows In-Reply-To: References: Message-ID: Hi Jeff 20141031 conference call discussed this topic. Some opinions are: Docker for Windows is a possibility. Although it's virtualization based and not native Windows program, it should be sufficient if it gives reasonable performance. As long as the socket is accessible, Windows applications can connect to it, without knowing whether it's virtualized. Windows Services for UNIX is only available on Windows Server and high-end Desktop editions. Cross-compiling with CygWin is more attractive because it can reach larger user base. The difficulty of either cross-compiling is expected to be at the same level of Android cross-compiling, and code changes may be inevitable. This work should be assigned to a contributor, instead of core NFD developers, because it's relatively independent. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From beichuan.zhang at gmail.com Fri Oct 31 14:47:27 2014 From: beichuan.zhang at gmail.com (Beichuan Zhang) Date: Fri, 31 Oct 2014 14:47:27 -0700 Subject: [Nfd-dev] Building NFD on Windows In-Reply-To: References: Message-ID: Felix did the docker image and vagrant for NFD. https://github.com/named-data-education/ndn-with-docker https://github.com/named-data-education/ndn-with-vagrant I think it?s a cheap and quick way to get NFD running on Windows, though we haven?t tested it. Beichuan > On Oct 31, 2014, at 2:39 PM, Junxiao Shi wrote: > > Hi Jeff > > 20141031 conference call discussed this topic. > Some opinions are: > > Docker for Windows is a possibility. > Although it's virtualization based and not native Windows program, it should be sufficient if it gives reasonable performance. > As long as the socket is accessible, Windows applications can connect to it, without knowing whether it's virtualized. > > Windows Services for UNIX is only available on Windows Server and high-end Desktop editions. > Cross-compiling with CygWin is more attractive because it can reach larger user base. > The difficulty of either cross-compiling is expected to be at the same level of Android cross-compiling, and code changes may be inevitable. > > This work should be assigned to a contributor, instead of core NFD developers, because it's relatively independent. > > Yours, Junxiao > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Fri Oct 31 21:55:24 2014 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Sat, 1 Nov 2014 04:55:24 +0000 Subject: [Nfd-dev] Building NFD on Windows In-Reply-To: Message-ID: Hi Junxiao & all, Thanks. We can try one of the virtualization options suggested initially and see how performance goes. Jeff From: Junxiao Shi > Date: Fri, 31 Oct 2014 14:39:56 -0700 To: Jeff Burke > Cc: "nfd-dev at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] Building NFD on Windows Hi Jeff 20141031 conference call discussed this topic. Some opinions are: Docker for Windows is a possibility. Although it's virtualization based and not native Windows program, it should be sufficient if it gives reasonable performance. As long as the socket is accessible, Windows applications can connect to it, without knowing whether it's virtualized. Windows Services for UNIX is only available on Windows Server and high-end Desktop editions. Cross-compiling with CygWin is more attractive because it can reach larger user base. The difficulty of either cross-compiling is expected to be at the same level of Android cross-compiling, and code changes may be inevitable. This work should be assigned to a contributor, instead of core NFD developers, because it's relatively independent. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: