From dibenede at cs.colostate.edu  Sun Jan  4 15:22:40 2015
From: dibenede at cs.colostate.edu (Steve DiBenedetto)
Date: Sun, 4 Jan 2015 16:22:40 -0700
Subject: [Nfd-dev] ndncat/putchunks: ndn-cxx or NFD tools?
Message-ID: <CAG95NwtzZYyL+7YevfqB-UzAfbL1a+zOQXyyrG0H4x-L5ODZNw@mail.gmail.com>

Hi,

There is an ongoing tools discussion related to issue #2106:

http://redmine.named-data.net/issues/2106
http://gerrit.named-data.net/#/c/1581/

The existing ndn-cxx/tools ndncat/putchunks3 are being reworked. The final
programs are slated to live under ndn-cxx/examples and the original
ndn-cxx/tools versions will be deleted.

However, there is an open question over whether or not the new programs are
also useful as tools. If they are, then we need to decide whether they
should live under NFD/tools or ndn-cxx/tools. There is also a maintenance
concern over having the same code in both ndn-cxx/examples and in one of
the tools directories.

Questions:
1. Are ndncat/putchunks useful tools? (now with latest version discovery
and in order output)
2. If so, where should they live?
3. What determines whether something is an NFD or ndn-cxx tool?

Thanks,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150104/ef772837/attachment.html>

From josh at caida.org  Mon Jan  5 08:52:13 2015
From: josh at caida.org (Josh Polterock)
Date: Mon, 5 Jan 2015 08:52:13 -0800
Subject: [Nfd-dev] need volunteer to test EthernetFace on OSX and Boost
 1.57
In-Reply-To: <CADfzvvb-7oX1JCu0p4M+JqwEDPbjTrd+zfhJN2S6EJqcP34Jjw@mail.gmail.com>
References: <20141223220239.GC14038@caida.org>
	<CAOFH+Obb=93j9s6VLiZem2R4ucDdEnDax_LCxMWEmPQnaO2rog@mail.gmail.com>
	<20141223220913.GD14038@caida.org>
	<CADfzvvZ+kwqxvhfS-x+iPg6StZQjD2Myz_-mZ809U-1Bfct=_Q@mail.gmail.com>
	<20141223233934.GE14038@caida.org>
	<CADfzvvZdYxF31e3nnW1W8nDub7H=s72rxLPuAg7uf2gubL5Y7w@mail.gmail.com>
	<20141224000518.GF14038@caida.org>
	<CADfzvvYPzwF0pZQKX31-HMp96=i1WXz_8x_nGNzRD5TkQMX-+w@mail.gmail.com>
	<20141224002210.GG14038@caida.org>
	<CADfzvvb-7oX1JCu0p4M+JqwEDPbjTrd+zfhJN2S6EJqcP34Jjw@mail.gmail.com>
Message-ID: <20150105165213.GH14038@caida.org>

Sorry. Went dark for the holiday.

I do see a couple Ethernet faces:

$ nfd-status -f
Faces:
  faceid=1 remote=internal:// local=internal:// counters={in={0i 11d 0B} out={4i 0d 0B}} local persistent point-to-point
  faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=255 remote=null:// local=null:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=256 remote=udp4://224.0.23.170:56363 local=udp4://192.172.226.92:56363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point 
  faceid=257 remote=udp4://224.0.23.170:56363 local=udp4://127.0.0.1:56363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
  faceid=258 remote=ether://[01:00:5e:00:17:aa] local=dev://en1 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
  faceid=259 remote=ether://[01:00:5e:00:17:aa] local=dev://en0 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
  faceid=260 remote=fd://24 local=unix:///private/var/run/nfd.sock counters={in={4i 0d 955B} out={0i 4d 2006B}} local on-demand point-to-point
  faceid=261 remote=fd://25 local=unix:///private/var/run/nfd.sock counters={in={1i 0d 46B} out={0i 0d 0B}} local on-demand point-to-point

Josh

On Wed, Dec 24, 2014 at 02:41:55AM +0100, Davide Pesavento wrote:
> Josh,
> 
> Ok, good. The face creation works as far as I can see. You should now
> have one or more Ethernet faces in `nfd-status -f`.
> 
> Junxiao asked for more thorough testing, including packet exchange,
> but I don't think it's necessary.
> 
> Thanks again for your help.
> 
> Best,
> Davide
> 
> On Wed, Dec 24, 2014 at 1:22 AM, Josh Polterock <josh at caida.org> wrote:
> > Updated /opt/local/etc/ndn/nfd.conf to match build/nfd.conf.sample
> >
> > NFD output attached.
> >
> > Josh
> >
> > On Wed, Dec 24, 2014 at 01:14:11AM +0100, Davide Pesavento wrote:
> >> The build-time configuration looks good. Please make sure that the
> >> "ether" section exists in the nfd.conf you're using and that it's not
> >> commented out. If unsure, use the default "build/nfd.conf.sample"
> >> file.
> >>
> >> Attach NFD output for the new run with the corrected conf file.
> >>
> >> Thanks,
> >> Davide
> >>
> >> On Wed, Dec 24, 2014 at 1:05 AM, Josh Polterock <josh at caida.org> wrote:
> >> > Wasn't sure which you wanted so included both ndn-cxx and NFD
> >> > build/config.log files attached.
> >> >
> >> > Josh
> >> >
> >> > On Wed, Dec 24, 2014 at 12:53:48AM +0100, Davide Pesavento wrote:
> >> >> EthernetFace does not seem to be enabled. Please attach the file
> >> >> "build/config.log"
> >> >>
> >> >> Thanks,
> >> >> Davide
> >> >>
> >> >> On Wed, Dec 24, 2014 at 12:39 AM, Josh Polterock <josh at caida.org> wrote:
> >> >> > Davide,
> >> >> >
> >> >> > Please find attached.
> >> >> >
> >> >> > Thanks,
> >> >> > Josh
> >> >> >
> >> >> > On Wed, Dec 24, 2014 at 12:23:01AM +0100, Davide Pesavento wrote:
> >> >> >> Josh,
> >> >> >>
> >> >> >> Thanks a lot for testing.
> >> >> >>
> >> >> >> Would you mind attaching (or pasting inline) the output of NFD startup
> >> >> >> phase at a debug level of "ALL"?
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Davide
> >> >> >>
> >> >> >> On Tue, Dec 23, 2014 at 11:09 PM, Josh Polterock <josh at caida.org> wrote:
> >> >> >> > Junxiao,
> >> >> >> >
> >> >> >> > Ok. nfd starts and gives regular DEBUG output.
> >> >> >> >
> >> >> >> > When I execute the 'nfd-status -f | grep 'dev' command it returns
> >> >> >> > nothing.
> >> >> >> >
> >> >> >> > Josh
> >> >> >> >


From shijunxiao at email.arizona.edu  Mon Jan  5 14:26:46 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 5 Jan 2015 15:26:46 -0700
Subject: [Nfd-dev] ndncat/putchunks: ndn-cxx or NFD tools?
In-Reply-To: <CAG95NwtzZYyL+7YevfqB-UzAfbL1a+zOQXyyrG0H4x-L5ODZNw@mail.gmail.com>
References: <CAG95NwtzZYyL+7YevfqB-UzAfbL1a+zOQXyyrG0H4x-L5ODZNw@mail.gmail.com>
Message-ID: <CAOFH+OZvrkLzbF9PacAg6eVdGyWAxueNOD457YYz9jn0NDSLqA@mail.gmail.com>

Hi Steve

I'll begin with the third question.

My observation and opinion is: a tool shall be bundled with ndn-cxx if it
can be used without installing NFD.
The two tools bundled with ndn-cxx are:

   - ndnsec: controls the KeyChain
   - tlvdump: parses the packet format

They both don't require NFD.


I recognize that there are certain tools which are not closely related to
NFD, but are useful in most places where NFD is installed.
They include:

   - peek and poke
   - catchunks and putchunks
   - ping and pingserver

I suggest creating a separate "ndn-tools" repository which contains all
these tools.
Operator still installs from three repositories, ndn-cxx, NFD, ndn-tools
(formerly ndn-tlv-ping), so this change doesn't increase the difficulty of
deployment.

Yours, Junxiao

On Sun, Jan 4, 2015 at 4:22 PM, Steve DiBenedetto <dibenede at cs.colostate.edu
> wrote:

> Hi,
>
> There is an ongoing tools discussion related to issue #2106:
>
> http://redmine.named-data.net/issues/2106
> http://gerrit.named-data.net/#/c/1581/
>
> The existing ndn-cxx/tools ndncat/putchunks3 are being reworked. The final
> programs are slated to live under ndn-cxx/examples and the original
> ndn-cxx/tools versions will be deleted.
>
> However, there is an open question over whether or not the new programs
> are also useful as tools. If they are, then we need to decide whether they
> should live under NFD/tools or ndn-cxx/tools. There is also a maintenance
> concern over having the same code in both ndn-cxx/examples and in one of
> the tools directories.
>
> Questions:
> 1. Are ndncat/putchunks useful tools? (now with latest version discovery
> and in order output)
> 2. If so, where should they live?
> 3. What determines whether something is an NFD or ndn-cxx tool?
>
> Thanks,
> Steve
>
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150105/7ea404f5/attachment.html>

From davide.pesavento at lip6.fr  Tue Jan  6 03:54:11 2015
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Tue, 6 Jan 2015 12:54:11 +0100
Subject: [Nfd-dev] need volunteer to test EthernetFace on OSX and Boost
	1.57
In-Reply-To: <20150105165213.GH14038@caida.org>
References: <20141223220239.GC14038@caida.org>
	<CAOFH+Obb=93j9s6VLiZem2R4ucDdEnDax_LCxMWEmPQnaO2rog@mail.gmail.com>
	<20141223220913.GD14038@caida.org>
	<CADfzvvZ+kwqxvhfS-x+iPg6StZQjD2Myz_-mZ809U-1Bfct=_Q@mail.gmail.com>
	<20141223233934.GE14038@caida.org>
	<CADfzvvZdYxF31e3nnW1W8nDub7H=s72rxLPuAg7uf2gubL5Y7w@mail.gmail.com>
	<20141224000518.GF14038@caida.org>
	<CADfzvvYPzwF0pZQKX31-HMp96=i1WXz_8x_nGNzRD5TkQMX-+w@mail.gmail.com>
	<20141224002210.GG14038@caida.org>
	<CADfzvvb-7oX1JCu0p4M+JqwEDPbjTrd+zfhJN2S6EJqcP34Jjw@mail.gmail.com>
	<20150105165213.GH14038@caida.org>
Message-ID: <CADfzvvZ2mypvVFSXvpSDgXCtZZc72VRqHTC_RCEdEAFGT9BGSQ@mail.gmail.com>

Great. I guess this (successfully) concludes our testing.

Thanks again for volunteering Josh!

Best,
Davide

On Mon, Jan 5, 2015 at 5:52 PM, Josh Polterock <josh at caida.org> wrote:
> Sorry. Went dark for the holiday.
>
> I do see a couple Ethernet faces:
>
> $ nfd-status -f
> Faces:
>   faceid=1 remote=internal:// local=internal:// counters={in={0i 11d 0B} out={4i 0d 0B}} local persistent point-to-point
>   faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
>   faceid=255 remote=null:// local=null:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
>   faceid=256 remote=udp4://224.0.23.170:56363 local=udp4://192.172.226.92:56363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
>   faceid=257 remote=udp4://224.0.23.170:56363 local=udp4://127.0.0.1:56363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
>   faceid=258 remote=ether://[01:00:5e:00:17:aa] local=dev://en1 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
>   faceid=259 remote=ether://[01:00:5e:00:17:aa] local=dev://en0 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
>   faceid=260 remote=fd://24 local=unix:///private/var/run/nfd.sock counters={in={4i 0d 955B} out={0i 4d 2006B}} local on-demand point-to-point
>   faceid=261 remote=fd://25 local=unix:///private/var/run/nfd.sock counters={in={1i 0d 46B} out={0i 0d 0B}} local on-demand point-to-point
>
> Josh
>
> On Wed, Dec 24, 2014 at 02:41:55AM +0100, Davide Pesavento wrote:
>> Josh,
>>
>> Ok, good. The face creation works as far as I can see. You should now
>> have one or more Ethernet faces in `nfd-status -f`.
>>
>> Junxiao asked for more thorough testing, including packet exchange,
>> but I don't think it's necessary.
>>
>> Thanks again for your help.
>>
>> Best,
>> Davide
>>
>> On Wed, Dec 24, 2014 at 1:22 AM, Josh Polterock <josh at caida.org> wrote:
>> > Updated /opt/local/etc/ndn/nfd.conf to match build/nfd.conf.sample
>> >
>> > NFD output attached.
>> >
>> > Josh
>> >
>> > On Wed, Dec 24, 2014 at 01:14:11AM +0100, Davide Pesavento wrote:
>> >> The build-time configuration looks good. Please make sure that the
>> >> "ether" section exists in the nfd.conf you're using and that it's not
>> >> commented out. If unsure, use the default "build/nfd.conf.sample"
>> >> file.
>> >>
>> >> Attach NFD output for the new run with the corrected conf file.
>> >>
>> >> Thanks,
>> >> Davide
>> >>
>> >> On Wed, Dec 24, 2014 at 1:05 AM, Josh Polterock <josh at caida.org> wrote:
>> >> > Wasn't sure which you wanted so included both ndn-cxx and NFD
>> >> > build/config.log files attached.
>> >> >
>> >> > Josh
>> >> >
>> >> > On Wed, Dec 24, 2014 at 12:53:48AM +0100, Davide Pesavento wrote:
>> >> >> EthernetFace does not seem to be enabled. Please attach the file
>> >> >> "build/config.log"
>> >> >>
>> >> >> Thanks,
>> >> >> Davide
>> >> >>
>> >> >> On Wed, Dec 24, 2014 at 12:39 AM, Josh Polterock <josh at caida.org> wrote:
>> >> >> > Davide,
>> >> >> >
>> >> >> > Please find attached.
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Josh
>> >> >> >
>> >> >> > On Wed, Dec 24, 2014 at 12:23:01AM +0100, Davide Pesavento wrote:
>> >> >> >> Josh,
>> >> >> >>
>> >> >> >> Thanks a lot for testing.
>> >> >> >>
>> >> >> >> Would you mind attaching (or pasting inline) the output of NFD startup
>> >> >> >> phase at a debug level of "ALL"?
>> >> >> >>
>> >> >> >> Thanks,
>> >> >> >> Davide
>> >> >> >>
>> >> >> >> On Tue, Dec 23, 2014 at 11:09 PM, Josh Polterock <josh at caida.org> wrote:
>> >> >> >> > Junxiao,
>> >> >> >> >
>> >> >> >> > Ok. nfd starts and gives regular DEBUG output.
>> >> >> >> >
>> >> >> >> > When I execute the 'nfd-status -f | grep 'dev' command it returns
>> >> >> >> > nothing.
>> >> >> >> >
>> >> >> >> > Josh
>> >> >> >> >
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev


From shijunxiao at email.arizona.edu  Tue Jan  6 08:35:49 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 6 Jan 2015 09:35:49 -0700
Subject: [Nfd-dev] ndn-cxx deprecated feature removal:
	DummyClientFace::onInterest|Data
Message-ID: <CAOFH+OZ-PjLA3-u_pLLFWxaKKDaLih0VgBid5RACD-KuY_2Z0g@mail.gmail.com>

Dear folks

The following deprecated feature will be removed from ndn-cxx soon:
DummyClientFace::onInterest => use onSendInterest
DummyClientFace::onData => use onSendData

If you have code that depend on this feature and cannot be fixed now,
please reply no later than Jan 13 12:00 UTC.
Otherwise, we'll proceed with the removal after that time.

You can compile your projects with ndn-cxx Change
http://gerrit.named-data.net/1592 and verify it works.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150106/dd761af0/attachment.html>

From alexander.afanasyev at ucla.edu  Wed Jan  7 11:52:57 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 7 Jan 2015 11:52:57 -0800
Subject: [Nfd-dev] [ndnSIM] NFD Development - Content Store
In-Reply-To: <659ce27888812915baf2556d0312b72c@ce.sharif.edu>
References: <659ce27888812915baf2556d0312b72c@ce.sharif.edu>
Message-ID: <DF4490CA-250C-41C9-A9CD-70C6BC0FC2F8@ucla.edu>

Hi Leonid,

There is nfd-dev at lists.cs.ucla.edu mailing list for discussions specificaly about NFD development (cc'ed here).

I saw your question on ndn-interest mailing list and it didn't strike me as directly related to NFD :)
Theoretically, if you want, you can make it persistent.  If you're asking about the current code, then we don't have that capability and you're welcome to contribute it.

---
Alex

> On Jan 7, 2015, at 3:45 AM, L.Zeynalvand <zeynalvand at ce.sharif.edu> wrote:
> 
> Hi, is there a specific mailing list to post questions regarding NFD Development? If not, I would appreciate if you help me out with this.
> Is there a way to make the Content Store persistent? By persistent I don't mean no cache replacement, what I mean is that if for any reason we power off the router and then power back on, whatever there was in content store remain intact. (consider the router is an end user  home wifi)
> 
> Regards,
> 
> -- 
> Leonid Zeynalvand
> M.Sc Information Technology
> Sharif University of Technology



From shijunxiao at email.arizona.edu  Wed Jan  7 22:15:23 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 7 Jan 2015 23:15:23 -0700
Subject: [Nfd-dev] Copyright holder section of license boilerplate
In-Reply-To: <CAOFH+Obxm55ceZ4QjJYCDVSqSB-1WJ-zFZc5CeFpJmiR1Wgbzw@mail.gmail.com>
References: <CAOFH+OaW_KdQa75-oUiK7TcoK-Bx=S6ovfHH0UPpj9Epz7vQgg@mail.gmail.com>
	<CAOFH+OZhMEFW62x_E=6i+m=pcsKjUUSQfhaEEp3EtJ4q-DXmNQ@mail.gmail.com>
	<CAOFH+ObnWSQNuF7qcSxhcaMmDy=OgxeGxi+Gm-EzmfGVCH7J4g@mail.gmail.com>
	<CAOFH+Obxm55ceZ4QjJYCDVSqSB-1WJ-zFZc5CeFpJmiR1Wgbzw@mail.gmail.com>
Message-ID: <CAOFH+OZoD087q4kLp4RJvvbb8DN2h_pJLOSUARx2_Z5p0fV-qg@mail.gmail.com>

Dear folks

During the review of NFD Task 2352, a question was raised about copyright
holder in license boilerplates.

My opinion is that every file must carry the same license boilerplate,
regardless of contributor. The benefit is that the whole NFD repository is
owned by a single set of copyright holders (the seven institutions), so
that relicensing is easy.

Alex's opinion is that one people from "NDN team" (which itself is an
undefined concept) needs to use a standard license boilerplate of seven
institutions as copyright holders, while other contributors can declare
different copyright holders without assigning copyright to the seven
institutions, but still get code merged into NFD repository. I think this
approach would cause difficulty in relicensing NFD code.

A policy decision on this problem is needed before #2352 can continue.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150107/4db71cbd/attachment.html>

From alexander.afanasyev at UCLA.EDU  Wed Jan  7 22:35:49 2015
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Wed, 7 Jan 2015 22:35:49 -0800
Subject: [Nfd-dev] Authorization settings update on NDN Jenkins
Message-ID: <A12C6F90-6B92-4500-82D8-25A3CF1C4A15@ucla.edu>

Given google is removing support for OpenID2, I have updated configuration to use Google Login.

Unfortunately, this means that there is no longer support for any other types of logins.  I hope this will not cause any big problems.

---
Alex


From shijunxiao at email.arizona.edu  Wed Jan  7 22:42:28 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 7 Jan 2015 23:42:28 -0700
Subject: [Nfd-dev] Authorization settings update on NDN Jenkins
In-Reply-To: <A12C6F90-6B92-4500-82D8-25A3CF1C4A15@ucla.edu>
References: <A12C6F90-6B92-4500-82D8-25A3CF1C4A15@ucla.edu>
Message-ID: <CAOFH+OYkM3xWL_rajvZCsBouQQ-PhiExw5PJiPDB8rix0eGtAA@mail.gmail.com>

Hi Alex

Can we have both username+password login and Google Login?

Also, I notice that my primary Google Account is mapped to a different
Jenkins account than the one linked with OpenID of the same Google Account.
How to get the Google Account mapped to the correct Jenkins account?

Yours, Junxiao
On Jan 7, 2015 11:36 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
wrote:

> Given google is removing support for OpenID2, I have updated configuration
> to use Google Login.
>
> Unfortunately, this means that there is no longer support for any other
> types of logins.  I hope this will not cause any big problems.
>
> ---
> Alex
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150107/2564c55e/attachment.html>

From alexander.afanasyev at ucla.edu  Wed Jan  7 23:03:36 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 7 Jan 2015 23:03:36 -0800
Subject: [Nfd-dev] Authorization settings update on NDN Jenkins
In-Reply-To: <CAOFH+OYkM3xWL_rajvZCsBouQQ-PhiExw5PJiPDB8rix0eGtAA@mail.gmail.com>
References: <A12C6F90-6B92-4500-82D8-25A3CF1C4A15@ucla.edu>
	<CAOFH+OYkM3xWL_rajvZCsBouQQ-PhiExw5PJiPDB8rix0eGtAA@mail.gmail.com>
Message-ID: <DD4644A9-BEAB-42F3-ABE2-C7813D6B0E1B@ucla.edu>

I don?t think it is possible, at least I don?t see such option to be available.

As I understand, jenkins account name is your google account name (gmail email).  You can select different account when you logging in, but with jenkins it doesn?t really matter.  We have relatively permissive security policy right now.

?
Alex

> On Jan 7, 2015, at 10:42 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Alex
> 
> Can we have both username+password login and Google Login?
> 
> Also, I notice that my primary Google Account is mapped to a different Jenkins account than the one linked with OpenID of the same Google Account. How to get the Google Account mapped to the correct Jenkins account?
> 
> Yours, Junxiao
> 
> On Jan 7, 2015 11:36 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu <mailto:alexander.afanasyev at ucla.edu>> wrote:
> Given google is removing support for OpenID2, I have updated configuration to use Google Login.
> 
> Unfortunately, this means that there is no longer support for any other types of logins.  I hope this will not cause any big problems.
> 
> ---
> Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150107/3468fefd/attachment.html>

From lixia at CS.UCLA.EDU  Thu Jan  8 08:09:13 2015
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Thu, 8 Jan 2015 08:09:13 -0800
Subject: [Nfd-dev] [ndnSIM] NFD Development - Content Store
In-Reply-To: <749c724082d6eb952517510af743f55c@ce.sharif.edu>
References: <659ce27888812915baf2556d0312b72c@ce.sharif.edu>
	<DF4490CA-250C-41C9-A9CD-70C6BC0FC2F8@ucla.edu>
	<749c724082d6eb952517510af743f55c@ce.sharif.edu>
Message-ID: <FAC739D1-DD95-4B0B-A4B9-3BE31B15895F@cs.ucla.edu>


> On Jan 8, 2015, at 1:39 AM, L.Zeynalvand <zeynalvand at ce.sharif.edu> wrote:
> 
> Thank you Alex,
> Actually my thesis is decentralized social networking using named data, in which people's private social content is hosted right from their homes, having a part of the content store persistent is crucial for me. I'll work on the NFD code and let you know the results.
> 
> Regards,
> -- 
> Leonid Zeynalvand
> M.Sc Information Technology
> Sharif University of Technology

Personally I would suggest you look into ndn repo for persistent storage

> 
> On 07.01.2015 23:22, Alex Afanasyev wrote:
>> Hi Leonid,
>> 
>> There is nfd-dev at lists.cs.ucla.edu mailing list for discussions
>> specificaly about NFD development (cc'ed here).
>> 
>> I saw your question on ndn-interest mailing list and it didn't strike
>> me as directly related to NFD :)
>> Theoretically, if you want, you can make it persistent.  If you're
>> asking about the current code, then we don't have that capability and
>> you're welcome to contribute it.
>> 
>> ---
>> Alex
>> 
>>> On Jan 7, 2015, at 3:45 AM, L.Zeynalvand <zeynalvand at ce.sharif.edu> wrote:
>>> 
>>> Hi, is there a specific mailing list to post questions regarding NFD Development? If not, I would appreciate if you help me out with this.
>>> Is there a way to make the Content Store persistent? By persistent I don't mean no cache replacement, what I mean is that if for any reason we power off the router and then power back on, whatever there was in content store remain intact. (consider the router is an end user  home wifi)
>>> 
>>> Regards,
>>> 
>>> --
>>> Leonid Zeynalvand
>>> M.Sc Information Technology
>>> Sharif University of Technology
> 
> _______________________________________________
> ndnSIM mailing list
> ndnSIM at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim




From dibenede at cs.colostate.edu  Thu Jan  8 08:48:16 2015
From: dibenede at cs.colostate.edu (Steve DiBenedetto)
Date: Thu, 8 Jan 2015 09:48:16 -0700
Subject: [Nfd-dev] Copyright holder section of license boilerplate
In-Reply-To: <CAOFH+OZoD087q4kLp4RJvvbb8DN2h_pJLOSUARx2_Z5p0fV-qg@mail.gmail.com>
References: <CAOFH+OaW_KdQa75-oUiK7TcoK-Bx=S6ovfHH0UPpj9Epz7vQgg@mail.gmail.com>
	<CAOFH+OZhMEFW62x_E=6i+m=pcsKjUUSQfhaEEp3EtJ4q-DXmNQ@mail.gmail.com>
	<CAOFH+ObnWSQNuF7qcSxhcaMmDy=OgxeGxi+Gm-EzmfGVCH7J4g@mail.gmail.com>
	<CAOFH+Obxm55ceZ4QjJYCDVSqSB-1WJ-zFZc5CeFpJmiR1Wgbzw@mail.gmail.com>
	<CAOFH+OZoD087q4kLp4RJvvbb8DN2h_pJLOSUARx2_Z5p0fV-qg@mail.gmail.com>
Message-ID: <CAG95Nwvsfg3Ecm1TrEMTRqYhAEDFeh91SFEVM7ZJ3AUe+GcatQ@mail.gmail.com>

