[ndnSIM] Red status for the faces

[Alex Afanasyev]

> On Jan 17, 2015, at 5:59 AM, Salvatore SIGNORELLO <salvatore.signorello at uni.lu> wrote:
> 
> Hi Alex,
> 
> thank you for the answer, few more questions inline.
> 
> Best,
> Salvo
> From: Alex Afanasyev [alexander.afanasyev at ucla.edu <mailto:alexander.afanasyev at ucla.edu>]
> Sent: Friday, January 16, 2015 9:12 PM
> To: Salvatore SIGNORELLO
> Cc: ndnsim at lists.cs.ucla.edu <mailto:ndnsim at lists.cs.ucla.edu>
> Subject: Re: [ndnSIM] Red status for the faces
> 
> Hi Salvatore,
> 
>> On Jan 16, 2015, at 12:40 AM, Salvatore SIGNORELLO <salvatore.signorello at uni.lu <mailto:salvatore.signorello at uni.lu>> wrote:
>> 
>> Hi all,
>> 
>> I've written out a simple tracer that prints the status of the faces for
>> the Fib entries, to troubleshoot the weird behavior I've experienced
>> with some simulations, where all the nodes use a BestRoute forwarding
>> strategy.
>> 
>> Well, I've never seen a Face marked as RED using the new developed
>> 'ifaceTracer' after several attempts in different simulation scenarios,
>> the same holds even if I simulate scenario with link failures using the
>> ndn::LinkControlHelper class. So, I've started digging into the source
>> code to see who is really marking the interfaces as RED. By now I've
>> just found the InvalidateAll method of the FibImpl class. This method
>> iterates all the Fib's entries and for each of them it iterates the list
>> of faces and it sets the status to Red calling in turn the Invalidate
>> method of the FaceMetric class. The InvalidateAll method is used only by
>> the GlobalRoutingHelper class to clean the status of all the Fib's
>> entries before starting the computation of the routes. Is there anything
>> I've missed? Could anyone please confirm the workflow summed up above?
> 
> Yes. This is the only place where RED status is set in the codebase.
> 
> May be this is a silly question,but I ask you anyway. Has the Red status
> been introduced as something to be marked just by the routing plane?
> If this is the case, the simulation study conducted and reported into
> the paper "A  case for stateful forwarding plane" did not use red
> labeling. Am I wrong?

Red flag was meant to represent a face with some fatal conditions, that is known to definitely not be able to retrieve the data under the prefix.  We did not go into exact details when exactly this condition happens.

>> Further, what about the probing of (inter)faces? It seems to me that also the codebase has foreseen it, but nobody is really using it.
> 
> 
> Depending on how you define probing.  The codebase doesn’t implement any active probing.  For the passive probing (trying different face if interest is retransmitted while PIT entry is alive), the status of faces may change to yellow (where the face is temporarily demoted).
> 
> Yeap, I meant active probing. So actually if you mark a face as red, the
> forwarding plane has no way of setting it back to working status, isn't
> it?

The point of active probing is to find working/not-working faces.  The strategy that is doing probing would certainly need to ignore the current status.

—
Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20150117/527f2301/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4166 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20150117/527f2301/attachment.bin>