From lanwang at memphis.edu Wed Jun 1 06:44:29 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Wed, 1 Jun 2016 13:44:29 +0000 Subject: [Ndn-interest] NLSR in NDNsim In-Reply-To: References:

Message-ID: <2579D02C-406F-4A61-BF46-7282894D46D5@memphis.edu> I?m cc?ing Anil in case he?s not on the ndn-interest list. Lan On Jun 1, 2016, at 1:00 AM, Tanusree Chatterjee > wrote: Okay. What is the latest update about that? On Jun 1, 2016 6:40 AM, "Lan Wang (lanwang)" > wrote: Sabet and Tanusree, Yes, we are still waiting for Anil to release the ndnSIM port of NLSR. Lan On May 31, 2016, at 11:31 AM, Muhammad Hosain Abdollahi Sabet > wrote: Well, that is not that simple. As far as I know Anil was porting NLSR to ndnSIM. I dont know what is the last status. Thanks, Sabet On 30 May 2016 21:30, "Tanusree Chatterjee" > wrote: Hello, How can I run NLSR through NDNsim? I have successfully installed the simulator (version 2.1) in ubuntu 14.04 and downloaded the NLSR codes from github from the following link. https://github.com/named-data/NLSR. I have downloaded ndn-cxx and nfd while installing the NDNsim. So, do I need to download it again? Then I need to build the nfd and ndn-cxx? How can I build them? I hope to get help in this regard very soon. -- Regards, Tanusree Chatterjee _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cedric.Westphal at huawei.com Tue Jun 7 16:08:46 2016 From: Cedric.Westphal at huawei.com (Cedric Westphal) Date: Tue, 7 Jun 2016 23:08:46 +0000 Subject: [Ndn-interest] ACM Information Centric Networking (ICN) 2016 @ Kyoto: CALL FOR Posters, Demos and Tutorials (Deadline: July 8, 2016) Message-ID: <369480A01F73974DAC423D05A977B4F21D37C879@SJCEML701-CHM.china.huawei.com> ACM Information Centric Networking (ICN) 2016 CALL FOR POSTERS, DEMOS and Tutorials http://conferences2.sigcomm.org/acm-icn/2016 CALL FOR POSTERS, DEMOS, and DATASETS The ICN poster and demo sessions are intended to showcase works-in-progress. Topics of interest are the same as those listed in the main track CFP. We strongly encourage both student and industry submissions. Both demos and posters should be accompanied by a 2 page extended abstract, which will be published in the conference proceedings. Abstract for posters, demos and datasets can be submitted via the ICN 2016 submission website. Preparation of Posters You are not required to submit the poster initially. Instead, you should submit a 2 page extended abstract. If the abstract is accepted, you will then be asked to prepare the poster. The abstract should clearly state: (a) the problem being addressed, (b) what makes this problem interesting, (c) your approach, and (d) the key contribution. Acceptance is based on a peer review process of all abstracts. A poster should be of size 32 inches x 42 inches (this is between A0 and A1) in portrait mode. It should be visually appealing, portraying ideas primarily via diagrams rather than text. The poster will be displayed on easels. The organizers will supply the foam backing and a method to mount the posters to the foam backing In particular, we call for posters that include accompanying datasets shared with the community. The aim is to collect and share datasets that can hopefully become a common ground for evaluation in the ICN community. Such posters will be eligible for a "best dataset award". Preparation of Demos You are required to submit a 2 page extended abstract, which describes the demo. The extended abstract should clearly state: (a) the problem being addressed and why it is important, (b) the approach taken and the design of the demo, (c) the key contribution and (d) any special technical requirements. If accepted, it is strongly recommended that a poster supporting the demo is produced. Acceptance is based on a peer review process of all abstracts. A "best demo award" will be given this year, based on community judging by registered participants A demo should be self contained and ideally interactive. Accepted demos will be given a table (6 feet by 30 inches), a power supply (100V TypeA) and WiFi Internet access(NAT only) by default. Details regarding poster preparation are described above. Important Poster and Demo Dates Poster and Demo Submission Deadline: July 8, 2016 Notification of Acceptance: July 29, 2016 Camera Ready Due: August 15, 2016 Conference: September 26-28, 2016 -------------------------------------------------- CALL FOR TUTORIALS Following last year's successful tutorials, ACM ICN 2016 solicits proposals for half- or full-day tutorials on topics relevant to the ICN research that can help the audience gain further understanding of this new and exciting area. In particular, we seek tutorials on intermediate and advanced topics of critical importance to the maturing ICN field (such as, but not limited to, applied cryptography, or technological advances for ICN, or application of ICN to specific fields such as IoT), offered through collaboration between ICN researchers and experts in other domains. Tutorials may be lectures, hands-on training, or any combination of the above. Exploring diverse ways of interacting with the audience is welcome, as are cross-disciplinary topics. Tutorial proposals should be submitted in PDF format, not exceeding three (3) pages in total, and be sent to the workshop/tutorial chairs. Each proposal must include: - A motivation for the tutorial (why this, why at ICN 2016?) - Detailed biographies of the trainers. - An outline of the tutorial content. - The type of tutorial (e.g., lecture vs. hands-on) - References to previous iterations of the tutorial (if applicable) including their date, venue, topics and number of participants and the motivation for the new proposal. - Requirements for the tutorial room. - Requirements for the attendants (e.g., must bring own laptop, familiarity with certain technologies or topics, etc.). - Any limitations (e.g., number of participants). Important tutorial dates Tutorial Proposal Submission Deadline: July 8, 2016 Notification of Acceptance: July 15, 2016 Conference: September 26-28, 2016 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Wed Jun 8 10:44:40 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Wed, 8 Jun 2016 10:44:40 -0700 Subject: [Ndn-interest] [CFP] 1st IEEE Workshop on Named Data Networking for Challenged Communication Environments (NDN-CCE'2016) Message-ID: <506C0A1C-A595-4449-9B05-B9054E074F2D@cs.ucla.edu> ========================================================= CALL FOR PAPERS 1st IEEE Workshop on Named Data Networking for Challenged Communication Environments (NDN-CCE'2016) Washington, DC, December 8th 2016 http://www2.mitre.org/public/ndn-cce/ ========================================================= Army tactical networks, first responder communication networks, and interplanetary networks are several examples of challenging communication environments that are typically referred to as DIL (disrupted, intermittently connected, and low bandwidth). Nevertheless, applications that operate in such environments generate mission critical data that must be disseminated promptly and reliably, despite the challenging nature of the communication environment. Many years of research efforts have been invested into IP-based communication networks to achieve the above goals, but only resulted in limited success. The root cause of the difficulties is a fundamental mismatch between the IP-based communication model and the challenged environments. The former assumes communications through established stable infrastructures. It requires the creation and maintenance of end-to-end connectivity between senders and receivers, while neither the infrastructure nor end-to-end connectivity exists in the latter. The key to solving the problem is to identify a new communication model that makes effective use of the heterogeneous network resources of challenged environments, removes dependency on infrastructure components, and emphasizes data dissemination in lieu end-to-end connectivity. Information-Centric Networking (ICN) and Named Data Networking (NDN), as the most prominent realization of the ICN vision, have emerged in recent years as promising directions to address the above stated challenges. By its name, this new networking model focuses on information (named data) retrieval, instead of reachability between nodes and locations. Therefore, it can circumvent the lack of persistent connectivity in challenged environments by focusing on moving data instead of end-to-end connectivity, utilizing any connectivity, as it comes into existence, to move data hop-by-hop towards requesting parties. This workshop aims to provide a timely venue for all interested parties to exchange their ideas and initial results in applying the NDN paradigm to: address the communication needs of mission critical applications in challenged environments, explore different design options, and identify design tradeoffs. Topics of interest includes: - NDN routing for challenged communication environments Supporting - high assurance NDN applications in challenged communication - environments Real deployment and case studies of NDN in challenged - communication environments QoS-aware NDN functionalities for - challenged communication environments Efficient and effective NDN - caching policies for challenged communication environments Modeling, - analysis and characterization of NDN functionalities in challenged - communication network ========================================================= IMPORTANT DATES Submission Deadline: July 1, 2016, 11:59pm Acceptance Notification: September 1, 2016 Camera-Ready Submission: October 1, 2016 ========================================================= Sincerely, Tamer Refaei (The MITRE Corporation) and Alex Afanasyev (UCLA) NDN-CCE Workshop Co-Chairs -------------- 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 Navdeep.Uniyal at neclab.eu Thu Jun 9 08:20:36 2016 From: Navdeep.Uniyal at neclab.eu (Navdeep Uniyal) Date: Thu, 9 Jun 2016 15:20:36 +0000 Subject: [Ndn-interest] Video tool for NDN Message-ID: <15421E67B274CD4AB5F6AEA46A684C3708AC9C6A@PALLENE.office.hd> Hi all, Is there any tool to generate and play video over NDN in order to experiment the forwarding strategies. Please help if there is any available. Best Regards, Navdeep Uniyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Jun 9 10:32:31 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 9 Jun 2016 10:32:31 -0700 Subject: [Ndn-interest] Video tool for NDN In-Reply-To: <15421E67B274CD4AB5F6AEA46A684C3708AC9C6A@PALLENE.office.hd> References: <15421E67B274CD4AB5F6AEA46A684C3708AC9C6A@PALLENE.office.hd> Message-ID: Hi Navdeep Search for ndn-rtc library, and NdnCon application. Both are OSX only, unfortunately. Yours, Junxiao On Jun 9, 2016 8:21 AM, "Navdeep Uniyal" wrote: > Hi all, > > > > Is there any tool to generate and play video over NDN in order to > experiment the forwarding strategies. Please help if there is any available. > > > > > > Best Regards, > > Navdeep Uniyal > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shishanshan at cstnet.cn Mon Jun 20 23:02:39 2016 From: shishanshan at cstnet.cn (=?GBK?B?yq/Juuap?=) Date: Tue, 21 Jun 2016 14:02:39 +0800 (GMT+08:00) Subject: [Ndn-interest] question about NFD Message-ID: <16a1652.15af1.155718db355.Coremail.shishanshan@cstnet.cn> hi, I have some questions when use NFD, and I want to test the function of file transfer but I am not sure of the below questions: 1> If I want to test the file transfer function between two end points , what tools or app should I use ? ChronoChat, ChronoSync or NDNFS? 2> I am not sure whether ChronoChat can transfer file or not. I tried to install it but there are something wrong with it and failed. Look forward to your reply and thank you so much. Best wishes shanshan -------------- next part -------------- An HTML attachment was scrubbed... URL: From weiweiliu at email.arizona.edu Tue Jun 21 16:10:43 2016 From: weiweiliu at email.arizona.edu (Weiwei Liu) Date: Tue, 21 Jun 2016 16:10:43 -0700 Subject: [Ndn-interest] question about NFD In-Reply-To: <125CF881-BBA4-44EC-8864-D01743BCE752@cs.arizona.edu> References: <16a1652.15af1.155718db355.Coremail.shishanshan@cstnet.cn> <125CF881-BBA4-44EC-8864-D01743BCE752@cs.arizona.edu> Message-ID: Hi Shanshan, ndncatchunks and ndnputchunks are a pair of programs for file transfer. Please install ndn-tools first : https://github.com/named-data/ndn-tools/blob/master/INSTALL.md, and then follow the instructions in the following link to publish and retrieve data: https://github.com/named-data/ndn-tools/tree/master/tools/chunks. By the way, I'm working on adding AIMD window adaptation to chunks and I will release it soon. Let me know if you have any further questions. Thanks, Weiwei On Tue, Jun 21, 2016 at 3:15 PM, Beichuan Zhang wrote: > Use ndnchunks. > > Weiwei, can you reply Shanshan and the ndn-interest list with the > ndnchunks link? Also say that you?re working to add AIMD window adaptation > to it and will release it soon. > > Beichuan > > On Jun 21, 2016, at 2:02 PM, ??? wrote: > > hi, > > I have some questions when use NFD, and I want to test the function of > file transfer but I am not sure of the below questions: > > 1> If I want to test the file transfer function between two end points , > what tools or app should I use ? ChronoChat > , ChronoSync > or NDNFS > ? > 2> I am not sure whether ChronoChat > can transfer file or not. I > tried to install it but there are something wrong with it and failed. > > Look forward to your reply and thank you so much. > > > Best wishes > shanshan > > > > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhasabet at gmail.com Sat Jun 25 00:14:27 2016 From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet) Date: Sat, 25 Jun 2016 11:44:27 +0430 Subject: [Ndn-interest] Modifiable components in Interests In-Reply-To: References:

