From josh at caida.org Fri Jul 1 16:13:01 2016 From: josh at caida.org (Josh Polterock) Date: Fri, 1 Jul 2016 16:13:01 -0700 Subject: [Ndn-interest] Named Data Networking (NDN) Project Monthly Newsletter for May-June 2016 Message-ID: <20160701231301.GB889@caida.org> Named Data Networking (NDN) Project Newsletter for May-June 2016 The NDN project team compiles and publishes this newsletter monthly to inform the community about recent activities, technical news, meetings, publications, presentations, code releases, and upcoming events. You can find these newsletters posted on the Named Data Networking Project blog. COMMUNITY OUTREACH * On May 31-June 1, 2016, NIST hosted a two-day workshop on Named Data Networking on their campus in Gaithersburg, MD. Day 1 theme focused on the Internet of Things, Day 2 theme covered Big Data and Big Media. Please find the agenda and links to the web cast below. Agenda: http://www.nist.gov/itl/antd/named-data-networking.cfm. Web cast: http://www.nist.gov/itl/antd/named-data-networking-webcast.cfm TECHNICAL NEWS * We released new NDN client libraries: - NDN JavaScript library NDN-JS v0.11.0 https://github.com/named-data/ndn-js/releases/tag/v0.11.0 - NDN C++ library NDN-CPP v0.10 https://github.com/named-data/ndn-cpp/releases/tag/v0.10 - NDN Python library PyNDN version v2.3beta1 https://github.com/named-data/PyNDN2/releases/tag/v2.3beta1 - NDN Client Library for Java v0.12 https://github.com/named-data/jndn/releases/tag/v0.12 These libraries now include support for setting a Link object and selected delegation in the Interest. In also includes support for NDNLPv2. * NDN-VIZ: An Interactive Visualization Tool for NDN Traffic We released an early version of NDN-VIZ, an interactive visualization tool for NDN traffic, aiming to help NDN researchers and developers to easily analyze their tests. NDN-VIZ uses D3 to build visualization based on log files (ndndump & topology). The current version contains only two visualization channels, topology and name tree. We plan to add a timeline and allow selection of specific time periods. https://www.cs.arizona.edu/people/philoliang/ndnviz/ NDN PUBLICATIONS, PRESENTATIONS, and TECHNICAL REPORTS * Peter Gusev, Zhehao Wang, Jeff Burke, Lixia Zhang, Eiichi Muramoto, Ryota Ohnishi, and Takahiro Yoneda. "Real-time streaming data delivery over Named Data Networking" IEICE Transactions, May 2016. http://named-data.net/publications/realtime_streaming_data_delivery_ndn/ * Vince Lehman, Ashlesh Gawande, Rodrigo Aldecoa, Dmitri Krioukov, Beichuan Zhang, Lixia Zhang, and Lan Wang. "An Experimental Investigation of Hyperbolic Routing with a Smart Forwarding Plane in NDN" IEEE IWQoS Symposium, June 2016. http://named-data.net/publications/experimental_investigation_hyperbolic_routing/ * We posted revision 1 of the technical report NDN-0039-1 "PartialSync: Efficient Synchronization of a Partial Namespace in NDN." Data synchronization plays an important role in NDN similar to transport protocols in IP. Some distributed applications, such as news and weather services, require a synchronization protocol where each consumer can subscribe to a different subset of a producer's data streams. In this paper, we propose PartialSync which aims to efficiently address this synchronization problem. http://named-data.net/publications/techreports/ndn-0039-1-partial-sync/. * Lixia Zhang presented "New Applications via Opportunistic Peer-to-Peer Wireless Communications" NSF Future Wireless Cities Workshop, Feb 2016. http://www.winlab.rutgers.edu/events/wicities/documents/LZhang_000.pdf * Lixia Zhang presented "Named Data Networking of Things" US-Europe Invited Workshop on Next Generation Internet of Things, March 2016. http://anrg.usc.edu/ngiot16/program.html * Alex Afanasyev presented "Supporting Mobility in Named Data Networking" At 3rd Workshop on Name-Oriented Mobility: Architecture, Algorithms and Applications, April 2016. http://web.cs.ucla.edu/~lixia/talks/1604ndn-mobility * Jeff Burke presented "Design Principles for Named Data Networking" ICNRG Interim meeting @ IETF 95, Buenos Aires, Argentina, April 3, 2016. https://www.ietf.org/proceedings/interim/2016/04/03/icnrg/slides/slides-interim-2016-icnrg-2-2.pdf * Lixia Zhang presented "Challenges in the Internet of Things Realization" at the 7th Annual PKU-UCLA Joint Research Institute Symposium. http://www.pku-jri.ucla.edu/jri/events/11766, May 2016 * Lixia Zhang presented "Looking Back, Looking Forward: Why We Need a New Internet Architecture" Keynote at 11th International Conference on Future Internet Technologies, June 2016. http://cfi2016.njnet.edu.cn/program.htm SEMINARS * The NDN seminars are internally focused. If you would like to participate in the NDN Seminars, please contact the PoC, UCLA PhD. candidate Spyridon Mastorakis for the most up-to-date information regarding upcoming seminars. - 2 June 2016 Klaus Schneider (University of Arizona), "Practical Congestion Control for NDN" RELATED NEWS * CALL FOR PAPERS: 15 July 2016 deadline: 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/ * CALL FOR PAPERS: 15 July 2016 deadline: 2nd IEEE International Workshop on Information Centric Networking Solutions for Real World Applications (ICNSRA). http://icnsra.nz.comm.waseda.ac.jp/ For more information about the Named Data Networking (NDN) Project please visit http://www.named-data.net/. From klaus at email.arizona.edu Wed Jul 6 17:06:00 2016 From: klaus at email.arizona.edu (Klaus Schneider) Date: Wed, 6 Jul 2016 17:06:00 -0700 Subject: [Ndn-interest] NACK In-Reply-To: References: <45FFA2D0-57BE-4F95-8BD0-718850F8C3A8@cs.ucla.edu> Message-ID: <577D9CE8.5010307@email.arizona.edu> I think there are at least two cases in which the verification fails: 1) random errors which couldn't be corrected by a lower layer and 2) purposeful manipulation of the packet by a malicious attacker. I don't know how easy these are to distinguish, but in both cases it's likely that the in-network routers have to solve the problem by forwarding interests on a different path. There is a trade-off in how persistently routers should retransmit before notifying the consumer: In one extreme all routers on the path try all of their paths before sending a NACK back (potentially increasing the delay to the point where the consumer no longer needs the data). In the other extreme, the NACK goes directly to the consumer and then the consumer sends a retransmission to tell the routers to try a different path (increasing delay and packet overhead compared to routers retransmitting on their own). It is also useful to identify how fine-granular the problem is: Did the data corruption affect 1) just a single packet, 2) many/most packets under that FIB-prefix-face combination, or 3) all packets send over that face? This information can then be used to make better decisions at the forwarding layer, like moving traffic of the affected "flow"/FIB prefix/face. I think the problem is quite similar to the one of congestion. Best regards, Klaus On 30.06.2016 14:29, Cesar Ghali wrote: > 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 > 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 > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From tnsr.chatterjee at gmail.com Wed Jul 6 18:49:36 2016 From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee) Date: Thu, 7 Jul 2016 07:19:36 +0530 Subject: [Ndn-interest] NACK In-Reply-To: <577D9CE8.5010307@email.arizona.edu> References: <45FFA2D0-57BE-4F95-8BD0-718850F8C3A8@cs.ucla.edu> <577D9CE8.5010307@email.arizona.edu> Message-ID: Can any special Interest be signed to check its authenticity on other side? On Jul 7, 2016 5:37 AM, "Klaus Schneider" wrote: > > I think there are at least two cases in which the verification fails: 1) random errors which couldn't be corrected by a lower layer and 2) purposeful manipulation of the packet by a malicious attacker. > > I don't know how easy these are to distinguish, but in both cases it's likely that the in-network routers have to solve the problem by forwarding interests on a different path. > > There is a trade-off in how persistently routers should retransmit before notifying the consumer: In one extreme all routers on the path try all of their paths before sending a NACK back (potentially increasing the delay to the point where the consumer no longer needs the data). In the other extreme, the NACK goes directly to the consumer and then the consumer sends a retransmission to tell the routers to try a different path (increasing delay and packet overhead compared to routers retransmitting on their own). > > It is also useful to identify how fine-granular the problem is: Did the data corruption affect 1) just a single packet, 2) many/most packets under that FIB-prefix-face combination, or 3) all packets send over that face? > > This information can then be used to make better decisions at the forwarding layer, like moving traffic of the affected "flow"/FIB prefix/face. I think the problem is quite similar to the one of congestion. > > Best regards, > Klaus > > > > > > > > On 30.06.2016 14:29, Cesar Ghali wrote: >> >> 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 >> 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 >> >> >> >> _______________________________________________ >> 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 klaus at email.arizona.edu Wed Jul 6 19:12:29 2016 From: klaus at email.arizona.edu (Klaus Schneider) Date: Wed, 6 Jul 2016 19:12:29 -0700 Subject: [Ndn-interest] NACK In-Reply-To: References: <45FFA2D0-57BE-4F95-8BD0-718850F8C3A8@cs.ucla.edu> <577D9CE8.5010307@email.arizona.edu> Message-ID: <577DBA8D.7060700@email.arizona.edu> I'm not an expert in NDN security, but it looks like it can: http://named-data.net/doc/ndn-cxx/current/tutorials/security-library.html#signing-interests http://named-data.net/doc/ndn-cxx/current/tutorials/signed-interest.html Best regards. On 06.07.2016 18:49, Tanusree Chatterjee wrote: > Can any special Interest be signed to check its authenticity on other side? > On Jul 7, 2016 5:37 AM, "Klaus Schneider" > wrote: > > > > I think there are at least two cases in which the verification fails: > 1) random errors which couldn't be corrected by a lower layer and 2) > purposeful manipulation of the packet by a malicious attacker. > > > > I don't know how easy these are to distinguish, but in both cases > it's likely that the in-network routers have to solve the problem by > forwarding interests on a different path. > > > > There is a trade-off in how persistently routers should retransmit > before notifying the consumer: In one extreme all routers on the path > try all of their paths before sending a NACK back (potentially > increasing the delay to the point where the consumer no longer needs the > data). In the other extreme, the NACK goes directly to the consumer and > then the consumer sends a retransmission to tell the routers to try a > different path (increasing delay and packet overhead compared to routers > retransmitting on their own). > > > > It is also useful to identify how fine-granular the problem is: Did > the data corruption affect 1) just a single packet, 2) many/most packets > under that FIB-prefix-face combination, or 3) all packets send over that > face? > > > > This information can then be used to make better decisions at the > forwarding layer, like moving traffic of the affected "flow"/FIB > prefix/face. I think the problem is quite similar to the one of congestion. > > > > Best regards, > > Klaus > > > > > > > > > > > > > > > > On 30.06.2016 14:29, Cesar Ghali wrote: > >> > >> 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 > >> > > 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 > >> > >> > >> > >> _______________________________________________ > >> Ndn-interest mailing list > >> Ndn-interest at lists.cs.ucla.edu > >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > >> > > _______________________________________________ > > Ndn-interest mailing list > > Ndn-interest at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From zeinabzali at gmail.com Thu Jul 7 06:41:36 2016 From: zeinabzali at gmail.com (Zeinab Zali) Date: Thu, 7 Jul 2016 18:11:36 +0430 Subject: [Ndn-interest] How sending an interest for each chunk is justified? Message-ID: Dear all, There is a serious question in my mind about NDN architecture and method. Is sending *an interest for each chunk *is efficient? In this way, for a large file lots of interest should be sent with all the security and communication (or even may be routing and forwarding) overhead. How It is justified? Is there a discussion in the literature about it? Thanks in advance, Zeinab. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Thu Jul 7 08:09:32 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Thu, 7 Jul 2016 15:09:32 +0000 Subject: [Ndn-interest] LSDB in NLSR In-Reply-To: References: Message-ID: <0690742F-ACB4-45C5-96A5-653D7567016D@memphis.edu> Tanusree, On Jun 25, 2016, at 6:36 AM, Tanusree Chatterjee > wrote: 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. This is a good summary of how ChronoSync works. If I understand correctly, ChronoSync doesn?t have a deep digest tree: just the leaves and a root. So, using chronosync, it reduces too much message exchanges than the previous sync protocol? Which previous sync protocol are you referring to? CCNSync? I?m not aware of comparisons in terms of message overhead between chronosync and CCNSync. They are not implemented on the same platform. The paper ?Synchronizing Namespaces with Invertible Bloom Filters? by Fu, Abraham and Crowley https://named-data.net/wp-content/uploads/2015/08/synchronizing_namespaces_invertible_bloom_filters.pdf has comparison between iSync and CCNSync. 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? NLSR uses ChronoSync. The Sync data packet carries the same name as the Sync interest (not the LSA name). The LSA name is carried inside the Sync data packet as content. Since the Sync data packet is a regular ndn data packet, it has a signature from the node that originates the Sync data. The trust model for the sync protocol protects the authenticity of the sync data (I think the trust model is still an open research issue for ChronoSync), but I may be wrong. Alex Afanasyev at UCLA can give you more accurate and up-to-date information about ChronoSync. Lan -- 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 lixia at CS.UCLA.EDU Thu Jul 7 08:53:20 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Thu, 7 Jul 2016 08:53:20 -0700 Subject: [Ndn-interest] How sending an interest for each chunk is justified? In-Reply-To: References: Message-ID: <7F45B45D-5EC4-45F2-B597-BE8E9437E95A@cs.ucla.edu> > On Jul 7, 2016, at 6:41 AM, Zeinab Zali wrote: > > Dear all, > > There is a serious question in my mind about NDN architecture and method. Is sending an interest for each chunk is efficient? In this way, for a large file lots of interest should be sent with all the security and communication (or even may be routing and forwarding) overhead. How It is justified? Is there a discussion in the literature about it? Dear Zeinab, thanks for bringing up the question. I tried to fully understand it before commenting: you asked: "Is sending an interest for each chunk is efficient?" this implies to me that you worry about sending more interest packets than necessary -- is that right? If so, - keen in mind we are talking about a network layer protocol here (network packet must have a MTU size that prevents a single packet blocking others for too long) - one of the many functions that interest-data exchange provides is loss recovery - if one sent an interest per big file, wouldn't that make the whole file as the unit of loss recovery? Would that be efficient? Lixia PS: You must know that a TCP connection also has packets going both directions, for the same purpose. There is no attempt to reduce TCP ack overhead by making TCP Ack to work on a file granularity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Mosko at parc.com Thu Jul 7 09:02:11 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Thu, 7 Jul 2016 16:02:11 +0000 Subject: [Ndn-interest] NACK In-Reply-To: <577DBA8D.7060700@email.arizona.edu> References: <45FFA2D0-57BE-4F95-8BD0-718850F8C3A8@cs.ucla.edu> <577D9CE8.5010307@email.arizona.edu> <577DBA8D.7060700@email.arizona.edu> Message-ID: <94812A34-5B78-41F1-9C28-545C35B5DA80@parc.com> As noted below, NDN has a method to embed a SignatureInfo and SignatureValue at the end of a name. This only protects the name, not the other fields in an interest. Those other fields could still be corrupted or maliciously altered. For example, someone could change MinSuffixComponents from ?0? to ?1? and there may be no way for the Interest originator to know this because they still get back valid Data, just not all the Data they were asking for. Or, one could modify the Exclude field to omit certain data packets or cause the same one to keep being returned. I do not think intermediate nodes should try to parse NDN SignedInterest. There is no deterministic way to figure out if a name is signed apart from knowledge of the application-layer framing and application security protocol. One could try to guess by inspecting the last four name components of the Interest to see if they look like a signature, but that is no guarantee they are a signature. My understanding from looking at the specs is that the last 4 name components would look like this, where ?__? is a length of the bytes to the right. %08%08/%08%08/%08__%16__/%08__%17__ The issue is that generic name component (%08) is an opaque octet string, so it could be anything that just happens to have %16 or %17 as the 1st byte of name component, based on the application?s use. I grant that if the %16__ evaluates to the correct length and %17__ evaluates to the correct length, then its more likely you have a signed interest, but you are still guessing. You could keep on trying to parse further and further down in the data structures to see if it syntactically looks like a signature info (not the signature value, it has no TLV structure), but that is a lot of work to do on every Interest and makes an easy attack vector against forwarders. The Naming Conventions tech report (https://named-data.net/wp-content/uploads/2014/08/ndn-tr-22-ndn-memo-naming-conventions.pdf) reserves some special values as the 1st byte of a name component, but the values %16 and %17 are not in those reserved values, so these fall squarely in the opaque octet string realm. Marc > On Jul 6, 2016, at 7:12 PM, Klaus Schneider wrote: > > I'm not an expert in NDN security, but it looks like it can: > > http://named-data.net/doc/ndn-cxx/current/tutorials/security-library.html#signing-interests > > http://named-data.net/doc/ndn-cxx/current/tutorials/signed-interest.html > > Best regards. > > > On 06.07.2016 18:49, Tanusree Chatterjee wrote: >> Can any special Interest be signed to check its authenticity on other side? >> On Jul 7, 2016 5:37 AM, "Klaus Schneider" > > wrote: >> > >> > I think there are at least two cases in which the verification fails: >> 1) random errors which couldn't be corrected by a lower layer and 2) >> purposeful manipulation of the packet by a malicious attacker. >> > >> > I don't know how easy these are to distinguish, but in both cases >> it's likely that the in-network routers have to solve the problem by >> forwarding interests on a different path. >> > >> > There is a trade-off in how persistently routers should retransmit >> before notifying the consumer: In one extreme all routers on the path >> try all of their paths before sending a NACK back (potentially >> increasing the delay to the point where the consumer no longer needs the >> data). In the other extreme, the NACK goes directly to the consumer and >> then the consumer sends a retransmission to tell the routers to try a >> different path (increasing delay and packet overhead compared to routers >> retransmitting on their own). >> > >> > It is also useful to identify how fine-granular the problem is: Did >> the data corruption affect 1) just a single packet, 2) many/most packets >> under that FIB-prefix-face combination, or 3) all packets send over that >> face? >> > >> > This information can then be used to make better decisions at the >> forwarding layer, like moving traffic of the affected "flow"/FIB >> prefix/face. I think the problem is quite similar to the one of congestion. >> > >> > Best regards, >> > Klaus >> > >> > >> > >> > >> > >> > >> > >> > On 30.06.2016 14:29, Cesar Ghali wrote: >> >> >> >> 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 >> >> > >> 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 >> >> >> >> >> >> >> >> _______________________________________________ >> >> Ndn-interest mailing list >> >> Ndn-interest at lists.cs.ucla.edu >> >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> >> >> > _______________________________________________ >> > Ndn-interest mailing list >> > Ndn-interest at lists.cs.ucla.edu >> > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From zeinabzali at gmail.com Thu Jul 7 10:45:57 2016 From: zeinabzali at gmail.com (Zeinab Zali) Date: Thu, 7 Jul 2016 22:15:57 +0430 Subject: [Ndn-interest] How sending an interest for each chunk is justified? In-Reply-To: <7F45B45D-5EC4-45F2-B597-BE8E9437E95A@cs.ucla.edu> References: <7F45B45D-5EC4-45F2-B597-BE8E9437E95A@cs.ucla.edu> Message-ID: Dear professor Zhang, Thanks a lot for your instant reply. Yes you got my intention and explained the reply perfectly. "You must know that a TCP connection also has packets going both directions, for the same purpose. There is no attempt to reduce TCP ack overhead by making TCP Ack to work on a file granularity." This explanation justified me. Best, On Thu, Jul 7, 2016 at 8:23 PM, Lixia Zhang wrote: > > On Jul 7, 2016, at 6:41 AM, Zeinab Zali wrote: > > Dear all, > > There is a serious question in my mind about NDN architecture and method. > Is sending *an interest for each chunk *is efficient? In this way, for a > large file lots of interest should be sent with all the security and > communication (or even may be routing and forwarding) overhead. How It is > justified? Is there a discussion in the literature about it? > > > Dear Zeinab, > > thanks for bringing up the question. I tried to fully understand it before > commenting: you asked: > "Is sending *an interest for each chunk *is efficient?" > this implies to me that you worry about sending more interest packets than > necessary -- is that right? > > If so, > - keen in mind we are talking about a network layer protocol here (network > packet must have a MTU size that prevents a single packet blocking others > for too long) > - one of the many functions that interest-data exchange provides is loss > recovery > - if one sent an interest per big file, wouldn't that make the whole file > as the unit of loss recovery? Would that be efficient? > > Lixia > PS: You must know that a TCP connection also has packets going both > directions, for the same purpose. There is no attempt to reduce TCP ack > overhead by making TCP Ack to work on a file granularity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Mosko at parc.com Thu Jul 7 15:30:13 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Thu, 7 Jul 2016 22:30:13 +0000 Subject: [Ndn-interest] How sending an interest for each chunk is justified? In-Reply-To: References: <7F45B45D-5EC4-45F2-B597-BE8E9437E95A@cs.ucla.edu> Message-ID: <060690E4-FE9B-4260-BB5E-E803A73B5A57@parc.com> I would note, however, that TCP does not require an ACK for every segment. One usually sends every 2 packets, or even more. So while one would not ?work on file granularity? (for a big file), one could have a very large window and infrequent ACKs in TCP while keeping each segment MTU size. An ACK only needs the IP addresses and a TCP header. A TCP ACK has 40 bytes of IPv6 header plus 20 bytes of TCP header (total 60 bytes) per 2880 bytes of payload (2x 1500 - 2x 60). Therefore, one must be careful of how much information is put in an Interest to request each segment. An Interest may have a much larger size than 60 byte. For parity with TCP, one would need no more than 30 byte interest per 1500 byte packet [1]. A 30 byte NDN interest (excluding NDNLP) means for a 5-component name you only have about 9 bytes of data per name component considering TLV encapsulation [2]. It also means you don?t have KeyID restrictions or hash restrictions in the name or selectors. Also, the data needs to echo back the name (or even a longer name), so you only get 1500 - TLV overhead & name overhead (66 bytes without any SignatureInfo or SignatureValue) = 1434 bytes per packet. So, as long as Interest size is around that size, you have parity with TCP6 on the upstream bandwidth. As long as the TLV encoding and name are on par with the IPv6/TCP headers, you have downstream parity. [1] One could use a larger MTU with fragmentation if you are willing to pay fragmentation overhead. But this could be done with TCP too. [2] I computed this as Interest TLV (2 bytes), Name TLV (2 bytes), 5x name component (10 bytes) gives 46 bytes of name, so 46 / 5 = 9.2 bytes per name component. Marc On Jul 7, 2016, at 10:45 AM, Zeinab Zali > wrote: Dear professor Zhang, Thanks a lot for your instant reply. Yes you got my intention and explained the reply perfectly. "You must know that a TCP connection also has packets going both directions, for the same purpose. There is no attempt to reduce TCP ack overhead by making TCP Ack to work on a file granularity." This explanation justified me. Best, On Thu, Jul 7, 2016 at 8:23 PM, Lixia Zhang > wrote: On Jul 7, 2016, at 6:41 AM, Zeinab Zali > wrote: Dear all, There is a serious question in my mind about NDN architecture and method. Is sending an interest for each chunk is efficient? In this way, for a large file lots of interest should be sent with all the security and communication (or even may be routing and forwarding) overhead. How It is justified? Is there a discussion in the literature about it? Dear Zeinab, thanks for bringing up the question. I tried to fully understand it before commenting: you asked: "Is sending an interest for each chunk is efficient?" this implies to me that you worry about sending more interest packets than necessary -- is that right? If so, - keen in mind we are talking about a network layer protocol here (network packet must have a MTU size that prevents a single packet blocking others for too long) - one of the many functions that interest-data exchange provides is loss recovery - if one sent an interest per big file, wouldn't that make the whole file as the unit of loss recovery? Would that be efficient? Lixia PS: You must know that a TCP connection also has packets going both directions, for the same purpose. There is no attempt to reduce TCP ack overhead by making TCP Ack to work on a file granularity. _______________________________________________ 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 Jul 7 16:04:57 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Thu, 7 Jul 2016 16:04:57 -0700 Subject: [Ndn-interest] How sending an interest for each chunk is justified? In-Reply-To: <060690E4-FE9B-4260-BB5E-E803A73B5A57@parc.com> References: <7F45B45D-5EC4-45F2-B597-BE8E9437E95A@cs.ucla.edu> <060690E4-FE9B-4260-BB5E-E803A73B5A57@parc.com> Message-ID: > On Jul 7, 2016, at 3:30 PM, wrote: > > I would note, however, that TCP does not require an ACK for every segment. One usually sends every 2 packets, or even more. So while one would not ?work on file granularity? (for a big file), one could have a very large window and infrequent ACKs in TCP while keeping each segment MTU size. An ACK only needs the IP addresses and a TCP header. A TCP ACK has 40 bytes of IPv6 header plus 20 bytes of TCP header (total 60 bytes) per 2880 bytes of payload (2x 1500 - 2x 60). Therefore, one must be careful of how much information is put in an Interest to request each segment. > > An Interest may have a much larger size than 60 byte. For parity with TCP, one would need no more than 30 byte interest per 1500 byte packet [1]. While TCP of course can use larger MTU sizes and use it if they are available. The problems is that the problems with IP fragmentation (e.g., loss of a single fragment invalidates the whole packet) de-incentivizes packets larger MTU, which in turn creates no incentives to increase MTU in the network. Moreover, the overhead ratio is acceptable, so there is no much pressure to do that. In ICN/NDN things are different. There are larger overheads: names may take more space, unlike fixed size IP addresses, signatures take another big chunk of space in data packets. To get acceptable level overhead, one would want to use larger packet sizes. This would be a good push to increase MTU sizes (I'm just speculating, but 4-8k may be reasonable in many cases). Having transparent hop-by-hop fragmentation (http://named-data.net/publications/techreports/ndn-0032-1-ndn-memo-fragmentation/ ) is another incentive and push to increase MTU in the network where possible. -- Alex > A 30 byte NDN interest (excluding NDNLP) means for a 5-component name you only have about 9 bytes of data per name component considering TLV encapsulation [2]. It also means you don?t have KeyID restrictions or hash restrictions in the name or selectors. Also, the data needs to echo back the name (or even a longer name), so you only get 1500 - TLV overhead & name overhead (66 bytes without any SignatureInfo or SignatureValue) = 1434 bytes per packet. > > So, as long as Interest size is around that size, you have parity with TCP6 on the upstream bandwidth. As long as the TLV encoding and name are on par with the IPv6/TCP headers, you have downstream parity. > > [1] One could use a larger MTU with fragmentation if you are willing to pay fragmentation overhead. But this could be done with TCP too. > [2] I computed this as Interest TLV (2 bytes), Name TLV (2 bytes), 5x name component (10 bytes) gives 46 bytes of name, so 46 / 5 = 9.2 bytes per name component. > > Marc > >> On Jul 7, 2016, at 10:45 AM, Zeinab Zali > wrote: >> >> Dear professor Zhang, >> >> Thanks a lot for your instant reply. Yes you got my intention and explained the reply perfectly. >> >> "You must know that a TCP connection also has packets going both directions, for the same purpose. There is no attempt to >> reduce TCP ack overhead by making TCP Ack to work on a file granularity." >> >> This explanation justified me. >> >> Best, >> >> On Thu, Jul 7, 2016 at 8:23 PM, Lixia Zhang > wrote: >> >>> On Jul 7, 2016, at 6:41 AM, Zeinab Zali > wrote: >>> >>> Dear all, >>> >>> There is a serious question in my mind about NDN architecture and method. Is sending an interest for each chunk is efficient? In this way, for a large file lots of interest should be sent with all the security and communication (or even may be routing and forwarding) overhead. How It is justified? Is there a discussion in the literature about it? >> >> Dear Zeinab, >> >> thanks for bringing up the question. I tried to fully understand it before commenting: you asked: >> "Is sending an interest for each chunk is efficient?" >> this implies to me that you worry about sending more interest packets than necessary -- is that right? >> >> If so, >> - keen in mind we are talking about a network layer protocol here (network packet must have a MTU size that prevents a single packet blocking others for too long) >> - one of the many functions that interest-data exchange provides is loss recovery >> - if one sent an interest per big file, wouldn't that make the whole file as the unit of loss recovery? Would that be efficient? >> >> Lixia >> PS: You must know that a TCP connection also has packets going both directions, for the same purpose. There is no attempt to reduce TCP ack overhead by making TCP Ack to work on a file granularity. >> >> _______________________________________________ >> 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: -------------- 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 zeinabzali at gmail.com Fri Jul 8 01:07:25 2016 From: zeinabzali at gmail.com (Zeinab Zali) Date: Fri, 8 Jul 2016 12:37:25 +0430 Subject: [Ndn-interest] How sending an interest for each chunk is justified? In-Reply-To: References: <7F45B45D-5EC4-45F2-B597-BE8E9437E95A@cs.ucla.edu> <060690E4-FE9B-4260-BB5E-E803A73B5A57@parc.com> Message-ID: Thank you so much Alex and Marc for the good discussion, that was useful for me. On Fri, Jul 8, 2016 at 3:34 AM, Alex Afanasyev wrote: > > On Jul 7, 2016, at 3:30 PM, > wrote: > > I would note, however, that TCP does not require an ACK for every > segment. One usually sends every 2 packets, or even more. So while one > would not ?work on file granularity? (for a big file), one could have a > very large window and infrequent ACKs in TCP while keeping each segment MTU > size. An ACK only needs the IP addresses and a TCP header. A TCP ACK has > 40 bytes of IPv6 header plus 20 bytes of TCP header (total 60 bytes) per > 2880 bytes of payload (2x 1500 - 2x 60). Therefore, one must be careful of > how much information is put in an Interest to request each segment. > > An Interest may have a much larger size than 60 byte. For parity with > TCP, one would need no more than 30 byte interest per 1500 byte packet [1]. > > > > While TCP of course can use larger MTU sizes and use it if they are > available. The problems is that the problems with IP fragmentation (e.g., > loss of a single fragment invalidates the whole packet) de-incentivizes > packets larger MTU, which in turn creates no incentives to increase MTU in > the network. Moreover, the overhead ratio is acceptable, so there is no > much pressure to do that. > > In ICN/NDN things are different. There are larger overheads: names may > take more space, unlike fixed size IP addresses, signatures take another > big chunk of space in data packets. To get acceptable level overhead, one > would want to use larger packet sizes. This would be a good push to > increase MTU sizes (I'm just speculating, but 4-8k may be reasonable in > many cases). Having transparent hop-by-hop fragmentation ( > http://named-data.net/publications/techreports/ndn-0032-1-ndn-memo-fragmentation/) > is another incentive and push to increase MTU in the network where possible. > > -- > Alex > > A 30 byte NDN interest (excluding NDNLP) means for a 5-component name you > only have about 9 bytes of data per name component considering TLV > encapsulation [2]. It also means you don?t have KeyID restrictions or hash > restrictions in the name or selectors. Also, the data needs to echo back > the name (or even a longer name), so you only get 1500 - TLV overhead & > name overhead (66 bytes without any SignatureInfo or SignatureValue) = 1434 > bytes per packet. > > So, as long as Interest size is around that size, you have parity with > TCP6 on the upstream bandwidth. As long as the TLV encoding and name are > on par with the IPv6/TCP headers, you have downstream parity. > > [1] One could use a larger MTU with fragmentation if you are willing to > pay fragmentation overhead. But this could be done with TCP too. > [2] I computed this as Interest TLV (2 bytes), Name TLV (2 bytes), 5x name > component (10 bytes) gives 46 bytes of name, so 46 / 5 = 9.2 bytes per name > component. > > > > > Marc > > On Jul 7, 2016, at 10:45 AM, Zeinab Zali wrote: > > Dear professor Zhang, > > Thanks a lot for your instant reply. Yes you got my intention and > explained the reply perfectly. > > "You must know that a TCP connection also has packets going both > directions, for the same purpose. There is no attempt to > reduce TCP ack overhead by making TCP Ack to work on a file granularity." > > This explanation justified me. > > Best, > > On Thu, Jul 7, 2016 at 8:23 PM, Lixia Zhang wrote: > >> >> On Jul 7, 2016, at 6:41 AM, Zeinab Zali wrote: >> >> Dear all, >> >> There is a serious question in my mind about NDN architecture and method. >> Is sending *an interest for each chunk *is efficient? In this way, for a >> large file lots of interest should be sent with all the security and >> communication (or even may be routing and forwarding) overhead. How It is >> justified? Is there a discussion in the literature about it? >> >> >> Dear Zeinab, >> >> thanks for bringing up the question. I tried to fully understand it >> before commenting: you asked: >> "Is sending *an interest for each chunk *is efficient?" >> this implies to me that you worry about sending more interest packets >> than necessary -- is that right? >> >> If so, >> - keen in mind we are talking about a network layer protocol here >> (network packet must have a MTU size that prevents a single packet blocking >> others for too long) >> - one of the many functions that interest-data exchange provides is loss >> recovery >> - if one sent an interest per big file, wouldn't that make the whole file >> as the unit of loss recovery? Would that be efficient? >> >> Lixia >> PS: You must know that a TCP connection also has packets going both >> directions, for the same purpose. There is no attempt to reduce TCP ack >> overhead by making TCP Ack to work on a file granularity. >> > > _______________________________________________ > 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 tailinchu at gmail.com Fri Jul 8 15:55:26 2016 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Fri, 8 Jul 2016 15:55:26 -0700 Subject: [Ndn-interest] NACK In-Reply-To: <94812A34-5B78-41F1-9C28-545C35B5DA80@parc.com> References: <45FFA2D0-57BE-4F95-8BD0-718850F8C3A8@cs.ucla.edu> <577D9CE8.5010307@email.arizona.edu> <577DBA8D.7060700@email.arizona.edu> <94812A34-5B78-41F1-9C28-545C35B5DA80@parc.com> Message-ID: > As noted below, NDN has a method to embed a SignatureInfo and SignatureValue at the end of a name. This only protects the name, not the other fields in an interest. Those other fields could still be corrupted or maliciously altered. For example, someone could change MinSuffixComponents from ?0? to ?1? and there may be no way for the Interest originator to know this because they still get back valid Data, just not all the Data they were asking for. Or, one could modify the Exclude field to omit certain data packets or cause the same one to keep being returned. The example is unlikely to happen. Because signed interest name is unique, there should be only one expected valid data. However, it is possible to deny signed interest response by modifying selectors. Am I missing something? Thanks! On Thu, Jul 7, 2016 at 9:02 AM, wrote: > As noted below, NDN has a method to embed a SignatureInfo and > SignatureValue at the end of a name. This only protects the name, not the > other fields in an interest. Those other fields could still be corrupted > or maliciously altered. For example, someone could change > MinSuffixComponents from ?0? to ?1? and there may be no way for the > Interest originator to know this because they still get back valid Data, > just not all the Data they were asking for. Or, one could modify the > Exclude field to omit certain data packets or cause the same one to keep > being returned. > > I do not think intermediate nodes should try to parse NDN SignedInterest. > There is no deterministic way to figure out if a name is signed apart from > knowledge of the application-layer framing and application security > protocol. One could try to guess by inspecting the last four name > components of the Interest to see if they look like a signature, but that > is no guarantee they are a signature. > > My understanding from looking at the specs is that the last 4 name > components would look like this, where ?__? is a length of the bytes to the > right. > > > %08%08/%08%08/%08__%16__/%08__%17__ > > The issue is that generic name component (%08) is an opaque octet string, > so it could be anything that just happens to have %16 or %17 as the 1st > byte of name component, based on the application?s use. I grant that if > the %16__ evaluates to the correct length and %17__ evaluates to the > correct length, then its more likely you have a signed interest, but you > are still guessing. You could keep on trying to parse further and further > down in the data structures to see if it syntactically looks like a > signature info (not the signature value, it has no TLV structure), but that > is a lot of work to do on every Interest and makes an easy attack vector > against forwarders. > > The Naming Conventions tech report ( > https://named-data.net/wp-content/uploads/2014/08/ndn-tr-22-ndn-memo-naming-conventions.pdf) > reserves some special values as the 1st byte of a name component, but the > values %16 and %17 are not in those reserved values, so these fall squarely > in the opaque octet string realm. > > Marc > > > On Jul 6, 2016, at 7:12 PM, Klaus Schneider > wrote: > > > > I'm not an expert in NDN security, but it looks like it can: > > > > > http://named-data.net/doc/ndn-cxx/current/tutorials/security-library.html#signing-interests > > > > http://named-data.net/doc/ndn-cxx/current/tutorials/signed-interest.html > > > > Best regards. > > > > > > On 06.07.2016 18:49, Tanusree Chatterjee wrote: > >> Can any special Interest be signed to check its authenticity on other > side? > >> On Jul 7, 2016 5:37 AM, "Klaus Schneider" >> > wrote: > >> > > >> > I think there are at least two cases in which the verification fails: > >> 1) random errors which couldn't be corrected by a lower layer and 2) > >> purposeful manipulation of the packet by a malicious attacker. > >> > > >> > I don't know how easy these are to distinguish, but in both cases > >> it's likely that the in-network routers have to solve the problem by > >> forwarding interests on a different path. > >> > > >> > There is a trade-off in how persistently routers should retransmit > >> before notifying the consumer: In one extreme all routers on the path > >> try all of their paths before sending a NACK back (potentially > >> increasing the delay to the point where the consumer no longer needs the > >> data). In the other extreme, the NACK goes directly to the consumer and > >> then the consumer sends a retransmission to tell the routers to try a > >> different path (increasing delay and packet overhead compared to routers > >> retransmitting on their own). > >> > > >> > It is also useful to identify how fine-granular the problem is: Did > >> the data corruption affect 1) just a single packet, 2) many/most packets > >> under that FIB-prefix-face combination, or 3) all packets send over that > >> face? > >> > > >> > This information can then be used to make better decisions at the > >> forwarding layer, like moving traffic of the affected "flow"/FIB > >> prefix/face. I think the problem is quite similar to the one of > congestion. > >> > > >> > Best regards, > >> > Klaus > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > On 30.06.2016 14:29, Cesar Ghali wrote: > >> >> > >> >> 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 > >> >> > > >> 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 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 Ndn-interest at lists.cs.ucla.edu> > >> >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > >> >> > >> > _______________________________________________ > >> > Ndn-interest mailing list > >> > Ndn-interest at lists.cs.ucla.edu > > >> > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > >> > > _______________________________________________ > > Ndn-interest mailing list > > Ndn-interest at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marc.Mosko at parc.com Fri Jul 8 22:57:12 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Sat, 9 Jul 2016 05:57:12 +0000 Subject: [Ndn-interest] NACK In-Reply-To: References: <45FFA2D0-57BE-4F95-8BD0-718850F8C3A8@cs.ucla.edu> <577D9CE8.5010307@email.arizona.edu> <577DBA8D.7060700@email.arizona.edu> <94812A34-5B78-41F1-9C28-545C35B5DA80@parc.com> Message-ID: <2E5FF13C-362D-4F47-A756-70A0C8D6CB0E@parc.com> Yes, your point is well taken. One would expect that a signed interest with a timestamp and nonce in the name would elicit only one response from an on-line producer. If a selector were modified or corrupted, it would likely result in either no effect or making the Interest un-satisfiable (e.g. MinSuffixComponents is changed from ?0? to ?3? and the producer does not generate a name like that). Marc From: Tai-Lin Chu Date: Friday, July 8, 2016 at 3:55 PM To: Marc Cc: "klaus at email.arizona.edu" , "ndn-interest at lists.cs.ucla.edu" Subject: Re: [Ndn-interest] NACK > As noted below, NDN has a method to embed a SignatureInfo and SignatureValue at the end of a name. This only protects the name, not the other fields in an interest. Those other fields could still be corrupted or maliciously altered. For example, someone could change MinSuffixComponents from ?0? to ?1? and there may be no way for the Interest originator to know this because they still get back valid Data, just not all the Data they were asking for. Or, one could modify the Exclude field to omit certain data packets or cause the same one to keep being returned. The example is unlikely to happen. Because signed interest name is unique, there should be only one expected valid data. However, it is possible to deny signed interest response by modifying selectors. Am I missing something? Thanks! On Thu, Jul 7, 2016 at 9:02 AM, > wrote: As noted below, NDN has a method to embed a SignatureInfo and SignatureValue at the end of a name. This only protects the name, not the other fields in an interest. Those other fields could still be corrupted or maliciously altered. For example, someone could change MinSuffixComponents from ?0? to ?1? and there may be no way for the Interest originator to know this because they still get back valid Data, just not all the Data they were asking for. Or, one could modify the Exclude field to omit certain data packets or cause the same one to keep being returned. I do not think intermediate nodes should try to parse NDN SignedInterest. There is no deterministic way to figure out if a name is signed apart from knowledge of the application-layer framing and application security protocol. One could try to guess by inspecting the last four name components of the Interest to see if they look like a signature, but that is no guarantee they are a signature. My understanding from looking at the specs is that the last 4 name components would look like this, where ?__? is a length of the bytes to the right. %08%08/%08%08/%08__%16__/%08__%17__ The issue is that generic name component (%08) is an opaque octet string, so it could be anything that just happens to have %16 or %17 as the 1st byte of name component, based on the application?s use. I grant that if the %16__ evaluates to the correct length and %17__ evaluates to the correct length, then its more likely you have a signed interest, but you are still guessing. You could keep on trying to parse further and further down in the data structures to see if it syntactically looks like a signature info (not the signature value, it has no TLV structure), but that is a lot of work to do on every Interest and makes an easy attack vector against forwarders. The Naming Conventions tech report (https://named-data.net/wp-content/uploads/2014/08/ndn-tr-22-ndn-memo-naming-conventions.pdf) reserves some special values as the 1st byte of a name component, but the values %16 and %17 are not in those reserved values, so these fall squarely in the opaque octet string realm. Marc > On Jul 6, 2016, at 7:12 PM, Klaus Schneider > wrote: > > I'm not an expert in NDN security, but it looks like it can: > > http://named-data.net/doc/ndn-cxx/current/tutorials/security-library.html#signing-interests > > http://named-data.net/doc/ndn-cxx/current/tutorials/signed-interest.html > > Best regards. > > > On 06.07.2016 18:49, Tanusree Chatterjee wrote: >> Can any special Interest be signed to check its authenticity on other side? >> On Jul 7, 2016 5:37 AM, "Klaus Schneider" >> >> wrote: >> > >> > I think there are at least two cases in which the verification fails: >> 1) random errors which couldn't be corrected by a lower layer and 2) >> purposeful manipulation of the packet by a malicious attacker. >> > >> > I don't know how easy these are to distinguish, but in both cases >> it's likely that the in-network routers have to solve the problem by >> forwarding interests on a different path. >> > >> > There is a trade-off in how persistently routers should retransmit >> before notifying the consumer: In one extreme all routers on the path >> try all of their paths before sending a NACK back (potentially >> increasing the delay to the point where the consumer no longer needs the >> data). In the other extreme, the NACK goes directly to the consumer and >> then the consumer sends a retransmission to tell the routers to try a >> different path (increasing delay and packet overhead compared to routers >> retransmitting on their own). >> > >> > It is also useful to identify how fine-granular the problem is: Did >> the data corruption affect 1) just a single packet, 2) many/most packets >> under that FIB-prefix-face combination, or 3) all packets send over that >> face? >> > >> > This information can then be used to make better decisions at the >> forwarding layer, like moving traffic of the affected "flow"/FIB >> prefix/face. I think the problem is quite similar to the one of congestion. >> > >> > Best regards, >> > Klaus >> > >> > >> > >> > >> > >> > >> > >> > On 30.06.2016 14:29, Cesar Ghali wrote: >> >> >> >> 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 >> >> >> >> 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 >> >> >> >> >> >> >> >> _______________________________________________ >> >> Ndn-interest mailing list >> >> Ndn-interest at lists.cs.ucla.edu > >> >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> >> >> > _______________________________________________ >> > Ndn-interest mailing list >> > Ndn-interest at lists.cs.ucla.edu > >> > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From lixia at CS.UCLA.EDU Fri Jul 8 23:10:22 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Fri, 8 Jul 2016 23:10:22 -0700 Subject: [Ndn-interest] How sending an interest for each chunk is justified? In-Reply-To: <060690E4-FE9B-4260-BB5E-E803A73B5A57@parc.com> References: <7F45B45D-5EC4-45F2-B597-BE8E9437E95A@cs.ucla.edu> <060690E4-FE9B-4260-BB5E-E803A73B5A57@parc.com> Message-ID: We often talk about "learn how to think architecturally", so we can try it on this specific example, to sort out what may be architecture, what may be engineering, or how one may look at performance of different architectures. 1/ apps have their own units of data, like a file; network layer packets have their own MTU limit because packet is unit of loss recovery, and because a network is shared and too big a packet could cause excessive delays on others. These network basics hold true in both IP and NDN networks. 2/ With these basic concepts: one can do a great deal of engineering to optimize certain performance metrics. TCP acking every other segment is such an example; it's still consistent with the requirement that network packets operate on network data unit. 3/ It is very true that, at this time, NDN interest size can be a lot bigger than a TCP ACK, but that does not mean the interest size cannot get smaller, nor does it imply an NDN network less efficient (as the stateful forwarding by the interest-data exchange improves network efficiency in some fundamental ways that a stateless IP data plane cannot do). > On Jul 7, 2016, at 3:30 PM, Marc.Mosko at parc.com wrote: > > I would note, however, that TCP does not require an ACK for every segment. One usually sends every 2 packets, or even more. So while one would not ?work on file granularity? (for a big file), one could have a very large window and infrequent ACKs in TCP while keeping each segment MTU size. An ACK only needs the IP addresses and a TCP header. A TCP ACK has 40 bytes of IPv6 header plus 20 bytes of TCP header (total 60 bytes) per 2880 bytes of payload (2x 1500 - 2x 60). Therefore, one must be careful of how much information is put in an Interest to request each segment. > > An Interest may have a much larger size than 60 byte. For parity with TCP, one would need no more than 30 byte interest per 1500 byte packet [1]. A 30 byte NDN interest (excluding NDNLP) means for a 5-component name you only have about 9 bytes of data per name component considering TLV encapsulation [2]. It also means you don?t have KeyID restrictions or hash restrictions in the name or selectors. Also, the data needs to echo back the name (or even a longer name), so you only get 1500 - TLV overhead & name overhead (66 bytes without any SignatureInfo or SignatureValue) = 1434 bytes per packet. > > So, as long as Interest size is around that size, you have parity with TCP6 on the upstream bandwidth. As long as the TLV encoding and name are on par with the IPv6/TCP headers, you have downstream parity. > > [1] One could use a larger MTU with fragmentation if you are willing to pay fragmentation overhead. But this could be done with TCP too. > [2] I computed this as Interest TLV (2 bytes), Name TLV (2 bytes), 5x name component (10 bytes) gives 46 bytes of name, so 46 / 5 = 9.2 bytes per name component. > > Marc > >> On Jul 7, 2016, at 10:45 AM, Zeinab Zali > wrote: >> >> Dear professor Zhang, >> >> Thanks a lot for your instant reply. Yes you got my intention and explained the reply perfectly. >> >> "You must know that a TCP connection also has packets going both directions, for the same purpose. There is no attempt to >> reduce TCP ack overhead by making TCP Ack to work on a file granularity." >> >> This explanation justified me. >> >> Best, >> >> On Thu, Jul 7, 2016 at 8:23 PM, Lixia Zhang > wrote: >> >>> On Jul 7, 2016, at 6:41 AM, Zeinab Zali > wrote: >>> >>> Dear all, >>> >>> There is a serious question in my mind about NDN architecture and method. Is sending an interest for each chunk is efficient? In this way, for a large file lots of interest should be sent with all the security and communication (or even may be routing and forwarding) overhead. How It is justified? Is there a discussion in the literature about it? >> >> Dear Zeinab, >> >> thanks for bringing up the question. I tried to fully understand it before commenting: you asked: >> "Is sending an interest for each chunk is efficient?" >> this implies to me that you worry about sending more interest packets than necessary -- is that right? >> >> If so, >> - keen in mind we are talking about a network layer protocol here (network packet must have a MTU size that prevents a single packet blocking others for too long) >> - one of the many functions that interest-data exchange provides is loss recovery >> - if one sent an interest per big file, wouldn't that make the whole file as the unit of loss recovery? Would that be efficient? >> >> Lixia >> PS: You must know that a TCP connection also has packets going both directions, for the same purpose. There is no attempt to reduce TCP ack overhead by making TCP Ack to work on a file granularity. >> _______________________________________________ >> 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 m.faran.majeed at gmail.com Sat Jul 9 02:19:15 2016 From: m.faran.majeed at gmail.com (Muhammad Faran) Date: Sat, 9 Jul 2016 16:19:15 +0700 Subject: [Ndn-interest] NDN on Existing IEEE 802.11p a Good Idea??? Message-ID: Hi Everyone, I am looking forward to apply NDN architecture in vehicular ad hoc networks. However, I am wondering to find solid reasons, why the current DSRC/WAVE architecture isn't sufficient or why NDN favorably gonna play role in an efficient way for mobile ad hoc networks? To be specific, can I get few benefits of NDN on existing IEEE 802.11p? Kind regards, Muhammad Faran Majeed, AIT, Thailand -------------- next part -------------- An HTML attachment was scrubbed... URL: From tnsr.chatterjee at gmail.com Mon Jul 18 08:25:18 2016 From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee) Date: Mon, 18 Jul 2016 20:55:18 +0530 Subject: [Ndn-interest] Same LSDB in entire network? Message-ID: Hi all, One thing I could not be sure about that whether all the nodes in the network have the common LSDB? If so, all the nodes have the idea of topology of the entire network? If NLSR is concerned, so this synchronization of same LSDB in the entire network helps in security also? Regards, Tanusree Chatterjee -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Tue Jul 19 06:39:10 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Tue, 19 Jul 2016 13:39:10 +0000 Subject: [Ndn-interest] Same LSDB in entire network? In-Reply-To: References: Message-ID: <4184E115-31E2-4189-803C-2CB2C517862A@memphis.edu> Tanusree, Every node in NLSR maintains an LSDB (i.e. the topology of the entire network) since NLSR is a link-state routing protocol. If the network has converged, all the LSDBs should be the same. Every LSA is signed by its originator and can be verified using a trust model to make sure that the LSA is indeed originated by that origin router. This is a security benefit provided by NDN?s data-centric security model. Is this what you mean by ?this synchronization of same LSDB in the entire network helps in security"? Lan On Jul 18, 2016, at 9:25 AM, Tanusree Chatterjee > wrote: Hi all, One thing I could not be sure about that whether all the nodes in the network have the common LSDB? If so, all the nodes have the idea of topology of the entire network? If NLSR is concerned, so this synchronization of same LSDB in the entire network helps in security also? 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 tnsr.chatterjee at gmail.com Tue Jul 19 08:54:24 2016 From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee) Date: Tue, 19 Jul 2016 21:24:24 +0530 Subject: [Ndn-interest] Same LSDB in entire network? In-Reply-To: <4184E115-31E2-4189-803C-2CB2C517862A@memphis.edu> References: <4184E115-31E2-4189-803C-2CB2C517862A@memphis.edu> Message-ID: Thanks for the response. By security, I also meant the digest tree maintained by all the nodes (last version of NLSR) in the entire network must be same as they exchange the root digest while sending interest periodically to each other. So, to do the same each node in the entire network must have the common LSDB. As a simple scenario of 5 nodes I was running in mini ndn emulator, the nlsrc status of all nodes show the same LSDB, which consists of all the LSAs of each node in the network. On Jul 19, 2016 7:09 PM, "Lan Wang (lanwang)" wrote: > Tanusree, > > Every node in NLSR maintains an LSDB (i.e. the topology of the entire > network) since NLSR is a link-state routing protocol. If the network has > converged, all the LSDBs should be the same. Every LSA is signed by its > originator and can be verified using a trust model to make sure that the > LSA is indeed originated by that origin router. This is a security benefit > provided by NDN?s data-centric security model. Is this what you mean by > ?this synchronization of same LSDB in the entire network helps in > security"? > > Lan > > On Jul 18, 2016, at 9:25 AM, Tanusree Chatterjee < > tnsr.chatterjee at gmail.com> wrote: > > Hi all, > One thing I could not be sure about that whether all the nodes in the > network have the common LSDB? If so, all the nodes have the idea of > topology of the entire network? If NLSR is concerned, so this > synchronization of same LSDB in the entire network helps in security also? > > 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 omarilias.elmimouni at nist.gov Wed Jul 20 13:16:23 2016 From: omarilias.elmimouni at nist.gov (El Mimouni, Omar Ilias (IntlAssoc)) Date: Wed, 20 Jul 2016 20:16:23 +0000 Subject: [Ndn-interest] (NDN-js) query localhost from browser? Message-ID: Hi all, I am currently playing with NDN-js library, and I was wondering if it is possible to query the localhost (e.g. ndn:/localhost/nfd/faces/list) . I could do that with node using UnixSocket. Is it possible to do it from a browser (knowing that the browser uses WebSockets) ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefft0 at remap.ucla.edu Wed Jul 20 13:25:27 2016 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Wed, 20 Jul 2016 20:25:27 +0000 Subject: [Ndn-interest] (NDN-js) query localhost from browser? Message-ID: See the example test-list-faces: https://github.com/named-data/ndn-js/blob/master/examples/browser/test-list-faces.html - Jeff T From: Ndn-interest > on behalf of "El Mimouni, Omar Ilias (IntlAssoc)" > Date: Wednesday, July 20, 2016 at 13:16:00 To: "ndn-interest at lists.cs.ucla.edu" > Subject: [Ndn-interest] (NDN-js) query localhost from browser? Hi all, I am currently playing with NDN-js library, and I was wondering if it is possible to query the localhost (e.g. ndn:/localhost/nfd/faces/list) . I could do that with node using UnixSocket. Is it possible to do it from a browser (knowing that the browser uses WebSockets) ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From agawande at memphis.edu Wed Jul 20 13:41:40 2016 From: agawande at memphis.edu (Ashlesh Gawande (agawande)) Date: Wed, 20 Jul 2016 20:41:40 +0000 Subject: [Ndn-interest] (NDN-js) query localhost from browser? In-Reply-To: References: Message-ID: I have tried that example and the browser does not get anything. NFD logs show that the interest for /localhost/nfd/faces/list is dropped due to scope violation. In https://github.com/named-data/ndn-js/blob/master/examples/browser/test-list-faces.html#L47 it says that a Unix socket is used to connect to the local forwarder, but nfd-status shows websocket. Ashlesh ________________________________ From: Ndn-interest on behalf of Thompson, Jeff Sent: Wednesday, July 20, 2016 3:25:27 PM To: El Mimouni, Omar Ilias (IntlAssoc); ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? See the example test-list-faces: https://github.com/named-data/ndn-js/blob/master/examples/browser/test-list-faces.html - Jeff T From: Ndn-interest > on behalf of "El Mimouni, Omar Ilias (IntlAssoc)" > Date: Wednesday, July 20, 2016 at 13:16:00 To: "ndn-interest at lists.cs.ucla.edu" > Subject: [Ndn-interest] (NDN-js) query localhost from browser? Hi all, I am currently playing with NDN-js library, and I was wondering if it is possible to query the localhost (e.g. ndn:/localhost/nfd/faces/list) . I could do that with node using UnixSocket. Is it possible to do it from a browser (knowing that the browser uses WebSockets) ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefft0 at remap.UCLA.edu Wed Jul 20 13:55:39 2016 From: jefft0 at remap.UCLA.edu (Thompson, Jeff) Date: Wed, 20 Jul 2016 20:55:39 +0000 Subject: [Ndn-interest] (NDN-js) query localhost from browser? In-Reply-To: References: Message-ID: See inline below. From: "Ashlesh Gawande (agawande)" > Date: Wednesday, July 20, 2016 at 13:41:00 I have tried that example and the browser does not get anything. NFD logs show that the interest for /localhost/nfd/faces/list is dropped due to scope violation. Is your nfd.conf modified from /usr/local/etc/ndn/nfd.conf.sample , especially in the websocket section? In https://github.com/named-data/ndn-js/blob/master/examples/browser/test-list-faces.html#L47 it says that a Unix socket is used to connect to the local forwarder, but nfd-status shows websocket. Whoopsie! (That?s a typo from copying from the Node.js example.) You?re right. it connects with WebSocket. I fixed the comment. Thanks, - Jeff T From: Ndn-interest > on behalf of Thompson, Jeff > Sent: Wednesday, July 20, 2016 3:25:27 PM To: El Mimouni, Omar Ilias (IntlAssoc); ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? See the example test-list-faces: https://github.com/named-data/ndn-js/blob/master/examples/browser/test-list-faces.html - Jeff T From: Ndn-interest > on behalf of "El Mimouni, Omar Ilias (IntlAssoc)" > Date: Wednesday, July 20, 2016 at 13:16:00 To: "ndn-interest at lists.cs.ucla.edu" > Subject: [Ndn-interest] (NDN-js) query localhost from browser? Hi all, I am currently playing with NDN-js library, and I was wondering if it is possible to query the localhost (e.g. ndn:/localhost/nfd/faces/list) . I could do that with node using UnixSocket. Is it possible to do it from a browser (knowing that the browser uses WebSockets) ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From agawande at memphis.edu Wed Jul 20 14:11:22 2016 From: agawande at memphis.edu (Ashlesh Gawande (agawande)) Date: Wed, 20 Jul 2016 21:11:22 +0000 Subject: [Ndn-interest] (NDN-js) query localhost from browser? In-Reply-To: References: , Message-ID: nfd.conf is same as nfd.conf.sample. I have confirmed the scope violation issue by disabling scope checking in NFD. (Commented out lines 116, 227, 320, 406 in daemon/fw/forwarder.cpp.) Then the browser gets the data. Ashlesh ________________________________ From: Thompson, Jeff Sent: Wednesday, July 20, 2016 3:55 PM To: Ashlesh Gawande (agawande); El Mimouni, Omar Ilias (IntlAssoc); ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? See inline below. From: "Ashlesh Gawande (agawande)" > Date: Wednesday, July 20, 2016 at 13:41:00 I have tried that example and the browser does not get anything. NFD logs show that the interest for /localhost/nfd/faces/list is dropped due to scope violation. Is your nfd.conf modified from /usr/local/etc/ndn/nfd.conf.sample , especially in the websocket section? In https://github.com/named-data/ndn-js/blob/master/examples/browser/test-list-faces.html#L47 it says that a Unix socket is used to connect to the local forwarder, but nfd-status shows websocket. Whoopsie! (That's a typo from copying from the Node.js example.) You're right. it connects with WebSocket. I fixed the comment. Thanks, - Jeff T From: Ndn-interest > on behalf of Thompson, Jeff > Sent: Wednesday, July 20, 2016 3:25:27 PM To: El Mimouni, Omar Ilias (IntlAssoc); ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? See the example test-list-faces: https://github.com/named-data/ndn-js/blob/master/examples/browser/test-list-faces.html - Jeff T From: Ndn-interest > on behalf of "El Mimouni, Omar Ilias (IntlAssoc)" > Date: Wednesday, July 20, 2016 at 13:16:00 To: "ndn-interest at lists.cs.ucla.edu" > Subject: [Ndn-interest] (NDN-js) query localhost from browser? Hi all, I am currently playing with NDN-js library, and I was wondering if it is possible to query the localhost (e.g. ndn:/localhost/nfd/faces/list) . I could do that with node using UnixSocket. Is it possible to do it from a browser (knowing that the browser uses WebSockets) ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nfd.conf Type: application/octet-stream Size: 11735 bytes Desc: nfd.conf URL: From jefft0 at remap.UCLA.edu Wed Jul 20 14:15:15 2016 From: jefft0 at remap.UCLA.edu (Thompson, Jeff) Date: Wed, 20 Jul 2016 21:15:15 +0000 Subject: [Ndn-interest] (NDN-js) query localhost from browser? In-Reply-To: References: Message-ID: NFD team, any suggestions on scope violation connecting to WebSocket locally? From: "Ashlesh Gawande (agawande)" > Date: Wednesday, July 20, 2016 at 14:11:00 To: Jeff Thompson >, "El Mimouni, Omar Ilias (IntlAssoc)" >, "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? nfd.conf is same as nfd.conf.sample. I have confirmed the scope violation issue by disabling scope checking in NFD. (Commented out lines 116, 227, 320, 406 in daemon/fw/forwarder.cpp.) Then the browser gets the data. Ashlesh ________________________________ From: Thompson, Jeff > Sent: Wednesday, July 20, 2016 3:55 PM To: Ashlesh Gawande (agawande); El Mimouni, Omar Ilias (IntlAssoc); ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? See inline below. From: "Ashlesh Gawande (agawande)" > Date: Wednesday, July 20, 2016 at 13:41:00 I have tried that example and the browser does not get anything. NFD logs show that the interest for /localhost/nfd/faces/list is dropped due to scope violation. Is your nfd.conf modified from /usr/local/etc/ndn/nfd.conf.sample , especially in the websocket section? In https://github.com/named-data/ndn-js/blob/master/examples/browser/test-list-faces.html#L47 it says that a Unix socket is used to connect to the local forwarder, but nfd-status shows websocket. Whoopsie! (That?s a typo from copying from the Node.js example.) You?re right. it connects with WebSocket. I fixed the comment. Thanks, - Jeff T From: Ndn-interest > on behalf of Thompson, Jeff > Sent: Wednesday, July 20, 2016 3:25:27 PM To: El Mimouni, Omar Ilias (IntlAssoc); ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? See the example test-list-faces: https://github.com/named-data/ndn-js/blob/master/examples/browser/test-list-faces.html - Jeff T From: Ndn-interest > on behalf of "El Mimouni, Omar Ilias (IntlAssoc)" > Date: Wednesday, July 20, 2016 at 13:16:00 To: "ndn-interest at lists.cs.ucla.edu" > Subject: [Ndn-interest] (NDN-js) query localhost from browser? Hi all, I am currently playing with NDN-js library, and I was wondering if it is possible to query the localhost (e.g. ndn:/localhost/nfd/faces/list) . I could do that with node using UnixSocket. Is it possible to do it from a browser (knowing that the browser uses WebSockets) ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrchwdhr at memphis.edu Wed Jul 20 14:43:53 2016 From: mrchwdhr at memphis.edu (Muktadir R Chowdhury (mrchwdhr)) Date: Wed, 20 Jul 2016 21:43:53 +0000 Subject: [Ndn-interest] (NDN-js) query localhost from browser? In-Reply-To: References: , Message-ID: The example works on my Mac OSX, but did not work on Ubuntu 14.04 (VM). Ashlesh was also using Ubuntu 14.04 that's why he is also not getting any data back. Muktadir ________________________________ From: Ndn-interest on behalf of Thompson, Jeff Sent: Thursday, July 21, 2016 3:15:15 AM To: Ashlesh Gawande (agawande); El Mimouni, Omar Ilias (IntlAssoc); ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? NFD team, any suggestions on scope violation connecting to WebSocket locally? From: "Ashlesh Gawande (agawande)" > Date: Wednesday, July 20, 2016 at 14:11:00 To: Jeff Thompson >, "El Mimouni, Omar Ilias (IntlAssoc)" >, "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? nfd.conf is same as nfd.conf.sample. I have confirmed the scope violation issue by disabling scope checking in NFD. (Commented out lines 116, 227, 320, 406 in daemon/fw/forwarder.cpp.) Then the browser gets the data. Ashlesh ________________________________ From: Thompson, Jeff > Sent: Wednesday, July 20, 2016 3:55 PM To: Ashlesh Gawande (agawande); El Mimouni, Omar Ilias (IntlAssoc); ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? See inline below. From: "Ashlesh Gawande (agawande)" > Date: Wednesday, July 20, 2016 at 13:41:00 I have tried that example and the browser does not get anything. NFD logs show that the interest for /localhost/nfd/faces/list is dropped due to scope violation. Is your nfd.conf modified from /usr/local/etc/ndn/nfd.conf.sample , especially in the websocket section? In https://github.com/named-data/ndn-js/blob/master/examples/browser/test-list-faces.html#L47 it says that a Unix socket is used to connect to the local forwarder, but nfd-status shows websocket. Whoopsie! (That?s a typo from copying from the Node.js example.) You?re right. it connects with WebSocket. I fixed the comment. Thanks, - Jeff T From: Ndn-interest > on behalf of Thompson, Jeff > Sent: Wednesday, July 20, 2016 3:25:27 PM To: El Mimouni, Omar Ilias (IntlAssoc); ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? See the example test-list-faces: https://github.com/named-data/ndn-js/blob/master/examples/browser/test-list-faces.html - Jeff T From: Ndn-interest > on behalf of "El Mimouni, Omar Ilias (IntlAssoc)" > Date: Wednesday, July 20, 2016 at 13:16:00 To: "ndn-interest at lists.cs.ucla.edu" > Subject: [Ndn-interest] (NDN-js) query localhost from browser? Hi all, I am currently playing with NDN-js library, and I was wondering if it is possible to query the localhost (e.g. ndn:/localhost/nfd/faces/list) . I could do that with node using UnixSocket. Is it possible to do it from a browser (knowing that the browser uses WebSockets) ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Jul 20 14:46:40 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 20 Jul 2016 14:46:40 -0700 Subject: [Ndn-interest] (NDN-js) query localhost from browser? In-Reply-To: References: Message-ID: Hi Omar This should be possible. You have to connect to NFD on the local machine with a loopback address, either ws://127.0.0.1:9696/ or ws://[::1]:9696/ , in order to be treated as a local face. Yours, Junxiao On Jul 20, 2016 13:17, "El Mimouni, Omar Ilias (IntlAssoc)" < omarilias.elmimouni at nist.gov> wrote: > Hi all, > > > > I am currently playing with NDN-js library, and I was wondering if it is > possible to query the localhost (e.g. *ndn:/localhost/nfd/faces/list*) . > > I could do that with node using UnixSocket. Is it possible to do it from a > browser (knowing that the browser uses WebSockets) ? > > > > Thanks. > > _______________________________________________ > 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 cwang1 at umass.edu Wed Jul 20 20:02:51 2016 From: cwang1 at umass.edu (Cong Wang) Date: Thu, 21 Jul 2016 03:02:51 +0000 Subject: [Ndn-interest] Error for installing NDN-CPP Message-ID: <4D886DFF-9EC0-4677-94FC-51D9452AE2D9@ads.umass.edu> Hello, I?m trying to install ndn-cpp following the instructions on this github page: https://github.com/named-data/ndn-cpp https://github.com/named-data/ndn-cpp/blob/master/INSTALL.md I?ve installed all the dependencies, and was able to successfully do ./configure, however, I got some errors for ?make?. Makefile:3749: recipe for target 'src/encrypt/consumer.lo' failed make[1]: Leaving directory '/home/cong/work/ndn-cpp' Makefile:3826: recipe for target 'all-recursive' failed I tried the installation on Ubuntu 14.04 and 16.04 but the error still persists. The configure and make logs are attached below. Did I miss anything here? Thank you very much! Cong -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: configure-log.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: make.log Type: application/octet-stream Size: 62927 bytes Desc: make.log URL: From s.h.ahmed at ieee.org Thu Jul 21 00:18:13 2016 From: s.h.ahmed at ieee.org (Syed Hassan Ahmed) Date: Thu, 21 Jul 2016 16:18:13 +0900 Subject: [Ndn-interest] Basic Query about Dual Names for one Content Message-ID: Respected NDN Community, Can we have two names for one Content? Let's say, we consider heterogeneous naming schemes, that have been applied at two different locations (X, Y) and the nodes are mobile (lets say Vehicles). Now when a node from location X moves into the range of location Y? How the NDN router/node resolves this issue? May be my question is a bit ambitious, however, I believe that one content can have multiple names. I understand the concept of NONCE somehow, but NONCE can be applied to two different names for the same content? Best Regards, ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ *Syed Hassan Ahmed *(??) Kyungpook National University, Daegu City, Republic of Korea. Cell: +82-10-9883-0786 https://sites.google.com/site/shahmedknu/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Thu Jul 21 00:33:32 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Thu, 21 Jul 2016 09:33:32 +0200 Subject: [Ndn-interest] Basic Query about Dual Names for one Content In-Reply-To: References: Message-ID: Just to be clear. There is content (payload) and there is a data packet that carries a payload. A data packet is unique and has a unique name. The same content can be carried in different data packets that can have different names, meta information, and signatures. If there are two producers that can serve data packets under the same prefix, then forwarding system can choose either of them. If data cannot be retrieved from one, the forwarding may try alternative path. In my opinion, if an application is designed properly, different producers will use different names for their data. They can use the common prefix and be alternative suppliers of the data with the common prefix, but there has to be a way to retrieve (identify) a specific piece of data from a specific producer. I'm not sure which nonce you're referring to. If you're talking about nonce in interest packets, then it is used for completely different purpose and not related to data packets. --- Alex > On Jul 21, 2016, at 9:18 AM, Syed Hassan Ahmed wrote: > > Respected NDN Community, > > Can we have two names for one Content? Let's say, we consider heterogeneous naming schemes, that have been applied at two different locations (X, Y) and the nodes are mobile (lets say Vehicles). Now when a node from location X moves into the range of location Y? How the NDN router/node resolves this issue? May be my question is a bit ambitious, however, I believe that one content can have multiple names. I understand the concept of NONCE somehow, but NONCE can be applied to two different names for the same content? > > > Best Regards, > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Syed Hassan Ahmed (??) > Kyungpook National University, > Daegu City, Republic of Korea. > Cell: +82-10-9883-0786 > https://sites.google.com/site/shahmedknu/ -------------- 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 lixia at CS.UCLA.EDU Thu Jul 21 00:34:33 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Thu, 21 Jul 2016 00:34:33 -0700 Subject: [Ndn-interest] Basic Query about Dual Names for one Content In-Reply-To: References: Message-ID: > On Jul 21, 2016, at 12:18 AM, Syed Hassan Ahmed wrote: > > Respected NDN Community, > > Can we have two names for one Content? Let's say, we consider heterogeneous naming schemes, that have been applied at two different locations (X, Y) and the nodes are mobile (lets say Vehicles). Now when a node from location X moves into the range of location Y? How the NDN router/node resolves this issue? May be my question is a bit ambitious, however, I believe that one content can have multiple names. I understand the concept of NONCE somehow, but NONCE can be applied to two different names for the same content? 1/ yes a single piece of content can have multiple names. However every name should name a unique piece of content. 2/ There can be applications that name content based on locations. generally speaking, content names are not location-specific. 3/ in your above example: do vehicles X and Y carry an identical piece of content? If so, that content can have its own name, independent from the locations of X or Y, there is no issue whether X and Y are far apart or close to each other (this could lead you to a different question: if a name is not location-dependent, how NDN forwarders find the content: some discussions here: http://named-data.net/publications/survey_mobility_support_ndn/ ) 4/ "nonce" is not relevant to the above discussions; it's used to mitigate interest looping. my 2 cents, Lixia -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.h.ahmed at ieee.org Thu Jul 21 01:16:11 2016 From: s.h.ahmed at ieee.org (Syed Hassan Ahmed) Date: Thu, 21 Jul 2016 17:16:11 +0900 Subject: [Ndn-interest] Basic Query about Dual Names for one Content In-Reply-To: References: Message-ID: Thanks Dr. Alex and Prof. Lixia for the replies that actually helped me in reshaping my query. I am foreseeing an example scenario, where we have a vehicle (c) moving from San Francisco (location X) to Los Angeles (location Y). Now in this new city, a user wants to watch the recent news bulletin on his/her vehicle On Board Unit screen. Previously, at location X, the vehicle (c) was using hierarchical naming prefixes in the Interest packet to look up and retrieve the content, for example: Unique NONCE: vid/sf/breakingnews/date/10pm/chunk ID... (Interest Type 1) Now quoting Dr. Alex, "If there are two producers that can serve data packets under the same prefix, then forwarding system can choose either of them. If data cannot be retrieved from one, the forwarding may try alternative path." Will it be okay to assume that globally the name prefixes will be identical? For example, at Location Y, the local users are using the following prefix to retrieve the same content, Unique NONCE: vid/sf/breakingnews/date/2200/chunk ID... (Interest Type 2) Since the vehicle (c) is not aware of this changed prefix, how it can be the provider of this content/chunk? Somehow, this vehicle needs to be informed about the changed pattern of content prefix. Is the responsibility of application then? I see this example, as two different name prefixes for the same content. When this vehicle receives an Interest of Type 2 with a unique Nonce Value {to avoid Interest Looping}, due to a different presentation of Time or any information within the prefix, vehicle (c) will not be able to forward the required Data. If it would be, how? Best Regards, ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ *Syed Hassan Ahmed *(??) Kyungpook National University, Daegu City, Republic of Korea. Cell: +82-10-9883-0786 https://sites.google.com/site/shahmedknu/ On Thu, Jul 21, 2016 at 4:34 PM, Lixia Zhang wrote: > > On Jul 21, 2016, at 12:18 AM, Syed Hassan Ahmed > wrote: > > Respected NDN Community, > > Can we have two names for one Content? Let's say, we consider > heterogeneous naming schemes, that have been applied at two different > locations (X, Y) and the nodes are mobile (lets say Vehicles). Now when a > node from location X moves into the range of location Y? How the NDN > router/node resolves this issue? May be my question is a bit ambitious, > however, I believe that one content can have multiple names. I understand > the concept of NONCE somehow, but NONCE can be applied to two different > names for the same content? > > > 1/ yes a single piece of content can have multiple names. > However every name should name a unique piece of content. > > 2/ There can be applications that name content based on locations. > generally speaking, content names are not location-specific. > > 3/ in your above example: do vehicles X and Y carry an identical piece of > content? > If so, that content can have its own name, independent from the locations > of X or Y, there is no issue whether X and Y are far apart or close to each > other (this could lead you to a different question: if a name is not > location-dependent, how NDN forwarders find the content: some discussions > here: http://named-data.net/publications/survey_mobility_support_ndn/) > > 4/ "nonce" is not relevant to the above discussions; it's used to mitigate > interest looping. > > my 2 cents, > Lixia > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Jul 21 03:39:10 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 21 Jul 2016 03:39:10 -0700 Subject: [Ndn-interest] Basic Query about Dual Names for one Content Message-ID: Hi Syed A properly designed application should use a consistent naming scheme to access the same content. Choose one of "10pm" and "2200", and stick to it. If the content is published under two different names, but the network is not aware of this situation, in-network caching would be ineffective when the Interest carries a different name. If the data mule (vehicle) knows the dual name situation, it could respond to "2200" Interest with "10pm" Data through encapsulation; Data /vid/sf/breakingnews/20151231/2200/%00%00 Content=Data /vid/sf/breakingnews/20151231/10pm/%00%00 Content=news headlines signed by breakingnews.com signed by vehicle Encapsulation is necessary because Interest name must be a prefix of Data name, but breakingnews.com signature is bound to the "10pm" name and the vehicle does not have breakingnews.com signing key. Or the response could use redirection: Data /vid/sf/breakingnews/20151231/2200/%00%00 Content=REDIRECT to /vid/sf/breakingnews/20151231/10pm/%00%00 signed by vehicle Upon receiving this response, the consumer should reexpress the Interest with "10pm" name. Yours, Junxiao On Thu, Jul 21, 2016 at 1:16 AM, Syed Hassan Ahmed wrote: > Thanks Dr. Alex and Prof. Lixia for the replies that actually helped me in > reshaping my query. > > I am foreseeing an example scenario, where we have a vehicle (c) moving > from San Francisco (location X) to Los Angeles (location Y). Now in this > new city, a user wants to watch the recent news bulletin on his/her vehicle > On Board Unit screen. Previously, at location X, the vehicle (c) was using > hierarchical naming prefixes in the Interest packet to look up and retrieve > the content, for example: > > Unique NONCE: vid/sf/breakingnews/date/10pm/chunk ID... (Interest Type 1) > > Now quoting Dr. Alex, "If there are two producers that can serve data > packets under the same prefix, then forwarding system can choose either of > them. If data cannot be retrieved from one, the forwarding may try > alternative path." > Will it be okay to assume that globally the name prefixes will be > identical? For example, at Location Y, the local users are using the > following prefix to retrieve the same content, > > Unique NONCE: vid/sf/breakingnews/date/2200/chunk ID... (Interest Type 2) > > Since the vehicle (c) is not aware of this changed prefix, how it can be > the provider of this content/chunk? Somehow, this vehicle needs to be > informed about the changed pattern of content prefix. Is the responsibility > of application then? I see this example, as two different name prefixes for > the same content. > > When this vehicle receives an Interest of Type 2 with a unique Nonce Value > {to avoid Interest Looping}, due to a different presentation of Time or any > information within the prefix, vehicle (c) will not be able to forward the > required Data. If it would be, how? > > > > Best Regards, > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > *Syed Hassan Ahmed *(??) > Kyungpook National University, > Daegu City, Republic of Korea. > Cell: +82-10-9883-0786 > https://sites.google.com/site/shahmedknu/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omarilias.elmimouni at nist.gov Thu Jul 21 07:46:49 2016 From: omarilias.elmimouni at nist.gov (El Mimouni, Omar Ilias (IntlAssoc)) Date: Thu, 21 Jul 2016 14:46:49 +0000 Subject: [Ndn-interest] (NDN-js) query localhost from browser? In-Reply-To: References: Message-ID: Hi Junxiao, First, in my html file I had: var face = new Face({host: "127.0.0.1"}); Now, based on your reply, I changed it to this: var ws = new WebSocket("ws://127.0.0.1:9696"); var face = new Face(ws); But still not working!!! In the web page I receive a timeout (Time out for interest /localhost/nfd/faces/list). And in NFD log: 1469111817.516596 INFO: [WebSocketTransport] [id=0,local=ws://[::ffff:127.0.0.1]:9696,remote=wsclient://[::ffff:127.0.0.1]:56256] Creating transport 1469111817.516618 INFO: [FaceTable] Added face id=259 remote=wsclient://[::ffff:127.0.0.1]:56256 local=ws://[::ffff:127.0.0.1]:9696 Cheers, Omar From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu] Sent: Wednesday, July 20, 2016 5:47 PM To: El Mimouni, Omar Ilias (IntlAssoc) Cc: ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] (NDN-js) query localhost from browser? Hi Omar This should be possible. You have to connect to NFD on the local machine with a loopback address, either ws://127.0.0.1:9696/ or ws://[::1]:9696/ , in order to be treated as a local face. Yours, Junxiao On Jul 20, 2016 13:17, "El Mimouni, Omar Ilias (IntlAssoc)" > wrote: Hi all, I am currently playing with NDN-js library, and I was wondering if it is possible to query the localhost (e.g. ndn:/localhost/nfd/faces/list) . I could do that with node using UnixSocket. Is it possible to do it from a browser (knowing that the browser uses WebSockets) ? Thanks. _______________________________________________ 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 andrew.brown at intel.com Thu Jul 21 08:56:40 2016 From: andrew.brown at intel.com (Brown, Andrew) Date: Thu, 21 Jul 2016 15:56:40 +0000 Subject: [Ndn-interest] Basic Query about Dual Names for one Content In-Reply-To: References: Message-ID: All, I am very interested in multiple names per data packet: for some time, I have wanted to produce one piece of data (e.g. a temperature reading), but consume it under multiple namespaces (e.g. /temp/[sensor id]/[timestamp] and /temp/[timestamp])-the point is that multiple sensors could produce simultaneously but a consumer could choose to retrieve either the latest sensor-specific reading (e.g. /temp/[sensor id]?ChildSelector=RightMost) or the latest global reading (/temp?ChildSelector=RightMost). I cannot do this in the current implementation: I must register both prefixes and generate packets for both types of requests. I can think of a couple of mechanisms that would be helpful (e.g. a field on the data packet for additional names, interest selectors that work on more than the last component) but are there architectural reasons that this can't or shouldn't be done? I originally thought the LINK mechanism would allow this but I don't think it does. Sincerely, Andrew Brown IoTG Strategy and Integrated Products Cell: 360-292-5859 From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Lixia Zhang Sent: Thursday, July 21, 2016 12:35 AM To: Syed Hassan Ahmed Cc: ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] Basic Query about Dual Names for one Content On Jul 21, 2016, at 12:18 AM, Syed Hassan Ahmed > wrote: Respected NDN Community, Can we have two names for one Content? Let's say, we consider heterogeneous naming schemes, that have been applied at two different locations (X, Y) and the nodes are mobile (lets say Vehicles). Now when a node from location X moves into the range of location Y? How the NDN router/node resolves this issue? May be my question is a bit ambitious, however, I believe that one content can have multiple names. I understand the concept of NONCE somehow, but NONCE can be applied to two different names for the same content? 1/ yes a single piece of content can have multiple names. However every name should name a unique piece of content. 2/ There can be applications that name content based on locations. generally speaking, content names are not location-specific. 3/ in your above example: do vehicles X and Y carry an identical piece of content? If so, that content can have its own name, independent from the locations of X or Y, there is no issue whether X and Y are far apart or close to each other (this could lead you to a different question: if a name is not location-dependent, how NDN forwarders find the content: some discussions here: http://named-data.net/publications/survey_mobility_support_ndn/) 4/ "nonce" is not relevant to the above discussions; it's used to mitigate interest looping. my 2 cents, Lixia -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7562 bytes Desc: not available URL: From s.h.ahmed at ieee.org Thu Jul 21 09:26:58 2016 From: s.h.ahmed at ieee.org (Syed Hassan Ahmed) Date: Fri, 22 Jul 2016 01:26:58 +0900 Subject: [Ndn-interest] Basic Query about Dual Names for one Content In-Reply-To: References: Message-ID: ?Dear Prof. Junxiao, Thanks for the detailed explanation. I understood the encapsulation idea, however, your very last comment is basically endorsing my query, where, the appearance of two prefixes may occur for the same content, the consumer has to send Interest two times. Because upon the first Interest Type 1 (referring my previous email), the consumer couldn't retrieve the required content, but it has been informed (redirected) to retransmit Interest with the valid Name prefix... 1. Now here jumps in the attacker? Or Malicious Node? What is the security aspect in this case? 2. Why would a consumer believe this publisher's intention? If the redirecting message is only signed by the vehicle? 3. And through what medium/face this Redirection information will be passed? I mean, in a pull based manner, the producer only sends Data, if the prefix matches, otherwise, forwarding Daemon gets active for that Interest and takes decision depending on the strategy, of course. Is there any scheme or architectural discussion available, where, two prefixes are used for same content or chunk level retrieval. ? Dear Andrew Brown, Thanks for your response. Tell me if I am wrong, I understand your example, as we have sensors installed for lets say Temperature Monitoring, and by sending an Interest, you want to retrieve sensed information from either specific sensor or generally from any sensor. I think, if the former case, if some other consumer has already requested the device specific readings and it is cached in the nearby router, so you will get it retrieved by sending the first prefix that you mentioned. Also, I agree that in the latter case, you have to have two prefixes and even though the reading is identical, but since in the first case, you are being device specific and in the second, you aren't.. As per current NDN, I can't find the other solutions for such case other than application sophistication level. Best Regards, ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ *Syed Hassan Ahmed *(??) Kyungpook National University, Daegu City, Republic of Korea. Cell: +82-10-9883-0786 https://sites.google.com/site/shahmedknu/ On Fri, Jul 22, 2016 at 12:56 AM, Brown, Andrew wrote: > All, > > > > I am very interested in multiple names per data packet: for some time, I > have wanted to produce one piece of data (e.g. a temperature reading), but > consume it under multiple namespaces (e.g. /temp/[sensor id]/[timestamp] > and /temp/[timestamp])?the point is that multiple sensors could produce > simultaneously but a consumer could choose to retrieve either the latest > sensor-specific reading (e.g. /temp/[sensor id]?ChildSelector=RightMost) or > the latest global reading (/temp?ChildSelector=RightMost). I cannot do this > in the current implementation: I must register both prefixes and generate > packets for both types of requests. I can think of a couple of mechanisms > that would be helpful (e.g. a field on the data packet for additional > names, interest selectors that work on more than the last component) but > are there architectural reasons that this can?t or shouldn?t be done? I > originally thought the LINK mechanism would allow this but I don?t think it > does. > > > > Sincerely, > > > > Andrew Brown > > IoTG Strategy and Integrated Products > > Cell: 360-292-5859 > > > > *From:* Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] *On > Behalf Of *Lixia Zhang > *Sent:* Thursday, July 21, 2016 12:35 AM > *To:* Syed Hassan Ahmed > *Cc:* ndn-interest at lists.cs.ucla.edu > *Subject:* Re: [Ndn-interest] Basic Query about Dual Names for one Content > > > > > > On Jul 21, 2016, at 12:18 AM, Syed Hassan Ahmed > wrote: > > > > Respected NDN Community, > > > > Can we have two names for one Content? Let's say, we consider > heterogeneous naming schemes, that have been applied at two different > locations (X, Y) and the nodes are mobile (lets say Vehicles). Now when a > node from location X moves into the range of location Y? How the NDN > router/node resolves this issue? May be my question is a bit ambitious, > however, I believe that one content can have multiple names. I understand > the concept of NONCE somehow, but NONCE can be applied to two different > names for the same content? > > > > 1/ yes a single piece of content can have multiple names. > > However every name should name a unique piece of content. > > > > 2/ There can be applications that name content based on locations. > > generally speaking, content names are not location-specific. > > > > 3/ in your above example: do vehicles X and Y carry an identical piece of > content? > > If so, that content can have its own name, independent from the locations > of X or Y, there is no issue whether X and Y are far apart or close to each > other (this could lead you to a different question: if a name is not > location-dependent, how NDN forwarders find the content: some discussions > here: http://named-data.net/publications/survey_mobility_support_ndn/) > > > > 4/ "nonce" is not relevant to the above discussions; it's used to mitigate > interest looping. > > > > my 2 cents, > > Lixia > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Jul 21 10:26:40 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 21 Jul 2016 10:26:40 -0700 Subject: [Ndn-interest] Basic Query about Dual Names for one Content In-Reply-To: References: Message-ID: <579105d0.86a2420a.f18b1.0458@mx.google.com> Hi Syed Upon learning the correct prefix ?10pm?, the consumer has to send a second Interest with ?10pm?. For all subsequent segments, the consumer can directly send ?10pm? Interests without first expressing a ?2200? Interest and getting a redirection. The redirection can be in the form of a Link object, as seen in SNAMP paper. Data /vid/sf/breakingnews/20151231/2200/%00%00 ? Content=REDIRECT to /vid/sf/breakingnews/20151231/10pm/%00%00 Link /vid/sf/breakingnews/20151231/10pm => /vid/sf/breakingnews/20151231/2200 signed by breakingnews.com ? signed by vehicle However, this implies the Link object needs to be prepared by the original publisher. A producer application must have registered a prefix in the local forwarder to receive the Interest, and construct the Data with redirection when an Interest arrives. ContentStore cannot handle it. Therefore, the best solution is still: make sure the naming scheme is consistent. Yours, Junxiao From: Syed Hassan Ahmed -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanwang at memphis.edu Thu Jul 21 15:56:04 2016 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Thu, 21 Jul 2016 22:56:04 +0000 Subject: [Ndn-interest] Same LSDB in entire network? In-Reply-To: References: <4184E115-31E2-4189-803C-2CB2C517862A@memphis.edu> Message-ID: <6132A8B5-6545-444B-B8A5-00B3B2A97A3E@memphis.edu> Having the same set of LSAs is simply an algorithmic requirement for routing convergence. What specific security threat do you see this prevents? Lan On Jul 19, 2016, at 10:54 AM, Tanusree Chatterjee > wrote: Thanks for the response. By security, I also meant the digest tree maintained by all the nodes (last version of NLSR) in the entire network must be same as they exchange the root digest while sending interest periodically to each other. So, to do the same each node in the entire network must have the common LSDB. As a simple scenario of 5 nodes I was running in mini ndn emulator, the nlsrc status of all nodes show the same LSDB, which consists of all the LSAs of each node in the network. On Jul 19, 2016 7:09 PM, "Lan Wang (lanwang)" > wrote: Tanusree, Every node in NLSR maintains an LSDB (i.e. the topology of the entire network) since NLSR is a link-state routing protocol. If the network has converged, all the LSDBs should be the same. Every LSA is signed by its originator and can be verified using a trust model to make sure that the LSA is indeed originated by that origin router. This is a security benefit provided by NDN?s data-centric security model. Is this what you mean by ?this synchronization of same LSDB in the entire network helps in security"? Lan On Jul 18, 2016, at 9:25 AM, Tanusree Chatterjee > wrote: Hi all, One thing I could not be sure about that whether all the nodes in the network have the common LSDB? If so, all the nodes have the idea of topology of the entire network? If NLSR is concerned, so this synchronization of same LSDB in the entire network helps in security also? 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 tailinchu at gmail.com Sun Jul 24 08:10:28 2016 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Sun, 24 Jul 2016 08:10:28 -0700 Subject: [Ndn-interest] Basic Query about Dual Names for one Content In-Reply-To: <579105d0.86a2420a.f18b1.0458@mx.google.com> References: <579105d0.86a2420a.f18b1.0458@mx.google.com> Message-ID: Hi, Syed and Junxiao, We experimented with LINK for a while. It works fine but there is a cost in managing LINKs, and its overhead (packet size and signing/verification) is high. As a result, we explored another solution on top of NDN. The idea is to have a set of dedicated nodes for distribution (this also tries to improve data availability). First, when producer publishes data, it also specifies possible name aliases (and some other things) in the content field of data packet. Second, producer tries to push the ?higher-level? data packet to the raft leader of the dedicated distribution nodes, and the leader replicates it to other nodes according to the raft consensus protocol. Third, these dedicated distribution nodes ?compile? one higher-level data packet to many data packets (with various name alias, signature types, etc) when it is received. This idea solves the availability problem, so producer can be off sometimes. For example, a sensor could use this to save power, without worrying that cache eviction and sleeping might make its data unavailable. In addition to improving availability, higher-level data packet makes producing data simpler. A producer only needs to publish one data packet, and the packet can be compiled with different signature types, and name hierarchies for consumers with various needs. In general, I think it is hard for ndn applications to pick only one name hierarchy. In order to embed application design in one name hierarchy, we often make significant compromises, but it should not be necessary to. Finally, this is more efficient because there are less signatures to sign and verify. In many use cases, this idea is like flattening data packet with LINK. I wonder there are some other improvements to publishing with different names. I am open to discuss more. On Thu, Jul 21, 2016 at 10:26 AM, Junxiao Shi wrote: > Hi Syed > > > > Upon learning the correct prefix ?10pm?, the consumer has to send a second > Interest with ?10pm?. For all subsequent segments, the consumer can directly > send ?10pm? Interests without first expressing a ?2200? Interest and getting > a redirection. > > > > The redirection can be in the form of a Link object, as seen in SNAMP paper. > > Data /vid/sf/breakingnews/20151231/2200/%00%00 > > Content=REDIRECT to /vid/sf/breakingnews/20151231/10pm/%00%00 > > Link /vid/sf/breakingnews/20151231/10pm > > => /vid/sf/breakingnews/20151231/2200 > > signed by breakingnews.com > > signed by vehicle > > However, this implies the Link object needs to be prepared by the original > publisher. > > > > A producer application must have registered a prefix in the local forwarder > to receive the Interest, and construct the Data with redirection when an > Interest arrives. ContentStore cannot handle it. > > Therefore, the best solution is still: make sure the naming scheme is > consistent. > > > > Yours, Junxiao > > > > From: Syed Hassan Ahmed > Sent: Thursday, July 21, 2016 09:27 > To: Brown, Andrew > Cc: ndn-interest at lists.cs.ucla.edu > Subject: Re: [Ndn-interest] Basic Query about Dual Names for one Content > > > > Dear Prof. Junxiao, > > > > Thanks for the detailed explanation. I understood the encapsulation idea, > however, your very last comment is basically endorsing my query, where, the > appearance of two prefixes may occur for the same content, the consumer has > to send Interest two times. Because upon the first Interest Type 1 > (referring my previous email), the consumer couldn't retrieve the required > content, but it has been informed (redirected) to retransmit Interest with > the valid Name prefix... > > > > 1. Now here jumps in the attacker? Or Malicious Node? What is the security > aspect in this case? > > 2. Why would a consumer believe this publisher's intention? If the > redirecting message is only signed by the vehicle? > > 3. And through what medium/face this Redirection information will be passed? > I mean, in a pull based manner, the producer only sends Data, if the prefix > matches, otherwise, forwarding Daemon gets active for that Interest and > takes decision depending on the strategy, of course. > > > > Is there any scheme or architectural discussion available, where, two > prefixes are used for same content or chunk level retrieval. ? > > > > > > > > > > > > From: Junxiao Shi > Sent: Thursday, July 21, 2016 03:39 > To: Syed Hassan Ahmed > Cc: ndn-interest at lists.cs.ucla.edu > Subject: Re: [Ndn-interest] Basic Query about Dual Names for one Content > > > > Hi Syed > > > > A properly designed application should use a consistent naming scheme to > access the same content. Choose one of "10pm" and "2200", and stick to it. > > If the content is published under two different names, but the network is > not aware of this situation, in-network caching would be ineffective when > the Interest carries a different name. > > > > If the data mule (vehicle) knows the dual name situation, it could respond > to "2200" Interest with "10pm" Data through encapsulation; > > Data /vid/sf/breakingnews/20151231/2200/%00%00 > > Content=Data /vid/sf/breakingnews/20151231/10pm/%00%00 > > Content=news headlines > > signed by breakingnews.com > > signed by vehicle > > Encapsulation is necessary because Interest name must be a prefix of Data > name, but breakingnews.com signature is bound to the "10pm" name and the > vehicle does not have breakingnews.com signing key. > > Or the response could use redirection: > > Data /vid/sf/breakingnews/20151231/2200/%00%00 > > Content=REDIRECT to /vid/sf/breakingnews/20151231/10pm/%00%00 > > signed by vehicle > > Upon receiving this response, the consumer should reexpress the Interest > with "10pm" name. > > > > Yours, Junxiao > > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From s.h.ahmed at ieee.org Sun Jul 24 23:07:22 2016 From: s.h.ahmed at ieee.org (Syed Hassan Ahmed) Date: Mon, 25 Jul 2016 15:07:22 +0900 Subject: [Ndn-interest] Vehicular NDN: Recent Papers Message-ID: Dear NDN community Members, Hope this email finds you all in the best of your health and work. I am sharing some recent publications regarding vehicular NDN from our group: [1] ?CODIE: Controlled Data and Interest Evaluation in Vehicular Named Data Networks,? IEEE Transactions on Vehicular Technology, Volume 65 , Issue 6, pp. 3954 - 3963, June 2016. Link: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7460243 [2] ?SmartCop: Enabling Smart Traffic Violations Ticketing in Vehicular Named Data Networks,? Mobile Information Systems, May 2016. Link: http://www.hindawi.com/journals/misy/2016/1353290/ [3] "DPEL: Dynamic PIT Entry Lifetime in Vehicular Named Data Networks," IEEE Communications Letters, Vol. 20, No. 2, pp. 336-339, Feb 2016. Link: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7366558 [4] ?PDF: Push-based Data Forwarding in Vehicular NDN,? ACM Conference on Mobile Systems, Applications and Services (MobiSys), Singapore, June 2016. Link: http://dl.acm.org/citation.cfm?doid=2938559.2948818 [5] "Interest Forwarding in Vehicular Information Centric Networks: A Survey," ACM Symposium on Applied Computing, (ACM SAC), Pisa, Italy, April 2016. Link: http://dl.acm.org/citation.cfm?id=2851857 [6] "CONET: COntrolled Data Packets Propagation in Vehicular Named Data NETworks," IEEE CCNC, Las Vegas, USA, January 2016. Link: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7444850 [7] "Towards Content-Centric Traffic Ticketing in VANETs: An Application Perspective," The 3rd International Workshop on Intelligent Vehicles, Sapporo, Japan, July 2015. Link: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7182541 [8] "Evaluating Interest/Data Propagation in Vehicular Named Data Networks," ACM Research in Adaptive and Convergent Systems, (RACS), Czech Republic, Oct 2015. Link: http://dl.acm.org/citation.cfm?id=2811411.2811539&coll=DL&dl=ACM I respect critical remarks and suggestions. :) Best Regards, ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Syed Hassan Ahmed (??) Kyungpook National University, Daegu City, Republic of Korea. Cell: +82-10-9883-0786 https://sites.google.com/site/shahmedknu/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tnsr.chatterjee at gmail.com Mon Jul 25 04:01:10 2016 From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee) Date: Mon, 25 Jul 2016 16:31:10 +0530 Subject: [Ndn-interest] Same LSDB in entire network? In-Reply-To: <6132A8B5-6545-444B-B8A5-00B3B2A97A3E@memphis.edu> References: <4184E115-31E2-4189-803C-2CB2C517862A@memphis.edu> <6132A8B5-6545-444B-B8A5-00B3B2A97A3E@memphis.edu> Message-ID: Thank you for the responses. I think my confusions have been resolved. Thanks & Regards, Tanusree Chatterjee On Jul 22, 2016 4:26 AM, "Lan Wang (lanwang)" wrote: > Having the same set of LSAs is simply an algorithmic requirement for > routing convergence. What specific security threat do you see this > prevents? > > Lan > > On Jul 19, 2016, at 10:54 AM, Tanusree Chatterjee < > tnsr.chatterjee at gmail.com> wrote: > > Thanks for the response. By security, I also meant the digest tree > maintained by all the nodes (last version of NLSR) in the entire network > must be same as they exchange the root digest while sending interest > periodically to each other. So, to do the same each node in the entire > network must have the common LSDB. > As a simple scenario of 5 nodes I was running in mini ndn emulator, the > nlsrc status of all nodes show the same LSDB, which consists of all the > LSAs of each node in the network. > On Jul 19, 2016 7:09 PM, "Lan Wang (lanwang)" wrote: > >> Tanusree, >> >> Every node in NLSR maintains an LSDB (i.e. the topology of the entire >> network) since NLSR is a link-state routing protocol. If the network has >> converged, all the LSDBs should be the same. Every LSA is signed by its >> originator and can be verified using a trust model to make sure that the >> LSA is indeed originated by that origin router. This is a security benefit >> provided by NDN?s data-centric security model. Is this what you mean by >> ?this synchronization of same LSDB in the entire network helps in >> security"? >> >> Lan >> >> On Jul 18, 2016, at 9:25 AM, Tanusree Chatterjee < >> tnsr.chatterjee at gmail.com> wrote: >> >> Hi all, >> One thing I could not be sure about that whether all the nodes in the >> network have the common LSDB? If so, all the nodes have the idea of >> topology of the entire network? If NLSR is concerned, so this >> synchronization of same LSDB in the entire network helps in security also? >> >> 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 NourElHouda.BenYoussef at wevioo.com Wed Jul 27 04:17:48 2016 From: NourElHouda.BenYoussef at wevioo.com (Nour El Houda Ben Youssef) Date: Wed, 27 Jul 2016 11:17:48 +0000 Subject: [Ndn-interest] NDN overhead Message-ID: <712FE4E7257849499414892DD92704BC7A990724@INFRAEX02.oxia.corp> Dear ndn users I would like to ask a pragmatic question Can we talk about control overhead with ndn? Can interest packets be considered as overhead since they are NOT data packets ? Best regards [logoslogan.png] Nour El Houda BEN YOUSSEF KOUB?A|Doctorante Technopark El Ghazela 2088 Tunis- Tunisia Phone: +216 31 34 00 14 Mobile: +216 40 01 73 56 www.wevioo.com Paris - Tunis - Dubai - Alger -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4997 bytes Desc: image001.png URL: From lixia at CS.UCLA.EDU Wed Jul 27 04:39:14 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Wed, 27 Jul 2016 04:39:14 -0700 Subject: [Ndn-interest] NDN overhead In-Reply-To: <712FE4E7257849499414892DD92704BC7A990724@INFRAEX02.oxia.corp> References: <712FE4E7257849499414892DD92704BC7A990724@INFRAEX02.oxia.corp> Message-ID: > On Jul 27, 2016, at 4:17 AM, Nour El Houda Ben Youssef wrote: > > Dear ndn users > > I would like to ask a pragmatic question > > Can we talk about control overhead with ndn? > > Can interest packets be considered as overhead since they are NOT data packets ? wonder if you could check the mail archive (pointer below) -- we had a discussion on this topic not long along, under the subject line "How sending an interest for each chunk is justified?" > > Best regards > > > Nour El Houda BEN YOUSSEF KOUB?A|Doctorante > Technopark El Ghazela 2088 Tunis- Tunisia > Phone: +216 31 34 00 14 > Mobile: +216 40 01 73 56 > www.wevioo.com > Paris ? Tunis - Dubai ? Alger > > > > > > _______________________________________________ > 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 NourElHouda.BenYoussef at wevioo.com Fri Jul 29 03:20:31 2016 From: NourElHouda.BenYoussef at wevioo.com (Nour El Houda Ben Youssef) Date: Fri, 29 Jul 2016 10:20:31 +0000 Subject: [Ndn-interest] NDN overhead In-Reply-To: References: <712FE4E7257849499414892DD92704BC7A990724@INFRAEX02.oxia.corp> Message-ID: <712FE4E7257849499414892DD92704BC7A991784@INFRAEX02.oxia.corp> Yes indeed I already checked this thread Yet too many aspects still fuzzy First of all, we know that each layer in the Internet protocol Suite causes its overhead which why we talk about control overhead, signaling overhead, etc With NDN Interest packets or nacks are considered as which overhead exactly Second, as I tried to experiment NFD, I noticed that I?m able only to use NDN as an overlay network on top of udp or TCP? So for my overhead: would it be the Internet protocol suite overheads in addition to ndn overhead (interests and nacks)? Best regards De : Lixia Zhang [mailto:lixia at cs.ucla.edu] Envoy? : mercredi 27 juillet 2016 12:39 ? : Nour El Houda Ben Youssef Cc : ndn-interest at lists.cs.ucla.edu Objet : Re: [Ndn-interest] NDN overhead On Jul 27, 2016, at 4:17 AM, Nour El Houda Ben Youssef > wrote: Dear ndn users I would like to ask a pragmatic question Can we talk about control overhead with ndn? Can interest packets be considered as overhead since they are NOT data packets ? wonder if you could check the mail archive (pointer below) -- we had a discussion on this topic not long along, under the subject line "How sending an interest for each chunk is justified?" Best regards Nour El Houda BEN YOUSSEF KOUB?A|Doctorante Technopark El Ghazela 2088 Tunis- Tunisia Phone: +216 31 34 00 14 Mobile: +216 40 01 73 56 www.wevioo.com Paris ? Tunis - Dubai ? Alger _______________________________________________ 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 Fri Jul 29 05:31:23 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 29 Jul 2016 05:31:23 -0700 Subject: [Ndn-interest] NDN overhead In-Reply-To: <712FE4E7257849499414892DD92704BC7A990724@INFRAEX02.oxia.corp> References: <712FE4E7257849499414892DD92704BC7A990724@INFRAEX02.oxia.corp> Message-ID: Hi Nour By analogy to HTTP over TLS: Interest name of initial Interest to retrieve a version => HTTP request URI line, Cookie, User-Agent, etc Interest name of subsequent Interests to retrieve additional segment in a version => TCP ACK Link object retrieval, Link object and PublisherPublicKeyLocator selector in Interest => DNS lookup including DNSSEC Data name, portion that duplicates Interest name => IP header Data name, portion that is in addition to Interest name => HTTP response headers Data payload => HTTP response body signature of signed Interests, signature in Data => TLS connection setup and TLS record headers So, if you consider HTTP request, TCP ACK, DNS lookup as overheads, Interest is overhead as well. Whether those overheads are worthy is a different question which has been answered in "How sending an interest for each chunk is justified?". Yours, Junxiao On Wed, Jul 27, 2016 at 4:17 AM, Nour El Houda Ben Youssef < NourElHouda.BenYoussef at wevioo.com> wrote: > Dear ndn users > > > > I would like to ask a pragmatic question > > > > Can we talk about control overhead with ndn? > > > > Can interest packets be considered as overhead since they are NOT data > packets ? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lixia at CS.UCLA.EDU Fri Jul 29 05:41:15 2016 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Fri, 29 Jul 2016 05:41:15 -0700 Subject: [Ndn-interest] NDN overhead In-Reply-To: <712FE4E7257849499414892DD92704BC7A991784@INFRAEX02.oxia.corp> References: <712FE4E7257849499414892DD92704BC7A990724@INFRAEX02.oxia.corp> <712FE4E7257849499414892DD92704BC7A991784@INFRAEX02.oxia.corp> Message-ID: <2F22E29D-ED68-4F4E-8AF7-D9CF76178100@cs.ucla.edu> > On Jul 29, 2016, at 3:20 AM, Nour El Houda Ben Youssef wrote: > > Yes indeed I already checked this thread > Yet too many aspects still fuzzy > > First of all, we know that each layer in the Internet protocol Suite causes its overhead which why we talk about control overhead, signaling overhead, etc > With NDN Interest packets or nacks are considered as which overhead exactly > > Second, as I tried to experiment NFD, I noticed that I?m able only to use NDN as an overlay network on top of udp or TCP? So for my overhead: would it be the Internet protocol suite overheads in addition to ndn overhead (interests and nacks)? (I would not call NACK as overhead -- one could do without NACK, just that leaves failure/problem detection to timeout, which can significantly impact performance) regarding whether NDN runs over tunnels, one should separates the design from the code available today. 1/ By design, NDN can run over anything that can do datagram delivery, bluetooth, wifi, any layer 2 links, and any tunnels at any levels. 2/ in terms of code: I believe one can run directly over wifi and ethernet; we did NDN over bluotooth a few years back, but I dont think that old code still works with the new NFD. But to travel far (cross many routers that only know IP), one needs to use tunnels. this is similar to early days of IP: during my early years of grad school, IP ran over ethernet locally, but to go far it had to either use telephone dialup, or go through leased lines from phone companies (Arpanet). Here is a short interview article that seems relevant to your interest and you might want to take a look: http://web.cs.ucla.edu/~lixia/papers/1603login_interview.pdf Lixia -------------- next part -------------- An HTML attachment was scrubbed... URL: From NourElHouda.BenYoussef at wevioo.com Sun Jul 31 05:14:48 2016 From: NourElHouda.BenYoussef at wevioo.com (Nour El Houda Ben Youssef) Date: Sun, 31 Jul 2016 12:14:48 +0000 Subject: [Ndn-interest] NDN overhead In-Reply-To: <2F22E29D-ED68-4F4E-8AF7-D9CF76178100@cs.ucla.edu> References: <712FE4E7257849499414892DD92704BC7A990724@INFRAEX02.oxia.corp> <712FE4E7257849499414892DD92704BC7A991784@INFRAEX02.oxia.corp> <2F22E29D-ED68-4F4E-8AF7-D9CF76178100@cs.ucla.edu> Message-ID: <712FE4E7257849499414892DD92704BC7A9927AE@INFRAEX02.oxia.corp> Thank you De : Lixia Zhang [mailto:lixia at cs.ucla.edu] Envoy? : vendredi 29 juillet 2016 13:41 ? : Nour El Houda Ben Youssef Cc : ndn-interest at lists.cs.ucla.edu Objet : Re: [Ndn-interest] NDN overhead On Jul 29, 2016, at 3:20 AM, Nour El Houda Ben Youssef > wrote: Yes indeed I already checked this thread Yet too many aspects still fuzzy First of all, we know that each layer in the Internet protocol Suite causes its overhead which why we talk about control overhead, signaling overhead, etc With NDN Interest packets or nacks are considered as which overhead exactly Second, as I tried to experiment NFD, I noticed that I?m able only to use NDN as an overlay network on top of udp or TCP? So for my overhead: would it be the Internet protocol suite overheads in addition to ndn overhead (interests and nacks)? (I would not call NACK as overhead -- one could do without NACK, just that leaves failure/problem detection to timeout, which can significantly impact performance) regarding whether NDN runs over tunnels, one should separates the design from the code available today. 1/ By design, NDN can run over anything that can do datagram delivery, bluetooth, wifi, any layer 2 links, and any tunnels at any levels. 2/ in terms of code: I believe one can run directly over wifi and ethernet; we did NDN over bluotooth a few years back, but I dont think that old code still works with the new NFD. But to travel far (cross many routers that only know IP), one needs to use tunnels. this is similar to early days of IP: during my early years of grad school, IP ran over ethernet locally, but to go far it had to either use telephone dialup, or go through leased lines from phone companies (Arpanet). Here is a short interview article that seems relevant to your interest and you might want to take a look: http://web.cs.ucla.edu/~lixia/papers/1603login_interview.pdf Lixia -------------- next part -------------- An HTML attachment was scrubbed... URL: From grace.w09 at gmail.com Sun Jul 31 08:13:03 2016 From: grace.w09 at gmail.com (Lan Wang) Date: Sun, 31 Jul 2016 10:13:03 -0500 Subject: [Ndn-interest] Fwd: ACM ICN 2016 Travel Grants References: <2C4FEB36-ED7E-413C-BEFA-EC2B3DA92D89@gmail.com> Message-ID: <2586E787-71BA-4F84-8A44-63EA81B9A7BE@gmail.com> > Begin forwarded message: > > From: Lan Wang > Subject: ACM ICN 2016 Travel Grants > Date: July 25, 2016 at 1:18:40 PM CDT > Cc: Qi Li > > Hi all, > > We have two kinds of travel support for 3rd ACM Conference on Information-Centric Networking (ICN 2016), Sep. 26 - 28, 2016, in Kyoto Japan. > > - ACM SIGCOMM GeoDiversity travel grants are available for attendees in their early career from under-represented countries, based on need, distance to the conference venue, and impact of their attendance in increasing the diversity of conference participation. > > - ICN?16 student travel grants are available for students only. > > Application details are at http://conferences2.sigcomm.org/acm-icn/2016/index.php . Below are the deadlines: > > - August 16, 2015 (23:59 CET) > > Travel Grant Application Submission Deadline > > - August 23, 2015 (23:59 CET) > > Travel Grant Award Notification > > - August 30, 2015 (23:59 CET) > > Deadline to Accept/Decline Travel Grant Award > > Thanks. > > Lan Wang and Qi Li, ICN 2016 Travel Grant Chairs > > > ************************************************ > > Lan Wang > > Chair, Department of Computer Science > > University of Memphis > > Memphis, TN 38152 > > URL: http://www.cs.memphis.edu/~lanwang > *********************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tteixeira at engin.umass.edu Sun Jul 31 17:09:28 2016 From: tteixeira at engin.umass.edu (Thiago Teixeira) Date: Mon, 1 Aug 2016 00:09:28 +0000 Subject: [Ndn-interest] Hyperbolic routing in mobile scenarios Message-ID: <41E7DF15B39B5C46BF24C9545D39304C2ADBAD36@oit-ex2010-mb1> Hi all, I have been reading about hyperbolic routing in NDN and how Interest/Data packets can be routed without the full knowledge of the network, through the hyperbolic coordinates and greedy routing; however, in all examples I've seen, the nodes are fixed. Has anybody studied hyperbolic routing in mobile topologies? Cheers, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: