<div dir="ltr">Hi Hila<div><br></div><div>I briefly read "In-Network Retransmission in Named Data Networking". The basic idea of this article relevant to this thread is to add an <i>Interest Retransmission Policy</i> (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.</div><div>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.</div><div><br></div><div>I agree that a per-packet strategy choice field should not name a specific strategy name, but should indicate general preference of the consumer.<br></div><div>IRP is one aspect. Some other aspects are:</div><div><ul><li>Does the consumer prefer a path with lower delay and lower throughput, or a path with higher delay and higher throughput?</li><li>(when IRP=true) Does the consumer want the network to retry the Interest upon SRTT timeout, or RTO timeout?</li></ul></div><div><br></div><div><br></div><div>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":</div><div>This problem is not a weakness in strategy choice. </div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 8, 2016 at 9:09 PM, Hila Ben Abraham <span dir="ltr"><<a href="mailto:hila@wustl.edu" target="_blank">hila@wustl.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">All,<div><br></div><div>I like the idea of supporting the needs of different applications by adopting a more flexible strategy choice design.</div><div><div><div><div><br></div><div>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.</div></div><div><br></div></div><div><span style="line-height:1.5">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 </span>flexible<span style="line-height:1.5"> in-network retransmission mechanism, since we found it to be a core mechanism that can impact both correctness and performance of some applications. </span><span style="line-height:1.5">This is still work in progress, but preliminary details can be found here:</span></div></div><div><div><a href="http://openscholarship.wustl.edu/cse_research/910" rel="noreferrer" style="font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px" target="_blank">http://openscholarship.wustl.edu/cse_research/910</a><br></div><div><a href="http://dl.acm.org/citation.cfm?id=2889475" target="_blank">http://dl.acm.org/citation.cfm?id=2889475</a><br></div></div><div><br></div><div><span style="line-height:1.5">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 </span>environments<span style="line-height:1.5"> 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.</span><br></div><div><br></div><div>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 '<u>who</u> is responsible' will determine '<u>what</u> 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? </div><span><font color="#888888"><div><br></div><div>Hila</div></font></span></div></blockquote></div></div></div></div>