<div dir="ltr">Hi Lan<div><br></div><div>2.</div><div>The problem is not "primary path is not working", but "primary path is working most of the time, but happens to lose one packet". Retrying on the same path helps.</div><div><br></div><div>3.</div><div>Forwarding strategy need not make an assumption on what routing protocol is used, but it should know the quality of paths.</div><div>High quality routes (such as those from link state routing) can reach the destination UNLESS there's a fault. Retrying is less aggressive, and a temporarily failed path is expected to come back shortly so probing is frequent.</div><div>Low quality routes (such as those from autoreg-server) are more likely to be incorrect. Retrying is aggressive, and a path that does not work is assumed to be an incorrect path so probing is infrequent.</div><div><br></div><div>4.</div><div>Backbone router strategy assumes all paths can reach the destination UNLESS there's a fault. If there's a fault, Interests go to backup path, but probing is frequent so that traffic can switch back to primary path once it comes back.<br></div><div>Access router strategy. When a working path is found, probing on other paths is infrequent. When producer is believed to be moved, the strategy won't expect the old path to work again until the new path fails (which means producer is moving again).</div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 1, 2014 at 7:56 AM, Lan Wang (lanwang) <span dir="ltr"><<a href="mailto:lanwang@memphis.edu" target="_blank">lanwang@memphis.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
<br>
<div><span class="">
<div>On Sep 30, 2014, at 6:43 PM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>> wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">Hi Lan
<div><br>
</div>
<div>1.</div>
<div>Yes, the root cause is that laptops are unable to register a precise prefix on the access router.</div>
<div>The most effective solution is to enable remote prefix registration on the access router.</div>
<div><br>
</div>
<div>2.</div>
<div>NCC strategy forwards an Interest to a nexthop, and that nexthop is never used again before InterestLifetime expires.</div>
<div>When there is a packet loss, even if the consumer is able to detect that and retransmit the Interest, the retransmission is suppressed by NCC strategy because it won't forward the Interest again to the same nexthop.</div>
<div>When a Data does not reach consumer before it's needed, the video frame cannot be constructed and cannot play out.</div>
</div>
</blockquote>
<div><br>
</div></span>
If the Interest was forwarded along some alternative paths by NCC, then it should still reach the producer and bring back the data, right?  And if the primary path is not working, sending the Interest there again probably won't help much either.  I just want
 to have a clear understanding of this problem for NDN-RTC on the testbed and then it's more clear how a more effective strategy should work.<span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>3.</div>
<div>Link state routing can ensure all nexthops in FIB entry can reach the destination.</div>
<div>Backbone strategy is designed for this scenario.</div>
<div><br>
</div>
<div>Strategy choice depends on network environment and application needs.</div>
<div>Hyperbolic routing might need a different strategy.</div>
</div>
</blockquote>
<div><br>
</div></span>
I'm not sure if the forwarding strategy should make an assumption of what routing protocol is used.  After all, the routing protocol may be relying on the forwarding strategy to fix some of the temporary problems so that it doesn't have to respond as quickly
 as in an IP network (Cheng's paper).   <span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>4.</div>
<div>The distinction between remote prefixes and local site prefix is: remote prefixes have mostly reachable nexthops and less changes (when link state routing is used), local site prefix suffers more from unreachable nexthops and laptop mobility.</div>
<div>I don't know whether there is a major difference in the structure of those two forwarding strategies, but they will at least differ in some parameter settings.</div>
</div>
</blockquote>
<div><br>
</div></span>
It seems to me that as long as the forwarding strategy satisfies the requirement of "Make use of multiple paths in FIB entry, and learn the best path.", then it can handle various failure situations (whether they are caused by laptop mobility or link failures).
  It would be better if you can make it clear what extra is required for local site prefix.</div><span class="HOEnZb"><font color="#888888">
<div><br>
</div>
</font></span><div><span class="HOEnZb"><font color="#888888">Lan
</font></span></div></div></blockquote></div><br></div></div></div>