From shijunxiao at email.arizona.edu Fri Jul 1 08:56:15 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 1 Jul 2016 08:56:15 -0700 Subject: [Nfd-dev] Help needed with debugging duplicate Nonce In-Reply-To: References: <57716ff0.0617620a.1b687.2b5e@mx.google.com>

, Message-ID: <5776929d.aa41420a.8c48f.05cf@mx.google.com> Hi Ashlesh The unusual thing, as you tagged in sync-interest-trail, is ?not sure what triggers A here?. I looked at A?s nfd.log and pieced together the changes on PIT entry. >From A?s point of view, face261 is the local app, face262 is B, face263 is C. Incoming+outgoing Interests, and PIT entry contents are as follows: 52.39 from=C=4168 to=app PIT in=[C=4168 at 52.39] out=[app at 52.39] 52.72 from=B=6605 PIT in=[C=4168 at 52.39,B=6605 at 52.72] out=[app at 52.39] 52.74 from=app=7385 to=B,C PIT in=[C=4168 at 52.39,B=6605 at 52.72,app=7385 at 52.74] out=[app at 52.39,B at 52.74,C at 52.74] 56.39 PIT in=[B=6605 at 52.72,app=7385 at 52.74]+expired[C=4168 at 52.39] out=[B at 52.74,C at 52.74]+expired[app at 52.39] 56.72 PIT in=[app=7385 at 52.74]+expired[C=4168 at 52.39,B=6605 at 52.72] out=[B at 52.74,C at 52.74]+expired[app at 52.39] 56.74 Interest unsatisfied, PIT erased 56.89 from=C=0641 to=app PIT in=[C=0641 at 56.89] out=[app at 56.89] 56.90 from=app=7567 to=B,C PIT in=[C=0641 at 56.89,app=7567 at 56.90] out=[app at 56.89,B at 56.90,C at 56.90] 57.06 from=B=1547 PIT in=[C=0641 at 56.89,app=7567 at 56.90,B=1547 at 57.06] out=[app at 56.89,B at 56.90,C at 56.90] 60.89 PIT in=[app=7567 at 56.90,B=1547 at 57.06]+expired[C=0641 at 56.89] out=[B at 56.90,C at 56.90]+expired[app at 56.89] 60.90 PIT in=[B=1547 at 57.06]+expired[C=0641 at 56.89,app=7567 at 56.90] out=[]+expired[app at 56.89,B at 56.90,C at 56.90] 61.05 from=C=6600 to=app,B,C PIT in=[B=1547 at 57.06,C=6600 at 61.05]+expired[app=7567 at 56.90] out=[app at 61.05,B at 61.05,C at 61.05] Time is represented with last two digits of integral part and first two digits of fractional part. Nonce is represented with last four digits. PIT in-record is represented as =@. PIT out-record is represented as @. The PIT entry has been erased at 56.74, so anything before that does not affect the later part. At 61.05, an Interest with nonce 6600 is received from C. Before processing this Interest, the PIT entry has one unexpired in-record from B which has nonce 1547 and was created at 57.06; all out-records have been expired. This Interest is forwarded with nonce 6600 to both app and B. Since the PIT entry indicates B still wants the Data, the strategy also forwards the Interest with nonce 1547 (which came from B at 57.06) back to C. While this may not be the best idea for multicast strategy, and using a nonce from non-local-app may be problematic with /localhop, this forwarding is valid in general: nonce 1547 has never been forwarded earlier, and downstream B still wants the Data, so the strategy can certainly forward the Interest to C using this nonce. If all you see is Nack-Duplicate, but application can still retrieve Data normally, don?t worry about that. The root cause of having Nack-Duplicates is that the topology contains a cycle. Also, in general case, ChronoSync should not use /localhop, because it?s possible that two participants are not directly connected. Yours, Junxiao From: Ashlesh Gawande (agawande) Sent: Wednesday, June 29, 2016 13:24 To: Junxiao Shi Cc: Lan Wang (lanwang); nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce Okay, so I performed a new experiment (i.e. just ran minindn and quit after some time) with FibManager and Forwarder DEBUG logs. In this experiment, looked at the first Duplicate NACK on localhop prefix (Nonce: 567161547) and found the following: 1) b->a 2) b->c 3) a->c 4) c sends Duplicate NACK This happens around 1467225861 - I don't see any FibManager messages around this time in NFD logs. I have attached a sync interest trail where I grepped for the particular sync interest such as: grep "/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce" */ndndump* | sort -t: -nk2 | awk '{split($NF,a,"Nonce="); $NF=""; print $0 " " a[2]}' > sync-interest-trail (ndndump* includes localhost as well as interface) Seems like before the NACK, a sends interests with two different Nonces - one to c (which resulted in the above NACK), one to b (resulted in another NACK). This time I didn't see any local new interest for the sync on a? (which should be equivalent to b from the previous example). Ashlesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at remap.ucla.edu Sun Jul 3 18:47:59 2016 From: peter at remap.ucla.edu (Gusev, Peter) Date: Mon, 4 Jul 2016 01:47:59 +0000 Subject: [Nfd-dev] nfd segmentation fault Message-ID: Hi all, After some manipulations with the system (don?t recall what exactly - moving around boost libraries, updating to El Captain, re-installing ndn-cxx) I no longer can launch NFD: nfd-start /usr/local/bin/ndnsec-install-cert: line 4: 54673 Segmentation fault: 11 (core dumped) `dirname "$0"`/ndnsec cert-install "$@" /usr/local/bin/ndnsec-keygen: line 4: 54674 Segmentation fault: 11 (core dumped) `dirname "$0"`/ndnsec key-gen "$@" $ nfd --version Segmentation fault: 11 $ ndnsec version 0.4.1 $ ndnsec list Segmentation fault: 11 Tried to revert changes (migrated Ports to El Captain, making sure boost libraries are in /opt/local/lib, rebuilt/reinstalled ndn-cxx-0.4.1 and NFD-0.4.1), with no effect - still the same problem. Before digging deeper, just wanted to check-in with people in this mailing list, whether they experienced anything like this before. Here?s the core dump from the "nfd-start? crash: * thread #1: tid = 0x0000, 0x00007fff8f531638 libc++.1.dylib`std::__1::basic_string, std::__1::allocator >::operator=(std::__1::basic_string, std::__1::allocator > const&) + 14, stop reason = signal SIGSTOP * frame #0: 0x00007fff8f531638 libc++.1.dylib`std::__1::basic_string, std::__1::allocator >::operator=(std::__1::basic_string, std::__1::allocator > const&) + 14 frame #1: 0x0000000107c6f411 nfd`boost::program_options::typed_value, std::__1::allocator >, char>::notify(boost::any const&) const + 97 frame #2: 0x0000000108156319 libboost_program_options-mt.dylib`boost::program_options::store(boost::program_options::basic_parsed_options const&, boost::program_options::variables_map&, bool) + 1353 frame #3: 0x0000000107c6332d nfd`main + 493 frame #4: 0x00007fff8f8a25ad libdyld.dylib`start + 1 frame #5: 0x00007fff8f8a25ad libdyld.dylib`start + 1 Possibly, something with libc++/libstdc++ libraries mismatch... Thanks, -- Peter Gusev peter at remap.ucla.edu +1 213 5872748 peetonn_ (skype) Software Engineer/Programmer Analyst @ REMAP UCLA Video streaming/ICN networks/Creative Development -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun Jul 3 18:56:49 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 3 Jul 2016 18:56:49 -0700 Subject: [Nfd-dev] nfd segmentation fault In-Reply-To: References: Message-ID: <5779c25e.c46d620a.43994.1273@mx.google.com> Hi Peter Try these aggressive but usually helpful repair steps: 1. backup NDN certificates, configurations, repo-ng contents if you can 2. delete ndn-cxx and NFD and ndn-tools; check for /etc/ndn, /usr/bin, /usr/local/bin, /usr/local/etc/ndn, /opt/local, /var/log/ndn directories for any remains 3. delete cloned ndn-cxx and NFD and ndn-tools repositories 4. uninstall MacPorts and HomeBrew, delete all ports and packages 5. in Keychain Access app, delete all NDN certificates 6. shutdown the machine, unplug the power, wait 30 minutes 7. plug in the machine and start the system 8. install HomeBrew only (MacPorts is supported but the strange paths sometimes cause problems) 9. clone ndn-cxx and NFD and ndn-tools from Gerrit (not GitHub), see instructions http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2015-April/001023.html 10. carefully follow installation instructions of each software; do not skip any step Yours, Junxiao From: Gusev, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at remap.ucla.edu Sun Jul 3 21:56:50 2016 From: peter at remap.ucla.edu (Gusev, Peter) Date: Mon, 4 Jul 2016 04:56:50 +0000 Subject: [Nfd-dev] nfd segmentation fault In-Reply-To: <5779c25e.c46d620a.43994.1273@mx.google.com> References: <5779c25e.c46d620a.43994.1273@mx.google.com> Message-ID: <5AD7103B-1120-44FF-81F3-433C4E4C8DF3@remap.ucla.edu> Hi Junxiao, Uninstalling ports and using just homebrew for dependencies helped. I also cloned repos from gerrit. Thanks, -- Peter Gusev peter at remap.ucla.edu +1 213 5872748 peetonn_ (skype) Software Engineer/Programmer Analyst @ REMAP UCLA Video streaming/ICN networks/Creative Development On Jul 3, 2016, at 6:56 PM, Junxiao Shi > wrote: Hi Peter Try these aggressive but usually helpful repair steps: 1. backup NDN certificates, configurations, repo-ng contents if you can 2. delete ndn-cxx and NFD and ndn-tools; check for /etc/ndn, /usr/bin, /usr/local/bin, /usr/local/etc/ndn, /opt/local, /var/log/ndn directories for any remains 3. delete cloned ndn-cxx and NFD and ndn-tools repositories 4. uninstall MacPorts and HomeBrew, delete all ports and packages 5. in Keychain Access app, delete all NDN certificates 6. shutdown the machine, unplug the power, wait 30 minutes 7. plug in the machine and start the system 8. install HomeBrew only (MacPorts is supported but the strange paths sometimes cause problems) 9. clone ndn-cxx and NFD and ndn-tools from Gerrit (not GitHub), see instructions http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2015-April/001023.html 10. carefully follow installation instructions of each software; do not skip any step Yours, Junxiao From: Gusev, Peter Sent: Sunday, July 3, 2016 18:48 To:

Subject: [Nfd-dev] nfd segmentation fault Hi all, After some manipulations with the system (don?t recall what exactly - moving around boost libraries, updating to El Captain, re-installing ndn-cxx) I no longer can launch NFD: nfd-start /usr/local/bin/ndnsec-install-cert: line 4: 54673 Segmentation fault: 11 (core dumped) `dirname "$0"`/ndnsec cert-install "$@" /usr/local/bin/ndnsec-keygen: line 4: 54674 Segmentation fault: 11 (core dumped) `dirname "$0"`/ndnsec key-gen "$@" $ nfd --version Segmentation fault: 11 $ ndnsec version 0.4.1 $ ndnsec list Segmentation fault: 11 Tried to revert changes (migrated Ports to El Captain, making sure boost libraries are in /opt/local/lib, rebuilt/reinstalled ndn-cxx-0.4.1 and NFD-0.4.1), with no effect - still the same problem. Before digging deeper, just wanted to check-in with people in this mailing list, whether they experienced anything like this before. Here?s the core dump from the "nfd-start? crash: * thread #1: tid = 0x0000, 0x00007fff8f531638 libc++.1.dylib`std::__1::basic_string, std::__1::allocator >::operator=(std::__1::basic_string, std::__1::allocator > const&) + 14, stop reason = signal SIGSTOP * frame #0: 0x00007fff8f531638 libc++.1.dylib`std::__1::basic_string, std::__1::allocator >::operator=(std::__1::basic_string, std::__1::allocator > const&) + 14 frame #1: 0x0000000107c6f411 nfd`boost::program_options::typed_value, std::__1::allocator >, char>::notify(boost::any const&) const + 97 frame #2: 0x0000000108156319 libboost_program_options-mt.dylib`boost::program_options::store(boost::program_options::basic_parsed_options const&, boost::program_options::variables_map&, bool) + 1353 frame #3: 0x0000000107c6332d nfd`main + 493 frame #4: 0x00007fff8f8a25ad libdyld.dylib`start + 1 frame #5: 0x00007fff8f8a25ad libdyld.dylib`start + 1 Possibly, something with libc++/libstdc++ libraries mismatch... Thanks, -- Peter Gusev peter at remap.ucla.edu +1 213 5872748 peetonn_ (skype) Software Engineer/Programmer Analyst @ REMAP UCLA Video streaming/ICN networks/Creative Development -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Jul 4 17:53:52 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 4 Jul 2016 17:53:52 -0700 Subject: [Nfd-dev] namespace-based strategy choice weakness Message-ID: Dear folks NFD adopts a namespace-based strategy choice: for an incoming Interest that needs to be forwarded, the forwarding strategy responsible for making forwarding decisions of this Interest is identified by a longest prefix match on the strategy choice table. For example, Arizona router has its strategy choice table configured as follows: - / => best-route v4 - /ndn/multicast => multicast v1 - /ndn/edu/arizona => access v1 - (other entries omitted) Interest /ndn/edu/ucla/ping/1 matches / entry and will be handled by best-route strategy. Interest /ndn/edu/arizona/cs/shijunxiao/ping/2 matches /ndn/edu/arizona entry and will be handled by access strategy. This namespace-based strategy choice allows a network operator to configure different strategies for different kinds of links. In the above Arizona router example, /ndn/edu/arizona is the local site prefix that covers all end hosts connected to Arizona router (typically via UDP tunnels), and access strategy is designed for this kind of last hop UDP tunnels. The default strategy, configured on / entry, is set to best-route v4, which is designed for forwarding Interests over multiple hops on the global backbone network. However, *namespace-based strategy choice offers very limited support for tailoring the strategy choice based on application needs*. Currently, NFD only has a handful of strategies. The "smart" ones (best-route, access, ncc) all optimize for the same goal: minimize round-trip delay. In the future, especially with the development in congestion control, NFD is likely to have more strategies with different optimization goals: some strategies can minimize round-trip delay, and some other strategies can maximize throughput. Different application scenarios can benefit from different strategy choices: a real-time video conferencing application wants lower delay but can tolerate smaller throughput as long as it's enough for receiving the lowest video quality, and wants to toss any Data that cannot arrive before the playout deadline; a file downloading application prefers higher throughput; a backup application can give more emphasize on minimizing monetary cost as long as the backup can complete overnight. In the current namespace-based strategy choice, *it's hard to configure different strategies to different applications*. Since we mandate every user to have a testbed certificate and use automatic prefix propagation to register prefixes toward end hosts, the only name structure applications can use is to have the user identity before application name, such as /ndn/edu/arizona/cs/shijunxiao/ndncon. Suppose ndncon wants to set a different strategy than the access strategy in /ndn/edu/arizona entry, it would *have to create a separate strategy choice entry for each user*'s ndncon sub-namespace. In other words, the Arizona router would end up with a strategy choice table that looks like this: - /ndn/edu/arizona/cs/shijunxiao/ndncon => realtime - /ndn/edu/arizona/cs/bzhang/ndncon => realtime - /ndn/edu/arizona/cs/zhuoli/ndncon => realtime - (repeat for every other user) This is certainly not scalable. Also, if we want to realtime strategy to be applied on other routers, every router in the backbone network needs to have these strategy choice entries. #2054-6 was a hassle similar to this. If we change the name structure to have the application name before the user identity (let's forget about automatic prefix propagation for now), we could have a name like /ndncon/ndn/edu/arizona/cs/shijunxiao. In this case, we only need one strategy choice entry for each application: - /ndncon => realtime - /ndnfs => high-throughput But it's a disaster for FIB. Our FIB would look like this: - /ndncon/ndn/edu/arizona/cs/shijunxiao => Junxiao's end host - /ndncon/ndn/edu/arizona/cs/bzhang => Beichuan's end host - /ndncon/ndn/edu/arizona/cs/zhuoli => Zhuo's end host - /ndnfs/ndn/edu/arizona/cs/shijunxiao => Junxiao's end host - /ndnfs/ndn/edu/arizona/cs/bzhang => Beichuan's end host - /ndnfs/ndn/edu/arizona/cs/zhuoli => Zhuo's end host - (repeat for every other application) And this also affects the global routing system. It would need multiple entries toward each site, like: - /ndncon/ndn/edu/arizona => nexthop toward Arizona - /ndnfs/ndn/edu/arizona => nexthop toward Arizona - (repeat for every other application) Therefore, *changing the name structure as application name before user identity causes scalability issue* in FIB and routing, and thus is not a viable solution. We have identified several alternate design ideas for strategy choice. NFD can *choose effective strategy from a marked component*. Instead of doing longest prefix match in the strategy choice table, a strategy choice entry can indicate: - contains "app=ndncon" => realtime - contains "app=ndnfs" => high-throughput The first entry can match any incoming Interest that contains "app=ndncon" as one of the name components, and choose realtime strategy for such traffic. It's necessary to use a marked component (see #2012 ) rather than a generic name component "ndncon", because only a marked component can identify the Interest is indeed ndncon traffic. Using a generic name component would match an Interest like /github/remap/ndncon/v0.7.7/ndncon.app which is the binary package of ndncon but not actual ndncon traffic. This should be used in conjunction with namespace-based strategy choice, because choosing a strategy based on link properties is also a useful feature. A weakness of the first idea is that the strategy choice is still based on the name. However, sometimes a different strategy may be preferred based on what the consumer is doing. ndncon is normally a realtime video conferencing application. It requires very low delay, and any Data that cannot be delivered before playout deadline can be tossed because they won't be played if they arrive late. However, suppose there's a video recording consumer that wants to record a high quality video stream from ndncon. Assuming a local repo-ng is deployed alongside ndncon producer, there would be no rush for the video recording consumer to receive the Data packet. In this case, this consumer would prefer a strategy that offers high throughput, and does not want any late arriving Data to be tossed. To support this use case, *an Interest can carry a strategy choice field*. NFD can choose a strategy according to this field. We could either put a strategy name into this field and let NFD retrieve the strategy program, or put some generic preferences in this field and let NFD pick a strategy that best matches those preferences. The bandwidth overhead of this field is less of a concern, because it would be much smaller than a Link object. A major challenge in this second idea is that it's unclear which strategy would be used if Interests sharing the same PIT entry from different consumers are asking for different strategies. It's certainly undesirable to split into multiple PIT entries based of different strategy choice and send packets multiple times. The above do not conflict with composable strategy building blocks (#2000 ) or composable forwarding plane. That just allows a different way to express strategy choice: instead of using a table, composable forwarding uses a script or flowchart to select a strategy behavior. The above do not conflict with expressing strategy choice through routing protocols. That just allows a different way to install entries into strategy choice table. One relation is that the strategy choice field in Interest can have the same format as how strategy choice is represented in routing announcements. The above content is extended a recap from my discussion with Zhuo Li, a new developer at Arizona that will work on forwarding. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From susmit at cs.colostate.edu Mon Jul 4 18:15:18 2016 From: susmit at cs.colostate.edu (Susmit) Date: Mon, 4 Jul 2016 19:15:18 -0600 Subject: [Nfd-dev] namespace-based strategy choice weakness In-Reply-To: References: Message-ID: > > NFD can choose effective strategy from a marked component. > Instead of doing longest prefix match in the strategy choice table, a > strategy choice entry can indicate: > > contains "app=ndncon" => realtime > contains "app=ndnfs" => high-throughput Two questions, a) Who is responsible for configuring strategies? Operators or users? Should users be responsible for finding optimal stategies in the network? b) How are we going to stop people from mislabeling Interests? Hypothetically speaking, If web search strategy is "normal-throughput", pages will load faster if they are labeled "high-throughput". Thanks. -- Regards, Susmit ==================================== http://www.cs.colostate.edu/~susmit ==================================== From lanwang at memphis.edu Tue Jul 5 05:06:30 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Tue, 5 Jul 2016 12:06:30 +0000 Subject: [Nfd-dev] namespace-based strategy choice weakness In-Reply-To: References: Message-ID: <32C07322-7F65-4078-A1DD-F31F4B2E7C28@memphis.edu> How about the following naming scheme? /ndn/edu/arizona/cs/app so strategies can be configured per app if needed, e.g., /ndn/edu/arizona/cs => access v1 /ndn/edu/arizona/cs/ndncon => realtime /ndn/edu/arizona/cs/nfs => highthroughput FIB can contain only one record: /ndn/edu/arizona/cs Lan On Jul 4, 2016, at 7:53 PM, Junxiao Shi > wrote: Dear folks NFD adopts a namespace-based strategy choice: for an incoming Interest that needs to be forwarded, the forwarding strategy responsible for making forwarding decisions of this Interest is identified by a longest prefix match on the strategy choice table. For example, Arizona router has its strategy choice table configured as follows: * / => best-route v4 * /ndn/multicast => multicast v1 * /ndn/edu/arizona => access v1 * (other entries omitted) Interest /ndn/edu/ucla/ping/1 matches / entry and will be handled by best-route strategy. Interest /ndn/edu/arizona/cs/shijunxiao/ping/2 matches /ndn/edu/arizona entry and will be handled by access strategy. This namespace-based strategy choice allows a network operator to configure different strategies for different kinds of links. In the above Arizona router example, /ndn/edu/arizona is the local site prefix that covers all end hosts connected to Arizona router (typically via UDP tunnels), and access strategy is designed for this kind of last hop UDP tunnels. The default strategy, configured on / entry, is set to best-route v4, which is designed for forwarding Interests over multiple hops on the global backbone network. However, namespace-based strategy choice offers very limited support for tailoring the strategy choice based on application needs. Currently, NFD only has a handful of strategies. The "smart" ones (best-route, access, ncc) all optimize for the same goal: minimize round-trip delay. In the future, especially with the development in congestion control, NFD is likely to have more strategies with different optimization goals: some strategies can minimize round-trip delay, and some other strategies can maximize throughput. Different application scenarios can benefit from different strategy choices: a real-time video conferencing application wants lower delay but can tolerate smaller throughput as long as it's enough for receiving the lowest video quality, and wants to toss any Data that cannot arrive before the playout deadline; a file downloading application prefers higher throughput; a backup application can give more emphasize on minimizing monetary cost as long as the backup can complete overnight. In the current namespace-based strategy choice, it's hard to configure different strategies to different applications. Since we mandate every user to have a testbed certificate and use automatic prefix propagation to register prefixes toward end hosts, the only name structure applications can use is to have the user identity before application name, such as /ndn/edu/arizona/cs/shijunxiao/ndncon. Suppose ndncon wants to set a different strategy than the access strategy in /ndn/edu/arizona entry, it would have to create a separate strategy choice entry for each user's ndncon sub-namespace. In other words, the Arizona router would end up with a strategy choice table that looks like this: * /ndn/edu/arizona/cs/shijunxiao/ndncon => realtime * /ndn/edu/arizona/cs/bzhang/ndncon => realtime * /ndn/edu/arizona/cs/zhuoli/ndncon => realtime * (repeat for every other user) This is certainly not scalable. Also, if we want to realtime strategy to be applied on other routers, every router in the backbone network needs to have these strategy choice entries. #2054-6 was a hassle similar to this. If we change the name structure to have the application name before the user identity (let's forget about automatic prefix propagation for now), we could have a name like /ndncon/ndn/edu/arizona/cs/shijunxiao. In this case, we only need one strategy choice entry for each application: * /ndncon => realtime * /ndnfs => high-throughput But it's a disaster for FIB. Our FIB would look like this: * /ndncon/ndn/edu/arizona/cs/shijunxiao => Junxiao's end host * /ndncon/ndn/edu/arizona/cs/bzhang => Beichuan's end host * /ndncon/ndn/edu/arizona/cs/zhuoli => Zhuo's end host * /ndnfs/ndn/edu/arizona/cs/shijunxiao => Junxiao's end host * /ndnfs/ndn/edu/arizona/cs/bzhang => Beichuan's end host * /ndnfs/ndn/edu/arizona/cs/zhuoli => Zhuo's end host * (repeat for every other application) And this also affects the global routing system. It would need multiple entries toward each site, like: * /ndncon/ndn/edu/arizona => nexthop toward Arizona * /ndnfs/ndn/edu/arizona => nexthop toward Arizona * (repeat for every other application) Therefore, changing the name structure as application name before user identity causes scalability issue in FIB and routing, and thus is not a viable solution. We have identified several alternate design ideas for strategy choice. NFD can choose effective strategy from a marked component. Instead of doing longest prefix match in the strategy choice table, a strategy choice entry can indicate: * contains "app=ndncon" => realtime * contains "app=ndnfs" => high-throughput The first entry can match any incoming Interest that contains "app=ndncon" as one of the name components, and choose realtime strategy for such traffic. It's necessary to use a marked component (see #2012) rather than a generic name component "ndncon", because only a marked component can identify the Interest is indeed ndncon traffic. Using a generic name component would match an Interest like /github/remap/ndncon/v0.7.7/ndncon.app which is the binary package of ndncon but not actual ndncon traffic. This should be used in conjunction with namespace-based strategy choice, because choosing a strategy based on link properties is also a useful feature. A weakness of the first idea is that the strategy choice is still based on the name. However, sometimes a different strategy may be preferred based on what the consumer is doing. ndncon is normally a realtime video conferencing application. It requires very low delay, and any Data that cannot be delivered before playout deadline can be tossed because they won't be played if they arrive late. However, suppose there's a video recording consumer that wants to record a high quality video stream from ndncon. Assuming a local repo-ng is deployed alongside ndncon producer, there would be no rush for the video recording consumer to receive the Data packet. In this case, this consumer would prefer a strategy that offers high throughput, and does not want any late arriving Data to be tossed. To support this use case, an Interest can carry a strategy choice field. NFD can choose a strategy according to this field. We could either put a strategy name into this field and let NFD retrieve the strategy program, or put some generic preferences in this field and let NFD pick a strategy that best matches those preferences. The bandwidth overhead of this field is less of a concern, because it would be much smaller than a Link object. A major challenge in this second idea is that it's unclear which strategy would be used if Interests sharing the same PIT entry from different consumers are asking for different strategies. It's certainly undesirable to split into multiple PIT entries based of different strategy choice and send packets multiple times. The above do not conflict with composable strategy building blocks (#2000) or composable forwarding plane. That just allows a different way to express strategy choice: instead of using a table, composable forwarding uses a script or flowchart to select a strategy behavior. The above do not conflict with expressing strategy choice through routing protocols. That just allows a different way to install entries into strategy choice table. One relation is that the strategy choice field in Interest can have the same format as how strategy choice is represented in routing announcements. The above content is extended a recap from my discussion with Zhuo Li, a new developer at Arizona that will work on forwarding. 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 nfd-call-notification at mail1.yoursunny.com Tue Jul 5 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 5 Jul 2016 07:00:02 -0700 Subject: [Nfd-dev] NFD call 20160705 Message-ID: <201607051400.u65E02uG025109@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Jul 5 13:56:42 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 5 Jul 2016 13:56:42 -0700 Subject: [Nfd-dev] namespace-based strategy choice weakness In-Reply-To: References:

Message-ID: Hi Susmit a) This question is orthogonal to my post. I'm talking about *what* goes into the strategy choice table and how are the entries interpreted, not *where* those entries come from. Today it's a local configuration by admin of each router / end host. "expressing strategy choice through routing protocols" is a different idea under discussion. b) Each strategy optimizes for a different goal, such as lower delay, higher throughput. It does not prioritize traffic of one application over another. If you mislabel web traffic as download traffic, you get higher throughput but possibly more delay so navigation actions are less responsive. Yours, Junxiao On Mon, Jul 4, 2016 at 6:15 PM, Susmit wrote: > > > > NFD can choose effective strategy from a marked component. > > Instead of doing longest prefix match in the strategy choice table, a > > strategy choice entry can indicate: > > > > contains "app=ndncon" => realtimeI' > > contains "app=ndnfs" => high-throughput > > Two questions, > > a) Who is responsible for configuring strategies? Operators or users? > Should users be responsible for finding optimal stategies in the > network? > > b) How are we going to stop people from mislabeling Interests? > Hypothetically speaking, If web search strategy is > "normal-throughput", pages will load faster if they are labeled > "high-throughput". > > Thanks. > > -- > > Regards, > Susmit > > ==================================== > http://www.cs.colostate.edu/~susmit > ==================================== > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Jul 5 16:13:51 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 5 Jul 2016 16:13:51 -0700 Subject: [Nfd-dev] namespace-based strategy choice weakness In-Reply-To: <32C07322-7F65-4078-A1DD-F31F4B2E7C28@memphis.edu> References: <32C07322-7F65-4078-A1DD-F31F4B2E7C28@memphis.edu> Message-ID: <577c3f2b.949b620a.618fe.06d0@mx.google.com> Hi Lan This is what NdnCon was using before #3513. In Oct 2014 we had to change the strategy for NdnCon traffic (#2054-6), and this wasn?t a pleasant experience. On each testbed node, a strategy choice entry is needed for all site prefixes: ? /ndn/edu/arizona/ndncon => realtime ? /ndn/edu/memphis/ndncon => realtime ? /ndn/edu/ucla/ndncon => realtime ? (repeat for every other application and site prefix) And this still causes FIB scalability issue on the local router (but doesn?t affect global routing): ? /ndn/edu/arizona/ndncon/cs/shijunxiao => Junxiao?s machine ? /ndn/edu/arizona/ndnfs/cs/shijunxiao => Junxiao?s machine ? /ndn/edu/arizona/ndncon/cs/bzhang => Beichuan?s machine ? /ndn/edu/arizona/ndnfs/cs/bzhang => Beichuan?s machine ? /ndn/edu/arizona/ndncon/cs/zhuoli => Zhuo?s machine ? /ndn/edu/arizona/ndnfs/cs/zhuoli => Zhuo?s machine ? (repeat for every other application and local user) Yours, Junxiao From: Lan Wang (lanwang) -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus at email.arizona.edu Wed Jul 6 17:36:28 2016 From: klaus at email.arizona.edu (Klaus Schneider) Date: Wed, 6 Jul 2016 17:36:28 -0700 Subject: [Nfd-dev] namespace-based strategy choice weakness In-Reply-To: References:

