From a.abencherou at gmail.com Tue Mar 1 07:37:30 2016 From: a.abencherou at gmail.com (ahmed abencherou) Date: Tue, 1 Mar 2016 16:37:30 +0100 Subject: [Ndn-interest] Write to CS Message-ID: Hi all, I wonder if an application can access the local cache (CS) to add Data packets in order to answer Interests Thanks. -- ABENCHEROU Ahmed -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.EDU Tue Mar 1 07:45:36 2016 From: shijunxiao at email.arizona.EDU (Junxiao Shi) Date: Tue, 1 Mar 2016 08:45:36 -0700 Subject: [Ndn-interest] Write to CS In-Reply-To: References: Message-ID: Hi Ahmed No, you cannot. This feature is in early and current version of NFD, but is scheduled to be removed in v0.5 (#2181 ). Instead, use InMemoryStorage or MemoryContentCache in your producer application. You may put generated Data into the in-app cache, and let the in-app cache answer Interests. Yours, Junxiao On Tue, Mar 1, 2016 at 8:37 AM, ahmed abencherou wrote: > Hi all, > > I wonder if an application can access the local cache (CS) to add Data > packets in order to answer Interests > > Thanks. > > -- > ABENCHEROU Ahmed > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tailinchu at gmail.com Tue Mar 1 08:52:46 2016 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Tue, 1 Mar 2016 08:52:46 -0800 Subject: [Ndn-interest] Write to CS In-Reply-To: References: Message-ID: There are two in-app cache implementations (ndn.Cache) in go-ndn: - persist.Cacher: uses on-disk mmap packet store - mux.Cacher: uses in-memory lru packet store See example https://github.com/go-ndn/example/blob/master/producer/producer.go On Tue, Mar 1, 2016 at 7:37 AM, ahmed abencherou wrote: > Hi all, > > I wonder if an application can access the local cache (CS) to add Data > packets in order to answer Interests > > Thanks. > > -- > ABENCHEROU Ahmed > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From Navdeep.Uniyal at neclab.eu Wed Mar 2 02:42:09 2016 From: Navdeep.Uniyal at neclab.eu (Navdeep Uniyal) Date: Wed, 2 Mar 2016 10:42:09 +0000 Subject: [Ndn-interest] [Mini-NDN] NLSR Error In-Reply-To: References: <15421E67B274CD4AB5F6AEA46A684C370384D9B1@Hydra.office.hd> Message-ID: <15421E67B274CD4AB5F6AEA46A684C370384DAFE@Hydra.office.hd> Hi Vince, Thank you for your reply. I saw the NFD logs(attached) and could not find any point where NFD is failing. But surprisingly, I could see that there is less number of interests that are forwarded even in the case they are not satisfied with the cache. I am using NDN Traffic generator to create the traffic in the network. Any pointer would be helpful. I am using a simple topology: Client1-->Client2-->Server (There are 3 paths from Client2 to server) Attached is the traffic generator client and server configuration. Please help. Thanks and Regards, Navdeep Uniyal From: Vince Lehman (vslehman) [mailto:vslehman at memphis.edu] Sent: Montag, 29. Februar 2016 16:48 To: Navdeep Uniyal Cc: ndn-interest at lists.cs.ucla.edu; mini-ndn at lists.cs.ucla.edu Subject: Re: [Mini-NDN] NLSR Error Hi Navdeep, This error is usually caused by the NFD process on the node terminating; NLSR is unable to receive data from NFD?s Unix socket. Can you check or share NFD?s log to see the reason for the process? termination? It could be something wrong with the configuration or if you are using ctl^c to kill a process on the Mini-NDN command-line, this can sometimes kill NFD processes also. -- Vince Lehman On Feb 29, 2016, at 7:52 AM, Navdeep Uniyal > wrote: Hi everyone, I am using minindn to run my experiments, I am finding few errors in the NLSR log. Due to which packet loss is occurring. Below is the snippet of the error and attached is the log file. Please if someone can help resolving the issue. 20160229054020045 DEBUG: [HelloProtocol] Interest Received for Name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hb 20160229054020045 DEBUG: [HelloProtocol] Neighbor: /ndn/edu/%C1.Router/cs/hb 20160229054020049 DEBUG: [HelloProtocol] Sending out data for name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hb 20160229054020533 DEBUG: [HelloProtocol] Interest Received for Name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hc 20160229054020533 DEBUG: [HelloProtocol] Neighbor: /ndn/edu/%C1.Router/cs/hc 20160229054020535 DEBUG: [HelloProtocol] Sending out data for name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hc 20160229054111562 FATAL: [Main] ERROR: error while receiving data from socket (End of file) 20160229054111562 DEBUG: [Fib] Fib::clean called Regards, Navdeep Uniyal _______________________________________________ Mini-NDN mailing list Mini-NDN at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ga.log Type: application/octet-stream Size: 1791955 bytes Desc: ga.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ndn-traffic-server.conf Type: application/octet-stream Size: 1570 bytes Desc: ndn-traffic-server.conf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ndn-traffic-client.conf Type: application/octet-stream Size: 1710 bytes Desc: ndn-traffic-client.conf URL: From vslehman at memphis.edu Wed Mar 2 07:01:05 2016 From: vslehman at memphis.edu (Vince Lehman (vslehman)) Date: Wed, 2 Mar 2016 15:01:05 +0000 Subject: [Ndn-interest] [Mini-NDN] NLSR Error In-Reply-To: <15421E67B274CD4AB5F6AEA46A684C370384DAFE@Hydra.office.hd> References: <15421E67B274CD4AB5F6AEA46A684C370384D9B1@Hydra.office.hd> <15421E67B274CD4AB5F6AEA46A684C370384DAFE@Hydra.office.hd> Message-ID: <455D46E2-5E72-4E6D-9BA7-335B1D37FEFF@memphis.edu> Hi Navdeep, Could you also attach the corresponding NLSR log file? Thanks. -- Vince Lehman On Mar 2, 2016, at 4:42 AM, Navdeep Uniyal > wrote: Hi Vince, Thank you for your reply. I saw the NFD logs(attached) and could not find any point where NFD is failing. But surprisingly, I could see that there is less number of interests that are forwarded even in the case they are not satisfied with the cache. I am using NDN Traffic generator to create the traffic in the network. Any pointer would be helpful. I am using a simple topology: Client1-->Client2-->Server (There are 3 paths from Client2 to server) Attached is the traffic generator client and server configuration. Please help. Thanks and Regards, Navdeep Uniyal From: Vince Lehman (vslehman) [mailto:vslehman at memphis.edu] Sent: Montag, 29. Februar 2016 16:48 To: Navdeep Uniyal Cc: ndn-interest at lists.cs.ucla.edu; mini-ndn at lists.cs.ucla.edu Subject: Re: [Mini-NDN] NLSR Error Hi Navdeep, This error is usually caused by the NFD process on the node terminating; NLSR is unable to receive data from NFD?s Unix socket. Can you check or share NFD?s log to see the reason for the process? termination? It could be something wrong with the configuration or if you are using ctl^c to kill a process on the Mini-NDN command-line, this can sometimes kill NFD processes also. -- Vince Lehman On Feb 29, 2016, at 7:52 AM, Navdeep Uniyal > wrote: Hi everyone, I am using minindn to run my experiments, I am finding few errors in the NLSR log. Due to which packet loss is occurring. Below is the snippet of the error and attached is the log file. Please if someone can help resolving the issue. 20160229054020045 DEBUG: [HelloProtocol] Interest Received for Name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hb 20160229054020045 DEBUG: [HelloProtocol] Neighbor: /ndn/edu/%C1.Router/cs/hb 20160229054020049 DEBUG: [HelloProtocol] Sending out data for name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hb 20160229054020533 DEBUG: [HelloProtocol] Interest Received for Name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hc 20160229054020533 DEBUG: [HelloProtocol] Neighbor: /ndn/edu/%C1.Router/cs/hc 20160229054020535 DEBUG: [HelloProtocol] Sending out data for name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hc 20160229054111562 FATAL: [Main] ERROR: error while receiving data from socket (End of file) 20160229054111562 DEBUG: [Fib] Fib::clean called Regards, Navdeep Uniyal _______________________________________________ Mini-NDN mailing list Mini-NDN at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn -------------- next part -------------- An HTML attachment was scrubbed... URL: From Navdeep.Uniyal at neclab.eu Wed Mar 2 07:16:55 2016 From: Navdeep.Uniyal at neclab.eu (Navdeep Uniyal) Date: Wed, 2 Mar 2016 15:16:55 +0000 Subject: [Ndn-interest] [Mini-NDN] NLSR Error In-Reply-To: <455D46E2-5E72-4E6D-9BA7-335B1D37FEFF@memphis.edu> References: <15421E67B274CD4AB5F6AEA46A684C370384D9B1@Hydra.office.hd> <15421E67B274CD4AB5F6AEA46A684C370384DAFE@Hydra.office.hd> <455D46E2-5E72-4E6D-9BA7-335B1D37FEFF@memphis.edu> Message-ID: <15421E67B274CD4AB5F6AEA46A684C370384FDD9@PALLENE.office.hd> Hi Vince, PFA the NLSR log file. Regards, Navdeep Uniyal From: Vince Lehman (vslehman) [mailto:vslehman at memphis.edu] Sent: Mittwoch, 2. M?rz 2016 16:01 To: Navdeep Uniyal Cc: ndn-interest at lists.cs.ucla.edu; mini-ndn at lists.cs.ucla.edu Subject: Re: [Mini-NDN] NLSR Error Hi Navdeep, Could you also attach the corresponding NLSR log file? Thanks. -- Vince Lehman On Mar 2, 2016, at 4:42 AM, Navdeep Uniyal > wrote: Hi Vince, Thank you for your reply. I saw the NFD logs(attached) and could not find any point where NFD is failing. But surprisingly, I could see that there is less number of interests that are forwarded even in the case they are not satisfied with the cache. I am using NDN Traffic generator to create the traffic in the network. Any pointer would be helpful. I am using a simple topology: Client1-->Client2-->Server (There are 3 paths from Client2 to server) Attached is the traffic generator client and server configuration. Please help. Thanks and Regards, Navdeep Uniyal From: Vince Lehman (vslehman) [mailto:vslehman at memphis.edu] Sent: Montag, 29. Februar 2016 16:48 To: Navdeep Uniyal Cc: ndn-interest at lists.cs.ucla.edu; mini-ndn at lists.cs.ucla.edu Subject: Re: [Mini-NDN] NLSR Error Hi Navdeep, This error is usually caused by the NFD process on the node terminating; NLSR is unable to receive data from NFD?s Unix socket. Can you check or share NFD?s log to see the reason for the process? termination? It could be something wrong with the configuration or if you are using ctl^c to kill a process on the Mini-NDN command-line, this can sometimes kill NFD processes also. -- Vince Lehman On Feb 29, 2016, at 7:52 AM, Navdeep Uniyal > wrote: Hi everyone, I am using minindn to run my experiments, I am finding few errors in the NLSR log. Due to which packet loss is occurring. Below is the snippet of the error and attached is the log file. Please if someone can help resolving the issue. 20160229054020045 DEBUG: [HelloProtocol] Interest Received for Name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hb 20160229054020045 DEBUG: [HelloProtocol] Neighbor: /ndn/edu/%C1.Router/cs/hb 20160229054020049 DEBUG: [HelloProtocol] Sending out data for name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hb 20160229054020533 DEBUG: [HelloProtocol] Interest Received for Name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hc 20160229054020533 DEBUG: [HelloProtocol] Neighbor: /ndn/edu/%C1.Router/cs/hc 20160229054020535 DEBUG: [HelloProtocol] Sending out data for name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hc 20160229054111562 FATAL: [Main] ERROR: error while receiving data from socket (End of file) 20160229054111562 DEBUG: [Fib] Fib::clean called Regards, Navdeep Uniyal _______________________________________________ Mini-NDN mailing list Mini-NDN at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nlsr.log Type: application/octet-stream Size: 924612 bytes Desc: nlsr.log URL: From vslehman at memphis.edu Wed Mar 2 07:29:38 2016 From: vslehman at memphis.edu (Vince Lehman (vslehman)) Date: Wed, 2 Mar 2016 15:29:38 +0000 Subject: [Ndn-interest] [Mini-NDN] NLSR Error In-Reply-To: <15421E67B274CD4AB5F6AEA46A684C370384FDD9@PALLENE.office.hd> References: <15421E67B274CD4AB5F6AEA46A684C370384D9B1@Hydra.office.hd> <15421E67B274CD4AB5F6AEA46A684C370384DAFE@Hydra.office.hd> <455D46E2-5E72-4E6D-9BA7-335B1D37FEFF@memphis.edu> <15421E67B274CD4AB5F6AEA46A684C370384FDD9@PALLENE.office.hd> Message-ID: <44E4BF3F-45B0-4059-ABC0-BB6AE0419927@memphis.edu> Hi Navdeep, It looks like the NFD log file was recorded on March 2, but all of the NLSR log messages in the attached file are from February 29. Do you have the NLSR log file for the same time period as the NFD log file? -- Vince Lehman On Mar 2, 2016, at 9:16 AM, Navdeep Uniyal > wrote: Hi Vince, PFA the NLSR log file. Regards, Navdeep Uniyal From: Vince Lehman (vslehman) [mailto:vslehman at memphis.edu] Sent: Mittwoch, 2. M?rz 2016 16:01 To: Navdeep Uniyal Cc: ndn-interest at lists.cs.ucla.edu; mini-ndn at lists.cs.ucla.edu Subject: Re: [Mini-NDN] NLSR Error Hi Navdeep, Could you also attach the corresponding NLSR log file? Thanks. -- Vince Lehman On Mar 2, 2016, at 4:42 AM, Navdeep Uniyal > wrote: Hi Vince, Thank you for your reply. I saw the NFD logs(attached) and could not find any point where NFD is failing. But surprisingly, I could see that there is less number of interests that are forwarded even in the case they are not satisfied with the cache. I am using NDN Traffic generator to create the traffic in the network. Any pointer would be helpful. I am using a simple topology: Client1-->Client2-->Server (There are 3 paths from Client2 to server) Attached is the traffic generator client and server configuration. Please help. Thanks and Regards, Navdeep Uniyal From: Vince Lehman (vslehman) [mailto:vslehman at memphis.edu] Sent: Montag, 29. Februar 2016 16:48 To: Navdeep Uniyal Cc: ndn-interest at lists.cs.ucla.edu; mini-ndn at lists.cs.ucla.edu Subject: Re: [Mini-NDN] NLSR Error Hi Navdeep, This error is usually caused by the NFD process on the node terminating; NLSR is unable to receive data from NFD?s Unix socket. Can you check or share NFD?s log to see the reason for the process? termination? It could be something wrong with the configuration or if you are using ctl^c to kill a process on the Mini-NDN command-line, this can sometimes kill NFD processes also. -- Vince Lehman On Feb 29, 2016, at 7:52 AM, Navdeep Uniyal > wrote: Hi everyone, I am using minindn to run my experiments, I am finding few errors in the NLSR log. Due to which packet loss is occurring. Below is the snippet of the error and attached is the log file. Please if someone can help resolving the issue. 20160229054020045 DEBUG: [HelloProtocol] Interest Received for Name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hb 20160229054020045 DEBUG: [HelloProtocol] Neighbor: /ndn/edu/%C1.Router/cs/hb 20160229054020049 DEBUG: [HelloProtocol] Sending out data for name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hb 20160229054020533 DEBUG: [HelloProtocol] Interest Received for Name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hc 20160229054020533 DEBUG: [HelloProtocol] Neighbor: /ndn/edu/%C1.Router/cs/hc 20160229054020535 DEBUG: [HelloProtocol] Sending out data for name: /ndn/edu/%C1.Router/cs/ga/NLSR/INFO/%07%1C%08%03ndn%08%03edu%08%08%C1.Router%08%02cs%08%02hc 20160229054111562 FATAL: [Main] ERROR: error while receiving data from socket (End of file) 20160229054111562 DEBUG: [Fib] Fib::clean called Regards, Navdeep Uniyal _______________________________________________ Mini-NDN mailing list Mini-NDN at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn -------------- next part -------------- An HTML attachment was scrubbed... URL: From susmit at cs.colostate.edu Thu Mar 3 09:11:37 2016 From: susmit at cs.colostate.edu (Susmit) Date: Thu, 3 Mar 2016 10:11:37 -0700 Subject: [Ndn-interest] Reminder: 2nd NDN Hackathon submission deadline in 3 days Message-ID: [x-post] ====================================== CALL FOR HACKS The 2nd Named Data Networking (NDN) Hackathon March 20-21, UC San Diego Campus, La Jolla, CA ====================================== The proposal submission deadline for second NDN hackathon is Sunday, March 6th. Please email your proposals to <2nd-ndn-hackathon at named-data.net>. The original call for hacks is here: http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2016-February/000962.html More details can be found on the website: http://2nd-ndn-hackathon.named-data.net/cfh.html -- Regards, Susmit ==================================== http://www.cs.colostate.edu/~susmit ==================================== From 121049189 at qq.com Thu Mar 3 17:32:30 2016 From: 121049189 at qq.com (=?gb18030?B?1dTWvs6w?=) Date: Fri, 4 Mar 2016 09:32:30 +0800 Subject: [Ndn-interest] transmission application Message-ID: Dear all: I'm quiet new to NDN, but I'm interested about it. Now my teacher told me to run a transmission application, I don't know how to do it.Could you tell me how to do it in detail. I'm looking forward it. ZHAO Zhiwei ------------------ ---------------------------------------------------- ??? ????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.AbdollahiSabet at mail.sbu.ac.ir Thu Mar 3 23:25:07 2016 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Fri, 4 Mar 2016 10:55:07 +0330 Subject: [Ndn-interest] transmission application References: Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC29FD@m-pdc.sbu.ac.ir> Hi, You can take look at these two: https://github.com/named-data/ChronoShare and https://github.com/named-data/ndn-tools/tree/master/tools/chunks Hope this helps. Thanks, Sabet -----Original Message----- From: Ndn-interest on behalf of ??? Sent: Fri 3/4/2016 5:02 AM To: ndn-interest Subject: [Ndn-interest] transmission application Dear all: I'm quiet new to NDN, but I'm interested about it. Now my teacher told me to run a transmission application, I don't know how to do it.Could you tell me how to do it in detail. I'm looking forward it. ZHAO Zhiwei ------------------ ---------------------------------------------------- ??? ????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Sat Mar 5 22:24:20 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Sat, 5 Mar 2016 22:24:20 -0800 Subject: [Ndn-interest] [New NDN paper] Named Data Networking of Things Message-ID: The new paper by the NDN team will be presented at the IoTDI conference in April. Title : Named Data Networking of Things Authors : Wentao Shang, Adeola Bannis, Teng Liang, Zhehao Wang, Yingdi Yu, Alexander Afanasyev, Jeff Thompson, Jeff Burke, Beichuan Zhang, and Lixia Zhang Conference : The 1st IEEE International Conference on Internet-of-Things Design and Implementation (IoTDI'2016, http://conferences.computer.org/IoTDI/) Abstract: The Internet of Things (IoT) is a vision for interconnecting all of the world?s "things"?from vehicles to diet scales, smart homes and electrical grids?through a common set of networking technologies. Realizing this vision using a host-to-host communication paradigm, such as that of the Internet Protocol (IP), is challenging in the context of highly heterogeneous, constrained devices that connect intermittently to one or more networks, often using multiple interfaces; communicate within various security regimes; and require both local and global communication capability. Using IP and similar protocols as the narrow waist of interoperability for IoT requires managing data exchange and security in terms that are largely orthogonal to application semantics, while simultaneously needing to minimize resource usage. This paper explores how Named Data Networking (NDN), a proposed future Internet architecture, addresses the root causes of these challenges and can help achieve the IoT vision in a more secure, straightforward, and innovation-friendly manner. NDN?s data-centric communication model aligns network and application semantics, enabling developers to work with ?things? and their data directly, and for IoT networks to be deployed and configured easily. To substantiate the high-level discussion, we give examples of ongoing design and implementation work in IoT over NDN and compare the architecture to well-known existing protocols and frameworks. Finally, we discuss short- and long-term scenarios for employing NDN to enable the Internet of Things. Information page for this publication: http://named-data.net/publications/ndn-iotdi-2016/ Direct link to PDF with authors' version of the paper: http://named-data.net/wp-content/uploads/2015/01/ndn-IOTDI-2016.pdf Other NDN papers: http://named-data.net/publications/ -------------- 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 mesarpe at gmail.com Fri Mar 4 06:54:29 2016 From: mesarpe at gmail.com (=?UTF-8?Q?C=C3=A9sar_A=2E_Bernardini?=) Date: Fri, 4 Mar 2016 15:54:29 +0100 Subject: [Ndn-interest] Registering an Interest into NDNx Message-ID: Hi, I am trying to understand how NDN client registers an Interest name. To this end, I am debugging ndnpoke. I will describe what I have understood so far: 1. Let us imagine that we want to register the name: /hello/there. 2. A template is created adding Key, Signature and to Encrypt the content 3. NDN_set_interest_filter is called (asynchronously) and a set of actions is described. 4. ndn_run is always running while ndnpoke is running. 5. ndn_run calls ndn_process_scheduled_operations that calls ndn_initiate_prefix_reg. 6. This function (ndn_initiate_prefix_reg) seems to alter the registered name: the interest name is encoded into base64 attached with the signature info and a prefix ndnx:/ndnx/self reg is appended. There is something else in base64 that I have not idea what it is. 7. Finally the function ndn_express_interest sends the Interest message to the NDNx server. Am I getting right the process? Is it that complicated? What is the base64 component added into the Interest message? Thanks, From aa at CS.UCLA.EDU Sun Mar 6 19:31:05 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Sun, 6 Mar 2016 19:31:05 -0800 Subject: [Ndn-interest] Registering an Interest into NDNx In-Reply-To: References: Message-ID: <51B83B5A-7CCF-4BB9-BEFE-E5B4BF2FFC9A@cs.ucla.edu> Hi C?sar, You are looking at the very old code that is currently not supported or used. I would recommend looking at the new code: NFD, ndn-cxx, and ndn-tools. Your question is related to the management protocol, i.e., how clients like ndnpoke send commands to the forwarder. You can read details of the NFD management in wiki: http://redmine.named-data.net/projects/nfd/wiki/Management. It should clarify what the constructed name of the signed interests are. --- Alex > On Mar 4, 2016, at 6:54 AM, C?sar A. Bernardini wrote: > > Hi, > > I am trying to understand how NDN client registers an Interest name. > To this end, I am debugging ndnpoke. I will describe what I have > understood so far: > > 1. Let us imagine that we want to register the name: /hello/there. > 2. A template is created adding Key, Signature and to Encrypt the content > 3. NDN_set_interest_filter is called (asynchronously) and a set of > actions is described. > > 4. ndn_run is always running while ndnpoke is running. > 5. ndn_run calls ndn_process_scheduled_operations that calls > ndn_initiate_prefix_reg. > 6. This function (ndn_initiate_prefix_reg) seems to alter the > registered name: the interest name is encoded into base64 attached > with the signature info and a prefix ndnx:/ndnx/self reg is appended. > There is something else in base64 that I have not idea what it is. > 7. Finally the function ndn_express_interest sends the Interest > message to the NDNx server. > > Am I getting right the process? Is it that complicated? > What is the base64 component added into the Interest message? > > Thanks, > _______________________________________________ > 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 Mar 6 20:43:25 2016 From: s.h.ahmed at ieee.org (Syed Hassan Ahmed) Date: Mon, 7 Mar 2016 13:43:25 +0900 Subject: [Ndn-interest] Content Centric Network (CCN) Book Message-ID: Dear Colleagues and Professors , ?I hope this email will find you all in the best your health and work. ? I am pleased to introduce my recent brief book on Content Centric Networks (CCN). This book provides a brief overview of current Internet limitations, newly proposed CCN and its applicability in our future communications. Moreover, various application oriented efforts have been summarized, followed by the current issues and challenges. ?This is the very first book on a timely topic and ? I believe that this book can be used as a supporting material for the Next Generation or Future Internet courses offered at both undergrad and grad level of studies. Book URL: http://www.springer.com/gp/book/9789811000645 Book Outline: Chapter 1: Introduction Chapter 2: Information-Centric Networks (ICN) Chapter 3: Content-Centric Networks (CCN) Chapter 4: Future Aspects For ?the CCN/NDN Community , I am including an official PDF version of the book along with the copyrights partially held by the Springer publisher. If you have any comments/questions, please feel free to send me an email. Best Regards, ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ *Syed Hassan Ahmed *(??) Kyungpook National University, Daegu City, Republic of Korea. Cell: +82-10-9883-0786 https://sites.google.com/site/shahmedknu/ This email has been sent from a virus-free computer protected by Avast. www.avast.com <#1919449078_859556257_1399473645_608753857_1711256061_-48146783_955366977_-1143453777_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CCN Book_Online.pdf Type: application/pdf Size: 2560014 bytes Desc: not available URL: From susmit at cs.colostate.edu Mon Mar 7 17:49:19 2016 From: susmit at cs.colostate.edu (Susmit) Date: Mon, 7 Mar 2016 18:49:19 -0700 Subject: [Ndn-interest] NDN Hackathon deadline extension until March 10th Message-ID: [x-post] ====================================== CALL FOR HACKS The 2nd Named Data Networking (NDN) Hackathon March 20-21, UC San Diego Campus, La Jolla, CA ====================================== The NDN hackthon submission deadline has been extended until Thursday, March 10th, 2016. If you haven't submitted a hack proposal yet, please consider submitting one (or more) to <2nd-ndn-hackathon AT named-data.net>. The original call for hacks is here: http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2016-February/000962.html More details can be found on the website: http://2nd-ndn-hackathon.named-data.net/cfh.html -- Regards, Susmit ==================================== http://www.cs.colostate.edu/~susmit ==================================== From aa at CS.UCLA.EDU Thu Mar 10 23:46:01 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Thu, 10 Mar 2016 23:46:01 -0800 Subject: [Ndn-interest] NDN Protocol Design Principles Message-ID: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> Dear all, Recently, we have been working to formalize a list of basic principles that underly the design of the NDN architecture. We have assembled the initial list of 6 principles and would like to ask everybody for the all kind of feedback about the identified principles, other potential principles, wording clarification, etc. We also hope that the NDN design principles will start a new round of public architectural discussions, clarifying the current and future design decisions and overall architecture objectives. The latest version of the principles and additional information is available on NDN website: http://named-data.net/project/ndn-design-principles/ * * * For convenience, here is the current version of the list without additional information: [1] **Universality**: NDN should be a common network protocol for all applications and network environments. [2] **Data-Centricity and Data Immutability**: NDN should fetch uniquely named, immutable ?data packets? requested using ?interest packets?. [3] **Securing Data Directly**: Security should be the property of data packets, staying the same whether the packets are in motion or at rest. [4] **Hierarchical Naming**: Packets should carry hierarchical names to enable demultiplexing and provide structured context. [5] **In-Network Name Discovery**: Interests should be able use incomplete names to retrieve data packets. [6] **Hop-by-Hop Flow Balance**: Over each link, one interest packet should bring back no more than one data packet. * * * Sincerely, Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From shock.jiang at gmail.com Fri Mar 11 00:06:18 2016 From: shock.jiang at gmail.com (Xiaoke Jiang) Date: Fri, 11 Mar 2016 16:06:18 +0800 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> Message-ID: Hi Alex, This is really an interesting topics, and I tried to summarize some principles too. And here is my comments. 1. The meaning of "NDN principle" is not very clear (at least to me). I think you do not refer to the design principle of NDN architecture itself, but more or less refer to NDN-based applications. But anyway, to clarify its meaning and usage would make it easier to understand. 2. I would say REST-style application layer interaction. Since no session is built between producer and consumer, Interest should not rely on context of communication in order to retrieve a data. This also relates to Interest concurrency, here I mean how many Interests can be sent in parallel. I categories the Interests to two kinds: 1) safe one, which does not change the status of producer, but "read" data only; 2) sensitive one, which may change the status. When there is sensitive Interests, the sequence of Interests is critical; otherwise, multiple Interests can be sent in parallel for better throughput. 3. Apps do not have to worry about scalability, since multiple data source, caching and hop-by-hop flow control effectively enables app to scale its throughput. But apps should avoid to move NDN communication back to end-to-end style by building session manually. (although session may be a must for some apps.) Xiaoke On Fri, Mar 11, 2016 at 3:46 PM, Alex Afanasyev wrote: > Dear all, > > Recently, we have been working to formalize a list of basic principles > that underly the design of the NDN architecture. We have assembled the > initial list of 6 principles and would like to ask everybody for the all > kind of feedback about the identified principles, other potential > principles, wording clarification, etc. > > We also hope that the NDN design principles will start a new round of > public architectural discussions, clarifying the current and future design > decisions and overall architecture objectives. > > The latest version of the principles and additional information is > available on NDN website: > http://named-data.net/project/ndn-design-principles/ > > * * * > > For convenience, here is the current version of the list without > additional information: > > [1] **Universality**: > NDN should be a common network protocol for all applications and > network environments. > > [2] **Data-Centricity and Data Immutability**: > NDN should fetch uniquely named, immutable ?data packets? requested > using ?interest packets?. > > [3] **Securing Data Directly**: > Security should be the property of data packets, staying the same > whether the packets are in motion or at rest. > > [4] **Hierarchical Naming**: > Packets should carry hierarchical names to enable demultiplexing and > provide structured context. > > [5] **In-Network Name Discovery**: > Interests should be able use incomplete names to retrieve data packets. > > [6] **Hop-by-Hop Flow Balance**: > Over each link, one interest packet should bring back no more than one > data packet. > > * * * > > Sincerely, > Alex > > > _______________________________________________ > 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 Ignacio.Solis at parc.com Fri Mar 11 00:26:34 2016 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Fri, 11 Mar 2016 08:26:34 +0000 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> Message-ID: <1EF575B5-C23B-4A3C-A162-1066FD389193@parc.com> I think it?s great to have spelled out protocol principles. It definitely lets people discuss things in a way that distinguishes the principle from the embodiment. You can then evaluate the tradeoffs that you?re making. It also helps frame the question as to why something is a principle at all. Is it a direct benefit? Or is it just a limitation so we don?t explore the complete answer space? One thing that you do not touch upon, is where in the layers (or lack-of-layers), something happens. Whether something is part of the ?core/base? protocol or in a layer above it (or bellow it). What are the assumptions about what is provided bellow and what are the assumptions about what you provide at the top? Is there any structure internally that matters, if so, what? For example, if there is a weather data set that is 2 gigs in size, is that something that is handled by NDN, a part of NDN, or something that runs on top of NDN? This makes some of the choices of the principles have different meanings. The main web page for UCLA cannot be immutable. Just like my bank account cannot be immutable. Surely some part of that can be immutable, and some part of that can have a name, but I assume there is a way to name the UCLA main web page, or my bank account. I will make some comments on the principles in separate emails. I do have one opening question. Is performance/efficiency not a principle at all? Would we be ok with a protocol that meets all of these principles but it?s not better in performance than the alternatives? Do we think that performance comes from these principles? Do we think performance doesn?t matter? Do we think that performance doesn?t matter yet? Do we think performance will come later? Or is performance implied as an overarching goal? Also, as a philosophical question; have you thought about framing the issue as ?these are the problems we are trying to solve? instead of ?this is what we think the end-goal is?? Nacho PS- Yes, I realize some of these questions can apply to CCN as well. -- Nacho (Ignacio) Solis Protocol Architect Principal Scientist Palo Alto Research Center (PARC) +1(650)812-4458 Ignacio.Solis at parc.com On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" wrote: >Dear all, > >Recently, we have been working to formalize a list of basic principles that underly the design of the NDN architecture. We have assembled the initial list of 6 principles and would like to ask everybody for the all kind of feedback about the identified principles, other potential principles, wording clarification, etc. > >We also hope that the NDN design principles will start a new round of public architectural discussions, clarifying the current and future design decisions and overall architecture objectives. > >The latest version of the principles and additional information is available on NDN website: >http://named-data.net/project/ndn-design-principles/ > >* * * > >For convenience, here is the current version of the list without additional information: > >[1] **Universality**: > NDN should be a common network protocol for all applications and network environments. > >[2] **Data-Centricity and Data Immutability**: > NDN should fetch uniquely named, immutable ?data packets? requested using ?interest packets?. > >[3] **Securing Data Directly**: > Security should be the property of data packets, staying the same whether the packets are in motion or at rest. > >[4] **Hierarchical Naming**: > Packets should carry hierarchical names to enable demultiplexing and provide structured context. > >[5] **In-Network Name Discovery**: > Interests should be able use incomplete names to retrieve data packets. > >[6] **Hop-by-Hop Flow Balance**: > Over each link, one interest packet should bring back no more than one data packet. > >* * * > >Sincerely, >Alex > From Ignacio.Solis at parc.com Fri Mar 11 00:48:32 2016 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Fri, 11 Mar 2016 08:48:32 +0000 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> Message-ID: >[1] **Universality**: > NDN should be a common network protocol for all applications and network environments. I?m assuming here that you imply a set of protocols. After all, the way you do flow control varies a lot from DTN to non-DTN environments. Or are you limiting this to the basic packet format? On the web page it calls out for DTN, IoT, Mesh networks, Web, etc. It seems obvious to me that these require various protocols; potentially layered or interoperating in some fashion. If one interprets this principle as ?the base protocol will allow??, then the question becomes how does the base protocol allow this. The document states that the protocol should be flexible and extensible. It then states that there should be no fixed parts or fixed length fields in the header. I?m unsure what the full rationale is here. Is it that we will exceed the length of the fields? Or that suddenly one field will become obsolete and we will want to remove it? Is it because we don?t want to make assumptions about packets coming in? We want them to be so flexible that anything is possible? In one way or another, we?re making assumptions about the packet coming in. If it?s not the static header, it?s the fact that the way we parse the packet has to be consistent. (As in, the first bit determines if the next byte is a continuation of the first byte, etc). So, to some degree, you are fixing some formatting. In one assumption, (fixed header), we are limiting the format and semantics of the first n bytes (8 or 16 or whatever). In the other space, you?re limiting the format (but maybe not the semantics of the first n bytes). You trade off some processing for some byte inefficiency. The fact that we want the same protocol to work on IoT, datacenter and interplanetary networks effectively says: - The benefits we get from optimizing for each of these scenarios are less important than the advantage we get by having a single protocol format that runs in all. It seems to me that having a single protocol is useful when traffic goes from one to the other. If we don?t expect traffic to go from one to the other the benefit diminishes. Here I?m assuming native network compatible traffic. So that one packet, comes from IoT and unmodified goes to the datacenter and unmodified goes to Mars. As opposed to having gateways that can speak multiple protocols or tunneling and overlays. To calibrate, I?m in the camp of thinking that PIM-SM and PIM-DM are different protocols. So I would also side with the fact that if you had a situation where packets on one end of the gateway use NDN but are not understood at the other side of the gateway then the packets are effectively from 2 different protocols. I would also argue that if the purpose of building an extremely flexible format is to save bytes in one scenario where those are not needed at the expense of processing, then I would say that you might as well go all the way and just implement some type of link-layer compression scheme and really save some bytes. Dictionaries can go a long way. Finally, going back to what?s on the page. When you say that there should be no fixed parts and no fixed length fields, do you really mean it? - Can I have a packet with no packet_size field? - Can I have a packet with no protocol version field? - Can I have a packet with no name? - Can I have a packet with an arbitrary length name? - Can I have a packet with an arbitrary size payload? - Can I have a packet with 3 payloads? - Can I have a packet with 2 names? - Can I have a packet with no signature? - Must all nodes support all of these packet types? - Can I have an arbitrary sized T in a TLV? (I?m assuming you?re proposing TLVs, but maybe you?re planning on using XML or json for flexibility.) - Can I have an arbitrary sized L? To preempt the discussion, what part of this is architecture and what part is policy? Nacho -- Nacho (Ignacio) Solis Protocol Architect Principal Scientist Palo Alto Research Center (PARC) +1(650)812-4458 Ignacio.Solis at parc.com From tailinchu at gmail.com Fri Mar 11 16:19:01 2016 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Fri, 11 Mar 2016 16:19:01 -0800 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> Message-ID: > Is performance/efficiency not a principle at all? Do you mind explaining what performance specifically (packet encoding/decoding, forwarding, or something else)? Thanks. > On Mar 11, 2016, at 12:48 AM, Ignacio.Solis at parc.com wrote: > > >> [1] **Universality**: >> NDN should be a common network protocol for all applications and network environments. > > I?m assuming here that you imply a set of protocols. After all, the way you do flow control varies a lot from DTN to non-DTN environments. Or are you limiting this to the basic packet format? > > On the web page it calls out for DTN, IoT, Mesh networks, Web, etc. It seems obvious to me that these require various protocols; potentially layered or interoperating in some fashion. > > If one interprets this principle as ?the base protocol will allow??, then the question becomes how does the base protocol allow this. > > The document states that the protocol should be flexible and extensible. It then states that there should be no fixed parts or fixed length fields in the header. I?m unsure what the full rationale is here. Is it that we will exceed the length of the fields? Or that suddenly one field will become obsolete and we will want to remove it? Is it because we don?t want to make assumptions about packets coming in? We want them to be so flexible that anything is possible? > > In one way or another, we?re making assumptions about the packet coming in. If it?s not the static header, it?s the fact that the way we parse the packet has to be consistent. (As in, the first bit determines if the next byte is a continuation of the first byte, etc). So, to some degree, you are fixing some formatting. > > In one assumption, (fixed header), we are limiting the format and semantics of the first n bytes (8 or 16 or whatever). In the other space, you?re limiting the format (but maybe not the semantics of the first n bytes). You trade off some processing for some byte inefficiency. > > The fact that we want the same protocol to work on IoT, datacenter and interplanetary networks effectively says: > - The benefits we get from optimizing for each of these scenarios are less important than the advantage we get by having a single protocol format that runs in all. > > It seems to me that having a single protocol is useful when traffic goes from one to the other. If we don?t expect traffic to go from one to the other the benefit diminishes. Here I?m assuming native network compatible traffic. So that one packet, comes from IoT and unmodified goes to the datacenter and unmodified goes to Mars. As opposed to having gateways that can speak multiple protocols or tunneling and overlays. > > To calibrate, I?m in the camp of thinking that PIM-SM and PIM-DM are different protocols. So I would also side with the fact that if you had a situation where packets on one end of the gateway use NDN but are not understood at the other side of the gateway then the packets are effectively from 2 different protocols. > > I would also argue that if the purpose of building an extremely flexible format is to save bytes in one scenario where those are not needed at the expense of processing, then I would say that you might as well go all the way and just implement some type of link-layer compression scheme and really save some bytes. Dictionaries can go a long way. > > > Finally, going back to what?s on the page. When you say that there should be no fixed parts and no fixed length fields, do you really mean it? > - Can I have a packet with no packet_size field? > - Can I have a packet with no protocol version field? > - Can I have a packet with no name? > > - Can I have a packet with an arbitrary length name? > - Can I have a packet with an arbitrary size payload? > - Can I have a packet with 3 payloads? > - Can I have a packet with 2 names? > - Can I have a packet with no signature? > - Must all nodes support all of these packet types? > - Can I have an arbitrary sized T in a TLV? (I?m assuming you?re proposing TLVs, but maybe you?re planning on using XML or json for flexibility.) > - Can I have an arbitrary sized L? > > To preempt the discussion, what part of this is architecture and what part is policy? > > > Nacho > > > > -- > Nacho (Ignacio) Solis > Protocol Architect > Principal Scientist > Palo Alto Research Center (PARC) > +1(650)812-4458 > Ignacio.Solis at parc.com > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From mjs at cisco.com Sat Mar 12 06:58:09 2016 From: mjs at cisco.com (Mark Stapp) Date: Sat, 12 Mar 2016 09:58:09 -0500 Subject: [Ndn-interest] NDN protocol principles: no privacy? Message-ID: <56E42E81.3060407@cisco.com> I had many questions as I first read the list of "six principles" that Alex shared this week. One question was about the issue of privacy. I was somewhat surprised to see nothing in the top-six list about exposure of user activities on the internet, or about establishing a privacy baseline for the NDN architecture. Given the current level of intense and broad interest in the issues of passive observation and personal data collection, it seems to me that that topic deserves a statement of "principle". I'd like to suggest that there be an unambiguous statement that NDN will establish a level of communication privacy that uses state-of-the-art cryptography as the default. I understand that some of the exposure and correlation issues we experience currently arise from existing application protocols. HTTP can be used for activity-tracking and correlating whether or not TLS is in use, for example. A statement of principle seems like a useful way to guide development of both NDN transport features and NDN applications. At the same time, if NDN has decided that it will not establish a private-by-default baseline, I think that deserves some justification. It's clear from our experience using the IP internet that without default settings that are privacy-preserving, individuals will continue to be vulnerable. Thanks, Mark From gts at ics.uci.edu Sat Mar 12 14:30:11 2016 From: gts at ics.uci.edu (GTS) Date: Sat, 12 Mar 2016 14:30:11 -0800 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <56E42E81.3060407@cisco.com> References: <56E42E81.3060407@cisco.com> Message-ID: <56E49873.9090806@ics.uci.edu> Hi Mark, I'm a huge fan of privacy and a lot of my research privacy-related. But, I can't define "privacy". I wonder if anyone can do it precisely and succinctly? Might be because it's an amorphous and fluid notion. Perhaps if NDN folks were to include *privacy* as one of their guiding principles, it'd be like a stereotypical beauty pageant contestant who, when asked about her (or his?) ideals, comes up with something like: "Peace on Earth"? :-) On a less serious note, whenever I see things like codified "principles" (a notion similar to "commandments"), I can't help but think of a new ideology or a new cult being started. Cheers, Gene ====================== Gene Tsudik Chancellor's Professor of Computer Science University of California, Irvine On 3/12/16 6:58 AM, Mark Stapp wrote: > I had many questions as I first read the list of "six principles" that > Alex shared this week. One question was about the issue of privacy. I > was somewhat surprised to see nothing in the top-six list about > exposure of user activities on the internet, or about establishing a > privacy baseline for the NDN architecture. Given the current level of > intense and broad interest in the issues of passive observation and > personal data collection, it seems to me that that topic deserves a > statement of "principle". I'd like to suggest that there be an > unambiguous statement that NDN will establish a level of communication > privacy that uses state-of-the-art cryptography as the default. > > I understand that some of the exposure and correlation issues we > experience currently arise from existing application protocols. HTTP > can be used for activity-tracking and correlating whether or not TLS > is in use, for example. A statement of principle seems like a useful > way to guide development of both NDN transport features and NDN > applications. > > At the same time, if NDN has decided that it will not establish a > private-by-default baseline, I think that deserves some justification. > It's clear from our experience using the IP internet that without > default settings that are privacy-preserving, individuals will > continue to be vulnerable. > > Thanks, > Mark > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From mjs at cisco.com Sun Mar 13 08:41:52 2016 From: mjs at cisco.com (Mark Stapp) Date: Sun, 13 Mar 2016 11:41:52 -0400 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <56E49873.9090806@ics.uci.edu> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> Message-ID: <56E58A40.9090704@cisco.com> Hi Gene, Absolutely - I don't think there's a three- or ten-word "definition" that I've seen. but I do think it would be a valuable principle - in the sense of a high-level goal or fundamental basis for evaluating alternatives. RFC 6973 takes a nice approach, for example, by offering definitions of some technical properties and mechanisms, but not trying to formulate an overall definition of "privacy". The editors there say that the body of the document, the discussion of the tradeoffs and alternatives, is the best way they could come up with to approach that abstraction. in practical terms, as you know well I think there's been an over-reliance on opportunistic caching in ICN generally, and as a result observability and correlation are defined to be positive properties of ICN communication rather than harmful ones. I think I understand your beauty-pageant analogy - but I don't agree that it applies. It would have been different (to me, anyway) if there had been a 'principle', even it had been vague or anodyne. I really felt that it was worth commenting when there was no statement whatsoever - that felt like a real gap (again, to me). most of these six "principles" sounded like "mechanisms" to me - the list felt like the end of a discussion about alternatives and the best ways to implement an architecture, rather than the start of one. it sounded like "we're tired of questions about LPM in the PIT, so we're going to stop calling that a possible mechanism and start calling it an inevitable, immutable, unquestionable 'principle'". Thanks, Mark On 3/12/16 5:30 PM, GTS wrote: > Hi Mark, > > I'm a huge fan of privacy and a lot of my research privacy-related. > But, I can't define "privacy". I wonder if anyone can do it precisely > and succinctly? > Might be because it's an amorphous and fluid notion. > > Perhaps if NDN folks were to include *privacy* as one of their guiding > principles, > it'd be like a stereotypical beauty pageant contestant who, > when asked about her (or his?) ideals, comes up with something > like: "Peace on Earth"? > :-) > > On a less serious note, whenever I see things like codified "principles" > (a notion similar to "commandments"), I can't help but think of a new > ideology > or a new cult being started. > > Cheers, > Gene > From aa at CS.UCLA.EDU Sun Mar 13 11:58:59 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Sun, 13 Mar 2016 11:58:59 -0700 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> Message-ID: Hi Xiaoke, > On Mar 11, 2016, at 12:06 AM, Xiaoke Jiang wrote: > > Hi Alex, > This is really an interesting topics, and I tried to summarize some principles too. And here is my comments. > 1. The meaning of "NDN principle" is not very clear (at least to me). I think you do not refer to the design principle of NDN architecture itself, but more or less refer to NDN-based applications. But anyway, to clarify its meaning and usage would make it easier to understand. These principles are for the NDN networking protocol, not applications. Yes, there are some implications to the applications, but the objective is to define what the networking protocol should be and do. > 2. I would say REST-style application layer interaction. Since no session is built between producer and consumer, Interest should not rely on context of communication in order to retrieve a data. > This also relates to Interest concurrency, here I mean how many Interests can be sent in parallel. I categories the Interests to two kinds: 1) safe one, which does not change the status of producer, but "read" data only; 2) sensitive one, which may change the status. When there is sensitive Interests, the sequence of Interests is critical; otherwise, multiple Interests can be sent in parallel for better throughput. > 3. Apps do not have to worry about scalability, since multiple data source, caching and hop-by-hop flow control effectively enables app to scale its throughput. But apps should avoid to move NDN communication back to end-to-end style by building session manually. (although session may be a must for some apps.) I think these points are about application, not networking layer. One can build any type of the application on top of the networking-level provided primitives. It is just a question how much network primitives help the application. --- Alex > > Xiaoke > > On Fri, Mar 11, 2016 at 3:46 PM, Alex Afanasyev > wrote: > Dear all, > > Recently, we have been working to formalize a list of basic principles that underly the design of the NDN architecture. We have assembled the initial list of 6 principles and would like to ask everybody for the all kind of feedback about the identified principles, other potential principles, wording clarification, etc. > > We also hope that the NDN design principles will start a new round of public architectural discussions, clarifying the current and future design decisions and overall architecture objectives. > > The latest version of the principles and additional information is available on NDN website: > http://named-data.net/project/ndn-design-principles/ > > * * * > > For convenience, here is the current version of the list without additional information: > > [1] **Universality**: > NDN should be a common network protocol for all applications and network environments. > > [2] **Data-Centricity and Data Immutability**: > NDN should fetch uniquely named, immutable ?data packets? requested using ?interest packets?. > > [3] **Securing Data Directly**: > Security should be the property of data packets, staying the same whether the packets are in motion or at rest. > > [4] **Hierarchical Naming**: > Packets should carry hierarchical names to enable demultiplexing and provide structured context. > > [5] **In-Network Name Discovery**: > Interests should be able use incomplete names to retrieve data packets. > > [6] **Hop-by-Hop Flow Balance**: > Over each link, one interest packet should bring back no more than one data packet. > > * * * > > Sincerely, > Alex > > > _______________________________________________ > 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 aa at CS.UCLA.EDU Sun Mar 13 12:25:35 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Sun, 13 Mar 2016 12:25:35 -0700 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: <1EF575B5-C23B-4A3C-A162-1066FD389193@parc.com> References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> <1EF575B5-C23B-4A3C-A162-1066FD389193@parc.com> Message-ID: <2EF25D4D-6F7E-4769-BB36-80902B7542B2@cs.ucla.edu> > On Mar 11, 2016, at 12:26 AM, Ignacio.Solis at parc.com wrote: > > I think it?s great to have spelled out protocol principles. It definitely lets people discuss things in a way that distinguishes the principle from the embodiment. You can then evaluate the tradeoffs that you?re making. It also helps frame the question as to why something is a principle at all. Is it a direct benefit? Or is it just a limitation so we don?t explore the complete answer space? > > One thing that you do not touch upon, is where in the layers (or lack-of-layers), something happens. Whether something is part of the ?core/base? protocol or in a layer above it (or bellow it). What are the assumptions about what is provided bellow and what are the assumptions about what you provide at the top? Is there any structure internally that matters, if so, what? > > For example, if there is a weather data set that is 2 gigs in size, is that something that is handled by NDN, a part of NDN, or something that runs on top of NDN? This makes some of the choices of the principles have different meanings. > > The main web page for UCLA cannot be immutable. Just like my bank account cannot be immutable. Surely some part of that can be immutable, and some part of that can have a name, but I assume there is a way to name the UCLA main web page, or my bank account. Immutable data packet does **NOT** mean that the content of UCLA page cannot be changed. It means that the specific and uniquely named data packet will not ever change. The UCLA page is simply representable with differently named data packet(s) at different points of time. The whole point of the data immutability is to provide coordination in a distributed system. (I would recommend reading "Immutability Changes Everything" by P. Helland http://dx.doi.org/10.1145/2844112 and related works.) > I will make some comments on the principles in separate emails. I do have one opening question. Is performance/efficiency not a principle at all? Would we be ok with a protocol that meets all of these principles but it?s not better in performance than the alternatives? Do we think that performance comes from these principles? Do we think performance doesn?t matter? Do we think that performance doesn?t matter yet? Do we think performance will come later? Or is performance implied as an overarching goal? Performance is important, but it cannot be a principle for the networking architecture. The first priority is the goals and general principles of the architecture. Then there is engineering on how to ensure that everything can work efficiently. As a historical perspective. If "performance" was the primary goal for IP, we wouldn't have it as the whole TCP/IP stack was considered extremely inefficient (Lixia, Van, and other can add more to this). It is the superior functionality of the IP that made it widespread and then highly optimized. > Also, as a philosophical question; have you thought about framing the issue as ?these are the problems we are trying to solve? instead of ?this is what we think the end-goal is?? Among the principles, there is a little bit of mix, but of slightly different things. There is a principles that is an overarching goal (e.e., universality) and there are principles about the directions we are achieving the overarching goal. I would call the latter "the feature to realize", not problems. --- Alex > > Nacho > > PS- Yes, I realize some of these questions can apply to CCN as well. > > > -- > Nacho (Ignacio) Solis > Protocol Architect > Principal Scientist > Palo Alto Research Center (PARC) > +1(650)812-4458 > Ignacio.Solis at parc.com > > > > > > > > > On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" wrote: > >> Dear all, >> >> Recently, we have been working to formalize a list of basic principles that underly the design of the NDN architecture. We have assembled the initial list of 6 principles and would like to ask everybody for the all kind of feedback about the identified principles, other potential principles, wording clarification, etc. >> >> We also hope that the NDN design principles will start a new round of public architectural discussions, clarifying the current and future design decisions and overall architecture objectives. >> >> The latest version of the principles and additional information is available on NDN website: >> http://named-data.net/project/ndn-design-principles/ >> >> * * * >> >> For convenience, here is the current version of the list without additional information: >> >> [1] **Universality**: >> NDN should be a common network protocol for all applications and network environments. >> >> [2] **Data-Centricity and Data Immutability**: >> NDN should fetch uniquely named, immutable ?data packets? requested using ?interest packets?. >> >> [3] **Securing Data Directly**: >> Security should be the property of data packets, staying the same whether the packets are in motion or at rest. >> >> [4] **Hierarchical Naming**: >> Packets should carry hierarchical names to enable demultiplexing and provide structured context. >> >> [5] **In-Network Name Discovery**: >> Interests should be able use incomplete names to retrieve data packets. >> >> [6] **Hop-by-Hop Flow Balance**: >> Over each link, one interest packet should bring back no more than one data packet. >> >> * * * >> >> Sincerely, >> Alex >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From aa at CS.UCLA.EDU Sun Mar 13 12:54:21 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Sun, 13 Mar 2016 12:54:21 -0700 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> Message-ID: <36AE833F-2FC1-454B-84FB-5C19042CAC6C@cs.ucla.edu> > On Mar 11, 2016, at 12:48 AM, Ignacio.Solis at parc.com wrote: > > >> [1] **Universality**: >> NDN should be a common network protocol for all applications and network environments. > > I?m assuming here that you imply a set of protocols. After all, the way you do flow control varies a lot from DTN to non-DTN environments. Or are you limiting this to the basic packet format? > > On the web page it calls out for DTN, IoT, Mesh networks, Web, etc. It seems obvious to me that these require various protocols; potentially layered or interoperating in some fashion. > > If one interprets this principle as ?the base protocol will allow??, then the question becomes how does the base protocol allow this. > > The document states that the protocol should be flexible and extensible. It then states that there should be no fixed parts or fixed length fields in the header. I?m unsure what the full rationale is here. Is it that we will exceed the length of the fields? Or that suddenly one field will become obsolete and we will want to remove it? Is it because we don?t want to make assumptions about packets coming in? We want them to be so flexible that anything is possible? This is a reference to the draft we wrote some time ago (a little bit outdated at this point): https://tools.ietf.org/html/draft-icn-packet-format-requirements-00 The overarching goal is to have the universal network protocol that allows communication over various types of networking environments (very constrained MTU; not so constrained MTU) and various applications. The latter implies there is a need for additional higher-level protocols that make use of the network-provided communication primitives (and one example of this is sync). Another point is extensibility. As we tried to add in the comment section, the history with protocol developments has shown that fixed headers don't make protocol be "easily" extensible in the future. Just a few random examples: version in IP header has been never used in any meaningful way; ID, flags, Fragment Offset fields has to be present even though majority of packets don't need them. Not having fixed fields doesn't mean that there couldn't be fixed order or the current technological limit on what fields are in the packet. It is just allows a path for evolutional change. > In one way or another, we?re making assumptions about the packet coming in. If it?s not the static header, it?s the fact that the way we parse the packet has to be consistent. (As in, the first bit determines if the next byte is a continuation of the first byte, etc). So, to some degree, you are fixing some formatting. > > In one assumption, (fixed header), we are limiting the format and semantics of the first n bytes (8 or 16 or whatever). In the other space, you?re limiting the format (but maybe not the semantics of the first n bytes). You trade off some processing for some byte inefficiency. > > The fact that we want the same protocol to work on IoT, datacenter and interplanetary networks effectively says: > - The benefits we get from optimizing for each of these scenarios are less important than the advantage we get by having a single protocol format that runs in all. > > It seems to me that having a single protocol is useful when traffic goes from one to the other. That's the whole point. Because we don't have a single network protocol, we don't even think that the same (interest/data) traffic can go from one network to another. Without a single network layer protocol, we would be back in today's position of inventing a large set of various protocols that not compatible with each other (I would add http://named-data.net/wp-content/uploads/2016/02/ndn-0038-1-challenges-iot.pdf as a partial reference for this). > If we don?t expect traffic to go from one to the other the benefit diminishes. Here I?m assuming native network compatible traffic. So that one packet, comes from IoT and unmodified goes to the datacenter and unmodified goes to Mars. As opposed to having gateways that can speak multiple protocols or tunneling and overlays. > To calibrate, I?m in the camp of thinking that PIM-SM and PIM-DM are different protocols. So I would also side with the fact that if you had a situation where packets on one end of the gateway use NDN but are not understood at the other side of the gateway then the packets are effectively from 2 different protocols. > > I would also argue that if the purpose of building an extremely flexible format is to save bytes in one scenario where those are not needed at the expense of processing, then I would say that you might as well go all the way and just implement some type of link-layer compression scheme and really save some bytes. Dictionaries can go a long way. > > > Finally, going back to what?s on the page. When you say that there should be no fixed parts and no fixed length fields, do you really mean it? What we meant is that - the protocol should use only TLV to do packet NDN network-level packet representation - T an L should not be fixed to allow flexibility in supporting small and large packets. How exactly it can be achieved is a good engineering question. TLV does not mean or imply there is no "fixed" set of TLVs at a given point of time. It mean that the set can be evolutionally (not revolutionary) changed over time. -- Alex > - Can I have a packet with no packet_size field? > - Can I have a packet with no protocol version field? > - Can I have a packet with no name? > > - Can I have a packet with an arbitrary length name? > - Can I have a packet with an arbitrary size payload? > - Can I have a packet with 3 payloads? > - Can I have a packet with 2 names? > - Can I have a packet with no signature? > - Must all nodes support all of these packet types? > - Can I have an arbitrary sized T in a TLV? (I?m assuming you?re proposing TLVs, but maybe you?re planning on using XML or json for flexibility.) > - Can I have an arbitrary sized L? > > To preempt the discussion, what part of this is architecture and what part is policy? > > > Nacho -------------- 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 gts at ics.uci.edu Sun Mar 13 21:07:45 2016 From: gts at ics.uci.edu (GTS) Date: Sun, 13 Mar 2016 21:07:45 -0700 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <56E58A40.9090704@cisco.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> Message-ID: <56E63911.7020605@ics.uci.edu> Hi Mark, just to be clear: even if it can't be defined well, I'm all for privacy in any modern network architecture, NDN and CCN included. Note that NDN wouldn't have been funded by the NSF if privacy (and security) weren't prominent in the architecture. (NSF made privacy+security-by-design a major requirement for funding.) And I believe it was/is, indeed, prominent in NDN. My analogy was perhaps not the best but I was trying to say that extolling privacy as a principle might be viewed as pollyannish, (sorry for another one) a bit like Google's (in)famous "don't be evil" motto. I agree with your last paragraph about the current principles reading more like mechanisms. Cheers, Gene p.s. I also agree that opportunistic caching is a privacy concern, especially, close to the edges of the network. At the same time, I keep hearing that caching in the network core is unlikely. If that is true, privacy might be hard to achieve. Or, caching might not be used. After all, it's not mandatory, if I recall correctly (i.e., not only a router is not obliged to cache everything, but a producer can request "no caching for specific content). ====================== Gene Tsudik Chancellor's Professor of Computer Science University of California, Irvine On 3/13/16 8:41 AM, Mark Stapp wrote: > Hi Gene, > Absolutely - I don't think there's a three- or ten-word "definition" > that I've seen. but I do think it would be a valuable principle - in > the sense of a high-level goal or fundamental basis for evaluating > alternatives. RFC 6973 takes a nice approach, for example, by offering > definitions of some technical properties and mechanisms, but not > trying to formulate an overall definition of "privacy". The editors > there say that the body of the document, the discussion of the > tradeoffs and alternatives, is the best way they could come up with to > approach that abstraction. in practical terms, as you know well I > think there's been an over-reliance on opportunistic caching in ICN > generally, and as a result observability and correlation are defined > to be positive properties of ICN communication rather than harmful ones. > > I think I understand your beauty-pageant analogy - but I don't agree > that it applies. It would have been different (to me, anyway) if there > had been a 'principle', even it had been vague or anodyne. I really > felt that it was worth commenting when there was no statement > whatsoever - that felt like a real gap (again, to me). > > most of these six "principles" sounded like "mechanisms" to me - the > list felt like the end of a discussion about alternatives and the best > ways to implement an architecture, rather than the start of one. it > sounded like "we're tired of questions about LPM in the PIT, so we're > going to stop calling that a possible mechanism and start calling it > an inevitable, immutable, unquestionable 'principle'". > > Thanks, > Mark > > On 3/12/16 5:30 PM, GTS wrote: >> Hi Mark, >> >> I'm a huge fan of privacy and a lot of my research privacy-related. >> But, I can't define "privacy". I wonder if anyone can do it precisely >> and succinctly? >> Might be because it's an amorphous and fluid notion. >> >> Perhaps if NDN folks were to include *privacy* as one of their guiding >> principles, >> it'd be like a stereotypical beauty pageant contestant who, >> when asked about her (or his?) ideals, comes up with something >> like: "Peace on Earth"? >> :-) >> >> On a less serious note, whenever I see things like codified "principles" >> (a notion similar to "commandments"), I can't help but think of a new >> ideology >> or a new cult being started. >> >> Cheers, >> Gene >> > From Ignacio.Solis at parc.com Sun Mar 13 23:30:04 2016 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Mon, 14 Mar 2016 06:30:04 +0000 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> Message-ID: <643A20B7-8AE5-4CDD-991F-B943AB22114D@parc.com> On 3/11/16, 4:19 PM, "Tai-Lin Chu" wrote: >> Is performance/efficiency not a principle at all? > >Do you mind explaining what performance specifically (packet encoding/decoding, forwarding, or something else)? Sure: being better than current networks at something; anything. I don?t think the principles reflect this well. That could be faster packet encoding, faster forwarding, more resilient routing, less failures, lower latency, higher privacy, higher security, better redundancy, lower hardware cost, lower overhead (less systems required? maybe like dns or something), etc. In my opinion, there has to be some justification as to why something is a principle. Why is this principle good or required if it is not natively a good one. For example, Universality. Why is this good? Is it good because it doesn?t discriminate? Or is it good because it reduce complexity? (which in turn could be good because it reduces bugs, etc). If so, make that the goal. Make that the principle: ?to make a simpler system? or whatever. Nacho >> On Mar 11, 2016, at 12:48 AM, Ignacio.Solis at parc.com wrote: >> >> >>> [1] **Universality**: >>> NDN should be a common network protocol for all applications and network environments. >> >> I?m assuming here that you imply a set of protocols. After all, the way you do flow control varies a lot from DTN to non-DTN environments. Or are you limiting this to the basic packet format? >> >> On the web page it calls out for DTN, IoT, Mesh networks, Web, etc. It seems obvious to me that these require various protocols; potentially layered or interoperating in some fashion. >> >> If one interprets this principle as ?the base protocol will allow??, then the question becomes how does the base protocol allow this. >> >> The document states that the protocol should be flexible and extensible. It then states that there should be no fixed parts or fixed length fields in the header. I?m unsure what the full rationale is here. Is it that we will exceed the length of the fields? Or that suddenly one field will become obsolete and we will want to remove it? Is it because we don?t want to make assumptions about packets coming in? We want them to be so flexible that anything is possible? >> >> In one way or another, we?re making assumptions about the packet coming in. If it?s not the static header, it?s the fact that the way we parse the packet has to be consistent. (As in, the first bit determines if the next byte is a continuation of the first byte, etc). So, to some degree, you are fixing some formatting. >> >> In one assumption, (fixed header), we are limiting the format and semantics of the first n bytes (8 or 16 or whatever). In the other space, you?re limiting the format (but maybe not the semantics of the first n bytes). You trade off some processing for some byte inefficiency. >> >> The fact that we want the same protocol to work on IoT, datacenter and interplanetary networks effectively says: >> - The benefits we get from optimizing for each of these scenarios are less important than the advantage we get by having a single protocol format that runs in all. >> >> It seems to me that having a single protocol is useful when traffic goes from one to the other. If we don?t expect traffic to go from one to the other the benefit diminishes. Here I?m assuming native network compatible traffic. So that one packet, comes from IoT and unmodified goes to the datacenter and unmodified goes to Mars. As opposed to having gateways that can speak multiple protocols or tunneling and overlays. >> >> To calibrate, I?m in the camp of thinking that PIM-SM and PIM-DM are different protocols. So I would also side with the fact that if you had a situation where packets on one end of the gateway use NDN but are not understood at the other side of the gateway then the packets are effectively from 2 different protocols. >> >> I would also argue that if the purpose of building an extremely flexible format is to save bytes in one scenario where those are not needed at the expense of processing, then I would say that you might as well go all the way and just implement some type of link-layer compression scheme and really save some bytes. Dictionaries can go a long way. >> >> >> Finally, going back to what?s on the page. When you say that there should be no fixed parts and no fixed length fields, do you really mean it? >> - Can I have a packet with no packet_size field? >> - Can I have a packet with no protocol version field? >> - Can I have a packet with no name? >> >> - Can I have a packet with an arbitrary length name? >> - Can I have a packet with an arbitrary size payload? >> - Can I have a packet with 3 payloads? >> - Can I have a packet with 2 names? >> - Can I have a packet with no signature? >> - Must all nodes support all of these packet types? >> - Can I have an arbitrary sized T in a TLV? (I?m assuming you?re proposing TLVs, but maybe you?re planning on using XML or json for flexibility.) >> - Can I have an arbitrary sized L? >> >> To preempt the discussion, what part of this is architecture and what part is policy? >> >> >> Nacho >> >> >> >> -- >> Nacho (Ignacio) Solis >> Protocol Architect >> Principal Scientist >> Palo Alto Research Center (PARC) >> +1(650)812-4458 >> Ignacio.Solis at parc.com >> >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > From mjs at cisco.com Mon Mar 14 06:20:12 2016 From: mjs at cisco.com (Mark Stapp) Date: Mon, 14 Mar 2016 09:20:12 -0400 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <56E63911.7020605@ics.uci.edu> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E63911.7020605@ics.uci.edu> Message-ID: <56E6BA8C.6090703@cisco.com> wow - just to be clear: On 3/14/16 12:07 AM, GTS wrote: > Hi Mark, > > just to be clear: even if it can't be defined well, I'm all for privacy > in any modern network architecture, > NDN and CCN included. Note that NDN wouldn't have been funded by the NSF > if privacy (and security) > weren't prominent in the architecture. (NSF made > privacy+security-by-design a major requirement > for funding.) And I believe it was/is, indeed, prominent in NDN. > that is a statement I've heard repeated, but the deeds don't align with the words. NDN has encouraged the use of long-lived public/private key pairs, and that makes individuals highly observable, and vulnerable in the case of key compromise. I don't know whether NSF noticed, but ... you can't do your banking with this stuff yet - and it's been years. and since the folks in charge flat-out reject DH negotiation, it's a little hard to see how they're going to come up with any forward-secure approach. just exactly what privacy-by-design feature are you referring to? > My analogy was perhaps not the best but I was trying to say that > extolling privacy as a principle > might be viewed as pollyannish, (sorry for another one) a bit like > Google's (in)famous "don't be evil" > motto. > just pointing out that you began by sort of implying that the principle was already in place - and that NSF had approved of the path NDN has taken. I have heard the words you echoed in your email many times - and so I was pointing out the absence of any privacy or confidentiality 'principle' in the initial list of six. [...] > p.s. I also agree that opportunistic caching is a privacy concern, > especially, close to > the edges of the network. At the same time, I keep hearing that caching > in the network core > is unlikely. If that is true, privacy might be hard to achieve. Or, > caching might not be used. > After all, it's not mandatory, if I recall correctly (i.e., not only a > router is not obliged to > cache everything, but a producer can request "no caching for specific > content). > the issue is that some of the other NDN mechanisms, like 'sync', rely on broadcasting and shared caching. and then that becomes a fundamental basis for ... every other example - the routing protocol, the NDN-RTC scheme, etc. and of course (again, as I'm sure you know) the issue isn't that you can't _ask_ unknown routers controlled by unknown parties _not_ to observe you, or capture/record your communication. the issue is that they may act against you anyway. as an individual user, you can only limit what an adversary can do, and using best-practice communication and crypto techniques is one of the best ways we know of to accomplish that. Thanks, Mark From jburke at remap.ucla.edu Mon Mar 14 08:02:18 2016 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Mon, 14 Mar 2016 15:02:18 +0000 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <56E6BA8C.6090703@cisco.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E63911.7020605@ics.uci.edu> <56E6BA8C.6090703@cisco.com> Message-ID: >wow - just to be clear: > >On 3/14/16 12:07 AM, GTS wrote: >> Hi Mark, >> >> just to be clear: even if it can't be defined well, I'm all for privacy >> in any modern network architecture, >> NDN and CCN included. Note that NDN wouldn't have been funded by the NSF >> if privacy (and security) >> weren't prominent in the architecture. (NSF made >> privacy+security-by-design a major requirement >> for funding.) And I believe it was/is, indeed, prominent in NDN. >> > >that is a statement I've heard repeated, but the deeds don't align with >the words. NDN has encouraged the use of long-lived public/private key >pairs, and that makes individuals highly observable, and vulnerable in >the case of key compromise. I don't know whether NSF noticed, but ... >you can't do your banking with this stuff yet - and it's been years. and >since the folks in charge flat-out reject DH negotiation, it's a little >hard to see how they're going to come up with any forward-secure >approach. just exactly what privacy-by-design feature are you referring to? Mark, Where are you getting this impression of a lack of interest in security? Six of the last ten NDN tech reports deal with security-related topics, several of the techniques could be extended to use ephemeral keys, and a few have discussions of forward secrecy. > >> My analogy was perhaps not the best but I was trying to say that >> extolling privacy as a principle >> might be viewed as pollyannish, (sorry for another one) a bit like >> Google's (in)famous "don't be evil" >> motto. >> > >just pointing out that you began by sort of implying that the principle >was already in place - and that NSF had approved of the path NDN has >taken. I have heard the words you echoed in your email many times - and >so I was pointing out the absence of any privacy or confidentiality >'principle' in the initial list of six. Can you give an example or two of what such a satisfactory privacy principle might look like? (Perhaps there is disagreement about whether this is a principle for the architecture or applications, but articulating it seems valuable. We've certainly set it up as a goal for some of the current applications proposed for the current NSF work.) I think we were going to present contrasting ideas on all of this (privacy at least) at the upcoming ICNRG meeting. Is that still the plan? (I think Dirk mentioned you wouldn't be there but perhaps someone else would present?) Jeff > >[...] > >> p.s. I also agree that opportunistic caching is a privacy concern, >> especially, close to >> the edges of the network. At the same time, I keep hearing that caching >> in the network core >> is unlikely. If that is true, privacy might be hard to achieve. Or, >> caching might not be used. >> After all, it's not mandatory, if I recall correctly (i.e., not only a >> router is not obliged to >> cache everything, but a producer can request "no caching for specific >> content). >> > >the issue is that some of the other NDN mechanisms, like 'sync', rely on >broadcasting and shared caching. and then that becomes a fundamental >basis for ... every other example - the routing protocol, the NDN-RTC >scheme, etc. > >and of course (again, as I'm sure you know) the issue isn't that you >can't _ask_ unknown routers controlled by unknown parties _not_ to >observe you, or capture/record your communication. the issue is that >they may act against you anyway. as an individual user, you can only >limit what an adversary can do, and using best-practice communication >and crypto techniques is one of the best ways we know of to accomplish that. > >Thanks, >Mark >_______________________________________________ >Ndn-interest mailing list >Ndn-interest at lists.cs.ucla.edu >http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From Christopher.Wood at parc.com Mon Mar 14 08:14:06 2016 From: Christopher.Wood at parc.com (Christopher.Wood at parc.com) Date: Mon, 14 Mar 2016 15:14:06 +0000 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E63911.7020605@ics.uci.edu> <56E6BA8C.6090703@cisco.com> Message-ID: Hi Jeff, On March 14, 2016 at 8:07:08 AM, Burke, Jeff (jburke at remap.ucla.edu) wrote: > Can you give an example or two of what such a satisfactory privacy principle might look > like? (Perhaps there is disagreement about whether this is a principle for the architecture > or applications, but articulating it seems valuable. We've certainly set it up as a goal > for some of the current applications proposed for the current NSF work.) > > I think we were going to present contrasting ideas on all of this (privacy at least) at > the upcoming ICNRG meeting. Is that still the plan? (I think Dirk mentioned you wouldn't > be there but perhaps someone else would present?) I believe so. Perhaps it would be useful to coordinate before the meeting to make the most out of our time together. Can we set up a call to chat about this? Best, Chris From jburke at remap.ucla.edu Mon Mar 14 08:27:02 2016 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Mon, 14 Mar 2016 15:27:02 +0000 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <56E58A40.9090704@cisco.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> Message-ID: Mark, >Hi Gene, >Absolutely - I don't think there's a three- or ten-word "definition" >that I've seen. but I do think it would be a valuable principle - in the >sense of a high-level goal or fundamental basis for evaluating >alternatives. RFC 6973 takes a nice approach, for example, by offering >definitions of some technical properties and mechanisms, but not trying >to formulate an overall definition of "privacy". So I can try to understand your point here - do you agree with the authors that the primary privacy concerns are those of individuals? (Or, more generally, are corporations people here for this discussion - a more generic "data owner"?) >The editors there say >that the body of the document, the discussion of the tradeoffs and >alternatives, is the best way they could come up with to approach that >abstraction. in practical terms, as you know well I think there's been >an over-reliance on opportunistic caching in ICN generally, and as a >result observability and correlation are defined to be positive >properties of ICN communication rather than harmful ones. Would I be correct to parse your concerns into two pieces that may have different implications: - Confidentiality of request (e.g., the consumer side) - Confidentiality of publication (e.g., the publisher side) > >I think I understand your beauty-pageant analogy - but I don't agree >that it applies. It would have been different (to me, anyway) if there >had been a 'principle', even it had been vague or anodyne. I really felt >that it was worth commenting when there was no statement whatsoever - >that felt like a real gap (again, to me). (See my other email - would be helpful to get some strawman ideas on what this might look like.) > >most of these six "principles" sounded like "mechanisms" to me - the >list felt like the end of a discussion about alternatives and the best >ways to implement an architecture, rather than the start of one. it >sounded like "we're tired of questions about LPM in the PIT, so we're >going to stop calling that a possible mechanism and start calling it an >inevitable, immutable, unquestionable 'principle'". Well, to take LPM for an example - it's actually not mentioned in the principle doc that Alex sent. The principle I suspect that you are referring to is: [5] In-Network Name Discovery: Interests should be able use incomplete names to retrieve data packets. A consumer may not know the complete network-level name for data, as some parts of the name cannot be guessed, computed, or inferred beforehand. Once initial data is received, naming conventions can help determine complete names of other related data: * majority of interests will carry complete names * in-network name discovery expected to be used to bootstrap communication) Can you explain your objection in these terms? Thanks, Jeff > >Thanks, >Mark > >On 3/12/16 5:30 PM, GTS wrote: >> Hi Mark, >> >> I'm a huge fan of privacy and a lot of my research privacy-related. >> But, I can't define "privacy". I wonder if anyone can do it precisely >> and succinctly? >> Might be because it's an amorphous and fluid notion. >> >> Perhaps if NDN folks were to include *privacy* as one of their guiding >> principles, >> it'd be like a stereotypical beauty pageant contestant who, >> when asked about her (or his?) ideals, comes up with something >> like: "Peace on Earth"? >> :-) >> >> On a less serious note, whenever I see things like codified "principles" >> (a notion similar to "commandments"), I can't help but think of a new >> ideology >> or a new cult being started. >> >> Cheers, >> Gene >> >_______________________________________________ >Ndn-interest mailing list >Ndn-interest at lists.cs.ucla.edu >http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From gts at ics.uci.edu Mon Mar 14 09:07:08 2016 From: gts at ics.uci.edu (GTS) Date: Mon, 14 Mar 2016 09:07:08 -0700 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E63911.7020605@ics.uci.edu> <56E6BA8C.6090703@cisco.com> Message-ID: <56E6E1AC.8000103@ics.uci.edu> Jeff: just a nit, but I think Mark was talking about privacy, not security. They are often at odds with each other. Cheers, Gene ====================== Gene Tsudik Chancellor's Professor of Computer Science University of California, Irvine On 3/14/16 8:02 AM, Burke, Jeff wrote: >> ... > > Mark, > > Where are you getting this impression of a lack of interest in security? Six of the last ten NDN tech reports deal with security-related topics, several of the techniques could be extended to use ephemeral keys, and a few have discussions of forward secrecy. > > From mjs at cisco.com Mon Mar 14 09:25:27 2016 From: mjs at cisco.com (Mark Stapp) Date: Mon, 14 Mar 2016 12:25:27 -0400 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E63911.7020605@ics.uci.edu> <56E6BA8C.6090703@cisco.com> Message-ID: <56E6E5F7.2070106@cisco.com> Hi Jeff, On 3/14/16 11:02 AM, Burke, Jeff wrote: > [...] >> that is a statement I've heard repeated, but the deeds don't align with >> the words. NDN has encouraged the use of long-lived public/private key >> pairs, and that makes individuals highly observable, and vulnerable in >> the case of key compromise. I don't know whether NSF noticed, but ... >> you can't do your banking with this stuff yet - and it's been years. and >> since the folks in charge flat-out reject DH negotiation, it's a little >> hard to see how they're going to come up with any forward-secure >> approach. just exactly what privacy-by-design feature are you referring to? > > > Mark, > > Where are you getting this impression of a lack of interest in security? Six of the last ten NDN tech reports deal with security-related topics, several of the techniques could be extended to use ephemeral keys, and a few have discussions of forward secrecy. > so ... I was referring specifically to privacy, not "security" in general. having "discussions" about forward-security is not equivalent to implementing and mandating it? as long as user activity can be correlated readily, there's an exposure that seems to me to be undesireable - and it's unnecessary, given the technology that exists. the initial point I was trying to make was that it felt (to me) that there was a gap in the list of six because there was no mention of private communication. as I said in an earlier email, even having a broad statement would seem to be desireable. [...] > > > Can you give an example or two of what such a satisfactory privacy principle might look like? (Perhaps there is disagreement about whether this is a principle for the architecture or applications, but articulating it seems valuable. We've certainly set it up as a goal for some of the current applications proposed for the current NSF work.) > sure, that'd be fun: NDN communication should use, by default, best-practice cryptographic methods to ensure privacy and confidentiality. unlike IP communication, where privacy is implemented by add-on libraries and has to be "programmed in" by each application implementation, NDN will encourage use of ephemerally-keyed, forward-secure protection for all communication by making negotiation of ephemeral key material a fundamental building-block of the architecture. or, The NDN architecture shares the view of the IP community that passive and pervasive observation represents an attack on individuals' communication. NDN communication will meet or exceed the evolving best-practices for privacy, confidentiality, and authentication used in IP networking. As the internet security community advances its understanding of the vulnerabilities affecting internet communication, NDN will move in parallel to assess vulnerabilites and maintain parity with the IP technologies. > I think we were going to present contrasting ideas on all of this (privacy at least) at the upcoming ICNRG meeting. Is that still the plan? (I think Dirk mentioned you wouldn't be there but perhaps someone else would present?) > > Jeff > > I haven't looked at the agenda, but I'm certainly interested in the topic. I won't be there in person, but I've been having some conversations with Chris Wood, and I think he is planning to offer some slides. Thanks, Mark From gts at ics.uci.edu Mon Mar 14 09:34:01 2016 From: gts at ics.uci.edu (GTS) Date: Mon, 14 Mar 2016 09:34:01 -0700 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <56E6BA8C.6090703@cisco.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E63911.7020605@ics.uci.edu> <56E6BA8C.6090703@cisco.com> Message-ID: <56E6E7F9.3040400@ics.uci.edu> See below please: On 3/14/16 6:20 AM, Mark Stapp wrote: > ..... > that is a statement I've heard repeated, but the deeds don't align > with the words. NDN has encouraged the use of long-lived > public/private key pairs, and that makes individuals highly > observable, and vulnerable in the case of key compromise. I don't know > whether NSF noticed, but ... you can't do your banking with this stuff > yet - and it's been years. and since the folks in charge flat-out > reject DH negotiation, it's a little hard to see how they're going to > come up with any forward-secure approach. just exactly what > privacy-by-design feature are you referring to? > I can't speak for NDN as I have no involvement with the project in the last few years. But, if I recall correctly, NSF liked that: (1) interests have no addresses, and (2) neither does content. (Yet, both interest and content clearly point to the producer). As we all know, (1) and (2) are made possible by router caches and PIT-s. Without caching, destination addresses in interests would be unavoidable. And, without PIT-s, source addresses in interests (and destination addresses in content packets) would be needed. Having persistent public keys is indeed a privacy issue. I completely agree. >> .... > > just pointing out that you began by sort of implying that the > principle was already in place - and that NSF had approved of the path > NDN has taken. I have heard the words you echoed in your email many > times - and so I was pointing out the absence of any privacy or > confidentiality 'principle' in the initial list of six. > No, I didn't mean to imply that NDN already adheres to the lofty privacy principle. I did mean to say that it does have some privacy features, commensurate with some privacy non-features :-) or problems, i.e., I wouldn't call NDN privacy-hostile or privacy-friendly. > ... > the issue is that some of the other NDN mechanisms, like 'sync', rely > on broadcasting and shared caching. and then that becomes a > fundamental basis for ... every other example - the routing protocol, > the NDN-RTC scheme, etc. > > and of course (again, as I'm sure you know) the issue isn't that you > can't _ask_ unknown routers controlled by unknown parties _not_ to > observe you, or capture/record your communication. the issue is that > they may act against you anyway. as an individual user, you can only > limit what an adversary can do, and using best-practice communication > and crypto techniques is one of the best ways we know of to accomplish > that. > Agreed. Cheers, Gene From Ignacio.Solis at parc.com Mon Mar 14 10:52:47 2016 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Mon, 14 Mar 2016 17:52:47 +0000 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <56E6E7F9.3040400@ics.uci.edu> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E63911.7020605@ics.uci.edu> <56E6BA8C.6090703@cisco.com> <56E6E7F9.3040400@ics.uci.edu> Message-ID: <593958A8-CDCB-4E14-9979-68195D3D60BC@parc.com> On 3/14/16, 9:34 AM, "Ndn-interest on behalf of GTS" wrote: >Without caching, destination addresses in interests would be >unavoidable. And, without PIT-s, source >addresses in interests (and destination addresses in content packets) >would be needed. Since we started nitpicking... We don?t specifically need the current structure of PITs, we need some state at the routers to avoid source addresses in interests. Also, to go even further, even if we had to put source addresses in [some] interests, that doesn?t mean that they have to be in the clear. I?m also not sure how to follow that caching specifically is what allows us to avoid destination addresses. Nacho From Ignacio.Solis at parc.com Mon Mar 14 11:33:10 2016 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Mon, 14 Mar 2016 18:33:10 +0000 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: <2EF25D4D-6F7E-4769-BB36-80902B7542B2@cs.ucla.edu> References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> <1EF575B5-C23B-4A3C-A162-1066FD389193@parc.com> <2EF25D4D-6F7E-4769-BB36-80902B7542B2@cs.ucla.edu> Message-ID: On 3/13/16, 12:25 PM, "Alex Afanasyev" wrote: > >> On Mar 11, 2016, at 12:26 AM, Ignacio.Solis at parc.com wrote: >> >> I think it?s great to have spelled out protocol principles. It definitely lets people discuss things in a way that distinguishes the principle from the embodiment. You can then evaluate the tradeoffs that you?re making. It also helps frame the question as to why something is a principle at all. Is it a direct benefit? Or is it just a limitation so we don?t explore the complete answer space? >> >> One thing that you do not touch upon, is where in the layers (or lack-of-layers), something happens. Whether something is part of the ?core/base? protocol or in a layer above it (or bellow it). What are the assumptions about what is provided bellow and what are the assumptions about what you provide at the top? Is there any structure internally that matters, if so, what? >> >> For example, if there is a weather data set that is 2 gigs in size, is that something that is handled by NDN, a part of NDN, or something that runs on top of NDN? This makes some of the choices of the principles have different meanings. >> >> The main web page for UCLA cannot be immutable. Just like my bank account cannot be immutable. Surely some part of that can be immutable, and some part of that can have a name, but I assume there is a way to name the UCLA main web page, or my bank account. > >Immutable data packet does **NOT** mean that the content of UCLA page cannot be changed. It means that the specific and uniquely named data packet will not ever change. The UCLA page is simply representable with differently named data packet(s) at different points of time. The whole point of the data immutability is to provide coordination in a distributed system. > >(I would recommend reading "Immutability Changes Everything" by P. Helland http://dx.doi.org/10.1145/2844112 and related works.) Maybe it wasn?t clear that I?m in favor of Immutability at many layers. Whether we?re talking about packets, reduplicated blocks, strings in python or RDDs. My point was that it is unclear from the principles what layers we?re talking about. When people talk about NDN (or CCN for that matter) they refer to a lot of different things. So, while I?m happy to push for immutability of packets, we need to be clear where we are talking about. Also, note that the text in the web-page is a little bit misleading. Quoting from the page: "Data packet immutability allows disambiguation of coordination in distributed system that may not be always connected. Although data packets are immutable, applications can make changes to the communicated content by creating new versions of immutable data packets.? What does it mean to create ?new versions of immutable data packets?? If they are immutable, how do you make changes? My guess is that there is some other concept that is missing. The concept of a ?big object? or a group, or some other ?named entity?. And this is the thing that has versions. And each version is composed of immutable data packets. I would suggest that this must be clarified. >> I will make some comments on the principles in separate emails. I do have one opening question. Is performance/efficiency not a principle at all? Would we be ok with a protocol that meets all of these principles but it?s not better in performance than the alternatives? Do we think that performance comes from these principles? Do we think performance doesn?t matter? Do we think that performance doesn?t matter yet? Do we think performance will come later? Or is performance implied as an overarching goal? > >Performance is important, but it cannot be a principle for the networking architecture. The first priority is the goals and general principles of the architecture. Then there is engineering on how to ensure that everything can work efficiently. > >As a historical perspective. If "performance" was the primary goal for IP, we wouldn't have it as the whole TCP/IP stack was considered extremely inefficient (Lixia, Van, and other can add more to this). It is the superior functionality of the IP that made it widespread and then highly optimized. TCP/IP did have a goal to be better than the previous networks. It is true that it did not _offer_ better ?performance? than the previous networks in many areas, but the goals was to make the network better. Quoting Dave Clark[1]: "The top level goal for the DARPA Internet Architecture was to develop an effective technique for multiplexed utilization of existing interconnected networks.? Note the use of the word effective; which Dave then tries to elaborate further down the paper. Also note that Dave talks about an alternative approach and part of the issue is a way to determine which approach was the right one. Since we?re on the subject; the second level goals from Dave?s paper: 1. Internet communication must continue despite loss of networks or gateways. 2. The Internet must support multiple types of communications service. 3. The Internet architecture must accommodate a variety of networks. 4. The Internet architecture must permit distributed management of its resources. 5. The Internet architecture must be cost effective. 6. The Internet architecture must permit host attachment with a low level of effort. 7. The resources used in the internet architecture must be accountable Note that these try to focus on the goal, not how the goal is achieved. To me, the principles that were sent seem more like ?design choices?, not principles or goals. For example; why is ?Securing Data Directly? a principle/property/goal at this layer? There should be some good justification of why this was done and we didn?t choose a different approach. Why is this not a transport level issue? Or an application level issue? I?m picking this mostly because I think it should be one of the easy ones to justify, no? But the same should be true for all principles. >> Also, as a philosophical question; have you thought about framing the issue as ?these are the problems we are trying to solve? instead of ?this is what we think the end-goal is?? > >Among the principles, there is a little bit of mix, but of slightly different things. There is a principles that is an overarching goal (e.e., universality) and there are principles about the directions we are achieving the overarching goal. I would call the latter "the feature to realize", not problems. So you?re saying that the principles are not really principles? Can we then clarify, what each principle is? A goal, a problem, a design decision, etc. Nacho [1] The Design Philosophy of the DARPA Internet Protocols - http://ccr.sigcomm.org/archive/1995/jan95/ccr-9501-clark.pdf > >--- >Alex > >> >> Nacho >> >> PS- Yes, I realize some of these questions can apply to CCN as well. >> >> >> -- >> Nacho (Ignacio) Solis >> Protocol Architect >> Principal Scientist >> Palo Alto Research Center (PARC) >> +1(650)812-4458 >> Ignacio.Solis at parc.com >> >> >> >> >> >> >> >> >> On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" wrote: >> >>> Dear all, >>> >>> Recently, we have been working to formalize a list of basic principles that underly the design of the NDN architecture. We have assembled the initial list of 6 principles and would like to ask everybody for the all kind of feedback about the identified principles, other potential principles, wording clarification, etc. >>> >>> We also hope that the NDN design principles will start a new round of public architectural discussions, clarifying the current and future design decisions and overall architecture objectives. >>> >>> The latest version of the principles and additional information is available on NDN website: >>> http://named-data.net/project/ndn-design-principles/ >>> >>> * * * >>> >>> For convenience, here is the current version of the list without additional information: >>> >>> [1] **Universality**: >>> NDN should be a common network protocol for all applications and network environments. >>> >>> [2] **Data-Centricity and Data Immutability**: >>> NDN should fetch uniquely named, immutable ?data packets? requested using ?interest packets?. >>> >>> [3] **Securing Data Directly**: >>> Security should be the property of data packets, staying the same whether the packets are in motion or at rest. >>> >>> [4] **Hierarchical Naming**: >>> Packets should carry hierarchical names to enable demultiplexing and provide structured context. >>> >>> [5] **In-Network Name Discovery**: >>> Interests should be able use incomplete names to retrieve data packets. >>> >>> [6] **Hop-by-Hop Flow Balance**: >>> Over each link, one interest packet should bring back no more than one data packet. >>> >>> * * * >>> >>> Sincerely, >>> Alex >>> > From mjs at cisco.com Mon Mar 14 12:10:26 2016 From: mjs at cisco.com (Mark Stapp) Date: Mon, 14 Mar 2016 15:10:26 -0400 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> Message-ID: <56E70CA2.1080905@cisco.com> interesting - On 3/14/16 11:27 AM, Burke, Jeff wrote: > [...] RFC 6973 takes a nice approach, for example, by offering >> definitions of some technical properties and mechanisms, but not trying >> to formulate an overall definition of "privacy". > > So I can try to understand your point here - do you agree with the authors that the primary privacy concerns are those of individuals? (Or, more generally, are corporations people here for this discussion - a more generic "data owner"?) > hmm - well, I don't think corporations are people, in the citizens united sense, but I think there's lots of commercial communication that needs to have the best possible protection, whether it's B2C or B2B? >> The editors there say >> that the body of the document, the discussion of the tradeoffs and >> alternatives, is the best way they could come up with to approach that >> abstraction. in practical terms, as you know well I think there's been >> an over-reliance on opportunistic caching in ICN generally, and as a >> result observability and correlation are defined to be positive >> properties of ICN communication rather than harmful ones. > > > Would I be correct to parse your concerns into two pieces that may have different implications: > > - Confidentiality of request (e.g., the consumer side) > - Confidentiality of publication (e.g., the publisher side) > I think I have a mental image of "confidential request" - where an observer cannot see much beyond the routeable prefix needed to reach an instance of the service I want to communicate with. I'm not sure what "confidential publication" means, though? I think I want the replies to my requests to be encrypted with ephemeral, forward-secure key material, I don't want the names in the replies to expose any more than the names in the requests, and I want to be able to authenticate the service before I expose anything about my own identity or intentions. is that what you meant by "the publisher side"? [...] >> >> most of these six "principles" sounded like "mechanisms" to me - the >> list felt like the end of a discussion about alternatives and the best >> ways to implement an architecture, rather than the start of one. it >> sounded like "we're tired of questions about LPM in the PIT, so we're >> going to stop calling that a possible mechanism and start calling it an >> inevitable, immutable, unquestionable 'principle'". > > Well, to take LPM for an example - it's actually not mentioned in > the principle doc that Alex sent. The principle I suspect that you are referring to is: > > [5] In-Network Name Discovery: Interests should be able use > incomplete names to retrieve data packets. > A consumer may not know the complete network-level name for data, as some parts of the name cannot be guessed, computed, or inferred beforehand. Once initial data is received, naming conventions can help determine complete names of other related data: > > > * majority of interests will carry complete names > > * in-network name discovery expected to be used to bootstrap communication) > > > > Can you explain your objection in these terms? > sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. Thanks, Mark From luca.muscariello at gmail.com Mon Mar 14 12:59:33 2016 From: luca.muscariello at gmail.com (Luca Muscariello) Date: Mon, 14 Mar 2016 20:59:33 +0100 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <56E70CA2.1080905@cisco.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> Message-ID: Imposing that all communications must be private is in contradiction with the principle of universality as long as the network is supposed to carry any kind of application. So I disagree that privacy is a principle. Not all communications are private. Luca On Monday, 14 March 2016, Mark Stapp wrote: > interesting - > > On 3/14/16 11:27 AM, Burke, Jeff wrote: > >> >> [...] > RFC 6973 takes a nice approach, for example, by offering > >> definitions of some technical properties and mechanisms, but not trying >>> to formulate an overall definition of "privacy". >>> >> >> So I can try to understand your point here - do you agree with the >> > authors that the primary privacy concerns are those of individuals? (Or, > more generally, are corporations people here for this discussion - a > more generic "data owner"?) > >> >> > hmm - well, I don't think corporations are people, in the citizens united > sense, but I think there's lots of commercial communication that needs to > have the best possible protection, whether it's B2C or B2B? > > The editors there say >>> that the body of the document, the discussion of the tradeoffs and >>> alternatives, is the best way they could come up with to approach that >>> abstraction. in practical terms, as you know well I think there's been >>> an over-reliance on opportunistic caching in ICN generally, and as a >>> result observability and correlation are defined to be positive >>> properties of ICN communication rather than harmful ones. >>> >> >> >> Would I be correct to parse your concerns into two pieces that may >> > have different implications: > >> >> - Confidentiality of request (e.g., the consumer side) >> - Confidentiality of publication (e.g., the publisher side) >> >> > I think I have a mental image of "confidential request" - where an > observer cannot see much beyond the routeable prefix needed to reach an > instance of the service I want to communicate with. I'm not sure what > "confidential publication" means, though? I think I want the replies to my > requests to be encrypted with ephemeral, forward-secure key material, I > don't want the names in the replies to expose any more than the names in > the requests, and I want to be able to authenticate the service before I > expose anything about my own identity or intentions. is that what you meant > by "the publisher side"? > > [...] > > >>> most of these six "principles" sounded like "mechanisms" to me - the >>> list felt like the end of a discussion about alternatives and the best >>> ways to implement an architecture, rather than the start of one. it >>> sounded like "we're tired of questions about LPM in the PIT, so we're >>> going to stop calling that a possible mechanism and start calling it an >>> inevitable, immutable, unquestionable 'principle'". >>> >> >> Well, to take LPM for an example - it's actually not mentioned in >> the >> > principle doc that Alex sent. The principle I suspect that you are > referring to is: > >> >> [5] In-Network Name Discovery: Interests should be able use >> incomplete >> > names to retrieve data packets. > >> A consumer may not know the complete network-level name for data, as >> > some parts of the name cannot be guessed, computed, or inferred > beforehand. Once initial data is received, naming conventions can help > determine complete names of other related data: > >> >> >> * majority of interests will carry complete names >> >> * in-network name discovery expected to be used to bootstrap >> > communication) > >> >> >> >> Can you explain your objection in these terms? >> >> > sure - I don't want to expose names that identify me, or expose my > communication activities. given that, the "network" doesn't have the job of > finding things for me by partial names - I only want to expose the details > of my communication to a service that I have authenticated, and only when > those details are encrypted. the "names" visible to the network in that > sort of world just get the packets moving - and the only LPM needed is LPM > in the FIB to get me to one or more instances of a service. > > Thanks, > Mark > _______________________________________________ > 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 btriezen at prgs.edu Mon Mar 14 13:06:32 2016 From: btriezen at prgs.edu (Triezenberg, Bonnie) Date: Mon, 14 Mar 2016 20:06:32 +0000 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> Message-ID: <92E8242CE49E5247B77E5C843C582457477387EC@smmb1.rand.org> Although not all communications are private, it does not follow that a network should be designed such that it is impossible obtain privacy or violates the privacy of communication?. Perhaps the principle is instead the ?ability to preserve privacy? of communication. bonnie From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Luca Muscariello Sent: Monday, March 14, 2016 1:00 PM To: Mark Stapp Cc: UCLA NDN List Subject: Re: [Ndn-interest] NDN protocol principles: no privacy? Imposing that all communications must be private is in contradiction with the principle of universality as long as the network is supposed to carry any kind of application. So I disagree that privacy is a principle. Not all communications are private. Luca On Monday, 14 March 2016, Mark Stapp > wrote: interesting - On 3/14/16 11:27 AM, Burke, Jeff wrote: [...] RFC 6973 takes a nice approach, for example, by offering definitions of some technical properties and mechanisms, but not trying to formulate an overall definition of "privacy". So I can try to understand your point here - do you agree with the authors that the primary privacy concerns are those of individuals? (Or, more generally, are corporations people here for this discussion - a more generic "data owner"?) hmm - well, I don't think corporations are people, in the citizens united sense, but I think there's lots of commercial communication that needs to have the best possible protection, whether it's B2C or B2B? The editors there say that the body of the document, the discussion of the tradeoffs and alternatives, is the best way they could come up with to approach that abstraction. in practical terms, as you know well I think there's been an over-reliance on opportunistic caching in ICN generally, and as a result observability and correlation are defined to be positive properties of ICN communication rather than harmful ones. Would I be correct to parse your concerns into two pieces that may have different implications: - Confidentiality of request (e.g., the consumer side) - Confidentiality of publication (e.g., the publisher side) I think I have a mental image of "confidential request" - where an observer cannot see much beyond the routeable prefix needed to reach an instance of the service I want to communicate with. I'm not sure what "confidential publication" means, though? I think I want the replies to my requests to be encrypted with ephemeral, forward-secure key material, I don't want the names in the replies to expose any more than the names in the requests, and I want to be able to authenticate the service before I expose anything about my own identity or intentions. is that what you meant by "the publisher side"? [...] most of these six "principles" sounded like "mechanisms" to me - the list felt like the end of a discussion about alternatives and the best ways to implement an architecture, rather than the start of one. it sounded like "we're tired of questions about LPM in the PIT, so we're going to stop calling that a possible mechanism and start calling it an inevitable, immutable, unquestionable 'principle'". Well, to take LPM for an example - it's actually not mentioned in the principle doc that Alex sent. The principle I suspect that you are referring to is: [5] In-Network Name Discovery: Interests should be able use incomplete names to retrieve data packets. A consumer may not know the complete network-level name for data, as some parts of the name cannot be guessed, computed, or inferred beforehand. Once initial data is received, naming conventions can help determine complete names of other related data: * majority of interests will carry complete names * in-network name discovery expected to be used to bootstrap communication) Can you explain your objection in these terms? sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. Thanks, Mark _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest __________________________________________________________________________ This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjs at cisco.com Mon Mar 14 13:14:20 2016 From: mjs at cisco.com (Mark Stapp) Date: Mon, 14 Mar 2016 16:14:20 -0400 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> Message-ID: <56E71B9C.1070506@cisco.com> ok, but - my suggestion is that the _default_ should be private, not that there should not be a way for an application to _ask_ for non-private. I'm hoping that the ongoing discussion will bring out some examples of communication that folks think _belongs_ in-the-clear - where some property of the application involved will be compromised if the communication is strongly protected and confidential. I think that it's going to be difficult to make much of a case there, given the capabilities that well-designed applications offer in the current internet, but it'd be interesting to hear the examples. and ... I have to say that I don't understand the "principle of universality", so ... I think that might be its own thread? -- Mark On 3/14/16 3:59 PM, Luca Muscariello wrote: > Imposing that all communications must be private is in contradiction > with the principle of universality as long as the network is supposed to > carry any kind of application. > > So I disagree that privacy is a principle. > Not all communications are private. > > Luca > > From luca.muscariello at gmail.com Mon Mar 14 13:45:46 2016 From: luca.muscariello at gmail.com (Luca Muscariello) Date: Mon, 14 Mar 2016 21:45:46 +0100 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <56E71B9C.1070506@cisco.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> <56E71B9C.1070506@cisco.com> Message-ID: To my understanding, principles are rules that are mutually exclusive and from which other rules can be derived. They are not axioms though. You can disagree. In the case of privacy, even if you run the network in such default mode, this cannot be a principle as I cannot derive non private communications from private communications unless I negate the principle. So It's not a principle. Requiring security on data seems like a principle though as you can build on this to create private and non private communications. On Monday, 14 March 2016, Mark Stapp wrote: > ok, but - my suggestion is that the _default_ should be private, not that > there should not be a way for an application to _ask_ for non-private. > > I'm hoping that the ongoing discussion will bring out some examples of > communication that folks think _belongs_ in-the-clear - where some property > of the application involved will be compromised if the communication is > strongly protected and confidential. I think that it's going to be > difficult to make much of a case there, given the capabilities that > well-designed applications offer in the current internet, but it'd be > interesting to hear the examples. > > and ... I have to say that I don't understand the "principle of > universality", so ... I think that might be its own thread? > > -- Mark > > On 3/14/16 3:59 PM, Luca Muscariello wrote: > >> Imposing that all communications must be private is in contradiction >> with the principle of universality as long as the network is supposed to >> carry any kind of application. >> >> So I disagree that privacy is a principle. >> Not all communications are private. >> >> Luca >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ignacio.Solis at parc.com Mon Mar 14 15:52:30 2016 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Mon, 14 Mar 2016 22:52:30 +0000 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: <36AE833F-2FC1-454B-84FB-5C19042CAC6C@cs.ucla.edu> References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> <36AE833F-2FC1-454B-84FB-5C19042CAC6C@cs.ucla.edu> Message-ID: <8F51EBC4-7274-448C-98D8-62A5333E372D@parc.com> On 3/13/16, 12:54 PM, "Alex Afanasyev" wrote: >> On Mar 11, 2016, at 12:48 AM, Ignacio.Solis at parc.com wrote: >> >> >>> [1] **Universality**: >>> NDN should be a common network protocol for all applications and network environments. >> >> I?m assuming here that you imply a set of protocols. After all, the way you do flow control varies a lot from DTN to non-DTN environments. Or are you limiting this to the basic packet format? >> >> On the web page it calls out for DTN, IoT, Mesh networks, Web, etc. It seems obvious to me that these require various protocols; potentially layered or interoperating in some fashion. >> >> If one interprets this principle as ?the base protocol will allow??, then the question becomes how does the base protocol allow this. >> >> The document states that the protocol should be flexible and extensible. It then states that there should be no fixed parts or fixed length fields in the header. I?m unsure what the full rationale is here. Is it that we will exceed the length of the fields? Or that suddenly one field will become obsolete and we will want to remove it? Is it because we don?t want to make assumptions about packets coming in? We want them to be so flexible that anything is possible? > >This is a reference to the draft we wrote some time ago (a little bit outdated at this point): https://tools.ietf.org/html/draft-icn-packet-format-requirements-00 > >The overarching goal is to have the universal network protocol that allows communication over various types of networking environments (very constrained MTU; not so constrained MTU) and various applications. The latter implies there is a need for additional higher-level protocols that make use of the network-provided communication primitives (and one example of this is sync). > >Another point is extensibility. As we tried to add in the comment section, the history with protocol developments has shown that fixed headers don't make protocol be "easily" extensible in the future. Just a few random examples: version in IP header has been never used in any meaningful way; ID, flags, Fragment Offset fields has to be present even though majority of packets don't need them. > >Not having fixed fields doesn't mean that there couldn't be fixed order or the current technological limit on what fields are in the packet. It is just allows a path for evolutional change. I understand that people have used the fact that IP was a problem as one of the big drivers for why we want to change; but the truth is IP has been very successful. If we are as successful with NDN/CCN as IP has been, we (at least I) would consider this a great victory. You are using the example of IP having a version field that has never been used in a meaningful way. Don?t you think this is the exact same issue you?ll see with a flexible packet? The version field in IP _gives_ you the flexibility to change, and yet, we didn?t use it. It?s hard to evolve protocols once deployed. This is true whether the encoding is flexible or strict. If you have a protocol that allows the size to be 8 bytes long for example, every data structure in the network will have to support that. Otherwise you will have devices that cannot handle the protocol. So, effectively, by having a size field that is 8 bytes long to allow the transfer of terabyte packets, you just made small sensor devices require the ability to process terabyte packets. Maybe this is exactly what you meant, to have sensor networks be required to process 18 exabyte packets; in my view this is not a good idea. You?re going to end up with devices that cannot process 18 exabyte packets and as such will not be able to meet the NDN standard. So, if your NDN IoT device cannot handle the 18 exabyte packet (which the current spec allows), is it actually doing NDN? Or is it doing another protocol NDN-lite? >> In one way or another, we?re making assumptions about the packet coming in. If it?s not the static header, it?s the fact that the way we parse the packet has to be consistent. (As in, the first bit determines if the next byte is a continuation of the first byte, etc). So, to some degree, you are fixing some formatting. >> >> In one assumption, (fixed header), we are limiting the format and semantics of the first n bytes (8 or 16 or whatever). In the other space, you?re limiting the format (but maybe not the semantics of the first n bytes). You trade off some processing for some byte inefficiency. >> >> The fact that we want the same protocol to work on IoT, datacenter and interplanetary networks effectively says: >> - The benefits we get from optimizing for each of these scenarios are less important than the advantage we get by having a single protocol format that runs in all. >> >> It seems to me that having a single protocol is useful when traffic goes from one to the other. > >That's the whole point. Because we don't have a single network protocol, we don't even think that the same (interest/data) traffic can go from one network to another. > >Without a single network layer protocol, we would be back in today's position of inventing a large set of various protocols that not compatible with each other (I would add http://named-data.net/wp-content/uploads/2016/02/ndn-0038-1-challenges-iot.pdf as a partial reference for this). There are many ways to pass data from one network to another. We do that today even when the networks speak the same protocol. Sometimes we mandate that. I don?t think this necessarily makes a good case for why universality is good. >> If we don?t expect traffic to go from one to the other the benefit diminishes. Here I?m assuming native network compatible traffic. So that one packet, comes from IoT and unmodified goes to the datacenter and unmodified goes to Mars. As opposed to having gateways that can speak multiple protocols or tunneling and overlays. > >> To calibrate, I?m in the camp of thinking that PIM-SM and PIM-DM are different protocols. So I would also side with the fact that if you had a situation where packets on one end of the gateway use NDN but are not understood at the other side of the gateway then the packets are effectively from 2 different protocols. >> >> I would also argue that if the purpose of building an extremely flexible format is to save bytes in one scenario where those are not needed at the expense of processing, then I would say that you might as well go all the way and just implement some type of link-layer compression scheme and really save some bytes. Dictionaries can go a long way. >> >> >> Finally, going back to what?s on the page. When you say that there should be no fixed parts and no fixed length fields, do you really mean it? > >What we meant is that >- the protocol should use only TLV to do packet NDN network-level packet representation >- T an L should not be fixed to allow flexibility in supporting small and large packets. > >How exactly it can be achieved is a good engineering question. > >TLV does not mean or imply there is no "fixed" set of TLVs at a given point of time. It mean that the set can be evolutionally (not revolutionary) changed over time. The fact that we use TLV _is_ an engineering decision. We could have used XML or JSON. Having flexible T?s and L?s that can take any size is not a good thing. It means you can constrain the design of your network elements without breaking the protocols. I would still like the following questions answered: >> - Can I have a packet with no packet_size field? >> - Can I have a packet with no protocol version field? >> - Can I have a packet with no name? >> >> - Can I have a packet with an arbitrary length name? >> - Can I have a packet with an arbitrary size payload? >> - Can I have a packet with 3 payloads? >> - Can I have a packet with 2 names? >> - Can I have a packet with no signature? >> - Must all nodes support all of these packet types? >> - Can I have an arbitrary sized T in a TLV? (I?m assuming you?re proposing TLVs, but maybe you?re planning on using XML or json for flexibility.) >> - Can I have an arbitrary sized L? >> >> To preempt the discussion, what part of this is architecture and what part is policy? Nacho From Ignacio.Solis at parc.com Mon Mar 14 16:09:34 2016 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Mon, 14 Mar 2016 23:09:34 +0000 Subject: [Ndn-interest] Hop-by-Hop Flow Balance Message-ID: [ Disclaimer: CCN currently uses flow balance as well ] The current Hop-by-Hop Flow Balance is nonsense. On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" wrote: >[6] **Hop-by-Hop Flow Balance**: > Over each link, one interest packet should bring back no more than one data packet. Seriously, who thinks this actually works? Let me quote the webpage ( http://named-data.net/project/ndn-design-principles/ ): "[6] Hop-by-Hop Flow Balancing: Over each link, one interest packet should bring back no more than one data packet. Hop-by-hop flow balancing enables each node to control load over its links. By deciding to sending interest over a link, router commits bandwidth for the returned data. By limiting the number of interests sent, each router and client node in the network control how much data it will receive. " Either there is a lot of information missing here to justify why this is so, or this is very na?ve. First, if what you want to do is limit the number of content objects (or packets) returned, you don?t need to send one interest. _Specially_ for NDN, which has prefix matching, you could send one interest with a count number (10) and expect to receive 10 content objects back. There is no reason why I need to send 10 exact copies of the same interest. Even if the interests had small variations, why send 10? Why not send 1 + the 10 deltas? I guess it?s possible you may call that part of the ?network adaptation layer?, who knows. Also by requiring 1-to-1, you are always requiring an overhead (on the requester side) that is quite high. If you think of today?s type of networks, where a packet (internet sized) is around 1500 bytes, that means that even if we send interests of 30 bytes, we are incurring quite a bit of overhead in the upstream. This becomes considerable when doing high bandwidth video. Please explain why the 1-to-1 is good. Second, NDN allows very large packet sizes. So, when I send 1 interest, I don?t now if what I?m going to get back is 1 byte or 18 exabytes. How do routers use this information to control how much data they?re going to receive? Are they going to reserve 18 exabytes of traffic time? If this principle were to be re-written as: ?Allow network nodes to participate in flow control? then the actual engineering solution might be able to achieve this. Finally, at least we should acknowledge the limitations this type of approach requires; like symmetrical forwarding. It would be awkward if the only way for NDN to work over Satellite links would be to break the principles. Nacho PS. Yes, there are people in this community who have looked at other ways to do flow-balance and flow-control. Maybe we should be learning from those and not just claiming as principle what we do today because we don?t want it questioned. -- Nacho (Ignacio) Solis Protocol Architect Principal Scientist Palo Alto Research Center (PARC) +1(650)812-4458 Ignacio.Solis at parc.com From tailinchu at gmail.com Mon Mar 14 20:15:10 2016 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Mon, 14 Mar 2016 20:15:10 -0700 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: <8F51EBC4-7274-448C-98D8-62A5333E372D@parc.com> References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> <36AE833F-2FC1-454B-84FB-5C19042CAC6C@cs.ucla.edu> <8F51EBC4-7274-448C-98D8-62A5333E372D@parc.com> Message-ID: <5E0918F2-0AD7-4A5E-A10F-B0099A2E6EA0@gmail.com> > You are using the example of IP having a version field that has never been used in a meaningful way. Don?t you think this is the exact same issue you?ll see with a flexible packet? The version field in IP _gives_ you the flexibility to change, and yet, we didn?t use it. ? It?s hard to evolve protocols once deployed. From your analysis, I don?t see that having version number is better than without it. I can come up with pros and cons for either side, but for simplicity, it is better to leave it out. > If you have a protocol that allows the size to be 8 bytes long for example, every data structure in the network will have to support that. This is an implementation decision: you can have devices that support tlv with size up to a certain limit. I think NDN?s current approach on this is fine because it is still possible that this size limit will increase rapidly as technology advances. It will be unwise to limit this at this point to two bytes. (I understand it will be (a lot) more efficient if this size is not encoded in variable-length number.) > There are many ways to pass data from one network to another. We do that today even when the networks speak the same protocol. Sometimes we mandate that. Universality by itself is good due to the overhead of inter-protocol conversion. This is a huge simplicity win for management. What I don?t want to see is that NDN becomes yet another future internet protocol. I hope I am not too rude for the comments above; I intend to make them short. Thanks. > On Mar 14, 2016, at 3:52 PM, wrote: > > On 3/13/16, 12:54 PM, "Alex Afanasyev" > wrote: > > >>> On Mar 11, 2016, at 12:48 AM, Ignacio.Solis at parc.com wrote: >>> >>> >>>> [1] **Universality**: >>>> NDN should be a common network protocol for all applications and network environments. >>> >>> I?m assuming here that you imply a set of protocols. After all, the way you do flow control varies a lot from DTN to non-DTN environments. Or are you limiting this to the basic packet format? >>> >>> On the web page it calls out for DTN, IoT, Mesh networks, Web, etc. It seems obvious to me that these require various protocols; potentially layered or interoperating in some fashion. >>> >>> If one interprets this principle as ?the base protocol will allow??, then the question becomes how does the base protocol allow this. >>> >>> The document states that the protocol should be flexible and extensible. It then states that there should be no fixed parts or fixed length fields in the header. I?m unsure what the full rationale is here. Is it that we will exceed the length of the fields? Or that suddenly one field will become obsolete and we will want to remove it? Is it because we don?t want to make assumptions about packets coming in? We want them to be so flexible that anything is possible? >> >> This is a reference to the draft we wrote some time ago (a little bit outdated at this point): https://tools.ietf.org/html/draft-icn-packet-format-requirements-00 >> >> The overarching goal is to have the universal network protocol that allows communication over various types of networking environments (very constrained MTU; not so constrained MTU) and various applications. The latter implies there is a need for additional higher-level protocols that make use of the network-provided communication primitives (and one example of this is sync). >> >> Another point is extensibility. As we tried to add in the comment section, the history with protocol developments has shown that fixed headers don't make protocol be "easily" extensible in the future. Just a few random examples: version in IP header has been never used in any meaningful way; ID, flags, Fragment Offset fields has to be present even though majority of packets don't need them. >> >> Not having fixed fields doesn't mean that there couldn't be fixed order or the current technological limit on what fields are in the packet. It is just allows a path for evolutional change. > > > I understand that people have used the fact that IP was a problem as one of the big drivers for why we want to change; but the truth is IP has been very successful. If we are as successful with NDN/CCN as IP has been, we (at least I) would consider this a great victory. > > You are using the example of IP having a version field that has never been used in a meaningful way. Don?t you think this is the exact same issue you?ll see with a flexible packet? The version field in IP _gives_ you the flexibility to change, and yet, we didn?t use it. > > It?s hard to evolve protocols once deployed. This is true whether the encoding is flexible or strict. > > If you have a protocol that allows the size to be 8 bytes long for example, every data structure in the network will have to support that. Otherwise you will have devices that cannot handle the protocol. So, effectively, by having a size field that is 8 bytes long to allow the transfer of terabyte packets, you just made small sensor devices require the ability to process terabyte packets. Maybe this is exactly what you meant, to have sensor networks be required to process 18 exabyte packets; in my view this is not a good idea. > > You?re going to end up with devices that cannot process 18 exabyte packets and as such will not be able to meet the NDN standard. > > So, if your NDN IoT device cannot handle the 18 exabyte packet (which the current spec allows), is it actually doing NDN? Or is it doing another protocol NDN-lite? > > > > >>> In one way or another, we?re making assumptions about the packet coming in. If it?s not the static header, it?s the fact that the way we parse the packet has to be consistent. (As in, the first bit determines if the next byte is a continuation of the first byte, etc). So, to some degree, you are fixing some formatting. >>> >>> In one assumption, (fixed header), we are limiting the format and semantics of the first n bytes (8 or 16 or whatever). In the other space, you?re limiting the format (but maybe not the semantics of the first n bytes). You trade off some processing for some byte inefficiency. >>> >>> The fact that we want the same protocol to work on IoT, datacenter and interplanetary networks effectively says: >>> - The benefits we get from optimizing for each of these scenarios are less important than the advantage we get by having a single protocol format that runs in all. >>> >>> It seems to me that having a single protocol is useful when traffic goes from one to the other. >> >> That's the whole point. Because we don't have a single network protocol, we don't even think that the same (interest/data) traffic can go from one network to another. >> >> Without a single network layer protocol, we would be back in today's position of inventing a large set of various protocols that not compatible with each other (I would add http://named-data.net/wp-content/uploads/2016/02/ndn-0038-1-challenges-iot.pdf as a partial reference for this). > > There are many ways to pass data from one network to another. We do that today even when the networks speak the same protocol. Sometimes we mandate that. > > I don?t think this necessarily makes a good case for why universality is good. > > > >>> If we don?t expect traffic to go from one to the other the benefit diminishes. Here I?m assuming native network compatible traffic. So that one packet, comes from IoT and unmodified goes to the datacenter and unmodified goes to Mars. As opposed to having gateways that can speak multiple protocols or tunneling and overlays. >> >>> To calibrate, I?m in the camp of thinking that PIM-SM and PIM-DM are different protocols. So I would also side with the fact that if you had a situation where packets on one end of the gateway use NDN but are not understood at the other side of the gateway then the packets are effectively from 2 different protocols. >>> >>> I would also argue that if the purpose of building an extremely flexible format is to save bytes in one scenario where those are not needed at the expense of processing, then I would say that you might as well go all the way and just implement some type of link-layer compression scheme and really save some bytes. Dictionaries can go a long way. >>> >>> >>> Finally, going back to what?s on the page. When you say that there should be no fixed parts and no fixed length fields, do you really mean it? >> >> What we meant is that >> - the protocol should use only TLV to do packet NDN network-level packet representation >> - T an L should not be fixed to allow flexibility in supporting small and large packets. >> >> How exactly it can be achieved is a good engineering question. >> >> TLV does not mean or imply there is no "fixed" set of TLVs at a given point of time. It mean that the set can be evolutionally (not revolutionary) changed over time. > > The fact that we use TLV _is_ an engineering decision. We could have used XML or JSON. Having flexible T?s and L?s that can take any size is not a good thing. It means you can constrain the design of your network elements without breaking the protocols. > > I would still like the following questions answered: > >>> - Can I have a packet with no packet_size field? >>> - Can I have a packet with no protocol version field? >>> - Can I have a packet with no name? >>> >>> - Can I have a packet with an arbitrary length name? >>> - Can I have a packet with an arbitrary size payload? >>> - Can I have a packet with 3 payloads? >>> - Can I have a packet with 2 names? >>> - Can I have a packet with no signature? >>> - Must all nodes support all of these packet types? >>> - Can I have an arbitrary sized T in a TLV? (I?m assuming you?re proposing TLVs, but maybe you?re planning on using XML or json for flexibility.) >>> - Can I have an arbitrary sized L? >>> >>> To preempt the discussion, what part of this is architecture and what part is policy? > > Nacho > > > _______________________________________________ > 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 Mon Mar 14 20:44:08 2016 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Mon, 14 Mar 2016 20:44:08 -0700 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <56E70CA2.1080905@cisco.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> Message-ID: <1870C141-6751-4065-9377-8FE8E104C477@gmail.com> > sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. Immutability is related to in-network discovery with LPM. If all packets are immutable, and there is no in-network discovery, ndn must rely on some other protocol that cannot not build on top of ndn for discovery (we should all agree that randomly guessing a version number or a certain name is not going to work well as ?discovery?). This devalues ndn as an ?universal" protocol. > On Mar 14, 2016, at 12:10 PM, Mark Stapp wrote: > > interesting - > > On 3/14/16 11:27 AM, Burke, Jeff wrote: >> > [...] > RFC 6973 takes a nice approach, for example, by offering >>> definitions of some technical properties and mechanisms, but not trying >>> to formulate an overall definition of "privacy". >> >> So I can try to understand your point here - do you agree with the > authors that the primary privacy concerns are those of individuals? (Or, > more generally, are corporations people here for this discussion - a > more generic "data owner"?) >> > > hmm - well, I don't think corporations are people, in the citizens united sense, but I think there's lots of commercial communication that needs to have the best possible protection, whether it's B2C or B2B? > >>> The editors there say >>> that the body of the document, the discussion of the tradeoffs and >>> alternatives, is the best way they could come up with to approach that >>> abstraction. in practical terms, as you know well I think there's been >>> an over-reliance on opportunistic caching in ICN generally, and as a >>> result observability and correlation are defined to be positive >>> properties of ICN communication rather than harmful ones. >> >> >> Would I be correct to parse your concerns into two pieces that may > have different implications: >> >> - Confidentiality of request (e.g., the consumer side) >> - Confidentiality of publication (e.g., the publisher side) >> > > I think I have a mental image of "confidential request" - where an observer cannot see much beyond the routeable prefix needed to reach an instance of the service I want to communicate with. I'm not sure what "confidential publication" means, though? I think I want the replies to my requests to be encrypted with ephemeral, forward-secure key material, I don't want the names in the replies to expose any more than the names in the requests, and I want to be able to authenticate the service before I expose anything about my own identity or intentions. is that what you meant by "the publisher side"? > > [...] > >>> >>> most of these six "principles" sounded like "mechanisms" to me - the >>> list felt like the end of a discussion about alternatives and the best >>> ways to implement an architecture, rather than the start of one. it >>> sounded like "we're tired of questions about LPM in the PIT, so we're >>> going to stop calling that a possible mechanism and start calling it an >>> inevitable, immutable, unquestionable 'principle'". >> >> Well, to take LPM for an example - it's actually not mentioned in >> the > principle doc that Alex sent. The principle I suspect that you are > referring to is: >> >> [5] In-Network Name Discovery: Interests should be able use >> incomplete > names to retrieve data packets. >> A consumer may not know the complete network-level name for data, as > some parts of the name cannot be guessed, computed, or inferred > beforehand. Once initial data is received, naming conventions can help > determine complete names of other related data: >> >> >> * majority of interests will carry complete names >> >> * in-network name discovery expected to be used to bootstrap > communication) >> >> >> >> Can you explain your objection in these terms? >> > > sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. > > Thanks, > Mark > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From Marc.Mosko at parc.com Mon Mar 14 21:01:49 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Tue, 15 Mar 2016 04:01:49 +0000 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <1870C141-6751-4065-9377-8FE8E104C477@gmail.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> <1870C141-6751-4065-9377-8FE8E104C477@gmail.com> Message-ID: > On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu wrote: > >> sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. > > Immutability is related to in-network discovery with LPM. If all packets are immutable, and there is no in-network discovery, ndn must rely on some other protocol that cannot not build on top of ndn for discovery (we should all agree that randomly guessing a version number or a certain name is not going to work well as ?discovery?). This devalues ndn as an ?universal" protocol. Could you please define immutable? Do you mean that a single publisher will never use the same name for different contents? Is that mandatory or enforceable? Or do you mean that there is some cryptographic function possible on a packet such that one can detect if it changes? Are those cryptographic primitives mandatory in each packet? I disagree that it is a necessary condition that one have name suffix completion matching of a data object to an interest to facilitate discovery. One can build a discovery protocol over exact name matching. I usually build these where the cache returns a chunked table of contents listing possible matches instead of the CCNx 0.x / NDN approach of having to return a (potentially very large) data object and walk a tree which is really only efficient if you expect what you want to be left-most or right-most child and not require iteration. > > >> On Mar 14, 2016, at 12:10 PM, Mark Stapp wrote: >> >> interesting - >> >> On 3/14/16 11:27 AM, Burke, Jeff wrote: >>> >> [...] >> RFC 6973 takes a nice approach, for example, by offering >>>> definitions of some technical properties and mechanisms, but not trying >>>> to formulate an overall definition of "privacy". >>> >>> So I can try to understand your point here - do you agree with the >> authors that the primary privacy concerns are those of individuals? (Or, >> more generally, are corporations people here for this discussion - a >> more generic "data owner"?) >>> >> >> hmm - well, I don't think corporations are people, in the citizens united sense, but I think there's lots of commercial communication that needs to have the best possible protection, whether it's B2C or B2B? >> >>>> The editors there say >>>> that the body of the document, the discussion of the tradeoffs and >>>> alternatives, is the best way they could come up with to approach that >>>> abstraction. in practical terms, as you know well I think there's been >>>> an over-reliance on opportunistic caching in ICN generally, and as a >>>> result observability and correlation are defined to be positive >>>> properties of ICN communication rather than harmful ones. >>> >>> >>> Would I be correct to parse your concerns into two pieces that may >> have different implications: >>> >>> - Confidentiality of request (e.g., the consumer side) >>> - Confidentiality of publication (e.g., the publisher side) >>> >> >> I think I have a mental image of "confidential request" - where an observer cannot see much beyond the routeable prefix needed to reach an instance of the service I want to communicate with. I'm not sure what "confidential publication" means, though? I think I want the replies to my requests to be encrypted with ephemeral, forward-secure key material, I don't want the names in the replies to expose any more than the names in the requests, and I want to be able to authenticate the service before I expose anything about my own identity or intentions. is that what you meant by "the publisher side"? >> >> [...] >> >>>> >>>> most of these six "principles" sounded like "mechanisms" to me - the >>>> list felt like the end of a discussion about alternatives and the best >>>> ways to implement an architecture, rather than the start of one. it >>>> sounded like "we're tired of questions about LPM in the PIT, so we're >>>> going to stop calling that a possible mechanism and start calling it an >>>> inevitable, immutable, unquestionable 'principle'". >>> >>> Well, to take LPM for an example - it's actually not mentioned in >>> the >> principle doc that Alex sent. The principle I suspect that you are >> referring to is: >>> >>> [5] In-Network Name Discovery: Interests should be able use >>> incomplete >> names to retrieve data packets. >>> A consumer may not know the complete network-level name for data, as >> some parts of the name cannot be guessed, computed, or inferred >> beforehand. Once initial data is received, naming conventions can help >> determine complete names of other related data: >>> >>> >>> * majority of interests will carry complete names >>> >>> * in-network name discovery expected to be used to bootstrap >> communication) >>> >>> >>> >>> Can you explain your objection in these terms? >>> >> >> sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. >> >> Thanks, >> Mark >> _______________________________________________ >> 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 tailinchu at gmail.com Mon Mar 14 21:53:40 2016 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Mon, 14 Mar 2016 21:53:40 -0700 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> <1870C141-6751-4065-9377-8FE8E104C477@gmail.com> Message-ID: <75438CDD-729A-412E-884B-BDE018E9AE32@gmail.com> Immutable = one data packet cannot be changed after publication. No, it is not ?a single publisher will never use the same name for different contents? (I believe this is "uniquely named") nor ?there is some cryptographic function possible on a packet such that one can detect if it changes?. Immutability is advisory here. If I start to violate immutablity in a distributed system where everything is assumed to be immutable, I am doomed to get incorrect result (I guess this sounds mandatory). I think immutability is a good choice overall, and it is better to state it as a principle so that nobody will use ndn the wrong way. > One can build a discovery protocol over exact name matching. Is the table of contents immutable? I think your approach is fine and efficient but it is rather hard to manage in a large distributed system if the table is not immutable. > On Mar 14, 2016, at 9:01 PM, wrote: > >> >> On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu > wrote: >> >>> sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. >> >> Immutability is related to in-network discovery with LPM. If all packets are immutable, and there is no in-network discovery, ndn must rely on some other protocol that cannot not build on top of ndn for discovery (we should all agree that randomly guessing a version number or a certain name is not going to work well as ?discovery?). This devalues ndn as an ?universal" protocol. > > Could you please define immutable? Do you mean that a single publisher will never use the same name for different contents? Is that mandatory or enforceable? Or do you mean that there is some cryptographic function possible on a packet such that one can detect if it changes? Are those cryptographic primitives mandatory in each packet? > > I disagree that it is a necessary condition that one have name suffix completion matching of a data object to an interest to facilitate discovery. One can build a discovery protocol over exact name matching. I usually build these where the cache returns a chunked table of contents listing possible matches instead of the CCNx 0.x / NDN approach of having to return a (potentially very large) data object and walk a tree which is really only efficient if you expect what you want to be left-most or right-most child and not require iteration. > > >> >> >>> On Mar 14, 2016, at 12:10 PM, Mark Stapp wrote: >>> >>> interesting - >>> >>> On 3/14/16 11:27 AM, Burke, Jeff wrote: >>>> >>> [...] >>> RFC 6973 takes a nice approach, for example, by offering >>>>> definitions of some technical properties and mechanisms, but not trying >>>>> to formulate an overall definition of "privacy". >>>> >>>> So I can try to understand your point here - do you agree with the >>> authors that the primary privacy concerns are those of individuals? (Or, >>> more generally, are corporations people here for this discussion - a >>> more generic "data owner"?) >>>> >>> >>> hmm - well, I don't think corporations are people, in the citizens united sense, but I think there's lots of commercial communication that needs to have the best possible protection, whether it's B2C or B2B? >>> >>>>> The editors there say >>>>> that the body of the document, the discussion of the tradeoffs and >>>>> alternatives, is the best way they could come up with to approach that >>>>> abstraction. in practical terms, as you know well I think there's been >>>>> an over-reliance on opportunistic caching in ICN generally, and as a >>>>> result observability and correlation are defined to be positive >>>>> properties of ICN communication rather than harmful ones. >>>> >>>> >>>> Would I be correct to parse your concerns into two pieces that may >>> have different implications: >>>> >>>> - Confidentiality of request (e.g., the consumer side) >>>> - Confidentiality of publication (e.g., the publisher side) >>>> >>> >>> I think I have a mental image of "confidential request" - where an observer cannot see much beyond the routeable prefix needed to reach an instance of the service I want to communicate with. I'm not sure what "confidential publication" means, though? I think I want the replies to my requests to be encrypted with ephemeral, forward-secure key material, I don't want the names in the replies to expose any more than the names in the requests, and I want to be able to authenticate the service before I expose anything about my own identity or intentions. is that what you meant by "the publisher side"? >>> >>> [...] >>> >>>>> >>>>> most of these six "principles" sounded like "mechanisms" to me - the >>>>> list felt like the end of a discussion about alternatives and the best >>>>> ways to implement an architecture, rather than the start of one. it >>>>> sounded like "we're tired of questions about LPM in the PIT, so we're >>>>> going to stop calling that a possible mechanism and start calling it an >>>>> inevitable, immutable, unquestionable 'principle'". >>>> >>>> Well, to take LPM for an example - it's actually not mentioned in >>>> the >>> principle doc that Alex sent. The principle I suspect that you are >>> referring to is: >>>> >>>> [5] In-Network Name Discovery: Interests should be able use >>>> incomplete >>> names to retrieve data packets. >>>> A consumer may not know the complete network-level name for data, as >>> some parts of the name cannot be guessed, computed, or inferred >>> beforehand. Once initial data is received, naming conventions can help >>> determine complete names of other related data: >>>> >>>> >>>> * majority of interests will carry complete names >>>> >>>> * in-network name discovery expected to be used to bootstrap >>> communication) >>>> >>>> >>>> >>>> Can you explain your objection in these terms? >>>> >>> >>> sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. >>> >>> Thanks, >>> Mark >>> _______________________________________________ >>> 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 Mon Mar 14 22:22:43 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Tue, 15 Mar 2016 05:22:43 +0000 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <75438CDD-729A-412E-884B-BDE018E9AE32@gmail.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> <1870C141-6751-4065-9377-8FE8E104C477@gmail.com> <75438CDD-729A-412E-884B-BDE018E9AE32@gmail.com> Message-ID: <95BF6005-B4EF-4807-AE9D-7C000DC1EBE0@parc.com> On Mar 14, 2016, at 9:53 PM, Tai-Lin Chu > wrote: Immutable = one data packet cannot be changed after publication. No, it is not ?a single publisher will never use the same name for different contents? (I believe this is "uniquely named") nor ?there is some cryptographic function possible on a packet such that one can detect if it changes?. Immutability is advisory here. If I start to violate immutablity in a distributed system where everything is assumed to be immutable, I am doomed to get incorrect result (I guess this sounds mandatory). I think immutability is a good choice overall, and it is better to state it as a principle so that nobody will use ndn the wrong way. Well, as you seemed to notice, if your system relies on an advisory feature for correctness, that?s a tenuous position. That?s probably not a correct statement for NDN, as an end node should be able to detect (hopefully) if a Data object is what it expected via signature or something and try again with an exclusion. however, you might not have liveness. So, my point here, is we talk about immutable objects but in truth we do not have them unless we use a hash-based name. We can define that a correctly operating publisher will never re-use a name and it cryptographically binds every Data object, but that is not immutable objects. That?s a protocol that generates unique objects. Unique is not immutable. A publisher could have a failure that causes its sequence number to reset or a memory error that causes the version number to flip a bit, etc. One can build a discovery protocol over exact name matching. Is the table of contents immutable? I think your approach is fine and efficient but it is rather hard to manage in a large distributed system if the table is not immutable. If the client sends a nonced name the publisher can return a link (in the ccnx sense, not the routing hints) plus uniquely named data of the table of contents appended for efficiency (to avoid a second round trip). I would think that doing cursors over table of contents rows is much more efficient in a large distributed system than returning potentially large data objects and doing search. If I have 100M versions of a name and I want to scan the data for some attribute, I think its much easier to fetch a partial tables of contents and pick the exact ones I want to retrieve than to iterate over the set using some name heuristic. This method also allows one to do discovery based on other criteria (attributes), such as signer keyids or other TLV fields, rather than just name elements. I could, for example, do a */superman.mov/* search for all names with superman.mov as a name component (if that type of query was allowed by the protocol). Or I could ask for only data objects that were manifests. Because this matching is done via an explicit discovery protocol, not as part of the forwarder, I have a lot of flexibility in the attributes I can query and the access control I can enforce. It is a design choice. NDN (from CCNx 0.x) chose to use mandatory in-network discovery base solely on name components, exclusions, and tree traversal. That?s ok, and one could claim that is sufficient. CCNx 1.0 chose to use explicit discovery protocols. My main point in asking about this is to point out that in-network mandatory discovery at the forwarder level is not a necessary condition. On Mar 14, 2016, at 9:01 PM, > > wrote: On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu > wrote: sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. Immutability is related to in-network discovery with LPM. If all packets are immutable, and there is no in-network discovery, ndn must rely on some other protocol that cannot not build on top of ndn for discovery (we should all agree that randomly guessing a version number or a certain name is not going to work well as ?discovery?). This devalues ndn as an ?universal" protocol. Could you please define immutable? Do you mean that a single publisher will never use the same name for different contents? Is that mandatory or enforceable? Or do you mean that there is some cryptographic function possible on a packet such that one can detect if it changes? Are those cryptographic primitives mandatory in each packet? I disagree that it is a necessary condition that one have name suffix completion matching of a data object to an interest to facilitate discovery. One can build a discovery protocol over exact name matching. I usually build these where the cache returns a chunked table of contents listing possible matches instead of the CCNx 0.x / NDN approach of having to return a (potentially very large) data object and walk a tree which is really only efficient if you expect what you want to be left-most or right-most child and not require iteration. On Mar 14, 2016, at 12:10 PM, Mark Stapp > wrote: interesting - On 3/14/16 11:27 AM, Burke, Jeff wrote: [...] RFC 6973 takes a nice approach, for example, by offering definitions of some technical properties and mechanisms, but not trying to formulate an overall definition of "privacy". So I can try to understand your point here - do you agree with the authors that the primary privacy concerns are those of individuals? (Or, more generally, are corporations people here for this discussion - a more generic "data owner"?) hmm - well, I don't think corporations are people, in the citizens united sense, but I think there's lots of commercial communication that needs to have the best possible protection, whether it's B2C or B2B? The editors there say that the body of the document, the discussion of the tradeoffs and alternatives, is the best way they could come up with to approach that abstraction. in practical terms, as you know well I think there's been an over-reliance on opportunistic caching in ICN generally, and as a result observability and correlation are defined to be positive properties of ICN communication rather than harmful ones. Would I be correct to parse your concerns into two pieces that may have different implications: - Confidentiality of request (e.g., the consumer side) - Confidentiality of publication (e.g., the publisher side) I think I have a mental image of "confidential request" - where an observer cannot see much beyond the routeable prefix needed to reach an instance of the service I want to communicate with. I'm not sure what "confidential publication" means, though? I think I want the replies to my requests to be encrypted with ephemeral, forward-secure key material, I don't want the names in the replies to expose any more than the names in the requests, and I want to be able to authenticate the service before I expose anything about my own identity or intentions. is that what you meant by "the publisher side"? [...] most of these six "principles" sounded like "mechanisms" to me - the list felt like the end of a discussion about alternatives and the best ways to implement an architecture, rather than the start of one. it sounded like "we're tired of questions about LPM in the PIT, so we're going to stop calling that a possible mechanism and start calling it an inevitable, immutable, unquestionable 'principle'". Well, to take LPM for an example - it's actually not mentioned in the principle doc that Alex sent. The principle I suspect that you are referring to is: [5] In-Network Name Discovery: Interests should be able use incomplete names to retrieve data packets. A consumer may not know the complete network-level name for data, as some parts of the name cannot be guessed, computed, or inferred beforehand. Once initial data is received, naming conventions can help determine complete names of other related data: * majority of interests will carry complete names * in-network name discovery expected to be used to bootstrap communication) Can you explain your objection in these terms? sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. Thanks, Mark _______________________________________________ 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 mesarpe at gmail.com Mon Mar 14 23:36:09 2016 From: mesarpe at gmail.com (=?UTF-8?Q?C=C3=A9sar_A=2E_Bernardini?=) Date: Tue, 15 Mar 2016 07:36:09 +0100 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <95BF6005-B4EF-4807-AE9D-7C000DC1EBE0@parc.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> <1870C141-6751-4065-9377-8FE8E104C477@gmail.com> <75438CDD-729A-412E-884B-BDE018E9AE32@gmail.com> <95BF6005-B4EF-4807-AE9D-7C000DC1EBE0@parc.com> Message-ID: Dear all, In ICC 2016[0], we are going to present a mechanism that protects the privacy of the user while the content router can still cache and lookup. The proposed mechanism is based on proxy encryption. With PROTECTOR, every user has a different key and every router holds collection of keys, but nobody has the master key of the system. [0] PROTECTOR: Privacy-Preserving Information Lookup in Content-Centric Networks - Ashgar, Bernardini, Crispo https://www.cs.auckland.ac.nz/~asghar/papers/Asghar-ICC16-PROTECTOR.pdf 2016-03-15 6:22 GMT+01:00 : > > On Mar 14, 2016, at 9:53 PM, Tai-Lin Chu wrote: > > Immutable = one data packet cannot be changed after publication. > > No, it is not ?a single publisher will never use the same name for different > contents? (I believe this is "uniquely named") nor ?there is some > cryptographic function possible on a packet such that one can detect if it > changes?. > > Immutability is advisory here. If I start to violate immutablity in a > distributed system where everything is assumed to be immutable, I am doomed > to get incorrect result (I guess this sounds mandatory). I think > immutability is a good choice overall, and it is better to state it as a > principle so that nobody will use ndn the wrong way. > > > Well, as you seemed to notice, if your system relies on an advisory feature > for correctness, that?s a tenuous position. That?s probably not a correct > statement for NDN, as an end node should be able to detect (hopefully) if a > Data object is what it expected via signature or something and try again > with an exclusion. however, you might not have liveness. > > So, my point here, is we talk about immutable objects but in truth we do not > have them unless we use a hash-based name. We can define that a correctly > operating publisher will never re-use a name and it cryptographically binds > every Data object, but that is not immutable objects. That?s a protocol > that generates unique objects. Unique is not immutable. A publisher could > have a failure that causes its sequence number to reset or a memory error > that causes the version number to flip a bit, etc. > > > > One can build a discovery protocol over exact name matching. > > > Is the table of contents immutable? I think your approach is fine and > efficient but it is rather hard to manage in a large distributed system if > the table is not immutable. > > > If the client sends a nonced name the publisher can return a link (in the > ccnx sense, not the routing hints) plus uniquely named data of the table of > contents appended for efficiency (to avoid a second round trip). > > I would think that doing cursors over table of contents rows is much more > efficient in a large distributed system than returning potentially large > data objects and doing search. If I have 100M versions of a name and I want > to scan the data for some attribute, I think its much easier to fetch a > partial tables of contents and pick the exact ones I want to retrieve than > to iterate over the set using some name heuristic. > > This method also allows one to do discovery based on other criteria > (attributes), such as signer keyids or other TLV fields, rather than just > name elements. I could, for example, do a */superman.mov/* search for all > names with superman.mov as a name component (if that type of query was > allowed by the protocol). Or I could ask for only data objects that were > manifests. > > Because this matching is done via an explicit discovery protocol, not as > part of the forwarder, I have a lot of flexibility in the attributes I can > query and the access control I can enforce. > > It is a design choice. NDN (from CCNx 0.x) chose to use mandatory > in-network discovery base solely on name components, exclusions, and tree > traversal. That?s ok, and one could claim that is sufficient. CCNx 1.0 > chose to use explicit discovery protocols. My main point in asking about > this is to point out that in-network mandatory discovery at the forwarder > level is not a necessary condition. > > > > > > > On Mar 14, 2016, at 9:01 PM, > wrote: > > > On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu wrote: > > sure - I don't want to expose names that identify me, or expose my > communication activities. given that, the "network" doesn't have the job of > finding things for me by partial names - I only want to expose the details > of my communication to a service that I have authenticated, and only when > those details are encrypted. the "names" visible to the network in that sort > of world just get the packets moving - and the only LPM needed is LPM in the > FIB to get me to one or more instances of a service. > > > Immutability is related to in-network discovery with LPM. If all packets > are immutable, and there is no in-network discovery, ndn must rely on some > other protocol that cannot not build on top of ndn for discovery (we should > all agree that randomly guessing a version number or a certain name is not > going to work well as ?discovery?). This devalues ndn as an ?universal" > protocol. > > > Could you please define immutable? Do you mean that a single publisher will > never use the same name for different contents? Is that mandatory or > enforceable? Or do you mean that there is some cryptographic function > possible on a packet such that one can detect if it changes? Are those > cryptographic primitives mandatory in each packet? > > I disagree that it is a necessary condition that one have name suffix > completion matching of a data object to an interest to facilitate discovery. > One can build a discovery protocol over exact name matching. I usually > build these where the cache returns a chunked table of contents listing > possible matches instead of the CCNx 0.x / NDN approach of having to return > a (potentially very large) data object and walk a tree which is really only > efficient if you expect what you want to be left-most or right-most child > and not require iteration. > > > > > On Mar 14, 2016, at 12:10 PM, Mark Stapp wrote: > > interesting - > > On 3/14/16 11:27 AM, Burke, Jeff wrote: > > > [...] > RFC 6973 takes a nice approach, for example, by offering > > definitions of some technical properties and mechanisms, but not trying > to formulate an overall definition of "privacy". > > > So I can try to understand your point here - do you agree with the > > authors that the primary privacy concerns are those of individuals? (Or, > more generally, are corporations people here for this discussion - a > more generic "data owner"?) > > > > hmm - well, I don't think corporations are people, in the citizens united > sense, but I think there's lots of commercial communication that needs to > have the best possible protection, whether it's B2C or B2B? > > The editors there say > that the body of the document, the discussion of the tradeoffs and > alternatives, is the best way they could come up with to approach that > abstraction. in practical terms, as you know well I think there's been > an over-reliance on opportunistic caching in ICN generally, and as a > result observability and correlation are defined to be positive > properties of ICN communication rather than harmful ones. > > > > Would I be correct to parse your concerns into two pieces that may > > have different implications: > > > - Confidentiality of request (e.g., the consumer side) > - Confidentiality of publication (e.g., the publisher side) > > > I think I have a mental image of "confidential request" - where an observer > cannot see much beyond the routeable prefix needed to reach an instance of > the service I want to communicate with. I'm not sure what "confidential > publication" means, though? I think I want the replies to my requests to be > encrypted with ephemeral, forward-secure key material, I don't want the > names in the replies to expose any more than the names in the requests, and > I want to be able to authenticate the service before I expose anything about > my own identity or intentions. is that what you meant by "the publisher > side"? > > [...] > > > most of these six "principles" sounded like "mechanisms" to me - the > list felt like the end of a discussion about alternatives and the best > ways to implement an architecture, rather than the start of one. it > sounded like "we're tired of questions about LPM in the PIT, so we're > going to stop calling that a possible mechanism and start calling it an > inevitable, immutable, unquestionable 'principle'". > > > Well, to take LPM for an example - it's actually not mentioned in > the > > principle doc that Alex sent. The principle I suspect that you are > referring to is: > > > [5] In-Network Name Discovery: Interests should be able use > incomplete > > names to retrieve data packets. > > A consumer may not know the complete network-level name for data, as > > some parts of the name cannot be guessed, computed, or inferred > beforehand. Once initial data is received, naming conventions can help > determine complete names of other related data: > > > > * majority of interests will carry complete names > > * in-network name discovery expected to be used to bootstrap > > communication) > > > > > Can you explain your objection in these terms? > > > sure - I don't want to expose names that identify me, or expose my > communication activities. given that, the "network" doesn't have the job of > finding things for me by partial names - I only want to expose the details > of my communication to a service that I have authenticated, and only when > those details are encrypted. the "names" visible to the network in that sort > of world just get the packets moving - and the only LPM needed is LPM in the > FIB to get me to one or more instances of a service. > > Thanks, > Mark > _______________________________________________ > 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 tailinchu at gmail.com Tue Mar 15 00:41:59 2016 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Tue, 15 Mar 2016 00:41:59 -0700 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <95BF6005-B4EF-4807-AE9D-7C000DC1EBE0@parc.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> <1870C141-6751-4065-9377-8FE8E104C477@gmail.com> <75438CDD-729A-412E-884B-BDE018E9AE32@gmail.com> <95BF6005-B4EF-4807-AE9D-7C000DC1EBE0@parc.com> Message-ID: <357E2AA0-8465-4C91-AAD8-A6BF45FC8837@gmail.com> > So, my point here, is we talk about immutable objects but in truth we do not have them unless we use a hash-based name. There is ndn ?implicit digest?, so if you take that into account, it will not be advisory. > If the client sends a nonced name the publisher can return a link (in the ccnx sense, not the routing hints) plus uniquely named data of the table of contents appended for efficiency (to avoid a second round trip). I might not understand this protocol well, but it seems that the discovery protocol tries to maintain immutability (given that you don?t change the data packet later, and the nonced name is unique enough.) > NDN (from CCNx 0.x) chose to use mandatory in-network discovery base solely on name components, exclusions, and tree traversal. That?s ok, and one could claim that is sufficient. CCNx 1.0 chose to use explicit discovery protocols. My main point in asking about this is to point out that in-network mandatory discovery at the forwarder level is not a necessary condition. Please don?t misunderstand my previous comments; I am a supporter for immutability not in-network discovery. > On Mar 14, 2016, at 10:22 PM, wrote: > > >> On Mar 14, 2016, at 9:53 PM, Tai-Lin Chu > wrote: >> >> Immutable = one data packet cannot be changed after publication. >> >> No, it is not ?a single publisher will never use the same name for different contents? (I believe this is "uniquely named") nor ?there is some cryptographic function possible on a packet such that one can detect if it changes?. >> >> Immutability is advisory here. If I start to violate immutablity in a distributed system where everything is assumed to be immutable, I am doomed to get incorrect result (I guess this sounds mandatory). I think immutability is a good choice overall, and it is better to state it as a principle so that nobody will use ndn the wrong way. > > Well, as you seemed to notice, if your system relies on an advisory feature for correctness, that?s a tenuous position. That?s probably not a correct statement for NDN, as an end node should be able to detect (hopefully) if a Data object is what it expected via signature or something and try again with an exclusion. however, you might not have liveness. > > So, my point here, is we talk about immutable objects but in truth we do not have them unless we use a hash-based name. We can define that a correctly operating publisher will never re-use a name and it cryptographically binds every Data object, but that is not immutable objects. That?s a protocol that generates unique objects. Unique is not immutable. A publisher could have a failure that causes its sequence number to reset or a memory error that causes the version number to flip a bit, etc. > >> >> >>> One can build a discovery protocol over exact name matching. >> >> Is the table of contents immutable? I think your approach is fine and efficient but it is rather hard to manage in a large distributed system if the table is not immutable. > > If the client sends a nonced name the publisher can return a link (in the ccnx sense, not the routing hints) plus uniquely named data of the table of contents appended for efficiency (to avoid a second round trip). > > I would think that doing cursors over table of contents rows is much more efficient in a large distributed system than returning potentially large data objects and doing search. If I have 100M versions of a name and I want to scan the data for some attribute, I think its much easier to fetch a partial tables of contents and pick the exact ones I want to retrieve than to iterate over the set using some name heuristic. > > This method also allows one to do discovery based on other criteria (attributes), such as signer keyids or other TLV fields, rather than just name elements. I could, for example, do a */superman.mov/* search for all names with superman.mov as a name component (if that type of query was allowed by the protocol). Or I could ask for only data objects that were manifests. > > Because this matching is done via an explicit discovery protocol, not as part of the forwarder, I have a lot of flexibility in the attributes I can query and the access control I can enforce. > > It is a design choice. NDN (from CCNx 0.x) chose to use mandatory in-network discovery base solely on name components, exclusions, and tree traversal. That?s ok, and one could claim that is sufficient. CCNx 1.0 chose to use explicit discovery protocols. My main point in asking about this is to point out that in-network mandatory discovery at the forwarder level is not a necessary condition. > >> >> >> >> >> >>> On Mar 14, 2016, at 9:01 PM, > > wrote: >>> >>>> >>>> On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu > wrote: >>>> >>>>> sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. >>>> >>>> Immutability is related to in-network discovery with LPM. If all packets are immutable, and there is no in-network discovery, ndn must rely on some other protocol that cannot not build on top of ndn for discovery (we should all agree that randomly guessing a version number or a certain name is not going to work well as ?discovery?). This devalues ndn as an ?universal" protocol. >>> >>> Could you please define immutable? Do you mean that a single publisher will never use the same name for different contents? Is that mandatory or enforceable? Or do you mean that there is some cryptographic function possible on a packet such that one can detect if it changes? Are those cryptographic primitives mandatory in each packet? >>> >>> I disagree that it is a necessary condition that one have name suffix completion matching of a data object to an interest to facilitate discovery. One can build a discovery protocol over exact name matching. I usually build these where the cache returns a chunked table of contents listing possible matches instead of the CCNx 0.x / NDN approach of having to return a (potentially very large) data object and walk a tree which is really only efficient if you expect what you want to be left-most or right-most child and not require iteration. >>> >>> >>>> >>>> >>>>> On Mar 14, 2016, at 12:10 PM, Mark Stapp > wrote: >>>>> >>>>> interesting - >>>>> >>>>> On 3/14/16 11:27 AM, Burke, Jeff wrote: >>>>>> >>>>> [...] >>>>> RFC 6973 takes a nice approach, for example, by offering >>>>>>> definitions of some technical properties and mechanisms, but not trying >>>>>>> to formulate an overall definition of "privacy". >>>>>> >>>>>> So I can try to understand your point here - do you agree with the >>>>> authors that the primary privacy concerns are those of individuals? (Or, >>>>> more generally, are corporations people here for this discussion - a >>>>> more generic "data owner"?) >>>>>> >>>>> >>>>> hmm - well, I don't think corporations are people, in the citizens united sense, but I think there's lots of commercial communication that needs to have the best possible protection, whether it's B2C or B2B? >>>>> >>>>>>> The editors there say >>>>>>> that the body of the document, the discussion of the tradeoffs and >>>>>>> alternatives, is the best way they could come up with to approach that >>>>>>> abstraction. in practical terms, as you know well I think there's been >>>>>>> an over-reliance on opportunistic caching in ICN generally, and as a >>>>>>> result observability and correlation are defined to be positive >>>>>>> properties of ICN communication rather than harmful ones. >>>>>> >>>>>> >>>>>> Would I be correct to parse your concerns into two pieces that may >>>>> have different implications: >>>>>> >>>>>> - Confidentiality of request (e.g., the consumer side) >>>>>> - Confidentiality of publication (e.g., the publisher side) >>>>>> >>>>> >>>>> I think I have a mental image of "confidential request" - where an observer cannot see much beyond the routeable prefix needed to reach an instance of the service I want to communicate with. I'm not sure what "confidential publication" means, though? I think I want the replies to my requests to be encrypted with ephemeral, forward-secure key material, I don't want the names in the replies to expose any more than the names in the requests, and I want to be able to authenticate the service before I expose anything about my own identity or intentions. is that what you meant by "the publisher side"? >>>>> >>>>> [...] >>>>> >>>>>>> >>>>>>> most of these six "principles" sounded like "mechanisms" to me - the >>>>>>> list felt like the end of a discussion about alternatives and the best >>>>>>> ways to implement an architecture, rather than the start of one. it >>>>>>> sounded like "we're tired of questions about LPM in the PIT, so we're >>>>>>> going to stop calling that a possible mechanism and start calling it an >>>>>>> inevitable, immutable, unquestionable 'principle'". >>>>>> >>>>>> Well, to take LPM for an example - it's actually not mentioned in >>>>>> the >>>>> principle doc that Alex sent. The principle I suspect that you are >>>>> referring to is: >>>>>> >>>>>> [5] In-Network Name Discovery: Interests should be able use >>>>>> incomplete >>>>> names to retrieve data packets. >>>>>> A consumer may not know the complete network-level name for data, as >>>>> some parts of the name cannot be guessed, computed, or inferred >>>>> beforehand. Once initial data is received, naming conventions can help >>>>> determine complete names of other related data: >>>>>> >>>>>> >>>>>> * majority of interests will carry complete names >>>>>> >>>>>> * in-network name discovery expected to be used to bootstrap >>>>> communication) >>>>>> >>>>>> >>>>>> >>>>>> Can you explain your objection in these terms? >>>>>> >>>>> >>>>> sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. >>>>> >>>>> Thanks, >>>>> Mark >>>>> _______________________________________________ >>>>> 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 mjs at cisco.com Tue Mar 15 06:13:03 2016 From: mjs at cisco.com (Mark Stapp) Date: Tue, 15 Mar 2016 09:13:03 -0400 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> <56E71B9C.1070506@cisco.com> Message-ID: <56E80A5F.9050801@cisco.com> hmm - it seems like you and Tai-Lin are sort of conflating some things that are not necessarily entangled. I think it would be good to make private communication the default - not the _only_ choice. I don't see how changing the default to 'private' does anything to compromise the network as a whole. there may well be types of communication that _must_ be in the clear - you seem to be asserting that there would be some significant impairment to some kind of communication if it were to be forward-securely encrypted as I've described in other emails. maybe someone could offer some examples of the impairment that would occur? when I think about the things I do on the net on a day-to-day basis - the applications I use, the hosts I log in to, the websites I visit, etc. - I can't personally come up with an example of an application that works _worse_ since it switched from in-the-clear to TLS. Thanks, Mark On 3/14/16 4:45 PM, Luca Muscariello wrote: > To my understanding, principles are rules that are mutually exclusive > and from which other rules can be derived. > > They are not axioms though. You can disagree. > > In the case of privacy, even if you run the network in such default > mode, this cannot be a principle as I cannot derive non private > communications from private communications unless I negate the > principle. So It's not a principle. > > Requiring security on data seems like a principle though as you can > build on this to create private and non private communications. > > On Monday, 14 March 2016, Mark Stapp > wrote: > > ok, but - my suggestion is that the _default_ should be private, not > that there should not be a way for an application to _ask_ for > non-private. > > I'm hoping that the ongoing discussion will bring out some examples > of communication that folks think _belongs_ in-the-clear - where > some property of the application involved will be compromised if the > communication is strongly protected and confidential. I think that > it's going to be difficult to make much of a case there, given the > capabilities that well-designed applications offer in the current > internet, but it'd be interesting to hear the examples. > > and ... I have to say that I don't understand the "principle of > universality", so ... I think that might be its own thread? > > -- Mark > > On 3/14/16 3:59 PM, Luca Muscariello wrote: > > Imposing that all communications must be private is in contradiction > with the principle of universality as long as the network is > supposed to > carry any kind of application. > > So I disagree that privacy is a principle. > Not all communications are private. > > Luca > > From mjs at cisco.com Tue Mar 15 06:25:59 2016 From: mjs at cisco.com (Mark Stapp) Date: Tue, 15 Mar 2016 09:25:59 -0400 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <1870C141-6751-4065-9377-8FE8E104C477@gmail.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> <1870C141-6751-4065-9377-8FE8E104C477@gmail.com> Message-ID: <56E80D67.9090400@cisco.com> On 3/14/16 11:44 PM, Tai-Lin Chu wrote: I wrote: >> sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. then you wrote: > > Immutability is related to in-network discovery with LPM. If all packets are immutable, and there is no in-network discovery, ndn must rely on some other protocol that cannot not build on top of ndn for discovery (we should all agree that randomly guessing a version number or a certain name is not going to work well as ?discovery?). This devalues ndn as an ?universal" protocol. > > so ... I absolutely agree that it's not a very useful approach to have to randomly guess 'names' in order to use the network. I agree that that should be ... strongly questioned, if it is offered as a solution to rendezvous. but I think you're misunderstanding what forward-secure communication would (probably) look like. there would not be any in-the-clear exposure of the nature of my activities. I would engage with an instance of the application I wanted to use, anonymously. that application would authenticate to me, so that I would not offer my identity to an adversary. I would possibly authenticate to the application, to gain access to my personal context, and to allow the application to apply access controls to me. the application and I would generate some key material, which would then be used to derive symmetric keys. from the perspective of the network, nothing about my use of the application would be visible - all of the details would be conveyed inside an encrypted envelope. the network would only see the routeable name on the 'outside' of the envelope, and that name would not refer to any 'object' - it would just offer enough routeable prefix to reach an instance of the application, and enough context identification to allow the application to locate the keys to use when communicating with me. how the application works, its semantics, would not have to be known to the network in any way. Thanks, Mark From borje.ohlman at ericsson.com Tue Mar 15 07:04:50 2016 From: borje.ohlman at ericsson.com (=?utf-8?B?QsO2cmplIE9obG1hbg==?=) Date: Tue, 15 Mar 2016 14:04:50 +0000 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <95BF6005-B4EF-4807-AE9D-7C000DC1EBE0@parc.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> <1870C141-6751-4065-9377-8FE8E104C477@gmail.com> <75438CDD-729A-412E-884B-BDE018E9AE32@gmail.com> <95BF6005-B4EF-4807-AE9D-7C000DC1EBE0@parc.com> Message-ID: On 15 mars 2016, at 06:22, Marc.Mosko at parc.com wrote: So, my point here, is we talk about immutable objects but in truth we do not have them unless we use a hash-based name. So let?s simply use hash based names for immutable objects. Why make things difficult? BTW, I liked the article about immutability that Alex pointed at. B?rje -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.UCLA.edu Tue Mar 15 09:09:28 2016 From: jburke at remap.UCLA.edu (Burke, Jeff) Date: Tue, 15 Mar 2016 16:09:28 +0000 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: <643A20B7-8AE5-4CDD-991F-B943AB22114D@parc.com> References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> <643A20B7-8AE5-4CDD-991F-B943AB22114D@parc.com> Message-ID: <1C73CB59-1E9A-498F-8A4C-9ED7BFE21EAA@remap.ucla.edu> Nacho, >On 3/11/16, 4:19 PM, "Tai-Lin Chu" wrote: > > >>> Is performance/efficiency not a principle at all? >> >>Do you mind explaining what performance specifically (packet encoding/decoding, forwarding, or something else)? > >Sure: being better than current networks at something; anything. > >I don?t think the principles reflect this well. > >That could be faster packet encoding, faster forwarding, more resilient routing, less failures, lower latency, higher privacy, higher security, better redundancy, lower hardware cost, lower overhead (less systems required? maybe like dns or something), etc. Whether or not this sort of thing is a principle, I'm not sure. (It's possible to have a goal that is not a design principle, I think.) But I'd also suggest that *if* performance is considered as a principle or goal, it should be in parallel with considerations that reflect total cost of application development and deployment, like expressiveness, closeness of mapping between the network and applications, etc. As I've suggested elsewhere one starting point is Green, Thomas R. G., and Marian Petre. "Usability analysis of visual programming environments: a ?cognitive dimensions? framework." Journal of Visual Languages & Computing 7.2 (1996): 131-174. Or, put perhaps more broadly, the way the architecture frames the world / motivates application design is important, too. "A chief service of a designer is helping clients discover what they want designed." - FP Brooks, The Design of Design. > >In my opinion, there has to be some justification as to why something is a principle. Why is this principle good or required if it is not natively a good one. Agreed. (Fortunately I am not organizing the articulation of principles so it is easy to agree. :) > >For example, Universality. Why is this good? Is it good because it doesn?t discriminate? Or is it good because it reduce complexity? (which in turn could be good because it reduces bugs, etc). If so, make that the goal. Make that the principle: ?to make a simpler system? or whatever. Not sure about this. There does need to be justification but simply to swap out design principles for their motivation is probably to end up in something that is too general to be used for design itself. If they are abstracted to far (Eventually this reduces to "The world should be better because this thing exists.") it will be really hard to make decisions based on them. Seems like a balance to strike through iterative discussion like this. Jeff > >Nacho > > > >>> On Mar 11, 2016, at 12:48 AM, Ignacio.Solis at parc.com wrote: >>> >>> >>>> [1] **Universality**: >>>> NDN should be a common network protocol for all applications and network environments. >>> >>> I?m assuming here that you imply a set of protocols. After all, the way you do flow control varies a lot from DTN to non-DTN environments. Or are you limiting this to the basic packet format? >>> >>> On the web page it calls out for DTN, IoT, Mesh networks, Web, etc. It seems obvious to me that these require various protocols; potentially layered or interoperating in some fashion. >>> >>> If one interprets this principle as ?the base protocol will allow??, then the question becomes how does the base protocol allow this. >>> >>> The document states that the protocol should be flexible and extensible. It then states that there should be no fixed parts or fixed length fields in the header. I?m unsure what the full rationale is here. Is it that we will exceed the length of the fields? Or that suddenly one field will become obsolete and we will want to remove it? Is it because we don?t want to make assumptions about packets coming in? We want them to be so flexible that anything is possible? >>> >>> In one way or another, we?re making assumptions about the packet coming in. If it?s not the static header, it?s the fact that the way we parse the packet has to be consistent. (As in, the first bit determines if the next byte is a continuation of the first byte, etc). So, to some degree, you are fixing some formatting. >>> >>> In one assumption, (fixed header), we are limiting the format and semantics of the first n bytes (8 or 16 or whatever). In the other space, you?re limiting the format (but maybe not the semantics of the first n bytes). You trade off some processing for some byte inefficiency. >>> >>> The fact that we want the same protocol to work on IoT, datacenter and interplanetary networks effectively says: >>> - The benefits we get from optimizing for each of these scenarios are less important than the advantage we get by having a single protocol format that runs in all. >>> >>> It seems to me that having a single protocol is useful when traffic goes from one to the other. If we don?t expect traffic to go from one to the other the benefit diminishes. Here I?m assuming native network compatible traffic. So that one packet, comes from IoT and unmodified goes to the datacenter and unmodified goes to Mars. As opposed to having gateways that can speak multiple protocols or tunneling and overlays. >>> >>> To calibrate, I?m in the camp of thinking that PIM-SM and PIM-DM are different protocols. So I would also side with the fact that if you had a situation where packets on one end of the gateway use NDN but are not understood at the other side of the gateway then the packets are effectively from 2 different protocols. >>> >>> I would also argue that if the purpose of building an extremely flexible format is to save bytes in one scenario where those are not needed at the expense of processing, then I would say that you might as well go all the way and just implement some type of link-layer compression scheme and really save some bytes. Dictionaries can go a long way. >>> >>> >>> Finally, going back to what?s on the page. When you say that there should be no fixed parts and no fixed length fields, do you really mean it? >>> - Can I have a packet with no packet_size field? >>> - Can I have a packet with no protocol version field? >>> - Can I have a packet with no name? >>> >>> - Can I have a packet with an arbitrary length name? >>> - Can I have a packet with an arbitrary size payload? >>> - Can I have a packet with 3 payloads? >>> - Can I have a packet with 2 names? >>> - Can I have a packet with no signature? >>> - Must all nodes support all of these packet types? >>> - Can I have an arbitrary sized T in a TLV? (I?m assuming you?re proposing TLVs, but maybe you?re planning on using XML or json for flexibility.) >>> - Can I have an arbitrary sized L? >>> >>> To preempt the discussion, what part of this is architecture and what part is policy? >>> >>> >>> Nacho >>> >>> >>> >>> -- >>> Nacho (Ignacio) Solis >>> Protocol Architect >>> Principal Scientist >>> Palo Alto Research Center (PARC) >>> +1(650)812-4458 >>> Ignacio.Solis at parc.com >>> >>> _______________________________________________ >>> 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 jburke at remap.UCLA.edu Tue Mar 15 09:09:37 2016 From: jburke at remap.UCLA.edu (Burke, Jeff) Date: Tue, 15 Mar 2016 16:09:37 +0000 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <95BF6005-B4EF-4807-AE9D-7C000DC1EBE0@parc.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> <1870C141-6751-4065-9377-8FE8E104C477@gmail.com> <75438CDD-729A-412E-884B-BDE018E9AE32@gmail.com> <95BF6005-B4EF-4807-AE9D-7C000DC1EBE0@parc.com> Message-ID: <7E8625A7-41ED-4321-B7D6-9EE394DA0275@remap.ucla.edu> From: Ndn-interest > on behalf of "Marc.Mosko at parc.com" > Date: Monday, March 14, 2016 at 10:22 PM To: "tailinchu at gmail.com" > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] NDN protocol principles: no privacy? Quick clarifications below... On Mar 14, 2016, at 9:53 PM, Tai-Lin Chu > wrote: Immutable = one data packet cannot be changed after publication. No, it is not ?a single publisher will never use the same name for different contents? (I believe this is "uniquely named") nor ?there is some cryptographic function possible on a packet such that one can detect if it changes?. Immutability is advisory here. If I start to violate immutablity in a distributed system where everything is assumed to be immutable, I am doomed to get incorrect result (I guess this sounds mandatory). I think immutability is a good choice overall, and it is better to state it as a principle so that nobody will use ndn the wrong way. Well, as you seemed to notice, if your system relies on an advisory feature for correctness, that?s a tenuous position. That?s probably not a correct statement for NDN, as an end node should be able to detect (hopefully) if a Data object is what it expected via signature or something and try again with an exclusion. however, you might not have liveness. So, my point here, is we talk about immutable objects but in truth we do not have them unless we use a hash-based name. We can define that a correctly operating publisher will never re-use a name and it cryptographically binds every Data object, but that is not immutable objects. That?s a protocol that generates unique objects. Unique is not immutable. A publisher could have a failure that causes its sequence number to reset or a memory error that causes the version number to flip a bit, etc. The full name of every (immutable) Data packet in NDN includes the implicit digest - http://named-data.net/doc/ndn-tlv/name.html#implicit-digest-component One can build a discovery protocol over exact name matching. Is the table of contents immutable? I think your approach is fine and efficient but it is rather hard to manage in a large distributed system if the table is not immutable. If the client sends a nonced name the publisher can return a link (in the ccnx sense, not the routing hints) plus uniquely named data of the table of contents appended for efficiency (to avoid a second round trip). I would think that doing cursors over table of contents rows is much more efficient in a large distributed system than returning potentially large data objects and doing search. If I have 100M versions of a name and I want to scan the data for some attribute, I think its much easier to fetch a partial tables of contents and pick the exact ones I want to retrieve than to iterate over the set using some name heuristic. I don't know that this approach necessarily follows from the NDN principles. Depending on the application, one could fetch a manifest (we are doing this in a mobile health app), use a selector once to then start sequential retrieval (NDNVideo's approach to "fetch keyframe nearest to time x"), use some type of sync protocol, etc. This method also allows one to do discovery based on other criteria (attributes), such as signer keyids or other TLV fields, rather than just name elements. I could, for example, do a */superman.mov/* search for all names with superman.mov as a name component (if that type of query was allowed by the protocol). Or I could ask for only data objects that were manifests. Because this matching is done via an explicit discovery protocol, not as part of the forwarder, I have a lot of flexibility in the attributes I can query and the access control I can enforce. It is a design choice. NDN (from CCNx 0.x) chose to use mandatory in-network discovery base solely on name components, exclusions, and tree traversal. That?s ok, and one could claim that is sufficient. CCNx 1.0 chose to use explicit discovery protocols. My main point in asking about this is to point out that in-network mandatory discovery at the forwarder level is not a necessary condition. NDN proposes some other discovery approaches (namely sync), too. These have some open challenges that Mark pointed out, but have the potential to support multi-publisher, multi-consumer scenarios. Regarding explicit discovery, I'll try to ask some related questions in response to Nacho's email. Jeff On Mar 14, 2016, at 9:01 PM, > > wrote: On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu > wrote: sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. Immutability is related to in-network discovery with LPM. If all packets are immutable, and there is no in-network discovery, ndn must rely on some other protocol that cannot not build on top of ndn for discovery (we should all agree that randomly guessing a version number or a certain name is not going to work well as ?discovery?). This devalues ndn as an ?universal" protocol. Could you please define immutable? Do you mean that a single publisher will never use the same name for different contents? Is that mandatory or enforceable? Or do you mean that there is some cryptographic function possible on a packet such that one can detect if it changes? Are those cryptographic primitives mandatory in each packet? I disagree that it is a necessary condition that one have name suffix completion matching of a data object to an interest to facilitate discovery. One can build a discovery protocol over exact name matching. I usually build these where the cache returns a chunked table of contents listing possible matches instead of the CCNx 0.x / NDN approach of having to return a (potentially very large) data object and walk a tree which is really only efficient if you expect what you want to be left-most or right-most child and not require iteration. On Mar 14, 2016, at 12:10 PM, Mark Stapp > wrote: interesting - On 3/14/16 11:27 AM, Burke, Jeff wrote: [...] RFC 6973 takes a nice approach, for example, by offering definitions of some technical properties and mechanisms, but not trying to formulate an overall definition of "privacy". So I can try to understand your point here - do you agree with the authors that the primary privacy concerns are those of individuals? (Or, more generally, are corporations people here for this discussion - a more generic "data owner"?) hmm - well, I don't think corporations are people, in the citizens united sense, but I think there's lots of commercial communication that needs to have the best possible protection, whether it's B2C or B2B? The editors there say that the body of the document, the discussion of the tradeoffs and alternatives, is the best way they could come up with to approach that abstraction. in practical terms, as you know well I think there's been an over-reliance on opportunistic caching in ICN generally, and as a result observability and correlation are defined to be positive properties of ICN communication rather than harmful ones. Would I be correct to parse your concerns into two pieces that may have different implications: - Confidentiality of request (e.g., the consumer side) - Confidentiality of publication (e.g., the publisher side) I think I have a mental image of "confidential request" - where an observer cannot see much beyond the routeable prefix needed to reach an instance of the service I want to communicate with. I'm not sure what "confidential publication" means, though? I think I want the replies to my requests to be encrypted with ephemeral, forward-secure key material, I don't want the names in the replies to expose any more than the names in the requests, and I want to be able to authenticate the service before I expose anything about my own identity or intentions. is that what you meant by "the publisher side"? [...] most of these six "principles" sounded like "mechanisms" to me - the list felt like the end of a discussion about alternatives and the best ways to implement an architecture, rather than the start of one. it sounded like "we're tired of questions about LPM in the PIT, so we're going to stop calling that a possible mechanism and start calling it an inevitable, immutable, unquestionable 'principle'". Well, to take LPM for an example - it's actually not mentioned in the principle doc that Alex sent. The principle I suspect that you are referring to is: [5] In-Network Name Discovery: Interests should be able use incomplete names to retrieve data packets. A consumer may not know the complete network-level name for data, as some parts of the name cannot be guessed, computed, or inferred beforehand. Once initial data is received, naming conventions can help determine complete names of other related data: * majority of interests will carry complete names * in-network name discovery expected to be used to bootstrap communication) Can you explain your objection in these terms? sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. Thanks, Mark _______________________________________________ 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 jburke at remap.UCLA.edu Tue Mar 15 09:10:52 2016 From: jburke at remap.UCLA.edu (Burke, Jeff) Date: Tue, 15 Mar 2016 16:10:52 +0000 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> <1EF575B5-C23B-4A3C-A162-1066FD389193@parc.com> <2EF25D4D-6F7E-4769-BB36-80902B7542B2@cs.ucla.edu> Message-ID: <42AABDFB-9EE6-4671-A73C-7DD96198286E@remap.ucla.edu> -----Original Message----- From: Ndn-interest on behalf of "Ignacio.Solis at parc.com" Date: Monday, March 14, 2016 at 11:33 AM To: "aa at CS.UCLA.EDU" Cc: "ndn-interest at lists.cs.ucla.edu" Subject: Re: [Ndn-interest] NDN Protocol Design Principles >On 3/13/16, 12:25 PM, "Alex Afanasyev" wrote: > > > >> >>> On Mar 11, 2016, at 12:26 AM, Ignacio.Solis at parc.com wrote: >>> >>> I think it?s great to have spelled out protocol principles. It definitely lets people discuss things in a way that distinguishes the principle from the embodiment. You can then evaluate the tradeoffs that you?re making. It also helps frame the question as to why something is a principle at all. Is it a direct benefit? Or is it just a limitation so we don?t explore the complete answer space? >>> >>> One thing that you do not touch upon, is where in the layers (or lack-of-layers), something happens. Whether something is part of the ?core/base? protocol or in a layer above it (or bellow it). What are the assumptions about what is provided bellow and what are the assumptions about what you provide at the top? Is there any structure internally that matters, if so, what? >>> >>> For example, if there is a weather data set that is 2 gigs in size, is that something that is handled by NDN, a part of NDN, or something that runs on top of NDN? This makes some of the choices of the principles have different meanings. >>> >>> The main web page for UCLA cannot be immutable. Just like my bank account cannot be immutable. Surely some part of that can be immutable, and some part of that can have a name, but I assume there is a way to name the UCLA main web page, or my bank account. >> >>Immutable data packet does **NOT** mean that the content of UCLA page cannot be changed. It means that the specific and uniquely named data packet will not ever change. The UCLA page is simply representable with differently named data packet(s) at different points of time. The whole point of the data immutability is to provide coordination in a distributed system. >> >>(I would recommend reading "Immutability Changes Everything" by P. Helland http://dx.doi.org/10.1145/2844112 and related works.) > >Maybe it wasn?t clear that I?m in favor of Immutability at many layers. Whether we?re talking about packets, reduplicated blocks, strings in python or RDDs. > >My point was that it is unclear from the principles what layers we?re talking about. When people talk about NDN (or CCN for that matter) they refer to a lot of different things. So, while I?m happy to push for immutability of packets, we need to be clear where we are talking about. > >Also, note that the text in the web-page is a little bit misleading. Quoting from the page: >"Data packet immutability allows disambiguation of coordination in distributed system that may not be always connected. Although data packets are immutable, applications can make changes to the communicated content by creating new versions of immutable data packets.? > >What does it mean to create ?new versions of immutable data packets?? If they are immutable, how do you make changes? > >My guess is that there is some other concept that is missing. The concept of a ?big object? or a group, or some other ?named entity?. And this is the thing that has versions. And each version is composed of immutable data packets. > >I would suggest that this must be clarified. Yes, a term for this would be helpful. In NDN, it is (sometimes, loosely) a name prefix for an object that has versions, segments, samples, etc. In CCN >1.0 it seems like there is a related idea of the name for which you might get different answers at different times / in different contexts? Am I drawing the right analogy? > > >>> I will make some comments on the principles in separate emails. I do have one opening question. Is performance/efficiency not a principle at all? Would we be ok with a protocol that meets all of these principles but it?s not better in performance than the alternatives? Do we think that performance comes from these principles? Do we think performance doesn?t matter? Do we think that performance doesn?t matter yet? Do we think performance will come later? Or is performance implied as an overarching goal? >> >>Performance is important, but it cannot be a principle for the networking architecture. The first priority is the goals and general principles of the architecture. Then there is engineering on how to ensure that everything can work efficiently. >> >>As a historical perspective. If "performance" was the primary goal for IP, we wouldn't have it as the whole TCP/IP stack was considered extremely inefficient (Lixia, Van, and other can add more to this). It is the superior functionality of the IP that made it widespread and then highly optimized. > >TCP/IP did have a goal to be better than the previous networks. It is true that it did not _offer_ better ?performance? than the previous networks in many areas, but the goals was to make the network better. > >Quoting Dave Clark[1]: "The top level goal for the DARPA Internet Architecture was to develop an effective technique for multiplexed utilization of existing interconnected networks.? > >Note the use of the word effective; which Dave then tries to elaborate further down the paper. Also note that Dave talks about an alternative approach and part of the issue is a way to determine which approach was the right one. > >Since we?re on the subject; the second level goals from Dave?s paper: >1. Internet communication must continue despite loss of networks or gateways. >2. The Internet must support multiple types of communications service. >3. The Internet architecture must accommodate a variety of networks. >4. The Internet architecture must permit distributed management of its resources. >5. The Internet architecture must be cost effective. >6. The Internet architecture must permit host attachment with a low level of effort. >7. The resources used in the internet architecture must be accountable > > >Note that these try to focus on the goal, not how the goal is achieved. Indeed, the paper calls these "goals", not principles, and IIRC it explains how they motivate features/principles. Two things to consider: 1) the paper is retrospective, as has been pointed out to me before, 2) there *are* decision decisions, pretty close to principles, that seem to be articulated in the paper as well, as a result of these goals - perhaps the choice of packet switching itself. See Section 2. > >To me, the principles that were sent seem more like ?design choices?, not principles or goals. > >For example; why is ?Securing Data Directly? a principle/property/goal at this layer? There should be some good justification of why this was done and we didn?t choose a different approach. Why is this not a transport level issue? Or an application level issue? > >I?m picking this mostly because I think it should be one of the easy ones to justify, no? But the same should be true for all principles. > >>> Also, as a philosophical question; have you thought about framing the issue as ?these are the problems we are trying to solve? instead of ?this is what we think the end-goal is?? I think this has been done, or is being done, through all of the publications on NDN that have been written. While there's definite value in trying to summarize those goals as they generate or impact these principles, I think the intended spirit of opening the principles to discussion is with the overarching goals articulated in that other material in mind. At least that's how I read them. Jeff >> >>Among the principles, there is a little bit of mix, but of slightly different things. There is a principles that is an overarching goal (e.e., universality) and there are principles about the directions we are achieving the overarching goal. I would call the latter "the feature to realize", not problems. > >So you?re saying that the principles are not really principles? > >Can we then clarify, what each principle is? A goal, a problem, a design decision, etc. > > >Nacho > > > > > >[1] The Design Philosophy of the DARPA Internet Protocols - http://ccr.sigcomm.org/archive/1995/jan95/ccr-9501-clark.pdf > > >> >>--- >>Alex >> >>> >>> Nacho >>> >>> PS- Yes, I realize some of these questions can apply to CCN as well. >>> >>> >>> -- >>> Nacho (Ignacio) Solis >>> Protocol Architect >>> Principal Scientist >>> Palo Alto Research Center (PARC) >>> +1(650)812-4458 >>> Ignacio.Solis at parc.com >>> >>> >>> >>> >>> >>> >>> >>> >>> On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" wrote: >>> >>>> Dear all, >>>> >>>> Recently, we have been working to formalize a list of basic principles that underly the design of the NDN architecture. We have assembled the initial list of 6 principles and would like to ask everybody for the all kind of feedback about the identified principles, other potential principles, wording clarification, etc. >>>> >>>> We also hope that the NDN design principles will start a new round of public architectural discussions, clarifying the current and future design decisions and overall architecture objectives. >>>> >>>> The latest version of the principles and additional information is available on NDN website: >>>> http://named-data.net/project/ndn-design-principles/ >>>> >>>> * * * >>>> >>>> For convenience, here is the current version of the list without additional information: >>>> >>>> [1] **Universality**: >>>> NDN should be a common network protocol for all applications and network environments. >>>> >>>> [2] **Data-Centricity and Data Immutability**: >>>> NDN should fetch uniquely named, immutable ?data packets? requested using ?interest packets?. >>>> >>>> [3] **Securing Data Directly**: >>>> Security should be the property of data packets, staying the same whether the packets are in motion or at rest. >>>> >>>> [4] **Hierarchical Naming**: >>>> Packets should carry hierarchical names to enable demultiplexing and provide structured context. >>>> >>>> [5] **In-Network Name Discovery**: >>>> Interests should be able use incomplete names to retrieve data packets. >>>> >>>> [6] **Hop-by-Hop Flow Balance**: >>>> Over each link, one interest packet should bring back no more than one data packet. >>>> >>>> * * * >>>> >>>> Sincerely, >>>> Alex >>>> >> > >_______________________________________________ >Ndn-interest mailing list >Ndn-interest at lists.cs.ucla.edu >http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From jburke at remap.UCLA.edu Tue Mar 15 09:11:07 2016 From: jburke at remap.UCLA.edu (Burke, Jeff) Date: Tue, 15 Mar 2016 16:11:07 +0000 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <56E70CA2.1080905@cisco.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> Message-ID: <6242E46A-6B7D-41BF-B636-E24C803263F4@remap.ucla.edu> -----Original Message----- From: Mark Stapp Date: Monday, March 14, 2016 at 12:10 PM To: Jeff Burke , GTS , UCLA NDN List Subject: Re: [Ndn-interest] NDN protocol principles: no privacy? >interesting - > >On 3/14/16 11:27 AM, Burke, Jeff wrote: >> >[...] >RFC 6973 takes a nice approach, for example, by offering >>> definitions of some technical properties and mechanisms, but not trying >>> to formulate an overall definition of "privacy". >> >> So I can try to understand your point here - do you agree with the >authors that the primary privacy concerns are those of individuals? (Or, >more generally, are corporations people here for this discussion - a >more generic "data owner"?) >> > >hmm - well, I don't think corporations are people, in the citizens >united sense, but I think there's lots of commercial communication that >needs to have the best possible protection, whether it's B2C or B2B? Ok. > >>> The editors there say >>> that the body of the document, the discussion of the tradeoffs and >>> alternatives, is the best way they could come up with to approach that >>> abstraction. in practical terms, as you know well I think there's been >>> an over-reliance on opportunistic caching in ICN generally, and as a >>> result observability and correlation are defined to be positive >>> properties of ICN communication rather than harmful ones. >> >> >> Would I be correct to parse your concerns into two pieces that may >have different implications: >> >> - Confidentiality of request (e.g., the consumer side) >> - Confidentiality of publication (e.g., the publisher side) >> > >I think I have a mental image of "confidential request" - where an >observer cannot see much beyond the routeable prefix needed to reach an >instance of the service I want to communicate with. I'm not sure what >"confidential publication" means, though? I think I want the replies to >my requests to be encrypted with ephemeral, forward-secure key material, >I don't want the names in the replies to expose any more than the names >in the requests, and I want to be able to authenticate the service >before I expose anything about my own identity or intentions. is that >what you meant by "the publisher side"? I was trying to distinguish between data the producer would like to keep confidential vs. requests and responses (e.g., identified by name only) that the consumer would like to keep confidential. Seems like there are some cases where the producer might not need to keep data confidential but the consumer might not want anyone to know they requested it, for example Wikipedia, or pubmed, or any government data in public record. Your example cases are often where both the consumer and producer desire data to be confidential (e.g., your bank data), but this is not the only case. > >[...] > >>> >>> most of these six "principles" sounded like "mechanisms" to me - the >>> list felt like the end of a discussion about alternatives and the best >>> ways to implement an architecture, rather than the start of one. it >>> sounded like "we're tired of questions about LPM in the PIT, so we're >>> going to stop calling that a possible mechanism and start calling it an >>> inevitable, immutable, unquestionable 'principle'". >> >> Well, to take LPM for an example - it's actually not mentioned in >> the >principle doc that Alex sent. The principle I suspect that you are >referring to is: >> >> [5] In-Network Name Discovery: Interests should be able use >> incomplete >names to retrieve data packets. >> A consumer may not know the complete network-level name for data, as >some parts of the name cannot be guessed, computed, or inferred >beforehand. Once initial data is received, naming conventions can help >determine complete names of other related data: >> >> >> * majority of interests will carry complete names >> >> * in-network name discovery expected to be used to bootstrap >communication) >> >> >> >> Can you explain your objection in these terms? >> > >sure - I don't want to expose names that identify me, or expose my >communication activities. given that, the "network" doesn't have the job >of finding things for me by partial names - I only want to expose the >details of my communication to a service that I have authenticated, and >only when those details are encrypted. the "names" visible to the >network in that sort of world just get the packets moving - and the only >LPM needed is LPM in the FIB to get me to one or more instances of a >service. So in this case you are ok with requests to service names that reflect a plaintext prefix (/com/facebook) but have further components encrypted by ephemeral keys? What about cert or key names that may reflect your identity being requested by the service during authentication? If "in-network discovery" was used to find a sufficiently current version of the certs in the authentication phase of this scenario, would that be objectionable? Just trying to understand the limits here. thanks, Jeff > >Thanks, >Mark From ravi.ravindran at gmail.com Tue Mar 15 09:22:02 2016 From: ravi.ravindran at gmail.com (Ravi Ravindran) Date: Tue, 15 Mar 2016 09:22:02 -0700 Subject: [Ndn-interest] Hop-by-Hop Flow Balance In-Reply-To: References: Message-ID: Another primitive that is missing in NDN/CCN is the need to PUSH content, most of the IoT and social networking applications requires this primitive. Today the solutions include using the long-lived interests or polling mechanisms which are not desirable, so if once such primitive is introduced this also questions the per-hop flow control objective. Regards, Ravi On Mon, Mar 14, 2016 at 4:09 PM, wrote: > [ Disclaimer: CCN currently uses flow balance as well ] > > The current Hop-by-Hop Flow Balance is nonsense. > > > > > > On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" < > ndn-interest-bounces at lists.cs.ucla.edu on behalf of aa at CS.UCLA.EDU> wrote: > >[6] **Hop-by-Hop Flow Balance**: > > Over each link, one interest packet should bring back no more than > one data packet. > > Seriously, who thinks this actually works? > > Let me quote the webpage ( > http://named-data.net/project/ndn-design-principles/ ): > "[6] Hop-by-Hop Flow Balancing: Over each link, one interest packet should > bring back no more than one data packet. > Hop-by-hop flow balancing enables each node to control load over its > links. By deciding to sending interest over a link, router commits > bandwidth for the returned data. By limiting the number of interests sent, > each router and client node in the network control how much data it will > receive. > " > > Either there is a lot of information missing here to justify why this is > so, or this is very na?ve. > > First, if what you want to do is limit the number of content objects (or > packets) returned, you don?t need to send one interest. _Specially_ for > NDN, which has prefix matching, you could send one interest with a count > number (10) and expect to receive 10 content objects back. There is no > reason why I need to send 10 exact copies of the same interest. Even if > the interests had small variations, why send 10? Why not send 1 + the 10 > deltas? I guess it?s possible you may call that part of the ?network > adaptation layer?, who knows. > > Also by requiring 1-to-1, you are always requiring an overhead (on the > requester side) that is quite high. If you think of today?s type of > networks, where a packet (internet sized) is around 1500 bytes, that means > that even if we send interests of 30 bytes, we are incurring quite a bit of > overhead in the upstream. This becomes considerable when doing high > bandwidth video. > > Please explain why the 1-to-1 is good. > > Second, NDN allows very large packet sizes. So, when I send 1 interest, I > don?t now if what I?m going to get back is 1 byte or 18 exabytes. How do > routers use this information to control how much data they?re going to > receive? Are they going to reserve 18 exabytes of traffic time? > > If this principle were to be re-written as: > ?Allow network nodes to participate in flow control? then the actual > engineering solution might be able to achieve this. > > Finally, at least we should acknowledge the limitations this type of > approach requires; like symmetrical forwarding. > > It would be awkward if the only way for NDN to work over Satellite links > would be to break the principles. > > Nacho > > > PS. Yes, there are people in this community who have looked at other ways > to do flow-balance and flow-control. Maybe we should be learning from those > and not just claiming as principle what we do today because we don?t want > it questioned. > > -- > Nacho (Ignacio) Solis > Protocol Architect > Principal Scientist > Palo Alto Research Center (PARC) > +1(650)812-4458 > Ignacio.Solis at parc.com > > _______________________________________________ > 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 jburke at remap.ucla.edu Tue Mar 15 09:44:51 2016 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Tue, 15 Mar 2016 16:44:51 +0000 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <56E6E5F7.2070106@cisco.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E63911.7020605@ics.uci.edu> <56E6BA8C.6090703@cisco.com> <56E6E5F7.2070106@cisco.com> Message-ID: Hi Mark, From: Mark Stapp Date: Monday, March 14, 2016 at 9:25 AM >Hi Jeff, > >On 3/14/16 11:02 AM, Burke, Jeff wrote: >> >[...] >>> that is a statement I've heard repeated, but the deeds don't align with >>> the words. NDN has encouraged the use of long-lived public/private key >>> pairs, and that makes individuals highly observable, and vulnerable in >>> the case of key compromise. I don't know whether NSF noticed, but ... >>> you can't do your banking with this stuff yet - and it's been years. and >>> since the folks in charge flat-out reject DH negotiation, it's a little >>> hard to see how they're going to come up with any forward-secure >>> approach. just exactly what privacy-by-design feature are you referring to? >> >> >> Mark, >> >> Where are you getting this impression of a lack of interest in >security? Six of the last ten NDN tech reports deal with >security-related topics, several of the techniques could be extended to >use ephemeral keys, and a few have discussions of forward secrecy. >> > >so ... I was referring specifically to privacy, not "security" in >general. having "discussions" about forward-security is not equivalent >to implementing and mandating it? Of course. I didn't really mean to conflate these or suggest that discussing them is the same as requiring them. Probably in a little haste I was responding to previous more general comments about security in other contexts - the point being that these things are being considered. >as long as user activity can be >correlated readily, there's an exposure that seems to me to be >undesireable - and it's unnecessary, given the technology that exists. >the initial point I was trying to make was that it felt (to me) that >there was a gap in the list of six because there was no mention of >private communication. as I said in an earlier email, even having a >broad statement would seem to be desireable. I tend to agree with Luca that I'm not sure this would be a principle in the same sense as the others. BUT, I am also really interested in what might be "application-level" concepts or conventions that would be just as valuable. So, to me, whether or not it is in the design principle list doesn't exclude it from discussion or showing up in some other list. > >[...] > >> >> >> Can you give an example or two of what such a satisfactory privacy >principle might look like? (Perhaps there is disagreement about whether >this is a principle for the architecture or applications, but >articulating it seems valuable. We've certainly set it up as a goal for >some of the current applications proposed for the current NSF work.) >> > >sure, that'd be fun: > >NDN communication should use, by default, best-practice cryptographic >methods to ensure privacy and confidentiality. unlike IP communication, >where privacy is implemented by add-on libraries and has to be >"programmed in" by each application implementation, NDN will encourage >use of ephemerally-keyed, forward-secure protection for all >communication by making negotiation of ephemeral key material a >fundamental building-block of the architecture. > >or, > >The NDN architecture shares the view of the IP community that passive >and pervasive observation represents an attack on individuals' >communication. NDN communication will meet or exceed the evolving >best-practices for privacy, confidentiality, and authentication used in >IP networking. As the internet security community advances its >understanding of the vulnerabilities affecting internet communication, >NDN will move in parallel to assess vulnerabilites and maintain parity >with the IP technologies. These really help to understand your perspective - thanks. I will discuss them with the NDN folks. Others may see them as application guidelines vs. architectural goals or principles, but the discussion is useful, I think. Some thoughts/questions off of the top of my head: - I'm not sure about the notion of a "default". It seems like it inevitably would devolve to discussion of how often one case versus another occurs, or the social cost of one case vs. the other, to determine what the default should be. I like the second articulation better for that reason, as a goal if not a principle, because it avoids both the language of "defaults" and specific mechanisms. - In the first articulation, can ephemeral be made more specific? How long should a key be used? - In your principle, would you object to using only the term confidentiality over privacy? Seems like this would make it sharper. If you would object, what does privacy cover that confidentiality doesn't, that can be achieved within a network architecture? - Is it possible to articulate confidentiality (or privacy) of what from whom in such a goal/principle? My primary concern here is that current "best practice" includes some real limitations and assumptions (e.g., that once the bits hit the edge of the remote service, things are safe). Just riffing on the above two points - I don't find that confidential communication with Facebook to actually do much for my personal privacy. I do want it to be confidential, but considering just the channel between my browser and the service is a red herring relative to bigger issues of privacy and data ownership. In fact, I would prefer that my postings are confidential from Facebook itself but not my "friends" in their social network - this is not really the current model of session-based security. I suspect that NDN can do better at that, revenue model of the service notwithstanding. (Here, I would like a goal or principles that goes beyond privacy and has to do with data ownership and control, which drives alternative service designs and reflects other rights, not just privacy.) Jeff > >> I think we were going to present contrasting ideas on all of this >(privacy at least) at the upcoming ICNRG meeting. Is that still the >plan? (I think Dirk mentioned you wouldn't be there but perhaps someone >else would present?) >> >> Jeff >> >> > >I haven't looked at the agenda, but I'm certainly interested in the >topic. I won't be there in person, but I've been having some >conversations with Chris Wood, and I think he is planning to offer some >slides. > >Thanks, >Mark From ravi.ravindran at gmail.com Tue Mar 15 09:50:34 2016 From: ravi.ravindran at gmail.com (Ravi Ravindran) Date: Tue, 15 Mar 2016 09:50:34 -0700 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: <36AE833F-2FC1-454B-84FB-5C19042CAC6C@cs.ucla.edu> References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> <36AE833F-2FC1-454B-84FB-5C19042CAC6C@cs.ucla.edu> Message-ID: Just to add to this thread about a single network layer, is that network layer in a provider domain could introduce more service primitives than what an end point may have. We showed this through the use of forwarding-label to handle seamless mobility, https://www.ietf.org/proceedings/interim/2016/01/14/icnrg/slides/slides-interim-2016-icnrg-1-10.pdf or service chaining if we want Interest/Data to go through multiple middle-box services. So in the context of the fixed header and packet format discussion these possibilities should be considered as well. Regards, Ravi On Sun, Mar 13, 2016 at 12:54 PM, Alex Afanasyev wrote: > > > On Mar 11, 2016, at 12:48 AM, Ignacio.Solis at parc.com wrote: > > > > > >> [1] **Universality**: > >> NDN should be a common network protocol for all applications and > network environments. > > > > I?m assuming here that you imply a set of protocols. After all, the way > you do flow control varies a lot from DTN to non-DTN environments. Or are > you limiting this to the basic packet format? > > > > On the web page it calls out for DTN, IoT, Mesh networks, Web, etc. It > seems obvious to me that these require various protocols; potentially > layered or interoperating in some fashion. > > > > If one interprets this principle as ?the base protocol will allow??, > then the question becomes how does the base protocol allow this. > > > > The document states that the protocol should be flexible and extensible. > It then states that there should be no fixed parts or fixed length fields > in the header. I?m unsure what the full rationale is here. Is it that we > will exceed the length of the fields? Or that suddenly one field will > become obsolete and we will want to remove it? Is it because we don?t want > to make assumptions about packets coming in? We want them to be so > flexible that anything is possible? > > This is a reference to the draft we wrote some time ago (a little bit > outdated at this point): > https://tools.ietf.org/html/draft-icn-packet-format-requirements-00 > > The overarching goal is to have the universal network protocol that allows > communication over various types of networking environments (very > constrained MTU; not so constrained MTU) and various applications. The > latter implies there is a need for additional higher-level protocols that > make use of the network-provided communication primitives (and one example > of this is sync). > > Another point is extensibility. As we tried to add in the comment > section, the history with protocol developments has shown that fixed > headers don't make protocol be "easily" extensible in the future. Just a > few random examples: version in IP header has been never used in any > meaningful way; ID, flags, Fragment Offset fields has to be present even > though majority of packets don't need them. > > Not having fixed fields doesn't mean that there couldn't be fixed order or > the current technological limit on what fields are in the packet. It is > just allows a path for evolutional change. > > > In one way or another, we?re making assumptions about the packet coming > in. If it?s not the static header, it?s the fact that the way we parse the > packet has to be consistent. (As in, the first bit determines if the next > byte is a continuation of the first byte, etc). So, to some degree, you > are fixing some formatting. > > > > In one assumption, (fixed header), we are limiting the format and > semantics of the first n bytes (8 or 16 or whatever). In the other space, > you?re limiting the format (but maybe not the semantics of the first n > bytes). You trade off some processing for some byte inefficiency. > > > > The fact that we want the same protocol to work on IoT, datacenter and > interplanetary networks effectively says: > > - The benefits we get from optimizing for each of these scenarios are > less important than the advantage we get by having a single protocol format > that runs in all. > > > > It seems to me that having a single protocol is useful when traffic goes > from one to the other. > > That's the whole point. Because we don't have a single network protocol, > we don't even think that the same (interest/data) traffic can go from one > network to another. > > Without a single network layer protocol, we would be back in today's > position of inventing a large set of various protocols that not compatible > with each other (I would add > http://named-data.net/wp-content/uploads/2016/02/ndn-0038-1-challenges-iot.pdf > as a partial reference for this). > > > If we don?t expect traffic to go from one to the other the benefit > diminishes. Here I?m assuming native network compatible traffic. So that > one packet, comes from IoT and unmodified goes to the datacenter and > unmodified goes to Mars. As opposed to having gateways that can speak > multiple protocols or tunneling and overlays. > > > To calibrate, I?m in the camp of thinking that PIM-SM and PIM-DM are > different protocols. So I would also side with the fact that if you had a > situation where packets on one end of the gateway use NDN but are not > understood at the other side of the gateway then the packets are > effectively from 2 different protocols. > > > > I would also argue that if the purpose of building an extremely flexible > format is to save bytes in one scenario where those are not needed at the > expense of processing, then I would say that you might as well go all the > way and just implement some type of link-layer compression scheme and > really save some bytes. Dictionaries can go a long way. > > > > > > Finally, going back to what?s on the page. When you say that there > should be no fixed parts and no fixed length fields, do you really mean it? > > What we meant is that > - the protocol should use only TLV to do packet NDN network-level packet > representation > - T an L should not be fixed to allow flexibility in supporting small and > large packets. > > How exactly it can be achieved is a good engineering question. > > TLV does not mean or imply there is no "fixed" set of TLVs at a given > point of time. It mean that the set can be evolutionally (not > revolutionary) changed over time. > > -- > Alex > > > - Can I have a packet with no packet_size field? > > - Can I have a packet with no protocol version field? > > - Can I have a packet with no name? > > > > - Can I have a packet with an arbitrary length name? > > - Can I have a packet with an arbitrary size payload? > > - Can I have a packet with 3 payloads? > > - Can I have a packet with 2 names? > > - Can I have a packet with no signature? > > - Must all nodes support all of these packet types? > > - Can I have an arbitrary sized T in a TLV? (I?m assuming you?re > proposing TLVs, but maybe you?re planning on using XML or json for > flexibility.) > > - Can I have an arbitrary sized L? > > > > To preempt the discussion, what part of this is architecture and what > part is policy? > > > > > > Nacho > > > _______________________________________________ > 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 s.h.ahmed at ieee.org Tue Mar 15 09:53:23 2016 From: s.h.ahmed at ieee.org (Syed Hassan Ahmed) Date: Wed, 16 Mar 2016 01:53:23 +0900 Subject: [Ndn-interest] Hop-by-Hop Flow Balance In-Reply-To: References: Message-ID: Dear Prof. Ravi, I do agree and in fact would like to highlight the issue with my advisor as well. According to my understanding, NDN doesn't provide mechanisms to address the demand of Push based communications. One would argue for the example, so here is one: If we expect NDN to support mobile networks, so we may wanna consider VANETs. In vehicular communications, the important messages are BSMs (safety messages) that needs to be push regardless of any Interest message to arrived. Also, there are so many situations, where the Data may want to be delivered by itself. I refer it as "Data Speaks". Precisely, we need to figure out sooner to get PUSH support while keeping the principles of NDN. I may be wrong to come up with a varying solution, however, we can design an "Interest for Interest" special packet and let neighbors to broadcast Interest packet for Data (that wants to be shared) in response to the special packet. Expert opinions are welcomed. Best Regards, Syed Hassan Ahmed. (??) Kyungpook National University, Daegu, Republic of Korea. https://sites.google.com/site/shahmedknu/ > On Mar 16, 2016, at 1:22 AM, Ravi Ravindran wrote: > > Another primitive that is missing in NDN/CCN is the need to PUSH content, most of the IoT and social networking applications requires this primitive. Today the solutions include using the long-lived interests or polling mechanisms which are not desirable, so if once such primitive is introduced this also questions the per-hop flow control objective. > > Regards, > Ravi > >> On Mon, Mar 14, 2016 at 4:09 PM, wrote: >> [ Disclaimer: CCN currently uses flow balance as well ] >> >> The current Hop-by-Hop Flow Balance is nonsense. >> >> >> >> >> >> On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" wrote: >> >[6] **Hop-by-Hop Flow Balance**: >> > Over each link, one interest packet should bring back no more than one data packet. >> >> Seriously, who thinks this actually works? >> >> Let me quote the webpage ( http://named-data.net/project/ndn-design-principles/ ): >> "[6] Hop-by-Hop Flow Balancing: Over each link, one interest packet should bring back no more than one data packet. >> Hop-by-hop flow balancing enables each node to control load over its links. By deciding to sending interest over a link, router commits bandwidth for the returned data. By limiting the number of interests sent, each router and client node in the network control how much data it will receive. >> " >> >> Either there is a lot of information missing here to justify why this is so, or this is very na?ve. >> >> First, if what you want to do is limit the number of content objects (or packets) returned, you don?t need to send one interest. _Specially_ for NDN, which has prefix matching, you could send one interest with a count number (10) and expect to receive 10 content objects back. There is no reason why I need to send 10 exact copies of the same interest. Even if the interests had small variations, why send 10? Why not send 1 + the 10 deltas? I guess it?s possible you may call that part of the ?network adaptation layer?, who knows. >> >> Also by requiring 1-to-1, you are always requiring an overhead (on the requester side) that is quite high. If you think of today?s type of networks, where a packet (internet sized) is around 1500 bytes, that means that even if we send interests of 30 bytes, we are incurring quite a bit of overhead in the upstream. This becomes considerable when doing high bandwidth video. >> >> Please explain why the 1-to-1 is good. >> >> Second, NDN allows very large packet sizes. So, when I send 1 interest, I don?t now if what I?m going to get back is 1 byte or 18 exabytes. How do routers use this information to control how much data they?re going to receive? Are they going to reserve 18 exabytes of traffic time? >> >> If this principle were to be re-written as: >> ?Allow network nodes to participate in flow control? then the actual engineering solution might be able to achieve this. >> >> Finally, at least we should acknowledge the limitations this type of approach requires; like symmetrical forwarding. >> >> It would be awkward if the only way for NDN to work over Satellite links would be to break the principles. >> >> Nacho >> >> >> PS. Yes, there are people in this community who have looked at other ways to do flow-balance and flow-control. Maybe we should be learning from those and not just claiming as principle what we do today because we don?t want it questioned. >> >> -- >> Nacho (Ignacio) Solis >> Protocol Architect >> Principal Scientist >> Palo Alto Research Center (PARC) >> +1(650)812-4458 >> Ignacio.Solis at parc.com >> >> _______________________________________________ >> 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 oran at cisco.com Tue Mar 15 09:55:00 2016 From: oran at cisco.com (Dave Oran (oran)) Date: Tue, 15 Mar 2016 16:55:00 +0000 Subject: [Ndn-interest] Hop-by-Hop Flow Balance In-Reply-To: References: Message-ID: > On Mar 15, 2016, at 9:22 AM, Ravi Ravindran wrote: > > Another primitive that is missing in NDN/CCN is the need to PUSH content, most of the IoT and social networking applications requires this primitive. Not really. What you need is an ability to provoke a pull. > Today the solutions include using the long-lived interests or polling mechanisms which are not desirable, so if once such primitive is introduced this also questions the per-hop flow control objective. > Not really. On the other hand it does require more aggressive congestion control on the Interest transmission. > Regards, > Ravi > > On Mon, Mar 14, 2016 at 4:09 PM, wrote: > [ Disclaimer: CCN currently uses flow balance as well ] > > The current Hop-by-Hop Flow Balance is nonsense. > > > > > > On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" wrote: > >[6] **Hop-by-Hop Flow Balance**: > > Over each link, one interest packet should bring back no more than one data packet. > > Seriously, who thinks this actually works? > > Let me quote the webpage ( http://named-data.net/project/ndn-design-principles/ ): > "[6] Hop-by-Hop Flow Balancing: Over each link, one interest packet should bring back no more than one data packet. > Hop-by-hop flow balancing enables each node to control load over its links. By deciding to sending interest over a link, router commits bandwidth for the returned data. By limiting the number of interests sent, each router and client node in the network control how much data it will receive. > " > > Either there is a lot of information missing here to justify why this is so, or this is very na?ve. > > First, if what you want to do is limit the number of content objects (or packets) returned, you don?t need to send one interest. _Specially_ for NDN, which has prefix matching, you could send one interest with a count number (10) and expect to receive 10 content objects back. There is no reason why I need to send 10 exact copies of the same interest. Even if the interests had small variations, why send 10? Why not send 1 + the 10 deltas? I guess it?s possible you may call that part of the ?network adaptation layer?, who knows. > > Also by requiring 1-to-1, you are always requiring an overhead (on the requester side) that is quite high. If you think of today?s type of networks, where a packet (internet sized) is around 1500 bytes, that means that even if we send interests of 30 bytes, we are incurring quite a bit of overhead in the upstream. This becomes considerable when doing high bandwidth video. > > Please explain why the 1-to-1 is good. > > Second, NDN allows very large packet sizes. So, when I send 1 interest, I don?t now if what I?m going to get back is 1 byte or 18 exabytes. How do routers use this information to control how much data they?re going to receive? Are they going to reserve 18 exabytes of traffic time? > > If this principle were to be re-written as: > ?Allow network nodes to participate in flow control? then the actual engineering solution might be able to achieve this. > > Finally, at least we should acknowledge the limitations this type of approach requires; like symmetrical forwarding. > > It would be awkward if the only way for NDN to work over Satellite links would be to break the principles. > > Nacho > > > PS. Yes, there are people in this community who have looked at other ways to do flow-balance and flow-control. Maybe we should be learning from those and not just claiming as principle what we do today because we don?t want it questioned. > > -- > Nacho (Ignacio) Solis > Protocol Architect > Principal Scientist > Palo Alto Research Center (PARC) > +1(650)812-4458 > Ignacio.Solis at parc.com > > _______________________________________________ > 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 Ignacio.Solis at parc.com Tue Mar 15 10:01:07 2016 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Tue, 15 Mar 2016 17:01:07 +0000 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: <1C73CB59-1E9A-498F-8A4C-9ED7BFE21EAA@remap.ucla.edu> References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> <643A20B7-8AE5-4CDD-991F-B943AB22114D@parc.com> <1C73CB59-1E9A-498F-8A4C-9ED7BFE21EAA@remap.ucla.edu> Message-ID: On 3/15/16, 9:09 AM, "Ndn-interest on behalf of Burke, Jeff" wrote: >>>> Is performance/efficiency not a principle at all? >>> >>>Do you mind explaining what performance specifically (packet encoding/decoding, forwarding, or something else)? >> >>Sure: being better than current networks at something; anything. >> >>I don?t think the principles reflect this well. >> >>That could be faster packet encoding, faster forwarding, more resilient routing, less failures, lower latency, higher privacy, higher security, better redundancy, lower hardware cost, lower overhead (less systems required? maybe like dns or something), etc. > > >Whether or not this sort of thing is a principle, I'm not sure. (It's possible to have a goal that is not a design principle, I think.) But I'd also suggest that *if* performance is considered as a principle or goal, it should be in parallel with considerations that reflect total cost of application development and deployment, like expressiveness, closeness of mapping between the network and applications, etc. As I've suggested elsewhere one starting point is Green, Thomas R. G., and Marian Petre. "Usability analysis of visual programming environments: a ?cognitive dimensions? framework." Journal of Visual Languages & Computing 7.2 (1996): 131-174. Those are all fine goals/principles/etc to have, parallel or primary. However, they, like many others, can be done at many layers. If we want a specific layer to have them as their driving goals we should justify why. The total cost of application development seems something closer to what you expect achieve via a stack and services, not necessarily related to the en maximum length of packets, or for that matter to flow balance. The same thing is true about expressiveness. I have not read your reference so I don?t have a good basis for comparison, but I?m absolutely in favor of having usable programming/application/deployment environments. But this to me does not imply a translation of one-to-one to how things are done at the network layer. >Or, put perhaps more broadly, the way the architecture frames the world / motivates application design is important, too. "A chief service of a designer is helping clients discover what they want designed." - FP Brooks, The Design of Design. Again, that?s a fine point if we talk about an architecture. But in that mode the architecture encompasses a lot of things, not just the bottom most protocol. The architecture encompasses flow control, application level naming, identities, programming APIs, abstract data structures, push primates, etc. > > >> >>In my opinion, there has to be some justification as to why something is a principle. Why is this principle good or required if it is not natively a good one. > >Agreed. (Fortunately I am not organizing the articulation of principles so it is easy to agree. :) > >> >>For example, Universality. Why is this good? Is it good because it doesn?t discriminate? Or is it good because it reduce complexity? (which in turn could be good because it reduces bugs, etc). If so, make that the goal. Make that the principle: ?to make a simpler system? or whatever. > > >Not sure about this. There does need to be justification but simply to swap out design principles for their motivation is probably to end up in something that is too general to be used for design itself. If they are abstracted to far (Eventually this reduces to "The world should be better because this thing exists.") it will be really hard to make decisions based on them. Seems like a balance to strike through iterative discussion like this. Oh yes, don?t get me wrong, you can?t start coding if your goal is just ?lower latency?. But you start from there and drill down as choices are considered and decisions are made. The problem with having something down the chain as a ?principle? means that we set something in stone that wasn?t our end goal or we have to change principles half way through. What we?re trying to get to is different than how we?re trying to get there and why we?re trying to get there. Where do these principles fit? Nacho >>>> On Mar 11, 2016, at 12:48 AM, Ignacio.Solis at parc.com wrote: >>>> >>>> >>>>> [1] **Universality**: >>>>> NDN should be a common network protocol for all applications and network environments. >>>> >>>> I?m assuming here that you imply a set of protocols. After all, the way you do flow control varies a lot from DTN to non-DTN environments. Or are you limiting this to the basic packet format? >>>> >>>> On the web page it calls out for DTN, IoT, Mesh networks, Web, etc. It seems obvious to me that these require various protocols; potentially layered or interoperating in some fashion. >>>> >>>> If one interprets this principle as ?the base protocol will allow??, then the question becomes how does the base protocol allow this. >>>> >>>> The document states that the protocol should be flexible and extensible. It then states that there should be no fixed parts or fixed length fields in the header. I?m unsure what the full rationale is here. Is it that we will exceed the length of the fields? Or that suddenly one field will become obsolete and we will want to remove it? Is it because we don?t want to make assumptions about packets coming in? We want them to be so flexible that anything is possible? >>>> >>>> In one way or another, we?re making assumptions about the packet coming in. If it?s not the static header, it?s the fact that the way we parse the packet has to be consistent. (As in, the first bit determines if the next byte is a continuation of the first byte, etc). So, to some degree, you are fixing some formatting. >>>> >>>> In one assumption, (fixed header), we are limiting the format and semantics of the first n bytes (8 or 16 or whatever). In the other space, you?re limiting the format (but maybe not the semantics of the first n bytes). You trade off some processing for some byte inefficiency. >>>> >>>> The fact that we want the same protocol to work on IoT, datacenter and interplanetary networks effectively says: >>>> - The benefits we get from optimizing for each of these scenarios are less important than the advantage we get by having a single protocol format that runs in all. >>>> >>>> It seems to me that having a single protocol is useful when traffic goes from one to the other. If we don?t expect traffic to go from one to the other the benefit diminishes. Here I?m assuming native network compatible traffic. So that one packet, comes from IoT and unmodified goes to the datacenter and unmodified goes to Mars. As opposed to having gateways that can speak multiple protocols or tunneling and overlays. >>>> >>>> To calibrate, I?m in the camp of thinking that PIM-SM and PIM-DM are different protocols. So I would also side with the fact that if you had a situation where packets on one end of the gateway use NDN but are not understood at the other side of the gateway then the packets are effectively from 2 different protocols. >>>> >>>> I would also argue that if the purpose of building an extremely flexible format is to save bytes in one scenario where those are not needed at the expense of processing, then I would say that you might as well go all the way and just implement some type of link-layer compression scheme and really save some bytes. Dictionaries can go a long way. >>>> >>>> >>>> Finally, going back to what?s on the page. When you say that there should be no fixed parts and no fixed length fields, do you really mean it? >>>> - Can I have a packet with no packet_size field? >>>> - Can I have a packet with no protocol version field? >>>> - Can I have a packet with no name? >>>> >>>> - Can I have a packet with an arbitrary length name? >>>> - Can I have a packet with an arbitrary size payload? >>>> - Can I have a packet with 3 payloads? >>>> - Can I have a packet with 2 names? >>>> - Can I have a packet with no signature? >>>> - Must all nodes support all of these packet types? >>>> - Can I have an arbitrary sized T in a TLV? (I?m assuming you?re proposing TLVs, but maybe you?re planning on using XML or json for flexibility.) >>>> - Can I have an arbitrary sized L? >>>> >>>> To preempt the discussion, what part of this is architecture and what part is policy? >>>> >>>> >>>> Nacho >>>> >>>> >>>> >>>> -- >>>> Nacho (Ignacio) Solis >>>> Protocol Architect >>>> Principal Scientist >>>> Palo Alto Research Center (PARC) >>>> +1(650)812-4458 >>>> Ignacio.Solis at parc.com >>>> >>>> _______________________________________________ >>>> 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 ravi.ravindran at gmail.com Tue Mar 15 10:19:12 2016 From: ravi.ravindran at gmail.com (Ravi Ravindran) Date: Tue, 15 Mar 2016 10:19:12 -0700 Subject: [Ndn-interest] Hop-by-Hop Flow Balance In-Reply-To: References: Message-ID: For the record, I'm from the industry :). Sure, that is good application application you are referring to, where waiting for an RTT for PULL is something one doesn't want. Using any Interest primitive to PUSH data, is always going to be treated as a content fetch by the forwarder, unless one has marked these Interests in someway. Also once you start marking, it is more or less another primitive. Moreover, if one wants to multicast content through a PUSH, then there are routing implications on how those name prefixes have to be treated in the forwarder as well. Regards, Ravi On Tue, Mar 15, 2016 at 9:53 AM, Syed Hassan Ahmed wrote: > Dear Prof. Ravi, > > I do agree and in fact would like to highlight the issue with my advisor > as well. According to my understanding, NDN doesn't provide mechanisms to > address the demand of Push based communications. One would argue for the > example, so here is one: > > If we expect NDN to support mobile networks, so we may wanna consider > VANETs. In vehicular communications, the important messages are BSMs > (safety messages) that needs to be push regardless of any Interest message > to arrived. > > Also, there are so many situations, where the Data may want to be > delivered by itself. I refer it as "Data Speaks". > > Precisely, we need to figure out sooner to get PUSH support while keeping > the principles of NDN. I may be wrong to come up with a varying solution, > however, we can design an "Interest for Interest" special packet and let > neighbors to broadcast Interest packet for Data (that wants to be shared) > in response to the special packet. > > Expert opinions are welcomed. > > Best Regards, > Syed Hassan Ahmed. (??) > Kyungpook National University, > Daegu, Republic of Korea. > https://sites.google.com/site/shahmedknu/ > > On Mar 16, 2016, at 1:22 AM, Ravi Ravindran > wrote: > > Another primitive that is missing in NDN/CCN is the need to PUSH content, > most of the IoT and social networking applications requires this primitive. > Today the solutions include using the long-lived interests or polling > mechanisms which are not desirable, so if once such primitive is introduced > this also questions the per-hop flow control objective. > > Regards, > Ravi > > On Mon, Mar 14, 2016 at 4:09 PM, wrote: > >> [ Disclaimer: CCN currently uses flow balance as well ] >> >> The current Hop-by-Hop Flow Balance is nonsense. >> >> >> >> >> >> On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" < >> ndn-interest-bounces at lists.cs.ucla.edu on behalf of aa at CS.UCLA.EDU> >> wrote: >> >[6] **Hop-by-Hop Flow Balance**: >> > Over each link, one interest packet should bring back no more than >> one data packet. >> >> Seriously, who thinks this actually works? >> >> Let me quote the webpage ( >> http://named-data.net/project/ndn-design-principles/ ): >> "[6] Hop-by-Hop Flow Balancing: Over each link, one interest packet >> should bring back no more than one data packet. >> Hop-by-hop flow balancing enables each node to control load over its >> links. By deciding to sending interest over a link, router commits >> bandwidth for the returned data. By limiting the number of interests sent, >> each router and client node in the network control how much data it will >> receive. >> " >> >> Either there is a lot of information missing here to justify why this is >> so, or this is very na?ve. >> >> First, if what you want to do is limit the number of content objects (or >> packets) returned, you don?t need to send one interest. _Specially_ for >> NDN, which has prefix matching, you could send one interest with a count >> number (10) and expect to receive 10 content objects back. There is no >> reason why I need to send 10 exact copies of the same interest. Even if >> the interests had small variations, why send 10? Why not send 1 + the 10 >> deltas? I guess it?s possible you may call that part of the ?network >> adaptation layer?, who knows. >> >> Also by requiring 1-to-1, you are always requiring an overhead (on the >> requester side) that is quite high. If you think of today?s type of >> networks, where a packet (internet sized) is around 1500 bytes, that means >> that even if we send interests of 30 bytes, we are incurring quite a bit of >> overhead in the upstream. This becomes considerable when doing high >> bandwidth video. >> >> Please explain why the 1-to-1 is good. >> >> Second, NDN allows very large packet sizes. So, when I send 1 interest, >> I don?t now if what I?m going to get back is 1 byte or 18 exabytes. How do >> routers use this information to control how much data they?re going to >> receive? Are they going to reserve 18 exabytes of traffic time? >> >> If this principle were to be re-written as: >> ?Allow network nodes to participate in flow control? then the actual >> engineering solution might be able to achieve this. >> >> Finally, at least we should acknowledge the limitations this type of >> approach requires; like symmetrical forwarding. >> >> It would be awkward if the only way for NDN to work over Satellite links >> would be to break the principles. >> >> Nacho >> >> >> PS. Yes, there are people in this community who have looked at other ways >> to do flow-balance and flow-control. Maybe we should be learning from those >> and not just claiming as principle what we do today because we don?t want >> it questioned. >> >> -- >> Nacho (Ignacio) Solis >> Protocol Architect >> Principal Scientist >> Palo Alto Research Center (PARC) >> +1(650)812-4458 >> Ignacio.Solis at parc.com >> >> _______________________________________________ >> 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 Ignacio.Solis at parc.com Tue Mar 15 10:43:09 2016 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Tue, 15 Mar 2016 17:43:09 +0000 Subject: [Ndn-interest] In-network name discovery -- Re: NDN protocol principles: no privacy? Message-ID: <0E38BD5B-8897-4CEF-B05D-02BD86F4948D@parc.com> On 3/15/16, 9:11 AM, "Ndn-interest on behalf of Burke, Jeff" wrote: >>sure - I don't want to expose names that identify me, or expose my >>communication activities. given that, the "network" doesn't have the job >>of finding things for me by partial names - I only want to expose the >>details of my communication to a service that I have authenticated, and >>only when those details are encrypted. the "names" visible to the >>network in that sort of world just get the packets moving - and the only >>LPM needed is LPM in the FIB to get me to one or more instances of a >>service. > >So in this case you are ok with requests to service names that reflect a plaintext prefix (/com/facebook) but have further components encrypted by ephemeral keys? What about cert or key names that may reflect your identity being requested by the service during authentication? If "in-network discovery" was used to find a sufficiently current version of the certs in the authentication phase of this scenario, would that be objectionable? Just trying to understand the limits here. You don?t have to expose names of keys or certs to intermediary nodes. You only need to expose that information to the parties you choose. Let me talk about "In-network discovery? for a second. [5] **In-Network Name Discovery**: Interests should be able use incomplete names to retrieve data packets. The first thing to say, is that in this phrasing, you mean the network layer, the forwarders, not the network as a whole. Today we do discovery in many ways. Whether it?s mDNS, DNS, a SQL query, a google/bing query or a piece of ajax code. Sometimes we do ping or trace route or god forbid snmp. (Did I mention routing protocols?) There are many ways to do ?discovery?. Because of the nature of NDN/CCN in naming everything, we have to do one extra step that other protocols don?t; the discovery of the name of a network packet. Many times this is not really discovery, it?s mostly like bootstrapping. We need to figure out where to start, and once we have that we can continue. These are all fine goals and problems to have. The way old CCN and NDN try to solve these is by having prefix matching on interests. The argument is that if the network-layer helps with this, then things will be better. I have yet to see a good argument of why this is the case. We?ve had this discussion a number of times. You can do everything the current LPM system can do if you create a simple service that lets you do LPM queries. Let?s call this service the Selector Service. Any node running a Selector Service can then process interests with selectors and generate replies. Any node running a Selector Service can also verify these replies if it wishes (under the same constraints as the current system). Any node NOT wishing to reveal what they have in their caches, or not wanting to waste the extra compute cycles may decide not to run that service. I would like to know what makes the built in LPM mode advantageous than the Selector Service method. I?m not saying that this Selector Service is what I would implement for discovery, but, there it is in case somebody wants it. LPM matching on interests throws a few wrenches in the system. Here are a few: - You never know what you?re going to get. You don?t know if the data you got is what you wanted. (how could you?, if you had known, you would have asked for it directly). Almost by definition, the only way for you to know if what you got is what you wanted is to ask again to get more information. Apparently in some solutions that use this system, you actually have calls that to succeed need to time out. - ?What?s in the network?? is fragile. People claim that you can do this in-network-layer discovery to find if one packet/piece of data (that I only partially know how to prefix-name) is in the connected network. For example, if the producer disconnected or if there is a network partition. This doesn?t really work without some very big participation from routing or by flooding the network. I?m not sure if it?s obvious to people how bad flooding the network is. The situations where this is considered advisable are very special. Why subject the world to this very special case that can lead to disaster? - LPM interests can be abused by malicious nodes. A malicious cache can reply with valid content in a way that creates extra traffic. I think sometimes there is a misunderstanding that exact matching means you must know everything in advance. This is not the case. It just means that I get to ask a specific question and somebody needs to stand up and answer it. Can we have a clear example of where the in-network-layer name discovery is required and provides a benefit? Nacho From Ignacio.Solis at parc.com Tue Mar 15 10:48:16 2016 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Tue, 15 Mar 2016 17:48:16 +0000 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> <643A20B7-8AE5-4CDD-991F-B943AB22114D@parc.com> <1C73CB59-1E9A-498F-8A4C-9ED7BFE21EAA@remap.ucla.edu> Message-ID: <8275101B-F1FD-456F-AB45-FE519453E778@parc.com> On 3/15/16, 10:41 AM, "Apollo Donnerschub" > wrote: Could we perhaps reset and agree that a set of principles are essential characteristics of the system, such that the effective operation or use of the system would be impossible if any one of the principles were to be ignored? I agree that principles are good. They guide design. However, I?m not sure if what you?re suggesting ("the effective operation or use of the system would be impossible if any one of the principles were to be ignored?) is a design description or a principle. In one, we?re describing what we have, not why we have it. In the other, we describe what we want to achieve; and from there we make choices based on tradeoffs. To Solis' point about layers, each layer can have its principles. Perhaps the principles can inform how the layers are formulated. I?m in favor of that. But I do understand that some people will have issues with layers. To Stapp's point, we ignore security at our own peril. If you ignore security you are limiting yourself to a very small world. Also, to be clear, Mark tries to champion privacy as an important driver. Nacho On Tue, Mar 15, 2016 at 10:01 AM, > wrote: On 3/15/16, 9:09 AM, "Ndn-interest on behalf of Burke, Jeff" on behalf of jburke at remap.UCLA.edu> wrote: >>>> Is performance/efficiency not a principle at all? >>> >>>Do you mind explaining what performance specifically (packet encoding/decoding, forwarding, or something else)? >> >>Sure: being better than current networks at something; anything. >> >>I don?t think the principles reflect this well. >> >>That could be faster packet encoding, faster forwarding, more resilient routing, less failures, lower latency, higher privacy, higher security, better redundancy, lower hardware cost, lower overhead (less systems required? maybe like dns or something), etc. > > >Whether or not this sort of thing is a principle, I'm not sure. (It's possible to have a goal that is not a design principle, I think.) But I'd also suggest that *if* performance is considered as a principle or goal, it should be in parallel with considerations that reflect total cost of application development and deployment, like expressiveness, closeness of mapping between the network and applications, etc. As I've suggested elsewhere one starting point is Green, Thomas R. G., and Marian Petre. "Usability analysis of visual programming environments: a ?cognitive dimensions? framework." Journal of Visual Languages & Computing 7.2 (1996): 131-174. Those are all fine goals/principles/etc to have, parallel or primary. However, they, like many others, can be done at many layers. If we want a specific layer to have them as their driving goals we should justify why. The total cost of application development seems something closer to what you expect achieve via a stack and services, not necessarily related to the en maximum length of packets, or for that matter to flow balance. The same thing is true about expressiveness. I have not read your reference so I don?t have a good basis for comparison, but I?m absolutely in favor of having usable programming/application/deployment environments. But this to me does not imply a translation of one-to-one to how things are done at the network layer. >Or, put perhaps more broadly, the way the architecture frames the world / motivates application design is important, too. "A chief service of a designer is helping clients discover what they want designed." - FP Brooks, The Design of Design. Again, that?s a fine point if we talk about an architecture. But in that mode the architecture encompasses a lot of things, not just the bottom most protocol. The architecture encompasses flow control, application level naming, identities, programming APIs, abstract data structures, push primates, etc. > > >> >>In my opinion, there has to be some justification as to why something is a principle. Why is this principle good or required if it is not natively a good one. > >Agreed. (Fortunately I am not organizing the articulation of principles so it is easy to agree. :) > >> >>For example, Universality. Why is this good? Is it good because it doesn?t discriminate? Or is it good because it reduce complexity? (which in turn could be good because it reduces bugs, etc). If so, make that the goal. Make that the principle: ?to make a simpler system? or whatever. > > >Not sure about this. There does need to be justification but simply to swap out design principles for their motivation is probably to end up in something that is too general to be used for design itself. If they are abstracted to far (Eventually this reduces to "The world should be better because this thing exists.") it will be really hard to make decisions based on them. Seems like a balance to strike through iterative discussion like this. Oh yes, don?t get me wrong, you can?t start coding if your goal is just ?lower latency?. But you start from there and drill down as choices are considered and decisions are made. The problem with having something down the chain as a ?principle? means that we set something in stone that wasn?t our end goal or we have to change principles half way through. What we?re trying to get to is different than how we?re trying to get there and why we?re trying to get there. Where do these principles fit? Nacho >>>> On Mar 11, 2016, at 12:48 AM, Ignacio.Solis at parc.com wrote: >>>> >>>> >>>>> [1] **Universality**: >>>>> NDN should be a common network protocol for all applications and network environments. >>>> >>>> I?m assuming here that you imply a set of protocols. After all, the way you do flow control varies a lot from DTN to non-DTN environments. Or are you limiting this to the basic packet format? >>>> >>>> On the web page it calls out for DTN, IoT, Mesh networks, Web, etc. It seems obvious to me that these require various protocols; potentially layered or interoperating in some fashion. >>>> >>>> If one interprets this principle as ?the base protocol will allow??, then the question becomes how does the base protocol allow this. >>>> >>>> The document states that the protocol should be flexible and extensible. It then states that there should be no fixed parts or fixed length fields in the header. I?m unsure what the full rationale is here. Is it that we will exceed the length of the fields? Or that suddenly one field will become obsolete and we will want to remove it? Is it because we don?t want to make assumptions about packets coming in? We want them to be so flexible that anything is possible? >>>> >>>> In one way or another, we?re making assumptions about the packet coming in. If it?s not the static header, it?s the fact that the way we parse the packet has to be consistent. (As in, the first bit determines if the next byte is a continuation of the first byte, etc). So, to some degree, you are fixing some formatting. >>>> >>>> In one assumption, (fixed header), we are limiting the format and semantics of the first n bytes (8 or 16 or whatever). In the other space, you?re limiting the format (but maybe not the semantics of the first n bytes). You trade off some processing for some byte inefficiency. >>>> >>>> The fact that we want the same protocol to work on IoT, datacenter and interplanetary networks effectively says: >>>> - The benefits we get from optimizing for each of these scenarios are less important than the advantage we get by having a single protocol format that runs in all. >>>> >>>> It seems to me that having a single protocol is useful when traffic goes from one to the other. If we don?t expect traffic to go from one to the other the benefit diminishes. Here I?m assuming native network compatible traffic. So that one packet, comes from IoT and unmodified goes to the datacenter and unmodified goes to Mars. As opposed to having gateways that can speak multiple protocols or tunneling and overlays. >>>> >>>> To calibrate, I?m in the camp of thinking that PIM-SM and PIM-DM are different protocols. So I would also side with the fact that if you had a situation where packets on one end of the gateway use NDN but are not understood at the other side of the gateway then the packets are effectively from 2 different protocols. >>>> >>>> I would also argue that if the purpose of building an extremely flexible format is to save bytes in one scenario where those are not needed at the expense of processing, then I would say that you might as well go all the way and just implement some type of link-layer compression scheme and really save some bytes. Dictionaries can go a long way. >>>> >>>> >>>> Finally, going back to what?s on the page. When you say that there should be no fixed parts and no fixed length fields, do you really mean it? >>>> - Can I have a packet with no packet_size field? >>>> - Can I have a packet with no protocol version field? >>>> - Can I have a packet with no name? >>>> >>>> - Can I have a packet with an arbitrary length name? >>>> - Can I have a packet with an arbitrary size payload? >>>> - Can I have a packet with 3 payloads? >>>> - Can I have a packet with 2 names? >>>> - Can I have a packet with no signature? >>>> - Must all nodes support all of these packet types? >>>> - Can I have an arbitrary sized T in a TLV? (I?m assuming you?re proposing TLVs, but maybe you?re planning on using XML or json for flexibility.) >>>> - Can I have an arbitrary sized L? >>>> >>>> To preempt the discussion, what part of this is architecture and what part is policy? >>>> >>>> >>>> Nacho >>>> >>>> >>>> >>>> -- >>>> Nacho (Ignacio) Solis >>>> Protocol Architect >>>> Principal Scientist >>>> Palo Alto Research Center (PARC) >>>> +1(650)812-4458 >>>> Ignacio.Solis at parc.com >>>> >>>> _______________________________________________ >>>> 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 apollodonnerschub at gmail.com Tue Mar 15 10:41:34 2016 From: apollodonnerschub at gmail.com (Apollo Donnerschub) Date: Tue, 15 Mar 2016 10:41:34 -0700 Subject: [Ndn-interest] NDN Protocol Design Principles In-Reply-To: References: <18BA9095-7EEB-45C2-9F3B-1E3C1D0B25D2@cs.ucla.edu> <643A20B7-8AE5-4CDD-991F-B943AB22114D@parc.com> <1C73CB59-1E9A-498F-8A4C-9ED7BFE21EAA@remap.ucla.edu> Message-ID: Hi, I'm usually just a lurker, but I really like the idea of a set of principles as a primary point of understanding the system. That said, the discussion is all over the place with a mix of principles, goals, strategies and so forth. Could we perhaps reset and agree that a set of principles are essential characteristics of the system, such that the effective operation or use of the system would be impossible if any one of the principles were to be ignored? To Solis' point about layers, each layer can have its principles. Perhaps the principles can inform how the layers are formulated. To Stapp's point, we ignore security at our own peril. On Tue, Mar 15, 2016 at 10:01 AM, wrote: > On 3/15/16, 9:09 AM, "Ndn-interest on behalf of Burke, Jeff" < > ndn-interest-bounces at lists.cs.ucla.edu on behalf of jburke at remap.UCLA.edu> > wrote: > > > >>>> Is performance/efficiency not a principle at all? > >>> > >>>Do you mind explaining what performance specifically (packet > encoding/decoding, forwarding, or something else)? > >> > >>Sure: being better than current networks at something; anything. > >> > >>I don?t think the principles reflect this well. > >> > >>That could be faster packet encoding, faster forwarding, more resilient > routing, less failures, lower latency, higher privacy, higher security, > better redundancy, lower hardware cost, lower overhead (less systems > required? maybe like dns or something), etc. > > > > > >Whether or not this sort of thing is a principle, I'm not sure. (It's > possible to have a goal that is not a design principle, I think.) But I'd > also suggest that *if* performance is considered as a principle or goal, it > should be in parallel with considerations that reflect total cost of > application development and deployment, like expressiveness, closeness of > mapping between the network and applications, etc. As I've suggested > elsewhere one starting point is Green, Thomas R. G., and Marian Petre. > "Usability analysis of visual programming environments: a ?cognitive > dimensions? framework." Journal of Visual Languages & Computing 7.2 (1996): > 131-174. > > Those are all fine goals/principles/etc to have, parallel or primary. > However, they, like many others, can be done at many layers. If we want a > specific layer to have them as their driving goals we should justify why. > > The total cost of application development seems something closer to what > you expect achieve via a stack and services, not necessarily related to the > en maximum length of packets, or for that matter to flow balance. The same > thing is true about expressiveness. > > I have not read your reference so I don?t have a good basis for > comparison, but I?m absolutely in favor of having usable > programming/application/deployment environments. But this to me does not > imply a translation of one-to-one to how things are done at the network > layer. > > > >Or, put perhaps more broadly, the way the architecture frames the world / > motivates application design is important, too. "A chief service of a > designer is helping clients discover what they want designed." - FP > Brooks, The Design of Design. > > Again, that?s a fine point if we talk about an architecture. But in that > mode the architecture encompasses a lot of things, not just the bottom most > protocol. The architecture encompasses flow control, application level > naming, identities, programming APIs, abstract data structures, push > primates, etc. > > > > > > > >> > >>In my opinion, there has to be some justification as to why something is > a principle. Why is this principle good or required if it is not natively a > good one. > > > >Agreed. (Fortunately I am not organizing the articulation of principles > so it is easy to agree. :) > > > >> > >>For example, Universality. Why is this good? Is it good because it > doesn?t discriminate? Or is it good because it reduce complexity? (which in > turn could be good because it reduces bugs, etc). If so, make that the > goal. Make that the principle: ?to make a simpler system? or whatever. > > > > > >Not sure about this. There does need to be justification but simply to > swap out design principles for their motivation is probably to end up in > something that is too general to be used for design itself. If they are > abstracted to far (Eventually this reduces to "The world should be better > because this thing exists.") it will be really hard to make decisions based > on them. Seems like a balance to strike through iterative discussion like > this. > > Oh yes, don?t get me wrong, you can?t start coding if your goal is just > ?lower latency?. But you start from there and drill down as choices are > considered and decisions are made. The problem with having something down > the chain as a ?principle? means that we set something in stone that wasn?t > our end goal or we have to change principles half way through. > > What we?re trying to get to is different than how we?re trying to get > there and why we?re trying to get there. > > Where do these principles fit? > > Nacho > > > >>>> On Mar 11, 2016, at 12:48 AM, Ignacio.Solis at parc.com wrote: > >>>> > >>>> > >>>>> [1] **Universality**: > >>>>> NDN should be a common network protocol for all applications and > network environments. > >>>> > >>>> I?m assuming here that you imply a set of protocols. After all, the > way you do flow control varies a lot from DTN to non-DTN environments. Or > are you limiting this to the basic packet format? > >>>> > >>>> On the web page it calls out for DTN, IoT, Mesh networks, Web, etc. > It seems obvious to me that these require various protocols; potentially > layered or interoperating in some fashion. > >>>> > >>>> If one interprets this principle as ?the base protocol will allow??, > then the question becomes how does the base protocol allow this. > >>>> > >>>> The document states that the protocol should be flexible and > extensible. It then states that there should be no fixed parts or fixed > length fields in the header. I?m unsure what the full rationale is here. > Is it that we will exceed the length of the fields? Or that suddenly one > field will become obsolete and we will want to remove it? Is it because we > don?t want to make assumptions about packets coming in? We want them to be > so flexible that anything is possible? > >>>> > >>>> In one way or another, we?re making assumptions about the packet > coming in. If it?s not the static header, it?s the fact that the way we > parse the packet has to be consistent. (As in, the first bit determines if > the next byte is a continuation of the first byte, etc). So, to some > degree, you are fixing some formatting. > >>>> > >>>> In one assumption, (fixed header), we are limiting the format and > semantics of the first n bytes (8 or 16 or whatever). In the other space, > you?re limiting the format (but maybe not the semantics of the first n > bytes). You trade off some processing for some byte inefficiency. > >>>> > >>>> The fact that we want the same protocol to work on IoT, datacenter > and interplanetary networks effectively says: > >>>> - The benefits we get from optimizing for each of these scenarios are > less important than the advantage we get by having a single protocol format > that runs in all. > >>>> > >>>> It seems to me that having a single protocol is useful when traffic > goes from one to the other. If we don?t expect traffic to go from one to > the other the benefit diminishes. Here I?m assuming native network > compatible traffic. So that one packet, comes from IoT and unmodified goes > to the datacenter and unmodified goes to Mars. As opposed to having > gateways that can speak multiple protocols or tunneling and overlays. > >>>> > >>>> To calibrate, I?m in the camp of thinking that PIM-SM and PIM-DM are > different protocols. So I would also side with the fact that if you had a > situation where packets on one end of the gateway use NDN but are not > understood at the other side of the gateway then the packets are > effectively from 2 different protocols. > >>>> > >>>> I would also argue that if the purpose of building an extremely > flexible format is to save bytes in one scenario where those are not needed > at the expense of processing, then I would say that you might as well go > all the way and just implement some type of link-layer compression scheme > and really save some bytes. Dictionaries can go a long way. > >>>> > >>>> > >>>> Finally, going back to what?s on the page. When you say that there > should be no fixed parts and no fixed length fields, do you really mean it? > >>>> - Can I have a packet with no packet_size field? > >>>> - Can I have a packet with no protocol version field? > >>>> - Can I have a packet with no name? > >>>> > >>>> - Can I have a packet with an arbitrary length name? > >>>> - Can I have a packet with an arbitrary size payload? > >>>> - Can I have a packet with 3 payloads? > >>>> - Can I have a packet with 2 names? > >>>> - Can I have a packet with no signature? > >>>> - Must all nodes support all of these packet types? > >>>> - Can I have an arbitrary sized T in a TLV? (I?m assuming you?re > proposing TLVs, but maybe you?re planning on using XML or json for > flexibility.) > >>>> - Can I have an arbitrary sized L? > >>>> > >>>> To preempt the discussion, what part of this is architecture and what > part is policy? > >>>> > >>>> > >>>> Nacho > >>>> > >>>> > >>>> > >>>> -- > >>>> Nacho (Ignacio) Solis > >>>> Protocol Architect > >>>> Principal Scientist > >>>> Palo Alto Research Center (PARC) > >>>> +1(650)812-4458 > >>>> Ignacio.Solis at parc.com > >>>> > >>>> _______________________________________________ > >>>> 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 aa at CS.UCLA.EDU Tue Mar 15 10:58:52 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Tue, 15 Mar 2016 10:58:52 -0700 Subject: [Ndn-interest] In-network name discovery -- Re: NDN protocol principles: no privacy? In-Reply-To: <0E38BD5B-8897-4CEF-B05D-02BD86F4948D@parc.com> References: <0E38BD5B-8897-4CEF-B05D-02BD86F4948D@parc.com> Message-ID: <81413C5A-D761-47C6-B3B2-C38E57298026@cs.ucla.edu> > On Mar 15, 2016, at 10:43 AM, wrote: > > On 3/15/16, 9:11 AM, "Ndn-interest on behalf of Burke, Jeff" wrote: > > >>> sure - I don't want to expose names that identify me, or expose my >>> communication activities. given that, the "network" doesn't have the job >>> of finding things for me by partial names - I only want to expose the >>> details of my communication to a service that I have authenticated, and >>> only when those details are encrypted. the "names" visible to the >>> network in that sort of world just get the packets moving - and the only >>> LPM needed is LPM in the FIB to get me to one or more instances of a >>> service. >> >> So in this case you are ok with requests to service names that reflect a plaintext prefix (/com/facebook) but have further components encrypted by ephemeral keys? What about cert or key names that may reflect your identity being requested by the service during authentication? If "in-network discovery" was used to find a sufficiently current version of the certs in the authentication phase of this scenario, would that be objectionable? Just trying to understand the limits here. > > You don?t have to expose names of keys or certs to intermediary nodes. You only need to expose that information to the parties you choose. > > Let me talk about "In-network discovery? for a second. > > [5] **In-Network Name Discovery**: > Interests should be able use incomplete names to retrieve data packets. > > > The first thing to say, is that in this phrasing, you mean the network layer, the forwarders, not the network as a whole. > > Today we do discovery in many ways. Whether it?s mDNS, DNS, a SQL query, a google/bing query or a piece of ajax code. Sometimes we do ping or trace route or god forbid snmp. (Did I mention routing protocols?) There are many ways to do ?discovery?. > > Because of the nature of NDN/CCN in naming everything, we have to do one extra step that other protocols don?t; the discovery of the name of a network packet. Many times this is not really discovery, it?s mostly like bootstrapping. We need to figure out where to start, and once we have that we can continue. These are all fine goals and problems to have. > > The way old CCN and NDN try to solve these is by having prefix matching on interests. The argument is that if the network-layer helps with this, then things will be better. I have yet to see a good argument of why this is the case. > > We?ve had this discussion a number of times. You can do everything the current LPM system can do if you create a simple service that lets you do LPM queries. Let?s call this service the Selector Service. Any node running a Selector Service can then process interests with selectors and generate replies. Any node running a Selector Service can also verify these replies if it wishes (under the same constraints as the current system). Any node NOT wishing to reveal what they have in their caches, or not wanting to waste the extra compute cycles may decide not to run that service. > > I would like to know what makes the built in LPM mode advantageous than the Selector Service method. > > I?m not saying that this Selector Service is what I would implement for discovery, but, there it is in case somebody wants it. > > LPM matching on interests throws a few wrenches in the system. Here are a few: > > - You never know what you?re going to get. You don?t know if the data you got is what you wanted. (how could you?, if you had known, you would have asked for it directly). Almost by definition, the only way for you to know if what you got is what you wanted is to ask again to get more information. Apparently in some solutions that use this system, you actually have calls that to succeed need to time out. > > - ?What?s in the network?? is fragile. People claim that you can do this in-network-layer discovery to find if one packet/piece of data (that I only partially know how to prefix-name) is in the connected network. For example, if the producer disconnected or if there is a network partition. This doesn?t really work without some very big participation from routing or by flooding the network. I?m not sure if it?s obvious to people how bad flooding the network is. The situations where this is considered advisable are very special. Why subject the world to this very special case that can lead to disaster? > > - LPM interests can be abused by malicious nodes. A malicious cache can reply with valid content in a way that creates extra traffic. > > > I think sometimes there is a misunderstanding that exact matching means you must know everything in advance. This is not the case. It just means that I get to ask a specific question and somebody needs to stand up and answer it. > > > Can we have a clear example of where the in-network-layer name discovery is required and provides a benefit? In order to support data retrieval **not only in infrastructure-based, always connected Internet**, but also in systems that can be infrequently connected (e.g., disaster environment, vehicular environments, some sensor networks, and many more example), you HAVE TO have the in-network discovery. There is simply no way it is possible to have an "oracle" that can tell you what is there. I think Tai Lin in one of the previous emails correctly noted that with immutable data packets, it is simply impossible to not have in-network discovery. The communication will not work otherwise without having an out-of-band channel to tell you what to fetch. What is the best way to achieve this is a completely different question. And a note note. It is not LPM! It is fetching data with interests that don't have a full name (if needed with hash digest. --- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mjs at cisco.com Tue Mar 15 12:06:24 2016 From: mjs at cisco.com (Mark Stapp) Date: Tue, 15 Mar 2016 15:06:24 -0400 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <6242E46A-6B7D-41BF-B636-E24C803263F4@remap.ucla.edu> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E70CA2.1080905@cisco.com> <6242E46A-6B7D-41BF-B636-E24C803263F4@remap.ucla.edu> Message-ID: <56E85D30.9040404@cisco.com> On 3/15/16 12:11 PM, Burke, Jeff wrote: > > [...] >> I think I have a mental image of "confidential request" - where an >> observer cannot see much beyond the routeable prefix needed to reach an >> instance of the service I want to communicate with. I'm not sure what >> "confidential publication" means, though? I think I want the replies to >> my requests to be encrypted with ephemeral, forward-secure key material, >> I don't want the names in the replies to expose any more than the names >> in the requests, and I want to be able to authenticate the service >> before I expose anything about my own identity or intentions. is that >> what you meant by "the publisher side"? > > > I was trying to distinguish between data the producer would like to > keep confidential vs. requests and responses (e.g., identified by name > only) that the consumer would like to keep confidential. Seems like > there are some cases where the producer might not need to keep data > confidential but the consumer might not want anyone to know they > requested it, for example Wikipedia, or pubmed, or any government data > in public record. Your example cases are often where both the consumer > and producer desire data to be confidential (e.g., your bank data), >but this is not the only case. > > hmm - I'm not sure I'm following that. Forward-secure transmission initiated by the client ensures that no observer can tell what the client did - what it asked for, what the results were - and ensures that different clients' activities cannot be correlated together. when you say "the producer might not need", are you saying that you think the producer would be impaired in some way if we communicated privately? I don't get that. [...] >> >> sure - I don't want to expose names that identify me, or expose my >> communication activities. given that, the "network" doesn't have the job >> of finding things for me by partial names - I only want to expose the >> details of my communication to a service that I have authenticated, and >> only when those details are encrypted. the "names" visible to the >> network in that sort of world just get the packets moving - and the only >> LPM needed is LPM in the FIB to get me to one or more instances of a >> service. > > So in this case you are ok with requests to service names that > reflect > a plaintext prefix (/com/facebook) but have further components > encrypted by ephemeral keys? What I've been trying to advocate is parity with the existing internet, as a baseline. If we can do better in ICN, that'd be great - and it would be fine to be spending less time justifying private communication and trying to identify some _advantage_ in the ICN architectures, frankly. In the current internet, an observer could see me query DNS for "facebook.com", and then could see the returned A or AAAA records, and then could see me initiate a TLS session with one of those destinations. DNS aside (or once DPRIVE is widely deployed), some observer could see me initiate a TLS session with a destination that could be associated with a facebook data center. so ... that's pretty much a wash, to me. now, fb is sort of special, because they're so big that they have their own DCs. Other applications that use AWS, for example, are somewhat obscured, if the DNS query is private. In their cases, the observer just sees me initiate TLS with an AWS DC, and they can't readily tell what application I'm using. As I say, I'd like to have ICN be able to do at least as well as IP. I can imagine that in fact some applications could do that in some cases. Apps running natively on my pc or my phone could in fact know that they use some DC/CDN, and could in fact just ... communicate with it using ICN messages. That'd represent parity (imo), in terms of what would be observable. and just to be clear: the forward-secure crypto doesn't encrypt the name-components in what I've proposed, and in what the ccnx-keyexchange draft describes. the name in the messages just routes to an instance of the application and carries some session identifier. the names are completely ephemeral. the actual communication that the application does takes places entirely inside the crypto envelope. what the application does in there is ... an application thing. > What about cert or key names that may reflect your > identity being requested by the service during authentication? hmm - that's not how TLS/dTLS/ccnx-keyex work. there's an initial diffie-hellman round, with no authentication. then the service authenticates, before the client offers anything at all. then the client may authenticate as part of the crypto, or not. it's very uncommon at this time for _individuals_ to be asked to supply proofs during private session setup. the 'login' you do to use a service as an individual happens inside the crypto envelope, not as part of establishing the envelope. but all of the authentication happens inside an ephemeral DH envelope, so it's pretty resistant to observation. it can be MITM'd, of course, but as I say, only the cert of the service would be available there, nothing from the client/individual. > If > "in-network discovery" was used to find a sufficiently current version > of the certs in the authentication phase of this scenario, would that > be objectionable? Just trying to understand the limits here. > that's ... also not really how it works. the service sends me (as a client) its cert, or cert chain, or a compressed version if it thinks I may already have cached or pinned the cert chain. I (as a client) don't have to go looking for it at all - presentation of the proof that the service holds a private key that should be trusted is part of the private session establishment protocol. Thanks, Mark From gts at ics.uci.edu Tue Mar 15 12:09:00 2016 From: gts at ics.uci.edu (GTS) Date: Tue, 15 Mar 2016 12:09:00 -0700 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: <593958A8-CDCB-4E14-9979-68195D3D60BC@parc.com> References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E63911.7020605@ics.uci.edu> <56E6BA8C.6090703@cisco.com> <56E6E7F9.3040400@ics.uci.edu> <593958A8-CDCB-4E14-9979-68195D3D60BC@parc.com> Message-ID: <56E85DCC.5070005@ics.uci.edu> Sorry, I'm a bit slow to reply: 1) True, PITs are not mandatory, but some form of router state is. (In order to avoid source addresses in interests). 2) Encrypted source addresses in interests are fine (I wasn't excluding them in my statement). However, who will decrypt them? Routers? Producers? Using what crypto? If public key, we'd have an excellent new means of DoS... If symmetric, how are keys distributed/managed? 3) I believe that router caching enables not having destination addresses in interests. But, I'm not even sure what a "destination address" is, broadly speaking. An interest reflects a content name, for which the corresponding content might at the producer (or not yet cached along any sensible path between consumer and producer). In that case, a content name is equivalent to a destination address. Otherwise, if the content is already cached along some consumer-producer path, we can view the content name (say, XYZ) in the interest as a destination address of an *anycast* group XYZ, where a node is a group member if it caches XYZ. So, either way, it's a destination address. Cheers, Gene p.s. In case it isn't obvious, (3) is a tongue-in-cheek comment. ====================== Gene Tsudik Chancellor's Professor of Computer Science University of California, Irvine On 3/14/16 10:52 AM, Ignacio.Solis at parc.com wrote: > ..... > We don?t specifically need the current structure of PITs, we need some > state at the routers to avoid source addresses in interests. Also, to > go even further, even if we had to put source addresses in [some] > interests, that doesn?t mean that they have to be in the clear. I?m > also not sure how to follow that caching specifically is what allows > us to avoid destination addresses. Nacho From oran at cisco.com Tue Mar 15 12:11:58 2016 From: oran at cisco.com (Dave Oran (oran)) Date: Tue, 15 Mar 2016 19:11:58 +0000 Subject: [Ndn-interest] In-network name discovery -- Re: NDN protocol principles: no privacy? In-Reply-To: <81413C5A-D761-47C6-B3B2-C38E57298026@cs.ucla.edu> References: <0E38BD5B-8897-4CEF-B05D-02BD86F4948D@parc.com> <81413C5A-D761-47C6-B3B2-C38E57298026@cs.ucla.edu> Message-ID: <4413371A-6849-487B-9C51-8DF3051B41E3@cisco.com> > On Mar 15, 2016, at 10:58 AM, Alex Afanasyev wrote: > >> >> On Mar 15, 2016, at 10:43 AM, wrote: >> >> On 3/15/16, 9:11 AM, "Ndn-interest on behalf of Burke, Jeff" wrote: >> [SNIP] >> Can we have a clear example of where the in-network-layer name discovery is required and provides a benefit? > > In order to support data retrieval **not only in infrastructure-based, always connected Internet**, but also in systems that can be infrequently connected (e.g., disaster environment, vehicular environments, some sensor networks, and many more example), you HAVE TO have the in-network discovery. There is simply no way it is possible to have an "oracle" that can tell you what is there. > I disagree. The requirement is that within any partition of the network that needs to operate autonomously, there has to be a service instance that can answer bootstrapping/discovery queries. The requirement for in-network discovery is in fact neither necessary NOR sufficient. If the network nodes that are doing this magic in fact have very small caches, or no caches at all (think a mesh sensor network with no large-memory nodes) then in-network discover mechanisms will fail. Further, if in order to obtain an useful bootstrapping data you have to flood rather than route to a discovery service, there are some obvious scalability and DDoS concerns. > I think Tai Lin in one of the previous emails correctly noted that with immutable data packets, it is simply impossible to not have in-network discovery. We need a crisp definition of an ?immutable data packet? to continue this discussion productively. If the only immutable property is on hash-based names and you ONLY can request data by hash-name, then you have only immutable packets. On the other hand, if you can have different packets, with different hashes, that bind the same name (minus the hash) to different data, the useful application-meaningful data is not immutable. It?s also important to add time to the semantics here, such that applications may operatie correctly if and only if there is only one *unexpired* packet with a given name emitted by a publisher in a given expiration period. > The communication will not work otherwise without having an out-of-band channel to tell you what to fetch. What is the best way to achieve this is a completely different question. > > And a note note. It is not LPM! It is fetching data with interests that don't have a full name (if needed with hash digest. Actually, this is an interesting point. Are you saying you can return *ANY* prefix match? If so, I don?t understand how you can design a non-terminating search algorithm unless you allow unbounded exclusion sets (which might be needed in practice even *with* LPM). > > --- > Alex > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Marc.Mosko at parc.com Tue Mar 15 12:20:05 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Tue, 15 Mar 2016 19:20:05 +0000 Subject: [Ndn-interest] In-network name discovery -- Re: NDN protocol principles: no privacy? In-Reply-To: <81413C5A-D761-47C6-B3B2-C38E57298026@cs.ucla.edu> References: <0E38BD5B-8897-4CEF-B05D-02BD86F4948D@parc.com> <81413C5A-D761-47C6-B3B2-C38E57298026@cs.ucla.edu> Message-ID: On Mar 15, 2016, at 10:58 AM, Alex Afanasyev > wrote: On Mar 15, 2016, at 10:43 AM, > > wrote: On 3/15/16, 9:11 AM, "Ndn-interest on behalf of Burke, Jeff" on behalf of jburke at remap.UCLA.edu> wrote: sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. So in this case you are ok with requests to service names that reflect a plaintext prefix (/com/facebook) but have further components encrypted by ephemeral keys? What about cert or key names that may reflect your identity being requested by the service during authentication? If "in-network discovery" was used to find a sufficiently current version of the certs in the authentication phase of this scenario, would that be objectionable? Just trying to understand the limits here. You don?t have to expose names of keys or certs to intermediary nodes. You only need to expose that information to the parties you choose. Let me talk about "In-network discovery? for a second. [5] **In-Network Name Discovery**: Interests should be able use incomplete names to retrieve data packets. The first thing to say, is that in this phrasing, you mean the network layer, the forwarders, not the network as a whole. Today we do discovery in many ways. Whether it?s mDNS, DNS, a SQL query, a google/bing query or a piece of ajax code. Sometimes we do ping or trace route or god forbid snmp. (Did I mention routing protocols?) There are many ways to do ?discovery?. Because of the nature of NDN/CCN in naming everything, we have to do one extra step that other protocols don?t; the discovery of the name of a network packet. Many times this is not really discovery, it?s mostly like bootstrapping. We need to figure out where to start, and once we have that we can continue. These are all fine goals and problems to have. The way old CCN and NDN try to solve these is by having prefix matching on interests. The argument is that if the network-layer helps with this, then things will be better. I have yet to see a good argument of why this is the case. We?ve had this discussion a number of times. You can do everything the current LPM system can do if you create a simple service that lets you do LPM queries. Let?s call this service the Selector Service. Any node running a Selector Service can then process interests with selectors and generate replies. Any node running a Selector Service can also verify these replies if it wishes (under the same constraints as the current system). Any node NOT wishing to reveal what they have in their caches, or not wanting to waste the extra compute cycles may decide not to run that service. I would like to know what makes the built in LPM mode advantageous than the Selector Service method. I?m not saying that this Selector Service is what I would implement for discovery, but, there it is in case somebody wants it. LPM matching on interests throws a few wrenches in the system. Here are a few: - You never know what you?re going to get. You don?t know if the data you got is what you wanted. (how could you?, if you had known, you would have asked for it directly). Almost by definition, the only way for you to know if what you got is what you wanted is to ask again to get more information. Apparently in some solutions that use this system, you actually have calls that to succeed need to time out. - ?What?s in the network?? is fragile. People claim that you can do this in-network-layer discovery to find if one packet/piece of data (that I only partially know how to prefix-name) is in the connected network. For example, if the producer disconnected or if there is a network partition. This doesn?t really work without some very big participation from routing or by flooding the network. I?m not sure if it?s obvious to people how bad flooding the network is. The situations where this is considered advisable are very special. Why subject the world to this very special case that can lead to disaster? - LPM interests can be abused by malicious nodes. A malicious cache can reply with valid content in a way that creates extra traffic. I think sometimes there is a misunderstanding that exact matching means you must know everything in advance. This is not the case. It just means that I get to ask a specific question and somebody needs to stand up and answer it. Can we have a clear example of where the in-network-layer name discovery is required and provides a benefit? In order to support data retrieval **not only in infrastructure-based, always connected Internet**, but also in systems that can be infrequently connected (e.g., disaster environment, vehicular environments, some sensor networks, and many more example), you HAVE TO have the in-network discovery. There is simply no way it is possible to have an "oracle" that can tell you what is there. I think Tai Lin in one of the previous emails correctly noted that with immutable data packets, it is simply impossible to not have in-network discovery. The communication will not work otherwise without having an out-of-band channel to tell you what to fetch. What is the best way to achieve this is a completely different question. So it is impossible to run a discovery agent on each content store that runs a different discovery protocol than NDN?s in-network discovery? consumer interest: /foo/bar/_discovery_/(nonce1), payload = ?query = select * from CS where name like ?%superman.mov/h264/%/manifest? and keyid=0x1234 and expired=false? From content store: /foo/bar/_discovery_/(nonce1), payload = LINK /acme/5/_content_store_/ver=12/chunk=0 /acme/5/_content_store_/ver=12/chunk=0 payload = rowset { { /WarnerBros/1978/superman.mov/h264/rate1/manifest, hash 0x12777, keyid 0x884844 }, { /WarnerBros/1978/superman.mov/h264/rate3/manifest, hash 0xaaaaa, keyid 0xbbbbb }, } consumer interest: /acme/5/_content_store_/ver=12/chunk=1 Acme #5: more rowset consumer interest: /foo/bar/_discovery_/(nonce2), payload = ?exclude /acme/5, query = select * from CS where name like ?%superman.mov/h264/%/manifest? and keyid=0x1234 and expired=false? and so on?. And a note note. It is not LPM! It is fetching data with interests that don't have a full name (if needed with hash digest. --- Alex _______________________________________________ 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 Tue Mar 15 12:35:58 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Tue, 15 Mar 2016 19:35:58 +0000 Subject: [Ndn-interest] In-network name discovery -- Re: NDN protocol principles: no privacy? In-Reply-To: References: <0E38BD5B-8897-4CEF-B05D-02BD86F4948D@parc.com> <81413C5A-D761-47C6-B3B2-C38E57298026@cs.ucla.edu> Message-ID: In my example (just typed in email), I put the wrong keyid in the response rowsets. They should have equaled the keyid restriction in the select query. There should have also been an ?expired? column too for it to be proper sql. I?m not saying this is a great network protocol. It was just offered as a counter example to ?impossible." Marc On Mar 15, 2016, at 12:20 PM, Marc.Mosko at parc.com wrote: On Mar 15, 2016, at 10:58 AM, Alex Afanasyev > wrote: On Mar 15, 2016, at 10:43 AM, > > wrote: On 3/15/16, 9:11 AM, "Ndn-interest on behalf of Burke, Jeff" on behalf of jburke at remap.UCLA.edu> wrote: sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service. So in this case you are ok with requests to service names that reflect a plaintext prefix (/com/facebook) but have further components encrypted by ephemeral keys? What about cert or key names that may reflect your identity being requested by the service during authentication? If "in-network discovery" was used to find a sufficiently current version of the certs in the authentication phase of this scenario, would that be objectionable? Just trying to understand the limits here. You don?t have to expose names of keys or certs to intermediary nodes. You only need to expose that information to the parties you choose. Let me talk about "In-network discovery? for a second. [5] **In-Network Name Discovery**: Interests should be able use incomplete names to retrieve data packets. The first thing to say, is that in this phrasing, you mean the network layer, the forwarders, not the network as a whole. Today we do discovery in many ways. Whether it?s mDNS, DNS, a SQL query, a google/bing query or a piece of ajax code. Sometimes we do ping or trace route or god forbid snmp. (Did I mention routing protocols?) There are many ways to do ?discovery?. Because of the nature of NDN/CCN in naming everything, we have to do one extra step that other protocols don?t; the discovery of the name of a network packet. Many times this is not really discovery, it?s mostly like bootstrapping. We need to figure out where to start, and once we have that we can continue. These are all fine goals and problems to have. The way old CCN and NDN try to solve these is by having prefix matching on interests. The argument is that if the network-layer helps with this, then things will be better. I have yet to see a good argument of why this is the case. We?ve had this discussion a number of times. You can do everything the current LPM system can do if you create a simple service that lets you do LPM queries. Let?s call this service the Selector Service. Any node running a Selector Service can then process interests with selectors and generate replies. Any node running a Selector Service can also verify these replies if it wishes (under the same constraints as the current system). Any node NOT wishing to reveal what they have in their caches, or not wanting to waste the extra compute cycles may decide not to run that service. I would like to know what makes the built in LPM mode advantageous than the Selector Service method. I?m not saying that this Selector Service is what I would implement for discovery, but, there it is in case somebody wants it. LPM matching on interests throws a few wrenches in the system. Here are a few: - You never know what you?re going to get. You don?t know if the data you got is what you wanted. (how could you?, if you had known, you would have asked for it directly). Almost by definition, the only way for you to know if what you got is what you wanted is to ask again to get more information. Apparently in some solutions that use this system, you actually have calls that to succeed need to time out. - ?What?s in the network?? is fragile. People claim that you can do this in-network-layer discovery to find if one packet/piece of data (that I only partially know how to prefix-name) is in the connected network. For example, if the producer disconnected or if there is a network partition. This doesn?t really work without some very big participation from routing or by flooding the network. I?m not sure if it?s obvious to people how bad flooding the network is. The situations where this is considered advisable are very special. Why subject the world to this very special case that can lead to disaster? - LPM interests can be abused by malicious nodes. A malicious cache can reply with valid content in a way that creates extra traffic. I think sometimes there is a misunderstanding that exact matching means you must know everything in advance. This is not the case. It just means that I get to ask a specific question and somebody needs to stand up and answer it. Can we have a clear example of where the in-network-layer name discovery is required and provides a benefit? In order to support data retrieval **not only in infrastructure-based, always connected Internet**, but also in systems that can be infrequently connected (e.g., disaster environment, vehicular environments, some sensor networks, and many more example), you HAVE TO have the in-network discovery. There is simply no way it is possible to have an "oracle" that can tell you what is there. I think Tai Lin in one of the previous emails correctly noted that with immutable data packets, it is simply impossible to not have in-network discovery. The communication will not work otherwise without having an out-of-band channel to tell you what to fetch. What is the best way to achieve this is a completely different question. So it is impossible to run a discovery agent on each content store that runs a different discovery protocol than NDN?s in-network discovery? consumer interest: /foo/bar/_discovery_/(nonce1), payload = ?query = select * from CS where name like ?%superman.mov/h264/%/manifest? and keyid=0x1234 and expired=false? From content store: /foo/bar/_discovery_/(nonce1), payload = LINK /acme/5/_content_store_/ver=12/chunk=0 /acme/5/_content_store_/ver=12/chunk=0 payload = rowset { { /WarnerBros/1978/superman.mov/h264/rate1/manifest, hash 0x12777, keyid 0x884844 }, { /WarnerBros/1978/superman.mov/h264/rate3/manifest, hash 0xaaaaa, keyid 0xbbbbb }, } consumer interest: /acme/5/_content_store_/ver=12/chunk=1 Acme #5: more rowset consumer interest: /foo/bar/_discovery_/(nonce2), payload = ?exclude /acme/5, query = select * from CS where name like ?%superman.mov/h264/%/manifest? and keyid=0x1234 and expired=false? and so on?. And a note note. It is not LPM! It is fetching data with interests that don't have a full name (if needed with hash digest. --- Alex _______________________________________________ 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 mjs at cisco.com Tue Mar 15 13:18:55 2016 From: mjs at cisco.com (Mark Stapp) Date: Tue, 15 Mar 2016 16:18:55 -0400 Subject: [Ndn-interest] NDN protocol principles: no privacy? In-Reply-To: References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu> <56E58A40.9090704@cisco.com> <56E63911.7020605@ics.uci.edu> <56E6BA8C.6090703@cisco.com> <56E6E5F7.2070106@cisco.com> Message-ID: <56E86E2F.90107@cisco.com> > >> as long as user activity can be >> correlated readily, there's an exposure that seems to me to be >> undesireable - and it's unnecessary, given the technology that exists. >> the initial point I was trying to make was that it felt (to me) that >> there was a gap in the list of six because there was no mention of >> private communication. as I said in an earlier email, even having a >> broad statement would seem to be desireable. > > I tend to agree with Luca that I'm not sure this would be a > principle in the same sense as the others. BUT, I am also really interested in what might be "application-level" concepts or conventions that would be just as valuable. So, to me, whether or not it is in the design principle list doesn't exclude it from discussion or showing up in some other list. > I ... didn't really expect that the NDN folks would suddenly discover an interest in privacy, and add it to their list. [...] > > > > Some thoughts/questions off of the top of my head: > > - I'm not sure about the notion of a "default". It seems like it inevitably would devolve to discussion of how often one case versus another occurs, or the social cost of one case vs. the other, to determine what the default should be. I like the second articulation better for that reason, as a goal if not a principle, because it avoids both the language of "defaults" and specific mechanisms. > the point is that there is a default in NDN - it's currently "in-the-clear". that's no longer the best practice for network communication - "in-the-clear" makes users vulnerable, and that's entirely unnecessary given the technologies we have available. > - In the first articulation, can ephemeral be made more specific? > How long should a key be used? > ephemeral in these terms means negotiated using a diffie-hellman exchange - finite-field or elliptic-curve. it means, basically, random and uncorrelated with any party to the communication in any way. symmetric key lifetime - that's really a question for the cryptographers in the room? I suspect there's a guideline out there somewhere for number of seconds/number of bytes, given a symmetric key of a particular size. > - In your principle, would you object to using only the term confidentiality over privacy? Seems like this would make it sharper. If you would object, what does privacy cover that confidentiality doesn't, that can be achieved within a network architecture? > if I understand the way the security folks use the words, "confidential" has a fairly specific meaning: "keeping data secret from unintended listeners" (that's from RFC6973). That RFC spends most of its text talking about "privacy", though - which may include a constellation of properties, such as authentication, authorization, a range of adversaries and vulnerabilities. I think that broader constellation is what I mean by "privacy", because different users and applications will desire different tradeoffs among the complex of system and communication properties. > - Is it possible to articulate confidentiality (or privacy) of what from whom in such a goal/principle? My primary concern here is that current "best practice" includes some real limitations and assumptions (e.g., that once the bits hit the edge of the remote service, things are safe). > I ... don't think that's quite fair. First, many services now continue to use TLS internally, and of course many or most encrypt data at rest as well. I don't see how the NDN choice to communicate in the clear affects what happens inside the service. > Just riffing on the above two points - I don't find that > confidential communication with Facebook to actually do much for my personal privacy. I do want it to be confidential, but considering just the channel between my browser and the service is a red herring relative to bigger issues of privacy and data ownership. ok ... but you've made the choice to use a service that you know treats _you_ as a target. (I don't use it, fwiw.) at least the service can apply some access controls among its users, even if it is itself able to observe all of your fb activity. you're not saying you'd like to login to and use fb without TLS - right? you don't want someone sitting next to you learning your password, or gaining access to material that a stranger should not see? the are data ownership, regulatory, and policy issues out there, for sure. the use of crypto on the wire is really orthogonal to those - it's not a replacement for addressing them. our legal and regulatory systems have had a difficult time keeping up with the pace of change in some of these areas. but that's not a reason to want to expose your personal info in-flight, is it? and if you want to protect your info in-flight, there are technologies to do that and they're available - and they are the default for IP. > In fact, I would prefer that my postings are confidential from Facebook itself but not my "friends" in their social network - this is not really the current model of session-based security. I suspect that NDN can do better at that, revenue model of the service notwithstanding. (Here, I would like a goal or principles that goes beyond privacy and has to do with data ownership and control, which drives alternative service designs and reflects other rights, not just privacy.) > I ... don't know how to respond to that. You've chosen to use a service that's not entirely benign. again, that's really orthogonal to the techniques used to protect your communication on the internet (or not). I understand there's a lot of interest in p2p in NDN. I don't see it happening myself, but I'll be interested to see what happens. but I think it's a mistake to continue to reject the best-practice techniques for communication privacy, and I think it's a mistake to be left behind as the internet moves forward. Thanks, Mark From tailinchu at gmail.com Tue Mar 15 13:31:19 2016 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Tue, 15 Mar 2016 13:31:19 -0700 Subject: [Ndn-interest] Hop-by-Hop Flow Balance In-Reply-To: References: Message-ID: <23E57567-EDD4-48AC-B184-3A978153A100@gmail.com> > Not really. What you need is an ability to provoke a pull. Do people who want PUSH consider that it is possible to use interest as a notification to provoke a pull? (Producer sends an interest to consumer to say, ?hey, I have something for you, please fetch it.") > On Mar 15, 2016, at 9:55 AM, Dave Oran (oran) wrote: > >> >> On Mar 15, 2016, at 9:22 AM, Ravi Ravindran > wrote: >> >> Another primitive that is missing in NDN/CCN is the need to PUSH content, most of the IoT and social networking applications requires this primitive. > Not really. What you need is an ability to provoke a pull. > >> Today the solutions include using the long-lived interests or polling mechanisms which are not desirable, so if once such primitive is introduced this also questions the per-hop flow control objective. >> > Not really. On the other hand it does require more aggressive congestion control on the Interest transmission. > >> Regards, >> Ravi >> >> On Mon, Mar 14, 2016 at 4:09 PM, wrote: >> [ Disclaimer: CCN currently uses flow balance as well ] >> >> The current Hop-by-Hop Flow Balance is nonsense. >> >> >> >> >> >> On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" wrote: >>> [6] **Hop-by-Hop Flow Balance**: >>> Over each link, one interest packet should bring back no more than one data packet. >> >> Seriously, who thinks this actually works? >> >> Let me quote the webpage ( http://named-data.net/project/ndn-design-principles/ ): >> "[6] Hop-by-Hop Flow Balancing: Over each link, one interest packet should bring back no more than one data packet. >> Hop-by-hop flow balancing enables each node to control load over its links. By deciding to sending interest over a link, router commits bandwidth for the returned data. By limiting the number of interests sent, each router and client node in the network control how much data it will receive. >> " >> >> Either there is a lot of information missing here to justify why this is so, or this is very na?ve. >> >> First, if what you want to do is limit the number of content objects (or packets) returned, you don?t need to send one interest. _Specially_ for NDN, which has prefix matching, you could send one interest with a count number (10) and expect to receive 10 content objects back. There is no reason why I need to send 10 exact copies of the same interest. Even if the interests had small variations, why send 10? Why not send 1 + the 10 deltas? I guess it?s possible you may call that part of the ?network adaptation layer?, who knows. >> >> Also by requiring 1-to-1, you are always requiring an overhead (on the requester side) that is quite high. If you think of today?s type of networks, where a packet (internet sized) is around 1500 bytes, that means that even if we send interests of 30 bytes, we are incurring quite a bit of overhead in the upstream. This becomes considerable when doing high bandwidth video. >> >> Please explain why the 1-to-1 is good. >> >> Second, NDN allows very large packet sizes. So, when I send 1 interest, I don?t now if what I?m going to get back is 1 byte or 18 exabytes. How do routers use this information to control how much data they?re going to receive? Are they going to reserve 18 exabytes of traffic time? >> >> If this principle were to be re-written as: >> ?Allow network nodes to participate in flow control? then the actual engineering solution might be able to achieve this. >> >> Finally, at least we should acknowledge the limitations this type of approach requires; like symmetrical forwarding. >> >> It would be awkward if the only way for NDN to work over Satellite links would be to break the principles. >> >> Nacho >> >> >> PS. Yes, there are people in this community who have looked at other ways to do flow-balance and flow-control. Maybe we should be learning from those and not just claiming as principle what we do today because we don?t want it questioned. >> >> -- >> Nacho (Ignacio) Solis >> Protocol Architect >> Principal Scientist >> Palo Alto Research Center (PARC) >> +1(650)812-4458 >> Ignacio.Solis at parc.com >> >> _______________________________________________ >> 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 Tue Mar 15 14:22:04 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Tue, 15 Mar 2016 21:22:04 +0000 Subject: [Ndn-interest] Hop-by-Hop Flow Balance In-Reply-To: <23E57567-EDD4-48AC-B184-3A978153A100@gmail.com> References: <23E57567-EDD4-48AC-B184-3A978153A100@gmail.com> Message-ID: > On Mar 15, 2016, at 1:31 PM, Tai-Lin Chu wrote: > >> Not really. What you need is an ability to provoke a pull. > > Do people who want PUSH consider that it is possible to use interest as a notification to provoke a pull? > > (Producer sends an interest to consumer to say, ?hey, I have something for you, please fetch it.?) This technique requires each producer to be individually addressable and adds delay adds message overhead (4 messages instead of 2). In the start-write method, you have read request, read, read response, read request ack. I understand that often people do not do the read request ack, but I believe it is needed for correctness and liveness. For example, I send a read request to /foo to read /bar. Then I get an interest for /bar. After I return /bar, can I delete it? What if that Interest was from a 3rd party, not from /foo? What if my response to the Interest for /bar got lost? 0) A: interest to /B/foo to read /A/bar 1) B: interest to /A/bar 2) A: content object /A/bar 3) B: content object to /B/foo giving ACK that it read /A/bar Because 3 might be at an indeterminate delay from 0, PIT state is likely timed out. You probably need to actually do something like: 3?) B: interest to /A/bar/FIN with payload that confirms /B/foo read. You probably need to include a sequence number or something in the start-write Interest (0) that this can ACK. 4) A: delete /A/bar If you don?t have 3? (with some authentication), then you could have this situation: 0) A: interest to /B/foo to read /A/bar 1) C: interest to /A/bar 2) A: content object /A/bar 3) A: delete /A/bar 4) B: interest to /A/bar 5) A: NAK For small-size data, such as IoT, I think it is better to put the data in the Interest and use the Data object as a ACK. Marc From tailinchu at gmail.com Tue Mar 15 18:58:08 2016 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Tue, 15 Mar 2016 18:58:08 -0700 Subject: [Ndn-interest] In-network name discovery -- Re: NDN protocol principles: no privacy? In-Reply-To: <4413371A-6849-487B-9C51-8DF3051B41E3@cisco.com> References: <0E38BD5B-8897-4CEF-B05D-02BD86F4948D@parc.com> <81413C5A-D761-47C6-B3B2-C38E57298026@cs.ucla.edu> <4413371A-6849-487B-9C51-8DF3051B41E3@cisco.com> Message-ID: <27B32EE6-8CA8-4EDC-A099-0AA74B1A9D75@gmail.com> >> And a note note. It is not LPM! This is a serious mistake from me. I apologize to everyone that is confused by it. > If so, I don?t understand how you can design a non-terminating search algorithm unless you allow unbounded exclusion sets Could you explain more? > The requirement for in-network discovery is in fact neither necessary NOR sufficient. If the network nodes that are doing this magic in fact have very small caches, or no caches at all (think a mesh sensor network with no large-memory nodes) I acknowledge your point that in-network discovery is not necessary. However, I want to know about how one implements out-of-network discovery, and how this out-of-network discovery mechanism differs from ndn?s tree-based mechanism. Like I said, I think discovery protocol is very important to ndn (either in- or out-of-network). If we rely on some out-of-network service, and NDN becomes limited without it, we should probably remove ?universality? as one of the principles because: 1. we now need TWO or more protocols (need to include this discovery protocol, and perhaps many other supporting protocols) not one common protocol. In addition, a device needs to consider what kind of discovery protocol is available. 2. it needs some infrastructure communication for discovery. This really devalues NDN. Although I am not a big fan of the current in-network discovery, I think it is wiser to improve it instead of removing it. > On Mar 15, 2016, at 12:11 PM, Dave Oran (oran) wrote: > > >> On Mar 15, 2016, at 10:58 AM, Alex Afanasyev wrote: >> >>> >>> On Mar 15, 2016, at 10:43 AM, wrote: >>> >>> On 3/15/16, 9:11 AM, "Ndn-interest on behalf of Burke, Jeff" wrote: >>> > [SNIP] > >>> Can we have a clear example of where the in-network-layer name discovery is required and provides a benefit? >> >> In order to support data retrieval **not only in infrastructure-based, always connected Internet**, but also in systems that can be infrequently connected (e.g., disaster environment, vehicular environments, some sensor networks, and many more example), you HAVE TO have the in-network discovery. There is simply no way it is possible to have an "oracle" that can tell you what is there. >> > I disagree. > The requirement is that within any partition of the network that needs to operate autonomously, there has to be a service instance that can answer bootstrapping/discovery queries. The requirement for in-network discovery is in fact neither necessary NOR sufficient. If the network nodes that are doing this magic in fact have very small caches, or no caches at all (think a mesh sensor network with no large-memory nodes) then in-network discover mechanisms will fail. Further, if in order to obtain an useful bootstrapping data you have to flood rather than route to a discovery service, there are some obvious scalability and DDoS concerns. > >> I think Tai Lin in one of the previous emails correctly noted that with immutable data packets, it is simply impossible to not have in-network discovery. > We need a crisp definition of an ?immutable data packet? to continue this discussion productively. If the only immutable property is on hash-based names and you ONLY can request data by hash-name, then you have only immutable packets. On the other hand, if you can have different packets, with different hashes, that bind the same name (minus the hash) to different data, the useful application-meaningful data is not immutable. It?s also important to add time to the semantics here, such that applications may operatie correctly if and only if there is only one *unexpired* packet with a given name emitted by a publisher in a given expiration period. > >> The communication will not work otherwise without having an out-of-band channel to tell you what to fetch. What is the best way to achieve this is a completely different question. >> >> And a note note. It is not LPM! It is fetching data with interests that don't have a full name (if needed with hash digest. > Actually, this is an interesting point. Are you saying you can return *ANY* prefix match? If so, I don?t understand how you can design a non-terminating search algorithm unless you allow unbounded exclusion sets (which might be needed in practice even *with* LPM). > > >> >> --- >> Alex >> >> _______________________________________________ >> 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 oran at cisco.com Wed Mar 16 10:16:00 2016 From: oran at cisco.com (Dave Oran (oran)) Date: Wed, 16 Mar 2016 17:16:00 +0000 Subject: [Ndn-interest] In-network name discovery -- Re: NDN protocol principles: no privacy? In-Reply-To: <27B32EE6-8CA8-4EDC-A099-0AA74B1A9D75@gmail.com> References: <0E38BD5B-8897-4CEF-B05D-02BD86F4948D@parc.com> <81413C5A-D761-47C6-B3B2-C38E57298026@cs.ucla.edu> <4413371A-6849-487B-9C51-8DF3051B41E3@cisco.com> <27B32EE6-8CA8-4EDC-A099-0AA74B1A9D75@gmail.com> Message-ID: <6F9BAEED-487E-4BBD-8434-C9E6E3D1479F@cisco.com> > On Mar 15, 2016, at 6:58 PM, Tai-Lin Chu wrote: > >>> And a note note. It is not LPM! > > > This is a serious mistake from me. I apologize to everyone that is confused by it. > >> If so, I don?t understand how you can design a non-terminating search algorithm unless you allow unbounded exclusion sets > > Could you explain more? > Sure. Without some deterministic globally-agreed matching algorithm, each subsequent request for a name could return something longer or shorter and the only way to converge onto a useful name that can be used to aglrothmically construct the name you are looking for is to either: a) keep adding exclusions until every possible name in existence in the tree above the desired name is excluded, leaving only the one you really want, or b) ensure that any name which is a prefix of another name in fact resolves to a manifest or other data structure that enumerates the names underneath, so you can explicitly traverse the hierarchy. If you can do (b), then you can effectively take the DNS approach of popping up to the root and navigating from there. But NDN does not mandate that (b) always works. >> The requirement for in-network discovery is in fact neither necessary NOR sufficient. If the network nodes that are doing this magic in fact have very small caches, or no caches at all (think a mesh sensor network with no large-memory nodes) > > I acknowledge your point that in-network discovery is not necessary. However, I want to know about how one implements out-of-network discovery, and how this out-of-network discovery mechanism differs from ndn?s tree-based mechanism. > Mark Mosko gave one example. My (b) above is another (albeit inefficient). There?s another consideration which also pushes one to having discovery services - application root of trust. It doesn?t do you any good to get able to pull random stuff out of router caches unless you can also pull out the necessary keying material to check the authenticity of the data. That means an application needs to have at least one built-in name and associated trust assertion to start navigating from: the name of the root of trust. If you can do that I would argue that the manifest tree approach to discovery can do everything else - the only thing you need a discovery service to hold in each network partition is the names and associated objects of each application root of trust that is in use in that network partition. Of course if the network is not partitioned, you can always get to the authoritative publisher of these objects, in which case in-network discovery is just an optimization like other forms of caching. > Like I said, I think discovery protocol is very important to ndn (either in- or out-of-network). If we rely on some out-of-network service, and NDN becomes limited without it, we should probably remove ?universality? as one of the principles because: > > 1. we now need TWO or more protocols (need to include this discovery protocol, and perhaps many other supporting protocols) not one common protocol. In addition, a device needs to consider what kind of discovery protocol is available. We need at least one upper level protocol on top of NDN to deal with trust schemas and keying. > 2. it needs some infrastructure communication for discovery. Which can be layered on NDN L3 just fine, so it doesn?t require some alternative L3 protocol. > > This really devalues NDN. > I disagree. While this is a highly imperfect analogy, the fact that IP today does not work in any practically useful way without DNS, I think it?s just fine for NDN (or CCN) to not work without a universally available discovery protocol built on top. From a implementation efficiency and simplicity point of view, if a very small volume of the communications need the discovery features, we can avoid some very expensive mechanisms in the forwarding path of the NDN routers. > Although I am not a big fan of the current in-network discovery, I think it is wiser to improve it instead of removing it. If we can find a way to improve it to the point it doesn?t add substantial complexity and performance problems, I?m all ears. DaveO. > > > > >> On Mar 15, 2016, at 12:11 PM, Dave Oran (oran) wrote: >> >> >>> On Mar 15, 2016, at 10:58 AM, Alex Afanasyev wrote: >>> >>>> >>>> On Mar 15, 2016, at 10:43 AM, wrote: >>>> >>>> On 3/15/16, 9:11 AM, "Ndn-interest on behalf of Burke, Jeff" wrote: >>>> >> [SNIP] >> >>>> Can we have a clear example of where the in-network-layer name discovery is required and provides a benefit? >>> >>> In order to support data retrieval **not only in infrastructure-based, always connected Internet**, but also in systems that can be infrequently connected (e.g., disaster environment, vehicular environments, some sensor networks, and many more example), you HAVE TO have the in-network discovery. There is simply no way it is possible to have an "oracle" that can tell you what is there. >>> >> I disagree. >> The requirement is that within any partition of the network that needs to operate autonomously, there has to be a service instance that can answer bootstrapping/discovery queries. The requirement for in-network discovery is in fact neither necessary NOR sufficient. If the network nodes that are doing this magic in fact have very small caches, or no caches at all (think a mesh sensor network with no large-memory nodes) then in-network discover mechanisms will fail. Further, if in order to obtain an useful bootstrapping data you have to flood rather than route to a discovery service, there are some obvious scalability and DDoS concerns. >> >>> I think Tai Lin in one of the previous emails correctly noted that with immutable data packets, it is simply impossible to not have in-network discovery. >> We need a crisp definition of an ?immutable data packet? to continue this discussion productively. If the only immutable property is on hash-based names and you ONLY can request data by hash-name, then you have only immutable packets. On the other hand, if you can have different packets, with different hashes, that bind the same name (minus the hash) to different data, the useful application-meaningful data is not immutable. It?s also important to add time to the semantics here, such that applications may operatie correctly if and only if there is only one *unexpired* packet with a given name emitted by a publisher in a given expiration period. >> >>> The communication will not work otherwise without having an out-of-band channel to tell you what to fetch. What is the best way to achieve this is a completely different question. >>> >>> And a note note. It is not LPM! It is fetching data with interests that don't have a full name (if needed with hash digest. >> Actually, this is an interesting point. Are you saying you can return *ANY* prefix match? If so, I don?t understand how you can design a non-terminating search algorithm unless you allow unbounded exclusion sets (which might be needed in practice even *with* LPM). >> >> >>> >>> --- >>> Alex >>> >>> _______________________________________________ >>> 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 g.white at cablelabs.com Wed Mar 16 11:02:41 2016 From: g.white at cablelabs.com (Greg White) Date: Wed, 16 Mar 2016 18:02:41 +0000 Subject: [Ndn-interest] Hop-by-Hop Flow Balance In-Reply-To: References: <23E57567-EDD4-48AC-B184-3A978153A100@gmail.com> Message-ID: <6A80331C-3178-4459-A41E-0AF9922378F9@cablelabs.com> On 3/15/16, 3:22 PM, "Ndn-interest on behalf of Marc.Mosko at parc.com" wrote: > >For small-size data, such as IoT, I think it is better to put the data in the Interest and use the Data object as a ACK. And with fragmentation support, ?small-size? could be large. :) For IoT applications, this method seems far superior to the alternative. Minimizing the need for IoT devices to publish routable names seems like a good idea from the perspective of routing scalability. Since the Interest can be signed by the producer (in CCN at least, I assume the same is true in NDN), it seems the only thing it lacks is the possibility for data to be cached in-network. Furthermore, the Data object (ACK) could provide a next-name that is unique to the receiver to allow stateful communication if needed. From oran at cisco.com Wed Mar 16 11:12:54 2016 From: oran at cisco.com (Dave Oran (oran)) Date: Wed, 16 Mar 2016 18:12:54 +0000 Subject: [Ndn-interest] Hop-by-Hop Flow Balance In-Reply-To: <6A80331C-3178-4459-A41E-0AF9922378F9@cablelabs.com> References: <23E57567-EDD4-48AC-B184-3A978153A100@gmail.com> <6A80331C-3178-4459-A41E-0AF9922378F9@cablelabs.com> Message-ID: > On Mar 16, 2016, at 11:02 AM, Greg White wrote: > > On 3/15/16, 3:22 PM, "Ndn-interest on behalf of Marc.Mosko at parc.com" wrote: > > >> >> For small-size data, such as IoT, I think it is better to put the data in the Interest and use the Data object as a ACK. > > > And with fragmentation support, ?small-size? could be large. :) > > For IoT applications, this method seems far superior to the alternative. Minimizing the need for IoT devices to publish routable names seems like a good idea from the perspective of routing scalability. > I agree, although this is easily avoidable with an Interest-Interest-Data paradigm. For another example of how this might work see the Web Paradigms paper from last year?s ICN conference. > Since the Interest can be signed by the producer (in CCN at least, I assume the same is true in NDN), it seems the only thing it lacks is the possibility for data to be cached in-network. > ?and encrypted?so you can?t just launch stuff; you need to get some symmetric (possibly shared) keys in place. > Furthermore, the Data object (ACK) could provide a next-name that is unique to the receiver to allow stateful communication if needed. True, but devices that just want to squark stuff all not all that likely to want to keep per-receiver state. > > > > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From tailinchu at gmail.com Wed Mar 16 23:08:30 2016 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Wed, 16 Mar 2016 23:08:30 -0700 Subject: [Ndn-interest] In-network name discovery -- Re: NDN protocol principles: no privacy? In-Reply-To: <6F9BAEED-487E-4BBD-8434-C9E6E3D1479F@cisco.com> References: <0E38BD5B-8897-4CEF-B05D-02BD86F4948D@parc.com> <81413C5A-D761-47C6-B3B2-C38E57298026@cs.ucla.edu> <4413371A-6849-487B-9C51-8DF3051B41E3@cisco.com> <27B32EE6-8CA8-4EDC-A099-0AA74B1A9D75@gmail.com> <6F9BAEED-487E-4BBD-8434-C9E6E3D1479F@cisco.com> Message-ID: <65F38985-D822-472F-B0B6-1593431F7499@gmail.com> > Without some deterministic globally-agreed matching algorithm, each subsequent request for a name could return something longer or shorter and the only way to converge onto a useful name If you already think of a name, I agree that ndn current in-network discovery will not be useful to find the same one. But I don?t understand why you try to do it; the point of discovery service is to discover unknown names. It is fine as long as the data packet returned satisfies the interest. I don?t think it is the case that I will never know what I will get; it just means I did not specify the right constraints. > While this is a highly imperfect analogy, the fact that IP today does not work in any practically useful way without DNS, I think it?s just fine for NDN (or CCN) to not work without a universally available discovery protocol built on top. From a implementation efficiency and simplicity point of view, if a very small volume of the communications need the discovery features, we can avoid some very expensive mechanisms in the forwarding path of the NDN routers. I am also satisfied if this results in efficiency and simplicity from ?application" point of view (no alternative l3 protocol, and faster discovery process). It is also important that there will be one common discovery protocol (DNS analogy). > On Mar 16, 2016, at 10:16 AM, Dave Oran (oran) wrote: > > >> On Mar 15, 2016, at 6:58 PM, Tai-Lin Chu wrote: >> >>>> And a note note. It is not LPM! >> >> >> This is a serious mistake from me. I apologize to everyone that is confused by it. >> >>> If so, I don?t understand how you can design a non-terminating search algorithm unless you allow unbounded exclusion sets >> >> Could you explain more? >> > Sure. Without some deterministic globally-agreed matching algorithm, each subsequent request for a name could return something longer or shorter and the only way to converge onto a useful name that can be used to aglrothmically construct the name you are looking for is to either: > a) keep adding exclusions until every possible name in existence in the tree above the desired name is excluded, leaving only the one you really want, or > b) ensure that any name which is a prefix of another name in fact resolves to a manifest or other data structure that enumerates the names underneath, so you can explicitly traverse the hierarchy. > > If you can do (b), then you can effectively take the DNS approach of popping up to the root and navigating from there. > > But NDN does not mandate that (b) always works. > >>> The requirement for in-network discovery is in fact neither necessary NOR sufficient. If the network nodes that are doing this magic in fact have very small caches, or no caches at all (think a mesh sensor network with no large-memory nodes) >> >> I acknowledge your point that in-network discovery is not necessary. However, I want to know about how one implements out-of-network discovery, and how this out-of-network discovery mechanism differs from ndn?s tree-based mechanism. >> > Mark Mosko gave one example. My (b) above is another (albeit inefficient). There?s another consideration which also pushes one to having discovery services - application root of trust. It doesn?t do you any good to get able to pull random stuff out of router caches unless you can also pull out the necessary keying material to check the authenticity of the data. That means an application needs to have at least one built-in name and associated trust assertion to start navigating from: the name of the root of trust. If you can do that I would argue that the manifest tree approach to discovery can do everything else - the only thing you need a discovery service to hold in each network partition is the names and associated objects of each application root of trust that is in use in that network partition. Of course if the network is not partitioned, you can always get to the authoritative publisher of these objects, in which case in-network discovery is just an optimization like other forms of caching. > >> Like I said, I think discovery protocol is very important to ndn (either in- or out-of-network). If we rely on some out-of-network service, and NDN becomes limited without it, we should probably remove ?universality? as one of the principles because: >> >> 1. we now need TWO or more protocols (need to include this discovery protocol, and perhaps many other supporting protocols) not one common protocol. In addition, a device needs to consider what kind of discovery protocol is available. > We need at least one upper level protocol on top of NDN to deal with trust schemas and keying. > >> 2. it needs some infrastructure communication for discovery. > Which can be layered on NDN L3 just fine, so it doesn?t require some alternative L3 protocol. > >> >> This really devalues NDN. >> > I disagree. While this is a highly imperfect analogy, the fact that IP today does not work in any practically useful way without DNS, I think it?s just fine for NDN (or CCN) to not work without a universally available discovery protocol built on top. From a implementation efficiency and simplicity point of view, if a very small volume of the communications need the discovery features, we can avoid some very expensive mechanisms in the forwarding path of the NDN routers. > >> Although I am not a big fan of the current in-network discovery, I think it is wiser to improve it instead of removing it. > If we can find a way to improve it to the point it doesn?t add substantial complexity and performance problems, I?m all ears. > > DaveO. > >> >> >> >> >>> On Mar 15, 2016, at 12:11 PM, Dave Oran (oran) wrote: >>> >>> >>>> On Mar 15, 2016, at 10:58 AM, Alex Afanasyev wrote: >>>> >>>>> >>>>> On Mar 15, 2016, at 10:43 AM, wrote: >>>>> >>>>> On 3/15/16, 9:11 AM, "Ndn-interest on behalf of Burke, Jeff" wrote: >>>>> >>> [SNIP] >>> >>>>> Can we have a clear example of where the in-network-layer name discovery is required and provides a benefit? >>>> >>>> In order to support data retrieval **not only in infrastructure-based, always connected Internet**, but also in systems that can be infrequently connected (e.g., disaster environment, vehicular environments, some sensor networks, and many more example), you HAVE TO have the in-network discovery. There is simply no way it is possible to have an "oracle" that can tell you what is there. >>>> >>> I disagree. >>> The requirement is that within any partition of the network that needs to operate autonomously, there has to be a service instance that can answer bootstrapping/discovery queries. The requirement for in-network discovery is in fact neither necessary NOR sufficient. If the network nodes that are doing this magic in fact have very small caches, or no caches at all (think a mesh sensor network with no large-memory nodes) then in-network discover mechanisms will fail. Further, if in order to obtain an useful bootstrapping data you have to flood rather than route to a discovery service, there are some obvious scalability and DDoS concerns. >>> >>>> I think Tai Lin in one of the previous emails correctly noted that with immutable data packets, it is simply impossible to not have in-network discovery. >>> We need a crisp definition of an ?immutable data packet? to continue this discussion productively. If the only immutable property is on hash-based names and you ONLY can request data by hash-name, then you have only immutable packets. On the other hand, if you can have different packets, with different hashes, that bind the same name (minus the hash) to different data, the useful application-meaningful data is not immutable. It?s also important to add time to the semantics here, such that applications may operatie correctly if and only if there is only one *unexpired* packet with a given name emitted by a publisher in a given expiration period. >>> >>>> The communication will not work otherwise without having an out-of-band channel to tell you what to fetch. What is the best way to achieve this is a completely different question. >>>> >>>> And a note note. It is not LPM! It is fetching data with interests that don't have a full name (if needed with hash digest. >>> Actually, this is an interesting point. Are you saying you can return *ANY* prefix match? If so, I don?t understand how you can design a non-terminating search algorithm unless you allow unbounded exclusion sets (which might be needed in practice even *with* LPM). >>> >>> >>>> >>>> --- >>>> Alex >>>> >>>> _______________________________________________ >>>> 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 Ignacio.Solis at parc.com Thu Mar 17 09:07:58 2016 From: Ignacio.Solis at parc.com (Ignacio.Solis at parc.com) Date: Thu, 17 Mar 2016 16:07:58 +0000 Subject: [Ndn-interest] In-network name discovery -- Re: NDN protocol principles: no privacy? In-Reply-To: <65F38985-D822-472F-B0B6-1593431F7499@gmail.com> References: <0E38BD5B-8897-4CEF-B05D-02BD86F4948D@parc.com> <81413C5A-D761-47C6-B3B2-C38E57298026@cs.ucla.edu> <4413371A-6849-487B-9C51-8DF3051B41E3@cisco.com> <27B32EE6-8CA8-4EDC-A099-0AA74B1A9D75@gmail.com> <6F9BAEED-487E-4BBD-8434-C9E6E3D1479F@cisco.com> <65F38985-D822-472F-B0B6-1593431F7499@gmail.com> Message-ID: On 3/16/16, 11:08 PM, "Tai-Lin Chu" wrote: >> Without some deterministic globally-agreed matching algorithm, each subsequent request for a name could return something longer or shorter and the only way to converge onto a useful name > >If you already think of a name, I agree that ndn current in-network discovery will not be useful to find the same one. But I don?t understand why you try to do it; the point of discovery service is to discover unknown names. It is fine as long as the data packet returned satisfies the interest. I don?t think it is the case that I will never know what I will get; it just means I did not specify the right constraints. If you don?t have enough information (constraints or not) to specify what you want, what makes you think that the network is going to know or get the right thing? It seems to me all you are doing is exploring the network, randomly walking a graph. >> While this is a highly imperfect analogy, the fact that IP today does not work in any practically useful way without DNS, I think it?s just fine for NDN (or CCN) to not work without a universally available discovery protocol built on top. From a implementation efficiency and simplicity point of view, if a very small volume of the communications need the discovery features, we can avoid some very expensive mechanisms in the forwarding path of the NDN routers. > >I am also satisfied if this results in efficiency and simplicity from ?application" point of view (no alternative l3 protocol, and faster discovery process). It is also important that there will be one common discovery protocol (DNS analogy). Nobody is proposing an alternative layer 3 protocol. We are proposing to have a separate discovery protocol that is not built into layer 3. The single discovery protocol is not as important as you think. We have many layers, applications, services and uses and they all have different mechanisms for discovery. Discovering the peers in the network attached to a shared channel is different than discovering the available virtual machine instances ready to run a task. Or where you talking about a single discovery protocol at a specific layer? The discovery protocol in an ad-hoc mobile network can be much different than of a centralized datacenter. I don?t rule a single protocol out, but I?m not ready to claim that is the solution. Nacho From Marc.Mosko at parc.com Fri Mar 18 14:57:21 2016 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Fri, 18 Mar 2016 21:57:21 +0000 Subject: [Ndn-interest] Hop-by-Hop Flow Balance In-Reply-To: <6A80331C-3178-4459-A41E-0AF9922378F9@cablelabs.com> References: <23E57567-EDD4-48AC-B184-3A978153A100@gmail.com> <6A80331C-3178-4459-A41E-0AF9922378F9@cablelabs.com> Message-ID: > On Mar 16, 2016, at 11:02 AM, Greg White wrote: > > On 3/15/16, 3:22 PM, "Ndn-interest on behalf of Marc.Mosko at parc.com" wrote: > > >> >> For small-size data, such as IoT, I think it is better to put the data in the Interest and use the Data object as a ACK. > > > And with fragmentation support, ?small-size? could be large. :) > > For IoT applications, this method seems far superior to the alternative. Minimizing the need for IoT devices to publish routable names seems like a good idea from the perspective of routing scalability. > > Since the Interest can be signed by the producer (in CCN at least, I assume the same is true in NDN), it seems the only thing it lacks is the possibility for data to be cached in-network. An Interest can be signed in both NDN and CCN, though the mechanisms differ. NDN adopted the method from CCNx 0.x where the consumer puts data in the name and signs the name. They also wrote a few tech reports on this quite a while ago related to controlling stage lighting and building management, if I remember correctly. That said one still needs keys for the signature (and encryption). The CCNx key exchange, which PARC presented at IETF last time and we?ll have an update this IETF too, is consumer driven and does not require named consumers. So, it could be executed by an IoT device to get shared secrets with a gateway. It allows bi-directional authentication using public key crypto, though that authentication could be extended to any of the EAP methods (like shared passwords or secrets) if that is better for IoT devices. > > Furthermore, the Data object (ACK) could provide a next-name that is unique to the receiver to allow stateful communication if needed. Yes, I did not get into details on how one could ACK, but clearly one could use any of the current technology of SACKs, cumulative ACKs, etc., and do not need to do stop-and-wait. Similarly to signing Interets, it would be good to have shared symmetric keys for signing (and encrypting) the ACKs. > > > > > From aa at CS.UCLA.EDU Fri Mar 25 15:49:21 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Fri, 25 Mar 2016 15:49:21 -0700 Subject: [Ndn-interest] NFD version 0.4.1 release Message-ID: <0D9BEB85-4A1A-4A57-83F5-A0B0E70FDC0D@cs.ucla.edu> Dear all, We are also pleased to announce the release of version 0.4.1 of Named Data Networking Forwarding Daemon (NFD). The detailed notes for the release: http://named-data.net/doc/NFD/0.4.1/RELEASE_NOTES.html Source code, instruction how to install NFD on Ubuntu Linux (12.04, 14.04, and 15.10) and OS X (10.9, 10.10, 10.11), tutorials, HOWTOs, a FAQ and other useful resources are available on the official NFD website: http://named-data.net/doc/NFD/0.4.1/ * * * Other related updates: - ndn-cxx library to version 0.4.1 http://named-data.net/doc/ndn-cxx/0.4.1/RELEASE_NOTES.html - NFD Developer's Guide to revision 6: http://named-data.net/publications/techreports/ndn-0021-6-nfd-developer-guide/ - NDN Essential Tools to version 0.3: https://github.com/named-data/ndn-tools * * * A special welcome to new contributors: Susmit Shannigrahi, Jos? Quevedo, Weiwei Liu, Spencer Lee. * * * The NDN/NFD Team: Alexander Afanasyev, Junxiao Shi, Beichuan Zhang, Lixia Zhang, Ilya Moiseenko, Yingdi Yu, Wentao Shang, Yanbiao Li, Spyridon Mastorakis, Yi Huang, Jerald Paul Abraham, Steve DiBenedetto, Chengyu Fan, Christos Papadopoulos, Davide Pesavento, Giulio Grassi, Giovanni Pau, Hang Zhang, Tian Song, Haowei Yuan, Hila Ben Abraham, Patrick Crowley, Syed Obaid Amin, Vince Lehman, Lan Wang, Eric Newberry, Yukai Tu, Muktadir Chowdhury, and others (http://named-data.net/project/participants/) -------------- 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 tnsr.chatterjee at gmail.com Wed Mar 30 02:20:59 2016 From: tnsr.chatterjee at gmail.com (Tanusree Chatterjee) Date: Wed, 30 Mar 2016 14:50:59 +0530 Subject: [Ndn-interest] Difficulty in running NDNsim with pythod visualizer Message-ID: Hello, I have successfully installed and compiled and run NDNsim in my machine. But whenever, I want to see the simulation live with the command *./waf --run= --vis*, it shows the following error. *assert failed. cond="uid != 0", msg="Assert in TypeId::LookupByName: ns3::VisualSimulatorImpl not found", file=../src/core/model/type-id.cc, line=755terminate called without an active exception* Command ['/home/tanusree/boost_1_59_0/ndnSIM/ns-3/build/src/ndnSIM/examples/ns3-dev-ndn-simple-debug', '--SimulatorImplementationType=ns3::VisualSimulatorImpl'] terminated with signal SIGIOT. Run it under a debugger to get more information (./waf --run --command-template="gdb --args %s "). Previously it has shown that the Python Visualizer wan not enabled. Please tell me how can I run the examples with visualizer. --Regards, Tanusree Chatterjee -------------- next part -------------- An HTML attachment was scrubbed... URL: From Navdeep.Uniyal at neclab.eu Wed Mar 30 05:42:11 2016 From: Navdeep.Uniyal at neclab.eu (Navdeep Uniyal) Date: Wed, 30 Mar 2016 12:42:11 +0000 Subject: [Ndn-interest] Data not received from NDN traffic generator Message-ID: <15421E67B274CD4AB5F6AEA46A684C3708AB280C@PALLENE.office.hd> Hi All, I am facing an issue. In my setup I am using a simple topology with one client, one server and with 3 different paths having one intermediate host on each path. All the generated interests are not getting satisfied while using best-route strategy. As per logs I can see, after satisfying a few interests, the server(NDN traffic generator) is not responding to the further requests and only the ones at CS store are getting satisfied. I am unable to find the reason for such a behavior. Although the number of interests generated are 2500 and there is no limit on max number of interests the traffic generator can satisfy ( although I also tried with max limit of 20000 interests). Attached are the NFD logs for the server generating data. Please, if someone can help in this regard. Regards, Navdeep Uniyal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: server.log.log Type: application/octet-stream Size: 4464980 bytes Desc: server.log.log URL: From chaim.rieger at gmail.com Wed Mar 30 09:54:02 2016 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Wed, 30 Mar 2016 09:54:02 -0700 Subject: [Ndn-interest] Difficulty in running NDNsim with pythod visualizer In-Reply-To: References: Message-ID: <56FC04AA.4030405@gmail.com> Did you install the prerequisites ? On 3/30/2016 2:20 AM, Tanusree Chatterjee wrote: > Hello, > > I have successfully installed and compiled and run NDNsim in my > machine. But whenever, I want to see the simulation live with the > command *./waf --run= --vis*, it shows the following error. > > *assert failed. cond="uid != 0", msg="Assert in TypeId::LookupByName: > ns3::VisualSimulatorImpl not found", > file=../src/core/model/type-id.cc, line=755 > terminate called without an active exception* > > Command > ['/home/tanusree/boost_1_59_0/ndnSIM/ns-3/build/src/ndnSIM/examples/ns3-dev-ndn-simple-debug', > '--SimulatorImplementationType=ns3::VisualSimulatorImpl'] terminated > with signal SIGIOT. Run it under a debugger to get more information > (./waf --run --command-template="gdb --args %s "). > > > Previously it has shown that the Python Visualizer wan not enabled. > Please tell me how can I run the examples with visualizer. > > --Regards, > Tanusree Chatterjee > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Mar 30 10:31:25 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 30 Mar 2016 10:31:25 -0700 Subject: [Ndn-interest] Data not received from NDN traffic generator In-Reply-To: <15421E67B274CD4AB5F6AEA46A684C3708AB280C@PALLENE.office.hd> References: <15421E67B274CD4AB5F6AEA46A684C3708AB280C@PALLENE.office.hd> Message-ID: Hi Navdeep I'm looking at the last few lines of the log file. It appears that there's some loop going on in the network. It's particularly strange that face 262 receives an Interest with duplicate Nonce within 0.2ms of sending it. InterestLifetime is set to 200ms, but the producer spends 500ms to generate Data. A longer InterestLifetime is needed; the consumer needs to send Interests at a slower rate; the producer needs to generate Data faster (eg. set digest signing instead of RSA). Also, you mentioned there are 2500 Interests, but I only see a small number of distinct names. 1459335670.181340 DEBUG: [Forwarder] onIncomingInterest face=258 interest=/ndn/nle/file3 1459335670.181630 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/nle/file3 1459335670.181672 DEBUG: [Forwarder] onOutgoingInterest face=262 interest=/ndn/nle/file3 1459335670.181898 DEBUG: [Forwarder] onIncomingInterest face=262 interest=/ndn/nle/file3 1459335670.182178 DEBUG: [Forwarder] onInterestLoop face=262 interest=/ndn/nle/file3 1459335670.201832 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file5 1459335670.201911 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file5 unsatisfied 1459335670.231633 DEBUG: [Forwarder] onIncomingInterest face=259 interest=/ndn/nle/file5 1459335670.231972 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/nle/file5 1459335670.232011 DEBUG: [Forwarder] onOutgoingInterest face=263 interest=/ndn/nle/file5 1459335670.271813 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file1 1459335670.271889 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file1 unsatisfied 1459335670.281172 DEBUG: [Forwarder] onIncomingInterest face=259 interest=/ndn/nle/file1 1459335670.281512 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/nle/file1 1459335670.281551 DEBUG: [Forwarder] onOutgoingInterest face=263 interest=/ndn/nle/file1 1459335670.381690 DEBUG: [Forwarder] onIncomingInterest face=259 interest=/ndn/nle/file7 1459335670.382148 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/nle/file7 1459335670.382193 DEBUG: [Forwarder] onOutgoingData face=259 data=/ndn/nle/file7 1459335670.382362 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file3 1459335670.382447 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file3 unsatisfied 1459335670.432216 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file5 1459335670.432315 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file5 unsatisfied 1459335670.481765 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file1 1459335670.481840 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file1 unsatisfied 1459335670.482383 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file7 satisfied 1459335685.781128 DEBUG: [Forwarder] onIncomingData face=263 data=/ndn/nle/file3 1459335685.781423 DEBUG: [Forwarder] onDataUnsolicited face=263 data=/ndn/nle/file3 cached 1459335685.782137 DEBUG: [Forwarder] onIncomingData face=263 data=/ndn/nle/file1 1459335685.782378 DEBUG: [Forwarder] onDataUnsolicited face=263 data=/ndn/nle/file1 cached Yours, Junxiao On Wed, Mar 30, 2016 at 5:42 AM, Navdeep Uniyal wrote: > Hi All, > > > > I am facing an issue. In my setup I am using a simple topology with one > client, one server and with 3 different paths having one intermediate host > on each path. All the generated interests are not getting satisfied while > using best-route strategy. As per logs I can see, after satisfying a few > interests, the server(NDN traffic generator) is not responding to the > further requests and only the ones at CS store are getting satisfied. I am > unable to find the reason for such a behavior. Although the number of > interests generated are 2500 and there is no limit on max number of > interests the traffic generator can satisfy ( although I also tried with > max limit of 20000 interests). Attached are the NFD logs for the server > generating data. Please, if someone can help in this regard. > > > > > > > > Regards, > > Navdeep Uniyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Navdeep.Uniyal at neclab.eu Thu Mar 31 04:24:29 2016 From: Navdeep.Uniyal at neclab.eu (Navdeep Uniyal) Date: Thu, 31 Mar 2016 11:24:29 +0000 Subject: [Ndn-interest] error while compiling the forwarding startegy Message-ID: <15421E67B274CD4AB5F6AEA46A684C3708AB28B9@PALLENE.office.hd> Hi All, I have recently upgraded nfd from 0.2.0 to 0.4.1. While compiling the NFD forwarding strategy I am getting the below mentioned error. Has the functioned been removed from the newer version. Please let me know the alternative for this. error: 'class nfd::pit::Entry' has no member named 'canForwardTo' Regards, Navdeep Uniyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Thu Mar 31 07:16:20 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 31 Mar 2016 07:16:20 -0700 Subject: [Ndn-interest] error while compiling the forwarding startegy In-Reply-To: <15421E67B274CD4AB5F6AEA46A684C3708AB28B9@PALLENE.office.hd> References: <15421E67B274CD4AB5F6AEA46A684C3708AB28B9@PALLENE.office.hd> Message-ID: Hi Navdeep This API is still there in 0.4.1, but is changed after 0.4.1. See NFD Task 3546 and nfd:commit:fef73e4b86b52a54f66c5d43fb575aee98b72ce3 to find out where it goes. Since NFD is not a library, APIs can be deprecated and removed without warning and there's no "deprecation notice" posted to the mailing list. If something doesn't compile, generally you can bisect the commits to find out which commit breaks your code, and look at that commit and the Redmine issue referenced in the commit messsage to find out what happens. Yours, Junxiao On Thu, Mar 31, 2016 at 4:24 AM, Navdeep Uniyal wrote: > Hi All, > > > > I have recently upgraded nfd from 0.2.0 to 0.4.1. While compiling the NFD > forwarding strategy I am getting the below mentioned error. Has the > functioned been removed from the newer version. Please let me know the > alternative for this. > > error: ?class nfd::pit::Entry? has no member named ?canForwardTo? > > > > Regards, > > Navdeep Uniyal > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at caida.org Thu Mar 31 16:51:16 2016 From: josh at caida.org (Josh Polterock) Date: Thu, 31 Mar 2016 16:51:16 -0700 Subject: [Ndn-interest] Named Data Networking (NDN) Project Monthly Newsletter for March 2016 Message-ID: <20160331235116.GB69584@caida.org> Named Data Networking (NDN) Project Newsletter for March 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 20-23 March 2016 we held the 2nd NDN Hackathon and Project Retreat. We welcomed over 30 participants for the Hackathon and over 50 for the Retreat to the University of California at San Diego campus in La Jolla, CA. The retreat focused on science applications, technical discussions with a focus on NFD development, autoconfiguration IoT over NDN, and architectural principles and future collaboration and funding opportunities. For final agenda, slides, and breakout outcomes see the web page at http://www.caida.org/workshops/ndn/1603/ . For the final list of projects and links to code from the Hackathon, see http://2nd-ndn-hackathon.named-data.net/ . TECHNICAL NEWS * We released version 0.11 of the the NDN Common Client Library for Java (jNDN). You can find code and documentation on the web at https://github.com/named-data/jndn . This release adds methods to support Name conventions and a bug fix for sending data with asyncrhonous TCP. * We announced the release of version 0.4.1 of Named Data Networking Forwarding Daemon (NFD) and ndn-cxx library. Please find detailed release notes: - NFD: http://named-data.net/doc/NFD/0.4.1/RELEASE_NOTES.html - ndn-cxx library: http://named-data.net/doc/ndn-cxx/0.4.1/RELEASE_NOTES.html More details about NFD, source code, install instructions, tutorials, HOWTOs, a FAQ and other useful resources are available on the official webpages of NFD and ndn-cxx: - http://named-data.net/doc/NFD/0.4.1/ - http://named-data.net/doc/ndn-cxx/0.4.1/ The latest version of NFD developer's guide revision 6: - http://named-data.net/publications/techreports/ndn-0021-6-nfd-developer-guide/ NDN Essential Tools to version 0.3: - https://github.com/named-data/ndn-tools NDN PUBLICATIONS, PRESENTATIONS, and TECHNICAL REPORTS * For links to the most recent presentations and breakout summaries, please see the 6th NDN Retreat 2016 web page at http://www.caida.org/workshops/ndn/1603/ . SEMINARS * Our NDN Seminar series continued in March. The NDN seminars are internally focused. If you would like to participate in the NDN Seminars, please contact the new PoC, UCLA PhD. candidate Spyridon Mastorakis for the most up-to-date information regarding upcoming seminars. - 2 March 2016 Susmit Shannigrahi (Colorado State University) "Scientific Data Applications in NDN" - 16 March 2016 Ben Murphy (University of Memphis) "Performance measurements of Android devices in NDN" For more information about the Named Data Networking (NDN) Project please visit http://www.named-data.net/.