I am not a lawyer (...and I'm not sure anyone on this list is).

Junxiao, I can see where you're coming from and agree with what you're
trying to achieve. However, I think Alex is right. It sounds like you are
trying to enforce an implicit contributor agreement. Implicit is probably a
very bad thing when it comes to legal matters.

The safest/best option is to seek legal counsel. A quick email to the SFLC (
https://www.softwarefreedom.org) might get us on the right track.

Additionally, we should consider having an explicit contributors agreement.
Here are a couple of well known agreement documents:

  Apache: http://www.apache.org/licenses/icla.txt
  Selenium (aka mercurial dvcs tool):
https://docs.google.com/forms/d/11Z8LoYpTGUIwCegifVH1YtL9smxVDNk-fOykUZTAWhE/viewform?formkey=dFFjXzBzM1VwekFlOWFWMjFFRjJMRFE6MQ&hl=en_US


-Steve

On Wed, Jan 7, 2015 at 11:15 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Dear folks
>
> During the review of NFD Task 2352, a question was raised about copyright
> holder in license boilerplates.
>
> My opinion is that every file must carry the same license boilerplate,
> regardless of contributor. The benefit is that the whole NFD repository is
> owned by a single set of copyright holders (the seven institutions), so
> that relicensing is easy.
>
> Alex's opinion is that one people from "NDN team" (which itself is an
> undefined concept) needs to use a standard license boilerplate of seven
> institutions as copyright holders, while other contributors can declare
> different copyright holders without assigning copyright to the seven
> institutions, but still get code merged into NFD repository. I think this
> approach would cause difficulty in relicensing NFD code.
>
> A policy decision on this problem is needed before #2352 can continue.
>
> Yours, Junxiao
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150108/c13626cb/attachment.html>

From oran at cisco.com  Thu Jan  8 08:49:24 2015
From: oran at cisco.com (Dave Oran (oran))
Date: Thu, 8 Jan 2015 16:49:24 +0000
Subject: [Nfd-dev] [ndnSIM] NFD Development - Content Store
In-Reply-To: <FAC739D1-DD95-4B0B-A4B9-3BE31B15895F@cs.ucla.edu>
References: <659ce27888812915baf2556d0312b72c@ce.sharif.edu>
	<DF4490CA-250C-41C9-A9CD-70C6BC0FC2F8@ucla.edu>
	<749c724082d6eb952517510af743f55c@ce.sharif.edu>
	<FAC739D1-DD95-4B0B-A4B9-3BE31B15895F@cs.ucla.edu>
Message-ID: <01C08130-0346-4EB0-9FA2-B56C3B22E8D9@cisco.com>


> On Jan 8, 2015, at 8:09 AM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
> 
> 
>> On Jan 8, 2015, at 1:39 AM, L.Zeynalvand <zeynalvand at ce.sharif.edu> wrote:
>> 
>> Thank you Alex,
>> Actually my thesis is decentralized social networking using named data, in which people's private social content is hosted right from their homes, having a part of the content store persistent is crucial for me. I'll work on the NFD code and let you know the results.
>> 
>> Regards,
>> -- 
>> Leonid Zeynalvand
>> M.Sc Information Technology
>> Sharif University of Technology
> 
> Personally I would suggest you look into ndn repo for persistent storage
> 
I think there are two independent capabilities here:

1. A ?repo? as a robust storage service to applications who want to be able to go quiet or stop running without the authoritative published data under their control becoming inaccessible.

2. A performance/robustness feature of a cache such that its content survive a disruption due to a power failure, reboot, etc.

We tend to use the term ?persistent storage" for both of these - I would argue they are conceptually different but could be achieved by similar or the same storage service features used by the NDN software. 

DaveO.

>> 
>> On 07.01.2015 23:22, Alex Afanasyev wrote:
>>> Hi Leonid,
>>> 
>>> There is nfd-dev at lists.cs.ucla.edu mailing list for discussions
>>> specificaly about NFD development (cc'ed here).
>>> 
>>> I saw your question on ndn-interest mailing list and it didn't strike
>>> me as directly related to NFD :)
>>> Theoretically, if you want, you can make it persistent.  If you're
>>> asking about the current code, then we don't have that capability and
>>> you're welcome to contribute it.
>>> 
>>> ---
>>> Alex
>>> 
>>>> On Jan 7, 2015, at 3:45 AM, L.Zeynalvand <zeynalvand at ce.sharif.edu> wrote:
>>>> 
>>>> Hi, is there a specific mailing list to post questions regarding NFD Development? If not, I would appreciate if you help me out with this.
>>>> Is there a way to make the Content Store persistent? By persistent I don't mean no cache replacement, what I mean is that if for any reason we power off the router and then power back on, whatever there was in content store remain intact. (consider the router is an end user  home wifi)
>>>> 
>>>> Regards,
>>>> 
>>>> --
>>>> Leonid Zeynalvand
>>>> M.Sc Information Technology
>>>> Sharif University of Technology
>> 
>> _______________________________________________
>> ndnSIM mailing list
>> ndnSIM at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From jburke at remap.UCLA.EDU  Thu Jan  8 08:56:22 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Thu, 8 Jan 2015 16:56:22 +0000
Subject: [Nfd-dev] Copyright holder section of license boilerplate
In-Reply-To: <CAG95Nwvsfg3Ecm1TrEMTRqYhAEDFeh91SFEVM7ZJ3AUe+GcatQ@mail.gmail.com>
Message-ID: <D0D3F677.1A2439%jburke@remap.ucla.edu>

An explicit contributor agreement is needed and should address this issue; this question should probably be directed to the PIs responsible for NFD before contacting SFLC since the team is in contact with them on other matters already.

jeff


From: Steve DiBenedetto <dibenede at cs.colostate.edu<mailto:dibenede at cs.colostate.edu>>
Date: Thu, 8 Jan 2015 09:48:16 -0700
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Cc: "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Copyright holder section of license boilerplate

I am not a lawyer (...and I'm not sure anyone on this list is).

Junxiao, I can see where you're coming from and agree with what you're trying to achieve. However, I think Alex is right. It sounds like you are trying to enforce an implicit contributor agreement. Implicit is probably a very bad thing when it comes to legal matters.

The safest/best option is to seek legal counsel. A quick email to the SFLC (https://www.softwarefreedom.org) might get us on the right track.

Additionally, we should consider having an explicit contributors agreement. Here are a couple of well known agreement documents:

  Apache: http://www.apache.org/licenses/icla.txt
  Selenium (aka mercurial dvcs tool): https://docs.google.com/forms/d/11Z8LoYpTGUIwCegifVH1YtL9smxVDNk-fOykUZTAWhE/viewform?formkey=dFFjXzBzM1VwekFlOWFWMjFFRjJMRFE6MQ&hl=en_US

-Steve

On Wed, Jan 7, 2015 at 11:15 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Dear folks

During the review of NFD Task 2352, a question was raised about copyright holder in license boilerplates.

My opinion is that every file must carry the same license boilerplate, regardless of contributor. The benefit is that the whole NFD repository is owned by a single set of copyright holders (the seven institutions), so that relicensing is easy.

Alex's opinion is that one people from "NDN team" (which itself is an undefined concept) needs to use a standard license boilerplate of seven institutions as copyright holders, while other contributors can declare different copyright holders without assigning copyright to the seven institutions, but still get code merged into NFD repository. I think this approach would cause difficulty in relicensing NFD code.

A policy decision on this problem is needed before #2352 can continue.

Yours, Junxiao

_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev


_______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150108/f7ebee06/attachment.html>

From zeynalvand at ce.sharif.edu  Thu Jan  8 13:06:16 2015
From: zeynalvand at ce.sharif.edu (L.Zeynalvand)
Date: Fri, 09 Jan 2015 00:36:16 +0330
Subject: [Nfd-dev] [ndnSIM] NFD Development - Content Store
In-Reply-To: <FAC739D1-DD95-4B0B-A4B9-3BE31B15895F@cs.ucla.edu>
References: <659ce27888812915baf2556d0312b72c@ce.sharif.edu>
	<DF4490CA-250C-41C9-A9CD-70C6BC0FC2F8@ucla.edu>
	<749c724082d6eb952517510af743f55c@ce.sharif.edu>
	<FAC739D1-DD95-4B0B-A4B9-3BE31B15895F@cs.ucla.edu>
Message-ID: <519eddf9c822ab4089ab5e5789617bca@ce.sharif.edu>

ndn repo seems to be just what I need, thank you.

On 08.01.2015 19:39, Lixia Zhang wrote:
>> On Jan 8, 2015, at 1:39 AM, L.Zeynalvand <zeynalvand at ce.sharif.edu> 
>> wrote:
>>
>> Thank you Alex,
>> Actually my thesis is decentralized social networking using named 
>> data, in which people's private social content is hosted right from 
>> their homes, having a part of the content store persistent is crucial 
>> for me. I'll work on the NFD code and let you know the results.
>>
>> Regards,
>> --
>> Leonid Zeynalvand
>> M.Sc Information Technology
>> Sharif University of Technology
>
> Personally I would suggest you look into ndn repo for persistent 
> storage
>
>>
>> On 07.01.2015 23:22, Alex Afanasyev wrote:
>>> Hi Leonid,
>>>
>>> There is nfd-dev at lists.cs.ucla.edu mailing list for discussions
>>> specificaly about NFD development (cc'ed here).
>>>
>>> I saw your question on ndn-interest mailing list and it didn't 
>>> strike
>>> me as directly related to NFD :)
>>> Theoretically, if you want, you can make it persistent.  If you're
>>> asking about the current code, then we don't have that capability 
>>> and
>>> you're welcome to contribute it.
>>>
>>> ---
>>> Alex
>>>
>>>> On Jan 7, 2015, at 3:45 AM, L.Zeynalvand 
>>>> <zeynalvand at ce.sharif.edu> wrote:
>>>>
>>>> Hi, is there a specific mailing list to post questions regarding 
>>>> NFD Development? If not, I would appreciate if you help me out with 
>>>> this.
>>>> Is there a way to make the Content Store persistent? By persistent 
>>>> I don't mean no cache replacement, what I mean is that if for any 
>>>> reason we power off the router and then power back on, whatever 
>>>> there was in content store remain intact. (consider the router is an 
>>>> end user  home wifi)
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Leonid Zeynalvand
>>>> M.Sc Information Technology
>>>> Sharif University of Technology
>>
>> _______________________________________________
>> ndnSIM mailing list
>> ndnSIM at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim

-- 
Leonid Zeynalvand
M.Sc Information Technology
Sharif University of Technology


From lixia at CS.UCLA.EDU  Thu Jan  8 19:32:33 2015
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Thu, 8 Jan 2015 19:32:33 -0800
Subject: [Nfd-dev] [ndnSIM] NFD Development - Content Store
In-Reply-To: <01C08130-0346-4EB0-9FA2-B56C3B22E8D9@cisco.com>
References: <659ce27888812915baf2556d0312b72c@ce.sharif.edu>
	<DF4490CA-250C-41C9-A9CD-70C6BC0FC2F8@ucla.edu>
	<749c724082d6eb952517510af743f55c@ce.sharif.edu>
	<FAC739D1-DD95-4B0B-A4B9-3BE31B15895F@cs.ucla.edu>
	<01C08130-0346-4EB0-9FA2-B56C3B22E8D9@cisco.com>
Message-ID: <D91EABAC-7926-46E9-BDFA-83393759A418@cs.ucla.edu>


> On Jan 8, 2015, at 8:49 AM, Dave Oran (oran) <oran at cisco.com> wrote:
> 
> 
>> On Jan 8, 2015, at 8:09 AM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
>> 
>> 
>>> On Jan 8, 2015, at 1:39 AM, L.Zeynalvand <zeynalvand at ce.sharif.edu> wrote:
>>> 
>>> Thank you Alex,
>>> Actually my thesis is decentralized social networking using named data, in which people's private social content is hosted right from their homes, having a part of the content store persistent is crucial for me. I'll work on the NFD code and let you know the results.
>>> 
>>> Regards,
>>> -- 
>>> Leonid Zeynalvand
>>> M.Sc Information Technology
>>> Sharif University of Technology
>> 
>> Personally I would suggest you look into ndn repo for persistent storage
>> 
> I think there are two independent capabilities here:
> 
> 1. A ?repo? as a robust storage service to applications who want to be able to go quiet or stop running without the authoritative published data under their control becoming inaccessible.
> 
> 2. A performance/robustness feature of a cache such that its content survive a disruption due to a power failure, reboot, etc.
> 
> We tend to use the term ?persistent storage" for both of these - I would argue they are conceptually different but could be achieved by similar or the same storage service features used by the NDN software. 
> 
> DaveO.

you are absolutely right that these are two separate issues.

>From Leonid's msg, I just guessed that he might meant a managed storage service, i.e. your first one. But I should have clarified, thanks for pointing out.

Lixia


From shijunxiao at email.arizona.edu  Fri Jan  9 09:25:24 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 9 Jan 2015 10:25:24 -0700
Subject: [Nfd-dev] NFD and ndn-cxx license boilerplate update script
Message-ID: <CAOFH+Obe7kT-mPyoL6N9BODz-xD_bdCuBL2YO5WPK8YACJwmBA@mail.gmail.com>

Hi developers

I wrote a simple script to automatically add or update the license
boilerplate for C++ files in NFD and ndn-cxx repository.
https://gist.github.com/yoursunny/6297f3c70f5441213184

You may choose to use this script instead of manually pasting license
boilerplate into each file you've edited.

Install:

   1. download the script to the parent folder of where you've cloned NFD
   and ndn-cxx
   2. make it executable

Usage:

   1. make changes to code
   2. git add or git rm
   3. ../update-license.sh
   4. git commit

If you've already committed:

   1. ../update-license.sh HEAD^1
   2. git commit -a --amend



Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150109/09e4d2dd/attachment.html>

From zeynalvand at ce.sharif.edu  Mon Jan 12 08:03:24 2015
From: zeynalvand at ce.sharif.edu (L.Zeynalvand)
Date: Mon, 12 Jan 2015 19:33:24 +0330
Subject: [Nfd-dev] [ndnSIM] NFD Development - Content Store
In-Reply-To: <D91EABAC-7926-46E9-BDFA-83393759A418@cs.ucla.edu>
References: <659ce27888812915baf2556d0312b72c@ce.sharif.edu>
	<DF4490CA-250C-41C9-A9CD-70C6BC0FC2F8@ucla.edu>
	<749c724082d6eb952517510af743f55c@ce.sharif.edu>
	<FAC739D1-DD95-4B0B-A4B9-3BE31B15895F@cs.ucla.edu>
	<01C08130-0346-4EB0-9FA2-B56C3B22E8D9@cisco.com>
	<D91EABAC-7926-46E9-BDFA-83393759A418@cs.ucla.edu>
Message-ID: <67ee60d573e69f70caec529a9d28eb53@ce.sharif.edu>

On 09.01.2015 07:02, Lixia Zhang wrote:
>> On Jan 8, 2015, at 8:49 AM, Dave Oran (oran) <oran at cisco.com> wrote:
>>
>>
>>> On Jan 8, 2015, at 8:09 AM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
>>>
>>>
>>>> On Jan 8, 2015, at 1:39 AM, L.Zeynalvand 
>>>> <zeynalvand at ce.sharif.edu> wrote:
>>>>
>>>> Thank you Alex,
>>>> Actually my thesis is decentralized social networking using named 
>>>> data, in which people's private social content is hosted right from 
>>>> their homes, having a part of the content store persistent is 
>>>> crucial for me. I'll work on the NFD code and let you know the 
>>>> results.
>>>>
>>>> Regards,
>>>> --
>>>> Leonid Zeynalvand
>>>> M.Sc Information Technology
>>>> Sharif University of Technology
>>>
>>> Personally I would suggest you look into ndn repo for persistent 
>>> storage
>>>
>> I think there are two independent capabilities here:
>>
>> 1. A ?repo? as a robust storage service to applications who want to 
>> be able to go quiet or stop running without the authoritative 
>> published data under their control becoming inaccessible.
>>
>> 2. A performance/robustness feature of a cache such that its content 
>> survive a disruption due to a power failure, reboot, etc.
>>
>> We tend to use the term ?persistent storage" for both of these - I 
>> would argue they are conceptually different but could be achieved by 
>> similar or the same storage service features used by the NDN software.
>>
>> DaveO.
>
> you are absolutely right that these are two separate issues.
>
> From Leonid's msg, I just guessed that he might meant a managed
> storage service, i.e. your first one. But I should have clarified,
> thanks for pointing out.
>
> Lixia

Thank you Dave for your consideration,
Actually the first one was exactly what I needed.
-- 
Leonid Zeynalvand
M.Sc Information Technology
Sharif University of Technology


From shijunxiao at email.arizona.edu  Tue Jan 13 20:18:31 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 13 Jan 2015 21:18:31 -0700
Subject: [Nfd-dev] review request: access strategy
Message-ID: <CAOFH+OayVNsnovHN80STgAymT+GXiHcOd+jHEW5RVZer0Ehn5g@mail.gmail.com>

Dear folks

I have implemented *Strategy for Access Router* (#1999) and I need someone
to review the code:

http://gerrit.named-data.net/1545

If you are willing to have a look at the patch, I'll appreciate that.
You don't have to be an expert in order to do a code review.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150113/585b5472/attachment.html>

From shijunxiao at email.arizona.edu  Tue Jan 13 21:30:03 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 13 Jan 2015 22:30:03 -0700
Subject: [Nfd-dev] RPM guru wanted
Message-ID: <CAOFH+Oae5_CLP-dPnD0guEMmyd=w98x0LDv+BOaeD=_2X-qokw@mail.gmail.com>

Dear folks

Does someone on this list know how to build RPM packages for Fedora or
CentOS platform?
We want to publish NFD binary packages for those platforms.

If you know a thing or two about RPM packaging, or startup configuration
(init daemon) on those platforms,
please have a look at http://redmine.named-data.net/issues/1587 and post a
note on that issue, or reply-all to this message.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150113/77f9baa6/attachment.html>

From susmit at cs.colostate.edu  Tue Jan 13 21:44:48 2015
From: susmit at cs.colostate.edu (Susmit)
Date: Wed, 14 Jan 2015 11:14:48 +0530
Subject: [Nfd-dev] RPM guru wanted
In-Reply-To: <CAOFH+Oae5_CLP-dPnD0guEMmyd=w98x0LDv+BOaeD=_2X-qokw@mail.gmail.com>
References: <CAOFH+Oae5_CLP-dPnD0guEMmyd=w98x0LDv+BOaeD=_2X-qokw@mail.gmail.com>
Message-ID: <CAM4XVkoTv6qh7kNdj8WSo5Y8LsMN-kFFT6-4SeBJ0Qd_0b4cHA@mail.gmail.com>

Are we looking to include NFD in the official Fedora/CentOS repo or
just planning to host them on named-data.net?

On Wed, Jan 14, 2015 at 11:00 AM, Junxiao Shi
<shijunxiao at email.arizona.edu> wrote:
> Dear folks
>
> Does someone on this list know how to build RPM packages for Fedora or
> CentOS platform?
> We want to publish NFD binary packages for those platforms.
>
> If you know a thing or two about RPM packaging, or startup configuration
> (init daemon) on those platforms,
> please have a look at http://redmine.named-data.net/issues/1587 and post a
> note on that issue, or reply-all to this message.
>
> Yours, Junxiao
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>



-- 

Regards,
Susmit

====================================
http://www.cs.colostate.edu/~susmit
====================================


From alexander.afanasyev at ucla.edu  Tue Jan 13 21:52:51 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 14 Jan 2015 00:52:51 -0500
Subject: [Nfd-dev] RPM guru wanted
In-Reply-To: <CAM4XVkoTv6qh7kNdj8WSo5Y8LsMN-kFFT6-4SeBJ0Qd_0b4cHA@mail.gmail.com>
References: <CAOFH+Oae5_CLP-dPnD0guEMmyd=w98x0LDv+BOaeD=_2X-qokw@mail.gmail.com>
	<CAM4XVkoTv6qh7kNdj8WSo5Y8LsMN-kFFT6-4SeBJ0Qd_0b4cHA@mail.gmail.com>
Message-ID: <69606C67-8A55-4CDC-9BB6-D6C9BA66C6C5@ucla.edu>


> On Jan 14, 2015, at 12:44 AM, Susmit <susmit at cs.colostate.edu> wrote:
> 
> Are we looking to include NFD in the official Fedora/CentOS repo or
> just planning to host them on named-data.net?

In the ideal world, we would like to include the rpms in the official repo.  More realistically, we will just host them somewhere on named-data.net (or some other public rpm hosting service, like launchpad for Ubuntu's .deb).

---
Alex

> On Wed, Jan 14, 2015 at 11:00 AM, Junxiao Shi
> <shijunxiao at email.arizona.edu> wrote:
>> Dear folks
>> 
>> Does someone on this list know how to build RPM packages for Fedora or
>> CentOS platform?
>> We want to publish NFD binary packages for those platforms.
>> 
>> If you know a thing or two about RPM packaging, or startup configuration
>> (init daemon) on those platforms,
>> please have a look at http://redmine.named-data.net/issues/1587 and post a
>> note on that issue, or reply-all to this message.
>> 
>> Yours, Junxiao
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
> 
> 
> 
> -- 
> 
> Regards,
> Susmit
> 
> ====================================
> http://www.cs.colostate.edu/~susmit
> ====================================
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From susmit at cs.colostate.edu  Tue Jan 13 22:07:22 2015
From: susmit at cs.colostate.edu (Susmit)
Date: Wed, 14 Jan 2015 11:37:22 +0530
Subject: [Nfd-dev] RPM guru wanted
In-Reply-To: <69606C67-8A55-4CDC-9BB6-D6C9BA66C6C5@ucla.edu>
References: <CAOFH+Oae5_CLP-dPnD0guEMmyd=w98x0LDv+BOaeD=_2X-qokw@mail.gmail.com>
	<CAM4XVkoTv6qh7kNdj8WSo5Y8LsMN-kFFT6-4SeBJ0Qd_0b4cHA@mail.gmail.com>
	<69606C67-8A55-4CDC-9BB6-D6C9BA66C6C5@ucla.edu>
Message-ID: <CAM4XVkpctp53kGKeVbJfgZHtUBs=_ydhpHRXiBui8z804quAxg@mail.gmail.com>

Submitting it to official repo is definitely a better idea. The RPM
will go through the review process and we will have access to the
Fedora
build systems. At the same time, it might take a while to get
approved. We can host it on named-data.net in the meantime.

I will work on creating a RPM next week.


On Wed, Jan 14, 2015 at 11:22 AM, Alex Afanasyev
<alexander.afanasyev at ucla.edu> wrote:
>
>> On Jan 14, 2015, at 12:44 AM, Susmit <susmit at cs.colostate.edu> wrote:
>>
>> Are we looking to include NFD in the official Fedora/CentOS repo or
>> just planning to host them on named-data.net?
>
> In the ideal world, we would like to include the rpms in the official repo.  More realistically, we will just host them somewhere on named-data.net (or some other public rpm hosting service, like launchpad for Ubuntu's .deb).
>
> ---
> Alex
>
>> On Wed, Jan 14, 2015 at 11:00 AM, Junxiao Shi
>> <shijunxiao at email.arizona.edu> wrote:
>>> Dear folks
>>>
>>> Does someone on this list know how to build RPM packages for Fedora or
>>> CentOS platform?
>>> We want to publish NFD binary packages for those platforms.
>>>
>>> If you know a thing or two about RPM packaging, or startup configuration
>>> (init daemon) on those platforms,
>>> please have a look at http://redmine.named-data.net/issues/1587 and post a
>>> note on that issue, or reply-all to this message.
>>>
>>> Yours, Junxiao
>>>
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>
>>
>>
>>
>> --
>>
>> Regards,
>> Susmit
>>
>> ====================================
>> http://www.cs.colostate.edu/~susmit
>> ====================================
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>



-- 

Regards,
Susmit

====================================
http://www.cs.colostate.edu/~susmit
====================================


From shijunxiao at email.ARIZONA.EDU  Fri Jan 16 08:26:47 2015
From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi)
Date: Fri, 16 Jan 2015 09:26:47 -0700
Subject: [Nfd-dev] IDE for working with NFD code base
Message-ID: <CAOFH+OZ6kRmU4KMqGCRDL+Fz9+HW7pUAF8usyZkmKzjWSQ1LOA@mail.gmail.com>

Dear folks

There's no official IDE for NFD code base.
I personally use pluma on LinuxMint, or gedit on Ubuntu.

Code style is documented at
http://redmine.named-data.net/projects/nfd/wiki/CodeStyle
If you are using an IDE, configure it to conform to this code style.
"My IDE automatically changes code into XYZ style" is not an excuse of not
conforming to code style.

Yours, Junxiao

On Fri, Jan 16, 2015 at 4:34 AM, Ivan Yeo <ivanyeo at cs.ucla.edu> wrote:

> Also, I wanted to check with you: When you guys work with the NFD code
> base, do you use an IDE like Xcode? Or do you do straight from Emacs?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150116/4967804d/attachment.html>

From davide.pesavento at lip6.fr  Fri Jan 16 09:27:21 2015
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Fri, 16 Jan 2015 18:27:21 +0100
Subject: [Nfd-dev] IDE for working with NFD code base
In-Reply-To: <CAOFH+OZ6kRmU4KMqGCRDL+Fz9+HW7pUAF8usyZkmKzjWSQ1LOA@mail.gmail.com>
References: <CAOFH+OZ6kRmU4KMqGCRDL+Fz9+HW7pUAF8usyZkmKzjWSQ1LOA@mail.gmail.com>
Message-ID: <CADfzvvZMcqdEGLn9p4Unyn=3WOSf+5TxvGjm=50ZJbeP0524kw@mail.gmail.com>

I use Qt Creator on Linux
(http://qt-project.org/wiki/Category:Tools::QtCreator).

Although centered around Qt development, it works perfectly fine on
plain C++ projects (as a matter of fact there's a project template for
non-Qt applications), and it's very fast and lightweight.

I suggest using a recent version, for improved C++11 support. Ubuntu
packages are somewhat outdated though... fortunately upstream provides
binaries for all three major desktop platforms:
http://www.qt.io/download-open-source/#section-6

Best,
Davide

On Fri, Jan 16, 2015 at 5:26 PM, Junxiao Shi
<shijunxiao at email.arizona.edu> wrote:
> Dear folks
>
> There's no official IDE for NFD code base.
> I personally use pluma on LinuxMint, or gedit on Ubuntu.
>
> Code style is documented at
> http://redmine.named-data.net/projects/nfd/wiki/CodeStyle
> If you are using an IDE, configure it to conform to this code style.
> "My IDE automatically changes code into XYZ style" is not an excuse of not
> conforming to code style.
>
> Yours, Junxiao
>
> On Fri, Jan 16, 2015 at 4:34 AM, Ivan Yeo <ivanyeo at cs.ucla.edu> wrote:
>>
>> Also, I wanted to check with you: When you guys work with the NFD code
>> base, do you use an IDE like Xcode? Or do you do straight from Emacs?
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>


From alexander.afanasyev at ucla.edu  Sat Jan 17 11:37:59 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Sat, 17 Jan 2015 11:37:59 -0800
Subject: [Nfd-dev] IDE for working with NFD code base
In-Reply-To: <CADfzvvZMcqdEGLn9p4Unyn=3WOSf+5TxvGjm=50ZJbeP0524kw@mail.gmail.com>
References: <CAOFH+OZ6kRmU4KMqGCRDL+Fz9+HW7pUAF8usyZkmKzjWSQ1LOA@mail.gmail.com>
	<CADfzvvZMcqdEGLn9p4Unyn=3WOSf+5TxvGjm=50ZJbeP0524kw@mail.gmail.com>
Message-ID: <218086B7-1266-4DED-AF71-09C1C3D11F96@ucla.edu>

I'm using Emacs (aquamacs).  Though I would not disagree with the statement that it may take a while to get used to it.

---
Alex

> On Jan 16, 2015, at 9:27 AM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:
> 
> I use Qt Creator on Linux
> (http://qt-project.org/wiki/Category:Tools::QtCreator).
> 
> Although centered around Qt development, it works perfectly fine on
> plain C++ projects (as a matter of fact there's a project template for
> non-Qt applications), and it's very fast and lightweight.
> 
> I suggest using a recent version, for improved C++11 support. Ubuntu
> packages are somewhat outdated though... fortunately upstream provides
> binaries for all three major desktop platforms:
> http://www.qt.io/download-open-source/#section-6
> 
> Best,
> Davide
> 
> On Fri, Jan 16, 2015 at 5:26 PM, Junxiao Shi
> <shijunxiao at email.arizona.edu> wrote:
>> Dear folks
>> 
>> There's no official IDE for NFD code base.
>> I personally use pluma on LinuxMint, or gedit on Ubuntu.
>> 
>> Code style is documented at
>> http://redmine.named-data.net/projects/nfd/wiki/CodeStyle
>> If you are using an IDE, configure it to conform to this code style.
>> "My IDE automatically changes code into XYZ style" is not an excuse of not
>> conforming to code style.
>> 
>> Yours, Junxiao
>> 
>> On Fri, Jan 16, 2015 at 4:34 AM, Ivan Yeo <ivanyeo at cs.ucla.edu> wrote:
>>> 
>>> Also, I wanted to check with you: When you guys work with the NFD code
>>> base, do you use an IDE like Xcode? Or do you do straight from Emacs?
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150117/7b28d7bc/attachment.bin>

From ivanyeo at CS.UCLA.EDU  Sat Jan 17 20:14:07 2015
From: ivanyeo at CS.UCLA.EDU (Ivan Yeo)
Date: Sat, 17 Jan 2015 20:14:07 -0800
Subject: [Nfd-dev] IDE for working with NFD code base
In-Reply-To: <218086B7-1266-4DED-AF71-09C1C3D11F96@ucla.edu>
References: <CAOFH+OZ6kRmU4KMqGCRDL+Fz9+HW7pUAF8usyZkmKzjWSQ1LOA@mail.gmail.com>
	<CADfzvvZMcqdEGLn9p4Unyn=3WOSf+5TxvGjm=50ZJbeP0524kw@mail.gmail.com>
	<218086B7-1266-4DED-AF71-09C1C3D11F96@ucla.edu>
Message-ID: <DEC83193-5BD1-4852-9D5D-72ED1BCA41D6@cs.ucla.edu>

Hi all,

Thanks for the response, I really appreciate it. Have a great weekend!

Cheers,
Ivan

> On Jan 17, 2015, at 11:37 AM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
> 
> I'm using Emacs (aquamacs).  Though I would not disagree with the statement that it may take a while to get used to it.
> 
> ---
> Alex
> 
>> On Jan 16, 2015, at 9:27 AM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:
>> 
>> I use Qt Creator on Linux
>> (http://qt-project.org/wiki/Category:Tools::QtCreator).
>> 
>> Although centered around Qt development, it works perfectly fine on
>> plain C++ projects (as a matter of fact there's a project template for
>> non-Qt applications), and it's very fast and lightweight.
>> 
>> I suggest using a recent version, for improved C++11 support. Ubuntu
>> packages are somewhat outdated though... fortunately upstream provides
>> binaries for all three major desktop platforms:
>> http://www.qt.io/download-open-source/#section-6
>> 
>> Best,
>> Davide
>> 
>> On Fri, Jan 16, 2015 at 5:26 PM, Junxiao Shi
>> <shijunxiao at email.arizona.edu> wrote:
>>> Dear folks
>>> 
>>> There's no official IDE for NFD code base.
>>> I personally use pluma on LinuxMint, or gedit on Ubuntu.
>>> 
>>> Code style is documented at
>>> http://redmine.named-data.net/projects/nfd/wiki/CodeStyle
>>> If you are using an IDE, configure it to conform to this code style.
>>> "My IDE automatically changes code into XYZ style" is not an excuse of not
>>> conforming to code style.
>>> 
>>> Yours, Junxiao
>>> 
>>> On Fri, Jan 16, 2015 at 4:34 AM, Ivan Yeo <ivanyeo at cs.ucla.edu> wrote:
>>>> 
>>>> Also, I wanted to check with you: When you guys work with the NFD code
>>>> base, do you use an IDE like Xcode? Or do you do straight from Emacs?
>>> 
>>> 
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From shijunxiao at email.arizona.edu  Mon Jan 19 04:36:03 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 19 Jan 2015 05:36:03 -0700
Subject: [Nfd-dev] review request: DummyClientFace::onInterest|Data removal
Message-ID: <CAOFH+OaMajHnsCCYjYmUWRRK6nFdoSVgm8acoa0eEweOE6VfRQ@mail.gmail.com>

Dear folks

I have removed DummyClientFace:xonInterest|dData and I need someone to
review the code:

http://gerrit.named-data.net/1592

If you are willing to have a look at the patch, I'll appreciate that.
You don't have to be an expert in order to do a code review.

Yours, Junxiao
On Jan 6, 2015 9:35 AM, "Junxiao Shi" <shijunxiao at email.arizona.edu> wrote:

> Dear folks
>
> The following deprecated feature will be removed from ndn-cxx soon:
> DummyClientFace::onInterest => use onSendInterest
> DummyClientFace::onData => use onSendData
>
> If you have code that depend on this feature and cannot be fixed now,
> please reply no later than Jan 13 12:00 UTC.
> Otherwise, we'll proceed with the removal after that time.
>
> You can compile your projects with ndn-cxx Change
> http://gerrit.named-data.net/1592 and verify it works.
>
> Yours, Junxiao
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/4f2a36cc/attachment.html>

From shijunxiao at email.arizona.edu  Mon Jan 19 04:55:27 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 19 Jan 2015 05:55:27 -0700
Subject: [Nfd-dev] Copyright holder section of license boilerplate
In-Reply-To: <CAOFH+OZoD087q4kLp4RJvvbb8DN2h_pJLOSUARx2_Z5p0fV-qg@mail.gmail.com>
References: <CAOFH+OaW_KdQa75-oUiK7TcoK-Bx=S6ovfHH0UPpj9Epz7vQgg@mail.gmail.com>
	<CAOFH+OZhMEFW62x_E=6i+m=pcsKjUUSQfhaEEp3EtJ4q-DXmNQ@mail.gmail.com>
	<CAOFH+ObnWSQNuF7qcSxhcaMmDy=OgxeGxi+Gm-EzmfGVCH7J4g@mail.gmail.com>
	<CAOFH+Obxm55ceZ4QjJYCDVSqSB-1WJ-zFZc5CeFpJmiR1Wgbzw@mail.gmail.com>
	<CAOFH+OZoD087q4kLp4RJvvbb8DN2h_pJLOSUARx2_Z5p0fV-qg@mail.gmail.com>
Message-ID: <CAOFH+OZF41jKpmVk4YLQBCtahOf84=v22cKhBEr4dwe0NGPnmA@mail.gmail.com>

Dear folks

Linux kernel, one of the oldest open source projects, has different
"copyright holders" in the repository. Therefore, I realize that enforcing
the same set of copyright holders is unnecessary.

The main dispute in 2352 review is: whether a complete example boilerplate
with seven institution listed as copyright holder can be included in
README-dev.md, or be placed on wiki AND linked from README-dev.md.
Alex's opinion is no, because only "NDN team" is required to use this set
of copyright holders, but he cannot define "NDN team".
My opinion is yes, because developers are able to copy and paste the
complete license boilerplate, and the snippet is easily found.

My suggestion is to include the following text in README-dev.md:

    If you are affiliated to an NSF-supported NDN project institution, you
must use the license boilerplate found on <wiki link>.

Yours, Junxiao
On Jan 7, 2015 11:15 PM, "Junxiao Shi" <shijunxiao at email.arizona.edu> wrote:

> Dear folks
>
> During the review of NFD Task 2352, a question was raised about copyright
> holder in license boilerplates.
>
> My opinion is that every file must carry the same license boilerplate,
> regardless of contributor. The benefit is that the whole NFD repository is
> owned by a single set of copyright holders (the seven institutions), so
> that relicensing is easy.
>
> Alex's opinion is that one people from "NDN team" (which itself is an
> undefined concept) needs to use a standard license boilerplate of seven
> institutions as copyright holders, while other contributors can declare
> different copyright holders without assigning copyright to the seven
> institutions, but still get code merged into NFD repository. I think this
> approach would cause difficulty in relicensing NFD code.
>
> A policy decision on this problem is needed before #2352 can continue.
>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/e2aa2216/attachment.html>

From shijunxiao at email.arizona.edu  Mon Jan 19 04:56:36 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 19 Jan 2015 05:56:36 -0700
Subject: [Nfd-dev] ndncat/putchunks: ndn-cxx or NFD tools?
In-Reply-To: <CAOFH+OZvrkLzbF9PacAg6eVdGyWAxueNOD457YYz9jn0NDSLqA@mail.gmail.com>
References: <CAG95NwtzZYyL+7YevfqB-UzAfbL1a+zOQXyyrG0H4x-L5ODZNw@mail.gmail.com>
	<CAOFH+OZvrkLzbF9PacAg6eVdGyWAxueNOD457YYz9jn0NDSLqA@mail.gmail.com>
Message-ID: <CAOFH+OYM52YRjomEsYcw7Q97uvY6JAu8SsKwRzQ-Eq-B8gD-Kw@mail.gmail.com>

Dear folks

Any other opinion on this?

Yours, Junxiao
On Jan 5, 2015 3:26 PM, "Junxiao Shi" <shijunxiao at email.arizona.edu> wrote:

> Hi Steve
>
> I'll begin with the third question.
>
> My observation and opinion is: a tool shall be bundled with ndn-cxx if it
> can be used without installing NFD.
> The two tools bundled with ndn-cxx are:
>
>    - ndnsec: controls the KeyChain
>    - tlvdump: parses the packet format
>
> They both don't require NFD.
>
>
> I recognize that there are certain tools which are not closely related to
> NFD, but are useful in most places where NFD is installed.
> They include:
>
>    - peek and poke
>    - catchunks and putchunks
>    - ping and pingserver
>
> I suggest creating a separate "ndn-tools" repository which contains all
> these tools.
> Operator still installs from three repositories, ndn-cxx, NFD, ndn-tools
> (formerly ndn-tlv-ping), so this change doesn't increase the difficulty of
> deployment.
>
> Yours, Junxiao
>
> On Sun, Jan 4, 2015 at 4:22 PM, Steve DiBenedetto <
> dibenede at cs.colostate.edu> wrote:
>
>> Hi,
>>
>> There is an ongoing tools discussion related to issue #2106:
>>
>> http://redmine.named-data.net/issues/2106
>> http://gerrit.named-data.net/#/c/1581/
>>
>> The existing ndn-cxx/tools ndncat/putchunks3 are being reworked. The
>> final programs are slated to live under ndn-cxx/examples and the original
>> ndn-cxx/tools versions will be deleted.
>>
>> However, there is an open question over whether or not the new programs
>> are also useful as tools. If they are, then we need to decide whether they
>> should live under NFD/tools or ndn-cxx/tools. There is also a maintenance
>> concern over having the same code in both ndn-cxx/examples and in one of
>> the tools directories.
>>
>> Questions:
>> 1. Are ndncat/putchunks useful tools? (now with latest version discovery
>> and in order output)
>> 2. If so, where should they live?
>> 3. What determines whether something is an NFD or ndn-cxx tool?
>>
>> Thanks,
>> Steve
>>
>>
>>
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/01a4bf46/attachment.html>

From chaim.rieger at gmail.com  Mon Jan 19 12:47:55 2015
From: chaim.rieger at gmail.com (Chaim Rieger)
Date: Mon, 19 Jan 2015 12:47:55 -0800
Subject: [Nfd-dev] NFD updated in ubuntu packages ?
Message-ID: <54BD6D7B.2090807@gmail.com>

NFD was updated recently in the ubuntu repo. I just installed the update
and now NFD will not keep running.
*Jan 19 12:37:55 crieger-Precision-WorkStation-T5500 kernel:
[237564.227273] init: nfd main process (4915) terminated with status 2
Jan 19 12:37:55 crieger-Precision-WorkStation-T5500 kernel:
[237564.227286] init: nfd main process ended, respawning

crieger at crieger-Precision-WorkStation-T5500:/var/log$ nfd-status
ERROR: error while connecting to the forwarder (No such file or directory)


Was running just fine just before the update. Anybody else notice an
issue when updating via packages on Ubuntu 14.04 ?



*


From shijunxiao at email.arizona.edu  Mon Jan 19 12:51:58 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 19 Jan 2015 13:51:58 -0700
Subject: [Nfd-dev] NFD updated in ubuntu packages ?
In-Reply-To: <54BD6D7B.2090807@gmail.com>
References: <54BD6D7B.2090807@gmail.com>
Message-ID: <54bd6e6d.e429460a.0dd3.336d@mx.google.com>

Hi Chaim

Is this caused by a bad configuration file?
Please look at the diff between sample configuration and your active configuration, to find out whether the configuration contains an option that has been deprecated and removed.

Also look at NFD's log (not syslog) to see why NFD would crash.

Yours, Junxiao

-----Original Message-----
From: "Chaim Rieger" <chaim.rieger at gmail.com>
Sent: ?1/?19/?2015 13:48
To: "nfd-dev at lists.cs.ucla.edu" <nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] NFD updated in ubuntu packages ?

NFD was updated recently in the ubuntu repo. I just installed the update
and now NFD will not keep running.
*Jan 19 12:37:55 crieger-Precision-WorkStation-T5500 kernel:
[237564.227273] init: nfd main process (4915) terminated with status 2
Jan 19 12:37:55 crieger-Precision-WorkStation-T5500 kernel:
[237564.227286] init: nfd main process ended, respawning

crieger at crieger-Precision-WorkStation-T5500:/var/log$ nfd-status
ERROR: error while connecting to the forwarder (No such file or directory)


Was running just fine just before the update. Anybody else notice an
issue when updating via packages on Ubuntu 14.04 ?



*
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/52b6497c/attachment.html>

From alexander.afanasyev at ucla.edu  Mon Jan 19 13:00:47 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 19 Jan 2015 13:00:47 -0800
Subject: [Nfd-dev] NFD updated in ubuntu packages ?
In-Reply-To: <54bd6e6d.e429460a.0dd3.336d@mx.google.com>
References: <54BD6D7B.2090807@gmail.com>
	<54bd6e6d.e429460a.0dd3.336d@mx.google.com>
Message-ID: <89E70E84-5034-4A16-8239-6C4800B2FB6F@ucla.edu>

Hi Chaim,

If you did an update, then this most likely caused by configuration file update (update process does not alter the existing configuration files if they have been modified).  I suspect that if you remove ?face.unix.listen yes?  option, nfd will be happy to start again.

You can always check /var/log/upstart/nfd.log (and other /var/log/upstart/nfd*.log  files) to see more detailed error on what exactly is going wrong.

?
Alex

> On Jan 19, 2015, at 12:51 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Chaim
> 
> Is this caused by a bad configuration file?
> Please look at the diff between sample configuration and your active configuration, to find out whether the configuration contains an option that has been deprecated and removed.
> 
> Also look at NFD's log (not syslog) to see why NFD would crash.
> 
> Yours, Junxiao
> From: Chaim Rieger <mailto:chaim.rieger at gmail.com>
> Sent: ?1/?19/?2015 13:48
> To: nfd-dev at lists.cs.ucla.edu <mailto:nfd-dev at lists.cs.ucla.edu>
> Subject: [Nfd-dev] NFD updated in ubuntu packages ?
> 
> NFD was updated recently in the ubuntu repo. I just installed the update
> and now NFD will not keep running.
> *Jan 19 12:37:55 crieger-Precision-WorkStation-T5500 kernel:
> [237564.227273] init: nfd main process (4915) terminated with status 2
> Jan 19 12:37:55 crieger-Precision-WorkStation-T5500 kernel:
> [237564.227286] init: nfd main process ended, respawning
> 
> crieger at crieger-Precision-WorkStation-T5500:/var/log$ nfd-status
> ERROR: error while connecting to the forwarder (No such file or directory)
> 
> 
> Was running just fine just before the update. Anybody else notice an
> issue when updating via packages on Ubuntu 14.04 ?
> 
> 
> 
> *
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/f024d07e/attachment.html>
-------------- 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/f024d07e/attachment.bin>

From shijunxiao at email.ARIZONA.EDU  Mon Jan 19 17:57:21 2015
From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi)
Date: Mon, 19 Jan 2015 18:57:21 -0700
Subject: [Nfd-dev] Fwd: Running NFD without sudo
In-Reply-To: <1843884717.32171397.1421711380096.JavaMail.root@cs.ucla.edu>
References: <1147353308.32171183.1421710938327.JavaMail.root@cs.ucla.edu>
	<1843884717.32171397.1421711380096.JavaMail.root@cs.ucla.edu>
Message-ID: <CAOFH+Oa7_KkP1NrSMNLqbKJEh9faLEgCfLZRokECt2jiJsM9xg@mail.gmail.com>

---------- Forwarded message ----------
From: Ivan Yeo <ivanyeo at cs.ucla.edu>
Date: Mon, Jan 19, 2015 at 4:49 PM
Subject: Running NFD without sudo
To: Junxiao Shi <shijunxiao at email.arizona.edu>


Hi Junxiao,

I have managed to get NFD to run on Mac OS 10.10 Yosemite by changing the
following settings in /usr/local/etc/ndn/nfd.conf:

face_system
{
  ; The unix section contains settings of UNIX stream faces and channels.
  unix
  {
    listen no; set to 'no' to disable UNIX stream listener, default 'yes'
    path /var/run/nfd.sock ; UNIX stream listener path
  }

  udp
  {
    mcast no; set to 'no' to disable UDP multicast, default 'yes'
    mcast_port 56363 ; UDP multicast port number
    mcast_group 224.0.23.170 ; UDP multicast group (IPv4 only)
  }
}

However, right now, NRD cannot seem to be able to connect to the running
NFD. I'm wondering if happened to turn off something that is required by
the NRD. I'm still diving deeper to understand how the NRD is connecting to
the NFD by looking into the code base. I was wondering if you happen to
know where I should start looking to expedite the process?

Thanks!

Cheers,
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/ed81d90b/attachment.html>

From dibenede at cs.colostate.edu  Mon Jan 19 18:02:14 2015
From: dibenede at cs.colostate.edu (Steve DiBenedetto)
Date: Mon, 19 Jan 2015 19:02:14 -0700
Subject: [Nfd-dev] Running NFD without sudo
In-Reply-To: <CAOFH+Oa7_KkP1NrSMNLqbKJEh9faLEgCfLZRokECt2jiJsM9xg@mail.gmail.com>
References: <1147353308.32171183.1421710938327.JavaMail.root@cs.ucla.edu>
	<1843884717.32171397.1421711380096.JavaMail.root@cs.ucla.edu>
	<CAOFH+Oa7_KkP1NrSMNLqbKJEh9faLEgCfLZRokECt2jiJsM9xg@mail.gmail.com>
Message-ID: <CAG95Nwt7mQL5hPUyDduxYSLRGY_GAxC-KF=X-fhaTCHarN3Aog@mail.gmail.com>

What's your client.conf look like? Also, does your current configuration
work if you use sudo?

On Mon, Jan 19, 2015 at 6:57 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

>
> ---------- Forwarded message ----------
> From: Ivan Yeo <ivanyeo at cs.ucla.edu>
> Date: Mon, Jan 19, 2015 at 4:49 PM
> Subject: Running NFD without sudo
> To: Junxiao Shi <shijunxiao at email.arizona.edu>
>
>
> Hi Junxiao,
>
> I have managed to get NFD to run on Mac OS 10.10 Yosemite by changing the
> following settings in /usr/local/etc/ndn/nfd.conf:
>
> face_system
> {
>   ; The unix section contains settings of UNIX stream faces and channels.
>   unix
>   {
>     listen no; set to 'no' to disable UNIX stream listener, default 'yes'
>     path /var/run/nfd.sock ; UNIX stream listener path
>   }
>
>   udp
>   {
>     mcast no; set to 'no' to disable UDP multicast, default 'yes'
>     mcast_port 56363 ; UDP multicast port number
>     mcast_group 224.0.23.170 ; UDP multicast group (IPv4 only)
>   }
> }
>
> However, right now, NRD cannot seem to be able to connect to the running
> NFD. I'm wondering if happened to turn off something that is required by
> the NRD. I'm still diving deeper to understand how the NRD is connecting to
> the NFD by looking into the code base. I was wondering if you happen to
> know where I should start looking to expedite the process?
>
> Thanks!
>
> Cheers,
> Ivan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/8f063f8b/attachment.html>

From shijunxiao at email.ARIZONA.EDU  Mon Jan 19 18:55:30 2015
From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi)
Date: Mon, 19 Jan 2015 19:55:30 -0700
Subject: [Nfd-dev] semantics of Transport::pause
Message-ID: <CAOFH+OaWZmp0_XJW9tQp3y-Lmu+oxq6z_b5J423kuXdJynYp3g@mail.gmail.com>

Dear folks

I'm trying to add UdpTransport into ndn-cxx to use in an experiment.
I notice that Transport class has pause and resume methods, but there's no
documentation.
What's the semantics of Transport::pause and Transport::resume methods?

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/483d5cf5/attachment.html>

From afanasev at CS.UCLA.EDU  Mon Jan 19 19:20:04 2015
From: afanasev at CS.UCLA.EDU (Alex Afanasyev)
Date: Mon, 19 Jan 2015 19:20:04 -0800
Subject: [Nfd-dev] semantics of Transport::pause
In-Reply-To: <CAOFH+OaWZmp0_XJW9tQp3y-Lmu+oxq6z_b5J423kuXdJynYp3g@mail.gmail.com>
References: <CAOFH+OaWZmp0_XJW9tQp3y-Lmu+oxq6z_b5J423kuXdJynYp3g@mail.gmail.com>
Message-ID: <EAB55F78-BD16-4D5E-8E33-ED57C7A4CB63@cs.ucla.edu>

These are internal implementation details.  The reason to have those calls is to enable use the following use case:

- <send interest>
- call io::run()  (face::processEvents)

as soon as data is retrieved, io::run unblocks.

What pause() does is cancels any pending async_read operations if it is known that no new data is expected to be received (no interest filter defined and all interests are satisfied).  When there are no more jobs left in io_service, io::run() unblocks.

Explicitly stopping io_service is additional and unnecessary burden on applications.

?
Alex

> On Jan 19, 2015, at 6:55 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Dear folks
> 
> I'm trying to add UdpTransport into ndn-cxx to use in an experiment.
> I notice that Transport class has pause and resume methods, but there's no documentation.
> What's the semantics of Transport::pause and Transport::resume methods?
> 
> Yours, Junxiao




From shijunxiao at email.ARIZONA.EDU  Mon Jan 19 19:45:07 2015
From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi)
Date: Mon, 19 Jan 2015 20:45:07 -0700
Subject: [Nfd-dev] semantics of Transport::pause
In-Reply-To: <EAB55F78-BD16-4D5E-8E33-ED57C7A4CB63@cs.ucla.edu>
References: <CAOFH+OaWZmp0_XJW9tQp3y-Lmu+oxq6z_b5J423kuXdJynYp3g@mail.gmail.com>
	<EAB55F78-BD16-4D5E-8E33-ED57C7A4CB63@cs.ucla.edu>
Message-ID: <CAOFH+OZ+r-LsCSocQXP43eRk9DZ0LvogbA=-S0ANWdjJhcJSzg@mail.gmail.com>

Hi Alex

If one is to implement a new Transport subclass, such as UdpTransport, or
even SSH tunnel transport, what is expected to appear in pause() and
resume()?

Yours, Junxiao

On Mon, Jan 19, 2015 at 8:20 PM, Alex Afanasyev <afanasev at cs.ucla.edu>
wrote:

> These are internal implementation details.  The reason to have those calls
> is to enable use the following use case:
>
> - <send interest>
> - call io::run()  (face::processEvents)
>
> as soon as data is retrieved, io::run unblocks.
>
> What pause() does is cancels any pending async_read operations if it is
> known that no new data is expected to be received (no interest filter
> defined and all interests are satisfied).  When there are no more jobs left
> in io_service, io::run() unblocks.
>
> Explicitly stopping io_service is additional and unnecessary burden on
> applications.
>
> ?
> Alex
>
> > On Jan 19, 2015, at 6:55 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
> >
> > Dear folks
> >
> > I'm trying to add UdpTransport into ndn-cxx to use in an experiment.
> > I notice that Transport class has pause and resume methods, but there's
> no documentation.
> > What's the semantics of Transport::pause and Transport::resume methods?
> >
> > Yours, Junxiao
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/0da67c8a/attachment.html>

From afanasev at CS.UCLA.EDU  Mon Jan 19 19:48:02 2015
From: afanasev at CS.UCLA.EDU (Alex Afanasyev)
Date: Mon, 19 Jan 2015 19:48:02 -0800
Subject: [Nfd-dev] semantics of Transport::pause
In-Reply-To: <CAOFH+OZ+r-LsCSocQXP43eRk9DZ0LvogbA=-S0ANWdjJhcJSzg@mail.gmail.com>
References: <CAOFH+OaWZmp0_XJW9tQp3y-Lmu+oxq6z_b5J423kuXdJynYp3g@mail.gmail.com>
	<EAB55F78-BD16-4D5E-8E33-ED57C7A4CB63@cs.ucla.edu>
	<CAOFH+OZ+r-LsCSocQXP43eRk9DZ0LvogbA=-S0ANWdjJhcJSzg@mail.gmail.com>
Message-ID: <BDB2B3F0-175D-4D7B-AC89-8864B8EFC910@cs.ucla.edu>

On pause, all pending io_service tasks (e.g., for asynchronous waiting for incoming data) need to be cancelled (but socket should be kept in open state)

On resume, new tasks need to get created to wait for new input.

?
Alex

> On Jan 19, 2015, at 7:45 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Alex
> 
> If one is to implement a new Transport subclass, such as UdpTransport, or even SSH tunnel transport, what is expected to appear in pause() and resume()?
> 
> Yours, Junxiao
> 
> On Mon, Jan 19, 2015 at 8:20 PM, Alex Afanasyev <afanasev at cs.ucla.edu <mailto:afanasev at cs.ucla.edu>> wrote:
> These are internal implementation details.  The reason to have those calls is to enable use the following use case:
> 
> - <send interest>
> - call io::run()  (face::processEvents)
> 
> as soon as data is retrieved, io::run unblocks.
> 
> What pause() does is cancels any pending async_read operations if it is known that no new data is expected to be received (no interest filter defined and all interests are satisfied).  When there are no more jobs left in io_service, io::run() unblocks.
> 
> Explicitly stopping io_service is additional and unnecessary burden on applications.
> 
> ?
> Alex
> 
> > On Jan 19, 2015, at 6:55 PM, Junxiao Shi <shijunxiao at email.arizona.edu <mailto:shijunxiao at email.arizona.edu>> wrote:
> >
> > Dear folks
> >
> > I'm trying to add UdpTransport into ndn-cxx to use in an experiment.
> > I notice that Transport class has pause and resume methods, but there's no documentation.
> > What's the semantics of Transport::pause and Transport::resume methods?
> >
> > Yours, Junxiao
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/7f7a2acb/attachment.html>

From davide.pesavento at lip6.fr  Mon Jan 19 20:12:49 2015
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Tue, 20 Jan 2015 05:12:49 +0100
Subject: [Nfd-dev] semantics of Transport::pause
In-Reply-To: <BDB2B3F0-175D-4D7B-AC89-8864B8EFC910@cs.ucla.edu>
References: <CAOFH+OaWZmp0_XJW9tQp3y-Lmu+oxq6z_b5J423kuXdJynYp3g@mail.gmail.com>
	<EAB55F78-BD16-4D5E-8E33-ED57C7A4CB63@cs.ucla.edu>
	<CAOFH+OZ+r-LsCSocQXP43eRk9DZ0LvogbA=-S0ANWdjJhcJSzg@mail.gmail.com>
	<BDB2B3F0-175D-4D7B-AC89-8864B8EFC910@cs.ucla.edu>
Message-ID: <CADfzvva8ASUFZo3J+FFkeaa5kyFAoe+dkS7V78aeyDmOmkz78w@mail.gmail.com>

On Tue, Jan 20, 2015 at 4:48 AM, Alex Afanasyev <afanasev at cs.ucla.edu> wrote:
> On pause, all pending io_service tasks (e.g., for asynchronous waiting for
> incoming data) need to be cancelled (but socket should be kept in open
> state)

What if the underlying transport mechanism needs to send periodic
keep-alive packets in order to maintain the connection? (Or am I
misunderstanding what you mean by keeping the socket "in open state"?)

Thanks,
Davide


From shijunxiao at email.arizona.edu  Mon Jan 19 20:14:08 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 19 Jan 2015 21:14:08 -0700
Subject: [Nfd-dev] semantics of Transport::pause
In-Reply-To: <BDB2B3F0-175D-4D7B-AC89-8864B8EFC910@cs.ucla.edu>
References: <CAOFH+OaWZmp0_XJW9tQp3y-Lmu+oxq6z_b5J423kuXdJynYp3g@mail.gmail.com>
	<EAB55F78-BD16-4D5E-8E33-ED57C7A4CB63@cs.ucla.edu>
	<CAOFH+OZ+r-LsCSocQXP43eRk9DZ0LvogbA=-S0ANWdjJhcJSzg@mail.gmail.com>
	<BDB2B3F0-175D-4D7B-AC89-8864B8EFC910@cs.ucla.edu>
Message-ID: <CAOFH+Ob2wgyJr5iYUjoHyGXjJ1ROn948m58Vo2K+jw2OGJXuEQ@mail.gmail.com>

Thanks. This information is added to ndn-cxx Application Developer Guide,
section 5.2.1.

On Mon, Jan 19, 2015 at 8:48 PM, Alex Afanasyev <afanasev at cs.ucla.edu>
wrote:

> On pause, all pending io_service tasks (e.g., for asynchronous waiting for
> incoming data) need to be cancelled (but socket should be kept in open
> state)
>
> On resume, new tasks need to get created to wait for new input.
>
> ?
> Alex
>
> On Jan 19, 2015, at 7:45 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> Hi Alex
>
> If one is to implement a new Transport subclass, such as UdpTransport, or
> even SSH tunnel transport, what is expected to appear in pause() and
> resume()?
>
> Yours, Junxiao
>
> On Mon, Jan 19, 2015 at 8:20 PM, Alex Afanasyev <afanasev at cs.ucla.edu>
> wrote:
>
>> These are internal implementation details.  The reason to have those
>> calls is to enable use the following use case:
>>
>> - <send interest>
>> - call io::run()  (face::processEvents)
>>
>> as soon as data is retrieved, io::run unblocks.
>>
>> What pause() does is cancels any pending async_read operations if it is
>> known that no new data is expected to be received (no interest filter
>> defined and all interests are satisfied).  When there are no more jobs left
>> in io_service, io::run() unblocks.
>>
>> Explicitly stopping io_service is additional and unnecessary burden on
>> applications.
>>
>> ?
>> Alex
>>
>> > On Jan 19, 2015, at 6:55 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>> >
>> > Dear folks
>> >
>> > I'm trying to add UdpTransport into ndn-cxx to use in an experiment.
>> > I notice that Transport class has pause and resume methods, but there's
>> no documentation.
>> > What's the semantics of Transport::pause and Transport::resume methods?
>> >
>> > Yours, Junxiao
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/329c3c73/attachment.html>

From shijunxiao at email.arizona.edu  Mon Jan 19 20:15:29 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 19 Jan 2015 21:15:29 -0700
Subject: [Nfd-dev] semantics of Transport::pause
In-Reply-To: <CADfzvva8ASUFZo3J+FFkeaa5kyFAoe+dkS7V78aeyDmOmkz78w@mail.gmail.com>
References: <CAOFH+OaWZmp0_XJW9tQp3y-Lmu+oxq6z_b5J423kuXdJynYp3g@mail.gmail.com>
	<EAB55F78-BD16-4D5E-8E33-ED57C7A4CB63@cs.ucla.edu>
	<CAOFH+OZ+r-LsCSocQXP43eRk9DZ0LvogbA=-S0ANWdjJhcJSzg@mail.gmail.com>
	<BDB2B3F0-175D-4D7B-AC89-8864B8EFC910@cs.ucla.edu>
	<CADfzvva8ASUFZo3J+FFkeaa5kyFAoe+dkS7V78aeyDmOmkz78w@mail.gmail.com>
Message-ID: <CAOFH+OaUq44RGiE3hhhu75vFf_2str7s3t-BFYaopkJs=tzKrQ@mail.gmail.com>

Hi Davide

TcpTransport and UnixTransport never need to send periodic keep-alive.

Yours, Junxiao

On Mon, Jan 19, 2015 at 9:12 PM, Davide Pesavento <davide.pesavento at lip6.fr>
wrote:

> On Tue, Jan 20, 2015 at 4:48 AM, Alex Afanasyev <afanasev at cs.ucla.edu>
> wrote:
> > On pause, all pending io_service tasks (e.g., for asynchronous waiting
> for
> > incoming data) need to be cancelled (but socket should be kept in open
> > state)
>
> What if the underlying transport mechanism needs to send periodic
> keep-alive packets in order to maintain the connection? (Or am I
> misunderstanding what you mean by keeping the socket "in open state"?)
>
> Thanks,
> Davide
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/c9d4a49b/attachment.html>

From afanasev at CS.UCLA.EDU  Mon Jan 19 20:20:35 2015
From: afanasev at CS.UCLA.EDU (Alex Afanasyev)
Date: Mon, 19 Jan 2015 20:20:35 -0800
Subject: [Nfd-dev] semantics of Transport::pause
In-Reply-To: <CAOFH+OaUq44RGiE3hhhu75vFf_2str7s3t-BFYaopkJs=tzKrQ@mail.gmail.com>
References: <CAOFH+OaWZmp0_XJW9tQp3y-Lmu+oxq6z_b5J423kuXdJynYp3g@mail.gmail.com>
	<EAB55F78-BD16-4D5E-8E33-ED57C7A4CB63@cs.ucla.edu>
	<CAOFH+OZ+r-LsCSocQXP43eRk9DZ0LvogbA=-S0ANWdjJhcJSzg@mail.gmail.com>
	<BDB2B3F0-175D-4D7B-AC89-8864B8EFC910@cs.ucla.edu>
	<CADfzvva8ASUFZo3J+FFkeaa5kyFAoe+dkS7V78aeyDmOmkz78w@mail.gmail.com>
	<CAOFH+OaUq44RGiE3hhhu75vFf_2str7s3t-BFYaopkJs=tzKrQ@mail.gmail.com>
Message-ID: <F29E487A-3963-46DC-8FAC-716AE1A60743@cs.ucla.edu>

These are assumptions in the library, which were based on a single machine environment where one can keep a hard state.  If we were to support something beyond local machine, pause/resume can be null operations (though it would require applications to be aware of that).

?
Alex

> On Jan 19, 2015, at 8:15 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Davide
> 
> TcpTransport and UnixTransport never need to send periodic keep-alive.
> 
> Yours, Junxiao
> 
> On Mon, Jan 19, 2015 at 9:12 PM, Davide Pesavento <davide.pesavento at lip6.fr <mailto:davide.pesavento at lip6.fr>> wrote:
> On Tue, Jan 20, 2015 at 4:48 AM, Alex Afanasyev <afanasev at cs.ucla.edu <mailto:afanasev at cs.ucla.edu>> wrote:
> > On pause, all pending io_service tasks (e.g., for asynchronous waiting for
> > incoming data) need to be cancelled (but socket should be kept in open
> > state)
> 
> What if the underlying transport mechanism needs to send periodic
> keep-alive packets in order to maintain the connection? (Or am I
> misunderstanding what you mean by keeping the socket "in open state"?)
> 
> Thanks,
> Davide
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/fd344a56/attachment.html>

From davide.pesavento at lip6.fr  Mon Jan 19 20:20:31 2015
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Tue, 20 Jan 2015 05:20:31 +0100
Subject: [Nfd-dev] semantics of Transport::pause
In-Reply-To: <CAOFH+OaUq44RGiE3hhhu75vFf_2str7s3t-BFYaopkJs=tzKrQ@mail.gmail.com>
References: <CAOFH+OaWZmp0_XJW9tQp3y-Lmu+oxq6z_b5J423kuXdJynYp3g@mail.gmail.com>
	<EAB55F78-BD16-4D5E-8E33-ED57C7A4CB63@cs.ucla.edu>
	<CAOFH+OZ+r-LsCSocQXP43eRk9DZ0LvogbA=-S0ANWdjJhcJSzg@mail.gmail.com>
	<BDB2B3F0-175D-4D7B-AC89-8864B8EFC910@cs.ucla.edu>
	<CADfzvva8ASUFZo3J+FFkeaa5kyFAoe+dkS7V78aeyDmOmkz78w@mail.gmail.com>
	<CAOFH+OaUq44RGiE3hhhu75vFf_2str7s3t-BFYaopkJs=tzKrQ@mail.gmail.com>
Message-ID: <CADfzvvaDj898Fx=Xkj_b8uW5QN4TzwLzQ62e2nr4GjUY+uxRZA@mail.gmail.com>

I know, I was not referring to the existing transports, hence the "what if".

On Tue, Jan 20, 2015 at 5:15 AM, Junxiao Shi
<shijunxiao at email.arizona.edu> wrote:
> Hi Davide
>
> TcpTransport and UnixTransport never need to send periodic keep-alive.
>
> Yours, Junxiao
>
>
> On Mon, Jan 19, 2015 at 9:12 PM, Davide Pesavento <davide.pesavento at lip6.fr>
> wrote:
>>
>> On Tue, Jan 20, 2015 at 4:48 AM, Alex Afanasyev <afanasev at cs.ucla.edu>
>> wrote:
>> > On pause, all pending io_service tasks (e.g., for asynchronous waiting
>> > for
>> > incoming data) need to be cancelled (but socket should be kept in open
>> > state)
>>
>> What if the underlying transport mechanism needs to send periodic
>> keep-alive packets in order to maintain the connection? (Or am I
>> misunderstanding what you mean by keeping the socket "in open state"?)
>>
>> Thanks,
>> Davide
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>


From alexander.afanasyev at ucla.edu  Mon Jan 19 21:21:36 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 19 Jan 2015 21:21:36 -0800
Subject: [Nfd-dev] ndncat/putchunks: ndn-cxx or NFD tools?
In-Reply-To: <CAOFH+OZvrkLzbF9PacAg6eVdGyWAxueNOD457YYz9jn0NDSLqA@mail.gmail.com>
References: <CAG95NwtzZYyL+7YevfqB-UzAfbL1a+zOQXyyrG0H4x-L5ODZNw@mail.gmail.com>
	<CAOFH+OZvrkLzbF9PacAg6eVdGyWAxueNOD457YYz9jn0NDSLqA@mail.gmail.com>
Message-ID: <CE4FB681-0AF8-4995-8343-ACEBFE2AF0EE@ucla.edu>


> On Jan 5, 2015, at 2:26 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Steve
> 
> I'll begin with the third question.
> 
> My observation and opinion is: a tool shall be bundled with ndn-cxx if it can be used without installing NFD.
> The two tools bundled with ndn-cxx are:
> ndnsec: controls the KeyChain
> tlvdump: parses the packet format
> They both don't require NFD.
> 
> 
> I recognize that there are certain tools which are not closely related to NFD, but are useful in most places where NFD is installed.
> They include:
> peek and poke
> catchunks and putchunks
> ping and pingserver
> I suggest creating a separate "ndn-tools" repository which contains all these tools.
> Operator still installs from three repositories, ndn-cxx, NFD, ndn-tools (formerly ndn-tlv-ping), so this change doesn't increase the difficulty of deployment.

Having a separate `ndn-tools` repository seem to me to be a reasonable solution.  We just need to clearly describe on ndn-cxx and NFD pages that additional tools can/should be installed from a different repo.

?
Alex

> Yours, Junxiao
> 
> On Sun, Jan 4, 2015 at 4:22 PM, Steve DiBenedetto <dibenede at cs.colostate.edu <mailto:dibenede at cs.colostate.edu>> wrote:
> Hi,
> 
> There is an ongoing tools discussion related to issue #2106:
> 
> http://redmine.named-data.net/issues/2106 <http://redmine.named-data.net/issues/2106>
> http://gerrit.named-data.net/#/c/1581/ <http://gerrit.named-data.net/#/c/1581/>
> 
> The existing ndn-cxx/tools ndncat/putchunks3 are being reworked. The final programs are slated to live under ndn-cxx/examples and the original ndn-cxx/tools versions will be deleted.
> 
> However, there is an open question over whether or not the new programs are also useful as tools. If they are, then we need to decide whether they should live under NFD/tools or ndn-cxx/tools. There is also a maintenance concern over having the same code in both ndn-cxx/examples and in one of the tools directories.
> 
> Questions:
> 1. Are ndncat/putchunks useful tools? (now with latest version discovery and in order output)
> 2. If so, where should they live?
> 3. What determines whether something is an NFD or ndn-cxx tool?
> 
> Thanks,
> Steve
> 
> 
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/372bbf71/attachment.html>
-------------- 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/372bbf71/attachment.bin>

From ivanyeo at CS.UCLA.EDU  Mon Jan 19 21:29:40 2015
From: ivanyeo at CS.UCLA.EDU (Ivan Yeo)
Date: Mon, 19 Jan 2015 21:29:40 -0800 (PST)
Subject: [Nfd-dev] Running NFD without sudo
In-Reply-To: <CAG95Nwt7mQL5hPUyDduxYSLRGY_GAxC-KF=X-fhaTCHarN3Aog@mail.gmail.com>
Message-ID: <1423751823.32182347.1421731780878.JavaMail.root@cs.ucla.edu>

Hi Steve,

Thanks for pointing that out. I think I've connected the dots. I changed the 'unix_socket' in both nfd.conf and client.conf to point to a file in my home directory and I now I am able to run NFD & NRD without the need for sudo. As a simple test, I ran the producer and consumer example programs on the ndn-cxx examples and all is working now (with and without sudo).

Right now, I'm trying to eliminate all API calls or access that require super user privileges in hope that I can just pop the NFD binaries over to the Android and run it from within a user process container. I've gone through the settings of nfd.conf and turned off all settings that require super user privileges. Off the top of your head, are there other configurations or API calls that you know of that might need elevated privileges? 

Cheers,
Ivan



----- Original Message -----
From: "Steve DiBenedetto" <dibenede at cs.colostate.edu>
To: "Junxiao Shi" <shijunxiao at email.arizona.edu>
Cc: "<nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu>, "Ivan Yeo" <ivanyeo at cs.ucla.edu>, "Steve DiBenedetto" <dibenede at cs.colostate.edu>
Sent: Monday, January 19, 2015 6:02:14 PM
Subject: Re: Running NFD without sudo


What's your client.conf look like? Also, does your current configuration work if you use sudo? 


On Mon, Jan 19, 2015 at 6:57 PM, Junxiao Shi < shijunxiao at email.arizona.edu > wrote: 





---------- Forwarded message ---------- 
From: Ivan Yeo < ivanyeo at cs.ucla.edu > 
Date: Mon, Jan 19, 2015 at 4:49 PM 
Subject: Running NFD without sudo 
To: Junxiao Shi < shijunxiao at email.arizona.edu > 


Hi Junxiao, 

I have managed to get NFD to run on Mac OS 10.10 Yosemite by changing the following settings in /usr/local/etc/ndn/nfd.conf: 

face_system 
{ 
; The unix section contains settings of UNIX stream faces and channels. 
unix 
{ 
listen no; set to 'no' to disable UNIX stream listener, default 'yes' 
path /var/run/nfd.sock ; UNIX stream listener path 
} 

udp 
{ 
mcast no; set to 'no' to disable UDP multicast, default 'yes' 
mcast_port 56363 ; UDP multicast port number 
mcast_group 224.0.23.170 ; UDP multicast group (IPv4 only) 
} 
} 

However, right now, NRD cannot seem to be able to connect to the running NFD. I'm wondering if happened to turn off something that is required by the NRD. I'm still diving deeper to understand how the NRD is connecting to the NFD by looking into the code base. I was wondering if you happen to know where I should start looking to expedite the process? 

Thanks! 

Cheers, 
Ivan 



From alexander.afanasyev at ucla.edu  Mon Jan 19 21:50:28 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 19 Jan 2015 21:50:28 -0800
Subject: [Nfd-dev] Running NFD without sudo
In-Reply-To: <1423751823.32182347.1421731780878.JavaMail.root@cs.ucla.edu>
References: <1423751823.32182347.1421731780878.JavaMail.root@cs.ucla.edu>
Message-ID: <33129CD1-C244-454E-9A1C-136816BDAB0A@ucla.edu>

There are exactly 2 settings that require superuser privileges: 
- location of unix socket: this does not exist in Android environment and TCP socket must be used instead.  In the compiled code (nfd-android.tar.gz), both nfd.conf and client.conf are already configured (etc/ndn/client.conf).
- ethernet support: this is not supported on Android for now and the whole section needs to be removed from nfd.conf

---
Alex

> On Jan 19, 2015, at 9:29 PM, Ivan Yeo <ivanyeo at CS.UCLA.EDU> wrote:
> 
> Hi Steve,
> 
> Thanks for pointing that out. I think I've connected the dots. I changed the 'unix_socket' in both nfd.conf and client.conf to point to a file in my home directory and I now I am able to run NFD & NRD without the need for sudo. As a simple test, I ran the producer and consumer example programs on the ndn-cxx examples and all is working now (with and without sudo).
> 
> Right now, I'm trying to eliminate all API calls or access that require super user privileges in hope that I can just pop the NFD binaries over to the Android and run it from within a user process container. I've gone through the settings of nfd.conf and turned off all settings that require super user privileges. Off the top of your head, are there other configurations or API calls that you know of that might need elevated privileges? 
> 
> Cheers,
> Ivan
> 
> 
> 
> ----- Original Message -----
> From: "Steve DiBenedetto" <dibenede at cs.colostate.edu>
> To: "Junxiao Shi" <shijunxiao at email.arizona.edu>
> Cc: "<nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu>, "Ivan Yeo" <ivanyeo at cs.ucla.edu>, "Steve DiBenedetto" <dibenede at cs.colostate.edu>
> Sent: Monday, January 19, 2015 6:02:14 PM
> Subject: Re: Running NFD without sudo
> 
> 
> What's your client.conf look like? Also, does your current configuration work if you use sudo? 
> 
> 
> On Mon, Jan 19, 2015 at 6:57 PM, Junxiao Shi < shijunxiao at email.arizona.edu > wrote: 
> 
> 
> 
> 
> 
> ---------- Forwarded message ---------- 
> From: Ivan Yeo < ivanyeo at cs.ucla.edu > 
> Date: Mon, Jan 19, 2015 at 4:49 PM 
> Subject: Running NFD without sudo 
> To: Junxiao Shi < shijunxiao at email.arizona.edu > 
> 
> 
> Hi Junxiao, 
> 
> I have managed to get NFD to run on Mac OS 10.10 Yosemite by changing the following settings in /usr/local/etc/ndn/nfd.conf: 
> 
> face_system 
> { 
> ; The unix section contains settings of UNIX stream faces and channels. 
> unix 
> { 
> listen no; set to 'no' to disable UNIX stream listener, default 'yes' 
> path /var/run/nfd.sock ; UNIX stream listener path 
> } 
> 
> udp 
> { 
> mcast no; set to 'no' to disable UDP multicast, default 'yes' 
> mcast_port 56363 ; UDP multicast port number 
> mcast_group 224.0.23.170 ; UDP multicast group (IPv4 only) 
> } 
> } 
> 
> However, right now, NRD cannot seem to be able to connect to the running NFD. I'm wondering if happened to turn off something that is required by the NRD. I'm still diving deeper to understand how the NRD is connecting to the NFD by looking into the code base. I was wondering if you happen to know where I should start looking to expedite the process? 
> 
> Thanks! 
> 
> Cheers, 
> Ivan 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4166 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150119/bcd20e78/attachment.bin>

From ivanyeo at CS.UCLA.EDU  Tue Jan 20 05:06:58 2015
From: ivanyeo at CS.UCLA.EDU (Ivan Yeo)
Date: Tue, 20 Jan 2015 05:06:58 -0800
Subject: [Nfd-dev] Running NFD without sudo
In-Reply-To: <33129CD1-C244-454E-9A1C-136816BDAB0A@ucla.edu>
References: <1423751823.32182347.1421731780878.JavaMail.root@cs.ucla.edu>
	<33129CD1-C244-454E-9A1C-136816BDAB0A@ucla.edu>
Message-ID: <842C2D3A-55DC-41B8-9471-992865F18DAE@cs.ucla.edu>

Awesome! I?ll look into that first thing tomorrow. Thanks team!

Cheers,
Ivan

> On Jan 19, 2015, at 9:50 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
> 
> There are exactly 2 settings that require superuser privileges: 
> - location of unix socket: this does not exist in Android environment and TCP socket must be used instead.  In the compiled code (nfd-android.tar.gz), both nfd.conf and client.conf are already configured (etc/ndn/client.conf).
> - ethernet support: this is not supported on Android for now and the whole section needs to be removed from nfd.conf
> 
> ---
> Alex
> 
>> On Jan 19, 2015, at 9:29 PM, Ivan Yeo <ivanyeo at CS.UCLA.EDU> wrote:
>> 
>> Hi Steve,
>> 
>> Thanks for pointing that out. I think I've connected the dots. I changed the 'unix_socket' in both nfd.conf and client.conf to point to a file in my home directory and I now I am able to run NFD & NRD without the need for sudo. As a simple test, I ran the producer and consumer example programs on the ndn-cxx examples and all is working now (with and without sudo).
>> 
>> Right now, I'm trying to eliminate all API calls or access that require super user privileges in hope that I can just pop the NFD binaries over to the Android and run it from within a user process container. I've gone through the settings of nfd.conf and turned off all settings that require super user privileges. Off the top of your head, are there other configurations or API calls that you know of that might need elevated privileges? 
>> 
>> Cheers,
>> Ivan
>> 
>> 
>> 
>> ----- Original Message -----
>> From: "Steve DiBenedetto" <dibenede at cs.colostate.edu>
>> To: "Junxiao Shi" <shijunxiao at email.arizona.edu>
>> Cc: "<nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu>, "Ivan Yeo" <ivanyeo at cs.ucla.edu>, "Steve DiBenedetto" <dibenede at cs.colostate.edu>
>> Sent: Monday, January 19, 2015 6:02:14 PM
>> Subject: Re: Running NFD without sudo
>> 
>> 
>> What's your client.conf look like? Also, does your current configuration work if you use sudo? 
>> 
>> 
>> On Mon, Jan 19, 2015 at 6:57 PM, Junxiao Shi < shijunxiao at email.arizona.edu > wrote: 
>> 
>> 
>> 
>> 
>> 
>> ---------- Forwarded message ---------- 
>> From: Ivan Yeo < ivanyeo at cs.ucla.edu > 
>> Date: Mon, Jan 19, 2015 at 4:49 PM 
>> Subject: Running NFD without sudo 
>> To: Junxiao Shi < shijunxiao at email.arizona.edu > 
>> 
>> 
>> Hi Junxiao, 
>> 
>> I have managed to get NFD to run on Mac OS 10.10 Yosemite by changing the following settings in /usr/local/etc/ndn/nfd.conf: 
>> 
>> face_system 
>> { 
>> ; The unix section contains settings of UNIX stream faces and channels. 
>> unix 
>> { 
>> listen no; set to 'no' to disable UNIX stream listener, default 'yes' 
>> path /var/run/nfd.sock ; UNIX stream listener path 
>> } 
>> 
>> udp 
>> { 
>> mcast no; set to 'no' to disable UDP multicast, default 'yes' 
>> mcast_port 56363 ; UDP multicast port number 
>> mcast_group 224.0.23.170 ; UDP multicast group (IPv4 only) 
>> } 
>> } 
>> 
>> However, right now, NRD cannot seem to be able to connect to the running NFD. I'm wondering if happened to turn off something that is required by the NRD. I'm still diving deeper to understand how the NRD is connecting to the NFD by looking into the code base. I was wondering if you happen to know where I should start looking to expedite the process? 
>> 
>> Thanks! 
>> 
>> Cheers, 
>> Ivan 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 




From shijunxiao at email.arizona.edu  Tue Jan 20 15:06:14 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 20 Jan 2015 16:06:14 -0700
Subject: [Nfd-dev] ndn-cxx breaking change: NotificationSubscriber
Message-ID: <CAOFH+OaTyzO-oZZz=RGqJ8gPZeU0D8R=0kyYQksHaocH0Spemw@mail.gmail.com>

Dear folks

EventEmitter has been deprecated.
I'm changing EventEmitter usage in NotificationSubscriber to Signal.
Unfortunately this change is not backwards compatible.

Please be prepared to fix your code.
Changes for ndn-cxx and your code need to be merged at the same time to
avoid interruption.

You can compile your projects with ndn-cxx Change
http://gerrit.named-data.net/1652 and verify it works.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150120/b1a15738/attachment.html>

From chenatu2006 at gmail.com  Wed Jan 21 07:05:32 2015
From: chenatu2006 at gmail.com (Shuo Chen)
Date: Wed, 21 Jan 2015 23:05:32 +0800
Subject: [Nfd-dev] thread safety of ndn::face::expressInterest()
Message-ID: <CADJo4Hn_Uw3Se0BXtAOh-BJHApnrbUjPOCfc08ZaypnUi_gmxg@mail.gmail.com>

Hi everyone,

I was trying to express interests in multi threads.
Is ndn::face::expressInterest() thread-safe? Besides, which components of
ndn-cxx are thread-safe and which are not?

----
Shuo Chen
Tsinghua University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150121/64a04235/attachment.html>

From alexander.afanasyev at UCLA.EDU  Wed Jan 21 12:17:36 2015
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Wed, 21 Jan 2015 12:17:36 -0800
Subject: [Nfd-dev] thread safety of ndn::face::expressInterest()
In-Reply-To: <CADJo4Hn_Uw3Se0BXtAOh-BJHApnrbUjPOCfc08ZaypnUi_gmxg@mail.gmail.com>
References: <CADJo4Hn_Uw3Se0BXtAOh-BJHApnrbUjPOCfc08ZaypnUi_gmxg@mail.gmail.com>
Message-ID: <783C6F1B-704C-4FE2-83D5-D74AEE1CE285@ucla.edu>

Hi Shuo,

There shouldn?t be problem expressing interests (or do any other job) with ndn-cxx within multiple threads.  However, there is a strong requirement that Face::processEvents (or io_service::run) is called exactly once in some thread (doesn?t really matter which one).

The library will ensure that interests expressed from different threads are properly synchronized/serialized.

?
Alex

> On Jan 21, 2015, at 7:05 AM, Shuo Chen <chenatu2006 at gmail.com> wrote:
> 
> Hi everyone,
> 
> I was trying to express interests in multi threads. Is ndn::face::expressInterest() thread-safe? Besides, which components of ndn-cxx are thread-safe and which are not?
> 
> ----
> Shuo Chen
> Tsinghua University

-------------- 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150121/0f087281/attachment.bin>

From peter at remap.UCLA.EDU  Wed Jan 21 12:32:26 2015
From: peter at remap.UCLA.EDU (Gusev, Peter)
Date: Wed, 21 Jan 2015 20:32:26 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
Message-ID: <82C9DE44-8E98-413B-8B62-2BB3FA7F9FEE@remap.ucla.edu>

Hi all,

I?ve been testing <https://github.com/remap/ndnrtc/tree/issues/2283-retransmissions> N<https://github.com/remap/ndnrtc/tree/issues/2283-retransmissions>DN-RTC with new consumer algorithm and exploring the problem of rebufferings on consumer side (a state, when consumer is not getting data for some amount of time, flushes everything and starts over again). Consumer rebufferings are perceived as audio/video interruptions for 1-1.5sec by the user and decrease overall user experience.

I'll appreciate your insights on the analysis of the logs I retrieved from NFD.

Setup:

[Consumer] <?> [NFD1] <==WiFi_link==> [NFD2] <==Ethernet_link==> [NFD3] <?> [Producer]

Case:
According to my logs, consumer starved for data after 2656 segment has arrived, so I tracked interests and data for 2657 segment. According to my logs, consumer eventually received this data but too late and rebuffering was already inevitable.

NFD1 log:
initial interest: 1421288806.271931 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.272215 DEBUG: [Forwarder] onOutgoingInterest face=262 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.272469 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115 from=266 newPitEntry-to=262
^ 270ms
retransmission: 1421288806.542289 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.542697 DEBUG: [Forwarder] onOutgoingInterest face=262 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.543032 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=562292066 from=266 retransmit-retry-to=262
^ 286ms
data arrives: 1421288806.829462 DEBUG: [Forwarder] onIncomingData face=262 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.829818 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.830042 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=262 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.830449 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0

NFD2 log:
initial interest: 1421288806.015075 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.015845 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.016255 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115 from=266 newPitEntry-to=264
^ 545ms
retransmission: 1421288806.561516 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.562233 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.562626 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=562292066 from=266 retransmit-retry-to=264
^ 2ms
data arrives: 1421288806.564828 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.565282 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.565594 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.566213 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
^ 13ms
data arrives 2:* 1421288806.579547 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.579915 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.580162 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0

*NOTE: no data was forwarded


NFD3 log:
initial interest: 1421288806.249712 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.250177 DEBUG: [Forwarder] onOutgoingInterest face=269 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.250573 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115 from=266 newPitEntry-to=269
^271ms
data generated: 1421288806.521982 DEBUG: [Forwarder] onIncomingData face=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.522531 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.522844 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.523363 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
^273ms
retransmission: 1421288806.796022 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.796418 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0



There are several questions arise:
1. Why do you think the delay b/w initial interest and retransmission for the NFD2 became 545ms (compared to 270ms with NFD1)? Could it be WiFi fault?
2. How come the delay b/w initial interest and data in NFD3 is 271ms and NFD3 forwards this data to NFD2, but NFD2 didn?t get this data and instead got retransmission interest after another 545-271=274ms and later got the same data with 13ms difference? Could it be unreliable logging in NFD?

I attached full NFD logs to this message.

Thank you in advance.
All ideas and thoughts are welcome.

Thanks,

PS. Basically, such things block deployment of NDN-RTC (NdnCon) for the community as it delivers low-quality user experience (i.e. videoconference with interruptions =( ), so I really hope for the help and feedback.


--
Peter Gusev
peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748 (USA)
+7 916 4434826 (Russia)
+37 259 226448 (in case any other number is unavailable)
peetonn_ (skype)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150121/c82865b5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Archive.zip
Type: application/zip
Size: 1621024 bytes
Desc: Archive.zip
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150121/c82865b5/attachment.zip>

From davide.pesavento at lip6.fr  Wed Jan 21 12:37:27 2015
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Wed, 21 Jan 2015 21:37:27 +0100
Subject: [Nfd-dev] thread safety of ndn::face::expressInterest()
In-Reply-To: <783C6F1B-704C-4FE2-83D5-D74AEE1CE285@ucla.edu>
References: <CADJo4Hn_Uw3Se0BXtAOh-BJHApnrbUjPOCfc08ZaypnUi_gmxg@mail.gmail.com>
	<783C6F1B-704C-4FE2-83D5-D74AEE1CE285@ucla.edu>
Message-ID: <CADfzvvaXZ+vdW9ngNUkk5kRP6wLod6L71QgrhRg4B0D7PgRL_g@mail.gmail.com>

But doesn't this mean that all calls depending on io_service (e.g.
network operations) are effectively single-threaded?

Best,
Davide

On Wed, Jan 21, 2015 at 9:17 PM, Alex Afanasyev
<alexander.afanasyev at ucla.edu> wrote:
> Hi Shuo,
>
> There shouldn?t be problem expressing interests (or do any other job) with ndn-cxx within multiple threads.  However, there is a strong requirement that Face::processEvents (or io_service::run) is called exactly once in some thread (doesn?t really matter which one).
>
> The library will ensure that interests expressed from different threads are properly synchronized/serialized.
>
> ?
> Alex
>
>> On Jan 21, 2015, at 7:05 AM, Shuo Chen <chenatu2006 at gmail.com> wrote:
>>
>> Hi everyone,
>>
>> I was trying to express interests in multi threads. Is ndn::face::expressInterest() thread-safe? Besides, which components of ndn-cxx are thread-safe and which are not?
>>
>> ----
>> Shuo Chen
>> Tsinghua University
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>



From alexander.afanasyev at ucla.edu  Wed Jan 21 12:48:54 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 21 Jan 2015 12:48:54 -0800
Subject: [Nfd-dev] thread safety of ndn::face::expressInterest()
In-Reply-To: <CADfzvvaXZ+vdW9ngNUkk5kRP6wLod6L71QgrhRg4B0D7PgRL_g@mail.gmail.com>
References: <CADJo4Hn_Uw3Se0BXtAOh-BJHApnrbUjPOCfc08ZaypnUi_gmxg@mail.gmail.com>
	<783C6F1B-704C-4FE2-83D5-D74AEE1CE285@ucla.edu>
	<CADfzvvaXZ+vdW9ngNUkk5kRP6wLod6L71QgrhRg4B0D7PgRL_g@mail.gmail.com>
Message-ID: <B2001AEC-99E9-4A9B-82BA-660899923AB7@ucla.edu>


> On Jan 21, 2015, at 12:37 PM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:
> 
> But doesn't this mean that all calls depending on io_service (e.g.
> network operations) are effectively single-threaded?

Yes. As of right now it means exactly this.  This was in attempt to avoid additional locking inside ndn-cxx implementation (which I believe would have resulted in about the same effect).  The cpu-heavy signature creation and verification (just verification part) can be performed in separate threads, as they are independent of io_service.

---
Alex

> Best,
> Davide
> 
> On Wed, Jan 21, 2015 at 9:17 PM, Alex Afanasyev
> <alexander.afanasyev at ucla.edu> wrote:
>> Hi Shuo,
>> 
>> There shouldn?t be problem expressing interests (or do any other job) with ndn-cxx within multiple threads.  However, there is a strong requirement that Face::processEvents (or io_service::run) is called exactly once in some thread (doesn?t really matter which one).
>> 
>> The library will ensure that interests expressed from different threads are properly synchronized/serialized.
>> 
>> ?
>> Alex
>> 
>>> On Jan 21, 2015, at 7:05 AM, Shuo Chen <chenatu2006 at gmail.com> wrote:
>>> 
>>> Hi everyone,
>>> 
>>> I was trying to express interests in multi threads. Is ndn::face::expressInterest() thread-safe? Besides, which components of ndn-cxx are thread-safe and which are not?
>>> 
>>> ----
>>> Shuo Chen
>>> Tsinghua University
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150121/bc04ed51/attachment.bin>

From alexander.afanasyev at UCLA.EDU  Wed Jan 21 18:26:14 2015
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Wed, 21 Jan 2015 18:26:14 -0800
Subject: [Nfd-dev] Packages for homebrew
Message-ID: <33BA4008-9350-4B20-A822-F2491878BE65@ucla.edu>

Hi everybody,

I finally finished hacking homebrew packages for NFD and few other things.  Homebrew is similar to macports, but may be easier to use for some people.  Also, a big difference is that I was able to provide compiled binaries, so actual compilation can be avoided.

I would appreciate if somebody take a look and give feedback whether it worked or not.

Quick and short instructions:

- To install brew copy the following in the command line

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

- Configure NDN "tap"

brew tap named-data/ndn

- Install packages (ndn-cxx, nfd, ndndump, and ndnping are currently available)

brew install nfd ndndump ndnping

*** On OS X 10.10, ndn-cxx, nfd, ndndump, and ndnping packages should be installed directly from the pre-compiled binaries (some other dependencies will also be installed on the way).

*** Binaries for older OS X releases may be created later.  The process is not automated, so it will be on best-effort basis if I have time or if there are volunteers to do that :-D

*** The most time I spent was in making NFD to use launchd to start/stop.  These operations are hidden by nfd-start and nfd-stop scripts.


For those who interested about details, brew formulae definitions are in our github repo: https://github.com/named-data/homebrew-ndn

---
Alex

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150121/883809be/attachment.bin>

From dibenede at cs.colostate.edu  Wed Jan 21 18:35:11 2015
From: dibenede at cs.colostate.edu (Steve DiBenedetto)
Date: Wed, 21 Jan 2015 19:35:11 -0700
Subject: [Nfd-dev] Packages for homebrew
In-Reply-To: <33BA4008-9350-4B20-A822-F2491878BE65@ucla.edu>
References: <33BA4008-9350-4B20-A822-F2491878BE65@ucla.edu>
Message-ID: <CAG95Nwu=OydDi0G9SgoFBbS24z-6XT1=ygjU+2K0etuqujhBiA@mail.gmail.com>

Works for me on 10.10.

On Wed, Jan 21, 2015 at 7:26 PM, Alex Afanasyev <
alexander.afanasyev at ucla.edu> wrote:

> Hi everybody,
>
> I finally finished hacking homebrew packages for NFD and few other
> things.  Homebrew is similar to macports, but may be easier to use for some
> people.  Also, a big difference is that I was able to provide compiled
> binaries, so actual compilation can be avoided.
>
> I would appreciate if somebody take a look and give feedback whether it
> worked or not.
>
> Quick and short instructions:
>
> - To install brew copy the following in the command line
>
> ruby -e "$(curl -fsSL
> https://raw.githubusercontent.com/Homebrew/install/master/install)"
>
> - Configure NDN "tap"
>
> brew tap named-data/ndn
>
> - Install packages (ndn-cxx, nfd, ndndump, and ndnping are currently
> available)
>
> brew install nfd ndndump ndnping
>
> *** On OS X 10.10, ndn-cxx, nfd, ndndump, and ndnping packages should be
> installed directly from the pre-compiled binaries (some other dependencies
> will also be installed on the way).
>
> *** Binaries for older OS X releases may be created later.  The process is
> not automated, so it will be on best-effort basis if I have time or if
> there are volunteers to do that :-D
>
> *** The most time I spent was in making NFD to use launchd to start/stop.
> These operations are hidden by nfd-start and nfd-stop scripts.
>
>
> For those who interested about details, brew formulae definitions are in
> our github repo: https://github.com/named-data/homebrew-ndn
>
> ---
> Alex
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150121/08a8c54a/attachment.html>

From shijunxiao at email.arizona.edu  Wed Jan 21 22:39:03 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 21 Jan 2015 23:39:03 -0700
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <82C9DE44-8E98-413B-8B62-2BB3FA7F9FEE@remap.ucla.edu>
References: <82C9DE44-8E98-413B-8B62-2BB3FA7F9FEE@remap.ucla.edu>
Message-ID: <CAOFH+OYSL_VFyCm8W8e87EY=uqGFHHz24OQechOOm6jXnhnapw@mail.gmail.com>

Hi Peter

It appears that NFD2 node is overloaded.
There is a big delay between NFD3 returns first Data and NFD2 receives that
Data.
There is a big delay between NFD1 forwards second Interests and NFD
receives that Interest.

To determine whether a node is overloaded, look at its CPU utilization. If
CPU utilization of any core is over 50%, reduce traffic rate.


It's expected for NFD2 not to return the second Data, because PIT entry has
been satisfied by the first Data.
When the second Data arrives, PIT entry contains no downstream record, and
therefore Data will not be returned to NFD1.


This experiment appears to be using an outdated NFD version (older than Sep
08, 2014).
For future reports, please use git-HEAD.

Yours, Junxiao

On Wed, Jan 21, 2015 at 1:32 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:

>  Hi all,
>
>  I?ve been testing
> <https://github.com/remap/ndnrtc/tree/issues/2283-retransmissions>N
> <https://github.com/remap/ndnrtc/tree/issues/2283-retransmissions>DN-RTC with
> new consumer algorithm and exploring the problem of rebufferings on
> consumer side (a state, when consumer is not getting data for some amount
> of time, flushes everything and starts over again). Consumer rebufferings
> are perceived as audio/video interruptions for 1-1.5sec by the user and
> decrease overall user experience.
>
>  I'll appreciate your insights on the analysis of the logs I retrieved
> from NFD.
>
>  *Setup:*
>
>  [Consumer] <?> [*NFD1*] <==*WiFi_link*==> [*NFD2*] <==*Ethernet_link*==>
> [*NFD3*] <?> [Producer]
>
>  *Case:*
> According to my logs, consumer starved for data after 2656 segment has
> arrived, so I tracked interests and data for *2657* segment. According to
> my logs, consumer eventually received this data but too late and
> rebuffering was already inevitable.
>
>  *NFD1 log:*
>  *initial interest: *1421288806.271931 DEBUG: [Forwarder]
> onIncomingInterest face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.272215 DEBUG: [Forwarder] onOutgoingInterest face=262
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.272469 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115
> from=266 newPitEntry-to=262
> *^ 270ms*
> *retransmission:* 1421288806.542289 DEBUG: [Forwarder] onIncomingInterest
> face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.542697 DEBUG: [Forwarder] onOutgoingInterest face=262
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.543032 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=562292066
> from=266 retransmit-retry-to=262
> *^ 286ms*
> *data arrives:* 1421288806.829462 DEBUG: [Forwarder] onIncomingData
> face=262
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
> 1421288806.829818 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.830042 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> inFace=262
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
> 1421288806.830449 DEBUG: [Forwarder] onOutgoingData face=266
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>
>  *NFD2 log:*
>  *initial interest:* 1421288806.015075 DEBUG: [Forwarder]
> onIncomingInterest face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.015845 DEBUG: [Forwarder] onOutgoingInterest face=264
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.016255 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115
> from=266 newPitEntry-to=264
> *^ 545ms*
> *retransmission:* 1421288806.561516 DEBUG: [Forwarder] onIncomingInterest
> face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.562233 DEBUG: [Forwarder] onOutgoingInterest face=264
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.562626 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=562292066
> from=266 retransmit-retry-to=264
> *^ 2ms*
> *data arrives:* 1421288806.564828 DEBUG: [Forwarder] onIncomingData
> face=264
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
> 1421288806.565282 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.565594 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
> 1421288806.566213 DEBUG: [Forwarder] onOutgoingData face=266
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
> *^ 13ms*
> *data arrives 2:** 1421288806.579547 DEBUG: [Forwarder] onIncomingData
> face=264
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
> 1421288806.579915 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.580162 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> inFace=264
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>
>  **NOTE:* *no data was forwarded*
>
>
>  *NFD3 log:*
>  *initial interest:* 1421288806.249712 DEBUG: [Forwarder]
> onIncomingInterest face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.250177 DEBUG: [Forwarder] onOutgoingInterest face=269
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.250573 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115
> from=266 newPitEntry-to=269
> *^271ms*
> *data generated:* 1421288806.521982 DEBUG: [Forwarder] onIncomingData
> face=269
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
> 1421288806.522531 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.522844 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> inFace=269
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
> 1421288806.523363 DEBUG: [Forwarder] onOutgoingData face=266
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
> *^273ms*
> *retransmission:* 1421288806.796022 DEBUG: [Forwarder] onIncomingInterest
> face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
> 1421288806.796418 DEBUG: [Forwarder] onOutgoingData face=266
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>
>
>
>  There are several questions arise:
> 1. Why do you think the delay b/w initial interest and retransmission for
> the NFD2 became 545ms (compared to 270ms with NFD1)? Could it be WiFi fault?
> 2. How come the delay b/w initial interest and data in NFD3 is 271ms and
> NFD3 forwards this data to NFD2, but NFD2 didn?t get this data and instead
> got retransmission interest after another 545-271=*274ms *and later got
> the same data with 13ms difference? Could it be unreliable logging in NFD?
>
>  I attached full NFD logs to this message.
>
>  Thank you in advance.
> All ideas and thoughts are welcome.
>
>  Thanks,
>
>  PS. Basically, such things block deployment of NDN-RTC (NdnCon) for the
> community as it delivers low-quality user experience (i.e. videoconference
> with interruptions =( ), so I really hope for the help and feedback.
>
>
> --
> Peter Gusev
> peter at remap.ucla.edu
> +1 213 5872748 (USA)
> +7 916 4434826 (Russia)
> +37 259 226448 (in case any other number is unavailable)
> peetonn_ (skype)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150121/1c50b222/attachment.html>

From jburke at remap.UCLA.EDU  Wed Jan 21 23:03:56 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Thu, 22 Jan 2015 07:03:56 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <CAOFH+OYSL_VFyCm8W8e87EY=uqGFHHz24OQechOOm6jXnhnapw@mail.gmail.com>
Message-ID: <D0E5E085.1ACCED%jburke@remap.ucla.edu>

Hi Junxiao,
Thanks for looking at this.
Would this <50% CPU utilization target to apply to end-hosts as well?  (Seems hard to meet this while running media apps.)
Jeff
From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Wed, 21 Jan 2015 23:39:03 -0700
To: "Gusev, Peter" <peter at remap.UCLA.EDU<mailto:peter at remap.UCLA.EDU>>
Cc: "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Peter

It appears that NFD2 node is overloaded.
There is a big delay between NFD3 returns first Data and NFD2 receives that Data.
There is a big delay between NFD1 forwards second Interests and NFD receives that Interest.

To determine whether a node is overloaded, look at its CPU utilization. If CPU utilization of any core is over 50%, reduce traffic rate.


It's expected for NFD2 not to return the second Data, because PIT entry has been satisfied by the first Data.
When the second Data arrives, PIT entry contains no downstream record, and therefore Data will not be returned to NFD1.


This experiment appears to be using an outdated NFD version (older than Sep 08, 2014).
For future reports, please use git-HEAD.

Yours, Junxiao

On Wed, Jan 21, 2015 at 1:32 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi all,

I?ve been testing <https://github.com/remap/ndnrtc/tree/issues/2283-retransmissions> N<https://github.com/remap/ndnrtc/tree/issues/2283-retransmissions>DN-RTC with new consumer algorithm and exploring the problem of rebufferings on consumer side (a state, when consumer is not getting data for some amount of time, flushes everything and starts over again). Consumer rebufferings are perceived as audio/video interruptions for 1-1.5sec by the user and decrease overall user experience.

I'll appreciate your insights on the analysis of the logs I retrieved from NFD.

Setup:

[Consumer] <?> [NFD1] <==WiFi_link==> [NFD2] <==Ethernet_link==> [NFD3] <?> [Producer]

Case:
According to my logs, consumer starved for data after 2656 segment has arrived, so I tracked interests and data for 2657 segment. According to my logs, consumer eventually received this data but too late and rebuffering was already inevitable.

NFD1 log:
initial interest:1421288806.271931 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.272215 DEBUG: [Forwarder] onOutgoingInterest face=262 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.272469 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115 from=266 newPitEntry-to=262
^ 270ms
retransmission:1421288806.542289 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.542697 DEBUG: [Forwarder] onOutgoingInterest face=262 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.543032 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=562292066 from=266 retransmit-retry-to=262
^ 286ms
data arrives:1421288806.829462 DEBUG: [Forwarder] onIncomingData face=262 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.829818 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.830042 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=262 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.830449 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0

NFD2 log:
initial interest:1421288806.015075 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.015845 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.016255 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115 from=266 newPitEntry-to=264
^ 545ms
retransmission:1421288806.561516 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.562233 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.562626 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=562292066 from=266 retransmit-retry-to=264
^ 2ms
data arrives:1421288806.564828 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.565282 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.565594 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.566213 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
^ 13ms
data arrives 2:*1421288806.579547 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.579915 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.580162 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0

*NOTE: no data was forwarded


NFD3 log:
initial interest:1421288806.249712 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.250177 DEBUG: [Forwarder] onOutgoingInterest face=269 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.250573 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115 from=266 newPitEntry-to=269
^271ms
data generated:1421288806.521982 DEBUG: [Forwarder] onIncomingData face=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.522531 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.522844 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.523363 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
^273ms
retransmission:1421288806.796022 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.796418 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0



There are several questions arise:
1. Why do you think the delay b/w initial interest and retransmission for the NFD2 became 545ms (compared to 270ms with NFD1)? Could it be WiFi fault?
2. How come the delay b/w initial interest and data in NFD3 is 271ms and NFD3 forwards this data to NFD2, but NFD2 didn?t get this data and instead got retransmission interest after another 545-271=274ms and later got the same data with 13ms difference? Could it be unreliable logging in NFD?

I attached full NFD logs to this message.

Thank you in advance.
All ideas and thoughts are welcome.

Thanks,

PS. Basically, such things block deployment of NDN-RTC (NdnCon) for the community as it delivers low-quality user experience (i.e. videoconference with interruptions =( ), so I really hope for the help and feedback.


--
Peter Gusev
peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748> (USA)
+7 916 4434826<tel:%2B7%20916%204434826> (Russia)
+37 259 226448<tel:%2B37%20259%20226448> (in case any other number is unavailable)
peetonn_ (skype)
_______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150122/43ce74a3/attachment.html>

From peter at remap.UCLA.EDU  Thu Jan 22 13:04:50 2015
From: peter at remap.UCLA.EDU (Gusev, Peter)
Date: Thu, 22 Jan 2015 21:04:50 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <D0E5E085.1ACCED%jburke@remap.ucla.edu>
References: <D0E5E085.1ACCED%jburke@remap.ucla.edu>
Message-ID: <8D97688B-3B64-48F6-A80C-5B124D04E7A6@remap.ucla.edu>

Hi Junxiao,

Thanks for your input!
I'm surprised to know that NFD2 was overloaded - this hub did not run any extraneous apps except MacOS Activity Monitor and NFD itself, however NFD1 and NFD3 were executing NDN-RTC code (consumer and producer respectively).
Besides that, NDN-RTC was running on lowest configuration (having one 8000-bytes segment per frame) so the number of interests was minimal (~30 interests/sec), which means for higher quality, the number of interests will increase.

Thanks,

--
Peter Gusev
peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748 (USA)
peetonn_ (skype)

On Jan 21, 2015, at 11:03 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Hi Junxiao,
Thanks for looking at this.
Would this <50% CPU utilization target to apply to end-hosts as well?  (Seems hard to meet this while running media apps.)
Jeff
From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Wed, 21 Jan 2015 23:39:03 -0700
To: "Gusev, Peter" <peter at remap.UCLA.EDU<mailto:peter at remap.UCLA.EDU>>
Cc: "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Peter

It appears that NFD2 node is overloaded.
There is a big delay between NFD3 returns first Data and NFD2 receives that Data.
There is a big delay between NFD1 forwards second Interests and NFD receives that Interest.

To determine whether a node is overloaded, look at its CPU utilization. If CPU utilization of any core is over 50%, reduce traffic rate.


It's expected for NFD2 not to return the second Data, because PIT entry has been satisfied by the first Data.
When the second Data arrives, PIT entry contains no downstream record, and therefore Data will not be returned to NFD1.


This experiment appears to be using an outdated NFD version (older than Sep 08, 2014).
For future reports, please use git-HEAD.

Yours, Junxiao

On Wed, Jan 21, 2015 at 1:32 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi all,

I?ve been testing <https://github.com/remap/ndnrtc/tree/issues/2283-retransmissions> N<https://github.com/remap/ndnrtc/tree/issues/2283-retransmissions>DN-RTC with new consumer algorithm and exploring the problem of rebufferings on consumer side (a state, when consumer is not getting data for some amount of time, flushes everything and starts over again). Consumer rebufferings are perceived as audio/video interruptions for 1-1.5sec by the user and decrease overall user experience.

I'll appreciate your insights on the analysis of the logs I retrieved from NFD.

Setup:

[Consumer] <?> [NFD1] <==WiFi_link==> [NFD2] <==Ethernet_link==> [NFD3] <?> [Producer]

Case:
According to my logs, consumer starved for data after 2656 segment has arrived, so I tracked interests and data for 2657 segment. According to my logs, consumer eventually received this data but too late and rebuffering was already inevitable.

NFD1 log:
initial interest:1421288806.271931 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.272215 DEBUG: [Forwarder] onOutgoingInterest face=262 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.272469 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115 from=266 newPitEntry-to=262
^ 270ms
retransmission:1421288806.542289 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.542697 DEBUG: [Forwarder] onOutgoingInterest face=262 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.543032 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=562292066 from=266 retransmit-retry-to=262
^ 286ms
data arrives:1421288806.829462 DEBUG: [Forwarder] onIncomingData face=262 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.829818 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.830042 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=262 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.830449 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0

NFD2 log:
initial interest:1421288806.015075 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.015845 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.016255 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115 from=266 newPitEntry-to=264
^ 545ms
retransmission:1421288806.561516 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.562233 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.562626 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=562292066 from=266 retransmit-retry-to=264
^ 2ms
data arrives:1421288806.564828 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.565282 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.565594 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.566213 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
^ 13ms
data arrives 2:*1421288806.579547 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.579915 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.580162 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0

*NOTE: no data was forwarded


NFD3 log:
initial interest:1421288806.249712 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.250177 DEBUG: [Forwarder] onOutgoingInterest face=269 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.250573 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115 from=266 newPitEntry-to=269
^271ms
data generated:1421288806.521982 DEBUG: [Forwarder] onIncomingData face=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.522531 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.522844 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.523363 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
^273ms
retransmission:1421288806.796022 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.796418 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0



There are several questions arise:
1. Why do you think the delay b/w initial interest and retransmission for the NFD2 became 545ms (compared to 270ms with NFD1)? Could it be WiFi fault?
2. How come the delay b/w initial interest and data in NFD3 is 271ms and NFD3 forwards this data to NFD2, but NFD2 didn?t get this data and instead got retransmission interest after another 545-271=274ms and later got the same data with 13ms difference? Could it be unreliable logging in NFD?

I attached full NFD logs to this message.

Thank you in advance.
All ideas and thoughts are welcome.

Thanks,

PS. Basically, such things block deployment of NDN-RTC (NdnCon) for the community as it delivers low-quality user experience (i.e. videoconference with interruptions =( ), so I really hope for the help and feedback.


--
Peter Gusev
peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748> (USA)
+7 916 4434826<tel:%2B7%20916%204434826> (Russia)
+37 259 226448<tel:%2B37%20259%20226448> (in case any other number is unavailable)
peetonn_ (skype)
_______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150122/571ec501/attachment.html>

From shijunxiao at email.arizona.edu  Thu Jan 22 16:07:33 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 22 Jan 2015 17:07:33 -0700
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <8D97688B-3B64-48F6-A80C-5B124D04E7A6@remap.ucla.edu>
References: <D0E5E085.1ACCED%jburke@remap.ucla.edu>
	<8D97688B-3B64-48F6-A80C-5B124D04E7A6@remap.ucla.edu>
Message-ID: <CAOFH+OZ9oCqn=4SqwG02SHGLaYCf+TzfnpO14xKjsVS+-aTMwg@mail.gmail.com>

Hi Peter

With 30 Interests/second, NFD2 is unlikely to be overloaded.

What's the MTU used on both links?
If it's below 9000, NDNLP fragmentation or IP fragmentation may cause
delays.
Please set MTU to 9000 or above and try again.

Yours, Junxiao

On Thu, Jan 22, 2015 at 2:04 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:

>  Hi Junxiao,
>
>  Thanks for your input!
> I'm surprised to know that NFD2 was overloaded - this hub did not run any
> extraneous apps except MacOS Activity Monitor and NFD itself, however NFD1
> and NFD3 were executing NDN-RTC code (consumer and producer respectively).
> Besides that, NDN-RTC was running on lowest configuration (having one
> 8000-bytes segment per frame) so the number of interests was minimal (~30
> interests/sec), which means for higher quality, the number of interests
> will increase.
>
>  Thanks,
>
> --
> Peter Gusev
> peter at remap.ucla.edu
> +1 213 5872748 (USA)
> peetonn_ (skype)
>
>  On Jan 21, 2015, at 11:03 PM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>
>  Hi Junxiao,
> Thanks for looking at this.
> Would this <50% CPU utilization target to apply to end-hosts as well?
>  (Seems hard to meet this while running media apps.)
> Jeff
>  From: Junxiao Shi <shijunxiao at email.arizona.edu>
> Date: Wed, 21 Jan 2015 23:39:03 -0700
> To: "Gusev, Peter" <peter at remap.UCLA.EDU>
> Cc: "<nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs
>
>  Hi Peter
>
>  It appears that NFD2 node is overloaded.
> There is a big delay between NFD3 returns first Data and NFD2 receives
> that Data.
> There is a big delay between NFD1 forwards second Interests and NFD
> receives that Interest.
>
>  To determine whether a node is overloaded, look at its CPU utilization.
> If CPU utilization of any core is over 50%, reduce traffic rate.
>
>
>  It's expected for NFD2 not to return the second Data, because PIT entry
> has been satisfied by the first Data.
> When the second Data arrives, PIT entry contains no downstream record, and
> therefore Data will not be returned to NFD1.
>
>
>  This experiment appears to be using an outdated NFD version (older than
> Sep 08, 2014).
> For future reports, please use git-HEAD.
>
>  Yours, Junxiao
>
> On Wed, Jan 21, 2015 at 1:32 PM, Gusev, Peter <peter at remap.ucla.edu>
> wrote:
>
>>  Hi all,
>>
>>  I?ve been testing
>> <https://github.com/remap/ndnrtc/tree/issues/2283-retransmissions>N
>> <https://github.com/remap/ndnrtc/tree/issues/2283-retransmissions>DN-RTC with
>> new consumer algorithm and exploring the problem of rebufferings on
>> consumer side (a state, when consumer is not getting data for some amount
>> of time, flushes everything and starts over again). Consumer rebufferings
>> are perceived as audio/video interruptions for 1-1.5sec by the user and
>> decrease overall user experience.
>>
>>  I'll appreciate your insights on the analysis of the logs I retrieved
>> from NFD.
>>
>>  *Setup:*
>>
>>  [Consumer] <?> [*NFD1*] <==*WiFi_link*==> [*NFD2*] <==*Ethernet_link*==>
>> [*NFD3*] <?> [Producer]
>>
>>  *Case:*
>> According to my logs, consumer starved for data after 2656 segment has
>> arrived, so I tracked interests and data for *2657* segment. According
>> to my logs, consumer eventually received this data but too late and
>> rebuffering was already inevitable.
>>
>>  *NFD1 log:*
>>  *initial interest:*1421288806.271931 DEBUG: [Forwarder]
>> onIncomingInterest face=266
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.272215 DEBUG: [Forwarder] onOutgoingInterest face=262
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.272469 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115
>> from=266 newPitEntry-to=262
>> *^ 270ms*
>> *retransmission:*1421288806.542289 DEBUG: [Forwarder] onIncomingInterest
>> face=266
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.542697 DEBUG: [Forwarder] onOutgoingInterest face=262
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.543032 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=562292066
>> from=266 retransmit-retry-to=262
>> *^ 286ms*
>> *data arrives:*1421288806.829462 DEBUG: [Forwarder] onIncomingData
>> face=262
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>> 1421288806.829818 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.830042 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> inFace=262
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>> 1421288806.830449 DEBUG: [Forwarder] onOutgoingData face=266
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>>
>>  *NFD2 log:*
>>  *initial interest:*1421288806.015075 DEBUG: [Forwarder]
>> onIncomingInterest face=266
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.015845 DEBUG: [Forwarder] onOutgoingInterest face=264
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.016255 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115
>> from=266 newPitEntry-to=264
>> *^ 545ms*
>> *retransmission:*1421288806.561516 DEBUG: [Forwarder] onIncomingInterest
>> face=266
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.562233 DEBUG: [Forwarder] onOutgoingInterest face=264
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.562626 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=562292066
>> from=266 retransmit-retry-to=264
>> *^ 2ms*
>> *data arrives:*1421288806.564828 DEBUG: [Forwarder] onIncomingData
>> face=264
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>> 1421288806.565282 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.565594 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>> 1421288806.566213 DEBUG: [Forwarder] onOutgoingData face=266
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>> *^ 13ms*
>> *data arrives 2:**1421288806.579547 DEBUG: [Forwarder] onIncomingData
>> face=264
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>> 1421288806.579915 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.580162 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> inFace=264
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>>
>>  **NOTE:* *no data was forwarded*
>>
>>
>>  *NFD3 log:*
>>  *initial interest:*1421288806.249712 DEBUG: [Forwarder]
>> onIncomingInterest face=266
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.250177 DEBUG: [Forwarder] onOutgoingInterest face=269
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.250573 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115
>> from=266 newPitEntry-to=269
>> *^271ms*
>> *data generated:*1421288806.521982 DEBUG: [Forwarder] onIncomingData
>> face=269
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>> 1421288806.522531 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.522844 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> inFace=269
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>> 1421288806.523363 DEBUG: [Forwarder] onOutgoingData face=266
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>> *^273ms*
>> *retransmission:*1421288806.796022 DEBUG: [Forwarder] onIncomingInterest
>> face=266
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
>> 1421288806.796418 DEBUG: [Forwarder] onOutgoingData face=266
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
>>
>>
>>
>>  There are several questions arise:
>> 1. Why do you think the delay b/w initial interest and retransmission for
>> the NFD2 became 545ms (compared to 270ms with NFD1)? Could it be WiFi fault?
>> 2. How come the delay b/w initial interest and data in NFD3 is 271ms and
>> NFD3 forwards this data to NFD2, but NFD2 didn?t get this data and instead
>> got retransmission interest after another 545-271=*274ms *and later got
>> the same data with 13ms difference? Could it be unreliable logging in NFD?
>>
>>  I attached full NFD logs to this message.
>>
>>  Thank you in advance.
>> All ideas and thoughts are welcome.
>>
>>  Thanks,
>>
>>  PS. Basically, such things block deployment of NDN-RTC (NdnCon) for the
>> community as it delivers low-quality user experience (i.e. videoconference
>> with interruptions =( ), so I really hope for the help and feedback.
>>
>>
>> --
>> Peter Gusev
>> peter at remap.ucla.edu
>> +1 213 5872748 (USA)
>> +7 916 4434826 (Russia)
>> +37 259 226448 (in case any other number is unavailable)
>> peetonn_ (skype)
>>
>   _______________________________________________ Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150122/b2158828/attachment.html>

From jefft0 at remap.ucla.edu  Fri Jan 23 10:53:35 2015
From: jefft0 at remap.ucla.edu (Thompson, Jeff)
Date: Fri, 23 Jan 2015 18:53:35 +0000
Subject: [Nfd-dev] Secure websocket support in NFD?
Message-ID: <D0E7D88A.1AE59%jefft0@remap.ucla.edu>

Hello NFD team,

If a web page is served over https, and the JavaScript in the web page wants to make a WebSocket connection, then this connection must be over secure WebSocket over TLS (wss). This means that if a web page servered over https needs to communicate with an NFD host, then the WebSocket proxy in NFD needs to support secure WebSocket.

Does the WebSocket library used by NFD support secure TLS connections (wss)?

Thanks,
- Jeff T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150123/83121a72/attachment.html>

From wentaoshang at gmail.com  Fri Jan 23 12:21:49 2015
From: wentaoshang at gmail.com (Wentao Shang)
Date: Fri, 23 Jan 2015 20:21:49 +0000
Subject: [Nfd-dev] Secure websocket support in NFD?
References: <D0E7D88A.1AE59%jefft0@remap.ucla.edu>
Message-ID: <CAD4s1gT+dSLBP5dqPAhQJtd3rm-NjoFVfha=avcBBakD59gdxw@mail.gmail.com>

Hi Jeff T,

The WebSocket library we are using in NFD is 'websocketpp'

http://www.zaphoyd.com/websocketpp

It supports WebSocket over TLS but we haven't added that to NFD yet. If
there is consensus that this will be useful, we can add wss support in the
next release of NFD (the only issue is to pick a port number for wss
server).

Best,
Wentao

On Fri Jan 23 2015 at 10:53:50 AM Thompson, Jeff <jefft0 at remap.ucla.edu>
wrote:

>  Hello NFD team,
>
>  If a web page is served over https, and the JavaScript in the web page
> wants to make a WebSocket connection, then this connection must be over
> secure WebSocket over TLS (wss). This means that if a web page servered
> over https needs to communicate with an NFD host, then the WebSocket proxy
> in NFD needs to support secure WebSocket.
>
>  Does the WebSocket library used by NFD support secure TLS connections
> (wss)?
>
>  Thanks,
> - Jeff T
>  _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150123/3ee66ba3/attachment.html>

From alexander.afanasyev at ucla.edu  Fri Jan 23 12:30:20 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Fri, 23 Jan 2015 12:30:20 -0800
Subject: [Nfd-dev] Secure websocket support in NFD?
In-Reply-To: <CAD4s1gT+dSLBP5dqPAhQJtd3rm-NjoFVfha=avcBBakD59gdxw@mail.gmail.com>
References: <D0E7D88A.1AE59%jefft0@remap.ucla.edu>
	<CAD4s1gT+dSLBP5dqPAhQJtd3rm-NjoFVfha=avcBBakD59gdxw@mail.gmail.com>
Message-ID: <77E2D59A-967C-470F-B777-AA365116B855@ucla.edu>

I think besides the basic support from the library, the actual problem with TLS is necessity to get actual CA-issued certificate and then configure it.
I would suggest not having such support (at least not in the near future).

Things can get relative simple if we integrated with Alex Halderman's https://letsencrypt.org/ <https://letsencrypt.org/> here, but it still will only apply to NFD?s that has domain names (e.g., some gateway nodes).

?
Alex

> On Jan 23, 2015, at 12:21 PM, Wentao Shang <wentaoshang at gmail.com> wrote:
> 
> Hi Jeff T,
> 
> The WebSocket library we are using in NFD is 'websocketpp'
> 
> http://www.zaphoyd.com/websocketpp <http://www.zaphoyd.com/websocketpp>
> 
> It supports WebSocket over TLS but we haven't added that to NFD yet. If there is consensus that this will be useful, we can add wss support in the next release of NFD (the only issue is to pick a port number for wss server).
> 
> Best,
> Wentao
> 
> On Fri Jan 23 2015 at 10:53:50 AM Thompson, Jeff <jefft0 at remap.ucla.edu <mailto:jefft0 at remap.ucla.edu>> wrote:
> Hello NFD team,
> 
> If a web page is served over https, and the JavaScript in the web page wants to make a WebSocket connection, then this connection must be over secure WebSocket over TLS (wss). This means that if a web page servered over https needs to communicate with an NFD host, then the WebSocket proxy in NFD needs to support secure WebSocket.
> 
> Does the WebSocket library used by NFD support secure TLS connections (wss)?
> 
> Thanks,
> - Jeff T

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150123/2ab87579/attachment.html>
-------------- 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150123/2ab87579/attachment.bin>

From shijunxiao at email.arizona.edu  Fri Jan 23 12:36:02 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 23 Jan 2015 13:36:02 -0700
Subject: [Nfd-dev] Secure websocket support in NFD?
In-Reply-To: <CAD4s1gTg6vee-gDtextcnpBjMq16kXQ48T-3VF5+a0oq58ZURQ@mail.gmail.com>
References: <D0E7D88A.1AE59%jefft0@remap.ucla.edu>
	<CAD4s1gT+dSLBP5dqPAhQJtd3rm-NjoFVfha=avcBBakD59gdxw@mail.gmail.com>
	<CAOFH+ObKj5f+XVBwS3QWyr=V_b3qkfbkk6ZcV+jDx9-KOFuZkQ@mail.gmail.com>
	<CAD4s1gTg6vee-gDtextcnpBjMq16kXQ48T-3VF5+a0oq58ZURQ@mail.gmail.com>
Message-ID: <CAOFH+OY8OoF+VneAiOw9qTvYOnW1zTWoj+wh7Fnr06Mzm3r_6w@mail.gmail.com>

Hi Wentao

Purchasing certificates shouldn't be a problem. Entry level certificates
can be purchased within 10 minutes.
During development and testing, you could use your own CA (Windows Server
Certificate Authority or OpenSSL).

The configuration file should just accept:

* a private key
* a bundle of certificates including root CA, intermediate CAs, and site
certificate

Yours, Junxiao

On Jan 23, 2015 1:30 PM, "Wentao Shang" <wentaoshang at gmail.com> wrote:
>
> Hi Junxiao,
>
> Alex reminded me of another important issue: if we want to serve
https/wss, we need to get certificates from CAs somehow. I don't have
experience with https deployment so not sure how difficult this will be.
>
> Wentao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150123/887f55c5/attachment.html>

From alexander.afanasyev at ucla.edu  Fri Jan 23 12:39:25 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Fri, 23 Jan 2015 12:39:25 -0800
Subject: [Nfd-dev] Secure websocket support in NFD?
In-Reply-To: <CAOFH+OY8OoF+VneAiOw9qTvYOnW1zTWoj+wh7Fnr06Mzm3r_6w@mail.gmail.com>
References: <D0E7D88A.1AE59%jefft0@remap.ucla.edu>
	<CAD4s1gT+dSLBP5dqPAhQJtd3rm-NjoFVfha=avcBBakD59gdxw@mail.gmail.com>
	<CAOFH+ObKj5f+XVBwS3QWyr=V_b3qkfbkk6ZcV+jDx9-KOFuZkQ@mail.gmail.com>
	<CAD4s1gTg6vee-gDtextcnpBjMq16kXQ48T-3VF5+a0oq58ZURQ@mail.gmail.com>
	<CAOFH+OY8OoF+VneAiOw9qTvYOnW1zTWoj+wh7Fnr06Mzm3r_6w@mail.gmail.com>
Message-ID: <9B51E730-7553-4FE6-8743-B886E284DD88@ucla.edu>

There are places where you can get free certificates.  http://www.startssl.com/ <http://www.startssl.com/> is one and https://letsencrypt.org/ <https://letsencrypt.org/> will be another one.

The problem is just someone needs to have domain name first, then it someone needs to actually generate cert, sign it, and then configure.  Nothing extraordinary, just takes time and effort.



> On Jan 23, 2015, at 12:36 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Wentao
> 
> Purchasing certificates shouldn't be a problem. Entry level certificates can be purchased within 10 minutes.
> During development and testing, you could use your own CA (Windows Server Certificate Authority or OpenSSL).
> 
> The configuration file should just accept:
> 
> * a private key
> * a bundle of certificates including root CA, intermediate CAs, and site certificate
> 
> Yours, Junxiao
> 
> On Jan 23, 2015 1:30 PM, "Wentao Shang" <wentaoshang at gmail.com <mailto:wentaoshang at gmail.com>> wrote:
> >
> > Hi Junxiao,
> >
> > Alex reminded me of another important issue: if we want to serve https/wss, we need to get certificates from CAs somehow. I don't have experience with https deployment so not sure how difficult this will be.
> >
> > Wentao
> >
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150123/29a2cfd5/attachment.html>
-------------- 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150123/29a2cfd5/attachment.bin>

From jburke at remap.UCLA.EDU  Fri Jan 23 12:40:20 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Fri, 23 Jan 2015 20:40:20 +0000
Subject: [Nfd-dev] Secure websocket support in NFD?
In-Reply-To: <77E2D59A-967C-470F-B777-AA365116B855@ucla.edu>
Message-ID: <D0E7F157.1ADC41%jburke@remap.ucla.edu>

Motivation here is that to use native crypto support emerging in browsers in NDN-JS (with a significant performance gain) requires delivering ndn.js and other elements over TLS.
Jeff

From: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Date: Fri, 23 Jan 2015 12:30:20 -0800
To: Wentao Shang <wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>>
Cc: nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Secure websocket support in NFD?

I think besides the basic support from the library, the actual problem with TLS is necessity to get actual CA-issued certificate and then configure it.
I would suggest not having such support (at least not in the near future).

Things can get relative simple if we integrated with Alex Halderman's https://letsencrypt.org/ here, but it still will only apply to NFD?s that has domain names (e.g., some gateway nodes).

?
Alex

On Jan 23, 2015, at 12:21 PM, Wentao Shang <wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>> wrote:

Hi Jeff T,

The WebSocket library we are using in NFD is 'websocketpp'

http://www.zaphoyd.com/websocketpp

It supports WebSocket over TLS but we haven't added that to NFD yet. If there is consensus that this will be useful, we can add wss support in the next release of NFD (the only issue is to pick a port number for wss server).

Best,
Wentao

On Fri Jan 23 2015 at 10:53:50 AM Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:
Hello NFD team,

If a web page is served over https, and the JavaScript in the web page wants to make a WebSocket connection, then this connection must be over secure WebSocket over TLS (wss). This means that if a web page servered over https needs to communicate with an NFD host, then the WebSocket proxy in NFD needs to support secure WebSocket.

Does the WebSocket library used by NFD support secure TLS connections (wss)?

Thanks,
- Jeff T

_______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150123/69718235/attachment.html>

From shijunxiao at email.arizona.edu  Fri Jan 23 12:46:26 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 23 Jan 2015 13:46:26 -0700
Subject: [Nfd-dev] Secure websocket support in NFD?
In-Reply-To: <D0E7D88A.1AE59%jefft0@remap.ucla.edu>
References: <D0E7D88A.1AE59%jefft0@remap.ucla.edu>
Message-ID: <CAOFH+Obc1CxGQ_wsFCgp8vdrCwZSkPCupW33qZzvxeFwX2Kj9w@mail.gmail.com>

Hi Jeff

An alternate to NFD serving wss directly is to add a frontend TLS=>TCP/HTTP
proxy, such as STunnel or nginx.
But I'm not sure how to configure those.

Yours, Junxiao
On Jan 23, 2015 11:53 AM, "Thompson, Jeff" <jefft0 at remap.ucla.edu> wrote:

>  Hello NFD team,
>
>  If a web page is served over https, and the JavaScript in the web page
> wants to make a WebSocket connection, then this connection must be over
> secure WebSocket over TLS (wss). This means that if a web page servered
> over https needs to communicate with an NFD host, then the WebSocket proxy
> in NFD needs to support secure WebSocket.
>
>  Does the WebSocket library used by NFD support secure TLS connections
> (wss)?
>
>  Thanks,
> - Jeff T
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150123/d2de9dd3/attachment.html>

From ivanyeo at CS.UCLA.EDU  Mon Jan 26 04:27:07 2015
From: ivanyeo at CS.UCLA.EDU (Ivan Yeo)
Date: Mon, 26 Jan 2015 04:27:07 -0800 (PST)
Subject: [Nfd-dev] NFDC Register
Message-ID: <2018379743.32639473.1422275227623.JavaMail.root@cs.ucla.edu>

Hi all,

I ran into some issues when I tried to run the following command on my localhost with NFD running:
nfdc register /ndn tcp4://spurs.cs.ucla.edu/

What I am trying to achieve is to modify the RIB so that I am able to forward the expressed name: /ndn/org/caida/ping/78038.0 through my localhost. However, the error message is shown as such:

ERROR: Face creation failed: Invalid URI (code: 408)
Obtain faceId failure: Canonize faceUri failed : Remote endpoint hostname or port cannot be resolved: Invalid argument

I'm not too sure if I'm missing anything or doing something wrong?

I'll keep looking around for now. Many thanks in advance.

Cheers,
Ivan


From lanwang at memphis.edu  Mon Jan 26 07:00:25 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Mon, 26 Jan 2015 15:00:25 +0000
Subject: [Nfd-dev] NFDC Register
In-Reply-To: <2018379743.32639473.1422275227623.JavaMail.root@cs.ucla.edu>
References: <2018379743.32639473.1422275227623.JavaMail.root@cs.ucla.edu>
Message-ID: <2CDD49F8-5EA0-4322-AAA2-8BFE4140B9FD@memphis.edu>

This is one of the problems Yi Zhuang reported in redmine.

Lan

Sent from my iPhone

> On Jan 26, 2015, at 6:27 AM, Ivan Yeo <ivanyeo at CS.UCLA.EDU> wrote:
> 
> Hi all,
> 
> I ran into some issues when I tried to run the following command on my localhost with NFD running:
> nfdc register /ndn tcp4://spurs.cs.ucla.edu/
> 
> What I am trying to achieve is to modify the RIB so that I am able to forward the expressed name: /ndn/org/caida/ping/78038.0 through my localhost. However, the error message is shown as such:
> 
> ERROR: Face creation failed: Invalid URI (code: 408)
> Obtain faceId failure: Canonize faceUri failed : Remote endpoint hostname or port cannot be resolved: Invalid argument
> 
> I'm not too sure if I'm missing anything or doing something wrong?
> 
> I'll keep looking around for now. Many thanks in advance.
> 
> Cheers,
> Ivan
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev



From lanwang at memphis.EDU  Mon Jan 26 07:37:46 2015
From: lanwang at memphis.EDU (Lan Wang (lanwang))
Date: Mon, 26 Jan 2015 15:37:46 +0000
Subject: [Nfd-dev] NFDC Register
In-Reply-To: <2CDD49F8-5EA0-4322-AAA2-8BFE4140B9FD@memphis.edu>
References: <2018379743.32639473.1422275227623.JavaMail.root@cs.ucla.edu>
	<2CDD49F8-5EA0-4322-AAA2-8BFE4140B9FD@memphis.edu>
Message-ID: <213932FA-3ECE-4F0C-A51A-4B7910F4D42A@memphis.edu>

See http://redmine.named-data.net/issues/1988 (note #30 reported by Yi Huang).

Lan

On Jan 26, 2015, at 9:00 AM, "Lan Wang (lanwang)" <lanwang at memphis.edu>
 wrote:

> This is one of the problems Yi Zhuang reported in redmine.
> 
> Lan
> 
> Sent from my iPhone
> 
>> On Jan 26, 2015, at 6:27 AM, Ivan Yeo <ivanyeo at CS.UCLA.EDU> wrote:
>> 
>> Hi all,
>> 
>> I ran into some issues when I tried to run the following command on my localhost with NFD running:
>> nfdc register /ndn tcp4://spurs.cs.ucla.edu/
>> 
>> What I am trying to achieve is to modify the RIB so that I am able to forward the expressed name: /ndn/org/caida/ping/78038.0 through my localhost. However, the error message is shown as such:
>> 
>> ERROR: Face creation failed: Invalid URI (code: 408)
>> Obtain faceId failure: Canonize faceUri failed : Remote endpoint hostname or port cannot be resolved: Invalid argument
>> 
>> I'm not too sure if I'm missing anything or doing something wrong?
>> 
>> I'll keep looking around for now. Many thanks in advance.
>> 
>> Cheers,
>> Ivan
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From cawka1 at gmail.com  Mon Jan 26 08:35:18 2015
From: cawka1 at gmail.com (Alex Afanasyev)
Date: Mon, 26 Jan 2015 08:35:18 -0800
Subject: [Nfd-dev] NFDC Register
In-Reply-To: <2018379743.32639473.1422275227623.JavaMail.root@cs.ucla.edu>
References: <2018379743.32639473.1422275227623.JavaMail.root@cs.ucla.edu>
Message-ID: <6D6AB415-D986-477F-998F-FBEA1B5CC04D@gmail.com>

You can use a fully qualified FaceURI for now

tcp4://1.1.1.1:6363

---
Alex

> On Jan 26, 2015, at 4:27 AM, Ivan Yeo <ivanyeo at CS.UCLA.EDU> wrote:
> 
> Hi all,
> 
> I ran into some issues when I tried to run the following command on my localhost with NFD running:
> nfdc register /ndn tcp4://spurs.cs.ucla.edu/
> 
> What I am trying to achieve is to modify the RIB so that I am able to forward the expressed name: /ndn/org/caida/ping/78038.0 through my localhost. However, the error message is shown as such:
> 
> ERROR: Face creation failed: Invalid URI (code: 408)
> Obtain faceId failure: Canonize faceUri failed : Remote endpoint hostname or port cannot be resolved: Invalid argument
> 
> I'm not too sure if I'm missing anything or doing something wrong?
> 
> I'll keep looking around for now. Many thanks in advance.
> 
> Cheers,
> Ivan
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2574 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150126/99cefd85/attachment.bin>

From alexander.afanasyev at ucla.edu  Mon Jan 26 11:18:46 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 26 Jan 2015 11:18:46 -0800
Subject: [Nfd-dev] NFDC Register
In-Reply-To: <213932FA-3ECE-4F0C-A51A-4B7910F4D42A@memphis.edu>
References: <2018379743.32639473.1422275227623.JavaMail.root@cs.ucla.edu>
	<2CDD49F8-5EA0-4322-AAA2-8BFE4140B9FD@memphis.edu>
	<213932FA-3ECE-4F0C-A51A-4B7910F4D42A@memphis.edu>
Message-ID: <1042AC28-CEF6-4892-99F8-88F7FF167A57@ucla.edu>


> On Jan 26, 2015, at 7:37 AM, Lan Wang (lanwang) <lanwang at memphis.EDU> wrote:
> 
> See http://redmine.named-data.net/issues/1988 (note #30 reported by Yi Huang).

This specific issue was within the Android environment.

I may have read wrong Ivan's original message.  If you're running **not** within Android, then the error should not exist and its origin needs to be tracked down.  If it is within the Android, then we already may have a solution.

---
Alex

> Lan
> 
> On Jan 26, 2015, at 9:00 AM, "Lan Wang (lanwang)" <lanwang at memphis.edu>
> wrote:
> 
>> This is one of the problems Yi Zhuang reported in redmine.
>> 
>> Lan
>> 
>> Sent from my iPhone
>> 
>>> On Jan 26, 2015, at 6:27 AM, Ivan Yeo <ivanyeo at CS.UCLA.EDU> wrote:
>>> 
>>> Hi all,
>>> 
>>> I ran into some issues when I tried to run the following command on my localhost with NFD running:
>>> nfdc register /ndn tcp4://spurs.cs.ucla.edu/
>>> 
>>> What I am trying to achieve is to modify the RIB so that I am able to forward the expressed name: /ndn/org/caida/ping/78038.0 through my localhost. However, the error message is shown as such:
>>> 
>>> ERROR: Face creation failed: Invalid URI (code: 408)
>>> Obtain faceId failure: Canonize faceUri failed : Remote endpoint hostname or port cannot be resolved: Invalid argument
>>> 
>>> I'm not too sure if I'm missing anything or doing something wrong?
>>> 
>>> I'll keep looking around for now. Many thanks in advance.
>>> 
>>> Cheers,
>>> Ivan
-------------- 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150126/d579bc50/attachment.bin>

From jdd at wustl.edu  Mon Jan 26 13:01:16 2015
From: jdd at wustl.edu (John DeHart)
Date: Mon, 26 Jan 2015 15:01:16 -0600
Subject: [Nfd-dev] What makes nfd grow in size?
Message-ID: <54C6AB1C.3010300@wustl.edu>


All:

I'm having a problem on one of the NDN Testbed nodes with nfd growing
to an unreasonable size.

There is a steady stream of Interests and Data going through it.
I have reduced the size of the CS down to 8K to see if that will
stop the growth but it doesn't seem to.

This is on the Tongji node. The virtual memory size of nfd will
continue to grow until eventually the node will get bogged
down and I have to restart nfd to clear things up.

I include below some ps samples that show the size and the change
in size at 5 second intervals.

What else besides the CS would cause nfd to continue to grow?

I should mention that I am experimenting with tcp faces to try
to alleviate some other network problems.


Thanks,
John


Tue Jan 27 04:48:22 CST 2015
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0  5211     1  20   0 2482116 1618620 ep_pol Ssl ?        8:53 
/usr/bin/nfd --config /etc/ndn/nfd.conf

Tue Jan 27 04:48:27 CST 2015
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0  5211     1  20   0 2488600 1625240 ep_pol Ssl ?        8:55 
/usr/bin/nfd --config /etc/ndn/nfd.conf

Tue Jan 27 04:48:32 CST 2015
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0  5211     1  20   0 2495212 1631896 ep_pol Ssl ?        8:56 
/usr/bin/nfd --config /etc/ndn/nfd.conf

Tue Jan 27 04:48:37 CST 2015
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0  5211     1  20   0 2502084 1608468 ep_pol Ssl ?        8:57 
/usr/bin/nfd --config /etc/ndn/nfd.conf

Tue Jan 27 04:48:42 CST 2015
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0  5211     1  20   0 2509112 1615620 ep_pol Ssl ?        8:59 
/usr/bin/nfd --config /etc/ndn/nfd.conf

Tue Jan 27 04:48:47 CST 2015
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0  5211     1  20   0 2515856 1622520 ep_pol Ssl ?        9:01 
/usr/bin/nfd --config /etc/ndn/nfd.conf


From shijunxiao at email.arizona.edu  Mon Jan 26 13:09:47 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 26 Jan 2015 14:09:47 -0700
Subject: [Nfd-dev] What makes nfd grow in size?
In-Reply-To: <54C6AB1C.3010300@wustl.edu>
References: <54C6AB1C.3010300@wustl.edu>
Message-ID: <CAOFH+Oaz38L5fhHLc2j61ad9EVt4OAq=KmfKcsi1RAZMD8P4Ng@mail.gmail.com>

Hi John

This may or may not be a memory leak.

Please collect the output of `nfd-status -vf` in order to determine whether
a certain table is growing.

Yours, Junxiao

On Mon, Jan 26, 2015 at 2:01 PM, John DeHart <jdd at wustl.edu> wrote:

>
> All:
>
> I'm having a problem on one of the NDN Testbed nodes with nfd growing
> to an unreasonable size.
>
> There is a steady stream of Interests and Data going through it.
> I have reduced the size of the CS down to 8K to see if that will
> stop the growth but it doesn't seem to.
>
> This is on the Tongji node. The virtual memory size of nfd will
> continue to grow until eventually the node will get bogged
> down and I have to restart nfd to clear things up.
>
> I include below some ps samples that show the size and the change
> in size at 5 second intervals.
>
> What else besides the CS would cause nfd to continue to grow?
>
> I should mention that I am experimenting with tcp faces to try
> to alleviate some other network problems.
>
>
> Thanks,
> John
>
>
> Tue Jan 27 04:48:22 CST 2015
> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
> COMMAND
> 4     0  5211     1  20   0 2482116 1618620 ep_pol Ssl ?        8:53
> /usr/bin/nfd --config /etc/ndn/nfd.conf
>
> Tue Jan 27 04:48:27 CST 2015
> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
> COMMAND
> 4     0  5211     1  20   0 2488600 1625240 ep_pol Ssl ?        8:55
> /usr/bin/nfd --config /etc/ndn/nfd.conf
>
> Tue Jan 27 04:48:32 CST 2015
> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
> COMMAND
> 4     0  5211     1  20   0 2495212 1631896 ep_pol Ssl ?        8:56
> /usr/bin/nfd --config /etc/ndn/nfd.conf
>
> Tue Jan 27 04:48:37 CST 2015
> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
> COMMAND
> 4     0  5211     1  20   0 2502084 1608468 ep_pol Ssl ?        8:57
> /usr/bin/nfd --config /etc/ndn/nfd.conf
>
> Tue Jan 27 04:48:42 CST 2015
> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
> COMMAND
> 4     0  5211     1  20   0 2509112 1615620 ep_pol Ssl ?        8:59
> /usr/bin/nfd --config /etc/ndn/nfd.conf
>
> Tue Jan 27 04:48:47 CST 2015
> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
> COMMAND
> 4     0  5211     1  20   0 2515856 1622520 ep_pol Ssl ?        9:01
> /usr/bin/nfd --config /etc/ndn/nfd.conf
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150126/268e74ee/attachment.html>

From jdd at wustl.edu  Mon Jan 26 13:45:56 2015
From: jdd at wustl.edu (John DeHart)
Date: Mon, 26 Jan 2015 15:45:56 -0600
Subject: [Nfd-dev] What makes nfd grow in size?
In-Reply-To: <CAOFH+Oaz38L5fhHLc2j61ad9EVt4OAq=KmfKcsi1RAZMD8P4Ng@mail.gmail.com>
References: <54C6AB1C.3010300@wustl.edu>
	<CAOFH+Oaz38L5fhHLc2j61ad9EVt4OAq=KmfKcsi1RAZMD8P4Ng@mail.gmail.com>
Message-ID: <54C6B594.80600@wustl.edu>


Junxiao,

Here are two snapshots of the counters after the time that the CS fills
and is no longer growing:

Tue Jan 27 05:35:38 CST 2015
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0  8414     1  20   0 1782908 1642192 ?   Rsl  ?          7:15 
/usr/bin/nfd --config /etc/ndn/nfd.conf

General NFD status:
nfdId=/localhost/daemons/nfd/KEY/ksk-1406409442387/ID-CERT
                version=0.2.0-88-gc5173de
              startTime=20150126T210446.307000
            currentTime=20150126T213538.190000
                 uptime=1851 seconds
       nNameTreeEntries=897
            nFibEntries=65
            nPitEntries=434
   nMeasurementsEntries=366
             nCsEntries=8192
           nInInterests=604737
          nOutInterests=317119
               nInDatas=179061
              nOutDatas=319898
--
Tue Jan 27 05:37:17 CST 2015
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0  8414     1  20   0 1926616 1647376 ep_pol Ssl ?        7:48 
/usr/bin/nfd --config /etc/ndn/nfd.conf

General NFD status:
nfdId=/localhost/daemons/nfd/KEY/ksk-1406409442387/ID-CERT
                version=0.2.0-88-gc5173de
              startTime=20150126T210446.307000
            currentTime=20150126T213717.379000
                 uptime=1951 seconds
       nNameTreeEntries=876
            nFibEntries=65
            nPitEntries=397
   nMeasurementsEntries=360
             nCsEntries=8191
           nInInterests=649582
          nOutInterests=340120
               nInDatas=194721
              nOutDatas=349244

I don't see any of the table sizes growing at this point but the nfd VSZ 
continues to grow.

Also, here is the version of nfd I am running on the Testbed.
ndnops at ndnops:~$ nfd --version
0.2.0-88-gc5173de
ndnops at ndnops:~$


Thanks,
John


On 1/26/15 3:09 PM, Junxiao Shi wrote:
> Hi John
>
> This may or may not be a memory leak.
>
> Please collect the output of `nfd-status -vf` in order to determine 
> whether a certain table is growing.
>
> Yours, Junxiao
>
> On Mon, Jan 26, 2015 at 2:01 PM, John DeHart <jdd at wustl.edu 
> <mailto:jdd at wustl.edu>> wrote:
>
>
>     All:
>
>     I'm having a problem on one of the NDN Testbed nodes with nfd growing
>     to an unreasonable size.
>
>     There is a steady stream of Interests and Data going through it.
>     I have reduced the size of the CS down to 8K to see if that will
>     stop the growth but it doesn't seem to.
>
>     This is on the Tongji node. The virtual memory size of nfd will
>     continue to grow until eventually the node will get bogged
>     down and I have to restart nfd to clear things up.
>
>     I include below some ps samples that show the size and the change
>     in size at 5 second intervals.
>
>     What else besides the CS would cause nfd to continue to grow?
>
>     I should mention that I am experimenting with tcp faces to try
>     to alleviate some other network problems.
>
>
>     Thanks,
>     John
>
>
>     Tue Jan 27 04:48:22 CST 2015
>     F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY     TIME
>     COMMAND
>     4     0  5211     1  20   0 2482116 1618620 ep_pol Ssl ?     8:53
>     /usr/bin/nfd --config /etc/ndn/nfd.conf
>
>     Tue Jan 27 04:48:27 CST 2015
>     F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY     TIME
>     COMMAND
>     4     0  5211     1  20   0 2488600 1625240 ep_pol Ssl ?     8:55
>     /usr/bin/nfd --config /etc/ndn/nfd.conf
>
>     Tue Jan 27 04:48:32 CST 2015
>     F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY     TIME
>     COMMAND
>     4     0  5211     1  20   0 2495212 1631896 ep_pol Ssl ?     8:56
>     /usr/bin/nfd --config /etc/ndn/nfd.conf
>
>     Tue Jan 27 04:48:37 CST 2015
>     F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY     TIME
>     COMMAND
>     4     0  5211     1  20   0 2502084 1608468 ep_pol Ssl ?     8:57
>     /usr/bin/nfd --config /etc/ndn/nfd.conf
>
>     Tue Jan 27 04:48:42 CST 2015
>     F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY     TIME
>     COMMAND
>     4     0  5211     1  20   0 2509112 1615620 ep_pol Ssl ?     8:59
>     /usr/bin/nfd --config /etc/ndn/nfd.conf
>
>     Tue Jan 27 04:48:47 CST 2015
>     F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY     TIME
>     COMMAND
>     4     0  5211     1  20   0 2515856 1622520 ep_pol Ssl ?     9:01
>     /usr/bin/nfd --config /etc/ndn/nfd.conf
>     _______________________________________________
>     Nfd-dev mailing list
>     Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
>     http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150126/eafa12cf/attachment.html>

From davide.pesavento at lip6.fr  Mon Jan 26 14:21:28 2015
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Mon, 26 Jan 2015 23:21:28 +0100
Subject: [Nfd-dev] What makes nfd grow in size?
In-Reply-To: <54C6B594.80600@wustl.edu>
References: <54C6AB1C.3010300@wustl.edu>
	<CAOFH+Oaz38L5fhHLc2j61ad9EVt4OAq=KmfKcsi1RAZMD8P4Ng@mail.gmail.com>
	<54C6B594.80600@wustl.edu>
Message-ID: <CADfzvvb5hJzkLuwHoU+rQHR7yJfMVQGs+rGyfCQWB9GGz1p5+Q@mail.gmail.com>

I suggest using valgrind's memcheck and massif tools on the nfd process.

Best,
Davide

On Mon, Jan 26, 2015 at 10:45 PM, John DeHart <jdd at wustl.edu> wrote:
>
> Junxiao,
>
> Here are two snapshots of the counters after the time that the CS fills
> and is no longer growing:
>
> Tue Jan 27 05:35:38 CST 2015
> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
> 4     0  8414     1  20   0 1782908 1642192 ?   Rsl  ?          7:15
> /usr/bin/nfd --config /etc/ndn/nfd.conf
>
> General NFD status:
>                  nfdId=/localhost/daemons/nfd/KEY/ksk-1406409442387/ID-CERT
>                version=0.2.0-88-gc5173de
>              startTime=20150126T210446.307000
>            currentTime=20150126T213538.190000
>                 uptime=1851 seconds
>       nNameTreeEntries=897
>            nFibEntries=65
>            nPitEntries=434
>   nMeasurementsEntries=366
>             nCsEntries=8192
>           nInInterests=604737
>          nOutInterests=317119
>               nInDatas=179061
>              nOutDatas=319898
> --
> Tue Jan 27 05:37:17 CST 2015
> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
> 4     0  8414     1  20   0 1926616 1647376 ep_pol Ssl ?        7:48
> /usr/bin/nfd --config /etc/ndn/nfd.conf
>
> General NFD status:
>                  nfdId=/localhost/daemons/nfd/KEY/ksk-1406409442387/ID-CERT
>                version=0.2.0-88-gc5173de
>              startTime=20150126T210446.307000
>            currentTime=20150126T213717.379000
>                 uptime=1951 seconds
>       nNameTreeEntries=876
>            nFibEntries=65
>            nPitEntries=397
>   nMeasurementsEntries=360
>             nCsEntries=8191
>           nInInterests=649582
>          nOutInterests=340120
>               nInDatas=194721
>              nOutDatas=349244
>
> I don't see any of the table sizes growing at this point but the nfd VSZ
> continues to grow.
>
> Also, here is the version of nfd I am running on the Testbed.
> ndnops at ndnops:~$ nfd --version
> 0.2.0-88-gc5173de
> ndnops at ndnops:~$
>
>
> Thanks,
> John
>
>
>
> On 1/26/15 3:09 PM, Junxiao Shi wrote:
>
> Hi John
>
> This may or may not be a memory leak.
>
> Please collect the output of `nfd-status -vf` in order to determine whether
> a certain table is growing.
>
> Yours, Junxiao
>
> On Mon, Jan 26, 2015 at 2:01 PM, John DeHart <jdd at wustl.edu> wrote:
>>
>>
>> All:
>>
>> I'm having a problem on one of the NDN Testbed nodes with nfd growing
>> to an unreasonable size.
>>
>> There is a steady stream of Interests and Data going through it.
>> I have reduced the size of the CS down to 8K to see if that will
>> stop the growth but it doesn't seem to.
>>
>> This is on the Tongji node. The virtual memory size of nfd will
>> continue to grow until eventually the node will get bogged
>> down and I have to restart nfd to clear things up.
>>
>> I include below some ps samples that show the size and the change
>> in size at 5 second intervals.
>>
>> What else besides the CS would cause nfd to continue to grow?
>>
>> I should mention that I am experimenting with tcp faces to try
>> to alleviate some other network problems.
>>
>>
>> Thanks,
>> John
>>
>>
>> Tue Jan 27 04:48:22 CST 2015
>> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
>> COMMAND
>> 4     0  5211     1  20   0 2482116 1618620 ep_pol Ssl ?        8:53
>> /usr/bin/nfd --config /etc/ndn/nfd.conf
>>
>> Tue Jan 27 04:48:27 CST 2015
>> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
>> COMMAND
>> 4     0  5211     1  20   0 2488600 1625240 ep_pol Ssl ?        8:55
>> /usr/bin/nfd --config /etc/ndn/nfd.conf
>>
>> Tue Jan 27 04:48:32 CST 2015
>> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
>> COMMAND
>> 4     0  5211     1  20   0 2495212 1631896 ep_pol Ssl ?        8:56
>> /usr/bin/nfd --config /etc/ndn/nfd.conf
>>
>> Tue Jan 27 04:48:37 CST 2015
>> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
>> COMMAND
>> 4     0  5211     1  20   0 2502084 1608468 ep_pol Ssl ?        8:57
>> /usr/bin/nfd --config /etc/ndn/nfd.conf
>>
>> Tue Jan 27 04:48:42 CST 2015
>> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
>> COMMAND
>> 4     0  5211     1  20   0 2509112 1615620 ep_pol Ssl ?        8:59
>> /usr/bin/nfd --config /etc/ndn/nfd.conf
>>
>> Tue Jan 27 04:48:47 CST 2015
>> F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME
>> COMMAND
>> 4     0  5211     1  20   0 2515856 1622520 ep_pol Ssl ?        9:01
>> /usr/bin/nfd --config /etc/ndn/nfd.conf
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>


From ivanyeo at CS.UCLA.EDU  Tue Jan 27 02:26:25 2015
From: ivanyeo at CS.UCLA.EDU (Ivan Yeo)
Date: Tue, 27 Jan 2015 02:26:25 -0800 (PST)
Subject: [Nfd-dev] NFDC Register
In-Reply-To: <1042AC28-CEF6-4892-99F8-88F7FF167A57@ucla.edu>
Message-ID: <238892180.32720238.1422354385479.JavaMail.root@cs.ucla.edu>

Hi all,

Thanks for all the help and replies. I finally got it figured out. I left the trailing slash '/' at the end of the command and it cause both an error on this Mac OS X Yosemite 10.10 that I'm running and on the Android as well. Nonetheless, when I removed it, all was fine. I have since been able to use nfdc to append a RIB entry.

The command that works for me now is: nfdc register /ndn tcp4://spurs.cs.ucla.edu

Cheers,
Ivan

----- Original Message -----
From: "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
To: "Lan Wang" <lanwang at memphis.EDU>
Cc: "Ivan Yeo" <ivanyeo at cs.ucla.edu>, "nfd-dev" <nfd-dev at lists.cs.ucla.edu>
Sent: Monday, January 26, 2015 11:18:46 AM
Subject: Re: [Nfd-dev] NFDC Register


> On Jan 26, 2015, at 7:37 AM, Lan Wang (lanwang) <lanwang at memphis.EDU> wrote:
> 
> See http://redmine.named-data.net/issues/1988 (note #30 reported by Yi Huang).

This specific issue was within the Android environment.

I may have read wrong Ivan's original message.  If you're running **not** within Android, then the error should not exist and its origin needs to be tracked down.  If it is within the Android, then we already may have a solution.

---
Alex

> Lan
> 
> On Jan 26, 2015, at 9:00 AM, "Lan Wang (lanwang)" <lanwang at memphis.edu>
> wrote:
> 
>> This is one of the problems Yi Zhuang reported in redmine.
>> 
>> Lan
>> 
>> Sent from my iPhone
>> 
>>> On Jan 26, 2015, at 6:27 AM, Ivan Yeo <ivanyeo at CS.UCLA.EDU> wrote:
>>> 
>>> Hi all,
>>> 
>>> I ran into some issues when I tried to run the following command on my localhost with NFD running:
>>> nfdc register /ndn tcp4://spurs.cs.ucla.edu/
>>> 
>>> What I am trying to achieve is to modify the RIB so that I am able to forward the expressed name: /ndn/org/caida/ping/78038.0 through my localhost. However, the error message is shown as such:
>>> 
>>> ERROR: Face creation failed: Invalid URI (code: 408)
>>> Obtain faceId failure: Canonize faceUri failed : Remote endpoint hostname or port cannot be resolved: Invalid argument
>>> 
>>> I'm not too sure if I'm missing anything or doing something wrong?
>>> 
>>> I'll keep looking around for now. Many thanks in advance.
>>> 
>>> Cheers,
>>> Ivan


From lanwang at memphis.edu  Tue Jan 27 07:35:28 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Tue, 27 Jan 2015 15:35:28 +0000
Subject: [Nfd-dev] NFDC Register
In-Reply-To: <238892180.32720238.1422354385479.JavaMail.root@cs.ucla.edu>
References: <238892180.32720238.1422354385479.JavaMail.root@cs.ucla.edu>
Message-ID: <724EE4F2-73DC-4CE3-92B9-082426981FE3@memphis.EDU>

Maybe the function that canonizes faceUri needs to remove the trailing /?

Lan

On Jan 27, 2015, at 4:26 AM, Ivan Yeo <ivanyeo at CS.UCLA.EDU> wrote:

> Hi all,
> 
> Thanks for all the help and replies. I finally got it figured out. I left the trailing slash '/' at the end of the command and it cause both an error on this Mac OS X Yosemite 10.10 that I'm running and on the Android as well. Nonetheless, when I removed it, all was fine. I have since been able to use nfdc to append a RIB entry.
> 
> The command that works for me now is: nfdc register /ndn tcp4://spurs.cs.ucla.edu
> 
> Cheers,
> Ivan
> 
> ----- Original Message -----
> From: "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
> To: "Lan Wang" <lanwang at memphis.EDU>
> Cc: "Ivan Yeo" <ivanyeo at cs.ucla.edu>, "nfd-dev" <nfd-dev at lists.cs.ucla.edu>
> Sent: Monday, January 26, 2015 11:18:46 AM
> Subject: Re: [Nfd-dev] NFDC Register
> 
> 
>> On Jan 26, 2015, at 7:37 AM, Lan Wang (lanwang) <lanwang at memphis.EDU> wrote:
>> 
>> See http://redmine.named-data.net/issues/1988 (note #30 reported by Yi Huang).
> 
> This specific issue was within the Android environment.
> 
> I may have read wrong Ivan's original message.  If you're running **not** within Android, then the error should not exist and its origin needs to be tracked down.  If it is within the Android, then we already may have a solution.
> 
> ---
> Alex
> 
>> Lan
>> 
>> On Jan 26, 2015, at 9:00 AM, "Lan Wang (lanwang)" <lanwang at memphis.edu>
>> wrote:
>> 
>>> This is one of the problems Yi Zhuang reported in redmine.
>>> 
>>> Lan
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Jan 26, 2015, at 6:27 AM, Ivan Yeo <ivanyeo at CS.UCLA.EDU> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I ran into some issues when I tried to run the following command on my localhost with NFD running:
>>>> nfdc register /ndn tcp4://spurs.cs.ucla.edu/
>>>> 
>>>> What I am trying to achieve is to modify the RIB so that I am able to forward the expressed name: /ndn/org/caida/ping/78038.0 through my localhost. However, the error message is shown as such:
>>>> 
>>>> ERROR: Face creation failed: Invalid URI (code: 408)
>>>> Obtain faceId failure: Canonize faceUri failed : Remote endpoint hostname or port cannot be resolved: Invalid argument
>>>> 
>>>> I'm not too sure if I'm missing anything or doing something wrong?
>>>> 
>>>> I'll keep looking around for now. Many thanks in advance.
>>>> 
>>>> Cheers,
>>>> Ivan




From shijunxiao at email.ARIZONA.EDU  Tue Jan 27 07:41:58 2015
From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi)
Date: Tue, 27 Jan 2015 08:41:58 -0700
Subject: [Nfd-dev] NFDC Register
In-Reply-To: <724EE4F2-73DC-4CE3-92B9-082426981FE3@memphis.EDU>
References: <238892180.32720238.1422354385479.JavaMail.root@cs.ucla.edu>
	<724EE4F2-73DC-4CE3-92B9-082426981FE3@memphis.EDU>
Message-ID: <CAOFH+OaKuLf_YBjXgmiD+_GLHOUxpzDwXr09CvmsEEKZJJm_Ag@mail.gmail.com>

Hi Lan

There's already a test case for trailing slash:
    addTest("udp4://192.0.2.4:6363/", true, "udp4://192.0.2.4:6363");
But there's no test case with DNS resolution + trailing slash.

Please report a bug on Redmine.

Yours, Junxiao

On Jan 27, 2015 8:35 AM, "Lan Wang (lanwang)" <lanwang at memphis.edu> wrote:
>
> Maybe the function that canonizes faceUri needs to remove the trailing /?
>
> Lan
>
> On Jan 27, 2015, at 4:26 AM, Ivan Yeo <ivanyeo at CS.UCLA.EDU> wrote:
>
> > Hi all,
> >
> > Thanks for all the help and replies. I finally got it figured out. I
left the trailing slash '/' at the end of the command and it cause both an
error on this Mac OS X Yosemite 10.10 that I'm running and on the Android
as well. Nonetheless, when I removed it, all was fine. I have since been
able to use nfdc to append a RIB entry.
> >
> > The command that works for me now is: nfdc register /ndn tcp4://
spurs.cs.ucla.edu
> >
> > Cheers,
> > Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150127/1aaf1796/attachment.html>

From afanasev at CS.UCLA.EDU  Tue Jan 27 09:10:26 2015
From: afanasev at CS.UCLA.EDU (Alex Afanasyev)
Date: Tue, 27 Jan 2015 09:10:26 -0800
Subject: [Nfd-dev] NFDC Register
In-Reply-To: <CAOFH+OaKuLf_YBjXgmiD+_GLHOUxpzDwXr09CvmsEEKZJJm_Ag@mail.gmail.com>
References: <238892180.32720238.1422354385479.JavaMail.root@cs.ucla.edu>
	<724EE4F2-73DC-4CE3-92B9-082426981FE3@memphis.EDU>
	<CAOFH+OaKuLf_YBjXgmiD+_GLHOUxpzDwXr09CvmsEEKZJJm_Ag@mail.gmail.com>
Message-ID: <C656E60D-A8C6-4F77-95C8-7FAE8DEC8262@cs.ucla.edu>

I cannot reproduce this problem on my macbook.

Ivan, can you show us the exact command that resulted in the error?

I tried

    nfdc register /ndn/ tcp4://spurs.cs.ucla.edu/ <tcp4://spurs.cs.ucla.edu/>

and 

    nfdc register /ndn udp://spurs.cs.ucla.edu/ <udp://spurs.cs.ucla.edu/>

Both succeeded, as expected

?
Alex

> On Jan 27, 2015, at 7:41 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Lan
> 
> There's already a test case for trailing slash:
>     addTest("udp4://192.0.2.4:6363/ <http://192.0.2.4:6363/>", true, "udp4://192.0.2.4:6363 <http://192.0.2.4:6363/>");
> But there's no test case with DNS resolution + trailing slash.
> 
> Please report a bug on Redmine.
> 
> Yours, Junxiao
> 
> On Jan 27, 2015 8:35 AM, "Lan Wang (lanwang)" <lanwang at memphis.edu <mailto:lanwang at memphis.edu>> wrote:
> >
> > Maybe the function that canonizes faceUri needs to remove the trailing /?
> >
> > Lan
> >
> > On Jan 27, 2015, at 4:26 AM, Ivan Yeo <ivanyeo at CS.UCLA.EDU <mailto:ivanyeo at CS.UCLA.EDU>> wrote:
> >
> > > Hi all,
> > >
> > > Thanks for all the help and replies. I finally got it figured out. I left the trailing slash '/' at the end of the command and it cause both an error on this Mac OS X Yosemite 10.10 that I'm running and on the Android as well. Nonetheless, when I removed it, all was fine. I have since been able to use nfdc to append a RIB entry.
> > >
> > > The command that works for me now is: nfdc register /ndn tcp4://spurs.cs.ucla.edu <http://spurs.cs.ucla.edu/>
> > >
> > > Cheers,
> > > Ivan
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150127/de1daab3/attachment.html>

From shijunxiao at email.arizona.edu  Tue Jan 27 14:26:27 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 27 Jan 2015 15:26:27 -0700
Subject: [Nfd-dev] review request: tunnel authentication protocol
Message-ID: <CAOFH+OYHFi8NhmWVoheNEA4CdV1Og-mWvsZRdJ+S8Tyq5U8gmg@mail.gmail.com>

Dear folks

I have written the high-level ideas about NFD tunnel authentication
protocol, and I need someone to review the design.

http://redmine.named-data.net/attachments/download/174/tunnel-auth_20141118.pptx

If you do not yet know what tunnel authentication protocol is, please see:
http://redmine.named-data.net/issues/1285#note-1

If you are willing to have a look at the design, I'll appreciate that.
You don't have to be an expert in order to do a design review.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150127/4720d0ca/attachment.html>

From Marc.Mosko at parc.com  Tue Jan 27 14:56:46 2015
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Tue, 27 Jan 2015 22:56:46 +0000
Subject: [Nfd-dev] review request: tunnel authentication protocol
In-Reply-To: <CAOFH+OYHFi8NhmWVoheNEA4CdV1Og-mWvsZRdJ+S8Tyq5U8gmg@mail.gmail.com>
References: <CAOFH+OYHFi8NhmWVoheNEA4CdV1Og-mWvsZRdJ+S8Tyq5U8gmg@mail.gmail.com>
Message-ID: <10FEE343-DE4A-4291-87BB-296BBCB7A275@parc.com>

You might want to look at the DTLS handshake https://tools.ietf.org/html/rfc6347.  There?s a lot of gotchas in negotiating a security relationship.

Marc

On Jan 27, 2015, at 2:26 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Dear folks

I have written the high-level ideas about NFD tunnel authentication protocol, and I need someone to review the design.

http://redmine.named-data.net/attachments/download/174/tunnel-auth_20141118.pptx

If you do not yet know what tunnel authentication protocol is, please see: http://redmine.named-data.net/issues/1285#note-1

If you are willing to have a look at the design, I'll appreciate that.
You don't have to be an expert in order to do a design review.

Yours, Junxiao
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150127/a21d438e/attachment.html>

From ivanyeo at CS.UCLA.EDU  Tue Jan 27 21:12:11 2015
From: ivanyeo at CS.UCLA.EDU (Ivan Yeo)
Date: Tue, 27 Jan 2015 21:12:11 -0800 (PST)
Subject: [Nfd-dev] NFDC Register
In-Reply-To: <C656E60D-A8C6-4F77-95C8-7FAE8DEC8262@cs.ucla.edu>
Message-ID: <880943169.32795458.1422421930972.JavaMail.root@cs.ucla.edu>

Hi Alex,

The exact command that I used is: nfdc register /ndn/ tcp4://spurs.cs.ucla.edu/

This has the trailing slash '/' and does not work on my system. However, if I remove the trailing slash '/', it all works fine. I am not too sure if this is the same test case that Junxiao pointed out that is failing. It's not too much of an issue right now. Do let me know if you'd like me to file a bug report Alex.

Cheers,
Ivan

----- Original Message -----
From: "Alex Afanasyev" <afanasev at CS.UCLA.EDU>
To: "Junxiao Shi" <shijunxiao at email.arizona.edu>
Cc: "<nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu>
Sent: Tuesday, January 27, 2015 9:10:26 AM
Subject: Re: [Nfd-dev] NFDC Register


I cannot reproduce this problem on my macbook. 


Ivan, can you show us the exact command that resulted in the error? 


I tried 


nfdc register /ndn/ tcp4://spurs.cs.ucla.edu/ 


and 


nfdc register /ndn udp://spurs.cs.ucla.edu/ 


Both succeeded, as expected 


? 
Alex 






On Jan 27, 2015, at 7:41 AM, Junxiao Shi < shijunxiao at email.arizona.edu > wrote: 



Hi Lan 

There's already a test case for trailing slash: 
addTest("udp4:// 192.0.2.4:6363/ ", true, "udp4:// 192.0.2.4:6363 "); 
But there's no test case with DNS resolution + trailing slash. 

Please report a bug on Redmine. 

Yours, Junxiao 

On Jan 27, 2015 8:35 AM, "Lan Wang (lanwang)" < lanwang at memphis.edu > wrote: 
> 
> Maybe the function that canonizes faceUri needs to remove the trailing /? 
> 
> Lan 
> 
> On Jan 27, 2015, at 4:26 AM, Ivan Yeo < ivanyeo at CS.UCLA.EDU > wrote: 
> 
> > Hi all, 
> > 
> > Thanks for all the help and replies. I finally got it figured out. I left the trailing slash '/' at the end of the command and it cause both an error on this Mac OS X Yosemite 10.10 that I'm running and on the Android as well. Nonetheless, when I removed it, all was fine. I have since been able to use nfdc to append a RIB entry. 
> > 
> > The command that works for me now is: nfdc register /ndn tcp4:// spurs.cs.ucla.edu 
> > 
> > Cheers, 
> > Ivan 

_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev



From shijunxiao at email.arizona.edu  Tue Jan 27 21:33:25 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 27 Jan 2015 22:33:25 -0700
Subject: [Nfd-dev] Secure websocket support in NFD?
In-Reply-To: <CAOFH+Obc1CxGQ_wsFCgp8vdrCwZSkPCupW33qZzvxeFwX2Kj9w@mail.gmail.com>
References: <D0E7D88A.1AE59%jefft0@remap.ucla.edu>
	<CAOFH+Obc1CxGQ_wsFCgp8vdrCwZSkPCupW33qZzvxeFwX2Kj9w@mail.gmail.com>
Message-ID: <CAOFH+OYtjKWOJAVrRDuHaTm3KtEputq=UFfbgtEZQ4oJYsftKA@mail.gmail.com>

Dear folks

It's quite easy to add a wss=>ws proxy. Here's how:

1. Assume you already have a working HTTPS website on nginx.

2. Edit /etc/nginx/sites-enabled/https-site
Put the following at the top of this file:

map $http_upgrade $connection_upgrade {
  default upgrade;
  '' close;
}

Put the following inside 'server' section:

  location /NFD {
    proxy_pass http://[2001:db8::1]:9696;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
  }

Substitute 2001:db9::1 with the IP address of NFD. I only tested IPv6.

3. Edit ndn.js:
Look for 'new WebSocket', and change the parameter into:

connectionInfo.wsuri || ('ws://' + connectionInfo.host + ':' +
connectionInfo.port)


4. Edit web app:
Change "new Face({ host:'nfd.example.com', port:9696 })" to "new Face({
wsuri:'wss://secure.example.com/NFD' })".

Yours, Junxiao

On Fri, Jan 23, 2015 at 1:46 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Jeff
>
> An alternate to NFD serving wss directly is to add a frontend
> TLS=>TCP/HTTP proxy, such as STunnel or nginx.
> But I'm not sure how to configure those.
>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150127/4c748496/attachment.html>

From alexander.afanasyev at ucla.edu  Tue Jan 27 23:30:45 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Tue, 27 Jan 2015 23:30:45 -0800
Subject: [Nfd-dev] Secure websocket support in NFD?
In-Reply-To: <CAOFH+OYtjKWOJAVrRDuHaTm3KtEputq=UFfbgtEZQ4oJYsftKA@mail.gmail.com>
References: <D0E7D88A.1AE59%jefft0@remap.ucla.edu>
	<CAOFH+Obc1CxGQ_wsFCgp8vdrCwZSkPCupW33qZzvxeFwX2Kj9w@mail.gmail.com>
	<CAOFH+OYtjKWOJAVrRDuHaTm3KtEputq=UFfbgtEZQ4oJYsftKA@mail.gmail.com>
Message-ID: <D41D76F8-5E33-49AE-B348-23D50C67B694@ucla.edu>

Junxiao, can you make a wiki page with these instructions?

?
Alex

> On Jan 27, 2015, at 9:33 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Dear folks
> 
> It's quite easy to add a wss=>ws proxy. Here's how:
> 
> 1. Assume you already have a working HTTPS website on nginx.
> 
> 2. Edit /etc/nginx/sites-enabled/https-site
> Put the following at the top of this file:
> map $http_upgrade $connection_upgrade {
>   default upgrade;
>   '' close;
> }
> Put the following inside 'server' section:
>   location /NFD {
>     proxy_pass http://[2001:db8::1]:9696;
>     proxy_http_version 1.1;
>     proxy_set_header Upgrade $http_upgrade;
>     proxy_set_header Connection "Upgrade";
>   }
> Substitute 2001:db9::1 with the IP address of NFD. I only tested IPv6.
> 
> 3. Edit ndn.js:
> Look for 'new WebSocket', and change the parameter into:
> connectionInfo.wsuri || ('ws://' + connectionInfo.host + ':' + connectionInfo.port)
> 
> 4. Edit web app:
> Change "new Face({ host:'nfd.example.com <http://nfd.example.com/>', port:9696 })" to "new Face({ wsuri:'wss://secure.example.com/NFD <http://secure.example.com/NFD>' })".
> 
> Yours, Junxiao
> 
> On Fri, Jan 23, 2015 at 1:46 PM, Junxiao Shi <shijunxiao at email.arizona.edu <mailto:shijunxiao at email.arizona.edu>> wrote:
> Hi Jeff
> 
> An alternate to NFD serving wss directly is to add a frontend TLS=>TCP/HTTP proxy, such as STunnel or nginx.
> But I'm not sure how to configure those.
> 
> Yours, Junxiao
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150127/399cc007/attachment.html>
-------------- 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150127/399cc007/attachment.bin>

From mjs at cisco.com  Wed Jan 28 06:32:39 2015
From: mjs at cisco.com (Mark Stapp)
Date: Wed, 28 Jan 2015 09:32:39 -0500
Subject: [Nfd-dev] review request: tunnel authentication protocol
In-Reply-To: <CAOFH+OYHFi8NhmWVoheNEA4CdV1Og-mWvsZRdJ+S8Tyq5U8gmg@mail.gmail.com>
References: <CAOFH+OYHFi8NhmWVoheNEA4CdV1Og-mWvsZRdJ+S8Tyq5U8gmg@mail.gmail.com>
Message-ID: <54C8F307.4090409@cisco.com>

hmm - having looked at the ppt, there are still a lot of questions - 
it's not clear that there's enough info in the slides to understand what 
is actually proposed.

what do you mean by the word "tunnel"? is there some encap being 
discussed somewhere that will be used? or do you mean "tcp connection"? 
or do you mean "udp packets from some specific source IP+port tuple"?

is there any MAC/MIC proposed? if so, how does it work?

if there's no MAC, nothing's stopping packet injection, right? if 
there's no MAC, what prevents DOS-ing the tunnel by just sending a bad 
"request" message?

what about fragments - who fragments what, and how is the threat of 
fragment injection handled?

what about replay attacks?

I take it there's some magic happening somewhere that allows every 
router to know the acceptable public key for every valid "client" ?

above all, as Marc M asked, if you're using IP, why not just use a TLS 
or dTLS tunnel with mutual auth? that would even add privacy, which 
would not be a bad thing at all for NDN to consider.

Thanks,
Mark

On 1/27/15 5:26 PM, Junxiao Shi wrote:
> Dear folks
>
> I have written the high-level ideas about NFD tunnel authentication
> protocol, and I need someone to review the design.
>
> http://redmine.named-data.net/attachments/download/174/tunnel-auth_20141118.pptx
>
> If you do not yet know what tunnel authentication protocol is, please
> see: http://redmine.named-data.net/issues/1285#note-1
>
> If you are willing to have a look at the design, I'll appreciate that.
> You don't have to be an expert in order to do a design review.
>
> Yours, Junxiao
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>


From lanwang at memphis.edu  Wed Jan 28 07:12:49 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 28 Jan 2015 15:12:49 +0000
Subject: [Nfd-dev] NFDC Register
In-Reply-To: <880943169.32795458.1422421930972.JavaMail.root@cs.ucla.edu>
References: <880943169.32795458.1422421930972.JavaMail.root@cs.ucla.edu>
Message-ID: <87D63F34-D1BB-46A4-95E7-942A49701F3C@memphis.edu>

Maybe you are not using the latest nfd and cxx code?

Lan

On Jan 27, 2015, at 11:12 PM, Ivan Yeo <ivanyeo at CS.UCLA.EDU> wrote:

> Hi Alex,
> 
> The exact command that I used is: nfdc register /ndn/ tcp4://spurs.cs.ucla.edu/
> 
> This has the trailing slash '/' and does not work on my system. However, if I remove the trailing slash '/', it all works fine. I am not too sure if this is the same test case that Junxiao pointed out that is failing. It's not too much of an issue right now. Do let me know if you'd like me to file a bug report Alex.
> 
> Cheers,
> Ivan
> 
> ----- Original Message -----
> From: "Alex Afanasyev" <afanasev at CS.UCLA.EDU>
> To: "Junxiao Shi" <shijunxiao at email.arizona.edu>
> Cc: "<nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu>
> Sent: Tuesday, January 27, 2015 9:10:26 AM
> Subject: Re: [Nfd-dev] NFDC Register
> 
> 
> I cannot reproduce this problem on my macbook. 
> 
> 
> Ivan, can you show us the exact command that resulted in the error? 
> 
> 
> I tried 
> 
> 
> nfdc register /ndn/ tcp4://spurs.cs.ucla.edu/ 
> 
> 
> and 
> 
> 
> nfdc register /ndn udp://spurs.cs.ucla.edu/ 
> 
> 
> Both succeeded, as expected 
> 
> 
> ? 
> Alex 
> 
> 
> 
> 
> 
> 
> On Jan 27, 2015, at 7:41 AM, Junxiao Shi < shijunxiao at email.arizona.edu > wrote: 
> 
> 
> 
> Hi Lan 
> 
> There's already a test case for trailing slash: 
> addTest("udp4:// 192.0.2.4:6363/ ", true, "udp4:// 192.0.2.4:6363 "); 
> But there's no test case with DNS resolution + trailing slash. 
> 
> Please report a bug on Redmine. 
> 
> Yours, Junxiao 
> 
> On Jan 27, 2015 8:35 AM, "Lan Wang (lanwang)" < lanwang at memphis.edu > wrote: 
>> 
>> Maybe the function that canonizes faceUri needs to remove the trailing /? 
>> 
>> Lan 
>> 
>> On Jan 27, 2015, at 4:26 AM, Ivan Yeo < ivanyeo at CS.UCLA.EDU > wrote: 
>> 
>>> Hi all, 
>>> 
>>> Thanks for all the help and replies. I finally got it figured out. I left the trailing slash '/' at the end of the command and it cause both an error on this Mac OS X Yosemite 10.10 that I'm running and on the Android as well. Nonetheless, when I removed it, all was fine. I have since been able to use nfdc to append a RIB entry. 
>>> 
>>> The command that works for me now is: nfdc register /ndn tcp4:// spurs.cs.ucla.edu 
>>> 
>>> Cheers, 
>>> Ivan 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From Marc.Mosko at parc.com  Wed Jan 28 09:33:40 2015
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Wed, 28 Jan 2015 17:33:40 +0000
Subject: [Nfd-dev] review request: tunnel authentication protocol
In-Reply-To: <54C8F307.4090409@cisco.com>
References: <CAOFH+OYHFi8NhmWVoheNEA4CdV1Og-mWvsZRdJ+S8Tyq5U8gmg@mail.gmail.com>
	<54C8F307.4090409@cisco.com>
Message-ID: <C8757C84-8979-4E10-B9DA-F4A8DB353DEC@parc.com>

Just to clarify, I didn?t mean that you should use DTLS (though I wouldn?t argue against that), but only that the DTLS RFC spells out many of the things one needs to do about replay attacks, IP fragmentation issues, and so forth, in establishing a cryptographic association, even if there is no encryption of the channel.  I agree with Mark S that if you do not include a MAC in each packet, there?s no on-going assurance.  And using a MAC means you negotiate session keys and then signing keys, so you might as well do DTLS.  DOCSIS does a similar thing too.

You could also look at the history of GRE tunnels (https://tools.ietf.org/html/rfc2784 and then https://tools.ietf.org/html/rfc2890). RFC 2890 says that one must use IPSec with the tunnel (either ESP or simple AH), especially if using the sequence number to re-order tunnel packets due to DoS issues with the re-order buffer.  Note that the Key field in GRE is really a flow label, not a security mechanism.

In DTLS, there is on-going authentication and the connection is identified by a session ID that only the holder of the parties certificate keys can use.

In your proposal, I think it suffers from a man in the middle attack: Alice - Eve - Bob.  Alice sends a signed interest, Eve intercepts it and now sends the packet to Bob with her socket endpoint.  Bob accepts the packet as from alice and opens a tunnel with Eve.  There?s nothing in the signed envelope that restricts the tunnel to Alice nor anything encrypted that requires Eve to have Alice?s of Bob?s key.  For example, if Alice included her socket endpoint in the signed information that would preclude this specific attack, but that?s not a proof that it?s sufficient for secure association.  If there?s no MAC, Eve could still inject packets as a MITM.  Generally one needs a handshake where each party proves they actually have the keys purported through a multi-round protocol (which could have a quick-resume).

I?m not a cryptographer, and this is the type of thing you want a cryptographer working on.  Or use a protocol that?s been vetted.

Marc


On Jan 28, 2015, at 6:32 AM, Mark Stapp <mjs at cisco.com> wrote:

> hmm - having looked at the ppt, there are still a lot of questions - it's not clear that there's enough info in the slides to understand what is actually proposed.
> 
> what do you mean by the word "tunnel"? is there some encap being discussed somewhere that will be used? or do you mean "tcp connection"? or do you mean "udp packets from some specific source IP+port tuple"?
> 
> is there any MAC/MIC proposed? if so, how does it work?
> 
> if there's no MAC, nothing's stopping packet injection, right? if there's no MAC, what prevents DOS-ing the tunnel by just sending a bad "request" message?
> 
> what about fragments - who fragments what, and how is the threat of fragment injection handled?
> 
> what about replay attacks?
> 
> I take it there's some magic happening somewhere that allows every router to know the acceptable public key for every valid "client" ?
> 
> above all, as Marc M asked, if you're using IP, why not just use a TLS or dTLS tunnel with mutual auth? that would even add privacy, which would not be a bad thing at all for NDN to consider.
> 
> Thanks,
> Mark
> 
> On 1/27/15 5:26 PM, Junxiao Shi wrote:
>> Dear folks
>> 
>> I have written the high-level ideas about NFD tunnel authentication
>> protocol, and I need someone to review the design.
>> 
>> http://redmine.named-data.net/attachments/download/174/tunnel-auth_20141118.pptx
>> 
>> If you do not yet know what tunnel authentication protocol is, please
>> see: http://redmine.named-data.net/issues/1285#note-1
>> 
>> If you are willing to have a look at the design, I'll appreciate that.
>> You don't have to be an expert in order to do a design review.
>> 
>> Yours, Junxiao
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From shijunxiao at email.arizona.edu  Wed Jan 28 17:34:19 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 28 Jan 2015 18:34:19 -0700
Subject: [Nfd-dev] ndn-cxx deprecated feature removal: Block(std::istream&)
	constructor
Message-ID: <CAOFH+OaY6wyJ-OPw52ova1GvjQEck2o2N=CwJjO8nKTx_rPF1g@mail.gmail.com>

Dear folks

The following deprecated feature will be removed from ndn-cxx soon:
Block(std::istream&) constructor

If you have code that depend on this feature and cannot be fixed now,
please reply no later than Feb 02 12:00 UTC.
Otherwise, we'll proceed with the removal after that time.

You can compile your projects with ndn-cxx Change
http://gerrit.named-data.net/1687 and verify it works.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150128/012ba8b0/attachment.html>

From ivanyeo at CS.UCLA.EDU  Wed Jan 28 17:40:55 2015
From: ivanyeo at CS.UCLA.EDU (Ivan Yeo)
Date: Wed, 28 Jan 2015 17:40:55 -0800
Subject: [Nfd-dev] NFDC Register
In-Reply-To: <87D63F34-D1BB-46A4-95E7-942A49701F3C@memphis.edu>
References: <880943169.32795458.1422421930972.JavaMail.root@cs.ucla.edu>
	<87D63F34-D1BB-46A4-95E7-942A49701F3C@memphis.edu>
Message-ID: <BB6D7B62-35B6-423B-ADB2-E3B086C17A2F@cs.ucla.edu>

Oh, was there something that changed? Let me get the new code and give it a try :)

Thanks for the heads up!

> On Jan 28, 2015, at 7:12 AM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:
> 
> Maybe you are not using the latest nfd and cxx code?
> 
> Lan
> 
> On Jan 27, 2015, at 11:12 PM, Ivan Yeo <ivanyeo at CS.UCLA.EDU> wrote:
> 
>> Hi Alex,
>> 
>> The exact command that I used is: nfdc register /ndn/ tcp4://spurs.cs.ucla.edu/
>> 
>> This has the trailing slash '/' and does not work on my system. However, if I remove the trailing slash '/', it all works fine. I am not too sure if this is the same test case that Junxiao pointed out that is failing. It's not too much of an issue right now. Do let me know if you'd like me to file a bug report Alex.
>> 
>> Cheers,
>> Ivan
>> 
>> ----- Original Message -----
>> From: "Alex Afanasyev" <afanasev at CS.UCLA.EDU>
>> To: "Junxiao Shi" <shijunxiao at email.arizona.edu>
>> Cc: "<nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu>
>> Sent: Tuesday, January 27, 2015 9:10:26 AM
>> Subject: Re: [Nfd-dev] NFDC Register
>> 
>> 
>> I cannot reproduce this problem on my macbook. 
>> 
>> 
>> Ivan, can you show us the exact command that resulted in the error? 
>> 
>> 
>> I tried 
>> 
>> 
>> nfdc register /ndn/ tcp4://spurs.cs.ucla.edu/ 
>> 
>> 
>> and 
>> 
>> 
>> nfdc register /ndn udp://spurs.cs.ucla.edu/ 
>> 
>> 
>> Both succeeded, as expected 
>> 
>> 
>> ? 
>> Alex 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Jan 27, 2015, at 7:41 AM, Junxiao Shi < shijunxiao at email.arizona.edu > wrote: 
>> 
>> 
>> 
>> Hi Lan 
>> 
>> There's already a test case for trailing slash: 
>> addTest("udp4:// 192.0.2.4:6363/ ", true, "udp4:// 192.0.2.4:6363 "); 
>> But there's no test case with DNS resolution + trailing slash. 
>> 
>> Please report a bug on Redmine. 
>> 
>> Yours, Junxiao 
>> 
>> On Jan 27, 2015 8:35 AM, "Lan Wang (lanwang)" < lanwang at memphis.edu > wrote: 
>>> 
>>> Maybe the function that canonizes faceUri needs to remove the trailing /? 
>>> 
>>> Lan 
>>> 
>>> On Jan 27, 2015, at 4:26 AM, Ivan Yeo < ivanyeo at CS.UCLA.EDU > wrote: 
>>> 
>>>> Hi all, 
>>>> 
>>>> Thanks for all the help and replies. I finally got it figured out. I left the trailing slash '/' at the end of the command and it cause both an error on this Mac OS X Yosemite 10.10 that I'm running and on the Android as well. Nonetheless, when I removed it, all was fine. I have since been able to use nfdc to append a RIB entry. 
>>>> 
>>>> The command that works for me now is: nfdc register /ndn tcp4:// spurs.cs.ucla.edu 
>>>> 
>>>> Cheers, 
>>>> Ivan 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 




From lanwang at memphis.edu  Thu Jan 29 11:35:22 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Thu, 29 Jan 2015 19:35:22 +0000
Subject: [Nfd-dev] smart flooding strategy
Message-ID: <5456163B-197E-4CD0-BDC2-6894D3A7A1CC@memphis.edu>

Junxiao,

Can I use the access router strategy (http://redmine.named-data.net/issues/1999) at every node (not just the access router) to implement essentially smart flooding?  Basically, I want the following strategy: 

1. The first time an Interest is received, the Interest will be sent to all the faces of the node except the incoming face.  

2. When the matching Data packet comes back, the face that brings back the data will be remembered.

3. subsequent Interests to this face will use the remembered face.

4. If no Data comes back, send subsequent Interests to all faces.

Since you implemented the access router strategy, I'm wondering if you think there's any potential problems with this.  Also in your design, you exclude the last working nexthop.  I'm not sure if this is necessary (it doesn't hurt to try it again). 

Lan




From lanwang at memphis.edu  Thu Jan 29 11:38:34 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Thu, 29 Jan 2015 19:38:34 +0000
Subject: [Nfd-dev] smart flooding strategy
In-Reply-To: <5456163B-197E-4CD0-BDC2-6894D3A7A1CC@memphis.edu>
References: <5456163B-197E-4CD0-BDC2-6894D3A7A1CC@memphis.edu>
Message-ID: <9D016654-6571-456C-810E-F0460CCEBB3E@memphis.edu>


On Jan 29, 2015, at 1:35 PM, "Lan Wang (lanwang)" <lanwang at memphis.edu>
 wrote:

> Junxiao,
> 
> Can I use the access router strategy (http://redmine.named-data.net/issues/1999) at every node (not just the access router) to implement essentially smart flooding?  Basically, I want the following strategy: 
> 
> 1. The first time an Interest is received, the Interest will be sent to all the faces of the node except the incoming face.  
> 
> 2. When the matching Data packet comes back, the face that brings back the data will be remembered.
> 
> 3. subsequent Interests to this face will use the remembered face.

I meant "to this node".
> 
> 4. If no Data comes back, send subsequent Interests to all faces.
> 
> Since you implemented the access router strategy, I'm wondering if you think there's any potential problems with this.  Also in your design, you exclude the last working next hop.  

In step 4.

> I'm not sure if this is necessary (it doesn't hurt to try it again). 
> 
> Lan
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From peter at remap.UCLA.EDU  Thu Jan 29 18:56:43 2015
From: peter at remap.UCLA.EDU (Gusev, Peter)
Date: Fri, 30 Jan 2015 02:56:43 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <82C9DE44-8E98-413B-8B62-2BB3FA7F9FEE@remap.ucla.edu>
References: <82C9DE44-8E98-413B-8B62-2BB3FA7F9FEE@remap.ucla.edu>
Message-ID: <FF26AA9A-F092-469B-9B5E-6F3F10CF64CB@remap.ucla.edu>

Hi all,

I?m doing tests and explorations on the reasons, why does NdnCon experience rebufferings (i.e. interruptions in video stream which lead to algorithm restart).
I would appreciate any help/suggestions/advices in debugging/analyzing NFD logs and NFD itself.

More specifically, I?d like to hear your comments on the following case.
With the same configuration as before ([Consumer] <?> [NFD1] <==Ethernet_link==> [NFD2] <==Ethernet_link==> [NFD3] <?> [Producer]) consumer experienced interruption after getting frame 640. So I tracked down frame?s 641 interests and data in NFD logs:

NFD1 log: ($ cat consumer/nfd.log | grep "/641/data/%00%00?)

1422581555.423600 DEBUG: [Forwarder] onIncomingInterest face=265 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.423943 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.424205 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=1282205730 from=265 newPitEntry-to=259
^ 294ms (retransmission, confirmed by consumer log)
1422581555.718095 DEBUG: [Forwarder] onIncomingInterest face=265 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.718589 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.718929 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=589980969 from=265 retransmit-retry-to=259
^ 232ms
1422581555.950466 DEBUG: [Forwarder] onIncomingData face=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.950763 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.950998 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.951438 DEBUG: [Forwarder] onOutgoingData face=265 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
^ 5ms
1422581555.956230 DEBUG: [Forwarder] onIncomingData face=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.956496 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.956724 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0

NFD2 log: ($ cat hub/nfd.log | grep "/641/data/%00%00?)

1422581521.773468 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581521.773947 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581521.774352 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=1282205730 from=266 newPitEntry-to=264
^ 522ms (??? where is the retransmission interest?)
1422581522.296967 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581522.297347 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581522.297614 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581522.298123 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
^ 5ms (ah, here it is? how?)
1422581522.303090 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581522.303430 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0

NFD3 log: ($ cat producer/nfd.log | grep "/641/data/%00%00?)

1422581555.255647 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.256007 DEBUG: [Forwarder] onOutgoingInterest face=269 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.256334 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=1282205730 from=266 newPitEntry-to=269
^ 47ms (!!! interest arrival was not late, data generation was not delayed)
1422581555.303275 DEBUG: [Forwarder] onIncomingData face=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.303640 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.303928 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.304458 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0


The questions here are:
1. How did the retransmission interest arrived on NFD2 ~220ms later than was expected and actually after the first interest was already answered?
2. If the data was generated and answered by NFD3 in timely manner, why did data arrived on NFD2 after 522ms but not after ~50ms?

Some peculiar place of NFD2?s log:
$ sed -n 38830,38840p hub/nfd.log

1422581521.916149 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
1422581521.916515 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A
1422581521.916799 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
1422581521.917301 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
^ 360ms
1422581522.277620 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/499/data/%00%06
1422581522.278080 DEBUG: [Strategy] beforeExpirePendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/499/data/%00%06
1422581522.278524 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/500/data/%00%06
1422581522.278901 DEBUG: [Strategy] beforeExpirePendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/500/data/%00%06
1422581522.279352 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%05
1422581522.279742 DEBUG: [Strategy] beforeExpirePendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%05
1422581522.280119 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%06


I would appreciate any help.
Looking forward for the insights of NFD developers,

Thanks,

PS. full logs are attached

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

On Jan 21, 2015, at 12:32 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:

Hi all,

I?ve been testing <https://github.com/remap/ndnrtc/tree/issues/2283-retransmissions> N<https://github.com/remap/ndnrtc/tree/issues/2283-retransmissions>DN-RTC with new consumer algorithm and exploring the problem of rebufferings on consumer side (a state, when consumer is not getting data for some amount of time, flushes everything and starts over again). Consumer rebufferings are perceived as audio/video interruptions for 1-1.5sec by the user and decrease overall user experience.

I'll appreciate your insights on the analysis of the logs I retrieved from NFD.

Setup:

[Consumer] <?> [NFD1] <==WiFi_link==> [NFD2] <==Ethernet_link==> [NFD3] <?> [Producer]

Case:
According to my logs, consumer starved for data after 2656 segment has arrived, so I tracked interests and data for 2657 segment. According to my logs, consumer eventually received this data but too late and rebuffering was already inevitable.

NFD1 log:
initial interest: 1421288806.271931 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.272215 DEBUG: [Forwarder] onOutgoingInterest face=262 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.272469 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115 from=266 newPitEntry-to=262
^ 270ms
retransmission: 1421288806.542289 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.542697 DEBUG: [Forwarder] onOutgoingInterest face=262 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.543032 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=562292066 from=266 retransmit-retry-to=262
^ 286ms
data arrives: 1421288806.829462 DEBUG: [Forwarder] onIncomingData face=262 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.829818 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.830042 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=262 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.830449 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0

NFD2 log:
initial interest: 1421288806.015075 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.015845 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.016255 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115 from=266 newPitEntry-to=264
^ 545ms
retransmission: 1421288806.561516 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.562233 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.562626 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=562292066 from=266 retransmit-retry-to=264
^ 2ms
data arrives: 1421288806.564828 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.565282 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.565594 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.566213 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
^ 13ms
data arrives 2:* 1421288806.579547 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.579915 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.580162 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0

*NOTE: no data was forwarded


NFD3 log:
initial interest: 1421288806.249712 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.250177 DEBUG: [Forwarder] onOutgoingInterest face=269 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.250573 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=108889115 from=266 newPitEntry-to=269
^271ms
data generated: 1421288806.521982 DEBUG: [Forwarder] onIncomingData face=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.522531 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.522844 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00 inFace=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
1421288806.523363 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0
^273ms
retransmission: 1421288806.796022 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00
1421288806.796418 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/camera/low/delta/2657/data/%00%00/1/2749/91/0



There are several questions arise:
1. Why do you think the delay b/w initial interest and retransmission for the NFD2 became 545ms (compared to 270ms with NFD1)? Could it be WiFi fault?
2. How come the delay b/w initial interest and data in NFD3 is 271ms and NFD3 forwards this data to NFD2, but NFD2 didn?t get this data and instead got retransmission interest after another 545-271=274ms and later got the same data with 13ms difference? Could it be unreliable logging in NFD?

I attached full NFD logs to this message.

Thank you in advance.
All ideas and thoughts are welcome.

Thanks,

PS. Basically, such things block deployment of NDN-RTC (NdnCon) for the community as it delivers low-quality user experience (i.e. videoconference with interruptions =( ), so I really hope for the help and feedback.


--
Peter Gusev
peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748 (USA)
+7 916 4434826 (Russia)
+37 259 226448 (in case any other number is unavailable)
peetonn_ (skype)

<Archive.zip>_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150130/d41c392f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Archive.zip
Type: application/zip
Size: 2409896 bytes
Desc: Archive.zip
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150130/d41c392f/attachment.zip>

From shijunxiao at email.arizona.edu  Thu Jan 29 20:50:26 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 29 Jan 2015 21:50:26 -0700
Subject: [Nfd-dev] smart flooding strategy
In-Reply-To: <5456163B-197E-4CD0-BDC2-6894D3A7A1CC@memphis.edu>
References: <5456163B-197E-4CD0-BDC2-6894D3A7A1CC@memphis.edu>
Message-ID: <CAOFH+OZzFPAy4=bVZir4nASFY0F2==BDbpyNS2P+Mi7gRRpy_w@mail.gmail.com>

Hi Lan

You may try this strategy on every node, although it's not what it was
designed for.
At least it should perform no worse than NCC.

Access route strategy is designed to avoid creating excess load.
One retrieval failure shouldn't cause the strategy to revert to multicast
immediately. See issue 2403 note-2
<http://redmine.named-data.net/issues/2403#note-2> for the reason.

Yours, Junxiao

On Thu, Jan 29, 2015 at 12:35 PM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

> Junxiao,
>
> Can I use the access router strategy (
> http://redmine.named-data.net/issues/1999) at every node (not just the
> access router) to implement essentially smart flooding?  Basically, I want
> the following strategy:
>
> 1. The first time an Interest is received, the Interest will be sent to
> all the faces of the node except the incoming face.
>
> 2. When the matching Data packet comes back, the face that brings back the
> data will be remembered.
>
> 3. subsequent Interests to this node will use the remembered face.
>
> 4. If no Data comes back, send subsequent Interests to all faces.
>
> Since you implemented the access router strategy, I'm wondering if you
> think there's any potential problems with this.  Also in your design, you
> exclude the last working nexthop in step 4.  I'm not sure if this is
> necessary (it doesn't hurt to try it again).
>
> Lan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150129/172b87d7/attachment.html>

From lanwang at memphis.edu  Fri Jan 30 06:47:16 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 30 Jan 2015 14:47:16 +0000
Subject: [Nfd-dev] smart flooding strategy
In-Reply-To: <CAOFH+OZzFPAy4=bVZir4nASFY0F2==BDbpyNS2P+Mi7gRRpy_w@mail.gmail.com>
References: <5456163B-197E-4CD0-BDC2-6894D3A7A1CC@memphis.edu>
	<CAOFH+OZzFPAy4=bVZir4nASFY0F2==BDbpyNS2P+Mi7gRRpy_w@mail.gmail.com>
Message-ID: <673792B7-2A13-478B-9648-3F52698FB649@memphis.edu>

Junxiao,

A question: how does the access strategy revert back to the best path after a link on the best path recovers from a failure?

Regarding the design of the access route strategy when RTO expires, two questions:

- what is the formula for RTO calculation?

- how is the expiration handled?  I read the issues but it is still unclear to me what's finally implemented.  Do the ppt slides at (http://redmine.named-data.net/issues/1999) reflect the latest design?

Lan

On Jan 29, 2015, at 10:50 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
 wrote:

Hi Lan

You may try this strategy on every node, although it's not what it was designed for.
At least it should perform no worse than NCC.

Access route strategy is designed to avoid creating excess load.
One retrieval failure shouldn't cause the strategy to revert to multicast immediately. See issue 2403 note-2<http://redmine.named-data.net/issues/2403#note-2> for the reason.

Yours, Junxiao

On Thu, Jan 29, 2015 at 12:35 PM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Junxiao,

Can I use the access router strategy (http://redmine.named-data.net/issues/1999) at every node (not just the access router) to implement essentially smart flooding?  Basically, I want the following strategy:

1. The first time an Interest is received, the Interest will be sent to all the faces of the node except the incoming face.

2. When the matching Data packet comes back, the face that brings back the data will be remembered.

3. subsequent Interests to this node will use the remembered face.

4. If no Data comes back, send subsequent Interests to all faces.

Since you implemented the access router strategy, I'm wondering if you think there's any potential problems with this.  Also in your design, you exclude the last working nexthop in step 4.  I'm not sure if this is necessary (it doesn't hurt to try it again).

Lan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150130/f182dca9/attachment.html>

From shijunxiao at email.arizona.edu  Fri Jan 30 08:21:49 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 30 Jan 2015 09:21:49 -0700
Subject: [Nfd-dev] ndncat/putchunks: ndn-cxx or NFD tools?
In-Reply-To: <CE4FB681-0AF8-4995-8343-ACEBFE2AF0EE@ucla.edu>
References: <CAG95NwtzZYyL+7YevfqB-UzAfbL1a+zOQXyyrG0H4x-L5ODZNw@mail.gmail.com>
	<CAOFH+OZvrkLzbF9PacAg6eVdGyWAxueNOD457YYz9jn0NDSLqA@mail.gmail.com>
	<CE4FB681-0AF8-4995-8343-ACEBFE2AF0EE@ucla.edu>
Message-ID: <CAOFH+OYedwSMatWUS9ffQwV4LFDb60DWPCm0GGr8pdvbcMOLjQ@mail.gmail.com>

Hi Alex

Please create ndn-tools repository, and also Redmine project (as a
subproject of NFD).

I suggest we keep the current repositories (ndn-cxx, NFD, ndn-tlv-ping) for
v0.3, and change to the new set (ndn-cxx, NFD, ndn-tools) since v0.4.

Yours, Junxiao

On Mon, Jan 19, 2015 at 10:21 PM, Alex Afanasyev <
alexander.afanasyev at ucla.edu> wrote:

>
> On Jan 5, 2015, at 2:26 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> Hi Steve
>
> I'll begin with the third question.
>
> My observation and opinion is: a tool shall be bundled with ndn-cxx if it
> can be used without installing NFD.
> The two tools bundled with ndn-cxx are:
>
>    - ndnsec: controls the KeyChain
>    - tlvdump: parses the packet format
>
> They both don't require NFD.
>
>
> I recognize that there are certain tools which are not closely related to
> NFD, but are useful in most places where NFD is installed.
> They include:
>
>    - peek and poke
>    - catchunks and putchunks
>    - ping and pingserver
>
> I suggest creating a separate "ndn-tools" repository which contains all
> these tools.
> Operator still installs from three repositories, ndn-cxx, NFD, ndn-tools
> (formerly ndn-tlv-ping), so this change doesn't increase the difficulty of
> deployment.
>
>
> Having a separate `ndn-tools` repository seem to me to be a reasonable
> solution.  We just need to clearly describe on ndn-cxx and NFD pages that
> additional tools can/should be installed from a different repo.
>
> ?
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150130/2a39ba49/attachment.html>

From shijunxiao at email.arizona.edu  Fri Jan 30 08:52:35 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 30 Jan 2015 09:52:35 -0700
Subject: [Nfd-dev] smart flooding strategy
In-Reply-To: <673792B7-2A13-478B-9648-3F52698FB649@memphis.edu>
References: <5456163B-197E-4CD0-BDC2-6894D3A7A1CC@memphis.edu>
	<CAOFH+OZzFPAy4=bVZir4nASFY0F2==BDbpyNS2P+Mi7gRRpy_w@mail.gmail.com>
	<673792B7-2A13-478B-9648-3F52698FB649@memphis.edu>
Message-ID: <CAOFH+OZLf7hzGwS6Szuvscg0e5uPq+6iHXUg69WwePovE4mXoQ@mail.gmail.com>

Hi Lan

The access router strategy will not attempt to probe other nexthops, until
the "last working nexthop" fails. If two laptops can provide the same
contents, after the faster laptop fails, the strategy will stick with the
slower laptop, even if the faster laptop recovers.
In reality, most contents are served from a single laptop which might move.
The strategy design didn't consider the scenario where multiple laptops can
serve same contents. This design may change in a future version of the
strategy.

RTO is calculated using the mean-deviation algorithm (same as TCP), but
there's no multiplier.

Measurements expiration is not specified in the design. This will be fixed
in Bug 2452.

The implementation accurately follows access-router-strategy_20141220.pptx
design.

Yours, Junxiao

On Fri, Jan 30, 2015 at 7:47 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

>  Junxiao,
>
>  A question: how does the access strategy revert back to the best path
> after a link on the best path recovers from a failure?
>
>  Regarding the design of the access route strategy when RTO expires, two
> questions:
>
>  - what is the formula for RTO calculation?
>
>  - how is the expiration handled?  I read the issues but it is still
> unclear to me what's finally implemented.  Do the ppt slides at (
> http://redmine.named-data.net/issues/1999) reflect the latest design?
>
>  Lan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150130/c4e00c2d/attachment.html>

From lanwang at memphis.edu  Fri Jan 30 10:22:40 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 30 Jan 2015 18:22:40 +0000
Subject: [Nfd-dev] smart flooding strategy
In-Reply-To: <CAOFH+OZLf7hzGwS6Szuvscg0e5uPq+6iHXUg69WwePovE4mXoQ@mail.gmail.com>
References: <5456163B-197E-4CD0-BDC2-6894D3A7A1CC@memphis.edu>
	<CAOFH+OZzFPAy4=bVZir4nASFY0F2==BDbpyNS2P+Mi7gRRpy_w@mail.gmail.com>
	<673792B7-2A13-478B-9648-3F52698FB649@memphis.edu>
	<CAOFH+OZLf7hzGwS6Szuvscg0e5uPq+6iHXUg69WwePovE4mXoQ@mail.gmail.com>
Message-ID: <49435CBF-C60A-419B-A823-5313D40042D2@memphis.edu>

Junxiao,

See comments below:

On Jan 30, 2015, at 10:52 AM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Lan

The access router strategy will not attempt to probe other nexthops, until the "last working nexthop" fails. If two laptops can provide the same contents, after the faster laptop fails, the strategy will stick with the slower laptop, even if the faster laptop recovers.
In reality, most contents are served from a single laptop which might move. The strategy design didn't consider the scenario where multiple laptops can serve same contents. This design may change in a future version of the strategy.

OK.  For my purpose, recovery is important so I think periodic probing needs to be added.  So how about I ask a student to implement a so-called smart flooding strategy based on your access strategy code, but add the probing part (and any other necessary changes)?  This probing can be what Cheng proposed in his "A case for stateful forwarding plane" paper (http://www.cs.memphis.edu/~lanwang/).  We can implement this as a generic probing strategy that different forwarding strategies can use or customize (similar to your retransmission strategy).

RTO is calculated using the mean-deviation algorithm (same as TCP), but there's no multiplier.

OK.

Measurements expiration is not specified in the design. This will be fixed in Bug 2452.

When do you plan to fix this?

I actually meant what will happen when the RTO for an Interest expires?  Looks like you and Alex have some disagreement on this handling (and Alex submitted a gerrit patch?), but I'm not sure what's the final decision and what's the rationale.

The implementation accurately follows access-router-strategy_20141220.pptx design.

Thanks.

Lan

Yours, Junxiao

On Fri, Jan 30, 2015 at 7:47 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Junxiao,

A question: how does the access strategy revert back to the best path after a link on the best path recovers from a failure?

Regarding the design of the access route strategy when RTO expires, two questions:

- what is the formula for RTO calculation?

- how is the expiration handled?  I read the issues but it is still unclear to me what's finally implemented.  Do the ppt slides at (http://redmine.named-data.net/issues/1999) reflect the latest design?

Lan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150130/0c74319b/attachment.html>

From shijunxiao at email.arizona.edu  Sat Jan 31 16:21:33 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sat, 31 Jan 2015 17:21:33 -0700
Subject: [Nfd-dev] ndn-cxx may breaks ndnSIM
Message-ID: <CAOFH+OZhSmxG-Gu4F2ekwrUdvtNJAVA3ejABMx8Rz83Da=BVXg@mail.gmail.com>

Dear folks

Currently ndnSIM installation procedure <
http://ndnsim.net/2.0/getting-started.html> recommends to use either
git-HEAD version of ndn-cxx, or ndn-cxx-dev package from PPA.
Some ndn-cxx Changes are inevitably backwards-incompatible, and may cause
the API to be incompatible with ndn-cxx-dev package.
This leads to a dilemma: if ndnSIM is updated to accommodate the new
ndn-cxx API, it won't compile with ndn-cxx-dev package; if ndnSIM is not
updated, it can compile with ndn-cxx-dev package, but cannot compile with
git-HEAD of ndn-cxx.

There are a few potential solutions:

   - ndnSIM installation procedure can pin a specific version of ndn-cxx,
   instead of using git-HEAD; that version shall have same API with
   ndn-cxx-dev package
   - ndnSIM installation procedure can recommend either git-HEAD or
   ndn-cxx-dev package, but not both
   - ndn-cxx-dev package should be rebuilt whenever a
   backwards-incompatible Change is merged to ndn-cxx


Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150131/c136f293/attachment.html>

From alexander.afanasyev at ucla.edu  Sat Jan 31 16:39:31 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Sat, 31 Jan 2015 16:39:31 -0800
Subject: [Nfd-dev] ndn-cxx may breaks ndnSIM
In-Reply-To: <CAOFH+OZhSmxG-Gu4F2ekwrUdvtNJAVA3ejABMx8Rz83Da=BVXg@mail.gmail.com>
References: <CAOFH+OZhSmxG-Gu4F2ekwrUdvtNJAVA3ejABMx8Rz83Da=BVXg@mail.gmail.com>
Message-ID: <53E4B538-52A5-44C1-B3B4-FD7C4A53E64C@ucla.edu>

Hi Junxiao,

The current recommendation for using git-HEAD is because we don?t have a release version of the library that is suitable for ndnSIM.  My plan is to change this recommendation to use the released version of ndn-cxx, which should be matched with PPA head.

At some point, it may be necessary to import ndn-cxx library in a similar way we did NFD (or add a submodule that is a forked version of ndn-cxx).  This may be necessary for further changes to make sure some ndn-cxx based application can run within the simulated environment.

?
Alex

> On Jan 31, 2015, at 4:21 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Dear folks
> 
> Currently ndnSIM installation procedure <http://ndnsim.net/2.0/getting-started.html <http://ndnsim.net/2.0/getting-started.html>> recommends to use either git-HEAD version of ndn-cxx, or ndn-cxx-dev package from PPA.
> Some ndn-cxx Changes are inevitably backwards-incompatible, and may cause the API to be incompatible with ndn-cxx-dev package.
> This leads to a dilemma: if ndnSIM is updated to accommodate the new ndn-cxx API, it won't compile with ndn-cxx-dev package; if ndnSIM is not updated, it can compile with ndn-cxx-dev package, but cannot compile with git-HEAD of ndn-cxx.
> 
> There are a few potential solutions:
> ndnSIM installation procedure can pin a specific version of ndn-cxx, instead of using git-HEAD; that version shall have same API with ndn-cxx-dev package
> ndnSIM installation procedure can recommend either git-HEAD or ndn-cxx-dev package, but not both
> ndn-cxx-dev package should be rebuilt whenever a backwards-incompatible Change is merged to ndn-cxx
> 
> Yours, Junxiao
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150131/a63f2469/attachment.html>
-------------- 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150131/a63f2469/attachment.bin>

From lanwang at memphis.edu  Sat Jan 31 18:18:48 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Sun, 1 Feb 2015 02:18:48 +0000
Subject: [Nfd-dev] packet format specification
Message-ID: <4475F971-1F32-4B13-A57D-DAB0BE9D5BBB@memphis.edu>

Hi all,

There seems to be some inconsistencies in the packet format specification at http://named-data.net/doc/ndn-tlv/data.html#metainfo:

FinalBlockId is an optional field of MetaInfo in the definition, but the following two statements suggest otherwise:

- "If both ContentType and FreshnessPeriod are optional, one may consider Metainfo itself should be optional. But would have all 4 parts of Data packet help simplify implementation? We leave this question to people who are more familiar with high speed implementations."  add FinalBlockId after FreshnessPeriod? 

- "Timestamp and FinalBlockID can be useful meta information for applications, but do not need to be processed at the network layer. Therefore, if desired, applications should encode such meta information as part of the content."  This is a remnant of previous version of the specification that argues why FinalBlockID should not be part of MetaInfo.  Remove FinalBlockID from this statement?

Lan




From shijunxiao at email.arizona.edu  Sat Jan 31 19:49:27 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sat, 31 Jan 2015 20:49:27 -0700
Subject: [Nfd-dev] smart flooding strategy
In-Reply-To: <49435CBF-C60A-419B-A823-5313D40042D2@memphis.edu>
References: <5456163B-197E-4CD0-BDC2-6894D3A7A1CC@memphis.edu>
	<CAOFH+OZzFPAy4=bVZir4nASFY0F2==BDbpyNS2P+Mi7gRRpy_w@mail.gmail.com>
	<673792B7-2A13-478B-9648-3F52698FB649@memphis.edu>
	<CAOFH+OZLf7hzGwS6Szuvscg0e5uPq+6iHXUg69WwePovE4mXoQ@mail.gmail.com>
	<49435CBF-C60A-419B-A823-5313D40042D2@memphis.edu>
Message-ID: <CAOFH+Oa+j+oCWSZqPknTY=qrxeeQd0ACeK6k-HkDo_rdaNorrA@mail.gmail.com>

Hi Lan

In the next month or so, I'll focus on designing strategy building blocks
so that a strategy designer can compose different features into a strategy
to fit different needs (#2000).

You could duplicate access router strategy and make changes in a separate
experimental branch, but I don't recommend trying to commit that into
master, because it would double the maintenance work in case a bug is found
and fixed in access router strategy.
After #2000 is complete, "smart flooding" could be composed as "access
router strategy" with addition of probing building block.


Bug 2452 is scheduled for target version v0.3, which means it must be fixed
before v0.3 release.


Upon RTO expiration of the last working nexthop, the Interest will be
multicasted to all other nexthops. There is no disagreement in this
particular point.

Yours, Junxiao

On Fri, Jan 30, 2015 at 11:22 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

>  Junxiao,
>
>  See comments below:
>
>  On Jan 30, 2015, at 10:52 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
>  Hi Lan
>
>  The access router strategy will not attempt to probe other nexthops,
> until the "last working nexthop" fails. If two laptops can provide the same
> contents, after the faster laptop fails, the strategy will stick with the
> slower laptop, even if the faster laptop recovers.
> In reality, most contents are served from a single laptop which might
> move. The strategy design didn't consider the scenario where multiple
> laptops can serve same contents. This design may change in a future version
> of the strategy.
>
>
>  OK.  For my purpose, recovery is important so I think periodic probing
> needs to be added.  So how about I ask a student to implement a so-called
> smart flooding strategy based on your access strategy code, but add the
> probing part (and any other necessary changes)?  This probing can be what
> Cheng proposed in his "A case for stateful forwarding plane" paper (
> http://www.cs.memphis.edu/~lanwang/).  We can implement this as a generic
> probing strategy that different forwarding strategies can use or customize
> (similar to your retransmission strategy).
>
>  RTO is calculated using the mean-deviation algorithm (same as TCP), but
> there's no multiplier.
>
>
>  OK.
>
>
>  Measurements expiration is not specified in the design. This will be
> fixed in Bug 2452.
>
>
>  When do you plan to fix this?
>
>  I actually meant what will happen when the RTO for an Interest expires?
> Looks like you and Alex have some disagreement on this handling (and Alex
> submitted a gerrit patch?), but I'm not sure what's the final decision and
> what's the rationale.
>
>
>  The implementation accurately follows
> access-router-strategy_20141220.pptx design.
>
>
>  Thanks.
>
>  Lan
>
>
>  Yours, Junxiao
>
> On Fri, Jan 30, 2015 at 7:47 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
> wrote:
>
>> Junxiao,
>>
>>  A question: how does the access strategy revert back to the best path
>> after a link on the best path recovers from a failure?
>>
>>  Regarding the design of the access route strategy when RTO expires, two
>> questions:
>>
>>  - what is the formula for RTO calculation?
>>
>>  - how is the expiration handled?  I read the issues but it is still
>> unclear to me what's finally implemented.  Do the ppt slides at (
>> http://redmine.named-data.net/issues/1999) reflect the latest design?
>>
>>  Lan
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150131/b8ca6157/attachment.html>

From shijunxiao at email.arizona.edu  Sat Jan 31 22:23:16 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sat, 31 Jan 2015 23:23:16 -0700
Subject: [Nfd-dev] Avoid inline functions to reduce code size bloat
Message-ID: <CAOFH+OZSL=fSa6jXb2oOZDWQLOeMViDhFgc5i9iP6uOng_WsoQ@mail.gmail.com>

Dear folks

Back in June, in issue 1694, I have pointed out that ndn-cxx has a tendency
of over-using inline functions.
According to C++ Dos and Don'ts
<http://www.chromium.org/developers/coding-style/cpp-dos-and-donts#TOC-Stop-inlining-code-in-headers>
from
Chromium project, using too much inline functions creates additional work
for the linker, because every file that includes those headers would emit a
version of an inline function in the object file (.o), and the linker has
to eliminate those duplicates.
There's also evidence that inline functions can lead to binary size bloat,
which is bad news of devices with small memory or storage, such as home
routers and IoT gadgets. Even if ndn-cxx can fit into those devices,
bloated binaries will consume precious memory space, and reduce available
memory for ContentStore.

A decision was made in 20140708 conference call
<http://redmine.named-data.net/issues/1694#note-6> that we should stop
adding new inline functions unless they are trivial getters/setters, but
fixing old code is low priority.
Of course, if a function is template, and all possible template parameters
are not known in advance, it can be inline.


During the review of issue 2183, I suggested Change Owner to move inline
functions into .cpp, as per the decision above.
However, this suggestion was rejected.
The reply was "whatever you saying. I'm refusing to do change here". No
valid reason is given with this reply.


To finally resolve this and similar disputes, I request a review on the
decision about inline function usage.
Please give your opinion about where inline functions should be used, along
with necessary reasons and citations.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150131/6280d848/attachment.html>

From shijunxiao at email.arizona.edu  Sat Jan 31 22:31:29 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sat, 31 Jan 2015 23:31:29 -0700
Subject: [Nfd-dev] review request: reduce implicit digest computation in
	ContentStore
Message-ID: <CAOFH+OaAsRO7+LjZ2EvOm=Nzo2ZO2-KuOB89TTOT_rJ0VSEHog@mail.gmail.com>

Dear folks

I implemented a new comparison algorithm in ContentStore in order to reduce
implicit digest computation in common cases, which accounted for 40% of
ContentStore CPU time.
I need someone to review the code:

http://gerrit.named-data.net/1688

I'll appreciate if anyone can have a look at this patch.
You don't have to be an expert in order to do a code review. Even if you
are new to the project, doing code reviews will help you get familiar with
the codebase and development procedures.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150131/7d2219c7/attachment.html>

From alexander.afanasyev at ucla.edu  Sat Jan 31 22:38:41 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Sat, 31 Jan 2015 22:38:41 -0800
Subject: [Nfd-dev] Avoid inline functions to reduce code size bloat
In-Reply-To: <CAOFH+OZSL=fSa6jXb2oOZDWQLOeMViDhFgc5i9iP6uOng_WsoQ@mail.gmail.com>
References: <CAOFH+OZSL=fSa6jXb2oOZDWQLOeMViDhFgc5i9iP6uOng_WsoQ@mail.gmail.com>
Message-ID: <F6B1494F-011E-4925-A49F-48AB0BFCE4A9@ucla.edu>

The cited page make an upfront disclaimer "A NOTE ABOUT USAGE: Unlike the style guide, the content of this page is advisory, not required.  You can always deviate from something on this page, if the relevant author/reviewer/OWNERS agree that another course is better.?

As a first point.  I don?t agree with everything stated in this guide and it is advisory at most.  You cannot require every single implementation to follow some specific rule.

Second.  I don?t agree with ?code bloat? problem.  Yes, I saw your tests long time ago and they showed some correlation between listing code inline and not.  It is always compilers decision anyways to inline something or not to inline something.  I believe, when it is not in the header, the compiler simply don?t have a chance to make optimizations if it deem them appropriate.  Use size-oriented optimization, where compiler should be smarter about inlining.

Third.  Putting (some) implementation in the header and not putting it has its own tradeoffs.  When ?hiding? in .cpp it reduces how much stuff is included, but also requires creation of additional compilation unit.  In some cases extra compilation unit make sense, in some cases it is not.  I?m against defining any specific rules for that, as it is developer?s discretion.

Finally.  There are so much other work to do.  We have >180 open redmine issues for NFD and ndn-cxx.  I?m completely against touching the code that has been working, even if we do modifications.  I can cite a couple of examples when such changes resulted in serious bugs.

?
Alex


> On Jan 31, 2015, at 10:23 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Dear folks
> 
> Back in June, in issue 1694, I have pointed out that ndn-cxx has a tendency of over-using inline functions.
> According to C++ Dos and Don'ts <http://www.chromium.org/developers/coding-style/cpp-dos-and-donts#TOC-Stop-inlining-code-in-headers> from Chromium project, using too much inline functions creates additional work for the linker, because every file that includes those headers would emit a version of an inline function in the object file (.o), and the linker has to eliminate those duplicates.
> There's also evidence that inline functions can lead to binary size bloat, which is bad news of devices with small memory or storage, such as home routers and IoT gadgets. Even if ndn-cxx can fit into those devices, bloated binaries will consume precious memory space, and reduce available memory for ContentStore.
> 
> A decision was made in 20140708 conference call <http://redmine.named-data.net/issues/1694#note-6> that we should stop adding new inline functions unless they are trivial getters/setters, but fixing old code is low priority.
> Of course, if a function is template, and all possible template parameters are not known in advance, it can be inline.
> 
> 
> During the review of issue 2183, I suggested Change Owner to move inline functions into .cpp, as per the decision above.
> However, this suggestion was rejected.
> The reply was "whatever you saying. I'm refusing to do change here". No valid reason is given with this reply.
> 
> 
> To finally resolve this and similar disputes, I request a review on the decision about inline function usage.
> Please give your opinion about where inline functions should be used, along with necessary reasons and citations.
> 
> Yours, Junxiao
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150131/751501c8/attachment.html>
-------------- 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: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150131/751501c8/attachment.bin>

From shijunxiao at email.arizona.edu  Sat Jan 31 23:16:47 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 1 Feb 2015 00:16:47 -0700
Subject: [Nfd-dev] Avoid inline functions to reduce code size bloat
In-Reply-To: <F6B1494F-011E-4925-A49F-48AB0BFCE4A9@ucla.edu>
References: <CAOFH+OZSL=fSa6jXb2oOZDWQLOeMViDhFgc5i9iP6uOng_WsoQ@mail.gmail.com>
	<F6B1494F-011E-4925-A49F-48AB0BFCE4A9@ucla.edu>
Message-ID: <CAOFH+OYSH4Ogc2u44f68Q+pTJWU=K+QZPmSN-vzKLhPZSpRqGg@mail.gmail.com>

Hi Alex

1. Yes, this guide is advisory. However, advisory rules can't be ignored
without justification.
Advisory rules can be interpreted as RFC 2119 "SHOULD" level: "there may
exist valid reasons in particular circumstances to ignore a particular
item".
A justification is needed for each function that SHOULD be non-inline but
is decided to be inline.

2. As said in C++ Dos and Don'ts, when the function is longer than a few
instructions, compiler won't inline it.

3. As benchmarked, adding two new compilation units for name and
name-component and eliminating inline functions in these two types result
in a reduction of total compilation time.
What are other reasons against additional compilation units?

4a. Having other work to do isn't an excuse of ignoring previous decision
without justification.

4b. Please cite a Bug that is solely caused by moving the definition of a
non-template function into .cpp.

Yours, Junxiao
On Jan 31, 2015 11:38 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
wrote:

> The cited page make an upfront disclaimer "A NOTE ABOUT USAGE: Unlike the
> style guide, the content of this page is advisory, not required.  You can
> always deviate from something on this page, if the
> relevant author/reviewer/OWNERS agree that another course is better.?
>
> As a first point.  I don?t agree with everything stated in this guide and
> it is advisory at most.  You cannot require every single implementation to
> follow some specific rule.
>
> Second.  I don?t agree with ?code bloat? problem.  Yes, I saw your tests
> long time ago and they showed some correlation between listing code inline
> and not.  It is always compilers decision anyways to inline something or
> not to inline something.  I believe, when it is not in the header, the
> compiler simply don?t have a chance to make optimizations if it deem them
> appropriate.  Use size-oriented optimization, where compiler should be
> smarter about inlining.
>
> Third.  Putting (some) implementation in the header and not putting it has
> its own tradeoffs.  When ?hiding? in .cpp it reduces how much stuff is
> included, but also requires creation of additional compilation unit.  In
> some cases extra compilation unit make sense, in some cases it is not.  I?m
> against defining any specific rules for that, as it is developer?s
> discretion.
>
> Finally.  There are so much other work to do.  We have >180 open redmine
> issues for NFD and ndn-cxx.  I?m completely against touching the code that
> has been working, even if we do modifications.  I can cite a couple of
> examples when such changes resulted in serious bugs.
>
> ?
> Alex
>
>
> On Jan 31, 2015, at 10:23 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> Dear folks
>
> Back in June, in issue 1694, I have pointed out that ndn-cxx has a
> tendency of over-using inline functions.
> According to C++ Dos and Don'ts
> <http://www.chromium.org/developers/coding-style/cpp-dos-and-donts#TOC-Stop-inlining-code-in-headers> from
> Chromium project, using too much inline functions creates additional work
> for the linker, because every file that includes those headers would emit a
> version of an inline function in the object file (.o), and the linker has
> to eliminate those duplicates.
> There's also evidence that inline functions can lead to binary size bloat,
> which is bad news of devices with small memory or storage, such as home
> routers and IoT gadgets. Even if ndn-cxx can fit into those devices,
> bloated binaries will consume precious memory space, and reduce available
> memory for ContentStore.
>
> A decision was made in 20140708 conference call
> <http://redmine.named-data.net/issues/1694#note-6> that we should stop
> adding new inline functions unless they are trivial getters/setters, but
> fixing old code is low priority.
> Of course, if a function is template, and all possible template parameters
> are not known in advance, it can be inline.
>
>
> During the review of issue 2183, I suggested Change Owner to move inline
> functions into .cpp, as per the decision above.
> However, this suggestion was rejected.
> The reply was "whatever you saying. I'm refusing to do change here". No
> valid reason is given with this reply.
>
>
> To finally resolve this and similar disputes, I request a review on the
> decision about inline function usage.
> Please give your opinion about where inline functions should be used,
> along with necessary reasons and citations.
>
> Yours, Junxiao
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150201/78f171cb/attachment.html>

From shijunxiao at email.arizona.edu  Sat Jan 31 23:36:36 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 1 Feb 2015 00:36:36 -0700
Subject: [Nfd-dev] packet format specification
In-Reply-To: <4475F971-1F32-4B13-A57D-DAB0BE9D5BBB@memphis.edu>
References: <4475F971-1F32-4B13-A57D-DAB0BE9D5BBB@memphis.edu>
Message-ID: <CAOFH+Obdt86NKuWRJ3O+Fg8Y+LjxvnJCEkG+Ep3gY-=X3CVJNQ@mail.gmail.com>

Hi Lan

Thanks for pointing these out.
This issue is tracked as Bug 2461 http://redmine.named-data.net/issues/2461

Yours, Junxiao
On Jan 31, 2015 7:19 PM, "Lan Wang (lanwang)" <lanwang at memphis.edu> wrote:

> Hi all,
>
> There seems to be some inconsistencies in the packet format specification
> at http://named-data.net/doc/ndn-tlv/data.html#metainfo:
>
> FinalBlockId is an optional field of MetaInfo in the definition, but the
> following two statements suggest otherwise:
>
> - "If both ContentType and FreshnessPeriod are optional, one may consider
> Metainfo itself should be optional. But would have all 4 parts of Data
> packet help simplify implementation? We leave this question to people who
> are more familiar with high speed implementations."  add FinalBlockId after
> FreshnessPeriod?
>
> - "Timestamp and FinalBlockID can be useful meta information for
> applications, but do not need to be processed at the network layer.
> Therefore, if desired, applications should encode such meta information as
> part of the content."  This is a remnant of previous version of the
> specification that argues why FinalBlockID should not be part of MetaInfo.
> Remove FinalBlockID from this statement?
>
> Lan
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150201/dd2309de/attachment.html>

From zeynalvand at ce.sharif.edu  Thu Jan  8 01:44:19 2015
From: zeynalvand at ce.sharif.edu (L.Zeynalvand)
Date: Thu, 08 Jan 2015 09:44:19 -0000
Subject: [Nfd-dev] [ndnSIM] NFD Development - Content Store
In-Reply-To: <DF4490CA-250C-41C9-A9CD-70C6BC0FC2F8@ucla.edu>
References: <659ce27888812915baf2556d0312b72c@ce.sharif.edu>
	<DF4490CA-250C-41C9-A9CD-70C6BC0FC2F8@ucla.edu>
Message-ID: <749c724082d6eb952517510af743f55c@ce.sharif.edu>

Thank you Alex,
Actually my thesis is decentralized social networking using named data, 
in which people's private social content is hosted right from their 
homes, having a part of the content store persistent is crucial for me. 
I'll work on the NFD code and let you know the results.

Regards,
-- 
Leonid Zeynalvand
M.Sc Information Technology
Sharif University of Technology


On 07.01.2015 23:22, Alex Afanasyev wrote:
> Hi Leonid,
>
> There is nfd-dev at lists.cs.ucla.edu mailing list for discussions
> specificaly about NFD development (cc'ed here).
>
> I saw your question on ndn-interest mailing list and it didn't strike
> me as directly related to NFD :)
> Theoretically, if you want, you can make it persistent.  If you're
> asking about the current code, then we don't have that capability and
> you're welcome to contribute it.
>
> ---
> Alex
>
>> On Jan 7, 2015, at 3:45 AM, L.Zeynalvand <zeynalvand at ce.sharif.edu> 
>> wrote:
>>
>> Hi, is there a specific mailing list to post questions regarding NFD 
>> Development? If not, I would appreciate if you help me out with this.
>> Is there a way to make the Content Store persistent? By persistent I 
>> don't mean no cache replacement, what I mean is that if for any reason 
>> we power off the router and then power back on, whatever there was in 
>> content store remain intact. (consider the router is an end user  home 
>> wifi)
>>
>> Regards,
>>
>> --
>> Leonid Zeynalvand
>> M.Sc Information Technology
>> Sharif University of Technology