[icnrg] Q

[<[e-mail]>]

See below.  Thanks for reading!  marc


On Aug 1, 2016, at 10:50 AM, Thompson, Jeff <[e-mail]<mailto:[e-mail]>> wrote:

Hi Marc,

Some comments:

Section 3.3 says “The excludes must be sorted in ascending order, using the normal Name sorting rules.” What are the “normal” name sorting rules? I don’t see them in  draft-irtf-icnrg-ccnxmessages-03.

It’s the 3rd paragraph of that section.  I’ll clear up the wording.


Section 4 says “A non-participating content store MUST objey the outer cache control directives, as normal…. It is RECOMMENDED that a participating node creating the encapsulated response set a short RecommendedCacheTime.” But draft-irtf-icnrg-ccnxmessages-03 section 3.4.2 says “[a Recommended Cache Time] is a recommendation only and may be ignored by the cache.”  So, for a non-participating content store, behavior “as normal” is that it can ignore the Recommended Cache Time. No? This seems to conflict with “MUST” in draft-mosko-icnrg-selectors-00.

Thank you for pointing out that distinction.  It may be better to use the ExpiryTime than the RecommendedCacheTime.


[You know I was going to bring this up, so here we go.] I assume cache time is important because a name with a selector such as a “right” child selector can indicate a different Content Object from one second to the next. So you need non-participating content stores on the return path to not keep returning the same Content Object for a name with this selector, when the intention is to indicate a “newer” Content Object. But draft-irtf-icnrg-ccnxmessages-03 only recommends obeying RecommendedCacheTime, and downplays problems with changes to this unsigned field, saying "There is little ill effect from an attacker changing the RCT as the RCT serves as a guideline only.” But where selector behavior is concerned, it’s a little more important than “a guideline only” since an old cache hit means that the consumer won’t get what they’re asking for.

Maybe draft-mosko-icnrg-selectors-00 can say something more about this?

Doing right child traversal is actually not the problem,  because as you discover the current right child, you then modify the exclusions to find the next one.  That means the 2nd name is different, so you will not get a cached response.

The following is a bit of thinking out loud...

The problem is if you get back an invalid encapsulated object that does not actually satisfy the Selectors.  In this case, one cannot actually ask for exactly the same thing, as you may get the cached response from a non-participating node.  One must either (a) exclude the invalid return and thus issue a next Selector query that is different and will not hit a cache entry on a non-participating node, or (b) make sure the cache times are short so they do not keep “poisoning” discovery responses.

I think option (a) is the best one, which follows the normal behavior, but one cannot actually do it twice.  For example, Alice sends discovery request Q,  Mallory sends bogus encapsulated response and there are no participating nodes in between.  Alice excludes the bogus response hash which updates the Selector query to Q’.  Mallory is still on path and returns the same bogus answer.  Alice cannot double exclude the same thing, so there’s not a defined method to make query Q’’.

This is a persistent problem when there’s only single path routing to Mallory, who is on path.  It would probably be a problem for NDN too, except it would be caught sooner because all nodes are participating (which would be true here too if all nodes were participating).  It may be useful to include a re-try counter or some similar mechanism (a query nonce) to allow non-participating nodes to differentiate identical requests Q to give them a chance to try multi-path without hitting a cache result (and thus avoid needing to fiddle with cache times).


Thanks,
- Jeff T

On 2016/8/1, 9:07:31, "icnrg on behalf of [e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

All,

Back in 2014, I believe we discussed how to use an equivalent of NDN/CCNx 0.x selector discovery in CCNx 1.0, but we never publicly published that spec.  It was tied up with some early drafts of CCNx 1.0.  Here is a writeup of how to do the equivalent of selector based discovery on top of CCNx 1.0.  I do not intend this to be the single, canonical way of doing discovery.  I think there are many ways one could do it, and CCNx 1.0 provides the flexibility to use different discovery protocols.

I had to update it a fair bit from the pre-public 1.0 spec it was written against at that time.  Therefore, there may still be a few issues with how it is written up and I would appreciate feedback.

Marc

https://www.ietf.org/id/draft-mosko-icnrg-selectors-00.txt


P.S.
Some other example discovery protocols are described here:

http://www.ccnx.org/pubs/hhg/4.8%20CCNx%201.0%20Simple%20Service%20Discovery%20for%20Content%20Centric%20Networks.pdf
http://www.ccnx.org/pubs/hhg/4.7%20CCNx%201.0%20Collection%20Synchronization.pdf

P.P.S
Also on the NDN-INTEREST mailing list, I gave another example that is more SQL-like in syntax and returns row sets (not data objects), and allows one to specifically exclude an entire Content Store.
http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2016-March/001051.html

_______________________________________________
icnrg mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/icnrg