From klaus at email.arizona.edu  Sat Oct  1 01:08:50 2016
From: klaus at email.arizona.edu (Klaus Schneider)
Date: Sat, 1 Oct 2016 01:08:50 -0700
Subject: [Ndn-interest] ndn replication strategy
In-Reply-To: <CAOV5UZ1p4LAueomGxvpD3ScAj4av=KNkr56sgF+pfPdh7j9MEQ@mail.gmail.com>
References: <712FE4E7257849499414892DD92704BC7A9B6A4A@INFRAEX02.oxia.corp>
	<CAOV5UZ38ngVEPaVKwdVRRa-STFpY6+9FYN6E4fCdpPSA_JnCKQ@mail.gmail.com>
	<712FE4E7257849499414892DD92704BC7A9B6A73@INFRAEX02.oxia.corp>
	<CAOV5UZ3FQfOfHB-kYzsJzC7D8wtpSHbuWk1H9ZuUyFKt+yDOcg@mail.gmail.com>
	<CAOV5UZ1p4LAueomGxvpD3ScAj4av=KNkr56sgF+pfPdh7j9MEQ@mail.gmail.com>
Message-ID: <32c104cc-76c1-a979-a6ab-4b110e446191@email.arizona.edu>

Hi Ibrahim,

if you are talking about the NDN Forwarding Daemon (NFD), yes it 
currently uses LCE (leave a copy everywhere) as cache decision policy (= 
what you call replication strategy).

We had a project at an earlier NDN Hackathon to implement and evaluate 
other cache decision policies. Here is some more information on that:

