[Ndn-interest] Selector Protocol over exact matching
Marc.Mosko at parc.com
Marc.Mosko at parc.com
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>
More information about the Ndn-interest
mailing list