[Nfd-dev] namespace-based strategy choice weakness

[Junxiao Shi]

Hi Hila

I briefly read "In-Network Retransmission in Named Data Networking". The
basic idea of this article relevant to this thread is to add an *Interest
Retransmission Policy* (IRP) boolean field to every Interest packet, which
requests the forwarding strategy to either retransmit the Interest in a way
defined by the strategy, or not to do any in-network retransmission.
This idea is in line with having a per-packet strategy choice field. It
specifies an important aspect of what the consumer wants the strategy to
do: retry the Interest upon Nack / RTO timeout, or don't retry at all.

I agree that a per-packet strategy choice field should not name a specific
strategy name, but should indicate general preference of the consumer.
IRP is one aspect. Some other aspects are:

   - Does the consumer prefer a path with lower delay and lower throughput,
   or a path with higher delay and higher throughput?
   - (when IRP=true) Does the consumer want the network to retry the
   Interest upon SRTT timeout, or RTO timeout?



Regarding "To ensure a correct behavior, the application developer
sometimes has to couple the application specifics to the details of the
selected forwarding strategy; if the suppression timer of best-route
changes between revisions, a matching change might be required in the
application code to support the change":
This problem is not a weakness in strategy choice.
As defined in "Networking Named Content", a strategy is a program written
for an abstract forwarding machine. This program can certainly be enclosed
in NDN Data packets. Since NDN Data is immutable, any modification to a
strategy requires changing its name (typically, incrementing a version
number component). Therefore, an application can always choose the same
strategy version it's designed for.

Obviously, this is in conflict with the idea of letting the application to
indicate a preference (instead of selecting a specific strategy). Selecting
a specific strategy on a per-packet basis is infeasible because it would
incur a huge delay if the strategy must be retrieved from some remote
location and loaded into the forwarder, but selecting a specific strategy
through configuration or routing protocol shall be possible, at least
within an enterprise network or within an ISP for their own services.

Yours, Junxiao

On Fri, Jul 8, 2016 at 9:09 PM, Hila Ben Abraham <hila at wustl.edu> wrote:

> All,
>
> I like the idea of supporting the needs of different applications by
> adopting a more flexible strategy choice design.
>
> I support the idea of adding header fields, but I think that this
> 'strategy choice' header should be used to better represent application
> needs rather than a specific strategy name or a strategy metric.
>
> In the last few months, we have been exploring conflicts between
> applications and forwarding strategies. We implemented an additional
> Interest header to support a more flexible in-network retransmission
> mechanism, since we found it to be a core mechanism that can impact both
> correctness and performance of some applications. This is still work in
> progress, but preliminary details can be found here:
> http://openscholarship.wustl.edu/cse_research/910
> http://dl.acm.org/citation.cfm?id=2889475
>
> As Junxiao mentioned, all the current "smart" strategies optimize for a
> minimal round-trip delay. However, each strategy achieves this goal using a
> different implementation. To ensure a correct behavior, the application
> developer sometimes has to couple the application specifics to the details
> of the selected forwarding strategy. For instance, the application must
> understand that ncc retransmits unsatisfied Interests on available faces
> while best-route requires application's retransmission to try additional
> faces. Moreover, if the suppression timer of best-route changes between
> revisions, a matching change might be required in the application code to
> support the change. Therefore, the application code is somewhat coupled
> with the strategy details. This creates challenges in shared resource
> environments as the NDN testbed, when multiple applications use the same
> strategy. Therefore, I think that any new 'strategy choice' design should
> simplify and support application-specific needs.
>
> To add to what Susmit asked, I understand why the question of who is
> responsible for configuring strategy choice seems orthogonal, but I do
> think that the answer to '*who* is responsible' will determine '*what* to
> configure'. Is the goal of this new 'strategy choice'  to have a more
> scalable configuration mechanism? Is it to provide a better support for the
> operator when choosing strategies according to congestion and other network
> issues? Or is it to allow applications-specific needs?
>
> Hila
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160710/41cd70c8/attachment.html>