From bassem.labib at gmail.com Sun Feb 1 11:29:52 2015 From: bassem.labib at gmail.com (Bassem Labib) Date: Sun, 1 Feb 2015 21:29:52 +0200 Subject: [Ndn-interest] Package libndn-cxx was not found Message-ID: Hi, I have downloaded and install NFD and ndn-cxx packages and its prerequisites, on Ubuntu 14.04, as described in http://named-data.net/doc/ndn-cxx/current/INSTALL.html but when I tried to Build ndn-cxx using the command [./waf configure] it failed!!? as shown in the attachment. [Checking for 'libndn-cxx' : not found The configuration failed] and in the log file: *Checking for 'libndn-cxx'* *['/usr/bin/pkg-config', '--cflags', '--libs', 'libndn-cxx']* *err: Package libndn-cxx was not found in the pkg-config search path.* *Perhaps you should add the directory containing `libndn-cxx.pc'* *to the PKG_CONFIG_PATH environment variable* *No package 'libndn-cxx' found* *not found* *from /home/basem/NFD: The configuration failed* Also I tried to check NFD status it gave me the following: ERROR: error while connecting to the forwarder (No such file or directory) Please, help to solve this issue. Best Regards, Bassem Labib -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2015-02-01 20:57:48.png Type: image/png Size: 145968 bytes Desc: not available URL: From shijunxiao at email.arizona.edu Sun Feb 1 14:20:49 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 1 Feb 2015 15:20:49 -0700 Subject: [Ndn-interest] Package libndn-cxx was not found In-Reply-To: References: Message-ID: Hi Bassem This error message should be appearing during NFD build procedure, not during ndn-cxx build procedure. Ubuntu 14.04 is a supported platform. The most probable cause is that ndn-cxx isn't properly installed. To install ndn-cxx, cd to ndn-cxx repository, and execute: sudo ./waf install sudo privilege is required to run this command. Yours, Junxiao On Feb 1, 2015 12:30 PM, "Bassem Labib" wrote: > Hi, > > I have downloaded and install NFD and ndn-cxx packages and its > prerequisites, on Ubuntu 14.04, as described in > http://named-data.net/doc/ndn-cxx/current/INSTALL.html > > but when I tried to Build ndn-cxx using the command [./waf configure] > it failed!!? as shown in the attachment. > [Checking for 'libndn-cxx' : not found > The configuration failed] > > and in the log file: > *Checking for 'libndn-cxx'* > *['/usr/bin/pkg-config', '--cflags', '--libs', 'libndn-cxx']* > *err: Package libndn-cxx was not found in the pkg-config search path.* > *Perhaps you should add the directory containing `libndn-cxx.pc'* > *to the PKG_CONFIG_PATH environment variable* > *No package 'libndn-cxx' found* > *not found* > *from /home/basem/NFD: The configuration failed* > > Also I tried to check NFD status it gave me the following: > ERROR: error while connecting to the forwarder (No such file or directory) > > Please, help to solve this issue. > > Best Regards, > Bassem Labib > > _______________________________________________ > 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 Mon Feb 2 17:12:08 2015 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Tue, 3 Feb 2015 01:12:08 +0000 Subject: [Ndn-interest] NDN Video FAQ 4 posted on scalable forwarding In-Reply-To: Message-ID: NDN Video FAQ #4 from Patrick Crowley, "Do NDN forwarding and longest prefix matching scale?" has been posted here: https://vimeo.com/118312141 https://vimeo.com/channels/ndnvfaq Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Tue Feb 3 16:24:15 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Tue, 3 Feb 2015 16:24:15 -0800 Subject: [Ndn-interest] NFD 0.3.0 and ndn-cxx 0.3.0 released Message-ID: <5D0E3744-1A85-4C01-B85D-BBD8E5682F7A@ucla.edu> Dear all, We are pleased to announce release of version 0.3.0 of Named Data Networking Forwarding Daemon (NFD) and ndn-cxx library. The detailed release notes: - for NFD: http://named-data.net/doc/NFD/0.3.0/RELEASE_NOTES.html - for ndn-cxx library: http://named-data.net/doc/ndn-cxx/0.3.0/RELEASE_NOTES.html More details about NFD, tutorials, HOWTOs, a FAQ and other useful resources are available on official webpages of NFD and ndn-cxx: - http://named-data.net/doc/NFD/0.3.0/ - http://named-data.net/doc/ndn-cxx/0.3.0/ We also have updated the NFD developer's guide to match the new release: http://named-data.net/techreport/ndn-0021-3-nfd-developer-guide.pdf. * * * The NFD Team: Alex Afanasyev, Junxiao Shi, Beichuan Zhang, Lixia Zhang, Ilya Moiseenko, Yingdi Yu, Wentao Shang, 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 -------------- 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 luca.muscariello at orange.com Thu Feb 5 02:06:36 2015 From: luca.muscariello at orange.com (MUSCARIELLO Luca IMT/OLN) Date: Thu, 5 Feb 2015 11:06:36 +0100 Subject: [Ndn-interest] lurch 0.1.0 for ndn and related tools Message-ID: <54D340AC.1000702@orange.com> Dear all, We are please to announce the first release of some tools that might be useful to people doing experimental research with NDN. We have successfully used this tool to run large NDN experiments in a large grid (www.grid5000.fr) but this is also useful to test smaller experiments in a local cluster of servers. The release and related documentation can be found on the following website: http://systemx.enst.fr/lurch Lurch is an NDN experimental test orchestrator including - virtual IP topology configuration and management; - NDN network configuration and management; - workload configuration and management; - test log retrieval. Lurch is available in two versions: 1) for unmodified NFD and ndn-cxx packages version 0.2.0, requiring the installation of "ndn-virtual-repo" and "ndn-icp-download" as additional packages. 2) lurch-custom-0.1.0 works with a modified version of NFD and ndn-cxx packages, NDN-0.2.0-custom, available here http://systemx.enst.fr/archives/NDN-0.2.0-custom.tgz and provides: - LRU cache replacement policy; - interest control rate at the client based on optimized multipath and adaptive remote AQM as described in [1] - congestion aware forwarding strategy as described in [1] - The virtual repo is inspired by the delphi implementation for CCNx 0.x.x by WashU and is available here: http://systemx.enst.fr/archives/ndn-virtual-repo.tgz - The Interest control protocol is an implementation for NDN of the protocol described in [1] and is available here: http://systemx.enst.fr/archives/ndn-icp-download.tgz Luca Muscariello Massimo Gallo [1] Carofiglio, et al. "Optimal multipath congestion control and request forwarding in Information-Centric Networks," IEEE ICNP 2013 http://dx.doi.org/10.1109/ICNP.2013.6733576 -- Orange Labs Networks Luca Muscariello - IMT/NMP/TRM 38 - 40, rue du General Leclerc 92794 Issy Les Moulineaux Cedex 9 - France Tel : +33 (0)1 45 29 60 37 http://perso.rd.francetelecom.fr/muscariello http://systemx.enst.fr/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaim.rieger at gmail.com Thu Feb 5 12:31:16 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Thu, 05 Feb 2015 12:31:16 -0800 Subject: [Ndn-interest] Time and synchronization Message-ID: <54D3D314.5080302@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When generating data that is for multicasting/distribution on an interactive level how would ndn keep track of the time across the network. Data has a requirement to be delivered and interacted with at a certain time after which it should expire or be ignored. Is there some sort of timekeeping within the NDN protocol ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU09MUAAoJEDAlxYoZHOEqTPEP/R8bMiLDOl8tq/hetD5X2N8v X1hOYa7SlqCSw1b7IGwMUOgbEaiYcCiDXEd/hdJN/TWNf/DYFJI4B3g4vdQhyv+4 evU5dFcU7+S9CAzeyYoIVdZE2d3KtZMoOrBilm3e38Q+yKFGc/dXzEjHZGnz8rGy EDBYnyZmixCWHv76s22PzjCVteYed5pg45ZyHenKKy5f54gaDVuVDfYmZh2s5kvZ HO2TZynGHzty0p3Jnz6e/4lHXTKm93KbOUU7/8Q5XXuzHqGYzBslPEyCdeNV7Q+i gXt/EDTElW/BXeQ5rRytEql1AsRgY0ie56xOq/hcRmYO+p316XMqDeQ50NJuDJ5g HrPkoC8kVz8MRN4szxf8NM+4zsBaAfbY2/QyQ5b/wprslvwUlzn2ile1HPhzW54I LNdivVM5hxjYiSJlt8hPv1byykFZjsjxqoIK3vDo257XAQbvvKEBkQ9McQVROaJK 9puuEeiBXcQHCNBpzZOPRtBsnI5LSjXoin3oUN1a2wofN09KIfMMBuuYigu10+oe UX6Q4GOuDrhuHDu6UkuVwktZ3clFd1vTwG3n/3W78YyM4Xc9XZ2N8uiU1Mhyga4t p4LNQLOAsG2ABkhmvw13y+Odk5Q5yIOmNhhuMoXTID8Ac3UYOj2WftZDAJ0czBER ki8ulc35TNmNzYmz4Bee =FOUr -----END PGP SIGNATURE----- From shijunxiao at email.arizona.edu Thu Feb 5 12:36:37 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Thu, 5 Feb 2015 13:36:37 -0700 Subject: [Ndn-interest] Time and synchronization In-Reply-To: <54D3D314.5080302@gmail.com> References: <54D3D314.5080302@gmail.com> Message-ID: Hi Chaim There isn't a timestamp on Data packet at network layer. If your application needs it, add a timestamp at application layer as part of Content. Yours, Junxiao On Feb 5, 2015 12:32 PM, "Chaim Rieger" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > When generating data that is for multicasting/distribution on an > interactive level how would ndn keep track of the time across the > network. Data has a requirement to be delivered and interacted with at > a certain time after which it should expire or be ignored. Is there > some sort of timekeeping within the NDN protocol ? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJU09MUAAoJEDAlxYoZHOEqTPEP/R8bMiLDOl8tq/hetD5X2N8v > X1hOYa7SlqCSw1b7IGwMUOgbEaiYcCiDXEd/hdJN/TWNf/DYFJI4B3g4vdQhyv+4 > evU5dFcU7+S9CAzeyYoIVdZE2d3KtZMoOrBilm3e38Q+yKFGc/dXzEjHZGnz8rGy > EDBYnyZmixCWHv76s22PzjCVteYed5pg45ZyHenKKy5f54gaDVuVDfYmZh2s5kvZ > HO2TZynGHzty0p3Jnz6e/4lHXTKm93KbOUU7/8Q5XXuzHqGYzBslPEyCdeNV7Q+i > gXt/EDTElW/BXeQ5rRytEql1AsRgY0ie56xOq/hcRmYO+p316XMqDeQ50NJuDJ5g > HrPkoC8kVz8MRN4szxf8NM+4zsBaAfbY2/QyQ5b/wprslvwUlzn2ile1HPhzW54I > LNdivVM5hxjYiSJlt8hPv1byykFZjsjxqoIK3vDo257XAQbvvKEBkQ9McQVROaJK > 9puuEeiBXcQHCNBpzZOPRtBsnI5LSjXoin3oUN1a2wofN09KIfMMBuuYigu10+oe > UX6Q4GOuDrhuHDu6UkuVwktZ3clFd1vTwG3n/3W78YyM4Xc9XZ2N8uiU1Mhyga4t > p4LNQLOAsG2ABkhmvw13y+Odk5Q5yIOmNhhuMoXTID8Ac3UYOj2WftZDAJ0czBER > ki8ulc35TNmNzYmz4Bee > =FOUr > -----END PGP SIGNATURE----- > _______________________________________________ > 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 chaim.rieger at gmail.com Thu Feb 5 12:53:12 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Thu, 05 Feb 2015 12:53:12 -0800 Subject: [Ndn-interest] Time and synchronization In-Reply-To: References: <54D3D314.5080302@gmail.com> Message-ID: <54D3D838.5080404@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does NDN do any sort of synchronization within itself ? Or is it up to the publishers of data to either timestamp or version data that gets produced ? On 2/5/2015 12:36 PM, Junxiao Shi wrote: > Hi Chaim > > There isn't a timestamp on Data packet at network layer. If your > application needs it, add a timestamp at application layer as part > of Content. > > Yours, Junxiao On Feb 5, 2015 12:32 PM, "Chaim Rieger" > wrote: > > When generating data that is for multicasting/distribution on an > interactive level how would ndn keep track of the time across the > network. Data has a requirement to be delivered and interacted with > at a certain time after which it should expire or be ignored. Is > there some sort of timekeeping within the NDN protocol ? >> _______________________________________________ Ndn-interest >> mailing list Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU09g4AAoJEDAlxYoZHOEqdecP/RzMp7FGY91d46JiRukJgVES GjEH8/8frM32HPgi1fdwi8RNB4mBwLV+zQCq7bfSmfj15V5oEm/Shl6y/IPm0j+k uRxkxXZxxW/xuUfyi76GfQVHVXSTg1eai/U/hw9A/V4jnW9yOyp2IFg9f+UQ4u3t rSH0dFRSbnJSxTNhz3HM26dZ7TU/oKc9umvRrUtdCmDsXgZRbaY/b9yMdES2vxRp v3XkcsoJwyYaP0pBRqka+weKXElM0aWcQYKek+RQJ3msmv06yp8DVSxcp4lYtHeF 3C/m9ba04MtbLlW5b82nD4p3dii7H86vCjefWfku2cNlTc+NGLtSAA+FeT6drhxc SKU1nR1v8Och1kXS9DL0BRXWJh05VBy6bBSi6Uu6jH1UOHdc1m0T0dey7Jmd10dP 4ZxrLk22bX8LRpTKTip82tpG2hJHOO4EQLbd3neDRDoguI73QRaQ0Erjd5rFJAST y12n+mSfQC8lcT37NmXPm/zthPVmsKPMwnFwj+JBnPauzL/pL1SM0Dy78sJ4mc2x YE/02C4hhl8oZW3OLoFIsQO2NdLw8+aKtuX+AK34pdgbScjYyzh0eMghdA/nMBJp HxQs9+btnlU+ieogaRdAh4SdOcSWFpAYiVUA1wqgeW8W0ZCq4pby+oge5kiykac8 dQqY8rl53v+l3QOyA4l1 =aVdt -----END PGP SIGNATURE----- From chaim.rieger at gmail.com Thu Feb 5 13:05:38 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Thu, 05 Feb 2015 13:05:38 -0800 Subject: [Ndn-interest] Time and synchronization In-Reply-To: References: <54D3D314.5080302@gmail.com> Message-ID: <54D3DB22.5060804@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Followup After reading http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing Snip... valid signed Interest whose timestamp is equal or later than the timestamp of the received one has been received before. Note that in order to detect this situation, the recipient needs to maintain a latest timestamp state for each trusted public key This speaks to my question, NDN has some requirements that depend on Time/Timestamp. Who is the master of said Time ? If I were to generate data in the future (Time+60s) would that be read after data that is generated in RealTime 30 Seconds from now ? There seems to have been some minor discussion that broached this subject on this mailing list back in Sept of 2014. Does my question(s) make sense ? On 2/5/2015 12:36 PM, Junxiao Shi wrote: > Hi Chaim > > There isn't a timestamp on Data packet at network layer. If your > application needs it, add a timestamp at application layer as part > of Content. > > Yours, Junxiao On Feb 5, 2015 12:32 PM, "Chaim Rieger" > wrote: > > When generating data that is for multicasting/distribution on an > interactive level how would ndn keep track of the time across the > network. Data has a requirement to be delivered and interacted > with at a certain time after which it should expire or be ignored. > Is there some sort of timekeeping within the NDN protocol ? >> _______________________________________________ Ndn-interest >> mailing list Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU09shAAoJEDAlxYoZHOEqUIsP/3+CWurV26mMI/pYaibfq8O9 YvnRPOPIlEHVThJCdzdrVYp9BkV/slXtcaenNGQmo8/84vx2UJ4dmo4b8XhfIy93 eKz6hgDxfMH1uS8sq5+nXJRP1fs3TKlhbJfTH6tfYk0AlAxDEAhw0DnQyD/NwbBH Y53m+o6yeMf4HDIJjvGeFJfYZxeIg8+R3ocMr1VZdvClfDRryvvucjU7mLEw+9NO 0xB3bn+My6ScuuR3Rspy7hssHOyJDcpZ4OkPaiMbCcUDc+GAKg1Cm1IzhL9cTj3D JftYboAde5i7cZDOhh37p7ezYp12bbWRKNVvxG2DZ/Ow4CU8GWUyjgnpZdpukB2v 0QGzzBryx6V9YB+8MDw+g2ljeMiHaKDnsKlm5dZSxbjAQ1axK3EecEc53r8LTjYk cZ/7JVO2FlI8wAR7DKUZADA3qPpH4q4AlG1yGvfhDHKGjzeprzjX0FIy440Ku263 wlvn0HLEH/8xwFl1pRydLhVUk54wHE2ImFRe5IZivGP5L0RUlaov/ihfi1KkJRq5 wI4j1d/FJecpQ38G7YdeLHU3R2XNQIh4Oqa8wIOyJVhkLSC4YgwAA5ZkslJ/tQLj yNQBlGJF3j2FHWHsqp6FZWJjXy4kalz5zTatW5DDbdp6k9qT9Tt+RHRwY6nf74X0 /M/8921w6UJQzeTy4UrP =3JiX -----END PGP SIGNATURE----- From Marc.Mosko at parc.com Thu Feb 5 13:18:15 2015 From: Marc.Mosko at parc.com (Marc.Mosko at parc.com) Date: Thu, 5 Feb 2015 21:18:15 +0000 Subject: [Ndn-interest] Time and synchronization In-Reply-To: <54D3DB22.5060804@gmail.com> References: <54D3D314.5080302@gmail.com> <54D3DB22.5060804@gmail.com> Message-ID: <7FBFE8AA-F3F7-42A5-A89A-BC50EBBF96BA@parc.com> The NDN spec for signed interests specifically says "Note that this verification process require signed interest to be received in order. Applications adopting this process may want to take 'stop-and-wait' strategy.? Therefore, the actual synchronization of timestamps is not essential, they are just a non-monotonic increasing sequence number. This may or may not work for you application. Computing the grace interval, as specified there, does require at least loose synchronization of clocks. > Note that for the first Interest, the state is not available. To handle this special situation, the recipient should check the Interest's timestamp against a grace interval (e.g., 120 seconds) [current_timestamp - interval/2, current_timestamp + interval/2]. The first interest is invalid if its timestamp is outside of the interval. DTLS and IPsec use a sliding window, so they specifically protect against replay without enforcing ordered packet arrivals. They use sequence numbers, not timestamps. Marc On Feb 5, 2015, at 1:05 PM, Chaim Rieger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Followup > After reading > http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing > > Snip... > > valid signed Interest whose timestamp is equal or later than the > timestamp of the received one has been received before. > Note that in order to detect this situation, the recipient needs to > maintain a latest timestamp state for each trusted public key > > > This speaks to my question, NDN has some requirements that depend on > Time/Timestamp. Who is the master of said Time ? If I were to generate > data in the future (Time+60s) would that be read after data that is > generated in RealTime 30 Seconds from now ? > > > There seems to have been some minor discussion that broached this > subject on this mailing list back in Sept of 2014. > Does my question(s) make sense ? > > > > On 2/5/2015 12:36 PM, Junxiao Shi wrote: >> Hi Chaim >> >> There isn't a timestamp on Data packet at network layer. If your >> application needs it, add a timestamp at application layer as part >> of Content. >> >> Yours, Junxiao On Feb 5, 2015 12:32 PM, "Chaim Rieger" >> wrote: >> >> When generating data that is for multicasting/distribution on an >> interactive level how would ndn keep track of the time across the >> network. Data has a requirement to be delivered and interacted >> with at a certain time after which it should expire or be ignored. >> Is there some sort of timekeeping within the NDN protocol ? >>> _______________________________________________ Ndn-interest >>> mailing list Ndn-interest at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>> >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJU09shAAoJEDAlxYoZHOEqUIsP/3+CWurV26mMI/pYaibfq8O9 > YvnRPOPIlEHVThJCdzdrVYp9BkV/slXtcaenNGQmo8/84vx2UJ4dmo4b8XhfIy93 > eKz6hgDxfMH1uS8sq5+nXJRP1fs3TKlhbJfTH6tfYk0AlAxDEAhw0DnQyD/NwbBH > Y53m+o6yeMf4HDIJjvGeFJfYZxeIg8+R3ocMr1VZdvClfDRryvvucjU7mLEw+9NO > 0xB3bn+My6ScuuR3Rspy7hssHOyJDcpZ4OkPaiMbCcUDc+GAKg1Cm1IzhL9cTj3D > JftYboAde5i7cZDOhh37p7ezYp12bbWRKNVvxG2DZ/Ow4CU8GWUyjgnpZdpukB2v > 0QGzzBryx6V9YB+8MDw+g2ljeMiHaKDnsKlm5dZSxbjAQ1axK3EecEc53r8LTjYk > cZ/7JVO2FlI8wAR7DKUZADA3qPpH4q4AlG1yGvfhDHKGjzeprzjX0FIy440Ku263 > wlvn0HLEH/8xwFl1pRydLhVUk54wHE2ImFRe5IZivGP5L0RUlaov/ihfi1KkJRq5 > wI4j1d/FJecpQ38G7YdeLHU3R2XNQIh4Oqa8wIOyJVhkLSC4YgwAA5ZkslJ/tQLj > yNQBlGJF3j2FHWHsqp6FZWJjXy4kalz5zTatW5DDbdp6k9qT9Tt+RHRwY6nf74X0 > /M/8921w6UJQzeTy4UrP > =3JiX > -----END PGP SIGNATURE----- > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest From alexander.afanasyev at ucla.edu Thu Feb 5 13:45:03 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Thu, 5 Feb 2015 13:45:03 -0800 Subject: [Ndn-interest] Time and synchronization In-Reply-To: <7FBFE8AA-F3F7-42A5-A89A-BC50EBBF96BA@parc.com> References: <54D3D314.5080302@gmail.com> <54D3DB22.5060804@gmail.com> <7FBFE8AA-F3F7-42A5-A89A-BC50EBBF96BA@parc.com> Message-ID: > On Feb 5, 2015, at 1:18 PM, wrote: > > The NDN spec for signed interests specifically says "Note that this verification process require signed interest to be received in order. Applications adopting this process may want to take 'stop-and-wait' strategy.? Therefore, the actual synchronization of timestamps is not essential, they are just a non-monotonic increasing sequence number. This may or may not work for you application. > > Computing the grace interval, as specified there, does require at least loose synchronization of clocks. > >> Note that for the first Interest, the state is not available. To handle this special situation, the recipient should check the Interest's timestamp against a grace interval (e.g., 120 seconds) [current_timestamp - interval/2, current_timestamp + interval/2]. The first interest is invalid if its timestamp is outside of the interval. > > > DTLS and IPsec use a sliding window, so they specifically protect against replay without enforcing ordered packet arrivals. They use sequence numbers, not timestamps. The reason they can use sequence numbers is because the "session" is getting authorized in the beginning with some challenge/nonce. We probably can do something similar, but idea was to avoid any sessions that need to be established before performing the control. -- Alex > > Marc > > On Feb 5, 2015, at 1:05 PM, Chaim Rieger wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Followup >> After reading >> http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing >> >> Snip... >> >> valid signed Interest whose timestamp is equal or later than the >> timestamp of the received one has been received before. >> Note that in order to detect this situation, the recipient needs to >> maintain a latest timestamp state for each trusted public key >> >> >> This speaks to my question, NDN has some requirements that depend on >> Time/Timestamp. Who is the master of said Time ? If I were to generate >> data in the future (Time+60s) would that be read after data that is >> generated in RealTime 30 Seconds from now ? >> >> >> There seems to have been some minor discussion that broached this >> subject on this mailing list back in Sept of 2014. >> Does my question(s) make sense ? >> >> >> >> On 2/5/2015 12:36 PM, Junxiao Shi wrote: >>> Hi Chaim >>> >>> There isn't a timestamp on Data packet at network layer. If your >>> application needs it, add a timestamp at application layer as part >>> of Content. >>> >>> Yours, Junxiao On Feb 5, 2015 12:32 PM, "Chaim Rieger" >>> wrote: >>> >>> When generating data that is for multicasting/distribution on an >>> interactive level how would ndn keep track of the time across the >>> network. Data has a requirement to be delivered and interacted >>> with at a certain time after which it should expire or be ignored. >>> Is there some sort of timekeeping within the NDN protocol ? >>>> _______________________________________________ Ndn-interest >>>> mailing list Ndn-interest at lists.cs.ucla.edu >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest >>>> >>> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQIcBAEBAgAGBQJU09shAAoJEDAlxYoZHOEqUIsP/3+CWurV26mMI/pYaibfq8O9 >> YvnRPOPIlEHVThJCdzdrVYp9BkV/slXtcaenNGQmo8/84vx2UJ4dmo4b8XhfIy93 >> eKz6hgDxfMH1uS8sq5+nXJRP1fs3TKlhbJfTH6tfYk0AlAxDEAhw0DnQyD/NwbBH >> Y53m+o6yeMf4HDIJjvGeFJfYZxeIg8+R3ocMr1VZdvClfDRryvvucjU7mLEw+9NO >> 0xB3bn+My6ScuuR3Rspy7hssHOyJDcpZ4OkPaiMbCcUDc+GAKg1Cm1IzhL9cTj3D >> JftYboAde5i7cZDOhh37p7ezYp12bbWRKNVvxG2DZ/Ow4CU8GWUyjgnpZdpukB2v >> 0QGzzBryx6V9YB+8MDw+g2ljeMiHaKDnsKlm5dZSxbjAQ1axK3EecEc53r8LTjYk >> cZ/7JVO2FlI8wAR7DKUZADA3qPpH4q4AlG1yGvfhDHKGjzeprzjX0FIy440Ku263 >> wlvn0HLEH/8xwFl1pRydLhVUk54wHE2ImFRe5IZivGP5L0RUlaov/ihfi1KkJRq5 >> wI4j1d/FJecpQ38G7YdeLHU3R2XNQIh4Oqa8wIOyJVhkLSC4YgwAA5ZkslJ/tQLj >> yNQBlGJF3j2FHWHsqp6FZWJjXy4kalz5zTatW5DDbdp6k9qT9Tt+RHRwY6nf74X0 >> /M/8921w6UJQzeTy4UrP >> =3JiX >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Ndn-interest mailing list >> Ndn-interest at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From chaim.rieger at gmail.com Thu Feb 5 13:50:08 2015 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Thu, 05 Feb 2015 13:50:08 -0800 Subject: [Ndn-interest] Time and synchronization In-Reply-To: References: <54D3D314.5080302@gmail.com> <54D3DB22.5060804@gmail.com> <7FBFE8AA-F3F7-42A5-A89A-BC50EBBF96BA@parc.com> Message-ID: <54D3E590.1080103@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So to answer half of my own question based on further reading and input from you. NDN does not maintain any form of synchronization with Time (which is an external algorithm). NDN will however upon the establishment of a session carry a sync (packet?) between the producer and the recipient, and any further packets within said session window will be incremented, thereby verifying that all data is synchronized. Is this statement somewhat correct. Am trying to put into as simple terms as possible for easy understanding by non technical folks. On 2/5/2015 1:45 PM, Alex Afanasyev wrote: > >> On Feb 5, 2015, at 1:18 PM, >> wrote: >> >> The NDN spec for signed interests specifically says "Note that >> this verification process require signed interest to be received >> in order. Applications adopting this process may want to take >> 'stop-and-wait' strategy.? Therefore, the actual >> synchronization of timestamps is not essential, they are just a >> non-monotonic increasing sequence number. This may or may not >> work for you application. >> >> Computing the grace interval, as specified there, does require >> at least loose synchronization of clocks. >> >>> Note that for the first Interest, the state is not available. >>> To handle this special situation, the recipient should check >>> the Interest's timestamp against a grace interval (e.g., 120 >>> seconds) [current_timestamp - interval/2, current_timestamp + >>> interval/2]. The first interest is invalid if its timestamp is >>> outside of the interval. >> >> >> DTLS and IPsec use a sliding window, so they specifically >> protect against replay without enforcing ordered packet arrivals. >> They use sequence numbers, not timestamps. > > The reason they can use sequence numbers is because the "session" > is getting authorized in the beginning with some challenge/nonce. > We probably can do something similar, but idea was to avoid any > sessions that need to be established before performing the > control. > > -- Alex > >> >> Marc >> >> On Feb 5, 2015, at 1:05 PM, Chaim Rieger >> wrote: >> > Followup After reading > http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing > > > Snip... > > valid signed Interest whose timestamp is equal or later than the > timestamp of the received one has been received before. Note that > in order to detect this situation, the recipient needs to maintain > a latest timestamp state for each trusted public key > > > This speaks to my question, NDN has some requirements that depend > on Time/Timestamp. Who is the master of said Time ? If I were to > generate data in the future (Time+60s) would that be read after > data that is generated in RealTime 30 Seconds from now ? > > > There seems to have been some minor discussion that broached this > subject on this mailing list back in Sept of 2014. Does my > question(s) make sense ? > > > > On 2/5/2015 12:36 PM, Junxiao Shi wrote: >>>>> Hi Chaim >>>>> >>>>> There isn't a timestamp on Data packet at network layer. >>>>> If your application needs it, add a timestamp at >>>>> application layer as part of Content. >>>>> >>>>> Yours, Junxiao On Feb 5, 2015 12:32 PM, "Chaim Rieger" >>>>> wrote: >>>>> >>>>> When generating data that is for multicasting/distribution >>>>> on an interactive level how would ndn keep track of the >>>>> time across the network. Data has a requirement to be >>>>> delivered and interacted with at a certain time after >>>>> which it should expire or be ignored. Is there some sort >>>>> of timekeeping within the NDN protocol ? >>>>>> _______________________________________________ >>>>>> 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU0+WQAAoJEDAlxYoZHOEq3oUQAJ4lEnrJx4rglzlBeDNKYQ+Z UGItIFpYvEaD0ehT2B2JNCqgfvriCE4SQWo+VZcw+DsnCy7L0h8cQtkyoW8Chynf 32hKeu+GggDkzoigUaH0NLAWo5GfHt6XC2TN30PiLMufxsCDAhNCi5PGUDNK0ZfW 5QFtcxg9om/6Fye0L3UqKpJfFBl10itw7iPj6vUSjZ7RhYJ/T/xEBl6SN/+davtZ LTM+iFv+/evy02MAAebFp5JBaDdlfBcPeBwOzjhzUwv1JrKwh5W7D9j3JA5WzptO cxM8FSJZ3SVC1OqfxGIjBimap+Akd2Bzv9F1sWd6eMab9qqZiR2u2LOTij1XPwok IspewT85Vf/gK8n7Qe5WqWcPtJmg8oxESmzmVYm8UTV8AFEMqcbeEjRrtemt3fjQ rj/7fenxwWnYOeeiQ1pCiBgraop5Pgj9XMdeDOboIvb9sJOSr7UVciQmwQnlyKXt iHEUU7dBLaTQWdzmo/bR3TAlJctxHkdtOcMRDyGaihHhr8I+APppfWLyalX6nrxa xLhAXPvsS1u2co4FosJMmSUWMBjAxbM8fqOIvphR5h9BgAIWdMMCS7ZoKVV1XCjI 518A7lcCJCr0kmQLnSENHhKGKWF4Prs0WD4/BXyD3ArafNqeqfeiQjr8SYGL4Lge OnBuLPRQdZLkBbewc10w =E3Mj -----END PGP SIGNATURE----- From alexander.afanasyev at ucla.edu Thu Feb 5 14:03:13 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Thu, 5 Feb 2015 14:03:13 -0800 Subject: [Ndn-interest] Time and synchronization In-Reply-To: <54D3E590.1080103@gmail.com> References: <54D3D314.5080302@gmail.com> <54D3DB22.5060804@gmail.com> <7FBFE8AA-F3F7-42A5-A89A-BC50EBBF96BA@parc.com> <54D3E590.1080103@gmail.com> Message-ID: <23210CDD-4DE7-42E6-9D96-659C274660EA@ucla.edu> > On Feb 5, 2015, at 1:50 PM, Chaim Rieger wrote: > > Signed PGP part > So to answer half of my own question based on further reading and > input from you. > > NDN does not maintain any form of synchronization with Time (which is > an external algorithm). NDN will however upon the establishment of a > session carry a sync (packet?) between the producer and the recipient, > and any further packets within said session window will be > incremented, thereby verifying that all data is synchronized. Any synchronization is applications specific. If some application needs it, then it may require (either as part of documentation or do something about it). There is nothing that is specific to the networking architecture itself. Also, there is nothing that prevents you to implement such sessions, you may just lose some benefits of NDN network. One potential issue with "sessions" is that there is no guarantee that NDN will deliver subsequent interests to the same place. NDN is data oriented architecture. Interest is trying to discover where data is located (using routing and other information as an input). -- Alex > Is this statement somewhat correct. Am trying to put into as simple > terms as possible for easy understanding by non technical folks. > > > > > On 2/5/2015 1:45 PM, Alex Afanasyev wrote: > > > >> On Feb 5, 2015, at 1:18 PM, > >> wrote: > >> > >> The NDN spec for signed interests specifically says "Note that > >> this verification process require signed interest to be received > >> in order. Applications adopting this process may want to take > >> 'stop-and-wait' strategy.? Therefore, the actual > >> synchronization of timestamps is not essential, they are just a > >> non-monotonic increasing sequence number. This may or may not > >> work for you application. > >> > >> Computing the grace interval, as specified there, does require > >> at least loose synchronization of clocks. > >> > >>> Note that for the first Interest, the state is not available. > >>> To handle this special situation, the recipient should check > >>> the Interest's timestamp against a grace interval (e.g., 120 > >>> seconds) [current_timestamp - interval/2, current_timestamp + > >>> interval/2]. The first interest is invalid if its timestamp is > >>> outside of the interval. > >> > >> > >> DTLS and IPsec use a sliding window, so they specifically > >> protect against replay without enforcing ordered packet arrivals. > >> They use sequence numbers, not timestamps. > > > > The reason they can use sequence numbers is because the "session" > > is getting authorized in the beginning with some challenge/nonce. > > We probably can do something similar, but idea was to avoid any > > sessions that need to be established before performing the > > control. > > > > -- Alex > > > >> > >> Marc > >> > >> On Feb 5, 2015, at 1:05 PM, Chaim Rieger > >> wrote: > >> > > Followup After reading > > http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing > > > > > > > Snip... > > > > valid signed Interest whose timestamp is equal or later than the > > timestamp of the received one has been received before. Note that > > in order to detect this situation, the recipient needs to maintain > > a latest timestamp state for each trusted public key > > > > > > This speaks to my question, NDN has some requirements that depend > > on Time/Timestamp. Who is the master of said Time ? If I were to > > generate data in the future (Time+60s) would that be read after > > data that is generated in RealTime 30 Seconds from now ? > > > > > > There seems to have been some minor discussion that broached this > > subject on this mailing list back in Sept of 2014. Does my > > question(s) make sense ? > > > > > > > > On 2/5/2015 12:36 PM, Junxiao Shi wrote: > >>>>> Hi Chaim > >>>>> > >>>>> There isn't a timestamp on Data packet at network layer. > >>>>> If your application needs it, add a timestamp at > >>>>> application layer as part of Content. > >>>>> > >>>>> Yours, Junxiao On Feb 5, 2015 12:32 PM, "Chaim Rieger" > >>>>> wrote: > >>>>> > >>>>> When generating data that is for multicasting/distribution > >>>>> on an interactive level how would ndn keep track of the > >>>>> time across the network. Data has a requirement to be > >>>>> delivered and interacted with at a certain time after > >>>>> which it should expire or be ignored. Is there some sort > >>>>> of timekeeping within the NDN protocol ? > >>>>>> _______________________________________________ > >>>>>> 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 -------------- 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 jlee700 at illinois.edu Thu Feb 5 18:07:20 2015 From: jlee700 at illinois.edu (Lee, Jongdeog) Date: Fri, 6 Feb 2015 02:07:20 +0000 Subject: [Ndn-interest] Exclude selector codes Message-ID: Hi, Does anybody have example codes for the exclude selector? http://named-data.net/doc/ndn-tlv/interest.html#selectors If somebody knows where I can find actual codes, please share it. Best wishes, Jongdeog Lee (JD) ------------------------------------------------ Ph.D. Student Department of Computer Science University of Illinois at Urbana-Champaign -------------- next part -------------- An HTML attachment was scrubbed... URL: From dibenede at cs.colostate.edu Thu Feb 5 18:10:40 2015 From: dibenede at cs.colostate.edu (Steve DiBenedetto) Date: Fri, 6 Feb 2015 02:10:40 +0000 (UTC) Subject: [Ndn-interest] Exclude selector codes In-Reply-To: References: Message-ID: http://gerrit.named-data.net/#/c/1581/4/examples/ndncatchunks-src/discover-version.cpp -Steve _____________________________ From: Lee, Jongdeog Sent: Thursday, February 5, 2015 6:07 PM Subject: [Ndn-interest] Exclude selector codes To: Hi, ? Does anybody have example codes for the exclude selector? ??http://named-data.net/doc/ndn-tlv/interest.html#selectors ? If somebody knows where I can find actual codes, please share it. Best wishes, Jongdeog Lee (JD) ------------------------------------------------ Ph.D. Student Department of Computer Science University of Illinois at Urbana-Champaign -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at remap.ucla.edu Fri Feb 6 17:35:45 2015 From: jburke at remap.ucla.edu (Burke, Jeff) Date: Sat, 7 Feb 2015 01:35:45 +0000 Subject: [Ndn-interest] NDN Video FAQs 6 & 7 - Routing, Application-Driven FIA research Message-ID: Hi everyone, We have posted two new video FAQs: 6. What routing strategies are being explored for NDN? Lan Wang University of Memphis 7. Why should future internet architecture research be application driven? David Clark MIT CSAIL https://vimeo.com/channels/ndnvfaq Best, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From bassem.labib at gmail.com Sat Feb 7 10:25:57 2015 From: bassem.labib at gmail.com (Bassem Labib) Date: Sat, 7 Feb 2015 20:25:57 +0200 Subject: [Ndn-interest] List of registerPrefix Message-ID: Hi All, I am using jNDN client with NFD, does any one have a code that can read or list all the "registerPrefix" registered in the FIB or RIB. Thanks in advance, Bassem Labib -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sat Feb 7 10:30:37 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 7 Feb 2015 11:30:37 -0700 Subject: [Ndn-interest] List of registerPrefix In-Reply-To: References: Message-ID: Hi Bassem Executing `nfd-status -r` on command line will display the RIB dataset. Routes installed in the RIB can be accessed by requesting RIB dataset . In jNDN, you can write a consumer program to request this dataset. Yours, Junxiao On Sat, Feb 7, 2015 at 11:25 AM, Bassem Labib wrote: > Hi All, > > I am using jNDN client with NFD, does any one have a code that can read or > list all the "registerPrefix" registered in the FIB or RIB. > > Thanks in advance, > Bassem Labib > > _______________________________________________ > 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 bassem.labib at gmail.com Sat Feb 7 11:03:39 2015 From: bassem.labib at gmail.com (Bassem Labib) Date: Sat, 7 Feb 2015 21:03:39 +0200 Subject: [Ndn-interest] List of registerPrefix In-Reply-To: References: Message-ID: Hi Junxiao, I don't know how to call `nfd-status -r` command using jNDN. Actually, I tried to do so, thorough using the class Node.RegisteredPrefix and Node.RegisterResponse, but I failed. So, I will be grateful if you provide any sample to get the required list of registerPrefix. Thanks, Bassem Labib On Sat, Feb 7, 2015 at 8:30 PM, Junxiao Shi wrote: > Hi Bassem > > Executing `nfd-status -r` on command line will display the RIB dataset. > > Routes installed in the RIB can be accessed by requesting RIB dataset > . > In jNDN, you can write a consumer program to request this dataset. > > Yours, Junxiao > > On Sat, Feb 7, 2015 at 11:25 AM, Bassem Labib > wrote: > >> Hi All, >> >> I am using jNDN client with NFD, does any one have a code that can read >> or list all the "registerPrefix" registered in the FIB or RIB. >> >> Thanks in advance, >> Bassem Labib >> >> _______________________________________________ >> 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 jefft0 at remap.ucla.edu Sun Feb 8 10:54:32 2015 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Sun, 8 Feb 2015 18:54:32 +0000 Subject: [Ndn-interest] List of registerPrefix In-Reply-To: References: Message-ID: Hello Bassem, May I ask what operating system you are using for jNDN? OS X or Linux or other? (I ask because jNDN has better default support on some operating systems.) - Jeff T From: Bassem Labib > Date: Saturday, February 7, 2015 at 10:25 To: "ndn-interest at lists.cs.ucla.edu" > Subject: [Ndn-interest] List of registerPrefix Hi All, I am using jNDN client with NFD, does any one have a code that can read or list all the "registerPrefix" registered in the FIB or RIB. Thanks in advance, Bassem Labib -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefft0 at remap.ucla.edu Sun Feb 8 18:20:27 2015 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Mon, 9 Feb 2015 02:20:27 +0000 Subject: [Ndn-interest] List of registerPrefix In-Reply-To: References: Message-ID: Hello Bassem, I added an example to jNDN which sends an interest to /localhost/nfd/rib/list and prints the returned RibEntry message. Please pull the lastest from GitHub. Here is the file: https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/TestListRib.java The content of the returned Data packet is a TLV RibEntry message. To decode it, the example uses the jNDN utility called ProtobufTlv. This works with a .proto definition file: https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/RibEntryProto.java Note that ProtobufTlv does not work with the Protobuf wire format. Instead, ProtobufTlv decodes the TLV and creates an in-memory Protobuf RibEntryMessage object that your code can examine to get the field values. The ProtobufTlv utility is very general. You can use it to encode and decode just about any TLV type, if you make the .proto file. Let me know if you have any trouble running the example. Thanks, - Jeff T From: Bassem Labib > Date: Saturday, February 7, 2015 at 11:03 To: Junxiao Shi > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] List of registerPrefix Hi Junxiao, I don't know how to call `nfd-status -r` command using jNDN. Actually, I tried to do so, thorough using the class Node.RegisteredPrefix and Node.RegisterResponse, but I failed. So, I will be grateful if you provide any sample to get the required list of registerPrefix. Thanks, Bassem Labib On Sat, Feb 7, 2015 at 8:30 PM, Junxiao Shi > wrote: Hi Bassem Executing `nfd-status -r` on command line will display the RIB dataset. Routes installed in the RIB can be accessed by requesting RIB dataset. In jNDN, you can write a consumer program to request this dataset. Yours, Junxiao On Sat, Feb 7, 2015 at 11:25 AM, Bassem Labib > wrote: Hi All, I am using jNDN client with NFD, does any one have a code that can read or list all the "registerPrefix" registered in the FIB or RIB. Thanks in advance, Bassem Labib _______________________________________________ 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 jefft0 at remap.ucla.edu Sun Feb 8 18:23:06 2015 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Mon, 9 Feb 2015 02:23:06 +0000 Subject: [Ndn-interest] List of registerPrefix In-Reply-To: References: Message-ID: Sorry. I should like to the .proto file, not to the RibEntryProto class which was generated from it. Here it is: https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/rib-entry-proto.proto From: , Jeff Thompson > Date: Sunday, February 8, 2015 at 18:20 To: Bassem Labib > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] List of registerPrefix Hello Bassem, I added an example to jNDN which sends an interest to /localhost/nfd/rib/list and prints the returned RibEntry message. Please pull the lastest from GitHub. Here is the file: https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/TestListRib.java The content of the returned Data packet is a TLV RibEntry message. To decode it, the example uses the jNDN utility called ProtobufTlv. This works with a .proto definition file: https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/RibEntryProto.java Note that ProtobufTlv does not work with the Protobuf wire format. Instead, ProtobufTlv decodes the TLV and creates an in-memory Protobuf RibEntryMessage object that your code can examine to get the field values. The ProtobufTlv utility is very general. You can use it to encode and decode just about any TLV type, if you make the .proto file. Let me know if you have any trouble running the example. Thanks, - Jeff T From: Bassem Labib > Date: Saturday, February 7, 2015 at 11:03 To: Junxiao Shi > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] List of registerPrefix Hi Junxiao, I don't know how to call `nfd-status -r` command using jNDN. Actually, I tried to do so, thorough using the class Node.RegisteredPrefix and Node.RegisterResponse, but I failed. So, I will be grateful if you provide any sample to get the required list of registerPrefix. Thanks, Bassem Labib On Sat, Feb 7, 2015 at 8:30 PM, Junxiao Shi > wrote: Hi Bassem Executing `nfd-status -r` on command line will display the RIB dataset. Routes installed in the RIB can be accessed by requesting RIB dataset. In jNDN, you can write a consumer program to request this dataset. Yours, Junxiao On Sat, Feb 7, 2015 at 11:25 AM, Bassem Labib > wrote: Hi All, I am using jNDN client with NFD, does any one have a code that can read or list all the "registerPrefix" registered in the FIB or RIB. Thanks in advance, Bassem Labib _______________________________________________ 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 Sun Feb 8 19:54:48 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sun, 8 Feb 2015 20:54:48 -0700 Subject: [Ndn-interest] List of registerPrefix In-Reply-To: References: Message-ID: Dear folks I need to point out that TestLibRib.java is an incomplete implementation of StatusDataset client requesting RIB dataset. A StatusDataset is segmented, but the example doesn't request all segments. Also, there's no guarantee that segment boundary is between two RibEntry elements. Yours, Junxiao On Sun, Feb 8, 2015 at 7:20 PM, Thompson, Jeff wrote: > Hello Bassem, > > I added an example to jNDN which sends an interest > to /localhost/nfd/rib/list and prints the returned RibEntry message. Please > pull the lastest from GitHub. Here is the file: > > https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/TestListRib.java > > The content of the returned Data packet is a TLV RibEntry message. To > decode it, the example uses the jNDN utility called ProtobufTlv. This > works with a .proto definition file: > > https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/rib-entry-proto.proto > > Note that ProtobufTlv does not work with the Protobuf wire format. > Instead, ProtobufTlv decodes the TLV and creates an in-memory Protobuf > RibEntryMessage object that your code can examine to get the field values. > The ProtobufTlv utility is very general. You can use it to encode and > decode just about any TLV type, if you make the .proto file. > > Let me know if you have any trouble running the example. > > Thanks, > - Jeff T > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefft0 at remap.UCLA.EDU Mon Feb 9 15:17:21 2015 From: jefft0 at remap.UCLA.EDU (Thompson, Jeff) Date: Mon, 9 Feb 2015 23:17:21 +0000 Subject: [Ndn-interest] List of registerPrefix In-Reply-To: References: Message-ID: Hi Junxiao, Yes you are right. Thanks for pointing it out. (I forgot to mention this while I was sending a reply quickly.) The example will only work with a reponse which fits into one Data packet. I can update the example to handle mutiple segments. Thanks, - Jeff T From: Junxiao Shi > Date: Sunday, February 8, 2015 at 19:54 To: Jeff Thompson > Cc: Bassem Labib >, "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] List of registerPrefix Dear folks I need to point out that TestLibRib.java is an incomplete implementation of StatusDataset client requesting RIB dataset. A StatusDataset is segmented, but the example doesn't request all segments. Also, there's no guarantee that segment boundary is between two RibEntry elements. Yours, Junxiao On Sun, Feb 8, 2015 at 7:20 PM, Thompson, Jeff > wrote: Hello Bassem, I added an example to jNDN which sends an interest to /localhost/nfd/rib/list and prints the returned RibEntry message. Please pull the lastest from GitHub. Here is the file: https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/TestListRib.java The content of the returned Data packet is a TLV RibEntry message. To decode it, the example uses the jNDN utility called ProtobufTlv. This works with a .proto definition file: https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/rib-entry-proto.proto Note that ProtobufTlv does not work with the Protobuf wire format. Instead, ProtobufTlv decodes the TLV and creates an in-memory Protobuf RibEntryMessage object that your code can examine to get the field values. The ProtobufTlv utility is very general. You can use it to encode and decode just about any TLV type, if you make the .proto file. Let me know if you have any trouble running the example. Thanks, - Jeff T -------------- next part -------------- An HTML attachment was scrubbed... URL: From jefft0 at remap.ucla.edu Mon Feb 9 17:29:03 2015 From: jefft0 at remap.ucla.edu (Thompson, Jeff) Date: Tue, 10 Feb 2015 01:29:03 +0000 Subject: [Ndn-interest] List of registerPrefix In-Reply-To: References: Message-ID: I updated TestListRib to fetch multiple segments to get the entire response before decoding the RibEntry dataset: https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/TestListRib.java Thanks, - Jeff T From: , Jeff Thompson > Date: Monday, February 9, 2015 at 15:17 To: Junxiao Shi > Cc: Bassem Labib >, "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] List of registerPrefix Hi Junxiao, Yes you are right. Thanks for pointing it out. (I forgot to mention this while I was sending a reply quickly.) The example will only work with a reponse which fits into one Data packet. I can update the example to handle mutiple segments. Thanks, - Jeff T From: Junxiao Shi > Date: Sunday, February 8, 2015 at 19:54 To: Jeff Thompson > Cc: Bassem Labib >, "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] List of registerPrefix Dear folks I need to point out that TestLibRib.java is an incomplete implementation of StatusDataset client requesting RIB dataset. A StatusDataset is segmented, but the example doesn't request all segments. Also, there's no guarantee that segment boundary is between two RibEntry elements. Yours, Junxiao On Sun, Feb 8, 2015 at 7:20 PM, Thompson, Jeff > wrote: Hello Bassem, I added an example to jNDN which sends an interest to /localhost/nfd/rib/list and prints the returned RibEntry message. Please pull the lastest from GitHub. Here is the file: https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/TestListRib.java The content of the returned Data packet is a TLV RibEntry message. To decode it, the example uses the jNDN utility called ProtobufTlv. This works with a .proto definition file: https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/rib-entry-proto.proto Note that ProtobufTlv does not work with the Protobuf wire format. Instead, ProtobufTlv decodes the TLV and creates an in-memory Protobuf RibEntryMessage object that your code can examine to get the field values. The ProtobufTlv utility is very general. You can use it to encode and decode just about any TLV type, if you make the .proto file. Let me know if you have any trouble running the example. Thanks, - Jeff T -------------- next part -------------- An HTML attachment was scrubbed... URL: From bassem.labib at gmail.com Tue Feb 10 12:20:52 2015 From: bassem.labib at gmail.com (Bassem Labib) Date: Tue, 10 Feb 2015 22:20:52 +0200 Subject: [Ndn-interest] List of registerPrefix In-Reply-To: References: Message-ID: Hi Jeff, Thanks for your support, I am using Ubuntu 14.04 as operating system. I will pull the latest version from GitHub and will try it. Thanks, Bassem Labib On Tue, Feb 10, 2015 at 3:29 AM, Thompson, Jeff wrote: > I updated TestListRib to fetch multiple segments to get the entire > response before decoding the RibEntry dataset: > > https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/TestListRib.java > > Thanks, > - Jeff T > > From: , Jeff Thompson > Date: Monday, February 9, 2015 at 15:17 > To: Junxiao Shi > > Cc: Bassem Labib , "ndn-interest at lists.cs.ucla.edu" > > Subject: Re: [Ndn-interest] List of registerPrefix > > Hi Junxiao, > > Yes you are right. Thanks for pointing it out. (I forgot to mention > this while I was sending a reply quickly.) The example will only work with > a reponse which fits into one Data packet. I can update the example to > handle mutiple segments. > > Thanks, > - Jeff T > > From: Junxiao Shi > Date: Sunday, February 8, 2015 at 19:54 > To: Jeff Thompson > Cc: Bassem Labib , "ndn-interest at lists.cs.ucla.edu" > > Subject: Re: [Ndn-interest] List of registerPrefix > > Dear folks > > I need to point out that TestLibRib.java > is > an incomplete implementation of StatusDataset client requesting RIB dataset. > A StatusDataset > is > segmented, but the example doesn't request all segments. > Also, there's no guarantee that segment boundary is between two RibEntry > elements. > > Yours, Junxiao > > > > On Sun, Feb 8, 2015 at 7:20 PM, Thompson, Jeff > wrote: > >> Hello Bassem, >> >> I added an example to jNDN which sends an interest >> to /localhost/nfd/rib/list and prints the returned RibEntry message. Please >> pull the lastest from GitHub. Here is the file: >> >> https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/TestListRib.java >> >> The content of the returned Data packet is a TLV RibEntry message. To >> decode it, the example uses the jNDN utility called ProtobufTlv. This >> works with a .proto definition file: >> >> https://github.com/named-data/jndn/blob/master/examples/src/net/named_data/jndn/tests/rib-entry-proto.proto >> >> Note that ProtobufTlv does not work with the Protobuf wire format. >> Instead, ProtobufTlv decodes the TLV and creates an in-memory Protobuf >> RibEntryMessage object that your code can examine to get the field values. >> The ProtobufTlv utility is very general. You can use it to encode and >> decode just about any TLV type, if you make the .proto file. >> >> Let me know if you have any trouble running the example. >> >> Thanks, >> - Jeff T >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.AbdollahiSabet at mail.sbu.ac.ir Thu Feb 12 14:16:36 2015 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Fri, 13 Feb 2015 01:46:36 +0330 Subject: [Ndn-interest] NDN-friendly Mobility solutions Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> Hello everyone. I've been studying NDN for a couple of months now. For supporting mobility in environments without any clear infrastructure and topology like MANET (VANET in particular), it's been developing like a charm. But as far as I've learned, it's producer-side mobility support in large scales still has some serious challenges, particularly in scenarios like mobile caller-callee. And as "A New Perspective on Mobility Support" has reported, none of the proposed solutions(Proxy based, Rendezvous point based, ...) seems to have a NDN-likely technique. I'm eager to work on it as my B.S thesis. But the problem is, when I look at the ICN workshops, conferences, articles, posters, demos and etc, I cannot find real attempts on this(unless Kite I may say). Not that I've seen for example about Routing or Security. And now I'm wondering: Is it really that clear?! Maybe you can guide me to a vision I don't have. Thanks, Sabet -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlee700 at illinois.edu Thu Feb 12 16:32:59 2015 From: jlee700 at illinois.edu (Lee, Jongdeog) Date: Fri, 13 Feb 2015 00:32:59 +0000 Subject: [Ndn-interest] ndn::Transport::Error? Message-ID: Dear all, Does anybody know reasons of the following error message? Is it related to the size of name? ============================================= terminate called after throwing an instance of 'ndn::Transport::Error' what(): error while connecting to the forwarder Aborted (core dumped) ============================================= Best wishes, Jongdeog Lee (JD) ------------------------------------------------ Ph.D. Student Department of Computer Science University of Illinois at Urbana-Champaign -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Thu Feb 12 16:49:59 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Thu, 12 Feb 2015 16:49:59 -0800 Subject: [Ndn-interest] ndn::Transport::Error? In-Reply-To: References: Message-ID: In you application you should catch std::exception or std::runtime_error. It will provide you more human-friendly error message in this (and other) cases. For example: try { face.processEvents(); } catch (const std::exception& e) { std::cerr << ?ERROR: ? << e.what(); std::endl; } Most likely your app cannot connect to nfd. Is it running? ? Alex > On Feb 12, 2015, at 4:32 PM, Lee, Jongdeog wrote: > > Dear all, > > Does anybody know reasons of the following error message? > Is it related to the size of name? > ============================================= > terminate called after throwing an instance of 'ndn::Transport::Error' > what(): error while connecting to the forwarder > Aborted (core dumped) > ============================================= > > Best wishes, > Jongdeog Lee (JD) > > ------------------------------------------------ > Ph.D. Student > Department of Computer Science > University of Illinois at Urbana-Champaign > _______________________________________________ > 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 jlee700 at illinois.EDU Thu Feb 12 18:04:02 2015 From: jlee700 at illinois.EDU (Lee, Jongdeog) Date: Fri, 13 Feb 2015 02:04:02 +0000 Subject: [Ndn-interest] ndn::Transport::Error? In-Reply-To: References: , Message-ID: Thanks. It is now running! Best, Jongdeog Lee (JD) ------------------------------------------------ Ph.D. Student Department of Computer Science University of Illinois at Urbana-Champaign ________________________________ From: Alex Afanasyev [alexander.afanasyev at ucla.edu] Sent: Thursday, February 12, 2015 6:49 PM To: Lee, Jongdeog Cc: ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] ndn::Transport::Error? In you application you should catch std::exception or std::runtime_error. It will provide you more human-friendly error message in this (and other) cases. For example: try { face.processEvents(); } catch (const std::exception& e) { std::cerr << ?ERROR: ? << e.what(); std::endl; } Most likely your app cannot connect to nfd. Is it running? ? Alex On Feb 12, 2015, at 4:32 PM, Lee, Jongdeog > wrote: Dear all, Does anybody know reasons of the following error message? Is it related to the size of name? ============================================= terminate called after throwing an instance of 'ndn::Transport::Error' what(): error while connecting to the forwarder Aborted (core dumped) ============================================= Best wishes, Jongdeog Lee (JD) ------------------------------------------------ Ph.D. Student Department of Computer Science University of Illinois at Urbana-Champaign _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From lixia at CS.UCLA.EDU Fri Feb 13 08:56:30 2015 From: lixia at CS.UCLA.EDU (Lixia Zhang) Date: Fri, 13 Feb 2015 08:56:30 -0800 Subject: [Ndn-interest] NDN-friendly Mobility solutions In-Reply-To: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> Message-ID: <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> > On Feb 12, 2015, at 2:16 PM, Muhammad Hosain Abdollahi Sabet wrote: > > Hello everyone. > I've been studying NDN for a couple of months now. For supporting mobility in environments without any clear infrastructure and topology like MANET (VANET in particular), it's been developing like a charm. But as far as I've learned, it's producer-side mobility support in large scales still has some serious challenges, particularly in scenarios like mobile caller-callee. And as "A New Perspective on Mobility Support" has reported, none of the proposed solutions(Proxy based, Rendezvous point based, ...) seems to have a NDN-likely technique. I'm eager to work on it as my B.S thesis. But the problem is, when I look at the ICN workshops, conferences, articles, posters, demos and etc, I cannot find real attempts on this(unless Kite I may say). Not that I've seen for example about Routing or Security. And now I'm wondering: Is it really that clear?! Maybe you can guide me to a vision I don't have. > > Thanks, > Sabet Sabet, thanks for your msg. I wonder what you meant by "Is it really that clear?!?. If you are asking whether it is clear that NDN can offer superior mobility support than TCP/IP, then you know the answer is YES, right? If you are asking whether mobile producer solutions have been fully developed: it is still being developed, hence the need for your effort on this problem. We *are* developing solutions, first for specific application scenarios, which help us understand how to provide general solutions. If you are asking for examples of routing solutions: I?m sure you?ve seen NLSR work as an example; we are also actively working on hyperbolic routing as potential long term directly. For security, you may look into recent NDN retreat which focused on security solution development. Lixia From jlee700 at illinois.edu Fri Feb 13 14:33:59 2015 From: jlee700 at illinois.edu (Lee, Jongdeog) Date: Fri, 13 Feb 2015 22:33:59 +0000 Subject: [Ndn-interest] Interest with same name and different exclude? Message-ID: Dear all, Suppose that there are two interest packets with the same name & different exclude. (Interest A: /prefix/postfix.....exclude=a Interest B: /prefix/postfix.....exclude=b) Do routers treat them differently or equally? I tested the simple code, and it seems they are treated as same. Best, Jongdeog Lee (JD) ------------------------------------------------ Ph.D. Student Department of Computer Science University of Illinois at Urbana-Champaign -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Feb 13 14:37:56 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 13 Feb 2015 15:37:56 -0700 Subject: [Ndn-interest] Interest with same name and different exclude? In-Reply-To: References: Message-ID: Hi Jongdeog A standard-conforming router will forward these two Interests separately. When a Data packet comes back that can satisfy both Interests, it will be returned to the requester only once. If you still have questions, please describe how you test the behavior and what leads to conclude that they are treated as same. Yours, Junxiao On Fri, Feb 13, 2015 at 3:33 PM, Lee, Jongdeog wrote: > Dear all, > > Suppose that there are two interest packets with the same name & > different exclude. > (Interest A: /prefix/postfix.....exclude=a > Interest B: /prefix/postfix.....exclude=b) > Do routers treat them differently or equally? > I tested the simple code, and it seems they are treated as same. > > Best, > Jongdeog Lee (JD) > > ------------------------------------------------ > *Ph.D. Student* > *Department of Computer Science* > *University of Illinois at Urbana-Champaign* > > _______________________________________________ > 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 nitinder1369 at iiitd.ac.in Sat Feb 14 02:50:09 2015 From: nitinder1369 at iiitd.ac.in (Nitinder Mohan) Date: Sat, 14 Feb 2015 16:20:09 +0530 Subject: [Ndn-interest] Interest Order Maintaining Message-ID: Hello All! A curious question comes to my mind regarding routing strategy in NDN. Let us assume that there is one consumer and one producer in a network consisting of myriad of routers. If a consumer issues continuous interests for different data packets from the same producer, is it guaranteed that the Interest packets will arrive at producer in the same order as in which they were published? I understand that NDN follows multipath routing and later selects paths from its PIT entry according to performance of returning data. But wouldn't consecutive interests be sent on the same interface presuming there is no change in the network. Thanks and Regards Nitinder Mohan MTech (CE) IIIT Delhi http://home.iiitd.edu.in/~nitinder1369/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Sat Feb 14 05:26:31 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 14 Feb 2015 06:26:31 -0700 Subject: [Ndn-interest] Interest Order Maintaining In-Reply-To: References: Message-ID: Hi Nitinder NDN network does not guarantee in order delivery. An Interest could also be delivered to the producer multiple times. It's advised that apps are designed to not require in order delivery. If an app requires in order Interest delivery, one choice is to implement stop and wait: consumer sends the next Interest after previous ones are answered. Yours, Junxiao On Feb 14, 2015 3:50 AM, "Nitinder Mohan" wrote: > Hello All! > > A curious question comes to my mind regarding routing strategy in NDN. > > Let us assume that there is one consumer and one producer in a network > consisting of myriad of routers. If a consumer issues continuous interests > for different data packets from the same producer, is it guaranteed that > the Interest packets will arrive at producer in the same order as in which > they were published? > > I understand that NDN follows multipath routing and later selects paths > from its PIT entry according to performance of returning data. But wouldn't > consecutive interests be sent on the same interface presuming there is no > change in the network. > > Thanks and Regards > > Nitinder Mohan > MTech (CE) IIIT Delhi > http://home.iiitd.edu.in/~nitinder1369/ > > _______________________________________________ > 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 nitinder1369 at iiitd.ac.in Sat Feb 14 05:35:32 2015 From: nitinder1369 at iiitd.ac.in (Nitinder Mohan) Date: Sat, 14 Feb 2015 19:05:32 +0530 Subject: [Ndn-interest] Interest Order Maintaining In-Reply-To: References: Message-ID: Hi Junxiao, Wouldn't this hamper working of multimedia applications that require live streaming of data? If the interest for next chunk of data has to wait until the earlier chunk has arrived, wouldn't this slow down data transfer rate considerably? Thanks and Regards Nitinder Mohan MTech (CE) IIIT Delhi http://home.iiitd.edu.in/~nitinder1369/ On Sat, Feb 14, 2015 at 6:56 PM, Junxiao Shi wrote: > Hi Nitinder > > NDN network does not guarantee in order delivery. An Interest could also > be delivered to the producer multiple times. > > It's advised that apps are designed to not require in order delivery. > > If an app requires in order Interest delivery, one choice is to implement > stop and wait: consumer sends the next Interest after previous ones are > answered. > > Yours, Junxiao > On Feb 14, 2015 3:50 AM, "Nitinder Mohan" > wrote: > >> Hello All! >> >> A curious question comes to my mind regarding routing strategy in NDN. >> >> Let us assume that there is one consumer and one producer in a network >> consisting of myriad of routers. If a consumer issues continuous interests >> for different data packets from the same producer, is it guaranteed that >> the Interest packets will arrive at producer in the same order as in which >> they were published? >> >> I understand that NDN follows multipath routing and later selects paths >> from its PIT entry according to performance of returning data. But wouldn't >> consecutive interests be sent on the same interface presuming there is no >> change in the network. >> >> Thanks and Regards >> >> Nitinder Mohan >> MTech (CE) IIIT Delhi >> http://home.iiitd.edu.in/~nitinder1369/ >> >> _______________________________________________ >> 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 Sat Feb 14 07:06:05 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 14 Feb 2015 08:06:05 -0700 Subject: [Ndn-interest] Interest Order Maintaining In-Reply-To: References: Message-ID: Hi Nitinder Live video streaming can be designed to not require in-order delivery. Interests can be delivered in any order. Received Data are buffered, and played out in-order. See http://named-data.net/publications/e-letter-july13_page6/ Yours, Junxiao On Sat, Feb 14, 2015 at 6:35 AM, Nitinder Mohan wrote: > Hi Junxiao, > > Wouldn't this hamper working of multimedia applications that require live > streaming of data? If the interest for next chunk of data has to wait until > the earlier chunk has arrived, wouldn't this slow down data transfer rate > considerably? > > Thanks and Regards > > Nitinder Mohan > MTech (CE) IIIT Delhi > http://home.iiitd.edu.in/~nitinder1369/ > > On Sat, Feb 14, 2015 at 6:56 PM, Junxiao Shi > wrote: > >> Hi Nitinder >> >> NDN network does not guarantee in order delivery. An Interest could also >> be delivered to the producer multiple times. >> >> It's advised that apps are designed to not require in order delivery. >> >> If an app requires in order Interest delivery, one choice is to implement >> stop and wait: consumer sends the next Interest after previous ones are >> answered. >> >> Yours, Junxiao >> On Feb 14, 2015 3:50 AM, "Nitinder Mohan" >> wrote: >> >>> Hello All! >>> >>> A curious question comes to my mind regarding routing strategy in NDN. >>> >>> Let us assume that there is one consumer and one producer in a network >>> consisting of myriad of routers. If a consumer issues continuous interests >>> for different data packets from the same producer, is it guaranteed that >>> the Interest packets will arrive at producer in the same order as in which >>> they were published? >>> >>> I understand that NDN follows multipath routing and later selects paths >>> from its PIT entry according to performance of returning data. But wouldn't >>> consecutive interests be sent on the same interface presuming there is no >>> change in the network. >>> >>> Thanks and Regards >>> >>> Nitinder Mohan >>> MTech (CE) IIIT Delhi >>> http://home.iiitd.edu.in/~nitinder1369/ >>> >>> _______________________________________________ >>> 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 christos at cs.colostate.edu Sat Feb 14 07:20:42 2015 From: christos at cs.colostate.edu (Christos Papadopoulos) Date: Sat, 14 Feb 2015 08:20:42 -0700 Subject: [Ndn-interest] Interest Order Maintaining In-Reply-To: References: Message-ID: <54DF67CA.8070504@cs.colostate.edu> On 02/14/2015 06:35 AM, Nitinder Mohan wrote: > Hi Junxiao, > > Wouldn't this hamper working of multimedia applications that require > live streaming of data? If the interest for next chunk of data has to > wait until the earlier chunk has arrived, wouldn't this slow down data > transfer rate considerably? Just like IP, you can build that functionality on top of the basic interest/data exchange. With IP you typically use a playout buffer to ensure smooth playback. The same buffer is typically used for reassembly if your transport is UDP. I suspect that a well-designed UDP/IP multimedia application that is mindful of out-of-order delivery would not be hard to port to NDN. Christos. > > Thanks and Regards > > Nitinder Mohan > MTech (CE) IIIT Delhi > http://home.iiitd.edu.in/~nitinder1369/ > > On Sat, Feb 14, 2015 at 6:56 PM, Junxiao Shi > > wrote: > > Hi Nitinder > > NDN network does not guarantee in order delivery. An Interest could > also be delivered to the producer multiple times. > > It's advised that apps are designed to not require in order delivery. > > If an app requires in order Interest delivery, one choice is to > implement stop and wait: consumer sends the next Interest after > previous ones are answered. > > Yours, Junxiao > > On Feb 14, 2015 3:50 AM, "Nitinder Mohan" > wrote: > > Hello All! > > A curious question comes to my mind regarding routing strategy > in NDN. > > Let us assume that there is one consumer and one producer in a > network consisting of myriad of routers. If a consumer issues > continuous interests for different data packets from the same > producer, is it guaranteed that the Interest packets will arrive > at producer in the same order as in which they were published? > > I understand that NDN follows multipath routing and later > selects paths from its PIT entry according to performance of > returning data. But wouldn't consecutive interests be sent on > the same interface presuming there is no change in the network. > > Thanks and Regards > > Nitinder Mohan > MTech (CE) IIIT Delhi > http://home.iiitd.edu.in/~nitinder1369/ > > _______________________________________________ > 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 shijunxiao at email.arizona.edu Sat Feb 14 07:21:08 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Sat, 14 Feb 2015 08:21:08 -0700 Subject: [Ndn-interest] Interest Order Maintaining In-Reply-To: References: Message-ID: Hi Nitinder NDN network does not guarantee in order delivery. An Interest could also be delivered to the producer multiple times. The end consumer, either implemented in app or in library, should handle out-of-order packets. This situation is no different from IP. Yours, Junxiao This is a correction to a previous answer. It replaces all prior answers. On Sat, Feb 14, 2015 at 3:50 AM, Nitinder Mohan wrote: > Hello All! > > A curious question comes to my mind regarding routing strategy in NDN. > > Let us assume that there is one consumer and one producer in a network > consisting of myriad of routers. If a consumer issues continuous interests > for different data packets from the same producer, is it guaranteed that > the Interest packets will arrive at producer in the same order as in which > they were published? > > I understand that NDN follows multipath routing and later selects paths > from its PIT entry according to performance of returning data. But wouldn't > consecutive interests be sent on the same interface presuming there is no > change in the network. > > Thanks and Regards > > Nitinder Mohan > MTech (CE) IIIT Delhi > http://home.iiitd.edu.in/~nitinder1369/ > > _______________________________________________ > 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 Sat Feb 14 08:03:45 2015 From: jburke at remap.UCLA.EDU (Burke, Jeff) Date: Sat, 14 Feb 2015 16:03:45 +0000 Subject: [Ndn-interest] Interest Order Maintaining In-Reply-To: Message-ID: As Junxiao says, reordering of data is necessary and, for example, is handled for video (and audio) in both NDNVideo and ndnrtc. NDNVideo has a longer playout buffer and thus can handle more out of order packets without impacting playback; ndnrtc is designed with a small buffer for real-time conversations but also handles reordering of data packets. (In these and many other applications, interest retransmissions in the case of dropped packets also have to be handled.) In these apps, interest reordering is not performed at the producer; it is simpler to just publish data to an application memory cache (done in ndnrtc) or ndn repository (done in NDNVideo), and let that store respond to whatever interests come in, regardless of ordering. So, only the consumer has to reorder data. This might not be the case in some applications that use Interest for control and might worried about the time the interests were issued at the source. There is active work to generalize APIs that handle ordering and retransmission, e.g., Ilya Moiseenko's work presented at NDNComm 2014. Jeff From: Junxiao Shi > Date: Sat, 14 Feb 2015 08:21:08 -0700 To: Nitinder Mohan > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Interest Order Maintaining Hi Nitinder NDN network does not guarantee in order delivery. An Interest could also be delivered to the producer multiple times. The end consumer, either implemented in app or in library, should handle out-of-order packets. This situation is no different from IP. Yours, Junxiao This is a correction to a previous answer. It replaces all prior answers. On Sat, Feb 14, 2015 at 3:50 AM, Nitinder Mohan > wrote: Hello All! A curious question comes to my mind regarding routing strategy in NDN. Let us assume that there is one consumer and one producer in a network consisting of myriad of routers. If a consumer issues continuous interests for different data packets from the same producer, is it guaranteed that the Interest packets will arrive at producer in the same order as in which they were published? I understand that NDN follows multipath routing and later selects paths from its PIT entry according to performance of returning data. But wouldn't consecutive interests be sent on the same interface presuming there is no change in the network. Thanks and Regards Nitinder Mohan MTech (CE) IIIT Delhi http://home.iiitd.edu.in/~nitinder1369/ _______________________________________________ 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 nitinder1369 at iiitd.ac.in Sat Feb 14 08:33:15 2015 From: nitinder1369 at iiitd.ac.in (Nitinder Mohan) Date: Sat, 14 Feb 2015 22:03:15 +0530 Subject: [Ndn-interest] Interest Order Maintaining In-Reply-To: References: Message-ID: Thank you all for your comments. It is much clearer to me now. On a completely unrelated topic, Dr. Burke I am very intrigued by NDNVideo and ndnrtc work. How are the packets reorganized at the consumer end? Does the data packets have inherent sequence numbers or are they shared according to their segmentation numbers? It would be extremely helpful of you if you can point me to an appropriate publication related to it. Thanks and Regards Nitinder Mohan MTech (CE) IIIT Delhi http://home.iiitd.edu.in/~nitinder1369/ On Sat, Feb 14, 2015 at 9:33 PM, Burke, Jeff wrote: > > As Junxiao says, reordering of data is necessary and, for example, is > handled for video (and audio) in both NDNVideo > and ndnrtc > . NDNVideo has a longer playout buffer > and thus can handle more out of order packets without impacting playback; > ndnrtc is designed with a small buffer for real-time conversations but > also handles reordering of data packets. (In these and many other > applications, interest retransmissions in the case of dropped packets also > have to be handled.) > > In these apps, interest reordering is not performed at the producer; it > is simpler to just publish data to an application memory cache (done in > ndnrtc) or ndn repository (done in NDNVideo), and let that store respond to > whatever interests come in, regardless of ordering. So, only the consumer > has to reorder data. This might not be the case in some applications that > use Interest for control and might worried about the time the interests > were issued at the source. > > There is active work to generalize APIs that handle ordering and > retransmission, e.g., Ilya Moiseenko's work presented at NDNComm 2014 > . > > Jeff > > From: Junxiao Shi > Date: Sat, 14 Feb 2015 08:21:08 -0700 > To: Nitinder Mohan > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] Interest Order Maintaining > > Hi Nitinder > > NDN network does not guarantee in order delivery. An Interest could also > be delivered to the producer multiple times. > The end consumer, either implemented in app or in library, should handle > out-of-order packets. This situation is no different from IP. > > Yours, Junxiao > This is a correction to a previous answer. It replaces all prior answers. > > On Sat, Feb 14, 2015 at 3:50 AM, Nitinder Mohan > wrote: > >> Hello All! >> >> A curious question comes to my mind regarding routing strategy in NDN. >> >> Let us assume that there is one consumer and one producer in a network >> consisting of myriad of routers. If a consumer issues continuous interests >> for different data packets from the same producer, is it guaranteed that >> the Interest packets will arrive at producer in the same order as in which >> they were published? >> >> I understand that NDN follows multipath routing and later selects paths >> from its PIT entry according to performance of returning data. But wouldn't >> consecutive interests be sent on the same interface presuming there is no >> change in the network. >> >> Thanks and Regards >> >> Nitinder Mohan >> MTech (CE) IIIT Delhi >> http://home.iiitd.edu.in/~nitinder1369/ >> >> _______________________________________________ >> 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 M.AbdollahiSabet at mail.sbu.ac.ir Sat Feb 14 09:22:25 2015 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Sat, 14 Feb 2015 20:52:25 +0330 Subject: [Ndn-interest] NDN-friendly Mobility solutions References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> Thank you so much for answering. Actually it struck my mind that "it" is unclear, which I'm sorry for the ambiguity. The second one was the closest one. I meant: "Is the solution for producer-side mobility clear enough that there hasn't been real attempt about it? I'll be absolutely glad to help. ?As far as I understand we have another paradigm shifting again in some mobility application scenarios like mobile caller-callee. NDN shifts networking from host-centric(point to point) to a content-centric architecture. And now we want to make point to point connection overlay of NDN. Right? So I think using some IP-like producer mobility solutions is not avoidable. On the other hand some of NDN features like being broadcast finendly which is referred to in "A New Perspective in Mobility Support'' as a suggestion, isn't practical in large scale because of producing heavy overhead of controlling data(specially in hard-state mode). Furthermore, hierarchical naming brings some location dependency, and maybe we need some conventions in this field, in which network can approximate location of endpoint while pinpointing location of endpoint can be postponed to last steps. I just listed some of the challenges I faced till now. I'll be grateful to know your opinion about them. Thanks again, Sabet -----Original Message----- From: Lixia Zhang [mailto:lixia at cs.ucla.edu] Sent: Fri 2/13/2015 8:26 PM To: Muhammad Hosain Abdollahi Sabet Cc: ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions > On Feb 12, 2015, at 2:16 PM, Muhammad Hosain Abdollahi Sabet wrote: > > Hello everyone. > I've been studying NDN for a couple of months now. For supporting mobility in environments without any clear infrastructure and topology like MANET (VANET in particular), it's been developing like a charm. But as far as I've learned, it's producer-side mobility support in large scales still has some serious challenges, particularly in scenarios like mobile caller-callee. And as "A New Perspective on Mobility Support" has reported, none of the proposed solutions(Proxy based, Rendezvous point based, ...) seems to have a NDN-likely technique. I'm eager to work on it as my B.S thesis. But the problem is, when I look at the ICN workshops, conferences, articles, posters, demos and etc, I cannot find real attempts on this(unless Kite I may say). Not that I've seen for example about Routing or Security. And now I'm wondering: Is it really that clear?! Maybe you can guide me to a vision I don't have. > > Thanks, > Sabet Sabet, thanks for your msg. I wonder what you meant by "Is it really that clear?!". If you are asking whether it is clear that NDN can offer superior mobility support than TCP/IP, then you know the answer is YES, right? If you are asking whether mobile producer solutions have been fully developed: it is still being developed, hence the need for your effort on this problem. We *are* developing solutions, first for specific application scenarios, which help us understand how to provide general solutions. If you are asking for examples of routing solutions: I'm sure you've seen NLSR work as an example; we are also actively working on hyperbolic routing as potential long term directly. For security, you may look into recent NDN retreat which focused on security solution development. Lixia -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Sat Feb 14 16:17:55 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Sun, 15 Feb 2015 00:17:55 +0000 Subject: [Ndn-interest] NDN-friendly Mobility solutions References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> Message-ID: On Sat Feb 14 2015 at 9:26:50 AM Muhammad Hosain Abdollahi Sabet < M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > Thank you so much for answering. > Actually it struck my mind that "it" is unclear, which I'm sorry for the > ambiguity. The second one was the closest one. I meant: "Is the solution > for producer-side mobility clear enough that there hasn't been real attempt > about it? > I'll be absolutely glad to help. ?As far as I understand we have another > paradigm shifting again in some mobility application scenarios like mobile > caller-callee. NDN shifts networking from host-centric(point to point) to a > content-centric architecture. And now we want to make point to point > connection overlay of NDN. Right? > Not sure why you want to make point-to-point connection over NDN. Is it a requirement from specific application in your mind? NDN shifts away from the P2P connection model and therefore provides new opportunity for better mobility support. Perhaps it is more efficient to design your application in the NDN model (in which case some mobility issue may disappear automatically) than to fit the old model into the new architecture. > So I think using some IP-like producer mobility solutions is not > avoidable. On the other hand some of NDN features like being broadcast > finendly which is referred to in "A New Perspective in Mobility Support'' > as a suggestion, isn't practical in large scale because of producing heavy > overhead of controlling data(specially in hard-state mode). > Broadcast is impractical for large scale IP network. But NDN has a smarter forwarding plain which opens possibility for intelligent broadcast/multicast using self-learning path selection and traffic reduction. Different mobility solutions are designed for different application scenarios. In some extreme cases where the network is so dynamic that it is impossible to maintain a stable topology, broadcast/multicast may be the only choice. > Furthermore, hierarchical naming brings some location dependency, > It is not that hierarchical naming brings location dependency. Any identifier that is used in routing and forwarding will cause location dependency. That's why people invented the concept of Locator/ID separation, which is mentioned in the mobility TR. The "forwarding hint" is one way to implement that in NDN. Wentao > and maybe we need some conventions in this field, in which network can > approximate location of endpoint while pinpointing location of endpoint can > be postponed to last steps. > I just listed some of the challenges I faced till now. I'll be grateful to > know your opinion about them. > > Thanks again, > Sabet > > > > > -----Original Message----- > From: Lixia Zhang [mailto:lixia at cs.ucla.edu ] > Sent: Fri 2/13/2015 8:26 PM > To: Muhammad Hosain Abdollahi Sabet > Cc: ndn-interest at lists.cs.ucla.edu > Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions > > > > On Feb 12, 2015, at 2:16 PM, Muhammad Hosain Abdollahi Sabet < > M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > > > > Hello everyone. > > I've been studying NDN for a couple of months now. For supporting > mobility in environments without any clear infrastructure and topology like > MANET (VANET in particular), it's been developing like a charm. But as far > as I've learned, it's producer-side mobility support in large scales still > has some serious challenges, particularly in scenarios like mobile > caller-callee. And as "A New Perspective on Mobility Support" has reported, > none of the proposed solutions(Proxy based, Rendezvous point based, ...) > seems to have a NDN-likely technique. I'm eager to work on it as my B.S > thesis. But the problem is, when I look at the ICN workshops, conferences, > articles, posters, demos and etc, I cannot find real attempts on > this(unless Kite I may say). Not that I've seen for example about Routing > or Security. And now I'm wondering: Is it really that clear?! Maybe you can > guide me to a vision I don't have. > > > > Thanks, > > Sabet > > Sabet, > > thanks for your msg. I wonder what you meant by "Is it really that > clear?!". > If you are asking whether it is clear that NDN can offer superior mobility > support than TCP/IP, then you know the answer is YES, right? > If you are asking whether mobile producer solutions have been fully > developed: it is still being developed, hence the need for your effort on > this problem. We *are* developing solutions, first for specific > application scenarios, which help us understand how to provide general > solutions. > If you are asking for examples of routing solutions: I'm sure you've seen > NLSR work as an example; we are also actively working on hyperbolic routing > as potential long term directly. > For security, you may look into recent NDN retreat which focused on > security solution development. > > Lixia > > > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.AbdollahiSabet at mail.sbu.ac.ir Sun Feb 15 03:45:41 2015 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Sun, 15 Feb 2015 15:15:41 +0330 Subject: [Ndn-interest] NDN-friendly Mobility solutions References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2930@m-pdc.sbu.ac.ir> Good point! I agree that NDN supports subscriber mobility in it's nature and as you said most of mobility issues in subscriber-side scenarios disappear automatically. But what about some producer ones? As an example, the application scenario we are talking about could be voice/video chat when both caller and callee are mobile. How could we consider it in a non-P2P model? Could you please guide me to find about possibility for intelligent broadcast/multicast using self-learning path selection ? -----Original Message----- From: Wentao Shang [mailto:wentaoshang at gmail.com] Sent: Sun 2/15/2015 3:47 AM To: Muhammad Hosain Abdollahi Sabet; Lixia Zhang; ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions On Sat Feb 14 2015 at 9:26:50 AM Muhammad Hosain Abdollahi Sabet < M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > Thank you so much for answering. > Actually it struck my mind that "it" is unclear, which I'm sorry for the > ambiguity. The second one was the closest one. I meant: "Is the solution > for producer-side mobility clear enough that there hasn't been real attempt > about it? > I'll be absolutely glad to help. ?As far as I understand we have another > paradigm shifting again in some mobility application scenarios like mobile > caller-callee. NDN shifts networking from host-centric(point to point) to a > content-centric architecture. And now we want to make point to point > connection overlay of NDN. Right? > Not sure why you want to make point-to-point connection over NDN. Is it a requirement from specific application in your mind? NDN shifts away from the P2P connection model and therefore provides new opportunity for better mobility support. Perhaps it is more efficient to design your application in the NDN model (in which case some mobility issue may disappear automatically) than to fit the old model into the new architecture. > So I think using some IP-like producer mobility solutions is not > avoidable. On the other hand some of NDN features like being broadcast > finendly which is referred to in "A New Perspective in Mobility Support'' > as a suggestion, isn't practical in large scale because of producing heavy > overhead of controlling data(specially in hard-state mode). > Broadcast is impractical for large scale IP network. But NDN has a smarter forwarding plain which opens possibility for intelligent broadcast/multicast using self-learning path selection and traffic reduction. Different mobility solutions are designed for different application scenarios. In some extreme cases where the network is so dynamic that it is impossible to maintain a stable topology, broadcast/multicast may be the only choice. > Furthermore, hierarchical naming brings some location dependency, > It is not that hierarchical naming brings location dependency. Any identifier that is used in routing and forwarding will cause location dependency. That's why people invented the concept of Locator/ID separation, which is mentioned in the mobility TR. The "forwarding hint" is one way to implement that in NDN. Wentao > and maybe we need some conventions in this field, in which network can > approximate location of endpoint while pinpointing location of endpoint can > be postponed to last steps. > I just listed some of the challenges I faced till now. I'll be grateful to > know your opinion about them. > > Thanks again, > Sabet > > > > > -----Original Message----- > From: Lixia Zhang [mailto:lixia at cs.ucla.edu ] > Sent: Fri 2/13/2015 8:26 PM > To: Muhammad Hosain Abdollahi Sabet > Cc: ndn-interest at lists.cs.ucla.edu > Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions > > > > On Feb 12, 2015, at 2:16 PM, Muhammad Hosain Abdollahi Sabet < > M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > > > > Hello everyone. > > I've been studying NDN for a couple of months now. For supporting > mobility in environments without any clear infrastructure and topology like > MANET (VANET in particular), it's been developing like a charm. But as far > as I've learned, it's producer-side mobility support in large scales still > has some serious challenges, particularly in scenarios like mobile > caller-callee. And as "A New Perspective on Mobility Support" has reported, > none of the proposed solutions(Proxy based, Rendezvous point based, ...) > seems to have a NDN-likely technique. I'm eager to work on it as my B.S > thesis. But the problem is, when I look at the ICN workshops, conferences, > articles, posters, demos and etc, I cannot find real attempts on > this(unless Kite I may say). Not that I've seen for example about Routing > or Security. And now I'm wondering: Is it really that clear?! Maybe you can > guide me to a vision I don't have. > > > > Thanks, > > Sabet > > Sabet, > > thanks for your msg. I wonder what you meant by "Is it really that > clear?!". > If you are asking whether it is clear that NDN can offer superior mobility > support than TCP/IP, then you know the answer is YES, right? > If you are asking whether mobile producer solutions have been fully > developed: it is still being developed, hence the need for your effort on > this problem. We *are* developing solutions, first for specific > application scenarios, which help us understand how to provide general > solutions. > If you are asking for examples of routing solutions: I'm sure you've seen > NLSR work as an example; we are also actively working on hyperbolic routing > as potential long term directly. > For security, you may look into recent NDN retreat which focused on > security solution development. > > Lixia > > > > _______________________________________________ > 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 wentaoshang at gmail.com Sun Feb 15 11:18:55 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Sun, 15 Feb 2015 19:18:55 +0000 Subject: [Ndn-interest] NDN-friendly Mobility solutions References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2930@m-pdc.sbu.ac.ir> Message-ID: While any solution must be based on the specific application scenario, there are still some general guidelines that you may consider: 1/ Producer mobility is hard because the consumer has to shoot Interest to a moving target. Therefore the principle is to find something invariant and use that as an indirection, which is essentially the same idea as locator/id separation. 2/ One way to do that is to directly apply the LISP concept to the NDN network: you can assign a location-independent name to the producer and let the producer register its current location to a general mapping system (e.g, NDNS); then the consumer can send Interest to the producer's latest location using either Interest encapsulation or forwarding hint. This design is useful if your application must enforce P2P communication (e.g., if you want to send control commands to a specific sensor on a plane that is flying from LAX to JFK). 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as indirection: you can have your producer publish its data to a well-known location, such as an NDN repo, so that the consumer can fetch data from the repo instead of talking to the producer directly. This design also applies to sensor networks where the producer has limited storage capacity and/or low duty-cycle so that it must offload the data storage task to a more powerful device. 4/ I remember Prof. Lixia showed us some slides in her class about the idea of NDN routing via self-learning. The key idea is to utilize NDN's stateful forwarding plain to estimate the validity of a route on the fly. Unfortunately I couldn't remember any reference for that work. Hope this may be helpful to your research. Wentao On Sun Feb 15 2015 at 3:47:47 AM Muhammad Hosain Abdollahi Sabet < M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > Good point! I agree that NDN supports subscriber mobility in it's nature > and as you said most of mobility issues in subscriber-side scenarios > disappear automatically. But what about some producer ones? As an example, > the application scenario we are talking about could be voice/video chat > when both caller and callee are mobile. How could we consider it in a > non-P2P model? > > Could you please guide me to find about possibility for intelligent > broadcast/multicast using self-learning path selection ? > > > > > -----Original Message----- > From: Wentao Shang [mailto:wentaoshang at gmail.com ] > Sent: Sun 2/15/2015 3:47 AM > To: Muhammad Hosain Abdollahi Sabet; Lixia Zhang; > ndn-interest at lists.cs.ucla.edu > Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions > > On Sat Feb 14 2015 at 9:26:50 AM Muhammad Hosain Abdollahi Sabet < > M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > > > Thank you so much for answering. > > Actually it struck my mind that "it" is unclear, which I'm sorry for the > > ambiguity. The second one was the closest one. I meant: "Is the solution > > for producer-side mobility clear enough that there hasn't been real > attempt > > about it? > > > I'll be absolutely glad to help. ?As far as I understand we have another > > > > paradigm shifting again in some mobility application scenarios like > mobile > > caller-callee. NDN shifts networking from host-centric(point to point) > to a > > content-centric architecture. And now we want to make point to point > > connection overlay of NDN. Right? > > > Not sure why you want to make point-to-point connection over NDN. Is it a > requirement from specific application in your mind? NDN shifts away from > the P2P connection model and therefore provides new opportunity for better > mobility support. Perhaps it is more efficient to design your application > in the NDN model (in which case some mobility issue may disappear > automatically) than to fit the old model into the new architecture. > > > > So I think using some IP-like producer mobility solutions is not > > avoidable. On the other hand some of NDN features like being broadcast > > finendly which is referred to in "A New Perspective in Mobility Support'' > > as a suggestion, isn't practical in large scale because of producing > heavy > > overhead of controlling data(specially in hard-state mode). > > > Broadcast is impractical for large scale IP network. But NDN has a smarter > forwarding plain which opens possibility for intelligent > broadcast/multicast using self-learning path selection and traffic > reduction. > > Different mobility solutions are designed for different application > scenarios. In some extreme cases where the network is so dynamic that it is > impossible to maintain a stable topology, broadcast/multicast may be the > only choice. > > > > Furthermore, hierarchical naming brings some location dependency, > > > It is not that hierarchical naming brings location dependency. Any > identifier that is used in routing and forwarding will cause location > dependency. That's why people invented the concept of Locator/ID > separation, which is mentioned in the mobility TR. The "forwarding hint" is > one way to implement that in NDN. > > Wentao > > > > and maybe we need some conventions in this field, in which network can > > approximate location of endpoint while pinpointing location of endpoint > can > > be postponed to last steps. > > I just listed some of the challenges I faced till now. I'll be grateful > to > > know your opinion about them. > > > > Thanks again, > > Sabet > > > > > > > > > > -----Original Message----- > > > From: Lixia Zhang [mailto:lixia at cs.ucla.edu < > lixia at cs.ucla.edu>] > > Sent: Fri 2/13/2015 8:26 PM > > To: Muhammad Hosain Abdollahi Sabet > > Cc: ndn-interest at lists.cs.ucla.edu > > Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions > > > > > > > On Feb 12, 2015, at 2:16 PM, Muhammad Hosain Abdollahi Sabet < > > M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > > > > > > Hello everyone. > > > I've been studying NDN for a couple of months now. For supporting > > mobility in environments without any clear infrastructure and topology > like > > MANET (VANET in particular), it's been developing like a charm. But as > far > > as I've learned, it's producer-side mobility support in large scales > still > > has some serious challenges, particularly in scenarios like mobile > > caller-callee. And as "A New Perspective on Mobility Support" has > reported, > > none of the proposed solutions(Proxy based, Rendezvous point based, ...) > > seems to have a NDN-likely technique. I'm eager to work on it as my B.S > > thesis. But the problem is, when I look at the ICN workshops, > conferences, > > articles, posters, demos and etc, I cannot find real attempts on > > this(unless Kite I may say). Not that I've seen for example about Routing > > or Security. And now I'm wondering: Is it really that clear?! Maybe you > can > > guide me to a vision I don't have. > > > > > > Thanks, > > > Sabet > > > > Sabet, > > > > thanks for your msg. I wonder what you meant by "Is it really that > > clear?!". > > If you are asking whether it is clear that NDN can offer superior > mobility > > support than TCP/IP, then you know the answer is YES, right? > > If you are asking whether mobile producer solutions have been fully > > developed: it is still being developed, hence the need for your effort on > > this problem. We *are* developing solutions, first for specific > > application scenarios, which help us understand how to provide general > > solutions. > > If you are asking for examples of routing solutions: I'm sure you've seen > > NLSR work as an example; we are also actively working on hyperbolic > routing > > as potential long term directly. > > For security, you may look into recent NDN retreat which focused on > > security solution development. > > > > Lixia > > > > > > > > _______________________________________________ > > Ndn-interest mailing list > > Ndn-interest at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tailinchu at gmail.com Sun Feb 15 12:09:53 2015 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Sun, 15 Feb 2015 12:09:53 -0800 Subject: [Ndn-interest] NDN-friendly Mobility solutions In-Reply-To: References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2930@m-pdc.sbu.ac.ir> Message-ID: > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as indirection: you can have your producer publish its data to a well-known location, such as an NDN repo, so that the consumer can fetch data from the repo instead of talking to the producer directly. I think there is something missing in this design. When producer needs to send its data to the repo, the repo becomes the client. As a result, this looks like a recursive algorithm without base case :) On Sun, Feb 15, 2015 at 11:18 AM, Wentao Shang wrote: > While any solution must be based on the specific application scenario, there > are still some general guidelines that you may consider: > > 1/ Producer mobility is hard because the consumer has to shoot Interest to a > moving target. Therefore the principle is to find something invariant and > use that as an indirection, which is essentially the same idea as locator/id > separation. > > 2/ One way to do that is to directly apply the LISP concept to the NDN > network: you can assign a location-independent name to the producer and let > the producer register its current location to a general mapping system (e.g, > NDNS); then the consumer can send Interest to the producer's latest location > using either Interest encapsulation or forwarding hint. > > This design is useful if your application must enforce P2P communication > (e.g., if you want to send control commands to a specific sensor on a plane > that is flying from LAX to JFK). > > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as > indirection: you can have your producer publish its data to a well-known > location, such as an NDN repo, so that the consumer can fetch data from the > repo instead of talking to the producer directly. > > This design also applies to sensor networks where the producer has limited > storage capacity and/or low duty-cycle so that it must offload the data > storage task to a more powerful device. > > 4/ I remember Prof. Lixia showed us some slides in her class about the idea > of NDN routing via self-learning. The key idea is to utilize NDN's stateful > forwarding plain to estimate the validity of a route on the fly. > Unfortunately I couldn't remember any reference for that work. > > Hope this may be helpful to your research. > > Wentao > > > On Sun Feb 15 2015 at 3:47:47 AM Muhammad Hosain Abdollahi Sabet > wrote: >> >> Good point! I agree that NDN supports subscriber mobility in it's nature >> and as you said most of mobility issues in subscriber-side scenarios >> disappear automatically. But what about some producer ones? As an example, >> the application scenario we are talking about could be voice/video chat when >> both caller and callee are mobile. How could we consider it in a non-P2P >> model? >> >> Could you please guide me to find about possibility for intelligent >> broadcast/multicast using self-learning path selection ? >> >> >> >> >> -----Original Message----- >> From: Wentao Shang [mailto:wentaoshang at gmail.com] >> Sent: Sun 2/15/2015 3:47 AM >> To: Muhammad Hosain Abdollahi Sabet; Lixia Zhang; >> ndn-interest at lists.cs.ucla.edu >> Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions >> >> On Sat Feb 14 2015 at 9:26:50 AM Muhammad Hosain Abdollahi Sabet < >> M.AbdollahiSabet at mail.sbu.ac.ir> wrote: >> >> > Thank you so much for answering. >> > Actually it struck my mind that "it" is unclear, which I'm sorry for the >> > ambiguity. The second one was the closest one. I meant: "Is the solution >> > for producer-side mobility clear enough that there hasn't been real >> > attempt >> > about it? >> >> > I'll be absolutely glad to help. ?As far as I understand we have another >> >> >> > paradigm shifting again in some mobility application scenarios like >> > mobile >> > caller-callee. NDN shifts networking from host-centric(point to point) >> > to a >> > content-centric architecture. And now we want to make point to point >> > connection overlay of NDN. Right? >> > >> Not sure why you want to make point-to-point connection over NDN. Is it a >> requirement from specific application in your mind? NDN shifts away from >> the P2P connection model and therefore provides new opportunity for better >> mobility support. Perhaps it is more efficient to design your application >> in the NDN model (in which case some mobility issue may disappear >> automatically) than to fit the old model into the new architecture. >> >> >> > So I think using some IP-like producer mobility solutions is not >> > avoidable. On the other hand some of NDN features like being broadcast >> > finendly which is referred to in "A New Perspective in Mobility >> > Support'' >> > as a suggestion, isn't practical in large scale because of producing >> > heavy >> > overhead of controlling data(specially in hard-state mode). >> > >> Broadcast is impractical for large scale IP network. But NDN has a smarter >> forwarding plain which opens possibility for intelligent >> broadcast/multicast using self-learning path selection and traffic >> reduction. >> >> Different mobility solutions are designed for different application >> scenarios. In some extreme cases where the network is so dynamic that it >> is >> impossible to maintain a stable topology, broadcast/multicast may be the >> only choice. >> >> >> > Furthermore, hierarchical naming brings some location dependency, >> > >> It is not that hierarchical naming brings location dependency. Any >> identifier that is used in routing and forwarding will cause location >> dependency. That's why people invented the concept of Locator/ID >> separation, which is mentioned in the mobility TR. The "forwarding hint" >> is >> one way to implement that in NDN. >> >> Wentao >> >> >> > and maybe we need some conventions in this field, in which network can >> > approximate location of endpoint while pinpointing location of endpoint >> > can >> > be postponed to last steps. >> > I just listed some of the challenges I faced till now. I'll be grateful >> > to >> > know your opinion about them. >> > >> > Thanks again, >> > Sabet >> > >> > >> > >> > >> > -----Original Message----- >> >> > From: Lixia Zhang [mailto:lixia at cs.ucla.edu ] >> > Sent: Fri 2/13/2015 8:26 PM >> > To: Muhammad Hosain Abdollahi Sabet >> > Cc: ndn-interest at lists.cs.ucla.edu >> > Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions >> > >> > >> > > On Feb 12, 2015, at 2:16 PM, Muhammad Hosain Abdollahi Sabet < >> > M.AbdollahiSabet at mail.sbu.ac.ir> wrote: >> > > >> > > Hello everyone. >> > > I've been studying NDN for a couple of months now. For supporting >> > mobility in environments without any clear infrastructure and topology >> > like >> > MANET (VANET in particular), it's been developing like a charm. But as >> > far >> > as I've learned, it's producer-side mobility support in large scales >> > still >> > has some serious challenges, particularly in scenarios like mobile >> > caller-callee. And as "A New Perspective on Mobility Support" has >> > reported, >> > none of the proposed solutions(Proxy based, Rendezvous point based, ...) >> > seems to have a NDN-likely technique. I'm eager to work on it as my B.S >> > thesis. But the problem is, when I look at the ICN workshops, >> > conferences, >> > articles, posters, demos and etc, I cannot find real attempts on >> > this(unless Kite I may say). Not that I've seen for example about >> > Routing >> > or Security. And now I'm wondering: Is it really that clear?! Maybe you >> > can >> > guide me to a vision I don't have. >> > > >> > > Thanks, >> > > Sabet >> > >> > Sabet, >> > >> > thanks for your msg. I wonder what you meant by "Is it really that >> > clear?!". >> > If you are asking whether it is clear that NDN can offer superior >> > mobility >> > support than TCP/IP, then you know the answer is YES, right? >> > If you are asking whether mobile producer solutions have been fully >> > developed: it is still being developed, hence the need for your effort >> > on >> > this problem. We *are* developing solutions, first for specific >> > application scenarios, which help us understand how to provide general >> > solutions. >> > If you are asking for examples of routing solutions: I'm sure you've >> > seen >> > NLSR work as an example; we are also actively working on hyperbolic >> > routing >> > as potential long term directly. >> > For security, you may look into recent NDN retreat which focused on >> > security solution development. >> > >> > Lixia >> > >> > >> > >> > _______________________________________________ >> > 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 wentaoshang at gmail.com Sun Feb 15 12:50:46 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Sun, 15 Feb 2015 20:50:46 +0000 Subject: [Ndn-interest] NDN-friendly Mobility solutions References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2930@m-pdc.sbu.ac.ir> Message-ID: On Sun Feb 15 2015 at 12:09:54 PM Tai-Lin Chu wrote: > > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as > indirection: you can have your producer publish its data to a well-known > location, such as an NDN repo, so that the consumer can fetch data from the > repo instead of talking to the producer directly. > > I think there is something missing in this design. When producer needs > to send its data to the repo, the repo becomes the client. As a > result, this looks like a recursive algorithm without base case :) > Exactly! Devil is always in the detail :) However, in this case you can make more assumptions about the repo: it will be always on line and perhaps not moving; it will have a routable prefix (which is a very important distinction because normal consumers do not have routable prefix) so that you can play tricks like Interest-Interest communication or use the Kite solution (Kite is designed exactly for this scenario). Wentao > > On Sun, Feb 15, 2015 at 11:18 AM, Wentao Shang > wrote: > > While any solution must be based on the specific application scenario, > there > > are still some general guidelines that you may consider: > > > > 1/ Producer mobility is hard because the consumer has to shoot Interest > to a > > moving target. Therefore the principle is to find something invariant and > > use that as an indirection, which is essentially the same idea as > locator/id > > separation. > > > > 2/ One way to do that is to directly apply the LISP concept to the NDN > > network: you can assign a location-independent name to the producer and > let > > the producer register its current location to a general mapping system > (e.g, > > NDNS); then the consumer can send Interest to the producer's latest > location > > using either Interest encapsulation or forwarding hint. > > > > This design is useful if your application must enforce P2P communication > > (e.g., if you want to send control commands to a specific sensor on a > plane > > that is flying from LAX to JFK). > > > > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as > > indirection: you can have your producer publish its data to a well-known > > location, such as an NDN repo, so that the consumer can fetch data from > the > > repo instead of talking to the producer directly. > > > > This design also applies to sensor networks where the producer has > limited > > storage capacity and/or low duty-cycle so that it must offload the data > > storage task to a more powerful device. > > > > 4/ I remember Prof. Lixia showed us some slides in her class about the > idea > > of NDN routing via self-learning. The key idea is to utilize NDN's > stateful > > forwarding plain to estimate the validity of a route on the fly. > > Unfortunately I couldn't remember any reference for that work. > > > > Hope this may be helpful to your research. > > > > Wentao > > > > > > On Sun Feb 15 2015 at 3:47:47 AM Muhammad Hosain Abdollahi Sabet > > wrote: > >> > >> Good point! I agree that NDN supports subscriber mobility in it's nature > >> and as you said most of mobility issues in subscriber-side scenarios > >> disappear automatically. But what about some producer ones? As an > example, > >> the application scenario we are talking about could be voice/video chat > when > >> both caller and callee are mobile. How could we consider it in a non-P2P > >> model? > >> > >> Could you please guide me to find about possibility for intelligent > >> broadcast/multicast using self-learning path selection ? > >> > >> > >> > >> > >> -----Original Message----- > >> From: Wentao Shang [mailto:wentaoshang at gmail.com] > >> Sent: Sun 2/15/2015 3:47 AM > >> To: Muhammad Hosain Abdollahi Sabet; Lixia Zhang; > >> ndn-interest at lists.cs.ucla.edu > >> Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions > >> > >> On Sat Feb 14 2015 at 9:26:50 AM Muhammad Hosain Abdollahi Sabet < > >> M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > >> > >> > Thank you so much for answering. > >> > Actually it struck my mind that "it" is unclear, which I'm sorry for > the > >> > ambiguity. The second one was the closest one. I meant: "Is the > solution > >> > for producer-side mobility clear enough that there hasn't been real > >> > attempt > >> > about it? > >> > >> > I'll be absolutely glad to help. ?As far as I understand we have > another > >> > >> > >> > paradigm shifting again in some mobility application scenarios like > >> > mobile > >> > caller-callee. NDN shifts networking from host-centric(point to point) > >> > to a > >> > content-centric architecture. And now we want to make point to point > >> > connection overlay of NDN. Right? > >> > > >> Not sure why you want to make point-to-point connection over NDN. Is it > a > >> requirement from specific application in your mind? NDN shifts away from > >> the P2P connection model and therefore provides new opportunity for > better > >> mobility support. Perhaps it is more efficient to design your > application > >> in the NDN model (in which case some mobility issue may disappear > >> automatically) than to fit the old model into the new architecture. > >> > >> > >> > So I think using some IP-like producer mobility solutions is not > >> > avoidable. On the other hand some of NDN features like being broadcast > >> > finendly which is referred to in "A New Perspective in Mobility > >> > Support'' > >> > as a suggestion, isn't practical in large scale because of producing > >> > heavy > >> > overhead of controlling data(specially in hard-state mode). > >> > > >> Broadcast is impractical for large scale IP network. But NDN has a > smarter > >> forwarding plain which opens possibility for intelligent > >> broadcast/multicast using self-learning path selection and traffic > >> reduction. > >> > >> Different mobility solutions are designed for different application > >> scenarios. In some extreme cases where the network is so dynamic that it > >> is > >> impossible to maintain a stable topology, broadcast/multicast may be the > >> only choice. > >> > >> > >> > Furthermore, hierarchical naming brings some location dependency, > >> > > >> It is not that hierarchical naming brings location dependency. Any > >> identifier that is used in routing and forwarding will cause location > >> dependency. That's why people invented the concept of Locator/ID > >> separation, which is mentioned in the mobility TR. The "forwarding hint" > >> is > >> one way to implement that in NDN. > >> > >> Wentao > >> > >> > >> > and maybe we need some conventions in this field, in which network can > >> > approximate location of endpoint while pinpointing location of > endpoint > >> > can > >> > be postponed to last steps. > >> > I just listed some of the challenges I faced till now. I'll be > grateful > >> > to > >> > know your opinion about them. > >> > > >> > Thanks again, > >> > Sabet > >> > > >> > > >> > > >> > > >> > -----Original Message----- > >> > >> > From: Lixia Zhang [mailto:lixia at cs.ucla.edu ] > >> > Sent: Fri 2/13/2015 8:26 PM > >> > To: Muhammad Hosain Abdollahi Sabet > >> > Cc: ndn-interest at lists.cs.ucla.edu > >> > Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions > >> > > >> > > >> > > On Feb 12, 2015, at 2:16 PM, Muhammad Hosain Abdollahi Sabet < > >> > M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > >> > > > >> > > Hello everyone. > >> > > I've been studying NDN for a couple of months now. For supporting > >> > mobility in environments without any clear infrastructure and topology > >> > like > >> > MANET (VANET in particular), it's been developing like a charm. But as > >> > far > >> > as I've learned, it's producer-side mobility support in large scales > >> > still > >> > has some serious challenges, particularly in scenarios like mobile > >> > caller-callee. And as "A New Perspective on Mobility Support" has > >> > reported, > >> > none of the proposed solutions(Proxy based, Rendezvous point based, > ...) > >> > seems to have a NDN-likely technique. I'm eager to work on it as my > B.S > >> > thesis. But the problem is, when I look at the ICN workshops, > >> > conferences, > >> > articles, posters, demos and etc, I cannot find real attempts on > >> > this(unless Kite I may say). Not that I've seen for example about > >> > Routing > >> > or Security. And now I'm wondering: Is it really that clear?! Maybe > you > >> > can > >> > guide me to a vision I don't have. > >> > > > >> > > Thanks, > >> > > Sabet > >> > > >> > Sabet, > >> > > >> > thanks for your msg. I wonder what you meant by "Is it really that > >> > clear?!". > >> > If you are asking whether it is clear that NDN can offer superior > >> > mobility > >> > support than TCP/IP, then you know the answer is YES, right? > >> > If you are asking whether mobile producer solutions have been fully > >> > developed: it is still being developed, hence the need for your effort > >> > on > >> > this problem. We *are* developing solutions, first for specific > >> > application scenarios, which help us understand how to provide general > >> > solutions. > >> > If you are asking for examples of routing solutions: I'm sure you've > >> > seen > >> > NLSR work as an example; we are also actively working on hyperbolic > >> > routing > >> > as potential long term directly. > >> > For security, you may look into recent NDN retreat which focused on > >> > security solution development. > >> > > >> > Lixia > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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 mhasabet at gmail.com Sun Feb 15 22:42:10 2015 From: mhasabet at gmail.com (Muhammad Sabet) Date: Mon, 16 Feb 2015 10:12:10 +0330 Subject: [Ndn-interest] NDN-friendly Mobility solutions In-Reply-To: References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2930@m-pdc.sbu.ac.ir> Message-ID: Actually what is awesome about the Kite solution is that the anchor point will be the final destination from the perspective of Interest sender(unlike previous rendezvous point based solutions), and since the ap is supposed to be fixed, there is no need for updating FIB entries. But when the mobile endpoint gets farther from access range of the anchor point, the solution starts to become something like previous proxy based ones and thus we will have the triangle routing issue. Unless there would be some mechanism to change anchor point optimally, which I didn't see such in the Kite TR. On Mon, Feb 16, 2015 at 12:20 AM, Wentao Shang wrote: > > > On Sun Feb 15 2015 at 12:09:54 PM Tai-Lin Chu wrote: > >> > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as >> indirection: you can have your producer publish its data to a well-known >> location, such as an NDN repo, so that the consumer can fetch data from the >> repo instead of talking to the producer directly. >> >> I think there is something missing in this design. When producer needs >> to send its data to the repo, the repo becomes the client. As a >> result, this looks like a recursive algorithm without base case :) >> > > Exactly! Devil is always in the detail :) > > However, in this case you can make more assumptions about the repo: it > will be always on line and perhaps not moving; it will have a routable > prefix (which is a very important distinction because normal consumers do > not have routable prefix) so that you can play tricks like > Interest-Interest communication or use the Kite solution (Kite is designed > exactly for this scenario). > > Wentao > > >> >> On Sun, Feb 15, 2015 at 11:18 AM, Wentao Shang >> wrote: >> > While any solution must be based on the specific application scenario, >> there >> > are still some general guidelines that you may consider: >> > >> > 1/ Producer mobility is hard because the consumer has to shoot Interest >> to a >> > moving target. Therefore the principle is to find something invariant >> and >> > use that as an indirection, which is essentially the same idea as >> locator/id >> > separation. >> > >> > 2/ One way to do that is to directly apply the LISP concept to the NDN >> > network: you can assign a location-independent name to the producer and >> let >> > the producer register its current location to a general mapping system >> (e.g, >> > NDNS); then the consumer can send Interest to the producer's latest >> location >> > using either Interest encapsulation or forwarding hint. >> > >> > This design is useful if your application must enforce P2P communication >> > (e.g., if you want to send control commands to a specific sensor on a >> plane >> > that is flying from LAX to JFK). >> > >> > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as >> > indirection: you can have your producer publish its data to a well-known >> > location, such as an NDN repo, so that the consumer can fetch data from >> the >> > repo instead of talking to the producer directly. >> > >> > This design also applies to sensor networks where the producer has >> limited >> > storage capacity and/or low duty-cycle so that it must offload the data >> > storage task to a more powerful device. >> > >> > 4/ I remember Prof. Lixia showed us some slides in her class about the >> idea >> > of NDN routing via self-learning. The key idea is to utilize NDN's >> stateful >> > forwarding plain to estimate the validity of a route on the fly. >> > Unfortunately I couldn't remember any reference for that work. >> > >> > Hope this may be helpful to your research. >> > >> > Wentao >> > >> > >> > On Sun Feb 15 2015 at 3:47:47 AM Muhammad Hosain Abdollahi Sabet >> > wrote: >> >> >> >> Good point! I agree that NDN supports subscriber mobility in it's >> nature >> >> and as you said most of mobility issues in subscriber-side scenarios >> >> disappear automatically. But what about some producer ones? As an >> example, >> >> the application scenario we are talking about could be voice/video >> chat when >> >> both caller and callee are mobile. How could we consider it in a >> non-P2P >> >> model? >> >> >> >> Could you please guide me to find about possibility for intelligent >> >> broadcast/multicast using self-learning path selection ? >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: Wentao Shang [mailto:wentaoshang at gmail.com] >> >> Sent: Sun 2/15/2015 3:47 AM >> >> To: Muhammad Hosain Abdollahi Sabet; Lixia Zhang; >> >> ndn-interest at lists.cs.ucla.edu >> >> Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions >> >> >> >> On Sat Feb 14 2015 at 9:26:50 AM Muhammad Hosain Abdollahi Sabet < >> >> M.AbdollahiSabet at mail.sbu.ac.ir> wrote: >> >> >> >> > Thank you so much for answering. >> >> > Actually it struck my mind that "it" is unclear, which I'm sorry for >> the >> >> > ambiguity. The second one was the closest one. I meant: "Is the >> solution >> >> > for producer-side mobility clear enough that there hasn't been real >> >> > attempt >> >> > about it? >> >> >> >> > I'll be absolutely glad to help. ?As far as I understand we have >> another >> >> >> >> >> >> > paradigm shifting again in some mobility application scenarios like >> >> > mobile >> >> > caller-callee. NDN shifts networking from host-centric(point to >> point) >> >> > to a >> >> > content-centric architecture. And now we want to make point to point >> >> > connection overlay of NDN. Right? >> >> > >> >> Not sure why you want to make point-to-point connection over NDN. Is >> it a >> >> requirement from specific application in your mind? NDN shifts away >> from >> >> the P2P connection model and therefore provides new opportunity for >> better >> >> mobility support. Perhaps it is more efficient to design your >> application >> >> in the NDN model (in which case some mobility issue may disappear >> >> automatically) than to fit the old model into the new architecture. >> >> >> >> >> >> > So I think using some IP-like producer mobility solutions is not >> >> > avoidable. On the other hand some of NDN features like being >> broadcast >> >> > finendly which is referred to in "A New Perspective in Mobility >> >> > Support'' >> >> > as a suggestion, isn't practical in large scale because of producing >> >> > heavy >> >> > overhead of controlling data(specially in hard-state mode). >> >> > >> >> Broadcast is impractical for large scale IP network. But NDN has a >> smarter >> >> forwarding plain which opens possibility for intelligent >> >> broadcast/multicast using self-learning path selection and traffic >> >> reduction. >> >> >> >> Different mobility solutions are designed for different application >> >> scenarios. In some extreme cases where the network is so dynamic that >> it >> >> is >> >> impossible to maintain a stable topology, broadcast/multicast may be >> the >> >> only choice. >> >> >> >> >> >> > Furthermore, hierarchical naming brings some location dependency, >> >> > >> >> It is not that hierarchical naming brings location dependency. Any >> >> identifier that is used in routing and forwarding will cause location >> >> dependency. That's why people invented the concept of Locator/ID >> >> separation, which is mentioned in the mobility TR. The "forwarding >> hint" >> >> is >> >> one way to implement that in NDN. >> >> >> >> Wentao >> >> >> >> >> >> > and maybe we need some conventions in this field, in which network >> can >> >> > approximate location of endpoint while pinpointing location of >> endpoint >> >> > can >> >> > be postponed to last steps. >> >> > I just listed some of the challenges I faced till now. I'll be >> grateful >> >> > to >> >> > know your opinion about them. >> >> > >> >> > Thanks again, >> >> > Sabet >> >> > >> >> > >> >> > >> >> > >> >> > -----Original Message----- >> >> >> >> > From: Lixia Zhang [mailto:lixia at cs.ucla.edu ] >> >> > Sent: Fri 2/13/2015 8:26 PM >> >> > To: Muhammad Hosain Abdollahi Sabet >> >> > Cc: ndn-interest at lists.cs.ucla.edu >> >> > Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions >> >> > >> >> > >> >> > > On Feb 12, 2015, at 2:16 PM, Muhammad Hosain Abdollahi Sabet < >> >> > M.AbdollahiSabet at mail.sbu.ac.ir> wrote: >> >> > > >> >> > > Hello everyone. >> >> > > I've been studying NDN for a couple of months now. For supporting >> >> > mobility in environments without any clear infrastructure and >> topology >> >> > like >> >> > MANET (VANET in particular), it's been developing like a charm. But >> as >> >> > far >> >> > as I've learned, it's producer-side mobility support in large scales >> >> > still >> >> > has some serious challenges, particularly in scenarios like mobile >> >> > caller-callee. And as "A New Perspective on Mobility Support" has >> >> > reported, >> >> > none of the proposed solutions(Proxy based, Rendezvous point based, >> ...) >> >> > seems to have a NDN-likely technique. I'm eager to work on it as my >> B.S >> >> > thesis. But the problem is, when I look at the ICN workshops, >> >> > conferences, >> >> > articles, posters, demos and etc, I cannot find real attempts on >> >> > this(unless Kite I may say). Not that I've seen for example about >> >> > Routing >> >> > or Security. And now I'm wondering: Is it really that clear?! Maybe >> you >> >> > can >> >> > guide me to a vision I don't have. >> >> > > >> >> > > Thanks, >> >> > > Sabet >> >> > >> >> > Sabet, >> >> > >> >> > thanks for your msg. I wonder what you meant by "Is it really that >> >> > clear?!". >> >> > If you are asking whether it is clear that NDN can offer superior >> >> > mobility >> >> > support than TCP/IP, then you know the answer is YES, right? >> >> > If you are asking whether mobile producer solutions have been fully >> >> > developed: it is still being developed, hence the need for your >> effort >> >> > on >> >> > this problem. We *are* developing solutions, first for specific >> >> > application scenarios, which help us understand how to provide >> general >> >> > solutions. >> >> > If you are asking for examples of routing solutions: I'm sure you've >> >> > seen >> >> > NLSR work as an example; we are also actively working on hyperbolic >> >> > routing >> >> > as potential long term directly. >> >> > For security, you may look into recent NDN retreat which focused on >> >> > security solution development. >> >> > >> >> > Lixia >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 M.AbdollahiSabet at mail.sbu.ac.ir Sun Feb 15 22:41:52 2015 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Mon, 16 Feb 2015 10:11:52 +0330 Subject: [Ndn-interest] NDN-friendly Mobility solutions References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir><7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu><4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir><4AC03A6244C3C34BB52A7EC60B799C4C03CC2930@m-pdc.sbu.ac.ir> Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2932@m-pdc.sbu.ac.ir> Sorry. The last one was from me. It was a mistake. -----Original Message----- From: Muhammad Sabet [mailto:mhasabet at gmail.com] Sent: Mon 2/16/2015 10:12 AM To: Wentao Shang Cc: Tai-Lin Chu; Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions Actually what is awesome about the Kite solution is that the anchor point will be the final destination from the perspective of Interest sender(unlike previous rendezvous point based solutions), and since the ap is supposed to be fixed, there is no need for updating FIB entries. But when the mobile endpoint gets farther from access range of the anchor point, the solution starts to become something like previous proxy based ones and thus we will have the triangle routing issue. Unless there would be some mechanism to change anchor point optimally, which I didn't see such in the Kite TR. On Mon, Feb 16, 2015 at 12:20 AM, Wentao Shang wrote: > > > On Sun Feb 15 2015 at 12:09:54 PM Tai-Lin Chu wrote: > >> > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as >> indirection: you can have your producer publish its data to a well-known >> location, such as an NDN repo, so that the consumer can fetch data from the >> repo instead of talking to the producer directly. >> >> I think there is something missing in this design. When producer needs >> to send its data to the repo, the repo becomes the client. As a >> result, this looks like a recursive algorithm without base case :) >> > > Exactly! Devil is always in the detail :) > > However, in this case you can make more assumptions about the repo: it > will be always on line and perhaps not moving; it will have a routable > prefix (which is a very important distinction because normal consumers do > not have routable prefix) so that you can play tricks like > Interest-Interest communication or use the Kite solution (Kite is designed > exactly for this scenario). > > Wentao > > >> >> On Sun, Feb 15, 2015 at 11:18 AM, Wentao Shang >> wrote: >> > While any solution must be based on the specific application scenario, >> there >> > are still some general guidelines that you may consider: >> > >> > 1/ Producer mobility is hard because the consumer has to shoot Interest >> to a >> > moving target. Therefore the principle is to find something invariant >> and >> > use that as an indirection, which is essentially the same idea as >> locator/id >> > separation. >> > >> > 2/ One way to do that is to directly apply the LISP concept to the NDN >> > network: you can assign a location-independent name to the producer and >> let >> > the producer register its current location to a general mapping system >> (e.g, >> > NDNS); then the consumer can send Interest to the producer's latest >> location >> > using either Interest encapsulation or forwarding hint. >> > >> > This design is useful if your application must enforce P2P communication >> > (e.g., if you want to send control commands to a specific sensor on a >> plane >> > that is flying from LAX to JFK). >> > >> > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as >> > indirection: you can have your producer publish its data to a well-known >> > location, such as an NDN repo, so that the consumer can fetch data from >> the >> > repo instead of talking to the producer directly. >> > >> > This design also applies to sensor networks where the producer has >> limited >> > storage capacity and/or low duty-cycle so that it must offload the data >> > storage task to a more powerful device. >> > >> > 4/ I remember Prof. Lixia showed us some slides in her class about the >> idea >> > of NDN routing via self-learning. The key idea is to utilize NDN's >> stateful >> > forwarding plain to estimate the validity of a route on the fly. >> > Unfortunately I couldn't remember any reference for that work. >> > >> > Hope this may be helpful to your research. >> > >> > Wentao >> > >> > >> > On Sun Feb 15 2015 at 3:47:47 AM Muhammad Hosain Abdollahi Sabet >> > wrote: >> >> >> >> Good point! I agree that NDN supports subscriber mobility in it's >> nature >> >> and as you said most of mobility issues in subscriber-side scenarios >> >> disappear automatically. But what about some producer ones? As an >> example, >> >> the application scenario we are talking about could be voice/video >> chat when >> >> both caller and callee are mobile. How could we consider it in a >> non-P2P >> >> model? >> >> >> >> Could you please guide me to find about possibility for intelligent >> >> broadcast/multicast using self-learning path selection ? >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: Wentao Shang [mailto:wentaoshang at gmail.com] >> >> Sent: Sun 2/15/2015 3:47 AM >> >> To: Muhammad Hosain Abdollahi Sabet; Lixia Zhang; >> >> ndn-interest at lists.cs.ucla.edu >> >> Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions >> >> >> >> On Sat Feb 14 2015 at 9:26:50 AM Muhammad Hosain Abdollahi Sabet < >> >> M.AbdollahiSabet at mail.sbu.ac.ir> wrote: >> >> >> >> > Thank you so much for answering. >> >> > Actually it struck my mind that "it" is unclear, which I'm sorry for >> the >> >> > ambiguity. The second one was the closest one. I meant: "Is the >> solution >> >> > for producer-side mobility clear enough that there hasn't been real >> >> > attempt >> >> > about it? >> >> >> >> > I'll be absolutely glad to help. ?As far as I understand we have >> another >> >> >> >> >> >> > paradigm shifting again in some mobility application scenarios like >> >> > mobile >> >> > caller-callee. NDN shifts networking from host-centric(point to >> point) >> >> > to a >> >> > content-centric architecture. And now we want to make point to point >> >> > connection overlay of NDN. Right? >> >> > >> >> Not sure why you want to make point-to-point connection over NDN. Is >> it a >> >> requirement from specific application in your mind? NDN shifts away >> from >> >> the P2P connection model and therefore provides new opportunity for >> better >> >> mobility support. Perhaps it is more efficient to design your >> application >> >> in the NDN model (in which case some mobility issue may disappear >> >> automatically) than to fit the old model into the new architecture. >> >> >> >> >> >> > So I think using some IP-like producer mobility solutions is not >> >> > avoidable. On the other hand some of NDN features like being >> broadcast >> >> > finendly which is referred to in "A New Perspective in Mobility >> >> > Support'' >> >> > as a suggestion, isn't practical in large scale because of producing >> >> > heavy >> >> > overhead of controlling data(specially in hard-state mode). >> >> > >> >> Broadcast is impractical for large scale IP network. But NDN has a >> smarter >> >> forwarding plain which opens possibility for intelligent >> >> broadcast/multicast using self-learning path selection and traffic >> >> reduction. >> >> >> >> Different mobility solutions are designed for different application >> >> scenarios. In some extreme cases where the network is so dynamic that >> it >> >> is >> >> impossible to maintain a stable topology, broadcast/multicast may be >> the >> >> only choice. >> >> >> >> >> >> > Furthermore, hierarchical naming brings some location dependency, >> >> > >> >> It is not that hierarchical naming brings location dependency. Any >> >> identifier that is used in routing and forwarding will cause location >> >> dependency. That's why people invented the concept of Locator/ID >> >> separation, which is mentioned in the mobility TR. The "forwarding >> hint" >> >> is >> >> one way to implement that in NDN. >> >> >> >> Wentao >> >> >> >> >> >> > and maybe we need some conventions in this field, in which network >> can >> >> > approximate location of endpoint while pinpointing location of >> endpoint >> >> > can >> >> > be postponed to last steps. >> >> > I just listed some of the challenges I faced till now. I'll be >> grateful >> >> > to >> >> > know your opinion about them. >> >> > >> >> > Thanks again, >> >> > Sabet >> >> > >> >> > >> >> > >> >> > >> >> > -----Original Message----- >> >> >> >> > From: Lixia Zhang [mailto:lixia at cs.ucla.edu ] >> >> > Sent: Fri 2/13/2015 8:26 PM >> >> > To: Muhammad Hosain Abdollahi Sabet >> >> > Cc: ndn-interest at lists.cs.ucla.edu >> >> > Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions >> >> > >> >> > >> >> > > On Feb 12, 2015, at 2:16 PM, Muhammad Hosain Abdollahi Sabet < >> >> > M.AbdollahiSabet at mail.sbu.ac.ir> wrote: >> >> > > >> >> > > Hello everyone. >> >> > > I've been studying NDN for a couple of months now. For supporting >> >> > mobility in environments without any clear infrastructure and >> topology >> >> > like >> >> > MANET (VANET in particular), it's been developing like a charm. But >> as >> >> > far >> >> > as I've learned, it's producer-side mobility support in large scales >> >> > still >> >> > has some serious challenges, particularly in scenarios like mobile >> >> > caller-callee. And as "A New Perspective on Mobility Support" has >> >> > reported, >> >> > none of the proposed solutions(Proxy based, Rendezvous point based, >> ...) >> >> > seems to have a NDN-likely technique. I'm eager to work on it as my >> B.S >> >> > thesis. But the problem is, when I look at the ICN workshops, >> >> > conferences, >> >> > articles, posters, demos and etc, I cannot find real attempts on >> >> > this(unless Kite I may say). Not that I've seen for example about >> >> > Routing >> >> > or Security. And now I'm wondering: Is it really that clear?! Maybe >> you >> >> > can >> >> > guide me to a vision I don't have. >> >> > > >> >> > > Thanks, >> >> > > Sabet >> >> > >> >> > Sabet, >> >> > >> >> > thanks for your msg. I wonder what you meant by "Is it really that >> >> > clear?!". >> >> > If you are asking whether it is clear that NDN can offer superior >> >> > mobility >> >> > support than TCP/IP, then you know the answer is YES, right? >> >> > If you are asking whether mobile producer solutions have been fully >> >> > developed: it is still being developed, hence the need for your >> effort >> >> > on >> >> > this problem. We *are* developing solutions, first for specific >> >> > application scenarios, which help us understand how to provide >> general >> >> > solutions. >> >> > If you are asking for examples of routing solutions: I'm sure you've >> >> > seen >> >> > NLSR work as an example; we are also actively working on hyperbolic >> >> > routing >> >> > as potential long term directly. >> >> > For security, you may look into recent NDN retreat which focused on >> >> > security solution development. >> >> > >> >> > Lixia >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 nitinder1369 at iiitd.ac.in Mon Feb 16 01:33:36 2015 From: nitinder1369 at iiitd.ac.in (Nitinder Mohan) Date: Mon, 16 Feb 2015 15:03:36 +0530 Subject: [Ndn-interest] Resend pending interests Message-ID: Hello All, NDN stores all duplicate interests (which have not been answered) in PIT entry of the router and thus does not forward the interest to the producer again. If we assume that a producer does not reply to an interest for quite a long time (error at producer side), can consumer, some how, resend the interest bypassing the PIT entries? Or does the consumer has to rename the interest in such a way that it asks for the same data but is still unique? Does NDN currently have any capability to do so? Thanks and Regards Nitinder Mohan MTech (CE) IIIT Delhi http://home.iiitd.edu.in/~nitinder1369/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Feb 16 06:12:50 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 16 Feb 2015 07:12:50 -0700 Subject: [Ndn-interest] Resend pending interests In-Reply-To: References: Message-ID: Hi Nitinder NDN forwarder keeps Interests in PIT so that similar Interests (same Name and Selectors) are suppressed. If the upstream/producer doesn't answer, forwarding strategy can try different paths. Typically, strategy won't forward to the same nexthop more than once on its own. When consumer retransmits a similar Interest (same Name and Selectors) with a different Nonce, the forwarding strategy can decide whether to forward this Interest again. In this situation, strategy may forward to the same upstream/producer again. Thus, consumer doesn't need to "rename" the Interest. It can just retransmit with a different Nonce. In NFD v0.3.0, best-route v2 strategy and access strategy will forward consumer retransmitted Interest if it's more than 100ms since the previous forwarded transmission; if the consumer retransmission is within 100ms, it's suppressed. The 100ms suppression interval is set arbitrarily. We are thinking about using exponential backoff algorithm to decide whether to suppress or forward. Other suggestions are welcomed. Yours, Junxiao On Feb 16, 2015 2:34 AM, "Nitinder Mohan" wrote: > Hello All, > > NDN stores all duplicate interests (which have not been answered) in PIT > entry of the router and thus does not forward the interest to the producer > again. If we assume that a producer does not reply to an interest for quite > a long time (error at producer side), can consumer, some how, resend the > interest bypassing the PIT entries? Or does the consumer has to rename the > interest in such a way that it asks for the same data but is still unique? > Does NDN currently have any capability to do so? > > Thanks and Regards > > Nitinder Mohan > MTech (CE) IIIT Delhi > http://home.iiitd.edu.in/~nitinder1369/ > > _______________________________________________ > 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 jlee700 at illinois.edu Mon Feb 16 15:54:35 2015 From: jlee700 at illinois.edu (Lee, Jongdeog) Date: Mon, 16 Feb 2015 23:54:35 +0000 Subject: [Ndn-interest] Interest with same name and different exclude? In-Reply-To: References: , Message-ID: Dear Junxiao, Thanks for the reply. I now know the reason. Since those two interest packets have the same name, routers will automatically forward data which is not in "exclude" field. The reason I thought that routers treat them differently is because the producer receives only one interest packet in previous example. excludeBefore() function helps to resolve this problem. BTW, how can I get one name component from an exclude. For example, if exclude = (*, A), how can I get A from this exclude? There is no get function in exclude... Best wishes, Jongdeog Lee (JD) ------------------------------------------------ Ph.D. Student Department of Computer Science University of Illinois at Urbana-Champaign ________________________________ From: Junxiao Shi [shijunxiao at email.arizona.edu] Sent: Friday, February 13, 2015 4:37 PM To: Lee, Jongdeog Cc: ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] Interest with same name and different exclude? Hi Jongdeog A standard-conforming router will forward these two Interests separately. When a Data packet comes back that can satisfy both Interests, it will be returned to the requester only once. If you still have questions, please describe how you test the behavior and what leads to conclude that they are treated as same. Yours, Junxiao On Fri, Feb 13, 2015 at 3:33 PM, Lee, Jongdeog > wrote: Dear all, Suppose that there are two interest packets with the same name & different exclude. (Interest A: /prefix/postfix.....exclude=a Interest B: /prefix/postfix.....exclude=b) Do routers treat them differently or equally? I tested the simple code, and it seems they are treated as same. Best, Jongdeog Lee (JD) ------------------------------------------------ Ph.D. Student Department of Computer Science University of Illinois at Urbana-Champaign _______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Feb 17 13:23:28 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 17 Feb 2015 14:23:28 -0700 Subject: [Ndn-interest] Interest with same name and different exclude? In-Reply-To: References: Message-ID: Hi Jongdeog If the first reply Data can satisfy both Interests, the second Interest will be satisfied straight from ContentStore and won't be delivered to producer. Please ask library API question on ndn-lib mailing list. Make sure to put the name of library you are using in message Subject. Yours, Junxiao On Mon, Feb 16, 2015 at 4:54 PM, Lee, Jongdeog wrote: > Dear Junxiao, > > Thanks for the reply. > I now know the reason. Since those two interest packets have the same > name, routers will automatically forward data which is not in "exclude" > field. The reason I thought that routers treat them differently is because > the producer receives only one interest packet in previous example. > > excludeBefore() function helps to resolve this problem. BTW, how can I > get one name component from an exclude. For example, if exclude = (*, A), > how can I get A from this exclude? There is no get function in exclude... > > Best wishes, > Jongdeog Lee (JD) > > ------------------------------------------------ > *Ph.D. Student* > *Department of Computer Science* > *University of Illinois at Urbana-Champaign* > ------------------------------ > *From:* Junxiao Shi [shijunxiao at email.arizona.edu] > *Sent:* Friday, February 13, 2015 4:37 PM > *To:* Lee, Jongdeog > *Cc:* ndn-interest at lists.cs.ucla.edu > *Subject:* Re: [Ndn-interest] Interest with same name and different > exclude? > > Hi Jongdeog > > A standard-conforming router will forward these two Interests separately. > When a Data packet comes back that can satisfy both Interests, it will be > returned to the requester only once. > > If you still have questions, please describe how you test the behavior > and what leads to conclude that they are treated as same. > > Yours, Junxiao > > On Fri, Feb 13, 2015 at 3:33 PM, Lee, Jongdeog > wrote: > >> Dear all, >> >> Suppose that there are two interest packets with the same name & >> different exclude. >> (Interest A: /prefix/postfix.....exclude=a >> Interest B: /prefix/postfix.....exclude=b) >> Do routers treat them differently or equally? >> I tested the simple code, and it seems they are treated as same. >> >> Best, >> Jongdeog Lee (JD) >> >> ------------------------------------------------ >> *Ph.D. Student* >> *Department of Computer Science* >> *University of Illinois at Urbana-Champaign* >> >> _______________________________________________ >> 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 Thu Feb 19 07:13:48 2015 From: mjs at cisco.com (Mark Stapp) Date: Thu, 19 Feb 2015 10:13:48 -0500 Subject: [Ndn-interest] NDN-friendly Mobility solutions In-Reply-To: References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2930@m-pdc.sbu.ac.ir> Message-ID: <54E5FDAC.1000002@cisco.com> Hi Wentao, On 2/15/15 2:18 PM, Wentao Shang wrote: > While any solution must be based on the specific application scenario, > there are still some general guidelines that you may consider: > [...] > > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as > indirection: you can have your producer publish its data to a well-known > location, such as an NDN repo, so that the consumer can fetch data from > the repo instead of talking to the producer directly. > hmm - that sure sounds like a CDN design, the kind that we use all the time - facebook, flickr, gmail. is that the kind of thing you had in mind? if so, as you know I agree, and I think there should be more focus on mechanisms that support this design. Thanks, Mark From wentaoshang at gmail.com Thu Feb 19 13:08:09 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Thu, 19 Feb 2015 21:08:09 +0000 Subject: [Ndn-interest] NDN-friendly Mobility solutions References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2930@m-pdc.sbu.ac.ir> <54E5FDAC.1000002@cisco.com> Message-ID: Hi Mark, Yes, I think the "CDN-style" model could be a starting point for solving a class of mobility problems. A few things that are still unclear to me include: 1/ Can we use this rendezvous model for real-time communications like video/audio conferencing? Not sure how the indirection will affect the delays. 2/ If we plan to use Interest-Interest communication, how do we handle the case when the producer doesn't have a routable prefix (or doesn't know he has)? The Kite approach (i.e., using PIT to do reverse path forwarding) is a significant change to the architecture and I still don't understand the implication of this change yet. Wentao On Thu Feb 19 2015 at 7:16:07 AM Mark Stapp wrote: > Hi Wentao, > > On 2/15/15 2:18 PM, Wentao Shang wrote: > > While any solution must be based on the specific application scenario, > > there are still some general guidelines that you may consider: > > > > [...] > > > > > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as > > indirection: you can have your producer publish its data to a well-known > > location, such as an NDN repo, so that the consumer can fetch data from > > the repo instead of talking to the producer directly. > > > > hmm - that sure sounds like a CDN design, the kind that we use all the > time - facebook, flickr, gmail. is that the kind of thing you had in > mind? if so, as you know I agree, and I think there should be more focus > on mechanisms that support this design. > > 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 M.AbdollahiSabet at mail.sbu.ac.ir Fri Feb 20 02:15:50 2015 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Fri, 20 Feb 2015 13:45:50 +0330 Subject: [Ndn-interest] NDN-friendly Mobility solutions Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2936@m-pdc.sbu.ac.ir> Despite the possibility of delay in repo-based solution, is it cost effective? I mean, in a CDN-like solution we focus on caching(for distributing contents), which in this scenario(real-time communication) is not that usable because we are not going to use the produced data(from the vice-chat application) again, right? ?? On 20 Feb 2015 00:39, "Wentao Shang" wrote: > > Hi Mark, > > Yes, I think the "CDN-style" model could be a starting point for solving a class of mobility problems. A few things that are still unclear to me include: > > 1/ Can we use this rendezvous model for real-time communications like video/audio conferencing? Not sure how the indirection will affect the delays. > > 2/ If we plan to use Interest-Interest communication, how do we handle the case when the producer doesn't have a routable prefix (or doesn't know he has)? The Kite approach (i.e., using PIT to do reverse path forwarding) is a significant change to the architecture and I still don't understand the implication of this change yet. > > Wentao > > > On Thu Feb 19 2015 at 7:16:07 AM Mark Stapp wrote: >> >> Hi Wentao, >> >> On 2/15/15 2:18 PM, Wentao Shang wrote: >> > While any solution must be based on the specific application scenario, >> > there are still some general guidelines that you may consider: >> > >> >> [...] >> >> > >> > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as >> > indirection: you can have your producer publish its data to a well-known >> > location, such as an NDN repo, so that the consumer can fetch data from >> > the repo instead of talking to the producer directly. >> > >> >> hmm - that sure sounds like a CDN design, the kind that we use all the >> time - facebook, flickr, gmail. is that the kind of thing you had in >> mind? if so, as you know I agree, and I think there should be more focus >> on mechanisms that support this design. >> >> 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 tailinchu at gmail.com Fri Feb 20 08:04:30 2015 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Fri, 20 Feb 2015 08:04:30 -0800 Subject: [Ndn-interest] NDN-friendly Mobility solutions In-Reply-To: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2936@m-pdc.sbu.ac.ir> References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2936@m-pdc.sbu.ac.ir> Message-ID: I wrote a mechanism to solve another problem, but I think it is highly relevant. Please take a look :) Thanks. On Fri, Feb 20, 2015 at 2:15 AM, Muhammad Hosain Abdollahi Sabet wrote: > Despite the possibility of delay in repo-based solution, is it cost > effective? I mean, in a CDN-like solution we focus on caching(for > distributing contents), which in this scenario(real-time communication) is > not that usable because we are not going to use the produced data(from the > vice-chat application) again, right? > > > > On 20 Feb 2015 00:39, "Wentao Shang" wrote: >> >> Hi Mark, >> >> Yes, I think the "CDN-style" model could be a starting point for solving a >> class of mobility problems. A few things that are still unclear to me >> include: >> >> 1/ Can we use this rendezvous model for real-time communications like >> video/audio conferencing? Not sure how the indirection will affect the >> delays. >> >> 2/ If we plan to use Interest-Interest communication, how do we handle the >> case when the producer doesn't have a routable prefix (or doesn't know he >> has)? The Kite approach (i.e., using PIT to do reverse path forwarding) is a >> significant change to the architecture and I still don't understand the >> implication of this change yet. >> >> Wentao >> >> >> On Thu Feb 19 2015 at 7:16:07 AM Mark Stapp wrote: >>> >>> Hi Wentao, >>> >>> On 2/15/15 2:18 PM, Wentao Shang wrote: >>> > While any solution must be based on the specific application scenario, >>> > there are still some general guidelines that you may consider: >>> > >>> >>> [...] >>> >>> > >>> > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as >>> > indirection: you can have your producer publish its data to a >>> > well-known >>> > location, such as an NDN repo, so that the consumer can fetch data from >>> > the repo instead of talking to the producer directly. >>> > >>> >>> hmm - that sure sounds like a CDN design, the kind that we use all the >>> time - facebook, flickr, gmail. is that the kind of thing you had in >>> mind? if so, as you know I agree, and I think there should be more focus >>> on mechanisms that support this design. >>> >>> 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: REST.pdf Type: application/pdf Size: 154754 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mobility.pdf Type: application/pdf Size: 125093 bytes Desc: not available URL: From M.AbdollahiSabet at mail.sbu.ac.ir Fri Feb 20 09:39:35 2015 From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet) Date: Fri, 20 Feb 2015 21:09:35 +0330 Subject: [Ndn-interest] NDN-friendly Mobility solutions References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2936@m-pdc.sbu.ac.ir> Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2938@m-pdc.sbu.ac.ir> Well, I'm just looking from the perspective of mobility problem. Is there any problem or prevention if pendingData not be empty? I mean, in the real-time connection between mobile caller-callee, both parties are producer and consumer at the same time, right? So what if a pendingData carries the data the caller wants, and creates backward pit entries at the same time? In that case, we won't have an empty packet with each data transaction. Moreover we will have a kind of virtual dynamic circuit. If so, it seems there's a need to modify packet structure and add optional pendingData flag field(something like Kite). What if the producer moves after sending the pendingData? I couldn't get the use of personal repo clearly. Sorry if I'm asking too much. -----Original Message----- From: Tai-Lin Chu [mailto:tailinchu at gmail.com] Sent: Fri 2/20/2015 7:34 PM To: Muhammad Hosain Abdollahi Sabet Cc: ndn-interest at lists.cs.ucla.edu Subject: Re: [Ndn-interest] NDN-friendly Mobility solutions I wrote a mechanism to solve another problem, but I think it is highly relevant. Please take a look :) Thanks. On Fri, Feb 20, 2015 at 2:15 AM, Muhammad Hosain Abdollahi Sabet wrote: > Despite the possibility of delay in repo-based solution, is it cost > effective? I mean, in a CDN-like solution we focus on caching(for > distributing contents), which in this scenario(real-time communication) is > not that usable because we are not going to use the produced data(from the > vice-chat application) again, right? > > > > On 20 Feb 2015 00:39, "Wentao Shang" wrote: >> >> Hi Mark, >> >> Yes, I think the "CDN-style" model could be a starting point for solving a >> class of mobility problems. A few things that are still unclear to me >> include: >> >> 1/ Can we use this rendezvous model for real-time communications like >> video/audio conferencing? Not sure how the indirection will affect the >> delays. >> >> 2/ If we plan to use Interest-Interest communication, how do we handle the >> case when the producer doesn't have a routable prefix (or doesn't know he >> has)? The Kite approach (i.e., using PIT to do reverse path forwarding) is a >> significant change to the architecture and I still don't understand the >> implication of this change yet. >> >> Wentao >> >> >> On Thu Feb 19 2015 at 7:16:07 AM Mark Stapp wrote: >>> >>> Hi Wentao, >>> >>> On 2/15/15 2:18 PM, Wentao Shang wrote: >>> > While any solution must be based on the specific application scenario, >>> > there are still some general guidelines that you may consider: >>> > >>> >>> [...] >>> >>> > >>> > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as >>> > indirection: you can have your producer publish its data to a >>> > well-known >>> > location, such as an NDN repo, so that the consumer can fetch data from >>> > the repo instead of talking to the producer directly. >>> > >>> >>> hmm - that sure sounds like a CDN design, the kind that we use all the >>> time - facebook, flickr, gmail. is that the kind of thing you had in >>> mind? if so, as you know I agree, and I think there should be more focus >>> on mechanisms that support this design. >>> >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wentaoshang at gmail.com Fri Feb 20 09:50:14 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Fri, 20 Feb 2015 17:50:14 +0000 Subject: [Ndn-interest] NDN-friendly Mobility solutions References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2936@m-pdc.sbu.ac.ir> Message-ID: On Fri Feb 20 2015 at 2:17:27 AM Muhammad Hosain Abdollahi Sabet < M.AbdollahiSabet at mail.sbu.ac.ir> wrote: > Despite the possibility of delay in repo-based solution, is it cost > effective? I mean, in a CDN-like solution we focus on caching(for > distributing contents), which in this scenario(real-time communication) is > not that usable because we are not going to use the produced data(from the > vice-chat application) again, right? > The data can be reused in the scenario of multi-party conferencing or when the application needs auto-archiving and/or playback. Wentao > > ?? > On 20 Feb 2015 00:39, "Wentao Shang" wrote: > > > > Hi Mark, > > > > Yes, I think the "CDN-style" model could be a starting point for solving > a class of mobility problems. A few things that are still unclear to me > include: > > > > 1/ Can we use this rendezvous model for real-time communications like > video/audio conferencing? Not sure how the indirection will affect the > delays. > > > > 2/ If we plan to use Interest-Interest communication, how do we handle > the case when the producer doesn't have a routable prefix (or doesn't know > he has)? The Kite approach (i.e., using PIT to do reverse path forwarding) > is a significant change to the architecture and I still don't understand > the implication of this change yet. > > > > Wentao > > > > > > On Thu Feb 19 2015 at 7:16:07 AM Mark Stapp wrote: > >> > >> Hi Wentao, > >> > >> On 2/15/15 2:18 PM, Wentao Shang wrote: > >> > While any solution must be based on the specific application scenario, > >> > there are still some general guidelines that you may consider: > >> > > >> > >> [...] > >> > >> > > >> > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point as > >> > indirection: you can have your producer publish its data to a > well-known > >> > location, such as an NDN repo, so that the consumer can fetch data > from > >> > the repo instead of talking to the producer directly. > >> > > >> > >> hmm - that sure sounds like a CDN design, the kind that we use all the > >> time - facebook, flickr, gmail. is that the kind of thing you had in > >> mind? if so, as you know I agree, and I think there should be more focus > >> on mechanisms that support this design. > >> > >> 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 Fri Feb 20 12:51:32 2015 From: mjs at cisco.com (Mark Stapp) Date: Fri, 20 Feb 2015 15:51:32 -0500 Subject: [Ndn-interest] NDN-friendly Mobility solutions In-Reply-To: References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2930@m-pdc.sbu.ac.ir> <54E5FDAC.1000002@cisco.com> Message-ID: <54E79E54.2080107@cisco.com> On 2/19/15 4:08 PM, Wentao Shang wrote: > Hi Mark, > > Yes, I think the "CDN-style" model could be a starting point for solving > a class of mobility problems. A few things that are still unclear to me > include: > > 1/ Can we use this rendezvous model for real-time communications like > video/audio conferencing? Not sure how the indirection will affect the > delays. > there are plenty of familiar services - skype, webex, gotomeeting - that use a managed, distributed cdn service for rendezvous, at least. that allows clients with topological names (at home, at work, on mobile network) to rendezvous with one another. the clients can then communicate directly, having learned the necessary names from the rendezvous service. if one client is truly mobile (not likely at work, perhaps, but possible while transitioning from one network to another) that client can update the rendezvous service and it's possible the communication can recover without significant interruption. > 2/ If we plan to use Interest-Interest communication, how do we handle > the case when the producer doesn't have a routable prefix (or doesn't > know he has)? The Kite approach (i.e., using PIT to do reverse path > forwarding) is a significant change to the architecture and I still > don't understand the implication of this change yet. > I don't quite follow that remark about not having a routable name. if you can't be reached, if you don't have a routable name, then ... you can't be reached? I guess I expect that when an ndn host arrives on a network, it learns some routable name prefix - just as an IP host learns one or more addresses along with other necessary IP info from DHCP. that will be a topological name, controlled by the administrator of the network. I expect that'd be the same whether you're getting 'native' ndn service (at home, at work), or using a tunnel to some ndn provider (as folks use v6 tunnel brokers like HE when native v6 or dual-stack service is not available). -- Mark > On Thu Feb 19 2015 at 7:16:07 AM Mark Stapp > wrote: > > Hi Wentao, > > On 2/15/15 2:18 PM, Wentao Shang wrote: > > While any solution must be based on the specific application > scenario, > > there are still some general guidelines that you may consider: > > > > [...] > > > > > 3/ A more NDN-ish design (in my opinion) is to use rendezvous > point as > > indirection: you can have your producer publish its data to a > well-known > > location, such as an NDN repo, so that the consumer can fetch > data from > > the repo instead of talking to the producer directly. > > > > hmm - that sure sounds like a CDN design, the kind that we use all the > time - facebook, flickr, gmail. is that the kind of thing you had in > mind? if so, as you know I agree, and I think there should be more focus > on mechanisms that support this design. > > Thanks, > Mark > > _________________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/__mailman/listinfo/ndn-interest > > From wentaoshang at gmail.com Fri Feb 20 13:10:03 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Fri, 20 Feb 2015 21:10:03 +0000 Subject: [Ndn-interest] NDN-friendly Mobility solutions References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2930@m-pdc.sbu.ac.ir> <54E5FDAC.1000002@cisco.com> <54E79E54.2080107@cisco.com> Message-ID: On Fri Feb 20 2015 at 12:51:41 PM Mark Stapp wrote: > > > On 2/19/15 4:08 PM, Wentao Shang wrote: > > Hi Mark, > > > > Yes, I think the "CDN-style" model could be a starting point for solving > > a class of mobility problems. A few things that are still unclear to me > > include: > > > > 1/ Can we use this rendezvous model for real-time communications like > > video/audio conferencing? Not sure how the indirection will affect the > > delays. > > > > there are plenty of familiar services - skype, webex, gotomeeting - that > use a managed, distributed cdn service for rendezvous, at least. that > allows clients with topological names (at home, at work, on mobile > network) to rendezvous with one another. the clients can then > communicate directly, having learned the necessary names from the > rendezvous service. if one client is truly mobile (not likely at work, > perhaps, but possible while transitioning from one network to another) > that client can update the rendezvous service and it's possible the > communication can recover without significant interruption. > > > > 2/ If we plan to use Interest-Interest communication, how do we handle > > the case when the producer doesn't have a routable prefix (or doesn't > > know he has)? The Kite approach (i.e., using PIT to do reverse path > > forwarding) is a significant change to the architecture and I still > > don't understand the implication of this change yet. > > > > I don't quite follow that remark about not having a routable name. if > you can't be reached, if you don't have a routable name, then ... you > can't be reached? I guess I expect that when an ndn host arrives on a > network, it learns some routable name prefix - just as an IP host learns > one or more addresses along with other necessary IP info from DHCP. This is true. But what if the producer wants to publish data under some provider-independent identity while he is moving across networks? The mobile device may be reachable via some local prefix but the data may be under a different prefix. E.g., I always want to publish data under /ucla/cs/wentao prefix while I'm moving from my office to my TWC homenet, or even back to China... Wentao > that > will be a topological name, controlled by the administrator of the > network. I expect that'd be the same whether you're getting 'native' ndn > service (at home, at work), or using a tunnel to some ndn provider (as > folks use v6 tunnel brokers like HE when native v6 or dual-stack service > is not available). > > -- Mark > > > On Thu Feb 19 2015 at 7:16:07 AM Mark Stapp > > wrote: > > > > Hi Wentao, > > > > On 2/15/15 2:18 PM, Wentao Shang wrote: > > > While any solution must be based on the specific application > > scenario, > > > there are still some general guidelines that you may consider: > > > > > > > [...] > > > > > > > > 3/ A more NDN-ish design (in my opinion) is to use rendezvous > > point as > > > indirection: you can have your producer publish its data to a > > well-known > > > location, such as an NDN repo, so that the consumer can fetch > > data from > > > the repo instead of talking to the producer directly. > > > > > > > hmm - that sure sounds like a CDN design, the kind that we use all > the > > time - facebook, flickr, gmail. is that the kind of thing you had in > > mind? if so, as you know I agree, and I think there should be more > focus > > on mechanisms that support this design. > > > > Thanks, > > Mark > > > > _________________________________________________ > > Ndn-interest mailing list > > Ndn-interest at lists.cs.ucla.edu 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 Fri Feb 20 13:38:44 2015 From: mjs at cisco.com (Mark Stapp) Date: Fri, 20 Feb 2015 16:38:44 -0500 Subject: [Ndn-interest] NDN-friendly Mobility solutions In-Reply-To: References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2930@m-pdc.sbu.ac.ir> <54E5FDAC.1000002@cisco.com> <54E79E54.2080107@cisco.com> Message-ID: <54E7A964.60806@cisco.com> On 2/20/15 4:10 PM, Wentao Shang wrote: [...] > I don't quite follow that remark about not having a routable name. if > you can't be reached, if you don't have a routable name, then ... you > can't be reached? I guess I expect that when an ndn host arrives on a > network, it learns some routable name prefix - just as an IP host learns > one or more addresses along with other necessary IP info from DHCP. > > > This is true. But what if the producer wants to publish data under some > provider-independent identity while he is moving across networks? The > mobile device may be reachable via some local prefix but the data may be > under a different prefix. E.g., I always want to publish data under > /ucla/cs/wentao prefix while I'm moving from my office to my TWC > homenet, or even back to China... > > Wentao > I know folks throw that hypothetical out there, but ... what is this "data", exactly? if it's a skype call, we've sort of talked about how that might work. if it's flickr photos, or facebook stuff, that doesn't seem too different. if you want to put something else somewhere on the ucla network, accessible via a "ucla.edu" name prefix, that should work too, just as if you updated ucla-hosted wiki or redmine, instance. an issue there might be whose keys are involved, I guess - does ucla vouch for _you_ directly, with ucla credentials of some kind? or does ucla delegate some new credential to you, valid for some entire subtree of ucla namespace? or do you have your own "wentao" credential, something independent of ucla, that folks trust whether your stuff comes from ucla, facebook, skype, etc. ? just what is it that you want to "publish" from ucla's namespace while travelling? Thanks, Mark From wentaoshang at gmail.com Fri Feb 20 13:46:44 2015 From: wentaoshang at gmail.com (Wentao Shang) Date: Fri, 20 Feb 2015 21:46:44 +0000 Subject: [Ndn-interest] NDN-friendly Mobility solutions References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2930@m-pdc.sbu.ac.ir> <54E5FDAC.1000002@cisco.com> <54E79E54.2080107@cisco.com> <54E7A964.60806@cisco.com> Message-ID: On Fri Feb 20 2015 at 1:38:44 PM Mark Stapp wrote: > On 2/20/15 4:10 PM, Wentao Shang wrote: > [...] > > I don't quite follow that remark about not having a routable name. if > > you can't be reached, if you don't have a routable name, then ... you > > can't be reached? I guess I expect that when an ndn host arrives on a > > network, it learns some routable name prefix - just as an IP host > learns > > one or more addresses along with other necessary IP info from DHCP. > > > > > > This is true. But what if the producer wants to publish data under some > > provider-independent identity while he is moving across networks? The > > mobile device may be reachable via some local prefix but the data may be > > under a different prefix. E.g., I always want to publish data under > > /ucla/cs/wentao prefix while I'm moving from my office to my TWC > > homenet, or even back to China... > > > > Wentao > > > > I know folks throw that hypothetical out there, but ... what is this > "data", exactly? if it's a skype call, we've sort of talked about how > that might work. if it's flickr photos, or facebook stuff, that doesn't > seem too different. if you want to put something else somewhere on the > ucla network, accessible via a "ucla.edu" name prefix, that should work > too, just as if you updated ucla-hosted wiki or redmine, instance. an > issue there might be whose keys are involved, I guess - does ucla vouch > for _you_ directly, with ucla credentials of some kind? or does ucla > delegate some new credential to you, valid for some entire subtree of > ucla namespace? or do you have your own "wentao" credential, something > independent of ucla, that folks trust whether your stuff comes from > ucla, facebook, skype, etc. ? > Yes. The main reason to use a fixed identity is to simplify the trust model. Otherwise you either create a complicated trust model (which may not be possible at all if your prefix in a foreign network is not permanent) or get multiple certificates from different networks where you may publish something... Wentao > > just what is it that you want to "publish" from ucla's namespace while > travelling? > > Thanks, > Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tailinchu at gmail.com Fri Feb 20 15:20:37 2015 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Fri, 20 Feb 2015 15:20:37 -0800 Subject: [Ndn-interest] NDN-friendly Mobility solutions In-Reply-To: <54E79E54.2080107@cisco.com> References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC292D@m-pdc.sbu.ac.ir> <7A8FCB16-0AD1-4EB1-BB60-4569CCC5F694@cs.ucla.edu> <4AC03A6244C3C34BB52A7EC60B799C4C03CC292F@m-pdc.sbu.ac.ir> <4AC03A6244C3C34BB52A7EC60B799C4C03CC2930@m-pdc.sbu.ac.ir> <54E5FDAC.1000002@cisco.com> <54E79E54.2080107@cisco.com> Message-ID: > there are plenty of familiar services - skype, webex, gotomeeting - that use a managed, distributed cdn service for rendezvous, at least. that allows clients with topological names (at home, at work, on mobile network) to rendezvous with one another. The situation is very different if we want to do this purely in ndn. > I don't quite follow that remark about not having a routable name. if you can't be reached, if you don't have a routable name, then ... you can't be reached? there are two different scenarios: 1. you dont have a routable name; It is ok that you can never spread information (publish data)? 2. you have a routable name; how long you have to wait til routing update finishes in order to publish data globally in a new location? I believe pendingData is a relatively simple solution. On Fri, Feb 20, 2015 at 12:51 PM, Mark Stapp wrote: > > > On 2/19/15 4:08 PM, Wentao Shang wrote: >> >> Hi Mark, >> >> Yes, I think the "CDN-style" model could be a starting point for solving >> a class of mobility problems. A few things that are still unclear to me >> include: >> >> 1/ Can we use this rendezvous model for real-time communications like >> video/audio conferencing? Not sure how the indirection will affect the >> delays. >> > > there are plenty of familiar services - skype, webex, gotomeeting - that use > a managed, distributed cdn service for rendezvous, at least. that allows > clients with topological names (at home, at work, on mobile network) to > rendezvous with one another. the clients can then communicate directly, > having learned the necessary names from the rendezvous service. if one > client is truly mobile (not likely at work, perhaps, but possible while > transitioning from one network to another) that client can update the > rendezvous service and it's possible the communication can recover without > significant interruption. > > >> 2/ If we plan to use Interest-Interest communication, how do we handle >> the case when the producer doesn't have a routable prefix (or doesn't >> know he has)? The Kite approach (i.e., using PIT to do reverse path >> forwarding) is a significant change to the architecture and I still >> don't understand the implication of this change yet. >> > > I don't quite follow that remark about not having a routable name. if you > can't be reached, if you don't have a routable name, then ... you can't be > reached? I guess I expect that when an ndn host arrives on a network, it > learns some routable name prefix - just as an IP host learns one or more > addresses along with other necessary IP info from DHCP. that will be a > topological name, controlled by the administrator of the network. I expect > that'd be the same whether you're getting 'native' ndn service (at home, at > work), or using a tunnel to some ndn provider (as folks use v6 tunnel > brokers like HE when native v6 or dual-stack service is not available). > > -- Mark > >> On Thu Feb 19 2015 at 7:16:07 AM Mark Stapp > > wrote: >> >> Hi Wentao, >> >> On 2/15/15 2:18 PM, Wentao Shang wrote: >> > While any solution must be based on the specific application >> scenario, >> > there are still some general guidelines that you may consider: >> > >> >> [...] >> >> > >> > 3/ A more NDN-ish design (in my opinion) is to use rendezvous >> point as >> > indirection: you can have your producer publish its data to a >> well-known >> > location, such as an NDN repo, so that the consumer can fetch >> data from >> > the repo instead of talking to the producer directly. >> > >> >> hmm - that sure sounds like a CDN design, the kind that we use all the >> time - facebook, flickr, gmail. is that the kind of thing you had in >> mind? if so, as you know I agree, and I think there should be more >> focus >> on mechanisms that support this design. >> >> 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 Fri Feb 20 15:42:48 2015 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Fri, 20 Feb 2015 15:42:48 -0800 Subject: [Ndn-interest] NDN-friendly Mobility solutions In-Reply-To: References: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2936@m-pdc.sbu.ac.ir> Message-ID: > Well, I'm just looking from the perspective of mobility problem. Is there any problem or prevention if pendingData not be empty? In case of pendingData, mobile caller has something to send but static callee doesn't. The other direction is supported by ndn already. > If so, it seems there's a need to modify packet structure and add optional pendingData flag field(something like Kite). I prefer not to add additional field, but implement this with a new ContentType: "pendingData" (0x3). (IMHO, we should try to remove field by making packet format flexible.) > What if the producer moves after sending the pendingData? In my pdf, pendingData's mechanism is just like regular interest in pending interest table. So unlike Kite, no additional table is needed. After the producer moves, the pendingData cannot get satisfied. The producer can efficiently start over. On Fri, Feb 20, 2015 at 9:50 AM, Wentao Shang wrote: > > > On Fri Feb 20 2015 at 2:17:27 AM Muhammad Hosain Abdollahi Sabet > wrote: >> >> Despite the possibility of delay in repo-based solution, is it cost >> effective? I mean, in a CDN-like solution we focus on caching(for >> distributing contents), which in this scenario(real-time communication) is >> not that usable because we are not going to use the produced data(from the >> vice-chat application) again, right? > > The data can be reused in the scenario of multi-party conferencing or when > the application needs auto-archiving and/or playback. > > Wentao > >> >> >> >> On 20 Feb 2015 00:39, "Wentao Shang" wrote: >> > >> > Hi Mark, >> > >> > Yes, I think the "CDN-style" model could be a starting point for solving >> > a class of mobility problems. A few things that are still unclear to me >> > include: >> > >> > 1/ Can we use this rendezvous model for real-time communications like >> > video/audio conferencing? Not sure how the indirection will affect the >> > delays. >> > >> > 2/ If we plan to use Interest-Interest communication, how do we handle >> > the case when the producer doesn't have a routable prefix (or doesn't know >> > he has)? The Kite approach (i.e., using PIT to do reverse path forwarding) >> > is a significant change to the architecture and I still don't understand the >> > implication of this change yet. >> > >> > Wentao >> > >> > >> > On Thu Feb 19 2015 at 7:16:07 AM Mark Stapp wrote: >> >> >> >> Hi Wentao, >> >> >> >> On 2/15/15 2:18 PM, Wentao Shang wrote: >> >> > While any solution must be based on the specific application >> >> > scenario, >> >> > there are still some general guidelines that you may consider: >> >> > >> >> >> >> [...] >> >> >> >> > >> >> > 3/ A more NDN-ish design (in my opinion) is to use rendezvous point >> >> > as >> >> > indirection: you can have your producer publish its data to a >> >> > well-known >> >> > location, such as an NDN repo, so that the consumer can fetch data >> >> > from >> >> > the repo instead of talking to the producer directly. >> >> > >> >> >> >> hmm - that sure sounds like a CDN design, the kind that we use all the >> >> time - facebook, flickr, gmail. is that the kind of thing you had in >> >> mind? if so, as you know I agree, and I think there should be more >> >> focus >> >> on mechanisms that support this design. >> >> >> >> 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 jlee700 at illinois.EDU Mon Feb 23 02:31:50 2015 From: jlee700 at illinois.EDU (Lee, Jongdeog) Date: Mon, 23 Feb 2015 10:31:50 +0000 Subject: [Ndn-interest] Exclude selector Message-ID: Dear all, I have a question on the exclude selector. Suppose that a provider has two data objects (/test/A/B, /test/C/D). Now a consumer issues the interest packet with the prefix "/test". Then, the consumer will get "/test/A/B". Now the consumer wants to request the next item using the exclude selector. The interest would be "/test ". However, the exclude can only specify a single level such as or or . Does anybody know how to express two or more levels in exclude? My guess is to use the appendExclude function, but not sure how to use it. Best, Jongdeog Lee (JD) ------------------------------------------------ Ph.D. Student Department of Computer Science University of Illinois at Urbana-Champaign -------------- next part -------------- An HTML attachment was scrubbed... URL: From raf.lastella at gmail.com Mon Feb 23 02:40:14 2015 From: raf.lastella at gmail.com (raffaele lastella) Date: Mon, 23 Feb 2015 11:40:14 +0100 Subject: [Ndn-interest] NLSR on Raspberry Pi Message-ID: Hi, following your guide ( http://redmine.named-data.net/projects/ndn-embedded/wiki/Cross-compiling_NDN_projects_for_Raspberry_Pi) I've successfully cross-compiled both NFD and ndn-cxx at their last releases (0.3.0) for Raspberry Pi. They work as a charm. I've also tried to cross-compile NLSR following similar rules and I did it, but once on Raspberry the nlsr executable seems to not work. While nfd is up, nlsr is not able to connect to it and says: ERROR: error while connecting to the forwarder I haven't found any reference about cross-compiling NLSR for Raspberry. At this time, is it possible to have NLSR on Raspberry or I simply missed something? Best regards Raffaele Lastella -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Mon Feb 23 06:54:43 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 23 Feb 2015 07:54:43 -0700 Subject: [Ndn-interest] NLSR on Raspberry Pi In-Reply-To: References: Message-ID: Hi Raffaele This doesn't look like a cross-compilation issue of NLSR. This error message means either NFD is not running, or the app (such as NLSR) isn't configured to connect to the correct socket. Are you able to run `ndn-tlv-peek /` successfully? Yours, Junxiao On Feb 23, 2015 7:51 AM, "raffaele lastella" wrote: > Hi, > following your guide ( > http://redmine.named-data.net/projects/ndn-embedded/wiki/Cross-compiling_NDN_projects_for_Raspberry_Pi) > I've successfully cross-compiled both NFD and ndn-cxx at their last > releases (0.3.0) for Raspberry Pi. They work as a charm. > > I've also tried to cross-compile NLSR following similar rules and I did > it, but once on Raspberry the nlsr executable seems to not work. > While nfd is up, nlsr is not able to connect to it and says: > ERROR: error while connecting to the forwarder > > I haven't found any reference about cross-compiling NLSR for Raspberry. > At this time, is it possible to have NLSR on Raspberry or I simply missed > something? > > Best regards > Raffaele Lastella > > _______________________________________________ > 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 Mon Feb 23 06:57:27 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 23 Feb 2015 07:57:27 -0700 Subject: [Ndn-interest] Exclude selector In-Reply-To: References: Message-ID: Hi Jongdeog You can't Exclude multiple levels. Express two Interests: * /test, Exclude=A * /test/A, Exclude=B At least one of them would retrieve what you want. Yours, Junxiao On Feb 23, 2015 3:32 AM, "Lee, Jongdeog" wrote: > Dear all, > > I have a question on the exclude selector. > > Suppose that a provider has two data objects (/test/A/B, /test/C/D). > Now a consumer issues the interest packet with the prefix "/test". Then, > the consumer will get "/test/A/B". > > Now the consumer wants to request the next item using the exclude > selector. > The interest would be "/test ". However, the exclude can > only specify a single level such as or or > . Does anybody know how to express two or more levels in > exclude? My guess is to use the appendExclude function, but not sure how to > use it. > > Best, > Jongdeog Lee (JD) > > ------------------------------------------------ > *Ph.D. Student* > *Department of Computer Science* > *University of Illinois at Urbana-Champaign* > > _______________________________________________ > 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 raf.lastella at gmail.com Mon Feb 23 07:52:09 2015 From: raf.lastella at gmail.com (raffaele lastella) Date: Mon, 23 Feb 2015 16:52:09 +0100 Subject: [Ndn-interest] NLSR on Raspberry Pi In-Reply-To: References: Message-ID: Hi Junxiao, Yes, I can run ndn-tlv-peek successfully. I see strange ASCII characters on the shell (maybe it's OK) but there aren't wrong connection issues wiht NFD. I also tested NFD with the Producer/Consumer applications and it works fine. Concerning the NLSR configuration file and certificates, I'm using the same stuff that works on a Linux machine. I can't understand why it doesn't work on Raspberry, As a hint, I can say that I've cross-compiled NFD without WebSocket support. Is that a problem? Thanks Raffaele 2015-02-23 15:54 GMT+01:00 Junxiao Shi : > Hi Raffaele > > This doesn't look like a cross-compilation issue of NLSR. > This error message means either NFD is not running, or the app (such as > NLSR) isn't configured to connect to the correct socket. > > Are you able to run `ndn-tlv-peek /` successfully? > > Yours, Junxiao > On Feb 23, 2015 7:51 AM, "raffaele lastella" > wrote: > >> Hi, >> following your guide ( >> http://redmine.named-data.net/projects/ndn-embedded/wiki/Cross-compiling_NDN_projects_for_Raspberry_Pi) >> I've successfully cross-compiled both NFD and ndn-cxx at their last >> releases (0.3.0) for Raspberry Pi. They work as a charm. >> >> I've also tried to cross-compile NLSR following similar rules and I did >> it, but once on Raspberry the nlsr executable seems to not work. >> While nfd is up, nlsr is not able to connect to it and says: >> ERROR: error while connecting to the forwarder >> >> I haven't found any reference about cross-compiling NLSR for Raspberry. >> At this time, is it possible to have NLSR on Raspberry or I simply missed >> something? >> >> Best regards >> Raffaele Lastella >> >> _______________________________________________ >> 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 lanwang at memphis.edu Tue Feb 24 06:35:31 2015 From: lanwang at memphis.edu (Lan Wang (lanwang)) Date: Tue, 24 Feb 2015 14:35:31 +0000 Subject: [Ndn-interest] NLSR on Raspberry Pi In-Reply-To: References: Message-ID: On Feb 23, 2015, at 4:40 AM, raffaele lastella > wrote: Hi, following your guide (http://redmine.named-data.net/projects/ndn-embedded/wiki/Cross-compiling_NDN_projects_for_Raspberry_Pi) I've successfully cross-compiled both NFD and ndn-cxx at their last releases (0.3.0) for Raspberry Pi. They work as a charm. I've also tried to cross-compile NLSR following similar rules and I did it, but once on Raspberry the nlsr executable seems to not work. While nfd is up, nlsr is not able to connect to it and says: ERROR: error while connecting to the forwarder On some machines/OSes, you need to wait for a few seconds after nfd starts before starting NLSR. If this is not the cause, you can send your NLSR and NFD logs to vslehman at memphis.edu. Lan I haven't found any reference about cross-compiling NLSR for Raspberry. At this time, is it possible to have NLSR on Raspberry or I simply missed something? Best regards Raffaele Lastella _______________________________________________ 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 raf.lastella at gmail.com Wed Feb 25 01:11:56 2015 From: raf.lastella at gmail.com (raffaele lastella) Date: Wed, 25 Feb 2015 10:11:56 +0100 Subject: [Ndn-interest] NLSR on Raspberry Pi In-Reply-To: References: Message-ID: Hi Lan, Thanks for your answer. I'll try to contact Vince sending him the logs. Regards Raffaele 2015-02-24 15:35 GMT+01:00 Lan Wang (lanwang) : > > On Feb 23, 2015, at 4:40 AM, raffaele lastella > wrote: > > Hi, > following your guide ( > http://redmine.named-data.net/projects/ndn-embedded/wiki/Cross-compiling_NDN_projects_for_Raspberry_Pi) > I've successfully cross-compiled both NFD and ndn-cxx at their last > releases (0.3.0) for Raspberry Pi. They work as a charm. > > I've also tried to cross-compile NLSR following similar rules and I did > it, but once on Raspberry the nlsr executable seems to not work. > While nfd is up, nlsr is not able to connect to it and says: > ERROR: error while connecting to the forwarder > > > On some machines/OSes, you need to wait for a few seconds after nfd > starts before starting NLSR. If this is not the cause, you can send your > NLSR and NFD logs to vslehman at memphis.edu. > > Lan > > > I haven't found any reference about cross-compiling NLSR for Raspberry. > At this time, is it possible to have NLSR on Raspberry or I simply missed > something? > > Best regards > Raffaele Lastella > _______________________________________________ > 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 bassem.labib at gmail.com Wed Feb 25 07:05:28 2015 From: bassem.labib at gmail.com (Bassem Labib) Date: Wed, 25 Feb 2015 17:05:28 +0200 Subject: [Ndn-interest] [jndn] Remote prefix registration (#6) In-Reply-To: References: Message-ID: Hi Jeff, While I'm testing the jndn to register a Prefix using *TestPublishAsyncNfd.java* under *test* package, It works fine and register the "/testecho" prefix successfully only when using the default host Face or using "localhost" and loop back address "127.0.0.1", *but* when using the IP address assigned to the same machine as "192.168.1.9"* it didn't work (Timeout)* and I notes it registers on *NDNx* and print out the following: Register prefix /testecho Feb 25, 2015 4:40:45 PM net.named_data.jndn.Node$RegisterResponse onTimeout INFO: Timeout for NFD register prefix command. Attempting an NDNx command... Feb 25, 2015 4:40:49 PM net.named_data.jndn.Node$NdndIdFetcher onTimeout INFO: Register prefix failed: Timeout fetching the NDNx ID Register failed for prefix /testecho please help, I need an explain this situation. Best Regards, Bassem Labib -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Feb 25 07:16:09 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 25 Feb 2015 08:16:09 -0700 Subject: [Ndn-interest] [jndn] Remote prefix registration (#6) In-Reply-To: References: Message-ID: Hi Bassem jndn currently supports localhost prefix registration only. NFD treats loopback address as localhost. 192.168.1.9 is not a loopback address despite that it's on same machine. A localhost registration, when sent to a non-local face, will be silently rejected. It's intentional for NFD to interpret non-loopback address of same machine as non-local, otherwise proxy app for new socket type or wire format won't be able to create a non-local face without requiring a separate machine. Yours, Junxiao On Feb 25, 2015 8:06 AM, "Bassem Labib" wrote: > Hi Jeff, > > While I'm testing the jndn to register a Prefix using > *TestPublishAsyncNfd.java* under *test* package, It works fine and > register the "/testecho" prefix successfully only when using the default > host Face or using "localhost" and loop back address "127.0.0.1", *but* > when using the IP address assigned to the same machine as "192.168.1.9"* > it didn't work (Timeout)* and I notes it registers on *NDNx* and print > out the following: > > Register prefix /testecho > Feb 25, 2015 4:40:45 PM net.named_data.jndn.Node$RegisterResponse onTimeout > INFO: Timeout for NFD register prefix command. Attempting an NDNx > command... > Feb 25, 2015 4:40:49 PM net.named_data.jndn.Node$NdndIdFetcher onTimeout > INFO: Register prefix failed: Timeout fetching the NDNx ID > Register failed for prefix /testecho > > please help, I need an explain this situation. > > Best Regards, > Bassem Labib > > > _______________________________________________ > 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 bassem.labib at gmail.com Wed Feb 25 08:26:51 2015 From: bassem.labib at gmail.com (Bassem Labib) Date: Wed, 25 Feb 2015 18:26:51 +0200 Subject: [Ndn-interest] [jndn] Remote prefix registration (#6) In-Reply-To: References: Message-ID: Hi Junxiao, Actually I am surprised when you said: *'jndn currently supports localhost prefix registration only.'* So, how can I implement the clients to do prefix registration and sharing the files between each other? Is there any solution to let external/non-local machines to make the registration? On the other hand, does the same happend for express Interest too? Please advice. Best Regards, Bassem Labib On Wed, Feb 25, 2015 at 5:16 PM, Junxiao Shi wrote: > Hi Bassem > > jndn currently supports localhost prefix registration only. > NFD treats loopback address as localhost. 192.168.1.9 is not a loopback > address despite that it's on same machine. > A localhost registration, when sent to a non-local face, will be silently > rejected. > > It's intentional for NFD to interpret non-loopback address of same machine > as non-local, otherwise proxy app for new socket type or wire format > won't be able to create a non-local face without requiring a separate > machine. > > Yours, Junxiao > On Feb 25, 2015 8:06 AM, "Bassem Labib" wrote: > >> Hi Jeff, >> >> While I'm testing the jndn to register a Prefix using >> *TestPublishAsyncNfd.java* under *test* package, It works fine and >> register the "/testecho" prefix successfully only when using the default >> host Face or using "localhost" and loop back address "127.0.0.1", *but* >> when using the IP address assigned to the same machine as "192.168.1.9"* >> it didn't work (Timeout)* and I notes it registers on *NDNx* and print >> out the following: >> >> Register prefix /testecho >> Feb 25, 2015 4:40:45 PM net.named_data.jndn.Node$RegisterResponse >> onTimeout >> INFO: Timeout for NFD register prefix command. Attempting an NDNx >> command... >> Feb 25, 2015 4:40:49 PM net.named_data.jndn.Node$NdndIdFetcher onTimeout >> INFO: Register prefix failed: Timeout fetching the NDNx ID >> Register failed for prefix /testecho >> >> please help, I need an explain this situation. >> >> Best Regards, >> Bassem Labib >> >> >> _______________________________________________ >> 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 Feb 25 08:37:47 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 25 Feb 2015 09:37:47 -0700 Subject: [Ndn-interest] [jndn] Remote prefix registration (#6) In-Reply-To: References: Message-ID: <54edfa51.a2c2440a.75ab.72cd@mx.google.com> Hi Bassem To create a file transfer app between two laptops without a third router: 1. both laptops need NFD running 2. on laptopA, write a producer app that does local prefix registration 3. on laptopB, use nfdc command line or NFD Management protocol to create a face toward laptopA, and register a prefix using local prefix registration with that face as nexthop 4. on laptopB, write a consumer app that expresses Interests for the prefix Remote prefix registration isn't needed in this solution. Yours, Junxiao -----Original Message----- From: "Bassem Labib" Sent: ?2/?25/?2015 9:27 To: "Junxiao Shi" Cc: "ndn-interest at lists.cs.ucla.edu" ; "Jeff Burke" Subject: Re: [Ndn-interest] [jndn] Remote prefix registration (#6) Hi Junxiao, Actually I am surprised when you said: 'jndn currently supports localhost prefix registration only.' So, how can I implement the clients to do prefix registration and sharing the files between each other? Is there any solution to let external/non-local machines to make the registration? On the other hand, does the same happend for express Interest too? Please advice. Best Regards, Bassem Labib On Wed, Feb 25, 2015 at 5:16 PM, Junxiao Shi wrote: Hi Bassem jndn currently supports localhost prefix registration only. NFD treats loopback address as localhost. 192.168.1.9 is not a loopback address despite that it's on same machine. A localhost registration, when sent to a non-local face, will be silently rejected. It's intentional for NFD to interpret non-loopback address of same machine as non-local, otherwise proxy app for new socket type or wire format won't be able to create a non-local face without requiring a separate machine. Yours, Junxiao On Feb 25, 2015 8:06 AM, "Bassem Labib" wrote: Hi Jeff, While I'm testing the jndn to register a Prefix using TestPublishAsyncNfd.java under test package, It works fine and register the "/testecho" prefix successfully only when using the default host Face or using "localhost" and loop back address "127.0.0.1", but when using the IP address assigned to the same machine as "192.168.1.9" it didn't work (Timeout) and I notes it registers on NDNx and print out the following: Register prefix /testecho Feb 25, 2015 4:40:45 PM net.named_data.jndn.Node$RegisterResponse onTimeout INFO: Timeout for NFD register prefix command. Attempting an NDNx command... Feb 25, 2015 4:40:49 PM net.named_data.jndn.Node$NdndIdFetcher onTimeout INFO: Register prefix failed: Timeout fetching the NDNx ID Register failed for prefix /testecho please help, I need an explain this situation. Best Regards, Bassem Labib _______________________________________________ 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 jefft0 at remap.UCLA.EDU Wed Feb 25 08:39:07 2015 From: jefft0 at remap.UCLA.EDU (Thompson, Jeff) Date: Wed, 25 Feb 2015 16:39:07 +0000 Subject: [Ndn-interest] [jndn] Remote prefix registration (#6) In-Reply-To: References: Message-ID: An API for remote prefix registration om iNDN is being discussed at this Redmine issue: http://redmine.named-data.net/issues/2532 From: Bassem Labib > Date: Wednesday, February 25, 2015 at 8:26 To: Junxiao Shi > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] [jndn] Remote prefix registration (#6) Hi Junxiao, Actually I am surprised when you said: 'jndn currently supports localhost prefix registration only.' So, how can I implement the clients to do prefix registration and sharing the files between each other? Is there any solution to let external/non-local machines to make the registration? On the other hand, does the same happend for express Interest too? Please advice. Best Regards, Bassem Labib On Wed, Feb 25, 2015 at 5:16 PM, Junxiao Shi > wrote: Hi Bassem jndn currently supports localhost prefix registration only. NFD treats loopback address as localhost. 192.168.1.9 is not a loopback address despite that it's on same machine. A localhost registration, when sent to a non-local face, will be silently rejected. It's intentional for NFD to interpret non-loopback address of same machine as non-local, otherwise proxy app for new socket type or wire format won't be able to create a non-local face without requiring a separate machine. Yours, Junxiao On Feb 25, 2015 8:06 AM, "Bassem Labib" > wrote: Hi Jeff, While I'm testing the jndn to register a Prefix using TestPublishAsyncNfd.java under test package, It works fine and register the "/testecho" prefix successfully only when using the default host Face or using "localhost" and loop back address "127.0.0.1", but when using the IP address assigned to the same machine as "192.168.1.9" it didn't work (Timeout) and I notes it registers on NDNx and print out the following: Register prefix /testecho Feb 25, 2015 4:40:45 PM net.named_data.jndn.Node$RegisterResponse onTimeout INFO: Timeout for NFD register prefix command. Attempting an NDNx command... Feb 25, 2015 4:40:49 PM net.named_data.jndn.Node$NdndIdFetcher onTimeout INFO: Register prefix failed: Timeout fetching the NDNx ID Register failed for prefix /testecho please help, I need an explain this situation. Best Regards, Bassem Labib _______________________________________________ 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 jefft0 at remap.UCLA.EDU Wed Feb 25 08:40:30 2015 From: jefft0 at remap.UCLA.EDU (Thompson, Jeff) Date: Wed, 25 Feb 2015 16:40:30 +0000 Subject: [Ndn-interest] [jndn] Remote prefix registration (#6) In-Reply-To: <54edfa51.a2c2440a.75ab.72cd@mx.google.com> References: <54edfa51.a2c2440a.75ab.72cd@mx.google.com> Message-ID: Junxiao is right. If you are able to run NFD locally, it is better to do this and use nfdc to route to the remote forwarder. - Jeff T From: Junxiao Shi > Date: Wednesday, February 25, 2015 at 8:37 To: Bassem Labib > Cc: "ndn-interest at lists.cs.ucla.edu" > Subject: Re: [Ndn-interest] [jndn] Remote prefix registration (#6) Hi Bassem To create a file transfer app between two laptops without a third router: 1. both laptops need NFD running 2. on laptopA, write a producer app that does local prefix registration 3. on laptopB, use nfdc command line or NFD Management protocol to create a face toward laptopA, and register a prefix using local prefix registration with that face as nexthop 4. on laptopB, write a consumer app that expresses Interests for the prefix Remote prefix registration isn't needed in this solution. Yours, Junxiao ________________________________ From: Bassem Labib Sent: ?2/?25/?2015 9:27 To: Junxiao Shi Cc: ndn-interest at lists.cs.ucla.edu; Jeff Burke Subject: Re: [Ndn-interest] [jndn] Remote prefix registration (#6) Hi Junxiao, Actually I am surprised when you said: 'jndn currently supports localhost prefix registration only.' So, how can I implement the clients to do prefix registration and sharing the files between each other? Is there any solution to let external/non-local machines to make the registration? On the other hand, does the same happend for express Interest too? Please advice. Best Regards, Bassem Labib On Wed, Feb 25, 2015 at 5:16 PM, Junxiao Shi > wrote: Hi Bassem jndn currently supports localhost prefix registration only. NFD treats loopback address as localhost. 192.168.1.9 is not a loopback address despite that it's on same machine. A localhost registration, when sent to a non-local face, will be silently rejected. It's intentional for NFD to interpret non-loopback address of same machine as non-local, otherwise proxy app for new socket type or wire format won't be able to create a non-local face without requiring a separate machine. Yours, Junxiao On Feb 25, 2015 8:06 AM, "Bassem Labib" > wrote: Hi Jeff, While I'm testing the jndn to register a Prefix using TestPublishAsyncNfd.java under test package, It works fine and register the "/testecho" prefix successfully only when using the default host Face or using "localhost" and loop back address "127.0.0.1", but when using the IP address assigned to the same machine as "192.168.1.9" it didn't work (Timeout) and I notes it registers on NDNx and print out the following: Register prefix /testecho Feb 25, 2015 4:40:45 PM net.named_data.jndn.Node$RegisterResponse onTimeout INFO: Timeout for NFD register prefix command. Attempting an NDNx command... Feb 25, 2015 4:40:49 PM net.named_data.jndn.Node$NdndIdFetcher onTimeout INFO: Register prefix failed: Timeout fetching the NDNx ID Register failed for prefix /testecho please help, I need an explain this situation. Best Regards, Bassem Labib _______________________________________________ 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 Feb 25 10:58:27 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 25 Feb 2015 11:58:27 -0700 Subject: [Ndn-interest] [jndn] Remote prefix registration (#6) In-Reply-To: References: <54edfa51.a2c2440a.75ab.72cd@mx.google.com> Message-ID: Hi Bassem Mobile devices can run NFD as well. It's useful for mobile devices to have forwarding intelligence instead of acting as dumb clients, because they may be multi-homed and there's a choice on which link to use (eg. expensive LTE or slow WiFi?). NFD-android project is an ongoing effort on running NFD on stock Android. https://github.com/named-data/NFD-android Yours, Junxiao On Feb 25, 2015 11:53 AM, "Bassem Labib" wrote: > > Hello Junxiao, Jeff, > > My Clients (Publisher/Subscriber) should to be a mobile devices not laptops and I need to implement many routers in a multi-domains module. Thus, It seems I have to use the remote prefix registration. > So, I cannot implement your suggestion, and still I have an open issue. > > I wonder why you make a constraint on the remote prefix registration and intent to use only the localhost. > > kindly, explain. > > Best Regards, > Bassem Labib -------------- next part -------------- An HTML attachment was scrubbed... URL: From anilj.mailing at gmail.com Wed Feb 25 16:00:41 2015 From: anilj.mailing at gmail.com (Anil Jangam) Date: Wed, 25 Feb 2015 16:00:41 -0800 Subject: [Ndn-interest] ChronoChat build is failing. Message-ID: Hi List, I am trying to build the ChronoChat application, and my build is consistently failing due to following error log. Incidentally, I also see a bug report logged couple of weeks back; want to know if this is fixed already? http://redmine.named-data.net/issues/2477 The compilation error is: [58/79] Compiling src/main.cpp ../src/chatroom-info.cpp: In instantiation of ?std::size_t chronos::ChatroomInfo::wireEncode(ndn::encoding::EncodingImpl

