From lanwang at memphis.edu Sun Mar 1 08:21:43 2015 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Sun, 1 Mar 2015 16:21:43 +0000 Subject: [Nfd-dev] strange results In-Reply-To: References: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu> Message-ID: <6EBCEC36-9AD0-4996-A147-2CEE495EFD50@memphis.edu> Junxiao, Thank you very much for the explanation and finding the root cause of the problem. It is causing wild oscillations in the NDNPing delays (switches back and forth between the best path and worse paths back and forth) since the measurements that the strategy is based on were wrong. I hope this could be fixed as soon as possible since we need the correct results for our paper. Conceptually the solution requires duplicate suppression (at least for some time) after a PIT entry has been satisfied. I thought the DeadNonceList was designed for this purpose. If you check the DeadNonceList before the PIT entry, then you'll detect the duplicate easily. However, if you do not want to check the DeadNonceList first (for whatever reason I don't understand), the current Interest processing flow has a couple issues if I understand correctly: 1. the current logic assume that there's no need to record a dead nonce if the PIT entry is satisfied. Obviously the example shows that although there's no danger of interest looping, there can be other dangers, e.g., the wrong measurements shown in the example. 2. the in-record and out-record were deleted when the PIT entry is satisfied. This causes problems since the current logic checks these things before checking the DeadNonceList. So to fix the above, the code needs to (a) record the dead nonce regardless of whether the PIT entry is satisfied and also (b) check the DeadNonceList even after a PIT entry is satisfied. Thanks a lot. Lan On Mar 1, 2015, at 12:53 AM, Junxiao Shi > wrote: Hi Lan Trace of CSU node has: 1. 5159.119 interestFrom UCLA 2. 5159.140 interestTo MEMPHIS 3. 5159.179 interestFrom UMICH 4. 5159.245887 dataFrom MEMPHIS 5. 5159.262 dataTo UCLA 6. 5159.345243 interestFrom UIUC 7. 5159.359 dataTo UIUC Here's what happens: 5159.119 upon receiving packet 1, new PIT entry is created with in-record of UCLA face 5159.140 Interest is forwarded to MEMPHIS as packet 2; out-record of MEMPHIS face is created 5159.179 packet 3 arrives, but it's suppressed due to duplicate Nonce in PIT entry 5159.245887 packet 4 arrives and satisfies the PIT entry; straggler timer is set to erase the PIT entry at 5159.345887 5159.262 Data is returned to UCLA as packet 5, but not UMICH because packet 2 was suppressed; in-records and out-record of MEMPHIS face are deleted; Nonce is not inserted to DeadNonceList because there's no risk of looping (see spec for exact condition) 5159.345243 packet 6 arrives and cancels the straggler timer; it hits ContentStore and is not forwarded 5159.345887 PIT entry won't be deleted now because straggler timer was cancelled by packet 6 5159.359 Data from ContentStore is returned to UIUC as packet 7 The problematic step is: "in-records and out-record of MEMPHIS face are deleted". Originally, PIT entry has a NonceList data structure to detect duplicate Nonces. Deleting in-records won't affect duplicate Nonce detection. When DeadNonceList is introduced, the PIT NonceList is dropped, and PIT entry would report a duplicate Nonce only if any in-record or out-record contains a duplicate Nonce. This assumes that in-records are retained before straggler timer expires, but forwarding pipelines are not able to fulfill this assumption. This issue is tracked as Bug 2592. Root cause is found, but I need to think about the design. Yours, Junxiao On Sat, Feb 28, 2015 at 11:02 PM, Lan Wang (lanwang) > wrote: csu/dump.0csu:1425075159.119112 From: 1.0.0.42, To: 1.0.0.41, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.4csu:1425075159.140391 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.6csu:1425075159.179620 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.4csu:1425075159.245887 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 csu/dump.0csu:1425075159.262268 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 csu/dump.5csu:1425075159.345243 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.5csu:1425075159.359534 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 Seems that CSU was not doing duplicate Interest suppression correctly. The Interest from UIUC to CSU received at time 1425075159.345243 should have been dropped because it's a duplicate of the earlier Interest from UCLA to CSU received at time 1425075159.119112, but it was not and instead brought data back. The time difference between the two Interests is 226ms. I'm not sure how the duplicate suppression is implemented. Someone more familiar with the forwarding pipeline please help explain the above trace. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oran at cisco.com Sun Mar 1 08:49:12 2015 From: oran at cisco.com (Dave Oran (oran)) Date: Sun, 1 Mar 2015 16:49:12 +0000 Subject: [Nfd-dev] strange results In-Reply-To: <6EBCEC36-9AD0-4996-A147-2CEE495EFD50@memphis.edu> References: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu> <6EBCEC36-9AD0-4996-A147-2CEE495EFD50@memphis.edu> Message-ID: <672D12F0-0FB9-4646-A380-A147B89262CE@cisco.com> Given that any Interest arriving after a PIT entry has been satisfied (or timed out) has the hazard of re-creating the PIT and getting processed when it shouldn?t, the ?DeadNonceList? entries have to persist for at least the MPL (maximum packet lifetime) of the network. In the IP world, various pathologies can cause this period to be very long; on the order of minutes. What?s the proposed DeadNonce timer for NFD? What?s the worst case memory pressure? - seems like it could be gigantic for a high-speed router. Are there replay attacks that can cause the DeadNonceList to grow without bound? Some folks have argued this isn?t an implementation question so much as an architecture question around the use of nonces for loop detection in the first place. DaveO. > On Mar 1, 2015, at 11:21 AM, Lan Wang (lanwang) wrote: > > Junxiao, > > Thank you very much for the explanation and finding the root cause of the problem. It is causing wild oscillations in the NDNPing delays (switches back and forth between the best path and worse paths back and forth) since the measurements that the strategy is based on were wrong. I hope this could be fixed as soon as possible since we need the correct results for our paper. > > > Conceptually the solution requires duplicate suppression (at least for some time) after a PIT entry has been satisfied. I thought the DeadNonceList was designed for this purpose. If you check the DeadNonceList before the PIT entry, then you'll detect the duplicate easily. > > However, if you do not want to check the DeadNonceList first (for whatever reason I don't understand), the current Interest processing flow has a couple issues if I understand correctly: > > 1. the current logic assume that there's no need to record a dead nonce if the PIT entry is satisfied. Obviously the example shows that although there's no danger of interest looping, there can be other dangers, e.g., the wrong measurements shown in the example. > > 2. the in-record and out-record were deleted when the PIT entry is satisfied. This causes problems since the current logic checks these things before checking the DeadNonceList. > > So to fix the above, the code needs to (a) record the dead nonce regardless of whether the PIT entry is satisfied and also (b) check the DeadNonceList even after a PIT entry is satisfied. > > Thanks a lot. > > Lan > > On Mar 1, 2015, at 12:53 AM, Junxiao Shi wrote: > >> Hi Lan >> >> Trace of CSU node has: >> ? 5159.119 interestFrom UCLA >> ? 5159.140 interestTo MEMPHIS >> ? 5159.179 interestFrom UMICH >> ? 5159.245887 dataFrom MEMPHIS >> ? 5159.262 dataTo UCLA >> ? 5159.345243 interestFrom UIUC >> ? 5159.359 dataTo UIUC >> >> Here's what happens: >> >> 5159.119 upon receiving packet 1, new PIT entry is created with in-record of UCLA face >> 5159.140 Interest is forwarded to MEMPHIS as packet 2; out-record of MEMPHIS face is created >> 5159.179 packet 3 arrives, but it's suppressed due to duplicate Nonce in PIT entry >> 5159.245887 packet 4 arrives and satisfies the PIT entry; straggler timer is set to erase the PIT entry at 5159.345887 >> 5159.262 Data is returned to UCLA as packet 5, but not UMICH because packet 2 was suppressed; in-records and out-record of MEMPHIS face are deleted; Nonce is not inserted to DeadNonceList because there's no risk of looping (see spec for exact condition) >> 5159.345243 packet 6 arrives and cancels the straggler timer; it hits ContentStore and is not forwarded >> 5159.345887 PIT entry won't be deleted now because straggler timer was cancelled by packet 6 >> 5159.359 Data from ContentStore is returned to UIUC as packet 7 >> >> >> The problematic step is: "in-records and out-record of MEMPHIS face are deleted". >> Originally, PIT entry has a NonceList data structure to detect duplicate Nonces. Deleting in-records won't affect duplicate Nonce detection. >> When DeadNonceList is introduced, the PIT NonceList is dropped, and PIT entry would report a duplicate Nonce only if any in-record or out-record contains a duplicate Nonce. >> This assumes that in-records are retained before straggler timer expires, but forwarding pipelines are not able to fulfill this assumption. >> >> This issue is tracked as Bug 2592. >> Root cause is found, but I need to think about the design. >> >> Yours, Junxiao >> >> On Sat, Feb 28, 2015 at 11:02 PM, Lan Wang (lanwang) wrote: >> csu/dump.0csu:1425075159.119112 From: 1.0.0.42, To: 1.0.0.41, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> csu/dump.4csu:1425075159.140391 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> csu/dump.6csu:1425075159.179620 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> csu/dump.4csu:1425075159.245887 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> csu/dump.0csu:1425075159.262268 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> csu/dump.5csu:1425075159.345243 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> csu/dump.5csu:1425075159.359534 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> >> Seems that CSU was not doing duplicate Interest suppression correctly. The Interest from UIUC to CSU received at time 1425075159.345243 should have been dropped because it's a duplicate of the earlier Interest from UCLA to CSU received at time 1425075159.119112, but it was not and instead brought data back. The time difference between the two Interests is 226ms. I'm not sure how the duplicate suppression is implemented. Someone more familiar with the forwarding pipeline please help explain the above trace. Thanks. > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From lixia at CS.UCLA.EDU Sun Mar 1 09:42:03 2015 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Sun, 1 Mar 2015 09:42:03 -0800 Subject: [Nfd-dev] strange results In-Reply-To: <4A7C4BA3-B5C3-456A-B1CA-24891D28996A@memphis.edu> References: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu> <4A7C4BA3-B5C3-456A-B1CA-24891D28996A@memphis.edu> Message-ID: <845F7EA7-B17A-4819-9816-E231124EA103@cs.ucla.edu> > On Feb 28, 2015, at 10:28 PM, Lan Wang (lanwang) wrote: > > In case you are wondering why this is a problem. Look at the UMich node. It first forwarded the Interest to CSU, but that one didn't bring back the data (perhaps it was correctly suppressed). However, its second Interest to UIUC did bring back data (which should not have happened). So from that point on, it's going to use UIUC instead of the better path CSU to forward Interest to CAIDA. We did observe this problem. > > Lan Lan, I do not know exactly how your ping measurement works, but from the above description, it seems that, - for each ping interest with nonce=N, for any node to get duplicates, there ought to be a branching point along its (the interest?s) path - UMich is not this point, since CSU already detected the interest from UMich as duplicate (So CSU node has seen interest(N) from some other neighbor) - this branching point (could be the origin consumer?) should be able to tell a good path from a worse path, right? Lixia > On Mar 1, 2015, at 12:02 AM, Lan Wang (lanwang) > wrote: > >> Hi all, >> >> We're seeing strange results from our latest experiments. Below is an ndndump trace of one ndnping packet from UCLA to CAIDA. We ran the experiments using mini-ndn. I'm also attaching a png file that shows where the Interests and Data packets were forwarded (white is the original transmission of the Interest, yellow and blue indicate retransmissions of this Interest with the same nonce by different routers). >> >> [Lans-MacBook-Air:test-ucla-ping-cpu-alloc-withNLSRlog-timing/ls/faces-2] lanwang1% grep "/ndn/edu/caida/ping/251436634" */dump* | sort -t ":" -k 2 | more >> ucla/dump.0ucla:1425075159.119036 From: 1.0.0.42, To: 1.0.0.41, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> csu/dump.0csu:1425075159.119112 From: 1.0.0.42, To: 1.0.0.41, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> csu/dump.4csu:1425075159.140391 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> memphis/dump.1memphis:1425075159.140488 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> ucla/dump.1ucla:1425075159.164108 From: 1.0.0.73, To: 1.0.0.74, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> umich/dump.0umich:1425075159.164185 From: 1.0.0.73, To: 1.0.0.74, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> umich/dump.2umich:1425075159.179542 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> csu/dump.6csu:1425075159.179620 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> memphis/dump.2memphis:1425075159.181041 From: 1.0.0.18, To: 1.0.0.17, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> caida/dump.4caida:1425075159.181138 From: 1.0.0.18, To: 1.0.0.17, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> caida/dump.4caida:1425075159.224372 From: 1.0.0.17, To: 1.0.0.18, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> memphis/dump.2memphis:1425075159.224444 From: 1.0.0.17, To: 1.0.0.18, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> memphis/dump.1memphis:1425075159.245821 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> csu/dump.4csu:1425075159.245887 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> csu/dump.0csu:1425075159.262268 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> ucla/dump.0ucla:1425075159.262344 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> umich/dump.4umich:1425075159.330700 From: 1.0.0.82, To: 1.0.0.81, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> uiuc/dump.2uiuc:1425075159.330771 From: 1.0.0.82, To: 1.0.0.81, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> uiuc/dump.0uiuc:1425075159.345166 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> csu/dump.5csu:1425075159.345243 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 >> csu/dump.5csu:1425075159.359534 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> uiuc/dump.0uiuc:1425075159.359617 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> uiuc/dump.2uiuc:1425075159.365972 From: 1.0.0.81, To: 1.0.0.82, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> umich/dump.4umich:1425075159.366036 From: 1.0.0.81, To: 1.0.0.82, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> umich/dump.0umich:1425075159.399394 From: 1.0.0.74, To: 1.0.0.73, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> ucla/dump.1ucla:1425075159.399522 From: 1.0.0.74, To: 1.0.0.73, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >> >> Since all these Interests were duplicates of the original Interest, there should be only one copy of the Data packet going back to the ndnping client, but it seems that the Data came back in two paths: >> >> - CAIDA -> Memphis -> CSU -> UCLA >> - CAIDA -> Memphis -> CSU -> UIUC -> UMich -> UCLA >> >> Seems that CSU was not doing duplicate Interest suppression correctly. The Interest from UIUC to CSU received at time 1425075159.345243 should have been dropped because it's a duplicate of the earlier Interest from UCLA to CSU received at time 1425075159.119112, but it was not and instead brought data back. The time difference between the two Interests is 226ms. I'm not sure how the duplicate suppression is implemented. Someone more familiar with the forwarding pipeline please help explain the above trace. Thanks. >> >> Lan >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.ARIZONA.EDU Sun Mar 1 10:08:17 2015 From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi) Date: Sun, 1 Mar 2015 11:08:17 -0700 Subject: [Nfd-dev] strange results In-Reply-To: <845F7EA7-B17A-4819-9816-E231124EA103@cs.ucla.edu> References: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu> <4A7C4BA3-B5C3-456A-B1CA-24891D28996A@memphis.edu> <845F7EA7-B17A-4819-9816-E231124EA103@cs.ucla.edu> Message-ID: Hi Lixia Yes, UCLA knows CSU is a better nexthop than UMICH, so it will prefer CSU for the next Interest. However, UMICH thinks UIUC is a better nexthop than CSU, which isn't true. This will affect future traffic than originates from UMICH. Yours, Junxiao On Sun, Mar 1, 2015 at 10:42 AM, Lixia Zhang wrote: > > On Feb 28, 2015, at 10:28 PM, Lan Wang (lanwang) > wrote: > > In case you are wondering why this is a problem. Look at the UMich > node. It first forwarded the Interest to CSU, but that one didn't bring > back the data (perhaps it was correctly suppressed). However, its second > Interest to UIUC did bring back data (which should not have happened). So > from that point on, it's going to use UIUC instead of the better path CSU > to forward Interest to CAIDA. We did observe this problem. > > Lan > > > Lan, I do not know exactly how your ping measurement works, but from the > above description, it seems that, > > - for each ping interest with nonce=N, for any node to get duplicates, > there ought to be a branching point along its (the interest?s) path > > - UMich is not this point, since CSU already detected the interest from > UMich as duplicate (So CSU node has seen interest(N) from some other > neighbor) > > - this branching point (could be the origin consumer?) should be able to > tell a good path from a worse path, right? > > Lixia > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun Mar 1 10:18:59 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 1 Mar 2015 11:18:59 -0700 Subject: [Nfd-dev] strange results In-Reply-To: <672D12F0-0FB9-4646-A380-A147B89262CE@cisco.com> References: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu> <6EBCEC36-9AD0-4996-A147-2CEE495EFD50@memphis.edu> <672D12F0-0FB9-4646-A380-A147B89262CE@cisco.com> Message-ID: Hi Dave NFD has no "pending Interest table". The table is called "Interest table", which contains both pending Interests and recently satisfied Interests (for duplicate suppression and measurements purposes). The abbreviation "PIT" is kept for historical reason. All incoming Interests, including those detected as duplicates, and those satisfied from ContentStore, will create an entry in the Interest table. Those Interest table entries are useful for duplication suppression, and will be deleted after "straggler timer" expires: 100ms. DeadNonceList has expected entry lifetime of 6 seconds. This setting is taken from ccnd 0.8.0. Only those with risk of looping will be inserted. "Multi-path arrival" is not looping. See spec < http://redmine.named-data.net/attachments/download/154/dead-nonce-list_20141004.pptx> for exact condition. Yours, Junxiao On Sun, Mar 1, 2015 at 9:49 AM, Dave Oran (oran) wrote: > Given that any Interest arriving after a PIT entry has been satisfied (or > timed out) has the hazard of re-creating the PIT and getting processed when > it shouldn?t, the ?DeadNonceList? entries have to persist for at least the > MPL (maximum packet lifetime) of the network. In the IP world, various > pathologies can cause this period to be very long; on the order of minutes. > What?s the proposed DeadNonce timer for NFD? What?s the worst case memory > pressure? - seems like it could be gigantic for a high-speed router. Are > there replay attacks that can cause the DeadNonceList to grow without bound? > > Some folks have argued this isn?t an implementation question so much as an > architecture question around the use of nonces for loop detection in the > first place. > > DaveO. > > > On Mar 1, 2015, at 11:21 AM, Lan Wang (lanwang) > wrote: > > > > Junxiao, > > > > Thank you very much for the explanation and finding the root cause of > the problem. It is causing wild oscillations in the NDNPing delays > (switches back and forth between the best path and worse paths back and > forth) since the measurements that the strategy is based on were wrong. I > hope this could be fixed as soon as possible since we need the correct > results for our paper. > > > > > > Conceptually the solution requires duplicate suppression (at least for > some time) after a PIT entry has been satisfied. I thought the > DeadNonceList was designed for this purpose. If you check the > DeadNonceList before the PIT entry, then you'll detect the duplicate easily. > > > > However, if you do not want to check the DeadNonceList first (for > whatever reason I don't understand), the current Interest processing flow > has a couple issues if I understand correctly: > > > > 1. the current logic assume that there's no need to record a dead nonce > if the PIT entry is satisfied. Obviously the example shows that although > there's no danger of interest looping, there can be other dangers, e.g., > the wrong measurements shown in the example. > > > > 2. the in-record and out-record were deleted when the PIT entry is > satisfied. This causes problems since the current logic checks these > things before checking the DeadNonceList. > > > > So to fix the above, the code needs to (a) record the dead nonce > regardless of whether the PIT entry is satisfied and also (b) check the > DeadNonceList even after a PIT entry is satisfied. > > > > Thanks a lot. > > > > Lan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Sun Mar 1 10:23:42 2015 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Sun, 1 Mar 2015 18:23:42 +0000 Subject: [Nfd-dev] strange results In-Reply-To: <845F7EA7-B17A-4819-9816-E231124EA103@cs.ucla.edu> References: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu> <4A7C4BA3-B5C3-456A-B1CA-24891D28996A@memphis.edu>, <845F7EA7-B17A-4819-9816-E231124EA103@cs.ucla.edu> Message-ID: On Mar 1, 2015, at 11:42 AM, Lixia Zhang > wrote: On Feb 28, 2015, at 10:28 PM, Lan Wang (lanwang) > wrote: In case you are wondering why this is a problem. Look at the UMich node. It first forwarded the Interest to CSU, but that one didn't bring back the data (perhaps it was correctly suppressed). However, its second Interest to UIUC did bring back data (which should not have happened). So from that point on, it's going to use UIUC instead of the better path CSU to forward Interest to CAIDA. We did observe this problem. Lan Lan, I do not know exactly how your ping measurement works, but from the above description, it seems that, - for each ping interest with nonce=N, for any node to get duplicates, there ought to be a branching point along its (the interest?s) path - UMich is not this point, since CSU already detected the interest from UMich as duplicate (So CSU node has seen interest(N) from some other neighbor) UMich was on one of the several branches that didn't get the data due to duplicate suppression, so it retransmitted the interest over a different (worse) path. This duplicate interest hit CSU's cache and was able to bring data back due to incorrect duplicate suppression. From this point on, Umich switched to the worse path. Junxiao has a good example with simpler topology at http://redmine.named-data.net/issues/2592 Lan - this branching point (could be the origin consumer?) should be able to tell a good path from a worse path, right? Lixia On Mar 1, 2015, at 12:02 AM, Lan Wang (lanwang) > wrote: Hi all, We're seeing strange results from our latest experiments. Below is an ndndump trace of one ndnping packet from UCLA to CAIDA. We ran the experiments using mini-ndn. I'm also attaching a png file that shows where the Interests and Data packets were forwarded (white is the original transmission of the Interest, yellow and blue indicate retransmissions of this Interest with the same nonce by different routers). [Lans-MacBook-Air:test-ucla-ping-cpu-alloc-withNLSRlog-timing/ls/faces-2] lanwang1% grep "/ndn/edu/caida/ping/251436634" */dump* | sort -t ":" -k 2 | more ucla/dump.0ucla:1425075159.119036 From: 1.0.0.42, To: 1.0.0.41, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.0csu:1425075159.119112 From: 1.0.0.42, To: 1.0.0.41, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.4csu:1425075159.140391 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 memphis/dump.1memphis:1425075159.140488 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 ucla/dump.1ucla:1425075159.164108 From: 1.0.0.73, To: 1.0.0.74, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 umich/dump.0umich:1425075159.164185 From: 1.0.0.73, To: 1.0.0.74, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 umich/dump.2umich:1425075159.179542 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.6csu:1425075159.179620 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 memphis/dump.2memphis:1425075159.181041 From: 1.0.0.18, To: 1.0.0.17, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 caida/dump.4caida:1425075159.181138 From: 1.0.0.18, To: 1.0.0.17, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 caida/dump.4caida:1425075159.224372 From: 1.0.0.17, To: 1.0.0.18, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 memphis/dump.2memphis:1425075159.224444 From: 1.0.0.17, To: 1.0.0.18, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 memphis/dump.1memphis:1425075159.245821 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 csu/dump.4csu:1425075159.245887 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 csu/dump.0csu:1425075159.262268 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 ucla/dump.0ucla:1425075159.262344 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 umich/dump.4umich:1425075159.330700 From: 1.0.0.82, To: 1.0.0.81, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 uiuc/dump.2uiuc:1425075159.330771 From: 1.0.0.82, To: 1.0.0.81, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 uiuc/dump.0uiuc:1425075159.345166 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.5csu:1425075159.345243 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.5csu:1425075159.359534 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 uiuc/dump.0uiuc:1425075159.359617 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 uiuc/dump.2uiuc:1425075159.365972 From: 1.0.0.81, To: 1.0.0.82, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 umich/dump.4umich:1425075159.366036 From: 1.0.0.81, To: 1.0.0.82, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 umich/dump.0umich:1425075159.399394 From: 1.0.0.74, To: 1.0.0.73, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 ucla/dump.1ucla:1425075159.399522 From: 1.0.0.74, To: 1.0.0.73, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 Since all these Interests were duplicates of the original Interest, there should be only one copy of the Data packet going back to the ndnping client, but it seems that the Data came back in two paths: - CAIDA -> Memphis -> CSU -> UCLA - CAIDA -> Memphis -> CSU -> UIUC -> UMich -> UCLA Seems that CSU was not doing duplicate Interest suppression correctly. The Interest from UIUC to CSU received at time 1425075159.345243 should have been dropped because it's a duplicate of the earlier Interest from UCLA to CSU received at time 1425075159.119112, but it was not and instead brought data back. The time difference between the two Interests is 226ms. I'm not sure how the duplicate suppression is implemented. Someone more familiar with the forwarding pipeline please help explain the above trace. Thanks. Lan _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Sun Mar 1 10:28:17 2015 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Sun, 1 Mar 2015 18:28:17 +0000 Subject: [Nfd-dev] strange results In-Reply-To: References: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu> <4A7C4BA3-B5C3-456A-B1CA-24891D28996A@memphis.edu>, <845F7EA7-B17A-4819-9816-E231124EA103@cs.ucla.edu>, Message-ID: <519FDF8F-6DA4-4211-AABC-3AB253B9E405@memphis.edu> On Mar 1, 2015, at 12:23 PM, Lan Wang (lanwang) > wrote: On Mar 1, 2015, at 11:42 AM, Lixia Zhang > wrote: On Feb 28, 2015, at 10:28 PM, Lan Wang (lanwang) > wrote: In case you are wondering why this is a problem. Look at the UMich node. It first forwarded the Interest to CSU, but that one didn't bring back the data (perhaps it was correctly suppressed). However, its second Interest to UIUC did bring back data (which should not have happened). So from that point on, it's going to use UIUC instead of the better path CSU to forward Interest to CAIDA. We did observe this problem. Lan Lan, I do not know exactly how your ping measurement works, but from the above description, it seems that, - for each ping interest with nonce=N, for any node to get duplicates, there ought to be a branching point along its (the interest?s) path - UMich is not this point, since CSU already detected the interest from UMich as duplicate (So CSU node has seen interest(N) from some other neighbor) UMich was on one of the several branches that didn't get the data due to duplicate suppression, so it retransmitted the interest over a different (worse) path. This duplicate interest hit CSU's cache and was able to bring data back due to incorrect duplicate suppression. From this point on, Umich switched to the worse path. Junxiao has a good example with simpler topology at http://redmine.named-data.net/issues/2592 In note 2. Lan Lan - this branching point (could be the origin consumer?) should be able to tell a good path from a worse path, right? Lixia On Mar 1, 2015, at 12:02 AM, Lan Wang (lanwang) > wrote: Hi all, We're seeing strange results from our latest experiments. Below is an ndndump trace of one ndnping packet from UCLA to CAIDA. We ran the experiments using mini-ndn. I'm also attaching a png file that shows where the Interests and Data packets were forwarded (white is the original transmission of the Interest, yellow and blue indicate retransmissions of this Interest with the same nonce by different routers). [Lans-MacBook-Air:test-ucla-ping-cpu-alloc-withNLSRlog-timing/ls/faces-2] lanwang1% grep "/ndn/edu/caida/ping/251436634" */dump* | sort -t ":" -k 2 | more ucla/dump.0ucla:1425075159.119036 From: 1.0.0.42, To: 1.0.0.41, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.0csu:1425075159.119112 From: 1.0.0.42, To: 1.0.0.41, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.4csu:1425075159.140391 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 memphis/dump.1memphis:1425075159.140488 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 ucla/dump.1ucla:1425075159.164108 From: 1.0.0.73, To: 1.0.0.74, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 umich/dump.0umich:1425075159.164185 From: 1.0.0.73, To: 1.0.0.74, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 umich/dump.2umich:1425075159.179542 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.6csu:1425075159.179620 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 memphis/dump.2memphis:1425075159.181041 From: 1.0.0.18, To: 1.0.0.17, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 caida/dump.4caida:1425075159.181138 From: 1.0.0.18, To: 1.0.0.17, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 caida/dump.4caida:1425075159.224372 From: 1.0.0.17, To: 1.0.0.18, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 memphis/dump.2memphis:1425075159.224444 From: 1.0.0.17, To: 1.0.0.18, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 memphis/dump.1memphis:1425075159.245821 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 csu/dump.4csu:1425075159.245887 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 csu/dump.0csu:1425075159.262268 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 ucla/dump.0ucla:1425075159.262344 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 umich/dump.4umich:1425075159.330700 From: 1.0.0.82, To: 1.0.0.81, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 uiuc/dump.2uiuc:1425075159.330771 From: 1.0.0.82, To: 1.0.0.81, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 uiuc/dump.0uiuc:1425075159.345166 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.5csu:1425075159.345243 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48 csu/dump.5csu:1425075159.359534 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 uiuc/dump.0uiuc:1425075159.359617 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 uiuc/dump.2uiuc:1425075159.365972 From: 1.0.0.81, To: 1.0.0.82, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 umich/dump.4umich:1425075159.366036 From: 1.0.0.81, To: 1.0.0.82, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 umich/dump.0umich:1425075159.399394 From: 1.0.0.74, To: 1.0.0.73, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 ucla/dump.1ucla:1425075159.399522 From: 1.0.0.74, To: 1.0.0.73, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 Since all these Interests were duplicates of the original Interest, there should be only one copy of the Data packet going back to the ndnping client, but it seems that the Data came back in two paths: - CAIDA -> Memphis -> CSU -> UCLA - CAIDA -> Memphis -> CSU -> UIUC -> UMich -> UCLA Seems that CSU was not doing duplicate Interest suppression correctly. The Interest from UIUC to CSU received at time 1425075159.345243 should have been dropped because it's a duplicate of the earlier Interest from UCLA to CSU received at time 1425075159.119112, but it was not and instead brought data back. The time difference between the two Interests is 226ms. I'm not sure how the duplicate suppression is implemented. Someone more familiar with the forwarding pipeline please help explain the above trace. Thanks. Lan _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From lixia at CS.UCLA.EDU Sun Mar 1 12:01:29 2015 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Sun, 1 Mar 2015 12:01:29 -0800 Subject: [Nfd-dev] strange results In-Reply-To: References: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu> <4A7C4BA3-B5C3-456A-B1CA-24891D28996A@memphis.edu> <845F7EA7-B17A-4819-9816-E231124EA103@cs.ucla.edu> Message-ID: > On Mar 1, 2015, at 10:08 AM, Junxiao Shi wrote: > > Hi Lixia > > Yes, UCLA knows CSU is a better nexthop than UMICH, so it will prefer CSU for the next Interest. > > However, UMICH thinks UIUC is a better nexthop than CSU, which isn't true. > This will affect future traffic than originates from UMICH. it seems that the root cause of this problem is that the origin consumer (node A in your note-2) sends an interest with the same nonce to 2 routers. So A is the branching point my earlier msg talked about. If A?s purpose is measurement: A better sends interest with different nonces to D and R. > On Sun, Mar 1, 2015 at 10:42 AM, Lixia Zhang > wrote: >> On Feb 28, 2015, at 10:28 PM, Lan Wang (lanwang) > wrote: >> >> In case you are wondering why this is a problem. Look at the UMich node. It first forwarded the Interest to CSU, but that one didn't bring back the data (perhaps it was correctly suppressed). However, its second Interest to UIUC did bring back data (which should not have happened). So from that point on, it's going to use UIUC instead of the better path CSU to forward Interest to CAIDA. We did observe this problem. >> >> Lan > > Lan, I do not know exactly how your ping measurement works, but from the above description, it seems that, > > - for each ping interest with nonce=N, for any node to get duplicates, there ought to be a branching point along its (the interest?s) path > > - UMich is not this point, since CSU already detected the interest from UMich as duplicate (So CSU node has seen interest(N) from some other neighbor) > > - this branching point (could be the origin consumer?) should be able to tell a good path from a worse path, right? > > Lixia > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ignacio.Solis at parc.com Sun Mar 1 17:25:55 2015 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Mon, 2 Mar 2015 01:25:55 +0000 Subject: [Nfd-dev] Re-presenting the case against nonces Message-ID: It is evident from these past email threads that nonces are still causing problems for NDN. Isn?t it time you re-evaluate their use? I would be one of the people that has argued that this is an architectural problem. >From the emails (and links) it has been stated that NONCES have issues in detecting loops when the loop is longer than the PIT entry. This is considering the simple case of interests not forking. To solve this problem (how to use nonces to detect loops reliably) the only possible solution is to have really long lived PIT entries. I would argue this won?t be feasible and it becomes an attack vector. In the non-simple case of an interest being forked with the same nonce, you may have a loop where the PIT entry is satisfied and no longer exists by the time the looped interest arrives. The current proposal to solve this is to keep nonces around for a long time. Again, this increases the memory usage at a router and you have to guess the time loops can take. There is a second issue which arises from nodes dropping an interest if the nonce has already been seen. Whether the second nonce is from a looped interest OR from a interest that has been forked in the past, there is a problem with interest aggregation. Any interest that has been aggregated in a PIT entry created by the original interest (the forked one with the original nonce) is at risk of being black-holed by dropping the repeated nonce. There are multiple ways to solve this. One is to change how aggregation is done (potentially the right choice). Another is to never fork an interest (also a potentially valid choice). Yet another is to not drop the interest with the repeated nonce. I admit that I don?t know what the NDN solution for this is. I do know, both from Alex and Lixia?s email, that there is a proposal/technique/suggestion that any router that forks interests should pick a new nonce for the forked interest. This seems like an interesting choice. If you do pick a new nonce every time you fork an interest, then the only use for nonces becomes loop detection. Since loop detection is more easily done with a hop limit, then it?s not clear why NDN is still keeping the nonce as a core feature. Nonces: A- Can?t assure that loops halt B- Break aggregation (if nodes discard repeated nonces and nodes fork nonces with the same nonce). So, again, if we?re not doing B (because nodes use different nonces when they fork) and nonces can?t assure that they halt loops, then why not look at other alternatives? (like hop limits) There are situations when nonces might be useful for exploration. There are also situations where case B can be solved by having a separate pruning protocol. So, I my argument is not to get rid of nonces completely, it?s to make nonces optional. After all, Lixia just stated that nodes can change nonces, so effectively they?re not required for end-to-end operation. Only some intermediate nodes need to understand what they are about. After all, given all the arguments NDN makes about exploration (like having a flexible TLV), wouldn?t it make sense to make nonces optional (so other methods an be explored)? Again, NDN argues for a TLV that is small enough to carry 1+1, but you?re forcing every packet to waste space in carrying a nonce that is only useful in edge cases. Nacho -- Nacho (Ignacio) Solis Protocol Architect Principal Scientist Palo Alto Research Center (PARC) +1(650)812-4458 Ignacio.Solis at parc.com On 3/1/15, 8:49 AM, "Dave Oran (oran)" wrote: >Given that any Interest arriving after a PIT entry has been satisfied (or >timed out) has the hazard of re-creating the PIT and getting processed >when it shouldn?t, the ?DeadNonceList? entries have to persist for at >least the MPL (maximum packet lifetime) of the network. In the IP world, >various pathologies can cause this period to be very long; on the order >of minutes. What?s the proposed DeadNonce timer for NFD? What?s the worst >case memory pressure? - seems like it could be gigantic for a high-speed >router. Are there replay attacks that can cause the DeadNonceList to grow >without bound? > >Some folks have argued this isn?t an implementation question so much as >an architecture question around the use of nonces for loop detection in >the first place. > >DaveO. > >> On Mar 1, 2015, at 11:21 AM, Lan Wang (lanwang) >>wrote: >> >> Junxiao, >> >> Thank you very much for the explanation and finding the root cause of >>the problem. It is causing wild oscillations in the NDNPing delays >>(switches back and forth between the best path and worse paths back and >>forth) since the measurements that the strategy is based on were wrong. >>I hope this could be fixed as soon as possible since we need the correct >>results for our paper. >> >> >> Conceptually the solution requires duplicate suppression (at least for >>some time) after a PIT entry has been satisfied. I thought the >>DeadNonceList was designed for this purpose. If you check the >>DeadNonceList before the PIT entry, then you'll detect the duplicate >>easily. >> >> However, if you do not want to check the DeadNonceList first (for >>whatever reason I don't understand), the current Interest processing >>flow has a couple issues if I understand correctly: >> >> 1. the current logic assume that there's no need to record a dead nonce >>if the PIT entry is satisfied. Obviously the example shows that >>although there's no danger of interest looping, there can be other >>dangers, e.g., the wrong measurements shown in the example. >> >> 2. the in-record and out-record were deleted when the PIT entry is >>satisfied. This causes problems since the current logic checks these >>things before checking the DeadNonceList. >> >> So to fix the above, the code needs to (a) record the dead nonce >>regardless of whether the PIT entry is satisfied and also (b) check the >>DeadNonceList even after a PIT entry is satisfied. >> >> Thanks a lot. >> >> Lan >> >> On Mar 1, 2015, at 12:53 AM, Junxiao Shi >>wrote: >> >>> Hi Lan >>> >>> Trace of CSU node has: >>> ? 5159.119 interestFrom UCLA >>> ? 5159.140 interestTo MEMPHIS >>> ? 5159.179 interestFrom UMICH >>> ? 5159.245887 dataFrom MEMPHIS >>> ? 5159.262 dataTo UCLA >>> ? 5159.345243 interestFrom UIUC >>> ? 5159.359 dataTo UIUC >>> >>> Here's what happens: >>> >>> 5159.119 upon receiving packet 1, new PIT entry is created with >>>in-record of UCLA face >>> 5159.140 Interest is forwarded to MEMPHIS as packet 2; out-record of >>>MEMPHIS face is created >>> 5159.179 packet 3 arrives, but it's suppressed due to duplicate Nonce >>>in PIT entry >>> 5159.245887 packet 4 arrives and satisfies the PIT entry; straggler >>>timer is set to erase the PIT entry at 5159.345887 >>> 5159.262 Data is returned to UCLA as packet 5, but not UMICH because >>>packet 2 was suppressed; in-records and out-record of MEMPHIS face are >>>deleted; Nonce is not inserted to DeadNonceList because there's no risk >>>of looping (see spec for exact condition) >>> 5159.345243 packet 6 arrives and cancels the straggler timer; it hits >>>ContentStore and is not forwarded >>> 5159.345887 PIT entry won't be deleted now because straggler timer was >>>cancelled by packet 6 >>> 5159.359 Data from ContentStore is returned to UIUC as packet 7 >>> >>> >>> The problematic step is: "in-records and out-record of MEMPHIS face >>>are deleted". >>> Originally, PIT entry has a NonceList data structure to detect >>>duplicate Nonces. Deleting in-records won't affect duplicate Nonce >>>detection. >>> When DeadNonceList is introduced, the PIT NonceList is dropped, and >>>PIT entry would report a duplicate Nonce only if any in-record or >>>out-record contains a duplicate Nonce. >>> This assumes that in-records are retained before straggler timer >>>expires, but forwarding pipelines are not able to fulfill this >>>assumption. >>> >>> This issue is tracked as Bug 2592. >>> Root cause is found, but I need to think about the design. >>> >>> Yours, Junxiao >>> >>> On Sat, Feb 28, 2015 at 11:02 PM, Lan Wang (lanwang) >>> wrote: >>> csu/dump.0csu:1425075159.119112 From: 1.0.0.42, To: 1.0.0.41, Tunnel >>>Type: UDP, INTEREST: >>>/ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, >>>size: 48 >>> csu/dump.4csu:1425075159.140391 From: 1.0.0.29, To: 1.0.0.30, Tunnel >>>Type: UDP, INTEREST: >>>/ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, >>>size: 48 >>> csu/dump.6csu:1425075159.179620 From: 1.0.0.50, To: 1.0.0.49, Tunnel >>>Type: UDP, INTEREST: >>>/ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, >>>size: 48 >>> csu/dump.4csu:1425075159.245887 From: 1.0.0.30, To: 1.0.0.29, Tunnel >>>Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >>> csu/dump.0csu:1425075159.262268 From: 1.0.0.41, To: 1.0.0.42, Tunnel >>>Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >>> csu/dump.5csu:1425075159.345243 From: 1.0.0.46, To: 1.0.0.45, Tunnel >>>Type: UDP, INTEREST: >>>/ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, >>>size: 48 >>> csu/dump.5csu:1425075159.359534 From: 1.0.0.45, To: 1.0.0.46, Tunnel >>>Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392 >>> >>> Seems that CSU was not doing duplicate Interest suppression correctly. >>> The Interest from UIUC to CSU received at time 1425075159.345243 >>>should have been dropped because it's a duplicate of the earlier >>>Interest from UCLA to CSU received at time 1425075159.119112, but it >>>was not and instead brought data back. The time difference between the >>>two Interests is 226ms. I'm not sure how the duplicate suppression is >>>implemented. Someone more familiar with the forwarding pipeline please >>>help explain the above trace. Thanks. >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From lixia at CS.UCLA.EDU Sun Mar 1 19:31:14 2015 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Sun, 1 Mar 2015 19:31:14 -0800 Subject: [Nfd-dev] Re-presenting the case against nonces In-Reply-To: References: Message-ID: <21569AFE-9448-4801-9C95-581117E18BAD@cs.ucla.edu> > On Mar 1, 2015, at 5:25 PM, Ignacio.Solis at parc.com wrote: > > It is evident from these past email threads that nonces are still causing > problems for NDN. Isn?t it time you re-evaluate their use? > > I would be one of the people that has argued that this is an architectural > problem. > > From the emails (and links) it has been stated that NONCES have issues in > detecting loops when the loop is longer than the PIT entry. This is > considering the simple case of interests not forking. To solve this > problem (how to use nonces to detect loops reliably) the only possible > solution is to have really long lived PIT entries. I would argue this > won?t be feasible and it becomes an attack vector. > > In the non-simple case of an interest being forked with the same nonce, > you may have a loop where the PIT entry is satisfied and no longer exists > by the time the looped interest arrives. The current proposal to solve > this is to keep nonces around for a long time. Again, this increases the > memory usage at a router and you have to guess the time loops can take. > > There is a second issue which arises from nodes dropping an interest if > the nonce has already been seen. Whether the second nonce is from a > looped interest OR from a interest that has been forked in the past, there > is a problem with interest aggregation. Any interest that has been > aggregated in a PIT entry created by the original interest (the forked one > with the original nonce) is at risk of being black-holed by dropping the > repeated nonce. > > There are multiple ways to solve this. One is to change how aggregation > is done (potentially the right choice). Another is to never fork an > interest (also a potentially valid choice). Yet another is to not drop the > interest with the repeated nonce. > > I admit that I don?t know what the NDN solution for this is. I do know, > both from Alex and Lixia?s email, that there is a > proposal/technique/suggestion that any router that forks interests should > pick a new nonce for the forked interest. Just to clarify this specific point: the above is not what I said. 1/ the issue brought up by Lan is not a looping problem. 2/ Lan was using pings for measurement, and saw unexpected forwarding paths (not loops) 3/ I suggested that she should send interest with different nonce if she expects the interests sent to different routers to all bring back data. Just a clarification. Now back to your discussion. From chenatu2006 at gmail.com Mon Mar 2 04:28:44 2015 From: chenatu2006 at gmail.com (Shuo Chen) Date: Mon, 2 Mar 2015 20:28:44 +0800 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> Message-ID: Hi Yingdi, My question is that how to sign a cert with the root cert generated by another host. Here is my security model root---------site1----------router1 |-----------site2----------router2 I installed certificates of root, site1 and router1 in host1. used ndnsec cert-dump to dump certificate of root in a file. The I transferred this certificate file into another machine and used ndnsec cert-install to install the certificate. All above works well. Then $ ndnsec-certgen -N /root/site2 -s /root site2-cert.req | ndnsec-cert-install - It shows ?ERROR: private key doesn't exists? ----- Shuo Chen On Thu, Nov 20, 2014 at 2:23 AM, Yingdi Yu wrote: > > On Nov 19, 2014, at 10:13 AM, Junxiao Shi > wrote: > > Dear folks > > While we are able to request testbed certificates from ndncert website, > when doing experiments, it's undesirable to request testbed certificates > for all nodes. > Suppose someone wants to start a certificate chain from scratch, how could > this be done? > > > Just to clarify, the scenario you describe is a trust model for the > ndncert only. For apps that just want to use simple trust model, it is not > necessary to create so many keys. > > > Specifically, what are the commands to: > > 1. generate a root certificate: /example/KEY/ksk-1/ID-CERT > 2. generate a site certificate and sign it by root certificate: > /example/KEY/site1/ksk-2/ID-CERT > 3. generate a user certificate and sign it by site certificate: > /example/site1/KEY/user1/ksk-3/ID-CERT > 4. publish root, site, user certificate in a repository or ndns system > 5. generate a data signing certificate and sign it by user > certificate: /example/site1/user1/KEY/dsk-4/ID-CERT > > > Another question is: why is testbed root certificate named > /ndn/KEY/ksk-xxxx/ID-CERT, instead of /KEY/ndn/ksk-xxxx/ID-CERT > > > Because the root of the testbed is "/ndn" rather than "/", and testbed > publish its root cert under its own prefix. > > Yingdi > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Mon Mar 2 07:15:48 2015 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Mon, 2 Mar 2015 15:15:48 +0000 Subject: [Nfd-dev] strange results In-Reply-To: References: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu> <4A7C4BA3-B5C3-456A-B1CA-24891D28996A@memphis.edu> <845F7EA7-B17A-4819-9816-E231124EA103@cs.ucla.edu> Message-ID: On Mar 1, 2015, at 2:01 PM, Lixia Zhang > wrote: On Mar 1, 2015, at 10:08 AM, Junxiao Shi > wrote: Hi Lixia Yes, UCLA knows CSU is a better nexthop than UMICH, so it will prefer CSU for the next Interest. However, UMICH thinks UIUC is a better nexthop than CSU, which isn't true. This will affect future traffic than originates from UMICH. it seems that the root cause of this problem is that the origin consumer (node A in your note-2) sends an interest with the same nonce to 2 routers. So A is the branching point my earlier msg talked about. If A?s purpose is measurement: A better sends interest with different nonces to D and R. The problem here is ineffective duplicate suppression. There's no need to use a different nonce in this case, as long as interests with duplicate nonces are detected correctly *after* a PIT is satisfied. Using a different nonce may work, but it's not required for solving this problem. Lan On Sun, Mar 1, 2015 at 10:42 AM, Lixia Zhang > wrote: On Feb 28, 2015, at 10:28 PM, Lan Wang (lanwang) > wrote: In case you are wondering why this is a problem. Look at the UMich node. It first forwarded the Interest to CSU, but that one didn't bring back the data (perhaps it was correctly suppressed). However, its second Interest to UIUC did bring back data (which should not have happened). So from that point on, it's going to use UIUC instead of the better path CSU to forward Interest to CAIDA. We did observe this problem. Lan Lan, I do not know exactly how your ping measurement works, but from the above description, it seems that, - for each ping interest with nonce=N, for any node to get duplicates, there ought to be a branching point along its (the interest?s) path - UMich is not this point, since CSU already detected the interest from UMich as duplicate (So CSU node has seen interest(N) from some other neighbor) - this branching point (could be the origin consumer?) should be able to tell a good path from a worse path, right? Lixia -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdd at wustl.edu Mon Mar 2 07:31:48 2015 From: jdd at wustl.edu (Dehart, John) Date: Mon, 2 Mar 2015 15:31:48 +0000 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> Message-ID: <54759201-75A6-4A2E-9DBB-D428D84B3C0C@wustl.edu> Shou, You have to be careful to get all the names correct from command to command. Here is what we currently do on the Testbed for NLSR. Note that we generate a set of keys and certs specifically for NLSR, separate from the other Testbed certs. On ucla Node we generate a root cert for NLSR: ucla> sudo su - nlsr -c 'export HOME=/var/lib/ndn/nlsr/; ndnsec-key-gen -n /ndn' ucla> sudo su - nlsr -c 'export HOME=/var/lib/ndn/nlsr/; ndnsec-sign-req /ndn > /etc/ndn/nlsr/keys/root.cert' On the WU node we generate a key: wu> sudo su - nlsr -c 'export HOME=/var/lib/ndn/nlsr/; ndnsec-key-gen -n /ndn/edu/wustl > ~nlsr/unsigned_site.cert' We sign that key with the root cert on UCLA: ucla> sudo su - nlsr -c 'export HOME=/var/lib/ndn/nlsr/; ndnsec-cert-gen -S 201410080000 -E 201510080000 -N "WU" -s /ndn -p /ndn/edu/wustl -r /home/nlsr/wu_unsigned_site.cert > /home/nlsr/wu_site.cert' We copy the root cert and the signed wu cert back to WU node into /etc/ndn/nlsr/keys/root.cert and /etc/ndn/nlsr/keys/site.cert . Then continue ? Generate a key for WU operator, ndnops: wu> sudo su - nlsr -c 'export HOME=/var/lib/ndn/nlsr/; ndnsec-key-gen -n /ndn/edu/wustl/%C1.Operator/ndnops > ~nlsr/unsigned_operator.cert? Sign operator key with site cert named /ndn/edu/wustl wu> sudo su - nlsr -c 'export HOME=/var/lib/ndn/nlsr/; ndnsec-cert-gen -S 201410080000 -E 201510080000 -N "WU Operator" -s /ndn/edu/wustl -p /ndn/edu/wustl/%C1.Operator/ndnops -r ~nlsr/unsigned_operator.cert > /etc/ndn/nlsr/keys/operator.cert? Generate a router key for WU: wu> sudo su - nlsr -c 'export HOME=/var/lib/ndn/nlsr/; ndnsec-key-gen -n /ndn/edu/wustl/%C1.Router/wundngw > ~nlsr/unsigned_router.cert? Sign router key with operator cert named /ndn/edu/wustl/%C1.Operator/ndnops wu> sudo su - nlsr -c 'export HOME=/var/lib/ndn/nlsr/; ndnsec-cert-gen -S 201410080000 -E 201510080000 -N "WU Router wundngw" -s /ndn/edu/wustl/%C1.Operator/ndnops -p /ndn/edu/wustl/%C1.Router/wundngw -r ~nlsr/unsigned_router.cert > /etc/ndn/nlsr/keys/router.cert' So, in the end, on each node we end up with four cert files in /etc/ndn/nlsr/keys: root.cert site.cert operator.cert router.cert Hope this helps. John On Mar 2, 2015, at 6:28 AM, Shuo Chen > wrote: Hi Yingdi, My question is that how to sign a cert with the root cert generated by another host. Here is my security model root---------site1----------router1 |-----------site2----------router2 I installed certificates of root, site1 and router1 in host1. used ndnsec cert-dump to dump certificate of root in a file. The I transferred this certificate file into another machine and used ndnsec cert-install to install the certificate. All above works well. Then $ ndnsec-certgen -N /root/site2 -s /root site2-cert.req | ndnsec-cert-install - It shows ?ERROR: private key doesn't exists? ----- Shuo Chen On Thu, Nov 20, 2014 at 2:23 AM, Yingdi Yu > wrote: On Nov 19, 2014, at 10:13 AM, Junxiao Shi > wrote: Dear folks While we are able to request testbed certificates from ndncert website, when doing experiments, it's undesirable to request testbed certificates for all nodes. Suppose someone wants to start a certificate chain from scratch, how could this be done? Just to clarify, the scenario you describe is a trust model for the ndncert only. For apps that just want to use simple trust model, it is not necessary to create so many keys. Specifically, what are the commands to: 1. generate a root certificate: /example/KEY/ksk-1/ID-CERT 2. generate a site certificate and sign it by root certificate: /example/KEY/site1/ksk-2/ID-CERT 3. generate a user certificate and sign it by site certificate: /example/site1/KEY/user1/ksk-3/ID-CERT 4. publish root, site, user certificate in a repository or ndns system 5. generate a data signing certificate and sign it by user certificate: /example/site1/user1/KEY/dsk-4/ID-CERT Another question is: why is testbed root certificate named /ndn/KEY/ksk-xxxx/ID-CERT, instead of /KEY/ndn/ksk-xxxx/ID-CERT Because the root of the testbed is "/ndn" rather than "/", and testbed publish its root cert under its own prefix. Yingdi _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Mon Mar 2 08:53:38 2015 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Mon, 2 Mar 2015 16:53:38 +0000 Subject: [Nfd-dev] Examples of setting up NFD networks In-Reply-To: References: Message-ID: Junxiao, Can you add a step to start nfd (before nfdc create udp4://192.0.2.1:6363) for people who are not familiar with nfd at all? They may not have read other material before looking at this. Thanks. Lan On Feb 27, 2015, at 9:24 AM, Junxiao Shi wrote: > Hi Jeff > > yoursunny.com published a blog post last year about how to create a two-node network and complete a ping: > http://yoursunny.com/t/2014/nfd-connect/ > > Yours, Junxiao > > On Feb 26, 2015 11:37 PM, "Burke, Jeff" wrote: > > Hi folks, > > I am curious where the best place to look is for (or where one could eventually contribute some) examples of actually settings up networks with NFD, even just simple ones using static routes. There is a brief mention of nfdc in the install.html but I am looking for a little more of a guidebook for an operator that briefly introduces all of the tools, explains how to set up a small multi-node network and test connectivity, maybe even introduces strategy. Does such a thing exist? > > Thanks, > > Jeff > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From shijunxiao at email.arizona.edu Mon Mar 2 15:37:56 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 2 Mar 2015 16:37:56 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> Message-ID: Dear folks I found the repo-ng solution from ndncert website source code: https://github.com/named-data/ndncert/blob/1e4ff1dad1ae4aabbd29b124ba83d9ce4ff7111d/ndnop-process-requests#L181 To publish a key: 1. repo-ng service must be running; in repo-ng.conf, repo.data.prefix must cover the certificate's Name 2. tee the input to ndnsec-cert-install into a file 3. base64 decode the certificate file and send the binary into localhost tcp/7376 port Example commands to create and publish root and site certificates: ndnsec-keygen /example | tee example.ndncert | ndnsec-cert-install - base64 -d example.ndncert | nc localhost 7376 ndnsec-keygen /example/site1 > site1.req ndnsec-certgen -N /example/site1 -s /example site1.req | tee site1.ndncert | ndnsec-cert-install - base64 -d site1.ndncert | nc localhost 7376 tcp/7376 is the "tcp bulk insert" service of repo-ng, which seems to treat anything from the socket as a Data packet and store it. I still want to hear about how ndns could be used to publish those certificates. Xiaoke can you answer? Yours, Junxiao On Mon, Feb 23, 2015 at 10:46 PM, Junxiao Shi wrote: > Dear folks > > The only missing piece is: publish root, site, user certificate in a > repository or ndns system. > Does anyone know how to publish a certificate with repo-ng and ndns? I > want to try both. > > Yours, Junxiao > > On Wed, Nov 19, 2014 at 12:49 PM, Yingdi Yu wrote: > >> Hi Junxiao, >> >> On Nov 19, 2014, at 11:23 AM, Junxiao Shi >> wrote: >> >> Hi Yingdi >> >> Suppose one wants to mirror the same trust model as testbed and ndncert >> website, how can he do that? What are the commands? >> >> I list the commands for the example below: >> >> >> Specifically, what are the commands to: >> >> >> generate a root certificate: /example/KEY/ksk-1/ID-CERT >> >> $ ndnsec-keygen /example | ndnsec-cert-install - >> >> >> generate a site certificate and sign it by root certificate: >> /example/KEY/site1/ksk-2/ID-CERT >> >> $ ndnsec-keygen /example/site1 > site1-cert.req >> $ ndnsec-certgen -N /example/site1 -s /example site1-cert.req | >> ndnsec-cert-install - >> >> >> generate a user certificate and sign it by site certificate: >> /example/site1/KEY/user1/ksk-3/ID-CERT >> >> $ ndnsec-keygen /example/site1/user1 > user1-cert.req >> $ ndnsec-certgen -N /example/site1/user1 -s /example/site1 user1-cert.req >> | ndnsec-cert-install - >> >> >> publish root, site, user certificate in a repository or ndns system >> >> This depends on the tools. I usually write a simple cert publishing tool >> or use PIB to publish certificates >> >> >> generate a data signing certificate and sign it by user certificate: >> /example/site1/user1/KEY/dsk-4/ID-CERT >> >> For now, the command line tool disables dsk generation, but we could >> enable that if necessary. >> >> >> Yingdi >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.ARIZONA.EDU Mon Mar 2 15:51:22 2015 From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi) Date: Mon, 2 Mar 2015 16:51:22 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> Message-ID: Hi Shuo If you have multiple machines, you'll need to copy the certificate request between machines. The example below assumes you have five machines: - root - site1 - site2 - router1 - router2 To protect CA private keys, you could keep root, site1, site2 machines offline, and use USB sticks to copy files to and from them. root> ndnsec-keygen /root | tee root.ndncert | ndn-cert-install - site1> ndnsec-keygen /root/site1 > site1.req (copy site1.req to root machine) root> ndnsec-certgen -N /root/site1 -s /root site1.req > site1.ndncert (copy site1.ndncert to site1 machine) site1> cat site1.ndncert | ndn-cert-install - (similar for site2) router1> ndnsec-keygen /root/site1/router1 > router1.req (copy router1.req to site1 machine) site1> ndnsec-certgen -N /root/site1/router1 -s /root/site1 router1.req > router1.ndncert (copy router1.ndncert to router1 machine) router1> cat router1.ndncert | ndn-cert-install - (similar for router2) (copy *.ndncert to some connected machine on the network, and publish them from repo-ng or ndns) Yours, Junxiao On Mon, Mar 2, 2015 at 5:28 AM, Shuo Chen wrote: > Hi Yingdi, > > My question is that how to sign a cert with the root cert generated by > another host. > > Here is my security model > > root---------site1----------router1 > |-----------site2----------router2 > > I installed certificates of root, site1 and router1 in host1. > used ndnsec cert-dump to dump certificate of root in a file. > The I transferred this certificate file into another machine and used > ndnsec cert-install to install the certificate. > All above works well. > Then > $ ndnsec-certgen -N /root/site2 -s /root site2-cert.req | > ndnsec-cert-install - > > It shows ?ERROR: private key doesn't exists? > > ----- > Shuo Chen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From obaidasyed at gmail.com Tue Mar 3 11:02:40 2015 From: obaidasyed at gmail.com (Syed Obaid Amin) Date: Tue, 3 Mar 2015 11:02:40 -0800 Subject: [Nfd-dev] IDE for working with NFD code base In-Reply-To: References: <218086B7-1266-4DED-AF71-09C1C3D11F96@ucla.edu> Message-ID: Hello all, Though it's an old thread but the information might be helpful. I recently came across Code::Blocks (http://www.codeblocks.org/) and it seems like a decent IDE, lightweight and full with features. It's available for major three platform (Mac/Linux/Win). On Ubuntu it is also available on Software Center. Regards, Obaid On Sat, Jan 17, 2015 at 8:14 PM, Ivan Yeo wrote: > Hi all, > > Thanks for the response, I really appreciate it. Have a great weekend! > > Cheers, > Ivan > > > On Jan 17, 2015, at 11:37 AM, Alex Afanasyev < > alexander.afanasyev at ucla.edu> wrote: > > > > I'm using Emacs (aquamacs). Though I would not disagree with the > statement that it may take a while to get used to it. > > > > --- > > Alex > > > >> On Jan 16, 2015, at 9:27 AM, Davide Pesavento > wrote: > >> > >> I use Qt Creator on Linux > >> (http://qt-project.org/wiki/Category:Tools::QtCreator). > >> > >> Although centered around Qt development, it works perfectly fine on > >> plain C++ projects (as a matter of fact there's a project template for > >> non-Qt applications), and it's very fast and lightweight. > >> > >> I suggest using a recent version, for improved C++11 support. Ubuntu > >> packages are somewhat outdated though... fortunately upstream provides > >> binaries for all three major desktop platforms: > >> http://www.qt.io/download-open-source/#section-6 > >> > >> Best, > >> Davide > >> > >> On Fri, Jan 16, 2015 at 5:26 PM, Junxiao Shi > >> wrote: > >>> Dear folks > >>> > >>> There's no official IDE for NFD code base. > >>> I personally use pluma on LinuxMint, or gedit on Ubuntu. > >>> > >>> Code style is documented at > >>> http://redmine.named-data.net/projects/nfd/wiki/CodeStyle > >>> If you are using an IDE, configure it to conform to this code style. > >>> "My IDE automatically changes code into XYZ style" is not an excuse of > not > >>> conforming to code style. > >>> > >>> Yours, Junxiao > >>> > >>> On Fri, Jan 16, 2015 at 4:34 AM, Ivan Yeo wrote: > >>>> > >>>> Also, I wanted to check with you: When you guys work with the NFD code > >>>> base, do you use an IDE like Xcode? Or do you do straight from Emacs? > >>> > >>> > >>> _______________________________________________ > >>> Nfd-dev mailing list > >>> Nfd-dev at lists.cs.ucla.edu > >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > >>> > >> _______________________________________________ > >> Nfd-dev mailing list > >> Nfd-dev at lists.cs.ucla.edu > >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > > _______________________________________________ > > Nfd-dev mailing list > > Nfd-dev at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Tue Mar 3 21:58:56 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Tue, 3 Mar 2015 21:58:56 -0800 Subject: [Nfd-dev] NFD/ndn-cxx 0.3.1 released Message-ID: <12E58E77-2BDC-4477-ABEF-924D6BA27B7A@ucla.edu> Dear all, We are pleased to announce release of version 0.3.1 of Named Data Networking Forwarding Daemon (NFD) and ndn-cxx library. The detailed release notes: - for NFD: http://named-data.net/doc/NFD/0.3.1/RELEASE_NOTES.html - for ndn-cxx library: http://named-data.net/doc/ndn-cxx/0.3.1/RELEASE_NOTES.html More details about NFD, tutorials, HOWTOs, a FAQ and other useful resources are available on official webpages of NFD and ndn-cxx: - http://named-data.net/doc/NFD/0.3.1/ - http://named-data.net/doc/ndn-cxx/0.3.1/ * * * The NFD Team: Alex Afanasyev, Junxiao Shi, Beichuan Zhang, Lixia Zhang, Ilya Moiseenko, Yingdi Yu, Wentao Shang, Yi Huang, Spyridon Mastorakis, Jerald Paul Abraham, Steve DiBenedetto, Chengyu Fan, Christos Papadopoulos, Davide Pesavento, Giulio Grassi, Giovanni Pau, Hang Zhang, Tian Song, Haowei Yuan, Hila Ben Abraham, Patrick Crowley, Syed Obaid Amin, Vince Lehman, Minsheng Zhang, Lan Wang From dibenede at cs.colostate.edu Thu Mar 5 10:01:31 2015 From: dibenede at cs.colostate.edu (Steve DiBenedetto) Date: Thu, 5 Mar 2015 11:01:31 -0700 Subject: [Nfd-dev] problem getting started with NFD 0.3.1 binaries Message-ID: Hi all, I have a brand new Ubuntu 14.04 VM and I'm trying to install the 0.3.1 release from the ppa. I'm following the instructions from http://named-data.net/doc/NFD/current/INSTALL.html and everything seems to have installed ok. I do a quick nfd-stop and nfd-start for good measure. However, when I run nfd-status I get: ERROR: error while connecting to the forwarder (Connection refused) The 0.3.1 source installation seems to work ok. Is there something wrong on my end or with the ubuntu packages? -Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdd at wustl.edu Thu Mar 5 10:43:31 2015 From: jdd at wustl.edu (Dehart, John) Date: Thu, 5 Mar 2015 18:43:31 +0000 Subject: [Nfd-dev] problem getting started with NFD 0.3.1 binaries In-Reply-To: References: Message-ID: <835A6C0D-35A0-4A4D-9E45-1527003A11B9@wustl.edu> Steve, Some things to check: 1. Is nfd actually running? 2. What does the nfd log file say? Its possible the nfd.conf file is not quite right. I just upgraded all the Testbed nodes (a couple are 14.04) but didn?t use the new config file. I used a new one I had already crafted for the Testbed. When I didn?t put that one it nfd would not run properly with my older nfd.conf file. If you want to compare what you have with what is on the Testbed take a look at the CSU nodes /etc/ndn/nfd.conf. John On Mar 5, 2015, at 12:01 PM, Steve DiBenedetto > wrote: Hi all, I have a brand new Ubuntu 14.04 VM and I'm trying to install the 0.3.1 release from the ppa. I'm following the instructions from http://named-data.net/doc/NFD/current/INSTALL.html and everything seems to have installed ok. I do a quick nfd-stop and nfd-start for good measure. However, when I run nfd-status I get: ERROR: error while connecting to the forwarder (Connection refused) The 0.3.1 source installation seems to work ok. Is there something wrong on my end or with the ubuntu packages? -Steve _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From dibenede at cs.colostate.edu Thu Mar 5 11:17:22 2015 From: dibenede at cs.colostate.edu (Steve DiBenedetto) Date: Thu, 5 Mar 2015 12:17:22 -0700 Subject: [Nfd-dev] problem getting started with NFD 0.3.1 binaries In-Reply-To: <835A6C0D-35A0-4A4D-9E45-1527003A11B9@wustl.edu> References: <835A6C0D-35A0-4A4D-9E45-1527003A11B9@wustl.edu> Message-ID: On Thu, Mar 5, 2015 at 11:43 AM, Dehart, John wrote: > > Steve, > > Some things to check: > > 1. Is nfd actually running? > I'm not sure, but leaning towards no. nfd-start mentions a process ID, but grepping ps -eaf/aux doesn't turn up anything nfd related. Running nfd-start 2 times in a row produces "start: Job is already running: nfd". > > 2. What does the nfd log file say? > ...and here's why: 1425578496.311558 FATAL: [NFD] Error in setting interest filter (/localhost/nfd/rib): Unauthorized command > > Its possible the nfd.conf file is not quite right. I just upgraded all > the Testbed nodes (a couple are 14.04) but didn?t > use the new config file. I used a new one I had already crafted for the > Testbed. When I didn?t put that > one it nfd would not run properly with my older nfd.conf file. > > If you want to compare what you have with what is on the Testbed take a > look at the CSU nodes /etc/ndn/nfd.conf. > Using the CSU node's nfd.conf: 1425578900.973334 FATAL: [NFD] Cannot read certificate from file: /etc/ndn/keys/default.ndncert NFD is correct. There is no /etc/ndn/keys directory. I do see a /etc/ndn/certs directory that contains localhost_daemons_nrd.ndncert. > > On Mar 5, 2015, at 12:01 PM, Steve DiBenedetto < > dibenede at cs.colostate.edu> wrote: > > Hi all, > > I have a brand new Ubuntu 14.04 VM and I'm trying to install the 0.3.1 > release from the ppa. I'm following the instructions from > http://named-data.net/doc/NFD/current/INSTALL.html and everything seems > to have installed ok. > > I do a quick nfd-stop and nfd-start for good measure. However, when I > run nfd-status I get: > > ERROR: error while connecting to the forwarder (Connection refused) > > The 0.3.1 source installation seems to work ok. Is there something wrong > on my end or with the ubuntu packages? > > -Steve > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Thu Mar 5 11:26:35 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Thu, 5 Mar 2015 11:26:35 -0800 Subject: [Nfd-dev] problem getting started with NFD 0.3.1 binaries In-Reply-To: References: <835A6C0D-35A0-4A4D-9E45-1527003A11B9@wustl.edu> Message-ID: > On Mar 5, 2015, at 11:17 AM, Steve DiBenedetto wrote: > > > > On Thu, Mar 5, 2015 at 11:43 AM, Dehart, John > wrote: > > Steve, > > Some things to check: > > 1. Is nfd actually running? > > I'm not sure, but leaning towards no. nfd-start mentions a process ID, but grepping ps -eaf/aux doesn't turn up anything nfd related. Running nfd-start 2 times in a row produces "start: Job is already running: nfd". > > > 2. What does the nfd log file say? > > ...and here's why: > > 1425578496.311558 FATAL: [NFD] Error in setting interest filter (/localhost/nfd/rib): Unauthorized command > > > Its possible the nfd.conf file is not quite right. I just upgraded all the Testbed nodes (a couple are 14.04) but didn?t > use the new config file. I used a new one I had already crafted for the Testbed. When I didn?t put that > one it nfd would not run properly with my older nfd.conf file. > > If you want to compare what you have with what is on the Testbed take a look at the CSU nodes /etc/ndn/nfd.conf. > > Using the CSU node's nfd.conf: > > 1425578900.973334 FATAL: [NFD] Cannot read certificate from file: /etc/ndn/keys/default.ndncert > > NFD is correct. There is no /etc/ndn/keys directory. I do see a /etc/ndn/certs directory that contains localhost_daemons_nrd.ndncert. I think this is the reason. Since the last time, we changed nrd/nfd to be the same process. I may have screwed up with initial configuration in PPA? (I think i forgot to update it properly to handle this). If you allow anybody to work with FIB, then you would have your current issue solved. ? Alex > > > > On Mar 5, 2015, at 12:01 PM, Steve DiBenedetto > wrote: > >> Hi all, >> >> I have a brand new Ubuntu 14.04 VM and I'm trying to install the 0.3.1 release from the ppa. I'm following the instructions from http://named-data.net/doc/NFD/current/INSTALL.html and everything seems to have installed ok. >> >> I do a quick nfd-stop and nfd-start for good measure. However, when I run nfd-status I get: >> >> ERROR: error while connecting to the forwarder (Connection refused) >> >> The 0.3.1 source installation seems to work ok. Is there something wrong on my end or with the ubuntu packages? >> >> -Steve >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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 ivanyeo at CS.UCLA.EDU Thu Mar 5 20:37:35 2015 From: ivanyeo at CS.UCLA.EDU (Ivan Yeo) Date: Thu, 05 Mar 2015 20:37:35 -0800 Subject: [Nfd-dev] IDE for working with NFD code base In-Reply-To: References: <218086B7-1266-4DED-AF71-09C1C3D11F96@ucla.edu> Message-ID: <54F92F0F.60600@cs.ucla.edu> Cool stuff! Thanks for the heads up :) Haven't used that in awhile, but I'm usually just navigating the code base and figuring stuff out. Right now I'm good with using Vim for reading purposes. Cheers, Ivan On 03/03/2015 11:02 AM, Syed Obaid Amin wrote: > Hello all, > > Though it's an old thread but the information might be helpful. I > recently came across Code::Blocks (http://www.codeblocks.org/) and it > seems like a decent IDE, lightweight and full with features. It's > available for major three platform (Mac/Linux/Win). On Ubuntu it is > also available on Software Center. > > Regards, > Obaid > > On Sat, Jan 17, 2015 at 8:14 PM, Ivan Yeo > wrote: > > Hi all, > > Thanks for the response, I really appreciate it. Have a great weekend! > > Cheers, > Ivan > > > On Jan 17, 2015, at 11:37 AM, Alex Afanasyev > > wrote: > > > > I'm using Emacs (aquamacs). Though I would not disagree with > the statement that it may take a while to get used to it. > > > > --- > > Alex > > > >> On Jan 16, 2015, at 9:27 AM, Davide Pesavento > > wrote: > >> > >> I use Qt Creator on Linux > >> (http://qt-project.org/wiki/Category:Tools::QtCreator). > >> > >> Although centered around Qt development, it works perfectly fine on > >> plain C++ projects (as a matter of fact there's a project > template for > >> non-Qt applications), and it's very fast and lightweight. > >> > >> I suggest using a recent version, for improved C++11 support. > Ubuntu > >> packages are somewhat outdated though... fortunately upstream > provides > >> binaries for all three major desktop platforms: > >> http://www.qt.io/download-open-source/#section-6 > >> > >> Best, > >> Davide > >> > >> On Fri, Jan 16, 2015 at 5:26 PM, Junxiao Shi > >> > wrote: > >>> Dear folks > >>> > >>> There's no official IDE for NFD code base. > >>> I personally use pluma on LinuxMint, or gedit on Ubuntu. > >>> > >>> Code style is documented at > >>> http://redmine.named-data.net/projects/nfd/wiki/CodeStyle > >>> If you are using an IDE, configure it to conform to this code > style. > >>> "My IDE automatically changes code into XYZ style" is not an > excuse of not > >>> conforming to code style. > >>> > >>> Yours, Junxiao > >>> > >>> On Fri, Jan 16, 2015 at 4:34 AM, Ivan Yeo > wrote: > >>>> > >>>> Also, I wanted to check with you: When you guys work with the > NFD code > >>>> base, do you use an IDE like Xcode? Or do you do straight > from Emacs? > >>> > >>> > >>> _______________________________________________ > >>> Nfd-dev mailing list > >>> Nfd-dev at lists.cs.ucla.edu > >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > >>> > >> _______________________________________________ > >> Nfd-dev mailing list > >> Nfd-dev at lists.cs.ucla.edu > >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > > _______________________________________________ > > Nfd-dev mailing list > > Nfd-dev at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdd at wustl.edu Fri Mar 6 12:46:44 2015 From: jdd at wustl.edu (Dehart, John) Date: Fri, 6 Mar 2015 20:46:44 +0000 Subject: [Nfd-dev] ndnping RTT investigation Message-ID: <0AF9F99D-04F0-40AA-A65E-44E36997CB7E@wustl.edu> All: We have been noticing odd spikes in ndnping RTTs and have been trying to track down the root cause of it. I believe I have narrowed it down to an interaction between the ndnping Interests and the Interests we send out to collect data from nfd for the ndnmap.arl.wustl.edu bandwidth display. I have some very specific data now on something strange that is happening with nfd. I include a portion of the combined log files from nfd and an ndndump I was running on the WU Testbed node at the time of such a spike. The ndnping in question has a reference number of: 1744606568 I have modified the log messages to insert ?nfd? and ?ndndump? to help keep straight which messages are from which log. Please note that this is all from the WU Testbed node so the times should be directly comparable. At time 1425669071.230902 , nfd performs a " [ContentStore] find /localhost/nfd/faces/list R? but it doesn?t register " [ContentStore] no-match? until 1425669071.253650, which is 22.748 ms later. There were NO nfd log messages in between. During that time, ndndump registers the arrival of 7 new Interests. >From this it would appear that the search of the CS took over 22.748 ms. At this point, the CS is full. I am analyzing a fuller log of the ContentStore messages and what I am finding is that the ?find ? R? lookups that come back no-match are taking longer as the CS fills up. The ?find ? L? lookups also are increasing in time but they seem to max out at around 2 or 3 ms. What is going on with the ?find ? R? lookups? John 1425669071.226706 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3582782466 1425669071.226759 nfd DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186 1425669071.227090 nfd DEBUG: [ContentStore] find /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186 L 1425669071.229658 nfd DEBUG: [ContentStore] no-match 1425669071.229736 nfd DEBUG: [AccessStrategy] /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3582782466 interestFrom 266 new-interest mi=/ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173 1425669071.230136 nfd DEBUG: [AccessStrategy] /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3582782466 interestTo 269 last-nexthop rto=111227 1425669071.230395 nfd DEBUG: [Forwarder] onOutgoingInterest face=269 interest=/ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186 1425669071.230794 nfd DEBUG: [Forwarder] onIncomingInterest face=269 interest=/localhost/nfd/faces/list 1425669071.230902 nfd DEBUG: [ContentStore] find /localhost/nfd/faces/list R 1425669071.231738 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2821820197 1425669071.236867 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/arizona/ndnmap/stats/192.172.226.248/129.82.138.48/141.225.11.173/133.9.73.66/128.187.81.12?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2335882350 1425669071.241170 ndndump From: 172.16.21.176, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/wustl/ping/1744606568?ndn.MustBeFresh=1&ndn.Nonce=1744606568 1425669071.241297 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/org/caida/ndnmap/stats/128.195.4.36/202.120.188.176?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2532105913 1425669071.244815 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/ch/unibas/ndnmap/stats/193.147.51.186/162.105.146.26/137.194.54.81?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3200941563 1425669071.249054 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/cn/edu/pku/ndnmap/stats/202.120.188.176/114.247.165.44?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=338471191 1425669071.253186 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/neu/ndnmap/stats/162.105.146.26?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=763898399 1425669071.253650 nfd DEBUG: [ContentStore] no-match 1425669071.253702 nfd DEBUG: [Forwarder] onOutgoingInterest face=1 interest=/localhost/nfd/faces/list 1425669071.253788 nfd DEBUG: [BestRouteStrategy2] /localhost/nfd/faces/list?ndn.ChildSelector=1&ndn.MustBeFresh=1&ndn.Nonce=2666790337 from=269 newPitEntry-to=1 1425669071.253909 nfd DEBUG: [InternalFace] received Interest: /localhost/nfd/faces/list 1425669071.253986 nfd DEBUG: [InternalFace] found Interest filter for /localhost/nfd/faces (previous match) 1425669071.254052 nfd DEBUG: [FaceManager] command result: processing verb: list 1425669071.257714 nfd DEBUG: [Forwarder] onIncomingData face=1 data=/localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00 1425669071.257882 nfd DEBUG: [ContentStore] insert /localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00 1425669071.258040 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/it/unipd/ndnmap/stats/72.36.112.82/192.43.193.111/193.147.51.186/161.105.195.18?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=738760142 1425669071.258043 nfd DEBUG: [Forwarder] onIncomingData matching=/localhost/nfd/faces/list 1425669071.258123 nfd DEBUG: [Strategy] beforeSatisfyInterest pitEntry=/localhost/nfd/faces/list inFace=1 data=/localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00 1425669071.258333 nfd DEBUG: [Forwarder] onOutgoingData face=269 data=/localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00 1425669071.258514 nfd DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36 1425669071.258815 nfd DEBUG: [ContentStore] find /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36 L 1425669071.261579 nfd DEBUG: [ContentStore] no-match 1425669071.261652 nfd DEBUG: [Forwarder] onOutgoingInterest face=260 interest=/ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36 1425669071.261920 ndndump From: 128.252.153.194, To: 72.36.112.82, Tunnel Type: UDP, INTEREST: /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2821820197 1425669071.261945 nfd DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2821820197 from=266 newPitEntry-to=260 1425669071.262232 nfd DEBUG: [Forwarder] onIncomingInterest face=303 interest=/ndn/edu/wustl/ping/1744606568 From lanwang at memphis.edu Mon Mar 9 08:54:26 2015 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Mon, 9 Mar 2015 15:54:26 +0000 Subject: [Nfd-dev] ndnping RTT investigation In-Reply-To: <0AF9F99D-04F0-40AA-A65E-44E36997CB7E@wustl.edu> References: <0AF9F99D-04F0-40AA-A65E-44E36997CB7E@wustl.edu> Message-ID: <8BDE8B91-0FF2-4B35-92D2-4343B4B4C613@memphis.edu> Junxiao: Do you have some idea of what's causing the long delay in the find?R lookup? ------- John: I'm just wondering, if the CS being full is related to the long search delay of find?R lookup, then wouldn't this happen all the time after the CS is full rather than periodically like what you observed? Lan On Mar 6, 2015, at 2:46 PM, "Dehart, John" wrote: > > All: > > We have been noticing odd spikes in ndnping RTTs and have been trying to track down the root cause of it. > > I believe I have narrowed it down to an interaction between the ndnping Interests and the Interests we send out to collect data > from nfd for the ndnmap.arl.wustl.edu bandwidth display. > > I have some very specific data now on something strange that is happening with nfd. > > I include a portion of the combined log files from nfd and an ndndump I was running on the WU Testbed node > at the time of such a spike. The ndnping in question has a reference number of: 1744606568 > I have modified the log messages to insert ?nfd? and ?ndndump? to help keep straight which messages > are from which log. Please note that this is all from the WU Testbed node so the times should be > directly comparable. > > At time 1425669071.230902 , nfd performs a " [ContentStore] find /localhost/nfd/faces/list R? > but it doesn?t register " [ContentStore] no-match? until 1425669071.253650, which is > 22.748 ms later. There were NO nfd log messages in between. > During that time, ndndump registers the arrival of 7 new Interests. > > From this it would appear that the search of the CS took over 22.748 ms. > At this point, the CS is full. I am analyzing a fuller log of the ContentStore messages > and what I am finding is that the ?find ? R? lookups that come back no-match are > taking longer as the CS fills up. > The ?find ? L? lookups also are increasing in time but they seem to max out at around 2 or 3 ms. > > What is going on with the ?find ? R? lookups? > > John > > > 1425669071.226706 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3582782466 > 1425669071.226759 nfd DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186 > 1425669071.227090 nfd DEBUG: [ContentStore] find /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186 L > 1425669071.229658 nfd DEBUG: [ContentStore] no-match > 1425669071.229736 nfd DEBUG: [AccessStrategy] /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3582782466 interestFrom 266 new-interest mi=/ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173 > 1425669071.230136 nfd DEBUG: [AccessStrategy] /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3582782466 interestTo 269 last-nexthop rto=111227 > 1425669071.230395 nfd DEBUG: [Forwarder] onOutgoingInterest face=269 interest=/ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186 > 1425669071.230794 nfd DEBUG: [Forwarder] onIncomingInterest face=269 interest=/localhost/nfd/faces/list > 1425669071.230902 nfd DEBUG: [ContentStore] find /localhost/nfd/faces/list R > 1425669071.231738 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2821820197 > 1425669071.236867 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/arizona/ndnmap/stats/192.172.226.248/129.82.138.48/141.225.11.173/133.9.73.66/128.187.81.12?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2335882350 > 1425669071.241170 ndndump From: 172.16.21.176, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/wustl/ping/1744606568?ndn.MustBeFresh=1&ndn.Nonce=1744606568 > 1425669071.241297 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/org/caida/ndnmap/stats/128.195.4.36/202.120.188.176?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2532105913 > 1425669071.244815 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/ch/unibas/ndnmap/stats/193.147.51.186/162.105.146.26/137.194.54.81?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3200941563 > 1425669071.249054 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/cn/edu/pku/ndnmap/stats/202.120.188.176/114.247.165.44?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=338471191 > 1425669071.253186 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/neu/ndnmap/stats/162.105.146.26?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=763898399 > 1425669071.253650 nfd DEBUG: [ContentStore] no-match > 1425669071.253702 nfd DEBUG: [Forwarder] onOutgoingInterest face=1 interest=/localhost/nfd/faces/list > 1425669071.253788 nfd DEBUG: [BestRouteStrategy2] /localhost/nfd/faces/list?ndn.ChildSelector=1&ndn.MustBeFresh=1&ndn.Nonce=2666790337 from=269 newPitEntry-to=1 > 1425669071.253909 nfd DEBUG: [InternalFace] received Interest: /localhost/nfd/faces/list > 1425669071.253986 nfd DEBUG: [InternalFace] found Interest filter for /localhost/nfd/faces (previous match) > 1425669071.254052 nfd DEBUG: [FaceManager] command result: processing verb: list > 1425669071.257714 nfd DEBUG: [Forwarder] onIncomingData face=1 data=/localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00 > 1425669071.257882 nfd DEBUG: [ContentStore] insert /localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00 > 1425669071.258040 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/it/unipd/ndnmap/stats/72.36.112.82/192.43.193.111/193.147.51.186/161.105.195.18?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=738760142 > 1425669071.258043 nfd DEBUG: [Forwarder] onIncomingData matching=/localhost/nfd/faces/list > 1425669071.258123 nfd DEBUG: [Strategy] beforeSatisfyInterest pitEntry=/localhost/nfd/faces/list inFace=1 data=/localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00 > 1425669071.258333 nfd DEBUG: [Forwarder] onOutgoingData face=269 data=/localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00 > 1425669071.258514 nfd DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36 > 1425669071.258815 nfd DEBUG: [ContentStore] find /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36 L > 1425669071.261579 nfd DEBUG: [ContentStore] no-match > 1425669071.261652 nfd DEBUG: [Forwarder] onOutgoingInterest face=260 interest=/ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36 > 1425669071.261920 ndndump From: 128.252.153.194, To: 72.36.112.82, Tunnel Type: UDP, INTEREST: /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2821820197 > 1425669071.261945 nfd DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2821820197 from=266 newPitEntry-to=260 > 1425669071.262232 nfd DEBUG: [Forwarder] onIncomingInterest face=303 interest=/ndn/edu/wustl/ping/1744606568 > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From jdd at wustl.edu Mon Mar 9 09:16:31 2015 From: jdd at wustl.edu (Dehart, John) Date: Mon, 9 Mar 2015 16:16:31 +0000 Subject: [Nfd-dev] ndnping RTT investigation In-Reply-To: <8BDE8B91-0FF2-4B35-92D2-4343B4B4C613@memphis.edu> References: <0AF9F99D-04F0-40AA-A65E-44E36997CB7E@wustl.edu> <8BDE8B91-0FF2-4B35-92D2-4343B4B4C613@memphis.edu> Message-ID: <152BED44-EC6B-4499-BE40-C59FB4F63BB8@wustl.edu> Lan, I have started a redmine issue on this: http://redmine.named-data.net/issues/2626 John On Mar 9, 2015, at 10:54 AM, Lan Wang (lanwang) wrote: > Junxiao: Do you have some idea of what's causing the long delay in the find?R lookup? > ------- > > John: I'm just wondering, if the CS being full is related to the long search delay of find?R lookup, then wouldn't this happen all the time after the CS is full rather than periodically like what you observed? > > Lan > > On Mar 6, 2015, at 2:46 PM, "Dehart, John" wrote: > >> >> All: >> >> We have been noticing odd spikes in ndnping RTTs and have been trying to track down the root cause of it. >> >> I believe I have narrowed it down to an interaction between the ndnping Interests and the Interests we send out to collect data >> from nfd for the ndnmap.arl.wustl.edu bandwidth display. >> >> I have some very specific data now on something strange that is happening with nfd. >> >> I include a portion of the combined log files from nfd and an ndndump I was running on the WU Testbed node >> at the time of such a spike. The ndnping in question has a reference number of: 1744606568 >> I have modified the log messages to insert ?nfd? and ?ndndump? to help keep straight which messages >> are from which log. Please note that this is all from the WU Testbed node so the times should be >> directly comparable. >> >> At time 1425669071.230902 , nfd performs a " [ContentStore] find /localhost/nfd/faces/list R? >> but it doesn?t register " [ContentStore] no-match? until 1425669071.253650, which is >> 22.748 ms later. There were NO nfd log messages in between. >> During that time, ndndump registers the arrival of 7 new Interests. >> >> From this it would appear that the search of the CS took over 22.748 ms. >> At this point, the CS is full. I am analyzing a fuller log of the ContentStore messages >> and what I am finding is that the ?find ? R? lookups that come back no-match are >> taking longer as the CS fills up. >> The ?find ? L? lookups also are increasing in time but they seem to max out at around 2 or 3 ms. >> >> What is going on with the ?find ? R? lookups? >> >> John >> >> >> 1425669071.226706 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3582782466 >> 1425669071.226759 nfd DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186 >> 1425669071.227090 nfd DEBUG: [ContentStore] find /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186 L >> 1425669071.229658 nfd DEBUG: [ContentStore] no-match >> 1425669071.229736 nfd DEBUG: [AccessStrategy] /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3582782466 interestFrom 266 new-interest mi=/ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173 >> 1425669071.230136 nfd DEBUG: [AccessStrategy] /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3582782466 interestTo 269 last-nexthop rto=111227 >> 1425669071.230395 nfd DEBUG: [Forwarder] onOutgoingInterest face=269 interest=/ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186 >> 1425669071.230794 nfd DEBUG: [Forwarder] onIncomingInterest face=269 interest=/localhost/nfd/faces/list >> 1425669071.230902 nfd DEBUG: [ContentStore] find /localhost/nfd/faces/list R >> 1425669071.231738 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2821820197 >> 1425669071.236867 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/arizona/ndnmap/stats/192.172.226.248/129.82.138.48/141.225.11.173/133.9.73.66/128.187.81.12?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2335882350 >> 1425669071.241170 ndndump From: 172.16.21.176, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/wustl/ping/1744606568?ndn.MustBeFresh=1&ndn.Nonce=1744606568 >> 1425669071.241297 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/org/caida/ndnmap/stats/128.195.4.36/202.120.188.176?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2532105913 >> 1425669071.244815 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/ch/unibas/ndnmap/stats/193.147.51.186/162.105.146.26/137.194.54.81?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3200941563 >> 1425669071.249054 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/cn/edu/pku/ndnmap/stats/202.120.188.176/114.247.165.44?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=338471191 >> 1425669071.253186 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/neu/ndnmap/stats/162.105.146.26?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=763898399 >> 1425669071.253650 nfd DEBUG: [ContentStore] no-match >> 1425669071.253702 nfd DEBUG: [Forwarder] onOutgoingInterest face=1 interest=/localhost/nfd/faces/list >> 1425669071.253788 nfd DEBUG: [BestRouteStrategy2] /localhost/nfd/faces/list?ndn.ChildSelector=1&ndn.MustBeFresh=1&ndn.Nonce=2666790337 from=269 newPitEntry-to=1 >> 1425669071.253909 nfd DEBUG: [InternalFace] received Interest: /localhost/nfd/faces/list >> 1425669071.253986 nfd DEBUG: [InternalFace] found Interest filter for /localhost/nfd/faces (previous match) >> 1425669071.254052 nfd DEBUG: [FaceManager] command result: processing verb: list >> 1425669071.257714 nfd DEBUG: [Forwarder] onIncomingData face=1 data=/localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00 >> 1425669071.257882 nfd DEBUG: [ContentStore] insert /localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00 >> 1425669071.258040 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/it/unipd/ndnmap/stats/72.36.112.82/192.43.193.111/193.147.51.186/161.105.195.18?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=738760142 >> 1425669071.258043 nfd DEBUG: [Forwarder] onIncomingData matching=/localhost/nfd/faces/list >> 1425669071.258123 nfd DEBUG: [Strategy] beforeSatisfyInterest pitEntry=/localhost/nfd/faces/list inFace=1 data=/localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00 >> 1425669071.258333 nfd DEBUG: [Forwarder] onOutgoingData face=269 data=/localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00 >> 1425669071.258514 nfd DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36 >> 1425669071.258815 nfd DEBUG: [ContentStore] find /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36 L >> 1425669071.261579 nfd DEBUG: [ContentStore] no-match >> 1425669071.261652 nfd DEBUG: [Forwarder] onOutgoingInterest face=260 interest=/ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36 >> 1425669071.261920 ndndump From: 128.252.153.194, To: 72.36.112.82, Tunnel Type: UDP, INTEREST: /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2821820197 >> 1425669071.261945 nfd DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2821820197 from=266 newPitEntry-to=260 >> 1425669071.262232 nfd DEBUG: [Forwarder] onIncomingInterest face=303 interest=/ndn/edu/wustl/ping/1744606568 >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From shijunxiao at email.arizona.edu Wed Mar 11 00:39:04 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 11 Mar 2015 00:39:04 -0700 Subject: [Nfd-dev] ndn-cxx feature deprecation: Block::fromBuffer overloads with output parameter In-Reply-To: References: Message-ID: Dear folks Deadline has passed. Since there's no objection before the deadline, the Change of adding DEPRECATED marker should be merged without further waiting. It's important to merge now, because this can prevent projects to introduce new usages of deprecated overloads, which would require extra work of fixing them. Yours, Junxiao On Feb 28, 2015 11:08 PM, "Junxiao Shi" wrote: > Dear folks > > The following items are deprecated in ndn-cxx: > > - bool Block::fromBuffer(const ConstBufferPtr&, size_t, Block&) > - bool Block::fromBuffer(const uint8_t*, size_t, Block&) > > If you have code that uses any of those features, please migrate to the > new syntax as described in Doxygen. > > I will add DEPRECATED macro onto those items soon, but that Change won't > merge until after Mar 08 12:00 UTC. > This means compiler will produce a warning whenever they are used. If your > project uses "-Werror" flag, this would become an error. > Try compiling your projects with http://gerrit.named-data.net/1822 to see > what happens. > > Those deprecated items will be deleted in v0.5. > > Yours, Junxiao > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Mar 11 11:47:35 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 11 Mar 2015 11:47:35 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> Message-ID: Hi Xiaoke Thanks for your examples. However, I need to start from scratch. Suppose: - root/site/user certificates are created according to http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000616.html - Two machines have NDNS package installed. One is to host root zone, the other is to host site1 zone. I need the commands to: - create root zone: /example - publish root certificate: /example/KEY/ksk-1/ID-CERT - create site zone: /example/site1 - delegate site zone from root zone - publish site certificate: /example/KEY/site-1/ksk-2/ID-CERT (should this be published at root zone or site1 zone?) - publish user certificate: /example/site1/KEY/user1/ksk-3/ID-CERT Yours, Junxiao On Wed, Mar 11, 2015 at 11:39 AM, Xiaoke Jiang wrote: > Hi Junxiao, > There are two ways to insert a certificate into NDNS, one is to embed it > in update message and deliver it to name server, and the other is calling > management tool to modify the local database directly. > I present an example to show the two ways, assume the certificate is > named > /ndn/edu/ucla/KEY/bob/dsk-1420913151451/ID-CERT/%FD%00%00%01J%D5%06%0F%C8, > and stored in the local file ndn.edu.ucla.bob.cert > 1) sending update message locally or remotely: ndns-update -f ndn.edu > .ucla.bob.cert > 2) calling management tool locally: ndns-add-rr-from-file /ndn/edu/ucla -f > ndn.edu.ucla.bob.cert > > And the management tools that remove it is: ndns-remove-rr /ndn/edu/ucla > /bob/dsk-1420913151451 ID-CERT. > As to remove it remotely, authorized party should send a update message > embedding a NDNS-NACK with the same name prefix but greater version number. > > Note that the certificates issued by NDN Testbed is automatically stored > in the NDNS instance hosted on the testbed. > > Xiaoke (Shock) > On Mon, Mar 2, 2015 at 4:37 PM, Junxiao Shi wrote: > I still want to hear about how ndns could be used to publish those > certificates. > Xiaoke can you answer? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Mar 11 11:55:57 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 11 Mar 2015 11:55:57 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> Message-ID: Hi Xiaoke/Jiewen (correcting a typo below) Thanks for your examples. However, I need to start from scratch. Suppose: - root/site/user certificates are created according to http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000616.html - Two machines have NDNS package installed. One is to host root zone, the other is to host site1 zone. I need the commands to: - create root zone: /example - publish root certificate: /example/KEY/ksk-1/ID-CERT - create site1 zone: /example/site1 - delegate site1 zone from root zone - publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT (should this be published at root zone or site1 zone?) - publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT Yours, Junxiao On Wed, Mar 11, 2015 at 11:39 AM, Xiaoke Jiang wrote: > Hi Junxiao, > There are two ways to insert a certificate into NDNS, one is to embed it > in update message and deliver it to name server, and the other is calling > management tool to modify the local database directly. > I present an example to show the two ways, assume the certificate is > named > /ndn/edu/ucla/KEY/bob/dsk-1420913151451/ID-CERT/%FD%00%00%01J%D5%06%0F%C8, > and stored in the local file ndn.edu.ucla.bob.cert > 1) sending update message locally or remotely: ndns-update -f ndn.edu > .ucla.bob.cert > 2) calling management tool locally: ndns-add-rr-from-file /ndn/edu/ucla -f > ndn.edu.ucla.bob.cert > > And the management tools that remove it is: ndns-remove-rr /ndn/edu/ucla > /bob/dsk-1420913151451 ID-CERT. > As to remove it remotely, authorized party should send a update message > embedding a NDNS-NACK with the same name prefix but greater version number. > > Note that the certificates issued by NDN Testbed is automatically stored > in the NDNS instance hosted on the testbed. > > Xiaoke (Shock) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanwake at ucla.edu Wed Mar 11 12:48:00 2015 From: alanwake at ucla.edu (Jiewen Tan) Date: Wed, 11 Mar 2015 12:48:00 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> Message-ID: <007501d05c34$48aebb90$da0c32b0$@ucla.edu> Hi Junxiao, Assuming the root key and root certificate are already presented in the system(PIB), 1) Create root zone: /example a. ndns-create-zone /example -k /example/KEY/ksk-1/ID-CERT Here is to create a zone named /example using a KSK store in the PIB. It will also generate a DSK signed by the KSK provided automatically and insert the DSK to NDNS database (publish). All other options are set to default. 2) Publish root certificate: /example/KEY/ksk-1/ID-CERT a. ndns-export-certificate /example/KEY/ksk-1/ID-CERT Here is to export the root certificate to stdout. It can be exported to a file by using -f option as well. b. ndns-add-rr-from-file /example Here is to insert the root certificate into NDNS database (publish under zone /example). Default is to use stdin as input. So you can just copy&paste the output from 2.a. It will terminate with Ctrl+D. 3) Create site1 zone: /example/site1 a. ndns-create-zone /example/site1 Here, the tool will automatically generate a self-signed KSK and a corresponding DSK. Moreover, the DSK will be published automatically. 4) Delegate site1 zone from root zone a. ndns-add-rr -t resp /example /site1 NS Here is to add a rrset into zone: /example which has label: /site1 and type: /NS. Specifically, the content-type of the rrset is set to resp which indicate the existence of zone /example/site1. Now the delegation is completed. However, if the site zone is a leaf zone, a TXT type rrset is preferred. 5) Publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT (Site1?s KSK needs to be published in its parent zone, i.e. root zone.) a. ndns-export-certificate /example/KEY/site1/ksk-2/ID-CERT -f site1.cert Export the certificate from site1 zone. b. Pass the certificate to the parent zone, i.e. root zone here. (Use whatever methods you prefer) c. ndns-add-rr-from-file /example -f site1.cert Here the tool will resign the certificate with the zone?s DSK such that an authentication chain can be established. After that, it will publish the certificate in the NDNS database with label set to /site1/ksk-2 and type set to ID-CERT. 6) Publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT (Assuming it is stored as user1.cert) a. ndns-add-rr-from-file /example/site1 -f user1.cert Noticed again, this operation needs to be done in the parent zone, i.e. /example/site1. In NDNS, publishing a certificate is essentially meaning to insert the certificate into NDNS database as an ID-CERT rrset. Therefore, I use these two terms interchangeably here. Thank you for asking this question. I will try to make the answer as complete as possible and post this answer on the ndns-tr as appendix. BTW, Xiaoke please make any supplement to my explanation if necessary. Regards, Jiewen Tan From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu] Sent: Wednesday, March 11, 2015 11:56 AM To: Cc: Xiaoke Jiang; Jiewen Tan Subject: Re: [Nfd-dev] How to start a certificate chain from scratch Hi Xiaoke/Jiewen (correcting a typo below) Thanks for your examples. However, I need to start from scratch. Suppose: ? root/site/user certificates are created according to http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000616.html ? Two machines have NDNS package installed. One is to host root zone, the other is to host site1 zone. I need the commands to: ? create root zone: /example ? publish root certificate: /example/KEY/ksk-1/ID-CERT ? create site1 zone: /example/site1 ? delegate site1 zone from root zone ? publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT (should this be published at root zone or site1 zone?) ? publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT Yours, Junxiao On Wed, Mar 11, 2015 at 11:39 AM, Xiaoke Jiang wrote: Hi Junxiao, There are two ways to insert a certificate into NDNS, one is to embed it in update message and deliver it to name server, and the other is calling management tool to modify the local database directly. I present an example to show the two ways, assume the certificate is named /ndn/edu/ucla/KEY/bob/dsk-1420913151451/ID-CERT/%FD%00%00%01J%D5%06%0F%C8, and stored in the local file ndn.edu .ucla.bob.cert 1) sending update message locally or remotely: ndns-update -f ndn.edu .ucla.bob.cert 2) calling management tool locally: ndns-add-rr-from-file /ndn/edu/ucla -f ndn.edu.ucla.bob.cert And the management tools that remove it is: ndns-remove-rr /ndn/edu/ucla /bob/dsk-1420913151451 ID-CERT. As to remove it remotely, authorized party should send a update message embedding a NDNS-NACK with the same name prefix but greater version number. Note that the certificates issued by NDN Testbed is automatically stored in the NDNS instance hosted on the testbed. Xiaoke (Shock) -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Mar 11 13:18:39 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 11 Mar 2015 13:18:39 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: <007501d05c34$48aebb90$da0c32b0$@ucla.edu> References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> <007501d05c34$48aebb90$da0c32b0$@ucla.edu> Message-ID: Hi Jiewen The procedure your provided seems to be generating a new site1 key. It is possible to use an existing key pair as site1 key? It's okay to re-sign this existing key with root zone's DSK instead of KSK. Yours, Junxiao On Wed, Mar 11, 2015 at 12:48 PM, Jiewen Tan wrote: > Hi Junxiao, > > > > Assuming the root key and root certificate are already presented in the > system(PIB), > > 1) Create root zone: /example > > a. ndns-create-zone /example -k /example/KEY/ksk-1/ID-CERT > > Here is to create a zone named /example using a KSK store in the PIB. It > will also generate a DSK signed by the KSK provided automatically and > insert the DSK to NDNS database (publish). All other options are set to > default. > > 2) Publish root certificate: /example/KEY/ksk-1/ID-CERT > > a. ndns-export-certificate /example/KEY/ksk-1/ID-CERT > > Here is to export the root certificate to stdout. It can be exported to a > file by using -f option as well. > > b. ndns-add-rr-from-file /example > > Here is to insert the root certificate into NDNS database (publish under > zone /example). Default is to use stdin as input. So you can just > copy&paste the output from 2.a. It will terminate with Ctrl+D. > > 3) Create site1 zone: /example/site1 > > a. ndns-create-zone /example/site1 > > Here, the tool will automatically generate a self-signed KSK and a > corresponding DSK. Moreover, the DSK will be published automatically. > > 4) Delegate site1 zone from root zone > > a. ndns-add-rr -t resp /example /site1 NS > > Here is to add a rrset into zone: /example which has label: /site1 and > type: /NS. Specifically, the content-type of the rrset is set to resp which > indicate the existence of zone /example/site1. Now the delegation is > completed. However, if the site zone is a leaf zone, a TXT type rrset is > preferred. > > 5) Publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT > (Site1?s KSK needs to be published in its parent zone, i.e. root zone.) > > a. ndns-export-certificate /example/KEY/site1/ksk-2/ID-CERT -f > site1.cert > > Export the certificate from site1 zone. > > b. Pass the certificate to the parent zone, i.e. root zone here. > (Use whatever methods you prefer) > > c. ndns-add-rr-from-file /example -f site1.cert > > Here the tool will resign the certificate with the zone?s DSK such that an > authentication chain can be established. After that, it will publish the > certificate in the NDNS database with label set to /site1/ksk-2 and type > set to ID-CERT. > > 6) Publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT > (Assuming it is stored as user1.cert) > > a. ndns-add-rr-from-file /example/site1 -f user1.cert > > Noticed again, this operation needs to be done in the parent zone, i.e. > /example/site1. > > > > In NDNS, publishing a certificate is essentially meaning to insert the > certificate into NDNS database as an ID-CERT rrset. Therefore, I use these > two terms interchangeably here. > > > > Thank you for asking this question. I will try to make the answer as > complete as possible and post this answer on the ndns-tr as appendix. > > > > BTW, Xiaoke please make any supplement to my explanation if necessary. > > > > Regards, > > Jiewen Tan > > *From:* Junxiao Shi [mailto:shijunxiao at email.arizona.edu] > *Sent:* Wednesday, March 11, 2015 11:56 AM > *To:* > *Cc:* Xiaoke Jiang; Jiewen Tan > *Subject:* Re: [Nfd-dev] How to start a certificate chain from scratch > > > > Hi Xiaoke/Jiewen > > (correcting a typo below) > > > > Thanks for your examples. However, I need to start from scratch. Suppose: > > ? root/site/user certificates are created according to > http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000616.html > > ? Two machines have NDNS package installed. One is to host root zone, > the other is to host site1 zone. > > I need the commands to: > > ? create root zone: /example > > ? publish root certificate: /example/KEY/ksk-1/ID-CERT > > ? create site1 zone: /example/site1 > > ? delegate site1 zone from root zone > > ? publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT (should > this be published at root zone or site1 zone?) > > ? publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT > > > > Yours, Junxiao > > On Wed, Mar 11, 2015 at 11:39 AM, Xiaoke Jiang > wrote: > > Hi Junxiao, > > There are two ways to insert a certificate into NDNS, one is to embed it > in update message and deliver it to name server, and the other is calling > management tool to modify the local database directly. > > I present an example to show the two ways, assume the certificate is named > /ndn/edu/ucla/KEY/bob/dsk-1420913151451/ID-CERT/%FD%00%00%01J%D5%06%0F%C8, > and stored in the local file ndn.edu.ucla.bob.cert > > 1) sending update message locally or remotely: ndns-update -f ndn.edu > .ucla.bob.cert > > 2) calling management tool locally: ndns-add-rr-from-file /ndn/edu/ucla -f > ndn.edu.ucla.bob.cert > > > > And the management tools that remove it is: ndns-remove-rr /ndn/edu/ucla > /bob/dsk-1420913151451 ID-CERT. > > As to remove it remotely, authorized party should send a update message > embedding a NDNS-NACK with the same name prefix but greater version number. > > > > Note that the certificates issued by NDN Testbed is automatically stored > in the NDNS instance hosted on the testbed. > > > > Xiaoke (Shock) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanwake at ucla.edu Wed Mar 11 13:29:01 2015 From: alanwake at ucla.edu (Jiewen Tan) Date: Wed, 11 Mar 2015 13:29:01 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> <007501d05c34$48aebb90$da0c32b0$@ucla.edu> Message-ID: <009701d05c3a$03f06890$0bd139b0$@ucla.edu> Hi Junxiao, It is possible. For ndns-create-zone command, you can supply it with -k option to use an existing KSK and with -d option to use an existing DSK. In current authentication model, a KSK certificate is ought to be signed by a DSK of parent zone. Regards, Jiewen Tan From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu] Sent: Wednesday, March 11, 2015 1:19 PM To: Jiewen Tan Cc: ; Xiaoke Jiang Subject: Re: [Nfd-dev] How to start a certificate chain from scratch Hi Jiewen The procedure your provided seems to be generating a new site1 key. It is possible to use an existing key pair as site1 key? It's okay to re-sign this existing key with root zone's DSK instead of KSK. Yours, Junxiao On Wed, Mar 11, 2015 at 12:48 PM, Jiewen Tan wrote: Hi Junxiao, Assuming the root key and root certificate are already presented in the system(PIB), 1) Create root zone: /example a. ndns-create-zone /example -k /example/KEY/ksk-1/ID-CERT Here is to create a zone named /example using a KSK store in the PIB. It will also generate a DSK signed by the KSK provided automatically and insert the DSK to NDNS database (publish). All other options are set to default. 2) Publish root certificate: /example/KEY/ksk-1/ID-CERT a. ndns-export-certificate /example/KEY/ksk-1/ID-CERT Here is to export the root certificate to stdout. It can be exported to a file by using -f option as well. b. ndns-add-rr-from-file /example Here is to insert the root certificate into NDNS database (publish under zone /example). Default is to use stdin as input. So you can just copy&paste the output from 2.a. It will terminate with Ctrl+D. 3) Create site1 zone: /example/site1 a. ndns-create-zone /example/site1 Here, the tool will automatically generate a self-signed KSK and a corresponding DSK. Moreover, the DSK will be published automatically. 4) Delegate site1 zone from root zone a. ndns-add-rr -t resp /example /site1 NS Here is to add a rrset into zone: /example which has label: /site1 and type: /NS. Specifically, the content-type of the rrset is set to resp which indicate the existence of zone /example/site1. Now the delegation is completed. However, if the site zone is a leaf zone, a TXT type rrset is preferred. 5) Publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT (Site1?s KSK needs to be published in its parent zone, i.e. root zone.) a. ndns-export-certificate /example/KEY/site1/ksk-2/ID-CERT -f site1.cert Export the certificate from site1 zone. b. Pass the certificate to the parent zone, i.e. root zone here. (Use whatever methods you prefer) c. ndns-add-rr-from-file /example -f site1.cert Here the tool will resign the certificate with the zone?s DSK such that an authentication chain can be established. After that, it will publish the certificate in the NDNS database with label set to /site1/ksk-2 and type set to ID-CERT. 6) Publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT (Assuming it is stored as user1.cert) a. ndns-add-rr-from-file /example/site1 -f user1.cert Noticed again, this operation needs to be done in the parent zone, i.e. /example/site1. In NDNS, publishing a certificate is essentially meaning to insert the certificate into NDNS database as an ID-CERT rrset. Therefore, I use these two terms interchangeably here. Thank you for asking this question. I will try to make the answer as complete as possible and post this answer on the ndns-tr as appendix. BTW, Xiaoke please make any supplement to my explanation if necessary. Regards, Jiewen Tan From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu] Sent: Wednesday, March 11, 2015 11:56 AM To: Cc: Xiaoke Jiang; Jiewen Tan Subject: Re: [Nfd-dev] How to start a certificate chain from scratch Hi Xiaoke/Jiewen (correcting a typo below) Thanks for your examples. However, I need to start from scratch. Suppose: ? root/site/user certificates are created according to http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000616.html ? Two machines have NDNS package installed. One is to host root zone, the other is to host site1 zone. I need the commands to: ? create root zone: /example ? publish root certificate: /example/KEY/ksk-1/ID-CERT ? create site1 zone: /example/site1 ? delegate site1 zone from root zone ? publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT (should this be published at root zone or site1 zone?) ? publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT Yours, Junxiao On Wed, Mar 11, 2015 at 11:39 AM, Xiaoke Jiang wrote: Hi Junxiao, There are two ways to insert a certificate into NDNS, one is to embed it in update message and deliver it to name server, and the other is calling management tool to modify the local database directly. I present an example to show the two ways, assume the certificate is named /ndn/edu/ucla/KEY/bob/dsk-1420913151451/ID-CERT/%FD%00%00%01J%D5%06%0F%C8, and stored in the local file ndn.edu .ucla.bob.cert 1) sending update message locally or remotely: ndns-update -f ndn.edu .ucla.bob.cert 2) calling management tool locally: ndns-add-rr-from-file /ndn/edu/ucla -f ndn.edu.ucla.bob.cert And the management tools that remove it is: ndns-remove-rr /ndn/edu/ucla /bob/dsk-1420913151451 ID-CERT. As to remove it remotely, authorized party should send a update message embedding a NDNS-NACK with the same name prefix but greater version number. Note that the certificates issued by NDN Testbed is automatically stored in the NDNS instance hosted on the testbed. Xiaoke (Shock) -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Mar 11 15:45:00 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 11 Mar 2015 15:45:00 -0700 Subject: [Nfd-dev] code-style "make incompleteness of split lines obvious" vs chained operations Message-ID: Dear folks Rule 1.12 says: The incompleteness of split lines must be made obvious. Split lines occurs when a statement exceed the 80 column limit given above. It is difficult to give rigid rules for how lines should be split, but the examples above should give a general hint. In general: - Break after a comma. - Break after an operator. - Align the new line with the beginning of the expression on the previous line. I'm curious how to format the following snippet: (for this example, let's suppose it doesn't fit in the line width limit) return QString("%1:%2:%3) .arg(localTime->tm_hour, 2, 10, '0') .arg(localTime->tm_min, 2, 10, '0') .arg(localTime->tm_sec, 2, 10, '0'); Technically ')' is an operator so I can break after it, but this doesn't make the incompleteness obvious. If I break after the dot operator, the snippet becomes: return QString("%1:%2:%3). arg(localTime->tm_hour, 2, 10, '0'). arg(localTime->tm_min, 2, 10, '0'). arg(localTime->tm_sec, 2, 10, '0'); but the bare "arg" in the front doesn't look good. If I break after the '(' operator, the snippet becomes: return QString("%1:%2:%3).arg( localTime->tm_hour, 2, 10, '0').arg( localTime->tm_min, 2, 10, '0').arg( localTime->tm_sec, 2, 10, '0'); but this is also weird. If I break after the comma, the snippet becomes: return QString("%1:%2:%3).arg(localTime->tm_hour, 2, 10, '0').arg(localTime->tm_min, 2, 10, '0') .arg(localTime->tm_sec, 2, 10, '0'); which looks even worse. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefft0 at remap.UCLA.EDU Wed Mar 11 16:06:08 2015 From: jefft0 at remap.UCLA.EDU (Thompson, Jeff) Date: Wed, 11 Mar 2015 23:06:08 +0000 Subject: [Nfd-dev] code-style "make incompleteness of split lines obvious" vs chained operations In-Reply-To: References: Message-ID: ndn-cxx already has plenty of code with the first option. This looks good to me. For example: https://github.com/named-data/ndn-cxx/blob/34a37630a14c67309467074b448057dbf62cda65/src/security/key-chain.cpp#L338 certName.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); - Jeff T From: Junxiao Shi > Date: Wednesday, March 11, 2015 at 15:45 To: nfd-dev > Subject: [Nfd-dev] code-style "make incompleteness of split lines obvious" vs chained operations Dear folks Rule 1.12 says: The incompleteness of split lines must be made obvious. Split lines occurs when a statement exceed the 80 column limit given above. It is difficult to give rigid rules for how lines should be split, but the examples above should give a general hint. In general: * Break after a comma. * Break after an operator. * Align the new line with the beginning of the expression on the previous line. I'm curious how to format the following snippet: (for this example, let's suppose it doesn't fit in the line width limit) return QString("%1:%2:%3) .arg(localTime->tm_hour, 2, 10, '0') .arg(localTime->tm_min, 2, 10, '0') .arg(localTime->tm_sec, 2, 10, '0'); Technically ')' is an operator so I can break after it, but this doesn't make the incompleteness obvious. If I break after the dot operator, the snippet becomes: return QString("%1:%2:%3). arg(localTime->tm_hour, 2, 10, '0'). arg(localTime->tm_min, 2, 10, '0'). arg(localTime->tm_sec, 2, 10, '0'); but the bare "arg" in the front doesn't look good. If I break after the '(' operator, the snippet becomes: return QString("%1:%2:%3).arg( localTime->tm_hour, 2, 10, '0').arg( localTime->tm_min, 2, 10, '0').arg( localTime->tm_sec, 2, 10, '0'); but this is also weird. If I break after the comma, the snippet becomes: return QString("%1:%2:%3).arg(localTime->tm_hour, 2, 10, '0').arg(localTime->tm_min, 2, 10, '0').arg(localTime->tm_sec, 2, 10, '0'); which looks even worse. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Mar 11 16:17:12 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 11 Mar 2015 16:17:12 -0700 Subject: [Nfd-dev] code-style "make incompleteness of split lines obvious" vs chained operations In-Reply-To: References: Message-ID: Dear folks Thanks JeffT for pointing out this snippet. I have more questions about the alignment. (for the example, let's assume two .append() calls cannot fit on the same line) 1. Why not align '.append' of subsequent lines (rule 3.23), given the part before it ("certName") is short? certName.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); I feel this looks better than indent subsequent lines with two spaces. 2. What if "certName" is a shorter identifier? (a) n.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); (b) n.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); I feel (b) looks better. 3. Suppose there's a 'return' in the front, how should I align subsequent lines? (a) return certName.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); (b) return certName.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); (c) return certName.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); (d) return certName.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); I'd prefer (d). (a) and (c) also look nice, in case (d) would exceed column limit. (b) is worse than (a) and (c). Yours, Junxiao On Wed, Mar 11, 2015 at 4:06 PM, Thompson, Jeff wrote: > ndn-cxx already has plenty of code with the first option. This looks > good to me. For example: > > https://github.com/named-data/ndn-cxx/blob/34a37630a14c67309467074b448057dbf62cda65/src/security/key-chain.cpp#L338 > > certName.append(signingIdentity) > > .append("KEY") > > .append(keyName.getSubName(signingIdentity.size())) > > .append("ID-CERT") > > .appendVersion(); > > > - Jeff T > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.pesavento at lip6.fr Wed Mar 11 16:23:36 2015 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Thu, 12 Mar 2015 00:23:36 +0100 Subject: [Nfd-dev] code-style "make incompleteness of split lines obvious" vs chained operations In-Reply-To: References: Message-ID: On Thu, Mar 12, 2015 at 12:17 AM, Junxiao Shi wrote: > Dear folks > > Thanks JeffT for pointing out this snippet. > I have more questions about the alignment. > (for the example, let's assume two .append() calls cannot fit on the same > line) > > > 1. Why not align '.append' of subsequent lines (rule 3.23), given the part > before it ("certName") is short? > > certName.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > > I feel this looks better than indent subsequent lines with two spaces. > Agreed. > > 2. What if "certName" is a shorter identifier? > > (a) > > n.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > > (b) > > n.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > > I feel (b) looks better. > Just use a longer name for the identifier. 'n' isn't descriptive anyways. > 3. Suppose there's a 'return' in the front, how should I align subsequent > lines? > > (a) > > return certName.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > > (b) > > return certName.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > > (c) > > return certName.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > (d) > > return certName.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > > I'd prefer (d). > (a) and (c) also look nice, in case (d) would exceed column limit. > (b) is worse than (a) and (c). > Obviously (d) is to be preferred, for consistency with example 1. Best, Davide From jefft0 at remap.UCLA.EDU Wed Mar 11 16:25:47 2015 From: jefft0 at remap.UCLA.EDU (Thompson, Jeff) Date: Wed, 11 Mar 2015 23:25:47 +0000 Subject: [Nfd-dev] code-style "make incompleteness of split lines obvious" vs chained operations In-Reply-To: References: Message-ID: I have no strong feelings. 3.(a) looks nice to me. If the first ".append" is too long you could also do: return certName .append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); From: Junxiao Shi > Date: Wednesday, March 11, 2015 at 16:17 To: Jeff Thompson > Cc: nfd-dev > Subject: Re: [Nfd-dev] code-style "make incompleteness of split lines obvious" vs chained operations Dear folks Thanks JeffT for pointing out this snippet. I have more questions about the alignment. (for the example, let's assume two .append() calls cannot fit on the same line) 1. Why not align '.append' of subsequent lines (rule 3.23), given the part before it ("certName") is short? certName.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); I feel this looks better than indent subsequent lines with two spaces. 2. What if "certName" is a shorter identifier? (a) n.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); (b) n.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); I feel (b) looks better. 3. Suppose there's a 'return' in the front, how should I align subsequent lines? (a) return certName.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); (b) return certName.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); (c) return certName.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); (d) return certName.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); I'd prefer (d). (a) and (c) also look nice, in case (d) would exceed column limit. (b) is worse than (a) and (c). Yours, Junxiao On Wed, Mar 11, 2015 at 4:06 PM, Thompson, Jeff > wrote: ndn-cxx already has plenty of code with the first option. This looks good to me. For example: https://github.com/named-data/ndn-cxx/blob/34a37630a14c67309467074b448057dbf62cda65/src/security/key-chain.cpp#L338 certName.append(signingIdentity) .append("KEY") .append(keyName.getSubName(signingIdentity.size())) .append("ID-CERT") .appendVersion(); - Jeff T -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Fri Mar 13 15:09:05 2015 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Fri, 13 Mar 2015 22:09:05 +0000 Subject: [Nfd-dev] some notes from the sync call with Van Message-ID: <4DE8DC70-89F2-4ABA-99E1-783A3802AF6F@memphis.edu> - mobile phone doesn't contain the entire set of data (at some point, may need to purge data), it syncs only that subset of data - different subsets of the data is synced among different groups of people - different subsets of the data is synced with different data processing units (DPU) - name should make the mobile's operation efficient, e.g., if most operations are based on time, then time should be higher up on the name tree (things that you are likely to use for filtering should be higher up on the tree). - mobile operations: pruning, discovering new data. - is there one specific filtering attribute/name component (e.g., time) or multiple attributes? * Van: time is likely near the root. essentially a database problem, but a modern one. - need to get interest to mobile? no, with sync * if one side is anchored, can use data/interest to bootstrap two-way communication * mobile can get nonce name space under whichever place they are attached to, send interest to repo with this information about this name space, sign it. * same model as the IEEE communication paper (custodian) - need to add something to autoreg (assign a name prefix to mobile) Lan From jburke at remap.UCLA.EDU Fri Mar 13 16:13:22 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Fri, 13 Mar 2015 23:13:22 +0000 Subject: [Nfd-dev] Behavior of "on demand" faces to applications In-Reply-To: Message-ID: Hi folks, Could you please confirm the default behavior of "on-demand" face creation for applications? My understanding: The face created by default when an application registers a prefix is "on demand", meaning it can be destroyed by NFD if inactive for some timeout period. This behavior has caused some troubleshooting challenges with a long-running publisher and occasionally interested consumers. Some questions: - Where is this behavior documented? It is mentioned in p10 of the developer's guide, but I can't find either the constant or configuration parameter that sets it. - Is it the case that on-demand faces will not be destroyed if any traffic has traversed them? Or just that no traffic has traversed during the timeout interval? - What is the appropriate way to create a face that persists until the process that created it is either destroyed or unregistered the prefix? Thank you, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at UCLA.EDU Fri Mar 13 16:25:41 2015 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Fri, 13 Mar 2015 16:25:41 -0700 Subject: [Nfd-dev] Behavior of "on demand" faces to applications In-Reply-To: References: Message-ID: <1BAF5DC3-45E9-4B40-A97B-9AC98A52074D@ucla.edu> > On Mar 13, 2015, at 4:13 PM, Burke, Jeff wrote: > > > Hi folks, > > Could you please confirm the default behavior of "on-demand" face creation for applications? > > My understanding: The face created by default when an application registers a prefix is "on demand", meaning it can be destroyed by NFD if inactive for some timeout period. Not exactly (may be I misunderstood the question). Whenever face is created by an explicit command, it is ?persistent? (we also reserved concept ?permanent?, but it is not yet implemented). On-demand face is face that is created as a response of incoming tcp connect or packet received on UDP face. Only UDP face can get destroyed, TCP faces exist for as long tcp connection is alive. * * * If you?re referring to the UDP face from the the other side of tunnel, then yes. That face is on-demand and can be destroyed on the other side if no traffic. Remote registration built in into NFD/RIB management can take care of proper refreshing state. This is currently implemented, but requires some conventions on registered namespaces / available keys (it is documented in TR Yanbiao is working). > This behavior has caused some troubleshooting challenges with a long-running publisher and occasionally interested consumers. > > Some questions: > > - Where is this behavior documented? It is mentioned in p10 of the developer's guide, but I can't find either the constant or configuration parameter that sets it. Some documentation regarding default values used is also available in nfd.conf.sample. > > - Is it the case that on-demand faces will not be destroyed if any traffic has traversed them? Or just that no traffic has traversed during the timeout interval? Not sure I understood the question. on-demand udp face will not be destroyed if at least one packet (data/interest) is received during the timeout interval. > > - What is the appropriate way to create a face that persists until the process that created it is either destroyed or unregistered the prefix? Rely on remote registration process (I would say this is preferred). Alternatively, this could be something else that periodically send interest towards the remote end. > > Thank you, > Jeff > > > > > _______________________________________________ > 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: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jburke at remap.UCLA.EDU Fri Mar 13 16:31:04 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Fri, 13 Mar 2015 23:31:04 +0000 Subject: [Nfd-dev] Behavior of "on demand" faces to applications In-Reply-To: <1BAF5DC3-45E9-4B40-A97B-9AC98A52074D@ucla.edu> References: , <1BAF5DC3-45E9-4B40-A97B-9AC98A52074D@ucla.edu> Message-ID: <020480B79F5DB249B89F4856EB5270EA987F57CD@EM1A.ad.ucla.edu> Thanks, Alex. Peter, can you explain where you were seeing this? I thought it was with an app face, not udp... -----Original Message----- From: Alex Afanasyev [alexander.afanasyev at ucla.edu] Received: Friday, 13 Mar 2015, 4:25PM To: Burke, Jeff [jburke at remap.ucla.edu] CC: nfd-dev at lists.cs.ucla.edu [nfd-dev at lists.cs.ucla.edu] Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications On Mar 13, 2015, at 4:13 PM, Burke, Jeff > wrote: Hi folks, Could you please confirm the default behavior of "on-demand" face creation for applications? My understanding: The face created by default when an application registers a prefix is "on demand", meaning it can be destroyed by NFD if inactive for some timeout period. Not exactly (may be I misunderstood the question). Whenever face is created by an explicit command, it is ?persistent? (we also reserved concept ?permanent?, but it is not yet implemented). On-demand face is face that is created as a response of incoming tcp connect or packet received on UDP face. Only UDP face can get destroyed, TCP faces exist for as long tcp connection is alive. * * * If you?re referring to the UDP face from the the other side of tunnel, then yes. That face is on-demand and can be destroyed on the other side if no traffic. Remote registration built in into NFD/RIB management can take care of proper refreshing state. This is currently implemented, but requires some conventions on registered namespaces / available keys (it is documented in TR Yanbiao is working). This behavior has caused some troubleshooting challenges with a long-running publisher and occasionally interested consumers. Some questions: - Where is this behavior documented? It is mentioned in p10 of the developer's guide, but I can't find either the constant or configuration parameter that sets it. Some documentation regarding default values used is also available in nfd.conf.sample. - Is it the case that on-demand faces will not be destroyed if any traffic has traversed them? Or just that no traffic has traversed during the timeout interval? Not sure I understood the question. on-demand udp face will not be destroyed if at least one packet (data/interest) is received during the timeout interval. - What is the appropriate way to create a face that persists until the process that created it is either destroyed or unregistered the prefix? Rely on remote registration process (I would say this is preferred). Alternatively, this could be something else that periodically send interest towards the remote end. Thank you, Jeff _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at remap.UCLA.EDU Fri Mar 13 16:40:54 2015 From: peter at remap.UCLA.EDU (Gusev, Peter) Date: Fri, 13 Mar 2015 23:40:54 +0000 Subject: [Nfd-dev] Behavior of "on demand" faces to applications In-Reply-To: <020480B79F5DB249B89F4856EB5270EA987F57CD@EM1A.ad.ucla.edu> References: <,<1BAF5DC3-45E9-4B40-A97B-9AC98A52074D@ucla.edu> <>> <020480B79F5DB249B89F4856EB5270EA987F57CD@EM1A.ad.ucla.edu> Message-ID: Hi Alex, The face is created in pretty standard way - here is the code. JeffT?s NDN-CPP library uses TcpTransport to connect to local NFD. When we noticed that consumer is not getting any data, but producer is alive and no exceptions were thrown (like socket destroyed or similar), we checked nfd-status output and discovered that there is no face with producer?s prefix anymore. The only fact that producer was running for some lengthy time (20-30 minutes) and no interests were issued for its? data during this period made us think it might be ?on-demand? faces? problem... Thanks, -- Peter Gusev Programmer/Analyst @ REMAP, UCLA peter at remap.ucla.edu +1 213 5872748 peetonn_ (skype) On Mar 13, 2015, at 4:31 PM, Burke, Jeff > wrote: Thanks, Alex. Peter, can you explain where you were seeing this? I thought it was with an app face, not udp... -----Original Message----- From: Alex Afanasyev [alexander.afanasyev at ucla.edu] Received: Friday, 13 Mar 2015, 4:25PM To: Burke, Jeff [jburke at remap.ucla.edu] CC: nfd-dev at lists.cs.ucla.edu [nfd-dev at lists.cs.ucla.edu] Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications On Mar 13, 2015, at 4:13 PM, Burke, Jeff > wrote: Hi folks, Could you please confirm the default behavior of "on-demand" face creation for applications? My understanding: The face created by default when an application registers a prefix is "on demand", meaning it can be destroyed by NFD if inactive for some timeout period. Not exactly (may be I misunderstood the question). Whenever face is created by an explicit command, it is ?persistent? (we also reserved concept ?permanent?, but it is not yet implemented). On-demand face is face that is created as a response of incoming tcp connect or packet received on UDP face. Only UDP face can get destroyed, TCP faces exist for as long tcp connection is alive. * * * If you?re referring to the UDP face from the the other side of tunnel, then yes. That face is on-demand and can be destroyed on the other side if no traffic. Remote registration built in into NFD/RIB management can take care of proper refreshing state. This is currently implemented, but requires some conventions on registered namespaces / available keys (it is documented in TR Yanbiao is working). This behavior has caused some troubleshooting challenges with a long-running publisher and occasionally interested consumers. Some questions: - Where is this behavior documented? It is mentioned in p10 of the developer's guide, but I can't find either the constant or configuration parameter that sets it. Some documentation regarding default values used is also available in nfd.conf.sample. - Is it the case that on-demand faces will not be destroyed if any traffic has traversed them? Or just that no traffic has traversed during the timeout interval? Not sure I understood the question. on-demand udp face will not be destroyed if at least one packet (data/interest) is received during the timeout interval. - What is the appropriate way to create a face that persists until the process that created it is either destroyed or unregistered the prefix? Rely on remote registration process (I would say this is preferred). Alternatively, this could be something else that periodically send interest towards the remote end. Thank you, Jeff _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Fri Mar 13 16:53:37 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Fri, 13 Mar 2015 16:53:37 -0700 Subject: [Nfd-dev] Behavior of "on demand" faces to applications In-Reply-To: References: <, <1BAF5DC3-45E9-4B40-A97B-9AC98A52074D@ucla.edu> <>> <020480B79F5DB249B89F4856EB5270EA987F57CD@EM1A.ad.ucla.edu> Message-ID: <9C3A05EE-C260-4C74-B136-A9787C1DA8A7@ucla.edu> This could be some side effect of tcp connection, though nothing really should be happening bad. Do not use TCP to connect to local daemon, unless it is your only option. You should enable DEBUG level on TcpFace, TcpLocalFace, FaceTable and see why face is removed. > On Mar 13, 2015, at 4:40 PM, Gusev, Peter wrote: > > Hi Alex, > > The face is created in pretty standard way - here is the code . JeffT?s NDN-CPP library uses TcpTransport to connect to local NFD. > When we noticed that consumer is not getting any data, but producer is alive and no exceptions were thrown (like socket destroyed or similar), we checked nfd-status output and discovered that there is no face with producer?s prefix anymore. > > The only fact that producer was running for some lengthy time (20-30 minutes) and no interests were issued for its? data during this period made us think it might be ?on-demand? faces? problem... > > Thanks, > > -- > Peter Gusev > Programmer/Analyst @ REMAP, UCLA > > peter at remap.ucla.edu > +1 213 5872748 > peetonn_ (skype) > >> On Mar 13, 2015, at 4:31 PM, Burke, Jeff > wrote: >> >> Thanks, Alex. Peter, can you explain where you were seeing this? I thought it was with an app face, not udp... >> >> -----Original Message----- >> From: Alex Afanasyev [alexander.afanasyev at ucla.edu ] >> Received: Friday, 13 Mar 2015, 4:25PM >> To: Burke, Jeff [jburke at remap.ucla.edu ] >> CC: nfd-dev at lists.cs.ucla.edu [nfd-dev at lists.cs.ucla.edu ] >> Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications >> >> >>> On Mar 13, 2015, at 4:13 PM, Burke, Jeff > wrote: >>> >>> >>> Hi folks, >>> >>> Could you please confirm the default behavior of "on-demand" face creation for applications? >>> >>> My understanding: The face created by default when an application registers a prefix is "on demand", meaning it can be destroyed by NFD if inactive for some timeout period. >> >> Not exactly (may be I misunderstood the question). Whenever face is created by an explicit command, it is ?persistent? (we also reserved concept ?permanent?, but it is not yet implemented). >> >> On-demand face is face that is created as a response of incoming tcp connect or packet received on UDP face. Only UDP face can get destroyed, TCP faces exist for as long tcp connection is alive. >> >> * * * >> >> If you?re referring to the UDP face from the the other side of tunnel, then yes. That face is on-demand and can be destroyed on the other side if no traffic. >> >> Remote registration built in into NFD/RIB management can take care of proper refreshing state. This is currently implemented, but requires some conventions on registered namespaces / available keys (it is documented in TR Yanbiao is working). >> >>> This behavior has caused some troubleshooting challenges with a long-running publisher and occasionally interested consumers. >>> >>> Some questions: >>> >>> - Where is this behavior documented? It is mentioned in p10 of the developer's guide, but I can't find either the constant or configuration parameter that sets it. >> >> Some documentation regarding default values used is also available in nfd.conf.sample. >> >>> >>> - Is it the case that on-demand faces will not be destroyed if any traffic has traversed them? Or just that no traffic has traversed during the timeout interval? >> >> Not sure I understood the question. on-demand udp face will not be destroyed if at least one packet (data/interest) is received during the timeout interval. >> >>> >>> - What is the appropriate way to create a face that persists until the process that created it is either destroyed or unregistered the prefix? >> >> Rely on remote registration process (I would say this is preferred). Alternatively, this could be something else that periodically send interest towards the remote end. >> >>> >>> Thank you, >>> Jeff >>> >>> >>> >>> >>> _______________________________________________ >>> 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: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alexander.afanasyev at ucla.edu Sun Mar 15 11:52:47 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Sun, 15 Mar 2015 11:52:47 -0700 Subject: [Nfd-dev] code-style "make incompleteness of split lines obvious" vs chained operations In-Reply-To: References: Message-ID: <4B3A2723-D056-4581-9BDA-823E8F90B1C8@ucla.edu> I don?t have a strong feeling that we need to standardize this part. I usually prefer something similar to what Jeff showed: variable + continuation for each .append method (modified 3a/3d). I don?t see any appealing reason to reject any of the presented styles. I can only wish that the selected way is consistent within a single module (at least .cpp/.hpp). ? Alex > On Mar 11, 2015, at 4:25 PM, Thompson, Jeff wrote: > > I have no strong feelings. 3.(a) looks nice to me. If the first ".append" is too long you could also do: > > return certName > .append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > > > From: Junxiao Shi > > Date: Wednesday, March 11, 2015 at 16:17 > To: Jeff Thompson > > Cc: nfd-dev > > Subject: Re: [Nfd-dev] code-style "make incompleteness of split lines obvious" vs chained operations > > Dear folks > > Thanks JeffT for pointing out this snippet. > I have more questions about the alignment. > (for the example, let's assume two .append() calls cannot fit on the same line) > > > 1. Why not align '.append' of subsequent lines (rule 3.23), given the part before it ("certName") is short? > > certName.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > > I feel this looks better than indent subsequent lines with two spaces. > > > 2. What if "certName" is a shorter identifier? > > (a) > > n.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > > (b) > > n.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > > I feel (b) looks better. > > 3. Suppose there's a 'return' in the front, how should I align subsequent lines? > > (a) > > return certName.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > > (b) > > return certName.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > > (c) > > return certName.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > (d) > > return certName.append(signingIdentity) > .append("KEY") > .append(keyName.getSubName(signingIdentity.size())) > .append("ID-CERT") > .appendVersion(); > > I'd prefer (d). > (a) and (c) also look nice, in case (d) would exceed column limit. > (b) is worse than (a) and (c). > > Yours, Junxiao > > On Wed, Mar 11, 2015 at 4:06 PM, Thompson, Jeff > wrote: >> ndn-cxx already has plenty of code with the first option. This looks good to me. For example: >> https://github.com/named-data/ndn-cxx/blob/34a37630a14c67309467074b448057dbf62cda65/src/security/key-chain.cpp#L338 >> >> certName.append(signingIdentity) >> .append("KEY") >> .append(keyName.getSubName(signingIdentity.size())) >> .append("ID-CERT") >> .appendVersion(); >> >> - Jeff T >> > _______________________________________________ > 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: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From shijunxiao at email.arizona.edu Tue Mar 17 08:12:09 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 17 Mar 2015 08:12:09 -0700 Subject: [Nfd-dev] code-style "make incompleteness of split lines obvious" vs chained operations In-Reply-To: <4B3A2723-D056-4581-9BDA-823E8F90B1C8@ucla.edu> References: <4B3A2723-D056-4581-9BDA-823E8F90B1C8@ucla.edu> Message-ID: Hi Alex I didn't ask for standardizing this part, because it rarely appears. I wanted to confirm the rule 1.12 exception when chained operations are involved. Yours, Junxiao On Sun, Mar 15, 2015 at 11:52 AM, Alex Afanasyev < alexander.afanasyev at ucla.edu> wrote: > I don?t have a strong feeling that we need to standardize this part. I > usually prefer something similar to what Jeff showed: variable + > continuation for each .append method (modified 3a/3d). I don?t see any > appealing reason to reject any of the presented styles. I can only wish > that the selected way is consistent within a single module (at least > .cpp/.hpp). > > ? > Alex > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Mar 17 20:37:15 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 17 Mar 2015 20:37:15 -0700 Subject: [Nfd-dev] Jenkins upgrade 20150318 Message-ID: Dear folks I will be upgrading VirtualBox on Jenkins host machine on Mar 18. Jenkins system will be unavailable for about 2 hours. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Mar 18 09:10:30 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 18 Mar 2015 09:10:30 -0700 Subject: [Nfd-dev] Jenkins upgrade 20150318 In-Reply-To: References: Message-ID: Dear folks The upgrade is completed. Yours, Junxiao On Tue, Mar 17, 2015 at 8:37 PM, Junxiao Shi wrote: > Dear folks > > I will be upgrading VirtualBox on Jenkins host machine on Mar 18. > Jenkins system will be unavailable for about 2 hours. > > Yours, Junxiao > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Wed Mar 18 17:03:20 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Thu, 19 Mar 2015 00:03:20 +0000 Subject: [Nfd-dev] Preview of NFD-iOS and SwiftNDN library Message-ID: Hi team, I write this message to inform you that there has been major progress on porting NFD to iOS platform. As for now, I'm able to compile and run NFD as an iOS App on the iPhone simulator. I cannot test it on real device because it requires signing the package with Apple-certified developer's key which I don't have. So there might be unexpected bugs when the App runs on real iPhones :P Unfortunately the code is not available on Github yet because I'm still trying to reorganize the dependencies in order to simplify the build process. After that I'll publish the code. Before I started the porting work, I was already working on a new NDN client library written in (almost) pure Swift, which is designed for Apple platforms exclusively (Mac, iPhone, iPad, etc.) It is not polished right now but you can take a look at the code at https://github.com/wentaoshang/SwiftNDN The motivation of using Swift as a development language is because it is one of the best languages for building OSX and iOS apps, especially when you need a GUI interface using Cocoa or Cocoa Touch. (The other choice is Objective C but I don't quite like that language. Also, Apple is promoting the new language very hard to hopefully replace the old one.) Attached are some screenshots of the NFD app running on iPhone simulator. It is built with Cocoa Touch and SwiftNDN and has the basic functionality of reporting forwarder status such as faces, fib and rib information. All my testing are done primarily using this demo app and some basic consumer/producer apps built with the same libraries. Best, Wentao -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iOS Simulator Screen Shot Mar 18, 2015, 4.24.29 PM.png Type: image/png Size: 92521 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iOS Simulator Screen Shot Mar 18, 2015, 4.24.56 PM.png Type: image/png Size: 103995 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iOS Simulator Screen Shot Mar 18, 2015, 4.24.33 PM.png Type: image/png Size: 52839 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iOS Simulator Screen Shot Mar 18, 2015, 4.24.37 PM.png Type: image/png Size: 47583 bytes Desc: not available URL: From ivanyeo at CS.UCLA.EDU Thu Mar 19 05:58:04 2015 From: ivanyeo at CS.UCLA.EDU (Ivan Yeo) Date: Thu, 19 Mar 2015 05:58:04 -0700 Subject: [Nfd-dev] [Ndn-lib] Preview of NFD-iOS and SwiftNDN library In-Reply-To: References: Message-ID: <550AC7DC.6070907@cs.ucla.edu> Nice! Looks great! I have a developer key and could test stuff out if you need me too. We can possibly do it over screen share, if you need to give me on screen instructions for stuff. Yep, Swift is probably the way to go, I'm with you on that, albeit, I develop mostly in ObjC :) Cheers, Ivan On 03/18/2015 05:03 PM, Wentao Shang wrote: > Hi team, > > I write this message to inform you that there has been major progress > on porting NFD to iOS platform. As for now, I'm able to compile and > run NFD as an iOS App on the iPhone simulator. I cannot test it on > real device because it requires signing the package with > Apple-certified developer's key which I don't have. So there might be > unexpected bugs when the App runs on real iPhones :P Unfortunately the > code is not available on Github yet because I'm still trying to > reorganize the dependencies in order to simplify the build process. > After that I'll publish the code. > > Before I started the porting work, I was already working on a new NDN > client library written in (almost) pure Swift, which is designed for > Apple platforms exclusively (Mac, iPhone, iPad, etc.) It is not > polished right now but you can take a look at the code at > https://github.com/wentaoshang/SwiftNDN > > The motivation of using Swift as a development language is because it > is one of the best languages for building OSX and iOS apps, especially > when you need a GUI interface using Cocoa or Cocoa Touch. (The other > choice is Objective C but I don't quite like that language. Also, > Apple is promoting the new language very hard to hopefully replace the > old one.) > > Attached are some screenshots of the NFD app running on iPhone > simulator. It is built with Cocoa Touch and SwiftNDN and has the basic > functionality of reporting forwarder status such as faces, fib and rib > information. All my testing are done primarily using this demo app and > some basic consumer/producer apps built with the same libraries. > > Best, > Wentao > > > > _______________________________________________ > Ndn-lib mailing list > Ndn-lib at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-lib -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Mar 19 06:20:43 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 19 Mar 2015 06:20:43 -0700 Subject: [Nfd-dev] [Ndn-lib] Preview of NFD-iOS and SwiftNDN library In-Reply-To: References: Message-ID: Hi Wentao I looked at the code, and liked the simplicity of TLV decoding procedures. It appears to be much easier to add a new TLV type in SwiftNDN than in ndn-cxx or NDN-JS. I probably won't use this app because I don't have iOS devices. Yours, Junxiao On Mar 18, 2015 5:09 PM, "Wentao Shang" wrote: > Hi team, > > I write this message to inform you that there has been major progress on > porting NFD to iOS platform. As for now, I'm able to compile and run NFD as > an iOS App on the iPhone simulator. I cannot test it on real device because > it requires signing the package with Apple-certified developer's key which > I don't have. So there might be unexpected bugs when the App runs on real > iPhones :P Unfortunately the code is not available on Github yet because > I'm still trying to reorganize the dependencies in order to simplify the > build process. After that I'll publish the code. > > Before I started the porting work, I was already working on a new NDN > client library written in (almost) pure Swift, which is designed for Apple > platforms exclusively (Mac, iPhone, iPad, etc.) It is not polished right > now but you can take a look at the code at > https://github.com/wentaoshang/SwiftNDN > > The motivation of using Swift as a development language is because it is > one of the best languages for building OSX and iOS apps, especially when > you need a GUI interface using Cocoa or Cocoa Touch. (The other choice is > Objective C but I don't quite like that language. Also, Apple is promoting > the new language very hard to hopefully replace the old one.) > > Attached are some screenshots of the NFD app running on iPhone simulator. > It is built with Cocoa Touch and SwiftNDN and has the basic functionality > of reporting forwarder status such as faces, fib and rib information. All > my testing are done primarily using this demo app and some basic > consumer/producer apps built with the same libraries. > > Best, > Wentao > > > _______________________________________________ > Ndn-lib mailing list > Ndn-lib at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-lib > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Thu Mar 19 08:02:11 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Thu, 19 Mar 2015 15:02:11 +0000 Subject: [Nfd-dev] [Ndn-lib] Preview of NFD-iOS and SwiftNDN library In-Reply-To: <550AC7DC.6070907@cs.ucla.edu> References: <550AC7DC.6070907@cs.ucla.edu> Message-ID: On Thu, Mar 19, 2015 at 5:58 AM Ivan Yeo wrote: > Nice! Looks great! I have a developer key and could test stuff out if > you need me too. We can possibly do it over screen share, if you need to > give me on screen instructions for stuff. > That will be very helpful! I'll let you know when the code is ready so you can test it. My biggest concern right now is the background execution mode. Somehow NFD works magically in background on the simulator without being suspended by iOS. But I'm not sure whether we will get the same behavior on a real device... Best, Wentao > > Yep, Swift is probably the way to go, I'm with you on that, albeit, I > develop mostly in ObjC :) > > Cheers, > Ivan > > > On 03/18/2015 05:03 PM, Wentao Shang wrote: > > Hi team, > > I write this message to inform you that there has been major progress on > porting NFD to iOS platform. As for now, I'm able to compile and run NFD as > an iOS App on the iPhone simulator. I cannot test it on real device because > it requires signing the package with Apple-certified developer's key which > I don't have. So there might be unexpected bugs when the App runs on real > iPhones :P Unfortunately the code is not available on Github yet because > I'm still trying to reorganize the dependencies in order to simplify the > build process. After that I'll publish the code. > > Before I started the porting work, I was already working on a new NDN > client library written in (almost) pure Swift, which is designed for Apple > platforms exclusively (Mac, iPhone, iPad, etc.) It is not polished right > now but you can take a look at the code at > https://github.com/wentaoshang/SwiftNDN > > The motivation of using Swift as a development language is because it is > one of the best languages for building OSX and iOS apps, especially when > you need a GUI interface using Cocoa or Cocoa Touch. (The other choice is > Objective C but I don't quite like that language. Also, Apple is promoting > the new language very hard to hopefully replace the old one.) > > Attached are some screenshots of the NFD app running on iPhone > simulator. It is built with Cocoa Touch and SwiftNDN and has the basic > functionality of reporting forwarder status such as faces, fib and rib > information. All my testing are done primarily using this demo app and some > basic consumer/producer apps built with the same libraries. > > Best, > Wentao > > > > _______________________________________________ > Ndn-lib mailing listNdn-lib at lists.cs.ucla.eduhttp://www.lists.cs.ucla.edu/mailman/listinfo/ndn-lib > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Thu Mar 19 08:12:48 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Thu, 19 Mar 2015 15:12:48 +0000 Subject: [Nfd-dev] [Ndn-lib] Preview of NFD-iOS and SwiftNDN library In-Reply-To: References: Message-ID: Hi Junxiao, I'm glad that you liked it :) The TLV encoding/decoding is where I spent a lot of effort. I've tried different approaches and eventually settled on the current one. Two things that I found most helpful in the current design: 1/ a generic decoder function that can parse a byte array into an array of TLV blocks. The compound TLV classes can call this function recursively to build the TLV parse tree. 2/ two generic TLV base classes for those whose value is a single non-negative integer and those whose value is a UTF-8 string. New TLV classes can inherit from those base classes and simply specify the desired TLV type code. The base class will handle all the encoding/decoding work. This comes very handy when you have to write a lot of TLV classes containing non-negative integers for NFD management protocol . Best, Wentao On Thu, Mar 19, 2015 at 6:20 AM Junxiao Shi wrote: > Hi Wentao > > I looked at the code, and liked the simplicity of TLV decoding procedures. > It appears to be much easier to add a new TLV type in SwiftNDN than in > ndn-cxx or NDN-JS. > > I probably won't use this app because I don't have iOS devices. > > Yours, Junxiao > On Mar 18, 2015 5:09 PM, "Wentao Shang" wrote: > >> Hi team, >> >> I write this message to inform you that there has been major progress on >> porting NFD to iOS platform. As for now, I'm able to compile and run NFD as >> an iOS App on the iPhone simulator. I cannot test it on real device because >> it requires signing the package with Apple-certified developer's key which >> I don't have. So there might be unexpected bugs when the App runs on real >> iPhones :P Unfortunately the code is not available on Github yet because >> I'm still trying to reorganize the dependencies in order to simplify the >> build process. After that I'll publish the code. >> >> Before I started the porting work, I was already working on a new NDN >> client library written in (almost) pure Swift, which is designed for Apple >> platforms exclusively (Mac, iPhone, iPad, etc.) It is not polished right >> now but you can take a look at the code at >> https://github.com/wentaoshang/SwiftNDN >> >> The motivation of using Swift as a development language is because it is >> one of the best languages for building OSX and iOS apps, especially when >> you need a GUI interface using Cocoa or Cocoa Touch. (The other choice is >> Objective C but I don't quite like that language. Also, Apple is promoting >> the new language very hard to hopefully replace the old one.) >> >> Attached are some screenshots of the NFD app running on iPhone simulator. >> It is built with Cocoa Touch and SwiftNDN and has the basic functionality >> of reporting forwarder status such as faces, fib and rib information. All >> my testing are done primarily using this demo app and some basic >> consumer/producer apps built with the same libraries. >> >> Best, >> Wentao >> >> >> _______________________________________________ >> Ndn-lib mailing list >> Ndn-lib at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-lib >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Thu Mar 19 22:28:01 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Fri, 20 Mar 2015 05:28:01 +0000 Subject: [Nfd-dev] Incorrect handling of exclude filter in CS lookup Message-ID: Hi team, When I was testing NFD on iOS, I noticed that NFD doesn't seem to handle Exclude filter correctly in CS lookup. I looked into the code and noticed that in ./daemon/table/cs.cpp, the Cs::find method only handles the child selector but never checks the exclude filter. And I suspect this is a bug. Can someone verify whether this is a real issue or the exclude filter is actually checked somewhere else? If it's a "feature not a bug", I wonder what is the reason behind the design decision to leave out exclude filter in CS lookup. Thanks, Wentao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Mar 19 22:40:31 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 19 Mar 2015 22:40:31 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: <007501d05c34$48aebb90$da0c32b0$@ucla.edu> References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> <007501d05c34$48aebb90$da0c32b0$@ucla.edu> Message-ID: Hi Jiewen I have tried these steps with ndns 0.0.2-ppa1~trusty. My experiences and questions are below. 1) create root zone a. ndns-create-zone - -k parameter must be the full certificate Name including the version component after ID-CERT, otherwise it complains "Error: Cannot verify KSK certificate". - sudo is needed, otherwise it complains "Error: INSERT INTO zones (name, ttl) VALUES (?, ?)", and operator's TPM is polluted with a useless DSK. 2) publish root certificate a. ndns-export-certificate (appears to be equivalent to ndnsec-dump-certificate) - first parameter must be the full certificate Name including the version component after ID-CERT, otherwise it complains "Error: Certificate name is illegal". b. ndns-add-rr-from-file - sudo is needed, otherwise it complains "Error: FileStore: error opening file for reading: /home/sunny/.ndn/ndnsec-tpm-file/KaThtq7TuD1zToRgAXsZ+QMEUA0e6A8O6rwm3f0vBlU=.pri" 3) create site1 zone a. ndns-create-zone - same as 1a, sudo is needed 4) delegate site1 zone from root zone a. ndns-add-rr - sudo is needed, otherwise it complains "Error: FileStore: error opening file for reading: /home/sunny/.ndn/ndnsec-tpm-file/KaThtq7TuD1zToRgAXsZ+QMEUA0e6A8O6rwm3f0vBlU=.pri" 5) publish site1 certificate a. ndns-export-certificate - same as 2a, first parameter must be the full certificate Name including the version component after ID-CERT; execute `ndnsec-list -c` to learn the full certificate Name. c. ndns-add-rr-from-file - same as 2b, sudo is needed 6) publish user1 certificate a. ndns-add-rr-from-file - sudo is needed, otherwise it complains "Error: FileStore: error opening file for reading: /home/sunny/.ndn/ndnsec-tpm-file/stCLw6BWTYfAe8nHMIocqKD9I9+rAglUbI6dbR%2oNM=.pri" However, after completing these steps, I'm still unable to fetch certificate with ndn-tlv-peek. It appears that ndns didn't register any routes in local NFD. ndns didn't create a log file in /var/log/ndn, so I can't see what's going on. Also, the root certificate doesn't seem correct. sunny at sunnyq ~ $ ndns-list-zone /root ; Zone /root ; rrset=/site1 type=NS version=%FD%00%00%01L5%A2k%D0 signed-by=/root/KEY/dsk-1426828258078/ID-CERT /site1 3600 NS /dsk-1426828258078 3600 ID-CERT ; content-type=NDNS-Raw version=%FD%00%00%01L5%97l%23 signed-by=/root/KEY/ksk-1426828193071/ID-CERT /ksk-1426828193071 3600 ID-CERT ; content-type=NDNS-Raw version=%FD%00%00%01L5%96n%83 signed-by=/root/KEY/dsk-1426828258078/ID-CERT /site1/ksk-1426828890240 3600 ID-CERT ; content-type=NDNS-Raw version=%FD%00%00%01L5%A1%12d signed-by=/root/KEY/dsk-1426828258078/ID-CERT This says that the root KSK is signed by the root DSK. It's not the original self-signed KSK. Yours, Junxiao On Wed, Mar 11, 2015 at 12:48 PM, Jiewen Tan wrote: > Hi Junxiao, > > > > Assuming the root key and root certificate are already presented in the > system(PIB), > > 1) Create root zone: /example > > a. ndns-create-zone /example -k /example/KEY/ksk-1/ID-CERT > > Here is to create a zone named /example using a KSK store in the PIB. It > will also generate a DSK signed by the KSK provided automatically and > insert the DSK to NDNS database (publish). All other options are set to > default. > > 2) Publish root certificate: /example/KEY/ksk-1/ID-CERT > > a. ndns-export-certificate /example/KEY/ksk-1/ID-CERT > > Here is to export the root certificate to stdout. It can be exported to a > file by using -f option as well. > > b. ndns-add-rr-from-file /example > > Here is to insert the root certificate into NDNS database (publish under > zone /example). Default is to use stdin as input. So you can just > copy&paste the output from 2.a. It will terminate with Ctrl+D. > > 3) Create site1 zone: /example/site1 > > a. ndns-create-zone /example/site1 > > Here, the tool will automatically generate a self-signed KSK and a > corresponding DSK. Moreover, the DSK will be published automatically. > > 4) Delegate site1 zone from root zone > > a. ndns-add-rr -t resp /example /site1 NS > > Here is to add a rrset into zone: /example which has label: /site1 and > type: /NS. Specifically, the content-type of the rrset is set to resp which > indicate the existence of zone /example/site1. Now the delegation is > completed. However, if the site zone is a leaf zone, a TXT type rrset is > preferred. > > 5) Publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT > (Site1?s KSK needs to be published in its parent zone, i.e. root zone.) > > a. ndns-export-certificate /example/KEY/site1/ksk-2/ID-CERT -f > site1.cert > > Export the certificate from site1 zone. > > b. Pass the certificate to the parent zone, i.e. root zone here. > (Use whatever methods you prefer) > > c. ndns-add-rr-from-file /example -f site1.cert > > Here the tool will resign the certificate with the zone?s DSK such that an > authentication chain can be established. After that, it will publish the > certificate in the NDNS database with label set to /site1/ksk-2 and type > set to ID-CERT. > > 6) Publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT > (Assuming it is stored as user1.cert) > > a. ndns-add-rr-from-file /example/site1 -f user1.cert > > Noticed again, this operation needs to be done in the parent zone, i.e. > /example/site1. > > > > In NDNS, publishing a certificate is essentially meaning to insert the > certificate into NDNS database as an ID-CERT rrset. Therefore, I use these > two terms interchangeably here. > > > > Thank you for asking this question. I will try to make the answer as > complete as possible and post this answer on the ndns-tr as appendix. > > > > BTW, Xiaoke please make any supplement to my explanation if necessary. > > > > Regards, > > Jiewen Tan > > *From:* Junxiao Shi [mailto:shijunxiao at email.arizona.edu] > *Sent:* Wednesday, March 11, 2015 11:56 AM > *To:* > *Cc:* Xiaoke Jiang; Jiewen Tan > *Subject:* Re: [Nfd-dev] How to start a certificate chain from scratch > > > > Hi Xiaoke/Jiewen > > (correcting a typo below) > > > > Thanks for your examples. However, I need to start from scratch. Suppose: > > ? root/site/user certificates are created according to > http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000616.html > > ? Two machines have NDNS package installed. One is to host root zone, > the other is to host site1 zone. > > I need the commands to: > > ? create root zone: /example > > ? publish root certificate: /example/KEY/ksk-1/ID-CERT > > ? create site1 zone: /example/site1 > > ? delegate site1 zone from root zone > > ? publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT (should > this be published at root zone or site1 zone?) > > ? publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT > > > > Yours, Junxiao > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Mar 19 22:49:27 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 19 Mar 2015 22:49:27 -0700 Subject: [Nfd-dev] Incorrect handling of exclude filter in CS lookup In-Reply-To: References: Message-ID: Hi Wentao As of NFD:commit:eab7249b74d4819f9dc32e2f2d12d392f36acdc1: - Cs::find returns an Entry only if Entry::canSatisfy returns true; this condition is checked in both Cs::findLeftmost and Cs::findRightmostAmongExact. - Entry::canSatisfy returns true only if Interest::matchesData returns true. - Interest::matchesData evaluates the Exclude Selector. If you have a problematic case, please open a Bug on NFD Redmine site. The Bug report should contain a concise code snippet or tcpdump trace that reproduces the problem. Yours, Junxiao On Thu, Mar 19, 2015 at 10:28 PM, Wentao Shang wrote: > Hi team, > > When I was testing NFD on iOS, I noticed that NFD doesn't seem to handle > Exclude filter correctly in CS lookup. I looked into the code and noticed > that in ./daemon/table/cs.cpp, the Cs::find method only handles the child > selector but never checks the exclude filter. And I suspect this is a bug. > Can someone verify whether this is a real issue or the exclude filter is > actually checked somewhere else? If it's a "feature not a bug", I wonder > what is the reason behind the design decision to leave out exclude filter > in CS lookup. > > Thanks, > Wentao > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Fri Mar 20 00:02:20 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Fri, 20 Mar 2015 07:02:20 +0000 Subject: [Nfd-dev] Incorrect handling of exclude filter in CS lookup In-Reply-To: References: Message-ID: Hi Junxiao, I found this problem on iOS using an "incorrect" implementation of the FaceStatus Dataset consumer. I'm not sure how to reproduce this error on normal computers yet. But here is a dump of log messages from NFD (this is the best I can get to describe the problem...): 2015-03-19 23:49:20.532 NFD[5139:69230] TRACE: [TcpLocalFace] [id=257,local=tcp4://127.0.0.1:6363,remote=tcp4://127.0.0.1:51868] Received: 63 bytes 2015-03-19 23:49:20.532 NFD[5139:69230] DEBUG: [Forwarder] onIncomingInterest face=257 interest=/localhost/nfd/faces/list?ndn.ChildSelector=1&ndn.InterestLifetime=1000&ndn.Nonce=1313767654&ndn.Exclude=...,%FD%00%00%01L5%F1K%21 2015-03-19 23:49:20.533 NFD[5139:69230] DEBUG: [ContentStore] find /localhost/nfd/faces/list R 2015-03-19 23:49:20.533 NFD[5139:69230] TRACE: [ContentStore] find-under-prefix /localhost/nfd/faces/list/%FD%00%00%01L5%F1K%21 2015-03-19 23:49:20.533 NFD[5139:69230] TRACE: [ContentStore] find-under-prefix /localhost/nfd/faces/list/%FD%00%00%01L5%F1%3D%BF 2015-03-19 23:49:20.533 NFD[5139:69230] DEBUG: [ContentStore] matching /localhost/nfd/faces/list/%FD%00%00%01L5%F1%3D%BF/%00%00 2015-03-19 23:49:20.533 NFD[5139:69230] DEBUG: [Forwarder] onOutgoingData face=257 data=/localhost/nfd/faces/list/%FD%00%00%01L5%F1%3D%BF/%00%00 2015-03-19 23:49:20.534 NFD[5139:69230] TRACE: [TcpLocalFace] [id=257,local=tcp4://127.0.0.1:6363,remote=tcp4://127.0.0.1:51868] sendData 2015-03-19 23:49:20.534 NFD[5139:69230] TRACE: [TcpLocalFace] [id=257,local=tcp4://127.0.0.1:6363,remote=tcp4://127.0.0.1:51868] Successfully sent: 724 bytes 2015-03-19 23:49:20.637 NFD[5139:69230] DEBUG: [Forwarder] onInterestFinalize interest=/localhost/nfd/faces/list satisfied You can see that I sent an Interest with exclude filter of [ANY, %FD%00%00%01L5%F1K%21]. But somehow NFD decided to match this interest to the data with suffix "%FD%00%00%01L5%F1%3D%BF/%00%00". Note that "%FD%00%00%01L5%F1K%21" is larger than "%FD%00%00%01L5%F1%3D%BF" because 'K' == 0x4B. So this data should have been filtered out... Thanks, Wentao On Thu, Mar 19, 2015 at 10:49 PM Junxiao Shi wrote: > Hi Wentao > > As of NFD:commit:eab7249b74d4819f9dc32e2f2d12d392f36acdc1: > > - Cs::find returns an Entry only if Entry::canSatisfy returns true; > this condition is checked in both Cs::findLeftmost and > Cs::findRightmostAmongExact. > - Entry::canSatisfy returns true only if Interest::matchesData returns > true. > - Interest::matchesData evaluates the Exclude Selector. > > > If you have a problematic case, please open a Bug on NFD Redmine site. > The Bug report should contain a concise code snippet or tcpdump trace that > reproduces the problem. > > Yours, Junxiao > > On Thu, Mar 19, 2015 at 10:28 PM, Wentao Shang > wrote: > >> Hi team, >> >> When I was testing NFD on iOS, I noticed that NFD doesn't seem to handle >> Exclude filter correctly in CS lookup. I looked into the code and noticed >> that in ./daemon/table/cs.cpp, the Cs::find method only handles the child >> selector but never checks the exclude filter. And I suspect this is a bug. >> Can someone verify whether this is a real issue or the exclude filter is >> actually checked somewhere else? If it's a "feature not a bug", I wonder >> what is the reason behind the design decision to leave out exclude filter >> in CS lookup. >> >> Thanks, >> Wentao >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Mar 20 00:31:02 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 20 Mar 2015 00:31:02 -0700 Subject: [Nfd-dev] Incorrect handling of exclude filter in CS lookup In-Reply-To: References: Message-ID: Hi Wentao This behavior is by design. The Interest has this Exclude Selector: %FD%00%00%01L5%F1K%21 Note that there isn't a element between two NameComponents. The returned Data does not violate this Exclude Selector, because %FD%00%00%01L5%F1%3D%BF doesn't appear in this Exclude Selector. Yours, Junxiao On Fri, Mar 20, 2015 at 12:02 AM, Wentao Shang wrote: > Hi Junxiao, > > I found this problem on iOS using an "incorrect" implementation of the > FaceStatus Dataset consumer. I'm not sure how to reproduce this error on > normal computers yet. But here is a dump of log messages from NFD (this is > the best I can get to describe the problem...): > > > 2015-03-19 23:49:20.532 NFD[5139:69230] TRACE: [TcpLocalFace] > [id=257,local=tcp4://127.0.0.1:6363,remote=tcp4://127.0.0.1:51868] > Received: 63 bytes > > 2015-03-19 23:49:20.532 NFD[5139:69230] DEBUG: [Forwarder] > onIncomingInterest face=257 > interest=/localhost/nfd/faces/list?ndn.ChildSelector=1&ndn.InterestLifetime=1000&ndn.Nonce=1313767654&ndn.Exclude=...,%FD%00%00%01L5%F1K%21 > > > 2015-03-19 23:49:20.533 NFD[5139:69230] DEBUG: [ContentStore] find > /localhost/nfd/faces/list R > > 2015-03-19 23:49:20.533 NFD[5139:69230] TRACE: [ContentStore] > find-under-prefix /localhost/nfd/faces/list/%FD%00%00%01L5%F1K%21 > > 2015-03-19 23:49:20.533 NFD[5139:69230] TRACE: [ContentStore] > find-under-prefix /localhost/nfd/faces/list/%FD%00%00%01L5%F1%3D%BF > > 2015-03-19 23:49:20.533 NFD[5139:69230] DEBUG: [ContentStore] matching > /localhost/nfd/faces/list/%FD%00%00%01L5%F1%3D%BF/%00%00 > > 2015-03-19 23:49:20.533 NFD[5139:69230] DEBUG: [Forwarder] onOutgoingData > face=257 data=/localhost/nfd/faces/list/%FD%00%00%01L5%F1%3D%BF/%00%00 > > 2015-03-19 23:49:20.534 NFD[5139:69230] TRACE: [TcpLocalFace] > [id=257,local=tcp4://127.0.0.1:6363,remote=tcp4://127.0.0.1:51868] > sendData > > 2015-03-19 23:49:20.534 NFD[5139:69230] TRACE: [TcpLocalFace] > [id=257,local=tcp4://127.0.0.1:6363,remote=tcp4://127.0.0.1:51868] > Successfully sent: 724 bytes > > 2015-03-19 23:49:20.637 NFD[5139:69230] DEBUG: [Forwarder] > onInterestFinalize interest=/localhost/nfd/faces/list satisfied > > You can see that I sent an Interest with exclude filter of [ANY, > %FD%00%00%01L5%F1K%21]. But somehow NFD decided to match this interest to > the data with suffix "%FD%00%00%01L5%F1%3D%BF/%00%00". Note that > "%FD%00%00%01L5%F1K%21" is larger than "%FD%00%00%01L5%F1%3D%BF" because > 'K' == 0x4B. So this data should have been filtered out... > > Thanks, > Wentao > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Fri Mar 20 08:26:53 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Fri, 20 Mar 2015 15:26:53 +0000 Subject: [Nfd-dev] Incorrect handling of exclude filter in CS lookup In-Reply-To: References: Message-ID: Ah, I see. There is a bug in my library :P Thanks for clearing my confusion! Wentao On Fri, Mar 20, 2015 at 12:31 AM Junxiao Shi wrote: > Hi Wentao > > This behavior is by design. > > The Interest has this Exclude Selector: > > > %FD%00%00%01L5%F1K%21 > > Note that there isn't a element between two NameComponents. > > The returned Data does not violate this Exclude Selector, because > %FD%00%00%01L5%F1%3D%BF doesn't appear in this Exclude Selector. > > Yours, Junxiao > > On Fri, Mar 20, 2015 at 12:02 AM, Wentao Shang > wrote: > >> Hi Junxiao, >> >> I found this problem on iOS using an "incorrect" implementation of the >> FaceStatus Dataset consumer. I'm not sure how to reproduce this error on >> normal computers yet. But here is a dump of log messages from NFD (this is >> the best I can get to describe the problem...): >> >> >> 2015-03-19 23:49:20.532 NFD[5139:69230] TRACE: [TcpLocalFace] >> [id=257,local=tcp4://127.0.0.1:6363,remote=tcp4://127.0.0.1:51868] >> Received: 63 bytes >> >> 2015-03-19 23:49:20.532 NFD[5139:69230] DEBUG: [Forwarder] >> onIncomingInterest face=257 >> interest=/localhost/nfd/faces/list?ndn.ChildSelector=1&ndn.InterestLifetime=1000&ndn.Nonce=1313767654&ndn.Exclude=...,%FD%00%00%01L5%F1K%21 >> >> >> 2015-03-19 23:49:20.533 NFD[5139:69230] DEBUG: [ContentStore] find >> /localhost/nfd/faces/list R >> >> 2015-03-19 23:49:20.533 NFD[5139:69230] TRACE: [ContentStore] >> find-under-prefix /localhost/nfd/faces/list/%FD%00%00%01L5%F1K%21 >> >> 2015-03-19 23:49:20.533 NFD[5139:69230] TRACE: [ContentStore] >> find-under-prefix /localhost/nfd/faces/list/%FD%00%00%01L5%F1%3D%BF >> >> 2015-03-19 23:49:20.533 NFD[5139:69230] DEBUG: [ContentStore] matching >> /localhost/nfd/faces/list/%FD%00%00%01L5%F1%3D%BF/%00%00 >> >> 2015-03-19 23:49:20.533 NFD[5139:69230] DEBUG: [Forwarder] onOutgoingData >> face=257 data=/localhost/nfd/faces/list/%FD%00%00%01L5%F1%3D%BF/%00%00 >> >> 2015-03-19 23:49:20.534 NFD[5139:69230] TRACE: [TcpLocalFace] >> [id=257,local=tcp4://127.0.0.1:6363,remote=tcp4://127.0.0.1:51868] >> sendData >> >> 2015-03-19 23:49:20.534 NFD[5139:69230] TRACE: [TcpLocalFace] >> [id=257,local=tcp4://127.0.0.1:6363,remote=tcp4://127.0.0.1:51868] >> Successfully sent: 724 bytes >> >> 2015-03-19 23:49:20.637 NFD[5139:69230] DEBUG: [Forwarder] >> onInterestFinalize interest=/localhost/nfd/faces/list satisfied >> >> You can see that I sent an Interest with exclude filter of [ANY, >> %FD%00%00%01L5%F1K%21]. But somehow NFD decided to match this interest to >> the data with suffix "%FD%00%00%01L5%F1%3D%BF/%00%00". Note that >> "%FD%00%00%01L5%F1K%21" is larger than "%FD%00%00%01L5%F1%3D%BF" because >> 'K' == 0x4B. So this data should have been filtered out... >> >> Thanks, >> Wentao >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanwake at UCLA.EDU Fri Mar 20 14:04:17 2015 From: alanwake at UCLA.EDU (Jiewen Tan) Date: Fri, 20 Mar 2015 14:04:17 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> <007501d05c34$48aebb90$da0c32b0$@ucla.edu> Message-ID: <015601d06351$6edd1db0$4c975910$@ucla.edu> Hi Junxiao, 1) All the operations you did are correct. Any modification to the NDNS database needs sudo privilege and All the certificates provided need to have the version number. 2) Actually, the current version of ndns-add-from-file is not capable to add a self-signed KSK to the NDNS database. It regards all the self-signed KSK as non-root certificate, and therefore it will resign the KSK using the zone?s DSK. Thank you for pointing out. I will add an option to add root certificate. Regards, Jiewen Tan From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu] Sent: Thursday, March 19, 2015 10:41 PM To: Jiewen Tan Cc: ; Xiaoke Jiang Subject: Re: [Nfd-dev] How to start a certificate chain from scratch Hi Jiewen I have tried these steps with ndns 0.0.2-ppa1~trusty. My experiences and questions are below. 1) create root zone a. ndns-create-zone * -k parameter must be the full certificate Name including the version component after ID-CERT, otherwise it complains "Error: Cannot verify KSK certificate". * sudo is needed, otherwise it complains "Error: INSERT INTO zones (name, ttl) VALUES (?, ?)", and operator's TPM is polluted with a useless DSK. 2) publish root certificate a. ndns-export-certificate (appears to be equivalent to ndnsec-dump-certificate) * first parameter must be the full certificate Name including the version component after ID-CERT, otherwise it complains "Error: Certificate name is illegal". b. ndns-add-rr-from-file * sudo is needed, otherwise it complains "Error: FileStore: error opening file for reading: /home/sunny/.ndn/ndnsec-tpm-file/KaThtq7TuD1zToRgAXsZ+QMEUA0e6A8O6rwm3f0vBlU=.pri" 3) create site1 zone a. ndns-create-zone * same as 1a, sudo is needed 4) delegate site1 zone from root zone a. ndns-add-rr * sudo is needed, otherwise it complains "Error: FileStore: error opening file for reading: /home/sunny/.ndn/ndnsec-tpm-file/KaThtq7TuD1zToRgAXsZ+QMEUA0e6A8O6rwm3f0vBlU=.pri" 5) publish site1 certificate a. ndns-export-certificate * same as 2a, first parameter must be the full certificate Name including the version component after ID-CERT; execute `ndnsec-list -c` to learn the full certificate Name. c. ndns-add-rr-from-file * same as 2b, sudo is needed 6) publish user1 certificate a. ndns-add-rr-from-file * sudo is needed, otherwise it complains "Error: FileStore: error opening file for reading: /home/sunny/.ndn/ndnsec-tpm-file/stCLw6BWTYfAe8nHMIocqKD9I9+rAglUbI6dbR%2oNM=.pri" However, after completing these steps, I'm still unable to fetch certificate with ndn-tlv-peek. It appears that ndns didn't register any routes in local NFD. ndns didn't create a log file in /var/log/ndn, so I can't see what's going on. Also, the root certificate doesn't seem correct. sunny at sunnyq ~ $ ndns-list-zone /root ; Zone /root ; rrset=/site1 type=NS version=%FD%00%00%01L5%A2k%D0 signed-by=/root/KEY/dsk-1426828258078/ID-CERT /site1 3600 NS /dsk-1426828258078 3600 ID-CERT ; content-type=NDNS-Raw version=%FD%00%00%01L5%97l%23 signed-by=/root/KEY/ksk-1426828193071/ID-CERT /ksk-1426828193071 3600 ID-CERT ; content-type=NDNS-Raw version=%FD%00%00%01L5%96n%83 signed-by=/root/KEY/dsk-1426828258078/ID-CERT /site1/ksk-1426828890240 3600 ID-CERT ; content-type=NDNS-Raw version=%FD%00%00%01L5%A1%12d signed-by=/root/KEY/dsk-1426828258078/ID-CERT This says that the root KSK is signed by the root DSK. It's not the original self-signed KSK. Yours, Junxiao On Wed, Mar 11, 2015 at 12:48 PM, Jiewen Tan wrote: Hi Junxiao, Assuming the root key and root certificate are already presented in the system(PIB), 1) Create root zone: /example a. ndns-create-zone /example -k /example/KEY/ksk-1/ID-CERT Here is to create a zone named /example using a KSK store in the PIB. It will also generate a DSK signed by the KSK provided automatically and insert the DSK to NDNS database (publish). All other options are set to default. 2) Publish root certificate: /example/KEY/ksk-1/ID-CERT a. ndns-export-certificate /example/KEY/ksk-1/ID-CERT Here is to export the root certificate to stdout. It can be exported to a file by using -f option as well. b. ndns-add-rr-from-file /example Here is to insert the root certificate into NDNS database (publish under zone /example). Default is to use stdin as input. So you can just copy&paste the output from 2.a. It will terminate with Ctrl+D. 3) Create site1 zone: /example/site1 a. ndns-create-zone /example/site1 Here, the tool will automatically generate a self-signed KSK and a corresponding DSK. Moreover, the DSK will be published automatically. 4) Delegate site1 zone from root zone a. ndns-add-rr -t resp /example /site1 NS Here is to add a rrset into zone: /example which has label: /site1 and type: /NS. Specifically, the content-type of the rrset is set to resp which indicate the existence of zone /example/site1. Now the delegation is completed. However, if the site zone is a leaf zone, a TXT type rrset is preferred. 5) Publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT (Site1?s KSK needs to be published in its parent zone, i.e. root zone.) a. ndns-export-certificate /example/KEY/site1/ksk-2/ID-CERT -f site1.cert Export the certificate from site1 zone. b. Pass the certificate to the parent zone, i.e. root zone here. (Use whatever methods you prefer) c. ndns-add-rr-from-file /example -f site1.cert Here the tool will resign the certificate with the zone?s DSK such that an authentication chain can be established. After that, it will publish the certificate in the NDNS database with label set to /site1/ksk-2 and type set to ID-CERT. 6) Publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT (Assuming it is stored as user1.cert) a. ndns-add-rr-from-file /example/site1 -f user1.cert Noticed again, this operation needs to be done in the parent zone, i.e. /example/site1. In NDNS, publishing a certificate is essentially meaning to insert the certificate into NDNS database as an ID-CERT rrset. Therefore, I use these two terms interchangeably here. Thank you for asking this question. I will try to make the answer as complete as possible and post this answer on the ndns-tr as appendix. BTW, Xiaoke please make any supplement to my explanation if necessary. Regards, Jiewen Tan From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu] Sent: Wednesday, March 11, 2015 11:56 AM To: Cc: Xiaoke Jiang; Jiewen Tan Subject: Re: [Nfd-dev] How to start a certificate chain from scratch Hi Xiaoke/Jiewen (correcting a typo below) Thanks for your examples. However, I need to start from scratch. Suppose: ? root/site/user certificates are created according to http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000616.html ? Two machines have NDNS package installed. One is to host root zone, the other is to host site1 zone. I need the commands to: ? create root zone: /example ? publish root certificate: /example/KEY/ksk-1/ID-CERT ? create site1 zone: /example/site1 ? delegate site1 zone from root zone ? publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT (should this be published at root zone or site1 zone?) ? publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Mar 20 20:05:46 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 20 Mar 2015 20:05:46 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: <015601d06351$6edd1db0$4c975910$@ucla.edu> References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> <007501d05c34$48aebb90$da0c32b0$@ucla.edu> <015601d06351$6edd1db0$4c975910$@ucla.edu> Message-ID: Hi Jiewen However, after completing these steps, I'm still unable to fetch certificate with ndn-tlv-peek. It appears that ndns didn't register any routes in local NFD. ndns didn't create a log file in /var/log/ndn, so I can't see what's going on. Any idea on how to diagnose this problem? Yours, Junxiao On Fri, Mar 20, 2015 at 2:04 PM, Jiewen Tan wrote: > Hi Junxiao, > > > > 1) All the operations you did are correct. Any modification to the > NDNS database needs sudo privilege and All the certificates provided need > to have the version number. > > 2) Actually, the current version of ndns-add-from-file is not > capable to add a self-signed KSK to the NDNS database. It regards all the > self-signed KSK as non-root certificate, and therefore it will resign the > KSK using the zone?s DSK. Thank you for pointing out. I will add an option > to add root certificate. > > > > Regards, > > Jiewen Tan > > > > *From:* Junxiao Shi [mailto:shijunxiao at email.arizona.edu] > *Sent:* Thursday, March 19, 2015 10:41 PM > *To:* Jiewen Tan > *Cc:* ; Xiaoke Jiang > *Subject:* Re: [Nfd-dev] How to start a certificate chain from scratch > > > > Hi Jiewen > > > > I have tried these steps with ndns 0.0.2-ppa1~trusty. > > My experiences and questions are below. > > > > 1) create root zone > > a. ndns-create-zone > > - -k parameter must be the full certificate Name including the version > component after ID-CERT, otherwise it complains "Error: Cannot verify KSK > certificate". > - sudo is needed, otherwise it complains "Error: INSERT INTO zones > (name, ttl) VALUES (?, ?)", and operator's TPM is polluted with a useless > DSK. > > > > 2) publish root certificate > > a. ndns-export-certificate (appears to be equivalent to > ndnsec-dump-certificate) > > - first parameter must be the full certificate Name including the > version component after ID-CERT, otherwise it complains "Error: Certificate > name is illegal". > > b. ndns-add-rr-from-file > > - sudo is needed, otherwise it complains "Error: FileStore: error > opening file for reading: > /home/sunny/.ndn/ndnsec-tpm-file/KaThtq7TuD1zToRgAXsZ+QMEUA0e6A8O6rwm3f0vBlU=.pri" > > > > 3) create site1 zone > > a. ndns-create-zone > > - same as 1a, sudo is needed > > > > 4) delegate site1 zone from root zone > > a. ndns-add-rr > > - sudo is needed, otherwise it complains "Error: FileStore: error > opening file for reading: > /home/sunny/.ndn/ndnsec-tpm-file/KaThtq7TuD1zToRgAXsZ+QMEUA0e6A8O6rwm3f0vBlU=.pri" > > > > 5) publish site1 certificate > > a. ndns-export-certificate > > - same as 2a, first parameter must be the full certificate Name > including the version component after ID-CERT; execute `ndnsec-list -c` to > learn the full certificate Name. > > c. ndns-add-rr-from-file > > - same as 2b, sudo is needed > > > > 6) publish user1 certificate > > a. ndns-add-rr-from-file > > - sudo is needed, otherwise it complains "Error: FileStore: error > opening file for reading: > /home/sunny/.ndn/ndnsec-tpm-file/stCLw6BWTYfAe8nHMIocqKD9I9+rAglUbI6dbR%2oNM=.pri" > > > > > > However, after completing these steps, I'm still unable to fetch > certificate with ndn-tlv-peek. > > It appears that ndns didn't register any routes in local NFD. > > ndns didn't create a log file in /var/log/ndn, so I can't see what's going > on. > > > > Also, the root certificate doesn't seem correct. > > sunny at sunnyq ~ $ ndns-list-zone /root > > ; Zone /root > > > > ; rrset=/site1 type=NS version=%FD%00%00%01L5%A2k%D0 > signed-by=/root/KEY/dsk-1426828258078/ID-CERT > > /site1 3600 NS > > > > /dsk-1426828258078 3600 ID-CERT ; content-type=NDNS-Raw > version=%FD%00%00%01L5%97l%23 signed-by=/root/KEY/ksk-1426828193071/ID-CERT > > > > /ksk-1426828193071 3600 ID-CERT ; content-type=NDNS-Raw > version=%FD%00%00%01L5%96n%83 signed-by=/root/KEY/dsk-1426828258078/ID-CERT > > > > /site1/ksk-1426828890240 3600 ID-CERT ; content-type=NDNS-Raw > version=%FD%00%00%01L5%A1%12d signed-by=/root/KEY/dsk-1426828258078/ID-CERT > > This says that the root KSK is signed by the root DSK. It's not the > original self-signed KSK. > > > > Yours, Junxiao > > > > On Wed, Mar 11, 2015 at 12:48 PM, Jiewen Tan wrote: > > Hi Junxiao, > > > > Assuming the root key and root certificate are already presented in the > system(PIB), > > 1) Create root zone: /example > > a. ndns-create-zone /example -k /example/KEY/ksk-1/ID-CERT > > Here is to create a zone named /example using a KSK store in the PIB. It > will also generate a DSK signed by the KSK provided automatically and > insert the DSK to NDNS database (publish). All other options are set to > default. > > 2) Publish root certificate: /example/KEY/ksk-1/ID-CERT > > a. ndns-export-certificate /example/KEY/ksk-1/ID-CERT > > Here is to export the root certificate to stdout. It can be exported to a > file by using -f option as well. > > b. ndns-add-rr-from-file /example > > Here is to insert the root certificate into NDNS database (publish under > zone /example). Default is to use stdin as input. So you can just > copy&paste the output from 2.a. It will terminate with Ctrl+D. > > 3) Create site1 zone: /example/site1 > > a. ndns-create-zone /example/site1 > > Here, the tool will automatically generate a self-signed KSK and a > corresponding DSK. Moreover, the DSK will be published automatically. > > 4) Delegate site1 zone from root zone > > a. ndns-add-rr -t resp /example /site1 NS > > Here is to add a rrset into zone: /example which has label: /site1 and > type: /NS. Specifically, the content-type of the rrset is set to resp which > indicate the existence of zone /example/site1. Now the delegation is > completed. However, if the site zone is a leaf zone, a TXT type rrset is > preferred. > > 5) Publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT > (Site1?s KSK needs to be published in its parent zone, i.e. root zone.) > > a. ndns-export-certificate /example/KEY/site1/ksk-2/ID-CERT -f > site1.cert > > Export the certificate from site1 zone. > > b. Pass the certificate to the parent zone, i.e. root zone here. > (Use whatever methods you prefer) > > c. ndns-add-rr-from-file /example -f site1.cert > > Here the tool will resign the certificate with the zone?s DSK such that an > authentication chain can be established. After that, it will publish the > certificate in the NDNS database with label set to /site1/ksk-2 and type > set to ID-CERT. > > 6) Publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT > (Assuming it is stored as user1.cert) > > a. ndns-add-rr-from-file /example/site1 -f user1.cert > > Noticed again, this operation needs to be done in the parent zone, i.e. > /example/site1. > > > > In NDNS, publishing a certificate is essentially meaning to insert the > certificate into NDNS database as an ID-CERT rrset. Therefore, I use these > two terms interchangeably here. > > > > Thank you for asking this question. I will try to make the answer as > complete as possible and post this answer on the ndns-tr as appendix. > > > > BTW, Xiaoke please make any supplement to my explanation if necessary. > > > > Regards, > > Jiewen Tan > > *From:* Junxiao Shi [mailto:shijunxiao at email.arizona.edu] > *Sent:* Wednesday, March 11, 2015 11:56 AM > *To:* > *Cc:* Xiaoke Jiang; Jiewen Tan > *Subject:* Re: [Nfd-dev] How to start a certificate chain from scratch > > > > Hi Xiaoke/Jiewen > > (correcting a typo below) > > > > Thanks for your examples. However, I need to start from scratch. Suppose: > > ? root/site/user certificates are created according to > http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000616.html > > ? Two machines have NDNS package installed. One is to host root zone, > the other is to host site1 zone. > > I need the commands to: > > ? create root zone: /example > > ? publish root certificate: /example/KEY/ksk-1/ID-CERT > > ? create site1 zone: /example/site1 > > ? delegate site1 zone from root zone > > ? publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT (should > this be published at root zone or site1 zone?) > > ? publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT > > > > Yours, Junxiao > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shock.jiang at gmail.com Fri Mar 20 20:23:08 2015 From: shock.jiang at gmail.com (Xiaoke Jiang) Date: Fri, 20 Mar 2015 20:23:08 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> <007501d05c34$48aebb90$da0c32b0$@ucla.edu> <015601d06351$6edd1db0$4c975910$@ucla.edu> Message-ID: <7CE5489F-45F7-4A48-B2FB-07BB49BBAD06@gmail.com> Hi Junxiao, > On 20 Mar, 2015, at 8:05 pm, Junxiao Shi wrote: > > Hi Jiewen > > However, after completing these steps, I'm still unable to fetch certificate with ndn-tlv-peek. I just tried ndn-tlv-peek /ndn/edu/ucla/NDNS/alice/TXT, and it works the point is, do NOT add the version number in the interest name. > It appears that ndns didn't register any routes in local NFD. that is not true. > ndns didn't create a log file in /var/log/ndn, so I can't see what's going on. > there is a log configuration, /usr/local/etc/ndns/log4cxx.properties, and when you start ndns-daemon, log will be printed to console. And you can also define you own log attributes to print it to file. > Any idea on how to diagnose this problem? > > Yours, Junxiao > > On Fri, Mar 20, 2015 at 2:04 PM, Jiewen Tan > wrote: > Hi Junxiao, > > > > 1) All the operations you did are correct. Any modification to the NDNS database needs sudo privilege and All the certificates provided need to have the version number. > > 2) Actually, the current version of ndns-add-from-file is not capable to add a self-signed KSK to the NDNS database. It regards all the self-signed KSK as non-root certificate, and therefore it will resign the KSK using the zone?s DSK. Thank you for pointing out. I will add an option to add root certificate. > > > > Regards, > > Jiewen Tan > > > > From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu ] > Sent: Thursday, March 19, 2015 10:41 PM > To: Jiewen Tan > Cc: >; Xiaoke Jiang > > Subject: Re: [Nfd-dev] How to start a certificate chain from scratch > > > > Hi Jiewen > > > > I have tried these steps with ndns 0.0.2-ppa1~trusty. > > My experiences and questions are below. > > > > 1) create root zone > > a. ndns-create-zone > > -k parameter must be the full certificate Name including the version component after ID-CERT, otherwise it complains "Error: Cannot verify KSK certificate". > sudo is needed, otherwise it complains "Error: INSERT INTO zones (name, ttl) VALUES (?, ?)", and operator's TPM is polluted with a useless DSK. > > > 2) publish root certificate > > a. ndns-export-certificate (appears to be equivalent to ndnsec-dump-certificate) > > first parameter must be the full certificate Name including the version component after ID-CERT, otherwise it complains "Error: Certificate name is illegal". > b. ndns-add-rr-from-file > > sudo is needed, otherwise it complains "Error: FileStore: error opening file for reading: /home/sunny/.ndn/ndnsec-tpm-file/KaThtq7TuD1zToRgAXsZ+QMEUA0e6A8O6rwm3f0vBlU=.pri" > > > 3) create site1 zone > > a. ndns-create-zone > > same as 1a, sudo is needed > > > 4) delegate site1 zone from root zone > > a. ndns-add-rr > > sudo is needed, otherwise it complains "Error: FileStore: error opening file for reading: /home/sunny/.ndn/ndnsec-tpm-file/KaThtq7TuD1zToRgAXsZ+QMEUA0e6A8O6rwm3f0vBlU=.pri" > > > 5) publish site1 certificate > > a. ndns-export-certificate > > same as 2a, first parameter must be the full certificate Name including the version component after ID-CERT; execute `ndnsec-list -c` to learn the full certificate Name. > c. ndns-add-rr-from-file > > same as 2b, sudo is needed > > > 6) publish user1 certificate > > a. ndns-add-rr-from-file > > sudo is needed, otherwise it complains "Error: FileStore: error opening file for reading: /home/sunny/.ndn/ndnsec-tpm-file/stCLw6BWTYfAe8nHMIocqKD9I9+rAglUbI6dbR%2oNM=.pri" > > > > > However, after completing these steps, I'm still unable to fetch certificate with ndn-tlv-peek. > > It appears that ndns didn't register any routes in local NFD. > > ndns didn't create a log file in /var/log/ndn, so I can't see what's going on. > > > > Also, the root certificate doesn't seem correct. > > sunny at sunnyq ~ $ ndns-list-zone /root > > ; Zone /root > > > > ; rrset=/site1 type=NS version=%FD%00%00%01L5%A2k%D0 signed-by=/root/KEY/dsk-1426828258078/ID-CERT > > /site1 3600 NS > > > > /dsk-1426828258078 3600 ID-CERT ; content-type=NDNS-Raw version=%FD%00%00%01L5%97l%23 signed-by=/root/KEY/ksk-1426828193071/ID-CERT > > > > /ksk-1426828193071 3600 ID-CERT ; content-type=NDNS-Raw version=%FD%00%00%01L5%96n%83 signed-by=/root/KEY/dsk-1426828258078/ID-CERT > > > > /site1/ksk-1426828890240 3600 ID-CERT ; content-type=NDNS-Raw version=%FD%00%00%01L5%A1%12d signed-by=/root/KEY/dsk-1426828258078/ID-CERT > > This says that the root KSK is signed by the root DSK. It's not the original self-signed KSK. > > > > Yours, Junxiao > > > > On Wed, Mar 11, 2015 at 12:48 PM, Jiewen Tan > wrote: > > Hi Junxiao, > > > > Assuming the root key and root certificate are already presented in the system(PIB), > > 1) Create root zone: /example > > a. ndns-create-zone /example -k /example/KEY/ksk-1/ID-CERT > > Here is to create a zone named /example using a KSK store in the PIB. It will also generate a DSK signed by the KSK provided automatically and insert the DSK to NDNS database (publish). All other options are set to default. > > 2) Publish root certificate: /example/KEY/ksk-1/ID-CERT > > a. ndns-export-certificate /example/KEY/ksk-1/ID-CERT > > Here is to export the root certificate to stdout. It can be exported to a file by using -f option as well. > > b. ndns-add-rr-from-file /example > > Here is to insert the root certificate into NDNS database (publish under zone /example). Default is to use stdin as input. So you can just copy&paste the output from 2.a. It will terminate with Ctrl+D. > > 3) Create site1 zone: /example/site1 > > a. ndns-create-zone /example/site1 > > Here, the tool will automatically generate a self-signed KSK and a corresponding DSK. Moreover, the DSK will be published automatically. > > 4) Delegate site1 zone from root zone > > a. ndns-add-rr -t resp /example /site1 NS > > Here is to add a rrset into zone: /example which has label: /site1 and type: /NS. Specifically, the content-type of the rrset is set to resp which indicate the existence of zone /example/site1. Now the delegation is completed. However, if the site zone is a leaf zone, a TXT type rrset is preferred. > > 5) Publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT (Site1?s KSK needs to be published in its parent zone, i.e. root zone.) > > a. ndns-export-certificate /example/KEY/site1/ksk-2/ID-CERT -f site1.cert > > Export the certificate from site1 zone. > > b. Pass the certificate to the parent zone, i.e. root zone here. (Use whatever methods you prefer) > > c. ndns-add-rr-from-file /example -f site1.cert > > Here the tool will resign the certificate with the zone?s DSK such that an authentication chain can be established. After that, it will publish the certificate in the NDNS database with label set to /site1/ksk-2 and type set to ID-CERT. > > 6) Publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT (Assuming it is stored as user1.cert) > > a. ndns-add-rr-from-file /example/site1 -f user1.cert > > Noticed again, this operation needs to be done in the parent zone, i.e. /example/site1. > > > > In NDNS, publishing a certificate is essentially meaning to insert the certificate into NDNS database as an ID-CERT rrset. Therefore, I use these two terms interchangeably here. > > > > Thank you for asking this question. I will try to make the answer as complete as possible and post this answer on the ndns-tr as appendix. > > > > BTW, Xiaoke please make any supplement to my explanation if necessary. > > > > Regards, > > Jiewen Tan > > From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu ] > Sent: Wednesday, March 11, 2015 11:56 AM > To: > > Cc: Xiaoke Jiang; Jiewen Tan > Subject: Re: [Nfd-dev] How to start a certificate chain from scratch > > > > Hi Xiaoke/Jiewen > > (correcting a typo below) > > > > Thanks for your examples. However, I need to start from scratch. Suppose: > > ? root/site/user certificates are created according to http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000616.html > ? Two machines have NDNS package installed. One is to host root zone, the other is to host site1 zone. > > I need the commands to: > > ? create root zone: /example > > ? publish root certificate: /example/KEY/ksk-1/ID-CERT > > ? create site1 zone: /example/site1 > > ? delegate site1 zone from root zone > > ? publish site1 certificate: /example/KEY/site1/ksk-2/ID-CERT (should this be published at root zone or site1 zone?) > > ? publish user1 certificate: /example/site1/KEY/user1/ksk-3/ID-CERT > > > > Yours, Junxiao > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Mar 20 20:41:41 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 20 Mar 2015 20:41:41 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: <7CE5489F-45F7-4A48-B2FB-07BB49BBAD06@gmail.com> References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> <007501d05c34$48aebb90$da0c32b0$@ucla.edu> <015601d06351$6edd1db0$4c975910$@ucla.edu> <7CE5489F-45F7-4A48-B2FB-07BB49BBAD06@gmail.com> Message-ID: Hi Jiewen This laptop has ndns installed from ppa:named-data/ppa. I found the configuration in /etc/ndns. It's somewhat inconsistent for ndns to put its configuration in /etc/ndns, while all other programs (such as NFD, NLSR, etc) put their configuration in /etc/ndn. There is no example in /etc/ndns/log4cxx.properties or /etc/ndns/log4cxx.properties.sample for how to append logs to a file. I notice that while `sudo service ndns restart` reports success, there's no ndns process. sunny at sunnyq ~ $ sudo service ndns restart stop: Unknown instance: ndns start/running, process 11515 sunny at sunnyq ~ $ ps aux | grep ndns sunny 11566 0.0 0.0 13416 932 pts/7 S+ 20:36 0:00 grep --colour=auto ndns Running ndns-daemon in console: the process exits automatically. No daemon process is forked. Nothing is printed to stdout or stderr. sunny at sunnyq ~ $ sudo ndns-daemon -c /etc/ndns/ndns.conf sunny at sunnyq ~ $ ps aux | grep ndns sunny 11682 0.0 0.0 13416 932 pts/7 S+ 20:36 0:00 grep --colour=auto ndns Running in gdb shows that the process exited normally. There's no crash. Is there something wrong with the PPA package? Yours, Junxiao On Fri, Mar 20, 2015 at 8:23 PM, Xiaoke Jiang wrote: > Hi Junxiao, > > On 20 Mar, 2015, at 8:05 pm, Junxiao Shi > wrote: > > Hi Jiewen > > However, after completing these steps, I'm still unable to fetch > certificate with ndn-tlv-peek. > > I just tried ndn-tlv-peek /ndn/edu/ucla/NDNS/alice/TXT, and it works > the point is, do NOT add the version number in the interest name. > > > It appears that ndns didn't register any routes in local NFD. > > that is not true. > > ndns didn't create a log file in /var/log/ndn, so I can't see what's going > on. > > there is a log configuration, /usr/local/etc/ndns/log4cxx.properties, and > when you start ndns-daemon, log will be printed to console. > And you can also define you own log attributes to print it to file. > > Any idea on how to diagnose this problem? > > Yours, Junxiao > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shock.jiang at gmail.com Fri Mar 20 20:43:54 2015 From: shock.jiang at gmail.com (Xiaoke Jiang) Date: Fri, 20 Mar 2015 20:43:54 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> <007501d05c34$48aebb90$da0c32b0$@ucla.edu> <015601d06351$6edd1db0$4c975910$@ucla.edu> <7CE5489F-45F7-4A48-B2FB-07BB49BBAD06@gmail.com> Message-ID: <9A21C5D9-EAA4-4F90-8E5D-E338C2507569@gmail.com> ppa contains an early version of ndns, so I recommend you to install from the source code. Xiaoke (Shock) > On 20 Mar, 2015, at 8:41 pm, Junxiao Shi wrote: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.ARIZONA.EDU Fri Mar 20 20:51:55 2015 From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi) Date: Fri, 20 Mar 2015 20:51:55 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: <9A21C5D9-EAA4-4F90-8E5D-E338C2507569@gmail.com> References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> <007501d05c34$48aebb90$da0c32b0$@ucla.edu> <015601d06351$6edd1db0$4c975910$@ucla.edu> <7CE5489F-45F7-4A48-B2FB-07BB49BBAD06@gmail.com> <9A21C5D9-EAA4-4F90-8E5D-E338C2507569@gmail.com> Message-ID: Hi Xiaoke I'll just wait for the next PPA release. Yours, Junxiao On Fri, Mar 20, 2015 at 8:43 PM, Xiaoke Jiang wrote: > ppa contains an early version of ndns, so I recommend you to install from > the source code. > > Xiaoke (Shock) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shock.jiang at gmail.com Fri Mar 20 20:53:58 2015 From: shock.jiang at gmail.com (Xiaoke Jiang) Date: Fri, 20 Mar 2015 20:53:58 -0700 Subject: [Nfd-dev] How to start a certificate chain from scratch In-Reply-To: References: <024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu> <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu> <007501d05c34$48aebb90$da0c32b0$@ucla.edu> <015601d06351$6edd1db0$4c975910$@ucla.edu> <7CE5489F-45F7-4A48-B2FB-07BB49BBAD06@gmail.com> <9A21C5D9-EAA4-4F90-8E5D-E338C2507569@gmail.com> Message-ID: Hi Junxiao, function wise, ppa contains the latest version. Xiaoke (Shock) > On 20 Mar, 2015, at 8:51 pm, Junxiao Shi wrote: > > Hi Xiaoke > > I'll just wait for the next PPA release. > > Yours, Junxiao > > On Fri, Mar 20, 2015 at 8:43 PM, Xiaoke Jiang > wrote: > ppa contains an early version of ndns, so I recommend you to install from the source code. > > Xiaoke (Shock) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.UCLA.EDU Sat Mar 21 13:44:00 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Sat, 21 Mar 2015 20:44:00 +0000 Subject: [Nfd-dev] Behavior of "on demand" faces to applications In-Reply-To: <9C3A05EE-C260-4C74-B136-A9787C1DA8A7@ucla.edu> Message-ID: Alex / nfd folks, We're going to make sure local connections are through unix sockets whenever available. Two quick related questions. Feel free to send a RTFM pointer: #A - - Is there a built-in way for "persistent" routes to get re-established if the TCP connection goes down? I interpreted your original description to mean this is not the default behavior. #B - In the case of UDP faces, what happens in this situation: 1. nfdc is used to register (with a local NFD) a persistent UDP face for a remote NFD 2. The face is created successfully 3. The remote NFD is killed and then restarted Is the intended behavior that the face created in #1 is still up after #3? (And, has this been the case in all versions of NFD? I am debugging a problem on an installation running an older version of NFD on the Raspberry PI.) Thanks! Jeff From: Alex Afanasyev > Date: Fri, 13 Mar 2015 16:53:37 -0700 To: "Gusev, Peter" > Cc: Jeff Burke >, "nfd-dev at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications This could be some side effect of tcp connection, though nothing really should be happening bad. Do not use TCP to connect to local daemon, unless it is your only option. You should enable DEBUG level on TcpFace, TcpLocalFace, FaceTable and see why face is removed. On Mar 13, 2015, at 4:40 PM, Gusev, Peter > wrote: Hi Alex, The face is created in pretty standard way - here is the code. JeffT?s NDN-CPP library uses TcpTransport to connect to local NFD. When we noticed that consumer is not getting any data, but producer is alive and no exceptions were thrown (like socket destroyed or similar), we checked nfd-status output and discovered that there is no face with producer?s prefix anymore. The only fact that producer was running for some lengthy time (20-30 minutes) and no interests were issued for its? data during this period made us think it might be ?on-demand? faces? problem... Thanks, -- Peter Gusev Programmer/Analyst @ REMAP, UCLA peter at remap.ucla.edu +1 213 5872748 peetonn_ (skype) On Mar 13, 2015, at 4:31 PM, Burke, Jeff > wrote: Thanks, Alex. Peter, can you explain where you were seeing this? I thought it was with an app face, not udp... -----Original Message----- From: Alex Afanasyev [alexander.afanasyev at ucla.edu] Received: Friday, 13 Mar 2015, 4:25PM To: Burke, Jeff [jburke at remap.ucla.edu] CC: nfd-dev at lists.cs.ucla.edu [nfd-dev at lists.cs.ucla.edu] Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications On Mar 13, 2015, at 4:13 PM, Burke, Jeff > wrote: Hi folks, Could you please confirm the default behavior of "on-demand" face creation for applications? My understanding: The face created by default when an application registers a prefix is "on demand", meaning it can be destroyed by NFD if inactive for some timeout period. Not exactly (may be I misunderstood the question). Whenever face is created by an explicit command, it is ?persistent? (we also reserved concept ?permanent?, but it is not yet implemented). On-demand face is face that is created as a response of incoming tcp connect or packet received on UDP face. Only UDP face can get destroyed, TCP faces exist for as long tcp connection is alive. * * * If you?re referring to the UDP face from the the other side of tunnel, then yes. That face is on-demand and can be destroyed on the other side if no traffic. Remote registration built in into NFD/RIB management can take care of proper refreshing state. This is currently implemented, but requires some conventions on registered namespaces / available keys (it is documented in TR Yanbiao is working). This behavior has caused some troubleshooting challenges with a long-running publisher and occasionally interested consumers. Some questions: - Where is this behavior documented? It is mentioned in p10 of the developer's guide, but I can't find either the constant or configuration parameter that sets it. Some documentation regarding default values used is also available in nfd.conf.sample. - Is it the case that on-demand faces will not be destroyed if any traffic has traversed them? Or just that no traffic has traversed during the timeout interval? Not sure I understood the question. on-demand udp face will not be destroyed if at least one packet (data/interest) is received during the timeout interval. - What is the appropriate way to create a face that persists until the process that created it is either destroyed or unregistered the prefix? Rely on remote registration process (I would say this is preferred). Alternatively, this could be something else that periodically send interest towards the remote end. Thank you, Jeff _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sat Mar 21 14:04:41 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 21 Mar 2015 14:04:41 -0700 Subject: [Nfd-dev] Behavior of "on demand" faces to applications In-Reply-To: References: <9C3A05EE-C260-4C74-B136-A9787C1DA8A7@ucla.edu> Message-ID: Hi Jeff A A *persistent* TCP face is considered *failed* when TCP connection is broken. There's no built-in way to re-establish the connection and routes. #2491 will provide the concept of *permanent* face which does exactly that: TCP connection is re-established after it's broken, and FaceId remains unchanged. This is still in early idea stage. The workaround used by NDN6.TK is: 1. use facemon to monitor face destroy events 2. pipe the output of facemon to an awk script 3. in the awk script, if the face to the uplink router is destroyed, invoke nfdc register to re-establish the face and register static routes I'm attaching the awk script for reference. B A *persistent* UDP unicast face is considered *failed* when it receives an ICMP error. During the restart of remote NFD, if local NFD sends a UDP packet and gets back an ICMP error, the face will be destryoed; if local NFD doesn't send during this period, the face should be intact. As I remember, this behavior dates back to May 2014, and hasn't been significantly changed since then. You may use iptables to block incoming ICMP PortUnreachable error to avoid face getting destroy. Otherwise, the workaround above is also effective. Yours, Junxiao On Sat, Mar 21, 2015 at 1:44 PM, Burke, Jeff wrote: > Alex / nfd folks, > > We're going to make sure local connections are through unix sockets > whenever available. > > Two quick related questions. Feel free to send a RTFM pointer: > > #A - > - Is there a built-in way for "persistent" routes to get re-established if > the TCP connection goes down? I interpreted your original description to > mean this is not the default behavior. > > #B - > In the case of UDP faces, what happens in this situation: > > 1. nfdc is used to register (with a local NFD) a persistent UDP face for > a remote NFD > 2. The face is created successfully > 3. The remote NFD is killed and then restarted > > Is the intended behavior that the face created in #1 is still up after > #3? (And, has this been the case in all versions of NFD? I am debugging > a problem on an installation running an older version of NFD on the > Raspberry PI.) > > Thanks! > Jeff > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tunnels.sh Type: application/x-sh Size: 1032 bytes Desc: not available URL: From zhtaoxiang at gmail.com Mon Mar 23 13:57:53 2015 From: zhtaoxiang at gmail.com (Haitao Zhang) Date: Mon, 23 Mar 2015 13:57:53 -0700 Subject: [Nfd-dev] NDNFit mobile cert design Message-ID: Hi folks, I will give a short talk about NDNFit mobile certificate design during NFD call. Attached is my slides. Comments and suggestions are welcomed! Thank you so much. -- Best, -Haitao -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NDNFit mobile cert-0323-v2.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 60804 bytes Desc: not available URL: From jburke at remap.UCLA.EDU Wed Mar 25 11:04:16 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Wed, 25 Mar 2015 18:04:16 +0000 Subject: [Nfd-dev] Behavior of "on demand" faces to applications In-Reply-To: Message-ID: Hi Junxiao, Thanks, this is very helpful. (@AlexH: We should probably implement this for all the permanent routes on borges & memoria.) I have added an issue in redmine to document face creation/destruction behavior ? this is something that should be easily understood by anyone deploying a multi-node application in a semi-real-world environment. As Lan points out in issue 2491, not having "permanent" faces creates deployment challenges. I would suggest that the NFD team make permanent face support (for any underlying transport) a high priority for implementation, and easily selected?even perhaps the default?in routes created by 'nfdc register'. Given that we try to use UDP wherever possible (so as not to create an invisible crutch of ordering and reliability for apps deployed on top), support for permanent UDP faces is actually higher for us than TCP, though both are used. A few use cases on our end: - We have a few Raspberry PIs deployed in an outdoor installation, which connect to each other via a wire and use NDN over UDP to communicate. One has a WiFi connection to the campus network, and uses NDN over TCP to get data from a remote process. Occasionally, we restart one of the NFDs and not the other. Also, occasionally, we have brief dropouts of wireless connectivity to the campus network. In both cases, we lose the NDN faces and lose uptime of something that's supposed to run continuously. While Junxiao's approach provides a solution, it involves running additional components, etc. Given that we are running out of time on that project, I'm probably going to remove NDN communication because of this and some performance issues on the PIs. Better would be if NFD itself handled intermittent connectivity losses more robustly as proposed in the "permanent face". - We have now a small number of persistent services (which we are trying to increase) that are designed to run unattended for long periods of time. (e.g., the ndnfs publisher for ndn content). This would be very useful to have. While the TCP connections are more stable, we are always upgrading / restarting versions of NFD, adding routes, etc. So a low-overhead way of having permanent routes would be extremely helpful. The "permanent" behavior seems to be the most typically desired for any manually registered routes ? whether for the lifetime of the NFD daemon (in the nfdc-created case) or the lifetime of an application process (in the app-created case). I hope this can be considered for implementation soon... Thanks!! Jeff From: Junxiao Shi > Date: Sat, 21 Mar 2015 14:04:41 -0700 To: Jeff Burke > Cc: Alex Afanasyev >, "Gusev, Peter" >, "nfd-dev at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications Hi Jeff A A persistent TCP face is considered failed when TCP connection is broken. There's no built-in way to re-establish the connection and routes. #2491 will provide the concept of permanent face which does exactly that: TCP connection is re-established after it's broken, and FaceId remains unchanged. This is still in early idea stage. The workaround used by NDN6.TK is: 1. use facemon to monitor face destroy events 2. pipe the output of facemon to an awk script 3. in the awk script, if the face to the uplink router is destroyed, invoke nfdc register to re-establish the face and register static routes I'm attaching the awk script for reference. B A persistent UDP unicast face is considered failed when it receives an ICMP error. During the restart of remote NFD, if local NFD sends a UDP packet and gets back an ICMP error, the face will be destryoed; if local NFD doesn't send during this period, the face should be intact. As I remember, this behavior dates back to May 2014, and hasn't been significantly changed since then. You may use iptables to block incoming ICMP PortUnreachable error to avoid face getting destroy. Otherwise, the workaround above is also effective. Yours, Junxiao On Sat, Mar 21, 2015 at 1:44 PM, Burke, Jeff > wrote: Alex / nfd folks, We're going to make sure local connections are through unix sockets whenever available. Two quick related questions. Feel free to send a RTFM pointer: #A - - Is there a built-in way for "persistent" routes to get re-established if the TCP connection goes down? I interpreted your original description to mean this is not the default behavior. #B - In the case of UDP faces, what happens in this situation: 1. nfdc is used to register (with a local NFD) a persistent UDP face for a remote NFD 2. The face is created successfully 3. The remote NFD is killed and then restarted Is the intended behavior that the face created in #1 is still up after #3? (And, has this been the case in all versions of NFD? I am debugging a problem on an installation running an older version of NFD on the Raspberry PI.) Thanks! Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tunnels[3].sh Type: application/octet-stream Size: 1033 bytes Desc: tunnels[3].sh URL: From jburke at remap.UCLA.EDU Fri Mar 27 21:54:56 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Sat, 28 Mar 2015 04:54:56 +0000 Subject: [Nfd-dev] Examples of setting up NFD networks In-Reply-To: <72E81791-D1F7-4734-B0B3-1E8D295ECF68@wustl.edu> Message-ID: Hi John, Just catching up on this thread ? yes, I think it would make sense to put our notes on a wiki ? but perhaps a public one in the named-data redmine? Would that make sense, or do you anticipate internal details that we wouldn't make public. Then, as Junxiao suggests, we can port the best notes over to articles on the website. Thanks, Jeff From: "Dehart, John" > Date: Fri, 27 Feb 2015 16:54:17 +0000 To: Jeff Burke > Cc: "nfd-dev at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] Examples of setting up NFD networks Jeff, Would it make sense to put together something on the NDN Wiki? https://ndnpub.caida.org/bin/view/NDN/WebHome I just went through some of the pages there and there is a lot that is out of date. John On Feb 27, 2015, at 12:37 AM, Burke, Jeff > wrote: Hi folks, I am curious where the best place to look is for (or where one could eventually contribute some) examples of actually settings up networkswith NFD, even just simple ones using static routes. There is a brief mention of nfdc in the install.html but I am looking for a little more of a guidebook for an operator that briefly introduces all of the tools, explains how to set up a small multi-node network and test connectivity, maybe even introduces strategy. Does such a thing exist? Thanks, Jeff _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.UCLA.EDU Sat Mar 28 12:01:56 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Sat, 28 Mar 2015 19:01:56 +0000 Subject: [Nfd-dev] Techniques for prioritizing audio in NdnCon In-Reply-To: Message-ID: Hi folks, We are trying to get NdnCon into use for practical conferencing soon. It is clear that audio quality ? in particular, minimizing dropouts ? is critical. Prioritizing audio over video performance when there are bandwidth / latency issues is something that can to some extent be done in the application. But I am wondering if there are any tools that the architecture can provide as well. In particular, can the notion of one-hop priority could be discussed further? Originally, when we had discussed implementations of scalable video coding over NDN with Van, he had suggested that one-hop priority might be useful. This is not end-to-end QoS but rather just a hint/request to the upstream hop on which interests the app would like fulfilled first. It could be propagated or not. In SVC streaming, such a capability would enable the consuming application to issue interests for the base layer with higher priority than those for the enhancement layer(s) without having to add complex machinery in the consumer to try to do this at the application level. (The pipelining/buffering machinery for low-latency communication is already somewhat tricky.) Looking at ndnrtc now, this capability could actually be very useful for prioritizing interests audio over video as well. What do people think? Is this something that could be considered / experimented with? Any other ideas? Thanks, Jeff ps. See my message to the ndn list ? it would be great if NFD developers could try out NdnCon! -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sat Mar 28 12:43:41 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 28 Mar 2015 12:43:41 -0700 Subject: [Nfd-dev] HOWTO: clone the NFD repository Message-ID: Dear folks I got question on how to clone the NFD repository for development purpose. Here's the procedure: 1. in a web browser, navigate to http://gerrit.named-data.net 2. click "Sign In" link on top-right corner, click "Google OAuth2", and then authenticate with your Google Account 3. after you are redirected back to Gerrit system, click "Projects - List" menu item on top navigate bar 4. type "NFD" in "Filter" textbox 5. click "NFD" table row 6. under "Project NFD" title, click "clone with commit-msg hook" and "SSH" buttons 7. find the textbox below "clone with commit-msg hook" (it should start with "git clone ssh:/") 8. the contents in this textbox is the complete command line needed to clone the NFD repository Note: the development machine must have git and openssh-client installed. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sat Mar 28 21:09:28 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 28 Mar 2015 21:09:28 -0700 Subject: [Nfd-dev] Techniques for prioritizing audio in NdnCon In-Reply-To: References: Message-ID: Hi Jeff Priority delivery is an interesting idea. Can you recommend some RFCs and papers about how to achieve this effect in IP networks? Yours, Junxiao On Sat, Mar 28, 2015 at 12:01 PM, Burke, Jeff wrote: > > > Hi folks, > > We are trying to get NdnCon into use for practical conferencing soon. > > It is clear that audio quality ? in particular, minimizing dropouts ? is > critical. Prioritizing audio over video performance when there are > bandwidth / latency issues is something that can to some extent be done in > the application. But I am wondering if there are any tools that the > architecture can provide as well. > > In particular, can the notion of one-hop priority could be discussed > further? > > Originally, when we had discussed implementations of scalable video > coding over NDN with Van, he had suggested that one-hop priority might be > useful. This is not end-to-end QoS but rather just a hint/request to the > upstream hop on which interests the app would like fulfilled first. It > could be propagated or not. > > In SVC streaming, such a capability would enable the consuming > application to issue interests for the base layer with higher priority than > those for the enhancement layer(s) without having to add complex machinery > in the consumer to try to do this at the application level. (The > pipelining/buffering machinery for low-latency communication is already > somewhat tricky.) > > Looking at ndnrtc now, this capability could actually be very useful for > prioritizing interests audio over video as well. > > What do people think? Is this something that could be considered / > experimented with? Any other ideas? > > Thanks, > Jeff > > ps. See my message to the ndn list ? it would be great if NFD > developers could try out NdnCon! > > > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Sat Mar 28 22:06:49 2015 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Sun, 29 Mar 2015 05:06:49 +0000 Subject: [Nfd-dev] Techniques for prioritizing audio in NdnCon In-Reply-To: Message-ID: Hi Junxiao, I will do some digging, but this is interesting: Bonald, Thomas, Luca Muscariello, and Norberto Ostallo. "Self-prioritization of audio and video traffic." Communications (ICC), 2011 IEEE International Conference on. IEEE, 2011. http://perso.telecom-paristech.fr/~bonald/Publications_files/BMO2011.pdf (Instead of identifying packets as part of a "flow", one would use namespace or priority flag hints.) There are follow up papers to this one, too. Interesting to note that Muscariello (and a later co-author, Carofiglio) are now doing ICN research. (There are RTCP receiver reports in RTP streaming, too. ) Jeff From: Junxiao Shi > Date: Sat, 28 Mar 2015 21:09:28 -0700 To: Jeff Burke > Cc: "nfd-dev at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] Techniques for prioritizing audio in NdnCon Hi Jeff Priority delivery is an interesting idea. Can you recommend some RFCs and papers about how to achieve this effect in IP networks? Yours, Junxiao On Sat, Mar 28, 2015 at 12:01 PM, Burke, Jeff > wrote: Hi folks, We are trying to get NdnCon into use for practical conferencing soon. It is clear that audio quality ? in particular, minimizing dropouts ? is critical. Prioritizing audio over video performance when there are bandwidth / latency issues is something that can to some extent be done in the application. But I am wondering if there are any tools that the architecture can provide as well. In particular, can the notion of one-hop priority could be discussed further? Originally, when we had discussed implementations of scalable video coding over NDN with Van, he had suggested that one-hop priority might be useful. This is not end-to-end QoS but rather just a hint/request to the upstream hop on which interests the app would like fulfilled first. It could be propagated or not. In SVC streaming, such a capability would enable the consuming application to issue interests for the base layer with higher priority than those for the enhancement layer(s) without having to add complex machinery in the consumer to try to do this at the application level. (The pipelining/buffering machinery for low-latency communication is already somewhat tricky.) Looking at ndnrtc now, this capability could actually be very useful for prioritizing interests audio over video as well. What do people think? Is this something that could be considered / experimented with? Any other ideas? Thanks, Jeff ps. See my message to the ndn list ? it would be great if NFD developers could try out NdnCon! _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.UCLA.EDU Sun Mar 29 09:09:09 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Sun, 29 Mar 2015 16:09:09 +0000 Subject: [Nfd-dev] Spurious traffic to CSU/BYU hubs? In-Reply-To: <9CECDB5D-EDA5-497D-A1AC-4D300F903C6A@wustl.edu> Message-ID: Hi, On ndnmap I am consistently seeing spurious traffic to the CSU hub. Can someone explain why? Steps to reproduce: - Start ndncon publisher with route via REMAP node (ndnradio example emailed about earlier). - Start ndncon consumer with route via CAIDA or UA (haven't tried others though using CSU as the consumer hub works) Results on ndnmap: - See ~500-1000 kb/sec traffic bidirectional from consumer to publisher. (e.g., CAIDA-UCLA-REMAP or REMAP-UA) - But, also see 100-250 kb/sec traffic from REMAP-CSU, REMAP-BYU-CSU. (note that traffic is asymmetric) Screenshot attached for consumer via CAIDA hub case. Thanks, Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2015-03-29 09.07.12.png Type: image/png Size: 294360 bytes Desc: Screenshot 2015-03-29 09.07.12.png URL: From jburke at remap.UCLA.EDU Sun Mar 29 09:21:31 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Sun, 29 Mar 2015 16:21:31 +0000 Subject: [Nfd-dev] Why don't additional routes impact performance? Message-ID: Hi, I am running some tests with ndncon and am curious about the following: Steps to reproduce: - Start ndncon publisher with route through REMAP node. - On consumer node, - Restart nfd - Use nfdc to register udp route for / through university of basel - Start consumer and observe performance (audio dropouts due to jitter buffer issues) - While ndncon is running, use nfdc to register udp route for / through REMAP, CAIDA, or another closer hub - No change in performance at the consumer and no change in traffic flow on ndnmap... why? - Quit ndncon and restart - Still no change This behavior is not intuitive. I would expect that by default NFD would be issuing interests to both faces, and/or that it would be probing performance new faces become available for a given route. Does a different strategy need to be used to get this behavior? On the consumer, I am running the latest version of NFD cloned from github this morning, with a default configuration (I think). Thanks! Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sun Mar 29 09:42:35 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 29 Mar 2015 09:42:35 -0700 Subject: [Nfd-dev] Why don't additional routes impact performance? In-Reply-To: References: Message-ID: Hi Jeff With default configuration, you are using best-route v3 strategy. Therefore, *this behavior is by design*. Please try: register BASEL route with *higher cost* than REMAP or CAIDA route. When a route with lower cost is inserted, traffic shall be switched immediately to the new route. Yours, Junxiao On Sun, Mar 29, 2015 at 9:21 AM, Burke, Jeff wrote: > > Hi, > > I am running some tests with ndncon and am curious about the following: > > Steps to reproduce: > > - Start ndncon publisher with route through REMAP node. > - On consumer node, > - Restart nfd > - Use nfdc to register udp route for / through university of basel > - Start consumer and observe performance (audio dropouts due to jitter > buffer issues) > - While ndncon is running, use nfdc to register udp route for / through > REMAP, CAIDA, or another closer hub > - No change in performance at the consumer and no change in traffic flow > on ndnmap... why? > - Quit ndncon and restart > - Still no change > > This behavior is not intuitive. I would expect that by default NFD > would be issuing interests to both faces, and/or that it would be probing > performance new faces become available for a given route. Does a > different strategy need to be used to get this behavior? > > On the consumer, I am running the latest version of NFD cloned from > github this morning, with a default configuration (I think). > > > Thanks! > Jeff > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.UCLA.EDU Sun Mar 29 10:03:27 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Sun, 29 Mar 2015 17:03:27 +0000 Subject: [Nfd-dev] Why don't additional routes impact performance? In-Reply-To: Message-ID: Hi Junxiao, Ok, that makes sense. This was sort of an extreme case, though. What about for two hosts likely to have "equal" cost (e.g., UCLA and UA, for REMAP) that have different performance in practice for a given subnamespace that is not known a priori? Jeff From: Junxiao Shi > Date: Sun, 29 Mar 2015 09:42:35 -0700 To: Jeff Burke > Cc: "nfd-dev at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] Why don't additional routes impact performance? Hi Jeff With default configuration, you are using best-route v3 strategy. Therefore, this behavior is by design. Please try: register BASEL route with higher cost than REMAP or CAIDA route. When a route with lower cost is inserted, traffic shall be switched immediately to the new route. Yours, Junxiao On Sun, Mar 29, 2015 at 9:21 AM, Burke, Jeff > wrote: Hi, I am running some tests with ndncon and am curious about the following: Steps to reproduce: - Start ndncon publisher with route through REMAP node. - On consumer node, - Restart nfd - Use nfdc to register udp route for / through university of basel - Start consumer and observe performance (audio dropouts due to jitter buffer issues) - While ndncon is running, use nfdc to register udp route for / through REMAP, CAIDA, or another closer hub - No change in performance at the consumer and no change in traffic flow on ndnmap... why? - Quit ndncon and restart - Still no change This behavior is not intuitive. I would expect that by default NFD would be issuing interests to both faces, and/or that it would be probing performance new faces become available for a given route. Does a different strategy need to be used to get this behavior? On the consumer, I am running the latest version of NFD cloned from github this morning, with a default configuration (I think). Thanks! Jeff _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.EDU Sun Mar 29 13:22:05 2015 From: lanwang at memphis.EDU (Lan Wang (lanwang)) Date: Sun, 29 Mar 2015 20:22:05 +0000 Subject: [Nfd-dev] Why don't additional routes impact performance? In-Reply-To: References: Message-ID: Jeff, The behavior you want can be achieved by the ncc strategy, but we have identified other undesirable problems with this strategy (an interaction of the sequential probing this strategy does and the duplicate suppression implemented in NFD). See this nfd issue: http://redmine.named-data.net/issues/2592 Unfortunately there're no alliterative other than ncc and best-route in NFD right now. Vince Lehman in my lab is working on implementing the GreenYedRed strategy (proposed in http://named-data.net/publications/comcom-stateful-forwarding/ and refined in http://named-data.net/publications/role_of_routing_ndn/), but it is not ready yet. Lan On Mar 29, 2015, at 12:03 PM, "Burke, Jeff" > wrote: Hi Junxiao, Ok, that makes sense. This was sort of an extreme case, though. What about for two hosts likely to have "equal" cost (e.g., UCLA and UA, for REMAP) that have different performance in practice for a given subnamespace that is not known a priori? Jeff From: Junxiao Shi > Date: Sun, 29 Mar 2015 09:42:35 -0700 To: Jeff Burke > Cc: "nfd-dev at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] Why don't additional routes impact performance? Hi Jeff With default configuration, you are using best-route v3 strategy. Therefore, this behavior is by design. Please try: register BASEL route with higher cost than REMAP or CAIDA route. When a route with lower cost is inserted, traffic shall be switched immediately to the new route. Yours, Junxiao On Sun, Mar 29, 2015 at 9:21 AM, Burke, Jeff > wrote: Hi, I am running some tests with ndncon and am curious about the following: Steps to reproduce: - Start ndncon publisher with route through REMAP node. - On consumer node, - Restart nfd - Use nfdc to register udp route for / through university of basel - Start consumer and observe performance (audio dropouts due to jitter buffer issues) - While ndncon is running, use nfdc to register udp route for / through REMAP, CAIDA, or another closer hub - No change in performance at the consumer and no change in traffic flow on ndnmap... why? - Quit ndncon and restart - Still no change This behavior is not intuitive. I would expect that by default NFD would be issuing interests to both faces, and/or that it would be probing performance new faces become available for a given route. Does a different strategy need to be used to get this behavior? On the consumer, I am running the latest version of NFD cloned from github this morning, with a default configuration (I think). Thanks! Jeff _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdd at wustl.edu Sun Mar 29 13:37:04 2015 From: jdd at wustl.edu (Dehart, John) Date: Sun, 29 Mar 2015 20:37:04 +0000 Subject: [Nfd-dev] [Operators] Spurious traffic to CSU/BYU hubs? In-Reply-To: References: Message-ID: <455596C9-1869-4CDF-8497-07E2CD0FCBB0@wustl.edu> Jeff, Looks like you have this up right now. I?ll take a look. Can you leave running for a while whatever you have running right now? John > On Mar 29, 2015, at 11:09 AM, Burke, Jeff wrote: > > > Hi, > > On ndnmap I am consistently seeing spurious traffic to the CSU hub. Can > someone explain why? > > Steps to reproduce: > > - Start ndncon publisher with route via REMAP node (ndnradio example > emailed about earlier). > - Start ndncon consumer with route via CAIDA or UA (haven't tried others > though using CSU as the consumer hub works) > > Results on ndnmap: > > - See ~500-1000 kb/sec traffic bidirectional from consumer to publisher. > (e.g., CAIDA-UCLA-REMAP or REMAP-UA) > - But, also see 100-250 kb/sec traffic from REMAP-CSU, REMAP-BYU-CSU. > (note that traffic is asymmetric) > > Screenshot attached for consumer via CAIDA hub case. > > Thanks, > Jeff > > _______________________________________________ > Operators mailing list > Operators at lists.named-data.net > http://lists.named-data.net/mailman/listinfo/operators From jdd at wustl.edu Sun Mar 29 13:52:24 2015 From: jdd at wustl.edu (Dehart, John) Date: Sun, 29 Mar 2015 20:52:24 +0000 Subject: [Nfd-dev] Techniques for prioritizing audio in NdnCon In-Reply-To: References: Message-ID: Jeff, And Luca is the operator for the Orange node of the NDN Testbed. John On Mar 29, 2015, at 12:06 AM, Burke, Jeff > wrote: Hi Junxiao, I will do some digging, but this is interesting: Bonald, Thomas, Luca Muscariello, and Norberto Ostallo. "Self-prioritization of audio and video traffic." Communications (ICC), 2011 IEEE International Conference on. IEEE, 2011. http://perso.telecom-paristech.fr/~bonald/Publications_files/BMO2011.pdf (Instead of identifying packets as part of a "flow", one would use namespace or priority flag hints.) There are follow up papers to this one, too. Interesting to note that Muscariello (and a later co-author, Carofiglio) are now doing ICN research. (There are RTCP receiver reports in RTP streaming, too. ) Jeff From: Junxiao Shi > Date: Sat, 28 Mar 2015 21:09:28 -0700 To: Jeff Burke > Cc: "nfd-dev at lists.cs.ucla.edu" > Subject: Re: [Nfd-dev] Techniques for prioritizing audio in NdnCon Hi Jeff Priority delivery is an interesting idea. Can you recommend some RFCs and papers about how to achieve this effect in IP networks? Yours, Junxiao On Sat, Mar 28, 2015 at 12:01 PM, Burke, Jeff > wrote: Hi folks, We are trying to get NdnCon into use for practical conferencing soon. It is clear that audio quality ? in particular, minimizing dropouts ? is critical. Prioritizing audio over video performance when there are bandwidth / latency issues is something that can to some extent be done in the application. But I am wondering if there are any tools that the architecture can provide as well. In particular, can the notion of one-hop priority could be discussed further? Originally, when we had discussed implementations of scalable video coding over NDN with Van, he had suggested that one-hop priority might be useful. This is not end-to-end QoS but rather just a hint/request to the upstream hop on which interests the app would like fulfilled first. It could be propagated or not. In SVC streaming, such a capability would enable the consuming application to issue interests for the base layer with higher priority than those for the enhancement layer(s) without having to add complex machinery in the consumer to try to do this at the application level. (The pipelining/buffering machinery for low-latency communication is already somewhat tricky.) Looking at ndnrtc now, this capability could actually be very useful for prioritizing interests audio over video as well. What do people think? Is this something that could be considered / experimented with? Any other ideas? Thanks, Jeff ps. See my message to the ndn list ? it would be great if NFD developers could try out NdnCon! _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Sun Mar 29 13:56:49 2015 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Sun, 29 Mar 2015 20:56:49 +0000 Subject: [Nfd-dev] [Operators] Spurious traffic to CSU/BYU hubs? In-Reply-To: References: Message-ID: <19126048-F026-4728-8FD9-F56EAA89F6EC@memphis.edu> Jeff, Can you give a little more information? - name prefix used by the ndncon producer? - strategy used by the name prefix? - was the spurious traffic present before the test? Lan On Mar 29, 2015, at 11:09 AM, "Burke, Jeff" wrote: > > Hi, > > On ndnmap I am consistently seeing spurious traffic to the CSU hub. Can > someone explain why? > > Steps to reproduce: > > - Start ndncon publisher with route via REMAP node (ndnradio example > emailed about earlier). > - Start ndncon consumer with route via CAIDA or UA (haven't tried others > though using CSU as the consumer hub works) > > Results on ndnmap: > > - See ~500-1000 kb/sec traffic bidirectional from consumer to publisher. > (e.g., CAIDA-UCLA-REMAP or REMAP-UA) > - But, also see 100-250 kb/sec traffic from REMAP-CSU, REMAP-BYU-CSU. > (note that traffic is asymmetric) > > Screenshot attached for consumer via CAIDA hub case. > > Thanks, > Jeff > > _______________________________________________ > Operators mailing list > Operators at lists.named-data.net > http://lists.named-data.net/mailman/listinfo/operators From jdd at wustl.edu Sun Mar 29 13:59:27 2015 From: jdd at wustl.edu (Dehart, John) Date: Sun, 29 Mar 2015 20:59:27 +0000 Subject: [Nfd-dev] [Operators] Spurious traffic to CSU/BYU hubs? In-Reply-To: <19126048-F026-4728-8FD9-F56EAA89F6EC@memphis.edu> References: <19126048-F026-4728-8FD9-F56EAA89F6EC@memphis.edu> Message-ID: <4666CB5B-83C7-4C02-9ACC-AB07CD12B618@wustl.edu> All: I think this was due to a misconfiguration of nfd-autoreg. When the BYU node was added it did not get added to the nfd-autoreg Blacklist for REMAP. So, REMAP was sending ndnrtc Interests to BYU as if BYU was a local host. I?ve corrected the config, restarted nfd and Jeff will retry his setup. John On Mar 29, 2015, at 3:56 PM, Lan Wang (lanwang) > wrote: Jeff, Can you give a little more information? - name prefix used by the ndncon producer? - strategy used by the name prefix? - was the spurious traffic present before the test? Lan On Mar 29, 2015, at 11:09 AM, "Burke, Jeff" > wrote: Hi, On ndnmap I am consistently seeing spurious traffic to the CSU hub. Can someone explain why? Steps to reproduce: - Start ndncon publisher with route via REMAP node (ndnradio example emailed about earlier). - Start ndncon consumer with route via CAIDA or UA (haven't tried others though using CSU as the consumer hub works) Results on ndnmap: - See ~500-1000 kb/sec traffic bidirectional from consumer to publisher. (e.g., CAIDA-UCLA-REMAP or REMAP-UA) - But, also see 100-250 kb/sec traffic from REMAP-CSU, REMAP-BYU-CSU. (note that traffic is asymmetric) Screenshot attached for consumer via CAIDA hub case. Thanks, Jeff _______________________________________________ Operators mailing list Operators at lists.named-data.net http://lists.named-data.net/mailman/listinfo/operators _______________________________________________ Operators mailing list Operators at lists.named-data.net http://lists.named-data.net/mailman/listinfo/operators -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.UCLA.EDU Sun Mar 29 14:03:04 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Sun, 29 Mar 2015 21:03:04 +0000 Subject: [Nfd-dev] [Operators] Spurious traffic to CSU/BYU hubs? In-Reply-To: <4666CB5B-83C7-4C02-9ACC-AB07CD12B618@wustl.edu> Message-ID: Hi, Re-registered the route to REMAP on the publisher. (Yet another use case for "permanent" routes!) Looks good on the map. Thanks! Jeff From: "Dehart, John" > Date: Sun, 29 Mar 2015 20:59:27 +0000 To: "Lan Wang (lanwang)" > Cc: Jeff Burke >, "nfd-dev at lists.cs.ucla.edu" >, ">" > Subject: Re: [Operators] Spurious traffic to CSU/BYU hubs? All: I think this was due to a misconfiguration of nfd-autoreg. When the BYU node was added it did not get added to the nfd-autoreg Blacklist for REMAP. So, REMAP was sending ndnrtc Interests to BYU as if BYU was a local host. I?ve corrected the config, restarted nfd and Jeff will retry his setup. John On Mar 29, 2015, at 3:56 PM, Lan Wang (lanwang) > wrote: Jeff, Can you give a little more information? - name prefix used by the ndncon producer? - strategy used by the name prefix? - was the spurious traffic present before the test? Lan On Mar 29, 2015, at 11:09 AM, "Burke, Jeff" > wrote: Hi, On ndnmap I am consistently seeing spurious traffic to the CSU hub. Can someone explain why? Steps to reproduce: - Start ndncon publisher with route via REMAP node (ndnradio example emailed about earlier). - Start ndncon consumer with route via CAIDA or UA (haven't tried others though using CSU as the consumer hub works) Results on ndnmap: - See ~500-1000 kb/sec traffic bidirectional from consumer to publisher. (e.g., CAIDA-UCLA-REMAP or REMAP-UA) - But, also see 100-250 kb/sec traffic from REMAP-CSU, REMAP-BYU-CSU. (note that traffic is asymmetric) Screenshot attached for consumer via CAIDA hub case. Thanks, Jeff _______________________________________________ Operators mailing list Operators at lists.named-data.net http://lists.named-data.net/mailman/listinfo/operators _______________________________________________ Operators mailing list Operators at lists.named-data.net http://lists.named-data.net/mailman/listinfo/operators -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdd at wustl.edu Sun Mar 29 14:21:18 2015 From: jdd at wustl.edu (Dehart, John) Date: Sun, 29 Mar 2015 21:21:18 +0000 Subject: [Nfd-dev] [Operators] Spurious traffic to CSU/BYU hubs? In-Reply-To: References: Message-ID: <5BA9C643-3929-41B0-934F-2763C8C93DE1@wustl.edu> Jeff, Great. I?ll make a pass through the rest of the Testbed and verify that I didn?t miss others. Of course, let me know if you see anything else like this. John On Mar 29, 2015, at 4:03 PM, Burke, Jeff > wrote: Hi, Re-registered the route to REMAP on the publisher. (Yet another use case for "permanent" routes!) Looks good on the map. Thanks! Jeff From: "Dehart, John" > Date: Sun, 29 Mar 2015 20:59:27 +0000 To: "Lan Wang (lanwang)" > Cc: Jeff Burke >, "nfd-dev at lists.cs.ucla.edu" >, ">" > Subject: Re: [Operators] Spurious traffic to CSU/BYU hubs? All: I think this was due to a misconfiguration of nfd-autoreg. When the BYU node was added it did not get added to the nfd-autoreg Blacklist for REMAP. So, REMAP was sending ndnrtc Interests to BYU as if BYU was a local host. I?ve corrected the config, restarted nfd and Jeff will retry his setup. John On Mar 29, 2015, at 3:56 PM, Lan Wang (lanwang) > wrote: Jeff, Can you give a little more information? - name prefix used by the ndncon producer? - strategy used by the name prefix? - was the spurious traffic present before the test? Lan On Mar 29, 2015, at 11:09 AM, "Burke, Jeff" > wrote: Hi, On ndnmap I am consistently seeing spurious traffic to the CSU hub. Can someone explain why? Steps to reproduce: - Start ndncon publisher with route via REMAP node (ndnradio example emailed about earlier). - Start ndncon consumer with route via CAIDA or UA (haven't tried others though using CSU as the consumer hub works) Results on ndnmap: - See ~500-1000 kb/sec traffic bidirectional from consumer to publisher. (e.g., CAIDA-UCLA-REMAP or REMAP-UA) - But, also see 100-250 kb/sec traffic from REMAP-CSU, REMAP-BYU-CSU. (note that traffic is asymmetric) Screenshot attached for consumer via CAIDA hub case. Thanks, Jeff _______________________________________________ Operators mailing list Operators at lists.named-data.net http://lists.named-data.net/mailman/listinfo/operators _______________________________________________ Operators mailing list Operators at lists.named-data.net http://lists.named-data.net/mailman/listinfo/operators -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Mar 30 07:29:37 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 30 Mar 2015 07:29:37 -0700 Subject: [Nfd-dev] Jenkins master migration Message-ID: Dear folks jenkins.named-data.net has been migrated to a new master server on Mar 29 evening. The new master server sits on the same physical machine, but it is allocated with more memory and disk space, and is created with Vagrant. Thanks Eric for the hard work. This migration should have no impact on build jobs. If you notice issues, please contact Eric (CC'ed) for help. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.UCLA.EDU Mon Mar 30 10:28:17 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Mon, 30 Mar 2015 17:28:17 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD Message-ID: Hi folks, We are facing this scenario in a few applications: 1) Interest received by NFD, passed to an application 2) Application not able to respond to interest, so interest stays in NFD PIT 3) Some time passes, but not enough for the Interest to expire 4) Application generates data (e.g., from a sensor reading) that would answer the Interest in the NFD PIT Question: How does app know to inform NFD it has the data after step 4, and how should it do that? - In this type of app, should it push the data unsolicited to the NFD and let it decide if there is something to do? - Is it recommended to implement an application-level PIT so the app is sure this data is solicited? (Why add another PIT?) Thank you, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From anilj.mailing at gmail.com Mon Mar 30 10:43:45 2015 From: anilj.mailing at gmail.com (Anil Jangam) Date: Mon, 30 Mar 2015 10:43:45 -0700 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: References: Message-ID: Hi Jeff, Point #1 suggest that application is ndn aware since you're forwarding Interest. But IMO it isn't always required. Also I am not sure where application is running. I think it will be appropriate to let NFD pull the data from application (or poll it) and decide how and when it can satisfy the Interest. This specially important, in the context of sensor node, due to computing resources constraints. If NFD is not supposed to have such custmizations, we can have an agent between NFD and all sensor nodes. This agent potentially be ndn capable and also have application specific customizations. /anil. On Mar 30, 2015 10:28 AM, "Burke, Jeff" wrote: > > Hi folks, > > We are facing this scenario in a few applications: > > 1) Interest received by NFD, passed to an application > 2) Application not able to respond to interest, so interest stays in NFD > PIT > 3) Some time passes, but not enough for the Interest to expire > 4) Application generates data (e.g., from a sensor reading) that would > answer the Interest in the NFD PIT > > Question: How does app know to inform NFD it has the data after step 4, > and how should it do that? > > - In this type of app, should it push the data unsolicited to the NFD > and let it decide if there is something to do? > - Is it recommended to implement an application-level PIT so the app is > sure this data is solicited? (Why add *another* PIT?) > > Thank you, > Jeff > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.UCLA.EDU Mon Mar 30 10:55:31 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Mon, 30 Mar 2015 17:55:31 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: Message-ID: Hi, To clarify, this is for an NDN application which receives an interest for data that's not yet ready. Jeff From: Anil Jangam > Date: Mon, 30 Mar 2015 10:43:45 -0700 To: Jeff Burke > Cc: > Subject: Re: [Nfd-dev] Handling new content in app for pending interest in NFD Hi Jeff, Point #1 suggest that application is ndn aware since you're forwarding Interest. But IMO it isn't always required. Also I am not sure where application is running. I think it will be appropriate to let NFD pull the data from application (or poll it) and decide how and when it can satisfy the Interest. This specially important, in the context of sensor node, due to computing resources constraints. If NFD is not supposed to have such custmizations, we can have an agent between NFD and all sensor nodes. This agent potentially be ndn capable and also have application specific customizations. /anil. On Mar 30, 2015 10:28 AM, "Burke, Jeff" > wrote: Hi folks, We are facing this scenario in a few applications: 1) Interest received by NFD, passed to an application 2) Application not able to respond to interest, so interest stays in NFD PIT 3) Some time passes, but not enough for the Interest to expire 4) Application generates data (e.g., from a sensor reading) that would answer the Interest in the NFD PIT Question: How does app know to inform NFD it has the data after step 4, and how should it do that? - In this type of app, should it push the data unsolicited to the NFD and let it decide if there is something to do? - Is it recommended to implement an application-level PIT so the app is sure this data is solicited? (Why add another PIT?) Thank you, Jeff _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Mon Mar 30 11:03:19 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Mon, 30 Mar 2015 18:03:19 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: References: Message-ID: On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff wrote: > > Hi folks, > > We are facing this scenario in a few applications: > > 1) Interest received by NFD, passed to an application > 2) Application not able to respond to interest, so interest stays in NFD > PIT > 3) Some time passes, but not enough for the Interest to expire > 4) Application generates data (e.g., from a sensor reading) that would > answer the Interest in the NFD PIT > > Question: How does app know to inform NFD it has the data after step 4, > and how should it do that? > > - In this type of app, should it push the data unsolicited to the NFD > and let it decide if there is something to do? > In my opinion, as long as the application is certain that the Interest has arrived and is stored in NFD's PIT, it can just push the data out to NFD. Wentao > - Is it recommended to implement an application-level PIT so the app is > sure this data is solicited? (Why add *another* PIT?) > > Thank you, > Jeff > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.UCLA.EDU Mon Mar 30 11:05:12 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Mon, 30 Mar 2015 18:05:12 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: Message-ID: On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff > wrote: Hi folks, We are facing this scenario in a few applications: 1) Interest received by NFD, passed to an application 2) Application not able to respond to interest, so interest stays in NFD PIT 3) Some time passes, but not enough for the Interest to expire 4) Application generates data (e.g., from a sensor reading) that would answer the Interest in the NFD PIT Question: How does app know to inform NFD it has the data after step 4, and how should it do that? - In this type of app, should it push the data unsolicited to the NFD and let it decide if there is something to do? In my opinion, as long as the application is certain that the Interest has arrived and is stored in NFD's PIT, it can just push the data out to NFD. How certain does it have to be? There is a chance it could have expired... jeff Wentao - Is it recommended to implement an application-level PIT so the app is sure this data is solicited? (Why add another PIT?) Thank you, Jeff _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdd at wustl.edu Mon Mar 30 11:08:06 2015 From: jdd at wustl.edu (Dehart, John) Date: Mon, 30 Mar 2015 18:08:06 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: References: Message-ID: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> Is there any harm in it pushing the data out without knowing for sure if the Interest is still active? John On Mar 30, 2015, at 1:05 PM, Burke, Jeff > wrote: On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff > wrote: Hi folks, We are facing this scenario in a few applications: 1) Interest received by NFD, passed to an application 2) Application not able to respond to interest, so interest stays in NFD PIT 3) Some time passes, but not enough for the Interest to expire 4) Application generates data (e.g., from a sensor reading) that would answer the Interest in the NFD PIT Question: How does app know to inform NFD it has the data after step 4, and how should it do that? - In this type of app, should it push the data unsolicited to the NFD and let it decide if there is something to do? In my opinion, as long as the application is certain that the Interest has arrived and is stored in NFD's PIT, it can just push the data out to NFD. How certain does it have to be? There is a chance it could have expired... jeff Wentao - Is it recommended to implement an application-level PIT so the app is sure this data is solicited? (Why add another PIT?) Thank you, Jeff _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Mon Mar 30 11:11:24 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Mon, 30 Mar 2015 18:11:24 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> References: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> Message-ID: On Mon, Mar 30, 2015 at 11:08 AM Dehart, John wrote: > > Is there any harm in it pushing the data out without knowing for sure if > the > Interest is still active? > Actually I don't think there is any problem with that either... Wentao > > John > > On Mar 30, 2015, at 1:05 PM, Burke, Jeff wrote: > > > > > > On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff > wrote: > >> >> Hi folks, >> >> We are facing this scenario in a few applications: >> >> 1) Interest received by NFD, passed to an application >> 2) Application not able to respond to interest, so interest stays in NFD >> PIT >> 3) Some time passes, but not enough for the Interest to expire >> 4) Application generates data (e.g., from a sensor reading) that would >> answer the Interest in the NFD PIT >> >> Question: How does app know to inform NFD it has the data after step 4, >> and how should it do that? >> >> - In this type of app, should it push the data unsolicited to the NFD >> and let it decide if there is something to do? >> > > In my opinion, as long as the application is certain that the Interest > has arrived and is stored in NFD's PIT, it can just push the data out to > NFD. > > > > How certain does it have to be? There is a chance it could have > expired... > jeff > > > > > > > Wentao > > >> - Is it recommended to implement an application-level PIT so the app is >> sure this data is solicited? (Why add *another* PIT?) >> >> Thank you, >> Jeff >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anilj.mailing at gmail.com Mon Mar 30 11:12:04 2015 From: anilj.mailing at gmail.com (Anil Jangam) Date: Mon, 30 Mar 2015 11:12:04 -0700 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> References: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> Message-ID: On Mar 30, 2015 11:08 AM, "Dehart, John" wrote: > > > Is there any harm in it pushing the data out without knowing for sure if the > Interest is still active? > If data is so critical, can the Interest be refreshed proactively before it expires? /anil > John > >> On Mar 30, 2015, at 1:05 PM, Burke, Jeff wrote: >> >> >> >>> >>> >>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff wrote: >>>> >>>> >>>> Hi folks, >>>> >>>> We are facing this scenario in a few applications: >>>> >>>> 1) Interest received by NFD, passed to an application >>>> 2) Application not able to respond to interest, so interest stays in NFD PIT >>>> 3) Some time passes, but not enough for the Interest to expire >>>> 4) Application generates data (e.g., from a sensor reading) that would answer the Interest in the NFD PIT >>>> >>>> Question: How does app know to inform NFD it has the data after step 4, and how should it do that? >>>> >>>> - In this type of app, should it push the data unsolicited to the NFD and let it decide if there is something to do? >>> >>> >>> In my opinion, as long as the application is certain that the Interest has arrived and is stored in NFD's PIT, it can just push the data out to NFD. >> >> >> >> How certain does it have to be? There is a chance it could have expired... >> jeff >> >> >> >> >> >>> >>> Wentao >>> >>>> >>>> - Is it recommended to implement an application-level PIT so the app is sure this data is solicited? (Why add another PIT?) >>>> >>>> Thank you, >>>> Jeff >>>> >>>> _______________________________________________ >>>> Nfd-dev mailing list >>>> Nfd-dev at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hyuan at wustl.edu Mon Mar 30 11:24:44 2015 From: hyuan at wustl.edu (Haowei Yuan) Date: Mon, 30 Mar 2015 13:24:44 -0500 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: References: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> Message-ID: I think as long as the data has actually been requested by an Interest packet, it is safe to send the Data packet to NFD. The NFD will either forward or drop the Data packet by checking if the Interest has expired. If the Interest has expired, Data packet is dropped, and the consumer is still interested in the data, the consumer could resend the Interest. Hopefully this time, the Data packet can be generated and sent faster by the application so that NFD will forward it. Haowei On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam wrote: > > On Mar 30, 2015 11:08 AM, "Dehart, John" wrote: >> >> >> Is there any harm in it pushing the data out without knowing for sure if >> the >> Interest is still active? >> > If data is so critical, can the Interest be refreshed proactively before it > expires? > > /anil > >> John >> >>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff wrote: >>> >>> >>> >>>> >>>> >>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff >>>> wrote: >>>>> >>>>> >>>>> Hi folks, >>>>> >>>>> We are facing this scenario in a few applications: >>>>> >>>>> 1) Interest received by NFD, passed to an application >>>>> 2) Application not able to respond to interest, so interest stays in >>>>> NFD PIT >>>>> 3) Some time passes, but not enough for the Interest to expire >>>>> 4) Application generates data (e.g., from a sensor reading) that would >>>>> answer the Interest in the NFD PIT >>>>> >>>>> Question: How does app know to inform NFD it has the data after step 4, >>>>> and how should it do that? >>>>> >>>>> - In this type of app, should it push the data unsolicited to the NFD >>>>> and let it decide if there is something to do? >>>> >>>> >>>> In my opinion, as long as the application is certain that the Interest >>>> has arrived and is stored in NFD's PIT, it can just push the data out to >>>> NFD. >>> >>> >>> >>> How certain does it have to be? There is a chance it could have >>> expired... >>> jeff >>> >>> >>> >>> >>> >>>> >>>> Wentao >>>> >>>>> >>>>> - Is it recommended to implement an application-level PIT so the app is >>>>> sure this data is solicited? (Why add another PIT?) >>>>> >>>>> Thank you, >>>>> Jeff >>>>> >>>>> _______________________________________________ >>>>> Nfd-dev mailing list >>>>> Nfd-dev at lists.cs.ucla.edu >>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> From davide.pesavento at lip6.fr Mon Mar 30 11:29:05 2015 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Mon, 30 Mar 2015 20:29:05 +0200 Subject: [Nfd-dev] Jenkins master migration In-Reply-To: References: Message-ID: Hi Eric, I'm not sure if it's related, but since today I'm getting a lot of java errors on jenkins.named-data.net web interface. Looks like a disk/filesystem issue, see below. java.io.IOException: Failed to create a temporary file in /var/lib/jenkins/users/davidepesa at gmail.com at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:68) at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:55) at hudson.XmlFile.write(XmlFile.java:175) at hudson.model.User.save(User.java:688) at hudson.model.User.addProperty(User.java:264) at org.jenkinsci.plugins.googlelogin.GoogleUserInfo.updateProfile(GoogleUserInfo.java:86) at org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm$2.onSuccess(GoogleOAuth2SecurityRealm.java:193) at org.jenkinsci.plugins.googlelogin.OAuthSession.doFinishLogin(OAuthSession.java:99) at org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm.doFinishLogin(GoogleOAuth2SecurityRealm.java:218) at sun.reflect.GeneratedMethodAccessor923.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:211) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:123) at hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter$1.call(ScmSyncConfigurationFilter.java:46) at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationDataProvider.provideRequestDuring(ScmSyncConfigurationDataProvider.java:103) at hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter.doFilter(ScmSyncConfigurationFilter.java:42) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:114) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:168) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.io.IOException: Read-only file system at java.io.UnixFileSystem.createFileExclusively(Native Method) at java.io.File.createNewFile(File.java:1006) at java.io.File.createTempFile(File.java:1989) at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:66) ... 84 more Thanks, Davide On Mon, Mar 30, 2015 at 4:29 PM, Junxiao Shi wrote: > Dear folks > > jenkins.named-data.net has been migrated to a new master server on Mar 29 > evening. > The new master server sits on the same physical machine, but it is allocated > with more memory and disk space, and is created with Vagrant. > Thanks Eric for the hard work. > > This migration should have no impact on build jobs. > If you notice issues, please contact Eric (CC'ed) for help. > > Yours, Junxiao > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From jburke at remap.UCLA.EDU Mon Mar 30 11:33:13 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Mon, 30 Mar 2015 18:33:13 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: Message-ID: On 3/30/15, 11:24 AM, "Haowei Yuan" wrote: >I think as long as the data has actually been requested by an Interest >packet, it is safe to send the Data packet to NFD. Yes, but if the app has no PIT, how would it know the data is requested by a (recent) Interest, if it does not immediately answer it? Jeff >The NFD will either >forward or drop the Data packet by checking if the Interest has >expired. > >If the Interest has expired, Data packet is dropped, and the consumer >is still interested in the data, the consumer could resend the >Interest. Hopefully this time, the Data packet can be generated and >sent faster by the application so that NFD will forward it. > >Haowei > > >On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam >wrote: >> >> On Mar 30, 2015 11:08 AM, "Dehart, John" wrote: >>> >>> >>> Is there any harm in it pushing the data out without knowing for sure >>>if >>> the >>> Interest is still active? >>> >> If data is so critical, can the Interest be refreshed proactively >>before it >> expires? >> >> /anil >> >>> John >>> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff >>>>wrote: >>>> >>>> >>>> >>>>> >>>>> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi folks, >>>>>> >>>>>> We are facing this scenario in a few applications: >>>>>> >>>>>> 1) Interest received by NFD, passed to an application >>>>>> 2) Application not able to respond to interest, so interest stays in >>>>>> NFD PIT >>>>>> 3) Some time passes, but not enough for the Interest to expire >>>>>> 4) Application generates data (e.g., from a sensor reading) that >>>>>>would >>>>>> answer the Interest in the NFD PIT >>>>>> >>>>>> Question: How does app know to inform NFD it has the data after >>>>>>step 4, >>>>>> and how should it do that? >>>>>> >>>>>> - In this type of app, should it push the data unsolicited to the >>>>>>NFD >>>>>> and let it decide if there is something to do? >>>>> >>>>> >>>>> In my opinion, as long as the application is certain that the >>>>>Interest >>>>> has arrived and is stored in NFD's PIT, it can just push the data >>>>>out to >>>>> NFD. >>>> >>>> >>>> >>>> How certain does it have to be? There is a chance it could have >>>> expired... >>>> jeff >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Wentao >>>>> >>>>>> >>>>>> - Is it recommended to implement an application-level PIT so the >>>>>>app is >>>>>> sure this data is solicited? (Why add another PIT?) >>>>>> >>>>>> Thank you, >>>>>> Jeff >>>>>> >>>>>> _______________________________________________ >>>>>> Nfd-dev mailing list >>>>>> Nfd-dev at lists.cs.ucla.edu >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>>> _______________________________________________ >>>> Nfd-dev mailing list >>>> Nfd-dev at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >_______________________________________________ >Nfd-dev mailing list >Nfd-dev at lists.cs.ucla.edu >http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From oran at cisco.com Mon Mar 30 11:52:18 2015 From: oran at cisco.com (Dave Oran (oran)) Date: Mon, 30 Mar 2015 18:52:18 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: References: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> Message-ID: <5B579956-A6A1-4992-A259-E989C29E20C7@cisco.com> Isn?t this what the repo was invented for? Holding packets in a router that has forgotten that they were asked for is a giant invitation to cache pollution/poisoning attacks. > On Mar 30, 2015, at 2:24 PM, Haowei Yuan wrote: > > I think as long as the data has actually been requested by an Interest > packet, it is safe to send the Data packet to NFD. The NFD will either > forward or drop the Data packet by checking if the Interest has > expired. > > If the Interest has expired, Data packet is dropped, and the consumer > is still interested in the data, the consumer could resend the > Interest. Hopefully this time, the Data packet can be generated and > sent faster by the application so that NFD will forward it. > > Haowei > > > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam wrote: >> >> On Mar 30, 2015 11:08 AM, "Dehart, John" wrote: >>> >>> >>> Is there any harm in it pushing the data out without knowing for sure if >>> the >>> Interest is still active? >>> >> If data is so critical, can the Interest be refreshed proactively before it >> expires? >> >> /anil >> >>> John >>> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff wrote: >>>> >>>> >>>> >>>>> >>>>> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi folks, >>>>>> >>>>>> We are facing this scenario in a few applications: >>>>>> >>>>>> 1) Interest received by NFD, passed to an application >>>>>> 2) Application not able to respond to interest, so interest stays in >>>>>> NFD PIT >>>>>> 3) Some time passes, but not enough for the Interest to expire >>>>>> 4) Application generates data (e.g., from a sensor reading) that would >>>>>> answer the Interest in the NFD PIT >>>>>> >>>>>> Question: How does app know to inform NFD it has the data after step 4, >>>>>> and how should it do that? >>>>>> >>>>>> - In this type of app, should it push the data unsolicited to the NFD >>>>>> and let it decide if there is something to do? >>>>> >>>>> >>>>> In my opinion, as long as the application is certain that the Interest >>>>> has arrived and is stored in NFD's PIT, it can just push the data out to >>>>> NFD. >>>> >>>> >>>> >>>> How certain does it have to be? There is a chance it could have >>>> expired... >>>> jeff >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Wentao >>>>> >>>>>> >>>>>> - Is it recommended to implement an application-level PIT so the app is >>>>>> sure this data is solicited? (Why add another PIT?) >>>>>> >>>>>> Thank you, >>>>>> Jeff >>>>>> >>>>>> _______________________________________________ >>>>>> Nfd-dev mailing list >>>>>> Nfd-dev at lists.cs.ucla.edu >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>>> _______________________________________________ >>>> Nfd-dev mailing list >>>> Nfd-dev at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From wangzhehao410305 at gmail.com Mon Mar 30 12:07:06 2015 From: wangzhehao410305 at gmail.com (Zhehao Wang) Date: Mon, 30 Mar 2015 12:07:06 -0700 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: References: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> Message-ID: Hi Wentao and John, Is there any harm in it pushing the data out without knowing for sure if > the > Interest is still active? I would think of this as a tradeoff between IO and processing capability, if compared with our current approach of memoryContentCache with in-application PIT. Both might be preferable given different application scenarios. As Dave suggested, using a repo implementation; or somehow (security risks?) using the data unsolicited pipeline in nfd could be more ideal? Thanks, Zhehao On Mon, Mar 30, 2015 at 11:11 AM, Wentao Shang wrote: > > > On Mon, Mar 30, 2015 at 11:08 AM Dehart, John wrote: > >> >> Is there any harm in it pushing the data out without knowing for sure if >> the >> Interest is still active? >> > > Actually I don't think there is any problem with that either... > > Wentao > > >> >> John >> >> On Mar 30, 2015, at 1:05 PM, Burke, Jeff wrote: >> >> >> >> >> >> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff >> wrote: >> >>> >>> Hi folks, >>> >>> We are facing this scenario in a few applications: >>> >>> 1) Interest received by NFD, passed to an application >>> 2) Application not able to respond to interest, so interest stays in NFD >>> PIT >>> 3) Some time passes, but not enough for the Interest to expire >>> 4) Application generates data (e.g., from a sensor reading) that would >>> answer the Interest in the NFD PIT >>> >>> Question: How does app know to inform NFD it has the data after step >>> 4, and how should it do that? >>> >>> - In this type of app, should it push the data unsolicited to the NFD >>> and let it decide if there is something to do? >>> >> >> In my opinion, as long as the application is certain that the Interest >> has arrived and is stored in NFD's PIT, it can just push the data out to >> NFD. >> >> >> >> How certain does it have to be? There is a chance it could have >> expired... >> jeff >> >> >> >> >> >> >> Wentao >> >> >>> - Is it recommended to implement an application-level PIT so the app >>> is sure this data is solicited? (Why add *another* PIT?) >>> >>> Thank you, >>> Jeff >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> >> > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Mon Mar 30 12:08:10 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Mon, 30 Mar 2015 19:08:10 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: <5B579956-A6A1-4992-A259-E989C29E20C7@cisco.com> References: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> <5B579956-A6A1-4992-A259-E989C29E20C7@cisco.com> Message-ID: I agree with Dave. In principle, router should not cache unsolicited data. In the situation we are discussing, the application should either just push the data out, which may be dropped by NFD if the interest has expired, or store the data in some application-level cache (or repo) for future fetching. Wentao On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) wrote: > Isn?t this what the repo was invented for? > > Holding packets in a router that has forgotten that they were asked for is > a giant invitation to cache pollution/poisoning attacks. > > > On Mar 30, 2015, at 2:24 PM, Haowei Yuan wrote: > > > > I think as long as the data has actually been requested by an Interest > > packet, it is safe to send the Data packet to NFD. The NFD will either > > forward or drop the Data packet by checking if the Interest has > > expired. > > > > If the Interest has expired, Data packet is dropped, and the consumer > > is still interested in the data, the consumer could resend the > > Interest. Hopefully this time, the Data packet can be generated and > > sent faster by the application so that NFD will forward it. > > > > Haowei > > > > > > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam > wrote: > >> > >> On Mar 30, 2015 11:08 AM, "Dehart, John" wrote: > >>> > >>> > >>> Is there any harm in it pushing the data out without knowing for sure > if > >>> the > >>> Interest is still active? > >>> > >> If data is so critical, can the Interest be refreshed proactively > before it > >> expires? > >> > >> /anil > >> > >>> John > >>> > >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff > wrote: > >>>> > >>>> > >>>> > >>>>> > >>>>> > >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff > >>>>> wrote: > >>>>>> > >>>>>> > >>>>>> Hi folks, > >>>>>> > >>>>>> We are facing this scenario in a few applications: > >>>>>> > >>>>>> 1) Interest received by NFD, passed to an application > >>>>>> 2) Application not able to respond to interest, so interest stays in > >>>>>> NFD PIT > >>>>>> 3) Some time passes, but not enough for the Interest to expire > >>>>>> 4) Application generates data (e.g., from a sensor reading) that > would > >>>>>> answer the Interest in the NFD PIT > >>>>>> > >>>>>> Question: How does app know to inform NFD it has the data after > step 4, > >>>>>> and how should it do that? > >>>>>> > >>>>>> - In this type of app, should it push the data unsolicited to the > NFD > >>>>>> and let it decide if there is something to do? > >>>>> > >>>>> > >>>>> In my opinion, as long as the application is certain that the > Interest > >>>>> has arrived and is stored in NFD's PIT, it can just push the data > out to > >>>>> NFD. > >>>> > >>>> > >>>> > >>>> How certain does it have to be? There is a chance it could have > >>>> expired... > >>>> jeff > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>> Wentao > >>>>> > >>>>>> > >>>>>> - Is it recommended to implement an application-level PIT so the > app is > >>>>>> sure this data is solicited? (Why add another PIT?) > >>>>>> > >>>>>> Thank you, > >>>>>> Jeff > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Nfd-dev mailing list > >>>>>> Nfd-dev at lists.cs.ucla.edu > >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > >>>> > >>>> _______________________________________________ > >>>> Nfd-dev mailing list > >>>> Nfd-dev at lists.cs.ucla.edu > >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > >>> > >>> > >>> > >>> _______________________________________________ > >>> Nfd-dev mailing list > >>> Nfd-dev at lists.cs.ucla.edu > >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > >>> > > _______________________________________________ > > Nfd-dev mailing list > > Nfd-dev at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vslehman at memphis.edu Mon Mar 30 12:12:45 2015 From: vslehman at memphis.edu (Vince Lehman (vslehman)) Date: Mon, 30 Mar 2015 19:12:45 +0000 Subject: [Nfd-dev] Jenkins master migration In-Reply-To: References: Message-ID: Hi Eric, I also get a similar error to Davide and noticed that the NLSR build failed with this message in the logs: No such file: /var/lib/jenkins/jobs/NLSR/configurations/axis-label/FreeBSD10/builds/490/log -- Vince Lehman On Mar 30, 2015, at 1:29 PM, Davide Pesavento > wrote: Hi Eric, I'm not sure if it's related, but since today I'm getting a lot of java errors on jenkins.named-data.net web interface. Looks like a disk/filesystem issue, see below. java.io.IOException: Failed to create a temporary file in /var/lib/jenkins/users/davidepesa at gmail.com at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:68) at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:55) at hudson.XmlFile.write(XmlFile.java:175) at hudson.model.User.save(User.java:688) at hudson.model.User.addProperty(User.java:264) at org.jenkinsci.plugins.googlelogin.GoogleUserInfo.updateProfile(GoogleUserInfo.java:86) at org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm$2.onSuccess(GoogleOAuth2SecurityRealm.java:193) at org.jenkinsci.plugins.googlelogin.OAuthSession.doFinishLogin(OAuthSession.java:99) at org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm.doFinishLogin(GoogleOAuth2SecurityRealm.java:218) at sun.reflect.GeneratedMethodAccessor923.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:211) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:123) at hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter$1.call(ScmSyncConfigurationFilter.java:46) at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationDataProvider.provideRequestDuring(ScmSyncConfigurationDataProvider.java:103) at hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter.doFilter(ScmSyncConfigurationFilter.java:42) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:114) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:168) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.io.IOException: Read-only file system at java.io.UnixFileSystem.createFileExclusively(Native Method) at java.io.File.createNewFile(File.java:1006) at java.io.File.createTempFile(File.java:1989) at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:66) ... 84 more Thanks, Davide On Mon, Mar 30, 2015 at 4:29 PM, Junxiao Shi > wrote: Dear folks jenkins.named-data.net has been migrated to a new master server on Mar 29 evening. The new master server sits on the same physical machine, but it is allocated with more memory and disk space, and is created with Vagrant. Thanks Eric for the hard work. This migration should have no impact on build jobs. If you notice issues, please contact Eric (CC'ed) for help. Yours, Junxiao _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Mosko at parc.com Mon Mar 30 12:52:35 2015 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Mon, 30 Mar 2015 19:52:35 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: References: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> <5B579956-A6A1-4992-A259-E989C29E20C7@cisco.com> Message-ID: <8502CDD5-59EB-4E87-A022-F0DDC14DC1AE@parc.com> I?ll add that in addition to the content having a PIT entry, Nacho Solis has suggested that a router should verify that a Content Object came in a face from which it was requested. Otherwise, there?s a potential for off-path attacks sending content objects that match popular well-known names. A variation on that, rather than tracking forward paths, would be to at minimum verify that a content object comes from a face for which there?s a corresponding FIB entry for the name. Marc On Mar 30, 2015, at 12:08 PM, Wentao Shang > wrote: I agree with Dave. In principle, router should not cache unsolicited data. In the situation we are discussing, the application should either just push the data out, which may be dropped by NFD if the interest has expired, or store the data in some application-level cache (or repo) for future fetching. Wentao On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) > wrote: Isn?t this what the repo was invented for? Holding packets in a router that has forgotten that they were asked for is a giant invitation to cache pollution/poisoning attacks. > On Mar 30, 2015, at 2:24 PM, Haowei Yuan > wrote: > > I think as long as the data has actually been requested by an Interest > packet, it is safe to send the Data packet to NFD. The NFD will either > forward or drop the Data packet by checking if the Interest has > expired. > > If the Interest has expired, Data packet is dropped, and the consumer > is still interested in the data, the consumer could resend the > Interest. Hopefully this time, the Data packet can be generated and > sent faster by the application so that NFD will forward it. > > Haowei > > > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam > wrote: >> >> On Mar 30, 2015 11:08 AM, "Dehart, John" > wrote: >>> >>> >>> Is there any harm in it pushing the data out without knowing for sure if >>> the >>> Interest is still active? >>> >> If data is so critical, can the Interest be refreshed proactively before it >> expires? >> >> /anil >> >>> John >>> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff > wrote: >>>> >>>> >>>> >>>>> >>>>> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff > >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi folks, >>>>>> >>>>>> We are facing this scenario in a few applications: >>>>>> >>>>>> 1) Interest received by NFD, passed to an application >>>>>> 2) Application not able to respond to interest, so interest stays in >>>>>> NFD PIT >>>>>> 3) Some time passes, but not enough for the Interest to expire >>>>>> 4) Application generates data (e.g., from a sensor reading) that would >>>>>> answer the Interest in the NFD PIT >>>>>> >>>>>> Question: How does app know to inform NFD it has the data after step 4, >>>>>> and how should it do that? >>>>>> >>>>>> - In this type of app, should it push the data unsolicited to the NFD >>>>>> and let it decide if there is something to do? >>>>> >>>>> >>>>> In my opinion, as long as the application is certain that the Interest >>>>> has arrived and is stored in NFD's PIT, it can just push the data out to >>>>> NFD. >>>> >>>> >>>> >>>> How certain does it have to be? There is a chance it could have >>>> expired... >>>> jeff >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Wentao >>>>> >>>>>> >>>>>> - Is it recommended to implement an application-level PIT so the app is >>>>>> sure this data is solicited? (Why add another PIT?) >>>>>> >>>>>> Thank you, >>>>>> Jeff >>>>>> >>>>>> _______________________________________________ >>>>>> Nfd-dev mailing list >>>>>> Nfd-dev at lists.cs.ucla.edu >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>>> _______________________________________________ >>>> Nfd-dev mailing list >>>> Nfd-dev at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Mon Mar 30 13:06:56 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Mon, 30 Mar 2015 20:06:56 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: <8502CDD5-59EB-4E87-A022-F0DDC14DC1AE@parc.com> References: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> <5B579956-A6A1-4992-A259-E989C29E20C7@cisco.com> <8502CDD5-59EB-4E87-A022-F0DDC14DC1AE@parc.com> Message-ID: On Mon, Mar 30, 2015 at 12:52 PM wrote: > I?ll add that in addition to the content having a PIT entry, Nacho Solis > has suggested that a router should verify that a Content Object came in a > face from which it was requested. Otherwise, there?s a potential for > off-path attacks sending content objects that match popular well-known > names. A variation on that, rather than tracking forward paths, would be > to at minimum verify that a content object comes from a face for which > there?s a corresponding FIB entry for the name. > This requirement makes sense for transit routers that receive packets from other routers. But I'm not sure whether this is necessary for forwarding daemons handling local applications... The pushed data should never get out of the local forwarder unless there is a PIT entry specifying a path pointing to some other router. Wentao > > Marc > > On Mar 30, 2015, at 12:08 PM, Wentao Shang wrote: > > I agree with Dave. > > In principle, router should not cache unsolicited data. In the situation > we are discussing, the application should either just push the data out, > which may be dropped by NFD if the interest has expired, or store the data > in some application-level cache (or repo) for future fetching. > > Wentao > > On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) wrote: > >> Isn?t this what the repo was invented for? >> >> Holding packets in a router that has forgotten that they were asked for >> is a giant invitation to cache pollution/poisoning attacks. >> >> > On Mar 30, 2015, at 2:24 PM, Haowei Yuan wrote: >> > >> > I think as long as the data has actually been requested by an Interest >> > packet, it is safe to send the Data packet to NFD. The NFD will either >> > forward or drop the Data packet by checking if the Interest has >> > expired. >> > >> > If the Interest has expired, Data packet is dropped, and the consumer >> > is still interested in the data, the consumer could resend the >> > Interest. Hopefully this time, the Data packet can be generated and >> > sent faster by the application so that NFD will forward it. >> > >> > Haowei >> > >> > >> > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam >> wrote: >> >> >> >> On Mar 30, 2015 11:08 AM, "Dehart, John" wrote: >> >>> >> >>> >> >>> Is there any harm in it pushing the data out without knowing for sure >> if >> >>> the >> >>> Interest is still active? >> >>> >> >> If data is so critical, can the Interest be refreshed proactively >> before it >> >> expires? >> >> >> >> /anil >> >> >> >>> John >> >>> >> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff >> wrote: >> >>>> >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff > > >> >>>>> wrote: >> >>>>>> >> >>>>>> >> >>>>>> Hi folks, >> >>>>>> >> >>>>>> We are facing this scenario in a few applications: >> >>>>>> >> >>>>>> 1) Interest received by NFD, passed to an application >> >>>>>> 2) Application not able to respond to interest, so interest stays >> in >> >>>>>> NFD PIT >> >>>>>> 3) Some time passes, but not enough for the Interest to expire >> >>>>>> 4) Application generates data (e.g., from a sensor reading) that >> would >> >>>>>> answer the Interest in the NFD PIT >> >>>>>> >> >>>>>> Question: How does app know to inform NFD it has the data after >> step 4, >> >>>>>> and how should it do that? >> >>>>>> >> >>>>>> - In this type of app, should it push the data unsolicited to the >> NFD >> >>>>>> and let it decide if there is something to do? >> >>>>> >> >>>>> >> >>>>> In my opinion, as long as the application is certain that the >> Interest >> >>>>> has arrived and is stored in NFD's PIT, it can just push the data >> out to >> >>>>> NFD. >> >>>> >> >>>> >> >>>> >> >>>> How certain does it have to be? There is a chance it could have >> >>>> expired... >> >>>> jeff >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>>> >> >>>>> Wentao >> >>>>> >> >>>>>> >> >>>>>> - Is it recommended to implement an application-level PIT so the >> app is >> >>>>>> sure this data is solicited? (Why add another PIT?) >> >>>>>> >> >>>>>> Thank you, >> >>>>>> Jeff >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Nfd-dev mailing list >> >>>>>> Nfd-dev at lists.cs.ucla.edu >> >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >>>> >> >>>> _______________________________________________ >> >>>> Nfd-dev mailing list >> >>>> Nfd-dev at lists.cs.ucla.edu >> >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Nfd-dev mailing list >> >>> Nfd-dev at lists.cs.ucla.edu >> >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >>> >> > _______________________________________________ >> > Nfd-dev mailing list >> > Nfd-dev at lists.cs.ucla.edu >> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Mon Mar 30 13:21:21 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Mon, 30 Mar 2015 13:21:21 -0700 Subject: [Nfd-dev] Jenkins master migration In-Reply-To: References: Message-ID: There was some issue with disk on the new VM. I fixed errors and rebooted. Hopefully, now it would work normally. ? Alex > On Mar 30, 2015, at 12:12 PM, Vince Lehman (vslehman) wrote: > > Hi Eric, > > I also get a similar error to Davide and noticed that the NLSR build failed with this message in the logs: > > No such file: /var/lib/jenkins/jobs/NLSR/configurations/axis-label/FreeBSD10/builds/490/log > > -- > Vince Lehman > >> On Mar 30, 2015, at 1:29 PM, Davide Pesavento > wrote: >> >> Hi Eric, >> >> I'm not sure if it's related, but since today I'm getting a lot of >> java errors on jenkins.named-data.net web interface. Looks like a >> disk/filesystem issue, see below. >> >> java.io.IOException: Failed to create a temporary file in >> /var/lib/jenkins/users/davidepesa at gmail.com >> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:68) >> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:55) >> at hudson.XmlFile.write(XmlFile.java:175) >> at hudson.model.User.save(User.java:688) >> at hudson.model.User.addProperty(User.java:264) >> at org.jenkinsci.plugins.googlelogin.GoogleUserInfo.updateProfile(GoogleUserInfo.java:86) >> at org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm$2.onSuccess(GoogleOAuth2SecurityRealm.java:193) >> at org.jenkinsci.plugins.googlelogin.OAuthSession.doFinishLogin(OAuthSession.java:99) >> at org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm.doFinishLogin(GoogleOAuth2SecurityRealm.java:218) >> at sun.reflect.GeneratedMethodAccessor923.invoke(Unknown Source) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:606) >> at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) >> at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) >> at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) >> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121) >> at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) >> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) >> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) >> at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:211) >> at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) >> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) >> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) >> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) >> at org.kohsuke.stapler.Stapler.service(Stapler.java:238) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) >> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) >> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) >> at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:123) >> at hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter$1.call(ScmSyncConfigurationFilter.java:46) >> at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationDataProvider.provideRequestDuring(ScmSyncConfigurationDataProvider.java:103) >> at hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter.doFilter(ScmSyncConfigurationFilter.java:42) >> at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) >> at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:114) >> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >> at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) >> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >> at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) >> at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) >> at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) >> at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) >> at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135) >> at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) >> at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93) >> at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) >> at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) >> at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) >> at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:168) >> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >> at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) >> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >> at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) >> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >> at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30) >> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) >> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) >> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) >> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533) >> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) >> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086) >> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) >> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) >> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) >> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) >> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) >> at org.eclipse.jetty.server.Server.handle(Server.java:370) >> at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) >> at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) >> at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) >> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) >> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) >> at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) >> at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668) >> at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) >> at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> at java.lang.Thread.run(Thread.java:745) >> Caused by: java.io.IOException: Read-only file system >> at java.io.UnixFileSystem.createFileExclusively(Native Method) >> at java.io.File.createNewFile(File.java:1006) >> at java.io.File.createTempFile(File.java:1989) >> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:66) >> ... 84 more >> >> Thanks, >> Davide >> >> On Mon, Mar 30, 2015 at 4:29 PM, Junxiao Shi >> > wrote: >>> Dear folks >>> >>> jenkins.named-data.net has been migrated to a new master server on Mar 29 >>> evening. >>> The new master server sits on the same physical machine, but it is allocated >>> with more memory and disk space, and is created with Vagrant. >>> Thanks Eric for the hard work. >>> >>> This migration should have no impact on build jobs. >>> If you notice issues, please contact Eric (CC'ed) for help. >>> >>> Yours, Junxiao >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > _______________________________________________ > 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: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From davide.pesavento at lip6.fr Mon Mar 30 13:27:02 2015 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Mon, 30 Mar 2015 22:27:02 +0200 Subject: [Nfd-dev] Jenkins master migration In-Reply-To: References: Message-ID: I don't get the java error anymore, but I can't log out (I click on "log out" and I'm still logged in). On Mon, Mar 30, 2015 at 10:21 PM, Alex Afanasyev wrote: > There was some issue with disk on the new VM. I fixed errors and rebooted. > Hopefully, now it would work normally. > > ? > Alex > > > On Mar 30, 2015, at 12:12 PM, Vince Lehman (vslehman) > wrote: > > Hi Eric, > > I also get a similar error to Davide and noticed that the NLSR build failed > with this message in the logs: > > No such file: > /var/lib/jenkins/jobs/NLSR/configurations/axis-label/FreeBSD10/builds/490/log > > > -- > Vince Lehman > > On Mar 30, 2015, at 1:29 PM, Davide Pesavento > wrote: > > Hi Eric, > > I'm not sure if it's related, but since today I'm getting a lot of > java errors on jenkins.named-data.net web interface. Looks like a > disk/filesystem issue, see below. > > java.io.IOException: Failed to create a temporary file in > /var/lib/jenkins/users/davidepesa at gmail.com > at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:68) > at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:55) > at hudson.XmlFile.write(XmlFile.java:175) > at hudson.model.User.save(User.java:688) > at hudson.model.User.addProperty(User.java:264) > at > org.jenkinsci.plugins.googlelogin.GoogleUserInfo.updateProfile(GoogleUserInfo.java:86) > at > org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm$2.onSuccess(GoogleOAuth2SecurityRealm.java:193) > at > org.jenkinsci.plugins.googlelogin.OAuthSession.doFinishLogin(OAuthSession.java:99) > at > org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm.doFinishLogin(GoogleOAuth2SecurityRealm.java:218) > at sun.reflect.GeneratedMethodAccessor923.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) > at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) > at > org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) > at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121) > at > org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) > at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:211) > at > org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) > at org.kohsuke.stapler.Stapler.service(Stapler.java:238) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) > at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) > at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:123) > at > hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter$1.call(ScmSyncConfigurationFilter.java:46) > at > hudson.plugins.scm_sync_configuration.ScmSyncConfigurationDataProvider.provideRequestDuring(ScmSyncConfigurationDataProvider.java:103) > at > hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter.doFilter(ScmSyncConfigurationFilter.java:42) > at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) > at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:114) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) > at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) > at > hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) > at > hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) > at > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) > at > hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) > at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:168) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) > at > org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) > at > hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) > at > org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086) > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) > at org.eclipse.jetty.server.Server.handle(Server.java:370) > at > org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) > at > org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) > at > org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) > at > org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) > at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.io.IOException: Read-only file system > at java.io.UnixFileSystem.createFileExclusively(Native Method) > at java.io.File.createNewFile(File.java:1006) > at java.io.File.createTempFile(File.java:1989) > at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:66) > ... 84 more > > Thanks, > Davide > > On Mon, Mar 30, 2015 at 4:29 PM, Junxiao Shi > wrote: > > Dear folks > > jenkins.named-data.net has been migrated to a new master server on Mar 29 > evening. > The new master server sits on the same physical machine, but it is allocated > with more memory and disk space, and is created with Vagrant. > Thanks Eric for the hard work. > > This migration should have no impact on build jobs. > If you notice issues, please contact Eric (CC'ed) for help. > > Yours, Junxiao > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From oran at cisco.com Mon Mar 30 13:35:58 2015 From: oran at cisco.com (Dave Oran (oran)) Date: Mon, 30 Mar 2015 20:35:58 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: References: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> <5B579956-A6A1-4992-A259-E989C29E20C7@cisco.com> <8502CDD5-59EB-4E87-A022-F0DDC14DC1AE@parc.com> Message-ID: <8CA298E4-2814-4D73-ACB2-8515D4062977@cisco.com> > On Mar 30, 2015, at 4:06 PM, Wentao Shang wrote: > > > > On Mon, Mar 30, 2015 at 12:52 PM wrote: > I?ll add that in addition to the content having a PIT entry, Nacho Solis has suggested that a router should verify that a Content Object came in a face from which it was requested. Otherwise, there?s a potential for off-path attacks sending content objects that match popular well-known names. A variation on that, rather than tracking forward paths, would be to at minimum verify that a content object comes from a face for which there?s a corresponding FIB entry for the name. > > This requirement makes sense for transit routers that receive packets from other routers. But I'm not sure whether this is necessary for forwarding daemons handling local applications... The pushed data should never get out of the local forwarder unless there is a PIT entry specifying a path pointing to some other router. > If ?local? really means LOCAL (i.e. same machine) then the risks are low since you can only poison other applications on the same machine. However, I?ve noticed that the current NFD<->host stack design does not enforce same machine boundaries and in fact encourages remote NFD connections by using UDP sockets. I still think Mark Mosko?s rules should be enshrined in the architecture and the code. You can relax the ?local forwarder? case by having all the applications share one logical local face with no security isolation among them as far as the forwarder is concerned. Then the rule would be satisfied as the PIT would indicate the Interest was in fact forwarded over the same ?interface? that data came back from. DaveO. > Wentao > > > Marc > > On Mar 30, 2015, at 12:08 PM, Wentao Shang wrote: > >> I agree with Dave. >> >> In principle, router should not cache unsolicited data. In the situation we are discussing, the application should either just push the data out, which may be dropped by NFD if the interest has expired, or store the data in some application-level cache (or repo) for future fetching. >> >> Wentao >> >> On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) wrote: >> Isn?t this what the repo was invented for? >> >> Holding packets in a router that has forgotten that they were asked for is a giant invitation to cache pollution/poisoning attacks. >> >> > On Mar 30, 2015, at 2:24 PM, Haowei Yuan wrote: >> > >> > I think as long as the data has actually been requested by an Interest >> > packet, it is safe to send the Data packet to NFD. The NFD will either >> > forward or drop the Data packet by checking if the Interest has >> > expired. >> > >> > If the Interest has expired, Data packet is dropped, and the consumer >> > is still interested in the data, the consumer could resend the >> > Interest. Hopefully this time, the Data packet can be generated and >> > sent faster by the application so that NFD will forward it. >> > >> > Haowei >> > >> > >> > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam wrote: >> >> >> >> On Mar 30, 2015 11:08 AM, "Dehart, John" wrote: >> >>> >> >>> >> >>> Is there any harm in it pushing the data out without knowing for sure if >> >>> the >> >>> Interest is still active? >> >>> >> >> If data is so critical, can the Interest be refreshed proactively before it >> >> expires? >> >> >> >> /anil >> >> >> >>> John >> >>> >> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff wrote: >> >>>> >> >>>> >> >>>> >> >>>>> >> >>>>> >> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff >> >>>>> wrote: >> >>>>>> >> >>>>>> >> >>>>>> Hi folks, >> >>>>>> >> >>>>>> We are facing this scenario in a few applications: >> >>>>>> >> >>>>>> 1) Interest received by NFD, passed to an application >> >>>>>> 2) Application not able to respond to interest, so interest stays in >> >>>>>> NFD PIT >> >>>>>> 3) Some time passes, but not enough for the Interest to expire >> >>>>>> 4) Application generates data (e.g., from a sensor reading) that would >> >>>>>> answer the Interest in the NFD PIT >> >>>>>> >> >>>>>> Question: How does app know to inform NFD it has the data after step 4, >> >>>>>> and how should it do that? >> >>>>>> >> >>>>>> - In this type of app, should it push the data unsolicited to the NFD >> >>>>>> and let it decide if there is something to do? >> >>>>> >> >>>>> >> >>>>> In my opinion, as long as the application is certain that the Interest >> >>>>> has arrived and is stored in NFD's PIT, it can just push the data out to >> >>>>> NFD. >> >>>> >> >>>> >> >>>> >> >>>> How certain does it have to be? There is a chance it could have >> >>>> expired... >> >>>> jeff >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>>> >> >>>>> Wentao >> >>>>> >> >>>>>> >> >>>>>> - Is it recommended to implement an application-level PIT so the app is >> >>>>>> sure this data is solicited? (Why add another PIT?) >> >>>>>> >> >>>>>> Thank you, >> >>>>>> Jeff >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Nfd-dev mailing list >> >>>>>> Nfd-dev at lists.cs.ucla.edu >> >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >>>> >> >>>> _______________________________________________ >> >>>> Nfd-dev mailing list >> >>>> Nfd-dev at lists.cs.ucla.edu >> >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Nfd-dev mailing list >> >>> Nfd-dev at lists.cs.ucla.edu >> >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >>> >> > _______________________________________________ >> > Nfd-dev mailing list >> > Nfd-dev at lists.cs.ucla.edu >> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From davide.pesavento at lip6.fr Mon Mar 30 13:53:57 2015 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Mon, 30 Mar 2015 22:53:57 +0200 Subject: [Nfd-dev] Jenkins master migration In-Reply-To: <5519B31C.2030901@email.arizona.edu> References: <5519B31C.2030901@email.arizona.edu> Message-ID: Yes I'm still logged into google. Anyway, I don't particularly care about logout, I can just use a private/incognito session if needed. Thanks, Davide On Mon, Mar 30, 2015 at 10:33 PM, Eric Newberry wrote: > David, > > Are you still logged into Google after this? I believe that you have to log > out there or it will automatically log you back in when Google tells Jenkins > you have an active session. > > Eric Newberry > > Computer Science Undergraduate > The University of Arizona > > On 3/30/2015 1:27 PM, Davide Pesavento wrote: >> >> I don't get the java error anymore, but I can't log out (I click on >> "log out" and I'm still logged in). >> >> On Mon, Mar 30, 2015 at 10:21 PM, Alex Afanasyev >> wrote: >>> >>> There was some issue with disk on the new VM. I fixed errors and >>> rebooted. >>> Hopefully, now it would work normally. >>> >>> ? >>> Alex >>> >>> >>> On Mar 30, 2015, at 12:12 PM, Vince Lehman (vslehman) >>> >>> wrote: >>> >>> Hi Eric, >>> >>> I also get a similar error to Davide and noticed that the NLSR build >>> failed >>> with this message in the logs: >>> >>> No such file: >>> >>> /var/lib/jenkins/jobs/NLSR/configurations/axis-label/FreeBSD10/builds/490/log >>> >>> >>> -- >>> Vince Lehman >>> >>> On Mar 30, 2015, at 1:29 PM, Davide Pesavento >>> wrote: >>> >>> Hi Eric, >>> >>> I'm not sure if it's related, but since today I'm getting a lot of >>> java errors on jenkins.named-data.net web interface. Looks like a >>> disk/filesystem issue, see below. >>> >>> java.io.IOException: Failed to create a temporary file in >>> /var/lib/jenkins/users/davidepesa at gmail.com >>> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:68) >>> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:55) >>> at hudson.XmlFile.write(XmlFile.java:175) >>> at hudson.model.User.save(User.java:688) >>> at hudson.model.User.addProperty(User.java:264) >>> at >>> >>> org.jenkinsci.plugins.googlelogin.GoogleUserInfo.updateProfile(GoogleUserInfo.java:86) >>> at >>> >>> org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm$2.onSuccess(GoogleOAuth2SecurityRealm.java:193) >>> at >>> >>> org.jenkinsci.plugins.googlelogin.OAuthSession.doFinishLogin(OAuthSession.java:99) >>> at >>> >>> org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm.doFinishLogin(GoogleOAuth2SecurityRealm.java:218) >>> at sun.reflect.GeneratedMethodAccessor923.invoke(Unknown Source) >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:606) >>> at >>> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) >>> at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) >>> at >>> >>> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) >>> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121) >>> at >>> >>> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) >>> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) >>> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) >>> at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:211) >>> at >>> >>> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) >>> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) >>> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) >>> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) >>> at org.kohsuke.stapler.Stapler.service(Stapler.java:238) >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) >>> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) >>> at >>> >>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) >>> at >>> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:123) >>> at >>> >>> hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter$1.call(ScmSyncConfigurationFilter.java:46) >>> at >>> >>> hudson.plugins.scm_sync_configuration.ScmSyncConfigurationDataProvider.provideRequestDuring(ScmSyncConfigurationDataProvider.java:103) >>> at >>> >>> hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter.doFilter(ScmSyncConfigurationFilter.java:42) >>> at >>> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) >>> at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:114) >>> at >>> >>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >>> at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) >>> at >>> >>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >>> at >>> >>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) >>> at >>> >>> hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) >>> at >>> >>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>> at >>> >>> jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) >>> at >>> >>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>> at >>> >>> org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) >>> at >>> >>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>> at >>> >>> org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135) >>> at >>> >>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>> at >>> >>> org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) >>> at >>> >>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>> at >>> >>> jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93) >>> at >>> >>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>> at >>> >>> org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) >>> at >>> >>> hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) >>> at >>> >>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>> at >>> >>> hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) >>> at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:168) >>> at >>> >>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >>> at >>> >>> org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) >>> at >>> >>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >>> at >>> >>> hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) >>> at >>> >>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >>> at >>> >>> org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30) >>> at >>> >>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) >>> at >>> >>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) >>> at >>> >>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) >>> at >>> >>> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533) >>> at >>> >>> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) >>> at >>> >>> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086) >>> at >>> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) >>> at >>> >>> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) >>> at >>> >>> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) >>> at >>> >>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) >>> at >>> >>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) >>> at org.eclipse.jetty.server.Server.handle(Server.java:370) >>> at >>> >>> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) >>> at >>> >>> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) >>> at >>> >>> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) >>> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) >>> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) >>> at >>> >>> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) >>> at >>> >>> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668) >>> at >>> >>> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) >>> at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>> at java.lang.Thread.run(Thread.java:745) >>> Caused by: java.io.IOException: Read-only file system >>> at java.io.UnixFileSystem.createFileExclusively(Native Method) >>> at java.io.File.createNewFile(File.java:1006) >>> at java.io.File.createTempFile(File.java:1989) >>> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:66) >>> ... 84 more >>> >>> Thanks, >>> Davide >>> >>> On Mon, Mar 30, 2015 at 4:29 PM, Junxiao Shi >>> wrote: >>> >>> Dear folks >>> >>> jenkins.named-data.net has been migrated to a new master server on Mar 29 >>> evening. >>> The new master server sits on the same physical machine, but it is >>> allocated >>> with more memory and disk space, and is created with Vagrant. >>> Thanks Eric for the hard work. >>> >>> This migration should have no impact on build jobs. >>> If you notice issues, please contact Eric (CC'ed) for help. >>> >>> Yours, Junxiao >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> > From alexander.afanasyev at ucla.edu Mon Mar 30 14:05:26 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Mon, 30 Mar 2015 14:05:26 -0700 Subject: [Nfd-dev] Jenkins master migration In-Reply-To: References: <5519B31C.2030901@email.arizona.edu> Message-ID: Jenkins is set up to login automatically when you're not logged in. I guess, this is the reason you see that you're being logged in. --- Alex > On Mar 30, 2015, at 1:53 PM, Davide Pesavento wrote: > > Yes I'm still logged into google. > Anyway, I don't particularly care about logout, I can just use a > private/incognito session if needed. > > Thanks, > Davide > > On Mon, Mar 30, 2015 at 10:33 PM, Eric Newberry > wrote: >> David, >> >> Are you still logged into Google after this? I believe that you have to log >> out there or it will automatically log you back in when Google tells Jenkins >> you have an active session. >> >> Eric Newberry >> >> Computer Science Undergraduate >> The University of Arizona >> >> On 3/30/2015 1:27 PM, Davide Pesavento wrote: >>> >>> I don't get the java error anymore, but I can't log out (I click on >>> "log out" and I'm still logged in). >>> >>> On Mon, Mar 30, 2015 at 10:21 PM, Alex Afanasyev >>> wrote: >>>> >>>> There was some issue with disk on the new VM. I fixed errors and >>>> rebooted. >>>> Hopefully, now it would work normally. >>>> >>>> ? >>>> Alex >>>> >>>> >>>> On Mar 30, 2015, at 12:12 PM, Vince Lehman (vslehman) >>>> >>>> wrote: >>>> >>>> Hi Eric, >>>> >>>> I also get a similar error to Davide and noticed that the NLSR build >>>> failed >>>> with this message in the logs: >>>> >>>> No such file: >>>> >>>> /var/lib/jenkins/jobs/NLSR/configurations/axis-label/FreeBSD10/builds/490/log >>>> >>>> >>>> -- >>>> Vince Lehman >>>> >>>> On Mar 30, 2015, at 1:29 PM, Davide Pesavento >>>> wrote: >>>> >>>> Hi Eric, >>>> >>>> I'm not sure if it's related, but since today I'm getting a lot of >>>> java errors on jenkins.named-data.net web interface. Looks like a >>>> disk/filesystem issue, see below. >>>> >>>> java.io.IOException: Failed to create a temporary file in >>>> /var/lib/jenkins/users/davidepesa at gmail.com >>>> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:68) >>>> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:55) >>>> at hudson.XmlFile.write(XmlFile.java:175) >>>> at hudson.model.User.save(User.java:688) >>>> at hudson.model.User.addProperty(User.java:264) >>>> at >>>> >>>> org.jenkinsci.plugins.googlelogin.GoogleUserInfo.updateProfile(GoogleUserInfo.java:86) >>>> at >>>> >>>> org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm$2.onSuccess(GoogleOAuth2SecurityRealm.java:193) >>>> at >>>> >>>> org.jenkinsci.plugins.googlelogin.OAuthSession.doFinishLogin(OAuthSession.java:99) >>>> at >>>> >>>> org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm.doFinishLogin(GoogleOAuth2SecurityRealm.java:218) >>>> at sun.reflect.GeneratedMethodAccessor923.invoke(Unknown Source) >>>> at >>>> >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:606) >>>> at >>>> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) >>>> at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) >>>> at >>>> >>>> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) >>>> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121) >>>> at >>>> >>>> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) >>>> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) >>>> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) >>>> at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:211) >>>> at >>>> >>>> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) >>>> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) >>>> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) >>>> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) >>>> at org.kohsuke.stapler.Stapler.service(Stapler.java:238) >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) >>>> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) >>>> at >>>> >>>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) >>>> at >>>> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:123) >>>> at >>>> >>>> hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter$1.call(ScmSyncConfigurationFilter.java:46) >>>> at >>>> >>>> hudson.plugins.scm_sync_configuration.ScmSyncConfigurationDataProvider.provideRequestDuring(ScmSyncConfigurationDataProvider.java:103) >>>> at >>>> >>>> hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter.doFilter(ScmSyncConfigurationFilter.java:42) >>>> at >>>> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) >>>> at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:114) >>>> at >>>> >>>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >>>> at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) >>>> at >>>> >>>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >>>> at >>>> >>>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) >>>> at >>>> >>>> hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) >>>> at >>>> >>>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>>> at >>>> >>>> jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) >>>> at >>>> >>>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>>> at >>>> >>>> org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) >>>> at >>>> >>>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>>> at >>>> >>>> org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135) >>>> at >>>> >>>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>>> at >>>> >>>> org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) >>>> at >>>> >>>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>>> at >>>> >>>> jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93) >>>> at >>>> >>>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>>> at >>>> >>>> org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) >>>> at >>>> >>>> hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) >>>> at >>>> >>>> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >>>> at >>>> >>>> hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) >>>> at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:168) >>>> at >>>> >>>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >>>> at >>>> >>>> org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) >>>> at >>>> >>>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >>>> at >>>> >>>> hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) >>>> at >>>> >>>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >>>> at >>>> >>>> org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30) >>>> at >>>> >>>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) >>>> at >>>> >>>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) >>>> at >>>> >>>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) >>>> at >>>> >>>> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533) >>>> at >>>> >>>> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) >>>> at >>>> >>>> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086) >>>> at >>>> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) >>>> at >>>> >>>> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) >>>> at >>>> >>>> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) >>>> at >>>> >>>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) >>>> at >>>> >>>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) >>>> at org.eclipse.jetty.server.Server.handle(Server.java:370) >>>> at >>>> >>>> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) >>>> at >>>> >>>> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) >>>> at >>>> >>>> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) >>>> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) >>>> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) >>>> at >>>> >>>> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) >>>> at >>>> >>>> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668) >>>> at >>>> >>>> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) >>>> at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) >>>> at >>>> >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>> at >>>> >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>> at java.lang.Thread.run(Thread.java:745) >>>> Caused by: java.io.IOException: Read-only file system >>>> at java.io.UnixFileSystem.createFileExclusively(Native Method) >>>> at java.io.File.createNewFile(File.java:1006) >>>> at java.io.File.createTempFile(File.java:1989) >>>> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:66) >>>> ... 84 more >>>> >>>> Thanks, >>>> Davide >>>> >>>> On Mon, Mar 30, 2015 at 4:29 PM, Junxiao Shi >>>> wrote: >>>> >>>> Dear folks >>>> >>>> jenkins.named-data.net has been migrated to a new master server on Mar 29 >>>> evening. >>>> The new master server sits on the same physical machine, but it is >>>> allocated >>>> with more memory and disk space, and is created with Vagrant. >>>> Thanks Eric for the hard work. >>>> >>>> This migration should have no impact on build jobs. >>>> If you notice issues, please contact Eric (CC'ed) for help. >>>> >>>> Yours, Junxiao >>>> >>>> _______________________________________________ >>>> Nfd-dev mailing list >>>> Nfd-dev at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>>> _______________________________________________ >>>> Nfd-dev mailing list >>>> Nfd-dev at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>>> >>>> _______________________________________________ >>>> Nfd-dev mailing list >>>> Nfd-dev at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Nfd-dev mailing list >>>> Nfd-dev at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >> -------------- next part -------------- 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 enewberry at email.arizona.edu Mon Mar 30 11:45:23 2015 From: enewberry at email.arizona.edu (Eric Newberry) Date: Mon, 30 Mar 2015 11:45:23 -0700 Subject: [Nfd-dev] Jenkins master migration Message-ID: I'll look into this issue today. Eric -- Eric Newberry Computer Science Undergraduate The University of Arizona Davide Pesavento wrote: >Hi Eric, > >I'm not sure if it's related, but since today I'm getting a lot of >java errors on jenkins.named-data.net web interface. Looks like a >disk/filesystem issue, see below. > >java.io.IOException: Failed to create a temporary file in >/var/lib/jenkins/users/davidepesa at gmail.com >at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:68) >at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:55) >at hudson.XmlFile.write(XmlFile.java:175) >at hudson.model.User.save(User.java:688) >at hudson.model.User.addProperty(User.java:264) >at org.jenkinsci.plugins.googlelogin.GoogleUserInfo.updateProfile(GoogleUserInfo.java:86) >at org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm$2.onSuccess(GoogleOAuth2SecurityRealm.java:193) >at org.jenkinsci.plugins.googlelogin.OAuthSession.doFinishLogin(OAuthSession.java:99) >at org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm.doFinishLogin(GoogleOAuth2SecurityRealm.java:218) >at sun.reflect.GeneratedMethodAccessor923.invoke(Unknown Source) >at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >at java.lang.reflect.Method.invoke(Method.java:606) >at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) >at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) >at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) >at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121) >at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) >at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) >at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) >at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:211) >at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) >at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) >at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) >at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) >at org.kohsuke.stapler.Stapler.service(Stapler.java:238) >at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) >at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) >at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) >at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:123) >at hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter$1.call(ScmSyncConfigurationFilter.java:46) >at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationDataProvider.provideRequestDuring(ScmSyncConfigurationDataProvider.java:103) >at hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter.doFilter(ScmSyncConfigurationFilter.java:42) >at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) >at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:114) >at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) >at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) >at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) >at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) >at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) >at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135) >at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) >at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93) >at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) >at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) >at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) >at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:168) >at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) >at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) >at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30) >at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) >at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) >at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) >at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533) >at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) >at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086) >at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) >at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) >at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) >at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) >at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) >at org.eclipse.jetty.server.Server.handle(Server.java:370) >at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) >at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) >at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) >at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) >at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) >at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) >at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668) >at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) >at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) >at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >at java.lang.Thread.run(Thread.java:745) >Caused by: java.io.IOException: Read-only file system >at java.io.UnixFileSystem.createFileExclusively(Native Method) >at java.io.File.createNewFile(File.java:1006) >at java.io.File.createTempFile(File.java:1989) >at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:66) >... 84 more > >Thanks, >Davide > >On Mon, Mar 30, 2015 at 4:29 PM, Junxiao Shi > wrote: >> Dear folks >> >> jenkins.named-data.net has been migrated to a new master server on Mar 29 >> evening. >> The new master server sits on the same physical machine, but it is allocated >> with more memory and disk space, and is created with Vagrant. >> Thanks Eric for the hard work. >> >> This migration should have no impact on build jobs. >> If you notice issues, please contact Eric (CC'ed) for help. >> >> Yours, Junxiao >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From enewberry at email.arizona.edu Mon Mar 30 13:33:32 2015 From: enewberry at email.arizona.edu (Eric Newberry) Date: Mon, 30 Mar 2015 13:33:32 -0700 Subject: [Nfd-dev] Jenkins master migration In-Reply-To: References: Message-ID: <5519B31C.2030901@email.arizona.edu> David, Are you still logged into Google after this? I believe that you have to log out there or it will automatically log you back in when Google tells Jenkins you have an active session. Eric Newberry Computer Science Undergraduate The University of Arizona On 3/30/2015 1:27 PM, Davide Pesavento wrote: > I don't get the java error anymore, but I can't log out (I click on > "log out" and I'm still logged in). > > On Mon, Mar 30, 2015 at 10:21 PM, Alex Afanasyev > wrote: >> There was some issue with disk on the new VM. I fixed errors and rebooted. >> Hopefully, now it would work normally. >> >> ? >> Alex >> >> >> On Mar 30, 2015, at 12:12 PM, Vince Lehman (vslehman) >> wrote: >> >> Hi Eric, >> >> I also get a similar error to Davide and noticed that the NLSR build failed >> with this message in the logs: >> >> No such file: >> /var/lib/jenkins/jobs/NLSR/configurations/axis-label/FreeBSD10/builds/490/log >> >> >> -- >> Vince Lehman >> >> On Mar 30, 2015, at 1:29 PM, Davide Pesavento >> wrote: >> >> Hi Eric, >> >> I'm not sure if it's related, but since today I'm getting a lot of >> java errors on jenkins.named-data.net web interface. Looks like a >> disk/filesystem issue, see below. >> >> java.io.IOException: Failed to create a temporary file in >> /var/lib/jenkins/users/davidepesa at gmail.com >> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:68) >> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:55) >> at hudson.XmlFile.write(XmlFile.java:175) >> at hudson.model.User.save(User.java:688) >> at hudson.model.User.addProperty(User.java:264) >> at >> org.jenkinsci.plugins.googlelogin.GoogleUserInfo.updateProfile(GoogleUserInfo.java:86) >> at >> org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm$2.onSuccess(GoogleOAuth2SecurityRealm.java:193) >> at >> org.jenkinsci.plugins.googlelogin.OAuthSession.doFinishLogin(OAuthSession.java:99) >> at >> org.jenkinsci.plugins.googlelogin.GoogleOAuth2SecurityRealm.doFinishLogin(GoogleOAuth2SecurityRealm.java:218) >> at sun.reflect.GeneratedMethodAccessor923.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:606) >> at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) >> at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) >> at >> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) >> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121) >> at >> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) >> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) >> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) >> at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:211) >> at >> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) >> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) >> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) >> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) >> at org.kohsuke.stapler.Stapler.service(Stapler.java:238) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) >> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) >> at >> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) >> at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:123) >> at >> hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter$1.call(ScmSyncConfigurationFilter.java:46) >> at >> hudson.plugins.scm_sync_configuration.ScmSyncConfigurationDataProvider.provideRequestDuring(ScmSyncConfigurationDataProvider.java:103) >> at >> hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter.doFilter(ScmSyncConfigurationFilter.java:42) >> at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) >> at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:114) >> at >> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >> at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) >> at >> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >> at >> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) >> at >> hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) >> at >> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at >> jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) >> at >> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at >> org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) >> at >> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at >> org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135) >> at >> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at >> org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) >> at >> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at >> jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93) >> at >> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at >> org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) >> at >> hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) >> at >> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) >> at >> hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) >> at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:168) >> at >> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >> at >> org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) >> at >> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >> at >> hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) >> at >> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) >> at >> org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30) >> at >> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) >> at >> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) >> at >> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) >> at >> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533) >> at >> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) >> at >> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086) >> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) >> at >> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) >> at >> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) >> at >> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) >> at >> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) >> at org.eclipse.jetty.server.Server.handle(Server.java:370) >> at >> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) >> at >> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) >> at >> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) >> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) >> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) >> at >> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) >> at >> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668) >> at >> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) >> at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> at java.lang.Thread.run(Thread.java:745) >> Caused by: java.io.IOException: Read-only file system >> at java.io.UnixFileSystem.createFileExclusively(Native Method) >> at java.io.File.createNewFile(File.java:1006) >> at java.io.File.createTempFile(File.java:1989) >> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:66) >> ... 84 more >> >> Thanks, >> Davide >> >> On Mon, Mar 30, 2015 at 4:29 PM, Junxiao Shi >> wrote: >> >> Dear folks >> >> jenkins.named-data.net has been migrated to a new master server on Mar 29 >> evening. >> The new master server sits on the same physical machine, but it is allocated >> with more memory and disk space, and is created with Vagrant. >> Thanks Eric for the hard work. >> >> This migration should have no impact on build jobs. >> If you notice issues, please contact Eric (CC'ed) for help. >> >> Yours, Junxiao >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> >> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> From Ignacio.Solis at parc.com Mon Mar 30 15:42:11 2015 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Mon, 30 Mar 2015 22:42:11 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: References: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> <5B579956-A6A1-4992-A259-E989C29E20C7@cisco.com> <8502CDD5-59EB-4E87-A022-F0DDC14DC1AE@parc.com>, Message-ID: <38eaa314-f5bf-40e5-8773-305fa2633fc3@parc.com> This rule is important, router or not. You can't have "non-priviledged" applications generating replies at servers. Specially important at systems with multiple users, tenants, virtual systems. At the local router there are even more restrictions. We haven't even gotten to talking about privileged names and restrictions and end-h out behavior. We have a design for this for CCN that we'll be talking about at CCNxCon. Nacho (Ignacio) Solis Principal Scientist Palo Alto Research Center From: Wentao Shang Sent: Mar 30, 2015 1:07 PM To: Mosko, Marc Cc: nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] Handling new content in app for pending interest in NFD On Mon, Mar 30, 2015 at 12:52 PM > wrote: I?ll add that in addition to the content having a PIT entry, Nacho Solis has suggested that a router should verify that a Content Object came in a face from which it was requested. Otherwise, there?s a potential for off-path attacks sending content objects that match popular well-known names. A variation on that, rather than tracking forward paths, would be to at minimum verify that a content object comes from a face for which there?s a corresponding FIB entry for the name. This requirement makes sense for transit routers that receive packets from other routers. But I'm not sure whether this is necessary for forwarding daemons handling local applications... The pushed data should never get out of the local forwarder unless there is a PIT entry specifying a path pointing to some other router. Wentao Marc On Mar 30, 2015, at 12:08 PM, Wentao Shang > wrote: I agree with Dave. In principle, router should not cache unsolicited data. In the situation we are discussing, the application should either just push the data out, which may be dropped by NFD if the interest has expired, or store the data in some application-level cache (or repo) for future fetching. Wentao On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) > wrote: Isn?t this what the repo was invented for? Holding packets in a router that has forgotten that they were asked for is a giant invitation to cache pollution/poisoning attacks. > On Mar 30, 2015, at 2:24 PM, Haowei Yuan > wrote: > > I think as long as the data has actually been requested by an Interest > packet, it is safe to send the Data packet to NFD. The NFD will either > forward or drop the Data packet by checking if the Interest has > expired. > > If the Interest has expired, Data packet is dropped, and the consumer > is still interested in the data, the consumer could resend the > Interest. Hopefully this time, the Data packet can be generated and > sent faster by the application so that NFD will forward it. > > Haowei > > > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam > wrote: >> >> On Mar 30, 2015 11:08 AM, "Dehart, John" > wrote: >>> >>> >>> Is there any harm in it pushing the data out without knowing for sure if >>> the >>> Interest is still active? >>> >> If data is so critical, can the Interest be refreshed proactively before it >> expires? >> >> /anil >> >>> John >>> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff > wrote: >>>> >>>> >>>> >>>>> >>>>> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff > >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi folks, >>>>>> >>>>>> We are facing this scenario in a few applications: >>>>>> >>>>>> 1) Interest received by NFD, passed to an application >>>>>> 2) Application not able to respond to interest, so interest stays in >>>>>> NFD PIT >>>>>> 3) Some time passes, but not enough for the Interest to expire >>>>>> 4) Application generates data (e.g., from a sensor reading) that would >>>>>> answer the Interest in the NFD PIT >>>>>> >>>>>> Question: How does app know to inform NFD it has the data after step 4, >>>>>> and how should it do that? >>>>>> >>>>>> - In this type of app, should it push the data unsolicited to the NFD >>>>>> and let it decide if there is something to do? >>>>> >>>>> >>>>> In my opinion, as long as the application is certain that the Interest >>>>> has arrived and is stored in NFD's PIT, it can just push the data out to >>>>> NFD. >>>> >>>> >>>> >>>> How certain does it have to be? There is a chance it could have >>>> expired... >>>> jeff >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Wentao >>>>> >>>>>> >>>>>> - Is it recommended to implement an application-level PIT so the app is >>>>>> sure this data is solicited? (Why add another PIT?) >>>>>> >>>>>> Thank you, >>>>>> Jeff >>>>>> >>>>>> _______________________________________________ >>>>>> Nfd-dev mailing list >>>>>> Nfd-dev at lists.cs.ucla.edu >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>>> _______________________________________________ >>>> Nfd-dev mailing list >>>> Nfd-dev at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Mon Mar 30 16:50:28 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Mon, 30 Mar 2015 23:50:28 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: <38eaa314-f5bf-40e5-8773-305fa2633fc3@parc.com> References: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> <5B579956-A6A1-4992-A259-E989C29E20C7@cisco.com> <8502CDD5-59EB-4E87-A022-F0DDC14DC1AE@parc.com> <38eaa314-f5bf-40e5-8773-305fa2633fc3@parc.com> Message-ID: Hi Nacho, I don't have any argument against this rule right now. But it seems more relevant to "forwarding" data packets, while the problem we were discussing is about "caching" unsolicited data packets, which cannot be forwarded anyway because there is no PIT. The simplest solution I would suggest to the problem is to drop any unsolicited data in the forwarder. Wentao On Mon, Mar 30, 2015 at 3:42 PM wrote: > This rule is important, router or not. You can't have "non-priviledged" > applications generating replies at servers. Specially important at systems > with multiple users, tenants, virtual systems. > > At the local router there are even more restrictions. We haven't even > gotten to talking about privileged names and restrictions and end-h out > behavior. We have a design for this for CCN that we'll be talking about > at CCNxCon. > > Nacho (Ignacio) Solis > Principal Scientist > Palo Alto Research Center > > *From:* Wentao Shang > *Sent:* Mar 30, 2015 1:07 PM > *To:* Mosko, Marc > > *Cc:* nfd-dev at lists.cs.ucla.edu > *Subject:* Re: [Nfd-dev] Handling new content in app for pending interest > in NFD > > On Mon, Mar 30, 2015 at 12:52 PM wrote: > >> I?ll add that in addition to the content having a PIT entry, Nacho Solis >> has suggested that a router should verify that a Content Object came in a >> face from which it was requested. Otherwise, there?s a potential for >> off-path attacks sending content objects that match popular well-known >> names. A variation on that, rather than tracking forward paths, would be >> to at minimum verify that a content object comes from a face for which >> there?s a corresponding FIB entry for the name. >> > > This requirement makes sense for transit routers that receive packets > from other routers. But I'm not sure whether this is necessary for > forwarding daemons handling local applications... The pushed data should > never get out of the local forwarder unless there is a PIT entry specifying > a path pointing to some other router. > > Wentao > > >> >> Marc >> >> On Mar 30, 2015, at 12:08 PM, Wentao Shang >> wrote: >> >> I agree with Dave. >> >> In principle, router should not cache unsolicited data. In the >> situation we are discussing, the application should either just push the >> data out, which may be dropped by NFD if the interest has expired, or store >> the data in some application-level cache (or repo) for future fetching. >> >> Wentao >> >> On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) wrote: >> >>> Isn?t this what the repo was invented for? >>> >>> Holding packets in a router that has forgotten that they were asked for >>> is a giant invitation to cache pollution/poisoning attacks. >>> >>> > On Mar 30, 2015, at 2:24 PM, Haowei Yuan wrote: >>> > >>> > I think as long as the data has actually been requested by an Interest >>> > packet, it is safe to send the Data packet to NFD. The NFD will either >>> > forward or drop the Data packet by checking if the Interest has >>> > expired. >>> > >>> > If the Interest has expired, Data packet is dropped, and the consumer >>> > is still interested in the data, the consumer could resend the >>> > Interest. Hopefully this time, the Data packet can be generated and >>> > sent faster by the application so that NFD will forward it. >>> > >>> > Haowei >>> > >>> > >>> > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam >>> wrote: >>> >> >>> >> On Mar 30, 2015 11:08 AM, "Dehart, John" wrote: >>> >>> >>> >>> >>> >>> Is there any harm in it pushing the data out without knowing for >>> sure if >>> >>> the >>> >>> Interest is still active? >>> >>> >>> >> If data is so critical, can the Interest be refreshed proactively >>> before it >>> >> expires? >>> >> >>> >> /anil >>> >> >>> >>> John >>> >>> >>> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff >>> wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff < >>> jburke at remap.ucla.edu> >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> >>> >>>>>> Hi folks, >>> >>>>>> >>> >>>>>> We are facing this scenario in a few applications: >>> >>>>>> >>> >>>>>> 1) Interest received by NFD, passed to an application >>> >>>>>> 2) Application not able to respond to interest, so interest stays >>> in >>> >>>>>> NFD PIT >>> >>>>>> 3) Some time passes, but not enough for the Interest to expire >>> >>>>>> 4) Application generates data (e.g., from a sensor reading) that >>> would >>> >>>>>> answer the Interest in the NFD PIT >>> >>>>>> >>> >>>>>> Question: How does app know to inform NFD it has the data after >>> step 4, >>> >>>>>> and how should it do that? >>> >>>>>> >>> >>>>>> - In this type of app, should it push the data unsolicited to the >>> NFD >>> >>>>>> and let it decide if there is something to do? >>> >>>>> >>> >>>>> >>> >>>>> In my opinion, as long as the application is certain that the >>> Interest >>> >>>>> has arrived and is stored in NFD's PIT, it can just push the data >>> out to >>> >>>>> NFD. >>> >>>> >>> >>>> >>> >>>> >>> >>>> How certain does it have to be? There is a chance it could have >>> >>>> expired... >>> >>>> jeff >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> Wentao >>> >>>>> >>> >>>>>> >>> >>>>>> - Is it recommended to implement an application-level PIT so the >>> app is >>> >>>>>> sure this data is solicited? (Why add another PIT?) >>> >>>>>> >>> >>>>>> Thank you, >>> >>>>>> Jeff >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> Nfd-dev mailing list >>> >>>>>> Nfd-dev at lists.cs.ucla.edu >>> >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>>> >>> >>>> _______________________________________________ >>> >>>> Nfd-dev mailing list >>> >>>> Nfd-dev at lists.cs.ucla.edu >>> >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Nfd-dev mailing list >>> >>> Nfd-dev at lists.cs.ucla.edu >>> >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> >>> > _______________________________________________ >>> > Nfd-dev mailing list >>> > Nfd-dev at lists.cs.ucla.edu >>> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ignacio.Solis at parc.com Mon Mar 30 17:06:33 2015 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Tue, 31 Mar 2015 00:06:33 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: References: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> <5B579956-A6A1-4992-A259-E989C29E20C7@cisco.com> <8502CDD5-59EB-4E87-A022-F0DDC14DC1AE@parc.com> <38eaa314-f5bf-40e5-8773-305fa2633fc3@parc.com>, Message-ID: <6cae5fe4-c081-44da-ad7c-17b311ca2ccc@parc.com> I'm going to guess that caching data rules will be the same as forwarding rules. If the interface is not allowed to produce that content (due to routing / fib entries, local naming policy) data should not be forwarded OR cached. NDN has a slightly more complicated problem with caching than CCN given then LPM matching rules. If you have a repo that has permission to serve this content then you changed the problem. Now you need the repo protocol to give you trust. For regular forwarding you are relying on trusting routing. For local apps you will rely (I assume) on local permissions. For repo you will need both of those plus now a repo permission protocol. Dropping unsolicited data may end up being your only recourse. There are obviously other approaches for pre-populating caches that involve higher level protocols, but I assume that's not what you're talking about. Nacho (Ignacio) Solis Principal Scientist Palo Alto Research Center From: Wentao Shang Sent: Mar 30, 2015 4:50 PM To: "Solis, Ignacio " ;Mosko, Marc Cc: nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] Handling new content in app for pending interest in NFD Hi Nacho, I don't have any argument against this rule right now. But it seems more relevant to "forwarding" data packets, while the problem we were discussing is about "caching" unsolicited data packets, which cannot be forwarded anyway because there is no PIT. The simplest solution I would suggest to the problem is to drop any unsolicited data in the forwarder. Wentao On Mon, Mar 30, 2015 at 3:42 PM > wrote: This rule is important, router or not. You can't have "non-priviledged" applications generating replies at servers. Specially important at systems with multiple users, tenants, virtual systems. At the local router there are even more restrictions. We haven't even gotten to talking about privileged names and restrictions and end-h out behavior. We have a design for this for CCN that we'll be talking about at CCNxCon. Nacho (Ignacio) Solis Principal Scientist Palo Alto Research Center From: Wentao Shang > Sent: Mar 30, 2015 1:07 PM To: Mosko, Marc > Cc: nfd-dev at lists.cs.ucla.edu Subject: Re: [Nfd-dev] Handling new content in app for pending interest in NFD On Mon, Mar 30, 2015 at 12:52 PM > wrote: I?ll add that in addition to the content having a PIT entry, Nacho Solis has suggested that a router should verify that a Content Object came in a face from which it was requested. Otherwise, there?s a potential for off-path attacks sending content objects that match popular well-known names. A variation on that, rather than tracking forward paths, would be to at minimum verify that a content object comes from a face for which there?s a corresponding FIB entry for the name. This requirement makes sense for transit routers that receive packets from other routers. But I'm not sure whether this is necessary for forwarding daemons handling local applications... The pushed data should never get out of the local forwarder unless there is a PIT entry specifying a path pointing to some other router. Wentao Marc On Mar 30, 2015, at 12:08 PM, Wentao Shang > wrote: I agree with Dave. In principle, router should not cache unsolicited data. In the situation we are discussing, the application should either just push the data out, which may be dropped by NFD if the interest has expired, or store the data in some application-level cache (or repo) for future fetching. Wentao On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) > wrote: Isn?t this what the repo was invented for? Holding packets in a router that has forgotten that they were asked for is a giant invitation to cache pollution/poisoning attacks. > On Mar 30, 2015, at 2:24 PM, Haowei Yuan > wrote: > > I think as long as the data has actually been requested by an Interest > packet, it is safe to send the Data packet to NFD. The NFD will either > forward or drop the Data packet by checking if the Interest has > expired. > > If the Interest has expired, Data packet is dropped, and the consumer > is still interested in the data, the consumer could resend the > Interest. Hopefully this time, the Data packet can be generated and > sent faster by the application so that NFD will forward it. > > Haowei > > > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam > wrote: >> >> On Mar 30, 2015 11:08 AM, "Dehart, John" > wrote: >>> >>> >>> Is there any harm in it pushing the data out without knowing for sure if >>> the >>> Interest is still active? >>> >> If data is so critical, can the Interest be refreshed proactively before it >> expires? >> >> /anil >> >>> John >>> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff > wrote: >>>> >>>> >>>> >>>>> >>>>> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff > >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi folks, >>>>>> >>>>>> We are facing this scenario in a few applications: >>>>>> >>>>>> 1) Interest received by NFD, passed to an application >>>>>> 2) Application not able to respond to interest, so interest stays in >>>>>> NFD PIT >>>>>> 3) Some time passes, but not enough for the Interest to expire >>>>>> 4) Application generates data (e.g., from a sensor reading) that would >>>>>> answer the Interest in the NFD PIT >>>>>> >>>>>> Question: How does app know to inform NFD it has the data after step 4, >>>>>> and how should it do that? >>>>>> >>>>>> - In this type of app, should it push the data unsolicited to the NFD >>>>>> and let it decide if there is something to do? >>>>> >>>>> >>>>> In my opinion, as long as the application is certain that the Interest >>>>> has arrived and is stored in NFD's PIT, it can just push the data out to >>>>> NFD. >>>> >>>> >>>> >>>> How certain does it have to be? There is a chance it could have >>>> expired... >>>> jeff >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Wentao >>>>> >>>>>> >>>>>> - Is it recommended to implement an application-level PIT so the app is >>>>>> sure this data is solicited? (Why add another PIT?) >>>>>> >>>>>> Thank you, >>>>>> Jeff >>>>>> >>>>>> _______________________________________________ >>>>>> Nfd-dev mailing list >>>>>> Nfd-dev at lists.cs.ucla.edu >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>>> _______________________________________________ >>>> Nfd-dev mailing list >>>> Nfd-dev at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> >>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Mon Mar 30 18:03:25 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Tue, 31 Mar 2015 01:03:25 +0000 Subject: [Nfd-dev] Handling new content in app for pending interest in NFD In-Reply-To: <6cae5fe4-c081-44da-ad7c-17b311ca2ccc@parc.com> References: <2A4FD9AB-D7D0-41A0-95F3-D323DFACFC0D@wustl.edu> <5B579956-A6A1-4992-A259-E989C29E20C7@cisco.com> <8502CDD5-59EB-4E87-A022-F0DDC14DC1AE@parc.com> <38eaa314-f5bf-40e5-8773-305fa2633fc3@parc.com> <6cae5fe4-c081-44da-ad7c-17b311ca2ccc@parc.com> Message-ID: On Mon, Mar 30, 2015 at 5:06 PM wrote: > I'm going to guess that caching data rules will be the same as > forwarding rules. If the interface is not allowed to produce that content > (due to routing / fib entries, local naming policy) data should not be > forwarded OR cached. > Caching rules could be simpler because the data is considered cachable only after it passes PIT matching. During PIT matching you can do all sorts of checking, including the check that the data indeed comes from one of the faces where the Interest was forwarded to. After that, the data can be inserted into cache table if cache management policy allows. If there is no PIT for the data, it really should be dropped in the first place. Wentao > > NDN has a slightly more complicated problem with caching than CCN given > then LPM matching rules. > > If you have a repo that has permission to serve this content then you > changed the problem. Now you need the repo protocol to give you trust. > > For regular forwarding you are relying on trusting routing. For local > apps you will rely (I assume) on local permissions. For repo you will need > both of those plus now a repo permission protocol. > > Dropping unsolicited data may end up being your only recourse. > > There are obviously other approaches for pre-populating caches that > involve higher level protocols, but I assume that's not what you're talking > about. > > Nacho (Ignacio) Solis > Principal Scientist > Palo Alto Research Center > > *From:* Wentao Shang > *Sent:* Mar 30, 2015 4:50 PM > *To:* "Solis, Ignacio " ;Mosko, > Marc > > *Cc:* nfd-dev at lists.cs.ucla.edu > *Subject:* Re: [Nfd-dev] Handling new content in app for pending interest > in NFD > > Hi Nacho, > > I don't have any argument against this rule right now. But it seems more > relevant to "forwarding" data packets, while the problem we were discussing > is about "caching" unsolicited data packets, which cannot be forwarded > anyway because there is no PIT. The simplest solution I would suggest to > the problem is to drop any unsolicited data in the forwarder. > > Wentao > > On Mon, Mar 30, 2015 at 3:42 PM wrote: > >> This rule is important, router or not. You can't have "non-priviledged" >> applications generating replies at servers. Specially important at systems >> with multiple users, tenants, virtual systems. >> >> At the local router there are even more restrictions. We haven't even >> gotten to talking about privileged names and restrictions and end-h out >> behavior. We have a design for this for CCN that we'll be talking about >> at CCNxCon. >> >> Nacho (Ignacio) Solis >> Principal Scientist >> Palo Alto Research Center >> >> *From:* Wentao Shang >> *Sent:* Mar 30, 2015 1:07 PM >> *To:* Mosko, Marc >> >> *Cc:* nfd-dev at lists.cs.ucla.edu >> *Subject:* Re: [Nfd-dev] Handling new content in app for pending >> interest in NFD >> >> On Mon, Mar 30, 2015 at 12:52 PM wrote: >> >>> I?ll add that in addition to the content having a PIT entry, Nacho Solis >>> has suggested that a router should verify that a Content Object came in a >>> face from which it was requested. Otherwise, there?s a potential for >>> off-path attacks sending content objects that match popular well-known >>> names. A variation on that, rather than tracking forward paths, would be >>> to at minimum verify that a content object comes from a face for which >>> there?s a corresponding FIB entry for the name. >>> >> >> This requirement makes sense for transit routers that receive packets >> from other routers. But I'm not sure whether this is necessary for >> forwarding daemons handling local applications... The pushed data should >> never get out of the local forwarder unless there is a PIT entry specifying >> a path pointing to some other router. >> >> Wentao >> >> >>> >>> Marc >>> >>> On Mar 30, 2015, at 12:08 PM, Wentao Shang >>> wrote: >>> >>> I agree with Dave. >>> >>> In principle, router should not cache unsolicited data. In the >>> situation we are discussing, the application should either just push the >>> data out, which may be dropped by NFD if the interest has expired, or store >>> the data in some application-level cache (or repo) for future fetching. >>> >>> Wentao >>> >>> On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) >>> wrote: >>> >>>> Isn?t this what the repo was invented for? >>>> >>>> Holding packets in a router that has forgotten that they were asked for >>>> is a giant invitation to cache pollution/poisoning attacks. >>>> >>>> > On Mar 30, 2015, at 2:24 PM, Haowei Yuan wrote: >>>> > >>>> > I think as long as the data has actually been requested by an Interest >>>> > packet, it is safe to send the Data packet to NFD. The NFD will either >>>> > forward or drop the Data packet by checking if the Interest has >>>> > expired. >>>> > >>>> > If the Interest has expired, Data packet is dropped, and the consumer >>>> > is still interested in the data, the consumer could resend the >>>> > Interest. Hopefully this time, the Data packet can be generated and >>>> > sent faster by the application so that NFD will forward it. >>>> > >>>> > Haowei >>>> > >>>> > >>>> > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam >>>> wrote: >>>> >> >>>> >> On Mar 30, 2015 11:08 AM, "Dehart, John" wrote: >>>> >>> >>>> >>> >>>> >>> Is there any harm in it pushing the data out without knowing for >>>> sure if >>>> >>> the >>>> >>> Interest is still active? >>>> >>> >>>> >> If data is so critical, can the Interest be refreshed proactively >>>> before it >>>> >> expires? >>>> >> >>>> >> /anil >>>> >> >>>> >>> John >>>> >>> >>>> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff < >>>> jburke at remap.ucla.edu> >>>> >>>>> wrote: >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Hi folks, >>>> >>>>>> >>>> >>>>>> We are facing this scenario in a few applications: >>>> >>>>>> >>>> >>>>>> 1) Interest received by NFD, passed to an application >>>> >>>>>> 2) Application not able to respond to interest, so interest >>>> stays in >>>> >>>>>> NFD PIT >>>> >>>>>> 3) Some time passes, but not enough for the Interest to expire >>>> >>>>>> 4) Application generates data (e.g., from a sensor reading) that >>>> would >>>> >>>>>> answer the Interest in the NFD PIT >>>> >>>>>> >>>> >>>>>> Question: How does app know to inform NFD it has the data after >>>> step 4, >>>> >>>>>> and how should it do that? >>>> >>>>>> >>>> >>>>>> - In this type of app, should it push the data unsolicited to >>>> the NFD >>>> >>>>>> and let it decide if there is something to do? >>>> >>>>> >>>> >>>>> >>>> >>>>> In my opinion, as long as the application is certain that the >>>> Interest >>>> >>>>> has arrived and is stored in NFD's PIT, it can just push the data >>>> out to >>>> >>>>> NFD. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> How certain does it have to be? There is a chance it could have >>>> >>>> expired... >>>> >>>> jeff >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> Wentao >>>> >>>>> >>>> >>>>>> >>>> >>>>>> - Is it recommended to implement an application-level PIT so the >>>> app is >>>> >>>>>> sure this data is solicited? (Why add another PIT?) >>>> >>>>>> >>>> >>>>>> Thank you, >>>> >>>>>> Jeff >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> Nfd-dev mailing list >>>> >>>>>> Nfd-dev at lists.cs.ucla.edu >>>> >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> Nfd-dev mailing list >>>> >>>> Nfd-dev at lists.cs.ucla.edu >>>> >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> Nfd-dev mailing list >>>> >>> Nfd-dev at lists.cs.ucla.edu >>>> >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>> >>>> > _______________________________________________ >>>> > Nfd-dev mailing list >>>> > Nfd-dev at lists.cs.ucla.edu >>>> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>>> >>>> _______________________________________________ >>>> Nfd-dev mailing list >>>> Nfd-dev at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>>> >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at UCLA.EDU Tue Mar 31 11:31:38 2015 From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev) Date: Tue, 31 Mar 2015 11:31:38 -0700 Subject: [Nfd-dev] Jenkins-CI outage Message-ID: <83B822B7-68ED-4162-8758-0869B56C01E0@ucla.edu> Please note that our Jenkins-CI is currently not working. We are aware of the issue and will try to put it back in business asap. --- Alex -------------- 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 enewberry at email.arizona.edu Tue Mar 31 15:06:28 2015 From: enewberry at email.arizona.edu (Eric Newberry) Date: Tue, 31 Mar 2015 15:06:28 -0700 Subject: [Nfd-dev] Jenkins-CI outage In-Reply-To: <83B822B7-68ED-4162-8758-0869B56C01E0@ucla.edu> References: <83B822B7-68ED-4162-8758-0869B56C01E0@ucla.edu> Message-ID: <551B1A64.70905@email.arizona.edu> Jenkins-CI is now back online. Apologies for any inconvenience caused. Eric Newberry Computer Science Undergraduate The University of Arizona On 3/31/2015 11:31 AM, Alex Afanasyev wrote: > Please note that our Jenkins-CI is currently not working. We are aware of the issue and will try to put it back in business asap. > > --- > Alex > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Mar 31 18:44:24 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 31 Mar 2015 18:44:24 -0700 Subject: [Nfd-dev] Techniques for prioritizing audio in NdnCon In-Reply-To: References: Message-ID: Hi Jeff I have read the paper "Self-prioritization of audio and video traffic". The paper aims at prioritizing audio/video traffic over download traffic on the user access link. It detects audio/video streams by looking at their traffic characteristics (constant send rate), and sends those packets before others. Mainly, it is a congestion control problem. Prioritizing audio over video, or prioritizing base layers over enhancement layers, is a different problem from above. It's hard for network to determine whether a packet is audio / base layer, without being told so. I think it's not too bad to peek the Name in an application specific strategy (#2000 would give us composable strategy which could be customized for every application namespace). The strategy for these applications can then prioritize audio / base layer packets when there's a congestion. Yours, Junxiao On Mar 28, 2015 10:06 PM, "Burke, Jeff" wrote: > > Hi Junxiao, > > I will do some digging, but this is interesting: > > Bonald, Thomas, Luca Muscariello, and Norberto Ostallo. "Self-prioritization of audio and video traffic." Communications (ICC), 2011 IEEE International Conference on. IEEE, 2011. > http://perso.telecom-paristech.fr/~bonald/Publications_files/BMO2011.pdf > (Instead of identifying packets as part of a "flow", one would use namespace or priority flag hints.) > > There are follow up papers to this one, too. Interesting to note that Muscariello (and a later co-author, Carofiglio) are now doing ICN research. > > (There are RTCP receiver reports in RTP streaming, too. ) > > Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: