[ndnSIM] how to modify nonce field in Interest packet
yao hu
huyao0107 at gmail.com
Sat May 4 00:51:51 PDT 2013
Hi Alex,
Thanks for your reply!
I see. I just use my custom strategy in CustomStrategy::DoPropagateInterest
not changing other default things in ndnsim. I set InterestLifetime a very
large value (20000s), but still only one data is retrieved after issuing 30
interests.
I think that is my problem with retransmission strategy. Just now, I
modified it and forwarded the retransmitted interest to other faces except
the failed one. Now it turns out that 23 data are returned for 30
interests. I will check it further.
Regards,
huyao
2013/5/4 Alex Afanasyev <alexander.afanasyev at ucla.edu>
> Hi huyao,
>
> Is the effect that you are describing happens with your custom strategy or
> with something like BestRoute? If you can send me your scenario, I can try
> to check, otherwise I'm not sure what is going on.
>
> From what I explained before, the router would not try to forward toward
> provider1 if there are no active PIT entry, meaning that it has no idea
> that it has already tried provider0 and it should not try again. Unless
> you configure parameters of RTT estimator, RTO timer can have a pretty
> large value, way larger than default InterestLifetime. You can try (for
> experiment) to set InterestLifetime a couple of hours (just to ensure that
> PIT entry never times out) and see how interests are forwarded.
>
> If you're using your custom strategy, do you still using color-coding of
> the faces in FIB?
>
> ---
> Alex
>
>
> On May 3, 2013, at 7:36 AM, yao hu <huyao0107 at gmail.com> wrote:
>
> Hi Alex,
>
> Thanks for your explanation. It seems it works. Then, I have a further
> question about "retry". Assume there is a simple topology as follows.
>
> consumer---router---provider0 /x
> |
> |
> provider1 /x
>
> In router, there are two FIB entries which point to face0 (provider0) and
> face1 (provider1) respectively. But in my forwarding strategy, router
> always forwards interest to face0 (provider0). The consumer sends 10
> interests per second. At some time, I let the link between router and
> provider0 down (link failure). Then the consumer retransmits the interest
> because it does not receive the data. It was expected that
>
> 1) router discards the retransmitted interest before the retry timer
> expires
> 2) consumer retransmit the interest again because it still does not
> receive the data
> 3) finally router will retry face1 (to provider1) to retrieve data after
> the retry timer expires ?
>
> However actually, I just saw few interests forwarded from router to
> provider1. In my rate-trace file, I just saw only one data from 30 issued
> interests for consumer.
>
> I think the router still tried to send retransmitted interest to provider0
> even after link failure happened. Am I right? If not, what is wrong with my
> understanding?
>
> Thanks a lot!!
>
> Regards,
> huyao
>
>
>
> 2013/5/3 Alex Afanasyev <alexander.afanasyev at ucla.edu>
>
>> Hi huyao,
>>
>> Yes, the current ndnSIM is implementing exactly what was mentioned in the
>> paper: when a consumer retransmits an interest, there should be an
>> outstanding PIT entry (if it has expired, then the router has no way to
>> know that the interest has actually been retransmitted), and the router
>> tries to send out interest somewhere else, besides the original face.
>>
>> Yes, you definitely can control where to send out an interest in the
>> forwarding strategy. It is just not exactly obvious. Ultimately,
>> DoPropagateInterest function has full control over what is happening to the
>> interest. Implementations in BestRoute/Flooding strategies use a couple of
>> helper methods to "skip" already tried faces, but you don't need to use
>> them. Just a brief overview what is happening to the interest in
>> DoPropagateInterest (based on BestRoute).
>>
>> -> ForwardingStrategy::TrySendOutInterest
>> -> ForwardingStrategy::CanSendOutInterest
>> -> NO if face == incoming (don't send interest back)
>> -> if # of outgoing > 0 (= have previously forwarded this interest)
>> -> YES if haven't tried yet (this is what essentially outgoing
>> ->m_retxCount >= pitEntry->GetMaxRetxCount () condition is for)
>> -> NO (face will be skipped)
>> -> YES otherwise
>>
>> ---
>> Alex
>>
>> On May 2, 2013, at 6:27 PM, yao hu <huyao0107 at gmail.com> wrote:
>>
>> 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
>>>
>>>
>>>
>> _______________________________________________
>> 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/20130504/23fa7e83/attachment.html>
More information about the ndnSIM
mailing list