[Nfd-dev] smart flooding strategy

[Lan Wang (lanwang)]

Junxiao,

A question: how does the access strategy revert back to the best path after a link on the best path recovers from a failure?

Regarding the design of the access route strategy when RTO expires, two questions:

- what is the formula for RTO calculation?

- how is the expiration handled?  I read the issues but it is still unclear to me what's finally implemented.  Do the ppt slides at (http://redmine.named-data.net/issues/1999) reflect the latest design?

Lan

On Jan 29, 2015, at 10:50 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
 wrote:

Hi Lan

You may try this strategy on every node, although it's not what it was designed for.
At least it should perform no worse than NCC.

Access route strategy is designed to avoid creating excess load.
One retrieval failure shouldn't cause the strategy to revert to multicast immediately. See issue 2403 note-2<http://redmine.named-data.net/issues/2403#note-2> for the reason.

Yours, Junxiao

On Thu, Jan 29, 2015 at 12:35 PM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Junxiao,

Can I use the access router strategy (http://redmine.named-data.net/issues/1999) at every node (not just the access router) to implement essentially smart flooding?  Basically, I want the following strategy:

1. The first time an Interest is received, the Interest will be sent to all the faces of the node except the incoming face.

2. When the matching Data packet comes back, the face that brings back the data will be remembered.

3. subsequent Interests to this node will use the remembered face.

4. If no Data comes back, send subsequent Interests to all faces.

Since you implemented the access router strategy, I'm wondering if you think there's any potential problems with this.  Also in your design, you exclude the last working nexthop in step 4.  I'm not sure if this is necessary (it doesn't hurt to try it again).

Lan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150130/f182dca9/attachment.html>