[Nfd-dev] smart flooding strategy

[Junxiao Shi]

Hi Lan

In the next month or so, I'll focus on designing strategy building blocks
so that a strategy designer can compose different features into a strategy
to fit different needs (#2000).

You could duplicate access router strategy and make changes in a separate
experimental branch, but I don't recommend trying to commit that into
master, because it would double the maintenance work in case a bug is found
and fixed in access router strategy.
After #2000 is complete, "smart flooding" could be composed as "access
router strategy" with addition of probing building block.


Bug 2452 is scheduled for target version v0.3, which means it must be fixed
before v0.3 release.


Upon RTO expiration of the last working nexthop, the Interest will be
multicasted to all other nexthops. There is no disagreement in this
particular point.

Yours, Junxiao

On Fri, Jan 30, 2015 at 11:22 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

>  Junxiao,
>
>  See comments below:
>
>  On Jan 30, 2015, at 10:52 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
>  Hi Lan
>
>  The access router strategy will not attempt to probe other nexthops,
> until the "last working nexthop" fails. If two laptops can provide the same
> contents, after the faster laptop fails, the strategy will stick with the
> slower laptop, even if the faster laptop recovers.
> In reality, most contents are served from a single laptop which might
> move. The strategy design didn't consider the scenario where multiple
> laptops can serve same contents. This design may change in a future version
> of the strategy.
>
>
>  OK.  For my purpose, recovery is important so I think periodic probing
> needs to be added.  So how about I ask a student to implement a so-called
> smart flooding strategy based on your access strategy code, but add the
> probing part (and any other necessary changes)?  This probing can be what
> Cheng proposed in his "A case for stateful forwarding plane" paper (
> http://www.cs.memphis.edu/~lanwang/).  We can implement this as a generic
> probing strategy that different forwarding strategies can use or customize
> (similar to your retransmission strategy).
>
>  RTO is calculated using the mean-deviation algorithm (same as TCP), but
> there's no multiplier.
>
>
>  OK.
>
>
>  Measurements expiration is not specified in the design. This will be
> fixed in Bug 2452.
>
>
>  When do you plan to fix this?
>
>  I actually meant what will happen when the RTO for an Interest expires?
> Looks like you and Alex have some disagreement on this handling (and Alex
> submitted a gerrit patch?), but I'm not sure what's the final decision and
> what's the rationale.
>
>
>  The implementation accurately follows
> access-router-strategy_20141220.pptx design.
>
>
>  Thanks.
>
>  Lan
>
>
>  Yours, Junxiao
>
> On Fri, Jan 30, 2015 at 7:47 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
> wrote:
>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150131/b8ca6157/attachment.html>