Message-ID: <577DA40C.80704@email.arizona.edu> Hi Susmit and Junxiao, >> b) >> Each strategy optimizes for a different goal, such as lower delay, >> higher throughput. It does not prioritize traffic of one application >> over another. >> If you mislabel web traffic as download traffic, you get higher >> throughput but possibly more delay so navigation actions are less >> responsive. Yes there is often a trade-off between things like throughput, delay and reliability. This will hopefully minimize the incentive to mislabel the preferred strategy. However, I'm not sure if that works in practice. It can become a problem when some strategies are clearly superior than others, like IP QoS classes ("best-effort", "expedited forwarding", "assured forwarding", etc.) Or if some strategies (like broadcast) create a much higher overhead than others. I like the idea of using a header field for the strategy choice: > > To support this use case, an Interest can carry a strategy choice field. NFD can choose a strategy according to this field. > We could either put a strategy name into this field and let NFD retrieve the strategy program, or put some generic preferences in this field and let NFD pick a strategy that best matches those preferences. > The bandwidth overhead of this field is less of a concern, because it would be much smaller than a Link object. > A major challenge in this second idea is that it's unclear which strategy would be used if Interests sharing the same PIT entry from different consumers are asking for different strategies. It's certainly undesirable to split into multiple PIT entries based of different strategy choice and send packets multiple times. > Maybe use "first come, first serve" (i.e., the first Interest determines the strategy of the PIT entry). Or use some sort of cumulative logic: Let's say the first Interest wants "shortest path", so it is forwarded on the shortest path. A later Interest wants "broadcast", so then it is sent out on the remaining faces. (Just throwing out ideas. I can see a number of problems here, like messing up RTT measurements and overhead). Also, does the strategy choice in the header field determine the strategy of all routers? What if you want "shortest path" on all the routers inside the network, but "access strategy" on the last hop? Best regards, Klaus On 05.07.2016 13:56, Junxiao Shi wrote: > Hi Susmit > > a) > This question is orthogonal to my post. I'm talking about /what/ goes > into the strategy choice table and how are the entries interpreted, not > /where/ those entries come from. > Today it's a local configuration by admin of each router / end host. > "expressing strategy choice through routing protocols" is a different > idea under discussion. > > b) > Each strategy optimizes for a different goal, such as lower delay, > higher throughput. It does not prioritize traffic of one application > over another. > If you mislabel web traffic as download traffic, you get higher > throughput but possibly more delay so navigation actions are less > responsive. > > Yours, Junxiao > > On Mon, Jul 4, 2016 at 6:15 PM, Susmit > wrote: > > > > > NFD can choose effective strategy from a marked component. > > Instead of doing longest prefix match in the strategy choice table, a > > strategy choice entry can indicate: > > > > contains "app=ndncon" => realtimeI' > > contains "app=ndnfs" => high-throughput > > Two questions, > > a) Who is responsible for configuring strategies? Operators or users? > Should users be responsible for finding optimal stategies in the > network? > > b) How are we going to stop people from mislabeling Interests? > Hypothetically speaking, If web search strategy is > "normal-throughput", pages will load faster if they are labeled > "high-throughput". > > Thanks. > > -- > > Regards, > Susmit > > ==================================== > http://www.cs.colostate.edu/~susmit > > ==================================== > > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From nfd-call-notification at mail1.yoursunny.com Thu Jul 7 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 7 Jul 2016 07:00:02 -0700 Subject: [Nfd-dev] NFD call 20160707 Message-ID: <201607071400.u67E02xr000390@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Thu Jul 7 17:20:39 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Fri, 8 Jul 2016 00:20:39 +0000 Subject: [Nfd-dev] Help needed with debugging duplicate Nonce In-Reply-To: <5776929d.aa41420a.8c48f.05cf@mx.google.com> References: <57716ff0.0617620a.1b687.2b5e@mx.google.com>

<5776929d.aa41420a.8c48f.05cf@mx.google.com> Message-ID: <7D17546E-AA1D-4D1C-947A-6DC00216A66F@memphis.edu> Junxiao, I have some questions about the specifics of the example that are best clarified through the nfd call, but here are some high-order questions: - Duplicate NACK is a problem because I think it will affect the pending interest information between the neighbors so their sync data packets won?t be able to propagate in time. What does a node do to its PIT when it sends/receives a duplicate NACK? - /localhop is fine for intradomain routing, because NLSR neighbors are one hop away from each other. But we don?t have to do this if we don?t have the duplicate NACK problem in the first place. - if we do have to use /localhop to remove the duplicate NACKs then we need to make sure that it only propagates one hop (not as implemented now). Lan On Jul 1, 2016, at 10:56 AM, Junxiao Shi > wrote: Hi Ashlesh The unusual thing, as you tagged in sync-interest-trail, is ?not sure what triggers A here?. I looked at A?s nfd.log and pieced together the changes on PIT entry. From A?s point of view, face261 is the local app, face262 is B, face263 is C. Incoming+outgoing Interests, and PIT entry contents are as follows: 52.39 from=C=4168 to=app PIT in=[C=4168 at 52.39] out=[app at 52.39] 52.72 from=B=6605 PIT in=[C=4168 at 52.39,B=6605 at 52.72] out=[app at 52.39] 52.74 from=app=7385 to=B,C PIT in=[C=4168 at 52.39,B=6605 at 52.72,app=7385 at 52.74] out=[app at 52.39,B at 52.74,C at 52.74] 56.39 PIT in=[B=6605 at 52.72,app=7385 at 52.74]+expired[C=4168 at 52.39] out=[B at 52.74,C at 52.74]+expired[app at 52.39] 56.72 PIT in=[app=7385 at 52.74]+expired[C=4168 at 52.39,B=6605 at 52.72] out=[B at 52.74,C at 52.74]+expired[app at 52.39] 56.74 Interest unsatisfied, PIT erased 56.89 from=C=0641 to=app PIT in=[C=0641 at 56.89] out=[app at 56.89] 56.90 from=app=7567 to=B,C PIT in=[C=0641 at 56.89,app=7567 at 56.90] out=[app at 56.89,B at 56.90,C at 56.90] 57.06 from=B=1547 PIT in=[C=0641 at 56.89,app=7567 at 56.90,B=1547 at 57.06] out=[app at 56.89,B at 56.90,C at 56.90] 60.89 PIT in=[app=7567 at 56.90,B=1547 at 57.06]+expired[C=0641 at 56.89] out=[B at 56.90,C at 56.90]+expired[app at 56.89] 60.90 PIT in=[B=1547 at 57.06]+expired[C=0641 at 56.89,app=7567 at 56.90] out=[]+expired[app at 56.89,B at 56.90,C at 56.90] 61.05 from=C=6600 to=app,B,C PIT in=[B=1547 at 57.06,C=6600 at 61.05]+expired[app=7567 at 56.90] out=[app at 61.05,B at 61.05,C at 61.05] Time is represented with last two digits of integral part and first two digits of fractional part. Nonce is represented with last four digits. PIT in-record is represented as =@. PIT out-record is represented as @. The PIT entry has been erased at 56.74, so anything before that does not affect the later part. At 61.05, an Interest with nonce 6600 is received from C. Before processing this Interest, the PIT entry has one unexpired in-record from B which has nonce 1547 and was created at 57.06; all out-records have been expired. This Interest is forwarded with nonce 6600 to both app and B. Since the PIT entry indicates B still wants the Data, the strategy also forwards the Interest with nonce 1547 (which came from B at 57.06) back to C. While this may not be the best idea for multicast strategy, and using a nonce from non-local-app may be problematic with /localhop, this forwarding is valid in general: nonce 1547 has never been forwarded earlier, and downstream B still wants the Data, so the strategy can certainly forward the Interest to C using this nonce. If all you see is Nack-Duplicate, but application can still retrieve Data normally, don?t worry about that. The root cause of having Nack-Duplicates is that the topology contains a cycle. Also, in general case, ChronoSync should not use /localhop, because it?s possible that two participants are not directly connected. Yours, Junxiao From: Ashlesh Gawande (agawande) Sent: Wednesday, June 29, 2016 13:24 To: Junxiao Shi Cc: Lan Wang (lanwang); nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce Okay, so I performed a new experiment (i.e. just ran minindn and quit after some time) with FibManager and Forwarder DEBUG logs. In this experiment, looked at the first Duplicate NACK on localhop prefix (Nonce: 567161547) and found the following: 1) b->a 2) b->c 3) a->c 4) c sends Duplicate NACK This happens around 1467225861 - I don't see any FibManager messages around this time in NFD logs. I have attached a sync interest trail where I grepped for the particular sync interest such as: grep "/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce" */ndndump* | sort -t: -nk2 | awk '{split($NF,a,"Nonce="); $NF=""; print $0 " " a[2]}' > sync-interest-trail (ndndump* includes localhost as well as interface) Seems like before the NACK, a sends interests with two different Nonces - one to c (which resulted in the above NACK), one to b (resulted in another NACK). This time I didn't see any local new interest for the sync on a (which should be equivalent to b from the previous example). Ashlesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Jul 8 07:21:54 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 8 Jul 2016 07:21:54 -0700 Subject: [Nfd-dev] Issue Your Own NDN Certificates Message-ID: Dear folks I've been asked a few times on how to issue sub-certificates from a primary testbed certificate from ndncert, so that you can have a different certificate for each of your devices. Here's an article that describes this procedure: https://yoursunny.com/t/2016/ndncert/ This article introduces NDN's hierarchical trust model, and explains how to issue certificates for your other machines and publish them so that they can use Automatic Prefix Propagation with a distinct prefix for each machine. This article also explains the difference between PKI and NDN's hierarchical trust model, and demonstrates that the authority of your certificate is restricted by your identity name. Procedure about signing certificates and publishing them using repo-ng were collected from: http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000616.html http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2015-March/000904.html Yours, Junxiao On Mon, Jun 27, 2016 at 4:17 AM, Junxiao Shi wrote: > If you are still trying to figure out how to get automated prefix > propagation working, this article shall be useful for you. > https://yoursunny.com/t/2016/nfd-prefix/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hila at wustl.edu Fri Jul 8 21:09:33 2016 From: hila at wustl.edu (Hila Ben Abraham) Date: Sat, 09 Jul 2016 04:09:33 +0000 Subject: [Nfd-dev] namespace-based strategy choice weakness In-Reply-To: <577DA40C.80704@email.arizona.edu> References:

<577DA40C.80704@email.arizona.edu> Message-ID: All, I like the idea of supporting the needs of different applications by adopting a more flexible strategy choice design. I support the idea of adding header fields, but I think that this 'strategy choice' header should be used to better represent application needs rather than a specific strategy name or a strategy metric. In the last few months, we have been exploring conflicts between applications and forwarding strategies. We implemented an additional Interest header to support a more flexible in-network retransmission mechanism, since we found it to be a core mechanism that can impact both correctness and performance of some applications. This is still work in progress, but preliminary details can be found here: http://openscholarship.wustl.edu/cse_research/910 http://dl.acm.org/citation.cfm?id=2889475 As Junxiao mentioned, all the current "smart" strategies optimize for a minimal round-trip delay. However, each strategy achieves this goal using a different implementation. To ensure a correct behavior, the application developer sometimes has to couple the application specifics to the details of the selected forwarding strategy. For instance, the application must understand that ncc retransmits unsatisfied Interests on available faces while best-route requires application's retransmission to try additional faces. Moreover, if the suppression timer of best-route changes between revisions, a matching change might be required in the application code to support the change. Therefore, the application code is somewhat coupled with the strategy details. This creates challenges in shared resource environments as the NDN testbed, when multiple applications use the same strategy. Therefore, I think that any new 'strategy choice' design should simplify and support application-specific needs. To add to what Susmit asked, I understand why the question of who is responsible for configuring strategy choice seems orthogonal, but I do think that the answer to '*who* is responsible' will determine '*what* to configure'. Is the goal of this new 'strategy choice' to have a more scalable configuration mechanism? Is it to provide a better support for the operator when choosing strategies according to congestion and other network issues? Or is it to allow applications-specific needs? Hila On Wed, Jul 6, 2016 at 7:37 PM Klaus Schneider wrote: > Hi Susmit and Junxiao, > > >> b) > >> Each strategy optimizes for a different goal, such as lower delay, > >> higher throughput. It does not prioritize traffic of one application > >> over another. > >> If you mislabel web traffic as download traffic, you get higher > >> throughput but possibly more delay so navigation actions are less > >> responsive. > > Yes there is often a trade-off between things like throughput, delay and > reliability. This will hopefully minimize the incentive to mislabel the > preferred strategy. > > However, I'm not sure if that works in practice. It can become a problem > when some strategies are clearly superior than others, like IP QoS > classes ("best-effort", "expedited forwarding", "assured forwarding", etc.) > > Or if some strategies (like broadcast) create a much higher overhead > than others. > > > I like the idea of using a header field for the strategy choice: > > > > > To support this use case, an Interest can carry a strategy choice field. > NFD can choose a strategy according to this field. > > We could either put a strategy name into this field and let NFD retrieve > the strategy program, or put some generic preferences in this field and let > NFD pick a strategy that best matches those preferences. > > The bandwidth overhead of this field is less of a concern, because it > would be much smaller than a Link object. > > A major challenge in this second idea is that it's unclear which > strategy would be used if Interests sharing the same PIT entry from > different consumers are asking for different strategies. It's certainly > undesirable to split into multiple PIT entries based of different strategy > choice and send packets multiple times. > > > > Maybe use "first come, first serve" (i.e., the first Interest determines > the strategy of the PIT entry). > > Or use some sort of cumulative logic: Let's say the first Interest wants > "shortest path", so it is forwarded on the shortest path. A later > Interest wants "broadcast", so then it is sent out on the remaining > faces. (Just throwing out ideas. I can see a number of problems here, > like messing up RTT measurements and overhead). > > Also, does the strategy choice in the header field determine the > strategy of all routers? What if you want "shortest path" on all the > routers inside the network, but "access strategy" on the last hop? > > Best regards, > Klaus > > > > > On 05.07.2016 13:56, Junxiao Shi wrote: > > Hi Susmit > > > > a) > > This question is orthogonal to my post. I'm talking about /what/ goes > > into the strategy choice table and how are the entries interpreted, not > > /where/ those entries come from. > > Today it's a local configuration by admin of each router / end host. > > "expressing strategy choice through routing protocols" is a different > > idea under discussion. > > > > b) > > Each strategy optimizes for a different goal, such as lower delay, > > higher throughput. It does not prioritize traffic of one application > > over another. > > If you mislabel web traffic as download traffic, you get higher > > throughput but possibly more delay so navigation actions are less > > responsive. > > > > Yours, Junxiao > > > > On Mon, Jul 4, 2016 at 6:15 PM, Susmit > > wrote: > > > > > > > > NFD can choose effective strategy from a marked component. > > > Instead of doing longest prefix match in the strategy choice > table, a > > > strategy choice entry can indicate: > > > > > > contains "app=ndncon" => realtimeI' > > > contains "app=ndnfs" => high-throughput > > > > Two questions, > > > > a) Who is responsible for configuring strategies? Operators or users? > > Should users be responsible for finding optimal stategies in the > > network? > > > > b) How are we going to stop people from mislabeling Interests? > > Hypothetically speaking, If web search strategy is > > "normal-throughput", pages will load faster if they are labeled > > "high-throughput". > > > > Thanks. > > > > -- > > > > Regards, > > Susmit > > > > ==================================== > > http://www.cs.colostate.edu/~susmit > > > > ==================================== > > > > > > > > > > _______________________________________________ > > 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 Sun Jul 10 09:10:03 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 10 Jul 2016 09:10:03 -0700 Subject: [Nfd-dev] namespace-based strategy choice weakness In-Reply-To: References:

<577DA40C.80704@email.arizona.edu> Message-ID: Hi Hila I briefly read "In-Network Retransmission in Named Data Networking". The basic idea of this article relevant to this thread is to add an *Interest Retransmission Policy* (IRP) boolean field to every Interest packet, which requests the forwarding strategy to either retransmit the Interest in a way defined by the strategy, or not to do any in-network retransmission. This idea is in line with having a per-packet strategy choice field. It specifies an important aspect of what the consumer wants the strategy to do: retry the Interest upon Nack / RTO timeout, or don't retry at all. I agree that a per-packet strategy choice field should not name a specific strategy name, but should indicate general preference of the consumer. IRP is one aspect. Some other aspects are: - Does the consumer prefer a path with lower delay and lower throughput, or a path with higher delay and higher throughput? - (when IRP=true) Does the consumer want the network to retry the Interest upon SRTT timeout, or RTO timeout? Regarding "To ensure a correct behavior, the application developer sometimes has to couple the application specifics to the details of the selected forwarding strategy; if the suppression timer of best-route changes between revisions, a matching change might be required in the application code to support the change": This problem is not a weakness in strategy choice. As defined in "Networking Named Content", a strategy is a program written for an abstract forwarding machine. This program can certainly be enclosed in NDN Data packets. Since NDN Data is immutable, any modification to a strategy requires changing its name (typically, incrementing a version number component). Therefore, an application can always choose the same strategy version it's designed for. Obviously, this is in conflict with the idea of letting the application to indicate a preference (instead of selecting a specific strategy). Selecting a specific strategy on a per-packet basis is infeasible because it would incur a huge delay if the strategy must be retrieved from some remote location and loaded into the forwarder, but selecting a specific strategy through configuration or routing protocol shall be possible, at least within an enterprise network or within an ISP for their own services. Yours, Junxiao On Fri, Jul 8, 2016 at 9:09 PM, Hila Ben Abraham wrote: > All, > > I like the idea of supporting the needs of different applications by > adopting a more flexible strategy choice design. > > I support the idea of adding header fields, but I think that this > 'strategy choice' header should be used to better represent application > needs rather than a specific strategy name or a strategy metric. > > In the last few months, we have been exploring conflicts between > applications and forwarding strategies. We implemented an additional > Interest header to support a more flexible in-network retransmission > mechanism, since we found it to be a core mechanism that can impact both > correctness and performance of some applications. This is still work in > progress, but preliminary details can be found here: > http://openscholarship.wustl.edu/cse_research/910 > http://dl.acm.org/citation.cfm?id=2889475 > > As Junxiao mentioned, all the current "smart" strategies optimize for a > minimal round-trip delay. However, each strategy achieves this goal using a > different implementation. To ensure a correct behavior, the application > developer sometimes has to couple the application specifics to the details > of the selected forwarding strategy. For instance, the application must > understand that ncc retransmits unsatisfied Interests on available faces > while best-route requires application's retransmission to try additional > faces. Moreover, if the suppression timer of best-route changes between > revisions, a matching change might be required in the application code to > support the change. Therefore, the application code is somewhat coupled > with the strategy details. This creates challenges in shared resource > environments as the NDN testbed, when multiple applications use the same > strategy. Therefore, I think that any new 'strategy choice' design should > simplify and support application-specific needs. > > To add to what Susmit asked, I understand why the question of who is > responsible for configuring strategy choice seems orthogonal, but I do > think that the answer to '*who* is responsible' will determine '*what* to > configure'. Is the goal of this new 'strategy choice' to have a more > scalable configuration mechanism? Is it to provide a better support for the > operator when choosing strategies according to congestion and other network > issues? Or is it to allow applications-specific needs? > > Hila > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun Jul 10 09:25:06 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 10 Jul 2016 09:25:06 -0700 Subject: [Nfd-dev] namespace-based strategy choice weakness In-Reply-To: <577DA40C.80704@email.arizona.edu> References:

<577DA40C.80704@email.arizona.edu> Message-ID: Hi Klaus The network administrator should ensure that there isn't a strategy "clearly superior" than others available for selection by any applications. Consider an ISP network, there could be superior strategies, but they should always be configured under a certain namespace that corresponds to the ISP's own services. If a superior strategy is available for selection under other namespaces, nothing stops every application to select it, because only allowing a subset of application (other than ISP's own services) to select this strategy would be a violation of network neutrality. If application developers are allowed to supply the strategy (through an Interest header field or routing announcements), restrictions could be placed on the overhead caused by those strategy, such as: - in any 60sec period, the number of outgoing Interests transmitted by the strategy is no more than 110% of incoming Interests - on average, at most 64 octets of measurements information can be stored per PIT entry - on average, at most 1ms CPU core time is permitted per incoming Interest for strategy program execution Such restriction can be uniformly placed onto every strategy (for non-ISP-owned services) so it's fair to every application. Yours, Junxiao On Wed, Jul 6, 2016 at 5:36 PM, Klaus Schneider wrote: > > Yes there is often a trade-off between things like throughput, delay and > reliability. This will hopefully minimize the incentive to mislabel the > preferred strategy. > > However, I'm not sure if that works in practice. It can become a problem > when some strategies are clearly superior than others, like IP QoS classes > ("best-effort", "expedited forwarding", "assured forwarding", etc.) > > Or if some strategies (like broadcast) create a much higher overhead than > others. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus at email.arizona.edu Sun Jul 10 14:29:51 2016 From: klaus at email.arizona.edu (Klaus Schneider) Date: Sun, 10 Jul 2016 14:29:51 -0700 Subject: [Nfd-dev] namespace-based strategy choice weakness In-Reply-To: References:

<577DA40C.80704@email.arizona.edu>

Message-ID: <5782BE4F.7070609@email.arizona.edu> Hi everyone, I agree with Hila that the header field should be an *abstract preference* rather than the selection of a specific strategy. And as Junxiao said, the ISP can then take this preference and provide a number of strategies that have clear trade-offs (like throughput vs. delay), so that it doesn't make sense for the application to fake the preference. We have already talked about the preferences of 1) high throughput and 2) low delay. In last years ICN paper, I also considered 3) high reliability (= low packet loss; which is especially relevant in wireless or tunneled networks) and 4) the notion that some links/strategies are more *costly* to use than others. For example, in-network retransmissions are clearly more costly than not retransmitting. But the cost can pay off if they help to avoid consumer retransmissions. However, the preference could be more fine-grained than selecting one of the attributes. For example, an audio conferencing application has a clear "deadline" until when the data is useful to the application (a couple 100 ms). So a router that knows this deadline can make smarter decisions about whether to retransmit than it could be just looking at the "Interest Retransmission Policy". Early on in the Interest lifetime you might want more aggressive retransmissions than shortly before the deadline is over. There is a paper from the ICN'13 which talks about this in more detail "Deadline-based Resource Management for Information-Centric Networks" http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.380.6698&rep=rep1&type=pdf There hasn't been much follow-up work, but maybe it's worth looking into these ideas again. Best regards, Klaus > Hi Klaus > > The network administrator should ensure that there isn't a strategy "clearly superior" than others available for selection by any applications. > Consider an ISP network, there could be superior strategies, but they should always be configured under a certain namespace that corresponds to the ISP's own services. > If a superior strategy is available for selection under other namespaces, nothing stops every application to select it, because only allowing a subset of application (other than ISP's own services) to select this strategy would be a violation of network neutrality. > > If application developers are allowed to supply the strategy (through an Interest header field or routing announcements), restrictions could be placed on the overhead caused by those strategy, such as: > > in any 60sec period, the number of outgoing Interests transmitted by the strategy is no more than 110% of incoming Interests > on average, at most 64 octets of measurements information can be stored per PIT entry > on average, at most 1ms CPU core time is permitted per incoming Interest for strategy program execution > > Such restriction can be uniformly placed onto every strategy (for non-ISP-owned services) so it's fair to every application. > > Yours, Junxiao > On 10.07.2016 09:10, Junxiao Shi wrote: > Hi Hila > > I briefly read "In-Network Retransmission in Named Data Networking". The > basic idea of this article relevant to this thread is to add an > /Interest Retransmission Policy/ (IRP) boolean field to every Interest > packet, which requests the forwarding strategy to either retransmit the > Interest in a way defined by the strategy, or not to do any in-network > retransmission. > This idea is in line with having a per-packet strategy choice field. It > specifies an important aspect of what the consumer wants the strategy to > do: retry the Interest upon Nack / RTO timeout, or don't retry at all. > > I agree that a per-packet strategy choice field should not name a > specific strategy name, but should indicate general preference of the > consumer. > IRP is one aspect. Some other aspects are: > > * Does the consumer prefer a path with lower delay and lower > throughput, or a path with higher delay and higher throughput? > * (when IRP=true) Does the consumer want the network to retry the > Interest upon SRTT timeout, or RTO timeout? > > > > Regarding "To ensure a correct behavior, the application developer > sometimes has to couple the application specifics to the details of the > selected forwarding strategy; if the suppression timer of best-route > changes between revisions, a matching change might be required in the > application code to support the change": > This problem is not a weakness in strategy choice. > As defined in "Networking Named Content", a strategy is a program > written for an abstract forwarding machine. This program can certainly > be enclosed in NDN Data packets. Since NDN Data is immutable, any > modification to a strategy requires changing its name (typically, > incrementing a version number component). Therefore, an application can > always choose the same strategy version it's designed for. > > Obviously, this is in conflict with the idea of letting the application > to indicate a preference (instead of selecting a specific strategy). > Selecting a specific strategy on a per-packet basis is infeasible > because it would incur a huge delay if the strategy must be retrieved > from some remote location and loaded into the forwarder, but selecting a > specific strategy through configuration or routing protocol shall be > possible, at least within an enterprise network or within an ISP for > their own services. > > Yours, Junxiao > > On Fri, Jul 8, 2016 at 9:09 PM, Hila Ben Abraham > wrote: > > All, > > I like the idea of supporting the needs of different applications by > adopting a more flexible strategy choice design. > > I support the idea of adding header fields, but I think that this > 'strategy choice' header should be used to better represent > application needs rather than a specific strategy name or a strategy > metric. > > In the last few months, we have been exploring conflicts between > applications and forwarding strategies. We implemented an additional > Interest header to support a more flexible in-network retransmission > mechanism, since we found it to be a core mechanism that can impact > both correctness and performance of some applications. This is still > work in progress, but preliminary details can be found here: > http://openscholarship.wustl.edu/cse_research/910 > http://dl.acm.org/citation.cfm?id=2889475 > > As Junxiao mentioned, all the current "smart" strategies optimize > for a minimal round-trip delay. However, each strategy achieves this > goal using a different implementation. To ensure a correct behavior, > the application developer sometimes has to couple the application > specifics to the details of the selected forwarding strategy. For > instance, the application must understand that ncc retransmits > unsatisfied Interests on available faces while best-route requires > application's retransmission to try additional faces. Moreover, if > the suppression timer of best-route changes between revisions, a > matching change might be required in the application code to support > the change. Therefore, the application code is somewhat coupled with > the strategy details. This creates challenges in shared resource > environments as the NDN testbed, when multiple applications use the > same strategy. Therefore, I think that any new 'strategy choice' > design should simplify and support application-specific needs. > > To add to what Susmit asked, I understand why the question of who is > responsible for configuring strategy choice seems orthogonal, but I > do think that the answer to '_who_ is responsible' will determine > '_what_ to configure'. Is the goal of this new 'strategy choice' to > have a more scalable configuration mechanism? Is it to provide a > better support for the operator when choosing strategies according > to congestion and other network issues? Or is it to allow > applications-specific needs? > > Hila > From shijunxiao at email.arizona.edu Mon Jul 11 18:13:18 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 11 Jul 2016 18:13:18 -0700 Subject: [Nfd-dev] Help needed with debugging duplicate Nonce In-Reply-To: <7D17546E-AA1D-4D1C-947A-6DC00216A66F@memphis.edu> References: <57716ff0.0617620a.1b687.2b5e@mx.google.com>

<5776929d.aa41420a.8c48f.05cf@mx.google.com> <7D17546E-AA1D-4D1C-947A-6DC00216A66F@memphis.edu> Message-ID: <5784442f.4e42620a.d5f8c.108c@mx.google.com> Hi Lan When forwarder receives a Nack from face A, it records on the PIT out-record of face A that a Nack has been received, and triggers the strategy. In case Data comes from face A in the future, this Data would still be accepted. When strategy instructs forwarder to send a Nack to face B, it removes the PIT in-record of face B. In case the PIT entry is later satisfied by Data, face B would not receive a copy of this Data. To make ChronoSync work in the general case, we should design for the situation where /localhop is not used, even if there might be a workaround with /localhop. Yours, Junxiao From: Lan Wang (lanwang) -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Tue Jul 12 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 12 Jul 2016 07:00:02 -0700 Subject: [Nfd-dev] NFD call 20160712 Message-ID: <201607121400.u6CE02Hx018210@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Tue Jul 12 09:28:44 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Tue, 12 Jul 2016 16:28:44 +0000 Subject: [Nfd-dev] Help needed with debugging duplicate Nonce In-Reply-To: <5784442f.4e42620a.d5f8c.108c@mx.google.com> References: <57716ff0.0617620a.1b687.2b5e@mx.google.com>

<5776929d.aa41420a.8c48f.05cf@mx.google.com> <7D17546E-AA1D-4D1C-947A-6DC00216A66F@memphis.edu> <5784442f.4e42620a.d5f8c.108c@mx.google.com> Message-ID: <39FB5146-3304-46F0-9502-D465E950A8E0@memphis.edu> Junxiao, On Jul 11, 2016, at 8:13 PM, Junxiao Shi > wrote: Hi Lan When forwarder receives a Nack from face A, it records on the PIT out-record of face A that a Nack has been received, and triggers the strategy. In case Data comes from face A in the future, this Data would still be accepted. When strategy instructs forwarder to send a Nack to face B, it removes the PIT in-record of face B. In case the PIT entry is later satisfied by Data, face B would not receive a copy of this Data. The above highlighted part is the problem. Since the in-record of face B is removed after sending the Nack, any Sync data packet generated by ChronoSync cannot be delivered to the neighbor on face B. The neighbor would wait for the sync period to expire and resend the next Sync Interest to receive the data. This is the major problem caused by the duplicate Nacks (not just pure message overhead). To make ChronoSync work in the general case, we should design for the situation where /localhop is not used, even if there might be a workaround with /localhop. Yes, we hope for a general solution (the forwarding plane should not generate these unnecessary Nacks). If this is not possible, then we have to resort to a custom solution e.g. /localhop, as I said before. Lan Yours, Junxiao From: Lan Wang (lanwang) Sent: Thursday, July 7, 2016 17:20 To: Junxiao Shi Cc: Ashlesh Gawande (agawande); nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce Junxiao, I have some questions about the specifics of the example that are best clarified through the nfd call, but here are some high-order questions: - Duplicate NACK is a problem because I think it will affect the pending interest information between the neighbors so their sync data packets won?t be able to propagate in time. What does a node do to its PIT when it sends/receives a duplicate NACK? - /localhop is fine for intradomain routing, because NLSR neighbors are one hop away from each other. But we don?t have to do this if we don?t have the duplicate NACK problem in the first place. - if we do have to use /localhop to remove the duplicate NACKs then we need to make sure that it only propagates one hop (not as implemented now). Lan -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Jul 12 10:58:25 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 12 Jul 2016 10:58:25 -0700 Subject: [Nfd-dev] Help needed with debugging duplicate Nonce In-Reply-To: <39FB5146-3304-46F0-9502-D465E950A8E0@memphis.edu> References: <57716ff0.0617620a.1b687.2b5e@mx.google.com>

<5776929d.aa41420a.8c48f.05cf@mx.google.com> <7D17546E-AA1D-4D1C-947A-6DC00216A66F@memphis.edu> <5784442f.4e42620a.d5f8c.108c@mx.google.com> <39FB5146-3304-46F0-9502-D465E950A8E0@memphis.edu> <57852fc2.8612620a.2501d.6abe@mx.google.com> Message-ID: <46489E6A-AAF8-4E07-8D91-7EA4B9D1F1BF@memphis.edu> Junxiao, On Jul 12, 2016, at 12:58 PM, Junxiao Shi > wrote: Hi Lan Look at this topology: A---B \ / C Assume every link has the same delay, and the processing delay at each node is zero. When C sends the same Interest to both A and B, A and B would forward the Interest to each other, and get Nack-Duplicate from each other. Per ChronoSync protocol, the applications on A and B should express Interests with the same name. Since A and B are symmetric, let?s look at A. There could be three different timings: TIMING0 AppA expresses the Interest before C?s Interest arrives at A. If we relabel A->C B->A C->B, it becomes either TIMING1 or TIMING2. TIMING1 AppA expresses the Interest after C?s Interest has been forwarded to B, but before B responds Nack-Duplicate. The duration between A forwarding C?s Interest to B and A receiving Nack-Duplicate from B is most likely shorter than the suppression interval, so appA?s Interest would be suppressed. When Nack-Duplicate against C?s Interest arrives from B, strategy at A should send appA?s Interest to B. TIMING2 AppA expresses the Interest after B responds Nack-Duplicate. When Nack-Duplicate against C?s Interest arrives from B, strategy at A should not return the Nack to C, because appA is another upstream which has not Nacked. When appA expresses the Interest, strategy at A should not suppress this Interest, because the sole pending upstream (appA) is now a downstream. The strategy should forward the Interest to both B and C. When the strategy behaves as what I describe above, everyone should be getting Data. Question is whether the multicast strategy ChronoSync uses has the above behavior or not (e.g., "When Nack-Duplicate against C?s Interest arrives from B, strategy at A should send appA?s Interest to B.?). I doubt it is the case based on the following. Below is from your earlier email: ============== below is from Junxiao?s email ======== From A?s point of view, face261 is the local app, face262 is B, face263 is C. Incoming+outgoing Interests, and PIT entry contents are as follows: 52.39 from=C=4168 to=app PIT in=[C=4168 at 52.39] out=[app at 52.39] 52.72 from=B=6605 PIT in=[C=4168 at 52.39,B=6605 at 52.72] out=[app at 52.39] 52.74 from=app=7385 to=B,C PIT in=[C=4168 at 52.39,B=6605 at 52.72,app=7385 at 52.74] out=[app at 52.39,B at 52.74,C at 52.74] 56.39 PIT in=[B=6605 at 52.72,app=7385 at 52.74]+expired[C=4168 at 52.39] out=[B at 52.74,C at 52.74]+expired[app at 52.39] 56.72 PIT in=[app=7385 at 52.74]+expired[C=4168 at 52.39,B=6605 at 52.72] out=[B at 52.74,C at 52.74]+expired[app at 52.39] 56.74 Interest unsatisfied, PIT erased 56.89 from=C=0641 to=app PIT in=[C=0641 at 56.89] out=[app at 56.89] 56.90 from=app=7567 to=B,C PIT in=[C=0641 at 56.89,app=7567 at 56.90] out=[app at 56.89,B at 56.90,C at 56.90] 57.06 from=B=1547 PIT in=[C=0641 at 56.89,app=7567 at 56.90,B=1547 at 57.06] out=[app at 56.89,B at 56.90,C at 56.90] 60.89 PIT in=[app=7567 at 56.90,B=1547 at 57.06]+expired[C=0641 at 56.89] out=[B at 56.90,C at 56.90]+expired[app at 56.89] 60.90 PIT in=[B=1547 at 57.06]+expired[C=0641 at 56.89,app=7567 at 56.90] out=[]+expired[app at 56.89,B at 56.90,C at 56.90] 61.05 from=C=6600 to=app,B,C PIT in=[B=1547 at 57.06,C=6600 at 61.05]+expired[app=7567 at 56.90] out=[app at 61.05,B at 61.05,C at 61.05] Time is represented with last two digits of integral part and first two digits of fractional part. Nonce is represented with last four digits. PIT in-record is represented as =@. PIT out-record is represented as @. The PIT entry has been erased at 56.74, so anything before that does not affect the later part. At 61.05, an Interest with nonce 6600 is received from C. Before processing this Interest, the PIT entry has one unexpired in-record from B which has nonce 1547 and was created at 57.06; all out-records have been expired. This Interest is forwarded with nonce 6600 to both app and B. Since the PIT entry indicates B still wants the Data, the strategy also forwards the Interest with nonce 1547 (which came from B at 57.06) back to C. While this may not be the best idea for multicast strategy, and using a nonce from non-local-app may be problematic with /localhop, this forwarding is valid in general: nonce 1547 has never been forwarded earlier, and downstream B still wants the Data, so the strategy can certainly forward the Interest to C using this nonce. ============ above is from Junxiao?s email ========= The above trace did not include some important information, i.e. (1) the NACK-duplicate messages and (2) what happens after receiving the NACKs. So I searched a?s nfd log from Ashlesh?s email and found the following which I hope are the relevant messages. 1467225861.054557 DEBUG: [Forwarder] onIncomingInterest face=263 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b (A received sync interest from C with nonce 6600 ? the nonce is inferred from your email, I didn?t check the ndndump log) 1467225861.054705 DEBUG: [Forwarder] onOutgoingInterest face=262 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b (A sent sync interest to B with the nonce 6600 - again nonce value is inferred from your email) 1467225861.054736 DEBUG: [Forwarder] onOutgoingInterest face=263 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b (A sent sync interest to C with the nonce 1547 - again nonce value is inferred from your email) ? the above three correspond to the last line in your trace ---- 1467225861.075402 DEBUG: [Forwarder] onIncomingNack face=263 nack=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b~Duplicate OK 1467225861.075601 DEBUG: [Forwarder] onIncomingNack face=262 nack=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b~Duplicate OK ? the above two message show that both B and C sent NACK-duplicate back to A ? C has previously received the nonce 1547 from A I think (A has expired the corresponding out record, but C has not deleted the in-record I guess). I?m not sure why B would also send a NACK-duplicate. Did it receive one with the nonce 6600 before from A? ? according to your earlier email, these two NACKs would erase the corresponding in record at B and C. 1467225861.224289 DEBUG: [Forwarder] onIncomingInterest face=262 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b (B sent another sync interest to A) 1467225861.378008 DEBUG: [Forwarder] onIncomingInterest face=261 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b (A?s app sent a sync interest to A?s nfd) 1467225861.378105 DEBUG: [Forwarder] onContentStoreMiss interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b 1467225865.378406 DEBUG: [Forwarder] onInterestUnsatisfied interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b 1467225865.378471 DEBUG: [Forwarder] onInterestFinalize interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b unsatisfied 1467225865.528040 DEBUG: [Forwarder] onIncomingInterest face=263 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b 1467225865.528083 DEBUG: [Forwarder] onContentStoreMiss interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b 1467225865.528126 DEBUG: [Forwarder] onOutgoingInterest face=261 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b ? the above shows that A did not send a sync interest to B and C after A?s app sent a sync interest to A?s nfd (there were no such messages between 61.3 and 65), which means that B and C won?t have the corresponding in record (but for ChronoSync to work there needs to be a pending interest on each direction in every link). Lan Yours, Junxiao From: Lan Wang (lanwang) Sent: Tuesday, July 12, 2016 09:28 To: Junxiao Shi Cc: Ashlesh Gawande (agawande); nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce When strategy instructs forwarder to send a Nack to face B, it removes the PIT in-record of face B. In case the PIT entry is later satisfied by Data, face B would not receive a copy of this Data. The above highlighted part is the problem. Since the in-record of face B is removed after sending the Nack, any Sync data packet generated by ChronoSync cannot be delivered to the neighbor on face B. The neighbor would wait for the sync period to expire and resend the next Sync Interest to receive the data. This is the major problem caused by the duplicate Nacks (not just pure message overhead). -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Jul 13 06:54:44 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 13 Jul 2016 06:54:44 -0700 Subject: [Nfd-dev] Help needed with debugging duplicate Nonce In-Reply-To: <46489E6A-AAF8-4E07-8D91-7EA4B9D1F1BF@memphis.edu> References: <57716ff0.0617620a.1b687.2b5e@mx.google.com>

<5776929d.aa41420a.8c48f.05cf@mx.google.com> <7D17546E-AA1D-4D1C-947A-6DC00216A66F@memphis.edu> <5784442f.4e42620a.d5f8c.108c@mx.google.com> <39FB5146-3304-46F0-9502-D465E950A8E0@memphis.edu> <57852fc2.8612620a.2501d.6abe@mx.google.com> <46489E6A-AAF8-4E07-8D91-7EA4B9D1F1BF@memphis.edu> <57864826.8148620a.c50c1.40ff@mx.google.com> Message-ID: <0521BE8D-DA8C-4CC9-B824-67F49E53F251@memphis.edu> Junxiao, Ashlesh can work on these two issues if no one else volunteers. Lan On Jul 13, 2016, at 8:54 AM, Junxiao Shi > wrote: Hi Lan Multicast strategy v1 does not have any of the desired behaviors. It neither allows consumer retransmission, nor processes incoming Nacks. ChronoSync developers could pick up the work on multicast strategy: Feature #2063: permit consumer retransmission Feature #3176: Nack processing Yours, Junxiao From: Lan Wang (lanwang) Sent: Wednesday, July 13, 2016 06:46 To: Junxiao Shi Cc: Ashlesh Gawande (agawande); nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce Junxiao, On Jul 12, 2016, at 12:58 PM, Junxiao Shi > wrote: Hi Lan Look at this topology: A---B \ / C Assume every link has the same delay, and the processing delay at each node is zero. When C sends the same Interest to both A and B, A and B would forward the Interest to each other, and get Nack-Duplicate from each other. Per ChronoSync protocol, the applications on A and B should express Interests with the same name. Since A and B are symmetric, let?s look at A. There could be three different timings: TIMING0 AppA expresses the Interest before C?s Interest arrives at A. If we relabel A->C B->A C->B, it becomes either TIMING1 or TIMING2. TIMING1 AppA expresses the Interest after C?s Interest has been forwarded to B, but before B responds Nack-Duplicate. The duration between A forwarding C?s Interest to B and A receiving Nack-Duplicate from B is most likely shorter than the suppression interval, so appA?s Interest would be suppressed. When Nack-Duplicate against C?s Interest arrives from B, strategy at A should send appA?s Interest to B. TIMING2 AppA expresses the Interest after B responds Nack-Duplicate. When Nack-Duplicate against C?s Interest arrives from B, strategy at A should not return the Nack to C, because appA is another upstream which has not Nacked. When appA expresses the Interest, strategy at A should not suppress this Interest, because the sole pending upstream (appA) is now a downstream. The strategy should forward the Interest to both B and C. When the strategy behaves as what I describe above, everyone should be getting Data. Question is whether the multicast strategy ChronoSync uses has the above behavior or not (e.g., "When Nack-Duplicate against C?s Interest arrives from B, strategy at A should send appA?s Interest to B.?). I doubt it is the case based on the following. Below is from your earlier email: ============== below is from Junxiao?s email ======== From A?s point of view, face261 is the local app, face262 is B, face263 is C. Incoming+outgoing Interests, and PIT entry contents are as follows: 52.39 from=C=4168 to=app PIT in=[C=4168 at 52.39] out=[app at 52.39] 52.72 from=B=6605 PIT in=[C=4168 at 52.39,B=6605 at 52.72] out=[app at 52.39] 52.74 from=app=7385 to=B,C PIT in=[C=4168 at 52.39,B=6605 at 52.72,app=7385 at 52.74] out=[app at 52.39,B at 52.74,C at 52.74] 56.39 PIT in=[B=6605 at 52.72,app=7385 at 52.74]+expired[C=4168 at 52.39] out=[B at 52.74,C at 52.74]+expired[app at 52.39] 56.72 PIT in=[app=7385 at 52.74]+expired[C=4168 at 52.39,B=6605 at 52.72] out=[B at 52.74,C at 52.74]+expired[app at 52.39] 56.74 Interest unsatisfied, PIT erased 56.89 from=C=0641 to=app PIT in=[C=0641 at 56.89] out=[app at 56.89] 56.90 from=app=7567 to=B,C PIT in=[C=0641 at 56.89,app=7567 at 56.90] out=[app at 56.89,B at 56.90,C at 56.90] 57.06 from=B=1547 PIT in=[C=0641 at 56.89,app=7567 at 56.90,B=1547 at 57.06] out=[app at 56.89,B at 56.90,C at 56.90] 60.89 PIT in=[app=7567 at 56.90,B=1547 at 57.06]+expired[C=0641 at 56.89] out=[B at 56.90,C at 56.90]+expired[app at 56.89] 60.90 PIT in=[B=1547 at 57.06]+expired[C=0641 at 56.89,app=7567 at 56.90] out=[]+expired[app at 56.89,B at 56.90,C at 56.90] 61.05 from=C=6600 to=app,B,C PIT in=[B=1547 at 57.06,C=6600 at 61.05]+expired[app=7567 at 56.90] out=[app at 61.05,B at 61.05,C at 61.05] Time is represented with last two digits of integral part and first two digits of fractional part. Nonce is represented with last four digits. PIT in-record is represented as =@. PIT out-record is represented as @. The PIT entry has been erased at 56.74, so anything before that does not affect the later part. At 61.05, an Interest with nonce 6600 is received from C. Before processing this Interest, the PIT entry has one unexpired in-record from B which has nonce 1547 and was created at 57.06; all out-records have been expired. This Interest is forwarded with nonce 6600 to both app and B. Since the PIT entry indicates B still wants the Data, the strategy also forwards the Interest with nonce 1547 (which came from B at 57.06) back to C. While this may not be the best idea for multicast strategy, and using a nonce from non-local-app may be problematic with /localhop, this forwarding is valid in general: nonce 1547 has never been forwarded earlier, and downstream B still wants the Data, so the strategy can certainly forward the Interest to C using this nonce. ============ above is from Junxiao?s email ========= The above trace did not include some important information, i.e. (1) the NACK-duplicate messages and (2) what happens after receiving the NACKs. So I searched a?s nfd log from Ashlesh?s email and found the following which I hope are the relevant messages. 1467225861.054557 DEBUG: [Forwarder] onIncomingInterest face=263 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b (A received sync interest from C with nonce 6600 ? the nonce is inferred from your email, I didn?t check the ndndump log) 1467225861.054705 DEBUG: [Forwarder] onOutgoingInterest face=262 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b (A sent sync interest to B with the nonce 6600 - again nonce value is inferred from your email) 1467225861.054736 DEBUG: [Forwarder] onOutgoingInterest face=263 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b (A sent sync interest to C with the nonce 1547 - again nonce value is inferred from your email) ? the above three correspond to the last line in your trace ---- 1467225861.075402 DEBUG: [Forwarder] onIncomingNack face=263 nack=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b~Duplicate OK 1467225861.075601 DEBUG: [Forwarder] onIncomingNack face=262 nack=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b~Duplicate OK ? the above two message show that both B and C sent NACK-duplicate back to A ? C has previously received the nonce 1547 from A I think (A has expired the corresponding out record, but C has not deleted the in-record I guess). I?m not sure why B would also send a NACK-duplicate. Did it receive one with the nonce 6600 before from A? ? according to your earlier email, these two NACKs would erase the corresponding in record at B and C. 1467225861.224289 DEBUG: [Forwarder] onIncomingInterest face=262 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b (B sent another sync interest to A) 1467225861.378008 DEBUG: [Forwarder] onIncomingInterest face=261 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b (A?s app sent a sync interest to A?s nfd) 1467225861.378105 DEBUG: [Forwarder] onContentStoreMiss interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b 1467225865.378406 DEBUG: [Forwarder] onInterestUnsatisfied interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b 1467225865.378471 DEBUG: [Forwarder] onInterestFinalize interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b unsatisfied 1467225865.528040 DEBUG: [Forwarder] onIncomingInterest face=263 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b 1467225865.528083 DEBUG: [Forwarder] onContentStoreMiss interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b 1467225865.528126 DEBUG: [Forwarder] onOutgoingInterest face=261 interest=/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b ? the above shows that A did not send a sync interest to B and C after A?s app sent a sync interest to A?s nfd (there were no such messages between 61.3 and 65), which means that B and C won?t have the corresponding in record (but for ChronoSync to work there needs to be a pending interest on each direction in every link). Lan Yours, Junxiao From: Lan Wang (lanwang) Sent: Tuesday, July 12, 2016 09:28 To: Junxiao Shi Cc: Ashlesh Gawande (agawande); nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce When strategy instructs forwarder to send a Nack to face B, it removes the PIT in-record of face B. In case the PIT entry is later satisfied by Data, face B would not receive a copy of this Data. The above highlighted part is the problem. Since the in-record of face B is removed after sending the Nack, any Sync data packet generated by ChronoSync cannot be delivered to the neighbor on face B. The neighbor would wait for the sync period to expire and resend the next Sync Interest to receive the data. This is the major problem caused by the duplicate Nacks (not just pure message overhead). -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Jul 14 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 14 Jul 2016 07:00:02 -0700 Subject: [Nfd-dev] NFD call 20160714 Message-ID: <201607141400.u6EE02u1005828@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From hila at wustl.edu Thu Jul 14 10:45:07 2016 From: hila at wustl.edu (Hila Ben Abraham) Date: Thu, 14 Jul 2016 17:45:07 +0000 Subject: [Nfd-dev] namespace-based strategy choice weakness In-Reply-To: <5782BE4F.7070609@email.arizona.edu> References:

<577DA40C.80704@email.arizona.edu>

<5782BE4F.7070609@email.arizona.edu> Message-ID: Junxiao and Klaus, Thank you for taking the time to comment to my email. I want to add one more point. A forwarding strategy is used today to support both application and network needs. I think that any selected design should be able to decompose application needs from strategy implementation, and minimize the conflicts created when multiple applications use the same strategy in shared resource networks. However, I think that it is not feasible to support every application preference in the strategy choice header. Following up on Klaus example, one application would greatly benefit from passing the "deadline" to the strategy layer, while others would prefer a completely different attribute. Obviously, the strategy can't support all and the application has the responsibility to implement its own specific mechanisms. But when it does, the strategy must not conflict with the application's requests. This is the reason the report I shared first tries to decompose the core strategy mechanisms and to understand what should be abstracted for applications. As mention, this is still work in progress and the report currently focuses on in-network retransmissions since we found it to be a crucial mechanism. Hila On Sun, Jul 10, 2016 at 4:29 PM Klaus Schneider wrote: > Hi everyone, > > I agree with Hila that the header field should be an *abstract > preference* rather than the selection of a specific strategy. And as > Junxiao said, the ISP can then take this preference and provide a number > of strategies that have clear trade-offs (like throughput vs. delay), so > that it doesn't make sense for the application to fake the preference. > > We have already talked about the preferences of 1) high throughput and > 2) low delay. In last years ICN paper, I also considered 3) high > reliability (= low packet loss; which is especially relevant in wireless > or tunneled networks) and 4) the notion that some links/strategies are > more *costly* to use than others. For example, in-network > retransmissions are clearly more costly than not retransmitting. But the > cost can pay off if they help to avoid consumer retransmissions. > > However, the preference could be more fine-grained than selecting one of > the attributes. For example, an audio conferencing application has a > clear "deadline" until when the data is useful to the application (a > couple 100 ms). So a router that knows this deadline can make smarter > decisions about whether to retransmit than it could be just looking at > the "Interest Retransmission Policy". Early on in the Interest lifetime > you might want more aggressive retransmissions than shortly before the > deadline is over. > > There is a paper from the ICN'13 which talks about this in more detail > "Deadline-based Resource Management for Information-Centric Networks" > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.380.6698&rep=rep1&type=pdf > > There hasn't been much follow-up work, but maybe it's worth looking into > these ideas again. > > Best regards, > Klaus > > > > Hi Klaus > > > > The network administrator should ensure that there isn't a strategy > "clearly superior" than others available for selection by any applications. > > Consider an ISP network, there could be superior strategies, but they > should always be configured under a certain namespace that corresponds to > the ISP's own services. > > If a superior strategy is available for selection under other > namespaces, nothing stops every application to select it, because only > allowing a subset of application (other than ISP's own services) to select > this strategy would be a violation of network neutrality. > > > > If application developers are allowed to supply the strategy (through an > Interest header field or routing announcements), restrictions could be > placed on the overhead caused by those strategy, such as: > > > > in any 60sec period, the number of outgoing Interests transmitted by > the strategy is no more than 110% of incoming Interests > > on average, at most 64 octets of measurements information can be > stored per PIT entry > > on average, at most 1ms CPU core time is permitted per incoming > Interest for strategy program execution > > > > Such restriction can be uniformly placed onto every strategy (for > non-ISP-owned services) so it's fair to every application. > > > > Yours, Junxiao > > > > > On 10.07.2016 09:10, Junxiao Shi wrote: > > Hi Hila > > > > I briefly read "In-Network Retransmission in Named Data Networking". The > > basic idea of this article relevant to this thread is to add an > > /Interest Retransmission Policy/ (IRP) boolean field to every Interest > > packet, which requests the forwarding strategy to either retransmit the > > Interest in a way defined by the strategy, or not to do any in-network > > retransmission. > > This idea is in line with having a per-packet strategy choice field. It > > specifies an important aspect of what the consumer wants the strategy to > > do: retry the Interest upon Nack / RTO timeout, or don't retry at all. > > > > I agree that a per-packet strategy choice field should not name a > > specific strategy name, but should indicate general preference of the > > consumer. > > IRP is one aspect. Some other aspects are: > > > > * Does the consumer prefer a path with lower delay and lower > > throughput, or a path with higher delay and higher throughput? > > * (when IRP=true) Does the consumer want the network to retry the > > Interest upon SRTT timeout, or RTO timeout? > > > > > > > > Regarding "To ensure a correct behavior, the application developer > > sometimes has to couple the application specifics to the details of the > > selected forwarding strategy; if the suppression timer of best-route > > changes between revisions, a matching change might be required in the > > application code to support the change": > > This problem is not a weakness in strategy choice. > > As defined in "Networking Named Content", a strategy is a program > > written for an abstract forwarding machine. This program can certainly > > be enclosed in NDN Data packets. Since NDN Data is immutable, any > > modification to a strategy requires changing its name (typically, > > incrementing a version number component). Therefore, an application can > > always choose the same strategy version it's designed for. > > > > Obviously, this is in conflict with the idea of letting the application > > to indicate a preference (instead of selecting a specific strategy). > > Selecting a specific strategy on a per-packet basis is infeasible > > because it would incur a huge delay if the strategy must be retrieved > > from some remote location and loaded into the forwarder, but selecting a > > specific strategy through configuration or routing protocol shall be > > possible, at least within an enterprise network or within an ISP for > > their own services. > > > > Yours, Junxiao > > > > On Fri, Jul 8, 2016 at 9:09 PM, Hila Ben Abraham > > wrote: > > > > All, > > > > I like the idea of supporting the needs of different applications by > > adopting a more flexible strategy choice design. > > > > I support the idea of adding header fields, but I think that this > > 'strategy choice' header should be used to better represent > > application needs rather than a specific strategy name or a strategy > > metric. > > > > In the last few months, we have been exploring conflicts between > > applications and forwarding strategies. We implemented an additional > > Interest header to support a more flexible in-network retransmission > > mechanism, since we found it to be a core mechanism that can impact > > both correctness and performance of some applications. This is still > > work in progress, but preliminary details can be found here: > > http://openscholarship.wustl.edu/cse_research/910 > > http://dl.acm.org/citation.cfm?id=2889475 > > > > As Junxiao mentioned, all the current "smart" strategies optimize > > for a minimal round-trip delay. However, each strategy achieves this > > goal using a different implementation. To ensure a correct behavior, > > the application developer sometimes has to couple the application > > specifics to the details of the selected forwarding strategy. For > > instance, the application must understand that ncc retransmits > > unsatisfied Interests on available faces while best-route requires > > application's retransmission to try additional faces. Moreover, if > > the suppression timer of best-route changes between revisions, a > > matching change might be required in the application code to support > > the change. Therefore, the application code is somewhat coupled with > > the strategy details. This creates challenges in shared resource > > environments as the NDN testbed, when multiple applications use the > > same strategy. Therefore, I think that any new 'strategy choice' > > design should simplify and support application-specific needs. > > > > To add to what Susmit asked, I understand why the question of who is > > responsible for configuring strategy choice seems orthogonal, but I > > do think that the answer to '_who_ is responsible' will determine > > '_what_ to configure'. Is the goal of this new 'strategy choice' to > > have a more scalable configuration mechanism? Is it to provide a > > better support for the operator when choosing strategies according > > to congestion and other network issues? Or is it to allow > > applications-specific needs? > > > > Hila > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Jul 14 11:28:56 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 14 Jul 2016 11:28:56 -0700 Subject: [Nfd-dev] ndn-cxx deprecated feature removal: makeDummyClientFace and DummyClientFace::sentDatas Message-ID: Dear folks The following deprecated feature will be removed from ndn-cxx soon: makeDummyClientFace function => replace with DummyClientFace constructor DummyClientFace::sentDatas => replace with DummyClientFace::sentData If you have code that depend on this feature and cannot be fixed now, please reply no later than Jul 18 12:00 UTC. Otherwise, we'll proceed with the removal after that time. You can compile your projects with ndn-cxx Change https://gerrit.named-data.net/2931 and verify it works. I have already prepared patches for these projects: NFD https://gerrit.named-data.net/2927 ndns https://gerrit.named-data.net/2928 ndn-tools https://gerrit.named-data.net/2929 ndn-group-encrypt https://gerrit.named-data.net/2930 ChronoSync https://gerrit.named-data.net/2932 NLSR https://gerrit.named-data.net/2933 nTorrent https://gerrit.named-data.net/2934 If you are a developer in one of these projects, please review the patch on Gerrit. Thanks. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sat Jul 16 06:00:02 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 16 Jul 2016 06:00:02 -0700 Subject: [Nfd-dev] review request: refactor nfd-status Message-ID: Dear folks I'm doing refactoring on nfd-status tool to use the newly introduced Controller::fetch API, and I need someone to review the code: https://gerrit.named-data.net/2910 If you are willing to have a look at the patch, I'll appreciate that. You don't have to be an expert in order to do a code review. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sat Jul 16 06:01:17 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 16 Jul 2016 06:01:17 -0700 Subject: [Nfd-dev] review request: ndn-cxx logging facility Message-ID: Dear folks I'm working on bringing the ndn-cxx-logging project into ndn-cxx codebase, and I need someone to review the code: https://gerrit.named-data.net/2918 If you are willing to have a look at the patch, I'll appreciate that. You don't have to be an expert in order to do a code review. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sat Jul 16 08:30:59 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 16 Jul 2016 08:30:59 -0700 Subject: [Nfd-dev] Redmine repository tab broken Message-ID: <578a5335.41e8420a.d2148.9053@mx.google.com> Hi Redmine admins I notice that ?repository? tab on Redmine has not updated in the past 4 weeks. Both ndn-cxx and NFD have several commits merged this week, but the latest revision shown on ?repository? tab is Jun 19 or Jun 20. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Sun Jul 17 00:50:17 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Sun, 17 Jul 2016 09:50:17 +0200 Subject: [Nfd-dev] Redmine repository tab broken In-Reply-To: <578a5335.41e8420a.d2148.9053@mx.google.com> References: <578a5335.41e8420a.d2148.9053@mx.google.com> Message-ID: Should be fixed now. > On Jul 16, 2016, at 5:30 PM, Junxiao Shi wrote: > > Hi Redmine admins > > I notice that ?repository? tab on Redmine has not updated in the past 4 weeks. > Both ndn-cxx and NFD have several commits merged this week, but the latest revision shown on ?repository? tab is Jun 19 or Jun 20. > > Yours, Junxiao -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jefft0 at remap.ucla.edu Mon Jul 18 08:44:50 2016 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Mon, 18 Jul 2016 15:44:50 +0000 Subject: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" Message-ID: Hello NFD developers, On a fresh OS X 10.11 virtual machine, I installed MacPorts and did: sudo port install pkgconfig boost sqlite3 libcryptopp libpcap export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig I was able to compile and install ndn-cxx. But when I compile NFD I get many errors starting with those below. Is there an extra configuration step relating to the logger? Thanks, - Jeff T ../daemon/table/cs.cpp:84:3: error: invalid operands to binary expression ('basic_record_ostream' and '::nfd::LoggerTimestamp') NFD_LOG_DEBUG("insert " << data.getName()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/jefft0/work/NFD/core/logger.hpp:154:35: note: expanded from macro 'NFD_LOG_DEBUG' #define NFD_LOG_DEBUG(expression) NFD_LOG(DEBUG, DEBUG, expression) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/jefft0/work/NFD/core/logger.hpp:149:39: note: expanded from macro 'NFD_LOG' BOOST_LOG(g_logger.boostLogger) << NFD_LOG_LINE(msg, expression); \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /opt/local/include/boost/log/utility/formatting_ostream.hpp:377:31: note: candidate function not viable: no known conversion from '::nfd::LoggerTimestamp' to 'ios_base_manip' (aka 'std::ios_base &(*)(std::ios_base &)') for 1st argument basic_formatting_ostream& operator<< (ios_base_manip manip) ^ /opt/local/include/boost/log/utility/formatting_ostream.hpp:382:31: note: candidate function not viable: no known conversion from '::nfd::LoggerTimestamp' to 'basic_ios_manip' (aka 'std::basic_ios &(*)(std::basic_ios &)') for 1st argument basic_formatting_ostream& operator<< (basic_ios_manip manip) -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.pesavento at lip6.fr Mon Jul 18 09:23:04 2016 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Mon, 18 Jul 2016 18:23:04 +0200 Subject: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" In-Reply-To: References: Message-ID: Hi Jeff, If I remember correctly, we had the same problem in ndn-cxx during the 2nd NDN hackathon. Basically the type returned by BOOST_LOG() doesn't like the overload of operator<< for LoggerTimestamp. The reasons for this behavior were not further investigated due to lack of time during the hackathon. The workaround we implemented was to feed an empty string to the boost logger before everything else[1]. I remember not everyone on the team was able to reproduce, so I suppose the issue is very much dependent on the compiler and/or boost version used. I don't know why we didn't adopt the same workaround when NFD was switched over to Boost.Log... probably because we couldn't reproduce anymore. Junxiao or Spyros might remember more details. [1] https://github.com/2nd-ndn-hackathon/ndn-cxx-logging/blob/master/src/util/logger.hpp#L107 Thanks, Davide On Mon, Jul 18, 2016 at 5:44 PM, Thompson, Jeff wrote: > Hello NFD developers, > > On a fresh OS X 10.11 virtual machine, I installed MacPorts and did: > > sudo port install pkgconfig boost sqlite3 libcryptopp libpcap > export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig > > I was able to compile and install ndn-cxx. But when I compile NFD I get many > errors starting with those below. Is there an extra configuration step > relating to the logger? > > Thanks, > - Jeff T > > ../daemon/table/cs.cpp:84:3: error: invalid operands to binary expression > ('basic_record_ostream' and '::nfd::LoggerTimestamp') > > NFD_LOG_DEBUG("insert " << data.getName()); > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > /Users/jefft0/work/NFD/core/logger.hpp:154:35: note: expanded from macro > 'NFD_LOG_DEBUG' > > #define NFD_LOG_DEBUG(expression) NFD_LOG(DEBUG, DEBUG, expression) > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > /Users/jefft0/work/NFD/core/logger.hpp:149:39: note: expanded from macro > 'NFD_LOG' > > BOOST_LOG(g_logger.boostLogger) << NFD_LOG_LINE(msg, expression); \ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > /opt/local/include/boost/log/utility/formatting_ostream.hpp:377:31: note: > candidate function not viable: no known conversion from > '::nfd::LoggerTimestamp' to 'ios_base_manip' (aka 'std::ios_base > &(*)(std::ios_base &)') for 1st argument > > basic_formatting_ostream& operator<< (ios_base_manip manip) > > ^ > > /opt/local/include/boost/log/utility/formatting_ostream.hpp:382:31: note: > candidate function not viable: no known conversion from > '::nfd::LoggerTimestamp' to 'basic_ios_manip' (aka > 'std::basic_ios &(*)(std::basic_ios traits_type> &)') for 1st argument > > basic_formatting_ostream& operator<< (basic_ios_manip manip) > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From jefft0 at remap.UCLA.edu Mon Jul 18 09:43:25 2016 From: jefft0 at remap.UCLA.edu (Thompson, Jeff) Date: Mon, 18 Jul 2016 16:43:25 +0000 Subject: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" In-Reply-To: References: Message-ID: Hi Davide, Good hint. logger.hpp has the following line. https://github.com/named-data/NFD/blob/master/core/logger.hpp#L149 BOOST_LOG(g_logger.boostLogger) << NFD_LOG_LINE(msg, expression); \ When I changed it to the following I was able to compile. BOOST_LOG(g_logger.boostLogger) << "" << NFD_LOG_LINE(msg, expression); \ Thanks, - Jeff T On 2016/7/18, 9:23:04, "Davide Pesavento" > wrote: Hi Jeff, If I remember correctly, we had the same problem in ndn-cxx during the 2nd NDN hackathon. Basically the type returned by BOOST_LOG() doesn't like the overload of operator<< for LoggerTimestamp. The reasons for this behavior were not further investigated due to lack of time during the hackathon. The workaround we implemented was to feed an empty string to the boost logger before everything else[1]. I remember not everyone on the team was able to reproduce, so I suppose the issue is very much dependent on the compiler and/or boost version used. I don't know why we didn't adopt the same workaround when NFD was switched over to Boost.Log... probably because we couldn't reproduce anymore. Junxiao or Spyros might remember more details. [1] https://github.com/2nd-ndn-hackathon/ndn-cxx-logging/blob/master/src/util/logger.hpp#L107 Thanks, Davide On Mon, Jul 18, 2016 at 5:44 PM, Thompson, Jeff > wrote: Hello NFD developers, On a fresh OS X 10.11 virtual machine, I installed MacPorts and did: sudo port install pkgconfig boost sqlite3 libcryptopp libpcap export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig I was able to compile and install ndn-cxx. But when I compile NFD I get many errors starting with those below. Is there an extra configuration step relating to the logger? Thanks, - Jeff T ../daemon/table/cs.cpp:84:3: error: invalid operands to binary expression ('basic_record_ostream' and '::nfd::LoggerTimestamp') NFD_LOG_DEBUG("insert " << data.getName()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/jefft0/work/NFD/core/logger.hpp:154:35: note: expanded from macro 'NFD_LOG_DEBUG' #define NFD_LOG_DEBUG(expression) NFD_LOG(DEBUG, DEBUG, expression) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/jefft0/work/NFD/core/logger.hpp:149:39: note: expanded from macro 'NFD_LOG' BOOST_LOG(g_logger.boostLogger) << NFD_LOG_LINE(msg, expression); \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /opt/local/include/boost/log/utility/formatting_ostream.hpp:377:31: note: candidate function not viable: no known conversion from '::nfd::LoggerTimestamp' to 'ios_base_manip' (aka 'std::ios_base &(*)(std::ios_base &)') for 1st argument basic_formatting_ostream& operator<< (ios_base_manip manip) ^ /opt/local/include/boost/log/utility/formatting_ostream.hpp:382:31: note: candidate function not viable: no known conversion from '::nfd::LoggerTimestamp' to 'basic_ios_manip' (aka 'std::basic_ios &(*)(std::basic_ios &)') for 1st argument basic_formatting_ostream& operator<< (basic_ios_manip manip) _______________________________________________ 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 Mon Jul 18 10:05:29 2016 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Mon, 18 Jul 2016 17:05:29 +0000 Subject: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" In-Reply-To: References:

Message-ID: Great, thanks for confirming. Can you open a ticket on redmine please, stating your boost and clang versions? Thanks, Davide On Mon, Jul 18, 2016, 6:51 PM Thompson, Jeff wrote: > Hi Davide, > > Good hint. logger.hpp has the following line. > https://github.com/named-data/NFD/blob/master/core/logger.hpp#L149 > > BOOST_LOG(g_logger.boostLogger) << NFD_LOG_LINE(msg, expression); \ > > When I changed it to the following I was able to compile. > > BOOST_LOG(g_logger.boostLogger) << "" << NFD_LOG_LINE(msg, > expression); \ > > Thanks, > - Jeff T > > On 2016/7/18, 9:23:04, "Davide Pesavento" > wrote: > > Hi Jeff, > > If I remember correctly, we had the same problem in ndn-cxx during the > 2nd NDN hackathon. > > Basically the type returned by BOOST_LOG() doesn't like the overload > of operator<< for LoggerTimestamp. The reasons for this behavior were > not further investigated due to lack of time during the hackathon. The > workaround we implemented was to feed an empty string to the boost > logger before everything else[1]. > > I remember not everyone on the team was able to reproduce, so I > suppose the issue is very much dependent on the compiler and/or boost > version used. I don't know why we didn't adopt the same workaround > when NFD was switched over to Boost.Log... probably because we > couldn't reproduce anymore. > > Junxiao or Spyros might remember more details. > > [1] > https://github.com/2nd-ndn-hackathon/ndn-cxx-logging/blob/master/src/util/logger.hpp#L107 > > Thanks, > Davide > > On Mon, Jul 18, 2016 at 5:44 PM, Thompson, Jeff > wrote: > > Hello NFD developers, > > On a fresh OS X 10.11 virtual machine, I installed MacPorts and did: > > sudo port install pkgconfig boost sqlite3 libcryptopp libpcap > export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig > > I was able to compile and install ndn-cxx. But when I compile NFD I get > many > errors starting with those below. Is there an extra configuration step > relating to the logger? > > Thanks, > - Jeff T > > ../daemon/table/cs.cpp:84:3: error: invalid operands to binary expression > ('basic_record_ostream' and '::nfd::LoggerTimestamp') > > NFD_LOG_DEBUG("insert " << data.getName()); > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > /Users/jefft0/work/NFD/core/logger.hpp:154:35: note: expanded from macro > 'NFD_LOG_DEBUG' > > #define NFD_LOG_DEBUG(expression) NFD_LOG(DEBUG, DEBUG, expression) > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > /Users/jefft0/work/NFD/core/logger.hpp:149:39: note: expanded from macro > 'NFD_LOG' > > BOOST_LOG(g_logger.boostLogger) << NFD_LOG_LINE(msg, expression); \ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > /opt/local/include/boost/log/utility/formatting_ostream.hpp:377:31: note: > candidate function not viable: no known conversion from > '::nfd::LoggerTimestamp' to 'ios_base_manip' (aka 'std::ios_base > &(*)(std::ios_base &)') for 1st argument > > basic_formatting_ostream& operator<< (ios_base_manip manip) > > ^ > > /opt/local/include/boost/log/utility/formatting_ostream.hpp:382:31: note: > candidate function not viable: no known conversion from > '::nfd::LoggerTimestamp' to 'basic_ios_manip' (aka > 'std::basic_ios &(*)(std::basic_ios traits_type> &)') for 1st argument > > basic_formatting_ostream& operator<< (basic_ios_manip manip) > > > > _______________________________________________ > 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 jefft0 at remap.UCLA.edu Mon Jul 18 10:15:37 2016 From: jefft0 at remap.UCLA.edu (Thompson, Jeff) Date: Mon, 18 Jul 2016 17:15:37 +0000 Subject: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" In-Reply-To: References:

Message-ID: https://redmine.named-data.net/issues/3674 From: Davide Pesavento > Date: Monday, July 18, 2016 at 10:05:00 To: Jeff Thompson > Cc: nfd-dev > Subject: Re: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" Great, thanks for confirming. Can you open a ticket on redmine please, stating your boost and clang versions? Thanks, Davide On Mon, Jul 18, 2016, 6:51 PM Thompson, Jeff > wrote: Hi Davide, Good hint. logger.hpp has the following line. https://github.com/named-data/NFD/blob/master/core/logger.hpp#L149 BOOST_LOG(g_logger.boostLogger) << NFD_LOG_LINE(msg, expression); \ When I changed it to the following I was able to compile. BOOST_LOG(g_logger.boostLogger) << "" << NFD_LOG_LINE(msg, expression); \ Thanks, - Jeff T On 2016/7/18, 9:23:04, "Davide Pesavento" > wrote: Hi Jeff, If I remember correctly, we had the same problem in ndn-cxx during the 2nd NDN hackathon. Basically the type returned by BOOST_LOG() doesn't like the overload of operator<< for LoggerTimestamp. The reasons for this behavior were not further investigated due to lack of time during the hackathon. The workaround we implemented was to feed an empty string to the boost logger before everything else[1]. I remember not everyone on the team was able to reproduce, so I suppose the issue is very much dependent on the compiler and/or boost version used. I don't know why we didn't adopt the same workaround when NFD was switched over to Boost.Log... probably because we couldn't reproduce anymore. Junxiao or Spyros might remember more details. [1] https://github.com/2nd-ndn-hackathon/ndn-cxx-logging/blob/master/src/util/logger.hpp#L107 Thanks, Davide On Mon, Jul 18, 2016 at 5:44 PM, Thompson, Jeff > wrote: Hello NFD developers, On a fresh OS X 10.11 virtual machine, I installed MacPorts and did: sudo port install pkgconfig boost sqlite3 libcryptopp libpcap export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig I was able to compile and install ndn-cxx. But when I compile NFD I get many errors starting with those below. Is there an extra configuration step relating to the logger? Thanks, - Jeff T ../daemon/table/cs.cpp:84:3: error: invalid operands to binary expression ('basic_record_ostream' and '::nfd::LoggerTimestamp') NFD_LOG_DEBUG("insert " << data.getName()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/jefft0/work/NFD/core/logger.hpp:154:35: note: expanded from macro 'NFD_LOG_DEBUG' #define NFD_LOG_DEBUG(expression) NFD_LOG(DEBUG, DEBUG, expression) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/jefft0/work/NFD/core/logger.hpp:149:39: note: expanded from macro 'NFD_LOG' BOOST_LOG(g_logger.boostLogger) << NFD_LOG_LINE(msg, expression); \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /opt/local/include/boost/log/utility/formatting_ostream.hpp:377:31: note: candidate function not viable: no known conversion from '::nfd::LoggerTimestamp' to 'ios_base_manip' (aka 'std::ios_base &(*)(std::ios_base &)') for 1st argument basic_formatting_ostream& operator<< (ios_base_manip manip) ^ /opt/local/include/boost/log/utility/formatting_ostream.hpp:382:31: note: candidate function not viable: no known conversion from '::nfd::LoggerTimestamp' to 'basic_ios_manip' (aka 'std::basic_ios &(*)(std::basic_ios &)') for 1st argument basic_formatting_ostream& operator<< (basic_ios_manip manip) _______________________________________________ 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 mrchwdhr at memphis.edu Mon Jul 18 10:34:46 2016 From: mrchwdhr at memphis.edu (Muktadir R Chowdhury (mrchwdhr)) Date: Mon, 18 Jul 2016 17:34:46 +0000 Subject: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" In-Reply-To: References:

, Message-ID: Hi JeffT and Davide, I was also having the same problem on my OSX 10.10.5. The workaround fixes it. Thanks. Muktadir ________________________________ From: Nfd-dev on behalf of Thompson, Jeff Sent: Monday, July 18, 2016 11:15:37 PM To: Davide Pesavento Cc: nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" https://redmine.named-data.net/issues/3674 From: Davide Pesavento > Date: Monday, July 18, 2016 at 10:05:00 To: Jeff Thompson > Cc: nfd-dev > Subject: Re: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" Great, thanks for confirming. Can you open a ticket on redmine please, stating your boost and clang versions? Thanks, Davide On Mon, Jul 18, 2016, 6:51 PM Thompson, Jeff > wrote: Hi Davide, Good hint. logger.hpp has the following line. https://github.com/named-data/NFD/blob/master/core/logger.hpp#L149 BOOST_LOG(g_logger.boostLogger) << NFD_LOG_LINE(msg, expression); \ When I changed it to the following I was able to compile. BOOST_LOG(g_logger.boostLogger) << "" << NFD_LOG_LINE(msg, expression); \ Thanks, - Jeff T On 2016/7/18, 9:23:04, "Davide Pesavento" > wrote: Hi Jeff, If I remember correctly, we had the same problem in ndn-cxx during the 2nd NDN hackathon. Basically the type returned by BOOST_LOG() doesn't like the overload of operator<< for LoggerTimestamp. The reasons for this behavior were not further investigated due to lack of time during the hackathon. The workaround we implemented was to feed an empty string to the boost logger before everything else[1]. I remember not everyone on the team was able to reproduce, so I suppose the issue is very much dependent on the compiler and/or boost version used. I don't know why we didn't adopt the same workaround when NFD was switched over to Boost.Log... probably because we couldn't reproduce anymore. Junxiao or Spyros might remember more details. [1] https://github.com/2nd-ndn-hackathon/ndn-cxx-logging/blob/master/src/util/logger.hpp#L107 Thanks, Davide On Mon, Jul 18, 2016 at 5:44 PM, Thompson, Jeff > wrote: Hello NFD developers, On a fresh OS X 10.11 virtual machine, I installed MacPorts and did: sudo port install pkgconfig boost sqlite3 libcryptopp libpcap export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig I was able to compile and install ndn-cxx. But when I compile NFD I get many errors starting with those below. Is there an extra configuration step relating to the logger? Thanks, - Jeff T ../daemon/table/cs.cpp:84:3: error: invalid operands to binary expression ('basic_record_ostream' and '::nfd::LoggerTimestamp') NFD_LOG_DEBUG("insert " << data.getName()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/jefft0/work/NFD/core/logger.hpp:154:35: note: expanded from macro 'NFD_LOG_DEBUG' #define NFD_LOG_DEBUG(expression) NFD_LOG(DEBUG, DEBUG, expression) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/jefft0/work/NFD/core/logger.hpp:149:39: note: expanded from macro 'NFD_LOG' BOOST_LOG(g_logger.boostLogger) << NFD_LOG_LINE(msg, expression); \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /opt/local/include/boost/log/utility/formatting_ostream.hpp:377:31: note: candidate function not viable: no known conversion from '::nfd::LoggerTimestamp' to 'ios_base_manip' (aka 'std::ios_base &(*)(std::ios_base &)') for 1st argument basic_formatting_ostream& operator<< (ios_base_manip manip) ^ /opt/local/include/boost/log/utility/formatting_ostream.hpp:382:31: note: candidate function not viable: no known conversion from '::nfd::LoggerTimestamp' to 'basic_ios_manip' (aka 'std::basic_ios &(*)(std::basic_ios &)') for 1st argument basic_formatting_ostream& operator<< (basic_ios_manip manip) _______________________________________________ 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 Jul 18 11:58:28 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 18 Jul 2016 11:58:28 -0700 Subject: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" In-Reply-To: References:

, Message-ID: <578d26d5.0536620a.2aea5.ee1b@mx.google.com> Hi JeffT & Muktadir I?ve uploaded the workaround as Change 2952. Can you test it in your environments and see whether it works? https://gerrit.named-data.net/2952 tap the ?download? button on top right corner to checkout the Change Yours, Junxiao From: Muktadir R Chowdhury (mrchwdhr) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefft0 at remap.ucla.edu Mon Jul 18 12:05:39 2016 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Mon, 18 Jul 2016 19:05:39 +0000 Subject: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" In-Reply-To: <578d26d5.0536620a.2aea5.ee1b@mx.google.com> References:

<578d26d5.0536620a.2aea5.ee1b@mx.google.com> Message-ID: Works for me. Thanks, - Jeff T From: Junxiao Shi > Date: Monday, July 18, 2016 at 11:58:00 To: "Muktadir R Chowdhury (mrchwdhr)" >, Jeff Thompson > Cc: nfd-dev > Subject: RE: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" Hi JeffT & Muktadir I?ve uploaded the workaround as Change 2952. Can you test it in your environments and see whether it works? https://gerrit.named-data.net/2952 tap the ?download? button on top right corner to checkout the Change Yours, Junxiao From: Muktadir R Chowdhury (mrchwdhr) Sent: Monday, July 18, 2016 10:35 To: Thompson, Jeff; Davide Pesavento; nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" Hi JeffT and Davide, I was also having the same problem on my OSX 10.10.5. The workaround fixes it. Thanks. Muktadir -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrchwdhr at memphis.edu Mon Jul 18 12:48:15 2016 From: mrchwdhr at memphis.edu (Muktadir R Chowdhury (mrchwdhr)) Date: Mon, 18 Jul 2016 19:48:15 +0000 Subject: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" In-Reply-To: <1dec1498-8c8c-4fd2-b94e-2ea039b458fa@EMHUB5.ad.ucla.edu> References:

<578d26d5.0536620a.2aea5.ee1b@mx.google.com>, <1dec1498-8c8c-4fd2-b94e-2ea039b458fa@EMHUB5.ad.ucla.edu> Message-ID: The patch is working for me too. -Muktadir ________________________________ From: Thompson, Jeff Sent: Tuesday, July 19, 2016 1:05:39 AM To: Junxiao Shi; Muktadir R Chowdhury (mrchwdhr) Cc: nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" Works for me. Thanks, - Jeff T From: Junxiao Shi > Date: Monday, July 18, 2016 at 11:58:00 To: "Muktadir R Chowdhury (mrchwdhr)" >, Jeff Thompson > Cc: nfd-dev > Subject: RE: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" Hi JeffT & Muktadir I?ve uploaded the workaround as Change 2952. Can you test it in your environments and see whether it works? https://gerrit.named-data.net/2952 tap the ?download? button on top right corner to checkout the Change Yours, Junxiao From: Muktadir R Chowdhury (mrchwdhr) Sent: Monday, July 18, 2016 10:35 To: Thompson, Jeff; Davide Pesavento; nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] NFD compile error "NFD_LOG_DEBUG" Hi JeffT and Davide, I was also having the same problem on my OSX 10.10.5. The workaround fixes it. Thanks. Muktadir -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaim.rieger at gmail.com Mon Jul 18 13:05:03 2016 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Mon, 18 Jul 2016 13:05:03 -0700 Subject: [Nfd-dev] Router question Message-ID: Are there any routers, or packaged dd-wrt instances, that have NFD/NDN onboard yet ? -- -- Chaim Rieger From shijunxiao at email.arizona.edu Mon Jul 18 14:40:05 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 18 Jul 2016 14:40:05 -0700 Subject: [Nfd-dev] Router question In-Reply-To: References: Message-ID: <578d4cb6.450f620a.c4030.0d7b@mx.google.com> Hi Chaim Technically any machine that can forward packets is a router, so your laptop is already an NDN router. For OpenWRT and DD-WRT home routers, there?s a guide on how to compile NFD for them: https://redmine.named-data.net/projects/ndn-embedded/wiki/Cross-compiling_NDN_projects_for_home_routers Yours, Junxiao From: Chaim Rieger -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Jul 18 16:10:42 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 18 Jul 2016 16:10:42 -0700 Subject: [Nfd-dev] ndn-cxx deprecated feature removal: makeDummyClientFace andDummyClientFace::sentDatas In-Reply-To: References: Message-ID: <578d61f4.141a620a.cc976.28a7@mx.google.com> Dear folks Deadline has passed. Currently we are waiting for Spyros to merge the nTorrent patch https://gerrit.named-data.net/2934 . Afterwards, we can proceed with the removal commit. Yours, Junxiao From: Junxiao Shi -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Jul 18 16:12:33 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 18 Jul 2016 16:12:33 -0700 Subject: [Nfd-dev] ndn-cxx deprecated feature removal: Name::set Message-ID: <578d6263.d367620a.c1e59.24b7@mx.google.com> Dear folks The following deprecated feature will be removed from ndn-cxx soon: Name::set method => replace with Name constructor If you have code that depend on this feature and cannot be fixed now, please reply no later than Jul 21 12:00 UTC. Otherwise, we'll proceed with the removal after that time. You can compile your projects with ndn-cxx Change https://gerrit.named-data.net/2953 and verify it works. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Tue Jul 19 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 19 Jul 2016 07:00:02 -0700 Subject: [Nfd-dev] NFD call 20160719 Message-ID: <201607191400.u6JE02Cj030193@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Jul 19 12:16:50 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 19 Jul 2016 12:16:50 -0700 Subject: [Nfd-dev] delegate prefix registration In-Reply-To: References: Message-ID: Hi Jeff The blog post promised below has been posted: Issue Your Own NDN Certificates https://yoursunny.com/t/2016/ndncert/ Yours, Junxiao On Wed, Jun 15, 2016 at 4:38 AM, Junxiao Shi wrote: > Hi Jeff > > As indicated in #3568 issue > description, ndncert certificates will be required until #2766 > and related functions are > available. > #2766 itself is blocked by KeyChain refactoring, so it's unlikely to be > available in next 6 months. > > For now, you have to request a user certificate for each and every > machine. You could use subaddressing (see RFC5233 > ) to request certificates for each > machine, such as peter+freeculture at remap.ucla.edu > peter+confbridge at remap.ucla.edu , instead of creating whole new mailboxes. > Note that although you can request multiple user certificates with the > same email address ( peter at remap.ucla.edu ) or copy the same user > certificate onto multiple machines, doing so would cause those machines to > register the same prefix on the router and rely on strategy to determine > the correct route, which can worsen forwarding performance. > > I do have a method to create delegated certificates like what Peter is > trying to do, using only supported software. > The basic idea is to publish certificates on an always-on server, so that > testbed router can retrieve it. > I'll write a blog post about this soon. > > Yours, Junxiao > > On Wed, Jun 15, 2016 at 3:34 AM, Burke, Jeff > wrote: > >> How / when are we going to be able to delegate in this way? >> We have many machines that are not directly associated with a user cert. >> >> Jeff >> >> >> >> *From: *Nfd-dev on behalf of Junxiao >> Shi >> *Date: *Monday, June 13, 2016 at 9:53 PM >> *To: *"Gusev, Peter" >> *Cc: *"" >> *Subject: *Re: [Nfd-dev] [ndn] NDN Seminar: Practical Congestion Control >> for NDN >> >> >> >> These sequence are incorrect. You cannot use any certificate other than >> the one directly requested from ndncert. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lixia at CS.UCLA.EDU Wed Jul 20 14:44:08 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Wed, 20 Jul 2016 14:44:08 -0700 Subject: [Nfd-dev] [Ndn-interest] (NDN-js) query localhost from browser? In-Reply-To: References:

Message-ID: > On Jul 20, 2016, at 2:15 PM, Thompson, Jeff wrote: > > NFD team, any suggestions on scope violation connecting to WebSocket locally? this thread ought to go nfd-dev list > > From: "Ashlesh Gawande (agawande)" > > Date: Wednesday, July 20, 2016 at 14:11:00 > To: Jeff Thompson >, "El Mimouni, Omar Ilias (IntlAssoc)" >, "ndn-interest at lists.cs.ucla.edu " > > Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? > > nfd.conf is same as nfd.conf.sample. > > I have confirmed the scope violation issue by disabling scope checking in NFD. > (Commented out lines 116, 227, 320, 406 in daemon/fw/forwarder.cpp.) > Then the browser gets the data. > > Ashlesh > > From: Thompson, Jeff > > Sent: Wednesday, July 20, 2016 3:55 PM > To: Ashlesh Gawande (agawande); El Mimouni, Omar Ilias (IntlAssoc); ndn-interest at lists.cs.ucla.edu > Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? > > See inline below. > >> From: "Ashlesh Gawande (agawande)" > >> Date: Wednesday, July 20, 2016 at 13:41:00 >> >> I have tried that example and the browser does not get anything. >> NFD logs show that the interest for /localhost/nfd/faces/list is dropped due to scope violation. > > > Is your nfd.conf modified from /usr/local/etc/ndn/nfd.conf.sample , especially in the websocket section? >> >> In https://github.com/named-data/ndn-js/blob/master/examples/browser/test-list-faces.html#L47 >> it says that a Unix socket is used to connect to the local forwarder, but nfd-status shows websocket. > > > Whoopsie! (That?s a typo from copying from the Node.js example.) You?re right. it connects with WebSocket. I fixed the comment. > > Thanks, > - Jeff T >> > > From: Ndn-interest > on behalf of Thompson, Jeff > > Sent: Wednesday, July 20, 2016 3:25:27 PM > To: El Mimouni, Omar Ilias (IntlAssoc); ndn-interest at lists.cs.ucla.edu