From mrchwdhr at memphis.edu Mon Aug 1 14:37:00 2016 From: mrchwdhr at memphis.edu (Muktadir R Chowdhury (mrchwdhr)) Date: Mon, 1 Aug 2016 21:37:00 +0000 Subject: [Ndn-interest] NLSR 0.3.0 release In-Reply-To: References: Message-ID: Dear all, We are pleased to announce the release of version 0.3.0 of Named-data Link State Routing Protocol (NLSR). Detailed release notes can be found at: http://named-data.net/doc/NLSR/0.3.0/RELEASE-NOTES.html More information about NLSR, tutorials, installation and configuration guides, and other useful resources are available on the official webpage of NLSR: http://named-data.net/doc/NLSR/0.3.0/ * * * NLSR Developers and Contributors: Vince Lehman, A K M Mahmudul Hoque, Adam Alyyan, Syed Obaid Amin, Muktadir Chowdhury, Ashlesh Gawande, Minsheng Zhang, Nicholas Gordon, Lan Wang, Alexander Afanasyev, Spyridon Mastorakis, Jiewen Tan, Yingdi Yu, Lixia Zhang, Junxiao Shi, Beichuan Zhang Regards, Muktadir Chowdhury -------------- next part -------------- An HTML attachment was scrubbed... URL: From marxer at claudio.li Wed Aug 3 01:15:51 2016 From: marxer at claudio.li (marxer at claudio.li) Date: Wed, 03 Aug 2016 10:15:51 +0200 Subject: [Ndn-interest] Loop Detection Issue Message-ID: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> Hi all, Urs and I constructed a situation in which we think the network does not behave as expected (attached PDF). Can this happen in the wild or did we oversee something? Thanks, Urs and Claudio -------------- next part -------------- A non-text attachment was scrubbed... Name: interest-looping.pdf Type: application/force-download Size: 116257 bytes Desc: not available URL: From lixia at CS.UCLA.EDU Wed Aug 3 02:54:28 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Wed, 3 Aug 2016 02:54:28 -0700 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> Message-ID: <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> I have a few other questions to the specifics of the scenario. for a short answer quick: interests form C1 and C2 carry different nonces, so your concern on the last slide should not happen as I see. > On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: > > Hi all, > > Urs and I constructed a situation in which we think the network does not behave as expected (attached PDF). Can this happen in the wild or did we oversee something? > > Thanks, > Urs and Claudio > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From lanwang at memphis.edu Wed Aug 3 05:28:33 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 3 Aug 2016 12:28:33 +0000 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> Message-ID: They have different nonces but if the PIT entry created by C1 has not been removed, then C2 may be suppressed. This is the dangling PIT entries problem. The solutions (already implemented in NFD) are the following: 1. some strategies, e.g., recent versions of BestRoute) allow interest retransmission: when an interest is forwarded, a suppression timer is set on the PIT. When the timer expires, it may forward any new Interest matching the PIT (and then set the suppression timer again). 2. when X detects an Interest with a duplicate nonce, it sends a duplicate NACK which may be further forwarded to clear the dangling PIT entries at the nodes that sent the interest. When the PIT entry is cleared, new interest with the same name can be forwarded. Right now some strategies (not all) in NFD handle the NACKs correctly. Lan > On Aug 3, 2016, at 4:54 AM, Lixia Zhang wrote: > > I have a few other questions to the specifics of the scenario. > for a short answer quick: interests form C1 and C2 carry different nonces, so your concern on the last slide should not happen as I see. > >> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: >> >> Hi all, >> >> Urs and I constructed a situation in which we think the network does not behave as expected (attached PDF). Can this happen in the wild or did we oversee something? >> >> Thanks, >> Urs and Claudio >> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From lixia at CS.UCLA.EDU Wed Aug 3 05:35:19 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Wed, 3 Aug 2016 05:35:19 -0700 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> Message-ID: <3FDF3C95-5DA0-4107-90F3-1D0832DDFA8C@cs.ucla.edu> > On Aug 3, 2016, at 5:28 AM, Lan Wang (lanwang) wrote: > > They have different nonces but if the PIT entry created by C1 has not been removed, then C2 may be suppressed. just to clarify: the original scenario described in the slide deck says that the data has been returned to C1 before C2's interest, that's what my early reply was based on. Otherwise: yes procedure (2) below as Lan described should be followed by design. > This is the dangling PIT entries problem. The solutions (already implemented in NFD) are the following: > > 1. some strategies, e.g., recent versions of BestRoute) allow interest retransmission: when an interest is forwarded, a suppression timer is set on the PIT. When the timer expires, it may forward any new Interest matching the PIT (and then set the suppression timer again). > > 2. when X detects an Interest with a duplicate nonce, it sends a duplicate NACK which may be further forwarded to clear the dangling PIT entries at the nodes that sent the interest. When the PIT entry is cleared, new interest with the same name can be forwarded. Right now some strategies (not all) in NFD handle the NACKs correctly. > > Lan > >> On Aug 3, 2016, at 4:54 AM, Lixia Zhang wrote: >> >> I have a few other questions to the specifics of the scenario. >> for a short answer quick: interests form C1 and C2 carry different nonces, so your concern on the last slide should not happen as I see. >> >>> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: >>> >>> Hi all, >>> >>> Urs and I constructed a situation in which we think the network does not behave as expected (attached PDF). Can this happen in the wild or did we oversee something? >>> >>> Thanks, >>> Urs and Claudio >>> >>> _______________________________________________ >>> Ndn-interest mailing list >>> Ndn-interest at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> >> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From lanwang at memphis.edu Wed Aug 3 05:44:25 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 3 Aug 2016 12:44:25 +0000 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: <3FDF3C95-5DA0-4107-90F3-1D0832DDFA8C@cs.ucla.edu> References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> <3FDF3C95-5DA0-4107-90F3-1D0832DDFA8C@cs.ucla.edu> Message-ID: > On Aug 3, 2016, at 7:35 AM, Lixia Zhang wrote: > > >> On Aug 3, 2016, at 5:28 AM, Lan Wang (lanwang) wrote: >> >> They have different nonces but if the PIT entry created by C1 has not been removed, then C2 may be suppressed. > > just to clarify: the original scenario described in the slide deck says that the data has been returned to C1 before C2's interest, that's what my early reply was based on. Maybe I?m missing something. But the data from S only clears the PIT entry at X and C1. It?s not forwarded to Z so the PIT entry at Z is not affected by the data (because X has dropped the interest from Z due to the duplicate nonce and doesn?t remember the incoming face from Z in its PIT). As long as Z has the PIT entry, it will block C2 without the two solutions in my original email). Lan > > Otherwise: yes procedure (2) below as Lan described should be followed by design. > >> This is the dangling PIT entries problem. The solutions (already implemented in NFD) are the following: >> >> 1. some strategies, e.g., recent versions of BestRoute) allow interest retransmission: when an interest is forwarded, a suppression timer is set on the PIT. When the timer expires, it may forward any new Interest matching the PIT (and then set the suppression timer again). >> >> 2. when X detects an Interest with a duplicate nonce, it sends a duplicate NACK which may be further forwarded to clear the dangling PIT entries at the nodes that sent the interest. When the PIT entry is cleared, new interest with the same name can be forwarded. Right now some strategies (not all) in NFD handle the NACKs correctly. >> >> Lan >> >>> On Aug 3, 2016, at 4:54 AM, Lixia Zhang wrote: >>> >>> I have a few other questions to the specifics of the scenario. >>> for a short answer quick: interests form C1 and C2 carry different nonces, so your concern on the last slide should not happen as I see. >>> >>>> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: >>>> >>>> Hi all, >>>> >>>> Urs and I constructed a situation in which we think the network does not behave as expected (attached PDF). Can this happen in the wild or did we oversee something? >>>> >>>> Thanks, >>>> Urs and Claudio >>>> >>>> _______________________________________________ >>>> Ndn-interest mailing list >>>> Ndn-interest at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>> >>> >>> _______________________________________________ >>> Ndn-interest mailing list >>> Ndn-interest at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> > From marxer at claudio.li Wed Aug 3 06:43:38 2016 From: marxer at claudio.li (marxer at claudio.li) Date: Wed, 03 Aug 2016 15:43:38 +0200 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> Message-ID: On 08/03/16 14:28, Lan Wang (lanwang) wrote: > They have different nonces but if the PIT entry created by C1 has not > been removed, then C2 may be suppressed. This is the dangling PIT > entries problem.The solutions (already implemented in NFD) are the > following: Yes, this is what we meant in the example. > > 1. some strategies, e.g., recent versions of BestRoute) allow interest > retransmission: when an interest is forwarded, a suppression timer is > set on the PIT. When the timer expires, it may forward any new > Interest matching the PIT (and then set the suppression timer again). > > 2. when X detects an Interest with a duplicate nonce, it sends a > duplicate NACK which may be further forwarded to clear the dangling > PIT entries at the nodes that sent the interest. When the PIT entry is > cleared, new interest with the same name can be forwarded. Right now > some strategies (not all) in NFD handle the NACKs correctly. Yes, this works. A question regarding the implementation: According to the NFD developer guide, the PIT does not hold nonce values. Thus Z can not fully reconstruct the interest from C2. Does Z generate a new nonce? If yes: Not sure but intuitively I think that loop partially detection might be broken if the green interest was also part of a loop (because Z changes its nonce). > > Lan Thanks to all of you for the explanations, Claudio > >> On Aug 3, 2016, at 4:54 AM, Lixia Zhang wrote: >> >> I have a few other questions to the specifics of the scenario. >> for a short answer quick: interests form C1 and C2 carry different >> nonces, so your concern on the last slide should not happen as I see. >> >>> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: >>> >>> Hi all, >>> >>> Urs and I constructed a situation in which we think the network does >>> not behave as expected (attached PDF). Can this happen in the wild or >>> did we oversee something? >>> >>> Thanks, >>> Urs and Claudio >>> >>> _______________________________________________ >>> Ndn-interest mailing list >>> Ndn-interest at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> >> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From marxer at claudio.li Wed Aug 3 06:50:24 2016 From: marxer at claudio.li (marxer at claudio.li) Date: Wed, 03 Aug 2016 15:50:24 +0200 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> Message-ID: <8bfb61ab-53b1-1e26-193d-c5aadc955c6c@claudio.li> Sorry, last sencence should mean: "I think that loop detection might be partially broken..." On 08/03/16 15:43, marxer at claudio.li wrote: > > On 08/03/16 14:28, Lan Wang (lanwang) wrote: >> They have different nonces but if the PIT entry created by C1 has not >> been removed, then C2 may be suppressed. This is the dangling PIT >> entries problem.The solutions (already implemented in NFD) are the >> following: > > Yes, this is what we meant in the example. > >> >> 1. some strategies, e.g., recent versions of BestRoute) allow interest >> retransmission: when an interest is forwarded, a suppression timer is >> set on the PIT. When the timer expires, it may forward any new >> Interest matching the PIT (and then set the suppression timer again). >> >> 2. when X detects an Interest with a duplicate nonce, it sends a >> duplicate NACK which may be further forwarded to clear the dangling >> PIT entries at the nodes that sent the interest. When the PIT entry >> is cleared, new interest with the same name can be forwarded. Right >> now some strategies (not all) in NFD handle the NACKs correctly. > > Yes, this works. A question regarding the implementation: According to > the NFD developer guide, the PIT does not hold nonce values. Thus Z can > not fully reconstruct the interest from C2. Does Z generate a new > nonce? > If yes: Not sure but intuitively I think that loop partially detection > might be broken if the green interest was also part of a loop (because > Z > changes its nonce). > >> >> Lan > > Thanks to all of you for the explanations, > Claudio > >> >>> On Aug 3, 2016, at 4:54 AM, Lixia Zhang wrote: >>> >>> I have a few other questions to the specifics of the scenario. >>> for a short answer quick: interests form C1 and C2 carry different >>> nonces, so your concern on the last slide should not happen as I see. >>> >>>> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: >>>> >>>> Hi all, >>>> >>>> Urs and I constructed a situation in which we think the network does >>>> not behave as expected (attached PDF). Can this happen in the wild >>>> or did we oversee something? >>>> >>>> Thanks, >>>> Urs and Claudio >>>> >>>> _______________________________________________ >>>> Ndn-interest mailing list >>>> Ndn-interest at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>> >>> >>> _______________________________________________ >>> Ndn-interest mailing list >>> Ndn-interest at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From Marc.Mosko at parc.com Wed Aug 3 08:16:48 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Wed, 3 Aug 2016 15:16:48 +0000 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> Message-ID: My understanding is that X should send a ?duplicate NACK? to Z. As long as the NACK is not lost, C2 will get the NACK and re-try its Interest with a difference nonce (if using BestRoute v2 strategy). If the NACK is lost, then you still have the described problematic behavior. Note that the BestRoute v2 strategy will not re-transmit the C2 Interest at Z with a different nonce, it will propagate the NACK to C2. I also think that the duplicate NACK would be propagated along the whole reverse route to Y and then back to X, if using BestRoute v2. Another thing to consider is that NFD uses an aggregation hold-down timer. The Interest from C2 would only be aggregated at Z if it arrived within 250 msec of the Interest from Y. If it arrived after that, it would not be aggregated. This is strategy dependent. I think there?s also current work on using an exponential back off rather than a fixed 250 msec. Yet another another thing to consider is that there are two ways X can detect a duplicate nonce. First is what we?ve talked about, it has a pending PIT entry. The second case is if the duplicate Interest from Z arrives after the content from S has cleared the PIT entry at X, but there is still a ?dead nonce list? entry at X. If you read section 4.2.1 (Incoming Interest Pipeline) of version 6 (I believe current) NFD guide, step 2 is to check the Dead Nonce List. In this case, even though X may have a content store entry, the Interest from Z is given to the ?Interest loop pipeline?. It explicitly does not create an in-record for the Interest from Z. Section 4.2.2 (Interest loop pipeline) will generate a NACK and drop the Interest. At this point Z would forward the NACK to C2 (via BestRoute) and C2 would re-try. Finally, one should also note that a duplicate NACK is only generated on a point-to-point face. If the incoming face is multiple access, no NACK is generated. C2 would need to timeout in that case. Marc > On Aug 3, 2016, at 6:43 AM, marxer at claudio.li wrote: > > > On 08/03/16 14:28, Lan Wang (lanwang) wrote: >> They have different nonces but if the PIT entry created by C1 has not been removed, then C2 may be suppressed. This is the dangling PIT entries problem.The solutions (already implemented in NFD) are the following: > > Yes, this is what we meant in the example. > >> 1. some strategies, e.g., recent versions of BestRoute) allow interest retransmission: when an interest is forwarded, a suppression timer is set on the PIT. When the timer expires, it may forward any new Interest matching the PIT (and then set the suppression timer again). >> 2. when X detects an Interest with a duplicate nonce, it sends a duplicate NACK which may be further forwarded to clear the dangling PIT entries at the nodes that sent the interest. When the PIT entry is cleared, new interest with the same name can be forwarded. Right now some strategies (not all) in NFD handle the NACKs correctly. > > Yes, this works. A question regarding the implementation: According to the NFD developer guide, the PIT does not hold nonce values. Thus Z can not fully reconstruct the interest from C2. Does Z generate a new nonce? If yes: Not sure but intuitively I think that loop partially detection might be broken if the green interest was also part of a loop (because Z changes its nonce). > >> Lan > > Thanks to all of you for the explanations, > Claudio > >>> On Aug 3, 2016, at 4:54 AM, Lixia Zhang wrote: >>> I have a few other questions to the specifics of the scenario. >>> for a short answer quick: interests form C1 and C2 carry different nonces, so your concern on the last slide should not happen as I see. >>>> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: >>>> Hi all, >>>> Urs and I constructed a situation in which we think the network does not behave as expected (attached PDF). Can this happen in the wild or did we oversee something? >>>> Thanks, >>>> Urs and Claudio >>>> _______________________________________________ >>>> Ndn-interest mailing list >>>> Ndn-interest at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>> _______________________________________________ >>> Ndn-interest mailing list >>> Ndn-interest at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From marxer at claudio.li Wed Aug 3 09:03:27 2016 From: marxer at claudio.li (marxer at claudio.li) Date: Wed, 03 Aug 2016 18:03:27 +0200 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> Message-ID: <2e86e10f-4e77-b5b7-c13a-a4f862c5a08e@claudio.li> On 08/03/16 17:16, Marc.Mosko at parc.com wrote: > My understanding is that X should send a ?duplicate NACK? to Z. As > long as the NACK is not lost, C2 will get the NACK and re-try its > Interest with a difference nonce (if using BestRoute v2 strategy). If > the NACK is lost, then you still have the described problematic > behavior. Note that the BestRoute v2 strategy will not re-transmit the > C2 Interest at Z with a different nonce, it will propagate the NACK to > C2. Right, the point is missed is that the interest of C2 (green) dangles at Z *but* the "duplicate NACK" caused by C1s looping interest (red) still reaches C2. Then the obvious solutions is - as you say - that C2 (instead of Z, as I first thought) re-tries with a new nonce. This new interest will not dangle at Z since Z meanwhile cleaned its PIT due to the NACK. "By-insight": Receiving a "duplicate NACK" does not necessarily mean that the own interest looped but also refer to an interest which carries the same name as the own interest but is generated by someone else. > > I also think that the duplicate NACK would be propagated along the > whole reverse route to Y and then back to X, if using BestRoute v2. > > Another thing to consider is that NFD uses an aggregation hold-down > timer. The Interest from C2 would only be aggregated at Z if it > arrived within 250 msec of the Interest from Y. If it arrived after > that, it would not be aggregated. This is strategy dependent. I think > there?s also current work on using an exponential back off rather than > a fixed 250 msec. > > Yet another another thing to consider is that there are two ways X can > detect a duplicate nonce. First is what we?ve talked about, it has a > pending PIT entry. The second case is if the duplicate Interest from Z > arrives after the content from S has cleared the PIT entry at X, but > there is still a ?dead nonce list? entry at X. If you read section > 4.2.1 (Incoming Interest Pipeline) of version 6 (I believe current) NFD > guide, step 2 is to check the Dead Nonce List. In this case, even > though X may have a content store entry, the Interest from Z is given > to the ?Interest loop pipeline?. It explicitly does not create an > in-record for the Interest from Z. Section 4.2.2 (Interest loop > pipeline) will generate a NACK and drop the Interest. At this point Z > would forward the NACK to C2 (via BestRoute) and C2 would re-try. > > Finally, one should also note that a duplicate NACK is only generated > on a point-to-point face. If the incoming face is multiple access, no > NACK is generated. C2 would need to timeout in that case. Thank you for all the additional information. > > Marc Claudio > > >> On Aug 3, 2016, at 6:43 AM, marxer at claudio.li wrote: >> >> >> On 08/03/16 14:28, Lan Wang (lanwang) wrote: >>> They have different nonces but if the PIT entry created by C1 has not >>> been removed, then C2 may be suppressed. This is the dangling PIT >>> entries problem.The solutions (already implemented in NFD) are the >>> following: >> >> Yes, this is what we meant in the example. >> >>> 1. some strategies, e.g., recent versions of BestRoute) allow >>> interest retransmission: when an interest is forwarded, a suppression >>> timer is set on the PIT. When the timer expires, it may forward any >>> new Interest matching the PIT (and then set the suppression timer >>> again). >>> 2. when X detects an Interest with a duplicate nonce, it sends a >>> duplicate NACK which may be further forwarded to clear the dangling >>> PIT entries at the nodes that sent the interest. When the PIT entry >>> is cleared, new interest with the same name can be forwarded. Right >>> now some strategies (not all) in NFD handle the NACKs correctly. >> >> Yes, this works. A question regarding the implementation: According to >> the NFD developer guide, the PIT does not hold nonce values. Thus Z >> can not fully reconstruct the interest from C2. Does Z generate a new >> nonce? If yes: Not sure but intuitively I think that loop partially >> detection might be broken if the green interest was also part of a >> loop (because Z changes its nonce). >> >>> Lan >> >> Thanks to all of you for the explanations, >> Claudio >> >>>> On Aug 3, 2016, at 4:54 AM, Lixia Zhang wrote: >>>> I have a few other questions to the specifics of the scenario. >>>> for a short answer quick: interests form C1 and C2 carry different >>>> nonces, so your concern on the last slide should not happen as I >>>> see. >>>>> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: >>>>> Hi all, >>>>> Urs and I constructed a situation in which we think the network >>>>> does not behave as expected (attached PDF). Can this happen in the >>>>> wild or did we oversee something? >>>>> Thanks, >>>>> Urs and Claudio >>>>> _______________________________________________ >>>>> Ndn-interest mailing list >>>>> Ndn-interest at lists.cs.ucla.edu >>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>>> _______________________________________________ >>>> Ndn-interest mailing list >>>> Ndn-interest at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From Marc.Mosko at parc.com Wed Aug 3 09:33:26 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Wed, 3 Aug 2016 16:33:26 +0000 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: <2e86e10f-4e77-b5b7-c13a-a4f862c5a08e@claudio.li> References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> <2e86e10f-4e77-b5b7-c13a-a4f862c5a08e@claudio.li> Message-ID: <3FD34434-C560-459D-8B93-6FD1605FAC72@parc.com> > On Aug 3, 2016, at 9:03 AM, marxer at claudio.li wrote: > > On 08/03/16 17:16, Marc.Mosko at parc.com wrote: >> My understanding is that X should send a ?duplicate NACK? to Z. As long as the NACK is not lost, C2 will get the NACK and re-try its Interest with a difference nonce (if using BestRoute v2 strategy). If the NACK is lost, then you still have the described problematic behavior. Note that the BestRoute v2 strategy will not re-transmit the C2 Interest at Z with a different nonce, it will propagate the NACK to C2. > > Right, the point is missed is that the interest of C2 (green) dangles at Z *but* the "duplicate NACK" caused by C1s looping interest (red) still reaches C2. Then the obvious solutions is - as you say - that C2 (instead of Z, as I first thought) re-tries with a new nonce. This new interest will not dangle at Z since Z meanwhile cleaned its PIT due to the NACK. > > "By-insight": Receiving a "duplicate NACK" does not necessarily mean that the own interest looped but also refer to an interest which carries the same name as the own interest but is generated by someone else. The nonce in the NACk from Z to C2 is C2?s nonce. It must be the nonce C2 sent to Z because NFD section 4.4.1 says ?and the last outgoing Nonce was the same as the Nonce carried in the NACK.? So, if Z were to return the C1 nonce, C2 would ignore that NACK. Section 4.4.2 says one must use the in-record (and nonce) in the NACK?s generation. So, C2 cannot determine whose Interest looped. Receiving the ?duplicate NACK? only means _some_ loop happened that prevented C2?s interest from being satisfied. I couldn?t find anything in NFD about what the NACk type is on these relayed duplicate NACKs. I assume they are all the same type. > >> I also think that the duplicate NACK would be propagated along the whole reverse route to Y and then back to X, if using BestRoute v2. >> Another thing to consider is that NFD uses an aggregation hold-down timer. The Interest from C2 would only be aggregated at Z if it arrived within 250 msec of the Interest from Y. If it arrived after that, it would not be aggregated. This is strategy dependent. I think there?s also current work on using an exponential back off rather than a fixed 250 msec. >> Yet another another thing to consider is that there are two ways X can detect a duplicate nonce. First is what we?ve talked about, it has a pending PIT entry. The second case is if the duplicate Interest from Z arrives after the content from S has cleared the PIT entry at X, but there is still a ?dead nonce list? entry at X. If you read section 4.2.1 (Incoming Interest Pipeline) of version 6 (I believe current) NFD guide, step 2 is to check the Dead Nonce List. In this case, even though X may have a content store entry, the Interest from Z is given to the ?Interest loop pipeline?. It explicitly does not create an in-record for the Interest from Z. Section 4.2.2 (Interest loop pipeline) will generate a NACK and drop the Interest. At this point Z would forward the NACK to C2 (via BestRoute) and C2 would re-try. >> Finally, one should also note that a duplicate NACK is only generated on a point-to-point face. If the incoming face is multiple access, no NACK is generated. C2 would need to timeout in that case. > > Thank you for all the additional information. > >> Marc > > Claudio > >>> On Aug 3, 2016, at 6:43 AM, marxer at claudio.li wrote: >>> On 08/03/16 14:28, Lan Wang (lanwang) wrote: >>>> They have different nonces but if the PIT entry created by C1 has not been removed, then C2 may be suppressed. This is the dangling PIT entries problem.The solutions (already implemented in NFD) are the following: >>> Yes, this is what we meant in the example. >>>> 1. some strategies, e.g., recent versions of BestRoute) allow interest retransmission: when an interest is forwarded, a suppression timer is set on the PIT. When the timer expires, it may forward any new Interest matching the PIT (and then set the suppression timer again). >>>> 2. when X detects an Interest with a duplicate nonce, it sends a duplicate NACK which may be further forwarded to clear the dangling PIT entries at the nodes that sent the interest. When the PIT entry is cleared, new interest with the same name can be forwarded. Right now some strategies (not all) in NFD handle the NACKs correctly. >>> Yes, this works. A question regarding the implementation: According to the NFD developer guide, the PIT does not hold nonce values. Thus Z can not fully reconstruct the interest from C2. Does Z generate a new nonce? If yes: Not sure but intuitively I think that loop partially detection might be broken if the green interest was also part of a loop (because Z changes its nonce). >>>> Lan >>> Thanks to all of you for the explanations, >>> Claudio >>>>> On Aug 3, 2016, at 4:54 AM, Lixia Zhang wrote: >>>>> I have a few other questions to the specifics of the scenario. >>>>> for a short answer quick: interests form C1 and C2 carry different nonces, so your concern on the last slide should not happen as I see. >>>>>> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: >>>>>> Hi all, >>>>>> Urs and I constructed a situation in which we think the network does not behave as expected (attached PDF). Can this happen in the wild or did we oversee something? >>>>>> Thanks, >>>>>> Urs and Claudio >>>>>> _______________________________________________ >>>>>> Ndn-interest mailing list >>>>>> Ndn-interest at lists.cs.ucla.edu >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>>>> _______________________________________________ >>>>> Ndn-interest mailing list >>>>> Ndn-interest at lists.cs.ucla.edu >>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>> _______________________________________________ >>> Ndn-interest mailing list >>> Ndn-interest at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From lanwang at memphis.edu Wed Aug 3 12:05:42 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 3 Aug 2016 19:05:42 +0000 Subject: [Ndn-interest] Hyperbolic routing in mobile scenarios In-Reply-To: <41E7DF15B39B5C46BF24C9545D39304C2ADBAD36@oit-ex2010-mb1> References: <41E7DF15B39B5C46BF24C9545D39304C2ADBAD36@oit-ex2010-mb1> Message-ID: <3040121E-9F1D-4495-B024-361732BF6D5A@memphis.edu> Hi Thiago, Thank you for the question. The answer depends on how mobile the nodes are: 1. if the nodes are in general static and 1a. if nodes only occasionally move in a small region, forwarding strategy can take care of some mobility by trying different faces if the face that usually leads to a node doesn?t work; 1b. if a node moves from one network to another network and gains new coordinates belonging to the new network, then the mapping between their content names and the coordinates may be updated in the mapping system so the new coordinates can be distributed or looked up; 2. if nodes are highly dynamic like in an ad hoc network, I?m not aware of any hyperbolic routing work in this area and it could be a potentially interesting research area. If you find such work, I would be glad to know. Lan On Jul 31, 2016, at 7:09 PM, Thiago Teixeira > wrote: Hi all, I have been reading about hyperbolic routing in NDN and how Interest/Data packets can be routed without the full knowledge of the network, through the hyperbolic coordinates and greedy routing; however, in all examples I?ve seen, the nodes are fixed. Has anybody studied hyperbolic routing in mobile topologies? Cheers, Thiago _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Wed Aug 3 19:26:30 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Thu, 4 Aug 2016 02:26:30 +0000 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> Message-ID: <12145F13-004E-4F67-AF5F-628C274B6F33@memphis.edu> > On Aug 3, 2016, at 8:43 AM, marxer at claudio.li wrote: > > > On 08/03/16 14:28, Lan Wang (lanwang) wrote: >> They have different nonces but if the PIT entry created by C1 has not been removed, then C2 may be suppressed. This is the dangling PIT entries problem.The solutions (already implemented in NFD) are the following: > > Yes, this is what we meant in the example. > >> 1. some strategies, e.g., recent versions of BestRoute) allow interest retransmission: when an interest is forwarded, a suppression timer is set on the PIT. When the timer expires, it may forward any new Interest matching the PIT (and then set the suppression timer again). >> 2. when X detects an Interest with a duplicate nonce, it sends a duplicate NACK which may be further forwarded to clear the dangling PIT entries at the nodes that sent the interest. When the PIT entry is cleared, new interest with the same name can be forwarded. Right now some strategies (not all) in NFD handle the NACKs correctly. > > Yes, this works. A question regarding the implementation: According to the NFD developer guide, the PIT does not hold nonce values. Thus Z can not fully reconstruct the interest from C2. Does Z generate a new nonce? If yes: Not sure but intuitively I think that loop partially detection might be broken if the green interest was also part of a loop (because Z changes its nonce). PIT entries do keep some nonce information (for each in-record and out-record, it keeps the last nonce and also a copy of the interest if I understand correctly). Lan > >> Lan > > Thanks to all of you for the explanations, > Claudio > >>> On Aug 3, 2016, at 4:54 AM, Lixia Zhang wrote: >>> I have a few other questions to the specifics of the scenario. >>> for a short answer quick: interests form C1 and C2 carry different nonces, so your concern on the last slide should not happen as I see. >>>> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: >>>> Hi all, >>>> Urs and I constructed a situation in which we think the network does not behave as expected (attached PDF). Can this happen in the wild or did we oversee something? >>>> Thanks, >>>> Urs and Claudio >>>> _______________________________________________ >>>> Ndn-interest mailing list >>>> Ndn-interest at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>> _______________________________________________ >>> Ndn-interest mailing list >>> Ndn-interest at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From lanwang at memphis.edu Thu Aug 4 07:25:26 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Thu, 4 Aug 2016 14:25:26 +0000 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> Message-ID: <67C76B72-02E5-4881-A29B-08240075C68D@memphis.edu> Marc, > On Aug 3, 2016, at 10:16 AM, Marc.Mosko at parc.com wrote: > > My understanding is that X should send a ?duplicate NACK? to Z. As long as the NACK is not lost, C2 will get the NACK and re-try its Interest with a difference nonce (if using BestRoute v2 strategy). If the NACK is lost, then you still have the described problematic behavior. Note that the BestRoute v2 strategy will not re-transmit the C2 Interest at Z with a different nonce, it will propagate the NACK to C2. The NACK will not be propagated from Z to C2 because the NACKed nonce is difference from the nonce in C2?s interest. > > I also think that the duplicate NACK would be propagated along the whole reverse route to Y and then back to X, if using BestRoute v2. This is correct. > > Another thing to consider is that NFD uses an aggregation hold-down timer. The Interest from C2 would only be aggregated at Z if it arrived within 250 msec of the Interest from Y. If it arrived after that, it would not be aggregated. This is strategy dependent. I think there?s also current work on using an exponential back off rather than a fixed 250 sec. Yes. > > Yet another another thing to consider is that there are two ways X can detect a duplicate nonce. First is what we?ve talked about, it has a pending PIT entry. The second case is if the duplicate Interest from Z arrives after the content from S has cleared the PIT entry at X, but there is still a ?dead nonce list? entry at X. If you read section 4.2.1 (Incoming Interest Pipeline) of version 6 (I believe current) NFD guide, step 2 is to check the Dead Nonce List. Yes. > In this case, even though X may have a content store entry, the Interest from Z is given to the ?Interest loop pipeline?. It explicitly does not create an in-record for the Interest from Z. Section 4.2.2 (Interest loop pipeline) will generate a NACK and drop the Interest. At this point Z would forward the NACK to C2 (via BestRoute) and C2 would re-try. > I don?t think the NACK will be forwarded to C2. > Finally, one should also note that a duplicate NACK is only generated on a point-to-point face. If the incoming face is multiple access, no NACK is generated. C2 would need to timeout in that case. Right now NACK is only generated on a point-to-point face in NFD, because we don?t have a final NACK design for multi-access links yet. But NACK is still applicable to multi-access links in general. Lan > > Marc > > >> On Aug 3, 2016, at 6:43 AM, marxer at claudio.li wrote: >> >> >> On 08/03/16 14:28, Lan Wang (lanwang) wrote: >>> They have different nonces but if the PIT entry created by C1 has not been removed, then C2 may be suppressed. This is the dangling PIT entries problem.The solutions (already implemented in NFD) are the following: >> >> Yes, this is what we meant in the example. >> >>> 1. some strategies, e.g., recent versions of BestRoute) allow interest retransmission: when an interest is forwarded, a suppression timer is set on the PIT. When the timer expires, it may forward any new Interest matching the PIT (and then set the suppression timer again). >>> 2. when X detects an Interest with a duplicate nonce, it sends a duplicate NACK which may be further forwarded to clear the dangling PIT entries at the nodes that sent the interest. When the PIT entry is cleared, new interest with the same name can be forwarded. Right now some strategies (not all) in NFD handle the NACKs correctly. >> >> Yes, this works. A question regarding the implementation: According to the NFD developer guide, the PIT does not hold nonce values. Thus Z can not fully reconstruct the interest from C2. Does Z generate a new nonce? If yes: Not sure but intuitively I think that loop partially detection might be broken if the green interest was also part of a loop (because Z changes its nonce). >> >>> Lan >> >> Thanks to all of you for the explanations, >> Claudio >> >>>> On Aug 3, 2016, at 4:54 AM, Lixia Zhang wrote: >>>> I have a few other questions to the specifics of the scenario. >>>> for a short answer quick: interests form C1 and C2 carry different nonces, so your concern on the last slide should not happen as I see. >>>>> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: >>>>> Hi all, >>>>> Urs and I constructed a situation in which we think the network does not behave as expected (attached PDF). Can this happen in the wild or did we oversee something? >>>>> Thanks, >>>>> Urs and Claudio >>>>> _______________________________________________ >>>>> Ndn-interest mailing list >>>>> Ndn-interest at lists.cs.ucla.edu >>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>>> _______________________________________________ >>>> Ndn-interest mailing list >>>> Ndn-interest at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From Marc.Mosko at parc.com Thu Aug 4 07:51:46 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Thu, 4 Aug 2016 14:51:46 +0000 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: <67C76B72-02E5-4881-A29B-08240075C68D@memphis.edu> References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> <67C76B72-02E5-4881-A29B-08240075C68D@memphis.edu> Message-ID: > On Aug 4, 2016, at 7:25 AM, Lan Wang (lanwang) wrote: > > Marc, > >> On Aug 3, 2016, at 10:16 AM, Marc.Mosko at parc.com wrote: >> >> My understanding is that X should send a ?duplicate NACK? to Z. As long as the NACK is not lost, C2 will get the NACK and re-try its Interest with a difference nonce (if using BestRoute v2 strategy). If the NACK is lost, then you still have the described problematic behavior. Note that the BestRoute v2 strategy will not re-transmit the C2 Interest at Z with a different nonce, it will propagate the NACK to C2. > > The NACK will not be propagated from Z to C2 because the NACKed nonce is difference from the nonce in C2?s interest. I thought that with BestRoute v2 it will propagate errors. Section 5.2.1 (BestRoute v2, Nack Processing) it says ?If all pending upstreams have Nacked, a Nack is sent to all downstreams.? And based on the text in 4.4.2 (Outgoing Nack Pipeline), each of those NACKs would carry the nonce of the in-record, so C2 would get a NACk with its nonce and Y would get a NACK with its nonce (the original C1 nonce). If they do not propagate, then you think in the case described in the slide deck that C2 has to time out? >> >> I also think that the duplicate NACK would be propagated along the whole reverse route to Y and then back to X, if using BestRoute v2. > > This is correct. >> >> Another thing to consider is that NFD uses an aggregation hold-down timer. The Interest from C2 would only be aggregated at Z if it arrived within 250 msec of the Interest from Y. If it arrived after that, it would not be aggregated. This is strategy dependent. I think there?s also current work on using an exponential back off rather than a fixed 250 sec. > > Yes. >> >> Yet another another thing to consider is that there are two ways X can detect a duplicate nonce. First is what we?ve talked about, it has a pending PIT entry. The second case is if the duplicate Interest from Z arrives after the content from S has cleared the PIT entry at X, but there is still a ?dead nonce list? entry at X. If you read section 4.2.1 (Incoming Interest Pipeline) of version 6 (I believe current) NFD guide, step 2 is to check the Dead Nonce List. > > Yes. > >> In this case, even though X may have a content store entry, the Interest from Z is given to the ?Interest loop pipeline?. It explicitly does not create an in-record for the Interest from Z. Section 4.2.2 (Interest loop pipeline) will generate a NACK and drop the Interest. At this point Z would forward the NACK to C2 (via BestRoute) and C2 would re-try. >> > I don?t think the NACK will be forwarded to C2. Same argument as in the 1st response above. I?m pretty sure it would, at least with BestRoute v2 as described in NFD guide. If it does not, then you are back in the case where C2 has to time out. And you could perpetually blackhole C2 given an adversarial timing of Interest retransmissions along the X->Y->Z->X path. > >> Finally, one should also note that a duplicate NACK is only generated on a point-to-point face. If the incoming face is multiple access, no NACK is generated. C2 would need to timeout in that case. > > Right now NACK is only generated on a point-to-point face in NFD, because we don?t have a final NACK design for multi-access links yet. But NACK is still applicable to multi-access links in general. Yes, I think in principle NACK should be usable on multi-access faces. I was pointing out that the current design, as described, does not do NACK on multi-access faces. BTW, its a multi-access face, which is different than a multi-access link, yes? I can still have point-to-point faces over Ethernet, for example. > > Lan >> >> Marc >> >> >>> On Aug 3, 2016, at 6:43 AM, marxer at claudio.li wrote: >>> >>> >>> On 08/03/16 14:28, Lan Wang (lanwang) wrote: >>>> They have different nonces but if the PIT entry created by C1 has not been removed, then C2 may be suppressed. This is the dangling PIT entries problem.The solutions (already implemented in NFD) are the following: >>> >>> Yes, this is what we meant in the example. >>> >>>> 1. some strategies, e.g., recent versions of BestRoute) allow interest retransmission: when an interest is forwarded, a suppression timer is set on the PIT. When the timer expires, it may forward any new Interest matching the PIT (and then set the suppression timer again). >>>> 2. when X detects an Interest with a duplicate nonce, it sends a duplicate NACK which may be further forwarded to clear the dangling PIT entries at the nodes that sent the interest. When the PIT entry is cleared, new interest with the same name can be forwarded. Right now some strategies (not all) in NFD handle the NACKs correctly. >>> >>> Yes, this works. A question regarding the implementation: According to the NFD developer guide, the PIT does not hold nonce values. Thus Z can not fully reconstruct the interest from C2. Does Z generate a new nonce? If yes: Not sure but intuitively I think that loop partially detection might be broken if the green interest was also part of a loop (because Z changes its nonce). >>> >>>> Lan >>> >>> Thanks to all of you for the explanations, >>> Claudio >>> >>>>> On Aug 3, 2016, at 4:54 AM, Lixia Zhang wrote: >>>>> I have a few other questions to the specifics of the scenario. >>>>> for a short answer quick: interests form C1 and C2 carry different nonces, so your concern on the last slide should not happen as I see. >>>>>> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: >>>>>> Hi all, >>>>>> Urs and I constructed a situation in which we think the network does not behave as expected (attached PDF). Can this happen in the wild or did we oversee something? >>>>>> Thanks, >>>>>> Urs and Claudio >>>>>> _______________________________________________ >>>>>> Ndn-interest mailing list >>>>>> Ndn-interest at lists.cs.ucla.edu >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>>>> _______________________________________________ >>>>> Ndn-interest mailing list >>>>> Ndn-interest at lists.cs.ucla.edu >>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>> _______________________________________________ >>> Ndn-interest mailing list >>> Ndn-interest at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> > From marxer at claudio.li Thu Aug 4 07:55:21 2016 From: marxer at claudio.li (marxer at claudio.li) Date: Thu, 04 Aug 2016 16:55:21 +0200 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: <67C76B72-02E5-4881-A29B-08240075C68D@memphis.edu> References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> <67C76B72-02E5-4881-A29B-08240075C68D@memphis.edu> Message-ID: <7fb0f7ff-86d4-8b37-efe8-bfed8f6cd948@claudio.li> On 08/04/16 16:25, Lan Wang (lanwang) wrote: > Marc, > >> On Aug 3, 2016, at 10:16 AM, Marc.Mosko at parc.com wrote: >> >> My understanding is that X should send a ?duplicate NACK? to Z. As >> long as the NACK is not lost, C2 will get the NACK and re-try its >> Interest with a difference nonce (if using BestRoute v2 strategy). If >> the NACK is lost, then you still have the described problematic >> behavior. Note that the BestRoute v2 strategy will not re-transmit >> the C2 Interest at Z with a different nonce, it will propagate the >> NACK to C2. > > The NACK will not be propagated from Z to C2 because the NACKed nonce > is difference from the nonce in C2?s interest. Since the interests from C1 and C2 are aggregated by Z, both clients are affected. Wouldn't it make sense that Z separates the NACK and also informs C2? For example by exchanging the nonce in the NACK or with something like a "dangling-entry-NACK" generated by Z. At the point C2 receives such a "dangling-entry-NACK", the PIT entries of the looping interest are removed because of the "duplicate NACK". Thus C2 could succesfully re-try. >> >> I also think that the duplicate NACK would be propagated along the >> whole reverse route to Y and then back to X, if using BestRoute v2. > > This is correct. >> >> Another thing to consider is that NFD uses an aggregation hold-down >> timer. The Interest from C2 would only be aggregated at Z if it >> arrived within 250 msec of the Interest from Y. If it arrived after >> that, it would not be aggregated. This is strategy dependent. I think >> there?s also current work on using an exponential back off rather than >> a fixed 250 sec. > > Yes. >> >> Yet another another thing to consider is that there are two ways X can >> detect a duplicate nonce. First is what we?ve talked about, it has a >> pending PIT entry. The second case is if the duplicate Interest from >> Z arrives after the content from S has cleared the PIT entry at X, but >> there is still a ?dead nonce list? entry at X. If you read section >> 4.2.1 (Incoming Interest Pipeline) of version 6 (I believe current) >> NFD guide, step 2 is to check the Dead Nonce List. > > Yes. > >> In this case, even though X may have a content store entry, the >> Interest from Z is given to the ?Interest loop pipeline?. It >> explicitly does not create an in-record for the Interest from Z. >> Section 4.2.2 (Interest loop pipeline) will generate a NACK and drop >> the Interest. At this point Z would forward the NACK to C2 (via >> BestRoute) and C2 would re-try. >> > I don?t think the NACK will be forwarded to C2. > >> Finally, one should also note that a duplicate NACK is only generated >> on a point-to-point face. If the incoming face is multiple access, no >> NACK is generated. C2 would need to timeout in that case. > > Right now NACK is only generated on a point-to-point face in NFD, > because we don?t have a final NACK design for multi-access links yet. > But NACK is still applicable to multi-access links in general. > > Lan >> >> Marc >> >> >>> On Aug 3, 2016, at 6:43 AM, marxer at claudio.li wrote: >>> >>> >>> On 08/03/16 14:28, Lan Wang (lanwang) wrote: >>>> They have different nonces but if the PIT entry created by C1 has >>>> not been removed, then C2 may be suppressed. This is the dangling >>>> PIT entries problem.The solutions (already implemented in NFD) are >>>> the following: >>> >>> Yes, this is what we meant in the example. >>> >>>> 1. some strategies, e.g., recent versions of BestRoute) allow >>>> interest retransmission: when an interest is forwarded, a >>>> suppression timer is set on the PIT. When the timer expires, it >>>> may forward any new Interest matching the PIT (and then set the >>>> suppression timer again). >>>> 2. when X detects an Interest with a duplicate nonce, it sends a >>>> duplicate NACK which may be further forwarded to clear the dangling >>>> PIT entries at the nodes that sent the interest. When the PIT entry >>>> is cleared, new interest with the same name can be forwarded. Right >>>> now some strategies (not all) in NFD handle the NACKs correctly. >>> >>> Yes, this works. A question regarding the implementation: According >>> to the NFD developer guide, the PIT does not hold nonce values. Thus >>> Z can not fully reconstruct the interest from C2. Does Z generate a >>> new nonce? If yes: Not sure but intuitively I think that loop >>> partially detection might be broken if the green interest was also >>> part of a loop (because Z changes its nonce). >>> >>>> Lan >>> >>> Thanks to all of you for the explanations, >>> Claudio >>> >>>>> On Aug 3, 2016, at 4:54 AM, Lixia Zhang wrote: >>>>> I have a few other questions to the specifics of the scenario. >>>>> for a short answer quick: interests form C1 and C2 carry different >>>>> nonces, so your concern on the last slide should not happen as I >>>>> see. >>>>>> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: >>>>>> Hi all, >>>>>> Urs and I constructed a situation in which we think the network >>>>>> does not behave as expected (attached PDF). Can this happen in the >>>>>> wild or did we oversee something? >>>>>> Thanks, >>>>>> Urs and Claudio >>>>>> _______________________________________________ >>>>>> Ndn-interest mailing list >>>>>> Ndn-interest at lists.cs.ucla.edu >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>>>> _______________________________________________ >>>>> Ndn-interest mailing list >>>>> Ndn-interest at lists.cs.ucla.edu >>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>> _______________________________________________ >>> Ndn-interest mailing list >>> Ndn-interest at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> > From urs.schnurrenberger at unibas.ch Thu Aug 4 08:18:04 2016 From: urs.schnurrenberger at unibas.ch (Urs Schnurrenberger) Date: Thu, 4 Aug 2016 15:18:04 +0000 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> <67C76B72-02E5-4881-A29B-08240075C68D@memphis.edu> Message-ID: <4DE5E8A1E5827142BA60833545E632698491034D@urz-mbx-1.urz.unibas.ch> Inline > -----Urspr?ngliche Nachricht----- > Von: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] Im > Auftrag von Marc.Mosko at parc.com > Gesendet: Donnerstag, 4. August 2016 16:52 > An: lanwang at memphis.edu > Cc: ndn-interest at lists.cs.ucla.edu > Betreff: Re: [Ndn-interest] Loop Detection Issue > > > > On Aug 4, 2016, at 7:25 AM, Lan Wang (lanwang) > wrote: > > > > Marc, > > > >> On Aug 3, 2016, at 10:16 AM, Marc.Mosko at parc.com wrote: > >> > >> My understanding is that X should send a ?duplicate NACK? to Z. As > long as the NACK is not lost, C2 will get the NACK and re-try its Interest > with a difference nonce (if using BestRoute v2 strategy). If the NACK is > lost, then you still have the described problematic behavior. Note that > the BestRoute v2 strategy will not re-transmit the C2 Interest at Z with a > different nonce, it will propagate the NACK to C2. > > > > The NACK will not be propagated from Z to C2 because the NACKed > nonce is difference from the nonce in C2?s interest. > > I thought that with BestRoute v2 it will propagate errors. Section 5.2.1 > (BestRoute v2, Nack Processing) it says ?If all pending upstreams have > Nacked, a Nack is sent to all downstreams.? And based on the text in > 4.4.2 (Outgoing Nack Pipeline), each of those NACKs would carry the > nonce of the in-record, so C2 would get a NACk with its nonce and Y > would get a NACK with its nonce (the original C1 nonce). > > If they do not propagate, then you think in the case described in the slide > deck that C2 has to time out? > I think propagating some sort of NACK to C2 is better than accepting a timeout for C2, but wouldn't it be anyway better that Z directly retransmits the Interest from C2 instead of sending a NACK to C2 (and then most probably receiving another Interest from C2)? Urs > > >> > >> I also think that the duplicate NACK would be propagated along the > whole reverse route to Y and then back to X, if using BestRoute v2. > > > > This is correct. > >> > >> Another thing to consider is that NFD uses an aggregation hold-down > timer. The Interest from C2 would only be aggregated at Z if it arrived > within 250 msec of the Interest from Y. If it arrived after that, it would not > be aggregated. This is strategy dependent. I think there?s also current > work on using an exponential back off rather than a fixed 250 sec. > > > > Yes. > >> > >> Yet another another thing to consider is that there are two ways X can > detect a duplicate nonce. First is what we?ve talked about, it has a > pending PIT entry. The second case is if the duplicate Interest from Z > arrives after the content from S has cleared the PIT entry at X, but there is > still a ?dead nonce list? entry at X. If you read section 4.2.1 (Incoming > Interest Pipeline) of version 6 (I believe current) NFD guide, step 2 is to > check the Dead Nonce List. > > > > Yes. > > > >> In this case, even though X may have a content store entry, the > Interest from Z is given to the ?Interest loop pipeline?. It explicitly does > not create an in-record for the Interest from Z. Section 4.2.2 (Interest > loop pipeline) will generate a NACK and drop the Interest. At this point Z > would forward the NACK to C2 (via BestRoute) and C2 would re-try. > >> > > I don?t think the NACK will be forwarded to C2. > > Same argument as in the 1st response above. I?m pretty sure it would, at > least with BestRoute v2 as described in NFD guide. If it does not, then > you are back in the case where C2 has to time out. And you could > perpetually blackhole C2 given an adversarial timing of Interest > retransmissions along the X->Y->Z->X path. > > > > >> Finally, one should also note that a duplicate NACK is only generated > on a point-to-point face. If the incoming face is multiple access, no NACK > is generated. C2 would need to timeout in that case. > > > > Right now NACK is only generated on a point-to-point face in NFD, > because we don?t have a final NACK design for multi-access links yet. But > NACK is still applicable to multi-access links in general. > > Yes, I think in principle NACK should be usable on multi-access faces. I > was pointing out that the current design, as described, does not do NACK > on multi-access faces. BTW, its a multi-access face, which is different than > a multi-access link, yes? I can still have point-to-point faces over Ethernet, > for example. > > > > > Lan > >> > >> Marc > >> > >> > >>> On Aug 3, 2016, at 6:43 AM, marxer at claudio.li wrote: > >>> > >>> > >>> On 08/03/16 14:28, Lan Wang (lanwang) wrote: > >>>> They have different nonces but if the PIT entry created by C1 has > not been removed, then C2 may be suppressed. This is the dangling PIT > entries problem.The solutions (already implemented in NFD) are the > following: > >>> > >>> Yes, this is what we meant in the example. > >>> > >>>> 1. some strategies, e.g., recent versions of BestRoute) allow interest > retransmission: when an interest is forwarded, a suppression timer is set > on the PIT. When the timer expires, it may forward any new Interest > matching the PIT (and then set the suppression timer again). > >>>> 2. when X detects an Interest with a duplicate nonce, it sends a > duplicate NACK which may be further forwarded to clear the dangling PIT > entries at the nodes that sent the interest. When the PIT entry is cleared, > new interest with the same name can be forwarded. Right now some > strategies (not all) in NFD handle the NACKs correctly. > >>> > >>> Yes, this works. A question regarding the implementation: According > to the NFD developer guide, the PIT does not hold nonce values. Thus Z > can not fully reconstruct the interest from C2. Does Z generate a new > nonce? If yes: Not sure but intuitively I think that loop partially detection > might be broken if the green interest was also part of a loop (because Z > changes its nonce). > >>> > >>>> Lan > >>> > >>> Thanks to all of you for the explanations, Claudio > >>> > >>>>> On Aug 3, 2016, at 4:54 AM, Lixia Zhang > wrote: > >>>>> I have a few other questions to the specifics of the scenario. > >>>>> for a short answer quick: interests form C1 and C2 carry different > nonces, so your concern on the last slide should not happen as I see. > >>>>>> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: > >>>>>> Hi all, > >>>>>> Urs and I constructed a situation in which we think the network > does not behave as expected (attached PDF). Can this happen in the wild > or did we oversee something? > >>>>>> Thanks, > >>>>>> Urs and Claudio > >>>>>> ___________________________________________ > >>>>>> ____ > >>>>>> Ndn-interest mailing list > >>>>>> Ndn-interest at lists.cs.ucla.edu > >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > >>>>> _______________________________________________ > >>>>> Ndn-interest mailing list > >>>>> Ndn-interest at lists.cs.ucla.edu > >>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > >>> _______________________________________________ > >>> Ndn-interest mailing list > >>> Ndn-interest at lists.cs.ucla.edu > >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > >> > > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From lanwang at memphis.edu Thu Aug 4 10:13:19 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Thu, 4 Aug 2016 17:13:19 +0000 Subject: [Ndn-interest] Loop Detection Issue In-Reply-To: References: <5ca438cf-fdc8-f5a0-205c-cf3cec1d8c76@claudio.li> <2601D0E5-32E7-40C7-8EE8-9726EDCCEA18@cs.ucla.edu> <67C76B72-02E5-4881-A29B-08240075C68D@memphis.edu> Message-ID: <4F4C08E8-E5EA-4FE0-9532-BE9ABFCBBEBE@memphis.edu> > On Aug 4, 2016, at 9:51 AM, Marc.Mosko at parc.com wrote: > >> >> On Aug 4, 2016, at 7:25 AM, Lan Wang (lanwang) wrote: >> >> Marc, >> >>> On Aug 3, 2016, at 10:16 AM, Marc.Mosko at parc.com wrote: >>> >>> My understanding is that X should send a ?duplicate NACK? to Z. As long as the NACK is not lost, C2 will get the NACK and re-try its Interest with a difference nonce (if using BestRoute v2 strategy). If the NACK is lost, then you still have the described problematic behavior. Note that the BestRoute v2 strategy will not re-transmit the C2 Interest at Z with a different nonce, it will propagate the NACK to C2. >> >> The NACK will not be propagated from Z to C2 because the NACKed nonce is difference from the nonce in C2?s interest. > > I thought that with BestRoute v2 it will propagate errors. Section 5.2.1 (BestRoute v2, Nack Processing) it says ?If all pending upstreams have Nacked, a Nack is sent to all downstreams.? And based on the text in 4.4.2 (Outgoing Nack Pipeline), each of those NACKs would carry the nonce of the in-record, so C2 would get a NACk with its nonce and Y would get a NACK with its nonce (the original C1 nonce). > > If they do not propagate, then you think in the case described in the slide deck that C2 has to time out? I think the correct strategy behavior at Z should forward the pending interest from C2 to X right after receiving the NACK for C1?s interest. The in-record at Z should have C2?s nonce and interest so it?s possible to send C2?s pending interest toward X at this time (instead of waiting for a timeout). What you described may or may not be implemented in BestRouteV2 (I need to read the code to see how it behaves), but in my opinion it doesn?t seem to be the right behavior to return a duplicate NACK with C1?s nonce to C2. I think Junxiao is the best person to clarify all of these as he implemented the BestRouteV2 strategy. But again the current implementation doesn?t necessarily mean it is the correct behavior. > > >>> >>> I also think that the duplicate NACK would be propagated along the whole reverse route to Y and then back to X, if using BestRoute v2. >> >> This is correct. >>> >>> Another thing to consider is that NFD uses an aggregation hold-down timer. The Interest from C2 would only be aggregated at Z if it arrived within 250 msec of the Interest from Y. If it arrived after that, it would not be aggregated. This is strategy dependent. I think there?s also current work on using an exponential back off rather than a fixed 250 sec. >> >> Yes. >>> >>> Yet another another thing to consider is that there are two ways X can detect a duplicate nonce. First is what we?ve talked about, it has a pending PIT entry. The second case is if the duplicate Interest from Z arrives after the content from S has cleared the PIT entry at X, but there is still a ?dead nonce list? entry at X. If you read section 4.2.1 (Incoming Interest Pipeline) of version 6 (I believe current) NFD guide, step 2 is to check the Dead Nonce List. >> >> Yes. >> >>> In this case, even though X may have a content store entry, the Interest from Z is given to the ?Interest loop pipeline?. It explicitly does not create an in-record for the Interest from Z. Section 4.2.2 (Interest loop pipeline) will generate a NACK and drop the Interest. At this point Z would forward the NACK to C2 (via BestRoute) and C2 would re-try. >>> >> I don?t think the NACK will be forwarded to C2. > > Same argument as in the 1st response above. I?m pretty sure it would, at least with BestRoute v2 as described in NFD guide. If it does not, then you are back in the case where C2 has to time out. And you could perpetually blackhole C2 given an adversarial timing of Interest retransmissions along the X->Y->Z->X path. > >> >>> Finally, one should also note that a duplicate NACK is only generated on a point-to-point face. If the incoming face is multiple access, no NACK is generated. C2 would need to timeout in that case. >> >> Right now NACK is only generated on a point-to-point face in NFD, because we don?t have a final NACK design for multi-access links yet. But NACK is still applicable to multi-access links in general. > > Yes, I think in principle NACK should be usable on multi-access faces. I was pointing out that the current design, as described, does not do NACK on multi-access faces. BTW, its a multi-access face, which is different than a multi-access link, yes? I can still have point-to-point faces over Ethernet, for example. Yes, multi-access face. Lan > >> >> Lan >>> >>> Marc >>> >>> >>>> On Aug 3, 2016, at 6:43 AM, marxer at claudio.li wrote: >>>> >>>> >>>> On 08/03/16 14:28, Lan Wang (lanwang) wrote: >>>>> They have different nonces but if the PIT entry created by C1 has not been removed, then C2 may be suppressed. This is the dangling PIT entries problem.The solutions (already implemented in NFD) are the following: >>>> >>>> Yes, this is what we meant in the example. >>>> >>>>> 1. some strategies, e.g., recent versions of BestRoute) allow interest retransmission: when an interest is forwarded, a suppression timer is set on the PIT. When the timer expires, it may forward any new Interest matching the PIT (and then set the suppression timer again). >>>>> 2. when X detects an Interest with a duplicate nonce, it sends a duplicate NACK which may be further forwarded to clear the dangling PIT entries at the nodes that sent the interest. When the PIT entry is cleared, new interest with the same name can be forwarded. Right now some strategies (not all) in NFD handle the NACKs correctly. >>>> >>>> Yes, this works. A question regarding the implementation: According to the NFD developer guide, the PIT does not hold nonce values. Thus Z can not fully reconstruct the interest from C2. Does Z generate a new nonce? If yes: Not sure but intuitively I think that loop partially detection might be broken if the green interest was also part of a loop (because Z changes its nonce). >>>> >>>>> Lan >>>> >>>> Thanks to all of you for the explanations, >>>> Claudio >>>> >>>>>> On Aug 3, 2016, at 4:54 AM, Lixia Zhang wrote: >>>>>> I have a few other questions to the specifics of the scenario. >>>>>> for a short answer quick: interests form C1 and C2 carry different nonces, so your concern on the last slide should not happen as I see. >>>>>>> On Aug 3, 2016, at 1:15 AM, marxer at claudio.li wrote: >>>>>>> Hi all, >>>>>>> Urs and I constructed a situation in which we think the network does not behave as expected (attached PDF). Can this happen in the wild or did we oversee something? >>>>>>> Thanks, >>>>>>> Urs and Claudio >>>>>>> _______________________________________________ >>>>>>> Ndn-interest mailing list >>>>>>> Ndn-interest at lists.cs.ucla.edu >>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>>>>> _______________________________________________ >>>>>> Ndn-interest mailing list >>>>>> Ndn-interest at lists.cs.ucla.edu >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>>> _______________________________________________ >>>> Ndn-interest mailing list >>>> Ndn-interest at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From tnsr.chatterjee at gmail.com Wed Aug 10 11:17:17 2016 From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee) Date: Wed, 10 Aug 2016 23:47:17 +0530 Subject: [Ndn-interest] Periodic sync interest Message-ID: Hello, Can anyone please tell me whether each router sends the periodic sync interests to all other routers in the network or only its direct neighbors? Is it a hop by hop notification when there is any updates? Or the node where the update occurred, floods the update to all other nodes in a data packet? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Thu Aug 11 05:55:39 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Thu, 11 Aug 2016 12:55:39 +0000 Subject: [Ndn-interest] Periodic sync interest In-Reply-To: References: Message-ID: On Aug 10, 2016, at 1:18 PM, Tanusree Chatterjee > wrote: Hello, Can anyone please tell me whether each router sends the periodic sync interests to all other routers in the network or only its direct neighbors? Is it a hop by hop notification when there is any updates? Or the node where the update occurred, floods the update to all other nodes in a data packet? The sync interests are sent using a multicast strategy, but they should be aggregated when every node has the same sync digest (thus same interest). So when the network is stable, only one sync interest is sent per link per direction. Lan _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From agawande at memphis.edu Thu Aug 18 11:58:33 2016 From: agawande at memphis.edu (Ashlesh Gawande (agawande)) Date: Thu, 18 Aug 2016 18:58:33 +0000 Subject: [Ndn-interest] Mini-NDN v0.2.0 release Message-ID: Dear all, We are pleased to announce the release of Mini-NDN v0.2.0. Mini-NDN is a lightweight networking emulation tool that enables testing, experimentation, and research on the NDN platform. Based on Mininet, Mini-NDN uses the NDN libraries, NFD, NLSR, and tools released by the NDN project (http://named-data.net/codebase/platform/) to emulate an NDN network on a single system. Detailed release notes with new features, changes, and bug fixes can be found at: https://github.com/named-data/mini-ndn/blob/master/docs/RELEASE-NOTES.md More information about Mini-NDN, tutorials, installation and configuration guides, and documentation are available at the Mini-NDN Github repository: https://github.com/named-data/mini-ndn Please report any bugs or issues, make feature requests, or provide feedback at our Redmine page: http://redmine.named-data.net/projects/mini-ndn or on our mailing list: http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn * * * Mini-NDN Developers and Contributors: Ashlesh Gawande, Vince Lehman, Yucheng Zhang Lan Wang, Alexander Afanasyev, Junxiao Shi, Beichuan Zhang -------------- next part -------------- An HTML attachment was scrubbed... URL: From tailinchu at gmail.com Thu Aug 18 15:48:41 2016 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Thu, 18 Aug 2016 15:48:41 -0700 Subject: [Ndn-interest] go-ndn 1.4 is released today Message-ID: Dear all, go-ndn 1.4 is released today. In this release, we mainly focus on optimization and increase test coverage. LPM, persistent content store, and implicit digest lookup implementation now are more GC-friendly. Together with go1.7 SSA work, go-ndn application has binary size 20-30% smaller, and runs 16%~22% faster on average. Oli Gavin tested NDN raft[1] implementation in a large-scale setting, and reported several bugs that were fixed in this release. Finally, we change the release cycle to be in sync with go team[2], so the next release go-ndn will happen roughly 1 week after go1.8. This allows us to address important changes from the go programming language. Contributors * Oli Gavin (NDN raft) * Mahyuddin Husairi (udp bug) * Marin Staykov (HMAC bug) Thank you! - go-ndn team [1] https://raft.github.io/ [2] https://github.com/golang/go/wiki/Go-Release-Cycle From jburke at remap.UCLA.EDU Thu Aug 18 18:31:56 2016 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Fri, 19 Aug 2016 01:31:56 +0000 Subject: [Ndn-interest] =?utf-8?q?New_posting_-_NDN_Team=E2=80=99s_Perspec?= =?utf-8?q?tive_on_IPR_and_Licensing?= Message-ID: <79E71770-0710-4873-B387-82ABA3C9E7BA@remap.ucla.edu> Please note the following document was recently posted to the NDN website that may be of interest to some on this list: The Named Data Networking (NDN) Team?s Perspective on IPR and Licensing of NDN and Related ICN Technologies August 15, 2016 https://named-data.net/ipr-aug-2016/ A discussion of the history of IPR and licensing in NDN, as well as the relationship to CCN, in response to community questions and in relation to the ?harmonization? activity in ICNRG. A short index including previous statements on intellectual property is here: https://named-data.net/ipr-approach/ Best, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Sun Aug 21 12:11:42 2016 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Sun, 21 Aug 2016 19:11:42 +0000 Subject: [Ndn-interest] NDNcomm 2016 - Save the Date - November 9-10 @ UCLA Message-ID: <5AE41B43-7984-4CD2-9ABC-54DC84626A1D@remap.ucla.edu> Hi everyone, NDNcomm 2016 will be held at UCLA from November 9-10, 2016. (There may be events, like a hackathon, leading up to it on November 8.) We look forward to seeing you there and will share more details soon! Best, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From tnsr.chatterjee at gmail.com Wed Aug 24 01:49:44 2016 From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee) Date: Wed, 24 Aug 2016 14:19:44 +0530 Subject: [Ndn-interest] Basic Query on LSDB Message-ID: Hi all, One thing I am little confused about is that, in NLSR whether it is known from the LSDB that a particular name prefix is served by which node? So, I came to know the destination of a content while sending the interest for it? And when the interest is being sent, the path is known as the destination is known. But, packets in NDN does not carry source or destination address. Or LSDB content only indicates whether at all the requested content is available in the network? If the content is available then the interest is just forwarded to the next hop router and/or routers? If it is not then it is flooded? Can anyone tell me how does the LSDB in NLSR look like? Thank you for your attention. -- Regards, Tanusree Chatterjee -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Thu Aug 25 11:52:03 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Thu, 25 Aug 2016 18:52:03 +0000 Subject: [Ndn-interest] Basic Query on LSDB In-Reply-To: References: Message-ID: <52008A6D-9203-4441-AECA-7611462F67F7@memphis.edu> On Aug 24, 2016, at 3:49 AM, Tanusree Chatterjee > wrote: Hi all, One thing I am little confused about is that, in NLSR whether it is known from the LSDB that a particular name prefix is served by which node? So, I came to know the destination of a content while sending the interest for it? And when the interest is being sent, the path is known as the destination is known. But, packets in NDN does not carry source or destination address. When a node advertises a name prefix, it puts its own name as the originator in the name LSA. Other nodes use the topology of the network (based on the adjacency LSAs) to figure out how to reach the originator of the name prefix. When an interest is sent, we only know the name in the interest (not who has the data). This name is matched against the forwarding table to decide where to send the interest. Or LSDB content only indicates whether at all the requested content is available in the network? If the content is available then the interest is just forwarded to the next hop router and/or routers? If it is not then it is flooded? The information in the LSDB contains all the name prefixes available and who advertised them, as well as all the adjacencies (the topology of the network). This information can be used to compute the next hop(s) toward each name prefix. Interests can be forwarded along the best next hop or multiple next hops depending on the forwarding strategy. Can anyone tell me how does the LSDB in NLSR look like? The best way to understand the LSDB in NLSR is to read the following: - our technical report: A Secure Link State Routing Protocol for NDN. Vince Lehman, A K M Mahmudul Hoque, Yingdi Yu, Lan Wang, Beichuan Zhang, and Lixia Zhang. NDN, Technical Report NDN-0037. http://named-data.net/publications/techreports/ndn-0037-1-nlsr/ - the latest code: https://github.com/named-data/NLSR - NLSR developer?s guide that describes our implementation: https://netwisdom.cs.memphis.edu/gitlab/vslehman/nlsr-docs/blob/master/nlsr-docs.pdf Lan ************************************************ Lan Wang Professor & Chair Department of Computer Science University of Memphis Memphis, TN 38152 Phone: 901-678-1643 URL: http://www.cs.memphis.edu/~lanwang *********************************************** Thank you for your attention. -- Regards, Tanusree Chatterjee _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Fri Aug 26 17:16:17 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Fri, 26 Aug 2016 17:16:17 -0700 Subject: [Ndn-interest] [NDN-TR] NDN-0041 revision 1: Hop-By-Hop Best Effort Link Layer Reliability in Named Data Networking Message-ID: A new NDN Technical Report (initial revision) is now available on NDN website. Comments and suggestions are highly welcome. Title : Hop-By-Hop Best Effort Link Layer Reliability in Named Data Networking Authors : Satyanarayana Vusirikala, Spyridon Mastorakis, Alexander Afanasyev, Lixia Zhang Number : NDN-0041 Revision : 1 Revision Date : August 26, 2016 Abstract: Named Data Networking (NDN) supports the best effort data retrieval using Interest-Data exchanges. When either an Interest or Data packet is lost and not recovered by the router?s Interest forwarding strategy (e.g., by retransmitting the Interest along an alternative path), relying on end applications for loss detection may add significant delays in data retrieval that can impact application performance. In this paper, we propose a best effort hop-by-hop link layer reliability protocol (BELRP) for point-to-point communication links. BELRP makes a quick, non-persistent attempt to detect and recover packet losses over a single link with minimal delay. We evaluated BELRP through simulations and our results show that BELRP can significantly shorten data retrieval delays and hence improve application performance, especially over networks with non- negligible probability of packet losses. Information page for this TR: https://named-data.net/publications/techreports/ndn-0041-1-hop-by-hop-link-reliability/ Direct link to PDF: https://named-data.net/wp-content/uploads/2016/08/ndn-0041-1-hop-by-hop-link-reliability.pdf Other NDN Technical Reports: http://named-data.net/publications/techreports/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From aa at CS.UCLA.EDU Fri Aug 26 18:30:55 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Fri, 26 Aug 2016 18:30:55 -0700 Subject: [Ndn-interest] [NDN-TR] NDN-0040 revision 1: NDN DeLorean: An Authentication System for Data Archives in Named Data Networking Message-ID: <06F6FA7C-89D9-4532-B8FF-8A02DC729445@cs.ucla.edu> A new NDN Technical Report (initial revision) is now available on NDN website. Comments and suggestions are highly welcome. Title : NDN DeLorean: An Authentication System for Data Archives in Named Data Networking Authors : Yingdi Yu, Alexander Afanasyev, Lixia Zhang Number : NDN-0040 Revision : 1 Revision Date : May 24, 2016 Abstract: Named Data Networking (NDN) enables data-centric security in network communication by mandating digital signatures on network-layer data packets. This change introduces a new issue with data authentication: the lifetime of data can be longer than the lifetime of the signatures which is limited by the validity periods of the corresponding certificates. In this paper, we introduce a new authentication system for archived NDN data, NDN DeLorean, which uses a look back validation model that authenticates data considering the time point when the data was produced instead of the time it is being retrieved. As long as the archived data received a valid signature at the time of its production, it can stay valid perpetually. We designed NDN DeLorean as a publicly audited timestamp service that maintains a historical evidence of the data?s validity. NDN DeLorean creates permanent existence proofs of data (and certificates) upon request at a time when the original data signatures are valid. With both data and its signing key certificates being time stamped, DeLorean frees data producers from necessity to periodically re-sign archived data in order to keep it valid. Information page for this TR: http://named-data.net/publications/techreports/ndn-0040-1-delorean/ Direct link to PDF: http://named-data.net/wp-content/uploads/2016/05/ndn-0040-1-delorean.pdf Other NDN Technical Reports: http://named-data.net/publications/techreports/ * * * Apologies for a late notification * * * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alexni1992 at gmail.com Tue Aug 30 19:10:01 2016 From: alexni1992 at gmail.com (Alexander Ni) Date: Wed, 31 Aug 2016 11:10:01 +0900 Subject: [Ndn-interest] NLSR build error Message-ID: Hello, I tried to build NLSR (0.3.0-6-g63bd034), but get next error. [root at Producer1 NLSR]# ./waf configure Setting top to : /usr/ndn/NLSR Setting out to : /usr/ndn/NLSR/build Checking for 'g++' (C++ compiler) : /usr/lib64/ccache/g++ Checking supported CXXFLAGS : -std=c++11 Checking supported CXXFLAGS : -O2 -g -pedantic -Wall -Wextra -Wno-unused-parameter -fdiagnostics-color Checking for program 'doxygen' : /usr/bin/doxygen Checking for program 'tar' : /usr/bin/tar Checking for program 'sphinx-build' : /usr/bin/sphinx-build Checking for program 'pkg-config' : /usr/bin/pkg-config Checking for 'libndn-cxx' : yes Checking for 'liblog4cxx' : yes Checking for OpenSSL library : yes Checking boost includes : 1.58.0 Checking boost libs : ok Checking for boost linkage : ok Checking for 'protobuf' : yes Checking for program 'protoc' : /usr/bin/protoc 'configure' finished successfully (7.053s) [root at Producer1 NLSR]# ./waf Waf: Entering directory `/usr/ndn/NLSR/build' [ 1/57] Compiling src/version.hpp.in [ 2/57] Processing nsync/sync-state.proto [ 3/57] Processing sphinx_build [man]: docs/manpages/nlsr.conf.rst docs/manpages/nlsr.rst docs/manpages/nlsrc.rst docs/conf.py -> build/docs/manpages/nlsr.1 build/docs/manpages/nlsr.conf.5 build/docs/manpages/nlsrc.1 [ 4/57] Compiling src/main.cpp [ 5/57] Compiling src/tlv/coordinate-lsa.cpp [ 6/57] Compiling src/tlv/adjacency.cpp [ 7/57] Compiling src/tlv/adjacency-lsa.cpp [ 8/57] Compiling src/sequencing-manager.cpp [ 9/57] Compiling src/route/routing-table-calculator.cpp [11/57] Compiling src/route/name-prefix-table-entry.cpp [11/57] Compiling src/route/map.cpp [12/57] Compiling src/publisher/lsdb-status-publisher.cpp [13/57] Compiling src/nlsr.cpp [14/57] Compiling src/logger.cpp [15/57] Compiling src/conf-file-processor.cpp [16/57] Compiling src/adjacency-list.cpp [17/57] Compiling nsync/sync-logging.cc [18/57] Compiling nsync/sync-full-leaf.cc [19/57] Compiling nsync/sync-diff-state.cc [20/57] Compiling nsync/sync-diff-leaf.cc [21/57] Compiling src/conf-parameter.cpp [22/57] Compiling src/lsa.cpp [23/57] Compiling src/nlsr-runner.cpp [24/57] Compiling src/route/fib-entry.cpp [25/57] Compiling src/route/name-prefix-table.cpp [26/57] Compiling src/route/routing-table.cpp [27/57] Compiling src/tlv/lsa-info.cpp [28/57] Compiling src/tlv/name-lsa.cpp [29/57] Compiling tools/nlsrc.cpp [30/57] Compiling src/tlv/lsdb-status.cpp [31/57] Compiling src/publisher/lsdb-dataset-interest-handler.cpp [32/57] Compiling src/publisher/lsa-publisher.cpp [33/57] Compiling src/name-prefix-list.cpp [34/57] Compiling src/communication/sync-logic-handler.cpp [35/57] Compiling nsync/sync-std-name-info.cc [36/57] Compiling nsync/sync-name-info.cc [37/57] Compiling nsync/sync-logic.cc [38/57] Compiling nsync/sync-full-state.cc [39/57] Compiling nsync/sync-digest.cc [40/57] Compiling nsync/sync-interest-table.cc [41/57] Compiling nsync/sync-leaf.cc [42/57] Compiling nsync/sync-seq-no.cc [43/57] Compiling nsync/sync-socket.cc [45/57] Compiling build/nsync/sync-state.pb.cc [44/57] Compiling nsync/sync-state.cc [46/57] Compiling src/adjacent.cpp [47/57] Compiling src/hello-protocol.cpp [48/57] Compiling src/lsdb.cpp [49/57] Compiling src/route/face-map.cpp [50/57] Compiling src/route/fib.cpp [51/57] Compiling src/route/nexthop-list.cpp [52/57] Compiling src/route/nexthop.cpp [53/57] Compiling src/update/prefix-update-commands.cpp [54/57] Compiling src/update/prefix-update-processor.cpp [55/57] Compiling src/utility/face-controller.cpp ../src/utility/face-controller.cpp: In member function ?void nlsr::util::FaceController::onCanonizeFailure(const string&, const CommandSuccessCallback&, const CommandFailureCallback&, const ndn::util::FaceUri&)?: ../src/utility/face-controller.cpp:79:13: error: ?ControlResponse? is not a member of ?ndn::nfd? onFailure(ndn::nfd::ControlResponse(CANONIZE_ERROR_CODE, ^ In file included from ../src/route/fib.cpp:32:0: ../src/route/fib.hpp:166:41: error: ?ControlResponse? in namespace ?ndn::nfd? does not name a type onRegistrationFailure(const ndn::nfd::ControlResponse& response, ^ ../src/route/fib.hpp:173:43: error: ?ControlResponse? in namespace ?ndn::nfd? does not name a type onUnregistrationFailure(const ndn::nfd::ControlResponse& response, ^ ../src/route/fib.hpp:181:40: error: ?ControlResponse? in namespace ?ndn::nfd? does not name a type onSetStrategyFailure(const ndn::nfd::ControlResponse& response, ^ ../src/route/fib.cpp:470:44: error: ?ControlResponse? in namespace ?ndn::nfd? does not name a type Fib::onRegistrationFailure(const ndn::nfd::ControlResponse& response, ^ ../src/route/fib.cpp: In member function ?void nlsr::Fib::onRegistrationFailure(const int&, const string&, const ndn::nfd::ControlParameters&, const string&, uint8_t)?: ../src/route/fib.cpp:476:30: error: request for member ?getText? in ?response?, which is of non-class type ?const int? _LOG_DEBUG(message << ": " << response.getText() << " (code: " << response.getCode() << ")"); ^ ../src/route/fib.cpp:476:66: error: request for member ?getCode? in ?response?, which is of non-class type ?const int? _LOG_DEBUG(message << ": " << response.getText() << " (code: " << response.getCode() << ")"); ^ ../src/route/fib.cpp: At global scope: ../src/route/fib.cpp:491:46: error: ?ControlResponse? in namespace ?ndn::nfd? does not name a type Fib::onUnregistrationFailure(const ndn::nfd::ControlResponse& response, ^ ../src/route/fib.cpp: In member function ?void nlsr::Fib::onUnregistrationFailure(const int&, const string&)?: ../src/route/fib.cpp:494:30: error: request for member ?getText? in ?response?, which is of non-class type ?const int? _LOG_DEBUG(message << ": " << response.getText() << " (code: " << response.getCode() << ")"); ^ ../src/route/fib.cpp:494:66: error: request for member ?getCode? in ?response?, which is of non-class type ?const int? _LOG_DEBUG(message << ": " << response.getText() << " (code: " << response.getCode() << ")"); ^ ../src/route/fib.cpp: At global scope: ../src/route/fib.cpp:506:43: error: ?ControlResponse? in namespace ?ndn::nfd? does not name a type Fib::onSetStrategyFailure(const ndn::nfd::ControlResponse& response, ^ ../src/nlsr.cpp: In member function ?void nlsr::Nlsr::destroyFaces()?: ../src/nlsr.cpp:341:71: error: no matching function for call to ?nlsr::Fib::destroyFace(const string&, std::_Bind_helper&>::type, std::_Bind_helper&>::type)? std::bind(&Nlsr::onDestroyFaceFailure, this, _1)); ^ In file included from ../src/nlsr.hpp:46:0, from ../src/nlsr.cpp:28: ../src/route/fib.hpp:127:3: note: candidate: void nlsr::Fib::destroyFace(const string&, const CommandSucceedCallback&, const CommandFailCallback&) destroyFace(const std::string& faceUri, ^ ../src/route/fib.hpp:127:3: note: no known conversion for argument 3 from ?std::_Bind_helper&>::type {aka std::_Bind(nlsr::Nlsr*, std::_Placeholder<1>)>}? to ?const CommandFailCallback& {aka const std::function&)>&}? ../src/hello-protocol.cpp: In member function ?void nlsr::HelloProtocol::registerPrefixes(const ndn::Name&, const string&, double, const milliseconds&)?: ../src/hello-protocol.cpp:215:62: error: no matching function for call to ?nlsr::Fib::registerPrefix(const ndn::Name&, const string&, double&, const milliseconds&, ndn::nfd::RouteFlags, int, std::_Bind_helper >&), nlsr::HelloProtocol*, const std::_Placeholder<1>&, const ndn::Name&, const boost::chrono::duration >&>::type, std::_Bind_helper&, const ndn::Name&>::type)? this, _1, adjName)); ^ In file included from ../src/nlsr.hpp:46:0, from ../src/hello-protocol.cpp:24: ../src/route/fib.hpp:105:3: note: candidate: void nlsr::Fib::registerPrefix(const ndn::Name&, const string&, uint64_t, const milliseconds&, uint64_t, uint8_t) registerPrefix(const ndn::Name& namePrefix, const std::string& faceUri, ^ ../src/route/fib.hpp:105:3: note: candidate expects 6 arguments, 8 provided ../src/route/fib.hpp:111:3: note: candidate: void nlsr::Fib::registerPrefix(const ndn::Name&, const string&, uint64_t, const milliseconds&, uint64_t, uint8_t, const CommandSucceedCallback&, const CommandFailCallback&) registerPrefix(const ndn::Name& namePrefix, ^ ../src/route/fib.hpp:111:3: note: no known conversion for argument 8 from ?std::_Bind_helper&, const ndn::Name&>::type {aka std::_Bind(nlsr::HelloProtocol*, std::_Placeholder<1>, ndn::Name)>}? to ?const CommandFailCallback& {aka const std::function&)>&}? Waf: Leaving directory `/usr/ndn/NLSR/build' Build failed -> task in 'nlsr-objects' failed (exit status 1): {task 140328346116752: cxx face-controller.cpp -> face-controller.cpp.3.o} ['/usr/lib64/ccache/g++', '-O2', '-g', '-pedantic', '-Wall', '-Wextra', '-Wno-unused-parameter', '-fdiagnostics-color', '-std=c++11', '-I/usr/ndn/NLSR/build', '-I/usr/ndn/NLSR', '-I/usr/ndn/NLSR/build/src', '-I/usr/ndn/NLSR/src', '-I/usr/ndn/NLSR/build/nsync', '-I/usr/ndn/NLSR/nsync', '-I/usr/include', '-I/usr/local/include', '-DNDEBUG', '-DHAVE_NDN_CXX=1', '-DHAVE_LOG4CXX=1', '-DHAVE_PROTOBUF=1', '../src/utility/face-controller.cpp', '-c', '-o', '/usr/ndn/NLSR/build/src/utility/face-controller.cpp.3.o'] -> task in 'nlsr-objects' failed (exit status 1): {task 140328346085264: cxx fib.cpp -> fib.cpp.3.o} ['/usr/lib64/ccache/g++', '-O2', '-g', '-pedantic', '-Wall', '-Wextra', '-Wno-unused-parameter', '-fdiagnostics-color', '-std=c++11', '-I/usr/ndn/NLSR/build', '-I/usr/ndn/NLSR', '-I/usr/ndn/NLSR/build/src', '-I/usr/ndn/NLSR/src', '-I/usr/ndn/NLSR/build/nsync', '-I/usr/ndn/NLSR/nsync', '-I/usr/include', '-I/usr/local/include', '-DNDEBUG', '-DHAVE_NDN_CXX=1', '-DHAVE_LOG4CXX=1', '-DHAVE_PROTOBUF=1', '../src/route/fib.cpp', '-c', '-o', '/usr/ndn/NLSR/build/src/route/fib.cpp.3.o'] -> task in 'nlsr-objects' failed (exit status 1): {task 140328346084432: cxx nlsr.cpp -> nlsr.cpp.3.o} ['/usr/lib64/ccache/g++', '-O2', '-g', '-pedantic', '-Wall', '-Wextra', '-Wno-unused-parameter', '-fdiagnostics-color', '-std=c++11', '-I/usr/ndn/NLSR/build', '-I/usr/ndn/NLSR', '-I/usr/ndn/NLSR/build/src', '-I/usr/ndn/NLSR/src', '-I/usr/ndn/NLSR/build/nsync', '-I/usr/ndn/NLSR/nsync', '-I/usr/include', '-I/usr/local/include', '-DNDEBUG', '-DHAVE_NDN_CXX=1', '-DHAVE_LOG4CXX=1', '-DHAVE_PROTOBUF=1', '../src/nlsr.cpp', '-c', '-o', '/usr/ndn/NLSR/build/src/nlsr.cpp.3.o'] -> task in 'nlsr-objects' failed (exit status 1): {task 140328346083600: cxx hello-protocol.cpp -> hello-protocol.cpp.3.o} ['/usr/lib64/ccache/g++', '-O2', '-g', '-pedantic', '-Wall', '-Wextra', '-Wno-unused-parameter', '-fdiagnostics-color', '-std=c++11', '-I/usr/ndn/NLSR/build', '-I/usr/ndn/NLSR', '-I/usr/ndn/NLSR/build/src', '-I/usr/ndn/NLSR/src', '-I/usr/ndn/NLSR/build/nsync', '-I/usr/ndn/NLSR/nsync', '-I/usr/include', '-I/usr/local/include', '-DNDEBUG', '-DHAVE_NDN_CXX=1', '-DHAVE_LOG4CXX=1', '-DHAVE_PROTOBUF=1', '../src/hello-protocol.cpp', '-c', '-o', '/usr/ndn/NLSR/build/src/hello-protocol.cpp.3.o'] Best Regards, Alexander Ni -------------- next part -------------- An HTML attachment was scrubbed... URL: From agawande at memphis.edu Wed Aug 31 07:30:05 2016 From: agawande at memphis.edu (Ashlesh Gawande (agawande)) Date: Wed, 31 Aug 2016 14:30:05 +0000 Subject: [Ndn-interest] NLSR build error In-Reply-To: References: Message-ID: Whats the version of ndn-cxx and NFD? Can you try updating ndn-cxx and NFD (install them from source) and then compile NLSR again? Ashlesh ________________________________ From: Ndn-interest on behalf of Alexander Ni Sent: Tuesday, August 30, 2016 9:10:01 PM To: ndn-interest at lists.cs.ucla.edu Subject: [Ndn-interest] NLSR build error Hello, I tried to build NLSR (0.3.0-6-g63bd034), but get next error. [root at Producer1 NLSR]# ./waf configure Setting top to : /usr/ndn/NLSR Setting out to : /usr/ndn/NLSR/build Checking for 'g++' (C++ compiler) : /usr/lib64/ccache/g++ Checking supported CXXFLAGS : -std=c++11 Checking supported CXXFLAGS : -O2 -g -pedantic -Wall -Wextra -Wno-unused-parameter -fdiagnostics-color Checking for program 'doxygen' : /usr/bin/doxygen Checking for program 'tar' : /usr/bin/tar Checking for program 'sphinx-build' : /usr/bin/sphinx-build Checking for program 'pkg-config' : /usr/bin/pkg-config Checking for 'libndn-cxx' : yes Checking for 'liblog4cxx' : yes Checking for OpenSSL library : yes Checking boost includes : 1.58.0 Checking boost libs : ok Checking for boost linkage : ok Checking for 'protobuf' : yes Checking for program 'protoc' : /usr/bin/protoc 'configure' finished successfully (7.053s) [root at Producer1 NLSR]# ./waf Waf: Entering directory `/usr/ndn/NLSR/build' [ 1/57] Compiling src/version.hpp.in [ 2/57] Processing nsync/sync-state.proto [ 3/57] Processing sphinx_build [man]: docs/manpages/nlsr.conf.rst docs/manpages/nlsr.rst docs/manpages/nlsrc.rst docs/conf.py -> build/docs/manpages/nlsr.1 build/docs/manpages/nlsr.conf.5 build/docs/manpages/nlsrc.1 [ 4/57] Compiling src/main.cpp [ 5/57] Compiling src/tlv/coordinate-lsa.cpp [ 6/57] Compiling src/tlv/adjacency.cpp [ 7/57] Compiling src/tlv/adjacency-lsa.cpp [ 8/57] Compiling src/sequencing-manager.cpp [ 9/57] Compiling src/route/routing-table-calculator.cpp [11/57] Compiling src/route/name-prefix-table-entry.cpp [11/57] Compiling src/route/map.cpp [12/57] Compiling src/publisher/lsdb-status-publisher.cpp [13/57] Compiling src/nlsr.cpp [14/57] Compiling src/logger.cpp [15/57] Compiling src/conf-file-processor.cpp [16/57] Compiling src/adjacency-list.cpp [17/57] Compiling nsync/sync-logging.cc [18/57] Compiling nsync/sync-full-leaf.cc [19/57] Compiling nsync/sync-diff-state.cc [20/57] Compiling nsync/sync-diff-leaf.cc [21/57] Compiling src/conf-parameter.cpp [22/57] Compiling src/lsa.cpp [23/57] Compiling src/nlsr-runner.cpp [24/57] Compiling src/route/fib-entry.cpp [25/57] Compiling src/route/name-prefix-table.cpp [26/57] Compiling src/route/routing-table.cpp [27/57] Compiling src/tlv/lsa-info.cpp [28/57] Compiling src/tlv/name-lsa.cpp [29/57] Compiling tools/nlsrc.cpp [30/57] Compiling src/tlv/lsdb-status.cpp [31/57] Compiling src/publisher/lsdb-dataset-interest-handler.cpp [32/57] Compiling src/publisher/lsa-publisher.cpp [33/57] Compiling src/name-prefix-list.cpp [34/57] Compiling src/communication/sync-logic-handler.cpp [35/57] Compiling nsync/sync-std-name-info.cc [36/57] Compiling nsync/sync-name-info.cc [37/57] Compiling nsync/sync-logic.cc [38/57] Compiling nsync/sync-full-state.cc [39/57] Compiling nsync/sync-digest.cc [40/57] Compiling nsync/sync-interest-table.cc [41/57] Compiling nsync/sync-leaf.cc [42/57] Compiling nsync/sync-seq-no.cc [43/57] Compiling nsync/sync-socket.cc [45/57] Compiling build/nsync/sync-state.pb.cc [44/57] Compiling nsync/sync-state.cc [46/57] Compiling src/adjacent.cpp [47/57] Compiling src/hello-protocol.cpp [48/57] Compiling src/lsdb.cpp [49/57] Compiling src/route/face-map.cpp [50/57] Compiling src/route/fib.cpp [51/57] Compiling src/route/nexthop-list.cpp [52/57] Compiling src/route/nexthop.cpp [53/57] Compiling src/update/prefix-update-commands.cpp [54/57] Compiling src/update/prefix-update-processor.cpp [55/57] Compiling src/utility/face-controller.cpp ../src/utility/face-controller.cpp: In member function ?void nlsr::util::FaceController::onCanonizeFailure(const string&, const CommandSuccessCallback&, const CommandFailureCallback&, const ndn::util::FaceUri&)?: ../src/utility/face-controller.cpp:79:13: error: ?ControlResponse? is not a member of ?ndn::nfd? onFailure(ndn::nfd::ControlResponse(CANONIZE_ERROR_CODE, ^ In file included from ../src/route/fib.cpp:32:0: ../src/route/fib.hpp:166:41: error: ?ControlResponse? in namespace ?ndn::nfd? does not name a type onRegistrationFailure(const ndn::nfd::ControlResponse& response, ^ ../src/route/fib.hpp:173:43: error: ?ControlResponse? in namespace ?ndn::nfd? does not name a type onUnregistrationFailure(const ndn::nfd::ControlResponse& response, ^ ../src/route/fib.hpp:181:40: error: ?ControlResponse? in namespace ?ndn::nfd? does not name a type onSetStrategyFailure(const ndn::nfd::ControlResponse& response, ^ ../src/route/fib.cpp:470:44: error: ?ControlResponse? in namespace ?ndn::nfd? does not name a type Fib::onRegistrationFailure(const ndn::nfd::ControlResponse& response, ^ ../src/route/fib.cpp: In member function ?void nlsr::Fib::onRegistrationFailure(const int&, const string&, const ndn::nfd::ControlParameters&, const string&, uint8_t)?: ../src/route/fib.cpp:476:30: error: request for member ?getText? in ?response?, which is of non-class type ?const int? _LOG_DEBUG(message << ": " << response.getText() << " (code: " << response.getCode() << ")"); ^ ../src/route/fib.cpp:476:66: error: request for member ?getCode? in ?response?, which is of non-class type ?const int? _LOG_DEBUG(message << ": " << response.getText() << " (code: " << response.getCode() << ")"); ^ ../src/route/fib.cpp: At global scope: ../src/route/fib.cpp:491:46: error: ?ControlResponse? in namespace ?ndn::nfd? does not name a type Fib::onUnregistrationFailure(const ndn::nfd::ControlResponse& response, ^ ../src/route/fib.cpp: In member function ?void nlsr::Fib::onUnregistrationFailure(const int&, const string&)?: ../src/route/fib.cpp:494:30: error: request for member ?getText? in ?response?, which is of non-class type ?const int? _LOG_DEBUG(message << ": " << response.getText() << " (code: " << response.getCode() << ")"); ^ ../src/route/fib.cpp:494:66: error: request for member ?getCode? in ?response?, which is of non-class type ?const int? _LOG_DEBUG(message << ": " << response.getText() << " (code: " << response.getCode() << ")"); ^ ../src/route/fib.cpp: At global scope: ../src/route/fib.cpp:506:43: error: ?ControlResponse? in namespace ?ndn::nfd? does not name a type Fib::onSetStrategyFailure(const ndn::nfd::ControlResponse& response, ^ ../src/nlsr.cpp: In member function ?void nlsr::Nlsr::destroyFaces()?: ../src/nlsr.cpp:341:71: error: no matching function for call to ?nlsr::Fib::destroyFace(const string&, std::_Bind_helper&>::type, std::_Bind_helper&>::type)? std::bind(&Nlsr::onDestroyFaceFailure, this, _1)); ^ In file included from ../src/nlsr.hpp:46:0, from ../src/nlsr.cpp:28: ../src/route/fib.hpp:127:3: note: candidate: void nlsr::Fib::destroyFace(const string&, const CommandSucceedCallback&, const CommandFailCallback&) destroyFace(const std::string& faceUri, ^ ../src/route/fib.hpp:127:3: note: no known conversion for argument 3 from ?std::_Bind_helper&>::type {aka std::_Bind(nlsr::Nlsr*, std::_Placeholder<1>)>}? to ?const CommandFailCallback& {aka const std::function&)>&}? ../src/hello-protocol.cpp: In member function ?void nlsr::HelloProtocol::registerPrefixes(const ndn::Name&, const string&, double, const milliseconds&)?: ../src/hello-protocol.cpp:215:62: error: no matching function for call to ?nlsr::Fib::registerPrefix(const ndn::Name&, const string&, double&, const milliseconds&, ndn::nfd::RouteFlags, int, std::_Bind_helper >&), nlsr::HelloProtocol*, const std::_Placeholder<1>&, const ndn::Name&, const boost::chrono::duration >&>::type, std::_Bind_helper&, const ndn::Name&>::type)? this, _1, adjName)); ^ In file included from ../src/nlsr.hpp:46:0, from ../src/hello-protocol.cpp:24: ../src/route/fib.hpp:105:3: note: candidate: void nlsr::Fib::registerPrefix(const ndn::Name&, const string&, uint64_t, const milliseconds&, uint64_t, uint8_t) registerPrefix(const ndn::Name& namePrefix, const std::string& faceUri, ^ ../src/route/fib.hpp:105:3: note: candidate expects 6 arguments, 8 provided ../src/route/fib.hpp:111:3: note: candidate: void nlsr::Fib::registerPrefix(const ndn::Name&, const string&, uint64_t, const milliseconds&, uint64_t, uint8_t, const CommandSucceedCallback&, const CommandFailCallback&) registerPrefix(const ndn::Name& namePrefix, ^ ../src/route/fib.hpp:111:3: note: no known conversion for argument 8 from ?std::_Bind_helper&, const ndn::Name&>::type {aka std::_Bind(nlsr::HelloProtocol*, std::_Placeholder<1>, ndn::Name)>}? to ?const CommandFailCallback& {aka const std::function&)>&}? Waf: Leaving directory `/usr/ndn/NLSR/build' Build failed -> task in 'nlsr-objects' failed (exit status 1): {task 140328346116752: cxx face-controller.cpp -> face-controller.cpp.3.o} ['/usr/lib64/ccache/g++', '-O2', '-g', '-pedantic', '-Wall', '-Wextra', '-Wno-unused-parameter', '-fdiagnostics-color', '-std=c++11', '-I/usr/ndn/NLSR/build', '-I/usr/ndn/NLSR', '-I/usr/ndn/NLSR/build/src', '-I/usr/ndn/NLSR/src', '-I/usr/ndn/NLSR/build/nsync', '-I/usr/ndn/NLSR/nsync', '-I/usr/include', '-I/usr/local/include', '-DNDEBUG', '-DHAVE_NDN_CXX=1', '-DHAVE_LOG4CXX=1', '-DHAVE_PROTOBUF=1', '../src/utility/face-controller.cpp', '-c', '-o', '/usr/ndn/NLSR/build/src/utility/face-controller.cpp.3.o'] -> task in 'nlsr-objects' failed (exit status 1): {task 140328346085264: cxx fib.cpp -> fib.cpp.3.o} ['/usr/lib64/ccache/g++', '-O2', '-g', '-pedantic', '-Wall', '-Wextra', '-Wno-unused-parameter', '-fdiagnostics-color', '-std=c++11', '-I/usr/ndn/NLSR/build', '-I/usr/ndn/NLSR', '-I/usr/ndn/NLSR/build/src', '-I/usr/ndn/NLSR/src', '-I/usr/ndn/NLSR/build/nsync', '-I/usr/ndn/NLSR/nsync', '-I/usr/include', '-I/usr/local/include', '-DNDEBUG', '-DHAVE_NDN_CXX=1', '-DHAVE_LOG4CXX=1', '-DHAVE_PROTOBUF=1', '../src/route/fib.cpp', '-c', '-o', '/usr/ndn/NLSR/build/src/route/fib.cpp.3.o'] -> task in 'nlsr-objects' failed (exit status 1): {task 140328346084432: cxx nlsr.cpp -> nlsr.cpp.3.o} ['/usr/lib64/ccache/g++', '-O2', '-g', '-pedantic', '-Wall', '-Wextra', '-Wno-unused-parameter', '-fdiagnostics-color', '-std=c++11', '-I/usr/ndn/NLSR/build', '-I/usr/ndn/NLSR', '-I/usr/ndn/NLSR/build/src', '-I/usr/ndn/NLSR/src', '-I/usr/ndn/NLSR/build/nsync', '-I/usr/ndn/NLSR/nsync', '-I/usr/include', '-I/usr/local/include', '-DNDEBUG', '-DHAVE_NDN_CXX=1', '-DHAVE_LOG4CXX=1', '-DHAVE_PROTOBUF=1', '../src/nlsr.cpp', '-c', '-o', '/usr/ndn/NLSR/build/src/nlsr.cpp.3.o'] -> task in 'nlsr-objects' failed (exit status 1): {task 140328346083600: cxx hello-protocol.cpp -> hello-protocol.cpp.3.o} ['/usr/lib64/ccache/g++', '-O2', '-g', '-pedantic', '-Wall', '-Wextra', '-Wno-unused-parameter', '-fdiagnostics-color', '-std=c++11', '-I/usr/ndn/NLSR/build', '-I/usr/ndn/NLSR', '-I/usr/ndn/NLSR/build/src', '-I/usr/ndn/NLSR/src', '-I/usr/ndn/NLSR/build/nsync', '-I/usr/ndn/NLSR/nsync', '-I/usr/include', '-I/usr/local/include', '-DNDEBUG', '-DHAVE_NDN_CXX=1', '-DHAVE_LOG4CXX=1', '-DHAVE_PROTOBUF=1', '../src/hello-protocol.cpp', '-c', '-o', '/usr/ndn/NLSR/build/src/hello-protocol.cpp.3.o'] Best Regards, Alexander Ni -------------- next part -------------- An HTML attachment was scrubbed... URL: