[Nfd-dev] namespace-based strategy choice weakness

[Hila Ben Abraham]

Junxiao and Klaus,

Thank you for taking the time to comment to my email.

I want to add one more point. A forwarding strategy is used today to
support both application and network needs. I think that any selected
design should be able to decompose application needs from strategy
implementation, and minimize the conflicts created when multiple
applications use the same strategy in shared resource networks.

However, I think that it is not feasible to support every application
preference in the strategy choice header.  Following up on Klaus example, one
application would greatly benefit from passing the "deadline" to the
strategy layer, while others would prefer a completely different attribute.
Obviously, the strategy can't support all and the application has the
responsibility to implement its own specific mechanisms. But when it does,
the strategy must not conflict with the application's requests.

This is the reason the report I shared first tries to decompose the core
strategy mechanisms and to understand what should be abstracted for
applications. As mention, this is still work in progress and the report
currently focuses on in-network retransmissions since we found it to be a
crucial mechanism.

Hila

On Sun, Jul 10, 2016 at 4:29 PM Klaus Schneider <klaus at email.arizona.edu>
wrote:

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160714/15a498a5/attachment.html>