[ndnSIM] FaceIterator
Alex Afanasyev
alexander.afanasyev at ucla.edu
Sat Mar 9 19:24:12 PST 2013
Hi Natalya,
No worries. You're always highly welcome here.
Just in case it may help. Due to the nature of message passing in NS-3 (mostly callbacks), you should be careful in cases of message passing inside the same node. For example in your case, when a node sends out an Interest and this Interest gets "NACKed" inside the same node, the consumer application will receive NACK before you exit SendInterest function (i.e., you can see something like "send call in ConsumerApp"->fw processing->...->DidExhaustForwarding->"onNack in ConsumerApp" stack trace). This may or may not be related in your case, but I was having hard time a couple of times trying to figure out what is happening.
---
Alex
On Mar 9, 2013, at 7:17 PM, Natalya Rozhnova <natalya.rozhnova at lip6.fr> wrote:
> Yes yes, I mean a Consumer node, not application.
> Ok, now I see where the NACKs come from and that I were looking for a bug I didn't have.
> Thanks, Alex! And sorry for disturbing you.
>
> Natalya
>
>
> 10.03.2013, 10:01, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>:
>> I still want to clarify first what do you mean by "Consumer"? Consumer node or a specific consumer application on the "consumer" node?
>>
>> If you are talking about a Consumer node and generating NACKs back to the application when forwarding cannot forward just received interest from the application, then it is definitely a right thing to do.
>>
>> ---
>> Alex
>>
>> On Mar 9, 2013, at 6:51 PM, Natalya Rozhnova <natalya.rozhnova at lip6.fr> wrote:
>>
>>> Hummm... please, let me ask a little question so... I want to make ForwardingStrategy to generate NACKs if transmission queue is full and there are no more available faces to reroute Interests. I add this condition in Nacks::DidExhaustForwardingOptions. Is it right that Consumer will also execute DidExhaustForwardingOptions to generate an NACK if its transmission queue is full?
>>>
>>> Thanks,
>>> Natalya
>>>
>>> 10.03.2013, 09:40, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>:
>>>> Hi again,
>>>>
>>>> The client? Do you mean one of the ndn::Consumer* applications? These classed don't themselves generate NACKs, they can trigger NACK generation if Interests cannot be forwarded anywhere. Not sure what is the problem you are observing...
>>>>
>>>> ---
>>>> Alex
>>>>
>>>> On Mar 9, 2013, at 5:47 PM, Natalya Rozhnova <natalya.rozhnova at lip6.fr> wrote:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>> Thanks! A little update: it seems like OK with faces (and so it was OK from the beginning), I found the error... it's really stupid, the Client generates NACKs himself when transmission queue is full...
>>>>> Is it possible to fix it somehow?
>>>>>
>>>>> Thanks!
>>>>> Natalya
>>>>>
>>>>> 10.03.2013, 08:01, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>:
>>>>>> Hi Natalya,
>>>>>>
>>>>>> Correct me if I'm wrong, but I think you should try another face when the base code cannot forward the Interest. The base version or CanSendOutInterests returns false when the node is trying to send out on the face the node has received interest from (in this case you definitely want to try another, if available), or (if retransmission detection is enabled) the node already send out interest to this phase during the current "retransmission cycle". In the latter case, it is also desirable to try another face to explore alternatives.
>>>>>>
>>>>>> Can you try to disable m_drop_cause logic and always try to send to the next face, if CanSendOutInterest returns false, and see what happens?
>>>>>>
>>>>>> ---
>>>>>> Alex
>>>>>>
>>>>>> On Mar 9, 2013, at 4:05 PM, Natalya Rozhnova <natalya.rozhnova at lip6.fr> wrote:
>>>>>>
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>> In my code, I added a condition at the end of CanSendOutInterest. The m_drop_cause parameter is set to 1 if CanSendOutInterest passes through this condition and returns false (i.g. node can not send Interest to the given face because the transmission queue is full and in this case I want to change the face). m_drop_cause is set to 2 if CanSendOutInterest returns false because of any existing in base code condition (like, retransmissions etc), in this case I don't want to change the face and node should just behaves normally.
>>>>>>> But I check this m_drop_cause parameter and it is equal to 1 but node doesn't try to find the next face (he enters to the condition if(m_drop_cause == 1) continue; but then just exits, it seems like there are no more available faces).
>>>>>>>
>>>>>>> Oh, yes, I use i_metric. The i_nth was just the last attempt to see if it can change anything.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Natalya
>>>>>>>
>>>>>>>
>>>>>>> 10.03.2013, 06:16, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>:
>>>>>>>> Hi Natalya,
>>>>>>>>
>>>>>>>> NACKs would be generated if DoPropagateInterest return false. TrySendOutInterest method makes an attempt to send out interest over the face and in your code I see that attempt to try next face would be aborted if m_drop_cause is not equal to 1 (e.g., if it is 1, only one face should be tried in most of the cases). Is this m_drop_cause a configuration parameter or something that is set for each attempt?
>>>>>>>>
>>>>>>>> Another side question. Are you intentionally not using metric to rank faces (fib::i_nth instead of fib::i_metric)?
>>>>>>>>
>>>>>>>> ---
>>>>>>>> Alex
>>>>>>>>
>>>>>>>> On Mar 9, 2013, at 1:47 PM, Natalya Rozhnova <natalya.rozhnova at lip6.fr> wrote:
>>>>>>>>
>>>>>>>>> Hi Alex,
>>>>>>>>>
>>>>>>>>> I want to re-send an Interest to next available face if the current one is unavailable because of any special reason. I trace the second face and see that it receives rerouted Interests but sometimes I see that the node generates a NACK rather than resend the Interest to the next face (it even doesn't try to choose the next face and just exits from DoPropagateInterest function ). So, there is something wrong in my implementation or in manually generated FIB... Could you tell me please, do I use a correct way for changing faces?
>>>>>>>>> I rewrite DoPropagateInterest function and choose the interface as follows:
>>>>>>>>>
>>>>>>>>> BOOST_FOREACH (const fib::FaceMetric &metricFace, pitEntry->GetFibEntry ()->m_faces.get<fib::i_nth> ())
>>>>>>>>> {
>>>>>>>>> if (!TrySendOutInterest (inFace, metricFace.m_face, header, origPacket, pitEntry))
>>>>>>>>> {
>>>>>>>>> if(m_drop_cause == 1)
>>>>>>>>> continue;
>>>>>>>>> else break;
>>>>>>>>> }
>>>>>>>>> propagatedCount++;
>>>>>>>>> break;
>>>>>>>>> }
>>>>>>>>> return propagatedCount > 0;
>>>>>>>>>
>>>>>>>>> Is it correct and the problem should not come from this piece?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Natalya
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>> _______________________________________________
>>> 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/20130309/67982aa3/attachment.html>
More information about the ndnSIM
mailing list