[ndnSIM] Satisfy Interests with more than one producer
Yusung Kim
yskim525 at gmail.com
Tue Apr 2 22:35:11 PDT 2013
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/20130403/7581f1ea/attachment.html>
More information about the ndnSIM
mailing list