From nfd-call-notification at mail1.yoursunny.com  Tue Dec  1 07:00:02 2015
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 1 Dec 2015 08:00:02 -0700
Subject: [Nfd-dev] NFD call 20151201
Message-ID: <201512011500.tB1F02p4018537@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151201/23817971/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Thu Dec  3 07:00:04 2015
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 3 Dec 2015 08:00:04 -0700
Subject: [Nfd-dev] NFD call 20151203
Message-ID: <201512031500.tB3F047q011420@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151203/220a0468/attachment.html>

From shijunxiao at email.arizona.edu  Thu Dec  3 12:13:41 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 3 Dec 2015 13:13:41 -0700
Subject: [Nfd-dev] ndn-cxx feature deprecation: LocalControlHeader
Message-ID: <CAOFH+OYPL0zq+_iHFfvd-7v+zq3iqWvLAq3e5XR3KwDkOHKV7Q@mail.gmail.com>

Dear folks

The following items are deprecated in ndn-cxx:

   - LocalControlHeader type
   - Interest::get/setLocalControlHeader
   - Interest::get/setIncomingFaceId
   - Interest::get/setNextHopFaceId
   - Data::get/setLocalControlHeader
   - Data::get/setIncomingFaceId
   - Data::get/setCachingPolicy

If you have code that uses any of those features, please migrate to the new
syntax as described in Doxygen.

The Change is http://gerrit.named-data.net/2589 and it will be merged soon.
The Change is backwards-compatible, but old syntax is being marked
DEPRECATED which would trigger a compiler warning.
Those deprecated items will be deleted in v0.5.

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

From nfd-call-notification at mail1.yoursunny.com  Tue Dec  8 07:00:02 2015
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 8 Dec 2015 08:00:02 -0700
Subject: [Nfd-dev] NFD call 20151208
Message-ID: <201512081500.tB8F02q5013244@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151208/9d1352f1/attachment.html>

From shijunxiao at email.arizona.edu  Wed Dec  9 10:49:38 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 9 Dec 2015 11:49:38 -0700
Subject: [Nfd-dev] Fwd: Request for assigned ContentType for "FLIC manifest"
In-Reply-To: <alpine.OSX.2.20.1512031101320.12988@huvi.local>
References: <alpine.OSX.2.20.1512031101320.12988@huvi.local>
Message-ID: <CAOFH+OZ=P4Cq4HgULwcOkhia_8jakv98nvG1nKiwyCYTqurj0g@mail.gmail.com>

---------- Forwarded message ----------
From: <christian.tschudin at unibas.ch>
Date: Dec 9, 2015 11:37
Subject: Request for assigned ContentType for "FLIC manifest"
To: <shijunxiao at email.arizona.edu>
Cc: <bzhang at arizona.edu>

Hi Junxiao,

could you please allocate a "ContentType" that I can use for the manifests
I have implemented?

The manifest format is called FLIC and is described in
https://github.com/tschudin/icn-flic-rfc/blob/master/draft-tschudin-icnrg-flic-00.txt

Here is a prototypical packet layout (assuming that the ContentType number
would be 0xC0):

   (Data/0x6
     (Name/0x7 ...)
     (MetaInfo/0x14
       (ContentType/0x18 0xC0)
     )
     (Content/0x15
       (HashGroup/0xC1
         (MetaData/0xC4
           (LocatorNm/0xC5 (NameComp/0x8 ...))
           (BlockSize/0xC7 INT)
           (TotalSize/0xC8 INT)
           (TotalHash/0xC9 OCTET[32])
         )
         (DataPtr/0xC2 OCTET[32])
         (MfstPtr/0xC3 OCTET[32])
       )
     )
     (SignatureInfo/0x16 ...)
     (SignatureValue/0x17 ...)
   )

An annex question is which type numbers I should use for the
"content-internal TLVs", marked 0xC1 etc (because of NDN's global type
policy). Should I also register them with you?

I will report back on experiments regarding FLIC transport over the NDN
testbed.

Thanks! And best regards,
christian

---
Prof. Dr. Christian F. Tschudin | Uni Basel | Dept of Mathematics and
Computer Science | Computer Networks Group | cn.cs.unibas.ch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151209/523d464d/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Thu Dec 10 07:00:02 2015
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 10 Dec 2015 08:00:02 -0700
Subject: [Nfd-dev] NFD call 20151210
Message-ID: <201512101500.tBAF02bM004589@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151210/d3885071/attachment.html>

From shijunxiao at email.arizona.EDU  Thu Dec 10 13:15:25 2015
From: shijunxiao at email.arizona.EDU (Junxiao Shi)
Date: Thu, 10 Dec 2015 14:15:25 -0700
Subject: [Nfd-dev] Request for assigned ContentType for "FLIC manifest"
In-Reply-To: <alpine.OSX.2.20.1512031101320.12988@huvi.local>
References: <alpine.OSX.2.20.1512031101320.12988@huvi.local>
Message-ID: <CAOFH+OYoNjikptEvvRH5f2gdWqJ05q7422k-h2AMy0mQB7KsNA@mail.gmail.com>

Hi Christian

20151210 conference call establishes guidelines for ContentType assignments.

   - 0~4 are already assigned.
   - 5~1023 are reserved for future usage.
   - 9000~9999 are reserved for private experiments and can never be
   assigned.


*FLIC is assigned ContentType 1024*.

Yours, Junxiao

On Wed, Dec 9, 2015 at 11:36 AM, <christian.tschudin at unibas.ch> wrote:

> Hi Junxiao,
>
> could you please allocate a "ContentType" that I can use for the manifests
> I have implemented?
>
> The manifest format is called FLIC and is described in
>
> https://github.com/tschudin/icn-flic-rfc/blob/master/draft-tschudin-icnrg-flic-00.txt
>
> Here is a prototypical packet layout (assuming that the ContentType number
> would be 0xC0):
>
>    (Data/0x6
>      (Name/0x7 ...)
>      (MetaInfo/0x14
>        (ContentType/0x18 0xC0)
>      )
>      (Content/0x15
>        (HashGroup/0xC1
>          (MetaData/0xC4
>            (LocatorNm/0xC5 (NameComp/0x8 ...))
>            (BlockSize/0xC7 INT)
>            (TotalSize/0xC8 INT)
>            (TotalHash/0xC9 OCTET[32])
>          )
>          (DataPtr/0xC2 OCTET[32])
>          (MfstPtr/0xC3 OCTET[32])
>        )
>      )
>      (SignatureInfo/0x16 ...)
>      (SignatureValue/0x17 ...)
>    )
>
> An annex question is which type numbers I should use for the
> "content-internal TLVs", marked 0xC1 etc (because of NDN's global type
> policy). Should I also register them with you?
>
> I will report back on experiments regarding FLIC transport over the NDN
> testbed.
>
> Thanks! And best regards,
> christian
>
> ---
> Prof. Dr. Christian F. Tschudin | Uni Basel | Dept of Mathematics and
> Computer Science | Computer Networks Group | cn.cs.unibas.ch
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151210/8b1f8ad0/attachment.html>

From lixia at CS.UCLA.EDU  Thu Dec 10 14:02:40 2015
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Thu, 10 Dec 2015 14:02:40 -0800
Subject: [Nfd-dev] Request for assigned ContentType for "FLIC manifest"
In-Reply-To: <CAOFH+OYoNjikptEvvRH5f2gdWqJ05q7422k-h2AMy0mQB7KsNA@mail.gmail.com>
References: <alpine.OSX.2.20.1512031101320.12988@huvi.local>
	<CAOFH+OYoNjikptEvvRH5f2gdWqJ05q7422k-h2AMy0mQB7KsNA@mail.gmail.com>
Message-ID: <6F0F4D2E-CD01-4226-AF61-8B328A067E60@cs.ucla.edu>


> On Dec 10, 2015, at 1:15 PM, Junxiao Shi <shijunxiao at email.arizona.EDU <mailto:shijunxiao at email.arizona.EDU>> wrote:
> 
> Hi Christian
> 
> 20151210 conference call establishes guidelines for ContentType assignments.
> 0~4 are already assigned.
> 5~1023 are reserved for future usage.
> 9000~9999 are reserved for private experiments and can never be assigned.
> 
> FLIC is assigned ContentType 1024.
> 
> Yours, Junxiao

Christian got his number to use, yes.

But this whole topic just *being discussed* 
The final decision and justification for the decision will be posted once we get there.  A webpage is being built on content type listing and registrations.

> 
> On Wed, Dec 9, 2015 at 11:36 AM, <christian.tschudin at unibas.ch <mailto:christian.tschudin at unibas.ch>> wrote:
> Hi Junxiao,
> 
> could you please allocate a "ContentType" that I can use for the manifests I have implemented?
> 
> The manifest format is called FLIC and is described in
> https://github.com/tschudin/icn-flic-rfc/blob/master/draft-tschudin-icnrg-flic-00.txt <https://github.com/tschudin/icn-flic-rfc/blob/master/draft-tschudin-icnrg-flic-00.txt>
> 
> Here is a prototypical packet layout (assuming that the ContentType number would be 0xC0):
> 
>    (Data/0x6
>      (Name/0x7 ...)
>      (MetaInfo/0x14
>        (ContentType/0x18 0xC0)
>      )
>      (Content/0x15
>        (HashGroup/0xC1
>          (MetaData/0xC4
>            (LocatorNm/0xC5 (NameComp/0x8 ...))
>            (BlockSize/0xC7 INT)
>            (TotalSize/0xC8 INT)
>            (TotalHash/0xC9 OCTET[32])
>          )
>          (DataPtr/0xC2 OCTET[32])
>          (MfstPtr/0xC3 OCTET[32])
>        )
>      )
>      (SignatureInfo/0x16 ...)
>      (SignatureValue/0x17 ...)
>    )
> 
> An annex question is which type numbers I should use for the "content-internal TLVs", marked 0xC1 etc (because of NDN's global type policy). Should I also register them with you?
> 
> I will report back on experiments regarding FLIC transport over the NDN testbed.
> 
> Thanks! And best regards,
> christian
> 
> ---
> Prof. Dr. Christian F. Tschudin | Uni Basel | Dept of Mathematics and
> Computer Science | Computer Networks Group | cn.cs.unibas.ch <http://cn.cs.unibas.ch/>
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

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

From christian.tschudin at unibas.ch  Fri Dec 11 16:12:07 2015
From: christian.tschudin at unibas.ch (christian.tschudin at unibas.ch)
Date: Fri, 11 Dec 2015 16:12:07 -0800 (PST)
Subject: [Nfd-dev] problem with selector for implicit digest?
Message-ID: <alpine.OSX.2.20.1512102005540.83047@huvi.attlocal.net>

I'm hitting a wall with nfd behavior when it comes to the implicit digest.

a) What is working correctly:
- first retrieve a packet by ordinary name
- compute the digest of the received packet
- then retrieve the same packet, but this time with the
   special digest component appended and MaxSuffix=0
- this works, the data will probably now be served from the CS
(digest is a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d)

b) What is not working:
- directly retrieve another packet with its (other) name and including
   the special digest component for that data, and MaxSuffix=0
- nfd accepts this request and forwards it upstream
- nfd receives that data packet
- but the received data is not delivered to the downstream
   client (timeout of ndnpeek although I can see that nfd
   received the right packet).
(digest is 65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623)

The content comes in both cases from an upstream node (running 
ccn-lite), see the topology below.

One potential catch is that the two names are almost identical:

The name in step a) is
/ndn/ch/unibas/repo256/movie7.mp4/_

The name in step b) is
/ndn/ch/unibas/repo256/movie7.mp4

Is this a bug in PIT matching? Or has the second data object an internal 
problem that lets nfd refuse it (see the attached packet)? Below I also 
add the command line logs, FYI.

Best, christian

---

# topology

   ndnpeek --> nfd (UDP 6363) --> ccn-lite-relay (UDP 3636) --> ccn-lite-repo256 (UDP 7777)


# case a), showing correct behavior

tschudin at cs-ndn-testbed1:~$ ndnpeek -v /ndn/ch/unibas/repo256/movie7.mp4/_ >pkt-1.bin
INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/_
DATA, RTT: 5ms

tschudin at cs-ndn-testbed1:~$ shasum -a 256 pkt-1.bin
a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d  pkt-1.bin

tschudin at cs-ndn-testbed1:~$ ndnpeek -v /ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d 
>pkt-2.bin
INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d
DATA, RTT: 5ms

tschudin at cs-ndn-testbed1:~$ cmp pkt-1.bin pkt-2.bin

tschudin at cs-ndn-testbed1:~$


# case b), showing the error

tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0 /ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb2adf74a4572b100c5f12885 >pkt-3.bin
INTEREST: /ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb2adf74a4572b100c5f12885?ndn.MaxSuffixComponents=0
TIMEOUT

tschudin at cs-ndn-testbed1:~$


# Log file captured with tcpdump (case b)

tschudin at cs-ndn-testbed1:~$ sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or udp port 7777' >traffic.log &
[2] 20530
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes

tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0 /ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623 >pkt-3.bin
INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623?ndn.MaxSuffixComponents=0
TIMEOUT

tschudin at cs-ndn-testbed1:~$ fg
sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or udp port 7777' > traffic.log
^C6 packets captured
12 packets received by filter
0 packets dropped by kernel

tschudin at cs-ndn-testbed1:~$ less traffic.log
00:47:08.269244 IP cs-ndn-testbed1.cs.unibas.ch.6363 > cs-ndn-testbed1.cs.unibas.ch.3636: UDP, length 87
00:47:08.270061 IP localhost.3636 > localhost.6363: UDP, length 87
00:47:08.270181 IP localhost.6363 > localhost.3636: UDP, length 100
00:47:08.270362 IP localhost.3636 > localhost.7777: UDP, length 87
00:47:08.271063 IP localhost.7777 > localhost.3636: UDP, length 3862
00:47:08.271227 IP cs-ndn-testbed1.cs.unibas.ch.3636 > cs-ndn-testbed1.cs.unibas.ch.6363: UDP, length 3862

traffic.log (END)


# log from the ccn-lite relay (which links to the upstream repo256, both running
# on the same machine as nfd but using UDP ports 3636 and 7777, respectively)

[D] 100.1443: ccnl_core_RX ifndx=0, 87 bytes
[D] 100.1443:   face 9, peer=192.43.193.111/6363
[I] 100.1444:   incoming interest=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013 from=192.43.193.111/6363
[D] 100.1444:   searching in CS
[D] 100.1446:   created new interest entry 0x1364f70 (prefix=/ndn/ch/unibas/repo256/movie7.mp4)
[D] 100.1446: ccnl_interest_propagate
[D] 100.1447:   ccnl_interest_propagate, fwd==0x13650d0
[I] 100.1447:   outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4> to=127.0.0.1/6363
[D] 100.1449: udp sendto(87 Bytes) to 127.0.0.1/6363 returned 87/0
[D] 100.1450:   ccnl_interest_propagate, fwd==0x100e1f0
[I] 100.1450:   outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4> to=127.0.0.1/7777
[D] 100.1450: udp sendto(87 Bytes) to 127.0.0.1/7777 returned 87/0
[D] 100.1450: ccnl_core_RX ifndx=0, 100 bytes
[D] 100.1451:   face 2, peer=127.0.0.1/6363
[I] 100.1457:   ndnlp packet
[D] 100.1458: ccnl_core_RX ifndx=0, 3862 bytes
[D] 100.1458:   face 6, peer=127.0.0.1/7777
[I] 100.1458:   incoming data=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013 from=127.0.0.1/7777
[I] 100.1458:   outgoing data=</ndn/ch/unibas/repo256/movie7.mp4>ndn2013 to=192.43.193.111/6363
[D] 100.1460: udp sendto(3862 Bytes) to 192.43.193.111/6363 returned 3862/0
[D] 100.1460:   adding content to cache

---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623.bin
Type: application/macbinary
Size: 3862 bytes
Desc: 
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151211/ca8c9a31/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d.bin
Type: application/macbinary
Size: 3725 bytes
Desc: 
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151211/ca8c9a31/attachment-0001.bin>

From jefft0 at remap.ucla.edu  Sat Dec 12 07:14:24 2015
From: jefft0 at remap.ucla.edu (Thompson, Jeff)
Date: Sat, 12 Dec 2015 15:14:24 +0000
Subject: [Nfd-dev] problem with selector for implicit digest?
In-Reply-To: <alpine.OSX.2.20.1512102005540.83047@huvi.attlocal.net>
References: <alpine.OSX.2.20.1512102005540.83047@huvi.attlocal.net>
Message-ID: <D29176FA.2F4D1%jefft0@remap.ucla.edu>

I tested in PyNDN and I confirm the same problem: NFD does not match an incoming data packet with an interest in the PIT which has an implicit digest component (but it does match from the content store).

Looking at the NFD code, Pit::findAllDataMatches calls m_nameTree.findAllMatches(data.getName(), ?) which does a longest prefix match of the data name to the interest name.
https://github.com/named-data/NFD/blob/5e5e44518286e89a0092ea0ad93c22e64128bdd2/daemon/table/pit.cpp#L97

But the interest name with the implicit digest component in the PIT is longer than the data name, so how can LPM match it? Should NFD strip the implicit digest component before putting the interest name in the PIT?s name tree?

- Jeff T

On 2015/12/11, 16:12:07, "Nfd-dev on behalf of christian.tschudin at unibas.ch<mailto:christian.tschudin at unibas.ch>" <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu> on behalf of christian.tschudin at unibas.ch<mailto:christian.tschudin at unibas.ch>> wrote:

I'm hitting a wall with nfd behavior when it comes to the implicit digest.

a) What is working correctly:
- first retrieve a packet by ordinary name
- compute the digest of the received packet
- then retrieve the same packet, but this time with the
   special digest component appended and MaxSuffix=0
- this works, the data will probably now be served from the CS
(digest is a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d)

b) What is not working:
- directly retrieve another packet with its (other) name and including
   the special digest component for that data, and MaxSuffix=0
- nfd accepts this request and forwards it upstream
- nfd receives that data packet
- but the received data is not delivered to the downstream
   client (timeout of ndnpeek although I can see that nfd
   received the right packet).
(digest is 65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623)

The content comes in both cases from an upstream node (running
ccn-lite), see the topology below.

One potential catch is that the two names are almost identical:

The name in step a) is
/ndn/ch/unibas/repo256/movie7.mp4/_

The name in step b) is
/ndn/ch/unibas/repo256/movie7.mp4

Is this a bug in PIT matching? Or has the second data object an internal
problem that lets nfd refuse it (see the attached packet)? Below I also
add the command line logs, FYI.

Best, christian

---

# topology

   ndnpeek --> nfd (UDP 6363) --> ccn-lite-relay (UDP 3636) --> ccn-lite-repo256 (UDP 7777)


# case a), showing correct behavior

tschudin at cs-ndn-testbed1:~$ ndnpeek -v /ndn/ch/unibas/repo256/movie7.mp4/_ >pkt-1.bin
INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/_
DATA, RTT: 5ms

tschudin at cs-ndn-testbed1:~$ shasum -a 256 pkt-1.bin
a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d  pkt-1.bin

tschudin at cs-ndn-testbed1:~$ ndnpeek -v /ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d
pkt-2.bin
INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d
DATA, RTT: 5ms

tschudin at cs-ndn-testbed1:~$ cmp pkt-1.bin pkt-2.bin

tschudin at cs-ndn-testbed1:~$


# case b), showing the error

tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0 /ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb2adf74a4572b100c5f12885 >pkt-3.bin
INTEREST: /ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb2adf74a4572b100c5f12885?ndn.MaxSuffixComponents=0
TIMEOUT

tschudin at cs-ndn-testbed1:~$


# Log file captured with tcpdump (case b)

tschudin at cs-ndn-testbed1:~$ sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or udp port 7777' >traffic.log &
[2] 20530
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes

tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0 /ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623 >pkt-3.bin
INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623?ndn.MaxSuffixComponents=0
TIMEOUT

tschudin at cs-ndn-testbed1:~$ fg
sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or udp port 7777' > traffic.log
^C6 packets captured
12 packets received by filter
0 packets dropped by kernel

tschudin at cs-ndn-testbed1:~$ less traffic.log
00:47:08.269244 IP cs-ndn-testbed1.cs.unibas.ch.6363 > cs-ndn-testbed1.cs.unibas.ch.3636: UDP, length 87
00:47:08.270061 IP localhost.3636 > localhost.6363: UDP, length 87
00:47:08.270181 IP localhost.6363 > localhost.3636: UDP, length 100
00:47:08.270362 IP localhost.3636 > localhost.7777: UDP, length 87
00:47:08.271063 IP localhost.7777 > localhost.3636: UDP, length 3862
00:47:08.271227 IP cs-ndn-testbed1.cs.unibas.ch.3636 > cs-ndn-testbed1.cs.unibas.ch.6363: UDP, length 3862

traffic.log (END)


# log from the ccn-lite relay (which links to the upstream repo256, both running
# on the same machine as nfd but using UDP ports 3636 and 7777, respectively)

[D] 100.1443: ccnl_core_RX ifndx=0, 87 bytes
[D] 100.1443:   face 9, peer=192.43.193.111/6363
[I] 100.1444:   incoming interest=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013 from=192.43.193.111/6363
[D] 100.1444:   searching in CS
[D] 100.1446:   created new interest entry 0x1364f70 (prefix=/ndn/ch/unibas/repo256/movie7.mp4)
[D] 100.1446: ccnl_interest_propagate
[D] 100.1447:   ccnl_interest_propagate, fwd==0x13650d0
[I] 100.1447:   outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4> to=127.0.0.1/6363
[D] 100.1449: udp sendto(87 Bytes) to 127.0.0.1/6363 returned 87/0
[D] 100.1450:   ccnl_interest_propagate, fwd==0x100e1f0
[I] 100.1450:   outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4> to=127.0.0.1/7777
[D] 100.1450: udp sendto(87 Bytes) to 127.0.0.1/7777 returned 87/0
[D] 100.1450: ccnl_core_RX ifndx=0, 100 bytes
[D] 100.1451:   face 2, peer=127.0.0.1/6363
[I] 100.1457:   ndnlp packet
[D] 100.1458: ccnl_core_RX ifndx=0, 3862 bytes
[D] 100.1458:   face 6, peer=127.0.0.1/7777
[I] 100.1458:   incoming data=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013 from=127.0.0.1/7777
[I] 100.1458:   outgoing data=</ndn/ch/unibas/repo256/movie7.mp4>ndn2013 to=192.43.193.111/6363
[D] 100.1460: udp sendto(3862 Bytes) to 192.43.193.111/6363 returned 3862/0
[D] 100.1460:   adding content to cache

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

From christian.tschudin at unibas.ch  Sat Dec 12 09:10:58 2015
From: christian.tschudin at unibas.ch (christian.tschudin at unibas.ch)
Date: Sat, 12 Dec 2015 09:10:58 -0800 (PST)
Subject: [Nfd-dev] problem with selector for implicit digest?
In-Reply-To: <D29176FA.2F4D1%jefft0@remap.ucla.edu>
References: <alpine.OSX.2.20.1512102005540.83047@huvi.attlocal.net>
	<D29176FA.2F4D1%jefft0@remap.ucla.edu>
Message-ID: <alpine.OSX.2.20.1512120856400.4503@huvi.attlocal.net>

Jeff, thanks for this insight.

This seems to indicate that so far digest-based lookup was not used by 
anyone, and therefore now would be a good moment to revisit that part of 
the mechanics?

Since the beginning of ccn-lite I thought that the handling of the 
implicit digest was not elegant and will lead to implementation 
accidents. Conceptually it is a selector and should be handled there, 
instead of a name component.

One could even go a step further and reserve a special field for it in 
the interest (instead of inside the selector block) because it is a 
knock-out restriction: Any selector then becomes irrelevant.

Thoughts?

best, c


On Sat, 12 Dec 2015, Thompson, Jeff wrote:

> I tested in PyNDN and I confirm the same problem: NFD does not match an incoming data
> packet with an interest in the PIT which has an implicit digest component (but it does
> match from the content store).
> 
> Looking at the NFD code,?Pit::findAllDataMatches calls
> m_nameTree.findAllMatches(data.getName(), ?) which does a longest prefix match of the
> data name to the interest name.
> https://github.com/named-data/NFD/blob/5e5e44518286e89a0092ea0ad93c22e64128bdd2/daemon/t
> able/pit.cpp#L97
> 
> But the interest name with the implicit digest component in the PIT is longer than the
> data name, so how can LPM match it? Should NFD strip the implicit digest component before
> putting the interest name in the PIT?s name tree?
> 
> - Jeff T
> 
> On 2015/12/11, 16:12:07, "Nfd-dev on behalf of christian.tschudin at unibas.ch"
> <nfd-dev-bounces at lists.cs.ucla.edu on behalf of christian.tschudin at unibas.ch> wrote:
>
>       I'm hitting a wall with nfd behavior when it comes to the implicit digest.
> 
> a) What is working correctly:
> - first retrieve a packet by ordinary name
> - compute the digest of the received packet
> - then retrieve the same packet, but this time with the
> ?? special digest component appended and MaxSuffix=0
> - this works, the data will probably now be served from the CS
> (digest is a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d)
> 
> b) What is not working:
> - directly retrieve another packet with its (other) name and including
> ?? the special digest component for that data, and MaxSuffix=0
> - nfd accepts this request and forwards it upstream
> - nfd receives that data packet
> - but the received data is not delivered to the downstream
> ?? client (timeout of ndnpeek although I can see that nfd
> ?? received the right packet).
> (digest is 65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623)
> 
> The content comes in both cases from an upstream node (running
> ccn-lite), see the topology below.
> 
> One potential catch is that the two names are almost identical:
> 
> The name in step a) is
> /ndn/ch/unibas/repo256/movie7.mp4/_
> 
> The name in step b) is
> /ndn/ch/unibas/repo256/movie7.mp4
> 
> Is this a bug in PIT matching? Or has the second data object an internal
> problem that lets nfd refuse it (see the attached packet)? Below I also
> add the command line logs, FYI.
> 
> Best, christian
> 
> ---
> 
> # topology
>
> ?? ndnpeek --> nfd (UDP 6363) --> ccn-lite-relay (UDP 3636) --> ccn-lite-repo256
> (UDP 7777)
> 
> 
> # case a), showing correct behavior
> 
> tschudin at cs-ndn-testbed1:~$ ndnpeek -v /ndn/ch/unibas/repo256/movie7.mp4/_
> >pkt-1.bin
> INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/_
> DATA, RTT: 5ms
> 
> tschudin at cs-ndn-testbed1:~$ shasum -a 256 pkt-1.bin
> a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d??pkt-1.bin
> 
> tschudin at cs-ndn-testbed1:~$ ndnpeek -v/ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc30
> 2784b9b18ecd3812deef6795d
>       pkt-2.bin
> 
> INTEREST:/ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc30
> 2784b9b18ecd3812deef6795d
> DATA, RTT: 5ms
> 
> tschudin at cs-ndn-testbed1:~$ cmp pkt-1.bin pkt-2.bin
> 
> tschudin at cs-ndn-testbed1:~$
> 
> 
> # case b), showing the error
> 
> tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0/ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb
> 2adf74a4572b100c5f12885 >pkt-3.bin
> INTEREST:/ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb
> 2adf74a4572b100c5f12885?ndn.MaxSuffixComponents=0
> TIMEOUT
> 
> tschudin at cs-ndn-testbed1:~$
> 
> 
> # Log file captured with tcpdump (case b)
> 
> tschudin at cs-ndn-testbed1:~$ sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or
> udp port 7777' >traffic.log &
> [2] 20530
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
> 
> tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0/ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c5093230
> 8d3019848f23b2f59bc0623 >pkt-3.bin
> INTEREST:/ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c5093230
> 8d3019848f23b2f59bc0623?ndn.MaxSuffixComponents=0
> TIMEOUT
> 
> tschudin at cs-ndn-testbed1:~$ fg
> sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or udp port 7777' > traffic.log
> ^C6 packets captured
> 12 packets received by filter
> 0 packets dropped by kernel
> 
> tschudin at cs-ndn-testbed1:~$ less traffic.log
> 00:47:08.269244 IP cs-ndn-testbed1.cs.unibas.ch.6363 >
> cs-ndn-testbed1.cs.unibas.ch.3636: UDP, length 87
> 00:47:08.270061 IP localhost.3636 > localhost.6363: UDP, length 87
> 00:47:08.270181 IP localhost.6363 > localhost.3636: UDP, length 100
> 00:47:08.270362 IP localhost.3636 > localhost.7777: UDP, length 87
> 00:47:08.271063 IP localhost.7777 > localhost.3636: UDP, length 3862
> 00:47:08.271227 IP cs-ndn-testbed1.cs.unibas.ch.3636 >
> cs-ndn-testbed1.cs.unibas.ch.6363: UDP, length 3862
> 
> traffic.log (END)
> 
> 
> # log from the ccn-lite relay (which links to the upstream repo256, both running
> # on the same machine as nfd but using UDP ports 3636 and 7777, respectively)
> 
> [D] 100.1443: ccnl_core_RX ifndx=0, 87 bytes
> [D] 100.1443:?? face 9, peer=192.43.193.111/6363
> [I] 100.1444:?? incoming
> interest=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013
> from=192.43.193.111/6363
> [D] 100.1444:?? searching in CS
> [D] 100.1446:?? created new interest entry 0x1364f70
> (prefix=/ndn/ch/unibas/repo256/movie7.mp4)
> [D] 100.1446: ccnl_interest_propagate
> [D] 100.1447:?? ccnl_interest_propagate, fwd==0x13650d0
> [I] 100.1447:?? outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4>
> to=127.0.0.1/6363
> [D] 100.1449: udp sendto(87 Bytes) to 127.0.0.1/6363 returned 87/0
> [D] 100.1450:?? ccnl_interest_propagate, fwd==0x100e1f0
> [I] 100.1450:?? outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4>
> to=127.0.0.1/7777
> [D] 100.1450: udp sendto(87 Bytes) to 127.0.0.1/7777 returned 87/0
> [D] 100.1450: ccnl_core_RX ifndx=0, 100 bytes
> [D] 100.1451:?? face 2, peer=127.0.0.1/6363
> [I] 100.1457:?? ndnlp packet
> [D] 100.1458: ccnl_core_RX ifndx=0, 3862 bytes
> [D] 100.1458:?? face 6, peer=127.0.0.1/7777
> [I] 100.1458:?? incoming
> data=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013 from=127.0.0.1/7777
> [I] 100.1458:?? outgoing data=</ndn/ch/unibas/repo256/movie7.mp4>ndn2013
> to=192.43.193.111/6363
> [D] 100.1460: udp sendto(3862 Bytes) to 192.43.193.111/6363 returned 3862/0
> [D] 100.1460:?? adding content to cache
> 
> ---
> 
> 
>

From Marc.Mosko at parc.com  Sat Dec 12 13:03:08 2015
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Sat, 12 Dec 2015 21:03:08 +0000
Subject: [Nfd-dev] problem with selector for implicit digest?
In-Reply-To: <D29176FA.2F4D1%jefft0@remap.ucla.edu>
References: <alpine.OSX.2.20.1512102005540.83047@huvi.attlocal.net>
	<D29176FA.2F4D1%jefft0@remap.ucla.edu>
Message-ID: <2ABB4B5D-14B4-49CB-B9B3-4A52FFC6D85C@parc.com>

As a point of historical interest, in  CCNx 0.8, all matching against a Content Object was done via the so-called ?full name.?  The full name of a content object is its name plus its implicit digest.  And only in this sense does the MaxSuffixComponents/MinSuffixComponents make sense.

If one does not always append the implicit digest, then one could run in to situations where someone conjures up a name with a fake terminal digest component which could match an Interest with a digest component.  For example, I have a content object with real digest 0x123.  I create a name /foo/bar/digest=0xFFF.  The full name should be /foo/bar/digest=0xFFF/digest=0x123.  If one does not always append the implicit digest, then the content object could match an interest for /foo/bar/digest=0xFFF, particularly if an implementation was sloppy on how it handled the min/max suffix components (which is often misunderstood).

Marc

On Dec 12, 2015, at 7:14 AM, Thompson, Jeff <jefft0 at remap.ucla.edu<mailto:jefft0 at remap.ucla.edu>> wrote:

I tested in PyNDN and I confirm the same problem: NFD does not match an incoming data packet with an interest in the PIT which has an implicit digest component (but it does match from the content store).

Looking at the NFD code, Pit::findAllDataMatches calls m_nameTree.findAllMatches(data.getName(), ?) which does a longest prefix match of the data name to the interest name.
https://github.com/named-data/NFD/blob/5e5e44518286e89a0092ea0ad93c22e64128bdd2/daemon/table/pit.cpp#L97

But the interest name with the implicit digest component in the PIT is longer than the data name, so how can LPM match it? Should NFD strip the implicit digest component before putting the interest name in the PIT?s name tree?

- Jeff T

On 2015/12/11, 16:12:07, "Nfd-dev on behalf of christian.tschudin at unibas.ch<mailto:christian.tschudin at unibas.ch>" <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu> on behalf of christian.tschudin at unibas.ch<mailto:christian.tschudin at unibas.ch>> wrote:

I'm hitting a wall with nfd behavior when it comes to the implicit digest.

a) What is working correctly:
- first retrieve a packet by ordinary name
- compute the digest of the received packet
- then retrieve the same packet, but this time with the
   special digest component appended and MaxSuffix=0
- this works, the data will probably now be served from the CS
(digest is a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d)

b) What is not working:
- directly retrieve another packet with its (other) name and including
   the special digest component for that data, and MaxSuffix=0
- nfd accepts this request and forwards it upstream
- nfd receives that data packet
- but the received data is not delivered to the downstream
   client (timeout of ndnpeek although I can see that nfd
   received the right packet).
(digest is 65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623)

The content comes in both cases from an upstream node (running
ccn-lite), see the topology below.

One potential catch is that the two names are almost identical:

The name in step a) is
/ndn/ch/unibas/repo256/movie7.mp4/_

The name in step b) is
/ndn/ch/unibas/repo256/movie7.mp4

Is this a bug in PIT matching? Or has the second data object an internal
problem that lets nfd refuse it (see the attached packet)? Below I also
add the command line logs, FYI.

Best, christian

---

# topology

   ndnpeek --> nfd (UDP 6363) --> ccn-lite-relay (UDP 3636) --> ccn-lite-repo256 (UDP 7777)


# case a), showing correct behavior

tschudin at cs-ndn-testbed1:~$ ndnpeek -v /ndn/ch/unibas/repo256/movie7.mp4/_ >pkt-1.bin
INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/_
DATA, RTT: 5ms

tschudin at cs-ndn-testbed1:~$ shasum -a 256 pkt-1.bin
a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d  pkt-1.bin

tschudin at cs-ndn-testbed1:~$ ndnpeek -v /ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d
pkt-2.bin
INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d
DATA, RTT: 5ms

tschudin at cs-ndn-testbed1:~$ cmp pkt-1.bin pkt-2.bin

tschudin at cs-ndn-testbed1:~$


# case b), showing the error

tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0 /ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb2adf74a4572b100c5f12885 >pkt-3.bin
INTEREST: /ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb2adf74a4572b100c5f12885?ndn.MaxSuffixComponents=0
TIMEOUT

tschudin at cs-ndn-testbed1:~$


# Log file captured with tcpdump (case b)

tschudin at cs-ndn-testbed1:~$ sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or udp port 7777' >traffic.log &
[2] 20530
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes

tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0 /ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623 >pkt-3.bin
INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623?ndn.MaxSuffixComponents=0
TIMEOUT

tschudin at cs-ndn-testbed1:~$ fg
sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or udp port 7777' > traffic.log
^C6 packets captured
12 packets received by filter
0 packets dropped by kernel

tschudin at cs-ndn-testbed1:~$ less traffic.log
00:47:08.269244 IP cs-ndn-testbed1.cs.unibas.ch<http://cs-ndn-testbed1.cs.unibas.ch>.6363 > cs-ndn-testbed1.cs.unibas.ch<http://cs-ndn-testbed1.cs.unibas.ch>.3636: UDP, length 87
00:47:08.270061 IP localhost.3636 > localhost.6363: UDP, length 87
00:47:08.270181 IP localhost.6363 > localhost.3636: UDP, length 100
00:47:08.270362 IP localhost.3636 > localhost.7777: UDP, length 87
00:47:08.271063 IP localhost.7777 > localhost.3636: UDP, length 3862
00:47:08.271227 IP cs-ndn-testbed1.cs.unibas.ch<http://cs-ndn-testbed1.cs.unibas.ch>.3636 > cs-ndn-testbed1.cs.unibas.ch<http://cs-ndn-testbed1.cs.unibas.ch>.6363: UDP, length 3862

traffic.log (END)


# log from the ccn-lite relay (which links to the upstream repo256, both running
# on the same machine as nfd but using UDP ports 3636 and 7777, respectively)

[D] 100.1443: ccnl_core_RX ifndx=0, 87 bytes
[D] 100.1443:   face 9, peer=192.43.193.111/6363
[I] 100.1444:   incoming interest=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013 from=192.43.193.111/6363
[D] 100.1444:   searching in CS
[D] 100.1446:   created new interest entry 0x1364f70 (prefix=/ndn/ch/unibas/repo256/movie7.mp4)
[D] 100.1446: ccnl_interest_propagate
[D] 100.1447:   ccnl_interest_propagate, fwd==0x13650d0
[I] 100.1447:   outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4> to=127.0.0.1/6363
[D] 100.1449: udp sendto(87 Bytes) to 127.0.0.1/6363 returned 87/0
[D] 100.1450:   ccnl_interest_propagate, fwd==0x100e1f0
[I] 100.1450:   outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4> to=127.0.0.1/7777
[D] 100.1450: udp sendto(87 Bytes) to 127.0.0.1/7777 returned 87/0
[D] 100.1450: ccnl_core_RX ifndx=0, 100 bytes
[D] 100.1451:   face 2, peer=127.0.0.1/6363
[I] 100.1457:   ndnlp packet
[D] 100.1458: ccnl_core_RX ifndx=0, 3862 bytes
[D] 100.1458:   face 6, peer=127.0.0.1/7777
[I] 100.1458:   incoming data=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013 from=127.0.0.1/7777
[I] 100.1458:   outgoing data=</ndn/ch/unibas/repo256/movie7.mp4>ndn2013 to=192.43.193.111/6363
[D] 100.1460: udp sendto(3862 Bytes) to 192.43.193.111/6363 returned 3862/0
[D] 100.1460:   adding content to cache

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

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

From aa at CS.UCLA.EDU  Sun Dec 13 13:35:54 2015
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Sun, 13 Dec 2015 13:35:54 -0800
Subject: [Nfd-dev] problem with selector for implicit digest?
In-Reply-To: <alpine.OSX.2.20.1512120856400.4503@huvi.attlocal.net>
References: <alpine.OSX.2.20.1512102005540.83047@huvi.attlocal.net>
	<D29176FA.2F4D1%jefft0@remap.ucla.edu>
	<alpine.OSX.2.20.1512120856400.4503@huvi.attlocal.net>
Message-ID: <05C0769A-2624-4EE0-9904-144DD7593DE4@cs.ucla.edu>

Hi Christian,

Thanks for discovering the issue.  Even though we unit test everything and do integration tests for many things, this important function is for some reason got broken.

I have created a follow up redmine ticket (http://redmine.named-data.net/issues/3363) with a simplified scenario to reproduce the problem.  We will fix the issue asap.

--
Alex

> On Dec 12, 2015, at 9:10 AM, christian.tschudin at unibas.ch wrote:
> 
> Jeff, thanks for this insight.
> 
> This seems to indicate that so far digest-based lookup was not used by anyone, and therefore now would be a good moment to revisit that part of the mechanics?
> 
> Since the beginning of ccn-lite I thought that the handling of the implicit digest was not elegant and will lead to implementation accidents. Conceptually it is a selector and should be handled there, instead of a name component.
> 
> One could even go a step further and reserve a special field for it in the interest (instead of inside the selector block) because it is a knock-out restriction: Any selector then becomes irrelevant.
> 
> Thoughts?
> 
> best, c
> 
> 
> On Sat, 12 Dec 2015, Thompson, Jeff wrote:
> 
>> I tested in PyNDN and I confirm the same problem: NFD does not match an incoming data
>> packet with an interest in the PIT which has an implicit digest component (but it does
>> match from the content store).
>> Looking at the NFD code, Pit::findAllDataMatches calls
>> m_nameTree.findAllMatches(data.getName(), ?) which does a longest prefix match of the
>> data name to the interest name.
>> https://github.com/named-data/NFD/blob/5e5e44518286e89a0092ea0ad93c22e64128bdd2/daemon/t
>> able/pit.cpp#L97
>> But the interest name with the implicit digest component in the PIT is longer than the
>> data name, so how can LPM match it? Should NFD strip the implicit digest component before
>> putting the interest name in the PIT?s name tree?
>> - Jeff T
>> On 2015/12/11, 16:12:07, "Nfd-dev on behalf of christian.tschudin at unibas.ch"
>> <nfd-dev-bounces at lists.cs.ucla.edu on behalf of christian.tschudin at unibas.ch> wrote:
>> 
>>      I'm hitting a wall with nfd behavior when it comes to the implicit digest.
>> a) What is working correctly:
>> - first retrieve a packet by ordinary name
>> - compute the digest of the received packet
>> - then retrieve the same packet, but this time with the
>>    special digest component appended and MaxSuffix=0
>> - this works, the data will probably now be served from the CS
>> (digest is a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d)
>> b) What is not working:
>> - directly retrieve another packet with its (other) name and including
>>    the special digest component for that data, and MaxSuffix=0
>> - nfd accepts this request and forwards it upstream
>> - nfd receives that data packet
>> - but the received data is not delivered to the downstream
>>    client (timeout of ndnpeek although I can see that nfd
>>    received the right packet).
>> (digest is 65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623)
>> The content comes in both cases from an upstream node (running
>> ccn-lite), see the topology below.
>> One potential catch is that the two names are almost identical:
>> The name in step a) is
>> /ndn/ch/unibas/repo256/movie7.mp4/_
>> The name in step b) is
>> /ndn/ch/unibas/repo256/movie7.mp4
>> Is this a bug in PIT matching? Or has the second data object an internal
>> problem that lets nfd refuse it (see the attached packet)? Below I also
>> add the command line logs, FYI.
>> Best, christian
>> ---
>> # topology
>> 
>>    ndnpeek --> nfd (UDP 6363) --> ccn-lite-relay (UDP 3636) --> ccn-lite-repo256
>> (UDP 7777)
>> # case a), showing correct behavior
>> tschudin at cs-ndn-testbed1:~$ ndnpeek -v /ndn/ch/unibas/repo256/movie7.mp4/_
>> >pkt-1.bin
>> INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/_
>> DATA, RTT: 5ms
>> tschudin at cs-ndn-testbed1:~$ shasum -a 256 pkt-1.bin
>> a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d  pkt-1.bin
>> tschudin at cs-ndn-testbed1:~$ ndnpeek -v/ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc30
>> 2784b9b18ecd3812deef6795d
>>      pkt-2.bin
>> INTEREST:/ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc30
>> 2784b9b18ecd3812deef6795d
>> DATA, RTT: 5ms
>> tschudin at cs-ndn-testbed1:~$ cmp pkt-1.bin pkt-2.bin
>> tschudin at cs-ndn-testbed1:~$
>> # case b), showing the error
>> tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0/ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb
>> 2adf74a4572b100c5f12885 >pkt-3.bin
>> INTEREST:/ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb
>> 2adf74a4572b100c5f12885?ndn.MaxSuffixComponents=0
>> TIMEOUT
>> tschudin at cs-ndn-testbed1:~$
>> # Log file captured with tcpdump (case b)
>> tschudin at cs-ndn-testbed1:~$ sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or
>> udp port 7777' >traffic.log &
>> [2] 20530
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
>> tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0/ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c5093230
>> 8d3019848f23b2f59bc0623 >pkt-3.bin
>> INTEREST:/ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c5093230
>> 8d3019848f23b2f59bc0623?ndn.MaxSuffixComponents=0
>> TIMEOUT
>> tschudin at cs-ndn-testbed1:~$ fg
>> sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or udp port 7777' > traffic.log
>> ^C6 packets captured
>> 12 packets received by filter
>> 0 packets dropped by kernel
>> tschudin at cs-ndn-testbed1:~$ less traffic.log
>> 00:47:08.269244 IP cs-ndn-testbed1.cs.unibas.ch.6363 >
>> cs-ndn-testbed1.cs.unibas.ch.3636: UDP, length 87
>> 00:47:08.270061 IP localhost.3636 > localhost.6363: UDP, length 87
>> 00:47:08.270181 IP localhost.6363 > localhost.3636: UDP, length 100
>> 00:47:08.270362 IP localhost.3636 > localhost.7777: UDP, length 87
>> 00:47:08.271063 IP localhost.7777 > localhost.3636: UDP, length 3862
>> 00:47:08.271227 IP cs-ndn-testbed1.cs.unibas.ch.3636 >
>> cs-ndn-testbed1.cs.unibas.ch.6363: UDP, length 3862
>> traffic.log (END)
>> # log from the ccn-lite relay (which links to the upstream repo256, both running
>> # on the same machine as nfd but using UDP ports 3636 and 7777, respectively)
>> [D] 100.1443: ccnl_core_RX ifndx=0, 87 bytes
>> [D] 100.1443:   face 9, peer=192.43.193.111/6363
>> [I] 100.1444:   incoming
>> interest=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013
>> from=192.43.193.111/6363
>> [D] 100.1444:   searching in CS
>> [D] 100.1446:   created new interest entry 0x1364f70
>> (prefix=/ndn/ch/unibas/repo256/movie7.mp4)
>> [D] 100.1446: ccnl_interest_propagate
>> [D] 100.1447:   ccnl_interest_propagate, fwd==0x13650d0
>> [I] 100.1447:   outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4>
>> to=127.0.0.1/6363
>> [D] 100.1449: udp sendto(87 Bytes) to 127.0.0.1/6363 returned 87/0
>> [D] 100.1450:   ccnl_interest_propagate, fwd==0x100e1f0
>> [I] 100.1450:   outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4>
>> to=127.0.0.1/7777
>> [D] 100.1450: udp sendto(87 Bytes) to 127.0.0.1/7777 returned 87/0
>> [D] 100.1450: ccnl_core_RX ifndx=0, 100 bytes
>> [D] 100.1451:   face 2, peer=127.0.0.1/6363
>> [I] 100.1457:   ndnlp packet
>> [D] 100.1458: ccnl_core_RX ifndx=0, 3862 bytes
>> [D] 100.1458:   face 6, peer=127.0.0.1/7777
>> [I] 100.1458:   incoming
>> data=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013 from=127.0.0.1/7777
>> [I] 100.1458:   outgoing data=</ndn/ch/unibas/repo256/movie7.mp4>ndn2013
>> to=192.43.193.111/6363
>> [D] 100.1460: udp sendto(3862 Bytes) to 192.43.193.111/6363 returned 3862/0
>> [D] 100.1460:   adding content to cache
>> ---
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

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

From salvatore.signorello at uni.lu  Mon Dec 14 14:37:08 2015
From: salvatore.signorello at uni.lu (Salvatore Signorello)
Date: Mon, 14 Dec 2015 23:37:08 +0100
Subject: [Nfd-dev] additional data between ethernet header and ndn header
Message-ID: <566F4494.8070607@uni.lu>

Hi all,

on a single machine, I generate an Interest with ndnpeek and then I 
sniff the veth interface my NFD has forwarded the Interest to. On 
wireshark (I'm using the dissector for the ndn protocol) I have 16 bytes 
between the ethernet header and the ndn one there are 14 bytes, what are 
those bytes for?

Thanks in advance,
best,
Salvatore


-- 
Salvatore Signorello
PhD student @ SecanLab

Interdisciplinary Centre for Security, Reliability and Trust
SnT, University of Luxembourg
http://wwwen.uni.lu/snt/people/salvatore_signorello



From aa at CS.UCLA.EDU  Mon Dec 14 14:42:20 2015
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Mon, 14 Dec 2015 14:42:20 -0800
Subject: [Nfd-dev] additional data between ethernet header and ndn header
In-Reply-To: <566F4494.8070607@uni.lu>
References: <566F4494.8070607@uni.lu>
Message-ID: <6ADF6759-EA2A-4F10-98B0-CC8D8A1CC882@cs.ucla.edu>

Hi Salvatore,

Can you attach an .pcap of a few packets you're observing?

--
Alex

> On Dec 14, 2015, at 2:37 PM, Salvatore Signorello <salvatore.signorello at uni.lu> wrote:
> 
> Hi all,
> 
> on a single machine, I generate an Interest with ndnpeek and then I sniff the veth interface my NFD has forwarded the Interest to. On wireshark (I'm using the dissector for the ndn protocol) I have 16 bytes between the ethernet header and the ndn one there are 14 bytes, what are those bytes for?
> 
> Thanks in advance,
> best,
> Salvatore
> 
> 
> --
> Salvatore Signorello
> PhD student @ SecanLab
> 
> Interdisciplinary Centre for Security, Reliability and Trust
> SnT, University of Luxembourg
> http://wwwen.uni.lu/snt/people/salvatore_signorello
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151214/a6fe75f3/attachment.bin>

From aa at CS.UCLA.EDU  Mon Dec 14 15:35:47 2015
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Mon, 14 Dec 2015 15:35:47 -0800
Subject: [Nfd-dev] additional data between ethernet header and ndn header
In-Reply-To: <566F4829.70207@uni.lu>
References: <566F4494.8070607@uni.lu>
	<6ADF6759-EA2A-4F10-98B0-CC8D8A1CC882@cs.ucla.edu>
	<566F4829.70207@uni.lu>
Message-ID: <0BD7C6B1-A918-4916-A714-26FCC27A9798@cs.ucla.edu>

Hmm..

Something is strange.  I have tried to capture packet on my machine (with 0.4.0-beta2-24-g25ac97f) and I'm having a different .pcap, which does not have anything between ethernet header and NDN packet:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: interest.pcap
Type: application/octet-stream
Size: 100 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151214/5f17358f/attachment.obj>
-------------- next part --------------


Can you describe the environment you're capturing packets?  Version of nfd (nfd --version), your OS, is it a VM, type of interface (wifi, ethernet, VLAN or not VLAN), output of ifconfig.

---
Alex

> On Dec 14, 2015, at 2:52 PM, Salvatore Signorello <salvatore.signorello at uni.lu> wrote:
> 
> Hi Alex,
> 
> the pcap is in attach. I'm not using the latest version of the software tools and daemon, so if you either don't see the issue or are not able to reproduce it. I'll likely update the ndn software suite before asking you for more support.
> 
> Thanks,
> Salvatore
> 
> On 12/14/2015 11:42 PM, Alex Afanasyev wrote:
>> Hi Salvatore,
>> 
>> Can you attach an .pcap of a few packets you're observing?
>> 
>> --
>> Alex
>> 
>>> On Dec 14, 2015, at 2:37 PM, Salvatore Signorello <salvatore.signorello at uni.lu> wrote:
>>> 
>>> Hi all,
>>> 
>>> on a single machine, I generate an Interest with ndnpeek and then I sniff the veth interface my NFD has forwarded the Interest to. On wireshark (I'm using the dissector for the ndn protocol) I have 16 bytes between the ethernet header and the ndn one there are 14 bytes, what are those bytes for?
>>> 
>>> Thanks in advance,
>>> best,
>>> Salvatore
>>> 
>>> 
>>> --
>>> Salvatore Signorello
>>> PhD student @ SecanLab
>>> 
>>> Interdisciplinary Centre for Security, Reliability and Trust
>>> SnT, University of Luxembourg
>>> http://wwwen.uni.lu/snt/people/salvatore_signorello
> 
> --
> Salvatore Signorello
> PhD student @ SecanLab
> 
> Interdisciplinary Centre for Security, Reliability and Trust
> SnT, University of Luxembourg
> http://wwwen.uni.lu/snt/people/salvatore_signorello
> 
> <packetDump.pcap>

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

From salvatore.signorello at uni.lu  Mon Dec 14 14:52:25 2015
From: salvatore.signorello at uni.lu (Salvatore Signorello)
Date: Mon, 14 Dec 2015 23:52:25 +0100
Subject: [Nfd-dev] additional data between ethernet header and ndn header
In-Reply-To: <6ADF6759-EA2A-4F10-98B0-CC8D8A1CC882@cs.ucla.edu>
References: <566F4494.8070607@uni.lu>
	<6ADF6759-EA2A-4F10-98B0-CC8D8A1CC882@cs.ucla.edu>
Message-ID: <566F4829.70207@uni.lu>

Hi Alex,

the pcap is in attach. I'm not using the latest version of the software 
tools and daemon, so if you either don't see the issue or are not able 
to reproduce it. I'll likely update the ndn software suite before asking 
you for more support.

Thanks,
Salvatore

On 12/14/2015 11:42 PM, Alex Afanasyev wrote:
> Hi Salvatore,
>
> Can you attach an .pcap of a few packets you're observing?
>
> --
> Alex
>
>> On Dec 14, 2015, at 2:37 PM, Salvatore Signorello <salvatore.signorello at uni.lu> wrote:
>>
>> Hi all,
>>
>> on a single machine, I generate an Interest with ndnpeek and then I sniff the veth interface my NFD has forwarded the Interest to. On wireshark (I'm using the dissector for the ndn protocol) I have 16 bytes between the ethernet header and the ndn one there are 14 bytes, what are those bytes for?
>>
>> Thanks in advance,
>> best,
>> Salvatore
>>
>>
>> --
>> Salvatore Signorello
>> PhD student @ SecanLab
>>
>> Interdisciplinary Centre for Security, Reliability and Trust
>> SnT, University of Luxembourg
>> http://wwwen.uni.lu/snt/people/salvatore_signorello

-- 
Salvatore Signorello
PhD student @ SecanLab

Interdisciplinary Centre for Security, Reliability and Trust
SnT, University of Luxembourg
http://wwwen.uni.lu/snt/people/salvatore_signorello

-------------- next part --------------
A non-text attachment was scrubbed...
Name: packetDump.pcap
Type: application/vnd.tcpdump.pcap
Size: 198 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151214/011d8b8b/attachment.bin>

From salvatore.signorello at uni.lu  Mon Dec 14 16:05:57 2015
From: salvatore.signorello at uni.lu (Salvatore Signorello)
Date: Tue, 15 Dec 2015 01:05:57 +0100
Subject: [Nfd-dev] additional data between ethernet header and ndn header
In-Reply-To: <0BD7C6B1-A918-4916-A714-26FCC27A9798@cs.ucla.edu>
References: <566F4494.8070607@uni.lu>
	<6ADF6759-EA2A-4F10-98B0-CC8D8A1CC882@cs.ucla.edu>
	<566F4829.70207@uni.lu>
	<0BD7C6B1-A918-4916-A714-26FCC27A9798@cs.ucla.edu>
Message-ID: <566F5965.1010302@uni.lu>

Hi Alex,

follow more details about my working environment:

OS: ubuntu 14.04 (it's not running into a virtual machine)
nfd: 0.3.3-14-ga714792
the interface is a virtual one whose ifconfig output is:

veth0     Link encap:Ethernet  HWaddr c2:91:c9:ee:78:77
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:21 errors:0 dropped:0 overruns:0 frame:0
           TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:1797 (1.7 KB)  TX bytes:1351 (1.3 KB)

I've also noticed that if I change the Interest name, those additional 
data maintain the same size, but they contain different values. Have you 
experienced sth like that with any older version of the software? I 
think that I'll go to update the sw to see if the problem persists.

Salvatore

On 12/15/2015 12:35 AM, Alex Afanasyev wrote:
> Hmm..
>
> Something is strange.  I have tried to capture packet on my machine (with 0.4.0-beta2-24-g25ac97f) and I'm having a different .pcap, which does not have anything between ethernet header and NDN packet:
>
>
>
>
> Can you describe the environment you're capturing packets?  Version of nfd (nfd --version), your OS, is it a VM, type of interface (wifi, ethernet, VLAN or not VLAN), output of ifconfig.
>
> ---
> Alex
>
>> On Dec 14, 2015, at 2:52 PM, Salvatore Signorello <salvatore.signorello at uni.lu> wrote:
>>
>> Hi Alex,
>>
>> the pcap is in attach. I'm not using the latest version of the software tools and daemon, so if you either don't see the issue or are not able to reproduce it. I'll likely update the ndn software suite before asking you for more support.
>>
>> Thanks,
>> Salvatore
>>
>> On 12/14/2015 11:42 PM, Alex Afanasyev wrote:
>>> Hi Salvatore,
>>>
>>> Can you attach an .pcap of a few packets you're observing?
>>>
>>> --
>>> Alex
>>>
>>>> On Dec 14, 2015, at 2:37 PM, Salvatore Signorello <salvatore.signorello at uni.lu> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> on a single machine, I generate an Interest with ndnpeek and then I sniff the veth interface my NFD has forwarded the Interest to. On wireshark (I'm using the dissector for the ndn protocol) I have 16 bytes between the ethernet header and the ndn one there are 14 bytes, what are those bytes for?
>>>>
>>>> Thanks in advance,
>>>> best,
>>>> Salvatore
>>>>
>>>>
>>>> --
>>>> Salvatore Signorello
>>>> PhD student @ SecanLab
>>>>
>>>> Interdisciplinary Centre for Security, Reliability and Trust
>>>> SnT, University of Luxembourg
>>>> http://wwwen.uni.lu/snt/people/salvatore_signorello
>> --
>> Salvatore Signorello
>> PhD student @ SecanLab
>>
>> Interdisciplinary Centre for Security, Reliability and Trust
>> SnT, University of Luxembourg
>> http://wwwen.uni.lu/snt/people/salvatore_signorello
>>
>> <packetDump.pcap>

-- 
Salvatore Signorello
PhD student @ SecanLab

Interdisciplinary Centre for Security, Reliability and Trust
SnT, University of Luxembourg
http://wwwen.uni.lu/snt/people/salvatore_signorello

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

From nfd-call-notification at mail1.yoursunny.com  Tue Dec 15 07:00:04 2015
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 15 Dec 2015 08:00:04 -0700
Subject: [Nfd-dev] NFD call 20151215
Message-ID: <201512151500.tBFF04TQ006519@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151215/8a35b5c4/attachment.html>

From shijunxiao at email.arizona.EDU  Tue Dec 15 07:37:32 2015
From: shijunxiao at email.arizona.EDU (Junxiao Shi)
Date: Tue, 15 Dec 2015 08:37:32 -0700
Subject: [Nfd-dev] additional data between ethernet header and ndn header
In-Reply-To: <566F4829.70207@uni.lu>
References: <566F4494.8070607@uni.lu>
	<6ADF6759-EA2A-4F10-98B0-CC8D8A1CC882@cs.ucla.edu>
	<566F4829.70207@uni.lu>
Message-ID: <CAOFH+OYmN9=T3heQwbDr20RP0tNqBhjer0J6nWfa1U9ybqRtLA@mail.gmail.com>

Hi Salvatore

The payload of the first packet in the pcap
is 50:37:51:08:00:00:00:00:00:00:00:11:54:2b:05:29:07:21:08:10:70:34:73:6f:66:74:77:61:72:65:73:77:69:74:63:68:08:0d:73:61:79:68:65:6c:6c:6f:77:6f:72:6c:64:0a:04:10:f2:e0:8f.
This appears to be NDNLPv1-TLV
<http://redmine.named-data.net/projects/nfd/wiki/NDNLP-TLV> protocol, and
can be interpreted as:

50 37 // NdnlpData
   51 08 // NdnlpSequence
      00 00 00 00 00 00 00 11
   54 2b // NdnlpPayload
      05 29 // Interest
         07 21 // Name
            08 10 // NameComponent
               70 34 73 6f 66 74 77 61 72 65 73 77 69 74 63 68
            08 0d // NameComponent
               73 61 79 68 65 6c 6c 6f 77 6f 72 6c 64
         0a 04 // Nonce
            10 f2 e0 8f

Neither ndndump nor NDN dissector for Wireshark supports NDNLPv1-TLV.
In latest NFD, NDNLPv1-TLV is deprecated and replaced by NDNLPv2
<http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2>, which will be
supported by NDN dissector for Wireshark in #3197
<http://redmine.named-data.net/issues/3197>.

Yours, Junxiao

On Mon, Dec 14, 2015 at 3:52 PM, Salvatore Signorello <
salvatore.signorello at uni.lu> wrote:

> Hi Alex,
>
> the pcap is in attach. I'm not using the latest version of the software
> tools and daemon, so if you either don't see the issue or are not able to
> reproduce it. I'll likely update the ndn software suite before asking you
> for more support.
>
> Thanks,
> Salvatore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151215/d90f3814/attachment.html>

From shijunxiao at email.arizona.edu  Tue Dec 15 14:07:57 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 15 Dec 2015 15:07:57 -0700
Subject: [Nfd-dev] additional data between ethernet header and ndn header
In-Reply-To: <56708D41.5050304@uni.lu>
References: <566F4494.8070607@uni.lu>
	<6ADF6759-EA2A-4F10-98B0-CC8D8A1CC882@cs.ucla.edu>
	<566F4829.70207@uni.lu>
	<CAOFH+OYmN9=T3heQwbDr20RP0tNqBhjer0J6nWfa1U9ybqRtLA@mail.gmail.com>
	<56708D41.5050304@uni.lu>
Message-ID: <4BAEDBB3-FF7C-4572-971D-F42FB0F43333@email.arizona.edu>

Hi Salvatore

Alex?s NFD version implements NDNLPv2. NDNLPv2 permits bare Interest/Data packets to appear on the wire. NFD?s NDNLPv2 implementation sends NDNLPv2 packets only if at least one NDNLPv2 header/trailer field is added.
In his experiment, if none of the NDNLPv2 header/trailer field is added, the packet would be bare Interest/Data and thus no additional octets appear on the wire.

Yours, Junxiao

> On Dec 15, 2015, at 2:59 PM, Salvatore Signorello <salvatore.signorello at uni.lu> wrote:
> 
> Thank you, Junxiao,
> 
> this clarifies things a lot ;)
> 
> If this protocol is always used by NFD, I wonder why Alex doesn't see the additional bytes when dumping a packet. Any clue about that?
> 
> Best,
> Salvatore
> 
> On 12/15/2015 04:37 PM, Junxiao Shi wrote:
>> Hi Salvatore
>> 
>> The payload of the first packet in the pcap is 50:37:51:08:00:00:00:00:00:00:00:11:54:2b:05:29:07:21:08:10:70:34:73:6f:66:74:77:61:72:65:73:77:69:74:63:68:08:0d:73:61:79:68:65:6c:6c:6f:77:6f:72:6c:64:0a:04:10:f2:e0:8f.
>> This appears to be NDNLPv1-TLV <http://redmine.named-data.net/projects/nfd/wiki/NDNLP-TLV> protocol, and can be interpreted as:
>> 
>> 50 37 // NdnlpData
>>    51 08 // NdnlpSequence
>>       00 00 00 00 00 00 00 11
>>    54 2b // NdnlpPayload
>>       05 29 // Interest
>>          07 21 // Name
>>             08 10 // NameComponent
>>                70 34 73 6f 66 74 77 61 72 65 73 77 69 74 63 68
>>             08 0d // NameComponent
>>                73 61 79 68 65 6c 6c 6f 77 6f 72 6c 64
>>          0a 04 // Nonce
>>             10 f2 e0 8f
>> 
>> Neither ndndump nor NDN dissector for Wireshark supports NDNLPv1-TLV.
>> In latest NFD, NDNLPv1-TLV is deprecated and replaced by NDNLPv2 <http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2>, which will be supported by NDN dissector for Wireshark in #3197 <http://redmine.named-data.net/issues/3197>.
>> 
>> Yours, Junxiao
>> 
>> On Mon, Dec 14, 2015 at 3:52 PM, Salvatore Signorello < <mailto:salvatore.signorello at uni.lu>salvatore.signorello at uni.lu <mailto:salvatore.signorello at uni.lu>> wrote:
>> Hi Alex,
>> 
>> the pcap is in attach. I'm not using the latest version of the software tools and daemon, so if you either don't see the issue or are not able to reproduce it. I'll likely update the ndn software suite before asking you for more support.
>> 
>> Thanks,
>> Salvatore
> 
> -- 
> Salvatore Signorello
> PhD student @ SecanLab
> 
> Interdisciplinary Centre for Security, Reliability and Trust
> SnT, University of Luxembourg
> http://wwwen.uni.lu/snt/people/salvatore_signorello <http://wwwen.uni.lu/snt/people/salvatore_signorello>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151215/413b76fb/attachment.html>

From aa at CS.UCLA.EDU  Thu Dec 17 00:44:16 2015
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Thu, 17 Dec 2015 00:44:16 -0800
Subject: [Nfd-dev] Mailer updates on redmine and gerrit
Message-ID: <0A86DFC4-355D-4392-9BFA-2B72CE69AE70@cs.ucla.edu>

In attempt to fix the mailing issue from redmine and gerrit sevices, I configured both to use gmail as SMTP relay.  As a result, there is a change in "From" field---it will include ndn.robot at gmail.com.

This is a test, and I may adjust settings again in the future (I'm worried that gmail may eventually block us, if we have too many emails).

--
Alex

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

From shijunxiao at email.arizona.EDU  Thu Dec 17 04:30:54 2015
From: shijunxiao at email.arizona.EDU (Junxiao Shi)
Date: Thu, 17 Dec 2015 05:30:54 -0700
Subject: [Nfd-dev] Mailer updates on redmine and gerrit
In-Reply-To: <0A86DFC4-355D-4392-9BFA-2B72CE69AE70@cs.ucla.edu>
References: <0A86DFC4-355D-4392-9BFA-2B72CE69AE70@cs.ucla.edu>
Message-ID: <CAOFH+OYFZQir+z++p8d3aOVESDEOY9Nw+N70Bc9ZaNt9qG6Y+A@mail.gmail.com>

Hi Alex

According to
http://group-mail.com/sending-email/email-send-limits-and-options/ , Gmail
allows 100-150 outgoing messages per day. Gerrit sends much more than that
on a busy day.
Consider using SendGrid or AWS.

Yours, Junxiao
On Dec 17, 2015 01:44, "Alex Afanasyev" <aa at cs.ucla.edu> wrote:

> In attempt to fix the mailing issue from redmine and gerrit sevices, I
> configured both to use gmail as SMTP relay.  As a result, there is a change
> in "From" field---it will include ndn.robot at gmail.com.
>
> This is a test, and I may adjust settings again in the future (I'm worried
> that gmail may eventually block us, if we have too many emails).
>
> --
> Alex
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151217/931eef02/attachment.html>

From pdpa at st-andrews.ac.uk  Thu Dec 17 05:04:34 2015
From: pdpa at st-andrews.ac.uk (Percy Perez Aruni)
Date: Thu, 17 Dec 2015 13:04:34 +0000
Subject: [Nfd-dev] Ethernet FaceURI in NFD-Android
Message-ID: <CAOP2KvwQyxkPk9AtbVX=31HKy7-KvmsLPFufBwZ0uxza2TkM0A@mail.gmail.com>

Hi Ndn-dev team

Can I ask for advice or tips regarding of how the actual "*NFD*-*Android*"
can create  new UriFaces using MAC addresses on rooted Android smartphones?

I am getting the error "Error creating face" when I creating a Ethernet
FaceURI. My syntax is:

Prefix: /my/prefix
Face URI: ether://[08:00:33:01:01:01]

Thanks you .

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

From shijunxiao at email.arizona.EDU  Thu Dec 17 05:11:57 2015
From: shijunxiao at email.arizona.EDU (Junxiao Shi)
Date: Thu, 17 Dec 2015 06:11:57 -0700
Subject: [Nfd-dev] Ethernet FaceURI in NFD-Android
In-Reply-To: <CAOP2KvwQyxkPk9AtbVX=31HKy7-KvmsLPFufBwZ0uxza2TkM0A@mail.gmail.com>
References: <CAOP2KvwQyxkPk9AtbVX=31HKy7-KvmsLPFufBwZ0uxza2TkM0A@mail.gmail.com>
Message-ID: <CAOFH+OaE3jgVGvftRE4BiL4rcSbs5_wsyXrVWDADArfAs_Ofhw@mail.gmail.com>

Hi Percy

NFD Management Protocol faces/create command only allows TCP and UDP
unicast face creation.
http://redmine.named-data.net/projects/nfd/wiki/FaceMgmt#Create-a-face

NFD creates one Ethernet multicast face on every NIC during initialization.
Subsequently, you may use its FaceId during prefix registration.

Yours, Junxiao
On Dec 17, 2015 06:07, "Percy Perez Aruni" <pdpa at st-andrews.ac.uk> wrote:

> Hi Ndn-dev team
>
> Can I ask for advice or tips regarding of how the actual "*NFD*-*Android*"
> can create  new UriFaces using MAC addresses on rooted Android smartphones?
>
> I am getting the error "Error creating face" when I creating a Ethernet
> FaceURI. My syntax is:
>
> Prefix: /my/prefix
> Face URI: ether://[08:00:33:01:01:01]
>
> Thanks you .
>
> Regards
> Percy
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151217/589b60b1/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Thu Dec 17 07:00:02 2015
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 17 Dec 2015 08:00:02 -0700
Subject: [Nfd-dev] NFD call 20151217
Message-ID: <201512171500.tBHF02PR010818@lectura.cs.arizona.edu>

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

From aa at CS.UCLA.EDU  Thu Dec 17 11:25:17 2015
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Thu, 17 Dec 2015 11:25:17 -0800
Subject: [Nfd-dev] Temporary outage of redmine, gerrit, www.named-data.net
Message-ID: <38D4A713-1314-40E8-98E0-10016A2D57E4@cs.ucla.edu>

I tried to fix a few things today on the server, and unfortunately did something that made server not accessible anymore.

I will try to restore everything asap, though it may take some time.

---
Alex

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

From aa at CS.UCLA.EDU  Thu Dec 17 12:28:33 2015
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Thu, 17 Dec 2015 12:28:33 -0800
Subject: [Nfd-dev] Temporary outage of redmine, gerrit,
	www.named-data.net
In-Reply-To: <38D4A713-1314-40E8-98E0-10016A2D57E4@cs.ucla.edu>
References: <38D4A713-1314-40E8-98E0-10016A2D57E4@cs.ucla.edu>
Message-ID: <4F10E4E8-3226-4A00-A9C7-25EFB37709D2@cs.ucla.edu>

Services are back online.

> On Dec 17, 2015, at 11:25 AM, Alex Afanasyev <aa at cs.ucla.edu> wrote:
> 
> I tried to fix a few things today on the server, and unfortunately did something that made server not accessible anymore.
> 
> I will try to restore everything asap, though it may take some time.

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

From nfd-call-notification at mail1.yoursunny.com  Tue Dec 22 07:00:01 2015
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 22 Dec 2015 08:00:01 -0700
Subject: [Nfd-dev] NFD call 20151222
Message-ID: <201512221500.tBMF01EI010185@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151222/54c44802/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Thu Dec 24 07:00:03 2015
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 24 Dec 2015 08:00:03 -0700
Subject: [Nfd-dev] NFD call 20151224
Message-ID: <201512241500.tBOF03v3030639@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151224/19d30b2d/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Tue Dec 29 07:00:02 2015
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 29 Dec 2015 08:00:02 -0700
Subject: [Nfd-dev] NFD call 20151229
Message-ID: <201512291500.tBTF02Sk023533@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151229/c56190f5/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Thu Dec 31 07:00:02 2015
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 31 Dec 2015 08:00:02 -0700
Subject: [Nfd-dev] NFD call 20151231
Message-ID: <201512311500.tBVF02uO003230@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151231/4b36e8e6/attachment.html>

From aa at CS.UCLA.EDU  Thu Dec 31 11:09:24 2015
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Thu, 31 Dec 2015 11:09:24 -0800
Subject: [Nfd-dev] NFD/ndn-cxx release 0.4.0
Message-ID: <7932B802-830E-4196-9082-B73E31BE3044@cs.ucla.edu>

Dear all,

Happy New Year to everybody!

We are also pleased to announce the release of version 0.4.0 of Named Data Networking
Forwarding Daemon (NFD) and ndn-cxx library.

The detailed notes for the releases:
- for NFD: http://named-data.net/doc/NFD/0.4.0/RELEASE_NOTES.html
- for ndn-cxx library: http://named-data.net/doc/ndn-cxx/0.4.0/RELEASE_NOTES.html

***
Please note that this release contains several breaking changes to face system and
configuration files.  See more details in the release notes.
***

Source code, instruction how to install NFD on Ubuntu Linux (12.04, 14.04, and 15.10) and
OS X (10.9, 10.10, 10.11), tutorials, HOWTOs, a FAQ and other useful resources are
available on official webpages of NFD and ndn-cxx:
- http://named-data.net/doc/NFD/0.4.0/
- http://named-data.net/doc/ndn-cxx/0.4.0/

We also have updated the NFD developer's guide to revision 5 (more updates coming
before the next release):
- http://named-data.net/techreport/ndn-0021-5-nfd-developer-guide.pdf.

* * *

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

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