[ndnSIM] Red status for the faces

[Salvatore SIGNORELLO]

Hi Alex,

________________________________
From: Alex Afanasyev [alexander.afanasyev at ucla.edu]
Sent: Sunday, January 18, 2015 5:19 AM
To: Salvatore SIGNORELLO
Cc: ndnsim at lists.cs.ucla.edu
Subject: Re: [ndnSIM] Red status for the faces


On Jan 17, 2015, at 5:59 AM, Salvatore SIGNORELLO <salvatore.signorello at uni.lu<mailto: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.

Ok for the answer to the former question, but I'm not sure that I've got the answer to the latter question about the simulation study. Was it a "yes, we did use it" or wasn't?

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/20150119/f426efce/attachment.html>