[ndnSIM] smartflooding behavior in case of link failure

[yao hu]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20130507/8361bb27/attachment.html>
-------------- next part --------------
# topo-linkfailure.txt

router

#node	city	y	x	mpi-partition
c	NA	50	10	
r8	NA	30	20	
r2	NA	70	30	
r4	NA	50	30	
r9	NA	30	30	
r12	NA	10	30	
r1	NA	80	40
r5	NA	50	40	
r10	NA	30	40	
r3	NA	70	50	
r6	NA	50	50	
r11	NA	30	50	
r7	NA	60	60	
r13	NA	10	70
p	NA      50      70

link

# from	    to		capacity	metric	delay	queue
r1	    r2   	10Mbps		1	10ms	100
c	    r2 	        10Mbps		1	10ms	100
r2	    r3   	10Mbps		1	10ms	100
r3	    r7   	10Mbps		1	10ms	100
r7	    p    	10Mbps		1	10ms	100
c	    r4   	10Mbps		1	10ms	100
r4	    r5   	10Mbps		1	10ms	100
r5	    r6   	10Mbps		1	10ms	100
r6	    r7  	10Mbps		1	10ms	100
c	    r8   	10Mbps		1	10ms	100
r8	    r9   	10Mbps		1	10ms	100
r9	    r10 	10Mbps		1	10ms	100
r10	    r11 	10Mbps		1	10ms	100
r11	    p    	10Mbps		1	10ms	100
r8	    r12    	10Mbps		1	10ms	100
r11	    r13    	10Mbps		1	10ms	100