[Ndn-interest] any comments on naming convention?
Lan Wang (lanwang)
lanwang at memphis.edu
Fri Sep 26 08:01:28 PDT 2014
On Sep 25, 2014, at 4:09 PM, <Marc.Mosko at parc.com>
> On Sep 25, 2014, at 10:01 PM, Lan Wang (lanwang) <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.
First of all, I'm not saying selectors prevent you from sending an Interest to the producer. Jeff's example is when you have five devices all wanting to get your emails, then the caching of the Data packet that contains the list of emails in Scheme A helps reduce the load on the producer. No matter how many devices want to get the list and when they send their Interest, the load on the server is constant (at most one Interest for the email list per second in the example). But in Scheme B, in worst case, the producer can get 5 Interests per second.
Second, with or without selectors, you need to keep asking since you never know when new emails will arrive and the list will change. With any design, you need to keep asking. The question is how often to ask. The user may be happy to get his new emails once every 10 minutes. You can ask for a new list every 10 minutes. If you get a list from somewhere (if it was cached, it must have been less than 1 second old if FreshnessSecond of 1 second was used; if not, it must have been generated by the server) or get a NACK from the server, you may stop asking. If the user insists getting new emails as soon as possible, then the email client can send an Interest, say, every minute. This serves as a pending Interest at the server, and the server will respond whenever there's a new list. This pending Interest needs to be refreshed whenever it times out (every minute in this example). This is similar to sync.
More information about the Ndn-interest