&) const [with bool T = false; std::size_t = long unsigned int]?: ../src/chatroom-info.cpp:94:46: required from here ../src/chatroom-info.cpp:75:85: error: ?prependNonNegativeIntegerBlock? was not declared in this scope totalLength += prependNonNegativeIntegerBlock(block, tlv::TrustModel, m_trustModel); ^ ../src/chatroom-info.cpp:75:85: note: suggested alternative: In file included from /usr/local/include/ndn-cxx/name-component.hpp:27:0, from /usr/local/include/ndn-cxx/name.hpp:30, from /usr/local/include/ndn-cxx/interest.hpp:27, from ../src/common.hpp:32, from ../src/chatroom-info.hpp:14, from ../src/chatroom-info.cpp:11: /usr/local/include/ndn-cxx/encoding/block-helpers.hpp:55:1: note: ?ndn::prependNonNegativeIntegerBlock? prependNonNegativeIntegerBlock(EncodingImpl

& encoder, uint32_t type, uint64_t number) ^ ../src/chatroom-info.cpp: In instantiation of ?std::size_t chronos::ChatroomInfo::wireEncode(ndn::encoding::EncodingImpl

&) const [with bool T = true; std::size_t = long unsigned int]?: ../src/chatroom-info.cpp:97:20: required from here ../src/chatroom-info.cpp:75:85: error: ?prependNonNegativeIntegerBlock? was not declared in this scope totalLength += prependNonNegativeIntegerBlock(block, tlv::TrustModel, m_trustModel); ^ ../src/chatroom-info.cpp:75:85: note: suggested alternative: In file included from /usr/local/include/ndn-cxx/name-component.hpp:27:0, from /usr/local/include/ndn-cxx/name.hpp:30, from /usr/local/include/ndn-cxx/interest.hpp:27, from ../src/common.hpp:32, from ../src/chatroom-info.hpp:14, from ../src/chatroom-info.cpp:11: /usr/local/include/ndn-cxx/encoding/block-helpers.hpp:55:1: note: ?ndn::prependNonNegativeIntegerBlock? prependNonNegativeIntegerBlock(EncodingImpl

& encoder, uint32_t type, uint64_t number) ^ cc1plus: warning: unrecognized command line option "-Wno-nested-anon-types" [enabled by default] In file included from ../src/chat-dialog.hpp:25:0, from ../src/controller.hpp:26, from ../src/main.cpp:14: ../src/digest-tree-scene.hpp:22:20: fatal error: Leaf.hpp: No such file or directory #include ^ compilation terminated. /anil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingdi at CS.UCLA.EDU Wed Feb 25 16:05:36 2015 From: yingdi at CS.UCLA.EDU (Yingdi Yu) Date: Wed, 25 Feb 2015 16:05:36 -0800 Subject: [Ndn-interest] ChronoChat build is failing. In-Reply-To: References: Message-ID: <83631DE7-9DAD-48B9-9593-3B47B1D14F4C@cs.ucla.edu> Hi, Please checkout the latest ChronoChat, commit https://github.com/named-data/ChronoChat/commit/1cc45d96b8d7b4c442469147f7ba3e6a37f90d4b should fix this bug. Yingdi > On Feb 25, 2015, at 4:00 PM, Anil Jangam wrote: > > Hi List, > > I am trying to build the ChronoChat application, and my build is consistently failing due to following error log. Incidentally, I also see a bug report logged couple of weeks back; want to know if this is fixed already? > > http://redmine.named-data.net/issues/2477 > > The compilation error is: > > [58/79] Compiling src/main.cpp > ../src/chatroom-info.cpp: In instantiation of ?std::size_t chronos::ChatroomInfo::wireEncode(ndn::encoding::EncodingImpl

&) const [with bool T = false; std::size_t = long unsigned int]?: > ../src/chatroom-info.cpp:94:46: required from here > ../src/chatroom-info.cpp:75:85: error: ?prependNonNegativeIntegerBlock? was not declared in this scope > totalLength += prependNonNegativeIntegerBlock(block, tlv::TrustModel, m_trustModel); > ^ > ../src/chatroom-info.cpp:75:85: note: suggested alternative: > In file included from /usr/local/include/ndn-cxx/name-component.hpp:27:0, > from /usr/local/include/ndn-cxx/name.hpp:30, > from /usr/local/include/ndn-cxx/interest.hpp:27, > from ../src/common.hpp:32, > from ../src/chatroom-info.hpp:14, > from ../src/chatroom-info.cpp:11: > /usr/local/include/ndn-cxx/encoding/block-helpers.hpp:55:1: note: ?ndn::prependNonNegativeIntegerBlock? > prependNonNegativeIntegerBlock(EncodingImpl

& encoder, uint32_t type, uint64_t number) > ^ > ../src/chatroom-info.cpp: In instantiation of ?std::size_t chronos::ChatroomInfo::wireEncode(ndn::encoding::EncodingImpl

&) const [with bool T = true; std::size_t = long unsigned int]?: > ../src/chatroom-info.cpp:97:20: required from here > ../src/chatroom-info.cpp:75:85: error: ?prependNonNegativeIntegerBlock? was not declared in this scope > totalLength += prependNonNegativeIntegerBlock(block, tlv::TrustModel, m_trustModel); > ^ > ../src/chatroom-info.cpp:75:85: note: suggested alternative: > In file included from /usr/local/include/ndn-cxx/name-component.hpp:27:0, > from /usr/local/include/ndn-cxx/name.hpp:30, > from /usr/local/include/ndn-cxx/interest.hpp:27, > from ../src/common.hpp:32, > from ../src/chatroom-info.hpp:14, > from ../src/chatroom-info.cpp:11: > /usr/local/include/ndn-cxx/encoding/block-helpers.hpp:55:1: note: ?ndn::prependNonNegativeIntegerBlock? > prependNonNegativeIntegerBlock(EncodingImpl

& encoder, uint32_t type, uint64_t number) > ^ > cc1plus: warning: unrecognized command line option "-Wno-nested-anon-types" [enabled by default] > > In file included from ../src/chat-dialog.hpp:25:0, > from ../src/controller.hpp:26, > from ../src/main.cpp:14: > ../src/digest-tree-scene.hpp:22:20: fatal error: Leaf.hpp: No such file or directory > #include > ^ > compilation terminated. > > /anil. > > _______________________________________________ > 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 anilj.mailing at gmail.com Wed Feb 25 16:27:48 2015 From: anilj.mailing at gmail.com (Anil Jangam) Date: Wed, 25 Feb 2015 16:27:48 -0800 Subject: [Ndn-interest] ChronoChat build is failing. In-Reply-To: <83631DE7-9DAD-48B9-9593-3B47B1D14F4C@cs.ucla.edu> References: <83631DE7-9DAD-48B9-9593-3B47B1D14F4C@cs.ucla.edu> Message-ID: Thanks Yingdi. Is this something to do with ndn-cxx ? I am already using the latest code of it, but still getting this error now after rectifying earlier one. [79/79] Linking build/ChronoChat /usr/local/lib/libChronoSync.so: undefined reference to `ndn::Scheduler::cancelEvent(std::shared_ptr const&)' /usr/local/lib/libChronoSync.so: undefined reference to `ndn::Name::compare(ndn::Name const&) const' /usr/local/lib/libChronoSync.so: undefined reference to `ndn::Scheduler::scheduleEvent(boost::chrono::duration > const&, std::function const&)' /usr/local/lib/libChronoSync.so: undefined reference to `ndn::Scheduler::cancelAllEvents()' /usr/local/lib/libChronoSync.so: undefined reference to `ndn::Scheduler::Scheduler(boost::asio::io_service&)' /usr/local/lib/libChronoSync.so: undefined reference to `unsigned long ndn::Name::wireEncode(ndn::EncodingImpl&) const' /usr/local/lib/libChronoSync.so: undefined reference to `unsigned long ndn::Name::wireEncode(ndn::EncodingImpl&) const' collect2: error: ld returned 1 exit status Waf: Leaving directory `/home/ndnusr2/sandbox/ChronoChat/build' Build failed /anil. On Wed, Feb 25, 2015 at 4:05 PM, Yingdi Yu wrote: > Hi, > > Please checkout the latest ChronoChat, commit > https://github.com/named-data/ChronoChat/commit/1cc45d96b8d7b4c442469147f7ba3e6a37f90d4b should > fix this bug. > > Yingdi > > > > > On Feb 25, 2015, at 4:00 PM, Anil Jangam wrote: > > Hi List, > > I am trying to build the ChronoChat application, and my build is > consistently failing due to following error log. Incidentally, I also see a > bug report logged couple of weeks back; want to know if this is fixed > already? > > http://redmine.named-data.net/issues/2477 > > The compilation error is: > > [58/79] Compiling src/main.cpp > ../src/chatroom-info.cpp: In instantiation of ?std::size_t > chronos::ChatroomInfo::wireEncode(ndn::encoding::EncodingImpl

&) const > [with bool T = false; std::size_t = long unsigned int]?: > ../src/chatroom-info.cpp:94:46: required from here > ../src/chatroom-info.cpp:75:85: error: ?prependNonNegativeIntegerBlock? > was not declared in this scope > totalLength += prependNonNegativeIntegerBlock(block, tlv::TrustModel, > m_trustModel); > > ^ > ../src/chatroom-info.cpp:75:85: note: suggested alternative: > In file included from /usr/local/include/ndn-cxx/name-component.hpp:27:0, > from /usr/local/include/ndn-cxx/name.hpp:30, > from /usr/local/include/ndn-cxx/interest.hpp:27, > from ../src/common.hpp:32, > from ../src/chatroom-info.hpp:14, > from ../src/chatroom-info.cpp:11: > /usr/local/include/ndn-cxx/encoding/block-helpers.hpp:55:1: note: > ?ndn::prependNonNegativeIntegerBlock? > prependNonNegativeIntegerBlock(EncodingImpl

& encoder, uint32_t type, > uint64_t number) > ^ > ../src/chatroom-info.cpp: In instantiation of ?std::size_t > chronos::ChatroomInfo::wireEncode(ndn::encoding::EncodingImpl

&) const > [with bool T = true; std::size_t = long unsigned int]?: > ../src/chatroom-info.cpp:97:20: required from here > ../src/chatroom-info.cpp:75:85: error: ?prependNonNegativeIntegerBlock? > was not declared in this scope > totalLength += prependNonNegativeIntegerBlock(block, tlv::TrustModel, > m_trustModel); > > ^ > ../src/chatroom-info.cpp:75:85: note: suggested alternative: > In file included from /usr/local/include/ndn-cxx/name-component.hpp:27:0, > from /usr/local/include/ndn-cxx/name.hpp:30, > from /usr/local/include/ndn-cxx/interest.hpp:27, > from ../src/common.hpp:32, > from ../src/chatroom-info.hpp:14, > from ../src/chatroom-info.cpp:11: > /usr/local/include/ndn-cxx/encoding/block-helpers.hpp:55:1: note: > ?ndn::prependNonNegativeIntegerBlock? > prependNonNegativeIntegerBlock(EncodingImpl

& encoder, uint32_t type, > uint64_t number) > ^ > cc1plus: warning: unrecognized command line option > "-Wno-nested-anon-types" [enabled by default] > > In file included from ../src/chat-dialog.hpp:25:0, > from ../src/controller.hpp:26, > from ../src/main.cpp:14: > ../src/digest-tree-scene.hpp:22:20: fatal error: Leaf.hpp: No such file or > directory > #include > ^ > compilation terminated. > > > /anil. > > _______________________________________________ > 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 yingdi at CS.UCLA.EDU Wed Feb 25 16:37:00 2015 From: yingdi at CS.UCLA.EDU (Yingdi Yu) Date: Wed, 25 Feb 2015 16:37:00 -0800 Subject: [Ndn-interest] ChronoChat build is failing. In-Reply-To: References: <83631DE7-9DAD-48B9-9593-3B47B1D14F4C@cs.ucla.edu> Message-ID: <479E34F5-C1A7-493A-B33C-FB502C047378@cs.ucla.edu> Hi anil, Did you rebuild and install the ChronoSync lib? also make sure the ChronoSync submodule is updated. Yingdi > On Feb 25, 2015, at 4:27 PM, Anil Jangam wrote: > > Thanks Yingdi. > > Is this something to do with ndn-cxx ? I am already using the latest code of it, but still getting this error now after rectifying earlier one. > > [79/79] Linking build/ChronoChat > /usr/local/lib/libChronoSync.so: undefined reference to `ndn::Scheduler::cancelEvent(std::shared_ptr const&)' > /usr/local/lib/libChronoSync.so: undefined reference to `ndn::Name::compare(ndn::Name const&) const' > /usr/local/lib/libChronoSync.so: undefined reference to `ndn::Scheduler::scheduleEvent(boost::chrono::duration > const&, std::function const&)' > /usr/local/lib/libChronoSync.so: undefined reference to `ndn::Scheduler::cancelAllEvents()' > /usr/local/lib/libChronoSync.so: undefined reference to `ndn::Scheduler::Scheduler(boost::asio::io_service&)' > /usr/local/lib/libChronoSync.so: undefined reference to `unsigned long ndn::Name::wireEncode(ndn::EncodingImpl&) const' > /usr/local/lib/libChronoSync.so: undefined reference to `unsigned long ndn::Name::wireEncode(ndn::EncodingImpl&) const' > collect2: error: ld returned 1 exit status > > Waf: Leaving directory `/home/ndnusr2/sandbox/ChronoChat/build' > Build failed > > /anil. > > > On Wed, Feb 25, 2015 at 4:05 PM, Yingdi Yu > wrote: > Hi, > > Please checkout the latest ChronoChat, commit https://github.com/named-data/ChronoChat/commit/1cc45d96b8d7b4c442469147f7ba3e6a37f90d4b should fix this bug. > > Yingdi > > > > >> On Feb 25, 2015, at 4:00 PM, Anil Jangam > wrote: >> >> Hi List, >> >> I am trying to build the ChronoChat application, and my build is consistently failing due to following error log. Incidentally, I also see a bug report logged couple of weeks back; want to know if this is fixed already? >> >> http://redmine.named-data.net/issues/2477 >> >> The compilation error is: >> >> [58/79] Compiling src/main.cpp >> ../src/chatroom-info.cpp: In instantiation of ?std::size_t chronos::ChatroomInfo::wireEncode(ndn::encoding::EncodingImpl

&) const [with bool T = false; std::size_t = long unsigned int]?: >> ../src/chatroom-info.cpp:94:46: required from here >> ../src/chatroom-info.cpp:75:85: error: ?prependNonNegativeIntegerBlock? was not declared in this scope >> totalLength += prependNonNegativeIntegerBlock(block, tlv::TrustModel, m_trustModel); >> ^ >> ../src/chatroom-info.cpp:75:85: note: suggested alternative: >> In file included from /usr/local/include/ndn-cxx/name-component.hpp:27:0, >> from /usr/local/include/ndn-cxx/name.hpp:30, >> from /usr/local/include/ndn-cxx/interest.hpp:27, >> from ../src/common.hpp:32, >> from ../src/chatroom-info.hpp:14, >> from ../src/chatroom-info.cpp:11: >> /usr/local/include/ndn-cxx/encoding/block-helpers.hpp:55:1: note: ?ndn::prependNonNegativeIntegerBlock? >> prependNonNegativeIntegerBlock(EncodingImpl

& encoder, uint32_t type, uint64_t number) >> ^ >> ../src/chatroom-info.cpp: In instantiation of ?std::size_t chronos::ChatroomInfo::wireEncode(ndn::encoding::EncodingImpl

&) const [with bool T = true; std::size_t = long unsigned int]?: >> ../src/chatroom-info.cpp:97:20: required from here >> ../src/chatroom-info.cpp:75:85: error: ?prependNonNegativeIntegerBlock? was not declared in this scope >> totalLength += prependNonNegativeIntegerBlock(block, tlv::TrustModel, m_trustModel); >> ^ >> ../src/chatroom-info.cpp:75:85: note: suggested alternative: >> In file included from /usr/local/include/ndn-cxx/name-component.hpp:27:0, >> from /usr/local/include/ndn-cxx/name.hpp:30, >> from /usr/local/include/ndn-cxx/interest.hpp:27, >> from ../src/common.hpp:32, >> from ../src/chatroom-info.hpp:14, >> from ../src/chatroom-info.cpp:11: >> /usr/local/include/ndn-cxx/encoding/block-helpers.hpp:55:1: note: ?ndn::prependNonNegativeIntegerBlock? >> prependNonNegativeIntegerBlock(EncodingImpl

& encoder, uint32_t type, uint64_t number) >> ^ >> cc1plus: warning: unrecognized command line option "-Wno-nested-anon-types" [enabled by default] >> >> In file included from ../src/chat-dialog.hpp:25:0, >> from ../src/controller.hpp:26, >> from ../src/main.cpp:14: >> ../src/digest-tree-scene.hpp:22:20: fatal error: Leaf.hpp: No such file or directory >> #include >> ^ >> compilation terminated. >> >> /anil. >> >> _______________________________________________ >> 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 chengy.fan at gmail.com Wed Feb 25 16:48:18 2015 From: chengy.fan at gmail.com (Chengyu Fan) Date: Wed, 25 Feb 2015 17:48:18 -0700 Subject: [Ndn-interest] ChronoChat build is failing. In-Reply-To: <479E34F5-C1A7-493A-B33C-FB502C047378@cs.ucla.edu> References: <83631DE7-9DAD-48B9-9593-3B47B1D14F4C@cs.ucla.edu> <479E34F5-C1A7-493A-B33C-FB502C047378@cs.ucla.edu> Message-ID: Hi Anil, I just created a very simple chronoChat example to show how to use ChronoSync library. Here is the pointer: https://github.com/chengyu/Simple-Chrono-Chat.git On Wed, Feb 25, 2015 at 5:37 PM, Yingdi Yu wrote: > Hi anil, > > Did you rebuild and install the ChronoSync lib? also make sure the > ChronoSync submodule is updated. > > Yingdi > > > > > On Feb 25, 2015, at 4:27 PM, Anil Jangam wrote: > > Thanks Yingdi. > > Is this something to do with ndn-cxx ? I am already using the latest code > of it, but still getting this error now after rectifying earlier one. > > > [79/79] Linking build/ChronoChat > /usr/local/lib/libChronoSync.so: undefined reference to > `ndn::Scheduler::cancelEvent(std::shared_ptr const&)' > /usr/local/lib/libChronoSync.so: undefined reference to > `ndn::Name::compare(ndn::Name const&) const' > /usr/local/lib/libChronoSync.so: undefined reference to > `ndn::Scheduler::scheduleEvent(boost::chrono::duration boost::ratio<1l, 1000000000l> > const&, std::function const&)' > /usr/local/lib/libChronoSync.so: undefined reference to > `ndn::Scheduler::cancelAllEvents()' > /usr/local/lib/libChronoSync.so: undefined reference to > `ndn::Scheduler::Scheduler(boost::asio::io_service&)' > /usr/local/lib/libChronoSync.so: undefined reference to `unsigned long > ndn::Name::wireEncode(ndn::EncodingImpl&) const' > /usr/local/lib/libChronoSync.so: undefined reference to `unsigned long > ndn::Name::wireEncode(ndn::EncodingImpl&) const' > collect2: error: ld returned 1 exit status > > Waf: Leaving directory `/home/ndnusr2/sandbox/ChronoChat/build' > > Build failed > > /anil. > > > On Wed, Feb 25, 2015 at 4:05 PM, Yingdi Yu wrote: > >> Hi, >> >> Please checkout the latest ChronoChat, commit >> https://github.com/named-data/ChronoChat/commit/1cc45d96b8d7b4c442469147f7ba3e6a37f90d4b should >> fix this bug. >> >> Yingdi >> >> >> >> >> On Feb 25, 2015, at 4:00 PM, Anil Jangam wrote: >> >> Hi List, >> >> I am trying to build the ChronoChat application, and my build is >> consistently failing due to following error log. Incidentally, I also see a >> bug report logged couple of weeks back; want to know if this is fixed >> already? >> >> http://redmine.named-data.net/issues/2477 >> >> The compilation error is: >> >> [58/79] Compiling src/main.cpp >> ../src/chatroom-info.cpp: In instantiation of ?std::size_t >> chronos::ChatroomInfo::wireEncode(ndn::encoding::EncodingImpl

&) const >> [with bool T = false; std::size_t = long unsigned int]?: >> ../src/chatroom-info.cpp:94:46: required from here >> ../src/chatroom-info.cpp:75:85: error: ?prependNonNegativeIntegerBlock? >> was not declared in this scope >> totalLength += prependNonNegativeIntegerBlock(block, tlv::TrustModel, >> m_trustModel); >> >> ^ >> ../src/chatroom-info.cpp:75:85: note: suggested alternative: >> In file included from /usr/local/include/ndn-cxx/name-component.hpp:27:0, >> from /usr/local/include/ndn-cxx/name.hpp:30, >> from /usr/local/include/ndn-cxx/interest.hpp:27, >> from ../src/common.hpp:32, >> from ../src/chatroom-info.hpp:14, >> from ../src/chatroom-info.cpp:11: >> /usr/local/include/ndn-cxx/encoding/block-helpers.hpp:55:1: note: >> ?ndn::prependNonNegativeIntegerBlock? >> prependNonNegativeIntegerBlock(EncodingImpl

& encoder, uint32_t type, >> uint64_t number) >> ^ >> ../src/chatroom-info.cpp: In instantiation of ?std::size_t >> chronos::ChatroomInfo::wireEncode(ndn::encoding::EncodingImpl

&) const >> [with bool T = true; std::size_t = long unsigned int]?: >> ../src/chatroom-info.cpp:97:20: required from here >> ../src/chatroom-info.cpp:75:85: error: ?prependNonNegativeIntegerBlock? >> was not declared in this scope >> totalLength += prependNonNegativeIntegerBlock(block, tlv::TrustModel, >> m_trustModel); >> >> ^ >> ../src/chatroom-info.cpp:75:85: note: suggested alternative: >> In file included from /usr/local/include/ndn-cxx/name-component.hpp:27:0, >> from /usr/local/include/ndn-cxx/name.hpp:30, >> from /usr/local/include/ndn-cxx/interest.hpp:27, >> from ../src/common.hpp:32, >> from ../src/chatroom-info.hpp:14, >> from ../src/chatroom-info.cpp:11: >> /usr/local/include/ndn-cxx/encoding/block-helpers.hpp:55:1: note: >> ?ndn::prependNonNegativeIntegerBlock? >> prependNonNegativeIntegerBlock(EncodingImpl

& encoder, uint32_t type, >> uint64_t number) >> ^ >> cc1plus: warning: unrecognized command line option >> "-Wno-nested-anon-types" [enabled by default] >> >> In file included from ../src/chat-dialog.hpp:25:0, >> from ../src/controller.hpp:26, >> from ../src/main.cpp:14: >> ../src/digest-tree-scene.hpp:22:20: fatal error: Leaf.hpp: No such file >> or directory >> #include >> ^ >> compilation terminated. >> >> >> /anil. >> >> _______________________________________________ >> 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 > > -- Thanks, Chengyu -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at caida.org Thu Feb 26 07:39:38 2015 From: josh at caida.org (Josh Polterock) Date: Thu, 26 Feb 2015 07:39:38 -0800 Subject: [Ndn-interest] Named Data Networking (NDN) Project Monthly Newsletter for February 2015 Message-ID: <20150226153937.GA1596@caida.org> Named Data Networking (NDN) Project Monthly Newsletter for February 2015 The NDN project team compiles and publishes this newletter 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 * We posted two new NDN FAQ videos: - Lan Wang, Associate Professor of Computer Science at University of Memphis answers the question, "What routing strategies are being explored for NDN?" https://vimeo.com/118961735 - David Clark, Senior Research Scientist at MIT Computer Science and Artificial Intelligence Lab addresses the question, "Why should future internet architecture research be application driven?" https://vimeo.com/118965175 See them all at: https://vimeo.com/channels/ndnvfaq TECHNICAL NEWS * We announced the release of version 0.3.0 of Named Data Networking Forwarding Daemon (NFD) and ndn-cxx library. The detailed release notes: - for NFD: http://named-data.net/doc/NFD/0.3.0/RELEASE_NOTES.html - for ndn-cxx library: http://named-data.net/doc/ndn-cxx/0.3.0/RELEASE_NOTES.html More details about NFD, tutorials, HOWTOs, a FAQ and other useful resources are available on official webpages of NFD and ndn-cxx: - http://named-data.net/doc/NFD/0.3.0/ - http://named-data.net/doc/ndn-cxx/0.3.0/ We also have updated the NFD developer's guide to match the new release: http://named-data.net/techreport/ndn-0021-3-nfd-developer-guide.pdf * We announced new versions of NdnCon version 0.4.0 and NDN-RTC version 1.1.0. - https://github.com/peetonn/ndncon/releases/tag/v0.4.0> - https://github.com/remap/ndnrtc/releases/tag/v1.1.0> You can find the updated wiki page for NdnCon at https://github.com/peetonn/ndncon/wiki with sections including: - How to use NdnCon https://github.com/peetonn/ndncon/wiki/How-to-use - NDN daemon configuration https://github.com/peetonn/ndncon/wiki/NDN-daemon-configuration * We announced the release of an updated version of NDN File System (ndnfs), along with a Firefox NDN add-on used to access retreat documents via NDN. The NDNFS file system provides a file access interface and stores files as well as their network-related metadata for remote access via NDN. Please see the technical report: http://named-data.net/wp-content/uploads/2014/10/ndn-tr-27-ndnfs.pdf We also internally distributed and tested a Firefox browser add-on using NDN-JS used for easy access to files. * We released version 0.3 of jNDN, the NDN Common Client LIbrary for Java. https://github.com/named-data/jndn One major change comes in the form of support for the Maven build system, which can automatically include jNDN as a dependency from the Maven Central Repository: https://search.maven.org/#artifactdetails|net.named-data|jndn|0.3|jar This release includes other changes. See the CHANGELOG for details: https://github.com/named-data/jndn/blob/5081f130ec3e9fb5fa9d526ab3c652fbcae30fbf/CHANGELOG * We released the Android version of NFD available publicly at: https://github.com/named-data/NFD-android * A group at Orange SA (orange.com) announced the first release of a tool, lurch, for conducting experimental research with NDN. The group has used the tool to successfully run NDN experiments in a large grid (www.grid5000.fr). The lurch tool applies equally well to test smaller experiments in a local cluster of servers. Please find the source and related documentation at: http://systemx.enst.fr/lurch * Intel released three Java libraries based on jndn that they use to simplify some NDN functionality. The source for the tools have been released under LGPLv3 and can be pulled in to any Maven project from the Central Repository. Andrew Brown would appreciate feedback, suggestions, and pull requests. https://github.com/01org/jndn-management https://github.com/01org/jndn-utils https://github.com/01org/jndn-mock NDN PUBLICATIONS, PRESENTATIONS, and TECHNICAL REPORTS * NFD Developer's Guide. Alexander Afanasyev, et al. NDN Technical Report NDN-0021. http://named-data.net/techreport/ndn-0021-3-nfd-developer-guide.pdf * Map-and-Encap for Scaling NDN Routing. Alexander Afanasyev, Cheng Yi, Lan Wang, Beichuan Zhang, and Lixia Zhang. NDN, Technical Report NDN-0004. http://named-data.net/techreport/ndn-0004-3-scaling-ndn-routing.pdf * ndnSIM 2.0: A new version of the NDN simulator for NS-3. Spyridon Mastorakis, Alexander Afanasyev, Ilya Moiseenko, and Lixia Zhang. NDN, Technical Report NDN-0028. http://named-data.net/techreport/ndn-0028-1-ndnsim-v2.pdf NDN SEMINARS * Our NDN Seminar series has been on hiatus but will start again soon. These seminars are internally focused. We usually hold these seminars on Wednesday from 2-3p (PST). So, if you would like to be included in the NDN Seminars, please contact Jongdeog Lee for the most up-to-date information regarding upcoming seminars. RELATED WORK * Amin Karami, Manel Guerrero-Zapata, "An ANFIS-based cache replacement method for mitigating cache pollution attacks in Named Data Networking", Computer Architecture Department (DAC), Universitat Politecnica de Catalunya (UPC), Campus Nord, Jordi Girona 1-3, 08034 Barcelona, Spain. http://www.sciencedirect.com/science/article/pii/S1389128615000316 * "Named Data Networking project wants to retire TCP/IP" by David Greer http://searchnetworking.techtarget.com/feature/Named-Data-Networking-project-wants-to-retire-TCP-IP * Collaborators at Tsinghua University, Zhongxing Ming, Huibin Wang, Mingwei Xu, Dai Pan, published the paper, "Efficient handover in railway networking via named data", International Journal of Machine Learning and Cybernetics. February 2015, Volume 6, Issue 1, pp 167-173 Date: 14 Jul 2014 http://dx.doi.org/10.1007/s13042-014-0282-9 * For more information about the Named Data Networking (NDN) Project please visit http://www.named-data.net/. From jlee700 at illinois.EDU Thu Feb 26 14:24:20 2015 From: jlee700 at illinois.EDU (Lee, Jongdeog) Date: Thu, 26 Feb 2015 22:24:20 +0000 Subject: [Ndn-interest] Waf errors Message-ID: Hi, Does anybody know why I got this error when I do "./waf configure"? I am using a Centos machine and I do have the sudo authority. =================================================== Traceback (most recent call last): File "./waf", line 163, in ? from waflib import Scripting File "/home/tarek/jlee700/ndn-cxx/.waf-1.8.5-d178df7a9bb732db109001d6b461550f/waflib/Scripting.py", line 6, in ? from waflib import Utils,Configure,Logs,Options,ConfigSet,Context,Errors,Build,Node File "/home/tarek/jlee700/ndn-cxx/.waf-1.8.5-d178df7a9bb732db109001d6b461550f/waflib/Utils.py", line 7, in ? from collections import deque,defaultdict ImportError: cannot import name defaultdict =================================================== Any advice would be appreciated. Best wishes, Jongdeog Lee (JD) ------------------------------------------------ Ph.D. Student Department of Computer Science University of Illinois at Urbana-Champaign -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Thu Feb 26 14:35:47 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Thu, 26 Feb 2015 14:35:47 -0800 Subject: [Ndn-interest] Waf errors In-Reply-To: References: Message-ID: <1534C353-922D-4C14-9366-9ACE860AE41D@ucla.edu> Does this apply to you: http://stackoverflow.com/questions/25288315/importerror-cannot-import-name-defaultdict ? Alex > On Feb 26, 2015, at 2:24 PM, Lee, Jongdeog wrote: > > Hi, > > Does anybody know why I got this error when I do "./waf configure"? > I am using a Centos machine and I do have the sudo authority. > > =================================================== > > Traceback (most recent call last): > > File "./waf", line 163, in ? > > from waflib import Scripting > > File "/home/tarek/jlee700/ndn-cxx/.waf-1.8.5-d178df7a9bb732db109001d6b461550f/waflib/Scripting.py", line 6, in ? > > from waflib import Utils,Configure,Logs,Options,ConfigSet,Context,Errors,Build,Node > > File "/home/tarek/jlee700/ndn-cxx/.waf-1.8.5-d178df7a9bb732db109001d6b461550f/waflib/Utils.py", line 7, in ? > > from collections import deque,defaultdict > > ImportError: cannot import name defaultdict > > =================================================== > > Any advice would be appreciated. > > Best wishes, > Jongdeog Lee (JD) > > ------------------------------------------------ > Ph.D. Student > Department of Computer Science > University of Illinois at Urbana-Champaign -------------- 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 anilj.mailing at gmail.com Fri Feb 27 09:45:07 2015 From: anilj.mailing at gmail.com (Anil Jangam) Date: Fri, 27 Feb 2015 09:45:07 -0800 Subject: [Ndn-interest] Wireshark and NDN Message-ID: Does Wireshark supports NDN. I know that CCNx is supported by Wireshark but not sure how compatible it is with NDN messages. I haven't tried it yet. https://github.com/ProjectCCNx/ccnx/tree/master/apps/wireshark Has someone tried it so far and what other alternative we have trace the NDN messages. /anil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Feb 27 09:52:55 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 27 Feb 2015 10:52:55 -0700 Subject: [Ndn-interest] Wireshark and NDN In-Reply-To: References: Message-ID: Hi Anil The official packet analyzer for NDN-TLV is ndndump < https://github.com/named-data/ndndump>. If you are interested in writing a Wireshark dissector for NDN-TLV, I suggest using Lua. A few years ago I posted an article about Lua dissectors < http://yoursunny.com/t/2008/Wireshark-Lua-dissector/> (it's in Chinese so you may need to use Bing Translator). Yours, Junxiao On Fri, Feb 27, 2015 at 10:45 AM, Anil Jangam wrote: > Does Wireshark supports NDN. I know that CCNx is supported by Wireshark > but not sure how compatible it is with NDN messages. I haven't tried it yet. > > https://github.com/ProjectCCNx/ccnx/tree/master/apps/wireshark > > Has someone tried it so far and what other alternative we have trace the > NDN messages. > > /anil. > > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tailinchu at gmail.com Fri Feb 27 10:18:03 2015 From: tailinchu at gmail.com (Tai-Lin Chu) Date: Fri, 27 Feb 2015 10:18:03 -0800 Subject: [Ndn-interest] Interest sends to multiple next-hops Message-ID: Can somebody confirm that if interest sends to multiple next-hops, the pit entry will be erased after the first satisfying data? Thanks. From shijunxiao at email.arizona.edu Fri Feb 27 10:24:41 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 27 Feb 2015 11:24:41 -0700 Subject: [Ndn-interest] Interest sends to multiple next-hops In-Reply-To: References: Message-ID: Hi Tai-Lin In NDN architecture, a pending Interest table entry will be erased after first satisifying Data. Data from other nexthops, if any, will be treated as unsolicited and dropped. In NFD, the "Interest table" is a superset of "pending Interest table": an Interest table entry is either a pending Interest or a recently satisfied Interest. An Interest table entry is kept until "straggler timer" expires. This allows the strategy to collect measurements about other possible nexthops. See NFD Developer Guide, Forwarding section for details. Yours, Junxiao On Fri, Feb 27, 2015 at 11:18 AM, Tai-Lin Chu wrote: > Can somebody confirm that if interest sends to multiple next-hops, the > pit entry will be erased after the first satisfying data? > > Thanks. > _______________________________________________ > Ndn-interest mailing list > Ndn-interest at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Feb 27 10:45:20 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 27 Feb 2015 11:45:20 -0700 Subject: [Ndn-interest] Wireshark and NDN Message-ID: Hi Anil Did you setup a Route for /name/data prefix toward a non-local udp4 or tcp4 face? ndndump is only able to capture NDN-TLV traffic over IPv4-UDP or IPv4-TCP tunnels. If traffic is over IPv6 tunnels or WebSocket or UNIX faces, ndndump won't see them. See this tutorial on how to setup routes: http://yoursunny.com/t/2014/nfd-connect/ Yours, Junxiao On Fri, Feb 27, 2015 at 11:31 AM, Anil Jangam wrote: > Hi Junxiao, > > Thanks for reply. I started ndndump as follows. by default it monitors the > eth0 (which is correct interface). > > sudo ndndump -v > ndndump: listening on eth0 > ndndump: pcap_filter = (ether proto 0x8624) || (tcp port 6363) || (udp > port 6363) > > > Later, I am doing a ndnping from same host for some random name prefix to > test the dump utility, but I do not see any activity. > > ndnping ndn:/name/data > > > === Pinging ndn:/name/data === > > Timeout From ndn:/name/data - Ping Reference = 8667669 > Timeout From ndn:/name/data - Ping Reference = 8667670 > Timeout From ndn:/name/data - Ping Reference = 8667671 > > > I am not sure what I am missing. Can you please comment? My larger goal is > to get the ChronoChat application running on my testbed. > > /anil. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Feb 27 11:27:03 2015 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 27 Feb 2015 12:27:03 -0700 Subject: [Ndn-interest] Fwd: Wireshark and NDN In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Anil Jangam Date: Fri, Feb 27, 2015 at 12:22 PM Subject: Re: [Ndn-interest] Wireshark and NDN To: Junxiao Shi Perfect! Nice tut.. On Fri, Feb 27, 2015 at 10:45 AM, Junxiao Shi wrote: > Hi Anil > > Did you setup a Route for /name/data prefix toward a non-local udp4 or > tcp4 face? > > ndndump is only able to capture NDN-TLV traffic over IPv4-UDP or IPv4-TCP > tunnels. > If traffic is over IPv6 tunnels or WebSocket or UNIX faces, ndndump won't > see them. > > See this tutorial on how to setup routes: > http://yoursunny.com/t/2014/nfd-connect/ > > Yours, Junxiao > > On Fri, Feb 27, 2015 at 11:31 AM, Anil Jangam > wrote: > >> Hi Junxiao, >> >> Thanks for reply. I started ndndump as follows. by default it monitors >> the eth0 (which is correct interface). >> >> sudo ndndump -v >> ndndump: listening on eth0 >> ndndump: pcap_filter = (ether proto 0x8624) || (tcp port 6363) || (udp >> port 6363) >> >> >> Later, I am doing a ndnping from same host for some random name prefix to >> test the dump utility, but I do not see any activity. >> >> ndnping ndn:/name/data >> >> >> === Pinging ndn:/name/data === >> >> Timeout From ndn:/name/data - Ping Reference = 8667669 >> Timeout From ndn:/name/data - Ping Reference = 8667670 >> Timeout From ndn:/name/data - Ping Reference = 8667671 >> >> >> I am not sure what I am missing. Can you please comment? My larger goal >> is to get the ChronoChat application running on my testbed. >> >> /anil. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From chengy.fan at gmail.com Fri Feb 27 12:10:39 2015 From: chengy.fan at gmail.com (Chengyu Fan) Date: Fri, 27 Feb 2015 13:10:39 -0700 Subject: [Ndn-interest] How to add the SecRuleRelative Rules in validator-regex? Message-ID: Hi, I'm trying to use the validator-regex to validate the incoming data, but I stuck at how to add the SecRuleRelative Rule. Can somebody tell me some clues? Specifically, I find the example in SecurityLibrary( http://redmine.named-data.net/projects/ndn-cxx/wiki/SecurityLibrary), but I don't understand the RuleRelative rule below ... SecRuleRelative rule("^(<>*)$", "^([^]*)(<>*)$", ">", "\\1", "\\1\\2", true); What's the meaning of ">", "\\1", "\\1\\2" ? Can someone give me an example? -- Thanks, Chengyu -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Fri Feb 27 12:59:34 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Fri, 27 Feb 2015 12:59:34 -0800 Subject: [Ndn-interest] How to add the SecRuleRelative Rules in validator-regex? In-Reply-To: References: Message-ID: <3AE5D813-81E9-449D-8FF9-045D0DD007F3@ucla.edu> > On Feb 27, 2015, at 12:10 PM, Chengyu Fan wrote: > > Hi, > > I'm trying to use the validator-regex to validate the incoming data, but I stuck at how to add the SecRuleRelative Rule. > > Can somebody tell me some clues? > > Specifically, I find the example in SecurityLibrary(http://redmine.named-data.net/projects/ndn-cxx/wiki/SecurityLibrary ), but I don't understand the RuleRelative rule below ... > SecRuleRelative rule("^(<>*)$", "^([^]*)(<>*)$", > ">", "\\1", "\\1\\2", true); > > What's the meaning of ">", "\\1", "\\1\\2" ? Can someone give me an example? This is just a regular expression rules. \\1 (\1, it?s just \ needs to be escaped in c++) refer to th first group of the regular expression, \\2 refer to the second group, etc. There are many documentation sources about regexps, e.g., http://www.boost.org/doc/libs/1_57_0/libs/regex/doc/html/boost_regex/syntax/perl_syntax.html . The only difference in our regular expressions is the fact that it is defined over name components, not just strings. There is a documentation for this at http://named-data.net/doc/ndn-cxx/current/tutorials/utils-ndn-regex.html ? Alex -------------- 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 anilj.mailing at gmail.com Fri Feb 27 13:22:12 2015 From: anilj.mailing at gmail.com (Anil Jangam) Date: Fri, 27 Feb 2015 13:22:12 -0800 Subject: [Ndn-interest] ChronoChat and its default RIB entries Message-ID: Hi, When I start the ChronoChat client, it creates certain default entries into the RIB as follows. /ndn/broadcast/chronochat/chatroom-list route={faceid=294 (origin=0 cost=0 ChildInherit)} /ndn/broadcast/ChronoChat/chatroom-e8745dec route={faceid=294 (origin=0 cost=0 ChildInherit)} /ndn/broadcast/%F0./chronochat-tmp-identity/f4e4ea96/CHRONOCHAT-INVITATION route={faceid=294 (origin=0 cost=0 ChildInherit)} I checked the faceId 294, and it is a non udp/tcp type of face. faceid=294 remote=fd://23 local=unix:///run/nfd.sock counters={in={70i 6d 16223B} out={0i 6d 5145B}} local on-demand point-to-point In what way I can program the ChronoChat client to use the specific face? may be through some configuration file or so? I have configured a face which points to the remote user in the Chat. I guess this local client should be using this interface (257) instead of 294, correct? faceid=257 remote=udp4://224.0.23.170:56363 local=udp4:// 133.164.60.154:56363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point /anil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anilj.mailing at gmail.com Fri Feb 27 15:08:53 2015 From: anilj.mailing at gmail.com (Anil Jangam) Date: Fri, 27 Feb 2015 15:08:53 -0800 Subject: [Ndn-interest] ChronoChat and its default RIB entries In-Reply-To: References: Message-ID: Hi, I could start two ChronoChat processes from same host, and upon creating and joining the same chatroom, they are able to chat with each other. However, I think this message transaction is not going over the IP network, and I am not able to see any messages on ndndump. What way we can trace these messages using tcpdump? I am also getting an Warning message, "Warning: no connection to hub or hub does not support prefix autoconfig".. I am not sure what this means. Again, I want to run this chat across two remote hosts, and the problem mentioned earlier still exist. How can I force ChronoChat to use specific face Id instead of picking up the default one. Can someone please comment on this? /anil On Fri, Feb 27, 2015 at 1:22 PM, Anil Jangam wrote: > Hi, > > When I start the ChronoChat client, it creates certain default entries > into the RIB as follows. > > /ndn/broadcast/chronochat/chatroom-list route={faceid=294 (origin=0 cost=0 > ChildInherit)} > /ndn/broadcast/ChronoChat/chatroom-e8745dec route={faceid=294 (origin=0 > cost=0 ChildInherit)} > /ndn/broadcast/%F0./chronochat-tmp-identity/f4e4ea96/CHRONOCHAT-INVITATION > route={faceid=294 (origin=0 cost=0 ChildInherit)} > > > I checked the faceId 294, and it is a non udp/tcp type of face. > > faceid=294 remote=fd://23 local=unix:///run/nfd.sock counters={in={70i 6d > 16223B} out={0i 6d 5145B}} local on-demand point-to-point > > In what way I can program the ChronoChat client to use the specific face? > may be through some configuration file or so? > > I have configured a face which points to the remote user in the Chat. I > guess this local client should be using this interface (257) instead of > 294, correct? > > faceid=257 remote=udp4://224.0.23.170:56363 local=udp4:// > 133.164.60.154:56363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local > persistent point-to-point > > > /anil. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Fri Feb 27 15:41:35 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Fri, 27 Feb 2015 15:41:35 -0800 Subject: [Ndn-interest] ChronoChat and its default RIB entries In-Reply-To: References: Message-ID: <2AB56CF2-6F8A-4432-81E1-C1B1F6E57F5E@ucla.edu> Hi Anil, I think you?re mixing a couple of things. The face that ChronoChat application uses is just a channel between the application and NFD. It is normally unix socket face, but it doesn?t really matter, as it is not related to you being able to chat with other people. Besides having a face that points to a remote chat node, you need to instruct NFD (RIB manager specifically) that specific data can be reached through this face. In your specific face, you may start by registering /ndn/broadcast prefix for your multicast udp face: nfdc register /ndn/broadcast 294 This will tell NFD that data packets with prefix /ndn/broadcast can be retrieved if interest send out through face 294. You can also register / prefix, which will essentially mean that NFD can try this face to fetch all kind of data packets. ? Alex > On Feb 27, 2015, at 1:22 PM, Anil Jangam wrote: > > Hi, > > When I start the ChronoChat client, it creates certain default entries into the RIB as follows. > > /ndn/broadcast/chronochat/chatroom-list route={faceid=294 (origin=0 cost=0 ChildInherit)} > /ndn/broadcast/ChronoChat/chatroom-e8745dec route={faceid=294 (origin=0 cost=0 ChildInherit)} > /ndn/broadcast/%F0./chronochat-tmp-identity/f4e4ea96/CHRONOCHAT-INVITATION route={faceid=294 (origin=0 cost=0 ChildInherit)} > > I checked the faceId 294, and it is a non udp/tcp type of face. > > faceid=294 remote=fd://23 local=unix:///run/nfd.sock counters={in={70i 6d 16223B} out={0i 6d 5145B}} local on-demand point-to-point > > In what way I can program the ChronoChat client to use the specific face? may be through some configuration file or so? > > I have configured a face which points to the remote user in the Chat. I guess this local client should be using this interface (257) instead of 294, correct? > > faceid=257 remote=udp4://224.0.23.170:56363 local=udp4://133.164.60.154:56363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point > > /anil. > > _______________________________________________ > 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 alexander.afanasyev at ucla.edu Fri Feb 27 15:43:03 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Fri, 27 Feb 2015 15:43:03 -0800 Subject: [Ndn-interest] ChronoChat and its default RIB entries In-Reply-To: References: Message-ID: > On Feb 27, 2015, at 3:08 PM, Anil Jangam wrote: > > Hi, > > I could start two ChronoChat processes from same host, and upon creating and joining the same chatroom, they are able to chat with each other. However, I think this message transaction is not going over the IP network, and I am not able to see any messages on ndndump. What way we can trace these messages using tcpdump? > > I am also getting an Warning message, "Warning: no connection to hub or hub does not support prefix autoconfig".. I am not sure what this means. You have this message, as the current ChronoChat implementation has some assumptions about the environment. However, this should not prevent you from chatting. ? Alex > Again, I want to run this chat across two remote hosts, and the problem mentioned earlier still exist. How can I force ChronoChat to use specific face Id instead of picking up the default one. > > Can someone please comment on this? > > /anil > > > On Fri, Feb 27, 2015 at 1:22 PM, Anil Jangam > wrote: > Hi, > > When I start the ChronoChat client, it creates certain default entries into the RIB as follows. > > /ndn/broadcast/chronochat/chatroom-list route={faceid=294 (origin=0 cost=0 ChildInherit)} > /ndn/broadcast/ChronoChat/chatroom-e8745dec route={faceid=294 (origin=0 cost=0 ChildInherit)} > /ndn/broadcast/%F0./chronochat-tmp-identity/f4e4ea96/CHRONOCHAT-INVITATION route={faceid=294 (origin=0 cost=0 ChildInherit)} > > I checked the faceId 294, and it is a non udp/tcp type of face. > > faceid=294 remote=fd://23 local=unix:///run/nfd.sock counters={in={70i 6d 16223B} out={0i 6d 5145B}} local on-demand point-to-point > > In what way I can program the ChronoChat client to use the specific face? may be through some configuration file or so? > > I have configured a face which points to the remote user in the Chat. I guess this local client should be using this interface (257) instead of 294, correct? > > faceid=257 remote=udp4://224.0.23.170:56363 local=udp4://133.164.60.154:56363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point > > /anil. > > > _______________________________________________ > 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 anilj.mailing at gmail.com Fri Feb 27 16:29:58 2015 From: anilj.mailing at gmail.com (Anil Jangam) Date: Fri, 27 Feb 2015 16:29:58 -0800 Subject: [Ndn-interest] ChronoChat and its default RIB entries In-Reply-To: <2AB56CF2-6F8A-4432-81E1-C1B1F6E57F5E@ucla.edu> References: <2AB56CF2-6F8A-4432-81E1-C1B1F6E57F5E@ucla.edu> Message-ID: Thanks Alex. Pls see inline. On Fri, Feb 27, 2015 at 3:41 PM, Alex Afanasyev < alexander.afanasyev at ucla.edu> wrote: > Hi Anil, > > I think you?re mixing a couple of things. The face that ChronoChat > application uses is just a channel between the application and NFD. It is > normally unix socket face, but it doesn?t really matter, as it is not > related to you being able to chat with other people. > > Besides having a face that points to a remote chat node, you need to > instruct NFD (RIB manager specifically) that specific data can be reached > through this face. > > So basically I need to register the name prefix of the remote user using faceId=257 so that when local chat application sends the Interest to fetch the messages (after ChronoSync update) from remote end, it is forwarded on face 257, correct? I tried to add user and its details through "Add contact" sub menu, but it did not succeed. This is the place where we configure the name Identity of the remote user, right? Also since this is decentralized system, it is not required to know what chat room the remote user is connected to, correct? How does this function? Do you have any document which will guide through various steps to establish a two-party chat session? In your specific face, you may start by registering /ndn/broadcast prefix > for your multicast udp face: > > nfdc register /ndn/broadcast 294 > > This will tell NFD that data packets with prefix /ndn/broadcast can be > retrieved if interest send out through face 294. You can also register / > prefix, which will essentially mean that NFD can try this face to fetch all > kind of data packets. > > ? > Alex > > On Feb 27, 2015, at 1:22 PM, Anil Jangam wrote: > > Hi, > > When I start the ChronoChat client, it creates certain default entries > into the RIB as follows. > > /ndn/broadcast/chronochat/chatroom-list route={faceid=294 (origin=0 cost=0 > ChildInherit)} > /ndn/broadcast/ChronoChat/chatroom-e8745dec route={faceid=294 (origin=0 > cost=0 ChildInherit)} > /ndn/broadcast/%F0./chronochat-tmp-identity/f4e4ea96/CHRONOCHAT-INVITATION > route={faceid=294 (origin=0 cost=0 ChildInherit)} > > > I checked the faceId 294, and it is a non udp/tcp type of face. > > faceid=294 remote=fd://23 local=unix:///run/nfd.sock counters={in={70i 6d > 16223B} out={0i 6d 5145B}} local on-demand point-to-point > > In what way I can program the ChronoChat client to use the specific face? > may be through some configuration file or so? > > I have configured a face which points to the remote user in the Chat. I > guess this local client should be using this interface (257) instead of > 294, correct? > > faceid=257 remote=udp4://224.0.23.170:56363 local=udp4:// > 133.164.60.154:56363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local > persistent point-to-point > > > /anil. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.afanasyev at ucla.edu Fri Feb 27 16:35:41 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Fri, 27 Feb 2015 16:35:41 -0800 Subject: [Ndn-interest] ChronoChat and its default RIB entries In-Reply-To: References: <2AB56CF2-6F8A-4432-81E1-C1B1F6E57F5E@ucla.edu> Message-ID: <3C882D56-A433-4404-9BB5-3978F3E5F5E6@ucla.edu> > On Feb 27, 2015, at 4:29 PM, Anil Jangam wrote: > > Thanks Alex. Pls see inline. > > On Fri, Feb 27, 2015 at 3:41 PM, Alex Afanasyev > wrote: > Hi Anil, > > I think you?re mixing a couple of things. The face that ChronoChat application uses is just a channel between the application and NFD. It is normally unix socket face, but it doesn?t really matter, as it is not related to you being able to chat with other people. > > Besides having a face that points to a remote chat node, you need to instruct NFD (RIB manager specifically) that specific data can be reached through this face. > > So basically I need to register the name prefix of the remote user using faceId=257 so that when local chat application sends the Interest to fetch the messages (after ChronoSync update) from remote end, it is forwarded on face 257, correct? Yes. Exactly. The only correction I?ll make is that ChronoChat app just wants to fetch messages. It is not aware local or remote. It just issues interest for data and NFD will figure out using the registered RIB entries. > I tried to add user and its details through "Add contact" sub menu, but it did not succeed. This is the place where we configure the name Identity of the remote user, right? I don?t know the extent this feature is implemented/working :) Yingdi or Qiuhan can help me with answering this question. I also don?t have answers to the following questions. Yingdi/Qiuhan, pls help :) ? Alex > Also since this is decentralized system, it is not required to know what chat room the remote user is connected to, correct? How does this function? > > Do you have any document which will guide through various steps to establish a two-party chat session? > > In your specific face, you may start by registering /ndn/broadcast prefix for your multicast udp face: > > nfdc register /ndn/broadcast 294 > > This will tell NFD that data packets with prefix /ndn/broadcast can be retrieved if interest send out through face 294. You can also register / prefix, which will essentially mean that NFD can try this face to fetch all kind of data packets. > > ? > Alex > >> On Feb 27, 2015, at 1:22 PM, Anil Jangam > wrote: >> >> Hi, >> >> When I start the ChronoChat client, it creates certain default entries into the RIB as follows. >> >> /ndn/broadcast/chronochat/chatroom-list route={faceid=294 (origin=0 cost=0 ChildInherit)} >> /ndn/broadcast/ChronoChat/chatroom-e8745dec route={faceid=294 (origin=0 cost=0 ChildInherit)} >> /ndn/broadcast/%F0./chronochat-tmp-identity/f4e4ea96/CHRONOCHAT-INVITATION route={faceid=294 (origin=0 cost=0 ChildInherit)} >> >> I checked the faceId 294, and it is a non udp/tcp type of face. >> >> faceid=294 remote=fd://23 <> local=unix:///run/nfd.sock <> counters={in={70i 6d 16223B} out={0i 6d 5145B}} local on-demand point-to-point >> >> In what way I can program the ChronoChat client to use the specific face? may be through some configuration file or so? >> >> I have configured a face which points to the remote user in the Chat. I guess this local client should be using this interface (257) instead of 294, correct? >> >> faceid=257 remote=udp4://224.0.23.170:56363 local=udp4://133.164.60.154:56363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point >> >> /anil. > > -------------- 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 chengy.fan at gmail.com Fri Feb 27 19:59:51 2015 From: chengy.fan at gmail.com (Chengyu Fan) Date: Fri, 27 Feb 2015 20:59:51 -0700 Subject: [Ndn-interest] How to add the SecRuleRelative Rules in validator-regex? In-Reply-To: <3AE5D813-81E9-449D-8FF9-045D0DD007F3@ucla.edu> References: <3AE5D813-81E9-449D-8FF9-045D0DD007F3@ucla.edu> Message-ID: Could you tell me how the SecRuleRelative Rule works? Specifically, what's the meaning of each parameter? What conditions the rule will test to make a incoming data satisfy the rule? ndn::SecRuleRelative::SecRuleRelative (const std::string & dataRegex,const std::string & signerRegex,const std::string & op,const std::string & dataExpand,const std::string & signerExpand,bool isPositive ) On Fri, Feb 27, 2015 at 1:59 PM, Alex Afanasyev < alexander.afanasyev at ucla.edu> wrote: > > On Feb 27, 2015, at 12:10 PM, Chengyu Fan wrote: > > Hi, > > I'm trying to use the validator-regex to validate the incoming data, but I > stuck at how to add the SecRuleRelative Rule. > > Can somebody tell me some clues? > > Specifically, I find the example in SecurityLibrary( > http://redmine.named-data.net/projects/ndn-cxx/wiki/SecurityLibrary), but > I don't understand the RuleRelative rule below ... > > SecRuleRelative rule("^(<>*)$", "^([^]*)(<>*)$", > ">", "\\1", "\\1\\2", true); > > What's the meaning of ">", "\\1", "\\1\\2" ? Can someone give me an > example? > > > This is just a regular expression rules. \\1 (\1, it?s just \ needs to > be escaped in c++) refer to th first group of the regular expression, \\2 refer > to the second group, etc. > > There are many documentation sources about regexps, e.g., > http://www.boost.org/doc/libs/1_57_0/libs/regex/doc/html/boost_regex/syntax/perl_syntax.html > . > > The only difference in our regular expressions is the fact that it is > defined over name components, not just strings. There is a documentation > for this at > http://named-data.net/doc/ndn-cxx/current/tutorials/utils-ndn-regex.html > > ? > Alex > > > -- Thanks, Chengyu -------------- next part -------------- An HTML attachment was scrubbed... URL: From dejiang_zhou at 163.com Sat Feb 28 02:12:04 2015 From: dejiang_zhou at 163.com (Dejiang Zhou) Date: Sat, 28 Feb 2015 18:12:04 +0800 (CST) Subject: [Ndn-interest] Data Accessibility in VM Live Migration over NDN Message-ID: <3921f845.1342a.14bcfabe795.Coremail.dejiang_zhou@163.com> Hi everyone, I have been studying VM live migration over NDN for mouths and taking some experiments in NDN testbed. VM is migrated from China to America with source host connecting NDN testbed node of Tongji and destination host in America connecting UMICH testbed node. Data in VM can be accessed by other host at the beginning. Name of Data can be ?/ndn/cn/edu/tongji/vm/ping?. However, this Data cannot be accessed after migration because the name of Data is not registered to FIB of other host. Other host is able to access the Data before migration because Interest can be forwarded to Tongji University by name prefix ?/ndn/cn/edu/tongji?. In contrast, Interest with name ?/ndn/cn/edu/tongji/vm/ping? cannot be forwarded to VM after migration because VM is behind UMICH testbed node but name prefix of the requested Data is not "/ndn/edu/umich". Does anyone have an idea for solving the problem? I think the rule of the solution is that name of Data in VM should not be changed after migration. Best regards, Dejiang Zhou -------------- next part -------------- An HTML attachment was scrubbed... URL: From shock.jiang at gmail.com Sat Feb 28 10:08:16 2015 From: shock.jiang at gmail.com (Xiaoke Jiang) Date: Sat, 28 Feb 2015 10:08:16 -0800 Subject: [Ndn-interest] Data Accessibility in VM Live Migration over NDN In-Reply-To: <3921f845.1342a.14bcfabe795.Coremail.dejiang_zhou@163.com> References: <3921f845.1342a.14bcfabe795.Coremail.dejiang_zhou@163.com> Message-ID: Hi Dejiang, Here is my opinion to your question. What mentioned here seems to be producer mobility support, which is on-going research among NDN. A straightforward solution is to let UMICH router announce the a prefix /ndn/cn/edu/tongji/vm/ping to routing system. Besides the routing approach, there are some proposals too address this problem 1) Kite: http://named-data.net/publications/techreports/tr-ndn20-kite/ 2) LINK+ Map-and-Encap: may also helps but need more efforts: http://named-data.net/techreport/ndn-0004-3-scaling-ndn-routing.pdf p.s., I wonder why not keep the original copy of the vm after migration, therefore you would have two copies can serve future requests. Xiaoke (Shock) > On 28 Feb, 2015, at 2:12 am, Dejiang Zhou wrote: > > Hi everyone, > I have been studying VM live migration over NDN for mouths and taking some experiments in NDN testbed. > VM is migrated from China to America with source host connecting NDN testbed node of Tongji and destination host in America connecting UMICH testbed node. Data in VM can be accessed by other host at the beginning. Name of Data can be ?/ndn/cn/edu/tongji/vm/ping?. However, this Data cannot be accessed after migration because the name of Data is not registered to FIB of other host. Other host is able to access the Data before migration because Interest can be forwarded to Tongji University by name prefix ?/ndn/cn/edu/tongji?. In contrast, Interest with name ?/ndn/cn/edu/tongji/vm/ping? cannot be forwarded to VM after migration because VM is behind UMICH testbed node but name prefix of the requested Data is not "/ndn/edu/umich". > Does anyone have an idea for solving the problem? I think the rule of the solution is that name of Data in VM should not be changed after migration. > Best regards, > Dejiang Zhou > > > _______________________________________________ > 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 alexander.afanasyev at ucla.edu Sat Feb 28 15:45:15 2015 From: alexander.afanasyev at ucla.edu (Alex Afanasyev) Date: Sat, 28 Feb 2015 15:45:15 -0800 Subject: [Ndn-interest] How to add the SecRuleRelative Rules in validator-regex? In-Reply-To: References: <3AE5D813-81E9-449D-8FF9-045D0DD007F3@ucla.edu> Message-ID: <5C834D2E-8F04-4731-A42E-B5B9EE41F676@ucla.edu> Hi Chengyu, I assumed there is a documentation for this method, but the commit that adds it is not yet merged. Here is the description we will have soon: /** * @brief Construct the rule * @param packetRegex regular expression to match the packet name that is qualified for the * the rule (e.g., `^(<.*>)$`) * @param signerRegex regular expression to match the the KeyLocator of the packet (e.g., * `^(<.*>)(<.*>)<>$`) * @param comparator Defines the way expanded signer's name is matched against expanded * packet's name. Possible values are: * - "is-prefix-of" * - "is-strict-prefix-of" * - "equal" * @param packetExpand Expansion rule for packet's name (e.g., `\1`) * @param signerExpand Expansion rule for signer's name (e.g., `\1\2`) * @param isPositive flag denoting whether the rule is positive or negative * * @note A packet complies with the rule only if both \p packetRegex matches the packet name * and \p signerRegex matches the KeyLocator name */ > On Feb 27, 2015, at 7:59 PM, Chengyu Fan wrote: > > Could you tell me how the SecRuleRelative Rule works? > > Specifically, what's the meaning of each parameter? What conditions the rule will test to make a incoming data satisfy the rule? > ndn::SecRuleRelative::SecRuleRelative ( const std::string & dataRegex, > const std::string & signerRegex, > const std::string & op, > const std::string & dataExpand, > const std::string & signerExpand, > bool isPositive > ) > > > > On Fri, Feb 27, 2015 at 1:59 PM, Alex Afanasyev > wrote: > >> On Feb 27, 2015, at 12:10 PM, Chengyu Fan > wrote: >> >> Hi, >> >> I'm trying to use the validator-regex to validate the incoming data, but I stuck at how to add the SecRuleRelative Rule. >> >> Can somebody tell me some clues? >> >> Specifically, I find the example in SecurityLibrary(http://redmine.named-data.net/projects/ndn-cxx/wiki/SecurityLibrary ), but I don't understand the RuleRelative rule below ... >> SecRuleRelative rule("^(<>*)$", "^([^]*)(<>*)$", >> ">", "\\1", "\\1\\2", true); >> >> What's the meaning of ">", "\\1", "\\1\\2" ? Can someone give me an example? > > This is just a regular expression rules. \\1 <> (\1, it?s just \ needs to be escaped in c++) refer to th first group of the regular expression, \\2 <> refer to the second group, etc. > > There are many documentation sources about regexps, e.g., http://www.boost.org/doc/libs/1_57_0/libs/regex/doc/html/boost_regex/syntax/perl_syntax.html . > > The only difference in our regular expressions is the fact that it is defined over name components, not just strings. There is a documentation for this at http://named-data.net/doc/ndn-cxx/current/tutorials/utils-ndn-regex.html > > ? > Alex > > > > > > -- > Thanks, > > Chengyu -------------- 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: