From nfd-call-notification at mail1.yoursunny.com Tue Aug 2 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 2 Aug 2016 07:00:02 -0700 Subject: [Nfd-dev] NFD call 20160802 Message-ID: <201608021400.u72E02QD016365@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From mhasabet at gmail.com Tue Aug 2 09:24:01 2016 From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet) Date: Tue, 2 Aug 2016 20:54:01 +0430 Subject: [Nfd-dev] OnContentSoreMiss pipline In-Reply-To: References: Message-ID: Junxiao, Why is it moved from pipelines to strategy? What is the reason to have Link objects handled in local strategies instead of global pipelines? Thanks, Sabet ????? ????? ?? ???? On Tue, Jul 26, 2016 at 11:18 PM, Junxiao Shi wrote: > Hi Sabet > > I'm doing refactoring these days, and devguide isn't updated yet. > In short, FIB lookup, including handling Link objects, is in > Forwarder::lookupFib method but it's invoked by the strategy instead of > pipelines. > See https://redmine.named-data.net/issues/3664#note-4 > > Yours, Junxiao > > On Mon, Jul 25, 2016 at 1:39 AM, Muhammad Hosain Abdollahi Sabet < > mhasabet at gmail.com> wrote: > >> ?Hi there, >> According to developer guid?e, section 4.2.3 ContentStore Miss Pipeline >> >> [image: Inline image 1] >> >> there should be some checkings on if incoming Interest has Link object, >> so to decide on how to forward the Interest. But in daemon/fw/forwarder.cpp >> there is no such checks in Forwarder::onContentStoreMiss: >> >> void >> Forwarder::onContentStoreMiss(const Face& inFace, >> shared_ptr pitEntry, >> const Interest& interest) >> { >> NFD_LOG_DEBUG("onContentStoreMiss interest=" << interest.getName()); >> >> shared_ptr face = >> const_pointer_cast(inFace.shared_from_this()); >> // insert InRecord >> pitEntry->insertOrUpdateInRecord(face, interest); >> >> // set PIT unsatisfy timer >> this->setUnsatisfyTimer(pitEntry); >> >> // FIB lookup >> shared_ptr fibEntry = >> m_fib.findLongestPrefixMatch(*pitEntry); >> >> // dispatch to strategy >> this->dispatchToStrategy(pitEntry, >> bind(&Strategy::afterReceiveInterest, _1, >> cref(inFace), cref(interest), >> fibEntry, pitEntry)); >> } >> >> Am I missing something? >> >> Actually I was wondering why setting Link object doesn't affect >> forwarding decisions in ndnSIM. I guess this the reason, right? >> >> Thanks, >> Sabet >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 39565 bytes Desc: not available URL: From shijunxiao at email.arizona.edu Tue Aug 2 09:33:59 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 2 Aug 2016 09:33:59 -0700 Subject: [Nfd-dev] OnContentSoreMiss pipline In-Reply-To: References: Message-ID: Hi Sabet The benefits of Forwarder::lookupFib is described in https://redmine.named-data.net/issues/3164#note-8 Yours, Junxiao On Aug 2, 2016 9:24 AM, "Muhammad Hosain Abdollahi Sabet" < mhasabet at gmail.com> wrote: > > Junxiao, > > Why is it moved from pipelines to strategy? What is the reason to have Link objects handled in local strategies instead of global pipelines? > > Thanks, > Sabet -------------- next part -------------- An HTML attachment was scrubbed... URL: From agawande at memphis.edu Tue Aug 2 14:19:39 2016 From: agawande at memphis.edu (Ashlesh Gawande (agawande)) Date: Tue, 2 Aug 2016 21:19:39 +0000 Subject: [Nfd-dev] Help needed with debugging duplicate Nonce In-Reply-To: <0521BE8D-DA8C-4CC9-B824-67F49E53F251@memphis.edu> References: <57716ff0.0617620a.1b687.2b5e@mx.google.com> <5776929d.aa41420a.8c48f.05cf@mx.google.com> <7D17546E-AA1D-4D1C-947A-6DC00216A66F@memphis.edu> <5784442f.4e42620a.d5f8c.108c@mx.google.com> <39FB5146-3304-46F0-9502-D465E950A8E0@memphis.edu> <57852fc2.8612620a.2501d.6abe@mx.google.com> <46489E6A-AAF8-4E07-8D91-7EA4B9D1F1BF@memphis.edu> <57864826.8148620a.c50c1.40ff@mx.google.com>, <0521BE8D-DA8C-4CC9-B824-67F49E53F251@memphis.edu> Message-ID: Hi Junxiao I am trying to test multicast v2 (https://gerrit.named-data.net/#/c/3013/1) before I push the code review ready patches to resolve our issue. (Issue 3176 and issue 2602). Number of duplicate NACKs have increased. For 3 node topology: NACKs increase from 58 (v1) to 132 (v2) for 30 second convergence time. For a 58 node topology: In multicast v2, NACKs increase from 913073 (v1) to 5624592(v2) and topology does not converge in 30 seconds as it does with v1 (most of them are duplicate NACK). The topology does converge even in 3 minutes. The increased NACK processing seems to take the blame for increased convergence time. I have attached the 3 node topology test with ndnump and logs. Maybe I am doing something wrong in the patch. Could you please take a look? Thanks Ashlesh ________________________________ From: Lan Wang (lanwang) Sent: Wednesday, July 13, 2016 2:37:19 PM To: Junxiao Shi Cc: Ashlesh Gawande (agawande); nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce Junxiao, Ashlesh can work on these two issues if no one else volunteers. Lan On Jul 13, 2016, at 8:54 AM, Junxiao Shi > wrote: Hi Lan Multicast strategy v1 does not have any of the desired behaviors. It neither allows consumer retransmission, nor processes incoming Nacks. ChronoSync developers could pick up the work on multicast strategy: Feature #2063: permit consumer retransmission Feature #3176: Nack processing Yours, Junxiao From: Lan Wang (lanwang) Sent: Wednesday, July 13, 2016 06:46 To: Junxiao Shi Cc: Ashlesh Gawande (agawande); nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce Junxiao, On Jul 12, 2016, at 12:58 PM, Junxiao Shi > wrote: Hi Lan Look at this topology: A---B \ / C Assume every link has the same delay, and the processing delay at each node is zero. When C sends the same Interest to both A and B, A and B would forward the Interest to each other, and get Nack-Duplicate from each other. Per ChronoSync protocol, the applications on A and B should express Interests with the same name. Since A and B are symmetric, let?s look at A. There could be three different timings: TIMING0 AppA expresses the Interest before C?s Interest arrives at A. If we relabel A->C B->A C->B, it becomes either TIMING1 or TIMING2. TIMING1 AppA expresses the Interest after C?s Interest has been forwarded to B, but before B responds Nack-Duplicate. The duration between A forwarding C?s Interest to B and A receiving Nack-Duplicate from B is most likely shorter than the suppression interval, so appA?s Interest would be suppressed. When Nack-Duplicate against C?s Interest arrives from B, strategy at A should send appA?s Interest to B. TIMING2 AppA expresses the Interest after B responds Nack-Duplicate. When Nack-Duplicate against C?s Interest arrives from B, strategy at A should not return the Nack to C, because appA is another upstream which has not Nacked. When appA expresses the Interest, strategy at A should not suppress this Interest, because the sole pending upstream (appA) is now a downstream. The strategy should forward the Interest to both B and C. When the strategy behaves as what I describe above, everyone should be getting Data. Question is whether the multicast strategy ChronoSync uses has the above behavior or not (e.g., "When Nack-Duplicate against C?s Interest arrives from B, strategy at A should send appA?s Interest to B.?). I doubt it is the case based on the following. Below is from your earlier email: ============== below is from Junxiao?s email ======== >From A?s point of view, face261 is the local app, face262 is B, face263 is C. Incoming+outgoing Interests, and PIT entry contents are as follows: 52.39 from=C=4168 to=app PIT in=[C=4168 at 52.39] out=[app at 52.39] 52.72 from=B=6605 PIT in=[C=4168 at 52.39,B=6605 at 52.72] out=[app at 52.39] 52.74 from=app=7385 to=B,C PIT in=[C=4168 at 52.39,B=6605 at 52.72,app=7385 at 52.74] out=[app at 52.39,B at 52.74,C at 52.74] 56.39 PIT in=[B=6605 at 52.72,app=7385 at 52.74]+expired[C=4168 at 52.39] out=[B at 52.74,C at 52.74]+expired[app at 52.39] 56.72 PIT in=[app=7385 at 52.74]+expired[C=4168 at 52.39,B=6605 at 52.72] out=[B at 52.74,C at 52.74]+expired[app at 52.39] 56.74 Interest unsatisfied, PIT erased 56.89 from=C=0641 to=app PIT in=[C=0641 at 56.89] out=[app at 56.89] 56.90 from=app=7567 to=B,C PIT in=[C=0641 at 56.89,app=7567 at 56.90] out=[app at 56.89,B at 56.90,C at 56.90] 57.06 from=B=1547 PIT in=[C=0641 at 56.89,app=7567 at 56.90,B=1547 at 57.06] out=[app at 56.89,B at 56.90,C at 56.90] 60.89 PIT in=[app=7567 at 56.90,B=1547 at 57.06]+expired[C=0641 at 56.89] out=[B at 56.90,C at 56.90]+expired[app at 56.89] 60.90 PIT in=[B=1547 at 57.06]+expired[C=0641 at 56.89,app=7567 at 56.90] out=[]+expired[app at 56.89,B at 56.90,C at 56.90] 61.05 from=C=6600 to=app,B,C PIT in=[B=1547 at 57.06,C=6600 at 61.05]+expired[app=7567 at 56.90] out=[app at 61.05,B at 61.05,C at 61.05] Time is represented with last two digits of integral part and first two digits of fractional part. Nonce is represented with last four digits. PIT in-record is represented as =@