[Nfd-dev] namespace-based strategy choice weakness

[Hila Ben Abraham]

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



On Wed, Jul 6, 2016 at 7:37 PM Klaus Schneider <klaus at email.arizona.edu>
wrote:

> Hi Susmit and Junxiao,
>
> >> b)
> >> Each strategy optimizes for a different goal, such as lower delay,
> >> higher throughput. It does not prioritize traffic of one application
> >> over another.
> >> If you mislabel web traffic as download traffic, you get higher
> >> throughput but possibly more delay so navigation actions are less
> >> responsive.
>
> Yes there is often a trade-off between things like throughput, delay and
> reliability. This will hopefully minimize the incentive to mislabel the
> preferred strategy.
>
> However, I'm not sure if that works in practice. It can become a problem
> when some strategies are clearly superior than others, like IP QoS
> classes ("best-effort", "expedited forwarding", "assured forwarding", etc.)
>
> Or if some strategies (like broadcast) create a much higher overhead
> than others.
>
>
> I like the idea of using a header field for the strategy choice:
>
> >
> > To support this use case, an Interest can carry a strategy choice field.
> NFD can choose a strategy according to this field.
> > We could either put a strategy name into this field and let NFD retrieve
> the strategy program, or put some generic preferences in this field and let
> NFD pick a strategy that best matches those preferences.
> > The bandwidth overhead of this field is less of a concern, because it
> would be much smaller than a Link object.
> > A major challenge in this second idea is that it's unclear which
> strategy would be used if Interests sharing the same PIT entry from
> different consumers are asking for different strategies. It's certainly
> undesirable to split into multiple PIT entries based of different strategy
> choice and send packets multiple times.
> >
>
> Maybe use "first come, first serve" (i.e., the first Interest determines
> the strategy of the PIT entry).
>
> Or use some sort of cumulative logic: Let's say the first Interest wants
> "shortest path", so it is forwarded on the shortest path. A later
> Interest wants "broadcast", so then it is sent out on the remaining
> faces. (Just throwing out ideas. I can see a number of problems here,
> like messing up RTT measurements and overhead).
>
> Also, does the strategy choice in the header field determine the
> strategy of all routers? What if you want "shortest path" on all the
> routers inside the network, but "access strategy" on the last hop?
>
> Best regards,
> Klaus
>
>
>
>
> On 05.07.2016 13:56, Junxiao Shi wrote:
> > Hi Susmit
> >
> > a)
> > This question is orthogonal to my post. I'm talking about /what/ goes
> > into the strategy choice table and how are the entries interpreted, not
> > /where/ those entries come from.
> > Today it's a local configuration by admin of each router / end host.
> > "expressing strategy choice through routing protocols" is a different
> > idea under discussion.
> >
> > b)
> > Each strategy optimizes for a different goal, such as lower delay,
> > higher throughput. It does not prioritize traffic of one application
> > over another.
> > If you mislabel web traffic as download traffic, you get higher
> > throughput but possibly more delay so navigation actions are less
> > responsive.
> >
> > Yours, Junxiao
> >
> > On Mon, Jul 4, 2016 at 6:15 PM, Susmit <susmit at cs.colostate.edu
> > <mailto:susmit at cs.colostate.edu>> wrote:
> >
> >     >
> >     > NFD can choose effective strategy from a marked component.
> >     > Instead of doing longest prefix match in the strategy choice
> table, a
> >     > strategy choice entry can indicate:
> >     >
> >     > contains "app=ndncon" => realtimeI'
> >     > contains "app=ndnfs" => high-throughput
> >
> >     Two questions,
> >
> >     a) Who is responsible for configuring strategies? Operators or users?
> >     Should users be responsible for finding optimal stategies in the
> >     network?
> >
> >     b) How are we going to stop people from mislabeling Interests?
> >     Hypothetically speaking, If web search strategy is
> >     "normal-throughput", pages will load faster if they are labeled
> >     "high-throughput".
> >
> >     Thanks.
> >
> >     --
> >
> >     Regards,
> >     Susmit
> >
> >     ====================================
> >     http://www.cs.colostate.edu/~susmit
> >     <http://www.cs.colostate.edu/%7Esusmit>
> >     ====================================
> >
> >
> >
> >
> > _______________________________________________
> > Nfd-dev mailing list
> > Nfd-dev at lists.cs.ucla.edu
> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> >
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160709/d670e4de/attachment.html>