[ndnSIM] Satisfy Interests with more than one producer
Yusung Kim
yskim525 at gmail.com
Wed Apr 3 19:54:46 PDT 2013
Hi Alex,
Yes I agree that it is an important issue.
For the last question,
"if a producer does not consider the digest component, how do the customer
will figure out it?"
In CCNx, the implicit digest component seems to be created and notified
by a CCN library rather than an application itself, right ?
If the process is going to be in a standard protocol such as TCP ( at a
separated layer ), it could be automatically handled without a consumer's *
participation**.*
otherwise, we may use such a protocol at a library ( like the
implementation in CCNx ) or design it at application-layer *individually*.
It's very useful discussion on the digest component.
I appreciate your kind comment.
Thank you,
*
*
- Yusung Kim -
*
*
On Thu, Apr 4, 2013 at 3:55 AM, Alex Afanasyev <alexander.afanasyev at ucla.edu
> wrote:
> Hi Yusung,
>
> It may not be that big of a disadvantage, but it is relatively serious
> requirement for the architecture, raising several questions. What exactly
> is this digest a hash of? The content? The packet? Some other data? Which
> digest algorithm suits best for everybody using the architecture? If
> producers don't consider (directly or indirectly) the digest component, how
> do the customers will figure out what is the digest to be put in the
> Interest?
>
> The last question, at least for me, is one of the major problems of having
> the implicit component. Yes, it is good to have ability to uniquely
> identify the data you want to get, but how exactly can you figure out this
> implicit digest before you got the data (or before data is actually
> produced).
>
> ---
> Alex
>
> On Apr 2, 2013, at 10:35 PM, Yusung Kim <yskim525 at gmail.com> wrote:
>
> Hi Alex,
>
> Thank you for your comment.
> I agree your explanation.
>
> By the way, would you tell me why you consider it as a "big" disadvantage
> ?
>
> When using the implicit digest component,
> a producer or an application developer does not need to consider the
> digest component.
> It seems to be easy to develop applications over NDN.
>
> What is a negative effect on using the implicit digest component?
>
> - Yusung Kim -
>
>
>
>
> On Wed, Apr 3, 2013 at 3:08 AM, Alex Afanasyev <
> alexander.afanasyev at ucla.edu> wrote:
>
>> Hi Yusung,
>>
>> The answer is of course NO, since the Interests specifies one name, but
>> the available data has different (does not matter implicit or explicit
>> component) name.
>>
>> What I'm seeing as advantage (and a "big" disadvantage at the same time)
>> of using the implicit digest component is that routers are required to
>> calculate this component based on the content. This prevents a producer
>> from "lying" and setting one explicit digest, while the content corresponds
>> to a completely different digest.
>>
>> ---
>> Alex
>>
>> On Apr 1, 2013, at 6:31 PM, Yusung Kim <yskim525 at gmail.com> wrote:
>>
>> Hi Alex,
>>
>> It's right, each individual piece of content should have a unique name
>> in NDN.
>>
>> We may explicitly add a digest component to the name as following;
>>
>> 1) /domain.com/video1.avi/sequence_num/*explicit_producer1_digest *
>> 2) /domain.com/video1.avi/sequence_num/*explicit_producer2_digest*
>>
>>
>> When User1 retrieved content by using the name 1) and the data is cached
>> at routers ,
>> if User2 sends an interest packet with the name 2), the interest cannot
>> be served from the Content Store since the cache was stored by the name 1)
>>
>>
>> How about using the implicit digest ?
>>
>> 3) /domain.com/video1.avi/sequence_num/*implicit_producer1_digest *
>> 4) /domain.com/video1.avi/sequence_num/*implicit_producer2_digest*
>> *
>> *
>> Once User1 retrieved content by using the name 3),
>> Could User2 retrieve the cached data, even though User2 sends an
>> interest with the name 4) ?
>>
>> If the answer is NO, what is the merit using the implicit digest
>> instead of the explicit digest?
>>
>> Thank you,
>>
>> - Yusung Kim -
>>
>>
>>
>> On Mon, Apr 1, 2013 at 11:58 AM, Alex Afanasyev <
>> alexander.afanasyev at ucla.edu> wrote:
>>
>>> Hi Yusung,
>>>
>>> No, ndnSIM (as of right now) does not have a concept of the implicit
>>> digest. Ideally, each individual piece of content should have a unique
>>> name. If you really want to distinguish between data produced by Producer1
>>> and Producer2, why not explicitly name these two data pieces differently?
>>> Alternatively, you can explicitly add a digest component to the name.
>>>
>>> ---
>>> Alex
>>>
>>> On Mar 31, 2013, at 7:50 PM, Yusung Kim <yskim525 at gmail.com> wrote:
>>>
>>> Hi Alex and ndnSIM community.
>>>
>>> When using ndnSIM, is there the same function of the implicit digest to
>>> get specific content ?
>>> ( the implicit digest is used in CCNx, right ? )
>>>
>>> In the your example topology,
>>> Does Consumer need to select one producer between Producer1 and
>>> Producer2 using the implicit digest ?
>>>
>>> Thanks,
>>>
>>> - Yusung Kim -
>>>
>>>
>>>
>>> On Mon, Apr 1, 2013 at 4:11 AM, Alex Afanasyev <
>>> alexander.afanasyev at ucla.edu> wrote:
>>>
>>>> Hi Amin,
>>>>
>>>> Let me clarify a little bit with a small example:
>>>>
>>>> Consumer --- Router ----- Producer1
>>>> |
>>>> +--------- Producer2
>>>>
>>>> Assuming ns3::ndn::fw::Flooding strategy, Interests from the Consumer
>>>> will reach both Producer1 and Producer2, and they both will send back a
>>>> content object packet.
>>>>
>>>> Router, receiving the first packet (depending on the topology, could be
>>>> from Producer1 or Producer2) will forward it to the consumer and remove*
>>>> the PIT entry. When the second content object arrives to the Router (not
>>>> the consumer), it will be discarded by the router, as unsolicited. (I
>>>> would not call this as a drop, since it is relatively high-level decision
>>>> to not forward the specific packet.)
>>>>
>>>> * PIT entry can be immediately removed (by default), or scheduled for
>>>> removal within a short time interval (PitEntryPruningTimout). In either
>>>> case, an extra content object will be discarded.
>>>>
>>>> ---
>>>> Alex
>>>>
>>>> On Mar 31, 2013, at 12:02 PM, Amin Karami <amin at ac.upc.edu> wrote:
>>>>
>>>> In case of ns3::ndn::fw::Flooding, we will have several drops.
>>>> Because when a consumer receives desired content from first
>>>> sender/producer, consumer will drop other same contents. Yes? because the
>>>> desired Interest has been satisfied and removed from PIT.
>>>>
>>>>
>>>> /Amin
>>>>
>>>>
>>>>
>>>> On 03/31/2013 08:42 ب.ظ, Alex Afanasyev wrote:
>>>>
>>>> Hi Amin,
>>>>
>>>> I is possible, but it depends on the forwarding strategy to deliver
>>>> Interests to different producers. For example, if you choose
>>>> ns3::ndn::fw::BestRoute, then Interests will only be delivered over the
>>>> "shortest-metric" path and some of the producers will never see the
>>>> Interests. If you use ns3::ndn::fw::Flooding, then all of the producers
>>>> will receive Interests and it would depend on network topology
>>>> (delays/losses) content object from which exactly producer will reach the
>>>> consumer.
>>>>
>>>> In case if you have several consumers, depending on topology and
>>>> forwarding strategy, they may be getting content objects from different
>>>> producers.
>>>>
>>>> If you want only some Interests be satisfied by one producers and
>>>> other by another, you may need to amend ndn::Producer implementation (or
>>>> better create a new custom Producer app) by adding the appropriate logic.
>>>>
>>>> ---
>>>> Alex
>>>>
>>>> On Mar 31, 2013, at 11:35 AM, Amin Karami <amin at ac.upc.edu> wrote:
>>>>
>>>> Hi friends,
>>>> Is it possible to satisfy sent Interests from a consumer with more than
>>>> one producer?
>>>> for example, does the following code work correctly to satisfy
>>>> Interests in /dst1 namespace with three producers?
>>>>
>>>> ndnGlobalRoutingHelper.AddOrigins ("/dst1", producer1); producerHelper.SetPrefix ("/dst1"); producerHelper.Install (producer1); ndnGlobalRoutingHelper.AddOrigins ("/dst1", producer2); producerHelper.SetPrefix ("/dst1"); producerHelper.Install (producer2);
>>>> ndnGlobalRoutingHelper.AddOrigins ("/dst1", producer3); producerHelper.SetPrefix ("/dst1"); producerHelper.Install (producer3);
>>>>
>>>>
>>>> Best Regards,
>>>> /Amin
>>>>
>>>> _______________________________________________
>>>> ndnSIM mailing list
>>>> ndnSIM at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> =======================================================
>>>> Amin Karami, PhD student in Computer Architecture Department (DAC) at
>>>> the Universitat Politècnica de Catalunya Barcelona Tech (UPC)
>>>>
>>>> e-mail: amin at ac.upc.edu | UPC-Campus Nord., Office: C6-E102
>>>> phone: +34 93 40 11 638 | Jordi Girona, 1-3
>>>> | 08034 Barcelona - SPAIN
>>>> WWW: http://personals.ac.upc.edu/amin/
>>>> =======================================================
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ndnSIM mailing list
>>>> ndnSIM at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>>>>
>>>>
>>> _______________________________________________
>>> ndnSIM mailing list
>>> ndnSIM at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>>>
>>>
>>>
>> _______________________________________________
>> ndnSIM mailing list
>> ndnSIM at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20130404/49278f99/attachment.html>
More information about the ndnSIM
mailing list