[ndnSIM] smartflooding behavior in case of link failure

[yao hu]

Hi Alex,

I understand. Thank you!

Regards,
huyao



2013/5/8 Alex Afanasyev <alexander.afanasyev at ucla.edu>

> 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
>
>
>


-- 
**************************************************
早稲田大学 基幹理工学研究科 情報理工学専攻
後藤滋樹研究室
胡 曜 (HU Yao)
E-mail : huyao at goto.info.waseda.ac.jp
**************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20130509/6612e784/attachment.html>