Message-ID: Hello everyone, In SNAMP paper section 3.C there is a reference to an ongoing discussion regarding whether Interest could carry modifiable components, and if positive, where to do modification. At that time it was about SelectedDelegation field in Interest tlv format. I just want to know the status of the discussion and arguments in agreement/disagreement. As far as I can say just in the moment, one argument in disagreement could be opening up the surface to mislead interests. P.S: For everybody's information, the mentioned filed was introduced because delegation list (a list of forwarding hints) in LINK object may contain more than one hints. Considering calculation overhead, it may be better to have this field filled, so that each router in DFZ does not need to decide which one of hints to choose for forwarding. Since choosing which hint as selected one, needs information about topology, traffic links and etc, an end application seems not to able to decide on this matter. Thanks, Sabet -------------- next part -------------- An HTML attachment was scrubbed... URL: From tnsr.chatterjee at gmail.com Sat Jun 25 04:36:38 2016 From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee) Date: Sat, 25 Jun 2016 17:06:38 +0530 Subject: [Ndn-interest] LSDB in NLSR Message-ID: Hi all, Previously, in NLSR we can see that Sync computes a hash tree over all the data in a slice (of LSDB) that exchange the root hash between neighbors to detect inconsistencies. If the hash value do not agree, then two neighboring nodes exchange the hash value of nodes on the next tree level until they detect the specific leaf nodes (data) causing the problems. While NLSR using chronosync every party keeps an outstanding sync interest with the current state digest.As soon as some party generates new data, the state digest changes, and the outstanding interest gets satisfied. ChronoSync module on her machine immediately noticesits state digest is newer and hence proceeds to satisfy the sync interest with sync data that contains the name of LSA. Whoever receives the sync data updates the digest tree to reflect the new change to the dataset state, and sends out a new sync interest with the updated state digest, reverting the system to a stable state. So, using chronosync, it reduces too much message exchanges than the previous sync protocol? While there is a change in the digest, the outstanding interest is satisfied by the LSA name itself which causes the change? It is in form of a ndn data packet thus preserving the integrity as well? What changes it has now in security while disseminating LSAs? -- Regards, Tanusree Chatterjee -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Jun 27 13:15:48 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 27 Jun 2016 13:15:48 -0700 Subject: [Ndn-interest] Modifiable components in Interests In-Reply-To: References:

