[ndnSIM] how to modify nonce field in Interest packet

yao hu huyao0107 at gmail.com
Thu May 2 18:27:07 PDT 2013


Hi Alex,

Thanks very much! Just a little confusion about what you said.. :(

>>...the consumer just retransmits the interest with the same name and
different nonce.
I remembered in one of your papers ("A Case for Stateful Forwarding Plane")
which says "an Interest retransmitted by the consumer that may need to be
forwarded using a different outgoing interface". Then in the current ndnsim,
for consumer, the retransmitted interest is sent on different faces? Could
I control that way or select the "different outgoing interface" in
forwarding stategy? (As you said, this should be also not the consumer
application)

Thanks a lot!!

Regards,
huyao



2013/5/3 Alex Afanasyev <alexander.afanasyev at ucla.edu>

> Hi huyao,
>
> Consumer retransmission timeout is not the same thing as PIT entry
> lifetime.  I tend to think that it should be shorter.  This way, when
> consumer retransmits, there is PIT entry (= memory about previous interest)
> and router may make a decision (and has ground to make this decision) to
> forward the retransmitted interest on some other available face.
>
> What I'm going to say next applies to the implemented strategies in ndnSIM
> and does not exactly apply to the strategy implemented in ccnx code.
>
> The consumer/end host is responsible to retransmit an interest if it feels
> that the data have not came back in time.  There is no notion of faces or
> interfaces, the consumer just retransmits the interest with the same name
> and different nonce.
>
> Intermediate nodes/routers receiving an interest in some cases can detect
> that the interest has been retransmitted by the consumer (this implies that
> there is an unexpired PIT entry).   When it is detected, the router may
> chose different face to forward the interest to.
>
> As I said earlier, consumer application has no idea (and I don't believe
> it should have any idea) about faces/interfaces available on the computer.
>  The application knows only how to express interest and how to handle data.
>  How exactly the interest is forwarded and to where it is forwarded, this
> should be a sole responsibility of the underlying NDN stack, not the
> application.
>
> I hope I didn't confuse you even more :)
>
> ---
> Alex
>
>
> On May 2, 2013, at 5:10 AM, yao hu <huyao at goto.info.waseda.ac.jp> wrote:
>
> I am sorry to append some words.. When link failure or network congestion
> happens,
>
> 1) end host or consumer is responsible to retransmit the interest on other
> alternative interfaces
> 2) intermediate node retries the retransmitted interest to other
> alternative interfaces
>
> So is there any strategy difference between 1) and 2) ? what part of
> functions or methods shows that retransmission or retry stategies?
>
> Thanks a lot again!
>
>
> 2013/5/2 yao hu <huyao0107 at gmail.com>
>
>> Hi Alex,
>>
>> Thanks a lot. I am looking into the related code but I am not sure if it
>> also applies to requester? Because there is no PIT entry to check for a
>> requester or consumer. What to do to change or control the requester
>> behavior when retransmitting the interest?
>>
>> Regards,
>> huyao
>>
>>
>> 2013/5/2 Alex Afanasyev <alexander.afanasyev at ucla.edu>
>>
>>> Hi huyao,
>>>
>>> Not really.  An application has basically no control on how exactly and
>>> to where its interests are getting forwarded.
>>> Moreover, an application does not know (and should not know) anything
>>> about other faces of an NDN router.
>>>
>>> Actually, there is already some code (this is part of the forwarding
>>> strategy) that attempts to use different faces if interest is
>>> retransmitted.  If an NDN router receives an interests for which there is
>>> an outstanding PIT entry, and this interest is coming from the face from
>>> which the router has already received an interest (with different nonce),
>>> such an interest is considered a retransmission and there is an attempt to
>>> forward the interest somewhere else.
>>>
>>> ndn::ForwardingStrategy::DetectRetransmittedInterest method defines the
>>> retransmission detection logic.
>>> ndn::ForwardingStrategy::CanSendOutInterest  performing some checking to
>>> determine whether an interest should be forwarded on the face or not,
>>> considering possible retransmission (this call is used in
>>> DoPropagateInterst by the implemented forwarding strategies).
>>>
>>> ---
>>> Alex
>>>
>>> On May 1, 2013, at 8:22 AM, yao hu <huyao0107 at gmail.com> wrote:
>>>
>>> Hi Alex,
>>>
>>> Thanks for your answer. I am sorry there is one more question after
>>> this.
>>> How to re-send timed out interest to all faces, not retransmit it to the
>>> same face again? Do I have to write my own "customConsumer", and do the
>>> following
>>> ndn::AppHelper consumerHelper ("customConsumer");
>>> ApplicationContainer consumer = consumerHelper.Install (node);
>>>
>>> Am I right? Thanks a lot~
>>>
>>> Regards,
>>> huyao
>>>
>>>
>>>
>>> 2013/4/29 Alex Afanasyev <alexander.afanasyev at ucla.edu>
>>>
>>>> Hi huyao,
>>>>
>>>> Actually, each retransmitted Interest by ndn::Consumer* application
>>>> gets its own "unique" (random) nonce.
>>>>
>>>> Consumer::CheckRetxTimeout method (
>>>> https://github.com/NDN-Routing/ndnSIM/blob/master/apps/ndn-consumer.cc#L122)
>>>> is responsible for detecting and scheduling retransmission of Interest.
>>>>
>>>> ---
>>>> Alex
>>>>
>>>> On Apr 28, 2013, at 7:12 PM, yao hu <huyao0107 at gmail.com> wrote:
>>>>
>>>> Hi Alex,
>>>>
>>>> Thanks for your reply. I see.
>>>>
>>>> One more question is about interest time out or retransmission. Is
>>>> there a method or function to deal with Interest retransmission or
>>>> retransmission queue in ndnsim? How about adding a new value to the nonce
>>>> field in retransmission Interest packet to differentiate it from the
>>>> orginal one?
>>>>
>>>> I assume that by default the original Interest and the retransmission
>>>> Interest if timeout happens should be the same format, right?
>>>>
>>>> Thanks a lot ~
>>>>
>>>> Regards,
>>>> huyao
>>>>
>>>>
>>>>
>>>> 2013/4/29 Alex Afanasyev <alexander.afanasyev at ucla.edu>
>>>>
>>>>> Hi huyao,
>>>>>
>>>>> (1) The application is fully responsible to put the nonce into the
>>>>> interests. ndn::Consumer-based applications put nonce from uniform
>>>>> distribution (
>>>>> https://github.com/NDN-Routing/ndnSIM/blob/master/apps/ndn-consumer.cc#L206
>>>>> )
>>>>>
>>>>> (2) There is  GetNonce() method for ndn::Interest class
>>>>>
>>>>> (3) If you write your own app, you just set nonce using SetNonce
>>>>> method.  If you want to reuse existing consumers, then you probably need to
>>>>> change their implementation to some extent.
>>>>>
>>>>> ---
>>>>> Alex
>>>>>
>>>>> On Apr 28, 2013, at 7:06 AM, yao hu <huyao0107 at gmail.com> wrote:
>>>>>
>>>>> Hi Alex,
>>>>>
>>>>> ndnsim documents says nonce field is filled with a value of uint32_t
>>>>> type. Could you please tell
>>>>>
>>>>> (1) what value is filled in nonce field in the current Interest packet
>>>>> implementation.
>>>>>
>>>>> (2) how to get the nonce value when receiving Interest packet?
>>>>>
>>>>> (3) is it possible to fill a self-defined value into nonce field?
>>>>>
>>>>> Thanks very much!
>>>>>
>>>>> Regards,
>>>>> huyao
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>>
>>
>
>
> --
> **************************************************
> 早稲田大学 基幹理工学研究科 情報理工学専攻
> 後藤滋樹研究室
> 胡 曜 (HU Yao)
> E-mail : huyao at goto.info.waseda.ac.jp
> **************************************************
>  _______________________________________________
> 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/20130503/064df561/attachment.html>


More information about the ndnSIM mailing list