[Ndn-interest] any comments on naming convention?

Burke, Jeff jburke at remap.ucla.edu
Fri Oct 3 20:37:58 PDT 2014



On 9/25/14, 2:09 PM, "Marc.Mosko at parc.com" <Marc.Mosko at parc.com> wrote:

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

Just musing but I'm not sure whether those are the only two cases.
Another way to think about it could be that instead of focusing on the
network as providing a path between a producer and consumer, with caches
along the way, and the 'gold standard' for latest version requests being
direct producer-consumer communication, is that the consumer faces a black
box that answers its Interests with certain (varying) timing properties
due to the mixture of multi-homed producers, caches, repos, etc.

In this alternate conceptualization, what's important is what pattern of
Interest/Data exchange seeking the "latest version" the network can
sustain--rather than communication with the producer. I.e., what's the
"latest version" the network can get to the consumer.   In live video
streaming, a respectful consumer application might not care to talk to an
authoritative producer for scaling reasons. Instead, the consumer
determines which of a set of target bitrates within some latency
constraint the "black box" of the network can sustain.  To do this on IP
requires probing and adaptation, so why not on NDN?  The probing for
"latest data" doesn't need to reach the producer - it needs to reflect
what the network can provide.  Some requests might go to the producer, but
they do not all need to.  This may open up more flexibility in how the
network can supply the data, how many producers there can be, when they
need to be online, etc.

A recent SIGCOMM paper [1] proposed that video streaming applications
could focus on simply on playout buffer fill rather than trying to
estimate network capacity, perhaps there is an an analogous idea here - we
can look for approaches that focus on what the network can deliver to the
consumer rather than trying to manage from whom the data comes.

Huang, Te-Yuan, Ramesh Johari, and Nick McKeown. "Downton abbey without
the hiccups:
Buffer-based rate adaptation for http video streaming." Proceedings of the
2013 ACM SIGCOMM workshop on Future human-centric multimedia networking.
ACM, 2013.



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





More information about the Ndn-interest mailing list