Message-ID: <57718973.c66b620a.f9fdb.381b@mx.google.com> Hi Sabet SelectedDelegation is not the first modifiable field in an Interest. InterestLifetime can be modified by a forwarder. Nodes that forward Interests may decrease the lifetime to account for the time spent in the node before forwarding, but are not required to do so. http://named-data.net/doc/ndn-tlv/interest.html#interestlifetime Yours, Junxiao From: Muhammad Hosain Abdollahi Sabet -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhasabet at gmail.com Mon Jun 27 14:18:39 2016 From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet) Date: Tue, 28 Jun 2016 01:48:39 +0430 Subject: [Ndn-interest] Modifiable components in Interests In-Reply-To: <57718973.c66b620a.f9fdb.381b@mx.google.com> References:

<57718973.c66b620a.f9fdb.381b@mx.google.com> Message-ID: Junxiao, Thanks. In the paper I've referred to, there is a mention of doing modification below network (NDN) layer. Is that it? I mean lifetime is also modifiable in adaption layer? Thanks, Sabet On 28 Jun 2016 12:45 am, "Junxiao Shi" wrote: > Hi Sabet > > > > SelectedDelegation is not the first modifiable field in an Interest. > > > > InterestLifetime can be modified by a forwarder. > > Nodes that forward Interests may decrease the lifetime to account for the > time spent in the node before forwarding, but are not required to do so. > > http://named-data.net/doc/ndn-tlv/interest.html#interestlifetime > > > > Yours, Junxiao > > > > *From: *Muhammad Hosain Abdollahi Sabet > *Sent: *Saturday, June 25, 2016 00:15 > *To: *ndn-interest at lists.cs.ucla.edu > *Cc: *yic at cs.arizona.edu; Alex Afanasyev > *Subject: *[Ndn-interest] Modifiable components in Interests > > > > Hello everyone, > > In SNAMP paper section 3.C there is a reference to an ongoing discussion > regarding whether Interest could carry modifiable components, and if > positive, where to do modification. At that time it was about > SelectedDelegation field in Interest tlv format. I just want to know the > status of the discussion and arguments in agreement/disagreement. As far as > I can say just in the moment, one argument in disagreement could be opening > up the surface to mislead interests. > > P.S: For everybody's information, the mentioned filed was introduced > because delegation list (a list of forwarding hints) in LINK object may > contain more than one hints. Considering calculation overhead, it may be > better to have this field filled, so that each router in DFZ does not need > to decide which one of hints to choose for forwarding. Since choosing which > hint as selected one, needs information about topology, traffic links and > etc, an end application seems not to able to decide on this matter. > > Thanks, > Sabet > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nano at remap.ucla.edu Mon Jun 27 17:30:07 2016 From: nano at remap.ucla.edu (Alex Horn) Date: Mon, 27 Jun 2016 19:30:07 -0500 Subject: [Ndn-interest] netflix prefix registration Message-ID: interesting to see how Netflix's Eureka (akin to Zookeeper or Consul) handles something like NDN's prefix registration. see Interest subscription model Interests.forSome( Interests.forApplications(Operator.Like, "eureka.*"), Interests.forApplications(Operator.Equals, "atlas") ); -------------- next part -------------- An HTML attachment was scrubbed... URL: From tnsr.chatterjee at gmail.com Tue Jun 28 01:47:08 2016 From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee) Date: Tue, 28 Jun 2016 14:17:08 +0530 Subject: [Ndn-interest] NACK Message-ID: If a data packet is modified and detected during verification, can forwarder send a NACK. How the data can be resend in this case? If consumer is not satisfied it has to send the same interest again, is there any other way out to get the data which may not been correctly received due to some modification. -- Regards, Tanusree Chatterjee -------------- next part -------------- An HTML attachment was scrubbed... URL: From gts at ics.uci.edu Tue Jun 28 02:20:03 2016 From: gts at ics.uci.edu (GTS) Date: Tue, 28 Jun 2016 02:20:03 -0700 Subject: [Ndn-interest] NACK In-Reply-To: References: Message-ID: <57724143.6020509@ics.uci.edu> One can choose to require a router to generate a NACK in this case. However, if this is a communication/transmission error, it's best for the consumer to timeout and resend the interest. Otherwise, it could be due to: (1) an implementation bug at either router or consumer -- probably best left alone, or (2) an attack -- adversary feeds incorrect content to router. If this is an on-path adversary (e.g., a subverted/malicious upstream router), sending a NACK is useless. A router that detects the error is better off trying another route. Another issue is how to secure the NACK itself. If not secured, this kind of NACK can be used as a DoS attack (anyone can generate it). If secured (e.g., signed), the originating router would incur some non-negligible computational burden. Cheers, Gene p.s. FYI, for a discussion of some NACK-related issues in ICN, take a look at: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7288477 or http://arxiv.org/pdf/1503.02123.pdf ====================== Gene Tsudik Chancellor's Professor of Computer Science University of California, Irvine On 6/28/16 1:47 AM, Tanusree Chatterjee wrote: > If a data packet is modified and detected during verification, can > forwarder send a NACK. How the data can be resend in this case? If > consumer is not satisfied it has to send the same interest again, is > there any other way out to get the data which may not been correctly > received due to some modification.? > > -- Regards, > Tanusree Chatterjee > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Jun 28 08:49:18 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 28 Jun 2016 08:49:18 -0700 Subject: [Ndn-interest] NACK In-Reply-To: References: Message-ID: <4845F6D2-1D3B-4563-A401-779F74EA0CD7@email.arizona.edu> Hi Tanusree What?s the reason for ?data packet is modified?? For a transmission error due to line noise, the lower layer is responsible for detecting such error and drop the packet. NDNLPv2 will attempt to repair the packet loss by retransmitting the packet. If there?s a malicious node on the path deliberately modifying the Data packet, NFD will not detect that because NFD neither has knowledge about the trust model, nor has the computation power to verify signatures. Consumer can re-express the Interest with an Exclude selector to exclude the bad Data, and hope the network can find a path to locate the good Data. Yours, Junxiao > On Jun 28, 2016, at 1:47 AM, Tanusree Chatterjee wrote: > > If a data packet is modified and detected during verification, can forwarder send a NACK. How the data can be resend in this case? If consumer is not satisfied it has to send the same interest again, is there any other way out to get the data which may not been correctly received due to some modification. > > -- Regards, > Tanusree Chatterjee From Marc.Mosko at parc.com Tue Jun 28 10:57:03 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Tue, 28 Jun 2016 17:57:03 +0000 Subject: [Ndn-interest] NACK In-Reply-To: <4845F6D2-1D3B-4563-A401-779F74EA0CD7@email.arizona.edu> References: <4845F6D2-1D3B-4563-A401-779F74EA0CD7@email.arizona.edu> Message-ID: <392C7E7A-C144-473A-BE0D-A94CA2A90A7F@parc.com> I disagree about the ?lower layer? statement. A fair number of errors do make their way past layer 2. While Ethernet with reasonable MTUs will have an ?age of the universe? error rate, bad cables, for example, can cause a higher error rate that will get past the CRC (due to 4 or more bit errors). Very large MTUs also have a non-linear effect on error rate, especially on very fast links because the scrambler can propagate single bit errors to multi-bit errors. There?s a ton of material on the IEEE web site on these effects (see the sections on MTU size for 1 Gbps + macs). Other PHYs will have different behavior too. Some compression schemes have a higher than normal error rate. There?s also a broad category of intermediate systems causing errors (bugs, hardware errors, etc.) [see ?When the CRC and TCP checksums Disagree?]. An intermediate system in NDN could verify validations, even though NFD does not. I think the OP was asking this sort of what if question, not asking about the implemented behavior. I agree with Gene?s position that one should not generate a NACK in this case. If the router has some strategy that allows it to re-transmit the Interest, I think that?s ok as it would either be a CS hit upstream if it was an honest error or be aggregated/retransmitted if not. But that needs to be rate limited, otherwise there is an amplification attack possible. Otherwise, I?d just increment a ?corrupted data packet? counter and drop it. Also, note that some Interests carry a signature. If the intermediate system is checking those too, then that might be a case where a NACK is warranted. If you?re spending all the cycles to check a signature, sending a NACK is a small incremental cost and that?s a 1:1 message transaction. Marc > On Jun 28, 2016, at 8:49 AM, Junxiao Shi wrote: > > Hi Tanusree > > What?s the reason for ?data packet is modified?? > For a transmission error due to line noise, the lower layer is responsible for detecting such error and drop the packet. NDNLPv2 will attempt to repair the packet loss by retransmitting the packet. > If there?s a malicious node on the path deliberately modifying the Data packet, NFD will not detect that because NFD neither has knowledge about the trust model, nor has the computation power to verify signatures. Consumer can re-express the Interest with an Exclude selector to exclude the bad Data, and hope the network can find a path to locate the good Data. > > Yours, Junxiao > >> On Jun 28, 2016, at 1:47 AM, Tanusree Chatterjee wrote: >> >> If a data packet is modified and detected during verification, can forwarder send a NACK. How the data can be resend in this case? If consumer is not satisfied it has to send the same interest again, is there any other way out to get the data which may not been correctly received due to some modification. >> >> -- Regards, >> Tanusree Chatterjee > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From aa at CS.UCLA.EDU Wed Jun 29 16:22:38 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Wed, 29 Jun 2016 16:22:38 -0700 Subject: [Ndn-interest] NACK In-Reply-To: <392C7E7A-C144-473A-BE0D-A94CA2A90A7F@parc.com> References: <4845F6D2-1D3B-4563-A401-779F74EA0CD7@email.arizona.edu> <392C7E7A-C144-473A-BE0D-A94CA2A90A7F@parc.com> Message-ID: There are cases when router can do some verification, including when router and client share the trust model or the interest carried the verification key and the router is willing to do crypto checks, or the interest carried full name, including the implicit digest of data. What to do when the previously sent interest retrieved a data packet that cannot satisfy the interest depends on the forwarding strategy. The strategy can try retrieve again, either using different interface and/or specifying the exclude filter. The strategy can also give up retrieving data and send network NACK (interest return) back downstream. The downstream router, receiving the NACK, can invoke its forwarding strategy actions and/or give up, sending its own NACK back. Note that this, potentially cascading, hop-by-hop network NACK mechanism does not create new security problems when links between routers are point-to-point. In multi-access cases, network NACKs indeed pose a problem and I'm not sure about a good way to handle this except timeout. --- Alex > On Jun 28, 2016, at 10:57 AM, Marc.Mosko at parc.com wrote: > > I disagree about the ?lower layer? statement. A fair number of errors do make their way past layer 2. While Ethernet with reasonable MTUs will have an ?age of the universe? error rate, bad cables, for example, can cause a higher error rate that will get past the CRC (due to 4 or more bit errors). Very large MTUs also have a non-linear effect on error rate, especially on very fast links because the scrambler can propagate single bit errors to multi-bit errors. There?s a ton of material on the IEEE web site on these effects (see the sections on MTU size for 1 Gbps + macs). Other PHYs will have different behavior too. Some compression schemes have a higher than normal error rate. There?s also a broad category of intermediate systems causing errors (bugs, hardware errors, etc.) [see ?When the CRC and TCP checksums Disagree?]. > > An intermediate system in NDN could verify validations, even though NFD does not. I think the OP was asking this sort of what if question, not asking about the implemented behavior. I agree with Gene?s position that one should not generate a NACK in this case. If the router has some strategy that allows it to re-transmit the Interest, I think that?s ok as it would either be a CS hit upstream if it was an honest error or be aggregated/retransmitted if not. But that needs to be rate limited, otherwise there is an amplification attack possible. Otherwise, I?d just increment a ?corrupted data packet? counter and drop it. > > Also, note that some Interests carry a signature. If the intermediate system is checking those too, then that might be a case where a NACK is warranted. If you?re spending all the cycles to check a signature, sending a NACK is a small incremental cost and that?s a 1:1 message transaction. > > Marc > >> On Jun 28, 2016, at 8:49 AM, Junxiao Shi wrote: >> >> Hi Tanusree >> >> What?s the reason for ?data packet is modified?? >> For a transmission error due to line noise, the lower layer is responsible for detecting such error and drop the packet. NDNLPv2 will attempt to repair the packet loss by retransmitting the packet. >> If there?s a malicious node on the path deliberately modifying the Data packet, NFD will not detect that because NFD neither has knowledge about the trust model, nor has the computation power to verify signatures. Consumer can re-express the Interest with an Exclude selector to exclude the bad Data, and hope the network can find a path to locate the good Data. >> >> Yours, Junxiao >> >>> On Jun 28, 2016, at 1:47 AM, Tanusree Chatterjee wrote: >>> >>> If a data packet is modified and detected during verification, can forwarder send a NACK. How the data can be resend in this case? If consumer is not satisfied it has to send the same interest again, is there any other way out to get the data which may not been correctly received due to some modification. >>> >>> -- Regards, >>> Tanusree Chatterjee >> >> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- 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 cghali at uci.edu Wed Jun 29 16:36:46 2016 From: cghali at uci.edu (Cesar Ghali) Date: Wed, 29 Jun 2016 16:36:46 -0700 Subject: [Ndn-interest] NACK In-Reply-To: References: <4845F6D2-1D3B-4563-A401-779F74EA0CD7@email.arizona.edu> <392C7E7A-C144-473A-BE0D-A94CA2A90A7F@parc.com> Message-ID: Both scenarios of content verification by routers that Alex mentioned are valid and are explained in more detail in this paper: http://dl.acm.org/citation.cfm?id=2677049 Cesar On Wednesday, June 29, 2016, Alex Afanasyev wrote: > There are cases when router can do some verification, including when > router and client share the trust model or the interest carried the > verification key and the router is willing to do crypto checks, or the > interest carried full name, including the implicit digest of data. > > What to do when the previously sent interest retrieved a data packet that > cannot satisfy the interest depends on the forwarding strategy. The > strategy can try retrieve again, either using different interface and/or > specifying the exclude filter. The strategy can also give up retrieving > data and send network NACK (interest return) back downstream. The > downstream router, receiving the NACK, can invoke its forwarding strategy > actions and/or give up, sending its own NACK back. > > Note that this, potentially cascading, hop-by-hop network NACK mechanism > does not create new security problems when links between routers are > point-to-point. In multi-access cases, network NACKs indeed pose a > problem and I'm not sure about a good way to handle this except timeout. > > --- > Alex > > > On Jun 28, 2016, at 10:57 AM, Marc.Mosko at parc.com wrote: > > > > I disagree about the ?lower layer? statement. A fair number of errors > do make their way past layer 2. While Ethernet with reasonable MTUs will > have an ?age of the universe? error rate, bad cables, for example, can > cause a higher error rate that will get past the CRC (due to 4 or more bit > errors). Very large MTUs also have a non-linear effect on error rate, > especially on very fast links because the scrambler can propagate single > bit errors to multi-bit errors. There?s a ton of material on the IEEE web > site on these effects (see the sections on MTU size for 1 Gbps + macs). > Other PHYs will have different behavior too. Some compression schemes > have a higher than normal error rate. There?s also a broad category of > intermediate systems causing errors (bugs, hardware errors, etc.) [see > ?When the CRC and TCP checksums Disagree?]. > > > > An intermediate system in NDN could verify validations, even though NFD > does not. I think the OP was asking this sort of what if question, not > asking about the implemented behavior. I agree with Gene?s position that > one should not generate a NACK in this case. If the router has some > strategy that allows it to re-transmit the Interest, I think that?s ok as > it would either be a CS hit upstream if it was an honest error or be > aggregated/retransmitted if not. But that needs to be rate limited, > otherwise there is an amplification attack possible. Otherwise, I?d just > increment a ?corrupted data packet? counter and drop it. > > > > Also, note that some Interests carry a signature. If the intermediate > system is checking those too, then that might be a case where a NACK is > warranted. If you?re spending all the cycles to check a signature, sending > a NACK is a small incremental cost and that?s a 1:1 message transaction. > > > > Marc > > > >> On Jun 28, 2016, at 8:49 AM, Junxiao Shi > wrote: > >> > >> Hi Tanusree > >> > >> What?s the reason for ?data packet is modified?? > >> For a transmission error due to line noise, the lower layer is > responsible for detecting such error and drop the packet. NDNLPv2 will > attempt to repair the packet loss by retransmitting the packet. > >> If there?s a malicious node on the path deliberately modifying the Data > packet, NFD will not detect that because NFD neither has knowledge about > the trust model, nor has the computation power to verify signatures. > Consumer can re-express the Interest with an Exclude selector to exclude > the bad Data, and hope the network can find a path to locate the good Data. > >> > >> Yours, Junxiao > >> > >>> On Jun 28, 2016, at 1:47 AM, Tanusree Chatterjee < > tnsr.chatterjee at gmail.com > wrote: > >>> > >>> If a data packet is modified and detected during verification, can > forwarder send a NACK. How the data can be resend in this case? If consumer > is not satisfied it has to send the same interest again, is there any other > way out to get the data which may not been correctly received due to some > modification. > >>> > >>> -- Regards, > >>> Tanusree Chatterjee > >> > >> > >> _______________________________________________ > >> Ndn-interest mailing list > >> Ndn-interest at lists.cs.ucla.edu > >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > > > > _______________________________________________ > > Ndn-interest mailing list > > Ndn-interest at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lixia at CS.UCLA.EDU Wed Jun 29 22:42:20 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Wed, 29 Jun 2016 22:42:20 -0700 Subject: [Ndn-interest] NACK In-Reply-To: References: Message-ID: <45FFA2D0-57BE-4F95-8BD0-718850F8C3A8@cs.ucla.edu> one detail that I have not seen mentioned so far: interest NACK versus data packet NACK. It seems to me that interest NACK is relatively well understood: a forwarding node failed to forward a received interest hence generates a NACK to its previous hop. data NACK seems to me not understood as fully: a) if a consumer gets a data packet that's not what it wants, it'd retry the interest in some way; b) any other forwarding node could drop an incorrect data packet, it can; whether it should generate a NACK on behalf of the consumer seems a separable question. > On Jun 28, 2016, at 1:47 AM, Tanusree Chatterjee wrote: > > If a data packet is modified and detected during verification, can forwarder send a NACK. How the data can be resend in this case? If consumer is not satisfied it has to send the same interest again, is there any other way out to get the data which may not been correctly received due to some modification. > > -- Regards, > Tanusree Chatterjee > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From cghali at uci.edu Thu Jun 30 14:29:50 2016 From: cghali at uci.edu (Cesar Ghali) Date: Thu, 30 Jun 2016 14:29:50 -0700 Subject: [Ndn-interest] NACK In-Reply-To: <45FFA2D0-57BE-4F95-8BD0-718850F8C3A8@cs.ucla.edu> References: <45FFA2D0-57BE-4F95-8BD0-718850F8C3A8@cs.ucla.edu> Message-ID: I just want to highlight that interest NACKs that Lixia mentioned are studied as two types of NACK messages in the paper that Gene shared earlier: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7288477 Cesar On Wednesday, June 29, 2016, Lixia Zhang wrote: > one detail that I have not seen mentioned so far: interest NACK versus > data packet NACK. > > It seems to me that interest NACK is relatively well understood: a > forwarding node failed to forward a received interest hence generates a > NACK to its previous hop. > data NACK seems to me not understood as fully: > a) if a consumer gets a data packet that's not what it wants, it'd retry > the interest in some way; > b) any other forwarding node could drop an incorrect data packet, it can; > whether it should generate a NACK on behalf of the consumer seems a > separable question. > > > > On Jun 28, 2016, at 1:47 AM, Tanusree Chatterjee < > tnsr.chatterjee at gmail.com > wrote: > > > > If a data packet is modified and detected during verification, can > forwarder send a NACK. How the data can be resend in this case? If consumer > is not satisfied it has to send the same interest again, is there any other > way out to get the data which may not been correctly received due to some > modification. > > > > -- Regards, > > Tanusree Chatterjee > > > > _______________________________________________ > > Ndn-interest mailing list > > Ndn-interest at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Thu Jun 30 19:10:43 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Thu, 30 Jun 2016 19:10:43 -0700 Subject: [Ndn-interest] [CFP] 1st IEEE Workshop on Named Data Networking for Challenged Communication Environments (NDN-CCE'2016) Message-ID: ** Deadline extended until July 15, 2016 ** ========================================================= CALL FOR PAPERS 1st IEEE Workshop on Named Data Networking for Challenged Communication Environments (NDN-CCE'2016) Washington, DC, December 8th 2016 http://www2.mitre.org/public/ndn-cce/ ========================================================= Army tactical networks, first responder communication networks, and interplanetary networks are several examples of challenging communication environments that are typically referred to as DIL (disrupted, intermittently connected, and low bandwidth). Nevertheless, applications that operate in such environments generate mission critical data that must be disseminated promptly and reliably, despite the challenging nature of the communication environment. Many years of research efforts have been invested into IP-based communication networks to achieve the above goals, but only resulted in limited success. The root cause of the difficulties is a fundamental mismatch between the IP-based communication model and the challenged environments. The former assumes communications through established stable infrastructures. It requires the creation and maintenance of end-to-end connectivity between senders and receivers, while neither the infrastructure nor end-to-end connectivity exists in the latter. The key to solving the problem is to identify a new communication model that makes effective use of the heterogeneous network resources of challenged environments, removes dependency on infrastructure components, and emphasizes data dissemination in lieu end-to-end connectivity. Information-Centric Networking (ICN) and Named Data Networking (NDN), as the most prominent realization of the ICN vision, have emerged in recent years as promising directions to address the above stated challenges. By its name, this new networking model focuses on information (named data) retrieval, instead of reachability between nodes and locations. Therefore, it can circumvent the lack of persistent connectivity in challenged environments by focusing on moving data instead of end-to-end connectivity, utilizing any connectivity, as it comes into existence, to move data hop-by-hop towards requesting parties. This workshop aims to provide a timely venue for all interested parties to exchange their ideas and initial results in applying the NDN paradigm to: address the communication needs of mission critical applications in challenged environments, explore different design options, and identify design tradeoffs. Topics of interest includes: - NDN routing for challenged communication environments Supporting - high assurance NDN applications in challenged communication - environments Real deployment and case studies of NDN in challenged - communication environments QoS-aware NDN functionalities for - challenged communication environments Efficient and effective NDN - caching policies for challenged communication environments Modeling, - analysis and characterization of NDN functionalities in challenged - communication network ========================================================= IMPORTANT DATES Submission Deadline: July 15, 2016, 11:59pm EDT (extended) Acceptance Notification: September 1, 2016 Camera-Ready Submission: October 1, 2016 ========================================================= Sincerely, Tamer Refaei (The MITRE Corporation) and Alex Afanasyev (UCLA) NDN-CCE Workshop Co-Chairs -------------- 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: