[Ndn-interest] Selector Protocol over exact matching

Fri Sep 26 01:26:41 PDT 2014

The ccnx 1.0 cache control directives for content objects are specified here, by the way.  This applies to content objects.

http://www.ccnx.org/pubs/ccnx-mosko-caching-01.txt

For an Interest, we played with the idea of adding a “MaximumAge” restriction so only a response with at least that many mills of remaining lifetime would satisfy the interest, but that didn’t seem like a great idea, so its not in the spec anywhere.

Saying “MustBeFresh” in an Interest, as its written up in NDN and in the old CCNx 0.x specs, does not work either.  Here’s a counter example:

A — |
B — C — D — E

Node A sends an Interest for “stale ok”.  Node C forwards it to D.  E is the actual producer who could send a fresh response.

Node B sends a “MustBeFresh” Interest.  Node C, seeing that its different than the previous interest, forwards it to node D too.

Node D receives the 1st interest from A and returns a stale Content Object.

Node C receives a ContentObject that says “Freshness=5”.  So, it must be fresh, yes?  Node C will send the stale response to both A and B.

Node E will eventually get the request from node B, because D could not satisy the request for a fresh response.  Node E forwards the interest to D, who caches it, then forwards it to C.  Node C has already satisfied the two interest, so it drops the fresh response.

Marc

On Sep 26, 2014, at 10:12 AM, <christian.tschudin at unibas.ch> <christian.tschudin at unibas.ch> wrote:

> On Fri, 26 Sep 2014, Ignacio.Solis at parc.com wrote:
> 
>> On 9/25/14, 10:35 PM, "Lan Wang (lanwang)" <lanwang at memphis.edu> wrote:
>> 
>>> In NDN, if a router wants to check the signature, then it can check.  If
>>> it wants to skip the checking, that's fine too.  If the design doesn't
>>> allow the router to verify the signature, then that's a problem.  In the
>>> above description, the cache signs a data packet with a name owned by
>>> someone else, it seems problematic for a design to advocate this.
>> 
>> Routers that support the Selector Protocol could check signatures.
>> 
>>> 
>>> One difference is that here the returned data can satisfy only that
>>> interest.  In the original selector design, the returned data can satisfy
>>> other Interests with the same name but different selectors (e.g., > 50).
>> 
>> Interests with the same selector would be exact matched throughout the
>> network at any node.
>> 
>> Interests with different selectors would not match on all routers, but
>> they would match just fine on routers that supported the Selector Protocol.
>> 
>> Basically, everything you want works on routers that support the Selector
>> Protocol, but routers that don¹t want to support it, don¹t have to.
> 
> A perhaps more careful statement would be:
> 
> - interests carry a query, not the name of data
>  (except if you go for the hash).
> 
> - caching results based on the query (that you call name)
>  only works of the query is idempotent.
> 
> I doubt that the selector expressiveness remains in idempotent land.
> 
> One requirement thus would be that selector-carrying interests can disable cache reponses from nodes that dont support selectors.
> 
> While it is true that you can force this by adding a nonce to each query, it would be cleaner to have an explicit signaling. Such a don't-cache-flag towards selector-ignoring nodes would be different from the dont-cache-flag in the query (that is directed to selector-aware nodes).
> 
> 
> christian
> 
>> 
>> 
>> Nacho
>> 
>> 
>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Nacho (Ignacio) Solis
>>>> Protocol Architect
>>>> Principal Scientist
>>>> Palo Alto Research Center (PARC)
>>>> +1(650)812-4458
>>>> Ignacio.Solis at parc.com
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Ndn-interest mailing list
>>>> Ndn-interest at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>> 
>>> 
>>> _______________________________________________
>>> Ndn-interest mailing list
>>> Ndn-interest at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> 
>> 
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140926/dba1c4a2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2595 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140926/dba1c4a2/attachment.bin>