[ndnSIM] smartflooding behavior in case of link failure

Alex Afanasyev alexander.afanasyev at ucla.edu
Tue May 7 11:58:12 PDT 2013


Hi huyao,

From what I have gathered, such a behavior resulted from consumer app being too conservative with its retransmission timer.  Because of multiple timeouts, RTO quickly went up to 3.2 seconds (which is larger than default interest lifetime), and you got about 4 seconds to get full recovery from the link failure.

Cbr app in general is very simplistic.  If you disable line 310 in ndn-consumer.cc, you should see "better" performance in terms of application delays, but this could comes at cost of too optimistic RTO estimate (which is also kind of wrong...).

---
Alex

On May 6, 2013, at 7:40 PM, yao hu <huyao0107 at gmail.com> wrote:

> Hi Alex, 
> 
> Thanks for your reply. Interest lifetime you mentioned means the InterestLifetime for some entry in PIT? You means 2-second value is not from the provider but from some intermediate node somewhere?
> 
> I attached the topology file, and I use the standard smartflooding way and let the link between r3 and r7 down sometime. I have not updated for about one month, so I am afraid I am not using the latest ndnsim code.
> 
> Thank you very much!
> 
> Regards,
> huyao
> 
> 
> 
> 2013/5/7 Alex Afanasyev <alexander.afanasyev at ucla.edu>
> Hi huyao,
> 
> Would you mind send the scenario that you're running?  2-second value suggests that this behavior is something to do with interest lifetime.  Ideally, the client should have detected the problem way before 2 second period and effectively recover from the problem.
> 
> Are you using the latest ndnSIM code?  There was a problem with RTT estimation that was discovered by Cheng and fixed not long time ago.
> 
> ---
> Alex
> 
> On May 6, 2013, at 11:29 AM, Smallcat <huyao0107 at gmail.com> wrote:
> 
> > Hi Alex,
> >
> > For my understanding, when there is a link failure on the highest rank Green face, it should switch to the secondary ranked Green face. That is, the FullDelay should increase largely and then drop to the normal value after it changed to the secondary face. However, from my observance of app-delays-trace file, first the FullDelay increase and then drop to the normal value, that should be reasonable. But it immediately increases again to a even large value for some time (around 2 seconds) and finally drops to a normal delay value. How to explain this smartflooding mechanism when encounting link failure on first prioritized face?
> >
> > Thank you very much!
> >
> > Regards,
> > huyao
> 
> <topo-linkfailure-huyao.txt>_______________________________________________
> 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/20130507/dbab1e9b/attachment.html>


More information about the ndnSIM mailing list