[Ndn-interest] Selector Protocol over exact matching

Fri Sep 26 01:57:15 PDT 2014

> 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.

The last paragraph was not as clear as it should have been.  Should say:

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

Marc

On Sep 26, 2014, at 10:26 AM, <Marc.Mosko at parc.com> <Marc.Mosko at parc.com> wrote:

> 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
> 
> _______________________________________________
> 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/cb160b3e/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/cb160b3e/attachment.bin>