From nfd-call-notification at mail1.yoursunny.com Tue Nov 1 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 1 Nov 2016 07:00:02 -0700 Subject: [Nfd-dev] NFD call 20161101 Message-ID: <201611011400.uA1E0277029652@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Nov 1 18:53:23 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 1 Nov 2016 18:53:23 -0700 Subject: [Nfd-dev] NDN Redmine upgraded In-Reply-To: <1206099D-45DD-436D-84A8-1E9B5DA0F942@cs.ucla.edu> References: <1206099D-45DD-436D-84A8-1E9B5DA0F942@cs.ucla.edu> Message-ID: Hi Alex https://redmine.named-data.net/issues/3828#note-8 There's a complaint that a user cannot update Issue Description. I have checked that the user has "developer" role on the project. Is there a privilege problem? Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From malhowaidi at gmail.com Wed Nov 2 11:22:19 2016 From: malhowaidi at gmail.com (Mohammad Alhowaidi) Date: Wed, 2 Nov 2016 13:22:19 -0500 Subject: [Nfd-dev] Content store path Message-ID: Hello, I want to increase the content store size and change the path where the data is cached in the content store, any idea how to do it and is there any limitation on doing it ? Thanks, Mohammad -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Wed Nov 2 12:53:10 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 2 Nov 2016 19:53:10 +0000 Subject: [Nfd-dev] new NFD call times Message-ID: <00D270CE-7AF5-40B0-B15D-62B4CC4DD55C@memphis.edu> Hi all, Here are the new NFD call times that we determined in an earlier NFD call: Tue 12-1pm PDT, Thu 1-2pm PDT. Unfortunately Bluejeans doesn?t allow me to set the time to be different on different days, so I had to create a new NFD call link for Tuesday. Below are the links: Tuesday (starting Nov. 8): https://bluejeans.com/394441725 Thursday (starting Nov. 10): https://bluejeans.com/424982807 I?ll send an ical invite directly from Bluejeans to the nfd-dev mailing list since some people prefer that. Lan From invite at bluejeans.com Wed Nov 2 12:54:18 2016 From: invite at bluejeans.com (Lan Wang via Blue Jeans Network) Date: Wed, 2 Nov 2016 19:54:18 +0000 (UTC) Subject: [Nfd-dev] NFD Call Tuesday Message-ID: <463026329.99081478116458169.JavaMail.denimuser@sj1-app-26-60> To join the meeting on a computer or mobile phone: https://bluejeans.com/394441725?src=textEmail Lan Wang has invited you to a video meeting. Meeting Title: NFD Call Tuesday Meeting Time: Every Tuesday from November 8, 2016 2 p.m. CST / 1 hr ------------------------------------------------ Connecting directly from a room system? 1) Dial: 199.48.152.152 or bjn.vc 2) Enter Meeting ID: 394441725 Just want to dial in on your phone? 1) +1.408.740.7256 (US) +1.888.240.2560 (US Toll Free) +1.408.317.9253 (Alternate number) (http://bluejeans.com/numbers) 2) Enter Meeting ID: 394441725 3) Press # ------------------------------------------------ Want to test your video connection? http://bluejeans.com/111 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1678 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1678 bytes Desc: not available URL: From invite at bluejeans.com Wed Nov 2 12:54:44 2016 From: invite at bluejeans.com (Lan Wang via Blue Jeans Network) Date: Wed, 2 Nov 2016 19:54:44 +0000 (UTC) Subject: [Nfd-dev] NFD Call Thursday Message-ID: <67328314.99101478116484286.JavaMail.denimuser@sj1-app-26-72> To join the meeting on a computer or mobile phone: https://bluejeans.com/424982807?src=textEmail Lan Wang has invited you to a video meeting. Meeting Title: NFD Call Thursday Meeting Time: Every Thursday from November 10, 2016 3 p.m. CST / 1 hr ------------------------------------------------ Connecting directly from a room system? 1) Dial: 199.48.152.152 or bjn.vc 2) Enter Meeting ID: 424982807 Just want to dial in on your phone? 1) +1.408.740.7256 (US) +1.888.240.2560 (US Toll Free) +1.408.317.9253 (Alternate number) (http://bluejeans.com/numbers) 2) Enter Meeting ID: 424982807 3) Press # ------------------------------------------------ Want to test your video connection? http://bluejeans.com/111 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1679 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1679 bytes Desc: not available URL: From nfd-call-notification at mail1.yoursunny.com Thu Nov 3 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 3 Nov 2016 07:00:02 -0700 Subject: [Nfd-dev] NFD call 20161103 Message-ID: <201611031400.uA3E02v2007978@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Thu Nov 3 07:03:02 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Thu, 3 Nov 2016 14:03:02 +0000 Subject: [Nfd-dev] NFD call 20161103 In-Reply-To: <201611031400.uA3E02v2007978@lectura.cs.arizona.edu> References: <201611031400.uA3E02v2007978@lectura.cs.arizona.edu> Message-ID: This call is canceled. Lan On Nov 3, 2016, at 8:00 AM, NFD call notification > wrote: Dear folks This is a reminder of the upcoming NFD call using Bluejeans https://bluejeans.com/424982807. The current call time is every Tuesday/Thursday 13:00-14:00 Arizona Time. The current agenda includes the following issues: ________________________________ https://redmine.named-data.net/issues/2237 Remote prefix registration: fetch certificates from requester need: Zhiyi https://redmine.named-data.net/issues/3800 NDN-FCH in autoconfig need: Gregory https://redmine.named-data.net/issues/3640 ECDSA validation need: Zhiyi https://redmine.named-data.net/issues/3823 Discuss some more details of the link loss detection design need: Klaus, Junxiao, Eric https://redmine.named-data.net/issues/3827 inaccuracy in ndnSIM documentation and NFD devguide need: Spyros, Lixia https://redmine.named-data.net/issues/3836 localhop scope need: Beichuan, Lan, Junxiao _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Nov 3 10:47:32 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 3 Nov 2016 11:47:32 -0600 Subject: [Nfd-dev] Code formatter/beautifier In-Reply-To: <87247931-65d8-232c-4e0b-d7381c7e6f19@memphis.edu> References: <87247931-65d8-232c-4e0b-d7381c7e6f19@memphis.edu> Message-ID: <581b7837.06a76b0a.1132d.d10f@mx.google.com> Hi Nick I heard there are someone using clang-format, but I haven't heard anyone being able to create a clang-format configuration that ensures 100% compliance. Thus, I still recommend developers to memorize all style rules and ensure compliance the moment you type it. I heard from a Google engineer that they use Eclipse to ensure Google code style compliance. I'm unsure whether it's possible with ndn-cxx rules. ndnSIM has defined their rules in terms of a particular clang-format configuration, which could be a solution. However, relying on a tool as the rules is similar to defining a network protocol in terms of a specific implementation, which could cause inter-operability problems. Yours, Junxiao -----Original Message----- From: "Nick Gordon" Sent: ?11/?3/?2016 11:36 To: "Junxiao Shi" Subject: Code formatter/beautifier Junxiao, In an attempt to smooth out style issues, I intend to use a formatter. It appears that there is a well-known program, "clang-format", that does this. Do you have any system that you use to format your code that I should know about? -Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at ucla.edu Thu Nov 3 11:06:18 2016 From: wentaoshang at ucla.edu (Wentao Shang) Date: Thu, 3 Nov 2016 12:06:18 -0600 Subject: [Nfd-dev] Code formatter/beautifier In-Reply-To: <581b7837.06a76b0a.1132d.d10f@mx.google.com> References: <87247931-65d8-232c-4e0b-d7381c7e6f19@memphis.edu> <581b7837.06a76b0a.1132d.d10f@mx.google.com> Message-ID: <4AF300FF-047B-4933-B379-6EEE6E25F1E9@ucla.edu> > On Nov 3, 2016, at 11:47 AM, Junxiao Shi wrote: > > Hi Nick > > I heard there are someone using clang-format, but I haven't heard anyone being able to create a clang-format configuration that ensures 100% compliance. > Thus, I still recommend developers to memorize all style rules and ensure compliance the moment you type it. > > I heard from a Google engineer that they use Eclipse to ensure Google code style compliance. I'm unsure whether it's possible with ndn-cxx rules. Inside Google, the auto-formatting tool is integrated into all the source control tools and text editors. You can either do ?git clang-format? before you push, or (more preferably) add a hook to your emacs/vim editor that formats the code automatically on save. As a lazy person, I highly recommend the second approach, provided that we can patch clang to support our formatting rules in ndn-cxx. Wentao > > ndnSIM has defined their rules in terms of a particular clang-format configuration, which could be a solution. However, relying on a tool as the rules is similar to defining a network protocol in terms of a specific implementation, which could cause inter-operability problems. > > Yours, Junxiao > From: Nick Gordon > Sent: ?11/?3/?2016 11:36 > To: Junxiao Shi > Subject: Code formatter/beautifier > > Junxiao, > > In an attempt to smooth out style issues, I intend to use a formatter. > It appears that there is a well-known program, "clang-format", that does > this. Do you have any system that you use to format your code that I > should know about? > > -Nick > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From aa at CS.UCLA.EDU Thu Nov 3 11:07:09 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Thu, 3 Nov 2016 12:07:09 -0600 Subject: [Nfd-dev] Code formatter/beautifier In-Reply-To: <581b7837.06a76b0a.1132d.d10f@mx.google.com> References: <87247931-65d8-232c-4e0b-d7381c7e6f19@memphis.edu> <581b7837.06a76b0a.1132d.d10f@mx.google.com> Message-ID: The standard version of clang-format (at least as of year ago) allows only limited customization. Our current style not really expressable with clang-format rules (I did some patching that got closer, but still not the same: https://github.com/named-data-ndnSIM/ndnSIM/blob/master/.clang-format). Potentially a good way of solving this problem is to select a more standard style (e.g., Google), which will make all the automation work. -- Alex > On Nov 3, 2016, at 11:47 AM, Junxiao Shi wrote: > > Hi Nick > > I heard there are someone using clang-format, but I haven't heard anyone being able to create a clang-format configuration that ensures 100% compliance. > Thus, I still recommend developers to memorize all style rules and ensure compliance the moment you type it. > > I heard from a Google engineer that they use Eclipse to ensure Google code style compliance. I'm unsure whether it's possible with ndn-cxx rules. > > ndnSIM has defined their rules in terms of a particular clang-format configuration, which could be a solution. However, relying on a tool as the rules is similar to defining a network protocol in terms of a specific implementation, which could cause inter-operability problems. > > Yours, Junxiao > From: Nick Gordon > Sent: ?11/?3/?2016 11:36 > To: Junxiao Shi > Subject: Code formatter/beautifier > > Junxiao, > > In an attempt to smooth out style issues, I intend to use a formatter. > It appears that there is a well-known program, "clang-format", that does > this. Do you have any system that you use to format your code that I > should know about? > > -Nick > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From mastorakis at CS.UCLA.EDU Thu Nov 3 11:09:00 2016 From: mastorakis at CS.UCLA.EDU (Spyridon (Spyros) Mastorakis) Date: Thu, 3 Nov 2016 11:09:00 -0700 Subject: [Nfd-dev] Code formatter/beautifier In-Reply-To: <4AF300FF-047B-4933-B379-6EEE6E25F1E9@ucla.edu> References: <87247931-65d8-232c-4e0b-d7381c7e6f19@memphis.edu> <581b7837.06a76b0a.1132d.d10f@mx.google.com> <4AF300FF-047B-4933-B379-6EEE6E25F1E9@ucla.edu> Message-ID: <72293445-6710-403B-8897-013FE3DC00DC@cs.ucla.edu> I agree with Wentao. The auto-formatting script should be triggered when you push a commit for code review. We cannot ask people to memorize all the coding style rules. Spyros Spyridon (Spyros) Mastorakis Personal Website: http://cs.ucla.edu/~mastorakis/ Internet Research Laboratory Computer Science Department UCLA > On Nov 3, 2016, at 11:06 AM, Wentao Shang wrote: > >> >> On Nov 3, 2016, at 11:47 AM, Junxiao Shi > wrote: >> >> Hi Nick >> >> I heard there are someone using clang-format, but I haven't heard anyone being able to create a clang-format configuration that ensures 100% compliance. >> Thus, I still recommend developers to memorize all style rules and ensure compliance the moment you type it. >> >> I heard from a Google engineer that they use Eclipse to ensure Google code style compliance. I'm unsure whether it's possible with ndn-cxx rules. > > Inside Google, the auto-formatting tool is integrated into all the source control tools and text editors. You can either do ?git clang-format? before you push, or (more preferably) add a hook to your emacs/vim editor that formats the code automatically on save. As a lazy person, I highly recommend the second approach, provided that we can patch clang to support our formatting rules in ndn-cxx. > > Wentao > >> >> ndnSIM has defined their rules in terms of a particular clang-format configuration, which could be a solution. However, relying on a tool as the rules is similar to defining a network protocol in terms of a specific implementation, which could cause inter-operability problems. >> >> Yours, Junxiao >> From: Nick Gordon >> Sent: ?11/?3/?2016 11:36 >> To: Junxiao Shi >> Subject: Code formatter/beautifier >> >> Junxiao, >> >> In an attempt to smooth out style issues, I intend to use a formatter. >> It appears that there is a well-known program, "clang-format", that does >> this. Do you have any system that you use to format your code that I >> should know about? >> >> -Nick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhasabet at gmail.com Thu Nov 3 11:10:04 2016 From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet) Date: Thu, 3 Nov 2016 21:40:04 +0330 Subject: [Nfd-dev] Code formatter/beautifier In-Reply-To: References: <87247931-65d8-232c-4e0b-d7381c7e6f19@memphis.edu> <581b7837.06a76b0a.1132d.d10f@mx.google.com> Message-ID: Alex, You mean to change style of ndn codebase? Maybe starts with ndnSIM new release? Sabet On Nov 3, 2016 9:37 PM, "Alex Afanasyev" wrote: > The standard version of clang-format (at least as of year ago) allows only > limited customization. Our current style not really expressable with > clang-format rules (I did some patching that got closer, but still not the > same: https://github.com/named-data-ndnSIM/ndnSIM/blob/master/. > clang-format). > > Potentially a good way of solving this problem is to select a more > standard style (e.g., Google), which will make all the automation work. > > -- > Alex > > > On Nov 3, 2016, at 11:47 AM, Junxiao Shi > wrote: > > > > Hi Nick > > > > I heard there are someone using clang-format, but I haven't heard anyone > being able to create a clang-format configuration that ensures 100% > compliance. > > Thus, I still recommend developers to memorize all style rules and > ensure compliance the moment you type it. > > > > I heard from a Google engineer that they use Eclipse to ensure Google > code style compliance. I'm unsure whether it's possible with ndn-cxx rules. > > > > ndnSIM has defined their rules in terms of a particular clang-format > configuration, which could be a solution. However, relying on a tool as the > rules is similar to defining a network protocol in terms of a specific > implementation, which could cause inter-operability problems. > > > > Yours, Junxiao > > From: Nick Gordon > > Sent: ?11/?3/?2016 11:36 > > To: Junxiao Shi > > Subject: Code formatter/beautifier > > > > Junxiao, > > > > In an attempt to smooth out style issues, I intend to use a formatter. > > It appears that there is a well-known program, "clang-format", that does > > this. Do you have any system that you use to format your code that I > > should know about? > > > > -Nick > > > > _______________________________________________ > > 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 Thu Nov 3 15:08:02 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 3 Nov 2016 15:08:02 -0700 Subject: [Nfd-dev] Content store path In-Reply-To: References: Message-ID: Hi Mohammad CS capacity is controlled in NFD configuration file (nfd.conf), tables.cs_max_packets key CS data is stored in memory, not under a filesystem path. Yours, Junxiao On Wed, Nov 2, 2016 at 11:22 AM, Mohammad Alhowaidi wrote: > Hello, > > I want to increase the content store size and change the path where the > data is cached in the content store, any idea how to do it and is there any > limitation on doing it ? > > Thanks, > Mohammad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Tue Nov 8 06:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 8 Nov 2016 07:00:02 -0700 Subject: [Nfd-dev] NFD call 20161108 Message-ID: <201611081400.uA8E02PU026379@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From invite at bluejeans.com Wed Nov 9 14:28:52 2016 From: invite at bluejeans.com (Lan Wang via Blue Jeans Network) Date: Wed, 9 Nov 2016 22:28:52 +0000 (UTC) Subject: [Nfd-dev] Updated: NDN Development Call Tuesday Message-ID: <501381372.163631478730532099.JavaMail.denimuser@sj1-app-26-60> To join the meeting on a computer or mobile phone: https://bluejeans.com/394441725?src=textEmail Lan Wang has updated the information for your video meeting. Meeting Title (Updated): NDN Development Call Tuesday Meeting Time: Every Tuesday from November 8, 2016 2 p.m. CST / 1 hr ------------------------------------------------ Connecting directly from a room system? 1) Dial: 199.48.152.152 or bjn.vc 2) Enter Meeting ID: 394441725 Just want to dial in on your phone? 1) +1.408.740.7256 (US) +1.888.240.2560 (US Toll Free) +1.408.317.9253 (Alternate number) (http://bluejeans.com/numbers) 2) Enter Meeting ID: 394441725 3) Press # ------------------------------------------------ Want to test your video connection? http://bluejeans.com/111 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1690 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1690 bytes Desc: not available URL: From invite at bluejeans.com Wed Nov 9 14:29:25 2016 From: invite at bluejeans.com (Lan Wang via Blue Jeans Network) Date: Wed, 9 Nov 2016 22:29:25 +0000 (UTC) Subject: [Nfd-dev] Updated: NDN Platform Development Call Thursday Message-ID: <1779963836.163601478730565293.JavaMail.denimuser@sj1-app-26-67> To join the meeting on a computer or mobile phone: https://bluejeans.com/424982807?src=textEmail Lan Wang has updated the information for your video meeting. Meeting Title (Updated): NDN Platform Development Call Thursday Meeting Time: Every Thursday from November 10, 2016 3 p.m. CST / 1 hr ------------------------------------------------ Connecting directly from a room system? 1) Dial: 199.48.152.152 or bjn.vc 2) Enter Meeting ID: 424982807 Just want to dial in on your phone? 1) +1.408.740.7256 (US) +1.888.240.2560 (US Toll Free) +1.408.317.9253 (Alternate number) (http://bluejeans.com/numbers) 2) Enter Meeting ID: 424982807 3) Press # ------------------------------------------------ Want to test your video connection? http://bluejeans.com/111 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1700 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1700 bytes Desc: not available URL: From invite at bluejeans.com Wed Nov 9 14:29:34 2016 From: invite at bluejeans.com (Lan Wang via Blue Jeans Network) Date: Wed, 9 Nov 2016 22:29:34 +0000 (UTC) Subject: [Nfd-dev] Updated: NDN Platform Development Call Tuesday Message-ID: <947361688.163621478730574437.JavaMail.denimuser@sj1-app-26-67> To join the meeting on a computer or mobile phone: https://bluejeans.com/394441725?src=textEmail Lan Wang has updated the information for your video meeting. Meeting Title (Updated): NDN Platform Development Call Tuesday Meeting Time: Every Tuesday from November 8, 2016 2 p.m. CST / 1 hr ------------------------------------------------ Connecting directly from a room system? 1) Dial: 199.48.152.152 or bjn.vc 2) Enter Meeting ID: 394441725 Just want to dial in on your phone? 1) +1.408.740.7256 (US) +1.888.240.2560 (US Toll Free) +1.408.317.9253 (Alternate number) (http://bluejeans.com/numbers) 2) Enter Meeting ID: 394441725 3) Press # ------------------------------------------------ Want to test your video connection? http://bluejeans.com/111 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1699 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1699 bytes Desc: not available URL: From nfd-call-notification at mail1.yoursunny.com Thu Nov 10 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 10 Nov 2016 08:00:02 -0700 Subject: [Nfd-dev] NFD call 20161110 Message-ID: <201611101500.uAAF02hi004889@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Tue Nov 15 06:00:03 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 15 Nov 2016 07:00:03 -0700 Subject: [Nfd-dev] NFD call 20161115 Message-ID: <201611151400.uAFE03QW016200@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From f80120 at ulusofona.pt Wed Nov 16 02:55:13 2016 From: f80120 at ulusofona.pt (Seweryn Dynerowicz) Date: Wed, 16 Nov 2016 10:55:13 +0000 Subject: [Nfd-dev] On the necessity of the STRAGGLER timer Message-ID: Dear NDN Developers, I'm currently investigating how to implement a Long-Lived Interest concept into NDN. In the process of reading the documentation and code (forwarder.cpp), I keep wondering about the STRAGGLER timer which makes me question the need for having one. According to the dev-guide, STRAGGLER serves a double purpose; loop detection and data measurements. For LOOP DETECTION, all I see is that STRAGGLER delays the transfer of the Nonces from the Out-Records to the DeadNonceList (DNL). It seems to me that no detection capability would be lost if the Nonces were transferred directly to DNL instead of starting STRAGGLER. As for the DATA MEASUREMENTS, I do not see why the PIT entry has to be involved in it. It seems to me that with a bit of rewriting, the NameTree could be used directly for the lookup which means that the PIT entry would not be required in the DATA MEASUREMENTS aspect. However, I might be missing something about the scope and nature of MEASUREMENTS foreseen for NDN. p.s. I want to make those modifications but I'd like to know if you will be interested by them :) Best regards, S. +----------------------------------------------+ | Dynerowicz Seweryn | | PostDoc Researcher | | SITI, COPELABS, Building U | | Universidade Lus?fona | | Campo Grande, 388, 1749-024 Lisboa, Portugal | | Mobile: +351 913 930 302 | +----------------------------------------------+ I hate the empty set; he's so full of himself. "Judge a man by his questions rather than his answers", Pierre-Marc Gaston, Duc de L?vis "Ignorance more frequently begets confidence than does knowledge.", C. Darwin "Seek freedom and become captive of your desires. Seek discipline and find your liberty.", F. Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Nov 16 03:28:02 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 16 Nov 2016 04:28:02 -0700 Subject: [Nfd-dev] On the necessity of the STRAGGLER timer In-Reply-To: References: Message-ID: Hi Seweryn Straggler timer delays transferring Nonces from PIT out-records to DNL, in order to keep DNL small. PIT entry is needed for Data measurements, because strategy needs to know which Interest is being satisfied by the incoming Data (recall that Interest name is a prefix of Data name and thus may be shorter than the Data name), and when that Interest was forwarded (so as to calculate RTT). Neither information is available in NameTree. Yours, Junxiao On Wed, Nov 16, 2016 at 3:55 AM, Seweryn Dynerowicz wrote: > Dear NDN Developers, > > I'm currently investigating how to implement a Long-Lived Interest concept > into NDN. > In the process of reading the documentation and code (forwarder.cpp), I > keep wondering > about the STRAGGLER timer which makes me question the need for having one. > > According to the dev-guide, STRAGGLER serves a double purpose; loop > detection and data > measurements. > > For LOOP DETECTION, all I see is that STRAGGLER delays the transfer of the > Nonces from > the Out-Records to the DeadNonceList (DNL). It seems to me that no > detection capability > would be lost if the Nonces were transferred directly to DNL instead of > starting STRAGGLER. > > As for the DATA MEASUREMENTS, I do not see why the PIT entry has to be > involved in it. > It seems to me that with a bit of rewriting, the NameTree could be used > directly for the lookup > which means that the PIT entry would not be required in the DATA > MEASUREMENTS aspect. However, > I might be missing something about the scope and nature of MEASUREMENTS > foreseen for NDN. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f80120 at ulusofona.pt Wed Nov 16 05:11:18 2016 From: f80120 at ulusofona.pt (Seweryn Dynerowicz) Date: Wed, 16 Nov 2016 13:11:18 +0000 Subject: [Nfd-dev] On the necessity of the STRAGGLER timer In-Reply-To: References: Message-ID: Dear Junxiao, On 16 November 2016 at 11:28, Junxiao Shi wrote: > > Straggler timer delays transferring Nonces from PIT out-records to DNL, in > order to keep DNL small. > >From their definitions, an Out-Record weighs 160 bits while a DNL entry occupies 64 bits so I assume you mean "small" in the sense of the number of entries. If the worry is about lookup time, then isn't it a matter of improving the data structure underlying the DNL ? > PIT entry is needed for Data measurements, because strategy needs to know > which Interest is being satisfied by the incoming Data (recall that > Interest name is a prefix of Data name and thus may be shorter than the > Data name), and when that Interest was forwarded (so as to calculate RTT). > Neither information is available in NameTree. > Why does the Strategy need to know that ? The basic behaviour of ICN for forwarding back DATA is the breadcrumbs, so you only need to send to the IN-Faces for the matching PIT entries. How does this differ in NDN ? Regarding the RTT computation, when incoming Data is received, the IN-Records (and therefore the specific Interest packets being satisfied) are removed. So you only compute the RTT for the first Data packet which satisfies the Interest, right ? If you're only interested in RTT, the OUT-Records do not enable you to do anything useful regarding that so they could be removed straightaway without waiting for STRAGGLER. Best regards, S. +----------------------------------------------+ | Dynerowicz Seweryn | | PostDoc Researcher | | SITI, COPELABS, Building U | | Universidade Lus?fona | | Campo Grande, 388, 1749-024 Lisboa, Portugal | | Mobile: +351 913 930 302 | +----------------------------------------------+ I hate the empty set; he's so full of himself. "Judge a man by his questions rather than his answers", Pierre-Marc Gaston, Duc de L?vis "Ignorance more frequently begets confidence than does knowledge.", C. Darwin "Seek freedom and become captive of your desires. Seek discipline and find your liberty.", F. Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus at cs.arizona.edu Wed Nov 16 13:51:40 2016 From: klaus at cs.arizona.edu (Klaus Schneider) Date: Wed, 16 Nov 2016 14:51:40 -0700 Subject: [Nfd-dev] On the necessity of the STRAGGLER timer In-Reply-To: References: Message-ID: On 11/16/2016 06:11 AM, Seweryn Dynerowicz wrote: > Dear Junxiao, > > On 16 November 2016 at 11:28, Junxiao Shi > wrote: > > Straggler timer delays transferring Nonces from PIT out-records to > DNL, in order to keep DNL small. > > > From their definitions, an Out-Record weighs 160 bits while a DNL entry > occupies 64 bits so I assume > you mean "small" in the sense of the number of entries. If the worry is > about lookup time, then isn't > it a matter of improving the data structure underlying the DNL ? I think Junxiao refers to Section 4.2.8 Interest Finalize Pipeline: "The Dead Nonce List is a global data structure designed to detect looping Interests, and we want to insert as few Nonces as possible to keep its size down." Another reason I can think off, is that historically there was no DNL and thus the straggler timer was used to detect loops. So you might be right, that the straggler timer is less important in the current NFD version. > > PIT entry is needed for Data measurements, because strategy needs to > know which Interest is being satisfied by the incoming Data (recall > that Interest name is a prefix of Data name and thus may be shorter > than the Data name), and when that Interest was forwarded (so as to > calculate RTT). Neither information is available in NameTree. > > > Why does the Strategy need to know that ? The basic behaviour of ICN for > forwarding back DATA is the breadcrumbs, so you only need to send to the > IN-Faces > for the matching PIT entries. How does this differ in NDN ? > > Regarding the RTT computation, when incoming Data is received, the > IN-Records (and therefore the specific Interest packets being satisfied) > are removed. Are they? > So you only compute the RTT for the first Data packet which satisfies > the Interest, right ? If you're only interested in RTT, the OUT-Records > do not enable you > to do anything useful regarding that so they could be removed > straightaway without waiting for STRAGGLER. I don't know about the specifics, but in principle the straggler timer should help you to do measurements of more then the fastest interface. Whenever you send out Interests on multiple faces (either in parallel or sequential) it can be useful to wait a little longer for responses (Data or NACKs). In addition to maintaining different RTT estimates, you could store information about a probed path being up (receiving another Data) or down (receiving a NACK), packet loss estimates, or other information. I've used the functionality enabled by the straggler timer extensively in my previous work: http://conferences2.sigcomm.org/acm-icn/2015/proceedings/p137-schneider.pdf Best regards, Klaus > > > Best regards, > > S. > > +----------------------------------------------+ > | Dynerowicz Seweryn | > | PostDoc Researcher | > | SITI, COPELABS, Building U | > | Universidade Lus?fona | > | Campo Grande, 388, 1749-024 Lisboa, Portugal | > | Mobile: +351 913 930 302 > | > +----------------------------------------------+ > > I hate the empty set; he's so full of himself. > > "Judge a man by his questions rather than his answers", > Pierre-Marc Gaston, Duc de L?vis > > "Ignorance more frequently begets confidence than does knowledge.", > C. Darwin > > "Seek freedom and become captive of your desires. Seek discipline > and find your liberty.", F. Herbert > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From malhowaidi at gmail.com Wed Nov 16 16:49:36 2016 From: malhowaidi at gmail.com (Mohammad Alhowaidi) Date: Wed, 16 Nov 2016 18:49:36 -0600 Subject: [Nfd-dev] reset content store Message-ID: Hello, How to delete nfd content store content? Is restarting nfd will delete the content store content? Thanks, Mohammad -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Nov 16 19:15:39 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 16 Nov 2016 20:15:39 -0700 Subject: [Nfd-dev] reset content store In-Reply-To: References: Message-ID: Hi Mohammad Yes, restarting NFD clears all tables, including the ContentStore. Yours, Junxiao On Nov 16, 2016 5:49 PM, "Mohammad Alhowaidi" wrote: > Hello, > > How to delete nfd content store content? Is restarting nfd will delete the > content store content? > > Thanks, > Mohammad > > _______________________________________________ > 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 f80120 at ulusofona.pt Thu Nov 17 03:09:20 2016 From: f80120 at ulusofona.pt (Seweryn Dynerowicz) Date: Thu, 17 Nov 2016 11:09:20 +0000 Subject: [Nfd-dev] On the necessity of the STRAGGLER timer In-Reply-To: References: Message-ID: Dear Klaus, On 16 November 2016 at 21:51, Klaus Schneider wrote: > > I think Junxiao refers to Section 4.2.8 > Interest Finalize Pipeline: "The Dead Nonce List is a global data > structure designed to detect looping Interests, and we want to insert as > few Nonces as possible to keep its size down." > The way I understand this specific point is that we do not want to insert the Nonce for every single Interest we ever receive. This is precisely what the next sentence states; "Only outgoing Nonces (in out-records) need to be inserted, because an incoming Nonce that has never been sent out won't loop back." In the current implementation, I only see two cases where a Nonce is not transferred from an OUT-Record to the DNL; - the condition in insertDeadNonceList determines that there is no need to save it in DNL - a new Interest arrived and was selected to be sent out the Face referenced in the OUT-Record thereby overwriting the Nonce of the previous Interest without placing it in DNL The condition in the first case will not change between the moment the STRAGGLER timer is started and the moment onInterestFinalize actually runs given that the parameters that will be passed to insertDeadNonceList are set upon starting STRAGGLER. As for the second case, I think it is an error, as it means that if the previous Interest actually loops back, the node will fail to identify it as a loop. The rest of the time, a Nonce is transferred to the DNL and STRAGGLER only delays that transfer. Another reason I can think off, is that historically there was no DNL and > thus the straggler timer was used to detect loops. So you might be right, > that the straggler timer is less important in the current NFD version. The times they are a changin' :) Regarding the RTT computation, when incoming Data is received, the >> IN-Records (and therefore the specific Interest packets being satisfied) >> are removed. >> > > Are they? Yes. Section 4.3.1. bullet 7. of the pipeline which is consistent with the onIncomingData pipeline code (I noticed some discrepancies) So you only compute the RTT for the first Data packet which satisfies >> the Interest, right ? If you're only interested in RTT, the OUT-Records >> do not enable you >> to do anything useful regarding that so they could be removed >> straightaway without waiting for STRAGGLER. >> > > I don't know about the specifics, but in principle the straggler timer > should help you to do measurements of more then the fastest interface. > Whenever you send out Interests on multiple faces (either in parallel or > sequential) it can be useful to wait a little longer for responses (Data or > NACKs). > I agree, that would be one reason to have the STRAGGLER timer. But as the RTT is a measure of how fast the last Interest up a certain path was satisfied, wouldn't it make more sense to use the FIB to keep track of the RTT ? In addition to maintaining different RTT estimates, you could store > information about a probed path being up (receiving another Data) or down > (receiving a NACK), packet loss estimates, or other information. > Ditto. > I've used the functionality enabled by the straggler timer extensively in > my previous work: http://conferences2.sigcomm.org/acm-icn/2015/proceedin > gs/p137-schneider.pdf Thank you for the reference. Best regards, S. +----------------------------------------------+ | Dynerowicz Seweryn | | PostDoc Researcher | | SITI, COPELABS, Building U | | Universidade Lus?fona | | Campo Grande, 388, 1749-024 Lisboa, Portugal | | Mobile: +351 913 930 302 | +----------------------------------------------+ I hate the empty set; he's so full of himself. "Judge a man by his questions rather than his answers", Pierre-Marc Gaston, Duc de L?vis "Ignorance more frequently begets confidence than does knowledge.", C. Darwin "Seek freedom and become captive of your desires. Seek discipline and find your liberty.", F. Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Mosko at parc.com Thu Nov 17 03:56:29 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Thu, 17 Nov 2016 11:56:29 +0000 Subject: [Nfd-dev] On the necessity of the STRAGGLER timer In-Reply-To: References: Message-ID: Two comments below On Nov 17, 2016, at 8:09 PM, Seweryn Dynerowicz > wrote: Dear Klaus, On 16 November 2016 at 21:51, Klaus Schneider > wrote: I think Junxiao refers to Section 4.2.8 Interest Finalize Pipeline: "The Dead Nonce List is a global data structure designed to detect looping Interests, and we want to insert as few Nonces as possible to keep its size down." The way I understand this specific point is that we do not want to insert the Nonce for every single Interest we ever receive. This is precisely what the next sentence states; "Only outgoing Nonces (in out-records) need to be inserted, because an incoming Nonce that has never been sent out won't loop back.? This is incorrect, or at best it?s a limited definition of loop. You could have a first Interest with nonce A that would, if nothing else happened, form a cycle and need to be dropped. however, at another node, that first Interest could be aggregated with a second Interest with nonce B, and it is that second Interest that loops. Then B might get aggregated with the node that sent A in the first place, and neither loop is detected because there was no duplicate nonces, only aggregations that will eventually timeout. One could ask, did a loop really happen in that case? I think if you are forming an equivalency class on Interests based on aggregation similarity, then yes a loop did happen. [snip] So you only compute the RTT for the first Data packet which satisfies the Interest, right ? If you're only interested in RTT, the OUT-Records do not enable you to do anything useful regarding that so they could be removed straightaway without waiting for STRAGGLER. I don't know about the specifics, but in principle the straggler timer should help you to do measurements of more then the fastest interface. Whenever you send out Interests on multiple faces (either in parallel or sequential) it can be useful to wait a little longer for responses (Data or NACKs). I agree, that would be one reason to have the STRAGGLER timer. But as the RTT is a measure of how fast the last Interest up a certain path was satisfied, wouldn't it make more sense to use the FIB to keep track of the RTT ? I disagree with this last statement too. There is nothing in a response that identifies which request triggered the response. If a forwarder has sent two Interests upstream on the same path you don?t know if you are measuring the time from the 1st interest to the response (a long time) or the time from the 2nd interest to the response (a shorter time). Because you have replaced the out record, I think you will only measure the shorter time, which could be incorrect. Personally, I think measuring response time at the granularity of the FIB (which I believe is what these come down to) is not a principled thing to do. A producer may be serving multiple classes of traffic under one FIB entry, such as very quick static content and very slow dynamically generated content. In that example, there is really a bi-modal RTT distribution and if you average them you will have an RTT estimate that is wrong for both classes of traffic. If one were to measure 2nd order statistics, perhaps one could get a 2-sigma or 3-sigma interval, but I?m not sure that?s really useful for anything at a forwarder. Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From f80120 at ulusofona.pt Thu Nov 17 05:57:33 2016 From: f80120 at ulusofona.pt (Seweryn Dynerowicz) Date: Thu, 17 Nov 2016 13:57:33 +0000 Subject: [Nfd-dev] On the necessity of the STRAGGLER timer In-Reply-To: References: Message-ID: Dear Marc, Thanks for this input, my replies are nested below. On 17 November 2016 at 11:56, wrote: > Two comments below > > On Nov 17, 2016, at 8:09 PM, Seweryn Dynerowicz > wrote: > > Dear Klaus, > > On 16 November 2016 at 21:51, Klaus Schneider > wrote: >> >> I think Junxiao refers to Section 4.2.8 >> Interest Finalize Pipeline: "The Dead Nonce List is a global data >> structure designed to detect looping Interests, and we want to insert as >> few Nonces as possible to keep its size down." >> > > The way I understand this specific point is that we do not want to insert > the Nonce for every single Interest we ever receive. This is precisely > what the next sentence states; > > "Only outgoing Nonces (in out-records) need to be inserted, because an > incoming Nonce that has never been sent out won't loop back.? > > > This is incorrect, or at best it?s a limited definition of loop. You > could have a first Interest with nonce A that would, if nothing else > happened, form a cycle and need to be dropped. however, at another node, > that first Interest could be aggregated with a second Interest with nonce > B, and it is that second Interest that loops. Then B might get aggregated > with the node that sent A in the first place, and neither loop is detected > because there was no duplicate nonces, only aggregations that will > eventually timeout. One could ask, did a loop really happen in that case? > I think if you are forming an equivalency class on Interests based on > aggregation similarity, then yes a loop did happen. > I agree. From the perspective of the implementation, it seems that the source of the problem you're pointing out is that the Forwarder implements a loop detection scheme which makes assumptions on how the Strategy behave (to make it worse it makes assumptions on how other nodes Strategy behaves). The first case you describe occurs with a Strategy which, for a given Name, forwards EITHER all Interests it receives without changing their Nonce OR none. The second case (aggregation) occurs with a Strategy which decides to only forward some strict subset of the Interests it receives for a given Name. To guarantee that the implemented scheme detects all loops, all the nodes must be using the first Strategy. If any node uses the second Strategy, this introduces the possibility of a non-detectable Interest loop. A more strict scheme for Loop detection (i.e. keep track of traversed nodes) seems to be necessary. > So you only compute the RTT for the first Data packet which satisfies >>> the Interest, right ? If you're only interested in RTT, the OUT-Records >>> do not enable you >>> to do anything useful regarding that so they could be removed >>> straightaway without waiting for STRAGGLER. >>> >> >> I don't know about the specifics, but in principle the straggler timer >> should help you to do measurements of more then the fastest interface. >> Whenever you send out Interests on multiple faces (either in parallel or >> sequential) it can be useful to wait a little longer for responses (Data or >> NACKs). >> > > I agree, that would be one reason to have the STRAGGLER timer. > > But as the RTT is a measure of how fast the last Interest up a certain > path was satisfied, wouldn't it make more sense to use the FIB to keep > track of the RTT ? > > I disagree with this last statement too. There is nothing in a response > that identifies which request triggered the response. If a forwarder has > sent two Interests upstream on the same path you don?t know if you are > measuring the time from the 1st interest to the response (a long time) or > the time from the 2nd interest to the response (a shorter time). Because > you have replaced the out record, I think you will only measure the shorter > time, which could be incorrect. > > Personally, I think measuring response time at the granularity of the FIB > (which I believe is what these come down to) is not a principled thing to > do. A producer may be serving multiple classes of traffic under one FIB > entry, such as very quick static content and very slow dynamically > generated content. In that example, there is really a bi-modal RTT > distribution and if you average them you will have an RTT estimate that is > wrong for both classes of traffic. If one were to measure 2nd order > statistics, perhaps one could get a 2-sigma or 3-sigma interval, but I?m > not sure that?s really useful for anything at a forwarder. > I was describing what I understand is the RTT that can be computed under the existing implementation. My original concern here is about how to do Data measurements without the need to keep the OUT-Records longer in the PIT entry. The solution to that should make it easy to implement whatever measurements to whichever granularity someone desires. I think I have a good solution to this but I need to think it through (short answer; put it entirely in the strategy and add a callback to it in the beginning of the onIncomingData pipeline). Best regards, S. +----------------------------------------------+ | Dynerowicz Seweryn | | PostDoc Researcher | | SITI, COPELABS, Building U | | Universidade Lus?fona | | Campo Grande, 388, 1749-024 Lisboa, Portugal | +----------------------------------------------+ I hate the empty set; he's so full of himself. "Judge a man by his questions rather than his answers", Pierre-Marc Gaston, Duc de L?vis "Ignorance more frequently begets confidence than does knowledge.", C. Darwin "Seek freedom and become captive of your desires. Seek discipline and find your liberty.", F. Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Nov 17 07:00:03 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 17 Nov 2016 08:00:03 -0700 Subject: [Nfd-dev] NFD call 20161117 Message-ID: <201611171500.uAHF03E5029137@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From klaus at cs.arizona.edu Thu Nov 17 11:02:25 2016 From: klaus at cs.arizona.edu (Klaus Schneider) Date: Thu, 17 Nov 2016 12:02:25 -0700 Subject: [Nfd-dev] On the necessity of the STRAGGLER timer In-Reply-To: References: Message-ID: <0c009256-c9f1-6336-a3af-3411cb15f14a@cs.arizona.edu> Some comments below. On 11/17/2016 06:57 AM, Seweryn Dynerowicz wrote: > Dear Marc, > > Thanks for this input, my replies are nested below. > > On 17 November 2016 at 11:56, > wrote: > > Two comments below >> On Nov 17, 2016, at 8:09 PM, Seweryn Dynerowicz >> > wrote: >> >> Dear Klaus, >> >> On 16 November 2016 at 21:51, Klaus Schneider >> > wrote: >> >> I think Junxiao refers to Section 4.2.8 >> Interest Finalize Pipeline: "The Dead Nonce List is a global >> data structure designed to detect looping Interests, and we >> want to insert as >> few Nonces as possible to keep its size down." >> >> >> The way I understand this specific point is that we do not want to >> insert the Nonce for every single Interest we ever receive. This >> is precisely >> what the next sentence states; >> >> "Only outgoing Nonces (in out-records) need to be inserted, >> because an incoming Nonce that has never been sent out won't loop >> back.? > > This is incorrect, or at best it?s a limited definition of loop. > You could have a first Interest with nonce A that would, if nothing > else happened, form a cycle and need to be dropped. however, at > another node, that first Interest could be aggregated with a second > Interest with nonce B, and it is that second Interest that loops. > Then B might get aggregated with the node that sent A in the first > place, and neither loop is detected because there was no duplicate > nonces, only aggregations that will eventually timeout. One could > ask, did a loop really happen in that case? I think if you are > forming an equivalency class on Interests based on aggregation > similarity, then yes a loop did happen. > > > I agree. From the perspective of the implementation, it seems that the > source of the problem you're pointing out is that the Forwarder > implements a loop detection scheme which makes assumptions on how the > Strategy behave (to make it worse it makes assumptions on how other > nodes Strategy behaves). The first case you describe occurs with a > Strategy which, for a given Name, forwards EITHER all Interests it > receives without changing their Nonce OR none. The second case > (aggregation) occurs with a Strategy which decides to only forward some > strict subset of the Interests it receives for a given Name. To > guarantee that the implemented scheme detects all loops, all the nodes > must be using the first Strategy. If any node uses the second Strategy, > this introduces the possibility of a non-detectable Interest loop. A > more strict scheme for Loop detection (i.e. keep track of traversed > nodes) seems to be necessary. A more strict loop detection scheme is to keep the PIT in-records around after the initial Interest was satisfied, as done by the straggler timer. The fundamental problem is that routers have limited memory, so you have to remove the information about previously seen Interests at some point. Any loop that takes longer than the router's ability to remember previous Interests/nonces cannot be detected that way. The "Dead Nonce List" is really only a performance optimization: Only store nonces, not the whole PIT entry + only store some nonces which seem more likely to loop (the ones in out-records). This saves some memory, but doesn't solve the fundamental problem that you would need unlimited memory for perfect loop detection. > >> So you only compute the RTT for the first Data packet >> which satisfies >> the Interest, right ? If you're only interested in RTT, >> the OUT-Records >> do not enable you >> to do anything useful regarding that so they could be removed >> straightaway without waiting for STRAGGLER. >> >> >> I don't know about the specifics, but in principle the >> straggler timer should help you to do measurements of more >> then the fastest interface. Whenever you send out Interests on >> multiple faces (either in parallel or sequential) it can be >> useful to wait a little longer for responses (Data or NACKs). >> >> >> I agree, that would be one reason to have the STRAGGLER timer. >> >> But as the RTT is a measure of how fast the last Interest up a >> certain path was satisfied, wouldn't it make more sense to use the >> FIB to keep track of the RTT ? > I disagree with this last statement too. There is nothing in a > response that identifies which request triggered the response. If a > forwarder has sent two Interests upstream on the same path you don?t > know if you are measuring the time from the 1st interest to the > response (a long time) or the time from the 2nd interest to the > response (a shorter time). Because you have replaced the out > record, I think you will only measure the shorter time, which could > be incorrect. > > Personally, I think measuring response time at the granularity of > the FIB (which I believe is what these come down to) is not a > principled thing to do. A producer may be serving multiple classes > of traffic under one FIB entry, such as very quick static content > and very slow dynamically generated content. In that example, there > is really a bi-modal RTT distribution and if you average them you > will have an RTT estimate that is wrong for both classes of > traffic. If one were to measure 2nd order statistics, perhaps one > could get a 2-sigma or 3-sigma interval, but I?m not sure that?s > really useful for anything at a forwarder. > > > I was describing what I understand is the RTT that can be computed under > the existing implementation. My original concern here is about how to do > Data measurements without the need to keep the OUT-Records longer in the > PIT entry. The solution to that should make it easy to implement > whatever measurements to whichever granularity someone desires. I think > I have a good solution to this but I need to think it through (short > answer; put it entirely in the strategy and add a callback to it in the > beginning of the onIncomingData pipeline). How is it possible to do an RTT measurement without the out-record? Let's say you send out two Interests and Face A and Face B. The Data returns on Face A and you remove the whole PIT entry. Now that second Data returns on Face B. How could you know its RTT? You just deleted the information about when you sent that Interest. Of course, you can store this information inside the strategy and then implement what you want in onUnsolicitedData(). But what's the benefit compared to just using the out-records? Best regards, Klaus > > > Best regards, > > S. > > +----------------------------------------------+ > | Dynerowicz Seweryn | > | PostDoc Researcher | > | SITI, COPELABS, Building U | > | Universidade Lus?fona | > | Campo Grande, 388, 1749-024 Lisboa, Portugal | > +----------------------------------------------+ > > I hate the empty set; he's so full of himself. > > "Judge a man by his questions rather than his answers", > Pierre-Marc Gaston, Duc de L?vis > > "Ignorance more frequently begets confidence than does knowledge.", > C. Darwin > > "Seek freedom and become captive of your desires. Seek discipline > and find your liberty.", F. Herbert > From bzhang at cs.arizona.edu Thu Nov 17 11:08:56 2016 From: bzhang at cs.arizona.edu (Beichuan Zhang) Date: Thu, 17 Nov 2016 12:08:56 -0700 Subject: [Nfd-dev] NFD call 20161117 cancelled In-Reply-To: <201611171500.uAHF03E5029137@lectura.cs.arizona.edu> References: <201611171500.uAHF03E5029137@lectura.cs.arizona.edu> Message-ID: <264A3050-3E51-49DC-A34F-7F4315588CB6@cs.arizona.edu> Due to conflict with a couple of other calls, today?s NFD call is cancelled. > On Nov 17, 2016, at 8:00 AM, NFD call notification wrote: > > Dear folks > > This is a reminder of the upcoming NFD call using Bluejeans https://bluejeans.com/424982807 . The current call time is every Tuesday 12:00-13:00 Pacific time and every Thursday 13:00-14:00 Pacific time. The current agenda includes the following issues: > > > > https://redmine.named-data.net/issues/3640 > ECDSA validation > > need: Zhiyi > > > > _______________________________________________ > 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 f80120 at ulusofona.pt Fri Nov 18 07:03:50 2016 From: f80120 at ulusofona.pt (Seweryn Dynerowicz) Date: Fri, 18 Nov 2016 15:03:50 +0000 Subject: [Nfd-dev] On the necessity of the STRAGGLER timer In-Reply-To: <0c009256-c9f1-6336-a3af-3411cb15f14a@cs.arizona.edu> References: <0c009256-c9f1-6336-a3af-3411cb15f14a@cs.arizona.edu> Message-ID: Dear Klaus, On 17 November 2016 at 19:02, Klaus Schneider wrote: > > A more strict loop detection scheme is to keep the PIT in-records around > after the initial Interest was satisfied, as done by the straggler timer. > I don't think that keeping the IN-Records will allow you to detect more loops than only keeping the OUT-Records Nonces. That scheme would not be able to detect the forwarding loops described by Marc in his first comment, namely if the Nonce of the INT a node A sent out gets aggregated under another INT at some node B upstream (or node B changes the Nonce) which THEN loops back. Node A will not be able to relate that INT to any it has previously received (IN-Record) or sent (OUT-Record). The fundamental problem is that routers have limited memory, so you have to > remove the information about previously seen Interests at some point. Any > loop that takes longer than the router's ability to remember previous > Interests/nonces cannot be detected that way. > > The "Dead Nonce List" is really only a performance optimization: Only > store nonces, not the whole PIT entry + only store some nonces which seem > more likely to loop (the ones in out-records). This saves some memory, but > doesn't solve the fundamental problem that you would need unlimited memory > for perfect loop detection. I'm not questioning the function that the Dead Nonce List fulfills. My original question was why delay the insertion of Nonces from OUT-Records to the DNL by means of the STRAGGLER timer but I guess that because the OUT-Records are kept in the PIT entry for data measurements it makes sense to wait that much before transferring only the Nonces in DNL before deleting the PIT entry. I was describing what I understand is the RTT that can be computed under >> the existing implementation. My original concern here is about how to do >> Data measurements without the need to keep the OUT-Records longer in the >> PIT entry. The solution to that should make it easy to implement >> whatever measurements to whichever granularity someone desires. I think >> I have a good solution to this but I need to think it through (short >> answer; put it entirely in the strategy and add a callback to it in the >> beginning of the onIncomingData pipeline). >> > > How is it possible to do an RTT measurement without the out-record? > Let's say you send out two Interests and Face A and Face B. The Data > returns on Face A and you remove the whole PIT entry. > Now that second Data returns on Face B. How could you know its RTT? You > just deleted the information about when you sent that Interest. > Of course, you can store this information inside the strategy and then > implement what you want in onUnsolicitedData(). But what's the benefit > compared to just using the out-records? > I'm still thinking about this... I don't see yet what measuring the RTT in NDN means. Best regards, S. +----------------------------------------------+ | Dynerowicz Seweryn | | PostDoc Researcher | | SITI, COPELABS, Building U | | Universidade Lus?fona | | Campo Grande, 388, 1749-024 Lisboa, Portugal | +----------------------------------------------+ I hate the empty set; he's so full of himself. "Judge a man by his questions rather than his answers", Pierre-Marc Gaston, Duc de L?vis "Ignorance more frequently begets confidence than does knowledge.", C. Darwin "Seek freedom and become captive of your desires. Seek discipline and find your liberty.", F. Herbert -------------- next part -------------- An HTML attachment was scrubbed... URL: From agawande at memphis.edu Fri Nov 18 13:22:32 2016 From: agawande at memphis.edu (Ashlesh Gawande (agawande)) Date: Fri, 18 Nov 2016 21:22:32 +0000 Subject: [Nfd-dev] Request for NFD release Message-ID: Hi all John uses named data PPA on the testbed. I am working on deploying Hyperbolic Routing on the testbed which needs ASF strategy to get around non-optimal paths. A critical bug fix for ASF recently merged without which ASF itself switches to non-optimal paths due to false RTT measurements. When would be the next release of NFD? Would it be possible to do a minor release so that testbed can use the fix? Ashlesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From malhowaidi at gmail.com Fri Nov 18 16:36:52 2016 From: malhowaidi at gmail.com (Mohammad Alhowaidi) Date: Fri, 18 Nov 2016 18:36:52 -0600 Subject: [Nfd-dev] reset content store In-Reply-To: References: Message-ID: Thank you for your reply, but sometime I still get the response from the intermediate router, even if I did (nfd-stop , nfd-start). isn't (nfd-stop, nfd-start) suppose to restart it and clear the content store? Thanks, Mohammad On Wed, Nov 16, 2016 at 9:15 PM, Junxiao Shi wrote: > Hi Mohammad > > Yes, restarting NFD clears all tables, including the ContentStore. > > Yours, Junxiao > > On Nov 16, 2016 5:49 PM, "Mohammad Alhowaidi" > wrote: > >> Hello, >> >> How to delete nfd content store content? Is restarting nfd will delete >> the content store content? >> >> Thanks, >> Mohammad >> >> _______________________________________________ >> 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 Nov 22 06:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 22 Nov 2016 07:00:02 -0700 Subject: [Nfd-dev] NFD call 20161122 Message-ID: <201611221400.uAME02IY014235@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Nov 24 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 24 Nov 2016 08:00:02 -0700 Subject: [Nfd-dev] NFD call 20161124 Message-ID: <201611241500.uAOF02Cp012216@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From malhowaidi at gmail.com Thu Nov 24 10:36:29 2016 From: malhowaidi at gmail.com (Mohammad Alhowaidi) Date: Thu, 24 Nov 2016 12:36:29 -0600 Subject: [Nfd-dev] Router issue interest Message-ID: Hello, Could the intermediate router issue an interest based on the interest coming from the consumer? so the router will not just forward the interest but will issue new other interest! Thanks, Mohammad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhasabet at gmail.com Thu Nov 24 10:59:19 2016 From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet) Date: Thu, 24 Nov 2016 22:29:19 +0330 Subject: [Nfd-dev] Router issue interest In-Reply-To: References: Message-ID: Hi Mohammad, Generally speaking, yes. You may decide where to put your program in pipelines. But I think first you should distinguish intermediate nodes from non-intermediate ones. Sabet On 24 Nov 2016 10:06 pm, "Mohammad Alhowaidi" wrote: > Hello, > > Could the intermediate router issue an interest based on the interest > coming from the consumer? so the router will not just forward the interest > but will issue new other interest! > > Thanks, > Mohammad > > > _______________________________________________ > 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 malhowaidi at gmail.com Thu Nov 24 11:10:12 2016 From: malhowaidi at gmail.com (Mohammad Alhowaidi) Date: Thu, 24 Nov 2016 13:10:12 -0600 Subject: [Nfd-dev] Router issue interest In-Reply-To: References: Message-ID: Thanks Sabet for the reply. Then should we modify the NFD code? since the the intermediate router should generate an interest based on the incoming interest from the consumer. For example if I have consumer --- router --- producer and the consumer send the interest /ndn/A , so when this interest reach the router, then the router will forward it to the producer and also will send another interest /ndn/AB. Thanks, Mohammad On Thu, Nov 24, 2016 at 12:59 PM, Muhammad Hosain Abdollahi Sabet < mhasabet at gmail.com> wrote: > Hi Mohammad, > > Generally speaking, yes. You may decide where to put your program in > pipelines. But I think first you should distinguish intermediate nodes from > non-intermediate ones. > > Sabet > > On 24 Nov 2016 10:06 pm, "Mohammad Alhowaidi" > wrote: > >> Hello, >> >> Could the intermediate router issue an interest based on the interest >> coming from the consumer? so the router will not just forward the interest >> but will issue new other interest! >> >> Thanks, >> Mohammad >> >> >> _______________________________________________ >> 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 lixia at CS.UCLA.EDU Thu Nov 24 11:10:43 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Thu, 24 Nov 2016 11:10:43 -0800 Subject: [Nfd-dev] Code formatter/beautifier In-Reply-To: References: <87247931-65d8-232c-4e0b-d7381c7e6f19@memphis.edu> <581b7837.06a76b0a.1132d.d10f@mx.google.com> Message-ID: > On Nov 3, 2016, at 11:10 AM, Muhammad Hosain Abdollahi Sabet wrote: > > Alex, > > You mean to change style of ndn codebase? Maybe starts with ndnSIM new release? > yeah how about this suggestion, i.e. starting with next ndnSIM release to try out first? > On Nov 3, 2016 9:37 PM, "Alex Afanasyev" > wrote: > The standard version of clang-format (at least as of year ago) allows only limited customization. Our current style not really expressable with clang-format rules (I did some patching that got closer, but still not the same: https://github.com/named-data-ndnSIM/ndnSIM/blob/master/.clang-format ). > > Potentially a good way of solving this problem is to select a more standard style (e.g., Google), which will make all the automation work. > > -- > Alex > > > On Nov 3, 2016, at 11:47 AM, Junxiao Shi > wrote: > > > > Hi Nick > > > > I heard there are someone using clang-format, but I haven't heard anyone being able to create a clang-format configuration that ensures 100% compliance. > > Thus, I still recommend developers to memorize all style rules and ensure compliance the moment you type it. > > > > I heard from a Google engineer that they use Eclipse to ensure Google code style compliance. I'm unsure whether it's possible with ndn-cxx rules. > > > > ndnSIM has defined their rules in terms of a particular clang-format configuration, which could be a solution. However, relying on a tool as the rules is similar to defining a network protocol in terms of a specific implementation, which could cause inter-operability problems. > > > > Yours, Junxiao > > From: Nick Gordon > > Sent: ?11/?3/?2016 11:36 > > To: Junxiao Shi > > Subject: Code formatter/beautifier > > > > Junxiao, > > > > In an attempt to smooth out style issues, I intend to use a formatter. > > It appears that there is a well-known program, "clang-format", that does > > this. Do you have any system that you use to format your code that I > > should know about? > > > > -Nick > > > > _______________________________________________ > > 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 > _______________________________________________ > 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 mhasabet at gmail.com Thu Nov 24 11:18:11 2016 From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet) Date: Thu, 24 Nov 2016 22:48:11 +0330 Subject: [Nfd-dev] Router issue interest In-Reply-To: References: Message-ID: Well, I guess it depends on what you want to do, then consider design trade-offs. Yes, you may modify nfd code or you may put you program over nfd, something like nlsr maybe. Apart from that, I suggest you to implement a simulated version so that you can firstly define semantics of what you are looking for. Sabet On 24 Nov 2016 10:40 pm, "Mohammad Alhowaidi" wrote: > Thanks Sabet for the reply. Then should we modify the NFD code? since the > the intermediate router should generate an interest based on the incoming > interest from the consumer. > > For example if I have > > consumer --- router --- producer > > and the consumer send the interest /ndn/A , so when this interest reach > the router, then the router will forward it to the producer and also will > send another interest /ndn/AB. > > Thanks, > Mohammad > > > On Thu, Nov 24, 2016 at 12:59 PM, Muhammad Hosain Abdollahi Sabet < > mhasabet at gmail.com> wrote: > >> Hi Mohammad, >> >> Generally speaking, yes. You may decide where to put your program in >> pipelines. But I think first you should distinguish intermediate nodes from >> non-intermediate ones. >> >> Sabet >> >> On 24 Nov 2016 10:06 pm, "Mohammad Alhowaidi" >> wrote: >> >>> Hello, >>> >>> Could the intermediate router issue an interest based on the interest >>> coming from the consumer? so the router will not just forward the interest >>> but will issue new other interest! >>> >>> Thanks, >>> Mohammad >>> >>> >>> _______________________________________________ >>> 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 Marc.Mosko at parc.com Thu Nov 24 11:37:16 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Thu, 24 Nov 2016 19:37:16 +0000 Subject: [Nfd-dev] Router issue interest In-Reply-To: References: Message-ID: This sort of behavior is usually called ?prefetching? or ?warming the cache?, where an intermediate system fetches ahead of time objects it expects will be useful in the future based on interests it currently sees. There?s been several papers on the topic. If you google scholar search for ?ndn ccn +prefetch? you should find them. In general, ndn does not guarantee consistent path selection (like tcp usually gets). Interests can be spread over a variety of next hops. So, prefetching will only be as useful as one can do it as key junction points or use a system that cooperates with Interest path selection. Another key problem to address is congestion control and how intermediate nodes generating new traffic interacts with the CC algorithm. Marc On Nov 24, 2016, at 11:10 AM, Mohammad Alhowaidi > wrote: Thanks Sabet for the reply. Then should we modify the NFD code? since the the intermediate router should generate an interest based on the incoming interest from the consumer. For example if I have consumer --- router --- producer and the consumer send the interest /ndn/A , so when this interest reach the router, then the router will forward it to the producer and also will send another interest /ndn/AB. Thanks, Mohammad On Thu, Nov 24, 2016 at 12:59 PM, Muhammad Hosain Abdollahi Sabet > wrote: Hi Mohammad, Generally speaking, yes. You may decide where to put your program in pipelines. But I think first you should distinguish intermediate nodes from non-intermediate ones. Sabet On 24 Nov 2016 10:06 pm, "Mohammad Alhowaidi" > wrote: Hello, Could the intermediate router issue an interest based on the interest coming from the consumer? so the router will not just forward the interest but will issue new other interest! Thanks, Mohammad _______________________________________________ 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 malhowaidi at gmail.com Thu Nov 24 16:51:26 2016 From: malhowaidi at gmail.com (Mohammad Alhowaidi) Date: Thu, 24 Nov 2016 18:51:26 -0600 Subject: [Nfd-dev] Router issue interest In-Reply-To: References: Message-ID: Thank you for the details, I am trying to implement one of the prefetching method in the literature to NDN. I was wondering how to make the router initiate such request, through the NFD or using separate program. Thanks, Mohammad On Nov 24, 2016 1:36 PM, wrote: > This sort of behavior is usually called ?prefetching? or ?warming the > cache?, where an intermediate system fetches ahead of time objects it > expects will be useful in the future based on interests it currently sees. > There?s been several papers on the topic. If you google scholar search for > ?ndn ccn +prefetch? you should find them. > > In general, ndn does not guarantee consistent path selection (like tcp > usually gets). Interests can be spread over a variety of next hops. So, > prefetching will only be as useful as one can do it as key junction points > or use a system that cooperates with Interest path selection. Another key > problem to address is congestion control and how intermediate nodes > generating new traffic interacts with the CC algorithm. > > Marc > > On Nov 24, 2016, at 11:10 AM, Mohammad Alhowaidi > wrote: > > Thanks Sabet for the reply. Then should we modify the NFD code? since the > the intermediate router should generate an interest based on the incoming > interest from the consumer. > > For example if I have > > consumer --- router --- producer > > and the consumer send the interest /ndn/A , so when this interest reach > the router, then the router will forward it to the producer and also will > send another interest /ndn/AB. > > Thanks, > Mohammad > > > On Thu, Nov 24, 2016 at 12:59 PM, Muhammad Hosain Abdollahi Sabet < > mhasabet at gmail.com> wrote: > >> Hi Mohammad, >> >> Generally speaking, yes. You may decide where to put your program in >> pipelines. But I think first you should distinguish intermediate nodes from >> non-intermediate ones. >> >> Sabet >> >> On 24 Nov 2016 10:06 pm, "Mohammad Alhowaidi" >> wrote: >> >>> Hello, >>> >>> Could the intermediate router issue an interest based on the interest >>> coming from the consumer? so the router will not just forward the interest >>> but will issue new other interest! >>> >>> Thanks, >>> Mohammad >>> >>> >>> _______________________________________________ >>> 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 philipp.moll at itec.aau.at Sun Nov 27 23:35:21 2016 From: philipp.moll at itec.aau.at (Philipp Moll) Date: Mon, 28 Nov 2016 08:35:21 +0100 Subject: [Nfd-dev] Redundant data transmissions on error-prone links Message-ID: <0ddae188-8ace-f84d-e87d-e6226a1c1131@itec.aau.at> Dear NDN Developers, I?m currently thinking of methods for redundant data transmission for real-time applications. In the case of (some) real-time applications a retransmission of lost packets is not reasonable. Therefore I would like to investigate redundant data transmission over multiple links. I think this could be useful especially in wireless access networks with higher loss rates. My idea is, to duplicate Interests and send them out over multiple faces (similar to Multicast). This duplication means, that the same Interest will also arrive over multiple faces on some hosts. In order to achieve a redundant data transmission, it is necessary that the Interest is registered in the PIT from all in-faces. I recognized, that the design of the Interest processing pipeline only allows that one Interest arrives from one face. If it arrives from two or more faces, only the first is processed, the others are classified as looping Interests, what is disadvantageous for my intent. I was thinking and testing a lot in order to understand this pipeline design, but I can?t see, why Interests with the same nonce are classified as looping if they arrive over different faces. In my opinion, a loop can only occur if two Interests with the same nonce arrive over the same face. This behavior also brings disadvantages in other cases. Imagine two nodes are connected over two links, a low latency low-bandwidth link, and a high latency high-bandwidth link. If a forwarding strategy like Multicast is used, only the low bandwidth link would be used because the Interest is faster at the receiver at this link. The Interest which traveled over the high bandwidth link is classified as looping, which means that the high-bandwidth link is not used, even if there are congestions on the low-bandwidth link. I would like to ask, if anyone can explain the reason for this pipeline design or could give me advices for implementing redundant data transmissions. Best regards, Philipp Moll -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at remap.ucla.edu Mon Nov 28 09:23:34 2016 From: peter at remap.ucla.edu (Gusev, Peter) Date: Mon, 28 Nov 2016 17:23:34 +0000 Subject: [Nfd-dev] Redundant data transmissions on error-prone links In-Reply-To: <0ddae188-8ace-f84d-e87d-e6226a1c1131@itec.aau.at> References: <0ddae188-8ace-f84d-e87d-e6226a1c1131@itec.aau.at> Message-ID: Hi Philipp, On related note - I used forward error correction in NDN-RTC and published redundant data under ?_parity? namespace for every video frame. This is not related to the problem with Interests you described, but relates to lossy links and retransmission/redundant data trade off. 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 Nov 27, 2016, at 11:35 PM, Philipp Moll > wrote: Dear NDN Developers, I?m currently thinking of methods for redundant data transmission for real-time applications. In the case of (some) real-time applications a retransmission of lost packets is not reasonable. Therefore I would like to investigate redundant data transmission over multiple links. I think this could be useful especially in wireless access networks with higher loss rates. My idea is, to duplicate Interests and send them out over multiple faces (similar to Multicast). This duplication means, that the same Interest will also arrive over multiple faces on some hosts. In order to achieve a redundant data transmission, it is necessary that the Interest is registered in the PIT from all in-faces. I recognized, that the design of the Interest processing pipeline only allows that one Interest arrives from one face. If it arrives from two or more faces, only the first is processed, the others are classified as looping Interests, what is disadvantageous for my intent. I was thinking and testing a lot in order to understand this pipeline design, but I can?t see, why Interests with the same nonce are classified as looping if they arrive over different faces. In my opinion, a loop can only occur if two Interests with the same nonce arrive over the same face. This behavior also brings disadvantages in other cases. Imagine two nodes are connected over two links, a low latency low-bandwidth link, and a high latency high-bandwidth link. If a forwarding strategy like Multicast is used, only the low bandwidth link would be used because the Interest is faster at the receiver at this link. The Interest which traveled over the high bandwidth link is classified as looping, which means that the high-bandwidth link is not used, even if there are congestions on the low-bandwidth link. I would like to ask, if anyone can explain the reason for this pipeline design or could give me advices for implementing redundant data transmissions. Best regards, Philipp Moll _______________________________________________ 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 hila at wustl.edu Mon Nov 28 10:55:04 2016 From: hila at wustl.edu (Hila Ben Abraham) Date: Mon, 28 Nov 2016 18:55:04 +0000 Subject: [Nfd-dev] Fwd: Redundant data transmissions on error-prone links In-Reply-To: References: <0ddae188-8ace-f84d-e87d-e6226a1c1131@itec.aau.at> Message-ID: Hi Philipp, In the following topology a loop can be created when both A and D forward an Interest with the same nonce to B. In this topology the Interest can be received on two different faces. A-->B-->C-->D ^ | ----------- Saying that, I agree that there might be cases in which processing 'looped' Interests can be helpful. The challenge in those cases is to identify those packets and prevent forever forwarded Interests. We started exploring differentiating strategy transmissions fron app transmissions as a possible solution to the problem, but it is still work in progress. You can find some more information in this report (section 5.2). Hila On Mon, Nov 28, 2016 at 11:24 AM Gusev, Peter wrote: Hi Philipp, On related note - I used forward error correction in NDN-RTC and published redundant data under ?_parity? namespace for every video frame. This is not related to the problem with Interests you described, but relates to lossy links and retransmission/redundant data trade off. Thanks, -- Peter Gusev peter at remap.ucla.edu +1 213 5872748 <+1%20213-587-2748> peetonn_ (skype) Software Engineer/Programmer Analyst @ REMAP UCLA Video streaming/ICN networks/Creative Development On Nov 27, 2016, at 11:35 PM, Philipp Moll wrote: Dear NDN Developers, I?m currently thinking of methods for redundant data transmission for real-time applications. In the case of (some) real-time applications a retransmission of lost packets is not reasonable. Therefore I would like to investigate redundant data transmission over multiple links. I think this could be useful especially in wireless access networks with higher loss rates. My idea is, to duplicate Interests and send them out over multiple faces (similar to Multicast). This duplication means, that the same Interest will also arrive over multiple faces on some hosts. In order to achieve a redundant data transmission, it is necessary that the Interest is registered in the PIT from all in-faces. I recognized, that the design of the Interest processing pipeline only allows that one Interest arrives from one face. If it arrives from two or more faces, only the first is processed, the others are classified as looping Interests, what is disadvantageous for my intent. I was thinking and testing a lot in order to understand this pipeline design, but I can?t see, why Interests with the same nonce are classified as looping if they arrive over different faces. In my opinion, a loop can only occur if two Interests with the same nonce arrive over the same face. This behavior also brings disadvantages in other cases. Imagine two nodes are connected over two links, a low latency low-bandwidth link, and a high latency high-bandwidth link. If a forwarding strategy like Multicast is used, only the low bandwidth link would be used because the Interest is faster at the receiver at this link. The Interest which traveled over the high bandwidth link is classified as looping, which means that the high-bandwidth link is not used, even if there are congestions on the low-bandwidth link. I would like to ask, if anyone can explain the reason for this pipeline design or could give me advices for implementing redundant data transmissions. Best regards, Philipp Moll _______________________________________________ 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 klaus at cs.arizona.edu Mon Nov 28 17:11:20 2016 From: klaus at cs.arizona.edu (Klaus Schneider) Date: Mon, 28 Nov 2016 18:11:20 -0700 Subject: [Nfd-dev] Fwd: Redundant data transmissions on error-prone links In-Reply-To: References: <0ddae188-8ace-f84d-e87d-e6226a1c1131@itec.aau.at> Message-ID: Hi Philipp, I agree with everything Hila said below. A loop is loosely defined as an Interest that comes back to the router that sent it, whether it's on the same interface or not. However, there's a solution for your problem: > My idea is, to duplicate Interests and send them out over multiple faces (similar to Multicast). This duplication means, that the same Interest will also arrive over multiple faces on some hosts. In order to achieve a redundant data transmission, it is necessary that the Interest is registered in the PIT from all in-faces. > So it sound like you not only want to duplicate the Interest, but also the Data that comes back? The default behavior is to have duplicated Interests, but only send back the fastest arriving Data packet. Sometimes this is exactly what people want. > I recognized, that the design of the Interest processing pipeline only allows that one Interest arrives from one face. If it arrives from two or more faces, only the first is processed, the others are classified as looping Interests, what is disadvantageous for my intent. > > I was thinking and testing a lot in order to understand this pipeline design, but I can?t see, why Interests with the same nonce are classified as looping if they arrive over different faces. In my opinion, a loop can only occur if two Interests with the same nonce arrive over the same face. > > This behavior also brings disadvantages in other cases. Imagine two nodes are connected over two links, a low latency low-bandwidth link, and a high latency high-bandwidth link. If a forwarding strategy like Multicast is used, only the low bandwidth link would be used because the Interest is faster at the receiver at this link. The Interest which traveled over the high bandwidth link is classified as looping, which means that the high-bandwidth link is not used, even if there are congestions on the low-bandwidth link. That's true when sending Interests on both parts redundantly. I think the reason why people haven't complained about this earlier is that most of the time, the forwarding strategy doesn't send Interests in parallel, but either tries a "best" face first with the second as backup, or splits up Interests to balance the load like in Multipath TCP. > I would like to ask, if anyone can explain the reason for this pipeline design or could give me advices for implementing redundant data transmissions. The easy solution is: At the forwarding strategy which duplicates the Interests, give them a new nonce! This presumably happens only once in the network and somewhere at the edge (wireless access networks), so looping is not a problem. You can do that by the "newNonce" option in the sendInterest() function: > this->sendInterest(pitEntry, outFace, true); Here's very simple implementation: - https://github.com/schneiderklaus/ndnSIM/blob/master/NFD/daemon/fw/broadcast-newnonce-strategy.hpp - https://github.com/schneiderklaus/ndnSIM/blob/master/NFD/daemon/fw/broadcast-newnonce-strategy.cpp We have developed a more sophisticated strategy that uses this sort of redundant forwarding, called the "Selective Parallel Strategy". It sends interests out on multiple faces, but only when the expected payoff to the application exceeds the cost of doing so: http://conferences2.sigcomm.org/acm-icn/2015/proceedings/p137-schneider.pdf Best regards, Klaus On 11/28/2016 11:55 AM, Hila Ben Abraham wrote: > > Hi Philipp, > > In the following topology a loop can be created when both A and D > forward an Interest with the same nonce to B. In this topology the > Interest can be received on two different faces. > A-->B-->C-->D > ^ | > ----------- > > Saying that, I agree that there might be cases in which processing > 'looped' Interests can be helpful. The challenge in those cases is to > identify those packets and prevent forever forwarded Interests. We > started exploring differentiating strategy transmissions fron app > transmissions as a possible solution to the problem, but it is still > work in progress. You can find some more information in this report > (section 5.2). > > Hila > > On Mon, Nov 28, 2016 at 11:24 AM Gusev, Peter > wrote: > > Hi Philipp, > > On related note - I used forward error correction in NDN-RTC and > published redundant data under ?_parity? namespace for every video > frame. This is not related to the problem with Interests you > described, but relates to lossy links and retransmission/redundant > data trade off. > > 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 Nov 27, 2016, at 11:35 PM, Philipp Moll >> > wrote: >> >> >> >> Dear NDN Developers, >> >> I?m currently thinking of methods for redundant data transmission >> for real-time applications. In the case of (some) real-time >> applications a retransmission of lost packets is not reasonable. >> Therefore I would like to investigate redundant data transmission >> over multiple links. I think this could be useful especially in >> wireless access networks with higher loss rates. >> >> My idea is, to duplicate Interests and send them out over multiple >> faces (similar to Multicast). This duplication means, that the >> same Interest will also arrive over multiple faces on some hosts. >> In order to achieve a redundant data transmission, it is necessary >> that the Interest is registered in the PIT from all in-faces. >> >> I recognized, that the design of the Interest processing pipeline >> only allows that one Interest arrives from one face. If it arrives >> from two or more faces, only the first is processed, the others >> are classified as looping Interests, what is disadvantageous for >> my intent. >> >> I was thinking and testing a lot in order to understand this >> pipeline design, but I can?t see, why Interests with the same >> nonce are classified as looping if they arrive over different >> faces. In my opinion, a loop can only occur if two Interests with >> the same nonce arrive over the same face. >> >> This behavior also brings disadvantages in other cases. Imagine >> two nodes are connected over two links, a low latency >> low-bandwidth link, and a high latency high-bandwidth link. If a >> forwarding strategy like Multicast is used, only the low bandwidth >> link would be used because the Interest is faster at the receiver >> at this link. The Interest which traveled over the high bandwidth >> link is classified as looping, which means that the high-bandwidth >> link is not used, even if there are congestions on the >> low-bandwidth link. >> >> I would like to ask, if anyone can explain the reason for this >> pipeline design or could give me advices for implementing >> redundant data transmissions. >> >> Best regards, >> >> Philipp Moll >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From malhowaidi at gmail.com Mon Nov 28 18:34:11 2016 From: malhowaidi at gmail.com (Mohammad Alhowaidi) Date: Mon, 28 Nov 2016 20:34:11 -0600 Subject: [Nfd-dev] NFD choosing one route only Message-ID: Hello, I setup the nfd to forward the traffic through the following route: nfdc register /ndn udp://10.71.102.53 nfdc register /ndn udp://10.71.103.63 The first one has a higher latency but it keep forward through the first one, shouldn't it choose the best route ( the second one since it has lower latency )? Thanks, Mohammad -------------- next part -------------- An HTML attachment was scrubbed... URL: From hila at wustl.edu Mon Nov 28 19:16:38 2016 From: hila at wustl.edu (Hila Ben Abraham) Date: Tue, 29 Nov 2016 03:16:38 +0000 Subject: [Nfd-dev] NFD choosing one route only In-Reply-To: References: Message-ID: Hi Mohammad, The forwarding strategy is the one making the next hop selection. Under the assumption that you are using the default best-route strategy, the next hop would be determined by the face cost and not by the link latency. According to my understanding, If both links have the same cost then the strategy would choose the first face listed in the FIB. You can use: nfdc register -c /ndn udp://10.71.102.53 nfdc register -c /ndn udp://10.71.103.63 with cost1>cost2 to achieve your expected behavior when using best-route. Hila On Mon, Nov 28, 2016 at 8:34 PM Mohammad Alhowaidi wrote: > Hello, > > I setup the nfd to forward the traffic through the following route: > > nfdc register /ndn udp://10.71.102.53 > nfdc register /ndn udp://10.71.103.63 > > The first one has a higher latency but it keep forward through the first > one, shouldn't it choose the best route ( the second one since it has lower > latency )? > > Thanks, > Mohammad > > _______________________________________________ > 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 Nov 29 06:00:03 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 29 Nov 2016 07:00:03 -0700 Subject: [Nfd-dev] NFD call 20161129 Message-ID: <201611291400.uATE039k028144@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From malhowaidi at gmail.com Tue Nov 29 08:43:15 2016 From: malhowaidi at gmail.com (Mohammad Alhowaidi) Date: Tue, 29 Nov 2016 10:43:15 -0600 Subject: [Nfd-dev] NFD choosing one route only In-Reply-To: References: Message-ID: Thank you for the reply, so we NFD can't do that in a dynamic way. What if the route status change after a while, then NFD will not change the route to select the best-route, right? Thanks, Mohammad On Mon, Nov 28, 2016 at 9:16 PM, Hila Ben Abraham wrote: > Hi Mohammad, > > The forwarding strategy is the one making the next hop selection. Under > the assumption that you are using the default best-route strategy, the next > hop would be determined by the face cost and not by the link latency. > According to my understanding, If both links have the same cost then the > strategy would choose the first face listed in the FIB. > > You can use: > nfdc register -c /ndn udp://10.71.102.53 > nfdc register -c /ndn udp://10.71.103.63 > > with cost1>cost2 to achieve your expected behavior when using best-route. > > Hila > > > On Mon, Nov 28, 2016 at 8:34 PM Mohammad Alhowaidi > wrote: > >> Hello, >> >> I setup the nfd to forward the traffic through the following route: >> >> nfdc register /ndn udp://10.71.102.53 >> nfdc register /ndn udp://10.71.103.63 >> >> The first one has a higher latency but it keep forward through the first >> one, shouldn't it choose the best route ( the second one since it has lower >> latency )? >> >> Thanks, >> Mohammad >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Tue Nov 29 11:32:29 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Tue, 29 Nov 2016 19:32:29 +0000 Subject: [Nfd-dev] NFD choosing one route only In-Reply-To: References: Message-ID: <0E349092-88EC-43D2-86A1-17B8FDAB3975@memphis.edu> It depends on the forwarding strategy. Some strategies (e.g. best route) simply follow the cost assigned by the routing protocol or the operator. Others (e.g., the new ASF strategy) will probe the available routes in the FIB and pick the best one based on RTT. However, if the link to the next hop fails), nfd will remove the entry. So that one won?t be used any strategy. Lan On Nov 29, 2016, at 10:43 AM, Mohammad Alhowaidi > wrote: Thank you for the reply, so we NFD can't do that in a dynamic way. What if the route status change after a while, then NFD will not change the route to select the best-route, right? Thanks, Mohammad On Mon, Nov 28, 2016 at 9:16 PM, Hila Ben Abraham > wrote: Hi Mohammad, The forwarding strategy is the one making the next hop selection. Under the assumption that you are using the default best-route strategy, the next hop would be determined by the face cost and not by the link latency. According to my understanding, If both links have the same cost then the strategy would choose the first face listed in the FIB. You can use: nfdc register -c /ndn udp://10.71.102.53 nfdc register -c /ndn udp://10.71.103.63 with cost1>cost2 to achieve your expected behavior when using best-route. Hila On Mon, Nov 28, 2016 at 8:34 PM Mohammad Alhowaidi > wrote: Hello, I setup the nfd to forward the traffic through the following route: nfdc register /ndn udp://10.71.102.53 nfdc register /ndn udp://10.71.103.63 The first one has a higher latency but it keep forward through the first one, shouldn't it choose the best route ( the second one since it has lower latency )? Thanks, Mohammad _______________________________________________ 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: