[Ndn-interest] any comments on naming convention?
jburke at remap.ucla.edu
Fri Sep 26 00:11:24 PDT 2014
I understand that there were probably many network architecture decisions that went into the following, and I am not primarily a network architect. However, it seems most of these examples run up against at least one of two things:
1) An interest with a selector is allowed to match in a cache.
By this I mean, the application semantics of 'leftmost child' and 'rightmost child' as I understand them are 'give me the earliest data ever produced under this prefix', or 'give me the latest data ever', respectively. (Early/late are lexicographical, not temporal.) Allowing caches to respond changes the meaning of the request to 'Give me the earliest/latest data that you've handled recently', and depending on how frequently things are evicted from the cache, it's almost meaningless. I think interests with selectors have special semantics and should never be served from a cache; they should propagate all the way back to the publisher. Excludes might be able to stay the same; the intent is 'please send me *any* data with this prefix, as long as it's not ___'.
I think differentiating between a cache and a producer is not necessarily a good thing. A core architectural idea (as I interpret it) of NDN, is that you asking the network for content, not a specific producer (or cache). Direct communication is a special case. If we focus on that, even in the case of selectors, we seem to lose a lot of interesting scaling properties. Not sure that we want to do that so easily.
2) An interest can only be answered with one Data packet.
I understand the PIT will stay smaller, on average, if we evict an entry as soon as it is satisfied. However, interests have time-outs associated with them; would it be possible to just forward everything that comes in until it is time to evict the entry? I understand it might also complicate the handling on the interest sender's side, since now you would either have to block delivery until the timeout ends and deliver the batch of responses, or maintain the timeout in the application somewhere and handle the stream of response data. But in the case of multiple caches needing to be exhausted, they could at least be searched in parallel, reducing the number of interests that need to be sent.
There was a paper @ ICN that proposed this as well. But there are some flow balance and denial-of-service issues, among other things, that perhaps others can comment on.
On Thu, Sep 25, 2014 at 2:39 PM, <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>> wrote:
I should clarify that the problems I describe below for selectors never knowing if there’s a more recent version apply to, I think, any protocol that’s talking with caches. I don’t mean to pick on selectors, these arguments apply in general. If the caches cannot tell you about the most recent, then you’ll never know by asking them. So its not just selectors, it applies to exact match names or continuation names or any discovery method that gets responses from intermediate caches (unless there’s a consensus protocol operating, but then they are active participants not opportunistic caches).
Only a response from the producer — that says its from the producer and recent — could give an application assurance that its getting the really most recent version. Distributed systems and consistency is a difficult problem.
On Sep 25, 2014, at 11:09 PM, <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>> <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>> wrote:
> On Sep 25, 2014, at 10:01 PM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
>>>> - Benefit seems apparent in multi-consumer scenarios, even without sync.
>>>> Let's say I have 5 personal devices requesting mail. In Scheme B, every
>>>> publisher receives and processes 5 interests per second on average. In
>>>> Scheme A, with an upstream caching node, each receives 1 per second
>>>> maximum. The publisher still has to throttle requests, but with no help
>>>> or scaling support from the network.
>>> This can be done without selectors. As long as all the clients produce a
>>> request for the same name they can take advantage caching.
>> What Jeff responded to is that scheme B requires a freshness of 0 for the initial interest to get to the producer (in order to get the latest list of email names). If freshness is 0, then there's no caching of the data. No meter how the clients name their Interests, they can't take advantage of caching.
> How do selectors prevent you from sending an Interest to the producer, if it’s connected. I send first interest “exclude <= 100” and cache A responds with version 110. Don’t you then turn around and send a second interest “exclude <= 110” to see if another cache has a more recent version? Won’t that interest go to the producer, if its connected? It will then need to send a NACk (or you need to timeout), if there’s nothing more recent.
> Using selectors, you still never know if there’s a more recent version until you get to the producer or you timeout. You always need to keep asking and asking. Also, there’s nothing special about the content object from the producer, so you still don’t necessarily believe that its the most recent, and you’ll then ask again. Sure, an application could just accept the 1st or 2nd content object it gets back, but it never really knows. Sure, if the CreateTime (I think you call it Timestamp in NDN, if you still have it) is very recent and you assume synchronized clocks, then you might have some belief that it’s current.
> We could also talk about FreshnessSeconds and MustBeFresh, but that would be best to start its own thread on.
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
_______________________________________________ Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest