[Nfd-dev] namespace-based strategy choice weakness

Sun Jul 10 14:29:51 PDT 2016

Hi everyone,

I agree with Hila that the header field should be an *abstract 
preference* rather than the selection of a specific strategy. And as 
Junxiao said, the ISP can then take this preference and provide a number 
of strategies that have clear trade-offs (like throughput vs. delay), so 
that it doesn't make sense for the application to fake the preference.

We have already talked about the preferences of 1) high throughput and 
2) low delay. In last years ICN paper, I also considered 3) high 
reliability (= low packet loss; which is especially relevant in wireless 
or tunneled networks) and 4) the notion that some links/strategies are 
more *costly* to use than others. For example, in-network 
retransmissions are clearly more costly than not retransmitting. But the 
cost can pay off if they help to avoid consumer retransmissions.

However, the preference could be more fine-grained than selecting one of 
the attributes. For example, an audio conferencing application has a 
clear "deadline" until when the data is useful to the application (a 
couple 100 ms). So a router that knows this deadline can make smarter 
decisions about whether to retransmit than it could be just looking at 
the "Interest Retransmission Policy". Early on in the Interest lifetime 
you might want more aggressive retransmissions than shortly before the 
deadline is over.

There is a paper from the ICN'13 which talks about this in more detail 
"Deadline-based Resource Management for Information-Centric Networks" 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.380.6698&rep=rep1&type=pdf

There hasn't been much follow-up work, but maybe it's worth looking into 
these ideas again.

Best regards,
Klaus

> Hi Klaus
>
> The network administrator should ensure that there isn't a strategy "clearly superior" than others available for selection by any applications.
> Consider an ISP network, there could be superior strategies, but they should always be configured under a certain namespace that corresponds to the ISP's own services.
> If a superior strategy is available for selection under other namespaces, nothing stops every application to select it, because only allowing a subset of application (other than ISP's own services) to select this strategy would be a violation of network neutrality.
>
> If application developers are allowed to supply the strategy (through an Interest header field or routing announcements), restrictions could be placed on the overhead caused by those strategy, such as:
>
>     in any 60sec period, the number of outgoing Interests transmitted by the strategy is no more than 110% of incoming Interests
>     on average, at most 64 octets of measurements information can be stored per PIT entry
>     on average, at most 1ms CPU core time is permitted per incoming Interest for strategy program execution
>
> Such restriction can be uniformly placed onto every strategy (for non-ISP-owned services) so it's fair to every application.
>
> Yours, Junxiao
>

On 10.07.2016 09:10, Junxiao Shi wrote:
> 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
> <mailto: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
>