>
> Here are the proposal slides (#5): https://github.com/ndncomm/nfd-caching-ndnsim/blob/master/graphs/final2/Hackathon%20Proposals.pdf
>
> It was specifically about "cache decision policies" (deciding which objects should be cached in the first place) for NFD rather than cache replacement policies (deciding which objects to remove once the cache is full).
>
> Specifically, we implemented a uniform random cache admission and a strategy called "leave a copy down" (LCD), which keeps a cache copy only one hop downstream of the last cache hit to increase caching diversity. The results are here:
>
> - https://github.com/ndncomm/nfd-caching-ndnsim/blob/master/graphs/final2/hack.pdf
>
> - https://github.com/ndncomm/nfd-caching-ndnsim/tree/master/graphs
> - https://github.com/ndncomm/nfd-caching-ndnsim/tree/master/results
>
> Here are some resources on caching in CCN/ICN:
>
> - http://netlab.pkusz.edu.cn/wordpress/wp-content/uploads/2011/10/Caching-performance-of-content-centric-networks-under-multi-path-routingand-more.pdf
>
> - https://www.researchgate.net/profile/Ioannis_Psaras/publication/254462976_Probabilistic_in-network_caching_for_information-centric/links/0046352f9d8eda214e000000.pdf

Best regards,
Klaus


On 29.09.2016 04:59, Ibrahim ABDULLAHI wrote:
> As replied
>
>
> On Sep 29, 2016 7:57 PM, "Ibrahim ABDULLAHI" <ibrojay01 at gmail.com
> <mailto:ibrojay01 at gmail.com>> wrote:
>
>     Move Copy Down. Even thou it can be thought of in another
>     perspective due to its plus in carefully reducing the amount of
>     redundant or replica content cache.
>
>     All the best
>
>
>     On Sep 29, 2016 7:32 PM, "Nour El Houda Ben Youssef"
>     <NourElHouda.BenYoussef at wevioo.com
>     <mailto:NourElHouda.BenYoussef at wevioo.com>> wrote:
>
>         Thank you for your reply ____
>
>         what do you exactly mean by MCD?____
>
>         __ __
>
>         Best regards____
>
>         __ __
>
>         *De :*Ibrahim ABDULLAHI [mailto:ibrojay01 at gmail.com
>         <mailto:ibrojay01 at gmail.com>]
>         *Envoy? :* jeudi 29 septembre 2016 12:06
>         *? :* Nour El Houda Ben Youssef
>         *Cc :* ndn-interest at lists.cs.ucla.edu
>         <mailto:ndn-interest at lists.cs.ucla.edu>
>         *Objet :* Re: [Ndn-interest] ndn replication strategy____
>
>         __ __
>
>         Dear Nour,
>         Yes LCE could be one of the strategies for the cache nature of
>         NDN. However, it all depends on the deployment particularly the
>         network setting. MCD, ProbCache are all good options. ____
>
>         __ __
>
>         On Sep 29, 2016 5:40 PM, "Nour El Houda Ben Youssef"
>         <NourElHouda.BenYoussef at wevioo.com
>         <mailto:NourElHouda.BenYoussef at wevioo.com>> wrote:____
>
>         Dear ndn users,____
>
>          ____
>
>         I was wondering which replication strategy does ndn use?____
>
>          ____
>
>         Since a copy of content is stored along the path, can it be
>         considered as LCE (leave copy everywhere) strategy ?____
>
>          ____
>
>         Best regards____
>
>          ____
>
>          ____
>
>          ____
>
>          ____
>
>          ____
>
>
>         _______________________________________________
>         Ndn-interest mailing list
>         Ndn-interest at lists.cs.ucla.edu
>         <mailto:Ndn-interest at lists.cs.ucla.edu>
>         http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>         <http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest>____
>
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>


From Matteo.Bertolino at eurecom.fr  Mon Oct  3 02:42:40 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Mon, 03 Oct 2016 11:42:40 +0200
Subject: [Ndn-interest] How to use repo-ng?
Message-ID: <20161003114240.3y6aqogpc88wg84w@webmail.eurecom.fr>

Good morning community,
I would like to exploit repo-ng in order to distribute certificates.

I tried, but I failed and I do not understand how to do.

Supposing a topology in which I have a consumer, a producer and a root
authority. The root authority sign the certificate of the producer,
the consumer trust in the root authority. Suppose that the same node
of the root authority distributes also the certificates. Consumer asks
for /root/site1 data, p announced /root/site1 and r announced /root/KEY.

Without repo and with an app publisher it works fine.

My steps are:

//Generation of the certification chain
At the end, the root has the certificate of the producer
"site1.ndncert" and its own (root.ndncert).

//Modify repo-ng.conf
Actually I have no idea how to do. I just modified the prefixes in  
"/root/KEY", and I put the config file in /usr/local/etc/ndn and  
/etc/ndn folders. I attached it.

//Put the certificate
I put the certificate site1.ndncert in the root folder and publisher folder.

//Publish the certificate:
r /home/bertolino/Desktop/miniNDN/mini-ndn/repo-ng/build/ndn-repo-ng &
(where r is the root authority node)

r base 64 -d site1.ndncert | nc localhost 7376

Then, r receives the request for the interest /root/KEY/site1 etc but  
it is not able to satisfy it.
In particular:
Sending /root/site1?ndn.MustBeFresh=1&ndn.InterestLifetime=1000
failedCannot fetch cert: /root/KEY/site1/ksk-1475484935283/ID-CERT

Any help is particularly appreciated,
Thank you very much,
Yours Matteo



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr

-------------- next part --------------
repo
{
  ; Section defining list of Data prefixes to register
  ; Only 'prefix' option is allowed here, which can be repeated multiple times
  data
  {
    prefix "ndn:/root/KEY"
  }

  ; Section defining list of command prefixes (to insert or delete Data) to register.
  ; Only 'prefix' option is allowed here, which can be repeated multiple times
  command
  {
    prefix "ndn:/root/KEY"
    prefix "ndn:/root/KEY"
  }

  ; Section to specify where data should be stored
  ; Right now only a single 'sqlite' option is allowed:
  storage
  {
    method "sqlite"             ; Currently, only sqlite storage engine is supported
    path "/var/db/ndn-repo-ng"  ; path to repo-ng storage folder
    max-packets 100000
  }

  ; Section to enable TCP bulk insert capability
  ; If section is present, then TCP bulk insert is enabled (empty section enables
  ; TCP bulk insert to listen on "localhost:7376")
  tcp_bulk_insert {
    ; host "localhost"  ; Set to listen on different IP address or hostname
    ; port 7376  ; Set to listen on different port number
  }

  validator
  {
    ; The following rule disables all security in the repo
    trust-anchor {
        type any
    }

    ; ; These rule are examples of validation of signed interests for commands and data.
    ; ; User could define its own rule for signed interest or data to be inserted
    ; ; according to Validator Configuration File Format.
    ; ; (http://redmine.named-data.net/projects/ndn-cxx/wiki/CommandValidatorConf)
    ; rule
    ; {
    ;   id "Simple Rule For Interest"
    ;   for interest
    ;   filter
    ;   {
    ;     type name
    ;     name /root/KEY
    ;     relation is-prefix-of
    ;   }
    ;   checker
    ;   {
    ;     type fixed-signer
    ;     sig-type rsa-sha256
    ;     signer
    ;     {
    ;       type file
    ;       ; repo-ng.cert.sample is just a non-existent certificate.
    ;       ; User should create its own certification using Security Tool.
    ;       ; (http://redmine.named-data.net/projects/ndn-cxx/wiki/SecurityTools)
    ;       file-name "repo-ng.cert.sample"
    ;     }
    ;   }
    ; }
    ;
    ; rule
    ; {
    ;   id "Simple Rule For Data"
    ;   for data
    ;   filter
    ;   {
    ;     type name
    ;     name /example/data/1
    ;     relation is-prefix-of
    ;   }
    ;   checker
    ;   {
    ;     type fixed-signer
    ;     sig-type rsa-sha256
    ;     signer
    ;     {
    ;       type file
    ;       ; repo-ng.cert.sample is just a non-existent certificate.
    ;       ; User should create its own certification using Security Tool.
    ;       ; (http://redmine.named-data.net/projects/ndn-cxx/wiki/SecurityTools)
    ;       file-name "repo-ng.cert.sample"
    ;     }
    ;   }
    ; }
  }
}

From shijunxiao at email.arizona.edu  Mon Oct  3 07:30:58 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 3 Oct 2016 07:30:58 -0700
Subject: [Ndn-interest] How to use repo-ng?
In-Reply-To: <20161003114240.3y6aqogpc88wg84w@webmail.eurecom.fr>
References: <20161003114240.3y6aqogpc88wg84w@webmail.eurecom.fr>
Message-ID: <CAOFH+OYf1yFwA7rnHkUzFQ1qa7fV=C+V2xMLYjzvnB3CVKReCw@mail.gmail.com>

Hi Matteo

Things to look for:

1. Are you able to fetch the certificate on node r with ndnpeek?
2. If yes, pipe the output to ndn-dissect. Does the Data packet look
correct? It should have the proper ContentType as a certificate.
3. Are there proper FIB entries from the node trying to fetch the
certificate to node r?

Yours, Junxiao

On Oct 3, 2016 02:43, "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
wrote:

> Good morning community,
> I would like to exploit repo-ng in order to distribute certificates.
>
> I tried, but I failed and I do not understand how to do.
>
> Supposing a topology in which I have a consumer, a producer and a root
> authority. The root authority sign the certificate of the producer,
> the consumer trust in the root authority. Suppose that the same node
> of the root authority distributes also the certificates. Consumer asks
> for /root/site1 data, p announced /root/site1 and r announced /root/KEY.
>
> Without repo and with an app publisher it works fine.
>
> My steps are:
>
> //Generation of the certification chain
> At the end, the root has the certificate of the producer
> "site1.ndncert" and its own (root.ndncert).
>
> //Modify repo-ng.conf
> Actually I have no idea how to do. I just modified the prefixes in
> "/root/KEY", and I put the config file in /usr/local/etc/ndn and /etc/ndn
> folders. I attached it.
>
> //Put the certificate
> I put the certificate site1.ndncert in the root folder and publisher
> folder.
>
> //Publish the certificate:
> r /home/bertolino/Desktop/miniNDN/mini-ndn/repo-ng/build/ndn-repo-ng &
> (where r is the root authority node)
>
> r base 64 -d site1.ndncert | nc localhost 7376
>
> Then, r receives the request for the interest /root/KEY/site1 etc but it
> is not able to satisfy it.
> In particular:
> Sending /root/site1?ndn.MustBeFresh=1&ndn.InterestLifetime=1000
> failedCannot fetch cert: /root/KEY/site1/ksk-1475484935283/ID-CERT
>
> Any help is particularly appreciated,
> Thank you very much,
> Yours Matteo
>
>
>
> ------------------------------------------------------------
> -------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161003/5c5cee72/attachment.html>

From Matteo.Bertolino at eurecom.fr  Mon Oct  3 07:50:54 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Mon, 03 Oct 2016 16:50:54 +0200
Subject: [Ndn-interest] How to use repo-ng?
In-Reply-To: <CAOFH+OYf1yFwA7rnHkUzFQ1qa7fV=C+V2xMLYjzvnB3CVKReCw@mail.gmail.com>
References: <20161003114240.3y6aqogpc88wg84w@webmail.eurecom.fr>
	<CAOFH+OYf1yFwA7rnHkUzFQ1qa7fV=C+V2xMLYjzvnB3CVKReCw@mail.gmail.com>
Message-ID: <20161003165054.t6iz2l6eio04040o@webmail.eurecom.fr>

Dear Junxiao,
Thank you for your answer.
No, I am not able. Here the resume on the node r:

/root/site1
   +->* /root/site1/ksk-1475505906705
        +->*  
/root/KEY/site1/ksk-1475505906705/ID-CERT/%FD%00%00%01W%8B%01%B0%84


FIB (on a gateway before r):
[..]
/root/KEY nexthops={faceid=266 (cost=10)}

But:
r /home/bertolino/Desktop/miniNDN/mini-ndn/ndn-tools/build/bin/ndnpeek  
/root/KEY/site1/ksk-1475505906705/ID-CERT/%FD%00%00%01W%8B%01%B0%84

---> No output

I tried a second approach, which ndnputfile. But I obtain just the  
string "ERROR check response timeout."

Finally, I tried to install ndns, but when I do sudo ./waf it told me:  
"ERROR: BASE64 is not part of ndn:io class".

I have no more idea and I am a bit demotivated, do you have an idea ?

Thank you,
Yours, Matteo





Quoting Junxiao Shi <shijunxiao at email.arizona.edu>:

> Hi Matteo
>
> Things to look for:
>
> 1. Are you able to fetch the certificate on node r with ndnpeek?
> 2. If yes, pipe the output to ndn-dissect. Does the Data packet look
> correct? It should have the proper ContentType as a certificate.
> 3. Are there proper FIB entries from the node trying to fetch the
> certificate to node r?
>
> Yours, Junxiao
>
> On Oct 3, 2016 02:43, "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
> wrote:
>
>> Good morning community,
>> I would like to exploit repo-ng in order to distribute certificates.
>>
>> I tried, but I failed and I do not understand how to do.
>>
>> Supposing a topology in which I have a consumer, a producer and a root
>> authority. The root authority sign the certificate of the producer,
>> the consumer trust in the root authority. Suppose that the same node
>> of the root authority distributes also the certificates. Consumer asks
>> for /root/site1 data, p announced /root/site1 and r announced /root/KEY.
>>
>> Without repo and with an app publisher it works fine.
>>
>> My steps are:
>>
>> //Generation of the certification chain
>> At the end, the root has the certificate of the producer
>> "site1.ndncert" and its own (root.ndncert).
>>
>> //Modify repo-ng.conf
>> Actually I have no idea how to do. I just modified the prefixes in
>> "/root/KEY", and I put the config file in /usr/local/etc/ndn and /etc/ndn
>> folders. I attached it.
>>
>> //Put the certificate
>> I put the certificate site1.ndncert in the root folder and publisher
>> folder.
>>
>> //Publish the certificate:
>> r /home/bertolino/Desktop/miniNDN/mini-ndn/repo-ng/build/ndn-repo-ng &
>> (where r is the root authority node)
>>
>> r base 64 -d site1.ndncert | nc localhost 7376
>>
>> Then, r receives the request for the interest /root/KEY/site1 etc but it
>> is not able to satisfy it.
>> In particular:
>> Sending /root/site1?ndn.MustBeFresh=1&ndn.InterestLifetime=1000
>> failedCannot fetch cert: /root/KEY/site1/ksk-1475484935283/ID-CERT
>>
>> Any help is particularly appreciated,
>> Thank you very much,
>> Yours Matteo
>>
>>
>>
>> ------------------------------------------------------------
>> -------------------
>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>>
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From shijunxiao at email.arizona.edu  Mon Oct  3 08:26:10 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 3 Oct 2016 08:26:10 -0700
Subject: [Ndn-interest] How to use repo-ng?
In-Reply-To: <20161003165054.t6iz2l6eio04040o@webmail.eurecom.fr>
References: <20161003114240.3y6aqogpc88wg84w@webmail.eurecom.fr>
	<CAOFH+OYf1yFwA7rnHkUzFQ1qa7fV=C+V2xMLYjzvnB3CVKReCw@mail.gmail.com>
	<20161003165054.t6iz2l6eio04040o@webmail.eurecom.fr>
Message-ID: <CAOFH+Ob4Qt9tW3xZ0Ze7PUtb1f23uJQsC+UCFpe+4kUgo0eoZA@mail.gmail.com>

Hi Matteo


> r /home/bertolino/Desktop/miniNDN/mini-ndn/ndn-tools/build/bin/ndnpeek
> /root/KEY/site1/ksk-1475505906705/ID-CERT/%FD%00%00%01W%8B%01%B0%84
>
> ---> No output
>
This indicates either the certificate is not properly inserted to repo-ng,
or repo-ng is not answering the Interest.

Finally, I tried to install ndns, but when I do sudo ./waf it told me:
> "ERROR: BASE64 is not part of ndn:io class".
>
ndn::io::BASE64 is added to ndn-cxx on Sep 03. Your ndn-cxx version is too
old.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161003/82be3ef7/attachment.html>

From Matteo.Bertolino at eurecom.fr  Mon Oct  3 08:36:21 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Mon, 03 Oct 2016 17:36:21 +0200
Subject: [Ndn-interest] How to use repo-ng?
In-Reply-To: <CAOFH+Ob4Qt9tW3xZ0Ze7PUtb1f23uJQsC+UCFpe+4kUgo0eoZA@mail.gmail.com>
References: <20161003114240.3y6aqogpc88wg84w@webmail.eurecom.fr>
	<CAOFH+OYf1yFwA7rnHkUzFQ1qa7fV=C+V2xMLYjzvnB3CVKReCw@mail.gmail.com>
	<20161003165054.t6iz2l6eio04040o@webmail.eurecom.fr>
	<CAOFH+Ob4Qt9tW3xZ0Ze7PUtb1f23uJQsC+UCFpe+4kUgo0eoZA@mail.gmail.com>
Message-ID: <20161003173621.8gx8d8frc48g8sos@webmail.eurecom.fr>

Dear Junxiao, thanks.
Ok, I understand the problem. Since I am really confused and I am  
trying 3 different approaches without success, I need to focus just on  
one.
The possible are:
- Publishing the certificates with repo-ng, using ndnputfile.
- Publishing the certificates with repo-ng, using base64 -d namecert |  
nc localhost 7376
- Publishing the certificates using ndns

Which among these 3 do you advice me ?
If you advice me a solution repo-ng based, can you imagine why repo-ng  
does not answer to the interest properly ? Because I followed step by  
step the instructions that I found on another discussion in the  
mailing list.. Maybe the repo-ng.conf wrong?

Thank you very much for your help,
Yours Matteo

Quoting Junxiao Shi <shijunxiao at email.arizona.edu>:

> Hi Matteo
>
>
>> r /home/bertolino/Desktop/miniNDN/mini-ndn/ndn-tools/build/bin/ndnpeek
>> /root/KEY/site1/ksk-1475505906705/ID-CERT/%FD%00%00%01W%8B%01%B0%84
>>
>> ---> No output
>>
> This indicates either the certificate is not properly inserted to repo-ng,
> or repo-ng is not answering the Interest.
>
> Finally, I tried to install ndns, but when I do sudo ./waf it told me:
>> "ERROR: BASE64 is not part of ndn:io class".
>>
> ndn::io::BASE64 is added to ndn-cxx on Sep 03. Your ndn-cxx version is too
> old.
>
> Yours, Junxiao
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From compagno at di.uniroma1.it  Tue Oct  4 07:41:03 2016
From: compagno at di.uniroma1.it (Alberto Compagno)
Date: Tue, 4 Oct 2016 16:41:03 +0200
Subject: [Ndn-interest] Security and Privacy Analysis of NSF Future Internet
 Architectures
Message-ID: <599C480E-05A8-408D-AD3F-DD811CCADA79@di.uniroma1.it>

Dear All, 

In the last period, I have been involved in a work which goal was to provide a thorough analysis and evaluation of security and privacy features in the four NFS funded FIA projects (NDN, XIA, MobilityFirst, Nebula). Such work is currently under submission on IEEE COMST, but me and the other authors decided to make it available on arXiv before its actual publication. In case you are interested to read it, this is the link to our paper:

http://arxiv.org/abs/1610.00355 <http://arxiv.org/abs/1610.00355>

We look forward to any comment and feedback from the community. Thank you in advance for your contribution.

Best Regards,
Alberto Compagno

PhD candidate in Computer Science, 
Sapienza University of Rome 
Department of Computer Science
personal website: https://sites.google.com/a/di.uniroma1.it/compagno/ <https://sites.google.com/a/di.uniroma1.it/compagno/>
SPRITZ security group: http://spritz.math.unipd.it <http://spritz.math.unipd.it/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161004/a4e5c5f2/attachment.html>

From mayutan.arumaithurai at gmail.com  Tue Oct  4 01:30:48 2016
From: mayutan.arumaithurai at gmail.com (Mayutan A.)
Date: Tue, 4 Oct 2016 10:30:48 +0200
Subject: [Ndn-interest] ACM SIGCOMM 2017 @ UCLA,
 Los Angeles: Call for Papers and Experience Track (Registration
 Deadline: January 20, 2017)
Message-ID: <CAADkTf25Y7GqFnT3J_ginceHvq55wHwkAecvJBC+6iHS=+iNnA@mail.gmail.com>

ACM SIGCOMM 2017
CALL FOR PAPERS, EXPERIENCE TRACK
http://conferences.sigcomm.org/sigcomm/2017/cfp.html


The ACM SIGCOMM 2017 conference seeks papers describing significant
research contributions to the field of computer and data communication
networks. We invite submissions on a wide range of networking research,
including, but not limited to:

    Network architectures and algorithms
    Distributed systems design, implementation & application
    Enterprise, datacenter, and storage area networks
    SDN, NFV, and network programming
    Experimental results from operational networks or network applications
    Measurement of and statistics methods/machine learning/dat mining
applied to networks
    Network monitoring and diagnosis
    Formal methods and network verification
    Economic aspects of the Internet
    Energy-aware communication
    Network management and operations
    Network security and privacy, censorship, transparency
    Network, transport, and application-layer protocols
    Fault-tolerance, reliability, and troubleshooting
    Operating system and host support for networking
    Novel physical layer technologies
    Networking hardware (Router/switch/NIC) design
    P2P and content (including video) distribution networks
    Cloud and wide-area networking systems & infrastructure
    Resource management, QoS, and signaling
    Routing, traffic engineering, switching, and addressing
    Wireless, mobile, and sensor networks
    Edge, access, and home networks
    Innovative uses of network data beyond communication

In addition to the main conference, SIGCOMM 2017 will have a series of
co-located workshops, tutorials, poster and demo sessions, a travel grant
program, and conference best paper(s) and SIGCOMM awards. For the criteria
for the selection of the conference best paper award(s), see Best Paper
Award Guidelines.
Submissions

SIGCOMM is a highly selective conference where full papers typically report
novel results firmly substantiated by experimentation, deployment,
simulation, or analysis. Submissions should be in two-column, 10-point
format, and can be up to 12 pages in length with as many additional pages
as necessary for references. Detailed submission instructions can be found
on the conference web site.


EXPERIENCE TRACK


In addition to submissions considered for the standard track, SIGCOMM 2017
will also include a submission category for experience papers on the
design, analysis, and evaluation of techniques in commercial (or otherwise
widespread) deployment. Authors must explicitly indicate whether a
submission is to be considered for this track or the standard track.
(Further information in the detailed submission instructions.)

ETHICAL CONCERNS

Authors must as part of the submission process attest that their work
complies with all applicable ethical standards of their home
institution(s), including, but not limited to privacy policies and policies
on experiments involving humans. Note that submitting research for approval
by one?s institution?s ethics review body is necessary, but not sufficient
? in cases where the PC has concerns about the ethics of the work in a
submission, the PC will have its own discussion of the ethics of that work.
The PC takes a broad view of what constitutes an ethical concern, and
authors agree to be available at any time during the review process to
rapidly respond to queries from the PC chairs regarding ethical standards.

AUTHORS TAKE NOTE

The official publication date is the date the proceedings are made
available in the ACM Digital Library. This date may be up to TWO WEEKS
prior to the first day of your conference. The official publication date
affects the deadline for any patent filings related to published work.

Important Dates
    Paper Registration Deadline: January 20, 2017 (5:00pm PST)
    Paper Submission Deadline: January 27, 2017 (5:00pm PST)
    Acceptance Notification: May 5, 2017
    Conference dates: August 21-25, 2017
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161004/5df1e8f2/attachment.html>

From aa at CS.UCLA.EDU  Tue Oct  4 19:58:09 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Tue, 4 Oct 2016 19:58:09 -0700
Subject: [Ndn-interest] [NDN-TR] NDN-0021 revision 7: NFD Developer's Guide
Message-ID: <895924DE-DEFD-4B23-A396-F56619AD602F@cs.ucla.edu>

A new revision of NDN Technical report is now available on NDN website.
Comments and suggestions are highly welcome.

  Title         : NFD Developer's Guide
  Authors       : Alexander Afanasyev, Junxiao Shi, Beichuan Zhang, Lixia Zhang,
                  Ilya Moiseenko, Yingdi Yu, Wentao Shang, Yanbiao Li, Spyridon
                  Mastorakis, Yi Huang, Jerald Paul Abraham, Steve DiBenedetto,
                  Chengyu Fan, Christos Papadopoulos, Davide Pesavento, Giulio
                  Grassi, Giovanni Pau, Hang Zhang, Tian Song, Haowei Yuan, Hila
                  Ben Abraham, Patrick Crowley, Syed Obaid Amin, Vince Lehman,
                  Muktadir Chowdhury, and Lan Wang
  Number        : NDN-0021
  Revision      : 7
  Revision Date : October 4, 2016

Abstract:
   NDN Forwarding Daemon (NFD) is a network forwarder that implements the Named
   Data Networking (NDN) protocol. NFD is designed with modularity and
   extensibility in mind to enable easy experiments with new protocol features,
   algorithms, and applications for NDN. To help developers extend and improve
   NFD, this document explains NFD's internals including the overall design,
   major modules, their implementations, and their interactions.

Information page for this TR:
   http://named-data.net/publications/techreports/ndn-0021-7-nfd-developer-guide/

Direct link to PDF:
   https://named-data.net/wp-content/uploads/2016/10/ndn-0021-7-nfd-developer-guide.pdf

Difference highlights from the previous revision:
   http://named-data.net/wp-content/uploads/2016/10/ndn-0021-diff-6..7-nfd-developer-guide.pdf

Other NDN Technical Reports:
   http://named-data.net/publications/techreports/




From aa at CS.UCLA.EDU  Tue Oct  4 22:08:59 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Tue, 4 Oct 2016 22:08:59 -0700
Subject: [Ndn-interest] NFD version 0.5.0 release
Message-ID: <D65091B4-D93D-438D-9640-B57CD8F8897F@cs.ucla.edu>

Dear all,

We are pleased to announce the release of version 0.5.0 of Named Data
Networking Forwarding Daemon (NFD).

The detailed notes for the release: 
  https://named-data.net/doc/NFD/0.5.0/RELEASE_NOTES.html

***
Please note that this release contains several breaking changes.  See
more details in the release notes.
***

Source code, instruction how to install NFD on Ubuntu Linux (14.04,
and 16.04) and macOS (10.10, 10.11, 10.12), tutorials, HOWTOs, a FAQ
and other useful resources are available on the official NFD
website:
  https://named-data.net/doc/NFD/0.5.0/

Binary packages of Ubuntu Linux will be available soon in our PPA
repository (https://launchpad.net/~named-data/+archive/ubuntu/ppa)

* * *

Other related updates:

- ndn-cxx library to version 0.5.0
  https://named-data.net/doc/ndn-cxx/0.5.0/RELEASE_NOTES.html

- NFD Developer's Guide to revision 7:
  https://named-data.net/publications/techreports/ndn-0021-6-nfd-developer-guide/

- NDN Essential Tools to version 0.4:
  https://github.com/named-data/ndn-tools

* * *

A special welcome to Zhiyi Zhang, our new contributor.

* * *

The NDN/NFD Team:
  Alexander Afanasyev, Junxiao Shi, Beichuan Zhang, Lixia Zhang, Ilya Moiseenko,
  Yingdi Yu, Wentao Shang, Yanbiao Li, Spyridon Mastorakis, Yi Huang, Jerald Paul
  Abraham, Steve DiBenedetto, Chengyu Fan, Christos Papadopoulos, Davide Pesavento,
  Giulio Grassi, Giovanni Pau, Hang Zhang, Tian Song, Haowei Yuan, Hila Ben Abraham,
  Patrick Crowley, Syed Obaid Amin, Vince Lehman, Lan Wang, Eric Newberry, Yukai Tu,
  Muktadir Chowdhury, and others (https://named-data.net/project/participants/)




From josh at caida.org  Wed Oct  5 09:02:19 2016
From: josh at caida.org (Josh Polterock)
Date: Wed, 5 Oct 2016 09:02:19 -0700
Subject: [Ndn-interest] Named Data Networking (NDN) Project Monthly
 Newsletter for September 2016
Message-ID: <20161005160219.GB14343@caida.org>

Named Data Networking (NDN) Project Newsletter for September 2016

The NDN project team compiles and publishes this newsletter periodically
to inform the community about recent activities, technical news,
meetings, publications, presentations, code releases, and upcoming
events. You can find these newsletters posted on the Named Data
Networking Project blog.

COMMUNITY OUTREACH

* Call for proposals: The 3rd Named Data Networking (NDN) Hackathon
  November 4-5th, Colorado State University, Fort Collins, CO
  Submission deadline: October 26, 2016
  Acceptance notification: October 31, 2016
  http://3rd-ndn-hackathon.named-data.net

* As part of ICN 2016, the NDN Team presented a full-day
  tutorial on "Exploring NDN Research through Real World Problem
  Solving" at the 3rd ACM Conference on Information Centric Networking (ICN 2016). 
  http://conferences2.sigcomm.org/acm-icn/2016/tutorial-ndn.php

* Coming up in December 2016, adjacent to IEEE Globecom 2016 at the
  Workshop on Information Centric Networking Solutions for Real
  World Applications (ICNSRA 2016) in Washington D.C., the NDN team
  will present two publications (listed below) as well as participate
  on a panel discussing "Application of ICN in Infrastructure-Free
  Environments: Rural Areas, Disaster Recovery, and Military Tactical
  Environments.  http://icnsra.nz.comm.waseda.ac.jp/?page_id=61

* Save the date: We have revised our plans to host the next NDNcomm
  at the University of Memphis March 23-24, 2017 immediately preceding
  IETF 97 in Chicago. We will hold the 4th NDN Hackathon immediately
  preceding NDNcomm on 22 March, 2017. Lan Wang and Christos Papadopolous
  will serve as co-chairs.

TECHNICAL NEWS

 * We released version 0.5.0 of Named Data Networking Forwarding
   Daemon (NFD) and ndn-cxx library.

   The detailed release notes:
    - for NFD: http://named-data.net/doc/NFD/0.5.0/RELEASE_NOTES.html
    - for ndn-cxx library: http://named-data.net/doc/ndn-cxx/0.5.0/RELEASE_NOTES.html

   More details about NFD, tutorials, HOWTOs, a FAQ and other useful
   resources are available on official webpages of NFD and ndn-cxx:
    - http://named-data.net/doc/NFD/0.5.0/
    - http://named-data.net/doc/ndn-cxx/0.5.0/

 * The Department of Energy announced that startup Operant Solar is
  a SunShot winner for a project using NDN.  Operant will apply NDN
  for networking in their residential solar panel communications
  system in collaboration with UCLA to build a running prototype.
  http://www.operantsolar.com/news.html


NDN PUBLICATIONS, PRESENTATIONS, and TECHNICAL REPORTS

* NDN TR-21 Revision 7: Alexander Afanasyev, Junxiao Shi, Beichuan
  Zhang, Lixia Zhang, Ilya Moiseenko, Yingdi Yu, Wentao Shang,
  Yanbiao Li, Spyridon Mastorakis, Yi Huang, Jerald Paul Abraham,
  Steve DiBenedetto, Chengyu Fan, Christos Papadopoulos, Davide
  Pesavento, Giulio Grassi, Giovanni Pau, Hang Zhang, Tian Song,
  Haowei Yuan, Hila Ben Abraham, Patrick Crowley, Syed Obaid Amin,
  Vince Lehman, Muktadir Chowdhury, and Lan Wang, "NFD Developer's
  Guide" To help developers extend and improve NFD, this document
  explains NFD's internals including overal design, major modules,
  their implementations, and their interactions.
  http://named-data.net/publications/techreports/ndn-0021-7-nfd-developer-guide/

* As part of an Internet2 Technical Exchange Featured Session , PI
  k claffy presented "A Brief History of a Future Internet: The
  Named Data Networking Architecture," a pre-event webinar streamable at
  http://www2.internet2.edu/e/66332/ndnicnintrowebinar20160914/8ss9vw/217961922

* We published a new video faq by J. Alex Halderman on security
  https://vimeo.com/channels/ndnvfaq


SEMINARS

* The NDN seminars are internally focused. If you would like to
  participate in the NDN Seminars, please contact the PoC, UCLA
  PhD. candidate Spyridon Mastorakis <Spiros.mastorakis at gmail.com>
  for the most up-to-date information regarding upcoming seminars.

   - 5 October 2016 2pm Wentao Shang (UCLA), "The Design and Implementation of the NDN Protocol Stack for RIOT-OS" 

RELATED NEWS

* NSF CI-NEW: Collaborative: Building the Core NDN Infrastructure
  to Advance Information-Centric Networking Research, $2.5M,
  9/1/2016-8/31/2019.  University of Arizona (Beichuan Zhang, lead),
  UCLA (Jeff Burke, Lixia Zhang), University of Memphis (Lan Wang),
  Washington University at St. Louis (Patrick Crowley).

  The goal of this project is to support the evaluation, experimentation,
  and further development of the Named Data Networking (NDN) architecture
  through building the core NDN infrastructure as a community resource,
  serving to advance research in the Information-Centric Networking
  (ICN) paradigm.
  http://nsf.gov/awardsearch/showAward?AWD_ID=1629769


* IEEE Access Journal (Indexed by SCI-E, IF: 1.270) is
  accepting submissions to our Special Section on "Future Networks:
  Architectures, Protocols, and Applications."
  http://ieeeaccess.ieee.org/special-sections/future-networks-architectures-protocols-applications/

For more information about the Named Data Networking (NDN) Project
please visit http://www.named-data.net/.




From susmit at cs.colostate.edu  Wed Oct  5 10:51:39 2016
From: susmit at cs.colostate.edu (Susmit)
Date: Wed, 5 Oct 2016 11:51:39 -0600
Subject: [Ndn-interest] 3rd NDN Hackathon: Registration Link
Message-ID: <CAM4XVkrOSTCdw7JzQ6b7rARexJzW42y+gC48_kSym=fEjiJinA@mail.gmail.com>

Please register below if you are planning to participate in the
upcoming NDN hackathon.
https://www.eventbrite.com/e/3rd-ndn-hackathon-tickets-28368329437

The call for participation is here:
http://3rd-ndn-hackathon.named-data.net/cfh.html

------------------------------------------
IMPORTANT DATES
------------------------------------------
Submission deadline: October 26, 2016
Acceptance notification: October 31, 2016
Hackathon: Nov 4th and 5th, 2016

We look forward to your participation.


From sepehrabdous at yahoo.com  Wed Oct  5 15:37:16 2016
From: sepehrabdous at yahoo.com (Sepehr Abdous)
Date: Wed, 5 Oct 2016 22:37:16 +0000 (UTC)
Subject: [Ndn-interest] NLSR in ndnSim
References: <1332862648.5080687.1475707036843.ref@mail.yahoo.com>
Message-ID: <1332862648.5080687.1475707036843@mail.yahoo.com>

Hello All,?
Could?someone?tell me if there is any implementation of NLSR in ndnSim?

Bests,Sepehr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161005/0aa3c2a3/attachment.html>

From list-ndn at cgundogan.de  Thu Oct  6 01:39:36 2016
From: list-ndn at cgundogan.de (Cenk =?utf-8?B?R8O8bmRvxJ9hbg==?=)
Date: Thu, 6 Oct 2016 10:39:36 +0200
Subject: [Ndn-interest] NLSR in ndnSim
In-Reply-To: <1332862648.5080687.1475707036843@mail.yahoo.com>
References: <1332862648.5080687.1475707036843.ref@mail.yahoo.com>
	<1332862648.5080687.1475707036843@mail.yahoo.com>
Message-ID: <20161006083936.GA25648@cgundogan.localdomain>

Hello Sepehr,

Judging by the mails in [1,2], I assume there is still ongoing work in
that direction. I quickly grep'ed through the code of the current ndnSim
version and couldn't find any references to NLSR.

Take this with a grain of salt, though, as my knowledge about ndnSim is
rather limited. You might attract more experts by asking on the ndnSim
mailing list [3].

Best,
Cenk

[1] http://www.lists.cs.ucla.edu/pipermail/ndnsim/2015-April/001836.html
[2] http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2016-May/001133.html
[3] http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim

On 16-10-05 22:37:16, Sepehr Abdous wrote:
> Hello All,?
> Could?someone?tell me if there is any implementation of NLSR in ndnSim?
> 
> Bests,Sepehr

> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest


-- 
Cenk G?ndo?an

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49 40 42875 - 8426
Mail: cenk.guendogan at haw-hamburg.de
Web: https://www.inet.haw-hamburg.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161006/ee8e9561/attachment.bin>

From lanwang at memphis.edu  Thu Oct  6 05:02:30 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Thu, 6 Oct 2016 12:02:30 +0000
Subject: [Ndn-interest] NLSR in ndnSim
In-Reply-To: <20161006083936.GA25648@cgundogan.localdomain>
References: <1332862648.5080687.1475707036843.ref@mail.yahoo.com>
	<1332862648.5080687.1475707036843@mail.yahoo.com>
	<20161006083936.GA25648@cgundogan.localdomain>
Message-ID: <E43F4E7C-DAC9-4E20-B54E-40750BCC4615@memphis.edu>

Cenk is right.  Anil Jangam has been working on porting NLSR to ndnSIM.  I?m cc?ing him.

Lan

> On Oct 6, 2016, at 3:39 AM, Cenk G?ndo?an <list-ndn at CGUNDOGAN.DE> wrote:
> 
> Hello Sepehr,
> 
> Judging by the mails in [1,2], I assume there is still ongoing work in
> that direction. I quickly grep'ed through the code of the current ndnSim
> version and couldn't find any references to NLSR.
> 
> Take this with a grain of salt, though, as my knowledge about ndnSim is
> rather limited. You might attract more experts by asking on the ndnSim
> mailing list [3].
> 
> Best,
> Cenk
> 
> [1] http://www.lists.cs.ucla.edu/pipermail/ndnsim/2015-April/001836.html
> [2] http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2016-May/001133.html
> [3] http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
> 
> On 16-10-05 22:37:16, Sepehr Abdous wrote:
>> Hello All, 
>> Could someone tell me if there is any implementation of NLSR in ndnSim?
>> 
>> Bests,Sepehr
> 
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> 
> 
> -- 
> Cenk G?ndo?an
> 
> Hamburg University of Applied Sciences
> Dept. of Computer Science / Internet Technologies Group
> Berliner Tor 7, 20099 Hamburg, Germany
> Fon: +49 40 42875 - 8426
> Mail: cenk.guendogan at haw-hamburg.de
> Web: https://www.inet.haw-hamburg.de/
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




From g.white at cablelabs.com  Thu Oct  6 11:17:26 2016
From: g.white at cablelabs.com (Greg White)
Date: Thu, 6 Oct 2016 18:17:26 +0000
Subject: [Ndn-interest] Label swap vs PIT (was Re: Largest DDoS attack
 ever delivered by botnet of hijacked IoT devices)
In-Reply-To: <CADQ0MFYeRSyR4pkonqFCR0M6UpxpE50ypsdCW5kB0fW1yON_7Q@mail.gmail.com>
References: <e080b8b3-13e8-6fd3-78f3-9368cba17b7f@colostate.edu>
	<74053D77-64FD-4076-B8A6-D35E18853CF0@cs.ucla.edu>
	<CAAj99KkVfCs7RUGcxd7cpQD_k1eYBPzDpbs-p3T9aAWcnReUFQ@mail.gmail.com>
	<FDDA7C7B-0778-4742-A209-A0353695348B@cs.ucla.edu>
	<CAFPbCdEUjWXb-W7vEtcGJpxbsNvWfHXFNVLW=FXNs3nTEbH_Jg@mail.gmail.com>
	<72074e38-b289-00a0-4cc0-0bce0b1a3b99@colostate.edu>
	<CAO8oSXmhwuSPY2onATrFqige0Q8eNB1bFLz+=U4+gZ0FxV5ttQ@mail.gmail.com>
	<6EBCC13F-3CBA-4031-AD05-7B54EF87EEC6@parc.com>
	<CAHx=1M4XJ07h32CxTcEGMPdq38L2JhSEKDznu48LAdPc5nxLQQ@mail.gmail.com>
	<55611889-29be-8b4e-a401-74f890175ec7@ics.uci.edu>
	<77C968E5-F44B-46BD-BCDD-A1EACA91EE25@parc.com>
	<CAHx=1M66hUPia5qp-1kNMvTr83uafwBzrOt1RZznnMU-aut+oQ@mail.gmail.com>
	<7D429D07-287E-43A4-8605-CCAFF40A938D@parc.com>
	<CADQ0MFYeRSyR4pkonqFCR0M6UpxpE50ypsdCW5kB0fW1yON_7Q@mail.gmail.com>
Message-ID: <1EAAA0B7-7338-4149-A5C4-3C303EB5D0B1@cablelabs.com>

I?m not sure if this specific idea has been explored before, but we came up with another PIT-less approach earlier this year after considering the Bloom-filter based approaches.  It seemed to us that the Bloom filter approach was perhaps too clever for its own good, and that a simpler approach might have better characteristics (e.g. zero false positives and trivial computational complexity).

Given that the vast majority of forwarders (maybe all) will have less than 256 faces, the value of N would almost always be 1, and thus the maximum size (in bytes) of the face-stack would effectively be D (where D is the diameter of the network or AS), and the average size of the face-stack would be d/2 (where d is the average path length).    The Bloom-filter approaches seem to use BF sizes of 16 or 32 bytes, which is likely larger than d/2 (and perhaps even larger than D).  Also, while it would be slightly more complex to implement, face labels could even be an integer number of bits rather than bytes, which would make the average face-stack only k*d/2 bits (where k is log2(average(degree)) ).

-Greg


From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu> on behalf of Muhammad Hosain Abdollahi Sabet <mhasabet at gmail.com>
Date: Thursday, September 29, 2016 at 6:19 PM
To: Marc Mosko <Marc.Mosko at parc.com>
Cc: "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>, "christos at colostate.edu" <christos at colostate.edu>
Subject: Re: [Ndn-interest] Label swap vs PIT (was Re: Largest DDoS attack ever delivered by botnet of hijacked IoT devices)


Marc,

There is nothing in JJ's latter proposal in ICN 2016 indicating anchors' identifiers are not anchors' names. Actually the namespaces could be the same. So name lookup can still hold.

Thanks,
Sabet

On 29 Sep 2016 10:11 am, <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>> wrote:
In the earlier label-swapping proposals, some of which are JJ?s, it is true that the Interest is routed per-hop via the name and the labels are established only to label swap back the Data.  The state space scales in the number of flows through a node.

In some of the later proposals, such as the paper JJ just presented at ICN 2016, because the routing is done on anchors one no longer needs to do a lookup on names at every hop, but on anchor identifiers.  I think it also went further in that once a forward path label is picked for an Interest, it could be label swapped in the forward direction too (assuming an SVC was already setup for that destination).  In this respect, the switching of interests and data inside the network is no different and only the edge devices need to do different computations on them.

Marc


On Sep 29, 2016, at 9:47 AM, Luca Muscariello <luca.muscariello at gmail.com<mailto:luca.muscariello at gmail.com>> wrote:

I think the PIT is not just a question of interests aggregation. It is more than that.
We need to be careful in comparing forwarding and the way routing is/can be built  on top of a given forwarding plane.

I read JJ's paper but not yet Gene's and Ravi's.
If Ravi's can send a preprint that would help the discussion.

Of course I would expect the authors of such papers to make the comparison we look for in the papers.

Why is the PIT more than just aggregation?

In CCN only Interests are routed. Data is in a way label switched by using local state. The name in the data is used to implement label switching and to follow the bread crumbs. But in principle you could use a token to implement data forwarding.
Still this token state space would scale with the interest names state space.

So the label switching proposed by JJ scales better because the system has changed state space of the labels. JJ is using an address space and not a name space. The assumption is that the address state space is way smaller. And it is true.

So the big change in JJ design is this one and not label swapping per se.

I read other papers proposing that like Carzaniga's work (ICN 2014) but I would like to read Gene's work and also Ravi's work to see how the solved the issue.

Now routing on locators is a whole new thread I guess. But PIT-less design that route on names is different. Again I need to check the new papers.

Luca









On Thursday, 29 September 2016, <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>> wrote:
This message got a bit off topic from the OP, so I label swapped the subject ;)

I think preserving the possibility of symmetric paths is a significant feature.  It is the main property that new congestion control protocols use and I think an attribute that deserves serious thought.

I agree with Luca that going label swapping instead of PIT trades one set of features for another set of features.  I think it would be useful to systematically list the features offered by the PIT and the features offered by label swapping.  One could then make a principled comparison between them.

I believe that the main feature lost is Interest aggregation.  If one has caching, then I think this is a minor loss.  The window for Interest aggregation to work is a RTT.  The window for caching to work could be much longer.  All the memory one was spending on the per-packet PIT state can now be used for more caching.  It would be useful to look at flash crowd dynamics to see if even in those cases aggregation saves much compared to caching.

In the NDN architecture, one would also lose the PIT nonce state, but NFD already has a second nonce table to keep them around after a PIT entry is erased, so that could stay as it is.  It wouldn?t be exactly like now, but one could probably make nonces still work if one thinks keeping them is worth the memory usage.

A significant feature gained is a large reduction in memory bandwidth by not having to update a large data structure at wire speed.  As we saw today from JJ?s presentation, if one uses label swapping and routing on anchor identifiers, then one can make the case of running on today?s forwarding hardware at or near full speed.  Thus the time to deployment on high speed routers could really shrink down.

Anyway, I think this is worth more formal study rather than this piecewise analysis.

Marc

On Sep 29, 2016, at 5:26 AM, GTS <gts at ics.uci.edu> wrote:

To get back to the issue of having or not having the PIT:

Recall that this thread started with discussion of massive DoS attacks on
the current Internet, initiated from IoT devices. It progressed to a discussion
of DoS attacks in CCN. It was then suggested that a PIT-less
design might address the only glaring major type of DoS attack in CCN --
interest flooding. I specifically say "address", not "solve" or "obviate".
(That's because even a PIT-less design allows the producers to be interest-flooded).
Now, the particular PIT-less design that Cesar mentioned is this:

https://arxiv.org/abs/1512.07755

It is NOT motivated solely by interest flooding mitigation. It just happens
to be one of its features. The authors (of whom I'm one) would love to
hear some reasoned criticism of this PIT-less design. It should be based
on actually reading the paper.

More generally, the PIT is currently a fundamental feature of both NDN and CCNx.
Should it even be questioned? To some true believers, this is clearly an anathema.
IMHO, all architecture features should be up for debate and all dogmas ought to be questioned.
For example, I believe that the PIT and the CACHE (for example) are not what
make an architecture Content-Centric. Either or both can be removed and what
remains would still be a Content-Centric Network (though perhaps not a good one).

Finally, the PIT-less design mentioned above could well be ill-advised,
or even totally senseless. We simply don't know yet.
Indeed, as the paper admits, it has some problems of its own.
Or, it might make sense in some settings, e.g., where the
network infrastructure is mobile. Or, it might be an alternative/optional implementation.
(BTW, it can in fact co-exist with a PIT-ful CCN).

Cheers,
Gene



======================

Gene Tsudik

Chancellor's Professor of Computer Science

University of California, Irvine


On 9/27/16 10:12 PM, Luca Muscariello wrote:
The work JJ has presented this morning is probably another interesting thread.
And I agree that the signal mentioned here is not a prerogative of the PIT.

So, to stay in topic to this thread, from my point of you what JJ has proposed
has more compelling properties to remove the PIT than the DDoS example
considered here.

In JJ's proposition, you trade something for something else. It's not an equivalent
architecture to NDN though. So we need to be careful before laying away pieces of the architecture. There is a  price for that.



On Wednesday, 28 September 2016, <Marc.Mosko at parc.com> wrote:
Removing the PIT and using, for example, a label swapping approach such as J.J. Garcia-Luna-Aceves has suggested, does not remove the ?signal? you talk about.  One could keep upstream and downstream counters for each label swap identifier and see which labels are not getting downstream data.

I do not think the strategy of purging PIT entries based on the shortness of their remaining lifetime gives you any correlation to purging attack packets.  First of all, an attacker could easily use a very large Interest Lifetime.  Well-behaved clients that are using RTT estimates in their Interest Lifetime would, by definition, likely have very small margins in the Interest Lifetime remaining  before the Data comes back (personally, I think it is a problem to make InterestLifetime based on RTT, but that?s a different thread).


Marc

> On Sep 28, 2016, at 10:47 AM, christopherwood07 at gmail.com wrote:
>
> On September 27, 2016 at 5:14:14 PM, Christos Papadopoulos
> (christos at colostate.edu) wrote:
>>
>>
>> On 09/27/2016 04:59 PM, woodc1 at uci.edu wrote:
>>> To re-iterate Cesar?s point, as of now, there is no truly effective
>>> interest flooding mitigation. However, one concrete way to minimize
>>> the attack surface (for routers) is to get rid of the attack's root
>>> cause: the PIT. (Producers could still be hosed with bogus interests.)
>>> And since the PIT enables several important functions, other
>>> architecture changes will probably have to follow in its wake.
>>
>> You start with what I believe to be the wrong premise: protecting the
>> router. In NDN we care about communication, not a single router.
>> Protecting a router is winning the battle but losing the war.
>
> I respectfully disagree. If the adversary takes out the producer,
> there is no communication. If the adversary takes out the routers
> adjacent or otherwise on the path to the producer, there is no
> communication. Protecting the router(s) is equally important,
> especially since it may impact more than just a single producer.
>
>>
>> I don't understand your statement that the root cause of DDoS attacks is
>> the PIT. The root cause of DDoS is resource exhaustion.
>
> In these attack scenarios, the PIT *is* the resource being exhausted.
>
>>
>>>
>>> Personally, I don?t think we should settle with an architectural
>>> element that has a known (and quite severe) weakness simply because it
>>> enables some nice features in practice. The more serious design
>>> problems must be dealt with first, not last.
>>
>> You are underestimating the importance of the signal the PIT provides.
>> It is an important insight into the status of communication. The PIT
>> does not simply enable some "nice features". Think a bit harder about
>> the things you can do with this signal.
>
> In most attack scenarios, yes, it tells you when bogus interests are
> flooding a particular prefix and otherwise when communication is
> failing. But consider this scenario. Suppose you have a malicious
> producer cooperating with one or more malicious consumers. The
> consumers are quickly sending interests to this legitimate producer,
> who responds with legitimate data. The communication is not failing.
> Their goal is to do nothing other than saturate the PIT of some
> intermediate router. Per Spyros? follow-up suggestion, that router
> might kick out old, legitimate interests in favor of these malicious
> ones. Of course, this is fundamentally how we would expect one to deal
> with and manage a limited resource. So preventing this attack seems
> difficult for any approach. But the point is that this resource, the
> PIT, is easily abused in CCN/NDN.
>
> Chris
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest


_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest



_______________________________________________

Ndn-interest mailing list

Ndn-interest at lists.cs.ucla.edu

http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161006/c8e2b864/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Face-StackCCN.pdf
Type: application/pdf
Size: 438886 bytes
Desc: Face-StackCCN.pdf
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161006/c8e2b864/attachment.pdf>

From Matteo.Bertolino at eurecom.fr  Fri Oct  7 06:30:27 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Fri, 07 Oct 2016 15:30:27 +0200
Subject: [Ndn-interest] How to verify an interest packet
Message-ID: <20161007153027.z1lgw0gaps0k80sw@webmail.eurecom.fr>

Dear community,
I am having some problem in verifying an interest packet.
Specifically, the error is: Packet cannot pass any checkers.

A root authority signs the certificate of the sender of the interest

My file config is:
rule
{
   id "p rule"
   checker
   {
     type hierarchical
     sig-type rsa-sha256
   }
}
trust-anchor
{
   type file
   file-name /tmp/p/root.ndncert
}

So it is very simple.
The sender of the interest, signs the interest in this way:
Name producerId("/root/site2"); ///test/site2/user2
m_keyChain.signByIdentity(interest, producerId);

While the content producer verifies it so:
void onInterest(const InterestFilter& filter, const Interest& interest)
{
m_validator->validate(interest, bind(&Producer::sendData, this, _1),
                           bind(&Producer::onInterestValidationFailed,  
this, _1, _2));
   }

The interest sent has the key included in the name, I noticed:
/root/site1/%00%00%01W%9F8%C4%11/%5Dl%F4%D2%8F%C5%D1%D6/%165%1B%01%01%1C0%07.%08%04root%08%03KEY%08%05site2%08%11ksk-1475844947720%08%07ID-CERT/%17%FD%01%0  
[...]

Do you notice any error?
Yours,
Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From shijunxiao at email.arizona.edu  Sat Oct  8 00:28:27 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sat, 8 Oct 2016 00:28:27 -0700
Subject: [Ndn-interest] How to verify an interest packet
In-Reply-To: <20161007153027.z1lgw0gaps0k80sw@webmail.eurecom.fr>
References: <20161007153027.z1lgw0gaps0k80sw@webmail.eurecom.fr>
Message-ID: <57f8a01f.52dc620a.24c61.2d8c@mx.google.com>

Hi Matteo

What's the error reason passed to onInterestValidationFailed function?

Is the certificate properly published? In other words, can you retrieve the certificate by expressing an Interest using ndnpeel?

Yours, Junxiao

-----Original Message-----
From: "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
Sent: ?10/?7/?2016 6:31
To: "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
Subject: [Ndn-interest] How to verify an interest packet

Dear community,
I am having some problem in verifying an interest packet.
Specifically, the error is: Packet cannot pass any checkers.

A root authority signs the certificate of the sender of the interest

My file config is:
rule
{
   id "p rule"
   checker
   {
     type hierarchical
     sig-type rsa-sha256
   }
}
trust-anchor
{
   type file
   file-name /tmp/p/root.ndncert
}

So it is very simple.
The sender of the interest, signs the interest in this way:
Name producerId("/root/site2"); ///test/site2/user2
m_keyChain.signByIdentity(interest, producerId);

While the content producer verifies it so:
void onInterest(const InterestFilter& filter, const Interest& interest)
{
m_validator->validate(interest, bind(&Producer::sendData, this, _1),
                           bind(&Producer::onInterestValidationFailed,  
this, _1, _2));
   }

The interest sent has the key included in the name, I noticed:
/root/site1/%00%00%01W%9F8%C4%11/%5Dl%F4%D2%8F%C5%D1%D6/%165%1B%01%01%1C0%07.%08%04root%08%03KEY%08%05site2%08%11ksk-1475844947720%08%07ID-CERT/%17%FD%01%0  
[...]

Do you notice any error?
Yours,
Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161008/e6e15664/attachment.html>

From Matteo.Bertolino at eurecom.fr  Mon Oct 10 06:27:32 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Mon, 10 Oct 2016 15:27:32 +0200
Subject: [Ndn-interest] How to verify an interest packet
In-Reply-To: <57f8a01f.52dc620a.24c61.2d8c@mx.google.com>
References: <20161007153027.z1lgw0gaps0k80sw@webmail.eurecom.fr>
	<57f8a01f.52dc620a.24c61.2d8c@mx.google.com>
Message-ID: <20161010152732.xi35x8w7k8ogs4kc@webmail.eurecom.fr>

Dear Junxiao,
I took some days in order to update the software at new release, but  
the problem still persists.

Yes, the certificate is properly published. I can retrieve it, and if  
I use it to sign data all is OK. The problem is signing interests only..

The error reason is: Packet cannot pass any checkers.

Any ideas?
Thank you,
Matteo


Quoting Junxiao Shi <shijunxiao at email.arizona.edu>:

> Hi Matteo
>
> What's the error reason passed to onInterestValidationFailed function?
>
> Is the certificate properly published? In other words, can you   
> retrieve the certificate by expressing an Interest using ndnpeel?
>
> Yours, Junxiao
>
> -----Original Message-----
> From: "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
> Sent: ?10/?7/?2016 6:31
> To: "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
> Subject: [Ndn-interest] How to verify an interest packet
>
> Dear community,
> I am having some problem in verifying an interest packet.
> Specifically, the error is: Packet cannot pass any checkers.
>
> A root authority signs the certificate of the sender of the interest
>
> My file config is:
> rule
> {
>    id "p rule"
>    checker
>    {
>      type hierarchical
>      sig-type rsa-sha256
>    }
> }
> trust-anchor
> {
>    type file
>    file-name /tmp/p/root.ndncert
> }
>
> So it is very simple.
> The sender of the interest, signs the interest in this way:
> Name producerId("/root/site2"); ///test/site2/user2
> m_keyChain.signByIdentity(interest, producerId);
>
> While the content producer verifies it so:
> void onInterest(const InterestFilter& filter, const Interest& interest)
> {
> m_validator->validate(interest, bind(&Producer::sendData, this, _1),
>                            bind(&Producer::onInterestValidationFailed,
> this, _1, _2));
>    }
>
> The interest sent has the key included in the name, I noticed:
> /root/site1/%00%00%01W%9F8%C4%11/%5Dl%F4%D2%8F%C5%D1%D6/%165%1B%01%01%1C0%07.%08%04root%08%03KEY%08%05site2%08%11ksk-1475844947720%08%07ID-CERT/%17%FD%01%0
> [...]
>
> Do you notice any error?
> Yours,
> Matteo
>
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From tteixeira at engin.umass.edu  Mon Oct 10 13:11:54 2016
From: tteixeira at engin.umass.edu (Thiago Teixeira)
Date: Mon, 10 Oct 2016 20:11:54 +0000
Subject: [Ndn-interest] Large file transfer
Message-ID: <66c4002e96404de38016c7c3fb21b891@engin.umass.edu>

Hi folks,

I am experimenting with mobility in NDN and want to evaluate the performance and reliability under intermittent/disconnected networks. NDN-Ping and NDN-Chunks run fine; however, ndnchunks handles single small files (data packet less than 8800 B, if I'm not mistaken).

I've also tried the NDN file system app (NDNFS) with file sizes 10MB, 100MB, and 1GB. The files are successfully sync'ed with the end host over a three hop wireless network, but when I run tcpdump to monitor the traffic in the network, I don't see any UDP packets during the sync (I do see UDP packets when I run ndnchunks). I can see mDNS packets.
Can you explain if this is the right behavior, please?

I could only find this post from Aug-2015 regarding packet fragmentation- http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2015-August/000824.html

Thanks in advance,
Thiago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161010/22117097/attachment.html>

From list-ndn at cgundogan.de  Tue Oct 11 00:19:21 2016
From: list-ndn at cgundogan.de (Cenk =?utf-8?B?R8O8bmRvxJ9hbg==?=)
Date: Tue, 11 Oct 2016 09:19:21 +0200
Subject: [Ndn-interest] Large file transfer
In-Reply-To: <66c4002e96404de38016c7c3fb21b891@engin.umass.edu>
References: <66c4002e96404de38016c7c3fb21b891@engin.umass.edu>
Message-ID: <20161011071921.GA5940@cgundogan.localdomain>

Hello Thiago,

could it be that the face is pointing to a TCP socket instead?
Did you see TCP traffic with tcpdump? I never used ndnfs, but after
glancing into the code, it seems that ndnfs is (capable of)
creating a face on the server-side with an underlying TCP socket.
This could explain why you didn't see UDP traffic, although the files
get synced (?)

Best,
Cenk

On 16-10-10 20:11:54, Thiago Teixeira wrote:
> Hi folks,
> 
> I am experimenting with mobility in NDN and want to evaluate the performance and reliability under intermittent/disconnected networks. NDN-Ping and NDN-Chunks run fine; however, ndnchunks handles single small files (data packet less than 8800 B, if I'm not mistaken).
> 
> I've also tried the NDN file system app (NDNFS) with file sizes 10MB, 100MB, and 1GB. The files are successfully sync'ed with the end host over a three hop wireless network, but when I run tcpdump to monitor the traffic in the network, I don't see any UDP packets during the sync (I do see UDP packets when I run ndnchunks). I can see mDNS packets.
> Can you explain if this is the right behavior, please?
> 
> I could only find this post from Aug-2015 regarding packet fragmentation- http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2015-August/000824.html
> 
> Thanks in advance,
> Thiago

> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest


-- 
Cenk G?ndo?an

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49 40 42875 - 8426
Mail: cenk.guendogan at haw-hamburg.de
Web: https://www.inet.haw-hamburg.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161011/e5b7b217/attachment.bin>

From davide.pesavento at lip6.fr  Tue Oct 11 03:16:06 2016
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Tue, 11 Oct 2016 12:16:06 +0200
Subject: [Ndn-interest] Large file transfer
In-Reply-To: <66c4002e96404de38016c7c3fb21b891@engin.umass.edu>
References: <66c4002e96404de38016c7c3fb21b891@engin.umass.edu>
Message-ID: <CADfzvvbz+8t_2io3nv=x37Wc=zccjQ61tsLAas2X3zzRr85URw@mail.gmail.com>

On Mon, Oct 10, 2016 at 10:11 PM, Thiago Teixeira <tteixeira at engin.umass.edu
> wrote:

> Hi folks,
>
>
>
> I am experimenting with mobility in NDN and want to evaluate the
> performance and reliability under intermittent/disconnected networks.
> NDN-Ping and NDN-Chunks run fine; however, ndnchunks handles single small
> files (data packet less than 8800 B, if I?m not mistaken).
>

This is partially incorrect. ndncatchunks/ndnputchunks (collectively
referred to as "chunks") can handle files of arbitrary size. A single Data
packet can be at most 8800 bytes long, so if the file is larger than that,
chunks will split it into segments. You can choose the maximum segment size
using the -s/--size option of ndnputchunks.

Thanks,
Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161011/1f31a686/attachment.html>

From tteixeira at engin.umass.edu  Tue Oct 11 10:32:40 2016
From: tteixeira at engin.umass.edu (Thiago Teixeira)
Date: Tue, 11 Oct 2016 17:32:40 +0000
Subject: [Ndn-interest] Large file transfer
In-Reply-To: <CADfzvvbz+8t_2io3nv=x37Wc=zccjQ61tsLAas2X3zzRr85URw@mail.gmail.com>
References: <66c4002e96404de38016c7c3fb21b891@engin.umass.edu>
	<CADfzvvbz+8t_2io3nv=x37Wc=zccjQ61tsLAas2X3zzRr85URw@mail.gmail.com>
Message-ID: <dc4843b9b7a34c13a18bb4e2f03f904a@engin.umass.edu>

Hi Davide,

Thanks for your help.

Cheers,
Thiago

From: Davide Pesavento [mailto:davide.pesavento at lip6.fr]
Sent: Tuesday, October 11, 2016 6:16 AM
To: Thiago Teixeira <tteixeira at engin.umass.edu>
Cc: ndn-interest at lists.cs.ucla.edu
Subject: Re: [Ndn-interest] Large file transfer

On Mon, Oct 10, 2016 at 10:11 PM, Thiago Teixeira <tteixeira at engin.umass.edu<mailto:tteixeira at engin.umass.edu>> wrote:
Hi folks,

I am experimenting with mobility in NDN and want to evaluate the performance and reliability under intermittent/disconnected networks. NDN-Ping and NDN-Chunks run fine; however, ndnchunks handles single small files (data packet less than 8800 B, if I?m not mistaken).

This is partially incorrect. ndncatchunks/ndnputchunks (collectively referred to as "chunks") can handle files of arbitrary size. A single Data packet can be at most 8800 bytes long, so if the file is larger than that, chunks will split it into segments. You can choose the maximum segment size using the -s/--size option of ndnputchunks.

Thanks,
Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161011/5d7298c3/attachment.html>

From Matteo.Bertolino at eurecom.fr  Wed Oct 12 05:32:56 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Wed, 12 Oct 2016 14:32:56 +0200
Subject: [Ndn-interest] Sending NACKs with ndn-cpp
Message-ID: <20161012143256.d3nlm1d0o4c8wks8@webmail.eurecom.fr>

Good morning,
using the ndn-cpp I do not manage to send a Nack. I do not see  
something like lp::Nack class of ndn-cxx, I see just the NetworkNack  
class but the documentation  
(http://named-data.net/doc/ndn-ccl-api/details/network-nack.html) does  
not specify how to make a NetworkNack, how to express etc. I did not  
find examples online too.

How can I express a nack with ndn-cpp such that the method  
Strategy::afterReceiveNack of my NFD could capture it?

Thank you,
Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr



From Matteo.Bertolino at eurecom.fr  Wed Oct 12 08:23:24 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Wed, 12 Oct 2016 17:23:24 +0200
Subject: [Ndn-interest] How to verify an interest packet
In-Reply-To: <20161010152732.xi35x8w7k8ogs4kc@webmail.eurecom.fr>
References: <20161007153027.z1lgw0gaps0k80sw@webmail.eurecom.fr>
	<57f8a01f.52dc620a.24c61.2d8c@mx.google.com>
	<20161010152732.xi35x8w7k8ogs4kc@webmail.eurecom.fr>
Message-ID: <20161012172324.l4krazddog8kg0gg@webmail.eurecom.fr>

After lots of day, I did not manage to verify an interest signed yet.  
Did someone successfully verify a signed interest? If so, please, can  
I have a look to that piece of code and to the validator file? It is  
really important for me.
Bests,
matteo

Quoting Matteo Bertolino <Matteo.Bertolino at eurecom.fr>:

> Dear Junxiao,
> I took some days in order to update the software at new release, but
> the problem still persists.
>
> Yes, the certificate is properly published. I can retrieve it, and if I
> use it to sign data all is OK. The problem is signing interests only..
>
> The error reason is: Packet cannot pass any checkers.
>
> Any ideas?
> Thank you,
> Matteo
>
>
> Quoting Junxiao Shi <shijunxiao at email.arizona.edu>:
>
>> Hi Matteo
>>
>> What's the error reason passed to onInterestValidationFailed function?
>>
>> Is the certificate properly published? In other words, can you    
>> retrieve the certificate by expressing an Interest using ndnpeel?
>>
>> Yours, Junxiao
>>
>> -----Original Message-----
>> From: "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
>> Sent: ?10/?7/?2016 6:31
>> To: "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
>> Subject: [Ndn-interest] How to verify an interest packet
>>
>> Dear community,
>> I am having some problem in verifying an interest packet.
>> Specifically, the error is: Packet cannot pass any checkers.
>>
>> A root authority signs the certificate of the sender of the interest
>>
>> My file config is:
>> rule
>> {
>>   id "p rule"
>>   checker
>>   {
>>     type hierarchical
>>     sig-type rsa-sha256
>>   }
>> }
>> trust-anchor
>> {
>>   type file
>>   file-name /tmp/p/root.ndncert
>> }
>>
>> So it is very simple.
>> The sender of the interest, signs the interest in this way:
>> Name producerId("/root/site2"); ///test/site2/user2
>> m_keyChain.signByIdentity(interest, producerId);
>>
>> While the content producer verifies it so:
>> void onInterest(const InterestFilter& filter, const Interest& interest)
>> {
>> m_validator->validate(interest, bind(&Producer::sendData, this, _1),
>>                           bind(&Producer::onInterestValidationFailed,
>> this, _1, _2));
>>   }
>>
>> The interest sent has the key included in the name, I noticed:
>> /root/site1/%00%00%01W%9F8%C4%11/%5Dl%F4%D2%8F%C5%D1%D6/%165%1B%01%01%1C0%07.%08%04root%08%03KEY%08%05site2%08%11ksk-1475844947720%08%07ID-CERT/%17%FD%01%0
>> [...]
>>
>> Do you notice any error?
>> Yours,
>> Matteo
>>
>> -------------------------------------------------------------------------------
>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>
>
>
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From jefft0 at remap.ucla.edu  Wed Oct 12 10:08:19 2016
From: jefft0 at remap.ucla.edu (Thompson, Jeff)
Date: Wed, 12 Oct 2016 17:08:19 +0000
Subject: [Ndn-interest] Sending NACKs with ndn-cpp
In-Reply-To: <20161012143256.d3nlm1d0o4c8wks8@webmail.eurecom.fr>
References: <20161012143256.d3nlm1d0o4c8wks8@webmail.eurecom.fr>
Message-ID: <D423BB60.37934%jefft0@remap.ucla.edu>

Hi Matteo.

A NetworkNack is a ?network? nack because it is generated by a forwarder
in the network, such as NFD. A client library like ndn-cpp is meant to be
used by an application which does not generate network-level messages. It
is called a ?network? nack to distinguish from an ?application? nack. Can
you describe the situation where your application needs to generate a nack?

- Jeff T

On 2016/10/12, 5:32:56, "Ndn-interest on behalf of Matteo Bertolino"
<ndn-interest-bounces at lists.cs.ucla.edu on behalf of
Matteo.Bertolino at eurecom.fr> wrote:

>Good morning,
>using the ndn-cpp I do not manage to send a Nack. I do not see
>something like lp::Nack class of ndn-cxx, I see just the NetworkNack
>class but the documentation
>(http://named-data.net/doc/ndn-ccl-api/details/network-nack.html) does
>not specify how to make a NetworkNack, how to express etc. I did not
>find examples online too.
>
>How can I express a nack with ndn-cpp such that the method
>Strategy::afterReceiveNack of my NFD could capture it?
>
>Thank you,
>Matteo
>
>--------------------------------------------------------------------------
>-----
>This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>_______________________________________________
>Ndn-interest mailing list
>Ndn-interest at lists.cs.ucla.edu
>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




From sepehrabdous at yahoo.com  Wed Oct 12 13:29:46 2016
From: sepehrabdous at yahoo.com (Sepehr Abdous)
Date: Wed, 12 Oct 2016 20:29:46 +0000 (UTC)
Subject: [Ndn-interest] mininet error
References: <1867736363.525430.1476304186257.ref@mail.yahoo.com>
Message-ID: <1867736363.525430.1476304186257@mail.yahoo.com>

Hello All,
I've tried to install mini-ndn by following steps in https://github.com/named-data/mini-ndn/blob/master/INSTALL.md
and in one aspect, it requires installing mini_net,
again I follow the exact steps stated but when I try to use 
sudo mn --test pingall
to see if it works well...
I encounter this error:
Exception: Error creating interface pair (h1-eth0,s1-eth1): RTNETLINK answers: Operation not supported
do you have any idea how can I handle it??Sepehr Abdous
Faculty: abdous at ce.sharif.edu
Gmail: sepehrabdous1375 at gmail.com
Cellphone:+989194030591
School of computer engineering
Sharif University of Technology
Tehran, Iran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161012/d390f257/attachment.html>

From shijunxiao at email.arizona.edu  Wed Oct 12 15:58:21 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 12 Oct 2016 15:58:21 -0700
Subject: [Ndn-interest] Sending NACKs with ndn-cpp
In-Reply-To: <D423BB60.37934%jefft0@remap.ucla.edu>
References: <20161012143256.d3nlm1d0o4c8wks8@webmail.eurecom.fr>
	<D423BB60.37934%jefft0@remap.ucla.edu>
Message-ID: <CAOFH+OasPNQ71UQ458OyA-9j8ivY4ydPNFyABp=s7jwO1k6oPA@mail.gmail.com>

Hi JeffT

I have a temperature sensor based on ESP8266 microcontroller. It uses
ndn-cpp-lite, connects to a remote forwarder over TCP, and acts as a
producer.
The ESP8266, clocked at 80MHz, has limited signing capability. It can sign
or verify 8 ECDSA signatures per second.
If Interests are arriving too fast, I want to be able to send a
NetworkNack-Congestion so that the remote forwarder can forward less
Interests to the sensor.
An application Nack cannot fulfill this purpose because it still requires a
signature. Allowing the Interests to time out increases overhead at the
remote forwarder because PIT entries stay longer.

Yours, Junxiao

On Wed, Oct 12, 2016 at 10:08 AM, Thompson, Jeff <jefft0 at remap.ucla.edu>
wrote:

> Hi Matteo.
>
> A NetworkNack is a ?network? nack because it is generated by a forwarder
> in the network, such as NFD. A client library like ndn-cpp is meant to be
> used by an application which does not generate network-level messages. It
> is called a ?network? nack to distinguish from an ?application? nack. Can
> you describe the situation where your application needs to generate a nack?
>
> - Jeff T
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161012/07de4d03/attachment.html>

From cghali at uci.edu  Thu Oct 13 08:29:13 2016
From: cghali at uci.edu (Cesar Ghali)
Date: Thu, 13 Oct 2016 15:29:13 +0000
Subject: [Ndn-interest] Sending NACKs with ndn-cpp
In-Reply-To: <CAOFH+OasPNQ71UQ458OyA-9j8ivY4ydPNFyABp=s7jwO1k6oPA@mail.gmail.com>
References: <20161012143256.d3nlm1d0o4c8wks8@webmail.eurecom.fr>
	<D423BB60.37934%jefft0@remap.ucla.edu>
	<CAOFH+OasPNQ71UQ458OyA-9j8ivY4ydPNFyABp=s7jwO1k6oPA@mail.gmail.com>
Message-ID: <CAAj99Kk-axkc+aA=+TibCzqKCwWtfWr=suwLx9z=npcK41cUTg@mail.gmail.com>

That's right, mixing network and application NACKs is not a good idea. From
a security perspective, this separation is discussed in details in:

http://ieeexplore.ieee.org/document/7288477/

Cesar

On Wed, Oct 12, 2016 at 16:07 Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi JeffT
>
> I have a temperature sensor based on ESP8266 microcontroller. It uses
> ndn-cpp-lite, connects to a remote forwarder over TCP, and acts as a
> producer.
> The ESP8266, clocked at 80MHz, has limited signing capability. It can sign
> or verify 8 ECDSA signatures per second.
> If Interests are arriving too fast, I want to be able to send a
> NetworkNack-Congestion so that the remote forwarder can forward less
> Interests to the sensor.
> An application Nack cannot fulfill this purpose because it still requires
> a signature. Allowing the Interests to time out increases overhead at the
> remote forwarder because PIT entries stay longer.
>
> Yours, Junxiao
>
>
> On Wed, Oct 12, 2016 at 10:08 AM, Thompson, Jeff <jefft0 at remap.ucla.edu>
> wrote:
>
>> Hi Matteo.
>>
>> A NetworkNack is a ?network? nack because it is generated by a forwarder
>> in the network, such as NFD. A client library like ndn-cpp is meant to be
>> used by an application which does not generate network-level messages. It
>> is called a ?network? nack to distinguish from an ?application? nack. Can
>> you describe the situation where your application needs to generate a
>> nack?
>>
>> - Jeff T
>>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161013/d928aaa1/attachment.html>

From jefft0 at remap.ucla.edu  Thu Oct 13 08:35:13 2016
From: jefft0 at remap.ucla.edu (Thompson, Jeff)
Date: Thu, 13 Oct 2016 15:35:13 +0000
Subject: [Ndn-interest] Sending NACKs with ndn-cpp
In-Reply-To: <CAAj99Kk-axkc+aA=+TibCzqKCwWtfWr=suwLx9z=npcK41cUTg@mail.gmail.com>
References: <20161012143256.d3nlm1d0o4c8wks8@webmail.eurecom.fr>
	<D423BB60.37934%jefft0@remap.ucla.edu>
	<CAOFH+OasPNQ71UQ458OyA-9j8ivY4ydPNFyABp=s7jwO1k6oPA@mail.gmail.com>
	<CAAj99Kk-axkc+aA=+TibCzqKCwWtfWr=suwLx9z=npcK41cUTg@mail.gmail.com>
Message-ID: <D424F721.379D5%jefft0@remap.ucla.edu>

Hi Cesar,

So in Junxiao?s example, the microcontroller would send an unsigned network Nack? Will forwarders be configured to respond to an unsigned Nack which comes from the (supposed) direction from any application? (I had though that these network signalling messages are send between forwarders on a pre-arranged trusted channel.)

- Jeff T

From: Cesar Ghali <cghali at uci.edu<mailto:cghali at uci.edu>>
Date: Thursday, October 13, 2016 at 8:29:00
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>, Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc: "ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>" <ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>>
Subject: Re: [Ndn-interest] Sending NACKs with ndn-cpp

That's right, mixing network and application NACKs is not a good idea. From a security perspective, this separation is discussed in details in:

http://ieeexplore.ieee.org/document/7288477/

Cesar

On Wed, Oct 12, 2016 at 16:07 Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:
Hi JeffT

I have a temperature sensor based on ESP8266 microcontroller. It uses ndn-cpp-lite, connects to a remote forwarder over TCP, and acts as a producer.
The ESP8266, clocked at 80MHz, has limited signing capability. It can sign or verify 8 ECDSA signatures per second.
If Interests are arriving too fast, I want to be able to send a NetworkNack-Congestion so that the remote forwarder can forward less Interests to the sensor.
An application Nack cannot fulfill this purpose because it still requires a signature. Allowing the Interests to time out increases overhead at the remote forwarder because PIT entries stay longer.

Yours, Junxiao


On Wed, Oct 12, 2016 at 10:08 AM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:
Hi Matteo.

A NetworkNack is a ?network? nack because it is generated by a forwarder
in the network, such as NFD. A client library like ndn-cpp is meant to be
used by an application which does not generate network-level messages. It
is called a ?network? nack to distinguish from an ?application? nack. Can
you describe the situation where your application needs to generate a nack?

- Jeff T
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161013/e3475bfe/attachment.html>

From cghali at uci.edu  Thu Oct 13 08:50:27 2016
From: cghali at uci.edu (Cesar Ghali)
Date: Thu, 13 Oct 2016 15:50:27 +0000
Subject: [Ndn-interest] Sending NACKs with ndn-cpp
In-Reply-To: <27ea99d5-1b46-4e10-b128-2e8689d79876@EMHUB6.ad.ucla.edu>
References: <20161012143256.d3nlm1d0o4c8wks8@webmail.eurecom.fr>
	<D423BB60.37934%jefft0@remap.ucla.edu>
	<CAOFH+OasPNQ71UQ458OyA-9j8ivY4ydPNFyABp=s7jwO1k6oPA@mail.gmail.com>
	<CAAj99Kk-axkc+aA=+TibCzqKCwWtfWr=suwLx9z=npcK41cUTg@mail.gmail.com>
	<27ea99d5-1b46-4e10-b128-2e8689d79876@EMHUB6.ad.ucla.edu>
Message-ID: <CAAj99KnHh8G4_tfe5fgUqQGXQexTVQq5pnNOx5J39n+pu5ALzQ@mail.gmail.com>

Hi Jeff,

That's right, untrusted NACKs should not be accepted in the network. In
fact a pre-arranged trusted channel is an approach proposed in the paper I
shared before.

Cesar

On Thu, Oct 13, 2016 at 08:45 Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:

> Hi Cesar,
>
> So in Junxiao?s example, the microcontroller would send an unsigned
> network Nack? Will forwarders be configured to respond to an unsigned Nack
> which comes from the (supposed) direction from any application? (I had
> though that these network signalling messages are send between forwarders
> on a pre-arranged trusted channel.)
>
> - Jeff T
>
> From: Cesar Ghali <cghali at uci.edu>
> Date: Thursday, October 13, 2016 at 8:29:00
> To: Junxiao Shi <shijunxiao at email.arizona.edu>, Jeff Thompson <
> jefft0 at remap.ucla.edu>
> Cc: "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
> Subject: Re: [Ndn-interest] Sending NACKs with ndn-cpp
>
> That's right, mixing network and application NACKs is not a good idea.
> From a security perspective, this separation is discussed in details in:
>
> http://ieeexplore.ieee.org/document/7288477/
>
> Cesar
>
> On Wed, Oct 12, 2016 at 16:07 Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
>> Hi JeffT
>>
>> I have a temperature sensor based on ESP8266 microcontroller. It uses
>> ndn-cpp-lite, connects to a remote forwarder over TCP, and acts as a
>> producer.
>> The ESP8266, clocked at 80MHz, has limited signing capability. It can
>> sign or verify 8 ECDSA signatures per second.
>> If Interests are arriving too fast, I want to be able to send a
>> NetworkNack-Congestion so that the remote forwarder can forward less
>> Interests to the sensor.
>> An application Nack cannot fulfill this purpose because it still requires
>> a signature. Allowing the Interests to time out increases overhead at the
>> remote forwarder because PIT entries stay longer.
>>
>> Yours, Junxiao
>>
>>
>> On Wed, Oct 12, 2016 at 10:08 AM, Thompson, Jeff <jefft0 at remap.ucla.edu>
>> wrote:
>>
>>> Hi Matteo.
>>>
>>> A NetworkNack is a ?network? nack because it is generated by a forwarder
>>> in the network, such as NFD. A client library like ndn-cpp is meant to be
>>> used by an application which does not generate network-level messages. It
>>> is called a ?network? nack to distinguish from an ?application? nack. Can
>>> you describe the situation where your application needs to generate a
>>> nack?
>>>
>>> - Jeff T
>>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161013/bd8a1d32/attachment.html>

From Marc.Mosko at parc.com  Thu Oct 13 09:05:06 2016
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Thu, 13 Oct 2016 16:05:06 +0000
Subject: [Ndn-interest] Sending NACKs with ndn-cpp
In-Reply-To: <CAAj99KnHh8G4_tfe5fgUqQGXQexTVQq5pnNOx5J39n+pu5ALzQ@mail.gmail.com>
References: <20161012143256.d3nlm1d0o4c8wks8@webmail.eurecom.fr>
	<D423BB60.37934%jefft0@remap.ucla.edu>
	<CAOFH+OasPNQ71UQ458OyA-9j8ivY4ydPNFyABp=s7jwO1k6oPA@mail.gmail.com>
	<CAAj99Kk-axkc+aA=+TibCzqKCwWtfWr=suwLx9z=npcK41cUTg@mail.gmail.com>
	<27ea99d5-1b46-4e10-b128-2e8689d79876@EMHUB6.ad.ucla.edu>
	<CAAj99KnHh8G4_tfe5fgUqQGXQexTVQq5pnNOx5J39n+pu5ALzQ@mail.gmail.com>
Message-ID: <032EF4D1-E49C-459C-B1A2-5CEC87D693BD@parc.com>

Doesn?t an application have a trust channel with its local forwarder, and the local forwarder with the next forwarder, etc.?

Marc

On Oct 13, 2016, at 8:50 AM, Cesar Ghali <cghali at uci.edu<mailto:cghali at uci.edu>> wrote:

Hi Jeff,

That's right, untrusted NACKs should not be accepted in the network. In fact a pre-arranged trusted channel is an approach proposed in the paper I shared before.

Cesar

On Thu, Oct 13, 2016 at 08:45 Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:
Hi Cesar,

So in Junxiao?s example, the microcontroller would send an unsigned network Nack? Will forwarders be configured to respond to an unsigned Nack which comes from the (supposed) direction from any application? (I had though that these network signalling messages are send between forwarders on a pre-arranged trusted channel.)

- Jeff T

From: Cesar Ghali <cghali at uci.edu<mailto:cghali at uci.edu>>
Date: Thursday, October 13, 2016 at 8:29:00
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>, Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc: "ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>" <ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>>
Subject: Re: [Ndn-interest] Sending NACKs with ndn-cpp

That's right, mixing network and application NACKs is not a good idea. From a security perspective, this separation is discussed in details in:

http://ieeexplore.ieee.org/document/7288477/

Cesar

On Wed, Oct 12, 2016 at 16:07 Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:
Hi JeffT

I have a temperature sensor based on ESP8266 microcontroller. It uses ndn-cpp-lite, connects to a remote forwarder over TCP, and acts as a producer.
The ESP8266, clocked at 80MHz, has limited signing capability. It can sign or verify 8 ECDSA signatures per second.
If Interests are arriving too fast, I want to be able to send a NetworkNack-Congestion so that the remote forwarder can forward less Interests to the sensor.
An application Nack cannot fulfill this purpose because it still requires a signature. Allowing the Interests to time out increases overhead at the remote forwarder because PIT entries stay longer.

Yours, Junxiao


On Wed, Oct 12, 2016 at 10:08 AM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:
Hi Matteo.

A NetworkNack is a ?network? nack because it is generated by a forwarder
in the network, such as NFD. A client library like ndn-cpp is meant to be
used by an application which does not generate network-level messages. It
is called a ?network? nack to distinguish from an ?application? nack. Can
you describe the situation where your application needs to generate a nack?

- Jeff T
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161013/12cb4bf7/attachment.html>

From shijunxiao at email.arizona.edu  Thu Oct 13 09:18:17 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 13 Oct 2016 09:18:17 -0700
Subject: [Ndn-interest] How to verify an interest packet
In-Reply-To: <20161010152732.xi35x8w7k8ogs4kc@webmail.eurecom.fr>
References: <20161007153027.z1lgw0gaps0k80sw@webmail.eurecom.fr>
	<57f8a01f.52dc620a.24c61.2d8c@mx.google.com>
	<20161010152732.xi35x8w7k8ogs4kc@webmail.eurecom.fr>
Message-ID: <CAOFH+Ob+LGbmHSiKJZJR2wx6poB4Q4bROCN=gZRcFFHQqPGcoQ@mail.gmail.com>

Hi Matteo

The configuration is invalid.
According to
http://named-data.net/doc/ndn-cxx/current/tutorials/security-validator-config.html#rules-in-general

A rule is either used to validate an interest packet or a data packet. This
information is specified in the property *for*. Only two value can be
specified: *data *and *interest*. A rule must have one and only one *for *
property.

But your checker does not have a *for *property.

An example configuration used in NFD-RIB can be found at
https://github.com/named-data/NFD/blob/88f5f7392bf0844edaaef8e85101470b1bba0527/nfd.conf.sample.in#L262-L305

Yours, Junxiao

On Mon, Oct 10, 2016 at 6:27 AM, Matteo Bertolino <
Matteo.Bertolino at eurecom.fr> wrote:

>
> Yes, the certificate is properly published. I can retrieve it, and if I
> use it to sign data all is OK. The problem is signing interests only..
>
> The error reason is: Packet cannot pass any checkers.
>

On Fri, Oct 7, 2016 at 6:30 AM, Matteo Bertolino <
Matteo.Bertolino at eurecom.fr> wrote:

>
> rule
> {
>   id "p rule"
>   checker
>   {
>     type hierarchical
>     sig-type rsa-sha256
>   }
> }
> trust-anchor
> {
>   type file
>   file-name /tmp/p/root.ndncert
> }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161013/5807023b/attachment.html>

From gts at ics.uci.edu  Thu Oct 13 09:36:19 2016
From: gts at ics.uci.edu (GTS)
Date: Thu, 13 Oct 2016 09:36:19 -0700
Subject: [Ndn-interest] Sending NACKs with ndn-cpp
In-Reply-To: <032EF4D1-E49C-459C-B1A2-5CEC87D693BD@parc.com>
References: <20161012143256.d3nlm1d0o4c8wks8@webmail.eurecom.fr>
	<D423BB60.37934%jefft0@remap.ucla.edu>
	<CAOFH+OasPNQ71UQ458OyA-9j8ivY4ydPNFyABp=s7jwO1k6oPA@mail.gmail.com>
	<CAAj99Kk-axkc+aA=+TibCzqKCwWtfWr=suwLx9z=npcK41cUTg@mail.gmail.com>
	<27ea99d5-1b46-4e10-b128-2e8689d79876@EMHUB6.ad.ucla.edu>
	<CAAj99KnHh8G4_tfe5fgUqQGXQexTVQq5pnNOx5J39n+pu5ALzQ@mail.gmail.com>
	<032EF4D1-E49C-459C-B1A2-5CEC87D693BD@parc.com>
Message-ID: <99bf3a5e-8dfc-ed0d-4ddf-c996c59ac6fe@ics.uci.edu>


Marc,

yes, it's reasonable -- though not always practical -- to assume that 
there are pairwise secure
channels between local app, local forwarder, next forwarder, etc, etc, 
all the way to the last
hop.

However, my apologies for this platitude, but trust is local.
The farther you get away (in trust hops) from the source, the less
trust there is, and more likely it becomes that someone on the path will 
be malicious.
It works the same way with humans :-)

Cheers,
Gene


======================
Gene Tsudik
Chancellor's Professor of Computer Science
University of California, Irvine

On 10/13/16 9:05 AM, Marc.Mosko at parc.com wrote:
> Doesn?t an application have a trust channel with its local forwarder, 
> and the local forwarder with the next forwarder, etc.?
>
> Marc
>
>> On Oct 13, 2016, at 8:50 AM, Cesar Ghali <cghali at uci.edu 
>> <mailto:cghali at uci.edu>> wrote:
>>
>> Hi Jeff, That's right, untrusted NACKs should not be accepted in the 
>> network. In fact a pre-arranged trusted channel is an approach 
>> proposed in the paper I shared before. Cesar
>>
>> On Thu, Oct 13, 2016 at 08:45 Thompson, Jeff <jefft0 at remap.ucla.edu 
>> <mailto:jefft0 at remap.ucla.edu>> wrote:
>>
>>     Hi Cesar,
>>
>>     So in Junxiao?s example, the microcontroller would send an
>>     unsigned network Nack? Will forwarders be configured to respond
>>     to an unsigned Nack which comes from the (supposed) direction
>>     from any application? (I had though that these network signalling
>>     messages are send between forwarders on a pre-arranged trusted
>>     channel.)
>>
>>     - Jeff T
>>
>>     From: Cesar Ghali <cghali at uci.edu <mailto:cghali at uci.edu>>
>>     Date: Thursday, October 13, 2016 at 8:29:00
>>     To: Junxiao Shi <shijunxiao at email.arizona.edu
>>     <mailto:shijunxiao at email.arizona.edu>>, Jeff Thompson
>>     <jefft0 at remap.ucla.edu <mailto:jefft0 at remap.ucla.edu>>
>>     Cc: "ndn-interest at lists.cs.ucla.edu
>>     <mailto:ndn-interest at lists.cs.ucla.edu>"
>>     <ndn-interest at lists.cs.ucla.edu
>>     <mailto:ndn-interest at lists.cs.ucla.edu>>
>>     Subject: Re: [Ndn-interest] Sending NACKs with ndn-cpp
>>
>>     That's right, mixing network and application NACKs is not a good
>>     idea. From a security perspective, this separation is discussed
>>     in details in: http://ieeexplore.ieee.org/document/7288477/ Cesar
>>
>>     On Wed, Oct 12, 2016 at 16:07 Junxiao Shi
>>     <shijunxiao at email.arizona.edu
>>     <mailto:shijunxiao at email.arizona.edu>> wrote:
>>
>>         Hi JeffT
>>
>>         I have a temperature sensor based on ESP8266 microcontroller.
>>         It uses ndn-cpp-lite, connects to a remote forwarder over
>>         TCP, and acts as a producer.
>>         The ESP8266, clocked at 80MHz, has limited signing
>>         capability. It can sign or verify 8 ECDSA signatures per second.
>>         If Interests are arriving too fast, I want to be able to send
>>         a NetworkNack-Congestion so that the remote forwarder can
>>         forward less Interests to the sensor.
>>         An application Nack cannot fulfill this purpose because it
>>         still requires a signature. Allowing the Interests to time
>>         out increases overhead at the remote forwarder because PIT
>>         entries stay longer.
>>
>>         Yours, Junxiao
>>
>>
>>         On Wed, Oct 12, 2016 at 10:08 AM, Thompson, Jeff
>>         <jefft0 at remap.ucla.edu <mailto:jefft0 at remap.ucla.edu>> wrote:
>>
>>             Hi Matteo.
>>
>>             A NetworkNack is a ?network? nack because it is generated
>>             by a forwarder
>>             in the network, such as NFD. A client library like
>>             ndn-cpp is meant to be
>>             used by an application which does not generate
>>             network-level messages. It
>>             is called a ?network? nack to distinguish from an
>>             ?application? nack. Can
>>             you describe the situation where your application needs
>>             to generate a nack?
>>
>>             - Jeff T
>>
>>         _______________________________________________
>>         Ndn-interest mailing list
>>         Ndn-interest at lists.cs.ucla.edu
>>         <mailto:Ndn-interest at lists.cs.ucla.edu>
>>         http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161013/29bdff2c/attachment.html>

From Marc.Mosko at parc.com  Thu Oct 13 09:41:01 2016
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Thu, 13 Oct 2016 16:41:01 +0000
Subject: [Ndn-interest] Sending NACKs with ndn-cpp
In-Reply-To: <99bf3a5e-8dfc-ed0d-4ddf-c996c59ac6fe@ics.uci.edu>
References: <20161012143256.d3nlm1d0o4c8wks8@webmail.eurecom.fr>
	<D423BB60.37934%jefft0@remap.ucla.edu>
	<CAOFH+OasPNQ71UQ458OyA-9j8ivY4ydPNFyABp=s7jwO1k6oPA@mail.gmail.com>
	<CAAj99Kk-axkc+aA=+TibCzqKCwWtfWr=suwLx9z=npcK41cUTg@mail.gmail.com>
	<27ea99d5-1b46-4e10-b128-2e8689d79876@EMHUB6.ad.ucla.edu>
	<CAAj99KnHh8G4_tfe5fgUqQGXQexTVQq5pnNOx5J39n+pu5ALzQ@mail.gmail.com>
	<032EF4D1-E49C-459C-B1A2-5CEC87D693BD@parc.com>
	<99bf3a5e-8dfc-ed0d-4ddf-c996c59ac6fe@ics.uci.edu>
Message-ID: <9BAFBBC4-EA86-444F-BB5C-C49CD2B53E45@parc.com>

I agree things get more murky the further one gets away from where a message was initiated.

But I thought the premise of the previous messages is that adjacent forwarders already trust each other for NACKs.  My point was that if forwarders already trust each other for NACks, then why cannot a forwarder apply a similar trust mechanism to a local app, as it should know for which name spaces it trusts the app.

Marc


On Oct 13, 2016, at 9:36 AM, GTS <gts at ics.uci.edu<mailto:gts at ics.uci.edu>> wrote:


Marc,

yes, it's reasonable -- though not always practical -- to assume that there are pairwise secure
channels between local app, local forwarder, next forwarder, etc, etc, all the way to the last
hop.

However, my apologies for this platitude, but trust is local.
The farther you get away (in trust hops) from the source, the less
trust there is, and more likely it becomes that someone on the path will be malicious.
It works the same way with humans :-)

Cheers,
Gene



======================
Gene Tsudik
Chancellor's Professor of Computer Science
University of California, Irvine



On 10/13/16 9:05 AM, Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com> wrote:
Doesn?t an application have a trust channel with its local forwarder, and the local forwarder with the next forwarder, etc.?

Marc

On Oct 13, 2016, at 8:50 AM, Cesar Ghali <cghali at uci.edu<mailto:cghali at uci.edu>> wrote:

Hi Jeff, That's right, untrusted NACKs should not be accepted in the network. In fact a pre-arranged trusted channel is an approach proposed in the paper I shared before. Cesar

On Thu, Oct 13, 2016 at 08:45 Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:
Hi Cesar,

So in Junxiao?s example, the microcontroller would send an unsigned network Nack? Will forwarders be configured to respond to an unsigned Nack which comes from the (supposed) direction from any application? (I had though that these network signalling messages are send between forwarders on a pre-arranged trusted channel.)

- Jeff T

From: Cesar Ghali <cghali at uci.edu<mailto:cghali at uci.edu>>
Date: Thursday, October 13, 2016 at 8:29:00
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>, Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc: "ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>" <ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>>
Subject: Re: [Ndn-interest] Sending NACKs with ndn-cpp

That's right, mixing network and application NACKs is not a good idea. From a security perspective, this separation is discussed in details in: http://ieeexplore.ieee.org/document/7288477/ Cesar

On Wed, Oct 12, 2016 at 16:07 Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:
Hi JeffT

I have a temperature sensor based on ESP8266 microcontroller. It uses ndn-cpp-lite, connects to a remote forwarder over TCP, and acts as a producer.
The ESP8266, clocked at 80MHz, has limited signing capability. It can sign or verify 8 ECDSA signatures per second.
If Interests are arriving too fast, I want to be able to send a NetworkNack-Congestion so that the remote forwarder can forward less Interests to the sensor.
An application Nack cannot fulfill this purpose because it still requires a signature. Allowing the Interests to time out increases overhead at the remote forwarder because PIT entries stay longer.

Yours, Junxiao


On Wed, Oct 12, 2016 at 10:08 AM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:
Hi Matteo.

A NetworkNack is a ?network? nack because it is generated by a forwarder
in the network, such as NFD. A client library like ndn-cpp is meant to be
used by an application which does not generate network-level messages. It
is called a ?network? nack to distinguish from an ?application? nack. Can
you describe the situation where your application needs to generate a nack?

- Jeff T
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161013/a4c345a1/attachment.html>

From gts at ics.uci.edu  Thu Oct 13 10:10:23 2016
From: gts at ics.uci.edu (GTS)
Date: Thu, 13 Oct 2016 10:10:23 -0700
Subject: [Ndn-interest] Sending NACKs with ndn-cpp
In-Reply-To: <9BAFBBC4-EA86-444F-BB5C-C49CD2B53E45@parc.com>
References: <20161012143256.d3nlm1d0o4c8wks8@webmail.eurecom.fr>
	<D423BB60.37934%jefft0@remap.ucla.edu>
	<CAOFH+OasPNQ71UQ458OyA-9j8ivY4ydPNFyABp=s7jwO1k6oPA@mail.gmail.com>
	<CAAj99Kk-axkc+aA=+TibCzqKCwWtfWr=suwLx9z=npcK41cUTg@mail.gmail.com>
	<27ea99d5-1b46-4e10-b128-2e8689d79876@EMHUB6.ad.ucla.edu>
	<CAAj99KnHh8G4_tfe5fgUqQGXQexTVQq5pnNOx5J39n+pu5ALzQ@mail.gmail.com>
	<032EF4D1-E49C-459C-B1A2-5CEC87D693BD@parc.com>
	<99bf3a5e-8dfc-ed0d-4ddf-c996c59ac6fe@ics.uci.edu>
	<9BAFBBC4-EA86-444F-BB5C-C49CD2B53E45@parc.com>
Message-ID: <2364d8d4-74bd-2bda-ac16-1ff493f7bc14@ics.uci.edu>


Yep... I agree in the context of a forwarder talking a *collocated* app.
Cheers,
Gene

======================
Gene Tsudik
Chancellor's Professor of Computer Science
University of California, Irvine

On 10/13/16 9:41 AM, Marc.Mosko at parc.com wrote:
> I agree things get more murky the further one gets away from where a 
> message was initiated.
>
> But I thought the premise of the previous messages is that adjacent 
> forwarders already trust each other for NACKs.  My point was that if 
> forwarders already trust each other for NACks, then why cannot a 
> forwarder apply a similar trust mechanism to a local app, as it should 
> know for which name spaces it trusts the app.
>
> Marc
>
>
>> On Oct 13, 2016, at 9:36 AM, GTS <gts at ics.uci.edu 
>> <mailto:gts at ics.uci.edu>> wrote:
>>
>>
>> Marc,
>>
>> yes, it's reasonable -- though not always practical -- to assume that 
>> there are pairwise secure
>> channels between local app, local forwarder, next forwarder, etc, 
>> etc, all the way to the last
>> hop.
>>
>> However, my apologies for this platitude, but trust is local.
>> The farther you get away (in trust hops) from the source, the less
>> trust there is, and more likely it becomes that someone on the path 
>> will be malicious.
>> It works the same way with humans :-)
>>
>> Cheers,
>> Gene
>>
>>
>> ======================
>> Gene Tsudik
>> Chancellor's Professor of Computer Science
>> University of California, Irvine
>>
>> On 10/13/16 9:05 AM, Marc.Mosko at parc.com wrote:
>>> Doesn?t an application have a trust channel with its local 
>>> forwarder, and the local forwarder with the next forwarder, etc.?
>>>
>>> Marc
>>>
>>>> On Oct 13, 2016, at 8:50 AM, Cesar Ghali <cghali at uci.edu 
>>>> <mailto:cghali at uci.edu>> wrote:
>>>>
>>>> Hi Jeff, That's right, untrusted NACKs should not be accepted in 
>>>> the network. In fact a pre-arranged trusted channel is an approach 
>>>> proposed in the paper I shared before. Cesar
>>>>
>>>> On Thu, Oct 13, 2016 at 08:45 Thompson, Jeff <jefft0 at remap.ucla.edu 
>>>> <mailto:jefft0 at remap.ucla.edu>> wrote:
>>>>
>>>>     Hi Cesar,
>>>>
>>>>     So in Junxiao?s example, the microcontroller would send an
>>>>     unsigned network Nack? Will forwarders be configured to respond
>>>>     to an unsigned Nack which comes from the (supposed) direction
>>>>     from any application? (I had though that these network
>>>>     signalling messages are send between forwarders on a
>>>>     pre-arranged trusted channel.)
>>>>
>>>>     - Jeff T
>>>>
>>>>     From: Cesar Ghali <cghali at uci.edu <mailto:cghali at uci.edu>>
>>>>     Date: Thursday, October 13, 2016 at 8:29:00
>>>>     To: Junxiao Shi <shijunxiao at email.arizona.edu
>>>>     <mailto:shijunxiao at email.arizona.edu>>, Jeff Thompson
>>>>     <jefft0 at remap.ucla.edu <mailto:jefft0 at remap.ucla.edu>>
>>>>     Cc: "ndn-interest at lists.cs.ucla.edu
>>>>     <mailto:ndn-interest at lists.cs.ucla.edu>"
>>>>     <ndn-interest at lists.cs.ucla.edu
>>>>     <mailto:ndn-interest at lists.cs.ucla.edu>>
>>>>     Subject: Re: [Ndn-interest] Sending NACKs with ndn-cpp
>>>>
>>>>     That's right, mixing network and application NACKs is not a
>>>>     good idea. From a security perspective, this separation is
>>>>     discussed in details in:
>>>>     http://ieeexplore.ieee.org/document/7288477/ Cesar
>>>>
>>>>     On Wed, Oct 12, 2016 at 16:07 Junxiao Shi
>>>>     <shijunxiao at email.arizona.edu
>>>>     <mailto:shijunxiao at email.arizona.edu>> wrote:
>>>>
>>>>         Hi JeffT
>>>>
>>>>         I have a temperature sensor based on ESP8266
>>>>         microcontroller. It uses ndn-cpp-lite, connects to a remote
>>>>         forwarder over TCP, and acts as a producer.
>>>>         The ESP8266, clocked at 80MHz, has limited signing
>>>>         capability. It can sign or verify 8 ECDSA signatures per
>>>>         second.
>>>>         If Interests are arriving too fast, I want to be able to
>>>>         send a NetworkNack-Congestion so that the remote forwarder
>>>>         can forward less Interests to the sensor.
>>>>         An application Nack cannot fulfill this purpose because it
>>>>         still requires a signature. Allowing the Interests to time
>>>>         out increases overhead at the remote forwarder because PIT
>>>>         entries stay longer.
>>>>
>>>>         Yours, Junxiao
>>>>
>>>>
>>>>         On Wed, Oct 12, 2016 at 10:08 AM, Thompson, Jeff
>>>>         <jefft0 at remap.ucla.edu <mailto:jefft0 at remap.ucla.edu>> wrote:
>>>>
>>>>             Hi Matteo.
>>>>
>>>>             A NetworkNack is a ?network? nack because it is
>>>>             generated by a forwarder
>>>>             in the network, such as NFD. A client library like
>>>>             ndn-cpp is meant to be
>>>>             used by an application which does not generate
>>>>             network-level messages. It
>>>>             is called a ?network? nack to distinguish from an
>>>>             ?application? nack. Can
>>>>             you describe the situation where your application needs
>>>>             to generate a nack?
>>>>
>>>>             - Jeff T
>>>>
>>>>         _______________________________________________
>>>>         Ndn-interest mailing list
>>>>         Ndn-interest at lists.cs.ucla.edu
>>>>         <mailto:Ndn-interest at lists.cs.ucla.edu>
>>>>         http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>
>>>> _______________________________________________
>>>> Ndn-interest mailing list
>>>> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>
>>>
>>>
>>> _______________________________________________
>>> Ndn-interest mailing list
>>> Ndn-interest at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161013/8122d54c/attachment.html>

From jefft0 at remap.UCLA.edu  Thu Oct 13 11:03:49 2016
From: jefft0 at remap.UCLA.edu (Thompson, Jeff)
Date: Thu, 13 Oct 2016 18:03:49 +0000
Subject: [Ndn-interest] Sending NACKs with ndn-cpp
In-Reply-To: <2364d8d4-74bd-2bda-ac16-1ff493f7bc14@ics.uci.edu>
References: <20161012143256.d3nlm1d0o4c8wks8@webmail.eurecom.fr>
	<D423BB60.37934%jefft0@remap.ucla.edu>
	<CAOFH+OasPNQ71UQ458OyA-9j8ivY4ydPNFyABp=s7jwO1k6oPA@mail.gmail.com>
	<CAAj99Kk-axkc+aA=+TibCzqKCwWtfWr=suwLx9z=npcK41cUTg@mail.gmail.com>
	<27ea99d5-1b46-4e10-b128-2e8689d79876@EMHUB6.ad.ucla.edu>
	<CAAj99KnHh8G4_tfe5fgUqQGXQexTVQq5pnNOx5J39n+pu5ALzQ@mail.gmail.com>
	<032EF4D1-E49C-459C-B1A2-5CEC87D693BD@parc.com>
	<99bf3a5e-8dfc-ed0d-4ddf-c996c59ac6fe@ics.uci.edu>
	<9BAFBBC4-EA86-444F-BB5C-C49CD2B53E45@parc.com>
	<2364d8d4-74bd-2bda-ac16-1ff493f7bc14@ics.uci.edu>
Message-ID: <D4251A35.379F5%jefft0@remap.ucla.edu>

Hi Gene,
By ?collocated?, you mean talking over something like a Unix socket on the same computer with the idea that there is little chance of an adversary getting in the middle?
- Jeff T

From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu<mailto:ndn-interest-bounces at lists.cs.ucla.edu>> on behalf of GTS <gts at ics.uci.edu<mailto:gts at ics.uci.edu>>
Date: Thursday, October 13, 2016 at 10:10:00
To: "Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>" <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>>
Cc: "ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>" <ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>>
Subject: Re: [Ndn-interest] Sending NACKs with ndn-cpp


Yep... I agree in the context of a forwarder talking a *collocated* app.
Cheers,
Gene


======================
Gene Tsudik
Chancellor's Professor of Computer Science
University of California, Irvine



On 10/13/16 9:41 AM, Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com> wrote:
I agree things get more murky the further one gets away from where a message was initiated.

But I thought the premise of the previous messages is that adjacent forwarders already trust each other for NACKs.  My point was that if forwarders already trust each other for NACks, then why cannot a forwarder apply a similar trust mechanism to a local app, as it should know for which name spaces it trusts the app.

Marc


On Oct 13, 2016, at 9:36 AM, GTS <gts at ics.uci.edu<mailto:gts at ics.uci.edu>> wrote:


Marc,

yes, it's reasonable -- though not always practical -- to assume that there are pairwise secure
channels between local app, local forwarder, next forwarder, etc, etc, all the way to the last
hop.

However, my apologies for this platitude, but trust is local.
The farther you get away (in trust hops) from the source, the less
trust there is, and more likely it becomes that someone on the path will be malicious.
It works the same way with humans :-)

Cheers,
Gene



======================
Gene Tsudik
Chancellor's Professor of Computer Science
University of California, Irvine



On 10/13/16 9:05 AM, Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com> wrote:
Doesn?t an application have a trust channel with its local forwarder, and the local forwarder with the next forwarder, etc.?

Marc

On Oct 13, 2016, at 8:50 AM, Cesar Ghali <cghali at uci.edu<mailto:cghali at uci.edu>> wrote:

Hi Jeff, That's right, untrusted NACKs should not be accepted in the network. In fact a pre-arranged trusted channel is an approach proposed in the paper I shared before. Cesar

On Thu, Oct 13, 2016 at 08:45 Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:
Hi Cesar,

So in Junxiao?s example, the microcontroller would send an unsigned network Nack? Will forwarders be configured to respond to an unsigned Nack which comes from the (supposed) direction from any application? (I had though that these network signalling messages are send between forwarders on a pre-arranged trusted channel.)

- Jeff T

From: Cesar Ghali <cghali at uci.edu<mailto:cghali at uci.edu>>
Date: Thursday, October 13, 2016 at 8:29:00
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>, Jeff Thompson <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>>
Cc: "ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>" <ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>>
Subject: Re: [Ndn-interest] Sending NACKs with ndn-cpp

That's right, mixing network and application NACKs is not a good idea. From a security perspective, this separation is discussed in details in: http://ieeexplore.ieee.org/document/7288477/ Cesar

On Wed, Oct 12, 2016 at 16:07 Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:
Hi JeffT

I have a temperature sensor based on ESP8266 microcontroller. It uses ndn-cpp-lite, connects to a remote forwarder over TCP, and acts as a producer.
The ESP8266, clocked at 80MHz, has limited signing capability. It can sign or verify 8 ECDSA signatures per second.
If Interests are arriving too fast, I want to be able to send a NetworkNack-Congestion so that the remote forwarder can forward less Interests to the sensor.
An application Nack cannot fulfill this purpose because it still requires a signature. Allowing the Interests to time out increases overhead at the remote forwarder because PIT entries stay longer.

Yours, Junxiao


On Wed, Oct 12, 2016 at 10:08 AM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:
Hi Matteo.

A NetworkNack is a ?network? nack because it is generated by a forwarder
in the network, such as NFD. A client library like ndn-cpp is meant to be
used by an application which does not generate network-level messages. It
is called a ?network? nack to distinguish from an ?application? nack. Can
you describe the situation where your application needs to generate a nack?

- Jeff T
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161013/c0bd15ab/attachment.html>

From gts at ics.uci.edu  Thu Oct 13 11:13:37 2016
From: gts at ics.uci.edu (GTS)
Date: Thu, 13 Oct 2016 11:13:37 -0700
Subject: [Ndn-interest] Sending NACKs with ndn-cpp
In-Reply-To: <ea025ffb-819f-4143-963c-49e92845afd7@EMHUB5.ad.ucla.edu>
References: <20161012143256.d3nlm1d0o4c8wks8@webmail.eurecom.fr>
	<D423BB60.37934%jefft0@remap.ucla.edu>
	<CAOFH+OasPNQ71UQ458OyA-9j8ivY4ydPNFyABp=s7jwO1k6oPA@mail.gmail.com>
	<CAAj99Kk-axkc+aA=+TibCzqKCwWtfWr=suwLx9z=npcK41cUTg@mail.gmail.com>
	<27ea99d5-1b46-4e10-b128-2e8689d79876@EMHUB6.ad.ucla.edu>
	<CAAj99KnHh8G4_tfe5fgUqQGXQexTVQq5pnNOx5J39n+pu5ALzQ@mail.gmail.com>
	<032EF4D1-E49C-459C-B1A2-5CEC87D693BD@parc.com>
	<99bf3a5e-8dfc-ed0d-4ddf-c996c59ac6fe@ics.uci.edu>
	<9BAFBBC4-EA86-444F-BB5C-C49CD2B53E45@parc.com>
	<2364d8d4-74bd-2bda-ac16-1ff493f7bc14@ics.uci.edu>
	<ea025ffb-819f-4143-963c-49e92845afd7@EMHUB5.ad.ucla.edu>
Message-ID: <1a348606-d7ed-6cc4-90bf-701a872db953@ics.uci.edu>

Precisely! (Adversary here being something like a rogue app, or a set 
thereof, on the same platform)

Cheers,
Gene

======================
Gene Tsudik
Chancellor's Professor of Computer Science
University of California, Irvine

On 10/13/16 11:03 AM, Thompson, Jeff wrote:
> Hi Gene,
> By ?collocated?, you mean talking over something like a Unix socket on 
> the same computer with the idea that there is little chance of an 
> adversary getting in the middle?
> - Jeff T
>
> From: Ndn-interest <ndn-interest-bounces at lists.cs.ucla.edu 
> <mailto:ndn-interest-bounces at lists.cs.ucla.edu>> on behalf of GTS 
> <gts at ics.uci.edu <mailto:gts at ics.uci.edu>>
> Date: Thursday, October 13, 2016 at 10:10:00
> To: "Marc.Mosko at parc.com <mailto:Marc.Mosko at parc.com>" 
> <Marc.Mosko at parc.com <mailto:Marc.Mosko at parc.com>>
> Cc: "ndn-interest at lists.cs.ucla.edu 
> <mailto:ndn-interest at lists.cs.ucla.edu>" 
> <ndn-interest at lists.cs.ucla.edu <mailto:ndn-interest at lists.cs.ucla.edu>>
> Subject: Re: [Ndn-interest] Sending NACKs with ndn-cpp
>
>
> Yep... I agree in the context of a forwarder talking a *collocated* app.
> Cheers,
> Gene
>
> ======================
> Gene Tsudik
> Chancellor's Professor of Computer Science
> University of California, Irvine
>
> On 10/13/16 9:41 AM, Marc.Mosko at parc.com wrote:
>> I agree things get more murky the further one gets away from where a 
>> message was initiated.
>>
>> But I thought the premise of the previous messages is that adjacent 
>> forwarders already trust each other for NACKs.  My point was that if 
>> forwarders already trust each other for NACks, then why cannot a 
>> forwarder apply a similar trust mechanism to a local app, as it 
>> should know for which name spaces it trusts the app.
>>
>> Marc
>>
>>
>>> On Oct 13, 2016, at 9:36 AM, GTS <gts at ics.uci.edu 
>>> <mailto:gts at ics.uci.edu>> wrote:
>>>
>>>
>>> Marc,
>>>
>>> yes, it's reasonable -- though not always practical -- to assume 
>>> that there are pairwise secure
>>> channels between local app, local forwarder, next forwarder, etc, 
>>> etc, all the way to the last
>>> hop.
>>>
>>> However, my apologies for this platitude, but trust is local.
>>> The farther you get away (in trust hops) from the source, the less
>>> trust there is, and more likely it becomes that someone on the path 
>>> will be malicious.
>>> It works the same way with humans :-)
>>>
>>> Cheers,
>>> Gene
>>>
>>>
>>> ======================
>>> Gene Tsudik
>>> Chancellor's Professor of Computer Science
>>> University of California, Irvine
>>>
>>> On 10/13/16 9:05 AM, Marc.Mosko at parc.com wrote:
>>>> Doesn?t an application have a trust channel with its local 
>>>> forwarder, and the local forwarder with the next forwarder, etc.?
>>>>
>>>> Marc
>>>>
>>>>> On Oct 13, 2016, at 8:50 AM, Cesar Ghali <cghali at uci.edu 
>>>>> <mailto:cghali at uci.edu>> wrote:
>>>>>
>>>>> Hi Jeff, That's right, untrusted NACKs should not be accepted in 
>>>>> the network. In fact a pre-arranged trusted channel is an approach 
>>>>> proposed in the paper I shared before. Cesar
>>>>>
>>>>> On Thu, Oct 13, 2016 at 08:45 Thompson, Jeff 
>>>>> <jefft0 at remap.ucla.edu <mailto:jefft0 at remap.ucla.edu>> wrote:
>>>>>
>>>>>     Hi Cesar,
>>>>>
>>>>>     So in Junxiao?s example, the microcontroller would send an
>>>>>     unsigned network Nack? Will forwarders be configured to
>>>>>     respond to an unsigned Nack which comes from the (supposed)
>>>>>     direction from any application? (I had though that these
>>>>>     network signalling messages are send between forwarders on a
>>>>>     pre-arranged trusted channel.)
>>>>>
>>>>>     - Jeff T
>>>>>
>>>>>     From: Cesar Ghali <cghali at uci.edu <mailto:cghali at uci.edu>>
>>>>>     Date: Thursday, October 13, 2016 at 8:29:00
>>>>>     To: Junxiao Shi <shijunxiao at email.arizona.edu
>>>>>     <mailto:shijunxiao at email.arizona.edu>>, Jeff Thompson
>>>>>     <jefft0 at remap.ucla.edu <mailto:jefft0 at remap.ucla.edu>>
>>>>>     Cc: "ndn-interest at lists.cs.ucla.edu
>>>>>     <mailto:ndn-interest at lists.cs.ucla.edu>"
>>>>>     <ndn-interest at lists.cs.ucla.edu
>>>>>     <mailto:ndn-interest at lists.cs.ucla.edu>>
>>>>>     Subject: Re: [Ndn-interest] Sending NACKs with ndn-cpp
>>>>>
>>>>>     That's right, mixing network and application NACKs is not a
>>>>>     good idea. From a security perspective, this separation is
>>>>>     discussed in details in:
>>>>>     http://ieeexplore.ieee.org/document/7288477/ Cesar
>>>>>
>>>>>     On Wed, Oct 12, 2016 at 16:07 Junxiao Shi
>>>>>     <shijunxiao at email.arizona.edu
>>>>>     <mailto:shijunxiao at email.arizona.edu>> wrote:
>>>>>
>>>>>         Hi JeffT
>>>>>
>>>>>         I have a temperature sensor based on ESP8266
>>>>>         microcontroller. It uses ndn-cpp-lite, connects to a
>>>>>         remote forwarder over TCP, and acts as a producer.
>>>>>         The ESP8266, clocked at 80MHz, has limited signing
>>>>>         capability. It can sign or verify 8 ECDSA signatures per
>>>>>         second.
>>>>>         If Interests are arriving too fast, I want to be able to
>>>>>         send a NetworkNack-Congestion so that the remote forwarder
>>>>>         can forward less Interests to the sensor.
>>>>>         An application Nack cannot fulfill this purpose because it
>>>>>         still requires a signature. Allowing the Interests to time
>>>>>         out increases overhead at the remote forwarder because PIT
>>>>>         entries stay longer.
>>>>>
>>>>>         Yours, Junxiao
>>>>>
>>>>>
>>>>>         On Wed, Oct 12, 2016 at 10:08 AM, Thompson, Jeff
>>>>>         <jefft0 at remap.ucla.edu <mailto:jefft0 at remap.ucla.edu>> wrote:
>>>>>
>>>>>             Hi Matteo.
>>>>>
>>>>>             A NetworkNack is a ?network? nack because it is
>>>>>             generated by a forwarder
>>>>>             in the network, such as NFD. A client library like
>>>>>             ndn-cpp is meant to be
>>>>>             used by an application which does not generate
>>>>>             network-level messages. It
>>>>>             is called a ?network? nack to distinguish from an
>>>>>             ?application? nack. Can
>>>>>             you describe the situation where your application
>>>>>             needs to generate a nack?
>>>>>
>>>>>             - Jeff T
>>>>>
>>>>>         _______________________________________________
>>>>>         Ndn-interest mailing list
>>>>>         Ndn-interest at lists.cs.ucla.edu
>>>>>         <mailto:Ndn-interest at lists.cs.ucla.edu>
>>>>>         http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>
>>>>> _______________________________________________
>>>>> Ndn-interest mailing list
>>>>> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ndn-interest mailing list
>>>> Ndn-interest at lists.cs.ucla.eduhttp://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161013/2fbe1416/attachment.html>

From lixia at CS.UCLA.EDU  Thu Oct 13 17:19:07 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Thu, 13 Oct 2016 17:19:07 -0700
Subject: [Ndn-interest] mininet error
In-Reply-To: <1867736363.525430.1476304186257@mail.yahoo.com>
References: <1867736363.525430.1476304186257.ref@mail.yahoo.com>
	<1867736363.525430.1476304186257@mail.yahoo.com>
Message-ID: <31C17B91-022A-4062-B470-CA5BA9928B43@cs.ucla.edu>

you may want to send the question to mini-NDN mailing list,
   mini-ndn at lists.cs.ucla.edu

FYI.

> On Oct 12, 2016, at 1:29 PM, Sepehr Abdous <sepehrabdous at yahoo.com> wrote:
> 
> Hello All,
> I've tried to install mini-ndn by following steps in https://github.com/named-data/mini-ndn/blob/master/INSTALL.md <https://github.com/named-data/mini-ndn/blob/master/INSTALL.md>
> and in one aspect, it requires installing mini_net,
> again I follow the exact steps stated but when I try to use 
> sudo mn --test pingall
> to see if it works well...
> I encounter this error:
> Exception: Error creating interface pair (h1-eth0,s1-eth1): RTNETLINK answers: Operation not supported
> do you have any idea how can I handle it?
>  
> Sepehr Abdous
> Faculty: abdous at ce.sharif.edu <mailto:abdous at ce.sharif.edu>
> Gmail: sepehrabdous1375 at gmail.com <mailto:sepehrabdous at yahoo.com>
> Cellphone:+989194030591
> School of computer engineering
> Sharif University of Technology
> Tehran, Iran
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161013/6dba2e52/attachment.html>

From Matteo.Bertolino at eurecom.fr  Fri Oct 14 01:40:22 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Fri, 14 Oct 2016 10:40:22 +0200
Subject: [Ndn-interest] ndn-cxx small tutorial: nacks, certificates with repo,
	signed	interest
Message-ID: <20161014104022.shiybktq80os44ow@webmail.eurecom.fr>

Dear all,
this mail is though for who, like me, is just a beginner about NDN.
At the start of my work, I had some difficulties about "how to  
perform" some basic experiments.
Then I resumed in a little pdf the main important steps in the  
following topics:
1- Sending a personalized application nack
2- How to build a certificate chain, how to distribute it with  
repo-ng, how to verify the data
3- How to send and verify a signed interest.

I am absolutely sure that there will be some errors in my explanation,  
but I am sure also that this code and steps here listed  could help a  
novice.
I encourage all to publish their personal documentation, because in my  
opinion they are very useful.

Disclaimer: I found some pieces of code and some steps on the web, on  
the mailing list etc. Most of the work is my own, however.

The pdf is attached. Let me know if you want to contribute to it with  
new use cases. In my opinion, one about ndns is needed, like a section  
that explains well the difference between ndn-cxx and ndn-cpp, between  
mini and ndnsim, and so on.

If there is well done, you can put this file where you want.

You can find it also in my personal git:
https://github.com/MatteoBertolino92/NDN-matteo/blob/master/ndncxx_miniNDN_someUseCases:%20nacks%2C%20certificates%2C%20interest%20verification.pdf

Yours,
Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ndncxx_miniNDN_someUseCases: nacks, certificates, interest verification.pdf
Type: application/pdf
Size: 222708 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161014/b33cf38b/attachment.pdf>

From lanwang at memphis.edu  Fri Oct 14 04:53:48 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 14 Oct 2016 11:53:48 +0000
Subject: [Ndn-interest] mininet error
In-Reply-To: <31C17B91-022A-4062-B470-CA5BA9928B43@cs.ucla.edu>
References: <1867736363.525430.1476304186257.ref@mail.yahoo.com>
	<1867736363.525430.1476304186257@mail.yahoo.com>
	<31C17B91-022A-4062-B470-CA5BA9928B43@cs.ucla.edu>
Message-ID: <B6C9012C-245C-4940-8974-D1BB79D9FA42@memphis.edu>

Yes, Ashlesh and Junxiao are helping him on the mini-ndn mailing list.

Lan

On Oct 13, 2016, at 7:19 PM, Lixia Zhang <lixia at cs.ucla.edu<mailto:lixia at cs.ucla.edu>> wrote:

you may want to send the question to mini-NDN mailing list,
   mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>

FYI.

On Oct 12, 2016, at 1:29 PM, Sepehr Abdous <sepehrabdous at yahoo.com<mailto:sepehrabdous at yahoo.com>> wrote:

Hello All,
I've tried to install mini-ndn by following steps in https://github.com/named-data/mini-ndn/blob/master/INSTALL.md
and in one aspect, it requires installing mini_net,
again I follow the exact steps stated but when I try to use
sudo mn --test pingall
to see if it works well...
I encounter this error:
Exception: Error creating interface pair (h1-eth0,s1-eth1): RTNETLINK answers: Operation not supported
do you have any idea how can I handle it?

Sepehr Abdous
Faculty: abdous at ce.sharif.edu<mailto:abdous at ce.sharif.edu>
Gmail: sepehrabdous1375 at gmail.com<mailto:sepehrabdous at yahoo.com>
Cellphone:+989194030591
School of computer engineering
Sharif University of Technology
Tehran, Iran
_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161014/6bec7c2a/attachment.html>

From shijunxiao at email.arizona.edu  Fri Oct 14 07:29:54 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 14 Oct 2016 07:29:54 -0700
Subject: [Ndn-interest] ndn-cxx small tutorial: nacks,
 certificates with repo, signed interest
In-Reply-To: <20161014104022.shiybktq80os44ow@webmail.eurecom.fr>
References: <20161014104022.shiybktq80os44ow@webmail.eurecom.fr>
Message-ID: <CAOFH+OYGfcaOF6tGjNyQ9BEwsX8-9ELE-kki1uCWaw5WZpwQeg@mail.gmail.com>

Hi Matteo

I encourage you to post the contents on your personal website, like I have
been doing for the past two years https://yoursunny.com/t/ .
The best articles have the opportunity to be featured on named-data.net
official blog (an editor would contact you), which makes you a celebrity.

Yours, Junxiao

On Fri, Oct 14, 2016 at 1:40 AM, Matteo Bertolino <
Matteo.Bertolino at eurecom.fr> wrote:

> Dear all,
> this mail is though for who, like me, is just a beginner about NDN.
> At the start of my work, I had some difficulties about "how to perform"
> some basic experiments.
> Then I resumed in a little pdf the main important steps in the following
> topics:
> 1- Sending a personalized application nack
> 2- How to build a certificate chain, how to distribute it with repo-ng,
> how to verify the data
> 3- How to send and verify a signed interest.
>
> I am absolutely sure that there will be some errors in my explanation, but
> I am sure also that this code and steps here listed  could help a novice.
> I encourage all to publish their personal documentation, because in my
> opinion they are very useful.
>
> Disclaimer: I found some pieces of code and some steps on the web, on the
> mailing list etc. Most of the work is my own, however.
>
> The pdf is attached. Let me know if you want to contribute to it with new
> use cases. In my opinion, one about ndns is needed, like a section that
> explains well the difference between ndn-cxx and ndn-cpp, between mini and
> ndnsim, and so on.
>
> If there is well done, you can put this file where you want.
>
> You can find it also in my personal git:
> https://github.com/MatteoBertolino92/NDN-matteo/blob/master/
> ndncxx_miniNDN_someUseCases:%20nacks%2C%20certificates%2C%20
> interest%20verification.pdf
>
> Yours,
> Matteo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161014/3d73f895/attachment.html>

From Matteo.Bertolino at eurecom.fr  Tue Oct 18 05:39:31 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Tue, 18 Oct 2016 14:39:31 +0200
Subject: [Ndn-interest] From a simulator to real nodes
Message-ID: <20161018143931.e2zb8jbvw3og44ow@webmail.eurecom.fr>

Dear community,
I would like to perform my experiments that I tied in the simulator  
(for example mini) in real nodes (PC, microcontrollors, etc).
Is it enough running on each node just an instance of NLSR and NFD, or  
is it more complicated?
Bests,
Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr



From lanwang at memphis.edu  Tue Oct 18 07:48:05 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Tue, 18 Oct 2016 14:48:05 +0000
Subject: [Ndn-interest] From a simulator to real nodes
In-Reply-To: <20161018143931.e2zb8jbvw3og44ow@webmail.eurecom.fr>
References: <20161018143931.e2zb8jbvw3og44ow@webmail.eurecom.fr>
Message-ID: <AE9B6EE5-2B9D-40B9-A176-D890AE5102BE@memphis.edu>

Matteo,

The software running on each real node should be the same as what you run in each virtual node in mini-NDN (one instance of NLSR and NFD).

Lan

> On Oct 18, 2016, at 7:39 AM, Matteo Bertolino <Matteo.Bertolino at eurecom.fr> wrote:
> 
> Dear community,
> I would like to perform my experiments that I tied in the simulator (for example mini) in real nodes (PC, microcontrollors, etc).
> Is it enough running on each node just an instance of NLSR and NFD, or is it more complicated?
> Bests,
> Matteo
> 
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




From Matteo.Bertolino at eurecom.fr  Tue Oct 18 08:12:56 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Tue, 18 Oct 2016 17:12:56 +0200
Subject: [Ndn-interest] From a simulator to real nodes
In-Reply-To: <AE9B6EE5-2B9D-40B9-A176-D890AE5102BE@memphis.edu>
References: <20161018143931.e2zb8jbvw3og44ow@webmail.eurecom.fr>
	<AE9B6EE5-2B9D-40B9-A176-D890AE5102BE@memphis.edu>
Message-ID: <20161018171256.2n2kt864hwg80kg0@webmail.eurecom.fr>

Thank you Lan.
But shouldn't I wrote some configuration file, for example? Because if  
I run just "sudo ./NLSR/build/bin/nlsr &" it exits with error.
Bests,
Matteo

Quoting "Lan Wang (lanwang)" <lanwang at memphis.edu>:

> Matteo,
>
> The software running on each real node should be the same as what   
> you run in each virtual node in mini-NDN (one instance of NLSR and   
> NFD).
>
> Lan
>
>> On Oct 18, 2016, at 7:39 AM, Matteo Bertolino   
>> <Matteo.Bertolino at eurecom.fr> wrote:
>>
>> Dear community,
>> I would like to perform my experiments that I tied in the simulator  
>>  (for example mini) in real nodes (PC, microcontrollors, etc).
>> Is it enough running on each node just an instance of NLSR and NFD,  
>>  or is it more complicated?
>> Bests,
>> Matteo
>>
>> -------------------------------------------------------------------------------
>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From lanwang at memphis.edu  Tue Oct 18 08:24:37 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Tue, 18 Oct 2016 15:24:37 +0000
Subject: [Ndn-interest] From a simulator to real nodes
In-Reply-To: <20161018171256.2n2kt864hwg80kg0@webmail.eurecom.fr>
References: <20161018143931.e2zb8jbvw3og44ow@webmail.eurecom.fr>
	<AE9B6EE5-2B9D-40B9-A176-D890AE5102BE@memphis.edu>
	<20161018171256.2n2kt864hwg80kg0@webmail.eurecom.fr>
Message-ID: <51F440E4-5D03-4EEA-9EAE-8199DA705996@memphis.edu>

Yes you need a configuration file.  There is a sample that comes with the software.  In mini-NDN, I think it is automatically generated based on the topology you specify.  But in a real node, you need to modify the sample file.

Lan

> On Oct 18, 2016, at 10:12 AM, Matteo Bertolino <Matteo.Bertolino at eurecom.fr> wrote:
> 
> Thank you Lan.
> But shouldn't I wrote some configuration file, for example? Because if I run just "sudo ./NLSR/build/bin/nlsr &" it exits with error.
> Bests,
> Matteo
> 
> Quoting "Lan Wang (lanwang)" <lanwang at memphis.edu>:
> 
>> Matteo,
>> 
>> The software running on each real node should be the same as what  you run in each virtual node in mini-NDN (one instance of NLSR and  NFD).
>> 
>> Lan
>> 
>>> On Oct 18, 2016, at 7:39 AM, Matteo Bertolino  <Matteo.Bertolino at eurecom.fr> wrote:
>>> 
>>> Dear community,
>>> I would like to perform my experiments that I tied in the simulator  (for example mini) in real nodes (PC, microcontrollors, etc).
>>> Is it enough running on each node just an instance of NLSR and NFD,  or is it more complicated?
>>> Bests,
>>> Matteo
>>> 
>>> -------------------------------------------------------------------------------
>>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>> 
>>> _______________________________________________
>>> Ndn-interest mailing list
>>> Ndn-interest at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> 
>> 
> 
> 
> 
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
> 




From Matteo.Bertolino at eurecom.fr  Wed Oct 19 00:43:16 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Wed, 19 Oct 2016 09:43:16 +0200
Subject: [Ndn-interest] From a simulator to real nodes
In-Reply-To: <51F440E4-5D03-4EEA-9EAE-8199DA705996@memphis.edu>
References: <20161018143931.e2zb8jbvw3og44ow@webmail.eurecom.fr>
	<AE9B6EE5-2B9D-40B9-A176-D890AE5102BE@memphis.edu>
	<20161018171256.2n2kt864hwg80kg0@webmail.eurecom.fr>
	<51F440E4-5D03-4EEA-9EAE-8199DA705996@memphis.edu>
Message-ID: <20161019094316.gr8gsedrkoow0cgs@webmail.eurecom.fr>

Dear Lan, thank you very much.
My last question is: how to learn the system about the topology? I  
mean, if I have 4 physical nodes, A B C and D, how can I express to  
put these nodes in this topology:
A - B - C - D
or in the second one?
A - C
| \ |
B - D

Should I have to write by hand the section "neighbor" of nlsr.conf, like:
neighbor
{
   name /ndn/edu/%C1.Router/cs/c
   face-uri udp://1.0.0.1
   link-cost 10
}
?

Thank you,
Bests, Matteo

Quoting "Lan Wang (lanwang)" <lanwang at memphis.edu>:

> Yes you need a configuration file.  There is a sample that comes   
> with the software.  In mini-NDN, I think it is automatically   
> generated based on the topology you specify.  But in a real node,   
> you need to modify the sample file.
>
> Lan
>
>> On Oct 18, 2016, at 10:12 AM, Matteo Bertolino   
>> <Matteo.Bertolino at eurecom.fr> wrote:
>>
>> Thank you Lan.
>> But shouldn't I wrote some configuration file, for example? Because  
>>  if I run just "sudo ./NLSR/build/bin/nlsr &" it exits with error.
>> Bests,
>> Matteo
>>
>> Quoting "Lan Wang (lanwang)" <lanwang at memphis.edu>:
>>
>>> Matteo,
>>>
>>> The software running on each real node should be the same as what   
>>>  you run in each virtual node in mini-NDN (one instance of NLSR  
>>> and   NFD).
>>>
>>> Lan
>>>
>>>> On Oct 18, 2016, at 7:39 AM, Matteo Bertolino    
>>>> <Matteo.Bertolino at eurecom.fr> wrote:
>>>>
>>>> Dear community,
>>>> I would like to perform my experiments that I tied in the   
>>>> simulator  (for example mini) in real nodes (PC,   
>>>> microcontrollors, etc).
>>>> Is it enough running on each node just an instance of NLSR and   
>>>> NFD,  or is it more complicated?
>>>> Bests,
>>>> Matteo
>>>>
>>>> -------------------------------------------------------------------------------
>>>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>>>
>>>> _______________________________________________
>>>> Ndn-interest mailing list
>>>> Ndn-interest at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------------------------------
>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>
>
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From lanwang at memphis.edu  Wed Oct 19 09:37:50 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 19 Oct 2016 16:37:50 +0000
Subject: [Ndn-interest] From a simulator to real nodes
In-Reply-To: <20161019094316.gr8gsedrkoow0cgs@webmail.eurecom.fr>
References: <20161018143931.e2zb8jbvw3og44ow@webmail.eurecom.fr>
	<AE9B6EE5-2B9D-40B9-A176-D890AE5102BE@memphis.edu>
	<20161018171256.2n2kt864hwg80kg0@webmail.eurecom.fr>
	<51F440E4-5D03-4EEA-9EAE-8199DA705996@memphis.edu>
	<20161019094316.gr8gsedrkoow0cgs@webmail.eurecom.fr>
Message-ID: <40BA870A-48C0-4273-989E-B379A2501933@memphis.edu>

Yes, you will need to modify this section and have one per neighbor.  For example, A needs to have C, B and D as neighbors.

Lan

> On Oct 19, 2016, at 2:43 AM, Matteo Bertolino <Matteo.Bertolino at eurecom.fr> wrote:
> 
> Dear Lan, thank you very much.
> My last question is: how to learn the system about the topology? I mean, if I have 4 physical nodes, A B C and D, how can I express to put these nodes in this topology:
> A - B - C - D
> or in the second one?
> A - C
> | \ |
> B - D
> 
> Should I have to write by hand the section "neighbor" of nlsr.conf, like:
> neighbor
> {
>  name /ndn/edu/%C1.Router/cs/c
>  face-uri udp://1.0.0.1
>  link-cost 10
> }
> ?
> 
> Thank you,
> Bests, Matteo
> 
> Quoting "Lan Wang (lanwang)" <lanwang at memphis.edu>:
> 
>> Yes you need a configuration file.  There is a sample that comes  with the software.  In mini-NDN, I think it is automatically  generated based on the topology you specify.  But in a real node,  you need to modify the sample file.
>> 
>> Lan
>> 
>>> On Oct 18, 2016, at 10:12 AM, Matteo Bertolino  <Matteo.Bertolino at eurecom.fr> wrote:
>>> 
>>> Thank you Lan.
>>> But shouldn't I wrote some configuration file, for example? Because  if I run just "sudo ./NLSR/build/bin/nlsr &" it exits with error.
>>> Bests,
>>> Matteo
>>> 
>>> Quoting "Lan Wang (lanwang)" <lanwang at memphis.edu>:
>>> 
>>>> Matteo,
>>>> 
>>>> The software running on each real node should be the same as what   you run in each virtual node in mini-NDN (one instance of NLSR and   NFD).
>>>> 
>>>> Lan
>>>> 
>>>>> On Oct 18, 2016, at 7:39 AM, Matteo Bertolino   <Matteo.Bertolino at eurecom.fr> wrote:
>>>>> 
>>>>> Dear community,
>>>>> I would like to perform my experiments that I tied in the  simulator  (for example mini) in real nodes (PC,  microcontrollors, etc).
>>>>> Is it enough running on each node just an instance of NLSR and  NFD,  or is it more complicated?
>>>>> Bests,
>>>>> Matteo
>>>>> 
>>>>> -------------------------------------------------------------------------------
>>>>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>>>> 
>>>>> _______________________________________________
>>>>> Ndn-interest mailing list
>>>>> Ndn-interest at lists.cs.ucla.edu
>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> -------------------------------------------------------------------------------
>>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>> 
>> 
>> 
> 
> 
> 
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
> 




From Matteo.Bertolino at eurecom.fr  Fri Oct 21 04:21:34 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Fri, 21 Oct 2016 13:21:34 +0200
Subject: [Ndn-interest] Testbed architecture
Message-ID: <20161021132134.ewbgwzj6kgkgc8gw@webmail.eurecom.fr>

Good morning community,
I am wondering whether a little literature about the Testbed  
architecture is available.

I search something that probably is not included in the category  
"Testbed" on the official site.

I mean, suppose that I am in Italy and I would like to communicate  
with a node in US. I send an Interest, then I suppose that the request  
is encapsulated in an IP request in order to arrive to destination.
Is it correct? Can I know more about the practical steps?

Bests, Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr



From christos at colostate.edu  Fri Oct 21 05:18:22 2016
From: christos at colostate.edu (Christos Papadopoulos)
Date: Fri, 21 Oct 2016 06:18:22 -0600
Subject: [Ndn-interest] Testbed architecture
In-Reply-To: <20161021132134.ewbgwzj6kgkgc8gw@webmail.eurecom.fr>
References: <20161021132134.ewbgwzj6kgkgc8gw@webmail.eurecom.fr>
Message-ID: <58c0ea79-a505-686d-38af-9423d7da9c04@colostate.edu>

Matteo,

Are you connected to the NDN testbed through a node local to you? If 
yes, you would send an interest to your local NDN node, and that node 
will in turn route your interest to the closest node that advertises the 
content you are looking for.

Remember that with NDN you no longer communicate with other nodes 
(unless they are named explicitly), you request content. Your Interest 
will be directed to the closest provider of the content, which may be 
your local node, if the content was cached there.

Now assuming that you requested content that is currently only available 
through a publisher in the US, then your local node will select a face 
to forward the Interest based on what NLSR (the NDN routing protocol) 
specifies. In many cases the face will use an IP tunnel to get to the 
next hop. Eventually your Interest will reach the US publisher through a 
series of hops determined by the routing protocol.

Not sure if this helps you, but I wanted to point out that in NDN the 
term "I want to communicate with a node in the US" is not meaningful.

Christos.



On 10/21/2016 05:21 AM, Matteo Bertolino wrote:
> Good morning community,
> I am wondering whether a little literature about the Testbed 
> architecture is available.
>
> I search something that probably is not included in the category 
> "Testbed" on the official site.
>
> I mean, suppose that I am in Italy and I would like to communicate 
> with a node in US. I send an Interest, then I suppose that the request 
> is encapsulated in an IP request in order to arrive to destination.
> Is it correct? Can I know more about the practical steps?
>
> Bests, Matteo
>
> ------------------------------------------------------------------------------- 
>
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest



From Matteo.Bertolino at eurecom.fr  Fri Oct 21 05:29:57 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Fri, 21 Oct 2016 14:29:57 +0200
Subject: [Ndn-interest] Testbed architecture
In-Reply-To: <58c0ea79-a505-686d-38af-9423d7da9c04@colostate.edu>
References: <20161021132134.ewbgwzj6kgkgc8gw@webmail.eurecom.fr>
	<58c0ea79-a505-686d-38af-9423d7da9c04@colostate.edu>
Message-ID: <20161021142957.2ehxxe6nsw000wow@webmail.eurecom.fr>

Dear Christos,
thank you for your answer. Yes I expressed bad myself, however the  
point of my question was your sentece:

"In many cases the face will use an IP tunnel to get to the next hop."

I would like to deepen this point actually. Precisely, how? Is it a  
TCP tunnel, an UDP tunnel, do you know where I can check how this  
tunnel is created?

Thank you very much.
Yours,
Matteo


Quoting Christos Papadopoulos <christos at colostate.edu>:

> Matteo,
>
> Are you connected to the NDN testbed through a node local to you? If
> yes, you would send an interest to your local NDN node, and that node
> will in turn route your interest to the closest node that advertises
> the content you are looking for.
>
> Remember that with NDN you no longer communicate with other nodes
> (unless they are named explicitly), you request content. Your Interest
> will be directed to the closest provider of the content, which may be
> your local node, if the content was cached there.
>
> Now assuming that you requested content that is currently only
> available through a publisher in the US, then your local node will
> select a face to forward the Interest based on what NLSR (the NDN
> routing protocol) specifies. In many cases the face will use an IP
> tunnel to get to the next hop. Eventually your Interest will reach the
> US publisher through a series of hops determined by the routing
> protocol.
>
> Not sure if this helps you, but I wanted to point out that in NDN the
> term "I want to communicate with a node in the US" is not meaningful.
>
> Christos.
>
>
>
> On 10/21/2016 05:21 AM, Matteo Bertolino wrote:
>> Good morning community,
>> I am wondering whether a little literature about the Testbed   
>> architecture is available.
>>
>> I search something that probably is not included in the category   
>> "Testbed" on the official site.
>>
>> I mean, suppose that I am in Italy and I would like to communicate   
>> with a node in US. I send an Interest, then I suppose that the   
>> request is encapsulated in an IP request in order to arrive to   
>> destination.
>> Is it correct? Can I know more about the practical steps?
>>
>> Bests, Matteo
>>
>> ------------------------------------------------------------------------------- This message was sent using EURECOM Webmail:   
>> http://webmail.eurecom.fr
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From mhasabet at gmail.com  Fri Oct 21 05:50:56 2016
From: mhasabet at gmail.com (Muhammad Hosain Abdollahi Sabet)
Date: Fri, 21 Oct 2016 16:20:56 +0330
Subject: [Ndn-interest] Testbed architecture
In-Reply-To: <20161021142957.2ehxxe6nsw000wow@webmail.eurecom.fr>
References: <20161021132134.ewbgwzj6kgkgc8gw@webmail.eurecom.fr>
	<58c0ea79-a505-686d-38af-9423d7da9c04@colostate.edu>
	<20161021142957.2ehxxe6nsw000wow@webmail.eurecom.fr>
Message-ID: <CADQ0MFZWOwtq4v0hZXLU+VsZ7q8bn7z2p5S=XixtNdS7Tu60sg@mail.gmail.com>

Hi Matteo,

As far as I know all of underlying connections are established on udp
tunnels. You are registering a prefix on a faceUri, which is on a udp
tunnel. But nfd cares about prefixes(names) and faces, and what the
underlying of the face is, is out of scope of nfd.

Thanks,
Sabet

On Fri, Oct 21, 2016 at 3:59 PM, Matteo Bertolino <
Matteo.Bertolino at eurecom.fr> wrote:

> Dear Christos,
> thank you for your answer. Yes I expressed bad myself, however the point
> of my question was your sentece:
>
> "In many cases the face will use an IP tunnel to get to the next hop."
>
> I would like to deepen this point actually. Precisely, how? Is it a TCP
> tunnel, an UDP tunnel, do you know where I can check how this tunnel is
> created?
>
> Thank you very much.
> Yours,
> Matteo
>
>
>
> Quoting Christos Papadopoulos <christos at colostate.edu>:
>
> Matteo,
>>
>> Are you connected to the NDN testbed through a node local to you? If
>> yes, you would send an interest to your local NDN node, and that node
>> will in turn route your interest to the closest node that advertises
>> the content you are looking for.
>>
>> Remember that with NDN you no longer communicate with other nodes
>> (unless they are named explicitly), you request content. Your Interest
>> will be directed to the closest provider of the content, which may be
>> your local node, if the content was cached there.
>>
>> Now assuming that you requested content that is currently only
>> available through a publisher in the US, then your local node will
>> select a face to forward the Interest based on what NLSR (the NDN
>> routing protocol) specifies. In many cases the face will use an IP
>> tunnel to get to the next hop. Eventually your Interest will reach the
>> US publisher through a series of hops determined by the routing
>> protocol.
>>
>> Not sure if this helps you, but I wanted to point out that in NDN the
>> term "I want to communicate with a node in the US" is not meaningful.
>>
>> Christos.
>>
>>
>>
>> On 10/21/2016 05:21 AM, Matteo Bertolino wrote:
>>
>>> Good morning community,
>>> I am wondering whether a little literature about the Testbed
>>> architecture is available.
>>>
>>> I search something that probably is not included in the category
>>> "Testbed" on the official site.
>>>
>>> I mean, suppose that I am in Italy and I would like to communicate  with
>>> a node in US. I send an Interest, then I suppose that the  request is
>>> encapsulated in an IP request in order to arrive to  destination.
>>> Is it correct? Can I know more about the practical steps?
>>>
>>> Bests, Matteo
>>>
>>> -------------------------------------------------------------------------------
>>> This message was sent using EURECOM Webmail:  http://webmail.eurecom.fr
>>>
>>> _______________________________________________
>>> Ndn-interest mailing list
>>> Ndn-interest at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>
>
>
> ------------------------------------------------------------
> -------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161021/9e6af844/attachment.html>

From lanwang at memphis.edu  Fri Oct 21 07:48:48 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 21 Oct 2016 14:48:48 +0000
Subject: [Ndn-interest] Testbed architecture
In-Reply-To: <CADQ0MFZWOwtq4v0hZXLU+VsZ7q8bn7z2p5S=XixtNdS7Tu60sg@mail.gmail.com>
References: <20161021132134.ewbgwzj6kgkgc8gw@webmail.eurecom.fr>
	<58c0ea79-a505-686d-38af-9423d7da9c04@colostate.edu>
	<20161021142957.2ehxxe6nsw000wow@webmail.eurecom.fr>
	<CADQ0MFZWOwtq4v0hZXLU+VsZ7q8bn7z2p5S=XixtNdS7Tu60sg@mail.gmail.com>
Message-ID: <44DFEB63-4746-487A-A36D-752394C6046A@memphis.edu>

The NDN testbed currently uses udp tunnels between the hub nodes, but it is not restricted to using udp tunnels.  Other types tunnels can be used if there is a strong case for them.  Right now the tunnels are automatically set up by NLSR when it starts up, but we are moving this part out of NLSR.  Operators should then put the tunnel setup in NFD startup scripts and they can choose whichever type of tunnel that fits the purpose.

Lan

On Oct 21, 2016, at 7:50 AM, Muhammad Hosain Abdollahi Sabet <mhasabet at gmail.com<mailto:mhasabet at gmail.com>> wrote:

Hi Matteo,

As far as I know all of underlying connections are established on udp tunnels. You are registering a prefix on a faceUri, which is on a udp tunnel. But nfd cares about prefixes(names) and faces, and what the underlying of the face is, is out of scope of nfd.

Thanks,
Sabet

On Fri, Oct 21, 2016 at 3:59 PM, Matteo Bertolino <Matteo.Bertolino at eurecom.fr<mailto:Matteo.Bertolino at eurecom.fr>> wrote:
Dear Christos,
thank you for your answer. Yes I expressed bad myself, however the point of my question was your sentece:

"In many cases the face will use an IP tunnel to get to the next hop."

I would like to deepen this point actually. Precisely, how? Is it a TCP tunnel, an UDP tunnel, do you know where I can check how this tunnel is created?

Thank you very much.
Yours,
Matteo



Quoting Christos Papadopoulos <christos at colostate.edu<mailto:christos at colostate.edu>>:

Matteo,

Are you connected to the NDN testbed through a node local to you? If
yes, you would send an interest to your local NDN node, and that node
will in turn route your interest to the closest node that advertises
the content you are looking for.

Remember that with NDN you no longer communicate with other nodes
(unless they are named explicitly), you request content. Your Interest
will be directed to the closest provider of the content, which may be
your local node, if the content was cached there.

Now assuming that you requested content that is currently only
available through a publisher in the US, then your local node will
select a face to forward the Interest based on what NLSR (the NDN
routing protocol) specifies. In many cases the face will use an IP
tunnel to get to the next hop. Eventually your Interest will reach the
US publisher through a series of hops determined by the routing
protocol.

Not sure if this helps you, but I wanted to point out that in NDN the
term "I want to communicate with a node in the US" is not meaningful.

Christos.



On 10/21/2016 05:21 AM, Matteo Bertolino wrote:
Good morning community,
I am wondering whether a little literature about the Testbed  architecture is available.

I search something that probably is not included in the category  "Testbed" on the official site.

I mean, suppose that I am in Italy and I would like to communicate  with a node in US. I send an Interest, then I suppose that the  request is encapsulated in an IP request in order to arrive to  destination.
Is it correct? Can I know more about the practical steps?

Bests, Matteo

------------------------------------------------------------------------------- This message was sent using EURECOM Webmail:  http://webmail.eurecom.fr<http://webmail.eurecom.fr/>

_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr<http://webmail.eurecom.fr/>


_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161021/8ff59696/attachment.html>

From peter at remap.UCLA.edu  Fri Oct 21 14:23:21 2016
From: peter at remap.UCLA.edu (Gusev, Peter)
Date: Fri, 21 Oct 2016 21:23:21 +0000
Subject: [Ndn-interest] Accessing historical data using ChronoSync
Message-ID: <200572E9-7E8F-45C8-8ABB-709CED6EF969@remap.ucla.edu>

Hi all,

I?m curious whether there is any work done on the issue I?ll explain below. The issue concerns fetching historical chat data that was generated while a user was gone from the chat. This means two cases:

#1 Newcomers
In current ChronoSync implementation<https://github.com/named-data/ndn-cpp/blob/master/include/ndn-cpp/sync/chrono-sync2013.hpp>, when a newcomer wants to join existing chat (i.e. chat that was created earlier by someone else), she issues initial sync interest with ?00? marker (or any initial marker defined by implementation). Then, she waits for the current sync state data object (which contains current digest tree). This sync state data object can be sent out only by one of the currently active members (in the chatroom). Hence, the problem - if there are no active chat members (meaning, everyone already left the chatroom), newcomer will never receive the latest sync state object and eventually, will initialize a new digest tree from scratch, thus leaving herself without knowledge of the previous chat history.
Basically, I?m trying to figure out now how to prevent this and allow newcomers to retrieve chat history that was generated before them, without relying on the presence of active chat members.

#2 Returning users
Similar case, but simpler, with returning users. How do returning users (those, who were in the chat earlier, left eventually and now have joined chat again) can fetch all the data that was published while they were gone?
IMPORTANT NOTE: For both cases (#1 and #2), I assume the presence of the "network persistent storage" which stores all chat and sync data. With such assumption, I think, fetching of historical data can be resolved rather straightforwardly: returning user instead of issuing initial sync interest (with ?00? marker) issues sync interest with the digest, known for her when she left. Upon receiving sync state data, she updates digest tree with new changes and issues another, new sync interest. By repeating these steps sequentially, returning user is able to ?fast-forward? to the latest sync state and successfully join the chat.

Back to the case #1 -  after some thinking on the possible implementation workarounds, I came with few alternatives, neither of which seems satisfying to me:

1/ Publish initial sync state data (initial digest tree generated by chat?s creator) under the name with initial marker (?00?).
As this data will go to the ?network persistent storage? (i guess this will need to be clarified further on what does it actually mean), newcomers are able to receive data for their initial interests without requiring any active members in the chat. Upon receipt of this data, they ?fast-forward? in a similar way as returning users do.

2/ Publish versioned meta-object under the name with initial marker (?00?) which encapsulates latest sync state object (or it?s name) so that newcomer is able to use exclusion filters and/or rightmost child selector to quickly "jump" to the latest sync state object.
As this meta-object needs to be re-generated every time sync state object is updated, it seems that there might be potential difficulties in cases of simultaneous data generation and recovering.

3/ Use digests, where every newly generated digest comes after previous one in lexicographical order.
That way, newcomers simply use RightMostChild selector for initial interest (instead of ?00? marker) to fetch latest available sync state.
Didn?t do any research yet on whether this is possible in ChronoSync case (this<http://www.itu.dk/people/pagh/papers/sparse.pdf> seems relevant).

Please, let me know what you guys think on any of this. Any input will be appreciated.
Thanks,

--
Peter Gusev

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

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161021/4afe1f35/attachment.html>

From lixia at CS.UCLA.EDU  Fri Oct 21 19:55:58 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Fri, 21 Oct 2016 19:55:58 -0700
Subject: [Ndn-interest] Accessing historical data using ChronoSync
In-Reply-To: <200572E9-7E8F-45C8-8ABB-709CED6EF969@remap.ucla.edu>
References: <200572E9-7E8F-45C8-8ABB-709CED6EF969@remap.ucla.edu>
Message-ID: <E75F9356-0284-4FA9-8A5A-64559400D9EF@cs.ucla.edu>

1/ as you pointed out, to keep history requires a logger of the chatroom.
2/ for protocol specifics, maybe a f2f chat would be more effective?
you are 0.3 miles away from CS building :-)
we should resume the joint meetings.

> On Oct 21, 2016, at 2:23 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:
> 
> Hi all,
> 
> I?m curious whether there is any work done on the issue I?ll explain below. The issue concerns fetching historical chat data that was generated while a user was gone from the chat. This means two cases:
> 
> #1 Newcomers
> In current ChronoSync implementation <https://github.com/named-data/ndn-cpp/blob/master/include/ndn-cpp/sync/chrono-sync2013.hpp>, when a newcomer wants to join existing chat (i.e. chat that was created earlier by someone else), she issues initial sync interest with ?00? marker (or any initial marker defined by implementation). Then, she waits for the current sync state data object (which contains current digest tree). This sync state data object can be sent out only by one of the currently active members (in the chatroom). Hence, the problem - if there are no active chat members (meaning, everyone already left the chatroom), newcomer will never receive the latest sync state object and eventually, will initialize a new digest tree from scratch, thus leaving herself without knowledge of the previous chat history.
> Basically, I?m trying to figure out now how to prevent this and allow newcomers to retrieve chat history that was generated before them, without relying on the presence of active chat members.
> 
> #2 Returning users
> Similar case, but simpler, with returning users. How do returning users (those, who were in the chat earlier, left eventually and now have joined chat again) can fetch all the data that was published while they were gone? 
> IMPORTANT NOTE: For both cases (#1 and #2), I assume the presence of the "network persistent storage" which stores all chat and sync data. With such assumption, I think, fetching of historical data can be resolved rather straightforwardly: returning user instead of issuing initial sync interest (with ?00? marker) issues sync interest with the digest, known for her when she left. Upon receiving sync state data, she updates digest tree with new changes and issues another, new sync interest. By repeating these steps sequentially, returning user is able to ?fast-forward? to the latest sync state and successfully join the chat.
> 
> Back to the case #1 -  after some thinking on the possible implementation workarounds, I came with few alternatives, neither of which seems satisfying to me:
> 
> 1/ Publish initial sync state data (initial digest tree generated by chat?s creator) under the name with initial marker (?00?). 
> As this data will go to the ?network persistent storage? (i guess this will need to be clarified further on what does it actually mean), newcomers are able to receive data for their initial interests without requiring any active members in the chat. Upon receipt of this data, they ?fast-forward? in a similar way as returning users do.
> 
> 2/ Publish versioned meta-object under the name with initial marker (?00?) which encapsulates latest sync state object (or it?s name) so that newcomer is able to use exclusion filters and/or rightmost child selector to quickly "jump" to the latest sync state object.
> As this meta-object needs to be re-generated every time sync state object is updated, it seems that there might be potential difficulties in cases of simultaneous data generation and recovering.
> 
> 3/ Use digests, where every newly generated digest comes after previous one in lexicographical order.
> That way, newcomers simply use RightMostChild selector for initial interest (instead of ?00? marker) to fetch latest available sync state. 
> Didn?t do any research yet on whether this is possible in ChronoSync case (this <http://www.itu.dk/people/pagh/papers/sparse.pdf> seems relevant).
> 
> Please, let me know what you guys think on any of this. Any input will be appreciated.
> Thanks, 
> 
> -- 
> Peter Gusev
> 
> peter at remap.ucla.edu <mailto:peter at remap.ucla.edu>
> +1 213 5872748
> peetonn_ (skype)
> 
> Software Engineer/Programmer Analyst @ REMAP UCLA
> 
> Video streaming/ICN networks/Creative Development
> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161021/8d51b9f7/attachment.html>

From wentaoshang at ucla.edu  Fri Oct 21 20:25:29 2016
From: wentaoshang at ucla.edu (Wentao Shang)
Date: Fri, 21 Oct 2016 20:25:29 -0700
Subject: [Ndn-interest] Accessing historical data using ChronoSync
In-Reply-To: <200572E9-7E8F-45C8-8ABB-709CED6EF969@remap.ucla.edu>
References: <200572E9-7E8F-45C8-8ABB-709CED6EF969@remap.ucla.edu>
Message-ID: <BC059F2A-C9E5-43C0-B0BB-3360867CA1DB@ucla.edu>


> On Oct 21, 2016, at 2:23 PM, Gusev, Peter <peter at remap.UCLA.edu> wrote:
> 
> Hi all,
> 
> I?m curious whether there is any work done on the issue I?ll explain below. The issue concerns fetching historical chat data that was generated while a user was gone from the chat. This means two cases:
> 
> #1 Newcomers
> In current ChronoSync implementation, when a newcomer wants to join existing chat (i.e. chat that was created earlier by someone else), she issues initial sync interest with ?00? marker (or any initial marker defined by implementation). Then, she waits for the current sync state data object (which contains current digest tree). This sync state data object can be sent out only by one of the currently active members (in the chatroom). Hence, the problem - if there are no active chat members (meaning, everyone already left the chatroom), newcomer will never receive the latest sync state object and eventually, will initialize a new digest tree from scratch, thus leaving herself without knowledge of the previous chat history.
> Basically, I?m trying to figure out now how to prevent this and allow newcomers to retrieve chat history that was generated before them, without relying on the presence of active chat members.
> 
> #2 Returning users
> Similar case, but simpler, with returning users. How do returning users (those, who were in the chat earlier, left eventually and now have joined chat again) can fetch all the data that was published while they were gone? 
> IMPORTANT NOTE: For both cases (#1 and #2), I assume the presence of the "network persistent storage" which stores all chat and sync data. With such assumption, I think, fetching of historical data can be resolved rather straightforwardly: returning user instead of issuing initial sync interest (with ?00? marker) issues sync interest with the digest, known for her when she left. Upon receiving sync state data, she updates digest tree with new changes and issues another, new sync interest. By repeating these steps sequentially, returning user is able to ?fast-forward? to the latest sync state and successfully join the chat.
> 
> Back to the case #1 -  after some thinking on the possible implementation workarounds, I came with few alternatives, neither of which seems satisfying to me:
> 
> 1/ Publish initial sync state data (initial digest tree generated by chat?s creator) under the name with initial marker (?00?). 
> As this data will go to the ?network persistent storage? (i guess this will need to be clarified further on what does it actually mean), newcomers are able to receive data for their initial interests without requiring any active members in the chat. Upon receipt of this data, they ?fast-forward? in a similar way as returning users do.

Off the top of my head: why not have the new comer send a sync Interest without any digest? This interest will fetch whatever sync reply out there and the new comer can start from there. It may not work if the sync history diverged at some time and a recovery was performed to merge the conflict. But I didn?t think through this very carefully? 

> 
> 2/ Publish versioned meta-object under the name with initial marker (?00?) which encapsulates latest sync state object (or it?s name) so that newcomer is able to use exclusion filters and/or rightmost child selector to quickly "jump" to the latest sync state object.
> As this meta-object needs to be re-generated every time sync state object is updated, it seems that there might be potential difficulties in cases of simultaneous data generation and recovering.
> 
> 3/ Use digests, where every newly generated digest comes after previous one in lexicographical order.

How do you guarantee lexical order using digests? They are just random numbers generated by the hash functions? 

Wentao

> That way, newcomers simply use RightMostChild selector for initial interest (instead of ?00? marker) to fetch latest available sync state. 
> Didn?t do any research yet on whether this is possible in ChronoSync case (this seems relevant).
> 
> Please, let me know what you guys think on any of this. Any input will be appreciated.
> Thanks, 
> 
> -- 
> Peter Gusev
> 
> peter at remap.ucla.edu
> +1 213 5872748
> peetonn_ (skype)
> 
> Software Engineer/Programmer Analyst @ REMAP UCLA
> 
> Video streaming/ICN networks/Creative Development
> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




From wentaoshang at ucla.edu  Fri Oct 21 20:38:07 2016
From: wentaoshang at ucla.edu (Wentao Shang)
Date: Fri, 21 Oct 2016 20:38:07 -0700
Subject: [Ndn-interest] Accessing historical data using ChronoSync
In-Reply-To: <BC059F2A-C9E5-43C0-B0BB-3360867CA1DB@ucla.edu>
References: <200572E9-7E8F-45C8-8ABB-709CED6EF969@remap.ucla.edu>
	<BC059F2A-C9E5-43C0-B0BB-3360867CA1DB@ucla.edu>
Message-ID: <A9F0E8B8-7F46-4647-ADA0-F8EADAE9D8D7@ucla.edu>


> On Oct 21, 2016, at 8:25 PM, Wentao Shang <wentaoshang at ucla.edu> wrote:
> 
>> 
>> On Oct 21, 2016, at 2:23 PM, Gusev, Peter <peter at remap.UCLA.edu> wrote:
>> 
>> Hi all,
>> 
>> I?m curious whether there is any work done on the issue I?ll explain below. The issue concerns fetching historical chat data that was generated while a user was gone from the chat. This means two cases:
>> 
>> #1 Newcomers
>> In current ChronoSync implementation, when a newcomer wants to join existing chat (i.e. chat that was created earlier by someone else), she issues initial sync interest with ?00? marker (or any initial marker defined by implementation). Then, she waits for the current sync state data object (which contains current digest tree). This sync state data object can be sent out only by one of the currently active members (in the chatroom). Hence, the problem - if there are no active chat members (meaning, everyone already left the chatroom), newcomer will never receive the latest sync state object and eventually, will initialize a new digest tree from scratch, thus leaving herself without knowledge of the previous chat history.
>> Basically, I?m trying to figure out now how to prevent this and allow newcomers to retrieve chat history that was generated before them, without relying on the presence of active chat members.
>> 
>> #2 Returning users
>> Similar case, but simpler, with returning users. How do returning users (those, who were in the chat earlier, left eventually and now have joined chat again) can fetch all the data that was published while they were gone? 
>> IMPORTANT NOTE: For both cases (#1 and #2), I assume the presence of the "network persistent storage" which stores all chat and sync data. With such assumption, I think, fetching of historical data can be resolved rather straightforwardly: returning user instead of issuing initial sync interest (with ?00? marker) issues sync interest with the digest, known for her when she left. Upon receiving sync state data, she updates digest tree with new changes and issues another, new sync interest. By repeating these steps sequentially, returning user is able to ?fast-forward? to the latest sync state and successfully join the chat.
>> 
>> Back to the case #1 -  after some thinking on the possible implementation workarounds, I came with few alternatives, neither of which seems satisfying to me:
>> 
>> 1/ Publish initial sync state data (initial digest tree generated by chat?s creator) under the name with initial marker (?00?). 
>> As this data will go to the ?network persistent storage? (i guess this will need to be clarified further on what does it actually mean), newcomers are able to receive data for their initial interests without requiring any active members in the chat. Upon receipt of this data, they ?fast-forward? in a similar way as returning users do.
> 
> Off the top of my head: why not have the new comer send a sync Interest without any digest? This interest will fetch whatever sync reply out there and the new comer can start from there. It may not work if the sync history diverged at some time and a recovery was performed to merge the conflict. But I didn?t think through this very carefully? 

Sorry I forgot ChronoSync replies only contains the updates, not the full sync state. Ignore my comment above.

Wentao

> 
>> 
>> 2/ Publish versioned meta-object under the name with initial marker (?00?) which encapsulates latest sync state object (or it?s name) so that newcomer is able to use exclusion filters and/or rightmost child selector to quickly "jump" to the latest sync state object.
>> As this meta-object needs to be re-generated every time sync state object is updated, it seems that there might be potential difficulties in cases of simultaneous data generation and recovering.
>> 
>> 3/ Use digests, where every newly generated digest comes after previous one in lexicographical order.
> 
> How do you guarantee lexical order using digests? They are just random numbers generated by the hash functions? 
> 
> Wentao
> 
>> That way, newcomers simply use RightMostChild selector for initial interest (instead of ?00? marker) to fetch latest available sync state. 
>> Didn?t do any research yet on whether this is possible in ChronoSync case (this seems relevant).
>> 
>> Please, let me know what you guys think on any of this. Any input will be appreciated.
>> Thanks, 
>> 
>> -- 
>> Peter Gusev
>> 
>> peter at remap.ucla.edu
>> +1 213 5872748
>> peetonn_ (skype)
>> 
>> Software Engineer/Programmer Analyst @ REMAP UCLA
>> 
>> Video streaming/ICN networks/Creative Development
>> 
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




From susmit at cs.colostate.edu  Mon Oct 24 14:22:07 2016
From: susmit at cs.colostate.edu (Susmit)
Date: Mon, 24 Oct 2016 15:22:07 -0600
Subject: [Ndn-interest] [Reminder] 3rd NDN Hackathon: Approaching proposal
 submission deadline
Message-ID: <CAM4XVkoBKpSX9NKMPpzMSW7cuC1K0t-a=TyxkhF57btjStSySw@mail.gmail.com>

[Apologies for cross-posting]

Hi All,

This is a gentle reminder that the deadline for NDN hackathon proposal
submission is on Oct 26th.

Please send your hackathon proposals to <3rd-ndn-hackathon at named-data.net>.

Proposal format and other details can be found here:
http://3rd-ndn-hackathon.named-data.net/cfh.html

The original call for proposal is here:
http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2016-September/001304.html

We look forward to your participation in the hackathon.

Thanks!


From Matteo.Bertolino at eurecom.fr  Tue Oct 25 07:53:13 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Tue, 25 Oct 2016 16:53:13 +0200
Subject: [Ndn-interest] Mininet: connection refused
Message-ID: <20161025165313.965m178rtw480g4g@webmail.eurecom.fr>

Good morning,
I've to run an NDN node on miniNDN, but this ndn node at a certain  
time should perform a network operation like an http connection, a  
wget, a ping etc.
I obtain two kind of error:
1- Connection refused (when I try to connect the special ndn node to  
an http server)
2- Network unreachable (for example, when I try a wget or to ping the  
other node).

Do you have a solution?
Thanks,
Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr



From agawande at memphis.edu  Tue Oct 25 08:09:26 2016
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Tue, 25 Oct 2016 15:09:26 +0000
Subject: [Ndn-interest] [Mini-NDN] Mininet: connection refused
In-Reply-To: <20161025165313.965m178rtw480g4g@webmail.eurecom.fr>
References: <20161025165313.965m178rtw480g4g@webmail.eurecom.fr>
Message-ID: <BN3PR04MB219672DA7FD31B40CB8D44E9D9A80@BN3PR04MB2196.namprd04.prod.outlook.com>

For reaching the Internet:

https://github.com/mininet/mininet/wiki/FAQ#NAT

You will have to experiment how to integrate NAT with Mini-NDN.


In Mini-NDN you can't ping non-neighbors because there is no routing.

Need to use route command to set it up.

https://redmine.named-data.net/issues/3054


Ashlesh

________________________________
From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu> on behalf of Matteo Bertolino <Matteo.Bertolino at eurecom.fr>
Sent: Tuesday, October 25, 2016 9:53:13 AM
To: mini-ndn at lists.cs.ucla.edu
Cc: ndn-interest at lists.cs.ucla.edu
Subject: [Mini-NDN] Mininet: connection refused

Good morning,
I've to run an NDN node on miniNDN, but this ndn node at a certain
time should perform a network operation like an http connection, a
wget, a ping etc.
I obtain two kind of error:
1- Connection refused (when I try to connect the special ndn node to
an http server)
2- Network unreachable (for example, when I try a wget or to ping the
other node).

Do you have a solution?
Thanks,
Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr

_______________________________________________
Mini-NDN mailing list
Mini-NDN at lists.cs.ucla.edu
http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161025/90e9dc33/attachment.html>

From lanwang at memphis.edu  Tue Oct 25 08:30:06 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Tue, 25 Oct 2016 15:30:06 +0000
Subject: [Ndn-interest] [Mini-NDN] Mininet: connection refused
In-Reply-To: <BN3PR04MB219672DA7FD31B40CB8D44E9D9A80@BN3PR04MB2196.namprd04.prod.outlook.com>
References: <20161025165313.965m178rtw480g4g@webmail.eurecom.fr>
	<BN3PR04MB219672DA7FD31B40CB8D44E9D9A80@BN3PR04MB2196.namprd04.prod.outlook.com>
Message-ID: <69C9B954-99A6-4806-85D8-8E90BFF1AD3F@memphis.edu>



On Oct 25, 2016, at 10:09 AM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:

For reaching the Internet:
https://github.com/mininet/mininet/wiki/FAQ#NAT
You will have to experiment how to integrate NAT with Mini-NDN.


In Mini-NDN you can't ping non-neighbors because there is no routing.

Just want to clarify that this is because *IP* routing is not running in Mini-NDN.  If you run some form of IP routing (eg RIP or OSPF) then you can ping non-neighbors.

We do run NLSR in Mini-NDN so you can do ndnping.

Need to use route command to set it up.
https://redmine.named-data.net/issues/3054

Ashlesh
________________________________
From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu<mailto:mini-ndn-bounces at lists.cs.ucla.edu>> on behalf of Matteo Bertolino <Matteo.Bertolino at eurecom.fr<mailto:Matteo.Bertolino at eurecom.fr>>
Sent: Tuesday, October 25, 2016 9:53:13 AM
To: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Cc: ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>
Subject: [Mini-NDN] Mininet: connection refused

Good morning,
I've to run an NDN node on miniNDN, but this ndn node at a certain
time should perform a network operation like an http connection, a
wget, a ping etc.
I obtain two kind of error:
1- Connection refused (when I try to connect the special ndn node to
an http server)
2- Network unreachable (for example, when I try a wget or to ping the
other node).

Do you have a solution?
Thanks,
Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr<http://webmail.eurecom.fr/>

_______________________________________________
Mini-NDN mailing list
Mini-NDN at lists.cs.ucla.edu<mailto:Mini-NDN at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn
_______________________________________________
Mini-NDN mailing list
Mini-NDN at lists.cs.ucla.edu<mailto:Mini-NDN at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161025/61142f71/attachment.html>

From Matteo.Bertolino at eurecom.fr  Tue Oct 25 09:33:32 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Tue, 25 Oct 2016 18:33:32 +0200
Subject: [Ndn-interest] [Mini-NDN] Mininet: connection refused
In-Reply-To: <69C9B954-99A6-4806-85D8-8E90BFF1AD3F@memphis.edu>
References: <20161025165313.965m178rtw480g4g@webmail.eurecom.fr>
	<BN3PR04MB219672DA7FD31B40CB8D44E9D9A80@BN3PR04MB2196.namprd04.prod.outlook.com>
	<69C9B954-99A6-4806-85D8-8E90BFF1AD3F@memphis.edu>
Message-ID: <20161025183332.f58x2on38k00kgos@webmail.eurecom.fr>

Dears,
thank you for the interest. I have still some questions unsolved.

1- The sentence:
> You will have to experiment how to integrate NAT with Mini-NDN.
Does it mean that this feature is not available now? I have no idea  
how to integrate miniNDN with nat. In mininet I see --nat option, but  
here it does not work.

2- However, also writing mn --nat , the command h1 ping google.fr fails.

3- The sentence:
> If you run some form of IP routing (eg RIP or OSPF) then you can  
> ping non-neighbors.
Can you explain me how can I perform it?

4- (Final): My purpose is putting a little http server in the ndn  
network. To do it,I am confused about what can I do.

Thank you,
Matteo

Quoting "Lan Wang (lanwang)" <lanwang at memphis.edu>:

>
>
> On Oct 25, 2016, at 10:09 AM, Ashlesh Gawande (agawande)   
> <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:
>
> For reaching the Internet:
> https://github.com/mininet/mininet/wiki/FAQ#NAT
> You will have to experiment how to integrate NAT with Mini-NDN.
>
>
> In Mini-NDN you can't ping non-neighbors because there is no routing.
>
> Just want to clarify that this is because *IP* routing is not   
> running in Mini-NDN.  If you run some form of IP routing (eg RIP or   
> OSPF) then you can ping non-neighbors.
>
> We do run NLSR in Mini-NDN so you can do ndnping.
>
> Need to use route command to set it up.
> https://redmine.named-data.net/issues/3054
>
> Ashlesh
> ________________________________
> From: Mini-NDN   
> <mini-ndn-bounces at lists.cs.ucla.edu<mailto:mini-ndn-bounces at lists.cs.ucla.edu>> on behalf of Matteo Bertolino   
> <Matteo.Bertolino at eurecom.fr<mailto:Matteo.Bertolino at eurecom.fr>>
> Sent: Tuesday, October 25, 2016 9:53:13 AM
> To: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
> Cc: ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>
> Subject: [Mini-NDN] Mininet: connection refused
>
> Good morning,
> I've to run an NDN node on miniNDN, but this ndn node at a certain
> time should perform a network operation like an http connection, a
> wget, a ping etc.
> I obtain two kind of error:
> 1- Connection refused (when I try to connect the special ndn node to
> an http server)
> 2- Network unreachable (for example, when I try a wget or to ping the
> other node).
>
> Do you have a solution?
> Thanks,
> Matteo
>
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail:   
> http://webmail.eurecom.fr<http://webmail.eurecom.fr/>
>
> _______________________________________________
> Mini-NDN mailing list
> Mini-NDN at lists.cs.ucla.edu<mailto:Mini-NDN at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn
> _______________________________________________
> Mini-NDN mailing list
> Mini-NDN at lists.cs.ucla.edu<mailto:Mini-NDN at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn
>
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From tailinchu at gmail.com  Tue Oct 25 16:48:15 2016
From: tailinchu at gmail.com (Tai-Lin Chu)
Date: Tue, 25 Oct 2016 16:48:15 -0700
Subject: [Ndn-interest] How do you collect NDN application metrics?
Message-ID: <CABf5LwDnf12dO4jN2j7Vz-7ML3iaFQzVTqdmRaFWX+CGD2AQCA@mail.gmail.com>

Hi,

I want to ask people who have running NDN applications about how you
collect/aggregate/visualize NDN applications logs and runtime metrics.

I recently have this issue to scale current logging infrastructure for
many NDN apps, so I would like to hear more ideas.

Thanks!


From neogeoss1 at gmail.com  Wed Oct 26 04:16:33 2016
From: neogeoss1 at gmail.com (Hwang In Chan)
Date: Wed, 26 Oct 2016 20:16:33 +0900
Subject: [Ndn-interest] Question on NACK
Message-ID: <CADU-sK=LVAPtqRxA7kmVqCTUBfnLQ3+9HF9xN0+QDVxB6qjegA@mail.gmail.com>

Dear NDN researchers,


I would like to ask you a question on NACK in NDNsim. When I run NDNsim, is
it possible for a producer to make NACK
to the consumer at any time?
My script file has a fixed producer and a consumer in the scenario, I think
it is impossible for a producer to make NACKs.

While I was running my simulation script with modified NDNSIM, it gets
stuck at NACK handling. I should have coded NACk handling for my customed
NDNSIM, but I did not do it because I thought NACK would be unneccesary for
my customed scenario and ndnSIM.
If NACK is made even in an average scenario and NDNsim, I would have to
make one for my own simulator.

If any of you have any idea on NACK, please reply me.

Lots of love,

inchan hwang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161026/0b553026/attachment.html>

From agawande at memphis.edu  Wed Oct 26 11:28:43 2016
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Wed, 26 Oct 2016 18:28:43 +0000
Subject: [Ndn-interest] [Mini-NDN] Mininet: connection refused
In-Reply-To: <20161025183332.f58x2on38k00kgos@webmail.eurecom.fr>
References: <20161025165313.965m178rtw480g4g@webmail.eurecom.fr>
	<BN3PR04MB219672DA7FD31B40CB8D44E9D9A80@BN3PR04MB2196.namprd04.prod.outlook.com>
	<69C9B954-99A6-4806-85D8-8E90BFF1AD3F@memphis.edu>,
	<20161025183332.f58x2on38k00kgos@webmail.eurecom.fr>
Message-ID: <BN3PR04MB219649A918E13A8F42012054D9AB0@BN3PR04MB2196.namprd04.prod.outlook.com>

The mn --nat option attaches the nat to s1 (See: s1 ifconfig)


If you try s1 ping google.com that should work.


If you want h1 to reach google, I think this will help:

https://techandtrains.com/2013/11/24/mininet-host-talking-to-internet/


Can also study the nat example:

https://github.com/mininet/mininet/blob/master/examples/natnet.py


For routes to reach non-neighbors I don't remember how to set it up but you can try to use "route" or "ip route" command to add static routes to non neighbors.

Can also look into switches: https://github.com/mininet/openflow-tutorial/wiki/Router-Exercise

(Mini-NDN conf parser does handle switches if you want to insert them, but I have not tested it).

You will have to experiment with this as I don't know the exact steps for the setup. I will try to find them.


Can you describe the topology, where do you want to put the Http server?


Ashlesh

________________________________
From: Matteo Bertolino <Matteo.Bertolino at eurecom.fr>
Sent: Tuesday, October 25, 2016 11:33:32 AM
To: Lan Wang (lanwang)
Cc: Ashlesh Gawande (agawande); mini-ndn at lists.cs.ucla.edu; ndn-interest at lists.cs.ucla.edu
Subject: Re: [Mini-NDN] Mininet: connection refused

Dears,
thank you for the interest. I have still some questions unsolved.

1- The sentence:
> You will have to experiment how to integrate NAT with Mini-NDN.
Does it mean that this feature is not available now? I have no idea
how to integrate miniNDN with nat. In mininet I see --nat option, but
here it does not work.

2- However, also writing mn --nat , the command h1 ping google.fr fails.

3- The sentence:
> If you run some form of IP routing (eg RIP or OSPF) then you can
> ping non-neighbors.
Can you explain me how can I perform it?

4- (Final): My purpose is putting a little http server in the ndn
network. To do it,I am confused about what can I do.

Thank you,
Matteo

Quoting "Lan Wang (lanwang)" <lanwang at memphis.edu>:

>
>
> On Oct 25, 2016, at 10:09 AM, Ashlesh Gawande (agawande)
> <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:
>
> For reaching the Internet:
> https://github.com/mininet/mininet/wiki/FAQ#NAT
> You will have to experiment how to integrate NAT with Mini-NDN.
>
>
> In Mini-NDN you can't ping non-neighbors because there is no routing.
>
> Just want to clarify that this is because *IP* routing is not
> running in Mini-NDN.  If you run some form of IP routing (eg RIP or
> OSPF) then you can ping non-neighbors.
>
> We do run NLSR in Mini-NDN so you can do ndnping.
>
> Need to use route command to set it up.
> https://redmine.named-data.net/issues/3054
>
> Ashlesh
> ________________________________
> From: Mini-NDN
> <mini-ndn-bounces at lists.cs.ucla.edu<mailto:mini-ndn-bounces at lists.cs.ucla.edu>> on behalf of Matteo Bertolino
> <Matteo.Bertolino at eurecom.fr<mailto:Matteo.Bertolino at eurecom.fr>>
> Sent: Tuesday, October 25, 2016 9:53:13 AM
> To: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
> Cc: ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>
> Subject: [Mini-NDN] Mininet: connection refused
>
> Good morning,
> I've to run an NDN node on miniNDN, but this ndn node at a certain
> time should perform a network operation like an http connection, a
> wget, a ping etc.
> I obtain two kind of error:
> 1- Connection refused (when I try to connect the special ndn node to
> an http server)
> 2- Network unreachable (for example, when I try a wget or to ping the
> other node).
>
> Do you have a solution?
> Thanks,
> Matteo
>
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail:
> http://webmail.eurecom.fr<http://webmail.eurecom.fr/>
>
> _______________________________________________
> Mini-NDN mailing list
> Mini-NDN at lists.cs.ucla.edu<mailto:Mini-NDN at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn
> _______________________________________________
> Mini-NDN mailing list
> Mini-NDN at lists.cs.ucla.edu<mailto:Mini-NDN at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn
>
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161026/d73f37be/attachment.html>

From mastorakis at CS.UCLA.EDU  Wed Oct 26 21:54:02 2016
From: mastorakis at CS.UCLA.EDU (Spyridon (Spyros) Mastorakis)
Date: Wed, 26 Oct 2016 21:54:02 -0700
Subject: [Ndn-interest] Question on NACK
In-Reply-To: <CADU-sK=LVAPtqRxA7kmVqCTUBfnLQ3+9HF9xN0+QDVxB6qjegA@mail.gmail.com>
References: <CADU-sK=LVAPtqRxA7kmVqCTUBfnLQ3+9HF9xN0+QDVxB6qjegA@mail.gmail.com>
Message-ID: <FCA30CB8-3370-496F-9C38-F5E8BF49E40F@cs.ucla.edu>

Hi,

the latest NFD releases generate and process network NACKs. The NFD version used by ndnSIM 2.1 does not provide network NACK generation and processing.

However, we will make a new ndnSIM release soon, where NFD will be able to generate and process NACKs.

Hope that this helps,

Spyridon (Spyros) Mastorakis
Personal Website: http://cs.ucla.edu/~mastorakis/ <http://cs.ucla.edu/~mastorakis/>
Internet Research Laboratory
Computer Science Department
UCLA


> On Oct 26, 2016, at 4:16 AM, Hwang In Chan <neogeoss1 at gmail.com> wrote:
> 
> Dear NDN researchers,
> 
> 
> I would like to ask you a question on NACK in NDNsim. When I run NDNsim, is it possible for a producer to make NACK
> to the consumer at any time?
> My script file has a fixed producer and a consumer in the scenario, I think it is impossible for a producer to make NACKs.
> 
> While I was running my simulation script with modified NDNSIM, it gets stuck at NACK handling. I should have coded NACk handling for my customed NDNSIM, but I did not do it because I thought NACK would be unneccesary for my customed scenario and ndnSIM. 
> If NACK is made even in an average scenario and NDNsim, I would have to make one for my own simulator.
> 
> If any of you have any idea on NACK, please reply me.
> 
> Lots of love,
> 
> inchan hwang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161026/f5d9bd38/attachment.html>

From shijunxiao at email.arizona.edu  Thu Oct 27 13:50:16 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 27 Oct 2016 13:50:16 -0700
Subject: [Ndn-interest] Question on NACK
In-Reply-To: <FCA30CB8-3370-496F-9C38-F5E8BF49E40F@cs.ucla.edu>
References: <CADU-sK=LVAPtqRxA7kmVqCTUBfnLQ3+9HF9xN0+QDVxB6qjegA@mail.gmail.com>
	<FCA30CB8-3370-496F-9C38-F5E8BF49E40F@cs.ucla.edu>
Message-ID: <F865986C-7C99-4BCC-AD78-8FA64E9D4695@email.arizona.edu>

Hi Spyros

The ?new ndnSIM release? has been advertised for more than a month now. Is there an estimated date of its release?
Also, is there any plan to release an ndnSIM version based on NFD 0.5.0?

Yours, Junxiao

> On Oct 26, 2016, at 9:54 PM, Spyridon (Spyros) Mastorakis <mastorakis at CS.UCLA.EDU> wrote:
> 
> However, we will make a new ndnSIM release soon, where NFD will be able to generate and process NACKs.




From mastorakis at CS.UCLA.EDU  Thu Oct 27 13:53:14 2016
From: mastorakis at CS.UCLA.EDU (Spyridon (Spyros) Mastorakis)
Date: Thu, 27 Oct 2016 13:53:14 -0700
Subject: [Ndn-interest] Question on NACK
In-Reply-To: <F865986C-7C99-4BCC-AD78-8FA64E9D4695@email.arizona.edu>
References: <CADU-sK=LVAPtqRxA7kmVqCTUBfnLQ3+9HF9xN0+QDVxB6qjegA@mail.gmail.com>
	<FCA30CB8-3370-496F-9C38-F5E8BF49E40F@cs.ucla.edu>
	<F865986C-7C99-4BCC-AD78-8FA64E9D4695@email.arizona.edu>
Message-ID: <F3C49196-527F-4856-9135-D95AB5EFF173@cs.ucla.edu>

Hi Junxiao,

adding Alex to the discussion, since he might have a more accurate estimation than I do.

Thanks,

Spyridon (Spyros) Mastorakis
Personal Website: http://cs.ucla.edu/~mastorakis/ <http://cs.ucla.edu/~mastorakis/>
Internet Research Laboratory
Computer Science Department
UCLA

> On Oct 27, 2016, at 1:50 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Spyros
> 
> The ?new ndnSIM release? has been advertised for more than a month now. Is there an estimated date of its release?
> Also, is there any plan to release an ndnSIM version based on NFD 0.5.0?
> 
> Yours, Junxiao
> 
>> On Oct 26, 2016, at 9:54 PM, Spyridon (Spyros) Mastorakis <mastorakis at CS.UCLA.EDU> wrote:
>> 
>> However, we will make a new ndnSIM release soon, where NFD will be able to generate and process NACKs.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161027/cd484c0d/attachment.html>

From mastorakis at CS.UCLA.EDU  Thu Oct 27 13:54:22 2016
From: mastorakis at CS.UCLA.EDU (Spyridon (Spyros) Mastorakis)
Date: Thu, 27 Oct 2016 13:54:22 -0700
Subject: [Ndn-interest] Question on NACK
In-Reply-To: <F3C49196-527F-4856-9135-D95AB5EFF173@cs.ucla.edu>
References: <CADU-sK=LVAPtqRxA7kmVqCTUBfnLQ3+9HF9xN0+QDVxB6qjegA@mail.gmail.com>
	<FCA30CB8-3370-496F-9C38-F5E8BF49E40F@cs.ucla.edu>
	<F865986C-7C99-4BCC-AD78-8FA64E9D4695@email.arizona.edu>
	<F3C49196-527F-4856-9135-D95AB5EFF173@cs.ucla.edu>
Message-ID: <CD850E4C-986E-4175-BB84-710D88E81BD6@cs.ucla.edu>

Adding Alex to the discussion for real now..

Spyridon (Spyros) Mastorakis
Personal Website: http://cs.ucla.edu/~mastorakis/ <http://cs.ucla.edu/~mastorakis/>
Internet Research Laboratory
Computer Science Department
UCLA

> On Oct 27, 2016, at 1:53 PM, Spyridon (Spyros) Mastorakis <mastorakis at CS.UCLA.EDU> wrote:
> 
> Hi Junxiao,
> 
> adding Alex to the discussion, since he might have a more accurate estimation than I do.
> 
> Thanks,
> 
> Spyridon (Spyros) Mastorakis
> Personal Website: http://cs.ucla.edu/~mastorakis/ <http://cs.ucla.edu/~mastorakis/>
> Internet Research Laboratory
> Computer Science Department
> UCLA
> 
>> On Oct 27, 2016, at 1:50 PM, Junxiao Shi <shijunxiao at email.arizona.edu <mailto:shijunxiao at email.arizona.edu>> wrote:
>> 
>> Hi Spyros
>> 
>> The ?new ndnSIM release? has been advertised for more than a month now. Is there an estimated date of its release?
>> Also, is there any plan to release an ndnSIM version based on NFD 0.5.0?
>> 
>> Yours, Junxiao
>> 
>>> On Oct 26, 2016, at 9:54 PM, Spyridon (Spyros) Mastorakis <mastorakis at CS.UCLA.EDU <mailto:mastorakis at cs.ucla.edu>> wrote:
>>> 
>>> However, we will make a new ndnSIM release soon, where NFD will be able to generate and process NACKs.
>> 
> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161027/f136a497/attachment.html>

From Matteo.Bertolino at eurecom.fr  Fri Oct 28 00:40:53 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Fri, 28 Oct 2016 09:40:53 +0200
Subject: [Ndn-interest] How to compile using both ndn-cxx and another library
Message-ID: <20161028094053.whf7s2i1vy8400w8@webmail.eurecom.fr>

Good morning to all,
I need to compile a program that uses ndn-cxx and a couple of function  
of another cpp (static) library that is cpp-netlib (no really matter  
which library, it is a general question actually).

Then, I have no idea how to do it. I am used to compile all the  
programs in ndn-cxx/example folder using sudo ndn-cxx/waf command.  
Absolutely no idea how to modify the script, or other alternatives.

Any suggestions? Thanks,

Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr



From shijunxiao at email.arizona.edu  Fri Oct 28 04:55:42 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 28 Oct 2016 04:55:42 -0700
Subject: [Ndn-interest] How to compile using both ndn-cxx and another
 library
In-Reply-To: <20161028094053.whf7s2i1vy8400w8@webmail.eurecom.fr>
References: <20161028094053.whf7s2i1vy8400w8@webmail.eurecom.fr>
Message-ID: <CAOFH+OYXcVEES=fewoXNp-7NHhDCVfQWZPy5+VLMiw2+OZtQFw@mail.gmail.com>

Hi Matteo

1. Move your programs out of ndn-cxx repository.
2. Install ndn-cxx normally.
3. g++ -o myapp myapp.cpp -std=c++11 $(pkg-config --cflags --libs
libndn-cxx) -lother-library

Yours, Junxiao

On Oct 28, 2016 00:41, "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
wrote:

> Good morning to all,
> I need to compile a program that uses ndn-cxx and a couple of function of
> another cpp (static) library that is cpp-netlib (no really matter which
> library, it is a general question actually).
>
> Then, I have no idea how to do it. I am used to compile all the programs
> in ndn-cxx/example folder using sudo ndn-cxx/waf command. Absolutely no
> idea how to modify the script, or other alternatives.
>
> Any suggestions? Thanks,
>
> Matteo
>
> ------------------------------------------------------------
> -------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161028/868cb7c0/attachment.html>

From Matteo.Bertolino at eurecom.fr  Fri Oct 28 05:56:06 2016
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Fri, 28 Oct 2016 14:56:06 +0200
Subject: [Ndn-interest] How to compile using both ndn-cxx and
	another	library
In-Reply-To: <CAOFH+OYXcVEES=fewoXNp-7NHhDCVfQWZPy5+VLMiw2+OZtQFw@mail.gmail.com>
References: <20161028094053.whf7s2i1vy8400w8@webmail.eurecom.fr>
	<CAOFH+OYXcVEES=fewoXNp-7NHhDCVfQWZPy5+VLMiw2+OZtQFw@mail.gmail.com>
Message-ID: <20161028145606.vp1dw7w528kgg4c4@webmail.eurecom.fr>

Dear Junxiao, thank you very much, again :)
Can I kindly ask you how to integrate the compilation string in an  
external Makefile?
Bests,
Matteo

Quoting Junxiao Shi <shijunxiao at email.arizona.edu>:

> Hi Matteo
>
> 1. Move your programs out of ndn-cxx repository.
> 2. Install ndn-cxx normally.
> 3. g++ -o myapp myapp.cpp -std=c++11 $(pkg-config --cflags --libs
> libndn-cxx) -lother-library
>
> Yours, Junxiao
>
> On Oct 28, 2016 00:41, "Matteo Bertolino" <Matteo.Bertolino at eurecom.fr>
> wrote:
>
>> Good morning to all,
>> I need to compile a program that uses ndn-cxx and a couple of function of
>> another cpp (static) library that is cpp-netlib (no really matter which
>> library, it is a general question actually).
>>
>> Then, I have no idea how to do it. I am used to compile all the programs
>> in ndn-cxx/example folder using sudo ndn-cxx/waf command. Absolutely no
>> idea how to modify the script, or other alternatives.
>>
>> Any suggestions? Thanks,
>>
>> Matteo
>>
>> ------------------------------------------------------------
>> -------------------
>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr




From bouacherine.abdelkader at gmail.com  Sat Oct 29 04:14:24 2016
From: bouacherine.abdelkader at gmail.com (Bouacherine Abdelkader)
Date: Sat, 29 Oct 2016 12:14:24 +0100
Subject: [Ndn-interest] ndnSIM based on NFD version 0.5.0
Message-ID: <CAGcUBiyvBKRMtA6yZAyPLKgijo2wJ04K5zaJq_YHtB-vLvrdiw@mail.gmail.com>

Hi every one,

I would like to know (due to the breaking changes in NFD), if there is a
planned new release of ndnSIM based on NFD and ndn-cxx version 0.5.0.

Kind regards,

Abdelkader Bouacherine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161029/4809b4f0/attachment.html>

From lixia at CS.UCLA.EDU  Sat Oct 29 09:16:39 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Sat, 29 Oct 2016 09:16:39 -0700
Subject: [Ndn-interest] ndnSIM based on NFD version 0.5.0
In-Reply-To: <CAGcUBiyvBKRMtA6yZAyPLKgijo2wJ04K5zaJq_YHtB-vLvrdiw@mail.gmail.com>
References: <CAGcUBiyvBKRMtA6yZAyPLKgijo2wJ04K5zaJq_YHtB-vLvrdiw@mail.gmail.com>
Message-ID: <8BC1E033-2B24-4994-84E7-BC190602F085@cs.ucla.edu>


> On Oct 29, 2016, at 4:14 AM, Bouacherine Abdelkader <bouacherine.abdelkader at gmail.com> wrote:
> 
> Hi every one,
> 
> I would like to know (due to the breaking changes in NFD), if there is a planned new release of ndnSIM based on NFD and ndn-cxx version 0.5.0.

yes it has been in planning for some time.
I hope/believe a new ndnSIM release would come out soon.

> 
> Kind regards,
> 
> Abdelkader Bouacherine
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




From shijunxiao at email.arizona.edu  Sat Oct 29 09:22:59 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sat, 29 Oct 2016 09:22:59 -0700
Subject: [Ndn-interest] ndnSIM based on NFD version 0.5.0
In-Reply-To: <8BC1E033-2B24-4994-84E7-BC190602F085@cs.ucla.edu>
References: <CAGcUBiyvBKRMtA6yZAyPLKgijo2wJ04K5zaJq_YHtB-vLvrdiw@mail.gmail.com>
	<8BC1E033-2B24-4994-84E7-BC190602F085@cs.ucla.edu>
Message-ID: <CAOFH+ObA8O-uWPTNpJBX3a3aYuPEd7o0eA6kJn4WmCYQnqfrpw@mail.gmail.com>

Hi Abdelkader

I saw ndnSIM 2.2 release notes in code review system https://gerrit.named-
data.net/3291 which means a release can be expected very soon (I guess
within 15 days).
But 2.2 release is based on NFD 0.4.1 rather than 0.5.0.

ndnSIM maintainers appear to favor backwards compatibility rather than
bringing in new features.
In particular, there's still no Nack in 2.2 because it would conflict with
"ns3 packet tag" which is used to keep track of hop counts. Sigh~

Yours, Junxiao

On Sat, Oct 29, 2016 at 9:16 AM, Lixia Zhang <lixia at cs.ucla.edu> wrote:

> > I would like to know (due to the breaking changes in NFD), if there is a
> planned new release of ndnSIM based on NFD and ndn-cxx version 0.5.0.
>
> yes it has been in planning for some time.
> I hope/believe a new ndnSIM release would come out soon.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161029/7bf3e80b/attachment.html>

From lixia at CS.UCLA.EDU  Sat Oct 29 09:41:55 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Sat, 29 Oct 2016 09:41:55 -0700
Subject: [Ndn-interest] ndnSIM based on NFD version 0.5.0
In-Reply-To: <CAOFH+ObA8O-uWPTNpJBX3a3aYuPEd7o0eA6kJn4WmCYQnqfrpw@mail.gmail.com>
References: <CAGcUBiyvBKRMtA6yZAyPLKgijo2wJ04K5zaJq_YHtB-vLvrdiw@mail.gmail.com>
	<8BC1E033-2B24-4994-84E7-BC190602F085@cs.ucla.edu>
	<CAOFH+ObA8O-uWPTNpJBX3a3aYuPEd7o0eA6kJn4WmCYQnqfrpw@mail.gmail.com>
Message-ID: <ECF6A2E2-F946-4231-8CE9-F1E6CA86F0B3@cs.ucla.edu>


> On Oct 29, 2016, at 9:22 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Abdelkader
> 
> I saw ndnSIM 2.2 release notes in code review system https://gerrit.named-data.net/3291 <https://gerrit.named-data.net/3291> which means a release can be expected very soon (I guess within 15 days).
> But 2.2 release is based on NFD 0.4.1 rather than 0.5.0.

Junxiao, I am talking the new release based on 0.5 (as it was discussed yesterday during an internal meeting)


> ndnSIM maintainers appear to favor backwards compatibility rather than bringing in new features.
> In particular, there's still no Nack in 2.2 because it would conflict with "ns3 packet tag" which is used to keep track of hop counts. 

Let me explain:
a) the NACK signal is carried in NDNLP; NACK handling is in NFD. 
b) due to the consideration of "ns3 packet tag" that's used for tracing, ndnSIM has not turned on NDNLP (I know that's what you had wanted to see, Junxiao).
c) turning on LP is trivial, the concern is the tradeoff. Yesterday during the meeting we considered soliciting community input to see what people prefer.

> 
> On Sat, Oct 29, 2016 at 9:16 AM, Lixia Zhang <lixia at cs.ucla.edu <mailto:lixia at cs.ucla.edu>> wrote:
> > I would like to know (due to the breaking changes in NFD), if there is a planned new release of ndnSIM based on NFD and ndn-cxx version 0.5.0.
> 
> yes it has been in planning for some time.
> I hope/believe a new ndnSIM release would come out soon.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161029/fff829cf/attachment.html>

From mastorakis at CS.UCLA.EDU  Sat Oct 29 12:16:37 2016
From: mastorakis at CS.UCLA.EDU (Spyridon (Spyros) Mastorakis)
Date: Sat, 29 Oct 2016 12:16:37 -0700
Subject: [Ndn-interest] ndnSIM based on NFD version 0.5.0
In-Reply-To: <ECF6A2E2-F946-4231-8CE9-F1E6CA86F0B3@cs.ucla.edu>
References: <CAGcUBiyvBKRMtA6yZAyPLKgijo2wJ04K5zaJq_YHtB-vLvrdiw@mail.gmail.com>
	<8BC1E033-2B24-4994-84E7-BC190602F085@cs.ucla.edu>
	<CAOFH+ObA8O-uWPTNpJBX3a3aYuPEd7o0eA6kJn4WmCYQnqfrpw@mail.gmail.com>
	<ECF6A2E2-F946-4231-8CE9-F1E6CA86F0B3@cs.ucla.edu>
Message-ID: <08C069A5-8A87-47CC-9322-403E803CE8EF@cs.ucla.edu>

To clarify things:

the upcoming release of ndnSIM (v2.2) will be based on NFD 0.4.1. Our initial goal for the release after ndnSIM 2.2 is to be based on NFD 0.5, however, we really hope that it might be based on the latest (at that time) version of NFD.

The reason that ndnSIM 2.2 will be based on NFD 0.4.1 and not 0.5 is that NFD 0.5 contains a lot of internal restructuring that is not clear to us how easy or hard would be to integrate with ndnSIM. ndnSIM is based on NS3 and the NS3 world has some certain restrictions and patterns that sometimes make the integration of NFD features really hard.

I wish we had more manpower to be able to keep up more actively.

Thank you,
Spyros

Spyridon (Spyros) Mastorakis
Personal Website: http://cs.ucla.edu/~mastorakis/ <http://cs.ucla.edu/~mastorakis/>
Internet Research Laboratory
Computer Science Department
UCLA


> On Oct 29, 2016, at 9:41 AM, Lixia Zhang <lixia at CS.UCLA.EDU> wrote:
> 
> 
>> On Oct 29, 2016, at 9:22 AM, Junxiao Shi <shijunxiao at email.arizona.edu <mailto:shijunxiao at email.arizona.edu>> wrote:
>> 
>> Hi Abdelkader
>> 
>> I saw ndnSIM 2.2 release notes in code review system https://gerrit.named-data.net/3291 <https://gerrit.named-data.net/3291> which means a release can be expected very soon (I guess within 15 days).
>> But 2.2 release is based on NFD 0.4.1 rather than 0.5.0.
> 
> Junxiao, I am talking the new release based on 0.5 (as it was discussed yesterday during an internal meeting)
> 
> 
>> ndnSIM maintainers appear to favor backwards compatibility rather than bringing in new features.
>> In particular, there's still no Nack in 2.2 because it would conflict with "ns3 packet tag" which is used to keep track of hop counts. 
> 
> Let me explain:
> a) the NACK signal is carried in NDNLP; NACK handling is in NFD. 
> b) due to the consideration of "ns3 packet tag" that's used for tracing, ndnSIM has not turned on NDNLP (I know that's what you had wanted to see, Junxiao).
> c) turning on LP is trivial, the concern is the tradeoff. Yesterday during the meeting we considered soliciting community input to see what people prefer.
> 
>> 
>> On Sat, Oct 29, 2016 at 9:16 AM, Lixia Zhang <lixia at cs.ucla.edu <mailto:lixia at cs.ucla.edu>> wrote:
>> > I would like to know (due to the breaking changes in NFD), if there is a planned new release of ndnSIM based on NFD and ndn-cxx version 0.5.0.
>> 
>> yes it has been in planning for some time.
>> I hope/believe a new ndnSIM release would come out soon.
> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161029/4f304020/attachment.html>

From bouacherine.abdelkader at gmail.com  Sat Oct 29 13:11:04 2016
From: bouacherine.abdelkader at gmail.com (Bouacherine Abdelkader)
Date: Sat, 29 Oct 2016 21:11:04 +0100
Subject: [Ndn-interest] ndnSIM based on NFD version 0.5.0
In-Reply-To: <08C069A5-8A87-47CC-9322-403E803CE8EF@cs.ucla.edu>
References: <CAGcUBiyvBKRMtA6yZAyPLKgijo2wJ04K5zaJq_YHtB-vLvrdiw@mail.gmail.com>
	<8BC1E033-2B24-4994-84E7-BC190602F085@cs.ucla.edu>
	<CAOFH+ObA8O-uWPTNpJBX3a3aYuPEd7o0eA6kJn4WmCYQnqfrpw@mail.gmail.com>
	<ECF6A2E2-F946-4231-8CE9-F1E6CA86F0B3@cs.ucla.edu>
	<08C069A5-8A87-47CC-9322-403E803CE8EF@cs.ucla.edu>
Message-ID: <CAGcUBixDfcpJ0Z=bNB-pdXLpHj0o77+tXy=sd73H+hSx2gTfUw@mail.gmail.com>

Hi all,

Thanks to all the NDN team, you done and you are doing a wonderful work.
Knowing that the integration of NFD with ndnSIM is time consuming, I think
that whatever the benefit from migrating to NFD 0.4.1, it will be little
comparing the transition to NFD 0.5.0, unless it is Thanks to all the NDN
team, you done and you are doing a wonderful work. Knowing that the
integration of NFD with ndnSIM is time consuming, I think that whatever the
benefit from migrating to NFD 0.4.1, it will be little comparing the
transition to NFD 0.5.0, unless it is about to be ready. That was the
reason behind the question about migrating to NFD version 0.5.


Kind regards,


Abdelkader BOUACHERINE

Dept. of Computer Science,

Ecole Militaire Polytechnique, Algiers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161029/e8faefea/attachment.html>

From kchen at siu.edu  Sun Oct 16 18:51:21 2016
From: kchen at siu.edu (Kang Chen)
Date: Mon, 17 Oct 2016 01:51:21 -0000
Subject: [Ndn-interest] ICCCN 2017 Call for Workshop Proposal
Message-ID: <BLUPR0701MB2081DA29C41EEEB6ABD49796A4D00@BLUPR0701MB2081.namprd07.prod.outlook.com>



Call for Workshop Proposals

The 26th International Conference on Computer

Communication and Networks (ICCCN 2017)

Marriott Vancouver Pinnacle Downtown

July 31-August 3, 2017, Vancouver, Canada

http://www.icccn.org/icccn16



The 26th International Conference on Computer Communications and Networks (ICCCN) will be held in Vancouver, Canada, July 31-August 3, 2017. ICCCN workshops are exciting forums to present, discuss, and formulate specialized topics and emerging hot research topics (new areas, new problems or new methods). The topic of the proposed workshop should offer a perspective distinct from and complementary to the research themes of the main conference. Workshops for presenting papers from industry and papers on design and implementations of systems and services are welcome. As the ICCCN is a premier international conference in the field, a workshop at the conference will generate high visibility. Accepted and registered (and presented by one of authors) workshop papers will be published and included in the conference proceedings.



Scope: The topics we are soliciting include, but are NOT limited to:

* Internet of Things

* Critical Infrastructure Networks

* Smart Grid Networks and Smart Communities

* Security and Privacy in communications, networks, and testbeds

* Software Defined Networks

* Cyber Physical Systems

* Mobile Cloud Computing and Services

* Green communications and energy-harvesting networks

* Cognitive Networking and Communications

* Next Generation Broadband Wireless Access Networks

* Virtualized Infrastructure Systems and Architectures

* Networking of Mobile Handheld Devices, Social Networking, and Novel Applications



Submission Guidelines and Publication: In general, a workshop takes one day with 12-16 accepted and registered papers and presentations. Please send a workshop proposal by November 2nd, 2016, toWorkshop General Chairs Prof. Abhishek Parakh <aparakh at unomaha.edu<mailto:aparakh at unomaha.edu>> and Prof. Song Fu <song.fu at unt.edu<mailto:song.fu at unt.edu>>. Please note that the proposals will be reviewed once received and we will try to make the decision and send the notification back as soon as possible. Early-bird proposals are highly encouraged and will be given higher priority! For each approved workshop, at least one organizer must commit to attending and running the workshop on site. Please do not hesitate to send emails to the Chairs if you have any questions.



The workshop proposal should include the following information: (1) workshop title; (2) the names of the organizers, their brief bios and contact information; (3) a description of why and how the workshop will be organized (half to one page) e.g., relevance and significance of the workshop to the main conference; (4) a history of the workshop, if not being offered for the first time; (5) estimated paper submission volume and paper acceptance rate; (6) expected attendance; (7) length - Full day or half day; (8) indication if a journal special issue is associated with; (9) any other relevant information.


Each workshop will start to advertise and distribute its Call-For-Paper after receiving the approval notification. Papers submitted to each workshop should be original and peer reviewed by its program committee. An accepted paper must be registered and presented at the conference/workshop venue and must be limited to 6 pages in standard double-column, 10pt font format. If authors are willing to pay an over-length fee of $100/page, 2 additional pages are allowed for their submission. More updates will be posted on the ICCCN 2017 website and please refer to the Author Information at the website. Please contact the Workshop Chairs with any questions.


Best wishes,
Kang Chen



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20161017/b7ac091c/attachment.html>